Re: 2.6.18-rc7-mm1
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 [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-rc7-mm1
On Tue, 2006-09-19 at 13:36 -0700, Andrew Morton wrote:
On Tue, 19 Sep 2006 22:25:21 +0200
Rafael J. Wysocki [EMAIL PROTECTED] 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_reclen=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,
Re: 2.6.18-rc7-mm1
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 [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-rc7-mm1
On Tue, 19 Sep 2006 22:25:21 +0200 Rafael J. Wysocki [EMAIL PROTECTED] 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. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-rc7-mm1: networking breakage on HPC nx6325 + SUSE 10.1
On Tuesday, 19 September 2006 22:36, Andrew Morton wrote: On Tue, 19 Sep 2006 22:25:21 +0200 Rafael J. Wysocki [EMAIL PROTECTED] 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 dmesg.log.gz Description: GNU Zip compressed data strace.log.gz Description: GNU Zip compressed data
Re: 2.6.18-rc7-mm1: networking breakage on HPC nx6325 + SUSE 10.1
From: Rafael J. Wysocki [EMAIL PROTECTED] 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. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-rc7-mm1: networking breakage on HPC nx6325 + SUSE 10.1
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 [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-rc7-mm1: networking breakage on HPC nx6325 + SUSE 10.1
On Tue, Sep 19, 2006 at 03:06:29PM -0700, David Miller wrote: From: Rafael J. Wysocki [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-rc7-mm1: networking breakage on HPC nx6325 + SUSE 10.1
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 [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-rc7-mm1: networking breakage on HPC nx6325 + SUSE 10.1
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 :03:00.0 ( - 0003) ACPI: PCI Interrupt :03:00.0[A] - Link [LNKD] - GSI 11 (level, low) - IRQ 11 PCI: Setting latency timer of device :03:00.0 to 64 eth2: Xircom cardbus revision 3 at irq 11 PCI: Enabling device :03:00.1 ( - 0003) ACPI: PCI Interrupt :03:00.1[A] - Link [LNKD] - GSI 11 (level, low) - IRQ 11 :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 0xf400-0xfbff: excluding 0xf400-0xf8ff 0xfa00-0xfbff pcmcia: registering new device pcmcia2.0 orinoco 0.15 (David Gibson [EMAIL PROTECTED], Pavel Roskin [EMAIL PROTECTED], et al) orinoco_cs 0.15 (David Gibson [EMAIL PROTECTED], Pavel Roskin [EMAIL PROTECTED], 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: 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 :03:00.0 ( - 0003) ACPI: PCI Interrupt :03:00.0[A] - Link [LNKD] - GSI 11 (level, low) - IRQ 11 PCI: Setting latency timer of device :03:00.0 to 64 eth1: Xircom cardbus revision 3 at irq 11 PCI: Enabling device :03:00.1 ( - 0003) ACPI: PCI Interrupt :03:00.1[A] - Link [LNKD] - GSI 11 (level, low) - IRQ 11 :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 [EMAIL PROTECTED], Pavel Roskin [EMAIL PROTECTED], et al) orinoco_cs 0.15 (David Gibson [EMAIL PROTECTED], Pavel Roskin [EMAIL PROTECTED], 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... pgpbWRrp6DrOR.pgp Description: PGP signature
Re: 2.6.18-rc7-mm1: networking breakage on HPC nx6325 + SUSE 10.1
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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
---
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 =
Re: 2.6.18-rc7-mm1: networking breakage on HPC nx6325 + SUSE 10.1
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 [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
