Date: Wed, 21 Jul 2004 00:04:22 -0700 From: Julian Elischer <julian@elischer.org> To: Jake Hamby <jhamby@anobject.com> Cc: freebsd-mobile@freebsd.org Subject: Re: Using -current on a Fujitsu Lifebook N5010 (no Atheros 802.11, no Ethernet, + hard freezes) Message-ID: <40FE1576.10206@elischer.org> In-Reply-To: <40FE0DF3.4030008@anobject.com> References: <40FE0DF3.4030008@anobject.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jake Hamby wrote: > I recently purchased a new notebook (a Fujitsu Lifebook N5010, a > model which I can highly recommend as a desktop replacement) and > decided to try installing FreeBSD-CURRENT on it instead of Gentoo > Linux, which is the UNIX that I would normally install. Here are > some of the issues I faced in terms of missing kernel support for > this laptop. > > 1) Ethernet chipset not recognized. > > This laptop uses the SiS 648 chipset and includes a 10/100 Ethernet > port with a Realtek 8139-compatible interface. More specifically, it > is vendor id 0x10EC (Realtek), device id 0x8139 on PCI device > 00:07.0, recognized as type 'RTL-8100B/8139D' by the Linux 8139too > driver. > > What is even stranger is that this card shows up in a DOS-based > hardware scan (using AIDA from the Ultimate Boot CD), but not in the > output of pciconf. Nor does it show up in the dmesg output, even as > an unknown device. probably an unsupported bridge between it and the CPU.. I'll let the bus enumeration types handle that.. > > 2) Version of Atheron 802.11a/b/g driver is too old. This is something for sam@freebsd.org. give him a ping. > > With the version of the ath driver in CURRENT, I get this output: > > ath0: [GIANT-LOCKED] ath0: mac 5.6 phy 4.1 5ghz radio 3.6 ath0: > unable to collect channel list from hal device_attach: ath0 attach > returned 22 ath0: <Atheros 5212> mem 0xec010000-0xec01ffff irq 11 at > device 10.0 on pci0 > > The problem is inside of the portion of the code which is delivered > only in binary form. Fortunately for you all, I spent the last five > or six days hacking on it and was able to integrate the latest > version of the Linux Atheros hal code from > http://madwifi.sourceforge.net/, as well as the necessary changes to > the driver code provided as source. You can download my merged > version from here: > > http://www.anobject.com/jehamby/atheros_driver.tar.bz2 > [...] > > * Now uses four transmission queues of varying priority instead of > one: WME_AC_BE (highest), WME_AC_BK, WME_AC_VI, and WME_AC_VO > (lowest). There is code in the Linux version to support QOS and > insert outgoing packets into queue by priority, but I couldn't find > the equivalent of the priority field from Linux's sk_buff struct in > FreeBSD's equivalent ieee80211_frame struct. Currently all outgoing > packets go to WME_AC_BE, except packets of type > IEEE80211_FC0_TYPE_MGT, which go to WME_AC_VO. FreeBSD would store that information in what is called an mbuf tag. A separate small chunk of ram tagged onto teh first mbuf of the packet. This is relatively new and there is only just starting to be some use of it.. Official QOS support in the kernel does not exist yet. (though there are some sporadic users of priority tags here and there it is not general yet.) > [...] > > 3) Random freezes > > After an average of 30-40 minutes of heavy usage, I get random system > freezes. I am typically running XFree86 and downloading something > or reading web pages at the time it happens. More disturbingly, I am > occasionally seeing files get renamed, for example > /usr/src/UPDATING.64BIT became /usr/src/UPDATING.64BTT. This happens > with or without WITNESS, with INVARIANTS enabled, with or without > ACPI, and with or without SMP. I am using SCHED_ULE and no > PREEMPTION. you are not alone.. I think you just chose a bad moment to jump into -current :-/ > > I had been hoping that I could dump the memory to a partition and get > some debugging information from the core using gdb, but it doesn't > work. I have a dumpdev setting in my /etc/rc.conf but when the system > hangs, it hangs. I recently read about FireWire remote debugging, > which sounds pretty cool. I have a desktop PC with FireWire > currently running Gentoo Linux. Can someone point me to information > about how to do this? I assume that I would need to set up a FreeBSD > installation on that machine first? How likely is it that this will > provide any useful information for a random system hard lockup? it's not impossible that it could but it'd behard to knw for sure. Yes youd need a matching FreeBSD system with sources and the debug version of the kernel to use as a source of symbols. > > 4) ACPI is not working correctly. > > ACPI support is incomplete. I can suspend the system with "zzz", but > then there is no way to wake it back up. The power button turns the > machine on but then it hangs in a CPU loop (I can tell b/c the > cooling fan goes on) with a blank screen. Sometimes the output of > "apm" gives correct results (good enough for the GNOME battery status > applet, although suspending through APM gives a hard freeze), while > other times I get this output (giving an empty battery icon for > GNOME): > > APM version: 1.2 APM Management: Disabled AC Line status: on-line > Battery Status: charging Remaining battery life: invalid value > (0xffffffff) Remaining battery time: unknown Number of batteries: 1 > Battery 0: not present > > 5) DRI is not working. > > This laptop has a Radeon Mobility 9600 (M10) NP chip (ChipID = > 0x4e50), which runs XFree86 using the vesa driver, or with the radeon > driver in the XFree86 4.3.99.15 snapshot, which gives me this error: > > (WW) RADEON(0): Direct rendering not yet supported on Radeon > 9500/9700 and newer cards yeah Well that isn't freeBSD specific.. looked at X.org? > > I get no error when loading the radeon kernel module, but no output > either, and no drm0 message in dmesg. Is there any possibility that > the 9600 will be supported by a future version of XFree86? I have > already written ATI suggesting they release a FreeBSD version of > their proprietary Linux driver, but they probably won't. interstingly, if it is a XFree86 "driver" it may work as they are supposed to not use any services outside of the XF86 server. If it is a kernel device driver the, yes the'd need to do a lot of work..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40FE1576.10206>