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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
