Subject: port-i386/14013: i386/1.5Y kernel hangs in scsi device detection during boot
To: None <gnats-bugs@gnats.netbsd.org>
From: None <wiz@netbsd.org>
List: netbsd-bugs
Date: 09/20/2001 02:27:24
>Number:         14013
>Category:       port-i386
>Synopsis:       i386/1.5Y kernel hangs in scsi device detection during boot
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    port-i386-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Sep 19 17:30:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Thomas Klausner
>Release:        2001/09/20 around 1:00 a.m.
>Organization:
not enough
>Environment:
	
System: NetBSD hiro 1.5V NetBSD 1.5V (HIRO) #0: Sat May 19 23:30:38 CEST 2001 wiz@hiro:/archive/cvs/src/sys/arch/i386/compile/HIRO i386
Architecture: i386
Machine: i386
>Description:
Last booting kernel mentioned above, hadn't tried any in between.

During boot, kernel stops in the middle of detection of scsi devices on
ahc. From last working dmesg:
[...]
ahc0 at pci0 dev 9 function 0
ahc0: interrupting at irq 9
ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs
scsibus0 at ahc0: 16 targets, 8 luns per target
[...]
scsibus0: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 0 lun 0: <IBM, DDRS-39130D, DC1B> SCSI2 0/direct fixed
sd0: 8715 MB, 8387 cyl, 10 head, 212 sec, 512 bytes/sect x 17850000 sectors
sd0: sync (50.0ns offset 8), 16-bit (40.000MB/s) transfers, tagged queueing
sd1 at scsibus0 target 1 lun 0: <QUANTUM, FIREBALL ST4.3S, 0F0C> SCSI2 0/direct fixed
sd1: 4136 MB, 7068 cyl, 6 head, 199 sec, 512 bytes/sect x 8471232 sectors
sd1: sync (50.0ns offset 15), 8-bit (20.000MB/s) transfers, tagged queueing
cd0 at scsibus0 target 3 lun 0: <TOSHIBA, DVD-ROM SD-M1201, 1R08> SCSI2 5/cdrom removable
cd0: sync (100.0ns offset 15), 8-bit (10.000MB/s) transfers
sd2 at scsibus0 target 4 lun 0: <QUANTUM, ATLAS_V_18_WLS, 0200> SCSI3 0/direct fixed
sd2: 17510 MB, 20907 cyl, 4 head, 428 sec, 512 bytes/sect x 35861388 sectors
sd2: sync (50.0ns offset 8), 16-bit (40.000MB/s) transfers, tagged queueing
cd1 at scsibus0 target 6 lun 0: <PLEXTOR, CD-R   PX-W1210S, 1.03> SCSI2 5/cdrom removable
cd1: sync (50.0ns offset 15), 8-bit (20.000MB/s) transfers
sd5 at scsibus0 target 12 lun 0: <QUANTUM, ATLAS IV 18 WLS, 0909> SCSI3 0/direct fixed
sd5: 17522 MB, 13816 cyl, 8 head, 324 sec, 512 bytes/sect x 35885168 sectors
sd5: sync (50.0ns offset 8), 16-bit (40.000MB/s) transfers, tagged queueing

New kernel stops after second cd0 line. In other words: I don't get to
see sd2, cd1, no sd5, even after waiting over 7 minutes -- previously
there was a short pause at the same place, but only for 1-2 seconds.

Entering DDB at this place gives the following traceback:

cpu_Debugger
internal_command
wskbd_translate
wskbd_input
pckbd_input
pckbcintr
Xintr
--- interrupt ---
idle
bpendtsleep
scsipi_execute_xs(c0af0000, 0, 1c4, c0ad8100, c0442eb8)
scsi_scsipi_cmd(c0ad8100, c0442ee4, 6, 0, 0)
scsipi_command(c0ad8100, c0442ee4, 6, 0, 0)
scsipi_test_unit_ready
scsipi_set_xfer_mode
scsi_probe_bus
scsibus_config_interrupts
config_process_deferred
configure
main

>How-To-Repeat:
Boot kernel.
>Fix:
Sorry, unknown.
>Release-Note:
>Audit-Trail:
>Unformatted: