Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Thanks for all your help (was: URGENT! Server can't access net anymore)



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
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org