Re: 2.6.18-rc7-mm1

Re: 2.6.18-rc7-mm1

[Andrew Morton]

On Tue, 19 Sep 2006 22:25:21 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> > - It took maybe ten hours solid work to get this dogpile vaguely
> >   compiling and limping to a login prompt on x86, x86_64 and powerpc. 
> >   I guess it's worth briefly testing if you're keen.
> 
> It's not that bad, but unfortunately the networking doesn't work on my system
> (HPC nx6325 + SUSE 10.1 w/ updates, 64-bit).  Apparently, the interfaces don't
> get configured (both tg3 and bcm43xx are affected).

Is there anything interesting in the dmesg output?

Perhaps an `strace -f ifup' or whatever would tell us what's failing.

Re: 2.6.18-rc7-mm1: networking breakage on HPC nx6325 + SUSE 10.1

[Rafael J. Wysocki]

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

On Tuesday, 19 September 2006 22:36, Andrew Morton wrote:
> On Tue, 19 Sep 2006 22:25:21 +0200
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
> > > - It took maybe ten hours solid work to get this dogpile vaguely
> > >   compiling and limping to a login prompt on x86, x86_64 and powerpc. 
> > >   I guess it's worth briefly testing if you're keen.
> > 
> > It's not that bad, but unfortunately the networking doesn't work on my system
> > (HPC nx6325 + SUSE 10.1 w/ updates, 64-bit).  Apparently, the interfaces don't
> > get configured (both tg3 and bcm43xx are affected).
> 
> Is there anything interesting in the dmesg output?

Not to me. :-)
 
> Perhaps an `strace -f ifup' or whatever would tell us what's failing.

Well, I can configure the interfaces manually, with ifconfig, but the SUSE's
configuration tools don't work.  For example, "ifup eth0" tells me that
"No configuration found for eth0" and that's all.

Also, powersaved segfaults at startup so I think the problem is with hal
vs sysfs (again).

The output of dmesg after a fresh boot and the "strace ifup eth0" output
are attached.

Greetings,
Rafael


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

[-- Attachment #2: dmesg.log.gz --]
[-- Type: application/x-gzip, Size: 11523 bytes --]

[-- Attachment #3: strace.log.gz --]
[-- Type: application/x-gzip, Size: 5545 bytes --]

Re: 2.6.18-rc7-mm1: networking breakage on HPC nx6325 + SUSE 10.1

[David Miller]

From: "Rafael J. Wysocki" <rjw@sisk.pl>
Date: Wed, 20 Sep 2006 00:06:52 +0200

> I _guess_ the problem is caused by
> gregkh-driver-network-class_device-to-device.patch, but I can't verify this,
> because the kernel (obviously) doesn't compile if I revert it.

Indeed.

I thought we threw this patch out because we knew it would cause
problems for existing systems?  I do remember Greg making an argument
as to why we needed the change, but that doesn't make breaking people's
systems legitimate in any way.

Re: 2.6.18-rc7-mm1: networking breakage on HPC nx6325 + SUSE 10.1

[Rafael J. Wysocki]

On Tuesday, 19 September 2006 23:30, Rafael J. Wysocki wrote:
> On Tuesday, 19 September 2006 22:36, Andrew Morton wrote:
> > On Tue, 19 Sep 2006 22:25:21 +0200
> > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > 
> > > > - It took maybe ten hours solid work to get this dogpile vaguely
> > > >   compiling and limping to a login prompt on x86, x86_64 and powerpc. 
> > > >   I guess it's worth briefly testing if you're keen.
> > > 
> > > It's not that bad, but unfortunately the networking doesn't work on my system
> > > (HPC nx6325 + SUSE 10.1 w/ updates, 64-bit).  Apparently, the interfaces don't
> > > get configured (both tg3 and bcm43xx are affected).
> > 
> > Is there anything interesting in the dmesg output?
> 
> Not to me. :-)
>  
> > Perhaps an `strace -f ifup' or whatever would tell us what's failing.
> 
> Well, I can configure the interfaces manually, with ifconfig, but the SUSE's
> configuration tools don't work.  For example, "ifup eth0" tells me that
> "No configuration found for eth0" and that's all.
> 
> Also, powersaved segfaults at startup so I think the problem is with hal
> vs sysfs (again).
> 
> The output of dmesg after a fresh boot and the "strace ifup eth0" output
> are attached.

I _guess_ the problem is caused by
gregkh-driver-network-class_device-to-device.patch, but I can't verify this,
because the kernel (obviously) doesn't compile if I revert it.

Greetings,
Rafael


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

Re: 2.6.18-rc7-mm1: networking breakage on HPC nx6325 + SUSE 10.1

[Greg KH]

On Tue, Sep 19, 2006 at 03:06:29PM -0700, David Miller wrote:
> From: "Rafael J. Wysocki" <rjw@sisk.pl>
> Date: Wed, 20 Sep 2006 00:06:52 +0200
> 
> > I _guess_ the problem is caused by
> > gregkh-driver-network-class_device-to-device.patch, but I can't verify this,
> > because the kernel (obviously) doesn't compile if I revert it.
> 
> Indeed.
> 
> I thought we threw this patch out because we knew it would cause
> problems for existing systems?  I do remember Greg making an argument
> as to why we needed the change, but that doesn't make breaking people's
> systems legitimate in any way.

It's now thrown out, and I think Andrew already had a patch in his tree
that reverted this.

I'll be bringing it back eventually, but first we are going to work out
all the kinks by probably putting these changes in the next few SuSE
alpha releases to see what shakes out in userspace that we need to go
fix.

It's not 2.6.19 material at all, so don't worry :)

thanks,

greg k-h

Re: 2.6.18-rc7-mm1: networking breakage on HPC nx6325 + SUSE 10.1

[Rafael J. Wysocki]

On Wednesday, 20 September 2006 00:30, Greg KH wrote:
> On Tue, Sep 19, 2006 at 03:06:29PM -0700, David Miller wrote:
> > From: "Rafael J. Wysocki" <rjw@sisk.pl>
> > Date: Wed, 20 Sep 2006 00:06:52 +0200
> > 
> > > I _guess_ the problem is caused by
> > > gregkh-driver-network-class_device-to-device.patch, but I can't verify this,
> > > because the kernel (obviously) doesn't compile if I revert it.
> > 
> > Indeed.
> > 
> > I thought we threw this patch out because we knew it would cause
> > problems for existing systems?  I do remember Greg making an argument
> > as to why we needed the change, but that doesn't make breaking people's
> > systems legitimate in any way.
> 
> It's now thrown out, and I think Andrew already had a patch in his tree
> that reverted this.
> 
> I'll be bringing it back eventually, but first we are going to work out
> all the kinks by probably putting these changes in the next few SuSE
> alpha releases to see what shakes out in userspace that we need to go
> fix.
> 
> It's not 2.6.19 material at all, so don't worry :)

Please note, however, that by including such changes in -mm we make _other_
things be not tested.

For example, if I can't install a new kernel and use it on my system without
replacing some other pieces of software, I just won't be using it, because I
have no time for playing with udev, hal, powersaved, acpid, ...
Then, if there are any bugs in it that would have shown up on my system,
we won't know about them unless they show up on someone else's system,
which may not happen.

The more changes that break existing setups are there in -mm, the less
people will acutally try to use -mm kernels and that will result in buggier
-rc kernels and more bugs propagating to the "stable" ones.  Do we really
want that to happen?

Rafael


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

Re: 2.6.18-rc7-mm1: networking breakage on HPC nx6325 + SUSE 10.1

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 4369 bytes --]

On Tue, 19 Sep 2006 23:30:34 +0200, "Rafael J. Wysocki" said:

> Well, I can configure the interfaces manually, with ifconfig, but the SUSE's
> configuration tools don't work.  For example, "ifup eth0" tells me that
> "No configuration found for eth0" and that's all.

I'm seeing issues on a Dell Latitude C840 as well, but I'm not positive
it's the same bug(s).  The problem I'm seeing is that device renaming is
failing (I have up to 5 different ethernet-ish interfaces that can be
connected, so I abuse /sbin/nameif extensively. There seem to be some
other issues with pcmcia, but it's not clear what the problem is - it
manages to find the (normally down) ethernet on my Xircom card, but the
orinoco driver seems unable to find my wireless card....

For instance, under 2.6.18-rc6-mm2, I see:

pccard: CardBus card inserted into slot 0
PCI: Enabling device 0000:03:00.0 (0000 -> 0003)
ACPI: PCI Interrupt 0000:03:00.0[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:03:00.0 to 64
eth2: Xircom cardbus revision 3 at irq 11
PCI: Enabling device 0000:03:00.1 (0000 -> 0003)
ACPI: PCI Interrupt 0000:03:00.1[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
0000:03:00.1: ttyS1 at I/O 0xe080 (irq = 11) is a 16550A
pccard: PCMCIA card inserted into slot 2
[rename_device:851]: Changing netdevice name from [eth1] to [eth3]
ohci1394: fw-host0: AT dma reset ctx=0, aborting transmission
ieee1394: Current remote IRM is not 1394a-2000 compliant, resetting...
ieee1394: Host added: ID:BUS[0-00:1023]  GUID[374fc0002a71c021]
[rename_device:1237]: Changing netdevice name from [eth2] to [eth1]
cs: memory probe 0xf4000000-0xfbffffff: excluding 0xf4000000-0xf8ffffff 0xfa000000-0xfbffffff
pcmcia: registering new device pcmcia2.0
orinoco 0.15 (David Gibson <hermes@gibson.dropbear.id.au>, Pavel Roskin <proski@gnu.org>, et al)
orinoco_cs 0.15 (David Gibson <hermes@gibson.dropbear.id.au>, Pavel Roskin <proski@gnu.org>, et al)
pcmcia: request for exclusive IRQ could not be fulfilled.
pcmcia: the driver needs updating to supported shared IRQ lines.
cs: IO port probe 0x100-0x3af: excluding 0x370-0x37f
cs: IO port probe 0x3e0-0x4ff: clean.
cs: IO port probe 0x820-0x8ff: clean.
cs: IO port probe 0xc00-0xcf7: clean.
cs: IO port probe 0xa00-0xaff: clean.
cs: IO port probe 0x100-0x3af: excluding 0x370-0x37f
cs: IO port probe 0x3e0-0x4ff: clean.
cs: IO port probe 0x820-0x8ff: clean.
cs: IO port probe 0xc00-0xcf7: clean.
cs: IO port probe 0xa00-0xaff: clean.
cs: IO port probe 0x100-0x3af: excluding 0x370-0x37f
cs: IO port probe 0x3e0-0x4ff: clean.
cs: IO port probe 0x820-0x8ff: clean.
cs: IO port probe 0xc00-0xcf7: clean.
cs: IO port probe 0xa00-0xaff: clean.
eth2: Hardware identity 0005:0004:0005:0000
eth2: Station identity  001f:0001:0008:000a
eth2: Firmware determined as Lucent/Agere 8.10
eth2: Ad-hoc demo mode supported
eth2: IEEE standard IBSS ad-hoc mode supported
eth2: WEP supported, 104-bit key
eth2: MAC address 00:02:2D:5C:11:48
eth2: Station name "HERMES I"
eth2: ready
eth2: orinoco_cs at 2.0, irq 11, io 0xe100-0xe13f
[rename_device:1295]: Changing netdevice name from [eth2] to [eth5]
Non-volatile memory driver v1.2

and under -rc7-mm1, I see:

pccard: CardBus card inserted into slot 0
PCI: Enabling device 0000:03:00.0 (0000 -> 0003)
ACPI: PCI Interrupt 0000:03:00.0[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:03:00.0 to 64
eth1: Xircom cardbus revision 3 at irq 11 
PCI: Enabling device 0000:03:00.1 (0000 -> 0003)
ACPI: PCI Interrupt 0000:03:00.1[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
0000:03:00.1: ttyS1 at I/O 0xe080 (irq = 11) is a 16550A
pccard: PCMCIA card inserted into slot 2
ohci1394: fw-host0: AT dma reset ctx=0, aborting transmission
ieee1394: Current remote IRM is not 1394a-2000 compliant, resetting...
ieee1394: Host added: ID:BUS[0-00:1023]  GUID[374fc0002a71c021]
Non-volatile memory driver v1.2

Amazingly less chatty.  Much later, when /etc/rc5.d/S10network runs, we finally
see:

orinoco 0.15 (David Gibson <hermes@gibson.dropbear.id.au>, Pavel Roskin <proski@gnu.org>, et al)
orinoco_cs 0.15 (David Gibson <hermes@gibson.dropbear.id.au>, Pavel Roskin <proski@gnu.org>, et al)

but no output for the wireless configuring.

Unless somebody has a better idea overnight, I'll start a bisect of -rc7-mm1
in the morning...


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: 2.6.18-rc7-mm1: networking breakage on HPC nx6325 + SUSE 10.1

[Dmitry Torokhov]

On Tuesday 19 September 2006 18:30, Greg KH wrote:
> On Tue, Sep 19, 2006 at 03:06:29PM -0700, David Miller wrote:
> > From: "Rafael J. Wysocki" <rjw@sisk.pl>
> > Date: Wed, 20 Sep 2006 00:06:52 +0200
> > 
> > > I _guess_ the problem is caused by
> > > gregkh-driver-network-class_device-to-device.patch, but I can't verify this,
> > > because the kernel (obviously) doesn't compile if I revert it.
> > 
> > Indeed.
> > 
> > I thought we threw this patch out because we knew it would cause
> > problems for existing systems?  I do remember Greg making an argument
> > as to why we needed the change, but that doesn't make breaking people's
> > systems legitimate in any way.
> 
> It's now thrown out, and I think Andrew already had a patch in his tree
> that reverted this.
> 
> I'll be bringing it back eventually, but first we are going to work out
> all the kinks by probably putting these changes in the next few SuSE
> alpha releases to see what shakes out in userspace that we need to go
> fix.
> 

Greg,

Could you please comment on the patch below which is I believe achieves
the desired result - produces unified sysfs representation of kernel
device tree - without major reshuffle of every kernel subsystem.

-- 
Dmitry


Driver core: move class_device to /sys/device/... part of the tree

Move sysfs representation of class_device structure from /sys/class/...
to /sys/device/... to provide unified device tree; create symlinks
in /sys/class pointing to /sys/device/... to preserve existing
classification of devices.

Create /sys/device/virtual device which is parent for all class_devices
that do not have real parent device.

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---

 drivers/base/class.c |  154 ++++++++++++++++++++++++---------------------------
 1 files changed, 73 insertions(+), 81 deletions(-)

Index: work/drivers/base/class.c
===================================================================
--- work.orig/drivers/base/class.c
+++ work/drivers/base/class.c
@@ -521,60 +521,73 @@ char *make_class_name(const char *name, 
 	return class_name;
 }
 
+static struct device virtual_device = {
+	.bus_id = "virtual",
+};
+
 int class_device_add(struct class_device *class_dev)
 {
-	struct class *parent_class = NULL;
+	struct class *parent_class;
 	struct class_device *parent_class_dev = NULL;
+	struct device *parent_dev = NULL;
 	struct class_interface *class_intf;
-	char *class_name = NULL;
 	int error = -EINVAL;
 
-	class_dev = class_device_get(class_dev);
-	if (!class_dev)
-		return -EINVAL;
-
 	if (!strlen(class_dev->class_id))
-		goto out1;
+		return -EINVAL;
 
 	parent_class = class_get(class_dev->class);
 	if (!parent_class)
-		goto out1;
-
-	parent_class_dev = class_device_get(class_dev->parent);
+		return -EINVAL;
 
 	pr_debug("CLASS: registering class device: ID = '%s'\n",
 		 class_dev->class_id);
 
+	parent_class_dev = class_device_get(class_dev->parent);
+
+	if (!class_dev->dev)
+		class_dev->dev = &virtual_device;
+	parent_dev = get_device(class_dev->dev);
+
 	/* first, register with generic layer. */
 	error = kobject_set_name(&class_dev->kobj, "%s", class_dev->class_id);
 	if (error)
-		goto out2;
+		goto err_put_parents;
 
-	if (parent_class_dev)
-		class_dev->kobj.parent = &parent_class_dev->kobj;
-	else
-		class_dev->kobj.parent = &parent_class->subsys.kset.kobj;
+	class_dev->kobj.parent = parent_class_dev ?
+			&parent_class_dev->kobj : &parent_dev->kobj;
 
 	error = kobject_add(&class_dev->kobj);
 	if (error)
-		goto out2;
+		goto err_put_parents;
 
 	/* add the needed attributes to this device */
-	sysfs_create_link(&class_dev->kobj, &parent_class->subsys.kset.kobj, "subsystem");
+	error = sysfs_create_link(&class_dev->kobj,
+				  &parent_class->subsys.kset.kobj,
+				  "subsystem");
+	if (error)
+		goto err_del_kobject;
+
+	error = sysfs_create_link(&parent_class->subsys.kset.kobj,
+				  &class_dev->kobj,
+				  class_dev->class_id);
+	if (error)
+		goto err_del_subsys_link;
+
 	class_dev->uevent_attr.attr.name = "uevent";
 	class_dev->uevent_attr.attr.mode = S_IWUSR;
 	class_dev->uevent_attr.attr.owner = parent_class->owner;
 	class_dev->uevent_attr.store = store_uevent;
 	error = class_device_create_file(class_dev, &class_dev->uevent_attr);
 	if (error)
-		goto out3;
+		goto err_del_class_link;
 
 	if (MAJOR(class_dev->devt)) {
 		struct class_device_attribute *attr;
 		attr = kzalloc(sizeof(*attr), GFP_KERNEL);
 		if (!attr) {
 			error = -ENOMEM;
-			goto out4;
+			goto err_del_uevent_attr;
 		}
 		attr->attr.name = "dev";
 		attr->attr.mode = S_IRUGO;
@@ -583,7 +596,7 @@ int class_device_add(struct class_device
 		error = class_device_create_file(class_dev, attr);
 		if (error) {
 			kfree(attr);
-			goto out4;
+			goto err_del_uevent_attr;
 		}
 
 		class_dev->devt_attr = attr;
@@ -591,24 +604,11 @@ int class_device_add(struct class_device
 
 	error = class_device_add_attrs(class_dev);
 	if (error)
-		goto out5;
-
-	if (class_dev->dev) {
-		class_name = make_class_name(class_dev->class->name,
-					     &class_dev->kobj);
-		error = sysfs_create_link(&class_dev->kobj,
-					  &class_dev->dev->kobj, "device");
-		if (error)
-			goto out6;
-		error = sysfs_create_link(&class_dev->dev->kobj, &class_dev->kobj,
-					  class_name);
-		if (error)
-			goto out7;
-	}
+		goto err_del_devt_attr;
 
 	error = class_device_add_groups(class_dev);
 	if (error)
-		goto out8;
+		goto err_del_attrs;
 
 	kobject_uevent(&class_dev->kobj, KOBJ_ADD);
 
@@ -621,30 +621,26 @@ int class_device_add(struct class_device
 	}
 	up(&parent_class->sem);
 
-	goto out1;
+	return 0;
 
- out8:
-	if (class_dev->dev)
-		sysfs_remove_link(&class_dev->kobj, class_name);
- out7:
-	if (class_dev->dev)
-		sysfs_remove_link(&class_dev->kobj, "device");
- out6:
+ err_del_attrs:
 	class_device_remove_attrs(class_dev);
- out5:
+ err_del_devt_attr:
 	if (class_dev->devt_attr)
 		class_device_remove_file(class_dev, class_dev->devt_attr);
- out4:
+ err_del_uevent_attr:
 	class_device_remove_file(class_dev, &class_dev->uevent_attr);
- out3:
+ err_del_class_link:
+	sysfs_remove_link(&parent_class->subsys.kset.kobj, class_dev->class_id);
+ err_del_subsys_link:
+	sysfs_remove_link(&class_dev->kobj, "subsystem");
+ err_del_kobject:
 	kobject_del(&class_dev->kobj);
- out2:
-	if(parent_class_dev)
-		class_device_put(parent_class_dev);
+ err_put_parents:
+	class_device_put(parent_class_dev);
+	put_device(parent_dev);
 	class_put(parent_class);
- out1:
-	class_device_put(class_dev);
-	kfree(class_name);
+
 	return error;
 }
 
@@ -718,7 +714,8 @@ error:
 void class_device_del(struct class_device *class_dev)
 {
 	struct class *parent_class = class_dev->class;
-	struct class_device *parent_device = class_dev->parent;
+	struct class_device *parent_class_device = class_dev->parent;
+	struct device *parent_device = class_dev->dev;
 	struct class_interface *class_intf;
 	char *class_name = NULL;
 
@@ -731,12 +728,8 @@ void class_device_del(struct class_devic
 		up(&parent_class->sem);
 	}
 
-	if (class_dev->dev) {
-		class_name = make_class_name(class_dev->class->name,
-					     &class_dev->kobj);
-		sysfs_remove_link(&class_dev->kobj, "device");
-		sysfs_remove_link(&class_dev->dev->kobj, class_name);
-	}
+	sysfs_remove_link(&parent_class->subsys.kset.kobj,
+			  class_dev->class_id);
 	sysfs_remove_link(&class_dev->kobj, "subsystem");
 	class_device_remove_file(class_dev, &class_dev->uevent_attr);
 	if (class_dev->devt_attr)
@@ -747,7 +740,8 @@ void class_device_del(struct class_devic
 	kobject_uevent(&class_dev->kobj, KOBJ_REMOVE);
 	kobject_del(&class_dev->kobj);
 
-	class_device_put(parent_device);
+	put_device(parent_device);
+	class_device_put(parent_class_device);
 	class_put(parent_class);
 	kfree(class_name);
 }
@@ -788,36 +782,30 @@ void class_device_destroy(struct class *
 
 int class_device_rename(struct class_device *class_dev, char *new_name)
 {
-	int error = 0;
-	char *old_class_name = NULL, *new_class_name = NULL;
-
-	class_dev = class_device_get(class_dev);
-	if (!class_dev)
-		return -EINVAL;
+	int error;
+	char *old_name;
 
 	pr_debug("CLASS: renaming '%s' to '%s'\n", class_dev->class_id,
 		 new_name);
 
-	if (class_dev->dev)
-		old_class_name = make_class_name(class_dev->class->name,
-						 &class_dev->kobj);
+	old_name = kstrdup(class_dev->class_id, GFP_KERNEL);
+	if (!old_name)
+		return -ENOMEM;
 
 	strlcpy(class_dev->class_id, new_name, KOBJ_NAME_LEN);
 
 	error = kobject_rename(&class_dev->kobj, new_name);
-
-	if (class_dev->dev) {
-		new_class_name = make_class_name(class_dev->class->name,
-						 &class_dev->kobj);
-		sysfs_create_link(&class_dev->dev->kobj, &class_dev->kobj,
-				  new_class_name);
-		sysfs_remove_link(&class_dev->dev->kobj, old_class_name);
+	if (error) {
+		strlcpy(class_dev->class_id, old_name, KOBJ_NAME_LEN);
+		goto out;
 	}
-	class_device_put(class_dev);
 
-	kfree(old_class_name);
-	kfree(new_class_name);
+	sysfs_create_link(&class_dev->class->subsys.kset.kobj,
+			  &class_dev->kobj, new_name);
+	sysfs_remove_link(&class_dev->class->subsys.kset.kobj, old_name);
 
+ out:
+	kfree(old_name);
 	return error;
 }
 
@@ -877,8 +865,6 @@ void class_interface_unregister(struct c
 	class_put(parent);
 }
 
-
-
 int __init classes_init(void)
 {
 	int retval;
@@ -892,6 +878,12 @@ int __init classes_init(void)
 	subsystem_init(&class_obj_subsys);
 	if (!class_obj_subsys.kset.subsys)
 			class_obj_subsys.kset.subsys = &class_obj_subsys;
+
+	retval = device_register(&virtual_device);
+	if (retval)
+		printk(KERN_ERR "Failed to register virtual device, err: %d\n",
+			retval);
+
 	return 0;
 }
 

Re: 2.6.18-rc7-mm1: networking breakage on HPC nx6325 + SUSE 10.1

[Greg KH]

On Wed, Sep 20, 2006 at 12:56:57AM +0200, Rafael J. Wysocki wrote:
> On Wednesday, 20 September 2006 00:30, Greg KH wrote:
> > On Tue, Sep 19, 2006 at 03:06:29PM -0700, David Miller wrote:
> > > From: "Rafael J. Wysocki" <rjw@sisk.pl>
> > > Date: Wed, 20 Sep 2006 00:06:52 +0200
> > > 
> > > > I _guess_ the problem is caused by
> > > > gregkh-driver-network-class_device-to-device.patch, but I can't verify this,
> > > > because the kernel (obviously) doesn't compile if I revert it.
> > > 
> > > Indeed.
> > > 
> > > I thought we threw this patch out because we knew it would cause
> > > problems for existing systems?  I do remember Greg making an argument
> > > as to why we needed the change, but that doesn't make breaking people's
> > > systems legitimate in any way.
> > 
> > It's now thrown out, and I think Andrew already had a patch in his tree
> > that reverted this.
> > 
> > I'll be bringing it back eventually, but first we are going to work out
> > all the kinks by probably putting these changes in the next few SuSE
> > alpha releases to see what shakes out in userspace that we need to go
> > fix.
> > 
> > It's not 2.6.19 material at all, so don't worry :)
> 
> Please note, however, that by including such changes in -mm we make _other_
> things be not tested.
> 
> For example, if I can't install a new kernel and use it on my system without
> replacing some other pieces of software, I just won't be using it, because I
> have no time for playing with udev, hal, powersaved, acpid, ...
> Then, if there are any bugs in it that would have shown up on my system,
> we won't know about them unless they show up on someone else's system,
> which may not happen.
> 
> The more changes that break existing setups are there in -mm, the less
> people will acutally try to use -mm kernels and that will result in buggier
> -rc kernels and more bugs propagating to the "stable" ones.  Do we really
> want that to happen?

When it comes back, I will have updates for all versions of broken udev
packages so that it will not break older distros.  Then it will be able
to be tested.

thanks,

greg k-h

Re: 2.6.18-rc7-mm1

[Rafael J. Wysocki]

On Wednesday, 20 September 2006 16:23, Mike Galbraith wrote:
> On Tue, 2006-09-19 at 13:36 -0700, Andrew Morton wrote:
> > On Tue, 19 Sep 2006 22:25:21 +0200
> > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > 
> > > > - It took maybe ten hours solid work to get this dogpile vaguely
> > > >   compiling and limping to a login prompt on x86, x86_64 and powerpc. 
> > > >   I guess it's worth briefly testing if you're keen.
> > > 
> > > It's not that bad, but unfortunately the networking doesn't work on my system
> > > (HPC nx6325 + SUSE 10.1 w/ updates, 64-bit).  Apparently, the interfaces don't
> > > get configured (both tg3 and bcm43xx are affected).
> > 
> > Is there anything interesting in the dmesg output?
> > 
> > Perhaps an `strace -f ifup' or whatever would tell us what's failing.
> 
> FYI, it`s SuSE`s /sbin/getcfg binary that doesn't like the changes.  It
> sees /sys/class/net/eth0 as a symlink, and reels off into sys/block (?)
> looking for a directory.

I have filed a report in the SUSE bugzilla.  Let's see what happens.

Greetings,
Rafael


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

Re: 2.6.18-rc7-mm1

[Mike Galbraith]

On Tue, 2006-09-19 at 13:36 -0700, Andrew Morton wrote:
> On Tue, 19 Sep 2006 22:25:21 +0200
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
> > > - It took maybe ten hours solid work to get this dogpile vaguely
> > >   compiling and limping to a login prompt on x86, x86_64 and powerpc. 
> > >   I guess it's worth briefly testing if you're keen.
> > 
> > It's not that bad, but unfortunately the networking doesn't work on my system
> > (HPC nx6325 + SUSE 10.1 w/ updates, 64-bit).  Apparently, the interfaces don't
> > get configured (both tg3 and bcm43xx are affected).
> 
> Is there anything interesting in the dmesg output?
> 
> Perhaps an `strace -f ifup' or whatever would tell us what's failing.

FYI, it`s SuSE`s /sbin/getcfg binary that doesn't like the changes.  It
sees /sys/class/net/eth0 as a symlink, and reels off into sys/block (?)
looking for a directory.

lstat64("/sys/class/net/eth0", {st_dev=makedev(0, 0), st_ino=5968, st_mode=S_IFLNK|0777, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=0, st_atime=2006/09/20-13:59:13, st_mtime=2006/09/20-13:58:57, st_ctime=2006/09/20-13:58:57}) = 0
lstat64("/sys/block/eth0", 0xbf9e432c)  = -1 ENOENT (No such file or directory)
open("/proc/mounts", O_RDONLY)          = 3
fstat64(3, {st_dev=makedev(0, 3), st_ino=22711, st_mode=S_IFREG|0444, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=0, st_atime=2006/09/20-14:00:35, st_mtime=2006/09/20-14:00:35, st_ctime=2006/09/20-14:00:35}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f59000
read(3, "rootfs / rootfs rw 0 0\nudev /dev"..., 4096) = 601
close(3)                                = 0
munmap(0xb7f59000, 4096)                = 0
lstat64("/sys/block", {st_dev=makedev(0, 0), st_ino=256, st_mode=S_IFDIR|0755, st_nlink=18, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=0, st_atime=2006/09/20-14:00:17, st_mtime=2006/09/20-13:58:59, st_ctime=2006/09/20-13:58:59}) = 0
lstat64("/sys/block", {st_dev=makedev(0, 0), st_ino=256, st_mode=S_IFDIR|0755, st_nlink=18, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=0, st_atime=2006/09/20-14:00:17, st_mtime=2006/09/20-13:58:59, st_ctime=2006/09/20-13:58:59}) = 0
open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory)
open("/sys/block", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
fstat64(3, {st_dev=makedev(0, 0), st_ino=256, st_mode=S_IFDIR|0755, st_nlink=18, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=0, st_atime=2006/09/20-14:00:17, st_mtime=2006/09/20-13:58:59, st_ctime=2006/09/20-13:58:59}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
getdents64(3, {{d_ino=256, d_off=1, d_type=DT_DIR, d_reclen=24, d_name="."} {d_ino=1, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."} {d_ino=11521, d_off=3, d_type=DT_DIR, d_reclen=24, d_name="sde"} {d_ino=11455, d_off=4, d_type=DT_DIR, d_reclen=24, d_name="sdd"} {d_ino=11416, d_off=5, d_type=DT_DIR, d_reclen=24, d_name="sdc"} {d_ino=11358, d_off=6, d_type=DT_DIR, d_reclen=24, d_name="sdb"} {d_ino=11311, d_off=7, d_type=DT_DIR, d_reclen=24, d_name="sda"} {d_ino=1784, d_off=8, d_type=DT_DIR, d_reclen=24, d_name="hdd"} {d_ino=1770, d_off=9, d_type=DT_DIR, d_reclen=24, d_name="hdc"} {d_ino=1757, d_off=10, d_type=DT_DIR, d_reclen=24, d_name="hda"} {d_ino=1725, d_off=11, d_type=DT_DIR, d_reclen=32, d_name="loop7"} {d_ino=1722, d_off=12, d_type=DT_DIR, d_reclen=32, d_name="loop6"} {d_ino=1719, d_off=13, d_type=DT_DIR, d_reclen=32, d_name="loop5"} {d_ino=1716, d_off=14, d_type=DT_DIR, d_recle
 n=32, d_name="loop4"} {d_ino=1713, d_off=15, d_type=DT_DIR, d_reclen=32, d_name="loop3"} {d_ino=1710, d_off=16, d_type=DT_DIR, d_reclen=32, d_name="loop2"} {d_ino=1707, d_off=17, d_type=DT_DIR, d_reclen=32, d_name="loop1"} {d_ino=1704, d_off=18, d_type=DT_DIR, d_reclen=32, d_name="loop0"}}, 4096) = 496
lstat64("/sys/block/sde", {st_dev=makedev(0, 0), st_ino=11521, st_mode=S_IFDIR|0755, st_nlink=5, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=0, st_atime=2006/09/20-13:59:14, st_mtime=2006/09/20-13:58:59, st_ctime=2006/09/20-13:58:59}) = 0
lstat64("/sys/block/sde", {st_dev=makedev(0, 0), st_ino=11521, st_mode=S_IFDIR|0755, st_nlink=5, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=0, st_atime=2006/09/20-13:59:14, st_mtime=2006/09/20-13:58:59, st_ctime=2006/09/20-13:58:59}) = 0
lstat64("/sys/block/sdd", {st_dev=makedev(0, 0), st_ino=11455, st_mode=S_IFDIR|0755, st_nlink=5, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=0, st_atime=2006/09/20-13:59:14, st_mtime=2006/09/20-13:58:59, st_ctime=2006/09/20-13:58:59}) = 0
lstat64("/sys/block/sdd", {st_dev=makedev(0, 0), st_ino=11455, st_mode=S_IFDIR|0755, st_nlink=5, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=0, st_atime=2006/09/20-13:59:14, st_mtime=2006/09/20-13:58:59, st_ctime=2006/09/20-13:58:59}) = 0
lstat64("/sys/block/sdc", {st_dev=makedev(0, 0), st_ino=11416, st_mode=S_IFDIR|0755, st_nlink=5, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=0, st_atime=2006/09/20-13:59:14, st_mtime=2006/09/20-13:58:59, st_ctime=2006/09/20-13:58:59}) = 0
lstat64("/sys/block/sdc", {st_dev=makedev(0, 0), st_ino=11416, st_mode=S_IFDIR|0755, st_nlink=5, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=0, st_atime=2006/09/20-13:59:14, st_mtime=2006/09/20-13:58:59, st_ctime=2006/09/20-13:58:59}) = 0
lstat64("/sys/block/sdb", {st_dev=makedev(0, 0), st_ino=11358, st_mode=S_IFDIR|0755, st_nlink=5, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=0, st_atime=2006/09/20-13:59:14, st_mtime=2006/09/20-13:58:59, st_ctime=2006/09/20-13:58:59}) = 0
... fruitless search

Re: 2.6.18-rc7-mm1

[Andi Kleen]

On Wednesday 20 September 2006 16:23, Mike Galbraith wrote:
> On Tue, 2006-09-19 at 13:36 -0700, Andrew Morton wrote:
> > On Tue, 19 Sep 2006 22:25:21 +0200
> > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > 
> > > > - It took maybe ten hours solid work to get this dogpile vaguely
> > > >   compiling and limping to a login prompt on x86, x86_64 and powerpc. 
> > > >   I guess it's worth briefly testing if you're keen.
> > > 
> > > It's not that bad, but unfortunately the networking doesn't work on my system
> > > (HPC nx6325 + SUSE 10.1 w/ updates, 64-bit).  Apparently, the interfaces don't
> > > get configured (both tg3 and bcm43xx are affected).
> > 
> > Is there anything interesting in the dmesg output?
> > 
> > Perhaps an `strace -f ifup' or whatever would tell us what's failing.
> 
> FYI, it`s SuSE`s /sbin/getcfg binary that doesn't like the changes.  It
> sees /sys/class/net/eth0 as a symlink, and reels off into sys/block (?)
> looking for a directory.

It's a known problem. It's actually libsysfs' fault which somehow manages
to not support symlinks properly. Unfortunately getcfg made the mistake of using libsysfs
instead of accessing /sys directly

-Andi