[Bug 338315] New: hdparm cannot tweak IDE DVD/CDRW as /dev/ sr0 is SCSI Generic sg
https://bugzilla.novell.com/show_bug.cgi?id=338315 Summary: hdparm cannot tweak IDE DVD/CDRW as /dev/sr0 is SCSI Generic sg Product: openSUSE 10.3 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Installation AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: rob.opensuse.linux@googlemail.com QAContact: jsrain@novell.com Found By: Customer After installing OS10.3 on an old SuSE-8.2 box, where the old ide-scsi DVD/CD-RW needed UDMA turned off for stability, I found I could no longer do a, hdparm -X now as the system does not know it's really an ATAPI device. I do know about udev, and tried all the device names available, but none of them would cooperate. I think I could do hdparm -i, but had trouble getting signed up here, so ask me if you need exact logs and more info. The IDE disk, is addressable through the SCSI layer (libata?), but the CDRW is using sg SCSI Generic layer which complains about invalid ioctl's for that device. These tweaks matter on machines with slightly dodgy hardware/firmware which was designed for Windows at time everyone expected Windows to crash regularly. On the plus side, to my amazement a 12x CD-R was burned & verified without error, so I'm suspecting past troubles was interaction between CD-RW and a HTP366 controller on the BP6 motherboard, rather than the DVD/CD-RW device itself. But it's an ATAPI and should be addressable as an IDE device, even if OS10 prefers to give it /dev/sr0 like a SCSI CDR. I thought ATAPI's didn't need any SCSI layer anymore in 2.6, so I'm a bit bemused by /dev/sr0, may be the udev rules need rethinking for ATAPI CDR's? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=338315 Cyril Hrubis <chrubis@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team-screening@forge.provo.novell.com |kernel-maintainers@forge.provo.novell.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=338315#c1 --- Comment #1 from Robert Davies <rob.opensuse.linux@googlemail.com> 2007-11-15 20:34:27 MST --- This problem also occurs in Sidux Debian kernel 2.6.23.1 kernel, interestingly "hdparm -i /dev/hdc" audibly spins up the DVD/CD-RW, then says "/dev/hdc: No such file or directory". Using hdparm -i on /dev/sr0 succeeds, but -X mdam2 fails with "HDIO_DRIVE_CMD(setxfermode) failed: Input/output error". Effects Ubuntu 2.6.22-14 kernel, and there some disks don't have IDE devices I could access them by, so it was actually worse. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=338315 Greg Kroah-Hartman <gregkh@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|kernel-maintainers@forge.provo.novell.com |teheo@novell.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=338315 User teheo@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=338315#c2 Tejun Heo <teheo@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |rob.opensuse.linux@googlemail.com --- Comment #2 from Tejun Heo <teheo@novell.com> 2008-02-05 21:41:28 MST --- W/ libata drivers, all ATA/ATAPI devices appear as SCSI devices. For ATAPI devices, this makes more sense because ATAPI is basically SCSI transport over ATA bus. For some obscure reasons, setting transfer mode is not supported yet but support is scheduled. At any rate, users shouldn't need to change transfer mode manually, the driver should be able to find appropriate mode and use it. Are you experiencing any problematic behavior other than the annoyance of renamed device node? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=338315 User cthiel@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=338315#c3 Christoph Thiel <cthiel@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |RESOLVED Info Provider|rob.opensuse.linux@googlemail.com | Resolution| |NORESPONSE --- Comment #3 from Christoph Thiel <cthiel@novell.com> 2008-04-25 06:49:01 MST --- Closing NOREPSONSE, due to missing information for more than 21 days. Please feel free to reopen and provide the requested information. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=338315 User rob.opensuse.linux@googlemail.com added comment https://bugzilla.novell.com/show_bug.cgi?id=338315#c4 --- Comment #4 from Robert Davies <rob.opensuse.linux@googlemail.com> 2008-12-09 09:45:22 MST --- Recently Tejun submitted a kernel patch to turn off UDMA and DMA in ATA adapters for CD-ROMs on HPT366 controllers. So he ought to have a clue why I as sysadmin wanted to do hdparm tweaks. Whilst it is true, that it's nice when drivers do things correctly, that doesn't allow the sysadmin to account for particular problems in a configuration. An original ATA/IDE developer was Andre Hedrik and he had a BP6 board, with the HPT366 controller. The board permitted Dual Celeron's overclocked to 100Mhz FSB, so were very desirable (and cheap) compared to the PII offerings at that time. So the DVD/CD-ROM having DMA turned off (even if it was on the host controller) was a stability fix for this board. Similarly for disks on the HPT366, stability appeared to be improved by using udma3 not udma4, and an hdparm -X tweak was used there. When disks are accessed via libata through the pata_ drivers, hdparm(8) appears to lie, and much of it not work. There are a number of libata/pata_* issues, and I note the article http://lwn.net/Articles/198344/ at lwn.net, the feedbacks discuss another reason or two for wanting hdparm access. This is really an upstream kernel hackers problem, with how to permit low level configuration commands like hdparm(8) into the I/O architecture. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=338315 User rob.opensuse.linux@googlemail.com added comment https://bugzilla.novell.com/show_bug.cgi?id=338315#c5 Robert Davies <rob.opensuse.linux@googlemail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|NORESPONSE | --- Comment #5 from Robert Davies <rob.opensuse.linux@googlemail.com> 2008-12-09 09:46:28 MST --- Recently Tejun submitted a kernel patch to turn off UDMA and DMA in ATA adapters for CD-ROMs on HPT366 controllers. So he ought to have a clue why I as sysadmin wanted to do hdparm tweaks. Whilst it is true, that it's nice when drivers do things correctly, that doesn't allow the sysadmin to account for particular problems in a configuration. An original ATA/IDE developer was Andre Hedrik and he had a BP6 board, with the HPT366 controller. The board permitted Dual Celeron's overclocked to 100Mhz FSB, so were very desirable (and cheap) compared to the PII offerings at that time. So the DVD/CD-ROM having DMA turned off (even if it was on the host controller) was a stability fix for this board. Similarly for disks on the HPT366, stability appeared to be improved by using udma3 not udma4, and an hdparm -X tweak was used there. When disks are accessed via libata through the pata_ drivers, hdparm(8) appears to lie, and much of it not work. There are a number of libata/pata_* issues, and I note the article http://lwn.net/Articles/198344/ at lwn.net, the feedbacks discuss another reason or two for wanting hdparm access. This is really an upstream kernel hackers problem, with how to permit low level configuration commands like hdparm(8) into the I/O architecture. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=338315 User teheo@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=338315#c6 Tejun Heo <teheo@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |UPSTREAM --- Comment #6 from Tejun Heo <teheo@novell.com> 2008-12-09 21:34:51 MST --- Hello, Robert. I'll probably commit those pata_hpt366 patches to HEAD and SL111_BRANCH. Are you sure about the ATAPI DMA problem is caused by overclocked bus? I added that patch because my MWDMA2 cdrom successfully locked up the whole machine unless DMA is turned off and my 366 is running on 33MHz PCI bus alright. As for the hdparm tweak, it's not gonna happen for SL111 or SLES11 but it's going to happen. We need cross-port synchronization to implement such tweak reliably and it kind of requires good amount of architecture changes which are scheduled but take time (yes, it has been arguably too long but hdparm tweaking was of low priority). I'm gonna close this as UPSTREAM for now but it's now near the top of my long term libata-TODO list, so it will happen sooner or later. For the time being, you can use "libata.force=P.D:udma/33" where P is the ATA port number and D is the ATA device number to force udma/33 (or any other transfer mode). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=338315 User rob.opensuse.linux@googlemail.com added comment https://bugzilla.novell.com/show_bug.cgi?id=338315#c7 --- Comment #7 from Robert Davies <rob.opensuse.linux@googlemail.com> 2008-12-10 06:46:11 MST --- Trying to be brief but the Dual Celeron Abit BP6 was the 'hot' box in early 2000, when the marketing men were pushing more expensive Slot based CPUs with off die caches. Intel did not support dual Celereon, the Intel BX chip was already old, but a classic and was pushed to it's limits in this board. It worked well with 1 CPU but, with the 2nd slot occupied, shall we say a lot of SMP code got shook down, and I think Linux 2.4 had included lots of fix ups, for slack Bios. Celeron 300A, 300 Mhz clock, 66Mhz FSB. PCI 33Mhz Celeron Overclock 450, 450 Mhz clock, 100Mhz FSB, PCI 33Mhz The PII 100Mhz FSB, had larger cache but off die, but a horrible slot system, and was much more expensive. The DVD/CD-RW drive was a late 2000 upgrade, and I think it's UDMA was flakey, at time Windows (98SE,ME,NT) was expected to crash frequently, so the mainstream weren't noticing unreliable hardware. I just found, with experience from BP6 Linux list (included ppl like Andre Hedrik and Rogier Wolff), that certain steps improved the box reliablility. HPT366 - hard disks on UDMA3 not the full 66 transfer speed. DVD/CD-ROM - turn off dma, when disks were on HPT366 There was a lot of stuff with incorrect documentation, so I think the driver guys like Andre, would despite signing NDA's and working with manufacturer's, end up with a certain amount of 'Witchcraft' based on trial and error. Looking at the LWN article,seeing the aims of PATA, and seeing that the Bugzilla system is working (I got a bit discouraged last year as I seemed to put in a lot of testing and reporting work for little effect), was reason I checked up on all reports. Whilst the hdparm settings was integrated with YaST2, via an /etc/rc script. I actually think those boot settings will do most of the job. hdparm helped a lot, when drivers were over cautious by default (not using UDMA modes for example), and a few things like setting idle spin down on disks that are only occasionally used. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=338315 User teheo@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=338315#c8 --- Comment #8 from Tejun Heo <teheo@novell.com> 2008-12-10 21:46:53 MST --- The reason why I pushed in ATAPI NODMA patch was that my hpt366 successfully froze the whole machine if my MWDMA2 CDROM was attached to the first channel (but it was okay if it was connected to the second channel), so it probably is something overly sensitive to the hardware configuration or something. I don't have much idea as for the specifics but at the moment I'll have to go with the safe bet. As for the hdparm, most stuff other than transfer mode setting works. Transfer mode configuration on-the-fly is a bit more complex and left unimplemented. Well, let's hope it happens soon. :-) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=338315 User rob.opensuse.linux@googlemail.com added comment https://bugzilla.novell.com/show_bug.cgi?id=338315#c9 --- Comment #9 from Robert Davies <rob.opensuse.linux@googlemail.com> 2008-12-11 01:53:22 MST --- I remember from the BP6 Linux list, which has probably been lost to the net, that it was considered a "No No" to connect CD-ROMs to the HPT366 controllers. I have original box and docs for the Abit BP6 still, and it may even have some statement telling you not to do it. Some BS about the HPT366 being "designed for disks". Not very satisfying but ... I think you're doing 'naive' users a favour if you do disable DMA for ATAPI devices on that controller. I'd have put in an objection, if I had reason to think having UDMA ATAP devices on the HPT366 was useful. On the host controller for instance a driver blacklist, disabling UDMA for ATAPI, when HPT366 was present would be very annoying, as I believe it's perfectly possible to get configurations (probably BP6 with single CPU) where it's stable. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com