a panic race on module unload. The wakeup() is internal to
kproc_exit/kthread_exit. The correct fix is to fix the msleep() in
detach to sleep on fdc->fdc_thread instead of &fdc->fdc_thread.
Noted and reviewed by: jhb
Pointy hat to: kib
MFC after: 1 week
Wakeup the thread doing the fdc_detach() when the fdc worker thread exits [1].
Write access to the write-protected floppy shall call device_unbusy() to
pair the device_busy() in the fd_access() [2].
PR: 116537 [1], 116539 [2]
MFC after: 1 week
to kproc_xxx as they actually make whole processes.
Thos makes way for us to add REAL kthread_create() and friends
that actually make theads. it turns out that most of these
calls actually end up being moved back to the thread version
when it's added. but we need to make this cosmetic change first.
I'd LOVE to do this rename in 7.0 so that we can eventually MFC the
new kthread_xxx() calls.
specific privilege names to a broad range of privileges. These may
require some future tweaking.
Sponsored by: nCircle Network Security, Inc.
Obtained from: TrustedBSD Project
Discussed on: arch@
Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri,
Alex Lyashkov <umka at sevcity dot net>,
Skip Ford <skip dot ford at verizon dot net>,
Antoine Brodin <antoine dot brodin at laposte dot net>
significantly reduces booting time when there is broken floppy disk drive,
controller, cable, BIOS, etc.
When the floppy controller interface is correctly implemented, disk change
signal (DSKCHG) is reflected in the Digital Input Register (DIR) at 0x3f7.
However, there are many cases that the signal is unusable. Moreover, some
BIOS does not reserve the port at all. In those cases, the register may not
function.
Use it to reset controller and to select data rate. According to Intel
80277AA datasheet, software reset behaves the same as DOR reset except
that it is self clearing. National Semiconductor PC8477B datasheet says
the same. As a side effect, we no longer use Configuration Control
Register (CCR) at 0x3f7 for these controllers, which is often missing
in modern hardware.
mutex.
- Don't use callout_drain() to stop the toffhandle callout while holding the
fdc mutex (this could deadlock) in functions called from softclock
(callouts aren't allowed to do voluntary sleeps). Instead, use
callout_stop(). Note that since we hold the associated mutex and are now
using callout_init_mtx(), callout_stop() is just as effective as
callout_drain(). (Though callout_drain() is still needed in detach to
make sure softclock isn't contesting on our mutex before we destroy the
mutex.)
- Remove unused callout 'tohandle' from softc.
MFC after: 1 week
Provide a backwards compatible way to have the extra macro by defining
PCCARD_API_LEVEL 5 before including pccarddevs for driver writers that
want/need to have the same driver on 5 and 6 with pccard attachments.
Approved by: re (dwhite)
that we free that resource. All the other resources are freed in
their own routine, but since we haven't saved a pointer to this one,
it is leaked. This is the failure case that lead to the sio ports
that weren't working, I think.
resources. When allocating 6 ports for a 4 port range isa code
returns an error. I'm not sure yet why this is the case, but suspect
it is just a non-regularity in how the resource allocation code works
which should be corrected. Use 1 as the ports size in this case.
However, in the hints case, we have to specify the length, so use 6 in
that case. I believe that this is also acpi friendly.
Also, complain when we can't allocate FDOUT register space. Right now we
silently fail when we can't. This failure is referred to above.
When there's no resource for FDCTL, go ahead and allocate one by hand.
Many PNPBIOS tables don't list this resource, and our hints mechanism also
doesn't cover that range. If we can't allocate it, whine, but fake up
something. Before, we were always bogusly faking it and no one noticed
the sham (save the original author who has now fixed his private shame).
Rather than have a twisty maze of special case allocations, move
instead to a data driven allocation. This should be the most robust
way to cope with the resource problems that the multiplicity of ways
of encoding 5 registers that have the misfortune of not being a power
of 2 nor contiguous.
Also, make it less impossible that pccard will work. I've not been able
to get my libretto floppy working, but it now fails later than before.
phk and I had similar ideas on this during the 5.3 release cycle, but
it wasn't until recently that I could test more than one allocation
scenario.
MFC After: 1 month (5.4 if possible, 5.5 if not)
+ * 9: 0x3f0-0x3f3,0x3f4-0x3f5,0x3f7
This requires only one change to support. Rather than keying on the
size of the resource being 2, instead key off the end & 7 being 3.
This covers the same cases that the size of 2 would catch, but also
covers the new above case.
In addition, I think it is clearer to use the end in preference to the
size and start for case #8 as well. Turns two tests into one, and
catches no other cases.
Make minor commentary changes to deal with new case #9.
# This change is specifically minimal to allow easy MFC. A more
# extensive change will go into current once I've had a chance to test
# it on a lot of hardware...
in the actual _FDE parsing. If the failure occurs earlier such as in
fdc_attach() then don't try to probe any drives.
MFC after: 3 days
Reviewed by: njl
Tested by: Christian Laursen xi at borderworlds dot dk
Use kthread_exit() instead of falling through the end of the worker
thread's main function. Since kthread_exit() wakeup(9)s everyone
sleeping on the thread handle, drop the superfluous wakeup() call.
and 0x3f7. fdc_isa_alloc_resource() didn't work right in this case
(it accessed FDOUT correctly due to an overflow of the first resource.
It accesed FDSTS and FDDATA incorrectly via the second resource (which
wound up accessing FDOUT and the tape register at 0x3f3) and badly for
the CTL register (at location 0x3f4). This is a minimal fix that just
'eats' the first one if it covers two locations and has an offset of
0. This confusion lead the floppy driver to think there'd been a disk
change, which uncovered a deadlock in the floppy/geom code which lead
to a panic. These changes fix that by fixing the underlying resource
problem, but doesn't address the potential deadlock issue that might
still be there.
This is a minimal fix so it can more safely be merged into 5 w/o risk
for known working configurations (hence the use of the ugly goto,
which reduces case 8 to case 6 w/o affecting cases 1-7). A more
invasive fix that will handle more ACPI resource list diversity is in
the pipeline that should kill these issues once and for all, while
staying within the resources that we allocate.
Tested/Reported by: das
Reviewed by: njl
MFC before: re->next_release_name(5.3-BETA5);
driver. Trim its fingernails by removing some useless bits before
fixing the 'thread not terminated on detach' problem.
o dmacnt is no longer used now that we allocate at attach time. Remove
it from struct fdc_data.
o ISPNP was only ever set, but never tested. It used to be used for the
allocation routines to change how it allocated resources. Since that's
no longer necessary, retire the flag.
o ISPCMICA was only ever tested, but never set. GC it. This removes
a special case in determining the drive type. The drive type is
now set in fdc_pcmcia.c, so the hack isn't needed anymore. Sadly,
this isn't tested with a Y-E Data pcmcia floppy drive because there
are a number of other issues that preclude it from working.
o Fix ifdef for reading from the rtc. I'm of the opinion that this ifdef
should be moved into fdc_isa.c, but not today as ideally there'd be
other fixes to the probing of children. So now we just read it on
i386 ! pc98 (there's no #define for MACHINE_ARCH, just MACHINE, hence
this slightly inelegant kludge) and amd64. The PC98 exclusion likely
isn't meaningful since pc98 uses a different driver, but will be when
merging of the pc98 floppy code into this driver is complete (this is the
other reason I think this block of code belongs outside fdc.c).
All of these changes are safe to MT5.
another way to misinterpret the spec. Also, always fall back to the hints
probe on any attach failure, not just when _FDE fails.
Thanks to imp and scottl for finding this.
Tested by: rwatson (minimally)
MFC after: 5 days
reserving it at use time is more miserly, low memory (< 16MB)
evaporates quickly on many systems, so there may not be any suitable
buffers available. This specifically doesn't use the newer, fancier
isa_dma_init to ease merging to 5.
Reviewed by: tegge, phk
errors for the attachment process for the floppy controller. This is
a band-aide because it doesn't try any of the fallback methods when
_FDE isn't long enough, but should be sufficient for people
experiencing the dreaded mutex not initialized panic.
o Allow for up to 3 resource I/O ranges to be given for the floppy
controller, rather than just two that are allowed for now.
o Make sure that we can work with either a base address of 0x3f0 or 0x3f2.
o Create new inline functions to access the YE DATA's unique BDCR register.
o Update pccard attachment to add the fd device.
o Do some minor style(9) polishing.
# I'm guessing that the fdc pccard attachment broke some time ago, since
# there are a number of issues with it still.
ENOENT when there's no PNP ID for this device node, or ENXIO when there
is one, but it doesn't match.
In the nonPNP case (as most Alpha systems appear to be), we were
treating the error return as an error, when it should be have ignored
it. Version 1.9 properly ignored it, but the attach re-write of 1.10
introduced this logic error.
Pointy Hat to: phk (for breaking it then asking me to fix it :-)
Sponsored by: The Voices in Bill Paul's Head, LLC
the old one is. Hence we need to evaluate the old one for _FDI since it
has a valid ACPI_HANDLE ivar. This is a minimal fix. Make a note that a
more complete one is to make fdc support the ACPI_HANDLE ivar for its
children.
This and the previous change are MT5 candidates.
