* [BUG] New Kernel Bugs @ 2007-11-13 6:42 Natalie Protasevich 2007-11-13 11:15 ` Andrew Morton 0 siblings, 1 reply; 268+ messages in thread From: Natalie Protasevich @ 2007-11-13 6:42 UTC (permalink / raw) To: linux-kernel, akpm, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon This is the listing of the open bugs that are relatively new, around 2.6.22 and up. They are vaguely classified by specific area. (not a full list, there are more :) The good part is that reporters of the bugs below are still around and haven't dissipated, or disposed of their hardware, so it is a good time to get the bugs. Those bugzillas that have been started as regressions on Rafael's list are not mentioned here so far, since they are being tracked as new regressions already. It would be appreciated if the corresponding maintenance team could take a look, close off any which are fixed and see if they can fix any which aren't. NOTE: when replying to this email, please add the bug number to the Subject in the form [Bug 1234] so that bugzilla will capture the discussion. Thanks. ACPI==================================================================== System does not load without acpi=off ide=nodma noapic http://bugzilla.kernel.org/show_bug.cgi?id=9358 Kernel: 2.6.23.1 ACPI Error attaching device data http://bugzilla.kernel.org/show_bug.cgi?id=9354 Kernel: 2.6.24-rc2 /proc/acpi/battery displays Incorrect voltages http://bugzilla.kernel.org/show_bug.cgi?id=9341 Kernel: 2.6.23.1 PATA scan: ACPI Exception AE_AML_PACKAGE_LIMIT... is beyond end of object http://bugzilla.kernel.org/show_bug.cgi?id=9320 Kernel: 2.6.24-rc2 (Tejun: calling _GTF without calling _STM first. _GTM doesn't have any prerequisite (it can't). Can someone familiar with ACPI tell me why the method is failing? At any rate, libata should work fine regardless of ACPI failures. Maybe it's time to start blacklist to skip ATA-ACPI for some boards to avoid those annoying messages during boot) ACPI Battery Info in /sys but not /proc/acpi http://bugzilla.kernel.org/show_bug.cgi?id=9183 Kernel: 2.6.23-rc8-mm2 When using ACPI on a Compaq Presario V6221EU the laptop goes into deadlock after a random amount of time http://bugzilla.kernel.org/show_bug.cgi?id=9118 Kernel: 2.6.23-rc6 ACPI video driver should validate brightness level before setting it via _BCM http://bugzilla.kernel.org/show_bug.cgi?id=9277 Kernel: 2.6.23 VIDEO/DVB dvb driver reboot system http://bugzilla.kernel.org/show_bug.cgi?id=9357 Kernel: 2.6.21.5 PLATFORM=============================================================== xipImage is built so that uBoot cant run it (ARM) http://bugzilla.kernel.org/show_bug.cgi?id=9356 Kernel: 2.6.21 Samsung R20 - ACPI: PCI Root Bridge [PCI0] (0000:00) http://bugzilla.kernel.org/show_bug.cgi?id=9339 Kernel: 2.6.24 (boot is very long ..MP-BIOS bug: 8254 timer not connected to IO-APIC then the boot stop at : ACPI: PCI Root Bridge [PCI0] (0000:00) (during 3 minutes, and boot continue) system_64.h: switch_to inline asm should be more robbust wrt optimizations http://bugzilla.kernel.org/show_bug.cgi?id=9302 Kernel: 2.6.24-rc1 with CONFIG_NO_HZ and/or CONFIG_HPET_TIMER set kernel 2.6.23 doesn't boot (ARM, Timer) http://bugzilla.kernel.org/show_bug.cgi?id=9229 Kernel: 2.6.23 NETWORKING=========================================================== RTNLGRP_ND_USEROPT does not report ifindex (IPv6) http://bugzilla.kernel.org/show_bug.cgi?id=9349 Kernel: 2.6.24+ a kernel error happend in the func: __skb_dequeue when using in pfifo_fast_dequeue http://bugzilla.kernel.org/show_bug.cgi?id=9342 Kernel: 2.6.11.1 - reporter asked to try recent kernel e100 does not work after boot http://bugzilla.kernel.org/show_bug.cgi?id=9336 Kernel: 2.6.23.1 2.6.23.1-smp kernel panic (network-related) http://bugzilla.kernel.org/show_bug.cgi?id=9318 Kernel: 2.6.23.1 Infiniband panic sundance -> 4port D-Link System Inc DFE-580TX -> Log errors http://bugzilla.kernel.org/show_bug.cgi?id=9311 Kernel: 2.6.22.9 via-rhine driver stalls with: PHY status 786d, resetting... http://bugzilla.kernel.org/show_bug.cgi?id=9300 Kernel: 2.6.23+ Weird network problems with 2.6.23-rc2 http://bugzilla.kernel.org/show_bug.cgi?id=9080 http://lkml.org/lkml/2007/8/11/40 - description rt2500pci: low TCP throughput (wireless) http://bugzilla.kernel.org/show_bug.cgi?id=9273 Kernel: 2.6.24-rc1 This is a regression Unable to build wifi network between zd1201 and b43 http://bugzilla.kernel.org/show_bug.cgi?id=9237 Kernel: 2.6.24-rc1 Crash after module unload in b43 (wireless) http://bugzilla.kernel.org/show_bug.cgi?id=9233 Kernel: 2.6.24-rc1 (net typhoon) "no descs for cmd, had (needed) 0 (1) cmd, 31 (7) resp" http://bugzilla.kernel.org/show_bug.cgi?id=9225 Kernel: 2.6.23.1 IDE/SATA========================================================= pata_pdc202xx_old excessive ATA bus errors http://bugzilla.kernel.org/show_bug.cgi?id=9337 2.6.24-rc2 Drive seagate ST380011AS needs to be blacklisted http://bugzilla.kernel.org/show_bug.cgi?id=9309 Kernel: 2.6.22.X DVD-RAM umount and disk free bug http://bugzilla.kernel.org/show_bug.cgi?id=9265 Kernel: 2.6.15 (asked to try current kernel) FILE SYSTEMS======================================================= ext4: delalloc space accounting problem drops data http://bugzilla.kernel.org/show_bug.cgi?id=9329 Kernel: 2.6.24-rc1 POSIX Access Control Lists cause bogus file system check errors http://bugzilla.kernel.org/show_bug.cgi?id=9241 Kernel: 2.6.23.1 MEMORY MANAGEMENT================================================ My system hangs when it has no more free memory to allocate via malloc() http://bugzilla.kernel.org/show_bug.cgi?id=9316 Kernel: 2.6.23 User program, "My system hangs when it has no more free memory to allocate via malloc()" BUG: unable to handle kernel paging request at virtual address 26121228/kswapd0[231] exited with preempt_count 1 http://bugzilla.kernel.org/show_bug.cgi?id=9305 EIP is at free_block+0x6d/0xe4 Kernel: 2.6.22.6 POWER MANAGEMENT================================================== IBM X41 looses time after Suspend2Disk http://bugzilla.kernel.org/show_bug.cgi?id=9314 Kernel: 2.6.23 Suspend to RAM resume hangs on a tickless (NO_HZ) kernel http://bugzilla.kernel.org/show_bug.cgi?id=9275 Kernel: 2.6.23 This is HP notebook nc6320 T2400 945GM VIDEO DRIVERS======================================================== No text consoles with FRAMEBUFFER_CONSOLE_DETECT_PRIMARY http://bugzilla.kernel.org/show_bug.cgi?id=9310 Kernel: 2.6.24-rc1 This is a regression PARALLEL PORT======================================================== LPC IT8705 POST port making noise on parallel port http://bugzilla.kernel.org/show_bug.cgi?id=9306 Kernel: 2.6.16+ I/O STORAGE=========================================================== kernel bug from pktcdvd http://bugzilla.kernel.org/show_bug.cgi?id=9294 Kernel: 2.6.23 After pci-e video card was installed, pci add-on usb card & firewire card fail http://bugzilla.kernel.org/show_bug.cgi?id=9223 Kernel: 2.6.20 (testing of latest kernel requested) SCSI================================================================== qla2xxx: driver initialization does not complete when booting with Port connected http://bugzilla.kernel.org/show_bug.cgi?id=9267 Kernel: 2.6.23.1 SOUND ALSA============================================================ Unable to load snd-hda-intel module: Unknown symbol in module, or unknown parameter http://bugzilla.kernel.org/show_bug.cgi?id=9242 Kernel: 2.6.24-rc1 usbaudio microphone: regular sound distortion on several Logitech Webcams http://bugzilla.kernel.org/show_bug.cgi?id=9230 Kernel: 2.6.22.9 HID==================================================================== Kernel NULL pointer dereference at :usbhid:hiddev_ioctl+0x2f/0xabc http://bugzilla.kernel.org/show_bug.cgi?id=9216 Kernel: 2.6.23.1 Looks like this is a regression ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 6:42 [BUG] New Kernel Bugs Natalie Protasevich @ 2007-11-13 11:15 ` Andrew Morton 2007-11-13 11:24 ` Jens Axboe ` (11 more replies) 0 siblings, 12 replies; 268+ messages in thread From: Andrew Morton @ 2007-11-13 11:15 UTC (permalink / raw) To: Natalie Protasevich Cc: linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Mon, 12 Nov 2007 22:42:32 -0800 "Natalie Protasevich" <protasnb@gmail.com> wrote: > This is the listing of the open bugs that are relatively new, around > 2.6.22 and up. They are vaguely classified by specific area. > (not a full list, there are more :) > > The good part is that reporters of the bugs below are still around and > haven't dissipated, or disposed of their hardware, so it is a good > time to get the bugs. > Those bugzillas that have been started as regressions on Rafael's list > are not mentioned here so far, since they are being tracked as new > regressions already. Thanks. > It would be appreciated if the corresponding maintenance team could take a > look, close off any which are fixed and see if they can fix any which aren't. > > NOTE: when replying to this email, please add the bug number to the Subject in > the form [Bug 1234] so that bugzilla will capture the discussion. > Thanks. You're optimistic. > ACPI==================================================================== > > System does not load without acpi=off ide=nodma noapic > http://bugzilla.kernel.org/show_bug.cgi?id=9358 > Kernel: 2.6.23.1 One response from a developer > ACPI Error attaching device data > http://bugzilla.kernel.org/show_bug.cgi?id=9354 > Kernel: 2.6.24-rc2 Zero responses from developers > /proc/acpi/battery displays Incorrect voltages > http://bugzilla.kernel.org/show_bug.cgi?id=9341 > Kernel: 2.6.23.1 Zero responses from developers > PATA scan: ACPI Exception AE_AML_PACKAGE_LIMIT... is beyond end of object > http://bugzilla.kernel.org/show_bug.cgi?id=9320 > Kernel: 2.6.24-rc2 > (Tejun: calling _GTF without calling _STM first. _GTM doesn't have any > prerequisite (it can't). Can someone familiar with ACPI tell me why the method > is failing? At any rate, libata should work fine regardless of ACPI failures. > Maybe it's time to start blacklist to skip ATA-ACPI for some boards to avoid > those annoying messages during boot) Tejun doing stuff > ACPI Battery Info in /sys but not /proc/acpi > http://bugzilla.kernel.org/show_bug.cgi?id=9183 > Kernel: 2.6.23-rc8-mm2 Marked as a duplicate of an already-resolved bug. > > When using ACPI on a Compaq Presario V6221EU the laptop goes into > deadlock after a random amount of time > http://bugzilla.kernel.org/show_bug.cgi?id=9118 > Kernel: 2.6.23-rc6 Someone called Jike Song is trying to help out. Regular developers awol. > > ACPI video driver should validate brightness level before setting it via _BCM > http://bugzilla.kernel.org/show_bug.cgi?id=9277 > Kernel: 2.6.23 Zero responses from developers > VIDEO/DVB > > dvb driver reboot system > http://bugzilla.kernel.org/show_bug.cgi?id=9357 > Kernel: 2.6.21.5 Mauro thinks it might be bad hardware > > PLATFORM=============================================================== > > xipImage is built so that uBoot cant run it (ARM) > http://bugzilla.kernel.org/show_bug.cgi?id=9356 > Kernel: 2.6.21 Zero responses from developers > > Samsung R20 - ACPI: PCI Root Bridge [PCI0] (0000:00) > http://bugzilla.kernel.org/show_bug.cgi?id=9339 > Kernel: 2.6.24 > (boot is very long > ..MP-BIOS bug: 8254 timer not connected to IO-APIC > then the boot stop at : > ACPI: PCI Root Bridge [PCI0] (0000:00) > (during 3 minutes, and boot continue) No response from developers > system_64.h: switch_to inline asm should be more robbust wrt optimizations > http://bugzilla.kernel.org/show_bug.cgi?id=9302 > Kernel: 2.6.24-rc1 Not really a bug. > with CONFIG_NO_HZ and/or CONFIG_HPET_TIMER set kernel 2.6.23 doesn't > boot (ARM, Timer) > http://bugzilla.kernel.org/show_bug.cgi?id=9229 > Kernel: 2.6.23 No response from developers > NETWORKING=========================================================== > > RTNLGRP_ND_USEROPT does not report ifindex (IPv6) > http://bugzilla.kernel.org/show_bug.cgi?id=9349 > Kernel: 2.6.24+ No response from developers > a kernel error happend in the func: __skb_dequeue when using in > pfifo_fast_dequeue > http://bugzilla.kernel.org/show_bug.cgi?id=9342 > Kernel: 2.6.11.1 - reporter asked to try recent kernel No response from developers > e100 does not work after boot > http://bugzilla.kernel.org/show_bug.cgi?id=9336 > Kernel: 2.6.23.1 No response from developers > 2.6.23.1-smp kernel panic (network-related) > http://bugzilla.kernel.org/show_bug.cgi?id=9318 > Kernel: 2.6.23.1 > Infiniband panic No response from developers > sundance -> 4port D-Link System Inc DFE-580TX -> Log errors > http://bugzilla.kernel.org/show_bug.cgi?id=9311 > Kernel: 2.6.22.9 No response from developers > via-rhine driver stalls with: PHY status 786d, resetting... > http://bugzilla.kernel.org/show_bug.cgi?id=9300 > Kernel: 2.6.23+ No response from developers > > Weird network problems with 2.6.23-rc2 > http://bugzilla.kernel.org/show_bug.cgi?id=9080 > http://lkml.org/lkml/2007/8/11/40 - description No response from developers > rt2500pci: low TCP throughput (wireless) > http://bugzilla.kernel.org/show_bug.cgi?id=9273 > Kernel: 2.6.24-rc1 > This is a regression No response from developers > Unable to build wifi network between zd1201 and b43 > http://bugzilla.kernel.org/show_bug.cgi?id=9237 > Kernel: 2.6.24-rc1 No response from developers > Crash after module unload in b43 (wireless) > http://bugzilla.kernel.org/show_bug.cgi?id=9233 > Kernel: 2.6.24-rc1 No response from developers > (net typhoon) "no descs for cmd, had (needed) 0 (1) cmd, 31 (7) resp" > http://bugzilla.kernel.org/show_bug.cgi?id=9225 > Kernel: 2.6.23.1 No response from developers > > IDE/SATA========================================================= > > pata_pdc202xx_old excessive ATA bus errors > http://bugzilla.kernel.org/show_bug.cgi?id=9337 > 2.6.24-rc2 No response from developers > Drive seagate ST380011AS needs to be blacklisted > http://bugzilla.kernel.org/show_bug.cgi?id=9309 > Kernel: 2.6.22.X Jeff and Tehun did some stuff. > DVD-RAM umount and disk free bug > http://bugzilla.kernel.org/show_bug.cgi?id=9265 > Kernel: 2.6.15 (asked to try current kernel) No response from developers > FILE SYSTEMS======================================================= > > ext4: delalloc space accounting problem drops data > http://bugzilla.kernel.org/show_bug.cgi?id=9329 > Kernel: 2.6.24-rc1 No response from developers > POSIX Access Control Lists cause bogus file system check errors > http://bugzilla.kernel.org/show_bug.cgi?id=9241 > Kernel: 2.6.23.1 Andreas did some work, seemed to lose interest. > MEMORY MANAGEMENT================================================ > > My system hangs when it has no more free memory to allocate via malloc() > http://bugzilla.kernel.org/show_bug.cgi?id=9316 > Kernel: 2.6.23 > User program, "My system hangs when it has no more free memory to > allocate via malloc()" Rafael poked Thomas a week ago, to no effect. Thomas has been travelling. > BUG: unable to handle kernel paging request at virtual address > 26121228/kswapd0[231] exited with preempt_count 1 > http://bugzilla.kernel.org/show_bug.cgi?id=9305 > EIP is at free_block+0x6d/0xe4 > Kernel: 2.6.22.6 No response from developers > POWER MANAGEMENT================================================== > > IBM X41 looses time after Suspend2Disk > http://bugzilla.kernel.org/show_bug.cgi?id=9314 > Kernel: 2.6.23 Rafael poked Thomas a week ago, to no effect. Thomas has been travelling. > Suspend to RAM resume hangs on a tickless (NO_HZ) kernel > http://bugzilla.kernel.org/show_bug.cgi?id=9275 > Kernel: 2.6.23 > This is HP notebook nc6320 T2400 945GM No response from developers > > VIDEO DRIVERS======================================================== > > No text consoles with FRAMEBUFFER_CONSOLE_DETECT_PRIMARY > http://bugzilla.kernel.org/show_bug.cgi?id=9310 > Kernel: 2.6.24-rc1 > This is a regression No response from developers > > PARALLEL PORT======================================================== > > LPC IT8705 POST port making noise on parallel port > http://bugzilla.kernel.org/show_bug.cgi?id=9306 > Kernel: 2.6.16+ > No response from developers > I/O STORAGE=========================================================== > > kernel bug from pktcdvd > http://bugzilla.kernel.org/show_bug.cgi?id=9294 > Kernel: 2.6.23 I think we might have fixed this. > After pci-e video card was installed, pci add-on usb card & firewire card fail > http://bugzilla.kernel.org/show_bug.cgi?id=9223 > Kernel: 2.6.20 (testing of latest kernel requested) No response from developers > SCSI================================================================== > > qla2xxx: driver initialization does not complete when booting with > Port connected > http://bugzilla.kernel.org/show_bug.cgi?id=9267 > Kernel: 2.6.23.1 No response from developers > SOUND ALSA============================================================ > > Unable to load snd-hda-intel module: Unknown symbol in module, or > unknown parameter > http://bugzilla.kernel.org/show_bug.cgi?id=9242 > Kernel: 2.6.24-rc1 Takashi has responded > usbaudio microphone: regular sound distortion on several Logitech Webcams > http://bugzilla.kernel.org/show_bug.cgi?id=9230 > Kernel: 2.6.22.9 Clemens responded > HID==================================================================== > > Kernel NULL pointer dereference at :usbhid:hiddev_ioctl+0x2f/0xabc > http://bugzilla.kernel.org/show_bug.cgi?id=9216 > Kernel: 2.6.23.1 > Looks like this is a regression No response from developers So I count around seven reports which people are doing something with and twenty seven which have been just ignored. Three of these reports have been identified as regressions. All three of those remain unresponded to. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 11:15 ` Andrew Morton @ 2007-11-13 11:24 ` Jens Axboe 2007-11-13 11:33 ` Evgeniy Polyakov ` (10 subsequent siblings) 11 siblings, 0 replies; 268+ messages in thread From: Jens Axboe @ 2007-11-13 11:24 UTC (permalink / raw) To: Andrew Morton Cc: Natalie Protasevich, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tue, Nov 13 2007, Andrew Morton wrote: > > I/O STORAGE=========================================================== > > > > kernel bug from pktcdvd > > http://bugzilla.kernel.org/show_bug.cgi?id=9294 > > Kernel: 2.6.23 > > I think we might have fixed this. It's fixed and merged, I just forgot to close the bugzilla. Did so now. -- Jens Axboe ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 11:15 ` Andrew Morton 2007-11-13 11:24 ` Jens Axboe @ 2007-11-13 11:33 ` Evgeniy Polyakov 2007-11-13 11:39 ` David Miller ` (9 subsequent siblings) 11 siblings, 0 replies; 268+ messages in thread From: Evgeniy Polyakov @ 2007-11-13 11:33 UTC (permalink / raw) To: Andrew Morton; +Cc: Natalie Protasevich, linux-kernel, netdev On Tue, Nov 13, 2007 at 03:15:53AM -0800, Andrew Morton (akpm@linux-foundation.org) wrote: > > NETWORKING=========================================================== > > > > RTNLGRP_ND_USEROPT does not report ifindex (IPv6) > > http://bugzilla.kernel.org/show_bug.cgi?id=9349 > > Kernel: 2.6.24+ > > No response from developers Fixed (extended) in the DaveM's tree (or will be soon - patch was submitted by Pierre Ynard). Sorry, others are either driver related (and thus require hardware to be tested on and maintainers to be kicked in) or too obscure (like 2.6.11 bug and weird network problem which is undetectible on other systems). Yes, we suck, but we try to recover :) -- Evgeniy Polyakov ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 11:15 ` Andrew Morton 2007-11-13 11:24 ` Jens Axboe 2007-11-13 11:33 ` Evgeniy Polyakov @ 2007-11-13 11:39 ` David Miller 2007-11-13 11:49 ` Andrew Morton 2007-11-13 11:47 ` Jarek Poplawski ` (8 subsequent siblings) 11 siblings, 1 reply; 268+ messages in thread From: David Miller @ 2007-11-13 11:39 UTC (permalink / raw) To: akpm Cc: protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon From: Andrew Morton <akpm@linux-foundation.org> Date: Tue, 13 Nov 2007 03:15:53 -0800 > > NETWORKING=========================================================== > > > > RTNLGRP_ND_USEROPT does not report ifindex (IPv6) > > http://bugzilla.kernel.org/show_bug.cgi?id=9349 > > Kernel: 2.6.24+ > > No response from developers That's funny, then how come there was a proper patch fix posted and it's now in my tree ready to go to Linus? I think you like just saying "No response from developers" over and over again to make some of point about how developers are ignoring lots of bugs. That's fine, but at least be accurate about it :-) ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 11:39 ` David Miller @ 2007-11-13 11:49 ` Andrew Morton 2007-11-13 11:58 ` David Miller 0 siblings, 1 reply; 268+ messages in thread From: Andrew Morton @ 2007-11-13 11:49 UTC (permalink / raw) To: David Miller Cc: protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tue, 13 Nov 2007 03:39:46 -0800 (PST) David Miller <davem@davemloft.net> wrote: > From: Andrew Morton <akpm@linux-foundation.org> > Date: Tue, 13 Nov 2007 03:15:53 -0800 > > > > NETWORKING=========================================================== > > > > > > RTNLGRP_ND_USEROPT does not report ifindex (IPv6) > > > http://bugzilla.kernel.org/show_bug.cgi?id=9349 > > > Kernel: 2.6.24+ > > > > No response from developers > > That's funny, then how come there was a proper patch fix posted > and it's now in my tree ready to go to Linus? > > I think you like just saying "No response from developers" over and > over again to make some of point about how developers are ignoring > lots of bugs. That's fine, but at least be accurate about it :-) Do you believe that our response to bug reports is adequate? ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 11:49 ` Andrew Morton @ 2007-11-13 11:58 ` David Miller 2007-11-13 12:12 ` Andrew Morton 0 siblings, 1 reply; 268+ messages in thread From: David Miller @ 2007-11-13 11:58 UTC (permalink / raw) To: akpm Cc: protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon From: Andrew Morton <akpm@linux-foundation.org> Date: Tue, 13 Nov 2007 03:49:16 -0800 > Do you believe that our response to bug reports is adequate? Do you feel that making us feel and look like shit helps? I guess I'm just masterbating here all night long with the 46 bug fixes I've reviewed fully and queued up into my tree. Along with all the 10 or so -stable submissions I did tonight as well. When someone like me is bug fixing full time, I take massive offense to the impression you're trying to give especially when it's directed at the networking. So turn it down a notch Andrew. I bet if you did things like list explicitly by name every single person who adds a bug fix (however trivial) to an -mm release instead of a new feature, you'll better achieve your goal than what you're doing here. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 11:58 ` David Miller @ 2007-11-13 12:12 ` Andrew Morton 2007-11-13 12:32 ` David Miller 2007-11-13 13:40 ` Ingo Molnar 0 siblings, 2 replies; 268+ messages in thread From: Andrew Morton @ 2007-11-13 12:12 UTC (permalink / raw) To: David Miller Cc: protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tue, 13 Nov 2007 03:58:24 -0800 (PST) David Miller <davem@davemloft.net> wrote: > From: Andrew Morton <akpm@linux-foundation.org> > Date: Tue, 13 Nov 2007 03:49:16 -0800 > > > Do you believe that our response to bug reports is adequate? > > Do you feel that making us feel and look like shit helps? > That doesn't answer my question. See, first we need to work out whether we have a problem. If we do this, then we can then have a think about what to do about it. I tried to convince the 2006 KS attendees that we have a problem and I resoundingly failed. People seemed to think that we're doing OK. But it appears that data such as this contradicts that belief. This is not a minor matter. If the kernel _is_ slowly deteriorating then this won't become readily apparent until it has been happening for a number of years. By that stage there will be so much work to do to get us back to an acceptable level that it will take a huge effort. And it will take a long time after that for the kerel to get its reputation back. So it is important that we catch deterioration *early* if it is happening. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 12:12 ` Andrew Morton @ 2007-11-13 12:32 ` David Miller 2007-11-13 19:02 ` Andrew Morton 2007-11-13 19:32 ` [BUG] New Kernel Bugs Russell King 2007-11-13 13:40 ` Ingo Molnar 1 sibling, 2 replies; 268+ messages in thread From: David Miller @ 2007-11-13 12:32 UTC (permalink / raw) To: akpm Cc: protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon From: Andrew Morton <akpm@linux-foundation.org> Date: Tue, 13 Nov 2007 04:12:59 -0800 > On Tue, 13 Nov 2007 03:58:24 -0800 (PST) David Miller <davem@davemloft.net> wrote: > > > From: Andrew Morton <akpm@linux-foundation.org> > > Date: Tue, 13 Nov 2007 03:49:16 -0800 > > > > > Do you believe that our response to bug reports is adequate? > > > > Do you feel that making us feel and look like shit helps? > > That doesn't answer my question. > > See, first we need to work out whether we have a problem. If we do this, > then we can then have a think about what to do about it. > > I tried to convince the 2006 KS attendees that we have a problem and I > resoundingly failed. People seemed to think that we're doing OK. > > But it appears that data such as this contradicts that belief. > > This is not a minor matter. If the kernel _is_ slowly deteriorating then > this won't become readily apparent until it has been happening for a number > of years. By that stage there will be so much work to do to get us back to > an acceptable level that it will take a huge effort. And it will take a > long time after that for the kerel to get its reputation back. > > So it is important that we catch deterioration *early* if it is happening. You tell me what I should spend my time working on, and I promise to do it OK? :-) For example, if I have a choice between a TCP crash just about anyone can hit and some obscure issue only reported with some device nearly nobody has, which one should I analyze and work on? That's the problem. All of us prioritize and it means the chaff collects at the bottom. You cannot fix that except by getting more bug fixers so that the chaff pile has a chance to get smaller. Luckily if the report being ignored isn't chaff, it will show up again (and again and again) and this triggers a reprioritization because not only is the bug no longer chaff, it also now got a lot of information tagged to it so it's a double worthwhile investment to work on the problem. I think a lot of bugs that "aren't getting looked at" are simply sitting in some early stage of this process. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 12:32 ` David Miller @ 2007-11-13 19:02 ` Andrew Morton 2007-11-13 20:00 ` Christian Kujau 2007-11-13 19:32 ` [BUG] New Kernel Bugs Russell King 1 sibling, 1 reply; 268+ messages in thread From: Andrew Morton @ 2007-11-13 19:02 UTC (permalink / raw) To: David Miller Cc: protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tue, 13 Nov 2007 04:32:07 -0800 (PST) David Miller <davem@davemloft.net> wrote: > From: Andrew Morton <akpm@linux-foundation.org> > Date: Tue, 13 Nov 2007 04:12:59 -0800 > > > On Tue, 13 Nov 2007 03:58:24 -0800 (PST) David Miller <davem@davemloft.net> wrote: > > > > > From: Andrew Morton <akpm@linux-foundation.org> > > > Date: Tue, 13 Nov 2007 03:49:16 -0800 > > > > > > > Do you believe that our response to bug reports is adequate? > > > > > > Do you feel that making us feel and look like shit helps? > > > > That doesn't answer my question. > > > > See, first we need to work out whether we have a problem. If we do this, > > then we can then have a think about what to do about it. > > > > I tried to convince the 2006 KS attendees that we have a problem and I > > resoundingly failed. People seemed to think that we're doing OK. > > > > But it appears that data such as this contradicts that belief. > > > > This is not a minor matter. If the kernel _is_ slowly deteriorating then > > this won't become readily apparent until it has been happening for a number > > of years. By that stage there will be so much work to do to get us back to > > an acceptable level that it will take a huge effort. And it will take a > > long time after that for the kerel to get its reputation back. > > > > So it is important that we catch deterioration *early* if it is happening. > > You tell me what I should spend my time working on, and I promise to > do it OK? :-) My suggestion: regressions. If we're really active in chasing down the regressions then I think we can be confident that the kernel isn't deteriorating. Probably it will be improving as we also fix some always-been-there bugs. I think that we're fairly good about working the regressions in Adrian/Michal/Rafael's lists but once Linus releases 2.6.x we tend to let the unsolved ones slide, and we don't pay as much attention to the regressions which 2.6.x testers report. > For example, if I have a choice between a TCP crash just about anyone > can hit and some obscure issue only reported with some device nearly > nobody has, which one should I analyze and work on? > > That's the problem. All of us prioritize and it means the chaff > collects at the bottom. You cannot fix that except by getting more > bug fixers so that the chaff pile has a chance to get smaller. > > Luckily if the report being ignored isn't chaff, it will show up again > (and again and again) and this triggers a reprioritization because not > only is the bug no longer chaff, it also now got a lot of information > tagged to it so it's a double worthwhile investment to work on the > problem. > > I think a lot of bugs that "aren't getting looked at" are simply > sitting in some early stage of this process. Yes, that's a useful technique. If multiple people are being hurt a lot by a bug then that's a more important one to fix than the single-person minor-irritant bug. otoh that doesn't work very well with driver/platform bugs. Often these are regressions which only a single person can reproduce within the time window which we have in which we can fix it. If we don't fix it in that window it'll go out to distros and presumably some more people will hit it. So I don't see much alternative here to the traditional work-with-the-originator way of resolving it. git bisection should really help us with these regressions but it doesn't appear that people are using as much as one would like. I'm hoping that the very good http://www.kernel.org/doc/local/git-quick.html will help us out here. Thanks to the mystery person who prepared that. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 19:02 ` Andrew Morton @ 2007-11-13 20:00 ` Christian Kujau 2007-11-13 21:04 ` Andrew Morton 0 siblings, 1 reply; 268+ messages in thread From: Christian Kujau @ 2007-11-13 20:00 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, torvalds On Tue, 13 Nov 2007, Andrew Morton wrote: > I think that we're fairly good about working the regressions in > Adrian/Michal/Rafael's lists but once Linus releases 2.6.x we tend to let > the unsolved ones slide, and we don't pay as much attention to the > regressions which 2.6.x testers report. Can't we wait until all regressions[0] are fixed before releasing a new 2.6.x? I'd consider regressions a *literal* show stopper, and with this policy they just have be fixed, nothing would "slide"... my 2 cents, Christian. [0] preferably only reproducible regressions, with responsive reporters. -- BOFH excuse #380: Operators killed when huge stack of backup tapes fell over. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 20:00 ` Christian Kujau @ 2007-11-13 21:04 ` Andrew Morton 2007-11-13 16:56 ` Nick Piggin ` (2 more replies) 0 siblings, 3 replies; 268+ messages in thread From: Andrew Morton @ 2007-11-13 21:04 UTC (permalink / raw) To: Christian Kujau; +Cc: linux-kernel, torvalds On Tue, 13 Nov 2007 21:00:30 +0100 (CET) Christian Kujau <lists@nerdbynature.de> wrote: > On Tue, 13 Nov 2007, Andrew Morton wrote: > > I think that we're fairly good about working the regressions in > > Adrian/Michal/Rafael's lists but once Linus releases 2.6.x we tend to let > > the unsolved ones slide, and we don't pay as much attention to the > > regressions which 2.6.x testers report. > > Can't we wait until all regressions[0] are fixed before releasing a new > 2.6.x? I'd consider regressions a *literal* show stopper, and with this > policy they just have be fixed, nothing would "slide"... > Problem is that everyone would then sit around pumping shiny new features into their trees waiting until someone else fixes the regressions. There are a number of process things we _could_ do. Like - have bugfix-only kernel releases - Just refuse to merge any non-bugfix patches for a subsystem when it is determined that the subsystem has "too many" regressions. - Create an "if you added a regression, you should fix some other bug too" rule. - probably other stuff. But we can't/shouldn't do any of that until it is generally agreed that we have a problem and that the problem is of sufficient magnitude that process changes are needed to address it. We aren't at that stage yet. Here's an important point: developers have a fixed amount of development time. They spend some of that time fixing bugs and the rest of that time on <otherstuff>. And while one could cook up all sorts of wonderful process changes, they all would be aimed at a single thing: shifting some of the developers' time away from <otherstuff> and onto bugfixing. At this stage the only tool which is being deployed to attempt to bring about that reprioritisation is suasion. aka "lkml flamewar". ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 21:04 ` Andrew Morton @ 2007-11-13 16:56 ` Nick Piggin 2007-11-14 19:54 ` Linus Torvalds 2007-11-13 21:37 ` Adrian Bunk 2007-11-13 21:56 ` Christian Kujau 2 siblings, 1 reply; 268+ messages in thread From: Nick Piggin @ 2007-11-13 16:56 UTC (permalink / raw) To: Andrew Morton; +Cc: Christian Kujau, linux-kernel, torvalds rant on :) ... These aren't directed specifically at Andrew, but everyone who merges patches or is involved in the release process. On Wednesday 14 November 2007 08:04, Andrew Morton wrote: > On Tue, 13 Nov 2007 21:00:30 +0100 (CET) Christian Kujau <lists@nerdbynature.de> wrote: > > On Tue, 13 Nov 2007, Andrew Morton wrote: > > > I think that we're fairly good about working the regressions in > > > Adrian/Michal/Rafael's lists but once Linus releases 2.6.x we tend to > > > let the unsolved ones slide, and we don't pay as much attention to the > > > regressions which 2.6.x testers report. > > > > Can't we wait until all regressions[0] are fixed before releasing a new > > 2.6.x? I'd consider regressions a *literal* show stopper, and with this > > policy they just have be fixed, nothing would "slide"... > > Problem is that everyone would then sit around pumping shiny new features > into their trees waiting until someone else fixes the regressions. Not if you said their regression causing patches will get reverted unless it can be fixed for release. For everyone not involved, they'll be doing their own productive things and we don't want to stop that. > There are a number of process things we _could_ do. Like > > - have bugfix-only kernel releases I don't know why this would be better than the above. If you are worried about perception of released kernels, then it would actually be worse, because the non-bugfix-only releases will get out there, and the numbering scheme gets yet another level of complexity. Make 2.6.24-rc3 your bugfix only release. If you argue that would make the cycle too long, the solution is to merge less stuff in 2.6.24-rc1. > - Just refuse to merge any non-bugfix patches for a subsystem when it is > determined that the subsystem has "too many" regressions. If you don't allow regressions to build up over releases in the first place, then this naturally gets done for you. > - Create an "if you added a regression, you should fix some other bug > too" rule. That's pretty annoying. Everybody tries not to introduce regressions. It's just a natural part of development. You just have to make the system work well within that constraint. It's easy: "if you add a regression, you fix it. If it doesn't get fixed, we either don't release or we revert your patch." That takes care of regressions. Now for actually improving quality. I think to do that you have to encourage code review and bug fixing. - Take reviewers seriously, and don't allow patches to be merged if they have outstanding unaddressed comments (unaddressed doesn't have to mean changed completely to reviewers taste, but at least answered questions and provided rationale). Don't merge unreviewed patches. - Prioritise bugfixes and regression fixes. I realise they can be very complex changes, but I am disappointed sometimes at how some of my bugfix attempts are received. Things like silent and un-reproduceable pagecache corruption, memory ordering bugs which will likewise cause silent and un-reproduceable data corruption are totally unacceptable IMO; worse than most simple (eg. fail-stop, performance) regressions. To see them struggle because the patch isn't perfect right off the bat, they're deemed too hard, or they clash with some pending "feature" is a pity to me. I don't expect thanks or even help, but at least having some priority would help me stay interested and the bug to get fixed quicker. For a concrete example: when I did the remap_vmalloc_range() patch, I converted over all in-tree drivers to use the range checking and much safer remap_vmalloc_range. During this conversion I found several places where drivers were potentially inserting mappings wrongly or not checking user inputs properly (eg. corruption and/or security issues). And tried to fix them. And yet the whole patchset was dropped, despite being simpler and cleaner code, and attempting to fix bugs. Because I wasn't able to test the hardware (and/or maintainers didn't respond). It didn't even get a chance in -mm (and if it had, it probably would have been immediately dropped if I had a typo somewhere). Those patches are still rotting on my hdd somewhere... So it is actually far easier for me to shut my eyes and not bother reviewing any in-tree code when introducing a new API or something like that. And yet something like CFS basically bypasses the review and test process entirely and gets upstream at least a release too soon. That isn't anything against the technical side of CFS development, which I'm a lot happier with than the old scheduler. It is a problem with the merging and release process. - "if you added a regression, you should fix some other bug too" rule should be "if you want to add a new feature, you should review a number of other patches". Review points can be traded. If this could be done right, it would create a direct economic incentive to review. OK, the last one is my pipedream that will never happen ;) But you should understand what can be achieved, what can't, and what will be the most productive way to change the system. > - probably other stuff. > > But we can't/shouldn't do any of that until it is generally agreed that we > have a problem and that the problem is of sufficient magnitude that process > changes are needed to address it. We aren't at that stage yet. Well I don't think I need to agree that the kernel is getting worse in order to think there are ways we can change the system to help it get better. We can make changes for the better without making things more difficult for anybody, IMO. But is the kernel getting worse? I wonder if it has anything to do with getting further away from large distros? (and thus will get better again during the next distro release cycle). Because I know SLES9 took a huge amount of work to get stable. Or do you think it is getting worse since 2.6.0? > Here's an important point: developers have a fixed amount of development > time. They spend some of that time fixing bugs and the rest of that time > on <otherstuff>. And while one could cook up all sorts of wonderful > process changes, they all would be aimed at a single thing: shifting some > of the developers' time away from <otherstuff> and onto bugfixing. > > At this stage the only tool which is being deployed to attempt to bring > about that reprioritisation is suasion. aka "lkml flamewar". To summarise, I think don't actually worry about how the developers spend their time. All you have to do is control what patches you take and release policy. Improve the system so it tolerates regressions and poor quality code (which are inevitable). Review bandwidth and regression fix rate should just naturally throttle new features / code going in. And you encourage people to do good things rather than hit them when inevitable bad things happen. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 16:56 ` Nick Piggin @ 2007-11-14 19:54 ` Linus Torvalds 2007-11-14 22:22 ` Heikki Orsila 0 siblings, 1 reply; 268+ messages in thread From: Linus Torvalds @ 2007-11-14 19:54 UTC (permalink / raw) To: Nick Piggin; +Cc: Andrew Morton, Christian Kujau, linux-kernel On Wed, 14 Nov 2007, Nick Piggin wrote: > > Not if you said their regression causing patches will get reverted unless it > can be fixed for release. Actually, I'm pretty happy reverting patches that cause regressions even if it *can* be "fixed for release". If there isn't a fix available within a day or two, it should get reverted. The "fix" can then be re-applying the *fixed* patch - and at that point we should strive to require the person who re-submits the patch (with fixes) having to have an Ack from the person who found the problem in the first place, so that it's verified to actually fix things! So I really would encourage people to send me emails like Please revert commit xyz, because it breaks abc, and there is no fix available even though this was reported x days ago. I have verified that revert just that change fixes the issue. and just make the "because it breaks abc" be specific and clear enough that I go "Ahh, ok, I'd better revert it". Also, please notice the latter part of the suggestion above: even if somebody has bisected down their problem to a specific commit, I really *do* want to hear that actually undoing the commit on top of the current tree acually fixes it again, because sometimes that just isn't the case - sometimes you end up having various interactions that means that reverting a commit might simply not even work. I have no trouble at all with reverting commits in general. I think regressions are serious. So the problematic cases are the cases where: - the commit no longer reverts cleanly, or just otherwise introduces other infrastructure that other commits that already got merged depend on. So sometimes you actually need a patch along with the revert (Andrew does that kind of thing anyway, since he works with patches regardless, so the "needs a patch" case is obviously not limited to just the problem cases) - more commonly: it's not entirely clear which commit actually caused the problem. but I *do* want to encourage people to revert (and ask other people to revert) much more aggressively. I personally try to revert things that people report regressions to me about very actively, unless I know somebody already has or is working on a fix. Linus ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 19:54 ` Linus Torvalds @ 2007-11-14 22:22 ` Heikki Orsila 2007-11-14 23:05 ` Linus Torvalds 0 siblings, 1 reply; 268+ messages in thread From: Heikki Orsila @ 2007-11-14 22:22 UTC (permalink / raw) To: Linus Torvalds; +Cc: Nick Piggin, Andrew Morton, Christian Kujau, linux-kernel On Wed, Nov 14, 2007 at 11:54:16AM -0800, Linus Torvalds wrote: > Actually, I'm pretty happy reverting patches that cause regressions even > if it *can* be "fixed for release". If there isn't a fix available within > a day or two, it should get reverted. > ... > Also, please notice the latter part of the suggestion above: even if > somebody has bisected down their problem to a specific commit, I really > *do* want to hear that actually undoing the commit on top of the current > tree acually fixes it again, because sometimes that just isn't the case - > sometimes you end up having various interactions that means that reverting > a commit might simply not even work. Ok. drivers/net/skge has been broken for several weeks. I have manually fixed the driver at each rc* release since then. Please revert skge changes, the commit that broke driver is 7fb7ac241162dc51ec0f7644d4a97b2855213c32 See http://bugzilla.kernel.org/show_bug.cgi?id=9321 for more information. I think Stephen Hemminger is working on the skge fix, but it has been several days since I've heard anything from him. -- Heikki Orsila Barbie's law: heikki.orsila@iki.fi "Math is hard, let's go shopping!" http://www.iki.fi/shd ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 22:22 ` Heikki Orsila @ 2007-11-14 23:05 ` Linus Torvalds 0 siblings, 0 replies; 268+ messages in thread From: Linus Torvalds @ 2007-11-14 23:05 UTC (permalink / raw) To: Heikki Orsila, Stephen Hemminger Cc: Nick Piggin, Andrew Morton, Christian Kujau, Linux Kernel Mailing List On Thu, 15 Nov 2007, Heikki Orsila wrote: > > See > http://bugzilla.kernel.org/show_bug.cgi?id=9321 > > for more information. That's a pretty unhelpful thing. It doesn't describe the breakage at all, so there is hardly much "more info". You've also apparently made all the attachements "octet-streams", so they are singularly painful to look at (ie no normal web-browser will show them, you have to save them to a file and look at them there). That said, I think I'll revert it, since it certainly fits the bill, but that's a really quite unreadable bug-report. I finally found the actual description of the problem (by following multiple links), but really, if people want me to revert things, I would *strongly* suggest they make it *obvious* what's going on in the email to me that says "please revert". Because quite frankly, if that email doesn't explain why something should be reverted (and just points to other things), it doesn't really cut it. Linus ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 21:04 ` Andrew Morton 2007-11-13 16:56 ` Nick Piggin @ 2007-11-13 21:37 ` Adrian Bunk 2007-11-13 21:56 ` Christian Kujau 2 siblings, 0 replies; 268+ messages in thread From: Adrian Bunk @ 2007-11-13 21:37 UTC (permalink / raw) To: Andrew Morton; +Cc: Christian Kujau, linux-kernel, torvalds On Tue, Nov 13, 2007 at 01:04:11PM -0800, Andrew Morton wrote: >... > Here's an important point: developers have a fixed amount of development > time. They spend some of that time fixing bugs and the rest of that time > on <otherstuff>. And while one could cook up all sorts of wonderful > process changes, they all would be aimed at a single thing: shifting some > of the developers' time away from <otherstuff> and onto bugfixing. >... There is another possible solution: Finding more maintainers. The problem seems to be that there are many people who want to write drivers for cool shiny new hardware, but not many people willing to learn to know and maintain existing code. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 21:04 ` Andrew Morton 2007-11-13 16:56 ` Nick Piggin 2007-11-13 21:37 ` Adrian Bunk @ 2007-11-13 21:56 ` Christian Kujau 2007-11-15 4:07 ` Bron Gondwana 2 siblings, 1 reply; 268+ messages in thread From: Christian Kujau @ 2007-11-13 21:56 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, torvalds On Tue, 13 Nov 2007, Andrew Morton wrote: > There are a number of process things we _could_ do. Like > - have bugfix-only kernel releases Adrian Bunk does (did?) this with 2.6.16.x, although it always seemed to me like an unrewarded one man show. AFAIK not even the big distros are begging for bugfix-only versions, as they too want to have (sell) new features. Mission critical systems might want to require such versions, but I guess they're using heavily customized trees anyway. > - Just refuse to merge any non-bugfix patches for a subsystem when it is > determined that the subsystem has "too many" regressions. Hm, that's what I had in mind. Has this been tried already? > - Create an "if you added a regression, you should fix some other bug > too" rule. Naah, I'm not really in favour of blaming someone. The kernel doesn't have SLA contracts (yet), so no need for giving out penalties :) > But we can't/shouldn't do any of that until it is generally agreed that we > have a problem and that the problem is of sufficient magnitude that process > changes are needed to address it. We aren't at that stage yet. Keeping track of the (number of) regressions / bugs each release seems to be a good start, IMHO. > process changes, they all would be aimed at a single thing: shifting some > of the developers' time away from <otherstuff> and onto bugfixing. True. Implementing "only bugfixes from now on" (i.e. a longer freeze-window) would perhaps speed up the shifting a bit: $developer can still do $otherstuff all day long, but it won't get merged anyway, because we're in "only bugfixes from now on"-mode. > At this stage the only tool which is being deployed to attempt to bring > about that reprioritisation is suasion. aka "lkml flamewar". True. But I just noticed that I have to distinguish between "flamewars" and "fierce discussions": if I'd imagine a room with ~50 developers/bystanders brainstorming on a issue like this (at the same time, without the wonderful delay of writing/sending an email), it'd feel much more uncomfortable. Christian. -- BOFH excuse #433: error: one bad user found in front of screen ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 21:56 ` Christian Kujau @ 2007-11-15 4:07 ` Bron Gondwana 2007-11-15 4:24 ` Linus Torvalds 0 siblings, 1 reply; 268+ messages in thread From: Bron Gondwana @ 2007-11-15 4:07 UTC (permalink / raw) To: Christian Kujau; +Cc: Andrew Morton, linux-kernel, torvalds On Tue, Nov 13, 2007 at 10:56:01PM +0100, Christian Kujau wrote: > On Tue, 13 Nov 2007, Andrew Morton wrote: >> There are a number of process things we _could_ do. Like >> - have bugfix-only kernel releases > > Adrian Bunk does (did?) this with 2.6.16.x, although it always seemed to me > like an unrewarded one man show. AFAIK not even the big distros are begging > for bugfix-only versions, as they too want to have (sell) new features. > Mission critical systems might want to require such versions, but I guess > they're using heavily customized trees anyway. And congratulations to him for that. We almost entirely dropped 2.6.16, but there's a regression some time since then that makes large MMAPed files a major pain (specifically the dcc database clean takes about 5 minutes on 2.6.16 and about 12 hours on 2.6.20 or 2.6.23 series kernels) But we keep putting off writing a small testcase that can repeat the issue so we can bisect it - because it's working fine with 2.6.16 on that machine. Bron. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-15 4:07 ` Bron Gondwana @ 2007-11-15 4:24 ` Linus Torvalds 2007-11-15 5:25 ` Bron Gondwana 0 siblings, 1 reply; 268+ messages in thread From: Linus Torvalds @ 2007-11-15 4:24 UTC (permalink / raw) To: Bron Gondwana; +Cc: Christian Kujau, Andrew Morton, linux-kernel On Thu, 15 Nov 2007, Bron Gondwana wrote: > > And congratulations to him for that. We almost entirely dropped 2.6.16, > but there's a regression some time since then that makes large MMAPed > files a major pain (specifically the dcc database clean takes about 5 > minutes on 2.6.16 and about 12 hours on 2.6.20 or 2.6.23 series kernels) > > But we keep putting off writing a small testcase that can repeat the > issue so we can bisect it - because it's working fine with 2.6.16 on > that machine. Heh. I suspect you don't even need to bisect it. The big difference with large mmap'ed files is that later kernels will actually track dirty ratios for dirty mmap'ed pages. Earlier kernels never did. So in older kernels, you can dirty as much memory as you want, and the kernel will never try to write it back (well - "never" here means one of either (a) you ask it to with msync or (b) you run out of memory, when the kernel then totally falls down and the machine is essentially unusuable). So *if* the symptom seems to be that the later kernels do a lot more IO, then try to change /proc/sys/vm/dirty_[background_]ratio which is just a percentage of memory (defaults to 5% for background and 10% for foreground dirtying). Turn them both up a lot (say to 50 and 80 percent respectively) and see if that makes a difference. If so, you'll be the first one to officially even notice this change, I think. Linus ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-15 4:24 ` Linus Torvalds @ 2007-11-15 5:25 ` Bron Gondwana 2007-11-15 5:35 ` Linus Torvalds 0 siblings, 1 reply; 268+ messages in thread From: Bron Gondwana @ 2007-11-15 5:25 UTC (permalink / raw) To: Linus Torvalds Cc: Bron Gondwana, Christian Kujau, Andrew Morton, linux-kernel On Wed, Nov 14, 2007 at 08:24:53PM -0800, Linus Torvalds wrote: > > > On Thu, 15 Nov 2007, Bron Gondwana wrote: > > > > And congratulations to him for that. We almost entirely dropped 2.6.16, > > but there's a regression some time since then that makes large MMAPed > > files a major pain (specifically the dcc database clean takes about 5 > > minutes on 2.6.16 and about 12 hours on 2.6.20 or 2.6.23 series kernels) > > > > But we keep putting off writing a small testcase that can repeat the > > issue so we can bisect it - because it's working fine with 2.6.16 on > > that machine. > > Heh. I suspect you don't even need to bisect it. > > The big difference with large mmap'ed files is that later kernels will > actually track dirty ratios for dirty mmap'ed pages. Earlier kernels never > did. > > So in older kernels, you can dirty as much memory as you want, and the > kernel will never try to write it back (well - "never" here means one of > either (a) you ask it to with msync or (b) you run out of memory, when the > kernel then totally falls down and the machine is essentially unusuable). > > So *if* the symptom seems to be that the later kernels do a lot more IO, > then try to change > > /proc/sys/vm/dirty_[background_]ratio > > which is just a percentage of memory (defaults to 5% for background and > 10% for foreground dirtying). Turn them both up a lot (say to 50 and 80 > percent respectively) and see if that makes a difference. >From our sysctl.conf: # This should help reduce flushing on Cache::FastMmap files vm.dirty_background_ratio = 50 vm.dirty_expire_centisecs = 9000 vm.dirty_ratio = 80 vm.dirty_writeback_centisecs = 3000 So we've already been running those settings for a while. They didn't help. We also gave this thing its very own dedicated ServeRAID card and associated RAID1 set of high speed SCSI drives (mainly because they were just sitting there already attached to the machine and unused, we don't love DCC that much) and it didn't help. Helped the rest of the machine now that the system drive wasn't being pegged 100% for 12 hours a day, but it didn't speed things up any. It was making some pretty random little scattered changes all through that file. Hmm.. here's what the developers said about it: First dbclean creates a new dcc_db file by copying from the old file. As it copies, it decides whether each record is worth keeping. That involves looking up the checksums in the old hash table. This is as almost afast a simple /bin/cp if the old dcc_db and dcc_db.hash files fit in RAM. The dbclean creates a new dcc_db.hash file. This starts with creating an empty new dcc_db.hash file. Then the new dcc_db and dcc_db.hash files are mapped into memory, and dbclean creates pointers to each checksum in the dcc_db file in the dcc_db.hash file. While dbclean is running, dccd unmaps everything and tries to stay out of the way. > If so, you'll be the first one to officially even notice this change, I > think. Yay for us. Thankfully it doesn't affect Cyrus's MMAP usage (read only with direct seek and write calls to change anything, then remap) or we would have suffered pretty badly! Guess we'd better get on to figuring building a simple test app. The mmap file that DCC uses is about 2Gb if that makes any difference: -rw-r--r-- 1 dcc dcc 2035138560 Nov 15 00:15 dcc_db -rw-r--r-- 1 dcc dcc 516612096 Nov 14 06:27 dcc_db.hash The machine has 6Gb of memory and should be able to fit these files fine: [root@out1 hm]$ free total used free shared buffers cached Mem: 6232364 5758112 474252 0 41756 3002528 -/+ buffers/cache: 2713828 3518536 Swap: 2048248 74944 1973304 And here's what top says about the process: 15 0 1914m 57m 41m D 5 1.0 346:07.79 dccd This is on: 2.6.16.55-reiserfix-fai (one small patch to reiserfs, and built with netboot support for FAI) So yeah - we'll try to get a clearer idea of what it's doing, but the knob twiddle didn't work for us. Bron. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-15 5:25 ` Bron Gondwana @ 2007-11-15 5:35 ` Linus Torvalds 2007-11-15 5:53 ` Linus Torvalds 0 siblings, 1 reply; 268+ messages in thread From: Linus Torvalds @ 2007-11-15 5:35 UTC (permalink / raw) To: Bron Gondwana; +Cc: Christian Kujau, Andrew Morton, linux-kernel On Thu, 15 Nov 2007, Bron Gondwana wrote: > > So we've already been running those settings for a while. They didn't > help. Ok, so something else is up. If the mmap file is 2G, and you have 6G of RAM, you shouldn't be hitting the dirty limits with those setups. Of course, it may still be that some accounting thing is simply off, and the dirty limits trigger *despite* all the proper config settings ;) > Guess we'd better get on to figuring building a simple test app. Yeah, if you have something that others can see in action, that is sure going to get more people to look at it. That said - I'm sincerely hoping that you're not running on a 32-bit kernel. Because if so, those percentages are percentages of *normal* memory, not highmem (that got changed at one point after people ran out of lowmem). So even at 100% dirty limits, it won't let you dirty more than 1GB on the default 32-bit setup. Linus ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-15 5:35 ` Linus Torvalds @ 2007-11-15 5:53 ` Linus Torvalds 2007-11-15 11:50 ` mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) Bron Gondwana 0 siblings, 1 reply; 268+ messages in thread From: Linus Torvalds @ 2007-11-15 5:53 UTC (permalink / raw) To: Bron Gondwana; +Cc: Christian Kujau, Andrew Morton, linux-kernel On Wed, 14 Nov 2007, Linus Torvalds wrote: > > So even at 100% dirty limits, it won't let you dirty more than 1GB on the > default 32-bit setup. Side note: all of these are obviously still just heuristics. If you really *do* run on a 32-bit kernel, and you want to have the pain, I'm sure you can just disable the dirty limits with a one-liner kernel mod. And if it's useful enough, we can certainly expose flags like that.. Not that I expect that much anybody else will ever care, but it's not like it's wrong to expose the silly heuristics the kernel has to users that have very specific loads. That said, I still do hope you aren't actually using HIGHMEM64G. I was really hoping that the people who had enough moolah to buy >4GB of RAM had long since also upgraded to a 64-bit machine ;) Linus ^ permalink raw reply [flat|nested] 268+ messages in thread
* mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) 2007-11-15 5:53 ` Linus Torvalds @ 2007-11-15 11:50 ` Bron Gondwana 2007-11-15 16:32 ` Linus Torvalds 0 siblings, 1 reply; 268+ messages in thread From: Bron Gondwana @ 2007-11-15 11:50 UTC (permalink / raw) To: Linus Torvalds Cc: Bron Gondwana, Christian Kujau, Andrew Morton, linux-kernel, robm On Wed, Nov 14, 2007 at 09:53:38PM -0800, Linus Torvalds wrote: > > > On Wed, 14 Nov 2007, Linus Torvalds wrote: > > > > So even at 100% dirty limits, it won't let you dirty more than 1GB on the > > default 32-bit setup. > > Side note: all of these are obviously still just heuristics. If you really > *do* run on a 32-bit kernel, and you want to have the pain, I'm sure you > can just disable the dirty limits with a one-liner kernel mod. And if it's > useful enough, we can certainly expose flags like that.. Not that I expect > that much anybody else will ever care, but it's not like it's wrong to > expose the silly heuristics the kernel has to users that have very > specific loads. > > That said, I still do hope you aren't actually using HIGHMEM64G. I was > really hoping that the people who had enough moolah to buy >4GB of RAM had > long since also upgraded to a 64-bit machine ;) I'm afraid we are, which probably explains it. We have a bunch of 64 bit machines, but this particular machine is one of our somewhat more ancient IBM x235 machines. It's got stacks of fast SCSI drives and a couple of hyperthreading Xeons in it. Very nice machine in its day, and very reliable which is why we have kept them, even though at 6RU it chews through disk space. Unfortunately none of the 64 bit machines are world facing, and we're running HIGHMEM64G on a bunch of machines both for consistency value and because we only have one machine left with only 2Gb. I guess we'll be doing the one-liner kernel mod and testing that then. I'd certainly like to build a test case anyway so I'm not spending too much time rebooting that machine, it's also our outbound SMTP gateway. And I'll keep in mind finding a 64 bit capable machine for the role when I can. Thanks for the feedback on this - I'll come back with more details once we've done some testing, but this sounds likely, and I don't think DCC is going to change how it works, so we're stuck supporting it. Bron. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) 2007-11-15 11:50 ` mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) Bron Gondwana @ 2007-11-15 16:32 ` Linus Torvalds 2007-11-15 19:40 ` Peter Zijlstra 2007-11-21 23:51 ` mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) Bron Gondwana 0 siblings, 2 replies; 268+ messages in thread From: Linus Torvalds @ 2007-11-15 16:32 UTC (permalink / raw) To: Bron Gondwana Cc: Christian Kujau, Andrew Morton, Peter Zijlstra, Linux Kernel Mailing List, robm On Thu, 15 Nov 2007, Bron Gondwana wrote: > > I guess we'll be doing the one-liner kernel mod and testing > that then. The thing to look at is "get_dirty_limits()" in mm/page-writeback.c, and in this particular case it's the unsigned long available_memory = determine_dirtyable_memory(); that's going to bite you. In particular, note the x -= highmem_dirtyable_memory(x); that we do in determine_dirtyable_memory(). So in this case, if you basically remove that line, it will allow all of memory to be dirtied (including highmem), and then the background_ratio will work on the whole 6GB. HOWEVER! It's worth noting that we also have some other old legacy cruft there that may interfere with your code. In particular, if you look at the top of "get_dirty_limits()", it *also* does a unmapped_ratio = 100 - ((global_page_state(NR_FILE_MAPPED) + global_page_state(NR_ANON_PAGES)) * 100) / available_memory; dirty_ratio = vm_dirty_ratio; if (dirty_ratio > unmapped_ratio / 2) dirty_ratio = unmapped_ratio / 2; and that whole "unmapped_ratio" comparison is probably bogus these days, since we now take the mapped dirty pages into account. That code harks back to the days before we did that, and dirty ratios only affected non-mapped pages. And in particular, now that I look at it, I wonder if it can even go negative (because "available_memory" may be *smaller* than the NR_FILE_MAPPED|ANON_PAGES sum!). We'll fix up a negative value anyway (because of the clamping of dirty_ratio to no less than 5), but the point is that the whole "unmapped_ratio" thing probably doesn't make sense any more, and may well make the dirty_ratio not work for you, because you may have a very small unmapped_ratio that effectively makes all dirty limits always clamp to a very small value. So regardless, I think you may want to try the appended patch *first*. If this patch makes a difference, please holler. I think it's the correct thing to do, but I'm not going to actually commit it without somebody saying that it makes a difference (and preferably Peter Zijlstra and Andrew acking it too). Only *after* testing this change is it probably a good idea to test the real hack of then removing the highmem_dirtyable_memory() thing. Peter? Andrew? Linus --- mm/page-writeback.c | 8 -------- 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/mm/page-writeback.c b/mm/page-writeback.c index 81a91e6..d55cfca 100644 --- a/mm/page-writeback.c +++ b/mm/page-writeback.c @@ -297,20 +297,12 @@ get_dirty_limits(long *pbackground, long *pdirty, long *pbdi_dirty, { int background_ratio; /* Percentages */ int dirty_ratio; - int unmapped_ratio; long background; long dirty; unsigned long available_memory = determine_dirtyable_memory(); struct task_struct *tsk; - unmapped_ratio = 100 - ((global_page_state(NR_FILE_MAPPED) + - global_page_state(NR_ANON_PAGES)) * 100) / - available_memory; - dirty_ratio = vm_dirty_ratio; - if (dirty_ratio > unmapped_ratio / 2) - dirty_ratio = unmapped_ratio / 2; - if (dirty_ratio < 5) dirty_ratio = 5; ^ permalink raw reply related [flat|nested] 268+ messages in thread
* Re: mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) 2007-11-15 16:32 ` Linus Torvalds @ 2007-11-15 19:40 ` Peter Zijlstra 2007-11-15 20:44 ` Peter Zijlstra 2007-11-21 23:51 ` mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) Bron Gondwana 1 sibling, 1 reply; 268+ messages in thread From: Peter Zijlstra @ 2007-11-15 19:40 UTC (permalink / raw) To: Linus Torvalds Cc: Bron Gondwana, Christian Kujau, Andrew Morton, Linux Kernel Mailing List, robm On Thu, 2007-11-15 at 08:32 -0800, Linus Torvalds wrote: > > On Thu, 15 Nov 2007, Bron Gondwana wrote: > > > > I guess we'll be doing the one-liner kernel mod and testing > > that then. > > The thing to look at is "get_dirty_limits()" in mm/page-writeback.c, and > in this particular case it's the > > unsigned long available_memory = determine_dirtyable_memory(); > > that's going to bite you. In particular, note the > > x -= highmem_dirtyable_memory(x); > > that we do in determine_dirtyable_memory(). > > So in this case, if you basically remove that line, it will allow all of > memory to be dirtied (including highmem), and then the background_ratio > will work on the whole 6GB. > > HOWEVER! It's worth noting that we also have some other old legacy cruft > there that may interfere with your code. In particular, if you look at the > top of "get_dirty_limits()", it *also* does a > > unmapped_ratio = 100 - ((global_page_state(NR_FILE_MAPPED) + > global_page_state(NR_ANON_PAGES)) * 100) / > available_memory; > > dirty_ratio = vm_dirty_ratio; > if (dirty_ratio > unmapped_ratio / 2) > dirty_ratio = unmapped_ratio / 2; > > and that whole "unmapped_ratio" comparison is probably bogus these days, > since we now take the mapped dirty pages into account. That code harks > back to the days before we did that, and dirty ratios only affected > non-mapped pages. > > And in particular, now that I look at it, I wonder if it can even go > negative (because "available_memory" may be *smaller* than the > NR_FILE_MAPPED|ANON_PAGES sum!). > > We'll fix up a negative value anyway (because of the clamping of > dirty_ratio to no less than 5), but the point is that the whole > "unmapped_ratio" thing probably doesn't make sense any more, and may well > make the dirty_ratio not work for you, because you may have a very small > unmapped_ratio that effectively makes all dirty limits always clamp to a > very small value. > > So regardless, I think you may want to try the appended patch *first*. > > If this patch makes a difference, please holler. I think it's the correct > thing to do, but I'm not going to actually commit it without somebody > saying that it makes a difference (and preferably Peter Zijlstra and > Andrew acking it too). > > Only *after* testing this change is it probably a good idea to test the > real hack of then removing the highmem_dirtyable_memory() thing. > > Peter? Andrew? I wondered about that part the other day when I went through the BDI dirty code due to that iozone thing.. The initial commit states: commit d90e4590519d196004efbb308d0d47596ee4befe Author: akpm <akpm> Date: Sun Oct 13 16:33:20 2002 +0000 [PATCH] reduce the dirty threshold when there's a lot of mapped Dirty memory thresholds are currently set by /proc/sys/vm/dirty_ratio. Background writeout levels are controlled by /proc/sys/vm/dirty_background_ratio. Problem is that these levels are hard to get right - they are too static. If there is a lot of mapped memory around then the 40% clamping level causes too much dirty data. We do lots of scanning in page reclaim, and the VM generally starts getting into distress. Extra swapping, extra page unmapping. It would be much better to simply tell the caller of write(2) to slow down - to write out their dirty data sooner, to make those written pages trivially reclaimable. Penalise the offender, not the innocent page allocators. This patch changes the writer throttling code so that we clamp down much harder on writers if there is a lot of mapped memory in the machine. We only permit memory dirtiers to dirty up to 50% of unmapped memory before forcing them to clean their own pagecache. BKrev: 3da9a050Mz7H6VkAR9xo6ongavTMrw But because dirty mapped pages are no longer special, I'd say the reason for its existance is gone. So, Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl> As for the highmem part, that was due to buffer cache, and unfortunately that is still true. Although maybe we can do something smart with the per-bdi stuff. > --- > mm/page-writeback.c | 8 -------- > 1 files changed, 0 insertions(+), 8 deletions(-) > > diff --git a/mm/page-writeback.c b/mm/page-writeback.c > index 81a91e6..d55cfca 100644 > --- a/mm/page-writeback.c > +++ b/mm/page-writeback.c > @@ -297,20 +297,12 @@ get_dirty_limits(long *pbackground, long *pdirty, long *pbdi_dirty, > { > int background_ratio; /* Percentages */ > int dirty_ratio; > - int unmapped_ratio; > long background; > long dirty; > unsigned long available_memory = determine_dirtyable_memory(); > struct task_struct *tsk; > > - unmapped_ratio = 100 - ((global_page_state(NR_FILE_MAPPED) + > - global_page_state(NR_ANON_PAGES)) * 100) / > - available_memory; > - > dirty_ratio = vm_dirty_ratio; > - if (dirty_ratio > unmapped_ratio / 2) > - dirty_ratio = unmapped_ratio / 2; > - > if (dirty_ratio < 5) > dirty_ratio = 5; > ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) 2007-11-15 19:40 ` Peter Zijlstra @ 2007-11-15 20:44 ` Peter Zijlstra 2007-11-15 20:56 ` Linus Torvalds 0 siblings, 1 reply; 268+ messages in thread From: Peter Zijlstra @ 2007-11-15 20:44 UTC (permalink / raw) To: Linus Torvalds Cc: Bron Gondwana, Christian Kujau, Andrew Morton, Linux Kernel Mailing List, robm On Thu, 2007-11-15 at 20:40 +0100, Peter Zijlstra wrote: > As for the highmem part, that was due to buffer cache, and unfortunately > that is still true. Although maybe we can do something smart with the > per-bdi stuff. Something like this ought to do I guess. Although my mapping_is_buffercache() is the ugliest thing. I'm sure that can be done better. Uncompiled, untested Not-Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> --- mm/page-writeback.c | 28 ++++++++++++++++++++-------- 1 file changed, 20 insertions(+), 8 deletions(-) Index: linux-2.6/mm/page-writeback.c =================================================================== --- linux-2.6.orig/mm/page-writeback.c +++ linux-2.6/mm/page-writeback.c @@ -280,27 +280,28 @@ static unsigned long highmem_dirtyable_m #endif } -static unsigned long determine_dirtyable_memory(void) +static unsigned long determine_dirtyable_memory(int highmem) { unsigned long x; x = global_page_state(NR_FREE_PAGES) + global_page_state(NR_INACTIVE) + global_page_state(NR_ACTIVE); - x -= highmem_dirtyable_memory(x); + if (!highmem) + x -= highmem_dirtyable_memory(x); return x + 1; /* Ensure that we never return 0 */ } static void get_dirty_limits(long *pbackground, long *pdirty, long *pbdi_dirty, - struct backing_dev_info *bdi) + struct backing_dev_info *bdi, int highmem) { int background_ratio; /* Percentages */ int dirty_ratio; int unmapped_ratio; long background; long dirty; - unsigned long available_memory = determine_dirtyable_memory(); + unsigned long available_memory = determine_dirtyable_memory(highmem); struct task_struct *tsk; unmapped_ratio = 100 - ((global_page_state(NR_FILE_MAPPED) + @@ -346,6 +347,16 @@ get_dirty_limits(long *pbackground, long } } +static inline int mapping_is_buffercache(struct address_space *mapping) +{ + struct super_block *sb = mapping->host->i_sb; + + if (sb && sb->s_bdev && sb->s_bdev->bd_inode->i_mapping != mapping) + return 0; + + return 1; +} + /* * balance_dirty_pages() must be called by processes which are generating dirty * data. It looks at the number of dirty pages in the machine and will force @@ -364,6 +375,7 @@ static void balance_dirty_pages(struct a unsigned long write_chunk = sync_writeback_pages(); struct backing_dev_info *bdi = mapping->backing_dev_info; + int highmem = !mapping_is_buffercache(mapping); for (;;) { struct writeback_control wbc = { @@ -375,7 +387,7 @@ static void balance_dirty_pages(struct a }; get_dirty_limits(&background_thresh, &dirty_thresh, - &bdi_thresh, bdi); + &bdi_thresh, bdi, highmem); bdi_nr_reclaimable = bdi_stat(bdi, BDI_RECLAIMABLE); bdi_nr_writeback = bdi_stat(bdi, BDI_WRITEBACK); if (bdi_nr_reclaimable + bdi_nr_writeback <= bdi_thresh) @@ -394,7 +406,7 @@ static void balance_dirty_pages(struct a writeback_inodes(&wbc); pages_written += write_chunk - wbc.nr_to_write; get_dirty_limits(&background_thresh, &dirty_thresh, - &bdi_thresh, bdi); + &bdi_thresh, bdi, highmem); } /* @@ -503,7 +515,7 @@ void throttle_vm_writeout(gfp_t gfp_mask long dirty_thresh; for ( ; ; ) { - get_dirty_limits(&background_thresh, &dirty_thresh, NULL, NULL); + get_dirty_limits(&background_thresh, &dirty_thresh, NULL, NULL, 1); /* * Boost the allowable dirty threshold a bit for page @@ -546,7 +558,7 @@ static void background_writeout(unsigned long background_thresh; long dirty_thresh; - get_dirty_limits(&background_thresh, &dirty_thresh, NULL, NULL); + get_dirty_limits(&background_thresh, &dirty_thresh, NULL, NULL, 1); if (global_page_state(NR_FILE_DIRTY) + global_page_state(NR_UNSTABLE_NFS) < background_thresh && min_pages <= 0) ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) 2007-11-15 20:44 ` Peter Zijlstra @ 2007-11-15 20:56 ` Linus Torvalds 2007-11-15 20:59 ` Peter Zijlstra 2007-11-15 21:14 ` Linus Torvalds 0 siblings, 2 replies; 268+ messages in thread From: Linus Torvalds @ 2007-11-15 20:56 UTC (permalink / raw) To: Peter Zijlstra Cc: Bron Gondwana, Christian Kujau, Andrew Morton, Linux Kernel Mailing List, robm On Thu, 15 Nov 2007, Peter Zijlstra wrote: > > Something like this ought to do I guess. Although my > mapping_is_buffercache() is the ugliest thing. I'm sure that can be done > better. No, this absolutely sucks. Why? It's totally unacceptable to have per-mapping notions of how much memory we have. We used to do *exactly* that, and it's idiocy. The reason it's unacceptable idiocy is that it means that two processes that access different files will then have *TOTALLY*DIFFERENT* notions of what the "dirty limit" is. And as a result, one process will happily write lots and lots of dirty stuff and never throttle, and the other process will have to throttle all the time - and clean up after the process that didn't! See? The fact is, because we count dirty pages as one resource, we must also have *one* limit. So this patch is a huge regression. You might not notice it, because if everybody writes to the same kind of mapping, nobody will be hurt (they all have effectively the same global limit anyway), but you *will* notice if you ever have two different values of "highmem". Unacceptable. We used to do exactly what your patch does, and it got fixed once. We're not introducing that fundamentally broken concept again. Linus ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) 2007-11-15 20:56 ` Linus Torvalds @ 2007-11-15 20:59 ` Peter Zijlstra 2007-11-15 21:12 ` Peter Zijlstra 2007-11-15 21:14 ` Linus Torvalds 1 sibling, 1 reply; 268+ messages in thread From: Peter Zijlstra @ 2007-11-15 20:59 UTC (permalink / raw) To: Linus Torvalds Cc: Bron Gondwana, Christian Kujau, Andrew Morton, Linux Kernel Mailing List, robm On Thu, 2007-11-15 at 12:56 -0800, Linus Torvalds wrote: > > On Thu, 15 Nov 2007, Peter Zijlstra wrote: > > > > Something like this ought to do I guess. Although my > > mapping_is_buffercache() is the ugliest thing. I'm sure that can be done > > better. > > No, this absolutely sucks. Agreed, I was just about to send out an email saying that.. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) 2007-11-15 20:59 ` Peter Zijlstra @ 2007-11-15 21:12 ` Peter Zijlstra 0 siblings, 0 replies; 268+ messages in thread From: Peter Zijlstra @ 2007-11-15 21:12 UTC (permalink / raw) To: Linus Torvalds Cc: Bron Gondwana, Christian Kujau, Andrew Morton, Linux Kernel Mailing List, robm On Thu, 2007-11-15 at 21:59 +0100, Peter Zijlstra wrote: > On Thu, 2007-11-15 at 12:56 -0800, Linus Torvalds wrote: > > > > On Thu, 15 Nov 2007, Peter Zijlstra wrote: > > > > > > Something like this ought to do I guess. Although my > > > mapping_is_buffercache() is the ugliest thing. I'm sure that can be done > > > better. > > > > No, this absolutely sucks. > > Agreed, I was just about to send out an email saying that. Say all buffer cache users were against default_backing_dev_info, and we'd give default_backing_dev_info less, that should work out, right? ( I'm not yet clear on if buffer cache already uses default_backing_dev_info or not, bdget() seems to suggest it does ) ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) 2007-11-15 20:56 ` Linus Torvalds 2007-11-15 20:59 ` Peter Zijlstra @ 2007-11-15 21:14 ` Linus Torvalds 2007-11-15 21:26 ` Linus Torvalds ` (3 more replies) 1 sibling, 4 replies; 268+ messages in thread From: Linus Torvalds @ 2007-11-15 21:14 UTC (permalink / raw) To: Peter Zijlstra Cc: Bron Gondwana, Christian Kujau, Andrew Morton, Linux Kernel Mailing List, robm On Thu, 15 Nov 2007, Linus Torvalds wrote: > > Unacceptable. We used to do exactly what your patch does, and it got fixed > once. We're not introducing that fundamentally broken concept again. Examples of non-broken solutions: (a) always use lowmem sizes (what we do now) (b) always use total mem sizes (sane but potentially dangerous: but the VM pressure should work! It has serious bounce-buffer issues, though, which is why I think it's crazy even if it's otherwise consistent) (c) make all dirty counting be *purely* per-bdi, so that everybody can disagree on what the limits are, but at least they also then use different counters So it's just the "different writers look at the same dirty counts but then interpret it to mean totally different things" that I think is so fundamentally bogus. I'm not claiming that what we do now is the only way to do things, I just don't think your approach is tenable. Btw, I actually suspect that while (a) is what we do now, for the specific case that Bron has, we could have a /proc/sys/vm option to just enable (b). So we don't have to have just one consistent model, we can allow odd users (and Bron sounds like one - sorry Bron ;) to just force other, odd, but consistent models. I'd also like to point out that while the "bounce buffer" issue is not so much a HIGHMEM issue on its own (it's really about the device DMA limits, which are _independent_ of HIGHMEM, of course), the reason HIGHMEM is special is that without HIGHMEM the bounce buffers generally work perfectly fine. The problem with HIGHMEM is that it causes various metadata (dentries, inodes, page struct tables etc) to eat up memory "prime real estate" under the same kind of conditions that also dirty a lot of memory. So the reason we disallow HIGHMEM from dirty limits is only *partly* the per-device or mapping DMA limits, and to a large degree the fact that non-highmem memory is special in general, and it is usually the non-highmem areas that are constrained - and need to be protected. Linus ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) 2007-11-15 21:14 ` Linus Torvalds @ 2007-11-15 21:26 ` Linus Torvalds 2007-11-15 21:26 ` Peter Zijlstra ` (2 subsequent siblings) 3 siblings, 0 replies; 268+ messages in thread From: Linus Torvalds @ 2007-11-15 21:26 UTC (permalink / raw) To: Peter Zijlstra Cc: Bron Gondwana, Christian Kujau, Andrew Morton, Linux Kernel Mailing List, robm On Thu, 15 Nov 2007, Linus Torvalds wrote: > > The problem with HIGHMEM is that it causes various metadata (dentries, > inodes, page struct tables etc) to eat up memory "prime real estate" under > the same kind of conditions that also dirty a lot of memory. So the reason > we disallow HIGHMEM from dirty limits is only *partly* the per-device or > mapping DMA limits, and to a large degree the fact that non-highmem memory > is special in general, and it is usually the non-highmem areas that are > constrained - and need to be protected. Final note on this (promise): I'd really be very interested to hear if the patch I *do* think makes sense (ie the removal of the old "unmapped_ratio" logic) actually already solves most of Bron's problems. It may well be that that unmapped_ratio logic effectively undid the system configuration changes that Bron has done. It doesn't matter if Bron has >From our sysctl.conf: # This should help reduce flushing on Cache::FastMmap files vm.dirty_background_ratio = 50 vm.dirty_expire_centisecs = 9000 vm.dirty_ratio = 80 vm.dirty_writeback_centisecs = 3000 if it turns out that the "unmapped_ratio" logic turns the 80% back down to 5%. It may well be that 80% of the non-highmem memory is plenty good enough! Sure, older kernels allowed even more of memory to be dirty (since they didn't count dirty mappings at all), but we may have a case where the fact that we discount the HIGHMEM stuff isn't the major problem in itself, and that the dirty_ratio sysctl should be ok - but just gets screwed over by that unmapped_ratio logic. So Bron, if you can test that patch, I'd love to hear if it matters. It may not make any difference (maybe you don't actually trigger the unmapped_ratio logic at all), but I think it has the potential for being totally broken for you. People that don't change the dirty_ratio from the default values would generally never care, because the default dirty-ratio is *already* so low that even if the unmapped_ratio logic triggers, it won't much matter! Linus ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) 2007-11-15 21:14 ` Linus Torvalds 2007-11-15 21:26 ` Linus Torvalds @ 2007-11-15 21:26 ` Peter Zijlstra 2007-11-15 21:47 ` Linus Torvalds 2007-11-19 3:54 ` Bron Gondwana 2007-11-22 3:42 ` [PATCH 1/1] mm: add dirty_highmem option Bron Gondwana 3 siblings, 1 reply; 268+ messages in thread From: Peter Zijlstra @ 2007-11-15 21:26 UTC (permalink / raw) To: Linus Torvalds Cc: Bron Gondwana, Christian Kujau, Andrew Morton, Linux Kernel Mailing List, robm, riel, Anton Altaparmakov On Thu, 2007-11-15 at 13:14 -0800, Linus Torvalds wrote: > > On Thu, 15 Nov 2007, Linus Torvalds wrote: > > > > Unacceptable. We used to do exactly what your patch does, and it got fixed > > once. We're not introducing that fundamentally broken concept again. > > Examples of non-broken solutions: > (a) always use lowmem sizes (what we do now) > (b) always use total mem sizes (sane but potentially dangerous: but the > VM pressure should work! It has serious bounce-buffer issues, though, > which is why I think it's crazy even if it's otherwise consistent) > (c) make all dirty counting be *purely* per-bdi, so that everybody can > disagree on what the limits are, but at least they also then use > different counters I think that (c) is doable. If its worth the effort, who knows, apparently there still are people using 32bit kernels on boxen with mucho memory. > So it's just the "different writers look at the same dirty counts but then > interpret it to mean totally different things" that I think is so > fundamentally bogus. I'm not claiming that what we do now is the only way > to do things, I just don't think your approach is tenable. Agreed, the per mapping thing was utter crap. > I'd also like to point out that while the "bounce buffer" issue is not so > much a HIGHMEM issue on its own (it's really about the device DMA limits, > which are _independent_ of HIGHMEM, of course), the reason HIGHMEM is > special is that without HIGHMEM the bounce buffers generally work > perfectly fine. > > The problem with HIGHMEM is that it causes various metadata (dentries, > inodes, page struct tables etc) to eat up memory "prime real estate" under > the same kind of conditions that also dirty a lot of memory. So the reason > we disallow HIGHMEM from dirty limits is only *partly* the per-device or > mapping DMA limits, and to a large degree the fact that non-highmem memory > is special in general, and it is usually the non-highmem areas that are > constrained - and need to be protected. But this problem is already an issue, Anton recently had a case where a 12GB highmem box locked up due to NTFS running out of lowmem - or something like that. And I think that with the targeted slab reclaim (or slab defrag as its apparently still called) we can properly fix this side of the problem. I think Rik was looking into doing so. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) 2007-11-15 21:26 ` Peter Zijlstra @ 2007-11-15 21:47 ` Linus Torvalds 2007-11-15 22:11 ` Chris Friesen ` (3 more replies) 0 siblings, 4 replies; 268+ messages in thread From: Linus Torvalds @ 2007-11-15 21:47 UTC (permalink / raw) To: Peter Zijlstra Cc: Bron Gondwana, Christian Kujau, Andrew Morton, Linux Kernel Mailing List, robm, riel, Anton Altaparmakov On Thu, 15 Nov 2007, Peter Zijlstra wrote: > > But this problem is already an issue, Anton recently had a case where a > 12GB highmem box locked up due to NTFS running out of lowmem - or > something like that. Yeah. I always considered HIGHMEM to just be unusable. It's ok for extending to 2-4GB (ie HIGHMEM4G, not 64G), and it's probably borderline usable for 4-8G if you are careful. But quite frankly, I refuse to even care about anything past that. If you have 12G (or heaven forbid, even more) in your machine, and you can't be bothered to just upgrade to a 64-bit CPU, then quite frankly, *I* personally can't be bothered to care. That's my personal opinion, and I realize that some of the commercial vendors may care about their insane customers' satisfaction, but I'm simply not interested in insane users. If they have that much RAM (and bought it a few years ago when a 64-bit CPU wasn't an option), they can't be poor. So the _only_ explanation today for 12GB on a 32-bit machine is (a) insanity or (b) being so lazy as to not bother to upgrade and in either case, my personal reaction is "I'm *not* crazy, and yes, I'm lazy too, and I can't give a rats *ss about those problems". HIGHMEM was a mistake in the first place. It's one that we can live with, but I refuse to support it more than it needs to be supported. And 12GB is *way* past the end of what is worth supporting. Linus ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) 2007-11-15 21:47 ` Linus Torvalds @ 2007-11-15 22:11 ` Chris Friesen 2007-11-15 22:31 ` Linus Torvalds 2007-11-15 22:24 ` Rob Mueller ` (2 subsequent siblings) 3 siblings, 1 reply; 268+ messages in thread From: Chris Friesen @ 2007-11-15 22:11 UTC (permalink / raw) To: Linus Torvalds Cc: Peter Zijlstra, Bron Gondwana, Christian Kujau, Andrew Morton, Linux Kernel Mailing List, robm, riel, Anton Altaparmakov Linus Torvalds wrote: > So the _only_ explanation today for 12GB on a 32-bit machine is > (a) insanity > or > (b) being so lazy as to not bother to upgrade > and in either case, my personal reaction is "I'm *not* crazy, and yes, I'm > lazy too, and I can't give a rats *ss about those problems". How about... c) they bought it at the beginning of a project and are stuck with it because they aren't getting any more money for hardware d) they've shipped it to the field and have to support it We've got some 32-bit 8GB boxes for which both of these would hold true. Chris ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) 2007-11-15 22:11 ` Chris Friesen @ 2007-11-15 22:31 ` Linus Torvalds 0 siblings, 0 replies; 268+ messages in thread From: Linus Torvalds @ 2007-11-15 22:31 UTC (permalink / raw) To: Chris Friesen Cc: Peter Zijlstra, Bron Gondwana, Christian Kujau, Andrew Morton, Linux Kernel Mailing List, robm, riel, Anton Altaparmakov On Thu, 15 Nov 2007, Chris Friesen wrote: > > We've got some 32-bit 8GB boxes for which both of these would hold true. Still not enough of a reason for me to care. Remember - I'm the guy who refused to merge RH's 4G:4G patches because I thought they were an unsupportable nightmare. I care a lot about future supportability, and HIGHMEM is there purely as a temporary wart and blip on the screen. I did acknowledge that others may care more, but the fact is, I suspect that it's going to be cheaper to literally buy and ship a new machine to a customer than to really "suppport" it in any other form. Side note: HIGHMEM64G works perfectly fine with 12GB of RAM under *limited*loads*. If your customer does certain well-defined and simple things that don't put huge and varied loads on the VFS or VM layer, then 12GB+ is probably fine regardless. Linus ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) 2007-11-15 21:47 ` Linus Torvalds 2007-11-15 22:11 ` Chris Friesen @ 2007-11-15 22:24 ` Rob Mueller 2007-11-18 23:13 ` Daniel Phillips 2007-11-16 0:48 ` Alan Cox 2007-11-21 21:25 ` Jan Engelhardt 3 siblings, 1 reply; 268+ messages in thread From: Rob Mueller @ 2007-11-15 22:24 UTC (permalink / raw) To: Linus Torvalds, Peter Zijlstra Cc: Bron Gondwana, Christian Kujau, Andrew Morton, Linux Kernel Mailing List, riel, Anton Altaparmakov > That's my personal opinion, and I realize that some of the commercial > vendors may care about their insane customers' satisfaction, but I'm > simply not interested in insane users. If they have that much RAM (and > bought it a few years ago when a 64-bit CPU wasn't an option), they can't > be poor. >From our perspective, the main issue is that some of these machines we spent quite a bit of money on the big RAM (for it's day) + lots of 15k RPM SCSI drives + multi-year support contracts. They're highly IO bound, and barely use 10-20% of their old 2.4Ghz Prestonia Xeon CPUs. It's hard to justify junking those machines < 5 years. We have a couple of 6G machines and some 8G machines using PAE. On the whole, they actually have been working really well (hmmm, apart from the recent dirty pages issue + reiserfs data=journal leaks + inodes in lowmem limits) Rob ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) 2007-11-15 22:24 ` Rob Mueller @ 2007-11-18 23:13 ` Daniel Phillips 2007-11-19 3:41 ` Bron Gondwana 0 siblings, 1 reply; 268+ messages in thread From: Daniel Phillips @ 2007-11-18 23:13 UTC (permalink / raw) To: Rob Mueller Cc: Linus Torvalds, Peter Zijlstra, Bron Gondwana, Christian Kujau, Andrew Morton, Linux Kernel Mailing List, riel, Anton Altaparmakov On Thursday 15 November 2007 14:24, Rob Mueller wrote: > > That's my personal opinion, and I realize that some of the > > commercial vendors may care about their insane customers' > > satisfaction, but I'm simply not interested in insane users. If > > they have that much RAM (and bought it a few years ago when a > > 64-bit CPU wasn't an option), they can't be poor. > > From our perspective, the main issue is that some of these machines > we spent quite a bit of money on the big RAM (for it's day) + lots of > 15k RPM SCSI drives + multi-year support contracts. They're highly IO > bound, and barely use 10-20% of their old 2.4Ghz Prestonia Xeon CPUs. > It's hard to justify junking those machines < 5 years. > > We have a couple of 6G machines and some 8G machines using PAE. On > the whole, they actually have been working really well (hmmm, apart > from the recent dirty pages issue + reiserfs data=journal leaks + > inodes in lowmem limits) Junk everything except the 15K drives, you will be glad you did. Too bad about those multi-year support contracts, hopefully you got a deal on them. Prediction: after these dirty pages issues are gone, there will be more dirty page issues because the notion of dirty page limit is fundamentally broken. Your smartest recourse is to re-motherboard to a place where the dirty page limit borkage does not hurt as much, and in the process you will get a cheap hardware upgrade. Everybody will be happy, the sun will come out, the birds will sing. Regards, Daniel ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) 2007-11-18 23:13 ` Daniel Phillips @ 2007-11-19 3:41 ` Bron Gondwana 0 siblings, 0 replies; 268+ messages in thread From: Bron Gondwana @ 2007-11-19 3:41 UTC (permalink / raw) To: Daniel Phillips Cc: Rob Mueller, Linus Torvalds, Peter Zijlstra, Bron Gondwana, Christian Kujau, Andrew Morton, Linux Kernel Mailing List, riel, Anton Altaparmakov On Sun, Nov 18, 2007 at 04:13:18PM -0700, Daniel Phillips wrote: > On Thursday 15 November 2007 14:24, Rob Mueller wrote: > > > That's my personal opinion, and I realize that some of the > > > commercial vendors may care about their insane customers' > > > satisfaction, but I'm simply not interested in insane users. If > > > they have that much RAM (and bought it a few years ago when a > > > 64-bit CPU wasn't an option), they can't be poor. > > > > From our perspective, the main issue is that some of these machines > > we spent quite a bit of money on the big RAM (for it's day) + lots of > > 15k RPM SCSI drives + multi-year support contracts. They're highly IO > > bound, and barely use 10-20% of their old 2.4Ghz Prestonia Xeon CPUs. > > It's hard to justify junking those machines < 5 years. > > > > We have a couple of 6G machines and some 8G machines using PAE. On > > the whole, they actually have been working really well (hmmm, apart > > from the recent dirty pages issue + reiserfs data=journal leaks + > > inodes in lowmem limits) > > Junk everything except the 15K drives, you will be glad you did. Too > bad about those multi-year support contracts, hopefully you got a deal > on them. Actually, the 15K drives are the bit we're getting the least use out of now, since we're moving everything to external SATA units that are more easily swapable. > Prediction: after these dirty pages issues are gone, there will be more > dirty page issues because the notion of dirty page limit is > fundamentally broken. Your smartest recourse is to re-motherboard to a > place where the dirty page limit borkage does not hurt as much, and in > the process you will get a cheap hardware upgrade. Everybody will be > happy, the sun will come out, the birds will sing. Or just keep running 2.6.16 where it's all been working quite fine thanks very much, or maintain a simple patch that rips all that out since we don't care too much about "fairness" - we only run a couple of things on that machine and they run fine. Bron ( going to settle down and really test this stuff to make sure we have an acceptable "fix" for us then do it! ) ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) 2007-11-15 21:47 ` Linus Torvalds 2007-11-15 22:11 ` Chris Friesen 2007-11-15 22:24 ` Rob Mueller @ 2007-11-16 0:48 ` Alan Cox 2007-11-21 21:25 ` Jan Engelhardt 3 siblings, 0 replies; 268+ messages in thread From: Alan Cox @ 2007-11-16 0:48 UTC (permalink / raw) To: Linus Torvalds Cc: Peter Zijlstra, Bron Gondwana, Christian Kujau, Andrew Morton, Linux Kernel Mailing List, robm, riel, Anton Altaparmakov > So the _only_ explanation today for 12GB on a 32-bit machine is > (a) insanity > or > (b) being so lazy as to not bother to upgrade > and in either case, my personal reaction is "I'm *not* crazy, and yes, I'm > lazy too, and I can't give a rats *ss about those problems". 12GB-16GB worked well historically so its a regression. Above 16GB its all utterly mad. You forgot reason (c) though (c) 32bit is a tested approved certified etc environment - essentially conservativsm and paranoia, and its hard to explain to some of these people that the right answer really is less RAM or 64bit, especially as they may already know it but have a 12 month process to prove and certify a system configuration. > HIGHMEM was a mistake in the first place. It's one that we can live with, > but I refuse to support it more than it needs to be supported. And 12GB is > *way* past the end of what is worth supporting. Highmem to 4GB was sensible. Highmem to 8GB was pushing it. Alan ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) 2007-11-15 21:47 ` Linus Torvalds ` (2 preceding siblings ...) 2007-11-16 0:48 ` Alan Cox @ 2007-11-21 21:25 ` Jan Engelhardt 3 siblings, 0 replies; 268+ messages in thread From: Jan Engelhardt @ 2007-11-21 21:25 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Linus Torvalds, Bron Gondwana, Christian Kujau, Andrew Morton, Peter Zijlstra, Linux Kernel Mailing List, robm On Thu, 15 Nov 2007 13:47:54 -0800 (PST) Linus Torvalds wrote: > >But quite frankly, I refuse to even care about anything past that. If >you have 12G (or heaven forbid, even more) in your machine, and you >can't be bothered to just upgrade to a 64-bit CPU, then quite frankly, >*I* personally can't be bothered to care. > >If they have that much RAM (and bought it a few years ago when a 64-bit >CPU wasn't an option), they can't be poor. > >So the _only_ explanation today for 12GB on a 32-bit machine is > (a) insanity >or > (b) being so lazy as to not bother to upgrade > Just around the corner... $ ftp ftp Connected to ftp.gwdg.de. 220-==================================================================== 220-Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH Goettingen 220-==================================================================== 220-This is a Linux PC (Dell PE-2650, 2 CPUs P4/2800, 12 GB RAM) 220-running SuSE-Linux-8.2 with SuSE kernel 2.4.20-64GB-SMP. There is no reason to upgrade the hardware - if it works, hey good then. And I am pretty sure that a few 2 GB sticks are cheaper than a big opteron (if you only go by that). It sure is now - and probably even back then. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) 2007-11-15 21:14 ` Linus Torvalds 2007-11-15 21:26 ` Linus Torvalds 2007-11-15 21:26 ` Peter Zijlstra @ 2007-11-19 3:54 ` Bron Gondwana 2007-11-22 3:42 ` [PATCH 1/1] mm: add dirty_highmem option Bron Gondwana 3 siblings, 0 replies; 268+ messages in thread From: Bron Gondwana @ 2007-11-19 3:54 UTC (permalink / raw) To: Linus Torvalds Cc: Peter Zijlstra, Bron Gondwana, Christian Kujau, Andrew Morton, Linux Kernel Mailing List, robm On Thu, Nov 15, 2007 at 01:14:32PM -0800, Linus Torvalds wrote: Sorry about not replying to this earlier. I actually got a weekend away from the computer pretty much last weekend - took the kids swimming, helped a friend clear dead wood from around her house before the fire season. Shocking I know. > On Thu, 15 Nov 2007, Linus Torvalds wrote: > > > > Unacceptable. We used to do exactly what your patch does, and it got fixed > > once. We're not introducing that fundamentally broken concept again. > > Examples of non-broken solutions: > (a) always use lowmem sizes (what we do now) > (b) always use total mem sizes (sane but potentially dangerous: but the > VM pressure should work! It has serious bounce-buffer issues, though, > which is why I think it's crazy even if it's otherwise consistent) > (c) make all dirty counting be *purely* per-bdi, so that everybody can > disagree on what the limits are, but at least they also then use > different counters > > So it's just the "different writers look at the same dirty counts but then > interpret it to mean totally different things" that I think is so > fundamentally bogus. I'm not claiming that what we do now is the only way > to do things, I just don't think your approach is tenable. > > Btw, I actually suspect that while (a) is what we do now, for the specific > case that Bron has, we could have a /proc/sys/vm option to just enable > (b). So we don't have to have just one consistent model, we can allow odd > users (and Bron sounds like one - sorry Bron ;) to just force other, odd, > but consistent models. Hey, if Andrew Morton can tell us we find all the interesting bugs, you can call me odd. I've been called worse! We also run ReiserFS (3 of course, I tried 4 and it et my laptop disk) on all our production IMAP servers. Tried ext3 and the performance was so horrible that our users hated us (and I hated being woken in the night by things timing out and paging me). And I'm spending far too long still writing C thanks to Cyrus having enough bugs to keep me busy for the rest of my natural life if I don't break and go write my own IMAP server at some point. *clears throat* > I'd also like to point out that while the "bounce buffer" issue is not so > much a HIGHMEM issue on its own (it's really about the device DMA limits, > which are _independent_ of HIGHMEM, of course), the reason HIGHMEM is > special is that without HIGHMEM the bounce buffers generally work > perfectly fine. > > The problem with HIGHMEM is that it causes various metadata (dentries, > inodes, page struct tables etc) to eat up memory "prime real estate" under > the same kind of conditions that also dirty a lot of memory. So the reason > we disallow HIGHMEM from dirty limits is only *partly* the per-device or > mapping DMA limits, and to a large degree the fact that non-highmem memory > is special in general, and it is usually the non-highmem areas that are > constrained - and need to be protected. I'm going to finish off writing a decent test case so I can reliably reproduce the problem first, and then go compile a small set of kernels with the various patches that have been thrown around here and see if they solve the problems for me. Thankfully I don't have the same problem you do Linus - I don't care if any particular patch isn't consistent - isn't fair in the general sense - even "doesn't work for anyone else". So long as it's stable and it works on this machine I'm happy to support it through the next couple of years until we either get a world facing 64 bit machine with the spare capacity to run DCC or we drop DCC. The only reason to upgrade the kernel there at all is keeping up-to-date with security patches, and the relative tradeoffs of backporting (or expecting Adrian Bunk to keep doing it for us) rather than maintaing a small patch to keep the behaviour of one thing we like. And to all of you in this thread (especially Linus and Peter) - thanks heaps for grabbing on to a throw away line in an unrelated discussion and putting the work in to: a) explain the problem and the cause to me before I put in heaps of work tracking it down; and b) putting together some patches for me to test. I saw a couple of days ago someone posted an "Ask Slashdot" whether 6 weeks was an appropriate time for a software vendor to get a fix out to a customer and implying that the customer was an unrealistic whiner to expect anyone to be able to do better. I'll be able to point to this thread if anyone suggests that you can't get decent support on Linux! Bron. ^ permalink raw reply [flat|nested] 268+ messages in thread
* [PATCH 1/1] mm: add dirty_highmem option 2007-11-15 21:14 ` Linus Torvalds ` (2 preceding siblings ...) 2007-11-19 3:54 ` Bron Gondwana @ 2007-11-22 3:42 ` Bron Gondwana 2007-11-26 17:53 ` Linus Torvalds 2007-11-27 4:54 ` Andrew Morton 3 siblings, 2 replies; 268+ messages in thread From: Bron Gondwana @ 2007-11-22 3:42 UTC (permalink / raw) To: Linus Torvalds Cc: Peter Zijlstra, Bron Gondwana, Christian Kujau, Andrew Morton, Linux Kernel Mailing List, robm On Thu, Nov 15, 2007 at 01:14:32PM -0800, Linus Torvalds wrote: > Examples of non-broken solutions: > (a) always use lowmem sizes (what we do now) > (b) always use total mem sizes (sane but potentially dangerous: but the > VM pressure should work! It has serious bounce-buffer issues, though, > which is why I think it's crazy even if it's otherwise consistent) > > Btw, I actually suspect that while (a) is what we do now, for the specific > case that Bron has, we could have a /proc/sys/vm option to just enable > (b). So we don't have to have just one consistent model, we can allow odd > users (and Bron sounds like one - sorry Bron ;) to just force other, odd, > but consistent models. A 32 bit machine with HIGHMEM64 enabled running DCC has an MMAPed file of approximately 2Gb size which contains a hash format that is written "randomly" by the dbclean process. On 2.6.16 this process took a few minutes. With lowmem only accounting of dirty ratios, this takes about 12 hours of 100% disk IO, all random writes. This patch includes some code cleanup from Linus and a toggle in /proc/sys/vm/dirty_highmem which can be set to 1 to add the highmem back to the total available memory count. Signed-off-by: Bron Gondwana <brong@fastmail.fm> Index: linux-2.6.23.8-reiserfix-fai-vmdirty/mm/page-writeback.c =================================================================== --- linux-2.6.23.8-reiserfix-fai-vmdirty.orig/mm/page-writeback.c 2007-11-22 01:48:20.000000000 +0000 +++ linux-2.6.23.8-reiserfix-fai-vmdirty/mm/page-writeback.c 2007-11-22 02:42:04.000000000 +0000 @@ -70,6 +70,12 @@ static inline long sync_writeback_pages( int dirty_background_ratio = 5; /* + * free highmem will not be subtracted from the total free memory + * for calculating free ratios if vm_dirty_highmem is true + */ +int vm_dirty_highmem; + +/* * The generator of dirty data starts writeback at this percentage */ int vm_dirty_ratio = 10; @@ -153,7 +159,8 @@ static unsigned long determine_dirtyable x = global_page_state(NR_FREE_PAGES) + global_page_state(NR_INACTIVE) + global_page_state(NR_ACTIVE); - x -= highmem_dirtyable_memory(x); + if (!vm_dirty_highmem) + x -= highmem_dirtyable_memory(x); return x + 1; /* Ensure that we never return 0 */ } @@ -163,20 +170,12 @@ get_dirty_limits(long *pbackground, long { int background_ratio; /* Percentages */ int dirty_ratio; - int unmapped_ratio; long background; long dirty; unsigned long available_memory = determine_dirtyable_memory(); struct task_struct *tsk; - unmapped_ratio = 100 - ((global_page_state(NR_FILE_MAPPED) + - global_page_state(NR_ANON_PAGES)) * 100) / - available_memory; - dirty_ratio = vm_dirty_ratio; - if (dirty_ratio > unmapped_ratio / 2) - dirty_ratio = unmapped_ratio / 2; - if (dirty_ratio < 5) dirty_ratio = 5; Index: linux-2.6.23.8-reiserfix-fai-vmdirty/include/linux/writeback.h =================================================================== --- linux-2.6.23.8-reiserfix-fai-vmdirty.orig/include/linux/writeback.h 2007-10-09 20:31:38.000000000 +0000 +++ linux-2.6.23.8-reiserfix-fai-vmdirty/include/linux/writeback.h 2007-11-22 01:48:21.000000000 +0000 @@ -92,6 +92,7 @@ void throttle_vm_writeout(gfp_t gfp_mask /* These are exported to sysctl. */ extern int dirty_background_ratio; +extern int vm_dirty_highmem; extern int vm_dirty_ratio; extern int dirty_writeback_interval; extern int dirty_expire_interval; Index: linux-2.6.23.8-reiserfix-fai-vmdirty/kernel/sysctl.c =================================================================== --- linux-2.6.23.8-reiserfix-fai-vmdirty.orig/kernel/sysctl.c 2007-10-09 20:31:38.000000000 +0000 +++ linux-2.6.23.8-reiserfix-fai-vmdirty/kernel/sysctl.c 2007-11-22 01:48:21.000000000 +0000 @@ -776,6 +776,7 @@ static ctl_table kern_table[] = { /* Constants for minimum and maximum testing in vm_table. We use these as one-element integer vectors. */ static int zero; +static int one = 1; static int two = 2; static int one_hundred = 100; @@ -1066,6 +1067,19 @@ static ctl_table vm_table[] = { .extra1 = &zero, }, #endif +#ifdef CONFIG_HIGHMEM + { + .ctl_name = CTL_UNNUMBERED, + .procname = "dirty_highmem", + .data = &vm_dirty_highmem, + .maxlen = sizeof(vm_dirty_highmem), + .mode = 0644, + .proc_handler = &proc_dointvec_minmax, + .strategy = &sysctl_intvec, + .extra1 = &zero, + .extra2 = &one, + }, +#endif /* * NOTE: do not add new entries to this table unless you have read * Documentation/sysctl/ctl_unnumbered.txt Index: linux-2.6.23.8-reiserfix-fai-vmdirty/Documentation/filesystems/proc.txt =================================================================== --- linux-2.6.23.8-reiserfix-fai-vmdirty.orig/Documentation/filesystems/proc.txt 2007-11-22 02:32:36.000000000 +0000 +++ linux-2.6.23.8-reiserfix-fai-vmdirty/Documentation/filesystems/proc.txt 2007-11-22 02:39:11.000000000 +0000 @@ -1229,6 +1229,18 @@ dirty_background_ratio Contains, as a percentage of total system memory, the number of pages at which the pdflush background writeback daemon will start writing out dirty data. +dirty_highmem +------------- + +Contains, as a boolean, a switch to allow highmem to be counted as +part of the "available" memory against which the dirty ratios will be +applied. + +Setting this to 1 can be useful on 32 bit machines where you want to make +random changes within an MMAPed file that is larger than your available +lowmem, however it is potentially dangerous and has serious bounce-buffer +issues. + dirty_ratio ----------------- Index: linux-2.6.23.8-reiserfix-fai-vmdirty/Documentation/sysctl/vm.txt =================================================================== --- linux-2.6.23.8-reiserfix-fai-vmdirty.orig/Documentation/sysctl/vm.txt 2007-11-22 02:31:32.000000000 +0000 +++ linux-2.6.23.8-reiserfix-fai-vmdirty/Documentation/sysctl/vm.txt 2007-11-22 02:32:31.000000000 +0000 @@ -18,6 +18,7 @@ files can be found in mm/swap.c. Currently, these files are in /proc/sys/vm: - overcommit_memory - page-cluster +- dirty_highmem - dirty_ratio - dirty_background_ratio - dirty_expire_centisecs @@ -36,10 +37,10 @@ Currently, these files are in /proc/sys/ ============================================================== -dirty_ratio, dirty_background_ratio, dirty_expire_centisecs, -dirty_writeback_centisecs, vfs_cache_pressure, laptop_mode, -block_dump, swap_token_timeout, drop-caches, -hugepages_treat_as_movable: +dirty_highmem, dirty_ratio, dirty_background_ratio, +dirty_expire_centisecs, dirty_writeback_centisecs, +vfs_cache_pressure, laptop_mode, block_dump, +swap_token_timeout, drop-caches, hugepages_treat_as_movable: See Documentation/filesystems/proc.txt ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [PATCH 1/1] mm: add dirty_highmem option 2007-11-22 3:42 ` [PATCH 1/1] mm: add dirty_highmem option Bron Gondwana @ 2007-11-26 17:53 ` Linus Torvalds 2007-11-27 1:30 ` Bron Gondwana 2007-11-27 4:54 ` Andrew Morton 1 sibling, 1 reply; 268+ messages in thread From: Linus Torvalds @ 2007-11-26 17:53 UTC (permalink / raw) To: Bron Gondwana Cc: Peter Zijlstra, Christian Kujau, Andrew Morton, Linux Kernel Mailing List, robm On Thu, 22 Nov 2007, Bron Gondwana wrote: > > This patch includes some code cleanup from Linus and a toggle in > /proc/sys/vm/dirty_highmem which can be set to 1 to add the highmem > back to the total available memory count. Just to verify - can you confirm that this "just fixes it" for you? I think this is the right approach to take, and seems very safe (ie people who know that their loads are ok can just set the flag), but I do want to verify that there was nothing else going on, and that you now see the same performance as you did in 2.6.16? The other alternative, of course, would be to simply allow the dirty percentages to be > 100%, but that's just *odd* ;) Linus ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [PATCH 1/1] mm: add dirty_highmem option 2007-11-26 17:53 ` Linus Torvalds @ 2007-11-27 1:30 ` Bron Gondwana 0 siblings, 0 replies; 268+ messages in thread From: Bron Gondwana @ 2007-11-27 1:30 UTC (permalink / raw) To: Linus Torvalds Cc: Bron Gondwana, Peter Zijlstra, Christian Kujau, Andrew Morton, Linux Kernel Mailing List, robm On Mon, Nov 26, 2007 at 09:53:17AM -0800, Linus Torvalds wrote: > > > On Thu, 22 Nov 2007, Bron Gondwana wrote: > > > > This patch includes some code cleanup from Linus and a toggle in > > /proc/sys/vm/dirty_highmem which can be set to 1 to add the highmem > > back to the total available memory count. > > Just to verify - can you confirm that this "just fixes it" for you? > > I think this is the right approach to take, and seems very safe (ie people > who know that their loads are ok can just set the flag), but I do want to > verify that there was nothing else going on, and that you now see the same > performance as you did in 2.6.16? > > The other alternative, of course, would be to simply allow the dirty > percentages to be > 100%, but that's just *odd* ;) Yes, toggling dirty_highmem "just fixes it" in all our tests. I hadn't tested it on the production machine yet - but I'm just installing it there now since it's been running fine on a less important machine for a few days now. I did wonder about allowing the dirty percentage to go way up, but that would have cause "this one goes up to 110%" comments in the sysctl limits code and people would have thought I was childish. Can't have that. Much better to have "int one = 1" instead. Bron. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [PATCH 1/1] mm: add dirty_highmem option 2007-11-22 3:42 ` [PATCH 1/1] mm: add dirty_highmem option Bron Gondwana 2007-11-26 17:53 ` Linus Torvalds @ 2007-11-27 4:54 ` Andrew Morton 2007-11-27 5:24 ` Bron Gondwana 1 sibling, 1 reply; 268+ messages in thread From: Andrew Morton @ 2007-11-27 4:54 UTC (permalink / raw) To: Bron Gondwana Cc: Linus Torvalds, Peter Zijlstra, Christian Kujau, Linux Kernel Mailing List, robm On Thu, 22 Nov 2007 14:42:04 +1100 Bron Gondwana <brong@fastmail.fm> wrote: > /* > + * free highmem will not be subtracted from the total free memory > + * for calculating free ratios if vm_dirty_highmem is true > + */ > +int vm_dirty_highmem; One would expect that setting dirty_highmem to true would cause highmem to be accounted in dirty-memory calculations. However with this change reality is in fact the inverse of that. So how about this? Documentation/filesystems/proc.txt | 4 ++-- mm/page-writeback.c | 8 ++++---- 2 files changed, 6 insertions(+), 6 deletions(-) diff -puN Documentation/filesystems/proc.txt~mm-add-dirty_highmem-option-fix Documentation/filesystems/proc.txt --- a/Documentation/filesystems/proc.txt~mm-add-dirty_highmem-option-fix +++ a/Documentation/filesystems/proc.txt @@ -1265,8 +1265,8 @@ Contains, as a boolean, a switch to allo part of the "available" memory against which the dirty ratios will be applied. -Setting this to 1 can be useful on 32 bit machines where you want to make -random changes within an MMAPed file that is larger than your available +Setting this to 0 (false) can be useful on 32 bit machines where you wish to +make random changes within an MMAPed file that is larger than your available lowmem, however it is potentially dangerous and has serious bounce-buffer issues. diff -puN mm/page-writeback.c~mm-add-dirty_highmem-option-fix mm/page-writeback.c --- a/mm/page-writeback.c~mm-add-dirty_highmem-option-fix +++ a/mm/page-writeback.c @@ -69,10 +69,10 @@ static inline long sync_writeback_pages( int dirty_background_ratio = 5; /* - * free highmem will not be subtracted from the total free memory - * for calculating free ratios if vm_dirty_highmem is true + * free highmem will be subtracted from the total free memory for calculating + * free ratios if vm_dirty_highmem is true */ -int vm_dirty_highmem; +int vm_dirty_highmem = 1; /* * The generator of dirty data starts writeback at this percentage @@ -293,7 +293,7 @@ static unsigned long determine_dirtyable x = global_page_state(NR_FREE_PAGES) + global_page_state(NR_INACTIVE) + global_page_state(NR_ACTIVE); - if (!vm_dirty_highmem) + if (vm_dirty_highmem) x -= highmem_dirtyable_memory(x); return x + 1; /* Ensure that we never return 0 */ } _ (I dropped the already-merged part of your patch) (I fixed a build error in kernel/sysctl.c: "one" was defined twice when suitable config options were set). (It's an unpleasing patch, btw. But it's an unpleasant problem and at least this way people can tell us "hey, I did <this> and it started to work") ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [PATCH 1/1] mm: add dirty_highmem option 2007-11-27 4:54 ` Andrew Morton @ 2007-11-27 5:24 ` Bron Gondwana 2007-11-27 5:53 ` Andrew Morton 0 siblings, 1 reply; 268+ messages in thread From: Bron Gondwana @ 2007-11-27 5:24 UTC (permalink / raw) To: Andrew Morton Cc: Linus Torvalds, Peter Zijlstra, Christian Kujau, Linux Kernel Mailing List, Rob Mueller On Mon, 26 Nov 2007 20:54:28 -0800, "Andrew Morton" <akpm@linux-foundation.org> said: > On Thu, 22 Nov 2007 14:42:04 +1100 Bron Gondwana <brong@fastmail.fm> > wrote: > > > /* > > + * free highmem will not be subtracted from the total free memory > > + * for calculating free ratios if vm_dirty_highmem is true > > + */ > > +int vm_dirty_highmem; > > One would expect that setting dirty_highmem to true would cause highmem > to > be accounted in dirty-memory calculations. However with this change > reality is in fact the inverse of that. > > So how about this? Actually, I'm confused now. Maybe I chose a bad name to begin with. Does it mean "I am allowed to dirty high memory" or "my high memory will be dirty if this is on"? Hmm... I'm even having trouble articulating what's odd about it. I guess my internal model was: "if this flag is set then you are allowed to make high memory dirty without needing to flush it immediately", which is why I made it that way around. No - you're wrong. My patch _did_ include high memory in the dirty memory calculations when dirty_highmem was true. > x = global_page_state(NR_FREE_PAGES) > + global_page_state(NR_INACTIVE) > + global_page_state(NR_ACTIVE); This is the total memory, _including_ high memory. > x -= highmem_dirtyable_memory(x); This removes the high memory from the total count. I think I got it right. If dirty_highmem is set to true, then don't subtract highmem from the total memory count before calculating the percentages. That's what I meant, and that's what the toggle did. Removed the subtraction. Bron. > Documentation/filesystems/proc.txt | 4 ++-- > mm/page-writeback.c | 8 ++++---- > 2 files changed, 6 insertions(+), 6 deletions(-) > > diff -puN > Documentation/filesystems/proc.txt~mm-add-dirty_highmem-option-fix > Documentation/filesystems/proc.txt > --- a/Documentation/filesystems/proc.txt~mm-add-dirty_highmem-option-fix > +++ a/Documentation/filesystems/proc.txt > @@ -1265,8 +1265,8 @@ Contains, as a boolean, a switch to allo > part of the "available" memory against which the dirty ratios will be > applied. > > -Setting this to 1 can be useful on 32 bit machines where you want to > make > -random changes within an MMAPed file that is larger than your available > +Setting this to 0 (false) can be useful on 32 bit machines where you > wish to > +make random changes within an MMAPed file that is larger than your > available > lowmem, however it is potentially dangerous and has serious > bounce-buffer > issues. > > diff -puN mm/page-writeback.c~mm-add-dirty_highmem-option-fix > mm/page-writeback.c > --- a/mm/page-writeback.c~mm-add-dirty_highmem-option-fix > +++ a/mm/page-writeback.c > @@ -69,10 +69,10 @@ static inline long sync_writeback_pages( > int dirty_background_ratio = 5; > > /* > - * free highmem will not be subtracted from the total free memory > - * for calculating free ratios if vm_dirty_highmem is true > + * free highmem will be subtracted from the total free memory for > calculating > + * free ratios if vm_dirty_highmem is true > */ > -int vm_dirty_highmem; > +int vm_dirty_highmem = 1; > > /* > * The generator of dirty data starts writeback at this percentage > @@ -293,7 +293,7 @@ static unsigned long determine_dirtyable > x = global_page_state(NR_FREE_PAGES) > + global_page_state(NR_INACTIVE) > + global_page_state(NR_ACTIVE); > - if (!vm_dirty_highmem) > + if (vm_dirty_highmem) > x -= highmem_dirtyable_memory(x); > return x + 1; /* Ensure that we never return 0 */ > } > _ > > > > > (I dropped the already-merged part of your patch) > > (I fixed a build error in kernel/sysctl.c: "one" was defined twice when > suitable config options were set). > > (It's an unpleasing patch, btw. But it's an unpleasant problem and at > least > this way people can tell us "hey, I did <this> and it started to work") -- Bron Gondwana brong@fastmail.fm ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [PATCH 1/1] mm: add dirty_highmem option 2007-11-27 5:24 ` Bron Gondwana @ 2007-11-27 5:53 ` Andrew Morton 2007-11-27 12:10 ` dirty highmem calculation sysctl name (Was: [PATCH 1/1] mm: add dirty_highmem option) Bron Gondwana 0 siblings, 1 reply; 268+ messages in thread From: Andrew Morton @ 2007-11-27 5:53 UTC (permalink / raw) To: Bron Gondwana Cc: Linus Torvalds, Peter Zijlstra, Christian Kujau, Linux Kernel Mailing List, Rob Mueller On Tue, 27 Nov 2007 16:24:24 +1100 "Bron Gondwana" <brong@fastmail.fm> wrote: > On Mon, 26 Nov 2007 20:54:28 -0800, "Andrew Morton" <akpm@linux-foundation.org> said: > > On Thu, 22 Nov 2007 14:42:04 +1100 Bron Gondwana <brong@fastmail.fm> > > wrote: > > > > > /* > > > + * free highmem will not be subtracted from the total free memory > > > + * for calculating free ratios if vm_dirty_highmem is true > > > + */ > > > +int vm_dirty_highmem; > > > > One would expect that setting dirty_highmem to true would cause highmem > > to > > be accounted in dirty-memory calculations. However with this change > > reality is in fact the inverse of that. > > > > So how about this? > > Actually, I'm confused now. Maybe I chose a bad name to begin with. > Does it mean "I am allowed to dirty high memory" or "my high memory > will be dirty if this is on"? But we're always allowed to dirty highmem - there'd be no point in having it otherwise. Hence the term dirty_highmem is confusing. umm, really you want /proc/sys/vm/dont-account-highmem-in-dirty-memory-calculations, only shorter. Do you agree? If so, then it's still not a very pleasing interface - setting something to "true" to disable a particular piece of kernel behaviour implies a single negation which we don't really need. It would be simpler to have /proc/sys/vm/do-account-highmem-in-dirty-memory-calculations, defaulting to "true" - this has no negations. So... how about /proc/sys/vm/, umm. <looks at inbox, brain explodes> OK, I give up. Please see if you can think of something less confusing which involves no negations? Thanks. ^ permalink raw reply [flat|nested] 268+ messages in thread
* dirty highmem calculation sysctl name (Was: [PATCH 1/1] mm: add dirty_highmem option) 2007-11-27 5:53 ` Andrew Morton @ 2007-11-27 12:10 ` Bron Gondwana 2007-11-27 13:06 ` [PATCH] mm/page-writeback - highmem_is_dirtyable option (replaces dirty_highmem patch) Bron Gondwana 0 siblings, 1 reply; 268+ messages in thread From: Bron Gondwana @ 2007-11-27 12:10 UTC (permalink / raw) To: Andrew Morton Cc: Bron Gondwana, Linus Torvalds, Peter Zijlstra, Christian Kujau, Linux Kernel Mailing List, Rob Mueller On Mon, Nov 26, 2007 at 09:53:15PM -0800, Andrew Morton wrote: > On Tue, 27 Nov 2007 16:24:24 +1100 "Bron Gondwana" <brong@fastmail.fm> wrote: > > > On Mon, 26 Nov 2007 20:54:28 -0800, "Andrew Morton" <akpm@linux-foundation.org> said: > > > On Thu, 22 Nov 2007 14:42:04 +1100 Bron Gondwana <brong@fastmail.fm> > > > wrote: > > > > > > > /* > > > > + * free highmem will not be subtracted from the total free memory > > > > + * for calculating free ratios if vm_dirty_highmem is true > > > > + */ > > > > +int vm_dirty_highmem; > > > > > > One would expect that setting dirty_highmem to true would cause highmem > > > to > > > be accounted in dirty-memory calculations. However with this change > > > reality is in fact the inverse of that. > > > > > > So how about this? > > > > Actually, I'm confused now. Maybe I chose a bad name to begin with. > > Does it mean "I am allowed to dirty high memory" or "my high memory > > will be dirty if this is on"? > > But we're always allowed to dirty highmem - there'd be no point in having > it otherwise. Hence the term dirty_highmem is confusing. > > umm, really you want > /proc/sys/vm/dont-account-highmem-in-dirty-memory-calculations, only > shorter. > > Do you agree? I still read dirty_highmem as: /proc/sys/vm/do-account-highmem-in-dirty-memory-calculations ... so we're still talking one negative apart! > If so, then it's still not a very pleasing interface - setting something to > "true" to disable a particular piece of kernel behaviour implies a single > negation which we don't really need. Well, the particular piece of kernel behaviour is already a negative: "decrease the amount of memory allowed to get dirty so we never dirty more than a percentage of available lowmem" So what this flag is saying is: "DON'T decrease the amount of memory allowed to get dirty down to just the lowmem - dirty a percentage of total available including highmem" As Linus said - the alternative of allowing more than 100% of lowmem to be dirty is just plain too wierd, hence this approach of allowing an option to turn off the new restriction that appeared since 2.6.16. > It would be simpler to have > /proc/sys/vm/do-account-highmem-in-dirty-memory-calculations, > defaulting to "true" - this has no negations. No, that's not true. The whole point is that between 2.6.16 and 2.6.20 the kernel behaviour changed. It currently doesn't count highmem in dirty memory calculations, which is why the memory pressure appears to be so great when actually there's still 4Gb of unused memory in the box. /proc/sys/vm/do-account-highmem-in-dirty-memory-calculations would default to "false" to get the current behaviour post-2.6.16 kernels. Setting a flag to make it true would stop the kernel subtracting highmem from the available count, giving the "old" behaviour of allowing a percentage of all the memory in the system to be dirty before forcing writeback. > So... how about /proc/sys/vm/, umm. > > <looks at inbox, brain explodes> > > OK, I give up. Please see if you can think of something less confusing > which involves no negations? I've spent a while thinking about this, and looking at the code. I think this might be slightly clearer: /proc/sys/vm/highmem_is_dirtyable - defaults to false Here's how it would look in the code: static unsigned long determine_dirtyable_memory(void) { unsigned long x; x = global_page_state(NR_FREE_PAGES) + global_page_state(NR_INACTIVE) + global_page_state(NR_ACTIVE); if (!vm_highmem_is_dirtyable) x -= highmem_dirtyable_memory(x); return x + 1; /* Ensure that we never return 0 */ } I think that's very clear. "Unless highmem is dirtyable, subtract the otherwise dirtyable pages from the total dirtyable memory count if they are in highmem" Or without negatives: "If highmem is dirtyable then include highmem pages in the total dirtyable memory count" Unfortunately this isn't expressed without negatives in the code because it's easier (I presume without looking at all the different zones on a cruddy piece of old i386) to add up the total and remove the pages in the HIGHMEM zone than to add up all the non-HIGHMEM zones separately. Does that suit you? Does my explaination make sense? Would you like me to re-submit the patch based on this? I'm certainly not happy with dirty_highmem as it is now in mm because it looks backwards and unclear to me. Bron. ^ permalink raw reply [flat|nested] 268+ messages in thread
* [PATCH] mm/page-writeback - highmem_is_dirtyable option (replaces dirty_highmem patch) 2007-11-27 12:10 ` dirty highmem calculation sysctl name (Was: [PATCH 1/1] mm: add dirty_highmem option) Bron Gondwana @ 2007-11-27 13:06 ` Bron Gondwana 0 siblings, 0 replies; 268+ messages in thread From: Bron Gondwana @ 2007-11-27 13:06 UTC (permalink / raw) To: Andrew Morton, Linus Torvalds, Peter Zijlstra, Christian Kujau, Linux Kernel Mailing List, Rob Mueller On Tue, Nov 27, 2007 at 11:10:28PM +1100, Bron Gondwana wrote: > On Mon, Nov 26, 2007 at 09:53:15PM -0800, Andrew Morton wrote: > > umm, really you want > > /proc/sys/vm/dont-account-highmem-in-dirty-memory-calculations, only > > shorter. > > > > Do you agree? > > I still read dirty_highmem as: > > /proc/sys/vm/do-account-highmem-in-dirty-memory-calculations > > ... so we're still talking one negative apart! > > > It would be simpler to have > > /proc/sys/vm/do-account-highmem-in-dirty-memory-calculations, > > defaulting to "true" - this has no negations. > > No, that's not true. The whole point is that between 2.6.16 and > 2.6.20 the kernel behaviour changed. It currently doesn't count > highmem in dirty memory calculations, which is why the memory pressure > appears to be so great when actually there's still 4Gb of unused > memory in the box. > > > OK, I give up. Please see if you can think of something less confusing > > which involves no negations? > > I think this might be slightly clearer: > > /proc/sys/vm/highmem_is_dirtyable - defaults to false > > [ ... ] > > Would you like me to re-submit the patch based on this? I'm > certainly not happy with dirty_highmem as it is now in mm > because it looks backwards and unclear to me. Well, it was quick enough to just do - here's the patch. I've also updated the documentation a bit to clarify the intention and the reasons why you might want to use it (based in part on the comments to the original change that made highmem uncountable for dirtyness purposes) Tested and applied against 2.6.23.9 (our build script makes Debian packages from a clean unpack of kernel major plus patch minor plus svn checkout of out quilt series and apply regardless, so it was just as easy to bump the version number while I was at it). Builds, boots, passes a quick run of the test program I used last time around. Bron. Add vm.highmem_is_dirtyable toggle A 32 bit machine with HIGHMEM64 enabled running DCC has an MMAPed file of approximately 2Gb size which contains a hash format that is written randomly by the dbclean process. On 2.6.16 this process took a few minutes. With lowmem only accounting of dirty ratios, this takes about 12 hours of 100% disk IO, all random writes. This patch includes some code cleanup from Linus and a toggle in /proc/sys/vm/highmem_is_dirtyable which can be set to 1 to add the highmem back to the total available memory count. Signed-off-by: Bron Gondwana <brong@fastmail.fm> Index: linux-2.6.23.8-reiserfix-fai-vmdirty/mm/page-writeback.c =================================================================== --- linux-2.6.23.8-reiserfix-fai-vmdirty.orig/mm/page-writeback.c 2007-11-21 21:58:20.000000000 -0500 +++ linux-2.6.23.8-reiserfix-fai-vmdirty/mm/page-writeback.c 2007-11-27 07:27:51.000000000 -0500 @@ -70,6 +70,12 @@ int dirty_background_ratio = 5; /* + * free highmem will not be subtracted from the total free memory + * for calculating free ratios if vm_highmem_is_dirtyable is true + */ +int vm_highmem_is_dirtyable; + +/* * The generator of dirty data starts writeback at this percentage */ int vm_dirty_ratio = 10; @@ -153,7 +159,10 @@ x = global_page_state(NR_FREE_PAGES) + global_page_state(NR_INACTIVE) + global_page_state(NR_ACTIVE); - x -= highmem_dirtyable_memory(x); + + if (!vm_highmem_is_dirtyable) + x -= highmem_dirtyable_memory(x); + return x + 1; /* Ensure that we never return 0 */ } @@ -163,20 +172,12 @@ { int background_ratio; /* Percentages */ int dirty_ratio; - int unmapped_ratio; long background; long dirty; unsigned long available_memory = determine_dirtyable_memory(); struct task_struct *tsk; - unmapped_ratio = 100 - ((global_page_state(NR_FILE_MAPPED) + - global_page_state(NR_ANON_PAGES)) * 100) / - available_memory; - dirty_ratio = vm_dirty_ratio; - if (dirty_ratio > unmapped_ratio / 2) - dirty_ratio = unmapped_ratio / 2; - if (dirty_ratio < 5) dirty_ratio = 5; Index: linux-2.6.23.8-reiserfix-fai-vmdirty/include/linux/writeback.h =================================================================== --- linux-2.6.23.8-reiserfix-fai-vmdirty.orig/include/linux/writeback.h 2007-10-09 16:31:38.000000000 -0400 +++ linux-2.6.23.8-reiserfix-fai-vmdirty/include/linux/writeback.h 2007-11-27 07:22:17.000000000 -0500 @@ -95,6 +95,7 @@ extern int vm_dirty_ratio; extern int dirty_writeback_interval; extern int dirty_expire_interval; +extern int vm_highmem_is_dirtyable; extern int block_dump; extern int laptop_mode; Index: linux-2.6.23.8-reiserfix-fai-vmdirty/kernel/sysctl.c =================================================================== --- linux-2.6.23.8-reiserfix-fai-vmdirty.orig/kernel/sysctl.c 2007-10-09 16:31:38.000000000 -0400 +++ linux-2.6.23.8-reiserfix-fai-vmdirty/kernel/sysctl.c 2007-11-27 07:26:43.000000000 -0500 @@ -776,6 +776,7 @@ /* Constants for minimum and maximum testing in vm_table. We use these as one-element integer vectors. */ static int zero; +static int one = 1; static int two = 2; static int one_hundred = 100; @@ -1066,6 +1067,19 @@ .extra1 = &zero, }, #endif +#ifdef CONFIG_HIGHMEM + { + .ctl_name = CTL_UNNUMBERED, + .procname = "highmem_is_dirtyable", + .data = &vm_highmem_is_dirtyable, + .maxlen = sizeof(vm_highmem_is_dirtyable), + .mode = 0644, + .proc_handler = &proc_dointvec_minmax, + .strategy = &sysctl_intvec, + .extra1 = &zero, + .extra2 = &one, + }, +#endif /* * NOTE: do not add new entries to this table unless you have read * Documentation/sysctl/ctl_unnumbered.txt Index: linux-2.6.23.8-reiserfix-fai-vmdirty/Documentation/filesystems/proc.txt =================================================================== --- linux-2.6.23.8-reiserfix-fai-vmdirty.orig/Documentation/filesystems/proc.txt 2007-10-09 16:31:38.000000000 -0400 +++ linux-2.6.23.8-reiserfix-fai-vmdirty/Documentation/filesystems/proc.txt 2007-11-27 07:21:22.000000000 -0500 @@ -1253,6 +1253,21 @@ Data which has been dirty in-memory for longer than this interval will be written out next time a pdflush daemon wakes up. +highmem_is_dirtyable +-------------------- + +Only present if CONFIG_HIGHMEM is set. + +This defaults to 0 (false), meaning that the ratios set above are calculated +as a percentage of lowmem only. This protects against excessive scanning +in page reclaim, swapping and general VM distress. + +Setting this to 1 can be useful on 32 bit machines where you want to make +random changes within an MMAPed file that is larger than your available +lowmem without causing large quantities of random IO. Is is safe if the +behavior of all programs running on the machine is known and memory will +not be otherwise stressed. + legacy_va_layout ---------------- Index: linux-2.6.23.8-reiserfix-fai-vmdirty/Documentation/sysctl/vm.txt =================================================================== --- linux-2.6.23.8-reiserfix-fai-vmdirty.orig/Documentation/sysctl/vm.txt 2007-10-09 16:31:38.000000000 -0400 +++ linux-2.6.23.8-reiserfix-fai-vmdirty/Documentation/sysctl/vm.txt 2007-11-27 07:13:30.000000000 -0500 @@ -22,6 +22,7 @@ - dirty_background_ratio - dirty_expire_centisecs - dirty_writeback_centisecs +- highmem_is_dirtyable (only if CONFIG_HIGHMEM set) - max_map_count - min_free_kbytes - laptop_mode @@ -36,10 +37,10 @@ ============================================================== -dirty_ratio, dirty_background_ratio, dirty_expire_centisecs, -dirty_writeback_centisecs, vfs_cache_pressure, laptop_mode, -block_dump, swap_token_timeout, drop-caches, -hugepages_treat_as_movable: +dirty_ratio, dirty_background_ratio, dirty_expire_centisecs, +dirty_writeback_centisecs, highmem_is_dirtyable, +vfs_cache_pressure, laptop_mode, block_dump, swap_token_timeout, +drop-caches, hugepages_treat_as_movable: See Documentation/filesystems/proc.txt ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) 2007-11-15 16:32 ` Linus Torvalds 2007-11-15 19:40 ` Peter Zijlstra @ 2007-11-21 23:51 ` Bron Gondwana 2007-11-22 2:16 ` Bron Gondwana 1 sibling, 1 reply; 268+ messages in thread From: Bron Gondwana @ 2007-11-21 23:51 UTC (permalink / raw) To: Linus Torvalds Cc: Bron Gondwana, Christian Kujau, Andrew Morton, Peter Zijlstra, Linux Kernel Mailing List, robm On Thu, Nov 15, 2007 at 08:32:22AM -0800, Linus Torvalds wrote: > On Thu, 15 Nov 2007, Bron Gondwana wrote: > > > > I guess we'll be doing the one-liner kernel mod and testing > > that then. > > The thing to look at is "get_dirty_limits()" in mm/page-writeback.c, and > in this particular case it's the > > unsigned long available_memory = determine_dirtyable_memory(); > > that's going to bite you. In particular, note the > > x -= highmem_dirtyable_memory(x); > > that we do in determine_dirtyable_memory(). > > So in this case, if you basically remove that line, it will allow all of > memory to be dirtied (including highmem), and then the background_ratio > will work on the whole 6GB. > > HOWEVER! It's worth noting that we also have some other old legacy cruft > there that may interfere with your code. In particular, if you look at the > top of "get_dirty_limits()", it *also* does a > > unmapped_ratio = 100 - ((global_page_state(NR_FILE_MAPPED) + > global_page_state(NR_ANON_PAGES)) * 100) / > available_memory; > > dirty_ratio = vm_dirty_ratio; > if (dirty_ratio > unmapped_ratio / 2) > dirty_ratio = unmapped_ratio / 2; > > and that whole "unmapped_ratio" comparison is probably bogus these days, > since we now take the mapped dirty pages into account. That code harks > back to the days before we did that, and dirty ratios only affected > non-mapped pages. > > And in particular, now that I look at it, I wonder if it can even go > negative (because "available_memory" may be *smaller* than the > NR_FILE_MAPPED|ANON_PAGES sum!). > > We'll fix up a negative value anyway (because of the clamping of > dirty_ratio to no less than 5), but the point is that the whole > "unmapped_ratio" thing probably doesn't make sense any more, and may well > make the dirty_ratio not work for you, because you may have a very small > unmapped_ratio that effectively makes all dirty limits always clamp to a > very small value. > > So regardless, I think you may want to try the appended patch *first*. > > If this patch makes a difference, please holler. I think it's the correct > thing to do, but I'm not going to actually commit it without somebody > saying that it makes a difference (and preferably Peter Zijlstra and > Andrew acking it too). mmap: mmap call failed: errno: 12 errmsg: Cannot allocate memory Yep, that's "fixed" the problem alright! No way this puppy is dirtying 2Gb of memory any more. http://linux.brong.fastmail.fm/2007-11-22/bmtest.pl That said, pushing the size down to 1700 rather than 2000 in that file makes it run, and the behaviour matches the 2000 Mb case on 2.6.16.55 rather than 2.6.20.20 or 2.6.23.1 (my other test case kernels that happened to be pre-built on that machine) [root@lb1 ~]$ free total used free shared buffers cached Mem: 4149836 2073056 2076780 0 22036 1846096 -/+ buffers/cache: 204924 3944912 Swap: 2096472 0 2096472 That's after running the 1700Mb version. You can see this machine is our one remaining 4Gb machine (it's not running any production services unlike the 6Gb machine, so it's better for testing) Anyway - looks like this may be a "good enough" solution for out1 if it can manage an ~2Gb file with 6Gb of memory available. I'll test that later today - but I should drag myself into the office now... Bron. (patch left attached below for reference) > Only *after* testing this change is it probably a good idea to test the > real hack of then removing the highmem_dirtyable_memory() thing. > > Peter? Andrew? > > Linus > > --- > mm/page-writeback.c | 8 -------- > 1 files changed, 0 insertions(+), 8 deletions(-) > > diff --git a/mm/page-writeback.c b/mm/page-writeback.c > index 81a91e6..d55cfca 100644 > --- a/mm/page-writeback.c > +++ b/mm/page-writeback.c > @@ -297,20 +297,12 @@ get_dirty_limits(long *pbackground, long *pdirty, long *pbdi_dirty, > { > int background_ratio; /* Percentages */ > int dirty_ratio; > - int unmapped_ratio; > long background; > long dirty; > unsigned long available_memory = determine_dirtyable_memory(); > struct task_struct *tsk; > > - unmapped_ratio = 100 - ((global_page_state(NR_FILE_MAPPED) + > - global_page_state(NR_ANON_PAGES)) * 100) / > - available_memory; > - > dirty_ratio = vm_dirty_ratio; > - if (dirty_ratio > unmapped_ratio / 2) > - dirty_ratio = unmapped_ratio / 2; > - > if (dirty_ratio < 5) > dirty_ratio = 5; > ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) 2007-11-21 23:51 ` mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) Bron Gondwana @ 2007-11-22 2:16 ` Bron Gondwana 0 siblings, 0 replies; 268+ messages in thread From: Bron Gondwana @ 2007-11-22 2:16 UTC (permalink / raw) To: Bron Gondwana Cc: Linus Torvalds, Christian Kujau, Andrew Morton, Peter Zijlstra, Linux Kernel Mailing List, robm On Thu, Nov 22, 2007 at 10:51:15AM +1100, Bron Gondwana wrote: > On Thu, Nov 15, 2007 at 08:32:22AM -0800, Linus Torvalds wrote: > > If this patch makes a difference, please holler. I think it's the correct > > thing to do, but I'm not going to actually commit it without somebody > > saying that it makes a difference (and preferably Peter Zijlstra and > > Andrew acking it too). > > mmap: mmap call failed: errno: 12 errmsg: Cannot allocate memory > > Yep, that's "fixed" the problem alright! No way this puppy is > dirtying 2Gb of memory any more. > > http://linux.brong.fastmail.fm/2007-11-22/bmtest.pl Alternatively perhaps I'm just a moron who used a config file with: CONFIG_PAGE_OFFSET=0x80000000 set to build the new kernel (I hadn't committed it because it turned out not to solve the issue it was there for). That would explain a few things. [root@lb1 perl]$ free total used free shared buffers cached Mem: 4150620 2272284 1878336 0 11212 2066536 -/+ buffers/cache: 194536 3956084 Swap: 2096472 0 2096472 That's more the usage I would expect to see. Now for the downside. It works again, but it still runs slow. Seems to hit (and this is totally unscientific, I'm just watching the numbers scroll by) at about 120000 writes rather than 70000 writes, but that's still not fitting the while file dirty. I notice that PF_LESS_THROTTLE gets set by nfsd to get an extra 25% bonus free space allocated. Potentially dcc could use similar tricks to claim extra space if that knob is available up in userspace. I'm happy to patch dcc as well if I have to, I'm already backporting it, so adding another little quilt directory and applying it is pretty trivial (must try guilt/stgit one of these days) Bron. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 12:32 ` David Miller 2007-11-13 19:02 ` Andrew Morton @ 2007-11-13 19:32 ` Russell King 2007-11-13 20:13 ` Adrian Bunk 2007-11-13 20:52 ` Andrew Morton 1 sibling, 2 replies; 268+ messages in thread From: Russell King @ 2007-11-13 19:32 UTC (permalink / raw) To: David Miller Cc: akpm, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input On Tue, Nov 13, 2007 at 04:32:07AM -0800, David Miller wrote: > Luckily if the report being ignored isn't chaff, it will show up again > (and again and again) and this triggers a reprioritization because not > only is the bug no longer chaff, it also now got a lot of information > tagged to it so it's a double worthwhile investment to work on the > problem. Strongly agree. This is exactly what happened to that ARM NO_HZ bug report. The report in bugzilla was rather lacking (and wrong) in ways that have already been described. HPET on ARM? 8) Then on the morning of 6th November, someone reported on the mailing list that "pxa270 doesn't work with oneshot timer" and that was the trigger to getting the bug resolved - because it was a narrowly defined bug report. Since it was a narrowly defined bug report, it became very easy to investigate and resolve. About half an hour of time for an initial patch. There's another issue I want to raise concerning bugzilla. We have the classic case of "not enough people reading bugzilla bugs" - which is one of the biggest problems with bugzilla. Virtually no one in the ARM community looks for ARM bugs in bugzilla. Let's not forget that it would be a waste of time for people to manually check bugzilla for ARM bugs. There's soo few people reporting ARM bugs into bugzilla that a weekly manual check by every maintainer would just return the same old boring results for months and months at a time. It would be far more productive if the ARM category was deleted from bugzilla and the few people who use bugzilla reported their bugs on the mailing list. We've a couple of thousand people on the ARM kernel mailing list at the moment - that's 3 orders of magnitude more of eyes than look at bugzilla. (I'm not saying that if the ARM NO_HZ bug as reported in bugzilla had been reported on the correct mailing list would've been solved earlier; I doubt there'd be much difference. However, the probability of a question being asked of the reporter would've been much higher, and _that_ might have led to an earlier resolution.) -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 19:32 ` [BUG] New Kernel Bugs Russell King @ 2007-11-13 20:13 ` Adrian Bunk 2007-11-13 23:29 ` Russell King 2007-11-13 20:52 ` Andrew Morton 1 sibling, 1 reply; 268+ messages in thread From: Adrian Bunk @ 2007-11-13 20:13 UTC (permalink / raw) To: David Miller, akpm, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input On Tue, Nov 13, 2007 at 07:32:19PM +0000, Russell King wrote: >... > There's another issue I want to raise concerning bugzilla. We have the > classic case of "not enough people reading bugzilla bugs" - which is one > of the biggest problems with bugzilla. Virtually no one in the ARM > community looks for ARM bugs in bugzilla. > > Let's not forget that it would be a waste of time for people to manually > check bugzilla for ARM bugs. There's soo few people reporting ARM bugs > into bugzilla that a weekly manual check by every maintainer would just > return the same old boring results for months and months at a time. >... What about having all ARM bugs in Bugzilla by default assigned to linux-arm-kernel@lists.arm.linux.org.uk? [1] > Russell King cu Adrian [1] Either directly or through a pseudo address, but that's just a technical detail. -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 20:13 ` Adrian Bunk @ 2007-11-13 23:29 ` Russell King 2007-11-13 23:38 ` Andrew Morton 0 siblings, 1 reply; 268+ messages in thread From: Russell King @ 2007-11-13 23:29 UTC (permalink / raw) To: Adrian Bunk Cc: David Miller, akpm, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input On Tue, Nov 13, 2007 at 09:13:19PM +0100, Adrian Bunk wrote: > On Tue, Nov 13, 2007 at 07:32:19PM +0000, Russell King wrote: > >... > > There's another issue I want to raise concerning bugzilla. We have the > > classic case of "not enough people reading bugzilla bugs" - which is one > > of the biggest problems with bugzilla. Virtually no one in the ARM > > community looks for ARM bugs in bugzilla. > > > > Let's not forget that it would be a waste of time for people to manually > > check bugzilla for ARM bugs. There's soo few people reporting ARM bugs > > into bugzilla that a weekly manual check by every maintainer would just > > return the same old boring results for months and months at a time. > >... > > What about having all ARM bugs in Bugzilla by default assigned to > linux-arm-kernel@lists.arm.linux.org.uk? [1] That would also work, probably much better than setting up yet another list. My experience of trying to get mbligh to do this when I stopped looking after PCMCIA stuff was *extremely* painful. Wonder if it's become any easier of late? -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 23:29 ` Russell King @ 2007-11-13 23:38 ` Andrew Morton 0 siblings, 0 replies; 268+ messages in thread From: Andrew Morton @ 2007-11-13 23:38 UTC (permalink / raw) To: Russell King Cc: Adrian Bunk, David Miller, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input On Tue, 13 Nov 2007 23:29:54 +0000 Russell King <rmk+lkml@arm.linux.org.uk> wrote: > On Tue, Nov 13, 2007 at 09:13:19PM +0100, Adrian Bunk wrote: > > On Tue, Nov 13, 2007 at 07:32:19PM +0000, Russell King wrote: > > >... > > > There's another issue I want to raise concerning bugzilla. We have the > > > classic case of "not enough people reading bugzilla bugs" - which is one > > > of the biggest problems with bugzilla. Virtually no one in the ARM > > > community looks for ARM bugs in bugzilla. > > > > > > Let's not forget that it would be a waste of time for people to manually > > > check bugzilla for ARM bugs. There's soo few people reporting ARM bugs > > > into bugzilla that a weekly manual check by every maintainer would just > > > return the same old boring results for months and months at a time. > > >... > > > > What about having all ARM bugs in Bugzilla by default assigned to > > linux-arm-kernel@lists.arm.linux.org.uk? [1] > > That would also work, probably much better than setting up yet another > list. cpufreq (at least) does it this way. I don't know how well it is turning out in practice. It's useful if the initial report makes it clear (ie; to me) that the report has already gone to a mailing list so I don't go and forward a duplicate. But there are so few arm reports in bugzilla that this is all rather moot. > My experience of trying to get mbligh to do this when I stopped looking > after PCMCIA stuff was *extremely* painful. Wonder if it's become any > easier of late? He's a bad, bad man ;) But he's been turning these things around pretty rapidly lately. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 19:32 ` [BUG] New Kernel Bugs Russell King 2007-11-13 20:13 ` Adrian Bunk @ 2007-11-13 20:52 ` Andrew Morton 2007-11-13 22:18 ` Russell King 1 sibling, 1 reply; 268+ messages in thread From: Andrew Morton @ 2007-11-13 20:52 UTC (permalink / raw) To: Russell King Cc: David Miller, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input On Tue, 13 Nov 2007 19:32:19 +0000 Russell King <rmk+lkml@arm.linux.org.uk> wrote: > There's another issue I want to raise concerning bugzilla. We have the > classic case of "not enough people reading bugzilla bugs" - which is one > of the biggest problems with bugzilla. Virtually no one in the ARM > community looks for ARM bugs in bugzilla. Nor should they. > Let's not forget that it would be a waste of time for people to manually > check bugzilla for ARM bugs. There's soo few people reporting ARM bugs > into bugzilla that a weekly manual check by every maintainer would just > return the same old boring results for months and months at a time. I screen all bugzilla reports. 100% of them. - I'll try to establish whether it is a regression - I'll solicit any extra information which I believe the reveloper will need - I'll ensure that an appropriate developer has seen the report And yes, the number of arm-specific reports in there is very small. > It would be far more productive if the ARM category was deleted from > bugzilla and the few people who use bugzilla reported their bugs on the > mailing list. We've a couple of thousand people on the ARM kernel > mailing list at the moment - that's 3 orders of magnitude more of eyes > than look at bugzilla. Is that linux-arm-kernel@lists.arm.linux.org.uk? If so, MANITAINERS claims that it is subscribers-only. That would cause some bug reporters to give up and go away. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 20:52 ` Andrew Morton @ 2007-11-13 22:18 ` Russell King 2007-11-13 22:32 ` Andrew Morton 2007-11-14 5:56 ` [BUG] New Kernel Bugs Sam Ravnborg 0 siblings, 2 replies; 268+ messages in thread From: Russell King @ 2007-11-13 22:18 UTC (permalink / raw) To: Andrew Morton Cc: David Miller, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input On Tue, Nov 13, 2007 at 12:52:22PM -0800, Andrew Morton wrote: > On Tue, 13 Nov 2007 19:32:19 +0000 Russell King <rmk+lkml@arm.linux.org.uk> wrote: > > There's another issue I want to raise concerning bugzilla. We have the > > classic case of "not enough people reading bugzilla bugs" - which is one > > of the biggest problems with bugzilla. Virtually no one in the ARM > > community looks for ARM bugs in bugzilla. > > Nor should they. So what you're saying is... > > Let's not forget that it would be a waste of time for people to manually > > check bugzilla for ARM bugs. There's soo few people reporting ARM bugs > > into bugzilla that a weekly manual check by every maintainer would just > > return the same old boring results for months and months at a time. > > I screen all bugzilla reports. 100% of them. > > - I'll try to establish whether it is a regression > > - I'll solicit any extra information which I believe the reveloper will need > > - I'll ensure that an appropriate developer has seen the report > > And yes, the number of arm-specific reports in there is very small. that just because you do this everyone in a select clique, who you include me in, should be doing this as well. No. Thank. You. > > It would be far more productive if the ARM category was deleted from > > bugzilla and the few people who use bugzilla reported their bugs on the > > mailing list. We've a couple of thousand people on the ARM kernel > > mailing list at the moment - that's 3 orders of magnitude more of eyes > > than look at bugzilla. > > Is that linux-arm-kernel@lists.arm.linux.org.uk? Yes. > If so, MANITAINERS claims that it is subscribers-only. That would cause > some bug reporters to give up and go away. Find some other mailing list; I'm not hosting *nor* am I willing to run a non-subscribers only mailing list. Period. Not negotiable, so don't even try to change my mind. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 22:18 ` Russell King @ 2007-11-13 22:32 ` Andrew Morton 2007-11-13 23:09 ` Russell King 2007-11-14 1:55 ` David Miller 2007-11-14 5:56 ` [BUG] New Kernel Bugs Sam Ravnborg 1 sibling, 2 replies; 268+ messages in thread From: Andrew Morton @ 2007-11-13 22:32 UTC (permalink / raw) To: Russell King Cc: David Miller, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input On Tue, 13 Nov 2007 22:18:01 +0000 Russell King <rmk+lkml@arm.linux.org.uk> wrote: > On Tue, Nov 13, 2007 at 12:52:22PM -0800, Andrew Morton wrote: > > On Tue, 13 Nov 2007 19:32:19 +0000 Russell King <rmk+lkml@arm.linux.org.uk> wrote: > > > There's another issue I want to raise concerning bugzilla. We have the > > > classic case of "not enough people reading bugzilla bugs" - which is one > > > of the biggest problems with bugzilla. Virtually no one in the ARM > > > community looks for ARM bugs in bugzilla. > > > > Nor should they. > > So what you're saying is... > > > > Let's not forget that it would be a waste of time for people to manually > > > check bugzilla for ARM bugs. There's soo few people reporting ARM bugs > > > into bugzilla that a weekly manual check by every maintainer would just > > > return the same old boring results for months and months at a time. > > > > I screen all bugzilla reports. 100% of them. > > > > - I'll try to establish whether it is a regression > > > > - I'll solicit any extra information which I believe the reveloper will need > > > > - I'll ensure that an appropriate developer has seen the report > > > > And yes, the number of arm-specific reports in there is very small. > > that just because you do this everyone in a select clique, who you include > me in, should be doing this as well. > > No. Thank. You. No, I don't mean that at all and this was very plainly obviously from my very clearly written email. Let me try again. No, no subsystem developer needs to monitor new bugzilla reports. This is because *I do it for them*. I will actively make them aware of new reports which I believe are legitimate and which contain sufficient information for them to be able to take further action. > > > It would be far more productive if the ARM category was deleted from > > > bugzilla and the few people who use bugzilla reported their bugs on the > > > mailing list. We've a couple of thousand people on the ARM kernel > > > mailing list at the moment - that's 3 orders of magnitude more of eyes > > > than look at bugzilla. > > > > Is that linux-arm-kernel@lists.arm.linux.org.uk? > > Yes. > > > If so, MANITAINERS claims that it is subscribers-only. That would cause > > some bug reporters to give up and go away. > > Find some other mailing list; I'm not hosting *nor* am I willing to run a > non-subscribers only mailing list. Period. Not negotiable, so don't even > try to change my mind. Making a list subscribers-only will cause some bug reports to be lost. Tradeoffs are involved, against which decisions must be made. You have made yours. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 22:32 ` Andrew Morton @ 2007-11-13 23:09 ` Russell King 2007-11-13 23:17 ` Andrew Morton 2007-11-14 1:55 ` David Miller 1 sibling, 1 reply; 268+ messages in thread From: Russell King @ 2007-11-13 23:09 UTC (permalink / raw) To: Andrew Morton Cc: David Miller, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input On Tue, Nov 13, 2007 at 02:32:01PM -0800, Andrew Morton wrote: > On Tue, 13 Nov 2007 22:18:01 +0000 Russell King <rmk+lkml@arm.linux.org.uk> wrote: > > On Tue, Nov 13, 2007 at 12:52:22PM -0800, Andrew Morton wrote: > > > On Tue, 13 Nov 2007 19:32:19 +0000 Russell King <rmk+lkml@arm.linux.org.uk> wrote: > > > > There's another issue I want to raise concerning bugzilla. We have the > > > > classic case of "not enough people reading bugzilla bugs" - which is one > > > > of the biggest problems with bugzilla. Virtually no one in the ARM > > > > community looks for ARM bugs in bugzilla. > > > > > > Nor should they. > > > > So what you're saying is... > > > > > > Let's not forget that it would be a waste of time for people to manually > > > > check bugzilla for ARM bugs. There's soo few people reporting ARM bugs > > > > into bugzilla that a weekly manual check by every maintainer would just > > > > return the same old boring results for months and months at a time. > > > > > > I screen all bugzilla reports. 100% of them. > > > > > > - I'll try to establish whether it is a regression > > > > > > - I'll solicit any extra information which I believe the reveloper will need > > > > > > - I'll ensure that an appropriate developer has seen the report > > > > > > And yes, the number of arm-specific reports in there is very small. > > > > that just because you do this everyone in a select clique, who you include > > me in, should be doing this as well. > > > > No. Thank. You. > > No, I don't mean that at all and this was very plainly obviously from my very > clearly written email. Let me try again. If you screen all bugzilla reports then you'll know that bug #9356 arrived at about 1400 GMT yesterday. It's hardly surprising then that your utterly crappy responses to Natalie's message (which, incidentally, wasn't copied to me) sent within 24 hours of that report cause *great* annoyance. > No, no subsystem developer needs to monitor new bugzilla reports. This is > because *I do it for them*. I will actively make them aware of new reports > which I believe are legitimate and which contain sufficient information for > them to be able to take further action. On the whole you do an excellent job with feeding the bug reports to people, and while I recognise that you're only human, things do occasionally go wrong. For instance, sending clearly marked Samsung S3C bugs to me rather than Ben Dooks (who's in MAINTAINERS for those platforms.) > > > > It would be far more productive if the ARM category was deleted from > > > > bugzilla and the few people who use bugzilla reported their bugs on the > > > > mailing list. We've a couple of thousand people on the ARM kernel > > > > mailing list at the moment - that's 3 orders of magnitude more of eyes > > > > than look at bugzilla. > > > > > > Is that linux-arm-kernel@lists.arm.linux.org.uk? > > > > Yes. > > > > > If so, MANITAINERS claims that it is subscribers-only. That would cause > > > some bug reporters to give up and go away. > > > > Find some other mailing list; I'm not hosting *nor* am I willing to run a > > non-subscribers only mailing list. Period. Not negotiable, so don't even > > try to change my mind. > > Making a list subscribers-only will cause some bug reports to be lost. > > Tradeoffs are involved, against which decisions must be made. You have > made yours. So how are they lost when they're held in a moderation queue and are either accepted, a useful response given to the original poster, or are forwarded to someone who can deal with the issue. I don't think "subscribers only" describes my lists - we don't devnull stuff just because the poster is not a subscriber. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 23:09 ` Russell King @ 2007-11-13 23:17 ` Andrew Morton 0 siblings, 0 replies; 268+ messages in thread From: Andrew Morton @ 2007-11-13 23:17 UTC (permalink / raw) To: Russell King Cc: David Miller, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input On Tue, 13 Nov 2007 23:09:37 +0000 Russell King <rmk+lkml@arm.linux.org.uk> wrote: > On Tue, Nov 13, 2007 at 02:32:01PM -0800, Andrew Morton wrote: > > On Tue, 13 Nov 2007 22:18:01 +0000 Russell King <rmk+lkml@arm.linux.org.uk> wrote: > > > On Tue, Nov 13, 2007 at 12:52:22PM -0800, Andrew Morton wrote: > > > > On Tue, 13 Nov 2007 19:32:19 +0000 Russell King <rmk+lkml@arm.linux.org.uk> wrote: > > No, I don't mean that at all and this was very plainly obviously from my very > > clearly written email. Let me try again. > > If you screen all bugzilla reports then you'll know that bug #9356 arrived > at about 1400 GMT yesterday. It's hardly surprising then that your utterly > crappy responses to Natalie's message (which, incidentally, wasn't copied > to me) sent within 24 hours of that report cause *great* annoyance. > > > No, no subsystem developer needs to monitor new bugzilla reports. This is > > because *I do it for them*. I will actively make them aware of new reports > > which I believe are legitimate and which contain sufficient information for > > them to be able to take further action. > > On the whole you do an excellent job with feeding the bug reports to > people, and while I recognise that you're only human, things do > occasionally go wrong. For instance, sending clearly marked Samsung > S3C bugs to me rather than Ben Dooks (who's in MAINTAINERS for those > platforms.) Well whatever, sorry. But this is in the noise floor. Point is: many bug reports aren't being attended to. > > > > > It would be far more productive if the ARM category was deleted from > > > > > bugzilla and the few people who use bugzilla reported their bugs on the > > > > > mailing list. We've a couple of thousand people on the ARM kernel > > > > > mailing list at the moment - that's 3 orders of magnitude more of eyes > > > > > than look at bugzilla. > > > > > > > > Is that linux-arm-kernel@lists.arm.linux.org.uk? > > > > > > Yes. > > > > > > > If so, MANITAINERS claims that it is subscribers-only. That would cause > > > > some bug reporters to give up and go away. > > > > > > Find some other mailing list; I'm not hosting *nor* am I willing to run a > > > non-subscribers only mailing list. Period. Not negotiable, so don't even > > > try to change my mind. > > > > Making a list subscribers-only will cause some bug reports to be lost. > > > > Tradeoffs are involved, against which decisions must be made. You have > > made yours. > > So how are they lost when they're held in a moderation queue and are > either accepted, a useful response given to the original poster, or > are forwarded to someone who can deal with the issue. > > I don't think "subscribers only" describes my lists - we don't devnull > stuff just because the poster is not a subscriber. Oh, OK, as long as there really is a human paying attention to those things then that's fine. When one is on the sending end of these things one never knows how long it will take, not whether it will even happen. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 22:32 ` Andrew Morton 2007-11-13 23:09 ` Russell King @ 2007-11-14 1:55 ` David Miller 2007-11-14 2:27 ` Andrew Morton 2007-11-14 9:55 ` Russell King 1 sibling, 2 replies; 268+ messages in thread From: David Miller @ 2007-11-14 1:55 UTC (permalink / raw) To: akpm Cc: rmk+lkml, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input From: Andrew Morton <akpm@linux-foundation.org> Date: Tue, 13 Nov 2007 14:32:01 -0800 > On Tue, 13 Nov 2007 22:18:01 +0000 Russell King <rmk+lkml@arm.linux.org.uk> wrote: > > > Find some other mailing list; I'm not hosting *nor* am I willing to run a > > non-subscribers only mailing list. Period. Not negotiable, so don't even > > try to change my mind. > > Making a list subscribers-only will cause some bug reports to be lost. > > Tradeoffs are involved, against which decisions must be made. You have > made yours. Russell doesn't have to worry any more, he doesn't have to host it, and he doesn't have to be willing to run a non-subscribers-only mailing list. Because I am. I've created linux-arm@vger.kernel.org Enjoy. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 1:55 ` David Miller @ 2007-11-14 2:27 ` Andrew Morton 2007-11-14 3:47 ` David Miller 2007-11-14 8:30 ` Russell King 2007-11-14 9:55 ` Russell King 1 sibling, 2 replies; 268+ messages in thread From: Andrew Morton @ 2007-11-14 2:27 UTC (permalink / raw) To: David Miller Cc: rmk+lkml, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input On Tue, 13 Nov 2007 17:55:51 -0800 (PST) David Miller <davem@davemloft.net> wrote: > I've created linux-arm@vger.kernel.org Let me just say - I'm astonished at how little spam gets though the vger lists. Considering how many times those email addresses must have been added to spam databases. It must be a lot of work, and whoever is doing it does it well. I don't even know. Is it Matti? You? <contemplates linux-kernel@lists.sourceforge.net. Shudders.> ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 2:27 ` Andrew Morton @ 2007-11-14 3:47 ` David Miller 2007-11-14 8:30 ` Russell King 1 sibling, 0 replies; 268+ messages in thread From: David Miller @ 2007-11-14 3:47 UTC (permalink / raw) To: akpm Cc: rmk+lkml, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input From: Andrew Morton <akpm@linux-foundation.org> Date: Tue, 13 Nov 2007 18:27:00 -0800 > Let me just say - I'm astonished at how little spam gets though the vger > lists. Considering how many times those email addresses must have been > added to spam databases. > > It must be a lot of work, and whoever is doing it does it well. > > I don't even know. Is it Matti? You? Matti gets all the credit for setting up the bayesian et al. filters we have and training it as needed. > <contemplates linux-kernel@lists.sourceforge.net. Shudders.> Yes, sourceforge is a complete joke. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 2:27 ` Andrew Morton 2007-11-14 3:47 ` David Miller @ 2007-11-14 8:30 ` Russell King 1 sibling, 0 replies; 268+ messages in thread From: Russell King @ 2007-11-14 8:30 UTC (permalink / raw) To: Andrew Morton Cc: David Miller, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input On Tue, Nov 13, 2007 at 06:27:00PM -0800, Andrew Morton wrote: > On Tue, 13 Nov 2007 17:55:51 -0800 (PST) David Miller <davem@davemloft.net> wrote: > > > I've created linux-arm@vger.kernel.org > > Let me just say - I'm astonished at how little spam gets though the vger > lists. Considering how many times those email addresses must have been > added to spam databases. > > It must be a lot of work, and whoever is doing it does it well. > > I don't even know. Is it Matti? You? > > <contemplates linux-kernel@lists.sourceforge.net. Shudders.> Martin's changed the owner for ARM bugs last night to the mailing list so the whole issue is now redundant. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 1:55 ` David Miller 2007-11-14 2:27 ` Andrew Morton @ 2007-11-14 9:55 ` Russell King 2007-11-14 10:07 ` David Miller 1 sibling, 1 reply; 268+ messages in thread From: Russell King @ 2007-11-14 9:55 UTC (permalink / raw) To: David Miller Cc: akpm, netdev, linux-pcmcia, alsa-devel, protasnb, linux-kernel, linux-ide, bugme-daemon, linux-input On Tue, Nov 13, 2007 at 05:55:51PM -0800, David Miller wrote: > From: Andrew Morton <akpm@linux-foundation.org> > Date: Tue, 13 Nov 2007 14:32:01 -0800 > > > On Tue, 13 Nov 2007 22:18:01 +0000 Russell King <rmk+lkml@arm.linux.org.uk> wrote: > > > > > Find some other mailing list; I'm not hosting *nor* am I willing to run a > > > non-subscribers only mailing list. Period. Not negotiable, so don't even > > > try to change my mind. > > > > Making a list subscribers-only will cause some bug reports to be lost. > > > > Tradeoffs are involved, against which decisions must be made. You have > > made yours. > > Russell doesn't have to worry any more, he doesn't have to > host it, and he doesn't have to be willing to run a > non-subscribers-only mailing list. > > Because I am. > > I've created linux-arm@vger.kernel.org By doing so you've just said (implicitly) that you can not tolerate someone having a different opinion from your own. While I accept *your* right to run *your* lists how you please, you are unable to accept *my* right to run *my* lists how I see fit. Time will tell which lists will survive. Whatever, I suspect that by doing what you've just done, you're going to create more confusion and problems. Instead of having one focused place for discussions and bug reports, they're going to be spread more thinly, meaning less people looking at such things, meaning more bugs get ignored. Thus making the issue worse. So, when are you creating a replacement alsa-devel mailing list on vger? That's also subscribers-only. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 9:55 ` Russell King @ 2007-11-14 10:07 ` David Miller 2007-11-14 11:46 ` [alsa-devel] " Rene Herman ` (2 more replies) 0 siblings, 3 replies; 268+ messages in thread From: David Miller @ 2007-11-14 10:07 UTC (permalink / raw) To: rmk+lkml Cc: akpm, netdev, linux-pcmcia, alsa-devel, protasnb, linux-kernel, linux-ide, bugme-daemon, linux-input From: Russell King <rmk+lkml@arm.linux.org.uk> Date: Wed, 14 Nov 2007 09:55:07 +0000 > On Tue, Nov 13, 2007 at 05:55:51PM -0800, David Miller wrote: > > I've created linux-arm@vger.kernel.org > > By doing so you've just said (implicitly) that you can not tolerate > someone having a different opinion from your own. I created a mailing list on a machine where I provide such services. People can choose to use or not use the new list, it is their choice. > While I accept *your* right to run *your* lists how you please, you > are unable to accept *my* right to run *my* lists how I see fit. I didn't tell you to take your list down or to run it in some other way. I didn't tell you to unsubscribe everyone and move them over to the new list either. I've provided an alternative, and people can pick and choose how they see fit. I'm letting natural selection run it's course. Are you able to cope with the fact that people might not want to use your list any longer? Perhaps that is what bugs you so much about my giving people a alternative choice. > So, when are you creating a replacement alsa-devel mailing list on > vger? That's also subscribers-only. The operative term is "alternative" rather than "replacement". Perhaps this misunderstanding is what you're so upset about. And yes, that alsa list bugs the crap out of me too. I'm more than happy to provide an alternative for that one as well. In fact, *poof*, there it is, linux-alsa@vger.kernel.org is there and available for anyone who wants to use it. Have a nice day Russell. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [alsa-devel] [BUG] New Kernel Bugs 2007-11-14 10:07 ` David Miller @ 2007-11-14 11:46 ` Rene Herman 2007-11-14 11:56 ` David Miller 2007-11-15 4:16 ` Bron Gondwana 2007-11-14 19:44 ` Russell King 2007-11-16 22:16 ` Use *poof* for linux-omap (Was: [BUG] New Kernel Bugs) Tony Lindgren 2 siblings, 2 replies; 268+ messages in thread From: Rene Herman @ 2007-11-14 11:46 UTC (permalink / raw) To: David Miller Cc: rmk+lkml, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, akpm, Jaroslav Kysela, Takashi Iwai On 14-11-07 11:07, David Miller wrote: Added Jaroslav and Takashi to the already extensive CC.... > From: Russell King <rmk+lkml@arm.linux.org.uk> >> So, when are you creating a replacement alsa-devel mailing list on >> vger? That's also subscribers-only. > > The operative term is "alternative" rather than "replacement". > Perhaps this misunderstanding is what you're so upset about. > > And yes, that alsa list bugs the crap out of me too. I'm more than > happy to provide an alternative for that one as well. alsa-devel@alsa-project.org is not subscriber-only. Same as that arm list, it's _moderated_ for non-subscribers and given that I and other moderators have been doing our best to moderate quickly (I tend to stay logged in to the moderation interface all day for example) what specifically bugged the crap out of you? It's not something a poster needs to concern himself with. Also for alsa-devel the moderators tend to add any valid non-subcribers to a whitelist after landing in the queue the first time meaning even a delay is just a one-time thing normally. So what's the trouble? Basically, noone need even notice... > In fact, *poof*, there it is, linux-alsa@vger.kernel.org is there and > available for anyone who wants to use it. Not that I think that moving alsa-devel over to vger wouldn't be a good idea mind you; when the list moved from sourceforge, asking you to host it was my preferred option. I do somewhat suspect that Jaroslav would like to keep the alsa-devel@ name (and I'd like to ask you to then also host alsa-user@) and would then rewrite mail to those lists @alsa-project.org to vger. But what is the problem you speak of with the alsa-devel list? While I would not mind loosing it, moderation hasn't been overly laborious and I'm not aware of any serious problems. Rene. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [alsa-devel] [BUG] New Kernel Bugs 2007-11-14 11:46 ` [alsa-devel] " Rene Herman @ 2007-11-14 11:56 ` David Miller 2007-11-14 12:01 ` David Miller 2007-11-14 12:09 ` Rene Herman 2007-11-15 4:16 ` Bron Gondwana 1 sibling, 2 replies; 268+ messages in thread From: David Miller @ 2007-11-14 11:56 UTC (permalink / raw) To: rene.herman Cc: rmk+lkml, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, akpm, perex, tiwai From: Rene Herman <rene.herman@keyaccess.nl> Date: Wed, 14 Nov 2007 12:46:24 +0100 > alsa-devel@alsa-project.org is not subscriber-only. Same as that arm list, > it's _moderated_ for non-subscribers and given that I and other moderators > have been doing our best to moderate quickly (I tend to stay logged in to > the moderation interface all day for example) what specifically bugged the > crap out of you? It's not something a poster needs to concern himself with. The fact that it farts at me every time I post to this thread. That's rude and annoying. > Also for alsa-devel the moderators tend to add any valid non-subcribers to > a whitelist after landing in the queue the first time meaning even a delay > is just a one-time thing normally. So what's the trouble? Basically, noone > need even notice... That sucks for new people taking part in the conversation. There is no reason for moderation at all, it isn't necessary for spam prevention and it does nothing but annoy new posters and make work for the moderator. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [alsa-devel] [BUG] New Kernel Bugs 2007-11-14 11:56 ` David Miller @ 2007-11-14 12:01 ` David Miller 2007-11-14 8:25 ` Moderated list (Was: Re: [BUG] New Kernel Bugs) Takashi Iwai 2007-11-14 12:12 ` [alsa-devel] [BUG] New Kernel Bugs Rene Herman 2007-11-14 12:09 ` Rene Herman 1 sibling, 2 replies; 268+ messages in thread From: David Miller @ 2007-11-14 12:01 UTC (permalink / raw) To: rene.herman Cc: rmk+lkml, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, akpm, perex, tiwai From: David Miller <davem@davemloft.net> Date: Wed, 14 Nov 2007 03:56:57 -0800 (PST) > The fact that it farts at me every time I post to this thread. See? I got another one and I have received at least 10 of the following over the past 2 days. That's rediculious. And because a human adds the whitelist this is always going to happen to someone when they start posting to the alsa list for the first time. /me gets ready for the 11th copy in response to this one... -------------------- Subject: Your message to Alsa-devel awaits moderator approval From: alsa-devel-bounces@alsa-project.org To: davem@davemloft.net Date: Wed, 14 Nov 2007 12:57:06 +0100 Sender: alsa-devel-bounces@alsa-project.org Your mail to 'Alsa-devel' with the subject Re: [alsa-devel] [BUG] New Kernel Bugs Is being held until the list moderator can review it for approval. The reason it is being held: Too many recipients to the message Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://mailman.alsa-project.org/mailman/confirm/alsa-devel/12dd3bd077bbf9cd142f214beae6d22ae43b53aa ^ permalink raw reply [flat|nested] 268+ messages in thread
* Moderated list (Was: Re: [BUG] New Kernel Bugs) 2007-11-14 12:01 ` David Miller @ 2007-11-14 8:25 ` Takashi Iwai 2007-11-14 12:21 ` Rene Herman 2007-11-14 12:12 ` [alsa-devel] [BUG] New Kernel Bugs Rene Herman 1 sibling, 1 reply; 268+ messages in thread From: Takashi Iwai @ 2007-11-14 8:25 UTC (permalink / raw) To: David Miller Cc: rene.herman, rmk+lkml, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, akpm, perex At Wed, 14 Nov 2007 04:01:31 -0800 (PST), David Miller wrote: > > From: David Miller <davem@davemloft.net> > Date: Wed, 14 Nov 2007 03:56:57 -0800 (PST) > > > The fact that it farts at me every time I post to this thread. > > See? I got another one and I have received at least 10 of the > following over the past 2 days. > > That's rediculious. > > And because a human adds the whitelist this is always going to > happen to someone when they start posting to the alsa list for > the first time. ... if you give too many recipients in your post. That is often really annoying thing to me, together with keeping the unrelated subject line ;) I personally don't care whether it's a moderated or open list. We chose it simply due to too bad S/N ratio at that time. So, if the current list annoys your or many others and the list management on vger is so good, it'd be basically a good move, of course. I'll appreciate it. The only confusion would be the change of ML address, but we can do it slowly, too. Takashi ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Moderated list (Was: Re: [BUG] New Kernel Bugs) 2007-11-14 8:25 ` Moderated list (Was: Re: [BUG] New Kernel Bugs) Takashi Iwai @ 2007-11-14 12:21 ` Rene Herman 2007-11-14 9:47 ` Takashi Iwai 0 siblings, 1 reply; 268+ messages in thread From: Rene Herman @ 2007-11-14 12:21 UTC (permalink / raw) To: Takashi Iwai Cc: David Miller, rmk+lkml, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, akpm, perex On 14-11-07 09:25, Takashi Iwai wrote: > At Wed, 14 Nov 2007 04:01:31 -0800 (PST), > David Miller wrote: >> From: David Miller <davem@davemloft.net> >> Date: Wed, 14 Nov 2007 03:56:57 -0800 (PST) >> >>> The fact that it farts at me every time I post to this thread. >> See? I got another one and I have received at least 10 of the >> following over the past 2 days. >> >> That's rediculious. >> >> And because a human adds the whitelist this is always going to >> happen to someone when they start posting to the alsa list for >> the first time. > > ... if you give too many recipients in your post. That is often > really annoying thing to me, together with keeping the unrelated > subject line ;) > > I personally don't care whether it's a moderated or open list. > We chose it simply due to too bad S/N ratio at that time. So, if the > current list annoys your or many others and the list management on > vger is so good, it'd be basically a good move, of course. I'll > appreciate it. > > The only confusion would be the change of ML address, but we can do it > slowly, too. I'd love the lists at vger. Amazing spam-filtering. I'd like to request the name alsa-devel@vger.kernel.org (and alsa-user@vger.kernel.org if at all possible so we can open that one up as well) though. There wouldn't need to be a forced ML address change if Jaroslov would then just rewrite alsa-{devel,user}@alsa-project.org to vger.kernel.org same as he did for alsa-devel and does for alsa-user to @lists.sf.net. Rene. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Moderated list (Was: Re: [BUG] New Kernel Bugs) 2007-11-14 12:21 ` Rene Herman @ 2007-11-14 9:47 ` Takashi Iwai 2007-11-14 23:23 ` Moderated list David Miller 0 siblings, 1 reply; 268+ messages in thread From: Takashi Iwai @ 2007-11-14 9:47 UTC (permalink / raw) To: Rene Herman Cc: David Miller, rmk+lkml, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, akpm, perex At Wed, 14 Nov 2007 13:21:30 +0100, Rene Herman wrote: > > On 14-11-07 09:25, Takashi Iwai wrote: > > > At Wed, 14 Nov 2007 04:01:31 -0800 (PST), > > David Miller wrote: > >> From: David Miller <davem@davemloft.net> > >> Date: Wed, 14 Nov 2007 03:56:57 -0800 (PST) > >> > >>> The fact that it farts at me every time I post to this thread. > >> See? I got another one and I have received at least 10 of the > >> following over the past 2 days. > >> > >> That's rediculious. > >> > >> And because a human adds the whitelist this is always going to > >> happen to someone when they start posting to the alsa list for > >> the first time. > > > > ... if you give too many recipients in your post. That is often > > really annoying thing to me, together with keeping the unrelated > > subject line ;) > > > > I personally don't care whether it's a moderated or open list. > > We chose it simply due to too bad S/N ratio at that time. So, if the > > current list annoys your or many others and the list management on > > vger is so good, it'd be basically a good move, of course. I'll > > appreciate it. > > > > The only confusion would be the change of ML address, but we can do it > > slowly, too. > > I'd love the lists at vger. Amazing spam-filtering. I'd like to request the > name alsa-devel@vger.kernel.org (and alsa-user@vger.kernel.org if at all > possible so we can open that one up as well) though. I think alsa-user can stay as is. It's no place for dragging many other addresses like alsa-devel. BTW, I also prefer keeping the name alsa-devel@. It's been so. > There wouldn't need to be a forced ML address change if Jaroslov would then > just rewrite alsa-{devel,user}@alsa-project.org to vger.kernel.org same as > he did for alsa-devel and does for alsa-user to @lists.sf.net. If it works, then I'm for it, too. thanks, Takashi ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Moderated list 2007-11-14 9:47 ` Takashi Iwai @ 2007-11-14 23:23 ` David Miller 2007-11-15 6:09 ` Rene Herman 0 siblings, 1 reply; 268+ messages in thread From: David Miller @ 2007-11-14 23:23 UTC (permalink / raw) To: tiwai Cc: rene.herman, rmk+lkml, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, akpm, perex From: Takashi Iwai <tiwai@suse.de> Date: Wed, 14 Nov 2007 10:47:39 +0100 > I think alsa-user can stay as is. It's no place for dragging many > other addresses like alsa-devel. > > BTW, I also prefer keeping the name alsa-devel@. It's been so. That's fine with me, I've changed it alsa-devel@vger.kernel.org ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Moderated list 2007-11-14 23:23 ` Moderated list David Miller @ 2007-11-15 6:09 ` Rene Herman 0 siblings, 0 replies; 268+ messages in thread From: Rene Herman @ 2007-11-15 6:09 UTC (permalink / raw) To: David Miller, perex Cc: tiwai, rmk+lkml, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, akpm On 15-11-07 00:23, David Miller wrote: > From: Takashi Iwai <tiwai@suse.de> >> BTW, I also prefer keeping the name alsa-devel@. It's been so. > > That's fine with me, I've changed it alsa-devel@vger.kernel.org Great, thanks. Jaroslav -- given that this list won't need moderation I'd consider it the main/only alsa-devel. The alsa-devel subscriber database was cleansed only a couple of months ago when moving from sourceforge so it should now be okay to just transfer all subscriptions. Or maybe you're already moving things; mailman.alsa-project.org seems to be down at least.... Rene. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [alsa-devel] [BUG] New Kernel Bugs 2007-11-14 12:01 ` David Miller 2007-11-14 8:25 ` Moderated list (Was: Re: [BUG] New Kernel Bugs) Takashi Iwai @ 2007-11-14 12:12 ` Rene Herman 1 sibling, 0 replies; 268+ messages in thread From: Rene Herman @ 2007-11-14 12:12 UTC (permalink / raw) To: David Miller Cc: rmk+lkml, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, akpm, perex, tiwai On 14-11-07 13:01, David Miller wrote: > From: David Miller <davem@davemloft.net> > Date: Wed, 14 Nov 2007 03:56:57 -0800 (PST) > >> The fact that it farts at me every time I post to this thread. > > See? I got another one and I have received at least 10 of the > following over the past 2 days. Nah, in this case you are not even getting them to not being a non-subcriber but due to too many CCs. I got one as well. That just needs to be disabled, does not have anything to do with non-subscribers (and you're in the white list) but is just a retarted bit of list configuration... (no, I can't personally change it, needs Jaroslav Kysela) Rene. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [alsa-devel] [BUG] New Kernel Bugs 2007-11-14 11:56 ` David Miller 2007-11-14 12:01 ` David Miller @ 2007-11-14 12:09 ` Rene Herman 1 sibling, 0 replies; 268+ messages in thread From: Rene Herman @ 2007-11-14 12:09 UTC (permalink / raw) To: David Miller Cc: rmk+lkml, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, akpm, perex, tiwai On 14-11-07 12:56, David Miller wrote: > From: Rene Herman <rene.herman@keyaccess.nl> > Date: Wed, 14 Nov 2007 12:46:24 +0100 > >> alsa-devel@alsa-project.org is not subscriber-only. Same as that arm list, >> it's _moderated_ for non-subscribers and given that I and other moderators >> have been doing our best to moderate quickly (I tend to stay logged in to >> the moderation interface all day for example) what specifically bugged the >> crap out of you? It's not something a poster needs to concern himself with. > > The fact that it farts at me every time I post to this thread. That's > rude and annoying. It certainly is. I only experienced that now due to the "too many recipients to message" moderation notice that I got from my own message. Jaroslav -- please disable that junk or if possible, make it a "at most once per address per month" thing or somesuch. This is complete crap. >> Also for alsa-devel the moderators tend to add any valid non-subcribers to >> a whitelist after landing in the queue the first time meaning even a delay >> is just a one-time thing normally. So what's the trouble? Basically, noone >> need even notice... > > That sucks for new people taking part in the conversation. > > There is no reason for moderation at all, it isn't necessary > for spam prevention and it does nothing but annoy new posters > and make work for the moderator. Yes there is. It's necessary for lists that do not have the human and other resouces behind it that vger does. alsa-devel was drowning in spam and dying as a result back when it was at sourceforge. Upon moving, my preference was to ask the lists to be hosted at vger but given that (it seems) Jaroslav wanted to keep them locally, moderation was very necessary. I moderate out quite a bit of spam every day. vger is doing an amazing job at spam filtering -- if it's an option to move to vger, than sure, no need. But otherwise, the "no need" needs a list admin with enough bandwidth and skill. As to the "new people": it's not optimal, but (upto this thread I'll admit -- I woke up to a huge number of posts in the queue) it's not been a _real_ problem. alsa-devel is not high-volume enough for it to be. Rene. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [alsa-devel] [BUG] New Kernel Bugs 2007-11-14 11:46 ` [alsa-devel] " Rene Herman 2007-11-14 11:56 ` David Miller @ 2007-11-15 4:16 ` Bron Gondwana 2007-11-15 5:59 ` Rene Herman 1 sibling, 1 reply; 268+ messages in thread From: Bron Gondwana @ 2007-11-15 4:16 UTC (permalink / raw) To: Rene Herman Cc: David Miller, rmk+lkml, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, akpm, Jaroslav Kysela, Takashi Iwai On Wed, Nov 14, 2007 at 12:46:24PM +0100, Rene Herman wrote: > On 14-11-07 11:07, David Miller wrote: > > Added Jaroslav and Takashi to the already extensive CC.... > >> From: Russell King <rmk+lkml@arm.linux.org.uk> > >>> So, when are you creating a replacement alsa-devel mailing list on >>> vger? That's also subscribers-only. >> The operative term is "alternative" rather than "replacement". >> Perhaps this misunderstanding is what you're so upset about. >> And yes, that alsa list bugs the crap out of me too. I'm more than >> happy to provide an alternative for that one as well. > > alsa-devel@alsa-project.org is not subscriber-only. Same as that arm list, > it's _moderated_ for non-subscribers and given that I and other moderators > have been doing our best to moderate quickly (I tend to stay logged in to > the moderation interface all day for example) what specifically bugged the > crap out of you? It's not something a poster needs to concern himself with. Totally unrelated - I sent something to the kolab mailing list a couple of days ago (it's moderated for non subscribers) informing them that I had found the cause of some Cyrus bugs that they had problems with in the past and providing a link to my post to the cyrus list with the patches attached. It sat in the moderation queue and then was rejected with "non subscriber post to subscription only list". Not only was the reponse a day later when I had moved on to other things, but it got me really pissed off that I had put some effort into providing a good quality post that outlined the specific issues and how they applied to their project, and had been summarily dismissed, probably without the effort being put in. There's no way for a non-subscriber to know in advance if the list they are trying to post to will do that to them, completely negating the effort put in to writing something worthwhile to inform that community. It's insular, and it sucks. So yeah, my attitude now is that the Kolab folks can go screw themselves and track down the fix on their own or wait until I've convinced upstream to accept the fixes (likely) and they have moved to the new version (unlikely for a long time, and meanwhile they're missing out on the performance increases that having a more stable skiplist library would give them) I'm sure if I had something that I considered worth informing the ALSA project of, I'd be wary of spending the same effort writing a good post knowing it may be dropped in between the by a list moderator just selecing all and bouncing them. Bron. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [alsa-devel] [BUG] New Kernel Bugs 2007-11-15 4:16 ` Bron Gondwana @ 2007-11-15 5:59 ` Rene Herman 2007-11-15 12:02 ` Bron Gondwana 2007-11-15 13:17 ` Olivier Galibert 0 siblings, 2 replies; 268+ messages in thread From: Rene Herman @ 2007-11-15 5:59 UTC (permalink / raw) To: Bron Gondwana Cc: David Miller, rmk+lkml, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, akpm, Jaroslav Kysela, Takashi Iwai On 15-11-07 05:16, Bron Gondwana wrote: > Totally unrelated - I sent something to the kolab mailing list a couple [ ... ] > I'm sure if I had something that I considered worth informing the ALSA > project of, I'd be wary of spending the same effort writing a good post > knowing it may be dropped in between the by a list moderator just > selecing all and bouncing them. Totally unrelated indeed so why are spouting crap? If the kohab list has a problem take it up with them but keep ALSA out of it. alsa-devel has only ever moderated out spam -- nothing else. ene ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [alsa-devel] [BUG] New Kernel Bugs 2007-11-15 5:59 ` Rene Herman @ 2007-11-15 12:02 ` Bron Gondwana 2007-11-15 12:26 ` Rene Herman 2007-11-15 13:17 ` Olivier Galibert 1 sibling, 1 reply; 268+ messages in thread From: Bron Gondwana @ 2007-11-15 12:02 UTC (permalink / raw) To: Rene Herman Cc: Bron Gondwana, David Miller, rmk+lkml, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, akpm, Jaroslav Kysela, Takashi Iwai On Thu, Nov 15, 2007 at 06:59:34AM +0100, Rene Herman wrote: > On 15-11-07 05:16, Bron Gondwana wrote: > >> Totally unrelated - I sent something to the kolab mailing list a couple > > [ ... ] > >> I'm sure if I had something that I considered worth informing the ALSA >> project of, I'd be wary of spending the same effort writing a good post >> knowing it may be dropped in between the by a list moderator just selecing >> all and bouncing them. > > Totally unrelated indeed so why are spouting crap? If the kohab list has a > problem take it up with them but keep ALSA out of it. alsa-devel has only > ever moderated out spam -- nothing else. As an outsider to the list, how do I know what your policy will be other than "I've been rejected out of hand by someone else's list, so my experience is that member only lists aren't willing to listen to something I have to say unless I make the effort to sign up and have yet another folder accumulating unread messages". I don't. Well, ok - maybe I do here since I've let myself be dragged in to the debate. Oops. I get the same information from both project websites: "moderated for non-members, public archives" - no way of knowing that ALSA will accept me informing them of something they would be interested without committing to reading or bit-bucketing their list. The alternative is to subscribe just long enough to send something and then unsubscribe again.... or cold-email a member and ask them to pass a message along. Or post and hope it doesn't get rejected, not even knowing for a day or so. Bron. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [alsa-devel] [BUG] New Kernel Bugs 2007-11-15 12:02 ` Bron Gondwana @ 2007-11-15 12:26 ` Rene Herman 2007-11-15 13:00 ` Jörn Engel 0 siblings, 1 reply; 268+ messages in thread From: Rene Herman @ 2007-11-15 12:26 UTC (permalink / raw) To: Bron Gondwana Cc: David Miller, rmk+lkml, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, akpm, Jaroslav Kysela, Takashi Iwai On 15-11-07 13:02, Bron Gondwana wrote: > I get the same information from both project websites: "moderated for > non-members, public archives" - no way of knowing that ALSA will accept > me informing them of something they would be interested without > committing to reading or bit-bucketing their list. Can you please just shelve this crap? You have a way of knowing that "ALSA will accept you" and that is knowing or assuming that the ALSA project doesn't consist of drooling retards. When a project list goes to the difficulty of moderating non-subscribers it has made the explicit choice to _not_ become subscriber only. Then refusing valid non-subscribers after all makes no sense whatsoever. I'm sorry you got your feelings hurt by that other list but it was no doubt an accident; take it up with them. Rene. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [alsa-devel] [BUG] New Kernel Bugs 2007-11-15 12:26 ` Rene Herman @ 2007-11-15 13:00 ` Jörn Engel 2007-11-15 14:29 ` Rene Herman 0 siblings, 1 reply; 268+ messages in thread From: Jörn Engel @ 2007-11-15 13:00 UTC (permalink / raw) To: Rene Herman Cc: Bron Gondwana, David Miller, rmk+lkml, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, akpm, Jaroslav Kysela, Takashi Iwai On Thu, 15 November 2007 13:26:51 +0100, Rene Herman wrote: > > Can you please just shelve this crap? You have a way of knowing that "ALSA > will accept you" and that is knowing or assuming that the ALSA project > doesn't consist of drooling retards. Well, my experience with moderation has been that moderated mails are stuck in some queue for weeks. Two seperate lists, neither of them was alsa. If also is doing a better job, great. But it still has to live with the general reputation of non-subscriber moderation. > When a project list goes to the difficulty of moderating non-subscribers it > has made the explicit choice to _not_ become subscriber only. Then refusing > valid non-subscribers after all makes no sense whatsoever. I'm sorry you > got your feelings hurt by that other list but it was no doubt an accident; > take it up with them. Been there, done that. In spite of people not being drooling retards, the amount of time and effort they invest into either moderation or improving the ruleset is quite limited. Problems persist. And even without mails being held hostage for weeks, every single moderation mail is annoying. Like the one I'm sure to receive after sending this out. Jörn -- Joern's library part 5: http://www.faqs.org/faqs/compression-faq/part2/section-9.html ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [alsa-devel] [BUG] New Kernel Bugs 2007-11-15 13:00 ` Jörn Engel @ 2007-11-15 14:29 ` Rene Herman 0 siblings, 0 replies; 268+ messages in thread From: Rene Herman @ 2007-11-15 14:29 UTC (permalink / raw) To: Jörn Engel Cc: Bron Gondwana, David Miller, rmk+lkml, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, akpm, Jaroslav Kysela, Takashi Iwai On 15-11-07 14:00, Jörn Engel wrote: > And even without mails being held hostage for weeks, every single > moderation mail is annoying. Like the one I'm sure to receive after > sending this out. Certainly. Upto this thread I wasn't actually aware the list was doing that. While it might be informative once, getting it each time quickly gets old. Don't know if mailman can do anything like it but I'd suggest anyone running a non-subscriber-moderation list configure it to send such messages at most once a <time-period> per address or some such. And just disable the message if it cannot do that. Fortunately, alsa-devel is (almost) no longer such a list anyway as it's moving to vger. Hurrah. David -- thanks. Rene. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [alsa-devel] [BUG] New Kernel Bugs 2007-11-15 5:59 ` Rene Herman 2007-11-15 12:02 ` Bron Gondwana @ 2007-11-15 13:17 ` Olivier Galibert 2007-11-15 9:34 ` Takashi Iwai 1 sibling, 1 reply; 268+ messages in thread From: Olivier Galibert @ 2007-11-15 13:17 UTC (permalink / raw) To: Rene Herman Cc: Bron Gondwana, David Miller, rmk+lkml, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, akpm, Jaroslav Kysela, Takashi Iwai On Thu, Nov 15, 2007 at 06:59:34AM +0100, Rene Herman wrote: > Totally unrelated indeed so why are spouting crap? If the kohab list has a > problem take it up with them but keep ALSA out of it. alsa-devel has only > ever moderated out spam -- nothing else. That is incorrect. Hopefully it is the case now though, since my experience of the subject was years ago. OG. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [alsa-devel] [BUG] New Kernel Bugs 2007-11-15 13:17 ` Olivier Galibert @ 2007-11-15 9:34 ` Takashi Iwai 0 siblings, 0 replies; 268+ messages in thread From: Takashi Iwai @ 2007-11-15 9:34 UTC (permalink / raw) To: Olivier Galibert Cc: Rene Herman, Bron Gondwana, David Miller, rmk+lkml, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, akpm, Jaroslav Kysela At Thu, 15 Nov 2007 14:17:27 +0100, Olivier Galibert wrote: > > On Thu, Nov 15, 2007 at 06:59:34AM +0100, Rene Herman wrote: > > Totally unrelated indeed so why are spouting crap? If the kohab list has a > > problem take it up with them but keep ALSA out of it. alsa-devel has only > > ever moderated out spam -- nothing else. > > That is incorrect. Hopefully it is the case now though, since my > experience of the subject was years ago. Yeah, it was really years ago that we once switched to the open list. Funny that people never forget such a thing :) Takashi ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 10:07 ` David Miller 2007-11-14 11:46 ` [alsa-devel] " Rene Herman @ 2007-11-14 19:44 ` Russell King 2007-11-16 22:16 ` Use *poof* for linux-omap (Was: [BUG] New Kernel Bugs) Tony Lindgren 2 siblings, 0 replies; 268+ messages in thread From: Russell King @ 2007-11-14 19:44 UTC (permalink / raw) To: David Miller Cc: alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, akpm On Wed, Nov 14, 2007 at 02:07:06AM -0800, David Miller wrote: > From: Russell King <rmk+lkml@arm.linux.org.uk> > Date: Wed, 14 Nov 2007 09:55:07 +0000 > > > On Tue, Nov 13, 2007 at 05:55:51PM -0800, David Miller wrote: > > > I've created linux-arm@vger.kernel.org > > > > By doing so you've just said (implicitly) that you can not tolerate > > someone having a different opinion from your own. > > I created a mailing list on a machine where I provide such services. > > People can choose to use or not use the new list, it is their choice. > > > While I accept *your* right to run *your* lists how you please, you > > are unable to accept *my* right to run *my* lists how I see fit. > > I didn't tell you to take your list down or to run it in some other > way. I didn't tell you to unsubscribe everyone and move them over > to the new list either. I didn't say that you were. > I've provided an alternative, and people can pick and choose how they > see fit. I'm letting natural selection run it's course. Are you > able to cope with the fact that people might not want to use your > list any longer? Perhaps that is what bugs you so much about my > giving people a alternative choice. Absolutely, and if you'd have read my message you'd have seen that I'd said effectively the same thing that you're saying here. Having been flamed for not reading emails properly by AKPM shall I flame you for not reading my emails properly? Oh no, it's merely human to occasionally have such misunderstandings. Unless you're rmk. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ^ permalink raw reply [flat|nested] 268+ messages in thread
* Use *poof* for linux-omap (Was: [BUG] New Kernel Bugs) 2007-11-14 10:07 ` David Miller 2007-11-14 11:46 ` [alsa-devel] " Rene Herman 2007-11-14 19:44 ` Russell King @ 2007-11-16 22:16 ` Tony Lindgren 2007-11-17 0:45 ` Use *poof* for linux-omap David Miller 2 siblings, 1 reply; 268+ messages in thread From: Tony Lindgren @ 2007-11-16 22:16 UTC (permalink / raw) To: David Miller; +Cc: linux-kernel Hi Dave, * David Miller <davem@davemloft.net> [071114 02:09]: <snip> > > In fact, *poof*, there it is, linux-alsa@vger.kernel.org is there and > available for anyone who wants to use it. Can you please use your *poof* trick one more time to set up linux-omap@vger.kernel.org? We've (as in linux-omap community) would like to move from subscriber only list at linux-omap-open-source@linux.omap.com to vger as we're starting to get more patches and comments on LKML. For related discussion on linux-omap-open-source@linux.omap.com, see [1]. Regards, Tony [1] http://linux.omap.com/pipermail/linux-omap-open-source/2007-November/011980.html ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Use *poof* for linux-omap 2007-11-16 22:16 ` Use *poof* for linux-omap (Was: [BUG] New Kernel Bugs) Tony Lindgren @ 2007-11-17 0:45 ` David Miller 2007-11-18 20:01 ` Tony Lindgren 0 siblings, 1 reply; 268+ messages in thread From: David Miller @ 2007-11-17 0:45 UTC (permalink / raw) To: tony; +Cc: linux-kernel From: Tony Lindgren <tony@atomide.com> Date: Fri, 16 Nov 2007 14:16:11 -0800 > Can you please use your *poof* trick one more time to set up > linux-omap@vger.kernel.org? Done, enjoy. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Use *poof* for linux-omap 2007-11-17 0:45 ` Use *poof* for linux-omap David Miller @ 2007-11-18 20:01 ` Tony Lindgren 0 siblings, 0 replies; 268+ messages in thread From: Tony Lindgren @ 2007-11-18 20:01 UTC (permalink / raw) To: David Miller; +Cc: linux-kernel * David Miller <davem@davemloft.net> [071116 16:46]: > From: Tony Lindgren <tony@atomide.com> > Date: Fri, 16 Nov 2007 14:16:11 -0800 > > > Can you please use your *poof* trick one more time to set up > > linux-omap@vger.kernel.org? > > Done, enjoy. Thanks! Tony ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 22:18 ` Russell King 2007-11-13 22:32 ` Andrew Morton @ 2007-11-14 5:56 ` Sam Ravnborg 2007-11-14 5:59 ` Sam Ravnborg 2007-11-14 6:13 ` David Miller 1 sibling, 2 replies; 268+ messages in thread From: Sam Ravnborg @ 2007-11-14 5:56 UTC (permalink / raw) To: Andrew Morton, David Miller, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input > > > If so, MANITAINERS claims that it is subscribers-only. That would cause > > some bug reporters to give up and go away. > > Find some other mailing list; I'm not hosting *nor* am I willing to run a > non-subscribers only mailing list. Period. Not negotiable, so don't even > try to change my mind. The postmasters at vger is pretty good at running mailing lists. For linux-kbuild my effort so far has been to request it. Thats not a big deal. So if they accept it you could have linux-arm@vger.kernel.org for zero overhead for you. Sam ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 5:56 ` [BUG] New Kernel Bugs Sam Ravnborg @ 2007-11-14 5:59 ` Sam Ravnborg 2007-11-14 6:13 ` David Miller 1 sibling, 0 replies; 268+ messages in thread From: Sam Ravnborg @ 2007-11-14 5:59 UTC (permalink / raw) To: Andrew Morton, David Miller, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input On Wed, Nov 14, 2007 at 06:56:06AM +0100, Sam Ravnborg wrote: > > > > > If so, MANITAINERS claims that it is subscribers-only. That would cause > > > some bug reporters to give up and go away. > > > > Find some other mailing list; I'm not hosting *nor* am I willing to run a > > non-subscribers only mailing list. Period. Not negotiable, so don't even > > try to change my mind. > > The postmasters at vger is pretty good at running mailing lists. > For linux-kbuild my effort so far has been to request it. > Thats not a big deal. > > So if they accept it you could have linux-arm@vger.kernel.org for zero > overhead for you. And in a later mail I saw davem already created it. Sam ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 5:56 ` [BUG] New Kernel Bugs Sam Ravnborg 2007-11-14 5:59 ` Sam Ravnborg @ 2007-11-14 6:13 ` David Miller 1 sibling, 0 replies; 268+ messages in thread From: David Miller @ 2007-11-14 6:13 UTC (permalink / raw) To: sam Cc: akpm, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input From: Sam Ravnborg <sam@ravnborg.org> Date: Wed, 14 Nov 2007 06:56:06 +0100 > > > > > If so, MANITAINERS claims that it is subscribers-only. That would cause > > > some bug reporters to give up and go away. > > > > Find some other mailing list; I'm not hosting *nor* am I willing to run a > > non-subscribers only mailing list. Period. Not negotiable, so don't even > > try to change my mind. > > The postmasters at vger is pretty good at running mailing lists. > For linux-kbuild my effort so far has been to request it. > Thats not a big deal. > > So if they accept it you could have linux-arm@vger.kernel.org for zero > overhead for you. I already did, get a little deeper in your mailbox before replying :-) ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 12:12 ` Andrew Morton 2007-11-13 12:32 ` David Miller @ 2007-11-13 13:40 ` Ingo Molnar 2007-11-13 14:08 ` Mark Lord 2007-11-13 16:55 ` Randy Dunlap 1 sibling, 2 replies; 268+ messages in thread From: Ingo Molnar @ 2007-11-13 13:40 UTC (permalink / raw) To: Andrew Morton Cc: David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon * Andrew Morton <akpm@linux-foundation.org> wrote: > > > Do you believe that our response to bug reports is adequate? > > > > Do you feel that making us feel and look like shit helps? > > That doesn't answer my question. > > See, first we need to work out whether we have a problem. If we do > this, then we can then have a think about what to do about it. > > I tried to convince the 2006 KS attendees that we have a problem and I > resoundingly failed. People seemed to think that we're doing OK. > > But it appears that data such as this contradicts that belief. > > This is not a minor matter. If the kernel _is_ slowly deteriorating > then this won't become readily apparent until it has been happening > for a number of years. By that stage there will be so much work to do > to get us back to an acceptable level that it will take a huge effort. > And it will take a long time after that for the kerel to get its > reputation back. > > So it is important that we catch deterioration *early* if it is > happening. yes, yes, yes, and i agree with you that there is a problem. I tried to make this point at the 2007 KS: not only is degradation in quality not apparent for years, slow degradation in quality can give kernel developers the exact _opposite_ perception! (Fewer testers means fewer bugreports and that results in apparent "improved" quality and fewer reported regressions - while exactly the opposite is happening and testers are leaving us without giving us any indication that this is happening. We just dont notice.) I'm not moaning about bugs that slip through - those are unavoidable facts of a high flux codebase. I'm moaning about reoccuring, avoidable bugs, i'm moaning about hostility towards testers, i'm moaning about hostility towards automated testing, i'm moaning about unnecessary hoops a willing (but unskilled) tester has to go through to help us out. I tried to make the point that the only good approach is to remove our current subjective bias from quality metrics and to at least realize what a cavalier attitude we still have to QA. The moment we are able to _measure_ how bad we are, kernel developers will adopt in a second and will improve those metrics. Lets use more debug tools, both static and dynamic ones. Lets measure tester base and we need to measure _lost_ early adopters and the reasons why they are lost. Regression metrics are a very important first step too and i'm very happy about the increasing effort that is being spent on this. This is all QA-101 that _cannot be argued against on a rational basis_, it's just that these sorts of things have been largely ignored for years, in favor of the all-too-easy "open source means many eyeballs and that is our QA" answer, which is a _good_ answer but by far not the most intelligent answer! Today "many eyeballs" is simply not good enough and nature (and other OS projects) will route us around if we dont change. We kernel developers have been spoiled by years of abundance in testing resources. We squander tons of resources in this area, and we could be so much more economic about this without hindering our development model in any way. We could be so much better about QA and everyone would benefit without having to compromize on the incoming flux of changes - it's so much easier to write new features for a high quality kernel. My current guesstimation is that we are utilizing our current testing resources at around 10% efficiency. (i.e. if we did an 'ideal' job we could fix 10 times as many bugs with the same size of tester effort!) It used to be around 5%. (and i mainly attribute the increase from 5% to 10% to Andrew and the many other people who do kernel QA - kudos!) 10% is still awful and we very much suck. Paradoxically, the "end product" is still considerably good quality in absolute terms because other pieces of our infrastructure are so good and powerful, but QA is still a 'weak link' of our path to the user that reduces the quality of the end result. We could _really_ be so much better without any compromises that hurt. (and this is in no way directed at the networking folks - it holds for all of us. I have one main complaint about networking: the separate netdev list is a bad idea - networking regressions should be discussed and fixed on lkml, like most other subsystems are. Any artificial split of the lk discussion space is bad.) Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 13:40 ` Ingo Molnar @ 2007-11-13 14:08 ` Mark Lord 2007-11-13 15:24 ` Giacomo A. Catenazzi ` (4 more replies) 2007-11-13 16:55 ` Randy Dunlap 1 sibling, 5 replies; 268+ messages in thread From: Mark Lord @ 2007-11-13 14:08 UTC (permalink / raw) To: Ingo Molnar Cc: Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon Ingo Molnar wrote: .. > This is all QA-101 that _cannot be argued against on a rational basis_, > it's just that these sorts of things have been largely ignored for > years, in favor of the all-too-easy "open source means many eyeballs and > that is our QA" answer, which is a _good_ answer but by far not the most > intelligent answer! Today "many eyeballs" is simply not good enough and > nature (and other OS projects) will route us around if we dont change. .. QA-101 and "many eyeballs" are not at all in opposition. The latter is how we find out about bugs on uncommon hardware, and the former is what we need to track them and overall quality. A HUGE problem I have with current "efforts", is that once someone reports a bug, the onus seems to be 99% on the *reporter* to find the exact line of code or commit. Ghad what a repressive method. And if the "developer" who broke the damn thing, or who at least "claims" to be supporting that code, cannot "reproduce" the bug, they drop it completely. Contrast that flawed approach with how Linus does things.. he thinks through the symptoms, matches them to the code, and figures out what the few possibilities might be, and feeds back some trial balloon patches for the bug reporter to try. MUCH better. Linus also asks for a git bisect, but doesn't insist upon the reporter learning an entire new (poorly documented) toolset just to to report a bug. Blah! And remember, *I'm* an old-time Linux kernel developer.. just think about the people reporting bugs who haven't been around here since 1992.. -ml ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 14:08 ` Mark Lord @ 2007-11-13 15:24 ` Giacomo A. Catenazzi 2007-11-13 15:57 ` Ray Lee 2007-11-13 15:52 ` Benoit Boissinot ` (3 subsequent siblings) 4 siblings, 1 reply; 268+ messages in thread From: Giacomo A. Catenazzi @ 2007-11-13 15:24 UTC (permalink / raw) To: Mark Lord Cc: Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon Mark Lord wrote: > Ingo Molnar wrote: > .. >> This is all QA-101 that _cannot be argued against on a rational >> basis_, it's just that these sorts of things have been largely ignored >> for years, in favor of the all-too-easy "open source means many >> eyeballs and that is our QA" answer, which is a _good_ answer but by >> far not the most intelligent answer! Today "many eyeballs" is simply >> not good enough and nature (and other OS projects) will route us >> around if we dont change. > .. > > QA-101 and "many eyeballs" are not at all in opposition. > The latter is how we find out about bugs on uncommon hardware, > and the former is what we need to track them and overall quality. > > A HUGE problem I have with current "efforts", is that once someone > reports a bug, the onus seems to be 99% on the *reporter* to find > the exact line of code or commit. Ghad what a repressive method. As a long time kernel tester, I see some problem with the newer "new development model". In the short merge windows, after to much time, there are to many patches. So there are problem to bisect bugs, and to have attention of developers. My impression is that in a week there are many more messages in lkml and to much bugs to be handled in these few days. I've two proposal: - better patch quality. I would like that every commit would compile. So an automatic commit test and public blames could increase the quality of first commits. [bisecting with non compilable point it is not a trivial task] - a slow down the patch inclusion on the merge windows (aka: not to much big changes in the first days). As tester I prefer that some big changes would be included in a "secondary window" (pre o rc release), in an other period as the big patch rush. ciao cate ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 15:24 ` Giacomo A. Catenazzi @ 2007-11-13 15:57 ` Ray Lee 2007-11-13 17:01 ` Adrian Bunk 0 siblings, 1 reply; 268+ messages in thread From: Ray Lee @ 2007-11-13 15:57 UTC (permalink / raw) To: Giacomo A. Catenazzi Cc: Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Nov 13, 2007 7:24 AM, Giacomo A. Catenazzi <cate@cateee.net> wrote: > As a long time kernel tester, I see some problem with the > newer "new development model". In the short merge windows, > after to much time, there are to many patches. I think the root issue there is that it's hard to get all testers to run a bisect, but easy to ask them to test snapshots. Right now the snapshots are generated nightly, but I think it would make more sense if they were generated every N patches, for some value of N... Of course, for that to really work, we have to ensure that the result is always compilable, which has been getting better, but not perfect. Ray ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 15:57 ` Ray Lee @ 2007-11-13 17:01 ` Adrian Bunk 2007-11-13 17:50 ` Romano Giannetti 0 siblings, 1 reply; 268+ messages in thread From: Adrian Bunk @ 2007-11-13 17:01 UTC (permalink / raw) To: Ray Lee Cc: Giacomo A. Catenazzi, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tue, Nov 13, 2007 at 07:57:54AM -0800, Ray Lee wrote: > On Nov 13, 2007 7:24 AM, Giacomo A. Catenazzi <cate@cateee.net> wrote: > > As a long time kernel tester, I see some problem with the > > newer "new development model". In the short merge windows, > > after to much time, there are to many patches. > > I think the root issue there is that it's hard to get all testers to > run a bisect, but easy to ask them to test snapshots. Right now the > snapshots are generated nightly, but I think it would make more sense > if they were generated every N patches, for some value of N... >... I don't see a point in doing that - that would be a more manual bisecting, and the result would not be one guilty commit. Testers are not expected to be able to hack a kernel, but it's reasonable to expect testers to be able to build their own kernels (and your proposal wouldn't change that). The small instruction below is enough for everyone who is able to build his own kernel to do a git bisect. > Ray cu Adrian <-- snip --> # install git # clone Linus' tree: git clone \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git # start bisecting: cd linux-2.6 git bisect start git bisect bad v2.6.21 git bisect good v2.6.20 cp /path/to/.config . # start a round make oldconfig make # install kernel, check whether it's good or bad, then: git bisect [bad|good] # start next round After at about 10-15 reboots you'll have found the guilty commit ("... is first bad commit"). More information on git bisecting: man git-bisect ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 17:01 ` Adrian Bunk @ 2007-11-13 17:50 ` Romano Giannetti 2007-11-13 22:03 ` Frans Pop 0 siblings, 1 reply; 268+ messages in thread From: Romano Giannetti @ 2007-11-13 17:50 UTC (permalink / raw) To: Adrian Bunk Cc: Ray Lee, Giacomo A. Catenazzi, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon I jump in this discussion hoping to have some more insight on git and to report my experience as a tester. I consider myself as half-literate in this (I am here since 1991, more or less, and I am able to compile a kernel and even hand-apply a patch, although I am in no way a kernel programmer). On Tue, 2007-11-13 at 18:01 +0100, Adrian Bunk wrote: > The small instruction below is enough for everyone who is able to > build his own kernel to do a git bisect. > # start bisecting: > cd linux-2.6 > git bisect start > git bisect bad v2.6.21 > git bisect good v2.6.20 > cp /path/to/.config . > This was what I did in my (in the end almost successful) bisecting when trying to find the mmc problem (see the thread named "2.6.24-rc1 eat my SD card"). This is true in theory, but it has some problem. The "this commit does not compile is the easiest and in man git-bisect it's explained how to solve it. The changes in .config options, added or removed, are another problem when jumping back and forth from version (I was bitten by the gadzillions new options added to hda-intel alsa driver, but well, that is solvable with a bit of attention). The main problem I had, and that stopped me to arrive to a definite is this situation: j version-bad i h g unrelated (but similar) bug corrected f e d unrelated (but similar) bug introduced c b a version-good (d was the series to change drivers to use sg helpers, and g was a "fix fallout from sg helpers" patch). Now I have a series of kernels (d, e, f) that did not work at all and so I cannot mark them good or bad. With the number of patches added in the free-for-all week, this is a very probable scenario. There is a way out from this using bisect? Romano PS as a suggestion, I think that added a "Reported-by", or "Tested-by", or "Debugged-by" attribution in the repository, as happened to be in the MMC case, is a nice an d welcomed reward for the effort. -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 17:50 ` Romano Giannetti @ 2007-11-13 22:03 ` Frans Pop 0 siblings, 0 replies; 268+ messages in thread From: Frans Pop @ 2007-11-13 22:03 UTC (permalink / raw) To: Romano Giannetti Cc: akpm, alsa-devel, bugme-daemon, bunk, cate, davem, liml, linux-ide, linux-input, linux-kernel, linux-pcmcia, mingo, netdev, protasnb, ray-lk Romano Giannetti wrote: > This was what I did in my (in the end almost successful) bisecting when > trying to find the mmc problem (see the thread named "2.6.24-rc1 eat my > SD card"). This is true in theory, but it has some problem. The "this > commit does not compile is the easiest and in man git-bisect it's > explained how to solve it. The changes in .config options, added or > removed, are another problem when jumping back and forth from version. > > The main problem I had, and that stopped me to arrive to a definite is > this situation: [...] > (d was the series to change drivers to use sg helpers, and g was a "fix > fallout from sg helpers" patch). Now I have a series of kernels (d, e, > f) that did not work at all and so I cannot mark them good or bad. With > the number of patches added in the free-for-all week, this is a very > probable scenario. There is a way out from this using bisect? I think there are three strategies you can use in this case: - create a kernel config that is as simple as possible, but still supports your hardware and reproduces your problem; a simpler config will often avoid compilation issues in parts of the kernel that you're not using anyway and has the benefit of speeding up the compiles too - if you know/suspect in what part of the tree the bug is, first limit the bisection to that; you will have to verify that you did indeed find the correct (broken) change by doing a compile for the "last good commit + 1" - if you find a broken commit, use 'git-reset --hard' to try to jump past the bad set of commits, but of course that does not help in the case: g version-bad f unrelated bug corrected e d the broken commit that caused your problem c b unrelated bug that breaks compilation or system introduced a version-good in that case the best you can reasonably be expected to do is report that you narrowed it down to "between a and g" and leave the rest to the developers Cheers, FJP ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 14:08 ` Mark Lord 2007-11-13 15:24 ` Giacomo A. Catenazzi @ 2007-11-13 15:52 ` Benoit Boissinot 2007-11-13 16:49 ` Ingo Molnar 2007-11-13 17:13 ` Theodore Tso 2007-11-13 16:46 ` Ingo Molnar ` (2 subsequent siblings) 4 siblings, 2 replies; 268+ messages in thread From: Benoit Boissinot @ 2007-11-13 15:52 UTC (permalink / raw) To: Mark Lord Cc: Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Nov 13, 2007 3:08 PM, Mark Lord <liml@rtr.ca> wrote: > > Ingo Molnar wrote: > .. > > This is all QA-101 that _cannot be argued against on a rational basis_, > > it's just that these sorts of things have been largely ignored for > > years, in favor of the all-too-easy "open source means many eyeballs and > > that is our QA" answer, which is a _good_ answer but by far not the most > > intelligent answer! Today "many eyeballs" is simply not good enough and > > nature (and other OS projects) will route us around if we dont change. > .. > > QA-101 and "many eyeballs" are not at all in opposition. > The latter is how we find out about bugs on uncommon hardware, > and the former is what we need to track them and overall quality. > > A HUGE problem I have with current "efforts", is that once someone > reports a bug, the onus seems to be 99% on the *reporter* to find > the exact line of code or commit. Ghad what a repressive method. > Btw, I used to test every -mm kernel. But since I've switched distros (gentoo->ubuntu) and I have less time, I feel it's harder to test -rc or -mm kernels (I know this isn't a lkml problem but more a distro problem, but I would love having an ubuntu blessed repo with current dev kernel for the latest stable ubuntu release). For debugging, maybe it's time someone does an amazon ec2+s3 service to automate the bisecting and create .deb/.rpm from git, I don't know how much it would cost though. regards, Benoit ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 15:52 ` Benoit Boissinot @ 2007-11-13 16:49 ` Ingo Molnar 2007-11-13 17:13 ` Theodore Tso 1 sibling, 0 replies; 268+ messages in thread From: Ingo Molnar @ 2007-11-13 16:49 UTC (permalink / raw) To: Benoit Boissinot Cc: Mark Lord, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon * Benoit Boissinot <bboissin@gmail.com> wrote: > For debugging, maybe it's time someone does an amazon ec2+s3 service > to automate the bisecting and create .deb/.rpm from git, I don't know > how much it would cost though. a few months ago i estimated the costs of this and it's just a few terabytes so within arm's reach. As long as the .deb/.rpm's are built by tracking -git in a rolling fashion CPU time should not be a big issue. The only limit is download bandwidth - but even that problem might be solvable via a huge git repository of ready-to-boot .o's that are linked together on the tester's machine. Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 15:52 ` Benoit Boissinot 2007-11-13 16:49 ` Ingo Molnar @ 2007-11-13 17:13 ` Theodore Tso 2007-11-13 17:30 ` Alan Cox ` (3 more replies) 1 sibling, 4 replies; 268+ messages in thread From: Theodore Tso @ 2007-11-13 17:13 UTC (permalink / raw) To: Benoit Boissinot Cc: Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tue, Nov 13, 2007 at 04:52:32PM +0100, Benoit Boissinot wrote: > Btw, I used to test every -mm kernel. But since I've switched distros > (gentoo->ubuntu) > and I have less time, I feel it's harder to test -rc or -mm kernels (I > know this isn't a lkml problem > but more a distro problem, but I would love having an ubuntu blessed > repo with current dev kernel > for the latest stable ubuntu release). There are two parts to this. One is a Ubuntu development kernel which we can give to large numbers of people to expand our testing pool. But if we don't do a better job of responding to bug reports that would be generated by expanded testing this won't necessarily help us. The other an automated set of standard pre-built bisection points so that testers can more easily localize a bug down to a few hundred commits without needing to learn how to use "git bisect" (think Ubuntu users). So for the first, I've actually been playing with some plans to put together an unofficial kernel that basically "what Ted is using on his laptop". It generally has emergency bug fixes that haven't made it into mainline, plus some other trees where I've been more aggressive since I want to latest in wireless and powersaving technology, etc. It has the property that "if it breaks, you get to keep both pieces --- and I've helpfully included the git ID in the package name so you can do the bisection yourself". If you want to try it, the first such kernel is here: http://www.kernel.org/~tytso/tbek I wasn't planning on talking about it until it was more fully baked, but if people want something vaguely stable based on 2.6.24-rc2, this might be interesting. As for the second, I was just talking to Arjan over pizza and beer last night, and we reached the same conclusion as Ingo, which is this really isn't that hard. It wouldn't be that hard to set up infrastructure to do this, and it's just a matter of getting the disk space and the network bandwidth togehter in the right place, plus a relatively small amount of prgramming at least for the simplest iteration of the idea. (As is quite common when doing designs over beer, we talked about some more gradious web-based schemes to do custom built kernels that was tied to the kernel bugzilla, but first things first. :-) - Ted ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 17:13 ` Theodore Tso @ 2007-11-13 17:30 ` Alan Cox 2007-11-13 17:33 ` Larry Finger ` (2 subsequent siblings) 3 siblings, 0 replies; 268+ messages in thread From: Alan Cox @ 2007-11-13 17:30 UTC (permalink / raw) To: Theodore Tso Cc: Benoit Boissinot, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon > The other an automated set of standard pre-built bisection points so > that testers can more easily localize a bug down to a few hundred > commits without needing to learn how to use "git bisect" (think Ubuntu > users). Before that you want a flowchart or instruction list of boot options to try. A lot of errors can be localised simply by asking the reported to boot with things like "iommu=off", "pci=routeirq", "apci=off" etc That takes a lot less time to run through and can be very informative. Alan ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 17:13 ` Theodore Tso 2007-11-13 17:30 ` Alan Cox @ 2007-11-13 17:33 ` Larry Finger 2007-11-13 18:55 ` Theodore Tso 2007-11-13 17:56 ` Adrian Bunk 2007-11-14 23:23 ` Daniel Barkalow 3 siblings, 1 reply; 268+ messages in thread From: Larry Finger @ 2007-11-13 17:33 UTC (permalink / raw) To: Theodore Tso, Benoit Boissinot, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon Theodore Tso wrote: > On Tue, Nov 13, 2007 at 04:52:32PM +0100, Benoit Boissinot wrote: >> Btw, I used to test every -mm kernel. But since I've switched distros >> (gentoo->ubuntu) >> and I have less time, I feel it's harder to test -rc or -mm kernels (I >> know this isn't a lkml problem >> but more a distro problem, but I would love having an ubuntu blessed >> repo with current dev kernel >> for the latest stable ubuntu release). > > There are two parts to this. One is a Ubuntu development kernel which > we can give to large numbers of people to expand our testing pool. > But if we don't do a better job of responding to bug reports that > would be generated by expanded testing this won't necessarily help us. I'm very encouraged to read of your expanded testing efforts. As a bcm43xx developer, Ubuntu has been our problem distro, mostly because your standard kernels have debugging turned off for bcm43xx. When a Ubuntu user reports a problem and we ask for the relevant output from dmesg, they have no information. I ask two things of all distros: (1) Turn on debugging - we don't spam the logs that badly, and (2) forward any bugs found by your testing to the maintainer, and/or the bcm43xx mailing list. Thanks, Larry ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 17:33 ` Larry Finger @ 2007-11-13 18:55 ` Theodore Tso 2007-11-13 20:07 ` Larry Finger 0 siblings, 1 reply; 268+ messages in thread From: Theodore Tso @ 2007-11-13 18:55 UTC (permalink / raw) To: Larry Finger Cc: Benoit Boissinot, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tue, Nov 13, 2007 at 11:33:44AM -0600, Larry Finger wrote: > I'm very encouraged to read of your expanded testing efforts. As a > bcm43xx developer, Ubuntu has been our problem distro, mostly > because your standard kernels have debugging turned off for bcm43xx. > When a Ubuntu user reports a problem and we ask for the relevant > output from dmesg, they have no information. I ask two things of all > distros: (1) Turn on debugging - we don't spam the logs that badly, > and (2) forward any bugs found by your testing to the maintainer, > and/or the bcm43xx mailing list. Heh. I hadn't enabled CONFIG_BCM43XX_DEBUG myself, but I just changed it for my next kernel build. This is a slightly different issue, which is that sometimes _DEBUG options shouldn't be turned on by default (because they really trash performance and bloat log size), and sometimes they are painless to turn on and don't cost much. If that is the case, I'd suggest removing the option and just making it compiled in by default with a run-time option to enable it. - Ted ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 18:55 ` Theodore Tso @ 2007-11-13 20:07 ` Larry Finger 0 siblings, 0 replies; 268+ messages in thread From: Larry Finger @ 2007-11-13 20:07 UTC (permalink / raw) To: Theodore Tso, Larry Finger, Benoit Boissinot, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon Theodore Tso wrote: > > Heh. I hadn't enabled CONFIG_BCM43XX_DEBUG myself, but I just changed > it for my next kernel build. This is a slightly different issue, > which is that sometimes _DEBUG options shouldn't be turned on by > default (because they really trash performance and bloat log size), > and sometimes they are painless to turn on and don't cost much. > > If that is the case, I'd suggest removing the option and just making > it compiled in by default with a run-time option to enable it. I am taking your suggestion and will produce the necessary patches for ssb, b43 and b43legacy. As bcm43xx is likely to be removed from 2.6.25, which is the earliest such a non-bug fix patch would be accepted, I hope that your future distribution and testing kernels will include the debug option. Thanks, Larry ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 17:13 ` Theodore Tso 2007-11-13 17:30 ` Alan Cox 2007-11-13 17:33 ` Larry Finger @ 2007-11-13 17:56 ` Adrian Bunk 2007-11-13 18:57 ` Gabriel C ` (2 more replies) 2007-11-14 23:23 ` Daniel Barkalow 3 siblings, 3 replies; 268+ messages in thread From: Adrian Bunk @ 2007-11-13 17:56 UTC (permalink / raw) To: Theodore Tso, Benoit Boissinot, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tue, Nov 13, 2007 at 12:13:56PM -0500, Theodore Tso wrote: > On Tue, Nov 13, 2007 at 04:52:32PM +0100, Benoit Boissinot wrote: > > Btw, I used to test every -mm kernel. But since I've switched distros > > (gentoo->ubuntu) > > and I have less time, I feel it's harder to test -rc or -mm kernels (I > > know this isn't a lkml problem > > but more a distro problem, but I would love having an ubuntu blessed > > repo with current dev kernel > > for the latest stable ubuntu release). > > There are two parts to this. One is a Ubuntu development kernel which > we can give to large numbers of people to expand our testing pool. > But if we don't do a better job of responding to bug reports that > would be generated by expanded testing this won't necessarily help us. >... The main problem aren't missing testers [1] - we already have relatively experienced people testing kernels and/or reporting bugs, and we slowly scare them away due to the many bug reports without any reaction. The main problem is finding experienced developers who spend time on looking into bug reports. Getting many relatively unexperienced users (who need more guidance for debugging issues) as additional testers is therefore IMHO not necessarily a good idea. > - Ted cu Adrian [1] and e.g. when Greg says he has a few hundred people who want to write drivers it would most likely be possible to find a few dozen additional -rc testers among them -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 17:56 ` Adrian Bunk @ 2007-11-13 18:57 ` Gabriel C 2007-11-14 0:41 ` Denys Vlasenko 2007-11-14 0:39 ` Denys Vlasenko 2007-11-14 16:55 ` Jan Evert van Grootheest 2 siblings, 1 reply; 268+ messages in thread From: Gabriel C @ 2007-11-13 18:57 UTC (permalink / raw) To: Adrian Bunk Cc: Theodore Tso, Benoit Boissinot, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon Adrian Bunk wrote: > On Tue, Nov 13, 2007 at 12:13:56PM -0500, Theodore Tso wrote: >> On Tue, Nov 13, 2007 at 04:52:32PM +0100, Benoit Boissinot wrote: >>> Btw, I used to test every -mm kernel. But since I've switched distros >>> (gentoo->ubuntu) >>> and I have less time, I feel it's harder to test -rc or -mm kernels (I >>> know this isn't a lkml problem >>> but more a distro problem, but I would love having an ubuntu blessed >>> repo with current dev kernel >>> for the latest stable ubuntu release). >> There are two parts to this. One is a Ubuntu development kernel which >> we can give to large numbers of people to expand our testing pool. >> But if we don't do a better job of responding to bug reports that >> would be generated by expanded testing this won't necessarily help us. >> ... > > The main problem is finding experienced developers who spend time on > looking into bug reports. There are already. IMO the problem is the development model. There are tons new features in each new kernel release and 'tons new bugs' which are not fixed during the release cycle nor in the .XX stable kernels. Maybe after XX kernel releases there should be one just with bug-fixes _without_ any new features , eg: cleaning bugs from bugzilla , know regressions , cleaning up code , removing broken drivers and the like. > cu > Adrian Gabriel ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 18:57 ` Gabriel C @ 2007-11-14 0:41 ` Denys Vlasenko 0 siblings, 0 replies; 268+ messages in thread From: Denys Vlasenko @ 2007-11-14 0:41 UTC (permalink / raw) To: Gabriel C Cc: Adrian Bunk, Theodore Tso, Benoit Boissinot, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tuesday 13 November 2007 11:57, Gabriel C wrote: > > The main problem is finding experienced developers who spend time on > > looking into bug reports. > > There are already. IMO the problem is the development model. > > There are tons new features in each new kernel release and 'tons new bugs' > which are not fixed during the release cycle nor in the .XX stable kernels. > > Maybe after XX kernel releases there should be one just with bug-fixes > _without_ any new features , eg: cleaning bugs from bugzilla , know > regressions , cleaning up code , removing broken drivers and the like. Won't work. You cannot force people to work on things they don't find interesting, long-term. -- vda ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 17:56 ` Adrian Bunk 2007-11-13 18:57 ` Gabriel C @ 2007-11-14 0:39 ` Denys Vlasenko 2007-11-14 7:27 ` Adrian Bunk 2007-11-14 16:55 ` Jan Evert van Grootheest 2 siblings, 1 reply; 268+ messages in thread From: Denys Vlasenko @ 2007-11-14 0:39 UTC (permalink / raw) To: Adrian Bunk Cc: Theodore Tso, Benoit Boissinot, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tuesday 13 November 2007 10:56, Adrian Bunk wrote: > On Tue, Nov 13, 2007 at 12:13:56PM -0500, Theodore Tso wrote: > > On Tue, Nov 13, 2007 at 04:52:32PM +0100, Benoit Boissinot wrote: > > > Btw, I used to test every -mm kernel. But since I've switched distros > > > (gentoo->ubuntu) > > > and I have less time, I feel it's harder to test -rc or -mm kernels (I > > > know this isn't a lkml problem > > > but more a distro problem, but I would love having an ubuntu blessed > > > repo with current dev kernel > > > for the latest stable ubuntu release). > > > > There are two parts to this. One is a Ubuntu development kernel which > > we can give to large numbers of people to expand our testing pool. > > But if we don't do a better job of responding to bug reports that > > would be generated by expanded testing this won't necessarily help us. > >... > > The main problem aren't missing testers [1] - we already have relatively > experienced people testing kernels and/or reporting bugs, and we slowly > scare them away due to the many bug reports without any reaction. > > The main problem is finding experienced developers who spend time on > looking into bug reports. > > Getting many relatively unexperienced users (who need more guidance for > debugging issues) as additional testers is therefore IMHO not > necessarily a good idea. And where experienced developrs are coming from? They are not born with Linux kernel skills. They grow up from within user base. Bigger user base -> more developers (eventually) -- vda ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 0:39 ` Denys Vlasenko @ 2007-11-14 7:27 ` Adrian Bunk 2007-11-14 7:46 ` Denys Vlasenko 0 siblings, 1 reply; 268+ messages in thread From: Adrian Bunk @ 2007-11-14 7:27 UTC (permalink / raw) To: Denys Vlasenko Cc: Theodore Tso, Benoit Boissinot, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tue, Nov 13, 2007 at 05:39:45PM -0700, Denys Vlasenko wrote: > On Tuesday 13 November 2007 10:56, Adrian Bunk wrote: > > On Tue, Nov 13, 2007 at 12:13:56PM -0500, Theodore Tso wrote: > > > On Tue, Nov 13, 2007 at 04:52:32PM +0100, Benoit Boissinot wrote: > > > > Btw, I used to test every -mm kernel. But since I've switched distros > > > > (gentoo->ubuntu) > > > > and I have less time, I feel it's harder to test -rc or -mm kernels (I > > > > know this isn't a lkml problem > > > > but more a distro problem, but I would love having an ubuntu blessed > > > > repo with current dev kernel > > > > for the latest stable ubuntu release). > > > > > > There are two parts to this. One is a Ubuntu development kernel which > > > we can give to large numbers of people to expand our testing pool. > > > But if we don't do a better job of responding to bug reports that > > > would be generated by expanded testing this won't necessarily help us. > > >... > > > > The main problem aren't missing testers [1] - we already have relatively > > experienced people testing kernels and/or reporting bugs, and we slowly > > scare them away due to the many bug reports without any reaction. > > > > The main problem is finding experienced developers who spend time on > > looking into bug reports. > > > > Getting many relatively unexperienced users (who need more guidance for > > debugging issues) as additional testers is therefore IMHO not > > necessarily a good idea. > > And where experienced developrs are coming from? > They are not born with Linux kernel skills. > They grow up from within user base. > > Bigger user base -> more developers (eventually) You missed the following in my email: "we slowly scare them away due to the many bug reports without any reaction." The problem is that bug reports take time. If you go away from easy things like compile errors then even things like describing what does no longer work, ideally producing a scenario where you can reproduce it and verifying whether it was present in previous kernels can easily take many hours that are spent before the initial bug report. If the bug report then gets ignored we discourage the person who sent the bug report to do any work related to the kernel again. > vda cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 7:27 ` Adrian Bunk @ 2007-11-14 7:46 ` Denys Vlasenko 2007-11-14 13:30 ` Matthew Wilcox 2007-11-14 18:27 ` Kok, Auke 0 siblings, 2 replies; 268+ messages in thread From: Denys Vlasenko @ 2007-11-14 7:46 UTC (permalink / raw) To: Adrian Bunk Cc: Theodore Tso, Benoit Boissinot, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Wednesday 14 November 2007 00:27, Adrian Bunk wrote: > You missed the following in my email: > "we slowly scare them away due to the many bug reports without any > reaction." > > The problem is that bug reports take time. If you go away from easy > things like compile errors then even things like describing what does > no longer work, ideally producing a scenario where you can reproduce it > and verifying whether it was present in previous kernels can easily take > many hours that are spent before the initial bug report. > > If the bug report then gets ignored we discourage the person who sent > the bug report to do any work related to the kernel again. Cannot agree more. I am in a similar position right now. My patch to aic7xxx driver was ubmitted four times with not much reaction from scsi guys. Finally they replied and asked to rediff it against their git tree. I did that and sent patches back. No reply since then. And mind you, the patch is not trying to do anything complex, it mostly moves code around, removes 'inline', adds 'const'. What should I think about it? -- vda ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 7:46 ` Denys Vlasenko @ 2007-11-14 13:30 ` Matthew Wilcox 2007-11-14 13:35 ` Hannes Reinecke 2007-11-14 18:27 ` Kok, Auke 1 sibling, 1 reply; 268+ messages in thread From: Matthew Wilcox @ 2007-11-14 13:30 UTC (permalink / raw) To: Denys Vlasenko Cc: Adrian Bunk, alsa-devel, Theodore Tso, Andrew Morton, netdev, bugme-daemon, linux-pcmcia, linux-kernel, protasnb, linux-ide, Benoit Boissinot, Mark Lord, linux-input, Ingo Molnar, David Miller, Hannes Reinecke On Wed, Nov 14, 2007 at 12:46:20AM -0700, Denys Vlasenko wrote: > Finally they replied and asked to rediff it against their > git tree. I did that and sent patches back. No reply since then. > > And mind you, the patch is not trying to do anything > complex, it mostly moves code around, removes 'inline', > adds 'const'. What should I think about it? I'm waiting for an ACK/NAK from Hannes, the maintainer. What should I do? -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 13:30 ` Matthew Wilcox @ 2007-11-14 13:35 ` Hannes Reinecke 2007-11-14 21:39 ` Denys Vlasenko 0 siblings, 1 reply; 268+ messages in thread From: Hannes Reinecke @ 2007-11-14 13:35 UTC (permalink / raw) To: Matthew Wilcox Cc: Denys Vlasenko, Adrian Bunk, alsa-devel, Theodore Tso, Andrew Morton, netdev, bugme-daemon, linux-pcmcia, linux-kernel, protasnb, linux-ide, Benoit Boissinot, Mark Lord, linux-input, Ingo Molnar, David Miller Matthew Wilcox wrote: > On Wed, Nov 14, 2007 at 12:46:20AM -0700, Denys Vlasenko wrote: >> Finally they replied and asked to rediff it against their >> git tree. I did that and sent patches back. No reply since then. >> >> And mind you, the patch is not trying to do anything >> complex, it mostly moves code around, removes 'inline', >> adds 'const'. What should I think about it? > > I'm waiting for an ACK/NAK from Hannes, the maintainer. What should I > do? > I haven't actually been able to test it here (too busy, sorry). If someone else confirms it does it's job then Acked-by: Hannes Reinecke <hare@suse.de> Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 13:35 ` Hannes Reinecke @ 2007-11-14 21:39 ` Denys Vlasenko 2007-11-14 21:58 ` Gabriel C 0 siblings, 1 reply; 268+ messages in thread From: Denys Vlasenko @ 2007-11-14 21:39 UTC (permalink / raw) To: Hannes Reinecke, Matthew Wilcox Cc: Adrian Bunk, Theodore Tso, Andrew Morton, linux-kernel, protasnb, linux-ide, Benoit Boissinot, Mark Lord, Ingo Molnar, David Miller hi Matthew, On Wednesday 14 November 2007 06:35, Hannes Reinecke wrote: > Matthew Wilcox wrote: > > On Wed, Nov 14, 2007 at 12:46:20AM -0700, Denys Vlasenko wrote: > >> Finally they replied and asked to rediff it against their > >> git tree. I did that and sent patches back. No reply since then. > >> > >> And mind you, the patch is not trying to do anything > >> complex, it mostly moves code around, removes 'inline', > >> adds 'const'. What should I think about it? > > > > I'm waiting for an ACK/NAK from Hannes, the maintainer. What should I > > do? You could have informed me about this, and I would talk to Hannes myself. This would free up your mind from keeping track of this particular patch. Parallelize development, prevent things from being forgotten. Hi Hannes, > I haven't actually been able to test it here (too busy, sorry). If someone > else confirms it does it's job then > > Acked-by: Hannes Reinecke <hare@suse.de> It's not in my mailbox on this machine, gladly we have lkml archived in the Net. Here is a positive tester report: http://lkml.org/lkml/2007/10/15/168: ====================== Date Mon, 15 Oct 2007 15:53:08 +0200 From Gabriel C <> Subject Re: [PATCH 0/3] debloat aic7xxx and aic79xx drivers >> Compile tested and applies cleanly to 2.6.23. >> I don't have this hardware anymore and cannot run test these patches. > > I can test these patches on an aic7892 controller later on today if you want. Works fine for me tested on : 03:0e.0 SCSI storage controller [0100]: Adaptec AIC-7892P U160/m [9005:008f] (rev 02) Gabriel ======================= -- vda ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 21:39 ` Denys Vlasenko @ 2007-11-14 21:58 ` Gabriel C 0 siblings, 0 replies; 268+ messages in thread From: Gabriel C @ 2007-11-14 21:58 UTC (permalink / raw) To: Denys Vlasenko Cc: Hannes Reinecke, Matthew Wilcox, Adrian Bunk, Theodore Tso, Andrew Morton, linux-kernel, protasnb, linux-ide, Benoit Boissinot, Mark Lord, Ingo Molnar, David Miller Denys Vlasenko wrote: > hi Matthew, > > On Wednesday 14 November 2007 06:35, Hannes Reinecke wrote: >> Matthew Wilcox wrote: >>> On Wed, Nov 14, 2007 at 12:46:20AM -0700, Denys Vlasenko wrote: >>>> Finally they replied and asked to rediff it against their >>>> git tree. I did that and sent patches back. No reply since then. >>>> >>>> And mind you, the patch is not trying to do anything >>>> complex, it mostly moves code around, removes 'inline', >>>> adds 'const'. What should I think about it? >>> I'm waiting for an ACK/NAK from Hannes, the maintainer. What should I >>> do? > > You could have informed me about this, and I would talk to Hannes > myself. This would free up your mind from keeping track of this > particular patch. > Parallelize development, prevent things from being forgotten. > > > Hi Hannes, > >> I haven't actually been able to test it here (too busy, sorry). If someone >> else confirms it does it's job then >> >> Acked-by: Hannes Reinecke <hare@suse.de> > > It's not in my mailbox on this machine, gladly we have lkml archived > in the Net. Here is a positive tester report: > > http://lkml.org/lkml/2007/10/15/168: > > ====================== > Date Mon, 15 Oct 2007 15:53:08 +0200 > From Gabriel C <> > Subject Re: [PATCH 0/3] debloat aic7xxx and aic79xx drivers > >>> Compile tested and applies cleanly to 2.6.23. >>> I don't have this hardware anymore and cannot run test these patches. >> I can test these patches on an aic7892 controller later on today if you > want. > > Works fine for me tested on : > > 03:0e.0 SCSI storage controller [0100]: Adaptec AIC-7892P U160/m [9005:008f] > (rev 02) > > Gabriel > ======================= I still run the patches on a box with 2.6.23 and one with 2.6.24-rc1 without any problems. Didn't tested rc2/current git but I can if is needed. If you need an Tested-by.. let me know. > > -- > vda Gabriel ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 7:46 ` Denys Vlasenko 2007-11-14 13:30 ` Matthew Wilcox @ 2007-11-14 18:27 ` Kok, Auke 1 sibling, 0 replies; 268+ messages in thread From: Kok, Auke @ 2007-11-14 18:27 UTC (permalink / raw) To: Denys Vlasenko Cc: Adrian Bunk, Theodore Tso, Benoit Boissinot, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon Denys Vlasenko wrote: > On Wednesday 14 November 2007 00:27, Adrian Bunk wrote: >> You missed the following in my email: >> "we slowly scare them away due to the many bug reports without any >> reaction." >> >> The problem is that bug reports take time. If you go away from easy >> things like compile errors then even things like describing what does >> no longer work, ideally producing a scenario where you can reproduce it >> and verifying whether it was present in previous kernels can easily take >> many hours that are spent before the initial bug report. >> >> If the bug report then gets ignored we discourage the person who sent >> the bug report to do any work related to the kernel again. > > Cannot agree more. I am in a similar position right now. > My patch to aic7xxx driver was ubmitted four times > with not much reaction from scsi guys. > > Finally they replied and asked to rediff it against their > git tree. I did that and sent patches back. No reply since then. > > And mind you, the patch is not trying to do anything > complex, it mostly moves code around, removes 'inline', > adds 'const'. What should I think about it? this has nothing to do with the bugs on bugzilla. you're trying to send a janitor patch. It should be logical that the response to that is not heated or receiving a joyous reception :) If you have a problem getting your cleanup patch to the driver maintainer, send it to the subsystem maintainer instead, or even the janitors, or even Adrian Bunk who will gladly push it to everyone. Or, even to Andrew Morton who will carry it in -mm for a while and then harrasses the subsystem maintainer to merge it for you! Cheers, Auke ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 17:56 ` Adrian Bunk 2007-11-13 18:57 ` Gabriel C 2007-11-14 0:39 ` Denys Vlasenko @ 2007-11-14 16:55 ` Jan Evert van Grootheest 2 siblings, 0 replies; 268+ messages in thread From: Jan Evert van Grootheest @ 2007-11-14 16:55 UTC (permalink / raw) To: Adrian Bunk Cc: Theodore Tso, Benoit Boissinot, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, ne Adrian Bunk wrote: > On Tue, Nov 13, 2007 at 12:13:56PM -0500, Theodore Tso wrote: > >> On Tue, Nov 13, 2007 at 04:52:32PM +0100, Benoit Boissinot wrote: >> >>> Btw, I used to test every -mm kernel. But since I've switched distros >>> (gentoo->ubuntu) >>> and I have less time, I feel it's harder to test -rc or -mm kernels (I >>> know this isn't a lkml problem >>> but more a distro problem, but I would love having an ubuntu blessed >>> repo with current dev kernel >>> for the latest stable ubuntu release). >>> >> There are two parts to this. One is a Ubuntu development kernel which >> we can give to large numbers of people to expand our testing pool. >> But if we don't do a better job of responding to bug reports that >> would be generated by expanded testing this won't necessarily help us. >> ... >> > > The main problem aren't missing testers [1] - we already have relatively > experienced people testing kernels and/or reporting bugs, and we slowly > scare them away due to the many bug reports without any reaction. > > The main problem is finding experienced developers who spend time on > looking into bug reports. > > Getting many relatively unexperienced users (who need more guidance for > debugging issues) as additional testers is therefore IMHO not > necessarily a good idea. > > [1] and e.g. when Greg says he has a few hundred people who want to > write drivers it would most likely be possible to find a few > dozen additional -rc testers among them > Hum. If only each of those would squash one bug a week besides their own work... I would expect he's got a handful that know IDE, another group that is into network drivers and so on. I predict that pile of bugs to disappear in weeks (-; Just my $0.02. Jan Evert ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 17:13 ` Theodore Tso ` (2 preceding siblings ...) 2007-11-13 17:56 ` Adrian Bunk @ 2007-11-14 23:23 ` Daniel Barkalow 2007-11-15 15:30 ` Theodore Tso 3 siblings, 1 reply; 268+ messages in thread From: Daniel Barkalow @ 2007-11-14 23:23 UTC (permalink / raw) To: Theodore Tso Cc: Benoit Boissinot, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tue, 13 Nov 2007, Theodore Tso wrote: > There are two parts to this. One is a Ubuntu development kernel which > we can give to large numbers of people to expand our testing pool. > But if we don't do a better job of responding to bug reports that > would be generated by expanded testing this won't necessarily help us. > > The other an automated set of standard pre-built bisection points so > that testers can more easily localize a bug down to a few hundred > commits without needing to learn how to use "git bisect" (think Ubuntu > users). I don't see any reason that we couldn't have a tool accessible to Ubuntu users that does a real "git bisect". Git is really good at being scripted by fancy GUIs. It should be easy enough to have a drop down with all of the Ubuntu kernel package releases, where the user selects what works and what doesn't. Then the tool clones a git repository with flags to only get relevant parts, and then leads a bisect run, where it's also configuring, building, and installing the kernels (as a different grub entry), and providing instructions in general. Fundamentally, "git bisect" is a really low-interaction process: you tell it a couple of commits, and then it does stuff, and then you tell it "I tested, and it worked" or "I tested, and it had the problem" or "Something else went wrong", and it asks you something new. Other than that, it just takes time (and a build system hook, which this tool would handle for the kernel). Eventually, it tells you what to report, and you do so. -Daniel *This .sig left intentionally blank* ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 23:23 ` Daniel Barkalow @ 2007-11-15 15:30 ` Theodore Tso 2007-11-15 16:19 ` Daniel Barkalow 0 siblings, 1 reply; 268+ messages in thread From: Theodore Tso @ 2007-11-15 15:30 UTC (permalink / raw) To: Daniel Barkalow Cc: Benoit Boissinot, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Wed, Nov 14, 2007 at 06:23:34PM -0500, Daniel Barkalow wrote: > I don't see any reason that we couldn't have a tool accessible to Ubuntu > users that does a real "git bisect". Git is really good at being scripted > by fancy GUIs. It should be easy enough to have a drop down with all of > the Ubuntu kernel package releases, where the user selects what works and > what doesn't. It's possible users who haven't yet downloaded a git repository have to surmount some obstacles that might cause them to lose interest. First, they have to download some 190 megs of git repository, and if they have a slow link, that can take a while, and then they have to build each kernel, which can take a while. A full kernel build with everything selected can take good 30 minutes or more, and that's on a fast dual-core machine with 4gigs of memory and 7200rpm disk drives. On a slower, memory limited laptop, doing a single kernel build can take more time than the user has patiences; multiply that by 7 or 8 build and test boots, and it starts to get tiresome. And then on top of that there are the issues about whether there is enough support for dealing with hitting kernel revisions that fail due to other bugs getting merged in during the -rc1 process, etc. I agree that a tool that automated the bisection process and walked the user through it would be helpful, but I believe it would be possible for us do better. - Ted ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-15 15:30 ` Theodore Tso @ 2007-11-15 16:19 ` Daniel Barkalow 2007-11-16 8:20 ` Romano Giannetti 0 siblings, 1 reply; 268+ messages in thread From: Daniel Barkalow @ 2007-11-15 16:19 UTC (permalink / raw) To: Theodore Tso Cc: Benoit Boissinot, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Thu, 15 Nov 2007, Theodore Tso wrote: > On Wed, Nov 14, 2007 at 06:23:34PM -0500, Daniel Barkalow wrote: > > I don't see any reason that we couldn't have a tool accessible to Ubuntu > > users that does a real "git bisect". Git is really good at being scripted > > by fancy GUIs. It should be easy enough to have a drop down with all of > > the Ubuntu kernel package releases, where the user selects what works and > > what doesn't. > > It's possible users who haven't yet downloaded a git repository have > to surmount some obstacles that might cause them to lose interest. > First, they have to download some 190 megs of git repository, and if > they have a slow link, that can take a while, and then they have to > build each kernel, which can take a while. It should be possible for it to clone only the portion that they actually care about based on where the known-good version is. It should also (in theory, anyway) be possible to put off some amount of the download until it's actually going to be relevant. > A full kernel build with everything selected can take good 30 minutes or > more, and that's on a fast dual-core machine with 4gigs of memory and > 7200rpm disk drives. On a slower, memory limited laptop, doing a single > kernel build can take more time than the user has patiences; multiply > that by 7 or 8 build and test boots, and it starts to get tiresome. None of this is going to take as long, even on a slow link and a slow computer, as waiting for a response to a mailing list post. It'd annoy users who are specifically waiting for it, but if the interface is that the user says "kernel package X didn't work but the current kernel does", and it says "I'll let you know when I've got something to test", and the user watches a DVD, and afterward finds a message saying there's something to test, and tries it, and reports how it went, and the process repeats until it narrows it down to a single commit after a couple of days of the user getting occasional responses, it's not that different from asking for help online. > And then on top of that there are the issues about whether there is > enough support for dealing with hitting kernel revisions that fail due > to other bugs getting merged in during the -rc1 process, etc. Could have a distro-provided mask of things that aren't worth testing and possibly back-ported fixes for revisions in particular ranges. > I agree that a tool that automated the bisection process and walked > the user through it would be helpful, but I believe it would be > possible for us do better. That would probably help for giving the user something to try right away. I still think that the main cost to the user is the number of times that the user has to stop doing stuff to reboot with a kernel to test, whether the test kernels are available quickly from the distro site, slowly built locally, or slowly as suggested by humans helping online. -Daniel *This .sig left intentionally blank* ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-15 16:19 ` Daniel Barkalow @ 2007-11-16 8:20 ` Romano Giannetti 2007-11-16 18:20 ` Daniel Barkalow 0 siblings, 1 reply; 268+ messages in thread From: Romano Giannetti @ 2007-11-16 8:20 UTC (permalink / raw) To: Daniel Barkalow Cc: Theodore Tso, Benoit Boissinot, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel (Cc: trimmed a bit). On Thu, 2007-11-15 at 11:19 -0500, Daniel Barkalow wrote: > On Thu, 15 Nov 2007, Theodore Tso wrote: [...] > > A full kernel build with everything selected can take good 30 minutes or > > more, and that's on a fast dual-core machine with 4gigs of memory and > > 7200rpm disk drives. On a slower, memory limited laptop, doing a single > > kernel build can take more time than the user has patiences; multiply > > that by 7 or 8 build and test boots, and it starts to get tiresome. > > None of this is going to take as long, Well, the compile phase can. Especially if the first time you try to compile the kernel with EXTRAVERSION=`git describe` which force almost a full rebuild every time... But the worst problem is that a full recompile, with a distro .config, will take hours on my 2.66GHz/CoreDuo/1G ram. Trimming down .config is fundamental to be able to bisect effectively, but it's not an easy thing to do for an unexperienced user (and a painful one for all the rest of us). What would be an invaluable help would be a tool that generates a .config with all the modules and subsystems I am using *now*. Should be possible in principle by parsing KConfig and Makefiles and using as input the current .config and lsmod... is it possible to map the kernel object name to the option enabling it? Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-16 8:20 ` Romano Giannetti @ 2007-11-16 18:20 ` Daniel Barkalow 2007-11-16 19:46 ` Theodore Tso 0 siblings, 1 reply; 268+ messages in thread From: Daniel Barkalow @ 2007-11-16 18:20 UTC (permalink / raw) To: Romano Giannetti Cc: Theodore Tso, Benoit Boissinot, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel On Fri, 16 Nov 2007, Romano Giannetti wrote: > > (Cc: trimmed a bit). > > On Thu, 2007-11-15 at 11:19 -0500, Daniel Barkalow wrote: > > On Thu, 15 Nov 2007, Theodore Tso wrote: > [...] > > > A full kernel build with everything selected can take good 30 minutes or > > > more, and that's on a fast dual-core machine with 4gigs of memory and > > > 7200rpm disk drives. On a slower, memory limited laptop, doing a single > > > kernel build can take more time than the user has patiences; multiply > > > that by 7 or 8 build and test boots, and it starts to get tiresome. > > > > None of this is going to take as long, > > Well, the compile phase can. Especially if the first time you try to > compile the kernel with EXTRAVERSION=`git describe` which force almost a > full rebuild every time... Compared to getting useful suggestions from a mailing list, especially before you've gotten anybody's attention? Hours or overnight isn't particularly long, and doesn't take up much of your time if you've got a working kernel to use while it's working. > But the worst problem is that a full recompile, with a distro .config, > will take hours on my 2.66GHz/CoreDuo/1G ram. Trimming down .config is > fundamental to be able to bisect effectively, but it's not an easy thing > to do for an unexperienced user (and a painful one for all the rest of > us). > > What would be an invaluable help would be a tool that generates > a .config with all the modules and subsystems I am using *now*. Should > be possible in principle by parsing KConfig and Makefiles and using as > input the current .config and lsmod... is it possible to map the kernel > object name to the option enabling it? I don't think there's anything set up for that, aside from the actual build system generating it, and I don't know how hard that would be to repurpose for generating a configuration. -Daniel *This .sig left intentionally blank* ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-16 18:20 ` Daniel Barkalow @ 2007-11-16 19:46 ` Theodore Tso 2007-11-17 12:20 ` Adrian Bunk 0 siblings, 1 reply; 268+ messages in thread From: Theodore Tso @ 2007-11-16 19:46 UTC (permalink / raw) To: Daniel Barkalow Cc: Romano Giannetti, Benoit Boissinot, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel On Fri, Nov 16, 2007 at 01:20:16PM -0500, Daniel Barkalow wrote: > Compared to getting useful suggestions from a mailing list, especially > before you've gotten anybody's attention? Hours or overnight isn't > particularly long, and doesn't take up much of your time if you've got a > working kernel to use while it's working. But a bisect takes around 7 compiles. And even when it takes only an hour, that's enough time for you to get started working on something else, and saving all of your context so you can at that point try booting into a kernel really is quite annoying. Hence the suggestion for a way for users to download commonly used snapshot points for bisect runs. Yes, it will require some central infrastructure, but if it allows for more distributed debugging, this would be a good thing. - Ted ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-16 19:46 ` Theodore Tso @ 2007-11-17 12:20 ` Adrian Bunk 2007-11-18 18:01 ` Theodore Tso 0 siblings, 1 reply; 268+ messages in thread From: Adrian Bunk @ 2007-11-17 12:20 UTC (permalink / raw) To: Theodore Tso, Daniel Barkalow, Romano Giannetti, Benoit Boissinot, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel On Fri, Nov 16, 2007 at 02:46:18PM -0500, Theodore Tso wrote: > On Fri, Nov 16, 2007 at 01:20:16PM -0500, Daniel Barkalow wrote: > > Compared to getting useful suggestions from a mailing list, especially > > before you've gotten anybody's attention? Hours or overnight isn't > > particularly long, and doesn't take up much of your time if you've got a > > working kernel to use while it's working. > > But a bisect takes around 7 compiles. >... I don't understand that number. The common case are regressions in -rc1, and a bisection of at about 7000 commits takes around 13 compiles. > - Ted cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-17 12:20 ` Adrian Bunk @ 2007-11-18 18:01 ` Theodore Tso 0 siblings, 0 replies; 268+ messages in thread From: Theodore Tso @ 2007-11-18 18:01 UTC (permalink / raw) To: Adrian Bunk Cc: Daniel Barkalow, Romano Giannetti, Benoit Boissinot, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel On Sat, Nov 17, 2007 at 01:20:10PM +0100, Adrian Bunk wrote: > > But a bisect takes around 7 compiles. > >... > > I don't understand that number. > > The common case are regressions in -rc1, and a bisection of > at about 7000 commits takes around 13 compiles. Worst case it would take 13. In practice I've seen less. Part of it is I suspect that I'm starting with something more recent than the previous 2.6.23, but rather a daily -git13 or -git14 tree. Part of it may be because git can sometimes be more efficient by cutting off entire branches with trail builds, since git history isn't completely linear, but rather pulls of various branches together. - Ted ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 14:08 ` Mark Lord 2007-11-13 15:24 ` Giacomo A. Catenazzi 2007-11-13 15:52 ` Benoit Boissinot @ 2007-11-13 16:46 ` Ingo Molnar 2007-11-13 17:50 ` Mark Lord 2007-11-13 19:37 ` [BUG] New Kernel Bugs Russell King 2007-11-14 0:34 ` Denys Vlasenko 4 siblings, 1 reply; 268+ messages in thread From: Ingo Molnar @ 2007-11-13 16:46 UTC (permalink / raw) To: Mark Lord Cc: Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon * Mark Lord <liml@rtr.ca> wrote: > Ingo Molnar wrote: > .. >> This is all QA-101 that _cannot be argued against on a rational basis_, >> it's just that these sorts of things have been largely ignored for years, >> in favor of the all-too-easy "open source means many eyeballs and that is >> our QA" answer, which is a _good_ answer but by far not the most >> intelligent answer! Today "many eyeballs" is simply not good enough and >> nature (and other OS projects) will route us around if we dont change. > .. > > QA-101 and "many eyeballs" are not at all in opposition. yes, absolutely so - that's why i used the "good" qualifier. "Good is not good enough" calls for additional efforts to make it more efficient, not for the abolition of the many eyeballs concept (which would be absurd). So what i wanted to say is that _sole_ reliance on the large numbers of eyeballs is a fundamental mistake. It's even sometimes used as an excuse to merge questionable stuff. "we'll find any bugs, many eyeballs will make bugs shallow". In reality the many eyeballs are not infinite, nor should they be taken for granted if they are used for bogus things. We have to make sure the eyeballs stay 'many', and we also have to make sure they are not wasted. It's a physical resource that must be intelligently handled. Its positive effects can be easily wasted and we do that today. for example git-bisect was godsent. I remember that years ago bisection of a bug was a very laborous task so that it was only used as a final, last-ditch approach for really nasty bugs. Today we can autonomouly bisect build bugs via a simple shell command around "git-bisect run", without any human interaction! This freed up testing resources enormously and made bisection one of the _first_ things that are tried when bugs are met. We just need more of this (distros should offer pre-built kernel rpm 'farms' for every important commit point and automated tools for users to easily specify breakage points, without them having to install those kernels individually) , and everyone should be aware of the fact that we still suck (we merge too much crap and still dont have good enough tools to de-crappify what we merge) and that we are losing testers. Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 16:46 ` Ingo Molnar @ 2007-11-13 17:50 ` Mark Lord 2007-11-13 18:12 ` Adrian Bunk ` (3 more replies) 0 siblings, 4 replies; 268+ messages in thread From: Mark Lord @ 2007-11-13 17:50 UTC (permalink / raw) To: Ingo Molnar Cc: Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon Ingo Molnar wrote: > > for example git-bisect was godsent. I remember that years ago bisection > of a bug was a very laborous task so that it was only used as a final, > last-ditch approach for really nasty bugs. Today we can autonomouly > bisect build bugs via a simple shell command around "git-bisect run", > without any human interaction! This freed up testing resources .. It's only a godsend for the few people who happen to be kernel developers and who happen to already use git. It's a 540MByte download over a slow link for everyone else. -ml ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 17:50 ` Mark Lord @ 2007-11-13 18:12 ` Adrian Bunk 2007-11-13 18:18 ` Mark Lord 2007-11-13 18:17 ` Peter Zijlstra ` (2 subsequent siblings) 3 siblings, 1 reply; 268+ messages in thread From: Adrian Bunk @ 2007-11-13 18:12 UTC (permalink / raw) To: Mark Lord Cc: Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tue, Nov 13, 2007 at 12:50:08PM -0500, Mark Lord wrote: > Ingo Molnar wrote: >> >> for example git-bisect was godsent. I remember that years ago bisection of >> a bug was a very laborous task so that it was only used as a final, >> last-ditch approach for really nasty bugs. Today we can autonomouly bisect >> build bugs via a simple shell command around "git-bisect run", without any >> human interaction! This freed up testing resources > .. > > It's only a godsend for the few people who happen to be kernel developers It's also godsend for users who want a regression they observe fixed. If you can tell which patch broke it you often turned a very hard to debug problem into a relatively easy fixable problem. As an example, [1] was an issue a normal user could discover, and bisecting made the difference between "nearly undebuggable" and "easily fixable by revertng a commit". > and who happen to already use git. As already said in thread, the required instructions for bisecting are relatively short and simple (assuming the user can build his own kernels). > It's a 540MByte download over a slow link for everyone else. Not everyone has a slow connection. For me, the speed of cloning a tree from git.kernel.org is completely cpu bound and limited by the speed of the 1.8 Ghz Athlon in my computer... But if there is a real life problem like people with extremely slow and expensive internet connections not being able to bisect bugs these problems should be named and fixed (e.g. by sending CDs). > -ml cu Adrian [1] http://lkml.org/lkml/2007/11/12/154 -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 18:12 ` Adrian Bunk @ 2007-11-13 18:18 ` Mark Lord 2007-11-13 18:36 ` Adrian Bunk 2007-11-14 1:10 ` David Miller 0 siblings, 2 replies; 268+ messages in thread From: Mark Lord @ 2007-11-13 18:18 UTC (permalink / raw) To: Adrian Bunk Cc: Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon Adrian Bunk wrote: > On Tue, Nov 13, 2007 at 12:50:08PM -0500, Mark Lord wrote: >> Ingo Molnar wrote: >>> for example git-bisect was godsent. I remember that years ago bisection of >>> a bug was a very laborous task so that it was only used as a final, >>> last-ditch approach for really nasty bugs. Today we can autonomouly bisect >>> build bugs via a simple shell command around "git-bisect run", without any >>> human interaction! This freed up testing resources >> .. >> >> It's only a godsend for the few people who happen to be kernel developers > > It's also godsend for users who want a regression they observe fixed. > > If you can tell which patch broke it you often turned a very hard to > debug problem into a relatively easy fixable problem. .. Oh yes, definitely. When that use happens to be a kernel dev + git user, it saves the *fool who broke it* a hell of a lot of time, because they can slough it off onto the poor bloke who notices it. Mind you, no arguing that this is effective when that poor bloke has a day free to download the git-tree and build/reboot a dozen times. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 18:18 ` Mark Lord @ 2007-11-13 18:36 ` Adrian Bunk 2007-11-13 18:47 ` Mark Lord 2007-11-14 1:10 ` David Miller 1 sibling, 1 reply; 268+ messages in thread From: Adrian Bunk @ 2007-11-13 18:36 UTC (permalink / raw) To: Mark Lord Cc: Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tue, Nov 13, 2007 at 01:18:43PM -0500, Mark Lord wrote: > Adrian Bunk wrote: >> On Tue, Nov 13, 2007 at 12:50:08PM -0500, Mark Lord wrote: >>> Ingo Molnar wrote: >>>> for example git-bisect was godsent. I remember that years ago bisection >>>> of a bug was a very laborous task so that it was only used as a final, >>>> last-ditch approach for really nasty bugs. Today we can autonomouly >>>> bisect build bugs via a simple shell command around "git-bisect run", >>>> without any human interaction! This freed up testing resources >>> .. >>> >>> It's only a godsend for the few people who happen to be kernel developers >> >> It's also godsend for users who want a regression they observe fixed. >> >> If you can tell which patch broke it you often turned a very hard to debug >> problem into a relatively easy fixable problem. > .. > > Oh yes, definitely. When that use happens to be a kernel dev + git user, > it saves the *fool who broke it* a hell of a lot of time, because they can > slough it off onto the poor bloke who notices it. "fool who broke it" are hard works. Bugs are part of software development, so you'd have to name everyone who develops software a fool. But the main point is that often you don't know who broke it until you know which commit broke it. > Mind you, no arguing that this is effective when that poor bloke > has a day free to download the git-tree and build/reboot a dozen times. I did bisecting myself, and I know that it costs time and work. But the first point is the above one that it makes otherwise nearly undebuggable problems debuggable and fixable. Another point is that it shifts the work from the few experienced developers to the many users. Users (and voluntary testers) we have many, but developer time for debugging bug reports is a quite scarce resource. And why "poor bloke"? Bisecting takes time, but that's not different from e.g. writing code or cleaning up code or going through bug reports. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 18:36 ` Adrian Bunk @ 2007-11-13 18:47 ` Mark Lord 2007-11-13 19:04 ` Adrian Bunk 0 siblings, 1 reply; 268+ messages in thread From: Mark Lord @ 2007-11-13 18:47 UTC (permalink / raw) To: Adrian Bunk Cc: Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon Adrian Bunk wrote: ... > I did bisecting myself, and I know that it costs time and work. > > But the first point is the above one that it makes otherwise nearly > undebuggable problems debuggable and fixable. .. Definitely useful, no question. But the problem is now that kernel devs are addicted to it, many won't even consider resolving a problem any other way. That's not "maintaining" (or supporting) one's code. And when a "maintainer" is too busy to find/fix their own bugs, that could be a sign that they've bitten off too big of a chunk of the kernel, and it's time for them to distribute code maintainership. Cheers ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 18:47 ` Mark Lord @ 2007-11-13 19:04 ` Adrian Bunk 2007-11-13 19:12 ` Mark Lord 2007-11-13 19:26 ` Mark Lord 0 siblings, 2 replies; 268+ messages in thread From: Adrian Bunk @ 2007-11-13 19:04 UTC (permalink / raw) To: Mark Lord Cc: Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tue, Nov 13, 2007 at 01:47:10PM -0500, Mark Lord wrote: > Adrian Bunk wrote: > ... >> I did bisecting myself, and I know that it costs time and work. >> >> But the first point is the above one that it makes otherwise nearly >> undebuggable problems debuggable and fixable. > .. > > Definitely useful, no question. > > But the problem is now that kernel devs are addicted to it, > many won't even consider resolving a problem any other way. > > That's not "maintaining" (or supporting) one's code. What you replaced with two dots contained the answer to this: Another point is that it shifts the work from the few experienced developers to the many users. Users (and voluntary testers) we have many, but developer time for debugging bug reports is a quite scarce resource. > And when a "maintainer" is too busy to find/fix their own bugs, > that could be a sign that they've bitten off too big of a chunk > of the kernel, and it's time for them to distribute code maintainership. The problem is: Maintainers don't grow on trees. You need people who are both technically capable and willing to spend time on the non-sexy task of debugging problems. Where do you plan to find them? If you don't believe me, please find a maintainer for the currently unmaintained parallel port support. Or if you want a harder task, find a maintainer for the floppy driver... > Cheers cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 19:04 ` Adrian Bunk @ 2007-11-13 19:12 ` Mark Lord 2007-11-13 19:30 ` Adrian Bunk 2007-11-13 19:26 ` Mark Lord 1 sibling, 1 reply; 268+ messages in thread From: Mark Lord @ 2007-11-13 19:12 UTC (permalink / raw) To: Adrian Bunk Cc: Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon Adrian Bunk wrote: > On Tue, Nov 13, 2007 at 01:47:10PM -0500, Mark Lord wrote: >> Adrian Bunk wrote: >> ... >>> I did bisecting myself, and I know that it costs time and work. >>> >>> But the first point is the above one that it makes otherwise nearly >>> undebuggable problems debuggable and fixable. >> .. >> >> Definitely useful, no question. >> >> But the problem is now that kernel devs are addicted to it, >> many won't even consider resolving a problem any other way. >> >> That's not "maintaining" (or supporting) one's code. > > What you replaced with two dots contained the answer to this: > > Another point is that it shifts the work from the few experienced > developers to the many users. Users (and voluntary testers) we have > many, but developer time for debugging bug reports is a quite scarce > resource. > >> And when a "maintainer" is too busy to find/fix their own bugs, >> that could be a sign that they've bitten off too big of a chunk >> of the kernel, and it's time for them to distribute code maintainership. > > The problem is: Maintainers don't grow on trees. > > You need people who are both technically capable and willing to spend > time on the non-sexy task of debugging problems. > > Where do you plan to find them? > > If you don't believe me, please find a maintainer for the currently > unmaintained parallel port support. > > Or if you want a harder task, find a maintainer for the floppy driver... .. Again, the problem is: > But the problem is now that kernel devs are addicted to it, > many won't even consider resolving a problem any other way. And that's simply not good enough. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 19:12 ` Mark Lord @ 2007-11-13 19:30 ` Adrian Bunk 2007-11-13 19:46 ` Russell King 0 siblings, 1 reply; 268+ messages in thread From: Adrian Bunk @ 2007-11-13 19:30 UTC (permalink / raw) To: Mark Lord Cc: Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tue, Nov 13, 2007 at 02:12:57PM -0500, Mark Lord wrote: > Adrian Bunk wrote: >> On Tue, Nov 13, 2007 at 01:47:10PM -0500, Mark Lord wrote: >>> Adrian Bunk wrote: >>> ... >>>> I did bisecting myself, and I know that it costs time and work. >>>> >>>> But the first point is the above one that it makes otherwise nearly >>>> undebuggable problems debuggable and fixable. >>> .. >>> >>> Definitely useful, no question. >>> >>> But the problem is now that kernel devs are addicted to it, >>> many won't even consider resolving a problem any other way. >>> >>> That's not "maintaining" (or supporting) one's code. >> >> What you replaced with two dots contained the answer to this: >> >> Another point is that it shifts the work from the few experienced >> developers to the many users. Users (and voluntary testers) we have >> many, but developer time for debugging bug reports is a quite scarce >> resource. >> >>> And when a "maintainer" is too busy to find/fix their own bugs, >>> that could be a sign that they've bitten off too big of a chunk >>> of the kernel, and it's time for them to distribute code maintainership. >> >> The problem is: Maintainers don't grow on trees. >> >> You need people who are both technically capable and willing to spend time >> on the non-sexy task of debugging problems. >> >> Where do you plan to find them? >> >> If you don't believe me, please find a maintainer for the currently >> unmaintained parallel port support. >> >> Or if you want a harder task, find a maintainer for the floppy driver... > .. > > Again, the problem is: > >> But the problem is now that kernel devs are addicted to it, >> many won't even consider resolving a problem any other way. > > And that's simply not good enough. There is this silly limit that noone can work more than 168 hours per week on the Linux kernel, and some kernel developers seem to take the liberty of spending even less time on kernel development... Considering our problems to cope with the amount of incoming bug reports, everything that would require a kernel developer to spend more time for getting a bug fixed would be a horrible mistake. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 19:30 ` Adrian Bunk @ 2007-11-13 19:46 ` Russell King 2007-11-13 20:04 ` Adrian Bunk 0 siblings, 1 reply; 268+ messages in thread From: Russell King @ 2007-11-13 19:46 UTC (permalink / raw) To: Adrian Bunk Cc: Mark Lord, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, David Miller, linux-ide, bugme-daemon, linux-input, Ingo Molnar, Andrew Morton On Tue, Nov 13, 2007 at 08:30:35PM +0100, Adrian Bunk wrote: > There is this silly limit that noone can work more than 168 hours per > week on the Linux kernel, and some kernel developers seem to take the > liberty of spending even less time on kernel development... That limit of 168 hours applies all around the world to everyone. Moreover, not all kernel developers are employed to hack on the kernel for 168 hours a week. For me, personally, that figure is in reality about 24 hours a week. Yes, just 24. The rest of the time (like *now*) is time I'm volunteering because I happen to be reading my email... ... and happen to be wasting replying to discussions like this rather than reading that message which has just arrived on the ARM kernel mailing list from someone having problems using copy_from_user() with a kernel pointer. So, please, stop this idea that somehow kernel developers can somehow spend infinite amounts of time solving lots and lots of bugs. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 19:46 ` Russell King @ 2007-11-13 20:04 ` Adrian Bunk 0 siblings, 0 replies; 268+ messages in thread From: Adrian Bunk @ 2007-11-13 20:04 UTC (permalink / raw) To: Mark Lord, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, David Miller, linux-ide, bugme-daemon, linux-input, Ingo Molnar, Andrew Morton On Tue, Nov 13, 2007 at 07:46:49PM +0000, Russell King wrote: > On Tue, Nov 13, 2007 at 08:30:35PM +0100, Adrian Bunk wrote: > > There is this silly limit that noone can work more than 168 hours per > > week on the Linux kernel, and some kernel developers seem to take the > > liberty of spending even less time on kernel development... > > That limit of 168 hours applies all around the world to everyone. > Moreover, not all kernel developers are employed to hack on the > kernel for 168 hours a week. > > For me, personally, that figure is in reality about 24 hours a > week. Yes, just 24. The rest of the time (like *now*) is time I'm > volunteering because I happen to be reading my email... > > ... and happen to be wasting replying to discussions like this rather > than reading that message which has just arrived on the ARM kernel > mailing list from someone having problems using copy_from_user() > with a kernel pointer. > > So, please, stop this idea that somehow kernel developers can > somehow spend infinite amounts of time solving lots and lots of > bugs. Sorry, that happens when using irony in a non-native language... What I wanted to express: Noone has unlimited time for kernel development. > Russell King cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 19:04 ` Adrian Bunk 2007-11-13 19:12 ` Mark Lord @ 2007-11-13 19:26 ` Mark Lord 2007-11-13 20:00 ` Adrian Bunk 1 sibling, 1 reply; 268+ messages in thread From: Mark Lord @ 2007-11-13 19:26 UTC (permalink / raw) To: Adrian Bunk Cc: Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon Adrian Bunk wrote: > On Tue, Nov 13, 2007 at 01:47:10PM -0500, Mark Lord wrote: >> Adrian Bunk wrote: .. > Another point is that it shifts the work from the few experienced > developers to the many users. Users (and voluntary testers) we have > many, but developer time for debugging bug reports is a quite scarce > resource. > >> And when a "maintainer" is too busy to find/fix their own bugs, >> that could be a sign that they've bitten off too big of a chunk >> of the kernel, and it's time for them to distribute code maintainership. > > The problem is: Maintainers don't grow on trees. .. Hey, if somebody has time to break things, then they damn well ought to be able to make time to fix them again. And the best developers here on LKML do just that (fix what they break). You broke it, you fix it. A simple rule. Translation for the particularly daft: If you've been making significant updates to a driver/subsystem, and people are reporting that it is now broken for them, then it's your job to make it right. The reporters can help, and many may even git-bisect or send patches. But you cannot *expect* or *insist* upon them doing your job. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 19:26 ` Mark Lord @ 2007-11-13 20:00 ` Adrian Bunk 2007-11-13 20:13 ` Mark Lord 2007-11-13 21:12 ` Alan Cox 0 siblings, 2 replies; 268+ messages in thread From: Adrian Bunk @ 2007-11-13 20:00 UTC (permalink / raw) To: Mark Lord Cc: Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tue, Nov 13, 2007 at 02:26:05PM -0500, Mark Lord wrote: > Adrian Bunk wrote: >> On Tue, Nov 13, 2007 at 01:47:10PM -0500, Mark Lord wrote: >>> Adrian Bunk wrote: > .. >> Another point is that it shifts the work from the few experienced >> developers to the many users. Users (and voluntary testers) we have >> many, but developer time for debugging bug reports is a quite scarce >> resource. >> >>> And when a "maintainer" is too busy to find/fix their own bugs, >>> that could be a sign that they've bitten off too big of a chunk >>> of the kernel, and it's time for them to distribute code maintainership. >> >> The problem is: Maintainers don't grow on trees. > .. > > Hey, if somebody has time to break things, then they damn well ought > to be able to make time to fix them again. And the best developers > here on LKML do just that (fix what they break). > > You broke it, you fix it. A simple rule. > > Translation for the particularly daft: > > If you've been making significant updates to a driver/subsystem, > and people are reporting that it is now broken for them, What are "significant updates"? Sometimes one person makes one small patch and this patch contains a typo. > then it's your job to make it right. We have some open drivers/ata/ regressions. I see some person named "Mark Lord" being responsible for 4 commits. What pubishment do you plan for him if 2.6.24 ships with any libata regressions? Let George W. Bush wrongly accuse him of possessing weapons of mass destructions and invade Canada? > The reporters can help, > and many may even git-bisect or send patches. > But you cannot *expect* or *insist* upon them doing your job. Bullshit. Bug fixing is not about finding someone to blame, it's about getting the bug fixed. The bug reporter is the person who can reproduce the problem, and if it's a regression then bisecting is the natural way of getting nearer at getting it fixed. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 20:00 ` Adrian Bunk @ 2007-11-13 20:13 ` Mark Lord 2007-11-13 21:20 ` Adrian Bunk 2007-11-13 21:12 ` Alan Cox 1 sibling, 1 reply; 268+ messages in thread From: Mark Lord @ 2007-11-13 20:13 UTC (permalink / raw) To: Adrian Bunk Cc: Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon Adrian Bunk wrote: > On Tue, Nov 13, 2007 at 02:26:05PM -0500, Mark Lord wrote: .. >> If you've been making significant updates to a driver/subsystem, >> and people are reporting that it is now broken for them, > > What are "significant updates"? > > Sometimes one person makes one small patch and this patch contains > a typo. .. Then that person should double check their changes against the problems reported, and re-convince themselves that the breakage wasn't from those. Simple. >> then it's your job to make it right. > > We have some open drivers/ata/ regressions. .. Yup, but they're more specific than just that entire subsystem, and the maintainers are actively pursuing the problems. Exactly what should be happening. > I see some person named "Mark Lord" being responsible for 4 commits. > > What pubishment do you plan for him if 2.6.24 ships with any libata > regressions? .. If the code I'm touching breaks, then I'll fix it ASAP, exactly what the users of that code might expect. >> The reporters can help, >> and many may even git-bisect or send patches. >> But you cannot *expect* or *insist* upon them doing your job. > > Bullshit. > > Bug fixing is not about finding someone to blame, it's about getting the > bug fixed. .. It's not about blame, it's about paying attention to breakages in code that a person claims to be supporting, and then doing their best to resolve the issues. Again, if one has the time to actively write/modify code such that something breaks, then that person should also make time to fix the breakages. > The bug reporter is the person who can reproduce the problem, and if > it's a regression then bisecting is the natural way of getting nearer > at getting it fixed. .. For the third time, no disagreement here. git-bsect can help in many cases, but not in all cases. And it requires a great time commitment from somebody who's system used to work and now doesn't work. The person who broke it has a fair bit of responsibility there, too. cheers ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 20:13 ` Mark Lord @ 2007-11-13 21:20 ` Adrian Bunk 0 siblings, 0 replies; 268+ messages in thread From: Adrian Bunk @ 2007-11-13 21:20 UTC (permalink / raw) To: Mark Lord Cc: Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tue, Nov 13, 2007 at 03:13:46PM -0500, Mark Lord wrote: > Adrian Bunk wrote: >> On Tue, Nov 13, 2007 at 02:26:05PM -0500, Mark Lord wrote: > .. >>> If you've been making significant updates to a driver/subsystem, >>> and people are reporting that it is now broken for them, >> >> What are "significant updates"? >> >> Sometimes one person makes one small patch and this patch contains >> a typo. > .. > > Then that person should double check their changes against > the problems reported, and re-convince themselves that the > breakage wasn't from those. Simple. Simple? Everything you have in mind with "should double check their changes" is simply not realistic with dozens of known unfixed regressions within more than half a million changed or new lines of code written by more than 800 people - all numbers only counted since 2.6.23. >... >>> The reporters can help, >>> and many may even git-bisect or send patches. But you cannot *expect* or >>> *insist* upon them doing your job. >> >> Bullshit. >> >> Bug fixing is not about finding someone to blame, it's about getting the >> bug fixed. > .. > > It's not about blame, it's about paying attention to breakages in code that a > person claims to be supporting, and then doing their best to resolve the issues. Maintainers are just humans with limited time. You were the one who suggested to "distribute code maintainership", so you should explain how to find the additional maintainers. > Again, if one has the time to actively write/modify code such that something breaks, > then that person should also make time to fix the breakages. code writer != subsystem maintainer And git-bisect is the tool that tells you who broke it. >> The bug reporter is the person who can reproduce the problem, and if it's >> a regression then bisecting is the natural way of getting nearer at >> getting it fixed. > .. > For the third time, no disagreement here. git-bsect can help in many cases, > but not in all cases. And it requires a great time commitment from somebody > who's system used to work and now doesn't work. The person who broke it has > a fair bit of responsibility there, too. git-bisect can help only for regressions, and it can help for most regressions. And you shouldn't try to make a problem out of something that isn't a problem: Bug submitters are either volunteers who test -rc or even -git or -mm kernels for finding bugs or people who want a problem they experience fixed. In both cases the submitters are usually willing to invest some time for helping to get the bug fixed. > cheers cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 20:00 ` Adrian Bunk 2007-11-13 20:13 ` Mark Lord @ 2007-11-13 21:12 ` Alan Cox 2007-11-14 0:52 ` Chuck Ebbert 1 sibling, 1 reply; 268+ messages in thread From: Alan Cox @ 2007-11-13 21:12 UTC (permalink / raw) To: Adrian Bunk Cc: Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon > Bug fixing is not about finding someone to blame, it's about getting the > bug fixed. Partly - its also about understanding why the bug occurred and making it not happen again. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 21:12 ` Alan Cox @ 2007-11-14 0:52 ` Chuck Ebbert 2007-11-14 1:11 ` Stephen Hemminger 0 siblings, 1 reply; 268+ messages in thread From: Chuck Ebbert @ 2007-11-14 0:52 UTC (permalink / raw) To: Alan Cox Cc: Adrian Bunk, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On 11/13/2007 04:12 PM, Alan Cox wrote: >> Bug fixing is not about finding someone to blame, it's about getting the >> bug fixed. > > Partly - its also about understanding why the bug occurred and making it > not happen again. Very few people think about that part. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 0:52 ` Chuck Ebbert @ 2007-11-14 1:11 ` Stephen Hemminger 2007-11-14 2:10 ` Andrew Morton 0 siblings, 1 reply; 268+ messages in thread From: Stephen Hemminger @ 2007-11-14 1:11 UTC (permalink / raw) To: Chuck Ebbert Cc: Alan Cox, Adrian Bunk, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tue, 13 Nov 2007 19:52:17 -0500 Chuck Ebbert <cebbert@redhat.com> wrote: > On 11/13/2007 04:12 PM, Alan Cox wrote: > >> Bug fixing is not about finding someone to blame, it's about getting the > >> bug fixed. > > > > Partly - its also about understanding why the bug occurred and making it > > not happen again. > > Very few people think about that part. Why does the kernel have very few useful tests? Lack of interest? resources? expertise? Ideally each new feature would just be a small add on to an existing test. Unlike developing new features which seems to grow well with more developers. Bug fixing also seems to be a scarcity process. There often seems to be a very few people that understand the problem well enough or have the necessary hardware to reproduce and fix the problem. Recent changes like tickless and scheduler rework were well thought out and caused very little impact to 90% of the users. The problem is the 10% who do have problems. Worse, the developers often only hear about the a small sample of those. -- Stephen Hemminger <shemminger@linux-foundation.org> ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 1:11 ` Stephen Hemminger @ 2007-11-14 2:10 ` Andrew Morton 0 siblings, 0 replies; 268+ messages in thread From: Andrew Morton @ 2007-11-14 2:10 UTC (permalink / raw) To: Stephen Hemminger Cc: Chuck Ebbert, Alan Cox, Adrian Bunk, Mark Lord, Ingo Molnar, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tue, 13 Nov 2007 17:11:36 -0800 Stephen Hemminger <shemminger@linux-foundation.org> wrote: > On Tue, 13 Nov 2007 19:52:17 -0500 > Chuck Ebbert <cebbert@redhat.com> wrote: > > > On 11/13/2007 04:12 PM, Alan Cox wrote: > > >> Bug fixing is not about finding someone to blame, it's about getting the > > >> bug fixed. > > > > > > Partly - its also about understanding why the bug occurred and making it > > > not happen again. > > > > Very few people think about that part. > > Why does the kernel have very few useful tests? Tests would of course be nice, but they aren't very useful(!) Looking at this list which Natalie has generated I see around thirty which are dependent on the right hardware and ten which are not. This ratio is typical, I think. In fact I'd say that more than 75% of reported bugs are dependent on hardware. So the best test of all for the kernel is "run it on a different machine". This is why we are sooooo dependent upon our volunteer testers/reporters to be able to do kernel development. > Lack of interest? resources? expertise? > Ideally each new feature would just be a small add on to an existing test. Sure. For system-call-visible features it would be good to do that. But this tends not to be where bugs get exposed. Because the original developer can 100% exercise such code. That isn't the case with driver/arch/platform changes. > Unlike developing new features which seems to grow well with more developers. > Bug fixing also seems to be a scarcity process. There often seems to be > a very few people that understand the problem well enough or have the necessary > hardware to reproduce and fix the problem. We're 100% dead if "having the hardware" is a prerequisite to fixing a bug. The terminal state there is that the kernel runs on about 200 machines worldwide. We have to work with reporters via email to fix these sorts of things. As we of course do. > Recent changes like tickless and scheduler rework were well thought out and caused > very little impact to 90% of the users. The problem is the 10% who do have problems. > Worse, the developers often only hear about the a small sample of those. Yes. An unknown number of people just shrug and go back to an old kernel. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 18:18 ` Mark Lord 2007-11-13 18:36 ` Adrian Bunk @ 2007-11-14 1:10 ` David Miller 2007-11-14 1:18 ` Peter Stuge 1 sibling, 1 reply; 268+ messages in thread From: David Miller @ 2007-11-14 1:10 UTC (permalink / raw) To: liml Cc: bunk, mingo, akpm, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon From: Mark Lord <liml@rtr.ca> Date: Tue, 13 Nov 2007 13:18:43 -0500 > Mind you, no arguing that this is effective when that poor bloke has > a day free to download the git-tree and build/reboot a dozen times. Like the internet, this time spent is beneficial because it's pushing the work out to the end nodes. In fact git bisect is an awesome example of the end node principle in action for software development and QA. For the end-user wanting their bug fixed and the developer it's a win win situation because the reporter is actually able to do something proactive which will help get the bug they want fixed faster. So I don't agree with framing this person as a "poor bloke". Our testers are more empowered than ever to lead the process towards a fix. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 1:10 ` David Miller @ 2007-11-14 1:18 ` Peter Stuge 0 siblings, 0 replies; 268+ messages in thread From: Peter Stuge @ 2007-11-14 1:18 UTC (permalink / raw) To: linux-pcmcia, linux-kernel Please stop cross-posting this thread at least to linux-pcmcia until your post is relevant to PCMCIA. Sorry for being a bore. (Not that I don't love reading LKML discussions, but I found that it took too much time, and now they're over at linux-pcmcia too! :) Thank you in advance. //Peter ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 17:50 ` Mark Lord 2007-11-13 18:12 ` Adrian Bunk @ 2007-11-13 18:17 ` Peter Zijlstra 2007-11-13 18:39 ` Matthew Wilcox 2007-11-18 12:44 ` size of git repository (was Re: [BUG] New Kernel Bugs) Pavel Machek 3 siblings, 0 replies; 268+ messages in thread From: Peter Zijlstra @ 2007-11-13 18:17 UTC (permalink / raw) To: Mark Lord Cc: Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tue, 2007-11-13 at 12:50 -0500, Mark Lord wrote: > Ingo Molnar wrote: > > > > for example git-bisect was godsent. I remember that years ago bisection > > of a bug was a very laborous task so that it was only used as a final, > > last-ditch approach for really nasty bugs. Today we can autonomouly > > bisect build bugs via a simple shell command around "git-bisect run", > > without any human interaction! This freed up testing resources > ... > > It's only a godsend for the few people who happen to be kernel developers > and who happen to already use git. > > It's a 540MByte download over a slow link for everyone else. Oh, common. Leeching CDs is so yesterday. These days some distributions don't even offer CDs anymore in favour of DVDs. I'd be amazed if a lot of the testers would still be on slownet, its impossible to keep up with the latest distros without broadband. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 17:50 ` Mark Lord 2007-11-13 18:12 ` Adrian Bunk 2007-11-13 18:17 ` Peter Zijlstra @ 2007-11-13 18:39 ` Matthew Wilcox 2007-11-13 18:43 ` Mark Lord 2007-11-18 12:44 ` size of git repository (was Re: [BUG] New Kernel Bugs) Pavel Machek 3 siblings, 1 reply; 268+ messages in thread From: Matthew Wilcox @ 2007-11-13 18:39 UTC (permalink / raw) To: Mark Lord Cc: Ingo Molnar, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, Andrew Morton, David Miller On Tue, Nov 13, 2007 at 12:50:08PM -0500, Mark Lord wrote: > It's a 540MByte download over a slow link for everyone else. Where do you get this number from? $ du -sh .git/objects/pack/ 249M .git/objects/pack/ $ du -sh .git/objects/ 253M .git/objects/ ie about half what you claim. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 18:39 ` Matthew Wilcox @ 2007-11-13 18:43 ` Mark Lord 2007-11-13 18:49 ` Matthew Wilcox 0 siblings, 1 reply; 268+ messages in thread From: Mark Lord @ 2007-11-13 18:43 UTC (permalink / raw) To: Matthew Wilcox Cc: Ingo Molnar, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, Andrew Morton, David Miller Matthew Wilcox wrote: > On Tue, Nov 13, 2007 at 12:50:08PM -0500, Mark Lord wrote: >> It's a 540MByte download over a slow link for everyone else. > > Where do you get this number from? > $ du -sh .git/objects/pack/ > 249M .git/objects/pack/ > $ du -sh .git/objects/ > 253M .git/objects/ > > ie about half what you claim. .. No, it's from earlier in this very thread: Adrian Bunk wrote: > The small instruction below is enough for everyone who is able to > build his own kernel to do a git bisect. .. > <-- snip --> > > > # install git > > # clone Linus' tree: > git clone \ > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git .. mkdir t cd t git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git (wait half an hour) /usr/bin/du -s linux-2.6 522732 linux-2.6 ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 18:43 ` Mark Lord @ 2007-11-13 18:49 ` Matthew Wilcox 2007-11-13 18:54 ` Mark Lord 0 siblings, 1 reply; 268+ messages in thread From: Matthew Wilcox @ 2007-11-13 18:49 UTC (permalink / raw) To: Mark Lord Cc: Ingo Molnar, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, Andrew Morton, David Miller On Tue, Nov 13, 2007 at 01:43:53PM -0500, Mark Lord wrote: > Matthew Wilcox wrote: > >ie about half what you claim. > .. > > No, it's from earlier in this very thread: > > Adrian Bunk wrote: > >git clone \ > >git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > .. > > mkdir t > cd t > git clone > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > (wait half an hour) > /usr/bin/du -s linux-2.6 > 522732 linux-2.6 You're assuming that everything in linux-2.6 was downloaded; that's not true. Everything in linux-2.6/.git was downloaded; but then you do a checkout which happens to approximately double the size of the linux-2.6 directory. If you do git-clone -n, you'll get a closer estimate to the size of the download. I suppose git-clone should grow a -v option that it could pass to rsync to let us find out how many bytes are actually transferred, but i'm happy to go with 250MB as a close estimate to the amount of data to xfer. When you compare it to the 60MB tarballs that are published, it's really not that bad. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 18:49 ` Matthew Wilcox @ 2007-11-13 18:54 ` Mark Lord 2007-11-13 22:09 ` Rafael J. Wysocki 2007-11-14 14:30 ` Ingo Molnar 0 siblings, 2 replies; 268+ messages in thread From: Mark Lord @ 2007-11-13 18:54 UTC (permalink / raw) To: Matthew Wilcox Cc: Ingo Molnar, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, Andrew Morton, David Miller Matthew Wilcox wrote: > On Tue, Nov 13, 2007 at 01:43:53PM -0500, Mark Lord wrote: > >> mkdir t >> cd t >> git clone >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git >> (wait half an hour) >> /usr/bin/du -s linux-2.6 >> 522732 linux-2.6 > > You're assuming that everything in linux-2.6 was downloaded; that's > not true. Everything in linux-2.6/.git was downloaded; but then you do a > checkout which happens to approximately double the size of the linux-2.6 > directory. .. Ah, I wondered why it took only half an hour to download. .. > When you compare it to the 60MB tarballs that are published, it's really > not that bad. .. The tarballs I download are only 45MB. Cheers ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 18:54 ` Mark Lord @ 2007-11-13 22:09 ` Rafael J. Wysocki 2007-11-14 14:30 ` Ingo Molnar 1 sibling, 0 replies; 268+ messages in thread From: Rafael J. Wysocki @ 2007-11-13 22:09 UTC (permalink / raw) To: Mark Lord Cc: Matthew Wilcox, Ingo Molnar, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, Andrew Morton, David Miller On Tuesday, 13 of November 2007, Mark Lord wrote: > Matthew Wilcox wrote: > > On Tue, Nov 13, 2007 at 01:43:53PM -0500, Mark Lord wrote: > > > >> mkdir t > >> cd t > >> git clone > >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > >> (wait half an hour) > >> /usr/bin/du -s linux-2.6 > >> 522732 linux-2.6 > > > > You're assuming that everything in linux-2.6 was downloaded; that's > > not true. Everything in linux-2.6/.git was downloaded; but then you do a > > checkout which happens to approximately double the size of the linux-2.6 > > directory. > .. > > Ah, I wondered why it took only half an hour to download. > > .. > > When you compare it to the 60MB tarballs that are published, it's really > > not that bad. > .. > > The tarballs I download are only 45MB. You clone the git repo once. Afterwards, you only update it and that usually doesn't take that much time and a little effort. Greetings, Rafael ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 18:54 ` Mark Lord 2007-11-13 22:09 ` Rafael J. Wysocki @ 2007-11-14 14:30 ` Ingo Molnar 2007-11-14 14:49 ` Larry Finger 1 sibling, 1 reply; 268+ messages in thread From: Ingo Molnar @ 2007-11-14 14:30 UTC (permalink / raw) To: Mark Lord Cc: Matthew Wilcox, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, Andrew Morton, David Miller * Mark Lord <liml@rtr.ca> wrote: >> You're assuming that everything in linux-2.6 was downloaded; that's >> not true. Everything in linux-2.6/.git was downloaded; but then you >> do a checkout which happens to approximately double the size of the >> linux-2.6 directory. > .. > > Ah, I wondered why it took only half an hour to download. and you can get even lower than the 260MB by downloading a shallow clone of v2.6.23 and then populating the git tree from tht point on. (see the --depth parameter of git-clone) [because most of the time you want to bisect back to the last stable release, not back to 2 years of git history.] Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 14:30 ` Ingo Molnar @ 2007-11-14 14:49 ` Larry Finger 0 siblings, 0 replies; 268+ messages in thread From: Larry Finger @ 2007-11-14 14:49 UTC (permalink / raw) To: Ingo Molnar Cc: Mark Lord, alsa-devel, Matthew Wilcox, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, Andrew Morton, David Miller Ingo Molnar wrote: > * Mark Lord <liml@rtr.ca> wrote: > >>> You're assuming that everything in linux-2.6 was downloaded; that's >>> not true. Everything in linux-2.6/.git was downloaded; but then you >>> do a checkout which happens to approximately double the size of the >>> linux-2.6 directory. >> .. >> >> Ah, I wondered why it took only half an hour to download. > > and you can get even lower than the 260MB by downloading a shallow clone > of v2.6.23 and then populating the git tree from tht point on. (see the > --depth parameter of git-clone) [because most of the time you want to > bisect back to the last stable release, not back to 2 years of git > history.] When creating additional git trees (Linville's wireless-2.6 tree, for example) for driver development, you can save a lot of download bandwidth by using the --reference parameter of git-clone. Larry ^ permalink raw reply [flat|nested] 268+ messages in thread
* size of git repository (was Re: [BUG] New Kernel Bugs) 2007-11-13 17:50 ` Mark Lord ` (2 preceding siblings ...) 2007-11-13 18:39 ` Matthew Wilcox @ 2007-11-18 12:44 ` Pavel Machek 2007-11-18 12:58 ` Rene Herman 2007-11-18 14:56 ` Ingo Molnar 3 siblings, 2 replies; 268+ messages in thread From: Pavel Machek @ 2007-11-18 12:44 UTC (permalink / raw) To: Mark Lord Cc: Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tue 2007-11-13 12:50:08, Mark Lord wrote: > Ingo Molnar wrote: > > > >for example git-bisect was godsent. I remember that > >years ago bisection of a bug was a very laborous task > >so that it was only used as a final, last-ditch > >approach for really nasty bugs. Today we can > >autonomouly bisect build bugs via a simple shell > >command around "git-bisect run", without any human > >interaction! This freed up testing resources > .. > > It's only a godsend for the few people who happen to be > kernel developers > and who happen to already use git. > > It's a 540MByte download over a slow link for everyone > else. Hmmm, clean-cg is 7.7G on my machine, and yes I tried git-prune-packed. What am I doing wrong? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: size of git repository (was Re: [BUG] New Kernel Bugs) 2007-11-18 12:44 ` size of git repository (was Re: [BUG] New Kernel Bugs) Pavel Machek @ 2007-11-18 12:58 ` Rene Herman 2007-11-18 14:35 ` James Bottomley 2007-11-18 14:56 ` Ingo Molnar 1 sibling, 1 reply; 268+ messages in thread From: Rene Herman @ 2007-11-18 12:58 UTC (permalink / raw) To: Pavel Machek Cc: Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On 18-11-07 13:44, Pavel Machek wrote: > On Tue 2007-11-13 12:50:08, Mark Lord wrote: >> It's a 540MByte download over a slow link for everyone >> else. > > Hmmm, clean-cg is 7.7G on my machine, and yes I tried > git-prune-packed. What am I doing wrong? clean-cg? But failure to run "git repack -a -d" every once in a while? Rene. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: size of git repository (was Re: [BUG] New Kernel Bugs) 2007-11-18 12:58 ` Rene Herman @ 2007-11-18 14:35 ` James Bottomley 2007-11-18 15:19 ` Rene Herman 0 siblings, 1 reply; 268+ messages in thread From: James Bottomley @ 2007-11-18 14:35 UTC (permalink / raw) To: Rene Herman Cc: Pavel Machek, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Sun, 2007-11-18 at 13:58 +0100, Rene Herman wrote: > On 18-11-07 13:44, Pavel Machek wrote: > > > On Tue 2007-11-13 12:50:08, Mark Lord wrote: > > >> It's a 540MByte download over a slow link for everyone > >> else. > > > > Hmmm, clean-cg is 7.7G on my machine, and yes I tried > > git-prune-packed. What am I doing wrong? > > clean-cg? But failure to run "git repack -a -d" every once in a while? Actually, the best command is git gc which does a repack (into a single pack file rather than an incremenal), and then removes all the objects now in the pack. If, like me, you work on temporary branches which you keep rebasing, you can add a --prune to gc which will erase all unreferenced objects as it packs (use this one with care. I usually never use it but run a git prune -n just to see what would be removed, and then run git prune separately if it looks OK). James ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: size of git repository (was Re: [BUG] New Kernel Bugs) 2007-11-18 14:35 ` James Bottomley @ 2007-11-18 15:19 ` Rene Herman 0 siblings, 0 replies; 268+ messages in thread From: Rene Herman @ 2007-11-18 15:19 UTC (permalink / raw) To: James Bottomley Cc: Pavel Machek, Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On 18-11-07 15:35, James Bottomley wrote: >> clean-cg? But failure to run "git repack -a -d" every once in a while? > > Actually, the best command is > > git gc > > which does a repack (into a single pack file rather than an incremenal), > and then removes all the objects now in the pack. If, like me, you work > on temporary branches which you keep rebasing, you can add a --prune to > gc which will erase all unreferenced objects as it packs (use this one > with care. I usually never use it but run a git prune -n just to see > what would be removed, and then run git prune separately if it looks OK). Thanks for the comment. That managed to indeed shave a few extra bytes off my already "repack -a -d" packed repo still. Rene. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: size of git repository (was Re: [BUG] New Kernel Bugs) 2007-11-18 12:44 ` size of git repository (was Re: [BUG] New Kernel Bugs) Pavel Machek 2007-11-18 12:58 ` Rene Herman @ 2007-11-18 14:56 ` Ingo Molnar 2007-11-19 4:43 ` Willy Tarreau 1 sibling, 1 reply; 268+ messages in thread From: Ingo Molnar @ 2007-11-18 14:56 UTC (permalink / raw) To: Pavel Machek Cc: Mark Lord, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon * Pavel Machek <pavel@ucw.cz> wrote: > On Tue 2007-11-13 12:50:08, Mark Lord wrote: > > Ingo Molnar wrote: > > > > > >for example git-bisect was godsent. I remember that > > >years ago bisection of a bug was a very laborous task > > >so that it was only used as a final, last-ditch > > >approach for really nasty bugs. Today we can > > >autonomouly bisect build bugs via a simple shell > > >command around "git-bisect run", without any human > > >interaction! This freed up testing resources > > .. > > > > It's only a godsend for the few people who happen to be > > kernel developers > > and who happen to already use git. > > > > It's a 540MByte download over a slow link for everyone > > else. > > Hmmm, clean-cg is 7.7G on my machine, and yes I tried > git-prune-packed. What am I doing wrong? "git-repack -a -d" gives me ~220 MB: $ du -s .git 222064 .git anyone who can download a 43 MB tar.bz2 tarball for a kernel release should be able to afford a _one time_ download size of 250 MB (the size of the current kernel.org git repository). If not, burning a CD or DVD and carrying it home ought to do the trick. Git is very bandwidth-efficient after that point - lots of people behind narrow pipes are using it - it's just the initial clone that takes time. And given all the history and metadata that the git repository carries (full changelogs, annotations, etc.) it's a no-brainer that kernel developers should be using it. (and you can shrink the 250 MB further down by using shallow clones, etc.) yes, some people complained when distros stopped doing floppy installs. Some people complained when distros stopped doing CD installs. Yes, i've myself done a 250+ MB download over a 56 kbit modem in the past, and while it indeed took overnight to finish, it's very much doable. It's not really qualitatively different from the 1.5 hours a kernel tar.bz2 took to download. Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: size of git repository (was Re: [BUG] New Kernel Bugs) 2007-11-18 14:56 ` Ingo Molnar @ 2007-11-19 4:43 ` Willy Tarreau 0 siblings, 0 replies; 268+ messages in thread From: Willy Tarreau @ 2007-11-19 4:43 UTC (permalink / raw) To: Ingo Molnar Cc: Pavel Machek, Mark Lord, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Sun, Nov 18, 2007 at 03:56:11PM +0100, Ingo Molnar wrote: > > * Pavel Machek <pavel@ucw.cz> wrote: > > > On Tue 2007-11-13 12:50:08, Mark Lord wrote: > > > Ingo Molnar wrote: > > > > > > > >for example git-bisect was godsent. I remember that > > > >years ago bisection of a bug was a very laborous task > > > >so that it was only used as a final, last-ditch > > > >approach for really nasty bugs. Today we can > > > >autonomouly bisect build bugs via a simple shell > > > >command around "git-bisect run", without any human > > > >interaction! This freed up testing resources > > > .. > > > > > > It's only a godsend for the few people who happen to be > > > kernel developers > > > and who happen to already use git. > > > > > > It's a 540MByte download over a slow link for everyone > > > else. > > > > Hmmm, clean-cg is 7.7G on my machine, and yes I tried > > git-prune-packed. What am I doing wrong? > > "git-repack -a -d" gives me ~220 MB: > > $ du -s .git > 222064 .git > > anyone who can download a 43 MB tar.bz2 tarball for a kernel release > should be able to afford a _one time_ download size of 250 MB (the size > of the current kernel.org git repository). If not, burning a CD or DVD > and carrying it home ought to do the trick. Git is very > bandwidth-efficient after that point - lots of people behind narrow > pipes are using it - it's just the initial clone that takes time. And > given all the history and metadata that the git repository carries (full > changelogs, annotations, etc.) it's a no-brainer that kernel developers > should be using it. > > (and you can shrink the 250 MB further down by using shallow clones, > etc.) > > yes, some people complained when distros stopped doing floppy installs. > Some people complained when distros stopped doing CD installs. Yes, i've > myself done a 250+ MB download over a 56 kbit modem in the past, and > while it indeed took overnight to finish, it's very much doable. It's > not really qualitatively different from the 1.5 hours a kernel tar.bz2 > took to download. Probably that once in a while, we should set up a complete tree in a tar.bz2 format on kernel.org. It would help a lot of people behind small pipes. I have been encountering problems with git-clone when the link is unstable. After the smallest error, it erases everything and you have to retry from start, which is quite frustrating and expensive. At least, downloading a tar.bz2 with FTP would be easier and a lot more reliable. Also, people could download it from their workplace and bring it home. Willy ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 14:08 ` Mark Lord ` (2 preceding siblings ...) 2007-11-13 16:46 ` Ingo Molnar @ 2007-11-13 19:37 ` Russell King 2007-11-13 20:18 ` Mark Lord 2007-11-14 0:34 ` Denys Vlasenko 4 siblings, 1 reply; 268+ messages in thread From: Russell King @ 2007-11-13 19:37 UTC (permalink / raw) To: Mark Lord Cc: Ingo Molnar, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, Andrew Morton, David Miller On Tue, Nov 13, 2007 at 09:08:32AM -0500, Mark Lord wrote: > Ingo Molnar wrote: > .. > > This is all QA-101 that _cannot be argued against on a rational basis_, > > it's just that these sorts of things have been largely ignored for > > years, in favor of the all-too-easy "open source means many eyeballs and > > that is our QA" answer, which is a _good_ answer but by far not the most > > intelligent answer! Today "many eyeballs" is simply not good enough and > > nature (and other OS projects) will route us around if we dont change. > .. > > QA-101 and "many eyeballs" are not at all in opposition. > The latter is how we find out about bugs on uncommon hardware, > and the former is what we need to track them and overall quality. > > A HUGE problem I have with current "efforts", is that once someone > reports a bug, the onus seems to be 99% on the *reporter* to find > the exact line of code or commit. Ghad what a repressive method. 99% on the reporter? Is that why I always try to understand the reporters problem (*provided* it's in an area I know about) and come up with a patch to test a theory or fix the issue? I'm _less_ inclined to provide such a "service" for lazy maintainers who've moved off into new and wonderfully exciting technologies, to churn out more patches for me to merge (and eventually provide a free to them bug fixing service for.) That's "less" inclined, not "won't". -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 19:37 ` [BUG] New Kernel Bugs Russell King @ 2007-11-13 20:18 ` Mark Lord 2007-11-13 21:33 ` Jörn Engel 2007-11-13 23:40 ` Russell King 0 siblings, 2 replies; 268+ messages in thread From: Mark Lord @ 2007-11-13 20:18 UTC (permalink / raw) To: Ingo Molnar, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, Andrew Morton, David Miller Russell King wrote: > On Tue, Nov 13, 2007 at 09:08:32AM -0500, Mark Lord wrote: >> Ingo Molnar wrote: >> .. >>> This is all QA-101 that _cannot be argued against on a rational basis_, >>> it's just that these sorts of things have been largely ignored for >>> years, in favor of the all-too-easy "open source means many eyeballs and >>> that is our QA" answer, which is a _good_ answer but by far not the most >>> intelligent answer! Today "many eyeballs" is simply not good enough and >>> nature (and other OS projects) will route us around if we dont change. >> .. >> >> QA-101 and "many eyeballs" are not at all in opposition. >> The latter is how we find out about bugs on uncommon hardware, >> and the former is what we need to track them and overall quality. >> >> A HUGE problem I have with current "efforts", is that once someone >> reports a bug, the onus seems to be 99% on the *reporter* to find >> the exact line of code or commit. Ghad what a repressive method. > > 99% on the reporter? Is that why I always try to understand the > reporters problem (*provided* it's in an area I know about) and come > up with a patch to test a theory or fix the issue? .. Same here. I just find it weird that something can be known broken for several -rc* kernels before I happen to install it, discover it's broken on my own machine, and then I track it down, fix it, and submit the patch, generally all within a couple of hours. Where the heck was the dude(ess) that broke it ?? AWOL. And when I receive hostility from the "maintainers" of said code for fixing their bugs, well.. that really motivates me to continue reporting new ones.. > I'm _less_ inclined to provide such a "service" for lazy maintainers > who've moved off into new and wonderfully exciting technologies, to > churn out more patches for me to merge (and eventually provide a free > to them bug fixing service for.) > > That's "less" inclined, not "won't". > ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 20:18 ` Mark Lord @ 2007-11-13 21:33 ` Jörn Engel 2007-11-13 21:56 ` Andrew Morton 2007-11-13 22:29 ` Mark Lord 2007-11-13 23:40 ` Russell King 1 sibling, 2 replies; 268+ messages in thread From: Jörn Engel @ 2007-11-13 21:33 UTC (permalink / raw) To: Mark Lord Cc: Ingo Molnar, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, Andrew Morton, David Miller On Tue, 13 November 2007 15:18:07 -0500, Mark Lord wrote: > > I just find it weird that something can be known broken for several -rc* > kernels before I happen to install it, discover it's broken on my own > machine, > and then I track it down, fix it, and submit the patch, generally all > within a > couple of hours. Where the heck was the dude(ess) that broke it ?? AWOL. > > And when I receive hostility from the "maintainers" of said code for fixing > their bugs, well.. that really motivates me to continue reporting new ones.. Given a decent bug report, I agree that having the bug not looked at is shameful. But what can a developer do if a bug report effectively reads "there is some bug somewhere in recent kernels"? How can I know that in this particular case it is my bug that I introduced? It could just as easily be 50 other people and none of them are eager to debug it unless they suspect it to be their bug. This is a common problem and fairly unrelated to linux in general or the kernel in particular. Who is going to be the sucker that figures out which developer the bug belongs to? And I have yet to find a project, commercial or opensource, where volunteers flock to become such a sucker. One option is to push this role to the bug reporter. Another is to strong-arm some developers into this role, by whatever means. A third would be for $LARGE_COMPANY to hire some people. If you have a better idea or would volunteer your time, I'd be grateful. Simply blaming one side, whether bug reporter or a random developer, for not being the sucker doesn't help anyone. Jörn -- Joern's library part 2: http://www.art.net/~hopkins/Don/unix-haters/tirix/embarrassing-memo.html ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 21:33 ` Jörn Engel @ 2007-11-13 21:56 ` Andrew Morton 2007-11-13 22:24 ` Jörn Engel 2007-11-13 22:29 ` Mark Lord 1 sibling, 1 reply; 268+ messages in thread From: Andrew Morton @ 2007-11-13 21:56 UTC (permalink / raw) To: Jörn Engel Cc: Mark Lord, Ingo Molnar, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, David Miller On Tue, 13 Nov 2007 22:33:58 +0100 Jörn Engel <joern@logfs.org> wrote: > On Tue, 13 November 2007 15:18:07 -0500, Mark Lord wrote: > > > > I just find it weird that something can be known broken for several -rc* > > kernels before I happen to install it, discover it's broken on my own > > machine, > > and then I track it down, fix it, and submit the patch, generally all > > within a > > couple of hours. Where the heck was the dude(ess) that broke it ?? AWOL. > > > > And when I receive hostility from the "maintainers" of said code for fixing > > their bugs, well.. that really motivates me to continue reporting new ones.. > > Given a decent bug report, I agree that having the bug not looked at is > shameful. But what can a developer do if a bug report effectively reads > "there is some bug somewhere in recent kernels"? How can I know that in > this particular case it is my bug that I introduced? It could just as > easily be 50 other people and none of them are eager to debug it unless > they suspect it to be their bug. It's relatively common that a regression in subsystem A will manifest as a failure in subsystem B, and the report initially lands on the desk of the subsystem B developers. But that's OK. The subsystem B people are the ones with the expertise to be able to work out where the bug resides and to help the subsystem A people understand what went wrong. Alas, sometimes the B people will just roll eyes and do nothing because they know the problem wasn't in their code. Sometimes. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 21:56 ` Andrew Morton @ 2007-11-13 22:24 ` Jörn Engel 2007-11-13 22:43 ` Andrew Morton 0 siblings, 1 reply; 268+ messages in thread From: Jörn Engel @ 2007-11-13 22:24 UTC (permalink / raw) To: Andrew Morton Cc: Jörn Engel, Mark Lord, Ingo Molnar, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, David Miller On Tue, 13 November 2007 13:56:58 -0800, Andrew Morton wrote: > > It's relatively common that a regression in subsystem A will manifest as a > failure in subsystem B, and the report initially lands on the desk of the > subsystem B developers. > > But that's OK. The subsystem B people are the ones with the expertise to > be able to work out where the bug resides and to help the subsystem A > people understand what went wrong. > > Alas, sometimes the B people will just roll eyes and do nothing because > they know the problem wasn't in their code. Sometimes. And sometimes the A people will ignore the B people after the root cause has been worked out. Do you have a good idea how to shame A into action? Should I put you on Cc:? Right now I'm in the eye-rolling phase. Jörn -- The cost of changing business rules is much more expensive for software than for a secretaty. -- unknown ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 22:24 ` Jörn Engel @ 2007-11-13 22:43 ` Andrew Morton 0 siblings, 0 replies; 268+ messages in thread From: Andrew Morton @ 2007-11-13 22:43 UTC (permalink / raw) To: Jörn Engel Cc: Mark Lord, Ingo Molnar, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, David Miller On Tue, 13 Nov 2007 23:24:14 +0100 Jörn Engel <joern@logfs.org> wrote: > On Tue, 13 November 2007 13:56:58 -0800, Andrew Morton wrote: > > > > It's relatively common that a regression in subsystem A will manifest as a > > failure in subsystem B, and the report initially lands on the desk of the > > subsystem B developers. > > > > But that's OK. The subsystem B people are the ones with the expertise to > > be able to work out where the bug resides and to help the subsystem A > > people understand what went wrong. > > > > Alas, sometimes the B people will just roll eyes and do nothing because > > they know the problem wasn't in their code. Sometimes. > > And sometimes the A people will ignore the B people after the root cause > has been worked out. Do you have a good idea how to shame A into > action? Should I put you on Cc:? Right now I'm in the eye-rolling > phase. > Well, that's the problem, isn't it? The best I can come up with is to suggest that all the info be captured in a bugzilla report so that at least it doesn't get forgotten about. I suppose that other options are a) try to fix it yourself. I'll take the patch and as long as we make a big enough mess of it, someone who knows what they're doing might fix it for real. b) If it was a regression, identify the offending commit and we'll just revert it. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 21:33 ` Jörn Engel 2007-11-13 21:56 ` Andrew Morton @ 2007-11-13 22:29 ` Mark Lord 1 sibling, 0 replies; 268+ messages in thread From: Mark Lord @ 2007-11-13 22:29 UTC (permalink / raw) To: Jörn Engel Cc: Mark Lord, Ingo Molnar, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, Andrew Morton, David Miller Jörn Engel wrote: > On Tue, 13 November 2007 15:18:07 -0500, Mark Lord wrote: >> I just find it weird that something can be known broken for several -rc* >> kernels before I happen to install it, discover it's broken on my own machine, >> and then I track it down, fix it, and submit the patch, generally all within a >> couple of hours. Where the heck was the dude(ess) that broke it ?? AWOL. >> >> And when I receive hostility from the "maintainers" of said code for fixing >> their bugs, well.. that really motivates me to continue reporting new ones.. > > Given a decent bug report, I agree that having the bug not looked at is > shameful. But what can a developer do if a bug report effectively reads > "there is some bug somewhere in recent kernels"? How can I know that in > this particular case it is my bug that I introduced? It could just as > easily be 50 other people and none of them are eager to debug it unless > they suspect it to be their bug. .. Most of the regressions we have are easily identifiable and not of the type where there could "50 other people" touching the relevant code. As a developer (and former subsystem maintainer) I look hard at my own code when there's a bug reported that could have come from recent updates there. Usually there are not that many updates to consider, and tracking it down is just a matter of being willing to do so. Of late, I've given up on other developers fixing the stuff they break on my own machines, and I generally just dive into totally unfamiliar code, and find and fix it myself. Quite quickly, usually. And the bugs are often very apparent just from looking at the source code diffs (patches) from recent history in the code that's not working. This is not rocket science, and it doesn't require a log2 download/rebuild/reboot process. But yes, there are more difficult ones, like when my machine crashed yesterday with some form of corruption showing up during JBD filesystem I/O. That's one where the problem isn't going to be obvious to anyone, and I don't actually expect anyone to go looking for it right away. If more such events happen, then it will get more attention. But things like broken drivers, in almost every case those are trivial to track down and fix, even for people not familar with that specific code. > This is a common problem and fairly unrelated to linux in general or the > kernel in particular. Who is going to be the sucker that figures out > which developer the bug belongs to? And I have yet to find a project, > commercial or opensource, where volunteers flock to become such a > sucker. > > One option is to push this role to the bug reporter. Another is to > strong-arm some developers into this role, by whatever means. A third > would be for $LARGE_COMPANY to hire some people. If you have a better > idea or would volunteer your time, I'd be grateful. Simply blaming one > side, whether bug reporter or a random developer, for not being the > sucker doesn't help anyone. .. Nobody's blaming anyone here. I'm just asking that developers here do more like our Top Penguin does, and actually look at problems and try to understand them and suggest fixes to try. And not rely solely on the git-bisect crutch. It's a good crutch, provided the reporter is a kernel developer, or has a lot of time on their hands. But we debugged Linux here for a long time without it. And I already volunteer my time here, thanks, BIG TIME, since 1992 or so. Cheers ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 20:18 ` Mark Lord 2007-11-13 21:33 ` Jörn Engel @ 2007-11-13 23:40 ` Russell King 2007-11-14 1:56 ` David Miller 1 sibling, 1 reply; 268+ messages in thread From: Russell King @ 2007-11-13 23:40 UTC (permalink / raw) To: Mark Lord Cc: Ingo Molnar, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, Andrew Morton, David Miller On Tue, Nov 13, 2007 at 03:18:07PM -0500, Mark Lord wrote: > Russell King wrote: > > On Tue, Nov 13, 2007 at 09:08:32AM -0500, Mark Lord wrote: > >> Ingo Molnar wrote: > >> .. > >>> This is all QA-101 that _cannot be argued against on a rational basis_, > >>> it's just that these sorts of things have been largely ignored for > >>> years, in favor of the all-too-easy "open source means many eyeballs and > >>> that is our QA" answer, which is a _good_ answer but by far not the most > >>> intelligent answer! Today "many eyeballs" is simply not good enough and > >>> nature (and other OS projects) will route us around if we dont change. > >> .. > >> > >> QA-101 and "many eyeballs" are not at all in opposition. > >> The latter is how we find out about bugs on uncommon hardware, > >> and the former is what we need to track them and overall quality. > >> > >> A HUGE problem I have with current "efforts", is that once someone > >> reports a bug, the onus seems to be 99% on the *reporter* to find > >> the exact line of code or commit. Ghad what a repressive method. > > > > 99% on the reporter? Is that why I always try to understand the > > reporters problem (*provided* it's in an area I know about) and come > > up with a patch to test a theory or fix the issue? > .. > > Same here. > > I just find it weird that something can be known broken for several -rc* > kernels before I happen to install it, discover it's broken on my own machine, > and then I track it down, fix it, and submit the patch, generally all within a > couple of hours. Where the heck was the dude(ess) that broke it ?? AWOL. Same thing can be said for compile breakages as well. Looking at the latest kautobuild output: ARM ep93xx defconfig has been broken since 2.6.23-git1 due to: drivers/net/arm/ep93xx_eth.c:420: error: implicit declaration of function '__netif_rx_schedule_prep' caused by: [NET]: Make NAPI polling independent of struct net_device objects. ARM netx defconfig has been broken since 2.6.23-git1 due to: drivers/net/netx-eth.c: In function 'netx_eth_hard_start_xmit': drivers/net/netx-eth.c:131: error: 'dev' undeclared (first use in this function) drivers/net/netx-eth.c:131: error: (Each undeclared identifier is reported only once drivers/net/netx-eth.c:131: error: for each function it appears in.) drivers/net/netx-eth.c: In function 'netx_eth_receive': drivers/net/netx-eth.c:158: error: 'dev' undeclared (first use in this function) caused by: [NET] drivers/net: statistics cleanup #1 -- save memory and shrink code Haven't got a report for either of those, but Kautobuild lets people know if folk can be bothered to subscribe to its mailing list and/or look at the site occasionally. I suspect the maintainers of the above drivers aren't aware that their drivers are broken. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 23:40 ` Russell King @ 2007-11-14 1:56 ` David Miller 0 siblings, 0 replies; 268+ messages in thread From: David Miller @ 2007-11-14 1:56 UTC (permalink / raw) To: rmk+lkml Cc: liml, mingo, alsa-devel, netdev, linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input, akpm From: Russell King <rmk+lkml@arm.linux.org.uk> Date: Tue, 13 Nov 2007 23:40:33 +0000 > ARM ep93xx defconfig has been broken since 2.6.23-git1 due to: > > drivers/net/arm/ep93xx_eth.c:420: error: implicit declaration of function '__netif_rx_schedule_prep' > > caused by: [NET]: Make NAPI polling independent of struct net_device objects. > > ARM netx defconfig has been broken since 2.6.23-git1 due to: > > drivers/net/netx-eth.c: In function 'netx_eth_hard_start_xmit': > drivers/net/netx-eth.c:131: error: 'dev' undeclared (first use in this function) > drivers/net/netx-eth.c:131: error: (Each undeclared identifier is reported only once > drivers/net/netx-eth.c:131: error: for each function it appears in.) > drivers/net/netx-eth.c: In function 'netx_eth_receive': > drivers/net/netx-eth.c:158: error: 'dev' undeclared (first use in this function) > > caused by: [NET] drivers/net: statistics cleanup #1 -- save memory and shrink code > I'll fix these up, thanks for the report. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 14:08 ` Mark Lord ` (3 preceding siblings ...) 2007-11-13 19:37 ` [BUG] New Kernel Bugs Russell King @ 2007-11-14 0:34 ` Denys Vlasenko 2007-11-15 3:06 ` Neil Brown 4 siblings, 1 reply; 268+ messages in thread From: Denys Vlasenko @ 2007-11-14 0:34 UTC (permalink / raw) To: Mark Lord Cc: Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tuesday 13 November 2007 07:08, Mark Lord wrote: > Ingo Molnar wrote: > .. > > > This is all QA-101 that _cannot be argued against on a rational basis_, > > it's just that these sorts of things have been largely ignored for > > years, in favor of the all-too-easy "open source means many eyeballs and > > that is our QA" answer, which is a _good_ answer but by far not the most > > intelligent answer! Today "many eyeballs" is simply not good enough and > > nature (and other OS projects) will route us around if we dont change. > > .. > > QA-101 and "many eyeballs" are not at all in opposition. > The latter is how we find out about bugs on uncommon hardware, > and the former is what we need to track them and overall quality. > > A HUGE problem I have with current "efforts", is that once someone > reports a bug, the onus seems to be 99% on the *reporter* to find > the exact line of code or commit. Ghad what a repressive method. This is the only method that scales. Developer has only 24 hours in each day, and sometimes he needs to eat, sleep, and maybe even pay attention to e.g. his kids. But bug reporters are much more numerous and they have more hours in one day combined. BUT - it means that developers should try to increase user base, not scare users away. > And if the "developer" who broke the damn thing, or who at least > "claims" to be supporting that code, cannot "reproduce" the bug, > they drop it completely. Developer should let reporter know that reporter needs to help a bit here. Sometimes a bit of hand holding is needed, but it pays off because you breed more qualified testers/bug reporters. > Contrast that flawed approach with how Linus does things.. > he thinks through the symptoms, matches them to the code, > and figures out what the few possibilities might be, > and feeds back some trial balloon patches for the bug reporter to try. > > MUCH better. > > And remember, *I'm* an old-time Linux kernel developer.. just think about > the people reporting bugs who haven't been around here since 1992.. Yes. Developers should not grow more and more unhelpful and arrogant towards their users just because inexperienced users send incomplete/poorly written bug reports. They need to provide help, not humiliate/ignore. I think we agree here. -- vda ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 0:34 ` Denys Vlasenko @ 2007-11-15 3:06 ` Neil Brown 0 siblings, 0 replies; 268+ messages in thread From: Neil Brown @ 2007-11-15 3:06 UTC (permalink / raw) To: Denys Vlasenko Cc: Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-input, bugme-daemon On Tuesday November 13, vda.linux@googlemail.com wrote: > On Tuesday 13 November 2007 07:08, Mark Lord wrote: > > Ingo Molnar wrote: > > .. > > > > > This is all QA-101 that _cannot be argued against on a rational basis_, > > > it's just that these sorts of things have been largely ignored for > > > years, in favor of the all-too-easy "open source means many eyeballs and > > > that is our QA" answer, which is a _good_ answer but by far not the most > > > intelligent answer! Today "many eyeballs" is simply not good enough and > > > nature (and other OS projects) will route us around if we dont change. > > > > .. > > > > QA-101 and "many eyeballs" are not at all in opposition. > > The latter is how we find out about bugs on uncommon hardware, > > and the former is what we need to track them and overall quality. > > > > A HUGE problem I have with current "efforts", is that once someone > > reports a bug, the onus seems to be 99% on the *reporter* to find > > the exact line of code or commit. Ghad what a repressive method. > > This is the only method that scales. That sounds overly hash, and the rest of you mail sounds much more moderate and sensible - I can only assume you were using hyperbole?? Putting the "onus on the reporter" is simply not going to work unless you have a business relationship. In the community, we are all volunteering our time (well, maybe my employer is volunteering my time to do community support, but the effect is the same). I would hope that the focus of developers is to empower bug reporters to provide further information (and as has been said, "git bisect" is a great empowerer). Some people will be incredibly help, especially if you ask politely and say thankyou. Others won't for any of a number of reasons - and maybe that means their bug won't get fixed. To my eyes, the "only method that scales" is investing effort in encouraging and training bug reporters. Some of that effort might not produce results, but when others among those you have encouraged start answering the newbee questions on the list and save you the time, you get a distinct feeling that it was all worth while. I think we are in agreement - I just wanted to take issue with that one sentence :-) The rest is great. NeilBrown > > Developer has only 24 hours in each day, and sometimes he needs to eat, > sleep, and maybe even pay attention to e.g. his kids. > > But bug reporters are much more numerous and they have more > hours in one day combined. > > BUT - it means that developers should try to increase user base, > not scare users away. > > > And if the "developer" who broke the damn thing, or who at least > > "claims" to be supporting that code, cannot "reproduce" the bug, > > they drop it completely. > > Developer should let reporter know that reporter needs to help > a bit here. Sometimes a bit of hand holding is needed, but it > pays off because you breed more qualified testers/bug reporters. > > > Contrast that flawed approach with how Linus does things.. > > he thinks through the symptoms, matches them to the code, > > and figures out what the few possibilities might be, > > and feeds back some trial balloon patches for the bug reporter to try. > > > > MUCH better. > > > > And remember, *I'm* an old-time Linux kernel developer.. just think about > > the people reporting bugs who haven't been around here since 1992.. > > Yes. Developers should not grow more and more unhelpful > and arrogant towards their users just because inexperienced > users send incomplete/poorly written bug reports. > They need to provide help, not humiliate/ignore. > > I think we agree here. > -- > vda > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 13:40 ` Ingo Molnar 2007-11-13 14:08 ` Mark Lord @ 2007-11-13 16:55 ` Randy Dunlap 2007-11-14 14:08 ` Ingo Molnar 1 sibling, 1 reply; 268+ messages in thread From: Randy Dunlap @ 2007-11-13 16:55 UTC (permalink / raw) To: Ingo Molnar Cc: Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tue, 13 Nov 2007 14:40:29 +0100 Ingo Molnar wrote: > > * Andrew Morton <akpm@linux-foundation.org> wrote: > > > > > Do you believe that our response to bug reports is adequate? > > > > > > Do you feel that making us feel and look like shit helps? > > > > That doesn't answer my question. > > > > See, first we need to work out whether we have a problem. If we do > > this, then we can then have a think about what to do about it. > > > > I tried to convince the 2006 KS attendees that we have a problem and I > > resoundingly failed. People seemed to think that we're doing OK. We were a minority. > > But it appears that data such as this contradicts that belief. > > > > This is not a minor matter. If the kernel _is_ slowly deteriorating > > then this won't become readily apparent until it has been happening > > for a number of years. By that stage there will be so much work to do > > to get us back to an acceptable level that it will take a huge effort. > > And it will take a long time after that for the kerel to get its > > reputation back. > > > > So it is important that we catch deterioration *early* if it is > > happening. > [agree with most of Ingo's moaning] > (and this is in no way directed at the networking folks - it holds for > all of us. I have one main complaint about networking: the separate > netdev list is a bad idea - networking regressions should be discussed > and fixed on lkml, like most other subsystems are. Any artificial split > of the lk discussion space is bad.) but here I disagree. LKML is already too busy and noisy. Major subsystems need their own discussion areas. --- ~Randy ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 16:55 ` Randy Dunlap @ 2007-11-14 14:08 ` Ingo Molnar 2007-11-14 17:38 ` Randy Dunlap 2007-11-14 19:56 ` David Miller 0 siblings, 2 replies; 268+ messages in thread From: Ingo Molnar @ 2007-11-14 14:08 UTC (permalink / raw) To: Randy Dunlap Cc: Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon * Randy Dunlap <rdunlap@xenotime.net> wrote: > > (and this is in no way directed at the networking folks - it holds > > for all of us. I have one main complaint about networking: the > > separate netdev list is a bad idea - networking regressions should > > be discussed and fixed on lkml, like most other subsystems are. Any > > artificial split of the lk discussion space is bad.) > > but here I disagree. LKML is already too busy and noisy. Major > subsystems need their own discussion areas. That's a stupid argument. We lose much more by forced isolation of discussion than what we win by having less traffic! It's _MUCH_ easier to narrow down information (by filter by threads, by topics, by people, etc.) than it is to gobble information together from various fractured sources. We learned it _again and again_ that isolation of kernel discussions causes bad things. In fact this thread is the very example: David points out that on netdev some of those bugs were already discussed and resolved. Had it been all on lkml we'd all be aware of it. this is a single kernel project that is released together as one codebase, so a central place of discussion is obvious and common-sense. so please stop this "too busy and too noisy" nonsense already. It was nonsense 10 years ago and it's nonsense today. In 10 years the kernel grew from a 1 million lines codebase to an 8 million lines codebase, so what? Deal with it and be intelligent about filtering your information influx instead of imposing a hard pre-filtering criteria that restricts intelligent processing of information. Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 14:08 ` Ingo Molnar @ 2007-11-14 17:38 ` Randy Dunlap 2007-11-14 18:23 ` J. Bruce Fields 2007-11-14 20:16 ` Ingo Molnar 2007-11-14 19:56 ` David Miller 1 sibling, 2 replies; 268+ messages in thread From: Randy Dunlap @ 2007-11-14 17:38 UTC (permalink / raw) To: Ingo Molnar Cc: Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Wed, 14 Nov 2007 15:08:47 +0100 Ingo Molnar wrote: > > * Randy Dunlap <rdunlap@xenotime.net> wrote: > > > > (and this is in no way directed at the networking folks - it holds > > > for all of us. I have one main complaint about networking: the > > > separate netdev list is a bad idea - networking regressions should > > > be discussed and fixed on lkml, like most other subsystems are. Any > > > artificial split of the lk discussion space is bad.) > > > > but here I disagree. LKML is already too busy and noisy. Major > > subsystems need their own discussion areas. > > That's a stupid argument. We lose much more by forced isolation of > discussion than what we win by having less traffic! It's _MUCH_ easier > to narrow down information (by filter by threads, by topics, by people, > etc.) than it is to gobble information together from various fractured > sources. We learned it _again and again_ that isolation of kernel > discussions causes bad things. > > In fact this thread is the very example: David points out that on netdev > some of those bugs were already discussed and resolved. Had it been all > on lkml we'd all be aware of it. or had <someone> been on netdev. > this is a single kernel project that is released together as one > codebase, so a central place of discussion is obvious and common-sense. Central doesn't have to mean one-and-only-one-list-for-everything. > so please stop this "too busy and too noisy" nonsense already. It was > nonsense 10 years ago and it's nonsense today. In 10 years the kernel > grew from a 1 million lines codebase to an 8 million lines codebase, so > what? Deal with it and be intelligent about filtering your information > influx instead of imposing a hard pre-filtering criteria that restricts > intelligent processing of information. So you have a preferred method of handling email. Please don't force it on the rest of us. I'll plan to use lkml-list-only when you have convinced DaveM to drop all of the other mailing lists at vger.kernel.org. Yeah, sure. --- ~Randy ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 17:38 ` Randy Dunlap @ 2007-11-14 18:23 ` J. Bruce Fields 2007-11-15 2:50 ` Neil Brown 2007-11-14 20:16 ` Ingo Molnar 1 sibling, 1 reply; 268+ messages in thread From: J. Bruce Fields @ 2007-11-14 18:23 UTC (permalink / raw) To: Randy Dunlap Cc: Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Wed, Nov 14, 2007 at 09:38:20AM -0800, Randy Dunlap wrote: > On Wed, 14 Nov 2007 15:08:47 +0100 Ingo Molnar wrote: > > so please stop this "too busy and too noisy" nonsense already. It was > > nonsense 10 years ago and it's nonsense today. In 10 years the kernel > > grew from a 1 million lines codebase to an 8 million lines codebase, so > > what? Deal with it and be intelligent about filtering your information > > influx instead of imposing a hard pre-filtering criteria that restricts > > intelligent processing of information. > > So you have a preferred method of handling email. Please don't > force it on the rest of us. I'd be curious for any pointers on tools, actually. I "read" (ok, skim) lkml but still overlook relevant bug reports occasionally. (Fortunately, between Trond and Andrew and others forwarding things it's not actually a problem, but I'm still curious). --b. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 18:23 ` J. Bruce Fields @ 2007-11-15 2:50 ` Neil Brown 2007-11-16 0:05 ` J. Bruce Fields 0 siblings, 1 reply; 268+ messages in thread From: Neil Brown @ 2007-11-15 2:50 UTC (permalink / raw) To: J. Bruce Fields Cc: Randy Dunlap, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-input, bugme-daemon On Wednesday November 14, bfields@fieldses.org wrote: > On Wed, Nov 14, 2007 at 09:38:20AM -0800, Randy Dunlap wrote: > > On Wed, 14 Nov 2007 15:08:47 +0100 Ingo Molnar wrote: > > > so please stop this "too busy and too noisy" nonsense already. It was > > > nonsense 10 years ago and it's nonsense today. In 10 years the kernel > > > grew from a 1 million lines codebase to an 8 million lines codebase, so > > > what? Deal with it and be intelligent about filtering your information > > > influx instead of imposing a hard pre-filtering criteria that restricts > > > intelligent processing of information. > > > > So you have a preferred method of handling email. Please don't > > force it on the rest of us. > > I'd be curious for any pointers on tools, actually. I "read" (ok, skim) > lkml but still overlook relevant bug reports occasionally. > (Fortunately, between Trond and Andrew and others forwarding things it's > not actually a problem, but I'm still curious). Virtual Folders. I use VM mode in EMACS, but I believe some other mail readers have the same functionality. I have a virtual folder called "nfs" which shows me all mail in my inbox which has the string 'nfs' or 'lockd' in a To, Cc, or Subject field. When I visit that folder, I see all mail about nfs, whether it was sent to me personally, or to a relevant list, or to lkml. Admittedly if someone doesn't bother to choose a meaningful Subject, then I might miss that. I think this mostly happens when Andrew sends a "-mm" announcement, asked people to change the subject line when following up, and someone follows up without changing the subject line and say "NFS doesn't work any more". I have another virtual folder which matches "md" and "raid" and "mdadm" in any header (so when the people from coraid.com talk about ATA over Ethernet, that gets badly filed, but it is a small cost). Then I have the "bkernel" (boring kernel) folder for all mail from lkml that doesn't mention nfs or raid or md, and isn't from or to me. That folder I skim every week or so and just read the juicy debates and look for interesting tidbits from interesting people - then delete the whole folder, mostly unread. I don't think I could cope with mail without virtual folders. NeilBrown ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-15 2:50 ` Neil Brown @ 2007-11-16 0:05 ` J. Bruce Fields 0 siblings, 0 replies; 268+ messages in thread From: J. Bruce Fields @ 2007-11-16 0:05 UTC (permalink / raw) To: Neil Brown Cc: Randy Dunlap, Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-input, bugme-daemon On Thu, Nov 15, 2007 at 01:50:43PM +1100, Neil Brown wrote: > Virtual Folders. > > I use VM mode in EMACS, but I believe some other mail readers have the > same functionality. > I have a virtual folder called "nfs" which shows me all mail in my > inbox which has the string 'nfs' or 'lockd' in a To, Cc, or Subject > field. When I visit that folder, I see all mail about nfs, whether it > was sent to me personally, or to a relevant list, or to lkml. Hm (googling around for "mutt" and "virtual folders"): looks like I can get most of the way there in mutt with some macros based on its "limit" command: http://www.tummy.com/journals/entries/jafo_20060303_044440 Thanks.--b. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 17:38 ` Randy Dunlap 2007-11-14 18:23 ` J. Bruce Fields @ 2007-11-14 20:16 ` Ingo Molnar 2007-11-14 20:29 ` Randy Dunlap 1 sibling, 1 reply; 268+ messages in thread From: Ingo Molnar @ 2007-11-14 20:16 UTC (permalink / raw) To: Randy Dunlap Cc: Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon * Randy Dunlap <rdunlap@xenotime.net> wrote: > On Wed, 14 Nov 2007 15:08:47 +0100 Ingo Molnar wrote: > > > > > * Randy Dunlap <rdunlap@xenotime.net> wrote: > > > > > > (and this is in no way directed at the networking folks - it holds > > > > for all of us. I have one main complaint about networking: the > > > > separate netdev list is a bad idea - networking regressions should > > > > be discussed and fixed on lkml, like most other subsystems are. Any > > > > artificial split of the lk discussion space is bad.) > > > > > > but here I disagree. LKML is already too busy and noisy. Major > > > subsystems need their own discussion areas. > > > > That's a stupid argument. We lose much more by forced isolation of > > discussion than what we win by having less traffic! It's _MUCH_ ^^^^^^^^^^^^ > > easier to narrow down information (by filter by threads, by topics, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > by people, etc.) than it is to gobble information together from ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > various fractured sources. We learned it _again and again_ that ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > isolation of kernel discussions causes bad things. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > In fact this thread is the very example: David points out that on > > netdev some of those bugs were already discussed and resolved. Had > > it been all on lkml we'd all be aware of it. > > or had <someone> been on netdev. countered by the underlined sentences above, just in case you missed it. Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 20:16 ` Ingo Molnar @ 2007-11-14 20:29 ` Randy Dunlap 2007-11-14 20:37 ` Ingo Molnar 0 siblings, 1 reply; 268+ messages in thread From: Randy Dunlap @ 2007-11-14 20:29 UTC (permalink / raw) To: Ingo Molnar Cc: Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Wed, 14 Nov 2007 21:16:39 +0100 Ingo Molnar wrote: > countered by the underlined sentences above, just in case you missed it. I didn't miss your claim. --- ~Randy ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 20:29 ` Randy Dunlap @ 2007-11-14 20:37 ` Ingo Molnar 2007-11-14 21:05 ` Randy Dunlap 0 siblings, 1 reply; 268+ messages in thread From: Ingo Molnar @ 2007-11-14 20:37 UTC (permalink / raw) To: Randy Dunlap Cc: Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon * Randy Dunlap <rdunlap@xenotime.net> wrote: > On Wed, 14 Nov 2007 21:16:39 +0100 Ingo Molnar wrote: > > > countered by the underlined sentences above, just in case you missed > > it. > > I didn't miss your claim. ok, then you conceded it by not replying to it? good ;-) Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 20:37 ` Ingo Molnar @ 2007-11-14 21:05 ` Randy Dunlap 0 siblings, 0 replies; 268+ messages in thread From: Randy Dunlap @ 2007-11-14 21:05 UTC (permalink / raw) To: Ingo Molnar Cc: Andrew Morton, David Miller, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Wed, 14 Nov 2007 21:37:37 +0100 Ingo Molnar wrote: > ok, then you conceded it by not replying to it? good ;-) No, I don't intend to carry on this discussion, but I appreciate the smiley. --- ~Randy ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 14:08 ` Ingo Molnar 2007-11-14 17:38 ` Randy Dunlap @ 2007-11-14 19:56 ` David Miller 2007-11-14 20:09 ` James Bottomley 2007-11-14 20:48 ` Ingo Molnar 1 sibling, 2 replies; 268+ messages in thread From: David Miller @ 2007-11-14 19:56 UTC (permalink / raw) To: mingo Cc: rdunlap, akpm, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon From: Ingo Molnar <mingo@elte.hu> Date: Wed, 14 Nov 2007 15:08:47 +0100 > In fact this thread is the very example: David points out that on netdev > some of those bugs were already discussed and resolved. Had it been all > on lkml we'd all be aware of it. That's a rediculious argument. One other reason these bugs are resolved, is that the networking developers only need to subscribe to netdev and not have to listen to all the noise on lkml. People who want to manage bugs know what list to look on and contact about problems. Dumping even more crap on lkml is not the answer. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 19:56 ` David Miller @ 2007-11-14 20:09 ` James Bottomley 2007-11-14 20:54 ` Ingo Molnar 2007-11-14 20:48 ` Ingo Molnar 1 sibling, 1 reply; 268+ messages in thread From: James Bottomley @ 2007-11-14 20:09 UTC (permalink / raw) To: David Miller Cc: mingo, rdunlap, akpm, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Wed, 2007-11-14 at 11:56 -0800, David Miller wrote: > From: Ingo Molnar <mingo@elte.hu> > Date: Wed, 14 Nov 2007 15:08:47 +0100 > > > In fact this thread is the very example: David points out that on netdev > > some of those bugs were already discussed and resolved. Had it been all > > on lkml we'd all be aware of it. > > That's a rediculious argument. > > One other reason these bugs are resolved, is that the networking > developers only need to subscribe to netdev and not have to listen to > all the noise on lkml. > > People who want to manage bugs know what list to look on and > contact about problems. > > Dumping even more crap on lkml is not the answer. I agree totally with David, and this goes for SCSI too. If it's not reported on linux-scsi, there's a significant chance of us missing the bug report. The fact that some people notice bugs go past on LKML and forward them to linux-scsi is a happy accident and not necessarily something to rely on. LKML has 10-20x the traffic of linux-scsi and a much smaller signal to noise ratio. Having a specialist list where all the experts in the field hangs out actually enhances our ability to fix bugs. James ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 20:09 ` James Bottomley @ 2007-11-14 20:54 ` Ingo Molnar 0 siblings, 0 replies; 268+ messages in thread From: Ingo Molnar @ 2007-11-14 20:54 UTC (permalink / raw) To: James Bottomley Cc: David Miller, rdunlap, akpm, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon * James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > On Wed, 2007-11-14 at 11:56 -0800, David Miller wrote: > > From: Ingo Molnar <mingo@elte.hu> > > Date: Wed, 14 Nov 2007 15:08:47 +0100 > > > > > In fact this thread is the very example: David points out that on netdev > > > some of those bugs were already discussed and resolved. Had it been all > > > on lkml we'd all be aware of it. > > > > That's a rediculious argument. > > > > One other reason these bugs are resolved, is that the networking > > developers only need to subscribe to netdev and not have to listen > > to all the noise on lkml. > > > > People who want to manage bugs know what list to look on and contact > > about problems. > > > > Dumping even more crap on lkml is not the answer. > > I agree totally with David, and this goes for SCSI too. If it's not > reported on linux-scsi, there's a significant chance of us missing the > bug report. The fact that some people notice bugs go past on LKML and > forward them to linux-scsi is a happy accident and not necessarily > something to rely on. > > LKML has 10-20x the traffic of linux-scsi and a much smaller signal to > noise ratio. Having a specialist list where all the experts in the > field hangs out actually enhances our ability to fix bugs. you are actually proving my point. People have to scan lkml for SCSI regressions _anyway_, because otherwise _you_ would miss them. In the case a user is fortunate enough to realize that a regression is SCSI related, and he is lucky enough to pre-select the SCSI mailing list in the first go, he might get a fix from you. That already reduces the number of useful bugreports by about an order of magnitude. Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 19:56 ` David Miller 2007-11-14 20:09 ` James Bottomley @ 2007-11-14 20:48 ` Ingo Molnar 2007-11-14 21:05 ` david 1 sibling, 1 reply; 268+ messages in thread From: Ingo Molnar @ 2007-11-14 20:48 UTC (permalink / raw) To: David Miller Cc: rdunlap, akpm, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon * David Miller <davem@davemloft.net> wrote: > From: Ingo Molnar <mingo@elte.hu> > Date: Wed, 14 Nov 2007 15:08:47 +0100 > > > In fact this thread is the very example: David points out that on netdev > > some of those bugs were already discussed and resolved. Had it been all > > on lkml we'd all be aware of it. > > That's a rediculious argument. > > One other reason these bugs are resolved, is that the networking > developers only need to subscribe to netdev and not have to listen to > all the noise on lkml. what noise? If someone really wants networking discussions only, use this procmail rule: :0 HBc * .*net: * sched-patches to separate it into an extra folder and use "net: " as an agreed upon Subject line if you really want to narrow things down. (But there would still be all the other mail just in case the developer has to look at the wider picture. There would be no "I'm only subscribed to netdev" excuse. ) but there should still be one central repository for all kernel discussions - just like there is one central repository for all kernel code. > People who want to manage bugs know what list to look on and contact > about problems. i think that's the problem. Developers (and here i dont mean you) who want to do "development only", without being exposed to the global state of the kernel and without being exposed to bugs. I think that's the basic mindset difference. That is one of the factor that is causing assymetric allocation of developers and the increasing detachment from reality. > Dumping even more crap on lkml is not the answer. that "crap" that i'd like to see dumped upon lkml would be netdev traffic mainly - most of the other kernel development lists (and i'm subscribed to many of them) are low-traffic. netdev is the main reason why we cannot do a "one common discussion forum" approach. Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 20:48 ` Ingo Molnar @ 2007-11-14 21:05 ` david 0 siblings, 0 replies; 268+ messages in thread From: david @ 2007-11-14 21:05 UTC (permalink / raw) To: Ingo Molnar Cc: David Miller, rdunlap, akpm, protasnb, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Wed, 14 Nov 2007, Ingo Molnar wrote: >> Dumping even more crap on lkml is not the answer. > > that "crap" that i'd like to see dumped upon lkml would be netdev > traffic mainly - most of the other kernel development lists (and i'm > subscribed to many of them) are low-traffic. netdev is the main reason > why we cannot do a "one common discussion forum" approach. hmm, how much work would it be to tweak the mail software on vger to have a linux-all@vger.kernel.org that got a copy of any linux-* list hosted by vger. this would solve half the problem (people on linux-kernel not seeing discussions on the other lists) David Lang ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 11:15 ` Andrew Morton ` (2 preceding siblings ...) 2007-11-13 11:39 ` David Miller @ 2007-11-13 11:47 ` Jarek Poplawski 2007-11-13 13:58 ` Mark Lord ` (7 subsequent siblings) 11 siblings, 0 replies; 268+ messages in thread From: Jarek Poplawski @ 2007-11-13 11:47 UTC (permalink / raw) To: Andrew Morton Cc: Natalie Protasevich, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On 13-11-2007 12:15, Andrew Morton wrote: ... > Zero responses from developers ... > No response from developers ... > Andreas did some work, seemed to lose interest. ... > Rafael poked Thomas a week ago, to no effect. Thomas has been travelling. Looks like very reproducible! Maybe you should add this to ...bugzilla? Regards, Jarek P. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 11:15 ` Andrew Morton ` (3 preceding siblings ...) 2007-11-13 11:47 ` Jarek Poplawski @ 2007-11-13 13:58 ` Mark Lord 2007-11-13 14:18 ` Mark Lord 2007-11-13 16:07 ` Thomas Gleixner 2007-11-13 15:21 ` Bartlomiej Zolnierkiewicz ` (6 subsequent siblings) 11 siblings, 2 replies; 268+ messages in thread From: Mark Lord @ 2007-11-13 13:58 UTC (permalink / raw) To: Andrew Morton Cc: Natalie Protasevich, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon Andrew Morton wrote: > On Mon, 12 Nov 2007 22:42:32 -0800 "Natalie Protasevich" <protasnb@gmail.com> wrote: .. >> with CONFIG_NO_HZ and/or CONFIG_HPET_TIMER set kernel 2.6.23 doesn't >> boot (ARM, Timer) >> http://bugzilla.kernel.org/show_bug.cgi?id=9229 >> Kernel: 2.6.23 > > No response from developers .. Note: that same bug exists/existed on i386 back when NO_HZ was introduced (2.6.21?). I still see it from time to time on my Quad core system (very rare), but not any more on my Duo notebook where it used to happen about 1 in n boots (n < 10). AFAICT no fix was ever released for it. >> Suspend to RAM resume hangs on a tickless (NO_HZ) kernel >> http://bugzilla.kernel.org/show_bug.cgi?id=9275 >> Kernel: 2.6.23 >> This is HP notebook nc6320 T2400 945GM > No response from developers .. I *still* get very slow resume-from-RAM quite often here (new in 2.6.22 kernel, wasn't there in early 2.6.23-rc*). Something eventually times out after a minute or so and it comes back. Cannot make it happen reliably, unless I'm in a hurry to get something done. :) I suspect USB here, probably the same loopy bug that we added a "loop limit failsafe" for back in 2.6.21(?). ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 13:58 ` Mark Lord @ 2007-11-13 14:18 ` Mark Lord 2007-11-13 16:08 ` Thomas Gleixner 2007-11-13 16:07 ` Thomas Gleixner 1 sibling, 1 reply; 268+ messages in thread From: Mark Lord @ 2007-11-13 14:18 UTC (permalink / raw) To: Andrew Morton Cc: Natalie Protasevich, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon Mark Lord wrote: > Andrew Morton wrote: >> On Mon, 12 Nov 2007 22:42:32 -0800 "Natalie Protasevich" >> <protasnb@gmail.com> wrote: > .. .. >>> Suspend to RAM resume hangs on a tickless (NO_HZ) kernel >>> http://bugzilla.kernel.org/show_bug.cgi?id=9275 >>> Kernel: 2.6.23 >>> This is HP notebook nc6320 T2400 945GM >> No response from developers > .. > > I *still* get very slow resume-from-RAM quite often here > (new in 2.6.22 kernel, wasn't there in early 2.6.23-rc*). .. Typo. That should have said: > (new in 2.6.23 kernel, wasn't there in early 2.6.23-rc*). ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 14:18 ` Mark Lord @ 2007-11-13 16:08 ` Thomas Gleixner 0 siblings, 0 replies; 268+ messages in thread From: Thomas Gleixner @ 2007-11-13 16:08 UTC (permalink / raw) To: Mark Lord Cc: Andrew Morton, Natalie Protasevich, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tue, 13 Nov 2007, Mark Lord wrote: > Mark Lord wrote: > > Andrew Morton wrote: > > > On Mon, 12 Nov 2007 22:42:32 -0800 "Natalie Protasevich" > > > <protasnb@gmail.com> wrote: > > .. > .. > > > > Suspend to RAM resume hangs on a tickless (NO_HZ) kernel > > > > http://bugzilla.kernel.org/show_bug.cgi?id=9275 > > > > Kernel: 2.6.23 > > > > This is HP notebook nc6320 T2400 945GM > > > No response from developers > > .. > > > > I *still* get very slow resume-from-RAM quite often here > > (new in 2.6.22 kernel, wasn't there in early 2.6.23-rc*). > .. > > Typo. That should have said: > > > (new in 2.6.23 kernel, wasn't there in early 2.6.23-rc*). Just asked that :) Is there a chance to bisect that ? Thanks, tglx ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 13:58 ` Mark Lord 2007-11-13 14:18 ` Mark Lord @ 2007-11-13 16:07 ` Thomas Gleixner 2007-11-13 17:47 ` Mark Lord ` (2 more replies) 1 sibling, 3 replies; 268+ messages in thread From: Thomas Gleixner @ 2007-11-13 16:07 UTC (permalink / raw) To: Mark Lord Cc: Andrew Morton, Natalie Protasevich, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tue, 13 Nov 2007, Mark Lord wrote: > Andrew Morton wrote: > > On Mon, 12 Nov 2007 22:42:32 -0800 "Natalie Protasevich" > > <protasnb@gmail.com> wrote: > .. > > > with CONFIG_NO_HZ and/or CONFIG_HPET_TIMER set kernel 2.6.23 doesn't > > > boot (ARM, Timer) > > > http://bugzilla.kernel.org/show_bug.cgi?id=9229 > > > Kernel: 2.6.23 > > > > No response from developers > .. The bug report is bogus. ARM has no CONFIG_HPET_TIMER. > Note: that same bug exists/existed on i386 back when NO_HZ was > introduced (2.6.21?). I still see it from time to time on my Quad core > system (very rare), but not any more on my Duo notebook where it used > to happen about 1 in n boots (n < 10). > > AFAICT no fix was ever released for it. Hmm, at which point does the boot stop ? > > > Suspend to RAM resume hangs on a tickless (NO_HZ) kernel > > > http://bugzilla.kernel.org/show_bug.cgi?id=9275 > > > Kernel: 2.6.23 > > > This is HP notebook nc6320 T2400 945GM > > No response from developers > .. > > I *still* get very slow resume-from-RAM quite often here > (new in 2.6.22 kernel, wasn't there in early 2.6.23-rc*). Hmm. Which one 22 or 23 ? > Something eventually times out after a minute or so > and it comes back. Cannot make it happen reliably, > unless I'm in a hurry to get something done. :) > I suspect USB here, probably the same loopy bug that > we added a "loop limit failsafe" for back in 2.6.21(?). Do you have a pointer to that please ? Thanks, tglx ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 16:07 ` Thomas Gleixner @ 2007-11-13 17:47 ` Mark Lord 2007-11-15 16:32 ` [BUG] Strange 1-second pauses during Resume-from-RAM Mark Lord 2007-11-13 17:54 ` [BUG] New Kernel Bugs Mark Lord 2007-11-13 18:10 ` Russell King 2 siblings, 1 reply; 268+ messages in thread From: Mark Lord @ 2007-11-13 17:47 UTC (permalink / raw) To: Thomas Gleixner Cc: Andrew Morton, Natalie Protasevich, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon Thomas Gleixner wrote: > On Tue, 13 Nov 2007, Mark Lord wrote: .. >> I *still* get very slow resume-from-RAM quite often here >> (new in 2.6.23 kernel, wasn't there in early 2.6.23-rc*). .. >> Something eventually times out after a minute or so >> and it comes back. Cannot make it happen reliably, >> unless I'm in a hurry to get something done. :) >> I suspect USB here, probably the same loopy bug that >> we added a "loop limit failsafe" for back in 2.6.21(?). > > Do you have a pointer to that please ? .. The "limit" added in the code below, which was for messages of this form: hub 1-1:1.0: hub_port_status failed (err = -71) last message repeated 347 times drivers/usb/hub.c: > static void hub_tt_kevent (struct work_struct *work) > { > struct usb_hub *hub = > container_of(work, struct usb_hub, tt.kevent); > unsigned long flags; > int limit = 100; > > spin_lock_irqsave (&hub->tt.lock, flags); > while (--limit && !list_empty (&hub->tt.clear_list)) { > ... I'm not yet sure what's happening on resume now, but there's this huge long pause with a dark screen and then suddenly the USB subsystem comes to life (my mouse lights up) and the system finally resumes. More when I know more. But it doesn't happen every time, or even most times, so git-bisect is not possible either. This one actually requires a developer/maintainer to put in some effort and think about things. Currently, that's me. -ml ^ permalink raw reply [flat|nested] 268+ messages in thread
* [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-13 17:47 ` Mark Lord @ 2007-11-15 16:32 ` Mark Lord 2007-11-15 16:49 ` Ray Lee ` (2 more replies) 0 siblings, 3 replies; 268+ messages in thread From: Mark Lord @ 2007-11-15 16:32 UTC (permalink / raw) To: Thomas Gleixner, len.brown; +Cc: Andrew Morton, linux-kernel, linux-pm, rjw I have been reporting this off and on since 2.6.23 was released. This problem was not apparent up to perhaps 2.6.23-rc8, but definitely became common in 2.6.23 and 2.6.23.1. Most of the time, a resume-from-RAM on my notebook takes about 2.1 seconds of kernel time to complete. Once in a while, it takes *much* longer, in the 14-20 second range. These long events *seem* to be mostly after the notebook has been in suspend for a longish time, but there's really nothing consistent here. So git-bisect isn't going to work for this one. I recently rebuilt the kernel to include printk timestamps, and then it went 2 days without the issue happening, until this morning (after an overnight suspend) finally. The machine is a Dell Inspiron 9400, Intel chipset + Core2Duo 2.1GHZ w/3GB DDR2. PCIe express chipset, ATI graphics, SATA hard drive. 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03) 00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express PCI Express Root Port (rev 03) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01) 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 01) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 01) 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 01) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility X1400 03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02) 03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd Unknown device 0832 03:01.1 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19) 03:01.2 System peripheral: Ricoh Co Ltd Unknown device 0843 (rev 01) 03:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 0a) 03:01.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 05) 0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) There's also a USB2 hub connected, with the Logitech mouse being the only thing plugged into it at present. The best clue I have of what is happening, other than that it was first seen during the late 2.6.23-rc* series, are the following two sets of kernel logs. The first set is from a "normal" fast wake-up, and the second set is from the "slow" wake-up seen this morning. Both logs show the same information, in pretty much the same order. The BIG difference is a bunch of unexplained pauses of exactly 1-second each that occur during the slow wakeup. The only other difference is that the SATA disk messages are placed differently within the two logs. I'm thinking on that one but it doesn't look significant to me. The real question is, why the 1-sec pauses? * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * HERE IS THE NORMAL RESUME LOG. [ 820.147914] CPU1 is down [ 0.355669] Back to C! [ 0.356120] Enabling non-boot CPUs ... [ 0.377167] SMP alternatives: switching to SMP code [ 0.378565] Booting processor 1/1 eip 3000 [ 0.378568] CPU 1 irqstacks, hard=c0375000 soft=c0373000 [ 0.389374] Initializing CPU#1 [ 0.470225] Calibrating delay using timer specific routine.. 4324.85 BogoMIPS (lpj=7204571) [ 0.470235] CPU: After generic identify, caps: bfebfbff 20100000 00000000 00000000 0000e3bd 00000000 00000001 00000000 [ 0.470244] monitor/mwait feature present. [ 0.470248] CPU: L1 I cache: 32K, L1 D cache: 32K [ 0.470252] CPU: L2 cache: 4096K [ 0.470255] CPU: Physical Processor ID: 0 [ 0.470257] CPU: Processor Core ID: 1 [ 0.470260] CPU: After all inits, caps: bfebfbff 20100000 00000000 00003940 0000e3bd 00000000 00000001 00000000 [ 0.471330] CPU1: Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz stepping 06 [ 0.471724] CPU1 is up [ 0.474787] Switched to high resolution mode on CPU 1 [ 0.483415] PM: Writing back config space on device 0000:00:01.0 at offset a (was f, writing 0) [ 0.483422] PM: Writing back config space on device 0000:00:01.0 at offset 7 (was e0e0, writing 2000e0e0) [ 0.483428] PM: Writing back config space on device 0000:00:01.0 at offset 3 (was 10000, writing 10010) [ 0.483869] PCI: Setting latency timer of device 0000:00:01.0 to 64 [ 0.484224] PM: Writing back config space on device 0000:00:1b.0 at offset f (was 100, writing 10b) [ 0.484244] PM: Writing back config space on device 0000:00:1b.0 at offset 4 (was ffa7c004, writing efffc004) [ 0.484250] PM: Writing back config space on device 0000:00:1b.0 at offset 3 (was 0, writing 10) [ 0.484258] PM: Writing back config space on device 0000:00:1b.0 at offset 1 (was 100000, writing 100102) [ 0.484282] ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 21 (level, low) -> IRQ 20 [ 0.484292] PCI: Setting latency timer of device 0000:00:1b.0 to 64 [ 0.486711] PM: Writing back config space on device 0000:00:1c.0 at offset f (was 100, writing 20100) [ 0.486725] PM: Writing back config space on device 0000:00:1c.0 at offset 9 (was 10001, writing 1fff1) [ 0.486731] PM: Writing back config space on device 0000:00:1c.0 at offset 8 (was 0, writing fff0) [ 0.486738] PM: Writing back config space on device 0000:00:1c.0 at offset 7 (was 0, writing f0) [ 0.486744] PM: Writing back config space on device 0000:00:1c.0 at offset 6 (was 0, writing b0b00) [ 0.486753] PM: Writing back config space on device 0000:00:1c.0 at offset 3 (was 810000, writing 810010) [ 0.486761] PM: Writing back config space on device 0000:00:1c.0 at offset 1 (was 100000, writing 100007) [ 0.486782] PCI: Setting latency timer of device 0000:00:1c.0 to 64 [ 0.486788] pciehp_resume ENTRY [ 0.486829] PM: Writing back config space on device 0000:00:1c.1 at offset f (was 200, writing 20200) [ 0.486841] PM: Writing back config space on device 0000:00:1c.1 at offset 9 (was 10001, writing 1fff1) [ 0.486848] PM: Writing back config space on device 0000:00:1c.1 at offset 8 (was 0, writing efc0efc0) [ 0.486854] PM: Writing back config space on device 0000:00:1c.1 at offset 7 (was 20000000, writing 200000f0) [ 0.486861] PM: Writing back config space on device 0000:00:1c.1 at offset 6 (was 0, writing c0c00) [ 0.486870] PM: Writing back config space on device 0000:00:1c.1 at offset 3 (was 810000, writing 810010) [ 0.486877] PM: Writing back config space on device 0000:00:1c.1 at offset 1 (was 100000, writing 100107) [ 0.486898] PCI: Setting latency timer of device 0000:00:1c.1 to 64 [ 0.486903] pciehp_resume ENTRY [ 0.488916] pciehp: Device 0000:0c:00.0 already exists at c:0, cannot hot-add [ 0.488920] pciehp: Cannot add device 0xc:0 [ 0.488949] PM: Writing back config space on device 0000:00:1c.3 at offset f (was 400, writing 20400) [ 0.488963] PM: Writing back config space on device 0000:00:1c.3 at offset 9 (was 10001, writing e011e001) [ 0.488969] PM: Writing back config space on device 0000:00:1c.3 at offset 8 (was 0, writing efb0efa0) [ 0.488976] PM: Writing back config space on device 0000:00:1c.3 at offset 7 (was 0, writing d0d0) [ 0.488982] PM: Writing back config space on device 0000:00:1c.3 at offset 6 (was 0, writing e0d00) [ 0.488991] PM: Writing back config space on device 0000:00:1c.3 at offset 3 (was 810000, writing 810010) [ 0.488998] PM: Writing back config space on device 0000:00:1c.3 at offset 1 (was 100000, writing 100007) [ 0.489020] PCI: Setting latency timer of device 0000:00:1c.3 to 64 [ 0.489025] pciehp_resume ENTRY [ 0.489063] ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 20 (level, low) -> IRQ 19 [ 0.489070] PCI: Setting latency timer of device 0000:00:1d.0 to 64 [ 0.489121] usb usb1: root hub lost power or was reset [ 0.489144] PCI: Enabling device 0000:00:1d.1 (0000 -> 0001) [ 0.489149] ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 21 (level, low) -> IRQ 20 [ 0.489157] PCI: Setting latency timer of device 0000:00:1d.1 to 64 [ 0.489164] PM: Writing back config space on device 0000:00:1d.1 at offset f (was 200, writing 20b) [ 0.489178] PM: Writing back config space on device 0000:00:1d.1 at offset 8 (was 1, writing bf61) [ 0.489214] usb usb2: root hub lost power or was reset [ 0.489236] PCI: Enabling device 0000:00:1d.2 (0000 -> 0001) [ 0.489240] ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 22 (level, low) -> IRQ 21 [ 0.489248] PCI: Setting latency timer of device 0000:00:1d.2 to 64 [ 0.489255] PM: Writing back config space on device 0000:00:1d.2 at offset f (was 300, writing 309) [ 0.489269] PM: Writing back config space on device 0000:00:1d.2 at offset 8 (was 1, writing bf41) [ 0.489307] usb usb3: root hub lost power or was reset [ 0.489329] PCI: Enabling device 0000:00:1d.3 (0000 -> 0001) [ 0.489333] ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 23 (level, low) -> IRQ 22 [ 0.489341] PCI: Setting latency timer of device 0000:00:1d.3 to 64 [ 0.489348] PM: Writing back config space on device 0000:00:1d.3 at offset f (was 400, writing 407) [ 0.489363] PM: Writing back config space on device 0000:00:1d.3 at offset 8 (was 1, writing bf21) [ 0.489400] usb usb4: root hub lost power or was reset [ 0.489535] ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 20 (level, low) -> IRQ 19 [ 0.489543] PCI: Setting latency timer of device 0000:00:1d.7 to 64 [ 0.489622] PM: Writing back config space on device 0000:00:1e.0 at offset 9 (was 100f1, writing 1fff1) [ 0.489629] PM: Writing back config space on device 0000:00:1e.0 at offset 8 (was 90, writing ef90ef90) [ 0.489635] PM: Writing back config space on device 0000:00:1e.0 at offset 7 (was 2280e0f0, writing 228000f0) [ 0.489648] PM: Writing back config space on device 0000:00:1e.0 at offset 1 (was 100007, writing 100107) [ 0.489668] PCI: Setting latency timer of device 0000:00:1e.0 to 64 [ 0.489707] PM: Writing back config space on device 0000:00:1f.0 at offset 1 (was 2100007, writing 2100107) [ 0.489872] PM: Writing back config space on device 0000:00:1f.2 at offset f (was 200, writing 205) [ 0.489908] ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 17 (level, low) -> IRQ 17 [ 0.489915] PCI: Setting latency timer of device 0000:00:1f.2 to 64 [ 0.489933] PM: Writing back config space on device 0000:00:1f.3 at offset f (was 200, writing 205) [ 0.489963] PM: Writing back config space on device 0000:00:1f.3 at offset 1 (was 2800001, writing 2800101) [ 0.489981] PM: Writing back config space on device 0000:01:00.0 at offset f (was 1ff, writing 104) [ 0.489996] PM: Writing back config space on device 0000:01:00.0 at offset 3 (was 0, writing 10) [ 0.490053] PM: Writing back config space on device 0000:0c:00.0 at offset f (was 100, writing 105) [ 0.490119] PM: Writing back config space on device 0000:0c:00.0 at offset 4 (was 0, writing efcff000) [ 0.490133] PM: Writing back config space on device 0000:0c:00.0 at offset 3 (was 0, writing 10) [ 0.490152] PM: Writing back config space on device 0000:0c:00.0 at offset 1 (was 100000, writing 100106) [ 0.490217] PM: Writing back config space on device 0000:03:00.0 at offset f (was 100, writing 105) [ 0.490236] PM: Writing back config space on device 0000:03:00.0 at offset 4 (was 0, writing ef9fe000) [ 0.490242] PM: Writing back config space on device 0000:03:00.0 at offset 3 (was 0, writing 4000) [ 0.490250] PM: Writing back config space on device 0000:03:00.0 at offset 1 (was 100000, writing 100106) [ 0.490267] ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 17 [ 0.492382] PM: Writing back config space on device 0000:03:01.0 at offset f (was 4020100, writing 4020103) [ 0.492403] PM: Writing back config space on device 0000:03:01.0 at offset 4 (was 0, writing ef9fd800) [ 0.492410] PM: Writing back config space on device 0000:03:01.0 at offset 3 (was 800000, writing 804000) [ 0.492417] PM: Writing back config space on device 0000:03:01.0 at offset 1 (was 2100000, writing 2100106) [ 0.493339] PM: Writing back config space on device 0000:03:01.1 at offset f (was 200, writing 209) [ 0.493361] PM: Writing back config space on device 0000:03:01.1 at offset 4 (was 0, writing ef9fd400) [ 0.493368] PM: Writing back config space on device 0000:03:01.1 at offset 3 (was 800000, writing 804000) [ 0.493376] PM: Writing back config space on device 0000:03:01.1 at offset 1 (was 2100000, writing 2100106) [ 0.493397] ACPI: PCI Interrupt 0000:03:01.1[B] -> GSI 18 (level, low) -> IRQ 23 [ 0.493428] PM: Writing back config space on device 0000:03:01.2 at offset f (was 200, writing 209) [ 0.493449] PM: Writing back config space on device 0000:03:01.2 at offset 4 (was 0, writing ef9fd500) [ 0.493459] PM: Writing back config space on device 0000:03:01.2 at offset 1 (was 2100000, writing 2100106) [ 0.493480] PM: Writing back config space on device 0000:03:01.3 at offset f (was 200, writing 209) [ 0.493500] PM: Writing back config space on device 0000:03:01.3 at offset 4 (was 0, writing ef9fd600) [ 0.493509] PM: Writing back config space on device 0000:03:01.3 at offset 1 (was 2100000, writing 2100102) [ 0.493530] PM: Writing back config space on device 0000:03:01.4 at offset f (was 200, writing 209) [ 0.493550] PM: Writing back config space on device 0000:03:01.4 at offset 4 (was 0, writing ef9fd700) [ 0.493559] PM: Writing back config space on device 0000:03:01.4 at offset 1 (was 2100000, writing 2100102) [ 0.493599] pciehp_resume ENTRY [ 0.493633] pciehp_resume ENTRY [ 0.503412] ata2.00: configured for UDMA/33 [ 0.505628] pciehp: Device 0000:0c:00.0 already exists at c:0, cannot hot-add [ 0.505633] pciehp: Cannot add device 0xc:0 [ 0.505654] pciehp_resume ENTRY [ 0.505972] sd 0:0:0:0: [sda] Starting disk [ 0.601233] ata1.00: configured for UDMA/133 [ 0.624888] sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB) [ 0.624910] sd 0:0:0:0: [sda] Write Protect is off [ 0.624914] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 0.624943] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 0.801255] b44: eth0: Link is up at 100 Mbps, full duplex. [ 0.801260] b44: eth0: Flow control is off for TX and off for RX. [ 0.834760] Restarting tasks ... <6>usb 5-1: USB disconnect, address 17 [ 0.972042] done. [ 0.998126] usb 5-1: new high speed USB device using ehci_hcd and address 21 [ 1.121762] usb 5-1: configuration #1 chosen from 1 choice [ 1.121912] hub 5-1:1.0: USB hub found [ 1.121994] hub 5-1:1.0: 4 ports detected [ 1.224647] usb 5-7: USB disconnect, address 18 [ 1.224651] usb 5-7.1: USB disconnect, address 20 [ 1.334249] usb 5-7: new high speed USB device using ehci_hcd and address 22 [ 1.479331] usb 5-7: configuration #1 chosen from 1 choice [ 1.479760] hub 5-7:1.0: USB hub found [ 1.480770] hub 5-7:1.0: 4 ports detected [ 1.782796] usb 5-1.4: new full speed USB device using ehci_hcd and address 23 [ 1.884536] usb 5-1.4: configuration #1 chosen from 1 choice [ 2.079252] usb 5-7.1: new low speed USB device using ehci_hcd and address 24 [ 2.166603] usb 5-7.1: configuration #1 chosen from 1 choice [ 2.169524] input: Logitech Optical USB Mouse as /class/input/input11 [ 2.170506] input: USB HID v1.10 Mouse [Logitech Optical USB Mouse] on usb-0000:00:1d.7-7.1 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * HERE IS THE SLOW RESUME LOG. Note the 1-second pauses.. [ 3725.539992] CPU1 is down [ 0.354353] Back to C! [ 0.354793] Enabling non-boot CPUs ... [ 0.389097] SMP alternatives: switching to SMP code [ 0.389884] Booting processor 1/1 eip 3000 [ 0.389886] CPU 1 irqstacks, hard=c0375000 soft=c0373000 [ 0.401516] Initializing CPU#1 [ 0.482207] Calibrating delay using timer specific routine.. 4324.78 BogoMIPS (lpj=7204462) [ 0.482212] CPU: After generic identify, caps: bfebfbff 20100000 00000000 00000000 0000e3bd 00000000 00000001 00000000 [ 0.482217] monitor/mwait feature present. [ 0.482219] CPU: L1 I cache: 32K, L1 D cache: 32K [ 0.482221] CPU: L2 cache: 4096K [ 0.482222] CPU: Physical Processor ID: 0 [ 0.482223] CPU: Processor Core ID: 1 [ 0.482225] CPU: After all inits, caps: bfebfbff 20100000 00000000 00003940 0000e3bd 00000000 00000001 00000000 [ 0.482814] CPU1: Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz stepping 06 [ 0.483053] CPU1 is up [ 0.486165] Switched to high resolution mode on CPU 1 [ 0.490338] PM: Writing back config space on device 0000:00:01.0 at offset a (was f, writing 0) [ 0.490342] PM: Writing back config space on device 0000:00:01.0 at offset 7 (was e0e0, writing 2000e0e0) [ 0.490345] PM: Writing back config space on device 0000:00:01.0 at offset 3 (was 10000, writing 10010) [ 0.490351] PCI: Setting latency timer of device 0000:00:01.0 to 64 [ 0.490605] PM: Writing back config space on device 0000:00:1b.0 at offset f (was 100, writing 10b) [ 0.490626] PM: Writing back config space on device 0000:00:1b.0 at offset 4 (was ffa7c004, writing efffc004) [ 0.490632] PM: Writing back config space on device 0000:00:1b.0 at offset 3 (was 0, writing 10) [ 0.490640] PM: Writing back config space on device 0000:00:1b.0 at offset 1 (was 100000, writing 100102) [ 0.490665] ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 21 (level, low) -> IRQ 20 [ 0.490674] PCI: Setting latency timer of device 0000:00:1b.0 to 64 [ 1.492418] PM: Writing back config space on device 0000:00:1c.0 at offset f (was 100, writing 20100) [ 1.492432] PM: Writing back config space on device 0000:00:1c.0 at offset 9 (was 10001, writing 1fff1) [ 1.492438] PM: Writing back config space on device 0000:00:1c.0 at offset 8 (was 0, writing fff0) [ 1.492445] PM: Writing back config space on device 0000:00:1c.0 at offset 7 (was 0, writing f0) [ 1.492451] PM: Writing back config space on device 0000:00:1c.0 at offset 6 (was 0, writing b0b00) [ 1.492460] PM: Writing back config space on device 0000:00:1c.0 at offset 3 (was 810000, writing 810010) [ 1.492468] PM: Writing back config space on device 0000:00:1c.0 at offset 1 (was 100000, writing 100007) [ 1.492490] PCI: Setting latency timer of device 0000:00:1c.0 to 64 [ 1.492496] pciehp_resume ENTRY [ 1.492539] PM: Writing back config space on device 0000:00:1c.1 at offset f (was 200, writing 20200) [ 1.492552] PM: Writing back config space on device 0000:00:1c.1 at offset 9 (was 10001, writing 1fff1) [ 1.492559] PM: Writing back config space on device 0000:00:1c.1 at offset 8 (was 0, writing efc0efc0) [ 1.492565] PM: Writing back config space on device 0000:00:1c.1 at offset 7 (was 20000000, writing f0) [ 1.492572] PM: Writing back config space on device 0000:00:1c.1 at offset 6 (was 0, writing c0c00) [ 1.492581] PM: Writing back config space on device 0000:00:1c.1 at offset 3 (was 810000, writing 810010) [ 1.492588] PM: Writing back config space on device 0000:00:1c.1 at offset 1 (was 100000, writing 100107) [ 1.492610] PCI: Setting latency timer of device 0000:00:1c.1 to 64 [ 1.492615] pciehp_resume ENTRY [ 1.493885] pciehp: Device 0000:0c:00.0 already exists at c:0, cannot hot-add [ 1.493889] pciehp: Cannot add device 0xc:0 [ 1.493916] PM: Writing back config space on device 0000:00:1c.3 at offset f (was 400, writing 20400) [ 1.493929] PM: Writing back config space on device 0000:00:1c.3 at offset 9 (was 10001, writing e011e001) [ 1.493936] PM: Writing back config space on device 0000:00:1c.3 at offset 8 (was 0, writing efb0efa0) [ 1.493942] PM: Writing back config space on device 0000:00:1c.3 at offset 7 (was 0, writing d0d0) [ 1.493949] PM: Writing back config space on device 0000:00:1c.3 at offset 6 (was 0, writing e0d00) [ 1.493958] PM: Writing back config space on device 0000:00:1c.3 at offset 3 (was 810000, writing 810010) [ 1.493966] PM: Writing back config space on device 0000:00:1c.3 at offset 1 (was 100000, writing 100007) [ 1.493987] PCI: Setting latency timer of device 0000:00:1c.3 to 64 [ 1.493992] pciehp_resume ENTRY [ 1.494028] ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 20 (level, low) -> IRQ 19 [ 1.494036] PCI: Setting latency timer of device 0000:00:1d.0 to 64 [ 1.494088] usb usb1: root hub lost power or was reset [ 1.494110] PCI: Enabling device 0000:00:1d.1 (0000 -> 0001) [ 1.494114] ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 21 (level, low) -> IRQ 20 [ 1.494122] PCI: Setting latency timer of device 0000:00:1d.1 to 64 [ 1.494130] PM: Writing back config space on device 0000:00:1d.1 at offset f (was 200, writing 20b) [ 1.494144] PM: Writing back config space on device 0000:00:1d.1 at offset 8 (was 1, writing bf61) [ 1.494180] usb usb2: root hub lost power or was reset [ 1.494202] PCI: Enabling device 0000:00:1d.2 (0000 -> 0001) [ 1.494206] ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 22 (level, low) -> IRQ 21 [ 1.494214] PCI: Setting latency timer of device 0000:00:1d.2 to 64 [ 1.494222] PM: Writing back config space on device 0000:00:1d.2 at offset f (was 300, writing 309) [ 1.494236] PM: Writing back config space on device 0000:00:1d.2 at offset 8 (was 1, writing bf41) [ 1.494273] usb usb3: root hub lost power or was reset [ 1.494295] PCI: Enabling device 0000:00:1d.3 (0000 -> 0001) [ 1.494299] ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 23 (level, low) -> IRQ 22 [ 1.494307] PCI: Setting latency timer of device 0000:00:1d.3 to 64 [ 1.494314] PM: Writing back config space on device 0000:00:1d.3 at offset f (was 400, writing 407) [ 1.494328] PM: Writing back config space on device 0000:00:1d.3 at offset 8 (was 1, writing bf21) [ 1.494365] usb usb4: root hub lost power or was reset [ 1.496460] ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 20 (level, low) -> IRQ 19 [ 1.496468] PCI: Setting latency timer of device 0000:00:1d.7 to 64 [ 1.496534] PM: Writing back config space on device 0000:00:1e.0 at offset 9 (was 100f1, writing 1fff1) [ 1.496542] PM: Writing back config space on device 0000:00:1e.0 at offset 8 (was 90, writing ef90ef90) [ 1.496551] PM: Writing back config space on device 0000:00:1e.0 at offset 7 (was 2280e0f0, writing 228000f0) [ 1.496570] PM: Writing back config space on device 0000:00:1e.0 at offset 1 (was 100007, writing 100107) [ 1.496590] PCI: Setting latency timer of device 0000:00:1e.0 to 64 [ 1.496629] PM: Writing back config space on device 0000:00:1f.0 at offset 1 (was 2100007, writing 2100107) [ 1.745307] PM: Writing back config space on device 0000:00:1f.2 at offset f (was 200, writing 205) [ 1.745344] ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 17 (level, low) -> IRQ 17 [ 1.745351] PCI: Setting latency timer of device 0000:00:1f.2 to 64 [ 1.745369] PM: Writing back config space on device 0000:00:1f.3 at offset f (was 200, writing 205) [ 1.745406] PM: Writing back config space on device 0000:00:1f.3 at offset 1 (was 2800001, writing 2800101) [ 1.745430] PM: Writing back config space on device 0000:01:00.0 at offset f (was 1ff, writing 104) [ 1.745453] PM: Writing back config space on device 0000:01:00.0 at offset 3 (was 0, writing 10) [ 1.745514] PM: Writing back config space on device 0000:0c:00.0 at offset f (was 100, writing 105) [ 1.745584] PM: Writing back config space on device 0000:0c:00.0 at offset 4 (was 0, writing efcff000) [ 1.745600] PM: Writing back config space on device 0000:0c:00.0 at offset 3 (was 0, writing 10) [ 1.745623] PM: Writing back config space on device 0000:0c:00.0 at offset 1 (was 100000, writing 100106) [ 1.745709] PM: Writing back config space on device 0000:03:00.0 at offset f (was 100, writing 105) [ 1.745729] PM: Writing back config space on device 0000:03:00.0 at offset 4 (was 0, writing ef9fe000) [ 1.745735] PM: Writing back config space on device 0000:03:00.0 at offset 3 (was 0, writing 4000) [ 1.745743] PM: Writing back config space on device 0000:03:00.0 at offset 1 (was 100000, writing 100106) [ 1.745765] ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 17 [ 2.753018] PM: Writing back config space on device 0000:03:01.0 at offset f (was 4020100, writing 4020103) [ 2.753038] PM: Writing back config space on device 0000:03:01.0 at offset 4 (was 0, writing ef9fd800) [ 2.753045] PM: Writing back config space on device 0000:03:01.0 at offset 3 (was 800000, writing 804000) [ 2.753053] PM: Writing back config space on device 0000:03:01.0 at offset 1 (was 2100000, writing 2100106) [ 3.756771] ata1.00: configured for UDMA/133 [ 3.756818] sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB) [ 3.756836] sd 0:0:0:0: [sda] Write Protect is off [ 3.756840] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 3.756868] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 4.763813] b44: eth0: Link is up at 100 Mbps, full duplex. [ 4.763817] b44: eth0: Flow control is off for TX and off for RX. [ 4.764090] PM: Writing back config space on device 0000:03:01.1 at offset f (was 200, writing 209) [ 4.764111] PM: Writing back config space on device 0000:03:01.1 at offset 4 (was 0, writing ef9fd400) [ 4.764118] PM: Writing back config space on device 0000:03:01.1 at offset 3 (was 800000, writing 804000) [ 4.764126] PM: Writing back config space on device 0000:03:01.1 at offset 1 (was 2100000, writing 2100106) [ 4.764145] ACPI: PCI Interrupt 0000:03:01.1[B] -> GSI 18 (level, low) -> IRQ 23 [ 4.764171] PM: Writing back config space on device 0000:03:01.2 at offset f (was 200, writing 209) [ 4.764191] PM: Writing back config space on device 0000:03:01.2 at offset 4 (was 0, writing ef9fd500) [ 4.764201] PM: Writing back config space on device 0000:03:01.2 at offset 1 (was 2100000, writing 2100106) [ 4.764222] PM: Writing back config space on device 0000:03:01.3 at offset f (was 200, writing 209) [ 4.764242] PM: Writing back config space on device 0000:03:01.3 at offset 4 (was 0, writing ef9fd600) [ 4.764251] PM: Writing back config space on device 0000:03:01.3 at offset 1 (was 2100000, writing 2100102) [ 4.764273] PM: Writing back config space on device 0000:03:01.4 at offset f (was 200, writing 209) [ 4.764293] PM: Writing back config space on device 0000:03:01.4 at offset 4 (was 0, writing ef9fd700) [ 4.764303] PM: Writing back config space on device 0000:03:01.4 at offset 1 (was 2100000, writing 2100102) [ 4.764340] pciehp_resume ENTRY [ 4.764369] pciehp_resume ENTRY [ 5.765432] ata2.00: configured for UDMA/33 [ 5.767529] pciehp: Device 0000:0c:00.0 already exists at c:0, cannot hot-add [ 5.767532] pciehp: Cannot add device 0xc:0 [ 5.767547] pciehp_resume ENTRY [ 5.767864] sd 0:0:0:0: [sda] Starting disk [ 7.750047] Restarting tasks ... done. [ 7.830571] usb 5-1: USB disconnect, address 21 [ 8.126832] usb 5-1: new high speed USB device using ehci_hcd and address 25 [ 10.230397] usb 5-1: configuration #1 chosen from 1 choice [ 10.230517] hub 5-1:1.0: USB hub found [ 10.230545] hub 5-1:1.0: 4 ports detected [ 10.281481] usb 5-7: USB disconnect, address 22 [ 10.281489] usb 5-7.1: USB disconnect, address 24 [ 10.889785] usb 5-7: new high speed USB device using ehci_hcd and address 26 [ 11.658319] usb 5-7: configuration #1 chosen from 1 choice [ 11.658631] hub 5-7:1.0: USB hub found [ 11.658985] hub 5-7:1.0: 4 ports detected [ 13.190055] usb 5-1.4: new full speed USB device using ehci_hcd and address 27 [ 13.961678] usb 5-1.4: configuration #1 chosen from 1 choice [ 14.171766] usb 5-7.1: new low speed USB device using ehci_hcd and address 28 [ 14.295838] usb 5-7.1: configuration #1 chosen from 1 choice [ 14.298596] input: Logitech Optical USB Mouse as /class/input/input12 [ 14.299091] input: USB HID v1.10 Mouse [Logitech Optical USB Mouse] on usb-0000:00:1d.7-7.1 ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-15 16:32 ` [BUG] Strange 1-second pauses during Resume-from-RAM Mark Lord @ 2007-11-15 16:49 ` Ray Lee 2007-11-15 16:51 ` Mark Lord 2007-11-15 18:14 ` Pavel Machek 2007-11-18 16:10 ` Mark Lord 2 siblings, 1 reply; 268+ messages in thread From: Ray Lee @ 2007-11-15 16:49 UTC (permalink / raw) To: Mark Lord Cc: Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw On Nov 15, 2007 8:32 AM, Mark Lord <liml@rtr.ca> wrote: > I have been reporting this off and on since 2.6.23 was released. > This problem was not apparent up to perhaps 2.6.23-rc8, > but definitely became common in 2.6.23 and 2.6.23.1. > > Most of the time, a resume-from-RAM on my notebook takes about 2.1 seconds > of kernel time to complete. > > Once in a while, it takes *much* longer, in the 14-20 second range. > These long events *seem* to be mostly after the notebook has been > in suspend for a longish time, but there's really nothing consistent here. > > So git-bisect isn't going to work for this one. I recently rebuilt the kernel > to include printk timestamps, and then it went 2 days without the issue happening, > until this morning (after an overnight suspend) finally. > > The machine is a Dell Inspiron 9400, Intel chipset + Core2Duo 2.1GHZ w/3GB DDR2. > PCIe express chipset, ATI graphics, SATA hard drive. > > 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03) > 00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express PCI Express Root Port (rev 03) > 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) > 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) > 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01) > 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 01) > 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 01) > 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 01) > 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 01) > 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 01) > 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) > 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1) > 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 01) > 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 01) > 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) > 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility X1400 > 03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02) > 03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd Unknown device 0832 > 03:01.1 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19) > 03:01.2 System peripheral: Ricoh Co Ltd Unknown device 0843 (rev 01) > 03:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 0a) > 03:01.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 05) > 0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) > > There's also a USB2 hub connected, with the Logitech mouse being the > only thing plugged into it at present. > > The best clue I have of what is happening, other than that it was first > seen during the late 2.6.23-rc* series, are the following two sets of > kernel logs. The first set is from a "normal" fast wake-up, > and the second set is from the "slow" wake-up seen this morning. > > Both logs show the same information, in pretty much the same order. > The BIG difference is a bunch of unexplained pauses of exactly 1-second > each that occur during the slow wakeup. > > The only other difference is that the SATA disk messages are placed > differently within the two logs. I'm thinking on that one but it > doesn't look significant to me. > > The real question is, why the 1-sec pauses? Well, and why the 1-second pauses eventually stop, too. Seems interesting that they don't continue. Also, they're pretty much dead-on one- and two-second pauses, with HZ accuracy. Is this with a NO_HZ kernel? ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-15 16:49 ` Ray Lee @ 2007-11-15 16:51 ` Mark Lord 2007-11-15 16:53 ` Mark Lord 0 siblings, 1 reply; 268+ messages in thread From: Mark Lord @ 2007-11-15 16:51 UTC (permalink / raw) To: Ray Lee Cc: Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw Ray Lee wrote: > On Nov 15, 2007 8:32 AM, Mark Lord <liml@rtr.ca> wrote: >> I have been reporting this off and on since 2.6.23 was released. >> This problem was not apparent up to perhaps 2.6.23-rc8, >> but definitely became common in 2.6.23 and 2.6.23.1. >> >> Most of the time, a resume-from-RAM on my notebook takes about 2.1 seconds >> of kernel time to complete. >> >> Once in a while, it takes *much* longer, in the 14-20 second range. >> These long events *seem* to be mostly after the notebook has been >> in suspend for a longish time, but there's really nothing consistent here. >> >> So git-bisect isn't going to work for this one. I recently rebuilt the kernel >> to include printk timestamps, and then it went 2 days without the issue happening, >> until this morning (after an overnight suspend) finally. >> >> The machine is a Dell Inspiron 9400, Intel chipset + Core2Duo 2.1GHZ w/3GB DDR2. >> PCIe express chipset, ATI graphics, SATA hard drive. >> >> 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03) >> 00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express PCI Express Root Port (rev 03) >> 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) >> 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) >> 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01) >> 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 01) >> 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 01) >> 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 01) >> 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 01) >> 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 01) >> 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) >> 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1) >> 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 01) >> 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 01) >> 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) >> 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility X1400 >> 03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02) >> 03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd Unknown device 0832 >> 03:01.1 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19) >> 03:01.2 System peripheral: Ricoh Co Ltd Unknown device 0843 (rev 01) >> 03:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 0a) >> 03:01.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 05) >> 0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) >> >> There's also a USB2 hub connected, with the Logitech mouse being the >> only thing plugged into it at present. >> >> The best clue I have of what is happening, other than that it was first >> seen during the late 2.6.23-rc* series, are the following two sets of >> kernel logs. The first set is from a "normal" fast wake-up, >> and the second set is from the "slow" wake-up seen this morning. >> >> Both logs show the same information, in pretty much the same order. >> The BIG difference is a bunch of unexplained pauses of exactly 1-second >> each that occur during the slow wakeup. >> >> The only other difference is that the SATA disk messages are placed >> differently within the two logs. I'm thinking on that one but it >> doesn't look significant to me. >> >> The real question is, why the 1-sec pauses? > > Well, and why the 1-second pauses eventually stop, too. Seems > interesting that they don't continue. Also, they're pretty much > dead-on one- and two-second pauses, with HZ accuracy. Is this with a > NO_HZ kernel? .. Yes, A NO_HZ kernel. Full config follows: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc2-git4 # Wed Nov 14 14:19:45 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 # CONFIG_CGROUPS is not set # CONFIG_FAIR_GROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y # CONFIG_SLUB_DEBUG is not set # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set CONFIG_BLK_DEV_BSG=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT_GUEST is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MCORE2=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 CONFIG_HPET_TIMER=y CONFIG_NR_CPUS=2 # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y # CONFIG_X86_MCE is not set CONFIG_VM86=y # CONFIG_TOSHIBA is not set CONFIG_I8K=m CONFIG_X86_REBOOTFIXUPS=y CONFIG_MICROCODE=m CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # CONFIG_EDD=m CONFIG_DELL_RBU=m CONFIG_DCDBAS=m CONFIG_DMIID=y # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_VMSPLIT_3G=y # CONFIG_VMSPLIT_3G_OPT is not set # CONFIG_VMSPLIT_2G is not set # CONFIG_VMSPLIT_2G_OPT is not set # CONFIG_VMSPLIT_1G is not set CONFIG_PAGE_OFFSET=0xC0000000 CONFIG_HIGHMEM=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_SPARSEMEM_STATIC=y # CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_RESOURCES_64BIT is not set CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_NR_QUICK=1 CONFIG_VIRT_TO_BUS=y # CONFIG_HIGHPTE is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set # CONFIG_IRQBALANCE is not set # CONFIG_SECCOMP is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_300=y # CONFIG_HZ_1000 is not set CONFIG_HZ=300 # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x100000 # CONFIG_RELOCATABLE is not set CONFIG_PHYSICAL_ALIGN=0x100000 CONFIG_HOTPLUG_CPU=y # CONFIG_COMPAT_VDSO is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y # # Power management options (ACPI, APM) # CONFIG_PM=y CONFIG_PM_LEGACY=y # CONFIG_PM_DEBUG is not set CONFIG_PM_SLEEP_SMP=y CONFIG_PM_SLEEP=y CONFIG_SUSPEND_SMP_POSSIBLE=y CONFIG_SUSPEND=y CONFIG_HIBERNATION_SMP_POSSIBLE=y CONFIG_HIBERNATION=y CONFIG_PM_STD_PARTITION="/dev/sda3" CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_PROCFS=y CONFIG_ACPI_PROC_EVENT=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_FAN=m # CONFIG_ACPI_DOCK is not set CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_ACPI_THERMAL=m # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y CONFIG_ACPI_CONTAINER=m # CONFIG_ACPI_SBS is not set # CONFIG_APM is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y # CONFIG_CPU_FREQ_DEBUG is not set CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m # # CPUFreq processor drivers # CONFIG_X86_ACPI_CPUFREQ=m # CONFIG_X86_POWERNOW_K6 is not set # CONFIG_X86_POWERNOW_K7 is not set # CONFIG_X86_POWERNOW_K8 is not set # CONFIG_X86_GX_SUSPMOD is not set CONFIG_X86_SPEEDSTEP_CENTRINO=m CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y CONFIG_X86_SPEEDSTEP_ICH=m # CONFIG_X86_SPEEDSTEP_SMI is not set # CONFIG_X86_P4_CLOCKMOD is not set # CONFIG_X86_CPUFREQ_NFORCE2 is not set # CONFIG_X86_LONGRUN is not set # CONFIG_X86_LONGHAUL is not set # CONFIG_X86_E_POWERSAVER is not set # # shared options # # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set CONFIG_X86_SPEEDSTEP_LIB=m # CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK is not set CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_DOMAINS=y CONFIG_PCIEPORTBUS=y CONFIG_HOTPLUG_PCI_PCIE=m CONFIG_PCIEAER=y CONFIG_ARCH_SUPPORTS_MSI=y # CONFIG_PCI_MSI is not set CONFIG_PCI_LEGACY=y # CONFIG_PCI_DEBUG is not set # CONFIG_HT_IRQ is not set CONFIG_ISA_DMA_API=y # CONFIG_ISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # CONFIG_PCCARD is not set CONFIG_HOTPLUG_PCI=m # CONFIG_HOTPLUG_PCI_FAKE is not set # CONFIG_HOTPLUG_PCI_COMPAQ is not set # CONFIG_HOTPLUG_PCI_IBM is not set # CONFIG_HOTPLUG_PCI_ACPI is not set # CONFIG_HOTPLUG_PCI_CPCI is not set # CONFIG_HOTPLUG_PCI_SHPC is not set # # Executable file formats # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_MISC=m # # Networking # CONFIG_NET=y # # Networking options # CONFIG_PACKET=m CONFIG_PACKET_MMAP=y CONFIG_UNIX=m CONFIG_XFRM=y CONFIG_XFRM_USER=m # CONFIG_XFRM_SUB_POLICY is not set # CONFIG_XFRM_MIGRATE is not set CONFIG_NET_KEY=m # CONFIG_NET_KEY_MIGRATE is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_ASK_IP_FIB_HASH=y # CONFIG_IP_FIB_TRIE is not set CONFIG_IP_FIB_HASH=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m CONFIG_INET_XFRM_TUNNEL=m CONFIG_INET_TUNNEL=m CONFIG_INET_XFRM_MODE_TRANSPORT=m CONFIG_INET_XFRM_MODE_TUNNEL=m CONFIG_INET_XFRM_MODE_BEET=m CONFIG_INET_LRO=y CONFIG_INET_DIAG=m CONFIG_INET_TCP_DIAG=m # CONFIG_TCP_CONG_ADVANCED is not set CONFIG_TCP_CONG_CUBIC=y CONFIG_DEFAULT_TCP_CONG="cubic" # CONFIG_TCP_MD5SIG is not set # CONFIG_IPV6 is not set # CONFIG_INET6_XFRM_TUNNEL is not set # CONFIG_INET6_TUNNEL is not set # CONFIG_NETWORK_SECMARK is not set # CONFIG_NETFILTER is not set # CONFIG_IP_DCCP is not set CONFIG_IP_SCTP=m # CONFIG_SCTP_DBG_MSG is not set # CONFIG_SCTP_DBG_OBJCNT is not set # CONFIG_SCTP_HMAC_NONE is not set # CONFIG_SCTP_HMAC_SHA1 is not set CONFIG_SCTP_HMAC_MD5=y # CONFIG_TIPC is not set # CONFIG_ATM is not set CONFIG_BRIDGE=m CONFIG_VLAN_8021Q=m # CONFIG_DECNET is not set CONFIG_LLC=m # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set CONFIG_NET_SCHED=y # # Queueing/Scheduling # CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RR=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_INGRESS=m # # Classification # CONFIG_NET_CLS=y CONFIG_NET_CLS_BASIC=m CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_CLS_U32_PERF=y CONFIG_CLS_U32_MARK=y CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_EMATCH=y CONFIG_NET_EMATCH_STACK=32 CONFIG_NET_EMATCH_CMP=m CONFIG_NET_EMATCH_NBYTE=m CONFIG_NET_EMATCH_U32=m CONFIG_NET_EMATCH_META=m CONFIG_NET_EMATCH_TEXT=m CONFIG_NET_CLS_ACT=y CONFIG_NET_ACT_POLICE=m CONFIG_NET_ACT_GACT=m CONFIG_GACT_PROB=y CONFIG_NET_ACT_MIRRED=m # CONFIG_NET_ACT_NAT is not set CONFIG_NET_ACT_PEDIT=m CONFIG_NET_ACT_SIMP=m # CONFIG_NET_CLS_POLICE is not set # CONFIG_NET_CLS_IND is not set CONFIG_NET_SCH_FIFO=y # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set CONFIG_BT=m CONFIG_BT_L2CAP=m CONFIG_BT_SCO=m CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=m CONFIG_BT_BNEP_MC_FILTER=y CONFIG_BT_BNEP_PROTO_FILTER=y CONFIG_BT_HIDP=m # # Bluetooth device drivers # CONFIG_BT_HCIUSB=m CONFIG_BT_HCIUSB_SCO=y # CONFIG_BT_HCIBTSDIO is not set CONFIG_BT_HCIUART=m CONFIG_BT_HCIUART_H4=y CONFIG_BT_HCIUART_BCSP=y CONFIG_BT_HCIUART_LL=y CONFIG_BT_HCIBCM203X=m CONFIG_BT_HCIBPA10X=m CONFIG_BT_HCIBFUSB=m CONFIG_BT_HCIVHCI=m # CONFIG_AF_RXRPC is not set CONFIG_FIB_RULES=y # # Wireless # CONFIG_CFG80211=m CONFIG_NL80211=y CONFIG_WIRELESS_EXT=y CONFIG_MAC80211=m CONFIG_MAC80211_RCSIMPLE=y # CONFIG_MAC80211_DEBUG is not set CONFIG_IEEE80211=m # CONFIG_IEEE80211_DEBUG is not set CONFIG_IEEE80211_CRYPT_WEP=m CONFIG_IEEE80211_CRYPT_CCMP=m CONFIG_IEEE80211_CRYPT_TKIP=m CONFIG_IEEE80211_SOFTMAC=m # CONFIG_IEEE80211_SOFTMAC_DEBUG is not set CONFIG_RFKILL=m CONFIG_RFKILL_INPUT=m # CONFIG_NET_9P is not set # # Device Drivers # # # Generic Driver Options # CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_STANDALONE=y # CONFIG_PREVENT_FIRMWARE_BUILD is not set CONFIG_FW_LOADER=m # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set # CONFIG_CONNECTOR is not set # CONFIG_MTD is not set # CONFIG_PARPORT is not set CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # CONFIG_PNPACPI=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_FD=m # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=4 CONFIG_BLK_DEV_RAM_SIZE=8192 CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024 CONFIG_CDROM_PKTCDVD=m CONFIG_CDROM_PKTCDVD_BUFFERS=8 # CONFIG_CDROM_PKTCDVD_WCACHE is not set CONFIG_ATA_OVER_ETH=m CONFIG_MISC_DEVICES=y # CONFIG_IBM_ASM is not set # CONFIG_PHANTOM is not set CONFIG_EEPROM_93CX6=m # CONFIG_SGI_IOC4 is not set CONFIG_TIFM_CORE=m # CONFIG_TIFM_7XX1 is not set # CONFIG_FUJITSU_LAPTOP is not set # CONFIG_MSI_LAPTOP is not set # CONFIG_SONY_LAPTOP is not set # CONFIG_THINKPAD_ACPI is not set # CONFIG_IDE is not set # # SCSI device support # # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y CONFIG_SCSI_DMA=y # CONFIG_SCSI_TGT is not set # CONFIG_SCSI_NETLINK is not set CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_CHR_DEV_SG=m # CONFIG_CHR_DEV_SCH is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y CONFIG_SCSI_SCAN_ASYNC=y CONFIG_SCSI_WAIT_SCAN=m # # SCSI Transports # # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_ISCSI_ATTRS is not set # CONFIG_SCSI_SAS_ATTRS is not set # CONFIG_SCSI_SAS_LIBSAS is not set # CONFIG_SCSI_SRP_ATTRS is not set # CONFIG_SCSI_LOWLEVEL is not set CONFIG_ATA=y # CONFIG_ATA_NONSTANDARD is not set CONFIG_ATA_ACPI=y # CONFIG_SATA_AHCI is not set # CONFIG_SATA_SVW is not set CONFIG_ATA_PIIX=y # CONFIG_SATA_MV is not set # CONFIG_SATA_NV is not set # CONFIG_PDC_ADMA is not set CONFIG_SATA_QSTOR=m # CONFIG_SATA_PROMISE is not set # CONFIG_SATA_SX4 is not set # CONFIG_SATA_SIL is not set CONFIG_SATA_SIL24=m # CONFIG_SATA_SIS is not set # CONFIG_SATA_ULI is not set # CONFIG_SATA_VIA is not set # CONFIG_SATA_VITESSE is not set # CONFIG_SATA_INIC162X is not set # CONFIG_PATA_ACPI is not set # CONFIG_PATA_ALI is not set # CONFIG_PATA_AMD is not set # CONFIG_PATA_ARTOP is not set # CONFIG_PATA_ATIIXP is not set # CONFIG_PATA_CMD640_PCI is not set # CONFIG_PATA_CMD64X is not set # CONFIG_PATA_CS5520 is not set # CONFIG_PATA_CS5530 is not set # CONFIG_PATA_CS5535 is not set # CONFIG_PATA_CS5536 is not set # CONFIG_PATA_CYPRESS is not set # CONFIG_PATA_EFAR is not set # CONFIG_ATA_GENERIC is not set # CONFIG_PATA_HPT366 is not set # CONFIG_PATA_HPT37X is not set # CONFIG_PATA_HPT3X2N is not set # CONFIG_PATA_HPT3X3 is not set # CONFIG_PATA_IT821X is not set # CONFIG_PATA_IT8213 is not set # CONFIG_PATA_JMICRON is not set # CONFIG_PATA_TRIFLEX is not set # CONFIG_PATA_MARVELL is not set # CONFIG_PATA_MPIIX is not set # CONFIG_PATA_OLDPIIX is not set # CONFIG_PATA_NETCELL is not set # CONFIG_PATA_NS87410 is not set # CONFIG_PATA_NS87415 is not set # CONFIG_PATA_OPTI is not set # CONFIG_PATA_OPTIDMA is not set # CONFIG_PATA_PDC_OLD is not set # CONFIG_PATA_RADISYS is not set # CONFIG_PATA_RZ1000 is not set # CONFIG_PATA_SC1200 is not set # CONFIG_PATA_SERVERWORKS is not set # CONFIG_PATA_PDC2027X is not set # CONFIG_PATA_SIL680 is not set # CONFIG_PATA_SIS is not set # CONFIG_PATA_VIA is not set # CONFIG_PATA_WINBOND is not set # CONFIG_PATA_PLATFORM is not set CONFIG_MD=y CONFIG_BLK_DEV_MD=m # CONFIG_MD_LINEAR is not set CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m # CONFIG_MD_RAID10 is not set # CONFIG_MD_RAID456 is not set # CONFIG_MD_MULTIPATH is not set # CONFIG_MD_FAULTY is not set CONFIG_BLK_DEV_DM=m # CONFIG_DM_DEBUG is not set CONFIG_DM_CRYPT=m CONFIG_DM_SNAPSHOT=m CONFIG_DM_MIRROR=m # CONFIG_DM_ZERO is not set # CONFIG_DM_MULTIPATH is not set # CONFIG_DM_DELAY is not set CONFIG_DM_UEVENT=y # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # CONFIG_FIREWIRE=m CONFIG_FIREWIRE_OHCI=m CONFIG_FIREWIRE_SBP2=m # CONFIG_IEEE1394 is not set # CONFIG_I2O is not set # CONFIG_MACINTOSH_DRIVERS is not set CONFIG_NETDEVICES=y # CONFIG_NETDEVICES_MULTIQUEUE is not set # CONFIG_IFB is not set CONFIG_DUMMY=m CONFIG_BONDING=m CONFIG_MACVLAN=m CONFIG_EQUALIZER=m CONFIG_TUN=m # CONFIG_VETH is not set # CONFIG_NET_SB1000 is not set # CONFIG_IP1000 is not set # CONFIG_ARCNET is not set CONFIG_PHYLIB=m # # MII PHY device drivers # # CONFIG_MARVELL_PHY is not set # CONFIG_DAVICOM_PHY is not set # CONFIG_QSEMI_PHY is not set # CONFIG_LXT_PHY is not set # CONFIG_CICADA_PHY is not set # CONFIG_VITESSE_PHY is not set # CONFIG_SMSC_PHY is not set # CONFIG_BROADCOM_PHY is not set # CONFIG_ICPLUS_PHY is not set CONFIG_FIXED_PHY=m CONFIG_FIXED_MII_10_FDX=y CONFIG_FIXED_MII_100_FDX=y CONFIG_FIXED_MII_1000_FDX=y CONFIG_FIXED_MII_AMNT=1 # CONFIG_MDIO_BITBANG is not set CONFIG_NET_ETHERNET=y CONFIG_MII=m # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_CASSINI is not set # CONFIG_NET_VENDOR_3COM is not set # CONFIG_NET_TULIP is not set # CONFIG_HP100 is not set # CONFIG_IBM_NEW_EMAC_ZMII is not set # CONFIG_IBM_NEW_EMAC_RGMII is not set # CONFIG_IBM_NEW_EMAC_TAH is not set # CONFIG_IBM_NEW_EMAC_EMAC4 is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set CONFIG_B44=m CONFIG_B44_PCI_AUTOSELECT=y CONFIG_B44_PCICORE_AUTOSELECT=y CONFIG_B44_PCI=y # CONFIG_FORCEDETH is not set # CONFIG_EEPRO100 is not set # CONFIG_E100 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_8139CP is not set # CONFIG_8139TOO is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_SC92031 is not set CONFIG_NETDEV_1000=y # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_E1000E is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set CONFIG_R8169=m # CONFIG_R8169_NAPI is not set # CONFIG_R8169_VLAN is not set # CONFIG_SIS190 is not set # CONFIG_SKGE is not set # CONFIG_SKY2 is not set # CONFIG_SK98LIN is not set # CONFIG_VIA_VELOCITY is not set # CONFIG_TIGON3 is not set # CONFIG_BNX2 is not set # CONFIG_QLA3XXX is not set # CONFIG_ATL1 is not set # CONFIG_NETDEV_10000 is not set # CONFIG_TR is not set # # Wireless LAN # # CONFIG_WLAN_PRE80211 is not set CONFIG_WLAN_80211=y CONFIG_IPW2100=m CONFIG_IPW2100_MONITOR=y # CONFIG_IPW2100_DEBUG is not set CONFIG_IPW2200=m CONFIG_IPW2200_MONITOR=y CONFIG_IPW2200_RADIOTAP=y CONFIG_IPW2200_PROMISCUOUS=y CONFIG_IPW2200_QOS=y # CONFIG_IPW2200_DEBUG is not set # CONFIG_LIBERTAS is not set # CONFIG_AIRO is not set # CONFIG_HERMES is not set # CONFIG_ATMEL is not set # CONFIG_PRISM54 is not set CONFIG_USB_ZD1201=m CONFIG_RTL8187=m # CONFIG_ADM8211 is not set # CONFIG_P54_COMMON is not set # CONFIG_IWLWIFI is not set # CONFIG_HOSTAP is not set CONFIG_BCM43XX=m # CONFIG_BCM43XX_DEBUG is not set CONFIG_BCM43XX_DMA=y CONFIG_BCM43XX_PIO=y CONFIG_BCM43XX_DMA_AND_PIO_MODE=y # CONFIG_BCM43XX_DMA_MODE is not set # CONFIG_BCM43XX_PIO_MODE is not set CONFIG_B43=m CONFIG_B43_PCI_AUTOSELECT=y CONFIG_B43_PCICORE_AUTOSELECT=y CONFIG_B43_RFKILL=y # CONFIG_B43_DEBUG is not set CONFIG_B43_DMA=y CONFIG_B43_PIO=y CONFIG_B43_DMA_AND_PIO_MODE=y # CONFIG_B43_DMA_MODE is not set # CONFIG_B43_PIO_MODE is not set CONFIG_B43LEGACY=m CONFIG_B43LEGACY_PCI_AUTOSELECT=y CONFIG_B43LEGACY_PCICORE_AUTOSELECT=y # CONFIG_B43LEGACY_DEBUG is not set CONFIG_B43LEGACY_DMA=y CONFIG_B43LEGACY_PIO=y CONFIG_B43LEGACY_DMA_AND_PIO_MODE=y # CONFIG_B43LEGACY_DMA_MODE is not set # CONFIG_B43LEGACY_PIO_MODE is not set CONFIG_ZD1211RW=m # CONFIG_ZD1211RW_DEBUG is not set # CONFIG_RT2X00 is not set # # USB Network Adapters # CONFIG_USB_CATC=m CONFIG_USB_KAWETH=m CONFIG_USB_PEGASUS=m CONFIG_USB_RTL8150=m CONFIG_USB_USBNET=m CONFIG_USB_NET_AX8817X=m CONFIG_USB_NET_CDCETHER=m CONFIG_USB_NET_DM9601=m CONFIG_USB_NET_GL620A=m CONFIG_USB_NET_NET1080=m CONFIG_USB_NET_PLUSB=m # CONFIG_USB_NET_MCS7830 is not set CONFIG_USB_NET_RNDIS_HOST=m CONFIG_USB_NET_CDC_SUBSET=m CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_BELKIN=y CONFIG_USB_ARMLINUX=y CONFIG_USB_EPSON2888=y CONFIG_USB_KC2190=y CONFIG_USB_NET_ZAURUS=m # CONFIG_WAN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set CONFIG_PPP=m CONFIG_PPP_MULTILINK=y CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPP_MPPE=m CONFIG_PPPOE=m CONFIG_PPPOL2TP=m # CONFIG_SLIP is not set CONFIG_SLHC=m # CONFIG_NET_FC is not set CONFIG_SHAPER=m CONFIG_NETCONSOLE=m # CONFIG_NETCONSOLE_DYNAMIC is not set CONFIG_NETPOLL=y # CONFIG_NETPOLL_TRAP is not set CONFIG_NET_POLL_CONTROLLER=y # CONFIG_ISDN is not set # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # CONFIG_INPUT_FF_MEMLESS is not set CONFIG_INPUT_POLLDEV=m # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=m CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set CONFIG_INPUT_EVDEV=y CONFIG_INPUT_EVBUG=m # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_KEYBOARD_STOWAWAY is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=m CONFIG_MOUSE_PS2_ALPS=y CONFIG_MOUSE_PS2_LOGIPS2PP=y CONFIG_MOUSE_PS2_SYNAPTICS=y # CONFIG_MOUSE_PS2_LIFEBOOK is not set # CONFIG_MOUSE_PS2_TRACKPOINT is not set # CONFIG_MOUSE_PS2_TOUCHKIT is not set CONFIG_MOUSE_SERIAL=m # CONFIG_MOUSE_APPLETOUCH is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TABLET is not set # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=m # CONFIG_INPUT_WISTRON_BTNS is not set # CONFIG_INPUT_ATLAS_BTNS is not set CONFIG_INPUT_ATI_REMOTE=m CONFIG_INPUT_ATI_REMOTE2=m CONFIG_INPUT_KEYSPAN_REMOTE=m # CONFIG_INPUT_POWERMATE is not set CONFIG_INPUT_YEALINK=m CONFIG_INPUT_UINPUT=m # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=m CONFIG_SERIO_CT82C710=m CONFIG_SERIO_PCIPS2=m CONFIG_SERIO_LIBPS2=y CONFIG_SERIO_RAW=m # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_VT_HW_CONSOLE_BINDING is not set # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=y # CONFIG_SERIAL_8250_CONSOLE is not set CONFIG_FIX_EARLYCON_MEM=y # CONFIG_SERIAL_8250_PCI is not set # CONFIG_SERIAL_8250_PNP is not set CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_RUNTIME_UARTS=2 # CONFIG_SERIAL_8250_EXTENDED is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y # CONFIG_SERIAL_JSM is not set CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 # CONFIG_IPMI_HANDLER is not set CONFIG_HW_RANDOM=y CONFIG_HW_RANDOM_INTEL=m # CONFIG_HW_RANDOM_AMD is not set # CONFIG_HW_RANDOM_GEODE is not set # CONFIG_HW_RANDOM_VIA is not set CONFIG_NVRAM=m # CONFIG_RTC is not set CONFIG_GEN_RTC=y CONFIG_GEN_RTC_X=y # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # CONFIG_MWAVE is not set # CONFIG_PC8736x_GPIO is not set # CONFIG_NSC_GPIO is not set # CONFIG_CS5535_GPIO is not set # CONFIG_RAW_DRIVER is not set CONFIG_HPET=y # CONFIG_HPET_RTC_IRQ is not set CONFIG_HPET_MMAP=y CONFIG_HANGCHECK_TIMER=m # CONFIG_TCG_TPM is not set # CONFIG_TELCLOCK is not set CONFIG_DEVPORT=y CONFIG_I2C=m CONFIG_I2C_BOARDINFO=y CONFIG_I2C_CHARDEV=m # # I2C Algorithms # CONFIG_I2C_ALGOBIT=m # CONFIG_I2C_ALGOPCF is not set # CONFIG_I2C_ALGOPCA is not set # # I2C Hardware Bus support # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set # CONFIG_I2C_PIIX4 is not set # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_OCORES is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PROSAVAGE is not set # CONFIG_I2C_SAVAGE4 is not set # CONFIG_I2C_SIMTEC is not set # CONFIG_SCx200_ACB is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set # CONFIG_I2C_TAOS_EVM is not set # CONFIG_I2C_STUB is not set # CONFIG_I2C_TINY_USB is not set # CONFIG_I2C_VIA is not set # CONFIG_I2C_VIAPRO is not set # CONFIG_I2C_VOODOO3 is not set # # Miscellaneous I2C Chip support # # CONFIG_SENSORS_DS1337 is not set # CONFIG_SENSORS_DS1374 is not set # CONFIG_DS1682 is not set # CONFIG_SENSORS_EEPROM is not set # CONFIG_SENSORS_PCF8574 is not set # CONFIG_SENSORS_PCA9539 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_SENSORS_MAX6875 is not set # CONFIG_SENSORS_TSL2550 is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # # SPI support # # CONFIG_SPI is not set # CONFIG_SPI_MASTER is not set # CONFIG_W1 is not set CONFIG_POWER_SUPPLY=m # CONFIG_POWER_SUPPLY_DEBUG is not set # CONFIG_PDA_POWER is not set # CONFIG_BATTERY_DS2760 is not set # CONFIG_HWMON is not set # CONFIG_WATCHDOG is not set # # Sonics Silicon Backplane # CONFIG_SSB_POSSIBLE=y CONFIG_SSB=m CONFIG_SSB_PCIHOST_POSSIBLE=y CONFIG_SSB_PCIHOST=y CONFIG_SSB_SILENT=y CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y CONFIG_SSB_DRIVER_PCICORE=y # # Multifunction device drivers # # CONFIG_MFD_SM501 is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # CONFIG_DVB_CORE is not set # CONFIG_DAB is not set # # Graphics support # CONFIG_AGP=m # CONFIG_AGP_ALI is not set CONFIG_AGP_ATI=m # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set CONFIG_AGP_INTEL=m # CONFIG_AGP_NVIDIA is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_SWORKS is not set # CONFIG_AGP_VIA is not set # CONFIG_AGP_EFFICEON is not set CONFIG_DRM=m # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set CONFIG_DRM_RADEON=m # CONFIG_DRM_I810 is not set # CONFIG_DRM_I830 is not set # CONFIG_DRM_I915 is not set # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # CONFIG_DRM_VIA is not set # CONFIG_DRM_SAVAGE is not set # CONFIG_VGASTATE is not set # CONFIG_VIDEO_OUTPUT_CONTROL is not set CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_DDC=m CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set # CONFIG_FB_SYS_FILLRECT is not set # CONFIG_FB_SYS_COPYAREA is not set # CONFIG_FB_SYS_IMAGEBLIT is not set # CONFIG_FB_SYS_FOPS is not set CONFIG_FB_DEFERRED_IO=y # CONFIG_FB_SVGALIB is not set # CONFIG_FB_MACMODES is not set CONFIG_FB_BACKLIGHT=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y # # Frame buffer hardware drivers # # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ARC is not set # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set # CONFIG_FB_VGA16 is not set CONFIG_FB_VESA=y # CONFIG_FB_HECUBA is not set # CONFIG_FB_HGA is not set # CONFIG_FB_S1D13XXX is not set # CONFIG_FB_NVIDIA is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_I810 is not set # CONFIG_FB_LE80578 is not set # CONFIG_FB_INTEL is not set # CONFIG_FB_MATROX is not set CONFIG_FB_RADEON=m CONFIG_FB_RADEON_I2C=y CONFIG_FB_RADEON_BACKLIGHT=y # CONFIG_FB_RADEON_DEBUG is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_S3 is not set # CONFIG_FB_SAVAGE is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_VT8623 is not set # CONFIG_FB_CYBLA is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_ARK is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_GEODE is not set # CONFIG_FB_VIRTUAL is not set CONFIG_BACKLIGHT_LCD_SUPPORT=y # CONFIG_LCD_CLASS_DEVICE is not set CONFIG_BACKLIGHT_CLASS_DEVICE=y # CONFIG_BACKLIGHT_CORGI is not set # CONFIG_BACKLIGHT_PROGEAR is not set # # Display device support # # CONFIG_DISPLAY_SUPPORT is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_VGACON_SOFT_SCROLLBACK=y CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64 CONFIG_VIDEO_SELECT=y CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=m # CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # CONFIG_LOGO is not set # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_PCM_OSS_PLUGINS=y CONFIG_SND_SEQUENCER_OSS=y # CONFIG_SND_DYNAMIC_MINORS is not set CONFIG_SND_SUPPORT_OLD_API=y # CONFIG_SND_VERBOSE_PROCFS is not set # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # CONFIG_SND_AC97_CODEC=m # CONFIG_SND_DUMMY is not set # CONFIG_SND_VIRMIDI is not set # CONFIG_SND_MTPAV is not set # CONFIG_SND_SERIAL_U16550 is not set # CONFIG_SND_MPU401 is not set # # PCI devices # CONFIG_SND_AD1889=m # CONFIG_SND_ALS300 is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_ATIIXP_MODEM is not set # CONFIG_SND_AU8810 is not set # CONFIG_SND_AU8820 is not set # CONFIG_SND_AU8830 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_BT87X is not set # CONFIG_SND_CA0106 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_CS4281 is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS5530 is not set # CONFIG_SND_CS5535AUDIO is not set # CONFIG_SND_DARLA20 is not set # CONFIG_SND_GINA20 is not set # CONFIG_SND_LAYLA20 is not set # CONFIG_SND_DARLA24 is not set # CONFIG_SND_GINA24 is not set # CONFIG_SND_LAYLA24 is not set # CONFIG_SND_MONA is not set # CONFIG_SND_MIA is not set # CONFIG_SND_ECHO3G is not set # CONFIG_SND_INDIGO is not set # CONFIG_SND_INDIGOIO is not set # CONFIG_SND_INDIGODJ is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_EMU10K1X is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_FM801 is not set CONFIG_SND_HDA_INTEL=m # CONFIG_SND_HDA_HWDEP is not set CONFIG_SND_HDA_CODEC_REALTEK=y CONFIG_SND_HDA_CODEC_ANALOG=y CONFIG_SND_HDA_CODEC_SIGMATEL=y CONFIG_SND_HDA_CODEC_VIA=y CONFIG_SND_HDA_CODEC_ATIHDMI=y CONFIG_SND_HDA_CODEC_CONEXANT=y CONFIG_SND_HDA_CODEC_CMEDIA=y CONFIG_SND_HDA_CODEC_SI3054=y CONFIG_SND_HDA_GENERIC=y CONFIG_SND_HDA_POWER_SAVE=y CONFIG_SND_HDA_POWER_SAVE_DEFAULT=10 # CONFIG_SND_HDSP is not set # CONFIG_SND_HDSPM is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set CONFIG_SND_INTEL8X0=m CONFIG_SND_INTEL8X0M=m # CONFIG_SND_KORG1212 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_MIXART is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_PCXHR is not set # CONFIG_SND_RIPTIDE is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_SONICVIBES is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_VIA82XX is not set # CONFIG_SND_VIA82XX_MODEM is not set # CONFIG_SND_VX222 is not set # CONFIG_SND_YMFPCI is not set CONFIG_SND_AC97_POWER_SAVE=y CONFIG_SND_AC97_POWER_SAVE_DEFAULT=10 # # USB devices # CONFIG_SND_USB_AUDIO=m CONFIG_SND_USB_USX2Y=m CONFIG_SND_USB_CAIAQ=m # CONFIG_SND_USB_CAIAQ_INPUT is not set # # System on Chip audio support # # CONFIG_SND_SOC is not set # # SoC Audio support for SuperH # # # Open Sound System # CONFIG_SOUND_PRIME=m # CONFIG_SOUND_TRIDENT is not set # CONFIG_SOUND_MSNDCLAS is not set # CONFIG_SOUND_MSNDPIN is not set CONFIG_SOUND_OSS=m # CONFIG_SOUND_TRACEINIT is not set # CONFIG_SOUND_DMAP is not set # CONFIG_SOUND_SSCAPE is not set CONFIG_SOUND_VMIDI=m # CONFIG_SOUND_TRIX is not set CONFIG_SOUND_MSS=m CONFIG_SOUND_MPU401=m # CONFIG_SOUND_PAS is not set # CONFIG_SOUND_PSS is not set CONFIG_SOUND_SB=m # CONFIG_SOUND_YM3812 is not set CONFIG_SOUND_UART6850=m # CONFIG_SOUND_AEDSP16 is not set # CONFIG_SOUND_KAHLUA is not set CONFIG_AC97_BUS=m CONFIG_HID_SUPPORT=y CONFIG_HID=m # CONFIG_HID_DEBUG is not set CONFIG_HIDRAW=y # # USB Input Devices # CONFIG_USB_HID=m # CONFIG_USB_HIDINPUT_POWERBOOK is not set # CONFIG_HID_FF is not set CONFIG_USB_HIDDEV=y # # USB HID Boot Protocol drivers # # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set CONFIG_USB_SUPPORT=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB=m # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y CONFIG_USB_DEVICE_CLASS=y # CONFIG_USB_DYNAMIC_MINORS is not set CONFIG_USB_SUSPEND=y CONFIG_USB_PERSIST=y # CONFIG_USB_OTG is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=m CONFIG_USB_EHCI_SPLIT_ISO=y CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_EHCI_TT_NEWSCHED=y # CONFIG_USB_ISP116X_HCD is not set CONFIG_USB_OHCI_HCD=m # CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set # CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_UHCI_HCD=m # CONFIG_USB_U132_HCD is not set CONFIG_USB_SL811_HCD=m # CONFIG_USB_R8A66597_HCD is not set # # USB Device Class drivers # CONFIG_USB_ACM=m CONFIG_USB_PRINTER=m # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' # # # may also be needed; see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set CONFIG_USB_STORAGE_DATAFAB=y CONFIG_USB_STORAGE_FREECOM=y CONFIG_USB_STORAGE_ISD200=y CONFIG_USB_STORAGE_DPCM=y CONFIG_USB_STORAGE_USBAT=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y CONFIG_USB_STORAGE_ALAUDA=y # CONFIG_USB_STORAGE_KARMA is not set CONFIG_USB_LIBUSUAL=y # # USB Imaging devices # CONFIG_USB_MDC800=m CONFIG_USB_MICROTEK=m CONFIG_USB_MON=y # # USB port drivers # # # USB Serial Converter support # CONFIG_USB_SERIAL=m CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_AIRCABLE=m CONFIG_USB_SERIAL_AIRPRIME=m CONFIG_USB_SERIAL_ARK3116=m CONFIG_USB_SERIAL_BELKIN=m CONFIG_USB_SERIAL_CH341=m CONFIG_USB_SERIAL_WHITEHEAT=m CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m CONFIG_USB_SERIAL_CP2101=m CONFIG_USB_SERIAL_CYPRESS_M8=m CONFIG_USB_SERIAL_EMPEG=m CONFIG_USB_SERIAL_FTDI_SIO=m CONFIG_USB_SERIAL_FUNSOFT=m CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_IPAQ=m CONFIG_USB_SERIAL_IR=m CONFIG_USB_SERIAL_EDGEPORT=m CONFIG_USB_SERIAL_EDGEPORT_TI=m CONFIG_USB_SERIAL_GARMIN=m CONFIG_USB_SERIAL_IPW=m CONFIG_USB_SERIAL_KEYSPAN_PDA=m CONFIG_USB_SERIAL_KEYSPAN=m CONFIG_USB_SERIAL_KEYSPAN_MPR=y CONFIG_USB_SERIAL_KEYSPAN_USA28=y CONFIG_USB_SERIAL_KEYSPAN_USA28X=y CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y CONFIG_USB_SERIAL_KEYSPAN_USA19=y CONFIG_USB_SERIAL_KEYSPAN_USA18X=y CONFIG_USB_SERIAL_KEYSPAN_USA19W=y CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y CONFIG_USB_SERIAL_KEYSPAN_USA49W=y CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y CONFIG_USB_SERIAL_KLSI=m CONFIG_USB_SERIAL_KOBIL_SCT=m CONFIG_USB_SERIAL_MCT_U232=m CONFIG_USB_SERIAL_MOS7720=m CONFIG_USB_SERIAL_MOS7840=m CONFIG_USB_SERIAL_NAVMAN=m CONFIG_USB_SERIAL_PL2303=m CONFIG_USB_SERIAL_OTI6858=m # CONFIG_USB_SERIAL_HP4X is not set CONFIG_USB_SERIAL_SAFE=m CONFIG_USB_SERIAL_SAFE_PADDED=y CONFIG_USB_SERIAL_SIERRAWIRELESS=m CONFIG_USB_SERIAL_TI=m CONFIG_USB_SERIAL_CYBERJACK=m CONFIG_USB_SERIAL_XIRCOM=m CONFIG_USB_SERIAL_OPTION=m CONFIG_USB_SERIAL_OMNINET=m # CONFIG_USB_SERIAL_DEBUG is not set CONFIG_USB_EZUSB=y # # USB Miscellaneous drivers # CONFIG_USB_EMI62=m CONFIG_USB_EMI26=m CONFIG_USB_ADUTUX=m CONFIG_USB_AUERSWALD=m CONFIG_USB_RIO500=m CONFIG_USB_LEGOTOWER=m CONFIG_USB_LCD=m # CONFIG_USB_BERRY_CHARGE is not set CONFIG_USB_LED=m CONFIG_USB_CYPRESS_CY7C63=m CONFIG_USB_CYTHERM=m # CONFIG_USB_PHIDGET is not set CONFIG_USB_IDMOUSE=m CONFIG_USB_FTDI_ELAN=m # CONFIG_USB_APPLEDISPLAY is not set CONFIG_USB_SISUSBVGA=m # CONFIG_USB_SISUSBVGA_CON is not set CONFIG_USB_LD=m # CONFIG_USB_TRANCEVIBRATOR is not set # CONFIG_USB_IOWARRIOR is not set CONFIG_USB_TEST=m # # USB DSL modem support # # # USB Gadget Support # # CONFIG_USB_GADGET is not set CONFIG_MMC=m # CONFIG_MMC_DEBUG is not set # CONFIG_MMC_UNSAFE_RESUME is not set # # MMC/SD Card Drivers # CONFIG_MMC_BLOCK=m CONFIG_MMC_BLOCK_BOUNCE=y # CONFIG_SDIO_UART is not set # # MMC/SD Host Controller Drivers # CONFIG_MMC_SDHCI=m CONFIG_MMC_RICOH_MMC=m # CONFIG_MMC_WBSD is not set CONFIG_MMC_TIFM_SD=m # CONFIG_NEW_LEDS is not set # CONFIG_INFINIBAND is not set # CONFIG_EDAC is not set CONFIG_RTC_LIB=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE="rtc0" # CONFIG_RTC_DEBUG is not set # # RTC interfaces # CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y # CONFIG_RTC_INTF_DEV_UIE_EMUL is not set CONFIG_RTC_DRV_TEST=m # # I2C RTC drivers # CONFIG_RTC_DRV_DS1307=m CONFIG_RTC_DRV_DS1374=m CONFIG_RTC_DRV_DS1672=m CONFIG_RTC_DRV_MAX6900=m CONFIG_RTC_DRV_RS5C372=m CONFIG_RTC_DRV_ISL1208=m CONFIG_RTC_DRV_X1205=m CONFIG_RTC_DRV_PCF8563=m CONFIG_RTC_DRV_PCF8583=m # CONFIG_RTC_DRV_M41T80 is not set # # SPI RTC drivers # # # Platform RTC drivers # CONFIG_RTC_DRV_CMOS=y CONFIG_RTC_DRV_DS1553=m # CONFIG_RTC_DRV_STK17TA8 is not set CONFIG_RTC_DRV_DS1742=m CONFIG_RTC_DRV_M48T86=m # CONFIG_RTC_DRV_M48T59 is not set CONFIG_RTC_DRV_V3020=m # # on-CPU RTC drivers # CONFIG_DMADEVICES=y # # DMA Devices # CONFIG_INTEL_IOATDMA=m CONFIG_DMA_ENGINE=y # # DMA Clients # CONFIG_NET_DMA=y CONFIG_DCA=m # CONFIG_VIRTUALIZATION is not set # # Userspace I/O # CONFIG_UIO=m # CONFIG_UIO_CIF is not set # # File systems # CONFIG_EXT2_FS=m # CONFIG_EXT2_FS_XATTR is not set CONFIG_EXT2_FS_XIP=y CONFIG_FS_XIP=y CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set # CONFIG_EXT4DEV_FS is not set CONFIG_JBD=y # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set CONFIG_FS_POSIX_ACL=y # CONFIG_XFS_FS is not set # CONFIG_GFS2_FS is not set # CONFIG_OCFS2_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_ROMFS_FS is not set CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y # CONFIG_QUOTA is not set CONFIG_DNOTIFY=y # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set CONFIG_FUSE_FS=m # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=m CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_UDF_FS=m CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" CONFIG_NTFS_FS=m # CONFIG_NTFS_DEBUG is not set CONFIG_NTFS_RW=y # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_SYSCTL=y CONFIG_SYSFS=y CONFIG_TMPFS=y # CONFIG_TMPFS_POSIX_ACL is not set # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_CONFIGFS_FS=m # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set CONFIG_HFS_FS=m CONFIG_HFSPLUS_FS=m # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=m CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y CONFIG_NFS_DIRECTIO=y CONFIG_NFSD=m CONFIG_NFSD_V2_ACL=y CONFIG_NFSD_V3=y CONFIG_NFSD_V3_ACL=y CONFIG_NFSD_V4=y CONFIG_NFSD_TCP=y CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_NFS_ACL_SUPPORT=m CONFIG_NFS_COMMON=y CONFIG_SUNRPC=m CONFIG_SUNRPC_GSS=m CONFIG_SUNRPC_BIND34=y CONFIG_RPCSEC_GSS_KRB5=m # CONFIG_RPCSEC_GSS_SPKM3 is not set CONFIG_SMB_FS=m CONFIG_SMB_NLS_DEFAULT=y CONFIG_SMB_NLS_REMOTE="cp437" CONFIG_CIFS=m # CONFIG_CIFS_STATS is not set CONFIG_CIFS_WEAK_PW_HASH=y # CONFIG_CIFS_XATTR is not set # CONFIG_CIFS_DEBUG2 is not set # CONFIG_CIFS_EXPERIMENTAL is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set CONFIG_MAC_PARTITION=y CONFIG_MSDOS_PARTITION=y # CONFIG_BSD_DISKLABEL is not set # CONFIG_MINIX_SUBPARTITION is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set CONFIG_LDM_PARTITION=y # CONFIG_LDM_DEBUG is not set # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set # CONFIG_KARMA_PARTITION is not set # CONFIG_EFI_PARTITION is not set # CONFIG_SYSV68_PARTITION is not set CONFIG_NLS=y CONFIG_NLS_DEFAULT="cp437" CONFIG_NLS_CODEPAGE_437=m # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set CONFIG_NLS_CODEPAGE_850=m # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set CONFIG_NLS_CODEPAGE_863=m # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ASCII=m CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_UTF8=m CONFIG_DLM=m # CONFIG_DLM_DEBUG is not set # CONFIG_INSTRUMENTATION is not set # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_PRINTK_TIME=y # CONFIG_ENABLE_WARN_DEPRECATED is not set # CONFIG_ENABLE_MUST_CHECK is not set CONFIG_MAGIC_SYSRQ=y # CONFIG_UNUSED_SYMBOLS is not set # CONFIG_DEBUG_FS is not set # CONFIG_HEADERS_CHECK is not set CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_SHIRQ is not set CONFIG_DETECT_SOFTLOCKUP=y # CONFIG_SCHED_DEBUG is not set # CONFIG_SCHEDSTATS is not set CONFIG_TIMER_STATS=y # CONFIG_DEBUG_PREEMPT is not set # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_RT_MUTEX_TESTER is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_MUTEXES is not set # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set # CONFIG_LOCK_STAT is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_HIGHMEM is not set CONFIG_DEBUG_BUGVERBOSE=y # CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_LIST is not set CONFIG_DEBUG_SG=y # CONFIG_FRAME_POINTER is not set # CONFIG_FORCED_INLINING is not set CONFIG_BOOT_PRINTK_DELAY=y # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_FAULT_INJECTION is not set # CONFIG_SAMPLES is not set # CONFIG_EARLY_PRINTK is not set # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_STACK_USAGE is not set # # Page alloc debug is incompatible with Software Suspend on i386 # # CONFIG_DEBUG_RODATA is not set CONFIG_4KSTACKS=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y CONFIG_DOUBLEFAULT=y # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set # CONFIG_SECURITY_FILE_CAPABILITIES is not set CONFIG_CRYPTO=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ABLKCIPHER=m CONFIG_CRYPTO_BLKCIPHER=m CONFIG_CRYPTO_HASH=m CONFIG_CRYPTO_MANAGER=m CONFIG_CRYPTO_HMAC=m CONFIG_CRYPTO_XCBC=m CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=y CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_GF128MUL=m CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_CBC=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_LRW=m # CONFIG_CRYPTO_XTS is not set CONFIG_CRYPTO_CRYPTD=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH_586=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_AES_586=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_ANUBIS=m # CONFIG_CRYPTO_SEED is not set CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_CRC32C=m CONFIG_CRYPTO_CAMELLIA=m # CONFIG_CRYPTO_TEST is not set # CONFIG_CRYPTO_AUTHENC is not set # CONFIG_CRYPTO_HW is not set # # Library routines # CONFIG_BITREVERSE=m CONFIG_CRC_CCITT=m CONFIG_CRC16=m CONFIG_CRC_ITU_T=m CONFIG_CRC32=m CONFIG_CRC7=m CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=m CONFIG_TEXTSEARCH_BM=m CONFIG_TEXTSEARCH_FSM=m CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_KTIME_SCALAR=y ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-15 16:51 ` Mark Lord @ 2007-11-15 16:53 ` Mark Lord 0 siblings, 0 replies; 268+ messages in thread From: Mark Lord @ 2007-11-15 16:53 UTC (permalink / raw) To: Ray Lee Cc: Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw Mark Lord wrote: > Ray Lee wrote: >.. >>> The real question is, why the 1-sec pauses? >> >> Well, and why the 1-second pauses eventually stop, too. Seems >> interesting that they don't continue. Also, they're pretty much >> dead-on one- and two-second pauses, with HZ accuracy. Is this with a >> NO_HZ kernel? > .. > > Yes, A NO_HZ kernel. Full config follows: .. Blah.. that was for the wrong kernel. Here is the correct .config that was in use for both suspend logs: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23.1 # Wed Nov 14 09:41:54 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 # CONFIG_CPUSETS is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set CONFIG_BLK_DEV_BSG=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MCORE2=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 CONFIG_HPET_TIMER=y CONFIG_NR_CPUS=2 # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y # CONFIG_X86_MCE is not set CONFIG_VM86=y # CONFIG_TOSHIBA is not set CONFIG_I8K=m CONFIG_X86_REBOOTFIXUPS=y CONFIG_MICROCODE=m CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # CONFIG_EDD=m CONFIG_DELL_RBU=m CONFIG_DCDBAS=m CONFIG_DMIID=y # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_VMSPLIT_3G=y # CONFIG_VMSPLIT_3G_OPT is not set # CONFIG_VMSPLIT_2G is not set # CONFIG_VMSPLIT_2G_OPT is not set # CONFIG_VMSPLIT_1G is not set CONFIG_PAGE_OFFSET=0xC0000000 CONFIG_HIGHMEM=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_SPARSEMEM_STATIC=y CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_RESOURCES_64BIT is not set CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_NR_QUICK=1 CONFIG_VIRT_TO_BUS=y # CONFIG_HIGHPTE is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set # CONFIG_IRQBALANCE is not set # CONFIG_SECCOMP is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_300=y # CONFIG_HZ_1000 is not set CONFIG_HZ=300 # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x100000 # CONFIG_RELOCATABLE is not set CONFIG_PHYSICAL_ALIGN=0x100000 CONFIG_HOTPLUG_CPU=y # CONFIG_COMPAT_VDSO is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y # # Power management options (ACPI, APM) # CONFIG_PM=y CONFIG_PM_LEGACY=y # CONFIG_PM_DEBUG is not set CONFIG_PM_SLEEP_SMP=y CONFIG_PM_SLEEP=y CONFIG_SUSPEND_SMP_POSSIBLE=y CONFIG_SUSPEND=y CONFIG_HIBERNATION_SMP_POSSIBLE=y CONFIG_HIBERNATION=y CONFIG_PM_STD_PARTITION="/dev/sda3" CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_PROCFS=y CONFIG_ACPI_PROC_EVENT=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_FAN=m # CONFIG_ACPI_DOCK is not set CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_ACPI_THERMAL=m # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y CONFIG_ACPI_CONTAINER=m # CONFIG_ACPI_SBS is not set # CONFIG_APM is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=m # CONFIG_CPU_FREQ_DEBUG is not set CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m # # CPUFreq processor drivers # CONFIG_X86_ACPI_CPUFREQ=m # CONFIG_X86_POWERNOW_K6 is not set # CONFIG_X86_POWERNOW_K7 is not set # CONFIG_X86_POWERNOW_K8 is not set # CONFIG_X86_GX_SUSPMOD is not set CONFIG_X86_SPEEDSTEP_CENTRINO=m CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y CONFIG_X86_SPEEDSTEP_ICH=m # CONFIG_X86_SPEEDSTEP_SMI is not set # CONFIG_X86_P4_CLOCKMOD is not set # CONFIG_X86_CPUFREQ_NFORCE2 is not set # CONFIG_X86_LONGRUN is not set # CONFIG_X86_LONGHAUL is not set # CONFIG_X86_E_POWERSAVER is not set # # shared options # # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set CONFIG_X86_SPEEDSTEP_LIB=m # CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCIEPORTBUS=y CONFIG_HOTPLUG_PCI_PCIE=m # CONFIG_HOTPLUG_PCI_PCIE_POLL_EVENT_MODE is not set CONFIG_PCIEAER=y CONFIG_ARCH_SUPPORTS_MSI=y # CONFIG_PCI_MSI is not set # CONFIG_PCI_DEBUG is not set # CONFIG_HT_IRQ is not set CONFIG_ISA_DMA_API=y # CONFIG_ISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set CONFIG_HOTPLUG_PCI=m # CONFIG_HOTPLUG_PCI_FAKE is not set # CONFIG_HOTPLUG_PCI_COMPAQ is not set # CONFIG_HOTPLUG_PCI_IBM is not set # CONFIG_HOTPLUG_PCI_ACPI is not set # CONFIG_HOTPLUG_PCI_CPCI is not set # CONFIG_HOTPLUG_PCI_SHPC is not set # # Executable file formats # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_MISC=m # # Networking # CONFIG_NET=y # # Networking options # CONFIG_PACKET=m CONFIG_PACKET_MMAP=y CONFIG_UNIX=m CONFIG_XFRM=y CONFIG_XFRM_USER=m # CONFIG_XFRM_SUB_POLICY is not set # CONFIG_XFRM_MIGRATE is not set CONFIG_NET_KEY=m # CONFIG_NET_KEY_MIGRATE is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_ASK_IP_FIB_HASH=y # CONFIG_IP_FIB_TRIE is not set CONFIG_IP_FIB_HASH=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m CONFIG_INET_XFRM_TUNNEL=m CONFIG_INET_TUNNEL=m CONFIG_INET_XFRM_MODE_TRANSPORT=m CONFIG_INET_XFRM_MODE_TUNNEL=m CONFIG_INET_XFRM_MODE_BEET=m CONFIG_INET_DIAG=m CONFIG_INET_TCP_DIAG=m # CONFIG_TCP_CONG_ADVANCED is not set CONFIG_TCP_CONG_CUBIC=y CONFIG_DEFAULT_TCP_CONG="cubic" # CONFIG_TCP_MD5SIG is not set # CONFIG_IPV6 is not set # CONFIG_INET6_XFRM_TUNNEL is not set # CONFIG_INET6_TUNNEL is not set # CONFIG_NETWORK_SECMARK is not set # CONFIG_NETFILTER is not set # CONFIG_IP_DCCP is not set CONFIG_IP_SCTP=m # CONFIG_SCTP_DBG_MSG is not set # CONFIG_SCTP_DBG_OBJCNT is not set # CONFIG_SCTP_HMAC_NONE is not set # CONFIG_SCTP_HMAC_SHA1 is not set CONFIG_SCTP_HMAC_MD5=y # CONFIG_TIPC is not set # CONFIG_ATM is not set CONFIG_BRIDGE=m CONFIG_VLAN_8021Q=m # CONFIG_DECNET is not set CONFIG_LLC=m # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # # QoS and/or fair queueing # CONFIG_NET_SCHED=y CONFIG_NET_SCH_FIFO=y # # Queueing/Scheduling # CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RR=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_INGRESS=m # # Classification # CONFIG_NET_CLS=y CONFIG_NET_CLS_BASIC=m CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_CLS_U32_PERF=y CONFIG_CLS_U32_MARK=y CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_EMATCH=y CONFIG_NET_EMATCH_STACK=32 CONFIG_NET_EMATCH_CMP=m CONFIG_NET_EMATCH_NBYTE=m CONFIG_NET_EMATCH_U32=m CONFIG_NET_EMATCH_META=m CONFIG_NET_EMATCH_TEXT=m CONFIG_NET_CLS_ACT=y CONFIG_NET_ACT_POLICE=m CONFIG_NET_ACT_GACT=m CONFIG_GACT_PROB=y CONFIG_NET_ACT_MIRRED=m CONFIG_NET_ACT_PEDIT=m CONFIG_NET_ACT_SIMP=m # CONFIG_NET_CLS_POLICE is not set # CONFIG_NET_CLS_IND is not set # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set CONFIG_BT=m CONFIG_BT_L2CAP=m CONFIG_BT_SCO=m CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=m CONFIG_BT_BNEP_MC_FILTER=y CONFIG_BT_BNEP_PROTO_FILTER=y CONFIG_BT_HIDP=m # # Bluetooth device drivers # CONFIG_BT_HCIUSB=m CONFIG_BT_HCIUSB_SCO=y CONFIG_BT_HCIUART=m CONFIG_BT_HCIUART_H4=y CONFIG_BT_HCIUART_BCSP=y CONFIG_BT_HCIBCM203X=m CONFIG_BT_HCIBPA10X=m CONFIG_BT_HCIBFUSB=m CONFIG_BT_HCIVHCI=m # CONFIG_AF_RXRPC is not set CONFIG_FIB_RULES=y # # Wireless # CONFIG_CFG80211=m CONFIG_WIRELESS_EXT=y CONFIG_MAC80211=m # CONFIG_MAC80211_DEBUG is not set CONFIG_IEEE80211=m # CONFIG_IEEE80211_DEBUG is not set CONFIG_IEEE80211_CRYPT_WEP=m CONFIG_IEEE80211_CRYPT_CCMP=m CONFIG_IEEE80211_CRYPT_TKIP=m CONFIG_IEEE80211_SOFTMAC=m # CONFIG_IEEE80211_SOFTMAC_DEBUG is not set CONFIG_RFKILL=m CONFIG_RFKILL_INPUT=m # CONFIG_NET_9P is not set # # Device Drivers # # # Generic Driver Options # CONFIG_STANDALONE=y # CONFIG_PREVENT_FIRMWARE_BUILD is not set CONFIG_FW_LOADER=m # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set # CONFIG_CONNECTOR is not set # CONFIG_MTD is not set # CONFIG_PARPORT is not set CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # CONFIG_PNPACPI=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_FD=m # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=4 CONFIG_BLK_DEV_RAM_SIZE=8192 CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024 CONFIG_CDROM_PKTCDVD=m CONFIG_CDROM_PKTCDVD_BUFFERS=8 # CONFIG_CDROM_PKTCDVD_WCACHE is not set CONFIG_ATA_OVER_ETH=m CONFIG_MISC_DEVICES=y # CONFIG_IBM_ASM is not set # CONFIG_PHANTOM is not set CONFIG_EEPROM_93CX6=m # CONFIG_SGI_IOC4 is not set CONFIG_TIFM_CORE=m # CONFIG_TIFM_7XX1 is not set # CONFIG_MSI_LAPTOP is not set # CONFIG_SONY_LAPTOP is not set # CONFIG_THINKPAD_ACPI is not set CONFIG_IDE=m CONFIG_IDE_MAX_HWIFS=2 CONFIG_BLK_DEV_IDE=m # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_IDE_SATA is not set # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=m CONFIG_IDEDISK_MULTI_MODE=y # CONFIG_BLK_DEV_IDECD is not set # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_BLK_DEV_IDEACPI is not set CONFIG_IDE_TASK_IOCTL=y CONFIG_IDE_PROC_FS=y # # IDE chipset support/bugfixes # # CONFIG_IDE_GENERIC is not set # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_IDEPNP is not set # CONFIG_BLK_DEV_IDEPCI is not set # CONFIG_IDEPCI_PCIBUS_ORDER is not set # CONFIG_IDE_ARM is not set # CONFIG_BLK_DEV_IDEDMA is not set # CONFIG_BLK_DEV_HD is not set # # SCSI device support # # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y CONFIG_SCSI_DMA=y # CONFIG_SCSI_TGT is not set # CONFIG_SCSI_NETLINK is not set CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_CHR_DEV_SG=m # CONFIG_CHR_DEV_SCH is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y CONFIG_SCSI_SCAN_ASYNC=y CONFIG_SCSI_WAIT_SCAN=m # # SCSI Transports # # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_ISCSI_ATTRS is not set # CONFIG_SCSI_SAS_ATTRS is not set # CONFIG_SCSI_SAS_LIBSAS is not set # CONFIG_SCSI_LOWLEVEL is not set CONFIG_ATA=y # CONFIG_ATA_NONSTANDARD is not set CONFIG_ATA_ACPI=y # CONFIG_SATA_AHCI is not set # CONFIG_SATA_SVW is not set CONFIG_ATA_PIIX=y # CONFIG_SATA_MV is not set # CONFIG_SATA_NV is not set # CONFIG_PDC_ADMA is not set CONFIG_SATA_QSTOR=m # CONFIG_SATA_PROMISE is not set # CONFIG_SATA_SX4 is not set # CONFIG_SATA_SIL is not set CONFIG_SATA_SIL24=m # CONFIG_SATA_SIS is not set # CONFIG_SATA_ULI is not set # CONFIG_SATA_VIA is not set # CONFIG_SATA_VITESSE is not set # CONFIG_SATA_INIC162X is not set # CONFIG_PATA_ALI is not set # CONFIG_PATA_AMD is not set # CONFIG_PATA_ARTOP is not set # CONFIG_PATA_ATIIXP is not set # CONFIG_PATA_CMD640_PCI is not set # CONFIG_PATA_CMD64X is not set # CONFIG_PATA_CS5520 is not set # CONFIG_PATA_CS5530 is not set # CONFIG_PATA_CS5535 is not set # CONFIG_PATA_CYPRESS is not set # CONFIG_PATA_EFAR is not set # CONFIG_ATA_GENERIC is not set # CONFIG_PATA_HPT366 is not set # CONFIG_PATA_HPT37X is not set # CONFIG_PATA_HPT3X2N is not set # CONFIG_PATA_HPT3X3 is not set # CONFIG_PATA_IT821X is not set # CONFIG_PATA_IT8213 is not set # CONFIG_PATA_JMICRON is not set # CONFIG_PATA_TRIFLEX is not set # CONFIG_PATA_MARVELL is not set # CONFIG_PATA_MPIIX is not set # CONFIG_PATA_OLDPIIX is not set # CONFIG_PATA_NETCELL is not set # CONFIG_PATA_NS87410 is not set # CONFIG_PATA_OPTI is not set # CONFIG_PATA_OPTIDMA is not set # CONFIG_PATA_PDC_OLD is not set # CONFIG_PATA_RADISYS is not set # CONFIG_PATA_RZ1000 is not set # CONFIG_PATA_SC1200 is not set # CONFIG_PATA_SERVERWORKS is not set # CONFIG_PATA_PDC2027X is not set # CONFIG_PATA_SIL680 is not set # CONFIG_PATA_SIS is not set # CONFIG_PATA_VIA is not set # CONFIG_PATA_WINBOND is not set # CONFIG_PATA_PLATFORM is not set CONFIG_MD=y CONFIG_BLK_DEV_MD=m # CONFIG_MD_LINEAR is not set CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m # CONFIG_MD_RAID10 is not set # CONFIG_MD_RAID456 is not set # CONFIG_MD_MULTIPATH is not set # CONFIG_MD_FAULTY is not set CONFIG_BLK_DEV_DM=m # CONFIG_DM_DEBUG is not set CONFIG_DM_CRYPT=m CONFIG_DM_SNAPSHOT=m CONFIG_DM_MIRROR=m # CONFIG_DM_ZERO is not set # CONFIG_DM_MULTIPATH is not set # CONFIG_DM_DELAY is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # CONFIG_FUSION_SPI is not set # CONFIG_FUSION_FC is not set # CONFIG_FUSION_SAS is not set # # IEEE 1394 (FireWire) support # CONFIG_FIREWIRE=m CONFIG_FIREWIRE_OHCI=m CONFIG_FIREWIRE_SBP2=m # CONFIG_IEEE1394 is not set # CONFIG_I2O is not set # CONFIG_MACINTOSH_DRIVERS is not set CONFIG_NETDEVICES=y # CONFIG_NETDEVICES_MULTIQUEUE is not set # CONFIG_IFB is not set CONFIG_DUMMY=m CONFIG_BONDING=m CONFIG_MACVLAN=m CONFIG_EQUALIZER=m CONFIG_TUN=m # CONFIG_NET_SB1000 is not set # CONFIG_ARCNET is not set CONFIG_PHYLIB=m # # MII PHY device drivers # # CONFIG_MARVELL_PHY is not set # CONFIG_DAVICOM_PHY is not set # CONFIG_QSEMI_PHY is not set # CONFIG_LXT_PHY is not set # CONFIG_CICADA_PHY is not set # CONFIG_VITESSE_PHY is not set # CONFIG_SMSC_PHY is not set # CONFIG_BROADCOM_PHY is not set # CONFIG_ICPLUS_PHY is not set CONFIG_FIXED_PHY=m CONFIG_FIXED_MII_10_FDX=y CONFIG_FIXED_MII_100_FDX=y CONFIG_NET_ETHERNET=y CONFIG_MII=m # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_CASSINI is not set # CONFIG_NET_VENDOR_3COM is not set # CONFIG_NET_TULIP is not set # CONFIG_HP100 is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set CONFIG_B44=m # CONFIG_FORCEDETH is not set # CONFIG_DGRS is not set # CONFIG_EEPRO100 is not set # CONFIG_E100 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_8139CP is not set # CONFIG_8139TOO is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_SC92031 is not set # CONFIG_NETDEV_1000 is not set # CONFIG_NETDEV_10000 is not set # CONFIG_TR is not set # # Wireless LAN # # CONFIG_WLAN_PRE80211 is not set CONFIG_WLAN_80211=y CONFIG_IPW2100=m CONFIG_IPW2100_MONITOR=y # CONFIG_IPW2100_DEBUG is not set CONFIG_IPW2200=m CONFIG_IPW2200_MONITOR=y CONFIG_IPW2200_RADIOTAP=y CONFIG_IPW2200_PROMISCUOUS=y CONFIG_IPW2200_QOS=y # CONFIG_IPW2200_DEBUG is not set # CONFIG_LIBERTAS is not set # CONFIG_AIRO is not set # CONFIG_HERMES is not set # CONFIG_ATMEL is not set # CONFIG_PRISM54 is not set CONFIG_USB_ZD1201=m CONFIG_RTL8187=m # CONFIG_HOSTAP is not set CONFIG_BCM43XX=m # CONFIG_BCM43XX_DEBUG is not set CONFIG_BCM43XX_DMA=y CONFIG_BCM43XX_PIO=y CONFIG_BCM43XX_DMA_AND_PIO_MODE=y # CONFIG_BCM43XX_DMA_MODE is not set # CONFIG_BCM43XX_PIO_MODE is not set CONFIG_ZD1211RW=m # CONFIG_ZD1211RW_DEBUG is not set # # USB Network Adapters # CONFIG_USB_CATC=m CONFIG_USB_KAWETH=m CONFIG_USB_PEGASUS=m CONFIG_USB_RTL8150=m CONFIG_USB_USBNET_MII=m CONFIG_USB_USBNET=m CONFIG_USB_NET_AX8817X=m CONFIG_USB_NET_CDCETHER=m CONFIG_USB_NET_DM9601=m CONFIG_USB_NET_GL620A=m CONFIG_USB_NET_NET1080=m CONFIG_USB_NET_PLUSB=m # CONFIG_USB_NET_MCS7830 is not set CONFIG_USB_NET_RNDIS_HOST=m CONFIG_USB_NET_CDC_SUBSET=m CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_BELKIN=y CONFIG_USB_ARMLINUX=y CONFIG_USB_EPSON2888=y CONFIG_USB_KC2190=y CONFIG_USB_NET_ZAURUS=m # CONFIG_WAN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set CONFIG_PPP=m CONFIG_PPP_MULTILINK=y CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPP_MPPE=m CONFIG_PPPOE=m CONFIG_PPPOL2TP=m # CONFIG_SLIP is not set CONFIG_SLHC=m # CONFIG_NET_FC is not set CONFIG_SHAPER=m CONFIG_NETCONSOLE=m CONFIG_NETPOLL=y # CONFIG_NETPOLL_TRAP is not set CONFIG_NET_POLL_CONTROLLER=y # CONFIG_ISDN is not set # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # CONFIG_INPUT_FF_MEMLESS is not set CONFIG_INPUT_POLLDEV=m # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=m CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set CONFIG_INPUT_EVDEV=y CONFIG_INPUT_EVBUG=m # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_KEYBOARD_STOWAWAY is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=m CONFIG_MOUSE_PS2_ALPS=y CONFIG_MOUSE_PS2_LOGIPS2PP=y CONFIG_MOUSE_PS2_SYNAPTICS=y # CONFIG_MOUSE_PS2_LIFEBOOK is not set # CONFIG_MOUSE_PS2_TRACKPOINT is not set # CONFIG_MOUSE_PS2_TOUCHKIT is not set CONFIG_MOUSE_SERIAL=m # CONFIG_MOUSE_APPLETOUCH is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TABLET is not set # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=m # CONFIG_INPUT_WISTRON_BTNS is not set # CONFIG_INPUT_ATLAS_BTNS is not set CONFIG_INPUT_ATI_REMOTE=m CONFIG_INPUT_ATI_REMOTE2=m CONFIG_INPUT_KEYSPAN_REMOTE=m # CONFIG_INPUT_POWERMATE is not set CONFIG_INPUT_YEALINK=m CONFIG_INPUT_UINPUT=m # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=m CONFIG_SERIO_CT82C710=m CONFIG_SERIO_PCIPS2=m CONFIG_SERIO_LIBPS2=y CONFIG_SERIO_RAW=m # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_VT_HW_CONSOLE_BINDING is not set # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=y # CONFIG_SERIAL_8250_CONSOLE is not set CONFIG_FIX_EARLYCON_MEM=y # CONFIG_SERIAL_8250_PCI is not set # CONFIG_SERIAL_8250_PNP is not set CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_RUNTIME_UARTS=2 # CONFIG_SERIAL_8250_EXTENDED is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y # CONFIG_SERIAL_JSM is not set CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 # CONFIG_IPMI_HANDLER is not set # CONFIG_WATCHDOG is not set CONFIG_HW_RANDOM=y CONFIG_HW_RANDOM_INTEL=m # CONFIG_HW_RANDOM_AMD is not set # CONFIG_HW_RANDOM_GEODE is not set # CONFIG_HW_RANDOM_VIA is not set CONFIG_NVRAM=m # CONFIG_RTC is not set CONFIG_GEN_RTC=y CONFIG_GEN_RTC_X=y # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set CONFIG_AGP=m # CONFIG_AGP_ALI is not set CONFIG_AGP_ATI=m # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set CONFIG_AGP_INTEL=m # CONFIG_AGP_NVIDIA is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_SWORKS is not set # CONFIG_AGP_VIA is not set # CONFIG_AGP_EFFICEON is not set CONFIG_DRM=m # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set CONFIG_DRM_RADEON=m # CONFIG_DRM_I810 is not set # CONFIG_DRM_I830 is not set # CONFIG_DRM_I915 is not set # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # CONFIG_DRM_VIA is not set # CONFIG_DRM_SAVAGE is not set # CONFIG_MWAVE is not set # CONFIG_PC8736x_GPIO is not set # CONFIG_NSC_GPIO is not set # CONFIG_CS5535_GPIO is not set # CONFIG_RAW_DRIVER is not set CONFIG_HPET=y # CONFIG_HPET_RTC_IRQ is not set CONFIG_HPET_MMAP=y CONFIG_HANGCHECK_TIMER=m # CONFIG_TCG_TPM is not set # CONFIG_TELCLOCK is not set CONFIG_DEVPORT=y CONFIG_I2C=m CONFIG_I2C_BOARDINFO=y CONFIG_I2C_CHARDEV=m # # I2C Algorithms # CONFIG_I2C_ALGOBIT=m # CONFIG_I2C_ALGOPCF is not set # CONFIG_I2C_ALGOPCA is not set # # I2C Hardware Bus support # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set # CONFIG_I2C_PIIX4 is not set # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_OCORES is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PROSAVAGE is not set # CONFIG_I2C_SAVAGE4 is not set # CONFIG_I2C_SIMTEC is not set # CONFIG_SCx200_ACB is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set # CONFIG_I2C_TAOS_EVM is not set # CONFIG_I2C_STUB is not set # CONFIG_I2C_TINY_USB is not set # CONFIG_I2C_VIA is not set # CONFIG_I2C_VIAPRO is not set # CONFIG_I2C_VOODOO3 is not set # # Miscellaneous I2C Chip support # # CONFIG_SENSORS_DS1337 is not set # CONFIG_SENSORS_DS1374 is not set # CONFIG_DS1682 is not set # CONFIG_SENSORS_EEPROM is not set # CONFIG_SENSORS_PCF8574 is not set # CONFIG_SENSORS_PCA9539 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_SENSORS_MAX6875 is not set # CONFIG_SENSORS_TSL2550 is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # # SPI support # # CONFIG_SPI is not set # CONFIG_SPI_MASTER is not set # CONFIG_W1 is not set CONFIG_POWER_SUPPLY=m # CONFIG_POWER_SUPPLY_DEBUG is not set # CONFIG_PDA_POWER is not set # CONFIG_BATTERY_DS2760 is not set # CONFIG_HWMON is not set # # Multifunction device drivers # # CONFIG_MFD_SM501 is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # CONFIG_DVB_CORE is not set # CONFIG_DAB is not set # # Graphics support # CONFIG_BACKLIGHT_LCD_SUPPORT=y # CONFIG_LCD_CLASS_DEVICE is not set CONFIG_BACKLIGHT_CLASS_DEVICE=y # CONFIG_BACKLIGHT_PROGEAR is not set # # Display device support # # CONFIG_DISPLAY_SUPPORT is not set # CONFIG_VGASTATE is not set # CONFIG_VIDEO_OUTPUT_CONTROL is not set CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_DDC=m CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_SYS_FILLRECT is not set # CONFIG_FB_SYS_COPYAREA is not set # CONFIG_FB_SYS_IMAGEBLIT is not set # CONFIG_FB_SYS_FOPS is not set CONFIG_FB_DEFERRED_IO=y # CONFIG_FB_SVGALIB is not set # CONFIG_FB_MACMODES is not set CONFIG_FB_BACKLIGHT=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y # # Frame buffer hardware drivers # # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ARC is not set # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set # CONFIG_FB_VGA16 is not set CONFIG_FB_VESA=y # CONFIG_FB_HECUBA is not set # CONFIG_FB_HGA is not set # CONFIG_FB_S1D13XXX is not set # CONFIG_FB_NVIDIA is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_I810 is not set # CONFIG_FB_LE80578 is not set # CONFIG_FB_INTEL is not set # CONFIG_FB_MATROX is not set CONFIG_FB_RADEON=m CONFIG_FB_RADEON_I2C=y CONFIG_FB_RADEON_BACKLIGHT=y # CONFIG_FB_RADEON_DEBUG is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_S3 is not set # CONFIG_FB_SAVAGE is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_VT8623 is not set # CONFIG_FB_CYBLA is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_ARK is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_GEODE is not set # CONFIG_FB_VIRTUAL is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_VGACON_SOFT_SCROLLBACK=y CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64 CONFIG_VIDEO_SELECT=y CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=m # CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # CONFIG_LOGO is not set # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_PCM_OSS_PLUGINS=y CONFIG_SND_SEQUENCER_OSS=y # CONFIG_SND_DYNAMIC_MINORS is not set CONFIG_SND_SUPPORT_OLD_API=y # CONFIG_SND_VERBOSE_PROCFS is not set # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # CONFIG_SND_AC97_CODEC=m # CONFIG_SND_DUMMY is not set # CONFIG_SND_VIRMIDI is not set # CONFIG_SND_MTPAV is not set # CONFIG_SND_SERIAL_U16550 is not set # CONFIG_SND_MPU401 is not set # # PCI devices # CONFIG_SND_AD1889=m # CONFIG_SND_ALS300 is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_ATIIXP_MODEM is not set # CONFIG_SND_AU8810 is not set # CONFIG_SND_AU8820 is not set # CONFIG_SND_AU8830 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_BT87X is not set # CONFIG_SND_CA0106 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_CS4281 is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS5530 is not set # CONFIG_SND_CS5535AUDIO is not set # CONFIG_SND_DARLA20 is not set # CONFIG_SND_GINA20 is not set # CONFIG_SND_LAYLA20 is not set # CONFIG_SND_DARLA24 is not set # CONFIG_SND_GINA24 is not set # CONFIG_SND_LAYLA24 is not set # CONFIG_SND_MONA is not set # CONFIG_SND_MIA is not set # CONFIG_SND_ECHO3G is not set # CONFIG_SND_INDIGO is not set # CONFIG_SND_INDIGOIO is not set # CONFIG_SND_INDIGODJ is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_EMU10K1X is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_FM801 is not set CONFIG_SND_HDA_INTEL=m # CONFIG_SND_HDSP is not set # CONFIG_SND_HDSPM is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set CONFIG_SND_INTEL8X0=m CONFIG_SND_INTEL8X0M=m # CONFIG_SND_KORG1212 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_MIXART is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_PCXHR is not set # CONFIG_SND_RIPTIDE is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_SONICVIBES is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_VIA82XX is not set # CONFIG_SND_VIA82XX_MODEM is not set # CONFIG_SND_VX222 is not set # CONFIG_SND_YMFPCI is not set CONFIG_SND_AC97_POWER_SAVE=y # # USB devices # CONFIG_SND_USB_AUDIO=m CONFIG_SND_USB_USX2Y=m CONFIG_SND_USB_CAIAQ=m # CONFIG_SND_USB_CAIAQ_INPUT is not set # # System on Chip audio support # # CONFIG_SND_SOC is not set # # SoC Audio support for SuperH # # # Open Sound System # CONFIG_SOUND_PRIME=m # CONFIG_SOUND_TRIDENT is not set # CONFIG_SOUND_MSNDCLAS is not set # CONFIG_SOUND_MSNDPIN is not set CONFIG_SOUND_OSS=m # CONFIG_SOUND_TRACEINIT is not set # CONFIG_SOUND_DMAP is not set # CONFIG_SOUND_SSCAPE is not set CONFIG_SOUND_VMIDI=m # CONFIG_SOUND_TRIX is not set CONFIG_SOUND_MSS=m CONFIG_SOUND_MPU401=m # CONFIG_SOUND_PAS is not set # CONFIG_SOUND_PSS is not set CONFIG_SOUND_SB=m # CONFIG_SOUND_YM3812 is not set CONFIG_SOUND_UART6850=m # CONFIG_SOUND_AEDSP16 is not set # CONFIG_SOUND_KAHLUA is not set CONFIG_AC97_BUS=m CONFIG_HID_SUPPORT=y CONFIG_HID=m # CONFIG_HID_DEBUG is not set # # USB Input Devices # CONFIG_USB_HID=m # CONFIG_USB_HIDINPUT_POWERBOOK is not set # CONFIG_HID_FF is not set CONFIG_USB_HIDDEV=y # # USB HID Boot Protocol drivers # # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set CONFIG_USB_SUPPORT=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB=m # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y CONFIG_USB_DEVICE_CLASS=y # CONFIG_USB_DYNAMIC_MINORS is not set CONFIG_USB_SUSPEND=y CONFIG_USB_PERSIST=y # CONFIG_USB_OTG is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=m CONFIG_USB_EHCI_SPLIT_ISO=y CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_EHCI_TT_NEWSCHED=y # CONFIG_USB_ISP116X_HCD is not set CONFIG_USB_OHCI_HCD=m # CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set # CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_UHCI_HCD=m # CONFIG_USB_U132_HCD is not set CONFIG_USB_SL811_HCD=m # CONFIG_USB_R8A66597_HCD is not set # # USB Device Class drivers # CONFIG_USB_ACM=m CONFIG_USB_PRINTER=m # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' # # # may also be needed; see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set CONFIG_USB_STORAGE_DATAFAB=y CONFIG_USB_STORAGE_FREECOM=y CONFIG_USB_STORAGE_ISD200=y CONFIG_USB_STORAGE_DPCM=y CONFIG_USB_STORAGE_USBAT=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y CONFIG_USB_STORAGE_ALAUDA=y # CONFIG_USB_STORAGE_KARMA is not set CONFIG_USB_LIBUSUAL=y # # USB Imaging devices # CONFIG_USB_MDC800=m CONFIG_USB_MICROTEK=m CONFIG_USB_MON=y # # USB port drivers # # # USB Serial Converter support # CONFIG_USB_SERIAL=m CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_AIRCABLE=m CONFIG_USB_SERIAL_AIRPRIME=m CONFIG_USB_SERIAL_ARK3116=m CONFIG_USB_SERIAL_BELKIN=m CONFIG_USB_SERIAL_WHITEHEAT=m CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m CONFIG_USB_SERIAL_CP2101=m CONFIG_USB_SERIAL_CYPRESS_M8=m CONFIG_USB_SERIAL_EMPEG=m CONFIG_USB_SERIAL_FTDI_SIO=m CONFIG_USB_SERIAL_FUNSOFT=m CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_IPAQ=m CONFIG_USB_SERIAL_IR=m CONFIG_USB_SERIAL_EDGEPORT=m CONFIG_USB_SERIAL_EDGEPORT_TI=m CONFIG_USB_SERIAL_GARMIN=m CONFIG_USB_SERIAL_IPW=m CONFIG_USB_SERIAL_KEYSPAN_PDA=m CONFIG_USB_SERIAL_KEYSPAN=m CONFIG_USB_SERIAL_KEYSPAN_MPR=y CONFIG_USB_SERIAL_KEYSPAN_USA28=y CONFIG_USB_SERIAL_KEYSPAN_USA28X=y CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y CONFIG_USB_SERIAL_KEYSPAN_USA19=y CONFIG_USB_SERIAL_KEYSPAN_USA18X=y CONFIG_USB_SERIAL_KEYSPAN_USA19W=y CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y CONFIG_USB_SERIAL_KEYSPAN_USA49W=y CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y CONFIG_USB_SERIAL_KLSI=m CONFIG_USB_SERIAL_KOBIL_SCT=m CONFIG_USB_SERIAL_MCT_U232=m CONFIG_USB_SERIAL_MOS7720=m CONFIG_USB_SERIAL_MOS7840=m CONFIG_USB_SERIAL_NAVMAN=m CONFIG_USB_SERIAL_PL2303=m CONFIG_USB_SERIAL_OTI6858=m # CONFIG_USB_SERIAL_HP4X is not set CONFIG_USB_SERIAL_SAFE=m CONFIG_USB_SERIAL_SAFE_PADDED=y CONFIG_USB_SERIAL_SIERRAWIRELESS=m CONFIG_USB_SERIAL_TI=m CONFIG_USB_SERIAL_CYBERJACK=m CONFIG_USB_SERIAL_XIRCOM=m CONFIG_USB_SERIAL_OPTION=m CONFIG_USB_SERIAL_OMNINET=m # CONFIG_USB_SERIAL_DEBUG is not set CONFIG_USB_EZUSB=y # # USB Miscellaneous drivers # CONFIG_USB_EMI62=m CONFIG_USB_EMI26=m CONFIG_USB_ADUTUX=m CONFIG_USB_AUERSWALD=m CONFIG_USB_RIO500=m CONFIG_USB_LEGOTOWER=m CONFIG_USB_LCD=m # CONFIG_USB_BERRY_CHARGE is not set CONFIG_USB_LED=m CONFIG_USB_CYPRESS_CY7C63=m CONFIG_USB_CYTHERM=m # CONFIG_USB_PHIDGET is not set CONFIG_USB_IDMOUSE=m CONFIG_USB_FTDI_ELAN=m # CONFIG_USB_APPLEDISPLAY is not set CONFIG_USB_SISUSBVGA=m # CONFIG_USB_SISUSBVGA_CON is not set CONFIG_USB_LD=m # CONFIG_USB_TRANCEVIBRATOR is not set # CONFIG_USB_IOWARRIOR is not set CONFIG_USB_TEST=m # # USB DSL modem support # # # USB Gadget Support # # CONFIG_USB_GADGET is not set CONFIG_MMC=m # CONFIG_MMC_DEBUG is not set # CONFIG_MMC_UNSAFE_RESUME is not set # # MMC/SD Card Drivers # CONFIG_MMC_BLOCK=m CONFIG_MMC_BLOCK_BOUNCE=y # # MMC/SD Host Controller Drivers # CONFIG_MMC_SDHCI=m # CONFIG_MMC_WBSD is not set CONFIG_MMC_TIFM_SD=m # CONFIG_NEW_LEDS is not set # CONFIG_INFINIBAND is not set # CONFIG_EDAC is not set CONFIG_RTC_LIB=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE="rtc0" # CONFIG_RTC_DEBUG is not set # # RTC interfaces # CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y # CONFIG_RTC_INTF_DEV_UIE_EMUL is not set CONFIG_RTC_DRV_TEST=m # # I2C RTC drivers # CONFIG_RTC_DRV_DS1307=m CONFIG_RTC_DRV_DS1672=m CONFIG_RTC_DRV_MAX6900=m CONFIG_RTC_DRV_RS5C372=m CONFIG_RTC_DRV_ISL1208=m CONFIG_RTC_DRV_X1205=m CONFIG_RTC_DRV_PCF8563=m CONFIG_RTC_DRV_PCF8583=m # CONFIG_RTC_DRV_M41T80 is not set # # SPI RTC drivers # # # Platform RTC drivers # CONFIG_RTC_DRV_CMOS=y CONFIG_RTC_DRV_DS1553=m # CONFIG_RTC_DRV_STK17TA8 is not set CONFIG_RTC_DRV_DS1742=m CONFIG_RTC_DRV_M48T86=m # CONFIG_RTC_DRV_M48T59 is not set CONFIG_RTC_DRV_V3020=m # # on-CPU RTC drivers # # # DMA Engine support # CONFIG_DMA_ENGINE=y # # DMA Clients # CONFIG_NET_DMA=y # # DMA Devices # CONFIG_INTEL_IOATDMA=m # CONFIG_VIRTUALIZATION is not set # # Userspace I/O # CONFIG_UIO=m # CONFIG_UIO_CIF is not set # # File systems # CONFIG_EXT2_FS=m # CONFIG_EXT2_FS_XATTR is not set CONFIG_EXT2_FS_XIP=y CONFIG_FS_XIP=y CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set # CONFIG_EXT4DEV_FS is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set CONFIG_FS_POSIX_ACL=y # CONFIG_XFS_FS is not set # CONFIG_GFS2_FS is not set # CONFIG_OCFS2_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_ROMFS_FS is not set CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y # CONFIG_QUOTA is not set CONFIG_DNOTIFY=y # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set CONFIG_FUSE_FS=m # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=m CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_UDF_FS=m CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" CONFIG_NTFS_FS=m # CONFIG_NTFS_DEBUG is not set CONFIG_NTFS_RW=y # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_SYSCTL=y CONFIG_SYSFS=y CONFIG_TMPFS=y # CONFIG_TMPFS_POSIX_ACL is not set # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y CONFIG_CONFIGFS_FS=m # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set CONFIG_HFS_FS=m CONFIG_HFSPLUS_FS=m # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # # Network File Systems # CONFIG_NFS_FS=m CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y CONFIG_NFS_DIRECTIO=y CONFIG_NFSD=m CONFIG_NFSD_V2_ACL=y CONFIG_NFSD_V3=y CONFIG_NFSD_V3_ACL=y CONFIG_NFSD_V4=y CONFIG_NFSD_TCP=y CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_NFS_ACL_SUPPORT=m CONFIG_NFS_COMMON=y CONFIG_SUNRPC=m CONFIG_SUNRPC_GSS=m CONFIG_SUNRPC_BIND34=y CONFIG_RPCSEC_GSS_KRB5=m # CONFIG_RPCSEC_GSS_SPKM3 is not set CONFIG_SMB_FS=m CONFIG_SMB_NLS_DEFAULT=y CONFIG_SMB_NLS_REMOTE="cp437" CONFIG_CIFS=m # CONFIG_CIFS_STATS is not set CONFIG_CIFS_WEAK_PW_HASH=y # CONFIG_CIFS_XATTR is not set # CONFIG_CIFS_DEBUG2 is not set # CONFIG_CIFS_EXPERIMENTAL is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set CONFIG_MAC_PARTITION=y CONFIG_MSDOS_PARTITION=y # CONFIG_BSD_DISKLABEL is not set # CONFIG_MINIX_SUBPARTITION is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set CONFIG_LDM_PARTITION=y # CONFIG_LDM_DEBUG is not set # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set # CONFIG_KARMA_PARTITION is not set # CONFIG_EFI_PARTITION is not set # CONFIG_SYSV68_PARTITION is not set # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="cp437" CONFIG_NLS_CODEPAGE_437=m # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set CONFIG_NLS_CODEPAGE_850=m # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set CONFIG_NLS_CODEPAGE_863=m # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ASCII=m CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_UTF8=m # # Distributed Lock Manager # CONFIG_DLM=m # CONFIG_DLM_DEBUG is not set # CONFIG_INSTRUMENTATION is not set # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_PRINTK_TIME=y # CONFIG_ENABLE_MUST_CHECK is not set CONFIG_MAGIC_SYSRQ=y # CONFIG_UNUSED_SYMBOLS is not set # CONFIG_DEBUG_FS is not set # CONFIG_HEADERS_CHECK is not set CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_SHIRQ is not set CONFIG_DETECT_SOFTLOCKUP=y # CONFIG_SCHED_DEBUG is not set # CONFIG_SCHEDSTATS is not set # CONFIG_TIMER_STATS is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_PREEMPT is not set # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_RT_MUTEX_TESTER is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_MUTEXES is not set # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set # CONFIG_LOCK_STAT is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_HIGHMEM is not set CONFIG_DEBUG_BUGVERBOSE=y # CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_LIST is not set # CONFIG_FRAME_POINTER is not set # CONFIG_FORCED_INLINING is not set # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_FAULT_INJECTION is not set # CONFIG_EARLY_PRINTK is not set # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_STACK_USAGE is not set # # Page alloc debug is incompatible with Software Suspend on i386 # # CONFIG_DEBUG_RODATA is not set CONFIG_4KSTACKS=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y CONFIG_DOUBLEFAULT=y # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set CONFIG_CRYPTO=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ABLKCIPHER=m CONFIG_CRYPTO_BLKCIPHER=m CONFIG_CRYPTO_HASH=m CONFIG_CRYPTO_MANAGER=m CONFIG_CRYPTO_HMAC=m CONFIG_CRYPTO_XCBC=m CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=y CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_GF128MUL=m CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_CBC=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_LRW=m CONFIG_CRYPTO_CRYPTD=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH_586=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_AES_586=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_CRC32C=m CONFIG_CRYPTO_CAMELLIA=m # CONFIG_CRYPTO_TEST is not set # CONFIG_CRYPTO_HW is not set # # Library routines # CONFIG_BITREVERSE=m CONFIG_CRC_CCITT=m CONFIG_CRC16=m CONFIG_CRC_ITU_T=m CONFIG_CRC32=m CONFIG_CRC7=m CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=m CONFIG_TEXTSEARCH_BM=m CONFIG_TEXTSEARCH_FSM=m CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_KTIME_SCALAR=y ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-15 16:32 ` [BUG] Strange 1-second pauses during Resume-from-RAM Mark Lord 2007-11-15 16:49 ` Ray Lee @ 2007-11-15 18:14 ` Pavel Machek 2007-11-15 17:31 ` Mark Lord 2007-11-18 16:10 ` Mark Lord 2 siblings, 1 reply; 268+ messages in thread From: Pavel Machek @ 2007-11-15 18:14 UTC (permalink / raw) To: Mark Lord Cc: Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw Hi! > I have been reporting this off and on since 2.6.23 was released. > This problem was not apparent up to perhaps 2.6.23-rc8, > but definitely became common in 2.6.23 and 2.6.23.1. > > Most of the time, a resume-from-RAM on my notebook takes about 2.1 seconds > of kernel time to complete. > > Once in a while, it takes *much* longer, in the 14-20 second range. > These long events *seem* to be mostly after the notebook has been > in suspend for a longish time, but there's really nothing consistent here. > > So git-bisect isn't going to work for this one. I recently rebuilt the > kernel > to include printk timestamps, and then it went 2 days without the issue > happening, > until this morning (after an overnight suspend) finally. > > The machine is a Dell Inspiron 9400, Intel chipset + Core2Duo 2.1GHZ w/3GB > DDR2. > PCIe express chipset, ATI graphics, SATA hard drive. > > 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT > Express Memory Controller Hub (rev 03) > 00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT > Express PCI Express Root Port (rev 03) > 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High > Definition Audio Controller (rev 01) > 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port > 1 (rev 01) > 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port > 2 (rev 01) > 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port > 4 (rev 01) > 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 > (rev 01) > 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 > (rev 01) > 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 > (rev 01) > 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 > (rev 01) > 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI > Controller (rev 01) > 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1) > 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface > Bridge (rev 01) > 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial > ATA Storage Controller IDE (rev 01) > 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev > 01) > 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility > X1400 > 03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX > (rev 02) > 03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd Unknown device 0832 > 03:01.1 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 > SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19) > 03:01.2 System peripheral: Ricoh Co Ltd Unknown device 0843 (rev 01) > 03:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host > Adapter (rev 0a) > 03:01.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 05) > 0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network > Connection (rev 02) > > There's also a USB2 hub connected, with the Logitech mouse being the > only thing plugged into it at present. > > The best clue I have of what is happening, other than that it was first > seen during the late 2.6.23-rc* series, are the following two sets of > kernel logs. The first set is from a "normal" fast wake-up, > and the second set is from the "slow" wake-up seen this morning. > > Both logs show the same information, in pretty much the same order. > The BIG difference is a bunch of unexplained pauses of exactly 1-second > each that occur during the slow wakeup. > > The only other difference is that the SATA disk messages are placed > differently within the two logs. I'm thinking on that one but it > doesn't look significant to me. > > The real question is, why the 1-sec pauses? Can you try nohz=off highres=off? Strange stuff is happening with nohz. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-15 18:14 ` Pavel Machek @ 2007-11-15 17:31 ` Mark Lord 2007-11-15 19:34 ` Ingo Molnar 2007-11-15 20:27 ` Rafael J. Wysocki 0 siblings, 2 replies; 268+ messages in thread From: Mark Lord @ 2007-11-15 17:31 UTC (permalink / raw) To: Pavel Machek Cc: Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw, Ingo Molnar > Hi! > >> > I have been reporting this off and on since 2.6.23 was released. >> > This problem was not apparent up to perhaps 2.6.23-rc8, >> > but definitely became common in 2.6.23 and 2.6.23.1. >> > >> > Most of the time, a resume-from-RAM on my notebook takes about 2.1 seconds >> > of kernel time to complete. >> > >> > Once in a while, it takes *much* longer, in the 14-20 second range. >> > These long events *seem* to be mostly after the notebook has been >> > in suspend for a longish time, but there's really nothing consistent here. >> > >> > So git-bisect isn't going to work for this one. I recently rebuilt the >> > kernel >> > to include printk timestamps, and then it went 2 days without the issue >> > happening, >> > until this morning (after an overnight suspend) finally. >> > >> > The machine is a Dell Inspiron 9400, Intel chipset + Core2Duo 2.1GHZ w/3GB >> > DDR2. >> > PCIe express chipset, ATI graphics, SATA hard drive. >> > >> > 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT >> > Express Memory Controller Hub (rev 03) >> > 00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT >> > Express PCI Express Root Port (rev 03) >> > 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High >> > Definition Audio Controller (rev 01) >> > 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port >> > 1 (rev 01) >> > 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port >> > 2 (rev 01) >> > 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port >> > 4 (rev 01) >> > 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 >> > (rev 01) >> > 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 >> > (rev 01) >> > 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 >> > (rev 01) >> > 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 >> > (rev 01) >> > 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI >> > Controller (rev 01) >> > 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1) >> > 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface >> > Bridge (rev 01) >> > 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial >> > ATA Storage Controller IDE (rev 01) >> > 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev >> > 01) >> > 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility >> > X1400 >> > 03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX >> > (rev 02) >> > 03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd Unknown device 0832 >> > 03:01.1 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 >> > SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19) >> > 03:01.2 System peripheral: Ricoh Co Ltd Unknown device 0843 (rev 01) >> > 03:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host >> > Adapter (rev 0a) >> > 03:01.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 05) >> > 0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network >> > Connection (rev 02) >> > >> > There's also a USB2 hub connected, with the Logitech mouse being the >> > only thing plugged into it at present. >> > >> > The best clue I have of what is happening, other than that it was first >> > seen during the late 2.6.23-rc* series, are the following two sets of >> > kernel logs. The first set is from a "normal" fast wake-up, >> > and the second set is from the "slow" wake-up seen this morning. >> > >> > Both logs show the same information, in pretty much the same order. >> > The BIG difference is a bunch of unexplained pauses of exactly 1-second >> > each that occur during the slow wakeup. >> > >> > The only other difference is that the SATA disk messages are placed >> > differently within the two logs. I'm thinking on that one but it >> > doesn't look significant to me. >> > >> > The real question is, why the 1-sec pauses? > > Can you try nohz=off highres=off? Strange stuff is happening with > nohz. .. (added Ingo to CC: list: maybe this is some weird interaction with CFS and jiffies being reset to 0 on resume ??) I can try it, but it won't help debug the problem much. Remember, this happens very inconsistently, maybe 3-4 times a day, or not at all for 3-4 days. But if somebody has a specific bug-fix patch that could explain this, then I'll happily apply it here. Cheers ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-15 17:31 ` Mark Lord @ 2007-11-15 19:34 ` Ingo Molnar 2007-11-15 19:36 ` Ingo Molnar 2007-11-15 20:27 ` Rafael J. Wysocki 1 sibling, 1 reply; 268+ messages in thread From: Ingo Molnar @ 2007-11-15 19:34 UTC (permalink / raw) To: Mark Lord Cc: Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw * Mark Lord <lkml@rtr.ca> wrote: >> Can you try nohz=off highres=off? Strange stuff is happening with >> nohz. > > (added Ingo to CC: list: maybe this is some weird interaction with CFS > and jiffies being reset to 0 on resume ??) hm, CFS should have no impact here. To see what's happening you could try to use the latency tracer of the -rt patch and do a cross-resume trace. pick up the latest latency tracer patch from: http://redhat.com/~mingo/private/latency-tracer-v2.6.24-rc2-git5-combo.patch apply it and enable CONFIG_FUNCTION_TRACING, then pick up trace-cmd.c: http://redhat.com/~mingo/private/trace-cmd.c and do something like: ./trace-cmd pm-suspend > trace.txt or: ./trace-cmd /bin/bash -c "echo ram > /sys/power/state" > trace.txt this should trigger suspend - then you should do the resume. If everything goes well then trace.txt should contain a pretty large trace of all the stuff we do during a suspend+resume. and wait for such a pause and send us the resulting trace.txt. if it's an SMP box then first do: echo 1 > /proc/sys/kernel/trace_all_cpus to get a global trace. Let me know if something doesnt work with this scheme. Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-15 19:34 ` Ingo Molnar @ 2007-11-15 19:36 ` Ingo Molnar 2007-11-15 22:23 ` Mark Lord 2007-11-30 12:56 ` Jörn Engel 0 siblings, 2 replies; 268+ messages in thread From: Ingo Molnar @ 2007-11-15 19:36 UTC (permalink / raw) To: Mark Lord Cc: Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw * Ingo Molnar <mingo@elte.hu> wrote: > pick up the latest latency tracer patch from: sorry, wrong URLs, the correct links are: http://redhat.com/~mingo/latency-tracing-patches/latency-tracer-v2.6.24-rc2-git5-combo.patch http://redhat.com/~mingo/latency-tracing-patches/trace-cmd.c Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-15 19:36 ` Ingo Molnar @ 2007-11-15 22:23 ` Mark Lord 2007-11-16 5:55 ` Ingo Molnar ` (2 more replies) 2007-11-30 12:56 ` Jörn Engel 1 sibling, 3 replies; 268+ messages in thread From: Mark Lord @ 2007-11-15 22:23 UTC (permalink / raw) To: Ingo Molnar Cc: Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw Ingo Molnar wrote: > * Ingo Molnar <mingo@elte.hu> wrote: > >> pick up the latest latency tracer patch from: > > sorry, wrong URLs, the correct links are: > > http://redhat.com/~mingo/latency-tracing-patches/latency-tracer-v2.6.24-rc2-git5-combo.patch > http://redhat.com/~mingo/latency-tracing-patches/trace-cmd.c .. Is there a version of these that works with 2.6.23.1 ? I'm not using 2.6.24-* on this machine because: (a) behaviour may be different, and (b) something broke VMware compatibility again. Thanks ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-15 22:23 ` Mark Lord @ 2007-11-16 5:55 ` Ingo Molnar 2007-11-16 7:15 ` Ingo Molnar 2007-11-16 18:35 ` Mark Lord 2007-11-30 20:12 ` Mark Lord 2 siblings, 1 reply; 268+ messages in thread From: Ingo Molnar @ 2007-11-16 5:55 UTC (permalink / raw) To: Mark Lord Cc: Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw * Mark Lord <lkml@rtr.ca> wrote: >> sorry, wrong URLs, the correct links are: >> >> http://redhat.com/~mingo/latency-tracing-patches/latency-tracer-v2.6.24-rc2-git5-combo.patch >> http://redhat.com/~mingo/latency-tracing-patches/trace-cmd.c > .. > > Is there a version of these that works with 2.6.23.1 ? yes, i've backported it and have uploaded the v2.6.23 version to: http://redhat.com/~mingo/latency-tracing-patches/latency-tracer-v2.6.23.1-combo.patch Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-16 5:55 ` Ingo Molnar @ 2007-11-16 7:15 ` Ingo Molnar 2007-11-16 8:21 ` Ingo Molnar 2007-11-16 19:06 ` [BUG] Strange 1-second pauses during Resume-from-RAM Mark Lord 0 siblings, 2 replies; 268+ messages in thread From: Ingo Molnar @ 2007-11-16 7:15 UTC (permalink / raw) To: Mark Lord Cc: Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw * Ingo Molnar <mingo@elte.hu> wrote: > > Is there a version of these that works with 2.6.23.1 ? > > yes, i've backported it and have uploaded the v2.6.23 version to: > > http://redhat.com/~mingo/latency-tracing-patches/latency-tracer-v2.6.23.1-combo.patch btw., if the trace is too large and the interesting section of suspend does not fit into it then you can narrow it down to the most important events only by changing this in trace-cmd.c: system("echo 1 > /proc/sys/kernel/mcount_enabled"); to: system("echo 0 > /proc/sys/kernel/mcount_enabled"); that way we'll still trace IRQs and scheduling events, which is enough to see roughly where the delay is happening. To include symbolic backtraces in the trace, do this: echo 1 > /proc/sys/kernel/stackframe_tracing to get such trace entries: ls 3688 1D..3 4642us+: deactivate_task <ls 3688> (0 0) ls 3688 1D..3 4644us+: schedule()<-do_exit()<-sys_exit_group()<-sys_exit_group() ls 3688 1D..3 4647us+: sysenter_past_esp()<-( -1)()<-( 0)()<-( 0)() <idle> 0 1D..2 4652us : schedule <ls 3688> (0 20) this way we can see why a task goes to sleep and which exact kernel codepath is waking it up. Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-16 7:15 ` Ingo Molnar @ 2007-11-16 8:21 ` Ingo Molnar 2007-11-16 11:23 ` Ingo Molnar 2007-11-16 19:06 ` [BUG] Strange 1-second pauses during Resume-from-RAM Mark Lord 1 sibling, 1 reply; 268+ messages in thread From: Ingo Molnar @ 2007-11-16 8:21 UTC (permalink / raw) To: Mark Lord Cc: Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw ok, i experimented around with the latency tracer, trying to capture the trace of a full suspend+resume cycle, and it needed the tracer fix below (GTOD clocksource suspend/resume would otherwise confuse the tracer and you'd get no trace output as a result). once that tracer bug was fixed, the best method to generate a trace was to do this: echo 1 > /proc/sys/kernel/stackframe_tracing echo 1 > /proc/sys/kernel/syscall_tracing ./trace-cmd bash -c "echo mem > /sys/power/state" > trace.txt Ingo --- kernel/latency_trace.c | 53 +++++++++++++++++++++++++++++++++---------------- 1 file changed, 36 insertions(+), 17 deletions(-) Index: linux/kernel/latency_trace.c =================================================================== --- linux.orig/kernel/latency_trace.c +++ linux/kernel/latency_trace.c @@ -67,13 +67,6 @@ static unsigned long notrace cycles_to_u } #endif -static notrace inline cycle_t now(void) -{ - if (trace_use_raw_cycles) - return get_cycles(); - return get_monotonic_cycles(); -} - #ifndef irqs_off # define irqs_off() 0 #endif @@ -237,6 +230,8 @@ struct cpu_trace { unsigned long critical_sequence; atomic_t underrun; atomic_t overrun; + cycle_t cycles; + cycle_t last_cycles; int early_warning; int latency_type; int cpu; @@ -263,6 +258,30 @@ static struct cpu_trace cpu_traces[NR_CP #endif } }; +static notrace cycle_t now(struct cpu_trace *tr, int monotonic) +{ + cycles_t now, delta, last = tr->last_cycles; + + if (trace_use_raw_cycles && !monotonic) + now = get_cycles(); + else + now = get_monotonic_cycles(); + + /* + * Protect against time warps: + */ + if (unlikely(now < last)) + delta = 1; + else + delta = now - last; + + tr->last_cycles = now; + tr->cycles += delta; + + return tr->cycles; +} + + #ifdef CONFIG_EVENT_TRACE int trace_enabled = 0; @@ -615,7 +634,7 @@ ____trace(int cpu, enum trace_type type, again: idx = tr->trace_idx; idx_next = idx + 1; - timestamp = now(); + timestamp = now(tr, 0); if (unlikely((trace_freerunning || print_functions || atomic_read(&tr->underrun)) && (idx_next >= MAX_TRACE) && !atomic_read(&tr->overrun))) { @@ -1743,7 +1762,7 @@ check_critical_timing(int cpu, struct cp * as long as possible: */ T0 = tr->preempt_timestamp; - T1 = get_monotonic_cycles(); + T1 = now(tr, 1); delta = T1-T0; local_save_flags(flags); @@ -1757,7 +1776,7 @@ check_critical_timing(int cpu, struct cp * might change it (it can only get larger so the latency * is fair to be reported): */ - T2 = get_monotonic_cycles(); + T2 = now(tr, 1); delta = T2-T0; @@ -1807,7 +1826,7 @@ check_critical_timing(int cpu, struct cp printk(" => ended at timestamp %lu: ", t1); print_symbol("<%s>\n", tr->critical_end); dump_stack(); - t1 = cycles_to_usecs(get_monotonic_cycles()); + t1 = cycles_to_usecs(now(tr, 1)); printk(" => dump-end timestamp %lu\n\n", t1); #endif @@ -1817,7 +1836,7 @@ check_critical_timing(int cpu, struct cp out: tr->critical_sequence = max_sequence; - tr->preempt_timestamp = get_monotonic_cycles(); + tr->preempt_timestamp = now(tr, 1); tr->early_warning = 0; reset_trace_idx(cpu, tr); _trace_cmdline(cpu, tr); @@ -1866,7 +1885,7 @@ __start_critical_timing(unsigned long ei atomic_inc(&tr->disabled); tr->critical_sequence = max_sequence; - tr->preempt_timestamp = get_monotonic_cycles(); + tr->preempt_timestamp = now(tr, 1); tr->critical_start = eip; reset_trace_idx(cpu, tr); tr->latency_type = latency_type; @@ -2150,7 +2169,7 @@ check_wakeup_timing(struct cpu_trace *tr goto out; T0 = tr->preempt_timestamp; - T1 = get_monotonic_cycles(); + T1 = now(tr, 1); /* * Any wraparound or time warp and we are out: */ @@ -2255,7 +2274,7 @@ void __trace_start_sched_wakeup(struct t // if (!atomic_read(&tr->disabled)) { atomic_inc(&tr->disabled); tr->critical_sequence = max_sequence; - tr->preempt_timestamp = get_monotonic_cycles(); + tr->preempt_timestamp = now(tr, 1); tr->latency_type = WAKEUP_LATENCY; tr->critical_start = CALLER_ADDR0; _trace_cmdline(raw_smp_processor_id(), tr); @@ -2366,7 +2385,7 @@ long user_trace_start(void) reset_trace_idx(cpu, tr); tr->critical_sequence = max_sequence; - tr->preempt_timestamp = get_monotonic_cycles(); + tr->preempt_timestamp = now(tr, 1); tr->critical_start = CALLER_ADDR0; _trace_cmdline(cpu, tr); mcount(); @@ -2425,7 +2444,7 @@ long user_trace_stop(void) unsigned long long tmp0; T0 = tr->preempt_timestamp; - T1 = get_monotonic_cycles(); + T1 = now(tr, 1); tmp0 = preempt_max_latency; if (T1 < T0) T0 = T1; ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-16 8:21 ` Ingo Molnar @ 2007-11-16 11:23 ` Ingo Molnar 2007-11-16 11:53 ` Mike Galbraith 2007-11-16 12:43 ` Ingo Molnar 0 siblings, 2 replies; 268+ messages in thread From: Ingo Molnar @ 2007-11-16 11:23 UTC (permalink / raw) To: Mark Lord Cc: Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw, Len Brown * Ingo Molnar <mingo@elte.hu> wrote: > once that tracer bug was fixed, the best method to generate a trace > was to do this: > > echo 1 > /proc/sys/kernel/stackframe_tracing > echo 1 > /proc/sys/kernel/syscall_tracing > ./trace-cmd bash -c "echo mem > /sys/power/state" > trace.txt so here's an UP suspend+resume trace i did: http://redhat.com/~mingo/latency-tracing-patches/misc/trace-suspend-long.txt.bz2 tons of detail - which might be interesting to other folks as well. Fact is, our suspend-to-RAM+resume cycle is very, very slow, even on fast hardware - and this trace shows all the reasons why. This was a fully cached system - i.e. i've done a suspend+resume before to warm up the caches. (not that suspend+resume does much IO normally.) The trace shows that a suspend+resume cycle is 7.95 seconds long (without counting the time the box spent suspended) - ouch! This was a T60 with Core2Duo 1.83GHz. For example here is where freezing starts: bash-2397 0.... 31686us : remove_wait_queue (vt_waitactive) bash-2397 0.... 31688us : freeze_processes (enter_state) bash-2397 0.... 31689us : printk (freeze_processes) here is where the ACPI code triggers the suspend: bash-2397 0D... 1904138us : acpi_hw_low_level_write (acpi_hw_register_write) but this is a whopping 1.9 seconds into the trace already! first sign of life after i opened the laptop lid again: bash-2397 0D... 1904138us : __restore_processor_state (restore_processor_state) bash-2397 0D... 1904138us : enable_sep_cpu (__restore_processor_state) (in the trace there's no delay visible - the period of time spent suspended is not visible to the tracer.) One good way to start looking at such traces is to filter out rescheduling events alone: grep ': schedule <' trace-suspend-long.txt that gives a rough outline of what's going on: <idle>-0 0D... 1776566us : schedule <bash-2397> (0 20) bash-2397 0D... 1786748us : schedule <<idle>-0> (20 0) scsi_eh_-419 0D... 1786814us : schedule <bash-2397> (0 -5) bash-2397 0D... 1786960us : schedule <scsi_eh_-419> (-5 0) scsi_eh_-421 0D... 1787020us : schedule <bash-2397> (0 -5) bash-2397 0D... 1787125us : schedule <scsi_eh_-421> (-5 0) so you can zoom in on the real area of interest by searching for the timestamp. Hope this helps, Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-16 11:23 ` Ingo Molnar @ 2007-11-16 11:53 ` Mike Galbraith 2007-11-16 12:43 ` Ingo Molnar 1 sibling, 0 replies; 268+ messages in thread From: Mike Galbraith @ 2007-11-16 11:53 UTC (permalink / raw) To: Ingo Molnar Cc: Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw, Len Brown On Fri, 2007-11-16 at 12:23 +0100, Ingo Molnar wrote: > * Ingo Molnar <mingo@elte.hu> wrote: > > > once that tracer bug was fixed, the best method to generate a trace > > was to do this: > > > > echo 1 > /proc/sys/kernel/stackframe_tracing > > echo 1 > /proc/sys/kernel/syscall_tracing > > ./trace-cmd bash -c "echo mem > /sys/power/state" > trace.txt > > so here's an UP suspend+resume trace i did: > > http://redhat.com/~mingo/latency-tracing-patches/misc/trace-suspend-long.txt.bz2 > > tons of detail - which might be interesting to other folks as well. Fact > is, our suspend-to-RAM+resume cycle is very, very slow, even on fast > hardware - and this trace shows all the reasons why. > > This was a fully cached system - i.e. i've done a suspend+resume before > to warm up the caches. (not that suspend+resume does much IO normally.) > > The trace shows that a suspend+resume cycle is 7.95 seconds long > (without counting the time the box spent suspended) - ouch! This was a > T60 with Core2Duo 1.83GHz. Ouch? That's an order of magnitude faster than my 3GHz P4 :) -Mike ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-16 11:23 ` Ingo Molnar 2007-11-16 11:53 ` Mike Galbraith @ 2007-11-16 12:43 ` Ingo Molnar 2007-11-16 12:58 ` [patch] snd hda suspend latency: shorten codec read Ingo Molnar 1 sibling, 1 reply; 268+ messages in thread From: Ingo Molnar @ 2007-11-16 12:43 UTC (permalink / raw) To: Mark Lord Cc: Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw, Len Brown * Ingo Molnar <mingo@elte.hu> wrote: > so here's an UP suspend+resume trace i did: > > http://redhat.com/~mingo/latency-tracing-patches/misc/trace-suspend-long.txt.bz2 > > tons of detail - which might be interesting to other folks as well. > Fact is, our suspend-to-RAM+resume cycle is very, very slow, even on > fast hardware - and this trace shows all the reasons why. > > This was a fully cached system - i.e. i've done a suspend+resume > before to warm up the caches. (not that suspend+resume does much IO > normally.) > > The trace shows that a suspend+resume cycle is 7.95 seconds long > (without counting the time the box spent suspended) - ouch! This was a > T60 with Core2Duo 1.83GHz. and the amount of time spent executing on the CPU was only 70 msecs! So we spent 99% of that 7.9 seconds with just waiting around. Here are the top 10 sleep reasons: 864 schedule()<-schedule_timeout()<-ps2_sendbyte()<-ps2_command() 183 schedule()<-vt_waitactive()<-vt_ioctl()<-tty_ioctl() 164 schedule()<-schedule_timeout()<-acpi_ec_wait()<-acpi_ec_transaction() 157 schedule()<-refrigerator()<-get_signal_to_deliver()<-do_notify_resume() 118 schedule()<-worker_thread()<-kthread()<-kernel_thread_helper() 80 schedule()<-do_msleep()<-msleep()<-sata_link_debounce() 64 schedule()<-schedule_timeout()<-inet_csk_accept()<-inet_accept() 37 schedule()<-__mutex_lock_slowpath()<-mutex_lock()<-acpi_ec_transaction() 20 schedule()<-schedule_timeout()<-do_select()<-core_sys_select() 20 schedule()<-io_schedule()<-sync_buffer()<-__wait_on_bit() what's weird are all those ps2 related sleeps - they make up for much of the delay. This how such a sleep point looks like: bash 3500 0D... 8641415us : schedule()<-schedule_timeout()<-ps2_sendbyte()<-ps2_command() bash 3500 0D... 8641417us : psmouse_sliced_command()<-synaptics_pt_write()<-ps2_sendbyte()<-ps2_command() it starts somewhere here: bash 3500 0.... 5302376us : serio_reconnect_driver (serio_resume) and ends: kseriod 208 0D... 9182560us : synaptics_query_hardware()<-synaptics_reconnect()<-psmouse_reconnect()<-serio_reconnect_driver() so this section (serio_resume()) took almost 4 seconds. the main delay seems to be dpm_resume(): bash 3500 0.N.. 3061040us : dpm_resume (device_resume) ... bash 3500 0.... 9105017us : mutex_unlock (dpm_resume) bash 3500 0.... 9105018us : mutex_unlock (device_resume) 6.1 seconds! Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* [patch] snd hda suspend latency: shorten codec read 2007-11-16 12:43 ` Ingo Molnar @ 2007-11-16 12:58 ` Ingo Molnar 2007-11-16 13:31 ` Rafael J. Wysocki 2007-11-16 14:21 ` Takashi Iwai 0 siblings, 2 replies; 268+ messages in thread From: Ingo Molnar @ 2007-11-16 12:58 UTC (permalink / raw) To: Mark Lord, perex, Takashi Iwai Cc: Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw, Len Brown snd hda suspend latency goes down a second via the patch below. Ingo -------------> Subject: snd hda suspend latency: shorten codec read From: Ingo Molnar <mingo@elte.hu> not sleeping for every codec read/write but doing a short udelay and a conditional reschedule has cut suspend+resume latency by about 1 second on my T60. Signed-off-by: Ingo Molnar <mingo@elte.hu> --- sound/pci/hda/hda_intel.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Index: linux/sound/pci/hda/hda_intel.c =================================================================== --- linux.orig/sound/pci/hda/hda_intel.c +++ linux/sound/pci/hda/hda_intel.c @@ -555,7 +555,8 @@ static unsigned int azx_rirb_get_respons } if (!chip->rirb.cmds) return chip->rirb.res; /* the last value */ - schedule_timeout_uninterruptible(1); + udelay(10); + cond_resched(); } while (time_after_eq(timeout, jiffies)); if (chip->msi) { ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [patch] snd hda suspend latency: shorten codec read 2007-11-16 12:58 ` [patch] snd hda suspend latency: shorten codec read Ingo Molnar @ 2007-11-16 13:31 ` Rafael J. Wysocki 2007-11-16 14:21 ` Takashi Iwai 1 sibling, 0 replies; 268+ messages in thread From: Rafael J. Wysocki @ 2007-11-16 13:31 UTC (permalink / raw) To: Ingo Molnar Cc: Mark Lord, perex, Takashi Iwai, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, Len Brown On Friday, 16 of November 2007, Ingo Molnar wrote: > > snd hda suspend latency goes down a second via the patch below. > > Ingo > > -------------> > Subject: snd hda suspend latency: shorten codec read > From: Ingo Molnar <mingo@elte.hu> > > not sleeping for every codec read/write but doing a short udelay and > a conditional reschedule has cut suspend+resume latency by about 1 > second on my T60. > > Signed-off-by: Ingo Molnar <mingo@elte.hu> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> > --- > sound/pci/hda/hda_intel.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > Index: linux/sound/pci/hda/hda_intel.c > =================================================================== > --- linux.orig/sound/pci/hda/hda_intel.c > +++ linux/sound/pci/hda/hda_intel.c > @@ -555,7 +555,8 @@ static unsigned int azx_rirb_get_respons > } > if (!chip->rirb.cmds) > return chip->rirb.res; /* the last value */ > - schedule_timeout_uninterruptible(1); > + udelay(10); > + cond_resched(); > } while (time_after_eq(timeout, jiffies)); > > if (chip->msi) { > > -- "Premature optimization is the root of all evil." - Donald Knuth ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [patch] snd hda suspend latency: shorten codec read 2007-11-16 12:58 ` [patch] snd hda suspend latency: shorten codec read Ingo Molnar 2007-11-16 13:31 ` Rafael J. Wysocki @ 2007-11-16 14:21 ` Takashi Iwai 1 sibling, 0 replies; 268+ messages in thread From: Takashi Iwai @ 2007-11-16 14:21 UTC (permalink / raw) To: Ingo Molnar Cc: Mark Lord, perex, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw, Len Brown At Fri, 16 Nov 2007 13:58:24 +0100, Ingo Molnar wrote: > > > snd hda suspend latency goes down a second via the patch below. > > Ingo > > -------------> > Subject: snd hda suspend latency: shorten codec read > From: Ingo Molnar <mingo@elte.hu> > > not sleeping for every codec read/write but doing a short udelay and > a conditional reschedule has cut suspend+resume latency by about 1 > second on my T60. > > Signed-off-by: Ingo Molnar <mingo@elte.hu> Cute, I applied to ALSA tree now. Thanks! Takashi > --- > sound/pci/hda/hda_intel.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > Index: linux/sound/pci/hda/hda_intel.c > =================================================================== > --- linux.orig/sound/pci/hda/hda_intel.c > +++ linux/sound/pci/hda/hda_intel.c > @@ -555,7 +555,8 @@ static unsigned int azx_rirb_get_respons > } > if (!chip->rirb.cmds) > return chip->rirb.res; /* the last value */ > - schedule_timeout_uninterruptible(1); > + udelay(10); > + cond_resched(); > } while (time_after_eq(timeout, jiffies)); > > if (chip->msi) { > ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-16 7:15 ` Ingo Molnar 2007-11-16 8:21 ` Ingo Molnar @ 2007-11-16 19:06 ` Mark Lord 1 sibling, 0 replies; 268+ messages in thread From: Mark Lord @ 2007-11-16 19:06 UTC (permalink / raw) To: Ingo Molnar Cc: Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw Ingo Molnar wrote: > * Ingo Molnar <mingo@elte.hu> wrote: > >>> Is there a version of these that works with 2.6.23.1 ? >> yes, i've backported it and have uploaded the v2.6.23 version to: >> >> http://redhat.com/~mingo/latency-tracing-patches/latency-tracer-v2.6.23.1-combo.patch .. > ok, i experimented around with the latency tracer, trying to capture the > trace of a full suspend+resume cycle, and it needed the tracer fix below > (GTOD clocksource suspend/resume would otherwise confuse the tracer and > you'd get no trace output as a result). > > once that tracer bug was fixed, the best method to generate a trace was > to do this: > > echo 1 > /proc/sys/kernel/stackframe_tracing > echo 1 > /proc/sys/kernel/syscall_tracing > ./trace-cmd bash -c "echo mem > /sys/power/state" > trace.txt .. I've applied the tracer for 2.6.23.1 patch, plus the bugfix, and now I just get blinking-LEDs (black screen of death) on resume. Cheers ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-15 22:23 ` Mark Lord 2007-11-16 5:55 ` Ingo Molnar @ 2007-11-16 18:35 ` Mark Lord 2007-11-30 20:12 ` Mark Lord 2 siblings, 0 replies; 268+ messages in thread From: Mark Lord @ 2007-11-16 18:35 UTC (permalink / raw) To: Ingo Molnar Cc: Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw Mark Lord wrote: > Ingo Molnar wrote: >> * Ingo Molnar <mingo@elte.hu> wrote: >> >>> pick up the latest latency tracer patch from: >> >> sorry, wrong URLs, the correct links are: >> >> >> http://redhat.com/~mingo/latency-tracing-patches/latency-tracer-v2.6.24-rc2-git5-combo.patch >> >> http://redhat.com/~mingo/latency-tracing-patches/trace-cmd.c .. make trace-cmd cc -Wall -O2 -s trace-cmd.c -o trace-cmd trace-cmd.c: In function ‘main’: trace-cmd.c:65: warning: label ‘usage’ defined but not used ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-15 22:23 ` Mark Lord 2007-11-16 5:55 ` Ingo Molnar 2007-11-16 18:35 ` Mark Lord @ 2007-11-30 20:12 ` Mark Lord 2 siblings, 0 replies; 268+ messages in thread From: Mark Lord @ 2007-11-30 20:12 UTC (permalink / raw) To: Ingo Molnar Cc: Pavel Machek, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw Mark Lord wrote: > Ingo Molnar wrote: >> * Ingo Molnar <mingo@elte.hu> wrote: >> >>> pick up the latest latency tracer patch from: >> >> sorry, wrong URLs, the correct links are: >> >> >> http://redhat.com/~mingo/latency-tracing-patches/latency-tracer-v2.6.24-rc2-git5-combo.patch >> >> http://redhat.com/~mingo/latency-tracing-patches/trace-cmd.c > .. > > Is there a version of these that works with 2.6.23.1 ? > > I'm not using 2.6.24-* on this machine because: > (a) behaviour may be different, and > (b) something broke VMware compatibility again. .. An update: Ingo's 2.6.23 version of the latency-tracing-patches only lock-up on resume here. But now that I've hacked vmware to work on 2.6.24, my notebook is now running the newer kernels. So now to see if the "strange 1-second pauses" ever happen here, and if they do I'll patch in Ingo's stuff to try and find out why. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-15 19:36 ` Ingo Molnar 2007-11-15 22:23 ` Mark Lord @ 2007-11-30 12:56 ` Jörn Engel 2007-11-30 13:35 ` Ingo Molnar 1 sibling, 1 reply; 268+ messages in thread From: Jörn Engel @ 2007-11-30 12:56 UTC (permalink / raw) To: Ingo Molnar Cc: Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw On Thu, 15 November 2007 20:36:12 +0100, Ingo Molnar wrote: > * Ingo Molnar <mingo@elte.hu> wrote: > > > pick up the latest latency tracer patch from: > > sorry, wrong URLs, the correct links are: > > http://redhat.com/~mingo/latency-tracing-patches/latency-tracer-v2.6.24-rc2-git5-combo.patch > http://redhat.com/~mingo/latency-tracing-patches/trace-cmd.c Don't seem to work with plain 2.6.23: kernel/sched.c:3384: warning: ‘struct prio_array’ declared inside parameter list kernel/sched.c:3384: warning: its scope is only this definition or declaration, which is probably not what you want kernel/sched.c: In function ‘trace_array’: kernel/sched.c:3391: error: dereferencing pointer to incomplete type kernel/sched.c:3393: error: dereferencing pointer to incomplete type kernel/sched.c:3393: error: dereferencing pointer to incomplete type kernel/sched.c:3396: error: dereferencing pointer to incomplete type kernel/sched.c:3396: error: dereferencing pointer to incomplete type kernel/sched.c: In function ‘trace_all_runnable_tasks’: kernel/sched.c:3407: error: ‘struct rq’ has no member named ‘active’ make[1]: *** [kernel/sched.o] Error 1 And I cannot find a definition of struct prio_array in current git either. Is another patch needed? Jörn -- Time? What's that? Time is only worth what you do with it. -- Theo de Raadt ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-30 12:56 ` Jörn Engel @ 2007-11-30 13:35 ` Ingo Molnar 2007-11-30 13:43 ` Ingo Molnar 2007-11-30 15:49 ` Jörn Engel 0 siblings, 2 replies; 268+ messages in thread From: Ingo Molnar @ 2007-11-30 13:35 UTC (permalink / raw) To: Jörn Engel Cc: Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw * Jörn Engel <joern@logfs.org> wrote: > On Thu, 15 November 2007 20:36:12 +0100, Ingo Molnar wrote: > > * Ingo Molnar <mingo@elte.hu> wrote: > > > > > pick up the latest latency tracer patch from: > > > > sorry, wrong URLs, the correct links are: > > > > http://redhat.com/~mingo/latency-tracing-patches/latency-tracer-v2.6.24-rc2-git5-combo.patch > > http://redhat.com/~mingo/latency-tracing-patches/trace-cmd.c > > Don't seem to work with plain 2.6.23: > > kernel/sched.c:3384: warning: ‘struct prio_array’ declared inside parameter list > kernel/sched.c:3384: warning: its scope is only this definition or declaration, which is probably not what you want > kernel/sched.c: In function ‘trace_array’: > kernel/sched.c:3391: error: dereferencing pointer to incomplete type > kernel/sched.c:3393: error: dereferencing pointer to incomplete type > kernel/sched.c:3393: error: dereferencing pointer to incomplete type > kernel/sched.c:3396: error: dereferencing pointer to incomplete type > kernel/sched.c:3396: error: dereferencing pointer to incomplete type > kernel/sched.c: In function ‘trace_all_runnable_tasks’: > kernel/sched.c:3407: error: ‘struct rq’ has no member named ‘active’ > make[1]: *** [kernel/sched.o] Error 1 > > And I cannot find a definition of struct prio_array in current git > either. Is another patch needed? change that to rt_prio_array in the code. Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-30 13:35 ` Ingo Molnar @ 2007-11-30 13:43 ` Ingo Molnar 2007-11-30 18:35 ` Jörn Engel 2007-11-30 15:49 ` Jörn Engel 1 sibling, 1 reply; 268+ messages in thread From: Ingo Molnar @ 2007-11-30 13:43 UTC (permalink / raw) To: J?rn Engel Cc: Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw * Ingo Molnar <mingo@elte.hu> wrote: > > > sorry, wrong URLs, the correct links are: > > > > > > http://redhat.com/~mingo/latency-tracing-patches/latency-tracer-v2.6.24-rc2-git5-combo.patch > > > http://redhat.com/~mingo/latency-tracing-patches/trace-cmd.c > > > > Don't seem to work with plain 2.6.23: could you try this updated version: http://redhat.com/~mingo/latency-tracing-patches/latency-tracing-v2.6.24-rc3.combo.patch does it work any better? Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-30 13:43 ` Ingo Molnar @ 2007-11-30 18:35 ` Jörn Engel 2007-11-30 18:46 ` Ingo Molnar 0 siblings, 1 reply; 268+ messages in thread From: Jörn Engel @ 2007-11-30 18:35 UTC (permalink / raw) To: Ingo Molnar Cc: J?rn Engel, Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw On Fri, 30 November 2007 14:43:12 +0100, Ingo Molnar wrote: > > http://redhat.com/~mingo/latency-tracing-patches/latency-tracing-v2.6.24-rc3.combo.patch > > does it work any better? It compiles. It boots with a 512M RAM (384M was too little with all the other debug options on). But it seems to lock up when running trace-cmd. On a rerun it locks up again, but with different output. Rerun was captured: http://logfs.org/~joern/trace1.jpg I should do a couple of runs, but my girlfriend claims realtime priority for the evening. Jörn -- Chance favors only the prepared mind. -- Louis Pasteur ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-30 18:35 ` Jörn Engel @ 2007-11-30 18:46 ` Ingo Molnar 2007-12-01 15:16 ` Jörn Engel 0 siblings, 1 reply; 268+ messages in thread From: Ingo Molnar @ 2007-11-30 18:46 UTC (permalink / raw) To: Jörn Engel Cc: Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw * Jörn Engel <joern@logfs.org> wrote: > On Fri, 30 November 2007 14:43:12 +0100, Ingo Molnar wrote: > > > > http://redhat.com/~mingo/latency-tracing-patches/latency-tracing-v2.6.24-rc3.combo.patch > > > > does it work any better? > > It compiles. It boots with a 512M RAM (384M was too little with all > the other debug options on). But it seems to lock up when running > trace-cmd. On a rerun it locks up again, but with different output. hm, you should decrease MAX_TRACE in kernel/latency_tracing.c from 1 million to 16K or so. 1 million entries probably depletes lowmem quite seriously. > Rerun was captured: > http://logfs.org/~joern/trace1.jpg hm, that looks weird. if you disable CONFIG_PROVE_LOCKING, does that improve things? (or just turns a noisy lockup into a silent lockup?) > I should do a couple of runs, but my girlfriend claims realtime > priority for the evening. yeah, SCHED_IDLE is not generally well received by them. Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-30 18:46 ` Ingo Molnar @ 2007-12-01 15:16 ` Jörn Engel 2007-12-01 18:32 ` Ingo Molnar 0 siblings, 1 reply; 268+ messages in thread From: Jörn Engel @ 2007-12-01 15:16 UTC (permalink / raw) To: Ingo Molnar Cc: Jörn Engel, Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw On Fri, 30 November 2007 19:46:25 +0100, Ingo Molnar wrote: > * Jörn Engel <joern@logfs.org> wrote: > > > > It compiles. It boots with a 512M RAM (384M was too little with all > > the other debug options on). But it seems to lock up when running > > trace-cmd. On a rerun it locks up again, but with different output. > > hm, you should decrease MAX_TRACE in kernel/latency_tracing.c from 1 > million to 16K or so. 1 million entries probably depletes lowmem quite > seriously. That's ok. RAM is cheap. > > Rerun was captured: > > http://logfs.org/~joern/trace1.jpg > > hm, that looks weird. if you disable CONFIG_PROVE_LOCKING, does that > improve things? (or just turns a noisy lockup into a silent lockup?) Not much, although the dumps look different now: http://logfs.org/~joern/trace3.jpg http://logfs.org/~joern/trace4.jpg I have to change my qemu setup a little to see the top of those dumps... > > I should do a couple of runs, but my girlfriend claims realtime > > priority for the evening. > > yeah, SCHED_IDLE is not generally well received by them. ...as soon as more urgent tasks has finished (weekend is over). Jörn -- It does not matter how slowly you go, so long as you do not stop. -- Confucius ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-12-01 15:16 ` Jörn Engel @ 2007-12-01 18:32 ` Ingo Molnar 2007-12-01 20:47 ` Jörn Engel 0 siblings, 1 reply; 268+ messages in thread From: Ingo Molnar @ 2007-12-01 18:32 UTC (permalink / raw) To: Jörn Engel Cc: Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw * Jörn Engel <joern@logfs.org> wrote: > > hm, that looks weird. if you disable CONFIG_PROVE_LOCKING, does that > > improve things? (or just turns a noisy lockup into a silent lockup?) > > Not much, although the dumps look different now: > http://logfs.org/~joern/trace3.jpg > http://logfs.org/~joern/trace4.jpg > > I have to change my qemu setup a little to see the top of those > dumps... btw., if you start qemu like this: qemu -cdrom ./cdrom.iso -hda ./hda.img -boot c -full-screen -kernel ~/bzImage -append "root=/dev/hda1 earlyprintk=serial,ttyS0,9600 console=tty console=ttyS0,9600 enforcing=0 debug" you'll get the inner kernel's serial console log to qemu's standard output. Pretty useful for capturing kernel crashes. Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-12-01 18:32 ` Ingo Molnar @ 2007-12-01 20:47 ` Jörn Engel 2007-12-01 20:54 ` Ingo Molnar 0 siblings, 1 reply; 268+ messages in thread From: Jörn Engel @ 2007-12-01 20:47 UTC (permalink / raw) To: Ingo Molnar Cc: Jörn Engel, Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw On Sat, 1 December 2007 19:32:56 +0100, Ingo Molnar wrote: > * Jörn Engel <joern@logfs.org> wrote: > > > I have to change my qemu setup a little to see the top of those > > dumps... > > btw., if you start qemu like this: > > qemu -cdrom ./cdrom.iso -hda ./hda.img -boot c -full-screen -kernel > ~/bzImage -append "root=/dev/hda1 earlyprintk=serial,ttyS0,9600 > console=tty console=ttyS0,9600 enforcing=0 debug" > > you'll get the inner kernel's serial console log to qemu's standard > output. Pretty useful for capturing kernel crashes. Almost. "-serial stdio" was missing. Much better now. stopped custom tracer. BUG: spinlock recursion on CPU#0, sh/953 lock: c030f280, .magic: dead4ead, .owner: sh/953, .owner_cpu: 0 Pid: 953, comm: sh Not tainted 2.6.24-rc3-ge1cca7e8-dirty #2 [<c0103a04>] show_trace_log_lvl+0x35/0x54 [<c010450a>] show_trace+0x2c/0x2e [<c0104e6d>] dump_stack+0x84/0x8a [<c01ded7c>] spin_bug+0xa7/0xae [<c01def14>] _raw_spin_lock+0x45/0xfa [<c02a02b1>] _spin_lock_irqsave+0x68/0x7a [<c01087e7>] pit_read+0x14/0x99 [<c0130ee9>] get_monotonic_cycles+0xf/0x2d [<c013c0ef>] now+0x2a/0x7c [<c013c33b>] ____trace+0x4d/0x1e8 [<c013dbf3>] __mcount+0x95/0xa6 [<c010d35c>] mcount+0x14/0x18 [<c0135a44>] lock_acquired+0xe/0x1d7 [<c02a02b9>] _spin_lock_irqsave+0x70/0x7a [<c01087e7>] pit_read+0x14/0x99 [<c0130791>] update_wall_time+0x23/0x692 [<c0121756>] do_timer+0x24/0xb1 [<c01331fe>] tick_periodic+0x49/0x84 [<c013325b>] tick_handle_periodic+0x22/0x73 [<c0106315>] timer_interrupt+0x4f/0x56 [<c013e2c7>] handle_IRQ_event+0x24/0x4f [<c013f44a>] handle_edge_irq+0xb8/0x125 [<c01054ee>] do_IRQ+0x89/0xa3 [<c01033df>] common_interrupt+0x23/0x28 [<c015d924>] vfs_write+0xa6/0x14c [<c015df6e>] sys_write+0x4c/0x70 [<c0102a1f>] syscall_call+0x7/0xb ======================= I assume you have the latency tracer working. If you could send me your config, I could do a manual config-bisect and see which part of mine causes the problem. Jörn -- Admonish your friends privately, but praise them openly. -- Publilius Syrus ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-12-01 20:47 ` Jörn Engel @ 2007-12-01 20:54 ` Ingo Molnar 2007-12-01 23:41 ` Jörn Engel 0 siblings, 1 reply; 268+ messages in thread From: Ingo Molnar @ 2007-12-01 20:54 UTC (permalink / raw) To: J??rn Engel Cc: Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw * J??rn Engel <joern@logfs.org> wrote: > Almost. "-serial stdio" was missing. Much better now. > > stopped custom tracer. > BUG: spinlock recursion on CPU#0, sh/953 > lock: c030f280, .magic: dead4ead, .owner: sh/953, .owner_cpu: 0 > Pid: 953, comm: sh Not tainted 2.6.24-rc3-ge1cca7e8-dirty #2 > [<c0103a04>] show_trace_log_lvl+0x35/0x54 > [<c010450a>] show_trace+0x2c/0x2e > [<c0104e6d>] dump_stack+0x84/0x8a > [<c01ded7c>] spin_bug+0xa7/0xae > [<c01def14>] _raw_spin_lock+0x45/0xfa > [<c02a02b1>] _spin_lock_irqsave+0x68/0x7a > [<c01087e7>] pit_read+0x14/0x99 > [<c0130ee9>] get_monotonic_cycles+0xf/0x2d ah. You should mark pit_read() function as notrace. PIT clocksource is rare. (add the 'notrace' word to the function prototype) Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-12-01 20:54 ` Ingo Molnar @ 2007-12-01 23:41 ` Jörn Engel 2007-12-02 8:56 ` Ingo Molnar 0 siblings, 1 reply; 268+ messages in thread From: Jörn Engel @ 2007-12-01 23:41 UTC (permalink / raw) To: Ingo Molnar Cc: J??rn Engel, Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw On Sat, 1 December 2007 21:54:56 +0100, Ingo Molnar wrote: > * J??rn Engel <joern@logfs.org> wrote: > > > > stopped custom tracer. > > BUG: spinlock recursion on CPU#0, sh/953 > > lock: c030f280, .magic: dead4ead, .owner: sh/953, .owner_cpu: 0 > > Pid: 953, comm: sh Not tainted 2.6.24-rc3-ge1cca7e8-dirty #2 > > [<c0103a04>] show_trace_log_lvl+0x35/0x54 > > [<c010450a>] show_trace+0x2c/0x2e > > [<c0104e6d>] dump_stack+0x84/0x8a > > [<c01ded7c>] spin_bug+0xa7/0xae > > [<c01def14>] _raw_spin_lock+0x45/0xfa > > [<c02a02b1>] _spin_lock_irqsave+0x68/0x7a > > [<c01087e7>] pit_read+0x14/0x99 > > [<c0130ee9>] get_monotonic_cycles+0xf/0x2d > > ah. You should mark pit_read() function as notrace. PIT clocksource is > rare. (add the 'notrace' word to the function prototype) Hardly a change at all. Apart from some offsets, this dump is identical. stopped custom tracer. BUG: spinlock recursion on CPU#0, sh/954 lock: c030f280, .magic: dead4ead, .owner: sh/954, .owner_cpu: 0 Pid: 954, comm: sh Not tainted 2.6.24-rc3-ge1cca7e8-dirty #3 [<c0103a04>] show_trace_log_lvl+0x35/0x54 [<c010450a>] show_trace+0x2c/0x2e [<c0104e6d>] dump_stack+0x84/0x8a [<c01ded7c>] spin_bug+0xa7/0xae [<c01def14>] _raw_spin_lock+0x45/0xfa [<c02a02b1>] _spin_lock_irqsave+0x68/0x7a [<c01087e2>] pit_read+0xf/0x91 [<c0130ee1>] get_monotonic_cycles+0xf/0x2d [<c013c0e7>] now+0x2a/0x7c [<c013c333>] ____trace+0x4d/0x1e8 [<c013dbeb>] __mcount+0x95/0xa6 [<c010d354>] mcount+0x14/0x18 [<c0135a3c>] lock_acquired+0xe/0x1d7 [<c02a02b9>] _spin_lock_irqsave+0x70/0x7a [<c01087e2>] pit_read+0xf/0x91 [<c0130789>] update_wall_time+0x23/0x692 [<c012174e>] do_timer+0x24/0xb1 [<c01331f6>] tick_periodic+0x49/0x84 [<c0133253>] tick_handle_periodic+0x22/0x73 [<c0106315>] timer_interrupt+0x4f/0x56 [<c013e2bf>] handle_IRQ_event+0x24/0x4f [<c013f442>] handle_edge_irq+0xb8/0x125 [<c01054ee>] do_IRQ+0x89/0xa3 [<c01033df>] common_interrupt+0x23/0x28 [<c010d354>] mcount+0x14/0x18 [<c0120130>] sysctl_head_finish+0xc/0x33 [<c0192d64>] proc_sys_write+0x96/0xa0 [<c015d91c>] vfs_write+0xa6/0x14c [<c015df66>] sys_write+0x4c/0x70 [<c0102a1f>] syscall_call+0x7/0xb ======================= Jörn -- Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats. -- Howard Aiken quoted by Ken Iverson quoted by Jim Horning quoted by Raph Levien, 1979 ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-12-01 23:41 ` Jörn Engel @ 2007-12-02 8:56 ` Ingo Molnar 2007-12-02 11:31 ` Jörn Engel 0 siblings, 1 reply; 268+ messages in thread From: Ingo Molnar @ 2007-12-02 8:56 UTC (permalink / raw) To: Jörn Engel Cc: Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw * Jörn Engel <joern@logfs.org> wrote: > > ah. You should mark pit_read() function as notrace. PIT clocksource > > is rare. (add the 'notrace' word to the function prototype) > > Hardly a change at all. Apart from some offsets, this dump is > identical. > > stopped custom tracer. > BUG: spinlock recursion on CPU#0, sh/954 > lock: c030f280, .magic: dead4ead, .owner: sh/954, .owner_cpu: 0 > Pid: 954, comm: sh Not tainted 2.6.24-rc3-ge1cca7e8-dirty #3 > [<c0103a04>] show_trace_log_lvl+0x35/0x54 > [<c010450a>] show_trace+0x2c/0x2e > [<c0104e6d>] dump_stack+0x84/0x8a > [<c01ded7c>] spin_bug+0xa7/0xae > [<c01def14>] _raw_spin_lock+0x45/0xfa > [<c02a02b1>] _spin_lock_irqsave+0x68/0x7a > [<c01087e2>] pit_read+0xf/0x91 > [<c0130ee1>] get_monotonic_cycles+0xf/0x2d > [<c013c0e7>] now+0x2a/0x7c > [<c013c333>] ____trace+0x4d/0x1e8 > [<c013dbeb>] __mcount+0x95/0xa6 > [<c010d354>] mcount+0x14/0x18 > [<c0135a3c>] lock_acquired+0xe/0x1d7 > [<c02a02b9>] _spin_lock_irqsave+0x70/0x7a > [<c01087e2>] pit_read+0xf/0x91 hm, it seems lock_acquired() [in kernel/lockdep.c] needs to be marked 'notrace' too - otherwise we recurse back into pit_read(). Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-12-02 8:56 ` Ingo Molnar @ 2007-12-02 11:31 ` Jörn Engel 2007-12-02 12:31 ` Jörn Engel 2007-12-02 13:57 ` Ingo Molnar 0 siblings, 2 replies; 268+ messages in thread From: Jörn Engel @ 2007-12-02 11:31 UTC (permalink / raw) To: Ingo Molnar Cc: Jörn Engel, Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw On Sun, 2 December 2007 09:56:08 +0100, Ingo Molnar wrote: > * Jörn Engel <joern@logfs.org> wrote: > > > > ah. You should mark pit_read() function as notrace. PIT clocksource > > > is rare. (add the 'notrace' word to the function prototype) > > > > Hardly a change at all. Apart from some offsets, this dump is > > identical. > > > > stopped custom tracer. > > BUG: spinlock recursion on CPU#0, sh/954 > > lock: c030f280, .magic: dead4ead, .owner: sh/954, .owner_cpu: 0 > > Pid: 954, comm: sh Not tainted 2.6.24-rc3-ge1cca7e8-dirty #3 > > [<c0103a04>] show_trace_log_lvl+0x35/0x54 > > [<c010450a>] show_trace+0x2c/0x2e > > [<c0104e6d>] dump_stack+0x84/0x8a > > [<c01ded7c>] spin_bug+0xa7/0xae > > [<c01def14>] _raw_spin_lock+0x45/0xfa > > [<c02a02b1>] _spin_lock_irqsave+0x68/0x7a > > [<c01087e2>] pit_read+0xf/0x91 > > [<c0130ee1>] get_monotonic_cycles+0xf/0x2d > > [<c013c0e7>] now+0x2a/0x7c > > [<c013c333>] ____trace+0x4d/0x1e8 > > [<c013dbeb>] __mcount+0x95/0xa6 > > [<c010d354>] mcount+0x14/0x18 > > [<c0135a3c>] lock_acquired+0xe/0x1d7 > > [<c02a02b9>] _spin_lock_irqsave+0x70/0x7a > > [<c01087e2>] pit_read+0xf/0x91 > > hm, it seems lock_acquired() [in kernel/lockdep.c] needs to be marked > 'notrace' too - otherwise we recurse back into pit_read(). This time not even the offsets have changed. Dump is identical. Jörn -- Mundie uses a textbook tactic of manipulation: start with some reasonable talk, and lead the audience to an unreasonable conclusion. -- Bruce Perens ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-12-02 11:31 ` Jörn Engel @ 2007-12-02 12:31 ` Jörn Engel 2007-12-02 13:57 ` Ingo Molnar 2007-12-02 14:46 ` Jörn Engel 2007-12-02 13:57 ` Ingo Molnar 1 sibling, 2 replies; 268+ messages in thread From: Jörn Engel @ 2007-12-02 12:31 UTC (permalink / raw) To: Jörn Engel Cc: Ingo Molnar, Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw On Sun, 2 December 2007 12:31:43 +0100, Jörn Engel wrote: > > This time not even the offsets have changed. Dump is identical. After another ten or so notrace annotations throughout the spinlock code, the latency tracer appears to work. Not sure how many useful information is missing through all the annotations, though. Jörn -- Das Aufregende am Schreiben ist es, eine Ordnung zu schaffen, wo vorher keine existiert hat. -- Doris Lessing ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-12-02 12:31 ` Jörn Engel @ 2007-12-02 13:57 ` Ingo Molnar 2007-12-02 14:46 ` Jörn Engel 1 sibling, 0 replies; 268+ messages in thread From: Ingo Molnar @ 2007-12-02 13:57 UTC (permalink / raw) To: Jörn Engel Cc: Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw * Jörn Engel <joern@logfs.org> wrote: > On Sun, 2 December 2007 12:31:43 +0100, Jörn Engel wrote: > > > > This time not even the offsets have changed. Dump is identical. > > After another ten or so notrace annotations throughout the spinlock > code, the latency tracer appears to work. Not sure how many useful > information is missing through all the annotations, though. a few annotations out of thousands of function calls in the kernel it's usually not significant. Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-12-02 12:31 ` Jörn Engel 2007-12-02 13:57 ` Ingo Molnar @ 2007-12-02 14:46 ` Jörn Engel 2007-12-02 15:44 ` Ingo Molnar 1 sibling, 1 reply; 268+ messages in thread From: Jörn Engel @ 2007-12-02 14:46 UTC (permalink / raw) To: Jörn Engel Cc: Ingo Molnar, Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw On Sun, 2 December 2007 13:31:25 +0100, Jörn Engel wrote: > > After another ten or so notrace annotations throughout the spinlock > code, the latency tracer appears to work. Not sure how many useful > information is missing through all the annotations, though. And here is a patch with the needed annotations. Looks a bit shabby, as it was generated though git diff, patcher, interdiff and combinediff. Jörn -- Joern's library part 10: http://blogs.msdn.com/David_Gristwood/archive/2004/06/24/164849.aspx unchanged: --- a/arch/x86/kernel/i8253.c +++ b/arch/x86/kernel/i8253.c @@ -125,7 +125,7 @@ void __init setup_pit_timer(void) * to just read by itself. So use jiffies to emulate a free * running counter: */ -static cycle_t pit_read(void) +static notrace cycle_t pit_read(void) { unsigned long flags; int count; unchanged: --- a/kernel/spinlock.c +++ b/kernel/spinlock.c @@ -76,7 +76,7 @@ void __lockfunc _read_lock(rwlock_t *lock) } EXPORT_SYMBOL(_read_lock); -unsigned long __lockfunc _spin_lock_irqsave(spinlock_t *lock) +unsigned long notrace __lockfunc _spin_lock_irqsave(spinlock_t *lock) { unsigned long flags; @@ -341,7 +341,7 @@ void __lockfunc _read_unlock(rwlock_t *lock) } EXPORT_SYMBOL(_read_unlock); -void __lockfunc _spin_unlock_irqrestore(spinlock_t *lock, unsigned long flags) +void notrace __lockfunc _spin_unlock_irqrestore(spinlock_t *lock, unsigned long flags) { spin_release(&lock->dep_map, 1, _RET_IP_); _raw_spin_unlock(lock); unchanged: --- a/lib/spinlock_debug.c +++ b/lib/spinlock_debug.c @@ -148,7 +148,7 @@ int _raw_spin_trylock(spinlock_t *lock) return ret; } -void _raw_spin_unlock(spinlock_t *lock) +void notrace _raw_spin_unlock(spinlock_t *lock) { debug_spin_unlock(lock); __raw_spin_unlock(&lock->raw_lock); only in patch2: unchanged: --- linux/arch/x86/kernel/tsc_32.c +++ linux-2.6.24-rc3logfs/arch/x86/kernel/tsc_32.c 2007-12-02 15:21:15.000000000 +0100 @@ -92,7 +92,7 @@ /* * Scheduler clock - returns current time in nanosec units. */ -unsigned long long native_sched_clock(void) +unsigned notrace long long native_sched_clock(void) { unsigned long long this_offset; only in patch2: unchanged: --- linux/kernel/lockdep.c +++ linux-2.6.24-rc3logfs/kernel/lockdep.c 2007-12-02 15:21:16.000000000 +0100 @@ -139,7 +139,7 @@ return i; } -static void lock_time_inc(struct lock_time *lt, s64 time) +static notrace void lock_time_inc(struct lock_time *lt, s64 time) { if (time > lt->max) lt->max = time; @@ -198,7 +198,7 @@ memset(class->contention_point, 0, sizeof(class->contention_point)); } -static struct lock_class_stats *get_lock_stats(struct lock_class *class) +static notrace struct lock_class_stats *get_lock_stats(struct lock_class *class) { return &get_cpu_var(lock_stats)[class - lock_classes]; } @@ -208,7 +208,7 @@ put_cpu_var(lock_stats); } -static void lock_release_holdtime(struct held_lock *hlock) +static notrace void lock_release_holdtime(struct held_lock *hlock) { struct lock_class_stats *stats; s64 holdtime; @@ -2872,7 +2872,7 @@ } EXPORT_SYMBOL_GPL(lock_contended); -void lock_acquired(struct lockdep_map *lock) +void notrace lock_acquired(struct lockdep_map *lock) { unsigned long flags; ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-12-02 14:46 ` Jörn Engel @ 2007-12-02 15:44 ` Ingo Molnar 0 siblings, 0 replies; 268+ messages in thread From: Ingo Molnar @ 2007-12-02 15:44 UTC (permalink / raw) To: Jörn Engel Cc: Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw, Steven Rostedt * Jörn Engel <joern@logfs.org> wrote: > On Sun, 2 December 2007 13:31:25 +0100, Jörn Engel wrote: > > > > After another ten or so notrace annotations throughout the spinlock > > code, the latency tracer appears to work. Not sure how many useful > > information is missing through all the annotations, though. > > And here is a patch with the needed annotations. Looks a bit shabby, > as it was generated though git diff, patcher, interdiff and > combinediff. thanks - the patches applied fine, i've added them to my latency-tracer patchqueue. Steve Rostedt might want to pick the fixes up for -rt as well. Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-12-02 11:31 ` Jörn Engel 2007-12-02 12:31 ` Jörn Engel @ 2007-12-02 13:57 ` Ingo Molnar 2007-12-02 14:11 ` Jörn Engel 1 sibling, 1 reply; 268+ messages in thread From: Ingo Molnar @ 2007-12-02 13:57 UTC (permalink / raw) To: Jörn Engel Cc: Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw * Jörn Engel <joern@logfs.org> wrote: > On Sun, 2 December 2007 09:56:08 +0100, Ingo Molnar wrote: > > * Jörn Engel <joern@logfs.org> wrote: > > > > > > ah. You should mark pit_read() function as notrace. PIT clocksource > > > > is rare. (add the 'notrace' word to the function prototype) > > > > > > Hardly a change at all. Apart from some offsets, this dump is > > > identical. > > > > > > stopped custom tracer. > > > BUG: spinlock recursion on CPU#0, sh/954 > > > lock: c030f280, .magic: dead4ead, .owner: sh/954, .owner_cpu: 0 > > > Pid: 954, comm: sh Not tainted 2.6.24-rc3-ge1cca7e8-dirty #3 > > > [<c0103a04>] show_trace_log_lvl+0x35/0x54 > > > [<c010450a>] show_trace+0x2c/0x2e > > > [<c0104e6d>] dump_stack+0x84/0x8a > > > [<c01ded7c>] spin_bug+0xa7/0xae > > > [<c01def14>] _raw_spin_lock+0x45/0xfa > > > [<c02a02b1>] _spin_lock_irqsave+0x68/0x7a > > > [<c01087e2>] pit_read+0xf/0x91 > > > [<c0130ee1>] get_monotonic_cycles+0xf/0x2d > > > [<c013c0e7>] now+0x2a/0x7c > > > [<c013c333>] ____trace+0x4d/0x1e8 > > > [<c013dbeb>] __mcount+0x95/0xa6 > > > [<c010d354>] mcount+0x14/0x18 > > > [<c0135a3c>] lock_acquired+0xe/0x1d7 > > > [<c02a02b9>] _spin_lock_irqsave+0x70/0x7a > > > [<c01087e2>] pit_read+0xf/0x91 > > > > hm, it seems lock_acquired() [in kernel/lockdep.c] needs to be marked > > 'notrace' too - otherwise we recurse back into pit_read(). > > This time not even the offsets have changed. Dump is identical. hm, do you have CONFIG_FRAME_POINTERS=y, i.e. are the dumps reliable? Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-12-02 13:57 ` Ingo Molnar @ 2007-12-02 14:11 ` Jörn Engel 2007-12-02 15:47 ` Ingo Molnar 0 siblings, 1 reply; 268+ messages in thread From: Jörn Engel @ 2007-12-02 14:11 UTC (permalink / raw) To: Ingo Molnar Cc: Jörn Engel, Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw On Sun, 2 December 2007 14:57:11 +0100, Ingo Molnar wrote: > > hm, do you have CONFIG_FRAME_POINTERS=y, i.e. are the dumps reliable? I do. Went through 10odd runs and annotated the function right below mcount each time. Seems to work now. Trouble is that it doesn't solve my real problem at hand. Something is causing significant delays when writing to logfs. Core logfs code is not running, but may cause whatever other code is running and burning up all the cpu time. Wasting 100ms of "qemu-time" to write a single page happens fairly frequently. With the latency tracer the problem appears to have become worse. Now the loftlockup code triggers quite frequently. Which makes a bit of sense, as the problem is a busy CPU, rather than an idle one. Guess I'll try oprofile or lcov instead. Jörn -- Joern's library part 5: http://www.faqs.org/faqs/compression-faq/part2/section-9.html ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-12-02 14:11 ` Jörn Engel @ 2007-12-02 15:47 ` Ingo Molnar 2007-12-02 19:55 ` Jörn Engel 0 siblings, 1 reply; 268+ messages in thread From: Ingo Molnar @ 2007-12-02 15:47 UTC (permalink / raw) To: Jörn Engel Cc: Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw * Jörn Engel <joern@logfs.org> wrote: > I do. Went through 10odd runs and annotated the function right below > mcount each time. Seems to work now. > > Trouble is that it doesn't solve my real problem at hand. Something > is causing significant delays when writing to logfs. Core logfs code > is not running, but may cause whatever other code is running and > burning up all the cpu time. Wasting 100ms of "qemu-time" to write a > single page happens fairly frequently. > > With the latency tracer the problem appears to have become worse. Now > the loftlockup code triggers quite frequently. Which makes a bit of > sense, as the problem is a busy CPU, rather than an idle one. well what does the trace say, where do the delays come from? To get a quick overview you can make tracing lighter weight by doing: echo 0 > /proc/sys/kernel/mcount_enabled echo 1 > /proc/sys/kernel/trace_syscalls (this turns the latency tracer into a "global strace" kind of tracer) Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-12-02 15:47 ` Ingo Molnar @ 2007-12-02 19:55 ` Jörn Engel 2007-12-02 20:07 ` Ingo Molnar 0 siblings, 1 reply; 268+ messages in thread From: Jörn Engel @ 2007-12-02 19:55 UTC (permalink / raw) To: Ingo Molnar Cc: Jörn Engel, Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw On Sun, 2 December 2007 16:47:46 +0100, Ingo Molnar wrote: > > well what does the trace say, where do the delays come from? To get a > quick overview you can make tracing lighter weight by doing: > > echo 0 > /proc/sys/kernel/mcount_enabled > echo 1 > /proc/sys/kernel/trace_syscalls I mistyped and did echo 1 > /proc/sys/kernel/mcount_enabled Result looked like a livelock and finally convinced me to abandon the latency tracer. Sorry, but it appears to be the right tool for the wrong job. Jörn -- They laughed at Galileo. They laughed at Copernicus. They laughed at Columbus. But remember, they also laughed at Bozo the Clown. -- unknown ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-12-02 19:55 ` Jörn Engel @ 2007-12-02 20:07 ` Ingo Molnar 2007-12-02 20:30 ` Jörn Engel 0 siblings, 1 reply; 268+ messages in thread From: Ingo Molnar @ 2007-12-02 20:07 UTC (permalink / raw) To: Jörn Engel Cc: Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw * Jörn Engel <joern@logfs.org> wrote: > On Sun, 2 December 2007 16:47:46 +0100, Ingo Molnar wrote: > > > > well what does the trace say, where do the delays come from? To get a > > quick overview you can make tracing lighter weight by doing: > > > > echo 0 > /proc/sys/kernel/mcount_enabled > > echo 1 > /proc/sys/kernel/trace_syscalls > > I mistyped and did > echo 1 > /proc/sys/kernel/mcount_enabled > > Result looked like a livelock and finally convinced me to abandon the > latency tracer. Sorry, but it appears to be the right tool for the > wrong job. hm, we routinely use it in -rt to capture "what on earth is happening" incidents. The snippet below is a random snipped from a trace that i've just captured, with mcount enabled. It seems to work fine here, with and without mcount. (pit clocksource is almost never used, that's why you had those early problems.) oprofile helps if you can reliably reproduce the slowdown in a loop or for a long amount of time, with lots of CPU utilization - and then it's also lower overhead. The tracer can be used to capture rare or complex events, and gives the full flow control and what is happening within the kernel. Ingo ------------> <idle> 0 1D... 811us : sched_clock_idle_sleep_event (acpi_processor_idle) <idle> 0 1D... 813us : _spin_lock (sched_clock_idle_sleep_event) trace-cm 2463 0.... 814us : native_flush_tlb_others (flush_tlb_mm) <idle> 0 1D... 815us : __update_rq_clock (sched_clock_idle_sleep_event) trace-cm 2463 0.... 817us : _spin_lock (native_flush_tlb_others) <idle> 0 1D... 817us+: acpi_cstate_enter (acpi_processor_idle) trace-cm 2463 0.... 820us+: send_IPI_mask_bitmask (native_flush_tlb_others) trace-cm 2463 0D... 823us+: apic_wait_icr_idle (send_IPI_mask_bitmask) trace-cm 2463 0.... 856us+: up_write (copy_process) trace-cm 2463 0.... 859us+: copy_keys (copy_process) trace-cm 2463 0.... 862us+: copy_namespaces (copy_process) trace-cm 2463 0.... 865us+: copy_thread (copy_process) trace-cm 2463 0.... 868us+: memcpy (copy_thread) trace-cm 2463 0.... 871us+: alloc_pid (copy_process) trace-cm 2463 0.... 874us+: kmem_cache_alloc (alloc_pid) trace-cm 2463 0.... 877us+: _spin_lock_irq (alloc_pid) trace-cm 2463 0.... 880us+: _write_lock_irq (copy_process) trace-cm 2463 0D... 883us+: _spin_lock (copy_process) trace-cm 2463 0D... 887us+: recalc_sigpending (copy_process) trace-cm 2463 0D... 890us+: recalc_sigpending_tsk (recalc_sigpending) trace-cm 2463 0D... 893us+: attach_pid (copy_process) trace-cm 2463 0D... 896us+: attach_pid (copy_process) trace-cm 2463 0D... 899us+: attach_pid (copy_process) trace-cm 2463 0.... 902us+: proc_fork_connector (copy_process) trace-cm 2463 0.... 905us+: wake_up_new_task (do_fork) trace-cm 2463 0.... 908us+: task_rq_lock (wake_up_new_task) trace-cm 2463 0D... 911us+: _spin_lock (task_rq_lock) trace-cm 2463 0D... 914us+: update_rq_clock (wake_up_new_task) trace-cm 2463 0D... 918us+: __update_rq_clock (update_rq_clock) trace-cm 2463 0D... 921us+: effective_prio (wake_up_new_task) trace-cm 2463 0D... 924us+: wake_up_new_task <hwclock 2474> (0 0) ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-12-02 20:07 ` Ingo Molnar @ 2007-12-02 20:30 ` Jörn Engel 2007-12-02 20:45 ` Ingo Molnar 0 siblings, 1 reply; 268+ messages in thread From: Jörn Engel @ 2007-12-02 20:30 UTC (permalink / raw) To: Ingo Molnar Cc: Jörn Engel, Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw On Sun, 2 December 2007 21:07:22 +0100, Ingo Molnar wrote: > * Jörn Engel <joern@logfs.org> wrote: > > > Result looked like a livelock and finally convinced me to abandon the > > latency tracer. Sorry, but it appears to be the right tool for the > > wrong job. > > hm, we routinely use it in -rt to capture "what on earth is happening" > incidents. The snippet below is a random snipped from a trace that i've > just captured, with mcount enabled. It seems to work fine here, with and > without mcount. (pit clocksource is almost never used, that's why you > had those early problems.) > > oprofile helps if you can reliably reproduce the slowdown in a loop or > for a long amount of time, with lots of CPU utilization - and then it's > also lower overhead. The tracer can be used to capture rare or complex > events, and gives the full flow control and what is happening within the > kernel. Such a trace would be useful indeed. But so far the patch has only given me grief and nothing remotely like useful output. Maybe I should simply use the complete -rt patch instead of debugging the broken-out latency-tracer patch. Jörn -- Mundie uses a textbook tactic of manipulation: start with some reasonable talk, and lead the audience to an unreasonable conclusion. -- Bruce Perens ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-12-02 20:30 ` Jörn Engel @ 2007-12-02 20:45 ` Ingo Molnar 2007-12-02 21:08 ` Jörn Engel 2007-12-02 21:10 ` Jörn Engel 0 siblings, 2 replies; 268+ messages in thread From: Ingo Molnar @ 2007-12-02 20:45 UTC (permalink / raw) To: Jörn Engel Cc: Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw * Jörn Engel <joern@logfs.org> wrote: > > oprofile helps if you can reliably reproduce the slowdown in a loop > > or for a long amount of time, with lots of CPU utilization - and > > then it's also lower overhead. The tracer can be used to capture > > rare or complex events, and gives the full flow control and what is > > happening within the kernel. > > Such a trace would be useful indeed. But so far the patch has only > given me grief and nothing remotely like useful output. Maybe I > should simply use the complete -rt patch instead of debugging the > broken-out latency-tracer patch. to capture that trace i did not use -rt, i just patched latest -git with: http://people.redhat.com/mingo/latency-tracing-patches/latency-tracing-v2.6.24-rc3.combo.patch (this has your fixes included already) have done: echo 1 > /proc/sys/kernel/mcount_enabled and have run: ./trace-cmd sleep 1 > trace.txt http://people.redhat.com/mingo/latency-tracing-patches/trace-cmd.c to capture a 1 second trace of what the system is doing. I think your troubles are due to running it within a qemu guest - that is not a typical utilization so you are on unchartered waters. Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-12-02 20:45 ` Ingo Molnar @ 2007-12-02 21:08 ` Jörn Engel 2007-12-02 21:10 ` Jörn Engel 1 sibling, 0 replies; 268+ messages in thread From: Jörn Engel @ 2007-12-02 21:08 UTC (permalink / raw) To: Ingo Molnar Cc: Jörn Engel, Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw On Sun, 2 December 2007 21:45:59 +0100, Ingo Molnar wrote: > > to capture a 1 second trace of what the system is doing. I think your > troubles are due to running it within a qemu guest - that is not a > typical utilization so you are on unchartered waters. Looks like it. Guess I'll switch to something else for the moment. Jörn -- Linux is more the core point of a concept that surrounds "open source" which, in turn, is based on a false concept. This concept is that people actually want to look at source code. -- Rob Enderle ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-12-02 20:45 ` Ingo Molnar 2007-12-02 21:08 ` Jörn Engel @ 2007-12-02 21:10 ` Jörn Engel 2007-12-02 21:19 ` Ingo Molnar 1 sibling, 1 reply; 268+ messages in thread From: Jörn Engel @ 2007-12-02 21:10 UTC (permalink / raw) To: Ingo Molnar Cc: Jörn Engel, Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw On Sun, 2 December 2007 21:45:59 +0100, Ingo Molnar wrote: > > to capture that trace i did not use -rt, i just patched latest -git > with: > > http://people.redhat.com/mingo/latency-tracing-patches/latency-tracing-v2.6.24-rc3.combo.patch > > (this has your fixes included already) > > have done: > > echo 1 > /proc/sys/kernel/mcount_enabled > > and have run: > > ./trace-cmd sleep 1 > trace.txt > > http://people.redhat.com/mingo/latency-tracing-patches/trace-cmd.c > > to capture a 1 second trace of what the system is doing. I think your > troubles are due to running it within a qemu guest - that is not a > typical utilization so you are on unchartered waters. Maybe one more thing: can you send me the config you used for the setup above? I'd like to know whether qemu or my config is to blame. Jörn -- Eighty percent of success is showing up. -- Woody Allen ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-12-02 21:10 ` Jörn Engel @ 2007-12-02 21:19 ` Ingo Molnar 2007-12-03 0:57 ` Jörn Engel 0 siblings, 1 reply; 268+ messages in thread From: Ingo Molnar @ 2007-12-02 21:19 UTC (permalink / raw) To: Jörn Engel Cc: Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw [-- Attachment #1: Type: text/plain, Size: 535 bytes --] * Jörn Engel <joern@logfs.org> wrote: > > ./trace-cmd sleep 1 > trace.txt > > > > http://people.redhat.com/mingo/latency-tracing-patches/trace-cmd.c > > > > to capture a 1 second trace of what the system is doing. I think > > your troubles are due to running it within a qemu guest - that is > > not a typical utilization so you are on unchartered waters. > > Maybe one more thing: can you send me the config you used for the > setup above? I'd like to know whether qemu or my config is to blame. sure - attached. Ingo [-- Attachment #2: config --] [-- Type: text/plain, Size: 72625 bytes --] # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc3 # Sun Dec 2 22:06:36 2007 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y # CONFIG_TASK_XACCT is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=20 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_LBD=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_LSF=y # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_PREEMPT_NOTIFIERS=y # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_X86_VSMP is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT_GUEST is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set CONFIG_M686=y # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_XADD=y CONFIG_X86_PPRO_FENCE=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_NR_CPUS=8 # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set # CONFIG_X86_MCE_P4THERMAL is not set CONFIG_VM86=y CONFIG_TOSHIBA=m CONFIG_I8K=m # CONFIG_X86_REBOOTFIXUPS is not set CONFIG_MICROCODE=m CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_PAGE_OFFSET=0xC0000000 CONFIG_HIGHMEM=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_SPARSEMEM_STATIC=y # CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_NR_QUICK=1 CONFIG_VIRT_TO_BUS=y # CONFIG_HIGHPTE is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_EFI=y CONFIG_IRQBALANCE=y CONFIG_BOOT_IOREMAP=y # CONFIG_SECCOMP is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_KEXEC=y # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x100000 # CONFIG_RELOCATABLE is not set CONFIG_PHYSICAL_ALIGN=0x100000 CONFIG_HOTPLUG_CPU=y CONFIG_COMPAT_VDSO=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y # # Power management options # CONFIG_PM=y CONFIG_PM_LEGACY=y # CONFIG_PM_DEBUG is not set CONFIG_PM_SLEEP_SMP=y CONFIG_PM_SLEEP=y CONFIG_SUSPEND_SMP_POSSIBLE=y CONFIG_SUSPEND=y CONFIG_HIBERNATION_SMP_POSSIBLE=y # CONFIG_HIBERNATION is not set CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_PROCFS=y CONFIG_ACPI_PROCFS_POWER=y CONFIG_ACPI_PROC_EVENT=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=y CONFIG_ACPI_DOCK=m # CONFIG_ACPI_BAY is not set CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_ACPI_THERMAL=y CONFIG_ACPI_ASUS=m CONFIG_ACPI_TOSHIBA=m CONFIG_ACPI_BLACKLIST_YEAR=1999 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y CONFIG_ACPI_CONTAINER=y CONFIG_ACPI_SBS=m CONFIG_APM=y # CONFIG_APM_IGNORE_USER_SUSPEND is not set # CONFIG_APM_DO_ENABLE is not set CONFIG_APM_CPU_IDLE=y # CONFIG_APM_DISPLAY_BLANK is not set # CONFIG_APM_ALLOW_INTS is not set # CONFIG_APM_REAL_MODE_POWER_OFF is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y CONFIG_CPU_FREQ_DEBUG=y CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m # # CPUFreq processor drivers # CONFIG_X86_ACPI_CPUFREQ=m # CONFIG_X86_POWERNOW_K6 is not set CONFIG_X86_POWERNOW_K7=y CONFIG_X86_POWERNOW_K7_ACPI=y CONFIG_X86_POWERNOW_K8=y CONFIG_X86_POWERNOW_K8_ACPI=y # CONFIG_X86_GX_SUSPMOD is not set CONFIG_X86_SPEEDSTEP_CENTRINO=y CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y CONFIG_X86_SPEEDSTEP_ICH=y CONFIG_X86_SPEEDSTEP_SMI=y CONFIG_X86_P4_CLOCKMOD=m # CONFIG_X86_CPUFREQ_NFORCE2 is not set CONFIG_X86_LONGRUN=y # CONFIG_X86_LONGHAUL is not set # CONFIG_X86_E_POWERSAVER is not set # # shared options # # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set CONFIG_X86_SPEEDSTEP_LIB=y # CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK is not set # CONFIG_CPU_IDLE is not set # # Bus options (PCI etc.) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_DOMAINS=y CONFIG_PCIEPORTBUS=y CONFIG_HOTPLUG_PCI_PCIE=m CONFIG_PCIEAER=y CONFIG_ARCH_SUPPORTS_MSI=y CONFIG_PCI_MSI=y CONFIG_PCI_LEGACY=y # CONFIG_PCI_DEBUG is not set CONFIG_HT_IRQ=y CONFIG_ISA_DMA_API=y CONFIG_ISA=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set CONFIG_K8_NB=y CONFIG_PCCARD=y # CONFIG_PCMCIA_DEBUG is not set CONFIG_PCMCIA=y CONFIG_PCMCIA_LOAD_CIS=y CONFIG_PCMCIA_IOCTL=y CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_YENTA=y CONFIG_YENTA_O2=y CONFIG_YENTA_RICOH=y CONFIG_YENTA_TI=y CONFIG_YENTA_ENE_TUNE=y CONFIG_YENTA_TOSHIBA=y CONFIG_PD6729=m CONFIG_I82092=m # CONFIG_I82365 is not set # CONFIG_TCIC is not set CONFIG_PCMCIA_PROBE=y CONFIG_PCCARD_NONSTATIC=y CONFIG_HOTPLUG_PCI=y CONFIG_HOTPLUG_PCI_FAKE=m CONFIG_HOTPLUG_PCI_COMPAQ=m # CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set CONFIG_HOTPLUG_PCI_IBM=m CONFIG_HOTPLUG_PCI_ACPI=m CONFIG_HOTPLUG_PCI_ACPI_IBM=m # CONFIG_HOTPLUG_PCI_CPCI is not set # CONFIG_HOTPLUG_PCI_SHPC is not set # # Executable file formats / Emulations # CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_MISC=y # # Networking # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_XFRM=y CONFIG_XFRM_USER=y # CONFIG_XFRM_SUB_POLICY is not set # CONFIG_XFRM_MIGRATE is not set CONFIG_NET_KEY=y # CONFIG_NET_KEY_MIGRATE is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_ASK_IP_FIB_HASH=y # CONFIG_IP_FIB_TRIE is not set CONFIG_IP_FIB_HASH=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m CONFIG_INET_XFRM_TUNNEL=m CONFIG_INET_TUNNEL=m CONFIG_INET_XFRM_MODE_TRANSPORT=m CONFIG_INET_XFRM_MODE_TUNNEL=m CONFIG_INET_XFRM_MODE_BEET=m CONFIG_INET_LRO=m CONFIG_INET_DIAG=m CONFIG_INET_TCP_DIAG=m CONFIG_TCP_CONG_ADVANCED=y CONFIG_TCP_CONG_BIC=y CONFIG_TCP_CONG_CUBIC=m CONFIG_TCP_CONG_WESTWOOD=m CONFIG_TCP_CONG_HTCP=m CONFIG_TCP_CONG_HSTCP=m CONFIG_TCP_CONG_HYBLA=m CONFIG_TCP_CONG_VEGAS=m CONFIG_TCP_CONG_SCALABLE=m CONFIG_TCP_CONG_LP=m CONFIG_TCP_CONG_VENO=m # CONFIG_TCP_CONG_YEAH is not set # CONFIG_TCP_CONG_ILLINOIS is not set CONFIG_DEFAULT_BIC=y # CONFIG_DEFAULT_CUBIC is not set # CONFIG_DEFAULT_HTCP is not set # CONFIG_DEFAULT_VEGAS is not set # CONFIG_DEFAULT_WESTWOOD is not set # CONFIG_DEFAULT_RENO is not set CONFIG_DEFAULT_TCP_CONG="bic" CONFIG_TCP_MD5SIG=y CONFIG_IP_VS=m # CONFIG_IP_VS_DEBUG is not set CONFIG_IP_VS_TAB_BITS=12 # # IPVS transport protocol load balancing support # CONFIG_IP_VS_PROTO_TCP=y CONFIG_IP_VS_PROTO_UDP=y CONFIG_IP_VS_PROTO_ESP=y CONFIG_IP_VS_PROTO_AH=y # # IPVS scheduler # CONFIG_IP_VS_RR=m CONFIG_IP_VS_WRR=m CONFIG_IP_VS_LC=m CONFIG_IP_VS_WLC=m CONFIG_IP_VS_LBLC=m CONFIG_IP_VS_LBLCR=m CONFIG_IP_VS_DH=m CONFIG_IP_VS_SH=m CONFIG_IP_VS_SED=m CONFIG_IP_VS_NQ=m # # IPVS application helper # CONFIG_IP_VS_FTP=m CONFIG_IPV6=m CONFIG_IPV6_PRIVACY=y CONFIG_IPV6_ROUTER_PREF=y CONFIG_IPV6_ROUTE_INFO=y # CONFIG_IPV6_OPTIMISTIC_DAD is not set CONFIG_INET6_AH=m CONFIG_INET6_ESP=m CONFIG_INET6_IPCOMP=m # CONFIG_IPV6_MIP6 is not set CONFIG_INET6_XFRM_TUNNEL=m CONFIG_INET6_TUNNEL=m CONFIG_INET6_XFRM_MODE_TRANSPORT=m CONFIG_INET6_XFRM_MODE_TUNNEL=m CONFIG_INET6_XFRM_MODE_BEET=m CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m CONFIG_IPV6_SIT=m CONFIG_IPV6_TUNNEL=m # CONFIG_IPV6_MULTIPLE_TABLES is not set CONFIG_NETLABEL=y CONFIG_NETWORK_SECMARK=y CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_BRIDGE_NETFILTER=y # # Core Netfilter Configuration # CONFIG_NETFILTER_NETLINK=y CONFIG_NETFILTER_NETLINK_QUEUE=y CONFIG_NETFILTER_NETLINK_LOG=y CONFIG_NF_CONNTRACK_ENABLED=m CONFIG_NF_CONNTRACK=m CONFIG_NF_CT_ACCT=y CONFIG_NF_CONNTRACK_MARK=y CONFIG_NF_CONNTRACK_SECMARK=y CONFIG_NF_CONNTRACK_EVENTS=y CONFIG_NF_CT_PROTO_GRE=m CONFIG_NF_CT_PROTO_SCTP=m # CONFIG_NF_CT_PROTO_UDPLITE is not set CONFIG_NF_CONNTRACK_AMANDA=m CONFIG_NF_CONNTRACK_FTP=m CONFIG_NF_CONNTRACK_H323=m CONFIG_NF_CONNTRACK_IRC=m CONFIG_NF_CONNTRACK_NETBIOS_NS=m CONFIG_NF_CONNTRACK_PPTP=m # CONFIG_NF_CONNTRACK_SANE is not set CONFIG_NF_CONNTRACK_SIP=m CONFIG_NF_CONNTRACK_TFTP=m CONFIG_NF_CT_NETLINK=m CONFIG_NETFILTER_XTABLES=m CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m CONFIG_NETFILTER_XT_TARGET_CONNMARK=m CONFIG_NETFILTER_XT_TARGET_DSCP=m CONFIG_NETFILTER_XT_TARGET_MARK=m CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m CONFIG_NETFILTER_XT_TARGET_NFLOG=m CONFIG_NETFILTER_XT_TARGET_NOTRACK=m # CONFIG_NETFILTER_XT_TARGET_TRACE is not set CONFIG_NETFILTER_XT_TARGET_SECMARK=m CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m # CONFIG_NETFILTER_XT_TARGET_TCPMSS is not set CONFIG_NETFILTER_XT_MATCH_COMMENT=m CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m # CONFIG_NETFILTER_XT_MATCH_CONNLIMIT is not set CONFIG_NETFILTER_XT_MATCH_CONNMARK=m CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m CONFIG_NETFILTER_XT_MATCH_DCCP=m CONFIG_NETFILTER_XT_MATCH_DSCP=m CONFIG_NETFILTER_XT_MATCH_ESP=m CONFIG_NETFILTER_XT_MATCH_HELPER=m CONFIG_NETFILTER_XT_MATCH_LENGTH=m CONFIG_NETFILTER_XT_MATCH_LIMIT=m CONFIG_NETFILTER_XT_MATCH_MAC=m CONFIG_NETFILTER_XT_MATCH_MARK=m CONFIG_NETFILTER_XT_MATCH_POLICY=m CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m CONFIG_NETFILTER_XT_MATCH_QUOTA=m CONFIG_NETFILTER_XT_MATCH_REALM=m CONFIG_NETFILTER_XT_MATCH_SCTP=m CONFIG_NETFILTER_XT_MATCH_STATE=m CONFIG_NETFILTER_XT_MATCH_STATISTIC=m CONFIG_NETFILTER_XT_MATCH_STRING=m CONFIG_NETFILTER_XT_MATCH_TCPMSS=m # CONFIG_NETFILTER_XT_MATCH_TIME is not set # CONFIG_NETFILTER_XT_MATCH_U32 is not set CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m # # IP: Netfilter Configuration # CONFIG_NF_CONNTRACK_IPV4=m CONFIG_NF_CONNTRACK_PROC_COMPAT=y CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_AH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_NF_NAT=m CONFIG_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m CONFIG_NF_NAT_SNMP_BASIC=m CONFIG_NF_NAT_PROTO_GRE=m CONFIG_NF_NAT_FTP=m CONFIG_NF_NAT_IRC=m CONFIG_NF_NAT_TFTP=m CONFIG_NF_NAT_AMANDA=m CONFIG_NF_NAT_PPTP=m CONFIG_NF_NAT_H323=m CONFIG_NF_NAT_SIP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_TTL=m CONFIG_IP_NF_TARGET_CLUSTERIP=m CONFIG_IP_NF_RAW=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m # # IPv6: Netfilter Configuration (EXPERIMENTAL) # CONFIG_NF_CONNTRACK_IPV6=m CONFIG_IP6_NF_QUEUE=m CONFIG_IP6_NF_IPTABLES=m CONFIG_IP6_NF_MATCH_RT=m CONFIG_IP6_NF_MATCH_OPTS=m CONFIG_IP6_NF_MATCH_FRAG=m CONFIG_IP6_NF_MATCH_HL=m CONFIG_IP6_NF_MATCH_OWNER=m CONFIG_IP6_NF_MATCH_IPV6HEADER=m CONFIG_IP6_NF_MATCH_AH=m # CONFIG_IP6_NF_MATCH_MH is not set CONFIG_IP6_NF_MATCH_EUI64=m CONFIG_IP6_NF_FILTER=m CONFIG_IP6_NF_TARGET_LOG=m CONFIG_IP6_NF_TARGET_REJECT=m CONFIG_IP6_NF_MANGLE=m CONFIG_IP6_NF_TARGET_HL=m CONFIG_IP6_NF_RAW=m # # DECnet: Netfilter Configuration # # CONFIG_DECNET_NF_GRABULATOR is not set # # Bridge: Netfilter Configuration # CONFIG_BRIDGE_NF_EBTABLES=m CONFIG_BRIDGE_EBT_BROUTE=m CONFIG_BRIDGE_EBT_T_FILTER=m CONFIG_BRIDGE_EBT_T_NAT=m CONFIG_BRIDGE_EBT_802_3=m CONFIG_BRIDGE_EBT_AMONG=m CONFIG_BRIDGE_EBT_ARP=m CONFIG_BRIDGE_EBT_IP=m CONFIG_BRIDGE_EBT_LIMIT=m CONFIG_BRIDGE_EBT_MARK=m CONFIG_BRIDGE_EBT_PKTTYPE=m CONFIG_BRIDGE_EBT_STP=m CONFIG_BRIDGE_EBT_VLAN=m CONFIG_BRIDGE_EBT_ARPREPLY=m CONFIG_BRIDGE_EBT_DNAT=m CONFIG_BRIDGE_EBT_MARK_T=m CONFIG_BRIDGE_EBT_REDIRECT=m CONFIG_BRIDGE_EBT_SNAT=m CONFIG_BRIDGE_EBT_LOG=m CONFIG_BRIDGE_EBT_ULOG=m CONFIG_IP_DCCP=m CONFIG_INET_DCCP_DIAG=m CONFIG_IP_DCCP_ACKVEC=y # # DCCP CCIDs Configuration (EXPERIMENTAL) # CONFIG_IP_DCCP_CCID2=m # CONFIG_IP_DCCP_CCID2_DEBUG is not set CONFIG_IP_DCCP_CCID3=m CONFIG_IP_DCCP_TFRC_LIB=m # CONFIG_IP_DCCP_CCID3_DEBUG is not set CONFIG_IP_DCCP_CCID3_RTO=100 # # DCCP Kernel Hacking # # CONFIG_IP_DCCP_DEBUG is not set # CONFIG_NET_DCCPPROBE is not set CONFIG_IP_SCTP=m # CONFIG_SCTP_DBG_MSG is not set # CONFIG_SCTP_DBG_OBJCNT is not set # CONFIG_SCTP_HMAC_NONE is not set # CONFIG_SCTP_HMAC_SHA1 is not set CONFIG_SCTP_HMAC_MD5=y CONFIG_TIPC=m # CONFIG_TIPC_ADVANCED is not set # CONFIG_TIPC_DEBUG is not set CONFIG_ATM=m CONFIG_ATM_CLIP=m # CONFIG_ATM_CLIP_NO_ICMP is not set CONFIG_ATM_LANE=m # CONFIG_ATM_MPOA is not set CONFIG_ATM_BR2684=m # CONFIG_ATM_BR2684_IPFILTER is not set CONFIG_BRIDGE=m CONFIG_VLAN_8021Q=m CONFIG_DECNET=m CONFIG_DECNET_ROUTER=y CONFIG_LLC=y # CONFIG_LLC2 is not set CONFIG_IPX=m # CONFIG_IPX_INTERN is not set CONFIG_ATALK=m CONFIG_DEV_APPLETALK=m # CONFIG_LTPC is not set # CONFIG_COPS is not set CONFIG_IPDDP=m CONFIG_IPDDP_ENCAP=y CONFIG_IPDDP_DECAP=y # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_ECONET is not set CONFIG_WAN_ROUTER=m CONFIG_NET_SCHED=y # # Queueing/Scheduling # CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_ATM=m CONFIG_NET_SCH_PRIO=m # CONFIG_NET_SCH_RR is not set CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_INGRESS=m # # Classification # CONFIG_NET_CLS=y CONFIG_NET_CLS_BASIC=m CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_CLS_U32_PERF=y CONFIG_CLS_U32_MARK=y CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_EMATCH=y CONFIG_NET_EMATCH_STACK=32 CONFIG_NET_EMATCH_CMP=m CONFIG_NET_EMATCH_NBYTE=m CONFIG_NET_EMATCH_U32=m CONFIG_NET_EMATCH_META=m CONFIG_NET_EMATCH_TEXT=m CONFIG_NET_CLS_ACT=y CONFIG_NET_ACT_POLICE=m CONFIG_NET_ACT_GACT=m CONFIG_GACT_PROB=y CONFIG_NET_ACT_MIRRED=m CONFIG_NET_ACT_IPT=m # CONFIG_NET_ACT_NAT is not set CONFIG_NET_ACT_PEDIT=m CONFIG_NET_ACT_SIMP=m # CONFIG_NET_CLS_POLICE is not set CONFIG_NET_CLS_IND=y CONFIG_NET_SCH_FIFO=y # # Network testing # CONFIG_NET_PKTGEN=m # CONFIG_NET_TCPPROBE is not set # CONFIG_HAMRADIO is not set CONFIG_IRDA=m # # IrDA protocols # CONFIG_IRLAN=m CONFIG_IRNET=m CONFIG_IRCOMM=m # CONFIG_IRDA_ULTRA is not set # # IrDA options # CONFIG_IRDA_CACHE_LAST_LSAP=y CONFIG_IRDA_FAST_RR=y # CONFIG_IRDA_DEBUG is not set # # Infrared-port device drivers # # # SIR device drivers # CONFIG_IRTTY_SIR=m # # Dongle support # CONFIG_DONGLE=y CONFIG_ESI_DONGLE=m CONFIG_ACTISYS_DONGLE=m CONFIG_TEKRAM_DONGLE=m CONFIG_TOIM3232_DONGLE=m CONFIG_LITELINK_DONGLE=m CONFIG_MA600_DONGLE=m CONFIG_GIRBIL_DONGLE=m CONFIG_MCP2120_DONGLE=m CONFIG_OLD_BELKIN_DONGLE=m CONFIG_ACT200L_DONGLE=m # CONFIG_KINGSUN_DONGLE is not set # CONFIG_KSDAZZLE_DONGLE is not set # CONFIG_KS959_DONGLE is not set # # Old SIR device drivers # # # Old Serial dongle support # # # FIR device drivers # CONFIG_USB_IRDA=m CONFIG_SIGMATEL_FIR=m CONFIG_NSC_FIR=m CONFIG_WINBOND_FIR=m CONFIG_TOSHIBA_FIR=m CONFIG_SMC_IRCC_FIR=m CONFIG_ALI_FIR=m CONFIG_VLSI_FIR=m CONFIG_VIA_FIR=m CONFIG_MCS_FIR=m CONFIG_BT=m CONFIG_BT_L2CAP=m CONFIG_BT_SCO=m CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=m CONFIG_BT_BNEP_MC_FILTER=y CONFIG_BT_BNEP_PROTO_FILTER=y CONFIG_BT_CMTP=m CONFIG_BT_HIDP=m # # Bluetooth device drivers # CONFIG_BT_HCIUSB=m CONFIG_BT_HCIUSB_SCO=y # CONFIG_BT_HCIBTSDIO is not set CONFIG_BT_HCIUART=m CONFIG_BT_HCIUART_H4=y CONFIG_BT_HCIUART_BCSP=y # CONFIG_BT_HCIUART_LL is not set CONFIG_BT_HCIBCM203X=m CONFIG_BT_HCIBPA10X=m CONFIG_BT_HCIBFUSB=m CONFIG_BT_HCIDTL1=m CONFIG_BT_HCIBT3C=m CONFIG_BT_HCIBLUECARD=m CONFIG_BT_HCIBTUART=m CONFIG_BT_HCIVHCI=m # CONFIG_AF_RXRPC is not set CONFIG_FIB_RULES=y # # Wireless # # CONFIG_CFG80211 is not set CONFIG_WIRELESS_EXT=y # CONFIG_MAC80211 is not set CONFIG_IEEE80211=m # CONFIG_IEEE80211_DEBUG is not set CONFIG_IEEE80211_CRYPT_WEP=m CONFIG_IEEE80211_CRYPT_CCMP=m CONFIG_IEEE80211_CRYPT_TKIP=m CONFIG_IEEE80211_SOFTMAC=m CONFIG_IEEE80211_SOFTMAC_DEBUG=y # CONFIG_RFKILL is not set # CONFIG_NET_9P is not set # # Device Drivers # # # Generic Driver Options # CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y # CONFIG_MTD is not set CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_SERIAL=m # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set CONFIG_PARPORT_PC_PCMCIA=m # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_AX88796 is not set CONFIG_PARPORT_1284=y CONFIG_PARPORT_NOT_PC=y CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # CONFIG_ISAPNP=y # CONFIG_PNPBIOS is not set CONFIG_PNPACPI=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_FD=m # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set CONFIG_BLK_CPQ_DA=y CONFIG_BLK_CPQ_CISS_DA=m CONFIG_CISS_SCSI_TAPE=y CONFIG_BLK_DEV_DAC960=m CONFIG_BLK_DEV_UMEM=m # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_SX8=m CONFIG_BLK_DEV_UB=m CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=16384 CONFIG_BLK_DEV_RAM_BLOCKSIZE=4096 CONFIG_CDROM_PKTCDVD=m CONFIG_CDROM_PKTCDVD_BUFFERS=8 # CONFIG_CDROM_PKTCDVD_WCACHE is not set CONFIG_ATA_OVER_ETH=m CONFIG_MISC_DEVICES=y CONFIG_IBM_ASM=m # CONFIG_PHANTOM is not set # CONFIG_EEPROM_93CX6 is not set # CONFIG_SGI_IOC4 is not set CONFIG_TIFM_CORE=m CONFIG_TIFM_7XX1=m # CONFIG_ASUS_LAPTOP is not set # CONFIG_FUJITSU_LAPTOP is not set CONFIG_MSI_LAPTOP=m # CONFIG_SONY_LAPTOP is not set # CONFIG_THINKPAD_ACPI is not set # CONFIG_IDE is not set # # SCSI device support # CONFIG_RAID_ATTRS=m CONFIG_SCSI=y CONFIG_SCSI_DMA=y CONFIG_SCSI_TGT=m CONFIG_SCSI_NETLINK=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=m # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=y CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=y CONFIG_CHR_DEV_SCH=y # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y # CONFIG_SCSI_SCAN_ASYNC is not set CONFIG_SCSI_WAIT_SCAN=m # # SCSI Transports # CONFIG_SCSI_SPI_ATTRS=y CONFIG_SCSI_FC_ATTRS=m # CONFIG_SCSI_FC_TGT_ATTRS is not set CONFIG_SCSI_ISCSI_ATTRS=m CONFIG_SCSI_SAS_ATTRS=y CONFIG_SCSI_SAS_LIBSAS=y # CONFIG_SCSI_SAS_ATA is not set # CONFIG_SCSI_SAS_LIBSAS_DEBUG is not set CONFIG_SCSI_SRP_ATTRS=m # CONFIG_SCSI_SRP_TGT_ATTRS is not set CONFIG_SCSI_LOWLEVEL=y CONFIG_ISCSI_TCP=m CONFIG_BLK_DEV_3W_XXXX_RAID=m CONFIG_SCSI_3W_9XXX=m # CONFIG_SCSI_7000FASST is not set CONFIG_SCSI_ACARD=m CONFIG_SCSI_AHA152X=m CONFIG_SCSI_AHA1542=m CONFIG_SCSI_AACRAID=m CONFIG_SCSI_AIC7XXX=y CONFIG_AIC7XXX_CMDS_PER_DEVICE=4 CONFIG_AIC7XXX_RESET_DELAY_MS=1000 # CONFIG_AIC7XXX_DEBUG_ENABLE is not set CONFIG_AIC7XXX_DEBUG_MASK=0 # CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set CONFIG_SCSI_AIC7XXX_OLD=m CONFIG_SCSI_AIC79XX=y CONFIG_AIC79XX_CMDS_PER_DEVICE=4 CONFIG_AIC79XX_RESET_DELAY_MS=1000 # CONFIG_AIC79XX_DEBUG_ENABLE is not set CONFIG_AIC79XX_DEBUG_MASK=0 # CONFIG_AIC79XX_REG_PRETTY_PRINT is not set CONFIG_SCSI_AIC94XX=y # CONFIG_AIC94XX_DEBUG is not set # CONFIG_SCSI_DPT_I2O is not set CONFIG_SCSI_ADVANSYS=m # CONFIG_SCSI_IN2000 is not set CONFIG_SCSI_ARCMSR=m # CONFIG_SCSI_ARCMSR_AER is not set CONFIG_MEGARAID_NEWGEN=y CONFIG_MEGARAID_MM=m CONFIG_MEGARAID_MAILBOX=m CONFIG_MEGARAID_LEGACY=m CONFIG_MEGARAID_SAS=m CONFIG_SCSI_HPTIOP=m CONFIG_SCSI_BUSLOGIC=m # CONFIG_SCSI_OMIT_FLASHPOINT is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set CONFIG_SCSI_FUTURE_DOMAIN=m CONFIG_SCSI_GDTH=m # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set CONFIG_SCSI_IPS=m CONFIG_SCSI_INITIO=m CONFIG_SCSI_INIA100=m CONFIG_SCSI_PPA=m CONFIG_SCSI_IMM=m # CONFIG_SCSI_IZIP_EPP16 is not set # CONFIG_SCSI_IZIP_SLOW_CTR is not set # CONFIG_SCSI_NCR53C406A is not set CONFIG_SCSI_STEX=m CONFIG_SCSI_SYM53C8XX_2=m CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16 CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64 CONFIG_SCSI_SYM53C8XX_MMIO=y # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set CONFIG_SCSI_QLOGIC_1280=m CONFIG_SCSI_QLA_FC=m CONFIG_SCSI_QLA_ISCSI=m CONFIG_SCSI_LPFC=m # CONFIG_SCSI_SEAGATE is not set # CONFIG_SCSI_SYM53C416 is not set CONFIG_SCSI_DC395x=m CONFIG_SCSI_DC390T=m # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set CONFIG_SCSI_SRP=m # CONFIG_SCSI_LOWLEVEL_PCMCIA is not set CONFIG_ATA=y # CONFIG_ATA_NONSTANDARD is not set CONFIG_ATA_ACPI=y CONFIG_SATA_AHCI=y CONFIG_SATA_SVW=y CONFIG_ATA_PIIX=y CONFIG_SATA_MV=y CONFIG_SATA_NV=y CONFIG_PDC_ADMA=y CONFIG_SATA_QSTOR=y CONFIG_SATA_PROMISE=y CONFIG_SATA_SX4=y CONFIG_SATA_SIL=y CONFIG_SATA_SIL24=y CONFIG_SATA_SIS=y CONFIG_SATA_ULI=y CONFIG_SATA_VIA=y CONFIG_SATA_VITESSE=y # CONFIG_SATA_INIC162X is not set # CONFIG_PATA_ACPI is not set CONFIG_PATA_ALI=y CONFIG_PATA_AMD=y CONFIG_PATA_ARTOP=y CONFIG_PATA_ATIIXP=y # CONFIG_PATA_CMD640_PCI is not set CONFIG_PATA_CMD64X=y CONFIG_PATA_CS5520=y CONFIG_PATA_CS5530=y CONFIG_PATA_CS5535=y # CONFIG_PATA_CS5536 is not set CONFIG_PATA_CYPRESS=y CONFIG_PATA_EFAR=y CONFIG_ATA_GENERIC=y CONFIG_PATA_HPT366=y CONFIG_PATA_HPT37X=y CONFIG_PATA_HPT3X2N=y CONFIG_PATA_HPT3X3=y # CONFIG_PATA_HPT3X3_DMA is not set # CONFIG_PATA_ISAPNP is not set CONFIG_PATA_IT821X=y # CONFIG_PATA_IT8213 is not set CONFIG_PATA_JMICRON=y CONFIG_PATA_LEGACY=m CONFIG_PATA_TRIFLEX=y CONFIG_PATA_MARVELL=y CONFIG_PATA_MPIIX=y CONFIG_PATA_OLDPIIX=y CONFIG_PATA_NETCELL=y CONFIG_PATA_NS87410=y # CONFIG_PATA_NS87415 is not set CONFIG_PATA_OPTI=y CONFIG_PATA_OPTIDMA=y # CONFIG_PATA_PCMCIA is not set CONFIG_PATA_PDC_OLD=y CONFIG_PATA_QDI=y CONFIG_PATA_RADISYS=y CONFIG_PATA_RZ1000=y CONFIG_PATA_SC1200=y CONFIG_PATA_SERVERWORKS=y CONFIG_PATA_PDC2027X=y CONFIG_PATA_SIL680=y CONFIG_PATA_SIS=y CONFIG_PATA_VIA=y CONFIG_PATA_WINBOND=y CONFIG_PATA_WINBOND_VLB=y CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID10=m CONFIG_MD_RAID456=m CONFIG_MD_RAID5_RESHAPE=y CONFIG_MD_MULTIPATH=m CONFIG_MD_FAULTY=m CONFIG_BLK_DEV_DM=m # CONFIG_DM_DEBUG is not set CONFIG_DM_CRYPT=m CONFIG_DM_SNAPSHOT=m CONFIG_DM_MIRROR=m CONFIG_DM_ZERO=m CONFIG_DM_MULTIPATH=m CONFIG_DM_MULTIPATH_EMC=m # CONFIG_DM_MULTIPATH_RDAC is not set # CONFIG_DM_MULTIPATH_HP is not set # CONFIG_DM_DELAY is not set # CONFIG_DM_UEVENT is not set CONFIG_FUSION=y CONFIG_FUSION_SPI=m CONFIG_FUSION_FC=m CONFIG_FUSION_SAS=m CONFIG_FUSION_MAX_SGE=40 CONFIG_FUSION_CTL=m CONFIG_FUSION_LAN=m # CONFIG_FUSION_LOGGING is not set # # IEEE 1394 (FireWire) support # # CONFIG_FIREWIRE is not set CONFIG_IEEE1394=m # # Subsystem Options # # CONFIG_IEEE1394_VERBOSEDEBUG is not set # # Controllers # CONFIG_IEEE1394_PCILYNX=m CONFIG_IEEE1394_OHCI1394=m # # Protocols # CONFIG_IEEE1394_VIDEO1394=m CONFIG_IEEE1394_SBP2=m # CONFIG_IEEE1394_SBP2_PHYS_DMA is not set CONFIG_IEEE1394_ETH1394_ROM_ENTRY=y CONFIG_IEEE1394_ETH1394=m CONFIG_IEEE1394_DV1394=m CONFIG_IEEE1394_RAWIO=m CONFIG_I2O=m # CONFIG_I2O_LCT_NOTIFY_ON_CHANGES is not set CONFIG_I2O_EXT_ADAPTEC=y CONFIG_I2O_CONFIG=m CONFIG_I2O_CONFIG_OLD_IOCTL=y CONFIG_I2O_BUS=m CONFIG_I2O_BLOCK=m CONFIG_I2O_SCSI=m CONFIG_I2O_PROC=m # CONFIG_MACINTOSH_DRIVERS is not set CONFIG_NETDEVICES=y # CONFIG_NETDEVICES_MULTIQUEUE is not set CONFIG_IFB=m CONFIG_DUMMY=m CONFIG_BONDING=m # CONFIG_MACVLAN is not set CONFIG_EQUALIZER=m CONFIG_TUN=m # CONFIG_VETH is not set CONFIG_NET_SB1000=m # CONFIG_IP1000 is not set # CONFIG_ARCNET is not set CONFIG_PHYLIB=m # # MII PHY device drivers # CONFIG_MARVELL_PHY=m CONFIG_DAVICOM_PHY=m CONFIG_QSEMI_PHY=m CONFIG_LXT_PHY=m CONFIG_CICADA_PHY=m CONFIG_VITESSE_PHY=m CONFIG_SMSC_PHY=m CONFIG_BROADCOM_PHY=m # CONFIG_ICPLUS_PHY is not set CONFIG_FIXED_PHY=m CONFIG_FIXED_MII_10_FDX=y CONFIG_FIXED_MII_100_FDX=y # CONFIG_FIXED_MII_1000_FDX is not set CONFIG_FIXED_MII_AMNT=1 # CONFIG_MDIO_BITBANG is not set CONFIG_NET_ETHERNET=y CONFIG_MII=y CONFIG_HAPPYMEAL=m CONFIG_SUNGEM=m CONFIG_CASSINI=m CONFIG_NET_VENDOR_3COM=y # CONFIG_EL1 is not set # CONFIG_EL2 is not set # CONFIG_ELPLUS is not set # CONFIG_EL16 is not set CONFIG_EL3=m # CONFIG_3C515 is not set CONFIG_VORTEX=m CONFIG_TYPHOON=m # CONFIG_LANCE is not set CONFIG_NET_VENDOR_SMC=y # CONFIG_WD80x3 is not set CONFIG_ULTRA=m # CONFIG_SMC9194 is not set # CONFIG_NET_VENDOR_RACAL is not set CONFIG_NET_TULIP=y CONFIG_DE2104X=m CONFIG_TULIP=m # CONFIG_TULIP_MWI is not set CONFIG_TULIP_MMIO=y # CONFIG_TULIP_NAPI is not set CONFIG_DE4X5=m CONFIG_WINBOND_840=m CONFIG_DM9102=m CONFIG_ULI526X=m CONFIG_PCMCIA_XIRCOM=m # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set CONFIG_NET_ISA=y # CONFIG_E2100 is not set CONFIG_EWRK3=m # CONFIG_EEXPRESS is not set # CONFIG_EEXPRESS_PRO is not set # CONFIG_HPLAN_PLUS is not set # CONFIG_HPLAN is not set # CONFIG_LP486E is not set # CONFIG_ETH16I is not set CONFIG_NE2000=m # CONFIG_ZNET is not set # CONFIG_SEEQ8005 is not set # CONFIG_IBM_NEW_EMAC_ZMII is not set # CONFIG_IBM_NEW_EMAC_RGMII is not set # CONFIG_IBM_NEW_EMAC_TAH is not set # CONFIG_IBM_NEW_EMAC_EMAC4 is not set CONFIG_NET_PCI=y CONFIG_PCNET32=m CONFIG_PCNET32_NAPI=y CONFIG_AMD8111_ETH=m CONFIG_AMD8111E_NAPI=y CONFIG_ADAPTEC_STARFIRE=m CONFIG_ADAPTEC_STARFIRE_NAPI=y # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set CONFIG_B44=m CONFIG_B44_PCI_AUTOSELECT=y CONFIG_B44_PCICORE_AUTOSELECT=y CONFIG_B44_PCI=y CONFIG_FORCEDETH=y CONFIG_FORCEDETH_NAPI=y # CONFIG_CS89x0 is not set # CONFIG_EEPRO100 is not set CONFIG_E100=y CONFIG_FEALNX=m CONFIG_NATSEMI=m CONFIG_NE2K_PCI=m CONFIG_8139CP=y CONFIG_8139TOO=y CONFIG_8139TOO_PIO=y # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_8139_OLD_RX_RESET is not set CONFIG_SIS900=m CONFIG_EPIC100=m CONFIG_SUNDANCE=m # CONFIG_SUNDANCE_MMIO is not set CONFIG_TLAN=m CONFIG_VIA_RHINE=m CONFIG_VIA_RHINE_MMIO=y CONFIG_VIA_RHINE_NAPI=y # CONFIG_SC92031 is not set CONFIG_NET_POCKET=y CONFIG_ATP=m CONFIG_DE600=m CONFIG_DE620=m CONFIG_NETDEV_1000=y CONFIG_ACENIC=m # CONFIG_ACENIC_OMIT_TIGON_I is not set CONFIG_DL2K=m CONFIG_E1000=y CONFIG_E1000_NAPI=y # CONFIG_E1000_DISABLE_PACKET_SPLIT is not set # CONFIG_E1000E is not set CONFIG_NS83820=m CONFIG_HAMACHI=m CONFIG_YELLOWFIN=m CONFIG_R8169=m CONFIG_R8169_NAPI=y CONFIG_R8169_VLAN=y CONFIG_SIS190=m CONFIG_SKGE=y # CONFIG_SKGE_DEBUG is not set CONFIG_SKY2=m # CONFIG_SKY2_DEBUG is not set # CONFIG_SK98LIN is not set CONFIG_VIA_VELOCITY=m CONFIG_TIGON3=y CONFIG_BNX2=m CONFIG_QLA3XXX=m # CONFIG_ATL1 is not set CONFIG_NETDEV_10000=y CONFIG_CHELSIO_T1=m CONFIG_CHELSIO_T1_1G=y CONFIG_CHELSIO_T1_NAPI=y # CONFIG_CHELSIO_T3 is not set # CONFIG_IXGBE is not set CONFIG_IXGB=m CONFIG_IXGB_NAPI=y CONFIG_S2IO=m CONFIG_S2IO_NAPI=y CONFIG_MYRI10GE=m CONFIG_NETXEN_NIC=m # CONFIG_NIU is not set # CONFIG_MLX4_CORE is not set # CONFIG_TEHUTI is not set CONFIG_TR=y # CONFIG_IBMTR is not set CONFIG_IBMOL=m CONFIG_IBMLS=m CONFIG_3C359=m # CONFIG_TMS380TR is not set # CONFIG_SMCTR is not set # # Wireless LAN # # CONFIG_WLAN_PRE80211 is not set # CONFIG_WLAN_80211 is not set # # USB Network Adapters # CONFIG_USB_CATC=m CONFIG_USB_KAWETH=m CONFIG_USB_PEGASUS=m CONFIG_USB_RTL8150=m CONFIG_USB_USBNET=m CONFIG_USB_NET_AX8817X=m CONFIG_USB_NET_CDCETHER=m # CONFIG_USB_NET_DM9601 is not set CONFIG_USB_NET_GL620A=m CONFIG_USB_NET_NET1080=m CONFIG_USB_NET_PLUSB=m CONFIG_USB_NET_MCS7830=m CONFIG_USB_NET_RNDIS_HOST=m CONFIG_USB_NET_CDC_SUBSET=m CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_BELKIN=y CONFIG_USB_ARMLINUX=y CONFIG_USB_EPSON2888=y # CONFIG_USB_KC2190 is not set CONFIG_USB_NET_ZAURUS=m CONFIG_NET_PCMCIA=y CONFIG_PCMCIA_3C589=m CONFIG_PCMCIA_3C574=m CONFIG_PCMCIA_FMVJ18X=m CONFIG_PCMCIA_PCNET=m CONFIG_PCMCIA_NMCLAN=m CONFIG_PCMCIA_SMC91C92=m CONFIG_PCMCIA_XIRC2PS=m CONFIG_PCMCIA_AXNET=m CONFIG_PCMCIA_IBMTR=m # CONFIG_WAN is not set CONFIG_ATM_DRIVERS=y # CONFIG_ATM_DUMMY is not set CONFIG_ATM_TCP=m CONFIG_ATM_LANAI=m CONFIG_ATM_ENI=m # CONFIG_ATM_ENI_DEBUG is not set # CONFIG_ATM_ENI_TUNE_BURST is not set CONFIG_ATM_FIRESTREAM=m # CONFIG_ATM_ZATM is not set CONFIG_ATM_NICSTAR=m # CONFIG_ATM_NICSTAR_USE_SUNI is not set # CONFIG_ATM_NICSTAR_USE_IDT77105 is not set CONFIG_ATM_IDT77252=m # CONFIG_ATM_IDT77252_DEBUG is not set # CONFIG_ATM_IDT77252_RCV_ALL is not set CONFIG_ATM_IDT77252_USE_SUNI=y CONFIG_ATM_AMBASSADOR=m # CONFIG_ATM_AMBASSADOR_DEBUG is not set CONFIG_ATM_HORIZON=m # CONFIG_ATM_HORIZON_DEBUG is not set # CONFIG_ATM_IA is not set CONFIG_ATM_FORE200E_MAYBE=m # CONFIG_ATM_FORE200E_PCA is not set CONFIG_ATM_HE=m # CONFIG_ATM_HE_USE_SUNI is not set CONFIG_FDDI=y # CONFIG_DEFXX is not set CONFIG_SKFP=m # CONFIG_HIPPI is not set CONFIG_PLIP=m CONFIG_PPP=m CONFIG_PPP_MULTILINK=y CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m # CONFIG_PPP_BSDCOMP is not set CONFIG_PPP_MPPE=m CONFIG_PPPOE=m CONFIG_PPPOATM=m # CONFIG_PPPOL2TP is not set CONFIG_SLIP=m CONFIG_SLIP_COMPRESSED=y CONFIG_SLHC=m CONFIG_SLIP_SMART=y # CONFIG_SLIP_MODE_SLIP6 is not set CONFIG_NET_FC=y # CONFIG_SHAPER is not set CONFIG_NETCONSOLE=y # CONFIG_NETCONSOLE_DYNAMIC is not set CONFIG_NETPOLL=y # CONFIG_NETPOLL_TRAP is not set CONFIG_NET_POLL_CONTROLLER=y CONFIG_ISDN=m CONFIG_ISDN_I4L=m CONFIG_ISDN_PPP=y CONFIG_ISDN_PPP_VJ=y CONFIG_ISDN_MPP=y CONFIG_IPPP_FILTER=y # CONFIG_ISDN_PPP_BSDCOMP is not set CONFIG_ISDN_AUDIO=y CONFIG_ISDN_TTY_FAX=y # # ISDN feature submodules # CONFIG_ISDN_DIVERSION=m # # ISDN4Linux hardware drivers # # # Passive cards # CONFIG_ISDN_DRV_HISAX=m # # D-channel protocol features # CONFIG_HISAX_EURO=y CONFIG_DE_AOC=y CONFIG_HISAX_NO_SENDCOMPLETE=y CONFIG_HISAX_NO_LLC=y CONFIG_HISAX_NO_KEYPAD=y CONFIG_HISAX_1TR6=y CONFIG_HISAX_NI1=y CONFIG_HISAX_MAX_CARDS=8 # # HiSax supported cards # # CONFIG_HISAX_16_0 is not set CONFIG_HISAX_16_3=y CONFIG_HISAX_TELESPCI=y CONFIG_HISAX_S0BOX=y # CONFIG_HISAX_AVM_A1 is not set CONFIG_HISAX_FRITZPCI=y CONFIG_HISAX_AVM_A1_PCMCIA=y CONFIG_HISAX_ELSA=y # CONFIG_HISAX_IX1MICROR2 is not set CONFIG_HISAX_DIEHLDIVA=y # CONFIG_HISAX_ASUSCOM is not set # CONFIG_HISAX_TELEINT is not set # CONFIG_HISAX_HFCS is not set CONFIG_HISAX_SEDLBAUER=y # CONFIG_HISAX_SPORTSTER is not set # CONFIG_HISAX_MIC is not set CONFIG_HISAX_NETJET=y CONFIG_HISAX_NETJET_U=y CONFIG_HISAX_NICCY=y # CONFIG_HISAX_ISURF is not set # CONFIG_HISAX_HSTSAPHIR is not set CONFIG_HISAX_BKM_A4T=y CONFIG_HISAX_SCT_QUADRO=y CONFIG_HISAX_GAZEL=y CONFIG_HISAX_HFC_PCI=y CONFIG_HISAX_W6692=y CONFIG_HISAX_HFC_SX=y CONFIG_HISAX_ENTERNOW_PCI=y # CONFIG_HISAX_DEBUG is not set # # HiSax PCMCIA card service modules # CONFIG_HISAX_SEDLBAUER_CS=m CONFIG_HISAX_ELSA_CS=m CONFIG_HISAX_AVM_A1_CS=m CONFIG_HISAX_TELES_CS=m # # HiSax sub driver modules # CONFIG_HISAX_ST5481=m # CONFIG_HISAX_HFCUSB is not set CONFIG_HISAX_HFC4S8S=m CONFIG_HISAX_FRITZ_PCIPNP=m CONFIG_HISAX_HDLC=y # # Active cards # # CONFIG_ISDN_DRV_ICN is not set # CONFIG_ISDN_DRV_PCBIT is not set # CONFIG_ISDN_DRV_SC is not set # CONFIG_ISDN_DRV_ACT2000 is not set CONFIG_ISDN_DRV_GIGASET=m CONFIG_GIGASET_BASE=m CONFIG_GIGASET_M105=m # CONFIG_GIGASET_M101 is not set # CONFIG_GIGASET_DEBUG is not set # CONFIG_GIGASET_UNDOCREQ is not set CONFIG_ISDN_CAPI=m CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON=y CONFIG_CAPI_TRACE=y CONFIG_ISDN_CAPI_MIDDLEWARE=y CONFIG_ISDN_CAPI_CAPI20=m CONFIG_ISDN_CAPI_CAPIFS_BOOL=y CONFIG_ISDN_CAPI_CAPIFS=m CONFIG_ISDN_CAPI_CAPIDRV=m # # CAPI hardware drivers # CONFIG_CAPI_AVM=y # CONFIG_ISDN_DRV_AVMB1_B1ISA is not set CONFIG_ISDN_DRV_AVMB1_B1PCI=m CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y # CONFIG_ISDN_DRV_AVMB1_T1ISA is not set CONFIG_ISDN_DRV_AVMB1_B1PCMCIA=m CONFIG_ISDN_DRV_AVMB1_AVM_CS=m CONFIG_ISDN_DRV_AVMB1_T1PCI=m CONFIG_ISDN_DRV_AVMB1_C4=m CONFIG_CAPI_EICON=y CONFIG_ISDN_DIVAS=m CONFIG_ISDN_DIVAS_BRIPCI=y CONFIG_ISDN_DIVAS_PRIPCI=y CONFIG_ISDN_DIVAS_DIVACAPI=m CONFIG_ISDN_DIVAS_USERIDI=m CONFIG_ISDN_DIVAS_MAINT=m # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y CONFIG_INPUT_FF_MEMLESS=y CONFIG_INPUT_POLLDEV=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_JOYDEV=m CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set CONFIG_KEYBOARD_STOWAWAY=m CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_MOUSE_PS2_ALPS=y CONFIG_MOUSE_PS2_LOGIPS2PP=y CONFIG_MOUSE_PS2_SYNAPTICS=y CONFIG_MOUSE_PS2_LIFEBOOK=y CONFIG_MOUSE_PS2_TRACKPOINT=y # CONFIG_MOUSE_PS2_TOUCHKIT is not set CONFIG_MOUSE_SERIAL=m # CONFIG_MOUSE_APPLETOUCH is not set # CONFIG_MOUSE_INPORT is not set # CONFIG_MOUSE_LOGIBM is not set # CONFIG_MOUSE_PC110PAD is not set CONFIG_MOUSE_VSXXXAA=m CONFIG_INPUT_JOYSTICK=y CONFIG_JOYSTICK_ANALOG=m CONFIG_JOYSTICK_A3D=m CONFIG_JOYSTICK_ADI=m CONFIG_JOYSTICK_COBRA=m CONFIG_JOYSTICK_GF2K=m CONFIG_JOYSTICK_GRIP=m CONFIG_JOYSTICK_GRIP_MP=m CONFIG_JOYSTICK_GUILLEMOT=m CONFIG_JOYSTICK_INTERACT=m CONFIG_JOYSTICK_SIDEWINDER=m CONFIG_JOYSTICK_TMDC=m CONFIG_JOYSTICK_IFORCE=m CONFIG_JOYSTICK_IFORCE_USB=y CONFIG_JOYSTICK_IFORCE_232=y CONFIG_JOYSTICK_WARRIOR=m CONFIG_JOYSTICK_MAGELLAN=m CONFIG_JOYSTICK_SPACEORB=m CONFIG_JOYSTICK_SPACEBALL=m CONFIG_JOYSTICK_STINGER=m CONFIG_JOYSTICK_TWIDJOY=m CONFIG_JOYSTICK_DB9=m CONFIG_JOYSTICK_GAMECON=m CONFIG_JOYSTICK_TURBOGRAFX=m CONFIG_JOYSTICK_JOYDUMP=m # CONFIG_JOYSTICK_XPAD is not set # CONFIG_INPUT_TABLET is not set CONFIG_INPUT_TOUCHSCREEN=y # CONFIG_TOUCHSCREEN_FUJITSU is not set CONFIG_TOUCHSCREEN_GUNZE=m CONFIG_TOUCHSCREEN_ELO=m CONFIG_TOUCHSCREEN_MTOUCH=m CONFIG_TOUCHSCREEN_MK712=m CONFIG_TOUCHSCREEN_PENMOUNT=m CONFIG_TOUCHSCREEN_TOUCHRIGHT=m CONFIG_TOUCHSCREEN_TOUCHWIN=m CONFIG_TOUCHSCREEN_UCB1400=m # CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=m CONFIG_INPUT_WISTRON_BTNS=m # CONFIG_INPUT_ATLAS_BTNS is not set # CONFIG_INPUT_ATI_REMOTE is not set # CONFIG_INPUT_ATI_REMOTE2 is not set # CONFIG_INPUT_KEYSPAN_REMOTE is not set # CONFIG_INPUT_POWERMATE is not set # CONFIG_INPUT_YEALINK is not set CONFIG_INPUT_UINPUT=m # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y CONFIG_SERIO_RAW=m CONFIG_GAMEPORT=m CONFIG_GAMEPORT_NS558=m CONFIG_GAMEPORT_L4=m CONFIG_GAMEPORT_EMU10K1=m CONFIG_GAMEPORT_FM801=m # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_VT_HW_CONSOLE_BINDING=y CONFIG_SERIAL_NONSTANDARD=y # CONFIG_COMPUTONE is not set # CONFIG_ROCKETPORT is not set CONFIG_CYCLADES=m # CONFIG_CYZ_INTR is not set # CONFIG_DIGIEPCA is not set # CONFIG_ESPSERIAL is not set # CONFIG_MOXA_INTELLIO is not set # CONFIG_MOXA_SMARTIO is not set CONFIG_MOXA_SMARTIO_NEW=m # CONFIG_ISI is not set CONFIG_SYNCLINK=m CONFIG_SYNCLINKMP=m CONFIG_SYNCLINK_GT=m CONFIG_N_HDLC=m # CONFIG_SPECIALIX is not set # CONFIG_SX is not set # CONFIG_RIO is not set # CONFIG_STALDRV is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_PNP=y CONFIG_SERIAL_8250_CS=m CONFIG_SERIAL_8250_NR_UARTS=32 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y # CONFIG_SERIAL_8250_FOURPORT is not set # CONFIG_SERIAL_8250_ACCENT is not set # CONFIG_SERIAL_8250_BOCA is not set CONFIG_SERIAL_8250_EXAR_ST16C554=m # CONFIG_SERIAL_8250_HUB6 is not set CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_8250_DETECT_IRQ=y CONFIG_SERIAL_8250_RSA=y # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_SERIAL_JSM=m CONFIG_UNIX98_PTYS=y # CONFIG_LEGACY_PTYS is not set CONFIG_PRINTER=m CONFIG_LP_CONSOLE=y CONFIG_PPDEV=m CONFIG_TIPAR=m CONFIG_IPMI_HANDLER=m # CONFIG_IPMI_PANIC_EVENT is not set CONFIG_IPMI_DEVICE_INTERFACE=m CONFIG_IPMI_SI=m CONFIG_IPMI_WATCHDOG=m CONFIG_IPMI_POWEROFF=m CONFIG_HW_RANDOM=y CONFIG_HW_RANDOM_INTEL=m CONFIG_HW_RANDOM_AMD=m CONFIG_HW_RANDOM_GEODE=m CONFIG_HW_RANDOM_VIA=m CONFIG_NVRAM=y CONFIG_RTC=y CONFIG_DTLK=m CONFIG_R3964=m # CONFIG_APPLICOM is not set CONFIG_SONYPI=m # # PCMCIA character devices # # CONFIG_SYNCLINK_CS is not set CONFIG_CARDMAN_4000=m CONFIG_CARDMAN_4040=m # CONFIG_MWAVE is not set # CONFIG_PC8736x_GPIO is not set # CONFIG_NSC_GPIO is not set # CONFIG_CS5535_GPIO is not set CONFIG_RAW_DRIVER=y CONFIG_MAX_RAW_DEVS=8192 CONFIG_HPET=y # CONFIG_HPET_RTC_IRQ is not set CONFIG_HPET_MMAP=y CONFIG_HANGCHECK_TIMER=m CONFIG_TCG_TPM=m CONFIG_TCG_TIS=m CONFIG_TCG_NSC=m CONFIG_TCG_ATMEL=m CONFIG_TCG_INFINEON=m # CONFIG_TELCLOCK is not set CONFIG_DEVPORT=y CONFIG_I2C=m CONFIG_I2C_BOARDINFO=y CONFIG_I2C_CHARDEV=m # # I2C Algorithms # CONFIG_I2C_ALGOBIT=m CONFIG_I2C_ALGOPCF=m CONFIG_I2C_ALGOPCA=m # # I2C Hardware Bus support # CONFIG_I2C_ALI1535=m CONFIG_I2C_ALI1563=m CONFIG_I2C_ALI15X3=m CONFIG_I2C_AMD756=m CONFIG_I2C_AMD756_S4882=m CONFIG_I2C_AMD8111=m CONFIG_I2C_I801=m CONFIG_I2C_I810=m CONFIG_I2C_PIIX4=m CONFIG_I2C_NFORCE2=m # CONFIG_I2C_OCORES is not set CONFIG_I2C_PARPORT=m CONFIG_I2C_PARPORT_LIGHT=m CONFIG_I2C_PROSAVAGE=m CONFIG_I2C_SAVAGE4=m # CONFIG_I2C_SIMTEC is not set # CONFIG_SCx200_ACB is not set CONFIG_I2C_SIS5595=m CONFIG_I2C_SIS630=m CONFIG_I2C_SIS96X=m # CONFIG_I2C_TAOS_EVM is not set CONFIG_I2C_STUB=m # CONFIG_I2C_TINY_USB is not set CONFIG_I2C_VIA=m CONFIG_I2C_VIAPRO=m CONFIG_I2C_VOODOO3=m CONFIG_I2C_PCA_ISA=m # # Miscellaneous I2C Chip support # CONFIG_SENSORS_DS1337=m CONFIG_SENSORS_DS1374=m # CONFIG_DS1682 is not set CONFIG_SENSORS_EEPROM=m CONFIG_SENSORS_PCF8574=m CONFIG_SENSORS_PCA9539=m CONFIG_SENSORS_PCF8591=m CONFIG_SENSORS_MAX6875=m # CONFIG_SENSORS_TSL2550 is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # # SPI support # # CONFIG_SPI is not set # CONFIG_SPI_MASTER is not set CONFIG_W1=m CONFIG_W1_CON=y # # 1-wire Bus Masters # CONFIG_W1_MASTER_MATROX=m CONFIG_W1_MASTER_DS2490=m CONFIG_W1_MASTER_DS2482=m # # 1-wire Slaves # CONFIG_W1_SLAVE_THERM=m CONFIG_W1_SLAVE_SMEM=m CONFIG_W1_SLAVE_DS2433=m CONFIG_W1_SLAVE_DS2433_CRC=y # CONFIG_W1_SLAVE_DS2760 is not set CONFIG_POWER_SUPPLY=m # CONFIG_POWER_SUPPLY_DEBUG is not set # CONFIG_PDA_POWER is not set # CONFIG_BATTERY_DS2760 is not set CONFIG_HWMON=m CONFIG_HWMON_VID=m CONFIG_SENSORS_ABITUGURU=m # CONFIG_SENSORS_ABITUGURU3 is not set # CONFIG_SENSORS_AD7418 is not set CONFIG_SENSORS_ADM1021=m CONFIG_SENSORS_ADM1025=m CONFIG_SENSORS_ADM1026=m # CONFIG_SENSORS_ADM1029 is not set CONFIG_SENSORS_ADM1031=m CONFIG_SENSORS_ADM9240=m # CONFIG_SENSORS_ADT7470 is not set CONFIG_SENSORS_K8TEMP=m CONFIG_SENSORS_ASB100=m CONFIG_SENSORS_ATXP1=m CONFIG_SENSORS_DS1621=m # CONFIG_SENSORS_I5K_AMB is not set CONFIG_SENSORS_F71805F=m # CONFIG_SENSORS_F71882FG is not set # CONFIG_SENSORS_F75375S is not set CONFIG_SENSORS_FSCHER=m CONFIG_SENSORS_FSCPOS=m # CONFIG_SENSORS_FSCHMD is not set CONFIG_SENSORS_GL518SM=m CONFIG_SENSORS_GL520SM=m # CONFIG_SENSORS_CORETEMP is not set # CONFIG_SENSORS_IBMPEX is not set CONFIG_SENSORS_IT87=m CONFIG_SENSORS_LM63=m CONFIG_SENSORS_LM75=m CONFIG_SENSORS_LM77=m CONFIG_SENSORS_LM78=m CONFIG_SENSORS_LM80=m CONFIG_SENSORS_LM83=m CONFIG_SENSORS_LM85=m CONFIG_SENSORS_LM87=m CONFIG_SENSORS_LM90=m CONFIG_SENSORS_LM92=m # CONFIG_SENSORS_LM93 is not set CONFIG_SENSORS_MAX1619=m # CONFIG_SENSORS_MAX6650 is not set CONFIG_SENSORS_PC87360=m CONFIG_SENSORS_PC87427=m CONFIG_SENSORS_SIS5595=m # CONFIG_SENSORS_DME1737 is not set CONFIG_SENSORS_SMSC47M1=m CONFIG_SENSORS_SMSC47M192=m CONFIG_SENSORS_SMSC47B397=m # CONFIG_SENSORS_THMC50 is not set CONFIG_SENSORS_VIA686A=m CONFIG_SENSORS_VT1211=m CONFIG_SENSORS_VT8231=m CONFIG_SENSORS_W83781D=m CONFIG_SENSORS_W83791D=m CONFIG_SENSORS_W83792D=m CONFIG_SENSORS_W83793=m CONFIG_SENSORS_W83L785TS=m CONFIG_SENSORS_W83627HF=m CONFIG_SENSORS_W83627EHF=m CONFIG_SENSORS_HDAPS=m # CONFIG_SENSORS_APPLESMC is not set # CONFIG_HWMON_DEBUG_CHIP is not set CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set # # Watchdog Device Drivers # CONFIG_SOFT_WATCHDOG=m # CONFIG_ACQUIRE_WDT is not set # CONFIG_ADVANTECH_WDT is not set CONFIG_ALIM1535_WDT=m CONFIG_ALIM7101_WDT=m # CONFIG_SC520_WDT is not set # CONFIG_EUROTECH_WDT is not set # CONFIG_IB700_WDT is not set CONFIG_IBMASR=m # CONFIG_WAFER_WDT is not set CONFIG_I6300ESB_WDT=m CONFIG_ITCO_WDT=m CONFIG_ITCO_VENDOR_SUPPORT=y # CONFIG_SC1200_WDT is not set CONFIG_PC87413_WDT=m # CONFIG_60XX_WDT is not set # CONFIG_SBC8360_WDT is not set # CONFIG_CPU5_WDT is not set # CONFIG_SMSC37B787_WDT is not set CONFIG_W83627HF_WDT=m CONFIG_W83697HF_WDT=m CONFIG_W83877F_WDT=m CONFIG_W83977F_WDT=m CONFIG_MACHZ_WDT=m # CONFIG_SBC_EPX_C3_WATCHDOG is not set # # ISA-based Watchdog Cards # # CONFIG_PCWATCHDOG is not set # CONFIG_MIXCOMWD is not set # CONFIG_WDT is not set # # PCI-based Watchdog Cards # CONFIG_PCIPCWATCHDOG=m CONFIG_WDTPCI=m CONFIG_WDT_501_PCI=y # # USB-based Watchdog Cards # CONFIG_USBPCWATCHDOG=m # # Sonics Silicon Backplane # CONFIG_SSB_POSSIBLE=y CONFIG_SSB=m CONFIG_SSB_PCIHOST_POSSIBLE=y CONFIG_SSB_PCIHOST=y CONFIG_SSB_PCMCIAHOST_POSSIBLE=y # CONFIG_SSB_PCMCIAHOST is not set # CONFIG_SSB_DEBUG is not set CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y CONFIG_SSB_DRIVER_PCICORE=y # # Multifunction device drivers # # CONFIG_MFD_SM501 is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set CONFIG_DVB_CORE=m # CONFIG_DVB_CORE_ATTACH is not set CONFIG_DVB_CAPTURE_DRIVERS=y # # Supported SAA7146 based PCI Adapters # # # Supported USB Adapters # CONFIG_DVB_USB=m # CONFIG_DVB_USB_DEBUG is not set CONFIG_DVB_USB_A800=m CONFIG_DVB_USB_DIBUSB_MB=m # CONFIG_DVB_USB_DIBUSB_MB_FAULTY is not set CONFIG_DVB_USB_DIBUSB_MC=m CONFIG_DVB_USB_DIB0700=m CONFIG_DVB_USB_UMT_010=m CONFIG_DVB_USB_CXUSB=m # CONFIG_DVB_USB_M920X is not set # CONFIG_DVB_USB_GL861 is not set # CONFIG_DVB_USB_AU6610 is not set CONFIG_DVB_USB_DIGITV=m CONFIG_DVB_USB_VP7045=m CONFIG_DVB_USB_VP702X=m CONFIG_DVB_USB_GP8PSK=m CONFIG_DVB_USB_NOVA_T_USB2=m CONFIG_DVB_USB_TTUSB2=m CONFIG_DVB_USB_DTT200U=m # CONFIG_DVB_USB_OPERA1 is not set # CONFIG_DVB_USB_AF9005 is not set CONFIG_DVB_TTUSB_BUDGET=m CONFIG_DVB_TTUSB_DEC=m CONFIG_DVB_CINERGYT2=m CONFIG_DVB_CINERGYT2_TUNING=y CONFIG_DVB_CINERGYT2_STREAM_URB_COUNT=32 CONFIG_DVB_CINERGYT2_STREAM_BUF_SIZE=512 CONFIG_DVB_CINERGYT2_QUERY_INTERVAL=250 CONFIG_DVB_CINERGYT2_ENABLE_RC_INPUT_DEVICE=y CONFIG_DVB_CINERGYT2_RC_QUERY_INTERVAL=100 # # Supported FlexCopII (B2C2) Adapters # CONFIG_DVB_B2C2_FLEXCOP=m CONFIG_DVB_B2C2_FLEXCOP_PCI=m CONFIG_DVB_B2C2_FLEXCOP_USB=m # CONFIG_DVB_B2C2_FLEXCOP_DEBUG is not set # # Supported BT878 Adapters # # # Supported Pluto2 Adapters # CONFIG_DVB_PLUTO2=m # # Supported DVB Frontends # # # Customise DVB Frontends # # CONFIG_DVB_FE_CUSTOMISE is not set # # DVB-S (satellite) frontends # CONFIG_DVB_STV0299=m CONFIG_DVB_CX24110=m CONFIG_DVB_CX24123=m CONFIG_DVB_TDA8083=m CONFIG_DVB_MT312=m CONFIG_DVB_VES1X93=m CONFIG_DVB_S5H1420=m CONFIG_DVB_TDA10086=m # # DVB-T (terrestrial) frontends # CONFIG_DVB_SP8870=m CONFIG_DVB_SP887X=m CONFIG_DVB_CX22700=m CONFIG_DVB_CX22702=m CONFIG_DVB_L64781=m CONFIG_DVB_TDA1004X=m CONFIG_DVB_NXT6000=m CONFIG_DVB_MT352=m CONFIG_DVB_ZL10353=m CONFIG_DVB_DIB3000MB=m CONFIG_DVB_DIB3000MC=m CONFIG_DVB_DIB7000M=m CONFIG_DVB_DIB7000P=m # # DVB-C (cable) frontends # CONFIG_DVB_VES1820=m CONFIG_DVB_TDA10021=m CONFIG_DVB_TDA10023=m CONFIG_DVB_STV0297=m # # ATSC (North American/Korean Terrestrial/Cable DTV) frontends # CONFIG_DVB_NXT200X=m CONFIG_DVB_OR51211=m CONFIG_DVB_OR51132=m CONFIG_DVB_BCM3510=m CONFIG_DVB_LGDT330X=m # CONFIG_DVB_S5H1409 is not set # # Tuners/PLL support # CONFIG_DVB_PLL=m CONFIG_DVB_TDA826X=m CONFIG_DVB_TDA827X=m # CONFIG_DVB_TUNER_QT1010 is not set CONFIG_DVB_TUNER_MT2060=m CONFIG_DVB_TUNER_MT2266=m # CONFIG_DVB_TUNER_MT2131 is not set CONFIG_DVB_TUNER_DIB0070=m # # Miscellaneous devices # CONFIG_DVB_LNBP21=m CONFIG_DVB_ISL6421=m CONFIG_DVB_TUA6100=m CONFIG_DAB=y CONFIG_USB_DABUSB=m # # Graphics support # CONFIG_AGP=y CONFIG_AGP_ALI=y CONFIG_AGP_ATI=y CONFIG_AGP_AMD=y CONFIG_AGP_AMD64=y CONFIG_AGP_INTEL=y CONFIG_AGP_NVIDIA=y CONFIG_AGP_SIS=y CONFIG_AGP_SWORKS=y CONFIG_AGP_VIA=y CONFIG_AGP_EFFICEON=y CONFIG_DRM=y # CONFIG_DRM_TDFX is not set CONFIG_DRM_R128=m CONFIG_DRM_RADEON=m CONFIG_DRM_I810=y # CONFIG_DRM_I830 is not set CONFIG_DRM_I915=y CONFIG_DRM_MGA=m # CONFIG_DRM_SIS is not set CONFIG_DRM_VIA=m CONFIG_DRM_SAVAGE=m CONFIG_VGASTATE=m CONFIG_VIDEO_OUTPUT_CONTROL=m CONFIG_FB=y # CONFIG_FIRMWARE_EDID is not set CONFIG_FB_DDC=m CONFIG_FB_CFB_FILLRECT=m CONFIG_FB_CFB_COPYAREA=m CONFIG_FB_CFB_IMAGEBLIT=m # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set # CONFIG_FB_SYS_FILLRECT is not set # CONFIG_FB_SYS_COPYAREA is not set # CONFIG_FB_SYS_IMAGEBLIT is not set # CONFIG_FB_SYS_FOPS is not set CONFIG_FB_DEFERRED_IO=y # CONFIG_FB_SVGALIB is not set # CONFIG_FB_MACMODES is not set CONFIG_FB_BACKLIGHT=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y # # Frame buffer hardware drivers # # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ARC is not set # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set # CONFIG_FB_VGA16 is not set # CONFIG_FB_UVESA is not set # CONFIG_FB_VESA is not set # CONFIG_FB_EFI is not set # CONFIG_FB_IMAC is not set # CONFIG_FB_HECUBA is not set # CONFIG_FB_HGA is not set # CONFIG_FB_S1D13XXX is not set CONFIG_FB_NVIDIA=m CONFIG_FB_NVIDIA_I2C=y # CONFIG_FB_NVIDIA_DEBUG is not set CONFIG_FB_NVIDIA_BACKLIGHT=y CONFIG_FB_RIVA=m # CONFIG_FB_RIVA_I2C is not set # CONFIG_FB_RIVA_DEBUG is not set CONFIG_FB_RIVA_BACKLIGHT=y CONFIG_FB_I810=m CONFIG_FB_I810_GTF=y CONFIG_FB_I810_I2C=y # CONFIG_FB_LE80578 is not set CONFIG_FB_INTEL=m # CONFIG_FB_INTEL_DEBUG is not set CONFIG_FB_INTEL_I2C=y CONFIG_FB_MATROX=m CONFIG_FB_MATROX_MILLENIUM=y CONFIG_FB_MATROX_MYSTIQUE=y CONFIG_FB_MATROX_G=y CONFIG_FB_MATROX_I2C=m CONFIG_FB_MATROX_MAVEN=m CONFIG_FB_MATROX_MULTIHEAD=y # CONFIG_FB_RADEON is not set CONFIG_FB_ATY128=m CONFIG_FB_ATY128_BACKLIGHT=y CONFIG_FB_ATY=m CONFIG_FB_ATY_CT=y CONFIG_FB_ATY_GENERIC_LCD=y CONFIG_FB_ATY_GX=y CONFIG_FB_ATY_BACKLIGHT=y # CONFIG_FB_S3 is not set CONFIG_FB_SAVAGE=m CONFIG_FB_SAVAGE_I2C=y CONFIG_FB_SAVAGE_ACCEL=y # CONFIG_FB_SIS is not set CONFIG_FB_NEOMAGIC=m CONFIG_FB_KYRO=m CONFIG_FB_3DFX=m CONFIG_FB_3DFX_ACCEL=y CONFIG_FB_VOODOO1=m # CONFIG_FB_VT8623 is not set # CONFIG_FB_CYBLA is not set CONFIG_FB_TRIDENT=m CONFIG_FB_TRIDENT_ACCEL=y # CONFIG_FB_ARK is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_GEODE is not set # CONFIG_FB_VIRTUAL is not set CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=m CONFIG_BACKLIGHT_CLASS_DEVICE=y # CONFIG_BACKLIGHT_CORGI is not set # CONFIG_BACKLIGHT_PROGEAR is not set # # Display device support # # CONFIG_DISPLAY_SUPPORT is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_VGACON_SOFT_SCROLLBACK=y CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64 CONFIG_VIDEO_SELECT=y # CONFIG_MDA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y # CONFIG_FRAMEBUFFER_CONSOLE is not set CONFIG_FONT_8x16=y CONFIG_LOGO=y # CONFIG_LOGO_LINUX_MONO is not set # CONFIG_LOGO_LINUX_VGA16 is not set CONFIG_LOGO_LINUX_CLUT224=y # # Sound # CONFIG_SOUND=y # # Advanced Linux Sound Architecture # CONFIG_SND=y CONFIG_SND_TIMER=y CONFIG_SND_PCM=y CONFIG_SND_HWDEP=y CONFIG_SND_RAWMIDI=y CONFIG_SND_SEQUENCER=y CONFIG_SND_SEQ_DUMMY=y CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=y CONFIG_SND_PCM_OSS=y CONFIG_SND_PCM_OSS_PLUGINS=y CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_RTCTIMER=y CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y # CONFIG_SND_DYNAMIC_MINORS is not set CONFIG_SND_SUPPORT_OLD_API=y CONFIG_SND_VERBOSE_PROCFS=y # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # CONFIG_SND_MPU401_UART=y CONFIG_SND_OPL3_LIB=m CONFIG_SND_VX_LIB=m CONFIG_SND_AC97_CODEC=y CONFIG_SND_DUMMY=m # CONFIG_SND_VIRMIDI is not set # CONFIG_SND_MTPAV is not set # CONFIG_SND_MTS64 is not set # CONFIG_SND_SERIAL_U16550 is not set CONFIG_SND_MPU401=y # CONFIG_SND_PORTMAN2X4 is not set CONFIG_SND_SB_COMMON=m # # ISA devices # # CONFIG_SND_ADLIB is not set # CONFIG_SND_AD1816A is not set # CONFIG_SND_AD1848 is not set # CONFIG_SND_ALS100 is not set # CONFIG_SND_AZT2320 is not set # CONFIG_SND_CMI8330 is not set # CONFIG_SND_CS4231 is not set # CONFIG_SND_CS4232 is not set # CONFIG_SND_CS4236 is not set # CONFIG_SND_DT019X is not set # CONFIG_SND_ES968 is not set # CONFIG_SND_ES1688 is not set # CONFIG_SND_ES18XX is not set # CONFIG_SND_SC6000 is not set # CONFIG_SND_GUSCLASSIC is not set # CONFIG_SND_GUSEXTREME is not set # CONFIG_SND_GUSMAX is not set # CONFIG_SND_INTERWAVE is not set # CONFIG_SND_INTERWAVE_STB is not set # CONFIG_SND_OPL3SA2 is not set # CONFIG_SND_OPTI92X_AD1848 is not set # CONFIG_SND_OPTI92X_CS4231 is not set # CONFIG_SND_OPTI93X is not set # CONFIG_SND_MIRO is not set # CONFIG_SND_SB8 is not set # CONFIG_SND_SB16 is not set # CONFIG_SND_SBAWE is not set # CONFIG_SND_SGALAXY is not set # CONFIG_SND_SSCAPE is not set # CONFIG_SND_WAVEFRONT is not set # # PCI devices # CONFIG_SND_AD1889=m # CONFIG_SND_ALS300 is not set CONFIG_SND_ALS4000=m CONFIG_SND_ALI5451=m CONFIG_SND_ATIIXP=m CONFIG_SND_ATIIXP_MODEM=m CONFIG_SND_AU8810=m CONFIG_SND_AU8820=m CONFIG_SND_AU8830=m CONFIG_SND_AZT3328=m CONFIG_SND_BT87X=m # CONFIG_SND_BT87X_OVERCLOCK is not set CONFIG_SND_CA0106=m CONFIG_SND_CMIPCI=m CONFIG_SND_CS4281=m CONFIG_SND_CS46XX=m CONFIG_SND_CS46XX_NEW_DSP=y # CONFIG_SND_CS5530 is not set # CONFIG_SND_CS5535AUDIO is not set # CONFIG_SND_DARLA20 is not set # CONFIG_SND_GINA20 is not set # CONFIG_SND_LAYLA20 is not set # CONFIG_SND_DARLA24 is not set # CONFIG_SND_GINA24 is not set # CONFIG_SND_LAYLA24 is not set # CONFIG_SND_MONA is not set # CONFIG_SND_MIA is not set # CONFIG_SND_ECHO3G is not set # CONFIG_SND_INDIGO is not set # CONFIG_SND_INDIGOIO is not set # CONFIG_SND_INDIGODJ is not set CONFIG_SND_EMU10K1=y CONFIG_SND_EMU10K1X=y CONFIG_SND_ENS1370=m CONFIG_SND_ENS1371=m CONFIG_SND_ES1938=m CONFIG_SND_ES1968=m CONFIG_SND_FM801=m # CONFIG_SND_FM801_TEA575X_BOOL is not set CONFIG_SND_HDA_INTEL=y # CONFIG_SND_HDA_HWDEP is not set CONFIG_SND_HDA_CODEC_REALTEK=y CONFIG_SND_HDA_CODEC_ANALOG=y CONFIG_SND_HDA_CODEC_SIGMATEL=y CONFIG_SND_HDA_CODEC_VIA=y CONFIG_SND_HDA_CODEC_ATIHDMI=y CONFIG_SND_HDA_CODEC_CONEXANT=y CONFIG_SND_HDA_CODEC_CMEDIA=y CONFIG_SND_HDA_CODEC_SI3054=y CONFIG_SND_HDA_GENERIC=y # CONFIG_SND_HDA_POWER_SAVE is not set CONFIG_SND_HDSP=m CONFIG_SND_HDSPM=m CONFIG_SND_ICE1712=m CONFIG_SND_ICE1724=m CONFIG_SND_INTEL8X0=y # CONFIG_SND_INTEL8X0M is not set CONFIG_SND_KORG1212=m CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL=y CONFIG_SND_MAESTRO3=m CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL=y # CONFIG_SND_MIXART is not set CONFIG_SND_NM256=m # CONFIG_SND_PCXHR is not set # CONFIG_SND_RIPTIDE is not set CONFIG_SND_RME32=m CONFIG_SND_RME96=m CONFIG_SND_RME9652=m CONFIG_SND_SONICVIBES=m CONFIG_SND_TRIDENT=m CONFIG_SND_VIA82XX=m CONFIG_SND_VIA82XX_MODEM=m CONFIG_SND_VX222=m CONFIG_SND_YMFPCI=m CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL=y CONFIG_SND_AC97_POWER_SAVE=y CONFIG_SND_AC97_POWER_SAVE_DEFAULT=0 # # USB devices # CONFIG_SND_USB_AUDIO=m CONFIG_SND_USB_USX2Y=m # CONFIG_SND_USB_CAIAQ is not set # # PCMCIA devices # # CONFIG_SND_VXPOCKET is not set # CONFIG_SND_PDAUDIOCF is not set # # System on Chip audio support # # CONFIG_SND_SOC is not set # # SoC Audio support for SuperH # # # Open Sound System # # CONFIG_SOUND_PRIME is not set CONFIG_AC97_BUS=y CONFIG_HID_SUPPORT=y CONFIG_HID=y CONFIG_HID_DEBUG=y # CONFIG_HIDRAW is not set # # USB Input Devices # CONFIG_USB_HID=m # CONFIG_USB_HIDINPUT_POWERBOOK is not set CONFIG_HID_FF=y CONFIG_HID_PID=y CONFIG_LOGITECH_FF=y # CONFIG_PANTHERLORD_FF is not set CONFIG_THRUSTMASTER_FF=y CONFIG_ZEROPLUS_FF=y CONFIG_USB_HIDDEV=y # # USB HID Boot Protocol drivers # CONFIG_USB_KBD=m CONFIG_USB_MOUSE=y CONFIG_USB_SUPPORT=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB=y # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y CONFIG_USB_DEVICE_CLASS=y # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_SUSPEND is not set # CONFIG_USB_PERSIST is not set # CONFIG_USB_OTG is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_SPLIT_ISO=y CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_EHCI_TT_NEWSCHED=y CONFIG_USB_ISP116X_HCD=m CONFIG_USB_OHCI_HCD=y # CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set # CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_UHCI_HCD=y CONFIG_USB_U132_HCD=m CONFIG_USB_SL811_HCD=m CONFIG_USB_SL811_CS=m # CONFIG_USB_R8A66597_HCD is not set # # USB Device Class drivers # CONFIG_USB_ACM=m CONFIG_USB_PRINTER=m # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' # # # may also be needed; see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set CONFIG_USB_STORAGE_DATAFAB=y CONFIG_USB_STORAGE_FREECOM=y # CONFIG_USB_STORAGE_ISD200 is not set CONFIG_USB_STORAGE_DPCM=y CONFIG_USB_STORAGE_USBAT=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y CONFIG_USB_STORAGE_ALAUDA=y CONFIG_USB_STORAGE_KARMA=y CONFIG_USB_LIBUSUAL=y # # USB Imaging devices # CONFIG_USB_MDC800=m CONFIG_USB_MICROTEK=m CONFIG_USB_MON=y # # USB port drivers # CONFIG_USB_USS720=m # # USB Serial Converter support # CONFIG_USB_SERIAL=m CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_AIRCABLE=m CONFIG_USB_SERIAL_AIRPRIME=m CONFIG_USB_SERIAL_ARK3116=m CONFIG_USB_SERIAL_BELKIN=m # CONFIG_USB_SERIAL_CH341 is not set CONFIG_USB_SERIAL_WHITEHEAT=m CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m CONFIG_USB_SERIAL_CP2101=m CONFIG_USB_SERIAL_CYPRESS_M8=m CONFIG_USB_SERIAL_EMPEG=m CONFIG_USB_SERIAL_FTDI_SIO=m CONFIG_USB_SERIAL_FUNSOFT=m CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_IPAQ=m CONFIG_USB_SERIAL_IR=m CONFIG_USB_SERIAL_EDGEPORT=m CONFIG_USB_SERIAL_EDGEPORT_TI=m CONFIG_USB_SERIAL_GARMIN=m CONFIG_USB_SERIAL_IPW=m CONFIG_USB_SERIAL_KEYSPAN_PDA=m CONFIG_USB_SERIAL_KEYSPAN=m CONFIG_USB_SERIAL_KEYSPAN_MPR=y CONFIG_USB_SERIAL_KEYSPAN_USA28=y CONFIG_USB_SERIAL_KEYSPAN_USA28X=y CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y CONFIG_USB_SERIAL_KEYSPAN_USA19=y CONFIG_USB_SERIAL_KEYSPAN_USA18X=y CONFIG_USB_SERIAL_KEYSPAN_USA19W=y CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y CONFIG_USB_SERIAL_KEYSPAN_USA49W=y CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y CONFIG_USB_SERIAL_KLSI=m CONFIG_USB_SERIAL_KOBIL_SCT=m CONFIG_USB_SERIAL_MCT_U232=m CONFIG_USB_SERIAL_MOS7720=m CONFIG_USB_SERIAL_MOS7840=m CONFIG_USB_SERIAL_NAVMAN=m CONFIG_USB_SERIAL_PL2303=m # CONFIG_USB_SERIAL_OTI6858 is not set CONFIG_USB_SERIAL_HP4X=m CONFIG_USB_SERIAL_SAFE=m CONFIG_USB_SERIAL_SAFE_PADDED=y CONFIG_USB_SERIAL_SIERRAWIRELESS=m CONFIG_USB_SERIAL_TI=m CONFIG_USB_SERIAL_CYBERJACK=m CONFIG_USB_SERIAL_XIRCOM=m CONFIG_USB_SERIAL_OPTION=m CONFIG_USB_SERIAL_OMNINET=m CONFIG_USB_SERIAL_DEBUG=m CONFIG_USB_EZUSB=y # # USB Miscellaneous drivers # CONFIG_USB_EMI62=m CONFIG_USB_EMI26=m CONFIG_USB_ADUTUX=m CONFIG_USB_AUERSWALD=m CONFIG_USB_RIO500=m CONFIG_USB_LEGOTOWER=m CONFIG_USB_LCD=m # CONFIG_USB_BERRY_CHARGE is not set CONFIG_USB_LED=m # CONFIG_USB_CYPRESS_CY7C63 is not set # CONFIG_USB_CYTHERM is not set CONFIG_USB_PHIDGET=m CONFIG_USB_PHIDGETKIT=m CONFIG_USB_PHIDGETMOTORCONTROL=m CONFIG_USB_PHIDGETSERVO=m CONFIG_USB_IDMOUSE=m CONFIG_USB_FTDI_ELAN=m CONFIG_USB_APPLEDISPLAY=m CONFIG_USB_SISUSBVGA=m CONFIG_USB_SISUSBVGA_CON=y CONFIG_USB_LD=m CONFIG_USB_TRANCEVIBRATOR=m # CONFIG_USB_IOWARRIOR is not set CONFIG_USB_TEST=m # # USB DSL modem support # CONFIG_USB_ATM=m CONFIG_USB_SPEEDTOUCH=m CONFIG_USB_CXACRU=m CONFIG_USB_UEAGLEATM=m CONFIG_USB_XUSBATM=m # # USB Gadget Support # # CONFIG_USB_GADGET is not set CONFIG_MMC=m # CONFIG_MMC_DEBUG is not set # CONFIG_MMC_UNSAFE_RESUME is not set # # MMC/SD Card Drivers # CONFIG_MMC_BLOCK=m CONFIG_MMC_BLOCK_BOUNCE=y # CONFIG_SDIO_UART is not set # # MMC/SD Host Controller Drivers # CONFIG_MMC_SDHCI=m # CONFIG_MMC_RICOH_MMC is not set CONFIG_MMC_WBSD=m CONFIG_MMC_TIFM_SD=m CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y # # LED drivers # # # LED Triggers # CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_TIMER=m CONFIG_LEDS_TRIGGER_HEARTBEAT=m CONFIG_INFINIBAND=m CONFIG_INFINIBAND_USER_MAD=m CONFIG_INFINIBAND_USER_ACCESS=m CONFIG_INFINIBAND_USER_MEM=y CONFIG_INFINIBAND_ADDR_TRANS=y CONFIG_INFINIBAND_MTHCA=m CONFIG_INFINIBAND_MTHCA_DEBUG=y # CONFIG_INFINIBAND_AMSO1100 is not set # CONFIG_MLX4_INFINIBAND is not set CONFIG_INFINIBAND_IPOIB=m # CONFIG_INFINIBAND_IPOIB_CM is not set CONFIG_INFINIBAND_IPOIB_DEBUG=y CONFIG_INFINIBAND_IPOIB_DEBUG_DATA=y CONFIG_INFINIBAND_SRP=m CONFIG_INFINIBAND_ISER=m CONFIG_EDAC=y # # Reporting subsystems # # CONFIG_EDAC_DEBUG is not set CONFIG_EDAC_MM_EDAC=m CONFIG_EDAC_AMD76X=m CONFIG_EDAC_E7XXX=m CONFIG_EDAC_E752X=m CONFIG_EDAC_I82875P=m # CONFIG_EDAC_I82975X is not set # CONFIG_EDAC_I3000 is not set CONFIG_EDAC_I82860=m CONFIG_EDAC_R82600=m # CONFIG_EDAC_I5000 is not set CONFIG_RTC_LIB=m CONFIG_RTC_CLASS=m # # RTC interfaces # CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y # CONFIG_RTC_INTF_DEV_UIE_EMUL is not set # CONFIG_RTC_DRV_TEST is not set # # I2C RTC drivers # CONFIG_RTC_DRV_DS1307=m # CONFIG_RTC_DRV_DS1374 is not set CONFIG_RTC_DRV_DS1672=m # CONFIG_RTC_DRV_MAX6900 is not set CONFIG_RTC_DRV_RS5C372=m CONFIG_RTC_DRV_ISL1208=m CONFIG_RTC_DRV_X1205=m CONFIG_RTC_DRV_PCF8563=m # CONFIG_RTC_DRV_PCF8583 is not set # CONFIG_RTC_DRV_M41T80 is not set # # SPI RTC drivers # # # Platform RTC drivers # # CONFIG_RTC_DRV_CMOS is not set CONFIG_RTC_DRV_DS1553=m # CONFIG_RTC_DRV_STK17TA8 is not set CONFIG_RTC_DRV_DS1742=m # CONFIG_RTC_DRV_M48T86 is not set # CONFIG_RTC_DRV_M48T59 is not set CONFIG_RTC_DRV_V3020=m # # on-CPU RTC drivers # # CONFIG_DMADEVICES is not set # CONFIG_AUXDISPLAY is not set CONFIG_VIRTUALIZATION=y CONFIG_KVM=y CONFIG_KVM_INTEL=y CONFIG_KVM_AMD=y # CONFIG_LGUEST is not set # # Userspace I/O # # CONFIG_UIO is not set # # Firmware Drivers # CONFIG_EDD=m CONFIG_EFI_VARS=y CONFIG_DELL_RBU=m CONFIG_DCDBAS=m CONFIG_DMIID=y # # File systems # CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT2_FS_XIP=y CONFIG_FS_XIP=y CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y # CONFIG_EXT4DEV_FS is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=y CONFIG_REISERFS_FS=m # CONFIG_REISERFS_CHECK is not set CONFIG_REISERFS_PROC_INFO=y CONFIG_REISERFS_FS_XATTR=y CONFIG_REISERFS_FS_POSIX_ACL=y CONFIG_REISERFS_FS_SECURITY=y CONFIG_JFS_FS=m CONFIG_JFS_POSIX_ACL=y CONFIG_JFS_SECURITY=y # CONFIG_JFS_DEBUG is not set # CONFIG_JFS_STATISTICS is not set CONFIG_FS_POSIX_ACL=y CONFIG_XFS_FS=m CONFIG_XFS_QUOTA=y CONFIG_XFS_SECURITY=y CONFIG_XFS_POSIX_ACL=y # CONFIG_XFS_RT is not set CONFIG_GFS2_FS=m CONFIG_GFS2_FS_LOCKING_NOLOCK=m CONFIG_GFS2_FS_LOCKING_DLM=m CONFIG_OCFS2_FS=m # CONFIG_OCFS2_DEBUG_MASKLOG is not set # CONFIG_OCFS2_DEBUG_FS is not set CONFIG_MINIX_FS=m CONFIG_ROMFS_FS=m CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y CONFIG_QUOTA=y # CONFIG_QUOTA_NETLINK_INTERFACE is not set CONFIG_PRINT_QUOTA_WARNING=y # CONFIG_QFMT_V1 is not set CONFIG_QFMT_V2=y CONFIG_QUOTACTL=y CONFIG_DNOTIFY=y CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=m CONFIG_FUSE_FS=m CONFIG_GENERIC_ACL=y # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_UDF_FS=m CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="ascii" # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_SYSCTL=y CONFIG_SYSFS=y CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_CONFIGFS_FS=m # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set CONFIG_AFFS_FS=m CONFIG_ECRYPT_FS=m CONFIG_HFS_FS=m CONFIG_HFSPLUS_FS=m CONFIG_BEFS_FS=m # CONFIG_BEFS_DEBUG is not set CONFIG_BFS_FS=m CONFIG_EFS_FS=m CONFIG_CRAMFS=m CONFIG_VXFS_FS=m # CONFIG_HPFS_FS is not set CONFIG_QNX4FS_FS=m CONFIG_SYSV_FS=m CONFIG_UFS_FS=m # CONFIG_UFS_FS_WRITE is not set # CONFIG_UFS_DEBUG is not set CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=m CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y CONFIG_NFS_DIRECTIO=y CONFIG_NFSD=m CONFIG_NFSD_V2_ACL=y CONFIG_NFSD_V3=y CONFIG_NFSD_V3_ACL=y CONFIG_NFSD_V4=y CONFIG_NFSD_TCP=y CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_NFS_ACL_SUPPORT=m CONFIG_NFS_COMMON=y CONFIG_SUNRPC=m CONFIG_SUNRPC_GSS=m CONFIG_SUNRPC_XPRT_RDMA=m # CONFIG_SUNRPC_BIND34 is not set CONFIG_RPCSEC_GSS_KRB5=m CONFIG_RPCSEC_GSS_SPKM3=m # CONFIG_SMB_FS is not set CONFIG_CIFS=m # CONFIG_CIFS_STATS is not set CONFIG_CIFS_WEAK_PW_HASH=y CONFIG_CIFS_XATTR=y CONFIG_CIFS_POSIX=y # CONFIG_CIFS_DEBUG2 is not set # CONFIG_CIFS_EXPERIMENTAL is not set CONFIG_NCP_FS=m CONFIG_NCPFS_PACKET_SIGNING=y CONFIG_NCPFS_IOCTL_LOCKING=y CONFIG_NCPFS_STRONG=y CONFIG_NCPFS_NFS_NS=y CONFIG_NCPFS_OS2_NS=y CONFIG_NCPFS_SMALLDOS=y CONFIG_NCPFS_NLS=y CONFIG_NCPFS_EXTRAS=y CONFIG_CODA_FS=m # CONFIG_CODA_FS_OLD_API is not set # CONFIG_AFS_FS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set CONFIG_OSF_PARTITION=y CONFIG_AMIGA_PARTITION=y # CONFIG_ATARI_PARTITION is not set CONFIG_MAC_PARTITION=y CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y CONFIG_MINIX_SUBPARTITION=y CONFIG_SOLARIS_X86_PARTITION=y CONFIG_UNIXWARE_DISKLABEL=y # CONFIG_LDM_PARTITION is not set CONFIG_SGI_PARTITION=y # CONFIG_ULTRIX_PARTITION is not set CONFIG_SUN_PARTITION=y CONFIG_KARMA_PARTITION=y CONFIG_EFI_PARTITION=y # CONFIG_SYSV68_PARTITION is not set CONFIG_NLS=y CONFIG_NLS_DEFAULT="utf8" CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=m CONFIG_NLS_CODEPAGE_861=m CONFIG_NLS_CODEPAGE_862=m CONFIG_NLS_CODEPAGE_863=m CONFIG_NLS_CODEPAGE_864=m CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_CODEPAGE_869=m CONFIG_NLS_CODEPAGE_936=m CONFIG_NLS_CODEPAGE_950=m CONFIG_NLS_CODEPAGE_932=m CONFIG_NLS_CODEPAGE_949=m CONFIG_NLS_CODEPAGE_874=m CONFIG_NLS_ISO8859_8=m CONFIG_NLS_CODEPAGE_1250=m CONFIG_NLS_CODEPAGE_1251=m CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_UTF8=m CONFIG_DLM=m CONFIG_DLM_DEBUG=y CONFIG_INSTRUMENTATION=y CONFIG_PROFILING=y CONFIG_OPROFILE=m CONFIG_KPROBES=y # CONFIG_MARKERS is not set # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y # CONFIG_PRINTK_TIME is not set CONFIG_ENABLE_WARN_DEPRECATED=y # CONFIG_ENABLE_MUST_CHECK is not set CONFIG_MAGIC_SYSRQ=y # CONFIG_UNUSED_SYMBOLS is not set CONFIG_DEBUG_FS=y # CONFIG_HEADERS_CHECK is not set CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_SHIRQ is not set CONFIG_DETECT_SOFTLOCKUP=y # CONFIG_SCHED_DEBUG is not set # CONFIG_SCHEDSTATS is not set # CONFIG_TIMER_STATS is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_RT_MUTEX_TESTER is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_MUTEXES is not set # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set # CONFIG_LOCK_STAT is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set CONFIG_STACKTRACE=y CONFIG_EVENT_TRACE=y CONFIG_FUNCTION_TRACE=y # CONFIG_WAKEUP_TIMING is not set # CONFIG_CRITICAL_IRQSOFF_TIMING is not set CONFIG_MCOUNT=y # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_HIGHMEM is not set CONFIG_DEBUG_BUGVERBOSE=y # CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_LIST is not set # CONFIG_DEBUG_SG is not set CONFIG_FRAME_POINTER=y # CONFIG_FORCED_INLINING is not set # CONFIG_BOOT_PRINTK_DELAY is not set # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_LKDTM is not set # CONFIG_FAULT_INJECTION is not set # CONFIG_SAMPLES is not set CONFIG_EARLY_PRINTK=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_STACK_USAGE is not set CONFIG_DEBUG_RODATA=y CONFIG_4KSTACKS=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y CONFIG_DOUBLEFAULT=y # # Security options # CONFIG_KEYS=y CONFIG_KEYS_DEBUG_PROC_KEYS=y CONFIG_SECURITY=y CONFIG_SECURITY_NETWORK=y # CONFIG_SECURITY_NETWORK_XFRM is not set CONFIG_SECURITY_CAPABILITIES=y # CONFIG_SECURITY_FILE_CAPABILITIES is not set # CONFIG_SECURITY_ROOTPLUG is not set CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1 CONFIG_SECURITY_SELINUX_DISABLE=y CONFIG_SECURITY_SELINUX_DEVELOP=y CONFIG_SECURITY_SELINUX_AVC_STATS=y CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1 # CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT is not set # CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set CONFIG_XOR_BLOCKS=m CONFIG_ASYNC_CORE=m CONFIG_ASYNC_MEMCPY=m CONFIG_ASYNC_XOR=m CONFIG_CRYPTO=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_XCBC=y CONFIG_CRYPTO_NULL=y CONFIG_CRYPTO_MD4=y CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_SHA256=y CONFIG_CRYPTO_SHA512=y CONFIG_CRYPTO_WP512=y CONFIG_CRYPTO_TGR192=y CONFIG_CRYPTO_GF128MUL=y CONFIG_CRYPTO_ECB=y CONFIG_CRYPTO_CBC=y CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_LRW=y # CONFIG_CRYPTO_XTS is not set # CONFIG_CRYPTO_CRYPTD is not set CONFIG_CRYPTO_DES=y # CONFIG_CRYPTO_FCRYPT is not set CONFIG_CRYPTO_BLOWFISH=y CONFIG_CRYPTO_TWOFISH=y CONFIG_CRYPTO_TWOFISH_COMMON=y # CONFIG_CRYPTO_TWOFISH_586 is not set CONFIG_CRYPTO_SERPENT=y CONFIG_CRYPTO_AES=y # CONFIG_CRYPTO_AES_586 is not set CONFIG_CRYPTO_CAST5=y CONFIG_CRYPTO_CAST6=y CONFIG_CRYPTO_TEA=y CONFIG_CRYPTO_ARC4=y CONFIG_CRYPTO_KHAZAD=y CONFIG_CRYPTO_ANUBIS=y # CONFIG_CRYPTO_SEED is not set CONFIG_CRYPTO_DEFLATE=y CONFIG_CRYPTO_MICHAEL_MIC=y CONFIG_CRYPTO_CRC32C=y # CONFIG_CRYPTO_CAMELLIA is not set # CONFIG_CRYPTO_TEST is not set # CONFIG_CRYPTO_AUTHENC is not set CONFIG_CRYPTO_HW=y CONFIG_CRYPTO_DEV_PADLOCK=m CONFIG_CRYPTO_DEV_PADLOCK_AES=m CONFIG_CRYPTO_DEV_PADLOCK_SHA=m CONFIG_CRYPTO_DEV_GEODE=m # # Library routines # CONFIG_BITREVERSE=y CONFIG_CRC_CCITT=y CONFIG_CRC16=y # CONFIG_CRC_ITU_T is not set CONFIG_CRC32=y # CONFIG_CRC7 is not set CONFIG_LIBCRC32C=y CONFIG_AUDIT_GENERIC=y CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=m CONFIG_TEXTSEARCH_BM=m CONFIG_TEXTSEARCH_FSM=m CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y CONFIG_CHECK_SIGNATURE=y ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-12-02 21:19 ` Ingo Molnar @ 2007-12-03 0:57 ` Jörn Engel 2007-12-04 0:06 ` Jörn Engel 0 siblings, 1 reply; 268+ messages in thread From: Jörn Engel @ 2007-12-03 0:57 UTC (permalink / raw) To: Ingo Molnar Cc: Jörn Engel, Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw On Sun, 2 December 2007 22:19:00 +0100, Ingo Molnar wrote: > * Jörn Engel <joern@logfs.org> wrote: > > > Maybe one more thing: can you send me the config you used for the > > setup above? I'd like to know whether qemu or my config is to blame. > > sure - attached. After an eternity of compile time, this config does generate some useful output. qemu is not to blame. Jörn -- Joern's library part 9: http://www.scl.ameslab.gov/Publications/Gus/TwelveWays.html ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-12-03 0:57 ` Jörn Engel @ 2007-12-04 0:06 ` Jörn Engel 2007-12-04 9:34 ` Ingo Molnar 0 siblings, 1 reply; 268+ messages in thread From: Jörn Engel @ 2007-12-04 0:06 UTC (permalink / raw) To: Jörn Engel Cc: Ingo Molnar, Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw On Mon, 3 December 2007 01:57:02 +0100, Jörn Engel wrote: > > After an eternity of compile time, this config does generate some useful > output. qemu is not to blame. Or is it? The output definitely looks suspicious. Large amounts of code get processed within a microsecond, while update_wall_time() appears to cause huge delays every time it is called: http://logfs.org/~joern/trace Does this output make sense or does it rather indicate some sloppiness wrt. time in the qemu virtual machine? Jörn -- tglx1 thinks that joern should get a (TM) for "Thinking Is Hard" -- Thomas Gleixner ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-12-04 0:06 ` Jörn Engel @ 2007-12-04 9:34 ` Ingo Molnar 0 siblings, 0 replies; 268+ messages in thread From: Ingo Molnar @ 2007-12-04 9:34 UTC (permalink / raw) To: Jörn Engel Cc: Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw * Jörn Engel <joern@logfs.org> wrote: > On Mon, 3 December 2007 01:57:02 +0100, Jörn Engel wrote: > > > > After an eternity of compile time, this config does generate some useful > > output. qemu is not to blame. > > Or is it? The output definitely looks suspicious. Large amounts of > code get processed within a microsecond, while update_wall_time() > appears to cause huge delays every time it is called: > http://logfs.org/~joern/trace > > Does this output make sense or does it rather indicate some sloppiness > wrt. time in the qemu virtual machine? not sure. It could be qemu being scheduled away? You could try to run qemu with nice -20 or so, to avoid getting preempted. If time lapses like this still show up: trace-cm 434 0D.h. 1008us!: do_timer (tick_periodic) trace-cm 434 0D.h. 1972us+: update_wall_time (do_timer) trace-cm 434 0D.h. 1008us!: do_timer (tick_periodic) trace-cm 434 0D.h. 1972us+: update_wall_time (do_timer) then that could indicate a timekeeping weirdness, OR it could mean that qemu is simply very slow. (there could be timer hw access between those two function calls) Ingo ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-30 13:35 ` Ingo Molnar 2007-11-30 13:43 ` Ingo Molnar @ 2007-11-30 15:49 ` Jörn Engel 1 sibling, 0 replies; 268+ messages in thread From: Jörn Engel @ 2007-11-30 15:49 UTC (permalink / raw) To: Ingo Molnar Cc: Jörn Engel, Mark Lord, Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, rjw On Fri, 30 November 2007 14:35:46 +0100, Ingo Molnar wrote: > * Jörn Engel <joern@logfs.org> wrote: > > > > kernel/sched.c:3384: warning: ‘struct prio_array’ declared inside parameter list > > kernel/sched.c:3384: warning: its scope is only this definition or declaration, which is probably not what you want > > kernel/sched.c: In function ‘trace_array’: > > kernel/sched.c:3391: error: dereferencing pointer to incomplete type > > kernel/sched.c:3393: error: dereferencing pointer to incomplete type > > kernel/sched.c:3393: error: dereferencing pointer to incomplete type > > kernel/sched.c:3396: error: dereferencing pointer to incomplete type > > kernel/sched.c:3396: error: dereferencing pointer to incomplete type > > kernel/sched.c: In function ‘trace_all_runnable_tasks’: > > kernel/sched.c:3407: error: ‘struct rq’ has no member named ‘active’ > > make[1]: *** [kernel/sched.o] Error 1 > > > > And I cannot find a definition of struct prio_array in current git > > either. Is another patch needed? > > change that to rt_prio_array in the code. Solves the prio_array problem, but leaves the non-existing member active. I've upgraded to -rc3 and will give your latest patch a whirl. Jörn -- Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. -- Doug MacIlroy ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-15 17:31 ` Mark Lord 2007-11-15 19:34 ` Ingo Molnar @ 2007-11-15 20:27 ` Rafael J. Wysocki 1 sibling, 0 replies; 268+ messages in thread From: Rafael J. Wysocki @ 2007-11-15 20:27 UTC (permalink / raw) To: Mark Lord Cc: Pavel Machek, Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, linux-kernel, linux-pm, Ingo Molnar On Thursday, 15 of November 2007, Mark Lord wrote: > > Hi! > > > >> > I have been reporting this off and on since 2.6.23 was released. > >> > This problem was not apparent up to perhaps 2.6.23-rc8, > >> > but definitely became common in 2.6.23 and 2.6.23.1. > >> > > >> > Most of the time, a resume-from-RAM on my notebook takes about 2.1 seconds > >> > of kernel time to complete. > >> > > >> > Once in a while, it takes *much* longer, in the 14-20 second range. > >> > These long events *seem* to be mostly after the notebook has been > >> > in suspend for a longish time, but there's really nothing consistent here. > >> > > >> > So git-bisect isn't going to work for this one. I recently rebuilt the > >> > kernel > >> > to include printk timestamps, and then it went 2 days without the issue > >> > happening, > >> > until this morning (after an overnight suspend) finally. > >> > > >> > The machine is a Dell Inspiron 9400, Intel chipset + Core2Duo 2.1GHZ w/3GB > >> > DDR2. > >> > PCIe express chipset, ATI graphics, SATA hard drive. > >> > > >> > 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT > >> > Express Memory Controller Hub (rev 03) > >> > 00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT > >> > Express PCI Express Root Port (rev 03) > >> > 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High > >> > Definition Audio Controller (rev 01) > >> > 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port > >> > 1 (rev 01) > >> > 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port > >> > 2 (rev 01) > >> > 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port > >> > 4 (rev 01) > >> > 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 > >> > (rev 01) > >> > 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 > >> > (rev 01) > >> > 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 > >> > (rev 01) > >> > 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 > >> > (rev 01) > >> > 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI > >> > Controller (rev 01) > >> > 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1) > >> > 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface > >> > Bridge (rev 01) > >> > 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial > >> > ATA Storage Controller IDE (rev 01) > >> > 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev > >> > 01) > >> > 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility > >> > X1400 > >> > 03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX > >> > (rev 02) > >> > 03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd Unknown device 0832 > >> > 03:01.1 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 > >> > SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19) > >> > 03:01.2 System peripheral: Ricoh Co Ltd Unknown device 0843 (rev 01) > >> > 03:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host > >> > Adapter (rev 0a) > >> > 03:01.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 05) > >> > 0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network > >> > Connection (rev 02) > >> > > >> > There's also a USB2 hub connected, with the Logitech mouse being the > >> > only thing plugged into it at present. > >> > > >> > The best clue I have of what is happening, other than that it was first > >> > seen during the late 2.6.23-rc* series, are the following two sets of > >> > kernel logs. The first set is from a "normal" fast wake-up, > >> > and the second set is from the "slow" wake-up seen this morning. > >> > > >> > Both logs show the same information, in pretty much the same order. > >> > The BIG difference is a bunch of unexplained pauses of exactly 1-second > >> > each that occur during the slow wakeup. > >> > > >> > The only other difference is that the SATA disk messages are placed > >> > differently within the two logs. I'm thinking on that one but it > >> > doesn't look significant to me. > >> > > >> > The real question is, why the 1-sec pauses? > > > > Can you try nohz=off highres=off? Strange stuff is happening with > > nohz. > .. > > (added Ingo to CC: list: maybe this is some weird interaction with CFS > and jiffies being reset to 0 on resume ??) > > I can try it, but it won't help debug the problem much. Well, if you could verify that it doesn't happen at all with NO_HZ unset, that would be a valuable data point, IMO. > Remember, this happens very inconsistently, maybe 3-4 times a day, > or not at all for 3-4 days. > > But if somebody has a specific bug-fix patch that could explain this, > then I'll happily apply it here. I'm not aware of any fix related to the symptoms that you observe. Greetings, Rafael ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-15 16:32 ` [BUG] Strange 1-second pauses during Resume-from-RAM Mark Lord 2007-11-15 16:49 ` Ray Lee 2007-11-15 18:14 ` Pavel Machek @ 2007-11-18 16:10 ` Mark Lord 2007-11-18 16:21 ` Ingo Molnar 2 siblings, 1 reply; 268+ messages in thread From: Mark Lord @ 2007-11-18 16:10 UTC (permalink / raw) To: Mark Lord Cc: Thomas Gleixner, len.brown, Andrew Morton, Linux Kernel, linux-pm, rjw, Ingo Molnar Mark Lord wrote: > I have been reporting this off and on since 2.6.23 was released. > This problem was not apparent up to perhaps 2.6.23-rc8, > but definitely became common in 2.6.23 and 2.6.23.1. > > Most of the time, a resume-from-RAM on my notebook takes about 2.1 seconds > of kernel time to complete. > > Once in a while, it takes *much* longer, in the 14-20 second range. > These long events *seem* to be mostly after the notebook has been > in suspend for a longish time, but there's really nothing consistent here. > > So git-bisect isn't going to work for this one. I recently rebuilt the > kernel > to include printk timestamps, and then it went 2 days without the issue > happening, > until this morning (after an overnight suspend) finally. > > The machine is a Dell Inspiron 9400, Intel chipset + Core2Duo 2.1GHZ > w/3GB DDR2. > PCIe express chipset, ATI graphics, SATA hard drive. > > 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and > 945GT Express Memory Controller Hub (rev 03) > 00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and > 945GT Express PCI Express Root Port (rev 03) > 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High > Definition Audio Controller (rev 01) > 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express > Port 1 (rev 01) > 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express > Port 2 (rev 01) > 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express > Port 4 (rev 01) > 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI > #1 (rev 01) > 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI > #2 (rev 01) > 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI > #3 (rev 01) > 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI > #4 (rev 01) > 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI > Controller (rev 01) > 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1) > 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface > Bridge (rev 01) > 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) > Serial ATA Storage Controller IDE (rev 01) > 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller > (rev 01) > 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility > X1400 > 03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX > (rev 02) > 03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd Unknown device 0832 > 03:01.1 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 > SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19) > 03:01.2 System peripheral: Ricoh Co Ltd Unknown device 0843 (rev 01) > 03:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host > Adapter (rev 0a) > 03:01.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 05) > 0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG > Network Connection (rev 02) > > There's also a USB2 hub connected, with the Logitech mouse being the > only thing plugged into it at present. > > The best clue I have of what is happening, other than that it was first > seen during the late 2.6.23-rc* series, are the following two sets of > kernel logs. The first set is from a "normal" fast wake-up, > and the second set is from the "slow" wake-up seen this morning. > > Both logs show the same information, in pretty much the same order. > The BIG difference is a bunch of unexplained pauses of exactly 1-second > each that occur during the slow wakeup. > > The only other difference is that the SATA disk messages are placed > differently within the two logs. I'm thinking on that one but it > doesn't look significant to me. > > The real question is, why the 1-sec pauses? > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > HERE IS THE NORMAL RESUME LOG. > > > [ 820.147914] CPU1 is down > [ 0.355669] Back to C! > [ 0.356120] Enabling non-boot CPUs ... > [ 0.377167] SMP alternatives: switching to SMP code > [ 0.378565] Booting processor 1/1 eip 3000 > [ 0.378568] CPU 1 irqstacks, hard=c0375000 soft=c0373000 > [ 0.389374] Initializing CPU#1 > [ 0.470225] Calibrating delay using timer specific routine.. 4324.85 > BogoMIPS (lpj=7204571) > [ 0.470235] CPU: After generic identify, caps: bfebfbff 20100000 > 00000000 00000000 0000e3bd 00000000 00000001 00000000 > [ 0.470244] monitor/mwait feature present. > [ 0.470248] CPU: L1 I cache: 32K, L1 D cache: 32K > [ 0.470252] CPU: L2 cache: 4096K > [ 0.470255] CPU: Physical Processor ID: 0 > [ 0.470257] CPU: Processor Core ID: 1 > [ 0.470260] CPU: After all inits, caps: bfebfbff 20100000 00000000 > 00003940 0000e3bd 00000000 00000001 00000000 > [ 0.471330] CPU1: Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz > stepping 06 > [ 0.471724] CPU1 is up > [ 0.474787] Switched to high resolution mode on CPU 1 > [ 0.483415] PM: Writing back config space on device 0000:00:01.0 at > offset a (was f, writing 0) > [ 0.483422] PM: Writing back config space on device 0000:00:01.0 at > offset 7 (was e0e0, writing 2000e0e0) > [ 0.483428] PM: Writing back config space on device 0000:00:01.0 at > offset 3 (was 10000, writing 10010) > [ 0.483869] PCI: Setting latency timer of device 0000:00:01.0 to 64 > [ 0.484224] PM: Writing back config space on device 0000:00:1b.0 at > offset f (was 100, writing 10b) > [ 0.484244] PM: Writing back config space on device 0000:00:1b.0 at > offset 4 (was ffa7c004, writing efffc004) > [ 0.484250] PM: Writing back config space on device 0000:00:1b.0 at > offset 3 (was 0, writing 10) > [ 0.484258] PM: Writing back config space on device 0000:00:1b.0 at > offset 1 (was 100000, writing 100102) > [ 0.484282] ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 21 (level, > low) -> IRQ 20 > [ 0.484292] PCI: Setting latency timer of device 0000:00:1b.0 to 64 > [ 0.486711] PM: Writing back config space on device 0000:00:1c.0 at > offset f (was 100, writing 20100) > [ 0.486725] PM: Writing back config space on device 0000:00:1c.0 at > offset 9 (was 10001, writing 1fff1) > [ 0.486731] PM: Writing back config space on device 0000:00:1c.0 at > offset 8 (was 0, writing fff0) > [ 0.486738] PM: Writing back config space on device 0000:00:1c.0 at > offset 7 (was 0, writing f0) > [ 0.486744] PM: Writing back config space on device 0000:00:1c.0 at > offset 6 (was 0, writing b0b00) > [ 0.486753] PM: Writing back config space on device 0000:00:1c.0 at > offset 3 (was 810000, writing 810010) > [ 0.486761] PM: Writing back config space on device 0000:00:1c.0 at > offset 1 (was 100000, writing 100007) > [ 0.486782] PCI: Setting latency timer of device 0000:00:1c.0 to 64 > [ 0.486788] pciehp_resume ENTRY > [ 0.486829] PM: Writing back config space on device 0000:00:1c.1 at > offset f (was 200, writing 20200) > [ 0.486841] PM: Writing back config space on device 0000:00:1c.1 at > offset 9 (was 10001, writing 1fff1) > [ 0.486848] PM: Writing back config space on device 0000:00:1c.1 at > offset 8 (was 0, writing efc0efc0) > [ 0.486854] PM: Writing back config space on device 0000:00:1c.1 at > offset 7 (was 20000000, writing 200000f0) > [ 0.486861] PM: Writing back config space on device 0000:00:1c.1 at > offset 6 (was 0, writing c0c00) > [ 0.486870] PM: Writing back config space on device 0000:00:1c.1 at > offset 3 (was 810000, writing 810010) > [ 0.486877] PM: Writing back config space on device 0000:00:1c.1 at > offset 1 (was 100000, writing 100107) > [ 0.486898] PCI: Setting latency timer of device 0000:00:1c.1 to 64 > [ 0.486903] pciehp_resume ENTRY > [ 0.488916] pciehp: Device 0000:0c:00.0 already exists at c:0, cannot > hot-add > [ 0.488920] pciehp: Cannot add device 0xc:0 > [ 0.488949] PM: Writing back config space on device 0000:00:1c.3 at > offset f (was 400, writing 20400) > [ 0.488963] PM: Writing back config space on device 0000:00:1c.3 at > offset 9 (was 10001, writing e011e001) > [ 0.488969] PM: Writing back config space on device 0000:00:1c.3 at > offset 8 (was 0, writing efb0efa0) > [ 0.488976] PM: Writing back config space on device 0000:00:1c.3 at > offset 7 (was 0, writing d0d0) > [ 0.488982] PM: Writing back config space on device 0000:00:1c.3 at > offset 6 (was 0, writing e0d00) > [ 0.488991] PM: Writing back config space on device 0000:00:1c.3 at > offset 3 (was 810000, writing 810010) > [ 0.488998] PM: Writing back config space on device 0000:00:1c.3 at > offset 1 (was 100000, writing 100007) > [ 0.489020] PCI: Setting latency timer of device 0000:00:1c.3 to 64 > [ 0.489025] pciehp_resume ENTRY > [ 0.489063] ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 20 (level, > low) -> IRQ 19 > [ 0.489070] PCI: Setting latency timer of device 0000:00:1d.0 to 64 > [ 0.489121] usb usb1: root hub lost power or was reset > [ 0.489144] PCI: Enabling device 0000:00:1d.1 (0000 -> 0001) > [ 0.489149] ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 21 (level, > low) -> IRQ 20 > [ 0.489157] PCI: Setting latency timer of device 0000:00:1d.1 to 64 > [ 0.489164] PM: Writing back config space on device 0000:00:1d.1 at > offset f (was 200, writing 20b) > [ 0.489178] PM: Writing back config space on device 0000:00:1d.1 at > offset 8 (was 1, writing bf61) > [ 0.489214] usb usb2: root hub lost power or was reset > [ 0.489236] PCI: Enabling device 0000:00:1d.2 (0000 -> 0001) > [ 0.489240] ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 22 (level, > low) -> IRQ 21 > [ 0.489248] PCI: Setting latency timer of device 0000:00:1d.2 to 64 > [ 0.489255] PM: Writing back config space on device 0000:00:1d.2 at > offset f (was 300, writing 309) > [ 0.489269] PM: Writing back config space on device 0000:00:1d.2 at > offset 8 (was 1, writing bf41) > [ 0.489307] usb usb3: root hub lost power or was reset > [ 0.489329] PCI: Enabling device 0000:00:1d.3 (0000 -> 0001) > [ 0.489333] ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 23 (level, > low) -> IRQ 22 > [ 0.489341] PCI: Setting latency timer of device 0000:00:1d.3 to 64 > [ 0.489348] PM: Writing back config space on device 0000:00:1d.3 at > offset f (was 400, writing 407) > [ 0.489363] PM: Writing back config space on device 0000:00:1d.3 at > offset 8 (was 1, writing bf21) > [ 0.489400] usb usb4: root hub lost power or was reset > [ 0.489535] ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 20 (level, > low) -> IRQ 19 > [ 0.489543] PCI: Setting latency timer of device 0000:00:1d.7 to 64 > [ 0.489622] PM: Writing back config space on device 0000:00:1e.0 at > offset 9 (was 100f1, writing 1fff1) > [ 0.489629] PM: Writing back config space on device 0000:00:1e.0 at > offset 8 (was 90, writing ef90ef90) > [ 0.489635] PM: Writing back config space on device 0000:00:1e.0 at > offset 7 (was 2280e0f0, writing 228000f0) > [ 0.489648] PM: Writing back config space on device 0000:00:1e.0 at > offset 1 (was 100007, writing 100107) > [ 0.489668] PCI: Setting latency timer of device 0000:00:1e.0 to 64 > [ 0.489707] PM: Writing back config space on device 0000:00:1f.0 at > offset 1 (was 2100007, writing 2100107) > [ 0.489872] PM: Writing back config space on device 0000:00:1f.2 at > offset f (was 200, writing 205) > [ 0.489908] ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 17 (level, > low) -> IRQ 17 > [ 0.489915] PCI: Setting latency timer of device 0000:00:1f.2 to 64 > [ 0.489933] PM: Writing back config space on device 0000:00:1f.3 at > offset f (was 200, writing 205) > [ 0.489963] PM: Writing back config space on device 0000:00:1f.3 at > offset 1 (was 2800001, writing 2800101) > [ 0.489981] PM: Writing back config space on device 0000:01:00.0 at > offset f (was 1ff, writing 104) > [ 0.489996] PM: Writing back config space on device 0000:01:00.0 at > offset 3 (was 0, writing 10) > [ 0.490053] PM: Writing back config space on device 0000:0c:00.0 at > offset f (was 100, writing 105) > [ 0.490119] PM: Writing back config space on device 0000:0c:00.0 at > offset 4 (was 0, writing efcff000) > [ 0.490133] PM: Writing back config space on device 0000:0c:00.0 at > offset 3 (was 0, writing 10) > [ 0.490152] PM: Writing back config space on device 0000:0c:00.0 at > offset 1 (was 100000, writing 100106) > [ 0.490217] PM: Writing back config space on device 0000:03:00.0 at > offset f (was 100, writing 105) > [ 0.490236] PM: Writing back config space on device 0000:03:00.0 at > offset 4 (was 0, writing ef9fe000) > [ 0.490242] PM: Writing back config space on device 0000:03:00.0 at > offset 3 (was 0, writing 4000) > [ 0.490250] PM: Writing back config space on device 0000:03:00.0 at > offset 1 (was 100000, writing 100106) > [ 0.490267] ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, > low) -> IRQ 17 > [ 0.492382] PM: Writing back config space on device 0000:03:01.0 at > offset f (was 4020100, writing 4020103) > [ 0.492403] PM: Writing back config space on device 0000:03:01.0 at > offset 4 (was 0, writing ef9fd800) > [ 0.492410] PM: Writing back config space on device 0000:03:01.0 at > offset 3 (was 800000, writing 804000) > [ 0.492417] PM: Writing back config space on device 0000:03:01.0 at > offset 1 (was 2100000, writing 2100106) > [ 0.493339] PM: Writing back config space on device 0000:03:01.1 at > offset f (was 200, writing 209) > [ 0.493361] PM: Writing back config space on device 0000:03:01.1 at > offset 4 (was 0, writing ef9fd400) > [ 0.493368] PM: Writing back config space on device 0000:03:01.1 at > offset 3 (was 800000, writing 804000) > [ 0.493376] PM: Writing back config space on device 0000:03:01.1 at > offset 1 (was 2100000, writing 2100106) > [ 0.493397] ACPI: PCI Interrupt 0000:03:01.1[B] -> GSI 18 (level, > low) -> IRQ 23 > [ 0.493428] PM: Writing back config space on device 0000:03:01.2 at > offset f (was 200, writing 209) > [ 0.493449] PM: Writing back config space on device 0000:03:01.2 at > offset 4 (was 0, writing ef9fd500) > [ 0.493459] PM: Writing back config space on device 0000:03:01.2 at > offset 1 (was 2100000, writing 2100106) > [ 0.493480] PM: Writing back config space on device 0000:03:01.3 at > offset f (was 200, writing 209) > [ 0.493500] PM: Writing back config space on device 0000:03:01.3 at > offset 4 (was 0, writing ef9fd600) > [ 0.493509] PM: Writing back config space on device 0000:03:01.3 at > offset 1 (was 2100000, writing 2100102) > [ 0.493530] PM: Writing back config space on device 0000:03:01.4 at > offset f (was 200, writing 209) > [ 0.493550] PM: Writing back config space on device 0000:03:01.4 at > offset 4 (was 0, writing ef9fd700) > [ 0.493559] PM: Writing back config space on device 0000:03:01.4 at > offset 1 (was 2100000, writing 2100102) > [ 0.493599] pciehp_resume ENTRY > [ 0.493633] pciehp_resume ENTRY > [ 0.503412] ata2.00: configured for UDMA/33 > [ 0.505628] pciehp: Device 0000:0c:00.0 already exists at c:0, cannot > hot-add > [ 0.505633] pciehp: Cannot add device 0xc:0 > [ 0.505654] pciehp_resume ENTRY > [ 0.505972] sd 0:0:0:0: [sda] Starting disk > [ 0.601233] ata1.00: configured for UDMA/133 > [ 0.624888] sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors > (160042 MB) > [ 0.624910] sd 0:0:0:0: [sda] Write Protect is off > [ 0.624914] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 > [ 0.624943] sd 0:0:0:0: [sda] Write cache: enabled, read cache: > enabled, doesn't support DPO or FUA > [ 0.801255] b44: eth0: Link is up at 100 Mbps, full duplex. > [ 0.801260] b44: eth0: Flow control is off for TX and off for RX. > [ 0.834760] Restarting tasks ... <6>usb 5-1: USB disconnect, address 17 > [ 0.972042] done. > [ 0.998126] usb 5-1: new high speed USB device using ehci_hcd and > address 21 > [ 1.121762] usb 5-1: configuration #1 chosen from 1 choice > [ 1.121912] hub 5-1:1.0: USB hub found > [ 1.121994] hub 5-1:1.0: 4 ports detected > [ 1.224647] usb 5-7: USB disconnect, address 18 > [ 1.224651] usb 5-7.1: USB disconnect, address 20 > [ 1.334249] usb 5-7: new high speed USB device using ehci_hcd and > address 22 > [ 1.479331] usb 5-7: configuration #1 chosen from 1 choice > [ 1.479760] hub 5-7:1.0: USB hub found > [ 1.480770] hub 5-7:1.0: 4 ports detected > [ 1.782796] usb 5-1.4: new full speed USB device using ehci_hcd and > address 23 > [ 1.884536] usb 5-1.4: configuration #1 chosen from 1 choice > [ 2.079252] usb 5-7.1: new low speed USB device using ehci_hcd and > address 24 > [ 2.166603] usb 5-7.1: configuration #1 chosen from 1 choice > [ 2.169524] input: Logitech Optical USB Mouse as /class/input/input11 > [ 2.170506] input: USB HID v1.10 Mouse [Logitech Optical USB Mouse] > on usb-0000:00:1d.7-7.1 > > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > HERE IS THE SLOW RESUME LOG. Note the 1-second pauses.. > > > [ 3725.539992] CPU1 is down > [ 0.354353] Back to C! > [ 0.354793] Enabling non-boot CPUs ... > [ 0.389097] SMP alternatives: switching to SMP code > [ 0.389884] Booting processor 1/1 eip 3000 > [ 0.389886] CPU 1 irqstacks, hard=c0375000 soft=c0373000 > [ 0.401516] Initializing CPU#1 > [ 0.482207] Calibrating delay using timer specific routine.. 4324.78 > BogoMIPS (lpj=7204462) > [ 0.482212] CPU: After generic identify, caps: bfebfbff 20100000 > 00000000 00000000 0000e3bd 00000000 00000001 00000000 > [ 0.482217] monitor/mwait feature present. > [ 0.482219] CPU: L1 I cache: 32K, L1 D cache: 32K > [ 0.482221] CPU: L2 cache: 4096K > [ 0.482222] CPU: Physical Processor ID: 0 > [ 0.482223] CPU: Processor Core ID: 1 > [ 0.482225] CPU: After all inits, caps: bfebfbff 20100000 00000000 > 00003940 0000e3bd 00000000 00000001 00000000 > [ 0.482814] CPU1: Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz > stepping 06 > [ 0.483053] CPU1 is up > [ 0.486165] Switched to high resolution mode on CPU 1 > [ 0.490338] PM: Writing back config space on device 0000:00:01.0 at > offset a (was f, writing 0) > [ 0.490342] PM: Writing back config space on device 0000:00:01.0 at > offset 7 (was e0e0, writing 2000e0e0) > [ 0.490345] PM: Writing back config space on device 0000:00:01.0 at > offset 3 (was 10000, writing 10010) > [ 0.490351] PCI: Setting latency timer of device 0000:00:01.0 to 64 > [ 0.490605] PM: Writing back config space on device 0000:00:1b.0 at > offset f (was 100, writing 10b) > [ 0.490626] PM: Writing back config space on device 0000:00:1b.0 at > offset 4 (was ffa7c004, writing efffc004) > [ 0.490632] PM: Writing back config space on device 0000:00:1b.0 at > offset 3 (was 0, writing 10) > [ 0.490640] PM: Writing back config space on device 0000:00:1b.0 at > offset 1 (was 100000, writing 100102) > [ 0.490665] ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 21 (level, > low) -> IRQ 20 > [ 0.490674] PCI: Setting latency timer of device 0000:00:1b.0 to 64 > [ 1.492418] PM: Writing back config space on device 0000:00:1c.0 at > offset f (was 100, writing 20100) > [ 1.492432] PM: Writing back config space on device 0000:00:1c.0 at > offset 9 (was 10001, writing 1fff1) > [ 1.492438] PM: Writing back config space on device 0000:00:1c.0 at > offset 8 (was 0, writing fff0) > [ 1.492445] PM: Writing back config space on device 0000:00:1c.0 at > offset 7 (was 0, writing f0) > [ 1.492451] PM: Writing back config space on device 0000:00:1c.0 at > offset 6 (was 0, writing b0b00) > [ 1.492460] PM: Writing back config space on device 0000:00:1c.0 at > offset 3 (was 810000, writing 810010) > [ 1.492468] PM: Writing back config space on device 0000:00:1c.0 at > offset 1 (was 100000, writing 100007) > [ 1.492490] PCI: Setting latency timer of device 0000:00:1c.0 to 64 > [ 1.492496] pciehp_resume ENTRY > [ 1.492539] PM: Writing back config space on device 0000:00:1c.1 at > offset f (was 200, writing 20200) > [ 1.492552] PM: Writing back config space on device 0000:00:1c.1 at > offset 9 (was 10001, writing 1fff1) > [ 1.492559] PM: Writing back config space on device 0000:00:1c.1 at > offset 8 (was 0, writing efc0efc0) > [ 1.492565] PM: Writing back config space on device 0000:00:1c.1 at > offset 7 (was 20000000, writing f0) > [ 1.492572] PM: Writing back config space on device 0000:00:1c.1 at > offset 6 (was 0, writing c0c00) > [ 1.492581] PM: Writing back config space on device 0000:00:1c.1 at > offset 3 (was 810000, writing 810010) > [ 1.492588] PM: Writing back config space on device 0000:00:1c.1 at > offset 1 (was 100000, writing 100107) > [ 1.492610] PCI: Setting latency timer of device 0000:00:1c.1 to 64 > [ 1.492615] pciehp_resume ENTRY > [ 1.493885] pciehp: Device 0000:0c:00.0 already exists at c:0, cannot > hot-add > [ 1.493889] pciehp: Cannot add device 0xc:0 > [ 1.493916] PM: Writing back config space on device 0000:00:1c.3 at > offset f (was 400, writing 20400) > [ 1.493929] PM: Writing back config space on device 0000:00:1c.3 at > offset 9 (was 10001, writing e011e001) > [ 1.493936] PM: Writing back config space on device 0000:00:1c.3 at > offset 8 (was 0, writing efb0efa0) > [ 1.493942] PM: Writing back config space on device 0000:00:1c.3 at > offset 7 (was 0, writing d0d0) > [ 1.493949] PM: Writing back config space on device 0000:00:1c.3 at > offset 6 (was 0, writing e0d00) > [ 1.493958] PM: Writing back config space on device 0000:00:1c.3 at > offset 3 (was 810000, writing 810010) > [ 1.493966] PM: Writing back config space on device 0000:00:1c.3 at > offset 1 (was 100000, writing 100007) > [ 1.493987] PCI: Setting latency timer of device 0000:00:1c.3 to 64 > [ 1.493992] pciehp_resume ENTRY > [ 1.494028] ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 20 (level, > low) -> IRQ 19 > [ 1.494036] PCI: Setting latency timer of device 0000:00:1d.0 to 64 > [ 1.494088] usb usb1: root hub lost power or was reset > [ 1.494110] PCI: Enabling device 0000:00:1d.1 (0000 -> 0001) > [ 1.494114] ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 21 (level, > low) -> IRQ 20 > [ 1.494122] PCI: Setting latency timer of device 0000:00:1d.1 to 64 > [ 1.494130] PM: Writing back config space on device 0000:00:1d.1 at > offset f (was 200, writing 20b) > [ 1.494144] PM: Writing back config space on device 0000:00:1d.1 at > offset 8 (was 1, writing bf61) > [ 1.494180] usb usb2: root hub lost power or was reset > [ 1.494202] PCI: Enabling device 0000:00:1d.2 (0000 -> 0001) > [ 1.494206] ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 22 (level, > low) -> IRQ 21 > [ 1.494214] PCI: Setting latency timer of device 0000:00:1d.2 to 64 > [ 1.494222] PM: Writing back config space on device 0000:00:1d.2 at > offset f (was 300, writing 309) > [ 1.494236] PM: Writing back config space on device 0000:00:1d.2 at > offset 8 (was 1, writing bf41) > [ 1.494273] usb usb3: root hub lost power or was reset > [ 1.494295] PCI: Enabling device 0000:00:1d.3 (0000 -> 0001) > [ 1.494299] ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 23 (level, > low) -> IRQ 22 > [ 1.494307] PCI: Setting latency timer of device 0000:00:1d.3 to 64 > [ 1.494314] PM: Writing back config space on device 0000:00:1d.3 at > offset f (was 400, writing 407) > [ 1.494328] PM: Writing back config space on device 0000:00:1d.3 at > offset 8 (was 1, writing bf21) > [ 1.494365] usb usb4: root hub lost power or was reset > [ 1.496460] ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 20 (level, > low) -> IRQ 19 > [ 1.496468] PCI: Setting latency timer of device 0000:00:1d.7 to 64 > [ 1.496534] PM: Writing back config space on device 0000:00:1e.0 at > offset 9 (was 100f1, writing 1fff1) > [ 1.496542] PM: Writing back config space on device 0000:00:1e.0 at > offset 8 (was 90, writing ef90ef90) > [ 1.496551] PM: Writing back config space on device 0000:00:1e.0 at > offset 7 (was 2280e0f0, writing 228000f0) > [ 1.496570] PM: Writing back config space on device 0000:00:1e.0 at > offset 1 (was 100007, writing 100107) > [ 1.496590] PCI: Setting latency timer of device 0000:00:1e.0 to 64 > [ 1.496629] PM: Writing back config space on device 0000:00:1f.0 at > offset 1 (was 2100007, writing 2100107) > [ 1.745307] PM: Writing back config space on device 0000:00:1f.2 at > offset f (was 200, writing 205) > [ 1.745344] ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 17 (level, > low) -> IRQ 17 > [ 1.745351] PCI: Setting latency timer of device 0000:00:1f.2 to 64 > [ 1.745369] PM: Writing back config space on device 0000:00:1f.3 at > offset f (was 200, writing 205) > [ 1.745406] PM: Writing back config space on device 0000:00:1f.3 at > offset 1 (was 2800001, writing 2800101) > [ 1.745430] PM: Writing back config space on device 0000:01:00.0 at > offset f (was 1ff, writing 104) > [ 1.745453] PM: Writing back config space on device 0000:01:00.0 at > offset 3 (was 0, writing 10) > [ 1.745514] PM: Writing back config space on device 0000:0c:00.0 at > offset f (was 100, writing 105) > [ 1.745584] PM: Writing back config space on device 0000:0c:00.0 at > offset 4 (was 0, writing efcff000) > [ 1.745600] PM: Writing back config space on device 0000:0c:00.0 at > offset 3 (was 0, writing 10) > [ 1.745623] PM: Writing back config space on device 0000:0c:00.0 at > offset 1 (was 100000, writing 100106) > [ 1.745709] PM: Writing back config space on device 0000:03:00.0 at > offset f (was 100, writing 105) > [ 1.745729] PM: Writing back config space on device 0000:03:00.0 at > offset 4 (was 0, writing ef9fe000) > [ 1.745735] PM: Writing back config space on device 0000:03:00.0 at > offset 3 (was 0, writing 4000) > [ 1.745743] PM: Writing back config space on device 0000:03:00.0 at > offset 1 (was 100000, writing 100106) > [ 1.745765] ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, > low) -> IRQ 17 > [ 2.753018] PM: Writing back config space on device 0000:03:01.0 at > offset f (was 4020100, writing 4020103) > [ 2.753038] PM: Writing back config space on device 0000:03:01.0 at > offset 4 (was 0, writing ef9fd800) > [ 2.753045] PM: Writing back config space on device 0000:03:01.0 at > offset 3 (was 800000, writing 804000) > [ 2.753053] PM: Writing back config space on device 0000:03:01.0 at > offset 1 (was 2100000, writing 2100106) > [ 3.756771] ata1.00: configured for UDMA/133 > [ 3.756818] sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors > (160042 MB) > [ 3.756836] sd 0:0:0:0: [sda] Write Protect is off > [ 3.756840] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 > [ 3.756868] sd 0:0:0:0: [sda] Write cache: enabled, read cache: > enabled, doesn't support DPO or FUA > [ 4.763813] b44: eth0: Link is up at 100 Mbps, full duplex. > [ 4.763817] b44: eth0: Flow control is off for TX and off for RX. > [ 4.764090] PM: Writing back config space on device 0000:03:01.1 at > offset f (was 200, writing 209) > [ 4.764111] PM: Writing back config space on device 0000:03:01.1 at > offset 4 (was 0, writing ef9fd400) > [ 4.764118] PM: Writing back config space on device 0000:03:01.1 at > offset 3 (was 800000, writing 804000) > [ 4.764126] PM: Writing back config space on device 0000:03:01.1 at > offset 1 (was 2100000, writing 2100106) > [ 4.764145] ACPI: PCI Interrupt 0000:03:01.1[B] -> GSI 18 (level, > low) -> IRQ 23 > [ 4.764171] PM: Writing back config space on device 0000:03:01.2 at > offset f (was 200, writing 209) > [ 4.764191] PM: Writing back config space on device 0000:03:01.2 at > offset 4 (was 0, writing ef9fd500) > [ 4.764201] PM: Writing back config space on device 0000:03:01.2 at > offset 1 (was 2100000, writing 2100106) > [ 4.764222] PM: Writing back config space on device 0000:03:01.3 at > offset f (was 200, writing 209) > [ 4.764242] PM: Writing back config space on device 0000:03:01.3 at > offset 4 (was 0, writing ef9fd600) > [ 4.764251] PM: Writing back config space on device 0000:03:01.3 at > offset 1 (was 2100000, writing 2100102) > [ 4.764273] PM: Writing back config space on device 0000:03:01.4 at > offset f (was 200, writing 209) > [ 4.764293] PM: Writing back config space on device 0000:03:01.4 at > offset 4 (was 0, writing ef9fd700) > [ 4.764303] PM: Writing back config space on device 0000:03:01.4 at > offset 1 (was 2100000, writing 2100102) > [ 4.764340] pciehp_resume ENTRY > [ 4.764369] pciehp_resume ENTRY > [ 5.765432] ata2.00: configured for UDMA/33 > [ 5.767529] pciehp: Device 0000:0c:00.0 already exists at c:0, cannot > hot-add > [ 5.767532] pciehp: Cannot add device 0xc:0 > [ 5.767547] pciehp_resume ENTRY > [ 5.767864] sd 0:0:0:0: [sda] Starting disk > [ 7.750047] Restarting tasks ... done. > [ 7.830571] usb 5-1: USB disconnect, address 21 > [ 8.126832] usb 5-1: new high speed USB device using ehci_hcd and > address 25 > [ 10.230397] usb 5-1: configuration #1 chosen from 1 choice > [ 10.230517] hub 5-1:1.0: USB hub found > [ 10.230545] hub 5-1:1.0: 4 ports detected > [ 10.281481] usb 5-7: USB disconnect, address 22 > [ 10.281489] usb 5-7.1: USB disconnect, address 24 > [ 10.889785] usb 5-7: new high speed USB device using ehci_hcd and > address 26 > [ 11.658319] usb 5-7: configuration #1 chosen from 1 choice > [ 11.658631] hub 5-7:1.0: USB hub found > [ 11.658985] hub 5-7:1.0: 4 ports detected > [ 13.190055] usb 5-1.4: new full speed USB device using ehci_hcd and > address 27 > [ 13.961678] usb 5-1.4: configuration #1 chosen from 1 choice > [ 14.171766] usb 5-7.1: new low speed USB device using ehci_hcd and > address 28 > [ 14.295838] usb 5-7.1: configuration #1 chosen from 1 choice > [ 14.298596] input: Logitech Optical USB Mouse as /class/input/input12 > [ 14.299091] input: USB HID v1.10 Mouse [Logitech Optical USB Mouse] > on usb-0000:00:1d.7-7.1 .. This is still happening. I was hoping my PCIe hotplug bug+fix might have been related, but no it happened just now after that fix. Since Ingo's latency trace patches lock up the machine on resume, the next thing I'll try instead is to re-enable CONFIG_IRQBALANCE=y. I think that I turned that flag off at around the same time as this problem began, maybe they're related (?). I did notice that CONFIG_IRQBALANCE=y *is* necessary to keep my myth box from having 1-second audio dropouts (2.6.23.1) during playback, so maybe that same 1-second lockout is happening on this box as well (?). Cheers ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-18 16:10 ` Mark Lord @ 2007-11-18 16:21 ` Ingo Molnar 2007-11-18 17:37 ` Mark Lord 0 siblings, 1 reply; 268+ messages in thread From: Ingo Molnar @ 2007-11-18 16:21 UTC (permalink / raw) To: Mark Lord Cc: Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, Linux Kernel, linux-pm, rjw * Mark Lord <lkml@rtr.ca> wrote: > Since Ingo's latency trace patches lock up the machine on resume, the > next thing I'll try instead is to re-enable CONFIG_IRQBALANCE=y. hm, which patch did you try? Could you check whether all chunks from the patch below are applied? (these are the fixed i did when i was doing cross-suspend traces - this is not something i've done before, so the tracer had to be adjusted) i suspect if you turn off CONFIG_FUNCTION_TRACING then you wont get any hung resume - and the resulting trace would still be pretty useful. (it will show scheduling and irq activities, etc.) Ingo --- arch/x86/kernel/stacktrace.c | 2 +- arch/x86/power/cpu.c | 3 ++- drivers/acpi/namespace/nsutils.c | 2 +- drivers/acpi/namespace/nswalk.c | 2 +- include/linux/sched.h | 2 ++ kernel/latency_trace.c | 26 +++++++++++++++++++++++--- kernel/softirq.c | 6 +++--- 7 files changed, 33 insertions(+), 10 deletions(-) Index: linux/arch/x86/kernel/stacktrace.c =================================================================== --- linux.orig/arch/x86/kernel/stacktrace.c +++ linux/arch/x86/kernel/stacktrace.c @@ -22,7 +22,7 @@ static int save_stack_stack(void *data, return -1; } -static void save_stack_address(void *data, unsigned long addr) +static void notrace save_stack_address(void *data, unsigned long addr) { struct stack_trace *trace = (struct stack_trace *)data; if (trace->skip > 0) { Index: linux/arch/x86/power/cpu.c =================================================================== --- linux.orig/arch/x86/power/cpu.c +++ linux/arch/x86/power/cpu.c @@ -123,8 +123,9 @@ void __restore_processor_state(struct sa mcheck_init(&boot_cpu_data); } -void restore_processor_state(void) +void notrace restore_processor_state(void) { + trace_resume(); __restore_processor_state(&saved_context); } Index: linux/drivers/acpi/namespace/nsutils.c =================================================================== --- linux.orig/drivers/acpi/namespace/nsutils.c +++ linux/drivers/acpi/namespace/nsutils.c @@ -923,7 +923,7 @@ struct acpi_namespace_node *acpi_ns_get_ * ******************************************************************************/ -struct acpi_namespace_node *acpi_ns_get_next_valid_node(struct +struct acpi_namespace_node * notrace acpi_ns_get_next_valid_node(struct acpi_namespace_node *node) { Index: linux/drivers/acpi/namespace/nswalk.c =================================================================== --- linux.orig/drivers/acpi/namespace/nswalk.c +++ linux/drivers/acpi/namespace/nswalk.c @@ -65,7 +65,7 @@ ACPI_MODULE_NAME("nswalk") * within Scope is returned. * ******************************************************************************/ -struct acpi_namespace_node *acpi_ns_get_next_node(acpi_object_type type, struct acpi_namespace_node +struct acpi_namespace_node * notrace acpi_ns_get_next_node(acpi_object_type type, struct acpi_namespace_node *parent_node, struct acpi_namespace_node *child_node) { Index: linux/include/linux/sched.h =================================================================== --- linux.orig/include/linux/sched.h +++ linux/include/linux/sched.h @@ -337,6 +337,7 @@ static inline void touch_all_softlockup_ extern long user_trace_stop(void); extern void trace_cmdline(void); extern void init_tracer(void); + extern void trace_resume(void); #else # define mcount_enabled 0 # define trace_enabled 0 @@ -358,6 +359,7 @@ static inline void touch_all_softlockup_ # define user_trace_stop() do { } while (0) # define trace_cmdline() do { } while (0) # define init_tracer() do { } while (0) +# define trace_resume() do { } while (0) #endif #ifdef CONFIG_WAKEUP_TIMING Index: linux/kernel/latency_trace.c =================================================================== --- linux.orig/kernel/latency_trace.c +++ linux/kernel/latency_trace.c @@ -258,19 +258,28 @@ static struct cpu_trace cpu_traces[NR_CP #endif } }; -static notrace cycle_t now(struct cpu_trace *tr, int monotonic) +static inline notrace cycle_t __now(int monotonic) { - cycles_t now, delta, last = tr->last_cycles; + cycles_t now; if (trace_use_raw_cycles && !monotonic) now = get_cycles(); else now = get_monotonic_cycles(); + return now; +} + +static notrace cycle_t now(struct cpu_trace *tr, int monotonic) +{ + cycles_t now, delta, last = tr->last_cycles; + + now = __now(monotonic); + /* * Protect against time warps: */ - if (unlikely(now < last)) + if (unlikely(now < last || !last)) delta = 1; else delta = now - last; @@ -281,6 +290,17 @@ static notrace cycle_t now(struct cpu_tr return tr->cycles; } +/* + * Resume callback - ignore any time spent resumed: + * (the clocksource readout might be unreliable anyway) + */ +void notrace trace_resume(void) +{ + struct cpu_trace *tr = cpu_traces + raw_smp_processor_id(); + + tr->last_cycles = 0; + mcount(); +} #ifdef CONFIG_EVENT_TRACE Index: linux/kernel/softirq.c =================================================================== --- linux.orig/kernel/softirq.c +++ linux/kernel/softirq.c @@ -91,7 +91,7 @@ static inline void __local_bh_disable(un } #endif /* CONFIG_TRACE_IRQFLAGS */ -void local_bh_disable(void) +void notrace local_bh_disable(void) { __local_bh_disable((unsigned long)__builtin_return_address(0)); } @@ -129,7 +129,7 @@ void _local_bh_enable(void) EXPORT_SYMBOL(_local_bh_enable); -void local_bh_enable(void) +void notrace local_bh_enable(void) { #ifdef CONFIG_TRACE_IRQFLAGS unsigned long flags; @@ -163,7 +163,7 @@ void local_bh_enable(void) } EXPORT_SYMBOL(local_bh_enable); -void local_bh_enable_ip(unsigned long ip) +void notrace local_bh_enable_ip(unsigned long ip) { #ifdef CONFIG_TRACE_IRQFLAGS unsigned long flags; ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] Strange 1-second pauses during Resume-from-RAM 2007-11-18 16:21 ` Ingo Molnar @ 2007-11-18 17:37 ` Mark Lord 0 siblings, 0 replies; 268+ messages in thread From: Mark Lord @ 2007-11-18 17:37 UTC (permalink / raw) To: Ingo Molnar Cc: Mark Lord, Thomas Gleixner, len.brown, Andrew Morton, Linux Kernel, linux-pm, rjw Ingo Molnar wrote: > * Mark Lord <lkml@rtr.ca> wrote: > >> Since Ingo's latency trace patches lock up the machine on resume, the >> next thing I'll try instead is to re-enable CONFIG_IRQBALANCE=y. > > hm, which patch did you try? Could you check whether all chunks from the > patch below are applied? (these are the fixed i did when i was doing > cross-suspend traces - this is not something i've done before, so the > tracer had to be adjusted) .. Hi Ingo! I was using your 2.6.23.1 version of the patches, plus the fix you posted. The new patch you gave just now is for 2.6.24, which won't apply to the older kernel. I'm not switching kernels yet, as doing so might mask the problem without actually resolving it for good. Cheers ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 16:07 ` Thomas Gleixner 2007-11-13 17:47 ` Mark Lord @ 2007-11-13 17:54 ` Mark Lord 2007-11-13 22:46 ` Thomas Gleixner 2007-11-13 18:10 ` Russell King 2 siblings, 1 reply; 268+ messages in thread From: Mark Lord @ 2007-11-13 17:54 UTC (permalink / raw) To: Thomas Gleixner Cc: Andrew Morton, Natalie Protasevich, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon Thomas Gleixner wrote: > On Tue, 13 Nov 2007, Mark Lord wrote: > >> > Andrew Morton wrote: >>> > > On Mon, 12 Nov 2007 22:42:32 -0800 "Natalie Protasevich" >>> > > <protasnb@gmail.com> wrote: >> > .. >>>> > > > with CONFIG_NO_HZ and/or CONFIG_HPET_TIMER set kernel 2.6.23 doesn't >>>> > > > boot (ARM, Timer) >>>> > > > http://bugzilla.kernel.org/show_bug.cgi?id=9229 >>>> > > > Kernel: 2.6.23 >>> > > >>> > > No response from developers >> > .. > > The bug report is bogus. ARM has no CONFIG_HPET_TIMER. > >> > Note: that same bug exists/existed on i386 back when NO_HZ was >> > introduced (2.6.21?). I still see it from time to time on my Quad core >> > system (very rare), but not any more on my Duo notebook where it used >> > to happen about 1 in n boots (n < 10). >> > >> > AFAICT no fix was ever released for it. > > Hmm, at which point does the boot stop ? .. Just as it prints out these messages, sometimes one of them, sometimes both (or all four on the quad core): kernel: switched to high resolution mode on cpu 1 kernel: switched to high resolution mode on cpu 0 ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 17:54 ` [BUG] New Kernel Bugs Mark Lord @ 2007-11-13 22:46 ` Thomas Gleixner 2007-11-13 23:37 ` Mark Lord 0 siblings, 1 reply; 268+ messages in thread From: Thomas Gleixner @ 2007-11-13 22:46 UTC (permalink / raw) To: Mark Lord Cc: Andrew Morton, Natalie Protasevich, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tue, 13 Nov 2007, Mark Lord wrote: > Thomas Gleixner wrote: > > On Tue, 13 Nov 2007, Mark Lord wrote: > > > > > > Andrew Morton wrote: > > > > > > On Mon, 12 Nov 2007 22:42:32 -0800 "Natalie Protasevich" > > > > > > <protasnb@gmail.com> wrote: > > > > .. > > > > > > > > with CONFIG_NO_HZ and/or CONFIG_HPET_TIMER set kernel 2.6.23 > > > > > doesn't > > > > > > > > boot (ARM, Timer) > > > > > > > > http://bugzilla.kernel.org/show_bug.cgi?id=9229 > > > > > > > > Kernel: 2.6.23 > > > > > > > > No response from developers > > > > .. > > > > The bug report is bogus. ARM has no CONFIG_HPET_TIMER. > > > > Note: that same bug exists/existed on i386 back when NO_HZ was > > > > introduced (2.6.21?). I still see it from time to time on my Quad core > > > > system (very rare), but not any more on my Duo notebook where it used > > > > to happen about 1 in n boots (n < 10). > > > > > AFAICT no fix was ever released for it. > > > > Hmm, at which point does the boot stop ? > .. > > Just as it prints out these messages, sometimes one of them, > sometimes both (or all four on the quad core): > > kernel: switched to high resolution mode on cpu 1 > kernel: switched to high resolution mode on cpu 0 It's completely dead afterwards ? tglx ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 22:46 ` Thomas Gleixner @ 2007-11-13 23:37 ` Mark Lord 0 siblings, 0 replies; 268+ messages in thread From: Mark Lord @ 2007-11-13 23:37 UTC (permalink / raw) To: Thomas Gleixner Cc: Andrew Morton, Natalie Protasevich, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon Thomas Gleixner wrote: > On Tue, 13 Nov 2007, Mark Lord wrote: > >> Thomas Gleixner wrote: >>> On Tue, 13 Nov 2007, Mark Lord wrote: >>> >>>>> Andrew Morton wrote: >>>>>>> On Mon, 12 Nov 2007 22:42:32 -0800 "Natalie Protasevich" >>>>>>> <protasnb@gmail.com> wrote: >>>>> .. >>>>>>>>> with CONFIG_NO_HZ and/or CONFIG_HPET_TIMER set kernel 2.6.23 >>>>>> doesn't >>>>>>>>> boot (ARM, Timer) >>>>>>>>> http://bugzilla.kernel.org/show_bug.cgi?id=9229 >>>>>>>>> Kernel: 2.6.23 >>>>>>>>> No response from developers >>>>> .. >>> The bug report is bogus. ARM has no CONFIG_HPET_TIMER. >>>>> Note: that same bug exists/existed on i386 back when NO_HZ was >>>>> introduced (2.6.21?). I still see it from time to time on my Quad core >>>>> system (very rare), but not any more on my Duo notebook where it used >>>>> to happen about 1 in n boots (n < 10). >>>>>> AFAICT no fix was ever released for it. >>> Hmm, at which point does the boot stop ? >> .. >> >> Just as it prints out these messages, sometimes one of them, >> sometimes both (or all four on the quad core): >> >> kernel: switched to high resolution mode on cpu 1 >> kernel: switched to high resolution mode on cpu 0 > > It's completely dead afterwards ? Yeah. No magic sysrq key or anything. There's gotta be a race somewhere that's causing it, but it's not obvious where to look for it. My regular 2-core notebook no longer suffers from it, and subtle .config changes used to make it come and go back when it first appeared. The quad-core has only done it twice on me thus far. Tracking this one down looks tricky. It might require some early lockup detection code to be tailor made or something. Cheers ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 16:07 ` Thomas Gleixner 2007-11-13 17:47 ` Mark Lord 2007-11-13 17:54 ` [BUG] New Kernel Bugs Mark Lord @ 2007-11-13 18:10 ` Russell King 2007-11-13 18:25 ` Alan Cox 2 siblings, 1 reply; 268+ messages in thread From: Russell King @ 2007-11-13 18:10 UTC (permalink / raw) To: Thomas Gleixner Cc: Mark Lord, alsa-devel, netdev, linux-pcmcia, linux-kernel, Natalie Protasevich, linux-ide, bugme-daemon, linux-input, Andrew Morton On Tue, Nov 13, 2007 at 05:07:21PM +0100, Thomas Gleixner wrote: > On Tue, 13 Nov 2007, Mark Lord wrote: > > > Andrew Morton wrote: > > > On Mon, 12 Nov 2007 22:42:32 -0800 "Natalie Protasevich" > > > <protasnb@gmail.com> wrote: > > .. > > > > with CONFIG_NO_HZ and/or CONFIG_HPET_TIMER set kernel 2.6.23 doesn't > > > > boot (ARM, Timer) > > > > http://bugzilla.kernel.org/show_bug.cgi?id=9229 > > > > Kernel: 2.6.23 > > > > > > No response from developers > > .. > > The bug report is bogus. ARM has no CONFIG_HPET_TIMER. Plus we've just merged a fix for NO_HZ on PXA platforms due to an utterly broken one-shot implementation. So chances are this problem is now fixed. However, I object strongly to Andrew's responses to these bugs. He's completely out of line. Given the wide range of ARM platforms today, it is utterly idiotic to expect a single person to be able to provide responses for all ARM bugs. I for one wish I'd never *VOLUNTEERED* to be a part of the kernel bugzilla, and really *WISH* I could pull out of that function. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 18:10 ` Russell King @ 2007-11-13 18:25 ` Alan Cox 2007-11-13 22:34 ` Russell King 0 siblings, 1 reply; 268+ messages in thread From: Alan Cox @ 2007-11-13 18:25 UTC (permalink / raw) To: Russell King Cc: Thomas Gleixner, Mark Lord, alsa-devel, netdev, linux-pcmcia, linux-kernel, Natalie Protasevich, linux-ide, bugme-daemon, linux-input, Andrew Morton > Given the wide range of ARM platforms today, it is utterly idiotic to > expect a single person to be able to provide responses for all ARM bugs. > I for one wish I'd never *VOLUNTEERED* to be a part of the kernel > bugzilla, and really *WISH* I could pull out of that function. You can. Perhaps that bugzilla needs to point to some kind of arm-maintainers@vger.kernel.org list for the various ARM platform maintainers ? Alan ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 18:25 ` Alan Cox @ 2007-11-13 22:34 ` Russell King 2007-11-15 20:16 ` Ben Dooks 0 siblings, 1 reply; 268+ messages in thread From: Russell King @ 2007-11-13 22:34 UTC (permalink / raw) To: Alan Cox Cc: Thomas Gleixner, Mark Lord, alsa-devel, netdev, linux-pcmcia, linux-kernel, Natalie Protasevich, linux-ide, bugme-daemon, linux-input, Andrew Morton On Tue, Nov 13, 2007 at 06:25:16PM +0000, Alan Cox wrote: > > Given the wide range of ARM platforms today, it is utterly idiotic to > > expect a single person to be able to provide responses for all ARM bugs. > > I for one wish I'd never *VOLUNTEERED* to be a part of the kernel > > bugzilla, and really *WISH* I could pull out of that function. > > You can. Perhaps that bugzilla needs to point to some kind of > arm-maintainers@vger.kernel.org list for the various ARM platform > maintainers ? That might work - though it would be hard to get all the platform maintainers to be signed up to yet another mailing list, I'm sure sufficient would do. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 22:34 ` Russell King @ 2007-11-15 20:16 ` Ben Dooks 0 siblings, 0 replies; 268+ messages in thread From: Ben Dooks @ 2007-11-15 20:16 UTC (permalink / raw) To: Alan Cox, Thomas Gleixner, Mark Lord, alsa-devel, netdev, linux-pcmcia, linux-kernel, Natalie Protasevich, linux-ide, bugme-daemon, linux-input, Andrew Morton On Tue, Nov 13, 2007 at 10:34:37PM +0000, Russell King wrote: > On Tue, Nov 13, 2007 at 06:25:16PM +0000, Alan Cox wrote: > > > Given the wide range of ARM platforms today, it is utterly idiotic to > > > expect a single person to be able to provide responses for all ARM bugs. > > > I for one wish I'd never *VOLUNTEERED* to be a part of the kernel > > > bugzilla, and really *WISH* I could pull out of that function. > > > > You can. Perhaps that bugzilla needs to point to some kind of > > arm-maintainers@vger.kernel.org list for the various ARM platform > > maintainers ? > > That might work - though it would be hard to get all the platform > maintainers to be signed up to yet another mailing list, I'm sure > sufficient would do. As long as it would just be bug reports, I'm sure that most of us could be persuaded to subscribe. Adding another list for general discussions is probably not going to be read, the current list provides more than enough to keep us busy. -- Ben Q: What's a light-year? A: One-third less calories than a regular year. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 11:15 ` Andrew Morton ` (4 preceding siblings ...) 2007-11-13 13:58 ` Mark Lord @ 2007-11-13 15:21 ` Bartlomiej Zolnierkiewicz 2007-11-13 15:33 ` James Bottomley ` (5 subsequent siblings) 11 siblings, 0 replies; 268+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2007-11-13 15:21 UTC (permalink / raw) To: Andrew Morton Cc: Natalie Protasevich, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Nov 13, 2007 12:15 PM, Andrew Morton <akpm@linux-foundation.org> wrote: > On Mon, 12 Nov 2007 22:42:32 -0800 "Natalie Protasevich" <protasnb@gmail.com> wrote: > > > This is the listing of the open bugs that are relatively new, around > > 2.6.22 and up. They are vaguely classified by specific area. > > (not a full list, there are more :) [...] > > IDE/SATA========================================================= [...] > > DVD-RAM umount and disk free bug > > http://bugzilla.kernel.org/show_bug.cgi?id=9265 > > Kernel: 2.6.15 (asked to try current kernel) > > No response from developers Bug was filled under IO/Storage-Other so is it assigned to <other_other@kernel-bugs.osdl.org>. Could be a FS problem as well but it is the best to wait for confirmation with 2.6.23 before proceeding further... ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 11:15 ` Andrew Morton ` (5 preceding siblings ...) 2007-11-13 15:21 ` Bartlomiej Zolnierkiewicz @ 2007-11-13 15:33 ` James Bottomley 2007-11-13 16:43 ` Randy Dunlap 2007-11-13 17:46 ` Martin Bligh 2007-11-13 15:36 ` Alan Cox ` (4 subsequent siblings) 11 siblings, 2 replies; 268+ messages in thread From: James Bottomley @ 2007-11-13 15:33 UTC (permalink / raw) To: Andrew Morton Cc: Natalie Protasevich, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon, linux-scsi On Tue, 2007-11-13 at 03:15 -0800, Andrew Morton wrote: > > > SCSI================================================================== > > > > qla2xxx: driver initialization does not complete when booting with > > Port connected > > http://bugzilla.kernel.org/show_bug.cgi?id=9267 > > Kernel: 2.6.23.1 > > No response from developers Urm, well, if no-one ever tells the SCSI list it's unrealistic to expect anyone to be working on it. As far as I can tell, email was sent to Andrew Vasquez only on 31 October. However, the fault looks to be generic, so he probably just dropped it. This seems to be the significant line from the trace: Oct 7 23:35:07 t-host kernel: ISP2422: PCI-X Mode 1 (133 MHz) @ 0000:01:03.0 hdma-, host#=1, fw=4.00.27 [IP] Oct 7 23:35:07 t-host kernel: ACPI: PCI Interrupt 0000:01:03.1[B] -> GSI 29 (level, low) -> IRQ 22 Oct 7 23:35:07 t-host kernel: qla2xxx 0000:01:03.1: Found an ISP2422, irq 22, iobase 0xf8cf4000 Oct 7 23:35:07 t-host kernel: qla2xxx 0000:01:03.1: Configuring PCI space... Oct 7 23:35:07 t-host kernel: qla2xxx 0000:01:03.1: Configure NVRAM parameters... Oct 7 23:35:07 t-host kernel: qla2xxx 0000:01:03.1: Verifying loaded RISC code... Oct 7 23:35:07 t-host kernel: qla2xxx 0000:01:03.1: Allocated (64 KB) for EFT... Oct 7 23:35:07 t-host kernel: qla2xxx 0000:01:03.1: Allocated (1413 KB) for firmware dump... Oct 7 23:35:07 t-host kernel: scsi2 : qla2xxx Oct 7 23:35:07 t-host kernel: qla2xxx 0000:01:03.1: Oct 7 23:35:07 t-host kernel: QLogic Fibre Channel HBA Driver: 8.01.07-k7 Oct 7 23:35:07 t-host kernel: QLogic QLA2462 - PCI-X 2.0 to 4Gb FC, Dual Channel Oct 7 23:35:07 t-host kernel: ISP2422: PCI-X Mode 1 (133 MHz) @ 0000:01:03.1 hdma-, host#=2, fw=4.00.27 [IP] Oct 7 23:35:07 t-host kernel: qla2xxx 0000:01:03.0: LIP reset occured (f8f7). Oct 7 23:35:07 t-host kernel: qla2xxx 0000:01:03.0: LIP occured (f8f7). Oct 7 23:35:07 t-host kernel: qla2xxx 0000:01:03.0: LOOP UP detected (4 Gbps). Oct 7 23:35:07 t-host kernel: ohci_hcd 0000:03:00.0: auto-stop root hub Oct 7 23:35:07 t-host kernel: ohci_hcd 0000:03:00.1: auto-stop root hub Oct 7 23:35:07 t-host kernel: scsi 1:0:0:0: Direct-Access transtec PV610F16R1C 348B PQ: 0 ANSI: 4 Oct 7 23:35:07 t-host kernel: kobject_add failed for 1:0:0:0 with -EEXIST, don't try to register things with the same name in the same directory. Oct 7 23:35:07 t-host kernel: [<c022c841>] kobject_shadow_add+0x111/0x190 Oct 7 23:35:07 t-host kernel: [<c0286814>] device_add+0xc4/0x570 Oct 7 23:35:07 t-host kernel: [<c02c90ce>] scsi_adjust_queue_depth+0x9e/0xf0 Oct 7 23:35:07 t-host kernel: [<c02249b2>] __blk_queue_init_tags+0x32/0x70 Oct 7 23:35:07 t-host kernel: [<c02d302f>] scsi_sysfs_add_sdev+0x4f/0x230 Oct 7 23:35:07 t-host kernel: [<f8d93421>] qla2xxx_slave_configure+0x71/0x100 [qla2xxx] Oct 7 23:35:07 t-host kernel: [<c02d0ecf>] scsi_probe_and_add_lun+0xa5f/0xb40 Oct 7 23:35:07 t-host kernel: [<c02d1559>] __scsi_scan_target+0xd9/0x6c0 Oct 7 23:35:07 t-host kernel: [<c03a5be1>] schedule+0x2e1/0x950 Oct 7 23:35:07 t-host kernel: [<c02d21f9>] scsi_scan_target+0xa9/0xe0 Oct 7 23:35:07 t-host kernel: [<c02d5640>] fc_scsi_scan_rport+0x0/0x80 Oct 7 23:35:07 t-host kernel: [<c02d56a9>] fc_scsi_scan_rport+0x69/0x80 Oct 7 23:35:07 t-host kernel: [<c012b032>] run_workqueue+0x72/0x100 Oct 7 23:35:07 t-host kernel: [<c012e8d0>] prepare_to_wait+0x20/0x70 Oct 7 23:35:07 t-host kernel: [<c012b8c0>] worker_thread+0x0/0x100 Oct 7 23:35:07 t-host kernel: [<c012b964>] worker_thread+0xa4/0x100 Oct 7 23:35:07 t-host kernel: [<c012e720>] autoremove_wake_function+0x0/0x50 Oct 7 23:35:07 t-host kernel: [<c012b8c0>] worker_thread+0x0/0x100 Oct 7 23:35:07 t-host kernel: [<c012e462>] kthread+0x42/0x70 Oct 7 23:35:07 t-host kernel: [<c012e420>] kthread+0x0/0x70 Oct 7 23:35:07 t-host kernel: [<c0103573>] kernel_thread_helper+0x7/0x14 Oct 7 23:35:07 t-host kernel: ======================= Oct 7 23:35:07 t-host kernel: error 1 It looks like some type of sysfs/kobject race in SCSI ... and I think we might have seen it before, just not able to reproduce it reliably. My bet would be that the LIP which acts like a reset and occurs in the middle of the scan and so the initialising object is killed on the first scan but not yet dead and then can't be re-added on the second scan. Hannes has patches to help with this, but they're rather complex, and not really 2.6.24 material. I could see if there's a simpler fix. James ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 15:33 ` James Bottomley @ 2007-11-13 16:43 ` Randy Dunlap 2007-11-13 17:46 ` Martin Bligh 1 sibling, 0 replies; 268+ messages in thread From: Randy Dunlap @ 2007-11-13 16:43 UTC (permalink / raw) To: James Bottomley, mbligh Cc: Andrew Morton, Natalie Protasevich, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon, linux-scsi On Tue, 13 Nov 2007 09:33:21 -0600 James Bottomley wrote: > On Tue, 2007-11-13 at 03:15 -0800, Andrew Morton wrote: > > > > > SCSI================================================================== > > > > > > qla2xxx: driver initialization does not complete when booting with > > > Port connected > > > http://bugzilla.kernel.org/show_bug.cgi?id=9267 > > > Kernel: 2.6.23.1 > > > > No response from developers > > Urm, well, if no-one ever tells the SCSI list it's unrealistic to expect > anyone to be working on it. As far as I can tell, email was sent to > Andrew Vasquez only on 31 October. However, the fault looks to be > generic, so he probably just dropped it. It seems that new SCSI bugs need to be sent to linux-scsi@vger.kernel.org. Martin, can you arrange that to happen automatically instead of Andrew having to do it manually? --- ~Randy ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 15:33 ` James Bottomley 2007-11-13 16:43 ` Randy Dunlap @ 2007-11-13 17:46 ` Martin Bligh 2007-11-13 18:47 ` Andrew Morton 2007-11-14 5:07 ` David Miller 1 sibling, 2 replies; 268+ messages in thread From: Martin Bligh @ 2007-11-13 17:46 UTC (permalink / raw) To: James Bottomley Cc: Andrew Morton, Natalie Protasevich, davem, linux-kernel, linux-scsi > > > http://bugzilla.kernel.org/show_bug.cgi?id=9267 > > > Kernel: 2.6.23.1 > > > > No response from developers > > Urm, well, if no-one ever tells the SCSI list it's unrealistic to expect > anyone to be working on it. As far as I can tell, email was sent to > Andrew Vasquez only on 31 October. However, the fault looks to be > generic, so he probably just dropped it. This is a technical issue with vger.kernel.org mailing lists that I've tried addressing before - maybe davem can help fix it? What I've tried doing is bouncing relevant postings from my procmail filters to the list, but it seems to drop bounces (probably as spam). Is there any way around this? (like can I get an exception to be allowed to bounce stuff or mark it with some magic X-secret-knock: header?) ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 17:46 ` Martin Bligh @ 2007-11-13 18:47 ` Andrew Morton 2007-11-14 5:07 ` David Miller 1 sibling, 0 replies; 268+ messages in thread From: Andrew Morton @ 2007-11-13 18:47 UTC (permalink / raw) To: Martin Bligh Cc: James Bottomley, Natalie Protasevich, davem, linux-kernel, linux-scsi On Tue, 13 Nov 2007 09:46:08 -0800 "Martin Bligh" <mbligh@google.com> wrote: > > > > http://bugzilla.kernel.org/show_bug.cgi?id=9267 > > > > Kernel: 2.6.23.1 > > > > > > No response from developers > > > > Urm, well, if no-one ever tells the SCSI list it's unrealistic to expect > > anyone to be working on it. As far as I can tell, email was sent to > > Andrew Vasquez only on 31 October. However, the fault looks to be > > generic, so he probably just dropped it. I looked at that one and decided not to forward it to anyone because it was already sent to Andrew. Oh well, sorry. > This is a technical issue with vger.kernel.org mailing lists that I've tried > addressing before - maybe davem can help fix it? > > What I've tried doing is bouncing relevant postings from my procmail > filters to the list, but it seems to drop bounces (probably as spam). > Is there any way around this? (like can I get an exception to be allowed > to bounce stuff or mark it with some magic X-secret-knock: header?) Please let me know asap if/when this starts working so I don't start forwarding duplicates everywhere. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 17:46 ` Martin Bligh 2007-11-13 18:47 ` Andrew Morton @ 2007-11-14 5:07 ` David Miller 1 sibling, 0 replies; 268+ messages in thread From: David Miller @ 2007-11-14 5:07 UTC (permalink / raw) To: mbligh; +Cc: James.Bottomley, akpm, protasnb, linux-kernel, linux-scsi From: "Martin Bligh" <mbligh@google.com> Date: Tue, 13 Nov 2007 09:46:08 -0800 > This is a technical issue with vger.kernel.org mailing lists that I've tried > addressing before - maybe davem can help fix it? I think the problem is that certain mail headers show up multiple times and this makes it look like a looping email so we toss it. I suspect the one you really need to block out is X-MailingList or similar. Why don't you do a few tries and I'll try to remember to keep an eye out for the bounces? Thanks. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 11:15 ` Andrew Morton ` (6 preceding siblings ...) 2007-11-13 15:33 ` James Bottomley @ 2007-11-13 15:36 ` Alan Cox 2007-11-13 17:49 ` Jan Kara ` (3 subsequent siblings) 11 siblings, 0 replies; 268+ messages in thread From: Alan Cox @ 2007-11-13 15:36 UTC (permalink / raw) To: Andrew Morton Cc: Natalie Protasevich, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon > > pata_pdc202xx_old excessive ATA bus errors > > http://bugzilla.kernel.org/show_bug.cgi?id=9337 > > 2.6.24-rc2 > > No response from developers Untrue. We've been discussing it on list in the past and its now on bugzilla. Not obvious from outside I realise. That one I'm afraid is probably a longer term item. > > DVD-RAM umount and disk free bug > > http://bugzilla.kernel.org/show_bug.cgi?id=9265 > > Kernel: 2.6.15 (asked to try current kernel) > > No response from developers Not actually sure who is looking after this now ? > > LPC IT8705 POST port making noise on parallel port > > http://bugzilla.kernel.org/show_bug.cgi?id=9306 > > Kernel: 2.6.16+ > > > > No response from developers Not sure who really owns parallel. Have grabbed and will sort out. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 11:15 ` Andrew Morton ` (7 preceding siblings ...) 2007-11-13 15:36 ` Alan Cox @ 2007-11-13 17:49 ` Jan Kara 2007-11-13 18:04 ` Russell King ` (2 subsequent siblings) 11 siblings, 0 replies; 268+ messages in thread From: Jan Kara @ 2007-11-13 17:49 UTC (permalink / raw) To: Andrew Morton Cc: Natalie Protasevich, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon > > FILE SYSTEMS======================================================= > > > > ext4: delalloc space accounting problem drops data > > http://bugzilla.kernel.org/show_bug.cgi?id=9329 > > Kernel: 2.6.24-rc1 > No response from developers Actually, there has been a response (Eric asked in mailing list and created a bug and got answer to the mailing list): http://marc.info/?l=linux-ext4&m=119454449014728&w=2 > > POSIX Access Control Lists cause bogus file system check errors > > http://bugzilla.kernel.org/show_bug.cgi?id=9241 > > Kernel: 2.6.23.1 > > Andreas did some work, seemed to lose interest. As I read the bug it seems that the cause was a filesystem with errors (which were in ACL's and thus kernel didn't boot only with ACL's enabled) and fsck fixed the problem... I would close this one as invalid (OK, I know the filesystem had to be corrupted somehow but unless this is at least occasionally reproducible, there's low chance of finding the bug). Honza -- Jan Kara <jack@suse.cz> SuSE CR Labs ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 11:15 ` Andrew Morton ` (8 preceding siblings ...) 2007-11-13 17:49 ` Jan Kara @ 2007-11-13 18:04 ` Russell King 2007-11-14 12:46 ` Jiri Kosina 2007-11-14 13:24 ` Pavel Machek 11 siblings, 0 replies; 268+ messages in thread From: Russell King @ 2007-11-13 18:04 UTC (permalink / raw) To: Andrew Morton Cc: Natalie Protasevich, alsa-devel, netdev, linux-pcmcia, linux-kernel, linux-ide, bugme-daemon, linux-input On Tue, Nov 13, 2007 at 03:15:53AM -0800, Andrew Morton wrote: > On Mon, 12 Nov 2007 22:42:32 -0800 "Natalie Protasevich" <protasnb@gmail.com> wrote: > > PLATFORM=============================================================== > > > > xipImage is built so that uBoot cant run it (ARM) > > http://bugzilla.kernel.org/show_bug.cgi?id=9356 > > Kernel: 2.6.21 > > Zero responses from developers For christ sake Andrew. Some of us are not employed to do kernel work 24h x 365days a year. You might be, I'm not. First thing, it's not a regression. Second thing, it's *not* a bug. uboot requires kernel images to be specially wrapped up in their crappy formats before uboot will recognise it. This means that if someone wants to boot a binary image with uboot, they need to either: 1. work out the correct 'mkimage' command and run that program after the kernel build has completed. 2. sort out adding a new target to the kernel makefiles to run this uboot specific 'mkimage' command automatically. And Alexandre (the original feature-missing reporter) has linked to a message where a patch was proposed to do (2). So obviously it's no longer a problem for the reporter. > > with CONFIG_NO_HZ and/or CONFIG_HPET_TIMER set kernel 2.6.23 doesn't > > boot (ARM, Timer) > > http://bugzilla.kernel.org/show_bug.cgi?id=9229 > > Kernel: 2.6.23 > > No response from developers Bug was assigned to reporter, so I ignored it on the grounds that the reporter was resolving it. Plus, until recently I didn't have any workable PXA systems to test stuff on. In the end, a similar issue has been resolved anyway after a lot of discussion on the ARM lists about how PXA should handle one-shot mode with clockevents. It took absolutely ages to get agreement on what was a simple patch. commit 91bc51d8a10b00d8233dd5b6f07d7eb40828b87d Author: Russell King <rmk@dyn-67.arm.linux.org.uk> Date: Thu Nov 8 23:35:46 2007 +0000 [ARM] pxa: fix one-shot timer mode One-shot timer mode on PXA has various bugs which prevent kernels build with NO_HZ enabled booting. They end up spinning on a permanently asserted timer interrupt because we don't properly clear it down - clearing the OIER bit does not stop the pending interrupt status. Fix this in the set_mode handler as well. Moreover, the code which sets the next expiry point may race with the hardware, and we might not set the match register sufficiently in the future. If we encounter that situation, return -ETIME so the generic time code retries. Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Ergo, the bug can be closed provided the reporter re-tests a recent git snapshot. Sorry, no idea how the above commit relates to Linus' releases and/or git snapshots. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 11:15 ` Andrew Morton ` (9 preceding siblings ...) 2007-11-13 18:04 ` Russell King @ 2007-11-14 12:46 ` Jiri Kosina 2007-11-14 13:24 ` Pavel Machek 11 siblings, 0 replies; 268+ messages in thread From: Jiri Kosina @ 2007-11-14 12:46 UTC (permalink / raw) To: Andrew Morton Cc: Natalie Protasevich, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon On Tue, 13 Nov 2007, Andrew Morton wrote: > > HID==================================================================== > > > > Kernel NULL pointer dereference at :usbhid:hiddev_ioctl+0x2f/0xabc > > http://bugzilla.kernel.org/show_bug.cgi?id=9216 > > Kernel: 2.6.23.1 > > Looks like this is a regression > No response from developers Hi, it is assigned to 'other_modules@kernel-bugs.osdl.org', so I didn't notice, it's as simple as that. -- Jiri Kosina ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-13 11:15 ` Andrew Morton ` (10 preceding siblings ...) 2007-11-14 12:46 ` Jiri Kosina @ 2007-11-14 13:24 ` Pavel Machek 2007-11-14 14:14 ` Fabio Comolli 2007-11-14 19:52 ` Russell King 11 siblings, 2 replies; 268+ messages in thread From: Pavel Machek @ 2007-11-14 13:24 UTC (permalink / raw) To: Andrew Morton Cc: Natalie Protasevich, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon Hi! > > Suspend to RAM resume hangs on a tickless (NO_HZ) kernel > > http://bugzilla.kernel.org/show_bug.cgi?id=9275 > > Kernel: 2.6.23 > > This is HP notebook nc6320 T2400 945GM > > No response from developers Maybe I'm optimistic, but I expected Ingo/Thomas to look after nohz problems. nohz=off highres=off fixes more than one suspend problem... ...stuff I've seen with NOHZ even without suspend (cursor blinking irregulary) make me think that nohz perhaps should not be used in production just yet... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 13:24 ` Pavel Machek @ 2007-11-14 14:14 ` Fabio Comolli 2007-11-14 19:52 ` Russell King 1 sibling, 0 replies; 268+ messages in thread From: Fabio Comolli @ 2007-11-14 14:14 UTC (permalink / raw) To: Pavel Machek Cc: Andrew Morton, Natalie Protasevich, linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon FWIW, I see the same problem with another HP notebook, DV4378EA with radeon X700 video card. It does not happen frequently but I can say that since I disabled the tickless feature I can't reproduce the problem anymore. On Nov 14, 2007 2:24 PM, Pavel Machek <pavel@ucw.cz> wrote: > Hi! > > > > Suspend to RAM resume hangs on a tickless (NO_HZ) kernel > > > http://bugzilla.kernel.org/show_bug.cgi?id=9275 > > > Kernel: 2.6.23 > > > This is HP notebook nc6320 T2400 945GM > > > > No response from developers > > Maybe I'm optimistic, but I expected Ingo/Thomas to look after nohz > problems. nohz=off highres=off fixes more than one suspend problem... > > ...stuff I've seen with NOHZ even without suspend (cursor blinking > irregulary) make me think that nohz perhaps should not be used in > production just yet... > > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [BUG] New Kernel Bugs 2007-11-14 13:24 ` Pavel Machek 2007-11-14 14:14 ` Fabio Comolli @ 2007-11-14 19:52 ` Russell King 1 sibling, 0 replies; 268+ messages in thread From: Russell King @ 2007-11-14 19:52 UTC (permalink / raw) To: Pavel Machek Cc: Andrew Morton, alsa-devel, netdev, linux-pcmcia, linux-kernel, Natalie Protasevich, linux-ide, bugme-daemon, linux-input On Wed, Nov 14, 2007 at 01:24:48PM +0000, Pavel Machek wrote: > Hi! > > > > Suspend to RAM resume hangs on a tickless (NO_HZ) kernel > > > http://bugzilla.kernel.org/show_bug.cgi?id=9275 > > > Kernel: 2.6.23 > > > This is HP notebook nc6320 T2400 945GM > > > > No response from developers > > Maybe I'm optimistic, but I expected Ingo/Thomas to look after nohz > problems. nohz=off highres=off fixes more than one suspend problem... > > ...stuff I've seen with NOHZ even without suspend (cursor blinking > irregulary) make me think that nohz perhaps should not be used in > production just yet... It appears that bug 9229 has been solved, and the reporter of that bug now says that: If I unset NO_TZ suspend/resume works. If I set it suspend/resume doesn't works. So I think this guy is now suffering from bug #9275 -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ^ permalink raw reply [flat|nested] 268+ messages in thread
end of thread, other threads:[~2007-12-04 9:35 UTC | newest] Thread overview: 268+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-11-13 6:42 [BUG] New Kernel Bugs Natalie Protasevich 2007-11-13 11:15 ` Andrew Morton 2007-11-13 11:24 ` Jens Axboe 2007-11-13 11:33 ` Evgeniy Polyakov 2007-11-13 11:39 ` David Miller 2007-11-13 11:49 ` Andrew Morton 2007-11-13 11:58 ` David Miller 2007-11-13 12:12 ` Andrew Morton 2007-11-13 12:32 ` David Miller 2007-11-13 19:02 ` Andrew Morton 2007-11-13 20:00 ` Christian Kujau 2007-11-13 21:04 ` Andrew Morton 2007-11-13 16:56 ` Nick Piggin 2007-11-14 19:54 ` Linus Torvalds 2007-11-14 22:22 ` Heikki Orsila 2007-11-14 23:05 ` Linus Torvalds 2007-11-13 21:37 ` Adrian Bunk 2007-11-13 21:56 ` Christian Kujau 2007-11-15 4:07 ` Bron Gondwana 2007-11-15 4:24 ` Linus Torvalds 2007-11-15 5:25 ` Bron Gondwana 2007-11-15 5:35 ` Linus Torvalds 2007-11-15 5:53 ` Linus Torvalds 2007-11-15 11:50 ` mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) Bron Gondwana 2007-11-15 16:32 ` Linus Torvalds 2007-11-15 19:40 ` Peter Zijlstra 2007-11-15 20:44 ` Peter Zijlstra 2007-11-15 20:56 ` Linus Torvalds 2007-11-15 20:59 ` Peter Zijlstra 2007-11-15 21:12 ` Peter Zijlstra 2007-11-15 21:14 ` Linus Torvalds 2007-11-15 21:26 ` Linus Torvalds 2007-11-15 21:26 ` Peter Zijlstra 2007-11-15 21:47 ` Linus Torvalds 2007-11-15 22:11 ` Chris Friesen 2007-11-15 22:31 ` Linus Torvalds 2007-11-15 22:24 ` Rob Mueller 2007-11-18 23:13 ` Daniel Phillips 2007-11-19 3:41 ` Bron Gondwana 2007-11-16 0:48 ` Alan Cox 2007-11-21 21:25 ` Jan Engelhardt 2007-11-19 3:54 ` Bron Gondwana 2007-11-22 3:42 ` [PATCH 1/1] mm: add dirty_highmem option Bron Gondwana 2007-11-26 17:53 ` Linus Torvalds 2007-11-27 1:30 ` Bron Gondwana 2007-11-27 4:54 ` Andrew Morton 2007-11-27 5:24 ` Bron Gondwana 2007-11-27 5:53 ` Andrew Morton 2007-11-27 12:10 ` dirty highmem calculation sysctl name (Was: [PATCH 1/1] mm: add dirty_highmem option) Bron Gondwana 2007-11-27 13:06 ` [PATCH] mm/page-writeback - highmem_is_dirtyable option (replaces dirty_highmem patch) Bron Gondwana 2007-11-21 23:51 ` mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs) Bron Gondwana 2007-11-22 2:16 ` Bron Gondwana 2007-11-13 19:32 ` [BUG] New Kernel Bugs Russell King 2007-11-13 20:13 ` Adrian Bunk 2007-11-13 23:29 ` Russell King 2007-11-13 23:38 ` Andrew Morton 2007-11-13 20:52 ` Andrew Morton 2007-11-13 22:18 ` Russell King 2007-11-13 22:32 ` Andrew Morton 2007-11-13 23:09 ` Russell King 2007-11-13 23:17 ` Andrew Morton 2007-11-14 1:55 ` David Miller 2007-11-14 2:27 ` Andrew Morton 2007-11-14 3:47 ` David Miller 2007-11-14 8:30 ` Russell King 2007-11-14 9:55 ` Russell King 2007-11-14 10:07 ` David Miller 2007-11-14 11:46 ` [alsa-devel] " Rene Herman 2007-11-14 11:56 ` David Miller 2007-11-14 12:01 ` David Miller 2007-11-14 8:25 ` Moderated list (Was: Re: [BUG] New Kernel Bugs) Takashi Iwai 2007-11-14 12:21 ` Rene Herman 2007-11-14 9:47 ` Takashi Iwai 2007-11-14 23:23 ` Moderated list David Miller 2007-11-15 6:09 ` Rene Herman 2007-11-14 12:12 ` [alsa-devel] [BUG] New Kernel Bugs Rene Herman 2007-11-14 12:09 ` Rene Herman 2007-11-15 4:16 ` Bron Gondwana 2007-11-15 5:59 ` Rene Herman 2007-11-15 12:02 ` Bron Gondwana 2007-11-15 12:26 ` Rene Herman 2007-11-15 13:00 ` Jörn Engel 2007-11-15 14:29 ` Rene Herman 2007-11-15 13:17 ` Olivier Galibert 2007-11-15 9:34 ` Takashi Iwai 2007-11-14 19:44 ` Russell King 2007-11-16 22:16 ` Use *poof* for linux-omap (Was: [BUG] New Kernel Bugs) Tony Lindgren 2007-11-17 0:45 ` Use *poof* for linux-omap David Miller 2007-11-18 20:01 ` Tony Lindgren 2007-11-14 5:56 ` [BUG] New Kernel Bugs Sam Ravnborg 2007-11-14 5:59 ` Sam Ravnborg 2007-11-14 6:13 ` David Miller 2007-11-13 13:40 ` Ingo Molnar 2007-11-13 14:08 ` Mark Lord 2007-11-13 15:24 ` Giacomo A. Catenazzi 2007-11-13 15:57 ` Ray Lee 2007-11-13 17:01 ` Adrian Bunk 2007-11-13 17:50 ` Romano Giannetti 2007-11-13 22:03 ` Frans Pop 2007-11-13 15:52 ` Benoit Boissinot 2007-11-13 16:49 ` Ingo Molnar 2007-11-13 17:13 ` Theodore Tso 2007-11-13 17:30 ` Alan Cox 2007-11-13 17:33 ` Larry Finger 2007-11-13 18:55 ` Theodore Tso 2007-11-13 20:07 ` Larry Finger 2007-11-13 17:56 ` Adrian Bunk 2007-11-13 18:57 ` Gabriel C 2007-11-14 0:41 ` Denys Vlasenko 2007-11-14 0:39 ` Denys Vlasenko 2007-11-14 7:27 ` Adrian Bunk 2007-11-14 7:46 ` Denys Vlasenko 2007-11-14 13:30 ` Matthew Wilcox 2007-11-14 13:35 ` Hannes Reinecke 2007-11-14 21:39 ` Denys Vlasenko 2007-11-14 21:58 ` Gabriel C 2007-11-14 18:27 ` Kok, Auke 2007-11-14 16:55 ` Jan Evert van Grootheest 2007-11-14 23:23 ` Daniel Barkalow 2007-11-15 15:30 ` Theodore Tso 2007-11-15 16:19 ` Daniel Barkalow 2007-11-16 8:20 ` Romano Giannetti 2007-11-16 18:20 ` Daniel Barkalow 2007-11-16 19:46 ` Theodore Tso 2007-11-17 12:20 ` Adrian Bunk 2007-11-18 18:01 ` Theodore Tso 2007-11-13 16:46 ` Ingo Molnar 2007-11-13 17:50 ` Mark Lord 2007-11-13 18:12 ` Adrian Bunk 2007-11-13 18:18 ` Mark Lord 2007-11-13 18:36 ` Adrian Bunk 2007-11-13 18:47 ` Mark Lord 2007-11-13 19:04 ` Adrian Bunk 2007-11-13 19:12 ` Mark Lord 2007-11-13 19:30 ` Adrian Bunk 2007-11-13 19:46 ` Russell King 2007-11-13 20:04 ` Adrian Bunk 2007-11-13 19:26 ` Mark Lord 2007-11-13 20:00 ` Adrian Bunk 2007-11-13 20:13 ` Mark Lord 2007-11-13 21:20 ` Adrian Bunk 2007-11-13 21:12 ` Alan Cox 2007-11-14 0:52 ` Chuck Ebbert 2007-11-14 1:11 ` Stephen Hemminger 2007-11-14 2:10 ` Andrew Morton 2007-11-14 1:10 ` David Miller 2007-11-14 1:18 ` Peter Stuge 2007-11-13 18:17 ` Peter Zijlstra 2007-11-13 18:39 ` Matthew Wilcox 2007-11-13 18:43 ` Mark Lord 2007-11-13 18:49 ` Matthew Wilcox 2007-11-13 18:54 ` Mark Lord 2007-11-13 22:09 ` Rafael J. Wysocki 2007-11-14 14:30 ` Ingo Molnar 2007-11-14 14:49 ` Larry Finger 2007-11-18 12:44 ` size of git repository (was Re: [BUG] New Kernel Bugs) Pavel Machek 2007-11-18 12:58 ` Rene Herman 2007-11-18 14:35 ` James Bottomley 2007-11-18 15:19 ` Rene Herman 2007-11-18 14:56 ` Ingo Molnar 2007-11-19 4:43 ` Willy Tarreau 2007-11-13 19:37 ` [BUG] New Kernel Bugs Russell King 2007-11-13 20:18 ` Mark Lord 2007-11-13 21:33 ` Jörn Engel 2007-11-13 21:56 ` Andrew Morton 2007-11-13 22:24 ` Jörn Engel 2007-11-13 22:43 ` Andrew Morton 2007-11-13 22:29 ` Mark Lord 2007-11-13 23:40 ` Russell King 2007-11-14 1:56 ` David Miller 2007-11-14 0:34 ` Denys Vlasenko 2007-11-15 3:06 ` Neil Brown 2007-11-13 16:55 ` Randy Dunlap 2007-11-14 14:08 ` Ingo Molnar 2007-11-14 17:38 ` Randy Dunlap 2007-11-14 18:23 ` J. Bruce Fields 2007-11-15 2:50 ` Neil Brown 2007-11-16 0:05 ` J. Bruce Fields 2007-11-14 20:16 ` Ingo Molnar 2007-11-14 20:29 ` Randy Dunlap 2007-11-14 20:37 ` Ingo Molnar 2007-11-14 21:05 ` Randy Dunlap 2007-11-14 19:56 ` David Miller 2007-11-14 20:09 ` James Bottomley 2007-11-14 20:54 ` Ingo Molnar 2007-11-14 20:48 ` Ingo Molnar 2007-11-14 21:05 ` david 2007-11-13 11:47 ` Jarek Poplawski 2007-11-13 13:58 ` Mark Lord 2007-11-13 14:18 ` Mark Lord 2007-11-13 16:08 ` Thomas Gleixner 2007-11-13 16:07 ` Thomas Gleixner 2007-11-13 17:47 ` Mark Lord 2007-11-15 16:32 ` [BUG] Strange 1-second pauses during Resume-from-RAM Mark Lord 2007-11-15 16:49 ` Ray Lee 2007-11-15 16:51 ` Mark Lord 2007-11-15 16:53 ` Mark Lord 2007-11-15 18:14 ` Pavel Machek 2007-11-15 17:31 ` Mark Lord 2007-11-15 19:34 ` Ingo Molnar 2007-11-15 19:36 ` Ingo Molnar 2007-11-15 22:23 ` Mark Lord 2007-11-16 5:55 ` Ingo Molnar 2007-11-16 7:15 ` Ingo Molnar 2007-11-16 8:21 ` Ingo Molnar 2007-11-16 11:23 ` Ingo Molnar 2007-11-16 11:53 ` Mike Galbraith 2007-11-16 12:43 ` Ingo Molnar 2007-11-16 12:58 ` [patch] snd hda suspend latency: shorten codec read Ingo Molnar 2007-11-16 13:31 ` Rafael J. Wysocki 2007-11-16 14:21 ` Takashi Iwai 2007-11-16 19:06 ` [BUG] Strange 1-second pauses during Resume-from-RAM Mark Lord 2007-11-16 18:35 ` Mark Lord 2007-11-30 20:12 ` Mark Lord 2007-11-30 12:56 ` Jörn Engel 2007-11-30 13:35 ` Ingo Molnar 2007-11-30 13:43 ` Ingo Molnar 2007-11-30 18:35 ` Jörn Engel 2007-11-30 18:46 ` Ingo Molnar 2007-12-01 15:16 ` Jörn Engel 2007-12-01 18:32 ` Ingo Molnar 2007-12-01 20:47 ` Jörn Engel 2007-12-01 20:54 ` Ingo Molnar 2007-12-01 23:41 ` Jörn Engel 2007-12-02 8:56 ` Ingo Molnar 2007-12-02 11:31 ` Jörn Engel 2007-12-02 12:31 ` Jörn Engel 2007-12-02 13:57 ` Ingo Molnar 2007-12-02 14:46 ` Jörn Engel 2007-12-02 15:44 ` Ingo Molnar 2007-12-02 13:57 ` Ingo Molnar 2007-12-02 14:11 ` Jörn Engel 2007-12-02 15:47 ` Ingo Molnar 2007-12-02 19:55 ` Jörn Engel 2007-12-02 20:07 ` Ingo Molnar 2007-12-02 20:30 ` Jörn Engel 2007-12-02 20:45 ` Ingo Molnar 2007-12-02 21:08 ` Jörn Engel 2007-12-02 21:10 ` Jörn Engel 2007-12-02 21:19 ` Ingo Molnar 2007-12-03 0:57 ` Jörn Engel 2007-12-04 0:06 ` Jörn Engel 2007-12-04 9:34 ` Ingo Molnar 2007-11-30 15:49 ` Jörn Engel 2007-11-15 20:27 ` Rafael J. Wysocki 2007-11-18 16:10 ` Mark Lord 2007-11-18 16:21 ` Ingo Molnar 2007-11-18 17:37 ` Mark Lord 2007-11-13 17:54 ` [BUG] New Kernel Bugs Mark Lord 2007-11-13 22:46 ` Thomas Gleixner 2007-11-13 23:37 ` Mark Lord 2007-11-13 18:10 ` Russell King 2007-11-13 18:25 ` Alan Cox 2007-11-13 22:34 ` Russell King 2007-11-15 20:16 ` Ben Dooks 2007-11-13 15:21 ` Bartlomiej Zolnierkiewicz 2007-11-13 15:33 ` James Bottomley 2007-11-13 16:43 ` Randy Dunlap 2007-11-13 17:46 ` Martin Bligh 2007-11-13 18:47 ` Andrew Morton 2007-11-14 5:07 ` David Miller 2007-11-13 15:36 ` Alan Cox 2007-11-13 17:49 ` Jan Kara 2007-11-13 18:04 ` Russell King 2007-11-14 12:46 ` Jiri Kosina 2007-11-14 13:24 ` Pavel Machek 2007-11-14 14:14 ` Fabio Comolli 2007-11-14 19:52 ` Russell King
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).