Messages in this thread |  | | | From | "Etienne Lorrain" <> | | Date | Thu, 16 Apr 1998 17:49:04 +0001 | | Subject | Re[2]: Pending IDE update for SMP, bugfixes, ... |
| |
Hi,
> I don't use a SMP machine, but have some experience with ali chipset, > so my $0.02: > > 1. I don't think it is safe to enable other CPU's interrupts while > probing ports for chipset detection. Some of ports beeing probed > may be used by other hardware (eg. for some MB's 0x34 is same as 0x20 > and probing it causes interrupt controller reprogramming)
I'd like also to add my $0.02 :
IHMO, to detect a chipset (and if it is possible), the software should try to read the I/O area in probe and search "constant bits", for instance bit which are always zero with the chipset considered. This can be done interrupt enabled.
When it is pretty sure that the board is here, it has to disable interrupt, then write some commands to be completely sure. If the result is positive, just continue initialising the board interrupt disabled, else (false detection) restore initial value of register before re-enabling interrupt.
This will not work for every chipset, but is mostly safe and do not disable interrupt too long. Also, the process exit quickly if no board are there (first read at 0xFF instead of a bit to 0). If an interrupt is generated by reading I/O space, the IRQ driver will most of the time be able to ignore it.
> 2. Is it (possible problems during probing) the reason that chipset probing > code is not available when compiling IDE support as a module?
Anyway probing while mounting a disk may be not safe enough.
My 0.02 French Francs, Etienne. ----------- etienne.lorrain@ibm.net -- hdc: irq timeout: status=0xd0 { Busy } -- ide1: reset: success ----------> I like Linux ! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
|  |