Egbert Eich wrote: > Bo Brinkman writes: > > Several months ago I mentioned that tdfx soft-boot problems seem to have > > re-appeared. I haven't had time until now to poke around into it. > > > > The current behavior (linux kernel 2.4.18-10, XFree86 4.2.0-8 through > > 10/12/2002 CVS) is that whenever I try to softboot either my Voodoo3 > > 2000 or Voodoo3 3000, the entire OS goes down. We used to have this > > problem due to improper PCI code (see the archives). No log file ever > > gets saved, but when I start X remotely, this is what I get: > > Unfortunately this is completely useless. Please send a scanpci -v > output prior to starting X and one just before the BIOS is POSTed. > To do that you need to put a breakpoint into the code and run it > inside gdb. > See xc/programs/Xserver/hw/xfree86/DebuggingHints in the sources for > details.
Sorry if I'm being an idiot, but could you give me a bit more of a hint about where I should stop the execution? Is this in the TDFXProbe code or in the int10 module? I didn't find any comments in either place that made it totally obvious to me that the BIOS is about to be POSTed. ;) I can't seem to make the module-aware gdb work either, but I'll just add a call to one of the dummy break functions in the appropriate place, since I don't really need to dig around in gdb. FWIW, it looks like we are actually getting a SIGFPE, which is not what I expected... Also note that before X ever runs, this is what scanpci -v gives for this card: pci bus 0x0000 cardnum 0x0a function 0x00: vendor 0x121a device 0x0005 3Dfx Interactive, Inc. Voodoo 3 CardVendor 0x121a card 0x0036 (3Dfx Interactive, Inc. Voodoo3) STATUS 0x8090 COMMAND 0x0000 CLASS 0x03 0x00 0x00 REVISION 0x01 BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00 BASE0 0xc4000000 addr 0xc4000000 MEM BASE1 0xca000008 addr 0xca000000 MEM PREFETCHABLE BASE2 0x0000b001 addr 0x0000b000 I/O BASEROM 0xc9ff0000 addr 0xc9ff0000 not-decode-enabled MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x05 BYTE_0 0x01 BYTE_1 0x00 BYTE_2 0x00 BYTE_3 0x00 Notice that BASEROM doesn't look crazy like it used to... It used to be left set to 0xffff0000. I assume that something has changed in the kernel which causes the BASEROM to be set in this way, because 0xffff0000 is the default value, and I assume it would stay there unless intentionally changed. Here is the scanpci -v output for the primary card, for comparison (Note that it is an AGP card). pci bus 0x0001 cardnum 0x00 function 0x00: vendor 0x121a device 0x0005 3Dfx Interactive, Inc. Voodoo 3 CardVendor 0x121a card 0x003a (3Dfx Interactive, Inc. Voodoo3 AGP) STATUS 0x80b0 COMMAND 0x0003 CLASS 0x03 0x00 0x00 REVISION 0x01 BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00 BASE0 0xc6000000 addr 0xc6000000 MEM BASE1 0xce000008 addr 0xce000000 MEM PREFETCHABLE BASE2 0x0000d801 addr 0x0000d800 I/O BASEROM 0xcdff0000 addr 0xcdff0000 not-decode-enabled MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x0b BYTE_0 0x01 BYTE_1 0x00 BYTE_2 0x00 BYTE_3 0x00 I will post complete scanpci -v info once I figure out where to put my breakpoint to generate the other info that Egbert wanted. -- William "Bo" Brinkman [EMAIL PROTECTED] Princeton Computer Science http://www.derandomized.org/ -- You have to *live* in the Hilbert space! -- Prof. Andy Yao _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
