I'm trying to get Onstream {SC|DI} tape drives - osstX devices - to be detected and set up correctly in FC3 Test 3, just as stX devices are. In spite of staring at the startup scripts for some time, I'm not sure where to start.
To quote a segment of my /etc/sysconfig/hwconf:
- class: TAPE bus: SCSI detached: 0 device: st0 ^^^ this should be osst0 driver: ignore desc: "Onstream SC-30" host: 0 id: 3 channel: 0 lun: 0 generic: sg0 - class: TAPE bus: SCSI detached: 0 device: st1 ^^^ this should be st0 driver: ignore desc: "Onstream ADR Series" host: 3 id: 0 channel: 0 lun: 0 generic: sg6 - class: TAPE bus: SCSI detached: 0 device: st2 ^^^ this should be osst1 driver: ignore desc: "Onstream DI-30" host: 4 id: 0 channel: 0 lun: 0 generic: sg7 - class: TAPE bus: SCSI detached: 0 device: st3 ^^^ this should be st1 driver: ignore desc: "Conner CTT8000-A" host: 5 id: 0 channel: 0 lun: 0 generic: sg8 -
What creates /etc/sysconfig/hwconf? Does it drive everything else? If not, what is the point at which I should start unraveling this?
Thanks for your help, Willem Riede.
On 10/25/2004 03:30:04 PM, Bill Nottingham wrote:
Willem Riede (wrrhdev@riede.org) said:
What creates /etc/sysconfig/hwconf?
kudzu
Does it drive everything else?
If you're referring to udev creating device nodes, no.
That part I've got working in my next release of osst.c which I'll be submitting soon upstream to linux-kernel/linux-scsi.
What I'm trying to also make work is that osst.ko gets auto-loaded at boot, just as st.ko does today. If that doesn't happen, a FC3 system won't have osst device nodes, which would seriously inconvenience Onstream owners.
Having hwconf be correct in and of itself is a nice-to-have, if it doesn't drive anything else.
How does one tell whether a device uses osst vs st?
By vendor and type returned by the device. In terms of hwconf, if "desc:" starts with "Onstream SC", "Onstream DI", "Onstream USB", or "Onstream FW", then the device needs the osst device driver. Note that "Onstream ADR Series" is reported by a second generation drive, which should be driven by st.
Alternatively, if "st" reports the following line to syslog: Oct 23 08:55:18 fallguy kernel: st: The suggested driver is osst.
Thanks, Willem Riede.
On 10/25/2004 06:09:33 PM, Willem Riede wrote:
On 10/25/2004 03:30:04 PM, Bill Nottingham wrote:
Willem Riede (wrrhdev@riede.org) said:
What creates /etc/sysconfig/hwconf?
kudzu
Bill (or anyone that can help me),
Should I create a bugzilla entry against kudzu to do the detection below to get hwconf correct?
And where is the startup code that loads the st module? In spite of looking for it for hours, I have not been able to find it :-(
Thanks, Willem Riede.
Does it drive everything else?
If you're referring to udev creating device nodes, no.
That part I've got working in my next release of osst.c which I'll be submitting soon upstream to linux-kernel/linux-scsi.
What I'm trying to also make work is that osst.ko gets auto-loaded at boot, just as st.ko does today. If that doesn't happen, a FC3 system won't have osst device nodes, which would seriously inconvenience Onstream owners.
Having hwconf be correct in and of itself is a nice-to-have, if it doesn't drive anything else.
How does one tell whether a device uses osst vs st?
By vendor and type returned by the device. In terms of hwconf, if "desc:" starts with "Onstream SC", "Onstream DI", "Onstream USB", or "Onstream FW", then the device needs the osst device driver. Note that "Onstream ADR Series"
is reported by a second generation drive, which should be driven by st.
Alternatively, if "st" reports the following line to syslog: Oct 23 08:55:18 fallguy kernel: st: The suggested driver is osst.
Thanks, Willem Riede.
Willem Riede (wrrhdev@riede.org) said:
kudzu
Bill (or anyone that can help me),
Should I create a bugzilla entry against kudzu to do the detection below to get hwconf correct?
Hm, you could, but since that info isn't really used for anything, not sure how much it would help.
And where is the startup code that loads the st module? In spite of looking for it for hours, I have not been able to find it :-(
udev, almost certainly.
Bill
devel@lists.stg.fedoraproject.org
-
Bill Nottingham -
Willem Riede