I've not been paying attention to this eepro100 issue but
a coworker mentions that she saw a driver (or patch) posted
here back around 6 Sep 2000 by [EMAIL PROTECTED] with
Subject: "Re: eepro100 trouble" that might be of interest.
Also, here's a possibly useless personal note WRT the
eepro100
I've not been paying attention to this eepro100 issue but
a coworker mentions that she saw a driver (or patch) posted
here back around 6 Sep 2000 by [EMAIL PROTECTED] with
Subject: "Re: eepro100 trouble" that might be of interest.
Also, here's a possibly useless personal note WRT the
eepro100
I got my new AsusA7V motherboard and AMD Thunderbird
booting RedHat5.2/linux2.0.36 with no trouble. (A dusty
old RH5.2 CD was all I had handy at the time) I then
downloaded the 2.2.17 and 2.4.0test8 sources and built
them, only to find that neither would even TRY to boot;
after I see the
I got my new AsusA7V motherboard and AMD Thunderbird
booting RedHat5.2/linux2.0.36 with no trouble. (A dusty
old RH5.2 CD was all I had handy at the time) I then
downloaded the 2.2.17 and 2.4.0test8 sources and built
them, only to find that neither would even TRY to boot;
after I see the
>> The problem I'm seeing is that at least one driver
>> has signed up to handle the wrong IRQ because,
>> when it queried that PCI config value, it went
>> back and got it from PCI config space rather
>> than from the in-kernel data structures where the
>> (correct) recalculated value had
Is there something (other than the kernel sources)
that I can read in order to understand the background
to the current state of PCI handling? I'm asking
because I (think I) have found an interrupt handling
bug that derives from uncoordinated management of
PCI config info, but I don't want to
Is there something (other than the kernel sources)
that I can read in order to understand the background
to the current state of PCI handling? I'm asking
because I (think I) have found an interrupt handling
bug that derives from uncoordinated management of
PCI config info, but I don't want to
The problem I'm seeing is that at least one driver
has signed up to handle the wrong IRQ because,
when it queried that PCI config value, it went
back and got it from PCI config space rather
than from the in-kernel data structures where the
(correct) recalculated value had been stored.
I wrote:
> I'm chasing (what appears to be) an interrupt-
> related problem that involves an Intel Lancewood
> SMP motherboard and I'd like to get my hands on
> something like a schematic or any other document
> that details the layout. Is this info available?
...and eventually found the
I'm chasing (what appears to be) an interrupt-
related problem that involves an Intel Lancewood
SMP motherboard and I'd like to get my hands on
something like a schematic or any other document
that details the layout. Is this info available?
-
To unsubscribe from this list: send the line
10 matches
Mail list logo
