2.6.13-mm1

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

[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

[PATCH] mips: remove typedef from struct flock

[Yoichi Yuasa]

Hi,

This patch has fixed the following warning about MIPS.
Please apply.

Yoichi

  CC      arch/mips/kernel/offset.s
In file included from include/linux/fcntl.h:4,
                 from include/linux/fs.h:689,
                 from include/linux/mm.h:15,
                 from arch/mips/kernel/offset.c:15:
include/asm/fcntl.h:53: warning: useless keyword or type name in empty declaration

Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>

diff -urN -X dontdiff mm1-orig/include/asm-mips/fcntl.h mm1/include/asm-mips/fcntl.h
--- mm1-orig/include/asm-mips/fcntl.h	2005-09-01 21:58:47.000000000 +0900
+++ mm1/include/asm-mips/fcntl.h	2005-09-01 23:38:18.000000000 +0900
@@ -42,7 +42,7 @@
 
 #ifndef __mips64
 
-typedef struct flock {
+struct flock {
 	short	l_type;
 	short	l_whence;
 	__kernel_off_t l_start;

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

[PATCH] : struct dentry : place d_hash close to d_parent and d_name to speedup lookups

[Eric Dumazet]

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


dentry cache uses sophisticated RCU technology (and prefetching if available) 
but touches 2 cache lines per dentry during hlist lookup.

This patch moves d_hash in the same cache line than d_parent and d_name fields 
so that :

1) One cache line is needed instead of two.
2) the hlist_for_each_rcu() prefetching has a chance to bring all the needed 
data in advance, not only the part that includes d_hash.next.

I also changed one old comment that was wrong for 64bits.

A further optimisation would be to separate dentry in two parts, one that is 
mostly read, and one writen (d_count/d_lock) to avoid false sharing on 
SMP/NUMA but this would need different field placement depending on 32bits or 
64bits platform.

Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>


[-- Attachment #2: dentry.patch --]
[-- Type: text/plain, Size: 0 bytes --]

[PATCH] : struct dentry : place d_hash close to d_parent and d_name to speedup lookups

[Eric Dumazet]

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

dentry cache uses sophisticated RCU technology (and prefetching if available) 
but touches 2 cache lines per dentry during hlist lookup.

This patch moves d_hash in the same cache line than d_parent and d_name fields 
so that :

1) One cache line is needed instead of two.
2) the hlist_for_each_rcu() prefetching has a chance to bring all the needed 
data in advance, not only the part that includes d_hash.next.

I also changed one old comment that was wrong for 64bits.

A further optimisation would be to separate dentry in two parts, one that is 
mostly read, and one writen (d_count/d_lock) to avoid false sharing on 
SMP/NUMA but this would need different field placement depending on 32bits or 
64bits platform.

with the patch this time :)

Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>


[-- Attachment #2: dcache.patch --]
[-- Type: text/plain, Size: 788 bytes --]

--- linux-2.6.13/include/linux/dcache.h	2005-08-29 01:41:01.000000000 +0200
+++ linux-2.6.13-ed/include/linux/dcache.h	2005-09-01 17:22:32.000000000 +0200
@@ -88,8 +88,9 @@
 					 * negative */
 	/*
 	 * The next three fields are touched by __d_lookup.  Place them here
-	 * so they all fit in a 16-byte range, with 16-byte alignment.
+	 * so they all fit in a cache line.
 	 */
+	struct hlist_node d_hash;	/* lookup hash list */	
 	struct dentry *d_parent;	/* parent directory */
 	struct qstr d_name;
 
@@ -103,7 +104,6 @@
 	void *d_fsdata;			/* fs-specific data */
  	struct rcu_head d_rcu;
 	struct dcookie_struct *d_cookie; /* cookie, if any */
-	struct hlist_node d_hash;	/* lookup hash list */	
 	int d_mounted;
 	unsigned char d_iname[DNAME_INLINE_LEN_MIN];	/* small names */
 };

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: [PATCH] : struct dentry : place d_hash close to d_parent and d_name to speedup lookups

[Dipankar Sarma]

On Thu, Sep 01, 2005 at 05:48:28PM +0200, Eric Dumazet wrote:
> dentry cache uses sophisticated RCU technology (and prefetching if 
> available) but touches 2 cache lines per dentry during hlist lookup.
> 
> This patch moves d_hash in the same cache line than d_parent and d_name 
> fields so that :
> 
> 1) One cache line is needed instead of two.
> 2) the hlist_for_each_rcu() prefetching has a chance to bring all the 
> needed data in advance, not only the part that includes d_hash.next.
> 
> I also changed one old comment that was wrong for 64bits.
> 
> A further optimisation would be to separate dentry in two parts, one that 
> is mostly read, and one writen (d_count/d_lock) to avoid false sharing on 
> SMP/NUMA but this would need different field placement depending on 32bits 
> or 64bits platform.

Do you have performance numbers that show the benefits ? In the
past, I did try some optimizations like this but found no demonstrable
benefits. If it ain't broken .....

Thanks
Dipankar

2.6.13-mm1 - drivers/isdn/i4l/isdn_tty broken

[Damir Perisa]

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

hi Andrew,
hi Alan,

updating the kernel26mm package for archlinux to 2.6.13-mm1 i found the isdn-tty to be broken:

  CC [M]  drivers/isdn/i4l/isdn_tty.o
drivers/isdn/i4l/isdn_tty.c: In function 'isdn_tty_try_read':
drivers/isdn/i4l/isdn_tty.c:71: error: 'struct tty_struct' has no member named 'flip'
drivers/isdn/i4l/isdn_tty.c:86: error: 'struct tty_struct' has no member named 'flip'
drivers/isdn/i4l/isdn_tty.c:86: error: 'struct tty_struct' has no member named 'flip'
drivers/isdn/i4l/isdn_tty.c:88: error: 'struct tty_struct' has no member named 'flip'
drivers/isdn/i4l/isdn_tty.c:89: error: 'struct tty_struct' has no member named 'flip'
drivers/isdn/i4l/isdn_tty.c:90: error: 'struct tty_struct' has no member named 'flip'
drivers/isdn/i4l/isdn_tty.c:90: error: 'struct tty_struct' has no member named 'flip'
drivers/isdn/i4l/isdn_tty.c:90: error: 'struct tty_struct' has no member named 'flip'
drivers/isdn/i4l/isdn_tty.c:90: error: 'struct tty_struct' has no member named 'flip'
drivers/isdn/i4l/isdn_tty.c:91: error: 'struct tty_struct' has no member named 'flip'
drivers/isdn/i4l/isdn_tty.c:96: error: 'struct tty_struct' has no member named 'flip'
drivers/isdn/i4l/isdn_tty.c:97: error: 'struct tty_struct' has no member named 'flip'
drivers/isdn/i4l/isdn_tty.c: In function 'isdn_tty_readmodem':
drivers/isdn/i4l/isdn_tty.c:134: error: 'struct tty_struct' has no member named 'flip'
drivers/isdn/i4l/isdn_tty.c:137: error: 'struct tty_struct' has no member named 'flip'
drivers/isdn/i4l/isdn_tty.c:138: error: 'struct tty_struct' has no member named 'flip'
drivers/isdn/i4l/isdn_tty.c:141: error: 'struct tty_struct' has no member named 'flip'
drivers/isdn/i4l/isdn_tty.c:141: error: 'struct tty_struct' has no member named 'flip'
drivers/isdn/i4l/isdn_tty.c:141: error: 'struct tty_struct' has no member named 'flip'
drivers/isdn/i4l/isdn_tty.c:141: error: 'struct tty_struct' has no member named 'flip'
drivers/isdn/i4l/isdn_tty.c:142: error: 'struct tty_struct' has no member named 'flip'
drivers/isdn/i4l/isdn_tty.c:143: error: 'struct tty_struct' has no member named 'flip'
drivers/isdn/i4l/isdn_tty.c:144: error: 'struct tty_struct' has no member named 'flip'
drivers/isdn/i4l/isdn_tty.c:146: error: 'struct tty_struct' has no member named 'flip'
drivers/isdn/i4l/isdn_tty.c: In function 'isdn_tty_at_cout':
drivers/isdn/i4l/isdn_tty.c:2372: error: 'struct tty_struct' has no member named 'flip'
drivers/isdn/i4l/isdn_tty.c:2403: error: 'struct tty_struct' has no member named 'flip'
drivers/isdn/i4l/isdn_tty.c:2418: error: 'struct tty_struct' has no member named 'flip'
make[3]: *** [drivers/isdn/i4l/isdn_tty.o] Error 1
make[2]: *** [drivers/isdn/i4l] Error 2
make[1]: *** [drivers/isdn] Error 2
make: *** [drivers] Error 2

greetings,
Damir

Le Thursday 01 September 2005 12:55, Andrew Morton a écrit :
| 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).

-- 
  Gentlemen, I want you to know that I am not always right, but I am
  never wrong. -Samuel Goldwyn

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

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

[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

[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: [PATCH] : struct dentry : place d_hash close to d_parent and d_name to speedup lookups

[Eric Dumazet]

Dipankar Sarma a écrit :
> On Thu, Sep 01, 2005 at 05:48:28PM +0200, Eric Dumazet wrote:
> 
>>dentry cache uses sophisticated RCU technology (and prefetching if 
>>available) but touches 2 cache lines per dentry during hlist lookup.
>>
>>This patch moves d_hash in the same cache line than d_parent and d_name 
>>fields so that :
>>
>>1) One cache line is needed instead of two.
>>2) the hlist_for_each_rcu() prefetching has a chance to bring all the 
>>needed data in advance, not only the part that includes d_hash.next.
>>
>>I also changed one old comment that was wrong for 64bits.
>>
>>A further optimisation would be to separate dentry in two parts, one that 
>>is mostly read, and one writen (d_count/d_lock) to avoid false sharing on 
>>SMP/NUMA but this would need different field placement depending on 32bits 
>>or 64bits platform.
> 
> 
> Do you have performance numbers that show the benefits ? In the
> past, I did try some optimizations like this but found no demonstrable
> benefits. If it ain't broken .....
> 

You mean... a microbenchmark ? :)

Well, the dentry cache hash table is so large that it's difficult to see the 
benefit, because chain length average is < 1 on most setups.
I suspect the sizing strategy of this hash table was made a long time ago...
Reducing the number of cache lines touched per dentry in lookup could let us 
shrink the hash table and save some ram.

Facts now :
------------

On a 512MB ia32 machine, the default sizing of the hash table gives 131072 
slots (0.5 MB of ram). So it's quite hard to populate the cache without eating 
all ram.

To see a benefit, I had to force a smaller hash size (appending in kernel 
params "dhash_entries=8191")

On this 512MB PIII 866MHz machine (L1_CACHE_SIZE=32), with 563887 files or 
directories the results are :

Remount the disk with noatime to make sure no disk access will be done

# mount -o remount /dev/hda2 / -o noatime

Populate the caches (dentry and disk buffers for directories)
# find / -name foofoo >/dev/null

# grep dentry_cache /proc/slabinfo
dentry_cache      131104 131370    136   29    1 : tunables  120   60    0 : 
slabdata   4530   4530      0

So average chain length is now 16

then time new searches using data in cache
time / -name foofoo >/dev/null

# time find / -name foofoo

real    0m3.077s
user    0m1.724s
sys     0m1.344s
# time find / -name foofoo

real    0m3.077s
user    0m1.728s
sys     0m1.348s
# time find / -name foofoo

real    0m3.084s
user    0m1.784s
sys     0m1.276s
# time find / -name foofoo

real    0m3.108s
user    0m1.716s
sys     0m1.348s
# time find / -name foofoo

real    0m3.061s
user    0m1.672s
sys     0m1.384s
# time find / -name foofoo

real    0m3.067s
user    0m1.644s
sys     0m1.424s
# time find / -name foofoo

real    0m3.061s
user    0m1.804s
sys     0m1.252s

kernel 2.6.13 build time
------------------------
mount -o remount /dev/hda2 /
make clean
time make bzImage
real    12m21.755s
user    11m5.070s
sys     1m0.756s


------------------------------------------------------------------

Results with a patched kernel


# time find / -name foofoo

real    0m3.017s
user    0m1.700s
sys     0m1.316s
# time find / -name foofoo

real    0m3.018s
user    0m1.592s
sys     0m1.424s
# time find / -name foofoo

real    0m3.017s
user    0m1.624s
sys     0m1.396s
# time find / -name foofoo

real    0m3.019s
user    0m1.680s
sys     0m1.340s
# time find / -name foofoo

real    0m3.021s
user    0m1.676s
sys     0m1.344s
# time find / -name foofoo

real    0m3.022s
user    0m1.644s
sys     0m1.376s
# time find / -name foofoo

real    0m3.021s
user    0m1.620s
sys     0m1.404s

kernel 2.6.13 build time
------------------------
mount -o remount /dev/hda2 /
make clean
time make bzImage
real    12m8.814s
user    11m2.129s
sys     0m52.187s

Conclusions:
-----------

1) There is a clear benefit, even without a microbenchmark :)

2) As sizeof(struct dentry)=136 on ia32 UP (140 on SMP), and dentry slab is 
not using SLAB_HWCACHE_ALIGN, I suspect lot of dentries are not aligned on a 
cache line boundary, so maybe reducing DNAME_INLINE_LEN_MIN (or increasing it) 
so that sizeof(struct dentry)%L1_CACHE_BYTES = {0 or (L1_CACHE_BYTES/2)} would 
even give better results.

Thank you

Eric

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 - drivers/isdn/i4l/isdn_tty broken

[Alan Cox]

On Thu, Sep 01, 2005 at 07:41:02PM +0200, Damir Perisa wrote:
> hi Andrew,
> hi Alan,
> 
> updating the kernel26mm package for archlinux to 2.6.13-mm1 i found the isdn-tty to be broken:

isdn-tty needs updating and is complex to update. I've been talking with
Karsten Keil about it by email and he will take a look soon (once I send him
the diff ...)

Re: 2.6.13-mm1: PCMCIA problem

[Rafael J. Wysocki]

On Thursday, 1 of 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/

I cannot start PCMCIA on x86-64 SuSE 9.3 on Asus L5D.  Apparently, the following
command:

sh -c modprobe --ignore-install firmware_class; echo 30 > /sys/class/firmware/timeout

loops forever with almost 100% of the time spent in the kernel.

AFAICS, 2.6.13-rc6-mm2 is also affected, but the mainline kernels are not.

Greetings,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

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: PCMCIA problem

[Andrew Morton]

"Rafael J. Wysocki" <rjw@sisk.pl> wrote:
>
> On Thursday, 1 of 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/
> 
> I cannot start PCMCIA on x86-64 SuSE 9.3 on Asus L5D.  Apparently, the following
> command:
> 
> sh -c modprobe --ignore-install firmware_class; echo 30 > /sys/class/firmware/timeout
> 
> loops forever with almost 100% of the time spent in the kernel.
> 
> AFAICS, 2.6.13-rc6-mm2 is also affected, but the mainline kernels are not.

OK.  There are no notable firmware changes in there.  While it's stuck
could you generate a kernel profile?    I do:

readprofile -r
sleep 5
readprofile -n -v -m /boot/System.map | sort -n +2 | tail -40

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

[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

2.6.13-mm1: broken drivers/video/sis/Makefile

[Adrian Bunk]

On Thu, Sep 01, 2005 at 03:55:42AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.13-rc6-mm2:
>...
> +sisfb-update.patch
>...
>  fbdev updates
>...

This patch accidentally replaces drivers/video/sis/Makefile with a 
toplevel Makefile.

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: broken drivers/video/sis/Makefile

[Thomas Winischhofer]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adrian Bunk wrote:
> On Thu, Sep 01, 2005 at 03:55:42AM -0700, Andrew Morton wrote:
> 
>>...
>>Changes since 2.6.13-rc6-mm2:
>>...
>>+sisfb-update.patch
>>...
>> fbdev updates
>>...
> 
> 
> This patch accidentally replaces drivers/video/sis/Makefile with a 
> toplevel Makefile.

ARGH..... that happens if you work with four trees at the same time...

My appologies. Correct Makefile-patch attached.

Thomas

- --
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net	       *** http://www.winischhofer.net
twini AT xfree86 DOT org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDF43FzydIRAktyUcRAptjAKDPQeYc3v5Ulu+HKnbRINsCNcfwwgCgkWnD
sJnT86TfSyX45JIW2KKRLog=
=TDOr
-----END PGP SIGNATURE-----

[-- Attachment #2: sisfb_mf_patch.diff --]
[-- Type: text/plain, Size: 347 bytes --]

--- linux-2.6.13-orig/drivers/video/sis/Makefile	2005-08-29 01:41:01.000000000 +0200
+++ linux-2.6.13-sisfb/drivers/video/sis/Makefile	2005-09-02 01:22:29.247255624 +0200
@@ -4,4 +4,4 @@
 
 obj-$(CONFIG_FB_SIS) += sisfb.o
 
-sisfb-objs := sis_main.o sis_accel.o init.o init301.o
+sisfb-objs := sis_main.o sis_accel.o init.o init301.o initextlfb.o

2.6.13-mm1: misc mwave issues

[Adrian Bunk]

On Thu, Sep 01, 2005 at 03:55:42AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.13-rc6-mm2:
>...
>  git-serial.patch
>...
>  Subsystem trees
>...

This patch contains Alan's patch for fixing the compilation of 
drivers/char/mwave/mwavedd.c, but the driver is still marked as BROKEN 
which should now be undone.

The MWAVE also got a comment
  # PLEASE DO NOT DO THIS - move this driver to drivers/serial

Since it seems this code is mostly unmaintained, can the
  mv drivers/char/mwave drivers/serial/
be done in the git-serial tree?

Additionally, drivers/char/mwave/mwavedd.c now requires an
  #include "8250.h"
for the serial8250_{,un}register_port prototypes.


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

2.6.13-mm1 - drivers/serial/jsm/jsm_tty broken too

[Damir Perisa]

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

i disabled the isdn subsystem temporarely and tried to recompile 
finding out that jsm-tty is affected too:

 CC [M]  drivers/serial/jsm/jsm_tty.o
drivers/serial/jsm/jsm_tty.c: In function 'jsm_input':
drivers/serial/jsm/jsm_tty.c:592: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:619: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:620: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:623: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:624: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:667: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:668: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:669: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:670: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:671: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:672: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:674: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:677: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:677: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:677: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:677: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:680: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:681: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:682: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:691: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:692: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:693: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:694: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:695: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:696: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:698: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:701: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:701: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:701: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:701: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:742: error: 'struct tty_struct' has no member named 'flip'
drivers/serial/jsm/jsm_tty.c:742: error: 'struct tty_struct' has no member named 'flip'
make[3]: *** [drivers/serial/jsm/jsm_tty.o] Error 1
make[2]: *** [drivers/serial/jsm] Error 2
make[1]: *** [drivers/serial] Error 2
make: *** [drivers] Error 2

hope that this tty breaks will be fixed in mm2

greetings,
Damir

-- 
It would save me a lot of time if you just gave up and went mad now.

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

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]

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: 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: PCMCIA problem

[Rafael J. Wysocki]

On Thursday, 1 of September 2005 23:28, Andrew Morton wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> >
> > On Thursday, 1 of 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/
> > 
> > I cannot start PCMCIA on x86-64 SuSE 9.3 on Asus L5D.  Apparently, the following
> > command:
> > 
> > sh -c modprobe --ignore-install firmware_class; echo 30 > /sys/class/firmware/timeout
> > 
> > loops forever with almost 100% of the time spent in the kernel.
> > 
> > AFAICS, 2.6.13-rc6-mm2 is also affected, but the mainline kernels are not.
> 
> OK.  There are no notable firmware changes in there.  While it's stuck
> could you generate a kernel profile?    I do:
> 
> readprofile -r
> sleep 5
> readprofile -n -v -m /boot/System.map | sort -n +2 | tail -40

OK
I ran "rcpcmcia start" in one vt and the above in another.  The result was:

    20 *unknown*
ffffffff802417f0 __memset                                      1   0.0052
ffffffff80242850 _raw_spin_lock                                1   0.0031
ffffffff8026a44c acpi_ns_get_next_node                         1   0.0118
ffffffff802ed040 sock_kfree_s                                  1   0.0156
ffffffff8010eb38 sysret_check                                  2   0.0241
ffffffff8010eb33 ret_from_sys_call                             4   0.8000
ffffffff80240cc0 copy_user_generic                             5   0.0168
ffffffff80221870 dummy_file_permission                         7   0.4375
ffffffff8023f5e0 simple_strtol                                14   0.2917
ffffffff80240c90 copy_from_user                               15   0.3125
ffffffff802ac800 class_attr_store                             17   0.3542
ffffffff8017df70 rw_verify_area                               22   0.1719
ffffffff8023f500 simple_strtoul                               24   0.1071
ffffffff8017ead0 sys_write                                    41   0.2847
ffffffff80240dea copy_user_generic_c                          82   2.1579
ffffffff8017f1d0 fget_light                                  108   0.4500
ffffffff8010eab0 system_call                                 189   1.4427
ffffffff8017e890 vfs_write                                   220   0.5288
ffffffff801bfc40 sysfs_write_file                            308   0.8370
0000000000000000 total                                      1062   0.0004

After I had stopped the (looping) "rcpcmcia start", I got:

  1243 *unknown*
ffffffff80240dea copy_user_generic_c                           1   0.0263
ffffffff802417f0 __memset                                      1   0.0052
0000000000000000 total                                         2   0.0000

Greetings,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: 2.6.13-mm1: PCMCIA problem

[Rafael J. Wysocki]

On Friday, 2 of September 2005 10:30, Rafael J. Wysocki wrote:
> On Thursday, 1 of September 2005 23:28, Andrew Morton wrote:
> > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > >
> > > On Thursday, 1 of 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/
> > > 
> > > I cannot start PCMCIA on x86-64 SuSE 9.3 on Asus L5D.  Apparently, the following
> > > command:
> > > 
> > > sh -c modprobe --ignore-install firmware_class; echo 30 > /sys/class/firmware/timeout
> > > 
> > > loops forever with almost 100% of the time spent in the kernel.
> > > 
> > > AFAICS, 2.6.13-rc6-mm2 is also affected, but the mainline kernels are not.
> > 
> > OK.  There are no notable firmware changes in there.  While it's stuck
> > could you generate a kernel profile?    I do:
> > 
> > readprofile -r
> > sleep 5
> > readprofile -n -v -m /boot/System.map | sort -n +2 | tail -40

]--snip--[

One more piece of information.  This is the one that loops:

echo 30 > /sys/class/firmware/timeout

and the related profile is:

    16 *unknown*
ffffffff8010eb38 sysret_check                                  1   0.0120
ffffffff80240b40 clear_page                                    1   0.0175
ffffffff80356397 bad_gs                                        1   0.0001
ffffffff80240cc0 copy_user_generic                             2   0.0067
ffffffff8010eb33 ret_from_sys_call                             6   1.2000
ffffffff80221870 dummy_file_permission                         7   0.4375
ffffffff80240c90 copy_from_user                                9   0.1875
ffffffff8023f5e0 simple_strtol                                11   0.2292
ffffffff8023f500 simple_strtoul                               17   0.0759
ffffffff802ac800 class_attr_store                             18   0.3750
ffffffff801bfc40 sysfs_write_file                             61   0.1658
ffffffff8017ead0 sys_write                                    78   0.5417
ffffffff8017df70 rw_verify_area                              143   1.1172
ffffffff80240dea copy_user_generic_c                         144   3.7895
ffffffff8010eab0 system_call                                 163   1.2443
ffffffff8017f1d0 fget_light                                  184   0.7667
ffffffff8017e890 vfs_write                                   209   0.5024
0000000000000000 total                                      1055   0.0004

Greetings,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: 2.6.13-mm1: PCMCIA problem

[Pavel Machek]

Hi!

> > > > On Thursday, 1 of 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/
> > > > 
> > > > I cannot start PCMCIA on x86-64 SuSE 9.3 on Asus L5D.  Apparently, the following
> > > > command:
> > > > 
> > > > sh -c modprobe --ignore-install firmware_class; echo 30 > /sys/class/firmware/timeout
> > > > 
> > > > loops forever with almost 100% of the time spent in the kernel.
> > > > 
> > > > AFAICS, 2.6.13-rc6-mm2 is also affected, but the mainline kernels are not.
> > > 
> > > OK.  There are no notable firmware changes in there.  While it's stuck
> > > could you generate a kernel profile?    I do:
> > > 
> > > readprofile -r
> > > sleep 5
> > > readprofile -n -v -m /boot/System.map | sort -n +2 | tail -40
> 
> ]--snip--[
> 
> One more piece of information.  This is the one that loops:
> 
> echo 30 > /sys/class/firmware/timeout

Try echo -n ...

-- 
if you have sharp zaurus hardware you don't need... you know my address

Re: 2.6.13-mm1: PCMCIA problem

[Rafael J. Wysocki]

On Friday, 2 of September 2005 12:43, Pavel Machek wrote:
> Hi!
> 
> > > > > On Thursday, 1 of 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/
> > > > > 
> > > > > I cannot start PCMCIA on x86-64 SuSE 9.3 on Asus L5D.  Apparently, the following
> > > > > command:
> > > > > 
> > > > > sh -c modprobe --ignore-install firmware_class; echo 30 > /sys/class/firmware/timeout
> > > > > 
> > > > > loops forever with almost 100% of the time spent in the kernel.
> > > > > 
> > > > > AFAICS, 2.6.13-rc6-mm2 is also affected, but the mainline kernels are not.
> > > > 
> > > > OK.  There are no notable firmware changes in there.  While it's stuck
> > > > could you generate a kernel profile?    I do:
> > > > 
> > > > readprofile -r
> > > > sleep 5
> > > > readprofile -n -v -m /boot/System.map | sort -n +2 | tail -40
> > 
> > ]--snip--[
> > 
> > One more piece of information.  This is the one that loops:
> > 
> > echo 30 > /sys/class/firmware/timeout
> 
> Try echo -n ...

Well that helps but it means the SuSE's scripts have to be changed to work with
2.6.13-mm1.  Specifically "/etc/modprobe.d/firmware".  Is that intentional or not?

Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: 2.6.13-mm1: PCMCIA problem

[Andrew Morton]

Pavel Machek <pavel@suse.cz> wrote:
>
> > One more piece of information.  This is the one that loops:
>  > 
>  > echo 30 > /sys/class/firmware/timeout
> 
>  Try echo -n ...

Or revert gregkh-driver-sysfs-strip_leading_trailing_whitespace.patch. 
Obviously if you write 30\n and the write returns 2 then the shell will
then try to write the \n.  That returns zero and the shell tries again, ad
infinitum.

Rant.  It took me two full days to weed out and fix all the crap people
sent me to get -mm1 into a state where it vaguely compiled and booted.  And
it's untested nonsense like this which wrecks the whole effort for many
testers.

I suppose this is as good as anything....


From: Andrew Morton <akpm@osdl.org>

Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 fs/sysfs/file.c |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff -puN fs/sysfs/file.c~gregkh-driver-sysfs-strip_leading_trailing_whitespace-fix fs/sysfs/file.c
--- 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: swsusp problem (was: PCMCIA problem)

[Rafael J. Wysocki]

On Friday, 2 of September 2005 13:09, Andrew Morton wrote:
> Pavel Machek <pavel@suse.cz> wrote:
> >
> > > One more piece of information.  This is the one that loops:
> >  > 
> >  > echo 30 > /sys/class/firmware/timeout
> > 
> >  Try echo -n ...
> 
> Or revert gregkh-driver-sysfs-strip_leading_trailing_whitespace.patch. 
> Obviously if you write 30\n and the write returns 2 then the shell will
> then try to write the \n.  That returns zero and the shell tries again, ad
> infinitum.
> 
> Rant.  It took me two full days to weed out and fix all the crap people
> sent me to get -mm1 into a state where it vaguely compiled and booted.  And
> it's untested nonsense like this which wrecks the whole effort for many
> testers.
> 
> I suppose this is as good as anything....

Thanks for the fix. :-)

Now, (using the fact that Pavel already is in the CC list ;-)) there's another
issue I have with swsusp, which is broken in a funny way.  Namely, after
resuming from disk the box immediately goes into standby from which it
can be woken up by pressing the power button, but then it oopses,
goes into standby (or something similar) again, and hangs solid (unfortunately
I can't get the traces right now).

Greetings,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: 2.6.13-mm1: misc mwave issues

[Alan Cox]

On Gwe, 2005-09-02 at 01:25 +0200, Adrian Bunk wrote:
> The MWAVE also got a comment
>   # PLEASE DO NOT DO THIS - move this driver to drivers/serial

Mwave is an interested toy - its mostly an enabled for the hardware and
the services provided are not just serial but also audio etc

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: swsusp problem (was: PCMCIA problem)

[Rafael J. Wysocki]

On Friday, 2 of September 2005 13:45, Rafael J. Wysocki wrote:
> On Friday, 2 of September 2005 13:09, Andrew Morton wrote:
> > Pavel Machek <pavel@suse.cz> wrote:
> > >
> > > > One more piece of information.  This is the one that loops:
> > >  > 
> > >  > echo 30 > /sys/class/firmware/timeout
> > > 
> > >  Try echo -n ...
> > 
> > Or revert gregkh-driver-sysfs-strip_leading_trailing_whitespace.patch. 
> > Obviously if you write 30\n and the write returns 2 then the shell will
> > then try to write the \n.  That returns zero and the shell tries again, ad
> > infinitum.
> > 
> > Rant.  It took me two full days to weed out and fix all the crap people
> > sent me to get -mm1 into a state where it vaguely compiled and booted.  And
> > it's untested nonsense like this which wrecks the whole effort for many
> > testers.
> > 
> > I suppose this is as good as anything....
> 
> Thanks for the fix. :-)
> 
> Now, (using the fact that Pavel already is in the CC list ;-)) there's another
> issue I have with swsusp, which is broken in a funny way.  Namely, after
> resuming from disk the box immediately goes into standby from which it
> can be woken up by pressing the power button, but then it oopses,
> goes into standby (or something similar) again, and hangs solid (unfortunately
> I can't get the traces right now).

Sorry for the noise.  This problem has been fixed by the same patch (ie suspend
is initiated by writing a string to a file on sysfs etc.).

Greetings,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

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

[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]

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

[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

[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

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

Re: 2.6.13-mm1: PCMCIA problem

[Pavel Machek]

Hi!

> > > One more piece of information.  This is the one that loops:
> >  > 
> >  > echo 30 > /sys/class/firmware/timeout
> > 
> >  Try echo -n ...
> 
> Or revert gregkh-driver-sysfs-strip_leading_trailing_whitespace.patch. 
> Obviously if you write 30\n and the write returns 2 then the shell will
> then try to write the \n.  That returns zero and the shell tries again, ad
> infinitum.

Can you revert
gregkh-driver-sysfs-strip_leading_trailing_whitespace.patch, instead?

Kernel should not provide "nice" interface. Striping trailing
whitespace is wrong, just teach users to use sysfs right.

								Pavel
-- 
if you have sharp zaurus hardware you don't need... you know my address

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

[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

[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

tty patches in 2.6.13-mm3 (was Re: 2.6.13-mm1)

[serue]

Quoting Alan Cox (alan@redhat.com):
> 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

Hi,

I'm not sure whether these are going in through some other channel,
but I notice neither the Alan's hvcs.c or icom.c patches are in
2.6.13-mm3.  In addition, hvc_console.c needs yet another...

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

I do have one, but have been gone for awhile.  But am willing and
eager to test (and get it working again :)

thanks,
-serge

Signed-off-by: Serge Hallyn <serue@us.ibm.com>

Index: linux-2.6.12/drivers/char/hvc_console.c
===================================================================
--- linux-2.6.12.orig/drivers/char/hvc_console.c	2005-09-12 15:08:41.000000000 -0500
+++ linux-2.6.12/drivers/char/hvc_console.c	2005-09-12 15:52:08.000000000 -0500
@@ -597,7 +597,7 @@ static int hvc_poll(struct hvc_struct *h
 
 	/* Read data if any */
 	for (;;) {
-		count = tty_buffer_request_room(tty, N_INBUF);
+		int count = tty_buffer_request_room(tty, N_INBUF);
 
 		/* If flip is full, just reschedule a later read */
 		if (count == 0) {
@@ -633,7 +633,7 @@ static int hvc_poll(struct hvc_struct *h
 			tty_insert_flip_char(tty, buf[i], 0);
 		}
 
-		if (tty->flip.count)
+		if (tty_buffer_request_room(tty, 1))
 			tty_schedule_flip(tty);
 
 		/*

Re: tty patches in 2.6.13-mm3 (was Re: 2.6.13-mm1)

[Joel Schopp]

> I'm not sure whether these are going in through some other channel,
> but I notice neither the Alan's hvcs.c or icom.c patches are in
> 2.6.13-mm3.  In addition, hvc_console.c needs yet another...

Yeah, there is still a whole lot broken in -mm.  Your patch below is a 
good start though.

Acked-by: Joel Schopp <jschopp@austin.ibm.com>

> Signed-off-by: Serge Hallyn <serue@us.ibm.com>
> 
> Index: linux-2.6.12/drivers/char/hvc_console.c
> ===================================================================
> --- linux-2.6.12.orig/drivers/char/hvc_console.c	2005-09-12 15:08:41.000000000 -0500
> +++ linux-2.6.12/drivers/char/hvc_console.c	2005-09-12 15:52:08.000000000 -0500
> @@ -597,7 +597,7 @@ static int hvc_poll(struct hvc_struct *h
>  
>  	/* Read data if any */
>  	for (;;) {
> -		count = tty_buffer_request_room(tty, N_INBUF);
> +		int count = tty_buffer_request_room(tty, N_INBUF);
>  
>  		/* If flip is full, just reschedule a later read */
>  		if (count == 0) {
> @@ -633,7 +633,7 @@ static int hvc_poll(struct hvc_struct *h
>  			tty_insert_flip_char(tty, buf[i], 0);
>  		}
>  
> -		if (tty->flip.count)
> +		if (tty_buffer_request_room(tty, 1))
>  			tty_schedule_flip(tty);
>  
>  		/*
> -
> 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

[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