How to crash a 4.99.69 with nothing but an USB stick...

[Martin S. Weber]

(NetBSD 4.99.69/i386. 14th of July, GENERIC kernel.)

- Use an MSDOS formatted USB stick.
- insert stick.
- mount
- use the filesystem so the system starts caching (*)
- sync
- umount
- remove the stick. Good chance (but < 100%) the system immediately dies.

- got along in doing so for more than one machine, for more than one stick.
- similarities: heavy activity on the stick, MSDOS filesystem.

- observance1: sometimes the stick blinks (= access) even after umount.
 => I thought this shouldn't happen, access to a device after umount??
- observance2: sometimes the system freezes for some seconds when inserting the stick
 => I thought this shouldn't happen, bring down a system with sticking in a HUB
        with a couple of mass storages??

I'd attach the dmesg of the last machine I crashed this way but I don't have
network so would need to use USB transport risking another crash for which I
am not in the mood at the very moment.

I don't have the time to play with other USB media and other filesystems
at the moment as well as with more modern -current's. Have fun!

-Martin

(*) usually like transfer some gig from or to it. Crash chance rises with
modification of data on the stick.

[Andreas Gustafsson-2]

Martin S. Weber wrote:
> I don't have the time to play with other USB media and other filesystems
> at the moment as well as with more modern -current's. Have fun!

As I reported in PR 38762, I can reliably crash 4.99.62 by mounting a
FFS filesystem over USB.  I have reproduced it on four different
machines, using both flash and rotating media, and using both ehci and
uhci controllers.
--
Andreas Gustafsson, gson@...

[Jared D. McNeill]

Martin S. Weber wrote:

> (NetBSD 4.99.69/i386. 14th of July, GENERIC kernel.)
>
> - Use an MSDOS formatted USB stick.
> - insert stick.
> - mount
> - use the filesystem so the system starts caching (*)
> - sync
> - umount
> - remove the stick. Good chance (but < 100%) the system immediately dies.
>
> - got along in doing so for more than one machine, for more than one stick.
> - similarities: heavy activity on the stick, MSDOS filesystem.
>
> - observance1: sometimes the stick blinks (= access) even after umount.
>  => I thought this shouldn't happen, access to a device after umount??
> - observance2: sometimes the system freezes for some seconds when inserting the stick
>  => I thought this shouldn't happen, bring down a system with sticking in a HUB
> with a couple of mass storages??
>
> I'd attach the dmesg of the last machine I crashed this way but I don't have
> network so would need to use USB transport risking another crash for which I
> am not in the mood at the very moment.
>
> I don't have the time to play with other USB media and other filesystems
> at the moment as well as with more modern -current's. Have fun!

"Me too". Not right away, but eventually it happens. I'm not sure that
it's msdosfs specific, and every time I've triggered it I seem to be
using X at the time so I have yet to catch the panic message.

Cheers,
Jared

[Martin S. Weber]

On Wed, Jul 23, 2008 at 10:02:33PM +0300, Andreas Gustafsson wrote:
> Martin S. Weber wrote:
> > I don't have the time to play with other USB media and other filesystems
> > at the moment as well as with more modern -current's. Have fun!
>
> As I reported in PR 38762, I can reliably crash 4.99.62 by mounting a
> FFS filesystem over USB.  I have reproduced it on four different
> machines, using both flash and rotating media, and using both ehci and
> uhci controllers.

The difference to what I am seeing is that the system does not panic
but instead simply freezes. No reaction on anything.

I might add that USB is giving me headaches on NetBSD for more than two
years now. Nice that we had the first USB stack. Would be nice if we
finally had a working one, too :-)

-Martin

[Martin S. Weber]

On Wed, Jul 23, 2008 at 03:08:54PM -0400, Jared D. McNeill wrote:
> (...)
> "Me too". Not right away, but eventually it happens. I'm not sure that
> it's msdosfs specific, and every time I've triggered it I seem to be
> using X at the time so I have yet to catch the panic message.

Uh yes, I forgot. Freeze might be panic in X. I was running X at the time, too.

-Martin

[Jared D. McNeill]

Martin S. Weber wrote:
> On Wed, Jul 23, 2008 at 03:08:54PM -0400, Jared D. McNeill wrote:
>> (...)
>> "Me too". Not right away, but eventually it happens. I'm not sure that
>> it's msdosfs specific, and every time I've triggered it I seem to be
>> using X at the time so I have yet to catch the panic message.
>
> Uh yes, I forgot. Freeze might be panic in X. I was running X at the time, too.

Just after I wrote my last email I had another one, laptop had been up
for >2 days, plugged in my Blackberry to charge it, and it froze or
panic'd again. Didn't even have to mount it.

Output from a normal attachment of it:

uberry0 at uhub1 port 1
uberry0: Research In Motion RIM Mass Storage Device, rev 1.10/1.06, addr 2
uberry0: at uhub1 port 1 (addr 2) disconnected
uberry0: detached
umass0 at uhub1 port 1 configuration 1 interface 1
umass0: Research In Motion RIM Composite Device, rev 1.10/1.06, addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, 1 lun per target
sd0 at scsibus0 target 0 lun 0: <RIM, BlackBerry SD, 0001> disk removable
sd0: drive offline

Cheers,
Jared

[David Hopper]

This got me too.  I had just bought a Dynex 2-port USB 2.0 PCI card  
and 320GB USB drive to do some network backups on my 4.99.69 x86 box.  
The drive was formatted FFS, mounted with softdep.  I successfully  
copied some 40 GB of data over SFTP, then the system wedged hard.  
Upon rebooting, the drive's magic number was gone, and could not be  
recovered from any of the backup sectors.

uhci0 at pci1 dev 10 function 0: VIA Technologies VT83C572 USB  
Controller (rev. 0x62)
uhci0: interrupting at ioapic0 pin 21
usb0 at uhci0: USB revision 1.0
uhci1 at pci1 dev 10 function 1: VIA Technologies VT83C572 USB  
Controller (rev. 0x62)
uhci1: interrupting at ioapic0 pin 22
usb1 at uhci1: USB revision 1.0
ehci0 at pci1 dev 10 function 2: VIA Technologies VT8237 EHCI USB  
Controller (rev. 0x65)
ehci0: interrupting at ioapic0 pin 16
ehci0: dropped intr workaround enabled
ehci0: EHCI version 1.0
ehci0: companion controllers, 2 ports each: uhci0 uhci1
usb2 at ehci0: USB revision 2.0
[...]
uhub0 at usb0: VIA Technologies UHCI root hub, class 9/0, rev  
1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhub1 at usb1: VIA Technologies UHCI root hub, class 9/0, rev  
1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhub2 at usb2: VIA Technologies EHCI root hub, class 9/0, rev  
2.00/1.00, addr 1
uhub2: 4 ports with 4 removable, self powered
[...]
umass0 at uhub2 port 1 configuration 1 interface 0
umass0: SimpleDrive PS SimpleTech, rev 2.00/1.00, addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, 1 lun per target
sd0 at scsibus0 target 0 lun 0: <WDC WD32, 00BEVT-22ZCT0, 11.0> disk  
fixed
sd0: fabricating a geometry
sd0: 298 GB, 305245 cyl, 64 head, 32 sec, 512 bytes/sect x 625142448  
sectors

--Dave


On Jul 23, 2008, at 1:55 PM, Jared D. McNeill wrote:

> Martin S. Weber wrote:
>> On Wed, Jul 23, 2008 at 03:08:54PM -0400, Jared D. McNeill wrote:
>>> (...)
>>> "Me too". Not right away, but eventually it happens. I'm not sure  
>>> that it's msdosfs specific, and every time I've triggered it I  
>>> seem to be using X at the time so I have yet to catch the panic  
>>> message.
>> Uh yes, I forgot. Freeze might be panic in X. I was running X at  
>> the time, too.
>
> Just after I wrote my last email I had another one, laptop had been  
> up for >2 days, plugged in my Blackberry to charge it, and it froze  
> or panic'd again. Didn't even have to mount it.
>
> Output from a normal attachment of it:
>
> uberry0 at uhub1 port 1
> uberry0: Research In Motion RIM Mass Storage Device, rev 1.10/1.06,  
> addr 2
> uberry0: at uhub1 port 1 (addr 2) disconnected
> uberry0: detached
> umass0 at uhub1 port 1 configuration 1 interface 1
> umass0: Research In Motion RIM Composite Device, rev 1.10/1.06, addr 2
> umass0: using SCSI over Bulk-Only
> scsibus0 at umass0: 2 targets, 1 lun per target
> sd0 at scsibus0 target 0 lun 0: <RIM, BlackBerry SD, 0001> disk  
> removable
> sd0: drive offline
>
> Cheers,
> Jared

[Steven M. Bellovin]

Perhaps a good side-effect of running an old kernel, but I'm not having
any USB problems.

[Jared D. McNeill]

Martin S. Weber wrote:
> I don't have the time to play with other USB media and other filesystems
> at the moment as well as with more modern -current's. Have fun!

If your system is MP, can you try with 'boot -1' and see if the problem
goes away?

[Martin S. Weber]

On Wed, Jul 23, 2008 at 04:55:58PM -0400, Jared D. McNeill wrote:
> Martin S. Weber wrote:
> >I don't have the time to play with other USB media and other filesystems
> >at the moment as well as with more modern -current's. Have fun!
>
> If your system is MP, can you try with 'boot -1' and see if the problem
> goes away?

The crashed system is UP (It's the laptop I've had the acpica probs with
after your intel import). I'm just trying to reproduce on the console to
get a panic message. But you know how reliably you can reproduce a bug
when you want to .....................................................

-Martin

[Patrick Welche-2]

On Wed, Jul 23, 2008 at 10:02:33PM +0300, Andreas Gustafsson wrote:
> Martin S. Weber wrote:
> > I don't have the time to play with other USB media and other filesystems
> > at the moment as well as with more modern -current's. Have fun!
>
> As I reported in PR 38762, I can reliably crash 4.99.62 by mounting a
> FFS filesystem over USB.  I have reproduced it on four different
> machines, using both flash and rotating media, and using both ehci and
> uhci controllers.

Hmm I don't get a panic, just a lot of:

umass0 at uhub1 port 5 configuration 1 interface 0
umass0: Kingston DataTraveler 2.0, rev 2.00/2.00, addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, 1 lun per target
sd0 at scsibus0 target 0 lun 0: <Kingston, DataTraveler 2.0, 1.00> disk removable
sd0: fabricating a geometry
sd0: 988 MB, 988 cyl, 64 head, 32 sec, 512 bytes/sect x 2023424 sectors
sd0: fabricating a geometry
umass0: BBB bulk-out stall clear failed, TIMEOUT
umass0: BBB reset failed, TIMEOUT
umass0: BBB bulk-in clear stall failed, TIMEOUT
umass0: BBB bulk-out clear stall failed, TIMEOUT
umass0: BBB reset failed, TIMEOUT
...

(The BBB... is after "ls -l /mnt", ie the mount worked, but access doesn't - the
ls never returns - the rest of the system is usable, I think the fs is FAT16)

This is with today's -current/amd64, MP.

Cheers,

Patrick