I am a little late in installing 4.25D but better late then never.
We have a number of Compaq Proliant 1600 that have dual channel (875
chipset) embedded scsi. Using the pre-release version of the Fsys.sym8scsi
driver date Mar 19, 1999 we started the driver in the boot image with just
the “-L” option and it worked fine. It would find devices on both channels
and if they existed and would provide access to these devices (only 1 CPU
ever had a device on the 2 channel).
Now with the driver from the 4.25D patch this no longer works. What happens
is that the driver loads finds a device on channel 1 (good) and then
searches channel 2 for a device and never comes back if no devices are
present (bad). To get around the problem we now have to specify the PCI
index to ensure the unused channel is not used by the driver. This is not so
bad but it now makes my configurations less consistent because I have a
machine that will require different options for that driver. I am just
wondering why this changed?
A few problems I found when trying to use the PCI index are as follows:
- The use message generally indicates that -p is used to specify the PCI
index but the example header specifies -I.
- I found that the -p option was useless without the -c option.
Cheers,
Ping
“Brown, Richard” <brownr@aecl.ca> wrote in message
news:8pl4m2$bdo$1@inn.qnx.com…
I am a little late in installing 4.25D but better late then never.
We have a number of Compaq Proliant 1600 that have dual channel (875
chipset) embedded scsi. Using the pre-release version of the Fsys.sym8scsi
driver date Mar 19, 1999 we started the driver in the boot image with just
the “-L” option and it worked fine. It would find devices on both channels
and if they existed and would provide access to these devices (only 1 CPU
ever had a device on the 2 channel).
Now with the driver from the 4.25D patch this no longer works. What
happens
is that the driver loads finds a device on channel 1 (good) and then
searches channel 2 for a device and never comes back if no devices are
present (bad). To get around the problem we now have to specify the PCI
index to ensure the unused channel is not used by the driver. This is not
so
bad but it now makes my configurations less consistent because I have a
machine that will require different options for that driver. I am just
wondering why this changed?
A few problems I found when trying to use the PCI index are as follows:
- The use message generally indicates that -p is used to specify the PCI
index but the example header specifies -I.
- I found that the -p option was useless without the -c option.
Cheers,
Hello, is anybody from QSSL listening?
I searched QDN for sym8scsi problems/work arounds and got squat. I then
looked over old messages in this new group and found another thread titled
“Fsys.sym8scsi problems” which went unanswered. I am experiencing the same
symptoms as that thread described. The driver from 425D patch experiences
these problems. The pre-release version on the other hand does NOT.
Comments from QSSL, please …
“Brown, Richard” <brownr@aecl.ca> wrote in message
news:8po8a6$97a$1@inn.qnx.com…
Ping
“Brown, Richard” <> brownr@aecl.ca> > wrote in message
news:8pl4m2$bdo$> 1@inn.qnx.com> …
I am a little late in installing 4.25D but better late then never.
We have a number of Compaq Proliant 1600 that have dual channel (875
chipset) embedded scsi. Using the pre-release version of the
Fsys.sym8scsi
driver date Mar 19, 1999 we started the driver in the boot image with
just
the “-L” option and it worked fine. It would find devices on both
channels
and if they existed and would provide access to these devices (only 1
CPU
ever had a device on the 2 channel).
Now with the driver from the 4.25D patch this no longer works. What
happens
is that the driver loads finds a device on channel 1 (good) and then
searches channel 2 for a device and never comes back if no devices are
present (bad). To get around the problem we now have to specify the PCI
index to ensure the unused channel is not used by the driver. This is
not
so
bad but it now makes my configurations less consistent because I have a
machine that will require different options for that driver. I am just
wondering why this changed?
A few problems I found when trying to use the PCI index are as follows:
- The use message generally indicates that -p is used to specify the
PCI
index but the example header specifies -I.
- I found that the -p option was useless without the -c option.
Cheers,
For what it’s worth, I posted that message. I ended up calling QSSL and
was told the best tack was to send e-mail via the web site. That got a
fairly quick response - less than a day, and a tech support fellow and
I corresponded for about a week. Nothing came of it other than a final
admission a week later that a developer would need to look at it. That
was on 6 Sept. Silence since. Maybe when thay get the RTP out they’ll
get back to us folk.
“Brown, Richard” wrote:
Hello, is anybody from QSSL listening?
I searched QDN for sym8scsi problems/work arounds and got squat. I then
looked over old messages in this new group and found another thread titled
“Fsys.sym8scsi problems” which went unanswered. I am experiencing the same
symptoms as that thread described. The driver from 425D patch experiences
these problems. The pre-release version on the other hand does NOT.
Comments from QSSL, please …
“Brown, Richard” <> brownr@aecl.ca> > wrote in message
news:8po8a6$97a$> 1@inn.qnx.com> …
Ping
“Brown, Richard” <> brownr@aecl.ca> > wrote in message
news:8pl4m2$bdo$> 1@inn.qnx.com> …
I am a little late in installing 4.25D but better late then never.
We have a number of Compaq Proliant 1600 that have dual channel (875
chipset) embedded scsi. Using the pre-release version of the
Fsys.sym8scsi
driver date Mar 19, 1999 we started the driver in the boot image with
just
the “-L” option and it worked fine. It would find devices on both
channels
and if they existed and would provide access to these devices (only 1
CPU
ever had a device on the 2 channel).
Now with the driver from the 4.25D patch this no longer works. What
happens
is that the driver loads finds a device on channel 1 (good) and then
searches channel 2 for a device and never comes back if no devices are
present (bad). To get around the problem we now have to specify the PCI
index to ensure the unused channel is not used by the driver. This is
not
so
bad but it now makes my configurations less consistent because I have a
machine that will require different options for that driver. I am just
wondering why this changed?
A few problems I found when trying to use the PCI index are as follows:
- The use message generally indicates that -p is used to specify the
PCI
index but the example header specifies -I.
- I found that the -p option was useless without the -c option.
Cheers,