Re: SCSI Tape corruption - update
On Fri, 20 Jul 2001, Geert Uytterhoeven wrote:
> On Sun, 8 Jul 2001, Geert Uytterhoeven wrote:
> > New findings:
> > - The problem doesn't happen with kernels <= 2.2.17. It does happen with all
> > kernels starting with 2.2.18-pre1.
> > - The only related stuff that changed in 2.2.18-pre1 seems to be the
> > Sym53c8xx driver itself. I'll do some more tests soon to isolate the
> > problem.
> > - The changes to the Sym53c8xx driver in 2.2.18-pre1 are _huge_. Are the
> > individual changes between sym53c8xx-1.3g and sym53c8xx-1.7.0 available
> > somewhere?
Not completely. The reason is that I used manual diffing/patching against
various kernel versions and it would be a PITA to resurrect all
intermediate driver versions using these patches. If we consider patches
that went directly to kernel main stream without changing the driver
version, a double PITA it would be. Btw, for sym-2.1.x series, I now use a
CVS tree and each driver release is tagged independently. For those ones,
it will be much more easy to isolate broken changes.
> The problem is indeed introduced by the changes to the Sym53c8xx in 2.2.18-pre1.
> I managed to find some intermediate versions in the 2.3.x series, and here are the
> results:
> - sym53c8xx-1.3g (from BK linuxppc_2_2): OK
> - sym53c8xx-1.5e: crash in SCSI interrupt during driver init
> - sym53c8xx-1.5f: lock up during driver init
> - sym53c8xx-1.5g: random 32-byte error bursts when writing to tape
That's an interesting result. But 1.5g - 1.3g diffs are probably very
large. Patches available from ftp.tux.org should allow to resurrect
driver versions 1.4, 1.5, 1.5a, 1.5b, 1.5c, 1.5d.
ftp://ftp.tux.org/pub/roudier/drivers/linux/sym53c8xx/README
You may, for example, apply incremental patches that address kernel 2.2.5
to a fresh kernel 2.2.5 tree and extract driver files accordingly.
> Perhaps I can get 1.5e and 1.5g to work using some PPC-specific fixes from the
> 1.3.g driver in the linuxppc_2_2 tree (it differed a bit from the 1.3g in
> Alan's 2.2.17). But even then the changes in 1.5f and 1.5g are rather small,
> compared to the changes between 1.3g and 1.5f.
Some PPC specific changes are very probably not present in my driver
sources. I am unable to help on that point.
> So I'd be very happy if I could get my hand on more intermediate versions.
> Thanks for your help! I _really_ want to nail this one down!
>
> Gr{oetje,eeting}s,
Regards,
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI Tape corruption - update
On Fri, 20 Jul 2001, Geert Uytterhoeven wrote:
On Sun, 8 Jul 2001, Geert Uytterhoeven wrote:
New findings:
- The problem doesn't happen with kernels = 2.2.17. It does happen with all
kernels starting with 2.2.18-pre1.
- The only related stuff that changed in 2.2.18-pre1 seems to be the
Sym53c8xx driver itself. I'll do some more tests soon to isolate the
problem.
- The changes to the Sym53c8xx driver in 2.2.18-pre1 are _huge_. Are the
individual changes between sym53c8xx-1.3g and sym53c8xx-1.7.0 available
somewhere?
Not completely. The reason is that I used manual diffing/patching against
various kernel versions and it would be a PITA to resurrect all
intermediate driver versions using these patches. If we consider patches
that went directly to kernel main stream without changing the driver
version, a double PITA it would be. Btw, for sym-2.1.x series, I now use a
CVS tree and each driver release is tagged independently. For those ones,
it will be much more easy to isolate broken changes.
The problem is indeed introduced by the changes to the Sym53c8xx in 2.2.18-pre1.
I managed to find some intermediate versions in the 2.3.x series, and here are the
results:
- sym53c8xx-1.3g (from BK linuxppc_2_2): OK
- sym53c8xx-1.5e: crash in SCSI interrupt during driver init
- sym53c8xx-1.5f: lock up during driver init
- sym53c8xx-1.5g: random 32-byte error bursts when writing to tape
That's an interesting result. But 1.5g - 1.3g diffs are probably very
large. Patches available from ftp.tux.org should allow to resurrect
driver versions 1.4, 1.5, 1.5a, 1.5b, 1.5c, 1.5d.
ftp://ftp.tux.org/pub/roudier/drivers/linux/sym53c8xx/README
You may, for example, apply incremental patches that address kernel 2.2.5
to a fresh kernel 2.2.5 tree and extract driver files accordingly.
Perhaps I can get 1.5e and 1.5g to work using some PPC-specific fixes from the
1.3.g driver in the linuxppc_2_2 tree (it differed a bit from the 1.3g in
Alan's 2.2.17). But even then the changes in 1.5f and 1.5g are rather small,
compared to the changes between 1.3g and 1.5f.
Some PPC specific changes are very probably not present in my driver
sources. I am unable to help on that point.
So I'd be very happy if I could get my hand on more intermediate versions.
Thanks for your help! I _really_ want to nail this one down!
Gr{oetje,eeting}s,
Regards,
Gérard.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI Tape corruption - update
On Sun, 8 Jul 2001, Geert Uytterhoeven wrote:
> On Thu, 21 Jun 2001, Geert Uytterhoeven wrote:
> > On Tue, 8 May 2001, Geert Uytterhoeven wrote:
> > > In the mean time I down/upgraded to 2.2.17 on my PPC box (CHRP LongTrail,
> > > Sym53c875, HP C5136A DDS1) and I can confirm that the problem does not happen
> > > under 2.2.17 neither.
> > >
> > > My experiences:
> > > - reading works fine, writing doesn't
> > > - 2.2.x works fine, 2.4.x doesn't (at least since 2.4.0-test1-ac10)
> > > - hardware compression doesn't matter
> > > - I have a sym53c875, Lorenzo has an Adaptec, so most likely it's not a
> > > SCSI hardware driver bug
> > > - I have a PPC, Lorenzo doesn't, so it's not CPU-specific
> > > - corruption is always a block of 32 bytes being replaced by 32 bytes from
> > > the previous tape block (depending on block size!) (approx. 6 errors per
> > > 256 MB)
> > >
> > > Lorenzo, can you please investigate the exact nature of the corruption on your
> > > system?
> > > - How many successive bytes are corrupted?
> > > - Where do the corrupted data come from?
> >
> > Yesterday I noticed the same corruption under 2.2.19 (yes, I run amverify after
> > backing up my system now, so it detects corruption through the gzip CRCs).
> >
> > I'll do some more tests (when I find time) to get a higher statistical
> > certainty that it really doesn't happen under earlier 2.2.x kernels.
>
> New findings:
> - The problem doesn't happen with kernels <= 2.2.17. It does happen with all
> kernels starting with 2.2.18-pre1.
> - The only related stuff that changed in 2.2.18-pre1 seems to be the
> Sym53c8xx driver itself. I'll do some more tests soon to isolate the
> problem.
> - The changes to the Sym53c8xx driver in 2.2.18-pre1 are _huge_. Are the
> individual changes between sym53c8xx-1.3g and sym53c8xx-1.7.0 available
> somewhere?
No. But you can move the sym/ncr driver bundle from 2.2.18-pre1 to 2.2.17
and vice-versa.
sym53c8xx.h, sym53c8xx_defs.h, sym53c8xx.c,
sym53c8xx_comm.h, ncr53c8xx.h, ncr53c8xx.c
You also can download either sym-1.7.3c-ncr-3.4.3b, or sym-2.1.11, or just
both and play with all that stuff under 2.2.17 and later 2.2 kernels.
ftp://ftp.tux.org/pub/roudier/README-drivers-linux
Btw, I am interested in results using sym-1.7.3c and sym-2.1.11 under
kernel 2.2.17 and possibly 2.2.18.
> BTW, I wrote a small test program which tries to analyze error bursts. You can
> find it at http://home.tvd.be/cr26864/Download/genpseudorandom.c
>
> Sample test using 2 bytes of data:
>
> genpseudorandom -o -l 2 > /dev/tape
> genpseudorandom -i < /dev/tape
Unfortunately, I haven't any tape device.
> So far I always saw problems when writing even only 10 MB to tape: ca. 3-5
> bursts of 32 or 12 incorrect bytes, which are always a copy of the
> corresponding bytes in the previous block. Of course I used a much larger test
> stream to verify 2.2.17.
>
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
Thanks for your testings,
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI Tape corruption - update
On Sun, 8 Jul 2001, Geert Uytterhoeven wrote:
On Thu, 21 Jun 2001, Geert Uytterhoeven wrote:
On Tue, 8 May 2001, Geert Uytterhoeven wrote:
In the mean time I down/upgraded to 2.2.17 on my PPC box (CHRP LongTrail,
Sym53c875, HP C5136A DDS1) and I can confirm that the problem does not happen
under 2.2.17 neither.
My experiences:
- reading works fine, writing doesn't
- 2.2.x works fine, 2.4.x doesn't (at least since 2.4.0-test1-ac10)
- hardware compression doesn't matter
- I have a sym53c875, Lorenzo has an Adaptec, so most likely it's not a
SCSI hardware driver bug
- I have a PPC, Lorenzo doesn't, so it's not CPU-specific
- corruption is always a block of 32 bytes being replaced by 32 bytes from
the previous tape block (depending on block size!) (approx. 6 errors per
256 MB)
Lorenzo, can you please investigate the exact nature of the corruption on your
system?
- How many successive bytes are corrupted?
- Where do the corrupted data come from?
Yesterday I noticed the same corruption under 2.2.19 (yes, I run amverify after
backing up my system now, so it detects corruption through the gzip CRCs).
I'll do some more tests (when I find time) to get a higher statistical
certainty that it really doesn't happen under earlier 2.2.x kernels.
New findings:
- The problem doesn't happen with kernels = 2.2.17. It does happen with all
kernels starting with 2.2.18-pre1.
- The only related stuff that changed in 2.2.18-pre1 seems to be the
Sym53c8xx driver itself. I'll do some more tests soon to isolate the
problem.
- The changes to the Sym53c8xx driver in 2.2.18-pre1 are _huge_. Are the
individual changes between sym53c8xx-1.3g and sym53c8xx-1.7.0 available
somewhere?
No. But you can move the sym/ncr driver bundle from 2.2.18-pre1 to 2.2.17
and vice-versa.
sym53c8xx.h, sym53c8xx_defs.h, sym53c8xx.c,
sym53c8xx_comm.h, ncr53c8xx.h, ncr53c8xx.c
You also can download either sym-1.7.3c-ncr-3.4.3b, or sym-2.1.11, or just
both and play with all that stuff under 2.2.17 and later 2.2 kernels.
ftp://ftp.tux.org/pub/roudier/README-drivers-linux
Btw, I am interested in results using sym-1.7.3c and sym-2.1.11 under
kernel 2.2.17 and possibly 2.2.18.
BTW, I wrote a small test program which tries to analyze error bursts. You can
find it at http://home.tvd.be/cr26864/Download/genpseudorandom.c
Sample test using 2 bytes of data:
genpseudorandom -o -l 2 /dev/tape
genpseudorandom -i /dev/tape
Unfortunately, I haven't any tape device.
So far I always saw problems when writing even only 10 MB to tape: ca. 3-5
bursts of 32 or 12 incorrect bytes, which are always a copy of the
corresponding bytes in the previous block. Of course I used a much larger test
stream to verify 2.2.17.
Thanks!
Gr{oetje,eeting}s,
Geert
Thanks for your testings,
Gérard.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: Changes for PCI
On Wed, 27 Jun 2001, Jeff Garzik wrote: > Tom Gall wrote: > > Well you have device drivers like the symbios scsi driver for instance that > > tries to determine if it's seen a card before. It does this by looking at the > > bus,dev etc numbers... It's quite reasonable for two different scsi cards to be > > on the same bus number, same dev number etc yet they are in different PCI > > domains. > > > > Is this a device driver bug or feature? > > I hesitate to call it a device driver bug, because that was likely the > best decision Gerard could make at the time. > > However, I think the driver (only going by your description) would be > more correct to use a pointer to struct pci_dev. We have a token in the > kernel that is guaranteed 100% unique to any given PCI device: the > pointer to its struct pci_dev. The driver checks against PCI bus+dev+func in 2 situations: 1) To apply the boot order that user can set up in the controller NVRAMs. 2) To detect buggy double reporting of the same device by the kernel PCI code (this made lot of troubles at some time). The great bug is to invent useless abstractions that don't match reality. Such brain masturbation leads to confusion (hence subtle bugs) and useless software bloatage (thus _real_ resource wastage). If we want to handle _real_ PCI bus domains, we just have to add a domain number to identify a _real_ PCI device. Anything that wants to hide such reality in some opaque data looks like brain masturbation to me. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: Changes for PCI
On Wed, 27 Jun 2001, Jeff Garzik wrote: Tom Gall wrote: Well you have device drivers like the symbios scsi driver for instance that tries to determine if it's seen a card before. It does this by looking at the bus,dev etc numbers... It's quite reasonable for two different scsi cards to be on the same bus number, same dev number etc yet they are in different PCI domains. Is this a device driver bug or feature? I hesitate to call it a device driver bug, because that was likely the best decision Gerard could make at the time. However, I think the driver (only going by your description) would be more correct to use a pointer to struct pci_dev. We have a token in the kernel that is guaranteed 100% unique to any given PCI device: the pointer to its struct pci_dev. The driver checks against PCI bus+dev+func in 2 situations: 1) To apply the boot order that user can set up in the controller NVRAMs. 2) To detect buggy double reporting of the same device by the kernel PCI code (this made lot of troubles at some time). The great bug is to invent useless abstractions that don't match reality. Such brain masturbation leads to confusion (hence subtle bugs) and useless software bloatage (thus _real_ resource wastage). If we want to handle _real_ PCI bus domains, we just have to add a domain number to identify a _real_ PCI device. Anything that wants to hide such reality in some opaque data looks like brain masturbation to me. Gérard. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Client receives TCP packets but does not ACK
On Fri, 15 Jun 2001, Mike Black wrote: > This is a very common misconception -- I worked a contract many years ago > where I actually had to quote the author of TCP to convince a banking > company I was working with that TCP is not a guaranteed protocol. > Guaranteed delivery at layer 5 - yes -- but NOT a guaranteed protcol. > > Guaranteed means that there is absolutely NO way that data can be dropped by > an application if either sender or receiver screws up. > > The only way to do this is at layer 7 of the OSI model -- even then you end > up making assumptions. You are mixing oranges (protocols) and apples (implementations and APIs) here. The layer that is expected to provide reliable end to end communication is layer 4 (transport layer). TCP, at least in theory, is as good as OSI transport in providing reliable end to end communication. > Here's some examples for layer 5 (which TCP operates at) but talking at > Layer 7: > > #1 - You send() data -- meanwhile the receiver terminates the connection -- > what happened to the data? It's gone! Your app never receives feedback > that it didn't send() correctly. You'll see the reset on the next read but > you don't know what happened to the data. > #2 - You send() data and overrun your IP queue -- nobody will ever know the > difference without a layer 7 protocol (or int the case quoted in this > subject it might lock up). > #3 - You send() data and either machine has bad RAM and flips a bit -- guess > what? -- data corruption. > > Even when you do layer 7 (with checksums and ack/nak) you make assumptions: > > #1 - You checksum the packet you just received -- what's to say a bit can't > flip? > > TCP may be guaranteed at layer 5 but we don't typically program at layer > 5 -- we program at layer 7 and then lots of people assume they're doing it > at layer 5 -- ergo the problems. Layers above layer 4 provide additionnal services for applications but they assume that layer 4 is reliable. In other words, a broken transport layer breaks all layers above it and thus the applications. In fact, when you build your application above layer 4 and need services normally provided by upper OSI layers, you have to implement equivalent services in your application, using layered protocols or not. > To look at it another way -- "Just 'cuz I told my C library to send a packet > doesn't mean it's going to work". > For example, if you're using non-blocking sockets you have to check to > ensure there's room in your IP queue to transmit. That's API semantic issue, not protocol issue. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Client receives TCP packets but does not ACK
On Fri, 15 Jun 2001, Mike Black wrote: This is a very common misconception -- I worked a contract many years ago where I actually had to quote the author of TCP to convince a banking company I was working with that TCP is not a guaranteed protocol. Guaranteed delivery at layer 5 - yes -- but NOT a guaranteed protcol. Guaranteed means that there is absolutely NO way that data can be dropped by an application if either sender or receiver screws up. The only way to do this is at layer 7 of the OSI model -- even then you end up making assumptions. You are mixing oranges (protocols) and apples (implementations and APIs) here. The layer that is expected to provide reliable end to end communication is layer 4 (transport layer). TCP, at least in theory, is as good as OSI transport in providing reliable end to end communication. Here's some examples for layer 5 (which TCP operates at) but talking at Layer 7: #1 - You send() data -- meanwhile the receiver terminates the connection -- what happened to the data? It's gone! Your app never receives feedback that it didn't send() correctly. You'll see the reset on the next read but you don't know what happened to the data. #2 - You send() data and overrun your IP queue -- nobody will ever know the difference without a layer 7 protocol (or int the case quoted in this subject it might lock up). #3 - You send() data and either machine has bad RAM and flips a bit -- guess what? -- data corruption. Even when you do layer 7 (with checksums and ack/nak) you make assumptions: #1 - You checksum the packet you just received -- what's to say a bit can't flip? TCP may be guaranteed at layer 5 but we don't typically program at layer 5 -- we program at layer 7 and then lots of people assume they're doing it at layer 5 -- ergo the problems. Layers above layer 4 provide additionnal services for applications but they assume that layer 4 is reliable. In other words, a broken transport layer breaks all layers above it and thus the applications. In fact, when you build your application above layer 4 and need services normally provided by upper OSI layers, you have to implement equivalent services in your application, using layered protocols or not. To look at it another way -- Just 'cuz I told my C library to send a packet doesn't mean it's going to work. For example, if you're using non-blocking sockets you have to check to ensure there's room in your IP queue to transmit. That's API semantic issue, not protocol issue. Gérard. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
On Sun, 3 Jun 2001, Adrian Cox wrote: > Marc Lehmann wrote: > > > > Aren't PCI delayed transaction supposed to be handled by the pci master > > (e.g. my northbridge), not by the (software) driver for my pdc(?) I would > > also be surprised if my pdc actually used that feature, not to speak of > > the fact that the promise + harddisk worked fine in another computer (the > > data corruption was easily detectable, one couldn't even write 500megs > > without altered bytes). > > > Wrong way round. You're right that the pci master is supposed to handle > delayed transactions, but during data transfer the pdc is the pci master > and the northbridge is the PCI target. Wrong in my opinion, at least as it is worded. :) PCI delayed transactions are not a PCI master issue at all, for the reason it is not possible for a PCI master to distiguish between a transaction which is delayed by the target and a simple retry requested by the target. Btw, a PCI master that is unable to properly retry a transaction (could the transaction be handled by the target as a delayed transaction on not) would not allow a system to work for a long time. I would expect system breakage within seconds in such situation. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
On Sun, 3 Jun 2001, Adrian Cox wrote: Marc Lehmann wrote: Aren't PCI delayed transaction supposed to be handled by the pci master (e.g. my northbridge), not by the (software) driver for my pdc(?) I would also be surprised if my pdc actually used that feature, not to speak of the fact that the promise + harddisk worked fine in another computer (the data corruption was easily detectable, one couldn't even write 500megs without altered bytes). Wrong way round. You're right that the pci master is supposed to handle delayed transactions, but during data transfer the pdc is the pci master and the northbridge is the PCI target. Wrong in my opinion, at least as it is worded. :) PCI delayed transactions are not a PCI master issue at all, for the reason it is not possible for a PCI master to distiguish between a transaction which is delayed by the target and a simple retry requested by the target. Btw, a PCI master that is unable to properly retry a transaction (could the transaction be handled by the target as a delayed transaction on not) would not allow a system to work for a long time. I would expect system breakage within seconds in such situation. Gérard. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sym53c8xx timer and smp fixes
On Thu, 31 May 2001, Tim Hockin wrote: > All, > > Attached is a patch for sym53c8xx.c to handle the error timer better, and > be more proper for SMP. The changes are very simple, and have been beaten > on by us. Please let me know if there are any problems accepting this > patch for general inclusion. I have no problems accepting your patch. Thanks for it. I just want to have to deal with a human manageable finite number of actual driver versions :). I also want the same driver source to also be useable on recent 2.2 kernels. About timers in modules and more generally either timers in drivers or modules unloading, you must keep in mind that this stuff has been racy for years in Linux. Allow time for me to check if it is really fixed in latest kernel and so to make sure it is worthwhile to apply your patch. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI-CD-Writer don't show up
On Sat, 2 Jun 2001, Matthias Schniedermeyer wrote: > #Include > > > > I have 3 SCSI-CD-Writers. "Strange" is that the boot-process only finds > the first one (1 0 5 0), the other two i have to add with > > echo "scsi add-single-device 2 0 4 0" > /proc/scsi/scsi > echo "scsi add-single-device 2 0 6 0" > /proc/scsi/scsi > > to make them useable. > > Here is the complete ist of my SCSI-Devices: > > Host: scsi0 Channel: 00 Id: 06 Lun: 00 > Vendor: IBM Model: DDYS-T18350N Rev: S93E > Type: Direct-AccessANSI SCSI revision: 03 > Host: scsi1 Channel: 00 Id: 00 Lun: 00 > Vendor: PLEXTOR Model: CD-ROM PX-32TS Rev: 1.03 > Type: CD-ROM ANSI SCSI revision: 02 > Host: scsi1 Channel: 00 Id: 01 Lun: 00 > Vendor: PIONEER Model: DVD-ROM DVD-303 Rev: 1.10 > Type: CD-ROM ANSI SCSI revision: 02 > Host: scsi1 Channel: 00 Id: 05 Lun: 00 > Vendor: TEAC Model: CD-R58S Rev: 1.0N > Type: CD-ROM ANSI SCSI revision: 02 > Host: scsi2 Channel: 00 Id: 02 Lun: 00 > Vendor: PIONEER Model: DVD-ROM DVD-304 Rev: 1.03 > Type: CD-ROM ANSI SCSI revision: 02 > Host: scsi2 Channel: 00 Id: 03 Lun: 00 > Vendor: PIONEER Model: DVD-ROM DVD-304 Rev: 1.03 > Type: CD-ROM ANSI SCSI revision: 02 > Host: scsi2 Channel: 00 Id: 04 Lun: 00 > Vendor: TEAC Model: CD-R58S Rev: 1.0K > Type: CD-ROM ANSI SCSI revision: 02 > Host: scsi2 Channel: 00 Id: 06 Lun: 00 > Vendor: TEAC Model: CD-R58S Rev: 1.0P > Type: CD-ROM ANSI SCSI revision: 02 > > I have a "Symbios 53c1010 (Dual Channel Ultra 160)" and a "NCR 810a" The > two devices which are not found are connected through adapters onto the > second channel of the Symbios 53c1010. > > Kernel is 2.4.4 or 2.4.5ac6. > As host-adapter-driver i use the "SYM53C8XX"-driver > > If other info is needed, no problem. :-) You should check if your devices are enabled for SCAN in the NVRAM. Devices that aren't enabled for "SCAN AT BOOT" are forced by the driver to fail the initial SCSI scan. As a plus, the driver also applies the boot order for all Symbios HBAs that look Symbios-compatible regarding GPIO pins and NVRAM layout. For such subset of SCSI BUSes, this allows to present SCSI devices to the kernel in the same order as BIOS saw them. On the other hand, this may speed-up the system boot process a lot. If you had numerous O/Ses installed on a single system, you would appreciate as useful it is. For example, I use to boot an O/S with only drive 80 seen by BIOS and sda seen by system, and then mount the other disks in the order I want. Gérard. PS: See README.ncr53c8xx for the way to disable this feature if it does not fit your expectation. :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI-CD-Writer don't show up
On Sat, 2 Jun 2001, Matthias Schniedermeyer wrote: #Include hallo.h I have 3 SCSI-CD-Writers. Strange is that the boot-process only finds the first one (1 0 5 0), the other two i have to add with echo scsi add-single-device 2 0 4 0 /proc/scsi/scsi echo scsi add-single-device 2 0 6 0 /proc/scsi/scsi to make them useable. Here is the complete ist of my SCSI-Devices: Host: scsi0 Channel: 00 Id: 06 Lun: 00 Vendor: IBM Model: DDYS-T18350N Rev: S93E Type: Direct-AccessANSI SCSI revision: 03 Host: scsi1 Channel: 00 Id: 00 Lun: 00 Vendor: PLEXTOR Model: CD-ROM PX-32TS Rev: 1.03 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 01 Lun: 00 Vendor: PIONEER Model: DVD-ROM DVD-303 Rev: 1.10 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 05 Lun: 00 Vendor: TEAC Model: CD-R58S Rev: 1.0N Type: CD-ROM ANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 02 Lun: 00 Vendor: PIONEER Model: DVD-ROM DVD-304 Rev: 1.03 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 03 Lun: 00 Vendor: PIONEER Model: DVD-ROM DVD-304 Rev: 1.03 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 04 Lun: 00 Vendor: TEAC Model: CD-R58S Rev: 1.0K Type: CD-ROM ANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 06 Lun: 00 Vendor: TEAC Model: CD-R58S Rev: 1.0P Type: CD-ROM ANSI SCSI revision: 02 I have a Symbios 53c1010 (Dual Channel Ultra 160) and a NCR 810a The two devices which are not found are connected through adapters onto the second channel of the Symbios 53c1010. Kernel is 2.4.4 or 2.4.5ac6. As host-adapter-driver i use the SYM53C8XX-driver If other info is needed, no problem. :-) You should check if your devices are enabled for SCAN in the NVRAM. Devices that aren't enabled for SCAN AT BOOT are forced by the driver to fail the initial SCSI scan. As a plus, the driver also applies the boot order for all Symbios HBAs that look Symbios-compatible regarding GPIO pins and NVRAM layout. For such subset of SCSI BUSes, this allows to present SCSI devices to the kernel in the same order as BIOS saw them. On the other hand, this may speed-up the system boot process a lot. If you had numerous O/Ses installed on a single system, you would appreciate as useful it is. For example, I use to boot an O/S with only drive 80 seen by BIOS and sda seen by system, and then mount the other disks in the order I want. Gérard. PS: See README.ncr53c8xx for the way to disable this feature if it does not fit your expectation. :) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sym53c8xx timer and smp fixes
On Thu, 31 May 2001, Tim Hockin wrote: All, Attached is a patch for sym53c8xx.c to handle the error timer better, and be more proper for SMP. The changes are very simple, and have been beaten on by us. Please let me know if there are any problems accepting this patch for general inclusion. I have no problems accepting your patch. Thanks for it. I just want to have to deal with a human manageable finite number of actual driver versions :). I also want the same driver source to also be useable on recent 2.2 kernels. About timers in modules and more generally either timers in drivers or modules unloading, you must keep in mind that this stuff has been racy for years in Linux. Allow time for me to check if it is really fixed in latest kernel and so to make sure it is worthwhile to apply your patch. Gérard. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sym53c8xx timer and smp fixes
On Fri, 1 Jun 2001, Jeff Garzik wrote:
> Tim Hockin wrote:
> > spinlock_t sym53c8xx_lock = SPIN_LOCK_UNLOCKED;
> > +spinlock_t sym53c8xx_host_lock = SPIN_LOCK_UNLOCKED;
> > #defineNCR_LOCK_DRIVER(flags) spin_lock_irqsave(_lock,
>flags)
> > #defineNCR_UNLOCK_DRIVER(flags)
>spin_unlock_irqrestore(_lock,flags)
> > +#defineNCR_LOCK_HOSTS(flags) spin_lock_irqsave(_host_lock,
>flags)
> > +#defineNCR_UNLOCK_HOSTS(flags)
>spin_unlock_irqrestore(_host_lock,flags)
> >
> > #define NCR_INIT_LOCK_NCB(np) spin_lock_init(>smp_lock);
> > #defineNCR_LOCK_NCB(np, flags)spin_lock_irqsave(>smp_lock, flags)
> > @@ -650,6 +655,8 @@
> >
> > #defineNCR_LOCK_DRIVER(flags) do { save_flags(flags); cli(); } while
>(0)
> > #defineNCR_UNLOCK_DRIVER(flags) do { restore_flags(flags); } while (0)
> > +#defineNCR_LOCK_HOSTS(flags) do { save_flags(flags); cli(); } while
>(0)
> > +#defineNCR_UNLOCK_HOSTS(flags) do { restore_flags(flags); } while (0)
> >
> > #defineNCR_INIT_LOCK_NCB(np) do { } while (0)
> > #defineNCR_LOCK_NCB(np, flags)do { save_flags(flags); cli(); } while
>(0)
> > @@ -695,7 +702,7 @@
>
> so, this driver is mixed spinlocks and save/restore_flags? Any chance
> this can be converted to all spinlocks?
This has been done years ago for linux 2.1.93.
The save/restore flags locking methods are conditionnaly compiled for
earlier kernels. This makes the corresponding code very probably quite
useless nowadays and I should remove it from the source.
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sym53c8xx timer and smp fixes
On Fri, 1 Jun 2001, Jeff Garzik wrote:
Tim Hockin wrote:
spinlock_t sym53c8xx_lock = SPIN_LOCK_UNLOCKED;
+spinlock_t sym53c8xx_host_lock = SPIN_LOCK_UNLOCKED;
#defineNCR_LOCK_DRIVER(flags) spin_lock_irqsave(sym53c8xx_lock,
flags)
#defineNCR_UNLOCK_DRIVER(flags)
spin_unlock_irqrestore(sym53c8xx_lock,flags)
+#defineNCR_LOCK_HOSTS(flags) spin_lock_irqsave(sym53c8xx_host_lock,
flags)
+#defineNCR_UNLOCK_HOSTS(flags)
spin_unlock_irqrestore(sym53c8xx_host_lock,flags)
#define NCR_INIT_LOCK_NCB(np) spin_lock_init(np-smp_lock);
#defineNCR_LOCK_NCB(np, flags)spin_lock_irqsave(np-smp_lock, flags)
@@ -650,6 +655,8 @@
#defineNCR_LOCK_DRIVER(flags) do { save_flags(flags); cli(); } while
(0)
#defineNCR_UNLOCK_DRIVER(flags) do { restore_flags(flags); } while (0)
+#defineNCR_LOCK_HOSTS(flags) do { save_flags(flags); cli(); } while
(0)
+#defineNCR_UNLOCK_HOSTS(flags) do { restore_flags(flags); } while (0)
#defineNCR_INIT_LOCK_NCB(np) do { } while (0)
#defineNCR_LOCK_NCB(np, flags)do { save_flags(flags); cli(); } while
(0)
@@ -695,7 +702,7 @@
so, this driver is mixed spinlocks and save/restore_flags? Any chance
this can be converted to all spinlocks?
This has been done years ago for linux 2.1.93.
The save/restore flags locking methods are conditionnaly compiled for
earlier kernels. This makes the corresponding code very probably quite
useless nowadays and I should remove it from the source.
Gérard.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: alpha iommu fixes
On Sun, 20 May 2001, Ivan Kokshaysky wrote: > On Sun, May 20, 2001 at 04:40:13AM +0200, Andrea Arcangeli wrote: > > I was only talking about when you get the "pci_map_sg failed" because > > you have not 3 but 300 scsi disks connected to your system and you are > > writing to all them at the same time allocating zillons of pte, and one > > of your drivers (possibly not even a storage driver) is actually not > > checking the reval of the pci_map_* functions. You don't need a pte > > memleak to trigger it, even regardless of the fact I grown the dynamic > > window to 1G which makes it 8 times harder to trigger than in mainline. > > I think you're too pessimistic. Don't mix "disks" and "controllers" -- > SCSI adapter with 10 drives attached is a single DMA agent, not 10 agents. > > If you're so concerned about Big Iron, go ahead and implement 64-bit PCI > support, it would be right long-term solution. I'm pretty sure that > high-end servers use mostly this kind of hardware. > > Oh, well. This doesn't mean that I'm disagreed with what you said. :-) > Driver writers must realize that pci mappings are limited resources. The IOMMU code allocation strategy is designed to fail due to fragmentation as everything that performs contiguous allocations of variable quantities. I may add a test of pci_map_* return code in the sym53c8xx driver, but the driver will panic on failure. It is not acceptable to consider such kind of failure as a normal situation (returning some ?_BUSY status to the SCSI driver) for the following reasons: - IOs may be reordered and break upper layers assumptions. - Spurious errors and even BUS resets may happen. For now, driver methods that are requested to queue IOs are not allowed to wait for resources. Anyway, the pci_map_* interface is unable to wait. There are obviously ways to deal gracefully with such resource lack, but the current SCSI layer isn't featured for that. For example, a freeze/unfreeze mechanism as described in CAM can be implemented in order not to reorder IOs, and some mechanism (callback, resource wait, etc...) must be added to restart the operation when resource is likely to be available. IMO, the only acceptable fix in the current kernel is to perform IOMMU PTE allocations of a fixed quantity at a time, as limiting SG entry to fit in a single PAGE for example. Gérard. PS: May-be I should look how *BSD's handles IOMMUs. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alpha iommu fixes
On Sun, 20 May 2001, Ivan Kokshaysky wrote: On Sun, May 20, 2001 at 04:40:13AM +0200, Andrea Arcangeli wrote: I was only talking about when you get the pci_map_sg failed because you have not 3 but 300 scsi disks connected to your system and you are writing to all them at the same time allocating zillons of pte, and one of your drivers (possibly not even a storage driver) is actually not checking the reval of the pci_map_* functions. You don't need a pte memleak to trigger it, even regardless of the fact I grown the dynamic window to 1G which makes it 8 times harder to trigger than in mainline. I think you're too pessimistic. Don't mix disks and controllers -- SCSI adapter with 10 drives attached is a single DMA agent, not 10 agents. If you're so concerned about Big Iron, go ahead and implement 64-bit PCI support, it would be right long-term solution. I'm pretty sure that high-end servers use mostly this kind of hardware. Oh, well. This doesn't mean that I'm disagreed with what you said. :-) Driver writers must realize that pci mappings are limited resources. The IOMMU code allocation strategy is designed to fail due to fragmentation as everything that performs contiguous allocations of variable quantities. I may add a test of pci_map_* return code in the sym53c8xx driver, but the driver will panic on failure. It is not acceptable to consider such kind of failure as a normal situation (returning some ?_BUSY status to the SCSI driver) for the following reasons: - IOs may be reordered and break upper layers assumptions. - Spurious errors and even BUS resets may happen. For now, driver methods that are requested to queue IOs are not allowed to wait for resources. Anyway, the pci_map_* interface is unable to wait. There are obviously ways to deal gracefully with such resource lack, but the current SCSI layer isn't featured for that. For example, a freeze/unfreeze mechanism as described in CAM can be implemented in order not to reorder IOs, and some mechanism (callback, resource wait, etc...) must be added to restart the operation when resource is likely to be available. IMO, the only acceptable fix in the current kernel is to perform IOMMU PTE allocations of a fixed quantity at a time, as limiting SG entry to fit in a single PAGE for example. Gérard. PS: May-be I should look how *BSD's handles IOMMUs. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wow! Is memory ever cheap!
On Tue, 8 May 2001, Dan Hollis wrote: > On Tue, 8 May 2001, Larry McVoy wrote: > > which is a text version of the paper I mentioned before. The basic > > message of the paper is that it really doesn't help much to have things > > like ECC unless you can be sure that 100% of the rest of your system > > has similar checks. > > UDMA has crc, scsi has parity, pci has (i think) parity, tcpip has crc, > your cpu l1 and l2 have ecc... SCSI Ultra-160 has CRC. PCI has parity (btw, you think right), but only a few drivers make sure PCI parity checking is enabled. On the other hand, a PCI parity error should be considered as extremally serious and the system should be stopped when such happens. Btw, it seems (read at the pci list) that the original PCI hadn't parity. After all, PCI had been designed for PC machines... :) > Looks like similar checks are already there. > > -Dan > Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wow! Is memory ever cheap!
On Tue, 8 May 2001, Dan Hollis wrote: On Tue, 8 May 2001, Larry McVoy wrote: which is a text version of the paper I mentioned before. The basic message of the paper is that it really doesn't help much to have things like ECC unless you can be sure that 100% of the rest of your system has similar checks. UDMA has crc, scsi has parity, pci has (i think) parity, tcpip has crc, your cpu l1 and l2 have ecc... SCSI Ultra-160 has CRC. PCI has parity (btw, you think right), but only a few drivers make sure PCI parity checking is enabled. On the other hand, a PCI parity error should be considered as extremally serious and the system should be stopped when such happens. Btw, it seems (read at the pci list) that the original PCI hadn't parity. After all, PCI had been designed for PC machines... :) Looks like similar checks are already there. -Dan Gérard. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ServerWorks LE and MTRR
On Sun, 29 Apr 2001, Steffen Persvold wrote: > [EMAIL PROTECTED] wrote: > > On Sun, 29 Apr 2001, Steffen Persvold wrote: > > > > > I've learned it the hard way, I have two types : Compaq DL360 (rev 5) and a > > > Tyan S2510 (rev 6). On the compaq machine I constantly get data corruption on > > > the last double word (4 bytes) in a 64 byte PCI burst when I use write > > > combining on the CPU. On the Tyan however the transfer is always ok. > > > > > > > Are you sure that is not due to board design differences? > > No I can't be 100% certain that the layout of the board isn't the reason since > I haven't asked ServerWorks about this and it doesn't say anything in their > docs (yes my company has the NDA, so I shouldn't get to much in detail here), > but if this was the case it would be totally wrong to disable write combining > on any LE chipset. > > The test case that I have been using to trigger this is sort of special because > we are using SCI shared memory adapters to write (with PIO) into remote nodes > memory, and the bandwidth tends to get quite high (approx 170 MByte/sec on LE > with write combining). I've been able to run this case on 5 different > motherboards using the LE and HE-SL ServerWorks chipsets, but only two of them > are LE (the DL360 and the S2510). Everything works fine with write-combining on > every motherboard except the DL360 (which has rev 5). > > One basic test case that I haven't tried, could be to enable write-combining on > your PCI graphics adapter memory and see if the X display gets screwed up. Done since 8 months on my Supermicro 370 DLE board. /proc/pci tells about 2 PCI bridges rev. 5. The 64bit PCI (bus 1) is interfacing a LSI53C1010 33MHz 64 bit PCI-SCSI controller. The other devices (3dfx, SYM53C895, ...) are on PCI bus #0. The machine does network using an external modem only. Never got a single glitch (linux-2.2.18), but the machine is not a server but my workstation I use at home. Here is /proc/pci layout: PCI devices found: Bus 0, device 0, function 1: Host bridge: Unknown vendor CNB30LE PCI Bridge (rev 5). Medium devsel. Master Capable. Latency=16. Bus 0, device 0, function 0: Host bridge: Unknown vendor CNB30LE PCI Bridge (rev 5). Medium devsel. Master Capable. Latency=32. Bus 0, device 1, function 0: SCSI storage controller: NCR 53c895 (rev 1). Medium devsel. IRQ 16. Master Capable. Latency=72. Min Gnt=30.Max Lat=64. I/O at 0xde00 [0xde01]. Non-prefetchable 32 bit memory at 0xfeaefe00 [0xfeaefe00]. Non-prefetchable 32 bit memory at 0xfeaec000 [0xfeaec000]. Bus 0, device 2, function 0: SCSI storage controller: NCR 53c810 (rev 18). Medium devsel. IRQ 18. Master Capable. Latency=64. Min Gnt=8.Max Lat=64. I/O at 0xd400 [0xd401]. Non-prefetchable 32 bit memory at 0xfeaeff00 [0xfeaeff00]. Bus 0, device 3, function 0: VGA compatible controller: 3Dfx Unknown device (rev 1). Vendor id=121a. Device id=5. Fast devsel. Fast back-to-back capable. IRQ 20. Non-prefetchable 32 bit memory at 0xfc00 [0xfc00]. Prefetchable 32 bit memory at 0xf800 [0xf808]. I/O at 0xd800 [0xd801]. Bus 0, device 6, function 0: Ethernet controller: Intel 82557 (rev 8). Medium devsel. Fast back-to-back capable. IRQ 31. Master Capable. Latency=64. Min Gnt=8.Max Lat=56. Non-prefetchable 32 bit memory at 0xfeaed000 [0xfeaed000]. I/O at 0xd000 [0xd001]. Non-prefetchable 32 bit memory at 0xfe90 [0xfe90]. Bus 0, device 15, function 0: ISA bridge: Unknown vendor Unknown device (rev 79). Vendor id=1166. Device id=200. Medium devsel. Master Capable. No bursts. Bus 0, device 15, function 1: IDE interface: Unknown vendor Unknown device (rev 0). Vendor id=1166. Device id=211. Medium devsel. Master Capable. Latency=64. I/O at 0xffa0 [0xffa1]. Bus 0, device 15, function 2: USB Controller: Unknown vendor Unknown device (rev 4). Vendor id=1166. Device id=220. Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable. Latency=64. Max Lat=80. Non-prefetchable 32 bit memory at 0xfeaee000 [0xfeaee000]. Bus 1, device 1, function 1: SCSI storage controller: NCR Unknown device (rev 1). Vendor id=1000. Device id=20. Medium devsel. IRQ 25. Master Capable. Latency=72. Min Gnt=17.Max Lat=18. I/O at 0xe800 [0xe801]. Non-prefetchable 64 bit memory at 0xfebffc00 [0xfebffc04]. Non-prefetchable 64 bit memory at 0xfebfc000 [0xfebfc004]. Bus 1, device 1, function 0: SCSI storage controller: NCR Unknown device (rev 1). Vendor id=1000. Device id=20. Medium devsel. IRQ 24. Master Capable. Latency=72. Min Gnt=17.Max Lat=18. I/O at 0xe400 [0xe401]. Non-prefetchable 64 bit memory at 0xfebff800 [0xfebff804]. Non-prefetchable 64 bit
Re: ServerWorks LE and MTRR
On Sun, 29 Apr 2001, Steffen Persvold wrote: [EMAIL PROTECTED] wrote: On Sun, 29 Apr 2001, Steffen Persvold wrote: I've learned it the hard way, I have two types : Compaq DL360 (rev 5) and a Tyan S2510 (rev 6). On the compaq machine I constantly get data corruption on the last double word (4 bytes) in a 64 byte PCI burst when I use write combining on the CPU. On the Tyan however the transfer is always ok. Are you sure that is not due to board design differences? No I can't be 100% certain that the layout of the board isn't the reason since I haven't asked ServerWorks about this and it doesn't say anything in their docs (yes my company has the NDA, so I shouldn't get to much in detail here), but if this was the case it would be totally wrong to disable write combining on any LE chipset. The test case that I have been using to trigger this is sort of special because we are using SCI shared memory adapters to write (with PIO) into remote nodes memory, and the bandwidth tends to get quite high (approx 170 MByte/sec on LE with write combining). I've been able to run this case on 5 different motherboards using the LE and HE-SL ServerWorks chipsets, but only two of them are LE (the DL360 and the S2510). Everything works fine with write-combining on every motherboard except the DL360 (which has rev 5). One basic test case that I haven't tried, could be to enable write-combining on your PCI graphics adapter memory and see if the X display gets screwed up. Done since 8 months on my Supermicro 370 DLE board. /proc/pci tells about 2 PCI bridges rev. 5. The 64bit PCI (bus 1) is interfacing a LSI53C1010 33MHz 64 bit PCI-SCSI controller. The other devices (3dfx, SYM53C895, ...) are on PCI bus #0. The machine does network using an external modem only. Never got a single glitch (linux-2.2.18), but the machine is not a server but my workstation I use at home. Here is /proc/pci layout: PCI devices found: Bus 0, device 0, function 1: Host bridge: Unknown vendor CNB30LE PCI Bridge (rev 5). Medium devsel. Master Capable. Latency=16. Bus 0, device 0, function 0: Host bridge: Unknown vendor CNB30LE PCI Bridge (rev 5). Medium devsel. Master Capable. Latency=32. Bus 0, device 1, function 0: SCSI storage controller: NCR 53c895 (rev 1). Medium devsel. IRQ 16. Master Capable. Latency=72. Min Gnt=30.Max Lat=64. I/O at 0xde00 [0xde01]. Non-prefetchable 32 bit memory at 0xfeaefe00 [0xfeaefe00]. Non-prefetchable 32 bit memory at 0xfeaec000 [0xfeaec000]. Bus 0, device 2, function 0: SCSI storage controller: NCR 53c810 (rev 18). Medium devsel. IRQ 18. Master Capable. Latency=64. Min Gnt=8.Max Lat=64. I/O at 0xd400 [0xd401]. Non-prefetchable 32 bit memory at 0xfeaeff00 [0xfeaeff00]. Bus 0, device 3, function 0: VGA compatible controller: 3Dfx Unknown device (rev 1). Vendor id=121a. Device id=5. Fast devsel. Fast back-to-back capable. IRQ 20. Non-prefetchable 32 bit memory at 0xfc00 [0xfc00]. Prefetchable 32 bit memory at 0xf800 [0xf808]. I/O at 0xd800 [0xd801]. Bus 0, device 6, function 0: Ethernet controller: Intel 82557 (rev 8). Medium devsel. Fast back-to-back capable. IRQ 31. Master Capable. Latency=64. Min Gnt=8.Max Lat=56. Non-prefetchable 32 bit memory at 0xfeaed000 [0xfeaed000]. I/O at 0xd000 [0xd001]. Non-prefetchable 32 bit memory at 0xfe90 [0xfe90]. Bus 0, device 15, function 0: ISA bridge: Unknown vendor Unknown device (rev 79). Vendor id=1166. Device id=200. Medium devsel. Master Capable. No bursts. Bus 0, device 15, function 1: IDE interface: Unknown vendor Unknown device (rev 0). Vendor id=1166. Device id=211. Medium devsel. Master Capable. Latency=64. I/O at 0xffa0 [0xffa1]. Bus 0, device 15, function 2: USB Controller: Unknown vendor Unknown device (rev 4). Vendor id=1166. Device id=220. Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable. Latency=64. Max Lat=80. Non-prefetchable 32 bit memory at 0xfeaee000 [0xfeaee000]. Bus 1, device 1, function 1: SCSI storage controller: NCR Unknown device (rev 1). Vendor id=1000. Device id=20. Medium devsel. IRQ 25. Master Capable. Latency=72. Min Gnt=17.Max Lat=18. I/O at 0xe800 [0xe801]. Non-prefetchable 64 bit memory at 0xfebffc00 [0xfebffc04]. Non-prefetchable 64 bit memory at 0xfebfc000 [0xfebfc004]. Bus 1, device 1, function 0: SCSI storage controller: NCR Unknown device (rev 1). Vendor id=1000. Device id=20. Medium devsel. IRQ 24. Master Capable. Latency=72. Min Gnt=17.Max Lat=18. I/O at 0xe400 [0xe401]. Non-prefetchable 64 bit memory at 0xfebff800 [0xfebff804]. Non-prefetchable 64 bit memory at 0xfebfa000 [0xfebfa004]. I
Re: ServerWorks LE and MTRR
On Sun, 29 Apr 2001, Steffen Persvold wrote:
> Hi all,
>
> I just compiled 2.4.4 and are running it on a Serverworks LE motherboard.
> Whenever I try to add a write-combining region, it gets rejected. I took a peek
> in the arch/i386/kernel/mtrr.c and found that this is just as expected with
> v1.40 of the code. It is great that the mtrr code checks and prevents the user
> from doing something that could eventually lead to data corruption. Using
> write-combining on PCI acesses can lead to this on certain LE revisions but
> _not_ all (only rev < 5). Therefore please consider my small patch to allow the
> good ones to be able to use write-combining. I have several rev 06 and they are
> working fine with this patch.
You wrote that 'only rev < 5' can lead to data corruption, but your patch
seems to disallow use of write combining for rev 5 too.
Could you clarify?
Gérard.
PS:
From what hat did you get this information ? as it seems that ServerWorks
require NDA for letting know technical information on their chipsets.
> Best regards,
> --
> Steffen PersvoldSystems Engineer
> Email : mailto:[EMAIL PROTECTED]Scali AS (http://www.scali.com)
> Norway : Tel : (+47) 2262 8950 Olaf Helsets vei 6
> Fax : (+47) 2262 8951 N-0621 Oslo, Norway
>
> USA: Tel : (+1) 713 706 0544 10500 Richmond Avenue, Suite 190
> Houston, Texas 77042, USA
>
> diff -Nur linux/arch/i386/kernel/mtrr.c.~1~ linux/arch/i386/kernel/mtrr.c
> --- linux/arch/i386/kernel/mtrr.c.~1~ Wed Apr 11 21:02:27 2001
> +++ linux/arch/i386/kernel/mtrr.c Sun Apr 29 10:18:06 2001
> @@ -480,6 +480,7 @@
> {
> unsigned long config, dummy;
> struct pci_dev *dev = NULL;
> +u8 rev;
>
> /* ServerWorks LE chipsets have problems with write-combining
>Don't allow it and leave room for other chipsets to be tagged */
> @@ -489,7 +490,9 @@
> case PCI_VENDOR_ID_SERVERWORKS:
> switch (dev->device) {
> case PCI_DEVICE_ID_SERVERWORKS_LE:
> - return 0;
> + pci_read_config_byte(dev, PCI_CLASS_REVISION, );
> + if (rev <= 5)
> + return 0;
> break;
> default:
> break;
> -
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ServerWorks LE and MTRR
On Sun, 29 Apr 2001, Steffen Persvold wrote:
Hi all,
I just compiled 2.4.4 and are running it on a Serverworks LE motherboard.
Whenever I try to add a write-combining region, it gets rejected. I took a peek
in the arch/i386/kernel/mtrr.c and found that this is just as expected with
v1.40 of the code. It is great that the mtrr code checks and prevents the user
from doing something that could eventually lead to data corruption. Using
write-combining on PCI acesses can lead to this on certain LE revisions but
_not_ all (only rev 5). Therefore please consider my small patch to allow the
good ones to be able to use write-combining. I have several rev 06 and they are
working fine with this patch.
You wrote that 'only rev 5' can lead to data corruption, but your patch
seems to disallow use of write combining for rev 5 too.
Could you clarify?
Gérard.
PS:
From what hat did you get this information ? as it seems that ServerWorks
require NDA for letting know technical information on their chipsets.
Best regards,
--
Steffen PersvoldSystems Engineer
Email : mailto:[EMAIL PROTECTED]Scali AS (http://www.scali.com)
Norway : Tel : (+47) 2262 8950 Olaf Helsets vei 6
Fax : (+47) 2262 8951 N-0621 Oslo, Norway
USA: Tel : (+1) 713 706 0544 10500 Richmond Avenue, Suite 190
Houston, Texas 77042, USA
diff -Nur linux/arch/i386/kernel/mtrr.c.~1~ linux/arch/i386/kernel/mtrr.c
--- linux/arch/i386/kernel/mtrr.c.~1~ Wed Apr 11 21:02:27 2001
+++ linux/arch/i386/kernel/mtrr.c Sun Apr 29 10:18:06 2001
@@ -480,6 +480,7 @@
{
unsigned long config, dummy;
struct pci_dev *dev = NULL;
+u8 rev;
/* ServerWorks LE chipsets have problems with write-combining
Don't allow it and leave room for other chipsets to be tagged */
@@ -489,7 +490,9 @@
case PCI_VENDOR_ID_SERVERWORKS:
switch (dev-device) {
case PCI_DEVICE_ID_SERVERWORKS_LE:
- return 0;
+ pci_read_config_byte(dev, PCI_CLASS_REVISION, rev);
+ if (rev = 5)
+ return 0;
break;
default:
break;
-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sym53c875 error
On Tue, 24 Apr 2001, Hamilton, Eamonn wrote: > Hi Folks. > > Under all of the kernels I have access to try ( 2.2.19, 2.4.X & 2.4.X-ac* ), > when I try and write an image in XA2 format to my SCSI writer ( Yamaha > CDR-400t ), I get a DMA overrun. When I try with a kernel patched with the > beta symbios driver ( 2.1.9 ), it works just fine. Interesting. Note that sym-2.1.9 status is probably far better than beta. I just haven't information enough to know how reliable this driver version actually is. FYI, I use sym-2.1.x under Linux and FreeBSD since several months. The NetBSD port is still work in progress, but the driver works just fine for me under this O/S too. > This is on a Debian woody system, using cdrecord 1.10 ( also 1.9 and 1.8 > with the same symptoms ) attached to a Tekram DC390F. > > Transcript as follows : > > cdrecord dev=0,3,0 -dummy -xa2 firmware.iso > > Cdrecord 1.10a18 (i686-pc-linux-gnu) Copyright (C) 1995-2001 Jörg Schilling > scsidev: '0,3,0' > scsibus: 0 target: 3 lun: 0 > Linux sg driver version: 3.1.17 > Using libscg version 'schily-0.5' > Device type: Removable CD-ROM > Version: 2 > Response Format: 2 > Capabilities : > Vendor_info: 'YAMAHA ' > Identifikation : 'CDR400t ' > Revision : '1.0q' > Device seems to be: Yamaha CDR-400. > Using generic SCSI-3/mmc CD-R driver (mmc_cdr). > Driver flags : SWABAUDIO > Starting to write CD/DVD at speed 1 in dummy mode for single session. > Last chance to quit, starting dummy write in 1 seconds. > cdrecord: Input/output error. write_g1: scsi sendcmd: retryable error > CDB: 2A 00 00 00 01 C2 00 00 1F 00 > status: 0x0 (GOOD STATUS) > DMA overrun, resid: -248 Would be interesting to know how cdrecord calculates the residual. It should probably use the return value from read()/write(). Does it ? > cmd finished after 0.579s timeout 40s > write track data: error after 0 bytes > Sense Bytes: 70 00 00 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 > > > And while that lot happens, I get > > sym53c875-0-<3,*>: target did not report SYNC. This message is not normal given the device that for sure supports synchronous data transfers. I will look into this problem, first. > sym53c875-0-<3,*>: extraneous data discarded. > sym53c875-0-<3,*>: COMMAND FAILED (89 0) @c12a3800. This one could have been triggerred by previous errors ???. > Standard burns work ok, it's just the xa2 stuff I have a problem with so > far. I also tried using the old NCR driver with the same results. If you mean that the ncr53c8xx driver gets the same error, then the cause can be a either common bug in sym53c8xx and ncr53c8xx, or caused by a difference between sym53c8xx/ncr53c8xx and sym-2.1.9. The main difference that comes to mind is that sym-2 uses the new error handling interface but sym53c8xx/ncr53c8xx use the old one. If it is the cause, then the sg driver might get involved in the failure. > Anybody got any ideas? No more than the above for now. Will let you know if I get better ones. Regards, Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sym53c875 error
On Tue, 24 Apr 2001, Hamilton, Eamonn wrote: Hi Folks. Under all of the kernels I have access to try ( 2.2.19, 2.4.X 2.4.X-ac* ), when I try and write an image in XA2 format to my SCSI writer ( Yamaha CDR-400t ), I get a DMA overrun. When I try with a kernel patched with the beta symbios driver ( 2.1.9 ), it works just fine. Interesting. Note that sym-2.1.9 status is probably far better than beta. I just haven't information enough to know how reliable this driver version actually is. FYI, I use sym-2.1.x under Linux and FreeBSD since several months. The NetBSD port is still work in progress, but the driver works just fine for me under this O/S too. This is on a Debian woody system, using cdrecord 1.10 ( also 1.9 and 1.8 with the same symptoms ) attached to a Tekram DC390F. Transcript as follows : cdrecord dev=0,3,0 -dummy -xa2 firmware.iso Cdrecord 1.10a18 (i686-pc-linux-gnu) Copyright (C) 1995-2001 Jörg Schilling scsidev: '0,3,0' scsibus: 0 target: 3 lun: 0 Linux sg driver version: 3.1.17 Using libscg version 'schily-0.5' Device type: Removable CD-ROM Version: 2 Response Format: 2 Capabilities : Vendor_info: 'YAMAHA ' Identifikation : 'CDR400t ' Revision : '1.0q' Device seems to be: Yamaha CDR-400. Using generic SCSI-3/mmc CD-R driver (mmc_cdr). Driver flags : SWABAUDIO Starting to write CD/DVD at speed 1 in dummy mode for single session. Last chance to quit, starting dummy write in 1 seconds. cdrecord: Input/output error. write_g1: scsi sendcmd: retryable error CDB: 2A 00 00 00 01 C2 00 00 1F 00 status: 0x0 (GOOD STATUS) DMA overrun, resid: -248 Would be interesting to know how cdrecord calculates the residual. It should probably use the return value from read()/write(). Does it ? cmd finished after 0.579s timeout 40s write track data: error after 0 bytes Sense Bytes: 70 00 00 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 And while that lot happens, I get sym53c875-0-3,*: target did not report SYNC. This message is not normal given the device that for sure supports synchronous data transfers. I will look into this problem, first. sym53c875-0-3,*: extraneous data discarded. sym53c875-0-3,*: COMMAND FAILED (89 0) @c12a3800. This one could have been triggerred by previous errors ???. Standard burns work ok, it's just the xa2 stuff I have a problem with so far. I also tried using the old NCR driver with the same results. If you mean that the ncr53c8xx driver gets the same error, then the cause can be a either common bug in sym53c8xx and ncr53c8xx, or caused by a difference between sym53c8xx/ncr53c8xx and sym-2.1.9. The main difference that comes to mind is that sym-2 uses the new error handling interface but sym53c8xx/ncr53c8xx use the old one. If it is the cause, then the sg driver might get involved in the failure. Anybody got any ideas? No more than the above for now. Will let you know if I get better ones. Regards, Gérard. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: scanner problem
On Thu, 12 Apr 2001 [EMAIL PROTECTED] wrote: > hi, > > when trying to scan with xsane and "agfa snapscan 1236s", i get the > following message: > > Attached scsi generic sg2 at scsi0, channel 0, id 5, lun 0, type 6 > sym53c895-0-<5,*>: target did not report SYNC. This message is just a warning. If your scanner does not support synchronous data transfers, then it is ok. You may want to check the doc of the device on this point. > sym53c895-0-<5,0>: extraneous data discarded. > sym53c895-0-<5,0>: COMMAND FAILED (89 0) @cff3d000. This is the way the driver signals data overrun. Btw, I never used xsane. If this tool has some trace mode that tells what SCSI commands are sent to the device, this would help to get such traces. > what can i do about this? At least, try to catch the SCSI commands that are sent to the device, and report them. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI Tape Corruption - update
On Thu, 12 Apr 2001 [EMAIL PROTECTED] wrote: > Still experimenting with my SDT-9000... tried connecting it to another > controller > (2940AU in place of 2904, sorry but I've only Adaptec stuff :). Same > problem. > Tried with another tape (even with an old DDS-2 tape). Same. Even tried > another > cable/removing the CDWR drive from the bus. > > It seems that the tape is written incorrectly. I wrote some large file > (300MB) > and read it back four time. The read copies are all the same. They differ > from the original only in 32 consecutive bytes (the replaced values SEEM > random). Of course, 32 bytes in 300MB tar.gz files are TOO MUCH to be > accepted :) A similar problem has been reported under Linux/PPC a couple of weeks ago using a sym53c875 controller. In this case, kernel 2.2 was fine. > Now I'll build some old 2.2 kernel to try... If 2.2 is ok with your tape, a software error in 2.4 gets very likely, in my opinion. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI Tape Corruption - update
On Thu, 12 Apr 2001 [EMAIL PROTECTED] wrote: Still experimenting with my SDT-9000... tried connecting it to another controller (2940AU in place of 2904, sorry but I've only Adaptec stuff :). Same problem. Tried with another tape (even with an old DDS-2 tape). Same. Even tried another cable/removing the CDWR drive from the bus. It seems that the tape is written incorrectly. I wrote some large file (300MB) and read it back four time. The read copies are all the same. They differ from the original only in 32 consecutive bytes (the replaced values SEEM random). Of course, 32 bytes in 300MB tar.gz files are TOO MUCH to be accepted :) A similar problem has been reported under Linux/PPC a couple of weeks ago using a sym53c875 controller. In this case, kernel 2.2 was fine. Now I'll build some old 2.2 kernel to try... If 2.2 is ok with your tape, a software error in 2.4 gets very likely, in my opinion. Grard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: scanner problem
On Thu, 12 Apr 2001 [EMAIL PROTECTED] wrote: hi, when trying to scan with xsane and "agfa snapscan 1236s", i get the following message: Attached scsi generic sg2 at scsi0, channel 0, id 5, lun 0, type 6 sym53c895-0-5,*: target did not report SYNC. This message is just a warning. If your scanner does not support synchronous data transfers, then it is ok. You may want to check the doc of the device on this point. sym53c895-0-5,0: extraneous data discarded. sym53c895-0-5,0: COMMAND FAILED (89 0) @cff3d000. This is the way the driver signals data overrun. Btw, I never used xsane. If this tool has some trace mode that tells what SCSI commands are sent to the device, this would help to get such traces. what can i do about this? At least, try to catch the SCSI commands that are sent to the device, and report them. Grard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx and 2.4.3 failures - fix, it is interrupt routing
On Mon, 9 Apr 2001, Jim Studt wrote: > G*rard Roudier insightfully opined.. > > Looks like an IRQ problem to me. > > I mean the kernel wants to change IRQ routing and just do the wrong job. > > Give the man a prize! > > After failing to work with 2.4.0, 2.4.1, 2.4.3, and 2.4.3-ac3 I > enabled X86_UP_IOAPIC to stir up the interrupt code and it works. > > I'll keep one of these servers set aside for testing and see if I can't > figure out a little more specifically what the problem is, but IOAPIC > is fine. Probably because the code that messes with IRQs isn't involved when IOAPIC is used. If I had to guess I would point "arch/i386/kernel/pci-irq.c", function "pcibios_lookup_irq()". Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx and 2.4.3 failures - fix, it is interrupt routing
On Mon, 9 Apr 2001, Jim Studt wrote: G*rard Roudier insightfully opined.. Looks like an IRQ problem to me. I mean the kernel wants to change IRQ routing and just do the wrong job. Give the man a prize! After failing to work with 2.4.0, 2.4.1, 2.4.3, and 2.4.3-ac3 I enabled X86_UP_IOAPIC to stir up the interrupt code and it works. I'll keep one of these servers set aside for testing and see if I can't figure out a little more specifically what the problem is, but IOAPIC is fine. Probably because the code that messes with IRQs isn't involved when IOAPIC is used. If I had to guess I would point "arch/i386/kernel/pci-irq.c", function "pcibios_lookup_irq()". Grard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx and 2.4.3 failures
Looks like an IRQ problem to me. I mean the kernel wants to change IRQ routing and just do the wrong job. Ingo reported me a similar problem a couple of week ago that made failed the sym53c8xx driver. Looks very similar to this one with the kernel PCI code wanting to assign IRQ 11 to almost everything. Btw, I donnot know the cause of the problem since I am still expecting some reply following some suggestions from me. :-) Gerard. On Mon, 9 Apr 2001, Jim Studt wrote: > > > A typical startup with 6.1.9 proceeds like this... (6.1.10 hangs silently > > > after emitting the scsi0 and scsi1 adapter summaries, maybe it is > > > going through the same gyrations silently.) > > > > > > > Alan Cox directs... > > Try saying N to the AIC7xxx driver and Y to AIC7XXX_OLD and see if that works. > > This is important both because it might solve your problem for now but also > > because if the old driver works we can be fairly sure the bug is in the > > new adaptec driver and not elsewhere and triggered on it > > Using AIC7XXX_OLD does not work either. Different output > > SCSI subsystem driver Revision: 1.00 > PCI: Assigned IRQ 11 for device 00:0c.0 > PCI: The same IRQ used for device 00:0c.1 > PCI: Found IRQ 11 for device 00:0c.1 > PCI: The same IRQ used for device 00:0c.0 > (scsi0) found at PCI 0/12/0 > (scsi0) Wide Channel A, SCSI ID=7, 32/255 SCBs > (scsi0) Downloading sequencer code... 392 instructions downloaded > (scsi1) found at PCI 0/12/1 > (scsi1) Wide Channel B, SCSI ID=7, 32/255 SCBs > (scsi1) Downloading sequencer code... 392 instructions downloaded > scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0 > > scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0 > > scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0, lun 0 >Inquiry 00 00 00 ff 00 > SCSI host 0 abort (pid 0) timed out - resetting > SCSI bus is being reset for host 0 channel 0. > SCSI host 0 channel 0 reset (pid 0) timed out - trying harder > SCSI bus is being reset for host 0 channel 0. > SCSI host 0 abort (pid 0) timed out - resetting > SCSI bus is being reset for host 0 channel 0. > SCSI host 0 channel 0 reset (pid 0) timed out - trying harder > SCSI bus is being reset for host 0 channel 0. > SCSI host 0 abort (pid 0) timed out - resetting > SCSI bus is being reset for host 0 channel 0. > .. > > > Since we are looking elsewhere now... I have tried PCI access mode > BIOS and Direct with no improvement. > > There is an unrecognized PCI bridge resource in the boot messages... > > CPU: L1 I cache: 16K, L1 D cache: 16K > CPU: L2 cache: 256K > Intel machine check architecture supported. > Intel machine check reporting enabled on CPU#0. > CPU serial number disabled. > CPU: Intel Pentium III (Coppermine) stepping 06 > Enabling fast FPU save and restore... done. > Enabling unmasked SIMD FPU exception support... done. > Checking 'hlt' instruction... OK. > POSIX conformance testing by UNIFIX > mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) > mtrr: detected mtrr type: Intel > PCI: Using configuration type 1 > PCI: Probing PCI hardware > Unknown bridge resource 0: assuming transparent > Unknown bridge resource 1: assuming transparent > Unknown bridge resource 2: assuming transparent > Unknown bridge resource 0: assuming transparent > Unknown bridge resource 1: assuming transparent > Unknown bridge resource 2: assuming transparent > PCI: Discovered primary peer bus ff [IRQ] > PCI: Using IRQ router PIIX [8086/7110] at 00:12.0 > > # lspci > 00:00.0 Host bridge: Intel Corporation 440GX - 82443GX Host bridge > 00:01.0 PCI bridge: Intel Corporation 440GX - 82443GX AGP bridge > 00:0c.0 SCSI storage controller: Adaptec 7896 > 00:0c.1 SCSI storage controller: Adaptec 7896 > 00:0e.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) > 00:12.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) > 00:12.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) > 00:12.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) > 00:12.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) > 00:14.0 VGA compatible controller: Cirrus Logic GD 5480 (rev 23) > 01:0f.0 PCI bridge: Digital Equipment Corporation DECchip 21150 (rev 06) > > I will go back and try 2.4.0 and 2.4.3-ac3 and see where that gets me. > > -- > Jim Studt, President > The Federated Software Group, Inc. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx and 2.4.3 failures
Looks like an IRQ problem to me. I mean the kernel wants to change IRQ routing and just do the wrong job. Ingo reported me a similar problem a couple of week ago that made failed the sym53c8xx driver. Looks very similar to this one with the kernel PCI code wanting to assign IRQ 11 to almost everything. Btw, I donnot know the cause of the problem since I am still expecting some reply following some suggestions from me. :-) Gerard. On Mon, 9 Apr 2001, Jim Studt wrote: A typical startup with 6.1.9 proceeds like this... (6.1.10 hangs silently after emitting the scsi0 and scsi1 adapter summaries, maybe it is going through the same gyrations silently.) Alan Cox directs... Try saying N to the AIC7xxx driver and Y to AIC7XXX_OLD and see if that works. This is important both because it might solve your problem for now but also because if the old driver works we can be fairly sure the bug is in the new adaptec driver and not elsewhere and triggered on it Using AIC7XXX_OLD does not work either. Different output SCSI subsystem driver Revision: 1.00 PCI: Assigned IRQ 11 for device 00:0c.0 PCI: The same IRQ used for device 00:0c.1 PCI: Found IRQ 11 for device 00:0c.1 PCI: The same IRQ used for device 00:0c.0 (scsi0) Adaptec AIC-7896/7 Ultra2 SCSI host adapter found at PCI 0/12/0 (scsi0) Wide Channel A, SCSI ID=7, 32/255 SCBs (scsi0) Downloading sequencer code... 392 instructions downloaded (scsi1) Adaptec AIC-7896/7 Ultra2 SCSI host adapter found at PCI 0/12/1 (scsi1) Wide Channel B, SCSI ID=7, 32/255 SCBs (scsi1) Downloading sequencer code... 392 instructions downloaded scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0 Adaptec AIC-7896/7 Ultra2 SCSI host adapter scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0 Adaptec AIC-7896/7 Ultra2 SCSI host adapter scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0, lun 0 Inquiry 00 00 00 ff 00 SCSI host 0 abort (pid 0) timed out - resetting SCSI bus is being reset for host 0 channel 0. SCSI host 0 channel 0 reset (pid 0) timed out - trying harder SCSI bus is being reset for host 0 channel 0. SCSI host 0 abort (pid 0) timed out - resetting SCSI bus is being reset for host 0 channel 0. SCSI host 0 channel 0 reset (pid 0) timed out - trying harder SCSI bus is being reset for host 0 channel 0. SCSI host 0 abort (pid 0) timed out - resetting SCSI bus is being reset for host 0 channel 0. .. Since we are looking elsewhere now... I have tried PCI access mode BIOS and Direct with no improvement. There is an unrecognized PCI bridge resource in the boot messages... CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU serial number disabled. CPU: Intel Pentium III (Coppermine) stepping 06 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent Unknown bridge resource 1: assuming transparent Unknown bridge resource 2: assuming transparent Unknown bridge resource 0: assuming transparent Unknown bridge resource 1: assuming transparent Unknown bridge resource 2: assuming transparent PCI: Discovered primary peer bus ff [IRQ] PCI: Using IRQ router PIIX [8086/7110] at 00:12.0 # lspci 00:00.0 Host bridge: Intel Corporation 440GX - 82443GX Host bridge 00:01.0 PCI bridge: Intel Corporation 440GX - 82443GX AGP bridge 00:0c.0 SCSI storage controller: Adaptec 7896 00:0c.1 SCSI storage controller: Adaptec 7896 00:0e.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) 00:12.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) 00:12.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:12.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:12.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) 00:14.0 VGA compatible controller: Cirrus Logic GD 5480 (rev 23) 01:0f.0 PCI bridge: Digital Equipment Corporation DECchip 21150 (rev 06) I will go back and try 2.4.0 and 2.4.3-ac3 and see where that gets me. -- Jim Studt, President The Federated Software Group, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at
Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)
On Sat, 7 Apr 2001, Tim Waugh wrote: > On Sat, Apr 07, 2001 at 08:42:35PM +0200, Gunther Mayer wrote: > > > Please apply this little patch instead of wasting time by > > finger-pointing and arguing. > > This patch would make me happy. > > It would allow support for new multi-IO cards to generally be the > addition of about two lines to two files (which is currently how it's > done), rather than having separate mutant hybrid monstrosity drivers > for each card (IMHO).. It is possible to design a single function PCI device that is able to do everything. Your approach is just encouraging this kind of monstrosity. Such montrosity will look like some single-IRQ capable ISA remake, thus worse than 20 years old ISA. If we want to encourage that, then we want to stay stupid for life, in my nervous opinion. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Multi-function PCI devices
On Sat, 7 Apr 2001, Michael Reinelt wrote: > Tim Waugh wrote: > > > > On Sat, Apr 07, 2001 at 01:33:25PM +0200, Michael Reinelt wrote: > > > > > Adding PCI entries to both serial.c and parport_pc.c was that easy > > > > And that's how it should be, IMHO. There needs to be provision for > > more than one driver to be able to talk to any given PCI device. > > True, true, true. Could you start up your brain now :) and think about the actual issue. All the drivers must share the device resources and there is no (simple) way to do so generically. What you want to do is to write a single software driver, optionnaly broken into several modules, that is aware of all the functionnalities of the board and that will register to all involved sub-systems as needed. > But - how to deal with it? Who decides if we can deal this way or not? > PCI maintainer? Linus? > > bye, Michael > > P.S. I really need this. I have to unload serial and parallel and reload > them in different order when I want either print something or talk to my > Palm :-( What about the option of using a different hardware ? :-) Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Multi-function PCI devices
On Sat, 7 Apr 2001, Michael Reinelt wrote: > Brian Gerst wrote: > > > > Gérard Roudier wrote: > > > > > > On Sat, 7 Apr 2001, Michael Reinelt wrote: > > > > > > > The card shows up on the PCI bus as one device. For the card provides > > > > both serial and parallel ports, it will be driven by two subsystems, the > > > > serial and the parallel driver. > > > > > > Given your description, this board is certainly not a multi-fonction PCI > > > device. Multi-function PCI devices provide separate resources for each > > > function in a way that allows each function to be driven by separate > > > software drivers. A single function PCI device that provides several > > > functionnalities commonly handled by separate sub-systems, is nothing but > > > a bag of shit we should not want to support in any O/S in my opinion. > > > Let me claim that ingenieers that want O/Ses to support such hardware are > > > either morons or bastards. > > > > Unfortunately, Windoze supports this configuration, and that's enough > > for most hardware designers. This is also an issue with the joystick > > ports on many PCI sound cards. We're not in a position to get up on the > > soap box and decree this hardware "a bag of shit" though, yet. > > How about other Multi-I/O-Cards? I think these 2S/1P (or 2P/1S or 2P/2S) > cards are very common. At least they have been as ISA (PnP) cards. I Please donnot compare ISA and PCI. ISA wasted trillions of user hours because of its inability to allow automatic configuration. PCI fixed this by assigning configuration space to each device. These 'a la shitty ISA' Multi-I/O boards just kill the advantage of PCI by moving again ISA burden to PCI. In year 2001, they stink a lot. > don't know, but I'm shure there are a lot of these out there in the > field. As mainboards without any ISA slots get more common every day, > there will be even more PCI multi-I/O-cards (apart from everyone running > to USB :-) PCI multi I/O boards _shall_ provide a separate function for each kind of IO. Those that donnot are kind of PCI messy IO boards. > I needed another serial and parallel port, and I've got one of these > mainboards (Asus A7V). So I had to buy such a PCI card. Nowadays you > can't even ask for a specific hardware manufacturer, everything the guy > in the shop knows is "yes, it's PCI, and yes, it has two serial and one > parallel port". > > As these cards are very cheap, you can't expect very much from them (I Cheap for whom? What happens is that other companies or people that want to to support such hardware must do additionnal efforts that could have been avoided if the board had been correctly designed. > don't even think there are any expensive ones out there). NetMos does > not produce this cards, they produce _chips_ for such cards. So there > are probably a lot of cards out there with these NetMos chips. > > Again, how about other cards? Are there any PCI Multi-I/O-cards out > there, which are supported by linux? I'd be interested in how the driver > looks like I donnot know and will never know. I only use hardware that does not look too shitty to me. Time is too much important for me to waste even seconds with dubious hardware. :) Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Multi-function PCI devices
On Sat, 7 Apr 2001, Michael Reinelt wrote:
> Hi there,
>
> I've got a problem with my communication card: It's a PCI card with a
> NetMos chip, and it provides two serial and one parallel port. It's not
> officially supported by the linux kernel, so I wrote my own patch and
> sent it to the parallel, serial and pci maintainer. The patch itself is
> basically an extension of the pci id tables; and I hope it's in the
> queue for the official kernel.
>
> The patch worked great for me with kernel 2.4.1 and .2, but no longer
> with 2.4.3. The parallel port still works, but the serial port will not
> be detected. I had a quite long debugging session last night (adding
> printk's to the pci code takes some time, for you have to reboot to load
> the new kernel), and I think I found the reason:
>
> The card shows up on the PCI bus as one device. For the card provides
> both serial and parallel ports, it will be driven by two subsystems, the
> serial and the parallel driver.
Given your description, this board is certainly not a multi-fonction PCI
device. Multi-function PCI devices provide separate resources for each
function in a way that allows each function to be driven by separate
software drivers. A single function PCI device that provides several
functionnalities commonly handled by separate sub-systems, is nothing but
a bag of shit we should not want to support in any O/S in my opinion.
Let me claim that ingenieers that want O/Ses to support such hardware are
either morons or bastards.
> I found that _either_ the parallel or the serial port works, depending
> on which module you load first. The reason for this seems to be in
> pci.c, especially in the pci_register_driver() function. It reads:
>
> int pci_register_driver(struct pci_driver *drv)
> {
> struct pci_dev *dev;
> int count = 0;
>
> list_add_tail(>node, _drivers);
> pci_for_each_dev(dev) {
> if (!pci_dev_driver(dev))
> count += pci_announce_device(drv, dev);
> }
> return count;
> }
>
>
> pci_announce_device() will be called only if there's no other driver
> claiming the device. This explains why either the parallel or the serial
> port will be detected: The first driver loaded will see the device, the
> next drivers won't.
>
> I'm afraid this is not a bug, but a design issue, and will be hard to
> solve. Maybe we need a flag for such devices which allows it to be
> claimed ba more thean one driver?
>
> In the meantime, what can I do to get both ports working?
Since the hardware does not allows the software to transparently share the
different functionnalities provided by the silicium, you must handle such
sharing by software. I mean, you must, at least, write a module (or
sub-driver or sub-system) that will handle the sharing of the PCI
function. Band-aiding the kernel code in order to cope with such
brain-deaded hardware would be a pity, in my opinion. Burden must stay
where it is deserved. If they want their 'save 0.01$ but push shit ahead'
hardware to be supported, they should write their drivers themselves, in
my opinion.
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Multi-function PCI devices
On Sat, 7 Apr 2001, Michael Reinelt wrote: Brian Gerst wrote: Grard Roudier wrote: On Sat, 7 Apr 2001, Michael Reinelt wrote: The card shows up on the PCI bus as one device. For the card provides both serial and parallel ports, it will be driven by two subsystems, the serial and the parallel driver. Given your description, this board is certainly not a multi-fonction PCI device. Multi-function PCI devices provide separate resources for each function in a way that allows each function to be driven by separate software drivers. A single function PCI device that provides several functionnalities commonly handled by separate sub-systems, is nothing but a bag of shit we should not want to support in any O/S in my opinion. Let me claim that ingenieers that want O/Ses to support such hardware are either morons or bastards. Unfortunately, Windoze supports this configuration, and that's enough for most hardware designers. This is also an issue with the joystick ports on many PCI sound cards. We're not in a position to get up on the soap box and decree this hardware "a bag of shit" though, yet. How about other Multi-I/O-Cards? I think these 2S/1P (or 2P/1S or 2P/2S) cards are very common. At least they have been as ISA (PnP) cards. I Please donnot compare ISA and PCI. ISA wasted trillions of user hours because of its inability to allow automatic configuration. PCI fixed this by assigning configuration space to each device. These 'a la shitty ISA' Multi-I/O boards just kill the advantage of PCI by moving again ISA burden to PCI. In year 2001, they stink a lot. don't know, but I'm shure there are a lot of these out there in the field. As mainboards without any ISA slots get more common every day, there will be even more PCI multi-I/O-cards (apart from everyone running to USB :-) PCI multi I/O boards _shall_ provide a separate function for each kind of IO. Those that donnot are kind of PCI messy IO boards. I needed another serial and parallel port, and I've got one of these mainboards (Asus A7V). So I had to buy such a PCI card. Nowadays you can't even ask for a specific hardware manufacturer, everything the guy in the shop knows is "yes, it's PCI, and yes, it has two serial and one parallel port". As these cards are very cheap, you can't expect very much from them (I Cheap for whom? What happens is that other companies or people that want to to support such hardware must do additionnal efforts that could have been avoided if the board had been correctly designed. don't even think there are any expensive ones out there). NetMos does not produce this cards, they produce _chips_ for such cards. So there are probably a lot of cards out there with these NetMos chips. Again, how about other cards? Are there any PCI Multi-I/O-cards out there, which are supported by linux? I'd be interested in how the driver looks like I donnot know and will never know. I only use hardware that does not look too shitty to me. Time is too much important for me to waste even seconds with dubious hardware. :) Grard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Multi-function PCI devices
On Sat, 7 Apr 2001, Michael Reinelt wrote: Tim Waugh wrote: On Sat, Apr 07, 2001 at 01:33:25PM +0200, Michael Reinelt wrote: Adding PCI entries to both serial.c and parport_pc.c was that easy And that's how it should be, IMHO. There needs to be provision for more than one driver to be able to talk to any given PCI device. True, true, true. Could you start up your brain now :) and think about the actual issue. All the drivers must share the device resources and there is no (simple) way to do so generically. What you want to do is to write a single software driver, optionnaly broken into several modules, that is aware of all the functionnalities of the board and that will register to all involved sub-systems as needed. But - how to deal with it? Who decides if we can deal this way or not? PCI maintainer? Linus? bye, Michael P.S. I really need this. I have to unload serial and parallel and reload them in different order when I want either print something or talk to my Palm :-( What about the option of using a different hardware ? :-) Grard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)
On Sat, 7 Apr 2001, Tim Waugh wrote: On Sat, Apr 07, 2001 at 08:42:35PM +0200, Gunther Mayer wrote: Please apply this little patch instead of wasting time by finger-pointing and arguing. This patch would make me happy. It would allow support for new multi-IO cards to generally be the addition of about two lines to two files (which is currently how it's done), rather than having separate mutant hybrid monstrosity drivers for each card (IMHO).. It is possible to design a single function PCI device that is able to do everything. Your approach is just encouraging this kind of monstrosity. Such montrosity will look like some single-IRQ capable ISA remake, thus worse than 20 years old ISA. If we want to encourage that, then we want to stay stupid for life, in my nervous opinion. Grard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: st corruption with 2.4.3-pre4
On Fri, 6 Apr 2001, Gérard Roudier wrote: > Here is a patch that removes the offending PPC PCI hacky area from the > driver (sym53c8xx_defs.h): > > --- sym53c8xx_defs.h Fri Apr 6 16:23:48 2001 > +++ sym53c8xx_defs.h.orig Sun Mar 4 13:54:11 2001 > @@ -175,6 +175,9 @@ > #define SCSI_NCR_IOMAPPED > #elif defined(__alpha__) > #define SCSI_NCR_IOMAPPED > +#elif defined(__powerpc__) > +#define SCSI_NCR_IOMAPPED > +#define SCSI_NCR_PCI_MEM_NOT_SUPPORTED > #elif defined(__sparc__) > #undef SCSI_NCR_IOMAPPED > #endif > Cut Here -- The patch is obviously reversed. You just have to remove the 3 lines that apply to powerpc using you preferred editor. Btw, using the one you dislike the most will also fit. :-) Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: st corruption with 2.4.3-pre4
On Thu, 5 Apr 2001, Geert Uytterhoeven wrote:
>
> BTW, my 2.4.3-pre8 kernel just said
>
> | sym53c875-0:0: ERROR (81:0) (3-21-0) (10/9d) @ (script 8a8:0b00).
Illegal instruction detected.
> | sym53c875-0: script cmd = 1100
> | sym53c875-0: regdump: da 10 80 9d 47 10 00 0d 00 03 80 21 80 01 09 09 00 30 4e 00
>08 ff ff ff.
> | sym53c875-0-<0,*>: FAST-20 WIDE SCSI 40.0 MB/s (50.0 ns, offset 16)
>
> during the boot process, and continued without problems. What does this mean?
Looks extremally serious to me.
The SCRIPTS processor should be fetching CHMOV DSA relative when DATA_IN
instructions. This corresponds to opcode 0x1100.
However, it seems to have fetched instruction 0x0b00 which is a
MOVE ABSOLUTE WHEN STATUS PHASE.
In (3-21-0) we can see that the chip is expecting STATUS PHASE (3), but
the target is driving DATA IN phase (21 - the 1 indicates DATA IN phase).
In other word, the SCRIPTS processor seems to have fetched a bogus
instruction. The signaled 'illegal instruction detected' may be due to the
count of bytes to transfer to be zero.
> Gr{oetje,eeting}s,
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: st corruption with 2.4.3-pre4
On Fri, 6 Apr 2001, Stefano Coluccini wrote: > > I'm still waiting for other reports of st/sym53c8xx on PPC under > > 2.4.x. BTW, > > does it work on other big-endian platforms, like sparc? > > I don't know if it is the same problem, but ... > I have a Motorola MVME5100 (PowerPC 750 based CPU) with a mezzanine PCI > based on the sym53c875 chip. I'm using the 2_5 kernel from fmslabs and the > first time I have downloaded the kernel all works fine, while in a > successive update the sym53c8xx driver was changed and my board don't work > anymore. The driver hangs on downloading the SCSI scripts. > I'm not a SCSI driver expert, so I've solved the problem installing the old > version of the driver. > Tom Rini says to me that it happened when he have merged some updates from > the 2_4 tree, so I think my problem is related to the latest updates to the > driver. > I hope this helps you. > Bye. > Stefano. IMO, it might well be the Linux/PPC PCI interface that doesn't return expected values. 1) The [sym|ncr]53c8xx need to know about BAR addresses as physical address values as seen from the BUS. These values are used by the SCSI SCRIPTS and _NOT_ by the CPU. 2) The pcidev structure returns cookies instead, that commonly are BARs physical addresses as seen from CPU. The recent change in the Symbios driver about point (1) is that the driver now reads the BARs using the pci_read_config*() interface. If these functions donnot return the actual BAR values usable from the BUS for some obscure reasons, this may explain your problem. The cookies contained in the pcidev structure are completely useless for the driver and probably for any driver. They just have to be used to remap memory BARs to CPU virtual addresses. Then the driver forgets about them. There are still some PPC PCI specific hacks in the sym53c8xx driver and it has been reported to me that they can be removed. If the PPC PCI interface is correct, then they should be removed without problems, IMO. Here is a patch that removes the offending PPC PCI hacky area from the driver (sym53c8xx_defs.h): --- sym53c8xx_defs.hFri Apr 6 16:23:48 2001 +++ sym53c8xx_defs.h.orig Sun Mar 4 13:54:11 2001 @@ -175,6 +175,9 @@ #defineSCSI_NCR_IOMAPPED #elif defined(__alpha__) #defineSCSI_NCR_IOMAPPED +#elif defined(__powerpc__) +#defineSCSI_NCR_IOMAPPED +#define SCSI_NCR_PCI_MEM_NOT_SUPPORTED #elif defined(__sparc__) #undef SCSI_NCR_IOMAPPED #endif Cut Here -- Regards, Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: st corruption with 2.4.3-pre4
On Fri, 6 Apr 2001, Stefano Coluccini wrote: I'm still waiting for other reports of st/sym53c8xx on PPC under 2.4.x. BTW, does it work on other big-endian platforms, like sparc? I don't know if it is the same problem, but ... I have a Motorola MVME5100 (PowerPC 750 based CPU) with a mezzanine PCI based on the sym53c875 chip. I'm using the 2_5 kernel from fmslabs and the first time I have downloaded the kernel all works fine, while in a successive update the sym53c8xx driver was changed and my board don't work anymore. The driver hangs on downloading the SCSI scripts. I'm not a SCSI driver expert, so I've solved the problem installing the old version of the driver. Tom Rini says to me that it happened when he have merged some updates from the 2_4 tree, so I think my problem is related to the latest updates to the driver. I hope this helps you. Bye. Stefano. IMO, it might well be the Linux/PPC PCI interface that doesn't return expected values. 1) The [sym|ncr]53c8xx need to know about BAR addresses as physical address values as seen from the BUS. These values are used by the SCSI SCRIPTS and _NOT_ by the CPU. 2) The pcidev structure returns cookies instead, that commonly are BARs physical addresses as seen from CPU. The recent change in the Symbios driver about point (1) is that the driver now reads the BARs using the pci_read_config*() interface. If these functions donnot return the actual BAR values usable from the BUS for some obscure reasons, this may explain your problem. The cookies contained in the pcidev structure are completely useless for the driver and probably for any driver. They just have to be used to remap memory BARs to CPU virtual addresses. Then the driver forgets about them. There are still some PPC PCI specific hacks in the sym53c8xx driver and it has been reported to me that they can be removed. If the PPC PCI interface is correct, then they should be removed without problems, IMO. Here is a patch that removes the offending PPC PCI hacky area from the driver (sym53c8xx_defs.h): --- sym53c8xx_defs.hFri Apr 6 16:23:48 2001 +++ sym53c8xx_defs.h.orig Sun Mar 4 13:54:11 2001 @@ -175,6 +175,9 @@ #defineSCSI_NCR_IOMAPPED #elif defined(__alpha__) #defineSCSI_NCR_IOMAPPED +#elif defined(__powerpc__) +#defineSCSI_NCR_IOMAPPED +#define SCSI_NCR_PCI_MEM_NOT_SUPPORTED #elif defined(__sparc__) #undef SCSI_NCR_IOMAPPED #endif Cut Here -- Regards, Grard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: st corruption with 2.4.3-pre4
On Thu, 5 Apr 2001, Geert Uytterhoeven wrote:
BTW, my 2.4.3-pre8 kernel just said
| sym53c875-0:0: ERROR (81:0) (3-21-0) (10/9d) @ (script 8a8:0b00).
Illegal instruction detected.
| sym53c875-0: script cmd = 1100
| sym53c875-0: regdump: da 10 80 9d 47 10 00 0d 00 03 80 21 80 01 09 09 00 30 4e 00
08 ff ff ff.
| sym53c875-0-0,*: FAST-20 WIDE SCSI 40.0 MB/s (50.0 ns, offset 16)
during the boot process, and continued without problems. What does this mean?
Looks extremally serious to me.
The SCRIPTS processor should be fetching CHMOV DSA relative when DATA_IN
instructions. This corresponds to opcode 0x1100.
However, it seems to have fetched instruction 0x0b00 which is a
MOVE ABSOLUTE WHEN STATUS PHASE.
In (3-21-0) we can see that the chip is expecting STATUS PHASE (3), but
the target is driving DATA IN phase (21 - the 1 indicates DATA IN phase).
In other word, the SCRIPTS processor seems to have fetched a bogus
instruction. The signaled 'illegal instruction detected' may be due to the
count of bytes to transfer to be zero.
Gr{oetje,eeting}s,
Grard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: st corruption with 2.4.3-pre4
On Fri, 6 Apr 2001, Grard Roudier wrote: Here is a patch that removes the offending PPC PCI hacky area from the driver (sym53c8xx_defs.h): --- sym53c8xx_defs.h Fri Apr 6 16:23:48 2001 +++ sym53c8xx_defs.h.orig Sun Mar 4 13:54:11 2001 @@ -175,6 +175,9 @@ #define SCSI_NCR_IOMAPPED #elif defined(__alpha__) #define SCSI_NCR_IOMAPPED +#elif defined(__powerpc__) +#define SCSI_NCR_IOMAPPED +#define SCSI_NCR_PCI_MEM_NOT_SUPPORTED #elif defined(__sparc__) #undef SCSI_NCR_IOMAPPED #endif Cut Here -- The patch is obviously reversed. You just have to remove the 3 lines that apply to powerpc using you preferred editor. Btw, using the one you dislike the most will also fit. :-) Grard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Assumption in sym53c8xx.c failed
Hello,
The patch I sent you yesterday has a typo that can lead to serious
breakage. This has been pointed out by Michal Jaegermann. Thanks, Michal.
(k must be compared against -1 and not against 1)
You want to apply this new tiny patch instead and let me know if it fixes:
--- sym53c8xx.c.0402Mon Apr 2 15:58:32 2001
+++ sym53c8xx.c Tue Apr 3 07:15:00 2001
@@ -10167,14 +10167,13 @@
if (i >= MAX_START*2)
i = 0;
}
- assert(k != -1);
- if (k != 1) {
+ if (k != -1) {
np->squeue[k] = np->squeue[i]; /* Idle task */
np->squeueput = k; /* Start queue pointer */
- cp->host_status = HS_ABORTED;
- cp->scsi_status = S_ILLEGAL;
- ncr_complete(np, cp);
}
+ cp->host_status = HS_ABORTED;
+ cp->scsi_status = S_ILLEGAL;
+ ncr_complete(np, cp);
}
break;
/*
- Cut Here -
Gérard.
On Mon, 2 Apr 2001, Gérard Roudier wrote:
>
>
> On Sat, 31 Mar 2001, Christian Kurz wrote:
>
> > Hi,
> >
> > I'm currently running 2.4.2-ac28 and today I got a failing assumption in
> > sym53c8xx.c. I'm not sure about the exact steps that I did to produce
> > this error, but it must have been something like: cdparanoia -blank=all,
> > then sending Ctrl+C to this process and after it's been killed
> > cdparanoia -blank=fast. I then got assertion: k!=-1 failed. But I found
> > no hint about this in the messages or syslog file. So I looked through
> > sym53c8xx.c to find this code and it seems like line 10123 is
> > responsible for creating this error and kernel panic. Should this be the
> > normal behaviour or is this a bug in the code?
>
> This might well be both at the same time. I mean normal behaviour given a
> bug in the code. :-)
>
> Could you try this tiny patch and let me know:
>
> --- sym53c8xx.c.0402 Mon Apr 2 15:58:32 2001
> +++ sym53c8xx.c Mon Apr 2 16:02:43 2001
> @@ -10167,14 +10167,13 @@
> if (i >= MAX_START*2)
> i = 0;
> }
> - assert(k != -1);
> if (k != 1) {
> np->squeue[k] = np->squeue[i]; /* Idle task */
> np->squeueput = k; /* Start queue pointer */
> - cp->host_status = HS_ABORTED;
> - cp->scsi_status = S_ILLEGAL;
> - ncr_complete(np, cp);
> }
> + cp->host_status = HS_ABORTED;
> + cp->scsi_status = S_ILLEGAL;
> + ncr_complete(np, cp);
> }
> break;
> /*
>
> What happens is that this part of the driver code assumed that the CCB for
> an IO to abort is queued to the SCSI SCRIPTS. This is not always true
> since the driver may temporarily not queue all IOs to SCRIPTS. This may
> happens on QUEUE FULL condition or for devices that donnot accept tagged
> commands, for example.
>
> Regards,
> Gérard.
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Assumption in sym53c8xx.c failed
Hello,
The patch I sent you yesterday has a typo that can lead to serious
breakage. This has been pointed out by Michal Jaegermann. Thanks, Michal.
(k must be compared against -1 and not against 1)
You want to apply this new tiny patch instead and let me know if it fixes:
--- sym53c8xx.c.0402Mon Apr 2 15:58:32 2001
+++ sym53c8xx.c Tue Apr 3 07:15:00 2001
@@ -10167,14 +10167,13 @@
if (i = MAX_START*2)
i = 0;
}
- assert(k != -1);
- if (k != 1) {
+ if (k != -1) {
np-squeue[k] = np-squeue[i]; /* Idle task */
np-squeueput = k; /* Start queue pointer */
- cp-host_status = HS_ABORTED;
- cp-scsi_status = S_ILLEGAL;
- ncr_complete(np, cp);
}
+ cp-host_status = HS_ABORTED;
+ cp-scsi_status = S_ILLEGAL;
+ ncr_complete(np, cp);
}
break;
/*
- Cut Here -
Grard.
On Mon, 2 Apr 2001, Grard Roudier wrote:
On Sat, 31 Mar 2001, Christian Kurz wrote:
Hi,
I'm currently running 2.4.2-ac28 and today I got a failing assumption in
sym53c8xx.c. I'm not sure about the exact steps that I did to produce
this error, but it must have been something like: cdparanoia -blank=all,
then sending Ctrl+C to this process and after it's been killed
cdparanoia -blank=fast. I then got assertion: k!=-1 failed. But I found
no hint about this in the messages or syslog file. So I looked through
sym53c8xx.c to find this code and it seems like line 10123 is
responsible for creating this error and kernel panic. Should this be the
normal behaviour or is this a bug in the code?
This might well be both at the same time. I mean normal behaviour given a
bug in the code. :-)
Could you try this tiny patch and let me know:
--- sym53c8xx.c.0402 Mon Apr 2 15:58:32 2001
+++ sym53c8xx.c Mon Apr 2 16:02:43 2001
@@ -10167,14 +10167,13 @@
if (i = MAX_START*2)
i = 0;
}
- assert(k != -1);
if (k != 1) {
np-squeue[k] = np-squeue[i]; /* Idle task */
np-squeueput = k; /* Start queue pointer */
- cp-host_status = HS_ABORTED;
- cp-scsi_status = S_ILLEGAL;
- ncr_complete(np, cp);
}
+ cp-host_status = HS_ABORTED;
+ cp-scsi_status = S_ILLEGAL;
+ ncr_complete(np, cp);
}
break;
/*
What happens is that this part of the driver code assumed that the CCB for
an IO to abort is queued to the SCSI SCRIPTS. This is not always true
since the driver may temporarily not queue all IOs to SCRIPTS. This may
happens on QUEUE FULL condition or for devices that donnot accept tagged
commands, for example.
Regards,
Grard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Assumption in sym53c8xx.c failed
On Sat, 31 Mar 2001, Christian Kurz wrote:
> Hi,
>
> I'm currently running 2.4.2-ac28 and today I got a failing assumption in
> sym53c8xx.c. I'm not sure about the exact steps that I did to produce
> this error, but it must have been something like: cdparanoia -blank=all,
> then sending Ctrl+C to this process and after it's been killed
> cdparanoia -blank=fast. I then got assertion: k!=-1 failed. But I found
> no hint about this in the messages or syslog file. So I looked through
> sym53c8xx.c to find this code and it seems like line 10123 is
> responsible for creating this error and kernel panic. Should this be the
> normal behaviour or is this a bug in the code?
This might well be both at the same time. I mean normal behaviour given a
bug in the code. :-)
Could you try this tiny patch and let me know:
--- sym53c8xx.c.0402Mon Apr 2 15:58:32 2001
+++ sym53c8xx.c Mon Apr 2 16:02:43 2001
@@ -10167,14 +10167,13 @@
if (i >= MAX_START*2)
i = 0;
}
- assert(k != -1);
if (k != 1) {
np->squeue[k] = np->squeue[i]; /* Idle task */
np->squeueput = k; /* Start queue pointer */
- cp->host_status = HS_ABORTED;
- cp->scsi_status = S_ILLEGAL;
- ncr_complete(np, cp);
}
+ cp->host_status = HS_ABORTED;
+ cp->scsi_status = S_ILLEGAL;
+ ncr_complete(np, cp);
}
break;
/*
What happens is that this part of the driver code assumed that the CCB for
an IO to abort is queued to the SCSI SCRIPTS. This is not always true
since the driver may temporarily not queue all IOs to SCRIPTS. This may
happens on QUEUE FULL condition or for devices that donnot accept tagged
commands, for example.
Regards,
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Assumption in sym53c8xx.c failed
On Sat, 31 Mar 2001, Christian Kurz wrote:
Hi,
I'm currently running 2.4.2-ac28 and today I got a failing assumption in
sym53c8xx.c. I'm not sure about the exact steps that I did to produce
this error, but it must have been something like: cdparanoia -blank=all,
then sending Ctrl+C to this process and after it's been killed
cdparanoia -blank=fast. I then got assertion: k!=-1 failed. But I found
no hint about this in the messages or syslog file. So I looked through
sym53c8xx.c to find this code and it seems like line 10123 is
responsible for creating this error and kernel panic. Should this be the
normal behaviour or is this a bug in the code?
This might well be both at the same time. I mean normal behaviour given a
bug in the code. :-)
Could you try this tiny patch and let me know:
--- sym53c8xx.c.0402Mon Apr 2 15:58:32 2001
+++ sym53c8xx.c Mon Apr 2 16:02:43 2001
@@ -10167,14 +10167,13 @@
if (i = MAX_START*2)
i = 0;
}
- assert(k != -1);
if (k != 1) {
np-squeue[k] = np-squeue[i]; /* Idle task */
np-squeueput = k; /* Start queue pointer */
- cp-host_status = HS_ABORTED;
- cp-scsi_status = S_ILLEGAL;
- ncr_complete(np, cp);
}
+ cp-host_status = HS_ABORTED;
+ cp-scsi_status = S_ILLEGAL;
+ ncr_complete(np, cp);
}
break;
/*
What happens is that this part of the driver code assumed that the CCB for
an IO to abort is queued to the SCSI SCRIPTS. This is not always true
since the driver may temporarily not queue all IOs to SCRIPTS. This may
happens on QUEUE FULL condition or for devices that donnot accept tagged
commands, for example.
Regards,
Grard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: WG: 2.4 on COMPQ Proliant
On Thu, 29 Mar 2001, Butter, Frank wrote: > 2.2.16 claimes to find a ncr53c1510D-chipset, supported by > the driver ncr53c8xx. Which kernel-param would be the correct one for this? There is no specific kernel option apart configuring the NCR53C8XX and/or the SYM53C8XX driver. (And not the 53c7,8xx driver as I have to repeat since 5 years). For the 53c1510D, you must ensure that the chip is configured for behaving as a 53c8xx chip (and not as an intelligent controller). To know about the 1510 configuration, you may check the PCI device id claimed by the chip. Value 0xa is the expected value if the chip is configured for 53c8xx mode. Btw, I donnot know how to change the 1510 from intelligent mode to 53c8xx mode and vice-versa. You may ask your vendor for that. Gérard. > Frank > > > -Ursprüngliche Nachricht- > > Von: Butter, Frank > > Gesendet: Donnerstag, 29. März 2001 17:11 > > An: '[EMAIL PROTECTED]' > > Betreff: 2.4 on COMPQ Proliant > > > > > > > > Has anyone experiences with 2.4.x on recent Compaq Proliant > > Servers (e.g. ML570)? > > > > I've installed RedHat7 and it worked fine out of the box. > > Except that the SMP-enabled kernel stated there was no > > SMP-board detected ;-/ > > For some reasons (Fibrechannel drivers and so on) I've compiled > > 2.4.2 and installed it. Although I've compiled the support > > in, the NCR-SCSI-chip was not found and therefore no > > root-partition. It is a model supported by 53c8xx - detected > > by the original RedHat-kernel. > > > > For testing I compiled a kernel with all (!) scsi-low-level-drivers - > > with the same result. The SMP-board also was NOT detected by 2.4.2. > > > > Any hint? > > > > Frank > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WG: 2.4 on COMPQ Proliant
On Thu, 29 Mar 2001, Butter, Frank wrote: 2.2.16 claimes to find a ncr53c1510D-chipset, supported by the driver ncr53c8xx. Which kernel-param would be the correct one for this? There is no specific kernel option apart configuring the NCR53C8XX and/or the SYM53C8XX driver. (And not the 53c7,8xx driver as I have to repeat since 5 years). For the 53c1510D, you must ensure that the chip is configured for behaving as a 53c8xx chip (and not as an intelligent controller). To know about the 1510 configuration, you may check the PCI device id claimed by the chip. Value 0xa is the expected value if the chip is configured for 53c8xx mode. Btw, I donnot know how to change the 1510 from intelligent mode to 53c8xx mode and vice-versa. You may ask your vendor for that. Grard. Frank -Ursprngliche Nachricht- Von: Butter, Frank Gesendet: Donnerstag, 29. Mrz 2001 17:11 An: '[EMAIL PROTECTED]' Betreff: 2.4 on COMPQ Proliant Has anyone experiences with 2.4.x on recent Compaq Proliant Servers (e.g. ML570)? I've installed RedHat7 and it worked fine out of the box. Except that the SMP-enabled kernel stated there was no SMP-board detected ;-/ For some reasons (Fibrechannel drivers and so on) I've compiled 2.4.2 and installed it. Although I've compiled the support in, the NCR-SCSI-chip was not found and therefore no root-partition. It is a model supported by 53c8xx - detected by the original RedHat-kernel. For testing I compiled a kernel with all (!) scsi-low-level-drivers - with the same result. The SMP-board also was NOT detected by 2.4.2. Any hint? Frank - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NCR53c8xx driver and multiple controllers...(not new prob)
On Sun, 25 Mar 2001, LA Walsh wrote:
> Here is the 'alternate' output when the ncr53c8xx driver is
> compiled in:
>
> SCSI subsystem driver Revision: 1.00
> scsi-ncr53c7,8xx : at PCI bus 0, device 8, function 0
> scsi-ncr53c7,8xx : warning : revision of 35 is greater than 2.
> scsi-ncr53c7,8xx : NCR53c810 at memory 0xfa101000, io 0x2000, irq 58
> scsi0 : burst length 16
> scsi0 : NCR code relocated to 0x37d6c610 (virt 0xf7d6c610)
> scsi0 : test 1 started
> scsi0 : NCR53c{7,8}xx (rel 17)
> request_module[block-major-8]: Root fs not mounted
> VFS: Cannot open root device "807" or 08:07
> Please append a correct "root=" boot option
> Kernel panic: VFS: Unable to mount root fs on 08:07
> -
The 53c7,8xx driver is a different driver that hasn't been updated for the
support of the 53C896. I figure out that you already have been replied
upon this point.
For your machine configuration you want to use either the NCR53C8XX driver
or the SYM53C8XX driver. The SYM53C8XX driver has a better support for the
896 as it handles phase mismatch from SCRIPTS. The both drivers share the
same kernel config options for simplicity (in fact the SYM53C8XX driver
just steals the NCR53C8XX config options).
Go to the SCSI low-level configuration form under make menuconfig for
example and configure the SYM53C8XX driver as 'Y' and the NCR53C8XX driver
as 'N'. Btw, also configure 'N' the 53c7,8xx driver to avoid conflicts.
You may also have a look at the help entries for these drivers and at the
file linux/drivers/scsi/README.ncr53c8xx (also applies to SYM53C8XX).
A driver named SYM-2 that replaces both the NCR53C8XX and the SYM53C8XX
drivers also exists. This driver is multi-platform and for now has been
added support for Linux, FreeBSD and NetBSD. It is intended to replace the
NCR53C8XX and the SYM53C8XX. It is not included in Linux for now since we
only have _stable_ kernels at the moment and the NCR+SYM driver pair is
the current _stable_ support for SYMBIOS 53C8XX controllers.
If you want to try SYM-2: ftp://ftp.tux.org/roudier/README-drivers-linux
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: NCR53c8xx driver and multiple controllers...(not new prob)
On Sun, 25 Mar 2001, LA Walsh wrote:
Here is the 'alternate' output when the ncr53c8xx driver is
compiled in:
SCSI subsystem driver Revision: 1.00
scsi-ncr53c7,8xx : at PCI bus 0, device 8, function 0
scsi-ncr53c7,8xx : warning : revision of 35 is greater than 2.
scsi-ncr53c7,8xx : NCR53c810 at memory 0xfa101000, io 0x2000, irq 58
scsi0 : burst length 16
scsi0 : NCR code relocated to 0x37d6c610 (virt 0xf7d6c610)
scsi0 : test 1 started
scsi0 : NCR53c{7,8}xx (rel 17)
request_module[block-major-8]: Root fs not mounted
VFS: Cannot open root device "807" or 08:07
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 08:07
-
The 53c7,8xx driver is a different driver that hasn't been updated for the
support of the 53C896. I figure out that you already have been replied
upon this point.
For your machine configuration you want to use either the NCR53C8XX driver
or the SYM53C8XX driver. The SYM53C8XX driver has a better support for the
896 as it handles phase mismatch from SCRIPTS. The both drivers share the
same kernel config options for simplicity (in fact the SYM53C8XX driver
just steals the NCR53C8XX config options).
Go to the SCSI low-level configuration form under make menuconfig for
example and configure the SYM53C8XX driver as 'Y' and the NCR53C8XX driver
as 'N'. Btw, also configure 'N' the 53c7,8xx driver to avoid conflicts.
You may also have a look at the help entries for these drivers and at the
file linux/drivers/scsi/README.ncr53c8xx (also applies to SYM53C8XX).
A driver named SYM-2 that replaces both the NCR53C8XX and the SYM53C8XX
drivers also exists. This driver is multi-platform and for now has been
added support for Linux, FreeBSD and NetBSD. It is intended to replace the
NCR53C8XX and the SYM53C8XX. It is not included in Linux for now since we
only have _stable_ kernels at the moment and the NCR+SYM driver pair is
the current _stable_ support for SYMBIOS 53C8XX controllers.
If you want to try SYM-2: ftp://ftp.tux.org/roudier/README-drivers-linux
Grard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: NCR53c8xx driver and multiple controllers...(not new prob)
Hello, You sent me by private e-mail, the /proc/pci information of your system. I donnot see anything wrong in these data. If the problem is PCI-related, you would probably have better help by sending these infos to the l-k list, in my opinion. To be honest (I may be wrong here - sorry if I am), I am under the impression that you may well be barking up the wrong tree. Just quoted here an exerpt of your mail that let me think so: > > When I compile it in, it only see the 1st controller > > and the boot partition I think is on the 3rd. ^ Knowing instead is required, here, IMO. 1) controllers attach SCSI devices, notably hard disks 2) hard disks contain partitions 3) partitions contain file systems. 4) the kernel needs to *know* the root file system to boot your system. What about point 4 ? i.e : how did you tell to the boot loader the root partition name to pass to the kernel at boot ? If you are using lilo and have configured it for user to be prompted before running the kernel, you may try to enter your root partition name when you are prompted by lilo. For example if root fs is on /dev/sda5: lilo: your_lilo_config_entry_name root=/dev/sda5 ro Just replace the lilo_config_entry_name and the root partition name by the values that match your configuration. Gérard. On Sat, 24 Mar 2001, Gérard Roudier wrote: > On Sat, 24 Mar 2001, LA Walsh wrote: > > > I have a machine with 3 of these controllers (a 4 CPU server). The > > 3 controllers are: > > ncr53c810a-0: rev=0x23, base=0xfa101000, io_port=0x2000, irq=58 > > ncr53c810a-0: ID 7, Fast-10, Parity Checking > > ncr53c896-1: rev=0x01, base=0xfe004000, io_port=0x3000, irq=57 > > ncr53c896-1: ID 7, Fast-40, Parity Checking > > ncr53c896-2: rev=0x01, base=0xfe004400, io_port=0x3400, irq=56 > > ncr53c896-2: ID 7, Fast-40, Parity Checking > > ncr53c896-2: on-chip RAM at 0xfe002000 > > > > I'd like to be able to make a kernel with the driver compiled in and > > no loadable module support. It don't see how to do this from the > > documentation -- it seems to require a separate module loaded for > > each controller. When I compile it in, it only see the 1st controller > > and the boot partition I think is on the 3rd. Any ideas? > > The driver tries to detect all controllers it supports. Since the > ncr53c8xx supports both the 810a and the 896, all your controllers should > have been detected. When loaded as a module, the driver must be loaded > once (btw, a seconf load should fail). > > > This problem is present in the 2.2.x series as well as 2.4.x (x up to 2). > > What hardware are you using (CPU, Core Logic and tutti quanti) ? > Is the 896 on PCI BUS #0 or on some sort of secondary PCI BUS ? > Does the sym53c8xx driver show same behaviour ? > > Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NCR53c8xx driver and multiple controllers...(not new prob)
Hello, You sent me by private e-mail, the /proc/pci information of your system. I donnot see anything wrong in these data. If the problem is PCI-related, you would probably have better help by sending these infos to the l-k list, in my opinion. To be honest (I may be wrong here - sorry if I am), I am under the impression that you may well be barking up the wrong tree. Just quoted here an exerpt of your mail that let me think so: When I compile it in, it only see the 1st controller and the boot partition I think is on the 3rd. ^ Knowing instead is required, here, IMO. 1) controllers attach SCSI devices, notably hard disks 2) hard disks contain partitions 3) partitions contain file systems. 4) the kernel needs to *know* the root file system to boot your system. What about point 4 ? i.e : how did you tell to the boot loader the root partition name to pass to the kernel at boot ? If you are using lilo and have configured it for user to be prompted before running the kernel, you may try to enter your root partition name when you are prompted by lilo. For example if root fs is on /dev/sda5: lilo: your_lilo_config_entry_name root=/dev/sda5 ro Just replace the lilo_config_entry_name and the root partition name by the values that match your configuration. Grard. On Sat, 24 Mar 2001, Grard Roudier wrote: On Sat, 24 Mar 2001, LA Walsh wrote: I have a machine with 3 of these controllers (a 4 CPU server). The 3 controllers are: ncr53c810a-0: rev=0x23, base=0xfa101000, io_port=0x2000, irq=58 ncr53c810a-0: ID 7, Fast-10, Parity Checking ncr53c896-1: rev=0x01, base=0xfe004000, io_port=0x3000, irq=57 ncr53c896-1: ID 7, Fast-40, Parity Checking ncr53c896-2: rev=0x01, base=0xfe004400, io_port=0x3400, irq=56 ncr53c896-2: ID 7, Fast-40, Parity Checking ncr53c896-2: on-chip RAM at 0xfe002000 I'd like to be able to make a kernel with the driver compiled in and no loadable module support. It don't see how to do this from the documentation -- it seems to require a separate module loaded for each controller. When I compile it in, it only see the 1st controller and the boot partition I think is on the 3rd. Any ideas? The driver tries to detect all controllers it supports. Since the ncr53c8xx supports both the 810a and the 896, all your controllers should have been detected. When loaded as a module, the driver must be loaded once (btw, a seconf load should fail). This problem is present in the 2.2.x series as well as 2.4.x (x up to 2). What hardware are you using (CPU, Core Logic and tutti quanti) ? Is the 896 on PCI BUS #0 or on some sort of secondary PCI BUS ? Does the sym53c8xx driver show same behaviour ? Grard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NCR53c8xx driver and multiple controllers...(not new prob)
On Sat, 24 Mar 2001, LA Walsh wrote: > I have a machine with 3 of these controllers (a 4 CPU server). The > 3 controllers are: > ncr53c810a-0: rev=0x23, base=0xfa101000, io_port=0x2000, irq=58 > ncr53c810a-0: ID 7, Fast-10, Parity Checking > ncr53c896-1: rev=0x01, base=0xfe004000, io_port=0x3000, irq=57 > ncr53c896-1: ID 7, Fast-40, Parity Checking > ncr53c896-2: rev=0x01, base=0xfe004400, io_port=0x3400, irq=56 > ncr53c896-2: ID 7, Fast-40, Parity Checking > ncr53c896-2: on-chip RAM at 0xfe002000 > > I'd like to be able to make a kernel with the driver compiled in and > no loadable module support. It don't see how to do this from the > documentation -- it seems to require a separate module loaded for > each controller. When I compile it in, it only see the 1st controller > and the boot partition I think is on the 3rd. Any ideas? The driver tries to detect all controllers it supports. Since the ncr53c8xx supports both the 810a and the 896, all your controllers should have been detected. When loaded as a module, the driver must be loaded once (btw, a seconf load should fail). > This problem is present in the 2.2.x series as well as 2.4.x (x up to 2). What hardware are you using (CPU, Core Logic and tutti quanti) ? Is the 896 on PCI BUS #0 or on some sort of secondary PCI BUS ? Does the sym53c8xx driver show same behaviour ? Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: etymology was: OOM fest
On Sat, 24 Mar 2001 [EMAIL PROTECTED] wrote: > > Btw, 'decade' comes from Latin 'deca'=10 and dies=days > > No. It is from the Greek dekas, dekados (group of ten). All my french dictionnaries agree with you. Thanks for the fix. :-) > > Could it be due to the word 'decadent' > > Unrelated. (MLatin: to fall down.) This one was intended to be the joke, but given the previous show-stopper... :-( Regards, Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent OOM from killing init
On Fri, 23 Mar 2001, Stephen E. Clark wrote: > Alan Cox wrote: > > > > > You don't beleve me if I tell you: DOS extender and JVM (Java Virtual > > > Machine) > > > > The JVM doesnt actually. The JVM will itself spontaenously explode in real > > life when out of memory. Maybe the JVM on a DOS extender 8) > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > Back in the early nineties I was working with 18 developers on a Data > General Aviion running DGUX. The system had only 16mb of memory and > 600mb of disk. We were all continuously going thru the edit, compile, > debug steps developing as large Computer Aided Dispatch System. Never > did this system with its limited resources crash, or randomly start > killing user or system processes. What about the following (it is an estimate): early nineties --> early eighties 18 developers --> 18 developers 16mb of memory --> 1 mb of memory 600 mb of disk --> 70 mb of disk Most current applications are so huge BLOATAGE that they should not deserve to be run just once. :-) The kernel must try to cope with that and also with its own BLOATAGE. Human nature is to eat what can be eaten, regardless if it is useful or not. > My $.02. What about 'My M$.02' in some decades. :) Btw, 'decade' comes from Latin 'deca'=10 and dies=days (not sure for dies). As a result, it should have meant a period of 10 days instead of 10 years. It means a period of 10 days in French. May-be, a knowledgeable person at this list has an explanation for this misinterpretation. Could it be due to the word 'decadent' that has a very different ethymology. 10 days is too short for getting decadent, but 10 years should be enough, no ? :-) > Steve Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent OOM from killing init
On Fri, 23 Mar 2001, Stephen E. Clark wrote: Alan Cox wrote: You don't beleve me if I tell you: DOS extender and JVM (Java Virtual Machine) The JVM doesnt actually. The JVM will itself spontaenously explode in real life when out of memory. Maybe the JVM on a DOS extender 8) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Back in the early nineties I was working with 18 developers on a Data General Aviion running DGUX. The system had only 16mb of memory and 600mb of disk. We were all continuously going thru the edit, compile, debug steps developing as large Computer Aided Dispatch System. Never did this system with its limited resources crash, or randomly start killing user or system processes. What about the following (it is an estimate): early nineties -- early eighties 18 developers -- 18 developers 16mb of memory -- 1 mb of memory 600 mb of disk -- 70 mb of disk Most current applications are so huge BLOATAGE that they should not deserve to be run just once. :-) The kernel must try to cope with that and also with its own BLOATAGE. Human nature is to eat what can be eaten, regardless if it is useful or not. My $.02. What about 'My M$.02' in some decades. :) Btw, 'decade' comes from Latin 'deca'=10 and dies=days (not sure for dies). As a result, it should have meant a period of 10 days instead of 10 years. It means a period of 10 days in French. May-be, a knowledgeable person at this list has an explanation for this misinterpretation. Could it be due to the word 'decadent' that has a very different ethymology. 10 days is too short for getting decadent, but 10 years should be enough, no ? :-) Steve Grard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NCR53c8xx driver and multiple controllers...(not new prob)
On Sat, 24 Mar 2001, LA Walsh wrote: I have a machine with 3 of these controllers (a 4 CPU server). The 3 controllers are: ncr53c810a-0: rev=0x23, base=0xfa101000, io_port=0x2000, irq=58 ncr53c810a-0: ID 7, Fast-10, Parity Checking ncr53c896-1: rev=0x01, base=0xfe004000, io_port=0x3000, irq=57 ncr53c896-1: ID 7, Fast-40, Parity Checking ncr53c896-2: rev=0x01, base=0xfe004400, io_port=0x3400, irq=56 ncr53c896-2: ID 7, Fast-40, Parity Checking ncr53c896-2: on-chip RAM at 0xfe002000 I'd like to be able to make a kernel with the driver compiled in and no loadable module support. It don't see how to do this from the documentation -- it seems to require a separate module loaded for each controller. When I compile it in, it only see the 1st controller and the boot partition I think is on the 3rd. Any ideas? The driver tries to detect all controllers it supports. Since the ncr53c8xx supports both the 810a and the 896, all your controllers should have been detected. When loaded as a module, the driver must be loaded once (btw, a seconf load should fail). This problem is present in the 2.2.x series as well as 2.4.x (x up to 2). What hardware are you using (CPU, Core Logic and tutti quanti) ? Is the 896 on PCI BUS #0 or on some sort of secondary PCI BUS ? Does the sym53c8xx driver show same behaviour ? Grard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: st corruption with 2.4.3-pre4
On Tue, 20 Mar 2001, Geert Uytterhoeven wrote: > On Tue, 20 Mar 2001, Geert Uytterhoeven wrote: > > On Mon, 19 Mar 2001, Jeff Garzik wrote: > > > Is the corruption reproducible? If so, does the corruption go away if > > > > Yes, it is reproducible. In all my tests, I tarred 16 files of 16 MB each to > > tape (I used a new one). > > - test 1: 4 files with failed md5sum (no further investigation on type of > > corruption) > > - test 2: 7 files with failed md5sum, 7 blocks of 32 consecutive bytes were > > corrupted, all starting at an offset of the form 32*x+1. > > - test 3: 7 files with failed md5sum, 7 blocks of 32 consecutive bytes were > > corrupted, all starting at an offset of the form 32*x+1. > > > > The files seem to be corrupted during writing only, as reading always gives the > > exact same (corrupted) data back. > > > > Copying files from the disk on the MESH to a disk on the Sym53c875 (which also > > has the tape drive) shows no corruption. > > I did some more tests: > - The problem also occurs when tarring up files from a disk on the Sym53c875. > - The corrupted data always occurs at offset 32*x (the `+1' above was caused > by hexdump, starting counting at 1). > - The 32 bytes of corrupted data at offset 32*x are always a copy of the data > at offset 32*x-10240. > - Since 10240 is the default blocksize of tar (bug in tar?), I made a tarball > on disk instead of on tape, but no corruption. > - 32 is the size of a cacheline on PPC. Is there a missing cacheflush > somewhere in the Sym53c875 driver? But then it should happen on disk as > well? The only PCI transaction that requires the cache line size to be correctly configured is PCI WRITE and INVALIDATE. This transaction may be used by the 875 only for data read from a SCSI device and DMAed to memory. Note that the controller may use optimized PCI transactions only if the cache line size is configured in its PCI device configuration space. Otherwise only normal PCI memory read and PCI memory write transactions will be used. Could you check if the cache line size is configured for your 875? Let me imagine it is so. Btw, I may be wasting my time if it is not ... Then the 875 may also use PCI read multiple transactions and/or PCI read line transactions when reading data from memory. If the corruption is due to the use of these transactions, the the PCI-HOST bridges may well be the culprit, in my opinion. Anyway, since the sym53c8xx driver does not try to change the configured cache line size on PPC, I would suggest to try again the same tests with the cache line size set to zero for the 875. You may hack the driver code or the PPC pci code if needed, for example, for value zero to be written in the proper place in the PCI configuration space of the 875. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: st corruption with 2.4.3-pre4
On Tue, 20 Mar 2001, Geert Uytterhoeven wrote: On Tue, 20 Mar 2001, Geert Uytterhoeven wrote: On Mon, 19 Mar 2001, Jeff Garzik wrote: Is the corruption reproducible? If so, does the corruption go away if Yes, it is reproducible. In all my tests, I tarred 16 files of 16 MB each to tape (I used a new one). - test 1: 4 files with failed md5sum (no further investigation on type of corruption) - test 2: 7 files with failed md5sum, 7 blocks of 32 consecutive bytes were corrupted, all starting at an offset of the form 32*x+1. - test 3: 7 files with failed md5sum, 7 blocks of 32 consecutive bytes were corrupted, all starting at an offset of the form 32*x+1. The files seem to be corrupted during writing only, as reading always gives the exact same (corrupted) data back. Copying files from the disk on the MESH to a disk on the Sym53c875 (which also has the tape drive) shows no corruption. I did some more tests: - The problem also occurs when tarring up files from a disk on the Sym53c875. - The corrupted data always occurs at offset 32*x (the `+1' above was caused by hexdump, starting counting at 1). - The 32 bytes of corrupted data at offset 32*x are always a copy of the data at offset 32*x-10240. - Since 10240 is the default blocksize of tar (bug in tar?), I made a tarball on disk instead of on tape, but no corruption. - 32 is the size of a cacheline on PPC. Is there a missing cacheflush somewhere in the Sym53c875 driver? But then it should happen on disk as well? The only PCI transaction that requires the cache line size to be correctly configured is PCI WRITE and INVALIDATE. This transaction may be used by the 875 only for data read from a SCSI device and DMAed to memory. Note that the controller may use optimized PCI transactions only if the cache line size is configured in its PCI device configuration space. Otherwise only normal PCI memory read and PCI memory write transactions will be used. Could you check if the cache line size is configured for your 875? Let me imagine it is so. Btw, I may be wasting my time if it is not ... Then the 875 may also use PCI read multiple transactions and/or PCI read line transactions when reading data from memory. If the corruption is due to the use of these transactions, the the PCI-HOST bridges may well be the culprit, in my opinion. Anyway, since the sym53c8xx driver does not try to change the configured cache line size on PPC, I would suggest to try again the same tests with the cache line size set to zero for the 875. You may hack the driver code or the PPC pci code if needed, for example, for value zero to be written in the proper place in the PCI configuration space of the 875. Grard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HP Vectra XU 5/90 interrupt problems
On Sun, 11 Mar 2001, John William wrote: > If shared, edge triggered interrupts are ok then I will talk to the driver > maintainers about the problem. If this isn't ok, then maybe the sanity check > in pci-irq.c would be to force level triggering only on shared PCI > interrupts? DEFINITELY NO! Given a PCI device + driver pair, level triggerred interrupt may be required for them to work properly, even when the line is not shared. Anyway, it is a requirement. OTOH, the PCI device must know how to trigger the interrupt. Edge triggerred interrupts cannot be shared. Level triggerred (level sensitive is a better wording, in my opinion) can be shared. Even when it is not shared (as it is required), an edge triggerred interrupt can be lost by the driver. Using level sensitive interrupt let the interrupt condition active as long as the condition is present at, at least, one device that wants to interrupt the CPU. Apart sharing of interrupt lines, level sensitive interrupt allows the device firmware to run concurrently to the CPU (software driver) without losing interrupt condition, providing that both driver and firmware use appropriate barriers against buffering in the bridge. In the same situation, using edge triggerred interrupt (not shared) can lead to interrupt condition being lost by the software driver. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HP Vectra XU 5/90 interrupt problems
On Sun, 11 Mar 2001, John William wrote: If shared, edge triggered interrupts are ok then I will talk to the driver maintainers about the problem. If this isn't ok, then maybe the sanity check in pci-irq.c would be to force level triggering only on shared PCI interrupts? DEFINITELY NO! Given a PCI device + driver pair, level triggerred interrupt may be required for them to work properly, even when the line is not shared. Anyway, it is a requirement. OTOH, the PCI device must know how to trigger the interrupt. Edge triggerred interrupts cannot be shared. Level triggerred (level sensitive is a better wording, in my opinion) can be shared. Even when it is not shared (as it is required), an edge triggerred interrupt can be lost by the driver. Using level sensitive interrupt let the interrupt condition active as long as the condition is present at, at least, one device that wants to interrupt the CPU. Apart sharing of interrupt lines, level sensitive interrupt allows the device firmware to run concurrently to the CPU (software driver) without losing interrupt condition, providing that both driver and firmware use appropriate barriers against buffering in the bridge. In the same situation, using edge triggerred interrupt (not shared) can lead to interrupt condition being lost by the software driver. Grard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SLAB vs. pci_alloc_xxx in usb-uhci patch [RFC: API]
On Fri, 9 Mar 2001, David Brownell wrote: > Gérard -- > > > Just for information to people that want to complexify the > > pci_alloc_consistent() interface thats looks simple and elegant to me: > > I certainly didn't propose that! Just a layer on top of the > pci_alloc_consistent code -- used as a page allocator, just > like you used it. > > > > The object file of the allocator as seen in sym2 is as tiny as 3.4K > > unstripped and 2.5K stripped. > > What I sent along just compiled to 2.3 KB ... stripped, and "-O". > Maybe smaller with normal kernel flags. The reverse mapping > code hast to be less than 0.1KB. If reverse mapping means bus_to_virt(), then I would suggest not to provide it since it is a confusing interface. OTOH, only a few drivers need or want to retrieve the virtual address that lead to some bus dma address and they should check that this virtual address is still valid prior to using it. As I wrote, some trivial hashed list can be used by such drivers (as sym* do). > I looked at your code, but it didn't seem straightforward to reuse. > I think the allocation and deallocation costs can be pretty comparable > in the two implementations. Your implementation might even fit behind > the API I sent. They're both layers over pci_*_consistent (and both > have address-to-address mappings, implemented much the same). I wanted the code as short as possible since the driver code is already very large. On the other hand there are bunches of #ifdef to deal with all still alive kernel versions. As a result, the code may well not be general nor clean enough to be moved to the kernel. Just what it actually does is fairly simple. > > Now, if modern programmers are expecting Java-like interfaces for writing > > kernel software, it is indeed another story. :-) > > Only if when you wrote "Java-like" you really meant "reusable"! :) Hmmm... 'reusable' implies 'usable'... Does 'usable' apply to Java applications ? :-) Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SLAB vs. pci_alloc_xxx in usb-uhci patch [RFC: API]
On Fri, 9 Mar 2001, David Brownell wrote: > > > > > extern void * > > > > > pci_pool_dma_to_cpu (struct pci_pool *pool, dma_addr_t handle); > > > > > > > > Do lots of drivers need the reverse mapping? It wasn't on my todo list > > > > yet. > > > > > > Some hardware (like OHCI) talks to drivers using those dma handles. > > > > I wonder if it may be feasible to allocate a bunch of contiguous > > pages. Then, whenever the hardware returns a bus address, subtract > > the remembered bus address of the zone start, add the offset to > > the virtual and voila. > > That's effectively what the implementation I posted is doing. > > Simple math ... as soon as you get the right "logical page", > and that page size could become a per-pool tunable. Currently > one logical page is PAGE_SIZE; there are some issues to > deal with in terms of not crossing page boundaries. > > There can be multiple such pages, known to the pool allocator > and hidden from the device drivers. I'd expect most USB host > controllers wouldn't allocate more than one or two pages, so > the cost of this function would typically be small. Just for information to people that want to complexify the pci_alloc_consistent() interface thats looks simple and elegant to me: (Hopefully, I am not off topic here) 1) The sym53c8xx driver and friends expect this simple interface to return naturally aligned memory chunks. It mostly allocates 1 page at a time. 2) The sym* drivers use a very simple allocator that keeps track of bus addresses for each chunk (page sized). The object file of the allocator as seen in sym2 is as tiny as 3.4K unstripped and 2.5K stripped. 3) The drivers need reverse virtual addresses for the DSA bus addresses and implements a simplistic hashed list that costs no more than 10 lines of trivial C code. Btw, as a result, if pci_alloc_consistent() will ever return not naturally aligned addresses the sym* drivers will be broken for Linux. This leaves me very surprised by all this noise given the _no_ issue I have seen using the pci_alloc_consistent() interface. It looked to me a _lot_ more simple to use than the equivalent interfaces I have had to suffer with other O/Ses. Now, if modern programmers are expecting Java-like interfaces for writing kernel software, it is indeed another story. :-) Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SLAB vs. pci_alloc_xxx in usb-uhci patch [RFC: API]
On Fri, 9 Mar 2001, David Brownell wrote: extern void * pci_pool_dma_to_cpu (struct pci_pool *pool, dma_addr_t handle); Do lots of drivers need the reverse mapping? It wasn't on my todo list yet. Some hardware (like OHCI) talks to drivers using those dma handles. I wonder if it may be feasible to allocate a bunch of contiguous pages. Then, whenever the hardware returns a bus address, subtract the remembered bus address of the zone start, add the offset to the virtual and voila. That's effectively what the implementation I posted is doing. Simple math ... as soon as you get the right "logical page", and that page size could become a per-pool tunable. Currently one logical page is PAGE_SIZE; there are some issues to deal with in terms of not crossing page boundaries. There can be multiple such pages, known to the pool allocator and hidden from the device drivers. I'd expect most USB host controllers wouldn't allocate more than one or two pages, so the cost of this function would typically be small. Just for information to people that want to complexify the pci_alloc_consistent() interface thats looks simple and elegant to me: (Hopefully, I am not off topic here) 1) The sym53c8xx driver and friends expect this simple interface to return naturally aligned memory chunks. It mostly allocates 1 page at a time. 2) The sym* drivers use a very simple allocator that keeps track of bus addresses for each chunk (page sized). The object file of the allocator as seen in sym2 is as tiny as 3.4K unstripped and 2.5K stripped. 3) The drivers need reverse virtual addresses for the DSA bus addresses and implements a simplistic hashed list that costs no more than 10 lines of trivial C code. Btw, as a result, if pci_alloc_consistent() will ever return not naturally aligned addresses the sym* drivers will be broken for Linux. This leaves me very surprised by all this noise given the _no_ issue I have seen using the pci_alloc_consistent() interface. It looked to me a _lot_ more simple to use than the equivalent interfaces I have had to suffer with other O/Ses. Now, if modern programmers are expecting Java-like interfaces for writing kernel software, it is indeed another story. :-) Grard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SLAB vs. pci_alloc_xxx in usb-uhci patch [RFC: API]
On Fri, 9 Mar 2001, David Brownell wrote: Grard -- Just for information to people that want to complexify the pci_alloc_consistent() interface thats looks simple and elegant to me: I certainly didn't propose that! Just a layer on top of the pci_alloc_consistent code -- used as a page allocator, just like you used it. The object file of the allocator as seen in sym2 is as tiny as 3.4K unstripped and 2.5K stripped. What I sent along just compiled to 2.3 KB ... stripped, and "-O". Maybe smaller with normal kernel flags. The reverse mapping code hast to be less than 0.1KB. If reverse mapping means bus_to_virt(), then I would suggest not to provide it since it is a confusing interface. OTOH, only a few drivers need or want to retrieve the virtual address that lead to some bus dma address and they should check that this virtual address is still valid prior to using it. As I wrote, some trivial hashed list can be used by such drivers (as sym* do). I looked at your code, but it didn't seem straightforward to reuse. I think the allocation and deallocation costs can be pretty comparable in the two implementations. Your implementation might even fit behind the API I sent. They're both layers over pci_*_consistent (and both have address-to-address mappings, implemented much the same). I wanted the code as short as possible since the driver code is already very large. On the other hand there are bunches of #ifdef to deal with all still alive kernel versions. As a result, the code may well not be general nor clean enough to be moved to the kernel. Just what it actually does is fairly simple. Now, if modern programmers are expecting Java-like interfaces for writing kernel software, it is indeed another story. :-) Only if when you wrote "Java-like" you really meant "reusable"! :) Hmmm... 'reusable' implies 'usable'... Does 'usable' apply to Java applications ? :-) Grard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx (and sym53c8xx) plans
On Mon, 19 Feb 2001, Peter Samuelson wrote: > [Justin Gibbs] > > I've verified the driver's functionality on 25 different cards thus > > far covering the full range of chips from aic7770->aic7899. > > That's very good to hear. I know the temptation of only testing on new > hardware; that's why I was concerned. > > > Lots of people here at Adaptec look at me funny when I pull a PC from > > the scrap-heap, or pull an old, discontinued card from an unused > > marketing display for use in my lab > > Heh. (: > > BTW, is there really enough common ground between the whole series of > AIC chips to justify a single huge driver? I know they ship three > separate NT drivers to cover this range.. LSILOGIC also ship 3 drivers to cover the 53C810 - 53C1010 range on NT. And, btw, these chips are all PCI. Doing so, 12 different drivers would be needed to cover 4 different O/Ses, for example. These drivers (I spoke about both LSILOGIC and ADAPTEC drivers for NT) obviously work for i386, but what about architecture dependencies at source level? May-be this is the reason some UNIX vendors seem to love UDI. :) If you also use SYMBIOS chips, you may give a try with SYM-2. For the moment, it replaces only 6 drivers :) as also seems to do, for the moment, Justin's AIC7XXX-6, by the way. The plans seem clear to me. :-) Btw, I _do_ like a lot better the 'one driver' plan over the '12 or more' one. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx (and sym53c8xx) plans
On Mon, 19 Feb 2001, Peter Samuelson wrote: [Justin Gibbs] I've verified the driver's functionality on 25 different cards thus far covering the full range of chips from aic7770-aic7899. That's very good to hear. I know the temptation of only testing on new hardware; that's why I was concerned. Lots of people here at Adaptec look at me funny when I pull a PC from the scrap-heap, or pull an old, discontinued card from an unused marketing display for use in my lab Heh. (: BTW, is there really enough common ground between the whole series of AIC chips to justify a single huge driver? I know they ship three separate NT drivers to cover this range.. LSILOGIC also ship 3 drivers to cover the 53C810 - 53C1010 range on NT. And, btw, these chips are all PCI. Doing so, 12 different drivers would be needed to cover 4 different O/Ses, for example. These drivers (I spoke about both LSILOGIC and ADAPTEC drivers for NT) obviously work for i386, but what about architecture dependencies at source level? May-be this is the reason some UNIX vendors seem to love UDI. :) If you also use SYMBIOS chips, you may give a try with SYM-2. For the moment, it replaces only 6 drivers :) as also seems to do, for the moment, Justin's AIC7XXX-6, by the way. The plans seem clear to me. :-) Btw, I _do_ like a lot better the 'one driver' plan over the '12 or more' one. Grard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] starfire reads irq before pci_enable_device.
On Tue, 13 Feb 2001, Ion Badulescu wrote: > On Tue, 13 Feb 2001 12:29:16 -0800, Ion Badulescu <[EMAIL PROTECTED]> >wrote: > > On Tue, 13 Feb 2001 07:06:44 -0600 (CST), Jeff Garzik ><[EMAIL PROTECTED]> wrote: > > > >> On 12 Feb 2001, Jes Sorensen wrote: > >>> In fact one has to look out for this and disable the feature in some > >>> cases. On the acenic not disabling Memory Write and Invalidate costs > >>> ~20% on performance on some systems. > >> > >> And in another message, On Mon, 12 Feb 2001, David S. Miller wrote: > >>> 3) The acenic/gbit performance anomalies have been cured > >>>by reverting the PCI mem_inval tweaks. > >> > >> Just to be clear, acenic should or should not use MWI? > > With the zerocopy patch, acenic always disables MWI by default. > > >> And can a general rule be applied here? Newer Tulip hardware also > >> has the ability to enable/disable MWI usage, IIRC. > > > > And so do eepro100 and starfire. On the eepro100 we're enabling MWI > > unconditionally, and on the starfire we disable it unconditionally... > > > > I should probably take a look at acenic's use of PCI_COMMAND_INVALIDATE > > to see when it gets activated. Some benchmarking would probably help, > > too -- maybe later today. > > I did some testing with starfire, and the results are inconclusive -- > at least on my P-III is makes absolutely no difference. Does it make > a difference on other architectures? sparc64, ia64 maybe? > > I should probably rephrase this: MWI makes no difference on i386, but > it is claimed that using MWI *reduces* performance on some systems. > Are there any systems on which MWI *increases* performance? I have read several data sheets about Intel PCI-HOST bridges and they all were said to alias PCI MWI to normal PCI MEMORY WRITE transactions. This matches your observations just fine. Even when MWI is handled as MW, the PCI master is required to transfer entire cache lines and this cannot be bad for performances. But this should probably not make significant difference with normal MW. Btw, your rephrasing looks improper to me. The processor is not involved in the handling of MWI., especially when the MWI targets the memory. It is the PCI-HOST bridge that must be considered here. What about ServerWorks chipset ? Hmmm... I would be glad to have docs about these ones. :( The MWI is intended to allow optimizations based on cache lines invalidations rather than snooping. The target (or bridge) can perfectly elect to handle the MWI as a normal MW and so, performance should not be significantly lowered using MWI. But nothing is perfect, as we know. The MWI is interesting for PCI throughput optimization but the MEMORY READ LINE and MEMORY READ MULTIPLE transactions are a lot more interesting, in my opinion. WRITEs can be posted (buffered), but in order to stream data from memory (prefetchable) the bridge can do a better work when it knows the intention of the PCI MASTER. All bridges should take in considerations hints associated with MRL and MRM. IIRC, Intel bridges do. > I've added some code to the starfire driver that allows changing the > use of MWI at module load time, just in case. By default, it activates > it. You should also play with MRL and MRM, in my opinion. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SYM-2 / SYM-1 / NCR-3 drivers UPdates
Updated drivers for SYMBIOS 53C[8XX|1010] chips are available from the ftp.tux.org site. sym53c8xx-1.7.3-pre1 + ncr53c8xx-3.4.3-pre1 --- URL (entered by hand): ftp.tux.org://roudier/drivers/linux/stable/sym-1.7.3-ncr-3.4.3-pre1.tar.gz sym-2.1.6 - URL (entered by foot :)) ftp.tux.org://roudier/drivers/portable/sym-2.1.6-20010207.tar.gz The former is an update for the driver bundle currently in 2.2 and 2.4. The latter is the portable sym driver that for now supports Linux and FreeBSD. Stock sym/ncr drivers in both 2.2 and 2.4 are more than 6 months old and need to be updated. My plan is to leave kernel maintainers the choice between sym-1/ncr-3 and sym-2. Btw, sym-2 is anyway candidate for 2.5. The both (tri?) drivers do call pci_enable_device() prior to looking into the pcidev structure. Donnot colour me happy of that, but given that it is not me but kernel maintainers that will be bashed if this breaks firmware RAID, I didn't see any problem for this change. :-) If some additionnal testing could be performed this week-end by courageous Linux users, this will avoid some noise once sent to kernel maintainers, if I missed something important in the updates. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] starfire reads irq before pci_enable_device.
On Fri, 9 Feb 2001, Alan Cox wrote: > > > For non routing paths its virtually free because the DMA forced the lines > > > from cache anyway. > > > > Are you actually sure about this? I thought DMA from PCI devices reached > > the main memory without polluting the L2 cache. Otherwise any large DMA > > transfer would kill the cache (think frame grabbers...) > > DMA to main memory normally invalidates those lines in the CPU cache rather > than the cache snooping and updating its view of them. In PCI, it is the Memory Write and Invalidate PCI transaction that is intended to allow core-logics to optimize DMA this way. For normal Memory Write PCI transactions or when the core-logic is aliasing MWI to MW, the snooping may well happen. All that stuff, very probably, varies a lot depending on the core-logic. As we know, in normal PCI, the target is not told about the transaction length prior to the bursting of the data. This makes difficult for a core logic to use cache invalidation rather than dma snooping when a normal MW is used, thus the invention of MWI. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
SYM-2 / SYM-1 / NCR-3 drivers UPdates
Updated drivers for SYMBIOS 53C[8XX|1010] chips are available from the ftp.tux.org site. sym53c8xx-1.7.3-pre1 + ncr53c8xx-3.4.3-pre1 --- URL (entered by hand): ftp.tux.org://roudier/drivers/linux/stable/sym-1.7.3-ncr-3.4.3-pre1.tar.gz sym-2.1.6 - URL (entered by foot :)) ftp.tux.org://roudier/drivers/portable/sym-2.1.6-20010207.tar.gz The former is an update for the driver bundle currently in 2.2 and 2.4. The latter is the portable sym driver that for now supports Linux and FreeBSD. Stock sym/ncr drivers in both 2.2 and 2.4 are more than 6 months old and need to be updated. My plan is to leave kernel maintainers the choice between sym-1/ncr-3 and sym-2. Btw, sym-2 is anyway candidate for 2.5. The both (tri?) drivers do call pci_enable_device() prior to looking into the pcidev structure. Donnot colour me happy of that, but given that it is not me but kernel maintainers that will be bashed if this breaks firmware RAID, I didn't see any problem for this change. :-) If some additionnal testing could be performed this week-end by courageous Linux users, this will avoid some noise once sent to kernel maintainers, if I missed something important in the updates. Grard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Hamachi not doing pci_enable before reading resources
You missed the newer statements about every piece of hardware being assumed to be hot-pluggable and all the hardware being under full control by CPU. You also missed the well known point that only device drivers are broken under Linux and that all the generic O/S code is just perfect. :-) Gérard. On Wed, 7 Feb 2001, Richard B. Johnson wrote: > On Wed, 7 Feb 2001 [EMAIL PROTECTED] wrote: > > > > > Hi Alan, > > > > Another driver not doing pci_enable_device() early enough. > > > > Dave. > > > > A PCI device does not and should not be enabled to probe for resources! > It is only devices that have BIOS that require the device to be enabled > for memory I/O prior to downloading the BIOS into RAM. The BARs are > read/writable (and are required to be), even when the Mem/I/O bits > in the cmd/status register are clear. > > This is a required condition! You certainly don't want to write all > ones to a decode (to find the resource length) of a live, on-line chip! > If the chip hickups (think network chips connected to networks, on a > warm-boot), you will trash lots of stuff in memory. > > It looks as though you are "fixing" drivers that are not broken and, > in fact, are trying to do the right thing. Maybe the PCI code in the > kernel is preventing access to resources unless the device has been > enabled??? If so, it's broken and should be fixed, instead of all > the drivers. > > Cheers, > Dick Johnson > > Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). > > "Memory is like gasoline. You use it up when you are running. Of > course you get it all back when you reboot..."; Actual explanation > obtained from the Micro$oft help desk. > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Hamachi not doing pci_enable before reading resources
You missed the newer statements about every piece of hardware being assumed to be hot-pluggable and all the hardware being under full control by CPU. You also missed the well known point that only device drivers are broken under Linux and that all the generic O/S code is just perfect. :-) Grard. On Wed, 7 Feb 2001, Richard B. Johnson wrote: On Wed, 7 Feb 2001 [EMAIL PROTECTED] wrote: Hi Alan, Another driver not doing pci_enable_device() early enough. Dave. A PCI device does not and should not be enabled to probe for resources! It is only devices that have BIOS that require the device to be enabled for memory I/O prior to downloading the BIOS into RAM. The BARs are read/writable (and are required to be), even when the Mem/I/O bits in the cmd/status register are clear. This is a required condition! You certainly don't want to write all ones to a decode (to find the resource length) of a live, on-line chip! If the chip hickups (think network chips connected to networks, on a warm-boot), you will trash lots of stuff in memory. It looks as though you are "fixing" drivers that are not broken and, in fact, are trying to do the right thing. Maybe the PCI code in the kernel is preventing access to resources unless the device has been enabled??? If so, it's broken and should be fixed, instead of all the drivers. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.4.0, 2.4.0-ac12: APIC lock-ups
On Fri, 2 Feb 2001, Manfred Spraul wrote: > Gérard Roudier wrote: > > > > So, why not using a pure software flag in memory and only tampering the > > things if the offending interrupt is actually delivered ? If the given > > interrupt is delivered and the software mask is set we could simply do: > > > > - MASK the given interrupt > > - EOI it. > > - return > > > Good idea. > I implemented it, and it was a full success: not it always locks up :-( > > If I apply the attached patch, then I get a lockup after ~ 100 packets > flood ping. > I've also attached the dmesg print. > I know that startup is currently wrong (must set trigger to level), but > that doesn't matter since I only ifup once. > > But I think we can change the bug description: > > If an io apic io redirection entry is unmasked while the irq pin is > active, then the io apic sends out the interrupt as edge triggered, but > nevertheless sets the IRR bit. Interesting. My little finger tells me that O/Ses that thread interrupts might well want to rely on MASK + EOI in order to quiesce incoming level-sensitive interrupts. Note that tampering the IO/APIC after initializations looks extremally ugly to me. In my opinion, only the local APIC was intended by Intel designers to be accessed by CPU after initialization (I may be wrong here). > In a second test run I checked the TMR bit in the local apics: the bit > on the cpu that received the last interrupt is really 0. > > I'll not try a 2 step enable: > * unmask. > * io_apic_sync() > * set trigger mode to level. Thanks for having tried my suggestion. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.4.0, 2.4.0-ac12: APIC lock-ups
On Fri, 2 Feb 2001, Manfred Spraul wrote: Grard Roudier wrote: So, why not using a pure software flag in memory and only tampering the things if the offending interrupt is actually delivered ? If the given interrupt is delivered and the software mask is set we could simply do: - MASK the given interrupt - EOI it. - return Good idea. I implemented it, and it was a full success: not it always locks up :-( If I apply the attached patch, then I get a lockup after ~ 100 packets flood ping. I've also attached the dmesg print. I know that startup is currently wrong (must set trigger to level), but that doesn't matter since I only ifup once. But I think we can change the bug description: If an io apic io redirection entry is unmasked while the irq pin is active, then the io apic sends out the interrupt as edge triggered, but nevertheless sets the IRR bit. Interesting. My little finger tells me that O/Ses that thread interrupts might well want to rely on MASK + EOI in order to quiesce incoming level-sensitive interrupts. Note that tampering the IO/APIC after initializations looks extremally ugly to me. In my opinion, only the local APIC was intended by Intel designers to be accessed by CPU after initialization (I may be wrong here). In a second test run I checked the TMR bit in the local apics: the bit on the cpu that received the last interrupt is really 0. I'll not try a 2 step enable: * unmask. * io_apic_sync() * set trigger mode to level. Thanks for having tried my suggestion. Grard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.4.0, 2.4.0-ac12: APIC lock-ups
On Fri, 2 Feb 2001, Maciej W. Rozycki wrote: > On Thu, 1 Feb 2001, Andrew Morton wrote: > +/* > + * It appears there is an erratum which affects at least the 82093AA > + * I/O APIC. If a level-triggered interrupt input is being masked in > + * the redirection entry while the interrupt is send pending (its > + * delivery status bit is set), the interrupt is erroneously > + * delivered as edge-triggered but the IRR bit gets set nevertheless. > + * As a result the I/O unit expects an EOI message but it will never > + * arrive and further interrupts are blocked for the source. > + * > + * A workaround is to set the trigger mode to edge when masking > + * a level-triggered interrupt and to revert the mode when unmasking. > + * The idea is from Manfred Spraul. --macro > + */ Is the below idea feasible or just stupid: Once a level-sensitive interrupt has been accepted by a local APIC, the IO APIC will wait for the EIO message prior to delivering again this interrupt. Therefore masking a level-sensitive interrupt once it has been delivered and prior to EIOing it should not race with the APIC hardware. So, why not using a pure software flag in memory and only tampering the things if the offending interrupt is actually delivered ? If the given interrupt is delivered and the software mask is set we could simply do: - MASK the given interrupt - EOI it. - return Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.4.0, 2.4.0-ac12: APIC lock-ups
On Fri, 2 Feb 2001, Maciej W. Rozycki wrote: On Thu, 1 Feb 2001, Andrew Morton wrote: +/* + * It appears there is an erratum which affects at least the 82093AA + * I/O APIC. If a level-triggered interrupt input is being masked in + * the redirection entry while the interrupt is send pending (its + * delivery status bit is set), the interrupt is erroneously + * delivered as edge-triggered but the IRR bit gets set nevertheless. + * As a result the I/O unit expects an EOI message but it will never + * arrive and further interrupts are blocked for the source. + * + * A workaround is to set the trigger mode to edge when masking + * a level-triggered interrupt and to revert the mode when unmasking. + * The idea is from Manfred Spraul. --macro + */ Is the below idea feasible or just stupid: Once a level-sensitive interrupt has been accepted by a local APIC, the IO APIC will wait for the EIO message prior to delivering again this interrupt. Therefore masking a level-sensitive interrupt once it has been delivered and prior to EIOing it should not race with the APIC hardware. So, why not using a pure software flag in memory and only tampering the things if the offending interrupt is actually delivered ? If the given interrupt is delivered and the software mask is set we could simply do: - MASK the given interrupt - EOI it. - return Grard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make sym53c8xx.c and ncr53c8xx.c call pci_enable_device
On Wed, 31 Jan 2001, Alan Cox wrote: > > If the pci_enable_device() thing is to be added to the drivers, it must > > preferently be placed after the checking against RAID attachement. > > You cant check the signature until the device has been enabled. Maybe you > could poke the LSI guys and find out how windows PnP stuff handles this. Personnaly I donnot need to know how windows handle this in order to figure out how it should be properly handled. In theory, the signature should be checked prior to any change in the device configuration space. But since PCI BIOS assigning of resource windows is complete mess-up, the O/S has to probe BAR sizes. The probing of BAR sizes does not seem to harm. This done, given that it is possible then to first check the signature and to leave quiet the device if it is owned by RAID, there is no valuable reason to still tamper the device for nothing if it is not to be attached. > I think the proposed change is ok because if the board is enabled then the > enabling code won't touch it. Can you swear that the code will never change ? Anyway, the current code at least enables response to IO and to MEM based on existing BARs. This probably does not harm but this should be done on behalf of the software driver and based on actually _used_ resources. On the other hand, the complex enabling of IRQ is really something we want to avoid in situation where it is not actually useful. End of story, since moving pci_enable_device() in its preferred place as I suggested is an obvious minute change. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make sym53c8xx.c and ncr53c8xx.c call pci_enable_device
On Wed, 31 Jan 2001, Alan Cox wrote: If the pci_enable_device() thing is to be added to the drivers, it must preferently be placed after the checking against RAID attachement. You cant check the signature until the device has been enabled. Maybe you could poke the LSI guys and find out how windows PnP stuff handles this. Personnaly I donnot need to know how windows handle this in order to figure out how it should be properly handled. In theory, the signature should be checked prior to any change in the device configuration space. But since PCI BIOS assigning of resource windows is complete mess-up, the O/S has to probe BAR sizes. The probing of BAR sizes does not seem to harm. This done, given that it is possible then to first check the signature and to leave quiet the device if it is owned by RAID, there is no valuable reason to still tamper the device for nothing if it is not to be attached. I think the proposed change is ok because if the board is enabled then the enabling code won't touch it. Can you swear that the code will never change ? Anyway, the current code at least enables response to IO and to MEM based on existing BARs. This probably does not harm but this should be done on behalf of the software driver and based on actually _used_ resources. On the other hand, the complex enabling of IRQ is really something we want to avoid in situation where it is not actually useful. End of story, since moving pci_enable_device() in its preferred place as I suggested is an obvious minute change. Grard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make sym53c8xx.c and ncr53c8xx.c call pci_enable_device(241p11)
You missed that SYMBIOS devices can be attached by RAID firmware and,
that, in such situation, the kernel should avoid tampering the SYMBIOS
device. The [ncr|sym]53c8xx drivers are aware of that, and donnot attach
SYMBIOS devices owned by RAID.
If the pci_enable_device() thing is to be added to the drivers, it must
preferently be placed after the checking against RAID attachement.
(look for 0x52414944 in the driver source which is the signature tested by
the drivers, or look into beta SYM-2).
Gérard.
On Mon, 29 Jan 2001, Rasmus Andersen wrote:
> Hi.
>
> The following patch makes drivers/scsi/sym53c8xx.c and (by way of
> sym53c8xx_comm.h::sym53c8xx__detect) ncr53c8xx.c do a
> pci_enable_device after finding a device.
>
> It applies against ac12 and 241p11.
>
> Comments?
>
>
> --- linux-ac11-clean/drivers/scsi/sym53c8xx.c Mon Jan 1 19:23:21 2001
> +++ linux-ac11/drivers/scsi/sym53c8xx.c Thu Jan 25 23:12:06 2001
> @@ -13294,6 +13294,8 @@
> ++j;
> continue;
> }
> + if (pci_enable_device(pcidev))
> + continue;
> /* Some HW as the HP LH4 may report twice PCI devices */
> for (i = 0; i < count ; i++) {
> if (devtbl[i].slot.bus == PciBusNumber(pcidev) &&
> --- linux-ac11-clean/drivers/scsi/sym53c8xx_comm.hMon Oct 16 21:56:50 2000
> +++ linux-ac11/drivers/scsi/sym53c8xx_comm.h Fri Jan 26 22:54:19 2001
> @@ -2754,6 +2754,8 @@
> ++j;
> continue;
> }
> + if (pci_enable_device(pcidev))
> + continue;
> /* Some HW as the HP LH4 may report twice PCI devices */
> for (i = 0; i < count ; i++) {
> if (devtbl[i].slot.bus == PciBusNumber(pcidev) &&
>
> --
> Regards,
> Rasmus([EMAIL PROTECTED])
>
> When C++ is your hammer, everything looks like a thumb. Steven M. Haflich
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make drivers/scsi/sym53c8xx.c check request_region'sreturn code (241p9)]
On Thu, 25 Jan 2001, Rasmus Andersen wrote:
> Hi.
>
> I apparently forgot to cc the lists on this one. Replies should be cc'ed
> to [EMAIL PROTECTED] also.
>
> Thanks.
The change should not harm, but request_region() is very unlikely to fail
here. Reason is that the drivers previously perform a check_region() in
order to synchronyze with any other driver that may have attached the same
device (candidates are : sym53c8xx, ncr53c8xx, 53c7,8xx)
By the way, as PCI only device drivers, the [sym|ncr]53c8xx drivers want
to use MMIO and not normal IO. The 'normal IO' path is here for archs that
donnot want to accept MMIO. Note that there are a couple of strangenesses
here:
1) The FreeBSD sym driver (derived from sym53c8xx) works with MMIO on
FreeBSD/Alpha, but the sym53c8xx fails MMIO under Linux/Alpha.
2) Power/PC port wants drivers to use normal IOs even on machines that
only have MMIO.
(2) looks rather a weirdness than a strangeness. :-)
Gérard.
> - Forwarded message from Rasmus Andersen <[EMAIL PROTECTED]> -
>
> Date: Tue, 23 Jan 2001 23:37:14 +0100
> From: Rasmus Andersen <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [PATCH] make drivers/scsi/sym53c8xx.c check request_region's return code
>(241p9)
> User-Agent: Mutt/1.2.4i
>
> Hi.
>
> The following patch makes drivers/scsi/sym53c8xx.c check the return
> code of request_region. It applies cleanly against ac10 and 241p9.
>
> Please comment.
>
>
>
> --- linux-ac10-clean/drivers/scsi/sym53c8xx.c Mon Jan 1 19:23:21 2001
> +++ linux-ac10/drivers/scsi/sym53c8xx.c Sun Jan 21 21:40:54 2001
> @@ -5817,7 +5817,11 @@
> */
>
> if (device->slot.io_port) {
> - request_region(device->slot.io_port, np->base_ws, NAME53C8XX);
> + if (!request_region(device->slot.io_port, np->base_ws,
> + NAME53C8XX)) {
> + printk(KERN_ERR "Cannot mmap IO range.\n");
> + goto attach_error;
> + }
> np->base_io = device->slot.io_port;
> }
>
> --- linux-ac10-clean/drivers/scsi/sym53c8xx_comm.hMon Oct 16 21:56:50 2000
> +++ linux-ac10/drivers/scsi/sym53c8xx_comm.h Mon Jan 22 21:56:46 2001
> @@ -1799,7 +1799,8 @@
> **Get access to chip IO registers
> */
> #ifdef NCR_IOMAPPED
> - request_region(devp->slot.io_port, 128, NAME53C8XX);
> + if (!request_region(devp->slot.io_port, 128, NAME53C8XX))
> + return;
> devp->slot.base_io = devp->slot.io_port;
> #else
> devp->slot.reg = (struct ncr_reg *) remap_pci_mem(devp->slot.base, 128);
>
>
> --
> Regards,
> Rasmus([EMAIL PROTECTED])
>
> It isn't pollution that's harming the environment. It's the impurities in
> our air and water that are doing it. -Former U.S. Vice-President Dan
> Quayle
>
> - End forwarded message -
>
> --
> Regards,
> Rasmus([EMAIL PROTECTED])
>
> Freedom of the press is limited to those who own one.
> - A.J. Liebling
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Poor SCSI drive performance on SMP machine, 2.2.16
On Sun, 28 Jan 2001, paradox3 wrote: > I have an SMP machine (dual PII 400s) running 2.2.16 with one 10,000 RPM IBM > 10 GB SCSI drive > (AIC 7890 on motherboard, using aic7xxx.o), and four various IDE drives. The > SCSI drive > performs the worst. In tests of writing 100 MB and sync'ing, one of my IDE > drives takes 31 seconds. The SCSI drive (while doing nothing else) took > 2 minutes, 10 seconds. This is extremely noticable in file transfers that > completely > monopolize the SCSI drive, and are much slower than when involving the IDE > drives. > After a large data operation on the SCSI drive, the system will hang for > several minutes. > Anyone know what could be causing this? Thanks. > > Attached are some data to help. You didn't provide enough information for anybody to have a single idea about the cause of the problem you report, in my opinion. Just any not too old 10,000 RPM disk is able to sustain more that 25 MB/s sequential data transfer, but cannot do better than 5 milli-seconds latency with random IO patterns. So, result for 100 MB transfer can be less than 4 seconds in the best case but greater than (25000*5)/1000=125 seconds for random 4K IO pattern, for example. What you want to do, in my opinion, could be: - Check in the syslog the actual transfer speed that has been negotiated for your SCSI disk. - Also check if error messages related to disk IOs have been reported by the kernel. - Run some benchmark to check, at least, sequential IO performance (iozone for example will fit) Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor SCSI drive performance on SMP machine, 2.2.16
On Sun, 28 Jan 2001, paradox3 wrote: I have an SMP machine (dual PII 400s) running 2.2.16 with one 10,000 RPM IBM 10 GB SCSI drive (AIC 7890 on motherboard, using aic7xxx.o), and four various IDE drives. The SCSI drive performs the worst. In tests of writing 100 MB and sync'ing, one of my IDE drives takes 31 seconds. The SCSI drive (while doing nothing else) took 2 minutes, 10 seconds. This is extremely noticable in file transfers that completely monopolize the SCSI drive, and are much slower than when involving the IDE drives. After a large data operation on the SCSI drive, the system will hang for several minutes. Anyone know what could be causing this? Thanks. Attached are some data to help. You didn't provide enough information for anybody to have a single idea about the cause of the problem you report, in my opinion. Just any not too old 10,000 RPM disk is able to sustain more that 25 MB/s sequential data transfer, but cannot do better than 5 milli-seconds latency with random IO patterns. So, result for 100 MB transfer can be less than 4 seconds in the best case but greater than (25000*5)/1000=125 seconds for random 4K IO pattern, for example. What you want to do, in my opinion, could be: - Check in the syslog the actual transfer speed that has been negotiated for your SCSI disk. - Also check if error messages related to disk IOs have been reported by the kernel. - Run some benchmark to check, at least, sequential IO performance (iozone for example will fit) Grard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Scanning problems - machine lockups
On Fri, 19 Jan 2001, Bob Frey wrote: > On Thu, Jan 18, 2001 at 11:24:54PM +, Stephen Kitchener wrote: > > The only thing that might be odd is that the scanner's scsi card and the > > display card are using the same IRQ, but I thought that IRQ sharing was ok in > > the new kernels. The display card is an AGP type and the scsi card is pci. > > > > As you might have guessed, I am at a loss as to what to do next. Any help > > appriciated, even suggestions as to how I can track down what I haven't done > > (yet!) > Sharing interrupts could be the problem. Interrupt sharing is supported > in the kernel as far as two different drivers being able to register a > handler for the same interrupt, but not much beyond that. From studying > the code I don't find any handling of unclaimed or spurious interrupts. > > Some drivers (like video cards) do not register a handler for their card's > interrupt. So when another driver (like the advansys driver) shares an > interrupt with this card's "unregistered" interrupt there is no one left > to handle the interrupt. The system will loop taking an interrupt from > the card. I've observed this using the frame buffer driver. Note: this > problem is unnoticed if the (video) card does not share an interrupt with > another driver, because (at least on x86) Linux does not enable the > PIC IRQ bit for IRQs that do not have registered interrupted handlers. > > For Linux I think the right way to handle this is to have each (SA_SHIRQ) > sharing capable interrupt handler return a TRUE or FALSE value indicating > whether the interrupt belongs to the driver. In kernel/irq.c:handle_IRQ_event() > check the return value. If after one pass through all of the interrupt > (action) handlers no one has claimed the inerrupt then log a warning message > (spurious interrupt) and clear the interrupt. The difficult/painstaking > problem is that all SA_SHIRQ drivers need to be changed to return a return > value to make this work. There is no ordering of interrupts with respect to transactions in PCI. As a result, getting interrupts that does not match a pending interrupt condition as seen by driver can happen, without the interrupt being spurious. As a result, the 2 following assertions: - All interrupts in PCI are spurious - No interrupt is PCI is spurious Are less wrong than asserting that some interrupts in PCI are relevant and some are spurious. :-) And btw, some hardwares, notably Intel ones, seems to ensure coherency prior to deliver interrupts. This is a useless work when the IRQ is actually shared and does only make sense for ISA or ISA-like PCI devices and in situations where the IRQ is not actually shared. > Anyway the simplest solution for you is probably if you can is to put > assign the video card its own interrupt. Putting the two advansys cards > on the same interrupt is fine. I have used interrupt sharing between > multiple advansys cards and and ethernet cards without a problem. In theory, the O/S should warn _loudly_ if any PCI device hasn't a software driver attached, for the reason there is no generic way to actually quiesce completely a PCI device. As a result, loading drivers after boot or just loading drivers with interrupt enabled at boot is unsafe with PCI devices. This shall be considered, even if the risk of a breakage is generally very low. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Scanning problems - machine lockups
On Fri, 19 Jan 2001, Bob Frey wrote: On Thu, Jan 18, 2001 at 11:24:54PM +, Stephen Kitchener wrote: The only thing that might be odd is that the scanner's scsi card and the display card are using the same IRQ, but I thought that IRQ sharing was ok in the new kernels. The display card is an AGP type and the scsi card is pci. As you might have guessed, I am at a loss as to what to do next. Any help appriciated, even suggestions as to how I can track down what I haven't done (yet!) Sharing interrupts could be the problem. Interrupt sharing is supported in the kernel as far as two different drivers being able to register a handler for the same interrupt, but not much beyond that. From studying the code I don't find any handling of unclaimed or spurious interrupts. Some drivers (like video cards) do not register a handler for their card's interrupt. So when another driver (like the advansys driver) shares an interrupt with this card's "unregistered" interrupt there is no one left to handle the interrupt. The system will loop taking an interrupt from the card. I've observed this using the frame buffer driver. Note: this problem is unnoticed if the (video) card does not share an interrupt with another driver, because (at least on x86) Linux does not enable the PIC IRQ bit for IRQs that do not have registered interrupted handlers. For Linux I think the right way to handle this is to have each (SA_SHIRQ) sharing capable interrupt handler return a TRUE or FALSE value indicating whether the interrupt belongs to the driver. In kernel/irq.c:handle_IRQ_event() check the return value. If after one pass through all of the interrupt (action) handlers no one has claimed the inerrupt then log a warning message (spurious interrupt) and clear the interrupt. The difficult/painstaking problem is that all SA_SHIRQ drivers need to be changed to return a return value to make this work. There is no ordering of interrupts with respect to transactions in PCI. As a result, getting interrupts that does not match a pending interrupt condition as seen by driver can happen, without the interrupt being spurious. As a result, the 2 following assertions: - All interrupts in PCI are spurious - No interrupt is PCI is spurious Are less wrong than asserting that some interrupts in PCI are relevant and some are spurious. :-) And btw, some hardwares, notably Intel ones, seems to ensure coherency prior to deliver interrupts. This is a useless work when the IRQ is actually shared and does only make sense for ISA or ISA-like PCI devices and in situations where the IRQ is not actually shared. Anyway the simplest solution for you is probably if you can is to put assign the video card its own interrupt. Putting the two advansys cards on the same interrupt is fine. I have used interrupt sharing between multiple advansys cards and and ethernet cards without a problem. In theory, the O/S should warn _loudly_ if any PCI device hasn't a software driver attached, for the reason there is no generic way to actually quiesce completely a PCI device. As a result, loading drivers after boot or just loading drivers with interrupt enabled at boot is unsafe with PCI devices. This shall be considered, even if the risk of a breakage is generally very low. Grard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sym-2.1.0-20001230 vs. sg (cdrecord)
On Thu, 11 Jan 2001, Boszormenyi Zoltan wrote: > Hi! > > I just wanted to let you know that I successfully ruined > a CD with 2.4.0 + sym-2.1.0-20001230. The system is a RH 7.0 > with glibc-2.2-9, cdrecord-1.9. Thanks for the report. But with so tiny information, it gives about no usefulness to me. > When will it be really usable? A single ruined CD is probably too weak a symptom for stating any serious sickness in the driver. FYI, I cannot even personnaly try to ruin a single CDR, for the reason I don't have CDR. If you can retrieve information related to the failure, you may send me them (syslog messages, cdrecord output messages, etc...). Thanks in advance. You may also give a try with stable kernel and related stuff and let me know the result. Regards, Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sym-2.1.0-20001230 vs. sg (cdrecord)
On Thu, 11 Jan 2001, Boszormenyi Zoltan wrote: Hi! I just wanted to let you know that I successfully ruined a CD with 2.4.0 + sym-2.1.0-20001230. The system is a RH 7.0 with glibc-2.2-9, cdrecord-1.9. Thanks for the report. But with so tiny information, it gives about no usefulness to me. When will it be really usable? A single ruined CD is probably too weak a symptom for stating any serious sickness in the driver. FYI, I cannot even personnaly try to ruin a single CDR, for the reason I don't have CDR. If you can retrieve information related to the failure, you may send me them (syslog messages, cdrecord output messages, etc...). Thanks in advance. You may also give a try with stable kernel and related stuff and let me know the result. Regards, Grard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
SYM-2 driver released (:=sym53c8xx+ncr53c8xx).
I just released sym-2.1.0 driver, that, according to my personnal QA plan :-), is the first Beta-release of this major driver version. People interested in either using or just trying it can found the reference tarball at the following URL: ftp://ftp.tux.org/roudier/drivers/portable/sym-2.1.x/sym-2.1.0-20001230.tar.gz This driver replaces functionnaly both sym53c8xx and ncr53c8xx. It is in fact the FreeBSD sym driver that got portable and that, for now, also supports Linux. The driver reference sources layout is the following: Common: sym_conf.h sym_defs.h sym_fw.csym_fw.h sym_fw1.hsym_fw2.h sym_hipd.c sym_hipd.h sym_malloc.c sym_misc.h sym_nvram.c FreeBSD: sym_glue.c sym_glue.h Linux: sym53c8xx.h sym_glue.c sym_glue.h All the files can also be clicked/clipped :) individually from the the following directory: ftp://ftp.tux.org/roudier/drivers/portable/sym-2.1.x/current/ Given the genealogy of this driver, I have decided to maintain a high level of compatibility with the sym53c8xx driver under Linux. But, due to the number of sources files (14 under Linux), the driver sources will now own a separate directory instead of being dropped in the huge drivers/scsi/ directory. The installation procedure supplied in the tarball moves the files to: /usr/linux/drivers/scsi/sym53c8xx/ As a result, a tiny patch is needed for the related kernel files to be aware of the new driver files location. And, as I have limited time, only patches for 2.2.16, 2.2.17 and 2.2.18 are supplied for now. People who will succeed installing the driver on other Linux kernel releases, especially recent ones, can send me the corresponding tiny kernel patch. Btw, this driver does not support Linux-2.0.X kernels. The major improvements against sym53c8xx driver can be summarized as follows: - Don't use the scsi_obsolete interface anymore. I could word it as 'use the new error handling interface', but the best advantage, in my opinion, is that driver entry points are not called recursively as does the old scsi code. - Support for the entire NCR/SYMBIOS/LSILOGIC 53C[8XX|1010] in a single driver without significant bloat of the object code. The driver with all options enabled is about 73K not stripped and 59K stripped under Linux-2.2.18. - Refining of a couple of work-arounds that let me claim that the driver supports the best possible all chips of all revisions, even very early revisions of recent chips. I am highly interested in receiving reports, either success or problem, about this driver version, especially when the driver is tried on non Intel IA32 platforms. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
SYM-2 driver released (:=sym53c8xx+ncr53c8xx).
I just released sym-2.1.0 driver, that, according to my personnal QA plan :-), is the first Beta-release of this major driver version. People interested in either using or just trying it can found the reference tarball at the following URL: ftp://ftp.tux.org/roudier/drivers/portable/sym-2.1.x/sym-2.1.0-20001230.tar.gz This driver replaces functionnaly both sym53c8xx and ncr53c8xx. It is in fact the FreeBSD sym driver that got portable and that, for now, also supports Linux. The driver reference sources layout is the following: Common: sym_conf.h sym_defs.h sym_fw.csym_fw.h sym_fw1.hsym_fw2.h sym_hipd.c sym_hipd.h sym_malloc.c sym_misc.h sym_nvram.c FreeBSD: sym_glue.c sym_glue.h Linux: sym53c8xx.h sym_glue.c sym_glue.h All the files can also be clicked/clipped :) individually from the the following directory: ftp://ftp.tux.org/roudier/drivers/portable/sym-2.1.x/current/ Given the genealogy of this driver, I have decided to maintain a high level of compatibility with the sym53c8xx driver under Linux. But, due to the number of sources files (14 under Linux), the driver sources will now own a separate directory instead of being dropped in the huge drivers/scsi/ directory. The installation procedure supplied in the tarball moves the files to: /usr/linux/drivers/scsi/sym53c8xx/ As a result, a tiny patch is needed for the related kernel files to be aware of the new driver files location. And, as I have limited time, only patches for 2.2.16, 2.2.17 and 2.2.18 are supplied for now. People who will succeed installing the driver on other Linux kernel releases, especially recent ones, can send me the corresponding tiny kernel patch. Btw, this driver does not support Linux-2.0.X kernels. The major improvements against sym53c8xx driver can be summarized as follows: - Don't use the scsi_obsolete interface anymore. I could word it as 'use the new error handling interface', but the best advantage, in my opinion, is that driver entry points are not called recursively as does the old scsi code. - Support for the entire NCR/SYMBIOS/LSILOGIC 53C[8XX|1010] in a single driver without significant bloat of the object code. The driver with all options enabled is about 73K not stripped and 59K stripped under Linux-2.2.18. - Refining of a couple of work-arounds that let me claim that the driver supports the best possible all chips of all revisions, even very early revisions of recent chips. I am highly interested in receiving reports, either success or problem, about this driver version, especially when the driver is tried on non Intel IA32 platforms. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
On Wed, 13 Dec 2000, Justin T. Gibbs wrote: > > Date: Wed, 13 Dec 2000 20:56:08 -0700 > > From: "Justin T. Gibbs" <[EMAIL PROTECTED]> > > > > None-the-less, it seems to me that spamming the kernel namespace > > with "current" in at least the way that the 2.2 kernels do (does > > this occur in later kernels?) should be corrected. > > > >Justin, "current" is a pointer to the current thread executing on the > >current processor under Linux. It has existed since day one of the > >Linux kernel and probably will exist till the end of it's life. > > > >I'm sure the BSD kernel has some similar bogosity :-) > > BSD has curproc, but that is considerably less likely to be > used in "inoccent code" than "current". I mean, "current what?". > It could be anything, current privledges, current process, current > thread, the current time... "buf, buffers, type, version" (of what ?) with FreeBSD kernel (if they still exist), but they are global variables, not macros. By the way, SYM-2, that is "FreeBSD sym back to Linux but still in FreeBSD":), clashed on Linux "current" as well. Reason is that the corresponding code was based on yours :) (as indicated in the sym driver source). I have changed "current" by "curr". This is as clear and has the advantage of scaling better with "user" and "goal" (4 characters each). tinfo.goal tinfo.user tinfo.curr Just a suggestion. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
On Wed, 13 Dec 2000, Justin T. Gibbs wrote: Date: Wed, 13 Dec 2000 20:56:08 -0700 From: "Justin T. Gibbs" [EMAIL PROTECTED] None-the-less, it seems to me that spamming the kernel namespace with "current" in at least the way that the 2.2 kernels do (does this occur in later kernels?) should be corrected. Justin, "current" is a pointer to the current thread executing on the current processor under Linux. It has existed since day one of the Linux kernel and probably will exist till the end of it's life. I'm sure the BSD kernel has some similar bogosity :-) BSD has curproc, but that is considerably less likely to be used in "inoccent code" than "current". I mean, "current what?". It could be anything, current privledges, current process, current thread, the current time... "buf, buffers, type, version" (of what ?) with FreeBSD kernel (if they still exist), but they are global variables, not macros. By the way, SYM-2, that is "FreeBSD sym back to Linux but still in FreeBSD":), clashed on Linux "current" as well. Reason is that the corresponding code was based on yours :) (as indicated in the sym driver source). I have changed "current" by "curr". This is as clear and has the advantage of scaling better with "user" and "goal" (4 characters each). tinfo.goal tinfo.user tinfo.curr Just a suggestion. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Signal 11 - the continuing saga
On Wed, 13 Dec 2000, Linus Torvalds wrote: > > > Ehh, I think I found it. > > Hint: "ptep_mkdirty()". > > Oops. > > I'll bet you $5 USD (and these days, that's about a gadzillion Euros) that Poor European Gérard as slim as 1.84 meter - 78 Kg these days. What about old days poor European Linus versus these days American Linus on these points ? ;-) > this explains it. Really ? :o) > Linus Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Signal 11 - the continuing saga
On Wed, 13 Dec 2000, Linus Torvalds wrote: Ehh, I think I found it. Hint: "ptep_mkdirty()". Oops. I'll bet you $5 USD (and these days, that's about a gadzillion Euros) that Poor European Gérard as slim as 1.84 meter - 78 Kg these days. What about old days poor European Linus versus these days American Linus on these points ? ;-) this explains it. Really ? :o) Linus Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: pdev_enable_device no longer used ?
On Tue, 12 Dec 2000, David S. Miller wrote: >Date: Tue, 12 Dec 2000 20:17:21 +0100 (CET) >From: Gérard Roudier <[EMAIL PROTECTED]> > >On Mon, 11 Dec 2000, David S. Miller wrote: > >> Tell me one valid use of this information first :-) > >SCRIPTS. Have a look into my kind :-) response to Martin. > > Ok, this I understand. > >> b) If you wish to interpret the BAR values and use them from a BUS >>perspective somehow, you still need to go through some interface >>because you cannot assume what even the hw BAR values mean. >>This is precisely the kind of interface I am suggesting. > >The BAR values make FULL sense on the BUS. > > I am saying there may be systems where it does not make any sense, > f.e. actually used bits of BAR depend upon whether CPU, or DEVICE on > that bus, or DEVICE on some other bus make the access. > > Forget all the PCI specifications, it is irrelevant here. All your > PCI expertiece means nothing, nor mine. People build dumb machines > with "PCI implementations" and we need to handle them. Even the dumbest PCI implementation will keep with BAR relevance. Reason is that PCI devices are using BAR values and corresponding size to make decision about claiming or not a transaction as target. You can be as dump as you want with PCI, but not that much. :-) >I will wait for your .txt file that describes your idea. Your >documentation about the new DMA mapping had been extremally useful. >Let me thank you again for it. > > It requires no .txt file :-), No problems, a ".text" file would also fit just fine. :-) > it will just be formalization of > existing bus_to_dvma_whatever hack :-) Specify PDEV (device) and > RESNUM (which I/O or MEM resource for that device), returns either > error or address as seen by BUS that PDEV is on. You may offset > this return value as desired, up to the size of that resource. > > I could make a more elaborate interface (add new parameter, > PDEV_MASTER which is device which wishes to access area described by > PDEV+RESNUM), allowing full PCI peer-to-peer setup, as described by > someone else in another email of this thread. This version would have > an error return, since there will be peer2peer situations on some > systems which cannot be made. But I feel this is inappropriate until > 2.5.x, others can disagree. I saw the proposal. Btw, unlike the person, that proposed it, that will be able to test peer-to-peer unability only, my current machine will allow to test peer-to-peer ability only between 2 different PCI BUSes. :-) For now, my intention is to encapsulate the right interface as seen from my brain device in macros and forget about it until a new interface will be provided. I will first implement it on SYM-2 and backport changes to sym53c8xx later. And since I need the new major driver version to be tested on non-Intel platforms, this will make full synergy for the testings. :-) Bye, Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: pdev_enable_device no longer used ?
On Mon, 11 Dec 2000, David S. Miller wrote: >Date: Mon, 11 Dec 2000 23:07:01 +0100 (CET) >From: Gérard Roudier <[EMAIL PROTECTED]> > >So, if you want to fix this insane PCI interface: > >1) Provide the _actual_ BARs values in the pci dev structure, otherwise > drivers that need them will have to deal with ugly hackery or access > explicitely the PCI configuration space. > > Tell me one valid use of this information first :-) SCRIPTS. Have a look into my kind :-) response to Martin. By the way, the genuine physical addresses, alias pcidev cookies, as seen from the CPU have exactly NO USE at all, except as input for ioremap(). Drivers can throw them away after that. So, given correct design they should not even have to deal with them. > a) If you want to use it to arrive at addresses MEM I/O operations >you need to go through something akin to ioremap() first anyways. ioremap() is the historical successor of vremap(). Without vremap(), it may well never have existed. > b) If you wish to interpret the BAR values and use them from a BUS >perspective somehow, you still need to go through some interface >because you cannot assume what even the hw BAR values mean. >This is precisely the kind of interface I am suggesting. The BAR values make FULL sense on the BUS. >Consider even just that top few bits of BAR values on some system >have some special meaning, and must be masked out before used from >PCI device side transactions. Perhaps these bits are interpreted >somehow at the host bridge when CPU accesses to device MEM or I/O >space are made. I argue not that this is compliant behavior, I >argue only that it is something idiots designing hardware will in >fact do. We have seen worse things occur. Now, subsequently, if >we start using raw BARs in drivers these systems (however important >or not important) will become difficult to impossible to support. >Here the blacklists will end up in your driver, which is where I >think both of us will agree they should not be :-) Read my reply to Martin on that point. >2) Provide an interface that accepts the PCI dev and the BAR offset as > input and that return somes cookie for read*/write* interface. > GiveMeSomeCookieForMmIo(pcidev, bar_offset). > > I do not understand why ioremap() is such a bletcherous interface > for you :-) You take resource in PDEV, add desired offset, and pass > it to ioremap(). What about this sequence requires you to take pain > killers? :-) It seems quite straightforward to me. I can live perfectly with ioremap(). :-)) > We do not want to expose physical BARs because you as a driver have > no way to portably interpret this information. On the other hand > if you tell us "Given PDEV resource X, plus offset Y, give me this > address in BUS space" we can do that and that is the interface that > makes sense and is implementable on all architectures. This is what > I am proposing for adding asm/pci.h > > Having people read and intepret BARs is not implementable on all > architecures (see discussion in (b) above). > > I guess there is some fundamental reason you do not like the kernel > trying to discourage access to physical BARs. This makes things so > much easier and cleaner, at least to me. > > I bet we end up in standstill here and ifdef hacks remain in symbios > drivers :-))) We will see... I will wait for your .txt file that describes your idea. Your documentation about the new DMA mapping had been extremally useful. Let me thank you again for it. Bye, Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
