All of lore.kernel.org
 help / color / mirror / Atom feed
* Linux 2.6.21-rc5
@ 2007-03-25 23:08 Linus Torvalds
  2007-03-26  8:31 ` Ingo Molnar
                   ` (19 more replies)
  0 siblings, 20 replies; 128+ messages in thread
From: Linus Torvalds @ 2007-03-25 23:08 UTC (permalink / raw)
  To: Linux Kernel Mailing List

[-- Attachment #1: Type: TEXT/PLAIN, Size: 16724 bytes --]


There's various fixes here, ranging from some architecture updates (ia64, 
ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.

And random one-liners.

But probably more important, and likely much more visible to most people 
is the fixes for the fallout from the hrtimers and no-HZ changes, and some 
of the ACPI regressions.

Those timer changes ended up much more painful than anybody wished for, 
but big thanks to Thomas Gleixner for being on it like a weasel on a dead 
rat, and the regression list has kept shrinking.

So if you have reported a regression in the 2.6.21-rc series, please check 
2.6.21-rc5, and update your report as appropriate (whether fixed or "still 
problems with xyzzy").

		Linus

---
Adrian Bunk (3):
      X86_P4_CLOCKMOD must select CPU_FREQ_TABLE
      [X25] x25_forward_call(): fix NULL dereferences
      drivers/video/s3fb.c: fix a use-before-check

Akira Iguchi (1):
      drivers/ata/Kconfig: PATA_SCC depends on wrong platform

Alan Stern (1):
      usblp: quirk flag and device entry for Seiko Epson M129C printer

Alan Tyson (1):
      [CIFS] reset mode when client notices that ATTR_READONLY is no longer set

Alessandro Zummo (1):
      pata_ixp4xx_cf: fix interrupt

Alexandr Andreev (1):
      x86-64: wire up compat sched_rr_get_interval(2)

Alexey Dobriyan (1):
      [NET]: Copy mac_len in skb_clone() as well

Alexey Starikovskiy (1):
      ACPI: resolve HP nx6125 S3 immediate wakeup regression

Andi Kleen (4):
      x86-64: Update defconfig
      i386: Update defconfig
      i386: Enforce GPLness of VMI ROM
      x86: Export _proxy_pda for gcc 4.2

Andrew Johnson (1):
      swsusp: fix suspend when console is in VT_AUTO+KD_GRAPHICS mode

Andrew Morton (2):
      machzwd warning fix
      "ext[34]: EA block reference count racing fix" performance fix

Andy Isaacson (1):
      fix read past end of array in md/linear.c

Ankita Garg (1):
      oom fix: prevent oom from killing a process with children/sibling unkillable

Anton Blanchard (2):
      [POWERPC] Bypass hcall stats until cpu features have run
      Fix return code in pci-skeleton.c

Antonino A. Daplas (2):
      savagefb: Fix black screen on load in Savage IX
      savagefb: Fix compile error if debugging is enabled

Arnaud Patard (1):
      spi_s3c24xx.c: warning fix

Atsushi Nemoto (5):
      [MIPS] Check FCSR for pending interrupts, alternative version
      [MIPS] FPU ownership management & preemption fixes
      SPI: at25: do not use pointer before assignment
      [MIPS] Qemu: Fix Symmetric Uniprocessor support.
      [MIPS] SPARSEMEM: The first pfn of zone should be min_low_pfn, not 0.

Avi Kivity (4):
      KVM: Unset kvm_arch_ops if arch module loading failed
      KVM: Fix guest sysenter on vmx
      KVM: MMU: Fix guest writes to nonpae pde
      KVM: MMU: Fix host memory corruption on i386 with >= 4GB ram

Bartlomiej Zolnierkiewicz (2):
      ide: don't allow DMA to be enabled if CONFIG_IDEDMA_{ICS,PCI}_AUTO=n
      ide: remove CONFIG_IDEDMA_{ICS,PCI}_AUTO config options

Bernhard Walle (3):
      Initialise SAK member for each virtual console to prevent oops
      Fix wrong /proc/iomem on SGI Altix
      [IA64] Fix wrong /proc/iomem on SGI Altix

Brice Goglin (4):
      myri10ge: Serverworks HT2100 provides aligned PCIe completion
      myri10ge: update wcfifo and intr_coal_delay default values
      myri10ge: fix management of >4kB allocated pages
      myri10ge: update driver version to 1.3.0-1.226

Bryan O'Sullivan (1):
      IB/ipath: Check return value of lookup_one_len

Chris Lesiak (1):
      spi: destroy workqueue after spi_unregister_master

Cyrill V. Gorcunov (1):
      i2c/ds1374: Check workqueue creation status

Dale Farnsworth (1):
      mv643xx_eth: add mv643xx_eth_shutdown function

Dan Williams (1):
      [ARM] 4271/1: iop32x: fix ep80219 detection (support iq80219 platforms)

Daniel Mack (1):
      ide: remove static prototypes from include/asm-mips/mach-au1x00/au1xxx_ide.h

Danny Kukawka (1):
      add Fujitsu Siemens Tablet PC devices to 8250_pnp.c

Dave Jones (1):
      [NET]: fix up misplaced inlines.

David Brownell (4):
      reduce pnp syslog spam
      rm pointless dmaengine exports
      gpio_direction_output() needs an initial value
      gpio_direction_output-needs-an-initial-value fix

David Howells (4):
      FRV: fix unannotated variable declarations
      NOMMU: supply get_unmapped_area() to fix NOMMU SYSV SHM
      NOMMU: make SYSV SHM nattch work correctly
      FDPIC: fix the /proc/pid/stat representation of executable boundaries

David S. Miller (3):
      [SPARC64]: Get DEBUG_PAGEALLOC working again.
      [SPARC64]: Use Kconfig.preempt
      [SPARC64]: store-init needs trailing membar.

Deepak Saxena (1):
      [MIPS] Make MIPS udelay() preempt safe under DEBUG_PREEMPT

Divy Le Ray (5):
      cxgb3 - fix ethtool cmd on multiple queues port
      cxgb3 - Auto-load FW if mismatch detected
      cxgb3 - Fix potential MAC hang
      cxgb3 - T3B2 pcie config space
      cxgb3 - fix white spaces in drivers/net/Kconfig

Eric W. Biederman (1):
      tty: Fix two reported pid leaks

Evgeniy Dushistov (4):
      ufs2: more correct work with time
      ufs: prepare write + change blocks on the fly
      ufs: zeroize the rest of block in truncate
      ufs2: tindirect truncate fix

Franck Bui-Huu (1):
      [MIPS] Always use virt_to_phys() when translating kernel addresses

G. Liakhovetski (1):
      [IrDA]: irttp_dup spin_lock initialisation

Geert Uytterhoeven (1):
      bool fbdevs must depend on FB = y

Graeme Gregory (1):
      [ARM] 4270/2: mach-s3c2443/irq.c off by one error in dma irqs

Greg Kroah-Hartman (1):
      USB: new Novatel device ids for option driver

Guennadi Liakhovetski (1):
      [ARM] 4278/1: configure pxa27x I2C SCL as "input"

Guido Guenther (1):
      rivafb: fix initial brightness

Guillaume Chazarain (1):
      i386: Don't use the TSC in sched_clock if unstable

Heiko Carstens (3):
      [S390] memory detection: fix off by one bug.
      [S390] Wire up compat_sys_epoll_pwait.
      [S390] Wire up sys_utimes.

Henrique de Moraes Holschuh (1):
      ACPI: ibm-acpi: allow module to load when acpi notifiers can't be set (v2)

Hideo Saito (1):
      sh: Fix PCI BAR address-space wraparound.

Ingo Molnar (2):
      futex: PI state locking fix
      setup_boot_APIC_clock() irq-enable fix

J. Bruce Fields (1):
      [CRYPTO] api: scatterwalk_copychunks() fails to advance through scatterlist

Jack Steiner (1):
      [IA64] Fix get_model_name() for mixed cpu type systems

James Bottomley (1):
      fix process crash caused by randomisation and 64k pages

James Morris (1):
      time: fix formatting in /proc/timer_list

Jamie Clark (1):
      sata_sil24: Add Adaptec 1220SA PCI ID

Jarek Poplawski (2):
      lockdep: lockdep_depth vs. debug_locks
      lockdep: debug_show_all_locks & debug_show_held_locks vs. debug_locks

Jaroslav Kysela (1):
      [ALSA] version 1.0.14rc3

Jay Lan (1):
      [IA64] Fix typo/thinko in crash.c

Jean Delvare (3):
      [S390] strlcpy is smart enough
      i2c-amd8111: Missed cleanup
      i2c-i801: Restore the device state before leaving

Jeff Garzik (1):
      [netdrvr] ewrk3: correct card detection bug

Jeremy Fitzhardinge (1):
      i386: fix typo in sync_constant_test_bit()'s name

Jim Radford (1):
      USB: fix usb-serial regression

Joachim Deguara (1):
      [ALSA] hda-intel - Fix HDA buffer alignment

Joachim Fenkes (1):
      IB/ehca: Make scaling code work without CPU hotplug

Johannes Berg (1):
      change misleading EFI partition support description

Johannes Schlumberger (1):
      [CRYPTO] doc: Fix typo in hash example

Johannes Weiner (1):
      Documentation/sysrq.txt: added short description for 'Q' (timerlist)

John Heffner (1):
      [TCP]: Fix tcp_mem[] initialization.

John Keller (2):
      ia64: platform_kernel_launch_event is noop on generic kernel
      [IA64] Altix: ioremap vga_console_iobase

Jon Dowland (1):
      USB: two more device ids for dm9601 usbnet driver

Joy Latten (1):
      [XFRM]: ipsecv6 needs a space when printing audit record.

Ken L Johnson (1):
      USB: berry_charge: correct dbg string for second magic command

Kou Ishizaki (1):
      scc_pata: dependency fix

Krzysztof Helt (1):
      [ARM] 4272/1: Missing symbol h1940_pm_return fix

Larry Finger (1):
      bcm43xx: MANUALWLAN fixes

Len Brown (5):
      ACPI: Add support to parse 2nd MADT
      ACPICA: revert "acpi_serialize" changes
      ACPI: parse 2nd MADT by default
      ACPI: IA64: fix allnoconfig build
      ACPI: IA64: fix %ll build warnings

Li Yang (1):
      Revert "ucc_geth: returns NETDEV_TX_BUSY when BD ring is full"

Linus Torvalds (3):
      Revert "ACPI: Only use IPI on known broken machines (AMD, Dothan/BaniasPentium M)"
      x86-64: add "local_apic_timer_c2_ok" here too
      Linux 2.6.21-rc5

Marcel Selhorst (1):
      tpm_infineon: maintainer

Mark Glines (1):
      airprime: USB ID for Novatel EV620 mini PCI-E card

Masayuki Nakagawa (1):
      [IPV6]: ipv6_fl_socklist is inadvertently shared.

Mathieu Desnoyers (2):
      [POWERPC] Fix atomicity of TIF update in flush_thread()
      Fix atomicity of TIF update in flush_thread() for x86_64

Mattia Dongili (1):
      sony-laptop: MAINTAINERS fix entry, add L: and W:

Michael Halcrow (1):
      eCryptfs: fix possible NULL ptr deref in ecryptfs_d_release()

Michael Holzheu (1):
      [S390] reboot from and dump to SCSI under z/VM fails.

Michael Krufky (1):
      cx88-dvb: fix nxt200x rf input switching

Michael S. Tsirkin (3):
      IPoIB/cm: Fix reaping of stale connections
      IPoIB: Fix use-after-free in path_rec_completion()
      IB/ipoib: Fix thinko in packet length checks

Michal Schmidt (1):
      airo: Fix an error path memory leak

Mike Frysinger (1):
      sh: Convert struct ioctls to static defines.

Mohan Kumar M (1):
      [POWERPC] Avoid hypervisor statistics calculation in real mode

Nick Piggin (1):
      mm: fix madvise infinine loop

Nicolas Boichat (1):
      [ALSA] hda-codec - Add support for MacBook Pro 1st generation

Nigel Williams (1):
      [IrDA]: Delay needed when uploading firmware chunks

Oliver Neukum (1):
      USB: necessary update for mos7720 driver

Ondrej Zajicek (1):
      sstfb: fix pixclock setting on Voodoo 1/2 cards

Patrick McHardy (4):
      [NET]: Fix fib_rules dump race
      [BRIDGE]: Fix fdb RCU race
      [NETFILTER]: nf_conntrack_netlink: add missing dependency on NF_NAT
      [NETFILTER]: nat: avoid rerouting packets if only XFRM policy key changed

Patrick Ringl (1):
      fix typos in net/ieee80211/Kconfig

Paul Mundt (4):
      sh: Define missing __NR_readahead.
      sh: Fix SH-3 cache entry_mask and way_size calculation.
      sh: Fix bogus regs pointer in do_IRQ().
      serial: Fix sh-sci break interrupt/sysrq handling.

Pavel Machek (1):
      fix extra BIOS invocation during resume

Pete Zaitcev (1):
      USB: RAZR v3i unusual_devs

Peter Zijlstra (1):
      nfs: fix congestion control

Rafael J. Wysocki (4):
      swsusp: Fix resume error path in platform mode
      swsusp: disable nonboot CPUs before entering platform suspend
      swsusp: Fix SNAPSHOT_S2RAM ioctl
      Make XFS workqueues nonfreezable

Ralf Baechle (22):
      [MIPS] IP27, IP35: Fix warnings.
      [CHAR] lcd: Fix two warnings.
      [MIPS] Compat: Fix build if CONFIG_SYSVIPC is disabled.
      [MIPS] Lasat: Downgrade 64-bit kernel from experimental to broken.
      [MIPS] RTLX: Don't use volatile; it's fragile.
      [MIPS] RTLX: Harden against compiler reordering and optimization.
      [MIPS] RTLX: Protect rtlx_{read,write} with mutex.
      [MIPS] RTLX: Handle copy_*_user return values.
      [MIPS] Lockdep: Fix recursion bug.
      [MIPS] Kconfig: Move missplaced NR_CPUS default from SMTC to VSMP.
      ide: au1xxx: fix use of mixed declarations and code
      Fix build error due to not including <linux/errno.h>
      [MIPS] VI: TRACE_IRQS_OFF clobbers $v0, so save & restore around call.
      [MIPS] Export except_vec_vi_{mori,lui,ori} as text symbols.
      SAA9730: Fix large pile of warnings
      [MIPS] Fix pipeline hazard.
      [MIPS] Implement flush_anon_page().
      [MIPS] ARC: Fix warning.
      [MIPS] R3000: local_flush_data_cache_page take a pointer argument.
      [MIPS] Jazz: Fix warning.
      [MIPS] SB1: Fix pile of gcc's bogus format string warnings.
      [MIPS] SB1250: Fix bugs/warnings by creative use of volatile.

Ralph Wuerthner (2):
      [S390] zcrypt: fix possible dead lock in AP bus module
      [S390] zcrypt: fix possible race when unloading zcrypt driver modules

Randy Cushman (1):
      [ALSA] ac97 - fix AD shared shared jack control logic

Randy Dunlap (1):
      libata: kernel-doc fix

Robert Olsson (1):
      [IPV4]: Do not disable preemption in trie_leaf_remove().

Roland McGrath (1):
      i386: clear segment register padding in core dumps

Russell King (1):
      [ARM] Fix breakage caused by 72486f1f8f0a2bc828b9d30cf4690cf2dd6807fc

Sam Ravnborg (1):
      x86-64: fix section mismatch warnings

Samuel Ortiz (1):
      [IrDA]: Calling ppp_unregister_channel() from process context

Sean Hefty (1):
      IPoIB: Fix race in detaching from mcast group before attaching

Sebastian Siewior (1):
      [CRYPTO] tcrypt: Fix error checking for comp allocation

Sergei Shtylyov (1):
      cmd64x: fix recovery time calculation (take 3)

Stefan Richter (1):
      ieee1394: fix oops on "modprobe -r ohci1394" after network class_device conversion

Stefano Brivio (1):
      hwmon: Build fix for SENSORS_W83793

Stelian Pop (1):
      [ARM] 4264/1: ldrex/strex syntax errors with recent compilers

Stephen Hemminger (3):
      skge: deadlock on tx timeout
      skge: mask irqs when device down
      skge: use per-port phy locking

Steve French (2):
      [CIFS] Do not negotiate new POSIX_PATH_OPERATIONS_CAP yet
      [CIFS] Allow reset of file to ATTR_NORMAL when archive bit not set

Steve Wise (1):
      RDMA/cxgb3: Handle build_phys_page_list() failure in iwch_reregister_phys_mem()

Takashi Iwai (6):
      [ALSA] soc - Fix dependencies in Kconfig files
      [ALSA] hda-intel - Fix codec probe with ATI contorllers
      [ALSA] hda-codec - Fix speaker output on MacPro
      [ALSA] intel8x0 - Fix Oops at kdump crash kernel
      [ALSA] hda-codec - Add model for HP Compaq d5700
      [ALSA] hda-codec - Add model for HP Compaq d5750

Tejun Heo (4):
      jmicron: make ide jmicron driver play nice with libata ones
      libata: don't whine if ->prereset() returns -ENOENT
      sata_inic162x: kill double region requests
      pata_ixp4xx_cf: fix oops on detach

Thiemo Seufer (2):
      [MIPS] Misc fixes for plat_irq_dispatch functions
      [MIPS] mips-boards: More liberal check for mips-board console

Thomas Gleixner (12):
      hrtimer: prevent overrun DoS in hrtimer_forward()
      hrtimer: fix up unlocked access to wall_to_monotonic
      fix MTIME_SEC_MAX on 32-bit
      clockevents: Fix suspend/resume to disk hangs
      i386: trust the PM-Timer calibration of the local APIC timer
      i386: clockevents fix breakage on Geode/Cyrix PIT implementations
      i386: disable local apic timer via command line or dmi quirk
      i386: add command line option "local_apic_timer_c2_ok"
      x86_64: avoid sending LOCAL_TIMER_VECTOR IPI to itself
      i386: Prevent early access to TSC to avoid crash on TSCless systems
      dynticks: fix hrtimer rounding error in next_timer_interrupt
      clocksource: Fix thinko in watchdog selection

Thomas Renninger (1):
      ACPI: Only use IPI on known broken machines (AMD, Dothan/BaniasPentium M)

Tobin Davis (2):
      [ALSA] hda-codec - Add suppoprt for Asus M2N-SLI motherboard
      [ALSA] hda-codec - more systems for Analog Devices

Tommi Kyntola (1):
      [ALSA] intel8x0 - Fix speaker output after S2RAM

Trond Myklebust (1):
      nfs: nfs_getattr() can't call nfs_sync_mapping_range() for non-regular files

Ursula Braun (1):
      [S390] cio: qdio slsb setup

Uwe Kleine-König (1):
      [ARM] 4235/1: ns9xxx: declare the clock functions as "const"

Vasily Averin (1):
      smbfs: double free memory corruption

Vlad Yasevich (4):
      [SCTP]: Clean up stale data during association restart
      [SCTP]: Increment error counters on user requested HBs.
      [SCTP]: Reset some transport and association variables on restart
      [SCTP]: Correctly reset ssthresh when restarting association

Zach Brown (1):
      dio: invalidate clean pages before dio write

Zilvinas Valinskas (1):
      initialise pi_lock if CONFIG_RT_MUTEXES=N

Zou Nan hai (1):
      [IA64] min_low_pfn and max_low_pfn calculation fix

suzuki (1):
      fix rescan_partitions to return errors properly

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.21-rc5
  2007-03-26  8:31 ` Ingo Molnar
@ 2007-03-26  8:17   ` Ayaz Abdulla
  2007-03-26  8:39   ` Ingo Molnar
  1 sibling, 0 replies; 128+ messages in thread
From: Ayaz Abdulla @ 2007-03-26  8:17 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Linus Torvalds, Linux Kernel Mailing List, Jeff Garzik,
	Adrian Bunk, Andrew Morton

This issue might be resolved with the patch provided in the following 
bug report: http://bugzilla.kernel.org/show_bug.cgi?id=8058

Please try out the patch in the bug report without your patch and see if 
the issue reproduces.

Ayaz


Ingo Molnar wrote:
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> 
>>There's various fixes here, ranging from some architecture updates 
>>(ia64, ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.
> 
> 
> here's a new v2.6.20 -> v2.6.21 forcedeth.c regression:
> 
> in the last week or so i've been seeing sporadic under-load forcedeth.c 
> crashes (see the full oops further below):
> 
>  eth1: too many iterations (6) in nv_nic_irq.
>  Unable to handle kernel NULL pointer dereference at 0000000000000088 RIP: 
>  [<ffffffff80404587>] nv_tx_done+0xf4/0x1cf
> 
> this is line 1906 of drivers/net/forcedeth.c:
> 
>     np->stats.tx_bytes += np->get_tx_ctx->skb->len;
> 
> struct sk_buff's len field is at offset 88, so np->get_tx_ctx->skb is 
> NULL. That is an 'impossible' scenario for tx descriptors here - the tx 
> ring descriptors are always set up with a valid skb (and a valid dma 
> address), and their completion is serialized via np->lock.
> 
> these crashes are almost instant on the .21-rc5-rt kernel, but extremely 
> sporadic on the upstream kernel and needed very high networking loads to 
> trigger. Today i found a good way to trigger it almost instantly on 
> upstream kernels too: apply the debug patch attached further below and 
> do:
> 
> 	echo 100 > /proc/sys/kernel/panic
> 
> that will inject 100 artificial 'too many iterations' failures and 
> provokes a TX timeout - which TX timeout will crash. (i've used a 
> dual-core Athlon64 system in this test)
> 
> my first quick guess was to extend np->priv locking to the whole of 
> nv_start_xmit/nv_start_xmit_optimized - while that appeared to make the 
> crash a bit less likely, it did not prevent it. So there must be some 
> other, more fundamental problem be left as well. At first glance the SMP 
> locking looks OK, so maybe the ring indices are messed up somehow and we 
> got into a 'ring head bites the tail' scenario?
> 
> i can provide more info if needed.
> 
> 	Ingo
> 
> -------------->
> eth1: too many iterations (6) in nv_nic_irq.
> Unable to handle kernel NULL pointer dereference at 0000000000000088 RIP: 
>  [<ffffffff80404587>] nv_tx_done+0xf4/0x1cf
> PGD 34d03067 PUD 34d02067 PMD 0 
> Oops: 0000 [1] PREEMPT SMP 
> CPU 1 
> Modules linked in:
> Pid: 0, comm: swapper Not tainted 2.6.21-rc5 #8
> RIP: 0010:[<ffffffff80404587>]  [<ffffffff80404587>] nv_tx_done+0xf4/0x1cf
> RSP: 0018:ffff81003ff6be40  EFLAGS: 00010206
> RAX: 0000000000000000 RBX: ffff810002e26700 RCX: 0000000000000001
> RDX: 0000000000000042 RSI: 000000003ef00cbe RDI: ffff81003fbeb070
> RBP: ffff81003ff6be60 R08: ffff810002e26a00 R09: 0000000000000003
> R10: ffff81003ff4e100 R11: ffff810001e283f8 R12: 000000003ef00cbe
> R13: ffff810002e26000 R14: ffff810002e28fc0 R15: 0000000000000000
> FS:  00002b6cb57f1db0(0000) GS:ffff81003ff4ad40(0000) knlGS:0000000000000000
> CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> CR2: 0000000000000088 CR3: 0000000034c87000 CR4: 00000000000006e0
> Process swapper (pid: 0, threadinfo ffff81003ff64000, task ffff81003ff4e100)
> Stack:  ffff810002e26700 0000000000000032 ffffc2000001a000 ffff810002e26000
>  ffff81003ff6bea0 ffffffff80406dae ffff810002e26700 ffff810002e26700
>  ffff810002e26000 00000000000000ff ffffc2000001a000 ffffffff80749080
> Call Trace:
>  <IRQ>  [<ffffffff80406dae>] nv_nic_irq+0x76/0x261
>  [<ffffffff8040961e>] nv_do_nic_poll+0x200/0x284
>  [<ffffffff8040941e>] nv_do_nic_poll+0x0/0x284
>  [<ffffffff80241995>] run_timer_softirq+0x167/0x1dd
>  [<ffffffff8023de45>] __do_softirq+0x5b/0xc9
>  [<ffffffff8020af0c>] call_softirq+0x1c/0x28
>  [<ffffffff8020c2b4>] do_softirq+0x31/0x84
>  [<ffffffff8023db16>] irq_exit+0x3f/0x50
>  [<ffffffff802190c2>] smp_apic_timer_interrupt+0x49/0x5b
>  [<ffffffff802087fb>] default_idle+0x0/0x44
>  [<ffffffff8020a9b6>] apic_timer_interrupt+0x66/0x70
>  <EOI>  [<ffffffff8020882a>] default_idle+0x2f/0x44
>  [<ffffffff8020804c>] enter_idle+0x22/0x24
>  [<ffffffff802088d0>] cpu_idle+0x91/0xd4
>  [<ffffffff80218572>] start_secondary+0x2e3/0x2f5
> 
> ---
>  drivers/net/forcedeth.c |   20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> Index: linux/drivers/net/forcedeth.c
> ===================================================================
> --- linux.orig/drivers/net/forcedeth.c
> +++ linux/drivers/net/forcedeth.c
> @@ -2908,6 +2908,10 @@ static irqreturn_t nv_nic_irq(int foo, v
>  			spin_unlock(&np->lock);
>  			break;
>  		}
> +		if (panic_timeout > 0) {
> +			panic_timeout--;
> +			i = max_interrupt_work+1;
> +		}
>  		if (unlikely(i > max_interrupt_work)) {
>  			spin_lock(&np->lock);
>  			/* disable interrupts on the nic */
> @@ -3026,6 +3030,10 @@ static irqreturn_t nv_nic_irq_optimized(
>  			break;
>  		}
>  
> +		if (panic_timeout > 0) {
> +			panic_timeout--;
> +			i = max_interrupt_work+1;
> +		}
>  		if (unlikely(i > max_interrupt_work)) {
>  			spin_lock(&np->lock);
>  			/* disable interrupts on the nic */
> @@ -3076,6 +3084,10 @@ static irqreturn_t nv_nic_irq_tx(int foo
>  			dprintk(KERN_DEBUG "%s: received irq with events 0x%x. Probably TX fail.\n",
>  						dev->name, events);
>  		}
> +		if (panic_timeout > 0) {
> +			panic_timeout--;
> +			i = max_interrupt_work+1;
> +		}
>  		if (unlikely(i > max_interrupt_work)) {
>  			spin_lock_irqsave(&np->lock, flags);
>  			/* disable interrupts on the nic */
> @@ -3191,6 +3203,10 @@ static irqreturn_t nv_nic_irq_rx(int foo
>  			}
>  		}
>  
> +		if (panic_timeout > 0) {
> +			panic_timeout--;
> +			i = max_interrupt_work+1;
> +		}
>  		if (unlikely(i > max_interrupt_work)) {
>  			spin_lock_irqsave(&np->lock, flags);
>  			/* disable interrupts on the nic */
> @@ -3264,6 +3280,10 @@ static irqreturn_t nv_nic_irq_other(int 
>  			printk(KERN_DEBUG "%s: received irq with unknown events 0x%x. Please report\n",
>  						dev->name, events);
>  		}
> +		if (panic_timeout > 0) {
> +			panic_timeout--;
> +			i = max_interrupt_work+1;
> +		}
>  		if (unlikely(i > max_interrupt_work)) {
>  			spin_lock_irqsave(&np->lock, flags);
>  			/* disable interrupts on the nic */

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.21-rc5
  2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
@ 2007-03-26  8:31 ` Ingo Molnar
  2007-03-26  8:17   ` Ayaz Abdulla
  2007-03-26  8:39   ` Ingo Molnar
  2007-03-26  8:55 ` Linux 2.6.21-rc5 Thomas Gleixner
                   ` (18 subsequent siblings)
  19 siblings, 2 replies; 128+ messages in thread
From: Ingo Molnar @ 2007-03-26  8:31 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Linux Kernel Mailing List, Ayaz Abdulla, Jeff Garzik,
	Adrian Bunk, Andrew Morton


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> There's various fixes here, ranging from some architecture updates 
> (ia64, ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.

here's a new v2.6.20 -> v2.6.21 forcedeth.c regression:

in the last week or so i've been seeing sporadic under-load forcedeth.c 
crashes (see the full oops further below):

 eth1: too many iterations (6) in nv_nic_irq.
 Unable to handle kernel NULL pointer dereference at 0000000000000088 RIP: 
 [<ffffffff80404587>] nv_tx_done+0xf4/0x1cf

this is line 1906 of drivers/net/forcedeth.c:

    np->stats.tx_bytes += np->get_tx_ctx->skb->len;

struct sk_buff's len field is at offset 88, so np->get_tx_ctx->skb is 
NULL. That is an 'impossible' scenario for tx descriptors here - the tx 
ring descriptors are always set up with a valid skb (and a valid dma 
address), and their completion is serialized via np->lock.

these crashes are almost instant on the .21-rc5-rt kernel, but extremely 
sporadic on the upstream kernel and needed very high networking loads to 
trigger. Today i found a good way to trigger it almost instantly on 
upstream kernels too: apply the debug patch attached further below and 
do:

	echo 100 > /proc/sys/kernel/panic

that will inject 100 artificial 'too many iterations' failures and 
provokes a TX timeout - which TX timeout will crash. (i've used a 
dual-core Athlon64 system in this test)

my first quick guess was to extend np->priv locking to the whole of 
nv_start_xmit/nv_start_xmit_optimized - while that appeared to make the 
crash a bit less likely, it did not prevent it. So there must be some 
other, more fundamental problem be left as well. At first glance the SMP 
locking looks OK, so maybe the ring indices are messed up somehow and we 
got into a 'ring head bites the tail' scenario?

i can provide more info if needed.

	Ingo

-------------->
eth1: too many iterations (6) in nv_nic_irq.
Unable to handle kernel NULL pointer dereference at 0000000000000088 RIP: 
 [<ffffffff80404587>] nv_tx_done+0xf4/0x1cf
PGD 34d03067 PUD 34d02067 PMD 0 
Oops: 0000 [1] PREEMPT SMP 
CPU 1 
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.21-rc5 #8
RIP: 0010:[<ffffffff80404587>]  [<ffffffff80404587>] nv_tx_done+0xf4/0x1cf
RSP: 0018:ffff81003ff6be40  EFLAGS: 00010206
RAX: 0000000000000000 RBX: ffff810002e26700 RCX: 0000000000000001
RDX: 0000000000000042 RSI: 000000003ef00cbe RDI: ffff81003fbeb070
RBP: ffff81003ff6be60 R08: ffff810002e26a00 R09: 0000000000000003
R10: ffff81003ff4e100 R11: ffff810001e283f8 R12: 000000003ef00cbe
R13: ffff810002e26000 R14: ffff810002e28fc0 R15: 0000000000000000
FS:  00002b6cb57f1db0(0000) GS:ffff81003ff4ad40(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000088 CR3: 0000000034c87000 CR4: 00000000000006e0
Process swapper (pid: 0, threadinfo ffff81003ff64000, task ffff81003ff4e100)
Stack:  ffff810002e26700 0000000000000032 ffffc2000001a000 ffff810002e26000
 ffff81003ff6bea0 ffffffff80406dae ffff810002e26700 ffff810002e26700
 ffff810002e26000 00000000000000ff ffffc2000001a000 ffffffff80749080
Call Trace:
 <IRQ>  [<ffffffff80406dae>] nv_nic_irq+0x76/0x261
 [<ffffffff8040961e>] nv_do_nic_poll+0x200/0x284
 [<ffffffff8040941e>] nv_do_nic_poll+0x0/0x284
 [<ffffffff80241995>] run_timer_softirq+0x167/0x1dd
 [<ffffffff8023de45>] __do_softirq+0x5b/0xc9
 [<ffffffff8020af0c>] call_softirq+0x1c/0x28
 [<ffffffff8020c2b4>] do_softirq+0x31/0x84
 [<ffffffff8023db16>] irq_exit+0x3f/0x50
 [<ffffffff802190c2>] smp_apic_timer_interrupt+0x49/0x5b
 [<ffffffff802087fb>] default_idle+0x0/0x44
 [<ffffffff8020a9b6>] apic_timer_interrupt+0x66/0x70
 <EOI>  [<ffffffff8020882a>] default_idle+0x2f/0x44
 [<ffffffff8020804c>] enter_idle+0x22/0x24
 [<ffffffff802088d0>] cpu_idle+0x91/0xd4
 [<ffffffff80218572>] start_secondary+0x2e3/0x2f5

---
 drivers/net/forcedeth.c |   20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

Index: linux/drivers/net/forcedeth.c
===================================================================
--- linux.orig/drivers/net/forcedeth.c
+++ linux/drivers/net/forcedeth.c
@@ -2908,6 +2908,10 @@ static irqreturn_t nv_nic_irq(int foo, v
 			spin_unlock(&np->lock);
 			break;
 		}
+		if (panic_timeout > 0) {
+			panic_timeout--;
+			i = max_interrupt_work+1;
+		}
 		if (unlikely(i > max_interrupt_work)) {
 			spin_lock(&np->lock);
 			/* disable interrupts on the nic */
@@ -3026,6 +3030,10 @@ static irqreturn_t nv_nic_irq_optimized(
 			break;
 		}
 
+		if (panic_timeout > 0) {
+			panic_timeout--;
+			i = max_interrupt_work+1;
+		}
 		if (unlikely(i > max_interrupt_work)) {
 			spin_lock(&np->lock);
 			/* disable interrupts on the nic */
@@ -3076,6 +3084,10 @@ static irqreturn_t nv_nic_irq_tx(int foo
 			dprintk(KERN_DEBUG "%s: received irq with events 0x%x. Probably TX fail.\n",
 						dev->name, events);
 		}
+		if (panic_timeout > 0) {
+			panic_timeout--;
+			i = max_interrupt_work+1;
+		}
 		if (unlikely(i > max_interrupt_work)) {
 			spin_lock_irqsave(&np->lock, flags);
 			/* disable interrupts on the nic */
@@ -3191,6 +3203,10 @@ static irqreturn_t nv_nic_irq_rx(int foo
 			}
 		}
 
+		if (panic_timeout > 0) {
+			panic_timeout--;
+			i = max_interrupt_work+1;
+		}
 		if (unlikely(i > max_interrupt_work)) {
 			spin_lock_irqsave(&np->lock, flags);
 			/* disable interrupts on the nic */
@@ -3264,6 +3280,10 @@ static irqreturn_t nv_nic_irq_other(int 
 			printk(KERN_DEBUG "%s: received irq with unknown events 0x%x. Please report\n",
 						dev->name, events);
 		}
+		if (panic_timeout > 0) {
+			panic_timeout--;
+			i = max_interrupt_work+1;
+		}
 		if (unlikely(i > max_interrupt_work)) {
 			spin_lock_irqsave(&np->lock, flags);
 			/* disable interrupts on the nic */

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.21-rc5
  2007-03-26  8:31 ` Ingo Molnar
  2007-03-26  8:17   ` Ayaz Abdulla
@ 2007-03-26  8:39   ` Ingo Molnar
  2007-03-26  8:58     ` [patch] forcedeth: work around NULL skb dereference crash Ingo Molnar
  1 sibling, 1 reply; 128+ messages in thread
From: Ingo Molnar @ 2007-03-26  8:39 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Linux Kernel Mailing List, Ayaz Abdulla, Jeff Garzik,
	Adrian Bunk, Andrew Morton


* Ingo Molnar <mingo@elte.hu> wrote:

> my first quick guess was to extend np->priv locking to the whole of 
> nv_start_xmit/nv_start_xmit_optimized - while that appeared to make 
> the crash a bit less likely, it did not prevent it. So there must be 
> some other, more fundamental problem be left as well. At first glance 
> the SMP locking looks OK, so maybe the ring indices are messed up 
> somehow and we got into a 'ring head bites the tail' scenario?

to be specific, the patch below is what i tried - but it didnt 
completely fix the crash.

	Ingo

---
 drivers/net/forcedeth.c |   15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

Index: linux/drivers/net/forcedeth.c
===================================================================
--- linux.orig/drivers/net/forcedeth.c
+++ linux/drivers/net/forcedeth.c
@@ -1650,9 +1650,10 @@ static int nv_start_xmit(struct sk_buff 
 			   ((skb_shinfo(skb)->frags[i].size & (NV_TX2_TSO_MAX_SIZE-1)) ? 1 : 0);
 	}
 
+	spin_lock_irq(&np->lock);
+
 	empty_slots = nv_get_empty_tx_slots(np);
 	if (unlikely(empty_slots <= entries)) {
-		spin_lock_irq(&np->lock);
 		netif_stop_queue(dev);
 		np->tx_stop = 1;
 		spin_unlock_irq(&np->lock);
@@ -1718,8 +1719,6 @@ static int nv_start_xmit(struct sk_buff 
 		tx_flags_extra = skb->ip_summed == CHECKSUM_PARTIAL ?
 			 NV_TX2_CHECKSUM_L3 | NV_TX2_CHECKSUM_L4 : 0;
 
-	spin_lock_irq(&np->lock);
-
 	/* set tx flags */
 	start_tx->flaglen |= cpu_to_le32(tx_flags | tx_flags_extra);
 	np->put_tx.orig = put_tx;
@@ -1766,9 +1765,10 @@ static int nv_start_xmit_optimized(struc
 			   ((skb_shinfo(skb)->frags[i].size & (NV_TX2_TSO_MAX_SIZE-1)) ? 1 : 0);
 	}
 
+	spin_lock_irq(&np->lock);
+
 	empty_slots = nv_get_empty_tx_slots(np);
 	if (unlikely(empty_slots <= entries)) {
-		spin_lock_irq(&np->lock);
 		netif_stop_queue(dev);
 		np->tx_stop = 1;
 		spin_unlock_irq(&np->lock);
@@ -1846,8 +1846,6 @@ static int nv_start_xmit_optimized(struc
 			start_tx->txvlan = 0;
 	}
 
-	spin_lock_irq(&np->lock);
-
 	/* set tx flags */
 	start_tx->flaglen |= cpu_to_le32(tx_flags | tx_flags_extra);
 	np->put_tx.ex = put_tx;
@@ -3484,6 +3482,7 @@ static void nv_do_nic_poll(unsigned long
 	struct net_device *dev = (struct net_device *) data;
 	struct fe_priv *np = netdev_priv(dev);
 	u8 __iomem *base = get_hwbase(dev);
+	unsigned long flags;
 	u32 mask = 0;
 
 	/*
@@ -3519,7 +3518,7 @@ static void nv_do_nic_poll(unsigned long
 		printk(KERN_INFO "forcedeth: MAC in recoverable error state\n");
 		if (netif_running(dev)) {
 			netif_tx_lock_bh(dev);
-			spin_lock(&np->lock);
+			spin_lock_irqsave(&np->lock, flags);
 			/* stop engines */
 			nv_stop_rx(dev);
 			nv_stop_tx(dev);
@@ -3545,7 +3544,7 @@ static void nv_do_nic_poll(unsigned long
 			/* restart rx engine */
 			nv_start_rx(dev);
 			nv_start_tx(dev);
-			spin_unlock(&np->lock);
+			spin_unlock_irqrestore(&np->lock, flags);
 			netif_tx_unlock_bh(dev);
 		}
 	}

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.21-rc5
  2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
  2007-03-26  8:31 ` Ingo Molnar
@ 2007-03-26  8:55 ` Thomas Gleixner
  2007-03-26 12:25   ` Bob Tracy
  2007-03-26  9:04 ` 2.6.21-rc5: maxcpus=1 crash in cpufreq: kernel BUG at drivers/cpufreq/cpufreq.c:82! Ingo Molnar
                   ` (17 subsequent siblings)
  19 siblings, 1 reply; 128+ messages in thread
From: Thomas Gleixner @ 2007-03-26  8:55 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List

On Sun, 2007-03-25 at 16:08 -0700, Linus Torvalds wrote:
> Those timer changes ended up much more painful than anybody wished for, 
> but big thanks to Thomas Gleixner for being on it like a weasel on a dead 
> rat, and the regression list has kept shrinking.

Why certainly ! I caused them, so I have to fix them. There are still a
few to hunt down and I want to sort them out before 2.6.21 final.

> So if you have reported a regression in the 2.6.21-rc series, please check 
> 2.6.21-rc5, and update your report as appropriate (whether fixed or "still 
> problems with xyzzy").

This fix from John Stultz is still missing:

http://lkml.org/lkml/2007/3/22/287

It's in Andrews queue already and waits to be sent to you.

	tglx




^ permalink raw reply	[flat|nested] 128+ messages in thread

* [patch] forcedeth: work around NULL skb dereference crash
  2007-03-26  8:39   ` Ingo Molnar
@ 2007-03-26  8:58     ` Ingo Molnar
  2007-04-02 11:56       ` [patch] forcedeth: improve NAPI logic Ingo Molnar
  0 siblings, 1 reply; 128+ messages in thread
From: Ingo Molnar @ 2007-03-26  8:58 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Linux Kernel Mailing List, Ayaz Abdulla, Jeff Garzik,
	Adrian Bunk, Andrew Morton


* Ingo Molnar <mingo@elte.hu> wrote:

> > my first quick guess was to extend np->priv locking to the whole of 
> > nv_start_xmit/nv_start_xmit_optimized - while that appeared to make 
> > the crash a bit less likely, it did not prevent it. So there must be 
> > some other, more fundamental problem be left as well. At first 
> > glance the SMP locking looks OK, so maybe the ring indices are 
> > messed up somehow and we got into a 'ring head bites the tail' 
> > scenario?
> 
> to be specific, the patch below is what i tried - but it didnt 
> completely fix the crash.

the patch below works the crash around. It does not seem to be a 'tx 
ring head bits the tail' scenario:

 get_tx: 55, put_tx: 57
 get_tx: 80, put_tx: 86
 get_tx: 88, put_tx: 97
 get_tx: 97, put_tx: 109
 get_tx: 97, put_tx: 109
 get_tx: 111, put_tx: 117
 get_tx: 117, put_tx: 125
 get_tx: 127, put_tx: 137
 get_tx: 137, put_tx: 147
 get_tx: 147, put_tx: 149

	Ingo

------------>
From: Ingo Molnar <mingo@elte.hu>
Subject: [patch] forcedeth: work around NULL skb dereference crash

work around a NULL skb dereference crash that occurs during high load.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 drivers/net/forcedeth.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

Index: linux/drivers/net/forcedeth.c
===================================================================
--- linux.orig/drivers/net/forcedeth.c
+++ linux/drivers/net/forcedeth.c
@@ -1902,6 +1902,11 @@ static void nv_tx_done(struct net_device
 						np->stats.tx_carrier_errors++;
 					np->stats.tx_errors++;
 				} else {
+					if (!np->get_tx_ctx->skb) {
+						printk("get_tx: %ld, put_tx: %ld\n", np->get_tx_ctx - np->first_tx_ctx, np->put_tx_ctx - np->first_tx_ctx);
+						WARN_ON(1);
+						break;
+					}
 					np->stats.tx_packets++;
 					np->stats.tx_bytes += np->get_tx_ctx->skb->len;
 				}
@@ -1917,6 +1922,11 @@ static void nv_tx_done(struct net_device
 						np->stats.tx_carrier_errors++;
 					np->stats.tx_errors++;
 				} else {
+					if (!np->get_tx_ctx->skb) {
+						printk("get_tx: %ld, put_tx: %ld\n", np->get_tx_ctx - np->first_tx_ctx, np->put_tx_ctx - np->first_tx_ctx);
+						WARN_ON(1);
+						break;
+					}
 					np->stats.tx_packets++;
 					np->stats.tx_bytes += np->get_tx_ctx->skb->len;
 				}

^ permalink raw reply	[flat|nested] 128+ messages in thread

* 2.6.21-rc5: maxcpus=1 crash in cpufreq: kernel BUG at drivers/cpufreq/cpufreq.c:82!
  2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
  2007-03-26  8:31 ` Ingo Molnar
  2007-03-26  8:55 ` Linux 2.6.21-rc5 Thomas Gleixner
@ 2007-03-26  9:04 ` Ingo Molnar
  2007-03-26 18:12   ` Venki Pallipadi
  2007-03-26  9:21 ` [PATCH] clockevents: remove bad designed sysfs support for now Thomas Gleixner
                   ` (16 subsequent siblings)
  19 siblings, 1 reply; 128+ messages in thread
From: Ingo Molnar @ 2007-03-26  9:04 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Dave Jones, Venkatesh Pallipadi

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


trying to debug the forcedeth crash triggered another, new
v2.6.20 -> v2.6.21 regression:

maxcpus=1 on a dual-core system crashes the x86_64 SMP kernel in 
lock_policy_rwsem_write() - see the crash log below. Config attached.

i suspect it could be related to this recent commit:

 commit 5a01f2e8f3ac134e24144d74bb48a60236f7024d
 Author: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
 Date:   Mon Feb 5 16:12:44 2007 -0800

    [CPUFREQ] Rewrite lock in cpufreq to eliminate cpufreq/hotplug related issue

	Ingo

---------------->
Linux version 2.6.21-rc5 (mingo@dione) (gcc version 4.0.2) #14 SMP PREEMPT Mon Mar 26 10:51:51 CEST 2007
Command line: root=/dev/hda5 earlyprintk=serial,ttyS0,115200 console=ttyS0,115200 console=tty 3 profile=0 debug initcall_debug noapic apic=debug maxcpus=1 selinux=0 netconsole=4444@10.0.1.12/eth0,4444@10.0.1.14/00:16:76:ab:6e:84 nmi_watchdog=2 ignore_loglevel debug_dir
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
 BIOS-e820: 000000003fff0000 - 000000003fff3000 (ACPI NVS)
 BIOS-e820: 000000003fff3000 - 0000000040000000 (ACPI data)
 BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
 BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
Entering add_active_range(0, 0, 159) 0 entries of 3200 used
Entering add_active_range(0, 256, 262128) 1 entries of 3200 used
end_pfn_map = 1048576
DMI 2.3 present.
ACPI: RSDP 000F76F0, 0014 (r0 Nvidia)
ACPI: RSDT 3FFF3040, 0034 (r1 Nvidia AWRDACPI 42302E31 AWRD        0)
ACPI: FACP 3FFF30C0, 0074 (r1 Nvidia AWRDACPI 42302E31 AWRD        0)
ACPI: DSDT 3FFF3180, 6264 (r1 NVIDIA AWRDACPI     1000 MSFT  100000E)
ACPI: FACS 3FFF0000, 0040
ACPI: SRAT 3FFF9500, 00A0 (r1 AMD    HAMMER          1 AMD         1)
ACPI: MCFG 3FFF9600, 003C (r1 Nvidia AWRDACPI 42302E31 AWRD        0)
ACPI: APIC 3FFF9440, 007C (r1 Nvidia AWRDACPI 42302E31 AWRD        0)
SRAT: PXM 0 -> APIC 0 -> Node 0
SRAT: PXM 0 -> APIC 1 -> Node 0
SRAT: Node 0 PXM 0 0-a0000
Entering add_active_range(0, 0, 159) 0 entries of 3200 used
SRAT: Node 0 PXM 0 0-40000000
Entering add_active_range(0, 0, 159) 1 entries of 3200 used
Entering add_active_range(0, 256, 262128) 1 entries of 3200 used
NUMA: Using 63 for the hash shift.
Bootmem setup node 0 0000000000000000-000000003fff0000
Zone PFN ranges:
  DMA             0 ->     4096
  DMA32        4096 ->  1048576
  Normal    1048576 ->  1048576
early_node_map[2] active PFN ranges
    0:        0 ->      159
    0:      256 ->   262128
On node 0 totalpages: 262031
  DMA zone: 56 pages used for memmap
  DMA zone: 2414 pages reserved
  DMA zone: 1529 pages, LIFO batch:0
  DMA32 zone: 3527 pages used for memmap
  DMA32 zone: 254505 pages, LIFO batch:31
  Normal zone: 0 pages used for memmap
Nvidia board detected. Ignoring ACPI timer override.
If you got timer trouble try acpi_use_timer_override
ACPI: PM-Timer IO Port: 0x4008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: Skipping IOAPIC probe due to 'noapic' option.
Using ACPI for processor (LAPIC) configuration information
Intel MultiProcessor Specification v1.4
MPTABLE: OEM ID: OEM00000 MPTABLE: Product ID: PROD00000000 MPTABLE: APIC at: 0xFEE00000
I/O APIC #2 at 0xFEC00000.
Setting APIC routing to physical flat
Processors: 2
mapped APIC to ffffffffff5fd000 (        fee00000)
mapped IOAPIC to ffffffffff5fc000 (00000000fec00000)
Nosave address range: 000000000009f000 - 00000000000a0000
Nosave address range: 00000000000a0000 - 00000000000f0000
Nosave address range: 00000000000f0000 - 0000000000100000
Allocating PCI resources starting at 50000000 (gap: 40000000:a0000000)
SMP: Allowing 2 CPUs, 0 hotplug CPUs
PERCPU: Allocating 68480 bytes of per cpu data
Built 1 zonelists.  Total pages: 256034
Kernel command line: root=/dev/hda5 earlyprintk=serial,ttyS0,115200 console=ttyS0,115200 console=tty 3 profile=0 debug initcall_debug noapic apic=debug maxcpus=1 selinux=0 netconsole=4444@10.0.1.12/eth0,4444@10.0.1.14/00:16:76:ab:6e:84 nmi_watchdog=2 ignore_loglevel debug_dir
kernel profiling enabled (shift: 0)
debug: ignoring loglevel setting.
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
time.c: Detected 2160.233 MHz processor.
disabling early console
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Checking aperture...
CPU 0: aperture @ 230000000 size 32 MB
Aperture too small (32 MB)
No AGP bridge found
Memory: 1009328k/1048512k available (3246k kernel code, 38796k reserved, 2130k data, 372k init)
Calibrating delay using timer specific routine.. 4321.70 BogoMIPS (lpj=2160852)
Security Framework v1.0.0 initialized
SELinux:  Disabled at boot.
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 0/0 -> Node 0
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
SMP alternatives: switching to UP code
ACPI: Core revision 20070126
ACPI: setting ELCR to 0200 (from 0828)
enabled ExtINT on CPU#0
Using local APIC timer interrupts.
result 13501473
Detected 13.501 MHz APIC timer.
Brought up 1 CPUs
testing NMI watchdog ... OK.
Calling initcall 0xffffffff80a30c7c: init_cpufreq_transition_notifier_list+0x0/0x14()
Calling initcall 0xffffffff80a1879f: cpufreq_tsc+0x0/0x60()
Calling initcall 0xffffffff80216f24: init_smp_flush+0x0/0x51()
Calling initcall 0xffffffff80a20bf1: init_elf32_binfmt+0x0/0x12()
Calling initcall 0xffffffff80a21c6f: sysctl_init+0x0/0x16()
Calling initcall 0xffffffff80a22299: helper_init+0x0/0x2b()
Calling initcall 0xffffffff80a22605: pm_init+0x0/0x29()
Calling initcall 0xffffffff80a2262e: pm_disk_init+0x0/0x19()
Calling initcall 0xffffffff80a22ae7: ksysfs_init+0x0/0x29()
Calling initcall 0xffffffff80a25457: filelock_init+0x0/0x31()
Calling initcall 0xffffffff80a25ec8: init_misc_binfmt+0x0/0x3c()
Calling initcall 0xffffffff80a25f04: init_script_binfmt+0x0/0x12()
Calling initcall 0xffffffff80a25f16: init_elf_binfmt+0x0/0x12()
Calling initcall 0xffffffff80a26918: debugfs_init+0x0/0x47()
Calling initcall 0xffffffff80a26e9d: securityfs_init+0x0/0x47()
Calling initcall 0xffffffff80a27e39: random32_init+0x0/0x57()
Calling initcall 0xffffffff80a30c90: cpufreq_core_init+0x0/0x76()
Calling initcall 0xffffffff80a32b06: sock_init+0x0/0x5f()
Calling initcall 0xffffffff80a3325d: netpoll_init+0x0/0x3b()
Calling initcall 0xffffffff80a334e5: netlink_proto_init+0x0/0x16a()
NET: Registered protocol family 16
Calling initcall 0xffffffff80a27d5d: kobject_uevent_init+0x0/0x3a()
Calling initcall 0xffffffff80a28142: pcibus_class_init+0x0/0x12()
Calling initcall 0xffffffff80a286ff: pci_driver_init+0x0/0x12()
Calling initcall 0xffffffff80a290d8: backlight_class_init+0x0/0x12()
Calling initcall 0xffffffff80a2ad14: dock_init+0x0/0x51()
No dock devices found.
Calling initcall 0xffffffff80a2c4c8: tty_class_init+0x0/0x2a()
Calling initcall 0xffffffff80a2cc16: vtconsole_class_init+0x0/0xba()
Calling initcall 0xffffffff80a2e000: register_node_type+0x0/0x12()
Calling initcall 0xffffffff80a18c45: mtrr_if_init+0x0/0x74()
Calling initcall 0xffffffff80a19bd2: ffh_cstate_init+0x0/0x31()
initcall at 0xffffffff80a19bd2: ffh_cstate_init+0x0/0x31(): returned with error code -1
Calling initcall 0xffffffff80a28c2a: acpi_pci_init+0x0/0x2e()
ACPI: bus type pci registered
Calling initcall 0xffffffff80a2a669: init_acpi_device_notify+0x0/0x4b()
Calling initcall 0xffffffff80a3191f: pci_access_init+0x0/0x43()
PCI: Using MMCONFIG at e0000000 - efffffff
PCI: No mmconfig possible on device 00:18
Calling initcall 0xffffffff80a18ab6: mtrr_init_finialize+0x0/0x34()
Calling initcall 0xffffffff80a1e915: topology_init+0x0/0x8d()
Calling initcall 0xffffffff80a2207f: param_sysfs_init+0x0/0x186()
Calling initcall 0xffffffff8025ce7d: pm_sysrq_init+0x0/0x1b()
Calling initcall 0xffffffff80a25b1b: init_bio+0x0/0x101()
Calling initcall 0xffffffff80a27b33: genhd_device_init+0x0/0x56()
Calling initcall 0xffffffff80a28c58: fbmem_init+0x0/0x95()
Calling initcall 0xffffffff80a2a46c: acpi_init+0x0/0x1fd()
ACPI: Interpreter enabled
ACPI: (supports S0 S1 S3 S4 S5)
ACPI: Using PIC for interrupt routing
Calling initcall 0xffffffff80a2a6b4: acpi_scan_init+0x0/0x10e()
Calling initcall 0xffffffff80a2a972: acpi_ec_init+0x0/0x61()
Calling initcall 0xffffffff80a2adc3: acpi_pci_root_init+0x0/0x28()
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
0000:00:06.0: cannot adjust BAR0 (not I/O)
0000:00:06.0: cannot adjust BAR1 (not I/O)
0000:00:06.0: cannot adjust BAR2 (not I/O)
0000:00:06.0: cannot adjust BAR3 (not I/O)
PCI: Transparent bridge - 0000:00:09.0
Boot video device is 0000:01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
Calling initcall 0xffffffff80a2aed8: acpi_pci_link_init+0x0/0x48()
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNK3] (IRQs 3 4 *5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LUBA] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LUBB] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LMAC] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LACI] (IRQs *3 4 5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LSMB] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LUB2] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LSID] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LFID] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LPCA] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [APC1] (IRQs 16) *0, disabled.
ACPI: PCI Interrupt Link [APC2] (IRQs 17) *0, disabled.
ACPI: PCI Interrupt Link [APC3] (IRQs 18) *0, disabled.
ACPI: PCI Interrupt Link [APC4] (IRQs<7>spurious 8259A interrupt: IRQ7.
 19) *0, disabled.
ACPI: PCI Interrupt Link [APC5] (IRQs *16), disabled.
ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCS] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APSI] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APSJ] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCP] (IRQs 20 21 22 23) *0, disabled.
Calling initcall 0xffffffff80a2afc1: acpi_power_init+0x0/0x77()
Calling initcall 0xffffffff80a2b1b5: acpi_system_init+0x0/0xc6()
Calling initcall 0xffffffff80a2b27b: acpi_event_init+0x0/0x3f()
Calling initcall 0xffffffff80a2be66: acpi_cm_sbs_init+0x0/0x8()
Calling initcall 0xffffffff80a2be6e: pnp_init+0x0/0x20()
Linux Plug and Play Support v0.97 (c) Adam Belay
Calling initcall 0xffffffff80a2bff7: pnpacpi_init+0x0/0x6a()
pnp: PnP ACPI init
pnp: PnP ACPI: found 16 devices
Calling initcall 0xffffffff80a2c938: misc_init+0x0/0x86()
Calling initcall 0xffffffff803d7702: cn_init+0x0/0xce()
Calling initcall 0xffffffff80a2efa8: init_scsi+0x0/0x90()
SCSI subsystem initialized
Calling initcall 0xffffffff80a2f475: ata_init+0x0/0x7b()
libata version 2.20 loaded.
Calling initcall 0xffffffff80a2fa3e: init_pcmcia_cs+0x0/0x38()
Calling initcall 0xffffffff80a30182: usb_init+0x0/0x118()
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Calling initcall 0xffffffff80a30574: serio_init+0x0/0x8b()
Calling initcall 0xffffffff80a3092f: input_init+0x0/0x123()
Calling initcall 0xffffffff80a30d38: leds_init+0x0/0x2a()
Calling initcall 0xffffffff80a313de: dma_bus_init+0x0/0x2c()
Calling initcall 0xffffffff80a31962: pci_acpi_init+0x0/0xab()
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
Calling initcall 0xffffffff80a31a0d: pci_legacy_init+0x0/0x124()
Calling initcall 0xffffffff80a31ecd: pcibios_irq_init+0x0/0x494()
Calling initcall 0xffffffff80a32361: pcibios_init+0x0/0x77()
Calling initcall 0xffffffff80a32bc0: proto_init+0x0/0x34()
Calling initcall 0xffffffff80a32d13: net_dev_init+0x0/0x253()
Calling initcall 0xffffffff80a33222: wireless_nlevent_init+0x0/0x3b()
Calling initcall 0xffffffff80a33298: fib_rules_init+0x0/0x12()
Calling initcall 0xffffffff80a333ad: pktsched_init+0x0/0xa6()
Calling initcall 0xffffffff80a33465: tc_filter_init+0x0/0x40()
Calling initcall 0xffffffff80a334a5: tc_action_init+0x0/0x40()
Calling initcall 0xffffffff80a3364f: genl_init+0x0/0xad()
Calling initcall 0xffffffff80a34885: cipso_v4_init+0x0/0x6b()
Calling initcall 0xffffffff80a34c88: netlbl_init+0x0/0x75()
NetLabel: Initializing
NetLabel:  domain hash size = 128
NetLabel:  protocols = UNLABELED CIPSOv4
NetLabel:  unlabeled traffic allowed by default
Calling initcall 0xffffffff80a184b7: pci_iommu_init+0x0/0x17()
Calling initcall 0xffffffff80a2237e: clocksource_done_booting+0x0/0x12()
Calling initcall 0xffffffff80a253e1<6>Time: tsc clocksource has been installed.
: init_pipe_fs+0x0/0x49()
Calling initcall 0xffffffff80a2bf72: pnp_system_init+0x0/0x12()
pnp: 00:01: ioport range 0x4000-0x407f has been reserved
pnp: 00:01: ioport range 0x4080-0x40ff has been reserved
pnp: 00:01: ioport range 0x4400-0x447f has been reserved
pnp: 00:01: ioport range 0x4480-0x44ff has been reserved
pnp: 00:01: ioport range 0x4800-0x487f has been reserved
pnp: 00:01: ioport range 0x4880-0x48ff has been reserved
pnp: 00:0e: iomem range 0xe0000000-0xefffffff has been reserved
pnp: 00:0f: iomem range 0xf0000-0xf3fff could not be reserved
pnp: 00:0f: iomem range 0xf4000-0xf7fff could not be reserved
pnp: 00:0f: iomem range 0xf8000-0xfbfff could not be reserved
pnp: 00:0f: iomem range 0xfc000-0xfffff could not be reserved
Calling initcall 0xffffffff80a2c3d0: chr_dev_init+0x0/0x88()
Calling initcall 0xffffffff80a2df90: firmware_class_init+0x0/0x70()
Calling initcall 0xffffffff80a2fa76: init_pcmcia_bus+0x0/0x7b()
Calling initcall 0xffffffff80a30d06: cpufreq_gov_performance_init+0x0/0x12()
Calling initcall 0xffffffff80a30d18: cpufreq_gov_userspace_init+0x0/0x20()
Calling initcall 0xffffffff80a31330: init_acpi_pm_clocksource+0x0/0xae()
Calling initcall 0xffffffff80a3140a<6>Time: acpi_pm clocksource has been installed.
: pcibios_assign_resources+0x0/0x8b()
PCI: Bridge: 0000:00:09.0
  IO window: c000-cfff
  MEM window: da000000-da0fffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0b.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0c.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0d.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0e.0
  IO window: b000-bfff
  MEM window: d8000000-d9ffffff
  PREFETCH window: d0000000-d7ffffff
PCI: Setting latency timer of device 0000:00:09.0 to 64
PCI: Setting latency timer of device 0000:00:0b.0 to 64
PCI: Setting latency timer of device 0000:00:0c.0 to 64
PCI: Setting latency timer of device 0000:00:0d.0 to 64
PCI: Setting latency timer of device 0000:00:0e.0 to 64
Calling initcall 0xffffffff80a32a33: fill_mp_bus_to_cpumask+0x0/0xd3()
Calling initcall 0xffffffff80a34194: inet_init+0x0/0x42d()
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 6, 262144 bytes)
TCP established hash table entries: 131072 (order: 9, 3145728 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
Calling initcall 0xffffffff80a15f52: populate_rootfs+0x0/0xec()
Calling initcall 0xffffffff8020d187: time_init_device+0x0/0x22()
Calling initcall 0xffffffff80a16c9e: init_timer_sysfs+0x0/0x22()
Calling initcall 0xffffffff80a16c7c: i8259A_init_sysfs+0x0/0x22()
Calling initcall 0xffffffff80a17102: vsyscall_init+0x0/0xa8()
Calling initcall 0xffffffff80a173bd: sbf_init+0x0/0xda()
Calling initcall 0xffffffff80a18210: i8237A_init_sysfs+0x0/0x22()
Calling initcall 0xffffffff80a18959: mce_init_device+0x0/0x78()
Calling initcall 0xffffffff80a18870: periodic_mcheck_init+0x0/0x27()
Calling initcall 0xffffffff80a189d1: thermal_throttle_init_device+0x0/0x9b()
Calling initcall 0xffffffff80a18a6c: threshold_init_device+0x0/0x4a()
Calling initcall 0xffffffff80a19c03: msr_init+0x0/0x100()
Calling initcall 0xffffffff80a19d03: cpuid_init+0x0/0x100()
Calling initcall 0xffffffff80a1a353: init_lapic_sysfs+0x0/0x37()
Calling initcall 0xffffffff80a1aebb: ioapic_init_sysfs+0x0/0xb3()
Calling initcall 0xffffffff80a1e717: audit_classes_init+0x0/0x8d()
Calling initcall 0xffffffff8022362d: cache_sysfs_init+0x0/0x5b()
Calling initcall 0xffffffff80a1e9a2: add_pcspkr+0x0/0x43()
Calling initcall 0xffffffff80a1ec6d: x8664_sysctl_init+0x0/0x14()
Calling initcall 0xffffffff80a208c7: aes_init+0x0/0x318()
Calling initcall 0xffffffff80a20bdf: init+0x0/0x12()
Calling initcall 0xffffffff80a20c03: ia32_binfmt_init+0x0/0x14()
Calling initcall 0xffffffff80a20c17: init_syscall32+0x0/0xba()
Calling initcall 0xffffffff80a21782: create_proc_profile+0x0/0x34f()
Calling initcall 0xffffffff80a21b59: ioresources_init+0x0/0x42()
Calling initcall 0xffffffff80a21c85: timekeeping_init_device+0x0/0x22()
Calling initcall 0xffffffff80a21dc1: uid_cache_init+0x0/0x8c()
Calling initcall 0xffffffff80a22205: init_posix_timers+0x0/0x94()
Calling initcall 0xffffffff80a222c4: init_posix_cpu_timers+0x0/0x69()
Calling initcall 0xffffffff80a2235b: latency_init+0x0/0x23()
Calling initcall 0xffffffff80a22390: init_clocksource_sysfs+0x0/0x50()
Calling initcall 0xffffffff80a22474: init_jiffies_clocksource+0x0/0x12()
Calling initcall 0xffffffff80a22486: init_timer_list_procfs+0x0/0x2f()
Calling initcall 0xffffffff80a22503: init_tstats_procfs+0x0/0x2f()
Calling initcall 0xffffffff80a22532: init+0x0/0x86()
Calling initcall 0xffffffff80253e98: init_rttest+0x0/0x14e()
Initializing RT-Tester: OK
Calling initcall 0xffffffff80a225b8: proc_dma_init+0x0/0x25()
Calling initcall 0xffffffff802552ad: percpu_modinit+0x0/0x76()
Calling initcall 0xffffffff80a225dd: kallsyms_init+0x0/0x28()
Calling initcall 0xffffffff80a226bb: snapshot_device_init+0x0/0x12()
Calling initcall 0xffffffff80a226cd: crash_notes_memory_init+0x0/0x3d()
Calling initcall 0xffffffff80a228ef: audit_init+0x0/0x121()
audit: initializing netlink socket (disabled)
audit(1174901870.063:1): initialized
Calling initcall 0xffffffff80a22a95: init_kprobes+0x0/0x52()
Calling initcall 0xffffffff80a22bd9: relay_init+0x0/0x14()
Calling initcall 0xffffffff80a22bed: utsname_sysctl_init+0x0/0x14()
Calling initcall 0xffffffff80a24017: init_per_zone_pages_min+0x0/0x41()
Calling initcall 0xffffffff80a24af6: pdflush_init+0x0/0x1a()
Calling initcall 0xffffffff80a24b3c: kswapd_init+0x0/0x72()
Calling initcall 0xffffffff80a24bae: setup_vmstat+0x0/0x19()
Calling initcall 0xffffffff80a24c0b: procswaps_init+0x0/0x25()
Calling initcall 0xffffffff80a24c63: hugetlb_init+0x0/0x69()
Total HugeTLB memory allocated, 0
Calling initcall 0xffffffff80a24dc1: init_tmpfs+0x0/0xc6()
Calling initcall 0xffffffff80a24f1a: cpucache_init+0x0/0x38()
Calling initcall 0xffffffff80a2542a: fasync_init+0x0/0x2d()
Calling initcall 0xffffffff80a25a58: aio_setup+0x0/0x69()
Calling initcall 0xffffffff80a25c96: inotify_setup+0x0/0x12()
Calling initcall 0xffffffff80a25ca8: inotify_user_setup+0x0/0xbc()
Calling initcall 0xffffffff80a25d64: eventpoll_init+0x0/0xcf()
Calling initcall 0xffffffff80a25e33: init_sys32_ioctl+0x0/0x95()
Calling initcall 0xffffffff80a25f28: init_mbcache+0x0/0x20()
Calling initcall 0xffffffff80a25f48: dquot_init+0x0/0xea()
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
Calling initcall 0xffffffff80a26032: init_v2_quota_format+0x0/0x12()
Calling initcall 0xffffffff80a26044: dnotify_init+0x0/0x2d()
Calling initcall 0xffffffff80a264c9: init_devpts_fs+0x0/0x3a()
Calling initcall 0xffffffff80a26503: init_ext3_fs+0x0/0x6b()
Calling initcall 0xffffffff80a2661e: journal_init+0x0/0xbc()
Calling initcall 0xffffffff80a266da: init_ext2_fs+0x0/0x6a()
Calling initcall 0xffffffff80a26778: init_ramfs_fs+0x0/0x12()
Calling initcall 0xffffffff80a2679c: init_hugetlbfs_fs+0x0/0x7f()
Calling initcall 0xffffffff80a2681b: init_iso9660_fs+0x0/0x6e()
Calling initcall 0xffffffff80a268f4: init_nls_cp437+0x0/0x12()
Calling initcall 0xffffffff80a26906: init_nls_ascii+0x0/0x12()
Calling initcall 0xffffffff80a2695f: ipc_init+0x0/0x17()
Calling initcall 0xffffffff80a26bbf: ipc_sysctl_init+0x0/0x14()
Calling initcall 0xffffffff80a26bd3: init_mqueue_fs+0x0/0xcf()
Calling initcall 0xffffffff80a26dff: key_proc_init+0x0/0x55()
Calling initcall 0xffffffff80a26fb8: selinux_nf_ip_init+0x0/0x56()
Calling initcall 0xffffffff80a2717e: init_sel_fs+0x0/0x5d()
Calling initcall 0xffffffff80a271db: selnl_init+0x0/0x42()
Calling initcall 0xffffffff80a2721d: sel_netif_init+0x0/0x67()
Calling initcall 0xffffffff80a27284: aurule_init+0x0/0x37()
Calling initcall 0xffffffff80a272bb: crypto_algapi_init+0x0/0xd()
Calling initcall 0xffffffff80a272eb: cryptomgr_init+0x0/0x12()
Calling initcall 0xffffffff80a272fd: hmac_module_init+0x0/0x12()
Calling initcall 0xffffffff80a2730f: crypto_xcbc_module_init+0x0/0x12()
Calling initcall 0xffffffff80a27321: init+0x0/0x5a()
Calling initcall 0xffffffff80a2737b: init+0x0/0x12()
Calling initcall 0xffffffff80a2738d: init+0x0/0x12()
Calling initcall 0xffffffff80a2739f: init+0x0/0x12()
Calling initcall 0xffffffff80a273b1: init+0x0/0x12()
Calling initcall 0xffffffff80a273c3: init+0x0/0x3c()
Calling initcall 0xffffffff80a273ff: init+0x0/0x61()
Calling initcall 0xffffffff80a27460: init+0x0/0x61()
Calling initcall 0xffffffff80a274c1: crypto_ecb_module_init+0x0/0x12()
Calling initcall 0xffffffff80a274d3: crypto_cbc_module_init+0x0/0x12()
Calling initcall 0xffffffff80a274e5: crypto_module_init+0x0/0x12()
Calling initcall 0xffffffff80a274f7: init+0x0/0x3c()
Calling initcall 0xffffffff80a27533: init+0x0/0x12()
Calling initcall 0xffffffff80a27545: init+0x0/0x12()
Calling initcall 0xffffffff80a27557: init+0x0/0x3c()
Calling initcall 0xffffffff80a27593: aes_init+0x0/0x31a()
Calling initcall 0xffffffff80a278ad: init+0x0/0x12()
Calling initcall 0xffffffff80a278bf: init+0x0/0x12()
Calling initcall 0xffffffff80a278d1: arc4_init+0x0/0x12()
Calling initcall 0xffffffff80a278e3: init+0x0/0x61()
Calling initcall 0xffffffff80a27944: init+0x0/0x12()
Calling initcall 0xffffffff80a27956: init+0x0/0x12()
Calling initcall 0xffffffff80a27968: init+0x0/0x12()
Calling initcall 0xffffffff80a2797a: michael_mic_init+0x0/0x12()
Calling initcall 0xffffffff80a2798c: init+0x0/0x12()
Calling initcall 0xffffffff80a27b89: noop_init+0x0/0x12()
io scheduler noop registered
Calling initcall 0xffffffff80a27b9b: as_init+0x0/0x12()
io scheduler anticipatory registered
Calling initcall 0xffffffff80a27bad: deadline_init+0x0/0x12()
io scheduler deadline registered
Calling initcall 0xffffffff80a27bbf: cfq_init+0x0/0xa6()
io scheduler cfq registered (default)
Calling initcall 0xffffffff80a27c65: blk_trace_init+0x0/0xf8()
Calling initcall 0xffffffff80369039: pci_init+0x0/0x34()
PCI: Found disabled HT MSI Mapping on 0000:00:0b.0
PCI: Found enabled HT MSI Mapping on 0000:00:00.0
PCI: Linking AER extended capability on 0000:00:0b.0
PCI: Found disabled HT MSI Mapping on 0000:00:0c.0
PCI: Found enabled HT MSI Mapping on 0000:00:00.0
PCI: Linking AER extended capability on 0000:00:0c.0
PCI: Found disabled HT MSI Mapping on 0000:00:0d.0
PCI: Found enabled HT MSI Mapping on 0000:00:00.0
PCI: Linking AER extended capability on 0000:00:0d.0
PCI: Found disabled HT MSI Mapping on 0000:00:0e.0
PCI: Found enabled HT MSI Mapping on 0000:00:00.0
PCI: Linking AER extended capability on 0000:00:0e.0
Calling initcall 0xffffffff80a28711: pci_sysfs_init+0x0/0x3b()
Calling initcall 0xffffffff80a2874c: pci_proc_init+0x0/0x6f()
Calling initcall 0xffffffff80a287bb: pcie_portdrv_init+0x0/0x49()
PCI: Setting latency timer of device 0000:00:0b.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0b.0:pcie00]
Allocate Port Service[0000:00:0b.0:pcie03]
PCI: Setting latency timer of device 0000:00:0c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0c.0:pcie00]
Allocate Port Service[0000:00:0c.0:pcie03]
PCI: Setting latency timer of device 0000:00:0d.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0d.0:pcie00]
Allocate Port Service[0000:00:0d.0:pcie03]
PCI: Setting latency timer of device 0000:00:0e.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0e.0:pcie00]
Allocate Port Service[0000:00:0e.0:pcie03]
Calling initcall 0xffffffff80a28804: aer_service_init+0x0/0x12()
Calling initcall 0xffffffff80a28816: pci_hotplug_init+0x0/0x59()
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
Calling initcall 0xffffffff80a2886f: acpiphp_init+0x0/0x51()
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
Calling initcall 0xffffffff80a28a6b: ibm_acpiphp_init+0x0/0x167()
acpiphp_ibm: ibm_find_acpi_device:  Failed to get device information<3>acpiphp_ibm: ibm_find_acpi_device:  Failed to get device information<3>acpiphp_ibm: ibm_acpiphp_init: acpi_walk_namespace failed
Calling initcall 0xffffffff80a28fc3: fb_console_init+0x0/0x115()
Calling initcall 0xffffffff80a2979c: vesafb_init+0x0/0x235()
Calling initcall 0xffffffff80a29d87: acpi_reserve_resources+0x0/0xf1()
Calling initcall 0xffffffff80a2a7c2: acpi_ac_init+0x0/0x45()
Calling initcall 0xffffffff80a2a807: acpi_battery_init+0x0/0x45()
Calling initcall 0xffffffff80a2a84c: acpi_button_init+0x0/0x5e()
input: Power Button (FF) as /class/input/input0
ACPI: Power Button (FF) [PWRF]
input: Power Button (CM) as /class/input/input1
ACPI: Power Button (CM) [PWRB]
Calling initcall 0xffffffff80a2acb6: acpi_fan_init+0x0/0x5e()
ACPI: Fan [FAN] (on)
Calling initcall 0xffffffff80a2ad65: acpi_video_init+0x0/0x5e()
Calling initcall 0xffffffff80a2aea0: irqrouter_init_sysfs+0x0/0x38()
Calling initcall 0xffffffff80a2b038: acpi_processor_init+0x0/0xdf()
Calling initcall 0xffffffff80a2b117: acpi_container_init+0x0/0x40()
Calling initcall 0xffffffff80a2b157: acpi_thermal_init+0x0/0x5e()
ACPI: Thermal Zone [THRM] (40 C)
Calling initcall 0xffffffff80a2b3ce: asus_acpi_init+0x0/0xe7()
Calling initcall 0xffffffff80a2b5c8: acpi_ibm_init+0x0/0x71b()
ibm_acpi: ec object not found
Calling initcall 0xffffffff80a2bce3: toshiba_acpi_init+0x0/0x183()
Calling initcall 0xffffffff80a2c467: rand_initialize+0x0/0x2c()
Calling initcall 0xffffffff80a2c4f2: tty_init+0x0/0x1c5()
Calling initcall 0xffffffff80a2c6b7: pty_init+0x0/0x281()
Calling initcall 0xffffffff80a2cf41: rtc_init+0x0/0x185()
Real Time Clock Driver v1.12ac
Calling initcall 0xffffffff80a2d0c6: nvram_init+0x0/0x89()
Non-volatile memory driver v1.2
Calling initcall 0xffffffff80a2d14f: agp_init+0x0/0x26()
Linux agpgart interface v0.102 (c) Dave Jones
Calling initcall 0xffffffff80a2d27f: agp_intel_init+0x0/0x29()
Calling initcall 0xffffffff80a2d2a8: agp_sis_init+0x0/0x29()
Calling initcall 0xffffffff80a2d2d1: agp_via_init+0x0/0x29()
Calling initcall 0xffffffff80a2d2fa: cn_proc_init+0x0/0x3a()
Calling initcall 0xffffffff80a2d7cf: serial8250_init+0x0/0x12c()
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
�serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Calling initcall 0xffffffff80a2d8fb: serial8250_pnp_init+0x0/0x12()
00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Calling initcall 0xffffffff80a2d90d: serial8250_pci_init+0x0/0x1b()
Calling initcall 0xffffffff803e6d69: topology_sysfs_init+0x0/0x4a()
Calling initcall 0xffffffff80a2e012: rd_init+0x0/0x1ab()
RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize
Calling initcall 0xffffffff80a2e1fc: e1000_init_module+0x0/0x84()
Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI
Copyright (c) 1999-2006 Intel Corporation.
Calling initcall 0xffffffff80a2e280: e100_init_module+0x0/0x62()
e100: Intel(R) PRO/100 Network Driver, 3.5.17-k2-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
Calling initcall 0xffffffff80a2e2e2: sky2_init_module+0x0/0x1b()
Calling initcall 0xffffffff80a2e34f: net_olddevs_init+0x0/0xa9()
Calling initcall 0xffffffff80a2e3f8: loopback_init+0x0/0x12()
Calling initcall 0xffffffff80a2e40a: init_nic+0x0/0x30()
forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.60.
ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LMAC] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:00:0a.0 to 64
forcedeth: using HIGHDMA
eth0: forcedeth.c: subsystem: 01043:8141 bound to 0000:00:0a.0
Calling initcall 0xffffffff80a2e43a: aec62xx_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e455: ali15x3_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e470: amd74xx_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e48b: atiixp_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e4a6: cmd64x_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e4c1: hpt34x_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e4dc: hpt366_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e4f7: it821x_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e512: pdc202xx_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e52d: pdc202new_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e548: piix_ide_init+0x0/0xc9()
Calling initcall 0xffffffff80a2e611: svwks_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e62c: siimage_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e647: sis5513_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e662: via_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e6a0: generic_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2edc0: ide_init+0x0/0x8f()
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
NFORCE-CK804: IDE controller at PCI slot 0000:00:06.0
NFORCE-CK804: chipset revision 242
NFORCE-CK804: not 100% native mode: will probe irqs later
NFORCE-CK804: 0000:00:06.0 (rev f2) UDMA133 controller
    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
hda: MAXTOR 6L040J2, ATA DISK drive
hdb: ST380011A, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
Calling initcall 0xffffffff80a2ef64: ide_generic_init+0x0/0x12()
Probing IDE interface ide1...
Calling initcall 0xffffffff80a2ef76: idedisk_init+0x0/0x12()
hda: max request size: 128KiB
hda: 78177792 sectors (40027 MB) w/1818KiB Cache, CHS=65535/16/63, UDMA(133)
hda: cache flushes supported
 hda: hda1 hda2 hda3 hda4 < hda5 >
hdb: max request size: 512KiB
hdb: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100)
hdb: cache flushes supported
 hdb: hdb1 hdb2 hdb3 < hdb5 >
Calling initcall 0xffffffff80a2ef88: idefloppy_init+0x0/0x20()
ide-floppy driver 0.99.newide
Calling initcall 0xffffffff80a2f216: init_sd+0x0/0xf5()
Calling initcall 0xffffffff80a2f30b: init_sg+0x0/0x15d()
Calling initcall 0xffffffff80a2f4f0: ahci_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f50b: k2_sata_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f526: piix_init+0x0/0x2c()
Calling initcall 0xffffffff80a2f552: pdc_ata_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f56d: qs_ata_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f588: sil_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f5a3: sil24_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f5be: svia_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f5d9: vsc_sata_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f5f4: sis_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f60f: pdc_sata_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f62a: nv_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f645: uli_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f660: mv_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f67b: adma_ata_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f696: ali_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f6b1: amd_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f6cc: artop_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f6e7: atiixp_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f702: cmd64x_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f71d: cs5520_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f738: cs5530_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f753: cy82c693_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f76e: efar_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f789: hpt36x_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f7a4: hpt37x_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f7bf: hpt3x2n_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f7da: hpt3x3_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f7f5: it821x_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f810: jmicron_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f82b: netcell_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f846: ns87410_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f861: opti_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f87c: optidma_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f897: marvell_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f8b2: mpiix_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f8cd: oldpiix_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f8e8: pcmcia_init+0x0/0x12()
Calling initcall 0xffffffff80a2f8fa: pdc2027x_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f915: pdc202xx_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f930: radisys_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f94b: rz1000_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f966: sc1200_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f981: serverworks_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f99c: sil680_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f9b7: via_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f9d2: sl82c105_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f9ed: sis_init+0x0/0x1b()
Calling initcall 0xffffffff80a2fa08: triflex_init+0x0/0x1b()
Calling initcall 0xffffffff80a2fa23: ata_generic_init+0x0/0x1b()
Calling initcall 0xffffffff80a2fb6d: nonstatic_sysfs_init+0x0/0x12()
Calling initcall 0xffffffff80a2fb7f: yenta_socket_init+0x0/0x1b()
Calling initcall 0xffffffff80a2fb9a: kvm_init+0x0/0x177()
Calling initcall 0xffffffff80a2fd2a: vmx_init+0x0/0x14()
kvm: no hardware support
initcall at 0xffffffff80a2fd2a: vmx_init+0x0/0x14(): returned with error code -95
Calling initcall 0xffffffff80a2fe01: svm_init+0x0/0x14()
has_svm: svm not available
kvm: no hardware support
initcall at 0xffffffff80a2fe01: svm_init+0x0/0x14(): returned with error code -95
Calling initcall 0xffffffff80a303d9: mon_init+0x0/0xa7()
Calling initcall 0xffffffff80a30544: usb_usual_init+0x0/0x30()
usbcore: registered new interface driver libusual
Calling initcall 0xffffffff80a305ff: i8042_init+0x0/0x2ff()
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
Calling initcall 0xffffffff80a308fe: serport_init+0x0/0x31()
Calling initcall 0xffffffff80a30a52: mousedev_init+0x0/0xc2()
mice: PS/2 mouse device common for all mice
Calling initcall 0xffffffff80a30b14: evdev_init+0x0/0x12()
Calling initcall 0xffffffff80a30b26: atkbd_init+0x0/0x1b()
Calling initcall 0xffffffff80a30b41: psmouse_init+0x0/0x65()
input: AT Translated Set 2 keyboard as /class/input/input2
Calling initcall 0xffffffff80a30ba6: md_init+0x0/0xd6()
Calling initcall 0xffffffff80a30d62: ledtrig_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a33050: flow_cache_init+0x0/0x19e()
Calling initcall 0xffffffff80a332aa: llc_init+0x0/0x5b()
Calling initcall 0xffffffff80a33305: snap_init+0x0/0x31()
Calling initcall 0xffffffff80a33336: rif_init+0x0/0x77()
Calling initcall 0xffffffff80a33453: blackhole_module_init+0x0/0x12()
Calling initcall 0xffffffff80a3485a: init_syncookies+0x0/0x19()
Calling initcall 0xffffffff805069c2: ipv4_netfilter_init+0x0/0x12()
Calling initcall 0xffffffff80a34873: bictcp_register+0x0/0x12()
TCP bic registered
Calling initcall 0xffffffff80a34ae0: xfrm_user_init+0x0/0x4d()
Initializing XFRM netlink socket
Calling initcall 0xffffffff80a34b2d: af_unix_init+0x0/0x6d()
NET: Registered protocol family 1
Calling initcall 0xffffffff80a34b9a: packet_init+0x0/0x5a()
NET: Registered protocol family 17
Calling initcall 0xffffffff80a34bf4: ipsec_pfkey_init+0x0/0x94()
NET: Registered protocol family 15
Calling initcall 0xffffffff80a1a408: ioapic_insert_resources+0x0/0x4f()
Calling initcall 0xffffffff80a1abf1: init_lapic_nmi_sysfs+0x0/0x38()
Calling initcall 0xffffffff8021e003: powernowk8_init+0x0/0x88()
powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ processors (version 2.00.00)
powernow-k8: BIOS error - no PSB or ACPI _PSS objects
------------[ cut here ]------------
kernel BUG at drivers/cpufreq/cpufreq.c:82!
invalid opcode: 0000 [1] PREEMPT SMP 
CPU 0 
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.21-rc5 #14
RIP: 0010:[<ffffffff804a0edd>]  [<ffffffff804a0edd>] lock_policy_rwsem_write+0x2b/0x7f
RSP: 0000:ffff81003ff31de0  EFLAGS: 00010246
RAX: 00000000ffffffff RBX: ffffffff80aa46a8 RCX: 0000000000000000
RDX: ffffffff80741080 RSI: 0000000000000202 RDI: 0000000000000001
RBP: ffff81003ff31e00 R08: ffff81003ff30000 R09: ffff810002dfdab0
R10: ffff810002dfdab0 R11: ffff810002dfdab0 R12: 0000000000000001
R13: ffffffff806cc2c0 R14: ffffffff80a37920 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffffffff80741000(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000f06f53 CR3: 0000000000201000 CR4: 00000000000006e0
Process swapper (pid: 1, threadinfo ffff81003ff30000, task ffff81003ff2a790)
Stack:  ffffffff806cc2c0 ffffffff80aa46a8 ffffffff80aa46a8 ffffffff806cc2c0
 ffff81003ff31e20 ffffffff804a1538 ffff810002dfdab0 ffffffff806f6a40
 ffff81003ff31e50 ffffffff803dffdf 00000000ffffffed 00000000ffffffed
Call Trace:
 [<ffffffff804a1538>] cpufreq_remove_dev+0x11/0x26
 [<ffffffff803dffdf>] sysdev_driver_unregister+0x52/0x98
 [<ffffffff804a0d3b>] cpufreq_register_driver+0x12d/0x191
 [<ffffffff8021e082>] powernowk8_init+0x7f/0x88
 [<ffffffff80a1099e>] init+0x1a8/0x2a9
 [<ffffffff8023294e>] schedule_tail+0x36/0x9a
 [<ffffffff8020ab98>] child_rip+0xa/0x12
 [<ffffffff80a107f6>] init+0x0/0x2a9
 [<ffffffff8020ab8e>] child_rip+0x0/0x12


Code: 0f 0b eb fe 4c 63 e8 48 c7 c3 a0 c1 a6 80 4a 8b 04 ed c0 7a 
RIP  [<ffffffff804a0edd>] lock_policy_rwsem_write+0x2b/0x7f
 RSP <ffff81003ff31de0>
Kernel panic - not syncing: Attempted to kill init!


[-- Attachment #2: config.bz2 --]
[-- Type: application/x-bzip2, Size: 16956 bytes --]

^ permalink raw reply	[flat|nested] 128+ messages in thread

* [PATCH] clockevents: remove bad designed sysfs support for now
  2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
                   ` (2 preceding siblings ...)
  2007-03-26  9:04 ` 2.6.21-rc5: maxcpus=1 crash in cpufreq: kernel BUG at drivers/cpufreq/cpufreq.c:82! Ingo Molnar
@ 2007-03-26  9:21 ` Thomas Gleixner
  2007-03-26  9:25   ` Ingo Molnar
                     ` (2 more replies)
  2007-03-26 10:11 ` -rc5: e1000 resume weirdness Ingo Molnar
                   ` (15 subsequent siblings)
  19 siblings, 3 replies; 128+ messages in thread
From: Thomas Gleixner @ 2007-03-26  9:21 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Linux Kernel Mailing List, Ingo Molnar, Greg KH, Andrew Morton

The current sysfs support of clockevents does not obey the "only one
value per file" rule.

The real fix is not 2.6.21 material. Therefor remove the sysfs support
for now.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
index 67932ea..76212b2 100644
--- a/kernel/time/clockevents.c
+++ b/kernel/time/clockevents.c
@@ -274,72 +274,3 @@ void clockevents_notify(unsigned long reason, void *arg)
 }
 EXPORT_SYMBOL_GPL(clockevents_notify);
 
-#ifdef CONFIG_SYSFS
-
-/**
- * clockevents_show_registered - sysfs interface for listing clockevents
- * @dev:	unused
- * @buf:	char buffer to be filled with clock events list
- *
- * Provides sysfs interface for listing registered clock event devices
- */
-static ssize_t clockevents_show_registered(struct sys_device *dev, char *buf)
-{
-	struct list_head *tmp;
-	char *p = buf;
-	int cpu;
-
-	spin_lock(&clockevents_lock);
-
-	list_for_each(tmp, &clockevent_devices) {
-		struct clock_event_device *ce;
-
-		ce = list_entry(tmp, struct clock_event_device, list);
-		p += sprintf(p, "%-20s F:%04x M:%d", ce->name,
-			     ce->features, ce->mode);
-		p += sprintf(p, " C:");
-		if (!cpus_equal(ce->cpumask, cpu_possible_map)) {
-			for_each_cpu_mask(cpu, ce->cpumask)
-				p += sprintf(p, " %d", cpu);
-		} else {
-			/*
-			 * FIXME: Add the cpu which is handling this sucker
-			 */
-		}
-		p += sprintf(p, "\n");
-	}
-
-	spin_unlock(&clockevents_lock);
-
-	return p - buf;
-}
-
-/*
- * Sysfs setup bits:
- */
-static SYSDEV_ATTR(registered, 0600,
-		   clockevents_show_registered, NULL);
-
-static struct sysdev_class clockevents_sysclass = {
-	set_kset_name("clockevents"),
-};
-
-static struct sys_device clockevents_sys_device = {
-	.id	= 0,
-	.cls	= &clockevents_sysclass,
-};
-
-static int __init clockevents_sysfs_init(void)
-{
-	int error = sysdev_class_register(&clockevents_sysclass);
-
-	if (!error)
-		error = sysdev_register(&clockevents_sys_device);
-	if (!error)
-		error = sysdev_create_file(
-				&clockevents_sys_device,
-				&attr_registered);
-	return error;
-}
-device_initcall(clockevents_sysfs_init);
-#endif



^ permalink raw reply related	[flat|nested] 128+ messages in thread

* Re: [PATCH] clockevents: remove bad designed sysfs support for now
  2007-03-26  9:21 ` [PATCH] clockevents: remove bad designed sysfs support for now Thomas Gleixner
@ 2007-03-26  9:25   ` Ingo Molnar
  2007-03-26 18:57     ` Greg KH
  2007-03-26 12:51   ` Pavel Machek
  2007-03-27  7:08   ` [PATCH] i386: Fix bogus return value in hpet_next_event() Thomas Gleixner
  2 siblings, 1 reply; 128+ messages in thread
From: Ingo Molnar @ 2007-03-26  9:25 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Linus Torvalds, Linux Kernel Mailing List, Greg KH, Andrew Morton


* Thomas Gleixner <tglx@linutronix.de> wrote:

> The current sysfs support of clockevents does not obey the "only one 
> value per file" rule.
> 
> The real fix is not 2.6.21 material. Therefor remove the sysfs support 
> for now.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Acked-by: Ingo Molnar <mingo@elte.hu>

	Ingo

^ permalink raw reply	[flat|nested] 128+ messages in thread

* -rc5: e1000 resume weirdness
  2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
                   ` (3 preceding siblings ...)
  2007-03-26  9:21 ` [PATCH] clockevents: remove bad designed sysfs support for now Thomas Gleixner
@ 2007-03-26 10:11 ` Ingo Molnar
  2007-03-26 15:39   ` Kok, Auke
  2007-03-26 15:50   ` Jesse Brandeburg
  2007-03-27  1:59 ` [1/5] 2.6.21-rc5: known regressions Adrian Bunk
                   ` (14 subsequent siblings)
  19 siblings, 2 replies; 128+ messages in thread
From: Ingo Molnar @ 2007-03-26 10:11 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List, auke-jan.h.kok, Adrian Bunk


hm, on a T60, after suspend/resume, i get an e1000 timeout:

e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
  Tx Queue             <0>
  TDH                  <ec>
  TDT                  <ec>
  next_to_use          <ec>
  next_to_clean        <82>
buffer_info[next_to_clean]
  time_stamp           <fffcc3db>
  next_to_watch        <82>
  jiffies              <fffd5da0>
  next_to_watch.status <1>

it works fine after that reset. The e1000 driver didnt do this before 
after resume the network was always available immediately. So this 
appears to be a relatively new regression (post-rc3 or so). high-res 
timers was disabled.

	Ingo

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.21-rc5
  2007-03-26  8:55 ` Linux 2.6.21-rc5 Thomas Gleixner
@ 2007-03-26 12:25   ` Bob Tracy
  2007-03-26 12:30     ` Thomas Gleixner
  0 siblings, 1 reply; 128+ messages in thread
From: Bob Tracy @ 2007-03-26 12:25 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: Linus Torvalds, Linux Kernel Mailing List, johnstul

Thomas Gleixner wrote:
> This fix from John Stultz is still missing:
> 
> http://lkml.org/lkml/2007/3/22/287
> 
> It's in Andrews queue already and waits to be sent to you.

In summary, that fix is a workaround to allow the acpi_pm clocksource
to be selected instead of the pit clocksource, thereby allowing my
Dell laptop with the PIIX4 bug to boot.  Other apic, clocksource, etc.
patches that were included in -rc5 fixed the problem that caused the
boot process to hang when the pit clocksource was selected, as I
suspected would be the case :-).

Per John's message in the above URL, while the fix is no longer needed
for allowing the laptop to boot, it's probably still "a good thing" to
allow a better clocksource to be selected.

-- 
-----------------------------------------------------------------------
Bob Tracy                   WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.21-rc5
  2007-03-26 12:25   ` Bob Tracy
@ 2007-03-26 12:30     ` Thomas Gleixner
  0 siblings, 0 replies; 128+ messages in thread
From: Thomas Gleixner @ 2007-03-26 12:30 UTC (permalink / raw)
  To: Bob Tracy; +Cc: Linus Torvalds, Linux Kernel Mailing List, johnstul

On Mon, 2007-03-26 at 07:25 -0500, Bob Tracy wrote:
> Thomas Gleixner wrote:
> > This fix from John Stultz is still missing:
> > 
> > http://lkml.org/lkml/2007/3/22/287
> > 
> > It's in Andrews queue already and waits to be sent to you.
> 
> In summary, that fix is a workaround to allow the acpi_pm clocksource
> to be selected instead of the pit clocksource, thereby allowing my
> Dell laptop with the PIIX4 bug to boot.  Other apic, clocksource, etc.
> patches that were included in -rc5 fixed the problem that caused the
> boot process to hang when the pit clocksource was selected, as I
> suspected would be the case :-).

Ah. Ok

> Per John's message in the above URL, while the fix is no longer needed
> for allowing the laptop to boot, it's probably still "a good thing" to
> allow a better clocksource to be selected.

Yes. The read three times pmtimer is faster and more reliable than the
PIT.

	tglx




^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [PATCH] clockevents: remove bad designed sysfs support for now
  2007-03-26  9:21 ` [PATCH] clockevents: remove bad designed sysfs support for now Thomas Gleixner
  2007-03-26  9:25   ` Ingo Molnar
@ 2007-03-26 12:51   ` Pavel Machek
  2007-03-27  7:08   ` [PATCH] i386: Fix bogus return value in hpet_next_event() Thomas Gleixner
  2 siblings, 0 replies; 128+ messages in thread
From: Pavel Machek @ 2007-03-26 12:51 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Linus Torvalds, Linux Kernel Mailing List, Ingo Molnar, Greg KH,
	Andrew Morton

On Mon 2007-03-26 11:21:08, Thomas Gleixner wrote:
> The current sysfs support of clockevents does not obey the "only one
> value per file" rule.
> 
> The real fix is not 2.6.21 material. Therefor remove the sysfs support
> for now.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Thanks!

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: -rc5: e1000 resume weirdness
  2007-03-26 10:11 ` -rc5: e1000 resume weirdness Ingo Molnar
@ 2007-03-26 15:39   ` Kok, Auke
  2007-03-26 15:50   ` Jesse Brandeburg
  1 sibling, 0 replies; 128+ messages in thread
From: Kok, Auke @ 2007-03-26 15:39 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Linus Torvalds, Linux Kernel Mailing List, Adrian Bunk

Ingo Molnar wrote:
> hm, on a T60, after suspend/resume, i get an e1000 timeout:
> 
> e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
> e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
>   Tx Queue             <0>
>   TDH                  <ec>
>   TDT                  <ec>
>   next_to_use          <ec>
>   next_to_clean        <82>
> buffer_info[next_to_clean]
>   time_stamp           <fffcc3db>
>   next_to_watch        <82>
>   jiffies              <fffd5da0>
>   next_to_watch.status <1>
> 
> it works fine after that reset. The e1000 driver didnt do this before 
> after resume the network was always available immediately. So this 
> appears to be a relatively new regression (post-rc3 or so). high-res 
> timers was disabled.
> 
> 	Ingo

THT == TDH -> this is a 'bogus' tx hang indicating that one or more parts
in the TX patch is not properly enabled.

Most likely, I suspect that we haven't enabled something because the ordering
of irq free/alloc was messed up and nobody cared before, but with all the
pci_save_state fixes going in we hit a bump.

The reset kicks it all back up in order so it's something silly like this for
sure.

The attached patch fixes that and sitting in my queue for a few days. Can you
see if that works?

Auke


---
e1000: Free interrupts symmetrically with resume

From: Auke Kok <auke-jan.h.kok@intel.com>

Free interrupts symmetrically with resume allocation to prevent
pci save/restore state from possibly failing or warning.

Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---

 drivers/net/e1000/e1000_main.c |    4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 55ef148..93d41f0 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -5190,6 +5190,7 @@ e1000_suspend(struct pci_dev *pdev, pm_message_t state)
 	if (netif_running(netdev)) {
 		WARN_ON(test_bit(__E1000_RESETTING, &adapter->flags));
 		e1000_down(adapter);
+		e1000_free_irq(adapter);
 	}
 
 #ifdef CONFIG_PM
@@ -5257,9 +5258,6 @@ e1000_suspend(struct pci_dev *pdev, pm_message_t state)
 	if (adapter->hw.phy.type == e1000_phy_igp_3)
 		e1000_igp3_phy_powerdown_workaround_ich8lan(&adapter->hw);
 
-	if (netif_running(netdev))
-		e1000_free_irq(adapter);
-
 	/* Release control of h/w to f/w.  If f/w is AMT enabled, this
 	 * would have already happened in close and is redundant. */
 	e1000_release_hw_control(adapter);

^ permalink raw reply related	[flat|nested] 128+ messages in thread

* Re: -rc5: e1000 resume weirdness
  2007-03-26 10:11 ` -rc5: e1000 resume weirdness Ingo Molnar
  2007-03-26 15:39   ` Kok, Auke
@ 2007-03-26 15:50   ` Jesse Brandeburg
  2007-03-26 15:55     ` Kok, Auke
  2007-03-26 17:39     ` Ingo Molnar
  1 sibling, 2 replies; 128+ messages in thread
From: Jesse Brandeburg @ 2007-03-26 15:50 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Linus Torvalds, Linux Kernel Mailing List, auke-jan.h.kok, Adrian Bunk

On 3/26/07, Ingo Molnar <mingo@elte.hu> wrote:
>
> hm, on a T60, after suspend/resume, i get an e1000 timeout:
>
> e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
> e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
>   Tx Queue             <0>
>   TDH                  <ec>
>   TDT                  <ec>
>   next_to_use          <ec>
>   next_to_clean        <82>
> buffer_info[next_to_clean]
>   time_stamp           <fffcc3db>
>   next_to_watch        <82>
>   jiffies              <fffd5da0>
>   next_to_watch.status <1>
>
> it works fine after that reset. The e1000 driver didnt do this before
> after resume the network was always available immediately. So this
> appears to be a relatively new regression (post-rc3 or so). high-res
> timers was disabled.

was there a "NETDEV WATCHDOG" message that follows this?  If not it is
a harmless debug print.  Note the time_stamp and jiffies difference,
very large, consistent with a resume.  I think we need to disable the
internal e1000 tx hang code that causes this debug print when we are
suspending.  I'll work with auke to generate a short patch.

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: -rc5: e1000 resume weirdness
  2007-03-26 15:50   ` Jesse Brandeburg
@ 2007-03-26 15:55     ` Kok, Auke
  2007-03-26 17:39     ` Ingo Molnar
  1 sibling, 0 replies; 128+ messages in thread
From: Kok, Auke @ 2007-03-26 15:55 UTC (permalink / raw)
  To: Jesse Brandeburg
  Cc: Ingo Molnar, Linus Torvalds, Linux Kernel Mailing List, Adrian Bunk

Jesse Brandeburg wrote:
> On 3/26/07, Ingo Molnar <mingo@elte.hu> wrote:
>> hm, on a T60, after suspend/resume, i get an e1000 timeout:
>>
>> e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
>> e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
>>   Tx Queue             <0>
>>   TDH                  <ec>
>>   TDT                  <ec>
>>   next_to_use          <ec>
>>   next_to_clean        <82>
>> buffer_info[next_to_clean]
>>   time_stamp           <fffcc3db>
>>   next_to_watch        <82>
>>   jiffies              <fffd5da0>
>>   next_to_watch.status <1>
>>
>> it works fine after that reset. The e1000 driver didnt do this before
>> after resume the network was always available immediately. So this
>> appears to be a relatively new regression (post-rc3 or so). high-res
>> timers was disabled.
> 
> was there a "NETDEV WATCHDOG" message that follows this?  If not it is
> a harmless debug print.  Note the time_stamp and jiffies difference,
> very large, consistent with a resume.  I think we need to disable the
> internal e1000 tx hang code that causes this debug print when we are
> suspending.  I'll work with auke to generate a short patch.

hmm, yeah, it appears that the patch I sent just a second ago isn't applicable 
in this case, since the irq handler is obviously enabled (the Link Up message 
proves that).

thanks to Jesse for being awake :)


Auke

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: -rc5: e1000 resume weirdness
  2007-03-26 15:50   ` Jesse Brandeburg
  2007-03-26 15:55     ` Kok, Auke
@ 2007-03-26 17:39     ` Ingo Molnar
  1 sibling, 0 replies; 128+ messages in thread
From: Ingo Molnar @ 2007-03-26 17:39 UTC (permalink / raw)
  To: Jesse Brandeburg
  Cc: Linus Torvalds, Linux Kernel Mailing List, auke-jan.h.kok, Adrian Bunk


* Jesse Brandeburg <jesse.brandeburg@gmail.com> wrote:

> was there a "NETDEV WATCHDOG" message that follows this?  If not it is 
> a harmless debug print.  Note the time_stamp and jiffies difference, 
> very large, consistent with a resume.  I think we need to disable the 
> internal e1000 tx hang code that causes this debug print when we are 
> suspending.  I'll work with auke to generate a short patch.

there was no "NETDEV WATCHDOG" message. But still there was a ~30 
seconds delay until i got the first few packets through the interface - 
while normally it's available almost instantly after resume. But ... 
this condition seems sporadic, i havent seen it on subsequent 
suspend+resume attempts.

	Ingo

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: 2.6.21-rc5: maxcpus=1 crash in cpufreq: kernel BUG at drivers/cpufreq/cpufreq.c:82!
  2007-03-26  9:04 ` 2.6.21-rc5: maxcpus=1 crash in cpufreq: kernel BUG at drivers/cpufreq/cpufreq.c:82! Ingo Molnar
@ 2007-03-26 18:12   ` Venki Pallipadi
  2007-03-26 19:03     ` Venki Pallipadi
  0 siblings, 1 reply; 128+ messages in thread
From: Venki Pallipadi @ 2007-03-26 18:12 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Linus Torvalds, Linux Kernel Mailing List, Dave Jones


On Mar 26, 2007, at 2:04 AM, Ingo Molnar wrote:

>
> trying to debug the forcedeth crash triggered another, new
> v2.6.20 -> v2.6.21 regression:
>
> maxcpus=1 on a dual-core system crashes the x86_64 SMP kernel in
> lock_policy_rwsem_write() - see the crash log below. Config attached.
>
> i suspect it could be related to this recent commit:
>
>  commit 5a01f2e8f3ac134e24144d74bb48a60236f7024d
>  Author: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
>  Date:   Mon Feb 5 16:12:44 2007 -0800
>
>     [CPUFREQ] Rewrite lock in cpufreq to eliminate cpufreq/hotplug  
> related issue
>
> 	Ingo
> Calling initcall 0xffffffff8021e003: powernowk8_init+0x0/0x88()
> powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+  
> processors (version 2.00.00)
> powernow-k8: BIOS error - no PSB or ACPI _PSS objects
> ------------[ cut here ]------------
> kernel BUG at drivers/cpufreq/cpufreq.c:82!
> invalid opcode: 0000 [1] PREEMPT SMP
> CPU 0
> Modules linked in:
> Pid: 1, comm: swapper Not tainted 2.6.21-rc5 #14
> RIP: 0010:[<ffffffff804a0edd>]  [<ffffffff804a0edd>]  
> lock_policy_rwsem_write+0x2b/0x7f
> RSP: 0000:ffff81003ff31de0  EFLAGS: 00010246
> RAX: 00000000ffffffff RBX: ffffffff80aa46a8 RCX: 0000000000000000
> RDX: ffffffff80741080 RSI: 0000000000000202 RDI: 0000000000000001
> RBP: ffff81003ff31e00 R08: ffff81003ff30000 R09: ffff810002dfdab0
> R10: ffff810002dfdab0 R11: ffff810002dfdab0 R12: 0000000000000001
> R13: ffffffff806cc2c0 R14: ffffffff80a37920 R15: 0000000000000000
> FS:  0000000000000000(0000) GS:ffffffff80741000(0000) knlGS: 
> 0000000000000000
> CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> CR2: 0000000000f06f53 CR3: 0000000000201000 CR4: 00000000000006e0
> Process swapper (pid: 1, threadinfo ffff81003ff30000, task  
> ffff81003ff2a790)
> Stack:  ffffffff806cc2c0 ffffffff80aa46a8 ffffffff80aa46a8  
> ffffffff806cc2c0
>  ffff81003ff31e20 ffffffff804a1538 ffff810002dfdab0 ffffffff806f6a40
>  ffff81003ff31e50 ffffffff803dffdf 00000000ffffffed 00000000ffffffed
> Call Trace:
>  [<ffffffff804a1538>] cpufreq_remove_dev+0x11/0x26
>  [<ffffffff803dffdf>] sysdev_driver_unregister+0x52/0x98
>  [<ffffffff804a0d3b>] cpufreq_register_driver+0x12d/0x191
>  [<ffffffff8021e082>] powernowk8_init+0x7f/0x88
>  [<ffffffff80a1099e>] init+0x1a8/0x2a9
>  [<ffffffff8023294e>] schedule_tail+0x36/0x9a
>  [<ffffffff8020ab98>] child_rip+0xa/0x12
>  [<ffffffff80a107f6>] init+0x0/0x2a9
>  [<ffffffff8020ab8e>] child_rip+0x0/0x12
>
>
> Code: 0f 0b eb fe 4c 63 e8 48 c7 c3 a0 c1 a6 80 4a 8b 04 ed c0 7a
> RIP  [<ffffffff804a0edd>] lock_policy_rwsem_write+0x2b/0x7f
>  RSP <ffff81003ff31de0>
> Kernel panic - not syncing: Attempted to kill init!
>

Looks like some error with cpufreq add_dev and remove_dev got exposed  
by the above patch.

The problem here is:

cpufreq_register_driver() calls sysdev_driver_register()
which in turn calls add() for the CPU already present and ignores the  
return value from that add().
(drivers/base/sys.c:183).
Not if that add had failed, cpufreq will not know and later a remove 
() is being called on the same device, which causes the BUG()  
condition here.

However, I am not sure at this point why this gets triggered only on  
numcpus=1 case and not on normal boot case.

Will dig into this a bit more and hopefully have a patch to fix this  
soon.

Thanks,
~Venki


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [PATCH] clockevents: remove bad designed sysfs support for now
  2007-03-26  9:25   ` Ingo Molnar
@ 2007-03-26 18:57     ` Greg KH
  0 siblings, 0 replies; 128+ messages in thread
From: Greg KH @ 2007-03-26 18:57 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Thomas Gleixner, Linus Torvalds, Linux Kernel Mailing List,
	Andrew Morton

On Mon, Mar 26, 2007 at 11:25:05AM +0200, Ingo Molnar wrote:
> 
> * Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> > The current sysfs support of clockevents does not obey the "only one 
> > value per file" rule.
> > 
> > The real fix is not 2.6.21 material. Therefor remove the sysfs support 
> > for now.
> > 
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> 
> Acked-by: Ingo Molnar <mingo@elte.hu>

Acked-by: Greg Kroah-Hartman <gregkh@suse.de>

Thanks Thomas for doing this.

greg k-h

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: 2.6.21-rc5: maxcpus=1 crash in cpufreq: kernel BUG at drivers/cpufreq/cpufreq.c:82!
  2007-03-26 18:12   ` Venki Pallipadi
@ 2007-03-26 19:03     ` Venki Pallipadi
  2007-03-27  7:11       ` Ingo Molnar
  0 siblings, 1 reply; 128+ messages in thread
From: Venki Pallipadi @ 2007-03-26 19:03 UTC (permalink / raw)
  To: Venki Pallipadi
  Cc: Ingo Molnar, Linus Torvalds, Linux Kernel Mailing List, Dave Jones

On Mon, Mar 26, 2007 at 11:12:02AM -0700, Venki Pallipadi wrote:
> 
> >Calling initcall 0xffffffff8021e003: powernowk8_init+0x0/0x88()
> >powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+  
> >processors (version 2.00.00)
> >powernow-k8: BIOS error - no PSB or ACPI _PSS objects
> >------------[ cut here ]------------
> >kernel BUG at drivers/cpufreq/cpufreq.c:82!
> >invalid opcode: 0000 [1] PREEMPT SMP
> >CPU 0
> >Modules linked in:
> >Pid: 1, comm: swapper Not tainted 2.6.21-rc5 #14
> >RIP: 0010:[<ffffffff804a0edd>]  [<ffffffff804a0edd>]  
> >lock_policy_rwsem_write+0x2b/0x7f
> >RSP: 0000:ffff81003ff31de0  EFLAGS: 00010246
> >RAX: 00000000ffffffff RBX: ffffffff80aa46a8 RCX: 0000000000000000
> >RDX: ffffffff80741080 RSI: 0000000000000202 RDI: 0000000000000001
> >RBP: ffff81003ff31e00 R08: ffff81003ff30000 R09: ffff810002dfdab0
> >R10: ffff810002dfdab0 R11: ffff810002dfdab0 R12: 0000000000000001
> >R13: ffffffff806cc2c0 R14: ffffffff80a37920 R15: 0000000000000000
> >FS:  0000000000000000(0000) GS:ffffffff80741000(0000) knlGS: 
> >0000000000000000
> >CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> >CR2: 0000000000f06f53 CR3: 0000000000201000 CR4: 00000000000006e0
> >Process swapper (pid: 1, threadinfo ffff81003ff30000, task  
> >ffff81003ff2a790)
> >Stack:  ffffffff806cc2c0 ffffffff80aa46a8 ffffffff80aa46a8  
> >ffffffff806cc2c0
> > ffff81003ff31e20 ffffffff804a1538 ffff810002dfdab0 ffffffff806f6a40
> > ffff81003ff31e50 ffffffff803dffdf 00000000ffffffed 00000000ffffffed
> >Call Trace:
> > [<ffffffff804a1538>] cpufreq_remove_dev+0x11/0x26
> > [<ffffffff803dffdf>] sysdev_driver_unregister+0x52/0x98
> > [<ffffffff804a0d3b>] cpufreq_register_driver+0x12d/0x191
> > [<ffffffff8021e082>] powernowk8_init+0x7f/0x88
> > [<ffffffff80a1099e>] init+0x1a8/0x2a9
> > [<ffffffff8023294e>] schedule_tail+0x36/0x9a
> > [<ffffffff8020ab98>] child_rip+0xa/0x12
> > [<ffffffff80a107f6>] init+0x0/0x2a9
> > [<ffffffff8020ab8e>] child_rip+0x0/0x12
> >
> >
> >Code: 0f 0b eb fe 4c 63 e8 48 c7 c3 a0 c1 a6 80 4a 8b 04 ed c0 7a
> >RIP  [<ffffffff804a0edd>] lock_policy_rwsem_write+0x2b/0x7f
> > RSP <ffff81003ff31de0>
> >Kernel panic - not syncing: Attempted to kill init!
> >
> 

Ingo,

Does the patch below help?

Thanks,
Venki


Patch to resolve maxcpus=1 trigerring BUG() as reported by Ingo here

lkml subject:
"2.6.21-rc5: maxcpus=1 crash in cpufreq: kernel BUG at drivers/cpufreq/cpufreq.c:82!"

This check added to remove_dev  is symmetric to one in add_dev and handles
callbacks for offline cpus cleanly.

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>

Index: new/drivers/cpufreq/cpufreq.c
===================================================================
--- new.orig/drivers/cpufreq/cpufreq.c	2007-03-22 07:43:37.000000000 -0800
+++ new/drivers/cpufreq/cpufreq.c	2007-03-26 10:07:06.000000000 -0800
@@ -1015,6 +1015,10 @@
 {
 	unsigned int cpu = sys_dev->id;
 	int retval;
+
+	if (cpu_is_offline(cpu))
+		return 0;
+
 	if (unlikely(lock_policy_rwsem_write(cpu)))
 		BUG();
 

^ permalink raw reply	[flat|nested] 128+ messages in thread

* [1/5] 2.6.21-rc5: known regressions
  2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
                   ` (4 preceding siblings ...)
  2007-03-26 10:11 ` -rc5: e1000 resume weirdness Ingo Molnar
@ 2007-03-27  1:59 ` Adrian Bunk
  2007-03-28 18:54   ` Kok, Auke
  2007-03-30 12:04   ` [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions" Ingo Molnar
  2007-03-27  1:59   ` Adrian Bunk
                   ` (13 subsequent siblings)
  19 siblings, 2 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-27  1:59 UTC (permalink / raw)
  To: Linus Torvalds, Andrew Morton
  Cc: Linux Kernel Mailing List, Oliver Pinter, Sid Boyce,
	Boris Mogwitz, Eric W. Biederman, Jose Alberto Reguero,
	Ingo Molnar, Jesse Brandeburg, Auke Kok, e1000-devel, jgarzik,
	netdev, Ayaz Abdulla, Albert Hopkins

This email lists some known regressions in Linus' tree compared to 2.6.20.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : crashes in KDE
References : http://bugzilla.kernel.org/show_bug.cgi?id=8157
Submitter  : Oliver Pinter <oliver.pntr@gmail.com>
Status     : unknown


Subject    : kwin dies silently  (sysctl related?)
References : http://lkml.org/lkml/2007/2/28/112
Submitter  : Sid Boyce <g3vbv@blueyonder.co.uk>
             Boris Mogwitz <boris@macbeth.rhoen.de>
Status     : submitter was asked to bisect further


Subject    : problem with sockets
References : http://lkml.org/lkml/2007/3/21/248
Submitter  : Jose Alberto Reguero <jareguero@telefonica.net>
Status     : unknown


Subject    : e1000 resume weirdness
References : http://lkml.org/lkml/2007/3/26/91
Submitter  : Ingo Molnar <mingo@elte.hu>
Handled-By : Jesse Brandeburg <jesse.brandeburg@gmail.com>
             Auke Kok <auke-jan.h.kok@intel.com>
Status     : problem is being debugged


Subject    : forcedeth: sporadic under-load crashes
References : http://lkml.org/lkml/2007/3/26/63
Submitter  : Ingo Molnar <mingo@elte.hu>
Handled-By : Ingo Molnar <mingo@elte.hu>
             Ayaz Abdulla <aabdulla@nvidia.com>
Status     : problem is being debugged


Subject    : forcedeth: skb_over_panic
References : http://bugzilla.kernel.org/show_bug.cgi?id=8058
Submitter  : Albert Hopkins <kernel@marduk.letterboxes.org>
Handled-By : Ayaz Abdulla <aabdulla@nvidia.com>
Patch      : http://bugzilla.kernel.org/show_bug.cgi?id=8058
Status     : patch available




^ permalink raw reply	[flat|nested] 128+ messages in thread

* [2/5] 2.6.21-rc5: known regressions
  2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
  2007-03-26  8:31 ` Ingo Molnar
@ 2007-03-27  1:59   ` Adrian Bunk
  2007-03-26  9:04 ` 2.6.21-rc5: maxcpus=1 crash in cpufreq: kernel BUG at drivers/cpufreq/cpufreq.c:82! Ingo Molnar
                     ` (17 subsequent siblings)
  19 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-27  1:59 UTC (permalink / raw)
  Cc: Linux Kernel Mailing List, Ingo Molnar, Venki Pallipadi, davej,
	cpufreq, Michal Jaegermann, jgarzik, linux-ide, lenb, linux-acpi,
	Mathieu Bérard, Tejun Heo, Fabio Comolli, Plamen Petrov,
	Laurent Riffard, Lukas Hejtmanek

This email lists some known regressions in Linus' tree compared to 2.6.20.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : x86_64 SMP kernel: maxcpus=1 crash in cpufreq
References : http://lkml.org/lkml/2007/3/26/54
Submitter  : Ingo Molnar <mingo@elte.hu>
Handled-By : Venki Pallipadi <venkatesh.pallipadi@intel.com>
Status     : problem is being debugged


Subject    : kernels fail to boot with drives on ATIIXP controller
             (ACPI/IRQ related)
References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621
             http://lkml.org/lkml/2007/3/4/257
Submitter  : Michal Jaegermann <michal@ellpspace.math.ualberta.ca>
Status     : unknown


Subject    : NCQ problem with ahci and Hitachi drive  (ACPI related)
References : http://lkml.org/lkml/2007/3/4/178
             http://lkml.org/lkml/2007/3/9/475
             http://lkml.org/lkml/2007/2/22/8
Submitter  : Mathieu Bérard <Mathieu.Berard@crans.org>
Handled-By : Tejun Heo <htejun@gmail.com>
Patch      : http://lkml.org/lkml/2007/2/22/8
Status     : possible patch available


Subject    : libata: PATA UDMA/100 configured as UDMA/33
References : http://lkml.org/lkml/2007/2/20/294
             http://www.mail-archive.com/linux-ide@vger.kernel.org/msg04115.html
             http://bugzilla.kernel.org/show_bug.cgi?id=8133
             http://bugzilla.kernel.org/show_bug.cgi?id=8164
             http://lkml.org/lkml/2007/3/21/330
Submitter  : Fabio Comolli <fabio.comolli@gmail.com>
             Plamen Petrov <plamen.petrov@tk.ru.acad.bg>
             Laurent Riffard <laurent.riffard@free.fr>
             Lukas Hejtmanek <xhejtman@mail.muni.cz>
Handled-By : Tejun Heo <htejun@gmail.com>
Patch      : http://thread.gmane.org/gmane.linux.ide/17444
Status     : patch available


-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 128+ messages in thread

* [2/5] 2.6.21-rc5: known regressions
@ 2007-03-27  1:59   ` Adrian Bunk
  0 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-27  1:59 UTC (permalink / raw)
  Cc: Linux Kernel Mailing List, Ingo Molnar, Venki Pallipadi, davej,
	cpufreq, Michal Jaegermann, jgarzik, linux-ide, lenb, linux-acpi,
	Mathieu Bérard, Tejun Heo, Fabio Comolli, Plamen Petrov,
	Laurent Riffard, Lukas Hejtmanek

This email lists some known regressions in Linus' tree compared to 2.6.20.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : x86_64 SMP kernel: maxcpus=1 crash in cpufreq
References : http://lkml.org/lkml/2007/3/26/54
Submitter  : Ingo Molnar <mingo@elte.hu>
Handled-By : Venki Pallipadi <venkatesh.pallipadi@intel.com>
Status     : problem is being debugged


Subject    : kernels fail to boot with drives on ATIIXP controller
             (ACPI/IRQ related)
References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621
             http://lkml.org/lkml/2007/3/4/257
Submitter  : Michal Jaegermann <michal@ellpspace.math.ualberta.ca>
Status     : unknown


Subject    : NCQ problem with ahci and Hitachi drive  (ACPI related)
References : http://lkml.org/lkml/2007/3/4/178
             http://lkml.org/lkml/2007/3/9/475
             http://lkml.org/lkml/2007/2/22/8
Submitter  : Mathieu Bérard <Mathieu.Berard@crans.org>
Handled-By : Tejun Heo <htejun@gmail.com>
Patch      : http://lkml.org/lkml/2007/2/22/8
Status     : possible patch available


Subject    : libata: PATA UDMA/100 configured as UDMA/33
References : http://lkml.org/lkml/2007/2/20/294
             http://www.mail-archive.com/linux-ide@vger.kernel.org/msg04115.html
             http://bugzilla.kernel.org/show_bug.cgi?id=8133
             http://bugzilla.kernel.org/show_bug.cgi?id=8164
             http://lkml.org/lkml/2007/3/21/330
Submitter  : Fabio Comolli <fabio.comolli@gmail.com>
             Plamen Petrov <plamen.petrov@tk.ru.acad.bg>
             Laurent Riffard <laurent.riffard@free.fr>
             Lukas Hejtmanek <xhejtman@mail.muni.cz>
Handled-By : Tejun Heo <htejun@gmail.com>
Patch      : http://thread.gmane.org/gmane.linux.ide/17444
Status     : patch available



^ permalink raw reply	[flat|nested] 128+ messages in thread

* [2/5] 2.6.21-rc5: known regressions
@ 2007-03-27  1:59   ` Adrian Bunk
  0 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-27  1:59 UTC (permalink / raw)
  Cc: Linux Kernel Mailing List, Ingo Molnar, Venki Pallipadi, davej,
	cpufreq, Michal Jaegermann, jgarzik, linux-ide, lenb, linux-acpi,
	Mathieu Bérard, Tejun Heo, Fabio Comolli, Plamen Petrov,
	Laurent Riffard, Lukas Hejtmanek

This email lists some known regressions in Linus' tree compared to 2.6.20.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : x86_64 SMP kernel: maxcpus=1 crash in cpufreq
References : http://lkml.org/lkml/2007/3/26/54
Submitter  : Ingo Molnar <mingo@elte.hu>
Handled-By : Venki Pallipadi <venkatesh.pallipadi@intel.com>
Status     : problem is being debugged


Subject    : kernels fail to boot with drives on ATIIXP controller
             (ACPI/IRQ related)
References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621
             http://lkml.org/lkml/2007/3/4/257
Submitter  : Michal Jaegermann <michal@ellpspace.math.ualberta.ca>
Status     : unknown


Subject    : NCQ problem with ahci and Hitachi drive  (ACPI related)
References : http://lkml.org/lkml/2007/3/4/178
             http://lkml.org/lkml/2007/3/9/475
             http://lkml.org/lkml/2007/2/22/8
Submitter  : Mathieu Bérard <Mathieu.Berard@crans.org>
Handled-By : Tejun Heo <htejun@gmail.com>
Patch      : http://lkml.org/lkml/2007/2/22/8
Status     : possible patch available


Subject    : libata: PATA UDMA/100 configured as UDMA/33
References : http://lkml.org/lkml/2007/2/20/294
             http://www.mail-archive.com/linux-ide@vger.kernel.org/msg04115.html
             http://bugzilla.kernel.org/show_bug.cgi?id=8133
             http://bugzilla.kernel.org/show_bug.cgi?id=8164
             http://lkml.org/lkml/2007/3/21/330
Submitter  : Fabio Comolli <fabio.comolli@gmail.com>
             Plamen Petrov <plamen.petrov@tk.ru.acad.bg>
             Laurent Riffard <laurent.riffard@free.fr>
             Lukas Hejtmanek <xhejtman@mail.muni.cz>
Handled-By : Tejun Heo <htejun@gmail.com>
Patch      : http://thread.gmane.org/gmane.linux.ide/17444
Status     : patch available


-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 128+ messages in thread

* [3/5] 2.6.21-rc5: known regressions
  2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
                   ` (6 preceding siblings ...)
  2007-03-27  1:59   ` Adrian Bunk
@ 2007-03-27  1:59 ` Adrian Bunk
  2007-03-27  1:59   ` Adrian Bunk
                   ` (11 subsequent siblings)
  19 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-27  1:59 UTC (permalink / raw)
  To: Linus Torvalds, Andrew Morton
  Cc: Linux Kernel Mailing List, CIJOML, v4l-dvb-maintainer,
	Michal Piotrowski, perex, alsa-devel, Tino Keitel,
	Marcelo Tosatti, Oliver Neukum, greg, linux-usb-devel

This email lists some known regressions in Linus' tree compared to 2.6.20.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : Oops when changing DVB-T adapter
References : http://lkml.org/lkml/2007/3/9/212
Submitter  : CIJOML <cijoml@volny.cz>
Status     : unknown


Subject    : snd_intel8x0: divide error: 0000
References : http://lkml.org/lkml/2007/3/5/252
Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Status     : unknown


Subject    : USB: iPod doesn't work  (CONFIG_USB_SUSPEND)
References : http://lkml.org/lkml/2007/3/21/320
Submitter  : Tino Keitel <tino.keitel@gmx.de>
Caused-By  : Marcelo Tosatti <marcelo@kvack.org>
             commit 1d619f128ba911cd3e6d6ad3475f146eb92f5c27
Handled-By : Oliver Neukum <oneukum@suse.de>
Status     : problem is being debuggged



^ permalink raw reply	[flat|nested] 128+ messages in thread

* [4/5] 2.6.21-rc5: known regressions
  2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
@ 2007-03-27  1:59   ` Adrian Bunk
  2007-03-26  8:55 ` Linux 2.6.21-rc5 Thomas Gleixner
                     ` (18 subsequent siblings)
  19 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-27  1:59 UTC (permalink / raw)
  To: Linus Torvalds, Andrew Morton
  Cc: Linux Kernel Mailing List, Dave Jones, Jeremy Fitzhardinge,
	Eric W. Biederman, Rafael J. Wysocki, gregkh, linux-pci, pavel,
	linux-pm, Thomas Meyer, Frédéric Riss, Marcus Better,
	Tobias Doerffel, Len Brown, linux-acpi, Thomas Gleixner,
	Soeren Sonnenburg, jgarzik, linux-ide, Jens Axboe, Jeff Chua,
	Maxim Levitsky, tigran

This email lists some known regressions in Linus' tree compared to 2.6.20.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : ThinkPad X60: resume no longer works  (PCI related?)
References : http://lkml.org/lkml/2007/3/13/3
Submitter  : Dave Jones <davej@redhat.com>
             Jeremy Fitzhardinge <jeremy@goop.org>
Caused-By  : PCI merge
             commit 78149df6d565c36675463352d0bfe0000b02b7a7
Handled-By : Eric W. Biederman <ebiederm@xmission.com>
             Rafael J. Wysocki <rjw@sisk.pl>
Status     : problem is being debugged


Subject    : second suspend to disk in a row results in an oops  (MSI)
References : http://lkml.org/lkml/2007/3/17/43
             http://lkml.org/lkml/2007/3/22/150
             http://lkml.org/lkml/2007/3/26/205
             http://lkml.org/lkml/2007/3/26/76
Submitter  : Thomas Meyer <thomas@m3y3r.de>
             Frédéric Riss <frederic.riss@gmail.com>
             Marcus Better <marcus@better.se>
Handled-By : Eric W. Biederman <ebiederm@xmission.com>
Patch      : http://lkml.org/lkml/2007/3/24/136
Status     : patch was suggested


Subject    : Suspend to RAM doesn't work anymore  (ACPI?)
References : http://lkml.org/lkml/2007/3/19/128
             http://bugzilla.kernel.org/show_bug.cgi?id=8247
Submitter  : Tobias Doerffel <tobias.doerffel@gmail.com>
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
             Len Brown <len.brown@intel.com>
Status     : problem is being debugged


Subject    : s2ram autowake regression  (ACPI?)
References : http://lkml.org/lkml/2007/3/20/96
Submitter  : Pavel Machek <pavel@ucw.cz>
Handled-By : Len Brown <lenb@kernel.org>
Status     : submitter was asked to test a patch


Subject    : SATA breakage on resume
References : http://lkml.org/lkml/2007/3/7/233
Submitter  : Thomas Gleixner <tglx@linutronix.de>
             Soeren Sonnenburg <kernel@nn7.de>
Status     : unknown


Subject    : suspend to disk: keypress required for power down
References : http://lkml.org/lkml/2007/3/25/78
Submitter  : Thomas Meyer <thomas@m3y3r.de>
Status     : unknown


Subject    : resume from RAM corrupts vesafb console
References : http://lkml.org/lkml/2007/3/26/76
Submitter  : Marcus Better <marcus@better.se>
Handled-By : Pavel Machek <pavel@ucw.cz>
Status     : problem is being debugged


Subject    : suspend to disk: non-boot cpus are disabled again
References : http://lkml.org/lkml/2007/3/25/78
Submitter  : Thomas Meyer <thomas@m3y3r.de>
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
             Eric W. Biederman <ebiederm@xmission.com>
Status     : problem is being debugged


Subject    : ThinkPad doesn't resume from suspend to RAM
References : http://lkml.org/lkml/2007/2/27/80
             http://lkml.org/lkml/2007/2/28/348
Submitter  : Jens Axboe <jens.axboe@oracle.com>
             Jeff Chua <jeff.chua.linux@gmail.com>
Status     : unknown


Subject    : suspend to disk hangs  (microcode driver)
References : http://lkml.org/lkml/2007/3/16/126
Submitter  : Maxim Levitsky <maximlevitsky@gmail.com>
Caused-By  : Rafael J. Wysocki <rjw@sisk.pl>
             commit e3c7db621bed4afb8e231cb005057f2feb5db557
             commit ed746e3b18f4df18afa3763155972c5835f284c5
             commit 259130526c267550bc365d3015917d90667732f1
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Patch      : http://lkml.org/lkml/2007/3/23/179
Status     : patch available



-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 128+ messages in thread

* [4/5] 2.6.21-rc5: known regressions
@ 2007-03-27  1:59   ` Adrian Bunk
  0 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-27  1:59 UTC (permalink / raw)
  To: Linus Torvalds, Andrew Morton
  Cc: Linux Kernel Mailing List, Dave Jones, Jeremy Fitzhardinge,
	Eric W. Biederman, Rafael J. Wysocki, gregkh, linux-pci, pavel,
	linux-pm, Thomas Meyer, Frédéric Riss, Marcus Better,
	Tobias Doerffel, Len Brown, linux-acpi, Thomas Gleixner,
	Soeren Sonnenburg, jgarzik, linux-ide, Jens Axboe, Jeff Chua,
	Maxim Levitsky, tigran

This email lists some known regressions in Linus' tree compared to 2.6.20.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : ThinkPad X60: resume no longer works  (PCI related?)
References : http://lkml.org/lkml/2007/3/13/3
Submitter  : Dave Jones <davej@redhat.com>
             Jeremy Fitzhardinge <jeremy@goop.org>
Caused-By  : PCI merge
             commit 78149df6d565c36675463352d0bfe0000b02b7a7
Handled-By : Eric W. Biederman <ebiederm@xmission.com>
             Rafael J. Wysocki <rjw@sisk.pl>
Status     : problem is being debugged


Subject    : second suspend to disk in a row results in an oops  (MSI)
References : http://lkml.org/lkml/2007/3/17/43
             http://lkml.org/lkml/2007/3/22/150
             http://lkml.org/lkml/2007/3/26/205
             http://lkml.org/lkml/2007/3/26/76
Submitter  : Thomas Meyer <thomas@m3y3r.de>
             Frédéric Riss <frederic.riss@gmail.com>
             Marcus Better <marcus@better.se>
Handled-By : Eric W. Biederman <ebiederm@xmission.com>
Patch      : http://lkml.org/lkml/2007/3/24/136
Status     : patch was suggested


Subject    : Suspend to RAM doesn't work anymore  (ACPI?)
References : http://lkml.org/lkml/2007/3/19/128
             http://bugzilla.kernel.org/show_bug.cgi?id=8247
Submitter  : Tobias Doerffel <tobias.doerffel@gmail.com>
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
             Len Brown <len.brown@intel.com>
Status     : problem is being debugged


Subject    : s2ram autowake regression  (ACPI?)
References : http://lkml.org/lkml/2007/3/20/96
Submitter  : Pavel Machek <pavel@ucw.cz>
Handled-By : Len Brown <lenb@kernel.org>
Status     : submitter was asked to test a patch


Subject    : SATA breakage on resume
References : http://lkml.org/lkml/2007/3/7/233
Submitter  : Thomas Gleixner <tglx@linutronix.de>
             Soeren Sonnenburg <kernel@nn7.de>
Status     : unknown


Subject    : suspend to disk: keypress required for power down
References : http://lkml.org/lkml/2007/3/25/78
Submitter  : Thomas Meyer <thomas@m3y3r.de>
Status     : unknown


Subject    : resume from RAM corrupts vesafb console
References : http://lkml.org/lkml/2007/3/26/76
Submitter  : Marcus Better <marcus@better.se>
Handled-By : Pavel Machek <pavel@ucw.cz>
Status     : problem is being debugged


Subject    : suspend to disk: non-boot cpus are disabled again
References : http://lkml.org/lkml/2007/3/25/78
Submitter  : Thomas Meyer <thomas@m3y3r.de>
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
             Eric W. Biederman <ebiederm@xmission.com>
Status     : problem is being debugged


Subject    : ThinkPad doesn't resume from suspend to RAM
References : http://lkml.org/lkml/2007/2/27/80
             http://lkml.org/lkml/2007/2/28/348
Submitter  : Jens Axboe <jens.axboe@oracle.com>
             Jeff Chua <jeff.chua.linux@gmail.com>
Status     : unknown


Subject    : suspend to disk hangs  (microcode driver)
References : http://lkml.org/lkml/2007/3/16/126
Submitter  : Maxim Levitsky <maximlevitsky@gmail.com>
Caused-By  : Rafael J. Wysocki <rjw@sisk.pl>
             commit e3c7db621bed4afb8e231cb005057f2feb5db557
             commit ed746e3b18f4df18afa3763155972c5835f284c5
             commit 259130526c267550bc365d3015917d90667732f1
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Patch      : http://lkml.org/lkml/2007/3/23/179
Status     : patch available




^ permalink raw reply	[flat|nested] 128+ messages in thread

* [5/5] 2.6.21-rc5: known regressions
  2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
@ 2007-03-27  1:59   ` Adrian Bunk
  2007-03-26  8:55 ` Linux 2.6.21-rc5 Thomas Gleixner
                     ` (18 subsequent siblings)
  19 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-27  1:59 UTC (permalink / raw)
  To: Linus Torvalds, Andrew Morton
  Cc: Linux Kernel Mailing List, Frédéric Riss, Tino Keitel,
	Thomas Gleixner, John Stultz, pavel, linux-pm, Mike Harris,
	Stephane Casset, Michael S. Tsirkin, Jeff Chua, Ingo Molnar,
	Soeren Sonnenburg, Tejun Heo, Rafael J. Wysocki

This email lists some known regressions in Linus' tree compared to 2.6.20.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : MacMini doesn't come out of suspend to ram  (i386 clockevents)
             (CONFIG_HPET_TIMER)
References : http://lkml.org/lkml/2007/3/21/374
Submitter  : Frédéric Riss <frederic.riss@gmail.com>
             Tino Keitel <tino.keitel@gmx.de>
Caused-By  : Thomas Gleixner <tglx@linutronix.de>
             commit e9e2cdb412412326c4827fc78ba27f410d837e6e
Status     : unknown


Subject    : MacBook Core Duo: suspend to disk hangs
References : http://bugzilla.kernel.org/show_bug.cgi?id=8224
Submitter  : Mike Harris <atarimike@wavecable.com>
Status     : unknown


Subject    : Dynticks and High resolution Timer hang boot during IDE detection
             workaround: clocksource=acpi_pm
References : http://lkml.org/lkml/2007/3/7/504
Submitter  : Stephane Casset <sept@logidee.com>
Caused-By  : John Stultz <johnstul@us.ibm.com>
             commit 6bb74df481223731af6c7e0ff3adb31f6442cfcd
Handled-By : John Stultz <johnstul@us.ibm.com>
Patch      : http://lkml.org/lkml/2007/3/22/287
Status     : workaround-patch available


Subject    : after resume: X hangs after drawing a couple of windows
             workaround: clocksource=acpi_pm
References : http://lkml.org/lkml/2007/3/8/117
             http://lkml.org/lkml/2007/3/25/20
             http://lkml.org/lkml/2007/3/26/151
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Status     : problem is being debugged


Subject    : first disk access after resume takes several minutes
             resume from RAM broken
             'date' does not advance after resume from RAM  (CONFIG_HPET_TIMER)
References : http://lkml.org/lkml/2007/3/8/117
             http://lkml.org/lkml/2007/3/25/20
             http://lkml.org/lkml/2007/3/26/18
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
             Jeff Chua <jeff.chua.linux@gmail.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
             Ingo Molnar <mingo@elte.hu>
Status     : problem is being debugged


Subject    : system doesn't come out of suspend  (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/22/391
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
             Soeren Sonnenburg <kernel@nn7.de>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
             Ingo Molnar <mingo@elte.hu>
             Tejun Heo <htejun@gmail.com>
             Rafael J. Wysocki <rjw@sisk.pl>
Status     : unknown


Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/3/25/217
Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
Status     : unknown



^ permalink raw reply	[flat|nested] 128+ messages in thread

* [5/5] 2.6.21-rc5: known regressions
@ 2007-03-27  1:59   ` Adrian Bunk
  0 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-27  1:59 UTC (permalink / raw)
  To: Linus Torvalds, Andrew Morton
  Cc: Soeren Sonnenburg, Tejun Heo, Frédéric Riss, Jeff Chua,
	John Stultz, Stephane Casset, Tino Keitel, linux-pm,
	Linux Kernel Mailing List, Michael S. Tsirkin, Thomas Gleixner,
	Ingo Molnar, Mike Harris

This email lists some known regressions in Linus' tree compared to 2.6.20.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : MacMini doesn't come out of suspend to ram  (i386 clockevents)
             (CONFIG_HPET_TIMER)
References : http://lkml.org/lkml/2007/3/21/374
Submitter  : Frédéric Riss <frederic.riss@gmail.com>
             Tino Keitel <tino.keitel@gmx.de>
Caused-By  : Thomas Gleixner <tglx@linutronix.de>
             commit e9e2cdb412412326c4827fc78ba27f410d837e6e
Status     : unknown


Subject    : MacBook Core Duo: suspend to disk hangs
References : http://bugzilla.kernel.org/show_bug.cgi?id=8224
Submitter  : Mike Harris <atarimike@wavecable.com>
Status     : unknown


Subject    : Dynticks and High resolution Timer hang boot during IDE detection
             workaround: clocksource=acpi_pm
References : http://lkml.org/lkml/2007/3/7/504
Submitter  : Stephane Casset <sept@logidee.com>
Caused-By  : John Stultz <johnstul@us.ibm.com>
             commit 6bb74df481223731af6c7e0ff3adb31f6442cfcd
Handled-By : John Stultz <johnstul@us.ibm.com>
Patch      : http://lkml.org/lkml/2007/3/22/287
Status     : workaround-patch available


Subject    : after resume: X hangs after drawing a couple of windows
             workaround: clocksource=acpi_pm
References : http://lkml.org/lkml/2007/3/8/117
             http://lkml.org/lkml/2007/3/25/20
             http://lkml.org/lkml/2007/3/26/151
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Status     : problem is being debugged


Subject    : first disk access after resume takes several minutes
             resume from RAM broken
             'date' does not advance after resume from RAM  (CONFIG_HPET_TIMER)
References : http://lkml.org/lkml/2007/3/8/117
             http://lkml.org/lkml/2007/3/25/20
             http://lkml.org/lkml/2007/3/26/18
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
             Jeff Chua <jeff.chua.linux@gmail.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
             Ingo Molnar <mingo@elte.hu>
Status     : problem is being debugged


Subject    : system doesn't come out of suspend  (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/22/391
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
             Soeren Sonnenburg <kernel@nn7.de>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
             Ingo Molnar <mingo@elte.hu>
             Tejun Heo <htejun@gmail.com>
             Rafael J. Wysocki <rjw@sisk.pl>
Status     : unknown


Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/3/25/217
Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
Status     : unknown

^ permalink raw reply	[flat|nested] 128+ messages in thread

* ATA ACPI (was Re: Linux 2.6.21-rc5)
  2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
                   ` (9 preceding siblings ...)
  2007-03-27  1:59   ` Adrian Bunk
@ 2007-03-27  5:51 ` Jeff Garzik
  2007-03-27  5:54   ` Tejun Heo
  2007-03-27 17:07   ` Linus Torvalds
  2007-03-27  6:17 ` Linux 2.6.21-rc5 Andrew Morton
                   ` (8 subsequent siblings)
  19 siblings, 2 replies; 128+ messages in thread
From: Jeff Garzik @ 2007-03-27  5:51 UTC (permalink / raw)
  To: IDE/ATA development list
  Cc: Linus Torvalds, Linux Kernel Mailing List, Alan, Tejun Heo,
	Len Brown, Kristen Carlson Accardi

Linus Torvalds wrote:
> There's various fixes here, ranging from some architecture updates (ia64, 
> ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.
> 
> And random one-liners.
> 
> But probably more important, and likely much more visible to most people 
> is the fixes for the fallout from the hrtimers and no-HZ changes, and some 
> of the ACPI regressions.
> 
> Those timer changes ended up much more painful than anybody wished for, 
> but big thanks to Thomas Gleixner for being on it like a weasel on a dead 
> rat, and the regression list has kept shrinking.
> 
> So if you have reported a regression in the 2.6.21-rc series, please check 
> 2.6.21-rc5, and update your report as appropriate (whether fixed or "still 
> problems with xyzzy").
> 
> 		Linus


[just got back from vacation, or would have sent this earlier]

FWIW, I'm still leaning towards disabling libata ACPI support by default 
for 2.6.21.

Upstream has Alan's fix for the worst PATA problems, but for different 
reasons, I think PATA ACPI and SATA ACPI support in libata does not feel 
quite ready for prime time in 2.6.21.

Scream now, or hold your peace until 2.6.22... :)

	Jeff



^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: ATA ACPI (was Re: Linux 2.6.21-rc5)
  2007-03-27  5:51 ` ATA ACPI (was Re: Linux 2.6.21-rc5) Jeff Garzik
@ 2007-03-27  5:54   ` Tejun Heo
  2007-03-27 21:32     ` Pavel Machek
  2007-03-27 17:07   ` Linus Torvalds
  1 sibling, 1 reply; 128+ messages in thread
From: Tejun Heo @ 2007-03-27  5:54 UTC (permalink / raw)
  To: Jeff Garzik
  Cc: IDE/ATA development list, Linus Torvalds,
	Linux Kernel Mailing List, Alan, Len Brown,
	Kristen Carlson Accardi

Jeff Garzik wrote:
> Linus Torvalds wrote:
>> There's various fixes here, ranging from some architecture updates 
>> (ia64, ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.
>>
>> And random one-liners.
>>
>> But probably more important, and likely much more visible to most 
>> people is the fixes for the fallout from the hrtimers and no-HZ 
>> changes, and some of the ACPI regressions.
>>
>> Those timer changes ended up much more painful than anybody wished 
>> for, but big thanks to Thomas Gleixner for being on it like a weasel 
>> on a dead rat, and the regression list has kept shrinking.
>>
>> So if you have reported a regression in the 2.6.21-rc series, please 
>> check 2.6.21-rc5, and update your report as appropriate (whether fixed 
>> or "still problems with xyzzy").
>>
>>         Linus
> 
> 
> [just got back from vacation, or would have sent this earlier]
> 
> FWIW, I'm still leaning towards disabling libata ACPI support by default 
> for 2.6.21.
> 
> Upstream has Alan's fix for the worst PATA problems, but for different 
> reasons, I think PATA ACPI and SATA ACPI support in libata does not feel 
> quite ready for prime time in 2.6.21.
> 
> Scream now, or hold your peace until 2.6.22... :)

I second disabling ACPI for 2.6.21.

-- 
tejun

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.21-rc5
  2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
                   ` (10 preceding siblings ...)
  2007-03-27  5:51 ` ATA ACPI (was Re: Linux 2.6.21-rc5) Jeff Garzik
@ 2007-03-27  6:17 ` Andrew Morton
  2007-03-27  6:20   ` Greg KH
                     ` (4 more replies)
  2007-03-27 18:34 ` Michal Piotrowski
                   ` (7 subsequent siblings)
  19 siblings, 5 replies; 128+ messages in thread
From: Andrew Morton @ 2007-03-27  6:17 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Linux Kernel Mailing List, Andi Kleen, Jaroslav Kysela,
	Takashi Iwai, Ben Dooks, Greg KH, Dmitry Torokhov


I have a few fixes here which belong to subsystem trees, which were missed
by the maintainers and which we probably want to get into 2.6.21.


ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/make-aout-executables-work-again.patch

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/revert-ac97-fix-microphone-and-line_in-selection-logic.patch

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/drivers-mfd-sm501c-fix-an-off-by-one.patch

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/pci-set-pci=bfsort-for-poweredge-r900.patch

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/fix-sudden-warps-in-mousedev.patch

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/fix-sysfs-rom-file-creation-for-bios-rom-shadows.patch

Maintainers are cc'ed.  Please promptly ack, nack or otherwise quack, else
I'll be making my own decisions ;)


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.21-rc5
  2007-03-27  6:17 ` Linux 2.6.21-rc5 Andrew Morton
@ 2007-03-27  6:20   ` Greg KH
  2007-03-27 16:49     ` Jesse Barnes
  2007-03-27  9:49   ` Takashi Iwai
                     ` (3 subsequent siblings)
  4 siblings, 1 reply; 128+ messages in thread
From: Greg KH @ 2007-03-27  6:20 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linus Torvalds, Linux Kernel Mailing List, Andi Kleen,
	Jaroslav Kysela, Takashi Iwai, Ben Dooks, Dmitry Torokhov

On Mon, Mar 26, 2007 at 10:17:31PM -0800, Andrew Morton wrote:
> 
> I have a few fixes here which belong to subsystem trees, which were missed
> by the maintainers and which we probably want to get into 2.6.21.
> 
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/pci-set-pci=bfsort-for-poweredge-r900.patch

Already in Linus's tree.

> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/fix-sysfs-rom-file-creation-for-bios-rom-shadows.patch

I'd prefer to wait until 2.6.22 for this one, I've had too many odd
reports of problems in this area, and since no one has reported this
issue, it's not a real rush at all.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 128+ messages in thread

* [PATCH] i386: Fix bogus return value in hpet_next_event()
  2007-03-26  9:21 ` [PATCH] clockevents: remove bad designed sysfs support for now Thomas Gleixner
  2007-03-26  9:25   ` Ingo Molnar
  2007-03-26 12:51   ` Pavel Machek
@ 2007-03-27  7:08   ` Thomas Gleixner
  2 siblings, 0 replies; 128+ messages in thread
From: Thomas Gleixner @ 2007-03-27  7:08 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Ingo Molnar, Andrew Morton

The clockevents / tick management code expects an error value, when the
event is already expired. hpet_next_event() returns 1 in that case.

Fix it to return the proper -ETIME error code.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
index f3ab61e..76afea6 100644
--- a/arch/i386/kernel/hpet.c
+++ b/arch/i386/kernel/hpet.c
@@ -197,7 +197,7 @@ static int hpet_next_event(unsigned long delta,
 	cnt += delta;
 	hpet_writel(cnt, HPET_T0_CMP);
 
-	return ((long)(hpet_readl(HPET_COUNTER) - cnt ) > 0);
+	return ((long)(hpet_readl(HPET_COUNTER) - cnt ) > 0) ? -ETIME : 0;
 }
 
 /*



^ permalink raw reply related	[flat|nested] 128+ messages in thread

* Re: 2.6.21-rc5: maxcpus=1 crash in cpufreq: kernel BUG at drivers/cpufreq/cpufreq.c:82!
  2007-03-26 19:03     ` Venki Pallipadi
@ 2007-03-27  7:11       ` Ingo Molnar
  0 siblings, 0 replies; 128+ messages in thread
From: Ingo Molnar @ 2007-03-27  7:11 UTC (permalink / raw)
  To: Venki Pallipadi; +Cc: Linus Torvalds, Linux Kernel Mailing List, Dave Jones


* Venki Pallipadi <venkatesh.pallipadi@intel.com> wrote:

> Ingo,
> 
> Does the patch below help?

> Patch to resolve maxcpus=1 trigerring BUG() as reported by Ingo here

yes, it solves it, thanks!

Acked-by: Ingo Molnar <mingo@elte.hu>

	Ingo

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [4/5] 2.6.21-rc5: known regressions
  2007-03-27  1:59   ` Adrian Bunk
  (?)
@ 2007-03-27  8:00   ` Marcus Better
  2007-03-27 13:25     ` Eric W. Biederman
  -1 siblings, 1 reply; 128+ messages in thread
From: Marcus Better @ 2007-03-27  8:00 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Linux Kernel Mailing List, Eric W. Biederman, Thomas Meyer,
	Frédéric Riss

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

> Subject    : second suspend to disk in a row results in an oops  (MSI)
> References : http://lkml.org/lkml/2007/3/17/43
>              http://lkml.org/lkml/2007/3/22/150
>              http://lkml.org/lkml/2007/3/26/205
>              http://lkml.org/lkml/2007/3/26/76
> Submitter  : Thomas Meyer <thomas@m3y3r.de>
>              Frédéric Riss <frederic.riss@gmail.com>
>              Marcus Better <marcus@better.se>
> Handled-By : Eric W. Biederman <ebiederm@xmission.com>
> Patch      : http://lkml.org/lkml/2007/3/24/136
> Status     : patch was suggested

For the sake of completeness, my bisection resulted in this:

392ee1e6dd901db6c4504617476f6442ed91f72d is first bad commit
commit 392ee1e6dd901db6c4504617476f6442ed91f72d
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Thu Mar 8 13:04:57 2007 -0700

    [PATCH] msi: Safer state caching.

Marcus

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

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.21-rc5
  2007-03-27  6:17 ` Linux 2.6.21-rc5 Andrew Morton
  2007-03-27  6:20   ` Greg KH
@ 2007-03-27  9:49   ` Takashi Iwai
  2007-03-27 12:25   ` Andi Kleen
                     ` (2 subsequent siblings)
  4 siblings, 0 replies; 128+ messages in thread
From: Takashi Iwai @ 2007-03-27  9:49 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linus Torvalds, Linux Kernel Mailing List, Andi Kleen,
	Jaroslav Kysela, Ben Dooks, Greg KH, Dmitry Torokhov

At Mon, 26 Mar 2007 22:17:31 -0800,
Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/revert-ac97-fix-microphone-and-line_in-selection-logic.patch

The better fix is already in rc5, so please drop this one from your
tree.

    c26a8de23a4417f556250c4c099b048b26c430be
    [ALSA] ac97 - fix AD shared shared jack control logic


thanks,

Takashi

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [4/5] 2.6.21-rc5: known regressions
  2007-03-27  1:59   ` Adrian Bunk
@ 2007-03-27 10:09     ` Rafael J. Wysocki
  -1 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2007-03-27 10:09 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
	Eric W. Biederman, pavel, linux-pm, Thomas Meyer,
	Thomas Gleixner

On Tuesday, 27 March 2007 03:59, Adrian Bunk wrote:
> This email lists some known regressions in Linus' tree compared to 2.6.20.
> 
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a breakage or I'm considering you in any other way
> possibly involved with one or more of these issues.
> 
> Due to the huge amount of recipients, please trim the Cc when answering.

I think the following two:
 
> Subject    : suspend to disk: keypress required for power down
> References : http://lkml.org/lkml/2007/3/25/78
> Submitter  : Thomas Meyer <thomas@m3y3r.de>
> Status     : unknown
 
> Subject    : suspend to disk: non-boot cpus are disabled again
> References : http://lkml.org/lkml/2007/3/25/78
> Submitter  : Thomas Meyer <thomas@m3y3r.de>
> Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
>              Eric W. Biederman <ebiederm@xmission.com>
> Status     : problem is being debugged

are related to the same issue.

The problem is that we call disable_nonboot_cpus() in swsusp before
powering down the system in order to avoid triggering the WARN_ON()
in arch/x86_64/kernel/acpi/sleep.c:init_low_mapping() and this doesn't
work well on Thomas' system.

Since the problem has been introduced by commit
94985134b7b46848267ed6b734320db01c974e72
(swsusp: disable nonboot CPUs before entering platform suspend), I think it's
better to revert this commit and remove the the WARN_ON() in
arch/x86_64/kernel/acpi/sleep.c:init_low_mapping() (appended is a patch that
removes the WARN_ON()).

Greetings,
Rafael


---
Remove the WARN_ON() in arch/x86_64/kernel/acpi/sleep.c:init_low_mapping(),
which triggers every time during the suspend to disk in the platform mode, as
the potential problem it is related to doesn't seem to occur in practice.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 arch/x86_64/kernel/acpi/sleep.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Index: linux-2.6.21-rc5/arch/x86_64/kernel/acpi/sleep.c
===================================================================
--- linux-2.6.21-rc5.orig/arch/x86_64/kernel/acpi/sleep.c
+++ linux-2.6.21-rc5/arch/x86_64/kernel/acpi/sleep.c
@@ -66,8 +66,10 @@ static void init_low_mapping(void)
 {
 	pgd_t *slot0 = pgd_offset(current->mm, 0UL);
 	low_ptr = *slot0;
+	/* FIXME: We're playing with the current task's page tables here, which
+	 * is potentially dangerous on SMP systems.
+	 */
 	set_pgd(slot0, *pgd_offset(current->mm, PAGE_OFFSET));
-	WARN_ON(num_online_cpus() != 1);
 	local_flush_tlb();
 }
 

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [4/5] 2.6.21-rc5: known regressions
@ 2007-03-27 10:09     ` Rafael J. Wysocki
  0 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2007-03-27 10:09 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Thomas Gleixner, Eric W. Biederman, Linus Torvalds,
	Andrew Morton, linux-pm, Linux Kernel Mailing List, Thomas Meyer

On Tuesday, 27 March 2007 03:59, Adrian Bunk wrote:
> This email lists some known regressions in Linus' tree compared to 2.6.20.
> 
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a breakage or I'm considering you in any other way
> possibly involved with one or more of these issues.
> 
> Due to the huge amount of recipients, please trim the Cc when answering.

I think the following two:
 
> Subject    : suspend to disk: keypress required for power down
> References : http://lkml.org/lkml/2007/3/25/78
> Submitter  : Thomas Meyer <thomas@m3y3r.de>
> Status     : unknown
 
> Subject    : suspend to disk: non-boot cpus are disabled again
> References : http://lkml.org/lkml/2007/3/25/78
> Submitter  : Thomas Meyer <thomas@m3y3r.de>
> Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
>              Eric W. Biederman <ebiederm@xmission.com>
> Status     : problem is being debugged

are related to the same issue.

The problem is that we call disable_nonboot_cpus() in swsusp before
powering down the system in order to avoid triggering the WARN_ON()
in arch/x86_64/kernel/acpi/sleep.c:init_low_mapping() and this doesn't
work well on Thomas' system.

Since the problem has been introduced by commit
94985134b7b46848267ed6b734320db01c974e72
(swsusp: disable nonboot CPUs before entering platform suspend), I think it's
better to revert this commit and remove the the WARN_ON() in
arch/x86_64/kernel/acpi/sleep.c:init_low_mapping() (appended is a patch that
removes the WARN_ON()).

Greetings,
Rafael


---
Remove the WARN_ON() in arch/x86_64/kernel/acpi/sleep.c:init_low_mapping(),
which triggers every time during the suspend to disk in the platform mode, as
the potential problem it is related to doesn't seem to occur in practice.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 arch/x86_64/kernel/acpi/sleep.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Index: linux-2.6.21-rc5/arch/x86_64/kernel/acpi/sleep.c
===================================================================
--- linux-2.6.21-rc5.orig/arch/x86_64/kernel/acpi/sleep.c
+++ linux-2.6.21-rc5/arch/x86_64/kernel/acpi/sleep.c
@@ -66,8 +66,10 @@ static void init_low_mapping(void)
 {
 	pgd_t *slot0 = pgd_offset(current->mm, 0UL);
 	low_ptr = *slot0;
+	/* FIXME: We're playing with the current task's page tables here, which
+	 * is potentially dangerous on SMP systems.
+	 */
 	set_pgd(slot0, *pgd_offset(current->mm, PAGE_OFFSET));
-	WARN_ON(num_online_cpus() != 1);
 	local_flush_tlb();
 }
 

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.21-rc5
  2007-03-27  6:17 ` Linux 2.6.21-rc5 Andrew Morton
  2007-03-27  6:20   ` Greg KH
  2007-03-27  9:49   ` Takashi Iwai
@ 2007-03-27 12:25   ` Andi Kleen
  2007-03-27 16:33     ` Andrew Morton
  2007-03-27 12:43   ` Dmitry Torokhov
  2007-03-28 22:32   ` Tilman Schmidt
  4 siblings, 1 reply; 128+ messages in thread
From: Andi Kleen @ 2007-03-27 12:25 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linus Torvalds, Linux Kernel Mailing List, Jaroslav Kysela,
	Takashi Iwai, Ben Dooks, Greg KH, Dmitry Torokhov

On Tuesday 27 March 2007 08:17, Andrew Morton wrote:
> 
> I have a few fixes here which belong to subsystem trees, which were missed
> by the maintainers and which we probably want to get into 2.6.21.
> 
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/make-aout-executables-work-again.patch

This is already fixed in a different way.

-Andi



^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.21-rc5
  2007-03-27  6:17 ` Linux 2.6.21-rc5 Andrew Morton
                     ` (2 preceding siblings ...)
  2007-03-27 12:25   ` Andi Kleen
@ 2007-03-27 12:43   ` Dmitry Torokhov
  2007-03-28 22:32   ` Tilman Schmidt
  4 siblings, 0 replies; 128+ messages in thread
From: Dmitry Torokhov @ 2007-03-27 12:43 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linus Torvalds, Linux Kernel Mailing List, Andi Kleen,
	Jaroslav Kysela, Takashi Iwai, Ben Dooks, Greg KH

On 3/27/07, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> I have a few fixes here which belong to subsystem trees, which were missed
> by the maintainers and which we probably want to get into 2.6.21.
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/fix-sudden-warps-in-mousedev.patch
>

Slightly different fix is already in input tree. I'd perfer waiting
for 2.6.22 as this only affects touchpads when not using synaptics X
driver (which most distributions use by default).

-- 
Dmitry

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [4/5] 2.6.21-rc5: known regressions
  2007-03-27  8:00   ` Marcus Better
@ 2007-03-27 13:25     ` Eric W. Biederman
  2007-03-27 16:53       ` Marcus Better
  0 siblings, 1 reply; 128+ messages in thread
From: Eric W. Biederman @ 2007-03-27 13:25 UTC (permalink / raw)
  To: Marcus Better
  Cc: Adrian Bunk, Linux Kernel Mailing List, Thomas Meyer,
	Frédéric Riss

Marcus Better <marcus@better.se> writes:

>> Subject    : second suspend to disk in a row results in an oops  (MSI)
>> References : http://lkml.org/lkml/2007/3/17/43
>>              http://lkml.org/lkml/2007/3/22/150
>>              http://lkml.org/lkml/2007/3/26/205
>>              http://lkml.org/lkml/2007/3/26/76
>> Submitter  : Thomas Meyer <thomas@m3y3r.de>
>>              Frédéric Riss <frederic.riss@gmail.com>
>>              Marcus Better <marcus@better.se>
>> Handled-By : Eric W. Biederman <ebiederm@xmission.com>
>> Patch      : http://lkml.org/lkml/2007/3/24/136
>> Status     : patch was suggested
>
> For the sake of completeness, my bisection resulted in this:
>
> 392ee1e6dd901db6c4504617476f6442ed91f72d is first bad commit
> commit 392ee1e6dd901db6c4504617476f6442ed91f72d
> Author: Eric W. Biederman <ebiederm@xmission.com>
> Date:   Thu Mar 8 13:04:57 2007 -0700
>
>     [PATCH] msi: Safer state caching.

Right.  However if this is what Thomas was seeing the problem turned
out to be an issue with pci_enable_device changing the irq number.
It just happens that now the code cares, so the bug is found.

Marcus any chance I could see an oops?  Or you could try the patch I
previously posted when debugging this with Thomas.

I'm going to clean that patch up and send it along in hopes that it
helps anyway and see where we land.

Eric

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.21-rc5
  2007-03-27 12:25   ` Andi Kleen
@ 2007-03-27 16:33     ` Andrew Morton
  0 siblings, 0 replies; 128+ messages in thread
From: Andrew Morton @ 2007-03-27 16:33 UTC (permalink / raw)
  To: Andi Kleen, Parag Warudkar
  Cc: Linus Torvalds, Linux Kernel Mailing List, Jaroslav Kysela,
	Takashi Iwai, Ben Dooks, Greg KH, Dmitry Torokhov

On Tue, 27 Mar 2007 14:25:07 +0200 Andi Kleen <ak@suse.de> wrote:

> On Tuesday 27 March 2007 08:17, Andrew Morton wrote:
> > 
> > I have a few fixes here which belong to subsystem trees, which were missed
> > by the maintainers and which we probably want to get into 2.6.21.
> > 
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/make-aout-executables-work-again.patch
> 
> This is already fixed in a different way.
> 

oh yeah.  Did that fix make it into 2.6.20.x?

I think we decided that make-aout-executables-work-again.patch might still
be a desirable thing to have, but I don't recall the reasoning for that.

Anyway, if it doesn't fix a bug it is nowhere near a high-priority patch
for that seething bugfest which we like to call a kernel, so I'll drop it.

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.21-rc5
  2007-03-27  6:20   ` Greg KH
@ 2007-03-27 16:49     ` Jesse Barnes
  0 siblings, 0 replies; 128+ messages in thread
From: Jesse Barnes @ 2007-03-27 16:49 UTC (permalink / raw)
  To: Greg KH
  Cc: Andrew Morton, Linus Torvalds, Linux Kernel Mailing List,
	Andi Kleen, Jaroslav Kysela, Takashi Iwai, Ben Dooks,
	Dmitry Torokhov

On Monday, March 26, 2007 11:20 pm Greg KH wrote:
> Already in Linus's tree.
>
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2
> >1-rc5/2.6.21-rc5-mm2/broken-out/fix-sysfs-rom-file-creation-for-bios
> >-rom-shadows.patch
>
> I'd prefer to wait until 2.6.22 for this one, I've had too many odd
> reports of problems in this area, and since no one has reported this
> issue, it's not a real rush at all.

Yeah, I don't think this one is critical.  These files aren't in heavy 
use yet, so fixing this in 2.6.22 should be ok.  I've only heard one 
complaint about this bug so far, and that was caused by some code still 
in development.

Jesse

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [4/5] 2.6.21-rc5: known regressions
  2007-03-27 13:25     ` Eric W. Biederman
@ 2007-03-27 16:53       ` Marcus Better
  2007-03-27 20:50         ` Eric W. Biederman
  0 siblings, 1 reply; 128+ messages in thread
From: Marcus Better @ 2007-03-27 16:53 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: Linux Kernel Mailing List

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

Eric W. Biederman wrote:

> >> Patch      : http://lkml.org/lkml/2007/3/24/136

> Marcus any chance I could see an oops?

I didn't see anything, it froze with the yellow "Linux!" sign. Any idea how to 
get a oops?

> Or you could try the patch I 
> previously posted when debugging this with Thomas.

Do you mean the one referenced above? I tried it [1] and it works.

Marcus

[1] http://permalink.gmane.org/gmane.linux.kernel/509299

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

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: ATA ACPI (was Re: Linux 2.6.21-rc5)
  2007-03-27  5:51 ` ATA ACPI (was Re: Linux 2.6.21-rc5) Jeff Garzik
  2007-03-27  5:54   ` Tejun Heo
@ 2007-03-27 17:07   ` Linus Torvalds
  2007-03-27 18:48     ` Jeff Garzik
  1 sibling, 1 reply; 128+ messages in thread
From: Linus Torvalds @ 2007-03-27 17:07 UTC (permalink / raw)
  To: Jeff Garzik
  Cc: IDE/ATA development list, Linux Kernel Mailing List, Alan,
	Tejun Heo, Len Brown, Kristen Carlson Accardi



On Tue, 27 Mar 2007, Jeff Garzik wrote:
> 
> FWIW, I'm still leaning towards disabling libata ACPI support by default for
> 2.6.21.

Hey, I'm not going to argue against anything that says "disable ACPI". Of 
*course* it should be disabled if there aren't thousands of machines that 
are in user hands that actually need it (and none that regress).

Anybody want to send me a patch?

		Linus

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.21-rc5
  2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
                   ` (11 preceding siblings ...)
  2007-03-27  6:17 ` Linux 2.6.21-rc5 Andrew Morton
@ 2007-03-27 18:34 ` Michal Piotrowski
  2007-03-27 22:29   ` Pavel Machek
  2007-03-27 18:53 ` Michal Piotrowski
                   ` (6 subsequent siblings)
  19 siblings, 1 reply; 128+ messages in thread
From: Michal Piotrowski @ 2007-03-27 18:34 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Stephen Hemminger, Jeff Garzik, Rafael J. Wysocki, Pavel Machek,
	Linux Kernel Mailing List

Hi,

On 26/03/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> There's various fixes here, ranging from some architecture updates (ia64,
> ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.
>

Suspend to disk doesn't work for me with this patch. It hangs after
PM: Preparing devices for restore.
Suspending console(s)
during resuming.

a504e64ab42bcc27074ea37405d06833ed6e0820 is first bad commit
commit a504e64ab42bcc27074ea37405d06833ed6e0820
Author: Stephen Hemminger <shemminger@linux-foundation.org>
Date:   Fri Feb 2 08:22:53 2007 -0800

    skge: WOL support

    Add WOL support for Yukon chipsets in skge device.

    Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
    Signed-off-by: Jeff Garzik <jeff@garzik.org>

:040000 040000 d3d4335e6cba330b7880b4787fbe48733e69f8fc
5845b004228d811de912a55da6a7843b72f23f81 M      drivers

http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc5/git-config2

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: ATA ACPI (was Re: Linux 2.6.21-rc5)
  2007-03-27 17:07   ` Linus Torvalds
@ 2007-03-27 18:48     ` Jeff Garzik
  0 siblings, 0 replies; 128+ messages in thread
From: Jeff Garzik @ 2007-03-27 18:48 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: IDE/ATA development list, Linux Kernel Mailing List, Alan,
	Tejun Heo, Len Brown, Kristen Carlson Accardi

Linus Torvalds wrote:
> 
> On Tue, 27 Mar 2007, Jeff Garzik wrote:
>> FWIW, I'm still leaning towards disabling libata ACPI support by default for
>> 2.6.21.
> 
> Hey, I'm not going to argue against anything that says "disable ACPI". Of 
> *course* it should be disabled if there aren't thousands of machines that 
> are in user hands that actually need it (and none that regress).

It's required to access data at all (BIOS-supplied password [un]locks 
disk), in a small minority of configurations.  It's strongly suggested 
for reliable suspend/resume, particularly on laptops, where libata ACPI 
support fixes some suspend/resume problems.

Some BIOSen also want to apply drive+board-specific errata workarounds. 
  That's OK, but ideally we should know about those in the kernel.

"none that regress" is the problem though.  Buggy tables, unexercised 
ACPI code paths, and in a few cases unexpected post-ACPI 
drive/controller behavior expose regressions.


> Anybody want to send me a patch?

Since everybody is OK with my plan, I'll send one today along with the 
rest of the post-vacation 2.6.21-rc bug fixes.

	Jeff



^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.21-rc5
  2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
                   ` (12 preceding siblings ...)
  2007-03-27 18:34 ` Michal Piotrowski
@ 2007-03-27 18:53 ` Michal Piotrowski
  2007-03-28 14:30   ` Andi Kleen
       [not found] ` <20070327230024.GJ16477@stusta.de>
                   ` (5 subsequent siblings)
  19 siblings, 1 reply; 128+ messages in thread
From: Michal Piotrowski @ 2007-03-27 18:53 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Andrew Morton, Andi Kleen

Linus Torvalds napisał(a):
> There's various fixes here, ranging from some architecture updates (ia64, 
> ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.
> 
> And random one-liners.
> 

I found this in mm snapshot
http://www.ussg.iu.edu/hypermail/linux/kernel/0703.2/1367.html
it's in mainline too.

Andi, any progress with this bug?

BUG: using smp_processor_id() in preemptible [00000001] code: mount/7245
caller is avail_to_resrv_perfctr_nmi_bit+0x1a/0x32
 [<c0105039>] show_trace_log_lvl+0x1a/0x2f
 [<c0105720>] show_trace+0x12/0x14
 [<c01057d2>] dump_stack+0x16/0x18
 [<c01f911e>] debug_smp_processor_id+0xa2/0xb4
 [<c0115832>] avail_to_resrv_perfctr_nmi_bit+0x1a/0x32
 [<fdca69b5>] nmi_create_files+0x2a/0x10e [oprofile]
 [<fdca5f4e>] oprofile_create_files+0xe6/0xec [oprofile]
 [<fdca6153>] oprofilefs_fill_super+0x78/0x7e [oprofile]
 [<c0173516>] get_sb_single+0x46/0x8c
 [<fdca608b>] oprofilefs_get_sb+0x1c/0x1e [oprofile]
 [<c0173406>] vfs_kern_mount+0x81/0xf1
 [<c01734be>] do_kern_mount+0x30/0x42
 [<c0185be9>] do_mount+0x601/0x678
 [<c0185ccf>] sys_mount+0x6f/0xa4
 [<c0104060>] syscall_call+0x7/0xb
 =======================
BUG: using smp_processor_id() in preemptible [00000001] code: mount/7245
caller is avail_to_resrv_perfctr_nmi_bit+0x1a/0x32
 [<c0105039>] show_trace_log_lvl+0x1a/0x2f
 [<c0105720>] show_trace+0x12/0x14
 [<c01057d2>] dump_stack+0x16/0x18
 [<c01f911e>] debug_smp_processor_id+0xa2/0xb4
 [<c0115832>] avail_to_resrv_perfctr_nmi_bit+0x1a/0x32
 [<fdca69b5>] nmi_create_files+0x2a/0x10e [oprofile]
 [<fdca5f4e>] oprofile_create_files+0xe6/0xec [oprofile]
 [<fdca6153>] oprofilefs_fill_super+0x78/0x7e [oprofile]
 [<c0173516>] get_sb_single+0x46/0x8c
 [<fdca608b>] oprofilefs_get_sb+0x1c/0x1e [oprofile]
 [<c0173406>] vfs_kern_mount+0x81/0xf1
 [<c01734be>] do_kern_mount+0x30/0x42
 [<c0185be9>] do_mount+0x601/0x678
 [<c0185ccf>] sys_mount+0x6f/0xa4
 [<c0104060>] syscall_call+0x7/0xb
 =======================
BUG: using smp_processor_id() in preemptible [00000001] code: mount/7245
caller is avail_to_resrv_perfctr_nmi_bit+0x1a/0x32
 [<c0105039>] show_trace_log_lvl+0x1a/0x2f
 [<c0105720>] show_trace+0x12/0x14
 [<c01057d2>] dump_stack+0x16/0x18
 [<c01f911e>] debug_smp_processor_id+0xa2/0xb4
 [<c0115832>] avail_to_resrv_perfctr_nmi_bit+0x1a/0x32
 [<fdca69b5>] nmi_create_files+0x2a/0x10e [oprofile]
 [<fdca5f4e>] oprofile_create_files+0xe6/0xec [oprofile]
 [<fdca6153>] oprofilefs_fill_super+0x78/0x7e [oprofile]
 [<c0173516>] get_sb_single+0x46/0x8c
 [<fdca608b>] oprofilefs_get_sb+0x1c/0x1e [oprofile]
 [<c0173406>] vfs_kern_mount+0x81/0xf1
 [<c01734be>] do_kern_mount+0x30/0x42
 [<c0185be9>] do_mount+0x601/0x678
 [<c0185ccf>] sys_mount+0x6f/0xa4
 [<c0104060>] syscall_call+0x7/0xb
 =======================
BUG: using smp_processor_id() in preemptible [00000001] code: mount/7245
caller is avail_to_resrv_perfctr_nmi_bit+0x1a/0x32
 [<c0105039>] show_trace_log_lvl+0x1a/0x2f
 [<c0105720>] show_trace+0x12/0x14
 [<c01057d2>] dump_stack+0x16/0x18
 [<c01f911e>] debug_smp_processor_id+0xa2/0xb4
 [<c0115832>] avail_to_resrv_perfctr_nmi_bit+0x1a/0x32
 [<fdca69b5>] nmi_create_files+0x2a/0x10e [oprofile]
 [<fdca5f4e>] oprofile_create_files+0xe6/0xec [oprofile]
 [<fdca6153>] oprofilefs_fill_super+0x78/0x7e [oprofile]
 [<c0173516>] get_sb_single+0x46/0x8c
 [<fdca608b>] oprofilefs_get_sb+0x1c/0x1e [oprofile]
 [<c0173406>] vfs_kern_mount+0x81/0xf1
 [<c01734be>] do_kern_mount+0x30/0x42
 [<c0185be9>] do_mount+0x601/0x678
 [<c0185ccf>] sys_mount+0x6f/0xa4
 [<c0104060>] syscall_call+0x7/0xb
 =======================
SELinux: initialized (dev oprofilefs, type oprofilefs), uses genfs_contexts

=================================
[ INFO: inconsistent lock state ]
2.6.21-rc5-gd4590940-dirty #128
---------------------------------
inconsistent {hardirq-on-W} -> {in-hardirq-W} usage.
firefox-bin/3542 [HC1[1]:SC0[0]:HE0:SE1] takes:
 (oprofilefs_lock){+-..}, at: [<fdca6b6a>] nmi_cpu_setup+0x15/0x4f [oprofile]
{hardirq-on-W} state was registered at:
  [<c013d338>] __lock_acquire+0x442/0xba1
  [<c013daff>] lock_acquire+0x68/0x82
  [<c031a947>] _spin_lock+0x35/0x42
  [<fdca6343>] oprofilefs_ulong_from_user+0x4e/0x74 [oprofile]
  [<fdca6393>] ulong_write_file+0x2a/0x38 [oprofile]
  [<c0171d13>] vfs_write+0xaf/0x138
  [<c01722dd>] sys_write+0x3d/0x61
  [<c0104060>] syscall_call+0x7/0xb
  [<ffffffff>] 0xffffffff
irq event stamp: 50464270
hardirqs last  enabled at (50464269): [<c0104189>] syscall_exit_work+0x11/0x26
hardirqs last disabled at (50464270): [<c0104ae9>] call_function_interrupt+0x29/0x38
softirqs last  enabled at (50462522): [<c012653b>] __do_softirq+0xe4/0xea
softirqs last disabled at (50462515): [<c01069b5>] do_softirq+0x64/0xd1

other info that might help us debug this:
no locks held by firefox-bin/3542.

stack backtrace:
 [<c0105039>] show_trace_log_lvl+0x1a/0x2f
 [<c0105720>] show_trace+0x12/0x14
 [<c01057d2>] dump_stack+0x16/0x18
 [<c013bd13>] print_usage_bug+0x140/0x14a
 [<c013c51e>] mark_lock+0xa1/0x40b
 [<c013d2a9>] __lock_acquire+0x3b3/0xba1
 [<c013daff>] lock_acquire+0x68/0x82
 [<c031a947>] _spin_lock+0x35/0x42
 [<fdca6b6a>] nmi_cpu_setup+0x15/0x4f [oprofile]
 [<c0112a61>] smp_call_function_interrupt+0x3a/0x56
 [<c0104af3>] call_function_interrupt+0x33/0x38
 =======================

http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc5/git-config2
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc5/git-dmesg

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [4/5] 2.6.21-rc5: known regressions
  2007-03-27 16:53       ` Marcus Better
@ 2007-03-27 20:50         ` Eric W. Biederman
  0 siblings, 0 replies; 128+ messages in thread
From: Eric W. Biederman @ 2007-03-27 20:50 UTC (permalink / raw)
  To: Marcus Better; +Cc: Linux Kernel Mailing List

Marcus Better <marcus@better.se> writes:

> Eric W. Biederman wrote:
>
>> >> Patch      : http://lkml.org/lkml/2007/3/24/136
>
>> Marcus any chance I could see an oops?
>
> I didn't see anything, it froze with the yellow "Linux!" sign. Any idea how to 
> get a oops?
>
>> Or you could try the patch I 
>> previously posted when debugging this with Thomas.
>
> Do you mean the one referenced above? I tried it [1] and it works.

Yes.  Sorry for being redundant. Having the bisect results after the
confirmation that the patch worked threw me.

Eric

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: ATA ACPI (was Re: Linux 2.6.21-rc5)
  2007-03-27  5:54   ` Tejun Heo
@ 2007-03-27 21:32     ` Pavel Machek
  2007-03-28  9:51       ` Tejun Heo
  0 siblings, 1 reply; 128+ messages in thread
From: Pavel Machek @ 2007-03-27 21:32 UTC (permalink / raw)
  To: Tejun Heo
  Cc: Jeff Garzik, IDE/ATA development list, Linus Torvalds,
	Linux Kernel Mailing List, Alan, Len Brown,
	Kristen Carlson Accardi

Hi!

> >>So if you have reported a regression in the 2.6.21-rc 
> >>series, please check 2.6.21-rc5, and update your 
> >>report as appropriate (whether fixed or "still 
> >>problems with xyzzy").
> >
> >[just got back from vacation, or would have sent this 
> >earlier]
> >
> >FWIW, I'm still leaning towards disabling libata ACPI 
> >support by default for 2.6.21.
> >
> >Upstream has Alan's fix for the worst PATA problems, 
> >but for different reasons, I think PATA ACPI and SATA 
> >ACPI support in libata does not feel quite ready for 
> >prime time in 2.6.21.
> >
> >Scream now, or hold your peace until 2.6.22... :)
> 
> I second disabling ACPI for 2.6.21.

Ugh.. does that mean we'll have 'regression reports' as in 'it worked
ok in -rc5, broken in final?

Well, suspend is currently so broken that we'll be flooded by reports,
anyway, but.... could we get at least define in code so that we can
tell users to flip it?

Or maybe it is enough to make libata dependend on EXPERIMETAL?
...making it dependend on BROKEN should be definitely enough...

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [4/5] 2.6.21-rc5: known regressions
  2007-03-27 10:09     ` Rafael J. Wysocki
@ 2007-03-27 22:29       ` Adrian Bunk
  -1 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-27 22:29 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
	Eric W. Biederman, pavel, linux-pm, Thomas Meyer,
	Thomas Gleixner

On Tue, Mar 27, 2007 at 12:09:13PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, 27 March 2007 03:59, Adrian Bunk wrote:
> > This email lists some known regressions in Linus' tree compared to 2.6.20.
> > 
> > If you find your name in the Cc header, you are either submitter of one
> > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > of you caused a breakage or I'm considering you in any other way
> > possibly involved with one or more of these issues.
> > 
> > Due to the huge amount of recipients, please trim the Cc when answering.
> 
> I think the following two:
>  
> > Subject    : suspend to disk: keypress required for power down
> > References : http://lkml.org/lkml/2007/3/25/78
> > Submitter  : Thomas Meyer <thomas@m3y3r.de>
> > Status     : unknown
>  
> > Subject    : suspend to disk: non-boot cpus are disabled again
> > References : http://lkml.org/lkml/2007/3/25/78
> > Submitter  : Thomas Meyer <thomas@m3y3r.de>
> > Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
> >              Eric W. Biederman <ebiederm@xmission.com>
> > Status     : problem is being debugged
> 
> are related to the same issue.
> 
> The problem is that we call disable_nonboot_cpus() in swsusp before
> powering down the system in order to avoid triggering the WARN_ON()
> in arch/x86_64/kernel/acpi/sleep.c:init_low_mapping() and this doesn't
> work well on Thomas' system.
> 
> Since the problem has been introduced by commit
> 94985134b7b46848267ed6b734320db01c974e72
> (swsusp: disable nonboot CPUs before entering platform suspend), I think it's
> better to revert this commit and remove the the WARN_ON() in
> arch/x86_64/kernel/acpi/sleep.c:init_low_mapping() (appended is a patch that
> removes the WARN_ON()).

It's now in Linus' tree.

Thomas (Meyer), are there any regressions left with the latest -git tree 
plus the MSI fix?

> Greetings,
> Rafael
>...

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


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [4/5] 2.6.21-rc5: known regressions
@ 2007-03-27 22:29       ` Adrian Bunk
  0 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-27 22:29 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Thomas Gleixner, Eric W. Biederman, Linus Torvalds,
	Andrew Morton, linux-pm, Linux Kernel Mailing List, Thomas Meyer

On Tue, Mar 27, 2007 at 12:09:13PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, 27 March 2007 03:59, Adrian Bunk wrote:
> > This email lists some known regressions in Linus' tree compared to 2.6.20.
> > 
> > If you find your name in the Cc header, you are either submitter of one
> > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > of you caused a breakage or I'm considering you in any other way
> > possibly involved with one or more of these issues.
> > 
> > Due to the huge amount of recipients, please trim the Cc when answering.
> 
> I think the following two:
>  
> > Subject    : suspend to disk: keypress required for power down
> > References : http://lkml.org/lkml/2007/3/25/78
> > Submitter  : Thomas Meyer <thomas@m3y3r.de>
> > Status     : unknown
>  
> > Subject    : suspend to disk: non-boot cpus are disabled again
> > References : http://lkml.org/lkml/2007/3/25/78
> > Submitter  : Thomas Meyer <thomas@m3y3r.de>
> > Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
> >              Eric W. Biederman <ebiederm@xmission.com>
> > Status     : problem is being debugged
> 
> are related to the same issue.
> 
> The problem is that we call disable_nonboot_cpus() in swsusp before
> powering down the system in order to avoid triggering the WARN_ON()
> in arch/x86_64/kernel/acpi/sleep.c:init_low_mapping() and this doesn't
> work well on Thomas' system.
> 
> Since the problem has been introduced by commit
> 94985134b7b46848267ed6b734320db01c974e72
> (swsusp: disable nonboot CPUs before entering platform suspend), I think it's
> better to revert this commit and remove the the WARN_ON() in
> arch/x86_64/kernel/acpi/sleep.c:init_low_mapping() (appended is a patch that
> removes the WARN_ON()).

It's now in Linus' tree.

Thomas (Meyer), are there any regressions left with the latest -git tree 
plus the MSI fix?

> Greetings,
> Rafael
>...

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

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.21-rc5
  2007-03-27 18:34 ` Michal Piotrowski
@ 2007-03-27 22:29   ` Pavel Machek
  2007-03-27 22:55     ` Michal Piotrowski
  0 siblings, 1 reply; 128+ messages in thread
From: Pavel Machek @ 2007-03-27 22:29 UTC (permalink / raw)
  To: Michal Piotrowski
  Cc: Linus Torvalds, Stephen Hemminger, Jeff Garzik,
	Rafael J. Wysocki, Linux Kernel Mailing List

Hi!
> >There's various fixes here, ranging from some architecture updates (ia64,
> >ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.
> >
> 
> Suspend to disk doesn't work for me with this patch. It hangs after
> PM: Preparing devices for restore.
> Suspending console(s)
> during resuming.
> 
> a504e64ab42bcc27074ea37405d06833ed6e0820 is first bad commit
> commit a504e64ab42bcc27074ea37405d06833ed6e0820
> Author: Stephen Hemminger <shemminger@linux-foundation.org>
> Date:   Fri Feb 2 08:22:53 2007 -0800
> 
>    skge: WOL support
> 
>    Add WOL support for Yukon chipsets in skge device.
> 
>    Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
>    Signed-off-by: Jeff Garzik <jeff@garzik.org>
> 
> :040000 040000 d3d4335e6cba330b7880b4787fbe48733e69f8fc
> 5845b004228d811de912a55da6a7843b72f23f81 M      drivers
> 
> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc5/git-config2

Do you use skge as your network device?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [4/5] 2.6.21-rc5: known regressions
  2007-03-27 22:29       ` Adrian Bunk
@ 2007-03-27 22:45         ` Thomas Meyer
  -1 siblings, 0 replies; 128+ messages in thread
From: Thomas Meyer @ 2007-03-27 22:45 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Rafael J. Wysocki, Linus Torvalds, Andrew Morton,
	Linux Kernel Mailing List, Eric W. Biederman, pavel, linux-pm,
	Thomas Gleixner

Adrian Bunk schrieb:
> It's now in Linus' tree.
>
> Thomas (Meyer), are there any regressions left with the latest -git tree 
> plus the MSI fix?
>   
No, not for me.

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [4/5] 2.6.21-rc5: known regressions
@ 2007-03-27 22:45         ` Thomas Meyer
  0 siblings, 0 replies; 128+ messages in thread
From: Thomas Meyer @ 2007-03-27 22:45 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Thomas Gleixner, Eric W. Biederman, linux-pm, Andrew Morton,
	Linus Torvalds, Linux Kernel Mailing List

Adrian Bunk schrieb:
> It's now in Linus' tree.
>
> Thomas (Meyer), are there any regressions left with the latest -git tree 
> plus the MSI fix?
>   
No, not for me.

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.21-rc5
  2007-03-27 22:29   ` Pavel Machek
@ 2007-03-27 22:55     ` Michal Piotrowski
  0 siblings, 0 replies; 128+ messages in thread
From: Michal Piotrowski @ 2007-03-27 22:55 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Michal Piotrowski, Linus Torvalds, Stephen Hemminger,
	Jeff Garzik, Rafael J. Wysocki, Linux Kernel Mailing List

Pavel Machek napisał(a):
> Hi!
>>> There's various fixes here, ranging from some architecture updates (ia64,
>>> ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.
>>>
>> Suspend to disk doesn't work for me with this patch. It hangs after
>> PM: Preparing devices for restore.
>> Suspending console(s)
>> during resuming.
>>
>> a504e64ab42bcc27074ea37405d06833ed6e0820 is first bad commit
>> commit a504e64ab42bcc27074ea37405d06833ed6e0820
>> Author: Stephen Hemminger <shemminger@linux-foundation.org>
>> Date:   Fri Feb 2 08:22:53 2007 -0800
>>
>>    skge: WOL support
>>
>>    Add WOL support for Yukon chipsets in skge device.
>>
>>    Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
>>    Signed-off-by: Jeff Garzik <jeff@garzik.org>
>>
>> :040000 040000 d3d4335e6cba330b7880b4787fbe48733e69f8fc
>> 5845b004228d811de912a55da6a7843b72f23f81 M      drivers
>>
>> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc5/git-config2
> 
> Do you use skge as your network device?

Yes, I have a Marvell based onboard NIC.

02:05.0 Ethernet controller: 3Com Corporation 3c940 10/100/1000Base-T [Marvell] (rev 12)
        Subsystem: ASUSTeK Computer Inc. A7V600/P4P800/K8V motherboard
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (5750ns min, 7750ns max), Cache Line Size: 16 bytes
        Interrupt: pin A routed to IRQ 17
        Region 0: Memory at f7ffc000 (32-bit, non-prefetchable) [size=16K]
        Region 1: I/O ports at e800 [size=256]
        Capabilities: [48] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=1 PME-
        Capabilities: [50] Vital Product Data


> 									Pavel

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: 2.6.21-rc5: known regressions with patches
       [not found] ` <20070327230024.GJ16477@stusta.de>
@ 2007-03-27 23:10   ` Rafael J. Wysocki
  2007-03-28  0:50   ` Jay Cliburn
  1 sibling, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2007-03-27 23:10 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
	Maxim Levitsky, tigran

On Wednesday, 28 March 2007 01:00, Adrian Bunk wrote:
> This email lists some known regressions in Linus' tree compared to 2.6.20
> with patches available.
> 
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a breakage or I'm considering you in any other way
> possibly involved with one or more of these issues.
> 
> Due to the huge amount of recipients, please trim the Cc when answering.
 
> Subject    : suspend to disk hangs  (microcode driver)
> References : http://lkml.org/lkml/2007/3/16/126
> Submitter  : Maxim Levitsky <maximlevitsky@gmail.com>
> Caused-By  : Rafael J. Wysocki <rjw@sisk.pl>
>              commit e3c7db621bed4afb8e231cb005057f2feb5db557
>              commit ed746e3b18f4df18afa3763155972c5835f284c5
>              commit 259130526c267550bc365d3015917d90667732f1
> Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
> Patch      : http://lkml.org/lkml/2007/3/23/179
> Status     : patch available

Updated patch is available at http://lkml.org/lkml/2007/3/25/71

Greetings,
Rafael

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: 2.6.21-rc5: known regressions with patches
       [not found] ` <20070327230024.GJ16477@stusta.de>
  2007-03-27 23:10   ` 2.6.21-rc5: known regressions with patches Rafael J. Wysocki
@ 2007-03-28  0:50   ` Jay Cliburn
  1 sibling, 0 replies; 128+ messages in thread
From: Jay Cliburn @ 2007-03-28  0:50 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, netdev,
	Jose Alberto Reguero, Chris Snook

On Wed, 28 Mar 2007 01:00:24 +0200
Adrian Bunk <bunk@stusta.de> wrote:

> Subject    : atl1 net driver: problem with sockets
> References : http://lkml.org/lkml/2007/3/21/248
> Submitter  : Jose Alberto Reguero <jareguero@telefonica.net>
> Patch      : http://marc.info/?l=linux-netdev&m=117502041808665&w=2
> Status     : patch available

Patch submitted to netdev.  http://lkml.org/lkml/2007/3/27/321

Best,
Jay

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: ATA ACPI (was Re: Linux 2.6.21-rc5)
  2007-03-27 21:32     ` Pavel Machek
@ 2007-03-28  9:51       ` Tejun Heo
  0 siblings, 0 replies; 128+ messages in thread
From: Tejun Heo @ 2007-03-28  9:51 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Jeff Garzik, IDE/ATA development list, Linus Torvalds,
	Linux Kernel Mailing List, Alan, Len Brown,
	Kristen Carlson Accardi

Pavel Machek wrote:
> Hi!
> 
>>>> So if you have reported a regression in the 2.6.21-rc 
>>>> series, please check 2.6.21-rc5, and update your 
>>>> report as appropriate (whether fixed or "still 
>>>> problems with xyzzy").
>>> [just got back from vacation, or would have sent this 
>>> earlier]
>>>
>>> FWIW, I'm still leaning towards disabling libata ACPI 
>>> support by default for 2.6.21.
>>>
>>> Upstream has Alan's fix for the worst PATA problems, 
>>> but for different reasons, I think PATA ACPI and SATA 
>>> ACPI support in libata does not feel quite ready for 
>>> prime time in 2.6.21.
>>>
>>> Scream now, or hold your peace until 2.6.22... :)
>> I second disabling ACPI for 2.6.21.
> 
> Ugh.. does that mean we'll have 'regression reports' as in 'it worked
> ok in -rc5, broken in final?
> 
> Well, suspend is currently so broken that we'll be flooded by reports,
> anyway, but.... could we get at least define in code so that we can
> tell users to flip it?

Just the default value for libata.noacpi is changed to 1, so user can
easily reenable it by passing boot/module parameter.

-- 
tejun

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [4/5] 2.6.21-rc5: known regressions
  2007-03-27  1:59   ` Adrian Bunk
                     ` (2 preceding siblings ...)
  (?)
@ 2007-03-28 12:19   ` Ingo Molnar
  2007-03-28 12:41     ` Ingo Molnar
  -1 siblings, 1 reply; 128+ messages in thread
From: Ingo Molnar @ 2007-03-28 12:19 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Linus Torvalds, Andrew Morton, linux-kernel, Eric W. Biederman,
	Thomas Meyer, Frederic Riss, Marcus Better


* Adrian Bunk <bunk@stusta.de> wrote:

> Subject    : second suspend to disk in a row results in an oops  (MSI)
> References : http://lkml.org/lkml/2007/3/17/43
>              http://lkml.org/lkml/2007/3/22/150
>              http://lkml.org/lkml/2007/3/26/205
>              http://lkml.org/lkml/2007/3/26/76
> Submitter  : Thomas Meyer <thomas@m3y3r.de>
>              Frédéric Riss <frederic.riss@gmail.com>
>              Marcus Better <marcus@better.se>
> Handled-By : Eric W. Biederman <ebiederm@xmission.com>
> Patch      : http://lkml.org/lkml/2007/3/24/136
> Status     : patch was suggested

i can reproduce a crash on the second suspend-to-ram, on a T60. I get a 
crash here:

 #ifdef CONFIG_PM
 static void __pci_restore_msi_state(struct pci_dev *dev)
 {
         int pos;
         u16 control;
         struct msi_desc *entry;

         if (!dev->msi_enabled)
                 return;

         entry = get_irq_msi(dev->irq);
         pos = entry->msi_attrib.pos; <-------- crash on NULL dereference


i.e. 'entry' is NULL after get_irq_msi(). (i can see the crash only on 
the VGA screen so no dump of it available. Can write down more info if  
it's helpful.)

I have tried Eric's patch above but now i always get a hang after 
"system 00:00: resuming", already upon the first suspend-resume. Not 
even the NMI watchdog can get the system out of that hang.

	Ingo

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [4/5] 2.6.21-rc5: known regressions
  2007-03-28 12:19   ` Ingo Molnar
@ 2007-03-28 12:41     ` Ingo Molnar
  2007-03-28 13:03       ` Ingo Molnar
  0 siblings, 1 reply; 128+ messages in thread
From: Ingo Molnar @ 2007-03-28 12:41 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Linus Torvalds, Andrew Morton, linux-kernel, Eric W. Biederman,
	Thomas Meyer, Frederic Riss, Marcus Better


* Ingo Molnar <mingo@elte.hu> wrote:

>          entry = get_irq_msi(dev->irq);
>          pos = entry->msi_attrib.pos; <-------- crash on NULL dereference
> 
> 
> i.e. 'entry' is NULL after get_irq_msi(). (i can see the crash only on 
> the VGA screen so no dump of it available. Can write down more info if 
> it's helpful.)
> 
> I have tried Eric's patch above but now i always get a hang after 
> "system 00:00: resuming", already upon the first suspend-resume. Not 
> even the NMI watchdog can get the system out of that hang.

find below the PM log of a successful suspend/resume cycle. (I've marked 
the place that hangs with '[hard hang]')

	Ingo

---------------->
PM: Preparing system for mem sleep
Stopping tasks ... done.
psmouse serio2: suspend
psmouse serio1: suspend
atkbd serio0: suspend
i8042 i8042: suspend
sd 0:0:0:0: suspend
ide 0.0: suspend
serial8250 serial8250: suspend
platform vesafb.0: suspend
pci_express 0000:00:1c.3:pcie03: suspend
pci_express 0000:00:1c.3:pcie02: suspend
pci_express 0000:00:1c.3:pcie00: suspend
pci_express 0000:00:1c.2:pcie03: suspend
pci_express 0000:00:1c.2:pcie02: suspend
pci_express 0000:00:1c.2:pcie00: suspend
pci_express 0000:00:1c.1:pcie03: suspend
pci_express 0000:00:1c.1:pcie02: suspend
pci_express 0000:00:1c.1:pcie00: suspend
pci_express 0000:00:1c.0:pcie03: suspend
pci_express 0000:00:1c.0:pcie02: suspend
pci_express 0000:00:1c.0:pcie00: suspend
platform pcspkr: suspend
pnp 00:0a: suspend
i8042 aux 00:09: suspend
i8042 kbd 00:08: suspend
pnp 00:07: suspend
pnp 00:06: suspend
pnp 00:05: suspend
pnp 00:04: suspend
pnp 00:03: suspend
system 00:02: suspend
pnp 00:01: suspend
system 00:00: suspend
yenta_cardbus 0000:15:00.0: suspend
pci 0000:03:00.0: suspend
e1000 0000:02:00.0: suspend
pci 0000:03:00.0: resuming
yenta_cardbus 0000:15:00.0: resuming
PM: Writing back config space on device 0000:15:00.0 at offset f (was 34001ff, writing 5c0010b)
PM: Writing back config space on device 0000:15:00.0 at offset e (was 0, writing 94fc)
PM: Writing back config space on device 0000:15:00.0 at offset d (was 0, writing 9400)
PM: Writing back config space on device 0000:15:00.0 at offset c (was 0, writing 90fc)
PM: Writing back config space on device 0000:15:00.0 at offset b (was 0, writing 9000)
PM: Writing back config space on device 0000:15:00.0 at offset a (was 0, writing 8bfff000)
PM: Writing back config space on device 0000:15:00.0 at offset 9 (was 0, writing 88000000)
PM: Writing back config space on device 0000:15:00.0 at offset 8 (was 0, writing e3fff000)
PM: Writing back config space on device 0000:15:00.0 at offset 7 (was 0, writing e0000000)
PM: Writing back config space on device 0000:15:00.0 at offset 6 (was 0, writing b0171615)
PM: Writing back config space on device 0000:15:00.0 at offset 4 (was 0, writing e4300000)
PM: Writing back config space on device 0000:15:00.0 at offset 3 (was 20000, writing 2a820)
PM: Writing back config space on device 0000:15:00.0 at offset 1 (was 2100000, writing 2100007)
system 00:00: resuming <-------------- [ hard hang ]
pnp 00:01: resuming
system 00:02: resuming
pnp 00:03: resuming
pnp 00:04: resuming
pnp 00:05: resuming
pnp 00:06: resuming
pnp 00:07: resuming
i8042 kbd 00:08: resuming
i8042 aux 00:09: resuming
pnp 00:0a: resuming
platform pcspkr: resuming
pci_express 0000:00:1c.0:pcie00: resuming
pci_express 0000:00:1c.0:pcie02: resuming
pci_express 0000:00:1c.0:pcie03: resuming
pci_express 0000:00:1c.1:pcie00: resuming
pci_express 0000:00:1c.1:pcie02: resuming
pci_express 0000:00:1c.1:pcie03: resuming
pci_express 0000:00:1c.2:pcie00: resuming
pci_express 0000:00:1c.2:pcie02: resuming
pci_express 0000:00:1c.2:pcie03: resuming
pci_express 0000:00:1c.3:pcie00: resuming
pci_express 0000:00:1c.3:pcie02: resuming
pci_express 0000:00:1c.3:pcie03: resuming
platform vesafb.0: resuming
serial8250 serial8250: resuming
ide 0.0: resuming
sd 0:0:0:0: resuming
i8042 i8042: resuming
atkbd serio0: resuming
psmouse serio1: resuming
ata2: SATA link down (SStatus 0 SControl 0)
ata3: SATA link down (SStatus 0 SControl 0)
ata4: SATA link down (SStatus 0 SControl 0)
psmouse serio2: resuming
ata1: waiting for device to spin up (7 secs)
Restarting tasks ... done.
e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: configured for UDMA/100
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
PM: Preparing system for mem sleep

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [4/5] 2.6.21-rc5: known regressions
  2007-03-28 12:41     ` Ingo Molnar
@ 2007-03-28 13:03       ` Ingo Molnar
  2007-03-28 13:06         ` [patch] MSI-X: fix resume crash Ingo Molnar
  0 siblings, 1 reply; 128+ messages in thread
From: Ingo Molnar @ 2007-03-28 13:03 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Linus Torvalds, Andrew Morton, linux-kernel, Eric W. Biederman,
	Thomas Meyer, Frederic Riss, Marcus Better


* Ingo Molnar <mingo@elte.hu> wrote:

> PM: Writing back config space on device 0000:15:00.0 at offset 4 (was 0, writing e4300000)
> PM: Writing back config space on device 0000:15:00.0 at offset 3 (was 20000, writing 2a820)
> PM: Writing back config space on device 0000:15:00.0 at offset 1 (was 2100000, writing 2100007)
> system 00:00: resuming <-------------- [ hard hang ]
> pnp 00:01: resuming
> system 00:02: resuming
> pnp 00:03: resuming

ok, this was a red herring: the hard hang was an effect of netconsole 
combined with CONFIG_DISABLE_CONSOLE_SUSPEND. Disabling netconsole 
solved it. I'll now re-test Eric's MSI patch.

	Ingo

^ permalink raw reply	[flat|nested] 128+ messages in thread

* [patch] MSI-X: fix resume crash
  2007-03-28 13:03       ` Ingo Molnar
@ 2007-03-28 13:06         ` Ingo Molnar
  2007-03-28 13:31           ` Eric W. Biederman
  2007-03-29  4:30           ` Len Brown
  0 siblings, 2 replies; 128+ messages in thread
From: Ingo Molnar @ 2007-03-28 13:06 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Linus Torvalds, Andrew Morton, linux-kernel, Eric W. Biederman,
	Thomas Meyer, Frederic Riss, Marcus Better, Len Brown


* Ingo Molnar <mingo@elte.hu> wrote:

> [...] I'll now re-test Eric's MSI patch.

Eric's patch seems to have done the trick on my T60: i've done 10 
suspend+resumes and each worked fine. I've tidied up the description 
part of Eric's patch a bit for upstream application - find it below.

	Ingo

---------------------->
Subject: [patch] MSI-X: fix resume crash
From: Eric W. Biederman <ebiederm@xmission.com>

I think the right solution is to simply make pci_enable_device just flip 
enable bits and move the rest of the work someplace else.

However a thorough cleanup is a little extreme for this point in the 
release cycle, so I think a quick hack that makes the code not stomp the 
irq when msi irq's are enabled should be the first fix.  Then we can 
later make the code not change the irqs at all.

Tony, Len the way pci_disable_device is being used in a suspend/resume 
path by a few drivers is completely incompatible with the way irqs are 
allocated on ia64.  In particular people the following sequence occurs 
in several drivers.

probe:
  pci_enable_device(pdev);
  request_irq(pdev->irq);
suspend:
  pci_disable_device(pdev);
resume:
  pci_enable_device(pdev);
remove:
  free_irq(pdev->irq);
  pci_disable_device(pdev);

What I'm proposing we do is move the irq allocation code out of 
pci_enable_device and the irq freeing code out of pci_disable_device in 
the future.  If we move ia64 to a model where the irq number equal the 
gsi like we have for x86_64 and are in the middle of for i386 that 
should be pretty straight forward.  It would even be relatively simple 
to delay vector allocation in that context until request_irq, if we 
needed the delayed allocation benefit.  Do you two have any problems 
with moving in that direction?

If fixing the arch code is unacceptable for some reason I'm not aware of 
we need to audit the 10-20 drivers that call pci_disable_device in their 
suspend/resume processing and ensure that they have freed all of the 
irqs before that point.  Given that I have bug reports on the msi path I 
know that isn't true.

From: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/cris/arch-v32/drivers/pci/bios.c |    4 +++-
 arch/frv/mb93090-mb00/pci-vdk.c       |    3 ++-
 arch/i386/pci/common.c                |    6 ++++--
 arch/ia64/pci/pci.c                   |    8 ++++++--
 4 files changed, 15 insertions(+), 6 deletions(-)

Index: linux/arch/cris/arch-v32/drivers/pci/bios.c
===================================================================
--- linux.orig/arch/cris/arch-v32/drivers/pci/bios.c
+++ linux/arch/cris/arch-v32/drivers/pci/bios.c
@@ -100,7 +100,9 @@ int pcibios_enable_device(struct pci_dev
 	if ((err = pcibios_enable_resources(dev, mask)) < 0)
 		return err;
 
-	return pcibios_enable_irq(dev);
+	if (!dev->msi_enabled)
+		pcibios_enable_irq(dev);
+	return 0;
 }
 
 int pcibios_assign_resources(void)
Index: linux/arch/frv/mb93090-mb00/pci-vdk.c
===================================================================
--- linux.orig/arch/frv/mb93090-mb00/pci-vdk.c
+++ linux/arch/frv/mb93090-mb00/pci-vdk.c
@@ -466,6 +466,7 @@ int pcibios_enable_device(struct pci_dev
 
 	if ((err = pcibios_enable_resources(dev, mask)) < 0)
 		return err;
-	pcibios_enable_irq(dev);
+	if (!dev->msi_enabled)
+		pcibios_enable_irq(dev);
 	return 0;
 }
Index: linux/arch/i386/pci/common.c
===================================================================
--- linux.orig/arch/i386/pci/common.c
+++ linux/arch/i386/pci/common.c
@@ -434,11 +434,13 @@ int pcibios_enable_device(struct pci_dev
 	if ((err = pcibios_enable_resources(dev, mask)) < 0)
 		return err;
 
-	return pcibios_enable_irq(dev);
+	if (!dev->msi_enabled)
+		return pcibios_enable_irq(dev);
+	return 0;
 }
 
 void pcibios_disable_device (struct pci_dev *dev)
 {
-	if (pcibios_disable_irq)
+	if (!dev->msi_enabled && pcibios_disable_irq)
 		pcibios_disable_irq(dev);
 }
Index: linux/arch/ia64/pci/pci.c
===================================================================
--- linux.orig/arch/ia64/pci/pci.c
+++ linux/arch/ia64/pci/pci.c
@@ -557,14 +557,18 @@ pcibios_enable_device (struct pci_dev *d
 	if (ret < 0)
 		return ret;
 
-	return acpi_pci_irq_enable(dev);
+	if (!dev->msi_enabled)
+		return acpi_pci_irq_enable(dev);
+	return 0;
 }
 
 void
 pcibios_disable_device (struct pci_dev *dev)
 {
 	BUG_ON(atomic_read(&dev->enable_cnt));
-	acpi_pci_irq_disable(dev);
+	if (!dev->msi_enabled)
+		acpi_pci_irq_disable(dev);
+	return 0;
 }
 
 void

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [patch] MSI-X: fix resume crash
  2007-03-28 13:06         ` [patch] MSI-X: fix resume crash Ingo Molnar
@ 2007-03-28 13:31           ` Eric W. Biederman
  2007-03-28 13:36             ` Ingo Molnar
  2007-03-29  4:30           ` Len Brown
  1 sibling, 1 reply; 128+ messages in thread
From: Eric W. Biederman @ 2007-03-28 13:31 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel,
	Thomas Meyer, Frederic Riss, Marcus Better, Len Brown

Ingo Molnar <mingo@elte.hu> writes:

> * Ingo Molnar <mingo@elte.hu> wrote:
>
>> [...] I'll now re-test Eric's MSI patch.
>
> Eric's patch seems to have done the trick on my T60: i've done 10 
> suspend+resumes and each worked fine. I've tidied up the description 
> part of Eric's patch a bit for upstream application - find it below.

Thanks.  Tidying up the description has been on my todo list for the
last little bit but I just haven't gotten there.

I've gotten at least Tony's sign off on the architectural direction
so there is nothing to prevent this patch from going in.  Unless
Linus or someone wants a more thorough patch this late in the
release cycle.

Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>


> ---------------------->
> Subject: [patch] MSI-X: fix resume crash
> From: Eric W. Biederman <ebiederm@xmission.com>
>
> I think the right solution is to simply make pci_enable_device just flip 
> enable bits and move the rest of the work someplace else.
>
> However a thorough cleanup is a little extreme for this point in the 
> release cycle, so I think a quick hack that makes the code not stomp the 
> irq when msi irq's are enabled should be the first fix.  Then we can 
> later make the code not change the irqs at all.
>
> Tony, Len the way pci_disable_device is being used in a suspend/resume 
> path by a few drivers is completely incompatible with the way irqs are 
> allocated on ia64.  In particular people the following sequence occurs 
> in several drivers.
>
> probe:
>   pci_enable_device(pdev);
>   request_irq(pdev->irq);
> suspend:
>   pci_disable_device(pdev);
> resume:
>   pci_enable_device(pdev);
> remove:
>   free_irq(pdev->irq);
>   pci_disable_device(pdev);
>
> What I'm proposing we do is move the irq allocation code out of 
> pci_enable_device and the irq freeing code out of pci_disable_device in 
> the future.  If we move ia64 to a model where the irq number equal the 
> gsi like we have for x86_64 and are in the middle of for i386 that 
> should be pretty straight forward.  It would even be relatively simple 
> to delay vector allocation in that context until request_irq, if we 
> needed the delayed allocation benefit.  Do you two have any problems 
> with moving in that direction?
>
> If fixing the arch code is unacceptable for some reason I'm not aware of 
> we need to audit the 10-20 drivers that call pci_disable_device in their 
> suspend/resume processing and ensure that they have freed all of the 
> irqs before that point.  Given that I have bug reports on the msi path I 
> know that isn't true.
>
> From: Eric W. Biederman <ebiederm@xmission.com>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
>  arch/cris/arch-v32/drivers/pci/bios.c |    4 +++-
>  arch/frv/mb93090-mb00/pci-vdk.c       |    3 ++-
>  arch/i386/pci/common.c                |    6 ++++--
>  arch/ia64/pci/pci.c                   |    8 ++++++--
>  4 files changed, 15 insertions(+), 6 deletions(-)
>
> Index: linux/arch/cris/arch-v32/drivers/pci/bios.c
> ===================================================================
> --- linux.orig/arch/cris/arch-v32/drivers/pci/bios.c
> +++ linux/arch/cris/arch-v32/drivers/pci/bios.c
> @@ -100,7 +100,9 @@ int pcibios_enable_device(struct pci_dev
>  	if ((err = pcibios_enable_resources(dev, mask)) < 0)
>  		return err;
>  
> -	return pcibios_enable_irq(dev);
> +	if (!dev->msi_enabled)
> +		pcibios_enable_irq(dev);
> +	return 0;
>  }
>  
>  int pcibios_assign_resources(void)
> Index: linux/arch/frv/mb93090-mb00/pci-vdk.c
> ===================================================================
> --- linux.orig/arch/frv/mb93090-mb00/pci-vdk.c
> +++ linux/arch/frv/mb93090-mb00/pci-vdk.c
> @@ -466,6 +466,7 @@ int pcibios_enable_device(struct pci_dev
>  
>  	if ((err = pcibios_enable_resources(dev, mask)) < 0)
>  		return err;
> -	pcibios_enable_irq(dev);
> +	if (!dev->msi_enabled)
> +		pcibios_enable_irq(dev);
>  	return 0;
>  }
> Index: linux/arch/i386/pci/common.c
> ===================================================================
> --- linux.orig/arch/i386/pci/common.c
> +++ linux/arch/i386/pci/common.c
> @@ -434,11 +434,13 @@ int pcibios_enable_device(struct pci_dev
>  	if ((err = pcibios_enable_resources(dev, mask)) < 0)
>  		return err;
>  
> -	return pcibios_enable_irq(dev);
> +	if (!dev->msi_enabled)
> +		return pcibios_enable_irq(dev);
> +	return 0;
>  }
>  
>  void pcibios_disable_device (struct pci_dev *dev)
>  {
> -	if (pcibios_disable_irq)
> +	if (!dev->msi_enabled && pcibios_disable_irq)
>  		pcibios_disable_irq(dev);
>  }
> Index: linux/arch/ia64/pci/pci.c
> ===================================================================
> --- linux.orig/arch/ia64/pci/pci.c
> +++ linux/arch/ia64/pci/pci.c
> @@ -557,14 +557,18 @@ pcibios_enable_device (struct pci_dev *d
>  	if (ret < 0)
>  		return ret;
>  
> -	return acpi_pci_irq_enable(dev);
> +	if (!dev->msi_enabled)
> +		return acpi_pci_irq_enable(dev);
> +	return 0;
>  }
>  
>  void
>  pcibios_disable_device (struct pci_dev *dev)
>  {
>  	BUG_ON(atomic_read(&dev->enable_cnt));
> -	acpi_pci_irq_disable(dev);
> +	if (!dev->msi_enabled)
> +		acpi_pci_irq_disable(dev);
> +	return 0;
>  }
>  
>  void

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [patch] MSI-X: fix resume crash
  2007-03-28 13:31           ` Eric W. Biederman
@ 2007-03-28 13:36             ` Ingo Molnar
  0 siblings, 0 replies; 128+ messages in thread
From: Ingo Molnar @ 2007-03-28 13:36 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel,
	Thomas Meyer, Frederic Riss, Marcus Better, Len Brown, Luck,
	Tony


* Eric W. Biederman <ebiederm@xmission.com> wrote:

> > Eric's patch seems to have done the trick on my T60: i've done 10 
> > suspend+resumes and each worked fine. I've tidied up the description 
> > part of Eric's patch a bit for upstream application - find it below.
> 
> Thanks.  Tidying up the description has been on my todo list for the 
> last little bit but I just haven't gotten there.
> 
> I've gotten at least Tony's sign off on the architectural direction so 
> there is nothing to prevent this patch from going in.  Unless Linus or 
> someone wants a more thorough patch this late in the release cycle.
> 
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>

i've updated the patch below with your sign-off, and trimmed the 
description to the relevant bits, for easy upstream application.

	Ingo

------------->
Subject: [patch] MSI-X: fix resume crash
From: Eric W. Biederman <ebiederm@xmission.com>

So I think the right solution is to simply make pci_enable_device just 
flip enable bits and move the rest of the work someplace else.

However a thorough cleanup is a little extreme for this point in the 
release cycle, so I think a quick hack that makes the code not stomp the 
irq when msi irq's are enabled should be the first fix.  Then we can 
later make the code not change the irqs at all.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/cris/arch-v32/drivers/pci/bios.c |    4 +++-
 arch/frv/mb93090-mb00/pci-vdk.c       |    3 ++-
 arch/i386/pci/common.c                |    6 ++++--
 arch/ia64/pci/pci.c                   |    8 ++++++--
 4 files changed, 15 insertions(+), 6 deletions(-)

Index: linux/arch/cris/arch-v32/drivers/pci/bios.c
===================================================================
--- linux.orig/arch/cris/arch-v32/drivers/pci/bios.c
+++ linux/arch/cris/arch-v32/drivers/pci/bios.c
@@ -100,7 +100,9 @@ int pcibios_enable_device(struct pci_dev
 	if ((err = pcibios_enable_resources(dev, mask)) < 0)
 		return err;
 
-	return pcibios_enable_irq(dev);
+	if (!dev->msi_enabled)
+		pcibios_enable_irq(dev);
+	return 0;
 }
 
 int pcibios_assign_resources(void)
Index: linux/arch/frv/mb93090-mb00/pci-vdk.c
===================================================================
--- linux.orig/arch/frv/mb93090-mb00/pci-vdk.c
+++ linux/arch/frv/mb93090-mb00/pci-vdk.c
@@ -466,6 +466,7 @@ int pcibios_enable_device(struct pci_dev
 
 	if ((err = pcibios_enable_resources(dev, mask)) < 0)
 		return err;
-	pcibios_enable_irq(dev);
+	if (!dev->msi_enabled)
+		pcibios_enable_irq(dev);
 	return 0;
 }
Index: linux/arch/i386/pci/common.c
===================================================================
--- linux.orig/arch/i386/pci/common.c
+++ linux/arch/i386/pci/common.c
@@ -434,11 +434,13 @@ int pcibios_enable_device(struct pci_dev
 	if ((err = pcibios_enable_resources(dev, mask)) < 0)
 		return err;
 
-	return pcibios_enable_irq(dev);
+	if (!dev->msi_enabled)
+		return pcibios_enable_irq(dev);
+	return 0;
 }
 
 void pcibios_disable_device (struct pci_dev *dev)
 {
-	if (pcibios_disable_irq)
+	if (!dev->msi_enabled && pcibios_disable_irq)
 		pcibios_disable_irq(dev);
 }
Index: linux/arch/ia64/pci/pci.c
===================================================================
--- linux.orig/arch/ia64/pci/pci.c
+++ linux/arch/ia64/pci/pci.c
@@ -557,14 +557,18 @@ pcibios_enable_device (struct pci_dev *d
 	if (ret < 0)
 		return ret;
 
-	return acpi_pci_irq_enable(dev);
+	if (!dev->msi_enabled)
+		return acpi_pci_irq_enable(dev);
+	return 0;
 }
 
 void
 pcibios_disable_device (struct pci_dev *dev)
 {
 	BUG_ON(atomic_read(&dev->enable_cnt));
-	acpi_pci_irq_disable(dev);
+	if (!dev->msi_enabled)
+		acpi_pci_irq_disable(dev);
+	return 0;
 }
 
 void

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.21-rc5
  2007-03-27 18:53 ` Michal Piotrowski
@ 2007-03-28 14:30   ` Andi Kleen
  2007-03-28 14:56     ` Michal Piotrowski
  2007-03-28 17:56     ` Linus Torvalds
  0 siblings, 2 replies; 128+ messages in thread
From: Andi Kleen @ 2007-03-28 14:30 UTC (permalink / raw)
  To: Michal Piotrowski
  Cc: Linus Torvalds, Linux Kernel Mailing List, Andrew Morton

On Tuesday 27 March 2007 20:53, Michal Piotrowski wrote:
> Linus Torvalds napisał(a):
> > There's various fixes here, ranging from some architecture updates (ia64, 
> > ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.
> > 
> > And random one-liners.
> > 
> 
> I found this in mm snapshot
> http://www.ussg.iu.edu/hypermail/linux/kernel/0703.2/1367.html
> it's in mainline too.
> 
> Andi, any progress with this bug?

Can you test this patch please? 

-Andi

i386/x86-64: Convert nmi reservation to be global

It doesn't make much sense to have this per CPU, because all
the services using NMIs run on all CPUs. So make it global.

This also fixes a warning about unprotected use of smp_processor_id
on preemptible kernels.

Signed-off-by: Andi Kleen <ak@suse.de>

Index: linux/arch/i386/kernel/nmi.c
===================================================================
--- linux.orig/arch/i386/kernel/nmi.c
+++ linux/arch/i386/kernel/nmi.c
@@ -41,8 +41,8 @@ int nmi_watchdog_enabled;
  *   different subsystems this reservation system just tries to coordinate
  *   things a little
  */
-static DEFINE_PER_CPU(unsigned long, perfctr_nmi_owner);
-static DEFINE_PER_CPU(unsigned long, evntsel_nmi_owner[3]);
+static unsigned long perfctr_nmi_owner;
+static unsigned long evntsel_nmi_owner[3];
 
 static cpumask_t backtrace_mask = CPU_MASK_NONE;
 
@@ -124,7 +124,7 @@ int avail_to_resrv_perfctr_nmi_bit(unsig
 {
 	BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-	return (!test_bit(counter, &__get_cpu_var(perfctr_nmi_owner)));
+	return (!test_bit(counter, &perfctr_nmi_owner));
 }
 
 /* checks the an msr for availability */
@@ -135,7 +135,7 @@ int avail_to_resrv_perfctr_nmi(unsigned 
 	counter = nmi_perfctr_msr_to_bit(msr);
 	BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-	return (!test_bit(counter, &__get_cpu_var(perfctr_nmi_owner)));
+	return (!test_bit(counter, &perfctr_nmi_owner));
 }
 
 int reserve_perfctr_nmi(unsigned int msr)
@@ -145,7 +145,7 @@ int reserve_perfctr_nmi(unsigned int msr
 	counter = nmi_perfctr_msr_to_bit(msr);
 	BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-	if (!test_and_set_bit(counter, &__get_cpu_var(perfctr_nmi_owner)))
+	if (!test_and_set_bit(counter, &perfctr_nmi_owner))
 		return 1;
 	return 0;
 }
@@ -157,7 +157,7 @@ void release_perfctr_nmi(unsigned int ms
 	counter = nmi_perfctr_msr_to_bit(msr);
 	BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-	clear_bit(counter, &__get_cpu_var(perfctr_nmi_owner));
+	clear_bit(counter, &perfctr_nmi_owner);
 }
 
 int reserve_evntsel_nmi(unsigned int msr)
@@ -167,7 +167,7 @@ int reserve_evntsel_nmi(unsigned int msr
 	counter = nmi_evntsel_msr_to_bit(msr);
 	BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-	if (!test_and_set_bit(counter, &__get_cpu_var(evntsel_nmi_owner)[0]))
+	if (!test_and_set_bit(counter, &evntsel_nmi_owner[0]))
 		return 1;
 	return 0;
 }
@@ -179,7 +179,7 @@ void release_evntsel_nmi(unsigned int ms
 	counter = nmi_evntsel_msr_to_bit(msr);
 	BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-	clear_bit(counter, &__get_cpu_var(evntsel_nmi_owner)[0]);
+	clear_bit(counter, &evntsel_nmi_owner[0]);
 }
 
 static __cpuinit inline int nmi_known_cpu(void)
Index: linux/arch/x86_64/kernel/nmi.c
===================================================================
--- linux.orig/arch/x86_64/kernel/nmi.c
+++ linux/arch/x86_64/kernel/nmi.c
@@ -39,8 +39,8 @@ int panic_on_unrecovered_nmi;
  *   different subsystems this reservation system just tries to coordinate
  *   things a little
  */
-static DEFINE_PER_CPU(unsigned, perfctr_nmi_owner);
-static DEFINE_PER_CPU(unsigned, evntsel_nmi_owner[2]);
+static unsigned perfctr_nmi_owner;
+static unsigned evntsel_nmi_owner[2];
 
 static cpumask_t backtrace_mask = CPU_MASK_NONE;
 
@@ -110,7 +110,7 @@ int avail_to_resrv_perfctr_nmi_bit(unsig
 {
 	BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-	return (!test_bit(counter, &__get_cpu_var(perfctr_nmi_owner)));
+	return (!test_bit(counter, &perfctr_nmi_owner));
 }
 
 /* checks the an msr for availability */
@@ -121,7 +121,7 @@ int avail_to_resrv_perfctr_nmi(unsigned 
 	counter = nmi_perfctr_msr_to_bit(msr);
 	BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-	return (!test_bit(counter, &__get_cpu_var(perfctr_nmi_owner)));
+	return (!test_bit(counter, &perfctr_nmi_owner));
 }
 
 int reserve_perfctr_nmi(unsigned int msr)
@@ -131,7 +131,7 @@ int reserve_perfctr_nmi(unsigned int msr
 	counter = nmi_perfctr_msr_to_bit(msr);
 	BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-	if (!test_and_set_bit(counter, &__get_cpu_var(perfctr_nmi_owner)))
+	if (!test_and_set_bit(counter, &perfctr_nmi_owner))
 		return 1;
 	return 0;
 }
@@ -143,7 +143,7 @@ void release_perfctr_nmi(unsigned int ms
 	counter = nmi_perfctr_msr_to_bit(msr);
 	BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-	clear_bit(counter, &__get_cpu_var(perfctr_nmi_owner));
+	clear_bit(counter, &perfctr_nmi_owner);
 }
 
 int reserve_evntsel_nmi(unsigned int msr)
@@ -153,7 +153,7 @@ int reserve_evntsel_nmi(unsigned int msr
 	counter = nmi_evntsel_msr_to_bit(msr);
 	BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-	if (!test_and_set_bit(counter, &__get_cpu_var(evntsel_nmi_owner)))
+	if (!test_and_set_bit(counter, &evntsel_nmi_owner))
 		return 1;
 	return 0;
 }
@@ -165,7 +165,7 @@ void release_evntsel_nmi(unsigned int ms
 	counter = nmi_evntsel_msr_to_bit(msr);
 	BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-	clear_bit(counter, &__get_cpu_var(evntsel_nmi_owner));
+	clear_bit(counter, &evntsel_nmi_owner);
 }
 
 static __cpuinit inline int nmi_known_cpu(void)

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.21-rc5
  2007-03-28 14:30   ` Andi Kleen
@ 2007-03-28 14:56     ` Michal Piotrowski
  2007-03-28 16:12       ` Jiri Kosina
  2007-03-28 17:56     ` Linus Torvalds
  1 sibling, 1 reply; 128+ messages in thread
From: Michal Piotrowski @ 2007-03-28 14:56 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Michal Piotrowski, Linus Torvalds, Linux Kernel Mailing List,
	Andrew Morton

Andi Kleen napisał(a):
> On Tuesday 27 March 2007 20:53, Michal Piotrowski wrote:
>> Linus Torvalds napisał(a):
>>> There's various fixes here, ranging from some architecture updates (ia64, 
>>> ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.
>>>
>>> And random one-liners.
>>>
>> I found this in mm snapshot
>> http://www.ussg.iu.edu/hypermail/linux/kernel/0703.2/1367.html
>> it's in mainline too.
>>
>> Andi, any progress with this bug?
> 
> Can you test this patch please? 
> 

BUG: using smp_processor_id() in preemptible [00000001] code: mount/7245 
is fixed, thanks.


but I still get this

[  208.523901] =================================
[  208.529739] [ INFO: inconsistent lock state ]
[  208.534087] 2.6.21-rc5-g28defbea-dirty #131
[  208.538260] ---------------------------------
[  208.542611] inconsistent {hardirq-on-W} -> {in-hardirq-W} usage.
[  208.548600] swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
[  208.553553]  (oprofilefs_lock){+-..}, at: [<fdc85b6a>] nmi_cpu_setup+0x15/0x4f [oprofile]
[  208.561800] {hardirq-on-W} state was registered at:
[  208.566665]   [<c013dba4>] __lock_acquire+0x442/0xba1
[  208.571765]   [<c013e36b>] lock_acquire+0x68/0x82
[  208.576519]   [<c031bb37>] _spin_lock+0x35/0x42
[  208.581102]   [<fdc85343>] oprofilefs_ulong_from_user+0x4e/0x74 [oprofile]
[  208.588026]   [<fdc85393>] ulong_write_file+0x2a/0x38 [oprofile]
[  208.594084]   [<c0172693>] vfs_write+0xaf/0x138
[  208.598658]   [<c0172c5d>] sys_write+0x3d/0x61
[  208.603171]   [<c0104060>] syscall_call+0x7/0xb
[  208.607751]   [<ffffffff>] 0xffffffff
[  208.611478] irq event stamp: 575782
[  208.614960] hardirqs last  enabled at (575781): [<c0102ac2>] default_idle+0x3e/0x59
[  208.622645] hardirqs last disabled at (575782): [<c0104ae9>] call_function_interrupt+0x29/0x38
[  208.631281] softirqs last  enabled at (575768): [<c0126537>] __do_softirq+0xe4/0xea
[  208.638965] softirqs last disabled at (575759): [<c01069b5>] do_softirq+0x64/0xd1
[  208.646478]
[  208.646479] other info that might help us debug this:
[  208.653003] no locks held by swapper/0.
[  208.656832]
[  208.656833] stack backtrace:
[  208.661199]  [<c0105039>] show_trace_log_lvl+0x1a/0x2f
[  208.666350]  [<c0105720>] show_trace+0x12/0x14
[  208.670811]  [<c01057d2>] dump_stack+0x16/0x18
[  208.675272]  [<c013c57f>] print_usage_bug+0x140/0x14a
[  208.680336]  [<c013cd8a>] mark_lock+0xa1/0x40b
[  208.684796]  [<c013db15>] __lock_acquire+0x3b3/0xba1
[  208.689775]  [<c013e36b>] lock_acquire+0x68/0x82
[  208.694410]  [<c031bb37>] _spin_lock+0x35/0x42
[  208.698869]  [<fdc85b6a>] nmi_cpu_setup+0x15/0x4f [oprofile]
[  208.704540]  [<c0112a61>] smp_call_function_interrupt+0x3a/0x56
[  208.710470]  [<c0104af3>] call_function_interrupt+0x33/0x38
[  208.716053]  [<c01023b8>] cpu_idle+0xb6/0xeb
[  208.720342]  [<c0113bb0>] start_secondary+0x333/0x33b
[  208.725407]  [<00000000>] 0x0
[  208.728397]  =======================


Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.21-rc5
  2007-03-28 14:56     ` Michal Piotrowski
@ 2007-03-28 16:12       ` Jiri Kosina
  2007-03-28 16:51         ` Michal Piotrowski
  0 siblings, 1 reply; 128+ messages in thread
From: Jiri Kosina @ 2007-03-28 16:12 UTC (permalink / raw)
  To: Michal Piotrowski
  Cc: Andi Kleen, Linus Torvalds, Linux Kernel Mailing List,
	Andrew Morton, Philippe Elie

On Wed, 28 Mar 2007, Michal Piotrowski wrote:

> BUG: using smp_processor_id() in preemptible [00000001] code: mount/7245 
> is fixed, thanks.
> but I still get this
> [  208.523901] =================================
> [  208.529739] [ INFO: inconsistent lock state ]
> [  208.534087] 2.6.21-rc5-g28defbea-dirty #131
> [  208.538260] ---------------------------------
> [  208.542611] inconsistent {hardirq-on-W} -> {in-hardirq-W} usage.
> [  208.548600] swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes:

Perhaps something like the one below?


From: Jiri Kosina <jkosina@suse.cz>

oprofile: fix potential deadlock on oprofilefs_lock

nmi_cpu_setup() is called from hardirq context and acquires oprofilefs_lock.
alloc_event_buffer() and oprofilefs_ulong_from_user() acquire this lock
without disabling irqs, which could deadlock.

Signed-off-by: Jiri Kosina <jkosina@suse.cz>

 drivers/oprofile/event_buffer.c |    5 +++--
 drivers/oprofile/oprofilefs.c   |    5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/oprofile/event_buffer.c b/drivers/oprofile/event_buffer.c
index 00e937e..e7fbac5 100644
--- a/drivers/oprofile/event_buffer.c
+++ b/drivers/oprofile/event_buffer.c
@@ -70,11 +70,12 @@ void wake_up_buffer_waiter(void)
 int alloc_event_buffer(void)
 {
 	int err = -ENOMEM;
+	unsigned long flags;
 
-	spin_lock(&oprofilefs_lock);
+	spin_lock_irqsave(&oprofilefs_lock, flags);
 	buffer_size = fs_buffer_size;
 	buffer_watershed = fs_buffer_watershed;
-	spin_unlock(&oprofilefs_lock);
+	spin_unlock_irqrestore(&oprofilefs_lock, flags);
  
 	if (buffer_watershed >= buffer_size)
 		return -EINVAL;
diff --git a/drivers/oprofile/oprofilefs.c b/drivers/oprofile/oprofilefs.c
index 6e67b42..8543cb2 100644
--- a/drivers/oprofile/oprofilefs.c
+++ b/drivers/oprofile/oprofilefs.c
@@ -65,6 +65,7 @@ ssize_t oprofilefs_ulong_to_user(unsigned long val, char __user * buf, size_t co
 int oprofilefs_ulong_from_user(unsigned long * val, char const __user * buf, size_t count)
 {
 	char tmpbuf[TMPBUFSIZE];
+	unsigned long flags;
 
 	if (!count)
 		return 0;
@@ -77,9 +78,9 @@ int oprofilefs_ulong_from_user(unsigned long * val, char const __user * buf, siz
 	if (copy_from_user(tmpbuf, buf, count))
 		return -EFAULT;
 
-	spin_lock(&oprofilefs_lock);
+	spin_lock_irqsave(&oprofilefs_lock, flags);
 	*val = simple_strtoul(tmpbuf, NULL, 0);
-	spin_unlock(&oprofilefs_lock);
+	spin_unlock_irqrestore(&oprofilefs_lock, flags);
 	return 0;
 }


^ permalink raw reply related	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.21-rc5
  2007-03-28 16:12       ` Jiri Kosina
@ 2007-03-28 16:51         ` Michal Piotrowski
  0 siblings, 0 replies; 128+ messages in thread
From: Michal Piotrowski @ 2007-03-28 16:51 UTC (permalink / raw)
  To: Jiri Kosina
  Cc: Andi Kleen, Linus Torvalds, Linux Kernel Mailing List,
	Andrew Morton, Philippe Elie

On 28/03/07, Jiri Kosina <jikos@jikos.cz> wrote:
> On Wed, 28 Mar 2007, Michal Piotrowski wrote:
>
> > BUG: using smp_processor_id() in preemptible [00000001] code: mount/7245
> > is fixed, thanks.
> > but I still get this
> > [  208.523901] =================================
> > [  208.529739] [ INFO: inconsistent lock state ]
> > [  208.534087] 2.6.21-rc5-g28defbea-dirty #131
> > [  208.538260] ---------------------------------
> > [  208.542611] inconsistent {hardirq-on-W} -> {in-hardirq-W} usage.
> > [  208.548600] swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
>
> Perhaps something like the one below?
>

Problem seems to be fixed. Thanks!

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.21-rc5
  2007-03-28 14:30   ` Andi Kleen
  2007-03-28 14:56     ` Michal Piotrowski
@ 2007-03-28 17:56     ` Linus Torvalds
  1 sibling, 0 replies; 128+ messages in thread
From: Linus Torvalds @ 2007-03-28 17:56 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Michal Piotrowski, Linux Kernel Mailing List, Andrew Morton, Jiri Kosina



On Wed, 28 Mar 2007, Andi Kleen wrote:
> 
> Can you test this patch please? 

This patch is totally broken.

> i386/x86-64: Convert nmi reservation to be global
> 
> It doesn't make much sense to have this per CPU, because all
> the services using NMIs run on all CPUs. So make it global.

NO!

If you do this, then you must make all *callers* be global too. But they 
aren't. Right now all callers do per-CPU setup!

See for example enable_lapic_nmi_watchdog():

	on_each_cpu(setup_apic_nmi_watchdog, NULL, 0, 1);

where "setup_apic_nmi_watchdog()" will call "setup_k7_watchdog()", which 
in turn will do a per-CPU reservation of the perfctl for the watchdog.

So I agree in that it probably doesn't make sense to have NMI/perfctl 
reservation per-CPU, but you can't just change the reservation and ignore 
all the *users* of that reservation that assumed that it was per-CPU.

Is that code insane? Probably. But it probably also works. After your 
patch, one CPU will be able to reserve the NMI/perfctl thing (fine so far) 
but then all the other CPU's that try to do it will fail.

			Linus

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [1/5] 2.6.21-rc5: known regressions
  2007-03-27  1:59 ` [1/5] 2.6.21-rc5: known regressions Adrian Bunk
@ 2007-03-28 18:54   ` Kok, Auke
  2007-03-28 19:23     ` Ingo Molnar
  2007-03-30 18:04     ` Adrian Bunk
  2007-03-30 12:04   ` [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions" Ingo Molnar
  1 sibling, 2 replies; 128+ messages in thread
From: Kok, Auke @ 2007-03-28 18:54 UTC (permalink / raw)
  To: Adrian Bunk, Ingo Molnar
  Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
	Jesse Brandeburg, e1000-devel, jgarzik, netdev

Adrian Bunk wrote:
> Subject    : e1000 resume weirdness
> References : http://lkml.org/lkml/2007/3/26/91
> Submitter  : Ingo Molnar <mingo@elte.hu>
> Handled-By : Jesse Brandeburg <jesse.brandeburg@gmail.com>
>              Auke Kok <auke-jan.h.kok@intel.com>
> Status     : problem is being debugged

The issue comes from a corner case and the underlying problem is that e1000 
isn't stopping tx properly. We have a fix for this pending in our tree that I'll 
push upstream for 2.6.22 to Jeff, but I don't think this should be a blocker and 
it's probably is not a regression at all, the gap has always been present.

on a side note, this is probably fixed easily by turning the adapters 
detect_tx_hung flag off in e1000_down, so if someone spots this reoccurring 
somewhat regularly, please contact me so we can debug it. I myself have a system 
suspend/resuming in circles for an hour now with traffic flying across without a 
single hit on it....

Adrian, you probably want to drop this issue from your list.

Cheers,


Auke

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [1/5] 2.6.21-rc5: known regressions
  2007-03-28 18:54   ` Kok, Auke
@ 2007-03-28 19:23     ` Ingo Molnar
  2007-03-30 18:04     ` Adrian Bunk
  1 sibling, 0 replies; 128+ messages in thread
From: Ingo Molnar @ 2007-03-28 19:23 UTC (permalink / raw)
  To: Kok, Auke
  Cc: Adrian Bunk, Linus Torvalds, Andrew Morton,
	Linux Kernel Mailing List, Jesse Brandeburg, e1000-devel,
	jgarzik, netdev


* Kok, Auke <auke-jan.h.kok@intel.com> wrote:

> Adrian Bunk wrote:
> >Subject    : e1000 resume weirdness
> >References : http://lkml.org/lkml/2007/3/26/91
> >Submitter  : Ingo Molnar <mingo@elte.hu>
> >Handled-By : Jesse Brandeburg <jesse.brandeburg@gmail.com>
> >             Auke Kok <auke-jan.h.kok@intel.com>
> >Status     : problem is being debugged

> Adrian, you probably want to drop this issue from your list.

agreed - i have done many suspend/resumes meanwhile, and this condition 
has not reoccured since then. (and even when it occured, it was 
transitionary)

	Ingo

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [2/5] 2.6.21-rc5: known regressions
  2007-03-27  1:59   ` Adrian Bunk
  (?)
  (?)
@ 2007-03-28 19:46   ` Laurent Riffard
  2007-03-29 19:02     ` Fabio Comolli
  -1 siblings, 1 reply; 128+ messages in thread
From: Laurent Riffard @ 2007-03-28 19:46 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Linux Kernel Mailing List, linux-ide, Tejun Heo, Fabio Comolli,
	Plamen Petrov, Lukas Hejtmanek

Le 27.03.2007 03:59, Adrian Bunk a écrit :
> This email lists some known regressions in Linus' tree compared to 2.6.20.
... 
> Subject    : libata: PATA UDMA/100 configured as UDMA/33
> References : http://lkml.org/lkml/2007/2/20/294
>              http://www.mail-archive.com/linux-ide@vger.kernel.org/msg04115.html
>              http://bugzilla.kernel.org/show_bug.cgi?id=8133
>              http://bugzilla.kernel.org/show_bug.cgi?id=8164
>              http://lkml.org/lkml/2007/3/21/330
> Submitter  : Fabio Comolli <fabio.comolli@gmail.com>
>              Plamen Petrov <plamen.petrov@tk.ru.acad.bg>
>              Laurent Riffard <laurent.riffard@free.fr>
>              Lukas Hejtmanek <xhejtman@mail.muni.cz>
> Handled-By : Tejun Heo <htejun@gmail.com>
> Patch      : http://thread.gmane.org/gmane.linux.ide/17444
> Status     : patch available

pata-via case is fixed for me in 2.6.21-rc5-mm2 (was already fixed in 2.6.21-rc4-mm1).

thanks
~~
laurent


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: Linux 2.6.21-rc5
  2007-03-27  6:17 ` Linux 2.6.21-rc5 Andrew Morton
                     ` (3 preceding siblings ...)
  2007-03-27 12:43   ` Dmitry Torokhov
@ 2007-03-28 22:32   ` Tilman Schmidt
  4 siblings, 0 replies; 128+ messages in thread
From: Tilman Schmidt @ 2007-03-28 22:32 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Linux Kernel Mailing List

Am 27.03.2007 08:17 schrieb Andrew Morton:
> I have a few fixes here which belong to subsystem trees, which were missed
> by the maintainers and which we probably want to get into 2.6.21.
[...]
> Maintainers are cc'ed.  Please promptly ack, nack or otherwise quack, else
> I'll be making my own decisions ;)

[CC list trimmed]

It's not on that list, but would you mind slipping
drivers-isdn-gigaset-mark-some-static-data-as-const-v2.patch
into 2.6.21 too? It's largely trivial but I'd like to get it
out of the door.

Thanks,
Tilman

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeoeffnet mindestens haltbar bis: (siehe Rueckseite)

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [patch] MSI-X: fix resume crash
  2007-03-28 13:06         ` [patch] MSI-X: fix resume crash Ingo Molnar
  2007-03-28 13:31           ` Eric W. Biederman
@ 2007-03-29  4:30           ` Len Brown
  2007-03-29  4:57             ` Eric W. Biederman
  1 sibling, 1 reply; 128+ messages in thread
From: Len Brown @ 2007-03-29  4:30 UTC (permalink / raw)
  To: Ingo Molnar, luming.yu
  Cc: Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel,
	Eric W. Biederman, Thomas Meyer, Frederic Riss, Marcus Better

> Tony, Len the way pci_disable_device is being used in a suspend/resume 
> path by a few drivers is completely incompatible with the way irqs are 
> allocated on ia64.  In particular people the following sequence occurs 
> in several drivers.
> 
> probe:
>   pci_enable_device(pdev);
>   request_irq(pdev->irq);
> suspend:
>   pci_disable_device(pdev);
> resume:
>   pci_enable_device(pdev);
> remove:
>   free_irq(pdev->irq);
>   pci_disable_device(pdev);

There are no IA64 machines that support system suspend/resume today --
so you have 0 chance of breaking the IA64 suspend/resume installed base.

My understanding is that Luming Yu has cobbled IA64 S4 support
together for a future release though.

> What I'm proposing we do is move the irq allocation code out of 
> pci_enable_device and the irq freeing code out of pci_disable_device in 
> the future.  If we move ia64 to a model where the irq number equal the 
> gsi like we have for x86_64 and are in the middle of for i386 that 
> should be pretty straight forward. It would even be relatively simple  
> to delay vector allocation in that context until request_irq, if we 
> needed the delayed allocation benefit.  Do you two have any problems 
> with moving in that direction?

I think consistency here would be _wonderful_.
Of course the beauty of having identity GSI=IRQ and a /proc/interrupts
that tells you what IOAPIC pin you are using become moot with MSI --
but hey, showing the IRQ number rather than the vector number
is consistent and makes sense.

> If fixing the arch code is unacceptable for some reason I'm not aware of 
> we need to audit the 10-20 drivers that call pci_disable_device in their 
> suspend/resume processing and ensure that they have freed all of the 
> irqs before that point.  Given that I have bug reports on the msi path I 
> know that isn't true.

I think the suspend/resume interrupt logic needs some serious attention.
We've had several schemes for suspend/resume of interrupts, several
changes in strategy, and right now I think we are inconsistent,
and frankly, I'm amazed it works at all.

-Len


> From: Eric W. Biederman <ebiederm@xmission.com>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
>  arch/cris/arch-v32/drivers/pci/bios.c |    4 +++-
>  arch/frv/mb93090-mb00/pci-vdk.c       |    3 ++-
>  arch/i386/pci/common.c                |    6 ++++--
>  arch/ia64/pci/pci.c                   |    8 ++++++--
>  4 files changed, 15 insertions(+), 6 deletions(-)
> 
> Index: linux/arch/cris/arch-v32/drivers/pci/bios.c
> ===================================================================
> --- linux.orig/arch/cris/arch-v32/drivers/pci/bios.c
> +++ linux/arch/cris/arch-v32/drivers/pci/bios.c
> @@ -100,7 +100,9 @@ int pcibios_enable_device(struct pci_dev
>  	if ((err = pcibios_enable_resources(dev, mask)) < 0)
>  		return err;
>  
> -	return pcibios_enable_irq(dev);
> +	if (!dev->msi_enabled)
> +		pcibios_enable_irq(dev);
> +	return 0;
>  }
>  
>  int pcibios_assign_resources(void)
> Index: linux/arch/frv/mb93090-mb00/pci-vdk.c
> ===================================================================
> --- linux.orig/arch/frv/mb93090-mb00/pci-vdk.c
> +++ linux/arch/frv/mb93090-mb00/pci-vdk.c
> @@ -466,6 +466,7 @@ int pcibios_enable_device(struct pci_dev
>  
>  	if ((err = pcibios_enable_resources(dev, mask)) < 0)
>  		return err;
> -	pcibios_enable_irq(dev);
> +	if (!dev->msi_enabled)
> +		pcibios_enable_irq(dev);
>  	return 0;
>  }
> Index: linux/arch/i386/pci/common.c
> ===================================================================
> --- linux.orig/arch/i386/pci/common.c
> +++ linux/arch/i386/pci/common.c
> @@ -434,11 +434,13 @@ int pcibios_enable_device(struct pci_dev
>  	if ((err = pcibios_enable_resources(dev, mask)) < 0)
>  		return err;
>  
> -	return pcibios_enable_irq(dev);
> +	if (!dev->msi_enabled)
> +		return pcibios_enable_irq(dev);
> +	return 0;
>  }
>  
>  void pcibios_disable_device (struct pci_dev *dev)
>  {
> -	if (pcibios_disable_irq)
> +	if (!dev->msi_enabled && pcibios_disable_irq)
>  		pcibios_disable_irq(dev);
>  }
> Index: linux/arch/ia64/pci/pci.c
> ===================================================================
> --- linux.orig/arch/ia64/pci/pci.c
> +++ linux/arch/ia64/pci/pci.c
> @@ -557,14 +557,18 @@ pcibios_enable_device (struct pci_dev *d
>  	if (ret < 0)
>  		return ret;
>  
> -	return acpi_pci_irq_enable(dev);
> +	if (!dev->msi_enabled)
> +		return acpi_pci_irq_enable(dev);
> +	return 0;
>  }
>  
>  void
>  pcibios_disable_device (struct pci_dev *dev)
>  {
>  	BUG_ON(atomic_read(&dev->enable_cnt));
> -	acpi_pci_irq_disable(dev);
> +	if (!dev->msi_enabled)
> +		acpi_pci_irq_disable(dev);
> +	return 0;
>  }
>  
>  void
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [patch] MSI-X: fix resume crash
  2007-03-29  4:30           ` Len Brown
@ 2007-03-29  4:57             ` Eric W. Biederman
  0 siblings, 0 replies; 128+ messages in thread
From: Eric W. Biederman @ 2007-03-29  4:57 UTC (permalink / raw)
  To: Len Brown
  Cc: Ingo Molnar, luming.yu, Adrian Bunk, Linus Torvalds,
	Andrew Morton, linux-kernel, Thomas Meyer, Frederic Riss,
	Marcus Better

Len Brown <lenb@kernel.org> writes:

>> Tony, Len the way pci_disable_device is being used in a suspend/resume 
>> path by a few drivers is completely incompatible with the way irqs are 
>> allocated on ia64.  In particular people the following sequence occurs 
>> in several drivers.
>> 
>> probe:
>>   pci_enable_device(pdev);
>>   request_irq(pdev->irq);
>> suspend:
>>   pci_disable_device(pdev);
>> resume:
>>   pci_enable_device(pdev);
>> remove:
>>   free_irq(pdev->irq);
>>   pci_disable_device(pdev);
>
> There are no IA64 machines that support system suspend/resume today --
> so you have 0 chance of breaking the IA64 suspend/resume installed base.

Ok.  So that is why the inconsistency persists...

> My understanding is that Luming Yu has cobbled IA64 S4 support
> together for a future release though.
>
>> What I'm proposing we do is move the irq allocation code out of 
>> pci_enable_device and the irq freeing code out of pci_disable_device in 
>> the future.  If we move ia64 to a model where the irq number equal the 
>> gsi like we have for x86_64 and are in the middle of for i386 that 
>> should be pretty straight forward. It would even be relatively simple  
>> to delay vector allocation in that context until request_irq, if we 
>> needed the delayed allocation benefit.  Do you two have any problems 
>> with moving in that direction?
>
> I think consistency here would be _wonderful_.
> Of course the beauty of having identity GSI=IRQ and a /proc/interrupts
> that tells you what IOAPIC pin you are using become moot with MSI --
> but hey, showing the IRQ number rather than the vector number
> is consistent and makes sense.

Yes.  It also allows for bigger machines.  And I can get a consistent
number out of MSI if we allocate irq numbers in a sufficiently non-sparse
way.  Something like bus|device|func|irq which is 8+5+3+12 or 28 bits...
I'll never get there though if i keep unearthing this long standing bugs.

>> If fixing the arch code is unacceptable for some reason I'm not aware of 
>> we need to audit the 10-20 drivers that call pci_disable_device in their 
>> suspend/resume processing and ensure that they have freed all of the 
>> irqs before that point.  Given that I have bug reports on the msi path I 
>> know that isn't true.
>
> I think the suspend/resume interrupt logic needs some serious attention.
> We've had several schemes for suspend/resume of interrupts, several
> changes in strategy, and right now I think we are inconsistent,
> and frankly, I'm amazed it works at all.

What I have been doing lately is to aim at consistency in how a function
is called (and thus how it is expected to be used) and how it is actually
implemented.  When I have a choice I try to pick a forgiving implementation
so that driver writers don't have to follow a magic correct path for
things to work correctly.  

Removing the irq assignment from pci_enable_device is something that
matches implementation with use.

As for the rest it seems reasonable to me to allow an irq to be held
requested over suspend/resume and to save and restore apic and msi
capability state.  Especially since irq numbers are a kernel
abstraction we should be able to do with them what we need to.

Honestly the whole suspend/resume thing is beyond me at this point I'm
laptop free...  But I do know how to make code consistent with itself.

Eric

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [2/5] 2.6.21-rc5: known regressions
  2007-03-28 19:46   ` Laurent Riffard
@ 2007-03-29 19:02     ` Fabio Comolli
  0 siblings, 0 replies; 128+ messages in thread
From: Fabio Comolli @ 2007-03-29 19:02 UTC (permalink / raw)
  To: Adrian Bunk, Linux Kernel Mailing List; +Cc: linux-ide, Tejun Heo

Hi.

> > This email lists some known regressions in Linus' tree compared to 2.6.20.
> ...
> > Subject    : libata: PATA UDMA/100 configured as UDMA/33
> > References : http://lkml.org/lkml/2007/2/20/294
> >              http://www.mail-archive.com/linux-ide@vger.kernel.org/msg04115.html
> >              http://bugzilla.kernel.org/show_bug.cgi?id=8133
> >              http://bugzilla.kernel.org/show_bug.cgi?id=8164
> >              http://lkml.org/lkml/2007/3/21/330
> > Submitter  : Fabio Comolli <fabio.comolli@gmail.com>
> >              Plamen Petrov <plamen.petrov@tk.ru.acad.bg>
> >              Laurent Riffard <laurent.riffard@free.fr>
> >              Lukas Hejtmanek <xhejtman@mail.muni.cz>
> > Handled-By : Tejun Heo <htejun@gmail.com>
> > Patch      : http://thread.gmane.org/gmane.linux.ide/17444
> > Status     : patch available
>

Fixed for me (ata_piix) with today's GIT (Tejun's patch got applied).
Regards,
Fabio

^ permalink raw reply	[flat|nested] 128+ messages in thread

* [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"
  2007-03-27  1:59 ` [1/5] 2.6.21-rc5: known regressions Adrian Bunk
  2007-03-28 18:54   ` Kok, Auke
@ 2007-03-30 12:04   ` Ingo Molnar
  2007-03-30 12:06     ` [bug] fixed_init(): BUG: at drivers/base/core.c:120 device_release(), " Ingo Molnar
                       ` (2 more replies)
  1 sibling, 3 replies; 128+ messages in thread
From: Ingo Molnar @ 2007-03-30 12:04 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Linus Torvalds, Andrew Morton, linux-kernel, Greg Kroah-Hartman


i just found a new category of driver regressions in 2.6.21, doing 
allyesconfig bzImage bootup tests: the init methods of various drivers 
hangs in driver_unregister().

It is caused by this problem: the semantics of driver_unregister() [also 
implicitly called in pci_driver_unregister()] has apparently changed 
recently. If a driver does:

	pci_register_driver(&my_driver);
	...
	if (some_failure) {
		pci_unregister_driver(&my_driver);
		...
	}

it will hang the bootup in the following piece of code:

 drivers/base/driver.c:

  void driver_unregister(struct device_driver * drv)
  {
         bus_remove_driver(drv);
         wait_for_completion(&drv->unloaded);

the completion is never done - because nobody removes the bus while the 
init is still happening, obviously. (and bootup is serialized anyway)

now, the majority of drivers does the driver unregistry from its 
module-cleanup function, so it's not affected by this problem. But if 
you apply the debug patch attached further below, and do an allyesconfig 
bzImage bootup, there's 3 hits already:

 BUG: at drivers/base/driver.c:187 driver_unregister()
  [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
  [<c01063e2>] show_trace+0x12/0x14
  [<c01063f8>] dump_stack+0x14/0x16
  [<c063f7e6>] driver_unregister+0x3d/0x43
  [<c0488048>] pci_unregister_driver+0x10/0x5f
  [<c1b5f7c7>] slgt_init+0x9b/0x1ca
  [<c1b31a2d>] init+0x15d/0x2bd
  [<c0105bc3>] kernel_thread_helper+0x7/0x10

 BUG: at drivers/base/driver.c:187 driver_unregister()
  [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
  [<c01063e2>] show_trace+0x12/0x14
  [<c01063f8>] dump_stack+0x14/0x16
  [<c063f7e6>] driver_unregister+0x3d/0x43
  [<c0488048>] pci_unregister_driver+0x10/0x5f
  [<c0619505>] init_ipmi_si+0x70a/0x738
  [<c1b31a2d>] init+0x15d/0x2bd
  [<c0105bc3>] kernel_thread_helper+0x7/0x10

 BUG: at drivers/base/driver.c:187 driver_unregister()
  [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
  [<c01063e2>] show_trace+0x12/0x14
  [<c01063f8>] dump_stack+0x14/0x16
  [<c063f7e6>] driver_unregister+0x3d/0x43
  [<c0488048>] pci_unregister_driver+0x10/0x5f
  [<c1b6d2d8>] tlan_probe+0x2dd/0x30e
  [<c1b31a2d>] init+0x15d/0x2bd
  [<c0105bc3>] kernel_thread_helper+0x7/0x10

possibly more could trigger. Each of these 3 places caused an actual 
bootup hang on my testbox, so these are real regressions and need to be 
fixed.

because there are a good number of drivers that do 
pci_unregister_device() from their init function, and because i cannot 
see anything obviously wrong in doing an unregister call after a 
failure, i think it's driver_unregister() that needs to be fixed. Greg, 
what do you think?

	Ingo

Index: linux/drivers/base/driver.c
===================================================================
--- linux.orig/drivers/base/driver.c
+++ linux/drivers/base/driver.c
@@ -183,7 +183,8 @@ int driver_register(struct device_driver
 void driver_unregister(struct device_driver * drv)
 {
 	bus_remove_driver(drv);
-	wait_for_completion(&drv->unloaded);
+	if (!drv->unloaded.done)
+		WARN_ON(1);
 }
 
 /**

^ permalink raw reply	[flat|nested] 128+ messages in thread

* [bug] fixed_init(): BUG: at drivers/base/core.c:120 device_release(), was: "2.6.21-rc5: known regressions"
  2007-03-30 12:04   ` [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions" Ingo Molnar
@ 2007-03-30 12:06     ` Ingo Molnar
  2007-03-30 14:18       ` Greg KH
  2007-03-30 14:16     ` [bug] hung bootup in various drivers, " Greg KH
  2007-04-01  7:49     ` Pavel Machek
  2 siblings, 1 reply; 128+ messages in thread
From: Ingo Molnar @ 2007-03-30 12:06 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Linus Torvalds, Andrew Morton, linux-kernel, Greg Kroah-Hartman


there's a new type of message in allyesconfig-bzImage bootup test:

Calling initcall 0xc1b6d692: fixed_init+0x0/0x33()
Fixed PHY: Registered new driver
Device 'fixed@100:1' does not have a release() function, it is broken and must be fixed.
BUG: at drivers/base/core.c:120 device_release()
 [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
 [<c01063e2>] show_trace+0x12/0x14
 [<c01063f8>] dump_stack+0x14/0x16
 [<c063cddf>] device_release+0x7c/0x7e
 [<c0476c32>] kobject_cleanup+0x44/0x5e
 [<c0476c57>] kobject_release+0xb/0xd
 [<c04773ef>] kref_put+0x63/0x71
 [<c0476757>] kobject_put+0x14/0x16
 [<c063ceef>] put_device+0x11/0x13
 [<c063d943>] device_unregister+0x12/0x15
 [<c07337d1>] fixed_mdio_register_device+0x210/0x23b
 [<c1b6d6b0>] fixed_init+0x1e/0x33
 [<c1b31a2d>] init+0x15d/0x2bd
 [<c0105bc3>] kernel_thread_helper+0x7/0x10
 =======================
Device 'fixed@10:1' does not have a release() function, it is broken and must be fixed.
BUG: at drivers/base/core.c:120 device_release()
 [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
 [<c01063e2>] show_trace+0x12/0x14
 [<c01063f8>] dump_stack+0x14/0x16
 [<c063cddf>] device_release+0x7c/0x7e
 [<c0476c32>] kobject_cleanup+0x44/0x5e
 [<c0476c57>] kobject_release+0xb/0xd
 [<c04773ef>] kref_put+0x63/0x71
 [<c0476757>] kobject_put+0x14/0x16
 [<c063ceef>] put_device+0x11/0x13
 [<c063d943>] device_unregister+0x12/0x15
 [<c07337d1>] fixed_mdio_register_device+0x210/0x23b
 [<c1b6d6c1>] fixed_init+0x2f/0x33
 [<c1b31a2d>] init+0x15d/0x2bd
 [<c0105bc3>] kernel_thread_helper+0x7/0x10
 =======================
Calling initcall 0xc1b6d6c5: sundance_init+0x0/0x16()
Calling initcall 0xc1b6d6db: hamachi_init+0x0/0x16()

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"
  2007-03-30 12:04   ` [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions" Ingo Molnar
  2007-03-30 12:06     ` [bug] fixed_init(): BUG: at drivers/base/core.c:120 device_release(), " Ingo Molnar
@ 2007-03-30 14:16     ` Greg KH
  2007-03-30 17:46       ` Ingo Molnar
  2007-04-01  7:49     ` Pavel Machek
  2 siblings, 1 reply; 128+ messages in thread
From: Greg KH @ 2007-03-30 14:16 UTC (permalink / raw)
  To: Ingo Molnar, Kay Sievers
  Cc: Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel

On Fri, Mar 30, 2007 at 02:04:16PM +0200, Ingo Molnar wrote:
> 
> i just found a new category of driver regressions in 2.6.21, doing 
> allyesconfig bzImage bootup tests: the init methods of various drivers 
> hangs in driver_unregister().
> 
> It is caused by this problem: the semantics of driver_unregister() [also 
> implicitly called in pci_driver_unregister()] has apparently changed 
> recently. If a driver does:
> 
> 	pci_register_driver(&my_driver);
> 	...
> 	if (some_failure) {
> 		pci_unregister_driver(&my_driver);
> 		...
> 	}
> 
> it will hang the bootup in the following piece of code:
> 
>  drivers/base/driver.c:
> 
>   void driver_unregister(struct device_driver * drv)
>   {
>          bus_remove_driver(drv);
>          wait_for_completion(&drv->unloaded);
> 
> the completion is never done - because nobody removes the bus while the 
> init is still happening, obviously. (and bootup is serialized anyway)
> 
> now, the majority of drivers does the driver unregistry from its 
> module-cleanup function, so it's not affected by this problem. But if 
> you apply the debug patch attached further below, and do an allyesconfig 
> bzImage bootup, there's 3 hits already:
> 
>  BUG: at drivers/base/driver.c:187 driver_unregister()
>   [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
>   [<c01063e2>] show_trace+0x12/0x14
>   [<c01063f8>] dump_stack+0x14/0x16
>   [<c063f7e6>] driver_unregister+0x3d/0x43
>   [<c0488048>] pci_unregister_driver+0x10/0x5f
>   [<c1b5f7c7>] slgt_init+0x9b/0x1ca
>   [<c1b31a2d>] init+0x15d/0x2bd
>   [<c0105bc3>] kernel_thread_helper+0x7/0x10
> 
>  BUG: at drivers/base/driver.c:187 driver_unregister()
>   [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
>   [<c01063e2>] show_trace+0x12/0x14
>   [<c01063f8>] dump_stack+0x14/0x16
>   [<c063f7e6>] driver_unregister+0x3d/0x43
>   [<c0488048>] pci_unregister_driver+0x10/0x5f
>   [<c0619505>] init_ipmi_si+0x70a/0x738
>   [<c1b31a2d>] init+0x15d/0x2bd
>   [<c0105bc3>] kernel_thread_helper+0x7/0x10
> 
>  BUG: at drivers/base/driver.c:187 driver_unregister()
>   [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
>   [<c01063e2>] show_trace+0x12/0x14
>   [<c01063f8>] dump_stack+0x14/0x16
>   [<c063f7e6>] driver_unregister+0x3d/0x43
>   [<c0488048>] pci_unregister_driver+0x10/0x5f
>   [<c1b6d2d8>] tlan_probe+0x2dd/0x30e
>   [<c1b31a2d>] init+0x15d/0x2bd
>   [<c0105bc3>] kernel_thread_helper+0x7/0x10
> 
> possibly more could trigger. Each of these 3 places caused an actual 
> bootup hang on my testbox, so these are real regressions and need to be 
> fixed.
> 
> because there are a good number of drivers that do 
> pci_unregister_device() from their init function, and because i cannot 
> see anything obviously wrong in doing an unregister call after a 
> failure, i think it's driver_unregister() that needs to be fixed. Greg, 
> what do you think?

Yes, we should allow the ability to call unregister_driver from within
the module_init function.

But I don't understand what is causing you to see this problem.  Who is
holding the reference on the struct device at this point in time?  Is it
the fact that userspace has some files open and it hasn't released them
yet?

I don't see anything implicit in the driver_unregister() path that
should not work from within the module_init() path.  Kay, am I missing
anything here?

(patch left below for Kay's benefit)

thanks,

greg k-h

> Index: linux/drivers/base/driver.c
> ===================================================================
> --- linux.orig/drivers/base/driver.c
> +++ linux/drivers/base/driver.c
> @@ -183,7 +183,8 @@ int driver_register(struct device_driver
>  void driver_unregister(struct device_driver * drv)
>  {
>  	bus_remove_driver(drv);
> -	wait_for_completion(&drv->unloaded);
> +	if (!drv->unloaded.done)
> +		WARN_ON(1);
>  }
>  
>  /**

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [bug] fixed_init(): BUG: at drivers/base/core.c:120 device_release(), was: "2.6.21-rc5: known regressions"
  2007-03-30 12:06     ` [bug] fixed_init(): BUG: at drivers/base/core.c:120 device_release(), " Ingo Molnar
@ 2007-03-30 14:18       ` Greg KH
  2007-03-30 14:25         ` Ingo Molnar
  0 siblings, 1 reply; 128+ messages in thread
From: Greg KH @ 2007-03-30 14:18 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel

On Fri, Mar 30, 2007 at 02:06:57PM +0200, Ingo Molnar wrote:
> 
> there's a new type of message in allyesconfig-bzImage bootup test:
> 
> Calling initcall 0xc1b6d692: fixed_init+0x0/0x33()
> Fixed PHY: Registered new driver
> Device 'fixed@100:1' does not have a release() function, it is broken and must be fixed.
> BUG: at drivers/base/core.c:120 device_release()
>  [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
>  [<c01063e2>] show_trace+0x12/0x14
>  [<c01063f8>] dump_stack+0x14/0x16
>  [<c063cddf>] device_release+0x7c/0x7e
>  [<c0476c32>] kobject_cleanup+0x44/0x5e
>  [<c0476c57>] kobject_release+0xb/0xd
>  [<c04773ef>] kref_put+0x63/0x71
>  [<c0476757>] kobject_put+0x14/0x16
>  [<c063ceef>] put_device+0x11/0x13
>  [<c063d943>] device_unregister+0x12/0x15
>  [<c07337d1>] fixed_mdio_register_device+0x210/0x23b
>  [<c1b6d6b0>] fixed_init+0x1e/0x33
>  [<c1b31a2d>] init+0x15d/0x2bd
>  [<c0105bc3>] kernel_thread_helper+0x7/0x10
>  =======================
> Device 'fixed@10:1' does not have a release() function, it is broken and must be fixed.
> BUG: at drivers/base/core.c:120 device_release()
>  [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
>  [<c01063e2>] show_trace+0x12/0x14
>  [<c01063f8>] dump_stack+0x14/0x16
>  [<c063cddf>] device_release+0x7c/0x7e
>  [<c0476c32>] kobject_cleanup+0x44/0x5e
>  [<c0476c57>] kobject_release+0xb/0xd
>  [<c04773ef>] kref_put+0x63/0x71
>  [<c0476757>] kobject_put+0x14/0x16
>  [<c063ceef>] put_device+0x11/0x13
>  [<c063d943>] device_unregister+0x12/0x15
>  [<c07337d1>] fixed_mdio_register_device+0x210/0x23b
>  [<c1b6d6c1>] fixed_init+0x2f/0x33
>  [<c1b31a2d>] init+0x15d/0x2bd
>  [<c0105bc3>] kernel_thread_helper+0x7/0x10

That means that whatever driver has fixed_mdio_register_device() in it
is broken and needs to be fixed.

It is independant from your previous question about unregistering the
device from within module_init().

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [bug] fixed_init(): BUG: at drivers/base/core.c:120 device_release(), was: "2.6.21-rc5: known regressions"
  2007-03-30 14:18       ` Greg KH
@ 2007-03-30 14:25         ` Ingo Molnar
  2007-03-30 16:31           ` Vitaly Bordug
  0 siblings, 1 reply; 128+ messages in thread
From: Ingo Molnar @ 2007-03-30 14:25 UTC (permalink / raw)
  To: Greg KH
  Cc: Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel, Vitaly Bordug


* Greg KH <gregkh@suse.de> wrote:

> > Device 'fixed@10:1' does not have a release() function, it is broken and must be fixed.
> > BUG: at drivers/base/core.c:120 device_release()
> >  [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
> >  [<c01063e2>] show_trace+0x12/0x14
> >  [<c01063f8>] dump_stack+0x14/0x16
> >  [<c063cddf>] device_release+0x7c/0x7e
> >  [<c0476c32>] kobject_cleanup+0x44/0x5e
> >  [<c0476c57>] kobject_release+0xb/0xd
> >  [<c04773ef>] kref_put+0x63/0x71
> >  [<c0476757>] kobject_put+0x14/0x16
> >  [<c063ceef>] put_device+0x11/0x13
> >  [<c063d943>] device_unregister+0x12/0x15
> >  [<c07337d1>] fixed_mdio_register_device+0x210/0x23b
> >  [<c1b6d6c1>] fixed_init+0x2f/0x33
> >  [<c1b31a2d>] init+0x15d/0x2bd
> >  [<c0105bc3>] kernel_thread_helper+0x7/0x10
> 
> That means that whatever driver has fixed_mdio_register_device() in it 
> is broken and needs to be fixed.

that would be drivers/net/phy/fixed.c.

> It is independant from your previous question about unregistering the 
> device from within module_init().

(yes - hence the different subject line, etc.)

	Ingo

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [bug] fixed_init(): BUG: at drivers/base/core.c:120 device_release(), was: "2.6.21-rc5: known regressions"
  2007-03-30 14:25         ` Ingo Molnar
@ 2007-03-30 16:31           ` Vitaly Bordug
  0 siblings, 0 replies; 128+ messages in thread
From: Vitaly Bordug @ 2007-03-30 16:31 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Greg KH, Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel

On Fri, 30 Mar 2007 16:25:14 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Greg KH <gregkh@suse.de> wrote:
> 
> > > Device 'fixed@10:1' does not have a release() function, it is broken and must be fixed.
> > > BUG: at drivers/base/core.c:120 device_release()
> > >  [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
> > >  [<c01063e2>] show_trace+0x12/0x14
> > >  [<c01063f8>] dump_stack+0x14/0x16
> > >  [<c063cddf>] device_release+0x7c/0x7e
> > >  [<c0476c32>] kobject_cleanup+0x44/0x5e
> > >  [<c0476c57>] kobject_release+0xb/0xd
> > >  [<c04773ef>] kref_put+0x63/0x71
> > >  [<c0476757>] kobject_put+0x14/0x16
> > >  [<c063ceef>] put_device+0x11/0x13
> > >  [<c063d943>] device_unregister+0x12/0x15
> > >  [<c07337d1>] fixed_mdio_register_device+0x210/0x23b
> > >  [<c1b6d6c1>] fixed_init+0x2f/0x33
> > >  [<c1b31a2d>] init+0x15d/0x2bd
> > >  [<c0105bc3>] kernel_thread_helper+0x7/0x10
> > 
> > That means that whatever driver has fixed_mdio_register_device() in it 
> > is broken and needs to be fixed.
> 
> that would be drivers/net/phy/fixed.c.
> 

OK, I'll look into it, thanks for pointing out.

> > It is independant from your previous question about unregistering the 
> > device from within module_init().
> 
> (yes - hence the different subject line, etc.)
> 


-- 
Sincerely, 
Vitaly

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"
  2007-03-30 14:16     ` [bug] hung bootup in various drivers, " Greg KH
@ 2007-03-30 17:46       ` Ingo Molnar
  2007-03-30 19:32         ` Greg KH
  0 siblings, 1 reply; 128+ messages in thread
From: Ingo Molnar @ 2007-03-30 17:46 UTC (permalink / raw)
  To: Greg KH
  Cc: Kay Sievers, Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel


* Greg KH <gregkh@suse.de> wrote:

> >  BUG: at drivers/base/driver.c:187 driver_unregister()
> >   [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
> >   [<c01063e2>] show_trace+0x12/0x14
> >   [<c01063f8>] dump_stack+0x14/0x16
> >   [<c063f7e6>] driver_unregister+0x3d/0x43
> >   [<c0488048>] pci_unregister_driver+0x10/0x5f
> >   [<c1b5f7c7>] slgt_init+0x9b/0x1ca
> >   [<c1b31a2d>] init+0x15d/0x2bd
> >   [<c0105bc3>] kernel_thread_helper+0x7/0x10

> Yes, we should allow the ability to call unregister_driver from within 
> the module_init function.
> 
> But I don't understand what is causing you to see this problem.  Who 
> is holding the reference on the struct device at this point in time?  
> Is it the fact that userspace has some files open and it hasn't 
> released them yet?

at least in the slgt_init() case the affected codepath is trivial:

        if ((rc = pci_register_driver(&pci_driver)) < 0) {
                printk("%s pci_register_driver error=%d\n", driver_name, rc);
                return rc;
        }
        pci_registered = 1;

        if (!slgt_device_list) {
                printk("%s no devices found\n",driver_name);
                pci_unregister_driver(&pci_driver);
                return -ENODEV;

slgt_device_list is NULL because no matching PCI ID is on my system (i 
dont have this hardware), so the ->probe() function did not get called 
at all.

i.e. a pure pci_register_driver() + pci_unregister_driver() sequence 
seems to cause a hang. I.e. it seems to be a pure driver-base-core 
matter.

	Ingo

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [1/5] 2.6.21-rc5: known regressions
  2007-03-28 18:54   ` Kok, Auke
  2007-03-28 19:23     ` Ingo Molnar
@ 2007-03-30 18:04     ` Adrian Bunk
  1 sibling, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-30 18:04 UTC (permalink / raw)
  To: Kok, Auke
  Cc: Ingo Molnar, Linus Torvalds, Andrew Morton,
	Linux Kernel Mailing List, Jesse Brandeburg, e1000-devel,
	jgarzik, netdev

On Wed, Mar 28, 2007 at 11:54:32AM -0700, Kok, Auke wrote:
> Adrian Bunk wrote:
> >Subject    : e1000 resume weirdness
> >References : http://lkml.org/lkml/2007/3/26/91
> >Submitter  : Ingo Molnar <mingo@elte.hu>
> >Handled-By : Jesse Brandeburg <jesse.brandeburg@gmail.com>
> >             Auke Kok <auke-jan.h.kok@intel.com>
> >Status     : problem is being debugged
> 
> The issue comes from a corner case and the underlying problem is that e1000 
> isn't stopping tx properly. We have a fix for this pending in our tree that 
> I'll push upstream for 2.6.22 to Jeff, but I don't think this should be a 
> blocker and it's probably is not a regression at all, the gap has always 
> been present.
> 
> on a side note, this is probably fixed easily by turning the adapters 
> detect_tx_hung flag off in e1000_down, so if someone spots this reoccurring 
> somewhat regularly, please contact me so we can debug it. I myself have a 
> system suspend/resuming in circles for an hour now with traffic flying 
> across without a single hit on it....
> 
> Adrian, you probably want to drop this issue from your list.

Thanks for the update, dropped as non-regression.

> Cheers,
> 
> 
> Auke

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


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"
  2007-03-30 17:46       ` Ingo Molnar
@ 2007-03-30 19:32         ` Greg KH
  2007-03-31  2:32           ` Kay Sievers
  2007-03-31 16:31           ` [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions" Ingo Molnar
  0 siblings, 2 replies; 128+ messages in thread
From: Greg KH @ 2007-03-30 19:32 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Kay Sievers, Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel

On Fri, Mar 30, 2007 at 07:46:19PM +0200, Ingo Molnar wrote:
> 
> * Greg KH <gregkh@suse.de> wrote:
> 
> > >  BUG: at drivers/base/driver.c:187 driver_unregister()
> > >   [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
> > >   [<c01063e2>] show_trace+0x12/0x14
> > >   [<c01063f8>] dump_stack+0x14/0x16
> > >   [<c063f7e6>] driver_unregister+0x3d/0x43
> > >   [<c0488048>] pci_unregister_driver+0x10/0x5f
> > >   [<c1b5f7c7>] slgt_init+0x9b/0x1ca
> > >   [<c1b31a2d>] init+0x15d/0x2bd
> > >   [<c0105bc3>] kernel_thread_helper+0x7/0x10
> 
> > Yes, we should allow the ability to call unregister_driver from within 
> > the module_init function.
> > 
> > But I don't understand what is causing you to see this problem.  Who 
> > is holding the reference on the struct device at this point in time?  
> > Is it the fact that userspace has some files open and it hasn't 
> > released them yet?
> 
> at least in the slgt_init() case the affected codepath is trivial:
> 
>         if ((rc = pci_register_driver(&pci_driver)) < 0) {
>                 printk("%s pci_register_driver error=%d\n", driver_name, rc);
>                 return rc;
>         }
>         pci_registered = 1;
> 
>         if (!slgt_device_list) {
>                 printk("%s no devices found\n",driver_name);
>                 pci_unregister_driver(&pci_driver);
>                 return -ENODEV;
> 
> slgt_device_list is NULL because no matching PCI ID is on my system (i 
> dont have this hardware), so the ->probe() function did not get called 
> at all.

Sorry, no, I realize how this could happen in the driver, I just don't
see what in the driver core would be keeping this driver from having
it's release function called at the unregister() time.

Something has grabbed a reference to the driver...

Oh wait, is this code a module or built into the kernel?

If it's built in, there's still a reference counting bug in the
module/driver hookup logic as we really don't have a "module" yet we are
still thinking we do as we represent it in /sys/module and create the
linkages.

I created some horrible patches to try to track this down, as it was
reported on lkml (look for "Subject: kref refcounting breakage in mainline" )
but never got it working correctly.

I bet if you build that code as a module, it will work just fine, can
you try it?

Kay, did you ever get a chance to look into this reference counting
issue?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 128+ messages in thread

* [1/4] 2.6.21-rc5: known regressions (v2)
  2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
@ 2007-03-30 21:32   ` Adrian Bunk
  2007-03-26  8:55 ` Linux 2.6.21-rc5 Thomas Gleixner
                     ` (18 subsequent siblings)
  19 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-30 21:32 UTC (permalink / raw)
  To: Linus Torvalds, Andrew Morton
  Cc: Linux Kernel Mailing List, Oliver Pinter, Ingo Molnar, Greg KH,
	Kay Sievers, Michal Jaegermann, lenb, linux-acpi, jgarzik,
	linux-ide, Mathieu Bérard, Tejun Heo

This email lists some known regressions in Linus' tree compared to 2.6.20.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : crashes in KDE
References : http://bugzilla.kernel.org/show_bug.cgi?id=8157
Submitter  : Oliver Pinter <oliver.pntr@gmail.com>
Status     : unknown


Subject    : hung bootup in various drivers
References : http://lkml.org/lkml/2007/3/30/68
Submitter  : Ingo Molnar <mingo@elte.hu>
Handled-By : Ingo Molnar <mingo@elte.hu>
             Greg KH <gregkh@suse.de>
             Kay Sievers <kay.sievers@vrfy.org>
Status     : problem is being discussed


Subject    : kernels fail to boot with drives on ATIIXP controller
             (ACPI/IRQ related)
References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621
             http://lkml.org/lkml/2007/3/4/257
Submitter  : Michal Jaegermann <michal@ellpspace.math.ualberta.ca>
Status     : unknown


Subject    : NCQ problem with ahci and Hitachi drive
References : http://lkml.org/lkml/2007/3/4/178
             http://lkml.org/lkml/2007/3/9/475
             http://lkml.org/lkml/2007/2/22/8
Submitter  : Mathieu Bérard <Mathieu.Berard@crans.org>
Handled-By : Tejun Heo <htejun@gmail.com>
Patch      : http://lkml.org/lkml/2007/2/22/8
Status     : possible patch available



-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 128+ messages in thread

* [1/4] 2.6.21-rc5: known regressions (v2)
@ 2007-03-30 21:32   ` Adrian Bunk
  0 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-30 21:32 UTC (permalink / raw)
  To: Linus Torvalds, Andrew Morton
  Cc: Linux Kernel Mailing List, Oliver Pinter, Ingo Molnar, Greg KH,
	Kay Sievers, Michal Jaegermann, lenb, linux-acpi, jgarzik,
	linux-ide, Mathieu Bérard, Tejun Heo

This email lists some known regressions in Linus' tree compared to 2.6.20.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : crashes in KDE
References : http://bugzilla.kernel.org/show_bug.cgi?id=8157
Submitter  : Oliver Pinter <oliver.pntr@gmail.com>
Status     : unknown


Subject    : hung bootup in various drivers
References : http://lkml.org/lkml/2007/3/30/68
Submitter  : Ingo Molnar <mingo@elte.hu>
Handled-By : Ingo Molnar <mingo@elte.hu>
             Greg KH <gregkh@suse.de>
             Kay Sievers <kay.sievers@vrfy.org>
Status     : problem is being discussed


Subject    : kernels fail to boot with drives on ATIIXP controller
             (ACPI/IRQ related)
References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621
             http://lkml.org/lkml/2007/3/4/257
Submitter  : Michal Jaegermann <michal@ellpspace.math.ualberta.ca>
Status     : unknown


Subject    : NCQ problem with ahci and Hitachi drive
References : http://lkml.org/lkml/2007/3/4/178
             http://lkml.org/lkml/2007/3/9/475
             http://lkml.org/lkml/2007/2/22/8
Submitter  : Mathieu Bérard <Mathieu.Berard@crans.org>
Handled-By : Tejun Heo <htejun@gmail.com>
Patch      : http://lkml.org/lkml/2007/2/22/8
Status     : possible patch available




^ permalink raw reply	[flat|nested] 128+ messages in thread

* [2/4] 2.6.21-rc5: known regressions (v2)
  2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
                   ` (15 preceding siblings ...)
  2007-03-30 21:32   ` Adrian Bunk
@ 2007-03-30 21:32 ` Adrian Bunk
  2007-03-30 21:32   ` Adrian Bunk
                   ` (2 subsequent siblings)
  19 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-30 21:32 UTC (permalink / raw)
  To: Linus Torvalds, Andrew Morton
  Cc: Linux Kernel Mailing List, Hans-Georg Rist, perex, alsa-devel,
	Michal Piotrowski, Andi Kleen, Oliver Neukum, greg,
	linux-usb-devel, Marcelo Tosatti, CIJOML, v4l-dvb-maintainer,
	Ingo Molnar, Ayaz Abdulla, jgarzik, netdev

This email lists some known regressions in Linus' tree compared to 2.6.20.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : snd_hda_intel doesn't work with ASUS M2V mainboard
References : http://bugzilla.kernel.org/show_bug.cgi?id=8273
Submitter  : Hans-Georg Rist <hg.rist@web.de>
Status     : unknown


Subject    : snd_intel8x0: divide error: 0000
References : http://lkml.org/lkml/2007/3/5/252
Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Status     : unknown


Subject    : hal daemon crashes after pulling a USB serial device
References : http://www.opensubscriber.com/message/linux-usb-devel@lists.sourceforge.net/6369800.html
Submitter  : Andi Kleen <ak@suse.de>
Handled-By : Oliver Neukum <oneukum@suse.de>
Status     : problem is being debugged


Subject    : USB: iPod doesn't work  (CONFIG_USB_SUSPEND)
References : http://lkml.org/lkml/2007/3/21/320
Submitter  : Tino Keitel <tino.keitel@gmx.de>
Caused-By  : Marcelo Tosatti <marcelo@kvack.org>
             commit 1d619f128ba911cd3e6d6ad3475f146eb92f5c27
Handled-By : Oliver Neukum <oneukum@suse.de>
Status     : problem is being debuggged


Subject    : USB: Oops when changing DVB-T adapter
References : http://lkml.org/lkml/2007/3/9/212
Submitter  : CIJOML <cijoml@volny.cz>
Status     : unknown


Subject    : forcedeth: sporadic under-load crashes
References : http://lkml.org/lkml/2007/3/26/63
Submitter  : Ingo Molnar <mingo@elte.hu>
Handled-By : Ingo Molnar <mingo@elte.hu>
             Ayaz Abdulla <aabdulla@nvidia.com>
Status     : problem is being debugged



^ permalink raw reply	[flat|nested] 128+ messages in thread

* [3/4] 2.6.21-rc5: known regressions (v2)
  2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
@ 2007-03-30 21:32   ` Adrian Bunk
  2007-03-26  8:55 ` Linux 2.6.21-rc5 Thomas Gleixner
                     ` (18 subsequent siblings)
  19 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-30 21:32 UTC (permalink / raw)
  To: Linus Torvalds, Andrew Morton
  Cc: Len Brown, Jeremy Fitzhardinge, tigran, Michal Piotrowski,
	adaplas, Soeren Sonnenburg, Marcus Better, linux-ide, Jens Axboe,
	Thomas Gleixner, Stephen Hemminger, Maxim Levitsky, Mike Harris,
	Jeff Chua, netdev, gregkh, linux-pm, Linux Kernel Mailing List,
	linux-acpi, Eric W. Biederman, linux-pci, jgarzik,
	Tobias Doerffel

This email lists some known regressions in Linus' tree compared to 2.6.20.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : ThinkPad X60: resume no longer works  (PCI related?)
References : http://lkml.org/lkml/2007/3/13/3
Submitter  : Dave Jones <davej@redhat.com>
             Jeremy Fitzhardinge <jeremy@goop.org>
Caused-By  : PCI merge
             commit 78149df6d565c36675463352d0bfe0000b02b7a7
Handled-By : Eric W. Biederman <ebiederm@xmission.com>
             Rafael J. Wysocki <rjw@sisk.pl>
Status     : problem is being debugged


Subject    : Suspend to RAM doesn't work anymore  (ACPI?)
References : http://lkml.org/lkml/2007/3/19/128
             http://bugzilla.kernel.org/show_bug.cgi?id=8247
Submitter  : Tobias Doerffel <tobias.doerffel@gmail.com>
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
             Len Brown <len.brown@intel.com>
Status     : problem is being debugged


Subject    : SATA breakage on resume
References : http://lkml.org/lkml/2007/3/7/233
Submitter  : Thomas Gleixner <tglx@linutronix.de>
             Soeren Sonnenburg <kernel@nn7.de>
Status     : unknown


Subject    : resume from RAM corrupts vesafb console
References : http://lkml.org/lkml/2007/3/26/76
Submitter  : Marcus Better <marcus@better.se>
Handled-By : Pavel Machek <pavel@ucw.cz>
Status     : problem is being debugged


Subject    : ThinkPad doesn't resume from suspend to RAM
References : http://lkml.org/lkml/2007/2/27/80
             http://lkml.org/lkml/2007/2/28/348
Submitter  : Jens Axboe <jens.axboe@oracle.com>
             Jeff Chua <jeff.chua.linux@gmail.com>
Status     : unknown


Subject    : MacBook Core Duo: suspend to memory wakeup hang
References : http://bugzilla.kernel.org/show_bug.cgi?id=8272
Submitter  : Mike Harris <atarimike@wavecable.com>
Status     : unknown


Subject    : suspend to disk hangs  (skge)
References : http://lkml.org/lkml/2007/3/27/212
Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Caused-By  : Stephen Hemminger <shemminger@linux-foundation.org>
             commit a504e64ab42bcc27074ea37405d06833ed6e0820
Status     : unknown


Subject    : suspend to disk hangs  (microcode driver)
References : http://lkml.org/lkml/2007/3/16/126
Submitter  : Maxim Levitsky <maximlevitsky@gmail.com>
Caused-By  : Rafael J. Wysocki <rjw@sisk.pl>
             commit e3c7db621bed4afb8e231cb005057f2feb5db557
             commit ed746e3b18f4df18afa3763155972c5835f284c5
             commit 259130526c267550bc365d3015917d90667732f1
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Patch      : http://lkml.org/lkml/2007/3/25/71
Status     : patch available

^ permalink raw reply	[flat|nested] 128+ messages in thread

* [3/4] 2.6.21-rc5: known regressions (v2)
@ 2007-03-30 21:32   ` Adrian Bunk
  0 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-30 21:32 UTC (permalink / raw)
  To: Linus Torvalds, Andrew Morton
  Cc: Linux Kernel Mailing List, Dave Jones, Jeremy Fitzhardinge,
	Eric W. Biederman, Rafael J. Wysocki, pavel, linux-pm, gregkh,
	linux-pci, Tobias Doerffel, Len Brown, linux-acpi,
	Thomas Gleixner, Soeren Sonnenburg, jgarzik, linux-ide,
	Marcus Better, adaplas, Jens Axboe, Jeff Chua, Mike Harris,
	Michal Piotrowski, Stephen Hemminger, netdev, Maxim Levitsky,
	tigran

This email lists some known regressions in Linus' tree compared to 2.6.20.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : ThinkPad X60: resume no longer works  (PCI related?)
References : http://lkml.org/lkml/2007/3/13/3
Submitter  : Dave Jones <davej@redhat.com>
             Jeremy Fitzhardinge <jeremy@goop.org>
Caused-By  : PCI merge
             commit 78149df6d565c36675463352d0bfe0000b02b7a7
Handled-By : Eric W. Biederman <ebiederm@xmission.com>
             Rafael J. Wysocki <rjw@sisk.pl>
Status     : problem is being debugged


Subject    : Suspend to RAM doesn't work anymore  (ACPI?)
References : http://lkml.org/lkml/2007/3/19/128
             http://bugzilla.kernel.org/show_bug.cgi?id=8247
Submitter  : Tobias Doerffel <tobias.doerffel@gmail.com>
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
             Len Brown <len.brown@intel.com>
Status     : problem is being debugged


Subject    : SATA breakage on resume
References : http://lkml.org/lkml/2007/3/7/233
Submitter  : Thomas Gleixner <tglx@linutronix.de>
             Soeren Sonnenburg <kernel@nn7.de>
Status     : unknown


Subject    : resume from RAM corrupts vesafb console
References : http://lkml.org/lkml/2007/3/26/76
Submitter  : Marcus Better <marcus@better.se>
Handled-By : Pavel Machek <pavel@ucw.cz>
Status     : problem is being debugged


Subject    : ThinkPad doesn't resume from suspend to RAM
References : http://lkml.org/lkml/2007/2/27/80
             http://lkml.org/lkml/2007/2/28/348
Submitter  : Jens Axboe <jens.axboe@oracle.com>
             Jeff Chua <jeff.chua.linux@gmail.com>
Status     : unknown


Subject    : MacBook Core Duo: suspend to memory wakeup hang
References : http://bugzilla.kernel.org/show_bug.cgi?id=8272
Submitter  : Mike Harris <atarimike@wavecable.com>
Status     : unknown


Subject    : suspend to disk hangs  (skge)
References : http://lkml.org/lkml/2007/3/27/212
Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Caused-By  : Stephen Hemminger <shemminger@linux-foundation.org>
             commit a504e64ab42bcc27074ea37405d06833ed6e0820
Status     : unknown


Subject    : suspend to disk hangs  (microcode driver)
References : http://lkml.org/lkml/2007/3/16/126
Submitter  : Maxim Levitsky <maximlevitsky@gmail.com>
Caused-By  : Rafael J. Wysocki <rjw@sisk.pl>
             commit e3c7db621bed4afb8e231cb005057f2feb5db557
             commit ed746e3b18f4df18afa3763155972c5835f284c5
             commit 259130526c267550bc365d3015917d90667732f1
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Patch      : http://lkml.org/lkml/2007/3/25/71
Status     : patch available


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [1/4] 2.6.21-rc5: known regressions (v2)
  2007-03-30 21:32   ` Adrian Bunk
  (?)
@ 2007-03-30 21:38   ` Greg KH
  -1 siblings, 0 replies; 128+ messages in thread
From: Greg KH @ 2007-03-30 21:38 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
	Oliver Pinter, Ingo Molnar, Kay Sievers, Michal Jaegermann, lenb,
	linux-acpi, jgarzik, linux-ide, Mathieu B??rard, Tejun Heo

On Fri, Mar 30, 2007 at 11:32:09PM +0200, Adrian Bunk wrote:
> Subject    : hung bootup in various drivers
> References : http://lkml.org/lkml/2007/3/30/68
> Submitter  : Ingo Molnar <mingo@elte.hu>
> Handled-By : Ingo Molnar <mingo@elte.hu>
>              Greg KH <gregkh@suse.de>
>              Kay Sievers <kay.sievers@vrfy.org>
> Status     : problem is being discussed

Note, this should probably read:
	hung bootup for drivers built into the kernel, that fail their
	module_init() call.

A much smaller minority of cases :)

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 128+ messages in thread

* [4/4] 2.6.21-rc5: known regressions (v2)
  2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
@ 2007-03-30 21:49   ` Adrian Bunk
  2007-03-26  8:55 ` Linux 2.6.21-rc5 Thomas Gleixner
                     ` (18 subsequent siblings)
  19 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-30 21:49 UTC (permalink / raw)
  To: Linus Torvalds, Andrew Morton
  Cc: Linux Kernel Mailing List, Frédéric Riss, Tino Keitel,
	Thomas Gleixner, pavel, linux-pm, Michael S. Tsirkin,
	Soeren Sonnenburg, Ingo Molnar, Tejun Heo, Rafael J. Wysocki,
	Jeff Chua

[ this time with a Cc... ]

This email lists some known regressions in Linus' tree compared to 2.6.20.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : MacMini doesn't come out of suspend to ram  (i386 clockevents)
             (CONFIG_HPET_TIMER)
References : http://lkml.org/lkml/2007/3/21/374
Submitter  : Frédéric Riss <frederic.riss@gmail.com>
             Tino Keitel <tino.keitel@gmx.de>
Caused-By  : Thomas Gleixner <tglx@linutronix.de>
             commit e9e2cdb412412326c4827fc78ba27f410d837e6e
Status     : unknown


Subject    : after resume: X hangs after drawing a couple of windows
             workaround: clocksource=acpi_pm
References : http://lkml.org/lkml/2007/3/8/117
             http://lkml.org/lkml/2007/3/25/20
             http://lkml.org/lkml/2007/3/26/151
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Status     : problem is being debugged


Subject    : system doesn't come out of suspend  (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/22/391
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
             Soeren Sonnenburg <kernel@nn7.de>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
             Ingo Molnar <mingo@elte.hu>
             Tejun Heo <htejun@gmail.com>
             Rafael J. Wysocki <rjw@sisk.pl>
Status     : unknown


Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/3/25/217
Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
Status     : unknown



^ permalink raw reply	[flat|nested] 128+ messages in thread

* [4/4] 2.6.21-rc5: known regressions (v2)
@ 2007-03-30 21:49   ` Adrian Bunk
  0 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-30 21:49 UTC (permalink / raw)
  To: Linus Torvalds, Andrew Morton
  Cc: Soeren Sonnenburg, Tejun Heo, Frédéric Riss, Jeff Chua,
	Tino Keitel, linux-pm, Linux Kernel Mailing List,
	Michael S. Tsirkin, Ingo Molnar, Thomas Gleixner

[ this time with a Cc... ]

This email lists some known regressions in Linus' tree compared to 2.6.20.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : MacMini doesn't come out of suspend to ram  (i386 clockevents)
             (CONFIG_HPET_TIMER)
References : http://lkml.org/lkml/2007/3/21/374
Submitter  : Frédéric Riss <frederic.riss@gmail.com>
             Tino Keitel <tino.keitel@gmx.de>
Caused-By  : Thomas Gleixner <tglx@linutronix.de>
             commit e9e2cdb412412326c4827fc78ba27f410d837e6e
Status     : unknown


Subject    : after resume: X hangs after drawing a couple of windows
             workaround: clocksource=acpi_pm
References : http://lkml.org/lkml/2007/3/8/117
             http://lkml.org/lkml/2007/3/25/20
             http://lkml.org/lkml/2007/3/26/151
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Status     : problem is being debugged


Subject    : system doesn't come out of suspend  (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/22/391
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
             Soeren Sonnenburg <kernel@nn7.de>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
             Ingo Molnar <mingo@elte.hu>
             Tejun Heo <htejun@gmail.com>
             Rafael J. Wysocki <rjw@sisk.pl>
Status     : unknown


Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/3/25/217
Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
Status     : unknown

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [1/4] 2.6.21-rc5: known regressions (v2)
  2007-03-30 21:32   ` Adrian Bunk
  (?)
  (?)
@ 2007-03-31  0:23   ` Michal Jaegermann
  2007-03-31 15:01     ` Adrian Bunk
  -1 siblings, 1 reply; 128+ messages in thread
From: Michal Jaegermann @ 2007-03-31  0:23 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Linux Kernel Mailing List, linux-acpi, jgarzik, linux-ide, Tejun Heo

On Fri, Mar 30, 2007 at 11:32:09PM +0200, Adrian Bunk wrote:
> 
> Subject    : kernels fail to boot with drives on ATIIXP controller
>              (ACPI/IRQ related)
> References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621
>              http://lkml.org/lkml/2007/3/4/257
> Submitter  : Michal Jaegermann <michal@ellpspace.math.ualberta.ca>
> Status     : unknown

I have now even better one with pata_via.  A kernel, which for
all practical purposes is 2.6.21-rc5, not only refuses to boot
(and I cannot find some option combination which would allow me to
do so anyway) but simply refuses to read _any_ data from a media.
This included a partitioning information.

Earlier kernel on the same hardware boots without raising any fuss.

Details are collected as
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234650

   Michal

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"
  2007-03-30 19:32         ` Greg KH
@ 2007-03-31  2:32           ` Kay Sievers
  2007-03-31 16:51             ` [patch] driver core: fix built-in drivers sysfs links Ingo Molnar
  2007-03-31 16:31           ` [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions" Ingo Molnar
  1 sibling, 1 reply; 128+ messages in thread
From: Kay Sievers @ 2007-03-31  2:32 UTC (permalink / raw)
  To: Greg KH
  Cc: Ingo Molnar, Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel

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

On Fri, 2007-03-30 at 12:32 -0700, Greg KH wrote:
> On Fri, Mar 30, 2007 at 07:46:19PM +0200, Ingo Molnar wrote:
> > 
> > * Greg KH <gregkh@suse.de> wrote:
> > 
> > > >  BUG: at drivers/base/driver.c:187 driver_unregister()
> > > >   [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
> > > >   [<c01063e2>] show_trace+0x12/0x14
> > > >   [<c01063f8>] dump_stack+0x14/0x16
> > > >   [<c063f7e6>] driver_unregister+0x3d/0x43
> > > >   [<c0488048>] pci_unregister_driver+0x10/0x5f
> > > >   [<c1b5f7c7>] slgt_init+0x9b/0x1ca
> > > >   [<c1b31a2d>] init+0x15d/0x2bd
> > > >   [<c0105bc3>] kernel_thread_helper+0x7/0x10
> > 
> > > Yes, we should allow the ability to call unregister_driver from within 
> > > the module_init function.
> > > 
> > > But I don't understand what is causing you to see this problem.  Who 
> > > is holding the reference on the struct device at this point in time?  
> > > Is it the fact that userspace has some files open and it hasn't 
> > > released them yet?
> > 
> > at least in the slgt_init() case the affected codepath is trivial:
> > 
> >         if ((rc = pci_register_driver(&pci_driver)) < 0) {
> >                 printk("%s pci_register_driver error=%d\n", driver_name, rc);
> >                 return rc;
> >         }
> >         pci_registered = 1;
> > 
> >         if (!slgt_device_list) {
> >                 printk("%s no devices found\n",driver_name);
> >                 pci_unregister_driver(&pci_driver);
> >                 return -ENODEV;
> > 
> > slgt_device_list is NULL because no matching PCI ID is on my system (i 
> > dont have this hardware), so the ->probe() function did not get called 
> > at all.
> 
> Sorry, no, I realize how this could happen in the driver, I just don't
> see what in the driver core would be keeping this driver from having
> it's release function called at the unregister() time.
> 
> Something has grabbed a reference to the driver...
> 
> Oh wait, is this code a module or built into the kernel?
> 
> If it's built in, there's still a reference counting bug in the
> module/driver hookup logic as we really don't have a "module" yet we are
> still thinking we do as we represent it in /sys/module and create the
> linkages.
> 
> I created some horrible patches to try to track this down, as it was
> reported on lkml (look for "Subject: kref refcounting breakage in mainline" )
> but never got it working correctly.
> 
> I bet if you build that code as a module, it will work just fine, can
> you try it?
> 
> Kay, did you ever get a chance to look into this reference counting
> issue?

Does the attached work for you?

Thanks,
Kay

[-- Attachment #2: built-in-driver-links-fix.patch --]
[-- Type: text/x-patch, Size: 1573 bytes --]

diff --git a/include/linux/device.h b/include/linux/device.h
index caad9bb..5cf30e9 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -128,6 +128,7 @@ struct device_driver {
 
 	struct module		* owner;
 	const char 		* mod_name;	/* used for built-in modules */
+	struct module_kobject	* mkobj;
 
 	int	(*probe)	(struct device * dev);
 	int	(*remove)	(struct device * dev);
diff --git a/kernel/module.c b/kernel/module.c
index fbc51de..dcdb32b 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2384,8 +2384,13 @@ void module_add_driver(struct module *mo
 
 		/* Lookup built-in module entry in /sys/modules */
 		mkobj = kset_find_obj(&module_subsys.kset, drv->mod_name);
-		if (mkobj)
+		if (mkobj) {
 			mk = container_of(mkobj, struct module_kobject, kobj);
+			/* remember our module structure */
+			drv->mkobj = mk;
+			/* kset_find_obj took a reference */
+			kobject_put(mkobj);
+		}
 	}
 
 	if (!mk)
@@ -2405,17 +2410,22 @@ EXPORT_SYMBOL(module_add_driver);
 
 void module_remove_driver(struct device_driver *drv)
 {
+	struct module_kobject *mk = NULL;
 	char *driver_name;
 
 	if (!drv)
 		return;
 
 	sysfs_remove_link(&drv->kobj, "module");
-	if (drv->owner && drv->owner->mkobj.drivers_dir) {
+
+	if (drv->owner)
+		mk = &drv->owner->mkobj;
+	else if (drv->mkobj)
+		mk = drv->mkobj;
+	if (mk && mk->drivers_dir) {
 		driver_name = make_driver_name(drv);
 		if (driver_name) {
-			sysfs_remove_link(drv->owner->mkobj.drivers_dir,
-					  driver_name);
+			sysfs_remove_link(mk->drivers_dir, driver_name);
 			kfree(driver_name);
 		}
 	}

^ permalink raw reply related	[flat|nested] 128+ messages in thread

* Re: [4/4] 2.6.21-rc5: known regressions (v2)
  2007-03-30 21:49   ` Adrian Bunk
@ 2007-03-31  2:41     ` Jeff Chua
  -1 siblings, 0 replies; 128+ messages in thread
From: Jeff Chua @ 2007-03-31  2:41 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
	Frédéric Riss, Tino Keitel, Thomas Gleixner, pavel,
	linux-pm, Michael S. Tsirkin, Soeren Sonnenburg, Ingo Molnar,
	Tejun Heo, Rafael J. Wysocki

On 3/31/07, Adrian Bunk <bunk@stusta.de> wrote:

> Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
> References : http://lkml.org/lkml/2007/3/25/217
> Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> Status     : unknown

Still broken on.2.6.21-rc5.

Jeff.

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [4/4] 2.6.21-rc5: known regressions (v2)
@ 2007-03-31  2:41     ` Jeff Chua
  0 siblings, 0 replies; 128+ messages in thread
From: Jeff Chua @ 2007-03-31  2:41 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Soeren Sonnenburg, Tejun Heo, Frédéric Riss,
	Tino Keitel, linux-pm, Linux Kernel Mailing List, Andrew Morton,
	Michael S. Tsirkin, Thomas Gleixner, Linus Torvalds, Ingo Molnar

On 3/31/07, Adrian Bunk <bunk@stusta.de> wrote:

> Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
> References : http://lkml.org/lkml/2007/3/25/217
> Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> Status     : unknown

Still broken on.2.6.21-rc5.

Jeff.

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [3/4] 2.6.21-rc5: known regressions (v2)
  2007-03-30 21:32   ` Adrian Bunk
  (?)
@ 2007-03-31  2:52     ` Jeff Chua
  -1 siblings, 0 replies; 128+ messages in thread
From: Jeff Chua @ 2007-03-31  2:52 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
	Dave Jones, Jeremy Fitzhardinge, Eric W. Biederman,
	Rafael J. Wysocki, pavel, linux-pm, gregkh, linux-pci,
	Tobias Doerffel, Len Brown, linux-acpi, Thomas Gleixner,
	Soeren Sonnenburg, jgarzik, linux-ide, Marcus Better, adaplas,
	Jens Axboe, Mike Harris, Michal Piotrowski, Stephen Hemminger

On 3/31/07, Adrian Bunk <bunk@stusta.de> wrote:

> Subject    : ThinkPad doesn't resume from suspend to RAM
> References : http://lkml.org/lkml/2007/2/27/80
>              http://lkml.org/lkml/2007/2/28/348
> Submitter  : Jens Axboe <jens.axboe@oracle.com>
>              Jeff Chua <jeff.chua.linux@gmail.com>
> Status     : unknown

Fixed with CONFIG_NO_HZ unset and patch from Maxim
(http://lkml.org/lkml/2007/3/29/108).

Thanks,
Jeff,

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [3/4] 2.6.21-rc5: known regressions (v2)
@ 2007-03-31  2:52     ` Jeff Chua
  0 siblings, 0 replies; 128+ messages in thread
From: Jeff Chua @ 2007-03-31  2:52 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
	Dave Jones, Jeremy Fitzhardinge, Eric W. Biederman,
	Rafael J. Wysocki, pavel, linux-pm, gregkh, linux-pci,
	Tobias Doerffel, Len Brown, linux-acpi, Thomas Gleixner,
	Soeren Sonnenburg, jgarzik, linux-ide, Marcus Better, adaplas,
	Jens Axboe, Mike Harris, Michal Piotrowski, Stephen Hemminger,
	netdev, Maxim Levitsky, tigran

On 3/31/07, Adrian Bunk <bunk@stusta.de> wrote:

> Subject    : ThinkPad doesn't resume from suspend to RAM
> References : http://lkml.org/lkml/2007/2/27/80
>              http://lkml.org/lkml/2007/2/28/348
> Submitter  : Jens Axboe <jens.axboe@oracle.com>
>              Jeff Chua <jeff.chua.linux@gmail.com>
> Status     : unknown

Fixed with CONFIG_NO_HZ unset and patch from Maxim
(http://lkml.org/lkml/2007/3/29/108).

Thanks,
Jeff,

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [3/4] 2.6.21-rc5: known regressions (v2)
@ 2007-03-31  2:52     ` Jeff Chua
  0 siblings, 0 replies; 128+ messages in thread
From: Jeff Chua @ 2007-03-31  2:52 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
	Dave Jones, Jeremy Fitzhardinge, Eric W. Biederman,
	Rafael J. Wysocki, pavel, linux-pm, gregkh, linux-pci,
	Tobias Doerffel, Len Brown, linux-acpi, Thomas Gleixner,
	Soeren Sonnenburg, jgarzik, linux-ide, Marcus Better, adaplas,
	Jens Axboe, Mike Harris, Michal Piotrowski, Stephen Hemminger

On 3/31/07, Adrian Bunk <bunk@stusta.de> wrote:

> Subject    : ThinkPad doesn't resume from suspend to RAM
> References : http://lkml.org/lkml/2007/2/27/80
>              http://lkml.org/lkml/2007/2/28/348
> Submitter  : Jens Axboe <jens.axboe@oracle.com>
>              Jeff Chua <jeff.chua.linux@gmail.com>
> Status     : unknown

Fixed with CONFIG_NO_HZ unset and patch from Maxim
(http://lkml.org/lkml/2007/3/29/108).

Thanks,
Jeff,

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [3/4] 2.6.21-rc5: known regressions (v2)
  2007-03-31  2:52     ` Jeff Chua
  (?)
  (?)
@ 2007-03-31  3:16     ` Adrian Bunk
  2007-03-31 11:08       ` Jens Axboe
  -1 siblings, 1 reply; 128+ messages in thread
From: Adrian Bunk @ 2007-03-31  3:16 UTC (permalink / raw)
  To: Jeff Chua
  Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, pavel,
	linux-pm, Len Brown, linux-acpi, Jens Axboe, Maxim Levitsky

On Sat, Mar 31, 2007 at 10:52:59AM +0800, Jeff Chua wrote:
> On 3/31/07, Adrian Bunk <bunk@stusta.de> wrote:
> 
> >Subject    : ThinkPad doesn't resume from suspend to RAM
> >References : http://lkml.org/lkml/2007/2/27/80
> >             http://lkml.org/lkml/2007/2/28/348
> >Submitter  : Jens Axboe <jens.axboe@oracle.com>
> >             Jeff Chua <jeff.chua.linux@gmail.com>
> >Status     : unknown
> 
> Fixed with CONFIG_NO_HZ unset and patch from Maxim
> (http://lkml.org/lkml/2007/3/29/108).

Thanks for this information.

Jens, does suspend to RAM also work for you with the latest -git?

> Thanks,
> Jeff,

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


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [4/4] 2.6.21-rc5: known regressions (v2)
  2007-03-30 21:49   ` Adrian Bunk
  (?)
  (?)
@ 2007-03-31  6:44   ` Frédéric Riss
  -1 siblings, 0 replies; 128+ messages in thread
From: Frédéric Riss @ 2007-03-31  6:44 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
	Tino Keitel, Thomas Gleixner, pavel, linux-pm, Ingo Molnar,
	Rafael J. Wysocki

Le vendredi 30 mars 2007 à 23:49 +0200, Adrian Bunk a écrit :
> Subject    : MacMini doesn't come out of suspend to ram  (i386 clockevents)
>              (CONFIG_HPET_TIMER)
> References : http://lkml.org/lkml/2007/3/21/374
> Submitter  : Frédéric Riss <frederic.riss@gmail.com>
>              Tino Keitel <tino.keitel@gmx.de>
> Caused-By  : Thomas Gleixner <tglx@linutronix.de>
>              commit e9e2cdb412412326c4827fc78ba27f410d837e6e
> Status     : unknown

This one has been fixed by 399afa4fc9238fbae42116cf25a54671c0e8f56e.
Suspend to ram now works with HPET enabled (and regardless of the NO_HZ
setting).

Thanks!

Fred.


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [3/4] 2.6.21-rc5: known regressions (v2)
  2007-03-31  3:16     ` Adrian Bunk
@ 2007-03-31 11:08       ` Jens Axboe
  0 siblings, 0 replies; 128+ messages in thread
From: Jens Axboe @ 2007-03-31 11:08 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Jeff Chua, Linus Torvalds, Andrew Morton,
	Linux Kernel Mailing List, pavel, linux-pm, Len Brown,
	linux-acpi, Maxim Levitsky

On Sat, Mar 31 2007, Adrian Bunk wrote:
> On Sat, Mar 31, 2007 at 10:52:59AM +0800, Jeff Chua wrote:
> > On 3/31/07, Adrian Bunk <bunk@stusta.de> wrote:
> > 
> > >Subject    : ThinkPad doesn't resume from suspend to RAM
> > >References : http://lkml.org/lkml/2007/2/27/80
> > >             http://lkml.org/lkml/2007/2/28/348
> > >Submitter  : Jens Axboe <jens.axboe@oracle.com>
> > >             Jeff Chua <jeff.chua.linux@gmail.com>
> > >Status     : unknown
> > 
> > Fixed with CONFIG_NO_HZ unset and patch from Maxim
> > (http://lkml.org/lkml/2007/3/29/108).
> 
> Thanks for this information.
> 
> Jens, does suspend to RAM also work for you with the latest -git?

Yep, it does, no problems since the last -rc.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [1/4] 2.6.21-rc5: known regressions (v2)
  2007-03-31  0:23   ` Michal Jaegermann
@ 2007-03-31 15:01     ` Adrian Bunk
  2007-03-31 16:42       ` Michal Jaegermann
  0 siblings, 1 reply; 128+ messages in thread
From: Adrian Bunk @ 2007-03-31 15:01 UTC (permalink / raw)
  To: Michal Jaegermann
  Cc: Linux Kernel Mailing List, linux-acpi, jgarzik, linux-ide, Tejun Heo

On Fri, Mar 30, 2007 at 06:23:10PM -0600, Michal Jaegermann wrote:
> On Fri, Mar 30, 2007 at 11:32:09PM +0200, Adrian Bunk wrote:
> > 
> > Subject    : kernels fail to boot with drives on ATIIXP controller
> >              (ACPI/IRQ related)
> > References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621
> >              http://lkml.org/lkml/2007/3/4/257
> > Submitter  : Michal Jaegermann <michal@ellpspace.math.ualberta.ca>
> > Status     : unknown
> 
> I have now even better one with pata_via.  A kernel, which for
> all practical purposes is 2.6.21-rc5, not only refuses to boot
> (and I cannot find some option combination which would allow me to
> do so anyway) but simply refuses to read _any_ data from a media.
> This included a partitioning information.
> 
> Earlier kernel on the same hardware boots without raising any fuss.
> 
> Details are collected as
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234650

If I understand this correctly, a plain 2.6.20 kernel is already broken?

>    Michal

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


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"
  2007-03-30 19:32         ` Greg KH
  2007-03-31  2:32           ` Kay Sievers
@ 2007-03-31 16:31           ` Ingo Molnar
  1 sibling, 0 replies; 128+ messages in thread
From: Ingo Molnar @ 2007-03-31 16:31 UTC (permalink / raw)
  To: Greg KH
  Cc: Kay Sievers, Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel


* Greg KH <gregkh@suse.de> wrote:

> Something has grabbed a reference to the driver...
> 
> Oh wait, is this code a module or built into the kernel?
> 
> If it's built in, there's still a reference counting bug in the 
> module/driver hookup logic as we really don't have a "module" yet we 
> are still thinking we do as we represent it in /sys/module and create 
> the linkages.

yes - an allyesconfig bzImage kernel is definitely massively built in :)

> Kay, did you ever get a chance to look into this reference counting 
> issue?

i'll try Kay's patch.

	Ingo

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [1/4] 2.6.21-rc5: known regressions (v2)
  2007-03-31 15:01     ` Adrian Bunk
@ 2007-03-31 16:42       ` Michal Jaegermann
  0 siblings, 0 replies; 128+ messages in thread
From: Michal Jaegermann @ 2007-03-31 16:42 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Linux Kernel Mailing List, linux-acpi, jgarzik, linux-ide, Tejun Heo

On Sat, Mar 31, 2007 at 05:01:23PM +0200, Adrian Bunk wrote:
> On Fri, Mar 30, 2007 at 06:23:10PM -0600, Michal Jaegermann wrote:
> > On Fri, Mar 30, 2007 at 11:32:09PM +0200, Adrian Bunk wrote:
> > > 
> > > Subject    : kernels fail to boot with drives on ATIIXP controller
> > >              (ACPI/IRQ related)
> > > References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621
> > >              http://lkml.org/lkml/2007/3/4/257
> > > Submitter  : Michal Jaegermann <michal@ellpspace.math.ualberta.ca>
> > > Status     : unknown
> > 
> > I have now even better one with pata_via.  A kernel, which for
> > all practical purposes is 2.6.21-rc5, not only refuses to boot
> > (and I cannot find some option combination which would allow me to
> > do so anyway) but simply refuses to read _any_ data from a media.
> > This included a partitioning information.
> > 
> > Earlier kernel on the same hardware boots without raising any fuss.
> > 
> > Details are collected as
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234650
> 
> If I understand this correctly, a plain 2.6.20 kernel is already broken?

You mean that a quoted report talks about 2.6.20-1.3025.fc7 kernel?
These are vagaries of kernel version numbering in Fedora.
Changelogs are not that clear but it appears that
2.6.19-1.2911.6.4.fc6 will be actually closer to 2.6.20.
That kernel from a bug report is really, for all intents and purposes,
2.6.21-rc5 (if I am not misreading something).

I am afraid that I do not have at this moment an easy to way to check
"plain" 2.6.20 on the hardware in question.  It appears that the
essential difference is that a working kernel is using and old IDE
driver, and sees the drive - in this case - as /dev/hdc, while the
current one tries to go through libata and chockes uncontrollably.

   Michal

^ permalink raw reply	[flat|nested] 128+ messages in thread

* [patch] driver core: fix built-in drivers sysfs links
  2007-03-31  2:32           ` Kay Sievers
@ 2007-03-31 16:51             ` Ingo Molnar
  0 siblings, 0 replies; 128+ messages in thread
From: Ingo Molnar @ 2007-03-31 16:51 UTC (permalink / raw)
  To: Kay Sievers
  Cc: Greg KH, Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel


* Kay Sievers <kay.sievers@vrfy.org> wrote:

> > I bet if you build that code as a module, it will work just fine, 
> > can you try it?
> > 
> > Kay, did you ever get a chance to look into this reference counting 
> > issue?
> 
> Does the attached work for you?

yeah, this fixed the hangs!

please push it to Andrew and Linus, we want this in v2.6.21. See the 
full patch below, with proper headers, etc.

	Ingo

--------------------->
From: Kay Sievers <kay.sievers@vrfy.org>
Subject: [patch] driver core: fix built-in drivers sysfs links

built-in drivers had broken sysfs links that caused bootup hangs for 
certain driver unregistry sequences.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 include/linux/device.h |    1 +
 kernel/module.c        |   18 ++++++++++++++----
 2 files changed, 15 insertions(+), 4 deletions(-)

Index: linux/include/linux/device.h
===================================================================
--- linux.orig/include/linux/device.h
+++ linux/include/linux/device.h
@@ -128,6 +128,7 @@ struct device_driver {
 
 	struct module		* owner;
 	const char 		* mod_name;	/* used for built-in modules */
+	struct module_kobject	* mkobj;
 
 	int	(*probe)	(struct device * dev);
 	int	(*remove)	(struct device * dev);
Index: linux/kernel/module.c
===================================================================
--- linux.orig/kernel/module.c
+++ linux/kernel/module.c
@@ -2384,8 +2384,13 @@ void module_add_driver(struct module *mo
 
 		/* Lookup built-in module entry in /sys/modules */
 		mkobj = kset_find_obj(&module_subsys.kset, drv->mod_name);
-		if (mkobj)
+		if (mkobj) {
 			mk = container_of(mkobj, struct module_kobject, kobj);
+			/* remember our module structure */
+			drv->mkobj = mk;
+			/* kset_find_obj took a reference */
+			kobject_put(mkobj);
+		}
 	}
 
 	if (!mk)
@@ -2405,17 +2410,22 @@ EXPORT_SYMBOL(module_add_driver);
 
 void module_remove_driver(struct device_driver *drv)
 {
+	struct module_kobject *mk = NULL;
 	char *driver_name;
 
 	if (!drv)
 		return;
 
 	sysfs_remove_link(&drv->kobj, "module");
-	if (drv->owner && drv->owner->mkobj.drivers_dir) {
+
+	if (drv->owner)
+		mk = &drv->owner->mkobj;
+	else if (drv->mkobj)
+		mk = drv->mkobj;
+	if (mk && mk->drivers_dir) {
 		driver_name = make_driver_name(drv);
 		if (driver_name) {
-			sysfs_remove_link(drv->owner->mkobj.drivers_dir,
-					  driver_name);
+			sysfs_remove_link(mk->drivers_dir, driver_name);
 			kfree(driver_name);
 		}
 	}

^ permalink raw reply	[flat|nested] 128+ messages in thread

* 2.6.21-rc5: known regressions with patches (v2)
  2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
@ 2007-03-31 18:19   ` Adrian Bunk
  2007-03-26  8:55 ` Linux 2.6.21-rc5 Thomas Gleixner
                     ` (18 subsequent siblings)
  19 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-31 18:19 UTC (permalink / raw)
  To: Linus Torvalds, Andrew Morton
  Cc: Robert Hancock, tigran, Tejun Heo, Maxim Levitsky, Kay Sievers,
	linux-pm, Linux Kernel Mailing List, linux-ide,
	Mathieu Bérard, Ingo Molnar, jgarzik

This email lists some known regressions in Linus' tree compared to 2.6.20
with patches available.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : hung bootup in various drivers
References : http://lkml.org/lkml/2007/3/30/68
Submitter  : Ingo Molnar <mingo@elte.hu>
Handled-By : Kay Sievers <kay.sievers@vrfy.org>
Patch      : http://lkml.org/lkml/2007/3/30/323
Status     : patch available


Subject    : NCQ problem with ahci and Hitachi drive
References : http://lkml.org/lkml/2007/3/4/178
             http://lkml.org/lkml/2007/3/9/475
             http://lkml.org/lkml/2007/2/22/8
Submitter  : Mathieu Bérard <Mathieu.Berard@crans.org>
Handled-By : Tejun Heo <htejun@gmail.com>
             Robert Hancock <hancockr@shaw.ca>
Patch      : http://lkml.org/lkml/2007/2/22/8
Status     : possible patch available


Subject    : suspend to disk hangs  (microcode driver)
References : http://lkml.org/lkml/2007/3/16/126
Submitter  : Maxim Levitsky <maximlevitsky@gmail.com>
Caused-By  : Rafael J. Wysocki <rjw@sisk.pl>
             commit e3c7db621bed4afb8e231cb005057f2feb5db557
             commit ed746e3b18f4df18afa3763155972c5835f284c5
             commit 259130526c267550bc365d3015917d90667732f1
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Patch      : http://lkml.org/lkml/2007/3/25/71
Status     : patch available

^ permalink raw reply	[flat|nested] 128+ messages in thread

* 2.6.21-rc5: known regressions with patches (v2)
@ 2007-03-31 18:19   ` Adrian Bunk
  0 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-31 18:19 UTC (permalink / raw)
  To: Linus Torvalds, Andrew Morton
  Cc: Linux Kernel Mailing List, Ingo Molnar, Kay Sievers, Greg KH,
	Mathieu Bérard, Tejun Heo, Robert Hancock, jgarzik,
	linux-ide, Maxim Levitsky, Rafael J. Wysocki, pavel, linux-pm,
	tigran

This email lists some known regressions in Linus' tree compared to 2.6.20
with patches available.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : hung bootup in various drivers
References : http://lkml.org/lkml/2007/3/30/68
Submitter  : Ingo Molnar <mingo@elte.hu>
Handled-By : Kay Sievers <kay.sievers@vrfy.org>
Patch      : http://lkml.org/lkml/2007/3/30/323
Status     : patch available


Subject    : NCQ problem with ahci and Hitachi drive
References : http://lkml.org/lkml/2007/3/4/178
             http://lkml.org/lkml/2007/3/9/475
             http://lkml.org/lkml/2007/2/22/8
Submitter  : Mathieu Bérard <Mathieu.Berard@crans.org>
Handled-By : Tejun Heo <htejun@gmail.com>
             Robert Hancock <hancockr@shaw.ca>
Patch      : http://lkml.org/lkml/2007/2/22/8
Status     : possible patch available


Subject    : suspend to disk hangs  (microcode driver)
References : http://lkml.org/lkml/2007/3/16/126
Submitter  : Maxim Levitsky <maximlevitsky@gmail.com>
Caused-By  : Rafael J. Wysocki <rjw@sisk.pl>
             commit e3c7db621bed4afb8e231cb005057f2feb5db557
             commit ed746e3b18f4df18afa3763155972c5835f284c5
             commit 259130526c267550bc365d3015917d90667732f1
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Patch      : http://lkml.org/lkml/2007/3/25/71
Status     : patch available


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [3/4] 2.6.21-rc5: known regressions (v2)
  2007-03-30 21:32   ` Adrian Bunk
@ 2007-04-01  5:39     ` Jeremy Fitzhardinge
  -1 siblings, 0 replies; 128+ messages in thread
From: Jeremy Fitzhardinge @ 2007-04-01  5:39 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
	Dave Jones, Eric W. Biederman, Rafael J. Wysocki, pavel,
	linux-pm, gregkh, Thomas Gleixner

Adrian Bunk wrote:
> Subject    : ThinkPad X60: resume no longer works  (PCI related?)
> References : http://lkml.org/lkml/2007/3/13/3
> Submitter  : Dave Jones <davej@redhat.com>
>              Jeremy Fitzhardinge <jeremy@goop.org>
> Caused-By  : PCI merge
>              commit 78149df6d565c36675463352d0bfe0000b02b7a7
> Handled-By : Eric W. Biederman <ebiederm@xmission.com>
>              Rafael J. Wysocki <rjw@sisk.pl>
> Status     : problem is being debugged
>   

I know this is currently a subject of discussion on lkml, but I wanted
to confirm that booting with "hpet=disable" fixes this, and resume works
for me.  It ends up using acpi_pm as the clocksource.

    J

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [3/4] 2.6.21-rc5: known regressions (v2)
@ 2007-04-01  5:39     ` Jeremy Fitzhardinge
  0 siblings, 0 replies; 128+ messages in thread
From: Jeremy Fitzhardinge @ 2007-04-01  5:39 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: linux-pm, Thomas Gleixner, Eric W. Biederman, Andrew Morton,
	gregkh, Linus Torvalds, Linux Kernel Mailing List

Adrian Bunk wrote:
> Subject    : ThinkPad X60: resume no longer works  (PCI related?)
> References : http://lkml.org/lkml/2007/3/13/3
> Submitter  : Dave Jones <davej@redhat.com>
>              Jeremy Fitzhardinge <jeremy@goop.org>
> Caused-By  : PCI merge
>              commit 78149df6d565c36675463352d0bfe0000b02b7a7
> Handled-By : Eric W. Biederman <ebiederm@xmission.com>
>              Rafael J. Wysocki <rjw@sisk.pl>
> Status     : problem is being debugged
>   

I know this is currently a subject of discussion on lkml, but I wanted
to confirm that booting with "hpet=disable" fixes this, and resume works
for me.  It ends up using acpi_pm as the clocksource.

    J

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [4/4] 2.6.21-rc5: known regressions (v2)
  2007-03-30 21:49   ` Adrian Bunk
@ 2007-04-01  7:04     ` Michael S. Tsirkin
  -1 siblings, 0 replies; 128+ messages in thread
From: Michael S. Tsirkin @ 2007-04-01  7:04 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
	Fr??d??ric Riss, Tino Keitel, Thomas Gleixner, pavel, linux-pm,
	Soeren Sonnenburg, Ingo Molnar, Tejun Heo, Rafael J. Wysocki,
	Jeff Chua, Maxim Levitsky

> Subject    : after resume: X hangs after drawing a couple of windows
>              workaround: clocksource=acpi_pm
> References : http://lkml.org/lkml/2007/3/8/117
>              http://lkml.org/lkml/2007/3/25/20
>              http://lkml.org/lkml/2007/3/26/151
> Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
> Handled-By : Thomas Gleixner <tglx@linutronix.de>
> Status     : problem is being debugged

Adrian,
the bug was found by Maxim Levitsky and
the following patch appears to have fixed the problem:
http://lkml.org/lkml/2007/3/28/104

the right way to fix it is still being discussed:
http://lkml.org/lkml/2007/3/28/182


-- 
MST

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [4/4] 2.6.21-rc5: known regressions (v2)
@ 2007-04-01  7:04     ` Michael S. Tsirkin
  0 siblings, 0 replies; 128+ messages in thread
From: Michael S. Tsirkin @ 2007-04-01  7:04 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Soeren Sonnenburg, Tejun Heo, Fr??d??ric Riss, Jeff Chua,
	Tino Keitel, linux-pm, Linux Kernel Mailing List, Andrew Morton,
	Thomas Gleixner, Linus Torvalds, Ingo Molnar, Maxim Levitsky

> Subject    : after resume: X hangs after drawing a couple of windows
>              workaround: clocksource=acpi_pm
> References : http://lkml.org/lkml/2007/3/8/117
>              http://lkml.org/lkml/2007/3/25/20
>              http://lkml.org/lkml/2007/3/26/151
> Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
> Handled-By : Thomas Gleixner <tglx@linutronix.de>
> Status     : problem is being debugged

Adrian,
the bug was found by Maxim Levitsky and
the following patch appears to have fixed the problem:
http://lkml.org/lkml/2007/3/28/104

the right way to fix it is still being discussed:
http://lkml.org/lkml/2007/3/28/182


-- 
MST

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"
  2007-03-30 12:04   ` [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions" Ingo Molnar
  2007-03-30 12:06     ` [bug] fixed_init(): BUG: at drivers/base/core.c:120 device_release(), " Ingo Molnar
  2007-03-30 14:16     ` [bug] hung bootup in various drivers, " Greg KH
@ 2007-04-01  7:49     ` Pavel Machek
  2007-04-01 17:17       ` Linus Torvalds
  2 siblings, 1 reply; 128+ messages in thread
From: Pavel Machek @ 2007-04-01  7:49 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel,
	Greg Kroah-Hartman

Hi!

> @@ -183,7 +183,8 @@ int driver_register(struct device_driver
>  void driver_unregister(struct device_driver * drv)
>  {
>  	bus_remove_driver(drv);
> -	wait_for_completion(&drv->unloaded);
> +	if (!drv->unloaded.done)
> +		WARN_ON(1);
>  }

WARN_ON(!done)?

							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"
  2007-04-01  7:49     ` Pavel Machek
@ 2007-04-01 17:17       ` Linus Torvalds
  2007-04-01 17:35         ` [patch] driver core: if built-in, do not wait in driver_unregister() Ingo Molnar
  0 siblings, 1 reply; 128+ messages in thread
From: Linus Torvalds @ 2007-04-01 17:17 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Ingo Molnar, Adrian Bunk, Andrew Morton, linux-kernel,
	Greg Kroah-Hartman



On Sun, 1 Apr 2007, Pavel Machek wrote:
> 
> > @@ -183,7 +183,8 @@ int driver_register(struct device_driver
> >  void driver_unregister(struct device_driver * drv)
> >  {
> >  	bus_remove_driver(drv);
> > -	wait_for_completion(&drv->unloaded);
> > +	if (!drv->unloaded.done)
> > +		WARN_ON(1);
> >  }
> 
> WARN_ON(!done)?

I think the whole "wait_for_completion()" is just broken. 

We asked to *unregister* the driver, not to wait for users.

I would suggest that for 2.6.21, the minimal fix is actually something 
like the appended. Comments? Ingo, does this fix things for you?

In general, I think the whole "wait for locks" or "wait for users" is 
almost always a sign of a much bigger bug in reference counting. Modules 
are special, though, since module code/data doesn't really get reference 
counted. But doing it for built-in stuff when you don't need to really 
just sounds *wrong*.

		Linus

---
 drivers/base/driver.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/drivers/base/driver.c b/drivers/base/driver.c
index 1214cbd..082bfde 100644
--- a/drivers/base/driver.c
+++ b/drivers/base/driver.c
@@ -183,7 +183,14 @@ int driver_register(struct device_driver * drv)
 void driver_unregister(struct device_driver * drv)
 {
 	bus_remove_driver(drv);
-	wait_for_completion(&drv->unloaded);
+	/*
+	 * If the driver is a module, we are probably in
+	 * the module unload path, and we want to wait
+	 * for everything to unload before we can actually
+	 * finish the unload.
+	 */
+	if (drv->owner)
+		wait_for_completion(&drv->unloaded);
 }
 
 /**

^ permalink raw reply related	[flat|nested] 128+ messages in thread

* [patch] driver core: if built-in, do not wait in driver_unregister()
  2007-04-01 17:17       ` Linus Torvalds
@ 2007-04-01 17:35         ` Ingo Molnar
  2007-04-02  1:47           ` Greg KH
  0 siblings, 1 reply; 128+ messages in thread
From: Ingo Molnar @ 2007-04-01 17:35 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Pavel Machek, Adrian Bunk, Andrew Morton, linux-kernel,
	Greg Kroah-Hartman


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> I would suggest that for 2.6.21, the minimal fix is actually something 
> like the appended. Comments? Ingo, does this fix things for you?

yeah - it does the trick: i just booted the .config in question and your 
patch works fine and the bootup does not hang in slgt_init() anymore:

 Calling initcall 0xc1e78d86: slgt_init+0x0/0x1ee()
 SyncLink GT $Revision: 4.36 $
 SyncLink GT no devices found
 initcall 0xc1e78d86: slgt_init+0x0/0x1ee() returned -19
 Calling initcall 0xc1e78f74: n_hdlc_init+0x0/0x9c()
 HDLC line discipline: version $Revision: 4.8 $, maxframe=4096
 N_HDLC line discipline registered.
 initcall 0xc1e78f74: n_hdlc_init+0x0/0x9c() returned 0

thanks! Find below the full patch with metadata filled in (no other 
changes).

	Ingo

------------------------->
Subject: [patch] driver core: if built-in, do not wait in driver_unregister()
From: Linus Torvalds <torvalds@linux-foundation.org>

built-in drivers suffered bootup hangs with certain driver unregistry
sequences, due to sysfs breakage.

do the minimal fix for v2.6.21: only wait if the driver is a module.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 drivers/base/driver.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

Index: linux/drivers/base/driver.c
===================================================================
--- linux.orig/drivers/base/driver.c
+++ linux/drivers/base/driver.c
@@ -183,7 +183,14 @@ int driver_register(struct device_driver
 void driver_unregister(struct device_driver * drv)
 {
 	bus_remove_driver(drv);
-	wait_for_completion(&drv->unloaded);
+	/*
+	 * If the driver is a module, we are probably in
+	 * the module unload path, and we want to wait
+	 * for everything to unload before we can actually
+	 * finish the unload.
+	 */
+	if (drv->owner)
+		wait_for_completion(&drv->unloaded);
 }
 
 /**

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [4/4] 2.6.21-rc5: known regressions (v2)
  2007-03-30 21:49   ` Adrian Bunk
@ 2007-04-01 20:37     ` Michael S. Tsirkin
  -1 siblings, 0 replies; 128+ messages in thread
From: Michael S. Tsirkin @ 2007-04-01 20:37 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
	Fr??d??ric Riss, Tino Keitel, Thomas Gleixner, pavel, linux-pm,
	Soeren Sonnenburg, Ingo Molnar, Tejun Heo, Rafael J. Wysocki,
	Jeff Chua, maximlevitsky

> Subject    : after resume: X hangs after drawing a couple of windows
>              workaround: clocksource=acpi_pm
> References : http://lkml.org/lkml/2007/3/8/117
>              http://lkml.org/lkml/2007/3/25/20
>              http://lkml.org/lkml/2007/3/26/151
> Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
> Handled-By : Thomas Gleixner <tglx@linutronix.de>
> Status     : problem is being debugged

Seems to be resolved with 399afa4fc9238fbae42116cf25a54671c0e8f56e.
Thanks Maxim!


-- 
MST

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [4/4] 2.6.21-rc5: known regressions (v2)
@ 2007-04-01 20:37     ` Michael S. Tsirkin
  0 siblings, 0 replies; 128+ messages in thread
From: Michael S. Tsirkin @ 2007-04-01 20:37 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Soeren Sonnenburg, Tejun Heo, Fr??d??ric Riss, Jeff Chua,
	Tino Keitel, linux-pm, Linux Kernel Mailing List, Andrew Morton,
	Thomas Gleixner, Linus Torvalds, Ingo Molnar, maximlevitsky

> Subject    : after resume: X hangs after drawing a couple of windows
>              workaround: clocksource=acpi_pm
> References : http://lkml.org/lkml/2007/3/8/117
>              http://lkml.org/lkml/2007/3/25/20
>              http://lkml.org/lkml/2007/3/26/151
> Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
> Handled-By : Thomas Gleixner <tglx@linutronix.de>
> Status     : problem is being debugged

Seems to be resolved with 399afa4fc9238fbae42116cf25a54671c0e8f56e.
Thanks Maxim!


-- 
MST

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [patch] driver core: if built-in, do not wait in driver_unregister()
  2007-04-01 17:35         ` [patch] driver core: if built-in, do not wait in driver_unregister() Ingo Molnar
@ 2007-04-02  1:47           ` Greg KH
  0 siblings, 0 replies; 128+ messages in thread
From: Greg KH @ 2007-04-02  1:47 UTC (permalink / raw)
  To: Ingo Molnar, Kay Sievers
  Cc: Linus Torvalds, Pavel Machek, Adrian Bunk, Andrew Morton, linux-kernel

On Sun, Apr 01, 2007 at 07:35:08PM +0200, Ingo Molnar wrote:
> 
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > I would suggest that for 2.6.21, the minimal fix is actually something 
> > like the appended. Comments? Ingo, does this fix things for you?
> 
> yeah - it does the trick: i just booted the .config in question and your 
> patch works fine and the bootup does not hang in slgt_init() anymore:
> 
>  Calling initcall 0xc1e78d86: slgt_init+0x0/0x1ee()
>  SyncLink GT $Revision: 4.36 $
>  SyncLink GT no devices found
>  initcall 0xc1e78d86: slgt_init+0x0/0x1ee() returned -19
>  Calling initcall 0xc1e78f74: n_hdlc_init+0x0/0x9c()
>  HDLC line discipline: version $Revision: 4.8 $, maxframe=4096
>  N_HDLC line discipline registered.
>  initcall 0xc1e78f74: n_hdlc_init+0x0/0x9c() returned 0
> 
> thanks! Find below the full patch with metadata filled in (no other 
> changes).

No, I think this will catch the "hang" but look in sysfs in
/sys/modules/ for the module directory for the module that "failed" to
be loaded.  I think you will see some dangling files there that are
incorrect, and might oops if you cat from them (don't remember).

Kay's patch is correct and fixes the reference count issue properly,
this one just papers over it by ignoring the fact that the driver is
never released and cleaned up in memory.

(patch included below so Kay can verify this...)

thanks,

greg k-h

> ------------------------->
> Subject: [patch] driver core: if built-in, do not wait in driver_unregister()
> From: Linus Torvalds <torvalds@linux-foundation.org>
> 
> built-in drivers suffered bootup hangs with certain driver unregistry
> sequences, due to sysfs breakage.
> 
> do the minimal fix for v2.6.21: only wait if the driver is a module.
> 
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
>  drivers/base/driver.c |    9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> Index: linux/drivers/base/driver.c
> ===================================================================
> --- linux.orig/drivers/base/driver.c
> +++ linux/drivers/base/driver.c
> @@ -183,7 +183,14 @@ int driver_register(struct device_driver
>  void driver_unregister(struct device_driver * drv)
>  {
>  	bus_remove_driver(drv);
> -	wait_for_completion(&drv->unloaded);
> +	/*
> +	 * If the driver is a module, we are probably in
> +	 * the module unload path, and we want to wait
> +	 * for everything to unload before we can actually
> +	 * finish the unload.
> +	 */
> +	if (drv->owner)
> +		wait_for_completion(&drv->unloaded);
>  }
>  
>  /**

^ permalink raw reply	[flat|nested] 128+ messages in thread

* [patch] forcedeth: improve NAPI logic
  2007-03-26  8:58     ` [patch] forcedeth: work around NULL skb dereference crash Ingo Molnar
@ 2007-04-02 11:56       ` Ingo Molnar
  0 siblings, 0 replies; 128+ messages in thread
From: Ingo Molnar @ 2007-04-02 11:56 UTC (permalink / raw)
  To: Ayaz Abdulla; +Cc: Linux Kernel Mailing List, Ayaz Abdulla, Andrew Morton

From: Ingo Molnar <mingo@elte.hu>
Subject: [patch] forcedeth.c: improve NAPI handler

another forcedeth.c thing: i noticed that its NAPI handler does not do 
tx-ring processing. The patch below implements this - tested on 
DESC_VER_2 hardware, with CONFIG_FORCEDETH_NAPI=y.

Signed-off-by: Ingo Molnar <mingo@elte.hu>

Index: linux/drivers/net/forcedeth.c
===================================================================
--- linux.orig/drivers/net/forcedeth.c
+++ linux/drivers/net/forcedeth.c
@@ -3118,9 +3118,17 @@ static int nv_napi_poll(struct net_devic
 	int retcode;
 
 	if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) {
+		spin_lock_irqsave(&np->lock, flags);
+		nv_tx_done(dev);
+		spin_unlock_irqrestore(&np->lock, flags);
+
 		pkts = nv_rx_process(dev, limit);
 		retcode = nv_alloc_rx(dev);
 	} else {
+		spin_lock_irqsave(&np->lock, flags);
+		nv_tx_done_optimized(dev, np->tx_ring_size);
+		spin_unlock_irqrestore(&np->lock, flags);
+
 		pkts = nv_rx_process_optimized(dev, limit);
 		retcode = nv_alloc_rx_optimized(dev);
 	}

^ permalink raw reply	[flat|nested] 128+ messages in thread

* [PATCH] libata: add NCQ blacklist entries from Silicon Image Windows driver (v2)
  2007-03-31 18:19   ` Adrian Bunk
  (?)
@ 2007-04-03  4:05   ` Robert Hancock
  2007-04-03  4:13     ` Tejun Heo
  2007-04-04  6:09     ` Jeff Garzik
  -1 siblings, 2 replies; 128+ messages in thread
From: Robert Hancock @ 2007-04-03  4:05 UTC (permalink / raw)
  To: Linux Kernel Mailing List, linux-ide
  Cc: Adrian Bunk, Linus Torvalds, Andrew Morton, jgarzik

This adds some NCQ blacklist entries taken from the Silicon Image 3124/3132
Windows driver .inf files. There are some confirming reports of problems
with these drives under Linux (for example http://lkml.org/lkml/2007/3/4/178)
so let's disable NCQ on these drives.

Signed-off-by: Robert Hancock <hancockr@shaw.ca>

--- linux-2.6.21-rc5-git9/drivers/ata/libata-core.c	2007-04-02 21:03:29.000000000 -0600
+++ linux-2.6.21-rc5-git9edit/drivers/ata/libata-core.c	2007-04-02 21:26:23.000000000 -0600
@@ -3363,6 +3363,11 @@ static const struct ata_blacklist_entry 
 	{ "Maxtor 6L250S0",     "BANC1G10",     ATA_HORKAGE_NONCQ },
 	/* NCQ hard hangs device under heavier load, needs hard power cycle */
 	{ "Maxtor 6B250S0",	"BANC1B70",	ATA_HORKAGE_NONCQ },
+	/* Blacklist entries taken from Silicon Image 3124/3132
+	   Windows driver .inf file - also several Linux problem reports */
+	{ "HTS541060G9SA00",    "MB3OC60D",     ATA_HORKAGE_NONCQ, },
+	{ "HTS541080G9SA00",    "MB4OC60D",     ATA_HORKAGE_NONCQ, },
+	{ "HTS541010G9SA00",    "MBZOC60D",     ATA_HORKAGE_NONCQ, },
 
 	/* Devices with NCQ limits */
 


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [PATCH] libata: add NCQ blacklist entries from Silicon Image Windows driver (v2)
  2007-04-03  4:05   ` [PATCH] libata: add NCQ blacklist entries from Silicon Image Windows driver (v2) Robert Hancock
@ 2007-04-03  4:13     ` Tejun Heo
  2007-04-04  6:09     ` Jeff Garzik
  1 sibling, 0 replies; 128+ messages in thread
From: Tejun Heo @ 2007-04-03  4:13 UTC (permalink / raw)
  To: Robert Hancock
  Cc: Linux Kernel Mailing List, linux-ide, Adrian Bunk,
	Linus Torvalds, Andrew Morton, jgarzik

Robert Hancock wrote:
> This adds some NCQ blacklist entries taken from the Silicon Image 3124/3132
> Windows driver .inf files. There are some confirming reports of problems
> with these drives under Linux (for example
> http://lkml.org/lkml/2007/3/4/178)
> so let's disable NCQ on these drives.
> 
> Signed-off-by: Robert Hancock <hancockr@shaw.ca>

Acked-by: Tejun Heo <htejun@gmail.com>

-- 
tejun

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [PATCH] libata: add NCQ blacklist entries from Silicon Image Windows driver (v2)
  2007-04-03  4:05   ` [PATCH] libata: add NCQ blacklist entries from Silicon Image Windows driver (v2) Robert Hancock
  2007-04-03  4:13     ` Tejun Heo
@ 2007-04-04  6:09     ` Jeff Garzik
  2007-04-04 14:26       ` Robert Hancock
  1 sibling, 1 reply; 128+ messages in thread
From: Jeff Garzik @ 2007-04-04  6:09 UTC (permalink / raw)
  To: Robert Hancock
  Cc: Linux Kernel Mailing List, linux-ide, Adrian Bunk,
	Linus Torvalds, Andrew Morton

Robert Hancock wrote:
> This adds some NCQ blacklist entries taken from the Silicon Image 3124/3132
> Windows driver .inf files. There are some confirming reports of problems
> with these drives under Linux (for example 
> http://lkml.org/lkml/2007/3/4/178)
> so let's disable NCQ on these drives.
> 
> Signed-off-by: Robert Hancock <hancockr@shaw.ca>
> 
> --- linux-2.6.21-rc5-git9/drivers/ata/libata-core.c    2007-04-02 
> 21:03:29.000000000 -0600
> +++ linux-2.6.21-rc5-git9edit/drivers/ata/libata-core.c    2007-04-02 
> 21:26:23.000000000 -0600
> @@ -3363,6 +3363,11 @@ static const struct ata_blacklist_entry     { 
> "Maxtor 6L250S0",     "BANC1G10",     ATA_HORKAGE_NONCQ },
>     /* NCQ hard hangs device under heavier load, needs hard power cycle */
>     { "Maxtor 6B250S0",    "BANC1B70",    ATA_HORKAGE_NONCQ },
> +    /* Blacklist entries taken from Silicon Image 3124/3132
> +       Windows driver .inf file - also several Linux problem reports */
> +    { "HTS541060G9SA00",    "MB3OC60D",     ATA_HORKAGE_NONCQ, },
> +    { "HTS541080G9SA00",    "MB4OC60D",     ATA_HORKAGE_NONCQ, },
> +    { "HTS541010G9SA00",    "MBZOC60D",     ATA_HORKAGE_NONCQ, },

The thread you link to seems like an irq problem, especially because it 
worked in 2.6.20 and prior?

	Jeff




^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [PATCH] libata: add NCQ blacklist entries from Silicon Image Windows driver (v2)
  2007-04-04  6:09     ` Jeff Garzik
@ 2007-04-04 14:26       ` Robert Hancock
  0 siblings, 0 replies; 128+ messages in thread
From: Robert Hancock @ 2007-04-04 14:26 UTC (permalink / raw)
  To: Jeff Garzik
  Cc: Linux Kernel Mailing List, linux-ide, Adrian Bunk,
	Linus Torvalds, Andrew Morton

Jeff Garzik wrote:
> Robert Hancock wrote:
>> This adds some NCQ blacklist entries taken from the Silicon Image 
>> 3124/3132
>> Windows driver .inf files. There are some confirming reports of problems
>> with these drives under Linux (for example 
>> http://lkml.org/lkml/2007/3/4/178)
>> so let's disable NCQ on these drives.
>>
>> Signed-off-by: Robert Hancock <hancockr@shaw.ca>
>>
>> --- linux-2.6.21-rc5-git9/drivers/ata/libata-core.c    2007-04-02 
>> 21:03:29.000000000 -0600
>> +++ linux-2.6.21-rc5-git9edit/drivers/ata/libata-core.c    2007-04-02 
>> 21:26:23.000000000 -0600
>> @@ -3363,6 +3363,11 @@ static const struct ata_blacklist_entry     { 
>> "Maxtor 6L250S0",     "BANC1G10",     ATA_HORKAGE_NONCQ },
>>     /* NCQ hard hangs device under heavier load, needs hard power 
>> cycle */
>>     { "Maxtor 6B250S0",    "BANC1B70",    ATA_HORKAGE_NONCQ },
>> +    /* Blacklist entries taken from Silicon Image 3124/3132
>> +       Windows driver .inf file - also several Linux problem reports */
>> +    { "HTS541060G9SA00",    "MB3OC60D",     ATA_HORKAGE_NONCQ, },
>> +    { "HTS541080G9SA00",    "MB4OC60D",     ATA_HORKAGE_NONCQ, },
>> +    { "HTS541010G9SA00",    "MBZOC60D",     ATA_HORKAGE_NONCQ, },
> 
> The thread you link to seems like an irq problem, especially because it 
> worked in 2.6.20 and prior?
> 
>     Jeff

According to this post:

http://lkml.org/lkml/2007/3/9/475

with 2.6.21-rc3, it started working after the kernel disabled NCQ 
because of too many errors. That seems to point away from it being an 
IRQ problem, as you'd expect it to not work at all. I don't expect the 
interrupts would be handled any differently between NCQ and non-NCQ 
commands. However, apparently disabling ACPI also prevents the problem, 
which does seem a bit odd.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/


^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [3/4] 2.6.21-rc5: known regressions (v2)
  2007-03-30 21:32   ` Adrian Bunk
@ 2007-04-13 16:32     ` Michal Piotrowski
  -1 siblings, 0 replies; 128+ messages in thread
From: Michal Piotrowski @ 2007-04-13 16:32 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
	Rafael J. Wysocki, pavel, linux-pm, Stephen Hemminger, netdev

On 30/03/07, Adrian Bunk <bunk@stusta.de> wrote:
> Subject    : suspend to disk hangs  (skge)
> References : http://lkml.org/lkml/2007/3/27/212
> Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
> Caused-By  : Stephen Hemminger <shemminger@linux-foundation.org>
>              commit a504e64ab42bcc27074ea37405d06833ed6e0820
> Status     : unknown

This problem is fixed in 2.6.21-rc6-git5 (commit
692412b31ffb5df00197ea591dd635fc07506c02).

Huge thanks to Stephen.

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)

^ permalink raw reply	[flat|nested] 128+ messages in thread

* Re: [3/4] 2.6.21-rc5: known regressions (v2)
@ 2007-04-13 16:32     ` Michal Piotrowski
  0 siblings, 0 replies; 128+ messages in thread
From: Michal Piotrowski @ 2007-04-13 16:32 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Stephen Hemminger, netdev, Linus Torvalds, Andrew Morton,
	linux-pm, Linux Kernel Mailing List

On 30/03/07, Adrian Bunk <bunk@stusta.de> wrote:
> Subject    : suspend to disk hangs  (skge)
> References : http://lkml.org/lkml/2007/3/27/212
> Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
> Caused-By  : Stephen Hemminger <shemminger@linux-foundation.org>
>              commit a504e64ab42bcc27074ea37405d06833ed6e0820
> Status     : unknown

This problem is fixed in 2.6.21-rc6-git5 (commit
692412b31ffb5df00197ea591dd635fc07506c02).

Huge thanks to Stephen.

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)

^ permalink raw reply	[flat|nested] 128+ messages in thread

end of thread, other threads:[~2007-04-13 16:32 UTC | newest]

Thread overview: 128+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
2007-03-26  8:31 ` Ingo Molnar
2007-03-26  8:17   ` Ayaz Abdulla
2007-03-26  8:39   ` Ingo Molnar
2007-03-26  8:58     ` [patch] forcedeth: work around NULL skb dereference crash Ingo Molnar
2007-04-02 11:56       ` [patch] forcedeth: improve NAPI logic Ingo Molnar
2007-03-26  8:55 ` Linux 2.6.21-rc5 Thomas Gleixner
2007-03-26 12:25   ` Bob Tracy
2007-03-26 12:30     ` Thomas Gleixner
2007-03-26  9:04 ` 2.6.21-rc5: maxcpus=1 crash in cpufreq: kernel BUG at drivers/cpufreq/cpufreq.c:82! Ingo Molnar
2007-03-26 18:12   ` Venki Pallipadi
2007-03-26 19:03     ` Venki Pallipadi
2007-03-27  7:11       ` Ingo Molnar
2007-03-26  9:21 ` [PATCH] clockevents: remove bad designed sysfs support for now Thomas Gleixner
2007-03-26  9:25   ` Ingo Molnar
2007-03-26 18:57     ` Greg KH
2007-03-26 12:51   ` Pavel Machek
2007-03-27  7:08   ` [PATCH] i386: Fix bogus return value in hpet_next_event() Thomas Gleixner
2007-03-26 10:11 ` -rc5: e1000 resume weirdness Ingo Molnar
2007-03-26 15:39   ` Kok, Auke
2007-03-26 15:50   ` Jesse Brandeburg
2007-03-26 15:55     ` Kok, Auke
2007-03-26 17:39     ` Ingo Molnar
2007-03-27  1:59 ` [1/5] 2.6.21-rc5: known regressions Adrian Bunk
2007-03-28 18:54   ` Kok, Auke
2007-03-28 19:23     ` Ingo Molnar
2007-03-30 18:04     ` Adrian Bunk
2007-03-30 12:04   ` [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions" Ingo Molnar
2007-03-30 12:06     ` [bug] fixed_init(): BUG: at drivers/base/core.c:120 device_release(), " Ingo Molnar
2007-03-30 14:18       ` Greg KH
2007-03-30 14:25         ` Ingo Molnar
2007-03-30 16:31           ` Vitaly Bordug
2007-03-30 14:16     ` [bug] hung bootup in various drivers, " Greg KH
2007-03-30 17:46       ` Ingo Molnar
2007-03-30 19:32         ` Greg KH
2007-03-31  2:32           ` Kay Sievers
2007-03-31 16:51             ` [patch] driver core: fix built-in drivers sysfs links Ingo Molnar
2007-03-31 16:31           ` [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions" Ingo Molnar
2007-04-01  7:49     ` Pavel Machek
2007-04-01 17:17       ` Linus Torvalds
2007-04-01 17:35         ` [patch] driver core: if built-in, do not wait in driver_unregister() Ingo Molnar
2007-04-02  1:47           ` Greg KH
2007-03-27  1:59 ` [2/5] 2.6.21-rc5: known regressions Adrian Bunk
2007-03-27  1:59   ` Adrian Bunk
2007-03-27  1:59   ` Adrian Bunk
2007-03-28 19:46   ` Laurent Riffard
2007-03-29 19:02     ` Fabio Comolli
2007-03-27  1:59 ` [3/5] " Adrian Bunk
2007-03-27  1:59 ` [4/5] " Adrian Bunk
2007-03-27  1:59   ` Adrian Bunk
2007-03-27  8:00   ` Marcus Better
2007-03-27 13:25     ` Eric W. Biederman
2007-03-27 16:53       ` Marcus Better
2007-03-27 20:50         ` Eric W. Biederman
2007-03-27 10:09   ` Rafael J. Wysocki
2007-03-27 10:09     ` Rafael J. Wysocki
2007-03-27 22:29     ` Adrian Bunk
2007-03-27 22:29       ` Adrian Bunk
2007-03-27 22:45       ` Thomas Meyer
2007-03-27 22:45         ` Thomas Meyer
2007-03-28 12:19   ` Ingo Molnar
2007-03-28 12:41     ` Ingo Molnar
2007-03-28 13:03       ` Ingo Molnar
2007-03-28 13:06         ` [patch] MSI-X: fix resume crash Ingo Molnar
2007-03-28 13:31           ` Eric W. Biederman
2007-03-28 13:36             ` Ingo Molnar
2007-03-29  4:30           ` Len Brown
2007-03-29  4:57             ` Eric W. Biederman
2007-03-27  1:59 ` [5/5] 2.6.21-rc5: known regressions Adrian Bunk
2007-03-27  1:59   ` Adrian Bunk
2007-03-27  5:51 ` ATA ACPI (was Re: Linux 2.6.21-rc5) Jeff Garzik
2007-03-27  5:54   ` Tejun Heo
2007-03-27 21:32     ` Pavel Machek
2007-03-28  9:51       ` Tejun Heo
2007-03-27 17:07   ` Linus Torvalds
2007-03-27 18:48     ` Jeff Garzik
2007-03-27  6:17 ` Linux 2.6.21-rc5 Andrew Morton
2007-03-27  6:20   ` Greg KH
2007-03-27 16:49     ` Jesse Barnes
2007-03-27  9:49   ` Takashi Iwai
2007-03-27 12:25   ` Andi Kleen
2007-03-27 16:33     ` Andrew Morton
2007-03-27 12:43   ` Dmitry Torokhov
2007-03-28 22:32   ` Tilman Schmidt
2007-03-27 18:34 ` Michal Piotrowski
2007-03-27 22:29   ` Pavel Machek
2007-03-27 22:55     ` Michal Piotrowski
2007-03-27 18:53 ` Michal Piotrowski
2007-03-28 14:30   ` Andi Kleen
2007-03-28 14:56     ` Michal Piotrowski
2007-03-28 16:12       ` Jiri Kosina
2007-03-28 16:51         ` Michal Piotrowski
2007-03-28 17:56     ` Linus Torvalds
     [not found] ` <20070327230024.GJ16477@stusta.de>
2007-03-27 23:10   ` 2.6.21-rc5: known regressions with patches Rafael J. Wysocki
2007-03-28  0:50   ` Jay Cliburn
2007-03-30 21:32 ` [1/4] 2.6.21-rc5: known regressions (v2) Adrian Bunk
2007-03-30 21:32   ` Adrian Bunk
2007-03-30 21:38   ` Greg KH
2007-03-31  0:23   ` Michal Jaegermann
2007-03-31 15:01     ` Adrian Bunk
2007-03-31 16:42       ` Michal Jaegermann
2007-03-30 21:32 ` [2/4] " Adrian Bunk
2007-03-30 21:32 ` [3/4] " Adrian Bunk
2007-03-30 21:32   ` Adrian Bunk
2007-03-31  2:52   ` Jeff Chua
2007-03-31  2:52     ` Jeff Chua
2007-03-31  2:52     ` Jeff Chua
2007-03-31  3:16     ` Adrian Bunk
2007-03-31 11:08       ` Jens Axboe
2007-04-01  5:39   ` Jeremy Fitzhardinge
2007-04-01  5:39     ` Jeremy Fitzhardinge
2007-04-13 16:32   ` Michal Piotrowski
2007-04-13 16:32     ` Michal Piotrowski
2007-03-30 21:49 ` [4/4] " Adrian Bunk
2007-03-30 21:49   ` Adrian Bunk
2007-03-31  2:41   ` Jeff Chua
2007-03-31  2:41     ` Jeff Chua
2007-03-31  6:44   ` Frédéric Riss
2007-04-01  7:04   ` Michael S. Tsirkin
2007-04-01  7:04     ` Michael S. Tsirkin
2007-04-01 20:37   ` Michael S. Tsirkin
2007-04-01 20:37     ` Michael S. Tsirkin
2007-03-31 18:19 ` 2.6.21-rc5: known regressions with patches (v2) Adrian Bunk
2007-03-31 18:19   ` Adrian Bunk
2007-04-03  4:05   ` [PATCH] libata: add NCQ blacklist entries from Silicon Image Windows driver (v2) Robert Hancock
2007-04-03  4:13     ` Tejun Heo
2007-04-04  6:09     ` Jeff Garzik
2007-04-04 14:26       ` Robert Hancock

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.