2.6.13-mm1

Andrew Morton

unread,

Sep 1, 2005, 7:10:19 AM9/1/05

to

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

Martin J. Bligh

unread,

Sep 1, 2005, 10:30:21 AM9/1/05

to

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) ???

Alan Cox

unread,

Sep 1, 2005, 11:00:15 AM9/1/05

to

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

Yoichi Yuasa

unread,

Sep 1, 2005, 11:10:14 AM9/1/05

to

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 <yu...@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;

Adrian Bunk

unread,

Sep 1, 2005, 11:10:22 AM9/1/05

to

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

Dominik Karall

unread,

Sep 1, 2005, 11:40:15 AM9/1/05

to

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

Eric Dumazet

unread,

Sep 1, 2005, 11:50:06 AM9/1/05

to

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 <da...@cosmosbay.com>

Eric Dumazet

unread,

Sep 1, 2005, 11:50:14 AM9/1/05

to

with the patch this time :)

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

dcache.patch

John Stoffel

unread,

Sep 1, 2005, 12:20:10 PM9/1/05

to

>>>>> "Dominik" == Dominik Karall <dominik...@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

Dominik Karall

unread,

Sep 1, 2005, 12:30:07 PM9/1/05

to

On Thursday 01 September 2005 18:09, John Stoffel wrote:
> >>>>> "Dominik" == Dominik Karall <dominik...@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

John Stoffel

unread,

Sep 1, 2005, 1:40:14 PM9/1/05

to

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?

Dipankar Sarma

unread,

Sep 1, 2005, 1:50:04 PM9/1/05

to

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

Damir Perisa

unread,

Sep 1, 2005, 1:50:16 PM9/1/05

to

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.

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

Dominik Karall

unread,

Sep 1, 2005, 2:10:07 PM9/1/05

to

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

John Stoffel

unread,

Sep 1, 2005, 2:30:26 PM9/1/05

to

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.

J.A. Magallon

unread,

Sep 1, 2005, 2:30:27 PM9/1/05

to

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

Eric Dumazet

unread,

Sep 1, 2005, 4:00:16 PM9/1/05

to

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

Joel Schopp

unread,

Sep 1, 2005, 5:00:16 PM9/1/05

to

>> /* 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'

Alan Cox

unread,

Sep 1, 2005, 5:10:14 PM9/1/05

to

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

Alan Cox

unread,

Sep 1, 2005, 5:20:17 PM9/1/05

to

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 */

Rafael J. Wysocki

unread,

Sep 1, 2005, 5:20:18 PM9/1/05

to

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"

Joel Schopp

unread,

Sep 1, 2005, 5:30:17 PM9/1/05

to

> 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

Andrew Morton

unread,

Sep 1, 2005, 5:30:22 PM9/1/05

to

"Rafael J. Wysocki" <r...@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

Alan Cox

unread,

Sep 1, 2005, 5:50:16 PM9/1/05

to

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

Adrian Bunk

unread,

Sep 1, 2005, 6:10:10 PM9/1/05

to

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

-

Adrian Bunk

unread,

Sep 1, 2005, 6:30:14 PM9/1/05

to

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

-

Thomas Winischhofer

unread,

Sep 1, 2005, 7:30:13 PM9/1/05

to

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

sisfb_mf_patch.diff

Adrian Bunk

unread,

Sep 1, 2005, 7:30:14 PM9/1/05

to

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

Damir Perisa

unread,

Sep 1, 2005, 9:10:05 PM9/1/05

to

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.

Reuben Farrelly

unread,

Sep 1, 2005, 9:50:06 PM9/1/05

to

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

J.A. Magallon

unread,

Sep 1, 2005, 10:00:08 PM9/1/05