On Thu, 09 Dec 2004 Marc Aurele La France wrote :On Wed, 8 Dec 2004, ASIF IQBAL wrote:Some more inputs I gathered on the scanpci issue are as follows:
1) scanpci () crashing is not consistent all the time. After removing my fix, and with the build procedure suggested by you, once it executed without system crashing, for a longer duration. But it was running for half an hour or so never ending, until I killed the process using Ctrl-c. 2) When I tried connecting remotely to the sparc, it never gave me a consistent output. The best last few lines that I could get are given below (and is got through the visual observation only).
pciGenFindNext: pciDeviceTag = 0x100f800, devid = 0xffffffff pciGenFindNext: pciBusNum 256 pciGenFindNext: pciFuncNum 0 pciReadLong(0x100f800, 0) pciGenFindNext: next bus pciGenFindNext: pciBusInfo[257] = 0x891b0 pciGenFindNext: [257, 0, 0] pciReadLong(0x1010000, 0)
This I got with a slight delay placed in pciReadLong () function within the “if” condition. This delay was added by me to breath for some time to place the log output in the console.
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.
Note that I'm assumning `mmapr` is in your $PATH. It should have been installed as '/usr/X11R6/bin/mmapr'. Be very careful with this utility. Typographical errors in its use can be disastrous.
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.
If this works, i.e. no crash, I can then change the X server's (and scanpci's) bus scan to do the same thing and this problem will be solved.
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.
