Date: Fri, 31 Oct 2003 15:12:29 -0800 From: Peter Wemm <peter@wemm.org> To: Adriaan de Groot <adridg@cs.kun.nl> Cc: amd64@freebsd.org Subject: Re: fyi: bootstrapped Message-ID: <20031031231229.EFF602A8EB@canning.wemm.org> In-Reply-To: <200310312355.30349.adridg@cs.kun.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
Adriaan de Groot wrote:
> sk0: Ethernet address: 00:0c:6e:b3:3f:38
> malloc() of "512" with the following non-sleepable locks held:
> exclusive sleep mutex skc0 (network driver) r = 0 (0xffffff0000bcba70) locked
> @ pci/if_sk.c:1292
> miibus0: <MII bus> on sk0
> e1000phy0: <Marvell 88E1000 Gigabit PHY> on miibus0
> lock order reversal
> 1st 0xffffff0000bcba70 skc0 (network driver) @ pci/if_sk.c:651
> 2nd 0xffffffff8077d540 kernel environment (kernel environment) @
> kern/kern_environment.c:288
> Stack backtrace:
> e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX,
> auto
>
> ### Looks like spinlocks with a potential problem
Hmm. This is a generic problem though, not amd64 specific.
> xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xb000-0xb07f mem
> 0xcfc00000-0xcfc0007f irq 10 at device 12.0 on pci0
> xl0: Ethernet address: 00:01:02:b3:de:a6
> miibus1: <MII bus> on xl0
> xlphy0: <3c905C 10/100 internal PHY> on miibus1
> xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> pci0: <display, VGA> at device 13.0 (no driver attached)
> atapci1: <VIA 8237 SATA150 controller> port
> 0xd000-0xd0ff,0xd400-0xd40f,0xd800-0xd803,0xe000-0xe007,0xe400-0xe403,0xe800-
0xe807
> irq 10 at device 15.0 on pci0
> atapci1: [MPSAFE]
>
> ### Impressive. I had it disabled in the BIOS.
Heh. It just doesn't probe it.
> uhci0: <VIA 83C572 USB controller> port 0xb400-0xb41f irq 5 at device 16.0 on
> pci0
> usb0: <VIA 83C572 USB controller> on uhci0
> usb0: USB revision 1.0
> uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> uhub0: 2 ports with 2 removable, self powered
> uhub0: port error, restarting port 1
> uhub0: port error, giving up port 1
>
> ### All my ports do this, even the ones with devices attached that
> ### subsequently function just fine (like the keyboard and mouse).
> ### Also, I have the orts set to USB 2.0, I'd expect that to be reported, no?
I get this too, in 32 bit mode as well. The USB uhci code simply doesn't like
something. I dont know what.
BTW; you can reduce the amount of noise by going into the bios setup and reducing
the number of ports to 2 or 4. I use 2.
> Buildworld took _way_ longer than the promised 14 minutes, but that's probabl
y
> just what you get when you have /usr on an ATA33 drive and /usr/src on a
> faster one.
Yes, you have witness etc turned on. Otherwise you wouldn't get the lock order
warning. witnetss slows things down massively.
Also, the 14 minutes was a 32 bit buildworld on 4.x. -current has a slower
compiler and compiles different things, eg: kerberos5.
> For my next goal, KDE-on-CURRENT-on-amd64, fetching lots of ports is needed,
> lots of downloads to go .. but in the meantime, is there anything useful I
> can do for you? You in the sense of the amd64 list, that is. I can push the
> system as a typical desktop user would (which isn't that hard), muck with the
To build kdebase3, you'll need a couple of tweaks to the XFree86-4-libraries
port. I did this:
$ make patch
$ cd work/xc/lib
$ vi xkb*/Imakefile
Make it so that:
#define DoSharedLib YES
and add the line:
SOXKBFILEREV = 6.0
so that it looks something like this:
#define DoNormalLib YES
#define DoSharedLib YES
#define DoExtraLib NO
#define DoDebugLib NO
#define DoProfileLib NO
#define HasSharedData NO
#define LibName xkbfile
SOXKBFILEREV = 6.0
#define SoRev SOXKBFILEREV
#define IncSubdir X11
#define IncSubSubdir extensions
There should be two Imakefiles that you need to change.
Then do the 'make install'. This is necessary in order to build kdebase3,
because without it, it tries to link libxkbfile.a into a .so file, which is
illegal (and fatal on amd64 platforms). XFree86 normally doesn't build these
as shared objects. The changes above turn on the shared libs so kdebase3 can
use them.
> stuff I'm worried about above, or mess with the ed driver (because I've got
> one). The latter two will probably generate more questions on my part, I
> think. Aside from attending the Device Driver talk at EuroBSDcon last year,
> I've not done much of this kind of stuff before.
>
> Hm, 1290u 1230s 44:59 before buildworld craps out in ipfstat. Remind me again
> how to resume broken buildworlds?
If you're in the final stage, you can do a 'make everything'. But I'd suggest
that you instead turn WITNESS and friends off first.
If kdebase3 blows up due to u_int32_t in netinet6/in6.h, you need to finish
your buildworld/installworld. You can manually edit (if you want)
/usr/include/netinet6/in6.h so that the ip6m_mtu varaible is changed from
u_int32_t to uint32_t. This has been committed already.
Now, the kdebase3 build is slow.... :-] But it (konq) is the only browser
I've been able to get running so far.
Cheers,
-Peter
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031031231229.EFF602A8EB>