Re: 2.6.13-mm1

Re: 2.6.13-mm1

[J.A. Magallon]

Hi...

Back from holydays and trying to get up-to-date with new kernel releases.
With 2.6.13-mm1, I get this:


werewolf:/usr/src/linux# make
  CHK     include/linux/version.h
make[1]: `arch/i386/kernel/asm-offsets.s' is up to date.
  CHK     include/linux/compile.h
  CHK     usr/initramfs_list
  LD      drivers/scsi/aic7xxx/built-in.o
drivers/scsi/aic7xxx/aic79xx.o: In function `aic_parse_brace_option':
: multiple definition of `aic_parse_brace_option'
drivers/scsi/aic7xxx/aic7xxx.o:: first defined here
make[3]: *** [drivers/scsi/aic7xxx/built-in.o] Error 1
make[2]: *** [drivers/scsi/aic7xxx] Error 2
make[1]: *** [drivers/scsi] Error 2
make: *** [drivers] Error 2

I have both aic7xxx and aic79xx built-in in my config. The problem is
including aiclib.c from both source files...
Fast and dirty workaround is plaguing it with 'static inline's, but it has
to be a better way...

by

--
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.12-jam12 (gcc 4.0.1 (4.0.1-0.2mdk for Mandriva Linux release 2006.0))

Re: 2.6.13-mm1

[Adrian Bunk]

On Thu, Sep 01, 2005 at 06:21:50PM +0000, J.A. Magallon wrote:

> Hi...
> 
> Back from holydays and trying to get up-to-date with new kernel releases.
> With 2.6.13-mm1, I get this:
> 
> 
> werewolf:/usr/src/linux# make
>   CHK     include/linux/version.h
> make[1]: `arch/i386/kernel/asm-offsets.s' is up to date.
>   CHK     include/linux/compile.h
>   CHK     usr/initramfs_list
>   LD      drivers/scsi/aic7xxx/built-in.o
> drivers/scsi/aic7xxx/aic79xx.o: In function `aic_parse_brace_option':
> : multiple definition of `aic_parse_brace_option'
> drivers/scsi/aic7xxx/aic7xxx.o:: first defined here
> make[3]: *** [drivers/scsi/aic7xxx/built-in.o] Error 1
> make[2]: *** [drivers/scsi/aic7xxx] Error 2
> make[1]: *** [drivers/scsi] Error 2
> make: *** [drivers] Error 2
>...

This problem exists since 2.6.13-rc6-mm1, and Christoph said he wanted 
to fix it...

> by

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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...

2.6.13-mm1

[Andrew Morton]

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

 Subsystem trees
 
-preempt-race-in-getppid.patch
-tpm_infineon-bugfix-in-pnpacpi-handling.patch
-md-make-sure-resync-gets-started-when-array-starts.patch
-gregkh-usb-usb-zd1201-kmalloc-size-fix.patch
-export-machine_power_off-on-ppc64.patch
-usbnet-oops-fix.patch
-x86_64-dont-oops-at-boot-when-empty-opteron-node-has-io.patch
-git-acpi-ia64-fixes.patch
-git-acpi-ia64-fix-2.patch
-git-drm-drm_agpsupport-warning-fix.patch
-gregkh-i2c-i2c-hwmon-class-01.patch
-gregkh-i2c-w1-changed_default_netlink_group.patch
-apple-usb-touchpad-driver.patch
-negative-timer-loop-with-lots-of-ipv4-peers.patch
-ipw2100-cleanup-debug-prints.patch
-gregkh-pci-pci-must_check-attributes.patch
-git-scsi-misc-ibmvscsi-fix.patch
-git-scsi-misc-ibmvscsi-fix-fix.patch
-ppc32-fix-gcc4-warning-in-asm-ppc-timeh.patch
-ppc64-remove-nested-feature-sections.patch
-ppc64-allow-xmon=off.patch
-ppc64-four-level-pagetables.patch
-ppc64-four-level-pagetables-fix.patch
-ppc64-large-initrd-causes-kernel-not-to-boot.patch
-i386-fix-incorrect-fp-signal-delivery.patch
-x86_64-fix-numa-node-sizing-in-nr_free_zone_pages.patch
-i810_audio-fix-release_region-misordering-in-error-exit-from-i810_probe.patch
-race-condition-with-drivers-char-vtc-bug-in-vt_ioctlc.patch
-nfs-nfs3-page-null-fill-in-a-short-read-situation.patch # wait
-nfs-fix-xprt_bindresvport.patch
-8250-serial-console-locking-bug-spelling-fix.patch

 Merged

+non-booting-g5-fix.patch

 ppc64 G5 fix

+dvb-saa7134-dvb-must-select-tda1004x.patch

 DVB Kconfig fix

+tpm_infineon-bugfix-in-pnpacpi-handling.patch

 TPM fix

+gregkh-driver-driver-bind-fix.patch
+gregkh-driver-driver-link-device-and-class.patch

 Driver tree updates

-driver-core-fix-bus_rescan_devices-race.patch
+driver-core-fix-bus_rescan_devices-race-2.patch

 Updated

+git-audit-ppc64-fix.patch

 Fix git-audit.patch

+hiddev-output-reports-are-dropped-when-hidiocsreport-is.patch

 Some USB fix

+git-jfs-fixup.patch

 Fix rejects in git-jfs.patch

+ignore-all-debugging-info-sections-in-scripts-reference_discardedpl.patch

 reference_discarded.pl tweak

+fix-minor-bug-in-sungemh.patch

 Sungem fix

+netlink-log-protocol-failures.patch

 Netlink debugging

+git-nfs-oops-fix.patch

 Revert dud patch from git-nfs.patch

+gregkh-pci-pci-must_check-attributes.patch

 PCI tree update

+fix-klist-semantics-for-lists-which-have-elements-removed.patch

 klist fix for scsi usage

+git-scsi-misc-sr-fix.patch

 Fix git-scsi-misc.patch

+gregkh-usb-usb-add-apple-touchpad-driver.patch

 USB tree update

+watchdog-new-sbc8360-driver.patch

 Watchdog driver

+ppc64-fix-sparsemem-extreme.patch

 Fix sparsemem-extreme.patch

+swap-swap-unsigned-int-consistency-warning-fix.patch

 cleanup

-add-swap-cache-mapping-comment.patch
-remove-stale-comment-from-swapfilec.patch

 Were wrong

+arm-allow-for-arch-specific-ioremap_max_order.patch

 ARM fix (controversial)

+hugetlb-add-pte_huge-macro.patch
+hugetlb-move-stale-pte-check-into-huge_pte_alloc.patch
+hugetlb-check-pd_present-in-huge_pte_offset.patch
+remove-hugetlb_clean_stale_pgtable-and-fix-huge_pte_alloc.patch

 hugetlb updates

+slab-consolidate-kmem_bufctl_t.patch

 slab cleanup

+page-fault-patches-optional-page_lock-acquisition-in-nicety.patch

 Clean up pagefault scalability patches

+ppp_mppe-add-ppp-mppe-encryption-module-author-address-change.patch

 New email address

+mdio_bus_exit-in-discarded-section-textexit.patch

 mdio section fix

+generic-vfs-fallback-for-security-xattrs.patch

 SELinux stuff

+cpm_uart-use-schedule_timeout-instead-of-direct-call-to.patch
+cpm_uart-fix-baseaddress-for-smc-1-and-2.patch

 cpm_uart updates

+ppc32-disable-ibm405_err77-and-ibm405_err51-workarounds-for-405ep.patch
+ppc32-ppc_sys-system-on-chip-identification-additions.patch
+ppc32-add-config_hz.patch
+ppc32-add-support-for-marvell-ev64360bp-board.patch
+ppc32-defconfig-for-marvell-ev64360bp-board.patch
+ppc32-fix-wundef-warning-for-config_8xx.patch
+ppc32-added-pci-support-mpc83xx.patch
+ppc32-re-order-cputable-for-750cxe-dd24-entry.patch
+ppc32-add-cputable-entry-for-750cxe-dd24-gekko.patch
+ppc32-move-4xx-phy_mode_xxx-defines-to-ibm_ocph.patch
+ppc32-add-dcr_base-field-to-ocp_func_mal_data.patch
+ppc32-l2-cache-prefetch-fixes-on-745x.patch
+ppc32-export-cacheable_memcpy.patch

 ppc32 updates

+frv-remove-export-of-strtok.patch

 cleanup

+mips-fix-build-warnings.patch
+mips-remove-timexh-for-vr41xx.patch
+mips-kludge-envdev-to-build-for-64-bit-mips-with-32-bit-compat.patch

 MIPS updates

+es7000-platform-update-i386.patch

 es7k updates

+x86-add-mce-resume.patch
+pm-fix-process-freezing.patch
+pm-cleanup-sys-power-disk.patch

 PM updates

+uml-error-path-cleanup.patch
+uml-build-cleanup.patch
+uml-remove-libc-reference-in-build.patch
+uml-mark-smp-on-uml-x86_64-as-broken.patch
+uml-remove-duplicated-exports.patch
+uml-uml-i386-is-i386-when-running-on-x86_64.patch
+uml-tlb-operation-batching.patch
+uml-merge-duplicated-page-table-code.patch

 UML

+xtensa-replace-extern-inline-with-static-inline.patch
+xtensa-delete-accidental-file.patch

 xtensa arch

+s390-machine-check-handler-bugs.patch
+s390-debug-feature-changes.patch
+s390-deadlock-in-dasd_devmap.patch
+s390-64-bit-diag250-support.patch
+s390-reipl-fix-and-extern-static-inline.patch
+s390-pfault-interrupt-race.patch
+s390-crypto-driver-update.patch
+s390-compat-system-calls.patch
+s390-spinlock-corner-case.patch
+s390-disconnected-3270-console.patch

 s390 updates

+futex_wake_op-pthread_cond_signal-speedup.patch

 Futex feature work

+relayfs-relayfs_remove-fix.patch
+relayfs-upgraded-read-implementation.patch
+relayfs-update-documentation-fix.patch

 relayfs updates

-aio-add-enosys-into-sys_io_cancel.patch
-aio-kiocb-locking-to-serialise-retry-and-cancel.patch

 Dropped (I have it in a new AIO patch series but I took yet another look at
 all the AIO stuff and felt queasy)

+radix-tree-remove-unnecessary-indirections-and-clean-up.patch

 radix-tree simplifications

+auxiliary-vector-cleanups-fix.patch

 Fix auxiliary-vector-cleanups.patch

+dcdbas-add-dell-systems-management-base-driver-with-sysfs-support.patch

 Dell Systems Management Base Driver

+futex-remove-duplicate-code.patch

 Futex celanup

+additions-to-dataread_mostly-section.patch

 More read-mostly variables

+ntp-ntp-helper-functions.patch

 ntp cleanup

+blk-use-blk_queue_xxx-functions-to-set-parameters.patch

 block layer cleanup

+convert-proc-devices-to-use-seq_file-interface.patch
+convert-proc-devices-to-use-seq_file-interface-fix.patch

 seq_file conversion

+tty-layer-buffering-revamp.patch

 TTY buffering rewrite

+pipe-remove-redundant-fifo_poll-abstraction.patch

 pipe cleanup

+ibm-hdaps-accelerometer-driver-with-probing.patch

 HDAPS driver

+remove-verify_area-remove-verify_area-from-various-uaccessh-headers.patch
+remove-verify_area-remove-or-edit-references-to-verify_area-in-documentation.patch
+remove-verify_area-remove-fs-umsdos-notes-as-it-only-contain-a-verify_area-related-note.patch

 cleanups

+serial-console-touch-nmi-watchdog.patch

 Poke the NMI watchdog when spewing to the serial console.

+optimise-64bit-unaligned-access-on-32bit-kernel.patch

 Speedup

+vt-fix-possible-memory-corruption-in-complement_pos.patch

 vt driver fix

+hpet-fix-drift-and-url.patch

 hpet fix

+isdn_v110-warning-fix.patch

 Fix a warning

+tpm-fix-tpm_atmelc-on-ich6.patch

 TPM fix

+create-asm-generic-fcntlh.patch
+consildate-asm-ppc-fcntlh.patch

 fcntl.h consolidation

+clean-up-the-open-flags.patch
+clean-up-the-fcntl-operations.patch
+clean-up-struct-flock-definitions.patch
+clean-up-struct-flock64-definitions.patch
+consolidate-the-asm-ppc-fcntlh-files-into-asm-powerpc.patch

 More code was dirty

+inotify-fix-event-loss-on-hardlinked-files.patch

 inotify fix

+sunrpc-print-unsigned-integers-in-stats.patch

 sunrpc fixlet

+open-returns-enfile-but-creates-file-anyway.patch
+open-returns-enfile-but-creates-file-anyway-tidy.patch

 Fix open() behaviour

+block-cfq-refcounting-fix.patch

 CFQ fix

+remove-ia_attr_flags.patch
+namei-cleanup.patch
+use-get_fs_struct-in-proc.patch

 Cleanups

+fix-enum-pid_directory_inos-in-proc-basec.patch

 procfs fix

+remove-duplicated-code-from-proc-and-ptrace.patch
+remove-duplicated-sys_open32-code-from-64bit-archs.patch

 cleanups

+cifs_create-fix.patch

 CIFS fix

+deprecate-openfoo-3.patch

 Deprecate open("foo", 3) (old lilo's trigger this)

+fix-reboot-via-keyboard-controller-reset.patch

 Make reboots work better with some keyboard controllers

+fix-dmi_check_system.patch

 DMI fix

+mmc-conditional-scr-sysfs-entry.patch

 MMC fix

-smsc-ircc2-pm-cleanup-do-not-close-device-when-suspending-fixes.patch

 Folded into smsc-ircc2-pm-cleanup-do-not-close-device-when-suspending.patch

+kprobes-fix-handling-of-simultaneous-probe-hit-unregister.patch

 kprobes fix

+pcmcia-yenta-dont-mess-with-bridge-control-register.patch
+pcmcia-remove-unused-client_t.patch
+pcmcia-remove-unused-vpp1-vpp2-and-vcc.patch
+pcmcia-omap-cf-controller.patch
+pcmcia-more-ids-for-ide_cs.patch
+pcmcia-add-pcmcia-to-irq-information.patch

 pcmcia/cardbus updates

+nfs-nfs3-page-null-fill-in-a-short-read-situation.patch

 NFS fix

+sched-less-newidle-locking.patch
+sched-less-locking.patch
+sched-ht-optimisation.patch

 CPU scheduler updates

-sched-dont-kick-alb-in-the-presence-of-pinned-task-fix.patch

 Folded into sched-dont-kick-alb-in-the-presence-of-pinned-task.patch

+reiser4-fix-wundef-warnings.patch

 reiser4 wranings

+v9fs-documentation-makefiles-configuration-fix-plan9port-example-in-v9fs.patch
+v9fs-vfs-inode-operations-adjust-follow_link-and-put_link-to.patch
+v9fs-9p-protocol-implementation-use-standard-kernel-byteswapping.patch
+v9fs-9p-protocol-implementation-remove-sparse-bitwise-warnings.patch
+v9fs-transport-modules-fix-a-problem-with-named-pipe-transport.patch
+v9fs-transport-modules-cleanup-fd-transport.patch
+v9fs-support-to-force-umount.patch
+v9fs-readlink-extended-mode-check.patch
+v9fs-fix-handling-of-malformed-9p-messages.patch

 v9fs updates

+ide-clean-up-the-garbage-in-eighty_ninty_three.patch

 IDE cleanup

+matroxfb-read-mga-pins-data-on-powerpc.patch
+sisfb-update.patch
+better-error-handing-in-savagefb_probe.patch
+framebuffer-new-driver-for-cyberblade-i1-graphics.patch
+framebuffer-bit_putcs-optimization-for-8x.patch
+radeonfb-only-request-resources-we-need.patch

 fbdev updates

+md-remove-old-cruft-from-md_kh-header-file.patch
+md-limit-size-of-sb-read-written-to-appropriate-amount.patch
+md-add-write-intent-bitmap-support-to-raid5.patch
+md-write-intent-bitmap-support-for-raid6.patch
+md-use-kthread-infrastructure-in-md.patch
+md-ensure-bitmap_writeback_daemon-handles-shutdown-properly.patch
+md-tidy-up-daemon-stop-start-code-in-md-bitmapc.patch

 RAID updates

+docbook-fix-kernel-api-documentation-generation.patch
+kdump-documentation-update.patch
+vfs-update-documentation.patch

 Documentation updates

+fuse-read-only-operations-follow_link-fix.patch

 FUSE fix



All 1126 patches:


ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/patch-list

Re: 2.6.13-mm1

[Martin J. Bligh]

Breaks build on PPC64

Lots of this:

In file included from fs/xfs/linux-2.6/xfs_linux.h:57,
                 from fs/xfs/xfs.h:35,
                 from fs/xfs/xfs_rtalloc.c:37:
fs/xfs/xfs_arch.h:55:21: warning: "__LITTLE_ENDIAN" is not defined
In file included from fs/xfs/xfs_rtalloc.c:50:
fs/xfs/xfs_bmap_btree.h:65:21: warning: "__LITTLE_ENDIAN" is not defined
  CC      fs/xfs/xfs_acl.o
In file included from fs/xfs/linux-2.6/xfs_linux.h:57,
                 from fs/xfs/xfs.h:35,
                 from fs/xfs/xfs_acl.c:33:
fs/xfs/xfs_arch.h:55:21: warning: "__LITTLE_ENDIAN" is not defined

Can't see anything obvious to cause that.
Then this:

CC      drivers/char/hvc_console.o
drivers/char/hvc_console.c: In function `hvc_poll':
drivers/char/hvc_console.c:600: error: `count' undeclared (first use in this function)
drivers/char/hvc_console.c:600: error: (Each undeclared identifier is reported only once
drivers/char/hvc_console.c:600: error: for each function it appears in.)
drivers/char/hvc_console.c:636: error: structure has no member named `flip'
make[2]: *** [drivers/char/hvc_console.o] Error 1
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2

Presumably this:

diff -puN drivers/char/hvc_console.c~tty-layer-buffering-revamp drivers/char/hvc
_console.c
--- 25/drivers/char/hvc_console.c~tty-layer-buffering-revamp    Wed Aug 31 12:50
:55 2005
+++ 25-akpm/drivers/char/hvc_console.c  Wed Aug 31 12:50:56 2005
@@ -597,10 +597,8 @@ static int hvc_poll(struct hvc_struct *h
 
        /* Read data if any */
        for (;;) {
-               int count = N_INBUF;
-               if (count > (TTY_FLIPBUF_SIZE - tty->flip.count))
-                       count = TTY_FLIPBUF_SIZE - tty->flip.count;
-
+               count = tty_buffer_request_room(tty, N_INBUF);
+               
                /* If flip is full, just reschedule a later read */
                if (count == 0) {
                        poll_mask |= HVC_POLL_READ;

shouldn't be deleting the declaration of count. 

and possibly the "flip removal" was incomplete (line 636) ???

Re: 2.6.13-mm1

[Alan Cox]

On Thu, Sep 01, 2005 at 07:22:53AM -0700, Martin J. Bligh wrote:
> -               if (count > (TTY_FLIPBUF_SIZE - tty->flip.count))
> -                       count = TTY_FLIPBUF_SIZE - tty->flip.count;
> -
> +               count = tty_buffer_request_room(tty, N_INBUF);
> +               

Should be "int count = " yes

>                 /* If flip is full, just reschedule a later read */
>                 if (count == 0) {
>                         poll_mask |= HVC_POLL_READ;
> 
> shouldn't be deleting the declaration of count. 
> and possibly the "flip removal" was incomplete (line 636) ???

Yep. You can remove the tty->flip.count test or use count, but at that
point count is guaranteed to be > 0 I believe. Fixed both in my tree will
push a new diff to Andre soon.

Also if you are tidying up all the 'read 64 chars and take a break' stuff
should just go away. The kernel will buffer large chunks of data for you
now. In the ideal case if you know the total pending space you can do

	int len = tty_buffer_request_room(tty, len)

and it'll look to kmalloc a big enough buffer for you if the buffer pool
isn't suitable. Even if that fails (its a hint) the tty layer will split the
data across multiple smaller buffers for you when you use tty_insert_flip_*

So you should be able to just ram data at it as it comes off the hvc.

Alan

Re: 2.6.13-mm1

[Joel Schopp]

>>                /* If flip is full, just reschedule a later read */
>>                if (count == 0) {
>>                        poll_mask |= HVC_POLL_READ;
>>
>>shouldn't be deleting the declaration of count. 
>>and possibly the "flip removal" was incomplete (line 636) ???
> 
> 
> Yep. You can remove the tty->flip.count test or use count, but at that
> point count is guaranteed to be > 0 I believe. Fixed both in my tree will
> push a new diff to Andre soon.

There are at least a couple other spots where flip got missed, after 
fixing the count and flip problem mentioned these come up:

drivers/char/hvcs.c:459: error: structure has no member named `flip'
drivers/char/hvcs.c:472: error: structure has no member named `flip'

Re: 2.6.13-mm1

[Alan Cox]

On Thu, Sep 01, 2005 at 03:56:08PM -0500, Joel Schopp wrote:
> There are at least a couple other spots where flip got missed, after 
> fixing the count and flip problem mentioned these come up:
> 
> drivers/char/hvcs.c:459: error: structure has no member named `flip'
> drivers/char/hvcs.c:472: error: structure has no member named `flip'

Try the diff below although I suspect much of the extra logic can go
away and something like

	len = tty_buffer_request_root(tty, HVCS_BUFF_LEN);
	if(len) {
		len = hvc_get_chars(...., len);
		tty_insert_flip_string(tty, buf, len);
	}

is better.


--- drivers/char/hvcs.c~	2005-09-01 22:08:42.205515648 +0100
+++ drivers/char/hvcs.c	2005-09-01 22:08:42.206515496 +0100
@@ -456,12 +456,11 @@
 	/* remove the read masks */
 	hvcsd->todo_mask &= ~(HVCS_READ_MASK);
 
-	if ((tty->flip.count + HVCS_BUFF_LEN) < TTY_FLIPBUF_SIZE) {
+	if (tty_buffer_request_room(tty, HVCS_BUFF_LEN) >= HVCS_BUFF_LEN) {
 		got = hvc_get_chars(unit_address,
 				&buf[0],
 				HVCS_BUFF_LEN);
-		for (i=0;got && i<got;i++)
-			tty_insert_flip_char(tty, buf[i], TTY_NORMAL);
+		tty_insert_flip_string(tty, buf, got);
 	}
 
 	/* Give the TTY time to process the data we just sent. */
@@ -469,10 +468,9 @@
 		hvcsd->todo_mask |= HVCS_QUICK_READ;
 
 	spin_unlock_irqrestore(&hvcsd->lock, flags);
-	if (tty->flip.count) {
-		/* This is synch because tty->low_latency == 1 */
+	/* This is synch because tty->low_latency == 1 */
+	if(got)
 		tty_flip_buffer_push(tty);
-	}
 
 	if (!got) {
 		/* Do this _after_ the flip_buffer_push */

Re: 2.6.13-mm1

[Joel Schopp]

> Try the diff below although I suspect much of the extra logic can go
> away and something like
> 
> 	len = tty_buffer_request_root(tty, HVCS_BUFF_LEN);
> 	if(len) {
> 		len = hvc_get_chars(...., len);
> 		tty_insert_flip_string(tty, buf, len);
> 	}
> 
> is better.

It's like whack a mole.  30 more now in drivers/serial/jsm/jsm_tty.c and 
  drivers/serial/icom.c

Re: 2.6.13-mm1

[Alan Cox]

On Thu, Sep 01, 2005 at 04:26:02PM -0500, Joel Schopp wrote:
> It's like whack a mole.  30 more now in drivers/serial/jsm/jsm_tty.c and 
>  drivers/serial/icom.c

I've been whacking moles for some time doing all those I can. the jsm_tty
code needs major surgery and its bad it ever got into the kernel as most of
the code is duplicating chunks of the tty layer and working around it. The
jsm stuff is unintelligible and the docs dont appear to be public.

I'll take a look at icom.c now. I notice at least one bug already that
should be dealt with - the existing code assumes that tty->flip.char_buf_ptr[0]
is the first it inserted this time which may not be true as far as I can see.
And it looks there if count was 0 so its undefined.. 

Assuming it means the first char this block then the following should do
the trick, but really someone who knows wtf that code is trying to do needs
to fix it - please review/test/let me know.


--- drivers/serial/icom.c~	2005-09-01 22:37:16.986829264 +0100
+++ drivers/serial/icom.c	2005-09-01 22:37:16.986829264 +0100
@@ -737,6 +737,7 @@
 
 	status = cpu_to_le16(icom_port->statStg->rcv[rcv_buff].flags);
 	while (status & SA_FL_RCV_DONE) {
+		int first = -1;
 
 		trace(icom_port, "FID_STATUS", status);
 		count = cpu_to_le16(icom_port->statStg->rcv[rcv_buff].leLength);
@@ -751,15 +752,17 @@
 			icom_port->recv_buf_pci;
 
 		/* Block copy all but the last byte as this may have status */
-		if(count > 0)
+		if(count > 0) {
+			first = icon->recv_buf[offset];
 			tty_insert_flip_string(tty, icon_port->recv_buf + offset, count - 1);
+		}
 
 		icount = &icom_port->uart_port.icount;
 		icount->rx += count;
 
 		/* Break detect logic */
 		if ((status & SA_FLAGS_FRAME_ERROR)
-		    && (tty->flip.char_buf_ptr[0] == 0x00)) {
+		    && first == 0) {
 			status &= ~SA_FLAGS_FRAME_ERROR;
 			status |= SA_FLAGS_BREAK_DET;
 			trace(icom_port, "BREAK_DET", 0);



Keep whacking - obviously I don't have a PPC64 (*and please don't send me one*)



Alan

Re: 2.6.13-mm1

[serue]

Hmm, this patch itself seems to have a few typos, but so does
the 2.6.13-mm{1,2,3}.

Quoting Alan Cox (alan@redhat.com):
> --- drivers/serial/icom.c~	2005-09-01 22:37:16.986829264 +0100
> +++ drivers/serial/icom.c	2005-09-01 22:37:16.986829264 +0100
> @@ -737,6 +737,7 @@
>  
>  	status = cpu_to_le16(icom_port->statStg->rcv[rcv_buff].flags);
>  	while (status & SA_FL_RCV_DONE) {
> +		int first = -1;
>  
>  		trace(icom_port, "FID_STATUS", status);
>  		count = cpu_to_le16(icom_port->statStg->rcv[rcv_buff].leLength);
> @@ -751,15 +752,17 @@
>  			icom_port->recv_buf_pci;
>  
>  		/* Block copy all but the last byte as this may have status */
> -		if(count > 0)
> +		if(count > 0) {
> +			first = icon->recv_buf[offset];
	s/icon/icom_port/ ?

>  			tty_insert_flip_string(tty, icon_port->recv_buf + offset, count - 1);

	s/icon_port/icom_port/ ?

> +		}
>  
>  		icount = &icom_port->uart_port.icount;
>  		icount->rx += count;
>  
>  		/* Break detect logic */
>  		if ((status & SA_FLAGS_FRAME_ERROR)
> -		    && (tty->flip.char_buf_ptr[0] == 0x00)) {
> +		    && first == 0) {
>  			status &= ~SA_FLAGS_FRAME_ERROR;
>  			status |= SA_FLAGS_BREAK_DET;
>  			trace(icom_port, "BREAK_DET", 0);

And in 2.6.13-mm3, we have:

@@ -798,33 +792,26 @@ static void recv_interrupt(u16 port_int_
 			status &= icom_port->read_status_mask;
 
 			if (status & SA_FLAGS_BREAK_DET) {
-				*tty->flip.flag_buf_ptr = TTY_BREAK;
+				flag = TTY_BREAK;
 			} else if (status & SA_FLAGS_PARITY_ERROR) {
 				trace(icom_port, "PARITY_ERROR", 0);
-				*tty->flip.flag_buf_ptr = TTY_PARITY;
+				flag = TTY_PARITY;
 			} else if (status & SA_FLAGS_FRAME_ERROR)
-				*tty->flip.flag_buf_ptr = TTY_FRAME;
+				flag = TTY_FRAME;
 
-			if (status & SA_FLAGS_OVERRUN) {
-				/*
-				 * Overrun is special, since it's
-				 * reported immediately, and doesn't
-				 * affect the current character
-				 */
-				if (tty->flip.count < TTY_FLIPBUF_SIZE) {
-					tty->flip.count++;
-					tty->flip.flag_buf_ptr++;
-					tty->flip.char_buf_ptr++;
-					*tty->flip.flag_buf_ptr = TTY_OVERRUN;
-				}
-			}
 		}
 
-		tty->flip.flag_buf_ptr++;
-		tty->flip.char_buf_ptr++;
-		tty->flip.count++;
-		ignore_char:
-			icom_port->statStg->rcv[rcv_buff].flags = 0;
+		tty_insert_flip_char(tty, icon_port->recv_buf + offset + count - 1, flag);
		^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Is this meant to be
	tty_insert_flip_char(tty, *(icon_port->recv_buf + offset + count - 1), flag);
?

+
+		if (status & SA_FLAGS_OVERRUN)
+			/*
+			 * Overrun is special, since it's
+			 * reported immediately, and doesn't
+			 * affect the current character
+			 */
+			tty_insert_flip_char(tty, 0, TTY_OVERRUN);
+ignore_char:
+		icom_port->statStg->rcv[rcv_buff].flags = 0;
 		icom_port->statStg->rcv[rcv_buff].leLength = 0;
 		icom_port->statStg->rcv[rcv_buff].WorkingLength =
 			(unsigned short int) cpu_to_le16(RCV_BUFF_SZ);

Again, sorry I didn't catch this back in -mm1 or -mm2...

thanks,
-serge

Re: 2.6.13-mm1

[Adrian Bunk]

On Thu, Sep 01, 2005 at 07:22:53AM -0700, Martin J. Bligh wrote:
>...
> Lots of this:
> 
> In file included from fs/xfs/linux-2.6/xfs_linux.h:57,
>                  from fs/xfs/xfs.h:35,
>                  from fs/xfs/xfs_rtalloc.c:37:
> fs/xfs/xfs_arch.h:55:21: warning: "__LITTLE_ENDIAN" is not defined
> In file included from fs/xfs/xfs_rtalloc.c:50:
> fs/xfs/xfs_bmap_btree.h:65:21: warning: "__LITTLE_ENDIAN" is not defined
>   CC      fs/xfs/xfs_acl.o
> In file included from fs/xfs/linux-2.6/xfs_linux.h:57,
>                  from fs/xfs/xfs.h:35,
>                  from fs/xfs/xfs_acl.c:33:
> fs/xfs/xfs_arch.h:55:21: warning: "__LITTLE_ENDIAN" is not defined
> 
> Can't see anything obvious to cause that.
>...

They are there since we added -Wundef to the CFLAGS several -mm kernels 
ago.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.13-mm1

[Dominik Karall]

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

On Thursday 01 September 2005 12:55, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13
>-mm1/

When I switch on my external harddisk, which is connected through usb, the 
kernel hangs. First time I did that at bootup there were a lot of backtraces 
printed on the screen but they did not find the way in the logfile :/
Now I switched the drive on while running and everything freezes after those 
messages:

usb 1-2.2: new high speed USB device using ehci_hcd and address 3
scsi2 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 3
usb-storage: waiting for device to settle before scanning
  Vendor: ST325082  Model: 3A                Rev: 3.02
  Type:   Direct-Access                      ANSI SCSI revision: 00
SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
sda: assuming drive cache: write through
SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
sda: assuming drive cache: write through

dominik

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

Re: 2.6.13-mm1

[John Stoffel]

>>>>> "Dominik" == Dominik Karall <dominik.karall@gmx.net> writes:

Dominik> When I switch on my external harddisk, which is connected
Dominik> through usb, the kernel hangs. First time I did that at
Dominik> bootup there were a lot of backtraces printed on the screen
Dominik> but they did not find the way in the logfile :/ Now I
Dominik> switched the drive on while running and everything freezes
Dominik> after those messages:

Dominik> usb 1-2.2: new high speed USB device using ehci_hcd and address 3
Dominik> scsi2 : SCSI emulation for USB Mass Storage devices
Dominik> usb-storage: device found at 3
Dominik> usb-storage: waiting for device to settle before scanning
Dominik>   Vendor: ST325082  Model: 3A                Rev: 3.02
Dominik>   Type:   Direct-Access                      ANSI SCSI revision: 00
Dominik> SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
Dominik> sda: assuming drive cache: write through
Dominik> SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
Dominik> sda: assuming drive cache: write through

Have you updated the firmware on the USB enclosure?  I have one using
the Prolific chipset for both USB/Firewire and it was crappy until I
upgraded the firmware on there.  It made all the difference.  

Also, can you use this USB enclosure on Windows or another computer?
And which kernel version are you running?  It's not clear if your on
2.6.13-mm1 or some other version.  

More details would be good too, such as:

	lsusb
	cat /proc/version
	

What happens if you unplug the drive when the system hangs?  Does it
recover?  And try powering up the enclosure without it being hooked to
anything, then once 30 seconds have passed, hook it upto the Linux box
and see what happens then.  Maybe the power on stuff is doing strange
things.

John

Re: 2.6.13-mm1

[Dominik Karall]

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

On Thursday 01 September 2005 18:09, John Stoffel wrote:
> >>>>> "Dominik" == Dominik Karall <dominik.karall@gmx.net> writes:
>
> Dominik> When I switch on my external harddisk, which is connected
> Dominik> through usb, the kernel hangs. First time I did that at
> Dominik> bootup there were a lot of backtraces printed on the screen
> Dominik> but they did not find the way in the logfile :/ Now I
> Dominik> switched the drive on while running and everything freezes
> Dominik> after those messages:
>
> Dominik> usb 1-2.2: new high speed USB device using ehci_hcd and address 3
> Dominik> scsi2 : SCSI emulation for USB Mass Storage devices
> Dominik> usb-storage: device found at 3
> Dominik> usb-storage: waiting for device to settle before scanning
> Dominik>   Vendor: ST325082  Model: 3A                Rev: 3.02
> Dominik>   Type:   Direct-Access                      ANSI SCSI revision:
> 00 Dominik> SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
> Dominik> sda: assuming drive cache: write through
> Dominik> SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
> Dominik> sda: assuming drive cache: write through
>
> Have you updated the firmware on the USB enclosure?  I have one using
> the Prolific chipset for both USB/Firewire and it was crappy until I
> upgraded the firmware on there.  It made all the difference.
>
> Also, can you use this USB enclosure on Windows or another computer?
> And which kernel version are you running?  It's not clear if your on
> 2.6.13-mm1 or some other version.

2.6.13-mm1, as mentioned in subject.
The external hdd worked with 2.6.13-rc6-mm1 and 2.6.13-ck1, which were the 
last versions I ran. Didn't test 2.6.13-rc6-mm2.

> More details would be good too, such as:
>
> 	lsusb

Bus 001 Device 004: ID 0840:009c Argosy Research, Inc.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x0840 Argosy Research, Inc.
  idProduct          0x009c
  bcdDevice            0.01
  iManufacturer           1 Generic
  iProduct                2 USB 2.0 Mass Storage Device
  iSerial                 3 009C0000000049BD
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk (Zip)
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  bNumConfigurations      1


dominik

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

Re: 2.6.13-mm1

[John Stoffel]

Dominik,

So what is the chipset inside the enclosure?  Looking at your output,
the 'Argosy' stuff doesn't tell me anything.  You might have to open
up the case to look in there to find more details.  

Again, check with your vendor and see if there is newer firmware.  And
have you powered up the device without having it plugged into the
system, then plug it in?  What happens then?

John

Re: 2.6.13-mm1

[Dominik Karall]

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

On Thursday 01 September 2005 19:34, John Stoffel wrote:
> Dominik,
>
> So what is the chipset inside the enclosure?  Looking at your output,
> the 'Argosy' stuff doesn't tell me anything.  You might have to open
> up the case to look in there to find more details.
>
> Again, check with your vendor and see if there is newer firmware.  And
> have you powered up the device without having it plugged into the
> system, then plug it in?  What happens then?

Why should I check for newer firmware!? I don't understand that point of view. 
The device works without any problems with 2.6.13-ck1 as 2.6.13-rc6-mm1 and 
before kernels. So there is no need to check the firmware imho.

I don't think that it makes any difference if I power up first or plug in 
first. The device is recognized when I power it on, so it would be the same 
when I power it on and connect after that imho.

I will try to get the backtraces from the kernel, this should make debugging 
easier.

greets,
dominik

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

Re: 2.6.13-mm1

[John Stoffel]

Dominik> Why should I check for newer firmware!? I don't understand
Dominik> that point of view.  The device works without any problems
Dominik> with 2.6.13-ck1 as 2.6.13-rc6-mm1 and before kernels. So
Dominik> there is no need to check the firmware imho.

That's on point of view.  In my experience, it simplifies debugging to
make sure the unit is at the latest firmware, since bugs in the
enclosure's IDE driver could be causing the problem.  As I said
before, when my enclosure was upgraded, all my problems went away.  

So that's why I was asking you to make sure your firmware was upto
date.  Is that so hard to understand?  

Dominik> I don't think that it makes any difference if I power up
Dominik> first or plug in first. The device is recognized when I power
Dominik> it on, so it would be the same when I power it on and connect
Dominik> after that imho.

Sure it can make a difference.  If the enclosure puts out crap signals
on the USB bus when it's powered up, and the older versions of the
Linux kernel dealt with them because of an oversight, but now we're
closer to the USB specs... it could the issue.  

In any case, it's a *simple* test to do, unless you're not physically
at the system with this device, or if you can't be bothered to:

1. unplug enclosure from USB.
2. power it off.
3. power it on.
4. wait 30 seconds.
5. plug in the USB cable.
6. what happens?

That tells us useful stuff.  

Dominik> I will try to get the backtraces from the kernel, this should
Dominik> make debugging easier.

That will help people debug this for sure.

In any case, I'm not going to be much help from here on.

Re: 2.6.13-mm1

[Benjamin LaHaise]

On Thu, Sep 01, 2005 at 03:55:42AM -0700, Andrew Morton wrote:
>  Dropped (I have it in a new AIO patch series but I took yet another look at
>  all the AIO stuff and felt queasy)

What's the nature of the queasiness?  Is it something that can be addressed 
by rewriting the patches, or just general worries about adding another 
feature?  The status quo is not acceptable.

		-ben

Re: 2.6.13-mm1

[Andrew Morton]

Benjamin LaHaise <bcrl@linux.intel.com> wrote:
>
> On Thu, Sep 01, 2005 at 03:55:42AM -0700, Andrew Morton wrote:
> >  Dropped (I have it in a new AIO patch series but I took yet another look at
> >  all the AIO stuff and felt queasy)
> 
> What's the nature of the queasiness?  Is it something that can be addressed 
> by rewriting the patches, or just general worries about adding another 
> feature?  The status quo is not acceptable.
> 

Cons:

- Additional arguments to various fastpath functions

- Additional code size

- Additional code complexity

- Significantly degrades collective understanding of how the VFS works.

Pros:

- Unclear.

Re: 2.6.13-mm1

[Benjamin LaHaise]

On Fri, Sep 02, 2005 at 01:57:35PM -0700, Andrew Morton wrote:
> Cons:
> 
> - Additional arguments to various fastpath functions

One possibility is to split the async and sync versions by way of inline 
functions.  That will result in more icache pressure, though, which makes 
it a questionable optimization.

> - Additional code size
> 
> - Additional code complexity

These are general concerns of all new features.  It is possible to split 
the code out into separate codepaths (the 2.4 async read/write paths were 
completely new), but that cuts down on code sharing between the traditional 
sync read/writes and async code.  If that is a requirement for merging, 
then they certainly could be split out and grown in a separate aio module, 
but that leads to other maintenence headches.

The flip side of this question is that we already have O_DIRECT and all of 
its associated overhead, yet the vast majority of systems don't use it in 
the course of day to day operation.  Maybe we should have config options 
for these things, but where does the line get drawn?

> - Significantly degrades collective understanding of how the VFS works.

That can be improved through the use of debugging options to teach people 
that aio_* functions should not block, which is the only real difference 
between async and non-async functions -- if you'd block, return -EIOCBRETRY 
instead.

> Pros:
> 
> - Unclear.

We already have a number of users demanding buffered filesystem aio -- the 
UML patches to use aio just went in.  Samba is able to make use of aio.  
There are lots of high performance server applications which require aio 
and filesystem caching (think iSCSI servers, web servers/caches).  Right 
now the only way to do that is via threads, which brings into play a lot 
of other overhead.  AIO is one of the last areas in which we don't provide 
a suitable implementation for use in normal applications, only highly 
specialised database users.

		-ben

Re: 2.6.13-mm1

[Alexander Nyberg]

On Thu, Sep 01, 2005 at 03:55:42AM -0700 Andrew Morton wrote:

> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/
> 

i386-boottime-for_each_cpu-broken.patch
i386-boottime-for_each_cpu-broken-fix.patch

The SMP version of __alloc_percpu checks the cpu_possible_map
before allocating memory for a certain cpu. With the above patches
the BSP cpuid is never set in cpu_possible_map which breaks CONFIG_SMP
on uniprocessor machines (as soon as someone tries to dereference
something allocated via __alloc_percpu, which in fact is never allocated
since the cpu is not set in cpu_possible_map).

The below fixes this, I'm not entirely sure about the voyager
part, should the cpu_possible_map really be CPU_MASK_ALL to begin
with there, Zwane?

Signed-off-by: Alexander Nyberg <alexn@telia.com>

Index: mm/arch/i386/kernel/smpboot.c
===================================================================
--- mm.orig/arch/i386/kernel/smpboot.c	2005-09-02 15:28:20.000000000 +0200
+++ mm/arch/i386/kernel/smpboot.c	2005-09-02 16:16:46.000000000 +0200
@@ -1265,6 +1265,7 @@
 	cpu_set(smp_processor_id(), cpu_online_map);
 	cpu_set(smp_processor_id(), cpu_callout_map);
 	cpu_set(smp_processor_id(), cpu_present_map);
+	cpu_set(smp_processor_id(), cpu_possible_map);
 	per_cpu(cpu_state, smp_processor_id()) = CPU_ONLINE;
 }
 
Index: mm/arch/i386/mach-voyager/voyager_smp.c
===================================================================
--- mm.orig/arch/i386/mach-voyager/voyager_smp.c	2005-09-02 15:28:20.000000000 +0200
+++ mm/arch/i386/mach-voyager/voyager_smp.c	2005-09-02 16:17:29.000000000 +0200
@@ -1910,6 +1910,7 @@
 {
 	cpu_set(smp_processor_id(), cpu_online_map);
 	cpu_set(smp_processor_id(), cpu_callout_map);
+	cpu_set(smp_processor_id(), cpu_possible_map);
 }
 
 int __devinit

Re: 2.6.13-mm1

[Zwane Mwaikambo]

On Fri, 2 Sep 2005, Alexander Nyberg wrote:

> On Thu, Sep 01, 2005 at 03:55:42AM -0700 Andrew Morton wrote:
> 
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/
> > 
> 
> i386-boottime-for_each_cpu-broken.patch
> i386-boottime-for_each_cpu-broken-fix.patch
> 
> The SMP version of __alloc_percpu checks the cpu_possible_map
> before allocating memory for a certain cpu. With the above patches
> the BSP cpuid is never set in cpu_possible_map which breaks CONFIG_SMP
> on uniprocessor machines (as soon as someone tries to dereference
> something allocated via __alloc_percpu, which in fact is never allocated
> since the cpu is not set in cpu_possible_map).

Yes indeed, if there is no mptable or madt we would have missed setting 
it.

> The below fixes this, I'm not entirely sure about the voyager
> part, should the cpu_possible_map really be CPU_MASK_ALL to begin
> with there, Zwane?

I wanted to avoid breaking it wholesale and since i don't entirely 
understand the voyager SMP boot sequence, i opted for the safe method. 
cpu_possible_map is fine because it's supposed to cover all possible 
processors, upto NR_CPUS. 

> Signed-off-by: Alexander Nyberg <alexn@telia.com>

Thanks Alex,

Acked-by: Zwane Mwaikambo <zwane@arm.linux.org.uk>

> Index: mm/arch/i386/kernel/smpboot.c
> ===================================================================
> --- mm.orig/arch/i386/kernel/smpboot.c	2005-09-02 15:28:20.000000000 +0200
> +++ mm/arch/i386/kernel/smpboot.c	2005-09-02 16:16:46.000000000 +0200
> @@ -1265,6 +1265,7 @@
>  	cpu_set(smp_processor_id(), cpu_online_map);
>  	cpu_set(smp_processor_id(), cpu_callout_map);
>  	cpu_set(smp_processor_id(), cpu_present_map);
> +	cpu_set(smp_processor_id(), cpu_possible_map);
>  	per_cpu(cpu_state, smp_processor_id()) = CPU_ONLINE;
>  }
>  
> Index: mm/arch/i386/mach-voyager/voyager_smp.c
> ===================================================================
> --- mm.orig/arch/i386/mach-voyager/voyager_smp.c	2005-09-02 15:28:20.000000000 +0200
> +++ mm/arch/i386/mach-voyager/voyager_smp.c	2005-09-02 16:17:29.000000000 +0200
> @@ -1910,6 +1910,7 @@
>  {
>  	cpu_set(smp_processor_id(), cpu_online_map);
>  	cpu_set(smp_processor_id(), cpu_callout_map);
> +	cpu_set(smp_processor_id(), cpu_possible_map);
>  }
>  
>  int __devinit
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: 2.6.13-mm1

[Adrian Bunk]

Hi Andrew,

it seems you dropped 
schedule-obsolete-oss-drivers-for-removal-version-2.patch, but there's 
zero mentioning of this dropping in the changelog of 2.6.13-mm1.

Can you explain why you did silently drop it?

TIA
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.13-mm1

[Andrew Morton]

Adrian Bunk <bunk@stusta.de> wrote:
>
> Hi Andrew,
> 
> it seems you dropped 
> schedule-obsolete-oss-drivers-for-removal-version-2.patch, but there's 
> zero mentioning of this dropping in the changelog of 2.6.13-mm1.
> 
> Can you explain why you did silently drop it?
> 

It spat rejects and when I looked at the putative removal date I just
didn't believe it anyway.  Send a rediffed one if you like, but
October 2005 is unrealistic.

Re: 2.6.13-mm1

[Adrian Bunk]

On Sat, Sep 03, 2005 at 12:34:10PM -0700, Andrew Morton wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > Hi Andrew,
> > 
> > it seems you dropped 
> > schedule-obsolete-oss-drivers-for-removal-version-2.patch, but there's 
> > zero mentioning of this dropping in the changelog of 2.6.13-mm1.
> > 
> > Can you explain why you did silently drop it?
> 
> It spat rejects and when I looked at the putative removal date I just
> didn't believe it anyway.  Send a rediffed one if you like, but
> October 2005 is unrealistic.

That the date is no longer realistic is clear. What disappoints me is 
that you didn't mention in the changelog of 2.6.13-mm1 where I'd have 
noticed it.

It semms I need my own bookkeeping of patches I sent that are in -mm to 
notice when they get lost. The only positive side effect of this is that 
I can use this to push you harder to forward some patches of me to Linus 
that stay unforwarded in -mm for several months...

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.13-mm1

[Andrew Morton]

Adrian Bunk <bunk@stusta.de> wrote:
>
> On Sat, Sep 03, 2005 at 12:34:10PM -0700, Andrew Morton wrote:
> > Adrian Bunk <bunk@stusta.de> wrote:
> > >
> > > Hi Andrew,
> > > 
> > > it seems you dropped 
> > > schedule-obsolete-oss-drivers-for-removal-version-2.patch, but there's 
> > > zero mentioning of this dropping in the changelog of 2.6.13-mm1.
> > > 
> > > Can you explain why you did silently drop it?
> > 
> > It spat rejects and when I looked at the putative removal date I just
> > didn't believe it anyway.  Send a rediffed one if you like, but
> > October 2005 is unrealistic.
> 
> That the date is no longer realistic is clear. What disappoints me is 
> that you didn't mention in the changelog of 2.6.13-mm1 where I'd have 
> noticed it.

Sometimes I can't be bothered getting into email threads over relatively
unimportant stuff.  Usually it's related to the number of bugs we have.

> It semms I need my own bookkeeping of patches I sent that are in -mm to 
> notice when they get lost.

This is called "quilt".

> The only positive side effect of this is that 
> I can use this to push you harder to forward some patches of me to Linus 
> that stay unforwarded in -mm for several months...

A single release cycle is 2-3 months.

I'll probably be dropping some of the patches which unexport symbols, btw. 
ANy ones which aren't really, really obvious.  We have a process for this.

Re: 2.6.13-mm1

[Adrian Bunk]

On Sat, Sep 03, 2005 at 01:06:32PM -0700, Andrew Morton wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > On Sat, Sep 03, 2005 at 12:34:10PM -0700, Andrew Morton wrote:
> > > Adrian Bunk <bunk@stusta.de> wrote:
> > > >
> > > > Hi Andrew,
> > > > 
> > > > it seems you dropped 
> > > > schedule-obsolete-oss-drivers-for-removal-version-2.patch, but there's 
> > > > zero mentioning of this dropping in the changelog of 2.6.13-mm1.
> > > > 
> > > > Can you explain why you did silently drop it?
> > > 
> > > It spat rejects and when I looked at the putative removal date I just
> > > didn't believe it anyway.  Send a rediffed one if you like, but
> > > October 2005 is unrealistic.
> > 
> > That the date is no longer realistic is clear. What disappoints me is 
> > that you didn't mention in the changelog of 2.6.13-mm1 where I'd have 
> > noticed it.
> 
> Sometimes I can't be bothered getting into email threads over relatively
> unimportant stuff.  Usually it's related to the number of bugs we have.

This is not about email threads.

You send a changelog when you announce a new -mm kernel.
Why didn't you simply mention that you dropped this patch due to rejects 
in the changelog you are sending?

> > It semms I need my own bookkeeping of patches I sent that are in -mm to 
> > notice when they get lost.
> 
> This is called "quilt".
> 
> > The only positive side effect of this is that 
> > I can use this to push you harder to forward some patches of me to Linus 
> > that stay unforwarded in -mm for several months...
> 
> A single release cycle is 2-3 months.

And I'm talking about patches waiting in -mm for more than 5 months.

> I'll probably be dropping some of the patches which unexport symbols, btw. 
> ANy ones which aren't really, really obvious.  We have a process for this.

You accept patches into -mm, and without any new issues with these 
patches you tell me more than five months later "I'll probably be 
dropping some of the patches which unexport symbols, btw."?

If this is how my work is appreciated here I'll better stop wasting part 
of my spare time and unsubscribe from linux-kernel.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.13-mm1

[Jesper Juhl]

On 9/3/05, Andrew Morton <akpm@osdl.org> wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > On Sat, Sep 03, 2005 at 12:34:10PM -0700, Andrew Morton wrote:
> > > Adrian Bunk <bunk@stusta.de> wrote:
> > > >
> > > > Hi Andrew,
> > > >
> > > > it seems you dropped
> > > > schedule-obsolete-oss-drivers-for-removal-version-2.patch, but there's
> > > > zero mentioning of this dropping in the changelog of 2.6.13-mm1.
> > > >
> > > > Can you explain why you did silently drop it?
> > >
> > > It spat rejects and when I looked at the putative removal date I just
> > > didn't believe it anyway.  Send a rediffed one if you like, but
> > > October 2005 is unrealistic.
> >
> > That the date is no longer realistic is clear. What disappoints me is
> > that you didn't mention in the changelog of 2.6.13-mm1 where I'd have
> > noticed it.
> 
> Sometimes I can't be bothered getting into email threads over relatively
> unimportant stuff.  Usually it's related to the number of bugs we have.
> 
> > It semms I need my own bookkeeping of patches I sent that are in -mm to
> > notice when they get lost.
> 
> This is called "quilt".
> 

I'm wondering if it would be too much trouble to have a mm-drops list
similar to the mm-commits list.

I also like to keep track of what patches of mine get accepted and
subsequently dropped.

What I'm thinking is that it seems you have the mails to mm-commit
pretty much automated (I may be wrong, but it seems that way to me).
If they are indeed automated, then how hard would it be to set your
end up to automatically send a mail to the same people who got the
original mm-commits mail + send it to a central mm-drops list that
those of us who care about this could subscribe to?

As far as I'm concerned the mails wouldn't even need to contain a
reason (although one would of course be nice) - just a mail stating
the fact that patch xyz was dropped from the mm tree would be great.


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: 2.6.13-mm1

[Andrew Morton]

Jesper Juhl <jesper.juhl@gmail.com> wrote:
>
> I'm wondering if it would be too much trouble to have a mm-drops list
>  similar to the mm-commits list.

Well I was sending drop messages to mm-commits, but lots of people went
"Waah, why did you drop my patch?".  A few hours after they'd been cc'ed as
the patch went in to Linus!  So then I was asked to include an explanation
with the drop message and that all got too hard so I turned them off.

<turns them back on again>

>  I also like to keep track of what patches of mine get accepted and
>  subsequently dropped.

As I say, the way to do this is via your quilt series file.

Re: 2.6.13-mm1

[Jesper Juhl]

On 9/4/05, Andrew Morton <akpm@osdl.org> wrote:
> Jesper Juhl <jesper.juhl@gmail.com> wrote:
> >
> > I'm wondering if it would be too much trouble to have a mm-drops list
> >  similar to the mm-commits list.
> 
> Well I was sending drop messages to mm-commits, but lots of people went
> "Waah, why did you drop my patch?".  A few hours after they'd been cc'ed as
> the patch went in to Linus!  So then I was asked to include an explanation
> with the drop message and that all got too hard so I turned them off.
> 

If patches dropped due to being merged in mainline were then commented
with a simple "merged in mainline" note, surely that would keep the
"Waah .." mails out of your mailbox. :-)

> <turns them back on again>
> 
> >  I also like to keep track of what patches of mine get accepted and
> >  subsequently dropped.
> 
> As I say, the way to do this is via your quilt series file.
> 
Hmm, I've been looking at quilt, but never really got to the point of
actually starting to use it - guess I should get started on that.


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: 2.6.13-mm1

[Paul Jackson]

Andrew wrote"
> So then I was asked to include an explanation
> with the drop message and that all got too hard so I turned them off.
> 
> <turns them back on again>


Dang it, Andrew.  It didn't have to be hard.  Just adding a
boiler plate sentence to all the drop messages saying something
like:

	If I just sent the patch to Linus, that is
	probably why I dropped it here.

That should be enough of a clue for most folks.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

Re: 2.6.13-mm1

[Andrew Morton]

Paul Jackson <pj@sgi.com> wrote:
>
> Andrew wrote"
>  > So then I was asked to include an explanation
>  > with the drop message and that all got too hard so I turned them off.
>  > 
>  > <turns them back on again>
> 
> 
>  Dang it, Andrew.  It didn't have to be hard.

I got three unhappy emails and turned it off again ;)

>  Just adding a
>  boiler plate sentence to all the drop messages saying something
>  like:
> 
>  	If I just sent the patch to Linus, that is
>  	probably why I dropped it here.
> 
>  That should be enough of a clue for most folks.

OK..

Re: 2.6.13-mm1

[Jesper Juhl]

On 9/7/05, Paul Jackson <pj@sgi.com> wrote:
> Andrew wrote"
> > So then I was asked to include an explanation
> > with the drop message and that all got too hard so I turned them off.
> >
> > <turns them back on again>
> 
> 
> Dang it, Andrew.  It didn't have to be hard.  Just adding a
> boiler plate sentence to all the drop messages saying something
> like:
> 
>         If I just sent the patch to Linus, that is
>         probably why I dropped it here.
> 
> That should be enough of a clue for most folks.

I agree completely. Something like that would be just fine for the
patches that have been sent on to Linus.


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: 2.6.13-mm1

[Paul Jackson]

Jesper wrote:
> Something like that would be just fine for the
> patches that have been sent on to Linus.

No - not just the patches sent to Linus - that's a burden on Andrew to
separate things out.

Andrew can put the boiler plate statement on _all_ drop messages

>         If I just sent the patch to Linus, that is
>         probably why I dropped it here.

At the very least, he gets to cuss us out for not being able to read,
instead of not being able to associate the 'patch to Linus' message with
the 'drop' message a few hours later.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

Re: 2.6.13-mm1

[Alexander Nyberg]

On Thu, Sep 01, 2005 at 03:55:42AM -0700 Andrew Morton wrote:

> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/
> 

I got:
<7>Dead loop on netdevice eth0, fix it urgently!

When using netconsole and printing out some information from kernel to
console.

The box uses:
netconsole=4444@192.168.1.12/eth0,7002@192.168.1.1/

0000:00:0f.0 Ethernet controller: Linksys NC100 Network Everywhere Fast
Ethernet 10/100 (rev 11)

Relevant config:
CONFIG_NET_TULIP=y
# CONFIG_DE2104X is not set
CONFIG_TULIP=y
CONFIG_TULIP_MWI=y
# CONFIG_TULIP_MMIO is not set
CONFIG_TULIP_NAPI=y


Matt, on another box I got some irq off hangs that went away when removing
netconsole from the .config on a box with 3c59x. Is this known? The
problem is getting backtraces when netconsole is active, but the last
thing I see before the box goes is that some carrier is up...