Re: 2.6.19-rc6-mm2: uli526x only works after reload

Re: 2.6.19-rc6-mm2: uli526x only works after reload

[Andrew Morton]

On Wed, 29 Nov 2006 21:08:00 +0100
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> On Wednesday, 29 November 2006 20:54, Rafael J. Wysocki wrote:
> > On Tuesday, 28 November 2006 11:02, Andrew Morton wrote:
> > > 
> > > Temporarily at
> > > 
> > > http://userweb.kernel.org/~akpm/2.6.19-rc6-mm2/
> > > 
> > > Will appear eventually at
> > > 
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/
> > 
> > A minor issue: on one of my (x86-64) test boxes the uli526x driver doesn't
> > work when it's first loaded.  I have to rmmod and modprobe it to make it work.

That isn't a minor issue.

> > It worked just fine on -mm1, so something must have happened to it recently.
> 
> Sorry, I was wrong.  The driver doesn't work at all, even after reload.
> 

tulip-dmfe-carrier-detection-fix.patch was added in rc6-mm2.  But you're
not using that (corrent?)

git-netdev-all changes drivers/net/tulip/de2104x.c, but you're not using
that either.

git-powerpc(!) alters drivers/net/tulip/de4x5.c, but you're not using that.

Beats me, sorry.  Perhaps it's due to changes in networking core.  It's
presumably a showstopper for statically-linked-uli526x users.  If you could
bisect it, please?  I'd start with git-netdev-all, then tulip-*.

Re: 2.6.19-rc6-mm2: uli526x only works after reload

[Rafael J. Wysocki]

On Wednesday, 29 November 2006 22:30, Andrew Morton wrote:
> On Wed, 29 Nov 2006 21:08:00 +0100
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
> > On Wednesday, 29 November 2006 20:54, Rafael J. Wysocki wrote:
> > > On Tuesday, 28 November 2006 11:02, Andrew Morton wrote:
> > > > 
> > > > Temporarily at
> > > > 
> > > > http://userweb.kernel.org/~akpm/2.6.19-rc6-mm2/
> > > > 
> > > > Will appear eventually at
> > > > 
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/
> > > 
> > > A minor issue: on one of my (x86-64) test boxes the uli526x driver doesn't
> > > work when it's first loaded.  I have to rmmod and modprobe it to make it work.
> 
> That isn't a minor issue.
> 
> > > It worked just fine on -mm1, so something must have happened to it recently.
> > 
> > Sorry, I was wrong.  The driver doesn't work at all, even after reload.
> > 
> 
> tulip-dmfe-carrier-detection-fix.patch was added in rc6-mm2.  But you're
> not using that (corrent?)
> 
> git-netdev-all changes drivers/net/tulip/de2104x.c, but you're not using
> that either.
> 
> git-powerpc(!) alters drivers/net/tulip/de4x5.c, but you're not using that.
> 
> Beats me, sorry.  Perhaps it's due to changes in networking core.  It's
> presumably a showstopper for statically-linked-uli526x users.  If you could
> bisect it, please?  I'd start with git-netdev-all, then tulip-*.

OK, but it'll take some time.

Re: 2.6.19-rc6-mm2: uli526x only works after reload

[Rafael J. Wysocki]

On Wednesday, 29 November 2006 22:31, Rafael J. Wysocki wrote:
> On Wednesday, 29 November 2006 22:30, Andrew Morton wrote:
> > On Wed, 29 Nov 2006 21:08:00 +0100
> > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > 
> > > On Wednesday, 29 November 2006 20:54, Rafael J. Wysocki wrote:
> > > > On Tuesday, 28 November 2006 11:02, Andrew Morton wrote:
> > > > > 
> > > > > Temporarily at
> > > > > 
> > > > > http://userweb.kernel.org/~akpm/2.6.19-rc6-mm2/
> > > > > 
> > > > > Will appear eventually at
> > > > > 
> > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/
> > > > 
> > > > A minor issue: on one of my (x86-64) test boxes the uli526x driver doesn't
> > > > work when it's first loaded.  I have to rmmod and modprobe it to make it work.
> > 
> > That isn't a minor issue.
> > 
> > > > It worked just fine on -mm1, so something must have happened to it recently.
> > > 
> > > Sorry, I was wrong.  The driver doesn't work at all, even after reload.
> > > 
> > 
> > tulip-dmfe-carrier-detection-fix.patch was added in rc6-mm2.  But you're
> > not using that (corrent?)
> > 
> > git-netdev-all changes drivers/net/tulip/de2104x.c, but you're not using
> > that either.
> > 
> > git-powerpc(!) alters drivers/net/tulip/de4x5.c, but you're not using that.
> > 
> > Beats me, sorry.  Perhaps it's due to changes in networking core.  It's
> > presumably a showstopper for statically-linked-uli526x users.  If you could
> > bisect it, please?  I'd start with git-netdev-all, then tulip-*.
> 
> OK, but it'll take some time.

OK, done.

It's one of these (the first one alone doesn't compile):

git-netdev-all.patch
git-netdev-all-fixup.patch
libphy-dont-do-that.patch

Is a broken-out version of git-netdev-all.patch available from somewhere?

Greetings,
Rafael

Re: 2.6.19-rc6-mm2: uli526x only works after reload

[Andrew Morton]

On Thu, 30 Nov 2006 00:08:21 +0100
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> On Wednesday, 29 November 2006 22:31, Rafael J. Wysocki wrote:
> > On Wednesday, 29 November 2006 22:30, Andrew Morton wrote:
> > > On Wed, 29 Nov 2006 21:08:00 +0100
> > > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > > 
> > > > On Wednesday, 29 November 2006 20:54, Rafael J. Wysocki wrote:
> > > > > On Tuesday, 28 November 2006 11:02, Andrew Morton wrote:
> > > > > > 
> > > > > > Temporarily at
> > > > > > 
> > > > > > http://userweb.kernel.org/~akpm/2.6.19-rc6-mm2/
> > > > > > 
> > > > > > Will appear eventually at
> > > > > > 
> > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/
> > > > > 
> > > > > A minor issue: on one of my (x86-64) test boxes the uli526x driver doesn't
> > > > > work when it's first loaded.  I have to rmmod and modprobe it to make it work.
> > > 
> > > That isn't a minor issue.
> > > 
> > > > > It worked just fine on -mm1, so something must have happened to it recently.
> > > > 
> > > > Sorry, I was wrong.  The driver doesn't work at all, even after reload.
> > > > 
> > > 
> > > tulip-dmfe-carrier-detection-fix.patch was added in rc6-mm2.  But you're
> > > not using that (corrent?)
> > > 
> > > git-netdev-all changes drivers/net/tulip/de2104x.c, but you're not using
> > > that either.
> > > 
> > > git-powerpc(!) alters drivers/net/tulip/de4x5.c, but you're not using that.
> > > 
> > > Beats me, sorry.  Perhaps it's due to changes in networking core.  It's
> > > presumably a showstopper for statically-linked-uli526x users.  If you could
> > > bisect it, please?  I'd start with git-netdev-all, then tulip-*.
> > 
> > OK, but it'll take some time.
> 
> OK, done.
> 
> It's one of these (the first one alone doesn't compile):
> 
> git-netdev-all.patch
> git-netdev-all-fixup.patch
> libphy-dont-do-that.patch

Are you able to eliminate libphy-dont-do-that.patch?

> Is a broken-out version of git-netdev-all.patch available from somewhere?

Nope, and my few fumbling attempts to generate the sort of patch series
which you want didn't work out too well.  One has to downgrade to
git-bisect :(

What does "doesn't work" mean, btw?

Re: 2.6.19-rc6-mm2: uli526x only works after reload

[Rafael J. Wysocki]

On Thursday, 30 November 2006 00:26, Andrew Morton wrote:
> On Thu, 30 Nov 2006 00:08:21 +0100
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
> > On Wednesday, 29 November 2006 22:31, Rafael J. Wysocki wrote:
> > > On Wednesday, 29 November 2006 22:30, Andrew Morton wrote:
> > > > On Wed, 29 Nov 2006 21:08:00 +0100
> > > > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > > > 
> > > > > On Wednesday, 29 November 2006 20:54, Rafael J. Wysocki wrote:
> > > > > > On Tuesday, 28 November 2006 11:02, Andrew Morton wrote:
> > > > > > > 
> > > > > > > Temporarily at
> > > > > > > 
> > > > > > > http://userweb.kernel.org/~akpm/2.6.19-rc6-mm2/
> > > > > > > 
> > > > > > > Will appear eventually at
> > > > > > > 
> > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/
> > > > > > 
> > > > > > A minor issue: on one of my (x86-64) test boxes the uli526x driver doesn't
> > > > > > work when it's first loaded.  I have to rmmod and modprobe it to make it work.
> > > > 
> > > > That isn't a minor issue.
> > > > 
> > > > > > It worked just fine on -mm1, so something must have happened to it recently.
> > > > > 
> > > > > Sorry, I was wrong.  The driver doesn't work at all, even after reload.
> > > > > 
> > > > 
> > > > tulip-dmfe-carrier-detection-fix.patch was added in rc6-mm2.  But you're
> > > > not using that (corrent?)
> > > > 
> > > > git-netdev-all changes drivers/net/tulip/de2104x.c, but you're not using
> > > > that either.
> > > > 
> > > > git-powerpc(!) alters drivers/net/tulip/de4x5.c, but you're not using that.
> > > > 
> > > > Beats me, sorry.  Perhaps it's due to changes in networking core.  It's
> > > > presumably a showstopper for statically-linked-uli526x users.  If you could
> > > > bisect it, please?  I'd start with git-netdev-all, then tulip-*.
> > > 
> > > OK, but it'll take some time.
> > 
> > OK, done.
> > 
> > It's one of these (the first one alone doesn't compile):
> > 
> > git-netdev-all.patch
> > git-netdev-all-fixup.patch
> > libphy-dont-do-that.patch
> 
> Are you able to eliminate libphy-dont-do-that.patch?
> 
> > Is a broken-out version of git-netdev-all.patch available from somewhere?
> 
> Nope, and my few fumbling attempts to generate the sort of patch series
> which you want didn't work out too well.  One has to downgrade to
> git-bisect :(
> 
> What does "doesn't work" mean, btw?

Well, it turns out not to be 100% reproducible.  I can only reproduce it after
a soft reboot (eg. shutdown -r now).

Then, while configuring network interfaces the system says the interface name
is ethxx0, but it should be eth1 (eth0 is an RTL-8139, which is not used).  Now
if I run ifconfig, it says:

eth0: error fetching interface information: Device not found

and that's all (normally, ifconfig would show the information for lo and eth1,
without eth0).  Moreover, 'ifconfig eth1' says:

eth1: error fetching interface information: Device not found

Next, I run 'rmmod uli526x' and 'modprobe uli526x' and then 'ifconfig' is
still saying the above (about eth0), but 'ifconfig eth1' seems to work as
it should.  However, the interface often fails to transfer anything after
that.

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

Re: 2.6.19-rc6-mm2: uli526x only works after reload

[Andrew Morton]

On Thu, 30 Nov 2006 02:04:15 +0100
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> > > 
> > > git-netdev-all.patch
> > > git-netdev-all-fixup.patch
> > > libphy-dont-do-that.patch
> > 
> > Are you able to eliminate libphy-dont-do-that.patch?
> > 
> > > Is a broken-out version of git-netdev-all.patch available from somewhere?
> > 
> > Nope, and my few fumbling attempts to generate the sort of patch series
> > which you want didn't work out too well.  One has to downgrade to
> > git-bisect :(
> > 
> > What does "doesn't work" mean, btw?
> 
> Well, it turns out not to be 100% reproducible.  I can only reproduce it after
> a soft reboot (eg. shutdown -r now).
> 
> Then, while configuring network interfaces the system says the interface name
> is ethxx0, but it should be eth1 (eth0 is an RTL-8139, which is not used).  Now
> if I run ifconfig, it says:
> 
> eth0: error fetching interface information: Device not found
> 
> and that's all (normally, ifconfig would show the information for lo and eth1,
> without eth0).  Moreover, 'ifconfig eth1' says:
> 
> eth1: error fetching interface information: Device not found
> 
> Next, I run 'rmmod uli526x' and 'modprobe uli526x' and then 'ifconfig' is
> still saying the above (about eth0), but 'ifconfig eth1' seems to work as
> it should.  However, the interface often fails to transfer anything after
> that.

Lovely.  Sounds like some startup race, perhaps against userspace.

Is CONFIG_PCI_MULTITHREAD_PROBE set?  (err, we meant to disable that for
2.6.19 but forgot).

Re: 2.6.19-rc6-mm2: uli526x only works after reload

[Rafael J. Wysocki]

On Thursday, 30 November 2006 02:04, Rafael J. Wysocki wrote:
> On Thursday, 30 November 2006 00:26, Andrew Morton wrote:
> > On Thu, 30 Nov 2006 00:08:21 +0100
> > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > 
> > > On Wednesday, 29 November 2006 22:31, Rafael J. Wysocki wrote:
> > > > On Wednesday, 29 November 2006 22:30, Andrew Morton wrote:
> > > > > On Wed, 29 Nov 2006 21:08:00 +0100
> > > > > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > > > > 
> > > > > > On Wednesday, 29 November 2006 20:54, Rafael J. Wysocki wrote:
> > > > > > > On Tuesday, 28 November 2006 11:02, Andrew Morton wrote:
> > > > > > > > 
> > > > > > > > Temporarily at
> > > > > > > > 
> > > > > > > > http://userweb.kernel.org/~akpm/2.6.19-rc6-mm2/
> > > > > > > > 
> > > > > > > > Will appear eventually at
> > > > > > > > 
> > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/
> > > > > > > 
> > > > > > > A minor issue: on one of my (x86-64) test boxes the uli526x driver doesn't
> > > > > > > work when it's first loaded.  I have to rmmod and modprobe it to make it work.
> > > > > 
> > > > > That isn't a minor issue.
> > > > > 
> > > > > > > It worked just fine on -mm1, so something must have happened to it recently.
> > > > > > 
> > > > > > Sorry, I was wrong.  The driver doesn't work at all, even after reload.
> > > > > > 
> > > > > 
> > > > > tulip-dmfe-carrier-detection-fix.patch was added in rc6-mm2.  But you're
> > > > > not using that (corrent?)
> > > > > 
> > > > > git-netdev-all changes drivers/net/tulip/de2104x.c, but you're not using
> > > > > that either.
> > > > > 
> > > > > git-powerpc(!) alters drivers/net/tulip/de4x5.c, but you're not using that.
> > > > > 
> > > > > Beats me, sorry.  Perhaps it's due to changes in networking core.  It's
> > > > > presumably a showstopper for statically-linked-uli526x users.  If you could
> > > > > bisect it, please?  I'd start with git-netdev-all, then tulip-*.
> > > > 
> > > > OK, but it'll take some time.
> > > 
> > > OK, done.
> > > 
> > > It's one of these (the first one alone doesn't compile):
> > > 
> > > git-netdev-all.patch
> > > git-netdev-all-fixup.patch
> > > libphy-dont-do-that.patch

Hm, all of these patches are the same as in -mm1 which hasn't caused any
problems to appear on this box.

So, it seems there's another change between -mm1 and -mm2 that causes this
to happen.

Greetings,
Rafael

Re: 2.6.19-rc6-mm2: uli526x only works after reload

[Andrew Morton]

On Thu, 30 Nov 2006 21:21:27 +0100
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> On Thursday, 30 November 2006 02:04, Rafael J. Wysocki wrote:
> > On Thursday, 30 November 2006 00:26, Andrew Morton wrote:
> > > On Thu, 30 Nov 2006 00:08:21 +0100
> > > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > > 
> > > > On Wednesday, 29 November 2006 22:31, Rafael J. Wysocki wrote:
> > > > > On Wednesday, 29 November 2006 22:30, Andrew Morton wrote:
> > > > > > On Wed, 29 Nov 2006 21:08:00 +0100
> > > > > > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > > > > > 
> > > > > > > On Wednesday, 29 November 2006 20:54, Rafael J. Wysocki wrote:
> > > > > > > > On Tuesday, 28 November 2006 11:02, Andrew Morton wrote:
> > > > > > > > > 
> > > > > > > > > Temporarily at
> > > > > > > > > 
> > > > > > > > > http://userweb.kernel.org/~akpm/2.6.19-rc6-mm2/
> > > > > > > > > 
> > > > > > > > > Will appear eventually at
> > > > > > > > > 
> > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/
> > > > > > > > 
> > > > > > > > A minor issue: on one of my (x86-64) test boxes the uli526x driver doesn't
> > > > > > > > work when it's first loaded.  I have to rmmod and modprobe it to make it work.
> > > > > > 
> > > > > > That isn't a minor issue.
> > > > > > 
> > > > > > > > It worked just fine on -mm1, so something must have happened to it recently.
> > > > > > > 
> > > > > > > Sorry, I was wrong.  The driver doesn't work at all, even after reload.
> > > > > > > 
> > > > > > 
> > > > > > tulip-dmfe-carrier-detection-fix.patch was added in rc6-mm2.  But you're
> > > > > > not using that (corrent?)
> > > > > > 
> > > > > > git-netdev-all changes drivers/net/tulip/de2104x.c, but you're not using
> > > > > > that either.
> > > > > > 
> > > > > > git-powerpc(!) alters drivers/net/tulip/de4x5.c, but you're not using that.
> > > > > > 
> > > > > > Beats me, sorry.  Perhaps it's due to changes in networking core.  It's
> > > > > > presumably a showstopper for statically-linked-uli526x users.  If you could
> > > > > > bisect it, please?  I'd start with git-netdev-all, then tulip-*.
> > > > > 
> > > > > OK, but it'll take some time.
> > > > 
> > > > OK, done.
> > > > 
> > > > It's one of these (the first one alone doesn't compile):
> > > > 
> > > > git-netdev-all.patch
> > > > git-netdev-all-fixup.patch
> > > > libphy-dont-do-that.patch
> 
> Hm, all of these patches are the same as in -mm1 which hasn't caused any
> problems to appear on this box.
> 
> So, it seems there's another change between -mm1 and -mm2 that causes this
> to happen.
> 

It would be nice to eliminate libphy-dont-do-that.patch if poss - that was
a rogue akpm patch aimed at some incomprehensible gobbledigook in the
netdev tree (and to fix the current_is_keventd-not-exported-to-modules
bug).

I have a feeling that your bug will be cheerily merged into mainline soon. 
That might of course mean that someone will hit it more firmly and it'll
get fixed.

Re: 2.6.19-rc6-mm2: uli526x only works after reload

[Rafael J. Wysocki]

[Trimmed the Cc list a bit.]

On Thursday, 30 November 2006 22:12, Andrew Morton wrote:
> On Thu, 30 Nov 2006 21:21:27 +0100
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
> > On Thursday, 30 November 2006 02:04, Rafael J. Wysocki wrote:
> > > On Thursday, 30 November 2006 00:26, Andrew Morton wrote:
> > > > On Thu, 30 Nov 2006 00:08:21 +0100
> > > > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > > > 
> > > > > On Wednesday, 29 November 2006 22:31, Rafael J. Wysocki wrote:
> > > > > > On Wednesday, 29 November 2006 22:30, Andrew Morton wrote:
> > > > > > > On Wed, 29 Nov 2006 21:08:00 +0100
> > > > > > > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > > > > > > 
> > > > > > > > On Wednesday, 29 November 2006 20:54, Rafael J. Wysocki wrote:
> > > > > > > > > On Tuesday, 28 November 2006 11:02, Andrew Morton wrote:
> > > > > > > > > > 
> > > > > > > > > > Temporarily at
> > > > > > > > > > 
> > > > > > > > > > http://userweb.kernel.org/~akpm/2.6.19-rc6-mm2/
> > > > > > > > > > 
> > > > > > > > > > Will appear eventually at
> > > > > > > > > > 
> > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/
> > > > > > > > > 
> > > > > > > > > A minor issue: on one of my (x86-64) test boxes the uli526x driver doesn't
> > > > > > > > > work when it's first loaded.  I have to rmmod and modprobe it to make it work.
> > > > > > > 
> > > > > > > That isn't a minor issue.
> > > > > > > 
> > > > > > > > > It worked just fine on -mm1, so something must have happened to it recently.
> > > > > > > > 
> > > > > > > > Sorry, I was wrong.  The driver doesn't work at all, even after reload.
> > > > > > > > 
> > > > > > > 
> > > > > > > tulip-dmfe-carrier-detection-fix.patch was added in rc6-mm2.  But you're
> > > > > > > not using that (corrent?)
> > > > > > > 
> > > > > > > git-netdev-all changes drivers/net/tulip/de2104x.c, but you're not using
> > > > > > > that either.
> > > > > > > 
> > > > > > > git-powerpc(!) alters drivers/net/tulip/de4x5.c, but you're not using that.
> > > > > > > 
> > > > > > > Beats me, sorry.  Perhaps it's due to changes in networking core.  It's
> > > > > > > presumably a showstopper for statically-linked-uli526x users.  If you could
> > > > > > > bisect it, please?  I'd start with git-netdev-all, then tulip-*.
> > > > > > 
> > > > > > OK, but it'll take some time.
> > > > > 
> > > > > OK, done.
> > > > > 
> > > > > It's one of these (the first one alone doesn't compile):
> > > > > 
> > > > > git-netdev-all.patch
> > > > > git-netdev-all-fixup.patch
> > > > > libphy-dont-do-that.patch
> > 
> > Hm, all of these patches are the same as in -mm1 which hasn't caused any
> > problems to appear on this box.
> > 
> > So, it seems there's another change between -mm1 and -mm2 that causes this
> > to happen.
> > 
> 
> It would be nice to eliminate libphy-dont-do-that.patch if poss - that was
> a rogue akpm patch aimed at some incomprehensible gobbledigook in the
> netdev tree (and to fix the current_is_keventd-not-exported-to-modules
> bug).

Unfortunately the kernel doesn't compile without it ...

Well, I think I'll try to find the patch that contains the change which has
triggered this.

Now it looks like the problem is 100% reproducible after a fresh poweron as
long as I don't run a non-failing kernel on the box.  [Symptoms tend to vary,
though.  Sometimes the reloading of uli526x doesn't help at all, sometimes
it makes the interface appear but without the possibility to transmit data,
and sometimes it makes the interface work.]

> I have a feeling that your bug will be cheerily merged into mainline soon. 
> That might of course mean that someone will hit it more firmly and it'll
> get fixed.

Yes, that's possible.

Re: 2.6.19-rc6-mm2: uli526x only works after reload

[Rafael J. Wysocki]

On Thursday, 30 November 2006 22:32, Rafael J. Wysocki wrote:
> [Trimmed the Cc list a bit.]
> 
> On Thursday, 30 November 2006 22:12, Andrew Morton wrote:
> > On Thu, 30 Nov 2006 21:21:27 +0100
> > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > 
> > > On Thursday, 30 November 2006 02:04, Rafael J. Wysocki wrote:
> > > > On Thursday, 30 November 2006 00:26, Andrew Morton wrote:
> > > > > On Thu, 30 Nov 2006 00:08:21 +0100
> > > > > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > > > > 
> > > > > > On Wednesday, 29 November 2006 22:31, Rafael J. Wysocki wrote:
> > > > > > > On Wednesday, 29 November 2006 22:30, Andrew Morton wrote:
> > > > > > > > On Wed, 29 Nov 2006 21:08:00 +0100
> > > > > > > > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > > > > > > > 
> > > > > > > > > On Wednesday, 29 November 2006 20:54, Rafael J. Wysocki wrote:
> > > > > > > > > > On Tuesday, 28 November 2006 11:02, Andrew Morton wrote:
> > > > > > > > > > > 
> > > > > > > > > > > Temporarily at
> > > > > > > > > > > 
> > > > > > > > > > > http://userweb.kernel.org/~akpm/2.6.19-rc6-mm2/
> > > > > > > > > > > 
> > > > > > > > > > > Will appear eventually at
> > > > > > > > > > > 
> > > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/
> > > > > > > > > > 
> > > > > > > > > > A minor issue: on one of my (x86-64) test boxes the uli526x driver doesn't
> > > > > > > > > > work when it's first loaded.  I have to rmmod and modprobe it to make it work.
> > > > > > > > 
> > > > > > > > That isn't a minor issue.
> > > > > > > > 
> > > > > > > > > > It worked just fine on -mm1, so something must have happened to it recently.
> > > > > > > > > 
> > > > > > > > > Sorry, I was wrong.  The driver doesn't work at all, even after reload.
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > tulip-dmfe-carrier-detection-fix.patch was added in rc6-mm2.  But you're
> > > > > > > > not using that (corrent?)
> > > > > > > > 
> > > > > > > > git-netdev-all changes drivers/net/tulip/de2104x.c, but you're not using
> > > > > > > > that either.
> > > > > > > > 
> > > > > > > > git-powerpc(!) alters drivers/net/tulip/de4x5.c, but you're not using that.
> > > > > > > > 
> > > > > > > > Beats me, sorry.  Perhaps it's due to changes in networking core.  It's
> > > > > > > > presumably a showstopper for statically-linked-uli526x users.  If you could
> > > > > > > > bisect it, please?  I'd start with git-netdev-all, then tulip-*.
> > > > > > > 
> > > > > > > OK, but it'll take some time.
> > > > > > 
> > > > > > OK, done.
> > > > > > 
> > > > > > It's one of these (the first one alone doesn't compile):
> > > > > > 
> > > > > > git-netdev-all.patch
> > > > > > git-netdev-all-fixup.patch
> > > > > > libphy-dont-do-that.patch
> > > 
> > > Hm, all of these patches are the same as in -mm1 which hasn't caused any
> > > problems to appear on this box.
> > > 
> > > So, it seems there's another change between -mm1 and -mm2 that causes this
> > > to happen.
> > > 
> > 
> > It would be nice to eliminate libphy-dont-do-that.patch if poss - that was
> > a rogue akpm patch aimed at some incomprehensible gobbledigook in the
> > netdev tree (and to fix the current_is_keventd-not-exported-to-modules
> > bug).
> 
> Unfortunately the kernel doesn't compile without it ...
> 
> Well, I think I'll try to find the patch that contains the change which has
> triggered this.

It looks like the winner is:

gregkh-driver-driver-core-fixes-sysfs_create_link-retval-checks-in-core.c.patch

Without this patch there are no problems, with this patch applied the problems
(with uli526x, when it's the second interface and the first one is not used)
occur, almost 100% of the time.

Re: 2.6.19-rc6-mm2: uli526x only works after reload

[Greg KH]

On Wed, Nov 29, 2006 at 06:18:09PM -0800, Andrew Morton wrote:
> On Thu, 30 Nov 2006 02:04:15 +0100
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
> > > > 
> > > > git-netdev-all.patch
> > > > git-netdev-all-fixup.patch
> > > > libphy-dont-do-that.patch
> > > 
> > > Are you able to eliminate libphy-dont-do-that.patch?
> > > 
> > > > Is a broken-out version of git-netdev-all.patch available from somewhere?
> > > 
> > > Nope, and my few fumbling attempts to generate the sort of patch series
> > > which you want didn't work out too well.  One has to downgrade to
> > > git-bisect :(
> > > 
> > > What does "doesn't work" mean, btw?
> > 
> > Well, it turns out not to be 100% reproducible.  I can only reproduce it after
> > a soft reboot (eg. shutdown -r now).
> > 
> > Then, while configuring network interfaces the system says the interface name
> > is ethxx0, but it should be eth1 (eth0 is an RTL-8139, which is not used).  Now
> > if I run ifconfig, it says:
> > 
> > eth0: error fetching interface information: Device not found
> > 
> > and that's all (normally, ifconfig would show the information for lo and eth1,
> > without eth0).  Moreover, 'ifconfig eth1' says:
> > 
> > eth1: error fetching interface information: Device not found
> > 
> > Next, I run 'rmmod uli526x' and 'modprobe uli526x' and then 'ifconfig' is
> > still saying the above (about eth0), but 'ifconfig eth1' seems to work as
> > it should.  However, the interface often fails to transfer anything after
> > that.
> 
> Lovely.  Sounds like some startup race, perhaps against userspace.
> 
> Is CONFIG_PCI_MULTITHREAD_PROBE set?  (err, we meant to disable that for
> 2.6.19 but forgot).

No, I disabled it for 2.6.19, -mm turns it back on :)

thanks,

greg k-h

Re: 2.6.19-rc6-mm2: uli526x only works after reload

[Greg KH]

On Fri, Dec 01, 2006 at 02:08:28AM +0100, Rafael J. Wysocki wrote:
> On Thursday, 30 November 2006 22:32, Rafael J. Wysocki wrote:
> > [Trimmed the Cc list a bit.]
> > 
> > On Thursday, 30 November 2006 22:12, Andrew Morton wrote:
> > > On Thu, 30 Nov 2006 21:21:27 +0100
> > > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > > 
> > > > On Thursday, 30 November 2006 02:04, Rafael J. Wysocki wrote:
> > > > > On Thursday, 30 November 2006 00:26, Andrew Morton wrote:
> > > > > > On Thu, 30 Nov 2006 00:08:21 +0100
> > > > > > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > > > > > 
> > > > > > > On Wednesday, 29 November 2006 22:31, Rafael J. Wysocki wrote:
> > > > > > > > On Wednesday, 29 November 2006 22:30, Andrew Morton wrote:
> > > > > > > > > On Wed, 29 Nov 2006 21:08:00 +0100
> > > > > > > > > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > > > > > > > > 
> > > > > > > > > > On Wednesday, 29 November 2006 20:54, Rafael J. Wysocki wrote:
> > > > > > > > > > > On Tuesday, 28 November 2006 11:02, Andrew Morton wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > Temporarily at
> > > > > > > > > > > > 
> > > > > > > > > > > > http://userweb.kernel.org/~akpm/2.6.19-rc6-mm2/
> > > > > > > > > > > > 
> > > > > > > > > > > > Will appear eventually at
> > > > > > > > > > > > 
> > > > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/
> > > > > > > > > > > 
> > > > > > > > > > > A minor issue: on one of my (x86-64) test boxes the uli526x driver doesn't
> > > > > > > > > > > work when it's first loaded.  I have to rmmod and modprobe it to make it work.
> > > > > > > > > 
> > > > > > > > > That isn't a minor issue.
> > > > > > > > > 
> > > > > > > > > > > It worked just fine on -mm1, so something must have happened to it recently.
> > > > > > > > > > 
> > > > > > > > > > Sorry, I was wrong.  The driver doesn't work at all, even after reload.
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > tulip-dmfe-carrier-detection-fix.patch was added in rc6-mm2.  But you're
> > > > > > > > > not using that (corrent?)
> > > > > > > > > 
> > > > > > > > > git-netdev-all changes drivers/net/tulip/de2104x.c, but you're not using
> > > > > > > > > that either.
> > > > > > > > > 
> > > > > > > > > git-powerpc(!) alters drivers/net/tulip/de4x5.c, but you're not using that.
> > > > > > > > > 
> > > > > > > > > Beats me, sorry.  Perhaps it's due to changes in networking core.  It's
> > > > > > > > > presumably a showstopper for statically-linked-uli526x users.  If you could
> > > > > > > > > bisect it, please?  I'd start with git-netdev-all, then tulip-*.
> > > > > > > > 
> > > > > > > > OK, but it'll take some time.
> > > > > > > 
> > > > > > > OK, done.
> > > > > > > 
> > > > > > > It's one of these (the first one alone doesn't compile):
> > > > > > > 
> > > > > > > git-netdev-all.patch
> > > > > > > git-netdev-all-fixup.patch
> > > > > > > libphy-dont-do-that.patch
> > > > 
> > > > Hm, all of these patches are the same as in -mm1 which hasn't caused any
> > > > problems to appear on this box.
> > > > 
> > > > So, it seems there's another change between -mm1 and -mm2 that causes this
> > > > to happen.
> > > > 
> > > 
> > > It would be nice to eliminate libphy-dont-do-that.patch if poss - that was
> > > a rogue akpm patch aimed at some incomprehensible gobbledigook in the
> > > netdev tree (and to fix the current_is_keventd-not-exported-to-modules
> > > bug).
> > 
> > Unfortunately the kernel doesn't compile without it ...
> > 
> > Well, I think I'll try to find the patch that contains the change which has
> > triggered this.
> 
> It looks like the winner is:
> 
> gregkh-driver-driver-core-fixes-sysfs_create_link-retval-checks-in-core.c.patch
> 
> Without this patch there are no problems, with this patch applied the problems
> (with uli526x, when it's the second interface and the first one is not used)
> occur, almost 100% of the time.

Hm, that's odd.  Let me look at this closer and see if we are somehow
now failing something that previously we were not (this has happened
before...)

Cornelia, this is your patch, can you see anything obvious that would
cause this issue?

thanks,

greg k-h

Re: 2.6.19-rc6-mm2: uli526x only works after reload

[Rafael J. Wysocki]

On Friday, 1 December 2006 02:20, Greg KH wrote:
> On Wed, Nov 29, 2006 at 06:18:09PM -0800, Andrew Morton wrote:
> > On Thu, 30 Nov 2006 02:04:15 +0100
> > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > 
> > > > > 
> > > > > git-netdev-all.patch
> > > > > git-netdev-all-fixup.patch
> > > > > libphy-dont-do-that.patch
> > > > 
> > > > Are you able to eliminate libphy-dont-do-that.patch?
> > > > 
> > > > > Is a broken-out version of git-netdev-all.patch available from somewhere?
> > > > 
> > > > Nope, and my few fumbling attempts to generate the sort of patch series
> > > > which you want didn't work out too well.  One has to downgrade to
> > > > git-bisect :(
> > > > 
> > > > What does "doesn't work" mean, btw?
> > > 
> > > Well, it turns out not to be 100% reproducible.  I can only reproduce it after
> > > a soft reboot (eg. shutdown -r now).
> > > 
> > > Then, while configuring network interfaces the system says the interface name
> > > is ethxx0, but it should be eth1 (eth0 is an RTL-8139, which is not used).  Now
> > > if I run ifconfig, it says:
> > > 
> > > eth0: error fetching interface information: Device not found
> > > 
> > > and that's all (normally, ifconfig would show the information for lo and eth1,
> > > without eth0).  Moreover, 'ifconfig eth1' says:
> > > 
> > > eth1: error fetching interface information: Device not found
> > > 
> > > Next, I run 'rmmod uli526x' and 'modprobe uli526x' and then 'ifconfig' is
> > > still saying the above (about eth0), but 'ifconfig eth1' seems to work as
> > > it should.  However, the interface often fails to transfer anything after
> > > that.
> > 
> > Lovely.  Sounds like some startup race, perhaps against userspace.
> > 
> > Is CONFIG_PCI_MULTITHREAD_PROBE set?  (err, we meant to disable that for
> > 2.6.19 but forgot).
> 
> No, I disabled it for 2.6.19, -mm turns it back on :)

But it's not set in my .config.

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

[-mm patch] drivers/net/netxen/: possible cleanups

[Adrian Bunk]

On Tue, Nov 28, 2006 at 02:02:46AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-rc6-mm1:
>...
>  git-netdev-all.patch
>...
>  git trees
>...

This patch contains the following possible cleanups:
- make needlessly global code static
- #if 0 the following unused global functions:
  - netxen_nic_hw.c: netxen_crb_read_val()
  - netxen_nic_niu.c: netxen_niu_xgbe_clear_phy_interrupts()
  - netxen_nic_niu.c: netxen_niu_gbe_handle_phy_interrupt()
  - netxen_nic_niu.c: netxen_niu_macaddr_get()
  - netxen_nic_niu.c: netxen_niu_enable_gbe_port()
  - netxen_nic_niu.c: netxen_niu_xg_macaddr_get()

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 drivers/net/netxen/netxen_nic.h      |   13 -------------
 drivers/net/netxen/netxen_nic_hw.c   |   13 +++++++------
 drivers/net/netxen/netxen_nic_hw.h   |    8 ++------
 drivers/net/netxen/netxen_nic_init.c |   21 +++++++++------------
 drivers/net/netxen/netxen_nic_isr.c  |   10 +++++-----
 drivers/net/netxen/netxen_nic_niu.c  |   22 ++++++++++++++++------
 6 files changed, 39 insertions(+), 48 deletions(-)

--- linux-2.6.19-rc6-mm2/drivers/net/netxen/netxen_nic_hw.c.old	2006-12-02 20:43:26.000000000 +0100
+++ linux-2.6.19-rc6-mm2/drivers/net/netxen/netxen_nic_hw.c	2006-12-02 20:45:07.000000000 +0100
@@ -51,9 +51,8 @@
 #define NETXEN_NIU_HDRSIZE	(0x1 << 6)
 #define NETXEN_NIU_TLRSIZE	(0x1 << 5)
 
-unsigned long netxen_nic_pci_set_window(void __iomem * pci_base,
-					unsigned long long addr);
-void netxen_free_hw_resources(struct netxen_adapter *adapter);
+static unsigned long netxen_nic_pci_set_window(void __iomem * pci_base,
+					       unsigned long long addr);
 
 int netxen_nic_set_mac(struct net_device *netdev, void *p)
 {
@@ -646,10 +645,10 @@
 	netxen_nic_pci_change_crbwindow(adapter, 1);
 }
 
-int netxen_pci_set_window_warning_count = 0;
+static int netxen_pci_set_window_warning_count = 0;
 
-unsigned long
-netxen_nic_pci_set_window(void __iomem * pci_base, unsigned long long addr)
+static unsigned long netxen_nic_pci_set_window(void __iomem * pci_base,
+					       unsigned long long addr)
 {
 	static int ddr_mn_window = -1;
 	static int qdr_sn_window = -1;
@@ -928,9 +927,11 @@
 		       fw_major, fw_minor);
 }
 
+#if 0
 int netxen_crb_read_val(struct netxen_adapter *adapter, unsigned long off)
 {
 	int data;
 	netxen_nic_hw_read_wx(adapter, off, &data, 4);
 	return data;
 }
+#endif  /*  0  */
--- linux-2.6.19-rc6-mm2/drivers/net/netxen/netxen_nic_init.c.old	2006-12-02 20:45:27.000000000 +0100
+++ linux-2.6.19-rc6-mm2/drivers/net/netxen/netxen_nic_init.c	2006-12-02 20:47:44.000000000 +0100
@@ -239,7 +239,7 @@
  * netxen_decode_crb_addr(0 - utility to translate from internal Phantom CRB
  * address to external PCI CRB address.
  */
-unsigned long netxen_decode_crb_addr(unsigned long addr)
+static unsigned long netxen_decode_crb_addr(unsigned long addr)
 {
 	int i;
 	unsigned long base_addr, offset, pci_base;
@@ -304,7 +304,7 @@
 
 }
 
-int netxen_wait_rom_done(struct netxen_adapter *adapter)
+static int netxen_wait_rom_done(struct netxen_adapter *adapter)
 {
 	long timeout = 0;
 	long done = 0;
@@ -582,9 +582,8 @@
  * and if the number of receives exceeds RX_BUFFERS_REFILL, then we
  * invoke the routine to send more rx buffers to the Phantom...
  */
-void
-netxen_process_rcv(struct netxen_adapter *adapter, int ctxid,
-		   struct status_desc *desc)
+static void netxen_process_rcv(struct netxen_adapter *adapter, int ctxid,
+			       struct status_desc *desc)
 {
 	struct netxen_port *port = adapter->port[STATUS_DESC_PORT(desc)];
 	struct pci_dev *pdev = port->pdev;
@@ -919,10 +918,9 @@
 	return 0;
 }
 
-int
-netxen_nic_fill_statistics(struct netxen_adapter *adapter,
-			   struct netxen_port *port,
-			   struct netxen_statistics *netxen_stats)
+static int netxen_nic_fill_statistics(struct netxen_adapter *adapter,
+				      struct netxen_port *port,
+				      struct netxen_statistics *netxen_stats)
 {
 	void __iomem *addr;
 
@@ -978,9 +976,8 @@
 	}
 }
 
-int
-netxen_nic_clear_statistics(struct netxen_adapter *adapter,
-			    struct netxen_port *port)
+static int netxen_nic_clear_statistics(struct netxen_adapter *adapter,
+				       struct netxen_port *port)
 {
 	int data = 0;
 
--- linux-2.6.19-rc6-mm2/drivers/net/netxen/netxen_nic.h.old	2006-12-02 20:48:02.000000000 +0100
+++ linux-2.6.19-rc6-mm2/drivers/net/netxen/netxen_nic.h	2006-12-02 20:54:30.000000000 +0100
@@ -793,16 +793,8 @@
 					   int port);
 int netxen_niu_gbe_disable_phy_interrupts(struct netxen_adapter *adapter,
 					  int port);
-int netxen_niu_xgbe_clear_phy_interrupts(struct netxen_adapter *adapter,
-					 int port);
-int netxen_niu_gbe_clear_phy_interrupts(struct netxen_adapter *adapter,
-					int port);
 void netxen_nic_xgbe_handle_phy_intr(struct netxen_adapter *adapter);
 void netxen_nic_gbe_handle_phy_intr(struct netxen_adapter *adapter);
-void netxen_niu_gbe_set_mii_mode(struct netxen_adapter *adapter, int port,
-				 long enable);
-void netxen_niu_gbe_set_gmii_mode(struct netxen_adapter *adapter, int port,
-				  long enable);
 int netxen_niu_gbe_phy_read(struct netxen_adapter *adapter, long phy, long reg,
 			    __le32 * readval);
 int netxen_niu_gbe_phy_write(struct netxen_adapter *adapter, long phy,
@@ -834,11 +826,6 @@
 int netxen_rom_fast_read(struct netxen_adapter *adapter, int addr, int *valp);
 
 /* Functions from netxen_nic_isr.c */
-void netxen_nic_isr_other(struct netxen_adapter *adapter);
-void netxen_indicate_link_status(struct netxen_adapter *adapter, u32 port,
-				 u32 link);
-void netxen_handle_port_int(struct netxen_adapter *adapter, u32 port,
-			    u32 enable);
 void netxen_nic_stop_all_ports(struct netxen_adapter *adapter);
 void netxen_initialize_adapter_sw(struct netxen_adapter *adapter);
 void netxen_initialize_adapter_hw(struct netxen_adapter *adapter);
--- linux-2.6.19-rc6-mm2/drivers/net/netxen/netxen_nic_isr.c.old	2006-12-02 20:48:15.000000000 +0100
+++ linux-2.6.19-rc6-mm2/drivers/net/netxen/netxen_nic_isr.c	2006-12-02 20:49:36.000000000 +0100
@@ -65,8 +65,8 @@
 	return stats;
 }
 
-void netxen_indicate_link_status(struct netxen_adapter *adapter, u32 portno,
-				 u32 link)
+static void netxen_indicate_link_status(struct netxen_adapter *adapter,
+					u32 portno, u32 link)
 {
 	struct netxen_port *pport = adapter->port[portno];
 	struct net_device *netdev = pport->netdev;
@@ -77,8 +77,8 @@
 		netif_carrier_off(netdev);
 }
 
-void netxen_handle_port_int(struct netxen_adapter *adapter, u32 portno,
-			    u32 enable)
+static void netxen_handle_port_int(struct netxen_adapter *adapter, u32 portno,
+				   u32 enable)
 {
 	__le32 int_src;
 	struct netxen_port *port;
@@ -147,7 +147,7 @@
 		adapter->ops->enable_phy_interrupts(adapter, portno);
 }
 
-void netxen_nic_isr_other(struct netxen_adapter *adapter)
+static void netxen_nic_isr_other(struct netxen_adapter *adapter)
 {
 	u32 enable, portno;
 	u32 i2qhi;
--- linux-2.6.19-rc6-mm2/drivers/net/netxen/netxen_nic_hw.h.old	2006-12-02 20:52:48.000000000 +0100
+++ linux-2.6.19-rc6-mm2/drivers/net/netxen/netxen_nic_hw.h	2006-12-02 20:53:51.000000000 +0100
@@ -457,15 +457,11 @@
 int netxen_niu_xg_set_promiscuous_mode(struct netxen_adapter *adapter,
 				       int port, netxen_niu_prom_mode_t mode);
 
-/* get/set the MAC address for a given MAC */
-int netxen_niu_macaddr_get(struct netxen_adapter *adapter, int port,
-			   netxen_ethernet_macaddr_t * addr);
+/* set the MAC address for a given MAC */
 int netxen_niu_macaddr_set(struct netxen_port *port,
 			   netxen_ethernet_macaddr_t addr);
 
-/* XG versons */
-int netxen_niu_xg_macaddr_get(struct netxen_adapter *adapter, int port,
-			      netxen_ethernet_macaddr_t * addr);
+/* XG verson */
 int netxen_niu_xg_macaddr_set(struct netxen_port *port,
 			      netxen_ethernet_macaddr_t addr);
 
--- linux-2.6.19-rc6-mm2/drivers/net/netxen/netxen_nic_niu.c.old	2006-12-02 20:49:50.000000000 +0100
+++ linux-2.6.19-rc6-mm2/drivers/net/netxen/netxen_nic_niu.c	2006-12-02 20:54:43.000000000 +0100
@@ -262,15 +262,17 @@
 	return result;
 }
 
+#if 0
 int netxen_niu_xgbe_clear_phy_interrupts(struct netxen_adapter *adapter,
 					 int port)
 {
 	netxen_crb_writelit_adapter(adapter, NETXEN_NIU_ACTIVE_INT, -1);
 	return 0;
 }
+#endif  /*  0  */
 
-int netxen_niu_gbe_clear_phy_interrupts(struct netxen_adapter *adapter,
-					int port)
+static int netxen_niu_gbe_clear_phy_interrupts(struct netxen_adapter *adapter,
+					       int port)
 {
 	int result = 0;
 	if (0 !=
@@ -286,8 +288,8 @@
  * netxen_niu_gbe_set_mii_mode- Set 10/100 Mbit Mode for GbE MAC
  *
  */
-void netxen_niu_gbe_set_mii_mode(struct netxen_adapter *adapter,
-				 int port, long enable)
+static void netxen_niu_gbe_set_mii_mode(struct netxen_adapter *adapter,
+					int port, long enable)
 {
 	netxen_crb_writelit_adapter(adapter, NETXEN_NIU_MODE, 0x2);
 	netxen_crb_writelit_adapter(adapter, NETXEN_NIU_GB_MAC_CONFIG_0(port),
@@ -324,8 +326,8 @@
 /* 
  * netxen_niu_gbe_set_gmii_mode- Set GbE Mode for GbE MAC
  */
-void netxen_niu_gbe_set_gmii_mode(struct netxen_adapter *adapter,
-				  int port, long enable)
+static void netxen_niu_gbe_set_gmii_mode(struct netxen_adapter *adapter,
+					 int port, long enable)
 {
 	netxen_crb_writelit_adapter(adapter, NETXEN_NIU_MODE, 0x2);
 	netxen_crb_writelit_adapter(adapter, NETXEN_NIU_GB_MAC_CONFIG_0(port),
@@ -407,6 +409,8 @@
 	return result;
 }
 
+#if 0
+
 /* 
  * netxen_niu_gbe_handle_phy_interrupt - Handles GbE PHY interrupts
  * @param enable 0 means don't enable the port
@@ -530,6 +534,8 @@
 	return 0;
 }
 
+#endif  /*  0  */
+
 /*
  * Set the station MAC address.
  * Note that the passed-in value must already be in network byte order.
@@ -557,6 +563,7 @@
 	return 0;
 }
 
+#if 0
 /* Enable a GbE interface */
 int netxen_niu_enable_gbe_port(struct netxen_adapter *adapter,
 			       int port, netxen_niu_gbe_ifmode_t mode)
@@ -634,6 +641,7 @@
 		return -EIO;
 	return 0;
 }
+#endif  /*  0  */
 
 /* Disable a GbE interface */
 int netxen_niu_disable_gbe_port(struct netxen_adapter *adapter, int port)
@@ -749,6 +757,7 @@
 	return 0;
 }
 
+#if 0
 /*
  * Return the current station MAC address.
  * Note that the passed-in value must already be in network byte order.
@@ -778,6 +787,7 @@
 
 	return 0;
 }
+#endif  /*  0  */
 
 int netxen_niu_xg_set_promiscuous_mode(struct netxen_adapter *adapter,
 				       int port, netxen_niu_prom_mode_t mode)

Re: 2.6.19-rc6-mm2: uli526x only works after reload

[Greg KH]

On Fri, Dec 01, 2006 at 02:08:28AM +0100, Rafael J. Wysocki wrote:
> On Thursday, 30 November 2006 22:32, Rafael J. Wysocki wrote:
> > [Trimmed the Cc list a bit.]
> > 
> > On Thursday, 30 November 2006 22:12, Andrew Morton wrote:
> > > On Thu, 30 Nov 2006 21:21:27 +0100
> > > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > > 
> > > > On Thursday, 30 November 2006 02:04, Rafael J. Wysocki wrote:
> > > > > On Thursday, 30 November 2006 00:26, Andrew Morton wrote:
> > > > > > On Thu, 30 Nov 2006 00:08:21 +0100
> > > > > > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > > > > > 
> > > > > > > On Wednesday, 29 November 2006 22:31, Rafael J. Wysocki wrote:
> > > > > > > > On Wednesday, 29 November 2006 22:30, Andrew Morton wrote:
> > > > > > > > > On Wed, 29 Nov 2006 21:08:00 +0100
> > > > > > > > > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > > > > > > > > 
> > > > > > > > > > On Wednesday, 29 November 2006 20:54, Rafael J. Wysocki wrote:
> > > > > > > > > > > On Tuesday, 28 November 2006 11:02, Andrew Morton wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > Temporarily at
> > > > > > > > > > > > 
> > > > > > > > > > > > http://userweb.kernel.org/~akpm/2.6.19-rc6-mm2/
> > > > > > > > > > > > 
> > > > > > > > > > > > Will appear eventually at
> > > > > > > > > > > > 
> > > > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/
> > > > > > > > > > > 
> > > > > > > > > > > A minor issue: on one of my (x86-64) test boxes the uli526x driver doesn't
> > > > > > > > > > > work when it's first loaded.  I have to rmmod and modprobe it to make it work.
> > > > > > > > > 
> > > > > > > > > That isn't a minor issue.
> > > > > > > > > 
> > > > > > > > > > > It worked just fine on -mm1, so something must have happened to it recently.
> > > > > > > > > > 
> > > > > > > > > > Sorry, I was wrong.  The driver doesn't work at all, even after reload.
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > tulip-dmfe-carrier-detection-fix.patch was added in rc6-mm2.  But you're
> > > > > > > > > not using that (corrent?)
> > > > > > > > > 
> > > > > > > > > git-netdev-all changes drivers/net/tulip/de2104x.c, but you're not using
> > > > > > > > > that either.
> > > > > > > > > 
> > > > > > > > > git-powerpc(!) alters drivers/net/tulip/de4x5.c, but you're not using that.
> > > > > > > > > 
> > > > > > > > > Beats me, sorry.  Perhaps it's due to changes in networking core.  It's
> > > > > > > > > presumably a showstopper for statically-linked-uli526x users.  If you could
> > > > > > > > > bisect it, please?  I'd start with git-netdev-all, then tulip-*.
> > > > > > > > 
> > > > > > > > OK, but it'll take some time.
> > > > > > > 
> > > > > > > OK, done.
> > > > > > > 
> > > > > > > It's one of these (the first one alone doesn't compile):
> > > > > > > 
> > > > > > > git-netdev-all.patch
> > > > > > > git-netdev-all-fixup.patch
> > > > > > > libphy-dont-do-that.patch
> > > > 
> > > > Hm, all of these patches are the same as in -mm1 which hasn't caused any
> > > > problems to appear on this box.
> > > > 
> > > > So, it seems there's another change between -mm1 and -mm2 that causes this
> > > > to happen.
> > > > 
> > > 
> > > It would be nice to eliminate libphy-dont-do-that.patch if poss - that was
> > > a rogue akpm patch aimed at some incomprehensible gobbledigook in the
> > > netdev tree (and to fix the current_is_keventd-not-exported-to-modules
> > > bug).
> > 
> > Unfortunately the kernel doesn't compile without it ...
> > 
> > Well, I think I'll try to find the patch that contains the change which has
> > triggered this.
> 
> It looks like the winner is:
> 
> gregkh-driver-driver-core-fixes-sysfs_create_link-retval-checks-in-core.c.patch
> 
> Without this patch there are no problems, with this patch applied the problems
> (with uli526x, when it's the second interface and the first one is not used)
> occur, almost 100% of the time.

Ok, I've now removed this from my tree.

thanks,

greg k-h