Re: Exposing ROM's though sysfs

Re: Exposing ROM's though sysfs

[Jon Smirl]

--- Torrey Hoffman <thoffman@arnor.net> wrote:
> This sounds interesting, but I'm curious...  why?  That is, what
> problem are you solving by making ROMs exposed?
> 
> Or is this just for fun?  (That's a legitimate reason IMO...)

Secondary video cards need to have code in their ROMs run to reset
them. When an x86 PC boots it only reset the primary video device, the
secondary ones won't work until their ROMs are run.

Another group needing this is laptop suspend/resume. Some cards won't
come back from suspend until their ROM is run to reinitialize them.

A third group is undocumented video hotware where the only way to set
the screen mode is by calling INT10 in the video ROMs. (Intel
i810,830,915 for example).

Small apps are attached to the hotplug events. These apps then use vm86
or emu86 to run the ROMs. emu86 is needed for ia64 or ppc when running
x86 ROMs on them.

=====
Jon Smirl
jonsmirl@yahoo.com


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail

Re: Exposing ROM's though sysfs

[Vojtech Pavlik]

On Fri, Jul 30, 2004 at 10:24:33AM -0700, Jon Smirl wrote:
> --- Torrey Hoffman <thoffman@arnor.net> wrote:
> > This sounds interesting, but I'm curious...  why?  That is, what
> > problem are you solving by making ROMs exposed?
> > 
> > Or is this just for fun?  (That's a legitimate reason IMO...)
> 
> Secondary video cards need to have code in their ROMs run to reset
> them. When an x86 PC boots it only reset the primary video device, the
> secondary ones won't work until their ROMs are run.
> 
> Another group needing this is laptop suspend/resume. Some cards won't
> come back from suspend until their ROM is run to reinitialize them.

Another trick laptops can do is that after a resume the card is in
uninitialized state _and_ the video ROM is not there, because the system
BIOS didn't copy it to the right location (when it's stored in a shared
flash). Then you definitely need your own copy from the real boot.

> A third group is undocumented video hotware where the only way to set
> the screen mode is by calling INT10 in the video ROMs. (Intel
> i810,830,915 for example).
> 
> Small apps are attached to the hotplug events. These apps then use vm86
> or emu86 to run the ROMs. emu86 is needed for ia64 or ppc when running
> x86 ROMs on them.

I'm starting to think that using emu86 always (independent on the
architecture) would be best. It's not like the execution speed is the
limit with video init, and it'll allow to find more bugs in emu86 when
it's used on i386 as well. It'll be needed for x86-64 (AMD64 and intel
EM64T) anyway.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Exposing ROM's though sysfs

[Jesse Barnes]

On Friday, July 30, 2004 12:14 pm, Vojtech Pavlik wrote:
> I'm starting to think that using emu86 always (independent on the
> architecture) would be best. It's not like the execution speed is the
> limit with video init, and it'll allow to find more bugs in emu86 when
> it's used on i386 as well. It'll be needed for x86-64 (AMD64 and intel
> EM64T) anyway.

Yeah, I was thinking the same thing, but emu86 needs some fixes to work on an 
x86 host apparently...

Jesse

Re: Exposing ROM's though sysfs

[Alan Cox]

On Gwe, 2004-07-30 at 21:26, Jesse Barnes wrote:
> On Friday, July 30, 2004 12:14 pm, Vojtech Pavlik wrote:
> > I'm starting to think that using emu86 always (independent on the
> > architecture) would be best. It's not like the execution speed is the
> > limit with video init, and it'll allow to find more bugs in emu86 when
> > it's used on i386 as well. It'll be needed for x86-64 (AMD64 and intel
> > EM64T) anyway.
> 
> Yeah, I was thinking the same thing, but emu86 needs some fixes to work on an 
> x86 host apparently...

emu86 is rather buggy. It can't boot C&T BIOSes for example. qemu might
be a better engine for this anyway in truth.

Re: Exposing ROM's though sysfs

[Benjamin Herrenschmidt]

> emu86 is rather buggy. It can't boot C&T BIOSes for example. qemu might
> be a better engine for this anyway in truth.

And I like the idea of chosing a solution that won't limit us to x86 hosts
anyway ;)

With proper support from the "VGA arbitration driver" that Jon talked about
earlier, that should be quite portable, the kernel driver doing the job of
providing PIO accessors to VGA space and mmap functionality for VGA memory
hole if it exist (can modern cards be POST'ed with an x86 BIOS on machines
that won't let you access any VGA memory hole, that is that won't let you
generate PCI memory cycles to low addresses that overlap RAM ? If yes, then
pmacs would be able to soft-boot x86 cards that way).

Ben.

Re: Exposing ROM's though sysfs

[Jesse Barnes]

On Tuesday, August 3, 2004 2:41 pm, Benjamin Herrenschmidt wrote:
> > emu86 is rather buggy. It can't boot C&T BIOSes for example. qemu might
> > be a better engine for this anyway in truth.
>
> And I like the idea of chosing a solution that won't limit us to x86 hosts
> anyway ;)

Yeah, me too!

> With proper support from the "VGA arbitration driver" that Jon talked about
> earlier, that should be quite portable, the kernel driver doing the job of
> providing PIO accessors to VGA space and mmap functionality for VGA memory
> hole if it exist (can modern cards be POST'ed with an x86 BIOS on machines
> that won't let you access any VGA memory hole, that is that won't let you
> generate PCI memory cycles to low addresses that overlap RAM ? If yes, then
> pmacs would be able to soft-boot x86 cards that way).

So you can do port I/O on low addresses but not memory accesses?  For some 
cards simply throwing away reads and writes to the low memory area is 
probably ok since it'll just be doing things like printing a BIOS banner or a 
pretty logo.  But then again, I've never disassembled one so I can't be sure.  
Alan would probably know though :)

If you can't do legacy port I/O on a given bus though, I think you'd be out of 
luck wrt POSTing a card with an x86 BIOS.

Jesse

Re: Exposing ROM's though sysfs

[Benjamin Herrenschmidt]

> So you can do port I/O on low addresses but not memory accesses?  For some 
> cards simply throwing away reads and writes to the low memory area is 
> probably ok since it'll just be doing things like printing a BIOS banner or a 
> pretty logo.  But then again, I've never disassembled one so I can't be sure.  
> Alan would probably know though :)

Yes, typically, on Apple north bridges, you have the PIO space memory
mapped somewhere in the CPU address space, generating IO cycles from 0
to N (usually 16Mb), but the MMIO space is directly mapped 1:1 from
0x8000000.

> If you can't do legacy port I/O on a given bus though, I think you'd be out of 
> luck wrt POSTing a card with an x86 BIOS.

Port IO should be fine in most cases (there might be one or 2 weird cases
with earlier models, but overall, it's fine). The typical case is a machine
using Apple "UniNorth" chipset (the one that supports AGP, been out for a while
now), since the AGP slot and the PCI bus are on 2 separate domains. Both can
do Port IO at any low address, but they are completely separate domains.

All this could be very nicely dealt with by the kernel driver.

Ben.

Re: legacy VGA device requirements (was: Exposing ROM's though sysfs)

[Jesse Barnes]

On Tuesday, August 3, 2004 5:59 pm, Benjamin Herrenschmidt wrote:
> All this could be very nicely dealt with by the kernel driver.

So what requirements have we collected so far?

  o device selection (presumably domain, bus, slot, function)
    i.e. select the device you'd like to manipulate
    ioctl?
  o per-domain & device VGA enable/disable
    need to disable VGA ports on cards in the same domain and/or bus
    ioctl?
  o legacy port I/O
    for properly routing I/O in multi-domain machines and machines where the
    kernel or firmware may need to trap master aborts
    read/write?
  o legacy memory mapping
    for mapping the legacy VGA framebuffer, may fail
    mmap?

Is that a complete list?  Of course, the interface mechanisms are up for 
debate too.  We might be able to do it with per-bus or per-domain files in 
sysfs for the legacy I/O and memory stuff, but that might not represent the 
fact that legacy devices have interdependencies very well (e.g. VGA ports 
must be disabled on device A before we poke device B, etc.).

Thanks,
Jesse

Re: Exposing ROM's though sysfs

[Jon Smirl]

Ben, can you put together a first pass on a "VGA arbitration driver"?
You probably know more about the quirks necessary on non-x86 platforms
than anyone else. I can help from the desktop x86 side but I've never
worked on high end hardware that allows things like multiple active VGA
devices. I'm sure the Mac machines and ia64 systems will need some
special code too.


=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

Re: Exposing ROM's though sysfs

[Benjamin Herrenschmidt]

On Wed, 2004-08-04 at 11:37, Jon Smirl wrote:
> Ben, can you put together a first pass on a "VGA arbitration driver"?
> You probably know more about the quirks necessary on non-x86 platforms
> than anyone else. I can help from the desktop x86 side but I've never
> worked on high end hardware that allows things like multiple active VGA
> devices. I'm sure the Mac machines and ia64 systems will need some
> special code too.

At this point, even the kernel doesn't have internally the necessary
platform hooks for dealing with multi domains legacy port IOs or
VGA memory space, it's all plaform hacks. But we can define an API at
least for userland and fix the kernel driver afterward.

I'm fairly busy this week, so it would be nice if you guys could come
up with some rough idea of the API you think the kernel driver should
provide (a /dev entry with ioctl's ? Linus won't be too happy ... something
in sysfs ?) and I can sit down & code something hopefully next week end
and/or next week.

Jesse did a pretty good summary of what features need to be provided
though. Note also that this "arbitration" layer may also need an in-kernel
API for things like vgacon or whatever may want to "grab" access to the
VGA device.

I suggest that at this point, we don't try to bother with simultaneous
access to devices on separate PCI domains, but just use an in-kernel
semaphore to arbitrate the single user at a given point in time who "owns"
the VGA access, whatever bus it is on. So we need 2 things, both in-kernel
and for userland:

 - A way to identify a VGA device on a given bus. Could this be a PCI
ID (or in kernel a pci_dev ?). That would mean no support for non-PCI stuffs,
how bad would that be ? Or we can try to be more smart and have userland
pass an ID string that contains the bus type, leaving us with some room
for accomodation of crappy bus types (read: embedded).
Maybe we just need to add to any entry in sysfs that is a VGA device some
kind of "vga_token" attribute that contains a "magic string" to be then used
with the driver for identification purposes ? For in kernel, we then just
use the pci_dev, with a special case for "legacy non-PCI" VGA ?

 - Basic API for grabbing/releasing the VGA lock, passing a given ID. This
would both take the exclusive access lock, and "set" IOs to the given device
(enable IOs to it). The API doesn't prevent future implementation of per-domain
locks if we want to have some concurrency here, though I feel that's useless.
The kernel-side is simple, the userland side could be an ioctl (hrm....).
However, should it be blocking or of trylock kind ? I don't like the idea of
userland beeing able to block the kernel (vgacon or whoever else in the kernel
need to do legacy IOs). Also, some console drivers still need to run in
'atomic' environment, though we did move a lot of things down to normal
task protected by the console semaphore, the printk and blanking code path,
afaik, are still a problem. So a simple semaphore may not do the trick. We
could simply abuse the console sem instead for now as our VGA lock, which means
that an fb driver would alwyas be called with the lock already held... but then,
we still need a call to "set"  the current active VGA device while already
owning the lock... I liked the idea of having one single call doing both.
Alan, what is your opinion there ?

 - In kernel API for vga_inX/outX and vga mem access on a given device

 - Userland should use read/write for IOs imho, either to a /dev device
(with maybe an ioctl to switch between PIO and VGA mem, though mmap is
better for the later) or to some sysfs entry (in which case, can we add
mmap call to a sysfs attribute ? last time I looked, it wasn't simple).

Ben.
 

Re: Exposing ROM's though sysfs

[Jesse Barnes]

On Tuesday, August 3, 2004 6:57 pm, Benjamin Herrenschmidt wrote:
> Jesse did a pretty good summary of what features need to be provided
> though. Note also that this "arbitration" layer may also need an in-kernel
> API for things like vgacon or whatever may want to "grab" access to the
> VGA device.

Good point, I forgot about that.  Theoretically, as long as a device has been 
POSTed, vgacon should work just fine with some small tweaks on platforms that 
allow mapping of the VGA framebuffer.

> I suggest that at this point, we don't try to bother with simultaneous
> access to devices on separate PCI domains, but just use an in-kernel
> semaphore to arbitrate the single user at a given point in time who "owns"
> the VGA access, whatever bus it is on. So we need 2 things, both in-kernel
> and for userland:

Sounds good.  Cards usually POST pretty quickly, so that won't be a problem 
until someone puts 32 cards in a system (oh wait, that's not too far off :).

>  - A way to identify a VGA device on a given bus. Could this be a PCI
> ID (or in kernel a pci_dev ?). That would mean no support for non-PCI
> stuffs, how bad would that be ?

I personally don't care about anything but PCI, AGP and PCI-Express, but you 
make a good point about embedded stuff.

>  - Userland should use read/write for IOs imho, either to a /dev device
> (with maybe an ioctl to switch between PIO and VGA mem, though mmap is
> better for the later) or to some sysfs entry (in which case, can we add
> mmap call to a sysfs attribute ? last time I looked, it wasn't simple).

Yeah, that sounds reasonable.  I'd vote for a real device as opposed to sysfs 
files, for now at least.

Jesse

Re: legacy VGA device requirements (was: Exposing ROM's though sysfs)

[Jon Smirl]

What should the API for this look like? We could add a VGA={0/1}
attribute to all the VGA devices in sysfs.

But then how do you:
1) list all of the conflicting VGA devices in a domain?
2) turn off all the VGA devices in a domain?

We could build a bus like directory structure in /sys/class

/sys/class/vga/domain1/vga1/(device/driver/enable)
/sys/class/vga/domain1/vga2/(device/driver/enable)
/sys/class/vga/domain2/vga1/(device/driver/enable)
/sys/class/vga/domain2/vga2/(device/driver/enable)

Then add an enable attribute in the domain directories that would shut
off all of the subdevices.

/sys/class/vga/domain1/enable
/sys/class/vga/domain2/enable

But the vga driver is not going to be attached to a device. Is there an
easy way to build this is sysfs?

--- Jesse Barnes <jbarnes@engr.sgi.com> wrote:

> On Tuesday, August 3, 2004 5:59 pm, Benjamin Herrenschmidt wrote:
> > All this could be very nicely dealt with by the kernel driver.
> 
> So what requirements have we collected so far?
> 
>   o device selection (presumably domain, bus, slot, function)
>     i.e. select the device you'd like to manipulate
>     ioctl?
>   o per-domain & device VGA enable/disable
>     need to disable VGA ports on cards in the same domain and/or bus
>     ioctl?
>   o legacy port I/O
>     for properly routing I/O in multi-domain machines and machines
> where the
>     kernel or firmware may need to trap master aborts
>     read/write?
>   o legacy memory mapping
>     for mapping the legacy VGA framebuffer, may fail
>     mmap?
> 
> Is that a complete list?  Of course, the interface mechanisms are up
> for 
> debate too.  We might be able to do it with per-bus or per-domain
> files in 
> sysfs for the legacy I/O and memory stuff, but that might not
> represent the 
> fact that legacy devices have interdependencies very well (e.g. VGA
> ports 
> must be disabled on device A before we poke device B, etc.).
> 
> Thanks,
> Jesse
> 

=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

Re: legacy VGA device requirements (was: Exposing ROM's though sysfs)

[Jesse Barnes]

On Friday, August 13, 2004 8:53 am, Jon Smirl wrote:
> What should the API for this look like? We could add a VGA={0/1}
> attribute to all the VGA devices in sysfs.
>
> But then how do you:
> 1) list all of the conflicting VGA devices in a domain?
> 2) turn off all the VGA devices in a domain?
>
> We could build a bus like directory structure in /sys/class
>
> /sys/class/vga/domain1/vga1/(device/driver/enable)
> /sys/class/vga/domain1/vga2/(device/driver/enable)
> /sys/class/vga/domain2/vga1/(device/driver/enable)
> /sys/class/vga/domain2/vga2/(device/driver/enable)
>
> Then add an enable attribute in the domain directories that would shut
> off all of the subdevices.
>
> /sys/class/vga/domain1/enable
> /sys/class/vga/domain2/enable
>
> But the vga driver is not going to be attached to a device. Is there an
> easy way to build this is sysfs?

Maybe we need a display driver class?  Could we reuse the dri drivers for that 
purpose?

Jesse

Re: legacy VGA device requirements (was: Exposing ROM's though sysfs)

[Alan Cox]

On Gwe, 2004-08-13 at 16:53, Jon Smirl wrote:
> What should the API for this look like? We could add a VGA={0/1}
> attribute to all the VGA devices in sysfs.
> 
> But then how do you:
> 1) list all of the conflicting VGA devices in a domain?
> 2) turn off all the VGA devices in a domain?

1. Is part of the PCI specification since there is a PCI class for
VGA video devices. 2 follows naturally from 1

Re: legacy VGA device requirements (was: Exposing ROM's though sysfs)

[Alan Cox]

On Gwe, 2004-08-13 at 17:11, Jesse Barnes wrote:
> Maybe we need a display driver class?  Could we reuse the dri drivers for that 
> purpose?

Display and VGA devices do not correlate neatly. There are non VGA
devices we treat as video, and VGA devices we don't use when using the
hardware ourselves because its switched out of the video side (eg
on the Oxygen GMX)

Re: legacy VGA device requirements (was: Exposing ROM's though sysfs)

[Jon Smirl]

I know internally how to find the VGA cards using the PCI class. I
meant this in the context of how do you enumerate all of the VGA
devices in a domain from a user space app. What is the API for this?
What is the user space API for turning off all of the VGA devices in a
domain?

--- Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> On Gwe, 2004-08-13 at 16:53, Jon Smirl wrote:
> > What should the API for this look like? We could add a VGA={0/1}
> > attribute to all the VGA devices in sysfs.
> > 
> > But then how do you:
> > 1) list all of the conflicting VGA devices in a domain?
> > 2) turn off all the VGA devices in a domain?
> 
> 1. Is part of the PCI specification since there is a PCI class for
> VGA video devices. 2 follows naturally from 1
> 
> 


=====
Jon Smirl
jonsmirl@yahoo.com


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

Re: legacy VGA device requirements (was: Exposing ROM's though sysfs)

[Alan Cox]

On Sad, 2004-08-14 at 00:56, Jon Smirl wrote:
> I know internally how to find the VGA cards using the PCI class. I
> meant this in the context of how do you enumerate all of the VGA
> devices in a domain from a user space app. What is the API for this?
> What is the user space API for turning off all of the VGA devices in a
> domain?

I don't follow the logic behind the question. Once you have the vga
locking device then that needs to handle the vga on/off.

Re: legacy VGA device requirements (was: Exposing ROM's though sysfs)

[Jon Smirl]

What is the API that a user space apps will use to control the state of
VGA devices?

For example:
1) a standard device exposing IOCTLs needing an header file describing
it.
or 2) Building a new tree in /sys/class/vga that uses attributes to
control the state. you turn the device on by copying a '1' to the
attribute.

Once we pick sysfs or ioctl API, what should the full set of calls look
like?

--- Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> On Sad, 2004-08-14 at 00:56, Jon Smirl wrote:
> > I know internally how to find the VGA cards using the PCI class. I
> > meant this in the context of how do you enumerate all of the VGA
> > devices in a domain from a user space app. What is the API for
> this?
> > What is the user space API for turning off all of the VGA devices
> in a
> > domain?
> 
> I don't follow the logic behind the question. Once you have the vga
> locking device then that needs to handle the vga on/off.
> 
> 


=====
Jon Smirl
jonsmirl@yahoo.com


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Re: legacy VGA device requirements (was: Exposing ROM's though sysfs)

[Jon Smirl]

Attached is a real world reason why we need a VGA control device.
VesaFB loads and marks the VGA screen region as reserved. The driver
does not attach to any device.

My new radeon DRM driver load and says no one is using the radeon card,
so it can drive it. Radeon loads and fails. It can attach the PCI
device but it can't reserve the memory block.

The short term fix for this is to make VesaFB aware of the PCI ROM
patch. The PCI ROM patch makes it possible to identify the boot video
device. Once VesaFB can identify the boot video device it can properly
attach itself to both the device and memory. Then DRM radeon loads
after vesafb it will find the PCI device already has a driver attached
and revert back into stealth compatibility mode.

Long term we need the vga control device and a unified DRM/fbdev.

The immediate work around is to use the radeonfb driver instead of
vesafb. The radeonfb driver marks the PCI device in use and triggers
stealth mode in radeon.


--- Alex Romosan <romosan@sycorax.lbl.gov> wrote:
> To: Dave Airlie <airlied@linux.ie>
> CC: dri-devel@lists.sourceforge.net
> Subject: Re: r200 oops
> From: Alex Romosan <romosan@sycorax.lbl.gov>
> Date: Thu, 19 Aug 2004 17:59:51 -0700
> 
> Dave Airlie <airlied@linux.ie> writes:
> 
> > can you insert the module with drm_opts=debug option and see what
> it
> > says..
> 
> [drm] Debug messages ON
> ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 4 (level, low) -> IRQ 4
> [drm:radeon_register_regions] *ERROR* cannot reserve FB region
> Unable to handle kernel NULL pointer dereference at virtual address
> 00000000
>  printing eip:
> e1195520
> *pde = 00000000
> Oops: 0002 [#1]
> PREEMPT
> Modules linked in: radeon sd_mod scsi_mod autofs4 microcode aes_i586
> airo ehci_hcd uhci_hcd usbcore parport_pc parport irtty_sir sir_dev
> irda crc_ccitt joydev evdev nls_iso8859_1 ntfs yenta_socket
> CPU:    0
> EIP:    0060:[<e1195520>]    Not tainted
> EFLAGS: 00010246   (2.6.8.1)
> EIP is at radeon_stub_putminor+0x20/0x110 [radeon]
> eax: 00000000   ebx: 00000000   ecx: 00000000   edx: 00000000
> esi: 00000000   edi: ffffffea   ebp: dc479e6c   esp: dc479e5c
> ds: 007b   es: 007b   ss: 0068
> Process insmod (pid: 2118, threadinfo=dc478000 task=df6e0cd0)
> Stack: dc479e78 00000000 00000000 00000000 dc479e84 e1195913 e11a363a
> e11a00f3
>        00000000 e11ab9e0 dc479ed0 e1191488 e11a37f0 e119fed0 dc479eac
> c017c056
>        41254b8f dbbab424 db054540 00000000 e11a9e18 c15c9c00 00000000
> dbbab424
> Call Trace:
>  [<c010545a>] show_stack+0x7a/0x90
>  [<c01055d9>] show_registers+0x149/0x1a0
>  [<c010576d>] die+0x8d/0x100
>  [<c0114465>] do_page_fault+0x1e5/0x567
>  [<c01050f5>] error_code+0x2d/0x38
>  [<e1195913>] radeon_stub_unregister+0x33/0x60 [radeon]
>  [<e1191488>] drm_probe+0x208/0x270 [radeon]
>  [<c01cc9d9>] pci_device_probe_static+0x49/0x60
>  [<c01cca27>] __pci_device_probe+0x37/0x50
>  [<c01cca66>] pci_device_probe+0x26/0x50
>  [<c0211f75>] bus_match+0x35/0x70
>  [<c02120a9>] driver_attach+0x59/0x90
>  [<c021254c>] bus_add_driver+0x8c/0xb0
>  [<c0212a6b>] driver_register+0x2b/0x30
>  [<c01ccc99>] pci_register_driver+0x59/0x80
>  [<e0fee09d>] drm_init+0x9d/0xd7 [radeon]
>  [<c012e178>] sys_init_module+0xf8/0x210
>  [<c0104f4b>] syscall_call+0x7/0xb
> Code: c7 04 10 00 00 00 00 a1 f0 d7 1a e1 89 4c 10 04 a1 f0 d7 1a
>  Segmentation fault
> 
> > can you also send on lspci -v and the contents of /proc/iomem
> 
> lspci -v:
> 
> 0000:00:00.0 Host bridge: Intel Corp. 82855PM Processor to I/O
> Controller (rev 03)
> 	Subsystem: IBM: Unknown device 0529
> 	Flags: bus master, fast devsel, latency 0
> 	Memory at d0000000 (32-bit, prefetchable) [size=256M]
> 	Capabilities: [e4] #09 [f104]
> 	Capabilities: [a0] AGP version 2.0
> 
> 0000:00:01.0 PCI bridge: Intel Corp. 82855PM Processor to AGP
> Controller (rev 03) (prog-if 00 [Normal decode])
> 	Flags: bus master, 66MHz, fast devsel, latency 96
> 	Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
> 	I/O behind bridge: 00003000-00003fff
> 	Memory behind bridge: c0100000-c01fffff
> 	Prefetchable memory behind bridge: e0000000-e7ffffff
> 
> 0000:00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM
> (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) (prog-if 00
> [UHCI])
> 	Subsystem: IBM: Unknown device 052d
> 	Flags: bus master, medium devsel, latency 0, IRQ 4
> 	I/O ports at 1800 [size=32]
> 
> 0000:00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM
> (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) (prog-if 00
> [UHCI])
> 	Subsystem: IBM: Unknown device 052d
> 	Flags: bus master, medium devsel, latency 0, IRQ 9
> 	I/O ports at 1820 [size=32]
> 
> 0000:00:1d.2 USB Controller: Intel Corp. 82801DB/DBL/DBM
> (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) (prog-if 00
> [UHCI])
> 	Subsystem: IBM: Unknown device 052d
> 	Flags: bus master, medium devsel, latency 0, IRQ 6
> 	I/O ports at 1840 [size=32]
> 
> 0000:00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M)
> USB 2.0 EHCI Controller (rev 01) (prog-if 20 [EHCI])
> 	Subsystem: IBM: Unknown device 052e
> 	Flags: bus master, medium devsel, latency 0, IRQ 11
> 	Memory at c0000000 (32-bit, non-prefetchable) [size=1K]
> 	Capabilities: [50] Power Management version 2
> 	Capabilities: [58] #0a [2080]
> 
> 0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 81)
> (prog-if 00 [Normal decode])
> 	Flags: bus master, fast devsel, latency 0
> 	Bus: primary=00, secondary=02, subordinate=08, sec-latency=64
> 	I/O behind bridge: 00004000-00008fff
> 	Memory behind bridge: c0200000-cfffffff
> 	Prefetchable memory behind bridge: e8000000-efffffff
> 
> 0000:00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface
> Controller (rev 01)
> 	Flags: bus master, medium devsel, latency 0
> 
> 0000:00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA
> Storage Controller (rev 01) (prog-if 8a [Master SecP PriP])
> 	Subsystem: IBM: Unknown device 052d
> 	Flags: bus master, medium devsel, latency 0, IRQ 6
> 	I/O ports at <unassigned>
> 	I/O ports at <unassigned>
> 	I/O ports at <unassigned>
> 	I/O ports at <unassigned>
> 	I/O ports at 1860 [size=16]
> 	Memory at 20000000 (32-bit, non-prefetchable) [size=1K]
> 
> 0000:00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
> SMBus Controller (rev 01)
> 	Subsystem: IBM: Unknown device 052d
> 	Flags: medium devsel, IRQ 5
> 	I/O ports at 1880 [size=32]
> 
> 0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM
> (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)
> 	Subsystem: IBM: Unknown device 0537
> 	Flags: bus master, medium devsel, latency 0, IRQ 5
> 	I/O ports at 1c00 [size=256]
> 	I/O ports at 18c0 [size=64]
> 	Memory at c0000c00 (32-bit, non-prefetchable) [size=512]
> 	Memory at c0000800 (32-bit, non-prefetchable) [size=256]
> 	Capabilities: [50] Power Management version 2
> 
> 0000:00:1f.6 Modem: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
> AC'97 Modem Controller (rev 01) (prog-if 00 [Generic])
> 	Subsystem: IBM: Unknown device 0525
> 	Flags: bus master, medium devsel, latency 0, IRQ 5
> 	I/O ports at 2400 [size=256]
> 	I/O ports at 2000 [size=128]
> 	Capabilities: [50] Power Management version 2
> 
> 0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon
> R250 Lf [Radeon Mobility 9000 M9] (rev 02) (prog-if 00 [VGA])
> 	Subsystem: IBM: Unknown device 0531
> 	Flags: bus master, stepping, fast Back2Back, 66MHz, medium devsel,
> latency 66, IRQ 4
> 	Memory at e0000000 (32-bit, prefetchable) [size=128M]
> 	I/O ports at 3000 [size=256]
> 	Memory at c0100000 (32-bit, non-prefetchable) [size=64K]
> 	Capabilities: [58] AGP version 2.0
> 	Capabilities: [50] Power Management version 2
> 
> 0000:02:00.0 CardBus bridge: Texas Instruments PCI1520 PC card
> Cardbus Controller (rev 01)
> 	Subsystem: IBM ThinkPad T30/T40
> 	Flags: bus master, medium devsel, latency 168, IRQ 4
> 	Memory at b0000000 (32-bit, non-prefetchable) [size=4K]
> 	Bus: primary=02, secondary=03, subordinate=06, sec-latency=176
> 	Memory window 0: 20400000-207ff000 (prefetchable)
> 	Memory window 1: 20800000-20bff000
> 	I/O window 0: 00004000-000040ff
> 	I/O window 1: 00004400-000044ff
> 	16-bit legacy interface ports at 0001
> 
> 0000:02:00.1 CardBus bridge: Texas Instruments PCI1520 PC card
> Cardbus Controller (rev 01)
> 	Subsystem: IBM ThinkPad T30/T40
> 	Flags: bus master, medium devsel, latency 168, IRQ 5
> 	Memory at b1000000 (32-bit, non-prefetchable) [size=4K]
> 	Bus: primary=02, secondary=07, subordinate=0a, sec-latency=176
> 	Memory window 0: 20c00000-20fff000 (prefetchable)
> 	Memory window 1: 21000000-213ff000
> 	I/O window 0: 00004800-000048ff
> 	I/O window 1: 00004c00-00004cff
> 	16-bit legacy interface ports at 0001
> 
> 0000:02:01.0 Ethernet controller: Intel Corp. 82540EP Gigabit
> Ethernet Controller (Mobile) (rev 03)
> 	Subsystem: IBM PRO/1000 MT Mobile Connection
> 	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 4
> 	Memory at c0220000 (32-bit, non-prefetchable) [size=128K]
> 	Memory at c0200000 (32-bit, non-prefetchable) [size=64K]
> 	I/O ports at 8400 [size=64]
> 	Capabilities: [dc] Power Management version 2
> 	Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0
> Enable-
> 
> 0000:02:02.0 Network controller: AIRONET Wireless Communications
> Cisco Aironet Wireless 802.11b
> 	Subsystem: AIRONET Wireless Communications: Unknown device 5000
> 	Flags: bus master, fast devsel, latency 64, IRQ 6
> 	I/O ports at 8000 [size=256]
> 	Memory at c0210000 (32-bit, non-prefetchable) [size=16K]
> 	Memory at c0400000 (32-bit, non-prefetchable) [size=4M]
> 	Capabilities: [40] Power Management version 2
> 	Capabilities: [48] Vital Product Data
> 
> /proc/iomem:
> 
> 00000000-0009efff : System RAM
> 0009f000-0009ffff : reserved
> 000a0000-000bffff : Video RAM area
> 000c0000-000cffff : Video ROM
> 000e0000-000effff : Extension ROM
> 000f0000-000fffff : System ROM
> 00100000-1ff5ffff : System RAM
>   00100000-003056de : Kernel code
>   003056df-003dd13f : Kernel data
> 1ff60000-1ff76fff : ACPI Tables
> 1ff77000-1ff78fff : ACPI Non-volatile Storage
> 1ff80000-1fffffff : reserved
> 20000000-200003ff : 0000:00:1f.1
> 20400000-207fffff : PCI CardBus #03
> 20800000-20bfffff : PCI CardBus #03
> 20c00000-20ffffff : PCI CardBus #07
> 21000000-213fffff : PCI CardBus #07
> b0000000-b0000fff : 0000:02:00.0
>   b0000000-b0000fff : yenta_socket
> b1000000-b1000fff : 0000:02:00.1
>   b1000000-b1000fff : yenta_socket
> c0000000-c00003ff : 0000:00:1d.7
>   c0000000-c00003ff : ehci_hcd
> c0000800-c00008ff : 0000:00:1f.5
>   c0000800-c00008ff : Intel 82801DB-ICH4 - Controller
> c0000c00-c0000dff : 0000:00:1f.5
>   c0000c00-c0000dff : Intel 82801DB-ICH4 - AC'97
> c0100000-c01fffff : PCI Bus #01
>   c0100000-c010ffff : 0000:01:00.0
>     c0100000-c010ffff : radeon
> c0200000-c020ffff : 0000:02:01.0
>   c0200000-c020ffff : e1000
> c0210000-c0213fff : 0000:02:02.0
>   c0210000-c0213fff : eth1
> c0220000-c023ffff : 0000:02:01.0
>   c0220000-c023ffff : e1000
> c0400000-c07fffff : 0000:02:02.0
>   c0400000-c043ffff : eth1
> d0000000-dfffffff : 0000:00:00.0
> e0000000-e7ffffff : PCI Bus #01
>   e0000000-e7ffffff : 0000:01:00.0
>     e0000000-e059b8bf : vesafb
> ff800000-ffffffff : reserved
> 
> i am sending the laptop back to ibm so i won't be able to run any
> tests for a while. hope this helps.
> 
> --alex--
> 
> -- 
> | I believe the moment is at hand when, by a paranoiac and active |
> |  advance of the mind, it will be possible (simultaneously with  |
> |  automatism and other passive states) to systematize confusion  |
> |  and thus to help to discredit completely the world of reality. |
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank
> Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
> 

=====
Jon Smirl
jonsmirl@yahoo.com


		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

Re: legacy VGA device requirements (was: Exposing ROM's though sysfs)

[Vojtech Pavlik]

On Thu, Aug 19, 2004 at 09:46:35PM -0700, Jon Smirl wrote:
> Attached is a real world reason why we need a VGA control device.
> VesaFB loads and marks the VGA screen region as reserved. The driver
> does not attach to any device.
> 
> My new radeon DRM driver load and says no one is using the radeon card,
> so it can drive it. Radeon loads and fails. It can attach the PCI
> device but it can't reserve the memory block.
> 
> The short term fix for this is to make VesaFB aware of the PCI ROM
> patch. The PCI ROM patch makes it possible to identify the boot video
> device. Once VesaFB can identify the boot video device it can properly
> attach itself to both the device and memory. Then DRM radeon loads
> after vesafb it will find the PCI device already has a driver attached
> and revert back into stealth compatibility mode.

Well, the stealth compatibility mode is even uglier than VesaFB not
claiming the PCI device, so I don't think it's really worth it for this
reason.

You can just as well enable the stealth mode if you can't get the
resources.

> Long term we need the vga control device and a unified DRM/fbdev.

We really need that. And we need it to be able to kick VESAfb out using
sysfs when it loads. For that you'll need to make VESAfb grab the VGA
PCI device.

> The immediate work around is to use the radeonfb driver instead of
> vesafb. The radeonfb driver marks the PCI device in use and triggers
> stealth mode in radeon.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: legacy VGA device requirements (was: Exposing ROM's though sysfs)

[Jon Smirl]

--- Vojtech Pavlik <vojtech@suse.cz> wrote:
> Well, the stealth compatibility mode is even uglier than VesaFB not
> claiming the PCI device, so I don't think it's really worth it for
> this reason.

Stealth mode will die the minute DRM and fbdev merge but until then we
have no choice. DRM has always run in steath mode, the new feature is
the mode where DRM claims the resources.

> 
> You can just as well enable the stealth mode if you can't get the
> resources.

I'll go look and see if I can modify the DRM probe function to claim
PCI device and resources before returning instead of just the device.
Before this it never occured to me that a driver would claim resources
without also claiming the device. Claiming both should be a simpler
solution than trying to fix VesaFB.


=====
Jon Smirl
jonsmirl@yahoo.com


		
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

Re: legacy VGA device requirements (was: Exposing ROM's though sysfs)

[Alan Cox]

On Gwe, 2004-08-20 at 05:46, Jon Smirl wrote:
> Attached is a real world reason why we need a VGA control device.
> VesaFB loads and marks the VGA screen region as reserved. The driver
> does not attach to any device.

You'll love this: The vesafb device might not be a VGA device. In
certain modes the Weitek P9100 is an example of this as in higher modes
it turns off its inbuilt 5286 and flips to the P9x00 engine which is
nonvga.

> The short term fix for this is to make VesaFB aware of the PCI ROM
> patch. The PCI ROM patch makes it possible to identify the boot video
> device. Once VesaFB can identify the boot video device it can properly
> attach itself to both the device and memory. Then DRM radeon loads

Device yes, memory we already know. We currently don't register the
memory always because it may not be in the ISA/PCI space. However we can
certainly walk the bars now you can find the boot video device
and use that to see if the video memory reported by the VESA bios is
in any of them. The other complication is that we can't use the PCI
device level allocator here because some PCI devices have video and
other functionality on one chip. Not however a problem if you grab just
the single resource.

Alan