Re: 2.6.13-mm1

Re: 2.6.13-mm1

[Reuben Farrelly]

Hi,

On 1/09/2005 10:58 a.m., Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/
> 
> - Included Alan's big tty layer buffering rewrite.  This breaks the build on
>   lots of more obscure character device drivers.  Patches welcome (please cc
>   Alan).
> 
> 
> 
> Changes since 2.6.13-rc6-mm2:
> 
> 
>  linus.patch
>  git-acpi.patch
>  git-arm.patch
>  git-cpufreq.patch
>  git-cryptodev.patch
>  git-ia64.patch
>  git-audit.patch
>  git-audit-ppc64-fix.patch
>  git-input.patch
>  git-jfs-fixup.patch
>  git-kbuild.patch
>  git-libata-all.patch
>  git-mtd.patch
>  git-netdev-all.patch
>  git-nfs.patch
>  git-ocfs2.patch
>  git-serial.patch
>  git-scsi-block.patch
>  git-scsi-iscsi.patch
>  git-scsi-misc.patch
>  git-watchdog.patch

This patch:

netlink-log-protocol-failures.patch

is causing lots of messages like this to be logged on my console:

Sep  2 11:52:41 tornado kernel: DEBUG: Failed to load PF_NETLINK protocol 9

It seems to be caused by audit support not being enabled in as if I rebuild 
with audit support the message goes away :)


I'm also observing some USB messages logged:

Sep  2 13:26:22 tornado kernel: usb 5-1: new full speed USB device using 
uhci_hcd and address 13
Sep  2 13:26:22 tornado kernel: drivers/usb/class/usblp.c: usblp0: USB 
Bidirectional printer dev 13 if 0 alt 0 proto 2 vid 0x03F0 pid 0x6204
Sep  2 13:26:23 tornado kernel: hub 5-0:1.0: port 1 disabled by hub (EMI?), 
re-enabling...
Sep  2 13:26:23 tornado kernel: usb 5-1: USB disconnect, address 13
Sep  2 13:26:23 tornado kernel: drivers/usb/class/usblp.c: usblp0: removed
Sep  2 13:26:23 tornado kernel: usb 5-1: new full speed USB device using 
uhci_hcd and address 14
Sep  2 13:26:23 tornado kernel: usb 5-1: device descriptor read/64, error -71
Sep  2 13:26:23 tornado kernel: usb 5-1: device descriptor read/64, error -71
Sep  2 13:26:23 tornado kernel: usb 5-1: new full speed USB device using 
uhci_hcd and address 15
Sep  2 13:26:23 tornado kernel: usb 5-1: device descriptor read/all, error -71
Sep  2 13:26:23 tornado kernel: usb 5-1: new full speed USB device using 
uhci_hcd and address 16
Sep  2 13:26:23 tornado kernel: usb 5-1: can't set config #1, error -71
Sep  2 13:26:23 tornado kernel: usb 5-1: new full speed USB device using 
uhci_hcd and address 17
Sep  2 13:26:24 tornado kernel: usb 5-1: unable to read config index 0 
descriptor/start
Sep  2 13:26:24 tornado kernel: usb 5-1: can't read configurations, error -71

[root@tornado kernel]# lsusb
Bus 005 Device 004: ID 050d:0105 Belkin Components
Bus 005 Device 003: ID 0451:2046 Texas Instruments, Inc. TUSB2046 Hub
Bus 005 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
[root@tornado kernel]#

Output of lsusb -v up at http://www.reub.net/kernel/lsusb-output

reuben

Re: 2.6.13-mm1

[J.A. Magallon]

On 1/09/2005 10:58 a.m., Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/
> 
> - Included Alan's big tty layer buffering rewrite.  This breaks the build on
>   lots of more obscure character device drivers.  Patches welcome (please cc
>   Alan).
> 

I have problems with udev and latest -mm.
2.6.13 boots fine, but 2.6.13-mm1 blocks when starting udev.
System is Mandriva Cooker. As cooker, things are changing fast (initscripts,
udev, etc), but the fact is that with the same setup, plain .13 boots
and -mm1 blocks. Udev is 068 version.

Any idea about what can be the reason ?

TIA

--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.13 (gcc 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0))

Re: 2.6.13-mm1

[Andrew Morton]

"J.A. Magallon" <jamagallon@able.es> wrote:
>
> 
> On 1/09/2005 10:58 a.m., Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/
> > 
> > - Included Alan's big tty layer buffering rewrite.  This breaks the build on
> >   lots of more obscure character device drivers.  Patches welcome (please cc
> >   Alan).
> > 
> 
> I have problems with udev and latest -mm.
> 2.6.13 boots fine, but 2.6.13-mm1 blocks when starting udev.
> System is Mandriva Cooker. As cooker, things are changing fast (initscripts,
> udev, etc), but the fact is that with the same setup, plain .13 boots
> and -mm1 blocks. Udev is 068 version.
> 
> Any idea about what can be the reason ?
> 

There's some suspect locking in the /proc/devices seq_file conversion code.

Could you revert convert-proc-devices-to-use-seq_file-interface-fix.patch
then convert-proc-devices-to-use-seq_file-interface.patch?

Re: 2.6.13-mm1

[J.A. Magallon]

On 09.02, Andrew Morton wrote:
> "J.A. Magallon" <jamagallon@able.es> wrote:
> >
> > 
> > On 1/09/2005 10:58 a.m., Andrew Morton wrote:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/
> > > 
> > > - Included Alan's big tty layer buffering rewrite.  This breaks the build on
> > >   lots of more obscure character device drivers.  Patches welcome (please cc
> > >   Alan).
> > > 
> > 
> > I have problems with udev and latest -mm.
> > 2.6.13 boots fine, but 2.6.13-mm1 blocks when starting udev.
> > System is Mandriva Cooker. As cooker, things are changing fast (initscripts,
> > udev, etc), but the fact is that with the same setup, plain .13 boots
> > and -mm1 blocks. Udev is 068 version.
> > 
> > Any idea about what can be the reason ?
> > 
> 
> There's some suspect locking in the /proc/devices seq_file conversion code.
> 
> Could you revert convert-proc-devices-to-use-seq_file-interface-fix.patch
> then convert-proc-devices-to-use-seq_file-interface.patch?
> 

Still the same result, system bocks starting udev...

--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.13 (gcc 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0))

Re: 2.6.13-mm1

[Andrew Morton]

"J.A. Magallon" <jamagallon@able.es> wrote:
>
> 
> On 09.02, Andrew Morton wrote:
> > "J.A. Magallon" <jamagallon@able.es> wrote:
> > >
> > > 
> > > On 1/09/2005 10:58 a.m., Andrew Morton wrote:
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/
> > > > 
> > > > - Included Alan's big tty layer buffering rewrite.  This breaks the build on
> > > >   lots of more obscure character device drivers.  Patches welcome (please cc
> > > >   Alan).
> > > > 
> > > 
> > > I have problems with udev and latest -mm.
> > > 2.6.13 boots fine, but 2.6.13-mm1 blocks when starting udev.
> > > System is Mandriva Cooker. As cooker, things are changing fast (initscripts,
> > > udev, etc), but the fact is that with the same setup, plain .13 boots
> > > and -mm1 blocks. Udev is 068 version.
> > > 
> > > Any idea about what can be the reason ?
> > > 
> > 
> > There's some suspect locking in the /proc/devices seq_file conversion code.
> > 
> > Could you revert convert-proc-devices-to-use-seq_file-interface-fix.patch
> > then convert-proc-devices-to-use-seq_file-interface.patch?
> > 
> 
> Still the same result, system bocks starting udev...
> 

OK, thanks.   Nothing from sysrq-t?  Does the below help?

--- devel/fs/sysfs/file.c~gregkh-driver-sysfs-strip_leading_trailing_whitespace-fix	2005-09-02 04:01:40.000000000 -0700
+++ devel-akpm/fs/sysfs/file.c	2005-09-02 04:05:02.000000000 -0700
@@ -202,13 +202,14 @@ fill_write_buffer(struct sysfs_buffer * 
  *	passing the buffer that we acquired in fill_write_buffer().
  */
 
-static int 
-flush_write_buffer(struct dentry * dentry, struct sysfs_buffer * buffer, size_t count)
+static int flush_write_buffer(struct dentry *dentry,
+			struct sysfs_buffer *buffer, size_t count_in)
 {
 	struct attribute * attr = to_attr(dentry);
 	struct kobject * kobj = to_kobj(dentry->d_parent);
 	struct sysfs_ops * ops = buffer->ops;
 	char *x;
+	size_t count = count_in;
 
 	/* locate trailing white space */
 	while ((count > 0) && isspace(buffer->page[count - 1]))
@@ -224,7 +225,8 @@ flush_write_buffer(struct dentry * dentr
 	/* terminate the string */
 	x[count] = '\0';
 
-	return ops->store(kobj, attr, x, count);
+	ops->store(kobj, attr, x, count);
+	return count_in;
 }
 
 
_

Re: 2.6.13-mm1

[J.A. Magallon]

On 09.02, Andrew Morton wrote:
> "J.A. Magallon" <jamagallon@able.es> wrote:
> >
> > 
> > On 09.02, Andrew Morton wrote:
> > > "J.A. Magallon" <jamagallon@able.es> wrote:
> > > >
> > > > 
> > > > On 1/09/2005 10:58 a.m., Andrew Morton wrote:
> > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/
> > > > > 
> > > > > - Included Alan's big tty layer buffering rewrite.  This breaks the build on
> > > > >   lots of more obscure character device drivers.  Patches welcome (please cc
> > > > >   Alan).
> > > > > 
> > > > 
> > > > I have problems with udev and latest -mm.
> > > > 2.6.13 boots fine, but 2.6.13-mm1 blocks when starting udev.
> > > > System is Mandriva Cooker. As cooker, things are changing fast (initscripts,
> > > > udev, etc), but the fact is that with the same setup, plain .13 boots
> > > > and -mm1 blocks. Udev is 068 version.
> > > > 
> > > > Any idea about what can be the reason ?
> > > > 
> > > 
> > > There's some suspect locking in the /proc/devices seq_file conversion code.
> > > 
> > > Could you revert convert-proc-devices-to-use-seq_file-interface-fix.patch
> > > then convert-proc-devices-to-use-seq_file-interface.patch?
> > > 
> > 
> > Still the same result, system bocks starting udev...
> > 
> 
> OK, thanks.   Nothing from sysrq-t?  Does the below help?
> 
> --- devel/fs/sysfs/file.c~gregkh-driver-sysfs-strip_leading_trailing_whitespace-fix	2005-09-02 04:01:40.000000000 -0700
> +++ devel-akpm/fs/sysfs/file.c	2005-09-02 04:05:02.000000000 -0700
> @@ -202,13 +202,14 @@ fill_write_buffer(struct sysfs_buffer * 
>   *	passing the buffer that we acquired in fill_write_buffer().
>   */
>  
> -static int 
> -flush_write_buffer(struct dentry * dentry, struct sysfs_buffer * buffer, size_t count)
> +static int flush_write_buffer(struct dentry *dentry,
> +			struct sysfs_buffer *buffer, size_t count_in)
>  {
>  	struct attribute * attr = to_attr(dentry);
>  	struct kobject * kobj = to_kobj(dentry->d_parent);
>  	struct sysfs_ops * ops = buffer->ops;
>  	char *x;
> +	size_t count = count_in;
>  
>  	/* locate trailing white space */
>  	while ((count > 0) && isspace(buffer->page[count - 1]))
> @@ -224,7 +225,8 @@ flush_write_buffer(struct dentry * dentr
>  	/* terminate the string */
>  	x[count] = '\0';
>  
> -	return ops->store(kobj, attr, x, count);
> +	ops->store(kobj, attr, x, count);
> +	return count_in;
>  }
>  

Bingo !.

That did the trink. Booting fine again.
I meant, just with this, without reverting the other 2 patches.

Thanks !

--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.13-jam2 (gcc 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0))

Re: 2.6.13-mm1

[gcoady]

On Fri, 2 Sep 2005 14:45:52 -0700, Andrew Morton <akpm@osdl.org> wrote:

>"J.A. Magallon" <jamagallon@able.es> wrote:
>>
[...] 
>> Still the same result, system bocks starting udev...
>> 
>
>OK, thanks.   Nothing from sysrq-t?  Does the below help?
>
>--- devel/fs/sysfs/file.c~gregkh-driver-sysfs-strip_leading_trailing_whitespace-fix	2005-09-02 04:01:40.000000000 -0700
>+++ devel-akpm/fs/sysfs/file.c	2005-09-02 04:05:02.000000000 -0700
>@@ -202,13 +202,14 @@ fill_write_buffer(struct sysfs_buffer * 
>  *	passing the buffer that we acquired in fill_write_buffer().
>  */
> 
>-static int 
>-flush_write_buffer(struct dentry * dentry, struct sysfs_buffer * buffer, size_t count)
>+static int flush_write_buffer(struct dentry *dentry,
>+			struct sysfs_buffer *buffer, size_t count_in)
> {
> 	struct attribute * attr = to_attr(dentry);
> 	struct kobject * kobj = to_kobj(dentry->d_parent);
> 	struct sysfs_ops * ops = buffer->ops;
> 	char *x;
>+	size_t count = count_in;
> 
> 	/* locate trailing white space */
> 	while ((count > 0) && isspace(buffer->page[count - 1]))
>@@ -224,7 +225,8 @@ flush_write_buffer(struct dentry * dentr
> 	/* terminate the string */
> 	x[count] = '\0';
> 
>-	return ops->store(kobj, attr, x, count);
>+	ops->store(kobj, attr, x, count);
>+	return count_in;
> }
> 
>
Hi Andrew,
Patch above fixes problem with sysfs writes to adm9240 driver 
locking up console in last three -mm kernels.

Grant.

Re: 2.6.13-mm1

[Andrew Morton]

Reuben Farrelly <reuben-lkml@reub.net> wrote:
>
> Hi,
> 
> On 1/09/2005 10:58 a.m., Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/
> > 
> ...
>
> This patch:
> 
> netlink-log-protocol-failures.patch
> 
> is causing lots of messages like this to be logged on my console:
> 
> Sep  2 11:52:41 tornado kernel: DEBUG: Failed to load PF_NETLINK protocol 9
>
> It seems to be caused by audit support not being enabled in as if I rebuild 
> with audit support the message goes away :)

OK, thanks.  I passed that on to David and Patrick.

> 
> 
> I'm also observing some USB messages logged:
> 
> Sep  2 13:26:22 tornado kernel: usb 5-1: new full speed USB device using 
> uhci_hcd and address 13
> Sep  2 13:26:22 tornado kernel: drivers/usb/class/usblp.c: usblp0: USB 
> Bidirectional printer dev 13 if 0 alt 0 proto 2 vid 0x03F0 pid 0x6204
> Sep  2 13:26:23 tornado kernel: hub 5-0:1.0: port 1 disabled by hub (EMI?), 
> re-enabling...
> Sep  2 13:26:23 tornado kernel: usb 5-1: USB disconnect, address 13
> Sep  2 13:26:23 tornado kernel: drivers/usb/class/usblp.c: usblp0: removed
> Sep  2 13:26:23 tornado kernel: usb 5-1: new full speed USB device using 
> uhci_hcd and address 14
> Sep  2 13:26:23 tornado kernel: usb 5-1: device descriptor read/64, error -71
> Sep  2 13:26:23 tornado kernel: usb 5-1: device descriptor read/64, error -71
> Sep  2 13:26:23 tornado kernel: usb 5-1: new full speed USB device using 
> uhci_hcd and address 15
> Sep  2 13:26:23 tornado kernel: usb 5-1: device descriptor read/all, error -71
> Sep  2 13:26:23 tornado kernel: usb 5-1: new full speed USB device using 
> uhci_hcd and address 16
> Sep  2 13:26:23 tornado kernel: usb 5-1: can't set config #1, error -71
> Sep  2 13:26:23 tornado kernel: usb 5-1: new full speed USB device using 
> uhci_hcd and address 17
> Sep  2 13:26:24 tornado kernel: usb 5-1: unable to read config index 0 
> descriptor/start
> Sep  2 13:26:24 tornado kernel: usb 5-1: can't read configurations, error -71
> 
> [root@tornado kernel]# lsusb
> Bus 005 Device 004: ID 050d:0105 Belkin Components
> Bus 005 Device 003: ID 0451:2046 Texas Instruments, Inc. TUSB2046 Hub
> Bus 005 Device 001: ID 0000:0000
> Bus 004 Device 001: ID 0000:0000
> Bus 003 Device 001: ID 0000:0000
> Bus 002 Device 001: ID 0000:0000
> Bus 001 Device 001: ID 0000:0000
> [root@tornado kernel]#
> 
> Output of lsusb -v up at http://www.reub.net/kernel/lsusb-output
> 

Added the usual Cc's...

Re: [linux-usb-devel] Re: 2.6.13-mm1

[Alan Stern]

On Thu, 1 Sep 2005, Andrew Morton wrote:

> Reuben Farrelly <reuben-lkml@reub.net> wrote:

> > I'm also observing some USB messages logged:
> > 
> > Sep  2 13:26:22 tornado kernel: usb 5-1: new full speed USB device using 
> > uhci_hcd and address 13
> > Sep  2 13:26:22 tornado kernel: drivers/usb/class/usblp.c: usblp0: USB 
> > Bidirectional printer dev 13 if 0 alt 0 proto 2 vid 0x03F0 pid 0x6204
> > Sep  2 13:26:23 tornado kernel: hub 5-0:1.0: port 1 disabled by hub (EMI?), 
> > re-enabling...

This message means pretty much what it says: noise or something else 
caused the connection to be disabled.  In theory this could be caused by a 
problem with the host controller, the cable, or the printer.  Does this 
happen consistently with 2.6.13-mm1?  Did it happen with 2.6.12?

> > Sep  2 13:26:23 tornado kernel: usb 5-1: USB disconnect, address 13
> > Sep  2 13:26:23 tornado kernel: drivers/usb/class/usblp.c: usblp0: removed
> > Sep  2 13:26:23 tornado kernel: usb 5-1: new full speed USB device using 
> > uhci_hcd and address 14
> > Sep  2 13:26:23 tornado kernel: usb 5-1: device descriptor read/64, error -71
> > Sep  2 13:26:23 tornado kernel: usb 5-1: device descriptor read/64, error -71
> > Sep  2 13:26:23 tornado kernel: usb 5-1: new full speed USB device using 
> > uhci_hcd and address 15
> > Sep  2 13:26:23 tornado kernel: usb 5-1: device descriptor read/all, error -71
> > Sep  2 13:26:23 tornado kernel: usb 5-1: new full speed USB device using 
> > uhci_hcd and address 16
> > Sep  2 13:26:23 tornado kernel: usb 5-1: can't set config #1, error -71
> > Sep  2 13:26:23 tornado kernel: usb 5-1: new full speed USB device using 
> > uhci_hcd and address 17
> > Sep  2 13:26:24 tornado kernel: usb 5-1: unable to read config index 0 
> > descriptor/start
> > Sep  2 13:26:24 tornado kernel: usb 5-1: can't read configurations, error -71

If it's not already in 2.6.13-mm1, this patch may help with the 
reinitialization:

http://marc.theaimsgroup.com/?l=linux-usb-devel&m=112551468126219&w=2

Alan Stern

Re: [linux-usb-devel] Re: 2.6.13-mm1

[Reuben Farrelly]

Hi Alan,

On 3/09/2005 3:19 a.m., Alan Stern wrote:
> On Thu, 1 Sep 2005, Andrew Morton wrote:
> 
>> Reuben Farrelly <reuben-lkml@reub.net> wrote:
> 
>>> I'm also observing some USB messages logged:
>>>
>>> Sep  2 13:26:22 tornado kernel: usb 5-1: new full speed USB device using 
>>> uhci_hcd and address 13
>>> Sep  2 13:26:22 tornado kernel: drivers/usb/class/usblp.c: usblp0: USB 
>>> Bidirectional printer dev 13 if 0 alt 0 proto 2 vid 0x03F0 pid 0x6204
>>> Sep  2 13:26:23 tornado kernel: hub 5-0:1.0: port 1 disabled by hub (EMI?), 
>>> re-enabling...
> 
> This message means pretty much what it says: noise or something else 
> caused the connection to be disabled.  In theory this could be caused by a 
> problem with the host controller, the cable, or the printer.  Does this 
> happen consistently with 2.6.13-mm1?  Did it happen with 2.6.12?

It may have just been a red herring, as I haven't had the problem appear 
since, nor had I seen it before then.  I've done multiple reboots, plug and 
unplugs to test since and all have been OK.

Thanks for taking the time to reply.

reuben