Bug 138148
Summary: | open(2) shouldn't power up optical drives on laptops | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Steffen Persvold <sp> | ||||||||||||||
Component: | kernel | Assignee: | Dave Jones <davej> | ||||||||||||||
Status: | CLOSED CANTFIX | QA Contact: | |||||||||||||||
Severity: | medium | Docs Contact: | |||||||||||||||
Priority: | medium | ||||||||||||||||
Version: | 3 | CC: | davidz, feliciano.matias, hroberts, luke.hutch, m.a.young, mgb, mlists, pfrields, quintesse, sitsofe | ||||||||||||||
Target Milestone: | --- | ||||||||||||||||
Target Release: | --- | ||||||||||||||||
Hardware: | i686 | ||||||||||||||||
OS: | Linux | ||||||||||||||||
Whiteboard: | |||||||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||||
Clone Of: | Environment: | ||||||||||||||||
Last Closed: | 2005-10-03 00:23:13 UTC | Type: | --- | ||||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||||
Documentation: | --- | CRM: | |||||||||||||||
Verified Versions: | Category: | --- | |||||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||
Embargoed: | |||||||||||||||||
Attachments: |
|
Description
Steffen Persvold
2004-11-05 00:46:27 UTC
Created attachment 106197 [details]
/proc/ide/hda/identify
Created attachment 106198 [details]
/proc/ide/hdb/identify
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 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 *** Bug 139637 has been marked as a duplicate of this bug. *** 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 Created attachment 106913 [details]
hdparm -i and hdparm -I
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 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 ~]# What is the throughput before disabling Advanced PM? (with hald running) ~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. 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).
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. 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 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 ~]# **** 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 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 > 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 I would just like to confirm what was said in comments #15 and #17. I get the same results. Thanks. 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 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 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. 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 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 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. 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. Created attachment 107221 [details]
lshal
Created attachment 107504 [details]
lshal on a Dell Inspiron 8200
*** Bug 138769 has been marked as a duplicate of this bug. *** 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.) 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. The whole "physical eject button doesn't work while drive is polled" sounds a bit like bug 139243 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. Timothy -- what model laptop do you have? BIOS numbering is often different across models. 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 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? 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. 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. 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. 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 :-) See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213995 for a followup in FC6 where the same problem was re-discovered. |