On Jan 8, 2008 5:23 AM, David Miller <[EMAIL PROTECTED]> wrote:
> I am going to push this patch upstream, it is correct and we
> have a positive test case that failed before, so overall it's
> a net improvement even if we still don't exactly know why
> Adolfo's case still fails.
Sorry it took so l
From: Björn Steinbrink <[EMAIL PROTECTED]>
Date: Mon, 7 Jan 2008 02:46:38 +0100
> On 2008.01.06 19:49:49 -0200, Adolfo R. Brandes wrote:
> > I have this forcedeth MAC address reversal problem when suspending
> > on 2 distinct boxes. I can confirm Steinbrink's patch fixes the
> > problem on only
Björn Steinbrink skrev:
On 2008.01.06 19:49:49 -0200, Adolfo R. Brandes wrote:
I have this forcedeth MAC address reversal problem when suspending
on 2 distinct boxes. I can confirm Steinbrink's patch fixes the
problem on only one of them:
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Cont
Hi,
On Jan 6, 2008 10:46 PM, Björn Steinbrink <[EMAIL PROTECTED]> wrote:
> Any chance that you applied the patch on your modified sources and didn't get
> it right?
It is perfectly possible that I messed something up, although I
double checked what I was doing on the MCP51. However, on that b
On 2008.01.06 19:49:49 -0200, Adolfo R. Brandes wrote:
> I have this forcedeth MAC address reversal problem when suspending
> on 2 distinct boxes. I can confirm Steinbrink's patch fixes the
> problem on only one of them:
>
> 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev f3)
>
I have this forcedeth MAC address reversal problem when suspending
on 2 distinct boxes. I can confirm Steinbrink's patch fixes the
problem on only one of them:
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev f3)
On the other one the problem persists:
00:14.0 Bridge: nVidia C
On 2008.01.05 07:10:02 +0100, Björn Steinbrink wrote:
> - nv_probe sees 00:11:22:00:00:01
> - doesn't match the vendor stuff
> - becomes 01:00:00:22:11:00
>
> Oops, that's not quite the expected thing.
Haha, I just noticed that that even is a multicast address, so you'd get
a random MAC address i
On 2008.01.04 23:43:52 +0100, Andreas Mohr wrote:
> On Fri, Jan 04, 2008 at 11:17:40AM +0100, Björn Steinbrink wrote:
> > On 2008.01.04 09:45:17 +0100, Andreas Mohr wrote:
> > > And then it needs these card I/O functions wrapped into two
> > > functions which interface with driver- and OS-related M
On Fri, Jan 04, 2008 at 11:17:40AM +0100, Björn Steinbrink wrote:
> On 2008.01.04 09:45:17 +0100, Andreas Mohr wrote:
> > And then it needs these card I/O functions wrapped into two functions which
> > interface with driver- and OS-related MAC variables
> > (struct variables ALWAYS stored in usual
Björn Steinbrink skrev:
Richard, could you give this a spin? And then we'd likely need someone
to test that with kexec...
thanks,
Björn
The patch you sent does the trick, works fine now, thanks!
I cannot test this with kexec as I barely know what it is, I'll leave
that to someone else.
/ Ri
On 2008.01.04 09:45:17 +0100, Andreas Mohr wrote:
> Hi,
>
> On Fri, Jan 04, 2008 at 04:43:57AM +0100, Björn Steinbrink wrote:
> > On 2008.01.03 01:42:09 +0200, Adrian Bunk wrote:
> > > [ original bug report: http://lkml.org/lkml/2008/1/2/253 ]
> > >
> > > On Wed, Jan 02, 2008 at 10:48:43PM +0100,
Hi,
On Fri, Jan 04, 2008 at 04:43:57AM +0100, Björn Steinbrink wrote:
> On 2008.01.03 01:42:09 +0200, Adrian Bunk wrote:
> > [ original bug report: http://lkml.org/lkml/2008/1/2/253 ]
> >
> > On Wed, Jan 02, 2008 at 10:48:43PM +0100, Andreas Mohr wrote:
> > > The nv_probe() function then nicely o
On 2008.01.03 01:42:09 +0200, Adrian Bunk wrote:
> [ original bug report: http://lkml.org/lkml/2008/1/2/253 ]
>
> On Wed, Jan 02, 2008 at 10:48:43PM +0100, Andreas Mohr wrote:
> > Hi,
> >
> > On Wed, Jan 02, 2008 at 10:04:49PM +0100, Richard Jonsson wrote:
> > > Bugreport regarding forcedeth driv
I don't know, this all looks a bit dirty to me, MAC reading/writing
should have been implemented in a more central way, then those people
wouldn't have confused heaven and hell with MAC address fiddling.
And yeah, this certainly looks like a bug that should be fixed ASAP,
unless my short analysis
[ original bug report: http://lkml.org/lkml/2008/1/2/253 ]
On Wed, Jan 02, 2008 at 10:48:43PM +0100, Andreas Mohr wrote:
> Hi,
>
> On Wed, Jan 02, 2008 at 10:04:49PM +0100, Richard Jonsson wrote:
> > Bugreport regarding forcedeth driver.
> >
> > When returning from suspend-to-RAM the MAC-address
Hi,
On Wed, Jan 02, 2008 at 10:04:49PM +0100, Richard Jonsson wrote:
> Bugreport regarding forcedeth driver.
>
> When returning from suspend-to-RAM the MAC-address byteorder is reversed.
> After another suspend-resume cycle the MAC-address is again correct. This
> brings a great deal of pain sin
Bugreport regarding forcedeth driver.
When returning from suspend-to-RAM the MAC-address byteorder is
reversed. After another suspend-resume cycle the MAC-address is again
correct. This brings a great deal of pain since the NIC is assigned a
random MAC-address when it is detected as invalid.
17 matches
Mail list logo
