> It's the printk that gets it wrong, although that's harmless. > Intel's documentation states that the bug does NOT exist if the > bits 0 and 1 in eeprom[3] are 1. Thus, the workaround is correct, > the printk is wrong. So why does it fix the problem for him. His report and your reply don't make sense viewed together - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
- [PATCH] eepro100.c, kernel 2.4.1 Augustin Vidovic
- Re: [PATCH] eepro100.c, kernel 2.4.1 Ion Badulescu
- Re: [PATCH] eepro100.c, kernel 2.4.1 Augustin Vidovic
- Re: eepro100.c, kernel 2.4.1 Alan Cox
- Re: eepro100.c, kernel 2.4.1 Andrey Savochkin
- Re: [PATCH] eepro100.c, kernel 2.4.1 Ion Badulescu
- Re: [PATCH] eepro100.c, kernel 2.4.1 Augustin Vidovic
- Re: [PATCH] eepro100.c, kernel 2.4.... Ion Badulescu
- Re: [PATCH] eepro100.c, kernel ... Augustin Vidovic
- Re: [PATCH] eepro100.c, ker... Ion Badulescu
- Re: [PATCH] eepro100.c, ker... Augustin Vidovic
- Re: [PATCH] eepro100.c, ker... Ion Badulescu
- Re: [PATCH] eepro100.c, ker... Augustin Vidovic
- Re: eepro100.c, kernel 2.4.... Andrey Savochkin