Re: Daily backups of pkgdb failure
On 05/04/2011 23:56, Hans Ottevanger wrote:
On 05/05/11 04:43, Doug Barton wrote:
On 05/04/2011 04:49, Hans Ottevanger wrote:
make -f/usr/share/mk/bsd.port.mk -V PKG_DBDIR
"/usr/share/mk/bsd.port.mk", line 11: Could not find
/usr/ports/Mk/bsd.port.mk
make: fatal errors encountered -- cannot continue
I fixed this in HEAD by setting the default if pulling it from make
fails. I will MFC ASAP.
Of course this will solve my "problem" 8-)
But if you use something like
pkg_dbdir=${PKG_DBDIR-/var/db/pkg}
you will also cover the (infrequent) case where people redefine
PKG_DBDIR while running pkg_add et al (and actually remember to set
PKG_DBDIR in /etc/crontab !).
To be honest, I don't care. If you are doing this kind of thing you
deserve what you get.
If you really want to move your PKG_DBDIR and can't be bothered to
define it correctly, use a symlink. Or, if that's a problem, disable the
backup. This "problem" is not going to affect the overwhelming number of
freebsd users, and I don't think going through a lot of gymnastics to
support people who do silly things is a good idea for either side.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Daily backups of pkgdb failure
On 05/05/11 09:09, Doug Barton wrote:
On 05/04/2011 23:56, Hans Ottevanger wrote:
On 05/05/11 04:43, Doug Barton wrote:
On 05/04/2011 04:49, Hans Ottevanger wrote:
make -f/usr/share/mk/bsd.port.mk -V PKG_DBDIR
"/usr/share/mk/bsd.port.mk", line 11: Could not find
/usr/ports/Mk/bsd.port.mk
make: fatal errors encountered -- cannot continue
I fixed this in HEAD by setting the default if pulling it from make
fails. I will MFC ASAP.
Of course this will solve my "problem" 8-)
But if you use something like
pkg_dbdir=${PKG_DBDIR-/var/db/pkg}
you will also cover the (infrequent) case where people redefine
PKG_DBDIR while running pkg_add et al (and actually remember to set
PKG_DBDIR in /etc/crontab !).
To be honest, I don't care. If you are doing this kind of thing you
deserve what you get.
To be clear. it is OK for me, I use defaults wherever possible.
If you really want to move your PKG_DBDIR and can't be bothered to
define it correctly, use a symlink. Or, if that's a problem, disable the
backup. This "problem" is not going to affect the overwhelming number of
freebsd users, and I don't think going through a lot of gymnastics to
support people who do silly things is a good idea for either side.
My idea was that if you go through the trouble to use make to get
PKG_DBDIR from the ports (as possibly redefined in /etc/make.conf) you
might as well try something similar while using packages.
But again: every deliberate choice is OK for me.
Regards,
Hans
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: zpool upgrade, can't boot
On 3/05/11 2:42 AM, Jeff Blank wrote: Hi, I recently upgraded from 8.0-STABLE to 8.2-STABLE (Apr. 29 checkout) and upgraded my zpool (includes root FS) from v13 to v15. This is a dual-boot laptop, so I'm using MBR/boot0 and not GPT. Here's what happens when I boot: F1 Win F2 ? F3 FreeBSD F6 PXE Boot: F3 ZFS: unsupported ZFS version 15 (should be 13) No ZFS pools located, can't boot I've googled around, but I can't find anything relevant for MBR/boot0 configurations, just GPT. I've ensured that the loaders and boot0/boot1/boot2 are all new, and I rebuilt/reinstalled them in a fixit environment just to be sure. I also ran 'boot0cfg -B' (with an appropriate -b), but nothing has changed. How can I get my pool booting again? Not only do you have to get the boot loaders installed properly [1] but also there is a breakage in the FreeBSD 8.2-RELEASE code [2]. The MBR bootloader is broken in 8.2 and will not work with ZFS under at least some circumstances (2 of our boxes had the problem). The problem has been reported on the freebsd-fs list and I notice a fix has gone into svn for the 8-STABLE branch. You need to get a bootloader from 8-CURRENT or convert your partitions over to GPT if you hit that particular bug. But you aren't up to hitting that bug yet... you haven't installed the newer bootloader at the point you are up to. Ari [1] [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=153552 -- --> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: zpool upgrade, can't boot
On 5/05/11 7:24 PM, Aristedes Maniatis wrote: Not only do you have to get the boot loaders installed properly [1] but also there is a breakage in the FreeBSD 8.2-RELEASE code [2]. The MBR bootloader is broken in 8.2 and will not work with ZFS under at least some circumstances (2 of our boxes had the problem). The problem has been reported on the freebsd-fs list and I notice a fix has gone into svn for the 8-STABLE branch. You need to get a bootloader from 8-CURRENT or convert your partitions over to GPT if you hit that particular bug. But you aren't up to hitting that bug yet... you haven't installed the newer bootloader at the point you are up to. Ari [1] [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=153552 Sorry, [1] should be http://www.ish.com.au/node/1434 That has some useful pointers for installing the zfsboot onto MBR disks, but I'm sure you can find similar information in other places (just not in the FreeBSD handbooks unforuntately) Ari -- --> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Xorg lockup in drmwtq state
Hi! In the last week I have started to see the situation described in the subject several times. I'd really appreciate some help about this issue, since I don't know where to look at to better diagnose it. The screen locks up, but the mouse cursor still moves. I can log in via ssh and from top I see this line for Xorg: 1563 root 1 440 388M 326M drmwtq 1 5:05 0.00% Xorg the last line from Xorg.0.log reads: [mi] EQ overflowing. The server is probably stuck in an infinite loop. I updated the system on Apr 28 just after cvsupping the latest 8-stable. I also upgraded to Firefox 4 on that day. I mention Firefox 4 because these lockups are always happening while using FF4. It also looks like thay are happening when I use FF4 while I have at least one VirtualBox machine running. I know this sounds crazy, but this is what I'm seeing. I'm trying to do some more testing but I can't reproduce this with just FF4 or just VirtualBox running. This machine has intel graphics: vgapci0: port 0x1210-0x1217 mem 0xf010-0xf017,0xe000-0xefff,0xf000-0xf00f irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 6140k stolen memory drm0: on vgapci0 Up to March 10 this was not happening.(I have not used this machine in the days between March 10 and Apr 28, I'm sorry I can't really narrow it down any better) Putting blame on VirtualBox I disabled 3D acceleration in all virtual machines, but this did not solve nor mitigate the problem. Thank in advance for any help! I'm attaching dmesg, xorg.conf and Xorg.0.log. -- Guido Falsi Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-STABLE #1: Thu Apr 28 14:19:08 CEST 2011 root@hostname:/usr/obj/usr/src/sys/HOST amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz (2327.51-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11 Features=0xbfebfbff Features2=0xe3fd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 8594128896 (8196 MB) avail memory = 8165249024 (7786 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard netsmb_dev: loaded kbd1 at kbdmux0 cryptosoft0: on motherboard aesni0: No AESNI support. acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, dff0 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xf808-0xf80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x1210-0x1217 mem 0xf010-0xf017,0xe000-0xefff,0xf000-0xf00f irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 6140k stolen memory drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) info: [drm] AGP at 0xe000 256MB info: [drm] Initialized i915 1.6.0 20080730 pci0: at device 3.0 (no driver attached) pci0: at device 3.2 (no driver attached) pci0: at device 3.3 (no driver attached) em0: port 0x1100-0x111f mem 0xf018-0xf019,0xf01a5000-0xf01a5fff irq 19 at device 25.0 on pci0 em0: Using an MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1e:0b:ab:e6:a7 uhci0: port 0x1120-0x113f irq 20 at device 26.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x1140-0x115f irq 21 at device 26.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x1160-0x117f irq 22 at device 26.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 ehci0: mem 0xf01a6800-0xf01a6bff irq 22 at device 26.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 hdac0: mem 0xf01a-0xf01a3fff irq 21 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] pcib1: at device 28.0 on pci0 pci32: on pcib1 pcib2: irq 21 at device 28.1 on pci0 pci48: on pcib2 uhci3: port 0x1180-0x119f irq 20 at device 29.0 on pci0 uhci3: [ITHREAD] usbus4: on uhci3 uhci4: port 0x11a0-0x11bf irq 21 at device 29.1 on pci0 uhci4: [ITHREAD] usbus5: on uhci4 ehci1: mem 0xf01a6c00-0xf01a6fff irq 20 at device 29.7 on pci0 ehci1: [ITHREAD] usbus6: EHCI version 1.0 usbus6: on ehci1 pcib3: at device 30.0 on pci0 pci7: on pcib3 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x1230-0x1237,0x1248-0x124b,0x1238-0x123f,0x124c-0x124f,0x11c0-0x11df mem 0xf01a6000-0xf01a67ff irq 18 at device 31.2 on pci0 ahci0: [ITHREAD] ahci
Intel "em" driver sleeps with non-sleepable lock.
The motherboard in question is made by Intel and contains a Xeon 3440 (4 core x 2 HT per core). 16 Gig of RAM is installed and we are installing the 64 bit FreeBSD 8.2 using the PC-BSD installer (to install zfs root faster). The motherboard has 4 "igb" ethernet and one "em" ethernet. The "em" ethernet is shared with an internal "RMM3" remote management card and/or the onboard ILOM. This error happens when rebooting after installation and is repeatable with at least FreeBSD 8.1 and FreeBSD 8.2. The last boot message is "Starting devd" ... so I assume that the active link on em0 might be making devd start dhclient. After this last boot message, the screen reads: Sleeping thread (tid 100195, pid 619) owns a non-sleepable lock panic: sleeping thread cpuid = 2 KDB: stack backtrace: #0 0x805f4e03 at kdb_backtrace+0x5e #1 0x805c2d07 at panic+0x187 #2 0x80601a5d at propagate_priority+0x1cd #3 0x8060278a at turnstile_wait+0x1aa #4 0x805b34c0 at _mtx_lock_sleep+0xb0 #5 0x8032fd97 at em_init_locked+0xce7 #6 0x80331b8e at em_ioctl+0x5fe #7 0x80671114 at ifioctl+0x9e4 #8 0x806043c2 at kern_ioctl+0x102 #9 0x806045fd at ioctl+0xfd #10 0xff80600dd5 at syscallenter+0x1e5 #11 0xff808aca5b at syscall+0x4b #12 0xff80895292 at Xfast_syscall+0xe2 Now. I assume that booting without link on em0 (inconvenient) or booting without "em" in the kernel will fix things. I'll be checking this out shortly. I can provide (for a limited time) full console access and/or I can test code if someone sees a patch for this. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Intel "em" driver sleeps with non-sleepable lock.
So, this happens EVERY time after an install of 8.2 ?? Give me details about the hardware please. Jack On Thu, May 5, 2011 at 11:11 AM, Zaphod Beeblebrox wrote: > The motherboard in question is made by Intel and contains a Xeon 3440 > (4 core x 2 HT per core). 16 Gig of RAM is installed and we are > installing the 64 bit FreeBSD 8.2 using the PC-BSD installer (to > install zfs root faster). The motherboard has 4 "igb" ethernet and > one "em" ethernet. The "em" ethernet is shared with an internal > "RMM3" remote management card and/or the onboard ILOM. This error > happens when rebooting after installation and is repeatable with at > least FreeBSD 8.1 and FreeBSD 8.2. > > The last boot message is "Starting devd" ... so I assume that the > active link on em0 might be making devd start dhclient. After this > last boot message, the screen reads: > > Sleeping thread (tid 100195, pid 619) owns a non-sleepable lock > panic: sleeping thread > cpuid = 2 > KDB: stack backtrace: > #0 0x805f4e03 at kdb_backtrace+0x5e > #1 0x805c2d07 at panic+0x187 > #2 0x80601a5d at propagate_priority+0x1cd > #3 0x8060278a at turnstile_wait+0x1aa > #4 0x805b34c0 at _mtx_lock_sleep+0xb0 > #5 0x8032fd97 at em_init_locked+0xce7 > #6 0x80331b8e at em_ioctl+0x5fe > #7 0x80671114 at ifioctl+0x9e4 > #8 0x806043c2 at kern_ioctl+0x102 > #9 0x806045fd at ioctl+0xfd > #10 0xff80600dd5 at syscallenter+0x1e5 > #11 0xff808aca5b at syscall+0x4b > #12 0xff80895292 at Xfast_syscall+0xe2 > > Now. I assume that booting without link on em0 (inconvenient) or > booting without "em" in the kernel will fix things. I'll be checking > this out shortly. > > I can provide (for a limited time) full console access and/or I can > test code if someone sees a patch for this. > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
