Bug 5854 - dell firmware loader makes load grow up to 1, and permanently stay there
Summary: dell firmware loader makes load grow up to 1, and permanently stay there
Status: RESOLVED CODE_FIX
Alias: None
Product: Other
Classification: Unclassified
Component: Other (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: other_other
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-09 01:32 UTC by Wilfried Goesgens
Modified: 2006-01-16 01:20 UTC (History)
0 users

See Also:
Kernel Version: 2.6.14 & 2.6.15
Subsystem:
Regression: ---
Bisected commit-id:


Attachments

Description Wilfried Goesgens 2006-01-09 01:32:55 UTC
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.
Comment 1 Andrew Morton 2006-01-09 01:58:25 UTC
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.

Comment 2 Anonymous Emailer 2006-01-09 12:32:07 UTC
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

Comment 3 Andrew Morton 2006-01-09 16:18:19 UTC
<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.


Comment 4 Anonymous Emailer 2006-01-13 09:52:32 UTC
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 


Note You need to log in before you can comment on or make changes to this bug.