foner+x-forcedeth@media.mit.edu wrote: [restructured the mail to make it more readable] > As far as I can tell, this never went out to debbugs or anyone > named in the X-Debbugs-CC: line, so I'm sending directly. Thanks! > > [And if anyone receiving this knows either (a) that it -did- get > redistributed by debbugs, or (b) how to -get- it to go out, please > tell me and/or do so.] > > - - - Begin forwarded message - - - > > Date: Wed, 5 May 2004 16:39:18 -0400 (EDT) > From: foner+x-forcedeth@media.mit.edu > To: debbugs@bugs.debian.org > X-Debbugs-CC: XFree86@XFree86.Org, andrew@orbital.co.uk, c-d.hailfinger.kernel.2004@gmx.net > Subject: forcedeth breaks X in Debian-testing 2.4.25 on MSI K7N2 Delta-L mobo > > Summary: I can either have a network (with forcedeth loaded), or have > X start up. I cannot have both---although if I start X first, I can > then load forcedeth and bring up the network. What's going on? > > [Please keep me CC'ed on responses!] > > Details: > > [I can't put a useful Package/Version pseudoheader here because this > is some weird interaction between X and the forcedeth shipped in > Debian 2.4.25; there are 3 possibilities (kernel, forcedeth, X) > contending for which package I'm even talking about. I hope somebody > can help here. Note also that I can't even find a reasonable address > to which to report bugs in forcedeth---the best I could do is an You could have googled for "forcedeth". The first hit would have given you all the information you need. Quoting from there: | Send any reports to linux-kernel or netdev@oss.sgi.com and CC: | Carl-Daniel Hailfinger to get | the remaining issues fixed. > obviously short-term address of one of its maintainers and an address > of another author gleaned a random mailing list. Doesn't it have its > own buglist? Lots of googling has failed to turn one up and its Forcedeth is integrated into current 2.4 and 2.6, so there is no point in setting up a dedicated mailing list for it. > README doesn't say. This seems weird for something that's important Forcedeth has a README? Why has nobody told me so or sent it upstream? > enough to be shipped as part of Debian.] > > [I sent this to debian-user on 4/17 and, even though I see it went > out, I received zero replies, so I'm resending to debbugs, the XFree86 > buglist, and the maintainers, in the hope that -somebody- has seen > this before. Please keep me CC'ed on replies!] > > I just started running Debian-testing 2.4.25 on an MSI K7N2 Delta-L > motherboard. The installer ran fine, and then I discovered that the > network failed to come up when I rebooted. I quickly discovered bug > 239076, which pointed out that /etc/modutils/aliases was missing the > "alias eth0 forcedeth" that the installer originally wrote, but > putting that back in and running update-modules then made X fail to > start up. (In fact, before finding bug 239076, I'd manually done > "insmod forcedeth", "ifdown eth0", "ifup eth0" and then noticed a > little while later that X would no longer start up, but wrote it off > as a coincidence since I'd only booted once since the installer boot.) > [The installer was debian-sarge-netinst Beta 3 of March 30, 2004.] > > I'm now in the state where I can reliably cause X to not start if > forcedeth is loaded, and vice versa. Logfiles for both cases are > appended below. > > Does anyone know of a workaround? It looks like forcedeth is doing > something fishy that's breaking X's VESA handling. Googling for forcedeth only accesses the nForce nic. If that confuses the VESA BIOS code, the bug most probably is in the BIOS itself. > things mentioning the "vm86() syscall generated signal 4" message > in the XFree86 logfile hasn't turned up anything useful yet. And > I don't know if I should report this individually to the X and/or > forcedeth maintainers yet (and this version of X explicitly disclaims > support anyway; see logfile), or if this is fallout from a more > systemic bug, or if I should go through the pain of installing > nVidia's drivers instead (and I'd -really- rather not do that). > > [Yes, I know I could start X, then load forcedeth and have a network. > That's a bit klugier of a workaround than I was hoping for... Though, > annoying as it was that the aliases file was miswritten, I'm actually > very glad that it was! Otherwise X would simply have been mysteriously > broken such that it had -never- started on this machine and I'd have > had a much more enormous debugging space to explore to figure out why. > For once, I'm happy about an installer bug...] > > [Note also that I'm using the defaults that the installer picked when > I told it I had a flatpanel display. They're not quite right (for > example, it assumed 800x600 or something and this panel does more), > but I haven't bothered touching the XFree86 config file until the > forcedeth problem is resolved. I'm including it at the end, though > I doubt it has anything to do with the bug I'm reporting. It's a > borrowed video card that I won't be using in the real system and I > know next to nothing about it, hence my stab at just using the > installer's guessed defaults.] > > Logfiles follow. First, both versions of the XFree86 log. Next, > /var/log/messages -without- forcedeth loaded (e.g., the aliases line > removed from /etc/modules.conf) and then, so as not to drown people in > output, a diff of that with the next boot (where the eth0 line -is- in > modules.conf) [and with some irrelevances in the diff, plus the > ever-changing timestamps, removed] rather than the entire file again. > Xfree86.0.log (working version) attached, diff against non-working follows: --- Xfree86.0.log WITHOUT FORCEDETH LOADED: +++ Xfree86.0.log -WITH- FORCEDETH LOADED: @@ -65,7 +65,7 @@ ABI class: XFree86 Video Driver, version 0.6 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 -(II) PCI: stages = 0x03, oldVal1 = 0x8000110c, mode1Res1 = 0x80000000 +(II) PCI: stages = 0x03, oldVal1 = 0x00000000, mode1Res1 = 0x80000000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 10de,01e0 card 0000,0000 rev c1 class 06,00,00 hdr 80 (II) PCI: 00:00:1: chip 10de,01eb card 1462,5700 rev c1 class 05,00,00 hdr 80 @@ -346,880 +346,27 @@ (II) VESA(0): initializing int10 (II) VESA(0): Primary V_BIOS segment is: 0xc000 (WW) System lacks support for changing MTRRs -(II) VESA(0): VESA BIOS detected -(II) VESA(0): VESA VBE Version 1.2 -(II) VESA(0): VESA VBE Total Mem: 2048 kB -(II) VESA(0): VESA VBE OEM: STB PowerGraph 64 Video (Trio64V+) -(**) VESA(0): Depth 24, (--) framebuffer bpp 32 -(==) VESA(0): RGB weight 888 -(==) VESA(0): Default visual is TrueColor -(==) VESA(0): Using gamma correction (1.0, 1.0, 1.0) -(II) VESA(0): Searching for matching VESA mode(s): -[**** massive amounts of output snipped ****] +(EE) VESA(0): vm86() syscall generated signal 4. +(II) VESA(0): EAX=0x00004f00, EBX=0x00000000, ECX=0x00000000, EDX=0x00000000 +(II) VESA(0): ESP=0x00000ff8, EBP=0x00000000, ESI=0x00000000, EDI=0x00002000 +(II) VESA(0): CS=0x0001, SS=0x0100, DS=0x0040, ES=0x0000, FS=0x0000, GS=0x0000 +(II) VESA(0): EIP=0x0000010a, EFLAGS=0x00033202 +(II) VESA(0): code at 0x0000011a: + 63 35 01 05 01 04 ff ff ff 00 03 04 c0 a8 00 01 + 0f 16 6e 65 31 2e 63 6c 69 65 6e 74 32 2e 61 74 +(II) stack at 0x00001ff8: + 00 00 00 06 00 00 00 32 +(II) VESA(0): VESA BIOS not detected +(II) UnloadModule: "vesa" +(II) UnloadModule: "int10" +(II) UnloadModule: "vbe" +(EE) Screen(s) found, but none have a usable configuration. + +Fatal server error: +no screens found + +When reporting a problem related to a server crash, please send +the full server output, not just the last messages. +This can be found in the log file "/var/log/XFree86.0.log". +Please report problems to submit@bugs.debian.org. /var/log/messsages (working version) attached, diff against non-working follows: > @@ -3,7 +3,7 @@ > darkstar kernel: Inspecting /boot/System.map-2.4.25-1-386 > darkstar kernel: Loaded 18507 symbols from /boot/System.map-2.4.25-1-386. > darkstar kernel: Symbols match kernel version 2.4.25. > -darkstar kernel: Loaded 516 symbols from 19 modules. > +darkstar kernel: Loaded 520 symbols from 20 modules. > darkstar kernel: Linux version 2.4.25-1-386 (herbert@gondolin) (gcc version 3.3.2 (Debian)) #1 Tue Feb 24 08:11:13 EST 2004 > darkstar kernel: BIOS-provided physical RAM map: > darkstar kernel: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) > @@ -144,7 +144,9 @@ > darkstar kernel: usb-uhci.c: $Revision: 1.275 $ time 09:07:29 Feb 24 2004 > darkstar kernel: usb-uhci.c: High bandwidth mode enabled > darkstar kernel: usb-uhci.c: v1.275:USB Universal Host Controller Interface driver > -darkstar lpd[570]: restarted > +darkstar kernel: forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.22. > +darkstar kernel: eth0: forcedeth.c: subsystem: 01462:570c bound to 00:04.0 > +darkstar lpd[605]: restarted > darkstar kernel: Linux Kernel Card Services 3.1.22 > darkstar kernel: options: [pci] [cardbus] [pm] > darkstar kernel: isapnp: Scanning for PnP cards... XF86Config-4 attached. Regards, Carl-Daniel -- http://www.hailfinger.org/