Things are definitely calming down, and while I'm not ready to call it a
final 2.6.18 yet, this migt be the last -rc.
There's a few x86-64 updates, ARM and ppc stuff, and a couple of driver
fixes. And a small cifs update. Both ShortLog and diffstat is appended,
since they are both fairly small and easily viewed.
Linus
--- shortlog snip snip ---
Adrian Bunk:
[XFS] Fix char size overflow in bmap_alloc call for unwritten extent
schedule obsolete OSS drivers for removal, 2nd round
Akinobu Mita:
[NETLINK]: Call panic if nl_table allocation fails
[NET]: Rate limiting for socket allocation failure messages.
Alan Cox:
Missing PCI id update for VIA IDE
Alan Stern:
UHCI: don't stop at an Iso error
uhci-hcd: fix list access bug
Andi Kleen:
x86_64: Update defconfig
x86: Revert e820 MCFG heuristics
x86_64: Add kernel thread stack frame termination for properly stopping stack unwinds.
i386: Add kernel thread stack frame termination for properly stopping stack unwinds.
x86_64: Recover 1MB of kernel memory
x86_64: Remove alternative_smp
i386: Remove alternative_smp
x86: Disable MMCONFIG on Intel SDV using DMI blacklist
x86_64: Remove __KERNEL__ ifdef around _syscall*()
i386: Fix stack switching in do_IRQ
i386: Remove __KERNEL__ ifdef around _syscall*()
Andrew Morton:
USB: rtl8150_disconnect() needs tasklet_kill()
x86: increase MAX_MP_BUSSES on default arch
Badari Pulavarty:
manage-jbd-its-own-slab fix
Ben Dooks:
[ARM] 3764/1: S3C24XX: change type naming to kernel style
[ARM] 3765/1: S3C24XX: cleanup include/asm-arm/arch-s3c2410/dma.h
Benjamin Herrenschmidt:
[POWERPC] Fix performance regression in IRQ radix tree locking
[POWERPC] Fix MPIC sense codes in documentation
[POWERPC] Make OF irq map code detect more error cases
fbdev: Fix crashes in various fbdev's blank routines
powerpc: More via-pmu backlight fixes
powerpc: Fix PowerMac IRQ handling bug
backlight last round of fixes
powerpc: Fix typo in powermac platform functions
Bill Huey (hui:
xtensa: ptrace: EXIT_ZOMBIE fix
Chris Wright:
i386: rwlock.h fix smp alternatives fix
Christoph Lameter:
[IA64] Increase default nodes shift to 10, nr_cpus to 1024
ZVC: Overstep counters
ZVC: Scale thresholds depending on the size of the system
Corey Minyard:
IPMI: fix occasional oops on module unload
Daikichi Osuga:
[TCP]: Two RFC3465 Appropriate Byte Count fixes.
Daniel Jacobowitz:
[ARM] 3748/3: Correct error check in vfp_raise_exceptions
[ARM] 3749/3: Correct VFP single/double conversion emulation
[ARM] 3758/1: Preserve signalling NaNs in conversion
[ARM] 3750/3: Fix double VFP emulation for EABI kernels
David Brownell:
[ARM] 3741/1: remove sa1111.c build warning on non-sa1100 systems
[ARM] 3763/1: add both rtcs to csb337 defconfig
usb gadget: g_ether spinlock recursion fix
David S. Miller:
[E100]: Add module option to ignore bad EEPROM checksums.
[SPARC64]: Fix X server hangs due to large pages.
Dean Nelson:
[IA64-SGI] Silent data corruption caused by XPC V2.
George G. Davis:
[ARM] 3762/1: Fix ptrace cache coherency bug for ARM1136 VIPT nonaliasing Harvard caches
Heiko Carstens:
[S390] cio: kernel stack overflow.
Helge Deller:
[SERIAL] 8250: constify some serial structs
Henrik Kretzschmar:
kerneldoc for handle_bad_irq()
Horst Hummel:
[S390] dasd: fix device shutdown process.
Ian E. Morgan:
SBC8360: module_param() permission fixes
Jan Beulich:
x86: fix x86 cpuid keys used in alternative_smp()
x86: Make backtracer fallback logic more bullet-proof
Jeremy Allison:
[CIFS]
Jeremy Roberson:
hid-core.c: Adds all GTCO CalComp Digitizers and InterWrite School Products to blacklist
John Keller:
sgiioc4: fixup use of mmio ops
john stultz:
Fix faulty HPET clocksource usage (fix for bug #7062)
Jon Loeliger:
[POWERPC] Allow MPC8641 HPCN to build with CONFIG_PCI disabled too.
[POWERPC] Use mpc8641hpcn PIC base address from dev tree.
[email protected]:
USB floppy drive SAMSUNG SFD-321U/EP detected 8 times
Keir Fraser:
[IPV6]: ipv6_add_addr should install dstentry earlier
Keith Owens:
x86_64: Save original IST values for checking stack addresses
Kim Phillips:
[POWERPC] back up old school ipic.[hc] to arch/ppc
[POWERPC] Adapt ipic driver to new host_ops interface, add set_irq_type to set IRQ sense
[POWERPC] modify mpc83xx platforms to use new IRQ layer
[POWERPC] Add MPC8349E MDS device tree source file to arch/powerpc/boot/dts
Krzysztof Helt:
[SUNLANCE]: Fix probing problem.
Lennert Buytenhek:
[ARM] 3761/1: fix armv4t breakage after adding thumb interworking to userspace helpers
Linus Torvalds:
Linux 2.6.18-rc6
Lv Liangying:
[IPV6]: SNMPv2 "ipv6IfStatsInAddrErrors" counter error
Mark Hindley:
USB: Add VIA quirk fixup for VT8235 usb2
Martin Schwidefsky:
[S390] broken copy_in_user function.
Matt Porter:
[POWERPC] Remove flush_dcache_all export
[POWERPC] Fix powerpc 44x_mmu build
Nathan Scott:
[XFS] Update the MAINTAINERS file entry for XFS.
NeilBrown:
md: Fix issues with referencing rdev in md/raid1
Nishanth Aravamudan:
fix NUMA interleaving for huge pages
Nobuhiro Iwamatsu:
USB: Support for ELECOM LD-USB20 in pegasus
Olaf Hering:
exit early in floppy_init when no floppy exists
Oleg Nesterov:
eligible_child: remove an obsolete ->tgid check
Paul Fulghum:
synclink_gt: fix receive tty error handling
Paul Jackson:
[IA64] panic if topology_init kzalloc fails
Paul Mackerras:
[POWERPC] Restore copyright notice in arch/powerpc/kernel/fpu.S
[POWERPC] Fix problem with time not advancing on 32-bit platforms
[POWERPC] Fix irq enable/disable in smp_generic_take_timebase
[POWERPC] Fix return value from memcpy
ppc32: fix last_jiffy time comparison
Paul Sokolovsky:
[ARM] 3760/1: This patch adds timeouts while working with SSP registers. Such timeouts were en
Pavel Mironchik:
dm: work around mempool_alloc, bio_alloc_bioset deadlocks
Peter Horton:
[SERIAL] Support for Intashield 2 port PCI serial card
Peter Oberparleiter:
[S390] cio: no path after machine check.
Phil Dibowitz:
USB Storage: Remove the finecam3 unusual_devs entry
USB Storage: unusual_devs.h for Sony Ericsson M600i
Ping Cheng:
USB: add all wacom device to hid-core.c blacklist
Roland Dreier:
IB/mthca: Use IRQ safe locks to protect allocation bitmaps
Roland Scheidegger:
drm: radeon flush TCL VAP for vertex program enable/disable
Russ Anderson:
[IA64] remove redundant local_irq_save() calls from sn_sal.h
Russell King:
[ARM] Arrange for isa.c to use named initialisers
[ARM] Move prototype for register_isa_ports to asm/io.h
[ARM] Add Integrator support for glibc outb() and friends
[ARM] Fix ARM __raw_read_trylock() implementation
Sergei Shtylyov:
[SERIAL] Make uart_match_port() work with all memory mapped UARTs
Shailabh Nagar:
task delay accounting fixes
Sridhar Samudrala:
[SCTP]: Fix sctp_primitive_ABORT() call in sctp_close().
Stefan Bader:
[S390] cio: unsolicited interrupts during sense pgid.
Stephen Hemminger:
[STRIP]: Fix neighbour table refcount leak.
Stephen Rothwell:
[POWERPC] iseries: Define insw et al. so libata/ide will compile
Steve French:
[CIFS] Do not time out posix brl requests when using new posix setfileinfo
[CIFS] spinlock protect read of last srv response time in timeout path
[CIFS] Make midState usage more consistent
[CIFS] Allow cifsd to suspend if connection is lost
[CIFS] Fix oops when negotiating lanman and no password specified
[CIFS] Fix oops in cifs_close due to unitialized lock sem and list in
[CIFS] endian errors in lanman protocol support
[CIFS] Do not send Query All EAs SMB when mount option nouser_xattr
Suleiman Souhlal:
x86_64: Don't write out segments from vsyscall32 DSO if it is not mapped
Takashi Iwai:
ALSA: ac97: correct some Mic mixer elements
Wei Dong:
[IPV4]: Fix SNMPv2 "ipFragFails" counter error
Will Schmidt:
[POWERPC] Fix up ibm_architecture_vec definition
YOSHIFUJI Hideaki:
[IPV6]: Fix kernel OOPs when setting sticky socket options.
Zang Roy-r61911:
[POWERPC] Add mpc7448hpc2 device tree source file
[POWERPC] Support for "weird" MPICs and fixup mpc7448_hpc2
--- diffstat snip snip ---
Documentation/feature-removal-schedule.txt | 7
Documentation/kernel-parameters.txt | 2
Documentation/powerpc/booting-without-of.txt | 6
MAINTAINERS | 3
Makefile | 2
arch/arm/Makefile | 3
arch/arm/common/sa1111.c | 6
arch/arm/configs/csb337_defconfig | 37 +
arch/arm/kernel/Makefile | 3
arch/arm/kernel/isa.c | 63 +
arch/arm/mach-footbridge/dc21285.c | 1
arch/arm/mach-integrator/pci_v3.c | 2
arch/arm/mach-pxa/corgi_ssp.c | 20
arch/arm/mach-pxa/ssp.c | 35 +
arch/arm/mach-s3c2410/dma.c | 88 +-
arch/arm/mach-sa1100/ssp.c | 46 +
arch/arm/mm/Kconfig | 13
arch/arm/mm/flush.c | 26 +
arch/arm/vfp/vfp.h | 18
arch/arm/vfp/vfpdouble.c | 50 +
arch/arm/vfp/vfphw.S | 10
arch/arm/vfp/vfpmodule.c | 4
arch/arm/vfp/vfpsingle.c | 55 +
arch/i386/kernel/head.S | 14
arch/i386/kernel/hpet.c | 2
arch/i386/kernel/irq.c | 5
arch/i386/kernel/setup.c | 32 -
arch/i386/kernel/traps.c | 27 -
arch/i386/pci/common.c | 5
arch/i386/pci/mmconfig.c | 34 +
arch/i386/pci/pci.h | 3
arch/ia64/Kconfig | 4
arch/ia64/kernel/topology.c | 6
arch/ia64/sn/kernel/xpc_channel.c | 4
arch/ia64/sn/kernel/xpc_main.c | 28 -
arch/ia64/sn/kernel/xpc_partition.c | 24 -
arch/powerpc/Kconfig | 20
arch/powerpc/boot/dts/mpc7448hpc2.dts | 190 ++++
arch/powerpc/boot/dts/mpc8349emds.dts | 328 ++++++++
arch/powerpc/configs/mpc834x_mds_defconfig | 915 +++++++++++++++++++++
arch/powerpc/configs/mpc834x_sys_defconfig | 915 ---------------------
arch/powerpc/kernel/fpu.S | 5
arch/powerpc/kernel/irq.c | 84 ++
arch/powerpc/kernel/pci_64.c | 11
arch/powerpc/kernel/ppc_ksyms.c | 4
arch/powerpc/kernel/prom_init.c | 10
arch/powerpc/kernel/prom_parse.c | 17
arch/powerpc/kernel/smp-tbsync.c | 5
arch/powerpc/kernel/time.c | 25 -
arch/powerpc/lib/memcpy_64.S | 11
arch/powerpc/mm/44x_mmu.c | 4
arch/powerpc/platforms/83xx/mpc834x_itx.c | 49 -
arch/powerpc/platforms/83xx/mpc834x_sys.c | 56 -
arch/powerpc/platforms/83xx/mpc83xx.h | 1
arch/powerpc/platforms/83xx/pci.c | 9
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 26 -
arch/powerpc/platforms/86xx/pci.c | 3
arch/powerpc/platforms/embedded6xx/Kconfig | 1
arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c | 2
arch/powerpc/platforms/powermac/pfunc_base.c | 2
arch/powerpc/platforms/powermac/pic.c | 6
arch/powerpc/sysdev/Makefile | 4
arch/powerpc/sysdev/ipic.c | 303 +++++--
arch/powerpc/sysdev/ipic.h | 23 -
arch/powerpc/sysdev/mpic.c | 223 ++++-
arch/ppc/kernel/smp-tbsync.c | 7
arch/ppc/syslib/Makefile | 2
arch/ppc/syslib/ipic.c | 646 +++++++++++++++
arch/ppc/syslib/ipic.h | 47 +
arch/s390/lib/uaccess.S | 33 -
arch/s390/lib/uaccess64.S | 35 -
arch/sparc64/mm/generic.c | 2
arch/x86_64/defconfig | 66 --
arch/x86_64/ia32/ia32_binfmt.c | 57 +
arch/x86_64/kernel/e820.c | 35 -
arch/x86_64/kernel/entry.S | 3
arch/x86_64/kernel/head.S | 1
arch/x86_64/kernel/init_task.c | 5
arch/x86_64/kernel/setup.c | 6
arch/x86_64/kernel/setup64.c | 3
arch/x86_64/kernel/traps.c | 30 -
arch/x86_64/pci/mmconfig.c | 34 +
arch/xtensa/kernel/ptrace.c | 2
drivers/block/floppy.c | 12
drivers/char/drm/radeon_state.c | 9
drivers/char/ipmi/ipmi_msghandler.c | 1
drivers/char/synclink_gt.c | 14
drivers/char/watchdog/sbc8360.c | 4
drivers/ide/pci/sgiioc4.c | 60 +
drivers/ide/pci/via82cxxx.c | 3
drivers/infiniband/hw/mthca/mthca_allocator.c | 15
drivers/macintosh/via-pmu-backlight.c | 99 +-
drivers/macintosh/via-pmu.c | 12
drivers/md/raid1.c | 57 +
drivers/net/e100.c | 6
drivers/net/sunlance.c | 27 -
drivers/net/wireless/strip.c | 6
drivers/pci/quirks.c | 1
drivers/s390/block/dasd.c | 192 +++-
drivers/s390/block/dasd_genhd.c | 10
drivers/s390/cio/ccwgroup.c | 14
drivers/s390/cio/chsc.c | 10
drivers/s390/cio/device.c | 19
drivers/s390/cio/device_fsm.c | 20
drivers/s390/cio/device_pgid.c | 27 -
drivers/serial/8250_pci.c | 31 +
drivers/serial/serial_core.c | 3
drivers/usb/gadget/ether.c | 45 +
drivers/usb/host/uhci-q.c | 4
drivers/usb/input/hid-core.c | 149 ++-
drivers/usb/net/pegasus.h | 3
drivers/usb/net/rtl8150.c | 1
drivers/usb/storage/unusual_devs.h | 24 -
drivers/video/aty/aty128fb.c | 18
drivers/video/aty/atyfb_base.c | 18
drivers/video/aty/radeon_backlight.c | 4
drivers/video/nvidia/nv_backlight.c | 18
drivers/video/riva/fbdev.c | 18
fs/cifs/CHANGES | 10
fs/cifs/README | 2
fs/cifs/cifsencrypt.c | 3
fs/cifs/cifsfs.c | 6
fs/cifs/cifsfs.h | 2
fs/cifs/cifsglob.h | 18
fs/cifs/cifsproto.h | 4
fs/cifs/cifssmb.c | 28 +
fs/cifs/connect.c | 32 +
fs/cifs/dir.c | 4
fs/cifs/file.c | 97 ++
fs/cifs/netmisc.c | 1
fs/cifs/readdir.c | 2
fs/cifs/sess.c | 2
fs/cifs/smberr.h | 1
fs/cifs/transport.c | 618 +++++++++-----
fs/cifs/xattr.c | 6
fs/jbd/transaction.c | 2
fs/xfs/xfs_bmap.c | 2
include/asm-arm/arch-pxa/ssp.h | 4
include/asm-arm/arch-s3c2410/dma.h | 150 ++-
include/asm-arm/cacheflush.h | 18
include/asm-arm/hardware/ssp.h | 4
include/asm-arm/io.h | 7
include/asm-arm/spinlock.h | 16
include/asm-i386/alternative.h | 20
include/asm-i386/mach-default/mach_mpspec.h | 4
include/asm-i386/rwlock.h | 28 -
include/asm-i386/spinlock.h | 17
include/asm-i386/unistd.h | 4
include/asm-i386/unwind.h | 1
include/asm-ia64/sn/sn_sal.h | 6
include/asm-ia64/sn/xp.h | 22 -
include/asm-ia64/sn/xpc.h | 4
include/asm-powerpc/io.h | 7
include/asm-powerpc/ipic.h | 12
include/asm-powerpc/mpc86xx.h | 3
include/asm-powerpc/mpic.h | 125 +++
include/asm-powerpc/prom.h | 4
include/asm-powerpc/time.h | 4
include/asm-x86_64/alternative.h | 21
include/asm-x86_64/processor.h | 6
include/asm-x86_64/spinlock.h | 11
include/asm-x86_64/unistd.h | 11
include/asm-x86_64/unwind.h | 1
include/linux/delayacct.h | 10
include/linux/mmzone.h | 1
include/linux/pci_ids.h | 4
include/linux/sched.h | 1
kernel/delayacct.c | 16
kernel/exit.c | 3
kernel/fork.c | 6
kernel/irq/handle.c | 5
mm/mempolicy.c | 10
mm/mempool.c | 9
mm/vmstat.c | 151 +++
net/ipv4/ip_output.c | 1
net/ipv4/tcp_cong.c | 2
net/ipv4/tcp_input.c | 9
net/ipv6/addrconf.c | 4
net/ipv6/exthdrs.c | 29 -
net/ipv6/route.c | 4
net/netlink/af_netlink.c | 14
net/sctp/socket.c | 10
net/socket.c | 3
sound/oss/Kconfig | 30 +
sound/pci/ac97/ac97_codec.c | 4
185 files changed, 4986 insertions(+), 2598 deletions(-)
--
VGER BF report: S 0.999339
On Sunday 03 September 2006 22:42, Linus Torvalds wrote:
>Things are definitely calming down, and while I'm not ready to call it a
>final 2.6.18 yet, this migt be the last -rc.
>
It has one new build warning, no idea if show stopper or not:
----------
drivers/usb/input/hid-core.c:1447:1: warning: "USB_DEVICE_ID_GTCO_404"
redefined
drivers/usb/input/hid-core.c:1446:1: warning: this is the location of the
previous definition
----------
until after I boot to it...
And that didn't seem to effect the mouse. Other usb stuff has not been
exersized yet.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
--
VGER BF report: U 0.623711
On Mon, Sep 04, 2006 at 07:05:53AM -0400, Gene Heskett wrote:
> On Sunday 03 September 2006 22:42, Linus Torvalds wrote:
> >Things are definitely calming down, and while I'm not ready to call it a
> >final 2.6.18 yet, this migt be the last -rc.
> >
> It has one new build warning, no idea if show stopper or not:
> ----------
> drivers/usb/input/hid-core.c:1447:1: warning: "USB_DEVICE_ID_GTCO_404"
> redefined
> drivers/usb/input/hid-core.c:1446:1: warning: this is the location of the
> previous definition
> ----------
> until after I boot to it...
>
> And that didn't seem to effect the mouse. Other usb stuff has not been
> exersized yet.
The offending patch is
hid-core.c: Adds all GTCO CalComp Digitizers and InterWrite School Products to blacklist
If one looks at this patch it seems to be just a typo.
The patch below fixes at least the warning.
--- vanilla-2.6.18-rc6/drivers/usb/input/hid-core.c 2006-09-04 04:19:48.000000000 +0200
+++ linux-2.6.18-rc6/drivers/usb/input/hid-core.c 2006-09-04 23:53:10.000000000 +0200
@@ -1444,7 +1444,7 @@
#define USB_DEVICE_ID_GTCO_402 0x0402
#define USB_DEVICE_ID_GTCO_403 0x0403
#define USB_DEVICE_ID_GTCO_404 0x0404
-#define USB_DEVICE_ID_GTCO_404 0x0405
+#define USB_DEVICE_ID_GTCO_405 0x0405
#define USB_DEVICE_ID_GTCO_500 0x0500
#define USB_DEVICE_ID_GTCO_501 0x0501
#define USB_DEVICE_ID_GTCO_502 0x0502
@@ -1657,7 +1657,7 @@
{ USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_402, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_403, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_404, HID_QUIRK_IGNORE },
- { USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_404, HID_QUIRK_IGNORE },
+ { USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_405, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_500, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_501, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_502, HID_QUIRK_IGNORE },
On Monday 04 September 2006 18:31, Steffen Klassert wrote:
>On Mon, Sep 04, 2006 at 07:05:53AM -0400, Gene Heskett wrote:
>> On Sunday 03 September 2006 22:42, Linus Torvalds wrote:
>> >Things are definitely calming down, and while I'm not ready to call it
>> > a final 2.6.18 yet, this migt be the last -rc.
>>
>> It has one new build warning, no idea if show stopper or not:
>> ----------
>> drivers/usb/input/hid-core.c:1447:1: warning: "USB_DEVICE_ID_GTCO_404"
>> redefined
>> drivers/usb/input/hid-core.c:1446:1: warning: this is the location of
>> the previous definition
>> ----------
>> until after I boot to it...
>>
>> And that didn't seem to effect the mouse. Other usb stuff has not been
>> exersized yet.
>
>The offending patch is
>hid-core.c: Adds all GTCO CalComp Digitizers and InterWrite School
> Products to blacklist
>
>If one looks at this patch it seems to be just a typo.
>The patch below fixes at least the warning.
>
>--- vanilla-2.6.18-rc6/drivers/usb/input/hid-core.c 2006-09-04
> 04:19:48.000000000 +0200 +++
> linux-2.6.18-rc6/drivers/usb/input/hid-core.c 2006-09-04
> 23:53:10.000000000 +0200 @@ -1444,7 +1444,7 @@
> #define USB_DEVICE_ID_GTCO_402 0x0402
> #define USB_DEVICE_ID_GTCO_403 0x0403
> #define USB_DEVICE_ID_GTCO_404 0x0404
>-#define USB_DEVICE_ID_GTCO_404 0x0405
>+#define USB_DEVICE_ID_GTCO_405 0x0405
> #define USB_DEVICE_ID_GTCO_500 0x0500
> #define USB_DEVICE_ID_GTCO_501 0x0501
> #define USB_DEVICE_ID_GTCO_502 0x0502
>@@ -1657,7 +1657,7 @@
> { USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_402, HID_QUIRK_IGNORE },
> { USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_403, HID_QUIRK_IGNORE },
> { USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_404, HID_QUIRK_IGNORE },
>- { USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_404, HID_QUIRK_IGNORE },
>+ { USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_405, HID_QUIRK_IGNORE },
> { USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_500, HID_QUIRK_IGNORE },
> { USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_501, HID_QUIRK_IGNORE },
> { USB_VENDOR_ID_GTCO, USB_DEVICE_ID_GTCO_502, HID_QUIRK_IGNORE },
>-
I did apply this patch, with vim as its only 2 characters that are actually
changed. But now I'm going to go back and look at the log from before I
rebooted to this patch. Yes, since 2.6.18-rc6, I'm getting these in the
log, and this patch obviously has no effect on the below log entries.
--------------
Sep 3 15:20:10 coyote kernel: usb 3-2.1: reset low speed USB device using
ohci_hcd and address 3
Sep 3 15:33:14 coyote kernel: usb 3-2.1: reset low speed USB device using
ohci_hcd and address 3
Sep 3 15:47:25 coyote kernel: usb 3-2.1: reset low speed USB device using
ohci_hcd and address 3
Sep 3 15:56:45 coyote kernel: usb 3-2.1: reset low speed USB device using
ohci_hcd and address 3
Sep 3 16:08:05 coyote kernel: usb 3-2.1: reset low speed USB device using
ohci_hcd and address 3
Sep 3 16:17:24 coyote kernel: usb 3-2.1: reset low speed USB device using
ohci_hcd and address 3
Sep 3 16:37:13 coyote kernel: usb 3-2.1: reset low speed USB device using
ohci_hcd and address 3
Sep 3 16:48:12 coyote kernel: usb 3-2.1: reset low speed USB device using
ohci_hcd and address 3
Sep 3 17:19:10 coyote kernel: usb 3-2.1: reset low speed USB device using
ohci_hcd and address 3
Sep 3 17:26:16 coyote kernel: usb 3-2.1: reset low speed USB device using
ohci_hcd and address 3
Sep 3 17:36:22 coyote kernel: usb 3-2.1: reset low speed USB device using
ohci_hcd and address 3
Sep 3 17:42:18 coyote kernel: usb 3-2.1: reset low speed USB device using
ohci_hcd and address 3
Sep 3 17:51:46 coyote kernel: usb 3-2.1: reset low speed USB device using
ohci_hcd and address 3
Sep 3 18:03:08 coyote kernel: usb 3-2.1: reset low speed USB device using
ohci_hcd and address 3
Sep 3 18:16:52 coyote kernel: usb 3-2.1: reset low speed USB device using
ohci_hcd and address 3
Sep 3 18:35:08 coyote kernel: usb 3-2.1: reset low speed USB device using
ohci_hcd and address 3
Sep 3 18:43:34 coyote kernel: usb 3-2.1: reset low speed USB device using
ohci_hcd and address 3
Sep 3 18:52:31 coyote kernel: usb 3-2.1: reset low speed USB device using
ohci_hcd and address 3
Sep 3 19:10:15 coyote kernel: usb 3-2.1: reset low speed USB device using
ohci_hcd and address 3
Sep 3 19:27:17 coyote kernel: usb 3-2.1: reset low speed USB device using
ohci_hcd and address 3
Sep 3 19:35:45 coyote kernel: usb 3-2.1: reset low speed USB device using
ohci_hcd and address 3
-----------
And they are being logged at times when I am nowhere near the mouse to move
it, at varying intervals of 2-3 a minute as you can see above.
Is there a way to shut this up? The mouse is working great, although its
possible the battery is getting weak.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
On Sun, Sep 03, Linus Torvalds wrote:
>
> Things are definitely calming down, and while I'm not ready to call it a
> final 2.6.18 yet, this migt be the last -rc.
There is a regression on LVD drives (?) since early 2.6.18rc
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=60eef25701d25e99c991dd0f4a9f3832a0c3ad3e
I get a machine check on an older B&W G3.
<5>SCSI subsystem initialized
<6>st: Version 20050830, fixed bufsize 32768, s/g segs 256
<6>loop: loaded (max 8 devices)
<3>pmac_zilog 0.00013000:ch-b: irda_setup timed out on get_version byte
<6>scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
<4> <Adaptec 2940B Ultra2 SCSI adapter>
<4> aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs
<4>
<5> Vendor: IBM Model: DDRS-39130D Rev: DC2A
<5> Type: Direct-Access ANSI SCSI revision: 02
<4>scsi0:A:0:0: Tagged Queuing enabled. Depth 32
<6> target0:0:0: Beginning Domain Validation
<6> target0:0:0: wide asynchronous
<4>Machine check in kernel mode.
<4>Caused by (from SRR1=49030): Transfer error ack signal
<4>Oops: Machine check, sig: 7 [#1]
<4>
<4>Modules linked in: aic7xxx scsi_transport_spi cpufreq_ondemand loop nfs nfs_acl lockd sunrpc sg st sd_mod sr_mod scsi_mod ide_cd cdrom
<4>NIP: D21F03A0 LR: D20D9494 CTR: D21F0388
<4>REGS: cf5059f0 TRAP: 0200 Not tainted (2.6.18-rc6-20060905-default)
<4>MSR: 00049030 <EE,ME,IR,DR> CR: 22022242 XER: 00000000
<4>TASK = cf1d9990[963] 'insmod' THREAD: cf504000
<6>GPR00: 000000FF CF505AA0 CF1D9990 CF513400 CF505A6C CF564C00 CF564D00 00000000
<6>GPR08: 00000001 D105C000 CF64D400 00000000 F2841C80 100290EC 0000000F D22BFB50
<6>GPR16: 0000001E D229EDD0 CFC52500 D229EDA8 CF5139CC CF513818 CF5138BC CF513400
<6>GPR24: CF513800 CF5139A0 FFFFFFFF C37C0000 CF5139A0 CF513800 CF513000 CF513C00
<4>NIP [D21F03A0] ahc_linux_get_signalling+0x18/0xa8 [aic7xxx]
<4>LR [D20D9494] spi_dv_device+0x338/0x51c [scsi_transport_spi]
<4>Call Trace:
<4>[CF505AA0] [D20D9364] spi_dv_device+0x208/0x51c [scsi_transport_spi] (unreliable)
<4>[CF505AF0] [D21F0808] ahc_linux_slave_configure+0xfc/0x114 [aic7xxx]
<4>[CF505B30] [D20B71D8] scsi_probe_and_add_lun+0x8d4/0xa40 [scsi_mod]
<4>[CF505B90] [D20B78F8] __scsi_scan_target+0xd8/0x630 [scsi_mod]
<4>[CF505C20] [D20B7E9C] scsi_scan_channel+0x4c/0x9c [scsi_mod]
<4>[CF505C40] [D20B7FD4] scsi_scan_host_selected+0xe8/0x140 [scsi_mod]
<4>[CF505C70] [D21F3998] ahc_linux_register_host+0x344/0x35c [aic7xxx]
<4>[CF505D10] [D21F468C] ahc_linux_pci_dev_probe+0x1a8/0x1c8 [aic7xxx]
<4>[CF505D80] [C016A49C] pci_device_probe+0x6c/0xa0
<4>[CF505DA0] [C01F0AF4] driver_probe_device+0x60/0xf4
<4>[CF505DC0] [C01F0CC4] __driver_attach+0x8c/0xf0
<4>[CF505DE0] [C01F0424] bus_for_each_dev+0x50/0x94
<4>[CF505E10] [C01F0A08] driver_attach+0x24/0x34
<4>[CF505E20] [C01F000C] bus_add_driver+0x78/0x128
<4>[CF505E40] [C01F0FC4] driver_register+0xa0/0xb4
<4>[CF505E50] [C016A2C8] __pci_register_driver+0x4c/0x8c
<4>[CF505E60] [D21F44CC] ahc_linux_pci_init+0x20/0x38 [aic7xxx]
<4>[CF505E70] [D105A3C0] ahc_linux_init+0x3c0/0x530 [aic7xxx]
<4>[CF505EA0] [C004EB50] sys_init_module+0x1368/0x14f8
<4>[CF505F40] [C00125A4] ret_from_syscall+0x0/0x40
<4>--- Exception: c01 at 0xff698a4
<4> LR = 0x10001100
<4>Instruction dump:
<4>38600000 4e800020 38600000 4e800020 4e800020 4e800020 814302ac 800a0000
<4>2f800000 409e0018 812a0004 8809001f <0c000000> 4c00012c 48000028 812a0004
<4> scsi0: PCI error Interrupt at seqaddr = 0x8
<4>scsi0: Signaled a Target Abort
Here is the dmesg from a working 2.6.16 kernel:
...
SCSI subsystem initialized
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
<Adaptec 2940B Ultra2 SCSI adapter>
aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs
Vendor: IBM Model: DDRS-39130D Rev: DC2A
Type: Direct-Access ANSI SCSI revision: 02
scsi0:A:0:0: Tagged Queuing enabled. Depth 32
target0:0:0: Beginning Domain Validation
target0:0:0: wide asynchronous
target0:0:0: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 15)
target0:0:0: Domain Validation skipping write tests
target0:0:0: Ending Domain Validation
SCSI device sda: 17850000 512-byte hdwr sectors (9139 MB)
sda: Write Protect is off
sda: Mode Sense: e5 00 00 08
SCSI device sda: drive cache: write back
SCSI device sda: 17850000 512-byte hdwr sectors (9139 MB)
sda: Write Protect is off
sda: Mode Sense: e5 00 00 08
SCSI device sda: drive cache: write back
sda: [mac] sda1 sda2 sda3 sda4 sda5 sda6
sd 0:0:0:0: Attached scsi disk sda
sd 0:0:0:0: Attached scsi generic sg0 type 0
Vendor: IBM Model: DNES-318350W Rev: SA30
Type: Direct-Access ANSI SCSI revision: 03
scsi0:A:2:0: Tagged Queuing enabled. Depth 32
target0:0:2: Beginning Domain Validation
target0:0:2: wide asynchronous
target0:0:2: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
target0:0:2: Domain Validation skipping write tests
target0:0:2: Ending Domain Validation
SCSI device sdb: 35843670 512-byte hdwr sectors (18352 MB)
sdb: Write Protect is off
sdb: Mode Sense: c3 00 00 08
SCSI device sdb: drive cache: write back
SCSI device sdb: 35843670 512-byte hdwr sectors (18352 MB)
sdb: Write Protect is off
sdb: Mode Sense: c3 00 00 08
SCSI device sdb: drive cache: write back
sdb: [mac] sdb1 sdb2 sdb3 sdb4 sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 sdb12 sdb13
sd 0:0:2:0: Attached scsi disk sdb
sd 0:0:2:0: Attached scsi generic sg1 type 0
mesh: configured for synchronous 5 MB/s
mesh: performing initial bus reset...
scsi1 : MESH
ReiserFS: sda4: found reiserfs format "3.6" with standard journal
ReiserFS: sda4: using ordered data mode
...
On Tue, Sep 05, 2006 at 02:26:56PM +0200, Olaf Hering wrote:
> On Sun, Sep 03, Linus Torvalds wrote:
>
> >
> > Things are definitely calming down, and while I'm not ready to call it a
> > final 2.6.18 yet, this migt be the last -rc.
>
there is a regression since 2.6.17 on some boxes:
http://bugzilla.kernel.org/show_bug.cgi?id=6875
http://bugzilla.kernel.org/show_bug.cgi?id=6920
the attached patch is known to fix the regression:
http://bugzilla.kernel.org/attachment.cgi?id=8798&action=view
--
maks
On Tuesday 05 September 2006 01:17, Gene Heskett wrote:
> On Monday 04 September 2006 18:31, Steffen Klassert wrote:
> >On Mon, Sep 04, 2006 at 07:05:53AM -0400, Gene Heskett wrote:
> >> On Sunday 03 September 2006 22:42, Linus Torvalds wrote:
> >> >Things are definitely calming down, and while I'm not ready to call it
> >> > a final 2.6.18 yet, this migt be the last -rc.
> >>
> >> It has one new build warning, no idea if show stopper or not:
> >> ----------
> >> drivers/usb/input/hid-core.c:1447:1: warning: "USB_DEVICE_ID_GTCO_404"
> >> redefined
> >> drivers/usb/input/hid-core.c:1446:1: warning: this is the location of
> >> the previous definition
> >> ----------
> >> until after I boot to it...
> >>
> >> And that didn't seem to effect the mouse. Other usb stuff has not been
> >> exersized yet.
> >
> >The offending patch is
> >hid-core.c: Adds all GTCO CalComp Digitizers and InterWrite School
> > Products to blacklist
[snip]
> Sep 3 19:27:17 coyote kernel: usb 3-2.1: reset low speed USB device using
> ohci_hcd and address 3
> Sep 3 19:35:45 coyote kernel: usb 3-2.1: reset low speed USB device using
> ohci_hcd and address 3
Might not be a kernel problem, userspace might be using libusb and calling
usb_reset() on the device. Try dropping out of X11 and see if it still
happens.
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
On Tue, Sep 05, 2006 at 02:45:05PM +0200, maximilian attems wrote:
> On Tue, Sep 05, 2006 at 02:26:56PM +0200, Olaf Hering wrote:
> > On Sun, Sep 03, Linus Torvalds wrote:
> >
> > >
> > > Things are definitely calming down, and while I'm not ready to call it a
> > > final 2.6.18 yet, this migt be the last -rc.
> >
>
> there is a regression since 2.6.17 on some boxes:
> http://bugzilla.kernel.org/show_bug.cgi?id=6875
> http://bugzilla.kernel.org/show_bug.cgi?id=6920
>
> the attached patch is known to fix the regression:
> http://bugzilla.kernel.org/attachment.cgi?id=8798&action=view
The fix for this (your referenced patch) is already in 2.6.18-rc5. Does
it not work properly for you?
thanks,
greg k-h
On Tue, Sep 05, 2006 at 11:56:41AM -0700, Greg KH wrote:
> On Tue, Sep 05, 2006 at 02:45:05PM +0200, maximilian attems wrote:
> > On Tue, Sep 05, 2006 at 02:26:56PM +0200, Olaf Hering wrote:
> > > On Sun, Sep 03, Linus Torvalds wrote:
> > >
> > > >
> > > > Things are definitely calming down, and while I'm not ready to call it a
> > > > final 2.6.18 yet, this migt be the last -rc.
> > >
> >
> > there is a regression since 2.6.17 on some boxes:
> > http://bugzilla.kernel.org/show_bug.cgi?id=6875
> > http://bugzilla.kernel.org/show_bug.cgi?id=6920
> >
> > the attached patch is known to fix the regression:
> > http://bugzilla.kernel.org/attachment.cgi?id=8798&action=view
>
> The fix for this (your referenced patch) is already in 2.6.18-rc5. Does
> it not work properly for you?
>
> thanks,
>
> greg k-h
great that's why i didn't see it in latest -mm.
not affected myself,
but 2.6.17 + patch build for bug reporter works fine.
please consider it for next stable release.
thanks
--
maks
On Tuesday 05 September 2006 12:04, Alistair John Strachan wrote:
>On Tuesday 05 September 2006 01:17, Gene Heskett wrote:
>> On Monday 04 September 2006 18:31, Steffen Klassert wrote:
>> >On Mon, Sep 04, 2006 at 07:05:53AM -0400, Gene Heskett wrote:
>> >> On Sunday 03 September 2006 22:42, Linus Torvalds wrote:
>> >> >Things are definitely calming down, and while I'm not ready to call
>> >> > it a final 2.6.18 yet, this migt be the last -rc.
>> >>
>> >> It has one new build warning, no idea if show stopper or not:
>> >> ----------
>> >> drivers/usb/input/hid-core.c:1447:1: warning:
>> >> "USB_DEVICE_ID_GTCO_404" redefined
>> >> drivers/usb/input/hid-core.c:1446:1: warning: this is the location
>> >> of the previous definition
>> >> ----------
>> >> until after I boot to it...
>> >>
>> >> And that didn't seem to effect the mouse. Other usb stuff has not
>> >> been exersized yet.
>> >
>> >The offending patch is
>> >hid-core.c: Adds all GTCO CalComp Digitizers and InterWrite School
>> > Products to blacklist
>
>[snip]
>
>> Sep 3 19:27:17 coyote kernel: usb 3-2.1: reset low speed USB device
>> using ohci_hcd and address 3
>> Sep 3 19:35:45 coyote kernel: usb 3-2.1: reset low speed USB device
>> using ohci_hcd and address 3
>
>Might not be a kernel problem, userspace might be using libusb and
> calling usb_reset() on the device. Try dropping out of X11 and see if it
> still happens.
Unforch, its intermittent, and hasn't done it since the early evening hours
yesterday. As an experiment, I just moved another wireless M$ mouse that
normally sits on a corner of the same mousepad, one thats normally used
with my lappy, to a point a couple of feet away. Which if its crosstalk
in the base station, won't help as the base station is still about 4 feet
from both mice. I probably should take the battery out of it when the
lappy isn't running. M$ really should have put a power switch on a mouse
they know very well is going to be used on a lappy cause when you toss it
in the bag with the rest of the detrius of a laptop, it can't find a pad
surface and goes blinking crazy till you take the *&^$ battery out.
So I suspect I'm barking up the wrong tree after all... Sorry.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
On Tue, 2006-09-05 at 14:26 +0200, Olaf Hering wrote:
> <4>Machine check in kernel mode.
> <4>Caused by (from SRR1=49030): Transfer error ack signal
> <4>Oops: Machine check, sig: 7 [#1]
[...]
> <4> scsi0: PCI error Interrupt at seqaddr = 0x8
Is this actually a PCI bus error? In which case it's probably the
ahc_inb(,SBLKCTL) of ahc_linux_get_signalling(). Can you verify this?
And what happens when you try to cat /proc/scsi_host/host<n>/signalling
for this card?
James
On Tue, Sep 05, 2006 at 09:01:32PM +0200, maximilian attems wrote:
> On Tue, Sep 05, 2006 at 11:56:41AM -0700, Greg KH wrote:
> > On Tue, Sep 05, 2006 at 02:45:05PM +0200, maximilian attems wrote:
> > > On Tue, Sep 05, 2006 at 02:26:56PM +0200, Olaf Hering wrote:
> > > > On Sun, Sep 03, Linus Torvalds wrote:
> > > >
> > > > >
> > > > > Things are definitely calming down, and while I'm not ready to call it a
> > > > > final 2.6.18 yet, this migt be the last -rc.
> > > >
> > >
> > > there is a regression since 2.6.17 on some boxes:
> > > http://bugzilla.kernel.org/show_bug.cgi?id=6875
> > > http://bugzilla.kernel.org/show_bug.cgi?id=6920
> > >
> > > the attached patch is known to fix the regression:
> > > http://bugzilla.kernel.org/attachment.cgi?id=8798&action=view
> >
> > The fix for this (your referenced patch) is already in 2.6.18-rc5. Does
> > it not work properly for you?
> >
> > thanks,
> >
> > greg k-h
>
> great that's why i didn't see it in latest -mm.
> not affected myself,
> but 2.6.17 + patch build for bug reporter works fine.
>
> please consider it for next stable release.
Please forward it to the [email protected] address then so it can be
applied there :)
thanks,
greg k-h
On Tue, 2006-09-05 at 16:01 -0500, James Bottomley wrote:
> On Tue, 2006-09-05 at 14:26 +0200, Olaf Hering wrote:
> > <4>Machine check in kernel mode.
> > <4>Caused by (from SRR1=49030): Transfer error ack signal
> > <4>Oops: Machine check, sig: 7 [#1]
> [...]
> > <4> scsi0: PCI error Interrupt at seqaddr = 0x8
>
> Is this actually a PCI bus error? In which case it's probably the
> ahc_inb(,SBLKCTL) of ahc_linux_get_signalling(). Can you verify this?
> And what happens when you try to cat /proc/scsi_host/host<n>/signalling
> for this card?
Yes, it's a PCI error.
Ben.
On Wed, 2006-09-06 at 08:20 +1000, Benjamin Herrenschmidt wrote:
> Yes, it's a PCI error.
Thanks, and the cat of /proc/scsi_host/host<n>/signalling?
My suspicion is the register doesn't actually exist on this card so it
doesn't actually respond on the bus. However, on my equivalent
everything works; largely I think because the only PC's I have don't
know how to signal a PCI error.
James
On Tue, 2006-09-05 at 18:22 -0500, James Bottomley wrote:
> On Wed, 2006-09-06 at 08:20 +1000, Benjamin Herrenschmidt wrote:
> > Yes, it's a PCI error.
>
> Thanks, and the cat of /proc/scsi_host/host<n>/signalling?
>
> My suspicion is the register doesn't actually exist on this card so it
> doesn't actually respond on the bus. However, on my equivalent
> everything works; largely I think because the only PC's I have don't
> know how to signal a PCI error.
Olaf will tell us (I don't have the hardware) but it's indeed a typical
thing .... From my experience, Adaptec tend to very easily throw PCI
aborts at you if it doesn't like something in a register access (which
isn't necessarily a bad thing btw, other vendors are more lenient tho),
and Macs are well known to Machine Check the box when getting a PCI
error while most x86 boxes silently ignore them...
Ben.
On Tue, Sep 05, James Bottomley wrote:
> On Tue, 2006-09-05 at 14:26 +0200, Olaf Hering wrote:
> > <4>Machine check in kernel mode.
> > <4>Caused by (from SRR1=49030): Transfer error ack signal
> > <4>Oops: Machine check, sig: 7 [#1]
> [...]
> > <4> scsi0: PCI error Interrupt at seqaddr = 0x8
>
> Is this actually a PCI bus error? In which case it's probably the
> ahc_inb(,SBLKCTL) of ahc_linux_get_signalling(). Can you verify this?
> And what happens when you try to cat /proc/scsi_host/host<n>/signalling
> for this card?
This causes another machine check because it runs ahc_inb(ahc, SBLKCTL) again.
With debug I get:
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY_MS=5000
CONFIG_AIC7XXX_DEBUG_ENABLE=y
CONFIG_AIC7XXX_DEBUG_MASK=2047
CONFIG_AIC7XXX_REG_PRETTY_PRINT=y
<4>ahc_pci:1:4:0: hardware scb 64 bytes; kernel scb 52 bytes; ahc_dma 8 bytes
<6>scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
<4> <Adaptec 2940B Ultra2 SCSI adapter>
<4> aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs
<4>
<5> Vendor: IBM Model: DDRS-39130D Rev: DC2A
<5> Type: Direct-Access ANSI SCSI revision: 02
<4>scsi0:A:0:0: Tagged Queuing enabled. Depth 32
<6> target0:0:0: Beginning Domain Validation
<4>scsi0:A:0:0: INITIATOR_MSG_OUT byte 0xc0
<4>scsi0:A:0:0: INITIATOR_MSG_OUT byte 0x20
<4>scsi0:A:0:0: INITIATOR_MSG_OUT byte 0x3
<4>scsi0:A:0:0: INITIATOR_MSG_OUT byte 0x1
<4>scsi0:A:0:0: INITIATOR_MSG_OUT byte 0x2
<4>scsi0:A:0:0: INITIATOR_MSG_OUT byte 0x3
<4>scsi0:A:0:0: INITIATOR_MSG_OUT byte 0x1
<4>scsi0:A:0:0: INITIATOR_MSG_OUT PHASEMIS in Message-in phase
<4>scsi0:A:0:0: INITIATOR_MSG_IN byte 0x1
<4>scsi0:A:0:0: INITIATOR_MSG_IN byte 0x2
<4>scsi0:A:0:0: INITIATOR_MSG_IN byte 0x3
<4>scsi0:A:0:0: INITIATOR_MSG_IN byte 0x1
<4>scsi0:A:0:0: Asserting ATN for response
<4>scsi0:A:0:0: INITIATOR_MSG_IN PHASEMIS in Message-out phase
<4>scsi0:A:0:0: INITIATOR_MSG_OUT byte 0x1
<4>scsi0:A:0:0: INITIATOR_MSG_OUT byte 0x3
<4>scsi0:A:0:0: INITIATOR_MSG_OUT byte 0x1
<4>scsi0:A:0:0: INITIATOR_MSG_OUT byte 0x45
<4>scsi0:A:0:0: INITIATOR_MSG_OUT byte 0x0
<4>scsi0:A:0:0: INITIATOR_MSG_OUT PHASEMIS in Message-in phase
<4>scsi0:A:0:0: INITIATOR_MSG_IN byte 0x1
<4>scsi0:A:0:0: INITIATOR_MSG_IN byte 0x3
<4>scsi0:A:0:0: INITIATOR_MSG_IN byte 0x1
<4>scsi0:A:0:0: INITIATOR_MSG_IN byte 0x45
<4>scsi0:A:0:0: INITIATOR_MSG_IN byte 0x0
<6> target0:0:0: wide asynchronous
<4>scsi0:A:0:0: INITIATOR_MSG_IN PHASEMIS in Command phase
<4>Machine check in kernel mode.
<4>Caused by (from SRR1=49030): Transfer error ack signal
<4>Oops: Machine check, sig: 7 [#1]
<4>
<4>Modules linked in: aic7xxx scsi_transport_spi cpufreq_ondemand loop nfs nfs_acl lockd sunrpc sg st sd_mod sr_mod scsi_mod ide_cd cdrom
<4>NIP: D21F0604 LR: D20D9494 CTR: D21F05EC
<4>REGS: cf80d9f0 TRAP: 0200 Not tainted (2.6.18-rc6-20060905-default)
<4>MSR: 00049030 <EE,ME,IR,DR> CR: 22022242 XER: 00000000
<4>TASK = cf7e8760[963] 'insmod' THREAD: cf80c000
<6>GPR00: 000000FF CF80DAA0 CF7E8760 CEA58400 CF80DA6C CEA58000 CEA58100 00000000
<6>GPR08: 00000001 D105C000 CF6E3C00 00000000 2155D240 100290EC 0000000F D22C0498
<6>GPR16: 0000001E D229F258 C373D500 D229F230 CEA589CC CEA58818 CEA588BC CEA58400
<6>GPR24: CEA58800 CEA589A0 FFFFFFFF C37C2000 CEA589A0 CEA58800 CEA59C00 CEA58C00
<4>NIP [D21F0604] ahc_linux_get_signalling+0x18/0xa8 [aic7xxx]
<4>LR [D20D9494] spi_dv_device+0x338/0x51c [scsi_transport_spi]
<4>Call Trace:
<4>[CF80DAA0] [D20D9364] spi_dv_device+0x208/0x51c [scsi_transport_spi] (unreliable)
<4>[CF80DAF0] [D21F0A6C] ahc_linux_slave_configure+0xfc/0x114 [aic7xxx]
<4>[CF80DB30] [D20B71D8] scsi_probe_and_add_lun+0x8d4/0xa40 [scsi_mod]
<4>[CF80DB90] [D20B78F8] __scsi_scan_target+0xd8/0x630 [scsi_mod]
<4>[CF80DC20] [D20B7E9C] scsi_scan_channel+0x4c/0x9c [scsi_mod]
<4>[CF80DC40] [D20B7FD4] scsi_scan_host_selected+0xe8/0x140 [scsi_mod]
<4>[CF80DC70] [D21F3CA4] ahc_linux_register_host+0x344/0x35c [aic7xxx]
<4>[CF80DD10] [D21F4998] ahc_linux_pci_dev_probe+0x1a8/0x1c8 [aic7xxx]
<4>[CF80DD80] [C016A49C] pci_device_probe+0x6c/0xa0
<4>[CF80DDA0] [C01F0AF4] driver_probe_device+0x60/0xf4
<4>[CF80DDC0] [C01F0CC4] __driver_attach+0x8c/0xf0
<4>[CF80DDE0] [C01F0424] bus_for_each_dev+0x50/0x94
<4>[CF80DE10] [C01F0A08] driver_attach+0x24/0x34
<4>[CF80DE20] [C01F000C] bus_add_driver+0x78/0x128
<4>[CF80DE40] [C01F0FC4] driver_register+0xa0/0xb4
<4>[CF80DE50] [C016A2C8] __pci_register_driver+0x4c/0x8c
<4>[CF80DE60] [D21F47D8] ahc_linux_pci_init+0x20/0x38 [aic7xxx]
<4>[CF80DE70] [D105A3C0] ahc_linux_init+0x3c0/0x530 [aic7xxx]
<4>[CF80DEA0] [C004EB50] sys_init_module+0x1368/0x14f8
<4>[CF80DF40] [C00125A4] ret_from_syscall+0x0/0x40
<4>--- Exception: c01 at 0xff698a4
<4> LR = 0x10001100
<4>Instruction dump:
<4>38600000 4e800020 38600000 4e800020 4e800020 4e800020 814302ac 800a0000
<4>2f800000 409e0018 812a0004 8809001f <0c000000> 4c00012c 48000028 812a0004
<4> scsi0: PCI error Interrupt at seqaddr = 0x8
<4>scsi0: Signaled a Target Abort
On Tue, Sep 05, James Bottomley wrote:
> On Wed, 2006-09-06 at 08:20 +1000, Benjamin Herrenschmidt wrote:
> > Yes, it's a PCI error.
>
> Thanks, and the cat of /proc/scsi_host/host<n>/signalling?
>
> My suspicion is the register doesn't actually exist on this card so it
> doesn't actually respond on the bus. However, on my equivalent
> everything works; largely I think because the only PC's I have don't
> know how to signal a PCI error.
Where is that area mapped?
It crashes already if I read port 0.
Everything works if I also add the second hunk to disable signalling.
Index: linux-2.6.17/drivers/scsi/aic7xxx/aic7xxx_osm.c
===================================================================
--- linux-2.6.17.orig/drivers/scsi/aic7xxx/aic7xxx_osm.c
+++ linux-2.6.17/drivers/scsi/aic7xxx/aic7xxx_osm.c
@@ -2539,8 +2539,15 @@ static void ahc_linux_set_iu(struct scsi
static void ahc_linux_get_signalling(struct Scsi_Host *shost)
{
struct ahc_softc *ahc = *(struct ahc_softc **)shost->hostdata;
- u8 mode = ahc_inb(ahc, SBLKCTL);
+ int i;
+ u8 mode;
+ for (i=0;i!=SBLKCTL;i++) {
+ printk("i 0x%02x ",i);
+ mode = ahc_inb(ahc, i);
+ printk("m 0x%02x\n",mode);
+ }
+ mode = ahc_inb(ahc, SBLKCTL);
if (mode & ENAB40)
spi_signalling(shost) = SPI_SIGNAL_LVD;
else if (mode & ENAB20)
@@ -2566,8 +2573,8 @@ static struct spi_function_template ahc_
.show_iu = 1,
.set_qas = ahc_linux_set_qas,
.show_qas = 1,
-#endif
.get_signalling = ahc_linux_get_signalling,
+#endif
};
On Wed, 2006-09-06 at 13:01 +0200, Olaf Hering wrote:
> This causes another machine check because it runs ahc_inb(ahc, SBLKCTL) again.
> With debug I get:
Exactly. It's not a card state problem; the register simply doesn't
exist. It looks like from the source code, it only exists on twin or U2
and above chipsets (i.e. those supporting LVD).
Try this patch, which should deduce the bus type for U and below without
resorting to the SBLKCTL register.
James
diff --git a/drivers/scsi/aic7xxx/aic7xxx_osm.c b/drivers/scsi/aic7xxx/aic7xxx_osm.c
index e5bb4d8..0b3c01a 100644
--- a/drivers/scsi/aic7xxx/aic7xxx_osm.c
+++ b/drivers/scsi/aic7xxx/aic7xxx_osm.c
@@ -2539,15 +2539,23 @@ #endif
static void ahc_linux_get_signalling(struct Scsi_Host *shost)
{
struct ahc_softc *ahc = *(struct ahc_softc **)shost->hostdata;
- u8 mode = ahc_inb(ahc, SBLKCTL);
+ u8 mode;
- if (mode & ENAB40)
- spi_signalling(shost) = SPI_SIGNAL_LVD;
- else if (mode & ENAB20)
+ if (!(ahc->features & AHC_ULTRA2)) {
+ /* non-LVD chipset, may not have SBLKCTL reg */
spi_signalling(shost) =
ahc->features & AHC_HVD ?
SPI_SIGNAL_HVD :
SPI_SIGNAL_SE;
+ return;
+ }
+
+ mode = ahc_inb(ahc, SBLKCTL);
+
+ if (mode & ENAB40)
+ spi_signalling(shost) = SPI_SIGNAL_LVD;
+ else if (mode & ENAB20)
+ spi_signalling(shost) = SPI_SIGNAL_SE;
else
spi_signalling(shost) = SPI_SIGNAL_UNKNOWN;
}
On Wed, Sep 06, James Bottomley wrote:
> On Wed, 2006-09-06 at 13:01 +0200, Olaf Hering wrote:
> > This causes another machine check because it runs ahc_inb(ahc, SBLKCTL) again.
> > With debug I get:
>
> Exactly. It's not a card state problem; the register simply doesn't
> exist. It looks like from the source code, it only exists on twin or U2
> and above chipsets (i.e. those supporting LVD).
>
> Try this patch, which should deduce the bus type for U and below without
> resorting to the SBLKCTL register.
>
> James
>
> diff --git a/drivers/scsi/aic7xxx/aic7xxx_osm.c b/drivers/scsi/aic7xxx/aic7xxx_osm.c
> index e5bb4d8..0b3c01a 100644
> --- a/drivers/scsi/aic7xxx/aic7xxx_osm.c
> +++ b/drivers/scsi/aic7xxx/aic7xxx_osm.c
> @@ -2539,15 +2539,23 @@ #endif
> static void ahc_linux_get_signalling(struct Scsi_Host *shost)
> {
> struct ahc_softc *ahc = *(struct ahc_softc **)shost->hostdata;
> - u8 mode = ahc_inb(ahc, SBLKCTL);
> + u8 mode;
>
> - if (mode & ENAB40)
> - spi_signalling(shost) = SPI_SIGNAL_LVD;
> - else if (mode & ENAB20)
> + if (!(ahc->features & AHC_ULTRA2)) {
This does not work: ahc_linux_get_signalling: f 56f6
echo $(( 0x56f6 & 0x00002 )) gives 2, and the ahc_inb is called.
On Thu, 2006-09-07 at 11:15 +0200, Olaf Hering wrote:
> This does not work: ahc_linux_get_signalling: f 56f6
>
> echo $(( 0x56f6 & 0x00002 )) gives 2, and the ahc_inb is called.
Erm, there's something else going on then: An ultra 2 card has to have
this register. It's used to signal mode changes in
ahc_handle_scsiint(). The piece of code in there will trigger and read
this register for any ultra 2 + controller every time there's an error
(just to see if the bus mode changed).
James
Upgrading to this causes my copy of hal (0.5.3-0ubuntu14) to fail to start.
Bisecting tracked it down to the following commit. Reverting just this patch
against 2.6.18-rc6 gets things working again.
9bde7497e0b54178c317fac47a18be7f948dd471 is first bad commit
commit 9bde7497e0b54178c317fac47a18be7f948dd471
Author: Greg Kroah-Hartman <[email protected]>
Date: Wed Jun 14 12:14:34 2006 -0700
[PATCH] USB: make endpoints real struct devices
This will allow for us to give endpoints a major/minor to create a
"usbfs2-like" way to access endpoints directly from userspace in an
easier manner than the current usbfs provides us.
Signed-off-by: Greg Kroah-Hartman <[email protected]>
--
Jody Belka
knew (at) pimb (dot) org
ps. Please CC, as i'm not subscribed to the list. Thanks.
On Tue, Sep 12, 2006 at 04:04:33PM +0100, Jody Belka wrote:
> Upgrading to this causes my copy of hal (0.5.3-0ubuntu14) to fail to start.
> Bisecting tracked it down to the following commit. Reverting just this patch
> against 2.6.18-rc6 gets things working again.
>
>
> 9bde7497e0b54178c317fac47a18be7f948dd471 is first bad commit
> commit 9bde7497e0b54178c317fac47a18be7f948dd471
> Author: Greg Kroah-Hartman <[email protected]>
> Date: Wed Jun 14 12:14:34 2006 -0700
>
> [PATCH] USB: make endpoints real struct devices
>
> This will allow for us to give endpoints a major/minor to create a
> "usbfs2-like" way to access endpoints directly from userspace in an
> easier manner than the current usbfs provides us.
>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Yes, this exposed a bug in HAL where it was overflowing an internal
buffer. Please upgrade to the latest version, it has been fixed for a
few months now.
thanks,
greg k-h
On Tue, Sep 12, 2006 at 03:33:09PM -0700, Greg KH wrote:
> Yes, this exposed a bug in HAL where it was overflowing an internal
> buffer. Please upgrade to the latest version, it has been fixed for a
> few months now.
Would you happen to have a patch for the fix please? Then i can open a
report in the ubuntu bug tracker, and they can release an updated 0.5.3
that will work with 2.6.18.
Thanks in advance.
J
--
Jody Belka
knew (at) pimb (dot) org
ps. Please CC me, as i'm not subscribed to the list. Thanks.
On Wed, Sep 13, 2006 at 12:11:17AM +0100, Jody Belka wrote:
> On Tue, Sep 12, 2006 at 03:33:09PM -0700, Greg KH wrote:
> > Yes, this exposed a bug in HAL where it was overflowing an internal
> > buffer. Please upgrade to the latest version, it has been fixed for a
> > few months now.
>
> Would you happen to have a patch for the fix please? Then i can open a
> report in the ubuntu bug tracker, and they can release an updated 0.5.3
> that will work with 2.6.18.
>
> Thanks in advance.
Never mind, following some googling i found the commit. Tested and it works,
so opened a bug report with Ubuntu. In the meantime i'm running my own build
of the .deb :)
Thanks for the help.
J
--
Jody Belka
knew (at) pimb (dot) org
ps. Please CC me, as i'm not subscribed to the list. Thanks.
On Thu, 2006-09-07 at 09:04 -0500, James Bottomley wrote:
> On Thu, 2006-09-07 at 11:15 +0200, Olaf Hering wrote:
> > This does not work: ahc_linux_get_signalling: f 56f6
> >
> > echo $(( 0x56f6 & 0x00002 )) gives 2, and the ahc_inb is called.
>
> Erm, there's something else going on then: An ultra 2 card has to have
> this register. It's used to signal mode changes in
> ahc_handle_scsiint(). The piece of code in there will trigger and read
> this register for any ultra 2 + controller every time there's an error
> (just to see if the bus mode changed).
Sorry for my belated response, but this usually happens when you access
an aic chipset too soon after a chip reset. Try putting a delay before
whatever access is causing this to see if it make s difference. Common
problems include after a chip reset, touching any register will cause
the card to reset, etc.
--
Doug Ledford <[email protected]>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
On Fri, Sep 15, Doug Ledford wrote:
> Sorry for my belated response, but this usually happens when you access
> an aic chipset too soon after a chip reset. Try putting a delay before
> whatever access is causing this to see if it make s difference. Common
> problems include after a chip reset, touching any register will cause
> the card to reset, etc.
I put a ssleep(1) before the ahc_inb(ahc, SBLKCTL);
Does not help. Is it possible that the card loses some of its features
during reset and something needs to be done to reenable them?
On Fri, Sep 15, Doug Ledford wrote:
> On Thu, 2006-09-07 at 09:04 -0500, James Bottomley wrote:
> > On Thu, 2006-09-07 at 11:15 +0200, Olaf Hering wrote:
> > > This does not work: ahc_linux_get_signalling: f 56f6
> > >
> > > echo $(( 0x56f6 & 0x00002 )) gives 2, and the ahc_inb is called.
> >
> > Erm, there's something else going on then: An ultra 2 card has to have
> > this register. It's used to signal mode changes in
> > ahc_handle_scsiint(). The piece of code in there will trigger and read
> > this register for any ultra 2 + controller every time there's an error
> > (just to see if the bus mode changed).
>
> Sorry for my belated response, but this usually happens when you access
> an aic chipset too soon after a chip reset. Try putting a delay before
> whatever access is causing this to see if it make s difference. Common
> problems include after a chip reset, touching any register will cause
> the card to reset, etc.
As pointed out in private mail, this patch fixes the machine check for
me. Thanks Doug.
Maybe the AHC_ULTRA2 feature check is needed as well for other cards.
---
drivers/scsi/aic7xxx/aic7xxx_osm.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
Index: linux-2.6.18-rc7/drivers/scsi/aic7xxx/aic7xxx_osm.c
===================================================================
--- linux-2.6.18-rc7.orig/drivers/scsi/aic7xxx/aic7xxx_osm.c
+++ linux-2.6.18-rc7/drivers/scsi/aic7xxx/aic7xxx_osm.c
@@ -2539,7 +2539,14 @@ static void ahc_linux_set_iu(struct scsi
static void ahc_linux_get_signalling(struct Scsi_Host *shost)
{
struct ahc_softc *ahc = *(struct ahc_softc **)shost->hostdata;
- u8 mode = ahc_inb(ahc, SBLKCTL);
+ unsigned long flags;
+ u8 mode;
+
+ ahc_lock(ahc, &flags);
+ ahc_pause(ahc);
+ mode = ahc_inb(ahc, SBLKCTL);
+ ahc_unpause(ahc);
+ ahc_unlock(ahc, &flags);
if (mode & ENAB40)
spi_signalling(shost) = SPI_SIGNAL_LVD;
On Sun, 2006-09-17 at 07:38 +0200, Olaf Hering wrote:
> As pointed out in private mail, this patch fixes the machine check for
> me. Thanks Doug.
>
> Maybe the AHC_ULTRA2 feature check is needed as well for other cards.
It is ... the non ULTRA2 non twin cards might not have this register
(and if they do, it doesn't reflect the LVD/SE bus setting).
This is a pretty significant alteration, so it's not a -rc candidate,
but I'll put it in scsi-misc and see how it works out.
James
On Sun, 2006-09-17 at 09:05 -0500, James Bottomley wrote:
> On Sun, 2006-09-17 at 07:38 +0200, Olaf Hering wrote:
> > As pointed out in private mail, this patch fixes the machine check for
> > me. Thanks Doug.
> >
> > Maybe the AHC_ULTRA2 feature check is needed as well for other cards.
>
> It is ... the non ULTRA2 non twin cards might not have this register
> (and if they do, it doesn't reflect the LVD/SE bus setting).
>
> This is a pretty significant alteration, so it's not a -rc candidate,
> but I'll put it in scsi-misc and see how it works out.
No, it's present on all cards. Reading it for signaling may not be
needed on non-ultra 2 cards (as far as LVD goes), but it won't hurt.
However, all the other places this particular register is touched in the
driver, the card is already paused. Olaf's problem may be that this is
one of the registers that require the sequencer be paused before you
touch it. Depending on the chipset, if you touch a pause only register,
it either pukes up like Olaf is seeing or auto pauses the chip. I had
thought that all the Ultra2 chipsets did autopause, but maybe the
current driver disables that (and even if it did autopause, you would
still need an unpause or else the card stops until the next time
something happens that includes a pause/unpause pair). Anyway, I asked
Olaf to try wrapping the read in an ahc_lock/unlock and pause/unpause
pair to see if it makes a difference. We'll see.
--
Doug Ledford <[email protected]>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
On Sun, 2006-09-17 at 07:38 +0200, Olaf Hering wrote:
> On Fri, Sep 15, Doug Ledford wrote:
>
> > On Thu, 2006-09-07 at 09:04 -0500, James Bottomley wrote:
> > > On Thu, 2006-09-07 at 11:15 +0200, Olaf Hering wrote:
> > > > This does not work: ahc_linux_get_signalling: f 56f6
> > > >
> > > > echo $(( 0x56f6 & 0x00002 )) gives 2, and the ahc_inb is called.
> > >
> > > Erm, there's something else going on then: An ultra 2 card has to have
> > > this register. It's used to signal mode changes in
> > > ahc_handle_scsiint(). The piece of code in there will trigger and read
> > > this register for any ultra 2 + controller every time there's an error
> > > (just to see if the bus mode changed).
> >
> > Sorry for my belated response, but this usually happens when you access
> > an aic chipset too soon after a chip reset. Try putting a delay before
> > whatever access is causing this to see if it make s difference. Common
> > problems include after a chip reset, touching any register will cause
> > the card to reset, etc.
>
> As pointed out in private mail, this patch fixes the machine check for
> me. Thanks Doug.
Hehehe, everyone ignore my last email, I hadn't seen this one ;-)
You're welcome.
> Maybe the AHC_ULTRA2 feature check is needed as well for other cards.
>
> ---
> drivers/scsi/aic7xxx/aic7xxx_osm.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> Index: linux-2.6.18-rc7/drivers/scsi/aic7xxx/aic7xxx_osm.c
> ===================================================================
> --- linux-2.6.18-rc7.orig/drivers/scsi/aic7xxx/aic7xxx_osm.c
> +++ linux-2.6.18-rc7/drivers/scsi/aic7xxx/aic7xxx_osm.c
> @@ -2539,7 +2539,14 @@ static void ahc_linux_set_iu(struct scsi
> static void ahc_linux_get_signalling(struct Scsi_Host *shost)
> {
> struct ahc_softc *ahc = *(struct ahc_softc **)shost->hostdata;
> - u8 mode = ahc_inb(ahc, SBLKCTL);
> + unsigned long flags;
> + u8 mode;
> +
> + ahc_lock(ahc, &flags);
> + ahc_pause(ahc);
> + mode = ahc_inb(ahc, SBLKCTL);
> + ahc_unpause(ahc);
> + ahc_unlock(ahc, &flags);
>
> if (mode & ENAB40)
> spi_signalling(shost) = SPI_SIGNAL_LVD;
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Doug Ledford <[email protected]>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
Am 2006-09-05 17:04 +0100 schrieb Alistair John Strachan:
> Might not be a kernel problem, userspace might be using libusb and calling
> usb_reset() on the device. Try dropping out of X11 and see if it still
> happens.
I have this with 18_rc6 and 18_rc7 also:
Sep 22 11:01:50 anita usb 1-3: reset low speed USB device using ohci_hcd
and address 3
Sep 22 11:03:17 anita usb 1-3: reset low speed USB device using ohci_hcd
and address 3
Sep 22 11:04:04 anita usb 1-3: reset low speed USB device using ohci_hcd
and address 3
Sep 22 11:04:52 anita usb 1-3: reset low speed USB device using ohci_hcd
and address 3
Sep 22 11:05:46 anita usb 1-3: reset low speed USB device using ohci_hcd
and address 3
Sep 22 11:06:30 anita usb 1-3: reset low speed USB device using ohci_hcd
and address 3
In older Kernels or even 2.6.17 I never saw this.
So may be the initial report was barking at the wrong tree, this is a
plugged wired USB keyboard (daskeyboard.com).
The Keyboard is fully functional while typing on it and this happens
without being in X. It happens with nobody logged in local, the messages
are logged even only when logged in via ssh.
libusb and usbutils are not installed on this machine (should they?).
T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#= 3 Spd=1.5 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=046a ProdID=0048 Rev= 0.26
S: Product=Das Keyboard
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=10ms
Regards, Konsti
--
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E A080 1E69 3FDA EF62 FCEF