John wrote:
-0009 : System RAM
000a-000b : Video RAM area
000f-000f : System ROM
0010-0ffe : System RAM
0010-00296a1a : Kernel code
00296a1b-0031bbe7 : Kernel data
0fff-0fff2fff : ACPI Non-volatile Storage
0fff3000-0fff : ACPI Tables
2000-2
John wrote:
-0009 : System RAM
000a-000b : Video RAM area
000f-000f : System ROM
0010-0ffe : System RAM
0010-00296a1a : Kernel code
00296a1b-0031bbe7 : Kernel data
0fff-0fff2fff : ACPI Non-volatile Storage
0fff3000-0fff : ACPI Tables
2000-2
On 11/27/06, John <[EMAIL PROTECTED]> wrote:
John wrote:
>> -0009 : System RAM
>> 000a-000b : Video RAM area
>> 000f-000f : System ROM
>> 0010-0ffe : System RAM
>> 0010-00296a1a : Kernel code
>> 00296a1b-0031bbe7 : Kernel data
>> 0fff-0fff2fff : AC
Jesse Brandeburg wrote:
John wrote:
Here is some context for those who have been added to the CC list:
http://groups.google.com/group/linux.kernel/browse_frm/thread/bdc8fd08fb601c26
As far as I understand, some consider the eepro100 driver to be
obsolete, and it has been considered for remova
On 11/29/06, John <[EMAIL PROTECTED]> wrote:
> Let's go ahead and print the output from e100_load_eeprom
> debug patch attached.
Loading (then unloading) e100.ko fails the first few times (i.e. the
driver claims one of the EEPROMs is corrupted). Thereafter, sometimes it
fails, other times it wor
On 12/1/06, John <[EMAIL PROTECTED]> wrote:
> can you try adding mdelay(100); in e100_eeprom_load before the for loop,
> and then change the multiple udelay(4) to mdelay(1) in e100_eeprom_read
I applied the attached patch.
Loading the driver now takes around one minute :-)
ouch, but yep, that
Jesse Brandeburg wrote:
John wrote:
Jesse Brandeburg wrote:
can you try adding mdelay(100); in e100_eeprom_load before the for loop,
and then change the multiple udelay(4) to mdelay(1) in e100_eeprom_read
I applied the attached patch.
Loading the driver now takes around one minute :-)
o
John wrote:
> Jesse Brandeburg wrote:
>> What would you like to do? At this stage I would like e100 to work
>> better than it is, but I'm not sure what to do next.
>
> Hello everyone,
>
> I'm resurrecting this thread because it appears we'll need to support
> these motherboards for several month
Hello all,
[ E-mail address is a bit-bucket. I *do* monitor the mailing lists. ]
I will try and summarize the problem as I understand it at this point.
I've written two messages so far:
http://groups.google.com/group/linux.kernel/msg/3a05d819c66474db
http://groups.google.com/group/linux.kernel/
John wrote:
I have a motherboard with three on-board 82559 NICs.
o eepro100.ko properly initializes all three NICs
o e100.ko fails to initialize one of them
NOTE: With kernel 2.6.14, e100.ko fails to initialize the NIC with MAC
address 00:30:64:04:E6:E4. With kernel 2.6.18 e100.ko fails to
On 11/8/06, John <[EMAIL PROTECTED]> wrote:
Hello all,
[ E-mail address is a bit-bucket. I *do* monitor the mailing lists. ]
I will try and summarize the problem as I understand it at this point.
I've written two messages so far:
http://groups.google.com/group/linux.kernel/msg/3a05d819c66474db
Auke Kok wrote:
This is what I was afraid of: even though the code allows you to bypass
the EEPROM checksum, the probe fails on a further check to see if the
MAC address is valid.
Since something with this NIC specifically made the EEPROM return all
0xff's, the MAC address is automatically i
Jesse Brandeburg wrote:
I suspect that one reason Becker's code works is that it uses IO
based access (slower, and different method) to the adapter rather
than memory mapped access.
I've noticed this difference.
The second thought is that the adapter is in D3, and something about
your kernel
John wrote:
Auke Kok wrote:
This is what I was afraid of: even though the code allows you to
bypass the EEPROM checksum, the probe fails on a further check to see
if the MAC address is valid.
Since something with this NIC specifically made the EEPROM return all
0xff's, the MAC address is au
On 11/9/06, John <[EMAIL PROTECTED]> wrote:
> The second thought is that the adapter is in D3, and something about
> your kernel or the driver doesn't successfully wake it up to D0.
On my NICs, the EEPROM ID (Word 0Ah) is set to 0x40a2.
Thus DDPD (bit 6) is set to 0.
DDPD is the "Disable Deep P
Jesse Brandeburg wrote:
Can you send output of cat /proc/iomem
-0009 : System RAM
000a-000b : Video RAM area
000f-000f : System ROM
0010-0ffe : System RAM
0010-00296a1a : Kernel code
00296a1b-0031bbe7 : Kernel data
0fff-0fff2fff : ACPI Non-volati
16 matches
Mail list logo
