Date: Wed, 22 Dec 1999 15:12:21 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: current@freebsd.org, sos@freebsd.org Subject: General ata grousing Message-ID: <199912222012.PAA09596@skynet.ctr.columbia.edu>
next in thread | raw e-mail | index | archive | help
In an earlier post on -hackers, I mentioned that attempting to kldload the usb.ko module after the kernel had booted would panic the system. So far I've managed to track this problem all the way down down to sys/i386/isa/intr_machdep.c:add_intrdesc(). The system crashes when the uhci_pci module tries to set up an interrupt handler using bus_setup_intr(). I strongly suspect this is being caused by an unpleasant interaction with the ata driver: just my luck, the ATA controller, USB UHCI controller and power management happen to be implemented as subfunctions of the same PCI device. (Note that having /boot/loader pre-load the usb module along with the kernel does work.) In my case, each function is assigned IRQ 11 by the BIOS. I would think that each driver would register a handler for this IRQ using bus_alloc_resource() and bus_setup_intr() with the RF_SHAREABLE flag. However from what I can tell, the ATA driver isn't doing this in its PCI attach routine. I'm not sure why. What is doing is very weird: it appears that it tries to call inthand_add() directly in at least one part of the code. I'm nowhere near understanding the whys and the wherefores for all this yet, something tells me this has to be related to the USB problem. By some special magic, everything just happens to work right when the devices are probed at boot time (and of course, nobody thought to test any other case), but things break very badly when trying to load the usb.ko module *after* the system has booted. I don't want to sound like an ungrateful wretch, unduly criticizing someone else's code, especially at so late a date, but there are some other things that just seem like they really shouldn't be there: - Platform dependencies. The inthand_add() thing I mentioned previously appears to be an x86-specific kludge, and there's an alpha kludge to go along with it. There should be some way to get rid of this. - Magic numbers everywhere. I see lots of places where I/O and PCI config registers are being manipulated using just hard coded register offsets and bitmasks. Magic numbers are bad, mmmm-kay? - Use of inb/outb instead of bus_space_read_X()/bus_space_write_X(). My understanding is that bus_space_read_X()/bus_space_write_X() are the prefered way of doing register accesses. inb/out and friends are deprecated. Anyway, I'm going to continue trying to hunt down the interrupt setup problem once I get home tonight (nice thing about having a laptop for a test box: you don't have to leave the test machine at work and frob it remotely). If anyone has any insights, please feel free to share them. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912222012.PAA09596>