I've been running Linux (Slackware 3.0/kernel 1.2.13) on my
Thinkpad 755CX for some time, and have been having problems
upgrading to the 1.3.x kernel. This week I decided to put in a
more serious effort at it, with mixed success. Kernel 1.3.100 is
currently running OK, modulo some ugly defects:
(1) SVGA problems: accessing the 800x600 mode
(2) APM problems: resuming from the auto-powerdown/suspend
triggered by the ROM BIOS (e.g. in response to closing book)
The SVGA problem seems due to improvements in the setup code, in
video.S. With kernel 1.2.13 the only way I had been able to get
800x600 mode to work had been by using DOS to setup the video
mode, and then boot through loadlin. The auto-detection code in
setup got the screen with (100) correct, and I then just
hard-coded in a height that more or less worked (37). It is
usable, but the bottom few lines of the screen are rotating
garbage. I ended up doing a similar hack with the new video.S
(adding a new local mode), so that I can run again with a 100x37
character window. However, this leaves me feeling unsatisfied:
(1) I'd like to try fixing the auto-detect code in video.S so that
I can boot directly with LILO, i.e. so that it can initialize the
WD90C24 controller to the desired mode; (2) I'd like to be able to
use the 100x75 (8 pixel font) mode. To this end, I've been
looking through the Western Digital manual for the WD90C24, and
doing some experiments. I've also considered looking at the
autodetect code from XFree86, since that seems to be able to
detect and handle the WD90C24 OK. The going is slow, due to my
lack of familiarity with VGA interface programming and the
existing (rather complicated-looking) logic of video.S, so
I'm getting a bit discouraged.
The FDC problem also seems due to recent improvements in the
auto-detect code. The earlier version of the kernel variously
detected my drive as "FDC 0 is a post-1991 82077" (1.2.13), and
"FDC 0 is an 82078-1." (1.3.94), but the newer version of
"floppy.c" gives up entirely, with "FDC 0 init: SAVE: unexpected
return of -1 bytes.". Again, I'm tempted to take the expedient --
just hard-code in a reasonable value for my system -- but I'd
rather see it fixed correctly.
[I also have some APM problems, but they are not new. Hibernation
(where memory is copied to disk, and then reloaded) has never
worked, but the Suspend Mode is close enough to working that I
still have hope. That is, it works most of the time, but
sometimes when it powers back up there is no response to
keystrokes, and sometimes even no response to the power ON/OFF
switch.]
It occurs to me that I may be wasting effort on these problems, if
somebody else has already solved them, or knows enough more than I
do to point me in a direction that would reduce the amount of
trial and error.
Any advice?
--Ted Baker