2.6.31-rc2: Reported regressions from 2.6.30

2.6.31-rc2: Reported regressions from 2.6.30

[Rafael J. Wysocki]

[NOTE: I'll be traveling next week, so there won't be a summary report.]

This message contains a list of some regressions from 2.6.30, for which there
are no fixes in the mainline I know of.  If any of them have been fixed already,
please let me know.

If you know of any other unresolved regressions from 2.6.30, please let me know
either and I'll add them to the list.  Also, please let me know if any of the
entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.


Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2009-07-07       35       25          21
  2009-06-29       22       22          15


Unresolved regressions
----------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13733
Subject		: 2.6.31-rc2: irq 16: nobody cared
Submitter	: Niel Lambrechts <niel.lambrechts-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-07-06 18:32 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=124690524027166&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13732
Subject		: tty layer instabilities
Submitter	: Mikael Pettersson <mikpe-1zs4UD6AkMk@public.gmane.org>
Date		: 2009-07-06 13:43 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=124688781732419&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13731
Subject		: Inconsistent {IN-RECLAIM_FS-W} -> {RECLAIM_FS-ON-W} usage.
Submitter	: Miles Lane <miles.lane-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-07-06 4:22 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=124685417325348&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13730
Subject		: hitting lockdep limits...
Submitter	: Daniel J Blueman <daniel.blueman-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-07-05 18:19 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=124681799023782&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13729
Subject		: kernel BUG at fs/notify/notification.c:93!
Submitter	: Mikko C. <mikko.cal-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-06-04 10:16 (33 days old)
References	: http://lkml.org/lkml/2009/7/4/12
Handled-By	: Eric Paris <eparis-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13728
Subject		: 2.6.31-rc2 soft lockups, RPC-related
Submitter	: Paul Collins <paul-dsjeNyW6Qm/D+ROgJ3VA+kB+6BGkLq7r@public.gmane.org>
Date		: 2009-07-05 7:17 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=124677884816794&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13727
Subject		: Cannot Recognize Empty DVD Media
Submitter	: Tarkan Erimer <tarkan.erimer-AMZSHK9Z0TXlajqSnzHT9w@public.gmane.org>
Date		: 2009-07-02 16:23 (5 days old)
References	: http://lkml.org/lkml/2009/7/2/178


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13726
Subject		: fio sync read 4k block size 35% regression
Submitter	: Zhang, Yanmin <yanmin_zhang-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Date		: 2009-07-01 11:25 (6 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=51daa88ebd8e0d437289f589af29d4b39379ea76
References	: http://lkml.org/lkml/2009/6/30/679
Handled-By	: Wu Fengguang <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13716
Subject		: The AIC-7892P controller does not work any more
Submitter	: Andrej Podzimek <andrej-+Hii8LNHG6Ng9hUCZPvPmw@public.gmane.org>
Date		: 2009-07-05 19:23 (2 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13700
Subject		: usb error flood in dmesg, makes kde use plenty of cpu - bisected
Submitter	: jouni susiluoto <jouni.susiluoto-pxSi+dnQzZMxHbG02/KK1g@public.gmane.org>
Date		: 2009-07-03 21:13 (4 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13690
Subject		: nodes_clear cause hugepage unusable on non-NUMA machine
Submitter	: alexs <alex.shi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date		: 2009-07-02 01:22 (5 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13673
Subject		: HIGHMEM64G causes hang in PCI init on 32-bit x86
Submitter	: Mikael Pettersson <mikpe-1zs4UD6AkMk@public.gmane.org>
Date		: 2009-06-26 15:59 (11 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=95ee14e4379c5e19c0897c872350570402014742
References	: http://marc.info/?l=linux-pci&m=124615181602643&w=4
Handled-By	: H. Peter Anvin <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13667
Subject		: drm: display arifacts when X.Org is stopped
Submitter	: Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
Date		: 2009-06-27 18:52 (10 days old)
References	: http://lkml.org/lkml/2009/6/27/105


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13666
Subject		: WARNING: at mm/page_alloc.c:1743 __alloc_pages_nodemask
Submitter	: Thomas Meyer <thomas-VsYtu1Qij5c@public.gmane.org>
Date		: 2009-06-27 16:15 (10 days old)
References	: http://lkml.org/lkml/2009/6/27/75


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13661
Subject		: warning in smp_call_function_single while S2R
Submitter	: Thomas Meyer <thomas-VsYtu1Qij5c@public.gmane.org>
Date		: 2009-06-27 17:12 (10 days old)
References	: http://lkml.org/lkml/2009/6/27/80


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13657
Subject		: Linux-2.6.31-rc1 Fails To Recognize Some USB Disks
Submitter	: Tarkan Erimer <tarkan.erimer-AMZSHK9Z0TXlajqSnzHT9w@public.gmane.org>
Date		: 2009-06-26 10:03 (11 days old)
References	: http://lkml.org/lkml/2009/6/26/34


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13656
Subject		: 2.6.31-rc1 crashes randomly on my Machine.
Submitter	: Zeno Davatz <zdavatz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-06-26 08:56 (11 days old)
References	: http://lkml.org/lkml/2009/6/26/27


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13652
Subject		: scheduling while atomic: pptpgw
Submitter	: Sergey Senozhatsky <sergey.senozhatsky-A/MS7pq9VAU@public.gmane.org>
Date		: 2009-06-19 21:15 (18 days old)
References	: http://lkml.org/lkml/2009/6/19/237


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13650
Subject		: Problem with alloc_arch_preferred_bootmem() on powerpc
Submitter	: Sean MacLennan <smaclennan-Qtffpm9i2AVWk0Htik3J/w@public.gmane.org>
Date		: 2009-06-20 19:48 (17 days old)
References	: http://marc.info/?l=linuxppc-embedded&m=124552732411775&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13645
Subject		: NULL pointer dereference at (null) (level2_spare_pgt)
Submitter	: poornima nayak <mpnayak-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Date		: 2009-06-17 17:56 (20 days old)
References	: http://lkml.org/lkml/2009/6/17/194


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13522
Subject		: BUG: scheduling while atomic
Submitter	: Sergey Senozhatsky <sergey.senozhatsky-A/MS7pq9VAU@public.gmane.org>
Date		: 2009-06-12 19:29 (25 days old)
References	: http://lkml.org/lkml/2009/6/29/237


Regressions with patches
------------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13734
Subject		: regression in 2.6.31-rcX since commit a1091aa
Submitter	: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Date		: 2009-07-06 19:07 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=124690725130645&w=4
Handled-By	: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/34292/


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13665
Subject		: commit 69c854817566 causes OOMs
Submitter	: David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date		: 2009-06-27 08:12 (10 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69c854817566db82c362797b4a6521d0b00fe1d8
References	: http://lkml.org/lkml/2009/6/27/28
Handled-By	: Wu Fengguang <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/32740/


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13659
Subject		: iwlagn (4965): no wireless due to RFKILL problem
Submitter	: Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
Date		: 2009-06-26 13:36 (11 days old)
References	: http://lkml.org/lkml/2009/6/26/127
Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Patch		: http://lkml.org/lkml/2009/6/27/35


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13643
Subject		: Touchpad lost synchronization after resume from suspend to RAM
Submitter	: Cijoml Cijomlovic Cijomlov <cijoml-VIXq6x/3rUk@public.gmane.org>
Date		: 2009-06-28 10:42 (9 days old)
References	: http://lkml.org/lkml/2009/6/23/365
		  2.6.30-rc1: touchpad disabled
		  http://lkml.org/lkml/2009/6/25/256
Handled-By	: Thadeu Lima de Souza Cascardo <cascardo-DmMZpsCg3uxeGPcbtGPokg@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/34075/


For details, please visit the bug entries and follow the links given in
references.

As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.30,
unresolved as well as resolved, at:

http://bugzilla.kernel.org/show_bug.cgi?id=13615

Please let me know if there are any Bugzilla entries that should be added to
the list in there.

Thanks,
Rafael

[Bug #13522] BUG: scheduling while atomic

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13522
Subject		: BUG: scheduling while atomic
Submitter	: Sergey Senozhatsky <sergey.senozhatsky-A/MS7pq9VAU@public.gmane.org>
Date		: 2009-06-12 19:29 (25 days old)
References	: http://lkml.org/lkml/2009/6/29/237

Re: [Bug #13522] BUG: scheduling while atomic

[Sergey Senozhatsky]

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

On (07/07/09 02:00), Rafael J. Wysocki wrote:
> 
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.30.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13522
> Subject		: BUG: scheduling while atomic
> Submitter	: Sergey Senozhatsky <sergey.senozhatsky-A/MS7pq9VAU@public.gmane.org>
> Date		: 2009-06-12 19:29 (25 days old)
> References	: http://lkml.org/lkml/2009/6/29/237
> 

Hello Rafael,
it should be listed.

kernel: [ 1048.295158] BUG: scheduling while atomic: ksoftirqd/0/4/0x00000506
kernel: [ 1048.295169] INFO: lockdep is turned off.
kernel: [ 1048.295176] Modules linked in: ppp_deflate zlib_deflate ppp_async crc_ccitt ppp_generic slhc ipv6 fuse loop snd_hda_codec_si3054 snd_hda_codec_realtek snd_hda_intel
snd_hda_codec snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd psmouse i2c_i801 pcspkr serio_raw rng_core soundcore snd_page_alloc
asus_laptop evdev usbhid hid sg sr_mod cdrom sd_mod ata_generic pata_acpi uhci_hcd ricoh_mmc sdhci_pci sdhci ata_piix ide_pci_generic mmc_core led_class ehci_hcd usbcore r8169 mii
kernel: [ 1048.295334] Pid: 4, comm: ksoftirqd/0 Not tainted 2.6.31-rc2-pnv-git1-00254-ga4e2f0a-dirty #2
kernel: [ 1048.295342] Call Trace:
kernel: [ 1048.295361]  [<c1035f55>] __schedule_bug+0x95/0xa0
kernel: [ 1048.295375]  [<c14394f2>] schedule+0x962/0xb60
kernel: [ 1048.295388]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1048.295403]  [<c107b015>] ? print_lock_contention_bug+0x25/0x100
kernel: [ 1048.295416]  [<c143a3df>] __mutex_lock_common+0x17f/0x450
kernel: [ 1048.295428]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1048.295438]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1048.295451]  [<c143a754>] mutex_lock_nested+0x24/0x40
kernel: [ 1048.295461]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1048.295472]  [<c1300355>] tty_throttle+0x25/0x70
kernel: [ 1048.295483]  [<c12fecd7>] n_tty_receive_buf+0x3a7/0x11c0
kernel: [ 1048.295495]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1048.295507]  [<c107b015>] ? print_lock_contention_bug+0x25/0x100
kernel: [ 1048.295519]  [<c107b015>] ? print_lock_contention_bug+0x25/0x100
kernel: [ 1048.295531]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1048.295550]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1048.295561]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1048.295573]  [<c107c709>] ? trace_hardirqs_on+0x19/0x40
kernel: [ 1048.295585]  [<c143c5f7>] ? _spin_unlock_irqrestore+0x47/0x90
kernel: [ 1048.295596]  [<c13012d2>] ? tty_ldisc_try+0x42/0x60
kernel: [ 1048.295608]  [<c13038dd>] pty_write+0x7d/0x90
kernel: [ 1048.295624]  [<f80b3c8a>] ppp_async_push+0x3da/0x4d0 [ppp_async]
kernel: [ 1048.295639]  [<f80b3dc8>] ppp_async_send+0x48/0x70 [ppp_async]
kernel: [ 1048.295655]  [<f8097086>] ppp_push+0x176/0x5f0 [ppp_generic]
kernel: [ 1048.295670]  [<f8097816>] ? ppp_xmit_process+0x26/0x570 [ppp_generic]
kernel: [ 1048.295685]  [<f8097816>] ? ppp_xmit_process+0x26/0x570 [ppp_generic]
kernel: [ 1048.295702]  [<f809784a>] ppp_xmit_process+0x5a/0x570 [ppp_generic]
kernel: [ 1048.295717]  [<f8097fa5>] ? ppp_channel_push+0x95/0xd0 [ppp_generic]
kernel: [ 1048.295733]  [<f8097fb4>] ppp_channel_push+0xa4/0xd0 [ppp_generic]
kernel: [ 1048.295748]  [<f8097ffe>] ppp_output_wakeup+0x1e/0x40 [ppp_generic]
kernel: [ 1048.295760]  [<f80b43f0>] ppp_async_process+0x90/0xa0 [ppp_async]
kernel: [ 1048.295773]  [<c104ee15>] tasklet_action+0xf5/0x110
kernel: [ 1048.295784]  [<c104f9ea>] __do_softirq+0xba/0x240
kernel: [ 1048.295795]  [<c104fbe5>] do_softirq+0x75/0x90
kernel: [ 1048.295807]  [<c10502e2>] ksoftirqd+0x82/0x1a0
kernel: [ 1048.295817]  [<c1050260>] ? ksoftirqd+0x0/0x1a0
kernel: [ 1048.295831]  [<c10646e4>] kthread+0x84/0x90
kernel: [ 1048.295843]  [<c1064660>] ? kthread+0x0/0x90
kernel: [ 1048.295855]  [<c1004217>] kernel_thread_helper+0x7/0x70
kernel: [ 1048.296425] BUG: scheduling while atomic: ksoftirqd/0/4/0x00000406
kernel: [ 1048.296431] INFO: lockdep is turned off.
kernel: [ 1048.296437] Modules linked in: ppp_deflate zlib_deflate ppp_async crc_ccitt ppp_generic slhc ipv6 fuse loop snd_hda_codec_si3054 snd_hda_codec_realtek snd_hda_intel
snd_hda_codec snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd psmouse i2c_i801 pcspkr serio_raw rng_core soundcore snd_page_alloc
asus_laptop evdev usbhid hid sg sr_mod cdrom sd_mod ata_generic pata_acpi uhci_hcd ricoh_mmc sdhci_pci sdhci ata_piix ide_pci_generic mmc_core led_class ehci_hcd usbcore r8169 mii
kernel: [ 1048.296648] Pid: 4, comm: ksoftirqd/0 Not tainted 2.6.31-rc2-pnv-git1-00254-ga4e2f0a-dirty #2
kernel: [ 1048.296661] Call Trace:
kernel: [ 1048.296685]  [<c1035f55>] __schedule_bug+0x95/0xa0
kernel: [ 1048.296706]  [<c14394f2>] schedule+0x962/0xb60
kernel: [ 1048.296723]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1048.296741]  [<c107b015>] ? print_lock_contention_bug+0x25/0x100
kernel: [ 1048.296759]  [<c143a3df>] __mutex_lock_common+0x17f/0x450
kernel: [ 1048.296779]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1048.296794]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1048.296811]  [<c143a754>] mutex_lock_nested+0x24/0x40
kernel: [ 1048.296828]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1048.296842]  [<c1300355>] tty_throttle+0x25/0x70
kernel: [ 1048.296858]  [<c12fecd7>] n_tty_receive_buf+0x3a7/0x11c0
kernel: [ 1048.296872]  [<c143c5f7>] ? _spin_unlock_irqrestore+0x47/0x90
kernel: [ 1048.296885]  [<c1033273>] ? __wake_up+0x53/0x70
kernel: [ 1048.296899]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1048.296916]  [<c107b015>] ? print_lock_contention_bug+0x25/0x100
kernel: [ 1048.296937]  [<c107b015>] ? print_lock_contention_bug+0x25/0x100
kernel: [ 1048.296955]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1048.296973]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1048.296989]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1048.297007]  [<c107c709>] ? trace_hardirqs_on+0x19/0x40
kernel: [ 1048.297023]  [<c143c5f7>] ? _spin_unlock_irqrestore+0x47/0x90
kernel: [ 1048.297041]  [<c13012d2>] ? tty_ldisc_try+0x42/0x60
kernel: [ 1048.297057]  [<c13038dd>] pty_write+0x7d/0x90
kernel: [ 1048.297074]  [<f80b3c8a>] ppp_async_push+0x3da/0x4d0 [ppp_async]
kernel: [ 1048.297096]  [<f80b3dc8>] ppp_async_send+0x48/0x70 [ppp_async]
kernel: [ 1048.297113]  [<f8097086>] ppp_push+0x176/0x5f0 [ppp_generic]
kernel: [ 1048.297135]  [<c1397436>] ? skb_dequeue+0x26/0x80
kernel: [ 1048.297150]  [<c107c709>] ? trace_hardirqs_on+0x19/0x40
kernel: [ 1048.297168]  [<c143c5f7>] ? _spin_unlock_irqrestore+0x47/0x90
kernel: [ 1048.297185]  [<c1397463>] ? skb_dequeue+0x53/0x80
kernel: [ 1048.297204]  [<f8097bcd>] ppp_xmit_process+0x3dd/0x570 [ppp_generic]
kernel: [ 1048.297224]  [<c107c709>] ? trace_hardirqs_on+0x19/0x40
kernel: [ 1048.297238]  [<c1397311>] ? skb_queue_tail+0x41/0x60
kernel: [ 1048.297259]  [<f8097ec7>] ppp_start_xmit+0x167/0x1b0 [ppp_generic]
kernel: [ 1048.297274]  [<c13b8522>] ? __qdisc_run+0x192/0x260
kernel: [ 1048.297290]  [<c13a466c>] dev_hard_start_xmit+0x21c/0x3c0
kernel: [ 1048.297305]  [<c143bdae>] ? _spin_lock+0x6e/0x90
kernel: [ 1048.297321]  [<c13b853c>] __qdisc_run+0x1ac/0x260
kernel: [ 1048.297342]  [<c13a38e7>] net_tx_action+0xf7/0x170
kernel: [ 1048.297356]  [<c104f9ea>] __do_softirq+0xba/0x240
kernel: [ 1048.297375]  [<c104fbe5>] do_softirq+0x75/0x90
kernel: [ 1048.297389]  [<c10502e2>] ksoftirqd+0x82/0x1a0
kernel: [ 1048.297401]  [<c1050260>] ? ksoftirqd+0x0/0x1a0
kernel: [ 1048.297413]  [<c10646e4>] kthread+0x84/0x90
kernel: [ 1048.297433]  [<c1064660>] ? kthread+0x0/0x90
kernel: [ 1048.297453]  [<c1004217>] kernel_thread_helper+0x7/0x70
kernel: [ 1048.298100] BUG: scheduling while atomic: ksoftirqd/0/4/0x00000406
kernel: [ 1048.298115] INFO: lockdep is turned off.
kernel: [ 1048.298127] Modules linked in: ppp_deflate zlib_deflate ppp_async crc_ccitt ppp_generic slhc ipv6 fuse loop snd_hda_codec_si3054 snd_hda_codec_realtek snd_hda_intel
snd_hda_codec snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd psmouse i2c_i801 pcspkr serio_raw rng_core soundcore snd_page_alloc
asus_laptop evdev usbhid hid sg sr_mod cdrom sd_mod ata_generic pata_acpi uhci_hcd ricoh_mmc sdhci_pci sdhci ata_piix ide_pci_generic mmc_core led_class ehci_hcd usbcore r8169 mii
kernel: [ 1048.298482] Pid: 4, comm: ksoftirqd/0 Not tainted 2.6.31-rc2-pnv-git1-00254-ga4e2f0a-dirty #2
kernel: [ 1048.298490] Call Trace:
kernel: [ 1048.298507]  [<c1035f55>] __schedule_bug+0x95/0xa0
kernel: [ 1048.298527]  [<c14394f2>] schedule+0x962/0xb60
kernel: [ 1048.298544]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1048.298562]  [<c107b015>] ? print_lock_contention_bug+0x25/0x100
kernel: [ 1048.298580]  [<c143a3df>] __mutex_lock_common+0x17f/0x450
kernel: [ 1048.298594]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1048.298608]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1048.298626]  [<c143a754>] mutex_lock_nested+0x24/0x40
kernel: [ 1048.298641]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1048.298662]  [<c1300355>] tty_throttle+0x25/0x70
kernel: [ 1048.298683]  [<c12fecd7>] n_tty_receive_buf+0x3a7/0x11c0
kernel: [ 1048.298698]  [<c143c5f7>] ? _spin_unlock_irqrestore+0x47/0x90
kernel: [ 1048.298716]  [<c1033273>] ? __wake_up+0x53/0x70
kernel: [ 1048.298732]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1048.298750]  [<c107b015>] ? print_lock_contention_bug+0x25/0x100
kernel: [ 1048.298764]  [<c107b015>] ? print_lock_contention_bug+0x25/0x100
kernel: [ 1048.298780]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1048.298799]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1048.298817]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1048.298834]  [<c107c709>] ? trace_hardirqs_on+0x19/0x40
kernel: [ 1048.298849]  [<c143c5f7>] ? _spin_unlock_irqrestore+0x47/0x90
kernel: [ 1048.298866]  [<c13012d2>] ? tty_ldisc_try+0x42/0x60
kernel: [ 1048.298882]  [<c13038dd>] pty_write+0x7d/0x90
kernel: [ 1048.298897]  [<f80b3c8a>] ppp_async_push+0x3da/0x4d0 [ppp_async]
kernel: [ 1048.298916]  [<f80b3dc8>] ppp_async_send+0x48/0x70 [ppp_async]
kernel: [ 1048.298944]  [<f8097086>] ppp_push+0x176/0x5f0 [ppp_generic]
kernel: [ 1048.298963]  [<c1397436>] ? skb_dequeue+0x26/0x80
kernel: [ 1048.298980]  [<c107c709>] ? trace_hardirqs_on+0x19/0x40
kernel: [ 1048.299000]  [<c143c5f7>] ? _spin_unlock_irqrestore+0x47/0x90
kernel: [ 1048.299013]  [<c1397463>] ? skb_dequeue+0x53/0x80
kernel: [ 1048.299038]  [<f8097bcd>] ppp_xmit_process+0x3dd/0x570 [ppp_generic]
kernel: [ 1048.299054]  [<c107c709>] ? trace_hardirqs_on+0x19/0x40
kernel: [ 1048.299074]  [<c1397311>] ? skb_queue_tail+0x41/0x60
kernel: [ 1048.299092]  [<f8097ec7>] ppp_start_xmit+0x167/0x1b0 [ppp_generic]
kernel: [ 1048.299110]  [<c13b8522>] ? __qdisc_run+0x192/0x260
kernel: [ 1048.299130]  [<c13a466c>] dev_hard_start_xmit+0x21c/0x3c0
kernel: [ 1048.299145]  [<c143bdae>] ? _spin_lock+0x6e/0x90
kernel: [ 1048.299168]  [<c13b853c>] __qdisc_run+0x1ac/0x260
kernel: [ 1048.299186]  [<c13a38e7>] net_tx_action+0xf7/0x170
kernel: [ 1048.299208]  [<c104f9ea>] __do_softirq+0xba/0x240
kernel: [ 1048.299226]  [<c104fbe5>] do_softirq+0x75/0x90
kernel: [ 1048.299240]  [<c10502e2>] ksoftirqd+0x82/0x1a0
kernel: [ 1048.299253]  [<c1050260>] ? ksoftirqd+0x0/0x1a0
kernel: [ 1048.299268]  [<c10646e4>] kthread+0x84/0x90
kernel: [ 1048.299288]  [<c1064660>] ? kthread+0x0/0x90
kernel: [ 1048.299301]  [<c1004217>] kernel_thread_helper+0x7/0x70
kernel: [ 1067.299845] BUG: scheduling while atomic: ksoftirqd/0/4/0x00000506
kernel: [ 1067.299854] INFO: lockdep is turned off.
kernel: [ 1067.299860] Modules linked in: ppp_deflate zlib_deflate ppp_async crc_ccitt ppp_generic slhc ipv6 fuse loop snd_hda_codec_si3054 snd_hda_codec_realtek snd_hda_intel
snd_hda_codec snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd psmouse i2c_i801 pcspkr serio_raw rng_core soundcore snd_page_alloc
asus_laptop evdev usbhid hid sg sr_mod cdrom sd_mod ata_generic pata_acpi uhci_hcd ricoh_mmc sdhci_pci sdhci ata_piix ide_pci_generic mmc_core led_class ehci_hcd usbcore r8169 mii
kernel: [ 1067.300216] Pid: 4, comm: ksoftirqd/0 Not tainted 2.6.31-rc2-pnv-git1-00254-ga4e2f0a-dirty #2
kernel: [ 1067.300229] Call Trace:
kernel: [ 1067.300249]  [<c1035f55>] __schedule_bug+0x95/0xa0
kernel: [ 1067.300270]  [<c14394f2>] schedule+0x962/0xb60
kernel: [ 1067.300289]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1067.300306]  [<c107b015>] ? print_lock_contention_bug+0x25/0x100
kernel: [ 1067.300324]  [<c143a3df>] __mutex_lock_common+0x17f/0x450
kernel: [ 1067.300347]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1067.300365]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1067.300384]  [<c143a754>] mutex_lock_nested+0x24/0x40
kernel: [ 1067.300400]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1067.300418]  [<c1300355>] tty_throttle+0x25/0x70
kernel: [ 1067.300438]  [<c12fecd7>] n_tty_receive_buf+0x3a7/0x11c0
kernel: [ 1067.300452]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1067.300468]  [<c107b015>] ? print_lock_contention_bug+0x25/0x100
kernel: [ 1067.300485]  [<c107b015>] ? print_lock_contention_bug+0x25/0x100
kernel: [ 1067.300502]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1067.300518]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1067.300535]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1067.300554]  [<c107c709>] ? trace_hardirqs_on+0x19/0x40
kernel: [ 1067.300569]  [<c143c5f7>] ? _spin_unlock_irqrestore+0x47/0x90
kernel: [ 1067.300585]  [<c13012d2>] ? tty_ldisc_try+0x42/0x60
kernel: [ 1067.300600]  [<c13038dd>] pty_write+0x7d/0x90
kernel: [ 1067.300621]  [<f80b3c8a>] ppp_async_push+0x3da/0x4d0 [ppp_async]
kernel: [ 1067.300640]  [<f80b3dc8>] ppp_async_send+0x48/0x70 [ppp_async]
kernel: [ 1067.300665]  [<f8097086>] ppp_push+0x176/0x5f0 [ppp_generic]
kernel: [ 1067.300687]  [<f8097816>] ? ppp_xmit_process+0x26/0x570 [ppp_generic]
kernel: [ 1067.300709]  [<f8097816>] ? ppp_xmit_process+0x26/0x570 [ppp_generic]
kernel: [ 1067.300731]  [<f809784a>] ppp_xmit_process+0x5a/0x570 [ppp_generic]
kernel: [ 1067.300746]  [<f8097fa5>] ? ppp_channel_push+0x95/0xd0 [ppp_generic]
kernel: [ 1067.300763]  [<f8097fb4>] ppp_channel_push+0xa4/0xd0 [ppp_generic]
kernel: [ 1067.300781]  [<f8097ffe>] ppp_output_wakeup+0x1e/0x40 [ppp_generic]
kernel: [ 1067.300804]  [<f80b43f0>] ppp_async_process+0x90/0xa0 [ppp_async]
kernel: [ 1067.300822]  [<c104ee15>] tasklet_action+0xf5/0x110
kernel: [ 1067.300841]  [<c104f9ea>] __do_softirq+0xba/0x240
kernel: [ 1067.300855]  [<c104fbe5>] do_softirq+0x75/0x90
kernel: [ 1067.300873]  [<c10502e2>] ksoftirqd+0x82/0x1a0
kernel: [ 1067.300886]  [<c1050260>] ? ksoftirqd+0x0/0x1a0
kernel: [ 1067.300901]  [<c10646e4>] kthread+0x84/0x90
kernel: [ 1067.300918]  [<c1064660>] ? kthread+0x0/0x90
kernel: [ 1067.300937]  [<c1004217>] kernel_thread_helper+0x7/0x70
kernel: [ 1067.301595] BUG: scheduling while atomic: ksoftirqd/0/4/0x00000406
kernel: [ 1067.301608] INFO: lockdep is turned off.
kernel: [ 1067.301617] Modules linked in: ppp_deflate zlib_deflate ppp_async crc_ccitt ppp_generic slhc ipv6 fuse loop snd_hda_codec_si3054 snd_hda_codec_realtek snd_hda_intel
snd_hda_codec snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd psmouse i2c_i801 pcspkr serio_raw rng_core soundcore snd_page_alloc
asus_laptop evdev usbhid hid sg sr_mod cdrom sd_mod ata_generic pata_acpi uhci_hcd ricoh_mmc sdhci_pci sdhci ata_piix ide_pci_generic mmc_core led_class ehci_hcd usbcore r8169 mii
kernel: [ 1067.301969] Pid: 4, comm: ksoftirqd/0 Not tainted 2.6.31-rc2-pnv-git1-00254-ga4e2f0a-dirty #2
kernel: [ 1067.301981] Call Trace:
kernel: [ 1067.301998]  [<c1035f55>] __schedule_bug+0x95/0xa0
kernel: [ 1067.302018]  [<c14394f2>] schedule+0x962/0xb60
kernel: [ 1067.302031]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1067.302052]  [<c107b015>] ? print_lock_contention_bug+0x25/0x100
kernel: [ 1067.302072]  [<c143a3df>] __mutex_lock_common+0x17f/0x450
kernel: [ 1067.302092]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1067.302110]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1067.302126]  [<c143a754>] mutex_lock_nested+0x24/0x40
kernel: [ 1067.302139]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1067.302152]  [<c1300355>] tty_throttle+0x25/0x70
kernel: [ 1067.302167]  [<c12fecd7>] n_tty_receive_buf+0x3a7/0x11c0
kernel: [ 1067.302188]  [<c143c5f7>] ? _spin_unlock_irqrestore+0x47/0x90
kernel: [ 1067.302203]  [<c1033273>] ? __wake_up+0x53/0x70
kernel: [ 1067.302219]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1067.302234]  [<c107b015>] ? print_lock_contention_bug+0x25/0x100
kernel: [ 1067.302251]  [<c107b015>] ? print_lock_contention_bug+0x25/0x100
kernel: [ 1067.302268]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1067.302284]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1067.302301]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1067.302319]  [<c107c709>] ? trace_hardirqs_on+0x19/0x40
kernel: [ 1067.302339]  [<c143c5f7>] ? _spin_unlock_irqrestore+0x47/0x90
kernel: [ 1067.302352]  [<c13012d2>] ? tty_ldisc_try+0x42/0x60
kernel: [ 1067.302370]  [<c13038dd>] pty_write+0x7d/0x90
kernel: [ 1067.302389]  [<f80b3c8a>] ppp_async_push+0x3da/0x4d0 [ppp_async]
kernel: [ 1067.302412]  [<f80b3dc8>] ppp_async_send+0x48/0x70 [ppp_async]
kernel: [ 1067.302437]  [<f8097086>] ppp_push+0x176/0x5f0 [ppp_generic]
kernel: [ 1067.302454]  [<c1397436>] ? skb_dequeue+0x26/0x80
kernel: [ 1067.302473]  [<c107c709>] ? trace_hardirqs_on+0x19/0x40
kernel: [ 1067.302490]  [<c143c5f7>] ? _spin_unlock_irqrestore+0x47/0x90
kernel: [ 1067.302503]  [<c1397463>] ? skb_dequeue+0x53/0x80
kernel: [ 1067.302526]  [<f8097bcd>] ppp_xmit_process+0x3dd/0x570 [ppp_generic]
kernel: [ 1067.302541]  [<c107c709>] ? trace_hardirqs_on+0x19/0x40
kernel: [ 1067.302558]  [<c1397311>] ? skb_queue_tail+0x41/0x60
kernel: [ 1067.302577]  [<f8097ec7>] ppp_start_xmit+0x167/0x1b0 [ppp_generic]
kernel: [ 1067.302601]  [<c13b8522>] ? __qdisc_run+0x192/0x260
kernel: [ 1067.302622]  [<c13a466c>] dev_hard_start_xmit+0x21c/0x3c0
kernel: [ 1067.302640]  [<c143bdae>] ? _spin_lock+0x6e/0x90
kernel: [ 1067.302654]  [<c13b853c>] __qdisc_run+0x1ac/0x260
kernel: [ 1067.302675]  [<c13a38e7>] net_tx_action+0xf7/0x170
kernel: [ 1067.302698]  [<c104f9ea>] __do_softirq+0xba/0x240
kernel: [ 1067.302713]  [<c104fbe5>] do_softirq+0x75/0x90
kernel: [ 1067.302728]  [<c10502e2>] ksoftirqd+0x82/0x1a0
kernel: [ 1067.302745]  [<c1050260>] ? ksoftirqd+0x0/0x1a0
kernel: [ 1067.302761]  [<c10646e4>] kthread+0x84/0x90
kernel: [ 1067.302783]  [<c1064660>] ? kthread+0x0/0x90
kernel: [ 1067.302798]  [<c1004217>] kernel_thread_helper+0x7/0x70
kernel: [ 1076.490281] BUG: scheduling while atomic: ksoftirqd/0/4/0x00000406
kernel: [ 1076.490290] INFO: lockdep is turned off.
kernel: [ 1076.490296] Modules linked in: ppp_deflate zlib_deflate ppp_async crc_ccitt ppp_generic slhc ipv6 fuse loop snd_hda_codec_si3054 snd_hda_codec_realtek snd_hda_intel
snd_hda_codec snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd psmouse i2c_i801 pcspkr serio_raw rng_core soundcore snd_page_alloc
asus_laptop evdev usbhid hid sg sr_mod cdrom sd_mod ata_generic pata_acpi uhci_hcd ricoh_mmc sdhci_pci sdhci ata_piix ide_pci_generic mmc_core led_class ehci_hcd usbcore r8169 mii
kernel: [ 1076.490452] Pid: 4, comm: ksoftirqd/0 Not tainted 2.6.31-rc2-pnv-git1-00254-ga4e2f0a-dirty #2
kernel: [ 1076.490460] Call Trace:
kernel: [ 1076.490478]  [<c1035f55>] __schedule_bug+0x95/0xa0
kernel: [ 1076.490492]  [<c14394f2>] schedule+0x962/0xb60
kernel: [ 1076.490506]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1076.490521]  [<c107b015>] ? print_lock_contention_bug+0x25/0x100
kernel: [ 1076.490534]  [<c143a3df>] __mutex_lock_common+0x17f/0x450
kernel: [ 1076.490545]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1076.490556]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1076.490568]  [<c143a754>] mutex_lock_nested+0x24/0x40
kernel: [ 1076.490579]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1076.490590]  [<c1300355>] tty_throttle+0x25/0x70
kernel: [ 1076.490601]  [<c12fecd7>] n_tty_receive_buf+0x3a7/0x11c0
kernel: [ 1076.490613]  [<c143c5f7>] ? _spin_unlock_irqrestore+0x47/0x90
kernel: [ 1076.490625]  [<c1033273>] ? __wake_up+0x53/0x70
kernel: [ 1076.490636]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1076.490648]  [<c107b015>] ? print_lock_contention_bug+0x25/0x100
kernel: [ 1076.490659]  [<c107b015>] ? print_lock_contention_bug+0x25/0x100
kernel: [ 1076.490672]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1076.490682]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1076.490693]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1076.490705]  [<c107c709>] ? trace_hardirqs_on+0x19/0x40
kernel: [ 1076.490717]  [<c143c5f7>] ? _spin_unlock_irqrestore+0x47/0x90
kernel: [ 1076.490728]  [<c13012d2>] ? tty_ldisc_try+0x42/0x60
kernel: [ 1076.490741]  [<c13038dd>] pty_write+0x7d/0x90
kernel: [ 1076.490757]  [<f80b3c8a>] ppp_async_push+0x3da/0x4d0 [ppp_async]
kernel: [ 1076.490774]  [<f80b3dc8>] ppp_async_send+0x48/0x70 [ppp_async]
kernel: [ 1076.490790]  [<f8097086>] ppp_push+0x176/0x5f0 [ppp_generic]
kernel: [ 1076.490802]  [<c1397436>] ? skb_dequeue+0x26/0x80
kernel: [ 1076.490815]  [<c107c709>] ? trace_hardirqs_on+0x19/0x40
kernel: [ 1076.490835]  [<c143c5f7>] ? _spin_unlock_irqrestore+0x47/0x90
kernel: [ 1076.490846]  [<c1397463>] ? skb_dequeue+0x53/0x80
kernel: [ 1076.490861]  [<f8097bcd>] ppp_xmit_process+0x3dd/0x570 [ppp_generic]
kernel: [ 1076.490874]  [<c107c709>] ? trace_hardirqs_on+0x19/0x40
kernel: [ 1076.490885]  [<c1397311>] ? skb_queue_tail+0x41/0x60
kernel: [ 1076.490900]  [<f8097ec7>] ppp_start_xmit+0x167/0x1b0 [ppp_generic]
kernel: [ 1076.490912]  [<c13b8522>] ? __qdisc_run+0x192/0x260
kernel: [ 1076.490925]  [<c13a466c>] dev_hard_start_xmit+0x21c/0x3c0
kernel: [ 1076.490937]  [<c143bdae>] ? _spin_lock+0x6e/0x90
kernel: [ 1076.490948]  [<c13b853c>] __qdisc_run+0x1ac/0x260
kernel: [ 1076.490960]  [<c13a38e7>] net_tx_action+0xf7/0x170
kernel: [ 1076.490972]  [<c104f9ea>] __do_softirq+0xba/0x240
kernel: [ 1076.490984]  [<c104fbe5>] do_softirq+0x75/0x90
kernel: [ 1076.490995]  [<c10502e2>] ksoftirqd+0x82/0x1a0
kernel: [ 1076.491005]  [<c1050260>] ? ksoftirqd+0x0/0x1a0
kernel: [ 1076.491017]  [<c10646e4>] kthread+0x84/0x90
kernel: [ 1076.491029]  [<c1064660>] ? kthread+0x0/0x90
kernel: [ 1076.491041]  [<c1004217>] kernel_thread_helper+0x7/0x70
kernel: [ 1076.491622] BUG: scheduling while atomic: ksoftirqd/0/4/0x00000406
kernel: [ 1076.491629] INFO: lockdep is turned off.
kernel: [ 1076.491635] Modules linked in: ppp_deflate zlib_deflate ppp_async crc_ccitt ppp_generic slhc ipv6 fuse loop snd_hda_codec_si3054 snd_hda_codec_realtek snd_hda_intel
snd_hda_codec snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd psmouse i2c_i801 pcspkr serio_raw rng_core soundcore snd_page_alloc
asus_laptop evdev usbhid hid sg sr_mod cdrom sd_mod ata_generic pata_acpi uhci_hcd ricoh_mmc sdhci_pci sdhci ata_piix ide_pci_generic mmc_core led_class ehci_hcd usbcore r8169 mii
kernel: [ 1076.491786] Pid: 4, comm: ksoftirqd/0 Not tainted 2.6.31-rc2-pnv-git1-00254-ga4e2f0a-dirty #2
kernel: [ 1076.491794] Call Trace:
kernel: [ 1076.491807]  [<c1035f55>] __schedule_bug+0x95/0xa0
kernel: [ 1076.491818]  [<c14394f2>] schedule+0x962/0xb60
kernel: [ 1076.491829]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1076.491842]  [<c107b015>] ? print_lock_contention_bug+0x25/0x100
kernel: [ 1076.491856]  [<c143a3df>] __mutex_lock_common+0x17f/0x450
kernel: [ 1076.491867]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1076.491877]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1076.491889]  [<c143a754>] mutex_lock_nested+0x24/0x40
kernel: [ 1076.491900]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1076.491910]  [<c1300355>] tty_throttle+0x25/0x70
kernel: [ 1076.491921]  [<c12fecd7>] n_tty_receive_buf+0x3a7/0x11c0
kernel: [ 1076.491933]  [<c143c5f7>] ? _spin_unlock_irqrestore+0x47/0x90
kernel: [ 1076.491945]  [<c1033273>] ? __wake_up+0x53/0x70
kernel: [ 1076.491955]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1076.491967]  [<c107b015>] ? print_lock_contention_bug+0x25/0x100
kernel: [ 1076.491979]  [<c107b015>] ? print_lock_contention_bug+0x25/0x100
kernel: [ 1076.491991]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1076.492001]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1076.492012]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1076.492024]  [<c107c709>] ? trace_hardirqs_on+0x19/0x40
kernel: [ 1076.492035]  [<c143c5f7>] ? _spin_unlock_irqrestore+0x47/0x90
kernel: [ 1076.492047]  [<c13012d2>] ? tty_ldisc_try+0x42/0x60
kernel: [ 1076.492058]  [<c13038dd>] pty_write+0x7d/0x90
kernel: [ 1076.492072]  [<f80b3c8a>] ppp_async_push+0x3da/0x4d0 [ppp_async]
kernel: [ 1076.492088]  [<f80b3dc8>] ppp_async_send+0x48/0x70 [ppp_async]
kernel: [ 1076.492103]  [<f8097086>] ppp_push+0x176/0x5f0 [ppp_generic]
kernel: [ 1076.492114]  [<c1397436>] ? skb_dequeue+0x26/0x80
kernel: [ 1076.492126]  [<c107c709>] ? trace_hardirqs_on+0x19/0x40
kernel: [ 1076.492138]  [<c143c5f7>] ? _spin_unlock_irqrestore+0x47/0x90
kernel: [ 1076.492149]  [<c1397463>] ? skb_dequeue+0x53/0x80
kernel: [ 1076.492164]  [<f8097bcd>] ppp_xmit_process+0x3dd/0x570 [ppp_generic]
kernel: [ 1076.492176]  [<c107c709>] ? trace_hardirqs_on+0x19/0x40
kernel: [ 1076.492187]  [<c1397311>] ? skb_queue_tail+0x41/0x60
kernel: [ 1076.492202]  [<f8097ec7>] ppp_start_xmit+0x167/0x1b0 [ppp_generic]
kernel: [ 1076.492213]  [<c13b8522>] ? __qdisc_run+0x192/0x260
kernel: [ 1076.492225]  [<c13a466c>] dev_hard_start_xmit+0x21c/0x3c0
kernel: [ 1076.492236]  [<c143bdae>] ? _spin_lock+0x6e/0x90
kernel: [ 1076.492248]  [<c13b853c>] __qdisc_run+0x1ac/0x260
kernel: [ 1076.492259]  [<c13a38e7>] net_tx_action+0xf7/0x170
kernel: [ 1076.492270]  [<c104f9ea>] __do_softirq+0xba/0x240
kernel: [ 1076.492282]  [<c104fbe5>] do_softirq+0x75/0x90
kernel: [ 1076.492292]  [<c10502e2>] ksoftirqd+0x82/0x1a0
kernel: [ 1076.492302]  [<c1050260>] ? ksoftirqd+0x0/0x1a0
kernel: [ 1076.492313]  [<c10646e4>] kthread+0x84/0x90
kernel: [ 1076.492325]  [<c1064660>] ? kthread+0x0/0x90
kernel: [ 1076.492336]  [<c1004217>] kernel_thread_helper+0x7/0x70
kernel: [ 1117.962740] BUG: scheduling while atomic: ksoftirqd/0/4/0x00000406
kernel: [ 1117.962750] INFO: lockdep is turned off.
kernel: [ 1117.962756] Modules linked in: ppp_deflate zlib_deflate ppp_async crc_ccitt ppp_generic slhc ipv6 fuse loop snd_hda_codec_si3054 snd_hda_codec_realtek snd_hda_intel
snd_hda_codec snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd psmouse i2c_i801 pcspkr serio_raw rng_core soundcore snd_page_alloc
asus_laptop evdev usbhid hid sg sr_mod cdrom sd_mod ata_generic pata_acpi uhci_hcd ricoh_mmc sdhci_pci sdhci ata_piix ide_pci_generic mmc_core led_class ehci_hcd usbcore r8169 mii
kernel: [ 1117.962910] Pid: 4, comm: ksoftirqd/0 Not tainted 2.6.31-rc2-pnv-git1-00254-ga4e2f0a-dirty #2
kernel: [ 1117.962918] Call Trace:
kernel: [ 1117.962937]  [<c1035f55>] __schedule_bug+0x95/0xa0
kernel: [ 1117.962950]  [<c14394f2>] schedule+0x962/0xb60
kernel: [ 1117.962963]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1117.962978]  [<c107b015>] ? print_lock_contention_bug+0x25/0x100
kernel: [ 1117.962991]  [<c143a3df>] __mutex_lock_common+0x17f/0x450
kernel: [ 1117.963002]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1117.963013]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1117.963025]  [<c143a754>] mutex_lock_nested+0x24/0x40
kernel: [ 1117.963035]  [<c1300355>] ? tty_throttle+0x25/0x70
kernel: [ 1117.963046]  [<c1300355>] tty_throttle+0x25/0x70
kernel: [ 1117.963057]  [<c12fecd7>] n_tty_receive_buf+0x3a7/0x11c0
kernel: [ 1117.963069]  [<c143c5f7>] ? _spin_unlock_irqrestore+0x47/0x90
kernel: [ 1117.963081]  [<c1033273>] ? __wake_up+0x53/0x70
kernel: [ 1117.963092]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1117.963103]  [<c107b015>] ? print_lock_contention_bug+0x25/0x100
kernel: [ 1117.963115]  [<c107b015>] ? print_lock_contention_bug+0x25/0x100
kernel: [ 1117.963127]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1117.963138]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1117.963149]  [<c13012b5>] ? tty_ldisc_try+0x25/0x60
kernel: [ 1117.963161]  [<c107c709>] ? trace_hardirqs_on+0x19/0x40
kernel: [ 1117.963172]  [<c143c5f7>] ? _spin_unlock_irqrestore+0x47/0x90
kernel: [ 1117.963184]  [<c13012d2>] ? tty_ldisc_try+0x42/0x60
kernel: [ 1117.963195]  [<c13038dd>] pty_write+0x7d/0x90
kernel: [ 1117.963210]  [<f80b3c8a>] ppp_async_push+0x3da/0x4d0 [ppp_async]
kernel: [ 1117.963263]  [<f80b3dc8>] ppp_async_send+0x48/0x70 [ppp_async]
kernel: [ 1117.963285]  [<f8097086>] ppp_push+0x176/0x5f0 [ppp_generic]
kernel: [ 1117.963304]  [<c1397436>] ? skb_dequeue+0x26/0x80
kernel: [ 1117.963319]  [<c107c709>] ? trace_hardirqs_on+0x19/0x40
kernel: [ 1117.963335]  [<c143c5f7>] ? _spin_unlock_irqrestore+0x47/0x90
kernel: [ 1117.963350]  [<c1397463>] ? skb_dequeue+0x53/0x80
kernel: [ 1117.963369]  [<f8097bcd>] ppp_xmit_process+0x3dd/0x570 [ppp_generic]
kernel: [ 1117.963385]  [<c107c709>] ? trace_hardirqs_on+0x19/0x40
kernel: [ 1117.963403]  [<c1397311>] ? skb_queue_tail+0x41/0x60
kernel: [ 1117.963420]  [<f8097ec7>] ppp_start_xmit+0x167/0x1b0 [ppp_generic]
kernel: [ 1117.963440]  [<c13b8522>] ? __qdisc_run+0x192/0x260
kernel: [ 1117.963459]  [<c13a466c>] dev_hard_start_xmit+0x21c/0x3c0
kernel: [ 1117.963473]  [<c143bdae>] ? _spin_lock+0x6e/0x90
kernel: [ 1117.963489]  [<c13b853c>] __qdisc_run+0x1ac/0x260
kernel: [ 1117.963502]  [<c13a38e7>] net_tx_action+0xf7/0x170
kernel: [ 1117.963521]  [<c104f9ea>] __do_softirq+0xba/0x240
kernel: [ 1117.963536]  [<c1272008>] ? trace_hardirqs_on_thunk+0xc/0x10
kernel: [ 1117.963552]  [<c104fbe5>] do_softirq+0x75/0x90
kernel: [ 1117.963569]  [<c10502e2>] ksoftirqd+0x82/0x1a0
kernel: [ 1117.963585]  [<c1050260>] ? ksoftirqd+0x0/0x1a0
kernel: [ 1117.963602]  [<c10646e4>] kthread+0x84/0x90
kernel: [ 1117.963624]  [<c1064660>] ? kthread+0x0/0x90
kernel: [ 1117.963641]  [<c1004217>] kernel_thread_helper+0x7/0x70

	Sergey

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

Re: [Bug #13522] BUG: scheduling while atomic

[Rafael J. Wysocki]

On Tuesday 07 July 2009, Sergey Senozhatsky wrote:
> On (07/07/09 02:00), Rafael J. Wysocki wrote:
> > 
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.30.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13522
> > Subject		: BUG: scheduling while atomic
> > Submitter	: Sergey Senozhatsky <sergey.senozhatsky@mail.by>
> > Date		: 2009-06-12 19:29 (25 days old)
> > References	: http://lkml.org/lkml/2009/6/29/237
> > 
> 
> Hello Rafael,
> it should be listed.

Thanks for the update.

Best,
Rafael

[Bug #13659] iwlagn (4965): no wireless due to RFKILL problem

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13659
Subject		: iwlagn (4965): no wireless due to RFKILL problem
Submitter	: Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
Date		: 2009-06-26 13:36 (11 days old)
References	: http://lkml.org/lkml/2009/6/26/127
Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Patch		: http://lkml.org/lkml/2009/6/27/35

Re: [Bug #13659] iwlagn (4965): no wireless due to RFKILL problem

[Frans Pop]

On Tuesday 07 July 2009, Rafael J. Wysocki wrote:
> The following bug entry is on the current list of known regressions
> from 2.6.30.  Please verify if it still should be listed and let me
> know (either way).
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13659
> Subject	: iwlagn (4965): no wireless due to RFKILL problem
> Submitter	: Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
> Date		: 2009-06-26 13:36 (11 days old)
> References	: http://lkml.org/lkml/2009/6/26/127
> Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
> Patch		: http://lkml.org/lkml/2009/6/27/35

Should remain listed. Patch is available but not yet upstream.

Cheers,
FJP

Re: [Bug #13659] iwlagn (4965): no wireless due to RFKILL problem

[Rafael J. Wysocki]

On Tuesday 07 July 2009, Frans Pop wrote:
> On Tuesday 07 July 2009, Rafael J. Wysocki wrote:
> > The following bug entry is on the current list of known regressions
> > from 2.6.30.  Please verify if it still should be listed and let me
> > know (either way).
> >
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13659
> > Subject	: iwlagn (4965): no wireless due to RFKILL problem
> > Submitter	: Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
> > Date		: 2009-06-26 13:36 (11 days old)
> > References	: http://lkml.org/lkml/2009/6/26/127
> > Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
> > Patch		: http://lkml.org/lkml/2009/6/27/35
> 
> Should remain listed. Patch is available but not yet upstream.

Thanks for the update.

Best,
Rafael

[Bug #13656] 2.6.31-rc1 crashes randomly on my Machine.

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13656
Subject		: 2.6.31-rc1 crashes randomly on my Machine.
Submitter	: Zeno Davatz <zdavatz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-06-26 08:56 (11 days old)
References	: http://lkml.org/lkml/2009/6/26/27

[Bug #13645] NULL pointer dereference at (null) (level2_spare_pgt)

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13645
Subject		: NULL pointer dereference at (null) (level2_spare_pgt)
Submitter	: poornima nayak <mpnayak-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Date		: 2009-06-17 17:56 (20 days old)
References	: http://lkml.org/lkml/2009/6/17/194

[Bug #13643] Touchpad lost synchronization after resume from suspend to RAM

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13643
Subject		: Touchpad lost synchronization after resume from suspend to RAM
Submitter	: Cijoml Cijomlovic Cijomlov <cijoml-VIXq6x/3rUk@public.gmane.org>
Date		: 2009-06-28 10:42 (9 days old)
References	: http://lkml.org/lkml/2009/6/23/365
		  2.6.30-rc1: touchpad disabled
		  http://lkml.org/lkml/2009/6/25/256
Handled-By	: Thadeu Lima de Souza Cascardo <cascardo-DmMZpsCg3uxeGPcbtGPokg@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/34075/

[Bug #13657] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13657
Subject		: Linux-2.6.31-rc1 Fails To Recognize Some USB Disks
Submitter	: Tarkan Erimer <tarkan.erimer-AMZSHK9Z0TXlajqSnzHT9w@public.gmane.org>
Date		: 2009-06-26 10:03 (11 days old)
References	: http://lkml.org/lkml/2009/6/26/34

Re: [Bug #13657] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

[Tarkan Erimer]

On 07/07/2009 03:00 AM, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.30.  Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13657
> Subject		: Linux-2.6.31-rc1 Fails To Recognize Some USB Disks
> Submitter	: Tarkan Erimer<tarkan.erimer-AMZSHK9Z0TXlajqSnzHT9w@public.gmane.org>
> Date		: 2009-06-26 10:03 (11 days old)
> References	: http://lkml.org/lkml/2009/6/26/34
>
>
>    

I confirm that, as of Linux-2.6.31-rc3, this bug still exists.

[Bug #13650] Problem with alloc_arch_preferred_bootmem() on powerpc

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13650
Subject		: Problem with alloc_arch_preferred_bootmem() on powerpc
Submitter	: Sean MacLennan <smaclennan-Qtffpm9i2AVWk0Htik3J/w@public.gmane.org>
Date		: 2009-06-20 19:48 (17 days old)
References	: http://marc.info/?l=linuxppc-embedded&m=124552732411775&w=4

Re: [Bug #13650] Problem with alloc_arch_preferred_bootmem() on powerpc

[Sean MacLennan]

On Tue,  7 Jul 2009 01:49:28 +0200 (CEST)
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.30.  Please verify if it still should be listed and let me
> know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13650
> Subject		: Problem with alloc_arch_preferred_bootmem()
> on powerpc Submitter	: Sean MacLennan <smaclennan@pikatech.com>
> Date		: 2009-06-20 19:48 (17 days old)
> References	:
> http://marc.info/?l=linuxppc-embedded&m=124552732411775&w=4
> 
> 

Fixed!

Cheers,
   Sean

[Bug #13652] scheduling while atomic: pptpgw

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13652
Subject		: scheduling while atomic: pptpgw
Submitter	: Sergey Senozhatsky <sergey.senozhatsky-A/MS7pq9VAU@public.gmane.org>
Date		: 2009-06-19 21:15 (18 days old)
References	: http://lkml.org/lkml/2009/6/19/237

[Bug #13667] drm: display arifacts when X.Org is stopped

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13667
Subject		: drm: display arifacts when X.Org is stopped
Submitter	: Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
Date		: 2009-06-27 18:52 (10 days old)
References	: http://lkml.org/lkml/2009/6/27/105

Re: [Bug #13667] drm: display arifacts when X.Org is stopped

[Frans Pop]

On Tuesday 07 July 2009, Rafael J. Wysocki wrote:
> The following bug entry is on the current list of known regressions
> from 2.6.30.  Please verify if it still should be listed and let me
> know (either way).
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13667
> Subject	: drm: display arifacts when X.Org is stopped
> Submitter	: Frans Pop <elendil@planet.nl>
> Date		: 2009-06-27 18:52 (10 days old)
> References	: http://lkml.org/lkml/2009/6/27/105

Problem is still there with -rc2. Dave said he'd try to reproduce, but 
I've not heard back from him yet.

Cheers,
FJP

Re: [Bug #13667] drm: display arifacts when X.Org is stopped

[Dave Airlie]

On Wed, Jul 8, 2009 at 10:32 AM, Frans Pop<elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org> wrote:
> On Tuesday 07 July 2009, Rafael J. Wysocki wrote:
>> The following bug entry is on the current list of known regressions
>> from 2.6.30.  Please verify if it still should be listed and let me
>> know (either way).
>>
>> Bug-Entry     : http://bugzilla.kernel.org/show_bug.cgi?id=13667
>> Subject       : drm: display arifacts when X.Org is stopped
>> Submitter     : Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
>> Date          : 2009-06-27 18:52 (10 days old)
>> References    : http://lkml.org/lkml/2009/6/27/105
>
> Problem is still there with -rc2. Dave said he'd try to reproduce, but
> I've not heard back from him yet.
>

I have my 2510p, I just have to get a PSU to run it, at least I hope its just
the PSU.

Don't suppose you have a 32-bit install you could also test with?

Hopefully I can reproduce it on my box locally, otherwise its really
messy dealing with 2 drivers smashing on the same hw.

btw you get any wierd text mode issues without vesafb?

Dave.

Re: [Bug #13667] drm: display arifacts when X.Org is stopped

[Frans Pop]

On Wednesday 08 July 2009, Dave Airlie wrote:
> On Wed, Jul 8, 2009 at 10:32 AM, Frans Pop<elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org> wrote:
> > On Tuesday 07 July 2009, Rafael J. Wysocki wrote:
> >> The following bug entry is on the current list of known regressions
> >> from 2.6.30.  Please verify if it still should be listed and let me
> >> know (either way).
> >>
> >> Bug-Entry     : http://bugzilla.kernel.org/show_bug.cgi?id=13667
> >> Subject       : drm: display arifacts when X.Org is stopped
> >> Submitter     : Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
> >> Date          : 2009-06-27 18:52 (10 days old)
> >> References    : http://lkml.org/lkml/2009/6/27/105
> >
> > Problem is still there with -rc2. Dave said he'd try to reproduce,
> > but I've not heard back from him yet.
>
> Don't suppose you have a 32-bit install you could also test with?

You're in luck...
I also get artifacts, though less severe, with .31-rc2 on my Toshiba 
Satellite A40 (32-bit kernel) during logout from X.Org. The switch is 
clean with .30.

> Hopefully I can reproduce it on my box locally, otherwise its really
> messy dealing with 2 drivers smashing on the same hw.

Not sure why you're saying that. I would think VESA fb + X.Org is quite 
common and also a very valid use case [1]. How else would you get the 
pretty kernel boot logo? ;-)

> btw you get any wierd text mode issues without vesafb?

If I boot .31-rc2 without vga=791 I don't get the artifacts. The artifacts 
also do not appear if I boot with 'nopat'. Checked on both systems.

Note that I reported a similar issue once before, also reproducible on 
both systems. In that case it was a bug in PAT which was eventually fixed. 
See: http://bugzilla.kernel.org/show_bug.cgi?id=10843.

Given that 'nopat' helps, you may want to check with Suresh on this one.

Cheers,
FJP

[1] I'd even go so far as to feel it should be a standard test case for 
video driver developers, given that this is the third time it's shown 
regressions :-) For the third case the bug was in the X.Org i830 driver: 
http://bugs.freedesktop.org/show_bug.cgi?id=14481.

Re: [Bug #13667] drm: display arifacts when X.Org is stopped

[Dave Airlie]

On Wed, Jul 8, 2009 at 3:00 PM, Frans Pop<elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org> wrote:
> On Wednesday 08 July 2009, Dave Airlie wrote:
>> On Wed, Jul 8, 2009 at 10:32 AM, Frans Pop<elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org> wrote:
>> > On Tuesday 07 July 2009, Rafael J. Wysocki wrote:
>> >> The following bug entry is on the current list of known regressions
>> >> from 2.6.30.  Please verify if it still should be listed and let me
>> >> know (either way).
>> >>
>> >> Bug-Entry     : http://bugzilla.kernel.org/show_bug.cgi?id=13667
>> >> Subject       : drm: display arifacts when X.Org is stopped
>> >> Submitter     : Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
>> >> Date          : 2009-06-27 18:52 (10 days old)
>> >> References    : http://lkml.org/lkml/2009/6/27/105
>> >
>> > Problem is still there with -rc2. Dave said he'd try to reproduce,
>> > but I've not heard back from him yet.
>>
>> Don't suppose you have a 32-bit install you could also test with?
>
> You're in luck...
> I also get artifacts, though less severe, with .31-rc2 on my Toshiba
> Satellite A40 (32-bit kernel) during logout from X.Org. The switch is
> clean with .30.
>
>> Hopefully I can reproduce it on my box locally, otherwise its really
>> messy dealing with 2 drivers smashing on the same hw.
>
> Not sure why you're saying that. I would think VESA fb + X.Org is quite
> common and also a very valid use case [1]. How else would you get the
> pretty kernel boot logo? ;-)
>
>> btw you get any wierd text mode issues without vesafb?
>
> If I boot .31-rc2 without vga=791 I don't get the artifacts. The artifacts
> also do not appear if I boot with 'nopat'. Checked on both systems.
>
> Note that I reported a similar issue once before, also reproducible on
> both systems. In that case it was a bug in PAT which was eventually fixed.
> See: http://bugzilla.kernel.org/show_bug.cgi?id=10843.
>
> Given that 'nopat' helps, you may want to check with Suresh on this one.
>

I've cc'ed Venki and Suresh, guys since I switched AGP to using the page
arrays instead and the new array setting functions, Frans has been seeing
vesafb corruption when using non-KMS intel driver after X has finished running.
nopat makes it go away.

> [1] I'd even go so far as to feel it should be a standard test case for
> video driver developers, given that this is the third time it's shown
> regressions :-) For the third case the bug was in the X.Org i830 driver:
> http://bugs.freedesktop.org/show_bug.cgi?id=14481.

It might surprise you to learn this, but vesafb has never been considered
supportable by the X.org community, and you'll notice not very many distros
ship with it enabled, it breaks suspend/resume on many machines for example.

As I said having two drivers thinking they own the GPU is a recipe for total
disaster and thats why we've designed the new KMS code so you can get
cool bootup logos and avoid the insanity dance.

However we shall endeavour to fix this issues as it may be systemic of something
else going wrong in the new PAT/AGP code.

Dave.

Re: [Bug #13667] drm: display arifacts when X.Org is stopped

[Frans Pop]

On Thursday 09 July 2009, Dave Airlie wrote:
> > [1] I'd even go so far as to feel it should be a standard test case
> > for video driver developers, given that this is the third time it's
> > shown regressions :-) For the third case the bug was in the X.Org
> > i830 driver: http://bugs.freedesktop.org/show_bug.cgi?id=14481.
>
> It might surprise you to learn this, but vesafb has never been
> considered supportable by the X.org community, and you'll notice not
> very many distros ship with it enabled, it breaks suspend/resume on
> many machines for example.

I beg to disagree.
- Debian does have it enabled by default.
- I have always used it on all my machines without any problems.
- Both my laptops and my desktop suspend and resume perfectly with vesafb
  and X.Org.
- Jesse Barnes seems to disagree with you. To quote from the BR cited
  above (comment #11): "and you're right, making things work with vesafb
  isn't unreasonable".

I do know intelfb is considered to be terminally broken, but have always 
understood the use of vesafb to be accepted.

> As I said having two drivers thinking they own the GPU is a recipe for
> total disaster and thats why we've designed the new KMS code so you can
> get cool bootup logos and avoid the insanity dance.

Yes, and I really welcome the great progress being made there. But for me 
it's not yet an option as I run Debian stable on these boxes.

> However we shall endeavour to fix this issues as it may be systemic of
> something else going wrong in the new PAT/AGP code.

Great. Thanks in advance, I do appreciate it.

BTW, today I noticed another regression, but I have not yet looked into it 
deeply. When I suspend I normally see at least some console messages from 
the suspend procedure on the framebuffer console, but with .31-rc2 I only 
see a cursor. It does not really affect the suspend/resume.
Could possibly be related. Will investigate further.

Cheers,
FJP

Re: [Bug #13667] drm: display arifacts when X.Org is stopped

[Jesse Barnes]

On Thu, 9 Jul 2009 03:28:52 +0200
Frans Pop <elendil@planet.nl> wrote:

> On Thursday 09 July 2009, Dave Airlie wrote:
> > > [1] I'd even go so far as to feel it should be a standard test
> > > case for video driver developers, given that this is the third
> > > time it's shown regressions :-) For the third case the bug was in
> > > the X.Org i830 driver:
> > > http://bugs.freedesktop.org/show_bug.cgi?id=14481.
> >
> > It might surprise you to learn this, but vesafb has never been
> > considered supportable by the X.org community, and you'll notice not
> > very many distros ship with it enabled, it breaks suspend/resume on
> > many machines for example.
> 
> I beg to disagree.
> - Debian does have it enabled by default.
> - I have always used it on all my machines without any problems.
> - Both my laptops and my desktop suspend and resume perfectly with
> vesafb and X.Org.
> - Jesse Barnes seems to disagree with you. To quote from the BR cited
>   above (comment #11): "and you're right, making things work with
> vesafb isn't unreasonable".

Since my ears are burning I figured I'd better qualify this: I made
that statement before we had KMS upstream.  Supporting the case where
multiple drivers try to bang on the same device has always been a big
pain.  In a KMS configuration we don't support it at all.

> Yes, and I really welcome the great progress being made there. But
> for me it's not yet an option as I run Debian stable on these boxes.

Sounds like that's not an option for you though... which means
debugging where the interaction is going wrong...

Jesse

Re: [Bug #13667] drm: display arifacts when X.Org is stopped

[Frans Pop]

On Thursday 09 July 2009, Frans Pop wrote:
> > However we shall endeavour to fix this issues as it may be systemic
> > of something else going wrong in the new PAT/AGP code.
>
> Great. Thanks in advance, I do appreciate it.

Any news on this?

> BTW, today I noticed another regression, but I have not yet looked into
> it deeply. When I suspend I normally see at least some console messages
> from the suspend procedure on the framebuffer console, but with .31-rc2
> I only see a cursor. It does not really affect the suspend/resume.
> Could possibly be related. Will investigate further.

This turned out to be unrelated, and is actually an improvement. It's a 
logical result of a printk patch I submitted (for .32):
http://lkml.org/lkml/2009/7http://lkml.org/lkml/2009/7/6/108/6/108

Cheers,
FJP

Re: [Bug #13667] drm: display arifacts when X.Org is stopped

[Dave Airlie]

On Sun, Jul 26, 2009 at 2:33 AM, Frans Pop<elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org> wrote:
> On Thursday 09 July 2009, Frans Pop wrote:
>> > However we shall endeavour to fix this issues as it may be systemic
>> > of something else going wrong in the new PAT/AGP code.
>>
>> Great. Thanks in advance, I do appreciate it.
>
> Any news on this?\

http://git.infradead.org/users/dwmw2/iommu-agp.git

don't suppose you could pull that tree in and see if it helps?

Dave.

>
>> BTW, today I noticed another regression, but I have not yet looked into
>> it deeply. When I suspend I normally see at least some console messages
>> from the suspend procedure on the framebuffer console, but with .31-rc2
>> I only see a cursor. It does not really affect the suspend/resume.
>> Could possibly be related. Will investigate further.
>
> This turned out to be unrelated, and is actually an improvement. It's a
> logical result of a printk patch I submitted (for .32):
> http://lkml.org/lkml/2009/7http://lkml.org/lkml/2009/7/6/108/6/108
>
> Cheers,
> FJP
>

Re: [Bug #13667] drm: display arifacts when X.Org is stopped

[Frans Pop]

On Thursday 30 July 2009, Dave Airlie wrote:
> On Sun, Jul 26, 2009 at 2:33 AM, Frans Pop<elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org> wrote:
> > On Thursday 09 July 2009, Frans Pop wrote:
> >> > However we shall endeavour to fix this issues as it may be
> >> > systemic of something else going wrong in the new PAT/AGP code.
> >>
> >> Great. Thanks in advance, I do appreciate it.
> >
> > Any news on this?
>
> http://git.infradead.org/users/dwmw2/iommu-agp.git
>
> don't suppose you could pull that tree in and see if it helps?

Sure I can :-)
I merged its master branch on top of current mainline + some local patches 
I have. But I'm afraid it does not make any difference.

Note that I also added Venki's PAT patch set for .32 [1] in my local 
patches because of this issue, but that does not make any difference 
either.

Cheers,
FJP

[1] http://lkml.org/lkml/2009/7/10/284

RE: [Bug #13667] drm: display arifacts when X.Org is stopped

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: Frans Pop [mailto:elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org] 
>Sent: Thursday, July 30, 2009 4:41 AM
>To: Dave Airlie
>Cc: Rafael J. Wysocki; Linux Kernel Mailing List; Kernel 
>Testers List; Siddha, Suresh B; Pallipadi, Venkatesh
>Subject: Re: [Bug #13667] drm: display arifacts when X.Org is stopped
>
>On Thursday 30 July 2009, Dave Airlie wrote:
>> On Sun, Jul 26, 2009 at 2:33 AM, Frans Pop<elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org> wrote:
>> > On Thursday 09 July 2009, Frans Pop wrote:
>> >> > However we shall endeavour to fix this issues as it may be
>> >> > systemic of something else going wrong in the new PAT/AGP code.
>> >>
>> >> Great. Thanks in advance, I do appreciate it.
>> >
>> > Any news on this?
>>
>> http://git.infradead.org/users/dwmw2/iommu-agp.git
>>
>> don't suppose you could pull that tree in and see if it helps?
>
>Sure I can :-)
>I merged its master branch on top of current mainline + some 
>local patches 
>I have. But I'm afraid it does not make any difference.
>
>Note that I also added Venki's PAT patch set for .32 [1] in my local 
>patches because of this issue, but that does not make any difference 
>either.
>

Can you please check whether the patch here helps?
http://bugzilla.kernel.org/show_bug.cgi?id=13884

Thanks,
Venki--
To unsubscribe from this list: send the line "unsubscribe kernel-testers" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bug #13667] drm: display arifacts when X.Org is stopped

[Frans Pop]

On Saturday 01 August 2009, Pallipadi, Venkatesh wrote:
> >-----Original Message-----
> >From: Frans Pop [mailto:elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org]
> >Sent: Thursday, July 30, 2009 4:41 AM
> >To: Dave Airlie
> >Cc: Rafael J. Wysocki; Linux Kernel Mailing List; Kernel
> >Testers List; Siddha, Suresh B; Pallipadi, Venkatesh
> >Subject: Re: [Bug #13667] drm: display arifacts when X.Org is stopped
> >
> Can you please check whether the patch here helps?
> http://bugzilla.kernel.org/show_bug.cgi?id=13884

Yes! That fixes it.

Thanks,
FJP

[Bug #13666] WARNING: at mm/page_alloc.c:1743 __alloc_pages_nodemask

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13666
Subject		: WARNING: at mm/page_alloc.c:1743 __alloc_pages_nodemask
Submitter	: Thomas Meyer <thomas-VsYtu1Qij5c@public.gmane.org>
Date		: 2009-06-27 16:15 (10 days old)
References	: http://lkml.org/lkml/2009/6/27/75

Re: [Bug #13666] WARNING: at mm/page_alloc.c:1743 __alloc_pages_nodemask

[David Rientjes]

On Tue, 7 Jul 2009, Rafael J. Wysocki wrote:

> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.30.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13666
> Subject		: WARNING: at mm/page_alloc.c:1743 __alloc_pages_nodemask
> Submitter	: Thomas Meyer <thomas-VsYtu1Qij5c@public.gmane.org>
> Date		: 2009-06-27 16:15 (10 days old)
> References	: http://lkml.org/lkml/2009/6/27/75
> 

This should be suppressed with the patchset proposed by Mel on linux-mm:

	http://marc.info/?l=linux-mm&m=124568542405734
	http://marc.info/?l=linux-mm&m=124568542605738
	http://marc.info/?l=linux-mm&m=124568542905750
	http://marc.info/?l=linux-mm&m=124568543305755

It doesn't appear that these are in linux-next, however.

Re: [Bug #13666] WARNING: at mm/page_alloc.c:1743 __alloc_pages_nodemask

[Mel Gorman]

On Mon, Jul 06, 2009 at 09:23:03PM -0700, David Rientjes wrote:
> On Tue, 7 Jul 2009, Rafael J. Wysocki wrote:
> 
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.30.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13666
> > Subject		: WARNING: at mm/page_alloc.c:1743 __alloc_pages_nodemask
> > Submitter	: Thomas Meyer <thomas-VsYtu1Qij5c@public.gmane.org>
> > Date		: 2009-06-27 16:15 (10 days old)
> > References	: http://lkml.org/lkml/2009/6/27/75
> > 
> 
> This should be suppressed with the patchset proposed by Mel on linux-mm:
> 
> 	http://marc.info/?l=linux-mm&m=124568542405734
> 	http://marc.info/?l=linux-mm&m=124568542605738
> 	http://marc.info/?l=linux-mm&m=124568542905750
> 	http://marc.info/?l=linux-mm&m=124568543305755
> 
> It doesn't appear that these are in linux-next, however.
> 

In the middle of all the discussions, a few candidate patches haven't
made it upstream. I'm waiting for an mmotm against 2.6.31-rc2 before
going back to see what has been missed that needs resending.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

[Bug #13665] commit 69c854817566 causes OOMs

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13665
Subject		: commit 69c854817566 causes OOMs
Submitter	: David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date		: 2009-06-27 08:12 (10 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69c854817566db82c362797b4a6521d0b00fe1d8
References	: http://lkml.org/lkml/2009/6/27/28
Handled-By	: Wu Fengguang <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/32740/

Re: [Bug #13665] commit 69c854817566 causes OOMs

[Minchan Kim]

On Tue,  7 Jul 2009 02:01:03 +0200 (CEST)
"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:

> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.30.  Please verify if it still should be listed and let me know
> (either way).
> 

It should be listed.

I think it is caused by forking process bomb by msgctl11 on LTP. 
We can refer old discussion(http://osdir.com/ml/linux-kernel/2009-07/msg00926.html)

I think this issue can be solved by 
dynamic reclaim throttling patch which is making by Rik.

After he merges it, Let's test again. 

> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13665
> Subject		: commit 69c854817566 causes OOMs
> Submitter	: David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Date		: 2009-06-27 08:12 (10 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=69c854817566db82c362797b4a6521d0b00fe1d8
> References	: http://lkml.org/lkml/2009/6/27/28
> Handled-By	: Wu Fengguang <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Patch		: http://patchwork.kernel.org/patch/32740/
> 
> 


-- 
Kind regards,
Minchan Kim

Re: [Bug #13665] commit 69c854817566 causes OOMs

[Gene Heskett]

On Tuesday 07 July 2009, Minchan Kim wrote:
>On Tue,  7 Jul 2009 02:01:03 +0200 (CEST)
>
>"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>> This message has been generated automatically as a part of a report
>> of recent regressions.
>>
>> The following bug entry is on the current list of known regressions
>> from 2.6.30.  Please verify if it still should be listed and let me know
>> (either way).
>
>It should be listed.
>
>I think it is caused by forking process bomb by msgctl11 on LTP.
>We can refer old
> discussion(http://osdir.com/ml/linux-kernel/2009-07/msg00926.html)
>
>I think this issue can be solved by
>dynamic reclaim throttling patch which is making by Rik.
>
>After he merges it, Let's test again.
>
>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13665
>> Subject		: commit 69c854817566 causes OOMs
>> Submitter	: David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> Date		: 2009-06-27 08:12 (10 days old)
>> First-Bad-Commit:
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;
>>h=69c854817566db82c362797b4a6521d0b00fe1d8 References	:
>> http://lkml.org/lkml/2009/6/27/28
>> Handled-By	: Wu Fengguang <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Patch		: http://patchwork.kernel.org/patch/32740/

If I can chime in here, I just had to reboot from 2.6.31-rc2 for the 2nd time 
in about 24 hours cuz the oom killer killed it.  Back on 2.6.30.1 ATM for 
effects.

I have a previous post with traces etc.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The NRA is offering FREE Associate memberships to anyone who wants them.
<https://www.nrahq.org/nrabonus/accept-membership.asp>

The truth is rarely pure, and never simple.
		-- Oscar Wilde

[Bug #13661] warning in smp_call_function_single while S2R

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13661
Subject		: warning in smp_call_function_single while S2R
Submitter	: Thomas Meyer <thomas-VsYtu1Qij5c@public.gmane.org>
Date		: 2009-06-27 17:12 (10 days old)
References	: http://lkml.org/lkml/2009/6/27/80

[Bug #13700] usb error flood in dmesg, makes kde use plenty of cpu - bisected

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13700
Subject		: usb error flood in dmesg, makes kde use plenty of cpu - bisected
Submitter	: jouni susiluoto <jouni.susiluoto-pxSi+dnQzZMxHbG02/KK1g@public.gmane.org>
Date		: 2009-07-03 21:13 (4 days old)

[Bug #13673] HIGHMEM64G causes hang in PCI init on 32-bit x86

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13673
Subject		: HIGHMEM64G causes hang in PCI init on 32-bit x86
Submitter	: Mikael Pettersson <mikpe-1zs4UD6AkMk@public.gmane.org>
Date		: 2009-06-26 15:59 (11 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=95ee14e4379c5e19c0897c872350570402014742
References	: http://marc.info/?l=linux-pci&m=124615181602643&w=4
Handled-By	: H. Peter Anvin <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>

Re: [Bug #13673] HIGHMEM64G causes hang in PCI init on 32-bit x86

[Mikael Pettersson]

Rafael J. Wysocki wrote:
> The following bug entry is on the current list of known regressions
> from 2.6.30.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=3D13673
> Subject		: HIGHMEM64G causes hang in PCI init on 32-bit x86
> Submitter	: Mikael Pettersson <mikpe-1zs4UD6AkMk@public.gmane.org>
> Date		: 2009-06-26 15:59 (11 days old)
> First-Bad-Commit: http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linu=
> x-2.6.git;a=3Dcommit;h=3D95ee14e4379c5e19c0897c872350570402014742
> References	: http://marc.info/?l=3Dlinux-pci&m=3D124615181602643&w=3D4
> Handled-By	: H. Peter Anvin <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>

Fixed in 2.6.31-rc2.

Re: [Bug #13673] HIGHMEM64G causes hang in PCI init on 32-bit x86

[Rafael J. Wysocki]

On Tuesday 07 July 2009, Mikael Pettersson wrote:
> Rafael J. Wysocki wrote:
> > The following bug entry is on the current list of known regressions
> > from 2.6.30.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=3D13673
> > Subject		: HIGHMEM64G causes hang in PCI init on 32-bit x86
> > Submitter	: Mikael Pettersson <mikpe-1zs4UD6AkMk@public.gmane.org>
> > Date		: 2009-06-26 15:59 (11 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linu=
> > x-2.6.git;a=3Dcommit;h=3D95ee14e4379c5e19c0897c872350570402014742
> > References	: http://marc.info/?l=3Dlinux-pci&m=3D124615181602643&w=3D4
> > Handled-By	: H. Peter Anvin <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
> 
> Fixed in 2.6.31-rc2.

Thanks, closed.

Best,
Rafael

[Bug #13690] nodes_clear cause hugepage unusable on non-NUMA machine

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13690
Subject		: nodes_clear cause hugepage unusable on non-NUMA machine
Submitter	: alexs <alex.shi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date		: 2009-07-02 01:22 (5 days old)

Re: [Bug #13690] nodes_clear cause hugepage unusable on non-NUMA machine

[Yinghai Lu]

Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.30.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13690
> Subject		: nodes_clear cause hugepage unusable on non-NUMA machine
> Submitter	: alexs <alex.shi@intel.com>
> Date		: 2009-07-02 01:22 (5 days old)
> 


http://lkml.org/lkml/2009/7/2/326

YH

Re: [Bug #13690] nodes_clear cause hugepage unusable on non-NUMA machine

[Rafael J. Wysocki]

On Tuesday 07 July 2009, Yinghai Lu wrote:
> Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.30.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13690
> > Subject		: nodes_clear cause hugepage unusable on non-NUMA machine
> > Submitter	: alexs <alex.shi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > Date		: 2009-07-02 01:22 (5 days old)
> > 
> 
> 
> http://lkml.org/lkml/2009/7/2/326

Thanks, updated.

Best,
Rafael

[Bug #13728] 2.6.31-rc2 soft lockups, RPC-related

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13728
Subject		: 2.6.31-rc2 soft lockups, RPC-related
Submitter	: Paul Collins <paul-dsjeNyW6Qm/D+ROgJ3VA+kB+6BGkLq7r@public.gmane.org>
Date		: 2009-07-05 7:17 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=124677884816794&w=4

Re: [Bug #13728] 2.6.31-rc2 soft lockups, RPC-related

[Paul Collins]

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

"Rafael J. Wysocki" <rjw@sisk.pl> writes:

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13728
> Subject		: 2.6.31-rc2 soft lockups, RPC-related
> Submitter	: Paul Collins <paul@burly.ondioline.org>
> Date		: 2009-07-05 7:17 (2 days old)
> References	: http://marc.info/?l=linux-kernel&m=124677884816794&w=4

Still present as of 2.6.31-rc2-00257-gc2cc49a.

I tried reverting 3f09df70e3a33590ae5a97b8a15486d3711c7065 ("NFS: Ensure
we always hold the BKL when dereferencing inode->i_flock") to no avail,
so I guess it's bisection time.

Attached in case it is useful is dmesg from boot wherein the following
occurs: 1) I trigger the problem by opening a file on NFS with emacs 2)
I trigger sysrq-T 3) the softlockup warnings fire 4) I trigger sysrq-T
again.

After this all occurred I was still able to perform operations on the
NFS mount, including playing a movie stored there.


[-- Attachment #2: lockups-and-traces.gz --]
[-- Type: application/octet-stream, Size: 42512 bytes --]

[-- Attachment #3: Type: text/plain, Size: 93 bytes --]


-- 
Paul Collins
Wellington, New Zealand

Dag vijandelijk luchtschip de huismeester is dood

[Bug #13726] fio sync read 4k block size 35% regression

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13726
Subject		: fio sync read 4k block size 35% regression
Submitter	: Zhang, Yanmin <yanmin_zhang-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Date		: 2009-07-01 11:25 (6 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=51daa88ebd8e0d437289f589af29d4b39379ea76
References	: http://lkml.org/lkml/2009/6/30/679
Handled-By	: Wu Fengguang <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

Re: [Bug #13726] fio sync read 4k block size 35% regression

[Zhang, Yanmin]

On Tue, 2009-07-07 at 02:01 +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.30.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13726
> Subject		: fio sync read 4k block size 35% regression
> Submitter	: Zhang, Yanmin <yanmin_zhang-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> Date		: 2009-07-01 11:25 (6 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=51daa88ebd8e0d437289f589af29d4b39379ea76
> References	: http://lkml.org/lkml/2009/6/30/679
> Handled-By	: Wu Fengguang <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Fengguang,

I'm still working on it now. The new testing against 2.6.31-rc2 is ongoing.
fio sync/mmap read has new behavior. I did collect some data. But suddenly
with new created data, the fio_sync_read_4k regression disappeared, while
fio_mmap_read is still there. Originally, the testing and bisect were stable.
Let me check what happens firstly.

Just update.

How did you test your new readahead patches before sending to LKML?

Yanmin

Re: [Bug #13726] fio sync read 4k block size 35% regression

[Wu Fengguang]

On Tue, Jul 07, 2009 at 02:06:42PM +0800, Zhang, Yanmin wrote:
> On Tue, 2009-07-07 at 02:01 +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.30.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13726
> > Subject		: fio sync read 4k block size 35% regression
> > Submitter	: Zhang, Yanmin <yanmin_zhang-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> > Date		: 2009-07-01 11:25 (6 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=51daa88ebd8e0d437289f589af29d4b39379ea76
> > References	: http://lkml.org/lkml/2009/6/30/679
> > Handled-By	: Wu Fengguang <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Fengguang,
> 
> I'm still working on it now. The new testing against 2.6.31-rc2 is ongoing.
> fio sync/mmap read has new behavior. I did collect some data. But suddenly
> with new created data, the fio_sync_read_4k regression disappeared, while
> fio_mmap_read is still there. Originally, the testing and bisect were stable.
> Let me check what happens firstly.

OK, thank you for the update.

> Just update.
> 
> How did you test your new readahead patches before sending to LKML?

I run various workloads and check if the readahead traces are abnormal.
In this regression case, the readahead traces are in fact normal :)

Thanks,
Fengguang

Re: [Bug #13726] fio sync read 4k block size 35% regression

[Wu Fengguang]

On Tue, Jul 07, 2009 at 02:06:42PM +0800, Zhang, Yanmin wrote:
> On Tue, 2009-07-07 at 02:01 +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.30.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13726
> > Subject		: fio sync read 4k block size 35% regression
> > Submitter	: Zhang, Yanmin <yanmin_zhang-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> > Date		: 2009-07-01 11:25 (6 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=51daa88ebd8e0d437289f589af29d4b39379ea76
> > References	: http://lkml.org/lkml/2009/6/30/679
> > Handled-By	: Wu Fengguang <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Fengguang,
> 
> I'm still working on it now. The new testing against 2.6.31-rc2 is ongoing.
> fio sync/mmap read has new behavior. I did collect some data. But suddenly
> with new created data, the fio_sync_read_4k regression disappeared, while

Do you mean the fio_sync_read_4k regression disappeared because we are
collecting data with lots of printks?

> fio_mmap_read is still there. Originally, the testing and bisect were stable.
> Let me check what happens firstly.

Thanks! What's your fio_mmap_read job file and the readahead traces?

Thanks,
Fengguang

Re: [Bug #13726] fio sync read 4k block size 35% regression

[Zhang, Yanmin]

On Fri, 2009-07-10 at 14:37 +0800, Wu Fengguang wrote:
> On Tue, Jul 07, 2009 at 02:06:42PM +0800, Zhang, Yanmin wrote:
> > On Tue, 2009-07-07 at 02:01 +0200, Rafael J. Wysocki wrote:
> > > This message has been generated automatically as a part of a report
> > > of recent regressions.
> > > 
> > > The following bug entry is on the current list of known regressions
> > > from 2.6.30.  Please verify if it still should be listed and let me know
> > > (either way).
> > > 
> > > 
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13726
> > > Subject		: fio sync read 4k block size 35% regression
> > > Submitter	: Zhang, Yanmin <yanmin_zhang-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> > > Date		: 2009-07-01 11:25 (6 days old)
> > > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=51daa88ebd8e0d437289f589af29d4b39379ea76
> > > References	: http://lkml.org/lkml/2009/6/30/679
> > > Handled-By	: Wu Fengguang <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > Fengguang,
> > 
> > I'm still working on it now. The new testing against 2.6.31-rc2 is ongoing.
> > fio sync/mmap read has new behavior. I did collect some data. But suddenly
> > with new created data, the fio_sync_read_4k regression disappeared, while
> 
> Do you mean the fio_sync_read_4k regression disappeared because we are
> collecting data with lots of printks?
No. I recreated the data and the regression disappeared.

> 
> > fio_mmap_read is still there. Originally, the testing and bisect were stable.
> > Let me check what happens firstly.
> 
> Thanks! What's your fio_mmap_read job file and the readahead traces?
I dumped trace data of fio and found the sync read isn't really sequential. I
create many processes and every process could read a group of files. The trace
shows fio reads a record of a file, then switch to another file to read. My
original assumption is a process reads the complete file sequentially and then
read the 2nd file. Now I upgrade fio the latest version and add parameter
file_service_type=random:4000000 to rerun all testing.

Re: [Bug #13726] fio sync read 4k block size 35% regression

[Wu Fengguang]

On Fri, Jul 10, 2009 at 03:41:54PM +0800, Zhang, Yanmin wrote:
> On Fri, 2009-07-10 at 14:37 +0800, Wu Fengguang wrote:
> > On Tue, Jul 07, 2009 at 02:06:42PM +0800, Zhang, Yanmin wrote:
> > > On Tue, 2009-07-07 at 02:01 +0200, Rafael J. Wysocki wrote:
> > > > This message has been generated automatically as a part of a report
> > > > of recent regressions.
> > > > 
> > > > The following bug entry is on the current list of known regressions
> > > > from 2.6.30.  Please verify if it still should be listed and let me know
> > > > (either way).
> > > > 
> > > > 
> > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13726
> > > > Subject		: fio sync read 4k block size 35% regression
> > > > Submitter	: Zhang, Yanmin <yanmin_zhang-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> > > > Date		: 2009-07-01 11:25 (6 days old)
> > > > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=51daa88ebd8e0d437289f589af29d4b39379ea76
> > > > References	: http://lkml.org/lkml/2009/6/30/679
> > > > Handled-By	: Wu Fengguang <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > > Fengguang,
> > > 
> > > I'm still working on it now. The new testing against 2.6.31-rc2 is ongoing.
> > > fio sync/mmap read has new behavior. I did collect some data. But suddenly
> > > with new created data, the fio_sync_read_4k regression disappeared, while
> > 
> > Do you mean the fio_sync_read_4k regression disappeared because we are
> > collecting data with lots of printks?
> No. I recreated the data and the regression disappeared.

OK. It's because you recreated the files, instead of upgrading to -rc2?

> > 
> > > fio_mmap_read is still there. Originally, the testing and bisect were stable.
> > > Let me check what happens firstly.
> > 
> > Thanks! What's your fio_mmap_read job file and the readahead traces?
> I dumped trace data of fio and found the sync read isn't really sequential. I
> create many processes and every process could read a group of files. The trace
> shows fio reads a record of a file, then switch to another file to read. My
> original assumption is a process reads the complete file sequentially and then
> read the 2nd file. Now I upgrade fio the latest version and add parameter
> file_service_type=random:4000000 to rerun all testing.

However you organize the workload, it is a regression. If you mean
"this workload is expected to create regressions", then let's improve
the algorithm to cover that workload?

In your previous workload, what's the exact read pattern for any
single file over time?

Thanks,
Fengguang

Re: [Bug #13726] fio sync read 4k block size 35% regression

[Zhang, Yanmin]

On Fri, 2009-07-10 at 16:17 +0800, Wu Fengguang wrote:
> On Fri, Jul 10, 2009 at 03:41:54PM +0800, Zhang, Yanmin wrote:
> > On Fri, 2009-07-10 at 14:37 +0800, Wu Fengguang wrote:
> > > On Tue, Jul 07, 2009 at 02:06:42PM +0800, Zhang, Yanmin wrote:
> > > > On Tue, 2009-07-07 at 02:01 +0200, Rafael J. Wysocki wrote:
> > > > > This message has been generated automatically as a part of a report
> > > > > of recent regressions.
> > > > > 
> > > > > The following bug entry is on the current list of known regressions
> > > > > from 2.6.30.  Please verify if it still should be listed and let me know
> > > > > (either way).
> > > > > 
> > > > > 
> > > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13726
> > > > > Subject		: fio sync read 4k block size 35% regression
> > > > > Submitter	: Zhang, Yanmin <yanmin_zhang-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> > > > > Date		: 2009-07-01 11:25 (6 days old)
> > > > > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=51daa88ebd8e0d437289f589af29d4b39379ea76
> > > > > References	: http://lkml.org/lkml/2009/6/30/679
> > > > > Handled-By	: Wu Fengguang <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > > > Fengguang,
> > > > 
> > > > I'm still working on it now. The new testing against 2.6.31-rc2 is ongoing.
> > > > fio sync/mmap read has new behavior. I did collect some data. But suddenly
> > > > with new created data, the fio_sync_read_4k regression disappeared, while
> > > 
> > > Do you mean the fio_sync_read_4k regression disappeared because we are
> > > collecting data with lots of printks?
> > No. I recreated the data and the regression disappeared.
> 
> OK. It's because you recreated the files, instead of upgrading to -rc2?
Yes.

> 
> > > 
> > > > fio_mmap_read is still there. Originally, the testing and bisect were stable.
> > > > Let me check what happens firstly.
> > > 
> > > Thanks! What's your fio_mmap_read job file and the readahead traces?
> > I dumped trace data of fio and found the sync read isn't really sequential. I
> > create many processes and every process could read a group of files. The trace
> > shows fio reads a record of a file, then switch to another file to read. My
> > original assumption is a process reads the complete file sequentially and then
> > read the 2nd file. Now I upgrade fio the latest version and add parameter
> > file_service_type=random:4000000 to rerun all testing.
> 
> However you organize the workload, it is a regression. If you mean
> "this workload is expected to create regressions", then let's improve
> the algorithm to cover that workload?
Thanks Fengguang. You work carefully and be ready to resolve any regression.

When creating the workloads, I try to simulate _RealUsageModels_. For example,
fio_mmap_sync_read and fio_sync_read are to simulate ftp/web server and media
player to download big files. Such workloads mostly read files sequentially, not
interspersally among many files. I also have other workloads, such like
fio_mmap_rand_read/write simulating small/medium databases, which need IO
interspersally among a coulpe of files.

As for this report, my original testing reads files interspersally. It's hard to
find the usage models. In other hand, sometimes a method to improve one workload
might hurt other workloads. So let's focus on good workloads.

With the latest version of fio and new parameters, I found some other regressions.
I will check them and report if necessary.

> 
> In your previous workload, what's the exact read pattern for any
> single file over time?
Sequential read, but read a block (4k64k/128k), then switch to next file to read
another block. As for single file, read sequentially.
If there are 3 files:
1) read 1st block of f1; then read 1st block of f2; then f3;
2) read 2nd block of f1; then read 2nd block of f2; then f3;
3) ...

Such read scenario isn't good. I created it incorrectly because I misunderstood
some parameters of fio.

Pls. close the report.

yanmin

Re: [Bug #13726] fio sync read 4k block size 35% regression

[Wu Fengguang]

On Mon, Jul 13, 2009 at 10:51:30AM +0800, Zhang, Yanmin wrote:
> On Fri, 2009-07-10 at 16:17 +0800, Wu Fengguang wrote:
> > On Fri, Jul 10, 2009 at 03:41:54PM +0800, Zhang, Yanmin wrote:
> > > On Fri, 2009-07-10 at 14:37 +0800, Wu Fengguang wrote:
> > > > On Tue, Jul 07, 2009 at 02:06:42PM +0800, Zhang, Yanmin wrote:
> > > > > On Tue, 2009-07-07 at 02:01 +0200, Rafael J. Wysocki wrote:
> > > > > > This message has been generated automatically as a part of a report
> > > > > > of recent regressions.
> > > > > > 
> > > > > > The following bug entry is on the current list of known regressions
> > > > > > from 2.6.30.  Please verify if it still should be listed and let me know
> > > > > > (either way).
> > > > > > 
> > > > > > 
> > > > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13726
> > > > > > Subject		: fio sync read 4k block size 35% regression
> > > > > > Submitter	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
> > > > > > Date		: 2009-07-01 11:25 (6 days old)
> > > > > > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=51daa88ebd8e0d437289f589af29d4b39379ea76
> > > > > > References	: http://lkml.org/lkml/2009/6/30/679
> > > > > > Handled-By	: Wu Fengguang <fengguang.wu@intel.com>
> > > > > Fengguang,
> > > > > 
> > > > > I'm still working on it now. The new testing against 2.6.31-rc2 is ongoing.
> > > > > fio sync/mmap read has new behavior. I did collect some data. But suddenly
> > > > > with new created data, the fio_sync_read_4k regression disappeared, while
> > > > 
> > > > Do you mean the fio_sync_read_4k regression disappeared because we are
> > > > collecting data with lots of printks?
> > > No. I recreated the data and the regression disappeared.
> > 
> > OK. It's because you recreated the files, instead of upgrading to -rc2?
> Yes.
> 
> > 
> > > > 
> > > > > fio_mmap_read is still there. Originally, the testing and bisect were stable.
> > > > > Let me check what happens firstly.
> > > > 
> > > > Thanks! What's your fio_mmap_read job file and the readahead traces?
> > > I dumped trace data of fio and found the sync read isn't really sequential. I
> > > create many processes and every process could read a group of files. The trace
> > > shows fio reads a record of a file, then switch to another file to read. My
> > > original assumption is a process reads the complete file sequentially and then
> > > read the 2nd file. Now I upgrade fio the latest version and add parameter
> > > file_service_type=random:4000000 to rerun all testing.
> > 
> > However you organize the workload, it is a regression. If you mean
> > "this workload is expected to create regressions", then let's improve
> > the algorithm to cover that workload?
> Thanks Fengguang. You work carefully and be ready to resolve any regression.
> 
> When creating the workloads, I try to simulate _RealUsageModels_. For example,
> fio_mmap_sync_read and fio_sync_read are to simulate ftp/web server and media
> player to download big files. Such workloads mostly read files sequentially, not
> interspersally among many files. I also have other workloads, such like

Yes, file servers mostly read files sequentially.  But they do not
necessarily spawn one thread/process for each client (eg. lighttpd).
So you are testing some real workloads :)

> fio_mmap_rand_read/write simulating small/medium databases, which need IO
> interspersally among a coulpe of files.

Hmm, it seems that both regressions have something to do with
"one process accessing several files".

> As for this report, my original testing reads files interspersally. It's hard to
> find the usage models. In other hand, sometimes a method to improve one workload
> might hurt other workloads. So let's focus on good workloads.
> 
> With the latest version of fio and new parameters, I found some other regressions.
> I will check them and report if necessary.
> 
> > 
> > In your previous workload, what's the exact read pattern for any
> > single file over time?
> Sequential read, but read a block (4k64k/128k), then switch to next file to read
> another block. As for single file, read sequentially.
> If there are 3 files:
> 1) read 1st block of f1; then read 1st block of f2; then f3;
> 2) read 2nd block of f1; then read 2nd block of f2; then f3;
> 3) ...

In this case,
- one process process may issue IO for several files
  aka. random seeking
- several processes may issue IO for the same file
  aka. cooperative processes
The above IO patterns may well confuse the underlying CFQ io scheduler.

Would you please try rerun the test with

for param in /sys/block/sd?/queue/iosched/slice_idle
do
        echo 0 > $param
done

> Such read scenario isn't good. I created it incorrectly because I misunderstood
> some parameters of fio.
> 
> Pls. close the report.

No, you created a very good test scheme!  Let's fix this regression :)

Thanks,
Fengguang

[Bug #13716] The AIC-7892P controller does not work any more

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13716
Subject		: The AIC-7892P controller does not work any more
Submitter	: Andrej Podzimek <andrej-+Hii8LNHG6Ng9hUCZPvPmw@public.gmane.org>
Date		: 2009-07-05 19:23 (2 days old)

[Bug #13727] Cannot Recognize Empty DVD Media

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13727
Subject		: Cannot Recognize Empty DVD Media
Submitter	: Tarkan Erimer <tarkan.erimer-AMZSHK9Z0TXlajqSnzHT9w@public.gmane.org>
Date		: 2009-07-02 16:23 (5 days old)
References	: http://lkml.org/lkml/2009/7/2/178

Re: [Bug #13727] Cannot Recognize Empty DVD Media

[Tarkan Erimer]

On 07/07/2009 03:01 AM, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.30.  Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13727
> Subject		: Cannot Recognize Empty DVD Media
> Submitter	: Tarkan Erimer<tarkan.erimer@turknet.net.tr>
> Date		: 2009-07-02 16:23 (5 days old)
> References	: http://lkml.org/lkml/2009/7/2/178
>
>
>    

I confirm that, as of Linux-2.6.31-rc3, it's fixed.

Re: [Bug #13727] Cannot Recognize Empty DVD Media

[Maciej Rutecki]

2009/7/15 Tarkan Erimer <tarkan.erimer-AMZSHK9Z0TXlajqSnzHT9w@public.gmane.org>:
> On 07/07/2009 03:01 AM, Rafael J. Wysocki wrote:
>>
>> This message has been generated automatically as a part of a report
>> of recent regressions.
>>
>> The following bug entry is on the current list of known regressions
>> from 2.6.30.  Please verify if it still should be listed and let me know
>> (either way).
>>
>>
>> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13727
>> Subject         : Cannot Recognize Empty DVD Media
>> Submitter       : Tarkan Erimer<tarkan.erimer@turknet.net.tr>
>> Date            : 2009-07-02 16:23 (5 days old)
>> References      : http://lkml.org/lkml/2009/7/2/178
>>
>>
>>
>
> I confirm that, as of Linux-2.6.31-rc3, it's fixed.

I also confirm, that -rc3 works OK.

Thanks
-- 
Maciej Rutecki
http://www.maciek.unixy.pl

Re: [Bug #13727] Cannot Recognize Empty DVD Media

[Maciej Rutecki]

2009/7/15 Tarkan Erimer <tarkan.erimer-AMZSHK9Z0TXlajqSnzHT9w@public.gmane.org>:
> On 07/07/2009 03:01 AM, Rafael J. Wysocki wrote:
>>
>> This message has been generated automatically as a part of a report
>> of recent regressions.
>>
>> The following bug entry is on the current list of known regressions
>> from 2.6.30.  Please verify if it still should be listed and let me know
>> (either way).
>>
>>
>> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13727
>> Subject         : Cannot Recognize Empty DVD Media
>> Submitter       : Tarkan Erimer<tarkan.erimer@turknet.net.tr>
>> Date            : 2009-07-02 16:23 (5 days old)
>> References      : http://lkml.org/lkml/2009/7/2/178
>>
>>
>>
>
> I confirm that, as of Linux-2.6.31-rc3, it's fixed.

I also confirm, that -rc3 works OK.

Thanks
-- 
Maciej Rutecki
http://www.maciek.unixy.pl

[Bug #13733] 2.6.31-rc2: irq 16: nobody cared

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13733
Subject		: 2.6.31-rc2: irq 16: nobody cared
Submitter	: Niel Lambrechts <niel.lambrechts-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-07-06 18:32 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=124690524027166&w=4

[Bug #13732] tty layer instabilities

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13732
Subject		: tty layer instabilities
Submitter	: Mikael Pettersson <mikpe-1zs4UD6AkMk@public.gmane.org>
Date		: 2009-07-06 13:43 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=124688781732419&w=4

[Bug #13731] Inconsistent {IN-RECLAIM_FS-W} -> {RECLAIM_FS-ON-W} usage.

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13731
Subject		: Inconsistent {IN-RECLAIM_FS-W} -> {RECLAIM_FS-ON-W} usage.
Submitter	: Miles Lane <miles.lane-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-07-06 4:22 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=124685417325348&w=4

[Bug #13730] hitting lockdep limits...

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13730
Subject		: hitting lockdep limits...
Submitter	: Daniel J Blueman <daniel.blueman-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-07-05 18:19 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=124681799023782&w=4

[Bug #13729] kernel BUG at fs/notify/notification.c:93!

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13729
Subject		: kernel BUG at fs/notify/notification.c:93!
Submitter	: Mikko C. <mikko.cal-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-06-04 10:16 (33 days old)
References	: http://lkml.org/lkml/2009/7/4/12
Handled-By	: Eric Paris <eparis-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

[Bug #13734] regression in 2.6.31-rcX since commit a1091aa

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.30.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13734
Subject		: regression in 2.6.31-rcX since commit a1091aa
Submitter	: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Date		: 2009-07-06 19:07 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=124690725130645&w=4
Handled-By	: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/34292/

Re: [Bug #13734] regression in 2.6.31-rcX since commit a1091aa

[Larry Finger]

Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.30.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13734
> Subject		: regression in 2.6.31-rcX since commit a1091aa
> Submitter	: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> Date		: 2009-07-06 19:07 (1 days old)
> References	: http://marc.info/?l=linux-kernel&m=124690725130645&w=4
> Handled-By	: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> Patch		: http://patchwork.kernel.org/patch/34292/

It should be OK to close this one as the patch is on its way to Linus.

Larry

Re: [Bug #13734] regression in 2.6.31-rcX since commit a1091aa

[Rafael J. Wysocki]

On Tuesday 07 July 2009, Larry Finger wrote:
> Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.30.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13734
> > Subject		: regression in 2.6.31-rcX since commit a1091aa
> > Submitter	: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> > Date		: 2009-07-06 19:07 (1 days old)
> > References	: http://marc.info/?l=linux-kernel&m=124690725130645&w=4
> > Handled-By	: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> > Patch		: http://patchwork.kernel.org/patch/34292/
> 
> It should be OK to close this one as the patch is on its way to Linus.

Yes, it's already in the Linus' tree.  Bug closed.

Thanks,
Rafael

Re: 2.6.31-rc2: Reported regressions from 2.6.30

[Andres Freund]

Hi Rafael,

On Tuesday 07 July 2009 01:42:09 Rafael J. Wysocki wrote:
> If you know of any other unresolved regressions from 2.6.30, please let me
> know either and I'll add them to the list.  Also, please let me know if any
> of the entries below are invalid.
There is also http://lkml.org/lkml/2009/6/30/398 : Soft-Lockup/Race in 
networking in 2.6.31-rc1+195 (possibly caused by netem)


Andres

Re: 2.6.31-rc2: Reported regressions from 2.6.30

[Rafael J. Wysocki]

On Tuesday 07 July 2009, Andres Freund wrote:
> Hi Rafael,
> 
> On Tuesday 07 July 2009 01:42:09 Rafael J. Wysocki wrote:
> > If you know of any other unresolved regressions from 2.6.30, please let me
> > know either and I'll add them to the list.  Also, please let me know if any
> > of the entries below are invalid.
> There is also http://lkml.org/lkml/2009/6/30/398 : Soft-Lockup/Race in 
> networking in 2.6.31-rc1+195 (possibly caused by netem)

Thanks, added to the list.

Best,
Rafael

Re: 2.6.31-rc2: Reported regressions from 2.6.30

[John Dykstra]

On Tue, 2009-07-07 at 03:25 +0200, Andres Freund wrote:
> There is also http://lkml.org/lkml/2009/6/30/398 : Soft-Lockup/Race
> in 
> networking in 2.6.31-rc1+195 (possibly caused by netem)

There is some similarity between this soft lockup and the one reported
in http://www.spinics.net/lists/netdev/msg100957.html.  In both, the
process is doing both sends and receives on raw sockets.

  --  John

Re: 2.6.31-rc2: Reported regressions from 2.6.30

[Andres Freund]

Hi John, Hi Rafael,

On Friday 10 July 2009 03:46:57 John Dykstra wrote:
> On Tue, 2009-07-07 at 03:25 +0200, Andres Freund wrote:
> > There is also http://lkml.org/lkml/2009/6/30/398 : Soft-Lockup/Race
> > in
> > networking in 2.6.31-rc1+195 (possibly caused by netem)
>
> There is some similarity between this soft lockup and the one reported
> in http://www.spinics.net/lists/netdev/msg100957.html.  In both, the
> process is doing both sends and receives on raw sockets.
The issue turned out to be a hrtimer bug - i dont see anything like it in your 
trace. If you still want to test the fix, its 
de907e8432b08f2d5966c36e0747e97c0e596810 in -tip (or 
http://lkml.org/lkml/2009/7/9/150)

Rafael: In case youre reading this, I guess you can mark that bug as resolved.

Andres

Re: 2.6.31-rc2: Reported regressions from 2.6.30

[Frans Pop]

> If you know of any other unresolved regressions from 2.6.30, please let
> me know either and I'll add them to the list.

Please add: http://lkml.org/lkml/2009/6/29/88

Reinette Chatre is handling the bug and posted a patch in 
http://lkml.org/lkml/2009/6/30/224

Thanks,
FJP

Re: 2.6.31-rc2: Reported regressions from 2.6.30

[Rafael J. Wysocki]

On Tuesday 07 July 2009, Frans Pop wrote:
> > If you know of any other unresolved regressions from 2.6.30, please let
> > me know either and I'll add them to the list.
> 
> Please add: http://lkml.org/lkml/2009/6/29/88
> 
> Reinette Chatre is handling the bug and posted a patch in 
> http://lkml.org/lkml/2009/6/30/224

Added as http://bugzilla.kernel.org/show_bug.cgi?id=13742.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html