Bug 30802

Summary: repeat of i386/22760. Adaptec SCSI controller cannot find disks after reboot
Product: Base System Reporter: satz
Component: i386Assignee: Justin T. Gibbs <gibbs>
Status: Closed FIXED    
Severity: Affects Only Me CC: ahaynes21
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description satz 2001-09-24 23:10:01 UTC 
Rebooting a running 4.4-Stable FreeBSD system results in the adaptec 2740 bios in not finding any SCSI disks. The apaptec BIOS complains about a SCSI inquiry timeout. I have v1.1 of the adaptec bios. After the inquiry timeout error, the message "no disks to boot" pops up.

Resetting the system with ctrl-alt-del results in the same error. Only power cycling the system allows the adaptec to find its disks. This occured during the 4.1 development cycle and I reported the problem in i386/22760. At some point during the 4.1/4.2 release cycle, the problem disappeared. I was then able ot reboot my system and have it come all the way up without any problems.

It looks like somehow 4.4 (and the older 4.1) adaptec 2740 driver leaves the controller in a state that the motherboard BIOS cannot reset it. 4.4 nor ny of the boot loaders ever get to run once it is in this state so I don't know how to get any register information except to dump them at system shutdown.
Comment 1 Kris Kennaway freebsd_committer freebsd_triage 2001-10-05 06:56:53 UTC 
Responsible Changed
From-To: freebsd-bugs->freebsd-scsi

Assign this to the SCSI list so one of the interested developers can investigate
Comment 2 Justin T. Gibbs freebsd_committer freebsd_triage 2001-10-09 03:24:40 UTC 
Responsible Changed
From-To: freebsd-scsi->gibbs

My driver
Comment 3 Justin T. Gibbs freebsd_committer freebsd_triage 2001-10-09 03:24:57 UTC 
State Changed
From-To: open->analyzed

The ahc driver downloads firmware to the adapter that uses 
the onboard scratch ram in a very different way than Adaptec's 
proprietary firmware.  To ensure that the BIOS is not confused 
by this, the FreeBSD driver resets the chip and attempts to clear 
out all left over state at system shutdown.  This operation is 
performed in sys/dev/aic7xxx/aic7xxx.c:ahc_shutdown().  One 
of two things may be occuring: 

1) Your EISA system BIOS is not reinitialing the chip and its 
scratch RAM prior to invoking the BIOS as it should. 

2) Some change in the scope of the shutdown hook has left the 
chip in a state that on your system requires a full POR to clear. 

I cannot reproduce this particular problem on my EISA systems, 
so fixing this bug will require you to modify the ahc_shutdown() 
routine (stub it out first, then add items until failure) to determine 
the exact cause of the problem.
Comment 4 Justin T. Gibbs freebsd_committer freebsd_triage 2005-08-15 14:16:37 UTC 
State Changed
From-To: analyzed->closed

Feedback timeout.11