lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 2 Aug 2006 13:45:44 -0400 (EDT)
From:	Charlie Brady <charlieb@...ge.apana.org.au>
To:	Auke Kok <auke-jan.h.kok@...el.com>
cc:	Charlie Brady <charlieb@...ge.apana.org.au>,
	NetDev <netdev@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	molle.bestefich@...il.com
Subject: Re: [bug] e100: checksum mismatch on 82551ER rev10


On Wed, 2 Aug 2006, Auke Kok wrote:

> [cc-ing netdev]
> [adding original thread authors back, please do not strip CC]

[There were no Cc's visible in the lkml archive I used as source of my 
quotes.]

> Charlie Brady wrote:
>> 
>> Let's assume that these things are all true, and the NIC currently does 
>> not work perfectly, just imperfectly, but acceptably. With the recent 
>> driver change, it now does not work at all. That's surely a bug in the 
>> driver.
>
> There is no logic in that sentence at all. You're saying that the driver is 
> broken because it doesn't fix an error in the EEPROM?

I am not asking the driver to fix errors in the EEPROM. I'm asking it to 
send and receive packets, as it has done in the past.

> We're trying extremely hard to fix real errors here (especially when we find 
> that hardware resellers send out hardware with EEPROM problems) ...

I do not expect the kernel to perform QA tests on my hardware, just work.

> and you are 
> asking for a workaround that will (likely) introduce random errors and 
> failure into your kernel. I do not want to accept responsability for 
> that ...

You publish your code under the GPL. You explicitly disclaim any warranty.

> If you want to edit your own kernel then I am fine with it.

I suspect that if all/many T23 laptops perform as mine does then some 
major vendors will also edit their kernels. I'm sure they would rather not 
do that.

> If you want to recalculate the checksum yourself and put it in the 
> EEPROM then I am also fine with that.

Can you provide a reference as to how I might do that?

> As long as you never ask for support for that NIC. But we can't support 
> an option that allows all users to willingly enable a piece of 
> non-properly-working hardware. Because that is what it is: Not properly 
> configured hardware.

Which it may be. But it doesn't work at all with the new kernel, where it 
has in the past.

> The bottom line is that your problem is that a specific hardware vendor 
> is/was selling badly configured hardware, and you buy it from them, even 
> after it's End Of Lifed for that vendor. Even though that vendor did buy the 
> units properly configured and had all the tools needed to configure them 
> properly.

I don't think either of us knows that.

> I can maybe fix your problem by seeing if we can get you an eeprom 
> update...

That'd be great. Thanks!

Regards

---
Charlie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ