I have a reproducible problem that somehow reading from /proc causes a
SCSI parity error.
When I am inside a chroot environment (on my IDE hard disk) with proc
mounted on /proc and execute the following script from / (of chroot)
-----------------------
#!/bin/sh
case "z$1" in
z) echo Finding
find . -path "./old-distro" -prune -or -path "./static" -prune -or -
path "./usr/src" -prune -or -type f -exec $0 {} \;
;;
*) strings $1 | grep -q /static || exit 0
echo '*************'$1'****************'
strings $1 | grep -A 3 -B 3 /static
;;
esac
exit 0
----------------------
and then (not concurrently, can be a minute later) access my SCSI hard
disk, I get
sym53c875-0: SCSI parity error detected: SCR1=132 DBC=1e000000 SBCL=26
sym53c875-0: restart (scsi reset).
sym53c875-0: Downloading SCSI SCRIPTS.
When I access my SCSI hard disk first and use the script afterwards (again
there can be some time in between), I get
sym53c875-0: SCSI parity error detected: SCR1=132 DBC=50000000 SBCL=0
sym53c875-0: SCSI parity error detected: SCR1=132 DBC=870b0000 SBCL=0
sym53c875-0:0: ERROR (81:0) (8-0-0) (f/95) @ (script 28:f31c0004).
sym53c875-0: script cmd = e21c0004
sym53c875-0: regdump: da 00 00 95 47 0f 00 0f 35 08 80 00 80 00 0f 02.
sym53c875-0: restart (scsi reset).
sym53c875-0: Downloading SCSI SCRIPTS.
I can repeat this as often as I want. The errors stop occuring when I
unmount /proc (inside chroot). I can only guess that somehow reading from
/proc (note that I forgot to prune /proc in the find command) causes the
error. Are there some files in /proc that are not safe for reading?
And why does it only occur in chroot?
The error occurs with my normal 2.2.17 kernel and with the 2.4.12-ac3
kernel. I have a Tekram DC 390U SCSI controller.
MSB
Linux version 2.2.17 (root@(none)) (gcc version 2.95.2 19991024 (release))
#1 Fri Feb 2 14:06:58 CET 2001
Detected 501122 kHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 999.42 BogoMIPS
Memory: 257900k/262128k available (940k kernel code, 412k reserved, 2808k
data, 68k init)
Dentry hash table entries: 32768 (order 6, 256k)
Buffer cache hash table entries: 262144 (order 8, 1024k)
Page cache hash table entries: 65536 (order 6, 256k)
CPU: L1 I Cache: 32K L1 D Cache: 32K
CPU: AMD-K6(tm) 3D processor stepping 0c
Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.35a (19990819) Richard Gooch ([email protected])
PCI: PCI BIOS revision 2.10 entry at 0xf0720
PCI: Using configuration type 1
PCI: Probing PCI hardware
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0 for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
TCP: Hash tables configured (ehash 262144 bhash 65536)
Starting kswapd v 1.5
Serial driver version 4.27 with no serial options enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
es1370: version v0.31 time 14:08:53 Feb 2 2001
es1370: found adapter at io 0xd800 irq 15
es1370: features: joystick off, line in, mic impedance 0
RAM disk driver initialized: 16 RAM disks of 4096K size
loop: registered device at major 7
Uniform Multi-Platform E-IDE driver Revision: 6.30
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
ALI15X3: IDE controller on PCI bus 00 dev 78
ALI15X3: chipset revision 193
ALI15X3: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xb800-0xb807, BIOS settings: hda:DMA, hdb:pio
ALI15X3: simplex device: DMA disabled
ide1: ALI15X3 Bus-Master DMA disabled (BIOS)
hda: ST340823A, ATA DISK drive
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: ST340823A, 38166MB w/512kB Cache, CHS=4865/255/63, UDMA(33)
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
sym53c8xx: at PCI bus 0, device 10, function 0
sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up)
sym53c8xx: 53c875 detected with Tekram NVRAM
sym53c875-0: rev=0x03, base=0xd6000000, io_port=0xd400, irq=12
sym53c875-0: Tekram format NVRAM, ID 7, Fast-20, Parity Checking
sym53c875-0: on-chip RAM at 0xd5800000
sym53c875-0: restart (scsi reset).
sym53c875-0: Downloading SCSI SCRIPTS.
scsi0 : sym53c8xx - version 1.3g
scsi : 1 host.
Vendor: IBM Model: DDRS-34560 Rev: S97B
Type: Direct-Access ANSI SCSI revision: 02
Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
Vendor: FUJITSU Model: M2513E Rev: 0040
Type: Optical Device ANSI SCSI revision: 02
Detected scsi removable disk sdb at scsi0, channel 0, id 1, lun 0
Vendor: TEAC Model: CD-ROM CD-532S Rev: 1.0A
Type: CD-ROM ANSI SCSI revision: 02
Detected scsi CD-ROM sr0 at scsi0, channel 0, id 3, lun 0
sym53c875-0-<0,0>: tagged command queue depth set to 8
scsi : detected 1 SCSI cdrom 2 SCSI disks total.
sym53c875-0-<3,*>: FAST-20 SCSI 20.0 MB/s (50 ns, offset 16)
sr0: scsi3-mmc drive: 0x/0x caddy
Uniform CD-ROM driver Revision: 3.11
sym53c875-0-<0,*>: FAST-20 SCSI 20.0 MB/s (50 ns, offset 15)
SCSI device sda: hdwr sector= 512 bytes. Sectors= 8925000 [4357 MB] [4.4
GB]
sym53c875-0-<1,*>: FAST-10 SCSI 10.0 MB/s (100 ns, offset 15)
sdb : READ CAPACITY failed.
sdb : status = 1, message = 00, host = 0, driver = 28
sdb : extended sense code = 2
sdb : block size assumed to be 512 bytes, disk size 1GB.
ne2k-pci.c:vpre-1.00e 5/27/99 D. Becker/P. Gortmaker
http://cesdis.gsfc.nasa.gov/linux/drivers/ne2k-pci.html
ne2k-pci.c: PCI NE2000 clone 'RealTek RTL-8029' at I/O 0xd000, IRQ 10.
eth0: RealTek RTL-8029 found at 0xd000, IRQ 10, 00:00:21:C6:1E:30.
Partition check:
sda: sda1 sda2 < sda5 sda6 sda7 >
sdb:scsidisk I/O error: dev 08:10, sector 0
unable to read partition table
hda: hda1 hda2
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 68k freed
Adding Swap: 72256k swap-space (priority -1)
strings uses obsolete /proc/pci interface
----
Indecision is the key to flexibility.
I bet it only happens when you're root and you read /proc/scsi/sym53c8xx/0
(or whatever in your case).
I had this discussion with G?rard Roudier and it's not a bug, rather a
feature...
So don't do it!
[email protected] ("Matthias Benkmann") writes:
> I have a reproducible problem that somehow reading from /proc causes a
> SCSI parity error.
>
> When I am inside a chroot environment (on my IDE hard disk) with proc
> mounted on /proc and execute the following script from / (of chroot)
>
> -----------------------
> #!/bin/sh
>
> case "z$1" in
> z) echo Finding
> find . -path "./old-distro" -prune -or -path "./static" -prune -or -
> path "./usr/src" -prune -or -type f -exec $0 {} \;
> ;;
> *) strings $1 | grep -q /static || exit 0
> echo '*************'$1'****************'
> strings $1 | grep -A 3 -B 3 /static
> ;;
> esac
>
> exit 0
> ----------------------
>
> and then (not concurrently, can be a minute later) access my SCSI hard
> disk, I get
>
> sym53c875-0: SCSI parity error detected: SCR1=132 DBC=1e000000 SBCL=26
> sym53c875-0: restart (scsi reset).
> sym53c875-0: Downloading SCSI SCRIPTS.
>
>
> When I access my SCSI hard disk first and use the script afterwards (again
> there can be some time in between), I get
>
> sym53c875-0: SCSI parity error detected: SCR1=132 DBC=50000000 SBCL=0
> sym53c875-0: SCSI parity error detected: SCR1=132 DBC=870b0000 SBCL=0
> sym53c875-0:0: ERROR (81:0) (8-0-0) (f/95) @ (script 28:f31c0004).
> sym53c875-0: script cmd = e21c0004
> sym53c875-0: regdump: da 00 00 95 47 0f 00 0f 35 08 80 00 80 00 0f 02.
> sym53c875-0: restart (scsi reset).
> sym53c875-0: Downloading SCSI SCRIPTS.
>
>
> I can repeat this as often as I want. The errors stop occuring when I
> unmount /proc (inside chroot). I can only guess that somehow reading from
> /proc (note that I forgot to prune /proc in the find command) causes the
> error. Are there some files in /proc that are not safe for reading?
> And why does it only occur in chroot?
>
> The error occurs with my normal 2.2.17 kernel and with the 2.4.12-ac3
> kernel. I have a Tekram DC 390U SCSI controller.
>
> MSB
>
> Linux version 2.2.17 (root@(none)) (gcc version 2.95.2 19991024 (release))
> #1 Fri Feb 2 14:06:58 CET 2001
> Detected 501122 kHz processor.
> Console: colour VGA+ 80x25
> Calibrating delay loop... 999.42 BogoMIPS
> Memory: 257900k/262128k available (940k kernel code, 412k reserved, 2808k
> data, 68k init)
> Dentry hash table entries: 32768 (order 6, 256k)
> Buffer cache hash table entries: 262144 (order 8, 1024k)
> Page cache hash table entries: 65536 (order 6, 256k)
> CPU: L1 I Cache: 32K L1 D Cache: 32K
> CPU: AMD-K6(tm) 3D processor stepping 0c
> Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
> Checking 'hlt' instruction... OK.
> POSIX conformance testing by UNIFIX
> mtrr: v1.35a (19990819) Richard Gooch ([email protected])
> PCI: PCI BIOS revision 2.10 entry at 0xf0720
> PCI: Using configuration type 1
> PCI: Probing PCI hardware
> Linux NET4.0 for Linux 2.2
> Based upon Swansea University Computer Society NET3.039
> NET4: Unix domain sockets 1.0 for Linux NET4.0.
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP
> TCP: Hash tables configured (ehash 262144 bhash 65536)
> Starting kswapd v 1.5
> Serial driver version 4.27 with no serial options enabled
> ttyS00 at 0x03f8 (irq = 4) is a 16550A
> ttyS01 at 0x02f8 (irq = 3) is a 16550A
> es1370: version v0.31 time 14:08:53 Feb 2 2001
> es1370: found adapter at io 0xd800 irq 15
> es1370: features: joystick off, line in, mic impedance 0
> RAM disk driver initialized: 16 RAM disks of 4096K size
> loop: registered device at major 7
> Uniform Multi-Platform E-IDE driver Revision: 6.30
> ide: Assuming 33MHz system bus speed for PIO modes; override with
> idebus=xx
> ALI15X3: IDE controller on PCI bus 00 dev 78
> ALI15X3: chipset revision 193
> ALI15X3: not 100% native mode: will probe irqs later
> ide0: BM-DMA at 0xb800-0xb807, BIOS settings: hda:DMA, hdb:pio
> ALI15X3: simplex device: DMA disabled
> ide1: ALI15X3 Bus-Master DMA disabled (BIOS)
> hda: ST340823A, ATA DISK drive
> ide: Assuming 33MHz system bus speed for PIO modes; override with
> idebus=xx
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> hda: ST340823A, 38166MB w/512kB Cache, CHS=4865/255/63, UDMA(33)
> Floppy drive(s): fd0 is 1.44M
> FDC 0 is a post-1991 82077
> sym53c8xx: at PCI bus 0, device 10, function 0
> sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up)
> sym53c8xx: 53c875 detected with Tekram NVRAM
> sym53c875-0: rev=0x03, base=0xd6000000, io_port=0xd400, irq=12
> sym53c875-0: Tekram format NVRAM, ID 7, Fast-20, Parity Checking
> sym53c875-0: on-chip RAM at 0xd5800000
> sym53c875-0: restart (scsi reset).
> sym53c875-0: Downloading SCSI SCRIPTS.
> scsi0 : sym53c8xx - version 1.3g
> scsi : 1 host.
> Vendor: IBM Model: DDRS-34560 Rev: S97B
> Type: Direct-Access ANSI SCSI revision: 02
> Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
> Vendor: FUJITSU Model: M2513E Rev: 0040
> Type: Optical Device ANSI SCSI revision: 02
> Detected scsi removable disk sdb at scsi0, channel 0, id 1, lun 0
> Vendor: TEAC Model: CD-ROM CD-532S Rev: 1.0A
> Type: CD-ROM ANSI SCSI revision: 02
> Detected scsi CD-ROM sr0 at scsi0, channel 0, id 3, lun 0
> sym53c875-0-<0,0>: tagged command queue depth set to 8
> scsi : detected 1 SCSI cdrom 2 SCSI disks total.
> sym53c875-0-<3,*>: FAST-20 SCSI 20.0 MB/s (50 ns, offset 16)
> sr0: scsi3-mmc drive: 0x/0x caddy
> Uniform CD-ROM driver Revision: 3.11
> sym53c875-0-<0,*>: FAST-20 SCSI 20.0 MB/s (50 ns, offset 15)
> SCSI device sda: hdwr sector= 512 bytes. Sectors= 8925000 [4357 MB] [4.4
> GB]
> sym53c875-0-<1,*>: FAST-10 SCSI 10.0 MB/s (100 ns, offset 15)
> sdb : READ CAPACITY failed.
> sdb : status = 1, message = 00, host = 0, driver = 28
> sdb : extended sense code = 2
> sdb : block size assumed to be 512 bytes, disk size 1GB.
> ne2k-pci.c:vpre-1.00e 5/27/99 D. Becker/P. Gortmaker
> http://cesdis.gsfc.nasa.gov/linux/drivers/ne2k-pci.html
> ne2k-pci.c: PCI NE2000 clone 'RealTek RTL-8029' at I/O 0xd000, IRQ 10.
> eth0: RealTek RTL-8029 found at 0xd000, IRQ 10, 00:00:21:C6:1E:30.
> Partition check:
> sda: sda1 sda2 < sda5 sda6 sda7 >
> sdb:scsidisk I/O error: dev 08:10, sector 0
> unable to read partition table
> hda: hda1 hda2
> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 68k freed
> Adding Swap: 72256k swap-space (priority -1)
> strings uses obsolete /proc/pci interface
>
>
>
> ----
> Indecision is the key to flexibility.
>
> -
> 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/
>
--
Mathieu Chouquet-Stringer E-Mail : [email protected]
It is exactly because a man cannot do a thing that he is a
proper judge of it.
-- Oscar Wilde
On 28 Nov 2001, at 14:13, Mathieu Chouquet-Stringer wrote:
> I bet it only happens when you're root and you read /proc/scsi/sym53c8xx/0
> (or whatever in your case).
>
> I had this discussion with G?rard Roudier and it's not a bug, rather a
> feature...
Care to elaborate? What happens when you read that file? And why does it
cause an error even when the disk is not currently being accessed? As I
said there can be considerable time between running my script and
accessing the disk. And why do I get different errors depending on whether
I access the disk before I run the script or run the script before I
access the disk?
MSB
----
Who is this General Failure,
and why is he reading my disk ?
Ok I found the mail in some archives: it does not happen with
/proc/scsi/sym... but with /proc/bus/pci/xx (it seems that it messes the
scsi chip).
Here the answer (note that as a regular user you can't read more than the
first 128 bytes):
http://groups.google.com/groups?hl=en&threadm=fa.fhj0sbv.1ans7qt%40ifi.uio.no&rnum=1&prev=/groups%3Fq%3Dsym53c8xx%2Bproc%2Bscsi%2Breset%2Blinux%2Bmathieu%26hl%3Den%26rnum%3D1%26selm%3Dfa.fhj0sbv.1ans7qt%2540ifi.uio.no
> Oh, I've forgotten another thing. If I do cat /proc/bus/pci/00/* when I'm
> root (and only root), I get scsi reset (especially when I'm copying big
> files). Is this a bug or a feature?
Both. :-)
You donnot want to read configuration space beyong byte 128 for chip
earlier than SYM53C896.
Regards,
G?rard.
[email protected] ("Matthias Benkmann") writes:
> On 28 Nov 2001, at 14:13, Mathieu Chouquet-Stringer wrote:
>
> > I bet it only happens when you're root and you read =
> /proc/scsi/sym53c8xx/0
> > (or whatever in your case).
> >=20
> > I had this discussion with G=E9rard Roudier and it's not a bug, =
> rather a
> > feature...
>
> Care to elaborate? What happens when you read that file? And why does =
> it=20
> cause an error even when the disk is not currently being accessed? As I =
>
> said there can be considerable time between running my script and=20
> accessing the disk. And why do I get different errors depending on =
> whether=20
> I access the disk before I run the script or run the script before I=20
> access the disk?
>
> MSB
>
> ----
> Who is this General Failure,
> and why is he reading my disk ?
>
> -
> 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/
>
--
Mathieu Chouquet-Stringer E-Mail : [email protected]
It is exactly because a man cannot do a thing that he is a
proper judge of it.
-- Oscar Wilde
This is a known issue that had been discussed in time, but no fix had been
considered worth to be applied by PCI et co maintainers.
Up to the sym53c895, the Symbios chips have IO registers mapped at offset
0x80 of the chip configuration space. When you blindly read /proc with
enough system priviledge, it happens that configuration space of all PCI
devices are read beyond this offset. Since some IO registers of the chip
have side effects on read, unpredicable behaviour does happen.
For once, Murphy's law does not apply to you:). The reading of the SBDL
(SCSI BUS DATA LINES) IO register of the chip causes a spurious SCSI
parity error to be detected by the sym53c8xx and let it decide to reset
everything, so limiting the risks of screwing up your file systems.
By the way, the reasons that made the PCI stuff leave users of
pre-sym53c895 chip run the risk of screwing up their file systems
inadvertandly when reading /proc was some nit-picking about PCI
specifications. Linux PCI guys decided that PCI configuration space
reading must not have side effects even if PCI specifications did not
explicitely stated so (Something like "configuration infers no side
effects" is nothing but an axiom).
It is clear that NCR/SYMBIOS ingenieers decision to map IO registers
windows in PCI configuration space was very unclever an idea, but it
didn't conflict with the PCI specifications that were existing at the time
such chips had been designed. Newer chips have had this misfeature fixed.
In result, avoid to blindly read from /proc on your system, or purchase a
HBA with a recent chip that doesn't expose to side effects on PCI
configuration reading.
G?rard.
On Wed, 28 Nov 2001, Matthias Benkmann wrote:
> I have a reproducible problem that somehow reading from /proc causes a
> SCSI parity error.
>
> When I am inside a chroot environment (on my IDE hard disk) with proc
> mounted on /proc and execute the following script from / (of chroot)
>
> -----------------------
> #!/bin/sh
>
> case "z$1" in
> z) echo Finding
> find . -path "./old-distro" -prune -or -path "./static" -prune -or -
> path "./usr/src" -prune -or -type f -exec $0 {} \;
> ;;
> *) strings $1 | grep -q /static || exit 0
> echo '*************'$1'****************'
> strings $1 | grep -A 3 -B 3 /static
> ;;
> esac
>
> exit 0
> ----------------------
>
> and then (not concurrently, can be a minute later) access my SCSI hard
> disk, I get
>
> sym53c875-0: SCSI parity error detected: SCR1=132 DBC=1e000000 SBCL=26
> sym53c875-0: restart (scsi reset).
> sym53c875-0: Downloading SCSI SCRIPTS.
>
>
> When I access my SCSI hard disk first and use the script afterwards (again
> there can be some time in between), I get
>
> sym53c875-0: SCSI parity error detected: SCR1=132 DBC=50000000 SBCL=0
> sym53c875-0: SCSI parity error detected: SCR1=132 DBC=870b0000 SBCL=0
> sym53c875-0:0: ERROR (81:0) (8-0-0) (f/95) @ (script 28:f31c0004).
> sym53c875-0: script cmd = e21c0004
> sym53c875-0: regdump: da 00 00 95 47 0f 00 0f 35 08 80 00 80 00 0f 02.
> sym53c875-0: restart (scsi reset).
> sym53c875-0: Downloading SCSI SCRIPTS.
>
>
> I can repeat this as often as I want. The errors stop occuring when I
> unmount /proc (inside chroot). I can only guess that somehow reading from
> /proc (note that I forgot to prune /proc in the find command) causes the
> error. Are there some files in /proc that are not safe for reading?
> And why does it only occur in chroot?
>
> The error occurs with my normal 2.2.17 kernel and with the 2.4.12-ac3
> kernel. I have a Tekram DC 390U SCSI controller.
>
> MSB
>
> Linux version 2.2.17 (root@(none)) (gcc version 2.95.2 19991024 (release))
> #1 Fri Feb 2 14:06:58 CET 2001
> Detected 501122 kHz processor.
> Console: colour VGA+ 80x25
> Calibrating delay loop... 999.42 BogoMIPS
> Memory: 257900k/262128k available (940k kernel code, 412k reserved, 2808k
> data, 68k init)
> Dentry hash table entries: 32768 (order 6, 256k)
> Buffer cache hash table entries: 262144 (order 8, 1024k)
> Page cache hash table entries: 65536 (order 6, 256k)
> CPU: L1 I Cache: 32K L1 D Cache: 32K
> CPU: AMD-K6(tm) 3D processor stepping 0c
> Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
> Checking 'hlt' instruction... OK.
> POSIX conformance testing by UNIFIX
> mtrr: v1.35a (19990819) Richard Gooch ([email protected])
> PCI: PCI BIOS revision 2.10 entry at 0xf0720
> PCI: Using configuration type 1
> PCI: Probing PCI hardware
> Linux NET4.0 for Linux 2.2
> Based upon Swansea University Computer Society NET3.039
> NET4: Unix domain sockets 1.0 for Linux NET4.0.
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP
> TCP: Hash tables configured (ehash 262144 bhash 65536)
> Starting kswapd v 1.5
> Serial driver version 4.27 with no serial options enabled
> ttyS00 at 0x03f8 (irq = 4) is a 16550A
> ttyS01 at 0x02f8 (irq = 3) is a 16550A
> es1370: version v0.31 time 14:08:53 Feb 2 2001
> es1370: found adapter at io 0xd800 irq 15
> es1370: features: joystick off, line in, mic impedance 0
> RAM disk driver initialized: 16 RAM disks of 4096K size
> loop: registered device at major 7
> Uniform Multi-Platform E-IDE driver Revision: 6.30
> ide: Assuming 33MHz system bus speed for PIO modes; override with
> idebus=xx
> ALI15X3: IDE controller on PCI bus 00 dev 78
> ALI15X3: chipset revision 193
> ALI15X3: not 100% native mode: will probe irqs later
> ide0: BM-DMA at 0xb800-0xb807, BIOS settings: hda:DMA, hdb:pio
> ALI15X3: simplex device: DMA disabled
> ide1: ALI15X3 Bus-Master DMA disabled (BIOS)
> hda: ST340823A, ATA DISK drive
> ide: Assuming 33MHz system bus speed for PIO modes; override with
> idebus=xx
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> hda: ST340823A, 38166MB w/512kB Cache, CHS=4865/255/63, UDMA(33)
> Floppy drive(s): fd0 is 1.44M
> FDC 0 is a post-1991 82077
> sym53c8xx: at PCI bus 0, device 10, function 0
> sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up)
> sym53c8xx: 53c875 detected with Tekram NVRAM
> sym53c875-0: rev=0x03, base=0xd6000000, io_port=0xd400, irq=12
> sym53c875-0: Tekram format NVRAM, ID 7, Fast-20, Parity Checking
> sym53c875-0: on-chip RAM at 0xd5800000
> sym53c875-0: restart (scsi reset).
> sym53c875-0: Downloading SCSI SCRIPTS.
> scsi0 : sym53c8xx - version 1.3g
> scsi : 1 host.
> Vendor: IBM Model: DDRS-34560 Rev: S97B
> Type: Direct-Access ANSI SCSI revision: 02
> Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
> Vendor: FUJITSU Model: M2513E Rev: 0040
> Type: Optical Device ANSI SCSI revision: 02
> Detected scsi removable disk sdb at scsi0, channel 0, id 1, lun 0
> Vendor: TEAC Model: CD-ROM CD-532S Rev: 1.0A
> Type: CD-ROM ANSI SCSI revision: 02
> Detected scsi CD-ROM sr0 at scsi0, channel 0, id 3, lun 0
> sym53c875-0-<0,0>: tagged command queue depth set to 8
> scsi : detected 1 SCSI cdrom 2 SCSI disks total.
> sym53c875-0-<3,*>: FAST-20 SCSI 20.0 MB/s (50 ns, offset 16)
> sr0: scsi3-mmc drive: 0x/0x caddy
> Uniform CD-ROM driver Revision: 3.11
> sym53c875-0-<0,*>: FAST-20 SCSI 20.0 MB/s (50 ns, offset 15)
> SCSI device sda: hdwr sector= 512 bytes. Sectors= 8925000 [4357 MB] [4.4
> GB]
> sym53c875-0-<1,*>: FAST-10 SCSI 10.0 MB/s (100 ns, offset 15)
> sdb : READ CAPACITY failed.
> sdb : status = 1, message = 00, host = 0, driver = 28
> sdb : extended sense code = 2
> sdb : block size assumed to be 512 bytes, disk size 1GB.
> ne2k-pci.c:vpre-1.00e 5/27/99 D. Becker/P. Gortmaker
> http://cesdis.gsfc.nasa.gov/linux/drivers/ne2k-pci.html
> ne2k-pci.c: PCI NE2000 clone 'RealTek RTL-8029' at I/O 0xd000, IRQ 10.
> eth0: RealTek RTL-8029 found at 0xd000, IRQ 10, 00:00:21:C6:1E:30.
> Partition check:
> sda: sda1 sda2 < sda5 sda6 sda7 >
> sdb:scsidisk I/O error: dev 08:10, sector 0
> unable to read partition table
> hda: hda1 hda2
> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 68k freed
> Adding Swap: 72256k swap-space (priority -1)
> strings uses obsolete /proc/pci interface
>
>
>
> ----
> Indecision is the key to flexibility.
>
> -
> 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/
>
>
From: G?rard Roudier <[email protected]>
Date: Wed, 28 Nov 2001 19:14:52 +0100 (CET)
This is a known issue that had been discussed in time, but no fix had been
considered worth to be applied by PCI et co maintainers.
Why not just put some bitmap pointer into the pci device
struct. If it is non-NULL, it specifies PCI config space
areas which have side-effects.
On Wed, 28 Nov 2001, David S. Miller wrote:
> From: G?rard Roudier <[email protected]>
> Date: Wed, 28 Nov 2001 19:14:52 +0100 (CET)
>
> This is a known issue that had been discussed in time, but no fix had been
> considered worth to be applied by PCI et co maintainers.
>
> Why not just put some bitmap pointer into the pci device
> struct. If it is non-NULL, it specifies PCI config space
> areas which have side-effects.
Or a simple offset beyond which reading data isn't desirable for whatever
reasons.
G?rard.
From: G?rard Roudier <[email protected]>
Date: Wed, 28 Nov 2001 20:51:01 +0100 (CET)
On Wed, 28 Nov 2001, David S. Miller wrote:
> Why not just put some bitmap pointer into the pci device
> struct. If it is non-NULL, it specifies PCI config space
> areas which have side-effects.
Or a simple offset beyond which reading data isn't desirable for
whatever reasons.
I do not think that is sufficient.
I have seen chips where only one single PCI config space word would
trigger problems, and it was due to a hw bug. The "offset beyond"
scheme would not allow to cover this case.
> Why not just put some bitmap pointer into the pci device
> struct. If it is non-NULL, it specifies PCI config space
> areas which have side-effects.
Why not avoid poking around in dangerous device spaces. We don't have a
bitmap to protect /dev/mem either. The problem is similar too, we have many
devices with config space beyond the guaranteed bytes that do fatal
things that are not driven directly by Linux - eg some bridges have acpi
stuff overlapping there.
A non root user can only touch the safe bytes
On Wed, 28 Nov 2001, David S. Miller wrote:
> From: G?rard Roudier <[email protected]>
> Date: Wed, 28 Nov 2001 20:51:01 +0100 (CET)
>
> On Wed, 28 Nov 2001, David S. Miller wrote:
>
> > Why not just put some bitmap pointer into the pci device
> > struct. If it is non-NULL, it specifies PCI config space
> > areas which have side-effects.
>
> Or a simple offset beyond which reading data isn't desirable for
> whatever reasons.
>
> I do not think that is sufficient.
>
> I have seen chips where only one single PCI config space word would
> trigger problems, and it was due to a hw bug. The "offset beyond"
> scheme would not allow to cover this case.
OK. I ignored that such weirdness existed.
G?rard.