The old Dell was running a four-year-old OS (SUSE Linux 9.3 Professional), which had its issues (couldn't run flash10, can't order printing online from kinkos.com, can't run ffox3). Not to mention the scorn heaped upon my computer by the ex-teen's Penguinista friend. Therefore, I thought I'd install the latest stable opensuse distro, which was a lot harder than it should have been. The NFS, printing, and sound were not a real huge issue, but having the box freeze (keyboard and mouse have no effect -- I mean NumLock doesn't even toggle the LED; ctrl-alt-backspace, ctrl-alt-f1, all useless -- can ping, can't ssh in) is quite frustrating.
I asked my Linux buddies at work. Is it a driver issue? I tried replacing "intel" (with quotes) by "fbdev" in xorg.conf -- got no graphics at all. That was easier than updating the BIOS, which I tried next.
No-Windows BIOS upgrade procedure
Careful observation during bootup told me that the GX270 was running the ancient A02 BIOS (short for April 2002??); the latest (and therefore greatest?) seems to be A07. But I had a problem: you're supposed to run this under ’doze :( Now I have a partition on the HDD marked HPFS/NTFS, but of course it has an ext2 filesystem on it. I really (I mean really) don't do windows on this box.The good news though was that this could be run under DOS, for example FreeDOS. Yippee! But wait. Suppose I burn the CD image onto a CD-R and run it in "live CD" mode. How do I get it to run GX270A07.EXE? I mean, I downloaded it to an ext2 or maybe a reiserfs filesystem, which DOS manifestly doesn't grok. (Smart-alecks out there may refrain from suggesting I write an ext2-to-FAT shim for FreeDOS.) I thought, OK, I'll put it on a floppy disk. I actually have a few of these lying around, and my not-so-trusty GX270 even has a floppy drive! Yippee!
But though I found several disks lying around, they mostly seem to hate the GX270's disk drive. I finally wrote the A07 file onto a floppy, and burned a FreeDOS CD. Oh joy!
Booted FreeDOS, and with the floppy in the drive, typed:
A:\> B:GX270A07.EXE
Nothing happened. Thinking no news was good news, I rebooted the box and wasn't too happy to see BIOS VERSION: A02 on the screen.What?? Then it occurred to me -- usually programs like this tell you to hit <ENTER> to confirm whatever operation. I saw nothing like that. What to do, what to do? Should I try to find a "good" floppy? Heck, I didn't even know if the floppy drive was any good! Maybe I could burn a CD with the BIOS upgrade on it?
Well, FreeDOS gives you the option of booting in real mode, HIMEM, and one other. At least one of those options lets you see the actual CD as the "X:" drive. "D'oh!" I said to myself. Booting the FreeDOS live CD means it's executing from RAM. I typed "dir X:" at the command prompt and got the actual contents of the CD. Another "D'oh!" -- the CD was DOS/windows compatible by virtue of having that iso9660 Joliet thing on it.
The thought then was: boot the FreeDOS CD "live" (I had no intention of installing DOS on my HDD -- where would I put it?) and run from RAM. Then eject that CD and put the GX270A07.EXE CD into the drive, and say "X:\GX270A07.EXE" at the command prompt.
Brilliant. I found a CD-RW blank and put the BIOS file onto it. Actually I had both A06 and A07....
Booted from the FreeDOS CD-ROM and typed "
DIR X;" and got "No such file". What?? In my haste I made a typo -- made the same typo several times in a row actually before finally, carefully, holding the shift key down so that I had the right command:
A:\> DIR X:
That is, a colon, not a semicolon. Once I determined that I could read the files, I issued the fateful A:\> X:GX270A07.EXE
I said "yes" (twice I think) and rebooted. Was I ever happy to see BIOS VERSION A07 on the screen!But that wasn't quite enough
But logging in as the teenager still produced a blank screen. Well, almost blank. Also, if I did "startx -- :1" first, then I still, reliably got a freeze. No mouse, no keyboard. Next up: Bad RAM?I inserted the OpenSUSE 11.1 DVD and selected memory test. We went to church and returned, and MEMTESTX86+ has gone seven full passes with no errors whatsoever. I'm thinking it's not the RAM. Well, the 11.0 HCL page says that everything works under 11.0 on a GX270, so my next theory is that switching to 11.0 will result in a happier box. Pipe dream? I hope not! I'm burning an 11.0 image right now.
Someone suggested that maybe I need to find a cheap well-supported video card (one of those low-end ATI or matrox cards), "but that shouldn't be necessary." Well, I hope not. I swear the next box is gonna be a mac mini.
11.0: No joy
Well, that didn't work. I still get a freeze. ping: yes, ssh: no. Also keyboard useless.I grabbed a couple of video cards from the office -- both in computers not currently being used. One needs the wrong kind of AGP slot. The other plugs into a PCI slot, but yast2 hung when trying to probe it or something. I could still ssh in, so I became root and said "shutdown -h 0". that didn't do anything until I killed a few processes with HUP and some others with KILL. So I don't think these cards are gonna help me.
Next up is the framebuffer. I'm starting now (5pm) by just replcing "intel" with "fbdev" (with the quotes), like:
Section "Device"I know from experience this won't work, but I want to see the messages. OK, this gives "AddScreen/ScreenInit failed for driver 0" (no quotes). The log has:
BoardName "865 G"
BusID "0:2:0"
Driver "fbdev"
Identifier "Device[0]"
Option "NoDDC"
Vendorname "Intel"
EndSection
(II) Module fbdevhw: vendor="X.Org Foundation"Somebody said that the problem had to do with this line:
compiled for 1.5.2, module version = 0.0.2
ABI class: X.Org Video Driver, version 4.1
(**) FBDEV(0): claimed PCI slot 0@0:2:0
(II) FBDEV(0): using default device
(II) resource ranges after probing:
[0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B]
[1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[5] -1 0 0x00000000 - 0x00000000 (0x1) IX[B]
(**) FBDEV(0): Depth 24, (--) framebuffer bpp 32
(==) FBDEV(0): RGB weight 888
(==) FBDEV(0): Default visual is TrueColor
...lots of stuff...
(==) Depth 24 pixmap format is 32 bpp
(II) do I need RAC? No, I don't.
(II) resource ranges after preInit:
...elided...
(EE) FBDEV(0): FBIOPUT_VSCREENINFO succeeded but modified mode
(EE) FBDEV(0): mode initialization failed
(**) FBDEV(0): Depth 24, (--) framebuffer bpp 32so the thing to do was, per the above,
Adding "DefaultFbBpp 24" to the "Screen" section and running with 32 bitsBut hold on a sec, my log has this:
depth ("DefaultDepth 32") solves this problem
(II) FBDEV(0): checking modes against framebuffer device...Why would that fail? Ha, because I have the wrong vga mode, that's why:
(II) FBDEV(0): mode "1280x1024" test failed
(II) FBDEV(0): checking modes against monitor...
(--) FBDEV(0): Virtual size is 1024x768 (pitch 1024)
(**) FBDEV(0): Built-in mode "current": 78.7 MHz, 59.9 kHz, 75.7 Hz
(II) FBDEV(0): Modeline "current"x0.0 78.65 1024 1056 1184 1312 768 772 776
792 -hsync -vsync -csync (59.9 kHz)
collin@p4:~> cat /proc/cmdlineThat 0x305 vga says 1024x768 with 256 colors, according to this page OK, so lemme try with vga=0x31B... Think I'll continue in another post.
root=/dev/disk/by-id/scsi-SATA_Maxtor_6Y080L0_Y24H85SE-part6 resume=/dev/sda2 splash=silent vga=0x305
collin@p4:~>
No comments:
Post a Comment