Linux 2.6.21-rc4

Linux 2.6.21-rc4

[Linus Torvalds]

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


I pushed out the -git trees yesterday, but then got distracted, so the 
patches and tar-balls and the announcement got delayed until this morning. 
Oops. I'm a scatter-brain.

Anyway, the good news about -rc4 is that there's just lots of random 
fixes. I'm hoping that we've seriously cut down on the regression list, 
and I'd ask everybody who is on Adrian's list to please re-verify their 
regression, and in case it's one of the "patches available" ones but I 
haven't merged (maybe because it hasn't been sent to me!), make sure I do.

Shortlog appended. Nothing really stands out. 

		Linus
---
Adrian Bunk (2):
      [DLM] fs/dlm/user.c should #include "user.h"
      asus-laptop: make code static

Adrian Hunter (2):
      [MTD] Correct partition failed erase address
      [MTD] [OneNAND] add Nokia Copyright and a credit

Aji Srinivas (1):
      [BRIDGE]: adding new device to bridge should enable if up

Akiyama, Nobuyuki (1):
      [IA64] add missing syscall trace clear

Al Viro (31):
      fix deadlock in audit_log_task_context()
      sanitize security_getprocattr() API
      ibmtr probe is __devinit, not __init
      const file_operations fallout
      appldata build fix
      (uml) sparse flags for userland glue are missing $(CF)
      zatm __init abuse
      stacktrace doesn't work on uml
      fix ipath_dma_free_coherent() prototype
      m32r dma-mapping.h should simply include generic/dma-mapping-broken.h
      include of asm/pgtable.h in nfsfh is bogus
      BLK_DEV_IDE_CELLEB dependency fix
      sparc: have dma-mapping.h include generic/dma-mapping-broken in non-PCI case
      rtc-cmos needs RTC_ALWAYS_BCD known
      misc NULL noise
      fastcall still doesn't make sense in paravirt
      dmfe trivial endianness annotations
      constant should be long
      pasemi trivial iomem annotations
      sparc: nr_free_pages() is unsigned long
      trivial ATA iomem annotations
      cciss endian annotations
      qeth gfp_t annotations
      C99 initializers, proper use of const in drivers/ps3
      cifs endianness annotations
      hid-core endianness annotations
      ANSIfy powerpc floppy.h
      atl1 trivial endianness misannotations
      kill bogus casts in amd64 uaccess.h
      paride endianness annotations
      m68k dma-mapping: gfp_t annotations

Alan Cox (4):
      [MTD] [MAPS] dilnetpc: Fix printk warning
      libata-acpi: Try and stop all the non PCI devices crashing
      ata_piix: Remove ugly layering violation
      z85230: Fix FIFO handling

Alan Stern (4):
      USB: set the correct interval for interrupt URBs
      UHCI: fix port resume problem
      sysfs and driver core: add callback helper, used by SCSI and S390
      sysfs: reinstate exclusion between method calls and attribute unregistration

Alexey Starikovskiy (2):
      ACPICA: Fix ACPI Global Lock re-entrancy
      ACPI: ec: fix race in status register access

Andre Spahlinger (1):
      USB: ipaq.c: Additional devices

Andrew Morton (1):
      sony-laptop: fix uninitialised variable

Andrew Nayenko (1):
      USB storage: Nokia 6288 unusual_devs entry

Anthony Godshall, Ampro Computers, Inc (1):
      ACPI: make blacklist more verbose

Arnd Bergmann (2):
      [POWERPC] spufs: fix possible memory corruption is spufs_mem_write
      [POWERPC] update cell_defconfig

Artem Bityutskiy (1):
      [JFFS2] print a message when marking bad block

Benjamin Herrenschmidt (4):
      [POWERPC] Fix warning in prom_parse.c of_irq_map_oldworld()
      [POWERPC] Fix warning in powermac feature.c
      [POWERPC] Fix warning in powermac pci.c
      [POWERPC] Fix spu SLB invalidations

Bernhard Walle (1):
      ACPI: Add kernel-parameters hint that acpi=off doesn't work on IA64.

Brice Goglin (4):
      myri10ge: fix error checking and return value in myri10ge_allocate_rings
      myri10ge: use pci_map_page to prepare the dmatest buffer
      myri10ge: prevent 4k rdma on SGI TIOCE chipset
      myri10ge: add a wc_enabled flag to myri10ge_priv

Chris Dearman (1):
      [MIPS] Oprofile: Reset all performance registers for MIPS_MT_SMP configs

Chris Wright (1):
      [IPV6] fix ipv6_getsockopt_sticky copy_to_user leak

Christoph Hellwig (1):
      [POWERPC] avoid SPU_ACTIVATE_NOWAKE optimization

Cyrill Gorcunov (2):
      [MTD] ESB2 check for closed ROM window
      USB Elan FTDI: check for workqueue creation

Dale Farnsworth (1):
      mv643xx: Clear pending interrupts before calling request_irq

Dan Williams (1):
      [ARM] 4248/1: lh7a40x: fix missing definitions for get_irqnr_preamble

Dave Jones (2):
      update 'getting sparse' info.
      build fix for i386 earlyquirk.c

David Brownell (1):
      USB: at91_udc, fix more modpost bogosity (rename driver struct)

David Miller (1):
      RDMA/cxgb3: Fix build on sparc64

David S. Miller (5):
      [IPV6]: Handle np->opt being NULL in ipv6_getsockopt_sticky().
      [SPARC64]: Fix PARPORT build (again).
      [SPARC]: We do not need OLD_GETRLIMIT.
      [SPARC]: Hook up missing syscalls.
      [SPARC64]: Add missing HPAGE_MASK masks on address parameters.

David Woodhouse (2):
      [JFFS2] Use yield() between GC passes in background thread.
      [JFFS2] Check for all-zero node headers

Davide Libenzi (1):
      Add epoll compat_ code to fs/compat.c

Dirk Behme (1):
      ARM: OMAP: Fix missing workqueue include in board-h2.c

Dmitriy Monakhov (1):
      kobject: new_device->kref wasn't putted after error in kobject_move()

Dmitry Torokhov (1):
      Input: i8042 - another attempt to fix AUX delivery checks

Eric Paris (3):
      [IPSEC]: xfrm_policy delete security check misplaced
      [IPSEC]: Add xfrm policy change auditing to pfkey_spdget
      [IPSEC]: xfrm audit hook misplaced in pfkey_delete and xfrm_del_sa

Eric W. Biederman (2):
      msi: Safer state caching.
      pci: Repair pci_save/restore_state so we can restore one save many times.

Evgeniy Polyakov (1):
      [IPV4]: Fix rtm_to_ifaddr() error handling.

Fenghua Yu (1):
      [IA64] fsys_getcpu for IA64

Francois Romieu (2):
      r8169: revert bogus BMCR reset
      r8169: fix a race between PCI probe and dev_open

Gard Spreemann (1):
      USB: Product ID for FT232RL in ftdi_sio

Gary Zambrano (1):
      avr32: dma-mapping.h

Geert Uytterhoeven (2):
      [POWERPC] ps3: always make sure were running on a PS3
      [IPV4]: Fix warning in ip_mc_rejoin_group.

Gerrit Renker (2):
      [DCCP]: Revert patch which disables bidirectional mode
      [DCCP]: Initialise write_xmit_timer also on passive sockets

Greg Kroah-Hartman (2):
      Revert "driver core: refcounting fix"
      Driver core: add device symlink back to sysfs

Haavard Skinnemoen (5):
      [AVR32] at32_spi_setup_slaves should be __init
      [AVR32] show_trace: Only walk valid stack addresses
      [AVR32] Fix typo in include/asm-avr32/Kbuild
      [AVR32] Fix bogus ti->flags manipulation in debug handler
      [AVR32] Don't use kmap() in flush_icache_page()

Henrique de Moraes Holschuh (3):
      ACPI: ibm-acpi: fix initial status of backlight device
      ACPI: ibm-acpi: make ibm-acpi bay support optional
      ACPI: ibm-acpi: improve backlight power handling

Herbert Xu (2):
      [UDP]: Reread uh pointer after pskb_trim
      [IPV6]: Do not set IF_READY if device is down

Hideo Saito (1):
      sh: Fix kernel thread stack corruption with preempt.

Hoang-Nam Nguyen (1):
      IB/ehca: Fix sync between completion handler and destroy cq

Horms (3):
      [IA64] remove duplicate declaration of efi_initialize_iomem_resources
      [IA64] whitespace fixes for include/asm-ia64/sal.h
      [IA64] put kdump_find_rsvd_region in __init

Ingo Molnar (1):
      CPU hotplug: call check_tsc_sync_source() with irqs off

Ishizaki Kou (1):
      [POWERPC] Celleb: bug fix caused by not casting pointer types

Jarek Poplawski (1):
      [SCTP] ipv6: inconsistent lock state ipv6_add_addr/sctp_v6_copy_addrlist

Jeff Dike (1):
      uml: arch_prctl should set thread fs

Jim Radford (2):
      usb-serial: fix shutdown / device_unregister order
      USB: ftdi_sio: use port_probe / port_remove thereby fixing access to the latency_timer

Jiri Kosina (3):
      bluetooth: fix socket locking in hci_sock_dev_event()
      HID: allocate hid_parser in a proper way
      HID: zeroing of bytes in output fields is bogus

Joel Becker (4):
      ocfs2: Proper cleanup in case of error in ocfs2_register_hb_callbacks()
      ocfs2: Concurrent access of o2hb_region->hr_task was not locked
      ocfs2: add some missing address space callbacks
      configfs: add missing mutex_unlock()

Joerg Sommer (1):
      bcm43xx: Fix bug in frequency to channel conversion

Johannes Berg (1):
      driver core: export device_rename

John Keller (2):
      ACPI: Altix: cannot register acpi bus driver before bus scan
      ACPI: Altix: reinitialize acpi tables

Jon K Hellan (1):
      USB: New device IDs for cp2101 driver

Josef Whiter (2):
      [GFS2] fix locking mistake
      [GFS2] fix hangup when multiple processes are trying to write to the same file

Joy Latten (1):
      [XFRM]: Fix missing protocol comparison of larval SAs.

Julius Volz (1):
      ACPI: video: Fix spelling and grammar mistakes

Jörn Engel (1):
      Remove devfs from MAINTAINERS

KAMEZAWA Hiroyuki (1):
      [IA64] fix NULL pointer in ia64/irq_chip-mask/unmask function

Keith Owens (1):
      [IA64] Remove sparse warning from unwind code

Konstantin Karasyov (2):
      ACPI: fix S3 fan resume issue
      ACPI: ThinkPad Z60m: usb mouse stops working after suspend to RAM

Kristen Accardi (1):
      libata-acpi: allow _GTF on SATA, but disable on PATA for now

Kumar Gala (1):
      [POWERPC] 85xx: Enable CONFIG_SERIAL_8250_SHARE_IRQ

Kyungmin Park (4):
      [MTD] [OneNAND] Use oob buffer instead of main one in oob functions
      [MTD] [OneNAND] Fix typo & wrong comments
      [MTD] [OneNAND] Exit the loop when transferring/filling of the oob is finished
      [MTD] [OneNAND] Classify the page data and oob buffer

Larry Finger (1):
      bcm43xx: Fix errors in specs to code translation in B6PHY init

Len Brown (3):
      ACPI: fix Thinkpad 600/600E/600X interrupts
      ACPI: repair nvidia early quirk breakage on x86_64
      ACPI: repair nvidia early quirk breakage on x86_64

Li Yang (1):
      [POWERPC] 83xx: Minor fixes for 834x_mds USB setup code

Linsys Contractor Mithlesh Thukral (2):
      NetXen: Bug fix for Jumbo frames on XG card
      NetXen: Fix softlockup seen during hardware access

Linus Torvalds (3):
      Revert "USB: pxa2xx_udc: fix hardcoded irq number"
      Disable NMI watchdog by default properly
      Linux 2.6.21-rc4

Martin Schiller (1):
      USB: RTS/DTR signal patch for airprime driver

Mathieu Desnoyers (1):
      [SPARC64]: Fix atomicity of TIF update in flush_thread()

Max Dmitrichenko (1):
      USB: fix Unaligned access in EHCI driver

Michael Ellerman (1):
      [POWERPC] Add missing newline in xmon help output

Michael Karcher (1):
      ACPI: fix parallel port IRQ after resume from S3

Michael Olberg (1):
      USB: add QL355P power supply ids to fdti_sio

Milan Svoboda (2):
      USB: pxa2xx_udc: fix hardcoded irq number
      [ARM] 4263/1: fix IXP4XX_NPE[ABC]_BASE_VIRT address

Olaf Kirch (1):
      [IPV6]: Fix for ipv6_setsockopt NULL dereference

Oliver Neukum (5):
      USB: ratelimit debounce error messages
      USB: kill dead code from hub.c
      USB: fix usb-serial device naming bug
      USB: further fix for usb-serial
      USB: fix spinlock recursion in cdc-acm.c

Olof Johansson (1):
      [POWERPC] No DEEPNAP on 970MP 1.0

Paolo 'Blaisorblade' Giarrusso (9):
      uml: hostfs: fix double free
      uml: hostfs: make hostfs= option work as a jail, as intended.
      um: fix a memory leak in the multicast driver
      um: remove dead code about os_usr1_signal() and os_usr1_process()
      um: mark both consoles as CON_ANYTIME
      um: fix confusion irq early reenabling
      uml: activate_fd: return ENOMEM only when appropriate
      um: fix errno usage
      x86_64: fix 2.6.18 regression - PTRACE_OLDSETOPTIONS should be accepted

Pat Gefre (1):
      2.6 Altix: console fix for CONFIG_DEBUG_SHIRQ usage

Patrick McHardy (3):
      [NETFILTER]: nf_conntrack_ipv6: fix incorrect classification of IPv6 fragments as ESTABLISHED
      [NETFILTER]: nfnetlink_log: zero-terminate prefix
      [NETFILTER]: nfnetlink_log: fix crash on bridged packet

Paul Moore (1):
      [NetLabel]: parse the CIPSO ranged tag on incoming packets

Paul Mundt (6):
      doc: Add SH to vdso and earlyprintk in kernel-parameters.txt
      sysctl: Support vdso_enabled sysctl on SH.
      sh: Use L1_CACHE_BYTES for .data.cacheline_aligned.
      sh: Enable SM501 support for RTS7751R2D.
      sh: Revert lazy dcache writeback changes.
      sh: Kill off I/O cruft for R7780RP.

Pavel Pisa (3):
      [ARM] 4254/1: i.MX/MX1 CPU Frequency scaling honor boot loader set BCLK_DIV.
      [ARM] 4255/1: i.MX/MX1 Correct MPU PLL reference clock value.
      [ARM] 4256/1: i.MX/MX1 SDHC fix/workaround of SD card recognition problems

Pavel Roskin (1):
      bcm43xx: Fix assertion failures in interrupt handler

Peter Zijlstra (1):
      ecryptfs: nested locking annotation

Petr Vandrovec (1):
      Fix simplex adapters with libata

Phil Dibowitz (1):
      USB storage: Removed duplicate supertop unusual_dev entry

Philipp Reisner (1):
      [CONNECTOR]: Bugfix for cn_call_callback()

Ralf Baechle (14):
      [CHAR] ds1286: Fix handling of seconds in RTC_ALM_SET ioctl.
      [MIPS] ISA: Fix typo
      [MIPS] ARC: Fix several compiler warnings.
      [MIPS] DEC: Remove call to register_prom_console.
      netxen: fix warnings
      3c59x: Fix several modpost warnings
      ibmtr: Drain rich supply of modpost warnings.
      [MIPS] Sibyte: Do not allow enabling LDT support if PCI is disabled.
      [MIPS] Sibyte: Fix ZBbus profiler
      USB: goku_udc: Remove crude cache coherency code
      [ROSE]: Remove ourselves from waitqueue when receiving a signal
      [ROSE]: Socket locking is a great invention.
      [MIPS] Viper2: Remove defective support.
      [MIPS] kspd: ioctl needs a translation entry.

Richard Fearn (1):
      [GFS2] add newline to printk message

Richard Purdie (3):
      [ARM] 4249/1: Fix tosa compile failure
      [ARM] 4250/1: Fix locomo backlight conversion error/compile failure
      [ARM] 4251/1: Fix sharpsl_pm dependency

Richard Woodruff (1):
      ARM: OMAP: Fix OMAP2 dss2 so clk_set_parent works

Robert Hancock (1):
      sata_nv: revert use of notifiers for now

Robert P. J. Day (3):
      [MTD] [NAND] Correct misspelled preprocessor variable.
      ACPI: Kconfig: hide ACPI menu when CONFIG_PM=n
      [WANROUTER]: Delete superfluous source file "net/wanrouter/af_wanpipe.c".

Robert Reif (2):
      [CG14]: Fix section mismatch warnings.
      [BW2]: Fix section mismatch warnings.

Roger Luethi (1):
      via-rhine: set avoid_D3 for broken BIOSes

Roland Dreier (2):
      IPoIB: Only handle async events for one port
      IB/mthca: Fix error path in mthca_alloc_memfree()

Russ Anderson (2):
      [IA64] Proper handling of TLB errors from duplicate itr.d dropins
      [IA64] Cache error recovery

Ryusuke Sakato (1):
      sh: Fix sigmask trampling in signal delivery.

Sam Ravnborg (3):
      pcie: fix section mismatch warning
      PCI: aer: fix section mismatch warning
      pci: fix section mismatch warning

Sean Hefty (2):
      RDMA/cma: Initialize rdma_bind_list in cma_alloc_any_port()
      RDMA/ucma: Avoid sending reject if backlog is full

Segher Boessenkool (1):
      [POWERPC] Select u-image as default image for Linkstation

Shaohua Li (1):
      ACPI: fix boot hang w/o "noapic" on MSI MS-6390-L

Shirley Ma (1):
      IPoIB: Turn on interface's carrier after broadcast group is joined

Simon Horman (2):
      [IA64] kexec: declare ia64_mca_pal_base in mca.h rather than kexec.h
      [IA64] Cleanup in crash.c

Stephen Hemminger (2):
      sky2: turn off Rx checksum on bad hardware
      skge: set mac address bonding fix

Stephen Rothwell (3):
      [POWERPC] Allocate syscall number for sys_getcpu
      [POWERPC] Wire up sys_epoll_pwait
      [POWERPC] sys_move_pages should be callable from an SPU

Steve Wise (8):
      RDMA/cxgb3: Start ep timer on a MPA reject
      RDMA/cxgb3: Don't use mm after it's freed in iwch_mmap()
      RDMA/cxgb3: Fixes for "normal close" failures
      RDMA/cxgb3: Move QP to error on destroy if the state is IDLE
      RDMA/cxgb3: Stop EP timer when MPA exchange is aborted by peer
      RDMA/cxgb3: Squelch logging AE errors
      RDMA/cxgb3: Don't reuse skbs that are non-linear or cloned
      RDMA/cxgb3: Fix MR permission problems

Steven Whitehouse (5):
      [GFS2] Fix bz 230143, incorrect flushing of rgrps
      [GFS2] Fix bz 229831, lookup returns wrong inode
      [GFS2] Remove unused variable
      [GFS2] go_drop_bh is never used, so remove it
      [GFS2] Fix bz 229873, alternate test: assertion "!ip->i_inode.i_mapping->nrpages" failed

Stuart Menefy (1):
      sh: Clear UBC when not in use.

Sunil Mushran (2):
      ocfs2_dlm: Missing get/put lockres in dlm_run_purge_lockres
      ocfs2_dlm: Add missing locks in dlm_empty_lockres

Tejun Heo (3):
      libata: fix ata_host_release() free order
      devres: release resources on device_del()
      PCI: allow multiple calls to pcim_pin_device()

Thomas Schleusener (1):
      USB: add Additional PIDs in ftdi_sio

Tony Lindgren (1):
      ARM: OMAP: Include missing header

Tony Luck (2):
      [IA64] Pick highest possible saved_max_pfn for crash_dump
      [IA64] refresh config files

Uwe Kleine-König (1):
      [ARM] 4247/1: Fix long name for cc9p9360dev

Vijay Sampath (1):
      [MTD] [NOR] Fix oops in cfi_amdstd_sync

Vitaly Wool (2):
      [MTD] [NAND] make oobavail public
      [JFFS2] Fix writebuffer recovery in the first page of a block

Wendy Cheng (2):
      [GFS2] NFS filehandle check
      [GFS2] pass formal ino in do_filldir_main

William Lee Irwin III (1):
      [SPARC]: Fix TIF_USEDFPU flag atomicity

Wim Van Sebroeck (1):
      [WATCHDOG] i8xx TCO driver - mark for removal

YOSHIFUJI Hideaki (1):
      USBNET: DM9501: Add Corega FEther USB-TXC support.

Zachary Amsden (2):
      Fix VMI and COMPAT_VDSO for 2.6.21
      Fix vmi time header bug

Zhang, Yanmin (1):
      [IA64] pci_get_legacy_ide_irq should return irq (not GSI)

akpm@linux-foundation.org (1):
      [GFS2] build fix

broonie@sirena.org.uk (3):
      natsemi: Consistently use interrupt enable/disable functions
      natsemi: Fix NAPI for interrupt sharing
      natsemi: Avoid IntrStatus lossage if RX state machine resets.

suzuki (1):
      check_partition(): fix error check

Re: Linux 2.6.21-rc4

[Takashi Iwai]

At Fri, 16 Mar 2007 09:33:54 -0700 (PDT),
Linus Torvalds wrote:
> 
> Anyway, the good news about -rc4 is that there's just lots of random 
> fixes. I'm hoping that we've seriously cut down on the regression list, 
> and I'd ask everybody who is on Adrian's list to please re-verify their 
> regression, and in case it's one of the "patches available" ones but I 
> haven't merged (maybe because it hasn't been sent to me!), make sure I do.

alsa-git merge seems missing in rc4:
	http://lkml.org/lkml/2007/3/14/43

Linus, could you pull from below (linus brunch)?

  master.kernel.org:/pub/scm/linux/kernel/git/perex/alsa.git linus

It includes regression fixes.


Thanks,

Takashi

Re: Linux 2.6.21-rc4

[Michal Piotrowski]

Hi,

I've got *bad* news. Bug described here
http://www.ussg.iu.edu/hypermail/linux/kernel/0703.0/index.html#0889
http://www.ussg.iu.edu/hypermail/linux/kernel/0703.0/index.html#1165
probably leaked into mainline. 

Fsck!

http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc4/git-config
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc4/git-console.log

Takashi, unfortunately this bug isn't fixed
http://www.ussg.iu.edu/hypermail/linux/kernel/0703.0/index.html#1684

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

Re: Linux 2.6.21-rc4

[Andrew Morton]

On Fri, 16 Mar 2007 18:44:26 +0100 Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:

> I've got *bad* news. Bug described here
> http://www.ussg.iu.edu/hypermail/linux/kernel/0703.0/index.html#0889
> http://www.ussg.iu.edu/hypermail/linux/kernel/0703.0/index.html#1165
> probably leaked into mainline. 
> 
> Fsck!

fsck indeed.  I don't even understand what's happening with that one - it
seems like the kernel schedules a user process, but never deschedules it
again.

Re: Linux 2.6.21-rc4

[Takashi Iwai]

At Fri, 16 Mar 2007 18:44:26 +0100,
Michal Piotrowski wrote:
> 
> Takashi, unfortunately this bug isn't fixed
> http://www.ussg.iu.edu/hypermail/linux/kernel/0703.0/index.html#1684

The patch wasn't merged to rc4.
Or, do you mean the bug is still present even with the patch?


Takashi

Re: Linux 2.6.21-rc4

[Michal Piotrowski]

On 16/03/07, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Fri, 16 Mar 2007 18:44:26 +0100 Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
>
> > I've got *bad* news. Bug described here
> > http://www.ussg.iu.edu/hypermail/linux/kernel/0703.0/index.html#0889
> > http://www.ussg.iu.edu/hypermail/linux/kernel/0703.0/index.html#1165
> > probably leaked into mainline.
> >
> > Fsck!
>
> fsck indeed.  I don't even understand what's happening with that one - it
> seems like the kernel schedules a user process, but never deschedules it
> again.
>

Tomorrow, I'll try to find out how to reproduce this bug.

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

Re: Linux 2.6.21-rc4

[Michal Piotrowski]

On 16/03/07, Takashi Iwai <tiwai@suse.de> wrote:
> At Fri, 16 Mar 2007 18:44:26 +0100,
> Michal Piotrowski wrote:
> >
> > Takashi, unfortunately this bug isn't fixed
> > http://www.ussg.iu.edu/hypermail/linux/kernel/0703.0/index.html#1684
>
> The patch wasn't merged to rc4.

I know. I use patched 2.6.21-rc3-git4 for crashdump.

> Or, do you mean the bug is still present even with the patch?

This patch doesn't fix the problem.
http://www.ussg.iu.edu/hypermail/linux/kernel/0703.0/3080.html

Tomorrow, I'll try to provide more info about this problem.

>
>
> Takashi
>

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

Re: Linux 2.6.21-rc4

[Rafael J. Wysocki]

On Friday, 16 March 2007 17:33, Linus Torvalds wrote:
> 
> I pushed out the -git trees yesterday, but then got distracted, so the 
> patches and tar-balls and the announcement got delayed until this morning. 
> Oops. I'm a scatter-brain.
> 
> Anyway, the good news about -rc4 is that there's just lots of random 
> fixes. I'm hoping that we've seriously cut down on the regression list, 
> and I'd ask everybody who is on Adrian's list to please re-verify their 
> regression, and in case it's one of the "patches available" ones but I 
> haven't merged (maybe because it hasn't been sent to me!), make sure I do.

I'm afraid that if CONFIG_TICK_ONESHOT or CONFIG_NO_HZ is set, we still have a
problem with RCU synchronization while nonboot CPUs are being enabled during a
resume (http://lkml.org/lkml/2007/3/11/144, http://lkml.org/lkml/2007/3/4/88).

Can someone who had this problem with -rc3 check if it's present in -rc4?

Thanks,
Rafael

Re: Linux 2.6.21-rc4

[Thomas Gleixner]

On Fri, 2007-03-16 at 21:34 +0100, Rafael J. Wysocki wrote:
> On Friday, 16 March 2007 17:33, Linus Torvalds wrote:
> > 
> > I pushed out the -git trees yesterday, but then got distracted, so the 
> > patches and tar-balls and the announcement got delayed until this morning. 
> > Oops. I'm a scatter-brain.
> > 
> > Anyway, the good news about -rc4 is that there's just lots of random 
> > fixes. I'm hoping that we've seriously cut down on the regression list, 
> > and I'd ask everybody who is on Adrian's list to please re-verify their 
> > regression, and in case it's one of the "patches available" ones but I 
> > haven't merged (maybe because it hasn't been sent to me!), make sure I do.
> 
> I'm afraid that if CONFIG_TICK_ONESHOT or CONFIG_NO_HZ is set, we still have a
> problem with RCU synchronization while nonboot CPUs are being enabled during a
> resume (http://lkml.org/lkml/2007/3/11/144, http://lkml.org/lkml/2007/3/4/88).
> 
> Can someone who had this problem with -rc3 check if it's present in -rc4?

I finally found a box today, which shows this problem. I'm working on a
fix.

	tglx

Re: Linux 2.6.21-rc4

[Randy Dunlap]

On Fri, 16 Mar 2007 09:33:54 -0700 (PDT) Linus Torvalds wrote:

> 
> I pushed out the -git trees yesterday, but then got distracted, so the 
> patches and tar-balls and the announcement got delayed until this morning. 
> Oops. I'm a scatter-brain.

allmodconfig on i386:

WARNING: "default_idle" [arch/i386/kernel/apm.ko] undefined!
WARNING: "machine_real_restart" [arch/i386/kernel/apm.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: Linux 2.6.21-rc4

[Randy Dunlap]

On Fri, 16 Mar 2007 14:11:21 -0700 Randy Dunlap wrote:

> On Fri, 16 Mar 2007 09:33:54 -0700 (PDT) Linus Torvalds wrote:
> 
> > 
> > I pushed out the -git trees yesterday, but then got distracted, so the 
> > patches and tar-balls and the announcement got delayed until this morning. 
> > Oops. I'm a scatter-brain.
> 
> allmodconfig on i386:
> 
> WARNING: "default_idle" [arch/i386/kernel/apm.ko] undefined!
> WARNING: "machine_real_restart" [arch/i386/kernel/apm.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2

Please ignore.

I think that this was the result of doing 'make allyesconfig && make all'
followed by 'make allmodconfig && make all' without doing a 'make clean'
between them.

---
~Randy

Re: Linux 2.6.21-rc4

[Chris Friesen]

Randy Dunlap wrote:

>>allmodconfig on i386:
>>
>>WARNING: "default_idle" [arch/i386/kernel/apm.ko] undefined!
>>WARNING: "machine_real_restart" [arch/i386/kernel/apm.ko] undefined!
>>make[1]: *** [__modpost] Error 1
>>make: *** [modules] Error 2
> 
> 
> Please ignore.
> 
> I think that this was the result of doing 'make allyesconfig && make all'
> followed by 'make allmodconfig && make all' without doing a 'make clean'
> between them.

This would seem to be a bug in the build system then.  Or are you 
supposed to "make clean" after every config change?

Chris

Re: Linux 2.6.21-rc4

[Jan Engelhardt]

On Mar 16 2007 19:55, Michal Piotrowski wrote:
>> > I've got *bad* news. Bug described here
>> > http: //www.ussg.iu.edu/hypermail/linux/kernel/0703.0/index.html#0889
>> > http: //www.ussg.iu.edu/hypermail/linux/kernel/0703.0/index.html#1165
>> > probably leaked into mainline.
>> > 
>> > Fsck!
>> 
>> fsck indeed.  I don't even understand what's happening with that one - it
>> seems like the kernel schedules a user process, but never deschedules it
>> again.
>> 
>
> Tomorrow, I'll try to find out how to reproduce this bug.

>From #0889:

 "I have noticed some strange system behavior. When i try to build a
 kernel (medium load) - X, keyboard, mouse and sound hangs."

Note that ping is handled in interrupt or softirq context. So something has
locked up. Try without X? Or perhaps attack a serial console/netconsole, and
when it hangs, use Sysrq to dump the process' states.


Jan
-- 

[PATCH] clockevents: Fix suspend/resume to disk hangs

[Thomas Gleixner]

I finally found a dual core box, which survives suspend/resume without
crashing in the middle of nowhere. Sigh, I never figured out from the
code and the bug reports what's going on.

The observed hangs are caused by a stale state transition of the clock
event devices, which keeps the RCU synchronization away from completion,
when the non boot CPU is brought back up.

The suspend/resume in oneshot mode needs the similar care as the
periodic mode during suspend to RAM. My assumption that the state
transitions during the different shutdown/bringups of s2disk would go
through the periodic boot phase and then switch over to highres resp.
nohz mode were simply wrong.

Add the appropriate suspend / resume handling for the non periodic
modes.

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

diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index 5567745..eadfce2 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -307,12 +307,19 @@ int tick_resume_broadcast(void)
 	spin_lock_irqsave(&tick_broadcast_lock, flags);
 
 	bc = tick_broadcast_device.evtdev;
-	if (bc) {
-		if (tick_broadcast_device.mode == TICKDEV_MODE_PERIODIC &&
-		    !cpus_empty(tick_broadcast_mask))
-			tick_broadcast_start_periodic(bc);
 
-		broadcast = cpu_isset(smp_processor_id(), tick_broadcast_mask);
+	if (bc) {
+		switch (tick_broadcast_device.mode) {
+		case TICKDEV_MODE_PERIODIC:
+			if(!cpus_empty(tick_broadcast_mask))
+				tick_broadcast_start_periodic(bc);
+			broadcast = cpu_isset(smp_processor_id(),
+					      tick_broadcast_mask);
+			break;
+		case TICKDEV_MODE_ONESHOT:
+			broadcast = tick_resume_broadcast_oneshot(bc);
+			break;
+		}
 	}
 	spin_unlock_irqrestore(&tick_broadcast_lock, flags);
 
@@ -347,6 +354,16 @@ static int tick_broadcast_set_event(ktime_t expires, int force)
 	}
 }
 
+int tick_resume_broadcast_oneshot(struct clock_event_device *bc)
+{
+	clockevents_set_mode(bc, CLOCK_EVT_MODE_ONESHOT);
+
+	if(!cpus_empty(tick_broadcast_oneshot_mask))
+		tick_broadcast_set_event(ktime_get(), 1);
+
+	return cpu_isset(smp_processor_id(), tick_broadcast_oneshot_mask);
+}
+
 /*
  * Reprogram the broadcast device:
  *
diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index 43ba1bd..bfda3f7 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -298,18 +298,17 @@ static void tick_shutdown(unsigned int *cpup)
 	spin_unlock_irqrestore(&tick_device_lock, flags);
 }
 
-static void tick_suspend_periodic(void)
+static void tick_suspend(void)
 {
 	struct tick_device *td = &__get_cpu_var(tick_cpu_device);
 	unsigned long flags;
 
 	spin_lock_irqsave(&tick_device_lock, flags);
-	if (td->mode == TICKDEV_MODE_PERIODIC)
-		clockevents_set_mode(td->evtdev, CLOCK_EVT_MODE_SHUTDOWN);
+	clockevents_set_mode(td->evtdev, CLOCK_EVT_MODE_SHUTDOWN);
 	spin_unlock_irqrestore(&tick_device_lock, flags);
 }
 
-static void tick_resume_periodic(void)
+static void tick_resume(void)
 {
 	struct tick_device *td = &__get_cpu_var(tick_cpu_device);
 	unsigned long flags;
@@ -317,6 +316,8 @@ static void tick_resume_periodic(void)
 	spin_lock_irqsave(&tick_device_lock, flags);
 	if (td->mode == TICKDEV_MODE_PERIODIC)
 		tick_setup_periodic(td->evtdev, 0);
+	else
+		tick_resume_oneshot();
 	spin_unlock_irqrestore(&tick_device_lock, flags);
 }
 
@@ -348,13 +349,13 @@ static int tick_notify(struct notifier_block *nb, unsigned long reason,
 		break;
 
 	case CLOCK_EVT_NOTIFY_SUSPEND:
-		tick_suspend_periodic();
+		tick_suspend();
 		tick_suspend_broadcast();
 		break;
 
 	case CLOCK_EVT_NOTIFY_RESUME:
 		if (!tick_resume_broadcast())
-			tick_resume_periodic();
+			tick_resume();
 		break;
 
 	default:
diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h
index 75890ef..c9d203b 100644
--- a/kernel/time/tick-internal.h
+++ b/kernel/time/tick-internal.h
@@ -19,12 +19,13 @@ extern void tick_setup_oneshot(struct clock_event_device *newdev,
 extern int tick_program_event(ktime_t expires, int force);
 extern void tick_oneshot_notify(void);
 extern int tick_switch_to_oneshot(void (*handler)(struct clock_event_device *));
-
+extern void tick_resume_oneshot(void);
 # ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
 extern void tick_broadcast_setup_oneshot(struct clock_event_device *bc);
 extern void tick_broadcast_oneshot_control(unsigned long reason);
 extern void tick_broadcast_switch_to_oneshot(void);
 extern void tick_shutdown_broadcast_oneshot(unsigned int *cpup);
+extern int tick_resume_broadcast_oneshot(struct clock_event_device *bc);
 # else /* BROADCAST */
 static inline void tick_broadcast_setup_oneshot(struct clock_event_device *bc)
 {
@@ -43,6 +44,10 @@ void tick_setup_oneshot(struct clock_event_device *newdev,
 {
 	BUG();
 }
+static inline void tick_resume_oneshot(void)
+{
+	BUG();
+}
 static inline int tick_program_event(ktime_t expires, int force)
 {
 	return 0;
@@ -54,6 +59,10 @@ static inline void tick_broadcast_setup_oneshot(struct clock_event_device *bc)
 }
 static inline void tick_broadcast_oneshot_control(unsigned long reason) { }
 static inline void tick_shutdown_broadcast_oneshot(unsigned int *cpup) { }
+static inline int tick_resume_broadcast_oneshot(struct clock_event_device *bc)
+{
+	return 0;
+}
 #endif /* !TICK_ONESHOT */
 
 /*
diff --git a/kernel/time/tick-oneshot.c b/kernel/time/tick-oneshot.c
index 2e8b7ff..f6997ab 100644
--- a/kernel/time/tick-oneshot.c
+++ b/kernel/time/tick-oneshot.c
@@ -41,6 +41,18 @@ int tick_program_event(ktime_t expires, int force)
 }
 
 /**
+ * tick_resume_onshot - resume oneshot mode
+ */
+void tick_resume_oneshot(void)
+{
+	struct tick_device *td = &__get_cpu_var(tick_cpu_device);
+	struct clock_event_device *dev = td->evtdev;
+
+	clockevents_set_mode(dev, CLOCK_EVT_MODE_ONESHOT);
+	tick_program_event(ktime_get(), 1);
+}
+
+/**
  * tick_setup_oneshot - setup the event device for oneshot mode (hres or nohz)
  */
 void tick_setup_oneshot(struct clock_event_device *newdev,

Re: Linux 2.6.21-rc4

[Jan Engelhardt]

On Mar 16 2007 17:13, Chris Friesen wrote:
>
> This would seem to be a bug in the build system then.  Or are you
> supposed to "make clean" after every config change?

No. When .config is changed, include/linux/config/ is updated, which
causes things that depends on it one or the other way to rebuild. At
least that is what I observed since ages.


Jan
-- 

Re: Linux 2.6.21-rc4

[Michal Piotrowski]

On 17/03/07, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
>
> On Mar 16 2007 19:55, Michal Piotrowski wrote:
> >> > I've got *bad* news. Bug described here
> >> > http: //www.ussg.iu.edu/hypermail/linux/kernel/0703.0/index.html#0889
> >> > http: //www.ussg.iu.edu/hypermail/linux/kernel/0703.0/index.html#1165
> >> > probably leaked into mainline.
> >> >
> >> > Fsck!
> >>
> >> fsck indeed.  I don't even understand what's happening with that one - it
> >> seems like the kernel schedules a user process, but never deschedules it
> >> again.
> >>
> >
> > Tomorrow, I'll try to find out how to reproduce this bug.
>
> From #0889:
>
>  "I have noticed some strange system behavior. When i try to build a
>  kernel (medium load) - X, keyboard, mouse and sound hangs."
>
> Note that ping is handled in interrupt or softirq context. So something has
> locked up. Try without X? Or perhaps attack a serial console/netconsole, and
> when it hangs, use Sysrq to dump the process' states.

I already did this
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc4/git-console.log

>
>
> Jan
> --
>

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

Re: Linux 2.6.21-rc4

[Sam Ravnborg]

On Fri, Mar 16, 2007 at 03:39:57PM -0700, Randy Dunlap wrote:
> On Fri, 16 Mar 2007 14:11:21 -0700 Randy Dunlap wrote:
> 
> > On Fri, 16 Mar 2007 09:33:54 -0700 (PDT) Linus Torvalds wrote:
> > 
> > > 
> > > I pushed out the -git trees yesterday, but then got distracted, so the 
> > > patches and tar-balls and the announcement got delayed until this morning. 
> > > Oops. I'm a scatter-brain.
> > 
> > allmodconfig on i386:
> > 
> > WARNING: "default_idle" [arch/i386/kernel/apm.ko] undefined!
> > WARNING: "machine_real_restart" [arch/i386/kernel/apm.ko] undefined!
> > make[1]: *** [__modpost] Error 1
> > make: *** [modules] Error 2
> 
> Please ignore.
> 
> I think that this was the result of doing 'make allyesconfig && make all'
> followed by 'make allmodconfig && make all' without doing a 'make clean'
> between them.
But then we have a dependency error somewhere we need to track down.
I will try to test here.

	Sam

Re: Linux 2.6.21-rc4

[Mariusz Kozlowski]

Hello,

> > Note that ping is handled in interrupt or softirq context. So something has
> > locked up. Try without X? Or perhaps attack a serial console/netconsole, and
> > when it hangs, use Sysrq to dump the process' states.
> 
> I already did this
> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc4/git-console.log

Me too.

http://www.ussg.iu.edu/hypermail/linux/kernel/0703.0/1243.html

Although I can't reproduce it with 2.6.21-rc3-mm1.

Regards,

	Mariusz Kozlowski

Re: [PATCH] clockevents: Fix suspend/resume to disk hangs

[Milan Broz]

Thomas Gleixner wrote:
> I finally found a dual core box, which survives suspend/resume without
> crashing in the middle of nowhere. Sigh, I never figured out from the
> code and the bug reports what's going on.
> 
> The observed hangs are caused by a stale state transition of the clock
> event devices, which keeps the RCU synchronization away from completion,
> when the non boot CPU is brought back up.
> 
> The suspend/resume in oneshot mode needs the similar care as the
> periodic mode during suspend to RAM. My assumption that the state
> transitions during the different shutdown/bringups of s2disk would go
> through the periodic boot phase and then switch over to highres resp.
> nohz mode were simply wrong.
> 
> Add the appropriate suspend / resume handling for the non periodic
> modes.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Hi,
I can confirm that this patch fixed the problem on Thinkpad X60s.

Thanks !

Milan
--
mbroz@redhat.com
 

Re: [PATCH] clockevents: Fix suspend/resume to disk hangs

[Thomas Meyer]

Thomas Gleixner schrieb:
> I finally found a dual core box, which survives suspend/resume without
> crashing in the middle of nowhere. Sigh, I never figured out from the
> code and the bug reports what's going on.
>
> The observed hangs are caused by a stale state transition of the clock
> event devices, which keeps the RCU synchronization away from completion,
> when the non boot CPU is brought back up.
>
> The suspend/resume in oneshot mode needs the similar care as the
> periodic mode during suspend to RAM. My assumption that the state
> transitions during the different shutdown/bringups of s2disk would go
> through the periodic boot phase and then switch over to highres resp.
> nohz mode were simply wrong.
>
> Add the appropriate suspend / resume handling for the non periodic
> modes.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>   

Excellent work. Now suspend to disk is working again. But:

1.) The quirk added in commit a417a21e10831bca695b4ba9c74f4ddf5a95ac06
for the appletouch driver doesn't seem to work after resume.

2.) The first suspend to disk works with no problems, but the second
suspend to disk in a row results in an oops:
 ->resume_device ->
pci_device_resume->ata_host_resume->ahci_pci_device_resume->ata_pci_device_do_resume->pci_restore_state

Re: [PATCH] clockevents: Fix suspend/resume to disk hangs

[Rafael J. Wysocki]

On Saturday, 17 March 2007 11:07, Thomas Meyer wrote:
> Thomas Gleixner schrieb:
> > I finally found a dual core box, which survives suspend/resume without
> > crashing in the middle of nowhere. Sigh, I never figured out from the
> > code and the bug reports what's going on.
> >
> > The observed hangs are caused by a stale state transition of the clock
> > event devices, which keeps the RCU synchronization away from completion,
> > when the non boot CPU is brought back up.
> >
> > The suspend/resume in oneshot mode needs the similar care as the
> > periodic mode during suspend to RAM. My assumption that the state
> > transitions during the different shutdown/bringups of s2disk would go
> > through the periodic boot phase and then switch over to highres resp.
> > nohz mode were simply wrong.
> >
> > Add the appropriate suspend / resume handling for the non periodic
> > modes.
> >
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> >   
> 
> Excellent work. Now suspend to disk is working again. But:
> 
> 1.) The quirk added in commit a417a21e10831bca695b4ba9c74f4ddf5a95ac06
> for the appletouch driver doesn't seem to work after resume.
> 
> 2.) The first suspend to disk works with no problems, but the second
> suspend to disk in a row results in an oops:
>  ->resume_device ->
> pci_device_resume->ata_host_resume->ahci_pci_device_resume->ata_pci_device_do_resume->pci_restore_state

Can you please see if this problem is already in the Adrian's list of known
regressions?

Thanks,
Rafael

Re: Linux 2.6.21-rc4

[Adrian Bunk]

On Fri, Mar 16, 2007 at 08:03:29PM +0100, Michal Piotrowski wrote:
> On 16/03/07, Takashi Iwai <tiwai@suse.de> wrote:
> >At Fri, 16 Mar 2007 18:44:26 +0100,
> >Michal Piotrowski wrote:
> >>
> >> Takashi, unfortunately this bug isn't fixed
> >> http://www.ussg.iu.edu/hypermail/linux/kernel/0703.0/index.html#1684
> >
> >The patch wasn't merged to rc4.
> 
> I know. I use patched 2.6.21-rc3-git4 for crashdump.
> 
> >Or, do you mean the bug is still present even with the patch?
> 
> This patch doesn't fix the problem.
> http://www.ussg.iu.edu/hypermail/linux/kernel/0703.0/3080.html
> 
> Tomorrow, I'll try to provide more info about this problem.

You said at [1] that the patch from [2] (not yet merged into Linus' tree) 
fixed this problem for you.

Or do I confuse anything?

> Regards,
> Michal

cu
Adrian

[1] http://lkml.org/lkml/2007/3/13/276
[2] http://lkml.org/lkml/2007/3/7/540

-- 

       "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

appletouch quirk doesn't run at resume

[Adrian Bunk]

On Sat, Mar 17, 2007 at 11:07:38AM +0100, Thomas Meyer wrote:
> Thomas Gleixner schrieb:
> > I finally found a dual core box, which survives suspend/resume without
> > crashing in the middle of nowhere. Sigh, I never figured out from the
> > code and the bug reports what's going on.
> >
> > The observed hangs are caused by a stale state transition of the clock
> > event devices, which keeps the RCU synchronization away from completion,
> > when the non boot CPU is brought back up.
> >
> > The suspend/resume in oneshot mode needs the similar care as the
> > periodic mode during suspend to RAM. My assumption that the state
> > transitions during the different shutdown/bringups of s2disk would go
> > through the periodic boot phase and then switch over to highres resp.
> > nohz mode were simply wrong.
> >
> > Add the appropriate suspend / resume handling for the non periodic
> > modes.
> >
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> >   
> 
> Excellent work. Now suspend to disk is working again. But:
> 
> 1.) The quirk added in commit a417a21e10831bca695b4ba9c74f4ddf5a95ac06
> for the appletouch driver doesn't seem to work after resume.
>...

Not a regression, but still a bug.
Appropriate people added to the Cc.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Linux 2.6.21-rc4

[Sam Ravnborg]

On Sat, Mar 17, 2007 at 07:43:40AM +0100, Sam Ravnborg wrote:
> On Fri, Mar 16, 2007 at 03:39:57PM -0700, Randy Dunlap wrote:
> > On Fri, 16 Mar 2007 14:11:21 -0700 Randy Dunlap wrote:
> > 
> > > On Fri, 16 Mar 2007 09:33:54 -0700 (PDT) Linus Torvalds wrote:
> > > 
> > > > 
> > > > I pushed out the -git trees yesterday, but then got distracted, so the 
> > > > patches and tar-balls and the announcement got delayed until this morning. 
> > > > Oops. I'm a scatter-brain.
> > > 
> > > allmodconfig on i386:
> > > 
> > > WARNING: "default_idle" [arch/i386/kernel/apm.ko] undefined!
> > > WARNING: "machine_real_restart" [arch/i386/kernel/apm.ko] undefined!
> > > make[1]: *** [__modpost] Error 1
> > > make: *** [modules] Error 2
> > 
> > Please ignore.
> > 
> > I think that this was the result of doing 'make allyesconfig && make all'
> > followed by 'make allmodconfig && make all' without doing a 'make clean'
> > between them.
> But then we have a dependency error somewhere we need to track down.
> I will try to test here.

So far no luck in reproducing this.
I will await additional reports before looking more into this one.

	Sam

Re: Linux 2.6.21-rc4

[Michal Piotrowski]

Adrian Bunk napisał(a):
> On Fri, Mar 16, 2007 at 08:03:29PM +0100, Michal Piotrowski wrote:
>> On 16/03/07, Takashi Iwai <tiwai@suse.de> wrote:
>>> At Fri, 16 Mar 2007 18:44:26 +0100,
>>> Michal Piotrowski wrote:
>>>> Takashi, unfortunately this bug isn't fixed
>>>> http://www.ussg.iu.edu/hypermail/linux/kernel/0703.0/index.html#1684
>>> The patch wasn't merged to rc4.
>> I know. I use patched 2.6.21-rc3-git4 for crashdump.
>>
>>> Or, do you mean the bug is still present even with the patch?
>> This patch doesn't fix the problem.
>> http://www.ussg.iu.edu/hypermail/linux/kernel/0703.0/3080.html
>>
>> Tomorrow, I'll try to provide more info about this problem.
> 
> You said at [1] that the patch from [2] (not yet merged into Linus' tree) 
> fixed this problem for you.


Sorry, it's my fault.

This patch doesn't fix the problem.

> 
> Or do I confuse anything?
> 
>> Regards,
>> Michal
> 
> cu
> Adrian
> 
> [1] http://lkml.org/lkml/2007/3/13/276
> [2] http://lkml.org/lkml/2007/3/7/540
> 

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

Re: [PATCH] clockevents: Fix suspend/resume to disk hangs

[Adrian Bunk]

On Sat, Mar 17, 2007 at 10:47:01PM +0100, Rafael J. Wysocki wrote:
> On Saturday, 17 March 2007 11:07, Thomas Meyer wrote:
> >...
> > 2.) The first suspend to disk works with no problems, but the second
> > suspend to disk in a row results in an oops:
> >  ->resume_device ->
> > pci_device_resume->ata_host_resume->ahci_pci_device_resume->ata_pci_device_do_resume->pci_restore_state
> 
> Can you please see if this problem is already in the Adrian's list of known
> regressions?

AFAIK not, I've given it an own entry.

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

Re: appletouch quirk doesn't run at resume

[Jiri Kosina]

On Sun, 18 Mar 2007, Adrian Bunk wrote:

> > 1.) The quirk added in commit a417a21e10831bca695b4ba9c74f4ddf5a95ac06 
> >     for the appletouch driver doesn't seem to work after resume.
> Not a regression, but still a bug. Appropriate people added to the Cc.

(trimmed CC a little bit)

Thomas, could you please provide more information? Did it ever work for 
you after suspend/resume cycle and it just broke at some point in the 
past, or you are not sure whether it ever worked?

Also, what exactly does it mean that it doesn't work? Are both the 
interfaces after resume bound to usbhid driver (you can check this in 
/sys)? When the quirk works correctly, only the keyboard interface should 
be bound to usbhid driver. Please check the binding both before and after 
suspend/resume cycle, and let me know.

Thanks,

-- 
Jiri Kosina

[1/6] 2.6.21-rc4: known regressions

[Adrian Bunk]

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    : weird system hangs
References : http://lkml.org/lkml/2007/3/16/288
Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
             Mariusz Kozlowski <m.kozlowski@tuxland.pl>
Status     : unknown


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
References : http://lkml.org/lkml/2007/2/28/112
Submitter  : Sid Boyce <g3vbv@blueyonder.co.uk>
Status     : unknown

[2/6] 2.6.21-rc4: known regressions

[Adrian Bunk]

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: boot hangs unless CONFIG_PCIEPORTBUS=n and acpi=off
References : http://bugzilla.kernel.org/show_bug.cgi?id=8162
Submitter  : Randy Dunlap <randy.dunlap@oracle.com>
Status     : unknown


Subject    : AMD Elan: Crash after "Allocating PCI resources"
References : http://bugzilla.kernel.org/show_bug.cgi?id=8161
Submitter  : Vladimir Brik <no.hope@gmail.com>
Handled-By : Andi Kleen <ak@muc.de>
Status     : patch available


Subject    : ACPI regression with noapic
References : http://lkml.org/lkml/2007/3/8/468
Submitter  : Ray Lee <ray-lk@madrabbit.org>
Status     : unknown


Subject    : acpi_serialize locks system during boot
References : http://bugzilla.kernel.org/show_bug.cgi?id=8171
Submitter  : Colchao <colchaodemola@gmail.com>
Handled-By : Len Brown <len.brown@intel.com>
Patch      : http://bugzilla.kernel.org/show_bug.cgi?id=8171
Status     : patch available


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
Submitter  : Mathieu Bérard <Mathieu.Berard@crans.org>
Handled-By : Tejun Heo <htejun@gmail.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    : 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
Submitter  : Fabio Comolli <fabio.comolli@gmail.com>
             Plamen Petrov <plamen.petrov@tk.ru.acad.bg>
             Laurent Riffard <laurent.riffard@free.fr>
Handled-By : Tejun Heo <htejun@gmail.com>
             Alan Cox <alan@lxorguk.ukuu.org.uk>
Status     : Alan: Some cases should be fixed now but probably not all
                   (eg the Nvidia one)



-
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

[2/6] 2.6.21-rc4: known regressions

[Adrian Bunk]

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: boot hangs unless CONFIG_PCIEPORTBUS=n and acpi=off
References : http://bugzilla.kernel.org/show_bug.cgi?id=8162
Submitter  : Randy Dunlap <randy.dunlap@oracle.com>
Status     : unknown


Subject    : AMD Elan: Crash after "Allocating PCI resources"
References : http://bugzilla.kernel.org/show_bug.cgi?id=8161
Submitter  : Vladimir Brik <no.hope@gmail.com>
Handled-By : Andi Kleen <ak@muc.de>
Status     : patch available


Subject    : ACPI regression with noapic
References : http://lkml.org/lkml/2007/3/8/468
Submitter  : Ray Lee <ray-lk@madrabbit.org>
Status     : unknown


Subject    : acpi_serialize locks system during boot
References : http://bugzilla.kernel.org/show_bug.cgi?id=8171
Submitter  : Colchao <colchaodemola@gmail.com>
Handled-By : Len Brown <len.brown@intel.com>
Patch      : http://bugzilla.kernel.org/show_bug.cgi?id=8171
Status     : patch available


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
Submitter  : Mathieu Bérard <Mathieu.Berard@crans.org>
Handled-By : Tejun Heo <htejun@gmail.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    : 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
Submitter  : Fabio Comolli <fabio.comolli@gmail.com>
             Plamen Petrov <plamen.petrov@tk.ru.acad.bg>
             Laurent Riffard <laurent.riffard@free.fr>
Handled-By : Tejun Heo <htejun@gmail.com>
             Alan Cox <alan@lxorguk.ukuu.org.uk>
Status     : Alan: Some cases should be fixed now but probably not all
                   (eg the Nvidia one)

[3/6] 2.6.21-rc4: known regressions

[Adrian Bunk]

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    : 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
References : http://lkml.org/lkml/2007/3/6/142
Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
Status     : unknown


Subject    : suspend to disk hangs
References : http://lkml.org/lkml/2007/3/16/126
Submitter  : Maxim Levitsky <maximlevitsky@gmail.com>
Status     : unknown


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


Subject    : ThinkPad R60: suspend broken
References : http://lkml.org/lkml/2007/3/16/57
Submitter  : Marcus Better <marcus@better.se>
Status     : unknown


Subject    : laptop immediately resumes after suspend
References : http://lkml.org/lkml/2007/3/8/469
Submitter  : Ray Lee <ray-lk@madrabbit.org>
Caused-By  : Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
             commit ed41dab90eb40ac4911e60406bc653661f0e4ce1
Handled-By : Len Brown <lenb@kernel.org>
Patch      : http://lkml.org/lkml/2007/3/12/228
Status     : patch available


Subject    : second suspend to disk in a row results in an oops  (libata?)
References : http://lkml.org/lkml/2007/3/17/43
Submitter  : Thomas Meyer <thomas@m3y3r.de>
Status     : unknown


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

[3/6] 2.6.21-rc4: known regressions

[Adrian Bunk]

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    : 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
References : http://lkml.org/lkml/2007/3/6/142
Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
Status     : unknown


Subject    : suspend to disk hangs
References : http://lkml.org/lkml/2007/3/16/126
Submitter  : Maxim Levitsky <maximlevitsky@gmail.com>
Status     : unknown


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


Subject    : ThinkPad R60: suspend broken
References : http://lkml.org/lkml/2007/3/16/57
Submitter  : Marcus Better <marcus@better.se>
Status     : unknown


Subject    : laptop immediately resumes after suspend
References : http://lkml.org/lkml/2007/3/8/469
Submitter  : Ray Lee <ray-lk@madrabbit.org>
Caused-By  : Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
             commit ed41dab90eb40ac4911e60406bc653661f0e4ce1
Handled-By : Len Brown <lenb@kernel.org>
Patch      : http://lkml.org/lkml/2007/3/12/228
Status     : patch available


Subject    : second suspend to disk in a row results in an oops  (libata?)
References : http://lkml.org/lkml/2007/3/17/43
Submitter  : Thomas Meyer <thomas@m3y3r.de>
Status     : unknown


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

[4/6] 2.6.21-rc4: known regressions

[Adrian Bunk]

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    : suspend/resume hangs (until keypress)  (CONFIG_NO_HZ)
References : http://bugzilla.kernel.org/show_bug.cgi?id=8181
             http://lkml.org/lkml/2007/3/11/112
Submitter  : Tomas Janousek <tomi@nomi.cz>
             Thomas Meyer <thomas@m3y3r.de>
             Milan Broz <mbroz@redhat.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Patch      : http://lkml.org/lkml/2007/3/16/406
Status     : patch available


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     : problem is being debugged


Subject    : first disk access after resume takes several minutes
             ('date' does not advance after resume from RAM, CONFIG_NO_HZ=n)
References : http://lkml.org/lkml/2007/3/8/117
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
             Ingo Molnar <mingo@elte.hu>
Status     : problem is being debugged


Subject    : after resume: X hangs after drawing a couple of windows
References : http://lkml.org/lkml/2007/3/8/117
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
Status     : unknown

[4/6] 2.6.21-rc4: known regressions

[Adrian Bunk]

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    : suspend/resume hangs (until keypress)  (CONFIG_NO_HZ)
References : http://bugzilla.kernel.org/show_bug.cgi?id=8181
             http://lkml.org/lkml/2007/3/11/112
Submitter  : Tomas Janousek <tomi@nomi.cz>
             Thomas Meyer <thomas@m3y3r.de>
             Milan Broz <mbroz@redhat.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Patch      : http://lkml.org/lkml/2007/3/16/406
Status     : patch available


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     : problem is being debugged


Subject    : first disk access after resume takes several minutes
             ('date' does not advance after resume from RAM, CONFIG_NO_HZ=n)
References : http://lkml.org/lkml/2007/3/8/117
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
             Ingo Molnar <mingo@elte.hu>
Status     : problem is being debugged


Subject    : after resume: X hangs after drawing a couple of windows
References : http://lkml.org/lkml/2007/3/8/117
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
Status     : unknown

[5/6] 2.6.21-rc4: known regressions

[Adrian Bunk]

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    : Dynticks and High resolution Timer hanging the system
             workaround: clocksource=acpi_pm
References : http://lkml.org/lkml/2007/3/7/504
Submitter  : Stephane Casset <sept@logidee.com>
Caused-By  : Thomas Gleixner <tglx@linutronix.de>
Status     : unknown


Subject    : soft lockup detected on CPU#0
References : http://lkml.org/lkml/2007/3/3/152
Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
             Ingo Molnar <mingo@elte.hu>
Status     : unknown


Subject    : dynticks makes ksoftirqd1 use unreasonable amount of cpu time
References : http://bugzilla.kernel.org/show_bug.cgi?id=8100
Submitter  : Emil Karlson <jkarlson@cc.hut.fi>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Status     : problem is being debugged


Subject    : i386: APIC timer disabled due to verification failure
             (once in three boots or so)
References : http://lkml.org/lkml/2007/3/16/126
Submitter  : Maxim Levitsky <maximlevitsky@gmail.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Patch      : http://lkml.org/lkml/2007/3/16/420
Status     : patch available

[6/6] 2.6.21-rc4: known regressions

[Adrian Bunk]

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    : ipv6 crash
References : http://lkml.org/lkml/2007/3/10/2
Submitter  : Len Brown <lenb@kernel.org>
Status     : unknown


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>
Status     : submitter was asked to test a patch


Subject    : snd_intel8x0: divide error: 0000
References : http://lkml.org/lkml/2007/3/5/252
Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Handled-By : Takashi Iwai <tiwai@suse.de>
Status     : problem is being debugged


Subject    : snd-intel8x0: no 3d surround sound
References : http://lkml.org/lkml/2007/3/5/164
Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Caused-By  : Randy Cushman <rcushman_linux@earthlink.net>
             commit 831466f4ad2b5fe23dff77edbe6a7c244435e973
Handled-By : Takashi Iwai <tiwai@suse.de>
Status     : patch available


Subject    : Oops in __nodemgr_remove_host_dev
References : http://lkml.org/lkml/2007/3/14/4
             http://lkml.org/lkml/2007/3/18/87
Submitter  : Ismail Dönmez <ismail@pardus.org.tr>
             Stefan Richter <stefanr@s5r6.in-berlin.de>
             Thomas Meyer <thomas@m3y3r.de>
Caused-By  : Greg Kroah-Hartman <gregkh@suse.de>
             commit 43cb76d91ee85f579a69d42bc8efc08bac560278
             commit 40cf67c5fcc513406558c01b91129280208e57bf
Handled-By : Stefan Richter <stefanr@s5r6.in-berlin.de>
Status     : problem is being debugged


Subject    : USB: Oops when connecting USB 1.1 docks
References : http://lkml.org/lkml/2007/3/4/266
Submitter  : Mark Lord <lkml@rtr.ca>
Caused-By  : Jim Radford <radford@blackbean.org>
             commit d9a7ecacac5f8274d2afce09aadcf37bdb42b93a
Handled-By : Oliver Neukum <oneukum@suse.de>
             Jim Radford <radford@blackbean.org>
Patch      : http://lkml.org/lkml/2007/3/13/217
Status     : patch available


Subject    : Possible "struct pid" leak from tty_io.c
References : http://lkml.org/lkml/2007/3/8/222
Submitter  : Catalin Marinas <catalin.marinas@gmail.com>
Caused-By  : Eric W. Biederman <ebiederm@xmission.com>
             commit ab521dc0f8e117fd808d3e425216864d60390500
Handled-By : Eric W. Biederman <ebiederm@xmission.com>
Status     : problem is being debugged

[6/6] 2.6.21-rc4: known regressions

[Adrian Bunk]

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    : ipv6 crash
References : http://lkml.org/lkml/2007/3/10/2
Submitter  : Len Brown <lenb@kernel.org>
Status     : unknown


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>
Status     : submitter was asked to test a patch


Subject    : snd_intel8x0: divide error: 0000
References : http://lkml.org/lkml/2007/3/5/252
Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Handled-By : Takashi Iwai <tiwai@suse.de>
Status     : problem is being debugged


Subject    : snd-intel8x0: no 3d surround sound
References : http://lkml.org/lkml/2007/3/5/164
Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Caused-By  : Randy Cushman <rcushman_linux@earthlink.net>
             commit 831466f4ad2b5fe23dff77edbe6a7c244435e973
Handled-By : Takashi Iwai <tiwai@suse.de>
Status     : patch available


Subject    : Oops in __nodemgr_remove_host_dev
References : http://lkml.org/lkml/2007/3/14/4
             http://lkml.org/lkml/2007/3/18/87
Submitter  : Ismail Dönmez <ismail@pardus.org.tr>
             Stefan Richter <stefanr@s5r6.in-berlin.de>
             Thomas Meyer <thomas@m3y3r.de>
Caused-By  : Greg Kroah-Hartman <gregkh@suse.de>
             commit 43cb76d91ee85f579a69d42bc8efc08bac560278
             commit 40cf67c5fcc513406558c01b91129280208e57bf
Handled-By : Stefan Richter <stefanr@s5r6.in-berlin.de>
Status     : problem is being debugged


Subject    : USB: Oops when connecting USB 1.1 docks
References : http://lkml.org/lkml/2007/3/4/266
Submitter  : Mark Lord <lkml@rtr.ca>
Caused-By  : Jim Radford <radford@blackbean.org>
             commit d9a7ecacac5f8274d2afce09aadcf37bdb42b93a
Handled-By : Oliver Neukum <oneukum@suse.de>
             Jim Radford <radford@blackbean.org>
Patch      : http://lkml.org/lkml/2007/3/13/217
Status     : patch available


Subject    : Possible "struct pid" leak from tty_io.c
References : http://lkml.org/lkml/2007/3/8/222
Submitter  : Catalin Marinas <catalin.marinas@gmail.com>
Caused-By  : Eric W. Biederman <ebiederm@xmission.com>
             commit ab521dc0f8e117fd808d3e425216864d60390500
Handled-By : Eric W. Biederman <ebiederm@xmission.com>
Status     : problem is being debugged

Re: appletouch quirk doesn't run at resume

[Thomas Meyer]

Jiri Kosina schrieb:
> On Sun, 18 Mar 2007, Adrian Bunk wrote:
>
>   
> Thomas, could you please provide more information? Did it ever work for 
> you after suspend/resume cycle and it just broke at some point in the 
> past, or you are not sure whether it ever worked?
>   
I'm not sure whether this ever worked.
> Also, what exactly does it mean that it doesn't work? Are both the 
> interfaces after resume bound to usbhid driver (you can check this in 
> /sys)? When the quirk works correctly, only the keyboard interface should 
> be bound to usbhid driver. Please check the binding both before and after 
> suspend/resume cycle, and let me know.
>   
Appletouch is bound to the device:

T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  7 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=05ac ProdID=0218 Rev= 0.60
S:  Manufacturer=Apple Computer
S:  Product=Apple Internal Keyboard / Trackpad
C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr= 40mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=01 Driver=usbhid
E:  Ad=83(I) Atr=03(Int.) MxPS=   8 Ivl=8ms
I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=02 Driver=appletouch
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=8ms
I:* If#= 2 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
E:  Ad=84(I) Atr=03(Int.) MxPS=   1 Ivl=8ms


But the X server touchpad driver doesn't work anymore, that means i
can't emulte a right click by tapping with 3 fingers on the mouse pad.
after restarting x the mouse driver works again. So i think this is
maybe a problem in X?

Re: [5/6] 2.6.21-rc4: known regressions

[Maxim]

> Subject    : i386: APIC timer disabled due to verification failure
>              (once in three boots or so)
> References : http://lkml.org/lkml/2007/3/16/126
> Submitter  : Maxim Levitsky <maximlevitsky@gmail.com>
> Handled-By : Thomas Gleixner <tglx@linutronix.de>
> Patch      : http://lkml.org/lkml/2007/3/16/420
> Status     : patch available
> 
> 
> 

Hello,

This one is a small issue, I got bigger ones: as I said change in code order in suspend code broke both suspend to ram and disk

Those are commits.
        e3c7db621bed4afb8e231cb005057f2feb5db557 - [PATCH] [PATCH] PM: Change code ordering in main.c (breaks  S3)
        ed746e3b18f4df18afa3763155972c5835f284c5 - [PATCH] [PATCH] swsusp: Change code ordering in disk.c (breaks swsusp, I don't use it, but I tested it)
        259130526c267550bc365d3015917d90667732f1 - [PATCH] [PATCH] swsusp: Change code ordering in user.c (breaks uswsusp, that I use)

System freezes before suspend with those commits, even before suspend to disk.

I think that is is not so good idea to tell about all bugs in single letter ;-)

Regards,
	Maxim Levitsky

Re: [5/6] 2.6.21-rc4: known regressions

[Adrian Bunk]

On Sun, Mar 18, 2007 at 09:07:01PM +0200, Maxim wrote:
> > Subject    : i386: APIC timer disabled due to verification failure
> >              (once in three boots or so)
> > References : http://lkml.org/lkml/2007/3/16/126
> > Submitter  : Maxim Levitsky <maximlevitsky@gmail.com>
> > Handled-By : Thomas Gleixner <tglx@linutronix.de>
> > Patch      : http://lkml.org/lkml/2007/3/16/420
> > Status     : patch available
> 
> Hello,
> 
> This one is a small issue, I got bigger ones: as I said change in code order in suspend code broke both suspend to ram and disk
> 
> Those are commits.
>         e3c7db621bed4afb8e231cb005057f2feb5db557 - [PATCH] [PATCH] PM: Change code ordering in main.c (breaks  S3)
>         ed746e3b18f4df18afa3763155972c5835f284c5 - [PATCH] [PATCH] swsusp: Change code ordering in disk.c (breaks swsusp, I don't use it, but I tested it)
>         259130526c267550bc365d3015917d90667732f1 - [PATCH] [PATCH] swsusp: Change code ordering in user.c (breaks uswsusp, that I use)
> 
> System freezes before suspend with those commits, even before suspend to disk.

This was in my list as

Subject    : suspend to disk hangs
References : http://lkml.org/lkml/2007/3/16/126
Submitter  : Maxim Levitsky <maximlevitsky@gmail.com>
Status     : unknown

But I should add your bisecting information there.

> I think that is is not so good idea to tell about all bugs in single letter ;-)

These were 6 emails.

And they should give an overview as complete as possible of all 
currently known regressions.

> Regards,
> 	Maxim Levitsky

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: appletouch quirk doesn't run at resume

[Jiri Kosina]

On Sun, 18 Mar 2007, Thomas Meyer wrote:

> Appletouch is bound to the device:

OK, so the quirk actually works fine ...

> But the X server touchpad driver doesn't work anymore, that means i 
> can't emulte a right click by tapping with 3 fingers on the mouse pad. 
> after restarting x the mouse driver works again. So i think this is 
> maybe a problem in X?

... but there is something apparently wrong either with the appletouch 
driver or X. Could you test via evtest whether the events are properly 
generated by the kernel? If they do, I'd say it is almost certainly X bug.

Thanks,

-- 
Jiri Kosina

Re: [2/6] 2.6.21-rc4: known regressions

[Andi Kleen]

On Sun, Mar 18, 2007 at 07:49:15PM +0100, Adrian Bunk wrote:
> References : http://bugzilla.kernel.org/show_bug.cgi?id=8161
> Submitter  : Vladimir Brik <no.hope@gmail.com>
> Handled-By : Andi Kleen <ak@muc.de>
> Status     : patch available

Patch is in Linus' tree now.

-Andi

Re: [3/6] 2.6.21-rc4: known regressions

[Marcus Better]

[-- Attachment #1.1: Type: text/plain, Size: 353 bytes --]

> Subject    : ThinkPad R60: suspend broken
> References : http://lkml.org/lkml/2007/3/16/57
> Submitter  : Marcus Better <marcus@better.se>
> Status     : unknown

FWIW, it's still broken as of commit cd05a1f818073a623455a58e756c5b419fc98db9.

The in-kernel suspend to disk or RAM both hang after "Suspending consoles", 
with the fan stopped.

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

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

Re: [5/6] 2.6.21-rc4: known regressions

[Maxim]

On Sunday 18 March 2007 21:22:19 Adrian Bunk wrote:
> On Sun, Mar 18, 2007 at 09:07:01PM +0200, Maxim wrote:
> > > Subject    : i386: APIC timer disabled due to verification failure
> > >              (once in three boots or so)
> > > References : http://lkml.org/lkml/2007/3/16/126
> > > Submitter  : Maxim Levitsky <maximlevitsky@gmail.com>
> > > Handled-By : Thomas Gleixner <tglx@linutronix.de>
> > > Patch      : http://lkml.org/lkml/2007/3/16/420
> > > Status     : patch available
> > 
> > Hello,
> > 
> > This one is a small issue, I got bigger ones: as I said change in code order in suspend code broke both suspend to ram and disk
> > 
> > Those are commits.
> >         e3c7db621bed4afb8e231cb005057f2feb5db557 - [PATCH] [PATCH] PM: Change code ordering in main.c (breaks  S3)
> >         ed746e3b18f4df18afa3763155972c5835f284c5 - [PATCH] [PATCH] swsusp: Change code ordering in disk.c (breaks swsusp, I don't use it, but I tested it)
> >         259130526c267550bc365d3015917d90667732f1 - [PATCH] [PATCH] swsusp: Change code ordering in user.c (breaks uswsusp, that I use)
> > 
> > System freezes before suspend with those commits, even before suspend to disk.
> 
> This was in my list as
> 
> Subject    : suspend to disk hangs
> References : http://lkml.org/lkml/2007/3/16/126
> Submitter  : Maxim Levitsky <maximlevitsky@gmail.com>
> Status     : unknown
> 
> But I should add your bisecting information there.
> 
> > I think that is is not so good idea to tell about all bugs in single letter ;-)

You didn't understand me, I wanted to say that I sent a email with subject line 
"[BUG] 2.6.21-rc1,2,3 regressions on my system that I found so far"

And I think now that I did wrong that I put all regressions and bugs I found here, but not in separate emails
Anyway it is not a problem

And by the way suspend to ram also hangs and hangs before suspend (Disk powers down, screen too, but fans are on, and etc...)
Reverting those fixes it.

> 
> These were 6 emails.
> 
> And they should give an overview as complete as possible of all 
> currently known regressions.
> 
> > Regards,
> > 	Maxim Levitsky
> 
> cu
> Adrian
> 

Re: [5/6] 2.6.21-rc4: known regressions

[Maxim]

On Sunday 18 March 2007 21:59:42 Maxim wrote:
> On Sunday 18 March 2007 21:22:19 Adrian Bunk wrote:
> > On Sun, Mar 18, 2007 at 09:07:01PM +0200, Maxim wrote:
> > > > Subject    : i386: APIC timer disabled due to verification failure
> > > >              (once in three boots or so)
> > > > References : http://lkml.org/lkml/2007/3/16/126
> > > > Submitter  : Maxim Levitsky <maximlevitsky@gmail.com>
> > > > Handled-By : Thomas Gleixner <tglx@linutronix.de>
> > > > Patch      : http://lkml.org/lkml/2007/3/16/420
> > > > Status     : patch available
> > > 
> > > Hello,
> > > 
> > > This one is a small issue, I got bigger ones: as I said change in code order in suspend code broke both suspend to ram and disk
> > > 
> > > Those are commits.
> > >         e3c7db621bed4afb8e231cb005057f2feb5db557 - [PATCH] [PATCH] PM: Change code ordering in main.c (breaks  S3)
> > >         ed746e3b18f4df18afa3763155972c5835f284c5 - [PATCH] [PATCH] swsusp: Change code ordering in disk.c (breaks swsusp, I don't use it, but I tested it)
> > >         259130526c267550bc365d3015917d90667732f1 - [PATCH] [PATCH] swsusp: Change code ordering in user.c (breaks uswsusp, that I use)
> > > 
> > > System freezes before suspend with those commits, even before suspend to disk.
> > 
> > This was in my list as
> > 
> > Subject    : suspend to disk hangs
> > References : http://lkml.org/lkml/2007/3/16/126
> > Submitter  : Maxim Levitsky <maximlevitsky@gmail.com>
> > Status     : unknown
> > 
> > But I should add your bisecting information there.
> > 
> > > I think that is is not so good idea to tell about all bugs in single letter ;-)
> 
> You didn't understand me, I wanted to say that I sent a email with subject line 
> "[BUG] 2.6.21-rc1,2,3 regressions on my system that I found so far"
> 
> And I think now that I did wrong that I put all regressions and bugs I found here, but not in separate emails
> Anyway it is not a problem
> 
> And by the way suspend to ram also hangs and hangs before suspend (Disk powers down, screen too, but fans are on, and etc...)
> Reverting those fixes it.
> 
> > 
> > These were 6 emails.
> > 
> > And they should give an overview as complete as possible of all 
> > currently known regressions.
> > 
> > > Regards,
> > > 	Maxim Levitsky
> > 
> > cu
> > Adrian
> > 
> 
> 
> 

oops, ;-)

Regards,
	Maxim Levitsky

Re: Linux 2.6.21-rc4

[Randy Dunlap]

On Sun, 18 Mar 2007 13:39:45 +0100 Sam Ravnborg wrote:

> On Sat, Mar 17, 2007 at 07:43:40AM +0100, Sam Ravnborg wrote:
> > On Fri, Mar 16, 2007 at 03:39:57PM -0700, Randy Dunlap wrote:
> > > On Fri, 16 Mar 2007 14:11:21 -0700 Randy Dunlap wrote:
> > > 
> > > > On Fri, 16 Mar 2007 09:33:54 -0700 (PDT) Linus Torvalds wrote:
> > > > 
> > > > > 
> > > > > I pushed out the -git trees yesterday, but then got distracted, so the 
> > > > > patches and tar-balls and the announcement got delayed until this morning. 
> > > > > Oops. I'm a scatter-brain.
> > > > 
> > > > allmodconfig on i386:
> > > > 
> > > > WARNING: "default_idle" [arch/i386/kernel/apm.ko] undefined!
> > > > WARNING: "machine_real_restart" [arch/i386/kernel/apm.ko] undefined!
> > > > make[1]: *** [__modpost] Error 1
> > > > make: *** [modules] Error 2
> > > 
> > > Please ignore.
> > > 
> > > I think that this was the result of doing 'make allyesconfig && make all'
> > > followed by 'make allmodconfig && make all' without doing a 'make clean'
> > > between them.
> > But then we have a dependency error somewhere we need to track down.
> > I will try to test here.
> 
> So far no luck in reproducing this.
> I will await additional reports before looking more into this one.

Hi Sam,
It's reproducible for me.

(I'm on x86_64:)

make clean
make ARCH=i386 allyesconfig
make ARCH=i386 all
make ARCH=i386 allmodconfig
make ARCH=i386 all

What kind of debug info do you want/need on this?

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [2/6] 2.6.21-rc4: known regressions

[Randy Dunlap]

On Sun, 18 Mar 2007 19:49:15 +0100 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.
> 
> 
> Subject    : x86_64: boot hangs unless CONFIG_PCIEPORTBUS=n and acpi=off
> References : http://bugzilla.kernel.org/show_bug.cgi?id=8162
> Submitter  : Randy Dunlap <randy.dunlap@oracle.com>
> Status     : unknown

Bug is rejected due to user error.
This seems to be a netconsole hang, not ACPI.

---
~Randy

Re: [2/6] 2.6.21-rc4: known regressions

[Adrian Bunk]

On Mon, Mar 19, 2007 at 09:06:57AM -0700, Randy Dunlap wrote:
> On Sun, 18 Mar 2007 19:49:15 +0100 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.
> > 
> > 
> > Subject    : x86_64: boot hangs unless CONFIG_PCIEPORTBUS=n and acpi=off
> > References : http://bugzilla.kernel.org/show_bug.cgi?id=8162
> > Submitter  : Randy Dunlap <randy.dunlap@oracle.com>
> > Status     : unknown
> 
> Bug is rejected due to user error.
> This seems to be a netconsole hang, not ACPI.

Thanks for this information.

Is the netconsole hang a regression?

> ~Randy

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2/6] 2.6.21-rc4: known regressions

[Randy Dunlap]

Adrian Bunk wrote:
> On Mon, Mar 19, 2007 at 09:06:57AM -0700, Randy Dunlap wrote:
>> On Sun, 18 Mar 2007 19:49:15 +0100 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.
>>>
>>>
>>> Subject    : x86_64: boot hangs unless CONFIG_PCIEPORTBUS=n and acpi=off
>>> References : http://bugzilla.kernel.org/show_bug.cgi?id=8162
>>> Submitter  : Randy Dunlap <randy.dunlap@oracle.com>
>>> Status     : unknown
>> Bug is rejected due to user error.
>> This seems to be a netconsole hang, not ACPI.
> 
> Thanks for this information.
> 
> Is the netconsole hang a regression?

I have to do more debugging to find out what is going on.  It may be
PCIEPORTBUS-related, but 2.6.20 or later now boot for me without
netconsole and hang when using netconsole.  The ending lines in the console
log are:

[   17.946918] PCI: Setting latency timer of device 0000:00:02.0 to 64
[   17.953211] assign_interrupt_mode Found MSI capability
[   17.958388] Allocate Port Service[0000:00:02.0:pcie00]
[   17.963565] Allocate Port Service[0000:00:02.0:pcie01]
[   17.968736] Allocate Port Service[0000:00:02.0:pcie02]
[   17.973903] Allocate Port Service[0000:00:02.0:pcie03]
[   17.979134] PCI: Setting latency timer of device 0000:00:03.0 to 64
[   17.985430] assign_interrupt_mode Found MSI capability
[   17.990565] Losing some ticks... checking if CPU frequency changed.
[   17.996857] Allocate Port Service[0000:00:03.0:pcie00]
[   18.002013] Allocate Port Service[0000:00:03.0:pcie01]
[   18.007175] Allocate Port Service[0000:00:03.0:pcie02]
[   18.012336] Allocate Port Service[0000:00:03.0:pcie03]
[   18.017552] PCI: Setting latency timer of device 0000:00:03.1 to 64
[   18.023848] assign_interrupt_mode Found MSI capability
[   18.029012] Allocate Port Service[0000:00:03.1:pcie00]


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

2.6.21-rc4: known regressions with patches available

[Adrian Bunk]

Let's not bore people running -rc kernels with regressions that have 
patches available - let's get this patches into the tree for giving 
them the pure exciting experience of the many unfixed regressions.


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    : acpi_serialize locks system during boot
References : http://bugzilla.kernel.org/show_bug.cgi?id=8171
Submitter  : Colchao <colchaodemola@gmail.com>
Handled-By : Len Brown <len.brown@intel.com>
Patch      : http://bugzilla.kernel.org/show_bug.cgi?id=8171
Status     : patch available


Subject    : laptop immediately resumes after suspend
References : http://lkml.org/lkml/2007/3/8/469
Submitter  : Ray Lee <ray-lk@madrabbit.org>
Caused-By  : Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
             commit ed41dab90eb40ac4911e60406bc653661f0e4ce1
Handled-By : Len Brown <lenb@kernel.org>
Patch      : http://lkml.org/lkml/2007/3/12/228
Status     : patch available


Subject    : suspend/resume hangs (until keypress)  (CONFIG_NO_HZ)
References : http://bugzilla.kernel.org/show_bug.cgi?id=8181
             http://lkml.org/lkml/2007/3/11/112
Submitter  : Tomas Janousek <tomi@nomi.cz>
             Thomas Meyer <thomas@m3y3r.de>
             Milan Broz <mbroz@redhat.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Patch      : http://lkml.org/lkml/2007/3/16/406
Status     : patch available


Subject    : snd-intel8x0: no 3d surround sound
References : http://lkml.org/lkml/2007/3/5/164
Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Caused-By  : Randy Cushman <rcushman_linux@earthlink.net>
             commit 831466f4ad2b5fe23dff77edbe6a7c244435e973
Handled-By : Takashi Iwai <tiwai@suse.de>
Status     : patch available


Subject    : USB: Oops when connecting USB 1.1 docks
References : http://lkml.org/lkml/2007/3/4/266
Submitter  : Mark Lord <lkml@rtr.ca>
Caused-By  : Jim Radford <radford@blackbean.org>
             commit d9a7ecacac5f8274d2afce09aadcf37bdb42b93a
Handled-By : Oliver Neukum <oneukum@suse.de>
             Jim Radford <radford@blackbean.org>
Patch      : http://lkml.org/lkml/2007/3/13/217
Status     : patch available

2.6.21-rc4: known regressions with patches available

[Adrian Bunk]

Let's not bore people running -rc kernels with regressions that have 
patches available - let's get this patches into the tree for giving 
them the pure exciting experience of the many unfixed regressions.


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    : acpi_serialize locks system during boot
References : http://bugzilla.kernel.org/show_bug.cgi?id=8171
Submitter  : Colchao <colchaodemola@gmail.com>
Handled-By : Len Brown <len.brown@intel.com>
Patch      : http://bugzilla.kernel.org/show_bug.cgi?id=8171
Status     : patch available


Subject    : laptop immediately resumes after suspend
References : http://lkml.org/lkml/2007/3/8/469
Submitter  : Ray Lee <ray-lk@madrabbit.org>
Caused-By  : Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
             commit ed41dab90eb40ac4911e60406bc653661f0e4ce1
Handled-By : Len Brown <lenb@kernel.org>
Patch      : http://lkml.org/lkml/2007/3/12/228
Status     : patch available


Subject    : suspend/resume hangs (until keypress)  (CONFIG_NO_HZ)
References : http://bugzilla.kernel.org/show_bug.cgi?id=8181
             http://lkml.org/lkml/2007/3/11/112
Submitter  : Tomas Janousek <tomi@nomi.cz>
             Thomas Meyer <thomas@m3y3r.de>
             Milan Broz <mbroz@redhat.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Patch      : http://lkml.org/lkml/2007/3/16/406
Status     : patch available


Subject    : snd-intel8x0: no 3d surround sound
References : http://lkml.org/lkml/2007/3/5/164
Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Caused-By  : Randy Cushman <rcushman_linux@earthlink.net>
             commit 831466f4ad2b5fe23dff77edbe6a7c244435e973
Handled-By : Takashi Iwai <tiwai@suse.de>
Status     : patch available


Subject    : USB: Oops when connecting USB 1.1 docks
References : http://lkml.org/lkml/2007/3/4/266
Submitter  : Mark Lord <lkml@rtr.ca>
Caused-By  : Jim Radford <radford@blackbean.org>
             commit d9a7ecacac5f8274d2afce09aadcf37bdb42b93a
Handled-By : Oliver Neukum <oneukum@suse.de>
             Jim Radford <radford@blackbean.org>
Patch      : http://lkml.org/lkml/2007/3/13/217
Status     : patch available

2.6.21-rc4: known regressions with patches available

[Adrian Bunk]

Let's not bore people running -rc kernels with regressions that have 
patches available - let's get this patches into the tree for giving 
them the pure exciting experience of the many unfixed regressions.


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    : acpi_serialize locks system during boot
References : http://bugzilla.kernel.org/show_bug.cgi?id=8171
Submitter  : Colchao <colchaodemola@gmail.com>
Handled-By : Len Brown <len.brown@intel.com>
Patch      : http://bugzilla.kernel.org/show_bug.cgi?id=8171
Status     : patch available


Subject    : laptop immediately resumes after suspend
References : http://lkml.org/lkml/2007/3/8/469
Submitter  : Ray Lee <ray-lk@madrabbit.org>
Caused-By  : Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
             commit ed41dab90eb40ac4911e60406bc653661f0e4ce1
Handled-By : Len Brown <lenb@kernel.org>
Patch      : http://lkml.org/lkml/2007/3/12/228
Status     : patch available


Subject    : suspend/resume hangs (until keypress)  (CONFIG_NO_HZ)
References : http://bugzilla.kernel.org/show_bug.cgi?id=8181
             http://lkml.org/lkml/2007/3/11/112
Submitter  : Tomas Janousek <tomi@nomi.cz>
             Thomas Meyer <thomas@m3y3r.de>
             Milan Broz <mbroz@redhat.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Patch      : http://lkml.org/lkml/2007/3/16/406
Status     : patch available


Subject    : snd-intel8x0: no 3d surround sound
References : http://lkml.org/lkml/2007/3/5/164
Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Caused-By  : Randy Cushman <rcushman_linux@earthlink.net>
             commit 831466f4ad2b5fe23dff77edbe6a7c244435e973
Handled-By : Takashi Iwai <tiwai@suse.de>
Status     : patch available


Subject    : USB: Oops when connecting USB 1.1 docks
References : http://lkml.org/lkml/2007/3/4/266
Submitter  : Mark Lord <lkml@rtr.ca>
Caused-By  : Jim Radford <radford@blackbean.org>
             commit d9a7ecacac5f8274d2afce09aadcf37bdb42b93a
Handled-By : Oliver Neukum <oneukum@suse.de>
             Jim Radford <radford@blackbean.org>
Patch      : http://lkml.org/lkml/2007/3/13/217
Status     : patch available


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [6/6] 2.6.21-rc4: known regressions

[David Miller]

From: Adrian Bunk <bunk@stusta.de>
Date: Sun, 18 Mar 2007 19:49:38 +0100

> Subject    : ipv6 crash
> References : http://lkml.org/lkml/2007/3/10/2
> Submitter  : Len Brown <lenb@kernel.org>
> Status     : unknown

This is caused by some problem in the router round-robin code in
net/ipv6/route.c:rt6_select()

Somehow it NULLs out fn->leaf, and then fib6_add_1() crashes
dererencing that NULL pointer as is seen in the report.

Deleting the router round-robin list mangling code in rt6_select()
makes the crash go away, but such a change causes regressions in the
ipv6 conformance tests.

Thomas Graf discovered this bug some time ago, but we still
haven't come up with a fix suitable for upstream :-/

This bug has been there for a very long time and is not a regression
of 2.6.21

I'll see if I can come up with something to fix this properly.

Re: [PATCH] clockevents: Fix suspend/resume to disk hangs

[Marcus Better]

Thomas Gleixner wrote:

> I finally found a dual core box, which survives suspend/resume without
> crashing in the middle of nowhere. Sigh, I never figured out from the
> code and the bug reports what's going on.
> 
> The observed hangs are caused by a stale state transition of the clock
> event devices, which keeps the RCU synchronization away from completion,
> when the non boot CPU is brought back up.

This didn't fix the suspend problems on my Thinkpad R60. (Sorry for
nagging - please let me know if I can assist in debugging this...)

Marcus

Re: [1/6] 2.6.21-rc4: known regressions

[Tobias Diedrich]

Adrian Bunk wrote:
> This email lists some known regressions in Linus' tree compared to 2.6.20.

Since I didn't see any mention of this:

I'm seeing an Oops when removing the ohci1394 module:

[   16.047275] ieee1394: Node removed: ID:BUS[158717321-38:0860]  GUID[c033ced600000000]
[   16.047287] BUG: unable to handle kernel NULL pointer dereference at virtual address 00000094
[   16.047451]  printing eip:
[   16.047524] c02daf3d
[   16.047527] *pde = 00000000
[   16.047603] Oops: 0000 [#1]
[   16.047676] PREEMPT 
[   16.047788] Modules linked in: backlight ohci1394 parport_pc parport
[   16.048069] CPU:    0
[   16.048071] EIP:    0060:[<c02daf3d>]    Not tainted VLI
[   16.048074] EFLAGS: 00010246   (2.6.21-rc4 #35)
[   16.048298] EIP is at class_device_remove_attrs+0xa/0x30
[   16.048377] eax: dfd04338   ebx: 00000000   ecx: df655988   edx: 00000000
[   16.048456] esi: 00000000   edi: dfd04338   ebp: 00000000   esp: df506e38
[   16.048535] ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
[   16.048614] Process rmmod (pid: 1455, ti=df506000 task=df6cc0b0 task.ti=df506000)
[   16.048693] Stack: dfd04338 dfd04340 00000000 c02db02f 00000000 dfd04338 dfd041e4 c0331871 
[   16.049159]        00000000 c02db065 dfd041b0 c0331858 c055006d 0975d589 00000026 0000035c 
[   16.049626]        00000000 c033ced6 00000000 df24c000 c0331879 c02d859f df24c0bc df24c0bc 
[   16.050091] Call Trace:
[   16.050233]  [<c02db02f>] class_device_del+0xcc/0xfa
[   16.050352]  [<c0331871>] __nodemgr_remove_host_dev+0x0/0xb
[   16.050475]  [<c02db065>] class_device_unregister+0x8/0x10
[   16.050595]  [<c0331858>] nodemgr_remove_ne+0x61/0x7a
[   16.050714]  [<c033ced6>] ether1394_header_cache+0x0/0x43
[   16.050835]  [<c0331879>] __nodemgr_remove_host_dev+0x8/0xb
[   16.050954]  [<c02d859f>] device_for_each_child+0x1a/0x3c
[   16.051073]  [<c0331b98>] nodemgr_remove_host+0x30/0x90
[   16.051192]  [<c032f12c>] __unregister_host+0x1a/0xad
[   16.051311]  [<c032ee17>] hl_get_hostinfo+0x5b/0x76
[   16.051430]  [<c032f34a>] highlevel_remove_host+0x21/0x42
[   16.051549]  [<c032ed9d>] hpsb_remove_host+0x37/0x56
[   16.051668]  [<e0869263>] ohci1394_pci_remove+0x44/0x1c7 [ohci1394]
[   16.051794]  [<c027e5b0>] pci_device_remove+0x16/0x35
[   16.053376]  [<c02da6d7>] __device_release_driver+0x6e/0x8b
[   16.053496]  [<c02dab77>] driver_detach+0xa1/0xde
[   16.053613]  [<c02da33f>] bus_remove_driver+0x57/0x75
[   16.053733]  [<c02dabd4>] driver_unregister+0x8/0x13
[   16.053850]  [<c027e732>] pci_unregister_driver+0xc/0x6e
[   16.053969]  [<c0134d56>] sys_delete_module+0x174/0x19a
[   16.054091]  [<c0113cea>] do_page_fault+0x277/0x525
[   16.054211]  [<c0148b0d>] do_munmap+0x193/0x1ac
[   16.054331]  [<c0103d0c>] syscall_call+0x7/0xb
[   16.054450]  =======================
[   16.054523] Code: ff c3 85 c0 74 08 83 c0 08 e9 9b f8 ea ff b8 ea ff ff ff c3 85 c0 74 08 83 c0 08 e9 b9 db ea ff c3 57 89 c7 56 53 31 db 8b 70 44 <83> be 94 00 00 00 00 75 09 eb 17 89 f8 e8 d7 ff ff ff 89 da 83 
[   16.057248] EIP: [<c02daf3d>] class_device_remove_attrs+0xa/0x30 SS:ESP 0068:df506e38

-- 
Tobias						PGP: http://9ac7e0bc.uguu.de

Re: [Alsa-devel] 2.6.21-rc4: known regressions with patches available

[Takashi Iwai]

At Mon, 19 Mar 2007 21:39:43 +0100,
Adrian Bunk wrote:
> 
> Subject    : snd-intel8x0: no 3d surround sound
> References : http://lkml.org/lkml/2007/3/5/164
> Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
> Caused-By  : Randy Cushman <rcushman_linux@earthlink.net>
>              commit 831466f4ad2b5fe23dff77edbe6a7c244435e973
> Handled-By : Takashi Iwai <tiwai@suse.de>
> Status     : patch available

The patch was already merged after rc4.


thanks,

Takashi

Re: [1/6] 2.6.21-rc4: known regressions

[Adrian Bunk]

On Tue, Mar 20, 2007 at 11:24:41AM +0100, Tobias Diedrich wrote:
> Adrian Bunk wrote:
> > This email lists some known regressions in Linus' tree compared to 2.6.20.
> 
> Since I didn't see any mention of this:
> 
> I'm seeing an Oops when removing the ohci1394 module:
> 
> [   16.047275] ieee1394: Node removed: ID:BUS[158717321-38:0860]  GUID[c033ced600000000]
> [   16.047287] BUG: unable to handle kernel NULL pointer dereference at virtual address 00000094
> [   16.047451]  printing eip:
> [   16.047524] c02daf3d
> [   16.047527] *pde = 00000000
> [   16.047603] Oops: 0000 [#1]
> [   16.047676] PREEMPT 
> [   16.047788] Modules linked in: backlight ohci1394 parport_pc parport
> [   16.048069] CPU:    0
> [   16.048071] EIP:    0060:[<c02daf3d>]    Not tainted VLI
> [   16.048074] EFLAGS: 00010246   (2.6.21-rc4 #35)
> [   16.048298] EIP is at class_device_remove_attrs+0xa/0x30
> [   16.048377] eax: dfd04338   ebx: 00000000   ecx: df655988   edx: 00000000
> [   16.048456] esi: 00000000   edi: dfd04338   ebp: 00000000   esp: df506e38
> [   16.048535] ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
> [   16.048614] Process rmmod (pid: 1455, ti=df506000 task=df6cc0b0 task.ti=df506000)
> [   16.048693] Stack: dfd04338 dfd04340 00000000 c02db02f 00000000 dfd04338 dfd041e4 c0331871 
> [   16.049159]        00000000 c02db065 dfd041b0 c0331858 c055006d 0975d589 00000026 0000035c 
> [   16.049626]        00000000 c033ced6 00000000 df24c000 c0331879 c02d859f df24c0bc df24c0bc 
> [   16.050091] Call Trace:
> [   16.050233]  [<c02db02f>] class_device_del+0xcc/0xfa
> [   16.050352]  [<c0331871>] __nodemgr_remove_host_dev+0x0/0xb
>...
> [   16.057248] EIP: [<c02daf3d>] class_device_remove_attrs+0xa/0x30 SS:ESP 0068:df506e38
>...

You missed the following entry in my list [1]:

Subject    : Oops in __nodemgr_remove_host_dev
References : http://lkml.org/lkml/2007/3/14/4
             http://lkml.org/lkml/2007/3/18/87
Submitter  : Ismail Dönmez <ismail@pardus.org.tr>
             Stefan Richter <stefanr@s5r6.in-berlin.de>
             Thomas Meyer <thomas@m3y3r.de>
Caused-By  : Greg Kroah-Hartman <gregkh@suse.de>
             commit 43cb76d91ee85f579a69d42bc8efc08bac560278
             commit 40cf67c5fcc513406558c01b91129280208e57bf
Handled-By : Stefan Richter <stefanr@s5r6.in-berlin.de>
Status     : problem is being debugged


cu
Adrian

[1] not meant as an offence - there are so many items in the list
    that it's easy to miss one

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2/6] 2.6.21-rc4: known regressions

[Ray Lee]

Adrian Bunk wrote:
> This email lists some known regressions in Linus' tree compared to 2.6.20.
[...]
> Subject    : ACPI regression with noapic
> References : http://lkml.org/lkml/2007/3/8/468
> Submitter  : Ray Lee <ray-lk@madrabbit.org>
> Status     : unknown

I finally have time to start bisecting this. I'll have something in the
next day.

Ray

Re: [PATCH] clockevents: Fix suspend/resume to disk hangs

[Thomas Gleixner]

On Tue, 2007-03-20 at 10:35 +0100, Marcus Better wrote:
> Thomas Gleixner wrote:
> 
> > I finally found a dual core box, which survives suspend/resume without
> > crashing in the middle of nowhere. Sigh, I never figured out from the
> > code and the bug reports what's going on.
> > 
> > The observed hangs are caused by a stale state transition of the clock
> > event devices, which keeps the RCU synchronization away from completion,
> > when the non boot CPU is brought back up.
> 
> This didn't fix the suspend problems on my Thinkpad R60. (Sorry for
> nagging - please let me know if I can assist in debugging this...)

I did not expect that it fixes your problem. clockevents are only used
in arch/i386 right now. You are running a 64 bit kernel, so a change of
your problem would have been very surprising.

You said, that the breakage came between 2.6.20 and rc2. Can you bisect
it ?

	tglx

Re: [1/6] 2.6.21-rc4: known regressions

[Linus Torvalds]

On Sun, 18 Mar 2007, Adrian Bunk wrote:
> 
> Subject    : weird system hangs
> References : http://lkml.org/lkml/2007/3/16/288
> Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
>              Mariusz Kozlowski <m.kozlowski@tuxland.pl>
> Status     : unknown

According to the console log, it seems to be hung because a lot of 
processes are stuck in D state in various variations of this:

	Call Trace:
	 [<c01ba134>] start_this_handle+0x2d7/0x355
	 [<c01ba265>] journal_start+0xb3/0xe1
	 [<c01b2837>] ext3_journal_start_sb+0x48/0x4a
	 [<c01b0924>] ext3_create+0x47/0xe2
	 [<c017820c>] vfs_create+0xcd/0x13e
	 [<c017ab6e>] open_namei+0x176/0x5b5
	 [<c0170026>] do_filp_open+0x26/0x3b
	 [<c017007e>] do_sys_open+0x43/0xc2
	 [<c0170135>] sys_open+0x1c/0x1e
	 [<c0104064>] syscall_call+0x7/0xb

and then you have "kget" (whatever that is) which is doing

	Call Trace:
	 [<c0318981>] schedule_timeout+0x70/0x8e
	 [<c03189b4>] schedule_timeout_uninterruptible+0x15/0x17
	 [<c01b964a>] journal_stop+0xe2/0x1e6
	 [<c01ba2b0>] journal_force_commit+0x1d/0x1f
	 [<c01b29fb>] ext3_force_commit+0x22/0x24
	 [<c01ad607>] ext3_write_inode+0x34/0x3a
	 [<c0189f74>] __writeback_single_inode+0x1c5/0x2cb
	 [<c018a096>] sync_inode+0x1c/0x2e
	 [<c01a9ff7>] ext3_sync_file+0xab/0xc0
	 [<c018c8c5>] do_fsync+0x4b/0x98
	 [<c018c932>] __do_fsync+0x20/0x2f
	 [<c018c951>] sys_fdatasync+0x10/0x12
	 [<c0104064>] syscall_call+0x7/0xb

with kjournald in D sleep at

	 [<c01bb7b2>] journal_commit_transaction+0x15d/0x11d3
	 [<c01bfcbe>] kjournald+0xab/0x1e8
	 [<c01333dd>] kthread+0xb5/0xe0
	 [<c0104cd3>] kernel_thread_helper+0x7/0x10

which certainly looks like something is waiting for an IO to finish.

In contrast, the hang reported by Mariusz Kozlowski has a slightly 
different feel to it, but there's a tantalizing pattern in there too:

  http://www.ussg.iu.edu/hypermail/linux/kernel/0703.0/1243.html

	Call Trace:
	[<c03ec87e>] io_schedule+0x42/0x59
	[<c0184915>] sleep_on_buffer+0x8/0xc
	[<c03ed217>] __wait_on_bit+0x47/0x6c
	[<c03ed297>] out_of_line_wait_on_bit+0x5b/0x64
	[<c01848a8>] __wait_on_buffer+0x27/0x2d
	[<c01b4228>] journal_commit_transaction+0x707/0x127f
	[<c01b868b>] kjournald+0xac/0x1ed
	[<c0126af5>] kthread+0xa2/0xc9
	[<c010422b>] kernel_thread_helper+0x7/0x1c

which certainly also looks like an IO never completed (or completed but 
never woke anything up).

It also seems to be related to *buffers*. Maybe the whole bh layer thing 
is a fluke, but it's not waiting for normal data, it's very much waiting 
for those journal things that all use buffer heads.Which just makes me 
worry about those patches by Nick (which did come in through Andrew). I 
don't think it's the memorder one (it looks safe and shouldn't matter on 
x86 anyway!), but what about the

	fs: fix __block_write_full_page error case buffer submission

locking change for example? Or that "fs: fix nobh data leak" thing with 
its fix? It uses "SetPageUptodate(page);" without waking up anybody who 
might wait for it (but the waiters here seem to wait on buffers, so that's 
probably not it)..

Alternatively, maybe it really is an _io_ problem (and the buffer-head 
thing is just a red herring, and it could happen to other IO, it's just 
that metadata IO uses buffer heads), and it's the scheduler changes since 
2.6.20..

Jens, Nick.. Could you take a look?

		Linus

Re: [1/6] 2.6.21-rc4: known regressions

[Nick Piggin]

Linus Torvalds wrote:

> In contrast, the hang reported by Mariusz Kozlowski has a slightly 
> different feel to it, but there's a tantalizing pattern in there too:
> 
>   http://www.ussg.iu.edu/hypermail/linux/kernel/0703.0/1243.html
> 
> 	Call Trace:
> 	[<c03ec87e>] io_schedule+0x42/0x59
> 	[<c0184915>] sleep_on_buffer+0x8/0xc
> 	[<c03ed217>] __wait_on_bit+0x47/0x6c
> 	[<c03ed297>] out_of_line_wait_on_bit+0x5b/0x64
> 	[<c01848a8>] __wait_on_buffer+0x27/0x2d
> 	[<c01b4228>] journal_commit_transaction+0x707/0x127f
> 	[<c01b868b>] kjournald+0xac/0x1ed
> 	[<c0126af5>] kthread+0xa2/0xc9
> 	[<c010422b>] kernel_thread_helper+0x7/0x1c
> 
> which certainly also looks like an IO never completed (or completed but 
> never woke anything up).
> 
> It also seems to be related to *buffers*. Maybe the whole bh layer thing 
> is a fluke, but it's not waiting for normal data, it's very much waiting 
> for those journal things that all use buffer heads.Which just makes me 
> worry about those patches by Nick (which did come in through Andrew). I 
> don't think it's the memorder one (it looks safe and shouldn't matter on 
> x86 anyway!), but what about the
> 
> 	fs: fix __block_write_full_page error case buffer submission
> 
> locking change for example? Or that "fs: fix nobh data leak" thing with 
> its fix? It uses "SetPageUptodate(page);" without waking up anybody who 
> might wait for it (but the waiters here seem to wait on buffers, so that's 
> probably not it)..

Nothing sleeps on PageUptodate, so I don't think that could explain it.

The fs: fix __block_write_full_page error case buffer submission patch
does change the locking, but I'd be really suprised if that was the
problem, because it changes locking to match the regular non-error path
submission.

It could be possible that ext3 is doing something weird and expecting
the old behaviour if it failed get_block, but that seems pretty weird
to do, and would need fixing.

fs: nobh data leak... again hard to see how it could cause an unlock/wakeup
to get lost. Is Mariusz using the nobh mount option?

It wouldn't hurt to test with these patches backed out...

> Alternatively, maybe it really is an _io_ problem (and the buffer-head 
> thing is just a red herring, and it could happen to other IO, it's just 
> that metadata IO uses buffer heads), and it's the scheduler changes since 
> 2.6.20..

I see what you mean. Could it be an ext3 or jbd change I wonder?

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: [PATCH] clockevents: Fix suspend/resume to disk hangs

[Marcus Better]

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

Thomas Gleixner wrote:
> You said, that the breakage came between 2.6.20 and rc2. Can you bisect
> it ?

The XFS workqueue patch [1] fixes my problem [2].

Marcus

[1] http://permalink.gmane.org/gmane.linux.kernel/507616
[2] http://permalink.gmane.org/gmane.linux.kernel/505570

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

Re: [1/6] 2.6.21-rc4: known regressions

[Linus Torvalds]

On Thu, 22 Mar 2007, Nick Piggin wrote:
> 
> Nothing sleeps on PageUptodate, so I don't think that could explain it.

Good point. I forget that we just test "uptodate", but then always sleep 
on "locked".

> The fs: fix __block_write_full_page error case buffer submission patch
> does change the locking, but I'd be really suprised if that was the
> problem, because it changes locking to match the regular non-error path
> submission.

I'd agree, except something clearly has changed ;^)

> > Alternatively, maybe it really is an _io_ problem (and the buffer-head thing
> > is just a red herring, and it could happen to other IO, it's just that
> > metadata IO uses buffer heads), and it's the scheduler changes since
> > 2.6.20..
> 
> I see what you mean. Could it be an ext3 or jbd change I wonder?

jbd hasn't changed since 2.6.20, and the ext3 changes are mostly 
things like const'ness fixes. And others were things like changing 
"journal_current_handle()" into "ext3_journal_current_handle()", which 
looked exciting considering that the hung processes were waiting for the 
journal, but the fact is, that's just an inline function that just calls 
the old function, so..

But interestingly, there *is* a "EA block reference count racing fix" 
that does move a lock_buffer()/unlock_buffer() to cover a bigger area. It 
looks "obviously correct", but maybe there's a deadlock possibility there 
with ext3_forget() or something?

		Linus

Re: [1/6] 2.6.21-rc4: known regressions

[Mariusz Kozłowski]

Hello,

> > In contrast, the hang reported by Mariusz Kozlowski has a slightly 
> > different feel to it, but there's a tantalizing pattern in there too:

Just to make things clear. I didn't say I could reproduce it on 2.6.21-rc4.
In fact I'm running 2.6.21-rc4-mm1 with no problems so far. I just replied
to show my sysrq dumps of processes states with 2.6.21-rc2-mm1.

I could reproduce similar (but still each time slightly different) hangs 
on -mm series from 2.6.20-mm1 to 2.6.21-rc2-mm1. 2.6.21-rc3-mm1 worked well
for me so not sure If my report is still valid here.

Sorry if I didn't make it clear enough.

> >   http://www.ussg.iu.edu/hypermail/linux/kernel/0703.0/1243.html
> > 
> > 	Call Trace:
> > 	[<c03ec87e>] io_schedule+0x42/0x59
> > 	[<c0184915>] sleep_on_buffer+0x8/0xc
> > 	[<c03ed217>] __wait_on_bit+0x47/0x6c
> > 	[<c03ed297>] out_of_line_wait_on_bit+0x5b/0x64
> > 	[<c01848a8>] __wait_on_buffer+0x27/0x2d
> > 	[<c01b4228>] journal_commit_transaction+0x707/0x127f
> > 	[<c01b868b>] kjournald+0xac/0x1ed
> > 	[<c0126af5>] kthread+0xa2/0xc9
> > 	[<c010422b>] kernel_thread_helper+0x7/0x1c
> > 
> > which certainly also looks like an IO never completed (or completed but 
> > never woke anything up).

As I previously noticed each time the system hang I/O activity to disk looked
dead (couldn't even sysrq-s).

> It could be possible that ext3 is doing something weird and expecting

True. I'm using ext3.

> fs: nobh data leak... again hard to see how it could cause an unlock/wakeup
> to get lost. Is Mariusz using the nobh mount option?

No. He is not.

Regards,

	Mariusz Kozlowski

Re: [1/6] 2.6.21-rc4: known regressions

[Mingming Cao]

On Thu, 2007-03-22 at 08:21 -0700, Linus Torvalds wrote:
> 
> On Thu, 22 Mar 2007, Nick Piggin wrote:
> > 
> > Nothing sleeps on PageUptodate, so I don't think that could explain it.
> 
> Good point. I forget that we just test "uptodate", but then always sleep 
> on "locked".
> 
> > The fs: fix __block_write_full_page error case buffer submission patch
> > does change the locking, but I'd be really suprised if that was the
> > problem, because it changes locking to match the regular non-error path
> > submission.
> 
> I'd agree, except something clearly has changed ;^)
> 
> > > Alternatively, maybe it really is an _io_ problem (and the buffer-head thing
> > > is just a red herring, and it could happen to other IO, it's just that
> > > metadata IO uses buffer heads), and it's the scheduler changes since
> > > 2.6.20..
> > 
> > I see what you mean. Could it be an ext3 or jbd change I wonder?
> 
> jbd hasn't changed since 2.6.20, and the ext3 changes are mostly 
> things like const'ness fixes. And others were things like changing 
> "journal_current_handle()" into "ext3_journal_current_handle()", which 
> looked exciting considering that the hung processes were waiting for the 
> journal, but the fact is, that's just an inline function that just calls 
> the old function, so..
> 
> But interestingly, there *is* a "EA block reference count racing fix" 
> that does move a lock_buffer()/unlock_buffer() to cover a bigger area. It 
> looks "obviously correct", but maybe there's a deadlock possibility there 
> with ext3_forget() or something?
> 

I might missed something, so far I can't see a deadlock yet.
If there is a deadlock, I think we should see ext3_xattr_release_block()
and ext3_forget() on the stack. Is this the case?

Regards,
Mingming

> 		Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [1/6] 2.6.21-rc4: known regressions

[Linus Torvalds]

[ Ok, I think it's those timers again...

  Ingo: let me just state how *happy* I am that I told you off when you 
  wanted to merge the hires timers and NO_HZ before 2.6.20 because they 
  were "stable". You were wrong, and 2.6.20 is at least in reasonable 
  shape. Now we just need to make sure that 2.6.21 will be too.. ]

On Thu, 22 Mar 2007, Mingming Cao wrote:
> 
> I might missed something, so far I can't see a deadlock yet.
> If there is a deadlock, I think we should see ext3_xattr_release_block()
> and ext3_forget() on the stack. Is this the case?

No. What's strange is that two (maybe more, I didn't check) processes seem 
to be stuck in

	 [<c0318981>] schedule_timeout+0x70/0x8e
	 [<c03189b4>] schedule_timeout_uninterruptible+0x15/0x17
	 [<c01b964a>] journal_stop+0xe2/0x1e6
	 [<c01ba2b0>] journal_force_commit+0x1d/0x1f
	 [<c01b29fb>] ext3_force_commit+0x22/0x24
	 [<c01ad607>] ext3_write_inode+0x34/0x3a
	 [<c0189f74>] __writeback_single_inode+0x1c5/0x2cb
	 [<c018a096>] sync_inode+0x1c/0x2e
	 [<c01a9ff7>] ext3_sync_file+0xab/0xc0
	 [<c018c8c5>] do_fsync+0x4b/0x98
	 [<c018c932>] __do_fsync+0x20/0x2f
	 [<c018c960>] sys_fsync+0xd/0xf
	 [<c0104064>] syscall_call+0x7/0xb

but that that thing is literally:

		...
                do {
                        old_handle_count = transaction->t_handle_count;
                        schedule_timeout_uninterruptible(1);
                } while (old_handle_count != transaction->t_handle_count);
		...

and especially if nothing is happening, I'd not expect 
"transaction->t_handle_count" to keep changing, so it should stop very 
quickly.

Maybe it's CONFIG_NO_HZ again, and the problem is that timeout, and simply 
no timer tick happening?

Bingo. I think that's it.

	active timers:
	 #0: hardirq_stack, tick_sched_timer, S:01
	 # expires at 9530893000000 nsecs [in -2567889 nsecs]
	 #1: hardirq_stack, hrtimer_wakeup, S:01
	 # expires at 10858649798503 nsecs [in 1327754230614 nsecs]
	  .expires_next   : 9530893000000 nsecs

See

	http://lkml.org/lkml/2007/3/16/288

and that in turn points to the kernel log:

	http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc4/git-console.log

Re: [1/6] 2.6.21-rc4: known regressions

[Nick Piggin]

On Thu, Mar 22, 2007 at 06:40:41PM -0700, Linus Torvalds wrote:
> 
> [ Ok, I think it's those timers again...
> 
>   Ingo: let me just state how *happy* I am that I told you off when you 
>   wanted to merge the hires timers and NO_HZ before 2.6.20 because they 
>   were "stable". You were wrong, and 2.6.20 is at least in reasonable 
>   shape. Now we just need to make sure that 2.6.21 will be too.. ]
> 
> On Thu, 22 Mar 2007, Mingming Cao wrote:
> > 
> > I might missed something, so far I can't see a deadlock yet.
> > If there is a deadlock, I think we should see ext3_xattr_release_block()
> > and ext3_forget() on the stack. Is this the case?
> 
> No. What's strange is that two (maybe more, I didn't check) processes seem 
> to be stuck in
> 
> 	 [<c0318981>] schedule_timeout+0x70/0x8e
> 	 [<c03189b4>] schedule_timeout_uninterruptible+0x15/0x17
> 	 [<c01b964a>] journal_stop+0xe2/0x1e6
> 	 [<c01ba2b0>] journal_force_commit+0x1d/0x1f
> 	 [<c01b29fb>] ext3_force_commit+0x22/0x24
> 	 [<c01ad607>] ext3_write_inode+0x34/0x3a
> 	 [<c0189f74>] __writeback_single_inode+0x1c5/0x2cb
> 	 [<c018a096>] sync_inode+0x1c/0x2e
> 	 [<c01a9ff7>] ext3_sync_file+0xab/0xc0
> 	 [<c018c8c5>] do_fsync+0x4b/0x98
> 	 [<c018c932>] __do_fsync+0x20/0x2f
> 	 [<c018c960>] sys_fsync+0xd/0xf
> 	 [<c0104064>] syscall_call+0x7/0xb
> 
> but that that thing is literally:
> 
> 		...
>                 do {
>                         old_handle_count = transaction->t_handle_count;
>                         schedule_timeout_uninterruptible(1);
>                 } while (old_handle_count != transaction->t_handle_count);
> 		...
> 
> and especially if nothing is happening, I'd not expect 
> "transaction->t_handle_count" to keep changing, so it should stop very 
> quickly.
> 
> Maybe it's CONFIG_NO_HZ again, and the problem is that timeout, and simply 
> no timer tick happening?
> 
> Bingo. I think that's it.
> 
> 	active timers:
> 	 #0: hardirq_stack, tick_sched_timer, S:01
> 	 # expires at 9530893000000 nsecs [in -2567889 nsecs]
> 	 #1: hardirq_stack, hrtimer_wakeup, S:01
> 	 # expires at 10858649798503 nsecs [in 1327754230614 nsecs]
> 	  .expires_next   : 9530893000000 nsecs
> 
> See
> 
> 	http://lkml.org/lkml/2007/3/16/288
> 
> and that in turn points to the kernel log:
> 
> 	http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc4/git-console.log

Seems convincing. Michal, can you post your .config, and if you had
dynticks and hrtimers enabled, try reproducing without them?

Re: [1/6] 2.6.21-rc4: known regressions

[Michal Piotrowski]

On 23/03/07, Nick Piggin <npiggin@suse.de> wrote:
> On Thu, Mar 22, 2007 at 06:40:41PM -0700, Linus Torvalds wrote:
> >
> > [ Ok, I think it's those timers again...
> >
> >   Ingo: let me just state how *happy* I am that I told you off when you
> >   wanted to merge the hires timers and NO_HZ before 2.6.20 because they
> >   were "stable". You were wrong, and 2.6.20 is at least in reasonable
> >   shape. Now we just need to make sure that 2.6.21 will be too.. ]
> >
> > On Thu, 22 Mar 2007, Mingming Cao wrote:
> > >
> > > I might missed something, so far I can't see a deadlock yet.
> > > If there is a deadlock, I think we should see ext3_xattr_release_block()
> > > and ext3_forget() on the stack. Is this the case?
> >
> > No. What's strange is that two (maybe more, I didn't check) processes seem
> > to be stuck in
> >
> >        [<c0318981>] schedule_timeout+0x70/0x8e
> >        [<c03189b4>] schedule_timeout_uninterruptible+0x15/0x17
> >        [<c01b964a>] journal_stop+0xe2/0x1e6
> >        [<c01ba2b0>] journal_force_commit+0x1d/0x1f
> >        [<c01b29fb>] ext3_force_commit+0x22/0x24
> >        [<c01ad607>] ext3_write_inode+0x34/0x3a
> >        [<c0189f74>] __writeback_single_inode+0x1c5/0x2cb
> >        [<c018a096>] sync_inode+0x1c/0x2e
> >        [<c01a9ff7>] ext3_sync_file+0xab/0xc0
> >        [<c018c8c5>] do_fsync+0x4b/0x98
> >        [<c018c932>] __do_fsync+0x20/0x2f
> >        [<c018c960>] sys_fsync+0xd/0xf
> >        [<c0104064>] syscall_call+0x7/0xb
> >
> > but that that thing is literally:
> >
> >               ...
> >                 do {
> >                         old_handle_count = transaction->t_handle_count;
> >                         schedule_timeout_uninterruptible(1);
> >                 } while (old_handle_count != transaction->t_handle_count);
> >               ...
> >
> > and especially if nothing is happening, I'd not expect
> > "transaction->t_handle_count" to keep changing, so it should stop very
> > quickly.
> >
> > Maybe it's CONFIG_NO_HZ again, and the problem is that timeout, and simply
> > no timer tick happening?
> >
> > Bingo. I think that's it.
> >
> >       active timers:
> >        #0: hardirq_stack, tick_sched_timer, S:01
> >        # expires at 9530893000000 nsecs [in -2567889 nsecs]
> >        #1: hardirq_stack, hrtimer_wakeup, S:01
> >        # expires at 10858649798503 nsecs [in 1327754230614 nsecs]
> >         .expires_next   : 9530893000000 nsecs
> >
> > See
> >
> >       http://lkml.org/lkml/2007/3/16/288
> >
> > and that in turn points to the kernel log:
> >
> >       http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc4/git-console.log
>
> Seems convincing. Michal, can you post your .config, and if you had
> dynticks and hrtimers enabled, try reproducing without them?
>

http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc4/git-config

I don't know how to reproduce this bug on 2.6.21-rc4.On 2.6.21-rc2-mm1
it was very simple, just run youtube, bash_shared_mapping etc. In fact
I didn't see this bug for a week.

Unfortunately, I wasn't able to take a crash dump because of sound
card driver bug (I've got crash dump from 2.6.21-rc2-mm1).

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

Re: [PATCH] clockevents: Fix suspend/resume to disk hangs

[Marcus Better]

Marcus Better wrote:
> The XFS workqueue patch [1] fixes my problem [2].

> [1] http://permalink.gmane.org/gmane.linux.kernel/507616
> [2] http://permalink.gmane.org/gmane.linux.kernel/505570

Unfortunately it only fixed suspend to RAM. Suspend to disk still hangs
at "snapshotting system". Will try to bisect it...

Marcus

Re: [1/6] 2.6.21-rc4: known regressions

[Nick Piggin]

On Fri, Mar 23, 2007 at 08:51:13AM +0100, Michal Piotrowski wrote:
> On 23/03/07, Nick Piggin <npiggin@suse.de> wrote:
> >>
> >> and that in turn points to the kernel log:
> >>
> >>       
> >http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc4/git-console.log
> >
> >Seems convincing. Michal, can you post your .config, and if you had
> >dynticks and hrtimers enabled, try reproducing without them?
> >
> 
> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc4/git-config
> 
> I don't know how to reproduce this bug on 2.6.21-rc4.On 2.6.21-rc2-mm1
> it was very simple, just run youtube, bash_shared_mapping etc. In fact
> I didn't see this bug for a week.

OK... for some reason this is listed as a regression against 2.6.21-rc4.

You do have CONFIG_NO_HZ=y, and it is likely to be the cause of your
2.6.21-rc2-mm1 problems, but maybe there have been fixes since then? Ingo?

Re: [PATCH] clockevents: Fix suspend/resume to disk hangs

[Tino Keitel]

On Fri, Mar 23, 2007 at 10:14:11 +0100, Marcus Better wrote:
> Marcus Better wrote:
> > The XFS workqueue patch [1] fixes my problem [2].
> 
> > [1] http://permalink.gmane.org/gmane.linux.kernel/507616
> > [2] http://permalink.gmane.org/gmane.linux.kernel/505570
> 
> Unfortunately it only fixed suspend to RAM. Suspend to disk still hangs
> at "snapshotting system". Will try to bisect it...

I don't know if this is related, but using 2.6.21-rc4 and suspend2
2.2.9.7, I also get a hang at suspend. I could try if this also happens
with 2.6.20 and the same suspend2 version.

Regards,
Tino

Re: [1/6] 2.6.21-rc4: known regressions

[Ingo Molnar]

there's a new post-rc4 regression: my T60 hangs during early bootup. I 
bisected the hang down to this recent commit:

| commit 25496caec111481161e7f06bbfa12a533c43cc6f
| Author: Thomas Renninger <trenn@suse.de>
| Date:   Tue Feb 27 12:13:00 2007 -0500
|
|    ACPI: Only use IPI on known broken machines (AMD, Dothan/BaniasPentium M)

undoing this change fixes my T60 so it correctly boots again.

the commit has this confidence-raising comment:

|   However, I am not sure about the naming of the parameter and how it 
|   could/should get integrated into the dyntick part 
|   (CONFIG_GENERIC_CLOCKEVENTS). There, a more fine grained check (TSC 
|   still running?, ..) is needed?

could we please revert this commit until it's done correctly?

and did this end up being a 'fix'? The change weakens the scope of a 
hardware workaround, which IMO has no place so late in the cycle. At a 
minimum the clockevents maintainer (Thomas) should have been Cc:-ed on 
it.

	Ingo

Re: [1/6] 2.6.21-rc4: known regressions

[Thomas Gleixner]

On Fri, 2007-03-23 at 12:42 +0100, Ingo Molnar wrote:
> there's a new post-rc4 regression: my T60 hangs during early bootup. I 
> bisected the hang down to this recent commit:
> 
> | commit 25496caec111481161e7f06bbfa12a533c43cc6f
> | Author: Thomas Renninger <trenn@suse.de>
> | Date:   Tue Feb 27 12:13:00 2007 -0500
> |
> |    ACPI: Only use IPI on known broken machines (AMD, Dothan/BaniasPentium M)
> 
> undoing this change fixes my T60 so it correctly boots again.
> 
> the commit has this confidence-raising comment:
> 
> |   However, I am not sure about the naming of the parameter and how it 
> |   could/should get integrated into the dyntick part 
> |   (CONFIG_GENERIC_CLOCKEVENTS). There, a more fine grained check (TSC 
> |   still running?, ..) is needed?
> 
> could we please revert this commit until it's done correctly?
> 
> and did this end up being a 'fix'? The change weakens the scope of a 
> hardware workaround, which IMO has no place so late in the cycle. At a 
> minimum the clockevents maintainer (Thomas) should have been Cc:-ed on 
> it.

Ingo, 

I had seen it before, and I had no objections under the premise, that it
does not break things and especially survives on Andrews VAIO. I
expected that to come in via -mm so it gets enough testing.

We should revert that patch and add a "trust_lapic_timer_in_c2"
commandline option instead. So we are on the safe side.

	tglx

[patch] hrtimers debug patch

[Ingo Molnar]

* Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:

> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc4/git-config
> 
> I don't know how to reproduce this bug on 2.6.21-rc4. On 
> 2.6.21-rc2-mm1 it was very simple, just run youtube, 
> bash_shared_mapping etc. In fact I didn't see this bug for a week.

hm. The sysrq-q info you provided shows a weird (=='impossible') 
high-res timers state, in that CPU#1's hrtimer_cpu_base->expires_next is 
at KTIME_MAX, and state has been there for around 8-9 minutes. The 
timers there just stay pending and never expire. Thomas and me have just 
spent 4 hours reviewing the affected code inside out and upside down but 
we can find no credible way for this condition to trigger. But it 
obviously happened on your box, and persisted for many minutes.

So to move this issue forward, i've written a hrtimers debug patch 
(attached) - which checks a couple of key assumptions in the hrtimers.c 
code, and which also extends the SysRq-Q debug info with this:

  .expires_next   : 88378000000 nsecs
  .exp_prev       : 88377000000 nsecs
 last expires_next stacktrace:
  update_cpu_base_expires_next+5f/63
  hrtimer_interrupt+177/1b3
  smp_apic_timer_interrupt+6e/80
  apic_timer_interrupt+33/38
  <ffffffff>

knowing which codepath updated expires_next to KTIME_MAX would be very 
helpful to us.

So could you please pick up latest git (12998096c or later), undo commit 
25496caec (which broke my laptop - it might break your system too), and 
apply the attached patch, and keep lockdep enabled (so that you get 
CONFIG_STACKTRACE=y, essential for the stacktrace output above)? It 
might take some time for you to trigger this bug again, but that's the 
best idea we have so far. If we are lucky then one of the WARN_ON()s 
triggers much sooner.

if the hang occurs again then please do a SysRq-Q again and send us the 
output.

	Ingo

---------------------------->
Subject: [patch] hrtimers debug patch
From: Ingo Molnar <mingo@elte.hu>

debugging helper for hrtimers. Keep a lookout for WARN_ON messages.
Saves a stacktrace on every expires_next update, and makes that
stack-trace available in SysRq-Q (or /proc/timer_list) output.

( make sure to run this on a lockdep-enabled kernel, so that
  CONFIG_STACKTRACE=y. )

NOT-Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/i386/kernel/apic.c    |    2 +
 include/linux/hrtimer.h    |    7 +++++
 kernel/hrtimer.c           |   54 +++++++++++++++++++++++++++++++++++----------
 kernel/time/tick-oneshot.c |   13 ++++++++++
 kernel/time/timer_list.c   |   21 ++++++++++++++++-
 5 files changed, 83 insertions(+), 14 deletions(-)

Index: linux/arch/i386/kernel/apic.c
===================================================================
--- linux.orig/arch/i386/kernel/apic.c
+++ linux/arch/i386/kernel/apic.c
@@ -523,6 +523,8 @@ void __init setup_boot_APIC_clock(void)
 		 */
 		if (nmi_watchdog != NMI_IO_APIC)
 			lapic_clockevent.features &= ~CLOCK_EVT_FEAT_DUMMY;
+		else
+			printk(KERN_WARNING "APIC timer registered as dummy, due to nmi_watchdog=1!\n");
 	}
 
 	/* Setup the lapic or request the broadcast */
Index: linux/include/linux/hrtimer.h
===================================================================
--- linux.orig/include/linux/hrtimer.h
+++ linux/include/linux/hrtimer.h
@@ -15,6 +15,7 @@
 #ifndef _LINUX_HRTIMER_H
 #define _LINUX_HRTIMER_H
 
+#include <linux/stacktrace.h>
 #include <linux/rbtree.h>
 #include <linux/ktime.h>
 #include <linux/init.h>
@@ -196,6 +197,12 @@ struct hrtimer_cpu_base {
 	struct hrtimer_clock_base	clock_base[HRTIMER_MAX_CLOCK_BASES];
 #ifdef CONFIG_HIGH_RES_TIMERS
 	ktime_t				expires_next;
+# define HRTIMERS_STACK_TRACE_DEPTH	32
+# ifdef CONFIG_STACKTRACE
+	struct stack_trace		exp_trace;
+	unsigned long			exp_entries[HRTIMERS_STACK_TRACE_DEPTH];
+# endif
+	ktime_t				exp_prev;
 	int				hres_active;
 	struct list_head		cb_pending;
 	unsigned long			nr_events;
Index: linux/kernel/hrtimer.c
===================================================================
--- linux.orig/kernel/hrtimer.c
+++ linux/kernel/hrtimer.c
@@ -305,6 +305,27 @@ unsigned long ktime_divns(const ktime_t 
 /* High resolution timer related functions */
 #ifdef CONFIG_HIGH_RES_TIMERS
 
+static void update_cpu_base_expires_next(struct hrtimer_cpu_base *cpu_base,
+					 ktime_t expires_next)
+{
+	cpu_base->exp_prev = cpu_base->expires_next;
+	cpu_base->expires_next = expires_next;
+
+#ifdef CONFIG_STACKTRACE
+	{
+		struct stack_trace *trace = &cpu_base->exp_trace;
+
+		trace->nr_entries = 0;
+		trace->entries = cpu_base->exp_entries;
+		trace->max_entries = HRTIMERS_STACK_TRACE_DEPTH;
+		trace->skip = 1;
+		trace->all_contexts = 0;
+
+		save_stack_trace(trace, NULL);
+	}
+#endif
+}
+
 /*
  * High resolution timer enabled ?
  */
@@ -353,7 +374,7 @@ static void hrtimer_force_reprogram(stru
 	struct hrtimer_clock_base *base = cpu_base->clock_base;
 	ktime_t expires;
 
-	cpu_base->expires_next.tv64 = KTIME_MAX;
+	update_cpu_base_expires_next(cpu_base, (ktime_t){ .tv64 = KTIME_MAX });
 
 	for (i = 0; i < HRTIMER_MAX_CLOCK_BASES; i++, base++) {
 		struct hrtimer *timer;
@@ -363,7 +384,7 @@ static void hrtimer_force_reprogram(stru
 		timer = rb_entry(base->first, struct hrtimer, node);
 		expires = ktime_sub(timer->expires, base->offset);
 		if (expires.tv64 < cpu_base->expires_next.tv64)
-			cpu_base->expires_next = expires;
+			update_cpu_base_expires_next(cpu_base, expires);
 	}
 
 	if (cpu_base->expires_next.tv64 != KTIME_MAX)
@@ -382,7 +403,7 @@ static void hrtimer_force_reprogram(stru
 static int hrtimer_reprogram(struct hrtimer *timer,
 			     struct hrtimer_clock_base *base)
 {
-	ktime_t *expires_next = &__get_cpu_var(hrtimer_bases).expires_next;
+	struct hrtimer_cpu_base *cpu_base = &__get_cpu_var(hrtimer_bases);
 	ktime_t expires = ktime_sub(timer->expires, base->offset);
 	int res;
 
@@ -396,7 +417,7 @@ static int hrtimer_reprogram(struct hrti
 	if (hrtimer_callback_running(timer))
 		return 0;
 
-	if (expires.tv64 >= expires_next->tv64)
+	if (expires.tv64 >= cpu_base->expires_next.tv64)
 		return 0;
 
 	/*
@@ -404,7 +425,7 @@ static int hrtimer_reprogram(struct hrti
 	 */
 	res = tick_program_event(expires, 0);
 	if (!IS_ERR_VALUE(res))
-		*expires_next = expires;
+		update_cpu_base_expires_next(cpu_base, expires);
 	return res;
 }
 
@@ -479,7 +500,7 @@ static inline void hrtimer_remove_cb_pen
  */
 static inline void hrtimer_init_hres(struct hrtimer_cpu_base *base)
 {
-	base->expires_next.tv64 = KTIME_MAX;
+	update_cpu_base_expires_next(base, (ktime_t){ .tv64 = KTIME_MAX });
 	base->hres_active = 0;
 	INIT_LIST_HEAD(&base->cb_pending);
 }
@@ -543,7 +564,8 @@ static inline int hrtimer_enqueue_reprog
  */
 static int hrtimer_switch_to_hres(void)
 {
-	struct hrtimer_cpu_base *base = &__get_cpu_var(hrtimer_bases);
+	int cpu = smp_processor_id();
+	struct hrtimer_cpu_base *base = &per_cpu(hrtimer_bases, cpu);
 	unsigned long flags;
 
 	if (base->hres_active)
@@ -553,6 +575,8 @@ static int hrtimer_switch_to_hres(void)
 
 	if (tick_init_highres()) {
 		local_irq_restore(flags);
+		printk(KERN_WARNING "Could not switch to high resolution "
+				    "mode on CPU %d\n", cpu);
 		return 0;
 	}
 	base->hres_active = 1;
@@ -667,6 +691,7 @@ static void enqueue_hrtimer(struct hrtim
 	struct rb_node **link = &base->active.rb_node;
 	struct rb_node *parent = NULL;
 	struct hrtimer *entry;
+	int leftmost = 1;
 
 	/*
 	 * Find the right place in the rbtree:
@@ -678,18 +703,19 @@ static void enqueue_hrtimer(struct hrtim
 		 * We dont care about collisions. Nodes with
 		 * the same expiry time stay together.
 		 */
-		if (timer->expires.tv64 < entry->expires.tv64)
+		if (timer->expires.tv64 < entry->expires.tv64) {
 			link = &(*link)->rb_left;
-		else
+		} else {
 			link = &(*link)->rb_right;
+			leftmost = 0;
+		}
 	}
 
 	/*
 	 * Insert the timer to the rbtree and check whether it
 	 * replaces the first pending timer
 	 */
-	if (!base->first || timer->expires.tv64 <
-	    rb_entry(base->first, struct hrtimer, node)->expires.tv64) {
+	if (leftmost) {
 		/*
 		 * Reprogram the clock event device. When the timer is already
 		 * expired hrtimer_enqueue_reprogram has either called the
@@ -706,6 +732,9 @@ static void enqueue_hrtimer(struct hrtim
 
 	rb_link_node(&timer->node, parent, link);
 	rb_insert_color(&timer->node, &base->active);
+
+	WARN_ON(base->first != rb_first(&base->active));
+
 	/*
 	 * HRTIMER_STATE_ENQUEUED is or'ed to the current state to preserve the
 	 * state of a possibly running callback.
@@ -742,6 +771,7 @@ static void __remove_hrtimer(struct hrti
 				hrtimer_force_reprogram(base->cpu_base);
 		}
 		rb_erase(&timer->node, &base->active);
+		WARN_ON(base->first != rb_first(&base->active));
 	}
 	timer->state = newstate;
 }
@@ -1053,7 +1083,7 @@ void hrtimer_interrupt(struct clock_even
 		base++;
 	}
 
-	cpu_base->expires_next = expires_next;
+	update_cpu_base_expires_next(cpu_base, expires_next);
 
 	/* Reprogramming necessary ? */
 	if (expires_next.tv64 != KTIME_MAX) {
Index: linux/kernel/time/tick-oneshot.c
===================================================================
--- linux.orig/kernel/time/tick-oneshot.c
+++ linux/kernel/time/tick-oneshot.c
@@ -73,8 +73,19 @@ int tick_switch_to_oneshot(void (*handle
 	struct clock_event_device *dev = td->evtdev;
 
 	if (!dev || !(dev->features & CLOCK_EVT_FEAT_ONESHOT) ||
-	    !tick_device_is_functional(dev))
+		    !tick_device_is_functional(dev)) {
+
+		printk("could not switch to one-shot clockevents mode.\n");
+		if (!dev) {
+			printk("because no tick device\n");
+		} else {
+			if (!(dev->features & CLOCK_EVT_FEAT_ONESHOT))
+				printk("because %s does not support one-shot mode.\n", dev->name);
+			if (!tick_device_is_functional(dev))
+				printk("because %s is not functional.\n", dev->name);
+		}
 		return -EINVAL;
+	}
 
 	td->mode = TICKDEV_MODE_ONESHOT;
 	dev->event_handler = handler;
Index: linux/kernel/time/timer_list.c
===================================================================
--- linux.orig/kernel/time/timer_list.c
+++ linux/kernel/time/timer_list.c
@@ -46,7 +46,7 @@ static void print_name_offset(struct seq
 
 	sym_name = kallsyms_lookup(addr, &size, &offset, &modname, namebuf);
 	if (sym_name)
-		SEQ_printf(m, "%s", sym_name);
+		SEQ_printf(m, "%s+%lx/%lx", sym_name, offset, size);
 	else
 		SEQ_printf(m, "<%p>", sym);
 }
@@ -129,6 +129,23 @@ print_base(struct seq_file *m, struct hr
 	print_active_timers(m, base, now);
 }
 
+static void print_cpu_base_stack_trace(struct seq_file *m,
+				       struct hrtimer_cpu_base *cpu_base)
+{
+#ifdef CONFIG_STACKTRACE
+	struct stack_trace *trace = &cpu_base->exp_trace;
+	int i;
+
+	SEQ_printf(m, " last expires_next stacktrace:\n");
+	for (i = 0; i < trace->nr_entries; i++) {
+		SEQ_printf(m, "  ");
+		print_name_offset(m, (void *)trace->entries[i]);
+		SEQ_printf(m, "\n");
+	}
+	SEQ_printf(m, "\n");
+#endif
+}
+
 static void print_cpu(struct seq_file *m, int cpu, u64 now)
 {
 	struct hrtimer_cpu_base *cpu_base = &per_cpu(hrtimer_bases, cpu);
@@ -147,6 +164,8 @@ static void print_cpu(struct seq_file *m
 
 #ifdef CONFIG_HIGH_RES_TIMERS
 	P_ns(expires_next);
+	P_ns(exp_prev);
+	print_cpu_base_stack_trace(m, cpu_base);
 	P(hres_active);
 	P(nr_events);
 #endif

Re: [1/6] 2.6.21-rc4: known regressions

[Ingo Molnar]

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

> [ Ok, I think it's those timers again...

agreed - this seems to be a genuine CONFIG_HIGH_RES_TIMERS=y bug. (which 
has probably not been fixed since -rc4 either, we have no bugfix in this 
area that could explain the expires_next==KTIME_MAX timer state visible 
in SysRq-Q.)

there seems to be a trend in the reports: HT P4 CPUs.

>   Ingo: let me just state how *happy* I am that I told you off when 
>   you wanted to merge the hires timers and NO_HZ before 2.6.20 because 
>   they were "stable". You were wrong, and 2.6.20 is at least in 
>   reasonable shape. [...]

yes - i was quite wrong pushing it so hard. (and doubly so given your 
stated focus of making v2.6.20 a quiet release) Sorry :-/

> [...] Now we just need to make sure that 2.6.21 will be too.. ]

yeah - we are working hard on it.

	Ingo

Re: [PATCH] clockevents: Fix suspend/resume to disk hangs

[Rafael J. Wysocki]

On Friday, 23 March 2007 10:14, Marcus Better wrote:
> Marcus Better wrote:
> > The XFS workqueue patch [1] fixes my problem [2].
> 
> > [1] http://permalink.gmane.org/gmane.linux.kernel/507616
> > [2] http://permalink.gmane.org/gmane.linux.kernel/505570
> 
> Unfortunately it only fixed suspend to RAM. Suspend to disk still hangs
> at "snapshotting system". Will try to bisect it...

Do you use the microcode driver?

Rafael

Re: [PATCH] clockevents: Fix suspend/resume to disk hangs

[Marcus Better]

> Do you use the microcode driver?

No.

I'm in the middle of bisecting. Strange enough the symptoms change as I go. 
Some commits manage to suspend to RAM, but hang at resume.

Marcus

[PATCH] i386: add command line option "local_apic_timer_c2_ok"

[Thomas Gleixner]

On Fri, 2007-03-23 at 12:56 +0100, Thomas Gleixner wrote:
> We should revert that patch and add a "trust_lapic_timer_in_c2"
> commandline option instead. So we are on the safe side.

Here is a patch which applies after reverting 
25496caec111481161e7f06bbfa12a533c43cc6f

It turned out that it is almost impossible to trust ACPI, BIOS & Co.
regarding the C states. This was the reason to switch the local apic
timer off in C2 state already. OTOH there are sane and well behaving
systems, which get punished by that decision.

Allow the user to confirm that the local apic timer is trustworthy in C2
state. This keeps the default behaviour on the safe side.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index e39ab0c..09640a8 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -780,6 +780,9 @@ and is between 256 and 4096 characters. It is defined in the file
 	lapic		[IA-32,APIC] Enable the local APIC even if BIOS
 			disabled it.
 
+	lapic_timer_c2_ok	[IA-32,APIC] trust the local apic timer in
+			C2 power state.
+
 	lasi=		[HW,SCSI] PARISC LASI driver for the 53c700 chip
 			Format: addr:<io>,irq:<irq>
 
diff --git a/arch/i386/kernel/apic.c b/arch/i386/kernel/apic.c
index 244c3fe..e884152 100644
--- a/arch/i386/kernel/apic.c
+++ b/arch/i386/kernel/apic.c
@@ -64,6 +64,9 @@ static int enable_local_apic __initdata = 0;
 static int local_apic_timer_verify_ok;
 /* Disable local APIC timer from the kernel commandline or via dmi quirk */
 static int local_apic_timer_disabled;
+/* Local APIC timer works in C2 */
+int local_apic_timer_c2_ok;
+EXPORT_SYMBOL_GPL(local_apic_timer_c2_ok);
 
 /*
  * Debug level, exported for io_apic.c
@@ -1232,6 +1235,13 @@ static int __init parse_disable_lapic_timer(char *arg)
 }
 early_param("nolapic_timer", parse_disable_lapic_timer);
 
+static int __init parse_lapic_timer_c2_ok(char *arg)
+{
+	local_apic_timer_c2_ok = 1;
+	return 0;
+}
+early_param("lapic_timer_c2_ok", parse_lapic_timer_c2_ok);
+
 static int __init apic_set_verbosity(char *str)
 {
 	if (strcmp("debug", str) == 0)
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 6077300..cdf7894 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -268,6 +268,7 @@ static void acpi_timer_check_state(int state, struct acpi_processor *pr,
 				   struct acpi_processor_cx *cx)
 {
 	struct acpi_processor_power *pwr = &pr->power;
+	u8 type = local_apic_timer_c2_ok ? ACPI_STATE_C3 : ACPI_STATE_C2;
 
 	/*
 	 * Check, if one of the previous states already marked the lapic
@@ -276,7 +277,7 @@ static void acpi_timer_check_state(int state, struct acpi_processor *pr,
 	if (pwr->timer_broadcast_on_state < state)
 		return;
 
-	if (cx->type >= ACPI_STATE_C2)
+	if (cx->type >= type)
 		pr->power.timer_broadcast_on_state = state;
 }
 
diff --git a/include/asm-i386/apic.h b/include/asm-i386/apic.h
index cc6b165..a19810a 100644
--- a/include/asm-i386/apic.h
+++ b/include/asm-i386/apic.h
@@ -117,6 +117,7 @@ extern void enable_NMI_through_LVT0 (void * dummy);
 #define ARCH_APICTIMER_STOPS_ON_C3	1
 
 extern int timer_over_8254;
+extern int local_apic_timer_c2_ok;
 
 #else /* !CONFIG_X86_LOCAL_APIC */
 static inline void lapic_shutdown(void) { }

Re: [1/6] 2.6.21-rc4: known regressions

[Adrian Bunk]

On Fri, Mar 23, 2007 at 10:37:38AM +0100, Nick Piggin wrote:
> On Fri, Mar 23, 2007 at 08:51:13AM +0100, Michal Piotrowski wrote:
> > On 23/03/07, Nick Piggin <npiggin@suse.de> wrote:
> > >>
> > >> and that in turn points to the kernel log:
> > >>
> > >>       
> > >http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc4/git-console.log
> > >
> > >Seems convincing. Michal, can you post your .config, and if you had
> > >dynticks and hrtimers enabled, try reproducing without them?
> > >
> > 
> > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc4/git-config
> > 
> > I don't know how to reproduce this bug on 2.6.21-rc4.On 2.6.21-rc2-mm1
> > it was very simple, just run youtube, bash_shared_mapping etc. In fact
> > I didn't see this bug for a week.
> 
> OK... for some reason this is listed as a regression against 2.6.21-rc4.
>...

Due to
   http://lkml.org/lkml/2007/3/16/288

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [1/6] 2.6.21-rc4: known regressions

[Linus Torvalds]

On Fri, 23 Mar 2007, Thomas Gleixner wrote:
> 
> We should revert that patch and add a "trust_lapic_timer_in_c2"
> commandline option instead. So we are on the safe side.

Damn. I applied your patch, but it breaks on x86-64:

   drivers/acpi/processor_idle.c:271: error: 'local_apic_timer_c2_ok' 
	undeclared (f irst use in this function)

I really wish we had an x86-64 maintainer that understood that it's 
confusing that files in arch/i386/ are also used for arch/x86-64.

		Linus

Re: [1/6] 2.6.21-rc4: known regressions

[Linus Torvalds]

On Fri, 23 Mar 2007, Linus Torvalds wrote:
> 
> I really wish we had an x86-64 maintainer that understood that it's 
> confusing that files in arch/i386/ are also used for arch/x86-64.

Sorry, that was unfair. The patch was simply buggy. It added the test to 
drivers/acpi/ *without* adding it to the architectures that used it, it 
wasn't an i386/x86-64 thing.

Thomas, please fix.

		Linus

Re: [1/6] 2.6.21-rc4: known regressions

[Linus Torvalds]

On Fri, 23 Mar 2007, Linus Torvalds wrote:
> 
> Thomas, please fix.

Here's a possible fix. It compiles. And I still wish we had common files.

ia64 shouldn't be affected, because ia64 doesn't #define the 
ARCH_APICTIMER_STOPS_ON_C3 flag (and then we don't use the "c2_ok" thing 
either. But this is still pretty damn ugly.

Maybe a field in "struct acpi_processor" for C2/C3 problems?

		Linus

---
diff --git a/arch/x86_64/kernel/apic.c b/arch/x86_64/kernel/apic.c
index 723417d..46acf4f 100644
--- a/arch/x86_64/kernel/apic.c
+++ b/arch/x86_64/kernel/apic.c
@@ -47,6 +47,10 @@ int apic_calibrate_pmtmr __initdata;
 
 int disable_apic_timer __initdata;
 
+/* Local APIC timer works in C2? */
+int local_apic_timer_c2_ok;
+EXPORT_SYMBOL_GPL(local_apic_timer_c2_ok);
+
 static struct resource *ioapic_resources;
 static struct resource lapic_resource = {
 	.name = "Local APIC",
@@ -1192,6 +1196,13 @@ static __init int setup_nolapic(char *str)
 } 
 early_param("nolapic", setup_nolapic);
 
+static int __init parse_lapic_timer_c2_ok(char *arg)
+{
+	local_apic_timer_c2_ok = 1;
+	return 0;
+}
+early_param("lapic_timer_c2_ok", parse_lapic_timer_c2_ok);
+
 static __init int setup_noapictimer(char *str) 
 { 
 	if (str[0] != ' ' && str[0] != 0)
diff --git a/include/asm-x86_64/apic.h b/include/asm-x86_64/apic.h
index e81d0f2..7cfb39c 100644
--- a/include/asm-x86_64/apic.h
+++ b/include/asm-x86_64/apic.h
@@ -102,5 +102,6 @@ void switch_ipi_to_APIC_timer(void *cpumask);
 #define ARCH_APICTIMER_STOPS_ON_C3	1
 
 extern unsigned boot_cpu_id;
+extern int local_apic_timer_c2_ok;
 
 #endif /* __ASM_APIC_H */

Re: [1/6] 2.6.21-rc4: known regressions

[Thomas Gleixner]

On Fri, 2007-03-23 at 11:28 -0700, Linus Torvalds wrote:
> 
> On Fri, 23 Mar 2007, Linus Torvalds wrote:
> > 
> > Thomas, please fix.
> 
> Here's a possible fix. It compiles. And I still wish we had common files.

You beat me by 30 seconds.

> ia64 shouldn't be affected, because ia64 doesn't #define the 
> ARCH_APICTIMER_STOPS_ON_C3 flag (and then we don't use the "c2_ok" thing 
> either. 

Right, ia64 does not see it.

> But this is still pretty damn ugly.

Yes it is.

> Maybe a field in "struct acpi_processor" for C2/C3 problems?

Hmm, the acpi processor stuff is modular.

	tglx

[1/5] 2.6.21-rc4: known regressions (v2)

[Adrian Bunk]

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    : problem with sockets
References : http://lkml.org/lkml/2007/3/21/248
Submitter  : Jose Alberto Reguero <jareguero@telefonica.net>
Status     : unknown


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>
Status     : submitter was asked to bisect further

[2/5] 2.6.21-rc4: known regressions (v2)

[Adrian Bunk]

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    : 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    : x86_64: ACPI regression with noapic  (APICTIMER_STOPS_ON_C3?)
References : http://lkml.org/lkml/2007/3/8/468
             http://lkml.org/lkml/2007/3/22/156
Submitter  : Ray Lee <ray-lk@madrabbit.org>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Status     : problem is being debugged


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
Submitter  : Mathieu Bérard <Mathieu.Berard@crans.org>
Handled-By : Tejun Heo <htejun@gmail.com>
Status     : problem is being debugged


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>
             Alan Cox <alan@lxorguk.ukuu.org.uk>
Status     : Alan: Some cases should be fixed now but probably not all
                   (eg the Nvidia one)

[3/5] 2.6.21-rc4: known regressions (v2)

[Adrian Bunk]

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    : MacMini: doesn't come out of suspend to ram
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  : Bob Moore <robert.moore@intel.com>
             commit c5a7156959e89b32260ad6072bbf5077bcdfbeee
Status     : unknown


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>
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    : 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
References : http://lkml.org/lkml/2007/3/6/142
Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
Status     : unknown


Subject    : suspend to disk hangs
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
Status     : unknown


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


Subject    : ThinkPad R60: suspend to disk broken
References : http://lkml.org/lkml/2007/3/23/74
Submitter  : Marcus Better <marcus@better.se>
Status     : submitter tries to bisect


Subject    : after resume: X hangs after drawing a couple of windows
References : http://lkml.org/lkml/2007/3/8/117
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
Status     : unknown


Subject    : second suspend to disk in a row results in an oops  (libata?)
References : http://lkml.org/lkml/2007/3/17/43
Submitter  : Thomas Meyer <thomas@m3y3r.de>
Status     : unknown


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


-
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

[3/5] 2.6.21-rc4: known regressions (v2)

[Adrian Bunk]

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    : MacMini: doesn't come out of suspend to ram
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  : Bob Moore <robert.moore@intel.com>
             commit c5a7156959e89b32260ad6072bbf5077bcdfbeee
Status     : unknown


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>
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    : 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
References : http://lkml.org/lkml/2007/3/6/142
Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
Status     : unknown


Subject    : suspend to disk hangs
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
Status     : unknown


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


Subject    : ThinkPad R60: suspend to disk broken
References : http://lkml.org/lkml/2007/3/23/74
Submitter  : Marcus Better <marcus@better.se>
Status     : submitter tries to bisect


Subject    : after resume: X hangs after drawing a couple of windows
References : http://lkml.org/lkml/2007/3/8/117
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
Status     : unknown


Subject    : second suspend to disk in a row results in an oops  (libata?)
References : http://lkml.org/lkml/2007/3/17/43
Submitter  : Thomas Meyer <thomas@m3y3r.de>
Status     : unknown


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

[4/5] 2.6.21-rc4: known regressions (v2)

[Adrian Bunk]

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    : 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     : problem is being debugged


Subject    : first disk access after resume takes several minutes
             ('date' does not advance after resume from RAM, CONFIG_NO_HZ=n)
References : http://lkml.org/lkml/2007/3/8/117
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
             Ingo Molnar <mingo@elte.hu>
Status     : problem is being debugged


Subject    : Dynticks and High resolution Timer hanging the system
             workaround: clocksource=acpi_pm
References : http://lkml.org/lkml/2007/3/7/504
Submitter  : Stephane Casset <sept@logidee.com>
Caused-By  : Thomas Gleixner <tglx@linutronix.de>
Status     : unknown


Subject    : soft lockup detected on CPU#0
References : http://lkml.org/lkml/2007/3/3/152
Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
             Ingo Molnar <mingo@elte.hu>
Status     : unknown


Subject    : gettimeofday increments too slowly
References : http://bugzilla.kernel.org/show_bug.cgi?id=8027
Submitter  : David L <idht4n@hotmail.com>
Caused-By  : Thomas Gleixner <tglx@linutronix.de>
             commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Status     : problem is being debugged


Subject    : boot hangs during IDE detection  (clocksource)
References : http://lkml.org/lkml/2007/3/19/465
Submitter  : Bob Tracy <rct@gherkin.frus.com>
Caused-By  : John Stultz <johnstul@us.ibm.com>
             commit 6bb74df481223731af6c7e0ff3adb31f6442cfcd
Handled-By : John Stultz <johnstul@us.ibm.com>
Status     : problem is being debugged


Subject    : dynticks makes ksoftirqd1 use unreasonable amount of cpu time
References : http://bugzilla.kernel.org/show_bug.cgi?id=8100
Submitter  : Emil Karlson <jkarlson@cc.hut.fi>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Status     : problem is being debugged

[5/5] 2.6.21-rc4: known regressions (v2)

[Adrian Bunk]

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    : USB: iPod doesn't work
References : http://lkml.org/lkml/2007/3/21/320
Submitter  : Tino Keitel <tino.keitel@gmx.de>
Handled-By : Oliver Neukum <oneukum@suse.de>
Status     : problem is being debuggged


Subject    : snd_intel8x0: divide error: 0000
References : http://lkml.org/lkml/2007/3/5/252
Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Handled-By : Takashi Iwai <tiwai@suse.de>
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

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Maxim]

On Friday 23 March 2007 20:50:22 Adrian Bunk wrote:

> Subject    : suspend to disk hangs
> 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
> Status     : unknown
> 
> 

Hello, 
	It is fixed

	The problem is that now cpu_up/cpu_down is called with tasks frozen,
	and this can lead to deadlock if some driver that registered cpu up/down notifier, sleeps,

	On my system it froze in two places, one in XFS due to freezable workqueues, and in
	microcode update driver that ask the "frozen" userspace for firmware.

	Fix for XFS is already in mainline, and Rafael J. Wysocki. already posted a patch that fixes microcode issue,
	I will test it.

	But I feel that there are more drivers that can deadlock system in same way, on my system S3/S4 works perfect :-)
	Even the weird  hang i had disappeared.

	Big thanks to Rafael J. Wysocki.


	Best regards,
		Maxim Levitsky

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Maxim]

On Friday 23 March 2007 20:50:22 Adrian Bunk wrote:

> Subject    : suspend to disk hangs
> 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
> Status     : unknown
> 
> 

Hello, 
	It is fixed

	The problem is that now cpu_up/cpu_down is called with tasks frozen,
	and this can lead to deadlock if some driver that registered cpu up/down notifier, sleeps,

	On my system it froze in two places, one in XFS due to freezable workqueues, and in
	microcode update driver that ask the "frozen" userspace for firmware.

	Fix for XFS is already in mainline, and Rafael J. Wysocki. already posted a patch that fixes microcode issue,
	I will test it.

	But I feel that there are more drivers that can deadlock system in same way, on my system S3/S4 works perfect :-)
	Even the weird  hang i had disappeared.

	Big thanks to Rafael J. Wysocki.


	Best regards,
		Maxim Levitsky

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Adrian Bunk]

On Fri, Mar 23, 2007 at 08:15:38PM +0100, Thomas Gleixner wrote:
> On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
> > Subject    : gettimeofday increments too slowly
> > References : http://bugzilla.kernel.org/show_bug.cgi?id=8027
> > Submitter  : David L <idht4n@hotmail.com>
> > Caused-By  : Thomas Gleixner <tglx@linutronix.de>
> >              commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2
> > Handled-By : Thomas Gleixner <tglx@linutronix.de>
> > Status     : problem is being debugged
> 
> Patch available: http://lkml.org/lkml/2007/3/22/301
> 
> commit 6b3964cde70cfe6db79d35b42137431ef7d2f7e4

As far as I understood it, this patch only fixed the bogomips issue
caused by commit e9e2cdb412412326c4827fc78ba27f410d837e6e, but not the 
gettimeofday issue caused by commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2 ?

> 	tglx

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Thomas Gleixner]

On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
> Subject    : gettimeofday increments too slowly
> References : http://bugzilla.kernel.org/show_bug.cgi?id=8027
> Submitter  : David L <idht4n@hotmail.com>
> Caused-By  : Thomas Gleixner <tglx@linutronix.de>
>              commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2
> Handled-By : Thomas Gleixner <tglx@linutronix.de>
> Status     : problem is being debugged

Patch available: http://lkml.org/lkml/2007/3/22/301

commit 6b3964cde70cfe6db79d35b42137431ef7d2f7e4

	tglx

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Thomas Gleixner]

On Fri, 2007-03-23 at 20:15 +0100, Thomas Gleixner wrote:
> On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
> > Subject    : gettimeofday increments too slowly
> > References : http://bugzilla.kernel.org/show_bug.cgi?id=8027
> > Submitter  : David L <idht4n@hotmail.com>
> > Caused-By  : Thomas Gleixner <tglx@linutronix.de>
> >              commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2
> > Handled-By : Thomas Gleixner <tglx@linutronix.de>
> > Status     : problem is being debugged
> 
> Patch available: http://lkml.org/lkml/2007/3/22/301
> 
> commit 6b3964cde70cfe6db79d35b42137431ef7d2f7e4

Oops. That fixed only the one half of the problem. The timeofday one
persists.

John, any idea ?

	tglx

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Thomas Gleixner]

On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
> Subject    : dynticks makes ksoftirqd1 use unreasonable amount of cpu time
> References : http://bugzilla.kernel.org/show_bug.cgi?id=8100
> Submitter  : Emil Karlson <jkarlson@cc.hut.fi>
> Handled-By : Thomas Gleixner <tglx@linutronix.de>
> Status     : problem is being debugged

The problem is not reproducible on any of my machines.

Emil, is it still there with Linus latest ?

	tglx

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Thomas Gleixner]

On Fri, 2007-03-23 at 19:50 +0100, 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.
> 
> 
> 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     : problem is being debugged
> 
> 
> Subject    : first disk access after resume takes several minutes
>              ('date' does not advance after resume from RAM, CONFIG_NO_HZ=n)
> References : http://lkml.org/lkml/2007/3/8/117
> Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
> Handled-By : Thomas Gleixner <tglx@linutronix.de>
>              Ingo Molnar <mingo@elte.hu>
> Status     : problem is being debugged

I lost track of Michaels various nested problems.

Michael can you please give a summary on _all_ entries in the
regressions list against Linus latest ?

Thanks,

	tglx

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Thomas Gleixner]

On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
> Subject    : Dynticks and High resolution Timer hanging the system
>              workaround: clocksource=acpi_pm
> References : http://lkml.org/lkml/2007/3/7/504
> Submitter  : Stephane Casset <sept@logidee.com>
> Caused-By  : Thomas Gleixner <tglx@linutronix.de>
> Status     : unknown

Stephane, does the problem still exists with Linus latest ?

Thanks,

	tglx

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Thomas Gleixner]

On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
> Subject    : soft lockup detected on CPU#0
> References : http://lkml.org/lkml/2007/3/3/152
> Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
> Handled-By : Thomas Gleixner <tglx@linutronix.de>
>              Ingo Molnar <mingo@elte.hu>
> Status     : unknown

Michal,

any news on that one ? 

You said the same problem exists in 2.6.20.1. Has this been resolved in
2.6.20.2/3

Thanks,

	tglx

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Rafael J. Wysocki]

On Friday, 23 March 2007 19:50, 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.
> 
[--snip--]
> Subject    : suspend to disk hangs
> 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
> Status     : unknown

The problem has been identified as the known issue related to the XFS freezable
workqueues.  There is a patch available (http://lkml.org/lkml/2007/3/21/328),
that has been merged.

Still, there is a problem with the microcode update driver that's being worked
on.

The reporters of the resume problems who use the microcode driver, please
check if the problems go away if you unload the driver before the suspend.

Greetings,
Rafael

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Rafael J. Wysocki]

On Friday, 23 March 2007 19:50, 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.
> 
[--snip--]
> Subject    : suspend to disk hangs
> 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
> Status     : unknown

The problem has been identified as the known issue related to the XFS freezable
workqueues.  There is a patch available (http://lkml.org/lkml/2007/3/21/328),
that has been merged.

Still, there is a problem with the microcode update driver that's being worked
on.

The reporters of the resume problems who use the microcode driver, please
check if the problems go away if you unload the driver before the suspend.

Greetings,
Rafael

Re: [2/5] 2.6.21-rc4: known regressions (v2)

[Thomas Gleixner]

On Fri, 2007-03-23 at 19:48 +0100, Adrian Bunk wrote:
> Subject    : x86_64: ACPI regression with noapic  (APICTIMER_STOPS_ON_C3?)
> References : http://lkml.org/lkml/2007/3/8/468
>              http://lkml.org/lkml/2007/3/22/156
> Submitter  : Ray Lee <ray-lk@madrabbit.org>
> Handled-By : Thomas Gleixner <tglx@linutronix.de>
> Status     : problem is being debugged

Ray,

can you please test the patch below ?

Thanks,

	tglx

------------------>
Subject: [PATCH] x86_64: avoid sending LOCAL_TIMER_VECTOR IPI to itself

Ray Lee reported, that on an UP kernel with "noapic" commandline option
set, the box locks hard during boot.

Adding some debug printks revieled, that the last action on the box
before stalling was "Send IPI" - a debug printk which was put into
smp_send_timer_broadcast_ipi().

It seems that send_IPI_mask(mask, LOCAL_TIMER_VECTOR) fails when
"noapic" is set on the commandline on an UP kernel.

Aside of that it does not make much sense to trigger an interrupt
instead of calling the function directly on the CPU which gets the
PIT/HPET interrupt in case of broadcasting.

Reported-by: Ray Lee <ray-lk@madrabbit.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

diff --git a/arch/x86_64/kernel/apic.c b/arch/x86_64/kernel/apic.c
index 723417d..83328e1 100644
--- a/arch/x86_64/kernel/apic.c
+++ b/arch/x86_64/kernel/apic.c
@@ -930,9 +930,17 @@ EXPORT_SYMBOL(switch_APIC_timer_to_ipi);
 
 void smp_send_timer_broadcast_ipi(void)
 {
+	int cpu = smp_processor_id();
 	cpumask_t mask;
 
 	cpus_and(mask, cpu_online_map, timer_interrupt_broadcast_ipi_mask);
+
+	if (cpu_isset(cpu, mask)) {
+		cpu_clear(cpu, mask);
+		add_pda(apic_timer_irqs, 1);
+		smp_local_timer_interrupt();
+	}
+
 	if (!cpus_empty(mask)) {
 		send_IPI_mask(mask, LOCAL_TIMER_VECTOR);
 	}

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[john stultz]

On Fri, 2007-03-23 at 19:50 +0100, 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.

> Subject    : boot hangs during IDE detection  (clocksource)
> References : http://lkml.org/lkml/2007/3/19/465
> Submitter  : Bob Tracy <rct@gherkin.frus.com>
> Caused-By  : John Stultz <johnstul@us.ibm.com>
>              commit 6bb74df481223731af6c7e0ff3adb31f6442cfcd
> Handled-By : John Stultz <johnstul@us.ibm.com>
> Status     : problem is being debugged


The incorrect clocksource selection is resolved w/ this patch:
http://lkml.org/lkml/2007/3/22/287

There is still an issue of why the PIT clocksource hangs, but for the
moment the issue its worked-around.

thanks
-john

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Linus Torvalds]

On Fri, 23 Mar 2007, john stultz wrote:
> 
> The incorrect clocksource selection is resolved w/ this patch:
> http://lkml.org/lkml/2007/3/22/287
> 
> There is still an issue of why the PIT clocksource hangs, but for the
> moment the issue its worked-around.

Hmm.. I haven't seen it until now. Is it waiting for something?

		Linus

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Chuck Ebbert]

Thomas Gleixner wrote:
> On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
>> Subject    : gettimeofday increments too slowly
>> References : http://bugzilla.kernel.org/show_bug.cgi?id=8027
>> Submitter  : David L <idht4n@hotmail.com>
>> Caused-By  : Thomas Gleixner <tglx@linutronix.de>
>>              commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2
>> Handled-By : Thomas Gleixner <tglx@linutronix.de>
>> Status     : problem is being debugged
> 
> Patch available: http://lkml.org/lkml/2007/3/22/301
> 
> commit 6b3964cde70cfe6db79d35b42137431ef7d2f7e4
> 

For the other issue raised there, clock running too slow, I now
realize there is a similar report:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231626

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Thomas Gleixner]

On Fri, 2007-03-23 at 18:23 -0400, Chuck Ebbert wrote:
> Thomas Gleixner wrote:
> > On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
> >> Subject    : gettimeofday increments too slowly
> >> References : http://bugzilla.kernel.org/show_bug.cgi?id=8027
> >> Submitter  : David L <idht4n@hotmail.com>
> >> Caused-By  : Thomas Gleixner <tglx@linutronix.de>
> >>              commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2
> >> Handled-By : Thomas Gleixner <tglx@linutronix.de>
> >> Status     : problem is being debugged
> > 
> > Patch available: http://lkml.org/lkml/2007/3/22/301
> > 
> > commit 6b3964cde70cfe6db79d35b42137431ef7d2f7e4
> > 
> 
> For the other issue raised there, clock running too slow, I now
> realize there is a similar report:
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231626

That's a different one, AFAICT. Davids problem is probably caused by me
breaking the TSC watchdog. 

/me orders paperbags prophylactically and goes back to look at the code

	tglx

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Adrian Bunk]

On Fri, Mar 23, 2007 at 06:23:17PM -0400, Chuck Ebbert wrote:
> Thomas Gleixner wrote:
> > On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
> >> Subject    : gettimeofday increments too slowly
> >> References : http://bugzilla.kernel.org/show_bug.cgi?id=8027
> >> Submitter  : David L <idht4n@hotmail.com>
> >> Caused-By  : Thomas Gleixner <tglx@linutronix.de>
> >>              commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2
> >> Handled-By : Thomas Gleixner <tglx@linutronix.de>
> >> Status     : problem is being debugged
> > 
> > Patch available: http://lkml.org/lkml/2007/3/22/301
> > 
> > commit 6b3964cde70cfe6db79d35b42137431ef7d2f7e4
> > 
> 
> For the other issue raised there, clock running too slow, I now
> realize there is a similar report:
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231626

It shouldn't be the same issue:
2.6.20-1.2925.fc6 is based in 2.6.20.3-rc1 while this issue is a
2.6.21-rc regression.
Or do the -rc kernels include parts of the -rt patchsets?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Chuck Ebbert]

Adrian Bunk wrote:
>>>
>> For the other issue raised there, clock running too slow, I now
>> realize there is a similar report:
>>
>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231626
> 
> It shouldn't be the same issue:
> 2.6.20-1.2925.fc6 is based in 2.6.20.3-rc1 while this issue is a
> 2.6.21-rc regression.
> Or do the -rc kernels include parts of the -rt patchsets?
> 

Sometimes problems leak from the next kernel version into -stable
via the stable kernel patches.

Other times the bug may have been there all along but nobody had
found it yet...

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Thomas Gleixner]

On Fri, 2007-03-23 at 23:43 +0100, Thomas Gleixner wrote:
> On Fri, 2007-03-23 at 18:23 -0400, Chuck Ebbert wrote:
> > Thomas Gleixner wrote:
> > > On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
> > >> Subject    : gettimeofday increments too slowly
> > >> References : http://bugzilla.kernel.org/show_bug.cgi?id=8027
> > >> Submitter  : David L <idht4n@hotmail.com>
> > >> Caused-By  : Thomas Gleixner <tglx@linutronix.de>
> > >>              commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2
> > >> Handled-By : Thomas Gleixner <tglx@linutronix.de>
> > >> Status     : problem is being debugged
> > > 
> > > Patch available: http://lkml.org/lkml/2007/3/22/301
> > > 
> > > commit 6b3964cde70cfe6db79d35b42137431ef7d2f7e4
> > > 
> > 
> > For the other issue raised there, clock running too slow, I now
> > realize there is a similar report:
> > 
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231626
> 
> That's a different one, AFAICT. Davids problem is probably caused by me
> breaking the TSC watchdog. 
> 
> /me orders paperbags prophylactically and goes back to look at the code

David,

can you please test the patch below ?

	tglx

--------------------->
Subject: [PATCH] clocksource: Fix thinko in watchdog selection

The watchdog implementation excludes low res / non continuous
clocksources from being selected as a watchdog reference
unintentionally.

Allow using jiffies/PIT as a watchdog reference as long as no better
clocksource is available. This is necessary to detect TSC breakage on
systems, which have no pmtimer/hpet.

The main goal of the initial patch (preventing to switch to highres/nohz
when no reliable fallback clocksource is available) is still guaranteed
by the checks in clocksource_watchdog().

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

diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index 5b0e46b..fe5c7db 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -151,7 +151,8 @@ static void clocksource_check_watchdog(struct clocksource *cs)
 			watchdog_timer.expires = jiffies + WATCHDOG_INTERVAL;
 			add_timer(&watchdog_timer);
 		}
-	} else if (cs->flags & CLOCK_SOURCE_IS_CONTINUOUS) {
+	} else {
+		if (cs->flags & CLOCK_SOURCE_IS_CONTINUOUS)
 			cs->flags |= CLOCK_SOURCE_VALID_FOR_HRES;
 
 		if (!watchdog || cs->rating > watchdog->rating) {

Re: [2/5] 2.6.21-rc4: known regressions (v2)

[Ray Lee]

Thomas Gleixner wrote:
> On Fri, 2007-03-23 at 19:48 +0100, Adrian Bunk wrote:
>> Subject    : x86_64: ACPI regression with noapic  (APICTIMER_STOPS_ON_C3?)
>> References : http://lkml.org/lkml/2007/3/8/468
>>              http://lkml.org/lkml/2007/3/22/156
>> Submitter  : Ray Lee <ray-lk@madrabbit.org>
>> Handled-By : Thomas Gleixner <tglx@linutronix.de>
>> Status     : problem is being debugged
> 
> Ray,
> 
> can you please test the patch below ?
> 
> Thanks,
> 
> 	tglx

(I wondered about the IPI on a UP system, seemed a bit weird :-).)

Works great, booting both with NOAPIC and without. *Much* thanks for
debugging this while you're also handling a bunch of other issues at
the same time.

Patch reproduced below, with an acked-by (and, uhm, a couple of spelling
fixes in the description -- don't hate me, 'kay?). Please apply before
2.6.21 final.

------------------>
Subject: [PATCH] x86_64: avoid sending LOCAL_TIMER_VECTOR IPI to itself

Ray Lee reported, that on an UP kernel with "noapic" command line option
set, the box locks hard during boot.

Adding some debug printks revealed, that the last action on the box
before stalling was "Send IPI" - a debug printk which was put into
smp_send_timer_broadcast_ipi().

It seems that send_IPI_mask(mask, LOCAL_TIMER_VECTOR) fails when
"noapic" is set on the command line on an UP kernel.

Aside of that it does not make much sense to trigger an interrupt
instead of calling the function directly on the CPU which gets the
PIT/HPET interrupt in case of broadcasting.

Reported-by: Ray Lee <ray-lk@madrabbit.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by:  Ray Lee <ray-lk@madrabbit.org>

diff --git a/arch/x86_64/kernel/apic.c b/arch/x86_64/kernel/apic.c
index 723417d..83328e1 100644
--- a/arch/x86_64/kernel/apic.c
+++ b/arch/x86_64/kernel/apic.c
@@ -930,9 +930,17 @@ EXPORT_SYMBOL(switch_APIC_timer_to_ipi);

 void smp_send_timer_broadcast_ipi(void)
 {
+	int cpu = smp_processor_id();
 	cpumask_t mask;

 	cpus_and(mask, cpu_online_map, timer_interrupt_broadcast_ipi_mask);
+
+	if (cpu_isset(cpu, mask)) {
+		cpu_clear(cpu, mask);
+		add_pda(apic_timer_irqs, 1);
+		smp_local_timer_interrupt();
+	}
+
 	if (!cpus_empty(mask)) {
 		send_IPI_mask(mask, LOCAL_TIMER_VECTOR);
 	}

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[john stultz]

On Fri, 2007-03-23 at 14:54 -0700, Linus Torvalds wrote:
> 
> On Fri, 23 Mar 2007, john stultz wrote:
> > 
> > The incorrect clocksource selection is resolved w/ this patch:
> > http://lkml.org/lkml/2007/3/22/287
> > 
> > There is still an issue of why the PIT clocksource hangs, but for the
> > moment the issue its worked-around.
> 
> Hmm.. I haven't seen it until now. Is it waiting for something?

Not really. Just waiting for Andrew to pick it up and push it on.

thanks
-john

Re: [2/5] 2.6.21-rc4: known regressions (v2)

[Thomas Gleixner]

Ray,

On Fri, 2007-03-23 at 17:14 -0700, Ray Lee wrote:
> (I wondered about the IPI on a UP system, seemed a bit weird :-).)
> 
> Works great, booting both with NOAPIC and without. *Much* thanks for
> debugging this while you're also handling a bunch of other issues at
> the same time.

Thank you for debugging and excellent problem descriptions !

> Patch reproduced below, with an acked-by (and, uhm, a couple of spelling
> fixes in the description -- don't hate me, 'kay?).

I know that my English sucks.

Thanks,

	tglx

2.6.21-rc4: known regressions with patches (v2)

[Adrian Bunk]

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


Subject    : gettimeofday increments too slowly
References : http://bugzilla.kernel.org/show_bug.cgi?id=8027
             http://lkml.org/lkml/2007/3/23/329
Submitter  : David L <idht4n@hotmail.com>
Caused-By  : Thomas Gleixner <tglx@linutronix.de>
             commit 92c7e00254b2d0efc1e36ac3e45474ce1871b6b2
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Patch      : http://lkml.org/lkml/2007/3/23/329
Status     : patch available


Subject    : boot hangs during IDE detection  (clocksource)
References : http://lkml.org/lkml/2007/3/19/465
Submitter  : Bob Tracy <rct@gherkin.frus.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    : 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

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Thomas Gleixner]

Emil,

On Fri, 2007-03-23 at 20:22 +0100, Thomas Gleixner wrote:
> On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
> > Subject    : dynticks makes ksoftirqd1 use unreasonable amount of cpu time
> > References : http://bugzilla.kernel.org/show_bug.cgi?id=8100
> > Submitter  : Emil Karlson <jkarlson@cc.hut.fi>
> > Handled-By : Thomas Gleixner <tglx@linutronix.de>
> > Status     : problem is being debugged
> 
> The problem is not reproducible on any of my machines.
> 

I've uploaded a patch against 2.6.21-rc4 to

http://tglx.de/private/tglx/2.6.21-rc4-trace/2.6.21-rc4-trace.patch.bz2

It contains all changes in Linus tree since -rc4 plus the two pending
fixes (http://tglx.de/private/tglx/2.6.21-rc4-pending/) along with a
backport of the latency tracer from the realtime preemption patch.

Can you please apply the patch on top of -rc4 and build it with the
configuration, which exposes this strange behaviour. Please enable also
CONFIG_LATENCY_TRACE in the Kernel hacking menu.

When the problem is visible, then run trace-it
(http://tglx.de/private/tglx/2.6.21-rc4-trace/trace-it.c) as root:

# trace-it >trace.txt

This captures roughly one second of kernel code pathes. Please stick
trace.txt into Bugzilla.

Thanks,

	tglx

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Michal Piotrowski]

Hi,

On 23/03/07, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
> > Subject    : soft lockup detected on CPU#0
> > References : http://lkml.org/lkml/2007/3/3/152
> > Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
> > Handled-By : Thomas Gleixner <tglx@linutronix.de>
> >              Ingo Molnar <mingo@elte.hu>
> > Status     : unknown
>
> Michal,
>
> any news on that one ?
>
> You said the same problem exists in 2.6.20.1. Has this been resolved in
> 2.6.20.2/3

Yes, I tried 2.6.20.4 and it works fine.

>
> Thanks,
>
>         tglx
>
>
>

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

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Thomas Gleixner]

On Sat, 2007-03-24 at 14:59 +0100, Michal Piotrowski wrote:
> On 23/03/07, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
> > > Subject    : soft lockup detected on CPU#0
> > > References : http://lkml.org/lkml/2007/3/3/152
> > > Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
> > > Handled-By : Thomas Gleixner <tglx@linutronix.de>
> > >              Ingo Molnar <mingo@elte.hu>
> > > Status     : unknown
> >
> > Michal,
> >
> > any news on that one ?
> >
> > You said the same problem exists in 2.6.20.1. Has this been resolved in
> > 2.6.20.2/3
> 
> Yes, I tried 2.6.20.4 and it works fine.

Is it solved in Linus latest too ?

	tglx

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Michal Piotrowski]

On 24/03/07, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Sat, 2007-03-24 at 14:59 +0100, Michal Piotrowski wrote:
> > On 23/03/07, Thomas Gleixner <tglx@linutronix.de> wrote:
> > > On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
> > > > Subject    : soft lockup detected on CPU#0
> > > > References : http://lkml.org/lkml/2007/3/3/152
> > > > Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
> > > > Handled-By : Thomas Gleixner <tglx@linutronix.de>
> > > >              Ingo Molnar <mingo@elte.hu>
> > > > Status     : unknown
> > >
> > > Michal,
> > >
> > > any news on that one ?
> > >
> > > You said the same problem exists in 2.6.20.1. Has this been resolved in
> > > 2.6.20.2/3
> >
> > Yes, I tried 2.6.20.4 and it works fine.
>
> Is it solved in Linus latest too ?

Yes, it's solved.

Adrian, please remove this bug from known regressions list.
It's fixed in the latest -git and -stable.

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

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Thomas Meyer]

Adrian Bunk schrieb:
> Subject    : second suspend to disk in a row results in an oops  (libata?)
> References : http://lkml.org/lkml/2007/3/17/43
> Submitter  : Thomas Meyer <thomas@m3y3r.de>
> Status     : unknown
>   

The problem is identified: http://lkml.org/lkml/2007/3/22/150

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Eric W. Biederman]

Thomas Meyer <thomas@m3y3r.de> writes:

> Adrian Bunk schrieb:
>> Subject    : second suspend to disk in a row results in an oops  (libata?)
>> References : http://lkml.org/lkml/2007/3/17/43
>> Submitter  : Thomas Meyer <thomas@m3y3r.de>
>> Status     : unknown
>>   
>
> The problem is identified: http://lkml.org/lkml/2007/3/22/150

Given the description above I'm a little confused.  Doesn't this
happen every time now?

Or was this happening only the second time before I started my msi
fixes... 

Eric

Re: [2/5] 2.6.21-rc4: known regressions (v2)

[Ray Lee]

Thomas Gleixner wrote:
>> Patch reproduced below, with an acked-by (and, uhm, a couple of spelling
>> fixes in the description -- don't hate me, 'kay?).
> 
> I know that my English sucks.

Your English is fantastic, and far better than my German ever will be, so
no worries :-).

~r.

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Thomas Meyer]

Eric W. Biederman schrieb:
> Thomas Meyer <thomas@m3y3r.de> writes:
>
>   
>> Adrian Bunk schrieb:
>>     
>>> Subject    : second suspend to disk in a row results in an oops  (libata?)
>>> References : http://lkml.org/lkml/2007/3/17/43
>>> Submitter  : Thomas Meyer <thomas@m3y3r.de>
>>> Status     : unknown
>>>   
>>>       
>> The problem is identified: http://lkml.org/lkml/2007/3/22/150
>>     
>
> Given the description above I'm a little confused.  Doesn't this
> happen every time now?
>   
With current git head the oops happens in the second suspend to disk
attempt in a row.
> Or was this happening only the second time before I started my msi
> fixes... 
>   
So i think, that the current git head already contains your msi fixes.
I don't know if this already happend before your msi changes, but i can
test 2.6.20 if you like to?

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Eric W. Biederman]

Thomas Meyer <thomas@m3y3r.de> writes:

> Eric W. Biederman schrieb:
>> Thomas Meyer <thomas@m3y3r.de> writes:
>>
>>   
>>> Adrian Bunk schrieb:
>>>     
>>>> Subject    : second suspend to disk in a row results in an oops  (libata?)
>>>> References : http://lkml.org/lkml/2007/3/17/43
>>>> Submitter  : Thomas Meyer <thomas@m3y3r.de>
>>>> Status     : unknown
>>>>   
>>>>       
>>> The problem is identified: http://lkml.org/lkml/2007/3/22/150
>>>     
>>
>> Given the description above I'm a little confused.  Doesn't this
>> happen every time now?
>>   
> With current git head the oops happens in the second suspend to disk
> attempt in a row.

Odd.  I would have thought the oops happened in the first resume, not
the second. 

Hmm.  It may have something to do with the ``managed'' driver
aspect of this as well..

>> Or was this happening only the second time before I started my msi
>> fixes... 
>>   
> So i think, that the current git head already contains your msi fixes.

Yes it does.

> I don't know if this already happend before your msi changes, but i can
> test 2.6.20 if you like to?

Sure.  A data point if you boot with nomsi or have a kernel compiled
without msi support would be interesting as well.

As the problem case may not show up without msi support in the picture.

Eric

Re: [PATCH] x86_64: avoid sending LOCAL_TIMER_VECTOR IPI to itself

[Ingo Molnar]

* Ray Lee <ray-lk@madrabbit.org> wrote:

> Subject: [PATCH] x86_64: avoid sending LOCAL_TIMER_VECTOR IPI to 
> itself
> 
> Ray Lee reported, that on an UP kernel with "noapic" command line 
> option set, the box locks hard during boot.

i think this bug deserves a bit more attention, because similar problems 
could be in other codepaths too.

the problem here is that we tried to send an IPI to ourselves - which 
confused Ray's system which has an IO-APIC, but where due to noapic we 
keep the IO-APIC in its BIOS default.

this isnt a new problem: the new time code just exposed it more 
prominently that it was visible before. (the SMP kernel probably would 
hang in a similar way on Ray's system)

i dont see any clear debugging in the IPI code that excludes self-IPIs. 
I think the only valid way to do that is to use DEST_SELF. Andi?

	Ingo

Re: [6/6] 2.6.21-rc4: known regressions

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Mon, 19 Mar 2007 19:38:29 -0700 (PDT)

> From: Adrian Bunk <bunk@stusta.de>
> Date: Sun, 18 Mar 2007 19:49:38 +0100
> 
> > Subject    : ipv6 crash
> > References : http://lkml.org/lkml/2007/3/10/2
> > Submitter  : Len Brown <lenb@kernel.org>
> > Status     : unknown
> 
> This is caused by some problem in the router round-robin code in
> net/ipv6/route.c:rt6_select()
 ...
> I'll see if I can come up with something to fix this properly.

Here is the fix I came up with and just posted to netdev for
a quick review, I'll push this to the appropriate places soon
if nobody spots any problems in it.

commit 4c68db63b8314df3cf30b7fe595a1b8935bb2cb0
Author: David S. Miller <davem@sunset.davemloft.net>
Date:   Sat Mar 24 12:06:32 2007 -0700

    [IPV6]: Fix routing round-robin locking.
    
    As per RFC2461, section 6.3.6, item #2, when no routers on the
    matching list are known to be reachable or probably reachable we
    do round robin on those available routes so that we make sure
    to probe as many of them as possible to detect when one becomes
    reachable faster.
    
    Each routing table has a rwlock protecting the tree and the linked
    list of routes at each leaf.  The round robin code executes during
    lookup and thus with the rwlock taken as a reader.  A small local
    spinlock tries to provide protection but this does not work at all
    for two reasons:
    
    1) The round-robin list manipulation, as coded, goes like this (with
       read lock held):
    
    	walk routes finding head and tail
    
    	spin_lock();
    	rotate list using head and tail
    	spin_unlock();
    
       While one thread is rotating the list, another thread can
       end up with stale values of head and tail and then proceed
       to corrupt the list when it gets the lock.  This ends up causing
       the OOPS in fib6_add() later onthat many people have been hitting.
    
    2) All the other code paths that run with the rwlock held as
       a reader do not expect the list to change on them, they
       expect it to remain completely fixed while they hold the
       lock in that way.
    
    So, simply stated, it is impossible to implement this correctly using
    a manipulation of the list without violating the rwlock locking
    semantics.
    
    Reimplement using a per-fib6_node round-robin pointer.  This way we
    don't need to manipulate the list at all, and since the round-robin
    pointer can only ever point to real existing entries we don't need
    to perform any locking on the changing of the round-robin pointer
    itself.  We only need to reset the round-robin pointer to NULL when
    the entry it is pointing to is removed.
    
    The idea is from Thomas Graf and it is very similar to how this
    was implemented before the advanced router selection code when in.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
index 9eda572..cf355a3 100644
--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -58,6 +58,7 @@ struct fib6_node
 	__u16			fn_bit;		/* bit key */
 	__u16			fn_flags;
 	__u32			fn_sernum;
+	struct rt6_info		*rr_ptr;
 };
 
 #ifndef CONFIG_IPV6_SUBTREES
diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
index f4d7be7..c46f909 100644
--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -1109,6 +1109,10 @@ static void fib6_del_route(struct fib6_node *fn, struct rt6_info **rtp,
 	rt6_stats.fib_rt_entries--;
 	rt6_stats.fib_discarded_routes++;
 
+	/* Reset round-robin state, if necessary */
+	if (fn->rr_ptr == rt)
+		fn->rr_ptr = NULL;
+
 	/* Adjust walkers */
 	read_lock(&fib6_walker_lock);
 	FOR_WALKERS(w) {
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index a6b3117..3931b33 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -363,55 +363,76 @@ static int rt6_score_route(struct rt6_info *rt, int oif,
 	return m;
 }
 
-static struct rt6_info *rt6_select(struct rt6_info **head, int oif,
-				   int strict)
+static struct rt6_info *find_match(struct rt6_info *rt, int oif, int strict,
+				   int *mpri, struct rt6_info *match)
 {
-	struct rt6_info *match = NULL, *last = NULL;
-	struct rt6_info *rt, *rt0 = *head;
-	u32 metric;
+	int m;
+
+	if (rt6_check_expired(rt))
+		goto out;
+
+	m = rt6_score_route(rt, oif, strict);
+	if (m < 0)
+		goto out;
+
+	if (m > *mpri) {
+		if (strict & RT6_LOOKUP_F_REACHABLE)
+			rt6_probe(match);
+		*mpri = m;
+		match = rt;
+	} else if (strict & RT6_LOOKUP_F_REACHABLE) {
+		rt6_probe(rt);
+	}
+
+out:
+	return match;
+}
+
+static struct rt6_info *find_rr_leaf(struct fib6_node *fn,
+				     struct rt6_info *rr_head,
+				     u32 metric, int oif, int strict)
+{
+	struct rt6_info *rt, *match;
 	int mpri = -1;
 
-	RT6_TRACE("%s(head=%p(*head=%p), oif=%d)\n",
-		  __FUNCTION__, head, head ? *head : NULL, oif);
+	match = NULL;
+	for (rt = rr_head; rt && rt->rt6i_metric == metric;
+	     rt = rt->u.dst.rt6_next)
+		match = find_match(rt, oif, strict, &mpri, match);
+	for (rt = fn->leaf; rt && rt != rr_head && rt->rt6i_metric == metric;
+	     rt = rt->u.dst.rt6_next)
+		match = find_match(rt, oif, strict, &mpri, match);
 
-	for (rt = rt0, metric = rt0->rt6i_metric;
-	     rt && rt->rt6i_metric == metric && (!last || rt != rt0);
-	     rt = rt->u.dst.rt6_next) {
-		int m;
+	return match;
+}
 
-		if (rt6_check_expired(rt))
-			continue;
+static struct rt6_info *rt6_select(struct fib6_node *fn, int oif, int strict)
+{
+	struct rt6_info *match, *rt0;
 
-		last = rt;
+	RT6_TRACE("%s(fn->leaf=%p, oif=%d)\n",
+		  __FUNCTION__, fn->leaf, oif);
 
-		m = rt6_score_route(rt, oif, strict);
-		if (m < 0)
-			continue;
+	rt0 = fn->rr_ptr;
+	if (!rt0)
+		fn->rr_ptr = rt0 = fn->leaf;
 
-		if (m > mpri) {
-			if (strict & RT6_LOOKUP_F_REACHABLE)
-				rt6_probe(match);
-			match = rt;
-			mpri = m;
-		} else if (strict & RT6_LOOKUP_F_REACHABLE) {
-			rt6_probe(rt);
-		}
-	}
+	match = find_rr_leaf(fn, rt0, rt0->rt6i_metric, oif, strict);
 
 	if (!match &&
-	    (strict & RT6_LOOKUP_F_REACHABLE) &&
-	    last && last != rt0) {
+	    (strict & RT6_LOOKUP_F_REACHABLE)) {
+		struct rt6_info *next = rt0->u.dst.rt6_next;
+
 		/* no entries matched; do round-robin */
-		static DEFINE_SPINLOCK(lock);
-		spin_lock(&lock);
-		*head = rt0->u.dst.rt6_next;
-		rt0->u.dst.rt6_next = last->u.dst.rt6_next;
-		last->u.dst.rt6_next = rt0;
-		spin_unlock(&lock);
+		if (!next || next->rt6i_metric != rt0->rt6i_metric)
+			next = fn->leaf;
+
+		if (next != rt0)
+			fn->rr_ptr = next;
 	}
 
-	RT6_TRACE("%s() => %p, score=%d\n",
-		  __FUNCTION__, match, mpri);
+	RT6_TRACE("%s() => %p\n",
+		  __FUNCTION__, match);
 
 	return (match ? match : &ip6_null_entry);
 }
@@ -657,7 +678,7 @@ restart_2:
 	fn = fib6_lookup(&table->tb6_root, &fl->fl6_dst, &fl->fl6_src);
 
 restart:
-	rt = rt6_select(&fn->leaf, fl->iif, strict | reachable);
+	rt = rt6_select(fn, fl->iif, strict | reachable);
 	BACKTRACK(&fl->fl6_src);
 	if (rt == &ip6_null_entry ||
 	    rt->rt6i_flags & RTF_CACHE)
@@ -752,7 +773,7 @@ restart_2:
 	fn = fib6_lookup(&table->tb6_root, &fl->fl6_dst, &fl->fl6_src);
 
 restart:
-	rt = rt6_select(&fn->leaf, fl->oif, strict | reachable);
+	rt = rt6_select(fn, fl->oif, strict | reachable);
 	BACKTRACK(&fl->fl6_src);
 	if (rt == &ip6_null_entry ||
 	    rt->rt6i_flags & RTF_CACHE)

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Thomas Meyer]

Eric W. Biederman schrieb:
>
> Odd.  I would have thought the oops happened in the first resume, not
> the second. 
>
> Hmm.  It may have something to do with the ``managed'' driver
> aspect of this as well..
>   
No. I don't think so. The problem is caused by this sequence: (the info
is always before entry of a function and before the exit of a function):

1.) Normal boot
[kernel] ahci 0000:00:1f.2: version 2.1
[kernel] pci_enable_device: dev= c1a59000
[kernel] pci_enable_device: irq= 0
[kernel] pci_enable_device: msi_enabled= 0
[kernel] PCI: Enabling device 0000:00:1f.2 (0005 -> 0007)
[kernel] ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) ->
IRQ 19
[kernel] pci_enable_device: dev= c1a59000
[kernel] pci_enable_device: irq= 19
[kernel] pci_enable_device: msi_enabled= 0

2.) msi irq 218 gets assigned

3) First suspend to disk. Consists of
3a) Suspend devices
[kernel] ahci 0000:00:1f.2: freeze
[kernel] pci_disable_device: dev= c1a59000
[kernel] pci_disable_device: irq= 218
[kernel] pci_disable_device: msi_enabled= 1
[kernel] ACPI: PCI interrupt for device 0000:00:1f.2 disabled
[kernel] pci_disable_device: dev= c1a59000
[kernel] pci_disable_device: irq= 218
[kernel] pci_disable_device: msi_enabled= 1

3b) Disable non-boot cpus
3c) Snapshot memory
3d) Enable non-boot cpus
3e) Resume devices (after snapshot!)
[kernel] ahci 0000:00:1f.2: resuming
[kernel] PM: Writing back config space on device 0000:00:1f.2 at offset
1 (was 2b00403, writing 2b00407)
[kernel] pci_enable_device: dev= c1a59000
[kernel] pci_enable_device: irq= 218
[kernel] pci_enable_device: msi_enabled= 1
[kernel] ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) ->
IRQ 19
[kernel] pci_enable_device: dev= c1a59000
[kernel] pci_enable_device: irq= 19
[kernel] pci_enable_device: msi_enabled= 1

3f) Write memory image
3g) Power down + reboot

4a) Normal start and restore memory image
4b) Enable non-boot cpus
4c) Resume devices
[kernel] ahci 0000:00:1f.2: resuming
[kernel] PM: Writing back config space on device 0000:00:1f.2 at offset
1 (was 2b00403, writing 2b00407)
[kernel] pci_enable_device: dev= c1a59000
[kernel] pci_enable_device: irq= 218
[kernel] pci_enable_device: msi_enabled= 1
[kernel] ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) ->
IRQ 19
[kernel] pci_enable_device: dev= c1a59000
[kernel] pci_enable_device: irq= 19
[kernel] pci_enable_device: msi_enabled= 1
Now the system is running with irq=19 and msi enabled=1. So let's
suspend again:

5) Second suspend to disk consists of
5a) Suspend devices
[kernel] ahci 0000:00:1f.2: freeze
[kernel] pci_disable_device: dev= c1a59000
[kernel] pci_disable_device: irq= 19
[kernel] pci_disable_device: msi_enabled= 1
[kernel] ACPI: PCI interrupt for device 0000:00:1f.2 disabled
[kernel] pci_disable_device: dev= c1a59000
[kernel] pci_disable_device: irq= 19
[kernel] pci_disable_device: msi_enabled= 1

5b) Disable non-boot cpus
5c) Snapshot memory
5d) Enable non-boot cpus
5e) Resume devices
[kernel] pci_enable_device: dev= c1a59000
[kernel] pci_enable_device: irq= 19
[kernel] pci_enable_device: msi_enabled= 1

-> OOPS in restore_msi because it tries to access msi structure for irq
19 and not 218.

So i guess this has nothing to do with the managed pci functions?

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Eric W. Biederman]

Thomas Meyer <thomas@m3y3r.de> writes:

> Eric W. Biederman schrieb:
>>
>> Odd.  I would have thought the oops happened in the first resume, not
>> the second. 
>>
>> Hmm.  It may have something to do with the ``managed'' driver
>> aspect of this as well..
>>   
> No. I don't think so. The problem is caused by this sequence: (the info
> is always before entry of a function and before the exit of a function):

Ok.  Thanks.   It is the ordering of events that keeps it
from showing up.  The problem happens the first time but only
after we have restored msi state so we don't see the ill effects
until the second time.


Ok staring at the code and thinking about the problem.  The only
thing that pci_enable_device does (except messing with irqs is
flip enable bits).   Further pci_enable_device only messes with
on 5 architectures.   Only ia64 really cares.  i386 and x86_64
it is simply delaying work until we need it.  frv doesn't
really care it just pokes the irq value back into the hardware
for some reason.  cris just sets a hard coded value.  Does cris
only have one pci irq?

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.

Thomas could you verify the patch below makes the problem go away
for you.

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.

Tony, Len before we merge any fixes for 2.6.21-rcX I'd like to at
least get an ack on the long term direction.

Thanks,
Eric


diff --git a/arch/cris/arch-v32/drivers/pci/bios.c b/arch/cris/arch-v32/drivers/pci/bios.c
index a2b9c60..5b79a7a 100644
--- a/arch/cris/arch-v32/drivers/pci/bios.c
+++ b/arch/cris/arch-v32/drivers/pci/bios.c
@@ -100,7 +100,9 @@ int pcibios_enable_device(struct pci_dev *dev, int mask)
 	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)
diff --git a/arch/frv/mb93090-mb00/pci-vdk.c b/arch/frv/mb93090-mb00/pci-vdk.c
index f7279d7..0b581e3 100644
--- a/arch/frv/mb93090-mb00/pci-vdk.c
+++ b/arch/frv/mb93090-mb00/pci-vdk.c
@@ -466,6 +466,7 @@ int pcibios_enable_device(struct pci_dev *dev, int mask)
 
 	if ((err = pcibios_enable_resources(dev, mask)) < 0)
 		return err;
-	pcibios_enable_irq(dev);
+	if (!dev->msi_enabled)
+		pcibios_enable_irq(dev);
 	return 0;
 }
diff --git a/arch/i386/pci/common.c b/arch/i386/pci/common.c
index 1bb0693..a990a6c 100644
--- a/arch/i386/pci/common.c
+++ b/arch/i386/pci/common.c
@@ -426,11 +426,13 @@ int pcibios_enable_device(struct pci_dev *dev, int mask)
 	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);
 }
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 474d179..f8bcccd 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -557,14 +557,18 @@ pcibios_enable_device (struct pci_dev *dev, int mask)
 	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

Re: [1/5] 2.6.21-rc4: known regressions (v2)

[David Miller]

From: Adrian Bunk <bunk@stusta.de>
Date: Fri, 23 Mar 2007 19:48:17 +0100

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

Not enough information in his report, for example for the
case he says does not work he fails to indicate what kernel
or system type the Client runs on.

Furthermore, his scripts don't even execute properly when
I try to run them myself, for example server.py gives me
this syntax error when python tries to parse the script:

davem@sunset:~/src/GIT/net-2.6$ /usr/bin/python server.py
  File "server.py", line 9
    struct sockaddr_in ServerAddr;
                     ^
SyntaxError: invalid syntax


Can someone help de-crapify this bug report?

Re: [1/5] 2.6.21-rc4: known regressions (v2)

[Paul Collins]

David Miller <davem@davemloft.net> writes:

> Furthermore, his scripts don't even execute properly when
> I try to run them myself, for example server.py gives me
> this syntax error when python tries to parse the script:
>
> davem@sunset:~/src/GIT/net-2.6$ /usr/bin/python server.py
>   File "server.py", line 9
>     struct sockaddr_in ServerAddr;
>                      ^
> SyntaxError: invalid syntax

The reporter's client and server code seem to be C, but if the he thinks
they should be Python, I guess they're not the correct ones anyway.

-- 
Paul Collins
Wellington, New Zealand

Dag vijandelijk luchtschip de huismeester is dood

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Thomas Gleixner]

On Sun, 2007-03-25 at 09:11 +0200, Michael S. Tsirkin wrote:
> > I lost track of Michaels various nested problems.
> > 
> > Michael can you please give a summary on _all_ entries in the
> > regressions list against Linus latest ?
> 
> I tested 2 different configurations on my T60:
> - With CONFIG_NO_HZ enabled.
>   I tested this on -rc1, and have not retested with CONFIG_NO_HZ since.
>   Observed behaviour: the system would not come out of suspend to RAM.
>   After I press Fn/F4 the crescent LED starts blinking so it seems Linux started
>   doing something.
>   This is a problem but not a regression as such, since CONFIG_NO_HZ is new
>   in 2.6.21.

It needs to be fixed before 2.6.21 final nevertheless.

> - Without CONFIG_NO_HZ
>   I last tested this with cd05a1f818073a623455a58e756c5b419fc98db9.
>   After systems comes out of suspend to ram, I observed the following
>   behaviour (I used s2ram from console):
>   1. The first disk access takes much longer than with 2.6.20
>   2. System clock does not advance (date always reports the same time)
>   3. After an attempt to switch to X, X starts drawing some windows and then hangs
> 
>   All 3 issues are new and did not occur under 2.6.20, so this is a regression.
>   Attached is a full dmesg from boot to resume.

There is not much interesting to see in the log.

Can you please test the following:

Add "clocksource=acpi_pm" to the kernel commandline.

If this does not change anything, then disable CONFIG_HPET and retry.


One thing in the log is indeed scary:

[    2.959150] Calibrating delay using timer specific routine.. 20089.12
BogoMIPS (lpj=100445639)

This is after the reboot, but it is not related to your problem. This is
a different problem, which needs urgent attention.

Adrian, can you open a seperate entry for this please ? It is not a new
thing, this can be observed with older kernels as well, but it needs to
be addressed. It probably needs a similar solution as I did for the
local apic timer calibration.

	tglx

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Michael S. Tsirkin]

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

> > - Without CONFIG_NO_HZ
> >   I last tested this with cd05a1f818073a623455a58e756c5b419fc98db9.
> >   After systems comes out of suspend to ram, I observed the following
> >   behaviour (I used s2ram from console):
> >   1. The first disk access takes much longer than with 2.6.20
> >   2. System clock does not advance (date always reports the same time)
> >   3. After an attempt to switch to X, X starts drawing some windows and then hangs
> > 
> >   All 3 issues are new and did not occur under 2.6.20, so this is a regression.
> >   Attached is a full dmesg from boot to resume.
> 
> There is not much interesting to see in the log.
> 
> Can you please test the following:
> 
> Add "clocksource=acpi_pm" to the kernel commandline.
> 
> If this does not change anything, then disable CONFIG_HPET and retry.

I have:
$ grep CONFIG_HPET .config
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_HPET is not set

so I think all these tests were done with CONFIG_HPET=n.

Given this, does it still make sense to test clocksource=acpi_pm?

I attach my .config for reference.

-- 
MST

[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 49250 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.21-rc4
# Wed Mar 21 18:12:22 2007
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION="-work"
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_CPUSETS is not set
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y

#
# Block layer
#
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"

#
# Processor type and features
#
# CONFIG_TICK_ONESHOT is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_SMP=y
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_PARAVIRT is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
CONFIG_MPENTIUMM=y
# CONFIG_MCORE2 is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_NR_CPUS=8
# CONFIG_SCHED_SMT is not set
CONFIG_SCHED_MC=y
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_BKL=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
# CONFIG_X86_MCE_P4THERMAL is not set
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_3G_OPT is not set
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_IRQBALANCE=y
# CONFIG_SECCOMP is not set
CONFIG_HZ_100=y
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=100
CONFIG_KEXEC=y
CONFIG_PHYSICAL_START=0x100000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x100000
CONFIG_HOTPLUG_CPU=y
CONFIG_COMPAT_VDSO=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
CONFIG_PM_LEGACY=y
CONFIG_PM_DEBUG=y
# CONFIG_DISABLE_CONSOLE_SUSPEND is not set
# CONFIG_PM_TRACE is not set
# CONFIG_PM_SYSFS_DEPRECATED is not set
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_STD_PARTITION="/dev/sda6"
CONFIG_SUSPEND_SMP=y

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_SLEEP_PROC_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
# CONFIG_ACPI_BAY is not set
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
CONFIG_ACPI_IBM=y
CONFIG_ACPI_IBM_BAY=y
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
# CONFIG_ACPI_SBS is not set

#
# APM (Advanced Power Management) BIOS Support
#
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
# CONFIG_CPU_FREQ_DEBUG is not set
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_STAT_DETAILS=y
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=m
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m

#
# CPUFreq processor drivers
#
# CONFIG_X86_ACPI_CPUFREQ is not set
# CONFIG_X86_POWERNOW_K6 is not set
# CONFIG_X86_POWERNOW_K7 is not set
# CONFIG_X86_POWERNOW_K8 is not set
# CONFIG_X86_GX_SUSPMOD is not set
CONFIG_X86_SPEEDSTEP_CENTRINO=m
CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=y
CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y
# CONFIG_X86_SPEEDSTEP_ICH is not set
# CONFIG_X86_SPEEDSTEP_SMI is not set
# CONFIG_X86_P4_CLOCKMOD is not set
# CONFIG_X86_CPUFREQ_NFORCE2 is not set
# CONFIG_X86_LONGRUN is not set
# CONFIG_X86_LONGHAUL is not set
# CONFIG_X86_E_POWERSAVER is not set

#
# shared options
#
CONFIG_X86_ACPI_CPUFREQ_PROC_INTF=y
# CONFIG_X86_SPEEDSTEP_LIB is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCIEPORTBUS=y
# CONFIG_HOTPLUG_PCI_PCIE is not set
CONFIG_PCIEAER=y
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_DEBUG is not set
CONFIG_HT_IRQ=y
CONFIG_ISA_DMA_API=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
CONFIG_K8_NB=y

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# PCI Hotplug Support
#
CONFIG_HOTPLUG_PCI=y
# CONFIG_HOTPLUG_PCI_FAKE is not set
# CONFIG_HOTPLUG_PCI_COMPAQ is not set
# CONFIG_HOTPLUG_PCI_IBM is not set
CONFIG_HOTPLUG_PCI_ACPI=y
CONFIG_HOTPLUG_PCI_ACPI_IBM=y
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
CONFIG_NET_IPGRE=m
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
# CONFIG_INET_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK is not set
CONFIG_NF_CONNTRACK_ENABLED=y
CONFIG_NF_CONNTRACK_SUPPORT=y
# CONFIG_IP_NF_CONNTRACK_SUPPORT is not set
CONFIG_NF_CONNTRACK=y
# CONFIG_NF_CT_ACCT is not set
# CONFIG_NF_CONNTRACK_MARK is not set
# CONFIG_NF_CONNTRACK_EVENTS is not set
# CONFIG_NF_CT_PROTO_SCTP is not set
# CONFIG_NF_CONNTRACK_AMANDA is not set
CONFIG_NF_CONNTRACK_FTP=y
# CONFIG_NF_CONNTRACK_H323 is not set
# CONFIG_NF_CONNTRACK_IRC is not set
# CONFIG_NF_CONNTRACK_NETBIOS_NS is not set
# CONFIG_NF_CONNTRACK_PPTP is not set
# CONFIG_NF_CONNTRACK_SANE is not set
# CONFIG_NF_CONNTRACK_SIP is not set
# CONFIG_NF_CONNTRACK_TFTP is not set
CONFIG_NETFILTER_XTABLES=y
# CONFIG_NETFILTER_XT_TARGET_CLASSIFY is not set
# CONFIG_NETFILTER_XT_TARGET_CONNMARK is not set
# CONFIG_NETFILTER_XT_TARGET_DSCP is not set
# CONFIG_NETFILTER_XT_TARGET_MARK is not set
# CONFIG_NETFILTER_XT_TARGET_NFQUEUE is not set
# CONFIG_NETFILTER_XT_TARGET_NFLOG is not set
# CONFIG_NETFILTER_XT_TARGET_TCPMSS is not set
# CONFIG_NETFILTER_XT_MATCH_COMMENT is not set
# CONFIG_NETFILTER_XT_MATCH_CONNBYTES is not set
# CONFIG_NETFILTER_XT_MATCH_CONNMARK is not set
# CONFIG_NETFILTER_XT_MATCH_CONNTRACK is not set
# CONFIG_NETFILTER_XT_MATCH_DCCP is not set
# CONFIG_NETFILTER_XT_MATCH_DSCP is not set
# CONFIG_NETFILTER_XT_MATCH_ESP is not set
# CONFIG_NETFILTER_XT_MATCH_HELPER is not set
# CONFIG_NETFILTER_XT_MATCH_LENGTH is not set
CONFIG_NETFILTER_XT_MATCH_LIMIT=y
CONFIG_NETFILTER_XT_MATCH_MAC=y
# CONFIG_NETFILTER_XT_MATCH_MARK is not set
# CONFIG_NETFILTER_XT_MATCH_POLICY is not set
# CONFIG_NETFILTER_XT_MATCH_MULTIPORT is not set
# CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set
# CONFIG_NETFILTER_XT_MATCH_QUOTA is not set
# CONFIG_NETFILTER_XT_MATCH_REALM is not set
# CONFIG_NETFILTER_XT_MATCH_SCTP is not set
CONFIG_NETFILTER_XT_MATCH_STATE=y
# CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set
# CONFIG_NETFILTER_XT_MATCH_STRING is not set
# CONFIG_NETFILTER_XT_MATCH_TCPMSS is not set
# CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set

#
# IP: Netfilter Configuration
#
CONFIG_NF_CONNTRACK_IPV4=y
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_IPRANGE=m
# CONFIG_IP_NF_MATCH_TOS is not set
# CONFIG_IP_NF_MATCH_RECENT is not set
# CONFIG_IP_NF_MATCH_ECN is not set
# CONFIG_IP_NF_MATCH_AH is not set
# CONFIG_IP_NF_MATCH_TTL is not set
# CONFIG_IP_NF_MATCH_OWNER is not set
# CONFIG_IP_NF_MATCH_ADDRTYPE is not set
CONFIG_IP_NF_FILTER=y
# CONFIG_IP_NF_TARGET_REJECT is not set
CONFIG_IP_NF_TARGET_LOG=y
# CONFIG_IP_NF_TARGET_ULOG is not set
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
# CONFIG_IP_NF_TARGET_MASQUERADE is not set
# CONFIG_IP_NF_TARGET_REDIRECT is not set
# CONFIG_IP_NF_TARGET_NETMAP is not set
# CONFIG_IP_NF_TARGET_SAME is not set
# CONFIG_NF_NAT_SNMP_BASIC is not set
CONFIG_NF_NAT_FTP=m
# CONFIG_NF_NAT_IRC is not set
# CONFIG_NF_NAT_TFTP is not set
# CONFIG_NF_NAT_AMANDA is not set
# CONFIG_NF_NAT_PPTP is not set
# CONFIG_NF_NAT_H323 is not set
# CONFIG_NF_NAT_SIP is not set
CONFIG_IP_NF_MANGLE=m
# CONFIG_IP_NF_TARGET_TOS is not set
# CONFIG_IP_NF_TARGET_ECN is not set
# CONFIG_IP_NF_TARGET_TTL is not set
# CONFIG_IP_NF_TARGET_CLUSTERIP is not set
# CONFIG_IP_NF_RAW is not set
# CONFIG_IP_NF_ARPTABLES is not set

#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set

#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_IEEE80211=y
# CONFIG_IEEE80211_DEBUG is not set
CONFIG_IEEE80211_CRYPT_WEP=y
CONFIG_IEEE80211_CRYPT_CCMP=y
CONFIG_IEEE80211_CRYPT_TKIP=y
# CONFIG_IEEE80211_SOFTMAC is not set
CONFIG_WIRELESS_EXT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set

#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
# CONFIG_PARPORT_SERIAL is not set
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
CONFIG_PARPORT_1284=y

#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
CONFIG_PNPACPI=y

#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_MSI_LAPTOP is not set
# CONFIG_SONY_LAPTOP is not set

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_IDE_MAX_HWIFS=4
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_BLK_DEV_IDEACPI is not set
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
# CONFIG_IDE_GENERIC is not set
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_GENERIC is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_CS5535 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_JMICRON is not set
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_IT8213 is not set
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
CONFIG_BLK_DEV_VIA82CXXX=y
# CONFIG_BLK_DEV_TC86C001 is not set
# CONFIG_IDE_ARM is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
# CONFIG_SCSI_PROC_FS is not set

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=y
# CONFIG_CHR_DEV_SCH is not set

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
CONFIG_SCSI_ISCSI_ATTRS=m
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set

#
# SCSI low-level drivers
#
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_SRP is not set

#
# Serial ATA (prod) and Parallel ATA (experimental) drivers
#
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_SATA_AHCI=y
# CONFIG_SATA_SVW is not set
CONFIG_ATA_PIIX=y
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIL24 is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# CONFIG_SATA_INIC162X is not set
CONFIG_SATA_INTEL_COMBINED=y
CONFIG_SATA_ACPI=y
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CS5535 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
# CONFIG_ATA_GENERIC is not set
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
CONFIG_PATA_MPIIX=y
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
# CONFIG_PATA_PLATFORM is not set

#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
CONFIG_MD_LINEAR=m
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID10 is not set
# CONFIG_MD_RAID456 is not set
# CONFIG_MD_MULTIPATH is not set
# CONFIG_MD_FAULTY is not set
# CONFIG_BLK_DEV_DM is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_SPI is not set
# CONFIG_FUSION_FC is not set
# CONFIG_FUSION_SAS is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Macintosh device drivers
#
# CONFIG_MAC_EMUMOUSEBTN is not set

#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=m
# CONFIG_NET_SB1000 is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# PHY device support
#
# CONFIG_PHYLIB is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
CONFIG_E100=y
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_SC92031 is not set
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
CONFIG_E1000=m
# CONFIG_E1000_NAPI is not set
# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_CHELSIO_T3 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
# CONFIG_MYRI10GE is not set
# CONFIG_NETXEN_NIC is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
CONFIG_NET_RADIO=y
# CONFIG_NET_WIRELESS_RTNETLINK is not set

#
# Obsolete Wireless cards support (pre-802.11)
#
# CONFIG_STRIP is not set

#
# Wireless 802.11b ISA/PCI cards support
#
CONFIG_IPW2100=y
# CONFIG_IPW2100_MONITOR is not set
# CONFIG_IPW2100_DEBUG is not set
CONFIG_IPW2200=y
# CONFIG_IPW2200_MONITOR is not set
# CONFIG_IPW2200_QOS is not set
# CONFIG_IPW2200_DEBUG is not set
# CONFIG_AIRO is not set
# CONFIG_HERMES is not set
# CONFIG_ATMEL is not set

#
# Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support
#
# CONFIG_PRISM54 is not set
# CONFIG_USB_ZD1201 is not set
# CONFIG_HOSTAP is not set
CONFIG_NET_WIRELESS=y

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
CONFIG_PPP=m
# CONFIG_PPP_MULTILINK is not set
# CONFIG_PPP_FILTER is not set
# CONFIG_PPP_ASYNC is not set
# CONFIG_PPP_SYNC_TTY is not set
# CONFIG_PPP_DEFLATE is not set
# CONFIG_PPP_BSDCOMP is not set
# CONFIG_PPP_MPPE is not set
CONFIG_PPPOE=m
# CONFIG_SLIP is not set
CONFIG_SLHC=m
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1280
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=1024
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=m
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_PCSPKR is not set
# CONFIG_INPUT_WISTRON_BTNS is not set
# CONFIG_INPUT_ATLAS_BTNS is not set
# CONFIG_INPUT_UINPUT is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_CONSOLE is not set
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
CONFIG_PRINTER=y
# CONFIG_LP_CONSOLE is not set
# CONFIG_PPDEV is not set
# CONFIG_TIPAR is not set

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
CONFIG_NVRAM=y
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set
CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
CONFIG_AGP_VIA=y
# CONFIG_AGP_EFFICEON is not set
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
CONFIG_DRM_I810=m
CONFIG_DRM_I830=m
CONFIG_DRM_I915=m
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
# CONFIG_CS5535_GPIO is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# TPM devices
#
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set

#
# I2C support
#
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set

#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_PIIX4 is not set
CONFIG_I2C_ISA=y
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PASEMI is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_VIA is not set
CONFIG_I2C_VIAPRO=m
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set

#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Hardware Monitoring support
#
CONFIG_HWMON=y
CONFIG_HWMON_VID=y
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
CONFIG_SENSORS_IT87=y
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
CONFIG_SENSORS_HDAPS=m
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=y
CONFIG_VIDEO_V4L1=y
CONFIG_VIDEO_V4L1_COMPAT=y
CONFIG_VIDEO_V4L2=y

#
# Video Capture Adapters
#

#
# Video Capture Adapters
#
# CONFIG_VIDEO_ADV_DEBUG is not set
CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
# CONFIG_VIDEO_VIVI is not set
# CONFIG_VIDEO_BT848 is not set
# CONFIG_VIDEO_BWQCAM is not set
# CONFIG_VIDEO_CQCAM is not set
# CONFIG_VIDEO_W9966 is not set
# CONFIG_VIDEO_CPIA is not set
# CONFIG_VIDEO_CPIA2 is not set
# CONFIG_VIDEO_SAA5246A is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
# CONFIG_VIDEO_STRADIS is not set
# CONFIG_VIDEO_ZORAN is not set
CONFIG_VIDEO_SAA7134=y
# CONFIG_VIDEO_SAA7134_ALSA is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DPC is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_CX88 is not set
# CONFIG_VIDEO_CAFE_CCIC is not set

#
# V4L USB devices
#
# CONFIG_VIDEO_PVRUSB2 is not set
# CONFIG_VIDEO_EM28XX is not set
# CONFIG_VIDEO_USBVISION is not set
# CONFIG_USB_VICAM is not set
# CONFIG_USB_IBMCAM is not set
# CONFIG_USB_KONICAWC is not set
# CONFIG_USB_QUICKCAM_MESSENGER is not set
# CONFIG_USB_ET61X251 is not set
# CONFIG_VIDEO_OVCAMCHIP is not set
# CONFIG_USB_W9968CF is not set
# CONFIG_USB_OV511 is not set
# CONFIG_USB_SE401 is not set
# CONFIG_USB_SN9C102 is not set
# CONFIG_USB_STV680 is not set
# CONFIG_USB_ZC0301 is not set
# CONFIG_USB_PWC is not set

#
# Radio Adapters
#
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
# CONFIG_USB_DSBR is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
CONFIG_VIDEO_TUNER=y
CONFIG_VIDEO_BUF=y
CONFIG_VIDEO_IR=y
# CONFIG_USB_DABUSB is not set

#
# Graphics support
#
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_LCD_CLASS_DEVICE=m
# CONFIG_BACKLIGHT_PROGEAR is not set
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_DDC=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
CONFIG_FB_BACKLIGHT=y
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set

#
# Frambuffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
CONFIG_FB_VESA=y
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I810 is not set
CONFIG_FB_INTEL=y
# CONFIG_FB_INTEL_DEBUG is not set
CONFIG_FB_INTEL_I2C=y
# CONFIG_FB_MATROX is not set
CONFIG_FB_RADEON=y
CONFIG_FB_RADEON_I2C=y
CONFIG_FB_RADEON_BACKLIGHT=y
# CONFIG_FB_RADEON_DEBUG is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_CYBLA is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_VIDEO_SELECT=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y

#
# Logo configuration
#
# CONFIG_LOGO is not set

#
# Sound
#
CONFIG_SOUND=y

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_RAWMIDI=y
CONFIG_SND_SEQUENCER=y
# CONFIG_SND_SEQ_DUMMY is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=y
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
# CONFIG_SND_DYNAMIC_MINORS is not set
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
CONFIG_SND_MPU401_UART=y
CONFIG_SND_AC97_CODEC=y
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_MTS64 is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
# CONFIG_SND_PORTMAN2X4 is not set

#
# PCI devices
#
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS5535AUDIO is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
CONFIG_SND_HDA_INTEL=y
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
CONFIG_SND_VIA82XX=y
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_AC97_POWER_SAVE is not set

#
# USB devices
#
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set

#
# SoC audio support
#
# CONFIG_SND_SOC is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=y

#
# HID Devices
#
CONFIG_HID=y
# CONFIG_HID_DEBUG is not set

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_OTG is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_EHCI_SPLIT_ISO is not set
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_EHCI_BIG_ENDIAN_MMIO is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_SL811_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#

#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_LIBUSUAL is not set

#
# USB Input Devices
#
CONFIG_USB_HID=m
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
# CONFIG_HID_FF is not set
CONFIG_USB_HIDDEV=y

#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_ACECAD is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_TOUCHSCREEN is not set
# CONFIG_USB_YEALINK is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set
# CONFIG_USB_ATI_REMOTE2 is not set
# CONFIG_USB_KEYSPAN_REMOTE is not set
# CONFIG_USB_APPLETOUCH is not set
# CONFIG_USB_GTCO is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET_MII is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_MON is not set

#
# USB port drivers
#
# CONFIG_USB_USS720 is not set

#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_BERRY_CHARGE is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set

#
# USB DSL modem support
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# LED devices
#
# CONFIG_NEW_LEDS is not set

#
# LED drivers
#

#
# LED Triggers
#

#
# InfiniBand support
#
CONFIG_INFINIBAND=m
CONFIG_INFINIBAND_USER_MAD=m
CONFIG_INFINIBAND_USER_ACCESS=m
CONFIG_INFINIBAND_ADDR_TRANS=y
CONFIG_INFINIBAND_MTHCA=m
CONFIG_INFINIBAND_MTHCA_DEBUG=y
# CONFIG_INFINIBAND_AMSO1100 is not set
CONFIG_INFINIBAND_IPOIB=m
CONFIG_INFINIBAND_IPOIB_CM=y
CONFIG_INFINIBAND_IPOIB_DEBUG=y
# CONFIG_INFINIBAND_IPOIB_DEBUG_DATA is not set
CONFIG_INFINIBAND_SRP=m
CONFIG_INFINIBAND_ISER=m

#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#
# CONFIG_EDAC is not set

#
# Real Time Clock
#
# CONFIG_RTC_CLASS is not set

#
# DMA Engine support
#
# CONFIG_DMA_ENGINE is not set

#
# DMA Clients
#

#
# DMA Devices
#

#
# Auxiliary Display support
#
# CONFIG_KS0108 is not set

#
# Virtualization
#
CONFIG_KVM=m
CONFIG_KVM_INTEL=m
# CONFIG_KVM_AMD is not set

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
# CONFIG_EXT4DEV_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_INOTIFY is not set
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
CONFIG_FUSE_FS=y

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=850
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=y
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
# CONFIG_CONFIGFS_FS is not set

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_SMB_FS is not set
CONFIG_CIFS=y
# CONFIG_CIFS_STATS is not set
# CONFIG_CIFS_WEAK_PW_HASH is not set
# CONFIG_CIFS_XATTR is not set
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_CIFS_EXPERIMENTAL is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-15"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=y
# CONFIG_NLS_CODEPAGE_852 is not set
CONFIG_NLS_CODEPAGE_855=y
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
CONFIG_NLS_CODEPAGE_862=y
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
CONFIG_NLS_CODEPAGE_866=y
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
CONFIG_NLS_ISO8859_8=y
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
CONFIG_NLS_ISO8859_5=y
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
CONFIG_NLS_KOI8_R=y
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y

#
# Distributed Lock Manager
#
# CONFIG_DLM is not set

#
# Instrumentation Support
#
# CONFIG_PROFILING is not set
# CONFIG_KPROBES is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_LIST is not set
CONFIG_FRAME_POINTER=y
# CONFIG_FORCED_INLINING is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_FAULT_INJECTION is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set

#
# Page alloc debug is incompatible with Software Suspend on i386
#
CONFIG_DEBUG_RODATA=y
# CONFIG_4KSTACKS is not set
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_DOUBLEFAULT=y

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_MANAGER=y
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=m
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_GF128MUL is not set
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_PCBC=m
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_586 is not set
# CONFIG_CRYPTO_SERPENT is not set
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_586 is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
CONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_DEFLATE is not set
CONFIG_CRYPTO_MICHAEL_MIC=y
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_TEST is not set

#
# Hardware crypto devices
#
CONFIG_CRYPTO_DEV_PADLOCK=m
CONFIG_CRYPTO_DEV_PADLOCK_AES=m
CONFIG_CRYPTO_DEV_PADLOCK_SHA=m
CONFIG_CRYPTO_DEV_GEODE=m

#
# Library routines
#
CONFIG_BITREVERSE=y
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_KTIME_SCALAR=y

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Michael S. Tsirkin]

> Quoting Thomas Gleixner <tglx@linutronix.de>:
> Subject: Re: [4/5] 2.6.21-rc4: known regressions (v2)
> 
> On Sun, 2007-03-25 at 10:57 +0200, Michael S. Tsirkin wrote:
> > > Can you please test the following:
> > > 
> > > Add "clocksource=acpi_pm" to the kernel commandline.
> > > 
> > > If this does not change anything, then disable CONFIG_HPET and retry.
> > 
> > I have:
> > $ grep CONFIG_HPET .config
> > CONFIG_HPET_TIMER=y
> > CONFIG_HPET_EMULATE_RTC=y
> > # CONFIG_HPET is not set
> > 
> > so I think all these tests were done with CONFIG_HPET=n.
> 
> Gack. Please turn off CONFIG_HPET_TIMER and CONFIG_HPET_EMULATE_RTC

Okay ... although they are in defconfig for i386, and they did not create
problems in 2.6.20.

> > Given this, does it still make sense to test clocksource=acpi_pm?
> 
> Yes.

With or without CONFIG_HPET_TIMER?


-- 
MST

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Thomas Gleixner]

On Sun, 2007-03-25 at 10:57 +0200, Michael S. Tsirkin wrote:
> > Can you please test the following:
> > 
> > Add "clocksource=acpi_pm" to the kernel commandline.
> > 
> > If this does not change anything, then disable CONFIG_HPET and retry.
> 
> I have:
> $ grep CONFIG_HPET .config
> CONFIG_HPET_TIMER=y
> CONFIG_HPET_EMULATE_RTC=y
> # CONFIG_HPET is not set
> 
> so I think all these tests were done with CONFIG_HPET=n.

Gack. Please turn off CONFIG_HPET_TIMER and CONFIG_HPET_EMULATE_RTC

> Given this, does it still make sense to test clocksource=acpi_pm?

Yes.

	tglx

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Michael S. Tsirkin]

> Quoting Thomas Gleixner <tglx@linutronix.de>:
> Subject: Re: [4/5] 2.6.21-rc4: known regressions (v2)
> 
> On Sun, 2007-03-25 at 12:15 +0200, Michael S. Tsirkin wrote:
> > > Quoting Thomas Gleixner <tglx@linutronix.de>:
> > > Subject: Re: [4/5] 2.6.21-rc4: known regressions (v2)
> > > 
> > > On Sun, 2007-03-25 at 10:57 +0200, Michael S. Tsirkin wrote:
> > > > > Can you please test the following:
> > > > > 
> > > > > Add "clocksource=acpi_pm" to the kernel commandline.
> > > > > 
> > > > > If this does not change anything, then disable CONFIG_HPET and retry.
> > > > 
> > > > I have:
> > > > $ grep CONFIG_HPET .config
> > > > CONFIG_HPET_TIMER=y
> > > > CONFIG_HPET_EMULATE_RTC=y
> > > > # CONFIG_HPET is not set
> > > > 
> > > > so I think all these tests were done with CONFIG_HPET=n.
> > > 
> > > Gack. Please turn off CONFIG_HPET_TIMER and CONFIG_HPET_EMULATE_RTC
> > 
> > Okay ... although they are in defconfig for i386, and they did not create
> > problems in 2.6.20.
> 
> I know, but we are looking for a regression and the hpet related code
> _has_ changed.
> 
> > > > Given this, does it still make sense to test clocksource=acpi_pm?
> > > 
> > > Yes.
> > 
> > With or without CONFIG_HPET_TIMER?
> 
> with, as a first test.

Sorry, now I'm confused.
Could you pls list the full set of tests you want me to run,
and what information to collect from each of them?

-- 
MST

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Thomas Gleixner]

On Sun, 2007-03-25 at 12:15 +0200, Michael S. Tsirkin wrote:
> > Quoting Thomas Gleixner <tglx@linutronix.de>:
> > Subject: Re: [4/5] 2.6.21-rc4: known regressions (v2)
> > 
> > On Sun, 2007-03-25 at 10:57 +0200, Michael S. Tsirkin wrote:
> > > > Can you please test the following:
> > > > 
> > > > Add "clocksource=acpi_pm" to the kernel commandline.
> > > > 
> > > > If this does not change anything, then disable CONFIG_HPET and retry.
> > > 
> > > I have:
> > > $ grep CONFIG_HPET .config
> > > CONFIG_HPET_TIMER=y
> > > CONFIG_HPET_EMULATE_RTC=y
> > > # CONFIG_HPET is not set
> > > 
> > > so I think all these tests were done with CONFIG_HPET=n.
> > 
> > Gack. Please turn off CONFIG_HPET_TIMER and CONFIG_HPET_EMULATE_RTC
> 
> Okay ... although they are in defconfig for i386, and they did not create
> problems in 2.6.20.

I know, but we are looking for a regression and the hpet related code
_has_ changed.

> > > Given this, does it still make sense to test clocksource=acpi_pm?
> > 
> > Yes.
> 
> With or without CONFIG_HPET_TIMER?

with, as a first test.

	tglx

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Thomas Gleixner]

On Sun, 2007-03-25 at 12:25 +0200, Michael S. Tsirkin wrote:
> Sorry, now I'm confused.
> Could you pls list the full set of tests you want me to run,
> and what information to collect from each of them?

1. Test:

add clocksource=acpi_pm to command line with your current kernel config.
Check, whether the resume madness is gone

2. Test

Disable CONFIG_HPET_* in the kernel config and retest

Please capture both logs from boot to resume.

Thanks,

	tglx

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Ingo Molnar]

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

> > Sorry, now I'm confused.
> > Could you pls list the full set of tests you want me to run,
> > and what information to collect from each of them?
> 
> 1. Test:

I suspect step 0 would be use Linus' latest tree, ontop of -rc4:

 http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.21-rc4-git11.bz2

to make sure all post-rc4 time fixes are included.

	Ingo

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Thomas Meyer]

Eric W. Biederman schrieb:
>
> Thomas could you verify the patch below makes the problem go away
> for you.
>   

The patch solves the problem. I'm writing this after the third suspend
and resume cycle.
msi irq stays enabled for libata device:
cat /sys/devices/pci0000\:00/0000\:00\:1f.2/irq
218

cat /proc/interrupts
           CPU0       CPU1
  0:     274190          0   IO-APIC-edge      timer
  9:      13417          0   IO-APIC-fasteoi   acpi
 16:        166          0   IO-APIC-fasteoi   uhci_hcd:usb4
 17:      70908      88643   IO-APIC-fasteoi   wifi0
 18:       3060          0   IO-APIC-fasteoi   libata, uhci_hcd:usb3
 19:          8          0   IO-APIC-fasteoi   ohci1394, uhci_hcd:usb2
 20:      46252          0   IO-APIC-fasteoi   HDA Intel
 21:     168437          0   IO-APIC-fasteoi   uhci_hcd:usb1, ehci_hcd:usb5
218:      15896          0   PCI-MSI-edge      libata
219:          1          0   PCI-MSI-edge      eth0
NMI:          0          0
LOC:      87574     123338
ERR:          0
MIS:          0


BUT...


The first suspend to disk is ok. The second suspend to disk has a
strange behaviour:
1.) write pm image
2.) the system disable the non-boot cpus again (i guess this happens in
power_down())
3.) the system doesn't power down.
4.) pressing any key and the system powers down.

The same is true for the third suspend cycle. Maybe an acpi problem?

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Eric W. Biederman]

Thomas Meyer <thomas@m3y3r.de> writes:

> Eric W. Biederman schrieb:
>>
>> Thomas could you verify the patch below makes the problem go away
>> for you.
>>   
>
> The patch solves the problem. I'm writing this after the third suspend
> and resume cycle.
> msi irq stays enabled for libata device:
> cat /sys/devices/pci0000\:00/0000\:00\:1f.2/irq
> 218

> The first suspend to disk is ok. The second suspend to disk has a
> strange behaviour:
> 1.) write pm image
> 2.) the system disable the non-boot cpus again (i guess this happens in
> power_down())
> 3.) the system doesn't power down.
> 4.) pressing any key and the system powers down.
>
> The same is true for the third suspend cycle. Maybe an acpi problem?

Sounds possible.  You could probably verify it isn't my patch but running
an unpatched kernel without msi support.  As I think the crash you saw should
only be reproducible when using devices that support msi.

Unless I hear different I'm going to assume that this second case is a
completely different problem.  You might check to see if the acpi
interrupt is stuck after a suspend/resume cycle.

At this point I'm going to wait a bit for Tony and Len to have a
chance to give their opinion but unless I hear something I'm going to
plan on sending the patch out shortly...

Eric

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Thomas Gleixner]

On Sun, 2007-03-25 at 13:16 +0200, Ingo Molnar wrote:
> * Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> > > Sorry, now I'm confused.
> > > Could you pls list the full set of tests you want me to run,
> > > and what information to collect from each of them?
> > 
> > 1. Test:
> 
> I suspect step 0 would be use Linus' latest tree, ontop of -rc4:
> 
>  http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.21-rc4-git11.bz2
> 
> to make sure all post-rc4 time fixes are included.

Ick, yes: The missing bits are here:

http://tglx.de/private/tglx/2.6.21-rc4-pending/acpi-pm-fix.patch

http://tglx.de/private/tglx/2.6.21-rc4-pending/fix-tsc-watchdog.patch

	tglx

Re: [1/5] 2.6.21-rc4: known regressions (v2)

[Adrian Bunk]

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

On Sat, Mar 24, 2007 at 09:45:09PM -0700, David Miller wrote:
> From: Adrian Bunk <bunk@stusta.de>
> Date: Fri, 23 Mar 2007 19:48:17 +0100
> 
> > Subject    : problem with sockets
> > References : http://lkml.org/lkml/2007/3/21/248
> > Submitter  : Jose Alberto Reguero <jareguero@telefonica.net>
> > Status     : unknown
> 
> Not enough information in his report, for example for the
> case he says does not work he fails to indicate what kernel
> or system type the Client runs on.
> 
> Furthermore, his scripts don't even execute properly when
> I try to run them myself, for example server.py gives me
> this syntax error when python tries to parse the script:
> 
> davem@sunset:~/src/GIT/net-2.6$ /usr/bin/python server.py
>   File "server.py", line 9
>     struct sockaddr_in ServerAddr;
>                      ^
> SyntaxError: invalid syntax
> 
> Can someone help de-crapify this bug report?

He described one Python and one C example, and attached 2+2 programs.

The mailing list archive I quoted only contains the C files and doesn't 
display the Python files with the error message
"unhandled content-type:application/x-python" - but that's not the fault 
of the submitter, the bug report itself is OK.

I've attached all 4 files to this email.

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


[-- Attachment #2: client.py --]
[-- Type: text/x-python, Size: 212 bytes --]

# Echo client program
import socket

mcast_adress = "227.234.253.9"
port = 15922

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
s.sendto('Hello, world', (mcast_adress, port))
s.close()

[-- Attachment #3: server.py --]
[-- Type: text/x-python, Size: 555 bytes --]

# Echo server program
import socket
import struct

HOST = ''                 # Symbolic name meaning the local host
PORT = 15922              # Arbitrary non-privileged port
mcast_adress = "227.234.253.9"

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind((HOST, PORT))
mreq = struct.pack('4si', socket.inet_aton(mcast_adress), socket.INADDR_ANY)
s.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq)
data = s.recv(1024)
if (data):
    print (data)
s.close()

[-- Attachment #4: client.c --]
[-- Type: text/x-csrc, Size: 499 bytes --]

#include <sys/socket.h>
#include <netinet/in.h>
#include <string.h>

main()
{
	int sock = socket (AF_INET, SOCK_DGRAM, IPPROTO_UDP);
	struct sockaddr_in ClientAddr;
	memset(&ClientAddr, 0, sizeof(ClientAddr));
	ClientAddr.sin_family = AF_INET;
	ClientAddr.sin_addr.s_addr = inet_addr("227.234.253.9");
	int port = 15922;
	ClientAddr.sin_port = htons((short) port);
	char str[] = "Hello, world";
	sendto(sock, str, strlen(str), 0, (struct sockaddr *)&ClientAddr, sizeof(ClientAddr));
	close(sock);
}

[-- Attachment #5: server.c --]
[-- Type: text/x-csrc, Size: 1002 bytes --]

#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <string.h>
#include <stdio.h>

main()
{
        struct sockaddr_in ServerAddr;
        int sock = socket (AF_INET, SOCK_DGRAM, IPPROTO_UDP);
        int reuse = 1;
        setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &reuse, sizeof(int));
        memset(&ServerAddr, 0, sizeof(ServerAddr));
        ServerAddr.sin_family = AF_INET;
        ServerAddr.sin_addr.s_addr = htonl(INADDR_ANY);
        int port = 15922;
        ServerAddr.sin_port = htons((short) port);
        bind(sock, (struct sockaddr *)&ServerAddr, sizeof(ServerAddr));
        struct ip_mreq mreq;
	memset(&mreq, 0, sizeof(mreq));
        mreq.imr_multiaddr.s_addr = inet_addr("227.234.253.9");
	mreq.imr_interface.s_addr = htonl(INADDR_ANY);
        setsockopt(sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq));
        char str[100];
	memset(&str, 0, sizeof(str));
        recv(sock, str, 100, 0);
        printf(":%s:\n", str);
	close (sock);
}

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Rafael J. Wysocki]

On Sunday, 25 March 2007 14:03, Eric W. Biederman wrote:
> Thomas Meyer <thomas@m3y3r.de> writes:
> 
> > Eric W. Biederman schrieb:
> >>
> >> Thomas could you verify the patch below makes the problem go away
> >> for you.
> >>   
> >
> > The patch solves the problem. I'm writing this after the third suspend
> > and resume cycle.
> > msi irq stays enabled for libata device:
> > cat /sys/devices/pci0000\:00/0000\:00\:1f.2/irq
> > 218
> 
> > The first suspend to disk is ok. The second suspend to disk has a
> > strange behaviour:
> > 1.) write pm image
> > 2.) the system disable the non-boot cpus again (i guess this happens in
> > power_down())

Yes, in kernel/power/disk.c:power_down() .

Please comment out the disable_nonboot_cpus() in there and retest (but please
test the latest Linus' tree).

> > 3.) the system doesn't power down.
> > 4.) pressing any key and the system powers down.
> >
> > The same is true for the third suspend cycle. Maybe an acpi problem?
> 
> Sounds possible.  You could probably verify it isn't my patch but running
> an unpatched kernel without msi support.  As I think the crash you saw should
> only be reproducible when using devices that support msi.
> 
> Unless I hear different I'm going to assume that this second case is a
> completely different problem.

I think it is different too.

Greetings,
Rafael

[PATCH] dynticks: fix hrtimer rounding error in next_timer_interrupt

[Thomas Gleixner]

The rework of next_timer_interrupt() fixed the timer wheel bugs, but
invented a rounding error versus the next hrtimer event. This is caused
by the conversion of the hrtimer internal representation to relative
jiffies.

This causes bug #8100:
http://bugzilla.kernel.org/show_bug.cgi?id=8100

next_timer_interrupt() returns "now" in such a case and causes the code
in tick_nohz_stop_sched_tick() to trigger the timer softirq, which is
bogus as no timer is due for expiry. This results in an endless context
switching between idle and ksoftirqd until a timer is due for expiry.

Modify the hrtimer evaluation so that, it returns now + 1, when the
conversion results in a delta < 1 jiffie. 

It's confirmed to resolve bug #8100

Reported-by: Emil Karlson <jkarlson@cc.hut.fi>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

diff --git a/kernel/timer.c b/kernel/timer.c
index 797cccb..440048a 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -695,15 +695,28 @@ static unsigned long cmp_next_hrtimer_event(unsigned long now,
 {
 	ktime_t hr_delta = hrtimer_get_next_event();
 	struct timespec tsdelta;
+	unsigned long delta;
 
 	if (hr_delta.tv64 == KTIME_MAX)
 		return expires;
 
-	if (hr_delta.tv64 <= TICK_NSEC)
-		return now;
+	/*
+	 * Expired timer available, let it expire in the next tick
+	 */
+	if (hr_delta.tv64 <= 0)
+		return now + 1;
 
 	tsdelta = ktime_to_timespec(hr_delta);
-	now += timespec_to_jiffies(&tsdelta);
+	delta = timespec_to_jiffies(&tsdelta);
+	/*
+	 * Take rounding errors in to account and make sure, that it
+	 * expires in the next tick. Otherwise we go into an endless
+	 * ping pong due to tick_nohz_stop_sched_tick() retriggering
+	 * the timer softirq
+	 */
+	if (delta < 1)
+		delta = 1;
+	now += delta;
 	if (time_before(now, expires))
 		return now;
 	return expires;

[PATCH] clocksource: Fix thinko in watchdog selection

[Thomas Gleixner]

The watchdog implementation excludes low res / non continuous
clocksources from being selected as a watchdog reference
unintentionally.

Allow using jiffies/PIT as a watchdog reference as long as no better
clocksource is available. This is necessary to detect TSC breakage on
systems, which have no pmtimer/hpet.

The main goal of the initial patch (preventing to switch to highres/nohz
when no reliable fallback clocksource is available) is still guaranteed
by the checks in clocksource_watchdog().

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

diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index 5b0e46b..fe5c7db 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -151,7 +151,8 @@ static void clocksource_check_watchdog(struct clocksource *cs)
 			watchdog_timer.expires = jiffies + WATCHDOG_INTERVAL;
 			add_timer(&watchdog_timer);
 		}
-	} else if (cs->flags & CLOCK_SOURCE_IS_CONTINUOUS) {
+	} else {
+		if (cs->flags & CLOCK_SOURCE_IS_CONTINUOUS)
 			cs->flags |= CLOCK_SOURCE_VALID_FOR_HRES;
 
 		if (!watchdog || cs->rating > watchdog->rating) {

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Eric W. Biederman]

"Rafael J. Wysocki" <rjw@sisk.pl> writes:

> Yes, in kernel/power/disk.c:power_down() .
>
> Please comment out the disable_nonboot_cpus() in there and retest (but please
> test the latest Linus' tree).

<rant>

Why do we even need a disable_nonboot_cpus in that path?  machine_shutdown
on i386 and x86_64 should take care of that.  Further the code that computes
the boot cpu is bogus (not all architectures require cpu == 0 to be
the boot cpu), and disabling non boot cpus appears to be a strong
x86ism, in the first place.

If the only reason for disable_nonboot_cpus there is to avoid the
WARN_ON in init_low_mappings() we should seriously consider killing
it.  If we can wait for 2.6.22 the relocatable x86_64 patchset that
Andi has queued, has changes that kill the init_low_mapping() hack.

I'm not very comfortable with calling cpu_down in a common code path
right now either.  I'm fairly certain we still don't have that
correct.  So if we confine the mess that is cpu_down to #if
defined(CPU_HOTPLUG) && defined(CONFIG_EXPERIMENTAL) I don't care.
If we start using it everywhere I'm very nervous.  I know the irq
migration when bringing a cpu down is strongly racy, and I don't think
we actually put cpus to sleep properly either.

</rant>


Eric

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Thomas Meyer]

Eric W. Biederman schrieb:
> Sounds possible.  You could probably verify it isn't my patch but running
> an unpatched kernel without msi support.  As I think the crash you saw should
> only be reproducible when using devices that support msi.
>   
Without your patch and with pci=nomsi option the same error occur. But i
think this is not an acpi error, because every interrupt seems to
trigger the shutdown, like moving the mouse, or pressing a key.
> Unless I hear different I'm going to assume that this second case is a
> completely different problem.  You might check to see if the acpi
> interrupt is stuck after a suspend/resume cycle.
>   
D'accord.

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Thomas Meyer]

Rafael J. Wysocki schrieb:
> On Sunday, 25 March 2007 14:03, Eric W. Biederman wrote:
>   
>> Thomas Meyer <thomas@m3y3r.de> writes:
>>
>>     
>>> Eric W. Biederman schrieb:
>>>       
>>>> Thomas could you verify the patch below makes the problem go away
>>>> for you.
>>>>   
>>>>         
>>> The patch solves the problem. I'm writing this after the third suspend
>>> and resume cycle.
>>> msi irq stays enabled for libata device:
>>> cat /sys/devices/pci0000\:00/0000\:00\:1f.2/irq
>>> 218
>>>       
>>> The first suspend to disk is ok. The second suspend to disk has a
>>> strange behaviour:
>>> 1.) write pm image
>>> 2.) the system disable the non-boot cpus again (i guess this happens in
>>> power_down())
>>>       
>
> Yes, in kernel/power/disk.c:power_down() .
>
> Please comment out the disable_nonboot_cpus() in there and retest (but please
> test the latest Linus' tree).
>
>   
Without disable_nonboot_cpus in power_down the computer powers down
without the mysterious "wait for the next interrupt" hang.
>>> 3.) the system doesn't power down.
>>> 4.) pressing any key and the system powers down.
>>>
>>> The same is true for the third suspend cycle. Maybe an acpi problem?
>>>       
>> Sounds possible.  You could probably verify it isn't my patch but running
>> an unpatched kernel without msi support.  As I think the crash you saw should
>> only be reproducible when using devices that support msi.
>>
>> Unless I hear different I'm going to assume that this second case is a
>> completely different problem.
>>     
>
> I think it is different too.
>   
Yes, it's a different problem

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Adrian Bunk]

On Sun, Mar 25, 2007 at 01:41:33PM +0200, Thomas Meyer wrote:
>...
> The first suspend to disk is ok. The second suspend to disk has a
> strange behaviour:
> 1.) write pm image
> 2.) the system disable the non-boot cpus again (i guess this happens in
> power_down())
> 3.) the system doesn't power down.
> 4.) pressing any key and the system powers down.
>...

Is this also present with 2.6.20, or is it a regression?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Thomas Meyer]

Adrian Bunk schrieb:
> On Sun, Mar 25, 2007 at 01:41:33PM +0200, Thomas Meyer wrote:
>   
>> ...
>> The first suspend to disk is ok. The second suspend to disk has a
>> strange behaviour:
>> 1.) write pm image
>> 2.) the system disable the non-boot cpus again (i guess this happens in
>> power_down())
>> 3.) the system doesn't power down.
>> 4.) pressing any key and the system powers down.
>> ...
>>     
>
> Is this also present with 2.6.20, or is it a regression?
>   
No, this one is not present in 2.6.20 and this error doesn't (head=
317ec6cd00f25d05d153a780bc178c5335f320ee) occur with NO_HZ=n and
HIGH_RES_TIMERS=n

This error is maybe related with this commit:

commit cd05a1f818073a623455a58e756c5b419fc98db9
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sat Mar 17 00:25:52 2007 +0100

    [PATCH] clockevents: Fix suspend/resume to disk hangs

    I finally found a dual core box, which survives suspend/resume without
    crashing in the middle of nowhere. Sigh, I never figured out from the
    code and the bug reports what's going on.

    The observed hangs are caused by a stale state transition of the clock
    event devices, which keeps the RCU synchronization away from completion,
    when the non boot CPU is brought back up.

    The suspend/resume in oneshot mode needs the similar care as the
    periodic mode during suspend to RAM. My assumption that the state
    transitions during the different shutdown/bringups of s2disk would go
    through the periodic boot phase and then switch over to highres resp.
    nohz mode were simply wrong.

    Add the appropriate suspend / resume handling for the non periodic
    modes.

    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Rafael J. Wysocki]

On Sunday, 25 March 2007 16:17, Thomas Meyer wrote:
> Rafael J. Wysocki schrieb:
> > On Sunday, 25 March 2007 14:03, Eric W. Biederman wrote:
> >   
> >> Thomas Meyer <thomas@m3y3r.de> writes:
> >>
> >>     
> >>> Eric W. Biederman schrieb:
> >>>       
> >>>> Thomas could you verify the patch below makes the problem go away
> >>>> for you.
> >>>>   
> >>>>         
> >>> The patch solves the problem. I'm writing this after the third suspend
> >>> and resume cycle.
> >>> msi irq stays enabled for libata device:
> >>> cat /sys/devices/pci0000\:00/0000\:00\:1f.2/irq
> >>> 218
> >>>       
> >>> The first suspend to disk is ok. The second suspend to disk has a
> >>> strange behaviour:
> >>> 1.) write pm image
> >>> 2.) the system disable the non-boot cpus again (i guess this happens in
> >>> power_down())
> >>>       
> >
> > Yes, in kernel/power/disk.c:power_down() .
> >
> > Please comment out the disable_nonboot_cpus() in there and retest (but please
> > test the latest Linus' tree).
> >
> >   
> Without disable_nonboot_cpus in power_down the computer powers down
> without the mysterious "wait for the next interrupt" hang.

Do you have CONFIG_NO_HZ set?

Rafael

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Rafael J. Wysocki]

On Sunday, 25 March 2007 19:25, Thomas Meyer wrote:
> Adrian Bunk schrieb:
> > On Sun, Mar 25, 2007 at 01:41:33PM +0200, Thomas Meyer wrote:
> >   
> >> ...
> >> The first suspend to disk is ok. The second suspend to disk has a
> >> strange behaviour:
> >> 1.) write pm image
> >> 2.) the system disable the non-boot cpus again (i guess this happens in
> >> power_down())
> >> 3.) the system doesn't power down.
> >> 4.) pressing any key and the system powers down.
> >> ...
> >>     
> >
> > Is this also present with 2.6.20, or is it a regression?
> >   
> No, this one is not present in 2.6.20 and this error doesn't (head=
> 317ec6cd00f25d05d153a780bc178c5335f320ee) occur with NO_HZ=n and
> HIGH_RES_TIMERS=n
> 
> This error is maybe related with this commit:

Yes, it is, but I'd rather remove the disable_nonboot_cpus() from
power_down() (as Eric suggested) instead of trying to handle the RCU sync
problem here.

This has been caused by my commit 94985134b7b46848267ed6b734320db01c974e72
(swsusp: disable nonboot CPUs before entering platform suspend) that in such a
case should be reverted.

Greetings,
Rafael

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Rafael J. Wysocki]

On Sunday, 25 March 2007 14:56, Eric W. Biederman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> 
> > Yes, in kernel/power/disk.c:power_down() .
> >
> > Please comment out the disable_nonboot_cpus() in there and retest (but please
> > test the latest Linus' tree).
> 
> <rant>
> 
> Why do we even need a disable_nonboot_cpus in that path?  machine_shutdown
> on i386 and x86_64 should take care of that.  Further the code that computes
> the boot cpu is bogus (not all architectures require cpu == 0 to be
> the boot cpu), and disabling non boot cpus appears to be a strong
> x86ism, in the first place.

Yes.
 
> If the only reason for disable_nonboot_cpus there is to avoid the
> WARN_ON in init_low_mappings() we should seriously consider killing
> it.

We have considered it, but no one was sure that it was a good idea.

> If we can wait for 2.6.22 the relocatable x86_64 patchset that 
> Andi has queued, has changes that kill the init_low_mapping() hack.

I think we should kill the WARN_ON() right now, perhaps replacing it with
a FIXME comment.

> I'm not very comfortable with calling cpu_down in a common code path
> right now either.  I'm fairly certain we still don't have that
> correct.  So if we confine the mess that is cpu_down to #if
> defined(CPU_HOTPLUG) && defined(CONFIG_EXPERIMENTAL) I don't care.
> If we start using it everywhere I'm very nervous.
> migration when bringing a cpu down is strongly racy, and I don't think
> we actually put cpus to sleep properly either.

I'm interested in all of the details, please.  I seriously consider dropping
cpu_up()/cpu_down() from the suspend code paths.

Greetings,
Rafael

Re: [PATCH] x86_64: avoid sending LOCAL_TIMER_VECTOR IPI to itself

[Ray Lee]

Ingo Molnar wrote:
> * Ray Lee <ray-lk@madrabbit.org> wrote:
> 
>> Subject: [PATCH] x86_64: avoid sending LOCAL_TIMER_VECTOR IPI to 
>> itself
>>
>> Ray Lee reported, that on an UP kernel with "noapic" command line 
>> option set, the box locks hard during boot.
> 
> i think this bug deserves a bit more attention, because similar problems 
> could be in other codepaths too.
> 
> the problem here is that we tried to send an IPI to ourselves - which 
> confused Ray's system which has an IO-APIC, but where due to noapic we 
> keep the IO-APIC in its BIOS default.
> 
> this isnt a new problem: the new time code just exposed it more 
> prominently that it was visible before. (the SMP kernel probably would 
> hang in a similar way on Ray's system)

Taking the hint, yes it does. (I'd never had a reason to test it before.)
Booting an SMP kernel without NOAPIC works, with NOAPIC hangs fairly early
on, implying a real fix to my problem belongs down at the arch level, I
suppose.

> i dont see any clear debugging in the IPI code that excludes self-IPIs. 
> I think the only valid way to do that is to use DEST_SELF. Andi?

Ray

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Rafael J. Wysocki]

On Sunday, 25 March 2007 21:06, Rafael J. Wysocki wrote:
> On Sunday, 25 March 2007 19:25, Thomas Meyer wrote:
> > Adrian Bunk schrieb:
> > > On Sun, Mar 25, 2007 at 01:41:33PM +0200, Thomas Meyer wrote:
> > >   
> > >> ...
> > >> The first suspend to disk is ok. The second suspend to disk has a
> > >> strange behaviour:
> > >> 1.) write pm image
> > >> 2.) the system disable the non-boot cpus again (i guess this happens in
> > >> power_down())
> > >> 3.) the system doesn't power down.
> > >> 4.) pressing any key and the system powers down.
> > >> ...
> > >>     
> > >
> > > Is this also present with 2.6.20, or is it a regression?
> > >   
> > No, this one is not present in 2.6.20 and this error doesn't (head=
> > 317ec6cd00f25d05d153a780bc178c5335f320ee) occur with NO_HZ=n and
> > HIGH_RES_TIMERS=n
> > 
> > This error is maybe related with this commit:
> 
> Yes, it is, but I'd rather remove the disable_nonboot_cpus() from
> power_down() (as Eric suggested) instead of trying to handle the RCU sync
> problem here.
> 
> This has been caused by my commit 94985134b7b46848267ed6b734320db01c974e72
> (swsusp: disable nonboot CPUs before entering platform suspend) that in such a
> case should be reverted.

s/such a case/the present situation/

Rafael

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Eric W. Biederman]

"Rafael J. Wysocki" <rjw@sisk.pl> writes:

> On Sunday, 25 March 2007 14:56, Eric W. Biederman wrote:
>> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>> 
>> > Yes, in kernel/power/disk.c:power_down() .
>> >
>> > Please comment out the disable_nonboot_cpus() in there and retest (but
> please
>> > test the latest Linus' tree).
>> 
>> <rant>
>> 
>> Why do we even need a disable_nonboot_cpus in that path?  machine_shutdown
>> on i386 and x86_64 should take care of that.  Further the code that computes
>> the boot cpu is bogus (not all architectures require cpu == 0 to be
>> the boot cpu), and disabling non boot cpus appears to be a strong
>> x86ism, in the first place.
>
> Yes.
>  
>> If the only reason for disable_nonboot_cpus there is to avoid the
>> WARN_ON in init_low_mappings() we should seriously consider killing
>> it.
>
> We have considered it, but no one was sure that it was a good idea.

The problem with the current init_low_mappings is that it hacks the
current page table.  If we can instead use a different page table
the code becomes SMP safe.

I have extracted the patch that addresses this from the relocatable
patchset and appended it for sparking ideas.  It goes a little
farther than we need to solve this issue but the basics are there.

>> If we can wait for 2.6.22 the relocatable x86_64 patchset that 
>> Andi has queued, has changes that kill the init_low_mapping() hack.
>
> I think we should kill the WARN_ON() right now, perhaps replacing it with
> a FIXME comment.

Reasonable.

>> I'm not very comfortable with calling cpu_down in a common code path
>> right now either.  I'm fairly certain we still don't have that
>> correct.  So if we confine the mess that is cpu_down to #if
>> defined(CPU_HOTPLUG) && defined(CONFIG_EXPERIMENTAL) I don't care.
>> If we start using it everywhere I'm very nervous.
>> migration when bringing a cpu down is strongly racy, and I don't think
>> we actually put cpus to sleep properly either.
>
> I'm interested in all of the details, please.  I seriously consider dropping
> cpu_up()/cpu_down() from the suspend code paths.


So I'm not certain if in a multiple cpu context we can avoid all of the
issues with cpu hotplug but there is a reasonable chance so I will
explain as best I can.

Yanking the appropriate code out of linuxbios the way a processor should stop
itself is to send an INIT IPI to itself.  This puts a cpu into an optimized
wait for startup IPI state where it is otherwise disabled.  This is the state
any sane BIOS will put the cpus into before control is handed off to the kernel.

> static inline void stop_this_cpu(void)
> {
>         unsigned apicid;
>         apicid = lapicid();
> 
>         /* Send an APIC INIT to myself */
>         lapic_write(LAPIC_ICR2, SET_LAPIC_DEST_FIELD(apicid));
>         lapic_write(LAPIC_ICR, LAPIC_INT_LEVELTRIG | LAPIC_INT_ASSERT | LAPIC_DM_INIT);
>         /* Wait for the ipi send to finish */
>         lapic_wait_icr_idle();
> 
>         /* Deassert the APIC INIT */
>         lapic_write(LAPIC_ICR2, SET_LAPIC_DEST_FIELD(apicid));
>         lapic_write(LAPIC_ICR,  LAPIC_INT_LEVELTRIG | LAPIC_DM_INIT);
>         /* Wait for the ipi send to finish */
>         lapic_wait_icr_idle();
> 
>         /* If I haven't halted spin forever */
>         for(;;) {
>                 hlt();
>         }
> }

I'm not certain what to do with the interrupt races.  But I will see
if I can explain what I know.

<braindump>

- Most ioapics are buggy.
- Most ioapics do not follow pci-ordering rules with respect to
  interrupt message deliver so ensuring all in-flight irqs have
  arrived somewhere is very hard.
- To avoid bugs we always limit ourselves to reprogramming the ioapics
  in the interrupt handler, and not considering an interrupt
  successfully reprogrammed until we have received an irq in the new
  location.
- On x86 we have two basic interrupt handling modes.
  o logical addressing with lowest priority delivery.
  o physical addressing with delivery to a single cpu.
- With logical addressing as long as the cpu is not available for
  having an interrupt delivered to it the interrupt will be
  never be delivered to a particular cpu.  Ideally we also update
  the mask in the ioapic to not target that cpu.
- With physical addressing targeting a single cpu we need to reprogram
  the ioapics not to target that specific cpu.  This needs to happen
  in the interrupt handler and we need to wait for the next interrupt
  before we tear down our data structures for handling the interrupt.

  The current cpu hotplug code attempts to reprogram the ioapics from
  process context which is just wrong.

Now as part of suspend/resume I think we should be programming the
hardware not to generate interrupts in the first place at the actual
hardware devices so we can likely avoid all of the code that
reprograms interrupts while they are active.  If we can use things
like pci ordering rules to ensure the device will never fire the
interrupt until resumed we should be able to disable interrupts
synchronously.  Something that we can not safely do in the current
cpu hotplug scenario.  Which should make the problem of doing the
work race free much easier.

I don't know if other architectures need to disable cpus or not before
doing a suspend to ram or a suspend to disk.

I also don't know if we have any code that brings up the other cpus
after we have been suspended.  In either the cpu hotplug paths or the
architecture specific paths.

The bottom line is after the partial review of the irq handling during
cpu shutdown a little while ago that I consider the current cpu
hotplug code to be something that works when you are lucky.  There are
to many hardware bugs to support the general case it tries to
implement.

I have not reviewed the entire cpu hotplug path nor have I even tried
suspend/resume.  But I have been all and down the boot and shutdown
code paths so I understand the general problem.

The other part I know is that cpu numbers are assigned at the
architectures discretion.  So unless the architecture code or the
early boot code sets a variable remembering which was the boot cpu
there is no reason to believe we can deduce it.  In addition I don't
know if any other architectures have anything resembling the x86
requirement to disable non-boot cpus.  I do know machine_shutdown
on i386 and x86_64 performs that action (if not perfectly) so at
least currently we should be able to do this in architecture
specific code.

</braindump>

Eric



From: Vivek Goyal <vgoyal@in.ibm.com>
Subject: [PATCH 12/20] x86_64: 64bit ACPI wakeup trampoline

o Moved wakeup_level4_pgt into the wakeup routine so we can
  run the kernel above 4G.

o Now we first go to 64bit mode and continue to run from trampoline and
  then then start accessing kernel symbols and restore processor context.
  This enables us to resume even in relocatable kernel context when 
  kernel might not be loaded at physical addr it has been compiled for.

o Removed the need for modifying any existing kernel page table.

o Increased the size of the wakeup routine to 8K. This is required as
  wake page tables are on trampoline itself and they got to be at 4K
  boundary, hence one page is not sufficient.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
---

 arch/x86_64/kernel/acpi/sleep.c  |   22 ++------------
 arch/x86_64/kernel/acpi/wakeup.S | 59 ++++++++++++++++++++++++---------------
 arch/x86_64/kernel/head.S        |    9 -----
 3 files changed, 41 insertions(+), 49 deletions(-)

diff -puN arch/x86_64/kernel/acpi/sleep.c~x86_64-64bit-ACPI-wakeup-trampoline
arch/x86_64/kernel/acpi/sleep.c
---
linux-2.6.21-rc2-reloc/arch/x86_64/kernel/acpi/sleep.c~x86_64-64bit-ACPI-wakeup-trampoline
2007-03-07 01:28:11.000000000 +0530
+++ linux-2.6.21-rc2-reloc-root/arch/x86_64/kernel/acpi/sleep.c 2007-03-07
01:28:11.000000000 +0530
@@ -60,17 +60,6 @@ extern char wakeup_start, wakeup_end;
 
 extern unsigned long acpi_copy_wakeup_routine(unsigned long);
 
-static pgd_t low_ptr;
-
-static void init_low_mapping(void)
-{
-	pgd_t *slot0 = pgd_offset(current->mm, 0UL);
-	low_ptr = *slot0;
-	set_pgd(slot0, *pgd_offset(current->mm, PAGE_OFFSET));
-	WARN_ON(num_online_cpus() != 1);
-	local_flush_tlb();
-}
-
 /**
  * acpi_save_state_mem - save kernel state
  *
@@ -79,8 +68,6 @@ static void init_low_mapping(void)
  */
 int acpi_save_state_mem(void)
 {
-	init_low_mapping();
-
 	memcpy((void *)acpi_wakeup_address, &wakeup_start,
 	       &wakeup_end - &wakeup_start);
 	acpi_copy_wakeup_routine(acpi_wakeup_address);
@@ -93,8 +80,6 @@ int acpi_save_state_mem(void)
  */
 void acpi_restore_state_mem(void)
 {
-	set_pgd(pgd_offset(current->mm, 0UL), low_ptr);
-	local_flush_tlb();
 }
 
 /**
@@ -107,10 +92,11 @@ void acpi_restore_state_mem(void)
  */
 void __init acpi_reserve_bootmem(void)
 {
-	acpi_wakeup_address = (unsigned long)alloc_bootmem_low(PAGE_SIZE);
-	if ((&wakeup_end - &wakeup_start) > PAGE_SIZE)
+	acpi_wakeup_address = (unsigned long)alloc_bootmem_low(PAGE_SIZE*2);
+	if ((&wakeup_end - &wakeup_start) > (PAGE_SIZE*2))
 		printk(KERN_CRIT
- "ACPI: Wakeup code way too big, will crash on attempt to suspend\n");
+		       "ACPI: Wakeup code way too big, will crash on attempt"
+		       " to suspend\n");
 }
 
 static int __init acpi_sleep_setup(char *str)
diff -puN arch/x86_64/kernel/acpi/wakeup.S~x86_64-64bit-ACPI-wakeup-trampoline
arch/x86_64/kernel/acpi/wakeup.S
---
linux-2.6.21-rc2-reloc/arch/x86_64/kernel/acpi/wakeup.S~x86_64-64bit-ACPI-wakeup-trampoline
2007-03-07 01:28:11.000000000 +0530
+++ linux-2.6.21-rc2-reloc-root/arch/x86_64/kernel/acpi/wakeup.S 2007-03-07
01:28:11.000000000 +0530
@@ -1,6 +1,7 @@
 .text
 #include <linux/linkage.h>
 #include <asm/segment.h>
+#include <asm/pgtable.h>
 #include <asm/page.h>
 #include <asm/msr.h>
 
@@ -62,12 +63,15 @@ wakeup_code:
 
 	movb	$0xa2, %al	;  outb %al, $0x80
 	
-	lidt	%ds:idt_48a - wakeup_code
-	xorl	%eax, %eax
- movw %ds, %ax # (Convert %ds:gdt to a linear ptr)
-	shll	$4, %eax
-	addl	$(gdta - wakeup_code), %eax
-	movl	%eax, gdt_48a +2 - wakeup_code
+	mov	%ds, %ax			# Find 32bit wakeup_code addr
+ movzx %ax, %esi # (Convert %ds:gdt to a liner ptr)
+	shll    $4, %esi
+						# Fix up the vectors
+	addl    %esi, wakeup_32_vector - wakeup_code
+	addl    %esi, wakeup_long64_vector - wakeup_code
+	addl    %esi, gdt_48a + 2 - wakeup_code # Fixup the gdt pointer
+
+	lidtl	%ds:idt_48a - wakeup_code
 	lgdtl	%ds:gdt_48a - wakeup_code	# load gdt with whatever is
 						# appropriate
 
@@ -80,7 +84,7 @@ wakeup_code:
 
 	.balign 4
 wakeup_32_vector:
-	.long   wakeup_32 - __START_KERNEL_map
+	.long   wakeup_32 - wakeup_code
 	.word   __KERNEL32_CS, 0
 
 	.code32
@@ -103,10 +107,6 @@ wakeup_32:
 	movl	$__KERNEL_DS, %eax
 	movl	%eax, %ds
 
-	movl	saved_magic - __START_KERNEL_map, %eax
-	cmpl	$0x9abcdef0, %eax
-	jne	bogus_32_magic
-
 	movw	$0x0e00 + 'i', %ds:(0xb8012)
 	movb	$0xa8, %al	;  outb %al, $0x80;
 
@@ -120,7 +120,7 @@ wakeup_32:
 	movl	%eax, %cr4
 
 	/* Setup early boot stage 4 level pagetables */
-	movl	$(wakeup_level4_pgt - __START_KERNEL_map), %eax
+	leal    (wakeup_level4_pgt - wakeup_code)(%esi), %eax
 	movl	%eax, %cr3
 
 	/* Enable Long Mode */
@@ -159,11 +159,11 @@ wakeup_32:
 	 */
 
 	/* Finally jump in 64bit mode */
-	ljmp	*(wakeup_long64_vector - __START_KERNEL_map)
+        ljmp    *(wakeup_long64_vector - wakeup_code)(%esi)
 
 	.balign 4
 wakeup_long64_vector:
-	.long   wakeup_long64 - __START_KERNEL_map
+	.long   wakeup_long64 - wakeup_code
 	.word   __KERNEL_CS, 0
 
 .code64
@@ -178,11 +178,16 @@ wakeup_long64:
 	 * addresses where we're currently running on. We have to do that here
 	 * because in 32bit we couldn't load a 64bit linear address.
 	 */
-	lgdt	cpu_gdt_descr - __START_KERNEL_map
+	lgdt	cpu_gdt_descr
 
 	movw	$0x0e00 + 'n', %ds:(0xb8014)
 	movb	$0xa9, %al	;  outb %al, $0x80
 
+	movq    saved_magic, %rax
+	movq    $0x123456789abcdef0, %rdx
+	cmpq    %rdx, %rax
+	jne     bogus_64_magic
+
 	movw	$0x0e00 + 'u', %ds:(0xb8016)
 	
 	nop
@@ -223,20 +228,21 @@ idt_48a:
 gdt_48a:
 	.word	0x800				# gdt limit=2048,
 						#  256 GDT entries
-	.word	0, 0				# gdt base (filled in later)
-	
+	.long   gdta - wakeup_code              # gdt base (relocated in later)
 	
 real_magic:	.quad 0
 video_mode:	.quad 0
 video_flags:	.quad 0
 
+.code16
 bogus_real_magic:
 	movb	$0xba,%al	;  outb %al,$0x80
 	jmp bogus_real_magic
 
-bogus_32_magic:
+.code64
+bogus_64_magic:
 	movb	$0xb3,%al	;  outb %al,$0x80
-	jmp bogus_32_magic
+	jmp bogus_64_magic
 
 bogus_cpu:
 	movb	$0xbc,%al	;  outb %al,$0x80
@@ -263,6 +269,7 @@ bogus_cpu:
 #define VIDEO_FIRST_V7 0x0900
 
 # Setting of user mode (AX=mode ID) => CF=success
+.code16
 mode_seta:
 	movw	%ax, %bx
 #if 0
@@ -313,6 +320,13 @@ wakeup_stack_begin:	# Stack grows down
 .org	0xff0
 wakeup_stack:		# Just below end of page
 
+.org   0x1000
+ENTRY(wakeup_level4_pgt)
+	.quad   level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE
+	.fill   510,8,0
+	/* (2^48-(2*1024*1024*1024))/(2^39) = 511 */
+	.quad   level3_kernel_pgt - __START_KERNEL_map + _KERNPG_TABLE
+
 ENTRY(wakeup_end)
 	
 ##
@@ -338,9 +352,10 @@ ENTRY(acpi_copy_wakeup_routine)
 	movq	$0x123456789abcdef0, %rdx
 	movq	%rdx, saved_magic
 
-	movl	saved_magic - __START_KERNEL_map, %eax
-	cmpl	$0x9abcdef0, %eax
-	jne	bogus_32_magic
+	movq    saved_magic, %rax
+	movq    $0x123456789abcdef0, %rdx
+	cmpq    %rdx, %rax
+	jne     bogus_64_magic
 
 	# restore the regs we used
 	popq	%rdx
diff -puN arch/x86_64/kernel/head.S~x86_64-64bit-ACPI-wakeup-trampoline
arch/x86_64/kernel/head.S
---
linux-2.6.21-rc2-reloc/arch/x86_64/kernel/head.S~x86_64-64bit-ACPI-wakeup-trampoline
2007-03-07 01:28:11.000000000 +0530
+++ linux-2.6.21-rc2-reloc-root/arch/x86_64/kernel/head.S 2007-03-07
01:28:11.000000000 +0530
@@ -308,15 +308,6 @@ NEXT_PAGE(level2_kernel_pgt)
 
 	.data
 
-#ifdef CONFIG_ACPI_SLEEP
-	.align PAGE_SIZE
-ENTRY(wakeup_level4_pgt)
-	.quad	level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE
-	.fill	510,8,0
-	/* (2^48-(2*1024*1024*1024))/(2^39) = 511 */
-	.quad	level3_kernel_pgt - __START_KERNEL_map + _KERNPG_TABLE
-#endif
-
 #ifndef CONFIG_HOTPLUG_CPU
 	__INITDATA
 #endif
_

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Frédéric Riss]

Le vendredi 23 mars 2007 à 19:50 +0100, Adrian Bunk a écrit :
> Subject    : MacMini: doesn't come out of suspend to ram
> 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  : Bob Moore <robert.moore@intel.com>
>              commit c5a7156959e89b32260ad6072bbf5077bcdfbeee
> Status     : unknown

I spent some time this weekend investigating this issue more thoroughly.
In fact the regression caused by this commit has been corrected by
f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 (ACPI: Disable wake GPEs only
once.)  

However, as I pointed out in the initial report, the MacMini doesn't
come out of suspend to ram because a commit in another merged patchset
broke it. I tracked it down to:

commit e9e2cdb412412326c4827fc78ba27f410d837e6e
parent 79bf2bb335b85db25d27421c798595a2fa2a0e82 
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Fri Feb 16 01:28:04 2007 -0800

    [PATCH] clockevents: i386 drivers
    
This patch has already been mentioned in regression reports, but AFAICS
not related to suspend issues.

To be totally clear about what works and what doesn't:

79bf2bb335b85db25d27421c798595a2fa2a0e82 
   + cherry-pick f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38  ==> works

e9e2cdb412412326c4827fc78ba27f410d837e6e
   + cherry-pick f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38  ==> broken

To try to get more information, I commented the call to
do_suspend_lowlevel in drivers/acpi/sleep/main.c and used
CONFIG_DISABLE_CONSOLE_SUSPEND. Interestingly, the suspend/resume cycle
completes correctly in this mode.

Fred.

Re: [3/6] 2.6.21-rc4: known regressions

[Jeff Chua]

On 3/19/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
>
>
> Subject    : suspend to disk hangs
> References : http://lkml.org/lkml/2007/3/6/142
> Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> Status     : unknown

The good news is on 2.6.21-rc5, suspend to disk, and resume from disk works.
But, it only works with CONFIG_NO_HZ unset.

Setting CONFIG_NO_HZ will cause suspend to disk to hang just before
saving memory to disk.

Resume from RAM (s2ram) still broke (tried with or without
CONFIG_NO_HZ). Suspend to RAM seems ok, but upon resume, the screen
will only display "inu" and only after pressing the power button will
the system return to console. But "date" still doesn't advance.

Thanks,
Jeff.

Re: [3/6] 2.6.21-rc4: known regressions

[Adrian Bunk]

On Mon, Mar 26, 2007 at 09:25:51AM +0800, Jeff Chua wrote:
> On 3/19/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
> >
> >
> >Subject    : suspend to disk hangs
> >References : http://lkml.org/lkml/2007/3/6/142
> >Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> >Status     : unknown
> 
> The good news is on 2.6.21-rc5, suspend to disk, and resume from disk works.
> But, it only works with CONFIG_NO_HZ unset.

Thanks for this information.

> Setting CONFIG_NO_HZ will cause suspend to disk to hang just before
> saving memory to disk.

Thanks, noted.

> Resume from RAM (s2ram) still broke (tried with or without
> CONFIG_NO_HZ). Suspend to RAM seems ok, but upon resume, the screen
> will only display "inu" and only after pressing the power button will
> the system return to console. But "date" still doesn't advance.

This might be related to the following regression:

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

> 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

Re: [3/6] 2.6.21-rc4: known regressions

[Jeff Chua]

On 3/26/07, Adrian Bunk <bunk@stusta.de> wrote:

> > Resume from RAM (s2ram) still broke (tried with or without
> > CONFIG_NO_HZ). Suspend to RAM seems ok, but upon resume, the screen
> > will only display "inu" and only after pressing the power button will
> > the system return to console. But "date" still doesn't advance.
>
> This might be related to the following regression:
>
> Subject    : first disk access after resume takes several minutes
>              ('date' does not advance after resume from RAM, CONFIG_NO_HZ=n)
> References : http://lkml.org/lkml/2007/3/8/117
>              http://lkml.org/lkml/2007/3/25/20
> Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
> Handled-By : Thomas Gleixner <tglx@linutronix.de>
>              Ingo Molnar <mingo@elte.hu>
> Status     : problem is being debugged

Adrian,

It's related. I tested without CONFIG_HPET_TIMER, and now my X60 can
suspend and resume from RAM (s2ram). Even better, it works
with/without CONFIG_NO_HZ.

But, suspend to disk still broke with CONFIG_NO_HZ set.

Thanks,
Jeff.

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Frédéric RISS]

Le dimanche 25 mars 2007 à 23:34 +0200, Frédéric Riss a écrit :
> However, as I pointed out in the initial report, the MacMini doesn't
> come out of suspend to ram because a commit in another merged patchset
> broke it. I tracked it down to:
> 
> commit e9e2cdb412412326c4827fc78ba27f410d837e6e
> parent 79bf2bb335b85db25d27421c798595a2fa2a0e82 
> Author: Thomas Gleixner <tglx@linutronix.de>
> Date:   Fri Feb 16 01:28:04 2007 -0800
> 
>     [PATCH] clockevents: i386 drivers
>     
> This patch has already been mentioned in regression reports, but AFAICS
> not related to suspend issues.
> 
> To be totally clear about what works and what doesn't:
> 
> 79bf2bb335b85db25d27421c798595a2fa2a0e82 
>    + cherry-pick f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38  ==> works
> 
> e9e2cdb412412326c4827fc78ba27f410d837e6e
>    + cherry-pick f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38  ==> broken
> 
> To try to get more information, I commented the call to
> do_suspend_lowlevel in drivers/acpi/sleep/main.c and used
> CONFIG_DISABLE_CONSOLE_SUSPEND. Interestingly, the suspend/resume cycle
> completes correctly in this mode.

Additional data point: I just tried with -rc5 and the issue is still
present. The config I used for this test defines neither NO_HZ nor
HIGH_RES_TIMERS.

Fred.

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Thomas Gleixner]

On Mon, 2007-03-26 at 08:45 +0200, Frédéric RISS wrote:
> Additional data point: I just tried with -rc5 and the issue is still
> present. The config I used for this test defines neither NO_HZ nor
> HIGH_RES_TIMERS.

Do you have CONFIG_HPET_TIMER enabled and does the box have one ?
If yes, can you please turn it off and retry ?

Thanks,

	tglx

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Marcus Better]

[-- Attachment #1.1: Type: text/plain, Size: 940 bytes --]

Adrian Bunk wrote:
> Subject    : ThinkPad R60: suspend to disk broken
> References : http://lkml.org/lkml/2007/3/23/74
> Submitter  : Marcus Better <marcus@better.se>
> Status     : submitter tries to bisect

I just tried -rc5. Now suspend to disk seems to work. I think the XFS 
workqueue patch fixed this.

It can also suspend to RAM, but resume is worse. The first time around it 
resumed but corrupted the vesafb console (greenish blinking character cells), 
something that used to work before. But the system responded to input, so I 
suspended to RAM again. This time the resume failed, it hung after 
printing "Linux!" in yellow at the top of the screen. (Seems to be some 
artifact, I have seen it before even with working suspend.)

I'm attaching my config.

Not sure how to bisect this. I guess it would be necessary to keep the XFS 
workqueue patch throughout, otherwise it is guaranteed to break.

Marcus

[-- Attachment #1.2: .config --]
[-- Type: text/plain, Size: 47085 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.21-rc5-melech
# Mon Mar 26 10:56:13 2007
#
CONFIG_X86_64=y
CONFIG_64BIT=y
CONFIG_X86=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_ZONE_DMA32=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_CMPXCHG=y
CONFIG_EARLY_PRINTK=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_DMI=y
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
# CONFIG_TASKSTATS is not set
# CONFIG_UTS_NS is not set
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_CPUSETS is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y

#
# Block layer
#
CONFIG_BLOCK=y
# CONFIG_BLK_DEV_IO_TRACE is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_VSMP is not set
# CONFIG_MK8 is not set
# CONFIG_MPSC is not set
CONFIG_MCORE2=y
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_L1_CACHE_BYTES=64
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_INTERNODE_CACHE_BYTES=64
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_MICROCODE=m
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_X86_HT=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_MTRR=y
CONFIG_SMP=y
# CONFIG_SCHED_SMT is not set
CONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_BKL=y
# CONFIG_NUMA is not set
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_NR_CPUS=2
CONFIG_HOTPLUG_CPU=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_HPET_TIMER=y
CONFIG_IOMMU=y
# CONFIG_CALGARY_IOMMU is not set
CONFIG_SWIOTLB=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_INTEL=y
# CONFIG_X86_MCE_AMD is not set
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
CONFIG_PHYSICAL_START=0x100000
CONFIG_SECCOMP=y
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR_ALL is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_300=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=300
CONFIG_REORDER=y
CONFIG_K8_NB=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_ISA_DMA_API=y
CONFIG_GENERIC_PENDING_IRQ=y

#
# Power management options
#
CONFIG_PM=y
# CONFIG_PM_LEGACY is not set
# CONFIG_PM_DEBUG is not set
CONFIG_PM_SYSFS_DEPRECATED=y
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_STD_PARTITION="/dev/mapper/swap"
CONFIG_SUSPEND_SMP=y

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
# CONFIG_ACPI_SLEEP_PROC_SLEEP is not set
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=m
CONFIG_ACPI_DOCK=m
# CONFIG_ACPI_BAY is not set
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_THERMAL=m
# CONFIG_ACPI_ASUS is not set
CONFIG_ACPI_IBM=m
CONFIG_ACPI_IBM_BAY=y
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=m
# CONFIG_ACPI_SBS is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=m
# CONFIG_CPU_FREQ_DEBUG is not set
CONFIG_CPU_FREQ_STAT=m
# CONFIG_CPU_FREQ_STAT_DETAILS is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=m
CONFIG_CPU_FREQ_GOV_ONDEMAND=m
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m

#
# CPUFreq processor drivers
#
# CONFIG_X86_POWERNOW_K8 is not set
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
CONFIG_X86_ACPI_CPUFREQ=m

#
# shared options
#
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
# CONFIG_X86_P4_CLOCKMOD is not set
# CONFIG_X86_SPEEDSTEP_LIB is not set

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCIEPORTBUS=y
CONFIG_PCIEAER=y
CONFIG_PCI_MSI=y
CONFIG_HT_IRQ=y

#
# PCCARD (PCMCIA/CardBus) support
#
CONFIG_PCCARD=m
# CONFIG_PCMCIA_DEBUG is not set
CONFIG_PCMCIA=m
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_PCMCIA_IOCTL=y
CONFIG_CARDBUS=y

#
# PC-card bridges
#
CONFIG_YENTA=m
# CONFIG_YENTA_O2 is not set
# CONFIG_YENTA_RICOH is not set
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
# CONFIG_YENTA_TOSHIBA is not set
# CONFIG_PD6729 is not set
# CONFIG_I82092 is not set
CONFIG_PCCARD_NONSTATIC=m

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_IA32_EMULATION=y
# CONFIG_IA32_AOUT is not set
CONFIG_COMPAT=y
CONFIG_SYSVIPC_COMPAT=y

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=m
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
CONFIG_NET_KEY=m
# CONFIG_NET_KEY_MIGRATE is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
CONFIG_INET_XFRM_MODE_TRANSPORT=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
CONFIG_IPV6=m
CONFIG_IPV6_PRIVACY=y
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
CONFIG_IPV6_MIP6=y
CONFIG_INET6_XFRM_TUNNEL=m
CONFIG_INET6_TUNNEL=m
CONFIG_INET6_XFRM_MODE_TRANSPORT=m
CONFIG_INET6_XFRM_MODE_TUNNEL=m
CONFIG_INET6_XFRM_MODE_BEET=m
CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m
CONFIG_IPV6_SIT=m
CONFIG_IPV6_TUNNEL=m
CONFIG_IPV6_MULTIPLE_TABLES=y
CONFIG_IPV6_SUBTREES=y
# CONFIG_NETLABEL is not set
CONFIG_NETWORK_SECMARK=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
CONFIG_NF_CONNTRACK_ENABLED=m
CONFIG_NF_CONNTRACK_SUPPORT=y
# CONFIG_IP_NF_CONNTRACK_SUPPORT is not set
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CT_ACCT=y
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_SECMARK=y
# CONFIG_NF_CONNTRACK_EVENTS is not set
# CONFIG_NF_CT_PROTO_SCTP is not set
# CONFIG_NF_CONNTRACK_AMANDA is not set
# CONFIG_NF_CONNTRACK_FTP is not set
# CONFIG_NF_CONNTRACK_H323 is not set
# CONFIG_NF_CONNTRACK_IRC is not set
# CONFIG_NF_CONNTRACK_NETBIOS_NS is not set
# CONFIG_NF_CONNTRACK_PPTP is not set
# CONFIG_NF_CONNTRACK_SANE is not set
# CONFIG_NF_CONNTRACK_SIP is not set
# CONFIG_NF_CONNTRACK_TFTP is not set
CONFIG_NF_CT_NETLINK=m
CONFIG_NETFILTER_XTABLES=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
# CONFIG_NETFILTER_XT_TARGET_DSCP is not set
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m
# CONFIG_NETFILTER_XT_TARGET_TCPMSS is not set
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
# CONFIG_NETFILTER_XT_MATCH_CONNBYTES is not set
CONFIG_NETFILTER_XT_MATCH_CONNMARK=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
CONFIG_NETFILTER_XT_MATCH_DCCP=m
# CONFIG_NETFILTER_XT_MATCH_DSCP is not set
CONFIG_NETFILTER_XT_MATCH_ESP=m
CONFIG_NETFILTER_XT_MATCH_HELPER=m
CONFIG_NETFILTER_XT_MATCH_LENGTH=m
CONFIG_NETFILTER_XT_MATCH_LIMIT=m
CONFIG_NETFILTER_XT_MATCH_MAC=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
CONFIG_NETFILTER_XT_MATCH_POLICY=m
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
# CONFIG_NETFILTER_XT_MATCH_QUOTA is not set
CONFIG_NETFILTER_XT_MATCH_REALM=m
CONFIG_NETFILTER_XT_MATCH_SCTP=m
CONFIG_NETFILTER_XT_MATCH_STATE=m
# CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
# CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set

#
# IP: Netfilter Configuration
#
CONFIG_NF_CONNTRACK_IPV4=m
# CONFIG_NF_CONNTRACK_PROC_COMPAT is not set
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
# CONFIG_IP_NF_TARGET_LOG is not set
# CONFIG_IP_NF_TARGET_ULOG is not set
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
# CONFIG_IP_NF_TARGET_NETMAP is not set
# CONFIG_IP_NF_TARGET_SAME is not set
# CONFIG_NF_NAT_SNMP_BASIC is not set
# CONFIG_NF_NAT_FTP is not set
# CONFIG_NF_NAT_IRC is not set
# CONFIG_NF_NAT_TFTP is not set
# CONFIG_NF_NAT_AMANDA is not set
# CONFIG_NF_NAT_PPTP is not set
# CONFIG_NF_NAT_H323 is not set
# CONFIG_NF_NAT_SIP is not set
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_TTL=m
# CONFIG_IP_NF_TARGET_CLUSTERIP is not set
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m

#
# IPv6: Netfilter Configuration (EXPERIMENTAL)
#
CONFIG_NF_CONNTRACK_IPV6=m
# CONFIG_IP6_NF_QUEUE is not set
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_MATCH_OPTS=m
CONFIG_IP6_NF_MATCH_FRAG=m
CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_OWNER=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_AH=m
# CONFIG_IP6_NF_MATCH_MH is not set
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_FILTER=m
# CONFIG_IP6_NF_TARGET_LOG is not set
CONFIG_IP6_NF_TARGET_REJECT=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_TARGET_HL=m
CONFIG_IP6_NF_RAW=m

#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set

#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
CONFIG_NET_CLS_ROUTE=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_SCO=m
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=m
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y
CONFIG_BT_HIDP=m

#
# Bluetooth device drivers
#
CONFIG_BT_HCIUSB=m
CONFIG_BT_HCIUSB_SCO=y
# CONFIG_BT_HCIUART is not set
# CONFIG_BT_HCIBCM203X is not set
# CONFIG_BT_HCIBPA10X is not set
# CONFIG_BT_HCIBFUSB is not set
# CONFIG_BT_HCIDTL1 is not set
# CONFIG_BT_HCIBT3C is not set
# CONFIG_BT_HCIBLUECARD is not set
# CONFIG_BT_HCIBTUART is not set
CONFIG_BT_HCIVHCI=m
CONFIG_IEEE80211=m
CONFIG_IEEE80211_DEBUG=y
CONFIG_IEEE80211_CRYPT_WEP=m
CONFIG_IEEE80211_CRYPT_CCMP=m
CONFIG_IEEE80211_SOFTMAC=m
CONFIG_IEEE80211_SOFTMAC_DEBUG=y
CONFIG_WIRELESS_EXT=y
CONFIG_FIB_RULES=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
# CONFIG_SYS_HYPERVISOR is not set

#
# Connector - unified userspace <-> kernelspace linker
#
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_PC_FIFO=y
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_PC_PCMCIA is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
CONFIG_PARPORT_1284=y

#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
CONFIG_PNPACPI=y

#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=8192
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
# CONFIG_ATA_OVER_ETH is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_MSI_LAPTOP is not set
# CONFIG_SONY_LAPTOP is not set

#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
# CONFIG_SCSI_PROC_FS is not set

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
# CONFIG_BLK_DEV_SR_VENDOR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set

#
# SCSI low-level drivers
#
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_SRP is not set

#
# PCMCIA SCSI adapter support
#
# CONFIG_PCMCIA_FDOMAIN is not set
# CONFIG_PCMCIA_QLOGIC is not set
# CONFIG_PCMCIA_SYM53C500 is not set

#
# Serial ATA (prod) and Parallel ATA (experimental) drivers
#
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_SATA_AHCI=y
# CONFIG_SATA_SVW is not set
CONFIG_ATA_PIIX=y
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIL24 is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# CONFIG_SATA_INIC162X is not set
CONFIG_SATA_ACPI=y
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
CONFIG_ATA_GENERIC=y
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PCMCIA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
# CONFIG_PATA_PLATFORM is not set

#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
CONFIG_BLK_DEV_DM=m
# CONFIG_DM_DEBUG is not set
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
CONFIG_DM_ZERO=m
# CONFIG_DM_MULTIPATH is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_SPI is not set
# CONFIG_FUSION_FC is not set
# CONFIG_FUSION_SAS is not set

#
# IEEE 1394 (FireWire) support
#
CONFIG_IEEE1394=m

#
# Subsystem Options
#
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
CONFIG_IEEE1394_EXTRA_CONFIG_ROMS=y
CONFIG_IEEE1394_CONFIG_ROM_IP1394=y

#
# Device Drivers
#
# CONFIG_IEEE1394_PCILYNX is not set
CONFIG_IEEE1394_OHCI1394=m

#
# Protocol Drivers
#
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
CONFIG_IEEE1394_ETH1394=m
# CONFIG_IEEE1394_DV1394 is not set
CONFIG_IEEE1394_RAWIO=m

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Macintosh device drivers
#
# CONFIG_MAC_EMUMOUSEBTN is not set

#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
CONFIG_BONDING=m
# CONFIG_EQUALIZER is not set
CONFIG_TUN=m
# CONFIG_NET_SB1000 is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# PHY device support
#

#
# Ethernet (10 or 100Mbit)
#
# CONFIG_NET_ETHERNET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN is not set
CONFIG_TIGON3=m
# CONFIG_BNX2 is not set
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_CHELSIO_T3 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
# CONFIG_MYRI10GE is not set
# CONFIG_NETXEN_NIC is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# PCMCIA network device support
#
# CONFIG_NET_PCMCIA is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
CONFIG_PPP=m
# CONFIG_PPP_MULTILINK is not set
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
# CONFIG_PPP_SYNC_TTY is not set
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
# CONFIG_PPP_MPPE is not set
# CONFIG_PPPOE is not set
# CONFIG_SLIP is not set
CONFIG_SLHC=m
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
CONFIG_NETCONSOLE=m
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=m
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=m
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=m
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=m
# CONFIG_INPUT_ATLAS_BTNS is not set
CONFIG_INPUT_UINPUT=m

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=m
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
CONFIG_SERIO_RAW=m
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_CONSOLE is not set
# CONFIG_SERIAL_8250_PCI is not set
CONFIG_SERIAL_8250_PNP=y
# CONFIG_SERIAL_8250_CS is not set
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=1
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_PRINTER=m
# CONFIG_LP_CONSOLE is not set
CONFIG_PPDEV=m
# CONFIG_TIPAR is not set

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
# CONFIG_ALIM1535_WDT is not set
# CONFIG_ALIM7101_WDT is not set
# CONFIG_SC520_WDT is not set
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
# CONFIG_IBMASR is not set
# CONFIG_WAFER_WDT is not set
# CONFIG_I6300ESB_WDT is not set
# CONFIG_I8XX_TCO is not set
CONFIG_ITCO_WDT=m
# CONFIG_ITCO_VENDOR_SUPPORT is not set
# CONFIG_SC1200_WDT is not set
# CONFIG_PC87413_WDT is not set
# CONFIG_60XX_WDT is not set
# CONFIG_SBC8360_WDT is not set
# CONFIG_CPU5_WDT is not set
# CONFIG_SMSC37B787_WDT is not set
# CONFIG_W83627HF_WDT is not set
# CONFIG_W83697HF_WDT is not set
# CONFIG_W83877F_WDT is not set
# CONFIG_W83977F_WDT is not set
# CONFIG_MACHZ_WDT is not set
# CONFIG_SBC_EPX_C3_WATCHDOG is not set

#
# PCI-based Watchdog Cards
#
# CONFIG_PCIPCWATCHDOG is not set
# CONFIG_WDTPCI is not set

#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
CONFIG_HW_RANDOM=m
CONFIG_HW_RANDOM_INTEL=m
# CONFIG_HW_RANDOM_AMD is not set
# CONFIG_HW_RANDOM_GEODE is not set
CONFIG_NVRAM=m
CONFIG_RTC=m
CONFIG_GEN_RTC=m
CONFIG_GEN_RTC_X=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_VIA is not set
CONFIG_DRM=m
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_I810 is not set
# CONFIG_DRM_I830 is not set
CONFIG_DRM_I915=m
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
# CONFIG_CARDMAN_4000 is not set
# CONFIG_CARDMAN_4040 is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HPET=y
# CONFIG_HPET_RTC_IRQ is not set
CONFIG_HPET_MMAP=y
CONFIG_HANGCHECK_TIMER=m

#
# TPM devices
#
CONFIG_TCG_TPM=m
CONFIG_TCG_TIS=m
# CONFIG_TCG_NSC is not set
# CONFIG_TCG_ATMEL is not set
# CONFIG_TCG_INFINEON is not set
# CONFIG_TELCLOCK is not set

#
# I2C support
#
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=m

#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
CONFIG_I2C_I801=m
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PASEMI is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set

#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
CONFIG_SENSORS_EEPROM=m
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Hardware Monitoring support
#
CONFIG_HWMON=m
# CONFIG_HWMON_VID is not set
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
CONFIG_SENSORS_HDAPS=m
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m
# CONFIG_VIDEO_V4L1 is not set
# CONFIG_VIDEO_V4L1_COMPAT is not set
CONFIG_VIDEO_V4L2=y

#
# Video Capture Adapters
#

#
# Video Capture Adapters
#
# CONFIG_VIDEO_ADV_DEBUG is not set
CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
# CONFIG_VIDEO_VIVI is not set
# CONFIG_VIDEO_SAA5246A is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_CX88 is not set
# CONFIG_VIDEO_CAFE_CCIC is not set

#
# V4L USB devices
#
# CONFIG_VIDEO_PVRUSB2 is not set
# CONFIG_VIDEO_USBVISION is not set

#
# Radio Adapters
#
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
# CONFIG_USB_DSBR is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
# CONFIG_USB_DABUSB is not set

#
# Graphics support
#
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=m
CONFIG_LCD_CLASS_DEVICE=m
# CONFIG_BACKLIGHT_PROGEAR is not set
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_DDC=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set

#
# Frambuffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
CONFIG_FB_VESA=y
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
CONFIG_FB_INTEL=y
CONFIG_FB_INTEL_DEBUG=y
CONFIG_FB_INTEL_I2C=y
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_VIDEO_SELECT=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y

#
# Logo configuration
#
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y

#
# Sound
#
CONFIG_SOUND=m

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
# CONFIG_SND_DYNAMIC_MINORS is not set
# CONFIG_SND_SUPPORT_OLD_API is not set
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
CONFIG_SND_DUMMY=m
CONFIG_SND_VIRMIDI=m
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_MTS64 is not set
CONFIG_SND_SERIAL_U16550=m
# CONFIG_SND_MPU401 is not set
# CONFIG_SND_PORTMAN2X4 is not set

#
# PCI devices
#
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
CONFIG_SND_HDA_INTEL=m
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set

#
# USB devices
#
CONFIG_SND_USB_AUDIO=m
# CONFIG_SND_USB_USX2Y is not set

#
# PCMCIA devices
#
# CONFIG_SND_VXPOCKET is not set
# CONFIG_SND_PDAUDIOCF is not set

#
# SoC audio support
#
# CONFIG_SND_SOC is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# HID Devices
#
CONFIG_HID=m
# CONFIG_HID_DEBUG is not set

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_SPLIT_ISO=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_EHCI_BIG_ENDIAN_MMIO is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=m
# CONFIG_USB_SL811_HCD is not set

#
# USB Device Class drivers
#
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#

#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_LIBUSUAL is not set

#
# USB Input Devices
#
# CONFIG_USB_HID is not set

#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_ACECAD is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_TOUCHSCREEN is not set
# CONFIG_USB_YEALINK is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set
# CONFIG_USB_ATI_REMOTE2 is not set
# CONFIG_USB_KEYSPAN_REMOTE is not set
# CONFIG_USB_APPLETOUCH is not set
# CONFIG_USB_GTCO is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET_MII is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_MON is not set

#
# USB port drivers
#
# CONFIG_USB_USS720 is not set

#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
# CONFIG_USB_SERIAL_AIRCABLE is not set
# CONFIG_USB_SERIAL_AIRPRIME is not set
# CONFIG_USB_SERIAL_ARK3116 is not set
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_CP2101 is not set
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
# CONFIG_USB_SERIAL_EMPEG is not set
# CONFIG_USB_SERIAL_FTDI_SIO is not set
# CONFIG_USB_SERIAL_FUNSOFT is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
# CONFIG_USB_SERIAL_GARMIN is not set
# CONFIG_USB_SERIAL_IPW is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_MOS7720 is not set
# CONFIG_USB_SERIAL_MOS7840 is not set
# CONFIG_USB_SERIAL_NAVMAN is not set
# CONFIG_USB_SERIAL_PL2303 is not set
# CONFIG_USB_SERIAL_HP4X is not set
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_SIERRAWIRELESS is not set
# CONFIG_USB_SERIAL_TI is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
CONFIG_USB_SERIAL_OPTION=m
# CONFIG_USB_SERIAL_OMNINET is not set
# CONFIG_USB_SERIAL_DEBUG is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_BERRY_CHARGE is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set

#
# USB DSL modem support
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# LED devices
#
CONFIG_NEW_LEDS=y
# CONFIG_LEDS_CLASS is not set

#
# LED drivers
#

#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
# CONFIG_LEDS_TRIGGER_TIMER is not set
# CONFIG_LEDS_TRIGGER_HEARTBEAT is not set

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#
# CONFIG_EDAC is not set

#
# Real Time Clock
#
CONFIG_RTC_LIB=m
CONFIG_RTC_CLASS=m

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=m
CONFIG_RTC_INTF_PROC=m
CONFIG_RTC_INTF_DEV=m
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set

#
# RTC drivers
#
# CONFIG_RTC_DRV_CMOS is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_TEST is not set
# CONFIG_RTC_DRV_V3020 is not set

#
# DMA Engine support
#
# CONFIG_DMA_ENGINE is not set

#
# DMA Clients
#

#
# DMA Devices
#

#
# Auxiliary Display support
#
# CONFIG_KS0108 is not set

#
# Virtualization
#
CONFIG_KVM=m
CONFIG_KVM_INTEL=m
# CONFIG_KVM_AMD is not set

#
# Firmware Drivers
#
CONFIG_EDD=m
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set

#
# File systems
#
CONFIG_EXT2_FS=m
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=m
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
# CONFIG_EXT4DEV_FS is not set
CONFIG_JBD=m
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=m
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
CONFIG_REISERFS_FS_XATTR=y
CONFIG_REISERFS_FS_POSIX_ACL=y
CONFIG_REISERFS_FS_SECURITY=y
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_XFS_FS=m
CONFIG_XFS_QUOTA=y
CONFIG_XFS_SECURITY=y
CONFIG_XFS_POSIX_ACL=y
CONFIG_XFS_RT=y
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_QUOTA=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=m
CONFIG_QUOTACTL=y
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=m
CONFIG_FUSE_FS=m

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
# CONFIG_MSDOS_FS is not set
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_VMCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
CONFIG_CONFIGFS_FS=m

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
CONFIG_HFS_FS=m
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=y
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=m
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_NFS_ACL_SUPPORT=m
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_RPCSEC_GSS_KRB5=m
# CONFIG_RPCSEC_GSS_SPKM3 is not set
CONFIG_SMB_FS=m
# CONFIG_SMB_NLS_DEFAULT is not set
CONFIG_CIFS=m
# CONFIG_CIFS_STATS is not set
# CONFIG_CIFS_WEAK_PW_HASH is not set
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
# CONFIG_CIFS_DEBUG2 is not set
CONFIG_CIFS_EXPERIMENTAL=y
CONFIG_CIFS_UPCALL=y
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
CONFIG_LDM_PARTITION=y
# CONFIG_LDM_DEBUG is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=m
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=m
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=m
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=m

#
# Distributed Lock Manager
#
# CONFIG_DLM is not set

#
# Instrumentation Support
#
# CONFIG_PROFILING is not set
# CONFIG_KPROBES is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_UNUSED_SYMBOLS=y
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_KERNEL is not set
CONFIG_LOG_BUF_SHIFT=15
# CONFIG_DEBUG_BUGVERBOSE is not set

#
# Security options
#
CONFIG_KEYS=y
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_NETWORK_XFRM=y
CONFIG_SECURITY_CAPABILITIES=y
# CONFIG_SECURITY_ROOTPLUG is not set
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=y
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=m
CONFIG_CRYPTO_HASH=m
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_HMAC=m
CONFIG_CRYPTO_XCBC=m
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=m
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_WP512=m
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_GF128MUL=m
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
CONFIG_CRYPTO_TWOFISH_X86_64=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_X86_64=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_CRC32C=m
CONFIG_CRYPTO_CAMELLIA=m
# CONFIG_CRYPTO_TEST is not set

#
# Hardware crypto devices
#

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=m
CONFIG_CRC32=y
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_TEXTSEARCH_BM=m
CONFIG_TEXTSEARCH_FSM=m
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y

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

Re: [2/5] 2.6.21-rc4: known regressions (v2)

[Tejun Heo]

Adrian Bunk wrote:
> 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
> Submitter  : Mathieu Bérard <Mathieu.Berard@crans.org>
> Handled-By : Tejun Heo <htejun@gmail.com>
> Status     : problem is being debugged

Patch is available and whether to put it into mainline or not is being
discussed.  libata EH does the right thing after several errors so
things should work properly after several errors.

http://thread.gmane.org/gmane.linux.kernel/496524

> 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>
>              Alan Cox <alan@lxorguk.ukuu.org.uk>
> Status     : Alan: Some cases should be fixed now but probably not all
>                    (eg the Nvidia one)

Further patch submitted.

http://thread.gmane.org/gmane.linux.ide/17444

This should fix all regression cases.  sata_nv has been always broken so
isn't a regression.  It needs acpi tricks and I don't think it fits
2.6.21 cycle.

Thanks.

-- 
tejun

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Frederic Riss]

2007/3/26, Thomas Gleixner <tglx@linutronix.de>:
> On Mon, 2007-03-26 at 08:45 +0200, Frédéric RISS wrote:
> > Additional data point: I just tried with -rc5 and the issue is still
> > present. The config I used for this test defines neither NO_HZ nor
> > HIGH_RES_TIMERS.
>
> Do you have CONFIG_HPET_TIMER enabled and does the box have one ?
> If yes, can you please turn it off and retry ?

IIRC the box has a HPET and it gets used. I'll test and confirm when I
get home tonight.

Thanks,
Fred

Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"

[Pavel Machek]

Hi!

> It turned out that it is almost impossible to trust ACPI, BIOS & Co.
> regarding the C states. This was the reason to switch the local apic
> timer off in C2 state already. OTOH there are sane and well behaving
> systems, which get punished by that decision.
> 
> Allow the user to confirm that the local apic timer is trustworthy in C2
> state. This keeps the default behaviour on the safe side.
...
> @@ -780,6 +780,9 @@ and is between 256 and 4096 characters. It is defined in the file
>  	lapic		[IA-32,APIC] Enable the local APIC even if BIOS
>  			disabled it.
>  
> +	lapic_timer_c2_ok	[IA-32,APIC] trust the local apic timer in
> +			C2 power state.
> +

Could you add comment saying that this is always ok on non-broken
systems? That way perhaps it can be added to linux-firmware-test-cd,
etc.

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

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Pavel Machek]

Hi!

> > Subject    : ThinkPad R60: suspend to disk broken
> > References : http://lkml.org/lkml/2007/3/23/74
> > Submitter  : Marcus Better <marcus@better.se>
> > Status     : submitter tries to bisect
> 
> I just tried -rc5. Now suspend to disk seems to work. I think the XFS 
> workqueue patch fixed this.
> 
> It can also suspend to RAM, but resume is worse. The first time around it 
> resumed but corrupted the vesafb console (greenish blinking character cells), 
> something that used to work before. But the system responded to input, so I 
> suspended to RAM again. This time the resume failed, it hung after 
> printing "Linux!" in yellow at the top of the screen. (Seems to be some 
> artifact, I have seen it before even with working suspend.)

Yellow Linux! is my debugging trick. It should be there, but it should
also disapear quickly.

Try vga=0 ... text console seems to work for you.
							Pavel

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

Re: 2.6.21-rc4: known regressions with patches (v2)

[Bob Tracy]

Adrian Bunk wrote:
> Subject    : boot hangs during IDE detection  (clocksource)
> References : http://lkml.org/lkml/2007/3/19/465
> Submitter  : Bob Tracy <rct@gherkin.frus.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

The subject problem is fixed *without* the workaround patch in
2.6.21-rc5.  The acpi_pm clocksource patch for the case where the
PIIX4 bug is present should probably be included anyway.

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

Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"

[Thomas Gleixner]

On Mon, 2007-03-26 at 12:31 +0000, Pavel Machek wrote:
> > +	lapic_timer_c2_ok	[IA-32,APIC] trust the local apic timer in
> > +			C2 power state.
> > +
> 
> Could you add comment saying that this is always ok on non-broken
> systems? That way perhaps it can be added to linux-firmware-test-cd,
> etc.

Yep, post .21. 

I still twist my brain how to autodetect that in a safe way, which would
make it really useful for the firmware tester.

	tglx

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Marcus Better]

Pavel Machek wrote:

>> > Subject    : ThinkPad R60: suspend to disk broken
>> > References : http://lkml.org/lkml/2007/3/23/74

>> input, so I suspended to RAM again. This time the resume failed, it hung
>> after printing "Linux!" in yellow at the top of the screen.

> Yellow Linux! is my debugging trick.

Cute :-)

Here is my bisect log so far, with 98 revisions left. Note that all kernels have the XFS workqueue patch applied.

~$ git bisect log
git-bisect start
# bad: [6fb04ccf5c5e054c4107090bed6e866489f1089f] Linux 2.6.21-rc5
git-bisect bad 6fb04ccf5c5e054c4107090bed6e866489f1089f
# good: [c8f71b01a50597e298dc3214a2f2be7b8d31170c] Linux 2.6.21-rc1
git-bisect good c8f71b01a50597e298dc3214a2f2be7b8d31170c
# good: [ad5f1196792653dadf09c07a5fa917092b469c1c] ecryptfs: check xattr operation support fix
git-bisect good ad5f1196792653dadf09c07a5fa917092b469c1c
# good: [271368b69b9e8042063d6c713423e84503bbdaa0] Merge master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6
git-bisect good 271368b69b9e8042063d6c713423e84503bbdaa0
# bad: [f5b42c3324494ea3f9bf795e2a7e4d3cbb06c607] KVM: Fix guest sysenter on vmx
git-bisect bad f5b42c3324494ea3f9bf795e2a7e4d3cbb06c607

The bad kernels exhibit the hang on second resume from RAM.

The "good" ones all have the artifact with corrupted display. Moreover, they resume immediately from every suspend to RAM _after_ a suspend-to-disk, but not before it. This is when suspending with "echo mem > /sys/power/state".

> Try vga=0 ... text console seems to work for you.

Ok, will try.

Marcus

Re: [4/5] 2.6.21-rc4: known regressions (v2)

[Michael S. Tsirkin]

Update: I tested 2.6.21-rc5 with the following settings
# CONFIG_NO_HZ is not set
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_HPET is not set

1. Without additional kernel options

  After systems comes out of suspend to ram, I observed the following
  behaviour (I used s2ram from console):
  1. The first disk access takes much longer than with 2.6.20
  2. System clock does not advance (date always reports the same time)
  3. After an attempt to switch to X, X starts drawing some windows and then hangs
  All 3 issues are new and did not occur under 2.6.20, so this is a regression.

2. Setting clocksource=acpi_pm
After resume from RAM
  1. The first disk access takes much longer than with 2.6.20
  2. System clock seems to advance properly
  3. After an attempt to switch to X, X works correctly

So it seems that clocksource=acpi_pm can be used as a work-around.
What does this tell us?

I'm also not happy with how clocksource=acpi_pm performs -
the system seems to be jerky, stalling for fractions of
seconds now and them.

TODO: test without CONFIG_HPET_TIMER.

-- 
MST

Re: [patch] hrtimers debug patch

[Thomas Gleixner]

On Mon, 2007-03-26 at 16:20 +0200, Michal Piotrowski wrote:
> >
> > I've got a crash dump, I'll try to figure out what is causing it ;)
> >
> 
> That might be useful
> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc5/

Can you please upload a disassembly of hrtimer_interrupt() ?

I stared at hrtimer_interrupt() for quite a long time and I don't see
how it can leave without reprogramming the event, when there are timers
pending. And there are enough timers pending.

	tglx

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Adrian Bunk]

On Mon, Mar 26, 2007 at 12:00:22PM +0200, Marcus Better wrote:
> Adrian Bunk wrote:
> > Subject    : ThinkPad R60: suspend to disk broken
> > References : http://lkml.org/lkml/2007/3/23/74
> > Submitter  : Marcus Better <marcus@better.se>
> > Status     : submitter tries to bisect
> 
> I just tried -rc5. Now suspend to disk seems to work. I think the XFS 
> workqueue patch fixed this.
> 
> It can also suspend to RAM, but resume is worse. The first time around it 
> resumed but corrupted the vesafb console (greenish blinking character cells), 
> something that used to work before. But the system responded to input, so I 
> suspended to RAM again. This time the resume failed, it hung after 
> printing "Linux!" in yellow at the top of the screen. (Seems to be some 
> artifact, I have seen it before even with working suspend.)
>...

Does setting CONFIG_PCI_MSI=n make any difference?

> Marcus

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [patch] hrtimers debug patch

[Michal Piotrowski]

On 26/03/07, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Mon, 2007-03-26 at 16:20 +0200, Michal Piotrowski wrote:
> > >
> > > I've got a crash dump, I'll try to figure out what is causing it ;)
> > >
> >
> > That might be useful
> > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc5/
>
> Can you please upload a disassembly of hrtimer_interrupt() ?

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

http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc5/gdb.debug

>
> I stared at hrtimer_interrupt() for quite a long time and I don't see
> how it can leave without reprogramming the event, when there are timers
> pending. And there are enough timers pending.
>
>         tglx
>
>
>

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

Re: [patch] hrtimers debug patch

[Michal Piotrowski]

On 26/03/07, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> On 26/03/07, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Mon, 2007-03-26 at 16:20 +0200, Michal Piotrowski wrote:
> > > >
> > > > I've got a crash dump, I'll try to figure out what is causing it ;)
> > > >
> > >
> > > That might be useful
> > > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc5/
> >
> > Can you please upload a disassembly of hrtimer_interrupt() ?
>
> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc5/dis_hrtimer_interrupt
>

I just noticed, that 'dis hrtimer_interrupt > dis_hrtimer_interrupt'
doesn't save the whole output.

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

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

Re: [3/6] 2.6.21-rc4: known regressions

[Thomas Gleixner]

On Mon, 2007-03-26 at 13:37 +0800, Jeff Chua wrote:
> On 3/26/07, Adrian Bunk <bunk@stusta.de> wrote:
> 
> > > Resume from RAM (s2ram) still broke (tried with or without
> > > CONFIG_NO_HZ). Suspend to RAM seems ok, but upon resume, the screen
> > > will only display "inu" and only after pressing the power button will
> > > the system return to console. But "date" still doesn't advance.
> >
> > This might be related to the following regression:
> >
> > Subject    : first disk access after resume takes several minutes
> >              ('date' does not advance after resume from RAM, CONFIG_NO_HZ=n)
> > References : http://lkml.org/lkml/2007/3/8/117
> >              http://lkml.org/lkml/2007/3/25/20
> > Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
> > Handled-By : Thomas Gleixner <tglx@linutronix.de>
> >              Ingo Molnar <mingo@elte.hu>
> > Status     : problem is being debugged
> 
> Adrian,
> 
> It's related. I tested without CONFIG_HPET_TIMER, and now my X60 can
> suspend and resume from RAM (s2ram). Even better, it works
> with/without CONFIG_NO_HZ.

Does the patch below fix the HPET_TIMER=y case ?

	tglx

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

Re: [patch] hrtimers debug patch

[Ingo Molnar]

* Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:

> Stardust is down, console log and config attached.

thanks! I have stared at hrtimer.c a few more hours and the good news is 
that i found a narrow SMP race. The bad news is that i dont think it 
could explain your bug symptoms: the worst-case effect of the race 
should be an incorrect timeout on the current CPU - not a KTIME_MAX 
thing like your logs show.

But maybe i didnt think through the effects of the bug well enough, and 
your box has a HT CPU, with HT CPUs being pretty good at triggering 
narrow SMP races - so maybe we are lucky? Fix attached below. Patch is 
build and boot-tested.

	Ingo

------------------>
Subject: [patch] hrtimers: fix reprogramming SMP race
From: Ingo Molnar <mingo@elte.hu>

hrtimer_start() incorrectly set the 'reprogram' flag to 
enqueue_hrtimer(), which should only be 1 if the hrtimer is queued to 
the current CPU.

doing otherwise could result in a reprogramming of the current CPU's 
clockevents device, with a timer that is not queued to it - resulting in 
a bogus next expiry value.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Needs-to-be-tested-by: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
---
 kernel/hrtimer.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

Index: linux/kernel/hrtimer.c
===================================================================
--- linux.orig/kernel/hrtimer.c
+++ linux/kernel/hrtimer.c
@@ -844,7 +844,12 @@ hrtimer_start(struct hrtimer *timer, kti
 
 	timer_stats_hrtimer_set_start_info(timer);
 
-	enqueue_hrtimer(timer, new_base, base == new_base);
+	/*
+	 * Only allow reprogramming if the new base is on this CPU.
+	 * (it might still be on another CPU if the timer was pending)
+	 */
+	enqueue_hrtimer(timer, new_base,
+			new_base->cpu_base == &__get_cpu_var(hrtimer_bases));
 
 	unlock_hrtimer_base(timer, &flags);
 

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Marcus Better]

Adrian Bunk wrote:
> > > Subject    : ThinkPad R60: suspend to disk broken

> Does setting CONFIG_PCI_MSI=n make any difference?

Yes, it does. The hanging resume problem went away. 

(The display corruption and the instant resume were not affected.)

Marcus

Re: [3/6] 2.6.21-rc4: known regressions

[Jeff Chua]

On 3/27/07, Thomas Gleixner <tglx@linutronix.de> wrote:

> > It's related. I tested without CONFIG_HPET_TIMER, and now my X60 can
> > suspend and resume from RAM (s2ram). Even better, it works
> > with/without CONFIG_NO_HZ.
>
> Does the patch below fix the HPET_TIMER=y case ?

Thomas, I tried, but it didn't help. Upon resume from ram, "date"
still didn't advance.

Thanks,
Jeff.

Re: [patch] hrtimers debug patch

[Michal Piotrowski]

On 26/03/07, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
>
> > Stardust is down, console log and config attached.
>
> thanks! I have stared at hrtimer.c a few more hours and the good news is
> that i found a narrow SMP race. The bad news is that i dont think it
> could explain your bug symptoms: the worst-case effect of the race
> should be an incorrect timeout on the current CPU - not a KTIME_MAX
> thing like your logs show.
>
> But maybe i didnt think through the effects of the bug well enough, and
> your box has a HT CPU, with HT CPUs being pretty good at triggering
> narrow SMP races - so maybe we are lucky? Fix attached below. Patch is
> build and boot-tested.

Thanks. Verification may take some time.

>
>         Ingo
>

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

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Adrian Bunk]

On Mon, Mar 26, 2007 at 07:42:51PM +0200, Marcus Better wrote:
> Adrian Bunk wrote:
> > > > Subject    : ThinkPad R60: suspend to disk broken
> 
> > Does setting CONFIG_PCI_MSI=n make any difference?
> 
> Yes, it does. The hanging resume problem went away. 

Thanks for testing.

If you enable it again, does the patch from [1] also fix it?

> (The display corruption and the instant resume were not affected.)

Not a surprise - it's currently quite common that people run into 
several distinct suspend regressions...

> Marcus

cu
Adrian

[1] http://lkml.org/lkml/2007/3/24/136 [2]
[2] x86_64 uses arch/i386/pci/common.c

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Adrian Bunk]

On Mon, Mar 26, 2007 at 07:42:51PM +0200, Marcus Better wrote:
> Adrian Bunk wrote:
> > > > Subject    : ThinkPad R60: suspend to disk broken
> 
> > Does setting CONFIG_PCI_MSI=n make any difference?
> 
> Yes, it does. The hanging resume problem went away. 

Thanks for testing.

If you enable it again, does the patch from [1] also fix it?

> (The display corruption and the instant resume were not affected.)

Not a surprise - it's currently quite common that people run into 
several distinct suspend regressions...

> Marcus

cu
Adrian

[1] http://lkml.org/lkml/2007/3/24/136 [2]
[2] x86_64 uses arch/i386/pci/common.c

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Frédéric Riss]

Le lundi 26 mars 2007 à 11:14 +0200, Thomas Gleixner a écrit :
> On Mon, 2007-03-26 at 08:45 +0200, Frédéric RISS wrote:
> > Additional data point: I just tried with -rc5 and the issue is still
> > present. The config I used for this test defines neither NO_HZ nor
> > HIGH_RES_TIMERS.
> 
> Do you have CONFIG_HPET_TIMER enabled and does the box have one ?
> If yes, can you please turn it off and retry ?

Indeed, turning off CONFIG_HPET_TIMER does fix the coming-out-of-suspend
issue. (In fact it hangs at the second suspend, but that's another ATA
problem that I think has already been reported).

Fred.

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Adrian Bunk]

On Mon, Mar 26, 2007 at 08:53:20PM +0200, Frédéric Riss wrote:

>... (In fact it hangs at the second suspend, but that's another ATA
> problem that I think has already been reported).

This sounds like the MSI problem.

Do you have CONFIG_PCI_MSI enabled?
If yes, does disabling it fix it?
If yes, does CONFIG_PCI_MSI=y with the patch from [1] work?

> Fred.

cu
Adrian

[1] http://lkml.org/lkml/2007/3/24/136

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Frederic Riss]

2007/3/26, Adrian Bunk <bunk@stusta.de>:
> On Mon, Mar 26, 2007 at 08:53:20PM +0200, Frédéric Riss wrote:
>
> >... (In fact it hangs at the second suspend, but that's another ATA
> > problem that I think has already been reported).
>
> This sounds like the MSI problem.
>
> Do you have CONFIG_PCI_MSI enabled?
> If yes, does disabling it fix it?

Yes

> If yes, does CONFIG_PCI_MSI=y with the patch from [1] work?

Yes !

Just to be 100% clear, the hang I was seeing at the second suspend is this one:

Subject    : second suspend to disk in a row results in an oops  (libata?)
References : http://lkml.org/lkml/2007/3/17/43
Submitter  : Thomas Meyer <thomas@m3y3r.de>
Status     : unknown

I'm not sure it was associated with the MSI issue yet.

Thanks a lot,
Fred

> [1] http://lkml.org/lkml/2007/3/24/136

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Adrian Bunk]

On Mon, Mar 26, 2007 at 09:39:29PM +0200, Frederic Riss wrote:
> 2007/3/26, Adrian Bunk <bunk@stusta.de>:
> >On Mon, Mar 26, 2007 at 08:53:20PM +0200, Frédéric Riss wrote:
> >
> >>... (In fact it hangs at the second suspend, but that's another ATA
> >> problem that I think has already been reported).
> >
> >This sounds like the MSI problem.
> >
> >Do you have CONFIG_PCI_MSI enabled?
> >If yes, does disabling it fix it?
> 
> Yes
> 
> >If yes, does CONFIG_PCI_MSI=y with the patch from [1] work?
> 
> Yes !

Thanks for your testing.

> Just to be 100% clear, the hang I was seeing at the second suspend is this 
> one:
> 
> Subject    : second suspend to disk in a row results in an oops  (libata?)
> References : http://lkml.org/lkml/2007/3/17/43
> Submitter  : Thomas Meyer <thomas@m3y3r.de>
> Status     : unknown
> 
> I'm not sure it was associated with the MSI issue yet.

That's what I was calling "the MSI problem".
Since my latest regression list actual cause and patch have been found.

> Thanks a lot,
> Fred
> 
> >[1] http://lkml.org/lkml/2007/3/24/136

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

RE: [3/5] 2.6.21-rc4: known regressions (v2)

[Luck, Tony]

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

Sounds rational ... in a world that wasn't dominated by PCI it would
seem to be the logical approach (since the irq code would have much
more utility independent of the PCI code).

> Tony, Len before we merge any fixes for 2.6.21-rcX I'd like to at
> least get an ack on the long term direction.

Long-term-direction-acked-by: Tony Luck <tony.luck@intel.com>

-Tony

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Rafael J. Wysocki]

On Sunday, 25 March 2007 22:37, Eric W. Biederman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> 
> > On Sunday, 25 March 2007 14:56, Eric W. Biederman wrote:
> >> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> >> 
> >> > Yes, in kernel/power/disk.c:power_down() .
> >> >
> >> > Please comment out the disable_nonboot_cpus() in there and retest (but
> > please
> >> > test the latest Linus' tree).
> >> 
> >> <rant>
> >> 
> >> Why do we even need a disable_nonboot_cpus in that path?  machine_shutdown
> >> on i386 and x86_64 should take care of that.  Further the code that computes
> >> the boot cpu is bogus (not all architectures require cpu == 0 to be
> >> the boot cpu), and disabling non boot cpus appears to be a strong
> >> x86ism, in the first place.
> >
> > Yes.
> >  
> >> If the only reason for disable_nonboot_cpus there is to avoid the
> >> WARN_ON in init_low_mappings() we should seriously consider killing
> >> it.
> >
> > We have considered it, but no one was sure that it was a good idea.
> 
> The problem with the current init_low_mappings is that it hacks the
> current page table.  If we can instead use a different page table
> the code becomes SMP safe.

What exactly is the danger here?

> I have extracted the patch that addresses this from the relocatable
> patchset and appended it for sparking ideas.  It goes a little
> farther than we need to solve this issue but the basics are there.
> 
> >> If we can wait for 2.6.22 the relocatable x86_64 patchset that 
> >> Andi has queued, has changes that kill the init_low_mapping() hack.
> >
> > I think we should kill the WARN_ON() right now, perhaps replacing it with
> > a FIXME comment.
> 
> Reasonable.
> 
> >> I'm not very comfortable with calling cpu_down in a common code path
> >> right now either.  I'm fairly certain we still don't have that
> >> correct.  So if we confine the mess that is cpu_down to #if
> >> defined(CPU_HOTPLUG) && defined(CONFIG_EXPERIMENTAL) I don't care.
> >> If we start using it everywhere I'm very nervous.
> >> migration when bringing a cpu down is strongly racy, and I don't think
> >> we actually put cpus to sleep properly either.
> >
> > I'm interested in all of the details, please.  I seriously consider dropping
> > cpu_up()/cpu_down() from the suspend code paths.
> 
> So I'm not certain if in a multiple cpu context we can avoid all of the
> issues with cpu hotplug but there is a reasonable chance so I will
> explain as best I can.
> 
> Yanking the appropriate code out of linuxbios the way a processor should stop
> itself is to send an INIT IPI to itself.  This puts a cpu into an optimized
> wait for startup IPI state where it is otherwise disabled.  This is the state
> any sane BIOS will put the cpus into before control is handed off to the kernel.
> 
> > static inline void stop_this_cpu(void)
> > {
> >         unsigned apicid;
> >         apicid = lapicid();
> > 
> >         /* Send an APIC INIT to myself */
> >         lapic_write(LAPIC_ICR2, SET_LAPIC_DEST_FIELD(apicid));
> >         lapic_write(LAPIC_ICR, LAPIC_INT_LEVELTRIG | LAPIC_INT_ASSERT | LAPIC_DM_INIT);
> >         /* Wait for the ipi send to finish */
> >         lapic_wait_icr_idle();
> > 
> >         /* Deassert the APIC INIT */
> >         lapic_write(LAPIC_ICR2, SET_LAPIC_DEST_FIELD(apicid));
> >         lapic_write(LAPIC_ICR,  LAPIC_INT_LEVELTRIG | LAPIC_DM_INIT);
> >         /* Wait for the ipi send to finish */
> >         lapic_wait_icr_idle();
> > 
> >         /* If I haven't halted spin forever */
> >         for(;;) {
> >                 hlt();
> >         }
> > }
> 
> I'm not certain what to do with the interrupt races.  But I will see
> if I can explain what I know.
> 
> <braindump>
> 
> - Most ioapics are buggy.
> - Most ioapics do not follow pci-ordering rules with respect to
>   interrupt message deliver so ensuring all in-flight irqs have
>   arrived somewhere is very hard.
> - To avoid bugs we always limit ourselves to reprogramming the ioapics
>   in the interrupt handler, and not considering an interrupt
>   successfully reprogrammed until we have received an irq in the new
>   location.
> - On x86 we have two basic interrupt handling modes.
>   o logical addressing with lowest priority delivery.
>   o physical addressing with delivery to a single cpu.
> - With logical addressing as long as the cpu is not available for
>   having an interrupt delivered to it the interrupt will be
>   never be delivered to a particular cpu.  Ideally we also update
>   the mask in the ioapic to not target that cpu.
> - With physical addressing targeting a single cpu we need to reprogram
>   the ioapics not to target that specific cpu.  This needs to happen
>   in the interrupt handler and we need to wait for the next interrupt
>   before we tear down our data structures for handling the interrupt.
> 
>   The current cpu hotplug code attempts to reprogram the ioapics from
>   process context which is just wrong.

I wasn't aware of that.

> Now as part of suspend/resume I think we should be programming the
> hardware not to generate interrupts in the first place at the actual
> hardware devices so we can likely avoid all of the code that
> reprograms interrupts while they are active.

The devices are expected (and in fact required) not to generate interrupts
and not to do any DMA transfers after they have been frozen.

> If we can use things like pci ordering rules to ensure the device will
> never fire the interrupt until resumed we should be able to disable interrupts
> synchronously.  Something that we can not safely do in the current
> cpu hotplug scenario.  Which should make the problem of doing the
> work race free much easier.

I think this is doable.

> I don't know if other architectures need to disable cpus or not before
> doing a suspend to ram or a suspend to disk.

In the suspend to disk context we must ensure that the other CPUs won't
modify memory in any way while the image is being created, so I think we
should at least make them loop in a safe place and refuse to take any
interrupts.

> I also don't know if we have any code that brings up the other cpus
> after we have been suspended.  In either the cpu hotplug paths or the
> architecture specific paths.

I'm not sure what you mean.

Anyway, currently cpu_up() is used to enable the other CPUs when we have
finished with the image (as well as during the resume).
 
> The bottom line is after the partial review of the irq handling during
> cpu shutdown a little while ago that I consider the current cpu
> hotplug code to be something that works when you are lucky.  There are
> to many hardware bugs to support the general case it tries to
> implement.

Well, we've been using it for suspending SMP boxes for quite some time now
and there haven't been any major low-level problems.  The current problems are
related to the fact that the CPU hotplug calls lots of notifiers that need not
run during the suspend or resume (or in power_down() for that matter).

> I have not reviewed the entire cpu hotplug path nor have I even tried
> suspend/resume.  But I have been all and down the boot and shutdown
> code paths so I understand the general problem.
> 
> The other part I know is that cpu numbers are assigned at the
> architectures discretion.  So unless the architecture code or the
> early boot code sets a variable remembering which was the boot cpu
> there is no reason to believe we can deduce it.

I'm not sure if we have to.  On x86_* we cannot turn the 1st CPU off anyway.

> In addition I don't know if any other architectures have anything resembling
> the x86 requirement to disable non-boot cpus.  I do know machine_shutdown
> on i386 and x86_64 performs that action (if not perfectly) so at
> least currently we should be able to do this in architecture
> specific code.
> 
> </braindump>

Thanks a lot for the info.

The patch looks a bit too complicated for a quick fix.  I think we'll need to
remove that WARN_ON() in 2.6.21 after all.

Greetings,
Rafael

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Eric W. Biederman]

"Luck, Tony" <tony.luck@intel.com> writes:

>> 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.
>
> Sounds rational ... in a world that wasn't dominated by PCI it would
> seem to be the logical approach (since the irq code would have much
> more utility independent of the PCI code).

Right.  We can even do this earlier in the pci code.  Just doing this
on demand when the device driver needs it is problematic.  As devices
drivers like to keep the requested over a pci_disable_device pci_enable_device
pair.

The big practical issue is that we will like wind up allocating an irq
number to all usable irqs on ia64.  Which means we will like need many
more irq numbers...  Although I guess if we keep it at the pci layer
we should be fairly safe.

I was afraid there was some hotplug reason for waiting until pci_enable_device
to allocate the irq numbers.

>> Tony, Len before we merge any fixes for 2.6.21-rcX I'd like to at
>> least get an ack on the long term direction.
>
> Long-term-direction-acked-by: Tony Luck <tony.luck@intel.com>

Thanks.  Then small surgery will happen now, and I will start queuing up
the major surgery patches.  Although I won't be able to do more than
compile test and code review the ia64 changes.

Eric

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Marcus Better]

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

Adrian Bunk wrote:
> > > Does setting CONFIG_PCI_MSI=n make any difference?
> >
> > Yes, it does. The hanging resume problem went away.
>
> Thanks for testing.
>
> If you enable it again, does the patch from [1] also fix it?

Yes, it appears to fix it.

Marcus

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

Re: appletouch quirk doesn't run at resume

[Thomas Meyer]

Jiri Kosina schrieb:
> On Sun, 18 Mar 2007, Thomas Meyer wrote:
>
>   
>> Appletouch is bound to the device:
>>     
>
> OK, so the quirk actually works fine ...
>   
Yes, it works fine, but...
>   
>> But the X server touchpad driver doesn't work anymore, that means i 
>> can't emulte a right click by tapping with 3 fingers on the mouse pad. 
>> after restarting x the mouse driver works again. So i think this is 
>> maybe a problem in X?
>>     
>
> ... but there is something apparently wrong either with the appletouch 
> driver or X. Could you test via evtest whether the events are properly 
> generated by the kernel? If they do, I'd say it is almost certainly X bug.
>   

It seems, that after the resume all usb devices gets removed and plug in
again (virtually!). This results in a new input device name:

before suspend and resume:

appletouch Geyser 3 inited.
input: appletouch as /class/input/input2


after resume:
Restarting tasks ... <6>usb 1-2: USB disconnect, address 3
PM: Removing info for No Bus:usbdev1.3_ep83
PM: Removing info for usb:1-2:1.0
PM: Removing info for No Bus:usbdev1.3_ep81
input: appletouch disconnected
[cut]
PM: Adding info for No Bus:usbdev1.4_ep83
PM: Adding info for usb:1-2:1.1
appletouch Geyser 3 inited.
input: appletouch as /class/input/input15

This change confuses the X synaptics driver:

Touchpad no synaptics event device found (checked 11 nodes)
Touchpad The /dev/input/event* device nodes seem to be missing
(EE) xf86OpenSerial: Cannot open device /dev/input/event2
        No such file or directory.
(WW) Touchpad: cannot open input device

And so X falls back to my second pointer device which is a UsbMouse
under /dev/input/mice

One could say that the synaptics driver rightly complains about the
missing event2 device!
So is this a bug in the X synaptics driver?

Comments are welcome.

Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"

[Len Brown]

On Monday 26 March 2007 09:52, Thomas Gleixner wrote:
> On Mon, 2007-03-26 at 12:31 +0000, Pavel Machek wrote:
> > > +	lapic_timer_c2_ok	[IA-32,APIC] trust the local apic timer in
> > > +			C2 power state.
> > > +

> I still twist my brain how to autodetect that in a safe way, which would
> make it really useful for the firmware tester.

I think the only fool-proof way to do this automatically is to
1. do a boot-time calibration vs HPET, RTC, or 8254 to make sure it starts sane.
   ideally, this boot time test would enter the deepest available C-state --
   as that would catch 99% of the failures.
2. do a _continuous_ sanity check against the same time to make sure it never gets off track.
   It has to be continuous because we apparently have no control over
   when the BIOS breaks it on some systems.  However, continuous really
   means "long term" here, because over the uptime of the system we'd
   probably notice the drift between different timers etc, so we'd
   have to reset the sanity check periodically to not get fooled by that.

If this worked, then we could delete the new DMI entry for the nx6325,
as that would get detected and disable the lapic timer use automatically.
We could also delete the check for C2 and the check for C3 to disable
the lapic timer.

-Len

Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"

[Linus Torvalds]

On Tue, 27 Mar 2007, Len Brown wrote:
> 
> I think the only fool-proof way to do this automatically is to

Why not just take the known-good CPUID signature?

Screw firmware or ACPI tables. They're going to be occasionally wrong.

If we know that "Core 2, version X" has a good local APIC timer, we use 
it. Otherwise we don't.

That's generally how we handle other APIC bugs too (the read-after-write 
thing, for example, or the differences between integrated and off-chip 
APIC's). Sometimes we check the APIC version itself, sometimes we check 
the CPUID information, and sometimes we check both ("modern_apic()").

			Linus

Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"

[Len Brown]

On Tuesday 27 March 2007 17:34, Linus Torvalds wrote:
> 
> On Tue, 27 Mar 2007, Len Brown wrote:
> > 
> > I think the only fool-proof way to do this automatically is to
> 
> Why not just take the known-good CPUID signature?
>
> Screw firmware or ACPI tables. They're going to be occasionally wrong.
> 
> If we know that "Core 2, version X" has a good local APIC timer, we use 
> it. Otherwise we don't.
> 
> That's generally how we handle other APIC bugs too (the read-after-write 
> thing, for example, or the differences between integrated and off-chip 
> APIC's). Sometimes we check the APIC version itself, sometimes we check 
> the CPUID information, and sometimes we check both ("modern_apic()").

Yep, this is what we tried to do last week.
It failed, and the patch was reverted.

I agree, the BIOS vendor can lie with ACPI tables.
In particular, they can map any hardware C-state
to any ACPI C-state. Our expectation that they
would not map hardware C3 to ACPI C2
appears at this point to have been invalid.

So, speaking for Intel parts, every single one that supports
HW C3 from the beginning of history through today has a broken
LAPIC timer.  (and a few listed in that patch are known to
be broken in HW C2)   If we can't guarantee that the BIOS vendor
will not map that broken HW C3 to ACPI C2 (or even C1 via SMM)
then we have to not use the LAPIC timer except for systems with
a "known-good" signature = "part supports only C1".

If we really care about using the LAPIC timer on systems with deeper
than C1 support, the only alternative seems to be to test
if it actually works or not at boot and run-time.
Otherwise, we wait for future hardware with guaranteed
not to break under any (BIOS) conditions ships, and check for that.

Based on what I read of the HP nx6325 where the LAPIC timer
is breaking C1, AMD is in the same boat.

-Len

Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"

[Len Brown]

On Tuesday 27 March 2007 18:16, Len Brown wrote:
> On Tuesday 27 March 2007 17:34, Linus Torvalds wrote:
> > 
> > On Tue, 27 Mar 2007, Len Brown wrote:
> > > 
> > > I think the only fool-proof way to do this automatically is to
> > 
> > Why not just take the known-good CPUID signature?
> >
> > Screw firmware or ACPI tables. They're going to be occasionally wrong.
> > 
> > If we know that "Core 2, version X" has a good local APIC timer, we use 
> > it. Otherwise we don't.
> > 
> > That's generally how we handle other APIC bugs too (the read-after-write 
> > thing, for example, or the differences between integrated and off-chip 
> > APIC's). Sometimes we check the APIC version itself, sometimes we check 
> > the CPUID information, and sometimes we check both ("modern_apic()").
> 
> Yep, this is what we tried to do last week.
> It failed, and the patch was reverted.
> 
> I agree, the BIOS vendor can lie with ACPI tables.
> In particular, they can map any hardware C-state
> to any ACPI C-state. Our expectation that they
> would not map hardware C3 to ACPI C2
> appears at this point to have been invalid.
> 
> So, speaking for Intel parts, every single one that supports
> HW C3 from the beginning of history through today has a broken
> LAPIC timer.  (and a few listed in that patch are known to
> be broken in HW C2)   If we can't guarantee that the BIOS vendor
> will not map that broken HW C3 to ACPI C2 (or even C1 via SMM)
> then we have to not use the LAPIC timer except for systems with
> a "known-good" signature = "part supports only C1".

On an Intel processor, it seems that the safe and simple route
is if the system exports C2 or deeper, don't use the LAPIC timer.
(which is what 2.6.21-rc5 is doing as of this moment)
We may be able to white-list some systems over time.

> If we really care about using the LAPIC timer on systems with deeper
> than C1 support, the only alternative seems to be to test
> if it actually works or not at boot and run-time.
> Otherwise, we wait for future hardware with guaranteed
> not to break under any (BIOS) conditions ships, and check for that.
> 
> Based on what I read of the HP nx6325 where the LAPIC timer
> is breaking C1, AMD is in the same boat.

The nx6325 (Turion 64 X2) exports only C1.
I'm not sure how the conclusion was drawn that it has
a broken lapic timer as reflected in the "nolapic_timer" patch:

+               /*
+                * BIOS exports only C1 state, but uses deeper power
+                * modes behind the kernels back.
+                */
+                 .callback = lapic_check_broken_bios,
+                 .ident = "HP nx6325",
+                 .matches = {
+                       DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq nx6325"),
+                 },
+        },

But if this is true, then I don't know how to determine on
an AMD system if the LAPIC timer is guaranteed to work --
even for systems with just C1.

Jordan, William,
can you clarify?

thanks,
-Len

Re: [3/6] 2.6.21-rc4: known regressions

[Thomas Gleixner]

On Tue, 2007-03-27 at 01:46 +0800, Jeff Chua wrote:
> On 3/27/07, Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> > > It's related. I tested without CONFIG_HPET_TIMER, and now my X60 can
> > > suspend and resume from RAM (s2ram). Even better, it works
> > > with/without CONFIG_NO_HZ.
> >
> > Does the patch below fix the HPET_TIMER=y case ?
> 
> Thomas, I tried, but it didn't help. Upon resume from ram, "date"
> still didn't advance.

Can you please issue a SysRq-Q in this situation and provide the dmesg
output ?

Thanks,

	tglx

Re: appletouch quirk doesn't run at resume

[Jiri Kosina]

On Tue, 27 Mar 2007, Thomas Meyer wrote:

> It seems, that after the resume all usb devices gets removed and plug in 
> again (virtually!). This results in a new input device name:

Yes, this is what actually happens. JFYI see current thread on lkml which 
is a bit realted - http://lkml.org/lkml/2007/3/27/149 if interested.

> This change confuses the X synaptics driver:
> Touchpad no synaptics event device found (checked 11 nodes)
> Touchpad The /dev/input/event* device nodes seem to be missing
> (EE) xf86OpenSerial: Cannot open device /dev/input/event2
>         No such file or directory.
> (WW) Touchpad: cannot open input device
> One could say that the synaptics driver rightly complains about the 
> missing event2 device! So is this a bug in the X synaptics driver?

You can of course work this around by adding an udev rule such as

SUBSYSTEM=="input",KERNEL=="event*",SYSFS{name}=="appletouch",SYMLINK+="input/appletouchpad"

and the let Xorg use /dev/input/appletouchpad, which will always be a 
symlink to the correct device.

-- 
Jiri Kosina

Re: appletouch quirk doesn't run at resume

[Dmitry Torokhov]

On 3/28/07, Jiri Kosina <jikos@jikos.cz> wrote:
> On Tue, 27 Mar 2007, Thomas Meyer wrote:
>
> > It seems, that after the resume all usb devices gets removed and plug in
> > again (virtually!). This results in a new input device name:
>
> Yes, this is what actually happens. JFYI see current thread on lkml which
> is a bit realted - http://lkml.org/lkml/2007/3/27/149 if interested.
>
> > This change confuses the X synaptics driver:
> > Touchpad no synaptics event device found (checked 11 nodes)
> > Touchpad The /dev/input/event* device nodes seem to be missing
> > (EE) xf86OpenSerial: Cannot open device /dev/input/event2
> >         No such file or directory.
> > (WW) Touchpad: cannot open input device
> > One could say that the synaptics driver rightly complains about the
> > missing event2 device! So is this a bug in the X synaptics driver?
>
> You can of course work this around by adding an udev rule such as
>
> SUBSYSTEM=="input",KERNEL=="event*",SYSFS{name}=="appletouch",SYMLINK+="input/appletouchpad"
>
> and the let Xorg use /dev/input/appletouchpad, which will always be a
> symlink to the correct device.
>

I am not sure if this would help... According to the excerpt from X
log synaptics driver attempted to scan evdev devices and locate the
touchpad. However if this scan happen before udev had a chance to
process the event and create new /dev/input/eventX device node it will
fail.

I wonder if we should adjust the X driver to spin for a couple of
seconds in EventAutoDevProbe if the touchpad was already seen once...
Peter?

-- 
Dmitry

Re: [3/6] 2.6.21-rc4: known regressions

[Maxim]

On Wednesday 28 March 2007 09:04:28 Thomas Gleixner wrote:
> On Tue, 2007-03-27 at 01:46 +0800, Jeff Chua wrote:
> > On 3/27/07, Thomas Gleixner <tglx@linutronix.de> wrote:
> > 
> > > > It's related. I tested without CONFIG_HPET_TIMER, and now my X60 can
> > > > suspend and resume from RAM (s2ram). Even better, it works
> > > > with/without CONFIG_NO_HZ.
> > >
> > > Does the patch below fix the HPET_TIMER=y case ?
> > 
> > Thomas, I tried, but it didn't help. Upon resume from ram, "date"
> > still didn't advance.
> 
> Can you please issue a SysRq-Q in this situation and provide the dmesg
> output ?
> 
> Thanks,
> 
> 	tglx
> 
> 
> -
> 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/
> 

Hi,
	I almost sure Iknow why this happens,
		The problem is that both hpet clock source and hpet clockevents doesn't have a suspend/resume function
		On resume we should enable the main counter _and_ enable legacy replacement mode,
		On my system main counter in enabled, by I think by bios, but legacy replacement mode is not, so if
		a system doesn't use lapic as a tick source, but use hpet+broadcast, it will hang for sure on resume, and i tested it

		The patch below is a temporally fix, until clock-events and clocksources will get proper suspend/resume hooks:

		Regards,
			Maxim Levitsky

---

Add suspend/resume for HPET
Signed-off-by: Maxim Levitsky <maximlevisky@gmail.com>

---

diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
index 0fd9fba..a1ec79e 100644
--- a/arch/i386/kernel/hpet.c
+++ b/arch/i386/kernel/hpet.c
@@ -152,6 +152,16 @@ static void hpet_set_mode(enum clock_event_mode mode,
 	unsigned long cfg, cmp, now;
 	uint64_t delta;
 
+
+	if ( mode != CLOCK_EVT_MODE_UNUSED && mode != CLOCK_EVT_MODE_SHUTDOWN)
+	{
+		unsigned long cfg = hpet_readl(HPET_CFG);
+		cfg |= HPET_CFG_ENABLE | HPET_CFG_LEGACY;
+		hpet_writel(cfg, HPET_CFG);
+		
+	}
+		
+
 	switch(mode) {
 	case CLOCK_EVT_MODE_PERIODIC:
 		delta = ((uint64_t)(NSEC_PER_SEC/HZ)) * hpet_clockevent.mult;

Re: [3/6] 2.6.21-rc4: known regressions

[Ingo Molnar]

* Maxim <maximlevitsky@gmail.com> wrote:

> I almost sure I know why this happens,

cool! Your patch is a definite improvement on my t60 (where 
suspend/resume never worked with hpet enabled). But it does not fix 
everything - for example the timings are way off after resume. Thomas?

	Ingo

Re: [3/6] 2.6.21-rc4: known regressions

[Ingo Molnar]

* Maxim <maximlevitsky@gmail.com> wrote:

> I almost sure I know why this happens,

cool! Your patch is a definite improvement on my t60 (where 
suspend/resume never worked with hpet enabled). But it does not fix 
everything - for example the timings are way off after resume. Thomas?

	Ingo

Re: [3/6] 2.6.21-rc4: known regressions

[Maxim]

On Wednesday 28 March 2007 16:41:48 Ingo Molnar wrote:
> 
> * Maxim <maximlevitsky@gmail.com> wrote:
> 
> > I almost sure I know why this happens,
> 
> cool! Your patch is a definite improvement on my t60 (where 
> suspend/resume never worked with hpet enabled). But it does not fix 
> everything - for example the timings are way off after resume. Thomas?
> 
> 	Ingo
> 

The problem is that HPET  consists of two parts:
	one is a main counter and second is a a timers.

	To enable main counter one must set HPET_CFG_ENABLE.
	It is set only on boot, and not on resume now.

	But on my system I think bios re-enables it.

	Secondary to enable HPET to act as a timer on IRQ0 and to make it replace RTC IRQ8 one must set
	HPET_CFG_LEGACY

	This bit is definitely not set on resume, so on my system I get a hang if I use HPET as clockevents device,
	and on other system where bios doesn't reenable HPET, then even if HPET is used as timing device 
	'date won't advance'

	But I set those bits only in initialization of HPET clockevents device, and I set always, when it is turned on,
	It is not that good,but works.

	Now I don't have a clue how to set those bits if only HPET is used as clock source because now clocksources
	don't have _any_ resume hook.

	The timing problem you mention I think isd connected to the fact that HPET is not enabled instantly after resume, but after some time when clockevents
	core calls HPET to enable event timer.

	Best regards,
		Maxim Levitsky

Re: [3/6] 2.6.21-rc4: known regressions

[Linus Torvalds]

On Wed, 28 Mar 2007, Maxim wrote:
> 
> 	Now I don't have a clue how to set those bits if only HPET is used as clock source because now clocksources
> 	don't have _any_ resume hook.

One thing that drives me wild about that "clocksource resume" thing is 
that it seems to think that clocksources are somehow different from any 
other system devices..

Why isn't the HPET considered a "device", and has it's own *device* 
"suspend" and "resume"? Why do we seem to think that only "set_mode()" 
etc should wake up clock sources?

It's a *device*, dammit. It should save and resume like one (probably as a 
system device). The "set_mode()" etc stuff is at a completely different 
(higher) conceptual level.

Thomas? It does seem like Maxim has hit the nail on the head (at least 
partly) on the HPET timer resume problems..

		Linus

Re: [3/6] 2.6.21-rc4: known regressions

[Linus Torvalds]

On Wed, 28 Mar 2007, Maxim wrote:
> 
> 	Now I don't have a clue how to set those bits if only HPET is used as clock source because now clocksources
> 	don't have _any_ resume hook.

One thing that drives me wild about that "clocksource resume" thing is 
that it seems to think that clocksources are somehow different from any 
other system devices..

Why isn't the HPET considered a "device", and has it's own *device* 
"suspend" and "resume"? Why do we seem to think that only "set_mode()" 
etc should wake up clock sources?

It's a *device*, dammit. It should save and resume like one (probably as a 
system device). The "set_mode()" etc stuff is at a completely different 
(higher) conceptual level.

Thomas? It does seem like Maxim has hit the nail on the head (at least 
partly) on the HPET timer resume problems..

		Linus

Re: appletouch quirk doesn't run at resume

[Thomas Meyer]

Dmitry Torokhov schrieb:
> On 3/28/07, Jiri Kosina <jikos@jikos.cz> wrote:
>> On Tue, 27 Mar 2007, Thomas Meyer wrote:
>>
>> > It seems, that after the resume all usb devices gets removed and
>> plug in
>> > again (virtually!). This results in a new input device name:
>>
>> Yes, this is what actually happens. JFYI see current thread on lkml
>> which
>> is a bit realted - http://lkml.org/lkml/2007/3/27/149 if interested.
>>
>> > This change confuses the X synaptics driver:
>> > Touchpad no synaptics event device found (checked 11 nodes)
>> > Touchpad The /dev/input/event* device nodes seem to be missing
>> > (EE) xf86OpenSerial: Cannot open device /dev/input/event2
>> >         No such file or directory.
>> > (WW) Touchpad: cannot open input device
>> > One could say that the synaptics driver rightly complains about the
>> > missing event2 device! So is this a bug in the X synaptics driver?
>>
>> You can of course work this around by adding an udev rule such as
>>
>> SUBSYSTEM=="input",KERNEL=="event*",SYSFS{name}=="appletouch",SYMLINK+="input/appletouchpad"
>>
>>
>> and the let Xorg use /dev/input/appletouchpad, which will always be a
>> symlink to the correct device.
>>
This was my first idea, too. But then i found this entry in the
Changelog of the synaptics driver:

- In the DeviceOn() function, if opening the device node fails, try to
  auto-detect the correct event device again. This fixes some problems
  which occur after a suspend/resume cycle or after rmmod/insmod-ing
  the psmouse kernel driver.

>
> I am not sure if this would help... According to the excerpt from X
> log synaptics driver attempted to scan evdev devices and locate the
> touchpad. However if this scan happen before udev had a chance to
> process the event and create new /dev/input/eventX device node it will
> fail.
Okay. This strengthens above statement. And udev is too slow to create
the devices, while the driver already scanned the directory.
>
> I wonder if we should adjust the X driver to spin for a couple of
> seconds in EventAutoDevProbe if the touchpad was already seen once...
> Peter?
>

Re: appletouch quirk doesn't run at resume

[Jiri Kosina]

On Wed, 28 Mar 2007, Thomas Meyer wrote:

> > I am not sure if this would help... According to the excerpt from X
> > log synaptics driver attempted to scan evdev devices and locate the
> > touchpad. However if this scan happen before udev had a chance to
> > process the event and create new /dev/input/eventX device node it will
> > fail.
> Okay. This strengthens above statement. And udev is too slow to create
> the devices, while the driver already scanned the directory.
> > I wonder if we should adjust the X driver to spin for a couple of 
> > seconds in EventAutoDevProbe if the touchpad was already seen once... 
> > Peter?

Yes, it looks like this is the root cause.

However I must admit that I don't like this behavior too much. We 
shouldn't rely on drivers individual userland to wait for a reasonable 
time before the udev settles down. This is not a nice API to provide. Will 
try to think of some solution which would have reasonable 
nastiness/functionality ratio.

-- 
Jiri Kosina

Re: appletouch quirk doesn't run at resume

[Dmitry Torokhov]

On 3/28/07, Jiri Kosina <jikos@jikos.cz> wrote:
> On Wed, 28 Mar 2007, Thomas Meyer wrote:
>
> > > I am not sure if this would help... According to the excerpt from X
> > > log synaptics driver attempted to scan evdev devices and locate the
> > > touchpad. However if this scan happen before udev had a chance to
> > > process the event and create new /dev/input/eventX device node it will
> > > fail.
> > Okay. This strengthens above statement. And udev is too slow to create
> > the devices, while the driver already scanned the directory.
> > > I wonder if we should adjust the X driver to spin for a couple of
> > > seconds in EventAutoDevProbe if the touchpad was already seen once...
> > > Peter?
>
> Yes, it looks like this is the root cause.
>
> However I must admit that I don't like this behavior too much. We
> shouldn't rely on drivers individual userland to wait for a reasonable
> time before the udev settles down. This is not a nice API to provide. Will
> try to think of some solution which would have reasonable
> nastiness/functionality ratio.
>

The proper fix would be teach X to recognize hotplug events. I've
heard  they are working on it.

-- 
Dmitry

Re: [3/6] 2.6.21-rc4: known regressions

[Michael S. Tsirkin]

> Subject    : first disk access after resume takes several minutes
>              ('date' does not advance after resume from RAM, CONFIG_NO_HZ=n)
> References : http://lkml.org/lkml/2007/3/8/117
>              http://lkml.org/lkml/2007/3/25/20
> Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>

...

> Subject    : after resume: X hangs after drawing a couple of windows
> References : http://lkml.org/lkml/2007/3/8/117
> Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
> Status     : unknown

...

> > > > From: Jeff Chua <jeff.chua.linux@gmail.com>
> > > > > It's related. I tested without CONFIG_HPET_TIMER, and now my X60 can
> > > > > suspend and resume from RAM (s2ram). Even better, it works
> > > > > with/without CONFIG_NO_HZ.
> 
> Quoting Maxim <maximlevitsky@gmail.com>:
> 
> Hi,
> 	I almost sure Iknow why this happens,
> 			The problem is that both hpet clock source
> 	and hpet clockevents doesn't have a suspend/resume function
> 	On resume we should enable the main counter _and_ enable
> 	legacy replacement mode, On my system main counter in
> 	enabled, by I think by bios, but legacy replacement mode is
> 	not, so if a system doesn't use lapic as a tick source, but
> 	use hpet+broadcast, it will hang for sure on resume, and i
> 	tested it
> 	
> 			The patch below is a temporally fix, until
> 	clock-events and clocksources will get proper suspend/resume
> 	hooks:
> 
> 		Regards,
> 			Maxim Levitsky

Bingo!

The patch below fixes the two problems (listed above) with
resume from RAM that I have observed on my T60 with
2.6.21-rc5: with this patch applied, and with CONFIG_NO_HZ
unset, date advances correctly, X functions properly and
there is no delay on first disk access.

Thanks very much.

---
> Add suspend/resume for HPET
> Signed-off-by: Maxim Levitsky <maximlevisky@gmail.com>

Maxim, do you plan to send this upstream?

Acked-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>

---

diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
index 0fd9fba..a1ec79e 100644
--- a/arch/i386/kernel/hpet.c
+++ b/arch/i386/kernel/hpet.c
@@ -152,6 +152,16 @@ static void hpet_set_mode(enum clock_event_mode mode,
 	unsigned long cfg, cmp, now;
 	uint64_t delta;
 
+
+	if ( mode != CLOCK_EVT_MODE_UNUSED && mode != CLOCK_EVT_MODE_SHUTDOWN)
+	{
+		unsigned long cfg = hpet_readl(HPET_CFG);
+		cfg |= HPET_CFG_ENABLE | HPET_CFG_LEGACY;
+		hpet_writel(cfg, HPET_CFG);
+		
+	}
+		
+
 	switch(mode) {
 	case CLOCK_EVT_MODE_PERIODIC:
 		delta = ((uint64_t)(NSEC_PER_SEC/HZ)) * hpet_clockevent.mult;

-- 
MST

Re: [3/6] 2.6.21-rc4: known regressions

[Ingo Molnar]

* Michael S. Tsirkin <mst@dev.mellanox.co.il> wrote:

> Bingo!
> 
> The patch below fixes the two problems (listed above) with resume from 
> RAM that I have observed on my T60 with 2.6.21-rc5: with this patch 
> applied, and with CONFIG_NO_HZ unset, date advances correctly, X 
> functions properly and there is no delay on first disk access.
> 
> Thanks very much.
[...]
> 
> Maxim, do you plan to send this upstream?

we'll fix this the right way tomorrow, by adding a proper suspend/resume 
sysdev handler - the lapic clockevents driver already has that. Maxim 
definitely deserves alot of kudos for having found this bug!

	Ingo

Re: [3/6] 2.6.21-rc4: known regressions

[Ingo Molnar]

* Michael S. Tsirkin <mst@dev.mellanox.co.il> wrote:

> Bingo!
> 
> The patch below fixes the two problems (listed above) with resume from 
> RAM that I have observed on my T60 with 2.6.21-rc5: with this patch 
> applied, and with CONFIG_NO_HZ unset, date advances correctly, X 
> functions properly and there is no delay on first disk access.
> 
> Thanks very much.
[...]
> 
> Maxim, do you plan to send this upstream?

we'll fix this the right way tomorrow, by adding a proper suspend/resume 
sysdev handler - the lapic clockevents driver already has that. Maxim 
definitely deserves alot of kudos for having found this bug!

	Ingo

Re: [3/6] 2.6.21-rc4: known regressions

[Randy Dunlap]

On Wed, 28 Mar 2007 20:04:57 +0200 Michael S. Tsirkin wrote:

> > Subject    : first disk access after resume takes several minutes
> >              ('date' does not advance after resume from RAM, CONFIG_NO_HZ=n)
> > References : http://lkml.org/lkml/2007/3/8/117
> >              http://lkml.org/lkml/2007/3/25/20
> > Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
> 
> ...
> 
> > Subject    : after resume: X hangs after drawing a couple of windows
> > References : http://lkml.org/lkml/2007/3/8/117
> > Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
> > Status     : unknown
> 
> ...
> 
> > > > > From: Jeff Chua <jeff.chua.linux@gmail.com>
> > > > > > It's related. I tested without CONFIG_HPET_TIMER, and now my X60 can
> > > > > > suspend and resume from RAM (s2ram). Even better, it works
> > > > > > with/without CONFIG_NO_HZ.
> > 
> > Quoting Maxim <maximlevitsky@gmail.com>:
> > 
> > Hi,
> > 	I almost sure Iknow why this happens,
> > 			The problem is that both hpet clock source
> > 	and hpet clockevents doesn't have a suspend/resume function
> > 	On resume we should enable the main counter _and_ enable
> > 	legacy replacement mode, On my system main counter in
> > 	enabled, by I think by bios, but legacy replacement mode is
> > 	not, so if a system doesn't use lapic as a tick source, but
> > 	use hpet+broadcast, it will hang for sure on resume, and i
> > 	tested it
> > 	
> > 			The patch below is a temporally fix, until
> > 	clock-events and clocksources will get proper suspend/resume
> > 	hooks:
> > 
> > 		Regards,
> > 			Maxim Levitsky
> 
> Bingo!
> 
> The patch below fixes the two problems (listed above) with
> resume from RAM that I have observed on my T60 with
> 2.6.21-rc5: with this patch applied, and with CONFIG_NO_HZ
> unset, date advances correctly, X functions properly and
> there is no delay on first disk access.
> 
> Thanks very much.
> 
> ---
> > Add suspend/resume for HPET
> > Signed-off-by: Maxim Levitsky <maximlevisky@gmail.com>
> 
> Maxim, do you plan to send this upstream?

with whitespace fixes, please...


> Acked-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
> 
> ---
> 
> diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
> index 0fd9fba..a1ec79e 100644
> --- a/arch/i386/kernel/hpet.c
> +++ b/arch/i386/kernel/hpet.c
> @@ -152,6 +152,16 @@ static void hpet_set_mode(enum clock_event_mode mode,
>  	unsigned long cfg, cmp, now;
>  	uint64_t delta;
>  
> +
> +	if ( mode != CLOCK_EVT_MODE_UNUSED && mode != CLOCK_EVT_MODE_SHUTDOWN)
> +	{

	if (mode != CLOCK_EVT_MODE_UNUSED && mode != CLOCK_EVT_MODE_SHUTDOWN) {

> +		unsigned long cfg = hpet_readl(HPET_CFG);
> +		cfg |= HPET_CFG_ENABLE | HPET_CFG_LEGACY;
> +		hpet_writel(cfg, HPET_CFG);
> +		

delete above line.

> +	}
> +		
> +
>  	switch(mode) {
>  	case CLOCK_EVT_MODE_PERIODIC:
>  		delta = ((uint64_t)(NSEC_PER_SEC/HZ)) * hpet_clockevent.mult;


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [3/6] 2.6.21-rc4: known regressions

[Randy Dunlap]

On Wed, 28 Mar 2007 20:04:57 +0200 Michael S. Tsirkin wrote:

> > Subject    : first disk access after resume takes several minutes
> >              ('date' does not advance after resume from RAM, CONFIG_NO_HZ=n)
> > References : http://lkml.org/lkml/2007/3/8/117
> >              http://lkml.org/lkml/2007/3/25/20
> > Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
> 
> ...
> 
> > Subject    : after resume: X hangs after drawing a couple of windows
> > References : http://lkml.org/lkml/2007/3/8/117
> > Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
> > Status     : unknown
> 
> ...
> 
> > > > > From: Jeff Chua <jeff.chua.linux@gmail.com>
> > > > > > It's related. I tested without CONFIG_HPET_TIMER, and now my X60 can
> > > > > > suspend and resume from RAM (s2ram). Even better, it works
> > > > > > with/without CONFIG_NO_HZ.
> > 
> > Quoting Maxim <maximlevitsky@gmail.com>:
> > 
> > Hi,
> > 	I almost sure Iknow why this happens,
> > 			The problem is that both hpet clock source
> > 	and hpet clockevents doesn't have a suspend/resume function
> > 	On resume we should enable the main counter _and_ enable
> > 	legacy replacement mode, On my system main counter in
> > 	enabled, by I think by bios, but legacy replacement mode is
> > 	not, so if a system doesn't use lapic as a tick source, but
> > 	use hpet+broadcast, it will hang for sure on resume, and i
> > 	tested it
> > 	
> > 			The patch below is a temporally fix, until
> > 	clock-events and clocksources will get proper suspend/resume
> > 	hooks:
> > 
> > 		Regards,
> > 			Maxim Levitsky
> 
> Bingo!
> 
> The patch below fixes the two problems (listed above) with
> resume from RAM that I have observed on my T60 with
> 2.6.21-rc5: with this patch applied, and with CONFIG_NO_HZ
> unset, date advances correctly, X functions properly and
> there is no delay on first disk access.
> 
> Thanks very much.
> 
> ---
> > Add suspend/resume for HPET
> > Signed-off-by: Maxim Levitsky <maximlevisky@gmail.com>
> 
> Maxim, do you plan to send this upstream?

with whitespace fixes, please...


> Acked-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
> 
> ---
> 
> diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
> index 0fd9fba..a1ec79e 100644
> --- a/arch/i386/kernel/hpet.c
> +++ b/arch/i386/kernel/hpet.c
> @@ -152,6 +152,16 @@ static void hpet_set_mode(enum clock_event_mode mode,
>  	unsigned long cfg, cmp, now;
>  	uint64_t delta;
>  
> +
> +	if ( mode != CLOCK_EVT_MODE_UNUSED && mode != CLOCK_EVT_MODE_SHUTDOWN)
> +	{

	if (mode != CLOCK_EVT_MODE_UNUSED && mode != CLOCK_EVT_MODE_SHUTDOWN) {

> +		unsigned long cfg = hpet_readl(HPET_CFG);
> +		cfg |= HPET_CFG_ENABLE | HPET_CFG_LEGACY;
> +		hpet_writel(cfg, HPET_CFG);
> +		

delete above line.

> +	}
> +		
> +
>  	switch(mode) {
>  	case CLOCK_EVT_MODE_PERIODIC:
>  		delta = ((uint64_t)(NSEC_PER_SEC/HZ)) * hpet_clockevent.mult;


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [3/6] 2.6.21-rc4: known regressions

[David Brownell]

On Wednesday 28 March 2007 9:38 am, Linus Torvalds wrote:

> It's a *device*, dammit. It should save and resume like one (probably as a 
> system device). The "set_mode()" etc stuff is at a completely different 
> (higher) conceptual level.

Agreed, except about "probably as a system device".

Last I checked, there was no good reason to use sysdev suspend()/resume()
rather than platform_device suspend_late()/early_resume().  Which more
or less means no good reason to use sysdev in new code...


Also, making HPET use the legacy mode seems like a step backwards.

- Dave

Re: [linux-pm] [3/6] 2.6.21-rc4: known regressions

[David Brownell]

On Wednesday 28 March 2007 9:38 am, Linus Torvalds wrote:

> It's a *device*, dammit. It should save and resume like one (probably as a 
> system device). The "set_mode()" etc stuff is at a completely different 
> (higher) conceptual level.

Agreed, except about "probably as a system device".

Last I checked, there was no good reason to use sysdev suspend()/resume()
rather than platform_device suspend_late()/early_resume().  Which more
or less means no good reason to use sysdev in new code...


Also, making HPET use the legacy mode seems like a step backwards.

- Dave

Re: [linux-pm] [3/6] 2.6.21-rc4: known regressions

[Maxim]

On Wednesday 28 March 2007 21:38:55 David Brownell wrote:
> On Wednesday 28 March 2007 9:38 am, Linus Torvalds wrote:
> 
> > It's a *device*, dammit. It should save and resume like one (probably as a 
> > system device). The "set_mode()" etc stuff is at a completely different 
> > (higher) conceptual level.
> 
> Agreed, except about "probably as a system device".
> 
> Last I checked, there was no good reason to use sysdev suspend()/resume()
> rather than platform_device suspend_late()/early_resume().  Which more
> or less means no good reason to use sysdev in new code...
> 
> 
> Also, making HPET use the legacy mode seems like a step backwards.
> 
> - Dave
> 


Hi,
	It is not 'legacy' mode,
It is a legacy replacement mode.
It this mode HPET takes over IRQ0 and IRQ 8 and provides this way replacement for PIT and RTC periodic function

	Best regards,
		Maxim Levitsky

Re: [3/6] 2.6.21-rc4: known regressions

[Linus Torvalds]

On Wed, 28 Mar 2007, David Brownell wrote:
>
> On Wednesday 28 March 2007 9:38 am, Linus Torvalds wrote:
> 
> > It's a *device*, dammit. It should save and resume like one (probably as a 
> > system device). The "set_mode()" etc stuff is at a completely different 
> > (higher) conceptual level.
> 
> Agreed, except about "probably as a system device".
> 
> Last I checked, there was no good reason to use sysdev suspend()/resume()
> rather than platform_device suspend_late()/early_resume().  Which more
> or less means no good reason to use sysdev in new code...

I won't disagree - it might well be much nicer to just show it in the 
"real" device tree. I'm not 100% sure where in the tree it would go, 
though. It should probably be "inside" the root entry, before any of the 
PCI buses. It's generally what we've used those "system device" things 
for, but I agree that it would be better to just make system devices show 
up early on the regular device list than it is to have them be special 
cases.

Bit I think that's a separate (and fairly small) issue compared to the 
"don't use the clocksource infrastructure as a make-believe suspend/resume 
mechanism" problem that Maxim's patch had.

(Maxim, don't take that the wrong way - I think your analysis and patch 
were great, I just think another organization would be better)

> Also, making HPET use the legacy mode seems like a step backwards.

I don't think that's actually "legacy" in any sense but the interrupt 
delivery, where the "legacy mode" bit is not so much that the HPET itself 
is "legacy" but that it *replaces* legacy devices.

But I may have misunderstood the thing. I'm an old fart, so I know the old 
timers much better than I know the new ones ;). Somebody feel free to hit 
me with the clue-2x4.

			Linus

Re: [linux-pm] [3/6] 2.6.21-rc4: known regressions

[Linus Torvalds]

On Wed, 28 Mar 2007, David Brownell wrote:
>
> On Wednesday 28 March 2007 9:38 am, Linus Torvalds wrote:
> 
> > It's a *device*, dammit. It should save and resume like one (probably as a 
> > system device). The "set_mode()" etc stuff is at a completely different 
> > (higher) conceptual level.
> 
> Agreed, except about "probably as a system device".
> 
> Last I checked, there was no good reason to use sysdev suspend()/resume()
> rather than platform_device suspend_late()/early_resume().  Which more
> or less means no good reason to use sysdev in new code...

I won't disagree - it might well be much nicer to just show it in the 
"real" device tree. I'm not 100% sure where in the tree it would go, 
though. It should probably be "inside" the root entry, before any of the 
PCI buses. It's generally what we've used those "system device" things 
for, but I agree that it would be better to just make system devices show 
up early on the regular device list than it is to have them be special 
cases.

Bit I think that's a separate (and fairly small) issue compared to the 
"don't use the clocksource infrastructure as a make-believe suspend/resume 
mechanism" problem that Maxim's patch had.

(Maxim, don't take that the wrong way - I think your analysis and patch 
were great, I just think another organization would be better)

> Also, making HPET use the legacy mode seems like a step backwards.

I don't think that's actually "legacy" in any sense but the interrupt 
delivery, where the "legacy mode" bit is not so much that the HPET itself 
is "legacy" but that it *replaces* legacy devices.

But I may have misunderstood the thing. I'm an old fart, so I know the old 
timers much better than I know the new ones ;). Somebody feel free to hit 
me with the clue-2x4.

			Linus

Re: [linux-pm] [3/6] 2.6.21-rc4: known regressions

[David Brownell]

On Wednesday 28 March 2007 1:19 pm, Maxim wrote:
> On Wednesday 28 March 2007 21:38:55 David Brownell wrote:

> > 
> > Also, making HPET use the legacy mode seems like a step backwards.

> 	It is not 'legacy' mode,
> It is a legacy replacement mode.

Typo, sorry.


> It this mode HPET takes over IRQ0 and IRQ 8 and provides this way
> replacement for PIT and RTC periodic function 

It's that RTC periodic thing that bothers me, I don't mind about
the PIT.  Remember that IRQ8 is also used for other RTC functions.

Now, if there were a way to tell rtc-cmos that HPET is active,
and arrange some kind of handshake ... that would be different.

- Dave

Re: [linux-pm] [3/6] 2.6.21-rc4: known regressions

[David Brownell]

On Wednesday 28 March 2007 1:42 pm, Linus Torvalds wrote:
> 
> I won't disagree - it might well be much nicer to just show it in the 
> "real" device tree. I'm not 100% sure where in the tree it would go, 
> though. It should probably be "inside" the root entry, before any of the 
> PCI buses. 

Mixing "inside" and "before" is a small linguistic clue about
one of the issues with driver model PM.  Off topic here; and
in terms of suspend/resume callback sequencing that answer
shouldn't matter much for HPET (as I understand things).


> It's generally what we've used those "system device" things  
> for, but I agree that it would be better to just make system devices show 
> up early on the regular device list than it is to have them be special 
> cases.

Yes -- where "platform_device" is a regular Joe-Sixpack kind of
device, but "sysdev" is a special case.


> Bit I think that's a separate (and fairly small) issue compared to the 
> "don't use the clocksource infrastructure as a make-believe suspend/resume 
> mechanism" problem that Maxim's patch had.

Agreed -- although isn't it the "clockevent" change which is at issue?

A "clockevent" thingie wraps various kinds of timer IRQs; the clocksource
is conceptually just a free run counter.  Clocksources have been around
for a while, with no particular problems.

It's clockevent sources have been the problem with dynamic tick solutions
all along, since they mask such chaos inside x86 hardware and interact
with so many different parts of the kernel.  ;)

- Dave


> (Maxim, don't take that the wrong way - I think your analysis and patch 
> were great, I just think another organization would be better)

Re: [linux-pm] [3/6] 2.6.21-rc4: known regressions

[Maxim]

On Wednesday 28 March 2007 22:59:26 David Brownell wrote:
> On Wednesday 28 March 2007 1:19 pm, Maxim wrote:
> > On Wednesday 28 March 2007 21:38:55 David Brownell wrote:
> 
> > > 
> > > Also, making HPET use the legacy mode seems like a step backwards.
> 
> > 	It is not 'legacy' mode,
> > It is a legacy replacement mode.
> 
> Typo, sorry.
> 
> 
> > It this mode HPET takes over IRQ0 and IRQ 8 and provides this way
> > replacement for PIT and RTC periodic function 
> 
> It's that RTC periodic thing that bothers me, I don't mind about
> the PIT.  Remember that IRQ8 is also used for other RTC functions.
> 
> Now, if there were a way to tell rtc-cmos that HPET is active,
> and arrange some kind of handshake ... that would be different.
> 
> - Dave
> 

Yes,
	When HPET is active it eats RTC IRQ,
	So the only way out is to emulate RTC using HPET,
	It is done this way in old rtc driver, rtc-cmos should do the same.

	Of course suspend resume is not supported at all by old rtc driver

	I already wrote complete support for suspend/resume for old rtc driver (I wrote it long time ago)

	Now I fixed it to support HPET , and this way I discovered that HPET doesn't have suspend resume functions

	I will do last checks now and send this patch very soon

	I am also planning to add support of HPET and suspend/resume for rtc-cmos, but I didn't start this yet.

	Best regards,
		Maxim Levitsky




	

Re: [linux-pm] [3/6] 2.6.21-rc4: known regressions

[Maxim]

On Wednesday 28 March 2007 22:42:00 Linus Torvalds wrote:
> 
> On Wed, 28 Mar 2007, David Brownell wrote:
> >
> > On Wednesday 28 March 2007 9:38 am, Linus Torvalds wrote:
> > 
> > > It's a *device*, dammit. It should save and resume like one (probably as a 
> > > system device). The "set_mode()" etc stuff is at a completely different 
> > > (higher) conceptual level.
> > 
> > Agreed, except about "probably as a system device".
> > 
> > Last I checked, there was no good reason to use sysdev suspend()/resume()
> > rather than platform_device suspend_late()/early_resume().  Which more
> > or less means no good reason to use sysdev in new code...
> 
> I won't disagree - it might well be much nicer to just show it in the 
> "real" device tree. I'm not 100% sure where in the tree it would go, 
> though. It should probably be "inside" the root entry, before any of the 
> PCI buses. It's generally what we've used those "system device" things 
> for, but I agree that it would be better to just make system devices show 
> up early on the regular device list than it is to have them be special 
> cases.
> 
> Bit I think that's a separate (and fairly small) issue compared to the 
> "don't use the clocksource infrastructure as a make-believe suspend/resume 
> mechanism" problem that Maxim's patch had.
> 
> (Maxim, don't take that the wrong way - I think your analysis and patch 
> were great, I just think another organization would be better)

Exactly, I agree completely
I said that my patch was a  temporary fix, and I agree that the best way is to create a new system device
and use its suspend/resume hooks to bring HPET back to life on resume.

> 
> > Also, making HPET use the legacy mode seems like a step backwards.
> 
> I don't think that's actually "legacy" in any sense but the interrupt 
> delivery, where the "legacy mode" bit is not so much that the HPET itself 
> is "legacy" but that it *replaces* legacy devices.
> 
> But I may have misunderstood the thing. I'm an old fart, so I know the old 
> timers much better than I know the new ones ;). Somebody feel free to hit 
> me with the clue-2x4.
> 
> 			Linus
> 

Best regards,
	Maxim Levitsky

[ PATCH] Add suspend/resume for HPET was: Re: [3/6] 2.6.21-rc4: known regressions

[Maxim]

On Wednesday 28 March 2007 18:38:48 Linus Torvalds wrote:
> 
> On Wed, 28 Mar 2007, Maxim wrote:
> > 
> > 	Now I don't have a clue how to set those bits if only HPET is used as clock source because now clocksources
> > 	don't have _any_ resume hook.
> 
> One thing that drives me wild about that "clocksource resume" thing is 
> that it seems to think that clocksources are somehow different from any 
> other system devices..
> 
> Why isn't the HPET considered a "device", and has it's own *device* 
> "suspend" and "resume"? Why do we seem to think that only "set_mode()" 
> etc should wake up clock sources?
> 
> It's a *device*, dammit. It should save and resume like one (probably as a 
> system device). The "set_mode()" etc stuff is at a completely different 
> (higher) conceptual level.
> 
> Thomas? It does seem like Maxim has hit the nail on the head (at least 
> partly) on the HPET timer resume problems..
> 
> 		Linus
> 


Hi,
	I am sending here a patch that as was discussed here adds hpet to list of system devices
	and adds suspend/resume hooks this way.
	I tested it and it works fine.

---
Add suspend/resume support for HPET
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>

---
 arch/i386/kernel/hpet.c |   64 +++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 64 insertions(+), 0 deletions(-)

diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
index 0fd9fba..ac41476 100644
--- a/arch/i386/kernel/hpet.c
+++ b/arch/i386/kernel/hpet.c
@@ -3,6 +3,8 @@
 #include <linux/errno.h>
 #include <linux/hpet.h>
 #include <linux/init.h>
+#include <linux/sysdev.h>
+#include <linux/pm.h>
 
 #include <asm/hpet.h>
 #include <asm/io.h>
@@ -524,3 +526,65 @@ irqreturn_t hpet_rtc_interrupt(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 #endif
+
+
+/*
+ * Suspend/resume part
+ */
+
+#ifdef CONFIG_PM
+
+static int hpet_suspend(struct sys_device *sys_device, pm_message_t state)
+{
+	unsigned long cfg = hpet_readl(HPET_CFG);
+
+	cfg &= ~(HPET_CFG_ENABLE|HPET_CFG_LEGACY);
+	hpet_writel(cfg, HPET_CFG);
+
+	return 0;
+}
+
+static int hpet_resume(struct sys_device *sys_device)
+{
+	unsigned int id;
+
+	hpet_start_counter();
+
+	id = hpet_readl(HPET_ID);
+
+	if (id & HPET_ID_LEGSUP)
+		hpet_enable_int();
+
+	return 0;
+}
+
+static struct sysdev_class hpet_class = {
+	set_kset_name("hpet"),
+	.suspend	= hpet_suspend,
+	.resume		= hpet_resume,
+};
+
+static struct sys_device hpet_device = {
+	.id		= 0,
+	.cls		= &hpet_class,
+};
+
+
+static __init int hpet_register_sysfs(void)
+{
+	int err;
+
+	err = sysdev_class_register(&hpet_class);
+
+	if (!err) {
+		sysdev_register(&hpet_device);
+		if (err)
+			sysdev_class_unregister(&hpet_class);
+	}
+
+	return err;
+}
+
+device_initcall(hpet_register_sysfs);
+
+#endif
-- 
1.4.4.2

Re: [ PATCH] Add suspend/resume for HPET was: Re: [3/6] 2.6.21-rc4: known regressions

[Linus Torvalds]

On Thu, 29 Mar 2007, Maxim wrote:
>
> 	I am sending here a patch that as was discussed here adds hpet to list of system devices
> 	and adds suspend/resume hooks this way.
> 	I tested it and it works fine.

Ok, it certainly looks better, but it *also* looks like it just assumes 
the HPET is there. Which would work in testing _with_ a HPET, but would 
likely break on hardware without one, no?

Shouldn't there be at least something like a

	if (!is_hpet_capable())
		return 0;

at the top of that init routine? I'd also expect that you'd need to check 
that "hpet_virt_address" is valid or something?

(Or, better yet, shouldn't we set "boot_hpet_disable" when we decide not 
to use the HPET, and set hpet_virt_address to NULL?)

		Linus

Re: [ PATCH] Add suspend/resume for HPET was: Re: [3/6] 2.6.21-rc4: known regressions

[Linus Torvalds]

On Thu, 29 Mar 2007, Maxim wrote:
>
> 	I am sending here a patch that as was discussed here adds hpet to list of system devices
> 	and adds suspend/resume hooks this way.
> 	I tested it and it works fine.

Ok, it certainly looks better, but it *also* looks like it just assumes 
the HPET is there. Which would work in testing _with_ a HPET, but would 
likely break on hardware without one, no?

Shouldn't there be at least something like a

	if (!is_hpet_capable())
		return 0;

at the top of that init routine? I'd also expect that you'd need to check 
that "hpet_virt_address" is valid or something?

(Or, better yet, shouldn't we set "boot_hpet_disable" when we decide not 
to use the HPET, and set hpet_virt_address to NULL?)

		Linus

Re: [ PATCH] Add suspend/resume for HPET was: Re: [3/6] 2.6.21-rc4: known regressions

[Maxim]

On Thursday 29 March 2007 07:08:58 Linus Torvalds wrote:
> 
> On Thu, 29 Mar 2007, Maxim wrote:
> >
> > 	I am sending here a patch that as was discussed here adds hpet to list of system devices
> > 	and adds suspend/resume hooks this way.
> > 	I tested it and it works fine.
> 
> Ok, it certainly looks better, but it *also* looks like it just assumes 
> the HPET is there. Which would work in testing _with_ a HPET, but would 
> likely break on hardware without one, no?
> 
> Shouldn't there be at least something like a
> 
> 	if (!is_hpet_capable())
> 		return 0;
> 
> at the top of that init routine? I'd also expect that you'd need to check 
> that "hpet_virt_address" is valid or something?
> 
> (Or, better yet, shouldn't we set "boot_hpet_disable" when we decide not 
> to use the HPET, and set hpet_virt_address to NULL?)

This is done here

out_nohpet:
	iounmap(hpet_virt_address);
	hpet_virt_address = NULL;
> 
> 		Linus
> 

Hi, 
	Of course, I forgot.

	I was planning to put sysdev code in hpet_enable()
	but it is not possible because this function is called too early.

	Thus I put sysdev initialization  in separate function but forgot to test for HPET

	Thanks a lot.

	Best regards
		Maxim Levitsky

---
This adds support of suspend/resume on i386 for HPET
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>

---
 arch/i386/kernel/hpet.c |   68 +++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 68 insertions(+), 0 deletions(-)

diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
index 0fd9fba..7c67780 100644
--- a/arch/i386/kernel/hpet.c
+++ b/arch/i386/kernel/hpet.c
@@ -3,6 +3,8 @@
 #include <linux/errno.h>
 #include <linux/hpet.h>
 #include <linux/init.h>
+#include <linux/sysdev.h>
+#include <linux/pm.h>
 
 #include <asm/hpet.h>
 #include <asm/io.h>
@@ -310,6 +312,7 @@ int __init hpet_enable(void)
 out_nohpet:
 	iounmap(hpet_virt_address);
 	hpet_virt_address = NULL;
+	boot_hpet_disable = 1;
 	return 0;
 }
 
@@ -524,3 +527,68 @@ irqreturn_t hpet_rtc_interrupt(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 #endif
+
+
+/*
+ * Suspend/resume part
+ */
+
+#ifdef CONFIG_PM
+
+static int hpet_suspend(struct sys_device *sys_device, pm_message_t state)
+{
+	unsigned long cfg = hpet_readl(HPET_CFG);
+
+	cfg &= ~(HPET_CFG_ENABLE|HPET_CFG_LEGACY);
+	hpet_writel(cfg, HPET_CFG);
+
+	return 0;
+}
+
+static int hpet_resume(struct sys_device *sys_device)
+{
+	unsigned int id;
+
+	hpet_start_counter();
+
+	id = hpet_readl(HPET_ID);
+
+	if (id & HPET_ID_LEGSUP)
+		hpet_enable_int();
+
+	return 0;
+}
+
+static struct sysdev_class hpet_class = {
+	set_kset_name("hpet"),
+	.suspend	= hpet_suspend,
+	.resume		= hpet_resume,
+};
+
+static struct sys_device hpet_device = {
+	.id		= 0,
+	.cls		= &hpet_class,
+};
+
+
+static __init int hpet_register_sysfs(void)
+{
+	int err;
+
+	if (!is_hpet_capable())
+		return 0;
+
+	err = sysdev_class_register(&hpet_class);
+
+	if (!err) {
+		sysdev_register(&hpet_device);
+		if (err)
+			sysdev_class_unregister(&hpet_class);
+	}
+
+	return err;
+}
+
+device_initcall(hpet_register_sysfs);
+
+#endif
-- 
1.4.4.2

Re: [ PATCH] Add suspend/resume for HPET was: Re: [3/6] 2.6.21-rc4: known regressions

[Sergei Shtylyov]

Hello.

Maxim wrote:

> ---
> This adds support of suspend/resume on i386 for HPET

   The part after usually "---" gets cut off, the patch description and 
signoff should actially *precede* it.

> Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>

> diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
> index 0fd9fba..7c67780 100644
> --- a/arch/i386/kernel/hpet.c
> +++ b/arch/i386/kernel/hpet.c
[...]
> +static __init int hpet_register_sysfs(void)
> +{
> +	int err;
> +
> +	if (!is_hpet_capable())
> +		return 0;
> +
> +	err = sysdev_class_register(&hpet_class);
> +
> +	if (!err) {
> +		sysdev_register(&hpet_device);
> +		if (err)
> +			sysdev_class_unregister(&hpet_class);

    This doesn't make sense, err will always be 0.  Perhaps you actually 
intended to check the result of sysdev_register()?

> +	}
> +
> +	return err;
> +}
> +
> +device_initcall(hpet_register_sysfs);
> +
> +#endif

WBR, Sergei

Re: [ PATCH] Add suspend/resume for HPET was: Re: [3/6] 2.6.21-rc4: known regressions

[Sergei Shtylyov]

Hello.

Maxim wrote:

> ---
> This adds support of suspend/resume on i386 for HPET

   The part after usually "---" gets cut off, the patch description and 
signoff should actially *precede* it.

> Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>

> diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
> index 0fd9fba..7c67780 100644
> --- a/arch/i386/kernel/hpet.c
> +++ b/arch/i386/kernel/hpet.c
[...]
> +static __init int hpet_register_sysfs(void)
> +{
> +	int err;
> +
> +	if (!is_hpet_capable())
> +		return 0;
> +
> +	err = sysdev_class_register(&hpet_class);
> +
> +	if (!err) {
> +		sysdev_register(&hpet_device);
> +		if (err)
> +			sysdev_class_unregister(&hpet_class);

    This doesn't make sense, err will always be 0.  Perhaps you actually 
intended to check the result of sysdev_register()?

> +	}
> +
> +	return err;
> +}
> +
> +device_initcall(hpet_register_sysfs);
> +
> +#endif

WBR, Sergei

Re: [ PATCH] Add suspend/resume for HPET was: Re: [3/6] 2.6.21-rc4: known regressions

[Maxim]

On Thursday 29 March 2007 15:20:27 Sergei Shtylyov wrote:
> Hello.
> 
> Maxim wrote:
> 
> > ---
> > This adds support of suspend/resume on i386 for HPET
> 
>    The part after usually "---" gets cut off, the patch description and 
> signoff should actially *precede* it.
> 
> > Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
> 
> > diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
> > index 0fd9fba..7c67780 100644
> > --- a/arch/i386/kernel/hpet.c
> > +++ b/arch/i386/kernel/hpet.c
> [...]
> > +static __init int hpet_register_sysfs(void)
> > +{
> > +	int err;
> > +
> > +	if (!is_hpet_capable())
> > +		return 0;
> > +
> > +	err = sysdev_class_register(&hpet_class);
> > +
> > +	if (!err) {
> > +		sysdev_register(&hpet_device);
> > +		if (err)
> > +			sysdev_class_unregister(&hpet_class);
> 
>     This doesn't make sense, err will always be 0.  Perhaps you actually 
> intended to check the result of sysdev_register()?
> 
> > +	}
> > +
> > +	return err;
> > +}
> > +
> > +device_initcall(hpet_register_sysfs);
> > +
> > +#endif
> 
> WBR, Sergei
> 

Hi,
	Big thanks for pointing this out,
		I will resend that updated patch.

	Best regards,
		Maxim Levitsky

[PATCH v2] Add suspend/resume for HPET

[Maxim Levitsky]

Subject: Add suspend/resume for HPET
This adds support of suspend/resume on i386 for HPET
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>

---
 arch/i386/kernel/hpet.c |   68 +++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 68 insertions(+), 0 deletions(-)

diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
index 0fd9fba..7c67780 100644
--- a/arch/i386/kernel/hpet.c
+++ b/arch/i386/kernel/hpet.c
@@ -3,6 +3,8 @@
 #include <linux/errno.h>
 #include <linux/hpet.h>
 #include <linux/init.h>
+#include <linux/sysdev.h>
+#include <linux/pm.h>
 
 #include <asm/hpet.h>
 #include <asm/io.h>
@@ -310,6 +312,7 @@ int __init hpet_enable(void)
 out_nohpet:
 	iounmap(hpet_virt_address);
 	hpet_virt_address = NULL;
+	boot_hpet_disable = 1;
 	return 0;
 }
 
@@ -524,3 +527,68 @@ irqreturn_t hpet_rtc_interrupt(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 #endif
+
+
+/*
+ * Suspend/resume part
+ */
+
+#ifdef CONFIG_PM
+
+static int hpet_suspend(struct sys_device *sys_device, pm_message_t state)
+{
+	unsigned long cfg = hpet_readl(HPET_CFG);
+
+	cfg &= ~(HPET_CFG_ENABLE|HPET_CFG_LEGACY);
+	hpet_writel(cfg, HPET_CFG);
+
+	return 0;
+}
+
+static int hpet_resume(struct sys_device *sys_device)
+{
+	unsigned int id;
+
+	hpet_start_counter();
+
+	id = hpet_readl(HPET_ID);
+
+	if (id & HPET_ID_LEGSUP)
+		hpet_enable_int();
+
+	return 0;
+}
+
+static struct sysdev_class hpet_class = {
+	set_kset_name("hpet"),
+	.suspend	= hpet_suspend,
+	.resume		= hpet_resume,
+};
+
+static struct sys_device hpet_device = {
+	.id		= 0,
+	.cls		= &hpet_class,
+};
+
+
+static __init int hpet_register_sysfs(void)
+{
+	int err;
+
+	if (!is_hpet_capable())
+		return 0;
+
+	err = sysdev_class_register(&hpet_class);
+
+	if (!err) {
+		err = sysdev_register(&hpet_device);
+		if (err)
+			sysdev_class_unregister(&hpet_class);
+	}
+
+	return err;
+}
+
+device_initcall(hpet_register_sysfs);
+
+#endif
-- 
1.4.4.2

[PATCH v2] Add suspend/resume for HPET

[Maxim Levitsky]

Subject: Add suspend/resume for HPET
This adds support of suspend/resume on i386 for HPET
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>

---
 arch/i386/kernel/hpet.c |   68 +++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 68 insertions(+), 0 deletions(-)

diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
index 0fd9fba..7c67780 100644
--- a/arch/i386/kernel/hpet.c
+++ b/arch/i386/kernel/hpet.c
@@ -3,6 +3,8 @@
 #include <linux/errno.h>
 #include <linux/hpet.h>
 #include <linux/init.h>
+#include <linux/sysdev.h>
+#include <linux/pm.h>
 
 #include <asm/hpet.h>
 #include <asm/io.h>
@@ -310,6 +312,7 @@ int __init hpet_enable(void)
 out_nohpet:
 	iounmap(hpet_virt_address);
 	hpet_virt_address = NULL;
+	boot_hpet_disable = 1;
 	return 0;
 }
 
@@ -524,3 +527,68 @@ irqreturn_t hpet_rtc_interrupt(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 #endif
+
+
+/*
+ * Suspend/resume part
+ */
+
+#ifdef CONFIG_PM
+
+static int hpet_suspend(struct sys_device *sys_device, pm_message_t state)
+{
+	unsigned long cfg = hpet_readl(HPET_CFG);
+
+	cfg &= ~(HPET_CFG_ENABLE|HPET_CFG_LEGACY);
+	hpet_writel(cfg, HPET_CFG);
+
+	return 0;
+}
+
+static int hpet_resume(struct sys_device *sys_device)
+{
+	unsigned int id;
+
+	hpet_start_counter();
+
+	id = hpet_readl(HPET_ID);
+
+	if (id & HPET_ID_LEGSUP)
+		hpet_enable_int();
+
+	return 0;
+}
+
+static struct sysdev_class hpet_class = {
+	set_kset_name("hpet"),
+	.suspend	= hpet_suspend,
+	.resume		= hpet_resume,
+};
+
+static struct sys_device hpet_device = {
+	.id		= 0,
+	.cls		= &hpet_class,
+};
+
+
+static __init int hpet_register_sysfs(void)
+{
+	int err;
+
+	if (!is_hpet_capable())
+		return 0;
+
+	err = sysdev_class_register(&hpet_class);
+
+	if (!err) {
+		err = sysdev_register(&hpet_device);
+		if (err)
+			sysdev_class_unregister(&hpet_class);
+	}
+
+	return err;
+}
+
+device_initcall(hpet_register_sysfs);
+
+#endif
-- 
1.4.4.2

Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"

[Andi Kleen]

Len Brown <lenb@kernel.org> writes:

> On an Intel processor, it seems that the safe and simple route
> is if the system exports C2 or deeper, don't use the LAPIC timer.
> (which is what 2.6.21-rc5 is doing as of this moment)
> We may be able to white-list some systems over time.

On AMD it is the same, except that there seems to be at least
one system that does C2 like things while only exporting C1.
That is why i proposed to check for a battery too -- if there is one
always disable it too.

-Andi

Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"

[Andi Kleen]

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

> On Tue, 27 Mar 2007, Len Brown wrote:
> > 
> > I think the only fool-proof way to do this automatically is to
> 
> Why not just take the known-good CPUID signature?

I didn't think we could reliably distingush mobile cpus with C2+ 
versus desktop CPUs without it. Or rather you would need a table
for each new CPU revision Intel/AMD put out. That would be probably
quite nightmarish to maintain.

-Andi

Re: [3/6] 2.6.21-rc4: known regressions

[Jeff Chua]

On 3/29/07, Michael S. Tsirkin <mst@dev.mellanox.co.il> wrote:
> > Quoting Maxim <maximlevitsky@gmail.com>:
> >                       The patch below is a temporally fix, until
> >       clock-events and clocksources will get proper suspend/resume
> >       hooks:
> Bingo!

I confirmed that it suspend/resume disk/ram all works on my X60s with
CONFIG_HPET_TIMER=y and CONFIG_NO_HZ unset.

But suspend to disk still hang with CONFIG_NO_HZ=y no matter what
setting CONFIG_HPET_TIMER is set to.

Thanks,
Jeff.

RE: [PATCH] i386: add command line option "local_apic_timer_c2_ok"

[Langsdorf, Mark]

> > If we really care about using the LAPIC timer on systems with deeper
> > than C1 support, the only alternative seems to be to test
> > if it actually works or not at boot and run-time.
> > Otherwise, we wait for future hardware with guaranteed
> > not to break under any (BIOS) conditions ships, and check for that.
> > 
> > Based on what I read of the HP nx6325 where the LAPIC timer
> > is breaking C1, AMD is in the same boat.
> 
> The nx6325 (Turion 64 X2) exports only C1.
> I'm not sure how the conclusion was drawn that it has
> a broken lapic timer as reflected in the "nolapic_timer" patch:

If both cores goes into C1 at the same time, the chipset
can move the processor into a C3 like state called C1e.
 
> +               /*
> +                * BIOS exports only C1 state, but uses deeper power
> +                * modes behind the kernels back.
> +                */
> +                 .callback = lapic_check_broken_bios,
> +                 .ident = "HP nx6325",
> +                 .matches = {
> +                       DMI_MATCH(DMI_PRODUCT_NAME, "HP 
> Compaq nx6325"),
> +                 },
> +        },
> 
> But if this is true, then I don't know how to determine on
> an AMD system if the LAPIC timer is guaranteed to work --
> even for systems with just C1.
> 
> Jordan, William, can you clarify?

For K7 and K8 through and including revision E, the LAPIC
timer is guaranteed to work in C1.

For K8 revisions F and G, and for upcoming family 0x10 and
0x11 parts, if either bit in MSRC001_0055[28:27] is set,
C1e is enabled and the LAPIC timer cannot be trusted in
C1.

AMD can craft a patch to sort this out as soon as we have
an idea what the framework is going to look like.

-Mark Langsdorf
Operating Systems Research Center
AMD, Inc.

Re: [ PATCH] Add suspend/resume for HPET was: Re: [3/6] 2.6.21-rc4: known regressions

[Linus Torvalds]

On Thu, 29 Mar 2007, Maxim wrote:

> On Thursday 29 March 2007 07:08:58 Linus Torvalds wrote:
> > 
> > (Or, better yet, shouldn't we set "boot_hpet_disable" when we decide not 
> > to use the HPET, and set hpet_virt_address to NULL?)
> 
> This is done here
> 
> out_nohpet:
> 	iounmap(hpet_virt_address);
> 	hpet_virt_address = NULL;

No, that only clears hpet_virt_address, and thus makes all subsequent 
"hpet_readl()" and "hpet_writel()" calls oops.

But it doesn't actually *tell* anybody that the HPET is disabled, so if 
you later on do

	if (is_hpet_capable()) {
		time = hpet_readl(..);
		..

you will just Oops!

So as far as I can see, even with your latest patch, if hpet_enable() 
fails (and triggers the "goto out_nohpet" cases), you'll just oops 
immediately when you try to suspend/resume the HPET.

THAT was what I meant - when we clear hpet_virt_address, we should also 
tell all potential subsequent users that the HPET is not there!

		Linus

Re: [ PATCH] Add suspend/resume for HPET was: Re: [3/6] 2.6.21-rc4: known regressions

[Linus Torvalds]

On Thu, 29 Mar 2007, Maxim wrote:

> On Thursday 29 March 2007 07:08:58 Linus Torvalds wrote:
> > 
> > (Or, better yet, shouldn't we set "boot_hpet_disable" when we decide not 
> > to use the HPET, and set hpet_virt_address to NULL?)
> 
> This is done here
> 
> out_nohpet:
> 	iounmap(hpet_virt_address);
> 	hpet_virt_address = NULL;

No, that only clears hpet_virt_address, and thus makes all subsequent 
"hpet_readl()" and "hpet_writel()" calls oops.

But it doesn't actually *tell* anybody that the HPET is disabled, so if 
you later on do

	if (is_hpet_capable()) {
		time = hpet_readl(..);
		..

you will just Oops!

So as far as I can see, even with your latest patch, if hpet_enable() 
fails (and triggers the "goto out_nohpet" cases), you'll just oops 
immediately when you try to suspend/resume the HPET.

THAT was what I meant - when we clear hpet_virt_address, we should also 
tell all potential subsequent users that the HPET is not there!

		Linus

Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"

[Andi Kleen]

"Langsdorf, Mark" <mark.langsdorf@amd.com> writes:

> > > If we really care about using the LAPIC timer on systems with deeper
> > > than C1 support, the only alternative seems to be to test
> > > if it actually works or not at boot and run-time.
> > > Otherwise, we wait for future hardware with guaranteed
> > > not to break under any (BIOS) conditions ships, and check for that.
> > > 
> > > Based on what I read of the HP nx6325 where the LAPIC timer
> > > is breaking C1, AMD is in the same boat.
> > 
> > The nx6325 (Turion 64 X2) exports only C1.
> > I'm not sure how the conclusion was drawn that it has
> > a broken lapic timer as reflected in the "nolapic_timer" patch:
> 
> If both cores goes into C1 at the same time, the chipset
> can move the processor into a C3 like state called C1e.

... and that seems to break the local APIC timer.

> AMD can craft a patch to sort this out as soon as we have
> an idea what the framework is going to look like.

Just a snippet to detect it would be great. Then the dmi scan
could be removed and replaced with that. This would be a 2.6.21
candidate imho over the DMI hack.

-Andi

Re: [ PATCH] Add suspend/resume for HPET was: Re: [3/6] 2.6.21-rc4: known regressions

[Maxim Levitsky]

On Thursday 29 March 2007 18:35:21 Linus Torvalds wrote:
> 
> On Thu, 29 Mar 2007, Maxim wrote:
> 
> > On Thursday 29 March 2007 07:08:58 Linus Torvalds wrote:
> > > 
> > > (Or, better yet, shouldn't we set "boot_hpet_disable" when we decide not 
> > > to use the HPET, and set hpet_virt_address to NULL?)
> > 
> > This is done here
> > 
> > out_nohpet:
> > 	iounmap(hpet_virt_address);
> > 	hpet_virt_address = NULL;
> 
> No, that only clears hpet_virt_address, and thus makes all subsequent 
> "hpet_readl()" and "hpet_writel()" calls oops.
> 
> But it doesn't actually *tell* anybody that the HPET is disabled, so if 
> you later on do
> 
> 	if (is_hpet_capable()) {
> 		time = hpet_readl(..);
> 		..
> 
> you will just Oops!
> 
> So as far as I can see, even with your latest patch, if hpet_enable() 
> fails (and triggers the "goto out_nohpet" cases), you'll just oops 
> immediately when you try to suspend/resume the HPET.
> 
> THAT was what I meant - when we clear hpet_virt_address, we should also 
> tell all potential subsequent users that the HPET is not there!
> 
> 		Linus
> 

Hi,
	I agree, and as you said I did exactly that:

out_nohpet:
	iounmap(hpet_virt_address);
	hpet_virt_address = NULL;
	boot_hpet_disable = 1; <<<--- this ensures that is_hpet_capable() will never return positive value


	I also sent an updated version on my patch with subject line "[PATCH v2] Add suspend/resume for HPET"

	I forgot (a typo) to check error code in  hpet_register_sysfs
	Thanks to Sergei Shtylyov for pointing me on that.

	This patch should be ok.

	Best regards,
		Maxim Levitsky

Re: [ PATCH] Add suspend/resume for HPET was: Re: [3/6] 2.6.21-rc4: known regressions

[Maxim Levitsky]

On Thursday 29 March 2007 18:35:21 Linus Torvalds wrote:
> 
> On Thu, 29 Mar 2007, Maxim wrote:
> 
> > On Thursday 29 March 2007 07:08:58 Linus Torvalds wrote:
> > > 
> > > (Or, better yet, shouldn't we set "boot_hpet_disable" when we decide not 
> > > to use the HPET, and set hpet_virt_address to NULL?)
> > 
> > This is done here
> > 
> > out_nohpet:
> > 	iounmap(hpet_virt_address);
> > 	hpet_virt_address = NULL;
> 
> No, that only clears hpet_virt_address, and thus makes all subsequent 
> "hpet_readl()" and "hpet_writel()" calls oops.
> 
> But it doesn't actually *tell* anybody that the HPET is disabled, so if 
> you later on do
> 
> 	if (is_hpet_capable()) {
> 		time = hpet_readl(..);
> 		..
> 
> you will just Oops!
> 
> So as far as I can see, even with your latest patch, if hpet_enable() 
> fails (and triggers the "goto out_nohpet" cases), you'll just oops 
> immediately when you try to suspend/resume the HPET.
> 
> THAT was what I meant - when we clear hpet_virt_address, we should also 
> tell all potential subsequent users that the HPET is not there!
> 
> 		Linus
> 

Hi,
	I agree, and as you said I did exactly that:

out_nohpet:
	iounmap(hpet_virt_address);
	hpet_virt_address = NULL;
	boot_hpet_disable = 1; <<<--- this ensures that is_hpet_capable() will never return positive value


	I also sent an updated version on my patch with subject line "[PATCH v2] Add suspend/resume for HPET"

	I forgot (a typo) to check error code in  hpet_register_sysfs
	Thanks to Sergei Shtylyov for pointing me on that.

	This patch should be ok.

	Best regards,
		Maxim Levitsky

Re: [PATCH v2] Add suspend/resume for HPET

[Linus Torvalds]

On Thu, 29 Mar 2007, Maxim Levitsky wrote:
>
> Subject: Add suspend/resume for HPET
>
> This adds support of suspend/resume on i386 for HPET
>
> Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
> 
> ---
>  arch/i386/kernel/hpet.c |   68 +++++++++++++++++++++++++++++++++++++++++++++++

Btw, what about arch/x86_64/kernel/hpet.c?

That thing seems totally broken. Lookie here:

  arch/x86_64/kernel/hpet.c:irqreturn_t hpet_rtc_interrupt(int irq, void *dev_id, struct pt_regs *regs)
  drivers/char/rtc.c:extern irqreturn_t hpet_rtc_interrupt(int irq, void *dev_id);

anybody see a problem? The x86-64 version doesn't seem to be very well 
maintained. Is there some fundamental reason why this file isn't shared 
across architectures?

			Linus

Re: [PATCH v2] Add suspend/resume for HPET

[Linus Torvalds]

On Thu, 29 Mar 2007, Maxim Levitsky wrote:
>
> Subject: Add suspend/resume for HPET
>
> This adds support of suspend/resume on i386 for HPET
>
> Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
> 
> ---
>  arch/i386/kernel/hpet.c |   68 +++++++++++++++++++++++++++++++++++++++++++++++

Btw, what about arch/x86_64/kernel/hpet.c?

That thing seems totally broken. Lookie here:

  arch/x86_64/kernel/hpet.c:irqreturn_t hpet_rtc_interrupt(int irq, void *dev_id, struct pt_regs *regs)
  drivers/char/rtc.c:extern irqreturn_t hpet_rtc_interrupt(int irq, void *dev_id);

anybody see a problem? The x86-64 version doesn't seem to be very well 
maintained. Is there some fundamental reason why this file isn't shared 
across architectures?

			Linus

Re: [ PATCH] Add suspend/resume for HPET was: Re: [3/6] 2.6.21-rc4: known regressions

[Linus Torvalds]

On Thu, 29 Mar 2007, Maxim Levitsky wrote:
>
> 	I agree, and as you said I did exactly that:

Gaah. I'm blind. Sorry. Your patch did indeed do exactly that, I somehow 
overlooked it.

		Linus

Re: [ PATCH] Add suspend/resume for HPET was: Re: [3/6] 2.6.21-rc4: known regressions

[Linus Torvalds]

On Thu, 29 Mar 2007, Maxim Levitsky wrote:
>
> 	I agree, and as you said I did exactly that:

Gaah. I'm blind. Sorry. Your patch did indeed do exactly that, I somehow 
overlooked it.

		Linus

Re: [PATCH v2] Add suspend/resume for HPET

[Maxim Levitsky]

On Thursday 29 March 2007 18:53:37 Linus Torvalds wrote:
> 
> On Thu, 29 Mar 2007, Maxim Levitsky wrote:
> >
> > Subject: Add suspend/resume for HPET
> >
> > This adds support of suspend/resume on i386 for HPET
> >
> > Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
> > 
> > ---
> >  arch/i386/kernel/hpet.c |   68 +++++++++++++++++++++++++++++++++++++++++++++++
> 
> Btw, what about arch/x86_64/kernel/hpet.c?
> 
> That thing seems totally broken. Lookie here:
> 
>   arch/x86_64/kernel/hpet.c:irqreturn_t hpet_rtc_interrupt(int irq, void *dev_id, struct pt_regs *regs)
>   drivers/char/rtc.c:extern irqreturn_t hpet_rtc_interrupt(int irq, void *dev_id);
> 
> anybody see a problem? The x86-64 version doesn't seem to be very well 
> maintained. Is there some fundamental reason why this file isn't shared 
> across architectures?
> 
> 			Linus
> 

Hi,
	I agree with that, there seems to be lot of code duplication between i386 and x86_64.
	By the way, x86_64 does take care of suspend/resume for hpet, it is done by 

	linux-2.6/arch/x86_64/kernel/time.c:timer_resume(struct sys_device *dev):
		hpet_reenable()


	on i386 PIT driver goes out of way when HPET is detected
	So it seems that there is lot of work to do to remove redundant code.


	Best regards,
		Maxim Levitsky

Re: [patch, v2] add suspend/resume for HPET

[Ingo Molnar]

update: i've tested Maxim's v2 patch on both a hpet-capable and a 
hpet-less system, and it works fine here.

on a dual-core hpet-capable system, running a NO_HZ+!HIGH_RES_TIMERS 
kernel:

  europe:~> grep Clock /proc/timer_list
  Clock Event Device: hpet
  Clock Event Device: lapic
  Clock Event Device: lapic

s2ram works fine now - it hung on resume before.

on a dual-core non-hpet system, with a NO_HZ+!HIGH_RES_TIMERS kernel:

  neptune:~> grep Clock /proc/timer_list
  Clock Event Device: pit
  Clock Event Device: lapic
  Clock Event Device: lapic

s2ram worked fine before - and it still works now.

(The combination of NO_HZ+!HIGH_RES_TIMERS was the most fragile wrt. 
suspend because in the !HIGH_RES_TIMERS there's just a single instance 
after resume that we touch the timer hardware, and we very much rely on 
the periodic interrupt being set to the precise value.)

So this is a go on my systems - good work Maxim! (I've reproduced 
Maxim's patch below with minor patch-metadata updates.)

	Ingo

---------------------------->
Subject: [patch] add suspend/resume for HPET
From: Maxim Levitsky <maximlevitsky@gmail.com>

This adds support for suspend/resume on i386 for HPET.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>

---
 arch/i386/kernel/hpet.c |   68 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 68 insertions(+)

Index: linux/arch/i386/kernel/hpet.c
===================================================================
--- linux.orig/arch/i386/kernel/hpet.c
+++ linux/arch/i386/kernel/hpet.c
@@ -3,6 +3,8 @@
 #include <linux/errno.h>
 #include <linux/hpet.h>
 #include <linux/init.h>
+#include <linux/sysdev.h>
+#include <linux/pm.h>
 
 #include <asm/hpet.h>
 #include <asm/io.h>
@@ -307,6 +309,7 @@ int __init hpet_enable(void)
 out_nohpet:
 	iounmap(hpet_virt_address);
 	hpet_virt_address = NULL;
+	boot_hpet_disable = 1;
 	return 0;
 }
 
@@ -523,3 +526,68 @@ irqreturn_t hpet_rtc_interrupt(int irq, 
 	return IRQ_HANDLED;
 }
 #endif
+
+
+/*
+ * Suspend/resume part
+ */
+
+#ifdef CONFIG_PM
+
+static int hpet_suspend(struct sys_device *sys_device, pm_message_t state)
+{
+	unsigned long cfg = hpet_readl(HPET_CFG);
+
+	cfg &= ~(HPET_CFG_ENABLE|HPET_CFG_LEGACY);
+	hpet_writel(cfg, HPET_CFG);
+
+	return 0;
+}
+
+static int hpet_resume(struct sys_device *sys_device)
+{
+	unsigned int id;
+
+	hpet_start_counter();
+
+	id = hpet_readl(HPET_ID);
+
+	if (id & HPET_ID_LEGSUP)
+		hpet_enable_int();
+
+	return 0;
+}
+
+static struct sysdev_class hpet_class = {
+	set_kset_name("hpet"),
+	.suspend	= hpet_suspend,
+	.resume		= hpet_resume,
+};
+
+static struct sys_device hpet_device = {
+	.id		= 0,
+	.cls		= &hpet_class,
+};
+
+
+static __init int hpet_register_sysfs(void)
+{
+	int err;
+
+	if (!is_hpet_capable())
+		return 0;
+
+	err = sysdev_class_register(&hpet_class);
+
+	if (!err) {
+		err = sysdev_register(&hpet_device);
+		if (err)
+			sysdev_class_unregister(&hpet_class);
+	}
+
+	return err;
+}
+
+device_initcall(hpet_register_sysfs);
+
+#endif

Re: [patch, v2] add suspend/resume for HPET

[Ingo Molnar]

update: i've tested Maxim's v2 patch on both a hpet-capable and a 
hpet-less system, and it works fine here.

on a dual-core hpet-capable system, running a NO_HZ+!HIGH_RES_TIMERS 
kernel:

  europe:~> grep Clock /proc/timer_list
  Clock Event Device: hpet
  Clock Event Device: lapic
  Clock Event Device: lapic

s2ram works fine now - it hung on resume before.

on a dual-core non-hpet system, with a NO_HZ+!HIGH_RES_TIMERS kernel:

  neptune:~> grep Clock /proc/timer_list
  Clock Event Device: pit
  Clock Event Device: lapic
  Clock Event Device: lapic

s2ram worked fine before - and it still works now.

(The combination of NO_HZ+!HIGH_RES_TIMERS was the most fragile wrt. 
suspend because in the !HIGH_RES_TIMERS there's just a single instance 
after resume that we touch the timer hardware, and we very much rely on 
the periodic interrupt being set to the precise value.)

So this is a go on my systems - good work Maxim! (I've reproduced 
Maxim's patch below with minor patch-metadata updates.)

	Ingo

---------------------------->
Subject: [patch] add suspend/resume for HPET
From: Maxim Levitsky <maximlevitsky@gmail.com>

This adds support for suspend/resume on i386 for HPET.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>

---
 arch/i386/kernel/hpet.c |   68 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 68 insertions(+)

Index: linux/arch/i386/kernel/hpet.c
===================================================================
--- linux.orig/arch/i386/kernel/hpet.c
+++ linux/arch/i386/kernel/hpet.c
@@ -3,6 +3,8 @@
 #include <linux/errno.h>
 #include <linux/hpet.h>
 #include <linux/init.h>
+#include <linux/sysdev.h>
+#include <linux/pm.h>
 
 #include <asm/hpet.h>
 #include <asm/io.h>
@@ -307,6 +309,7 @@ int __init hpet_enable(void)
 out_nohpet:
 	iounmap(hpet_virt_address);
 	hpet_virt_address = NULL;
+	boot_hpet_disable = 1;
 	return 0;
 }
 
@@ -523,3 +526,68 @@ irqreturn_t hpet_rtc_interrupt(int irq, 
 	return IRQ_HANDLED;
 }
 #endif
+
+
+/*
+ * Suspend/resume part
+ */
+
+#ifdef CONFIG_PM
+
+static int hpet_suspend(struct sys_device *sys_device, pm_message_t state)
+{
+	unsigned long cfg = hpet_readl(HPET_CFG);
+
+	cfg &= ~(HPET_CFG_ENABLE|HPET_CFG_LEGACY);
+	hpet_writel(cfg, HPET_CFG);
+
+	return 0;
+}
+
+static int hpet_resume(struct sys_device *sys_device)
+{
+	unsigned int id;
+
+	hpet_start_counter();
+
+	id = hpet_readl(HPET_ID);
+
+	if (id & HPET_ID_LEGSUP)
+		hpet_enable_int();
+
+	return 0;
+}
+
+static struct sysdev_class hpet_class = {
+	set_kset_name("hpet"),
+	.suspend	= hpet_suspend,
+	.resume		= hpet_resume,
+};
+
+static struct sys_device hpet_device = {
+	.id		= 0,
+	.cls		= &hpet_class,
+};
+
+
+static __init int hpet_register_sysfs(void)
+{
+	int err;
+
+	if (!is_hpet_capable())
+		return 0;
+
+	err = sysdev_class_register(&hpet_class);
+
+	if (!err) {
+		err = sysdev_register(&hpet_device);
+		if (err)
+			sysdev_class_unregister(&hpet_class);
+	}
+
+	return err;
+}
+
+device_initcall(hpet_register_sysfs);
+
+#endif

Re: [PATCH v2] Add suspend/resume for HPET

[Ingo Molnar]

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

> Btw, what about arch/x86_64/kernel/hpet.c?

at least wrt. suspend/resume it should be fine, because in 
arch/x86_64/kernel/time.c it does this upon resume:

 static int timer_resume(struct sys_device *dev)
 {
         if (hpet_address)
                 hpet_reenable();
         else
                 i8254_timer_resume();

[ barring the issue that mixing two pieces of hardware like this in a 
  single resume function is wrong - all timer hardware should be 
  separated like we did it for i386. I've got 64-bit clockevents code in 
  -rt which does this separation. ]

> That thing seems totally broken. Lookie here:
> 
>   arch/x86_64/kernel/hpet.c:irqreturn_t hpet_rtc_interrupt(int irq, void *dev_id, struct pt_regs *regs)
>   drivers/char/rtc.c:extern irqreturn_t hpet_rtc_interrupt(int irq, void *dev_id);
> 
> anybody see a problem? The x86-64 version doesn't seem to be very well 
> maintained. Is there some fundamental reason why this file isn't 
> shared across architectures?

there's no fundamental reason. x86_64 COW-ed hpet_timer.c and 
time_hpet.c years ago and drifted off into different areas.
They should be unified: more power to arch/x86/ ;-)

	Ingo

Re: [PATCH v2] Add suspend/resume for HPET

[Ingo Molnar]

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

> Btw, what about arch/x86_64/kernel/hpet.c?

at least wrt. suspend/resume it should be fine, because in 
arch/x86_64/kernel/time.c it does this upon resume:

 static int timer_resume(struct sys_device *dev)
 {
         if (hpet_address)
                 hpet_reenable();
         else
                 i8254_timer_resume();

[ barring the issue that mixing two pieces of hardware like this in a 
  single resume function is wrong - all timer hardware should be 
  separated like we did it for i386. I've got 64-bit clockevents code in 
  -rt which does this separation. ]

> That thing seems totally broken. Lookie here:
> 
>   arch/x86_64/kernel/hpet.c:irqreturn_t hpet_rtc_interrupt(int irq, void *dev_id, struct pt_regs *regs)
>   drivers/char/rtc.c:extern irqreturn_t hpet_rtc_interrupt(int irq, void *dev_id);
> 
> anybody see a problem? The x86-64 version doesn't seem to be very well 
> maintained. Is there some fundamental reason why this file isn't 
> shared across architectures?

there's no fundamental reason. x86_64 COW-ed hpet_timer.c and 
time_hpet.c years ago and drifted off into different areas.
They should be unified: more power to arch/x86/ ;-)

	Ingo

Re: [PATCH v2] Add suspend/resume for HPET

[Jeff Chua]

On 3/29/07, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> Subject: Add suspend/resume for HPET
> This adds support of suspend/resume on i386 for HPET
> Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>

Confirmed that suspend/resume disk/ram works on X60s with
CONFIG_HPET_TIMER=y and CONFIG_NO_HZ unset.

But suspend to disk still hang with CONFIG_NO_HZ unset.

Thanks,
Jeff.

Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"

[Mark Langsdorf]

Andi Kleen wrote:
> "Langsdorf, Mark" <mark.langsdorf@amd.com> writes:
> 
>>>> If we really care about using the LAPIC timer on systems with deeper
>>>> than C1 support, the only alternative seems to be to test
>>>> if it actually works or not at boot and run-time.
>>>> Otherwise, we wait for future hardware with guaranteed
>>>> not to break under any (BIOS) conditions ships, and check for that.
>>>>
>>>> Based on what I read of the HP nx6325 where the LAPIC timer
>>>> is breaking C1, AMD is in the same boat.
>>> The nx6325 (Turion 64 X2) exports only C1.
>>> I'm not sure how the conclusion was drawn that it has
>>> a broken lapic timer as reflected in the "nolapic_timer" patch:
>> If both cores goes into C1 at the same time, the chipset
>> can move the processor into a C3 like state called C1e.
> 
> ... and that seems to break the local APIC timer.

Yes.  The APIC timer still runs, but no longer has an HT link
to send the signal on.

>> AMD can craft a patch to sort this out as soon as we have
>> an idea what the framework is going to look like.
> 
> Just a snippet to detect it would be great. Then the dmi scan
> could be removed and replaced with that. This would be a 2.6.21
> candidate imho over the DMI hack.

Reviewed but not tested.  Needs to be wrapped in an AMD specific
call.

#define ENABLE_C1E_MASK		0x18000000
#define CPUID_PROCESSOR_SIGNATURE	1
#define CPUID_XFAM		0x0ff00000
#define CPUID_XFAM_K8		0x00000000
#define CPUID_XFAM_10H		0x00100000
#define CPUID_XFAM_11H		0x00200000
#define CPUID_XMOD		0x000f0000
#define CPUID_XMOD_REV_F	0x00040000

	int safe_c1 = 1;
	u32 eax, lo, hi;
	eax = cpuid_eax(CPUID_PROCESSOR_SIGNATURE)
	switch (eax & CPUID_XFAM) {
	case CPUID_XFAM_K8:
		if ((eax & CPUID_XMOD) < CPUID_XMOD_REV_F)
			break;
	case CPUID_XFAM_10H:
	case CPUID_XFAM_11H:
		rdmsr(MSR_ENABLE_C1E, lo, hi);
		if (lo & ENABLE_C1E_MASK)
			safe_c1 = 0;
		break;
	default:
		/* err on the side of caution */
		safe_c1 = 0;
	}

-Mark Langsdorf
Operating Systems Research Center
AMD, Inc.

Re: [PATCH v2] Add suspend/resume for HPET

[Andi Kleen]

Ingo Molnar <mingo@elte.hu> writes:
> 
> there's no fundamental reason. x86_64 COW-ed hpet_timer.c and 
> time_hpet.c years ago and drifted off into different areas.

Not quite -- x86-64 did HPET long before i386; the only stuff cowed
was the character driver support code. But the core HPET code
was always totally different code streams. We never did the complicated 
pluggable clock code i386 did though -- i never quite saw the point of that
because there aren't that many timers there.
Of course it is already obsolete with clocksources now.

-Andi

Re: [PATCH v2] Add suspend/resume for HPET

[Andi Kleen]

Ingo Molnar <mingo@elte.hu> writes:
> 
> there's no fundamental reason. x86_64 COW-ed hpet_timer.c and 
> time_hpet.c years ago and drifted off into different areas.

Not quite -- x86-64 did HPET long before i386; the only stuff cowed
was the character driver support code. But the core HPET code
was always totally different code streams. We never did the complicated 
pluggable clock code i386 did though -- i never quite saw the point of that
because there aren't that many timers there.
Of course it is already obsolete with clocksources now.

-Andi

Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"

[Andi Kleen]

> Reviewed but not tested.  Needs to be wrapped in an AMD specific
> call.

Here's a patch. I don't have a system with C1E, so i only tested that
the apic timer still works on a older AMD box.

Would be good if someone with a Turion laptop, especially the HP nx6325
could test it with CONFIG_NO_HZ enabled.

-Andi

Disable local APIC timer use on AMD systems with C1E

AMD dual core laptops with C1E do not run the APIC timer correctly
when they go idle. Previously the code assumed this only happened
on C2 or deeper.  But not all of these systems report support C2.

Use a AMD supplied snippet to detect C1E being enabled and then disable
local apic timer use.

This supercedes an earlier workaround using DMI detection of specific systems.

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

Index: linux/arch/i386/kernel/apic.c
===================================================================
--- linux.orig/arch/i386/kernel/apic.c
+++ linux/arch/i386/kernel/apic.c
@@ -272,32 +272,6 @@ static void __devinit setup_APIC_timer(v
 }
 
 /*
- * Detect systems with known broken BIOS implementations
- */
-static int __init lapic_check_broken_bios(struct dmi_system_id *d)
-{
-	printk(KERN_NOTICE "%s detected: disabling lapic timer.\n",
-		       d->ident);
-	local_apic_timer_disabled = 1;
-	return 0;
-}
-
-static struct dmi_system_id __initdata broken_bios_dmi_table[] = {
-	{
-		/*
-		 * BIOS exports only C1 state, but uses deeper power
-		 * modes behind the kernels back.
-		 */
-		  .callback = lapic_check_broken_bios,
-		  .ident = "HP nx6325",
-		  .matches = {
-			DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq nx6325"),
-		  },
-	 },
-	 {}
-};
-
-/*
  * In this functions we calibrate APIC bus clocks to the external timer.
  *
  * We want to do the calibration only once since we want to have local timer
@@ -357,6 +331,44 @@ static void __init lapic_cal_handler(str
 	}
 }
 
+#define ENABLE_C1E_MASK         0x18000000
+#define CPUID_PROCESSOR_SIGNATURE       1
+#define CPUID_XFAM              0x0ff00000
+#define CPUID_XFAM_K8           0x00000000
+#define CPUID_XFAM_10H          0x00100000
+#define CPUID_XFAM_11H          0x00200000
+#define CPUID_XMOD              0x000f0000
+#define CPUID_XMOD_REV_F        0x00040000
+
+/* AMD systems with C1E don't have a working lAPIC timer. Check for that. */
+static __init int amd_apic_timer_broken(void)
+{
+	u32 lo, hi;
+	u32 eax = cpuid_eax(CPUID_PROCESSOR_SIGNATURE);
+	switch (eax & CPUID_XFAM) {
+	case CPUID_XFAM_K8:
+		if ((eax & CPUID_XMOD) < CPUID_XMOD_REV_F)
+			break;
+	case CPUID_XFAM_10H:
+	case CPUID_XFAM_11H:
+		rdmsr(MSR_K8_ENABLE_C1E, lo, hi);
+		if (lo & ENABLE_C1E_MASK)
+			return 1;
+                break;
+        default:
+                /* err on the side of caution */
+		return 1;
+        }
+	return 0;
+}
+
+static __init int apic_timer_broken(void)
+{
+	if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+		return amd_apic_timer_broken();
+	return 0;
+}
+
 /*
  * Setup the boot APIC
  *
@@ -372,12 +384,12 @@ void __init setup_boot_APIC_clock(void)
 	long delta, deltapm;
 	int pm_referenced = 0;
 
-	/* Detect know broken systems */
-	dmi_check_system(broken_bios_dmi_table);
+	if (apic_timer_broken())
+		local_apic_timer_disabled = 1;
 
 	/*
 	 * The local apic timer can be disabled via the kernel
-	 * commandline or from the dmi quirk above. Register the lapic
+	 * commandline or from the test above. Register the lapic
 	 * timer as a dummy clock event source on SMP systems, so the
 	 * broadcast mechanism is used. On UP systems simply ignore it.
 	 */
Index: linux/include/asm-i386/msr.h
===================================================================
--- linux.orig/include/asm-i386/msr.h
+++ linux/include/asm-i386/msr.h
@@ -275,6 +275,8 @@ static inline void wrmsr_on_cpu(unsigned
 #define MSR_K7_FID_VID_CTL		0xC0010041
 #define MSR_K7_FID_VID_STATUS		0xC0010042
 
+#define MSR_K8_ENABLE_C1E		0xC0010055
+
 /* extended feature register */
 #define MSR_EFER 			0xc0000080
 

Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"

[Linus Torvalds]

On Thu, 29 Mar 2007, Andi Kleen wrote:
> 
> Here's a patch. I don't have a system with C1E, so i only tested that
> the apic timer still works on a older AMD box.

I think this looks better than what we have now, but it would look even 
better if the core CPUID stuff was in arch/i386/kernel/cpu/amd.c, and we 
simply had X86_FEATURE_BROKEN_C1_LAPIC etc..

And then the apic.c code would just check

	if (boot_cpu_has(X86_FEATURE_BROKEN_C1_LAPIC))
		return -1;

or similar.

Doing the same for C2 and C3 gives us a clean way to have all these 
per-vendor things in their relevant places, rather than having various 
vendor-specific checks sprinkled in random places..

That's *especially* true for something like this that can hit both on 
x86-64 and i386, where the cpuid logic is shared, but the APIC logic is 
*not* shared. If I read your patch correctly, this only fixes it on 32-bit 
platforms, and I don't think the problem is in any way 32-bit specific, is 
it?

		Linus

Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"

[Grzegorz Chwesewicz]

On Thu, 29 Mar 2007 22:49:37 +0200, Andi Kleen wrote
> > Reviewed but not tested.  Needs to be wrapped in an AMD specific
> > call.
> 
> Here's a patch. I don't have a system with C1E, so i only tested that
> the apic timer still works on a older AMD box.
> 
> Would be good if someone with a Turion laptop, especially the HP nx6325
> could test it with CONFIG_NO_HZ enabled.

I have nx6325 with Turion.

ensima-hp linux-2.6 # cat .config|grep NO_HZ
CONFIG_NO_HZ=y

After patching system works ok on battery and on AC.

On battery:

cat /proc/interrupts

           CPU0       CPU1
  0:     115771          0  local-APIC-edge-fasteoi   timer
  1:        508          1   IO-APIC-edge      i8042
  8:          1          1   IO-APIC-edge      rtc
 12:        147          2   IO-APIC-edge      i8042
 14:         36          1   IO-APIC-edge      ide0
 16:          0          1   IO-APIC-fasteoi   yenta, sdhci:slot0
 17:       4538        116   IO-APIC-fasteoi   eth0
 18:       1697          6   IO-APIC-fasteoi   libata, HDA Intel
 19:         50          1   IO-APIC-fasteoi   ohci_hcd:usb1, ohci_hcd:usb2,
ehci_hcd:usb3
 21:         30          9   IO-APIC-fasteoi   acpi
NMI:          0          0
LOC:          0     115601
ERR:          1
MIS:          0

sleep 10

           CPU0       CPU1
  0:     125777          0  local-APIC-edge-fasteoi   timer
  1:        509          1   IO-APIC-edge      i8042
  8:          1          1   IO-APIC-edge      rtc
 12:        147          2   IO-APIC-edge      i8042
 14:         36          1   IO-APIC-edge      ide0
 16:          0          1   IO-APIC-fasteoi   yenta, sdhci:slot0
 17:       4749        116   IO-APIC-fasteoi   eth0
 18:       1704          6   IO-APIC-fasteoi   libata, HDA Intel
 19:         50          1   IO-APIC-fasteoi   ohci_hcd:usb1, ohci_hcd:usb2,
ehci_hcd:usb3
 21:         30          9   IO-APIC-fasteoi   acpi
NMI:          0          0
LOC:          0     125607
ERR:          1
MIS:          0

#######################################

On AC:

cat /proc/interrupts

           CPU0       CPU1
  0:        261          0  local-APIC-edge-fasteoi   timer
  1:        346          1   IO-APIC-edge      i8042
  8:          1          1   IO-APIC-edge      rtc
 12:        147          2   IO-APIC-edge      i8042
 14:         36          1   IO-APIC-edge      ide0
 16:          0          1   IO-APIC-fasteoi   yenta, sdhci:slot0
 17:       1135        115   IO-APIC-fasteoi   eth0
 18:       1620          6   IO-APIC-fasteoi   libata, HDA Intel
 19:         50          1   IO-APIC-fasteoi   ohci_hcd:usb1, ehci_hcd:usb2,
ohci_hcd:usb3
 21:         24          9   IO-APIC-fasteoi   acpi
NMI:          0          0
LOC:       7562       9007
ERR:          0
MIS:          0

sleep 10

           CPU0       CPU1
  0:        261          0  local-APIC-edge-fasteoi   timer
  1:        347          1   IO-APIC-edge      i8042
  8:          1          1   IO-APIC-edge      rtc
 12:        147          2   IO-APIC-edge      i8042
 14:         36          1   IO-APIC-edge      ide0
 16:          0          1   IO-APIC-fasteoi   yenta, sdhci:slot0
 17:       1411        115   IO-APIC-fasteoi   eth0
 18:       1627          6   IO-APIC-fasteoi   libata, HDA Intel
 19:         50          1   IO-APIC-fasteoi   ohci_hcd:usb1, ehci_hcd:usb2,
ohci_hcd:usb3
 21:         24          9   IO-APIC-fasteoi   acpi
NMI:          0          0
LOC:       7592       9184
ERR:          0
MIS:          0

--
Greetings - CeHo - Grzegorz Chwesewicz

Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"

[Andreas Mohr]

Hi,

On Thu, Mar 29, 2007 at 02:16:54PM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 29 Mar 2007, Andi Kleen wrote:
> > 
> > Here's a patch. I don't have a system with C1E, so i only tested that
> > the apic timer still works on a older AMD box.
> 
> I think this looks better than what we have now, but it would look even 
> better if the core CPUID stuff was in arch/i386/kernel/cpu/amd.c, and we 
> simply had X86_FEATURE_BROKEN_C1_LAPIC etc..

Please don't, this would break the interface logically.
X86_FEATURE_xxx usually denotes a *feature*, not a "feature"
(Micro$oft speak for "bug" ;).
IOW most flags express a positive attribute, not a negative one.
An exception to this probably is X86_FEATURE_FXSAVE_LEAK and
X86_FEATURE_CMP_LEGACY, but all others seem to be positive, so we might
want to enforce this rule.

Thus, how about e.g. X86_FEATURE_LAPIC_C1_OK?
Or is this less precise from a "C1 working ok" detection point of view?
(i.e. we'd just assume by default that most machines are ok except the ones
where we have issue detection code for, which might be too fuzzy)

Andreas Mohr

Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"

[Grzegorz Chwesewicz]

On Thu, 29 Mar 2007 23:43:28 +0200, Grzegorz Chwesewicz wrote
> On Thu, 29 Mar 2007 22:49:37 +0200, Andi Kleen wrote
> > > Reviewed but not tested.  Needs to be wrapped in an AMD specific
> > > call.
> > 
> > Here's a patch. I don't have a system with C1E, so i only tested that
> > the apic timer still works on a older AMD box.
> > 
> > Would be good if someone with a Turion laptop, especially the HP nx6325
> > could test it with CONFIG_NO_HZ enabled.
> 
> I have nx6325 with Turion.
> 
> ensima-hp linux-2.6 # cat .config|grep NO_HZ
> CONFIG_NO_HZ=y
> 
> After patching system works ok on battery and on AC.
> 
<cut>

Bootlogs on AC and battery can be found here:
http://bugzilla.kernel.org/show_bug.cgi?id=8235


--
Greetings - CeHo - Grzegorz Chwesewicz

Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"

[Linus Torvalds]

On Thu, 29 Mar 2007, Andreas Mohr wrote:
> 
> Please don't, this would break the interface logically.
> X86_FEATURE_xxx usually denotes a *feature*, not a "feature"
> (Micro$oft speak for "bug" ;).

Sure, we could  make it positive instead, and I agree it would make code 
nicer to read.

> Thus, how about e.g. X86_FEATURE_LAPIC_C1_OK?

I have no trouble at all with something like that instead. Anybody willing 
to cook up a patch?

		Linus

Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"

[Andi Kleen]

On Thursday 29 March 2007 23:16, Linus Torvalds wrote:
> 
> On Thu, 29 Mar 2007, Andi Kleen wrote:
> > 
> > Here's a patch. I don't have a system with C1E, so i only tested that
> > the apic timer still works on a older AMD box.
> 
> I think this looks better than what we have now, but it would look even 
> better if the core CPUID stuff was in arch/i386/kernel/cpu/amd.c, and we 
> simply had X86_FEATURE_BROKEN_C1_LAPIC etc..
> 
> And then the apic.c code would just check
> 
> 	if (boot_cpu_has(X86_FEATURE_BROKEN_C1_LAPIC))
> 		return -1;
> 
> or similar.

Ok fair point. Here's an updated patch.

> 
> Doing the same for C2 and C3 gives us a clean way to have all these 
> per-vendor things in their relevant places, rather than having various 
> vendor-specific checks sprinkled in random places..
> 
> That's *especially* true for something like this that can hit both on 
> x86-64 and i386, where the cpuid logic is shared,

It's not shared.

> but the APIC logic is  
> *not* shared. If I read your patch correctly, this only fixes it on 32-bit 
> platforms, and I don't think the problem is in any way 32-bit specific, is 
> it?

It is because 64bit doesn't have dyntick yet and doesn't try to use the lapic
timer only by default. It has a "apicmaintimer" option, but that is never set
automatically. When dyntick is ported over it will be needed there too.

-Andi

Disable local APIC timer use on AMD systems with C1E

AMD dual core laptops with C1E do not run the APIC timer correctly
when they go idle. Previously the code assumed this only happened
on C2 or deeper.  But not all of these systems report support C2.

Use a AMD supplied snippet to detect C1E being enabled and then disable
local apic timer use.

This supercedes an earlier workaround using DMI detection of specific systems.

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

Index: linux/arch/i386/kernel/apic.c
===================================================================
--- linux.orig/arch/i386/kernel/apic.c
+++ linux/arch/i386/kernel/apic.c
@@ -272,32 +272,6 @@ static void __devinit setup_APIC_timer(v
 }
 
 /*
- * Detect systems with known broken BIOS implementations
- */
-static int __init lapic_check_broken_bios(struct dmi_system_id *d)
-{
-	printk(KERN_NOTICE "%s detected: disabling lapic timer.\n",
-		       d->ident);
-	local_apic_timer_disabled = 1;
-	return 0;
-}
-
-static struct dmi_system_id __initdata broken_bios_dmi_table[] = {
-	{
-		/*
-		 * BIOS exports only C1 state, but uses deeper power
-		 * modes behind the kernels back.
-		 */
-		  .callback = lapic_check_broken_bios,
-		  .ident = "HP nx6325",
-		  .matches = {
-			DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq nx6325"),
-		  },
-	 },
-	 {}
-};
-
-/*
  * In this functions we calibrate APIC bus clocks to the external timer.
  *
  * We want to do the calibration only once since we want to have local timer
@@ -372,12 +346,12 @@ void __init setup_boot_APIC_clock(void)
 	long delta, deltapm;
 	int pm_referenced = 0;
 
-	/* Detect know broken systems */
-	dmi_check_system(broken_bios_dmi_table);
+	if (boot_cpu_has(X86_FEATURE_LAPIC_TIMER_BROKEN))
+		local_apic_timer_disabled = 1;
 
 	/*
 	 * The local apic timer can be disabled via the kernel
-	 * commandline or from the dmi quirk above. Register the lapic
+	 * commandline or from the test above. Register the lapic
 	 * timer as a dummy clock event source on SMP systems, so the
 	 * broadcast mechanism is used. On UP systems simply ignore it.
 	 */
Index: linux/include/asm-i386/msr.h
===================================================================
--- linux.orig/include/asm-i386/msr.h
+++ linux/include/asm-i386/msr.h
@@ -275,6 +275,8 @@ static inline void wrmsr_on_cpu(unsigned
 #define MSR_K7_FID_VID_CTL		0xC0010041
 #define MSR_K7_FID_VID_STATUS		0xC0010042
 
+#define MSR_K8_ENABLE_C1E		0xC0010055
+
 /* extended feature register */
 #define MSR_EFER 			0xc0000080
 
Index: linux/arch/i386/kernel/cpu/amd.c
===================================================================
--- linux.orig/arch/i386/kernel/cpu/amd.c
+++ linux/arch/i386/kernel/cpu/amd.c
@@ -22,6 +22,37 @@
 extern void vide(void);
 __asm__(".align 4\nvide: ret");
 
+#define ENABLE_C1E_MASK         0x18000000
+#define CPUID_PROCESSOR_SIGNATURE       1
+#define CPUID_XFAM              0x0ff00000
+#define CPUID_XFAM_K8           0x00000000
+#define CPUID_XFAM_10H          0x00100000
+#define CPUID_XFAM_11H          0x00200000
+#define CPUID_XMOD              0x000f0000
+#define CPUID_XMOD_REV_F        0x00040000
+
+/* AMD systems with C1E don't have a working lAPIC timer. Check for that. */
+static __cpuinit int amd_apic_timer_broken(void)
+{
+	u32 lo, hi;
+	u32 eax = cpuid_eax(CPUID_PROCESSOR_SIGNATURE);
+	switch (eax & CPUID_XFAM) {
+	case CPUID_XFAM_K8:
+		if ((eax & CPUID_XMOD) < CPUID_XMOD_REV_F)
+			break;
+	case CPUID_XFAM_10H:
+	case CPUID_XFAM_11H:
+		rdmsr(MSR_K8_ENABLE_C1E, lo, hi);
+		if (lo & ENABLE_C1E_MASK)
+			return 1;
+                break;
+        default:
+                /* err on the side of caution */
+		return 1;
+        }
+	return 0;
+}
+
 static void __cpuinit init_amd(struct cpuinfo_x86 *c)
 {
 	u32 l, h;
@@ -241,6 +272,9 @@ static void __cpuinit init_amd(struct cp
 
 	if (cpuid_eax(0x80000000) >= 0x80000006)
 		num_cache_leaves = 3;
+
+	if (amd_apic_timer_broken())
+		set_bit(X86_FEATURE_LAPIC_TIMER_BROKEN, c->x86_capability);
 }
 
 static unsigned int __cpuinit amd_size_cache(struct cpuinfo_x86 * c, unsigned int size)
Index: linux/include/asm-i386/cpufeature.h
===================================================================
--- linux.orig/include/asm-i386/cpufeature.h
+++ linux/include/asm-i386/cpufeature.h
@@ -75,6 +75,7 @@
 #define X86_FEATURE_ARCH_PERFMON (3*32+11) /* Intel Architectural PerfMon */
 #define X86_FEATURE_PEBS	(3*32+12)  /* Precise-Event Based Sampling */
 #define X86_FEATURE_BTS		(3*32+13)  /* Branch Trace Store */
+#define X86_FEATURE_LAPIC_TIMER_BROKEN (3*32+ 14) /* lapic timer broken in C1 */
 
 /* Intel-defined CPU features, CPUID level 0x00000001 (ecx), word 4 */
 #define X86_FEATURE_XMM3	(4*32+ 0) /* Streaming SIMD Extensions-3 */

Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"

[Andi Kleen]

On Thursday 29 March 2007 23:45, Andreas Mohr wrote:
> Hi,
> 
> On Thu, Mar 29, 2007 at 02:16:54PM -0700, Linus Torvalds wrote:
> > 
> > 
> > On Thu, 29 Mar 2007, Andi Kleen wrote:
> > > 
> > > Here's a patch. I don't have a system with C1E, so i only tested that
> > > the apic timer still works on a older AMD box.
> > 
> > I think this looks better than what we have now, but it would look even 
> > better if the core CPUID stuff was in arch/i386/kernel/cpu/amd.c, and we 
> > simply had X86_FEATURE_BROKEN_C1_LAPIC etc..
> 
> Please don't, this would break the interface logically.

We already have several of those. And negative is much easier. 

-Andi

Re: [linux-pm] [3/6] 2.6.21-rc4: known regressions

[David Brownell]

On Wednesday 28 March 2007 2:27 pm, Maxim wrote:
> On Wednesday 28 March 2007 22:59:26 David Brownell wrote:

> 	When HPET is active it eats RTC IRQ,

Only when HPET timers 0 and 1 are set up for "Legacy Replacement Mode".
In the more sensible "Standard Mode", they have their own IRQs.


> 	So the only way out is to emulate RTC using HPET,
> 	It is done this way in old rtc driver, rtc-cmos should do the same.

No.  Patches like

  http://marc.info/?l=linux-kernel&m=117219531503973&w=2

should be merged (I hope they're in the 2.6.22 queue!), making
HPET run in "Standard Mode" so that HPET can stop sticking its
fingers in code where they don't belong.


> 	I am also planning to add support of HPET and suspend/resume
> 	for rtc-cmos, but I didn't start this yet. 

It's already got suspend/resume support, and in the 2.6.22 queue
are RTC framework updates which will let the RTC framework replace
a lot more platform-specific RTC support.  (Platform changes can come
later, where they're needed.  ARM for example doesn't need any.)

Once HPET stops using "Legacy Replacement Mode" you won't need to
touch anything in the RTC stack (except maybe the legacy char/rtc.c
driver, removing HPET stuff).

The open issue with suspend/resume support in rtc-cmos relates to
how ACPI wakeup alarms should trigger.  I've not made time to test
those patches.

- Dave

Re: [3/6] 2.6.21-rc4: known regressions

[David Brownell]

On Wednesday 28 March 2007 2:27 pm, Maxim wrote:
> On Wednesday 28 March 2007 22:59:26 David Brownell wrote:

> 	When HPET is active it eats RTC IRQ,

Only when HPET timers 0 and 1 are set up for "Legacy Replacement Mode".
In the more sensible "Standard Mode", they have their own IRQs.


> 	So the only way out is to emulate RTC using HPET,
> 	It is done this way in old rtc driver, rtc-cmos should do the same.

No.  Patches like

  http://marc.info/?l=linux-kernel&m=117219531503973&w=2

should be merged (I hope they're in the 2.6.22 queue!), making
HPET run in "Standard Mode" so that HPET can stop sticking its
fingers in code where they don't belong.


> 	I am also planning to add support of HPET and suspend/resume
> 	for rtc-cmos, but I didn't start this yet. 

It's already got suspend/resume support, and in the 2.6.22 queue
are RTC framework updates which will let the RTC framework replace
a lot more platform-specific RTC support.  (Platform changes can come
later, where they're needed.  ARM for example doesn't need any.)

Once HPET stops using "Legacy Replacement Mode" you won't need to
touch anything in the RTC stack (except maybe the legacy char/rtc.c
driver, removing HPET stuff).

The open issue with suspend/resume support in rtc-cmos relates to
how ACPI wakeup alarms should trigger.  I've not made time to test
those patches.

- Dave

Re: [3/6] 2.6.21-rc4: known regressions

[Maxim Levitsky]

On Friday 30 March 2007 00:33:35 David Brownell wrote:
> On Wednesday 28 March 2007 2:27 pm, Maxim wrote:
> > On Wednesday 28 March 2007 22:59:26 David Brownell wrote:
> 
> > 	When HPET is active it eats RTC IRQ,
> 
> Only when HPET timers 0 and 1 are set up for "Legacy Replacement Mode".
> In the more sensible "Standard Mode", they have their own IRQs.
> 
> 
> > 	So the only way out is to emulate RTC using HPET,
> > 	It is done this way in old rtc driver, rtc-cmos should do the same.
> 
> No.  Patches like
> 
>   http://marc.info/?l=linux-kernel&m=117219531503973&w=2
> 
> should be merged (I hope they're in the 2.6.22 queue!), making
> HPET run in "Standard Mode" so that HPET can stop sticking its
> fingers in code where they don't belong.
> 
> 
> > 	I am also planning to add support of HPET and suspend/resume
> > 	for rtc-cmos, but I didn't start this yet. 
> 
> It's already got suspend/resume support, and in the 2.6.22 queue
> are RTC framework updates which will let the RTC framework replace
> a lot more platform-specific RTC support.  (Platform changes can come
> later, where they're needed.  ARM for example doesn't need any.)
> 
> Once HPET stops using "Legacy Replacement Mode" you won't need to
> touch anything in the RTC stack (except maybe the legacy char/rtc.c
> driver, removing HPET stuff).
> 
> The open issue with suspend/resume support in rtc-cmos relates to
> how ACPI wakeup alarms should trigger.  I've not made time to test
> those patches.
> 
> - Dave
> 

Hi,
	It is not that simple,

	Only in legacy replacement mode HPET can be put on IRQ0 (and sadly  IRQ8)
	At least this is true on some systems, on mine for example
	
	On my system first 2 hpet timers can only be assigned to IRQ21-23
	and third to ether IRQ11, IRQ21-IRQ23

	Or in legacy replacement mode first is assigned IRQ0 and second IRQ8

	this will make it difficult to use it as a clockevents source

	Not to mention the fact that current code assumes that BIOS assigned IRQs to all timers which is not true on my system.

	I have brand new intel DG965 motherboard.

	What is wrong with relying on HPET to provide RTC IRQ ?

	Best regards,
		Maxim Levitsky

Re: [linux-pm] [3/6] 2.6.21-rc4: known regressions

[Maxim Levitsky]

On Friday 30 March 2007 00:33:35 David Brownell wrote:
> On Wednesday 28 March 2007 2:27 pm, Maxim wrote:
> > On Wednesday 28 March 2007 22:59:26 David Brownell wrote:
> 
> > 	When HPET is active it eats RTC IRQ,
> 
> Only when HPET timers 0 and 1 are set up for "Legacy Replacement Mode".
> In the more sensible "Standard Mode", they have their own IRQs.
> 
> 
> > 	So the only way out is to emulate RTC using HPET,
> > 	It is done this way in old rtc driver, rtc-cmos should do the same.
> 
> No.  Patches like
> 
>   http://marc.info/?l=linux-kernel&m=117219531503973&w=2
> 
> should be merged (I hope they're in the 2.6.22 queue!), making
> HPET run in "Standard Mode" so that HPET can stop sticking its
> fingers in code where they don't belong.
> 
> 
> > 	I am also planning to add support of HPET and suspend/resume
> > 	for rtc-cmos, but I didn't start this yet. 
> 
> It's already got suspend/resume support, and in the 2.6.22 queue
> are RTC framework updates which will let the RTC framework replace
> a lot more platform-specific RTC support.  (Platform changes can come
> later, where they're needed.  ARM for example doesn't need any.)
> 
> Once HPET stops using "Legacy Replacement Mode" you won't need to
> touch anything in the RTC stack (except maybe the legacy char/rtc.c
> driver, removing HPET stuff).
> 
> The open issue with suspend/resume support in rtc-cmos relates to
> how ACPI wakeup alarms should trigger.  I've not made time to test
> those patches.
> 
> - Dave
> 

Hi,
	It is not that simple,

	Only in legacy replacement mode HPET can be put on IRQ0 (and sadly  IRQ8)
	At least this is true on some systems, on mine for example
	
	On my system first 2 hpet timers can only be assigned to IRQ21-23
	and third to ether IRQ11, IRQ21-IRQ23

	Or in legacy replacement mode first is assigned IRQ0 and second IRQ8

	this will make it difficult to use it as a clockevents source

	Not to mention the fact that current code assumes that BIOS assigned IRQs to all timers which is not true on my system.

	I have brand new intel DG965 motherboard.

	What is wrong with relying on HPET to provide RTC IRQ ?

	Best regards,
		Maxim Levitsky

Re: [linux-pm] [3/6] 2.6.21-rc4: known regressions

[David Brownell]

On Thursday 29 March 2007 4:29 pm, Maxim Levitsky wrote:
> On Friday 30 March 2007 00:33:35 David Brownell wrote:
> > On Wednesday 28 March 2007 2:27 pm, Maxim wrote:

> > > 	So the only way out is to emulate RTC using HPET,
> > > 	It is done this way in old rtc driver, rtc-cmos should do the same.
> > 
> > No.  Patches like
> > 
> >   http://marc.info/?l=linux-kernel&m=117219531503973&w=2

also:   http://marc.info/?l=linux-kernel&m=117219531526317&w=2

> > should be merged (I hope they're in the 2.6.22 queue!), making
> > HPET run in "Standard Mode" so that HPET can stop sticking its
> > fingers in code where they don't belong.
> >
> > ...
>
> 	It is not that simple,
> 
> 	Only in legacy replacement mode HPET can be put on IRQ0 (and sadly  IRQ8)
> 	At least this is true on some systems, on mine for example

Right, that's the entire point of legacy replacement mode.

But so what?  In standard mode, HPET just uses other IRQs.
Nothing would care about irq0, and irq8 would be used by
the RTC as necessary.


> 	this will make it difficult to use it as a clockevents source

Why?  It's not like the clockevent logic cares what IRQ a given
programmable timer uses.  So long as the HPET driver can receive
its IRQ, it'll make a fine clockevent.  There's no reason to have
HPET prevent other drivers from working, by insisting it use that
nasty "prevent other hardware from issuing IRQs" mode.

The patches from Venkatesh sure seem to have behaved for him.
And while he might have complained about difficulty, I think
that'd be more likely due to the SMP issues he also addressed
than because of some (historical?) attachment to irq0.


> 	Not to mention the fact that current code assumes that BIOS
> 	assigned IRQs to all timers which is not true on my system. 

Getting IRQ routing sorted out is a problem that's been solved
numerous times before.  And again, the patches referenced above
seem to have resolved any such issues.


> 	What is wrong with relying on HPET to provide RTC IRQ ?

For starters, it's not an RTC.  Why in the world would you want to
make the OS think it's an RTC ... unless you're Microsoft, and are
desperate to get another periodic timer (and don't much care about
the other RTC functionality?


... that's all off-topic for 2.6.21 regressions though; it's too
late to merge x86_64 clockevent support, or fix HPET issues like
not using "standard mode".

- Dave

Re: [3/6] 2.6.21-rc4: known regressions

[David Brownell]

On Thursday 29 March 2007 4:29 pm, Maxim Levitsky wrote:
> On Friday 30 March 2007 00:33:35 David Brownell wrote:
> > On Wednesday 28 March 2007 2:27 pm, Maxim wrote:

> > > 	So the only way out is to emulate RTC using HPET,
> > > 	It is done this way in old rtc driver, rtc-cmos should do the same.
> > 
> > No.  Patches like
> > 
> >   http://marc.info/?l=linux-kernel&m=117219531503973&w=2

also:   http://marc.info/?l=linux-kernel&m=117219531526317&w=2

> > should be merged (I hope they're in the 2.6.22 queue!), making
> > HPET run in "Standard Mode" so that HPET can stop sticking its
> > fingers in code where they don't belong.
> >
> > ...
>
> 	It is not that simple,
> 
> 	Only in legacy replacement mode HPET can be put on IRQ0 (and sadly  IRQ8)
> 	At least this is true on some systems, on mine for example

Right, that's the entire point of legacy replacement mode.

But so what?  In standard mode, HPET just uses other IRQs.
Nothing would care about irq0, and irq8 would be used by
the RTC as necessary.


> 	this will make it difficult to use it as a clockevents source

Why?  It's not like the clockevent logic cares what IRQ a given
programmable timer uses.  So long as the HPET driver can receive
its IRQ, it'll make a fine clockevent.  There's no reason to have
HPET prevent other drivers from working, by insisting it use that
nasty "prevent other hardware from issuing IRQs" mode.

The patches from Venkatesh sure seem to have behaved for him.
And while he might have complained about difficulty, I think
that'd be more likely due to the SMP issues he also addressed
than because of some (historical?) attachment to irq0.


> 	Not to mention the fact that current code assumes that BIOS
> 	assigned IRQs to all timers which is not true on my system. 

Getting IRQ routing sorted out is a problem that's been solved
numerous times before.  And again, the patches referenced above
seem to have resolved any such issues.


> 	What is wrong with relying on HPET to provide RTC IRQ ?

For starters, it's not an RTC.  Why in the world would you want to
make the OS think it's an RTC ... unless you're Microsoft, and are
desperate to get another periodic timer (and don't much care about
the other RTC functionality?


... that's all off-topic for 2.6.21 regressions though; it's too
late to merge x86_64 clockevent support, or fix HPET issues like
not using "standard mode".

- Dave

Re: [3/6] 2.6.21-rc4: known regressions

[Maxim Levitsky]

On Friday 30 March 2007 03:09:14 David Brownell wrote:
> On Thursday 29 March 2007 4:29 pm, Maxim Levitsky wrote:
> > On Friday 30 March 2007 00:33:35 David Brownell wrote:
> > > On Wednesday 28 March 2007 2:27 pm, Maxim wrote:
> 
> > > > 	So the only way out is to emulate RTC using HPET,
> > > > 	It is done this way in old rtc driver, rtc-cmos should do the same.
> > > 
> > > No.  Patches like
> > > 
> > >   http://marc.info/?l=linux-kernel&m=117219531503973&w=2
> 
> also:   http://marc.info/?l=linux-kernel&m=117219531526317&w=2
> 
> > > should be merged (I hope they're in the 2.6.22 queue!), making
> > > HPET run in "Standard Mode" so that HPET can stop sticking its
> > > fingers in code where they don't belong.
> > >
> > > ...
> >
> > 	It is not that simple,
> > 
> > 	Only in legacy replacement mode HPET can be put on IRQ0 (and sadly  IRQ8)
> > 	At least this is true on some systems, on mine for example
> 
> Right, that's the entire point of legacy replacement mode.
> 
> But so what?  In standard mode, HPET just uses other IRQs.
> Nothing would care about irq0, and irq8 would be used by
> the RTC as necessary.
> 
> 
> > 	this will make it difficult to use it as a clockevents source
> 
> Why?  It's not like the clockevent logic cares what IRQ a given
> programmable timer uses.  So long as the HPET driver can receive
> its IRQ, it'll make a fine clockevent.  There's no reason to have
> HPET prevent other drivers from working, by insisting it use that
> nasty "prevent other hardware from issuing IRQs" mode.
> 
> The patches from Venkatesh sure seem to have behaved for him.
> And while he might have complained about difficulty, I think
> that'd be more likely due to the SMP issues he also addressed
> than because of some (historical?) attachment to irq0.
> 
> 
> > 	Not to mention the fact that current code assumes that BIOS
> > 	assigned IRQs to all timers which is not true on my system. 
> 
> Getting IRQ routing sorted out is a problem that's been solved
> numerous times before.  And again, the patches referenced above
> seem to have resolved any such issues.
No they don't, 

First patch does that:

                        hd.hd_irq[i] = (timer->hpet_config &
                                        Tn_INT_ROUTE_CNF_MASK) >>                                
					Tn_INT_ROUTE_CNF_SHIFT;

This just reads values assigned by BIOS.


> 
> 
> > 	What is wrong with relying on HPET to provide RTC IRQ ?
> 
> For starters, it's not an RTC.  Why in the world would you want to
> make the OS think it's an RTC ... unless you're Microsoft, and are
> desperate to get another periodic timer (and don't much care about
> the other RTC functionality?
> 
> 
> ... that's all off-topic for 2.6.21 regressions though; it's too
> late to merge x86_64 clockevent support, or fix HPET issues like
> not using "standard mode".
> 
> - Dave
> 
> 

Hi,
	I feel that you are right,

	You meant that one of HPET timers will be used as clock source and will be assigned some IRQ (not IRQ0)
	
	Seems fine,

	Only one thing: the kernel must assign IRQs to HPETS , relying on bios is not good,
	Also the IRQ for clocksource should be not shared, but maybe I am wrong here 
	(I am afraid that latencies might be a problem here)

	By the way I never thought about the fact that legacy replacement mode  is a 'virtual legacy'

	I mean that it is intended to simulate RTCs and PITs on systems that don't have them, am I right here ?
	HPET spec says that RTC is still requred to provide all its usial functions except periodic freq.

	Best regards,
		Maxim Levitsky

Re: [linux-pm] [3/6] 2.6.21-rc4: known regressions

[Maxim Levitsky]

On Friday 30 March 2007 03:09:14 David Brownell wrote:
> On Thursday 29 March 2007 4:29 pm, Maxim Levitsky wrote:
> > On Friday 30 March 2007 00:33:35 David Brownell wrote:
> > > On Wednesday 28 March 2007 2:27 pm, Maxim wrote:
> 
> > > > 	So the only way out is to emulate RTC using HPET,
> > > > 	It is done this way in old rtc driver, rtc-cmos should do the same.
> > > 
> > > No.  Patches like
> > > 
> > >   http://marc.info/?l=linux-kernel&m=117219531503973&w=2
> 
> also:   http://marc.info/?l=linux-kernel&m=117219531526317&w=2
> 
> > > should be merged (I hope they're in the 2.6.22 queue!), making
> > > HPET run in "Standard Mode" so that HPET can stop sticking its
> > > fingers in code where they don't belong.
> > >
> > > ...
> >
> > 	It is not that simple,
> > 
> > 	Only in legacy replacement mode HPET can be put on IRQ0 (and sadly  IRQ8)
> > 	At least this is true on some systems, on mine for example
> 
> Right, that's the entire point of legacy replacement mode.
> 
> But so what?  In standard mode, HPET just uses other IRQs.
> Nothing would care about irq0, and irq8 would be used by
> the RTC as necessary.
> 
> 
> > 	this will make it difficult to use it as a clockevents source
> 
> Why?  It's not like the clockevent logic cares what IRQ a given
> programmable timer uses.  So long as the HPET driver can receive
> its IRQ, it'll make a fine clockevent.  There's no reason to have
> HPET prevent other drivers from working, by insisting it use that
> nasty "prevent other hardware from issuing IRQs" mode.
> 
> The patches from Venkatesh sure seem to have behaved for him.
> And while he might have complained about difficulty, I think
> that'd be more likely due to the SMP issues he also addressed
> than because of some (historical?) attachment to irq0.
> 
> 
> > 	Not to mention the fact that current code assumes that BIOS
> > 	assigned IRQs to all timers which is not true on my system. 
> 
> Getting IRQ routing sorted out is a problem that's been solved
> numerous times before.  And again, the patches referenced above
> seem to have resolved any such issues.
No they don't, 

First patch does that:

                        hd.hd_irq[i] = (timer->hpet_config &
                                        Tn_INT_ROUTE_CNF_MASK) >>                                
					Tn_INT_ROUTE_CNF_SHIFT;

This just reads values assigned by BIOS.


> 
> 
> > 	What is wrong with relying on HPET to provide RTC IRQ ?
> 
> For starters, it's not an RTC.  Why in the world would you want to
> make the OS think it's an RTC ... unless you're Microsoft, and are
> desperate to get another periodic timer (and don't much care about
> the other RTC functionality?
> 
> 
> ... that's all off-topic for 2.6.21 regressions though; it's too
> late to merge x86_64 clockevent support, or fix HPET issues like
> not using "standard mode".
> 
> - Dave
> 
> 

Hi,
	I feel that you are right,

	You meant that one of HPET timers will be used as clock source and will be assigned some IRQ (not IRQ0)
	
	Seems fine,

	Only one thing: the kernel must assign IRQs to HPETS , relying on bios is not good,
	Also the IRQ for clocksource should be not shared, but maybe I am wrong here 
	(I am afraid that latencies might be a problem here)

	By the way I never thought about the fact that legacy replacement mode  is a 'virtual legacy'

	I mean that it is intended to simulate RTCs and PITs on systems that don't have them, am I right here ?
	HPET spec says that RTC is still requred to provide all its usial functions except periodic freq.

	Best regards,
		Maxim Levitsky

Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"

[Grzegorz Chwesewicz]

On Fri, 30 Mar 2007 00:05:39 +0200, Andi Kleen wrote
> On Thursday 29 March 2007 23:16, Linus Torvalds wrote:
> > 
> > On Thu, 29 Mar 2007, Andi Kleen wrote:
> > > 
> > > Here's a patch. I don't have a system with C1E, so i only tested that
> > > the apic timer still works on a older AMD box.
> > 
> > I think this looks better than what we have now, but it would look even 
> > better if the core CPUID stuff was in arch/i386/kernel/cpu/amd.c, and we 
> > simply had X86_FEATURE_BROKEN_C1_LAPIC etc..
> > 
> > And then the apic.c code would just check
> > 
> > 	if (boot_cpu_has(X86_FEATURE_BROKEN_C1_LAPIC))
> > 		return -1;
> > 
> > or similar.
> 
> Ok fair point. Here's an updated patch.

This patch also works. If You want bootlog or output of /proc/interrupts I can
post it.

--
Greetings - CeHo - Grzegorz Chwesewicz

Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"

[Grzegorz Chwesewicz]

On Fri, 30 Mar 2007 00:05:39 +0200, Andi Kleen wrote
> On Thursday 29 March 2007 23:16, Linus Torvalds wrote:
> > 
> > On Thu, 29 Mar 2007, Andi Kleen wrote:
> > > 
> > > Here's a patch. I don't have a system with C1E, so i only tested that
> > > the apic timer still works on a older AMD box.
> > 
> > I think this looks better than what we have now, but it would look even 
> > better if the core CPUID stuff was in arch/i386/kernel/cpu/amd.c, and we 
> > simply had X86_FEATURE_BROKEN_C1_LAPIC etc..
> > 
> > And then the apic.c code would just check
> > 
> > 	if (boot_cpu_has(X86_FEATURE_BROKEN_C1_LAPIC))
> > 		return -1;
> > 
> > or similar.
> 
> Ok fair point. Here's an updated patch.

I've tested this patch little bit more on my nx6325 and I've found scenario in
which my box works slow. When I boot HP with connected AC (it boots fast), and
then after boot I unplug AC and try to power HP off it's working very slow
(powering off process take few minutes). On battery it's always booting and
powering off fast. Can enybody with nx6325 confirm this ?

--
Greetings - CeHo - Grzegorz Chwesewicz

Re: [PATCH v2] Add suspend/resume for HPET

[Thomas Gleixner]

On Thu, 2007-03-29 at 15:46 +0200, Maxim Levitsky wrote:
> Subject: Add suspend/resume for HPET
> This adds support of suspend/resume on i386 for HPET
> Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
>
> +static struct sysdev_class hpet_class = {
> +	set_kset_name("hpet"),
> +	.suspend	= hpet_suspend,
> +	.resume		= hpet_resume,
> +};
> +
> +static struct sys_device hpet_device = {
> +	.id		= 0,
> +	.cls		= &hpet_class,
> +};

Sorry for being inresponsive. I was travelling and unexpectedly cut off
from the internet for some days.

While I agree in principle with the patch, I'm a bit uncomfortable. The
sys device suspend / resume ordering is not guaranteed and relies on the
registering order.

Jeff still seems to have problems with CONFIG_NO_HZ=n and it might be
caused by time keeping / tick management resume happening before the
HPET resume.

The required resume order is:

clocksources
timekeeping
clockevents
tick management

I'm not sure how to do this properly with the sys device facilities, but
I look into it.

/me goes off to understand the sys device magic.

	tglx

Re: [PATCH v2] Add suspend/resume for HPET

[Thomas Gleixner]

On Thu, 2007-03-29 at 15:46 +0200, Maxim Levitsky wrote:
> Subject: Add suspend/resume for HPET
> This adds support of suspend/resume on i386 for HPET
> Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
>
> +static struct sysdev_class hpet_class = {
> +	set_kset_name("hpet"),
> +	.suspend	= hpet_suspend,
> +	.resume		= hpet_resume,
> +};
> +
> +static struct sys_device hpet_device = {
> +	.id		= 0,
> +	.cls		= &hpet_class,
> +};

Sorry for being inresponsive. I was travelling and unexpectedly cut off
from the internet for some days.

While I agree in principle with the patch, I'm a bit uncomfortable. The
sys device suspend / resume ordering is not guaranteed and relies on the
registering order.

Jeff still seems to have problems with CONFIG_NO_HZ=n and it might be
caused by time keeping / tick management resume happening before the
HPET resume.

The required resume order is:

clocksources
timekeeping
clockevents
tick management

I'm not sure how to do this properly with the sys device facilities, but
I look into it.

/me goes off to understand the sys device magic.

	tglx

Re: [PATCH v2] Add suspend/resume for HPET

[Jeff Chua]

On 3/31/07, Thomas Gleixner <tglx@linutronix.de> wrote:

> Jeff still seems to have problems with CONFIG_NO_HZ=n and it might be
> caused by time keeping / tick management resume happening before the
> HPET resume.


me>Confirmed that suspend/resume disk/ram works on X60s with
me>CONFIG_HPET_TIMER=y and CONFIG_NO_HZ unset.
me> But suspend to disk still hang with CONFIG_NO_HZ unset.


Oops, sorry. Typo (as a result copy/paste using mouse)
    ... I actually meant CONFIG_NO_HZ "set".

Just to be clear, suspend to disk still hang with CONFIG_NO_HZ=y. It
hang just before you see the percent saving %.


Jeff.

Re: [PATCH v2] Add suspend/resume for HPET

[Jeff Chua]

On 3/31/07, Thomas Gleixner <tglx@linutronix.de> wrote:

> Jeff still seems to have problems with CONFIG_NO_HZ=n and it might be
> caused by time keeping / tick management resume happening before the
> HPET resume.


me>Confirmed that suspend/resume disk/ram works on X60s with
me>CONFIG_HPET_TIMER=y and CONFIG_NO_HZ unset.
me> But suspend to disk still hang with CONFIG_NO_HZ unset.


Oops, sorry. Typo (as a result copy/paste using mouse)
    ... I actually meant CONFIG_NO_HZ "set".

Just to be clear, suspend to disk still hang with CONFIG_NO_HZ=y. It
hang just before you see the percent saving %.


Jeff.

Re: [PATCH v2] Add suspend/resume for HPET

[Thomas Gleixner]

On Sun, 2007-04-01 at 00:01 +0800, Jeff Chua wrote:
> On 3/31/07, Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> > Jeff still seems to have problems with CONFIG_NO_HZ=n and it might be
> > caused by time keeping / tick management resume happening before the
> > HPET resume.
> 
> 
> me>Confirmed that suspend/resume disk/ram works on X60s with
> me>CONFIG_HPET_TIMER=y and CONFIG_NO_HZ unset.
> me> But suspend to disk still hang with CONFIG_NO_HZ unset.
> 
> 
> Oops, sorry. Typo (as a result copy/paste using mouse)
>     ... I actually meant CONFIG_NO_HZ "set".
> 
> Just to be clear, suspend to disk still hang with CONFIG_NO_HZ=y. It
> hang just before you see the percent saving %.

Ah, that's a different one then. In that path the timers should be
alive, but who knows.

	tglx

Re: [PATCH v2] Add suspend/resume for HPET

[Linus Torvalds]

On Sat, 31 Mar 2007, Thomas Gleixner wrote:
> 
> While I agree in principle with the patch, I'm a bit uncomfortable. The
> sys device suspend / resume ordering is not guaranteed and relies on the
> registering order.

Well, this is why we probably should try to get away from the "system 
device" issue, exactly because system devices are totally outside the 
normal ordering and only have a random linear order.

If the clocksources were actually in the device tree, you'd get all the 
normal guarantees about hierarchical ordering..

		Linus

Re: [PATCH v2] Add suspend/resume for HPET

[Linus Torvalds]

On Sat, 31 Mar 2007, Thomas Gleixner wrote:
> 
> While I agree in principle with the patch, I'm a bit uncomfortable. The
> sys device suspend / resume ordering is not guaranteed and relies on the
> registering order.

Well, this is why we probably should try to get away from the "system 
device" issue, exactly because system devices are totally outside the 
normal ordering and only have a random linear order.

If the clocksources were actually in the device tree, you'd get all the 
normal guarantees about hierarchical ordering..

		Linus

Re: [PATCH v2] Add suspend/resume for HPET

[Thomas Gleixner]

On Sat, 2007-03-31 at 09:09 -0700, Linus Torvalds wrote:
> 
> On Sat, 31 Mar 2007, Thomas Gleixner wrote:
> > 
> > While I agree in principle with the patch, I'm a bit uncomfortable. The
> > sys device suspend / resume ordering is not guaranteed and relies on the
> > registering order.
> 
> Well, this is why we probably should try to get away from the "system 
> device" issue, exactly because system devices are totally outside the 
> normal ordering and only have a random linear order.
> 
> If the clocksources were actually in the device tree, you'd get all the 
> normal guarantees about hierarchical ordering..

Right, but clock - sources/events need to be extremly late suspended and
early resumed. How can we ensure this ?

	tglx

Re: [PATCH v2] Add suspend/resume for HPET

[Greg KH]

On Sat, Mar 31, 2007 at 06:33:20PM +0200, Thomas Gleixner wrote:
> On Sat, 2007-03-31 at 09:09 -0700, Linus Torvalds wrote:
> > 
> > On Sat, 31 Mar 2007, Thomas Gleixner wrote:
> > > 
> > > While I agree in principle with the patch, I'm a bit uncomfortable. The
> > > sys device suspend / resume ordering is not guaranteed and relies on the
> > > registering order.
> > 
> > Well, this is why we probably should try to get away from the "system 
> > device" issue, exactly because system devices are totally outside the 
> > normal ordering and only have a random linear order.
> > 
> > If the clocksources were actually in the device tree, you'd get all the 
> > normal guarantees about hierarchical ordering..
> 
> Right, but clock - sources/events need to be extremly late suspended and
> early resumed. How can we ensure this ?

Put it at the top of the device tree.

thanks,

greg k-h

Re: [PATCH v2] Add suspend/resume for HPET

[Linus Torvalds]

On Sat, 31 Mar 2007, Thomas Gleixner wrote:
> 
> Right, but clock - sources/events need to be extremly late suspended and
> early resumed. How can we ensure this ?

Make them be at the top of the device tree by adding them early. That's 
the whole point of the device tree after all - we have an ordering that is 
enforced by its topology, and that we sort by when things were added.

Right now the way things work is (iirc - somebody like Greg should 
double-check me) is that we add all devices to the power list at 
device_add() time by traversing the devices fromt he root all the way out, 
and doing a device_add() which does a device_pm_add(), which in turn adds 
it to the power-management list - so that the list is always topologically 
sorted.

So the only thing that needs to be done is to make sure that we add the 
timer devices early during bootup - something we have to do *anyway*. If a 
device is added early in bootup, that automatically means that it will be 
suspended late, and resumed early - because we maintain that order all the 
way through..

		Linus

Re: [PATCH v2] Add suspend/resume for HPET

[Linus Torvalds]

On Sat, 31 Mar 2007, Thomas Gleixner wrote:
> 
> Right, but clock - sources/events need to be extremly late suspended and
> early resumed. How can we ensure this ?

Make them be at the top of the device tree by adding them early. That's 
the whole point of the device tree after all - we have an ordering that is 
enforced by its topology, and that we sort by when things were added.

Right now the way things work is (iirc - somebody like Greg should 
double-check me) is that we add all devices to the power list at 
device_add() time by traversing the devices fromt he root all the way out, 
and doing a device_add() which does a device_pm_add(), which in turn adds 
it to the power-management list - so that the list is always topologically 
sorted.

So the only thing that needs to be done is to make sure that we add the 
timer devices early during bootup - something we have to do *anyway*. If a 
device is added early in bootup, that automatically means that it will be 
suspended late, and resumed early - because we maintain that order all the 
way through..

		Linus

Re: [PATCH v2] Add suspend/resume for HPET

[Maxim Levitsky]

On Saturday 31 March 2007 18:51:11 Thomas Gleixner wrote:
> On Thu, 2007-03-29 at 15:46 +0200, Maxim Levitsky wrote:
> > Subject: Add suspend/resume for HPET
> > This adds support of suspend/resume on i386 for HPET
> > Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
> >
> > +static struct sysdev_class hpet_class = {
> > +	set_kset_name("hpet"),
> > +	.suspend	= hpet_suspend,
> > +	.resume		= hpet_resume,
> > +};
> > +
> > +static struct sys_device hpet_device = {
> > +	.id		= 0,
> > +	.cls		= &hpet_class,
> > +};
> 
> Sorry for being inresponsive. I was travelling and unexpectedly cut off
> from the internet for some days.
> 
> While I agree in principle with the patch, I'm a bit uncomfortable. The
> sys device suspend / resume ordering is not guaranteed and relies on the
> registering order.
> 
> Jeff still seems to have problems with CONFIG_NO_HZ=n and it might be
> caused by time keeping / tick management resume happening before the
> HPET resume.
> 
> The required resume order is:
> 
> clocksources
> timekeeping
> clockevents
> tick management
> 
> I'm not sure how to do this properly with the sys device facilities, but
> I look into it.
> 
> /me goes off to understand the sys device magic.
> 
> 	tglx
> 
> 
> 

Hi,

So maybe I was right afrer all,
Maybe it is better to add a suspend/resume hook to each clock source and call 
it from timekeeping_resume() ?

Or maybe even unite clocksources with clockevents, don't know 

By the way I want to report maybe a bug / maybe a feature :-)  : 
(sorry for long explanation)

Basically I have two clockevent sources : PIT(HPET) and APIC
(Actually I it seems that in next version of kernel HPET will be switched out 
of 'legacy replacement mode' , so PIT and HPET and RTC could coexist of same system,
But HPET won't be able to generate IRQ0, and it will be assigned some IRQ, possibly shared with other devices)

APIC timer  is chosen by default and works fine, 
since I don't have C2/C2 states on my system (ICH8 doesn't support them :-( )

But if I force it off (nolapic_timer) HPET or PIC is chosen and strangely they are
 put in _periodic_ mode although they are capable of one-shot mode
Is this a bug ?

Secondary I am getting a very strange behavior if I use CONFIG_NOHZ + !CONFIG_HIGH_RES_TIMERS
and try to suspend to ram:

System resumes, but gets crazy:
'top' shows that  ksoftirqd consumes 9999 % of cpu time (this is not a typo)
And other 'normal' programs that are running show same 9999 too.
System slows to crawl.

Also I found that one of APICS is in periodic mode,  and second is in one shoot mode.
And I tested this with or without my patch (thank goodness it is not my fault)

CONFIG_NOHZ + CONFIG_HIGH_RES_TIMERS work just fine.

Best regards,
	Maxim Levitsky

Re: [PATCH v2] Add suspend/resume for HPET

[Ingo Molnar]

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

> On Sat, 31 Mar 2007, Thomas Gleixner wrote:
> > 
> > Right, but clock - sources/events need to be extremly late suspended and
> > early resumed. How can we ensure this ?

[...]
> So the only thing that needs to be done is to make sure that we add 
> the timer devices early during bootup - something we have to do 
> *anyway*. If a device is added early in bootup, that automatically 
> means that it will be suspended late, and resumed early - because we 
> maintain that order all the way through..

IIRC hpet is particularly hard to initialize early on in the bootup 
sequence. So the way the clockevents code works is that it will always 
try to make the best out of all available devices, and dynamically 
adapts things as devices 'arrive' or 'depart' - no matter how late that 
happens. (That way there's no dependency on how late a device gets 
registered - it will only delay the switch to high-res mode for 
example.) A given time device might 'depart' because for example the 
watchdog mechanism finds that its quality is not good enough, or because 
someone initiated cpufreq which breaks the TSC clocksource.

i dont think there's any particular problem here because suspend/resume 
wont be done during bootup - but we might need a way to move a device to 
earlier spots in the device tree, even if they got registered later on - 
instead of forcing the time devices to be registered very early?

	Ingo

Re: [PATCH v2] Add suspend/resume for HPET

[Ingo Molnar]

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

> On Sat, 31 Mar 2007, Thomas Gleixner wrote:
> > 
> > Right, but clock - sources/events need to be extremly late suspended and
> > early resumed. How can we ensure this ?

[...]
> So the only thing that needs to be done is to make sure that we add 
> the timer devices early during bootup - something we have to do 
> *anyway*. If a device is added early in bootup, that automatically 
> means that it will be suspended late, and resumed early - because we 
> maintain that order all the way through..

IIRC hpet is particularly hard to initialize early on in the bootup 
sequence. So the way the clockevents code works is that it will always 
try to make the best out of all available devices, and dynamically 
adapts things as devices 'arrive' or 'depart' - no matter how late that 
happens. (That way there's no dependency on how late a device gets 
registered - it will only delay the switch to high-res mode for 
example.) A given time device might 'depart' because for example the 
watchdog mechanism finds that its quality is not good enough, or because 
someone initiated cpufreq which breaks the TSC clocksource.

i dont think there's any particular problem here because suspend/resume 
wont be done during bootup - but we might need a way to move a device to 
earlier spots in the device tree, even if they got registered later on - 
instead of forcing the time devices to be registered very early?

	Ingo

Re: [PATCH v2] Add suspend/resume for HPET

[Greg KH]

On Sat, Mar 31, 2007 at 09:53:43AM -0700, Linus Torvalds wrote:
> Make them be at the top of the device tree by adding them early. That's 
> the whole point of the device tree after all - we have an ordering that is 
> enforced by its topology, and that we sort by when things were added.
> 
> Right now the way things work is (iirc - somebody like Greg should 
> double-check me) is that we add all devices to the power list at 
> device_add() time by traversing the devices fromt he root all the way out, 
> and doing a device_add() which does a device_pm_add(), which in turn adds 
> it to the power-management list - so that the list is always topologically 
> sorted.

Yes, this is how it works (or if not, then there's a bug that needs to
be fixed, as that is how it _should_ work...)

thanks,

greg k-h

Re: [PATCH v2] Add suspend/resume for HPET

[Linus Torvalds]

On Sat, 31 Mar 2007, Maxim Levitsky wrote:
> 
> So maybe I was right afrer all,
> Maybe it is better to add a suspend/resume hook to each clock source and call 
> it from timekeeping_resume() ?

Umm.. WHy not make the device tree look like this:

	    -- "clocksource" -- +-- HPET
				|
				+-- TSC
				|
				+-- i8259
				|
				+-- lapic timer
				|
				.. whatever else

and use the "struct device" that we *have* for this? The whole "struct 
device" is literally designed to do this, and to be embedded into whatever 
bigger structures you have that describes higher-level behaviour. Ie you'd 
put a "struct device" inside the "struct clocksource".

That thingalready *has* the suspend/resume hooks, and it will mean that 
people will see the clocks in the device tree rather than have a new 
notion.


			Linus

Re: [PATCH v2] Add suspend/resume for HPET

[Linus Torvalds]

On Sat, 31 Mar 2007, Maxim Levitsky wrote:
> 
> So maybe I was right afrer all,
> Maybe it is better to add a suspend/resume hook to each clock source and call 
> it from timekeeping_resume() ?

Umm.. WHy not make the device tree look like this:

	    -- "clocksource" -- +-- HPET
				|
				+-- TSC
				|
				+-- i8259
				|
				+-- lapic timer
				|
				.. whatever else

and use the "struct device" that we *have* for this? The whole "struct 
device" is literally designed to do this, and to be embedded into whatever 
bigger structures you have that describes higher-level behaviour. Ie you'd 
put a "struct device" inside the "struct clocksource".

That thingalready *has* the suspend/resume hooks, and it will mean that 
people will see the clocks in the device tree rather than have a new 
notion.


			Linus

Re: [PATCH v2] Add suspend/resume for HPET

[Ingo Molnar]

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

> Umm.. WHy not make the device tree look like this:
> 
> 	    -- "clocksource" -- +-- HPET
> 				|
> 				+-- TSC
> 				|
> 				+-- i8259
> 				|
> 				+-- lapic timer
> 				|
> 				.. whatever else
> 
> and use the "struct device" that we *have* for this? The whole "struct 
> device" is literally designed to do this, and to be embedded into 
> whatever bigger structures you have that describes higher-level 
> behaviour. Ie you'd put a "struct device" inside the "struct 
> clocksource".

yeah. There's some practical problems that need to be sorted out: much 
of the current GTOD code is irq-driven (and all GTOD locks are 
irq-safe), while the sysfs code needs to run in process-context level. 

Clocksources 'arrive' and 'depart' in hardirq context (which is the 
primary place where we notice their breakage, determine that they are 
now verified to be usable, etc.). This came partly from legacy: the 
gradual conversion of the monolithic time code, and the need to preserve 
GTOD and non-GTOD architectures without too much duplication. It also 
came partly because there's also a fundamental need to have accurate 
time, which is better served from irq context.

i very much agree that this should and must be cleaned up, but it needs 
quite a bit more logistics than it might appear at first sight. 
Clockevents basically just followed (and had to follow) the direction of 
clocksources in this regard.

	Ingo

Re: [PATCH v2] Add suspend/resume for HPET

[Ingo Molnar]

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

> Umm.. WHy not make the device tree look like this:
> 
> 	    -- "clocksource" -- +-- HPET
> 				|
> 				+-- TSC
> 				|
> 				+-- i8259
> 				|
> 				+-- lapic timer
> 				|
> 				.. whatever else
> 
> and use the "struct device" that we *have* for this? The whole "struct 
> device" is literally designed to do this, and to be embedded into 
> whatever bigger structures you have that describes higher-level 
> behaviour. Ie you'd put a "struct device" inside the "struct 
> clocksource".

yeah. There's some practical problems that need to be sorted out: much 
of the current GTOD code is irq-driven (and all GTOD locks are 
irq-safe), while the sysfs code needs to run in process-context level. 

Clocksources 'arrive' and 'depart' in hardirq context (which is the 
primary place where we notice their breakage, determine that they are 
now verified to be usable, etc.). This came partly from legacy: the 
gradual conversion of the monolithic time code, and the need to preserve 
GTOD and non-GTOD architectures without too much duplication. It also 
came partly because there's also a fundamental need to have accurate 
time, which is better served from irq context.

i very much agree that this should and must be cleaned up, but it needs 
quite a bit more logistics than it might appear at first sight. 
Clockevents basically just followed (and had to follow) the direction of 
clocksources in this regard.

	Ingo

Re: [linux-pm] [PATCH v2] Add suspend/resume for HPET

[David Brownell]

On Saturday 31 March 2007 9:53 am, Linus Torvalds wrote:
> 
> On Sat, 31 Mar 2007, Thomas Gleixner wrote:
> > 
> > Right, but clock - sources/events need to be extremly late suspended and
> > early resumed. How can we ensure this ?
> 
> Make them be at the top of the device tree by adding them early. That's 
> the whole point of the device tree after all - we have an ordering that is 
> enforced by its topology, and that we sort by when things were added.

Right, but "when things get added" doesn't correlate well to
"when they should get suspended/resumed".  It's also in basic
conflict with runtime PM models, where devices may be suspended
at essentially any time.  And sysdevs are even stranger.


One way out:  rather than constructing that list as devices get
enumerated, it could be constructed by a (linear-time, non-recursive)
walk of the device tree(s) before they get suspended.

(Or equivalently:  construct lists at enumeration time, but just
adding them *right after their parent* rather than at the end of
the list.)

Would that solve the problem here?  Potentially ... if the tree is
structured to meet Thomas' rules:

> > The required resume order is:
> > 
> > clocksources
> > timekeeping
> > clockevents
> > tick management

> So the only thing that needs to be done is to make sure that we add the 
> timer devices early during bootup - something we have to do *anyway*. If a 
> device is added early in bootup, that automatically means that it will be 
> suspended late, and resumed early - because we maintain that order all the 
> way through..

>             -- "clocksource" -- +-- HPET
>                                 |
>                                 +-- TSC
>                                 |
>                                 +-- i8259
>                                 |
>                                 +-- lapic timer
>                                 |
>                                 .. whatever else

If each of those were a device node, with "clocksource" suspend/resume
methods handling Thomas' "timekeeping" item, and simlarly for "clockevent"
devices ... I could see that all working neatly.

- Dave

-
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

Re: [linux-pm] [PATCH v2] Add suspend/resume for HPET

[David Brownell]

On Saturday 31 March 2007 9:53 am, Linus Torvalds wrote:
> 
> On Sat, 31 Mar 2007, Thomas Gleixner wrote:
> > 
> > Right, but clock - sources/events need to be extremly late suspended and
> > early resumed. How can we ensure this ?
> 
> Make them be at the top of the device tree by adding them early. That's 
> the whole point of the device tree after all - we have an ordering that is 
> enforced by its topology, and that we sort by when things were added.

Right, but "when things get added" doesn't correlate well to
"when they should get suspended/resumed".  It's also in basic
conflict with runtime PM models, where devices may be suspended
at essentially any time.  And sysdevs are even stranger.


One way out:  rather than constructing that list as devices get
enumerated, it could be constructed by a (linear-time, non-recursive)
walk of the device tree(s) before they get suspended.

(Or equivalently:  construct lists at enumeration time, but just
adding them *right after their parent* rather than at the end of
the list.)

Would that solve the problem here?  Potentially ... if the tree is
structured to meet Thomas' rules:

> > The required resume order is:
> > 
> > clocksources
> > timekeeping
> > clockevents
> > tick management

> So the only thing that needs to be done is to make sure that we add the 
> timer devices early during bootup - something we have to do *anyway*. If a 
> device is added early in bootup, that automatically means that it will be 
> suspended late, and resumed early - because we maintain that order all the 
> way through..

>             -- "clocksource" -- +-- HPET
>                                 |
>                                 +-- TSC
>                                 |
>                                 +-- i8259
>                                 |
>                                 +-- lapic timer
>                                 |
>                                 .. whatever else

If each of those were a device node, with "clocksource" suspend/resume
methods handling Thomas' "timekeeping" item, and simlarly for "clockevent"
devices ... I could see that all working neatly.

- Dave

Re: [PATCH v2] Add suspend/resume for HPET

[Daniel Walker]

On Sat, 2007-03-31 at 19:17 +0200, Ingo Molnar wrote:

> yeah. There's some practical problems that need to be sorted out: much 
> of the current GTOD code is irq-driven (and all GTOD locks are 
> irq-safe), while the sysfs code needs to run in process-context level. 
> 
> Clocksources 'arrive' and 'depart' in hardirq context (which is the 
> primary place where we notice their breakage, determine that they are 
> now verified to be usable, etc.). This came partly from legacy: the 
> gradual conversion of the monolithic time code, and the need to preserve 
> GTOD and non-GTOD architectures without too much duplication. It also 
> came partly because there's also a fundamental need to have accurate 
> time, which is better served from irq context.
> 

Is this in reference to the irq-context clocksource polling stuff? I
don't see a dire reason to keep that code, and I agree removing that is
a certainly a worth while cleanup .. I added this cleanup to one of my
trees when you first suggested it , and there is some infrastructure
that really should be added to facilitate it.

Daniel

Re: [linux-pm] [PATCH v2] Add suspend/resume for HPET

[David Brownell]

( please remove obsolute linux-pm@lists.osdl.org  from further messages!! )

On Saturday 31 March 2007 10:02 am, Ingo Molnar wrote:
> 
> i dont think there's any particular problem here because suspend/resume 
> wont be done during bootup - but we might need a way to move a device to 
> earlier spots in the device tree, even if they got registered later on - 
> instead of forcing the time devices to be registered very early?

I'm about ready to test the appended patch... a "move one device" call
might be safest at this point in the release cycle though.

- Dave

========================	SNIP!
Change how the PM list is constructed, so that devices are added right
after their parents (when they have one) rather than at the end of the
list.  This preserves sequencing guarantees, but enables sequencing of
suspend/resume operations by more important characteristics than "when
device happened to enumerate" ... e.g. clocksources and clockevents
at a clearly defined point during suspend and resume.

This patch has a potential downside for devices that have multiple
power dependencies and which "just happened to work" before.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

--- g26.orig/drivers/base/power/main.c	2006-07-02 12:30:30.000000000 -0700
+++ g26/drivers/base/power/main.c	2007-03-31 11:02:28.000000000 -0700
@@ -52,12 +52,17 @@ EXPORT_SYMBOL_GPL(device_pm_set_parent);
 int device_pm_add(struct device * dev)
 {
 	int error;
+	struct device *parent = dev->parent;
 
-	pr_debug("PM: Adding info for %s:%s\n",
-		 dev->bus ? dev->bus->name : "No Bus", dev->kobj.name);
+	pr_debug("PM: Adding info for %s:%s, after %s\n",
+		 dev->bus ? dev->bus->name : "No Bus", dev->kobj.name,
+		 parent ? parent->bus_id : "(no parent)");
 	down(&dpm_list_sem);
-	list_add_tail(&dev->power.entry, &dpm_active);
-	device_pm_set_parent(dev, dev->parent);
+	if (parent)
+		list_add(&dev->power.entry, &parent->power.entry);
+	else
+		list_add_tail(&dev->power.entry, &dpm_active);
+	device_pm_set_parent(dev, parent);
 	if ((error = dpm_sysfs_add(dev)))
 		list_del(&dev->power.entry);
 	up(&dpm_list_sem);

Re: [PATCH v2] Add suspend/resume for HPET

[David Brownell]

( please remove obsolute linux-pm@lists.osdl.org  from further messages!! )

On Saturday 31 March 2007 10:02 am, Ingo Molnar wrote:
> 
> i dont think there's any particular problem here because suspend/resume 
> wont be done during bootup - but we might need a way to move a device to 
> earlier spots in the device tree, even if they got registered later on - 
> instead of forcing the time devices to be registered very early?

I'm about ready to test the appended patch... a "move one device" call
might be safest at this point in the release cycle though.

- Dave

========================	SNIP!
Change how the PM list is constructed, so that devices are added right
after their parents (when they have one) rather than at the end of the
list.  This preserves sequencing guarantees, but enables sequencing of
suspend/resume operations by more important characteristics than "when
device happened to enumerate" ... e.g. clocksources and clockevents
at a clearly defined point during suspend and resume.

This patch has a potential downside for devices that have multiple
power dependencies and which "just happened to work" before.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

--- g26.orig/drivers/base/power/main.c	2006-07-02 12:30:30.000000000 -0700
+++ g26/drivers/base/power/main.c	2007-03-31 11:02:28.000000000 -0700
@@ -52,12 +52,17 @@ EXPORT_SYMBOL_GPL(device_pm_set_parent);
 int device_pm_add(struct device * dev)
 {
 	int error;
+	struct device *parent = dev->parent;
 
-	pr_debug("PM: Adding info for %s:%s\n",
-		 dev->bus ? dev->bus->name : "No Bus", dev->kobj.name);
+	pr_debug("PM: Adding info for %s:%s, after %s\n",
+		 dev->bus ? dev->bus->name : "No Bus", dev->kobj.name,
+		 parent ? parent->bus_id : "(no parent)");
 	down(&dpm_list_sem);
-	list_add_tail(&dev->power.entry, &dpm_active);
-	device_pm_set_parent(dev, dev->parent);
+	if (parent)
+		list_add(&dev->power.entry, &parent->power.entry);
+	else
+		list_add_tail(&dev->power.entry, &dpm_active);
+	device_pm_set_parent(dev, parent);
 	if ((error = dpm_sysfs_add(dev)))
 		list_del(&dev->power.entry);
 	up(&dpm_list_sem);

Re: [linux-pm] [PATCH v2] Add suspend/resume for HPET

[David Brownell]

On Saturday 31 March 2007 11:18 am, David Brownell wrote:
> ( please remove obsolute linux-pm@lists.osdl.org  from further messages!! )
> 
> On Saturday 31 March 2007 10:02 am, Ingo Molnar wrote:
> > 
> > i dont think there's any particular problem here because suspend/resume 
> > wont be done during bootup - but we might need a way to move a device to 
> > earlier spots in the device tree, even if they got registered later on - 
> > instead of forcing the time devices to be registered very early?
> 
> I'm about ready to test the appended patch... a "move one device" call
> might be safest at this point in the release cycle though.

As expected, this behaved OK on an x86 laptop.  I'll see if it breaks
some of the ARM boards I have handy.

To be clear, what this means is that if "clockevent" and "clocksource"
devices get registered "very early", and the various clockevent and
clock source devices get registered, then the suspend/resume methods
for those will all get grouped together ... suspended "very late" and
resumed "very early", regardless of when they get registered.  Pretty
much the driver model parts of what Linus was suggesting; clockevent
bits would still be needed.

- Dave



> - Dave
> 
> ========================	SNIP!
> Change how the PM list is constructed, so that devices are added right
> after their parents (when they have one) rather than at the end of the
> list.  This preserves sequencing guarantees, but enables sequencing of
> suspend/resume operations by more important characteristics than "when
> device happened to enumerate" ... e.g. clocksources and clockevents
> at a clearly defined point during suspend and resume.
> 
> This patch has a potential downside for devices that have multiple
> power dependencies and which "just happened to work" before.
> 
> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
> 
> --- g26.orig/drivers/base/power/main.c	2006-07-02 12:30:30.000000000 -0700
> +++ g26/drivers/base/power/main.c	2007-03-31 11:02:28.000000000 -0700
> @@ -52,12 +52,17 @@ EXPORT_SYMBOL_GPL(device_pm_set_parent);
>  int device_pm_add(struct device * dev)
>  {
>  	int error;
> +	struct device *parent = dev->parent;
>  
> -	pr_debug("PM: Adding info for %s:%s\n",
> -		 dev->bus ? dev->bus->name : "No Bus", dev->kobj.name);
> +	pr_debug("PM: Adding info for %s:%s, after %s\n",
> +		 dev->bus ? dev->bus->name : "No Bus", dev->kobj.name,
> +		 parent ? parent->bus_id : "(no parent)");
>  	down(&dpm_list_sem);
> -	list_add_tail(&dev->power.entry, &dpm_active);
> -	device_pm_set_parent(dev, dev->parent);
> +	if (parent)
> +		list_add(&dev->power.entry, &parent->power.entry);
> +	else
> +		list_add_tail(&dev->power.entry, &dpm_active);
> +	device_pm_set_parent(dev, parent);
>  	if ((error = dpm_sysfs_add(dev)))
>  		list_del(&dev->power.entry);
>  	up(&dpm_list_sem);
> 

Re: [PATCH v2] Add suspend/resume for HPET

[David Brownell]

On Saturday 31 March 2007 11:18 am, David Brownell wrote:
> ( please remove obsolute linux-pm@lists.osdl.org  from further messages!! )
> 
> On Saturday 31 March 2007 10:02 am, Ingo Molnar wrote:
> > 
> > i dont think there's any particular problem here because suspend/resume 
> > wont be done during bootup - but we might need a way to move a device to 
> > earlier spots in the device tree, even if they got registered later on - 
> > instead of forcing the time devices to be registered very early?
> 
> I'm about ready to test the appended patch... a "move one device" call
> might be safest at this point in the release cycle though.

As expected, this behaved OK on an x86 laptop.  I'll see if it breaks
some of the ARM boards I have handy.

To be clear, what this means is that if "clockevent" and "clocksource"
devices get registered "very early", and the various clockevent and
clock source devices get registered, then the suspend/resume methods
for those will all get grouped together ... suspended "very late" and
resumed "very early", regardless of when they get registered.  Pretty
much the driver model parts of what Linus was suggesting; clockevent
bits would still be needed.

- Dave



> - Dave
> 
> ========================	SNIP!
> Change how the PM list is constructed, so that devices are added right
> after their parents (when they have one) rather than at the end of the
> list.  This preserves sequencing guarantees, but enables sequencing of
> suspend/resume operations by more important characteristics than "when
> device happened to enumerate" ... e.g. clocksources and clockevents
> at a clearly defined point during suspend and resume.
> 
> This patch has a potential downside for devices that have multiple
> power dependencies and which "just happened to work" before.
> 
> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
> 
> --- g26.orig/drivers/base/power/main.c	2006-07-02 12:30:30.000000000 -0700
> +++ g26/drivers/base/power/main.c	2007-03-31 11:02:28.000000000 -0700
> @@ -52,12 +52,17 @@ EXPORT_SYMBOL_GPL(device_pm_set_parent);
>  int device_pm_add(struct device * dev)
>  {
>  	int error;
> +	struct device *parent = dev->parent;
>  
> -	pr_debug("PM: Adding info for %s:%s\n",
> -		 dev->bus ? dev->bus->name : "No Bus", dev->kobj.name);
> +	pr_debug("PM: Adding info for %s:%s, after %s\n",
> +		 dev->bus ? dev->bus->name : "No Bus", dev->kobj.name,
> +		 parent ? parent->bus_id : "(no parent)");
>  	down(&dpm_list_sem);
> -	list_add_tail(&dev->power.entry, &dpm_active);
> -	device_pm_set_parent(dev, dev->parent);
> +	if (parent)
> +		list_add(&dev->power.entry, &parent->power.entry);
> +	else
> +		list_add_tail(&dev->power.entry, &dpm_active);
> +	device_pm_set_parent(dev, parent);
>  	if ((error = dpm_sysfs_add(dev)))
>  		list_del(&dev->power.entry);
>  	up(&dpm_list_sem);
> 

Re: [PATCH v2] Add suspend/resume for HPET

[Jeff Chua]

On 4/1/07, David Brownell <david-b@pacbell.net> wrote:
> for those will all get grouped together ... suspended "very late" and
> resumed "very early", regardless of when they get registered.  Pretty
> much the driver model parts of what Linus was suggesting; clockevent
> bits would still be needed.

I tested your patch with CONFIG_NO_HZ=y, but it still hangs while
suspending to disk (before the percent saving).

But one discovery. I get tired of all these hangs, so I decided to
press some keys and the power button. Accidentally, the suspend
proceeded and successfully suspended!

I tried many more times, and discovered that to proceed with the
suspend, hit any 4 keys slowly. (e.g. "F1 F2 F3 F4", or "1 2 3 4").

My .config has CONFIG_NO_HZ=y and CONFIG_HIGH_RES_TIMERS=y, but I
suppose CONFIG_HIGH_RES_TIMERS=y gots nothing to do with the hang.

I went back with my vanilla 2.6.21-rc5 with Maxim's patch, and with
hitting the keys, I could suspend to disk with CONFIG_NO_HZ=y and
CONFIG_HIGH_RES_TIMERS=y.

Jeff.

Re: [linux-pm] [PATCH v2] Add suspend/resume for HPET

[Jeff Chua]

On 4/1/07, David Brownell <david-b@pacbell.net> wrote:
> for those will all get grouped together ... suspended "very late" and
> resumed "very early", regardless of when they get registered.  Pretty
> much the driver model parts of what Linus was suggesting; clockevent
> bits would still be needed.

I tested your patch with CONFIG_NO_HZ=y, but it still hangs while
suspending to disk (before the percent saving).

But one discovery. I get tired of all these hangs, so I decided to
press some keys and the power button. Accidentally, the suspend
proceeded and successfully suspended!

I tried many more times, and discovered that to proceed with the
suspend, hit any 4 keys slowly. (e.g. "F1 F2 F3 F4", or "1 2 3 4").

My .config has CONFIG_NO_HZ=y and CONFIG_HIGH_RES_TIMERS=y, but I
suppose CONFIG_HIGH_RES_TIMERS=y gots nothing to do with the hang.

I went back with my vanilla 2.6.21-rc5 with Maxim's patch, and with
hitting the keys, I could suspend to disk with CONFIG_NO_HZ=y and
CONFIG_HIGH_RES_TIMERS=y.

Jeff.

Re: [PATCH v2] Add suspend/resume for HPET

[David Brownell]

On Saturday 31 March 2007 8:13 pm, Jeff Chua wrote:
> On 4/1/07, David Brownell <david-b@pacbell.net> wrote:
> > for those will all get grouped together ... suspended "very late" and
> > resumed "very early", regardless of when they get registered.  Pretty
> > much the driver model parts of what Linus was suggesting; clockevent
> > bits would still be needed.
> 
> I tested your patch with CONFIG_NO_HZ=y, but it still hangs while
> suspending to disk (before the percent saving).

Of course.  No clockevent updates...

Re: [linux-pm] [PATCH v2] Add suspend/resume for HPET

[David Brownell]

On Saturday 31 March 2007 8:13 pm, Jeff Chua wrote:
> On 4/1/07, David Brownell <david-b@pacbell.net> wrote:
> > for those will all get grouped together ... suspended "very late" and
> > resumed "very early", regardless of when they get registered.  Pretty
> > much the driver model parts of what Linus was suggesting; clockevent
> > bits would still be needed.
> 
> I tested your patch with CONFIG_NO_HZ=y, but it still hangs while
> suspending to disk (before the percent saving).

Of course.  No clockevent updates...

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Bjorn Helgaas]

On Monday 26 March 2007 21:29, Eric W. Biederman wrote:
> "Luck, Tony" <tony.luck@intel.com> writes:
> 
> >> 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.
> >
> > Sounds rational ... in a world that wasn't dominated by PCI it would
> > seem to be the logical approach (since the irq code would have much
> > more utility independent of the PCI code).
> 
> Right.  We can even do this earlier in the pci code.  Just doing this
> on demand when the device driver needs it is problematic.  As devices
> drivers like to keep the requested over a pci_disable_device pci_enable_device
> pair.
> 
> The big practical issue is that we will like wind up allocating an irq
> number to all usable irqs on ia64.  Which means we will like need many
> more irq numbers...  Although I guess if we keep it at the pci layer
> we should be fairly safe.

The main reason we wait until pci_enable_device() to allocate an
IRQ number is that ia64 currently only has about 180 device vectors,
and there are machines with more PCI slots than that.

I also think it's nice that we don't do anything with a device until
we have a driver to claim it.  But there certainly have been cases
where delaying IRQ allocation has caused troubles.

I really like the idea of moving to the IRQ == GSI model for ia64.
But of course, we'll have to get rid of the 180-vector limit to
make that work, too.

Bjorn

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Bjorn Helgaas]

On Monday 02 April 2007 09:38, Bjorn Helgaas wrote:
> The main reason we wait until pci_enable_device() to allocate an
> IRQ number is that ia64 currently only has about 180 device vectors,
> and there are machines with more PCI slots than that.

Sigh, that didn't make much sense, did it?  At the time, ia64 didn't
support sharing IRQ vectors, and we preallocated four vectors for
every slot, including empty ones.  Allocate-on-demand dramatically
increased the number of devices we could support because most cards
use only one IRQ.

Re: [3/5] 2.6.21-rc4: known regressions (v2)

[Eric W. Biederman]

Bjorn Helgaas <bjorn.helgaas@hp.com> writes:

>
> The main reason we wait until pci_enable_device() to allocate an
> IRQ number is that ia64 currently only has about 180 device vectors,
> and there are machines with more PCI slots than that.

If we don't reserve irqs that the hardware doesn't support we should
be able to simply move the allocation and have about the same cost as
we do today.

> I also think it's nice that we don't do anything with a device until
> we have a driver to claim it.  But there certainly have been cases
> where delaying IRQ allocation has caused troubles.

Agreed.  It is the second call to pci_enable_device() by a driver where
things really start to unravel in the wait until we need it plan.

> I really like the idea of moving to the IRQ == GSI model for ia64.
> But of course, we'll have to get rid of the 180-vector limit to
> make that work, too.

Mostly that is a matter of porting the code from x86_64 where that is
already the case.  I'm pretty certain I have worked through all of
the bit issues, but there might be a few small problems that crop up.

If need by I will do the patches as I find time.  But if someone else gets
there before I do that would be great :)

Eric

Re: [patch] hrtimers debug patch

[Michal Piotrowski]

Hi all,

On 26/03/07, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
>
> > Stardust is down, console log and config attached.
>
> thanks! I have stared at hrtimer.c a few more hours and the good news is
> that i found a narrow SMP race. The bad news is that i dont think it
> could explain your bug symptoms: the worst-case effect of the race
> should be an incorrect timeout on the current CPU - not a KTIME_MAX
> thing like your logs show.
>
> But maybe i didnt think through the effects of the bug well enough, and
> your box has a HT CPU, with HT CPUs being pretty good at triggering
> narrow SMP races - so maybe we are lucky? Fix attached below. Patch is
> build and boot-tested.
>

I didn't see this weird hang for 12 days. I think that this patch
solves this issue.

Huge thans!

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

Re: [patch] hrtimers debug patch

[Ingo Molnar]

* Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:

> > thanks! I have stared at hrtimer.c a few more hours and the good 
> > news is that i found a narrow SMP race. The bad news is that i dont 
> > think it could explain your bug symptoms: the worst-case effect of 
> > the race should be an incorrect timeout on the current CPU - not a 
> > KTIME_MAX thing like your logs show.
> >
> > But maybe i didnt think through the effects of the bug well enough, 
> > and your box has a HT CPU, with HT CPUs being pretty good at 
> > triggering narrow SMP races - so maybe we are lucky? Fix attached 
> > below. Patch is build and boot-tested.
> 
> I didn't see this weird hang for 12 days. I think that this patch 
> solves this issue.

cool :)

> Huge thans!

huge thanks to you for testing it!

	Ingo