Re: cdrecord-2.01.01a21 refuses work on Linux 2.4 if non-ide-scsi DVD-ROM is present
Hi,
> I did never see any problems from a missing HZ definition.
> It looks like a bug on this distribution....
We discussed it in July 2004. Yes it is a distro bug
which i workaround each time i compile your source
releases. SuSE 9.0 seems to suffer from a mix of 100
and 1000 Hz. Probably the missing of a HZ macro is
meant to express and emphasize this interesting state.
> 1) is USER_HZ available on that system?
> 2) what value is in USER_HZ?
/usr/include/asm/param.h:# define USER_HZ 100
> 3) Are there system where USER_HZ is available but the SCSI code
> uses HZ as base for timeouts?
> 4) Are there systems where HZ is != 100 but the SCSI code uses
> HZ as base for timeouts?
Don't know. I just settled to HZ 100 and it always worked
flawless. This applies to my individual system only, of course.
We once filed the problem as a temprorary flaw of the SuSE distro.
They did correct it meanwhile :))
> are you able to access the non-ide-scsi drive with older cdrecord versions?
No. In a positive sense.
The drive /dev/hgd did never interact with cdrecord.
But it is quite a while since i last tested wether
dev=ATA -scanbus yields results on my system.
$ cdrecord dev=ATA -scanbus
Cdrecord-ProDVD-Clone 2.01.01a12 ...
...
cdrecord: Read-only file system. Cannot open '/dev/hdg'. Cannot open SCSI driver.
Same with
cdrecord-2.01.01a4
cdrecord-prodvd-2.01.01b03-i686-pc-linux-gnu
cdrecord.2.01a33
Older versions in my collection obviously do not recognize dev=ATA.
I am not aware to have seen the "Cannot open" error message
when i explored dev=ATA about 1 or 2 years ago. I do remember
that dev=ATA -scanbus did not yield a bus list of drive items
as successful bus scans do.
Since then i added a Promise Ultra 133 TX2 IDE controller and
the drive moved from hdd to hdg. Unclear wether this made any
difference.
(It does, of course, make much difference when using drives
simultaneously. hdc+hdd did suck. hdc+hde+hdg works great.)
I do remember that a bus scan test with the same computer
under a Slackware kernel 2.6 based rescue system shows the
drive as /dev/hdc "ATA:1,0,0". (The controllers swap places
depending on what Linux i boot. There is a bootloader
option ide=reverse by wich i might try to influence that.)
> Are you able to sens SCSI commands to this drive without using
> cdrecord dev=ATAPI:...
On SuSE 9.0 i cannot get cdrecord-2.01.01a21 to anything but
eventually printing help texts. Any drive operation fails
with the complaint about /dev/hdg. (Wether i use the known
addresses 0,0,0 and 0,1,0 for the ide-scsi burners or "/dev/hdg"
or guessed ATA:3,0,0 .)
Older cdrecords work well with the burners but refuse on
dev=/dev/hdg or any dev=ATA:... with the known hdg complaint.
The other way known to me how to send SCSI commands is
via libburn resp. its ioctl(SG_IO), which needs a O_RDWR
filedescriptor, which i cannot get because of the errno 30
with open().
So: no SCSI commands sendable for now.
> returning EROFS is a POSIX violation, see:
I see. It would be legal if /dev was on a read-only
file system but not if /dev/hdg is unable to host a
read-write filesystem.
Please consider just to ignore drives which return that
error and not to abort the whole cdrecord run which addresses
other drives resp. tries to scan the bus.
> > [cdrecord built on SuSE 9.0 fails on SuSE 9.3]
> > After all, the binary built on the local system did work.
> It is even stranger that a locally build binary behaves different.
For a few years we were free of those binary compatibility
problems - at least within SuSE versions. Sigh.
> It would be possible to disable /dev/hd* scanning (by default)
> for pre-2.6 systems.
I supported the recent libburn fork because there was a
mandatory bus scan before any drive usage which caused various
trouble. The decisive patch which icculus.org/burn did not
accept was about restricting the bus scan to one single
predicted drive address.
This earned me developership with an own burn library.
Sigh ... chuckle.
So - if you want advise - disable that new auto-scan feature
unless an explicit drive address is missing. Also, avoid to
get hampered by problematic drives which are not given
explicitely by dev= . I had some weeks of work to achieve
the same with cdrskin. It seems to be very handy that way.
Have a nice day :)
Thomas
Reply to: