linux-kernel - Re: radeonfb and X800 cards

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 19 May 2007 22:33:58 +0200
From:	"Fabio Comolli" <fabio.comolli@...il.com>
To:	"Benjamin Herrenschmidt" <benh@...nel.crashing.org>
Cc:	"Luca Tettamanti" <kronos.it@...il.com>,
	"Daniel Drake" <dsd@...too.org>,
	"linux list" <linux-kernel@...r.kernel.org>, Jimmy.Jazz@....net
Subject: Re: radeonfb and X800 cards

Hi.
This patch does not work for me.
Relevant part of the dmesg output is:

< ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16
< radeonfb: Reference=27.00 MHz (RefDiv=7) Memory=330.00 Mhz, System=358.00 MHz
< Device driver i2c-0 lacks bus and class support for being resumed.
< Device driver i2c-1 lacks bus and class support for being resumed.
< Device driver i2c-2 lacks bus and class support for being resumed.
< Device driver i2c-3 lacks bus and class support for being resumed.
< i2c-adapter i2c-2: unable to read EDID block.
< i2c-adapter i2c-2: unable to read EDID block.
< i2c-adapter i2c-2: unable to read EDID block.
<  * Connector 1 is Internal Panel. Head 0, Monitor: LVDS Flat panel
(EDID probed)
<    ddc port: 0, dac: -1, tmds: -1
<  * Connector 2 is VGA. Head -1, Monitor: None
<    ddc port: 2, dac: 0, tmds: -1
< radeonfb: detected LVDS panel size from BIOS: 1280x800
< radeonfb: Dynamic Clock Power Management enabled
< radeonfb (0000:01:00.0): ATI Radeon VS

My card is:

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon
Mobility X700 (PCIE) (prog-if 00 [VGA])
        Subsystem: Hewlett-Packard Company Unknown device 309e
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at d0000000 (32-bit, prefetchable) [size=128M]
        I/O ports at 3000 [size=256]
        Memory at c8100000 (32-bit, non-prefetchable) [size=64K]
        [virtual] Expansion ROM at c8120000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 2
        Capabilities: [58] Express Endpoint IRQ 0
        Capabilities: [80] Message Signalled Interrupts: 64bit+
Queue=0/0 Enable-
        Capabilities: [100] Advanced Error Reporting

Please let me know if you need more details.
Regards,
Fabio

On 5/18/07, Benjamin Herrenschmidt <benh@...nel.crashing.org> wrote:
> On Thu, 2007-05-17 at 22:29 +0200, Fabio Comolli wrote:
>
> > Is there a reason why this patch can't go upstream?
>
> Yes. A change of that magnitude will most certainly introduce
> regressions. So we can either:
>
>  - Have it in -mm for monthes trying to iron out all of them (and we'll
> miss some). And struggle also since it's hard to track subtle
> regressions with very big patches.
>
>  - Have it split in smaller bits, which make it possible to bisect in
> case of problem, and thus find/correct problems much faster.
>
> That's my main issue with it at this point. But I'm ok going for route
> #1 provided that you guys are willing to help with tracking regressions
> down. That also mean I need to do some serious testing on powermacs
> since those rely very heavily on a working radeonfb.
>
> Ben.
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/