Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Glenn Burkhardt wrote: > > > 2. Why would swapping the PCI slot cure this problem? Wouldn't the > > > problem follow the card if the interrupts are mismatched? > > It changes the I.O address and IRQ. > This is not an explanation. It's true, but it doesn't explain why the system > behaves differently after the slot change. > > Changing the card slot is a standard trick for getting boards to work in > Micky-soft systems. It forces the system to delete an existing device driver > (for the IO/IRQ values that no longer correspond to a board type), and install > a new copy of the driver. 3Com even mentions it in their manuals. > > But I'm hard pressed to understand why it would make a difference to a Linux > system, unless the original hardware/BIOS configuration was wrong. Because the BIOS has the Plug and Play routines that assign the parameters to the cards, not the OS. And it goes from the first card to the next assigning them. Note that I even put the cards back in the original order, but the two motherboards must go through the PCI slots in a different order from each other. - Subcription/unsubscription/info requests: send e-mail with "subscribe", "unsubscribe", or "info" on the first line of the message body to discuss-request at blu.org (Subject line is ignored).
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |