Recent wireless breakage (ipw2200, iwconfig, NetworkManager)

Recent kernels are having troubles with wireless for me. Two seemingly related problems:

a) NetworkManager seems oblivious to the existence of my IPW2200

b) Manual iwconfig waits for 60s and then reports:

A second attempt to enable WEP via iwconfig succeeds and network connectivity is normal. However, NetworkManager still ignores the device at this point.

Bisect with Mercurial points to this patch:

$ hg bisect bad
The first bad revision is:
changeset:   46985:f701b96bb2f7
user:        Greg Kroah-Hartman <[email protected]>
date:        Wed Feb 07 10:37:11 2007 -0800
summary:     Network: convert network devices to use struct device
instead of class_device

which corresponds to 43cb76d91ee85f579a69d42bc8efc08bac560278 in git.

[adding linux-wireless to CC]

Quoted 2 lines · Matt Mackall

Recent kernels are having troubles with wireless for me. Two seemingly related problems:

I don't think they are related actually.

Quoted 1 line

a) NetworkManager seems oblivious to the existence of my IPW2200

This is due to the recent sysfs restructuring I think. IIRC the fix is to upgrade hal to a current git version.

Quoted 1 line

b) Manual iwconfig waits for 60s and then reports:

That one's strange.

Quoted 3 lines

A second attempt to enable WEP via iwconfig succeeds and network connectivity is normal. However, NetworkManager still ignores the device at this point.

I'd think it's a ipw bug but I have no idea if that was even touched during this time.

Quoted 10 lines

Bisect with Mercurial points to this patch:

$ hg bisect bad
The first bad revision is:
changeset:   46985:f701b96bb2f7
user:        Greg Kroah-Hartman <[email protected]>
date:        Wed Feb 07 10:37:11 2007 -0800
summary:     Network: convert network devices to use struct device
instead of class_device

Quoted 1 line

which corresponds to 43cb76d91ee85f579a69d42bc8efc08bac560278 in git.

Yup, sysfs breakage/hal stuff. Can you try with a recent hal? And maybe try to bisect the iwconfig stop thing if you've got enough time...

Quoted 10 lines · Johannes Berg

[adding linux-wireless to CC]

Quoted 2 lines · Matt Mackall

Recent kernels are having troubles with wireless for me. Two seemingly related problems:

I don't think they are related actually.

Quoted 1 line

a) NetworkManager seems oblivious to the existence of my IPW2200

Quoted 2 lines

This is due to the recent sysfs restructuring I think. IIRC the fix is to upgrade hal to a current git version.

If that's the cause, the fix is to back out whatever was done to break userspace. Breaking userspace is not ok. Upgrading from 2.6.x to 2.6.x+1 should not entail replacing substantial parts of userspace, especially with NOT-EVEN-FRAKKING-RELEASED-YET CODE.

Quoted 14 lines · On Sun, 4 Mar 2007 18:25:50 -0600 Matt Mackall <[email protected]> wrote:

Quoted 12 lines · Johannes Berg

[adding linux-wireless to CC]

Quoted 2 lines · Matt Mackall

Recent kernels are having troubles with wireless for me. Two seemingly related problems:

I don't think they are related actually.

Quoted 1 line

a) NetworkManager seems oblivious to the existence of my IPW2200

This is due to the recent sysfs restructuring I think. IIRC the fix is to upgrade hal to a current git version.

Quoted 4 lines

If that's the cause, the fix is to back out whatever was done to break userspace. Breaking userspace is not ok. Upgrading from 2.6.x to 2.6.x+1 should not entail replacing substantial parts of userspace, especially with NOT-EVEN-FRAKKING-RELEASED-YET CODE.

yep. Adrian, I think we should track this as a blocking regression, at least until we've fully understood the implications and had the usual arguments.

Quoted 2 lines

This is due to the recent sysfs restructuring I think. IIRC the fix is to upgrade hal to a current git version.

If that's the cause, the fix is to back out whatever was done to break userspace. Breaking userspace is not ok. Upgrading from 2.6.x to 2.6.x+1 should not entail replacing substantial parts of userspace, especially with NOT-EVEN-FRAKKING-RELEASED-YET CODE.

I will try a new HAL when it shows up in Debian/unstable and not a moment sooner.

Quoted 10 lines · Johannes Berg

[adding linux-wireless to CC]

Quoted 2 lines · Matt Mackall

Recent kernels are having troubles with wireless for me. Two seemingly related problems:

I don't think they are related actually.

Quoted 1 line

a) NetworkManager seems oblivious to the existence of my IPW2200

Quoted 2 lines

This is due to the recent sysfs restructuring I think. IIRC the fix is to upgrade hal to a current git version.

If that's the cause, the fix is to back out whatever was done to break userspace. Breaking userspace is not ok. Upgrading from 2.6.x to 2.6.x+1 should not entail replacing substantial parts of userspace, especially with NOT-EVEN-FRAKKING-RELEASED-YET CODE.

Quoted 7 lines

Quoted 2 lines

This is due to the recent sysfs restructuring I think. IIRC the fix is to upgrade hal to a current git version.

If that's the cause, the fix is to back out whatever was done to break userspace. Breaking userspace is not ok. Upgrading from 2.6.x to 2.6.x+1 should not entail replacing substantial parts of userspace, especially with NOT-EVEN-FRAKKING-RELEASED-YET CODE.

I should not have broken any userspace if CONFIG_SYSFS_DEPRECATED is enabled with that patch. If that is enabled, and that patch still causes problems, please let me know.

I should not have broken any userspace if CONFIG_SYSFS_DEPRECATED is enabled with that patch. If that is enabled, and that patch still causes problems, please let me know.

Quoted 3 lines · Greg KH

I should not have broken any userspace if CONFIG_SYSFS_DEPRECATED is enabled with that patch. If that is enabled, and that patch still causes problems, please let me know.

But we still need to update the help text for CONFIG_SYS_DEPRECATED to make it clear that its deprecation schedule still needs to be 2009 to 2011 (depending on whether we want to accomodate Debian's glacial release schedule). Certainly the 2006 date which is currently there simply isn't accurate.

init/Kconfig config SYSFS_DEPRECATED · line 297

Quoted 9 lines · Greg KH

Ok, how about the following patch. Is it acceptable to everyone?

init/Kconfig +5 -2

-	  If you are using a distro that was released in 2006 or later,
-	  it should be safe to say N here.
+	  If you are using an OpenSuSE, Gentoo, Ubuntu, or Fedora
+	  release from 2007 or later, it should be safe to say N here.
+
+	  If you are using Debian or other distros that are slow to
+	  update HAL, please say Y here.

What HAL version do you think Debian ought to have, pray tell? And what the hell version do those other distros have?

The last HAL release was 0.5.8 on 11-Sep-2006. It showed up in Debian/unstable on 2-Oct. There have been six Debian bugfix releases, the most recent on 12-Feb.

http://people.freedesktop.org/~david/dist/
http://packages.debian.org/changelogs/pool/main/h/hal/hal_0.5.8.1-6.1/changelog

Ok, I only named HAL as that is what people have told me the problem is. I have been running this change on my boxs, without CONFIG_SYSFS_DEPRECATED since last July or so.

But I don't use NetworkManager here for the most part, but I have tried this in the OpenSuse10.3 alpha releases and it seems to work just fine with whatever version of NetworkManager it uses.

On Mon, Mar 05, 2007 at 07:59:50AM -0500, Theodore Tso wrote:

Ok, how about the following patch. Is it acceptable to everyone?

thanks,

greg k-h

---
 init/Kconfig |   13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

init/Kconfig +4 -2

@@ -290,8 +290,17 @@ config SYSFS_DEPRECATED
 	  that belong to a class, back into the /sys/class heirachy, in
 	  order to support older versions of udev.
 
-	  If you are using a distro that was released in 2006 or later,
-	  it should be safe to say N here.
+	  If you are using an OpenSuSE, Gentoo, Ubuntu, or Fedora
+	  release from 2007 or later, it should be safe to say N here.
+
+	  If you are using Debian or other distros that are slow to

Ok, how about the following patch. Is it acceptable to everyone?

thanks,

greg k-h

---
 init/Kconfig |   13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

init/Kconfig +0 -0

@@ -290,8 +290,17 @@ config SYSFS_DEPRECATED
 	  that belong to a class, back into the /sys/class heirachy, in

Quoted 15 lines · Greg KH

Ok, how about the following patch. Is it acceptable to everyone?

thanks,

greg k-h

---
 init/Kconfig |   13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

init/Kconfig +0 -0

@@ -290,8 +290,17 @@ config SYSFS_DEPRECATED
 	  that belong to a class, back into the /sys/class heirachy, in

init/Kconfig config SYSFS_DEPRECATED · line 297

Quoted 10 lines

init/Kconfig +5 -2

 	  order to support older versions of udev.
 
-	  If you are using a distro that was released in 2006 or later,
-	  it should be safe to say N here.
+	  If you are using an OpenSuSE, Gentoo, Ubuntu, or Fedora
+	  release from 2007 or later, it should be safe to say N here.
+
+	  If you are using Debian or other distros that are slow to
+	  update HAL, please say Y here.
...

The sane solution seems to be to enable SYSFS_DEPRECATED unconditionally for all users, and schedule it's removal for mid-2008 (or later).

12 months after the first _release_ of a HAL that can live without seems to be the first time when we can consider getting rid of it, since all distributions with at least one release a year should ship it by then.

Currently, SYSFS_DEPRECATED is only a trap for users.

Quoted 34 lines · Adrian Bunk

Quoted 15 lines · Greg KH

Ok, how about the following patch. Is it acceptable to everyone?

thanks,

greg k-h

---
 init/Kconfig |   13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

init/Kconfig +0 -0

@@ -290,8 +290,17 @@ config SYSFS_DEPRECATED
 	  that belong to a class, back into the /sys/class heirachy, in

init/Kconfig config SYSFS_DEPRECATED · line 297

Quoted 10 lines

init/Kconfig +5 -2

 	  order to support older versions of udev.
 
-	  If you are using a distro that was released in 2006 or later,
-	  it should be safe to say N here.
+	  If you are using an OpenSuSE, Gentoo, Ubuntu, or Fedora
+	  release from 2007 or later, it should be safe to say N here.
+
+	  If you are using Debian or other distros that are slow to
+	  update HAL, please say Y here.
...

The sane solution seems to be to enable SYSFS_DEPRECATED unconditionally for all users, and schedule it's removal for mid-2008 (or later).

12 months after the first _release_ of a HAL that can live without seems to be the first time when we can consider getting rid of it, since all distributions with at least one release a year should ship it by then.

Quoted 1 line

Currently, SYSFS_DEPRECATED is only a trap for users.

Huh?

No, again, I've been using this just fine for about 6 months now.

And what about all of the servers not using HAL/NetworkManager?

And what about all of the embedded systems not using either?

So to not allow this to be turned off by people who might want to (we want this for OpenSuSE 10.3, and Fedora 7 also will want this, as will other distros released this year), is pretty heavy-handed.

It also will work in OpenSuSE 10.2 which is already released, and I think Fedora 6, but I've only limited experience with these.

Oh, and Gentoo works just fine, and has been for the past 6 months.

I would just prefer to come up with an acceptable set of wording that will work to properly warn people.

I proposed one such wording which some people took as a slam against Debian, which it really was not at all.

Does someone else want to propose some other wording instead?

thanks,

greg k-h

Quoted 37 lines · Greg KH

Quoted 35 lines · Adrian Bunk

Quoted 15 lines · Greg KH

Ok, how about the following patch. Is it acceptable to everyone?

thanks,

greg k-h

---
 init/Kconfig |   13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

init/Kconfig +0 -0

@@ -290,8 +290,17 @@ config SYSFS_DEPRECATED
 	  that belong to a class, back into the /sys/class heirachy, in

init/Kconfig config SYSFS_DEPRECATED · line 297

Quoted 10 lines

init/Kconfig +5 -2

 	  order to support older versions of udev.
 
-	  If you are using a distro that was released in 2006 or later,
-	  it should be safe to say N here.
+	  If you are using an OpenSuSE, Gentoo, Ubuntu, or Fedora
+	  release from 2007 or later, it should be safe to say N here.
+
+	  If you are using Debian or other distros that are slow to
+	  update HAL, please say Y here.
...

The sane solution seems to be to enable SYSFS_DEPRECATED unconditionally for all users, and schedule it's removal for mid-2008 (or later).

12 months after the first _release_ of a HAL that can live without seems to be the first time when we can consider getting rid of it, since all distributions with at least one release a year should ship it by then.

Currently, SYSFS_DEPRECATED is only a trap for users.

Quoted 5 lines

Huh?

No, again, I've been using this just fine for about 6 months now.

And what about all of the servers not using HAL/NetworkManager?

On a server, it shouldn't harm.

Quoted 1 line

And what about all of the embedded systems not using either?

If it was much code, I would have sent a patch that allowed disabling it if EMBEDDED=y.

Quoted 8 lines

So to not allow this to be turned off by people who might want to (we want this for OpenSuSE 10.3, and Fedora 7 also will want this, as will other distros released this year), is pretty heavy-handed.

It also will work in OpenSuSE 10.2 which is already released, and I think Fedora 6, but I've only limited experience with these.

Oh, and Gentoo works just fine, and has been for the past 6 months.

For most people, it simply doesn't matter whether SYSFS_DEPRECATED is on or off.

But accidentally disabling SYSFS_DEPRECATED has proven to be a trap people sometimes fall into - and tracking them down to SYSFS_DEPRECATED=n sometimes takes some time.

Quoted 30 lines · Adrian Bunk

Quoted 15 lines · Greg KH

Ok, how about the following patch. Is it acceptable to everyone?

thanks,

greg k-h

---
 init/Kconfig |   13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

init/Kconfig +0 -0

@@ -290,8 +290,17 @@ config SYSFS_DEPRECATED
 	  that belong to a class, back into the /sys/class heirachy, in

init/Kconfig config SYSFS_DEPRECATED · line 297

Quoted 10 lines

init/Kconfig +5 -2

 	  order to support older versions of udev.
 
-	  If you are using a distro that was released in 2006 or later,
-	  it should be safe to say N here.
+	  If you are using an OpenSuSE, Gentoo, Ubuntu, or Fedora
+	  release from 2007 or later, it should be safe to say N here.
+
+	  If you are using Debian or other distros that are slow to
+	  update HAL, please say Y here.
...

The sane solution seems to be to enable SYSFS_DEPRECATED unconditionally for all users, and schedule it's removal for mid-2008 (or later).

Quoted 5 lines

12 months after the first _release_ of a HAL that can live without seems to be the first time when we can consider getting rid of it, since all distributions with at least one release a year should ship it by then.

Currently, SYSFS_DEPRECATED is only a trap for users.

Huh?

No, again, I've been using this just fine for about 6 months now.

And what about all of the servers not using HAL/NetworkManager? And what about all of the embedded systems not using either?

So to not allow this to be turned off by people who might want to (we want this for OpenSuSE 10.3, and Fedora 7 also will want this, as will other distros released this year), is pretty heavy-handed.

It also will work in OpenSuSE 10.2 which is already released, and I think Fedora 6, but I've only limited experience with these.

Oh, and Gentoo works just fine, and has been for the past 6 months.

I would just prefer to come up with an acceptable set of wording that will work to properly warn people.

I proposed one such wording which some people took as a slam against Debian, which it really was not at all.

Does someone else want to propose some other wording instead?

Quoted 53 lines · Greg KH

Quoted 30 lines · Adrian Bunk

Quoted 15 lines · Greg KH

Ok, how about the following patch. Is it acceptable to everyone?

thanks,

greg k-h

---
 init/Kconfig |   13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

init/Kconfig +0 -0

@@ -290,8 +290,17 @@ config SYSFS_DEPRECATED
 	  that belong to a class, back into the /sys/class heirachy, in

init/Kconfig config SYSFS_DEPRECATED · line 297

Quoted 10 lines

init/Kconfig +5 -2

 	  order to support older versions of udev.
 
-	  If you are using a distro that was released in 2006 or later,
-	  it should be safe to say N here.
+	  If you are using an OpenSuSE, Gentoo, Ubuntu, or Fedora
+	  release from 2007 or later, it should be safe to say N here.
+
+	  If you are using Debian or other distros that are slow to
+	  update HAL, please say Y here.
...

The sane solution seems to be to enable SYSFS_DEPRECATED unconditionally for all users, and schedule it's removal for mid-2008 (or later).

Quoted 5 lines

12 months after the first _release_ of a HAL that can live without seems to be the first time when we can consider getting rid of it, since all distributions with at least one release a year should ship it by then.

Currently, SYSFS_DEPRECATED is only a trap for users.

Huh?

No, again, I've been using this just fine for about 6 months now.

And what about all of the servers not using HAL/NetworkManager? And what about all of the embedded systems not using either?

So to not allow this to be turned off by people who might want to (we want this for OpenSuSE 10.3, and Fedora 7 also will want this, as will other distros released this year), is pretty heavy-handed.

It also will work in OpenSuSE 10.2 which is already released, and I think Fedora 6, but I've only limited experience with these.

Oh, and Gentoo works just fine, and has been for the past 6 months.

Quoted 7 lines

I would just prefer to come up with an acceptable set of wording that will work to properly warn people.

I proposed one such wording which some people took as a slam against Debian, which it really was not at all.

Does someone else want to propose some other wording instead?

Back up a bit. Let's review:

Problem: NetworkManager stopped working with my ipw2200 on Debian/unstable

Theory A: It broke because I'm not running an as-yet-unreleased HAL.

Then we should revert the patch pronto because it's an unqualified regression.

Theory B: It broke because I'm not running relatively recent HAL.

By all accounts I'm running the latest and greatest HAL and Network Manager, more than recent enough to work.

Theory C: It broke because I've got some goofy config.

My setup passes no arguments to either. The HAL config file is completely bare-bones and there's no sign of any configuration files for Network Manager.

Theory D: It broke for some nebulous Debian-related reason.

That's a bunch of unhelpful crap.

Can we come up with an actual theory for what's wrong with my setup, please? Like, perhaps:

Theory E: There's some undiagnosed new breakage that this introduces that no else hit until it went into mainline.

Theory F: It broke because you are using NetworkManager for your network devices and the patches that fix this have not made it into a real release?

I'm just guessing, but does anyone who is having this problem, NOT using NetworkManager?

I'm running an old version of HAL just fine, but I'm not using NetworkManager here.

Quoted 90 lines · Matt Mackall

Quoted 53 lines · Greg KH

Quoted 30 lines · Adrian Bunk

Quoted 15 lines · Greg KH

Ok, how about the following patch. Is it acceptable to everyone?

thanks,

greg k-h

---
 init/Kconfig |   13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

init/Kconfig +0 -0

@@ -290,8 +290,17 @@ config SYSFS_DEPRECATED
 	  that belong to a class, back into the /sys/class heirachy, in

init/Kconfig config SYSFS_DEPRECATED · line 297

Quoted 10 lines

init/Kconfig +5 -2

 	  order to support older versions of udev.
 
-	  If you are using a distro that was released in 2006 or later,
-	  it should be safe to say N here.
+	  If you are using an OpenSuSE, Gentoo, Ubuntu, or Fedora
+	  release from 2007 or later, it should be safe to say N here.
+
+	  If you are using Debian or other distros that are slow to
+	  update HAL, please say Y here.
...

The sane solution seems to be to enable SYSFS_DEPRECATED unconditionally for all users, and schedule it's removal for mid-2008 (or later).

Quoted 5 lines

12 months after the first _release_ of a HAL that can live without seems to be the first time when we can consider getting rid of it, since all distributions with at least one release a year should ship it by then.

Currently, SYSFS_DEPRECATED is only a trap for users.

Huh?

No, again, I've been using this just fine for about 6 months now.

And what about all of the servers not using HAL/NetworkManager? And what about all of the embedded systems not using either?

So to not allow this to be turned off by people who might want to (we want this for OpenSuSE 10.3, and Fedora 7 also will want this, as will other distros released this year), is pretty heavy-handed.

It also will work in OpenSuSE 10.2 which is already released, and I think Fedora 6, but I've only limited experience with these.

Oh, and Gentoo works just fine, and has been for the past 6 months.

Quoted 7 lines

I would just prefer to come up with an acceptable set of wording that will work to properly warn people.

I proposed one such wording which some people took as a slam against Debian, which it really was not at all.

Does someone else want to propose some other wording instead?

Back up a bit. Let's review:

Problem: NetworkManager stopped working with my ipw2200 on Debian/unstable

Theory A: It broke because I'm not running an as-yet-unreleased HAL.

Then we should revert the patch pronto because it's an unqualified regression.

Theory B: It broke because I'm not running relatively recent HAL.

By all accounts I'm running the latest and greatest HAL and Network Manager, more than recent enough to work.

Theory C: It broke because I've got some goofy config.

My setup passes no arguments to either. The HAL config file is completely bare-bones and there's no sign of any configuration files for Network Manager.

Theory D: It broke for some nebulous Debian-related reason.

That's a bunch of unhelpful crap.

Can we come up with an actual theory for what's wrong with my setup, please? Like, perhaps:

Quoted 2 lines

Theory E: There's some undiagnosed new breakage that this introduces that no else hit until it went into mainline.

Theory F: It broke because you are using NetworkManager for your network devices and the patches that fix this have not made it into a real release?

I'm just guessing, but does anyone who is having this problem, NOT using NetworkManager?

I'm running an old version of HAL just fine, but I'm not using NetworkManager here.

I am using NetworkManager on a OpenSuSE 10.3 release, but suse's version of NetworkManager is well known to not be anywhere near what is released as a tarball :(

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 56 lines · Greg KH

Quoted 30 lines · Adrian Bunk

Quoted 15 lines · Greg KH

Ok, how about the following patch. Is it acceptable to everyone?

thanks,

greg k-h

---
 init/Kconfig |   13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

init/Kconfig +0 -0

@@ -290,8 +290,17 @@ config SYSFS_DEPRECATED
 	  that belong to a class, back into the /sys/class heirachy, in

init/Kconfig config SYSFS_DEPRECATED · line 297

Quoted 10 lines

init/Kconfig +5 -2

 	  order to support older versions of udev.
 
-	  If you are using a distro that was released in 2006 or later,
-	  it should be safe to say N here.
+	  If you are using an OpenSuSE, Gentoo, Ubuntu, or Fedora
+	  release from 2007 or later, it should be safe to say N here.
+
+	  If you are using Debian or other distros that are slow to
+	  update HAL, please say Y here.
...

The sane solution seems to be to enable SYSFS_DEPRECATED unconditionally for all users, and schedule it's removal for mid-2008 (or later).

Quoted 5 lines

12 months after the first _release_ of a HAL that can live without seems to be the first time when we can consider getting rid of it, since all distributions with at least one release a year should ship it by then.

Currently, SYSFS_DEPRECATED is only a trap for users.

Huh?

No, again, I've been using this just fine for about 6 months now.

And what about all of the servers not using HAL/NetworkManager? And what about all of the embedded systems not using either?

So to not allow this to be turned off by people who might want to (we want this for OpenSuSE 10.3, and Fedora 7 also will want this, as will other distros released this year), is pretty heavy-handed.

It also will work in OpenSuSE 10.2 which is already released, and I think Fedora 6, but I've only limited experience with these.

Oh, and Gentoo works just fine, and has been for the past 6 months.

I would just prefer to come up with an acceptable set of wording that will work to properly warn people.

Quoted 4 lines

I proposed one such wording which some people took as a slam against Debian, which it really was not at all.

Does someone else want to propose some other wording instead?

Back up a bit. Let's review:

Problem: NetworkManager stopped working with my ipw2200 on Debian/unstable

Wait, have confirmed that if you enable this config option, NetworkManager starts back up again and works properly?

If so, can you disable the option and strace it to see what program is trying to access what? That will put the HAL/NetworkManager/libsysfs/distro script finger pointing to rest pretty quickly :)

If so, can you disable the option and strace it to see what program is trying to access what? That will put the HAL/NetworkManager/libsysfs/distro script finger pointing to rest pretty quickly :)

Quoted 4 lines · Greg KH

If so, can you disable the option and strace it to see what program is trying to access what? That will put the HAL/NetworkManager/libsysfs/distro script finger pointing to rest pretty quickly :)

Ok, I've got straces of both good and bad (>5M each). Filtered out random pointer values and the like, diffed, and filtered for /sys/, and the result's still 1.5M. What should I be looking for?

Quoted 9 lines · Matt Mackall

Quoted 4 lines · Greg KH

If so, can you disable the option and strace it to see what program is trying to access what? That will put the HAL/NetworkManager/libsysfs/distro script finger pointing to rest pretty quickly :)

Ok, I've got straces of both good and bad (>5M each). Filtered out random pointer values and the like, diffed, and filtered for /sys/, and the result's still 1.5M. What should I be looking for?

Failures when trying to read from /sys/class/net/

Or opening the directory and iterating over the subdirs in there. Or something like that.

But the /sys/class/net/ stuff should hopefully help narrow it down.

Quoted 11 lines · Greg KH

Quoted 9 lines · Matt Mackall

Quoted 4 lines · Greg KH

If so, can you disable the option and strace it to see what program is trying to access what? That will put the HAL/NetworkManager/libsysfs/distro script finger pointing to rest pretty quickly :)

Ok, I've got straces of both good and bad (>5M each). Filtered out random pointer values and the like, diffed, and filtered for /sys/, and the result's still 1.5M. What should I be looking for?

Quoted 6 lines

Failures when trying to read from /sys/class/net/

Or opening the directory and iterating over the subdirs in there. Or something like that.

But the /sys/class/net/ stuff should hopefully help narrow it down.

Works:

6857 open("/sys/class/net",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13

6857  fstat64(13, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
6857  fcntl64(13, F_SETFD, FD_CLOEXEC)  = 0
6857  getdents64(13, /* 5 entries */, 4096) = 120
6857  readlink("/sys/class/net/eth1", 0x80a2450, 256) = -1 EINVAL

(Invalid argument)
6857 readlink("/sys/class/net/eth1/device", "../../../devices/pci0000:00/0000:00:1e.0/0000:02:02.0", 256) = 53 6857 readlink("/sys/class/net/lo", 0x80a2450, 256) = -1 EINVAL (Invalid argument)
6857 readlink("/sys/class/net/lo/device", 0x80a2450, 256) = -1 ENOENT (No such
file or directory)
6857 readlink("/sys/class/net/eth0", 0x80a2450, 256) = -1 EINVAL (Invalid argument)
6857 readlink("/sys/class/net/eth0/device", "../../../devices/pci0000:00/0000:00:1e.0/0000:02:01.0", 256) = 53 6857 getdents64(13, /* 0 entries */, 4096) = 0
6857 close(13) = 0

Breaks:

3620 open("/sys/class/net",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13

3620  fstat64(13, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
3620  fcntl64(13, F_SETFD, FD_CLOEXEC)  = 0
3620  getdents64(13, /* 5 entries */, 4096) = 120
3620  readlink("/sys/class/net/eth1",

"../../devices/pci0000:00/0000:00:1e.0/00\00:02:02.0/eth1", 256) = 55 3620 readlink("/sys/devices/pci0000:00/0000:00:1e.0/0000:02:02.0/eth1/device", 0x809e910, 256) = -1 ENOENT (No such file or directory)
3620 readlink("/sys/class/net/lo", "../../devices/virtual/net/lo",
256) = 28
3620 readlink("/sys/devices/virtual/net/lo/device", 0x809e960, 256) = -1 ENOEN\T (No such file or directory)
3620 readlink("/sys/class/net/eth0", "../../devices/pci0000:00/0000:00:1e.0/00\00:02:01.0/eth0", 256) = 55 3620 readlink("/sys/devices/pci0000:00/0000:00:1e.0/0000:02:01.0/eth0/device", 0x809e960, 256) = -1 ENOENT (No such file or directory)
3620 getdents64(13, /* 0 entries */, 4096) = 0
3620 close(13) = 0

Quoted 11 lines · Greg KH

Quoted 9 lines · Matt Mackall

Quoted 4 lines · Greg KH

If so, can you disable the option and strace it to see what program is trying to access what? That will put the HAL/NetworkManager/libsysfs/distro script finger pointing to rest pretty quickly :)

Ok, I've got straces of both good and bad (>5M each). Filtered out random pointer values and the like, diffed, and filtered for /sys/, and the result's still 1.5M. What should I be looking for?

Quoted 6 lines

Failures when trying to read from /sys/class/net/

Or opening the directory and iterating over the subdirs in there. Or something like that.

But the /sys/class/net/ stuff should hopefully help narrow it down.

Works:

6857 open("/sys/class/net",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13

6857  fstat64(13, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
6857  fcntl64(13, F_SETFD, FD_CLOEXEC)  = 0
6857  getdents64(13, /* 5 entries */, 4096) = 120
6857  readlink("/sys/class/net/eth1", 0x80a2450, 256) = -1 EINVAL

(Invalid argument)
6857 readlink("/sys/class/net/eth1/device", "../../../devices/pci0000:00/0000:00:1e.0/0000:02:02.0", 256) = 53 6857 readlink("/sys/class/net/lo", 0x80a2450, 256) = -1 EINVAL (Invalid argument)
6857 readlink("/sys/class/net/lo/device", 0x80a2450, 256) = -1 ENOENT (No such
file or directory)
6857 readlink("/sys/class/net/eth0", 0x80a2450, 256) = -1 EINVAL (Invalid argument)
6857 readlink("/sys/class/net/eth0/device", "../../../devices/pci0000:00/0000:00:1e.0/0000:02:01.0", 256) = 53 6857 getdents64(13, /* 0 entries */, 4096) = 0
6857 close(13) = 0

Breaks:

3620 open("/sys/class/net",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13

3620  fstat64(13, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
3620  fcntl64(13, F_SETFD, FD_CLOEXEC)  = 0
3620  getdents64(13, /* 5 entries */, 4096) = 120
3620  readlink("/sys/class/net/eth1",

"../../devices/pci0000:00/0000:00:1e.0/00\00:02:02.0/eth1", 256) = 55 3620 readlink("/sys/devices/pci0000:00/0000:00:1e.0/0000:02:02.0/eth1/device", 0x809e910, 256) = -1 ENOENT (No such file or directory)
3620 readlink("/sys/class/net/lo", "../../devices/virtual/net/lo",
256) = 28
3620 readlink("/sys/devices/virtual/net/lo/device", 0x809e960, 256) = -1 ENOEN\T (No such file or directory)
3620 readlink("/sys/class/net/eth0", "../../devices/pci0000:00/0000:00:1e.0/00\00:02:01.0/eth0", 256) = 55 3620 readlink("/sys/devices/pci0000:00/0000:00:1e.0/0000:02:01.0/eth0/device", 0x809e960, 256) = -1 ENOENT (No such file or directory)
3620 getdents64(13, /* 0 entries */, 4096) = 0
3620 close(13) = 0

(depending on whether we want to accomodate Debian's glacial
release schedule).

Recent kernels are having troubles with wireless for me. Two seemingly related problems:

a) NetworkManager seems oblivious to the existence of my IPW2200
b) Manual iwconfig waits for 60s and then reports:

Error for wireless request "Set Encode" (8B2A) :
SET failed on device eth1 ; Operation not supported.

Quoted 3 lines · Matt Mackall

Recent kernels are having troubles with wireless for me. Two seemingly related problems:

Quoted 5 lines

a) NetworkManager seems oblivious to the existence of my IPW2200
b) Manual iwconfig waits for 60s and then reports:

Error for wireless request "Set Encode" (8B2A) :
SET failed on device eth1 ; Operation not supported.

Do you have CONFIG_SYSFS_DEPRECATED enabled? If not, please do as that will keep you from having to change any userspace code.

Quoted 4 lines · Greg KH

Quoted 3 lines · Matt Mackall

Recent kernels are having troubles with wireless for me. Two seemingly related problems:

Quoted 8 lines

Quoted 5 lines

a) NetworkManager seems oblivious to the existence of my IPW2200
b) Manual iwconfig waits for 60s and then reports:

Error for wireless request "Set Encode" (8B2A) :
SET failed on device eth1 ; Operation not supported.

Do you have CONFIG_SYSFS_DEPRECATED enabled? If not, please do as that will keep you from having to change any userspace code.

No, it's disabled. Will test once I'm done tracking down the iwconfig problem. From the help text for SYSFS_DEPRECATED:

If you are using a distro that was released in 2006 or later, it should be safe to say N here.

If we need an as-yet-unreleased HAL without it, I would say the above should be changed to 2008 or so. If Debian actually cuts a release in the next few months, you might make that 2010.

Quoted 17 lines · Matt Mackall

Quoted 4 lines · Greg KH

Quoted 3 lines · Matt Mackall

Recent kernels are having troubles with wireless for me. Two seemingly related problems:

Quoted 8 lines

Quoted 5 lines

a) NetworkManager seems oblivious to the existence of my IPW2200
b) Manual iwconfig waits for 60s and then reports:

Error for wireless request "Set Encode" (8B2A) :
SET failed on device eth1 ; Operation not supported.

Do you have CONFIG_SYSFS_DEPRECATED enabled? If not, please do as that will keep you from having to change any userspace code.

No, it's disabled. Will test once I'm done tracking down the iwconfig problem. From the help text for SYSFS_DEPRECATED:

Quoted 6 lines

If you are using a distro that was released in 2006 or later, it should be safe to say N here.

If we need an as-yet-unreleased HAL without it, I would say the above should be changed to 2008 or so. If Debian actually cuts a release in the next few months, you might make that 2010.

Well, just because Debian has such a slow release cycle, should the rest of the world be forced to follow suit? :)

When I originally wrote that, I thought Debian would have already done their release, my mistake...

Quoted 25 lines · Greg KH

Quoted 17 lines · Matt Mackall

Quoted 4 lines · Greg KH

Quoted 3 lines · Matt Mackall

Recent kernels are having troubles with wireless for me. Two seemingly related problems:

Quoted 8 lines

Quoted 5 lines

a) NetworkManager seems oblivious to the existence of my IPW2200
b) Manual iwconfig waits for 60s and then reports:

Error for wireless request "Set Encode" (8B2A) :
SET failed on device eth1 ; Operation not supported.

Do you have CONFIG_SYSFS_DEPRECATED enabled? If not, please do as that will keep you from having to change any userspace code.

No, it's disabled. Will test once I'm done tracking down the iwconfig problem. From the help text for SYSFS_DEPRECATED:

Quoted 6 lines

If you are using a distro that was released in 2006 or later, it should be safe to say N here.

If we need an as-yet-unreleased HAL without it, I would say the above should be changed to 2008 or so. If Debian actually cuts a release in the next few months, you might make that 2010.

Quoted 5 lines

Well, just because Debian has such a slow release cycle, should the rest of the world be forced to follow suit? :)

When I originally wrote that, I thought Debian would have already done their release, my mistake...

That's not the point. The point is that Debian/unstable as of _this morning_ doesn't work. For reference, I'm running both the latest releases of both hal (0.5.8.1-6.1) and network-manager (0.6.4-6). And there are people telling me I need a copy of HAL out of git that hasn't even been released for Debian to package. Debian isn't the problem here.

Quoted 6 lines

That's not the point. The point is that Debian/unstable as of _this morning_ doesn't work. For reference, I'm running both the latest releases of both hal (0.5.8.1-6.1) and network-manager (0.6.4-6). And there are people telling me I need a copy of HAL out of git that hasn't even been released for Debian to package. Debian isn't the problem here.

hal 0.5.9-rc1 (released, not from git) should work. It will be
problably released soon and picked by sane distributions. Debian is very irritating corner case.

Quoted 10 lines · Tomasz Torcz

Quoted 6 lines

That's not the point. The point is that Debian/unstable as of _this morning_ doesn't work. For reference, I'm running both the latest releases of both hal (0.5.8.1-6.1) and network-manager (0.6.4-6). And there are people telling me I need a copy of HAL out of git that hasn't even been released for Debian to package. Debian isn't the problem here.

hal 0.5.9-rc1 (released, not from git) should work. It will be
problably released soon and picked by sane distributions. Debian is very irritating corner case.

Presumably the -rc1 stands for "release candidate". Which means "not yet released". And when did it show up? 04-Mar-2007 at 18:31. That's right, YESTERDAY. Almost a full month after Greg's commit.

For the last time, DEBIAN IS NOT THE PROBLEM.

Quoted 16 lines · Matt Mackall

Quoted 10 lines · Tomasz Torcz

Quoted 6 lines

That's not the point. The point is that Debian/unstable as of _this morning_ doesn't work. For reference, I'm running both the latest releases of both hal (0.5.8.1-6.1) and network-manager (0.6.4-6). And there are people telling me I need a copy of HAL out of git that hasn't even been released for Debian to package. Debian isn't the problem here.

hal 0.5.9-rc1 (released, not from git) should work. It will be
problably released soon and picked by sane distributions. Debian is very irritating corner case.

Presumably the -rc1 stands for "release candidate". Which means "not yet released". And when did it show up? 04-Mar-2007 at 18:31. That's right, YESTERDAY. Almost a full month after Greg's commit.

Quoted 1 line

For the last time, DEBIAN IS NOT THE PROBLEM.

Can I please second this (having been burned by hell that was udev of the 0.5ish era) - Greg, please try to make changes in a cross-compatible way so that versions of userspace and kernel are not so closely dependant on tracking each other. The whole 2.6.8 -> 2.6.12 series of kernels and associated udevs are fraught with race conditions where upgrading one but not the other will leave your machine unbootable.

But I AM TRYING TO MAKE IT COMPATIBLE!!!

That's what that config option is there for. If you happen to be running a newer userspace, a different distro than what is in Debian right now, or don't use HAL and Networkmanager, then disable that option. Then all of sysfs looks just like it used to, no user visble changes at all. It doesn't get any more compatible than that.

So the question really is are we really done making changes to sysfs, or maybe what we should do is talk about major version numbers to sysfs.

Quoted 3 lines · On Mon, 5 Mar 2007 19:56:25 -0500 Theodore Tso <[email protected]> wrote:

So the question really is are we really done making changes to sysfs, or maybe what we should do is talk about major version numbers to sysfs.

Perhaps using a config option wasn't the right way to do this - a kernel boot parameter might be better.

Quoted 7 lines · Andrew Morton

Quoted 3 lines · On Mon, 5 Mar 2007 19:56:25 -0500 Theodore Tso <[email protected]> wrote:

So the question really is are we really done making changes to sysfs, or maybe what we should do is talk about major version numbers to sysfs.

Quoted 2 lines

Perhaps using a config option wasn't the right way to do this - a kernel boot parameter might be better.

Ok, I have no problem with that if people really want it. But give me the option to also make it a config option so I don't have to change our bootloaders too.

Does that sound acceptable?

Quoted 7 lines · Greg KH

But I AM TRYING TO MAKE IT COMPATIBLE!!!

That's what that config option is there for. If you happen to be running a newer userspace, a different distro than what is in Debian right now, or don't use HAL and Networkmanager, then disable that option. Then all of sysfs looks just like it used to, no user visble changes at all. It doesn't get any more compatible than that.

This is great, but I think the real problem isn't the config option, but what is changing if the config option isn't enabled. The claim which some, including Matt and Bron, seem to be making is that if you turn *off* CONFIG_SYSFS_DEPRECATED, you must be using at least hal 0.5.9-rc1, released ***yesterday***, or suffer breakages for at least some system configurations.

So the problem with putting a date in Kconfig.txt help file, or in Documentation/feature-removal-schedule.txt, is that if there are other incompatible changes which are added to sysfs in say, December 2007 or January 2008, but which are papered over with CONFIG_SYSFS_DEPRECATED, and then come June 2008, CONFIG_SYSFS_DEPRECATED is unceremoniously ripped out, then users will get screwed.

So the question really is are we really done making changes to sysfs, or maybe what we should do is talk about major version numbers to sysfs. Call what we have currently not CONFIG_SYSFS_DEPRECATED, but rather CONFIG_SYSFS_LAYOUT_1. At the moment, CONFIG_SYSFS_LAYOUT_2 is undergoing changes, but at some point we need to lock down and state that Layout version 2 is never going to change, and then people who want changes can go work on CONFIG_SYSFS_LAYOUT_3.

The problem with calling CONFIG_SYSFS_DEPRECATED is that people think that since it's deprecated, it should be turned off, but if we have staged major version numbers, with guarantees of absolute stability once a particular major version number is locked down, then it may make it a lot easier to talk about what version of hal and udev and Network Manager is really needed for different versions.

Quoted 6 lines · Matt Mackall

That's not the point. The point is that Debian/unstable as of _this morning_ doesn't work. For reference, I'm running both the latest releases of both hal (0.5.8.1-6.1) and network-manager (0.6.4-6). And there are people telling me I need a copy of HAL out of git that hasn't even been released for Debian to package. Debian isn't the problem here.

hal 0.5.9-rc1 (released, not from git) should work. It will be
problably released soon and picked by sane distributions. Debian is very irritating corner case.