Excellent. This seems to be implying that the bus scan is crashing the system when it gets around to probing what's behind your PCI bridge. To confirm this, the command ...
mmapr /dev/fbs/aperture 0x01FE01010000 4 > /dev/null
... (as root) should consistently crash the system. Does it?
Marc you are right. The system is crashed after the execution of the command. I have confirmed this behaviour by repeating twice.
Also, please do as root after a fresh reboot ...
mmapr /dev/fbs/aperture 0x01FE01002800 256 > pci5.dat
... and send me 'pci5.dat' as an attachment. This is a dump of the PCI bridge's configuration space (i.e. binary data), which hopefully will tell me what needs to be done to prevent the crash.
I have attached the pci5.dat binary as requested which is got by executing the mmap command. And this didn't have any effect (ie. no system crash). Can you elaborate the significance of the address for mmapr function.
`mmapr /dev/fbs/aperture` reads the CPU's physical address space. This address space is divided into various sub-areas (system memory, PCI configuration, PCI I/O, PCI memory, to name a few). In your case, PCI configuration space resides at displacement 0x01FE01000000 within this address space for a total length of 128KB. But, for some reason we are hopefully about to determine, the top 64K of this space is not accessible, and it should be.
As root, please do (_exactly_ as shown) ...
mmapw -b /dev/fbs/aperture 0x01FE01002864 0x7C mmapr /dev/fbs/aperture 0x01FE01010000 4 > /dev/null
... and tell me if the second command (the `mmapr`) still crashes your system. The `mmapw` is very important here. Its effect is to tell your PCI bridge to ignore most PCI errors that occur on its secondary bus segment.
Marc, still the system seems to crashing for the mmapr. I have executed first mampw followed by mmapr. I confirmed this beahviour by trying twice. Is there any way that I could confirm my mmapw of 0x7c is successfull using? Will this work "mmapr -b /dev/fbs/aperture 0x01FE01002864". If so were can I
To verify that the value was correctly written, you can pipe mmapr's stdout into /usr/bin/od, i.e. ...
mmapr -b /dev/fbs/aperture 0x01FE01002864 | /usr/bin/od -t x1
I should, at some point, change mmapr to optionally pretty-print its output.
see the read value ? In the console or else. I will stay today overnight so that I can try the steps suggested by you and reply you immedieatly. Please confirm me if you need, so that we can complete this issue and will allow me to proceed furter.
At this point, I need to ask you to install an adapter into one of the machine's PCI slots. Any adapter will do, as long as it's PCI of course. It doesn't even need to be a video adapter. The intent is to put an adapter behind the PCI bridge. If after installing this adapter, the command ...
mmapr /dev/fbs/aperture 0x01FE01010000 4 > /dev/null
... no longer crashes the system, then please send me the pci5.dat2 that results from ...
mmapr /dev/fbs/aperture 0x01FE01002800 256 > pci5.dat2
... and I'll compare that with the pci5.dat you've previously sent. I'll also need to see the updated `prtconf -Ppv` output.
Actually, come to think of it, the prtconf output would be useful whether or not installing the extra adapter crashes the system on the mmapr command.
Thanks.
Marc.
+----------------------------------+-----------------------------------+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax: 1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +-----------------------------------+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply | | CANADA | | +----------------------------------+-----------------------------------+ XFree86 developer and VP. ATI driver and X server internals. _______________________________________________ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
