I just pushed 2.6.15-rc3 out there, and here are both the shortlog and
diffstats appended.
Most notable are some VM fixes from Hugh Dickins (with me then redoing
some of it, but the bulk of the work goes to Hugh). That should finally
hopefully fix some of the issues some people hit with the PageReserved
removal and cleanup by Nick Piggin that was in -rc1.
There's also some input updates, cifs fixes, USB EHCI host controller
updates, and a number of random stuff. Details in the shortlog below,
Linus
--- shortlog ---
Adam Brooks:
[ARM] 3173/1: Fix to allow 2.6.15-rc2 to compile for IOP3xx boards
Adrian Bunk:
[SPARC]: drivers/sbus/char/aurora.c: "extern inline" -> "static inline"
drivers/message/i2o/pci.c: fix a NULL pointer dereference
drivers/infiniband/core/mad.c: fix use-after-release case
drivers/scsi/dpt_i2o.c: fix a NULL pointer dereference
Alan Stern:
Small fixes to driver core
Workaround for gcc 2.96 (undefined references)
Alasdair G Kergon:
device-mapper: list_versions fix
device-mapper: mirror log bitset fix
Alexandra Kossovsky:
[COMPAT] net: SIOCGIFCONF data corruption
Andi Kleen:
i386: Use bigsmp for > 8 core Opteron systems
Remove compat ioctl semaphore
Andrea Arcangeli:
shrinker->nr = LONG_MAX means deadlock for icache
Andrea Bittau:
[PKT_SCHED]: sch_netem: correctly order packets to be sent simultaneously
Andrew Morton:
Input: wistron - disable for x86_64
revert floppy-fix-read-only-handling
jffs2 debug gcc-2.9x fix
memory_sysdev_class is static
fork.c: proc_fork_connector() called under write_lock()
Antonino A. Daplas:
fbcon: Console Rotation - Fix wrong shift calculation
vgacon: Fix usage of stale height value on vc initialization
Arjan van de Ven:
[SERIAL] mark several serial tables const
Ashok Raj:
Register disabled CPUs
clean up lock_cpu_hotplug() in cpufreq
Ben Collins:
Fix hardcoded cpu=0 in workqueue for per_cpu_ptr() calls
Benjamin Herrenschmidt:
Fix crash in unregister_console()
Console rotation fixes
Benoit Boissinot:
[NETFILTER]: ip_conntrack_netlink.c needs linux/interrupt.h
Bernhard Rosenkraenzer:
Input: wistron - add support for Acer Aspire 1500 notebooks
Chris Humbert:
fix broken lib/genalloc.c
Christoph Hellwig:
[XFS] handle error returns from freeze_bdev
Damian Wrobel:
USB: SN9C10x driver - bad page state fix
Daniel Marjam?ki:
PCI: direct.c: DBG
Daniel Marjam?kia:
PCI: trivial printk updates in common.c
Dave Airlie:
I think that if a PCI bus is a root bus, attached to a host bridge not a
drm: add __GFP_COMP to the drm_alloc_pages
drm: move is_pci to the end of the structure
drm: fix quiescent locking
Dave Jones:
[AGPGART] Mark maxes_table as const
[AGPGART] Mark AMD64 aperture size structs as const
[AGPGART] Support VIA P4M800CE bridge.
dell_rbu driver depends on x86[64]
David Brownell:
USB: EHCI updates
USB: EHCI updates mostly whitespace cleanups
USB: EHCI updates split init/reinit logic for resume
USB: ohci, move ppc asic tweaks nearer pci
David Gibson:
Fix error handling with put_compat_statfs()
Fix hugetlbfs_statfs() reporting of block limits
powerpc: fix for hugepage areas straddling 4GB boundary
powerpc: More hugepage boundary case fixes
David Howells:
FRV: Make the FRV arch work again
David H?rdeman:
USB: fix USB key generates ioctl_internal_command errors issue
David S. Miller:
sparc: convert IO remapping to VM_PFNMAP
Dirk Opfer:
[ARM] 3170/1: Sharp SL-6000x: platform device conversion fixup
Dmitry Torokhov:
Input: atkbd - speed up setting leds/repeat state
Input: add Wistron driver
Input: wistron - convert to dynamic input_dev allocation
Input: wistron - add PM support
Input: uinput - convert to dynalloc allocation
Input: uinput - add UI_SET_SWBIT ioctl
Input: uinput - don't use "interruptible" in FF code
Input: handle failures in input_register_device()
Input: make serio and gameport more swsusp friendly
Fix an OOPS when initializing IR remote on saa7134
Fix missing initialization in ir-kbd-gpio.c
Fix an OOPS is CinergyT2
Eric Paris:
hugetlb: fix race in set_max_huge_pages for multiple updaters of nr_huge_pages
Eric Sandeen:
[XFS] Fix potential overflow in xfs_iomap_t delta for very large extents
Eugeniy Meshcheryakov:
hwmon: hdaps missing an axis
Felix Blyakher:
[XFS] Tight loop in xfs_finish_reclaim_all prevented the xfslogd to run
Glauber de Oliveira Costa:
ext3: Wrong return value for EXT3_IOC_GROUP_ADD
Grant Coady:
cpufreq: silence cpufreq for UP
[email protected]:
[IA64] fix bug in sn/ia64 for sparse CPU numbering
Herbert Xu:
[NETLINK]: Use tgid instead of pid for nlmsg_pid
Hirokazu Takata:
m32r: Fix sys_tas() syscall
m32r: Introduce atomic_cmpxchg and atomic_inc_not_zero operations
m32r: M3A-2170(Mappi-III) IDE support
Hugh Dickins:
unpaged: get_user_pages VM_RESERVED
unpaged: private write VM_RESERVED
unpaged: sound nopage get_page
unpaged: unifdefed PageCompound
unpaged: VM_UNPAGED
unpaged: VM_NONLINEAR VM_RESERVED
unpaged: COW on VM_UNPAGED
unpaged: anon in VM_UNPAGED
unpaged: ZERO_PAGE in VM_UNPAGED
unpaged: PG_reserved bad_page
unpaged: copy_page_range vma
unpaged: fix sound Bad page states
mm: update split ptlock Kconfig
mm: unbloat get_futex_key
mm: powerpc ptlock comments
mm: powerpc init_mm without ptlock
mm: fill arch atomic64 gaps
Ian Abbott:
USB: ftdi_sio: new IDs for KOBIL devices
Jack Steiner:
[IA64-SGI] support for older versions of PROM
[email protected]:
Fix x86_64/msr.h interface to agree with i386/msr.h
Jamal Hadi Salim:
[IPV4]: Fix secondary IP addresses after promotion
Jan Kara:
Fix oops in vfs_quotaon_mount()
Jasper Spaans:
fbcon: fix obvious bug in fbcon logo rotation code
[email protected]:
device-mapper snapshot: bio_list fix
Jean Delvare:
hwmon: Fix lm78 VID conversion
hwmon: Fix missing it87 fan div init
Jeff Dike:
uml: eliminate use of local in clone stub
uml: eliminate anonymous union and clean up symlink lossage
uml: properly invoke x86_64 system calls
uml: eliminate use of libc PAGE_SIZE
Jens Axboe:
as-iosched: remove state assertion in as_add_request()
Jim Keniston:
kprobes: Fix return probes on sys_execve
Jody McIntyre:
sbp2_command_orb_lock must be held when accessing the _orb_inuse list.
Clarify T: field in MAINTAINERS
Jonathan E Brassow:
device-mapper raid1: drop mark_region spinlock fix
Josh Boyer:
MTD git tree location added to MAINTAINERS
Add more SCM trees to MAINTAINERS
Kenneth Tan:
[ARM] 3171/1: To add missing QMGR region size for IXP4XX
Kiyoshi Ueda:
device-mapper dm-ioctl: missing put in table load error case
Kris Katterjohn:
[NET]: Reject socket filter if division by constant zero is attempted.
Latchesar Ionkov:
v9fs: fix memory leak in v9fs dentry code
Linus Torvalds:
Fix up GFP_ZONEMASK for GFP_DMA32 usage
compat-ioctl.c: fix compile with no CONFIG_JBD
Revert "[NET]: Shut up warnings in net/core/flow.c"
mm: re-architect the VM_UNPAGED logic
Linux v2.6.15-rc3
Lucas Correia Villa Real:
[ARM] 3178/1: S3C2400 - adds GPIO registers definitions to regs-gpio.h
Mark Maule:
[IA64] altix: fix copyright in tioce .h files
Matthew Dobson:
Fix a bug in scsi_get_command
Matthew Wilcox:
Check the irq number is within bounds
Michael Krufky:
fix broken hybrid v4l-dvb frontend selection
Miklos Szeredi:
fuse: check directory aliasing in mkdir
fuse: check for invalid node ID in fuse_create_open()
Miloslav Trmac:
Input: wistron - disable wifi/bluetooth on suspend
Nathan Scott:
[XFS] Fix a 32 bit value wraparound when providing a mapping for a large
[XFS] Fix a case where attr2 format was being used unconditionally.
[XFS] Resolve the xlog_grant_log_space hang, revert inline to macro.
Neil Horman:
[NET]: Fix ifenslave to not fail on lack of IP information
NeilBrown:
md: improve read speed to raid10 arrays using 'far copies'
md: fix locking problem in r5/r6
md: fix problem with raid6 intent bitmap
md: set default_bitmap_offset properly in set_array_info
md: fix --re-add for raid1 and raid6
Nick Piggin:
mm: __alloc_pages cleanup fix
Nicolas Kaiser:
[NETFILTER]: Remove ARRAY_SIZE duplicate
usb serial: remove redundant include
Olaf Rempel:
[BRIDGE]: recompute features when adding a new device
Oleg Drokin:
32bit integer overflow in invalidate_inode_pages2()
reiserfs: fix 32-bit overflow in map_block_for_writepage()
Oleg Nesterov:
fix do_wait() vs exec() race
fix 32bit overflow in timespec_to_sample()
Olof Johansson:
powerpc: update my email address
Pablo Neira Ayuso:
[NETFILTER] ctnetlink: Fix refcount leak ip_conntrack/nat_proto
Patrick McHardy:
[FIB_TRIE]: Don't show local table in /proc/net/route output
[DCCP]: Add missing no_policy flag to struct net_protocol
[NET]: Use unused bit for ipvs_property field in struct sk_buff
Paul Jackson:
cpuset fork locking fix
Pierre Ossman:
[MMC] Fix protocol errors
Prarit Bhargava:
[IA64] Prevent sn2 ptc code from executing on all ia64 subarches
Rajesh Shah:
PCI Express Hotplug: clear sticky power-fault bit
PCI: remove bogus resource collision error
Randy Dunlap:
[NET]: kernel-doc fixes
kernel Doc/ URL corrections
PCI: kernel-doc fix for pci-acpi.c
USB: kernel-doc for linux/usb.h
Richard Knutsson:
net: Fix compiler-error on dgrs.c when !CONFIG_PCI
Richard Purdie:
[ARM] 3179/1: Update/correct Zaurus Kconfig entries
[ARM] 3180/1: Update Zaurus defconfigs
Rik van Riel:
temporarily disable swap token on memory pressure
Roman Zippel:
prefer pkg-config for the QT check
Russ Anderson:
[IA64-SGI] bte_copy nasid_index fix
Russell King:
[ARM] Add asm/memory.h to asm/numnodes.h
[ARM] ebsa110: __arch_ioremap should be 3 args
[ARM] Shut up gcc warning in assabet.c
[ARM] Shut up gcc warning in clps7500 core.c
[SERIAL] imx: Fix missed platform_driver_unregister
[NET]: Shut up warnings in net/core/flow.c
[ARM] Remove asm/hardware.h include from SA1100 io.h
[ARM] Remove mach-types.h from head.S
[ARM] Do not call flush_tlb_kernel_range() with IRQs disabled.
[ARM] Realview core.c does not need mach-types.h
[ARM] Update mach-types
Sascha Hauer:
[ARM] 3181/1: add PORT_ identifier for Hilscher netx uart
Stefan Bader:
device-mapper dm-mpath: endio spinlock fix
Stephen Rothwell:
powerpc: remove arch/powerpc/include hack for 64 bit
Steve French:
[CIFS] Fix CIFS "nobrl" mount option so does not disable sending brl requests
[CIFS] Cleanup sparse warnings for unicode little endian casts
[CIFS] Recognize properly symlinks and char/blk devices (not just FIFOs)
[CIFS] Fix endian errors (setfacl/getfacl failures) in handling ACLs
[CIFS] Fix sparse warnings on smb bcc (byte count)
[CIFS] Recognize properly symlinks and char/blk devices (not just
[CIFS] Vectored and async i/o turned on and correct the
[CIFS] Fix scheduling while atomic when pending writes at file close time
[CIFS] Missing part of previous patch
[CIFS] Fix mknod of block and chardev over SFU mounts
[CIFS] Fix setattr of mode only (e.g. in some chmod cases) to Windows
Trond Myklebust:
NFSv4: Fix buggy nfs_wait_on_sequence()
NFSv4: Fix typo in lock caching
NFS: Fix a spinlock recursion inside nfs_update_inode()
SUNRPC: Funny looking code in __rpc_purge_upcall
Ville Nuorvala:
[IPV6]: Fix calculation of AH length during filling ancillary data.
Yan Zheng:
[IPV6]: Acquire addrconf_hash_lock for read in addrconf_verify(...)
Yasuyuki Kozakai:
[NETFILTER]: fixed dependencies between modules related with ip_conntrack
YOSHIFUJI Hideaki:
[IPV6]: Fix memory management error during setting up new advapi sockopts.
[IPV6]: Fix sending extension headers before and including routing header.
Yuan Mu:
hwmon: Fix missing boundary check when setting W83627THF in0 limits
--- diffstat ---
Documentation/DocBook/kernel-api.tmpl | 6
Documentation/arm/VFP/release-notes.txt | 2
Documentation/dvb/faq.txt | 1
Documentation/filesystems/affs.txt | 2
Documentation/filesystems/ext2.txt | 3
Documentation/floppy.txt | 10
Documentation/ioctl-number.txt | 2
Documentation/kernel-docs.txt | 60 +-
Documentation/mca.txt | 2
Documentation/networking/driver.txt | 5
Documentation/networking/ifenslave.c | 9
Documentation/networking/iphase.txt | 2
Documentation/networking/irda.txt | 8
Documentation/networking/ray_cs.txt | 3
Documentation/networking/vortex.txt | 28 -
Documentation/power/pci.txt | 2
Documentation/scsi/ibmmca.txt | 4
Documentation/usb/ibmcam.txt | 4
Documentation/usb/ov511.txt | 4
Documentation/usb/rio.txt | 6
Documentation/video4linux/zr36120.txt | 7
MAINTAINERS | 25 +
Makefile | 2
arch/arm/configs/corgi_defconfig | 83 ++
arch/arm/configs/poodle_defconfig | 1015 ---------------------------
arch/arm/configs/spitz_defconfig | 81 ++
arch/arm/kernel/head.S | 11
arch/arm/mach-clps7500/core.c | 2
arch/arm/mach-pxa/Kconfig | 4
arch/arm/mach-pxa/tosa.c | 2
arch/arm/mach-realview/core.c | 1
arch/arm/mach-sa1100/assabet.c | 3
arch/arm/mm/consistent.c | 13
arch/arm/tools/mach-types | 14
arch/frv/kernel/semaphore.c | 2
arch/frv/mb93090-mb00/pci-irq.c | 2
arch/frv/mm/init.c | 2
arch/frv/mm/pgalloc.c | 6
arch/i386/kernel/acpi/boot.c | 4
arch/i386/kernel/mpparse.c | 5
arch/i386/kernel/process.c | 7
arch/i386/pci/common.c | 4
arch/i386/pci/direct.c | 2
arch/i386/pci/i386.c | 7
arch/ia64/kernel/process.c | 7
arch/ia64/sn/kernel/bte.c | 1
arch/ia64/sn/kernel/sn2/sn2_smp.c | 3
arch/ia64/sn/kernel/sn2/sn_hwperf.c | 3
arch/m32r/kernel/io_mappi3.c | 54 +
arch/m32r/kernel/setup_mappi3.c | 20 -
arch/m32r/kernel/sys_m32r.c | 6
arch/powerpc/Makefile | 16
arch/powerpc/kernel/process.c | 1
arch/powerpc/kernel/vdso.c | 9
arch/powerpc/mm/4xx_mmu.c | 4
arch/powerpc/mm/hugetlbpage.c | 10
arch/powerpc/mm/mem.c | 2
arch/powerpc/mm/tlb_32.c | 6
arch/powerpc/mm/tlb_64.c | 4
arch/powerpc/platforms/iseries/iommu.c | 2
arch/powerpc/platforms/pseries/iommu.c | 2
arch/powerpc/sysdev/dart.h | 2
arch/powerpc/sysdev/u3_iommu.c | 4
arch/sparc/kernel/ioport.c | 2
arch/sparc/mm/generic.c | 10
arch/sparc64/kernel/sbus.c | 2
arch/sparc64/mm/generic.c | 15
arch/um/Makefile | 2
arch/um/include/sysdep-i386/stub.h | 9
arch/um/include/sysdep-x86_64/stub.h | 12
arch/um/kernel/skas/clone.c | 21 -
arch/um/sys-i386/Makefile | 2
arch/um/sys-i386/ldt.c | 35 +
arch/um/sys-i386/stub_segv.c | 11
arch/um/sys-x86_64/Makefile | 2
arch/um/sys-x86_64/stub_segv.c | 20 -
arch/x86_64/kernel/process.c | 7
block/as-iosched.c | 4
drivers/base/bus.c | 21 -
drivers/base/dd.c | 8
drivers/block/floppy.c | 6
drivers/char/agp/amd64-agp.c | 4
drivers/char/agp/backend.c | 2
drivers/char/agp/via-agp.c | 6
drivers/char/drm/drm_lock.c | 16
drivers/char/drm/drm_memory.c | 2
drivers/char/drm/drm_memory_debug.h | 2
drivers/char/drm/mga_drv.c | 2
drivers/char/drm/radeon_drv.h | 3
drivers/cpufreq/cpufreq.c | 14
drivers/firmware/Kconfig | 1
drivers/hwmon/hdaps.c | 2
drivers/hwmon/it87.c | 7
drivers/hwmon/lm78.c | 2
drivers/hwmon/w83627hf.c | 8
drivers/ieee1394/sbp2.c | 6
drivers/infiniband/core/mad.c | 4
drivers/input/gameport/gameport.c | 12
drivers/input/input.c | 63 +-
drivers/input/keyboard/atkbd.c | 99 ++-
drivers/input/misc/Kconfig | 10
drivers/input/misc/Makefile | 1
drivers/input/misc/uinput.c | 323 ++++-----
drivers/input/misc/wistron_btns.c | 561 +++++++++++++++
drivers/input/serio/serio.c | 12
drivers/md/dm-bio-list.h | 3
drivers/md/dm-ioctl.c | 3
drivers/md/dm-log.c | 4
drivers/md/dm-mpath.c | 13
drivers/md/dm-raid1.c | 20 -
drivers/md/md.c | 4
drivers/md/raid1.c | 8
drivers/md/raid10.c | 6
drivers/md/raid5.c | 2
drivers/md/raid6main.c | 27 +
drivers/media/dvb/cinergyT2/cinergyT2.c | 2
drivers/media/video/Kconfig | 2
drivers/media/video/cx88/Kconfig | 20 -
drivers/media/video/cx88/Makefile | 27 -
drivers/media/video/ir-kbd-gpio.c | 5
drivers/media/video/saa7134/Kconfig | 12
drivers/media/video/saa7134/Makefile | 19 -
drivers/media/video/saa7134/saa7134-input.c | 2
drivers/message/i2o/pci.c | 2
drivers/mmc/mmc.c | 2
drivers/net/dgrs.c | 2
drivers/pci/hotplug/pciehp.h | 1
drivers/pci/hotplug/pciehp_ctrl.c | 15
drivers/pci/hotplug/pciehp_hpc.c | 10
drivers/pci/pci-acpi.c | 1
drivers/pcmcia/m32r_cfc.c | 3
drivers/sbus/char/aurora.c | 12
drivers/scsi/dpt_i2o.c | 9
drivers/scsi/scsi.c | 2
drivers/serial/8250.c | 2
drivers/serial/8250_pci.c | 2
drivers/serial/imx.c | 2
drivers/serial/serial_core.c | 2
drivers/serial/serial_cs.c | 6
drivers/usb/core/hcd-pci.c | 38 +
drivers/usb/core/hub.c | 1
drivers/usb/host/ehci-hcd.c | 158 ++--
drivers/usb/host/ehci-hub.c | 7
drivers/usb/host/ehci-pci.c | 355 ++++-----
drivers/usb/host/ohci-pci.c | 36 -
drivers/usb/media/sn9c102_core.c | 2
drivers/usb/serial/ftdi_sio.c | 2
drivers/usb/serial/ftdi_sio.h | 7
drivers/usb/serial/ipw.c | 1
drivers/usb/storage/unusual_devs.h | 9
drivers/video/console/fbcon_ccw.c | 2
drivers/video/console/fbcon_rotate.h | 17
drivers/video/console/vgacon.c | 1
drivers/video/fbmem.c | 6
fs/9p/vfs_inode.c | 2
fs/cifs/CHANGES | 2
fs/cifs/cifs_unicode.c | 13
fs/cifs/cifs_unicode.h | 6
fs/cifs/cifsencrypt.c | 2
fs/cifs/cifsfs.c | 109 ++-
fs/cifs/cifsfs.h | 2
fs/cifs/cifspdu.h | 10
fs/cifs/cifssmb.c | 43 +
fs/cifs/connect.c | 91 +-
fs/cifs/dir.c | 32 +
fs/cifs/file.c | 2
fs/cifs/inode.c | 202 ++++-
fs/cifs/misc.c | 2
fs/cifs/readdir.c | 43 +
fs/cifs/transport.c | 4
fs/compat.c | 23 -
fs/compat_ioctl.c | 8
fs/dquot.c | 6
fs/exec.c | 8
fs/ext3/resize.c | 1
fs/fuse/dir.c | 37 +
fs/hugetlbfs/inode.c | 12
fs/jffs2/debug.h | 8
fs/nfs/inode.c | 26 -
fs/nfs/nfs4proc.c | 6
fs/nfs/nfs4state.c | 20 -
fs/proc/task_mmu.c | 7
fs/reiserfs/inode.c | 2
fs/xfs/linux-2.6/xfs_aops.c | 13
fs/xfs/xfs_attr_leaf.c | 11
fs/xfs/xfs_fsops.c | 2
fs/xfs/xfs_iomap.h | 2
fs/xfs/xfs_log_priv.h | 36 -
fs/xfs/xfs_vnodeops.c | 5
include/asm-alpha/atomic.h | 7
include/asm-arm/arch-ebsa110/io.h | 2
include/asm-arm/arch-iop3xx/timex.h | 2
include/asm-arm/arch-ixp4xx/ixp4xx-regs.h | 1
include/asm-arm/arch-s3c2410/regs-gpio.h | 239 ++++++
include/asm-arm/arch-sa1100/io.h | 2
include/asm-arm/numnodes.h | 2
include/asm-frv/hardirq.h | 1
include/asm-frv/ide.h | 8
include/asm-frv/page.h | 4
include/asm-frv/semaphore.h | 2
include/asm-frv/thread_info.h | 2
include/asm-ia64/sn/sn_sal.h | 34 +
include/asm-ia64/sn/tioce.h | 26 -
include/asm-ia64/sn/tioce_provider.h | 17
include/asm-m32r/atomic.h | 21 +
include/asm-m32r/ide.h | 13
include/asm-m32r/mappi3/mappi3_pld.h | 2
include/asm-m32r/system.h | 64 ++
include/asm-powerpc/iommu.h | 2
include/asm-powerpc/page_64.h | 23 -
include/asm-powerpc/tce.h | 2
include/asm-sparc64/atomic.h | 1
include/asm-sparc64/pgtable.h | 10
include/asm-um/ldt-i386.h | 2
include/asm-um/ldt-x86_64.h | 69 ++
include/asm-um/ldt.h | 74 --
include/asm-x86_64/atomic.h | 51 +
include/asm-x86_64/msr.h | 2
include/linux/cpu.h | 7
include/linux/gfp.h | 9
include/linux/jbd.h | 17
include/linux/memory.h | 1
include/linux/mm.h | 27 -
include/linux/mmc/protocol.h | 4
include/linux/mmzone.h | 18
include/linux/netfilter_ipv4/ipt_sctp.h | 12
include/linux/page-flags.h | 4
include/linux/pci_ids.h | 1
include/linux/rmap.h | 4
include/linux/sched.h | 1
include/linux/serial_core.h | 3
include/linux/skbuff.h | 7
include/linux/swap.h | 6
include/linux/uinput.h | 13
include/linux/usb.h | 1
include/net/ipv6.h | 2
include/net/route.h | 3
kernel/cpu.c | 83 +-
kernel/fork.c | 7
kernel/futex.c | 15
kernel/irq/manage.c | 15
kernel/posix-cpu-timers.c | 2
kernel/printk.c | 2
kernel/workqueue.c | 12
lib/genalloc.c | 14
mm/Kconfig | 6
mm/fremap.c | 28 -
mm/hugetlb.c | 6
mm/madvise.c | 2
mm/memory.c | 213 ++++--
mm/mempolicy.c | 12
mm/mmap.c | 11
mm/mprotect.c | 8
mm/msync.c | 12
mm/nommu.c | 2
mm/page_alloc.c | 75 +-
mm/rmap.c | 58 +-
mm/swap.c | 3
mm/thrash.c | 10
mm/truncate.c | 6
mm/vmscan.c | 29 +
net/bridge/br_if.c | 1
net/core/filter.c | 6
net/dccp/proto.c | 1
net/ipv4/devinet.c | 40 +
net/ipv4/fib_frontend.c | 2
net/ipv4/fib_trie.c | 3
net/ipv4/netfilter/Kconfig | 10
net/ipv4/netfilter/ip_conntrack_netlink.c | 25 -
net/ipv6/addrconf.c | 10
net/ipv6/datagram.c | 2
net/ipv6/exthdrs.c | 22 +
net/ipv6/ip6_flowlabel.c | 16
net/ipv6/raw.c | 4
net/ipv6/udp.c | 4
net/netlink/af_netlink.c | 2
net/sched/sch_netem.c | 2
net/sunrpc/rpc_pipe.c | 26 -
scripts/kconfig/Makefile | 68 +-
sound/core/memalloc.c | 2
sound/usb/usx2y/usx2yhwdeppcm.c | 1
281 files changed, 3435 insertions(+), 2934 deletions(-)
Linus Torvalds wrote:
>I just pushed 2.6.15-rc3 out there, and here are both the shortlog and
>diffstats appended.
>
>Most notable are some VM fixes from Hugh Dickins (with me then redoing
>some of it, but the bulk of the work goes to Hugh). That should finally
>hopefully fix some of the issues some people hit with the PageReserved
>removal and cleanup by Nick Piggin that was in -rc1.
>
>There's also some input updates, cifs fixes, USB EHCI host controller
>updates, and a number of random stuff. Details in the shortlog below,
>
>
Those memory problems affecting v4l/dvb seem to be fixed (for me) , and
everything seems to work, but I got this oops on bootup. This is the
first 2.6.15-rcX kernel that I've installed on this particular box.
2.6.14 worked fine.
Full dmesg posted at:
http://techsounds.org/2.6.15-rc3-oops.txt
Unable to handle kernel NULL pointer dereference at virtual address 00000015
printing eip:
c0149a66
*pde = 00000000
Oops: 0000 [#1]
SMP
Modules linked in: sbp2 usbhid usb_storage cx88_blackbird tda9887 tuner cx88_dvb cx8802 mt352 or51132 video_buf_dvb dvb_core nxt200x firmware_class lgdt330x cx22702 dvb_pll cx8800 cx88xx i2c_algo_bit video_buf ir_common tveeprom i2c_core v4l1_compat v4l2_common btcx_risc videodev ohci1394 ieee1394 ati_agp agpgart snd_atiixp ehci_hcd snd_atiixp_modem snd_ac97_codec snd_ac97_bus ohci_hcd snd_pcm snd_timer snd snd_page_alloc usbcore
CPU: 1
EIP: 0060:[<c0149a66>] Not tainted VLI
EFLAGS: 00010202 (2.6.15-rc3)
EIP is at vm_normal_page+0x17/0x60
eax: 37c08025 ebx: 00000000 ecx: 00000000 edx: 00037c08
esi: 37c08025 edi: ffffe000 ebp: 00000001 esp: f488fed0
ds: 007b es: 007b ss: 0068
Process gdb (pid: 5628, threadinfo=f488e000 task=f7239a30)
Stack: c014e2ae f72a4b80 ffffe000 00000ff8 c04b0820 ffffe000 c014a8f5 00000000
ffffe000 37c08025 00000010 00000000 c014b9a3 c1697920 081b3000 00000010
00000000 bff9be38 f6fa1530 ffffe000 c012536d f6fa1530 f72a4b80 ffffe000
Call Trace:
[<c014e2ae>] find_extend_vma+0x20/0x6b
[<c014a8f5>] get_user_pages+0x29f/0x309
[<c014b9a3>] do_no_page+0x15e/0x2ac
[<c012536d>] access_process_vm+0x133/0x1d7
[<c0106963>] arch_ptrace+0x65/0x4bd
[<c0124fa3>] ptrace_check_attach+0x38/0xae
[<c01258c1>] sys_ptrace+0x6f/0xb2
[<c0102d7d>] syscall_call+0x7/0xb
Code: 24 a0 75 3c c0 e8 87 3a fd ff 83 c4 18 5b 5e e9 ad a1 fb ff 57 56 53 83 ec 0c 8b 5c 24 1c 8b 7c 24 20 8b 74 24 24 89 f2 c1 ea 0c <f6> 43 15 04 75 1c 3b 15 00 08 4b c0 73 27 89 d1 c1 e1 05 03 0d
Regards,
Michael Krufky
vm_normal_page can be called with a NULL vma. This can be replaced with
gate_vma, and no problem because none of the gate vmas use VM_PFNMAP
(if they did they would need to set vm_pgoff).
Signed-off-by: Nick Piggin <[email protected]>
Index: linux-2.6/mm/memory.c
===================================================================
--- linux-2.6.orig/mm/memory.c
+++ linux-2.6/mm/memory.c
@@ -988,7 +988,8 @@ int get_user_pages(struct task_struct *t
return i ? : -EFAULT;
}
if (pages) {
- struct page *page = vm_normal_page(vma, start, *pte);
+ struct page *page;
+ page = vm_normal_page(gate_vma, start, *pte);
pages[i] = page;
if (page)
get_page(page);
Nick Piggin wrote:
> Michael Krufky wrote:
>
>> Unable to handle kernel NULL pointer dereference at virtual address
>
>> EFLAGS: 00010202 (2.6.15-rc3) EIP is at vm_normal_page+0x17/0x60
>
>> Process gdb (pid: 5628, threadinfo=f488e000 task=f7239a30)
>
>> [<c014a8f5>] get_user_pages+0x29f/0x309
>
> The clues point to the following patch. Can you give it a test
> please?
>
> Thanks,
> Nick
Nick-
Thank you, this patch fixed the oops, and it also fixed another bug that
I didnt yet report:
2.6.15-rc3 would hang when rebooting, just after it says, "Sending all
processes the TERM signal...."
Your patch below fixes this as well. I've noticed that akpm has already
applied this to his tree. :-D
Cheers,
Michael Krufky
>vm_normal_page can be called with a NULL vma. This can be replaced with
>gate_vma, and no problem because none of the gate vmas use VM_PFNMAP
>(if they did they would need to set vm_pgoff).
>
>Signed-off-by: Nick Piggin <[email protected]>
>
>Index: linux-2.6/mm/memory.c
>===================================================================
>--- linux-2.6.orig/mm/memory.c
>+++ linux-2.6/mm/memory.c
>@@ -988,7 +988,8 @@ int get_user_pages(struct task_struct *t
> return i ? : -EFAULT;
> }
> if (pages) {
>- struct page *page = vm_normal_page(vma, start, *pte);
>+ struct page *page;
>+ page = vm_normal_page(gate_vma, start, *pte);
> pages[i] = page;
> if (page)
> get_page(page);
>
>
Linus Torvalds wrote:
> I just pushed 2.6.15-rc3 out there, and here are both the shortlog and
> diffstats appended.
A config issue? It says 'choose M' which is not offered. Maybe it is just
an option for the bt8xx driver, which itself can be built as a module
(CONFIG_VIDEO_BT848)?
DVB/ATSC Support for bt878 based TV cards (VIDEO_BT848_DVB) [N/y/?] (NEW) ?
This adds support for DVB/ATSC cards based on the BT878 chip.
To compile this driver as a module, choose M here: the
module will be called dvb-bt8xx.
--
Eyal Lebedinsky ([email protected]) <http://samba.org/eyal/>
attach .zip as .dat
Eyal Lebedinsky wrote:
>Linus Torvalds wrote:
>
>
>>I just pushed 2.6.15-rc3 out there, and here are both the shortlog and
>>diffstats appended.
>>
>>
>A config issue? It says 'choose M' which is not offered. Maybe it is just
>an option for the bt8xx driver, which itself can be built as a module
>(CONFIG_VIDEO_BT848)?
>
>
> DVB/ATSC Support for bt878 based TV cards (VIDEO_BT848_DVB) [N/y/?] (NEW) ?
>
>This adds support for DVB/ATSC cards based on the BT878 chip.
>
>To compile this driver as a module, choose M here: the
>module will be called dvb-bt8xx.
>
No -- It's a typo. CONFIG_VIDEO_BT848_DVB is just an option to
CONFIG_VIDEO_BT848. It is a boolean option, and when chosen, Kconfig
SELECT's CONFIG_DVB_BT8XX, and that's the actual menu item that builds
the module.
The option is set as bool, so that if it's dependencies are set as
modules, dvb-bt8xx will also build as a module. If, however, the
dependencies are set to build in-kernel, then dvb-bt8xx will do so as well.
Consider this menu item a symbolic link to CONFIG_DVB_BT8XX -- it was
the only way to add this as a submenu option to VIDEO_BT848, without
removing the reference in the DVB submenu.
Anyhow, this patch removes the incorrect info:
Signed-off-by: Michael Krufky <[email protected]>
On Tue, 29 Nov 2005, Nick Piggin wrote:
>
> The clues point to the following patch. Can you give it a test
> please?
Obviously correct. Thanks,
Linus
On Tue, 29 Nov 2005, Michael Krufky wrote:
>
> Those memory problems affecting v4l/dvb seem to be fixed (for me) , and
> everything seems to work, but I got this oops on bootup. This is the first
> 2.6.15-rcX kernel that I've installed on this particular box. 2.6.14 worked
> fine.
Ok, Nick's obviously correct patch fixed that, but now I wonder what the
_heck_ your bootup process does:
> Process gdb (pid: 5628, threadinfo=f488e000 task=f7239a30)
what kind of _strange_ boot process has gdb in it?
Morbidly curious,
Linus
Linus Torvalds wrote:
>On Tue, 29 Nov 2005, Michael Krufky wrote:
>
>
>>Those memory problems affecting v4l/dvb seem to be fixed (for me) , and
>>everything seems to work, but I got this oops on bootup. This is the first
>>2.6.15-rcX kernel that I've installed on this particular box. 2.6.14 worked
>>fine.
>>
>>
>Ok, Nick's obviously correct patch fixed that, but now I wonder what the
>_heck_ your bootup process does:
>
>>Process gdb (pid: 5628, threadinfo=f488e000 task=f7239a30)
>>
>>
>what kind of _strange_ boot process has gdb in it?
>
>Morbidly curious,
>
> Linus
>
>
Linus-
Good point... I don't know what is going on there. That box is running
a newly-installed debian sarge, with it's default startup scripts. I
have done nothing to that system besides kernel testing and v4l / dvb
testing and development.
The oops was showing up immediately before xorg opens with it's
user-login box...
In other words, the OOPS is the last thing to show on the screen in text
mode, before the console switches into X, using debian sarge's default
bootup process.
I have no idea why gdb is running.... hmm... Anyhow, I'm away from that
machine right now, and it is powered off, so I can't look directly at
the startup scripts right now. Would you like me to send more info
later on when I get home? If so, what would you like to see?
Cheers,
Michael Krufky
On Tue, 29 Nov 2005, Michael Krufky wrote:
>
> In other words, the OOPS is the last thing to show on the screen in text mode,
> before the console switches into X, using debian sarge's default bootup
> process.
Ok. Whatever it is, I'm happy it is doing that, since it caused us to see
the oops quickly. None of _my_ boxes do that, obviously (and I tested on
x86, x86-64 and ppc64 exactly to get reasonable coverage of what different
architectures might do - but none of the boxes are debian-based).
> I have no idea why gdb is running.... hmm... Anyhow, I'm away from that
> machine right now, and it is powered off, so I can't look directly at the
> startup scripts right now. Would you like me to send more info later on when
> I get home? If so, what would you like to see?
It's not important, I was just curious about what strange things people
have in their bootup scripts. If you can just grep through the rc.d files
to see what uses gdb, I'd just like to know...
Linus
* Linus Torvalds ([email protected]) wrote:
> On Tue, 29 Nov 2005, Michael Krufky wrote:
> > In other words, the OOPS is the last thing to show on the screen in text mode,
> > before the console switches into X, using debian sarge's default bootup
> > process.
>
> Ok. Whatever it is, I'm happy it is doing that, since it caused us to see
> the oops quickly. None of _my_ boxes do that, obviously (and I tested on
> x86, x86-64 and ppc64 exactly to get reasonable coverage of what different
> architectures might do - but none of the boxes are debian-based).
I'm pretty curious about it too, none of my debian-based boxes have
'gdb' anywhere in /etc/init.d. The only thing I see is that the shell
script /usr/bin/mozilla-firefox calls gdb when passed '--debugger', or
when the DEBUG environment variable is set... Perhaps he's doing that
during his .xsession?
Thanks,
Stephen
Stephen Frost wrote:
>* Linus Torvalds ([email protected]) wrote:
>
>
>>On Tue, 29 Nov 2005, Michael Krufky wrote:
>>
>>
>>>In other words, the OOPS is the last thing to show on the screen in text mode,
>>>before the console switches into X, using debian sarge's default bootup
>>>process.
>>>
>>>
>>Ok. Whatever it is, I'm happy it is doing that, since it caused us to see
>>the oops quickly. None of _my_ boxes do that, obviously (and I tested on
>>x86, x86-64 and ppc64 exactly to get reasonable coverage of what different
>>architectures might do - but none of the boxes are debian-based).
>>
>>
>I'm pretty curious about it too, none of my debian-based boxes have
>'gdb' anywhere in /etc/init.d. The only thing I see is that the shell
>script /usr/bin/mozilla-firefox calls gdb when passed '--debugger', or
>when the DEBUG environment variable is set... Perhaps he's doing that
>during his .xsession?
>
>
I don't think that the .xsession can be involved, here..... The oops
happens BEFORE user login, and firefox definately isn't loaded before
logging in. ;-)
Anyhow, I forgot to mention that I am using the debian/testing sarge apt
repository ... Once again, I have a purely default configuration, with
the exception of the kernel. When I get home, I'll grep through my
startup scripts... I'll let you guys know what I find.
Cheers,
Mike
On Tue, Nov 29, 2005 at 08:38:48AM -0800, Linus Torvalds wrote:
>
>
> On Tue, 29 Nov 2005, Michael Krufky wrote:
> >
> > In other words, the OOPS is the last thing to show on the screen in text mode,
> > before the console switches into X, using debian sarge's default bootup
> > process.
>
> Ok. Whatever it is, I'm happy it is doing that, since it caused us to see
> the oops quickly. None of _my_ boxes do that, obviously (and I tested on
> x86, x86-64 and ppc64 exactly to get reasonable coverage of what different
> architectures might do - but none of the boxes are debian-based).
>
> > I have no idea why gdb is running.... hmm... Anyhow, I'm away from that
> > machine right now, and it is powered off, so I can't look directly at the
> > startup scripts right now. Would you like me to send more info later on when
> > I get home? If so, what would you like to see?
>
> It's not important, I was just curious about what strange things people
> have in their bootup scripts. If you can just grep through the rc.d files
> to see what uses gdb, I'd just like to know...
I doubt gdb is in rc.d scripts. My wild uninformed guess would be
that some process (maybe xinit?) hit a SEGV and had its own signal
handler installed that tried to call gdb and attach to the crashing
process. I could imagine something like that being useful for
generating nice userspace stack traces to send to the developers. I
think I've seen something similar in some builds.
-chris
* Chris Shoemaker ([email protected]) wrote:
> I doubt gdb is in rc.d scripts. My wild uninformed guess would be
> that some process (maybe xinit?) hit a SEGV and had its own signal
> handler installed that tried to call gdb and attach to the crashing
> process. I could imagine something like that being useful for
> generating nice userspace stack traces to send to the developers. I
> think I've seen something similar in some builds.
Not sure if it's relevent, but I think samba does this too...
Stephen
Just reporting a compile error with gcc-4.0.2 on i386. Below is the error. My
.config is attached. The error only appears at the very end of the vmlinux
linking stage.
I'm using binutils-2.16.91.0.3 20050821.
The error goes away when using gcc-3.4.3. I realize this is probably more a gcc
bug than a kernel bug, but I figured I'd let kernel people know anyway.
. . .
AS arch/i386/lib/putuser.o
CC arch/i386/lib/strstr.o
CC arch/i386/lib/usercopy.o
AR arch/i386/lib/lib.a
GEN .version
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD vmlinux
sound/built-in.o:(.rodata+0x54e4): undefined reference to `__compound_literal.84'
sound/built-in.o:(.rodata+0x54f4): undefined reference to `__compound_literal.87'
sound/built-in.o:(.rodata+0x5504): undefined reference to `__compound_literal.90'
sound/built-in.o:(.rodata+0x5514): undefined reference to `__compound_literal.93'
sound/built-in.o:(.rodata+0x5524): undefined reference to `__compound_literal.96'
sound/built-in.o:(.rodata+0x5534): undefined reference to `__compound_literal.99'
sound/built-in.o:(.rodata+0x5544): undefined reference to `__compound_literal.102'
sound/built-in.o:(.rodata+0x5554): undefined reference to `__compound_literal.105'
sound/built-in.o:(.rodata+0x5564): undefined reference to `__compound_literal.108'
sound/built-in.o:(.rodata+0x5574): undefined reference to `__compound_literal.113'
sound/built-in.o:(.rodata+0x5584): undefined reference to `__compound_literal.115'
sound/built-in.o:(.rodata+0x5594): undefined reference to `__compound_literal.117'
sound/built-in.o:(.rodata+0x55a4): undefined reference to `__compound_literal.119'
sound/built-in.o:(.rodata+0x55b4): undefined reference to `__compound_literal.122'
sound/built-in.o:(.rodata+0x55c4): undefined reference to `__compound_literal.125'
sound/built-in.o:(.rodata+0x55d4): undefined reference to `__compound_literal.127'
sound/built-in.o:(.rodata+0x55e4): undefined reference to `__compound_literal.129'
sound/built-in.o:(.rodata+0x55f4): undefined reference to `__compound_literal.131'
sound/built-in.o:(.rodata+0x5604): undefined reference to `__compound_literal.133'
sound/built-in.o:(.rodata+0x5614): undefined reference to `__compound_literal.135'
sound/built-in.o:(.rodata+0x5624): undefined reference to `__compound_literal.137'
sound/built-in.o:(.rodata+0x5634): undefined reference to `__compound_literal.139'
sound/built-in.o:(.rodata+0x5644): undefined reference to `__compound_literal.141'
sound/built-in.o:(.rodata+0x5654): undefined reference to `__compound_literal.143'
sound/built-in.o:(.rodata+0x5664): undefined reference to `__compound_literal.145'
sound/built-in.o:(.rodata+0x5674): undefined reference to `__compound_literal.147'
sound/built-in.o:(.rodata+0x5684): undefined reference to `__compound_literal.149'
sound/built-in.o:(.rodata+0x5694): undefined reference to `__compound_literal.151'
sound/built-in.o:(.rodata+0x56a4): undefined reference to `__compound_literal.154'
sound/built-in.o:(.rodata+0x56b4): undefined reference to `__compound_literal.156'
sound/built-in.o:(.rodata+0x56c4): undefined reference to `__compound_literal.158'
sound/built-in.o:(.rodata+0x56d4): undefined reference to `__compound_literal.160'
sound/built-in.o:(.rodata+0x56f4): undefined reference to `__compound_literal.163'
sound/built-in.o:(.rodata+0x5704): undefined reference to `__compound_literal.165'
sound/built-in.o:(.rodata+0x5714): undefined reference to `__compound_literal.167'
sound/built-in.o:(.rodata+0x5724): undefined reference to `__compound_literal.169'
sound/built-in.o:(.rodata+0x5734): undefined reference to `__compound_literal.171'
sound/built-in.o:(.rodata+0x5744): undefined reference to `__compound_literal.173'
sound/built-in.o:(.rodata+0x5754): undefined reference to `__compound_literal.175'
sound/built-in.o:(.rodata+0x5764): undefined reference to `__compound_literal.177'
sound/built-in.o:(.rodata+0x5774): undefined reference to `__compound_literal.179'
sound/built-in.o:(.rodata+0x5784): undefined reference to `__compound_literal.181'
sound/built-in.o:(.rodata+0x5794): undefined reference to `__compound_literal.183'
sound/built-in.o:(.rodata+0x57a4): undefined reference to `__compound_literal.185'
sound/built-in.o:(.rodata+0x57b4): undefined reference to `__compound_literal.187'
sound/built-in.o:(.rodata+0x57c4): undefined reference to `__compound_literal.189'
sound/built-in.o:(.rodata+0x57d4): undefined reference to `__compound_literal.192'
sound/built-in.o:(.rodata+0x57e4): undefined reference to `__compound_literal.194'
sound/built-in.o:(.rodata+0x57f4): undefined reference to `__compound_literal.196'
sound/built-in.o:(.rodata+0x5804): undefined reference to `__compound_literal.199'
sound/built-in.o:(.rodata+0x5814): undefined reference to `__compound_literal.201'
sound/built-in.o:(.rodata+0x5834): undefined reference to `__compound_literal.204'
sound/built-in.o:(.rodata+0x5844): undefined reference to `__compound_literal.206'
sound/built-in.o:(.rodata+0x5854): undefined reference to `__compound_literal.208'
make: *** [vmlinux] Error 1
--
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer Fax: (330) 644-8110
Commercial Timesharing Inc. Email: [email protected]
On Tue, 2005-11-29 at 13:37 -0500, Byron Stanoszek wrote:
> Just reporting a compile error with gcc-4.0.2 on i386. Below is the error. My
> .config is attached. The error only appears at the very end of the vmlinux
> linking stage.
this is a known gcc bug that already got fixed..... (it's in gcc
bugzilla for a while)
On Mon, Nov 28, 2005 at 08:11:35PM -0800, Linus Torvalds wrote:
>
> I just pushed 2.6.15-rc3 out there, and here are both the shortlog and
> diffstats appended.
>
This one did not mount root. I got:
Can't open root dev "831" or unknown block(8,49)
Please append a correct root= boot option
unable to mount root fs from block(8,49)
Now 2.6.14 works with exactl�y the same lilo.con,
where I have root=/dev/sdd1 (SATA drive)
The only changes from the 2.6.14 .config were a different
framebuffer font for the console (which worked fine) and
a change from voluntary preempt to fully preemptible in the
hope of running flash games and niced compiles together.
Helge Hafting
On Tuesday, 29 of November 2005 05:11, Linus Torvalds wrote:
>
> I just pushed 2.6.15-rc3 out there, and here are both the shortlog and
> diffstats appended.
Hangs solid on boot on dual-core Athlon64. No details yet, but I'm working
on them. I wonder if anyone else is seeing this.
Greetings,
Rafael
On Tue, 29 Nov 2005, Helge Hafting wrote:
>
> Can't open root dev "831" or unknown block(8,49)
> Please append a correct root= boot option
> unable to mount root fs from block(8,49)
Sounds like your SATA drive wasn't detected.
Please double-check that your config changes didn't disable it, but
otherwise:
> Now 2.6.14 works with exactly the same lilo.con,
> where I have root=/dev/sdd1 (SATA drive)
please specify _which_ SATA driver you are using so that Jeff & co can try
to figure out what broke since 2.6.14.
Also, if you can pinpoint where it broke better, that probably helps
(most sata changes were in -rc1, but there were some sata_mv and sata_sil4
changes in in -rc2 too, so even just poinpointing it to either of those
will help, although the daily builds might be even better).
Linus
Update:
On Tuesday, 29 of November 2005 22:47, Rafael J. Wysocki wrote:
> On Tuesday, 29 of November 2005 05:11, Linus Torvalds wrote:
> >
> > I just pushed 2.6.15-rc3 out there, and here are both the shortlog and
> > diffstats appended.
>
> Hangs solid on boot on dual-core Athlon64. No details yet, but I'm working
> on them. I wonder if anyone else is seeing this.
The problem is caused by the ehci_hcd driver and fixed by the David
Brownell's ehci-hang-fix.patch that's already in -mm.
Thanks,
Rafael
On Tue, 29 Nov 2005 23:42:35 +0100
"Rafael J. Wysocki" <[email protected]> wrote:
> Update:
>
> On Tuesday, 29 of November 2005 22:47, Rafael J. Wysocki wrote:
> > On Tuesday, 29 of November 2005 05:11, Linus Torvalds wrote:
> > >
> > > I just pushed 2.6.15-rc3 out there, and here are both the shortlog and
> > > diffstats appended.
> >
> > Hangs solid on boot on dual-core Athlon64. No details yet, but I'm working
> > on them. I wonder if anyone else is seeing this.
>
> The problem is caused by the ehci_hcd driver and fixed by the David
> Brownell's ehci-hang-fix.patch that's already in -mm.
I assume this is that bug:
--
[ 47.145873] kjournald starting. Commit interval 5 seconds
[ 47.187797] EXT3-fs: mounted filesystem with ordered data mode.
[ 48.395152] usbcore: registered new driver usbfs
[ 48.433382] usbcore: registered new driver hub
[ 58.733294] NMI Watchdog detected LOCKUP on CPU 1
[ 58.770674] CPU 1
[ 58.799348] Modules linked in: ehci_hcd i2c_amd8111 i2c_amd756 i2c_core snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc sky2 tg3 usbcore
[ 58.950846] Pid: 2042, comm: modprobe Not tainted 2.6.15-rc3-sky2 #1
[ 58.996375] RIP: 0010:[<ffffffff803c145b>] <ffffffff803c145b>{.text.lock.spinlock+34}
[ 59.022530] RSP: 0018:ffff81007fb39bb0 EFLAGS: 00000086
[ 59.090005] RAX: 0000000000000296 RBX: 0000000000002301 RCX: 0000000000000005
[ 59.138990] RDX: 0000000000000008 RSI: 0000000000002301 RDI: ffff81007cf84554
[ 59.187922] RBP: 0000000000000005 R08: 0000000000000000 R09: 0000000000000000
[ 59.236698] R10: 0000000000000037 R11: 000000000000000a R12: ffff81007cf84400
[ 59.285266] R13: 0000000000002395 R14: 0000000000000008 R15: ffff81007cf84538
[ 59.333549] FS: 00002aaaaaac53c0(0000) GS:ffffffff805c6880(0000) knlGS:0000000000000000
[ 59.385260] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 59.429103] CR2: 0000003d49a92660 CR3: 000000007d1c3000 CR4: 00000000000006e0
[ 59.477671] Process modprobe (pid: 2042, threadinfo ffff81007fb38000, task ffff81007c001060)
[ 59.530809] Stack: ffffffff88114d8a ffff810037cae1b0 0000000000000000 0000000000040000
[ 59.557613] 0000000000004283 0000000000000016 ffffffff8811ac60 ffff810037cae1b0
[ 59.609531] 0000000000000004 0000000000000002
[ 59.651373] Call Trace:<ffffffff88114d8a>{:ehci_hcd:ehci_hub_control+90} <ffffffff80257d38>{pci_bus_read_config_word+136}
[ 59.713317] <ffffffff80257c84>{pci_bus_read_config_byte+116} <ffffffff8811555d>{:ehci_hcd:ehci_port_power+157}
[ 59.775028] <ffffffff8811590d>{:ehci_hcd:ehci_pci_reinit+909} <ffffffff88117724>{:ehci_hcd:ehci_pci_reset+1156}
[ 59.837778] <ffffffff8030af1f>{pci_conf1_read+223} <ffffffff88008ee5>{:usbcore:usb_add_hcd+117}
[ 59.896527] <ffffffff8030a9ce>{pcibios_set_master+30} <ffffffff88012a4d>{:usbcore:usb_hcd_pci_probe+653}
[ 59.958237] <ffffffff8025c639>{pci_device_probe+89} <ffffffff802b867d>{driver_probe_device+77}
[ 60.017091] <ffffffff802b8760>{__driver_attach+0} <ffffffff802b87a0>{__driver_attach+64}
[ 60.074566] <ffffffff802b8760>{__driver_attach+0} <ffffffff802b7a49>{bus_for_each_dev+73}
[ 60.132538] <ffffffff802b7f80>{bus_add_driver+128} <ffffffff8025c130>{__pci_register_driver+160}
[ 60.192379] <ffffffff80150a22>{sys_init_module+258} <ffffffff8010dcee>{system_call+126}
[ 60.249856]
[ 60.315333]
[ 60.315334] Code: 83 3f 00 7e f9 e9 2e fe ff ff f3 90 83 3f 00 7e f9 e9 30 fe
[ 60.404781] console shuts up ...
[ 60.445767] <0>Kernel panic - not syncing: Aiee, killing interrupt handler!
On Tue, Nov 29, 2005 at 02:53:28PM -0800, Stephen Hemminger wrote:
> On Tue, 29 Nov 2005 23:42:35 +0100
> "Rafael J. Wysocki" <[email protected]> wrote:
>
> > Update:
> >
> > On Tuesday, 29 of November 2005 22:47, Rafael J. Wysocki wrote:
> > > On Tuesday, 29 of November 2005 05:11, Linus Torvalds wrote:
> > > >
> > > > I just pushed 2.6.15-rc3 out there, and here are both the shortlog and
> > > > diffstats appended.
> > >
> > > Hangs solid on boot on dual-core Athlon64. No details yet, but I'm working
> > > on them. I wonder if anyone else is seeing this.
> >
> > The problem is caused by the ehci_hcd driver and fixed by the David
> > Brownell's ehci-hang-fix.patch that's already in -mm.
>
> I assume this is that bug:
> --
> [ 47.145873] kjournald starting. Commit interval 5 seconds
> [ 47.187797] EXT3-fs: mounted filesystem with ordered data mode.
> [ 48.395152] usbcore: registered new driver usbfs
> [ 48.433382] usbcore: registered new driver hub
> [ 58.733294] NMI Watchdog detected LOCKUP on CPU 1
> [ 58.770674] CPU 1
> [ 58.799348] Modules linked in: ehci_hcd i2c_amd8111 i2c_amd756 i2c_core snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc sky2 tg3 usbcore
> [ 58.950846] Pid: 2042, comm: modprobe Not tainted 2.6.15-rc3-sky2 #1
> [ 58.996375] RIP: 0010:[<ffffffff803c145b>] <ffffffff803c145b>{.text.lock.spinlock+34}
> [ 59.022530] RSP: 0018:ffff81007fb39bb0 EFLAGS: 00000086
> [ 59.090005] RAX: 0000000000000296 RBX: 0000000000002301 RCX: 0000000000000005
> [ 59.138990] RDX: 0000000000000008 RSI: 0000000000002301 RDI: ffff81007cf84554
> [ 59.187922] RBP: 0000000000000005 R08: 0000000000000000 R09: 0000000000000000
> [ 59.236698] R10: 0000000000000037 R11: 000000000000000a R12: ffff81007cf84400
> [ 59.285266] R13: 0000000000002395 R14: 0000000000000008 R15: ffff81007cf84538
> [ 59.333549] FS: 00002aaaaaac53c0(0000) GS:ffffffff805c6880(0000) knlGS:0000000000000000
> [ 59.385260] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 59.429103] CR2: 0000003d49a92660 CR3: 000000007d1c3000 CR4: 00000000000006e0
> [ 59.477671] Process modprobe (pid: 2042, threadinfo ffff81007fb38000, task ffff81007c001060)
> [ 59.530809] Stack: ffffffff88114d8a ffff810037cae1b0 0000000000000000 0000000000040000
> [ 59.557613] 0000000000004283 0000000000000016 ffffffff8811ac60 ffff810037cae1b0
> [ 59.609531] 0000000000000004 0000000000000002
> [ 59.651373] Call Trace:<ffffffff88114d8a>{:ehci_hcd:ehci_hub_control+90} <ffffffff80257d38>{pci_bus_read_config_word+136}
> [ 59.713317] <ffffffff80257c84>{pci_bus_read_config_byte+116} <ffffffff8811555d>{:ehci_hcd:ehci_port_power+157}
> [ 59.775028] <ffffffff8811590d>{:ehci_hcd:ehci_pci_reinit+909} <ffffffff88117724>{:ehci_hcd:ehci_pci_reset+1156}
> [ 59.837778] <ffffffff8030af1f>{pci_conf1_read+223} <ffffffff88008ee5>{:usbcore:usb_add_hcd+117}
> [ 59.896527] <ffffffff8030a9ce>{pcibios_set_master+30} <ffffffff88012a4d>{:usbcore:usb_hcd_pci_probe+653}
> [ 59.958237] <ffffffff8025c639>{pci_device_probe+89} <ffffffff802b867d>{driver_probe_device+77}
> [ 60.017091] <ffffffff802b8760>{__driver_attach+0} <ffffffff802b87a0>{__driver_attach+64}
> [ 60.074566] <ffffffff802b8760>{__driver_attach+0} <ffffffff802b7a49>{bus_for_each_dev+73}
> [ 60.132538] <ffffffff802b7f80>{bus_add_driver+128} <ffffffff8025c130>{__pci_register_driver+160}
> [ 60.192379] <ffffffff80150a22>{sys_init_module+258} <ffffffff8010dcee>{system_call+126}
I think so. Can people test the following patch to make sure it fixes
the issue for them, before I send it to Linus?
thanks,
greg k-h
------------------
From: David Brownell <[email protected]>
Subject: USB: ehci fixups
Rename the EHCI "reset" routine so it better matches what it does (setup);
and move the one-time data structure setup earlier, before doing anything
that implicitly relies on it having been completed already.
From: David Brownell <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/host/ehci-pci.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
--- gregkh-2.6.orig/drivers/usb/host/ehci-pci.c
+++ gregkh-2.6/drivers/usb/host/ehci-pci.c
@@ -121,8 +121,8 @@ static int ehci_pci_reinit(struct ehci_h
return 0;
}
-/* called by khubd or root hub (re)init threads; leaves HC in halt state */
-static int ehci_pci_reset(struct usb_hcd *hcd)
+/* called during probe() after chip reset completes */
+static int ehci_pci_setup(struct usb_hcd *hcd)
{
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
struct pci_dev *pdev = to_pci_dev(hcd->self.controller);
@@ -141,6 +141,11 @@ static int ehci_pci_reset(struct usb_hcd
if (retval)
return retval;
+ /* data structure init */
+ retval = ehci_init(hcd);
+ if (retval)
+ return retval;
+
/* NOTE: only the parts below this line are PCI-specific */
switch (pdev->vendor) {
@@ -154,7 +159,8 @@ static int ehci_pci_reset(struct usb_hcd
/* AMD8111 EHCI doesn't work, according to AMD errata */
if (pdev->device == 0x7463) {
ehci_info(ehci, "ignoring AMD8111 (errata)\n");
- return -EIO;
+ retval = -EIO;
+ goto done;
}
break;
case PCI_VENDOR_ID_NVIDIA:
@@ -207,9 +213,8 @@ static int ehci_pci_reset(struct usb_hcd
/* REVISIT: per-port wake capability (PCI 0x62) currently unused */
retval = ehci_pci_reinit(ehci, pdev);
-
- /* finish init */
- return ehci_init(hcd);
+done:
+ return retval;
}
/*-------------------------------------------------------------------------*/
@@ -344,7 +349,7 @@ static const struct hc_driver ehci_pci_h
/*
* basic lifecycle operations
*/
- .reset = ehci_pci_reset,
+ .reset = ehci_pci_setup,
.start = ehci_run,
#ifdef CONFIG_PM
.suspend = ehci_pci_suspend,
On Tue, 29 Nov 2005 15:37:44 -0800
Greg KH <[email protected]> wrote:
> On Tue, Nov 29, 2005 at 02:53:28PM -0800, Stephen Hemminger wrote:
> > On Tue, 29 Nov 2005 23:42:35 +0100
> > "Rafael J. Wysocki" <[email protected]> wrote:
> >
> > > Update:
> > >
> > > On Tuesday, 29 of November 2005 22:47, Rafael J. Wysocki wrote:
> > > > On Tuesday, 29 of November 2005 05:11, Linus Torvalds wrote:
> > > > >
> > > > > I just pushed 2.6.15-rc3 out there, and here are both the shortlog and
> > > > > diffstats appended.
> > > >
> > > > Hangs solid on boot on dual-core Athlon64. No details yet, but I'm working
> > > > on them. I wonder if anyone else is seeing this.
> > >
> > > The problem is caused by the ehci_hcd driver and fixed by the David
> > > Brownell's ehci-hang-fix.patch that's already in -mm.
> >
> > I assume this is that bug:
> > --
> > [ 47.145873] kjournald starting. Commit interval 5 seconds
> > [ 47.187797] EXT3-fs: mounted filesystem with ordered data mode.
> > [ 48.395152] usbcore: registered new driver usbfs
> > [ 48.433382] usbcore: registered new driver hub
> > [ 58.733294] NMI Watchdog detected LOCKUP on CPU 1
> > [ 58.770674] CPU 1
> > [ 58.799348] Modules linked in: ehci_hcd i2c_amd8111 i2c_amd756 i2c_core snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc sky2 tg3 usbcore
> > [ 58.950846] Pid: 2042, comm: modprobe Not tainted 2.6.15-rc3-sky2 #1
> > [ 58.996375] RIP: 0010:[<ffffffff803c145b>] <ffffffff803c145b>{.text.lock.spinlock+34}
> > [ 59.022530] RSP: 0018:ffff81007fb39bb0 EFLAGS: 00000086
> > [ 59.090005] RAX: 0000000000000296 RBX: 0000000000002301 RCX: 0000000000000005
> > [ 59.138990] RDX: 0000000000000008 RSI: 0000000000002301 RDI: ffff81007cf84554
> > [ 59.187922] RBP: 0000000000000005 R08: 0000000000000000 R09: 0000000000000000
> > [ 59.236698] R10: 0000000000000037 R11: 000000000000000a R12: ffff81007cf84400
> > [ 59.285266] R13: 0000000000002395 R14: 0000000000000008 R15: ffff81007cf84538
> > [ 59.333549] FS: 00002aaaaaac53c0(0000) GS:ffffffff805c6880(0000) knlGS:0000000000000000
> > [ 59.385260] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > [ 59.429103] CR2: 0000003d49a92660 CR3: 000000007d1c3000 CR4: 00000000000006e0
> > [ 59.477671] Process modprobe (pid: 2042, threadinfo ffff81007fb38000, task ffff81007c001060)
> > [ 59.530809] Stack: ffffffff88114d8a ffff810037cae1b0 0000000000000000 0000000000040000
> > [ 59.557613] 0000000000004283 0000000000000016 ffffffff8811ac60 ffff810037cae1b0
> > [ 59.609531] 0000000000000004 0000000000000002
> > [ 59.651373] Call Trace:<ffffffff88114d8a>{:ehci_hcd:ehci_hub_control+90} <ffffffff80257d38>{pci_bus_read_config_word+136}
> > [ 59.713317] <ffffffff80257c84>{pci_bus_read_config_byte+116} <ffffffff8811555d>{:ehci_hcd:ehci_port_power+157}
> > [ 59.775028] <ffffffff8811590d>{:ehci_hcd:ehci_pci_reinit+909} <ffffffff88117724>{:ehci_hcd:ehci_pci_reset+1156}
> > [ 59.837778] <ffffffff8030af1f>{pci_conf1_read+223} <ffffffff88008ee5>{:usbcore:usb_add_hcd+117}
> > [ 59.896527] <ffffffff8030a9ce>{pcibios_set_master+30} <ffffffff88012a4d>{:usbcore:usb_hcd_pci_probe+653}
> > [ 59.958237] <ffffffff8025c639>{pci_device_probe+89} <ffffffff802b867d>{driver_probe_device+77}
> > [ 60.017091] <ffffffff802b8760>{__driver_attach+0} <ffffffff802b87a0>{__driver_attach+64}
> > [ 60.074566] <ffffffff802b8760>{__driver_attach+0} <ffffffff802b7a49>{bus_for_each_dev+73}
> > [ 60.132538] <ffffffff802b7f80>{bus_add_driver+128} <ffffffff8025c130>{__pci_register_driver+160}
> > [ 60.192379] <ffffffff80150a22>{sys_init_module+258} <ffffffff8010dcee>{system_call+126}
>
> I think so. Can people test the following patch to make sure it fixes
> the issue for them, before I send it to Linus?
>
> thanks,
>
> greg k-h
> ------------------
>
>
> From: David Brownell <[email protected]>
> Subject: USB: ehci fixups
>
> Rename the EHCI "reset" routine so it better matches what it does (setup);
> and move the one-time data structure setup earlier, before doing anything
> that implicitly relies on it having been completed already.
>
> From: David Brownell <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> ---
> drivers/usb/host/ehci-pci.c | 19 ++++++++++++-------
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> --- gregkh-2.6.orig/drivers/usb/host/ehci-pci.c
> +++ gregkh-2.6/drivers/usb/host/ehci-pci.c
> @@ -121,8 +121,8 @@ static int ehci_pci_reinit(struct ehci_h
> return 0;
> }
>
> -/* called by khubd or root hub (re)init threads; leaves HC in halt state */
> -static int ehci_pci_reset(struct usb_hcd *hcd)
> +/* called during probe() after chip reset completes */
> +static int ehci_pci_setup(struct usb_hcd *hcd)
> {
> struct ehci_hcd *ehci = hcd_to_ehci(hcd);
> struct pci_dev *pdev = to_pci_dev(hcd->self.controller);
> @@ -141,6 +141,11 @@ static int ehci_pci_reset(struct usb_hcd
> if (retval)
> return retval;
>
> + /* data structure init */
> + retval = ehci_init(hcd);
> + if (retval)
> + return retval;
> +
> /* NOTE: only the parts below this line are PCI-specific */
>
> switch (pdev->vendor) {
> @@ -154,7 +159,8 @@ static int ehci_pci_reset(struct usb_hcd
> /* AMD8111 EHCI doesn't work, according to AMD errata */
> if (pdev->device == 0x7463) {
> ehci_info(ehci, "ignoring AMD8111 (errata)\n");
> - return -EIO;
> + retval = -EIO;
> + goto done;
> }
> break;
> case PCI_VENDOR_ID_NVIDIA:
> @@ -207,9 +213,8 @@ static int ehci_pci_reset(struct usb_hcd
> /* REVISIT: per-port wake capability (PCI 0x62) currently unused */
>
> retval = ehci_pci_reinit(ehci, pdev);
> -
> - /* finish init */
> - return ehci_init(hcd);
> +done:
> + return retval;
> }
>
> /*-------------------------------------------------------------------------*/
> @@ -344,7 +349,7 @@ static const struct hc_driver ehci_pci_h
> /*
> * basic lifecycle operations
> */
> - .reset = ehci_pci_reset,
> + .reset = ehci_pci_setup,
> .start = ehci_run,
> #ifdef CONFIG_PM
> .suspend = ehci_pci_suspend,
Wrong, this now recursive faults:
[ 125.653485] <1>Fixing recursive fault but reboot is needed!
[ 125.653620] ----------- [cut here ] --------- [please bite here ] ---------
[ 125.653622] Kernel BUG at mm/mmap.c:1956
[ 125.653624] invalid operand: 0000 [727] SMP
[ 125.653625] CPU 0
[ 125.653627] Modules linked in:
[ 125.653629] Pid: 746, comm: hotplug Not tainted 2.6.15-rc3 #1
[ 125.653631] RIP: 0010:[<ffffffff8016cecb>] <ffffffff8016cecb>{exit_mmap+235}
[ 125.653636] RSP: 0018:ffff81007ebcfeb8 EFLAGS: 00010202
[ 125.653639] RAX: 0000000000000000 RBX: ffff810002c0e3e0 RCX: 00000000000005b4
[ 125.653642] RDX: 000000000000000f RSI: ffff81007fc2ead8 RDI: ffff81007ff5ca80
[ 125.653645] RBP: 0000000000000000 R08: ffff81007ff2c920 R09: 0000000000000000
[ 125.653647] R10: 0000000000000000 R11: 0000000000000246 R12: ffff81007eb785c0
[ 125.653649] R13: 0000000000000001 R14: 0000000000000100 R15: 0000000000000000
[ 125.653653] FS: 0000000000587850(0000) GS:ffffffff805c6800(0000) knlGS:0000000000000000
[ 125.653655] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 125.653658] CR2: 000000000040a9b0 CR3: 0000000000101000 CR4: 00000000000006e0
[ 125.653661] Process hotplug (pid: 746, threadinfo ffff81007ebce000, task ffff81007ebcafa0)
[ 125.653663] Stack: 000000000000003c ffff810002c0e3e0 ffff81007eb785c0 ffff81007eb78638
[ 125.653668] ffff81007ebcafa0 ffffffff80130d61 0000000000000100 0000000000000100
[ 125.653672] ffff81007ebcb5e4 ffffffff80135bb2
[ 125.653675] Call Trace:<ffffffff80130d61>{mmput+49} <ffffffff80135bb2>{do_exit+578}
[ 125.653682] <ffffffff8024f961>{__up_write+49} <ffffffff801366b8>{do_group_exit+248}
[ 125.653687] <ffffffff8010dcee>{system_call+126}
[ 125.653691]
[ 125.653692] Code: 0f 0b 68 de 7e 3e 80 c2 a4 07 48 83 c4 10 5b 5d 41 5c c3 66
[ 125.653700] RIP <ffffffff8016cecb>{exit_mmap+235} RSP <ffff81007ebcfeb8>
[ 125.653704] <1>Fixing recursive fault but reboot is needed!
[ 125.653841] ----------- [cut here ] --------- [please bite here ] ---------
[ 125.653843] Kernel BUG at mm/mmap.c:1956
--
Stephen Hemminger <[email protected]>
OSDL http://developer.osdl.org/~shemminger
From: Stephen Frost <[email protected]>
Date: Tue, 29 Nov 2005 11:49:46 -0500
> I'm pretty curious about it too, none of my debian-based boxes have
> 'gdb' anywhere in /etc/init.d. The only thing I see is that the shell
> script /usr/bin/mozilla-firefox calls gdb when passed '--debugger', or
> when the DEBUG environment variable is set... Perhaps he's doing that
> during his .xsession?
There are a bunch of programs out there which fork and fire up
gdb and attach it to themselves if they take a SIGSEGV or
SIGBUS. Printing out the parent process of the gdb will
likely reveal the exact case.
Stephen Hemminger <[email protected]> wrote:
>
> [ 125.653485] <1>Fixing recursive fault but reboot is needed!
> [ 125.653620] ----------- [cut here ] --------- [please bite here ] ---------
> [ 125.653622] Kernel BUG at mm/mmap.c:1956
> [ 125.653624] invalid operand: 0000 [727] SMP
> [ 125.653625] CPU 0
> [ 125.653627] Modules linked in:
> [ 125.653629] Pid: 746, comm: hotplug Not tainted 2.6.15-rc3 #1
> [ 125.653631] RIP: 0010:[<ffffffff8016cecb>] <ffffffff8016cecb>{exit_mmap+235}
> [ 125.653636] RSP: 0018:ffff81007ebcfeb8 EFLAGS: 00010202
> [ 125.653639] RAX: 0000000000000000 RBX: ffff810002c0e3e0 RCX: 00000000000005b4
> [ 125.653642] RDX: 000000000000000f RSI: ffff81007fc2ead8 RDI: ffff81007ff5ca80
> [ 125.653645] RBP: 0000000000000000 R08: ffff81007ff2c920 R09: 0000000000000000
> [ 125.653647] R10: 0000000000000000 R11: 0000000000000246 R12: ffff81007eb785c0
> [ 125.653649] R13: 0000000000000001 R14: 0000000000000100 R15: 0000000000000000
> [ 125.653653] FS: 0000000000587850(0000) GS:ffffffff805c6800(0000) knlGS:0000000000000000
> [ 125.653655] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 125.653658] CR2: 000000000040a9b0 CR3: 0000000000101000 CR4: 00000000000006e0
> [ 125.653661] Process hotplug (pid: 746, threadinfo ffff81007ebce000, task ffff81007ebcafa0)
> [ 125.653663] Stack: 000000000000003c ffff810002c0e3e0 ffff81007eb785c0 ffff81007eb78638
> [ 125.653668] ffff81007ebcafa0 ffffffff80130d61 0000000000000100 0000000000000100
> [ 125.653672] ffff81007ebcb5e4 ffffffff80135bb2
> [ 125.653675] Call Trace:<ffffffff80130d61>{mmput+49} <ffffffff80135bb2>{do_exit+578}
> [ 125.653682] <ffffffff8024f961>{__up_write+49} <ffffffff801366b8>{do_group_exit+248}
> [ 125.653687] <ffffffff8010dcee>{system_call+126}
> [ 125.653691]
> [ 125.653692] Code: 0f 0b 68 de 7e 3e 80 c2 a4 07 48 83 c4 10 5b 5d 41 5c c3 66
> [ 125.653700] RIP <ffffffff8016cecb>{exit_mmap+235} RSP <ffff81007ebcfeb8>
> [ 125.653704] <1>Fixing recursive fault but reboot is needed!
> [ 125.653841] ----------- [cut here ] --------- [please bite here ] ---------
> [ 125.653843] Kernel BUG at mm/mmap.c:1956
That's
BUG_ON(mm->nr_ptes > (FIRST_USER_ADDRESS+PMD_SIZE-1)>>PMD_SHIFT);
It's hard to see how this is caused by a USB patch.
Are you using the very latest Linus tree? You should...
This might help, dunno.
diff -puN mm/memory.c~mm-get_locked_pte-fix mm/memory.c
--- 25/mm/memory.c~mm-get_locked_pte-fix 2005-11-29 16:05:05.000000000 -0800
+++ 25-akpm/mm/memory.c 2005-11-29 16:05:24.000000000 -0800
@@ -1151,7 +1151,7 @@ pte_t *get_locked_pte(struct mm_struct *
pgd_t * pgd = pgd_offset(mm, addr);
pud_t * pud = pud_alloc(mm, pgd, addr);
if (pud) {
- pmd_t * pmd = pmd_alloc(mm, pgd, addr);
+ pmd_t * pmd = pmd_alloc(mm, pud, addr);
if (pmd)
return pte_alloc_map_lock(mm, pmd, addr, ptl);
}
_
On Tue, 29 Nov 2005 16:25:19 -0800
Andrew Morton <[email protected]> wrote:
> Stephen Hemminger <[email protected]> wrote:
> >
> > [ 125.653485] <1>Fixing recursive fault but reboot is needed!
> > [ 125.653620] ----------- [cut here ] --------- [please bite here ] ---------
> > [ 125.653622] Kernel BUG at mm/mmap.c:1956
> > [ 125.653624] invalid operand: 0000 [727] SMP
> > [ 125.653625] CPU 0
> > [ 125.653627] Modules linked in:
> > [ 125.653629] Pid: 746, comm: hotplug Not tainted 2.6.15-rc3 #1
> > [ 125.653631] RIP: 0010:[<ffffffff8016cecb>] <ffffffff8016cecb>{exit_mmap+235}
> > [ 125.653636] RSP: 0018:ffff81007ebcfeb8 EFLAGS: 00010202
> > [ 125.653639] RAX: 0000000000000000 RBX: ffff810002c0e3e0 RCX: 00000000000005b4
> > [ 125.653642] RDX: 000000000000000f RSI: ffff81007fc2ead8 RDI: ffff81007ff5ca80
> > [ 125.653645] RBP: 0000000000000000 R08: ffff81007ff2c920 R09: 0000000000000000
> > [ 125.653647] R10: 0000000000000000 R11: 0000000000000246 R12: ffff81007eb785c0
> > [ 125.653649] R13: 0000000000000001 R14: 0000000000000100 R15: 0000000000000000
> > [ 125.653653] FS: 0000000000587850(0000) GS:ffffffff805c6800(0000) knlGS:0000000000000000
> > [ 125.653655] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 125.653658] CR2: 000000000040a9b0 CR3: 0000000000101000 CR4: 00000000000006e0
> > [ 125.653661] Process hotplug (pid: 746, threadinfo ffff81007ebce000, task ffff81007ebcafa0)
> > [ 125.653663] Stack: 000000000000003c ffff810002c0e3e0 ffff81007eb785c0 ffff81007eb78638
> > [ 125.653668] ffff81007ebcafa0 ffffffff80130d61 0000000000000100 0000000000000100
> > [ 125.653672] ffff81007ebcb5e4 ffffffff80135bb2
> > [ 125.653675] Call Trace:<ffffffff80130d61>{mmput+49} <ffffffff80135bb2>{do_exit+578}
> > [ 125.653682] <ffffffff8024f961>{__up_write+49} <ffffffff801366b8>{do_group_exit+248}
> > [ 125.653687] <ffffffff8010dcee>{system_call+126}
> > [ 125.653691]
> > [ 125.653692] Code: 0f 0b 68 de 7e 3e 80 c2 a4 07 48 83 c4 10 5b 5d 41 5c c3 66
> > [ 125.653700] RIP <ffffffff8016cecb>{exit_mmap+235} RSP <ffff81007ebcfeb8>
> > [ 125.653704] <1>Fixing recursive fault but reboot is needed!
> > [ 125.653841] ----------- [cut here ] --------- [please bite here ] ---------
> > [ 125.653843] Kernel BUG at mm/mmap.c:1956
>
> That's
>
> BUG_ON(mm->nr_ptes > (FIRST_USER_ADDRESS+PMD_SIZE-1)>>PMD_SHIFT);
>
> It's hard to see how this is caused by a USB patch.
>
> Are you using the very latest Linus tree? You should...
Yes, when I retested with the usb patch it was against a fresh git pull.
So it probably isn't a USB problem but something that got introduced between
the two (2.6.15-rc3 vs latest).
I'll go back to the 2.6.15-rc3 tree and test usb fix.
--
Stephen Hemminger <[email protected]>
OSDL http://developer.osdl.org/~shemminger
> From: David Brownell <[email protected]>
> Subject: USB: ehci fixups
>
> Rename the EHCI "reset" routine so it better matches what it does (setup);
> and move the one-time data structure setup earlier, before doing anything
> that implicitly relies on it having been completed already.
>
> From: David Brownell <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
Yes, that fixed the usb problem with 2.6.15-rc3. Boots and
USB serial works okay.
The problem with git latest still exists.
--
Stephen Hemminger <[email protected]>
OSDL http://developer.osdl.org/~shemminger
"Rafael J. Wysocki" <[email protected]> writes:
> On Tuesday, 29 of November 2005 05:11, Linus Torvalds wrote:
> >
> > I just pushed 2.6.15-rc3 out there, and here are both the shortlog and
> > diffstats appended.
>
> Hangs solid on boot on dual-core Athlon64. No details yet, but I'm working
> on them. I wonder if anyone else is seeing this.
I also see a hang in EHCI on my single A64 VIA box, but curiously
it goes away with pci=noacpi (but that might just cover it - i
had a buggy USB storage device in the front usb ports and
I think with noacpi it just doesn't route them correctly)
Didn't investigate closer so far.
-Andi
On Tue, 29 Nov 2005, Stephen Hemminger wrote:
>
> Yes, when I retested with the usb patch it was against a fresh git pull.
> So it probably isn't a USB problem but something that got introduced between
> the two (2.6.15-rc3 vs latest).
>
> I'll go back to the 2.6.15-rc3 tree and test usb fix.
Can you check the current -git tree ( + the usb fix, which has _not_ made
it there yet). I think it was probably the stupid thinko that just didn't
trigger for me on ppc64 since it only breaks with 4-level page tables.
Linus
Linus Torvalds writes:
> Can you check the current -git tree ( + the usb fix, which has _not_ made
> it there yet). I think it was probably the stupid thinko that just didn't
> trigger for me on ppc64 since it only breaks with 4-level page tables.
Unless you have selected 64k pages (I assume not), ppc64 does use
4-level page tables.
Paul.
On Tue, 29 Nov 2005 17:57:00 -0800 (PST)
Linus Torvalds <[email protected]> wrote:
>
>
> On Tue, 29 Nov 2005, Stephen Hemminger wrote:
> >
> > Yes, when I retested with the usb patch it was against a fresh git pull.
> > So it probably isn't a USB problem but something that got introduced between
> > the two (2.6.15-rc3 vs latest).
> >
> > I'll go back to the 2.6.15-rc3 tree and test usb fix.
>
> Can you check the current -git tree ( + the usb fix, which has _not_ made
> it there yet). I think it was probably the stupid thinko that just didn't
> trigger for me on ppc64 since it only breaks with 4-level page tables.
>
> Linus
Okay, with updated -git tree + usb fix, that system boots and runs
again. Looks like time for -rc3.1
On Tue, 29 Nov 2005, Stephen Hemminger wrote:
>
> Okay, with updated -git tree + usb fix, that system boots and runs
> again. Looks like time for -rc3.1
I'll do an -rc4, but I'll wait for Greg to forward the patch properly.
There migth be other issues pending.
Linus
On Tue, Nov 29, 2005 at 07:16:32PM -0800, Linus Torvalds wrote:
>
>
> On Tue, 29 Nov 2005, Stephen Hemminger wrote:
> >
> > Okay, with updated -git tree + usb fix, that system boots and runs
> > again. Looks like time for -rc3.1
>
> I'll do an -rc4, but I'll wait for Greg to forward the patch properly.
> There migth be other issues pending.
I have a few patches I need to send to you for -rc3, will do so in a few
hours.
thanks,
greg k-h
Chris Shoemaker wrote:
>On Tue, Nov 29, 2005 at 08:38:48AM -0800, Linus Torvalds wrote:
>
>
>>On Tue, 29 Nov 2005, Michael Krufky wrote:
>>
>>
>>>In other words, the OOPS is the last thing to show on the screen in text mode,
>>>before the console switches into X, using debian sarge's default bootup
>>>process.
>>>
>>>
>>Ok. Whatever it is, I'm happy it is doing that, since it caused us to see
>>the oops quickly. None of _my_ boxes do that, obviously (and I tested on
>>x86, x86-64 and ppc64 exactly to get reasonable coverage of what different
>>architectures might do - but none of the boxes are debian-based).
>>
>>>I have no idea why gdb is running.... hmm... Anyhow, I'm away from that
>>>machine right now, and it is powered off, so I can't look directly at the
>>>startup scripts right now. Would you like me to send more info later on when
>>>I get home? If so, what would you like to see?
>>>
>>>
>>It's not important, I was just curious about what strange things people
>>have in their bootup scripts. If you can just grep through the rc.d files
>>to see what uses gdb, I'd just like to know...
>>
>>
>I doubt gdb is in rc.d scripts. My wild uninformed guess would be
>that some process (maybe xinit?) hit a SEGV and had its own signal
>handler installed that tried to call gdb and attach to the crashing
>process. I could imagine something like that being useful for
>generating nice userspace stack traces to send to the developers. I
>think I've seen something similar in some builds.
>
I think Chris is right. There is no gdb in the scripts at all. It
makes sense for these debug capabilities to be present in Debian
Sarge/Testing.
Nothing in my scripts look out-of-the-ordinary.
-Mike
Linus Torvalds wrote:
>On Tue, 29 Nov 2005, Helge Hafting wrote:
>
>
>>Can't open root dev "831" or unknown block(8,49)
>>Please append a correct root= boot option
>>unable to mount root fs from block(8,49)
>>
>>
>
>Sounds like your SATA drive wasn't detected.
>
>Please double-check that your config changes didn't disable it, but
>otherwise:
>
>
>
>>Now 2.6.14 works with exactly the same lilo.con,
>>where I have root=/dev/sdd1 (SATA drive)
>>
>>
>
>please specify _which_ SATA driver you are using so that Jeff & co can try
>to figure out what broke since 2.6.14.
>
>
>
lspci says:
0000:00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA
RAID Controller (rev 80)
My .config has "VIA SATA support" selected under "SCSI low-level drivers"
>Also, if you can pinpoint where it broke better, that probably helps
>(most sata changes were in -rc1, but there were some sata_mv and sata_sil4
>changes in in -rc2 too, so even just poinpointing it to either of those
>will help, although the daily builds might be even better).
>
>
I tried compiling and booting rc1. The machine is remote, and did not
come up. So I don't know why it didn't come up, but it is likely
that it is the same problem.
Helge Hafting
Helge Hafting wrote:
> I tried compiling and booting rc1. The machine is remote, and did not
> come up. So I don't know why it didn't come up, but it is likely
> that it is the same problem.
Any chance at all to get netconsole or serial console output, after
turning on ATA_DEBUG and ATA_VERBOSE_DEBUG in include/linux/libata.h ?
Jeff
Jeff Garzik wrote:
> Helge Hafting wrote:
>
>> I tried compiling and booting rc1. The machine is remote, and did not
>> come up. So I don't know why it didn't come up, but it is likely
>> that it is the same problem.
>
>
> Any chance at all to get netconsole or serial console output, after
> turning on ATA_DEBUG and ATA_VERBOSE_DEBUG in include/linux/libata.h ?
Tricky - no other machines around for serial. Maybe I can look into
netconsole, and see if it'll work over an internet connection.
The first try will be turning on that debug stuff and writing down what
happens.
The machine have the following block devices:
* floppy drive
* IDE dvd writer
* 3 SCSI disks on a scsi controller
* 2 SATA disks on the mainboard sata
* USB card reader with 4 SCSI LUNs.
Dmesg stuff from a normal 2.6.14 startup, in case it may be of help:
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1
Probing IDE interface ide0...
hda: PLEXTOR DVDR PX-712A, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Losing some ticks... checking if CPU frequency changed.
hda: ATAPI 40X DVD-ROM DVD-R CD-R/RW drive, 8192kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
ACPI: PCI Interrupt 0000:00:05.0[A] -> GSI 16 (level, low) -> IRQ 16
sym0: <895> rev 0x1 at pci 0000:00:05.0 irq 16
sym0: Tekram NVRAM, ID 7, Fast-40, LVD, parity checking
sym0: SCSI BUS has been reset.
scsi0 : sym-2.2.1
Vendor: FUJITSU Model: MAS3184NP Rev: 0104
Type: Direct-Access ANSI SCSI revision: 03
target0:0:0: tagged command queuing enabled, command queue depth 4.
target0:0:0: Beginning Domain Validation
target0:0:0: asynchronous.
target0:0:0: wide asynchronous.
target0:0:0: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
target0:0:0: Ending Domain Validation
target0:0:1: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
Vendor: IBM Model: DDYS-T09170N Rev: S96H
Type: Direct-Access ANSI SCSI revision: 03
target0:0:1: tagged command queuing enabled, command queue depth 4.
target0:0:1: Beginning Domain Validation
target0:0:1: asynchronous.
target0:0:1: wide asynchronous.
target0:0:1: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
target0:0:1: Ending Domain Validation
Vendor: IBM Model: IC35L018UWD210-0 Rev: S5BS
Type: Direct-Access ANSI SCSI revision: 03
target0:0:6: tagged command queuing enabled, command queue depth 4.
target0:0:6: Beginning Domain Validation
target0:0:6: asynchronous.
target0:0:6: wide asynchronous.
target0:0:6: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
target0:0:6: Ending Domain Validation
libata version 1.12 loaded.
sata_via version 1.1
ACPI: PCI Interrupt 0000:00:0f.0[B] -> Link [ALKA] -> GSI 20 (level,
low) -> IRQACPI: PCI Interrupt 0000:00:0f.0[B] -> Link [ALKA] -> GSI 20
(level, low) -> IRQ 17
PCI: Via IRQ fixup for 0000:00:0f.0, from 10 to 1
sata_via(0000:00:0f.0): routed to hard irq line 1
ata1: SATA max UDMA/133 cmd 0x9C00 ctl 0xA002 bmdma 0xAC00 irq 17
ata2: SATA max UDMA/133 cmd 0xA400 ctl 0xA802 bmdma 0xAC08 irq 17
ata1: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4063 85:7c69 86:3e01 87:4063
88:407f
ata1: dev 0 ATA, max UDMA/133, 398297088 sectors: lba48
ata1: dev 0 configured for UDMA/133
scsi1 : sata_via
ata2: dev 0 cfg 49:2f00 82:346b 83:7f61 84:4003 85:3469 86:3c41 87:4003
88:407f
ata2: dev 0 ATA, max UDMA/133, 390721968 sectors: lba48
ata2: dev 0 configured for UDMA/133
scsi2 : sata_via
Vendor: ATA Model: Maxtor 6B200M0 Rev: BANC
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: WDC WD2000JD-00H Rev: 08.0
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 35890512 512-byte hdwr sectors (18376 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 35890512 512-byte hdwr sectors (18376 MB)
SCSI device sda: drive cache: write back
sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 >
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sdb: 17916240 512-byte hdwr sectors (9173 MB)
SCSI device sdb: drive cache: write back
SCSI device sdb: 17916240 512-byte hdwr sectors (9173 MB)
SCSI device sdb: drive cache: write back
sdb: sdb1 sdb2 < sdb5 sdb6 >
Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0
SCSI device sdc: 35843670 512-byte hdwr sectors (18352 MB)
SCSI device sdc: drive cache: write back
SCSI device sdc: 35843670 512-byte hdwr sectors (18352 MB)
SCSI device sdc: drive cache: write back
sdc: sdc1 sdc2 sdc3
Attached scsi disk sdc at scsi0, channel 0, id 6, lun 0
SCSI device sdd: 398297088 512-byte hdwr sectors (203928 MB)
SCSI device sdd: drive cache: write back
SCSI device sdd: 398297088 512-byte hdwr sectors (203928 MB)
SCSI device sdd: drive cache: write back
sdd: sdd1 sdd2
Attached scsi disk sdd at scsi1, channel 0, id 0, lun 0
SCSI device sde: 390721968 512-byte hdwr sectors (200050 MB)
SCSI device sde: drive cache: write back
SCSI device sde: 390721968 512-byte hdwr sectors (200050 MB)
SCSI device sde: drive cache: write back
sde: sde1 sde2
Attached scsi disk sde at scsi2, channel 0, id 0, lun 0
Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0
Attached scsi generic sg1 at scsi0, channel 0, id 1, lun 0, type 0
Attached scsi generic sg2 at scsi0, channel 0, id 6, lun 0, type 0
Attached scsi generic sg3 at scsi1, channel 0, id 0, lun 0, type 0
Attached scsi generic sg4 at scsi2, channel 0, id 0, lun 0, type 0
[...]
Initializing USB Mass Storage driver...
scsi3 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 3
usb-storage: waiting for device to settle before scanning
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
[...]
Vendor: USB2.0 Model: HS-CF Rev: 1.64
Type: Direct-Access ANSI SCSI revision: 00
Attached scsi removable disk sdf at scsi3, channel 0, id 0, lun 0
Attached scsi generic sg5 at scsi3, channel 0, id 0, lun 0, type 0
Vendor: USB2.0 Model: HS-MS Rev: 1.64
Type: Direct-Access ANSI SCSI revision: 00
Attached scsi removable disk sdg at scsi3, channel 0, id 0, lun 1
Attached scsi generic sg6 at scsi3, channel 0, id 0, lun 1, type 0
Vendor: USB2.0 Model: HS-SM Rev: 1.64
Type: Direct-Access ANSI SCSI revision: 00
Attached scsi removable disk sdh at scsi3, channel 0, id 0, lun 2
Attached scsi generic sg7 at scsi3, channel 0, id 0, lun 2, type 0
Vendor: USB2.0 Model: HS-SD/MMC Rev: 1.64
Type: Direct-Access ANSI SCSI revision: 00
Attached scsi removable disk sdi at scsi3, channel 0, id 0, lun 3
Attached scsi generic sg8 at scsi3, channel 0, id 0, lun 3, type 0
usb-storage: device scan complete
Helge Hafting
Helge Hafting wrote:
> Jeff Garzik wrote:
>
>> Helge Hafting wrote:
>>
>>> I tried compiling and booting rc1. The machine is remote, and did not
>>> come up. So I don't know why it didn't come up, but it is likely
>>> that it is the same problem.
>>
>>
>>
>> Any chance at all to get netconsole or serial console output, after
>> turning on ATA_DEBUG and ATA_VERBOSE_DEBUG in include/linux/libata.h ?
>
>
> Tricky - no other machines around for serial. Maybe I can look into
> netconsole, and see if it'll work over an internet connection.
>
> The first try will be turning on that debug stuff and writing down what
> happens.
>
> The machine have the following block devices:
> * floppy drive
> * IDE dvd writer
> * 3 SCSI disks on a scsi controller
> * 2 SATA disks on the mainboard sata
> * USB card reader with 4 SCSI LUNs.
>
> Dmesg stuff from a normal 2.6.14 startup, in case it may be of help:
> VP_IDE: chipset revision 6
> VP_IDE: not 100% native mode: will probe irqs later
> VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1
> Probing IDE interface ide0...
> hda: PLEXTOR DVDR PX-712A, ATAPI CD/DVD-ROM drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> Losing some ticks... checking if CPU frequency changed.
> hda: ATAPI 40X DVD-ROM DVD-R CD-R/RW drive, 8192kB Cache, UDMA(33)
> Uniform CD-ROM driver Revision: 3.20
> ACPI: PCI Interrupt 0000:00:05.0[A] -> GSI 16 (level, low) -> IRQ 16
> sym0: <895> rev 0x1 at pci 0000:00:05.0 irq 16
> sym0: Tekram NVRAM, ID 7, Fast-40, LVD, parity checking
> sym0: SCSI BUS has been reset.
> scsi0 : sym-2.2.1
> Vendor: FUJITSU Model: MAS3184NP Rev: 0104
> Type: Direct-Access ANSI SCSI revision: 03
> target0:0:0: tagged command queuing enabled, command queue depth 4.
> target0:0:0: Beginning Domain Validation
> target0:0:0: asynchronous.
> target0:0:0: wide asynchronous.
> target0:0:0: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
> target0:0:0: Ending Domain Validation
> target0:0:1: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
> Vendor: IBM Model: DDYS-T09170N Rev: S96H
> Type: Direct-Access ANSI SCSI revision: 03
> target0:0:1: tagged command queuing enabled, command queue depth 4.
> target0:0:1: Beginning Domain Validation
> target0:0:1: asynchronous.
> target0:0:1: wide asynchronous.
> target0:0:1: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
> target0:0:1: Ending Domain Validation
> Vendor: IBM Model: IC35L018UWD210-0 Rev: S5BS
> Type: Direct-Access ANSI SCSI revision: 03
> target0:0:6: tagged command queuing enabled, command queue depth 4.
> target0:0:6: Beginning Domain Validation
> target0:0:6: asynchronous.
> target0:0:6: wide asynchronous.
> target0:0:6: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
> target0:0:6: Ending Domain Validation
> libata version 1.12 loaded.
> sata_via version 1.1
> ACPI: PCI Interrupt 0000:00:0f.0[B] -> Link [ALKA] -> GSI 20 (level,
> low) -> IRQACPI: PCI Interrupt 0000:00:0f.0[B] -> Link [ALKA] -> GSI 20
> (level, low) -> IRQ 17
> PCI: Via IRQ fixup for 0000:00:0f.0, from 10 to 1
> sata_via(0000:00:0f.0): routed to hard irq line 1
The VIA irq fixup keeps changing, I wonder if this is a cause...
Jeff
On Thu, Dec 01, 2005 at 03:16:16AM -0500, Jeff Garzik wrote:
> Helge Hafting wrote:
> >I tried compiling and booting rc1. The machine is remote, and did not
> >come up. So I don't know why it didn't come up, but it is likely
> >that it is the same problem.
>
> Any chance at all to get netconsole or serial console output, after
> turning on ATA_DEBUG and ATA_VERBOSE_DEBUG in include/linux/libata.h ?
There is nothing wrong with the SATA driver - I am posting from
2.6.15-rc1 now.
The problem is that the scsi order changed.
With 2.6.14 and earlier, I got:
sda, sdb, sdc : harddisks connected to sym2 pci host adapter
sdd, sde : harddisks connected to mainboard SATA
sdf,sdg,sdh,sdi : the slots in my USB card reader
With 2.6.15-rc1 and later, I get:
sda,sdb,sdc,sdd: the slots in my USB card reader
sde, sdf, sdg: harddisks connected to the sym2 pci host adapter
sdh, sdi : harddisks connected to mainboard SATA
This kernel have all drivers compiled in - no modules.
So I have to ask - is this change (USB devices before
any other scsi disks) _intentional_ ?
I can of course change my fstab, but I can imagine this causing all
sorts of trouble for people who plug in the occational USB pendrive.
Now it will shift all other scsi devices. That didn't happen before.
Therefore, I hope this change of scsi order will be reverted. USB should
be last, because USB drives are the most likely to be transient.
While SATA and SCSI host adapters are the ones most likely to contain
root file systems. I will happily test any patches attempting to restore
the old behaviour.
I guess mounting by UUID is another way of fixing this? Please tell if
this change is intentional - it will making mounting scsi disks by device sort
of useless for anyone with USB though :-/
Helge Hafting
On Sun, 4 Dec 2005, Helge Hafting wrote:
>
> With 2.6.15-rc1 and later, I get:
> sda,sdb,sdc,sdd: the slots in my USB card reader
> sde, sdf, sdg: harddisks connected to the sym2 pci host adapter
> sdh, sdi : harddisks connected to mainboard SATA
>
> This kernel have all drivers compiled in - no modules.
>
> So I have to ask - is this change (USB devices before
> any other scsi disks) _intentional_ ?
No. Not only isn't it intentional, it's definitely a bug.
We've had it before. The USB devices should come last.
Now, in general, we can't _guarantee_ ordering, since with modules and
lots of asynchronous events (USB is basically hotplug, we might "detect" a
disk at any time), so at best it's always just going to be very much a
"preferred ordering", but so far we've actually in _practice_ been able to
be very good at keeping the preferred ordering pretty stable.
> I guess mounting by UUID is another way of fixing this? Please tell if
> this change is intentional - it will making mounting scsi disks by device sort
> of useless for anyone with USB though :-/
Can you figure out exactly (or at least slightly more closely) where it
happened? It might be something silly like link ordering changes (like the
fact that drivers/block core files got moved to block/ - although I did
actually try to check that the link order stayed the same there, since
it was such an obvious thing), or it might be more subtle. But even just
pinpointing it to one particular nightly snapshot would be good (and using
"git bisect" to pinpoint it even more closely is obviously even better).
There's a fair number of changes wrt things like platform_device in
the -rc1 series. But I actually wonder if it's that simple Makefile
change.
Does this trivial patch fix it for you? It just makes sure that the usb/
subdirectory gets added to the list of driver subdirectories at the right
point ...
(Link order matters for the "initcall()" ordering, even if it doesn't
matter for anything else)
Linus
----
diff --git a/drivers/Makefile b/drivers/Makefile
index fac1e16..ea410b6 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -5,7 +5,7 @@
# Rewritten to use lists instead of if-statements.
#
-obj-$(CONFIG_PCI) += pci/ usb/
+obj-$(CONFIG_PCI) += pci/
obj-$(CONFIG_PARISC) += parisc/
obj-$(CONFIG_RAPIDIO) += rapidio/
obj-y += video/
@@ -49,6 +49,7 @@ obj-$(CONFIG_ATA_OVER_ETH) += block/aoe/
obj-$(CONFIG_PARIDE) += block/paride/
obj-$(CONFIG_TC) += tc/
obj-$(CONFIG_USB) += usb/
+obj-$(CONFIG_PCI) += usb/
obj-$(CONFIG_USB_GADGET) += usb/gadget/
obj-$(CONFIG_GAMEPORT) += input/gameport/
obj-$(CONFIG_INPUT) += input/
On Sat, 3 Dec 2005, Linus Torvalds wrote:
> diff --git a/drivers/Makefile b/drivers/Makefile
> index fac1e16..ea410b6 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -5,7 +5,7 @@
> # Rewritten to use lists instead of if-statements.
> #
>
> -obj-$(CONFIG_PCI) += pci/ usb/
> +obj-$(CONFIG_PCI) += pci/
> obj-$(CONFIG_PARISC) += parisc/
> obj-$(CONFIG_RAPIDIO) += rapidio/
> obj-y += video/
> @@ -49,6 +49,7 @@ obj-$(CONFIG_ATA_OVER_ETH) += block/aoe/
> obj-$(CONFIG_PARIDE) += block/paride/
> obj-$(CONFIG_TC) += tc/
> obj-$(CONFIG_USB) += usb/
> +obj-$(CONFIG_PCI) += usb/
> obj-$(CONFIG_USB_GADGET) += usb/gadget/
> obj-$(CONFIG_GAMEPORT) += input/gameport/
> obj-$(CONFIG_INPUT) += input/
Yes that fixed it, but why walk into usb/ on CONFIG_PCI?
On Sun, Dec 04, 2005 at 01:34:18AM -0800, Zwane Mwaikambo wrote:
> On Sat, 3 Dec 2005, Linus Torvalds wrote:
>
> > diff --git a/drivers/Makefile b/drivers/Makefile
> > index fac1e16..ea410b6 100644
> > --- a/drivers/Makefile
> > +++ b/drivers/Makefile
> > @@ -5,7 +5,7 @@
> > # Rewritten to use lists instead of if-statements.
> > #
> >
> > -obj-$(CONFIG_PCI) += pci/ usb/
> > +obj-$(CONFIG_PCI) += pci/
> > obj-$(CONFIG_PARISC) += parisc/
> > obj-$(CONFIG_RAPIDIO) += rapidio/
> > obj-y += video/
> > @@ -49,6 +49,7 @@ obj-$(CONFIG_ATA_OVER_ETH) += block/aoe/
> > obj-$(CONFIG_PARIDE) += block/paride/
> > obj-$(CONFIG_TC) += tc/
> > obj-$(CONFIG_USB) += usb/
> > +obj-$(CONFIG_PCI) += usb/
> > obj-$(CONFIG_USB_GADGET) += usb/gadget/
> > obj-$(CONFIG_GAMEPORT) += input/gameport/
> > obj-$(CONFIG_INPUT) += input/
>
> Yes that fixed it, but why walk into usb/ on CONFIG_PCI?
Because of drivers/usb/host/pci-quirks.c .
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
On Sun, Dec 04, 2005 at 01:34:18AM -0800, Zwane Mwaikambo wrote:
> On Sat, 3 Dec 2005, Linus Torvalds wrote:
>
> Yes that fixed it, but why walk into usb/ on CONFIG_PCI?
The patch worked for me also, and 2.6.15-rc5 is ok too. :-)
Helge Hafting