Re: kern/46931: Lock-up at resume apparently due usb(4)

[Grégoire Sutre <gregoire.sutre%gmail.com@localhost>]

The following reply was made to PR kern/46931; it has been noted by GNATS.

From: =?ISO-8859-1?Q?Gr=E9goire_Sutre?= <gregoire.sutre%gmail.com@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/46931: Lock-up at resume apparently due usb(4)
Date: Tue, 25 Sep 2012 02:49:49 +0200

 I've made more experiments, and the problem seems to be i/o related.
 The machine does not in fact lock up, as it responds to ping.  But
 the shell locks up after resume as soon as it accesses the disk.
 
 The conditions under which the bug happens are rather strange.  So,
 for the sake of reproducibility, I detail the procedure that I used
 for testing.  The problem arises with -current, but does not occur
 with 6.0 RC2.
 
 
 1. Download and burn the iso image on a DVD+RW.  I tried:
     - NetBSD-6.0_RC2-amd64.iso
     - NetBSD-6.99.11-amd64.iso  [NetBSD-daily/HEAD/201209230730Z]
 
 2. Boot on the DVD, then exit the install system and re-install a
 fresh base system on the hard drive (wd0a):
 
 mount /dev/wd0a /mnt
 cd /mnt
 rm -rf .cshrc .profile [a-z]*
 for s in base etc kern-GENERIC modules ; do
      tar -zxpf /amd64/binary/sets/$s.tgz
 done
 cp -p usr/mdec/boot .
 echo "/dev/wd0a / ffs rw,log 1 1" > etc/fstab
 echo "PermitRootLogin yes" >> etc/ssh/sshd_config
 cd dev
 ./MAKEDEV all
 cd /
 umount /mnt
 reboot
 
 3. Boot NetBSD from the hard drive, as single user, then accept the
 default shell (/bin/sh), and then source a test script that contains
 the following:
 
 sysctl -w hw.acpi.sleep.vbios=0
 mount /
 /etc/rc.d/syslogd start
 sleep 5
 echo -e '\a'
 sysctl -w hw.acpi.sleep.state=3
 echo -e '\a'
 sleep 0.5
 ls
 echo -e '\a'
 
 Wait for a few seconds after suspend and press the power button.
 
 
 I use beeps in the script since the laptop's panel remains blank
 after resume, but that's another story.
 
 Normally, there should be two beeps after resume.  However, with
 the -current installation, there is only one beep, and the shell
 becomes unresponsive.  Furthermore, pressing the power button does
 not shut the system down.  There is no such problem with 6.0 RC2.
 
 The problem with -current does not occur if syslogd is stopped
 before suspend in the above script.  Moreover, as mentioned in the
 original report, the problem does not occur if usb(4) is disabled
 in userconf.  Another way that seems to avoid the problem is to
 read the disk with ls and cat on a few directories and files before
 launching the above script.
 
 Getting back to the case where the machine exhibits the problem,
 by monitoring with an ssh connection, I can run top before suspend.
 Then, top resumes without problem (but of course, the ssh connection
 locks up as soon as I leave top).
 
 Before suspend, top shows:
 
 52 root      85    0    23M 1944K kqueue/0   0:00  0.00%  0.00% syslogd
 
 After suspend:
 
 52 root     117    0    23M 1964K tstile/2   0:00  0.00%  0.00% syslogd
 
 and syslogd remains in the tstile/2 state.