Date: Fri, 07 Jun 2002 11:42:32 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Lars Eggert <larse@ISI.EDU> Cc: frank@exit.com, stable@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Numerous hard hangs on TWO different ASUS P4T-E w/P4 1.6G Message-ID: <3D00FE98.3633CFF6@mindspring.com> References: <200206071657.g57Gvc2J003748@realtime.exit.com> <3D00EEC9.50009@isi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Lars Eggert wrote: > This may be unrelated, but I also found out that the sound driver isn't > happy when the card shares its IRQ with someone. The Dell Precision has > an onboard SCSI controller that by default shares an IRQ with the sound > card. Even with no SCSI disks connected, the sound would be really > choppy. When I disabled the SCSI controller in the BIOS, those problems > went away. Most likely, it's the SCSI card IRQ determination that's taking a long time to run, when the IRQ is shared. Basically, if you get an interrupt, all the devices that are attached to it have to be polled to see if they caused it. For some reason, polling the SCSI controller appears to be taking a relatively very long time (or actually having work to do, with nothing connected to it). This could be indicative of a bug in the driver for that card, since the poll routine should decide that there is nothing to service for the card, and just return very, very quickly. It could also be indicative of a problem with the hardware, where the SCSI card is generating interrupts when it's bus is unterminated or simply "because it feels like it" (this should not happen, in practice; you can use "vmstat -i" to see if it is happening anyway). I don't know if it's safe/prudent for the OS to disable two stage controllers (like SCSI or ATA) that aren't going to be useful to the system without a target present. If it's possible to hook up a device to the bus, and not have to inform the system for the device to become recognized (e.g., it should be possible to not require an explicit user initiated reprobe, at least for SCSI, if there is a SCSI reset when an unpowered target is powered, so this would end up needing to be sysctl'able), then it should be possible to avoid the extra bus overhead associated with a poll, automatically. I would *strongly* discourage anyone from implementing this optimization until the underlying SCSI problem is diagnosed and fixed, since from your report, it would be very effective in masking the problem without fixing it, until someone hooked up a disk or tape, and things went to hell again. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D00FE98.3633CFF6>