Mailing List Archive: Linux: Kernel

NCR53C8XX 3.0g fixes.

Index | Next | Previous | View Threaded

groudier at club-internet

Oct 4, 1998, 4:04 AM

Post #1 of 7 (62 views)
Permalink

NCR53C8XX 3.0g fixes.

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime [at] docserver for more info.
--8323328-480048176-907499075=:5291
Content-Type: TEXT/PLAIN; charset=US-ASCII
This attached patch against 2.1.123 is sort of smallest possible patch
that contains all known fixes (4) against ncr53c8xx driver version 3.0g.
In earlier time I would have sent it directly for inclusion into the
kernel, based on the fact that each fix has been reported ok.
This method of submitting fixes has recently been proven not to ensure
that the resulting larger patch is really good enough for the official
kernel.
So, if you have time for and your system has a 53C8XX SCSI controller in
it, you may want to give this patch a try and report me problems if any.
We are all responsible for ensuring changes are good enough for the
kernel, not only the maintainer of the code that is changed, IMO.

Thanks in advance.
Regards,
Gerard.
--8323328-480048176-907499075=:5291
Content-Type: APPLICATION/octet-stream; name="ncr53c8xx-3.0g-to-3.0i.patch.gz"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.3.95.981004130435.5291B [at] localhos>
Content-Description:
H4sICO9MFzYAA25jcjUzYzh4eC0zLjBnLXRvLTMuMGkucGF0Y2gAzVn5d9pI
Ev5Z/itqPc8JmMOIwwZnkg3BOGHGsRmw59idHT0hNdAbkBQdPmaS/32/6pYE
2DjJzubtG788QN1V1VVfna1UKhVaSC+5PXBDeS3C6CByInnQm9veTJz5s6rn
hK2G0769rV6MBq+Nn4RL3WRGZofq5nGjcWwe4XenvVMqlb5QkDFOPLpwYqIm
mfXjeg1itIyXL6lilptUMsv1Q3r5cqcytkP6LlmQ2SazcVyrKTp6LUI7dGnk
J64UIRVmof710lkkk4r0YhF6Iq5Ow+JOaf2w5p+SYOxTKK5lJH2PGtWaxEqF
en60FLF0yFEGRjT1Q4oCO3SoMEli8vxYLcVzQRqQIn7b2BDCjYgghMiyZPje
krFvF7Dr00RQEgFgZgxC1sKlwegHurYXicgIPBfgxrbn2pOFqCplxv5SgMHH
wjKiGxnP187Vx7rS9Z7G5DtOEuIQ6c2y7Xq1NdXq3IgQTPokm8a98YAisRBO
zJan4ikO5WwGQpcmd6ByFsIOF3dagOs7yVIotafCjhOIU4dLj6Y2fBAJ1o+h
wQk3fvjumAqtRq/988+AUQYZLDb4nIUtl/oQNmVpe4m9iFIM2HL+KW6Fk8Qi
VdUJZRBH9O8kilM5U7gRxDIObWXDzVwy4zzlcHwcJCMKRAjEl4zJptHFqpJz
OQeRH8RyKX/XgvA8Cf13wiP4geY2HgUeQrH0r4W75pSUilOBXASRg0hR5vne
VLn6Zs5CEBUzP5a5cPg3ZBTV8T4TnF2dp470hYYQ2ociCnwooPwVCnuRnlGl
roNtly3CnpKiLQuEE5UhCGfgn53S01SGyxvWa5LMqtre3Cj2U6aKjTTxlFN8
D05XavIhG+pPFcKsMMsIOHf8JAI5PKek5DEOcxA+cJdJUeIAm2iKXE99s4TP
UygvIe/pggmXoLFnAi7y4qd5jvhIOJz81hr1v+v3LnOqUDgiUErp+IY6QAln
h/5Sh8HpqxHJAx/LMxmpaFExw3uZ4rm0uZ2ioGBhDaq0ig8WnrsFsc6BYU+n
+AmcF4uVuDTtuERCs0gRKjF8qI/skh4ceRoK8Wp8ArMQ7pAuFouqwmEj1nMn
TeVt5qPIT5OOi9AN5+21dBEzLB7S55yOHO7aW7GvNnrQ2+VqgoIJ3v+p5NK9
gjnDSoWGoVgggTw7vFPa6or5Ss6o77nS9qjAiHJo9V0Ipl6VTvwoRgoSjFqj
Q4mdyxi4orwgU+Z+snBVkJI9s1Fp7pW/6k5le4tbNba5bm1suOoUDarXj9GZ
muYnW9uagI2WZh63Onlb5JbWbJWPqKQ+0dPoYH+H9veNcxv1gZ2fY+VP1/QG
zcFO5RtXTKWnvW6d90bWyWjwY39knXff9g1jN1eBKpuQ7+6U/iSr3N2hXMfe
XDjvkJtB4Kt6dMYo5KH7eWSdFFmgMxYB4omHhmb7uHX4hcg694eF+nHDXCF7
1GBk1ScjC8S07hXobh5yGN8p4nKms47HErYh058gkpsPCSTbruwf55YzipXB
IOtr0bHaJ/yN7zxnHvoe5/ZaHVT6tdrN8iGV+Etr+I1AEE9Zy2/kFA7CCKCG
BsuCw6SHZHIFfWtHywNMBtX5C9ClbkRvsQMrcKS1FMvCxI5EmSL5uygahcL1
0vKn00jEVlyExGtb7ReLK+7EW+e+tl03TNlXNNi9jv1gfhcVgqJhQG5QpCe8
bLnXS9ta2tG7ojKrXjPNcodK+K7jmw0z4DNn6RqqJRjGP4la/3qWL5NuFYEf
8Y65tmPoZqs4DrFe2Vyvq40jbJS2bXTWJS182+UTeKO5KcpzLdRAL94ibH1r
QxwKNjwjcs3ub9QzYZkr80Qbji5OB2d9a3w1HF6MLjVkjWaNQwHfZtlsacx0
vBoIWAyZ+waX97yHZfOWnpn03JPPZquxTHPyaII2nPJU9eJPNlqAXGKKQkQK
ZEI2j664IQyNNliIWFRTUQXMg7c4bG5fc3n11QB8gI8xLPvu6u1wRL/R4PS0
ezbuU+GnN/1zKvDW2/Fr6+Lqslgsg9aolbmVsGXEQs/FLWY+DHTc+5UOHq9E
Cz+upjgo+b2L4S9UaEKGxgx502bMOs2yWdOYGTrSUSsLURwmqAxuNEEsL6MZ
2ChXU2l5Obp6TElIGnZPTkZvqIB0zsNAqc+kZxfdE/jiNY5xMD5izC9T7bZd
y+1b19jEasUwRiwQDNNJqMmyhVSCPvZcL/I8kyr98WC/8tjftzQc9YfdUZ9e
bCfYPyj/oYNIYdY221wT6+1GLa05Ss+3Fz/2re6rMesKaNbAWNcJ+mCWKn6Z
cQ95tpiWh8BgyhOJnpKo+wp5kQ9W1WpV6d5oNFU9bzRare26N/+/umextIoW
xWKBx3IxmaVx2mh0OkrvJsriVr1bf029W7Wm0rtlHv4lYkXJORvpXO32vv+g
vi/PNUNNa91sdrjpYJ6C9mnzwfxJ8tnWtlpRl4R3he/7o3NrcH56QenosxdV
9txjnn2e1273avXbMnHX5IcFfkvf4tafP4bv+eftr94uDPp6MvciJZEMfROr
vOCLcNXDbFhG05ZxmTY2skkNxWq1o8qomgiA/cZieuA9Upxb5B64nXTtpcQD
riJ3O7GIxA59RQjcrwqBipHDziF32VLzqNYu13W71aFh5G16/AZV1RqMfshH
IEMtd2HPZX80uhpeWqdn3dfIg/U1+kB4HL8BI991cN0tTHw/xvw48dHcXpBZ
5Fnu/nRnGA8R24sYqPeJiNQtOprb/F4FmNBeRIw+bNRIFXXcGWri5D+AbTFE
BS8oftpnZSok1sL3ZkUCLfyeOvC/VMjdphA9ptB9LbYooQfhVJnPOGB9aTVE
K+xTdRmAB7aXKb9JWDA1VAo/ckaZVlei3TJrWaQ/Pu9IiNiALfPe1JYL3BMy
txlf7q9HXbT9KHfjKHpw1LbMzwE0cF3BPBnHtjO3RBj6Ic+5H3nWDSovWP7z
BwKe6Qw76qje0Wyjd7TTKgx3pHyMXVaLT/qvrl5zxulXfdtq9COhOA2F4Dhk
RbLiey/QsvO4nn1eiK62myLUSxP1t+aVTOxawfsS8e4nNcwCV+HXaZkKv85R
djdk1HF/BOQ1bmUVhWfhbzH4bzCbcuOmDx9ILQQilL6L69kT/cyMlhPwMz9K
771u9BzCX0EOPy8C5VSOGjXT8VCX3XcFsWSKQ9uLprhI09/19ffQrPEA3zps
NMpmfe2O/khobEu3FPYv8uUjLizdc+GfddwqcZhZlZyUqKzLGq0G8Vb7kIcq
3P07jSxBlCe0zbquPckeR/3x1dnlB/1wOTj/RVUfzubEwsUhpH0KEBgF/bTP
93JcRZGUwouENUmmQP2Zok9HIQxhqbVU2P3VY4MVLbl2bB+v2copqzACw3CE
omjxXFaA9HQxl7LOX9SH8Y2yIJ/XnpH81mzis1QqUs5Ae1xJ9wMsavJ8pwq4
9dpHBVbnCDMdwOq06/mt5aNCU8Uu9/3Ki+zVC2w/7WNOHPd13DooXsJaoH1Y
6o0GgIP191YBnnmoDHq40ev23vSts8E5ruyDf/SfZZ6SGD7ytv6c6sU1Iwqr
bsHIxqpfDnsD654wvmJz75zK2yRQTZPu66vOCxw5kX5k3YQyFhb/94CcWZO7
WBQmSZRVcWvq6fnGrB2Z6qUifuDOZJoaMscP7ix+u1t4wp9oafmbPenmFVTV
9rUpKo3bh8xEgwviaY34fREua5RObbsb7RxVBDQqzR5m70Op/B9aXrLkd29p
Cn8maT8tQmcufBUX15vBxos2j7Xitj+4eNsdDvsna80qFLPizn8AEjjV1AYd
AAA=
--8323328-480048176-907499075=:5291--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
Please read the FAQ at http://www.tux.org/lkml/

hes at xinit

Oct 4, 1998, 6:35 AM

Post #2 of 7 (58 views)
Permalink

Re: NCR53C8XX 3.0g fixes. [In reply to]

I am at work but If I get home at a decent time I will test this patch.
At home I have a file server with an ncr810 scsi controller. I had to patch the ncr driver to
be able to use it on this machine because my bios does not set the master bit. This is an x86
machine.
In the AM53C974 driver I fould the following comment:
/* PCI Spec 2.1 states that it is either the driver's or the PCI card's
responsibility
to set the PCI Master Enable Bit if needed.
(from Mark Stockton <marks [at] schooner>) */
So you can probably just remove the ifdef _powerpc_ around that piece of code since it does
not seem to be architecture dependent at all and remove the code from ifdef _sparc_. This is
not to much of a change for 2.2 is it?
I am attaching that patch (diff -c).
Earlier in the linux-kernel newsgroup we had a discussion around architecture dependant stuff
in drivers and came to some conclusion that such code should probably go into
drivers/pci/pci.c. This is of course a change for 2.3.
Is it feasibe to move the code architecture dependent code from the ncr driver and into
pci.c. Code for setting master bit is already present in drivers/pci/pci.c: pci_set_master.
The other stuff could be implemented as drivers/pci/pci.c: pci_set_io() pci_set_memory()
The wacky ibm stuff should probably be inside some ifdef_powerpc_ fix section.
The latency fix for sparc is probebly generic.
Well, I am no expert on the pci spec and I am sure hardware vendors break it all the time but
since we have the generic drivers/pci/pci.c code we should probably use it and try to fix all
architecture dependant stuff there. I know 2.0 does not have pci.c but I am still talking
about 2.3 development and we could probably drop 2.0 support in new versions of the drivers
when 2.2 is out.
The precense of pci.c probably calls for cleanup in lots of other drivers as well. We
probably have lots of duplicated code trying to deal with generic pci specific stuff in more
drivers.
Hans Eric
Here is the minor PCI_COMMAND_MASTER patch:
>diff -c ncr53c8xx.orig ncr53c8xx.c
*** ncr53c8xx.orig Sun Oct 4 14:31:04 1998
--- ncr53c8xx.c Sun Oct 4 15:22:07 1998
***************
*** 9732,9742 ****
return -1;
}
- #ifdef __powerpc__
- /*
- * Several fix-up for power/pc.
- * Should not be performed by the driver.
- */
if (!(command & PCI_COMMAND_MASTER)) {
printk("ncr53c8xx: attempting to force PCI_COMMAND_MASTER...");
command |= PCI_COMMAND_MASTER;
--- 9732,9737 ----
***************
*** 9749,9754 ****
--- 9744,9754 ----
}
}
+ #ifdef __powerpc__
+ /*
+ * Several fix-up for power/pc.
+ * Should not be performed by the driver.
+ */
if (!(command & PCI_COMMAND_IO)) {
printk("ncr53c8xx: attempting to force PCI_COMMAND_IO...");
command |= PCI_COMMAND_IO;
***************
*** 9802,9815 ****
base = __pa(base);
base_2 = __pa(base_2);
-
- if (!(command & PCI_COMMAND_MASTER)) {
- if (initverbose >= 2)
- printk("ncr53c8xx: setting PCI_COMMAND_MASTER bit (fixup)\n");
- command |= PCI_COMMAND_MASTER;
- pcibios_write_config_word(bus, device_fn, PCI_COMMAND, command);
- pcibios_read_config_word(bus, device_fn, PCI_COMMAND, &command);
- }
if ((chip->features & FE_WRIE) && !(command & PCI_COMMAND_INVALIDATE)) {
if (initverbose >= 2)
--- 9802,9807 ----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
Please read the FAQ at http://www.tux.org/lkml/

groudier at club-internet

Oct 4, 1998, 7:33 AM

Post #3 of 7 (58 views)
Permalink

Re: NCR53C8XX 3.0g fixes. [In reply to]

On Sun, 4 Oct 1998, Hans Eric Sandstr�m wrote:
> I am at work but If I get home at a decent time I will test this patch.
>
> At home I have a file server with an ncr810 scsi controller. I had to patch the ncr driver to
> be able to use it on this machine because my bios does not set the master bit. This is an x86
> machine.
>
> In the AM53C974 driver I fould the following comment:
> /* PCI Spec 2.1 states that it is either the driver's or
> the PCI card's responsibility
> to set the PCI Master Enable Bit if needed.
> (from Mark Stockton <marks [at] schooner>) */
At least half of this comment is wrong, since PCI cards are required to
reset with this bit set to ZERO.
Can somebody tell me at what page of the PCI specs I can read the
remaining half?
Thanks.
In fact most of the PCI control register bits power on with ZERO. On
systems where the POST software does not do its work, the kernel has to do
some fix-ups in order to complete the PCI set-up. The most part of PCI
device configuration can be done in a _generic_ manner, so it is just
bloat and often broken to tamper too much PCI device configuration from
PCI device driver.
Device drivers have a knowledge of hardware that is most of the time
limited to the device family they are intended to drive. Most of the time,
it is more relevant to consider a missing PCI feature bit as the way POST
software and BIOSes work around broken hardware.
Note that I have no objection for adding this work-around into the driver,
at least as a boot command option. But for this patch, it is too late.
> So you can probably just remove the ifdef _powerpc_ around that piece of
> code since it does not seem to be architecture dependent at all and
> remove the code from ifdef _sparc_. This is not to much of a change for
> 2.2 is it? I am attaching that patch (diff -c).
Thanks for the patch, but allow me to do different.
(BTW, if I am ever provided with a patch that removes all PCI
configuration tampering from the driver, I will apply it immediately.) ;-)
> Earlier in the linux-kernel newsgroup we had a discussion around
> architecture dependant stuff in drivers and came to some conclusion that
> such code should probably go into drivers/pci/pci.c. This is of course a
> change for 2.3.
I agree it is the right place for this kind of tweaking. Doing at driver
level stuff that can be done in a generic manner by a central module is
just bloating the kernel.
> Is it feasibe to move the code architecture dependent code from the ncr
> driver and into pci.c. Code for setting master bit is already present in
> drivers/pci/pci.c: pci_set_master.
>
> The other stuff could be implemented as drivers/pci/pci.c: pci_set_io()
> pci_set_memory()
>
> The wacky ibm stuff should probably be inside some ifdef_powerpc_ fix
> section.
>
> The latency fix for sparc is probebly generic.
I have accepted the #ifdef __arch__ for PCI since I thought that things
will be handled properly later (and they don't), but each time I disagreed
with these patches.
> Well, I am no expert on the pci spec and I am sure hardware vendors
> break it all the time but since we have the generic drivers/pci/pci.c
> code we should probably use it and try to fix all architecture dependant
> stuff there. I know 2.0 does not have pci.c but I am still talking about
> 2.3 development and we could probably drop 2.0 support in new versions
> of the drivers when 2.2 is out.
I have updated a system from 1.2.13 to 2.0.35 two months ago.
Dropping 2.0 support is beyond question at the moment, and will probably
stay so for years in my humble opinion.
> The precense of pci.c probably calls for cleanup in lots of other
> drivers as well. We probably have lots of duplicated code trying to deal
> with generic pci specific stuff in more drivers.
There is always room for improvements in anything. We cannot do all the
needed changes at a time. But I hope, as you, that the 2.3 kernel will get
rid of all PCI configuration tweaks that are not needed, especially from
low-level drivers.
Regards,
Gerard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
Please read the FAQ at http://www.tux.org/lkml/

shirsch at adelphia

Oct 4, 1998, 5:57 PM

Post #4 of 7 (59 views)
Permalink

Re: NCR53C8XX 3.0g fixes. [In reply to]

On Sun, 4 Oct 1998, Gerard Roudier wrote:
>
> This attached patch against 2.1.123 is sort of smallest possible patch
> that contains all known fixes (4) against ncr53c8xx driver version 3.0g.
Gerard, et al,
I applied this patch to 124pre-2 and built a kernel for my problem Alpha
UDB box. Much better! Rather than blowing up with incessant 'time out'
messages (with power-down the only recovery option), it intermittantly
spits out a slew of them and bounces back for more.
Interestingly, I had these occur even with the 2.0f driver retrofitted
into 124p2. There must have been a change somewhere to aggravate the
problem.
In sum, I have a working Alpha kernel with 3.0i, but it'd be nice to find
out why the time-outs are occuring.
This is the first 2.1.x kernel with 3.x ncr driver that can survive
through two consecutive kernel builds!
Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
Please read the FAQ at http://www.tux.org/lkml/

shirsch at adelphia

Oct 6, 1998, 4:39 AM

Post #5 of 7 (58 views)
Permalink

Re: NCR53C8XX 3.0g fixes. [In reply to]

On Sun, 4 Oct 1998, Steven N. Hirsch wrote:
> I applied this patch to 124pre-2 and built a kernel for my problem Alpha
> UDB box. Much better! Rather than blowing up with incessant 'time out'
> messages (with power-down the only recovery option), it intermittantly
> spits out a slew of them and bounces back for more.
Well, the honeymoon is over. After a brief respite, the 3.0i driver on my
UDB is back to the old behavior. I (again) re-installed the 2.5f
driver and it works fine. I am not seeing the same misbehavior reported
by others (message reject, etc.), it's a simple device timeout on the
Maxtor 540SL drive that seemingly never recovers.
Originally, I thought that the 2.5f driver was also broken with 2.1.124,
but it was my error in configuration - sorry for the misleading input.
Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
Please read the FAQ at http://www.tux.org/lkml/

babydr at baby-dragons

Oct 6, 1998, 11:16 AM

Post #6 of 7 (58 views)
Permalink

Re: NCR53C8XX 3.0g fixes. [In reply to]

Hello Steven, I had an exact same occurance that as long
as I went back to a particular previous version the drive
had -no- known troubles . But the minute I tried one of
Gerards newer releases It would hang in this manner .
The Drive gave out about 2 months into the discussions
with Gerard . Backup everything & test the -hell- out
of the disk & see if any errors crop up , bonnie is a
real good disk exerciser . Hth
On Tue, 6 Oct 1998, Steven N. Hirsch wrote:
> On Sun, 4 Oct 1998, Steven N. Hirsch wrote:
> > I applied this patch to 124pre-2 and built a kernel for my problem Alpha
> > UDB box. Much better! Rather than blowing up with incessant 'time out'
> > messages (with power-down the only recovery option), it intermittantly
> > spits out a slew of them and bounces back for more.
>
> Well, the honeymoon is over. After a brief respite, the 3.0i driver on my
> UDB is back to the old behavior. I (again) re-installed the 2.5f
> driver and it works fine. I am not seeing the same misbehavior reported
> by others (message reject, etc.), it's a simple device timeout on the
> Maxtor 540SL drive that seemingly never recovers.
>
> Originally, I thought that the 2.5f driver was also broken with 2.1.124,
> but it was my error in configuration - sorry for the misleading input.
>
> Steve
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo [at] vger
> Please read the FAQ at http://www.tux.org/lkml/
>
, JimL
+-----------------------------------------------------------------------+
| James W. Laferriere - Network Engineer - babydr [at] nwrain |
| System Techniques - 25416 - 22nd S. - Des-Moines, WA 98198 |
| Give me VMS -or- Give me Linux -but- only on AXP |
+-----------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
Please read the FAQ at http://www.tux.org/lkml/

groudier at club-internet

Oct 6, 1998, 2:15 PM

Post #7 of 7 (58 views)
Permalink

Re: NCR53C8XX 3.0g fixes. [In reply to]

On Tue, 6 Oct 1998, Steven N. Hirsch wrote:
> On Sun, 4 Oct 1998, Steven N. Hirsch wrote:
>
> > I applied this patch to 124pre-2 and built a kernel for my problem Alpha
> > UDB box. Much better! Rather than blowing up with incessant 'time out'
> > messages (with power-down the only recovery option), it intermittantly
> > spits out a slew of them and bounces back for more.
>
> Well, the honeymoon is over. After a brief respite, the 3.0i driver on my
> UDB is back to the old behavior. I (again) re-installed the 2.5f
Hmmm... Seems the fix weared out. :-)
How could it possible? :-)
Could you describe the behaviour.
> driver and it works fine. I am not seeing the same misbehavior reported
> by others (message reject, etc.), it's a simple device timeout on the
> Maxtor 540SL drive that seemingly never recovers.
Which SCSI features are enabled for the drive.
Could you report me your .config file and boot messages using driver 2.5f.
Could you provide me with more information on the problem like:
- Are other devices detected?
- At what step of the SCSI scan, the problem seem to occur.
- What is the command that times-out (config. with verbose SCSI message).
- What are the latest 'normal' kernel messages just before the breakage.
> Originally, I thought that the 2.5f driver was also broken with 2.1.124,
> but it was my error in configuration - sorry for the misleading input.
Regards,
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
Please read the FAQ at http://www.tux.org/lkml/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads