Bug 138148 - open(2) shouldn't power up optical drives on laptops
Summary: open(2) shouldn't power up optical drives on laptops
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 3
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Jones
QA Contact:
URL:
Whiteboard:
: 138769 139637 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-11-05 00:46 UTC by Steffen Persvold
Modified: 2015-01-04 22:11 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-10-03 00:23:13 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
/proc/ide/hda/identify (1.25 KB, text/plain)
2004-11-05 00:48 UTC, Steffen Persvold
no flags Details
/proc/ide/hdb/identify (1.25 KB, text/plain)
2004-11-05 00:48 UTC, Steffen Persvold
no flags Details
hdparm -i and hdparm -I (2.50 KB, text/plain)
2004-11-17 21:19 UTC, Hal Roberts
no flags Details
Output of hdparm -i and hdparm -I (2.82 KB, text/plain)
2004-11-17 22:32 UTC, Ismael Juma
no flags Details
lshal (46.51 KB, text/plain)
2004-11-22 19:16 UTC, Hal Roberts
no flags Details
lshal on a Dell Inspiron 8200 (45.88 KB, text/plain)
2004-11-27 20:17 UTC, Bjoern Doering
no flags Details

Description Steffen Persvold 2004-11-05 00:46:27 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041020
Firefox/0.10.1

Description of problem:
When harddrive and cdrom are on the same IDE bus (/dev/hda and
/dev/hdb), the harddrive access is beeing blocked by the polling of
the cdrom device (checking for media) and the performance is crippled.



Version-Release number of selected component (if applicable):
hal-0.4.0-10

How reproducible:
Always

Steps to Reproduce:
1. Make sure "hald" is running
2. run hdparm -t /dev/hda

    

Actual Results:
 Timing buffered disk reads:   38 MB in  5.65 seconds =   6.72 MB/sec
 Timing buffered disk reads:   14 MB in  4.38 seconds =   3.20 MB/sec
 Timing buffered disk reads:    2 MB in  3.48 seconds = 588.26 kB/sec

Expected Results:
 Timing buffered disk reads:   84 MB in  3.03 seconds =  27.74 MB/sec
 Timing buffered disk reads:   84 MB in  3.03 seconds =  27.73 MB/sec
 Timing buffered disk reads:   84 MB in  3.03 seconds =  27.74 MB/sec

Additional info:

This is a Dell Inspiron 8200 laptop, 1.6 GHz P4 and Intel 82801CAM IDE
U100 controller (8086:248c) running kernel 2.6.9-1.649

Comment 1 Steffen Persvold 2004-11-05 00:48:00 UTC
Created attachment 106197 [details]
/proc/ide/hda/identify

Comment 2 Steffen Persvold 2004-11-05 00:48:32 UTC
Created attachment 106198 [details]
/proc/ide/hdb/identify

Comment 3 Gregory Gulik 2004-11-05 00:56:37 UTC
I too have similar problems with a Dell 8100 laptop with the 1Ghz
processor and 512M of RAM.  FC3T3 is extremely slow compared to FC2
which this system was running prior to this.

Disk performance with hald running:
/dev/hda:
 Timing buffered disk reads:   26 MB in  3.27 seconds =   7.94 MB/sec

Disk performance without hald:
/dev/hda:
 Timing buffered disk reads:   70 MB in  3.05 seconds =  22.93 MB/sec

Comment 4 Ismael Juma 2004-11-15 15:49:58 UTC
I too have similar problems with a Dell Inspiron 8200 laptop running 
a fully updated Fedora Core 3 and a Hitachi Travelstar 7k60 
as /dev/hda. I have additional information though. Even though the 
best performace is achieved when hald is not running, it is possible 
to recover a great deal of the performace lost when hald is running 
by loading a cd into the cd-rom drive. My hdparm figures follow: 
 
Disk performance without hald (average of three runs): 
/dev/hda: 
 Timing buffered disk reads: 37.38 MB/sec 
 
Disk performace with hald (average of three runs) 
  With the cd-rom drive open: 
  /dev/hda: 
   Timing buffered disk reads:   5.11 MB/sec 
 
  With cd-rom drive closed but with no cd in it: 
  /dev/hda: 
   Timing buffered disk reads:   14.7 MB/sec 
   
  With a cd in the cd-rom drive: 
  /dev/hda: 
   Timing buffered disk reads:   29.90 MB/sec 

Comment 5 David Zeuthen 2004-11-17 15:19:55 UTC
*** Bug 139637 has been marked as a duplicate of this bug. ***

Comment 6 David Zeuthen 2004-11-17 21:11:41 UTC
I cannot reproduce this on a desktop system (with /dev/hda being the
harddrive and /dev/hdb being the CD-ROM drive) and I don't have any
Dell Inspirons handy. 

Anyone suffering from this care to post the contents of 'hdparm -i'?

Thanks,
David

Comment 7 Hal Roberts 2004-11-17 21:19:20 UTC
Created attachment 106913 [details]
hdparm -i and hdparm -I

Comment 8 David Zeuthen 2004-11-17 21:29:41 UTC
Comment 7: Interesting; try doing 'hdparm -B 255 /dev/hda' to disable
power management on the disk; does that work? Is there still a
performance problem?

Thanks,
David


Comment 9 Hal Roberts 2004-11-17 21:44:25 UTC
nope.

[root@zodiac ~]# hdparm -B 255 /dev/hda

/dev/hda:
 setting Advanced Power Management level to disabled
[root@zodiac ~]# /etc/rc.d/init.d/haldaemon start
Starting HAL daemon:                                       [  OK  ]
[root@zodiac ~]# hdparm -t /dev/hda

/dev/hda:
 Timing buffered disk reads:   52 MB in  3.04 seconds =  17.10 MB/sec
[root@zodiac ~]# /etc/rc.d/init.d/haldaemon stop
Stopping HAL daemon:                                       [  OK  ]
[root@zodiac ~]# hdparm -t /dev/hda

/dev/hda:
 Timing buffered disk reads:  102 MB in  3.02 seconds =  33.76 MB/sec
[root@zodiac ~]# 

Comment 10 David Zeuthen 2004-11-17 21:46:56 UTC
What is the throughput before disabling Advanced PM? (with hald running)

Comment 11 Hal Roberts 2004-11-17 22:09:31 UTC
~33M

The same as when I turn hald off in the above comment.  The perceived
performance with hald running is also much worse than just half. 
Without hald, X takes maybe a minute to start up and be functional. 
With hald, it takes about 15 minutes.

Comment 12 Ismael Juma 2004-11-17 22:32:20 UTC
Created attachment 106922 [details]
Output of hdparm -i and hdparm -I

I'm also attaching a file containing the output of hdparm -i and hdparm -I for
my Inspiron 8200. My hard drive is different to the one from the previous
poster's (Hitachi Travelstar 7K60).

Comment 13 Ismael Juma 2004-11-17 22:39:39 UTC
I'd also like to add that the suggestion did not solve my problem 
either. In fact, I was already running with Advanced Power Management 
level disabled. 

Comment 14 David Zeuthen 2004-11-22 00:06:43 UTC
The thread linked to below is pretty interesting; please download this
piece of source code

http://www.ussg.iu.edu/hypermail/linux/kernel/0202.0/att-0603/01-cd_poll.c

and compile it with 'gcc -o cd_poll 01-cd_poll.c' and run cd_poll as
root; also make sure hald is not running. How does performance look
with these kind of polling? 

(I'm not expecting the numbers to look good; I just want to confirm
that another kind of polling also slows down performance. It looks
like we need to try out asynchronous notifications with your drives.)

Thanks,
David

Comment 15 Hal Roberts 2004-11-22 00:45:07 UTC
Running this program does *not* slow down my drive:

****
[root@zodiac ~]# hdparm -t /dev/hda

/dev/hda:
 Timing buffered disk reads:  102 MB in  3.02 seconds =  33.77 MB/sec
[root@zodiac ~]# ~hroberts/tmp/cd_poll &
[1] 28911
[root@zodiac ~]# no media change
hdparm -t /dev/hda

/dev/hda:
 Timing buffered disk reads:   98 MB in  3.01 seconds =  32.60 MB/sec
[root@zodiac ~]# killall cd_poll
[root@zodiac ~]# 
[1]+  Terminated              ~hroberts/tmp/cd_poll
[root@zodiac ~]# hdparm -t /dev/hda

/dev/hda:
 Timing buffered disk reads:   88 MB in  3.05 seconds =  28.89 MB/sec
[root@zodiac ~]# 
****

Comment 16 David Zeuthen 2004-11-22 01:35:34 UTC
That is interesting - does the program work as intended, e.g. do you
get output like this

 media removal
 media removal
 new media
 media removal

OK, so if you get the output it seems that hal should use this kind of
polling instead, or at least provide an option to use it on certain
problematic drives which we can blacklist/whitelist. This will appear
in an update sometime next week.

Thanks for the testing.

Cheers,
David

Comment 17 Hal Roberts 2004-11-22 01:45:59 UTC
The program seems to work as intended.  I get 'media removal' when I
open the cd drive and 'new media' when I close the cd drive with a cd
in it.

It seems to me that the problem is likely not the particular drive,
since everyone who has reported this bug has a dell, and dell
presumably uses the same drives that many other notebook makers do.

-hal

Comment 18 David Zeuthen 2004-11-22 01:51:02 UTC
> The program seems to work as intended.  I get 'media removal' when I
> open the cd drive and 'new media' when I close the cd drive with a cd
> in it.

Ok, that looks good.

> It seems to me that the problem is likely not the particular drive,
> since everyone who has reported this bug has a dell, and dell
> presumably uses the same drives that many other notebook makers do.

The problem is that Dell makes the harddrive and the optical share the
same IDE channel. That is bad enough for normal performance concerns
(like e.g. in a desktop system) but it is bad in particular for
laptops as they have powermanagement to spin down the drives.

The good thing, however, is that this can be fixed. I only need to
know if the technique we're going to use works on all drives out there
or whether I need to make blacklists/whitelists.

Cheers,
David

Comment 19 Ismael Juma 2004-11-22 05:09:57 UTC
I would just like to confirm what was said in comments #15 and #17. I 
get the same results. Thanks. 

Comment 20 Steffen Persvold 2004-11-22 14:13:35 UTC
Just wanted to confirm that the 01-cd_poll.c approach doens't slow
down the harddrive perfomance on my Inspiron 8200 (hald do). Works
fine too (detects CDs).

Cheers,
Steffen

Comment 21 David Zeuthen 2004-11-22 15:02:16 UTC
OK, please try a slightly modified version here

 http://people.redhat.com/davidz/cd_poll.c

Basically we need to open/close the device on every poll because we
open it O_NONBLOCK for exclusive access and so does cd recording
software. This has the neat property that we don't do polling when a
CD is being recorded. Thus, if we didn't open/close it on every poll
we would lock cd recording software out. 

Thanks,
David

Comment 22 David Zeuthen 2004-11-22 15:04:51 UTC
Btw, just because I'm curious, does the program print "eject request"
when you hit the eject button and the disc is mounted? To my
knowledge, not a lot of drives do so it would be good with a few more
data points.

Comment 23 Steffen Persvold 2004-11-22 15:16:54 UTC
David,

This appears to have re-introduced the performance issue. So the
problem seems to be the open/close and not the ioctl itself.

The program prints "media removal" when I hit the eject button (and
when  I run the "eject" command).

Cheers,
Steffen

Comment 24 Steffen Persvold 2004-11-22 15:23:06 UTC
I just realized I didn't answer your question correctly.

Yes, the program prints "eject request" when a CD is mounted and I
press the eject button.

Thanks,
Steffen

Comment 25 Ismael Juma 2004-11-22 15:25:27 UTC
The cd_poll posted in comment #22 does affect the performace of my 
hard drive. If there is no media in the cd-rom drive, my results were 
similar to the following: 
 
Timing buffered disk reads:   34 MB in  3.05 seconds =  11.15 MB/sec 
 
The good news is that all the messages worked as intended, including 
the "eject request", when the drive is mounted and the eject button 
is pressed. It is important to note that the drive did not actually 
eject though. 

Comment 26 David Zeuthen 2004-11-22 19:09:47 UTC
OK, this appears to look like a kernel bug - I guess open(2) shouldn't
power up the IDE optical drive on a laptop since it's not necessary to
do so for detecting media changes as the short test program shows. I
could be wrong though.

Until this is resolved I need to blacklist your drives in hal so we
don't do media detection on them since this slows down the system.
Everyone who is experiencing this problem please attach the output of
lshal (hald needs to be running in order to do this).

Reassigning to kernel for now.


Comment 27 Hal Roberts 2004-11-22 19:16:02 UTC
Created attachment 107221 [details]
lshal

Comment 28 Bjoern Doering 2004-11-27 20:17:39 UTC
Created attachment 107504 [details]
lshal on a Dell Inspiron 8200

Comment 29 David Zeuthen 2004-11-30 22:56:01 UTC
*** Bug 138769 has been marked as a duplicate of this bug. ***

Comment 30 Luke Hutchison 2004-12-01 05:17:10 UTC
There are two other potential problems with using open()/close() to poll:

(1)  Unless the drive does emit an "eject request" signal which is
caught and acted upon, then the drive button will seem to be
unresponsive (if you push the button while the drive is being polled,
it will do nothing).

(2) Also, the umount/eject commands give errors like the following
while cd_poll.c above has the drive device open:

$ eject /media/cdrecorder
eject: unable to eject, last error: Invalid argument

Of course the test code never actually closes the fd, so the disk
cannot be ejected until cd_poll exits, but if hal is doing this, at
least for the duration of the poll (which is apparently about 0.2s on
the problematic Dell in the above dup, and apparently happens at about
0.25sec intervals), these two problems could surface.  (At least, this
is the behavior I see on my desktop machine.)

BTW I have a Lite-On DVD burner, SOHW-1633S.  It does raise the "eject
request" event.  I think an increasing number of drives generate this
event, particularly with more recent drives, as it seems that drive
manufacturers have been trying harder lately to adhere to published
standards.  It would be great if HAL were to pass the eject event to
Nautilus via DBUS, so Nautilus could check for open fds on the CD/DVD
and then unmount and eject if possible.  Other programs like totem
could register for the event too.  (There was even talk somewhere of
adding functionality to Nautilus at some point if the "eject request"
event ever became available, or even if the user tried to manually
eject, which would pop up a list of programs that have files open on
the drive, and give you the option of switching to or killing the
program.)

Comment 31 Luke Hutchison 2004-12-01 05:24:58 UTC
BTW do those with Dells have the latest BIOS for their laptop?  I am
wondering if a BIOS update does anything, since it seems a
Dell-specific problem.  I couldn't risk a BIOS update on my boss'
laptop in case of introducing other problems (since everything else
"ain't broke" at the moment), so for now it's running with haldaemon
turned off.  His laptop (as reported in the above dup) is a Dell
Latitude C840 laptop.  BIOS revision is A02, but rev. A12 is available
for that model.


Comment 32 Sitsofe Wheeler 2004-12-01 09:14:15 UTC
The whole "physical eject button doesn't work while drive is polled" sounds a
bit like bug 139243

Comment 33 R. Timothy Edwards 2004-12-01 15:53:18 UTC
Reply to comment #31:  My Dell has the same problem with hald,
but I have a recent BIOS (A11, I think).  The A02 has a bug
wherein if the machine overheats, the fan is set to maximum
speed and gets stuck that way.  It can't be reset until you
install the new BIOS.

Comment 34 Luke Hutchison 2004-12-01 16:07:35 UTC
Timothy -- what model laptop do you have?  BIOS numbering is often
different across models.

Comment 35 Ismael Juma 2004-12-02 01:27:54 UTC
I would just like to mention that hal-0.4.2-1.FC3 has solved the 
performance  
problem for me. However, as I understand it, it does this by 
blacklisting the  
cd-rom drive which implies some loss of functionality. At any rate, I 
think  
this is good news for users of FC3 who have Inspirons but are not 
aware of this  
bug (and as a consequence its workaround). FC3 will be finally usable 
to them. 

Comment 36 David Zeuthen 2004-12-02 03:03:34 UTC
Comment 35: Yeah, I put in some information to disable polling for
such problematic drives, but we should still leave this bug open. This
means you miss minor functionality; e.g. automounting won't work and
you'll also miss getting a disc icon when there is a blank disc in the
drive. 

Presumably there should be a way to tell the kernel to stop locking
the door etc. for problematic drives like this (perhaps only do it
when the block device is claimed by a filesystem, e.g. when mounting it).

Kernel duders, what do you think about that suggestion?

Comment 37 teuben 2005-01-02 19:49:43 UTC
I'm glad i finally ran into this thread (thanks Mike!) i'd also like
to add to 
Comment #4 From Ismael Juma (mlists.uk) that bug# 73661
that I reported some years ago is essentially the same problem
(grmpffff, it was closed, had it been kept related i would have seen
it earlier and saved me a few days of work going back and forth
to MDK10.1 [it worked fine on my laptop].

The point is that the old magicdev problem and this HAL problem are
I believe related.

Comment 38 Dave Jones 2005-07-15 17:53:00 UTC
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.

Comment 39 Dave Jones 2005-10-03 00:23:13 UTC
This bug has been automatically closed as part of a mass update.
It had been in NEEDINFO state since July 2005.
If this bug still exists in current errata kernels, please reopen this bug.

There are a large number of inactive bugs in the database, and this is the only
way to purge them.

Thank you.

Comment 40 quintesse 2006-11-04 12:20:21 UTC
I can confirm this problem still exists (or exists again) on FC6. This is on a
Dell Latitude C840.

Hmm, ok, I see I can't reopen this bug so I guess I'll have to make a new one.

In the meantime if somebody knows how to put in the blacklist info myself I can
at least get the laptop to work properly :-)

Comment 41 teuben 2006-12-16 05:42:00 UTC
See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213995 for
a followup in FC6 where the same problem was re-discovered.


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