Most recent kernel where this bug did not occur: .15 Distribution: Debian Sid Hardware Environment: Dell Inspiron 8500 0000:00:00.0 Host bridge: Intel Corporation 82845 845 (Brookdale) Chipset Host Bridge (rev 04) 0000:00:01.0 PCI bridge: Intel Corporation 82845 845 (Brookdale) Chipset AGP Bridge (rev 04) 0000:00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03) 0000:00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 03) 0000:00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 03) 0000:00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 03) 0000:00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 83) 0000:00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 03) 0000:00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 03) 0000:00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03) 0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 Lf [FireGL 9000] (rev 01) 0000:02:00.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev 01) 0000:02:01.0 CardBus bridge: Texas Instruments PCI4510 PC card Cardbus Controller (rev 02) 0000:02:01.1 FireWire (IEEE 1394): Texas Instruments PCI4510 IEEE-1394 Controller 0000:02:03.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 02) model name : Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz Software Environment: Problem Description: Processor type and features -> Firmware Drivers -> BIOS update support for DELL systems via sysfs enabled into kernel. system boots up, load says it's around 1 even if the system is idle. Steps to reproduce: i've stripped down the whole distro to just run init and two login shells. removed acpi, usb, speedstep, the whole powermanagement, increased the vm frequency to 1khz, no changes. at the time the system let me log in, the load was at .42, and in top constantly grew to 1 in steps of .02, where it then stood, and just increased if i run other programms, but never fell under 1. Top shows that the box is 100% idle most ways, sometimes 1-4% i/o wait pops up, any process shown in top uses more than 3% resources. Though the load of the system keeps being 1 and larger. Removing the above item from the kernel solve the problem.
bugme-daemon@bugzilla.kernel.org wrote: > > http://bugzilla.kernel.org/show_bug.cgi?id=5854 > Me too. This is because the kernel thread which request_firmware() creates is stuck in D state: root 954 0.0 0.0 0 0 ? DW 01:55 0:00 [firmware/dell_r] Here: firmware/dell D 00000002 0 954 1 972 198 (L-TLB) c1a83f3c c1a83f2c 00000002 00000002 00000000 cfd8983f cf9429d8 c1a83efc c055a880 c19cf800 000000d0 cf9429d8 000081a4 00000000 c1a83f20 c019c87d c1af0cf4 c057b37c c1204420 00000000 00000000 7dd06300 003d08bd cff68030 Call Trace: [<c0498a2e>] wait_for_completion+0x8e/0xc8 [<c02e25fd>] _request_firmware+0x15b/0x18a [<c02e26d4>] request_firmware_work_func+0x4e/0xef [<c01010e9>] kernel_thread_helper+0x5/0xb Abhay, what are we trying to do there? The code seems to be infinitely retrying the request_firmware too. Could you please explain the logic behind this, and take a look at fixing it up? Thanks.
Reply-To: Abhay_Salunke@Dell.com > bugme-daemon@bugzilla.kernel.org wrote: > > > > http://bugzilla.kernel.org/show_bug.cgi?id=5854 > > > > Me too. > > This is because the kernel thread which request_firmware() creates is > stuck > in D state: > > root 954 0.0 0.0 0 0 ? DW 01:55 0:00 > [firmware/dell_r] > > Here: > > > firmware/dell D 00000002 0 954 1 972 198 (L-TLB) > c1a83f3c c1a83f2c 00000002 00000002 00000000 cfd8983f cf9429d8 c1a83efc > c055a880 c19cf800 000000d0 cf9429d8 000081a4 00000000 c1a83f20 > c019c87d > c1af0cf4 c057b37c c1204420 00000000 00000000 7dd06300 003d08bd > cff68030 > Call Trace: > [<c0498a2e>] wait_for_completion+0x8e/0xc8 > [<c02e25fd>] _request_firmware+0x15b/0x18a > [<c02e26d4>] request_firmware_work_func+0x4e/0xef > [<c01010e9>] kernel_thread_helper+0x5/0xb > > Abhay, what are we trying to do there? The thread is waiting for completion signal; the completion happens when the user will echo some data in to /sys/class/firmware/dell_rbu/loading. Wait_for_completion should put the thread in a sleep state not sure why the load average goes up to 1. > > The code seems to be infinitely retrying the request_firmware too. Could > you please explain the logic behind this, and take a look at fixing it up? > request_firmware is first called when the dell_rbu driver is loaded; this created the dell_rbu entries in /sys/class/firmware/. To make the entries persistent as long as the dell_rbu driver remains loaded, they get recreated in a callback function which gets called as soon as the user finishes loading the image by echoing 0 to /sys/class/firmware/dell_rbu/loading. I am working on another patch which does not require dell_rbu to create entries every time and lets the user create the entries. The dell_rbu driver creates entry in /sys/devices/platform/dell_rbu/image_type at load time. The user needs to first echo the required image_type "mono" or "packer" in to this entry and then the user must echo "init" in to the image_type entry. Echoing "init" currently recreates the dell_rbu entries in /sys/class/firmware. Thus in the new patch there is no need to create the dell_rbu entries at load time. The user must always echo "init" before going ahead with a monolithic image update. And in case of packet update method the user need to echo "init" in to /sys/devices/platform/dell_rbu/image_type before starting to download every packet. This method will avoid the need for the dell_rbu driver to recreate the firmware entries on its own; which will also prevent the load average from climbing as the kernel thread now is short lived and gets created only on demand. I will finish and test this patch and send and update. Thanks Abhay
<Abhay_Salunke@Dell.com> wrote: > > > bugme-daemon@bugzilla.kernel.org wrote: > > > > > > http://bugzilla.kernel.org/show_bug.cgi?id=5854 > > > > > > > Me too. > > > > This is because the kernel thread which request_firmware() creates is > > stuck > > in D state: > > > > root 954 0.0 0.0 0 0 ? DW 01:55 0:00 > > [firmware/dell_r] > > > > Here: > > > > > > firmware/dell D 00000002 0 954 1 972 198 > (L-TLB) > > c1a83f3c c1a83f2c 00000002 00000002 00000000 cfd8983f cf9429d8 > c1a83efc > > c055a880 c19cf800 000000d0 cf9429d8 000081a4 00000000 c1a83f20 > > c019c87d > > c1af0cf4 c057b37c c1204420 00000000 00000000 7dd06300 003d08bd > > cff68030 > > Call Trace: > > [<c0498a2e>] wait_for_completion+0x8e/0xc8 > > [<c02e25fd>] _request_firmware+0x15b/0x18a > > [<c02e26d4>] request_firmware_work_func+0x4e/0xef > > [<c01010e9>] kernel_thread_helper+0x5/0xb > > > > Abhay, what are we trying to do there? > > The thread is waiting for completion signal; the completion happens when > the user will echo some data in to /sys/class/firmware/dell_rbu/loading. > Wait_for_completion should put the thread in a sleep state not sure why > the load average goes up to 1. > Because wait_for_completion() will wait in state TASK_UNINTERRUPTIBLE (ie: "D" state). Such a task contributes to the load average. > > > > The code seems to be infinitely retrying the request_firmware too. > Could > > you please explain the logic behind this, and take a look at fixing it > up? > > > request_firmware is first called when the dell_rbu driver is loaded; > this created the dell_rbu entries in /sys/class/firmware/. To make the > entries persistent as long as the dell_rbu driver remains loaded, they > get recreated in a callback function which gets called as soon as the > user finishes loading the image by echoing 0 to > /sys/class/firmware/dell_rbu/loading. > > I am working on another patch which does not require dell_rbu to create > entries every time and lets the user create the entries. The dell_rbu > driver creates entry in /sys/devices/platform/dell_rbu/image_type at > load time. > The user needs to first echo the required image_type "mono" or "packer" > in to this entry and then the user must echo "init" in to the image_type > entry. > Echoing "init" currently recreates the dell_rbu entries in > /sys/class/firmware. Thus in the new patch there is no need to create > the dell_rbu entries at load time. The user must always echo "init" > before going ahead with a monolithic image update. And in case of packet > update method the user need to echo "init" in to > /sys/devices/platform/dell_rbu/image_type before starting to download > every packet. > > This method will avoid the need for the dell_rbu driver to recreate the > firmware entries on its own; which will also prevent the load average > from climbing as the kernel thread now is short lived and gets created > only on demand. > > I will finish and test this patch and send and update. > ok. Please carefully describe the new design in the changelog for that patch. The current design kind of snuck through without anyone noticing that it had these problems.
Reply-To: Abhay_Salunke@Dell.com > -----Original Message----- > From: Andrew Morton [mailto:akpm@osdl.org] > Sent: Monday, January 09, 2006 6:29 PM > To: Salunke, Abhay > Cc: bugme-daemon@bugzilla.kernel.org > Subject: Re: [Bugme-new] [Bug 5854] New: dell firmware loader makes load > grow up to 1, and permanently stay there > > <Abhay_Salunke@Dell.com> wrote: > > > > > bugme-daemon@bugzilla.kernel.org wrote: > > > > > > > > http://bugzilla.kernel.org/show_bug.cgi?id=5854 > > > > > > > > > > Me too. > > > > > > This is because the kernel thread which request_firmware() creates is > > > stuck > > > in D state: > > > > > > root 954 0.0 0.0 0 0 ? DW 01:55 0:00 > > > [firmware/dell_r] > > > > > > Here: > > > > > > > > > firmware/dell D 00000002 0 954 1 972 198 > > (L-TLB) > > > c1a83f3c c1a83f2c 00000002 00000002 00000000 cfd8983f cf9429d8 > > c1a83efc > > > c055a880 c19cf800 000000d0 cf9429d8 000081a4 00000000 c1a83f20 > > > c019c87d > > > c1af0cf4 c057b37c c1204420 00000000 00000000 7dd06300 003d08bd > > > cff68030 > > > Call Trace: > > > [<c0498a2e>] wait_for_completion+0x8e/0xc8 > > > [<c02e25fd>] _request_firmware+0x15b/0x18a > > > [<c02e26d4>] request_firmware_work_func+0x4e/0xef > > > [<c01010e9>] kernel_thread_helper+0x5/0xb > > > > > > Abhay, what are we trying to do there? > > > > The thread is waiting for completion signal; the completion happens when > > the user will echo some data in to /sys/class/firmware/dell_rbu/loading. > > Wait_for_completion should put the thread in a sleep state not sure why > > the load average goes up to 1. > > > > Because wait_for_completion() will wait in state TASK_UNINTERRUPTIBLE (ie: > "D" state). Such a task contributes to the load average. > > > > > > > The code seems to be infinitely retrying the request_firmware too. > > Could > > > you please explain the logic behind this, and take a look at fixing it > > up? > > > > > request_firmware is first called when the dell_rbu driver is loaded; > > this created the dell_rbu entries in /sys/class/firmware/. To make the > > entries persistent as long as the dell_rbu driver remains loaded, they > > get recreated in a callback function which gets called as soon as the > > user finishes loading the image by echoing 0 to > > /sys/class/firmware/dell_rbu/loading. > > > > I am working on another patch which does not require dell_rbu to create > > entries every time and lets the user create the entries. The dell_rbu > > driver creates entry in /sys/devices/platform/dell_rbu/image_type at > > load time. > > The user needs to first echo the required image_type "mono" or "packer" > > in to this entry and then the user must echo "init" in to the image_type > > entry. > > Echoing "init" currently recreates the dell_rbu entries in > > /sys/class/firmware. Thus in the new patch there is no need to create > > the dell_rbu entries at load time. The user must always echo "init" > > before going ahead with a monolithic image update. And in case of packet > > update method the user need to echo "init" in to > > /sys/devices/platform/dell_rbu/image_type before starting to download > > every packet. > > > > This method will avoid the need for the dell_rbu driver to recreate the > > firmware entries on its own; which will also prevent the load average > > from climbing as the kernel thread now is short lived and gets created > > only on demand. > > > > I will finish and test this patch and send and update. > > > > ok. Please carefully describe the new design in the changelog for that > patch. The current design kind of snuck through without anyone noticing > that it had these problems. Andrew, I have sent a patch which fixes this bug to the LKML and also copied to you. This patch was tested by me and works fine. Thanks Abhay