[BUG] skge 0000:02:05: read data parity error

[BUG] skge 0000:02:05: read data parity error

[Oliver Pinter (Pintér Olivér)]

Hi All!

It is fully reproductable under 2.6.22.15, 2.6.23.13 (all tainted and
not tainted [4 different kernel] ) and 2 different PC:

[BUG] skge 0000:02:05: read data parity error
[BUG] skge 0000:02:05: read data parity error

steps:
1. login as root
2. start mc
3. cd /sys/bus/pci/drivers/skge/0000:02:05.0
4. press F3 (mcview) on resource0
5. the system hang up, without panic or bug ... only this message
printed 2x: [BUG] skge 0000:02:05: read data parity error

when I used cat for show what is in file , then bocome this message:
 cat: resource0: Input/output error
but the permissions is:
 -rw------- 1 root root 16384 2008-01-14 20:36 resource0

when I used mcview for show whats in file, then the system hang up,
and not reagiert neither for SysRQ-s, only for hard reset.

-----------

PC1.:
00:00.0 Host bridge [0600]: Intel Corporation 945G/GZ/P/PL Express
Memory Controller Hub [8086:2770] (rev 02)
00:01.0 PCI bridge [0604]: Intel Corporation 945G/GZ/P/PL Express PCI
Express Root Port [8086:2771] (rev 02)
00:1b.0 Audio device [0403]: Intel Corporation 82801G (ICH7 Family)
High Definition Audio Controller [8086:27d8] (rev 01)
00:1d.0 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family)
USB UHCI #1 [8086:27c8] (rev 01)
00:1d.1 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family)
USB UHCI #2 [8086:27c9] (rev 01)
00:1d.2 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family)
USB UHCI #3 [8086:27ca] (rev 01)
00:1d.3 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family)
USB UHCI #4 [8086:27cb] (rev 01)
00:1d.7 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family)
USB2 EHCI Controller [8086:27cc] (rev 01)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge
[8086:244e] (rev e1)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801GB/GR (ICH7 Family)
LPC Interface Bridge [8086:27b8] (rev 01)
00:1f.2 IDE interface [0101]: Intel Corporation 82801GB/GR/GH (ICH7
Family) Serial ATA Storage Controller IDE [8086:27c0] (rev 01)
00:1f.3 SMBus [0c05]: Intel Corporation 82801G (ICH7 Family) SMBus
Controller [8086:27da] (rev 01)
01:00.0 VGA compatible controller [0300]: nVidia Corporation GeForce
7300 GS [10de:01df] (rev a1)
02:01.0 Ethernet controller [0200]: Atheros Communications, Inc.
AR5212 802.11abg NIC [168c:0013] (rev 01)
02:05.0 Ethernet controller [0200]: Marvell Technology Group Ltd.
88E8001 Gigabit Ethernet Controller [11ab:4320] (rev 13)

PC2:
00:00.0 Host bridge [0600]: Intel Corporation 82875P/E7210 Memory
Controller Hub [8086:2578] (rev 02)
00:01.0 PCI bridge [0604]: Intel Corporation 82875P Processor to AGP
Controller [8086:2579] (rev 02)
00:06.0 System peripheral [0880]: Intel Corporation 82875P/E7210
Processor to I/O Memory Interface [8086:257e] (rev 02)
00:1d.0 USB Controller [0c03]: Intel Corporation 82801EB/ER
(ICH5/ICH5R) USB UHCI Controller #1 [8086:24d2] (rev 02)
00:1d.1 USB Controller [0c03]: Intel Corporation 82801EB/ER
(ICH5/ICH5R) USB UHCI Controller #2 [8086:24d4] (rev 02)
00:1d.7 USB Controller [0c03]: Intel Corporation 82801EB/ER
(ICH5/ICH5R) USB2 EHCI Controller [8086:24dd] (rev 02)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge
[8086:244e] (rev c2)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801EB/ER (ICH5/ICH5R)
LPC Interface Bridge [8086:24d0] (rev 02)
00:1f.1 IDE interface [0101]: Intel Corporation 82801EB/ER
(ICH5/ICH5R) IDE Controller [8086:24db] (rev 02)
00:1f.2 RAID bus controller [0104]: Intel Corporation 82801ER (ICH5R)
SATA Controller [8086:24df] (rev 02)
00:1f.3 SMBus [0c05]: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus
Controller [8086:24d3] (rev 02)
00:1f.5 Multimedia audio controller [0401]: Intel Corporation
82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller [8086:24d5] (rev 02)
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV350
AP [Radeon 9600] [1002:4150]
01:00.1 Display controller [0380]: ATI Technologies Inc RV350 AP
[Radeon 9600] (Secondary) [1002:4170]
02:05.0 Ethernet controller [0200]: 3Com Corporation 3c940
10/100/1000Base-T [Marvell] [10b7:1700] (rev 12)
02:0a.0 Ethernet controller [0200]: Atheros Communications, Inc.
AR5212/AR5213 Multiprotocol MAC/baseband processor [168c:0013] (rev
01)
-- 
Thanks,
Oliver

Re: [BUG] skge 0000:02:05: read data parity error

[Stephen Hemminger]

On Mon, 14 Jan 2008 20:57:49 +0100
"Oliver Pinter (Pintér Olivér)" <oliver.pntr@gmail.com> wrote:

> Hi All!
> 
> It is fully reproductable under 2.6.22.15, 2.6.23.13 (all tainted and
> not tainted [4 different kernel] ) and 2 different PC:
> 
> [BUG] skge 0000:02:05: read data parity error
> [BUG] skge 0000:02:05: read data parity error
> 
> steps:
> 1. login as root
> 2. start mc
> 3. cd /sys/bus/pci/drivers/skge/0000:02:05.0
> 4. press F3 (mcview) on resource0
> 5. the system hang up, without panic or bug ... only this message
> printed 2x: [BUG] skge 0000:02:05: read data parity error
> 

This is not a bug.

The hardware has some debug registers that if accessed cause a read
back to the host. Since this can point anywhere, it will cause errors
or system hang.

The point is don't do it.

-- 
Stephen Hemminger <stephen.hemminger@vyatta.com>

Re: [BUG] skge 0000:02:05: read data parity error

[Stephen Hemminger]

On Mon, 14 Jan 2008 20:57:49 +0100
"Oliver Pinter (Pintér Olivér)" <oliver.pntr@gmail.com> wrote:

> Hi All!
> 
> It is fully reproductable under 2.6.22.15, 2.6.23.13 (all tainted and
> not tainted [4 different kernel] ) and 2 different PC:
> 
> [BUG] skge 0000:02:05: read data parity error
> [BUG] skge 0000:02:05: read data parity error
> 
> steps:
> 1. login as root
> 2. start mc
> 3. cd /sys/bus/pci/drivers/skge/0000:02:05.0
> 4. press F3 (mcview) on resource0
> 5. the system hang up, without panic or bug ... only this message
> printed 2x: [BUG] skge 0000:02:05: read data parity error
> 

This is not a bug.

The hardware has some debug registers that if accessed cause a read
back to the host. Since this can point anywhere, it will cause errors
or system hang.

The point is don't do it.

-- 
Stephen Hemminger <stephen.hemminger@vyatta.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] skge 0000:02:05: read data parity error

[Adrian Bunk]

On Mon, Jan 14, 2008 at 12:52:00PM -0800, Stephen Hemminger wrote:
> On Mon, 14 Jan 2008 20:57:49 +0100
> "Oliver Pinter (Pintér Olivér)" <oliver.pntr@gmail.com> wrote:
> 
> > Hi All!
> > 
> > It is fully reproductable under 2.6.22.15, 2.6.23.13 (all tainted and
> > not tainted [4 different kernel] ) and 2 different PC:
> > 
> > [BUG] skge 0000:02:05: read data parity error
> > [BUG] skge 0000:02:05: read data parity error
> > 
> > steps:
> > 1. login as root
> > 2. start mc
> > 3. cd /sys/bus/pci/drivers/skge/0000:02:05.0
> > 4. press F3 (mcview) on resource0
> > 5. the system hang up, without panic or bug ... only this message
> > printed 2x: [BUG] skge 0000:02:05: read data parity error
> 
> This is not a bug.
> 
> The hardware has some debug registers that if accessed cause a read
> back to the host. Since this can point anywhere, it will cause errors
> or system hang.
> 
> The point is don't do it.

Is it really a good idea that _reading_ files under /sys can kill your 
machine?

That sounds like a huge trap for people debugging their machine (or e.g. 
forgetting to exclude /sys from their backup).

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [BUG] skge 0000:02:05: read data parity error

[Adrian Bunk]

On Mon, Jan 14, 2008 at 12:52:00PM -0800, Stephen Hemminger wrote:
> On Mon, 14 Jan 2008 20:57:49 +0100
> "Oliver Pinter (Pintér Olivér)" <oliver.pntr@gmail.com> wrote:
> 
> > Hi All!
> > 
> > It is fully reproductable under 2.6.22.15, 2.6.23.13 (all tainted and
> > not tainted [4 different kernel] ) and 2 different PC:
> > 
> > [BUG] skge 0000:02:05: read data parity error
> > [BUG] skge 0000:02:05: read data parity error
> > 
> > steps:
> > 1. login as root
> > 2. start mc
> > 3. cd /sys/bus/pci/drivers/skge/0000:02:05.0
> > 4. press F3 (mcview) on resource0
> > 5. the system hang up, without panic or bug ... only this message
> > printed 2x: [BUG] skge 0000:02:05: read data parity error
> 
> This is not a bug.
> 
> The hardware has some debug registers that if accessed cause a read
> back to the host. Since this can point anywhere, it will cause errors
> or system hang.
> 
> The point is don't do it.

Is it really a good idea that _reading_ files under /sys can kill your 
machine?

That sounds like a huge trap for people debugging their machine (or e.g. 
forgetting to exclude /sys from their backup).

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] skge 0000:02:05: read data parity error

[Greg KH]

On Mon, Jan 14, 2008 at 11:01:05PM +0200, Adrian Bunk wrote:
> On Mon, Jan 14, 2008 at 12:52:00PM -0800, Stephen Hemminger wrote:
> > On Mon, 14 Jan 2008 20:57:49 +0100
> > "Oliver Pinter (Pint??r Oliv??r)" <oliver.pntr@gmail.com> wrote:
> > 
> > > Hi All!
> > > 
> > > It is fully reproductable under 2.6.22.15, 2.6.23.13 (all tainted and
> > > not tainted [4 different kernel] ) and 2 different PC:
> > > 
> > > [BUG] skge 0000:02:05: read data parity error
> > > [BUG] skge 0000:02:05: read data parity error
> > > 
> > > steps:
> > > 1. login as root
> > > 2. start mc
> > > 3. cd /sys/bus/pci/drivers/skge/0000:02:05.0
> > > 4. press F3 (mcview) on resource0
> > > 5. the system hang up, without panic or bug ... only this message
> > > printed 2x: [BUG] skge 0000:02:05: read data parity error
> > 
> > This is not a bug.
> > 
> > The hardware has some debug registers that if accessed cause a read
> > back to the host. Since this can point anywhere, it will cause errors
> > or system hang.
> > 
> > The point is don't do it.
> 
> Is it really a good idea that _reading_ files under /sys can kill your 
> machine?

No, but mmapping them as root and then doing bad things with that data
isn't recommended :)

Note that this is a special file, just like the ones in /proc, that
provide a mmap interface into the pci card's resource.  This is nothing
new...

thanks,

greg k-h

Re: [BUG] skge 0000:02:05: read data parity error

[Oliver Pinter (Pintér Olivér)]

I think, it is a potential security breakpoint, when applications with
root permission its read, then a machine is freezed, or only i thin
it's?


-- 
Thanks,
Oliver

Re: [BUG] skge 0000:02:05: read data parity error

[Adrian Bunk]

On Mon, Jan 14, 2008 at 10:31:03PM +0100, Oliver Pinter (Pintér Olivér) wrote:
> I think, it is a potential security breakpoint, when applications with
> root permission its read, then a machine is freezed, or only i thin
> it's?

When you are root there are infinite ways to kill your machine, so 
there's nothing security related about this issue.

> Thanks,
> Oliver

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [BUG] skge 0000:02:05: read data parity error

[Greg KH]

On Mon, Jan 14, 2008 at 10:31:03PM +0100, Oliver Pinter (Pint?r Oliv?r) wrote:
> I think, it is a potential security breakpoint, when applications with
> root permission its read, then a machine is freezed, or only i thin
> it's?

I'm sorry, I don't quite understand what you are trying to say here.

Re: [BUG] skge 0000:02:05: read data parity error

[Oliver Pinter (Pintér Olivér)]

On 1/14/08, Adrian Bunk <bunk@kernel.org> wrote:
> On Mon, Jan 14, 2008 at 10:31:03PM +0100, Oliver Pinter (Pintér Olivér)
> wrote:
> > I think, it is a potential security breakpoint, when applications with
> > root permission its read, then a machine is freezed, or only i thin
> > it's?
>
> When you are root there are infinite ways to kill your machine, so
> there's nothing security related about this issue.

Yes, i know, but when some application or daemons read some file with
running root privileges, then ...


thanks, then it is only a "feature" and not bug.
>
> > Thanks,
> > Oliver
>
> cu
> Adrian
>
> --
>
>        "Is there not promise of rain?" Ling Tan asked suddenly out
>         of the darkness. There had been need of rain for many days.
>        "Only a promise," Lao Er said.
>                                        Pearl S. Buck - Dragon Seed
>
>


-- 
Thanks,
Oliver

Re: [BUG] skge 0000:02:05: read data parity error

[Oliver Pinter (Pintér Olivér)]

On 1/14/08, Greg KH <gregkh@suse.de> wrote:
> On Mon, Jan 14, 2008 at 10:31:03PM +0100, Oliver Pinter (Pint?r Oliv?r)
> wrote:
> > I think, it is a potential security breakpoint, when applications with
> > root permission its read, then a machine is freezed, or only i thinK
> > it's?
>
> I'm sorry, I don't quite understand what you are trying to say here.
>

huh, sorry, it's typo and i'm not learn english,  only myself ... and
my spelling is very bad, sorry

-- 
Thanks,
Oliver

Re: [BUG] skge 0000:02:05: read data parity error

[Greg KH]

On Mon, Jan 14, 2008 at 10:41:52PM +0100, Oliver Pinter (Pint?r Oliv?r) wrote:
> On 1/14/08, Adrian Bunk <bunk@kernel.org> wrote:
> > On Mon, Jan 14, 2008 at 10:31:03PM +0100, Oliver Pinter (Pint?r Oliv?r)
> > wrote:
> > > I think, it is a potential security breakpoint, when applications with
> > > root permission its read, then a machine is freezed, or only i thin
> > > it's?
> >
> > When you are root there are infinite ways to kill your machine, so
> > there's nothing security related about this issue.
> 
> Yes, i know, but when some application or daemons read some file with
> running root privileges, then ...

It's always been that way, this is nothing new.

thanks,

greg k-h

Re: [BUG] skge 0000:02:05: read data parity error

[Adrian Bunk]

On Mon, Jan 14, 2008 at 10:41:52PM +0100, Oliver Pinter (Pintér Olivér) wrote:
> On 1/14/08, Adrian Bunk <bunk@kernel.org> wrote:
> > On Mon, Jan 14, 2008 at 10:31:03PM +0100, Oliver Pinter (Pintér Olivér)
> > wrote:
> > > I think, it is a potential security breakpoint, when applications with
> > > root permission its read, then a machine is freezed, or only i thin
> > > it's?
> >
> > When you are root there are infinite ways to kill your machine, so
> > there's nothing security related about this issue.
> 
> Yes, i know, but when some application or daemons read some file with
> running root privileges, then ...
> 
> thanks, then it is only a "feature" and not bug.

It might be a bug in the application.

But there are worse things than crashing your machine (e.g. getting your 
/etc/shadow) that can happen when someone with bad intentions can read 
files with root privileges.

> Thanks,
> Oliver

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [BUG] skge 0000:02:05: read data parity error

[Oliver Pinter (Pintér Olivér)]

I "tested" other devices resources file, and only with skge freezed
the system. from this think, that is skge driver bug

-- 
Thanks,
Oliver

Re: [BUG] skge 0000:02:05: read data parity error

[Stephen Hemminger]

On Mon, 14 Jan 2008 22:58:51 +0100
"Oliver Pinter (Pintér Olivér)" <oliver.pntr@gmail.com> wrote:

> I "tested" other devices resources file, and only with skge freezed
> the system. from this think, that is skge driver bug
> 

Its a property of the hardware, and the current device model has
no way to stop it.  Other devices are worse and can die if you access
pci config space.




-- 
Stephen Hemminger <stephen.hemminger@vyatta.com>