Re: usb panics, ithread lockups, and atapi dma problems

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Hi All,
:
:I'm seeing a variety of usb problems when using my Kingston Data Traveller
:flash memory stick. And am also seeing atapi/dma problems as well.  
:
:Here's a summary, I'm looking for a bit of advice as to how to proceed
:
:
:When my memory stick is plugged in at boot time I get a panic. So far on 3/5
:attempts. This looks like a bug Ian Dowse fixed in -stable back in
:September, and related to the usb stack creating a kernel thread whenever a
:device gets attached. If the device is attached during probing the fork1()
:call runs calling splhigh() and then spl0(). The spl0() call was the
:problem as this enables all interrupts - not a good idea to do during
:device probing. Since the panic looked the same, I am blindly applying the
:below patch in hope it will fix it.
:
:
:Index: kern_fork.c
:===================================================================
:RCS file: /usr/dfly/repo/src/sys/kern/kern_fork.c,v
:retrieving revision 1.17
:retrieving revision 1.17.2.1
:diff -b -B -r1.17 -r1.17.2.1
:611a612
:>     int s;
:619c620
:<       (void) splhigh();
:---
:>       s = splhigh();
:622c623
:<       (void) spl0();
:---
:>       splx(s);
:
:
:may or may not be applicable to df, but not sure if the original spl0() was
:100% correct to begin with. :|
:
:The second problem I'm seeing is related to heavy device i/o on my data
:stick. When I attempt to copy large files to or from my data stick, the
:copy starts to work but about 5 seconds into it I get a complete lockup.

    I think I'm still getting this too.  I'll look into it but it could be
    a while before we figure out what is going on here.

:When I break to ddb and do a ps it tells me that I'm busy executing ithread1 
:when I ask ddb to panic I get a synching filesystems message and it hangs
:forever (well, forever in this case is at least 10 minutes).

    Ok, the boot-time panic we're already discussing but I wanted to comment
    on the spl code in kern_fork()... while it is arguably more correct to
    use splx() instead of spl0(), that patch will not have any effect on the
    usb thread creation code because the usb thread creation code does not
    call the fork routines at all in DFly (or it shouldn't, anyway).  It 
    directly creates a low level LWKT thread.

:The third problem I'm seeing is related to ata/dma and my cd burner.
:
:For the longest time in -stable I'd been using 
:
:hw.ata_atapi_dma=1  in my /boot/loader.conf file.
:
:This doesn't work in DF. The probe finds my cd devices, but accessing them
:always fails. Further, when I do an atacontrol reinit the devices just
:disappear.
:
:With hw.ata.atapi_dma=0  this doesn't happen.
:
:been working fine in -stable with this same hw for over 6 months :(

    DFly is not using ATAng yet, so your best bet is to leave DMA turned
    off for ATAPI devices.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>

:Let me know how you'd like me to proceed.
:
:Cheers,
:
:Andrew.