Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 31 Jan 2003 08:14:15 -0800
From:      "Kevin Oberman" <oberman@es.net>
To:        stark <stark@jeamland.ca>
Cc:        freebsd-current@freebsd.org
Subject:   Re: Fun and excitement with CURRENT 
Message-ID:  <20030131161415.3A4695D04@ptavv.es.net>
In-Reply-To: Your message of "30 Jan 2003 22:43:33 EST." <1043984613.604.38.camel@stinkpad.jeamland.ca> 

next in thread | previous in thread | raw e-mail | index | archive | help
> From: stark <stark@jeamland.ca>
> Date: 30 Jan 2003 22:43:33 -0500
> Sender: owner-freebsd-current@FreeBSD.ORG
> 
> OK, I've got just 1.5 bugs left, then I'll be all CURRENT-ed :)
> 
> (I'm using a brand new laptop.  Much different than getting
> BSD working on my desktops and servers :)
> 
> Things that work :
> - Making the third mouse button work on an IBM T30 (trackpoint &
>   touchpad model) you have to disable the touchpad in the BIOS.
> 
> - Making CURRENT compile on 4.7 involves NOT using cvsupit to
>   do your cvsup-ing.  or using it and editing it to use src-all
>   so you actually get the whole thing.
> 
> - When compiling a kernel, don't be a smartass and assume you can
>   make your 4.7 KERNCONF file work in 5.0.  start over with a 5.0
>   GENERIC and modify it.  You'll feel MUCH less stupid later.
> 
> - X on a Radeon mobility 7500 is PERFECT.  VERY VERY HAPPY! :)

I assume IBM is still using the Mobility M7? IF so, I would not say
"perfect". Are you using XFree86-Server-4.2.1? If so, the Radeon
Mobility has two well known problems.

Less serious is that line acceleration is broken and some things that
re-draw lines fast will leave black lines on the display. You can
eliminate these artifacts if you run the CVS drivers and add the
option "NoLineAccel" to you configuration. This will be in 4.3.0 when
it is release in about 2 weeks.

If the display is turned off by BIOS (e.g. suspend, Fn-F3, or
time-out), the display will restart very badly scrambled. No known fix
for this that I have seen, although there is a work-around of
switching to a text virtual terminal before the display turns off or
by switching to a test virtual terminal after the display comes on and
then cycling the display off and on.

> - don't use apm and acpi at the same time.

That is sound advice on any system. In fact, it looks like APM should
check on the presence of ACPI when probing and bail out (with a
suitable error) if it finds ACPI.

Is there any case on any platform when both would make any sense at
all?

> UNFORTUNATELY, that last one has a solution :
> 
> - DON'T USE ACPI.  It really causes a problem.
>   If I turn acpi on (in kernel or as a module
>   same result) it will die a horrible, horrible
>   death.  I'll get more info (as in, the text
>   it says when it crashes or the text it says
>   when it boots or whatever) after a couple of
>   reboots, but i was so happy it worked without
>   acpi i'm typing this now.  debug later :)

Try the acpi-jp list. There are many ACPI issues with IBMs (and many
others) that are currently being discovered. I'm told that the latest
BIOS makes ACPI work better, but still not correctly.

> - Sound is really really weird.  pcm doesn't work
>   with the i810 onboard (it works, but sound is
>   all static-y to the point of inaudibility,
>   and the OSS drivers seem to have a problem.
>   I think the oss drivers don't seem to work
>   without ACPI.  or at least not so far.  It
>   worked once, just not since :)

Odd. I have not seen this to this point, but I am not running V5 on my
T30 at the moment and I may not have ever tried it. The sound is fine
with Stable.

> so there ya go, 1.5 bugs.  The ACPI took me quite
> a while to work around because every time it booted
> with it it crashed the system before I could do
> anything productive.  REALLY ANNOYING :)
> (Is there a way to tell the kernel not to AUTOLOAD
> ACPI on boot?  That would be SUPER :)

Yes. Stop the system at the "countdown" and enter "unset acpi_load"
for a one-time fix and then add the line 'hint.acpi.0.disabled="1"' to
/boot/device.hints.

> Anyways, I'll keep the machine going and hopefully
> come up with some ACPI patches in the next few days
> that cause my laptop not to die a horrible death :)
> (If you have any such patches let me know! :)

ACPI patches would be greatly appreciated. If you find something,
please be sure that you send it to acpi-ap@jp.freebsd.org. (While the
"-jp" indicates a Japanese language list, I have never seen a message
that lacked an English translation and the majority of the messages
are all English.)

R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@es.net			Phone: +1 510 486-8634


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030131161415.3A4695D04>