mount root from zfs fails under current with error 6
Hi, I get the following error with recent -current (r222417) during boot: ... Trying to mount root from zfs:boot/ROOT/root []... Mounting from zfs:boot/ROOT/root failed with error 6. ... What does error 6 mean? The strange thing is, that I could boot with r222417 a few times but after applying a (here unrelated) one-liner from rmacklem@ to nfs_clkdtrace.c, recompile the module and reinstall, I could'n load either kernel nor kernel.old. I didn't even use the patched module. Only loading a kernel r221381 let me boot again. So may it be a race condition of some form? Anyone else sees this? Any further infos are available on request. Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: newnfs user setup
On Thu, 26 May 2011, Rick Macklem wrote: ... Alternately, if you could email me some simple instructions on how to test it, that would be appreciated as well. (I have never used DTrace, so I have no idea how to test it.) It is basically a clone of the other one, except for the NFSv4 stuff, so it should work about the same. The simplest way of a basic test should be: - Put into your kernel.conf: options KDTRACE_FRAME # could be for amd64 only options KDTRACE_HOOKS options DDB_CTF # could be optional - make buildworld WITH_CTF=1 make buildkernel WITH_CTF=1 - Put into your loader.conf: dtraceall_load=YES After reboot check: dtrace -l If you see lots of fbt and sdt (esp. the nfs ones) providers all should be prepared and fine. Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: newnfs user setup
On Fri, 27 May 2011, Alexander Leidinger wrote: Date: Fri, 27 May 2011 10:43:58 +0200 From: Alexander Leidinger alexan...@leidinger.net To: Michael Reifenberger m...@reifenberger.com Cc: Rick Macklem rmack...@uoguelph.ca, FreeBSD-Current freebsd-current@FreeBSD.org Subject: Re: newnfs user setup Quoting Michael Reifenberger m...@reifenberger.com (from Fri, 27 May 2011 10:02:09 +0200 (CEST)): - make buildworld WITH_CTF=1 make buildkernel WITH_CTF=1 Do not build world with CTF, this will produce broken static executables. Ups. Thanks for reminding! Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: newnfs user setup
On Thu, 26 May 2011, Rick Macklem wrote: ... http://people.freebsd.org/~rmacklem/dtrace.patch Hmm. Is it just me? Trying to test the patch I get: (fs)(root) patch -C dtrace.patch Hmm... I can't seem to find a patch in there anywhere. Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: newnfs user setup
On Thu, 26 May 2011, Rick Macklem wrote: Date: Thu, 26 May 2011 09:14:01 -0400 (EDT) From: Rick Macklem rmack...@uoguelph.ca To: Andriy Gapon a...@freebsd.org Cc: Rick Macklem rmack...@freebsd.org, FreeBSD-Current freebsd-current@FreeBSD.org Subject: Re: newnfs user setup Rick, maybe I've just not looked hard enough, but I am a little bit confused about how to setup properly newnfs server and client via rc.conf. That is, I am not sure which exactly daemons I need and what variables to set. I dunno if its matters here but it seems that the usage of DTrace (esp. dtnfsclient) forces the usage of oldnfs. Is it possible to use both oldnfs and newnfs kernel objects at once or does the usage of newnfs prohibit the usage of dtrace? Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: problems with em(4) since update to driver 7.2.2
Hi, I have the very same problem. - GENERIC 9.0-CURRENT (April 28) - em0 PRO/1000 7.2.3 - em0: Could not setup receive structures On 03.05.2011 10:58, Olivier Smedts wrote: I tried increasing kern.ipc.nmbjumbo* (is it what you suggested ?). Values doubled : kern.ipc.nmbjumbo16: 6400 kern.ipc.nmbjumbo9: 12800 kern.ipc.nmbjumbop: 25600 And unloaded / reloaded the kernel module. Still no luck, same problem, on latest 9-CURRENT (r221363). Same here. If I should provide some more configuration settings, please let me know. Michael ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: problems with em(4) since update to driver 7.2.2
On 03.05.2011 23:24, Jack Vogel wrote: If you get the setup receive structures fail, then increase the nmbclusters. If you use standard MTU then what you need are mbufs, and standard size clusters (2K). Only when you use jumbo frames will you need larger. You must configure enough, its that simple. I doubled the nmbclusters as well. But nothing happened. I have no load on this machine and nothing special configured. Thanks, Michael ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cardbus memory allocation problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have WIP patches to fix this but they aren't ready yet. pcib4: I/O decode0x4000-0x4fff pcib4: memory decode 0xf090-0xf09f *** this memory widow is what I expected all children to allocate from pcib4: no prefetched decode pcib4: Subtractively decoded bridge. It's a subtractive bridge, so the resources do not have to be allocated from the window. That said, I'm committing the last of my patches to HEAD today to rework how PCI-PCI bridges handle I/O windows to support growing windows, etc. and the new PCI-PCI bridge driver will attempt to grow the memory window to allocate a new range before falling back to depending on the subtractive decode. You might be pleased to hear that, without any special arrangements in loader.conf, the new PCI-PCI code does The Right Thing with memory allocation :-) Parent bridge: I fixed the subordinate bus using setpci -s 07:06.2 4c.b=02 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) (prog-if 01 [Subtractive decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=07, subordinate=09, sec-latency=64 I/O behind bridge: 4000-4fff Memory behind bridge: f090-f09f Cardbus bridge: 07:06.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller Subsystem: Toshiba America Info Systems Device ff10 Flags: bus master, medium devsel, latency 64, IRQ 18 Memory at f0907000 (32-bit, non-prefetchable) Bus: primary=07, secondary=08, subordinate=09, sec-latency=32 16-bit legacy interface ports at 0001 [ .. snip .. ] Cardbus inserted .. 08:00.0 Ethernet controller: Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter (rev 01) Subsystem: Netgear WG511T 108 Mbps Wireless PC Card (rev.A/B) Flags: medium devsel, IRQ 18 Memory at f091 (32-bit, non-prefetchable) Capabilities: [44] Power Management version 2 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3AlIkACgkQQv9rrgRC1JKC1ACcDVsXXN/4NrR9y707OkCMaBAm NmEAoKJfwjaP0+92LKDYI9FRDULy8gPx =m/J6 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cardbus memory allocation problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/03/11 19:49, I wrote: Parent bridge: I fixed the subordinate bus using setpci -s 07:06.2 4c.b=02 Correction: this should be pciconf -wb pci0:0:30:0 0x1a 9 imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3ApU4ACgkQQv9rrgRC1JKDTwCgyv7JAXZgsI459vCaFOCsYlwe 8x4AnAyeMAS2c23xglr29BdYQNXftlyW =NB2b -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
cardbus memory allocation problem
I've stared at this for a (long) while but haven't come to any reasonable conclusion as to why it does what it does or how to fix it :-( Specifically, the BIOS in this machine doesn't set up a memory window for the cardbus controller nor does it properly configure the PCI bridge to route to the correct buses. BSD tries but allocates memory from the wrong space. My question is - how to get PCI-cardbus bridge to allocate memory inside the window of the parent PCI-PCI bridge? .. the bus tree looks like .. imb@toshi:/home/imb sudo lspci -t -[:00]-+-00.0 +-02.0 +-02.1 +-1b.0 +-1c.0-[02]-- +-1c.1-[03-04]-- +-1c.2-[05-06]00.0 +-1d.0 +-1d.1 +-1d.2 +-1d.3 +-1d.7 +-1e.0-[07]--+-06.0 |+-06.1 |+-06.2 |+-06.3 |\-08.0 +-1f.0 +-1f.2 \-1f.3 I've annotated the verbose dmesg below to highlight the issues .. pcib4: ACPI PCI-PCI bridge at device 30.0 on pci0 pcib4: domain0 pcib4: secondary bus 7 pcib4: subordinate bus 7 *** subordinate bus needs to be '9' so as to include both '8' '9' *** for the PCI-cardbus bridge pcib4: I/O decode0x4000-0x4fff pcib4: memory decode 0xf090-0xf09f *** this memory widow is what I expected all children to allocate from pcib4: no prefetched decode pcib4: Subtractively decoded bridge. pci7: ACPI PCI bus on pcib4 pci7: domain=0, physical bus=7 found- vendor=0x104c, dev=0x8039, revid=0x00 domain=0, bus=7, slot=6, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x03 (750 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0, size 12, memory disabled *** silly uninitialized value here outside of the expected window found- vendor=0x104c, dev=0x803a, revid=0x00 domain=0, bus=7, slot=6, func=1 class=0c-00-10, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0210, cachelnsz=4 (dwords) lattimer=0x80 (3840 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=b, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf0906000, size 11, enabled *** everything else under the pcib4 bridge is in the right window pcib4: requested memory range 0xf0906000-0xf09067ff: good map[14]: type Memory, range 32, base 0xf090, size 14, enabled pcib4: requested memory range 0xf090-0xf0903fff: good pcib4: matched entry for 7.6.INTB pcib4: slot 6 INTB hardwired to IRQ 17 found- vendor=0x104c, dev=0x803b, revid=0x00 domain=0, bus=7, slot=6, func=2 class=01-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0210, cachelnsz=4 (dwords) lattimer=0x80 (3840 ns), mingnt=0x07 (1750 ns), maxlat=0x04 (1000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf0904000, size 12, enabled pcib4: requested memory range 0xf0904000-0xf0904fff: good pcib4: matched entry for 7.6.INTA pcib4: slot 6 INTA hardwired to IRQ 18 found- vendor=0x104c, dev=0x803c, revid=0x00 domain=0, bus=7, slot=6, func=3 class=08-05-01, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0210, cachelnsz=4 (dwords) lattimer=0x80 (3840 ns), mingnt=0x07 (1750 ns), maxlat=0x04 (1000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf0906800, size 8, enabled pcib4: requested memory range 0xf0906800-0xf09068ff: good pcib4: matched entry for 7.6.INTA pcib4: slot 6 INTA hardwired to IRQ 18 found- vendor=0x8086, dev=0x1092, revid=0x02 domain=0, bus=7, slot=8, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x42 (1980 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf0905000, size 12, enabled pcib4: requested memory range 0xf0905000-0xf0905fff: good map[14]: type I/O Port, range 32, base 0x4000, size 6, enabled pcib4: requested I/O range 0x4000-0x403f: in range pcib4: matched entry for 7.8.INTA pcib4: slot 8 INTA hardwired to IRQ 20 cbb0: PCI-CardBus Bridge at device 6.0 on pci7 pcib4: cbb0 requested memory range 0x0-0x: good *** what appears to be a wildcard alloc request cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xbf67 *** but which isn't constrained to be within the parent bridge's space cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 pcib4:
Re: Finding typos using codespell
On 19.04.2011 13:15, Bruce Cran wrote: There's a new tool that can be used to find spelling mistakes in code: codespell from http://www.politreco.com has already been used to find mistakes in both Linux and LLVM. I ran it on sys/ and it found lots of potential typos - the full diff (which I know does contain some incorrect changes) can be found at http://www.cran.org.uk/~brucec/freebsd/codespell_sys.diff . Nice! But there are also some false positives in .uu files. Cheers, Michael ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
SVN - CVS burp?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It seem that CVS hasn't seen any src updates sine the burp involving /usr/ports/net/unison232/files/patch-update.mli.diff. Any ideas? imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2cbSEACgkQQv9rrgRC1JLglwCfZj7aMroEyTrk1s6/NfiCS4GK FYsAnR4cWbt6DrsGHqAUPFFVbtlEeAT/ =n3Vi -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Booted nanobsd image has /etc schg flag set
Hi,
I've tracked this down:
- Because on the building host /var/empty (comes from BSD.var.dist) has schg set
it gets copied to the cfg slice during populate_slice() in nanobsd.sh
- During boot /cfg gets copied over to /etc and the schg flag too
- After that neither /cfg nor /etc are fully functional...
I'll commit the following fix:
...
Index: nanobsd.sh
===
--- nanobsd.sh (Revision 219862)
+++ nanobsd.sh (Arbeitskopie)
@@ -413,8 +413,8 @@
dir=$2
mnt=$3
lbl=$4
- test -z $2 dir=/var/empty
- test -d $dir || dir=/var/empty
+ test -z $2 dir=${NANO_WORLDDIR}/var/empty
+ test -d $dir || dir=${NANO_WORLDDIR}/var/empty
echo Creating ${dev} with ${dir} (mounting on ${mnt})
newfs_part $dev $mnt $lbl
cd ${dir}
...
On Sat, 26 Mar 2011, Michael Reifenberger wrote:
Date: Sat, 26 Mar 2011 18:25:40 +0100 (CET)
From: Michael Reifenberger m...@reifenberger.com
To: FreeBSD-Current curr...@freebsd.org
Subject: Booted nanobsd image has /etc schg flag set
Hi,
I can't find the place where the schg flag is set for /etc
during boot.
(Must be during boot since the FS inside the image doesn't contain a schg
flagged file)
/var which is also a MFS FS hasn't schg set.
This prevents the creation of new files like resolv.conf or host.conf
after startup...
Bye/2
---
Michael Reifenberger
mich...@reifenberger.com
http://www.Reifenberger.com
Bye/2
---
Michael Reifenberger
mich...@reifenberger.com
http://www.Reifenberger.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Booted nanobsd image has /etc schg flag set
Hi, I can't find the place where the schg flag is set for /etc during boot. (Must be during boot since the FS inside the image doesn't contain a schg flagged file) /var which is also a MFS FS hasn't schg set. This prevents the creation of new files like resolv.conf or host.conf after startup... Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
bsdinstall-amd64-20110313 remarks
Hi, yesterday I tested the images listed in the subject and have the following remarks: - At least the memstick image contains an empty fstab - Does the usage of a dangerously dedikated disklabel give any advantage? - The usage of an UFS-Label for root mounting should be more flexible - The first dialog step should set the keyboard layout - The /etc is not writable which would greatly reduce the usefulness for the ISO image (no modified resolv.conf, sshd_config, ...) The usage of a nanobsd based base-installation would give a sufficient advanced Live-OS installation. You could take a look into src/tools/tools/nanobsd/rescue where I tried to address most of the issues above primary for rescuing GPT/ZFS installations (with still hardcoded keyboard though). With two nanobsd slices on one memstick you can actually produce combined i386/and64 Live-OS memsticks... I get both on a 2GiB memstick (Without packages). What do you think? Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bsdinstall-amd64-20110313 remarks
On Mon, 21 Mar 2011, Lars Engels wrote: Date: Mon, 21 Mar 2011 11:04:28 +0100 From: Lars Engels lars.eng...@0x20.net To: Michael Reifenberger m...@reifenberger.com Cc: Nathan Whitehorn nwhiteh...@freebsd.org, FreeBSD-Current curr...@freebsd.org Subject: Re: bsdinstall-amd64-20110313 remarks On Mon, Mar 21, 2011 at 09:25:36AM +0100, Michael Reifenberger wrote: Hi, yesterday I tested the images listed in the subject and have the following remarks: - At least the memstick image contains an empty fstab - Does the usage of a dangerously dedikated disklabel give any advantage? - The usage of an UFS-Label for root mounting should be more flexible - UFS-labeling does not work I let bsdinstall partition the disk automatically and edited the proposed partitions to add labels, but after the first boot, neither fstab nor /dev/label showed any labels. I did not mean to use UFS-Labels for the bsdinstall partitioner. I meant the use of UFS-Labels for the memstick image itself. BTW: The UFS labels should show up under /dev/ufs/... The cd9660 labels should show up under /dev/cd9660/... Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bsdinstall-amd64-20110313 remarks
On Mon, 21 Mar 2011, Nathan Whitehorn wrote: ... - Does the usage of a dangerously dedikated disklabel give any advantage? Not that I can think of -- I'm not sure about maximum disk sizes for pure BSD-label disks. It's a legitimate option, though, for people doing manual configuration. The question was only ment for the use of dangerously dedikated disklabel by the memstick itself. I have no opinion for use by the patitioner. - The usage of an UFS-Label for root mounting should be more flexible Yes. It is somewhat difficult however, to cross-correlate gpart labels for GPT, APM, and PC98, with the labeled provider names (the label is not UFS labels, but gpart ones). ditto. - The first dialog step should set the keyboard layout That *is* the first step. Inside the bsdinstaller, yes. The very first dialog step is the welcome page. Inside Shell or Live CD youl'll not get asked. - The /etc is not writable which would greatly reduce the usefulness for the ISO image (no modified resolv.conf, sshd_config, ...) This is only partly true. /etc/resolv.conf is a symlink into /tmp, which allows DHCP and network configuration to work. I still prefer a standard /etc with writable entries. Less special and more POLA. Thanks for your work on bsdinstaller anyhow! Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Fwd: [head tinderbox] failure on .. SCTP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Original Message Subject: [head tinderbox] failure on ia64/ia64 Date: Sat, 26 Feb 2011 18:55:22 GMT From: FreeBSD Tinderbox tinder...@freebsd.org To: FreeBSD Tinderbox tinder...@freebsd.org, curr...@freebsd.org, i...@freebsd.org stage 3.2: building everything [...] /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' /src/sys/netinet/sctp_sysctl.c:641: error: 'struct sctp_sysctl' has no member named 'sctp_rttvar_eqret' [ .. snip .. ] While it's likely that this is not what the author intended, the attached patch will allow the kernel to be built, imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk1ph1wACgkQQv9rrgRC1JJ0kACfYcM/p4w/MoLLcxWENoeih8VN d60AnRmrl6AnWT59/vwQD9LzIN/1nJJx =CxgS -END PGP SIGNATURE- Index: sys/netinet/sctp.h === --- sys/netinet/sctp.h (revision 219070) +++ sys/netinet/sctp.h (working copy) @@ -42,6 +42,8 @@ #define SCTP_PACKED __attribute__((packed)) +#define SCTP_HAS_RTTCC 1 + /* * SCTP protocol - RFC2960. */ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
rename on socket fails :-(
Just upgraded my mail-server to -current only to be greated by: Feb 18 16:26:00 mail authdaemond: modules=authpam, daemons=5 Feb 18 16:26:00 mail authdaemond: Installing libauthpam Feb 18 16:26:00 mail authdaemond: Installation complete: authpam Feb 18 16:26:00 mail authdaemond: /var/run/authdaemond/socket: Cross-device link Essentially, authdaemond creates /var/run/authdaemond/socket.tmp and then tries to rename it to the above. In releng7_4, this worked, on -current, it doesn't. What broke it? This is on a normal UFS2 + soft-updates file-system :-( imb pgpOcGMZOhYcE.pgp Description: PGP signature
Re: rename on socket fails :-(
On Sat, Feb 19, 2011 at 12:11:09AM +0200, Kostik Belousov wrote:
On Fri, Feb 18, 2011 at 04:53:30PM -0500, michael butler wrote:
Just upgraded my mail-server to -current only to be greated by:
Feb 18 16:26:00 mail authdaemond: modules=authpam, daemons=5
Feb 18 16:26:00 mail authdaemond: Installing libauthpam
Feb 18 16:26:00 mail authdaemond: Installation complete: authpam
Feb 18 16:26:00 mail authdaemond: /var/run/authdaemond/socket: Cross-device
link
Essentially, authdaemond creates /var/run/authdaemond/socket.tmp and then
tries to rename it to the above. In releng7_4, this worked, on -current, it
doesn't. What broke it? This is on a normal UFS2 + soft-updates file-system
:-(
Are you sure that /var/run/authdaemond/socket.tmp is
renamed to /var/run/authdaemond/socket ? Can you show the
ktrace/kdump output ?
The relevant section of ktrace.out is:
10905 authdaemond.bin CALL unlink(0xbfbfeadc)
10905 authdaemond.bin NAMI /var/run/authdaemond/socket.tmp
10905 authdaemond.bin RET unlink 0
10905 authdaemond.bin CALL bind(0x5,0xbfbfeada,0x6a)
10905 authdaemond.bin STRU struct sockaddr { AF_LOCAL,
/var/run/authdaemond/socket.tmp }
10905 authdaemond.bin NAMI /var/run/authdaemond/socket.tmp
10905 authdaemond.bin RET bind 0
10905 authdaemond.bin CALL listen(0x5,0x80)
10905 authdaemond.bin RET listen 0
10905 authdaemond.bin CALL
chmod(0xbfbfeadc,0x1ffS_IRUSR|S_IWUSR|S_IXUSR|S_IRGRP|S_IWGRP|S_IXGRP|S_IROTH|S_IWOTH|S_IXOTH)
10905 authdaemond.bin NAMI /var/run/authdaemond/socket.tmp
10905 authdaemond.bin RET chmod 0
10905 authdaemond.bin CALL rename(0xbfbfeadc,0x804b1c1)
10905 authdaemond.bin NAMI /var/run/authdaemond/socket.tmp
10905 authdaemond.bin NAMI /var/run/authdaemond/socket
10905 authdaemond.bin RET rename -1 errno 18 Cross-device link
I also made sure that the relevant components were properly linked against
the -current shared libs ..
imb@mail:/usr/local/libexec/courier-authlib ldd authdaemond
authdaemond:
libltdl.so.7 = /usr/local/lib/libltdl.so.7 (0x2809a000)
libcourierauthcommon.so =
/usr/local/lib/courier-authlib/libcourierauthcommon.so (0x280a2000)
libcourierauth.so =
/usr/local/lib/courier-authlib/libcourierauth.so (0x280a6000)
libc.so.7 = /lib/libc.so.7 (0x280b1000)
libcrypt.so.5 = /lib/libcrypt.so.5 (0x281cb000)
imb@mail:/usr/local/libexec/courier-authlib ldd
/usr/local/lib/courier-authlib/libcourierauth.so
/usr/local/lib/courier-authlib/libcourierauth.so:
libc.so.7 = /lib/libc.so.7 (0x2809a000)
imb@mail:/usr/local/libexec/courier-authlib ldd
/usr/local/lib/courier-authlib/libcourierauthcommon.so
/usr/local/lib/courier-authlib/libcourierauthcommon.so:
libcourierauth.so =
/usr/local/lib/courier-authlib/libcourierauth.so (0x281c5000)
libcrypt.so.5 = /lib/libcrypt.so.5 (0x281d)
libc.so.7 = /lib/libc.so.7 (0x2809a000)
imb@mail:/usr/local/libexec/courier-authlib ldd /usr/local/lib/libltdl.so.7
/usr/local/lib/libltdl.so.7:
libc.so.7 = /lib/libc.so.7 (0x2809a000)
pgpIickAMoMiC.pgp
Description: PGP signature
Re: rename on socket fails :-(
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/18/11 18:22, Kostik Belousov wrote:
The patch below fixed the bug for the test extracted from your kdump.
diff --git a/sys/ufs/ufs/ufs_vnops.c b/sys/ufs/ufs/ufs_vnops.c
index 084971e..34b1758 100644
--- a/sys/ufs/ufs/ufs_vnops.c
+++ b/sys/ufs/ufs/ufs_vnops.c
@@ -1295,7 +1295,9 @@ relock:
newparent = tdp-i_number;
doingdirectory = 1;
}
- if (fvp-v_mountedhere != NULL || (tvp tvp-v_mountedhere != NULL)) {
+ if ((fvp-v_type == VDIR fvp-v_mountedhere != NULL) ||
+ (tvp != NULL tvp-v_type == VDIR
+ tvp-v_mountedhere != NULL)) {
error = EXDEV;
goto unlockout;
}
To confirm - this fixes the issue - thanks!
imb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (FreeBSD)
iEYEARECAAYFAk1fHKMACgkQQv9rrgRC1JKt+ACgv6Cx9NVZapjDn0bMUskLs7jM
ym8An0YIQKWY0dcJ12qX9zV4c6ePzgD+
=JQxR
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: acpi_resource bug?
On 02/14/11 10:29, Matthew Fleming wrote: 1) should the length of the bcopy() be changed to either respect res-Length or the actual length of the ACPI_RESOURCE_DATA for the type? It should just use res-Length: Is there a guarantee that res-Length is = sizeof(ACPI_RESOURCE) ? I don't know if it's related or a different bug .. If I run 'acpidump -t', I get a core-dump and .. [ .. snip .. ] /* MCFG: Length=60, Revision=1, Checksum=74, OEMID=INTEL, OEM Table ID=CALISTGA, OEM Revision=0x604, Creator ID=LOHR, Creator Revision=0x5a Base Address=0xe000 Segment Group=0x Start Bus=0 End Bus=255 */ /* TCPA: Length=50, Revision=1, Checksum=153, OEMID=PTLTD, OEM Table ID=CALISTGA, OEM Revision=0x604, Creator ID= PTL, Creator Revision=0x1 Class 0 Base Address 0x0 Length 65536 -268370093 0xc3e200f053ff00f053ff00f054ff00f0de9100f0 [unknown 0xf000ff53] ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: unknown mtx_assert at /usr/src/sys/x86/x86/io_apic.c:161
On 1/14/11 8:55 PM, Michael Jung mi...@paymentallianceintl.com wrote: John: Thanks, I actually didn¹t see the MCA errors on the screen as the system has reloaded but noted them in the ddb.txt file last night. The Motherboard, CPU, Memory and PS were replaced today. I¹ll post back if this has or not corrected the problem but I suspect you are on target in that the hardware was defective. This machine was remote and I found the fan in the power supply not working, so I¹m suspecting that the CPU was or other logic was damaged. Thanks for your reply. --mikej On 1/14/11 4:13 PM, John Baldwin j...@freebsd.org wrote: On Thursday, January 13, 2011 11:26:46 am Michael Jung wrote: Links to crash info below. http://216.26.153.6/msgbuf.txt This might be a hardware problem. The panic you got is a should never happen panic. Note that in the code line sourced, the second argument to mtx_assert() is MA_OWNED. The panic is saying that it is some invalid value (i.e. something other than MA_OWNED). Given that is a constant, that's not very likely at all barring some hardware glitch. You do have a somewhat scary looking machine check logged before your panic: MCA: Bank 1, Status 0xd171 MCA: Global Cap 0x0105, Status 0x MCA: Vendor AuthenticAMD, ID 0x20fc2, APIC ID 0 MCA: CPU 0 COR OVER ICACHE L1 EVICT error It is a correctable error, but given the nature of the panic I'd suspect a hardware problem. mcelog doesn't provide many more details: HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 0 1 instruction cache bit62 = error overflow (multiple errors) memory/cache error 'evict mem transaction, instruction transaction, level 1' STATUS d171 MCGSTATUS 0 MCGCAP 105 APICID 0 SOCKETID 0 CPUID Vendor AMD Family 15 Model 44 -- John Baldwin The box has run fine since hardware was replaced. Thanks for you help. ---mikej CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4001 or notify us at PAI , Dept. 99, 11857 Commonwealth Drive, Louisville, KY 40299. Thank you. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
cosmetic nit in mmc.c
In the process of making the sdhci driver work with my laptop, I noted a cosmetic issue where the SD card's serial number is not correctly reported (it's always zero). Possible patch attached, imb Index: mmc.c === --- mmc.c (revision 217480) +++ mmc.c (working copy) @@ -749,7 +749,10 @@ uint32_t retval = bits[i] shift; if (size + shift 32) retval |= bits[i - 1] (32 - shift); - return (retval ((1 size) - 1)); +if (size 32) + return (retval ((1 size) - 1)); + else + return (retval); } static void ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: unknown mtx_assert at /usr/src/sys/x86/x86/io_apic.c:161
John: Thanks, I actually didn¹t see the MCA errors on the screen as the system has reloaded but noted them in the ddb.txt file last night. The Motherboard, CPU, Memory and PS were replaced today. I¹ll post back if this has or not corrected the problem but I suspect you are on target in that the hardware was defective. This machine was remote and I found the fan in the power supply not working, so I¹m suspecting that the CPU was or other logic was damaged. Thanks for your reply. --mikej On 1/14/11 4:13 PM, John Baldwin j...@freebsd.org wrote: On Thursday, January 13, 2011 11:26:46 am Michael Jung wrote: Links to crash info below. http://216.26.153.6/msgbuf.txt This might be a hardware problem. The panic you got is a should never happen panic. Note that in the code line sourced, the second argument to mtx_assert() is MA_OWNED. The panic is saying that it is some invalid value (i.e. something other than MA_OWNED). Given that is a constant, that's not very likely at all barring some hardware glitch. You do have a somewhat scary looking machine check logged before your panic: MCA: Bank 1, Status 0xd171 MCA: Global Cap 0x0105, Status 0x MCA: Vendor AuthenticAMD, ID 0x20fc2, APIC ID 0 MCA: CPU 0 COR OVER ICACHE L1 EVICT error It is a correctable error, but given the nature of the panic I'd suspect a hardware problem. mcelog doesn't provide many more details: HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 0 1 instruction cache bit62 = error overflow (multiple errors) memory/cache error 'evict mem transaction, instruction transaction, level 1' STATUS d171 MCGSTATUS 0 MCGCAP 105 APICID 0 SOCKETID 0 CPUID Vendor AMD Family 15 Model 44 -- John Baldwin CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4001 or notify us at PAI , Dept. 99, 11857 Commonwealth Drive, Louisville, KY 40299. Thank you. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
unknown mtx_assert at /usr/src/sys/x86/x86/io_apic.c:161
Links to crash info below. http://216.26.153.6/bounds http://216.26.153.6/config.txt http://216.26.153.6/ddb.txt http://216.26.153.6/info.1 http://216.26.153.6/msgbuf.txt http://216.26.153.6/panic.txt http://216.26.153.6/ version.txt http://216.26.153.6/%20version.txt CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4001 or notify us at PAI , Dept. 99, 11857 Commonwealth Drive, Louisville, KY 40299. Thank you. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: AHCI on ICH7
On 01/12/11 05:50, Anton Yuzhaninov wrote:
Is it possible to get AHCI working on this controller:
atap...@pci0:0:31:2:class=0x01018f card=0x72101462 chip=0x27c08086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = '82801GB/GR/GH (ICH7 Family) Serial ATA Storage
Controller'
class = mass storage
subclass = ATA
bar [10] = type I/O Port, range 32, base 0xe880, size 8, enabled
bar [14] = type I/O Port, range 32, base 0xe800, size 4, enabled
bar [18] = type I/O Port, range 32, base 0xe480, size 8, enabled
bar [1c] = type I/O Port, range 32, base 0xe400, size 4, enabled
bar [20] = type I/O Port, range 32, base 0xe080, size 16, enabled
cap 01[70] = powerspec 2 supports D0 D3 current D0
BIOS show that AHCI 1.0 supported.
I tried this patch with no success:
--- sys/dev/ahci/ahci.c (revision 217301)
+++ sys/dev/ahci/ahci.c (working copy)
@@ -129,6 +129,7 @@
{0x26838086, 0x00, Intel ESB2,0},
{0x27c18086, 0x00, Intel ICH7,0},
{0x27c38086, 0x00, Intel ICH7,0},
+ {0x27c08086, 0x00, Intel ICH7,0},
{0x27c58086, 0x00, Intel ICH7M, 0},
{0x27c68086, 0x00, Intel ICH7M, 0},
{0x28218086, 0x00, Intel ICH8,0},
Since this series is also supported in the ata-intel driver ..
{ ATA_I82801GB, 0, 0, 1, ATA_UDMA5, ICH7 },
{ ATA_I82801GB_S1, 0, 0, 0, ATA_SA300, ICH7 },
{ ATA_I82801GB_R1, 0, 0, 0, ATA_SA300, ICH7 },
{ ATA_I82801GB_AH, 0, INTEL_AHCI, 0, ATA_SA300, ICH7 },
{ ATA_I82801GBM_S1, 0, 0, 0, ATA_SA150, ICH7M },
{ ATA_I82801GBM_R1, 0, 0, 0, ATA_SA150, ICH7M },
{ ATA_I82801GBM_AH, 0, INTEL_AHCI, 0, ATA_SA150, ICH7M },
.. and it seems that PCIR_BAR(5) is already set as I/O, you could try
adding the INTEL_AHCI attribute to the entry for ATA_I82801GB_S1,
which matches your chip-id and see what happens.
I have not tried this - please make sure you have a full backup first!
imb
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: AHCI on ICH7
On 01/12/11 10:44, Alexander Motin wrote:
[ .. snip .. ]
PCIR_BAR(5) is not set in this case, only 0-4. It won't help.
Ugh! My bad .. the only other option is to adjust the entry in ahci.c
for that chip-id, find a suitably free memory window and do something
like the attached patch (set 'AHCI_MEM_HACK' to the base of whatever
window you can allocate).
I use this on a Toshiba A-105 laptop but, in the process, I lose the
ability to talk to the PATA DVD-drive (the reason why the manufacturer
set compatibility mode in the BIOS).
On the other hand it gets me the (huge!) benefits of NCQ ;-)
imb
*** src/sys/dev/ahci/ahci.c Sat May 22 12:07:12 2010
--- src/sys/dev/ahci/ahci.c-patched Sat May 22 08:10:36 2010
***
*** 129,134
--- 129,135
{0x26838086, 0x00, Intel ESB2,0},
{0x27c18086, 0x00, Intel ICH7,0},
{0x27c38086, 0x00, Intel ICH7,0},
+ {0x27c48086, 0x00, Intel ICH7M, 0},
{0x27c58086, 0x00, Intel ICH7M, 0},
{0x27c68086, 0x00, Intel ICH7M, 0},
{0x28218086, 0x00, Intel ICH8,0},
***
*** 324,334
--- 325,353
ctlr-quirks = ahci_ids[i].quirks;
resource_int_value(device_get_name(dev),
device_get_unit(dev), ccc, ctlr-ccc);
+
+ #define AHCI_MEM_HACK 0xF0D44400 /* 0xf0d443ff is the last used by
others on Toshiba A105 */
+
+ /* Need to set the SCRAE bit and ensure SCRD not set */
+ pci_write_config(dev, 0x94, (pci_read_config(dev, 0x94, 4) | 0x200)
~0x4000, 4);
+ /* enable MSE */
+ pci_write_config(dev, 0x4, (pci_read_config(dev, 0x4, 2) | 2), 2);
+ pci_write_config(dev, 0x24, AHCI_MEM_HACK, 4);
+ pci_write_config(dev, 0x90, 0x40, 1); /* AHCI + non-combined */
+
+ /* allocate a free memory window for BAR(5) */
+ ctlr-r_rid = PCIR_BAR(5);
+ bus_set_resource(dev, SYS_RES_MEMORY, ctlr-r_rid, AHCI_MEM_HACK,
0x400);
+
/* if we have a memory BAR(5) we are likely on an AHCI part */
ctlr-r_rid = PCIR_BAR(5);
if (!(ctlr-r_mem = bus_alloc_resource_any(dev, SYS_RES_MEMORY,
ctlr-r_rid, RF_ACTIVE)))
return ENXIO;
+
+ /* enable ICH7M ports in AHCI space */
+ ATA_OUTL(ctlr-r_mem, AHCI_PI, ATA_INL(ctlr-r_mem, AHCI_PI) | 5);
+
/* Setup our own memory management for channels. */
ctlr-sc_iomem.rm_start = rman_get_start(ctlr-r_mem);
ctlr-sc_iomem.rm_end = rman_get_end(ctlr-r_mem);
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
if_ether.c (svn revision 217315) breakage on i386
cc1: warnings being treated as errors /usr/home/imb/svn/head/sys/netinet/if_ether.c: In function 'in_arpinput': /usr/home/imb/svn/head/sys/netinet/if_ether.c:540: warning: format '%ld' expects type 'long int', but argument 3 has type 'unsigned int' *** Error code 1 .. where unsigned int is actually a sizeof(struct in_addr), imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Lock-up with CPU busy at r217145; seems OK now at r217189
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/09/11 12:57, David Wolfskill wrote: As usual, I have been tracking, building, booting head daily on my laptop for a while. Yesterday, having built head at r217090, I had updated to r217145, built, and booted it OK. (I then booted from my stable/8 slice for the rest of the day, as usual.) This morning, I updated to r217189, but on 3 out of 3 attempts to perform make -j4 buildworld while running head at r217145, the machine became unresponsive (while the fans were at top speed and the screen remained lit). I have DDB in the kernel config, but was unable to break to the debugger. I too have been seeing *really* odd things - dump randomly stops in the middle of a backup, automoc4 spawns a child during a KDE-4 build which turns into a zombie but is never seen to return and the build stalls - weird :-( Having checked out and built SVN revision 217202 - I'll try again .. imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk0qAEgACgkQQv9rrgRC1JL9xwCgyHO8V8EE2wEXYpVifE4WjWve h/oAnjmJgG8GzJTF9v/mQxR3q+VllWZ7 =mMUo -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: How a full fsck screwed up my SU+J filesystem
On 12/01/10 19:30, Kirk McKusick wrote:
[ .. snip .. ]
Thanks all: Garrett for the report, Peter for the way to reproduce
the problem, and Kostik for a fix. I have copied Jeff so that he can
confirm that Kostik's fix is the appropriate thing to do. And I will
take a look at fsck to see if I can make it a bit more paranoid about
removing .sujournal.
Kirk McKusick
There's another case that SU+J fails and the patch has not yet been
committed .. specifically, when configure tries to do a directory rename
test .. as below ..
I am uncertain but it seems that 'dump -L' exhibits a similar behaviour
.. completely hung on me at 1am this morning :-(
imb
Original Message
Subject: Re: softupdate with journal panic
Date: Tue, 24 Aug 2010 00:12:57 +0300
From: Kostik Belousov kostik...@gmail.com
To: Peter Holm p...@freebsd.org
CC: Michael Butler i...@protected-networks.net,Jeff Roberson
jrober...@jroberson.net, curr...@freebsd.org
On Sun, Aug 22, 2010 at 03:21:04PM +0200, Peter Holm wrote:
On Sat, Aug 21, 2010 at 01:49:45PM -0400, Michael Butler wrote:
While updating sysutils/coreutils port on -current as of this morning
(SVN r211550), I noted a panic during the directory rename config test.
Your problem seems identical to this report:
http://docs.freebsd.org/cgi/mid.cgi?AANLkTinPjiOV21kDLZYV5WScrhLMN7DY8E8jVHWPU5mC
I believe that dotdotremref in this case is legitimately NULL. With this
assumption, the following patch would help.
*** src/sys/ufs/ffs/ffs_softdep.c~ Fri Aug 20 18:10:34 2010
--- src/sys/ufs/ffs/ffs_softdep.c Mon Aug 23 22:14:48 2010
***
*** 6770,6776
mkdir-md_jaddref = NULL;
if (mkdir-md_state MKDIR_PARENT) {
if (cancel_jaddref(jaddref, NULL,
! dirrem-dm_jwork) == 0) {
free_jremref(dotdotremref);
dotdotremref = NULL;
}
--- 6770,6777
mkdir-md_jaddref = NULL;
if (mkdir-md_state MKDIR_PARENT) {
if (cancel_jaddref(jaddref, NULL,
! dirrem-dm_jwork) == 0
! dotdotremref != NULL) {
free_jremref(dotdotremref);
dotdotremref = NULL;
}
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
kern_sysctl.c compilation failure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Seems that 'treat warnings as errors' snags on this .. patch attached,
imb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (FreeBSD)
iEYEARECAAYFAkz0B/YACgkQQv9rrgRC1JKLBgCeNhKn2W6Z2XFN/zt70PbFhKbP
eHcAoIwI0Iz0g5TmU/pjbnG8zlcY6a1y
=a/KQ
-END PGP SIGNATURE-
*** src/sys/kern/kern_sysctl.c~ Mon Nov 29 14:02:22 2010
--- src/sys/kern/kern_sysctl.c Mon Nov 29 14:32:56 2010
***
*** 845,851
sysctl_sysctl_name2oid(SYSCTL_HANDLER_ARGS)
{
char *p;
! int error, oid[CTL_MAXNAME], len;
struct sysctl_oid *op = 0;
if (!req-newlen)
--- 845,851
sysctl_sysctl_name2oid(SYSCTL_HANDLER_ARGS)
{
char *p;
! int error, oid[CTL_MAXNAME], len = 0;
struct sysctl_oid *op = 0;
if (!req-newlen)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kern_sysctl.c compilation failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/29/10 15:25, Matthew Fleming wrote: On Mon, Nov 29, 2010 at 12:07 PM, Michael Butler i...@protected-networks.net wrote: Seems that 'treat warnings as errors' snags on this .. patch attached, Which compiler are you using? I didn't have any trouble with this file on a make universe last night... There's nothing wrong with the patch; I'd just like to understand why you see an error and I do not. gcc complains of 'len' being used uninitialized after SVN r216059, imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (FreeBSD) iEUEARECAAYFAkz0DykACgkQQv9rrgRC1JLWNQCY/ZlpeKnLBH80N4X/ENSbqLqo bQCgqFld9e7+eK2sntXzOcqe5y8e2j0= =NiUc -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on amd64/amd64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/26/10 19:00, FreeBSD Tinderbox wrote: [ .. ] cc1: warnings being treated as errors /src/sys/dev/ichwd/ichwd.c: In function 'ichwd_attach': /src/sys/dev/ichwd/ichwd.c:526: warning: implicit declaration of function 'ich_read_tco_2' /src/sys/dev/ichwd/ichwd.c:526: warning: nested extern declaration of 'ich_read_tco_2' *** Error code 1 This should likely be changed to 'ichwd_read_tco_2' imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzwTZsACgkQQv9rrgRC1JJ9AgCfTHDoDq9jOJ8iUPV6X7Y0KOMu XWAAn1BdwIWvjXJDmm+rcbrtMo153anE =ll7Z -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
something missing from r215781? (if_igb)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Seems there are a couple of defines missing from an e1000_hw.h === igb (all) [ .. snip .. ] /usr/home/imb/svn/head/sys/modules/igb/../../dev/e1000/if_igb.c:142: error: 'E1000_DEV_ID_DH89XXCC_SERDES' undeclared here (not in a function) /usr/home/imb/svn/head/sys/modules/igb/../../dev/e1000/if_igb.c:143: error: 'E1000_DEV_ID_DH89XXCC_SGMII' undeclared here (not in a function) *** Error code 1 1 error -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzsWX4ACgkQQv9rrgRC1JLk8ACbB6TesvKtbbHL55qyFTBIEYYf 3zUAoKEx2CJSWoYh/gp+XAvA+9uWaGZL =DHTC -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ATI Radeon HD 3200 / HP Laptop (Using)
I see that the Radeon HD 3200 needs r600_dri.so On the mailing list I saw on Dec 5, 2009 there was a patch here: http://lists.freebsd.org/pipermail/freebsd-ports/2009-December/058115.html Can anyone confirm that this was ever committed to FreeBSD Head and MFC;d 8.1 I cant get my 3D acceleration to work in KDE4 Cheerio! Michael -- Thanks, Michael Rusch rus...@gmail.com twitter - @weeddude ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
r212281 breaks KDE
For the last week, on and off, I've been looking for something that caused KDE to be horridly unstable, i.e. machine freezes with and without a core-dump. Removing r212281 (and r212282) restores that stability. Is there a race condition that this update exposes by reducing lock strength? The most common failure with this code included produces a back-trace similar to the one attached, imb toshi.auburn.protected-networks.net dumped core - see /var/crash/vmcore.0 Sat Sep 11 15:33:22 EDT 2010 FreeBSD toshi.auburn.protected-networks.net 9.0-CURRENT FreeBSD 9.0-CURRENT #5 r212466M: Sat Sep 11 10:10:59 EDT 2010 r...@toshi.auburn.protected-networks.net:/usr/obj/usr/home/imb/svn/head/sys/TOSHI i386 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x22c fault code = supervisor read, page not present instruction pointer = 0x20:0xc066705a stack pointer = 0x28:0xe944b7f8 frame pointer = 0x28:0xe944b810 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1938 (kdeinit4) trap number = 12 panic: page fault cpuid = 0 Uptime: 2m33s Physical memory: 3049 MB Dumping 225 MB: 210 194 178 162 146 130 114 98 82 66 50 34 18 2 Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/modules/vboxnetadp.ko...done. Loaded symbols for /boot/modules/vboxnetadp.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko #0 doadump () at pcpu.h:231 231 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:231 #1 0xc06760f7 in boot (howto=260) at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:416 #2 0xc06764e8 in panic (fmt=0x104 Address 0x104 out of bounds) at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:590 #3 0xc09950ff in trap_fatal (frame=0xe944b7b8, eva=40) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:980 #4 0xc0995469 in trap_pfault (frame=0xe944b7b8, usermode=0, eva=556) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:893 #5 0xc09958f7 in trap (frame=0xe944b7b8) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:568 #6 0xc097e16c in calltrap () at /usr/home/imb/svn/head/sys/i386/i386/exception.s:168 #7 0xc066705a in _mtx_lock_sleep (m=0xc81c26e8, tid=3343885696, opts=0, file=0x0, line=0) at /usr/home/imb/svn/head/sys/kern/kern_mutex.c:369 #8 0xc09385d8 in vnode_create_vobject (vp=0xc825a330, isize=512, td=0xc74fa580) at /usr/home/imb/svn/head/sys/vm/vnode_pager.c:111 #9 0xc0904751 in ufs_lookup_ino (vdp=0xc825a330, vpp=0xe944bb40, cnp=0xe944bb54, dd_ino=0x0) at /usr/home/imb/svn/head/sys/ufs/ufs/ufs_lookup.c:260 #10 0xc0905370 in ufs_lookup (ap=0xe944b97c) at /usr/home/imb/svn/head/sys/ufs/ufs/ufs_lookup.c:215 #11 0xc06f9cc6 in vfs_cache_lookup (ap=0xe944ba08) at vnode_if.h:80 #12 0xc09b2811 in VOP_LOOKUP_APV (vop=0xc0ac7480, a=0xe944ba08) at vnode_if.c:123 #13 0xc0700e89 in lookup (ndp=0xe944bb28) at vnode_if.h:54 #14 0xc070218c in namei (ndp=0xe944bb28) at /usr/home/imb/svn/head/sys/kern/vfs_lookup.c:268 #15 0xc0711513 in kern_statat_vnhook (td=0xc74fa580, flag=0, fd=-100, path=0x2b2aa050 Address 0x2b2aa050 out of bounds, pathseg=UIO_USERSPACE, sbp=0xe944bbe4, hook=0) at /usr/home/imb/svn/head/sys/kern/vfs_syscalls.c:2352 #16 0xc07116b7 in kern_statat (td=0xc74fa580, flag=0, fd=-100, path=0x2b2aa050 Address 0x2b2aa050 out of bounds, pathseg=UIO_USERSPACE, sbp=0xe944bbe4) at /usr/home/imb/svn/head/sys/kern/vfs_syscalls.c:2333 #17 0xc07117db in kern_stat (td=0xc74fa580, path=0x2b2aa050 Address 0x2b2aa050 out of bounds, pathseg=UIO_USERSPACE, sbp=0xe944bbe4) at /usr/home/imb/svn/head/sys/kern/vfs_syscalls.c:2325 #18 0xc071186f in stat (td=0xc74fa580, uap=0xe944bcec) at /usr/home/imb/svn/head/sys/kern/vfs_syscalls.c:2294 #19 0xc06b4087 in syscallenter (td=0xc74fa580, sa=0xe944bce4) at /usr/home/imb/svn/head/sys/kern/subr_trap.c:319 #20 0xc09954cc in syscall (frame=0xe944bd28) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:1095 #21 0xc097e1d1 in Xint0x80_syscall () at /usr/home/imb/svn/head/sys/i386/i386/exception.s:266 #22 0x0033 in ?? ()
Re: r212281 breaks KDE
On 09/12/10 12:19, Kostik Belousov wrote: On Sun, Sep 12, 2010 at 10:42:57AM -0400, Michael Butler wrote: Removing r212281 (and r212282) restores that stability. Is there a race condition that this update exposes by reducing lock strength? [ .. ] Does the following change make any difference to you ? It made it worse :-( Frozen just as X tries to take over the display, imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Sleep/Lenovo SL410
On 08/23/10 21:49, Matt wrote: Please note atrtc0 error in dmesg? [ .. ] atrtc0: AT realtime clock port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. atrtc0: [FILTER] I get this on a Toshiba A105 but it doesn't seem to hurt anything, imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: softupdate with journal panic
On 08/23/10 17:12, Kostik Belousov wrote:
On Sun, Aug 22, 2010 at 03:21:04PM +0200, Peter Holm wrote:
On Sat, Aug 21, 2010 at 01:49:45PM -0400, Michael Butler wrote:
While updating sysutils/coreutils port on -current as of this morning
(SVN r211550), I noted a panic during the directory rename config test.
Your problem seems identical to this report:
http://docs.freebsd.org/cgi/mid.cgi?AANLkTinPjiOV21kDLZYV5WScrhLMN7DY8E8jVHWPU5mC
I believe that dotdotremref in this case is legitimately NULL. With this
assumption, the following patch would help.
Confirmed - with the patch below, it works as expected; thanks!
imb
diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c
index b666c0f..65e5255 100644
--- a/sys/ufs/ffs/ffs_softdep.c
+++ b/sys/ufs/ffs/ffs_softdep.c
@@ -6770,7 +6794,8 @@ cancel_diradd(dap, dirrem, jremref, dotremref,
dotdotremref)
mkdir-md_jaddref = NULL;
if (mkdir-md_state MKDIR_PARENT) {
if (cancel_jaddref(jaddref, NULL,
- dirrem-dm_jwork) == 0) {
+ dirrem-dm_jwork) == 0
+ dotdotremref != NULL) {
free_jremref(dotdotremref);
dotdotremref = NULL;
}
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
softupdate with journal panic
While updating sysutils/coreutils port on -current as of this morning (SVN r211550), I noted a panic during the directory rename config test. I disabled the journal and the test succeeded without a panic. Abbreviated core.txt is attached, imb toshi.auburn.protected-networks.net dumped core - see /var/crash/vmcore.4 Sat Aug 21 13:27:54 EDT 2010 FreeBSD toshi.auburn.protected-networks.net 9.0-CURRENT FreeBSD 9.0-CURRENT #22 r211550M: Sat Aug 21 07:49:50 EDT 2010 r...@toshi.auburn.protected-networks.net:/usr/obj/usr/home/imb/svn/head/sys/TOSHI i386 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x18 fault code = supervisor read, page not present instruction pointer = 0x20:0xc08da5c5 stack pointer = 0x28:0xe8d65870 frame pointer = 0x28:0xe8d65878 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 49855 (conftest) trap number = 12 panic: page fault cpuid = 1 Uptime: 4h35m14s Physical memory: 3049 MB Dumping 305 MB: 290 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2 Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/modules/vboxnetadp.ko...done. Loaded symbols for /boot/modules/vboxnetadp.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko #0 doadump () at pcpu.h:231 231 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:231 #1 0xc066b627 in boot (howto=260) at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:416 #2 0xc066ba18 in panic (fmt=0x104 Address 0x104 out of bounds) at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:590 #3 0xc098a5cf in trap_fatal (frame=0xe8d65830, eva=40) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:941 #4 0xc098a939 in trap_pfault (frame=0xe8d65830, usermode=0, eva=24) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:854 #5 0xc098adc7 in trap (frame=0xe8d65830) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:529 #6 0xc097363c in calltrap () at /usr/home/imb/svn/head/sys/i386/i386/exception.s:166 #7 0xc08da5c5 in free_jremref (jremref=0x0) at /usr/home/imb/svn/head/sys/ufs/ffs/ffs_softdep.c:3569 #8 0xc08e4ef3 in cancel_diradd (dap=0xce4d1e40, dirrem=0xcba243c0, jremref=0x0, dotremref=0xc9c0d440, dotdotremref=0x0) at /usr/home/imb/svn/head/sys/ufs/ffs/ffs_softdep.c:6774 #9 0xc08e514f in newdirrem (bp=0xda12ecec, dp=0xc9c0d440, ip=0xcd20a32c, isrmdir=1, prevdirremp=0xe8d65914) at /usr/home/imb/svn/head/sys/ufs/ffs/ffs_softdep.c:7197 #10 0xc08e560b in softdep_setup_directory_change (bp=0xda12ecec, dp=0xcd354a6c, ip=0xcd20a32c, newinum=10389760, isrmdir=1) at /usr/home/imb/svn/head/sys/ufs/ffs/ffs_softdep.c:7263 #11 0xc08f8c76 in ufs_dirrewrite (dp=0xcd354a6c, oip=0xcd20a32c, newinum=10389760, newtype=4, isrmdir=1) at /usr/home/imb/svn/head/sys/ufs/ufs/ufs_lookup.c:1304 #12 0xc0904757 in ufs_rename (ap=0xe8d65be8) at /usr/home/imb/svn/head/sys/ufs/ufs/ufs_vnops.c:1429 #13 0xc09a7287 in VOP_RENAME_APV (vop=0xc0ab7720, a=0xe8d65be8) at vnode_if.c:1474 #14 0xc070daeb in kern_renameat (td=0xc7117b00, oldfd=-100, old=0x8048511 Address 0x8048511 out of bounds, newfd=-100, new=0x8048505 Address 0x8048505 out of bounds, pathseg=UIO_USERSPACE) at vnode_if.h:636 #15 0xc070db51 in kern_rename (td=0xc7117b00, from=0x8048511 Address 0x8048511 out of bounds, to=0x8048505 Address 0x8048505 out of bounds, pathseg=UIO_USERSPACE) at /usr/home/imb/svn/head/sys/kern/vfs_syscalls.c:3574 #16 0xc070db7c in rename (td=0xc7117b00, uap=0xe8d65cec) at /usr/home/imb/svn/head/sys/kern/vfs_syscalls.c:3551 #17 0xc06a93c7 in syscallenter (td=0xc7117b00, sa=0xe8d65ce4) at /usr/home/imb/svn/head/sys/kern/subr_trap.c:319 #18 0xc098a99c in syscall (frame=0xe8d65d28) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:1056 #19 0xc09736a1 in Xint0x80_syscall () at /usr/home/imb/svn/head/sys/i386/i386/exception.s:264 #20 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) ___ freebsd-current@freebsd.org mailing list
Re: Interpreted language(s) in the base
On Mon, 16 Aug 2010, Poul-Henning Kamp wrote: ... PS: The sickening irony is that today we have two embedded languages, one in the kernel even, and it is the most crappy ones you can imagine: Forth and ACPI. Besides the syntax FORTH ist the only embeddable high level language which has both intepreter and compiler built in. It has a small form factor too. One alternative could be something like WABA (http://waba.sourceforge.net/). Besides the wrong license it would mean to have pre-compiled byte code on the FS and no chance to recompile on the fly... Or ECMAScript as a pure interpreted language. Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Apache 2.2 port and missing modules on current.
Hi, This bit me as well. Some experimentation showed that a few apache functions are now compiled in, rather than being modules. Don't know why. Editing httpd.conf to remove the items that were no longer modules restored service. ==ml On Tue, Aug 10, 2010 at 05:52:43PM +0200, Bartosz Stec wrote: On 2010-08-10 17:23, Ilya A. Arhipov wrote: make config and add [x] THREADS Enable threads support in APR :) and deinstall reinstall 10.08.10, 18:07, Bartosz Stecad...@kkip.pl: Arrgh! My mistake - I showed generic /usr/ports/www/apache22/Makefile.options instead of /var/db/ports/apache22/options. So here's the correct one: # This file is auto-generated by 'make config'. # No user-servicable parts inside! # Options for apache-2.2.16 _OPTIONS_READ=apache-2.2.16 WITH_THREADS=true WITHOUT_MYSQL=true WITHOUT_PGSQL=true WITHOUT_SQLITE=true WITH_IPV6=true WITHOUT_BDB=true WITH_AUTH_BASIC=true WITH_AUTH_DIGEST=true WITH_AUTHN_FILE=true WITHOUT_AUTHN_DBD=true WITH_AUTHN_DBM=true WITH_AUTHN_ANON=true WITH_AUTHN_DEFAULT=true WITH_AUTHN_ALIAS=true WITH_AUTHZ_HOST=true WITH_AUTHZ_GROUPFILE=true WITH_AUTHZ_USER=true WITH_AUTHZ_DBM=true WITH_AUTHZ_OWNER=true WITH_AUTHZ_DEFAULT=true WITH_CACHE=true WITH_DISK_CACHE=true WITH_FILE_CACHE=true WITHOUT_MEM_CACHE=true WITH_DAV=true WITH_DAV_FS=true WITHOUT_BUCKETEER=true WITHOUT_CASE_FILTER=true WITHOUT_CASE_FILTER_IN=true WITHOUT_EXT_FILTER=true WITHOUT_LOG_FORENSIC=true WITHOUT_OPTIONAL_HOOK_EXPORT=true WITHOUT_OPTIONAL_HOOK_IMPORT=true WITHOUT_OPTIONAL_FN_IMPORT=true WITHOUT_OPTIONAL_FN_EXPORT=true WITHOUT_LDAP=true WITHOUT_AUTHNZ_LDAP=true WITH_ACTIONS=true WITH_ALIAS=true WITH_ASIS=true WITH_AUTOINDEX=true WITH_CERN_META=true WITH_CGI=true WITH_CHARSET_LITE=true WITHOUT_DBD=true WITH_DEFLATE=true WITH_DIR=true WITH_DUMPIO=true WITH_ENV=true WITH_EXPIRES=true WITH_HEADERS=true WITH_IMAGEMAP=true WITH_INCLUDE=true WITH_INFO=true WITH_LOG_CONFIG=true WITH_LOGIO=true WITH_MIME=true WITH_MIME_MAGIC=true WITH_NEGOTIATION=true WITH_REWRITE=true WITH_SETENVIF=true WITH_SPELING=true WITH_STATUS=true WITH_UNIQUE_ID=true WITH_USERDIR=true WITH_USERTRACK=true WITH_VHOST_ALIAS=true WITH_FILTER=true WITH_VERSION=true WITHOUT_PROXY=true WITH_PROXY_CONNECT=true WITH_PATCH_PROXY_CONNECT=true WITHOUT_PROXY_FTP=true WITHOUT_PROXY_HTTP=true WITHOUT_PROXY_AJP=true WITHOUT_PROXY_BALANCER=true WITHOUT_PROXY_SCGI=true WITH_SSL=true WITHOUT_SUEXEC=true WITHOUT_SUEXEC_RSRCLIMIT=true WITH_REQTIMEOUT=true WITHOUT_CGID=true And just for case output of of apr1 options file: # This file is auto-generated by 'make config'. # No user-servicable parts inside! # Options for apr-ipv6-devrandom-gdbm-db42-1.4.2.1.3.9_1 _OPTIONS_READ=apr-ipv6-devrandom-gdbm-db42-1.4.2.1.3.9_1 WITH_THREADS=true WITH_IPV6=true WITH_BDB=true WITH_GDBM=true WITHOUT_LDAP=true WITHOUT_MYSQL=true WITHOUT_NDBM=true WITHOUT_PGSQL=true WITHOUT_SQLITE=true WITH_DEVRANDOM=true As you see, threads are enabled in both, but still it shouldn't have any effect on mod_cache, but only on mod_mem_cache, which is _disabled_. -- Bartosz Stec ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Michael W. Lucasmwlu...@blackhelicopters.org http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ New book available: Network Flow Analysis http://www.networkflowanalysis.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: k3b causing system freeze/panic
On 08/01/10 23:03, I wrote: Sadly, I still haven't been able to identify where the buffer address in the request structure is one of: left unset, gets lost or corrupted :-( Happens with k3b-kde4 too. I am assuming that this is as a consequence of the ATA_CAM code-path. I don't recall ever having this issue prior to switching disk names to ada from ad, I can confirm this behaviour - switching back to the ad device and using atapicam to access the DVD works correctly. My only conclusion is that it's a regression in the ATA_CAM code-path, imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: k3b causing system freeze/panic
On 07/28/10 04:27, Andriy Gapon wrote: You do realize that ATA_CAM just (well, mostly) introduces a wrapper around the now aging ATA driver ? No magic pixie dust to fix the bugs in it, but perhaps more ways to expose them. Sadly, I still haven't been able to identify where the buffer address in the request structure is one of: left unset, gets lost or corrupted :-( Happens with k3b-kde4 too. I am assuming that this is as a consequence of the ATA_CAM code-path. I don't recall ever having this issue prior to switching disk names to ada from ad, imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
k3b causing system freeze/panic
I have a custom kernel for my laptop which uses ATA_CAM rather than the
now aging ATA driver ..
In the case that the kernel compilation options KDB and DDB are enabled,
k3b will simply freeze. Without them, I managed to catch this panic:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0xbfbea376
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc04d96d7
stack pointer = 0x28:0xe6a92be4
frame pointer = 0x28:0xe6a92c10
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 12 (irq15: ata1)
trap number = 12
panic: page fault
cpuid = 1
Uptime: 3m18s
Physical memory: 3049 MB
Dumping 212 MB: 197 181 165 149 133 117 101 85 69 53 37 21 5
Reading symbols from /boot/modules/vboxdrv.ko...done.
Loaded symbols for /boot/modules/vboxdrv.ko
Reading symbols from /boot/modules/vboxnetflt.ko...done.
Loaded symbols for /boot/modules/vboxnetflt.ko
Reading symbols from /boot/modules/vboxnetadp.ko...done.
Loaded symbols for /boot/modules/vboxnetadp.ko
Reading symbols from /usr/local/modules/fuse.ko...done.
Loaded symbols for /usr/local/modules/fuse.ko
#0 doadump () at pcpu.h:231
231 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:231
#1 0xc067bbe7 in boot (howto=260) at
/usr/home/imb/svn/head/sys/kern/kern_shutdown.c:416
#2 0xc067bff7 in panic (fmt=0x104 Address 0x104 out of bounds) at
/usr/home/imb/svn/head/sys/kern/kern_shutdown.c:590
#3 0xc0998a1a in trap_fatal (frame=0xe6a92ba4, eva=40) at
/usr/home/imb/svn/head/sys/i386/i386/trap.c:945
#4 0xc0998d7f in trap_pfault (frame=0xe6a92ba4, usermode=0,
eva=3216941942) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:858
#5 0xc0999207 in trap (frame=0xe6a92ba4) at
/usr/home/imb/svn/head/sys/i386/i386/trap.c:533
#6 0xc09819ac in calltrap () at
/usr/home/imb/svn/head/sys/i386/i386/exception.s:166
#7 0xc04d96d7 in ata_pio_read (request=0xc7037424, length=18) at
cpufunc.h:217
#8 0xc04dae8f in ata_end_transaction (request=0xc7037424) at
/usr/home/imb/svn/head/sys/dev/ata/ata-lowlevel.c:392
#9 0xc04d70da in ata_interrupt_locked (data=Variable data is not
available.
) at /usr/home/imb/svn/head/sys/dev/ata/ata-all.c:548
#10 0xc04d7142 in ata_interrupt (data=0xc64b5400) at
/usr/home/imb/svn/head/sys/dev/ata/ata-all.c:512
#11 0xc065476a in intr_event_execute_handlers (p=0xc618b7f8,
ie=0xc61d3d00) at /usr/home/imb/svn/head/sys/kern/kern_intr.c:1220
#12 0xc0655e8d in ithread_loop (arg=0xc64bb4c0) at
/usr/home/imb/svn/head/sys/kern/kern_intr.c:1233
#13 0xc065236d in fork_exit (callout=0xc0655e27 ithread_loop,
arg=0xc64bb4c0, frame=0xe6a92d28) at
/usr/home/imb/svn/head/sys/kern/kern_fork.c:843
#14 0xc0981a24 in fork_trampoline () at
/usr/home/imb/svn/head/sys/i386/i386/exception.s:273
It seems that, since this was an interrupt service of some form,
dropping into KDB isn't working .. however, by the time we get to
ata_pio_read something has gone awry with the buffer address in the
request ..
(kgdb) up 7
(kgdb) info args
request = (struct ata_request *) 0xc7037424
length = 18
(kgdb) print *request
$1 = {dev = 0x0, parent = 0xc6450700, unit = 0, u = {ata = {command = 3
'\003', feature = 0, count = 18, lba = 0}, atapi = {
ccb =
\003\020\000\000\022\000\000\000\000\000\000\000\000\000\000, sense =
{error = 0 '\0', segment = 0 '\0', key = 0 '\0', cmd_info = 0,
sense_length = 0 '\0', cmd_specific_info = 0, asc = 0 '\0', ascq
= 0 '\0', replaceable_unit_code = 0 '\0', specific = 0 '\0', specific1 =
0 '\0',
specific2 = 0 '\0'}, saved_cmd = 0 '\0'}}, bytecount = 18,
transfersize = 18,
data = 0xbfbea376 Address 0xbfbea376 out of bounds, --***
tag = 0, flags = 8,
dma = 0x0, status = 88 'X', error = 0 '\0', donecount = 0, result = 0,
callback = 0, done = {sema_mtx = {lock_object = {lo_name = 0x0, lo_flags
= 0, lo_data = 0,
lo_witness = 0x0}, mtx_lock = 0}, sema_cv = {cv_description =
0x0, cv_waiters = 0}, sema_waiters = 0, sema_value = 0}, retries = 0,
timeout = 30,
callout = {c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0,
tqe_prev = 0xda0cd670}}, c_time = 227742, c_arg = 0xc7037424,
c_func = 0xc04dcf74 ata_timeout, c_lock = 0xc64b5574, c_flags =
22, c_cpu = 0}, task = {ta_running = 0x0, ta_link = {stqe_next = 0x0},
ta_pending = 0,
ta_priority = 0, ta_func = 0, ta_context = 0x0}, bio = 0x0, this =
0, composite = 0x0, driver = 0x0, chain = {tqe_next = 0x0, tqe_prev =
0x0}, ccb = 0xc6f7a000}
(kgdb) up 2
#9 0xc04d70da in ata_interrupt_locked (data=Variable data is not
available.
) at /usr/home/imb/svn/head/sys/dev/ata/ata-all.c:548
548 if (ch-hw.end_transaction(request) == ATA_OP_FINISHED) {
Current language: auto; currently c
(kgdb) print *ch
$3 = {dev = 0xc6450700, unit = 1, attached =
Re: making dependencies breaks between r210462 and r210495?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/26/10 09:55, David Wolfskill wrote: This is for GENERIC i386 kernel, running on head at r210462, sources updated to r210495: [ .. ] === usr.bin/kdump (depend) sh /usr/src/usr.bin/kdump/mkioctls /usr/obj/usr/src/tmp/usr/include ioctl.c sh /usr/src/usr.bin/kdump/mksubr /usr/obj/usr/src/tmp/usr/include kdump_subr.c stdin:1:31: error: altq/altq.h:#define: No such file or directory This was a breakage in the new BSD grep .. 1) update your sources 2) cd /usr/src/usr.bin/grep 3) make clean all install 4) reattempt buildworld/buildkernel imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxNoB4ACgkQQv9rrgRC1JKK3QCeNh8jjA/AfMqoyX0e10cLu+iW cPEAn15ZvW0F+3hbPoUU9CRF2SEg0fgg =axny -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problem with ZFS version 15
After reinitialized my gpt scheme, i can successfully import my zpool. After this there was a little bit trouble with my zpool.cache and booting from my pool, but now it works. Thank you to all for your help, Michael Am 20.07.2010 13:30, schrieb Michael Gusek: -Urspr?ngliche Nachricht- Von: Andrey V. Elsukov bu7c...@yandex.ru Gesendet: 20.07.2010 12:47:49 An: Michael Gusek michael.gu...@web.de Betreff: Re: Problem with ZFS version 15 On 20.07.2010 13:51, Michael Gusek wrote: and apply a new bootloader: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad0|ad1. After this, i've lost my gpt scheme ! gpart show ad0 says gpart: No such geom: ad0. How can i recover my gpt on ad0 and ad1 ? I'm running a zfs mirror on ad0 and ad1. It is very strange why this command broke your GPT. Actually incorrect PMBR can prevent probes for GEOM_PART_GPT. Yes, this is very strange. I don't have such a backup, only the whole disk for now. Everything else what can i do ? What if i initialize the gpt header: gpart create -s GPT ad0 ? Do i lost my data ? GPT headers and tables will be initialized. After that you should add all partitions with exactly same offsets and sizes. In this case your data will not be touched. Ok, i will try it. I did a backup of the first 16GB of my disk, because i don't know the exact size of my swap partition, but this is my part. Thank you, Michael -- WBR, Andrey V. Elsukov ___ GRATIS für alle WEB.DE Nutzer: Die maxdome Movie-FLAT! Jetzt freischalten unter http://movieflat.web.de ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problem with ZFS version 15
-Ursprüngliche Nachricht- Von: Xin LI delp...@delphij.net Gesendet: 19.07.2010 23:20:28 An: Michael Gusek michael.gu...@web.de Betreff: Re: Problem with ZFS version 15 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On 2010/07/17 06:40, Michael Gusek wrote: Hi, i updated my 8.1-PRERELEASE to ZFS version 15. The patch http://people.freebsd.org/~mm/patches/zfs/v15/head-v15-v3.patch applies fine and after reboot i upgrade my pool successfully to version 15. Now, after a new reboot the bootloader can't boot from version 15, it supports only 13. Well, i build a bootable usb pen with 8.1-PRERELEASE and ZFS version 15, boot from it and apply a new bootloader: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad0|ad1. After this, i've lost my gpt scheme ! gpart show ad0 says gpart: No such geom: ad0. How can i recover my gpt on ad0 and ad1 ? I'm running a zfs mirror on ad0 and ad1. If you have previous saved gpart information (e.g. start/end) then you can safely destroy and re-create the GPT partitions without destroying the data. Note that you may need to backup and dd the first and last sector of your hard drive before proceeding. I don't have such a backup, only the whole disk for now. Everything else what can i do ? What if i initialize the gpt header: gpart create -s GPT ad0 ? Do i lost my data ? Micha Cheers, Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMRMGcAAoJEATO+BI/yjfBbVUIAMIKRxUKMRpEdDJkPKqE3hZJ sjCUm8XveedJHVz2SupvpsQizo/hKDkgksfzeqeRd8JA1g4jerORLCNYilpcwMfc 2AiyjgvpKbsYmT27WcG4Grnl3eE4jFF+7Wm8B8WtuzE7L+YMo+QcEYiSPzL8P8hJ 1+RwLas/4nVkaDWWBW9osanLYT1v62zIN0ik1bnZypY3kYuprfJN3G7ZCKVX7ffD 4AZr7bvO57mcQOXON9gkmOMfewt89lNJiMYf5yQiGX+BL/i3pYUGSj2kt1Yc0su5 y5NyC42wiUNVEn15pVsIS5AUJVHs574pZBH2+DX5DfvDZMgxCkcUxgKq08QVnjE= =qQgN -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ GRATIS für alle WEB.DE Nutzer: Die maxdome Movie-FLAT! Jetzt freischalten unter http://movieflat.web.de ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problem with ZFS version 15
-Urspr?ngliche Nachricht- Von: Andrey V. Elsukov bu7c...@yandex.ru Gesendet: 20.07.2010 12:47:49 An: Michael Gusek michael.gu...@web.de Betreff: Re: Problem with ZFS version 15 On 20.07.2010 13:51, Michael Gusek wrote: and apply a new bootloader: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad0|ad1. After this, i've lost my gpt scheme ! gpart show ad0 says gpart: No such geom: ad0. How can i recover my gpt on ad0 and ad1 ? I'm running a zfs mirror on ad0 and ad1. It is very strange why this command broke your GPT. Actually incorrect PMBR can prevent probes for GEOM_PART_GPT. Yes, this is very strange. I don't have such a backup, only the whole disk for now. Everything else what can i do ? What if i initialize the gpt header: gpart create -s GPT ad0 ? Do i lost my data ? GPT headers and tables will be initialized. After that you should add all partitions with exactly same offsets and sizes. In this case your data will not be touched. Ok, i will try it. I did a backup of the first 16GB of my disk, because i don't know the exact size of my swap partition, but this is my part. Thank you, Michael -- WBR, Andrey V. Elsukov ___ GRATIS für alle WEB.DE Nutzer: Die maxdome Movie-FLAT! Jetzt freischalten unter http://movieflat.web.de signature.asc Description: OpenPGP digital signature
Problem with ZFS version 15
Hi, i updated my 8.1-PRERELEASE to ZFS version 15. The patch http://people.freebsd.org/~mm/patches/zfs/v15/head-v15-v3.patch applies fine and after reboot i upgrade my pool successfully to version 15. Now, after a new reboot the bootloader can't boot from version 15, it supports only 13. Well, i build a bootable usb pen with 8.1-PRERELEASE and ZFS version 15, boot from it and apply a new bootloader: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad0|ad1. After this, i've lost my gpt scheme ! gpart show ad0 says gpart: No such geom: ad0. How can i recover my gpt on ad0 and ad1 ? I'm running a zfs mirror on ad0 and ad1. Michael ___ Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Dell Perc 5/i Performance issues
On Sat, 19 Jun 2010, oizs wrote: Date: Sat, 19 Jun 2010 02:27:05 +0200 From: oizs o...@freemail.hu To: freebsd-current@freebsd.org Subject: Re: Dell Perc 5/i Performance issues Im using the Samsung F3 disks, which can do 140MB/s sequentially. I have tried different raids raid0 will do just as bad as raid5. I even tried one disk which performed as expected 100MB/s+ reads and writes so I'm not sure anymore what could be the problem. Maybe the controller hates samsung disks? I have a 8-disk Samsung F1/F3 mixed setup under FreeBSD-current: (fs)(root) mfiutil show drives mfi0 Physical Drives: ( 932G) ONLINE SAMSUNG HD103UJ 1118 serial=S13PJDWS500394 SATA slot 0 ( 932G) ONLINE SAMSUNG HD103UJ 1118 serial=S13PJDWS500033 SATA slot 1 ( 932G) ONLINE SAMSUNG HD103UJ 1113 serial=S13PJDWQC28106 SATA slot 2 ( 932G) ONLINE SAMSUNG HD103UJ 1113 serial=S13PJDWQC28108 SATA slot 3 ( 932G) ONLINE SAMSUNG HD103UJ 1104 serial=S13PJ1EPB00232 SATA slot 4 ( 932G) ONLINE ST31000340AS SD1A serial=9QJ18R8B SATA slot 5 ( 932G) ONLINE SAMSUNG HD103UJ 1104 serial=S13PJ1EPB00066 SATA slot 6 ( 932G) ONLINE SAMSUNG HD103UJ 1104 serial=S13PJ1EPB00602 SATA slot 7 The disks are organized as JBOD disks. Later on they form one ZFS pool: config: NAME STATE READ WRITE CKSUM xONLINE 0 0 0 mirror ONLINE 0 0 0 mfid0p4 ONLINE 0 0 0 mfid1p4 ONLINE 0 0 0 mirror ONLINE 0 0 0 mfid2p4 ONLINE 0 0 0 mfid3p4 ONLINE 0 0 0 mirror ONLINE 0 0 0 mfid4p4 ONLINE 0 0 0 mfid5p4 ONLINE 0 0 0 mirror ONLINE 0 0 0 mfid6p4 ONLINE 0 0 0 mfid7p4 ONLINE 0 0 0 ada0p3 ONLINE 0 0 0 (ada0 is there because mfid6 had some unreadable blocks lately) I get ~370MiB/s writing performance using `iozone -s10g -r1m`. While my samsung disks are problematic in the area of reliability (I get occasional parity mismatches or read errors), performance is good. Have you enabled the disk caches as well? Something like: MegaCli -LdSetProp Cached -LALL -a0 MegaCli -LdSetProp NORA -LALL -a0 MegaCli -LdSetProp WB -LALL -a0 MegaCli -LdSetProp -EnDskCache -LALL -a0 (Only if having a USV of course) Dunno if there is a mfiutil equivalent though. Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Dell Perc 5/i Performance issues
On Sat, 19 Jun 2010, pluknet wrote: ... MegaCli -LdSetProp Cached -LALL -a0 MegaCli -LdSetProp NORA -LALL -a0 MegaCli -LdSetProp WB -LALL -a0 MegaCli -LdSetProp -EnDskCache -LALL -a0 (Only if having a USV of course) Dunno if there is a mfiutil equivalent though. Hi. That would be: mfiutil cache mfid0 enable mfiutil cache mfid0 read-ahead none mfiutil cache mfid0 write-back mfiutil cache mfid0 write-cache enable Thanks! Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on ia64/ia64
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/10/10 19:11, FreeBSD Tinderbox wrote:
cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc
-I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common
-finline-limit=15000 --param inline-unit-growth=100 --param
large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13
-mfixed-range=f32-f127 -fpic -ffreestanding -Werror
/src/sys/net80211/ieee80211_sta.c
/src/sys/net80211/ieee80211_sta.c: In function 'sta_input':
/src/sys/net80211/ieee80211_sta.c:587: error: expected ')' before '!' token
*** Error code 1
I *think* this is supposed to be ..
if (HAS_SEQ(type) !IEEE80211_IS_MULTICAST(wh-i_addr1)) {
imb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (FreeBSD)
iEYEARECAAYFAkwRdRsACgkQQv9rrgRC1JLQ9ACfVPINlwHR8g0hXt0wenp5esfj
FooAnidIAWqJr9fJ3wQ8nhtEZtj9d0VG
=errN
-END PGP SIGNATURE-
*** /usr/src/sys/net80211/ieee80211_sta.c~ Thu Jun 10 17:53:24 2010
--- /usr/src/sys/net80211/ieee80211_sta.c Thu Jun 10 19:15:42 2010
***
*** 584,590
}
IEEE80211_RSSI_LPF(ni-ni_avgrssi, rssi);
ni-ni_noise = nf;
! if (HAS_SEQ(type) !IEEE80211_IS_MULTICAST(wh-i_addr1)) {
uint8_t tid = ieee80211_gettid(wh);
if (IEEE80211_QOS_HAS_SEQ(wh)
TID_TO_WME_AC(tid) = WME_AC_VI)
--- 584,590
}
IEEE80211_RSSI_LPF(ni-ni_avgrssi, rssi);
ni-ni_noise = nf;
! if (HAS_SEQ(type) !IEEE80211_IS_MULTICAST(wh-i_addr1)) {
uint8_t tid = ieee80211_gettid(wh);
if (IEEE80211_QOS_HAS_SEQ(wh)
TID_TO_WME_AC(tid) = WME_AC_VI)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SUJ and mount reporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/30/10 19:54, Ivan Voras wrote: Shouldn't SU+J be visible in the output of mount somehow? I've just enabled it on a root file system of a machine and while tunefs and dumpfs report both soft-updates and SUJ are enabled (after reboot), the mount command only shows soft-updates. Alternative question: how to verify is it active on a live file system? tunefs -p file-system works even when the file-system is mounted in multi-user mode, e.g. i...@toshi:/home/imb tunefs -p / tunefs: POSIX.1e ACLs: (-a)disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: average file size: (-f)16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L) imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkwC/dQACgkQQv9rrgRC1JKzagCgiviuFD/uTunc5bYQvkjvnT0j p1IAn3OJ8af8W4Jjj34cZVUyX4EMDk32 =cw0I -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: GPT on amd64 and boot managers
On Thu, 27 May 2010, Alban Hertroys wrote: Date: Thu, 27 May 2010 10:49:44 +0200 From: Alban Hertroys dal...@solfertje.student.utwente.nl To: FreeBSD Current curr...@freebsd.org Subject: GPT on amd64 and boot managers Good day, Yesterday I finally changed my FreeBSD disk to use GPT instead of a traditional MBR, but I hadn't realised that the FreeBSD boot manager doesn't understand GPT partitions (my CURRENT is from early January, if that matters). I used to have that disk set up in the BIOS as the preferred boot disk and the boot manager on it allowed me to boot one of the other disks containing Windows 7 [1]. FreeBSD boots just fine from GPT. See the examples section of gpart(8). Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: GPT on amd64 and boot managers
On Thu, 27 May 2010, Alban Hertroys wrote: ... You appear to have missed the point; I was talking about the boot manager - the thing that lets you choose which OS to boot, not the boot loader. I can boot FreeBSD just fine off GPT, but I have to select in the BIOS whether I want to boot FreeBSD or Windows (by means of changing the boot sequence). A working boot manager would be so much more convenient for that. Ah. I see. Sorry, can't help here. On all servers I use GPT for FreeBSD/ZFS exclusively. On the Notebooks I stay with MBR... Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic @r207433: System call fork returning with the following locks held
On 04/30/10 18:33, K. Macy wrote: How much memory do you have? I haven't been checking code in without testing it, but clearly my system behaves a bit differently. Please try 207452. Building this now although .. On Fri, Apr 30, 2010 at 2:42 PM, Manfred Antar n...@pozo.com wrote: At 02:21 PM 4/30/2010, K. Macy wrote: On Fri, Apr 30, 2010 at 12:38 PM, K. Macy km...@freebsd.org wrote: Sadly, it doesn't do it for me .. lockd start-up causes a panic on a sleeping thread. Do I need to do a buildworld as well as kernel? We're calling vm_pageout_flush with the page queue lock held in vm_object_page_collect_flush. I'll have a fix in soon. Please try updating to 207451 .. mine worked with this in place. For reference, 4GB RAM of which only 2990MB is usable on a Toshiba A105 laptop :-( imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
config(8) dumps core
Hi All, after upgrading a FreeBSD/sparc64 machine from CURRENT sources of 3rd March to ones of 28th April config(8) doesn't work correctly anymore: server01# config -x /boot/kernel/kernel options CONFIG_AUTOGENERATED ident GENERIC machine sparc64 cpu SUN4U [...] device fwe device fwip device dcons device dcons_crom Assertion failed: (r != '\0' (Char present in the configuration string mustn't be equal to 0)), function kernconfdump, file /usr/src/usr.sbin/config/main.c, line 721. Abort (core dumped) A backtrace does not bring up anything useful: (gdb) bt #0 0x40580668 in kill () from /lib/libc.so.7 #1 0x404b6be0 in abort () from /lib/libc.so.7 #2 0x4056848c in __assert () from /lib/libc.so.7 #3 0x00104064 in ?? () Previous frame identical to this frame (corrupt stack?) (gdb) Any ideas on this? Kind Regards -- Michael Moll ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: config(8) dumps core
Hi, On Thu, Apr 29, 2010 at 11:33:30PM +0300, Andriy Gapon wrote: on 29/04/2010 18:31 Michael Moll said the following: You can use hd to see if you indeed have '\0' (0x00) symbol somewhere within your kernel config file. Thanks, I checked this and there are no 0x00s in the config file itself, but a hd to /boot/kernel/kernel reveals: 09 66 77 69 70 0a 64 65 76 69 63 65 09 64 63 6f |.fwip.device.dco| 6e 73 0a 64 65 76 69 63 65 09 64 63 6f 6e 73 5f |ns.device.dcons_| 63 72 6f 6d 0a 00 00 00 00 00 00 00 00 00 00 00 |crom| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || This also explains why a recent config-binary worked against the old kernel... The were some commits to /src/usr.sbin/config/* in the last weeks, maybe one of them broke this. Kind Regards -- Michael Moll ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: config(8) dumps core
Hi, On Thu, Apr 29, 2010 at 11:30:06PM +0100, Bruce Cran wrote: /boot/kernel/kernel. It looks like it thinks there's more data available than there is. config/main.c gets the size of the configuration by running elfdump: elfdump -c /boot/kernel/kernel | grep -A 5 kern_conf | tail -2 | cut -d ' ' -f 2 | paste - - - 100533682656 The first column is the offset, and the second is the number of bytes, but the embedded configuration only has 2649 bytes. OK, that explains that with all the related commits backup out (207265-206664) the resulting config-binary still fails. I don't have time today to build the kernel with the different revisions to hunt the problem down to one commit... imp@: The last commits to usr.sbin/config/* might have raised this problem, could you have a look at it? Kind Regards -- Michael Moll ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: config(8) dumps core
On Thu, Apr 29, 2010 at 05:07:00PM -0600, M. Warner Losh wrote: Do you have a small, reproducible sequence of events that will recreate this problem? I've seen no problems at all in my testing. I assume this is in -current? Yes, -CURRENT. Compile a kernel on sparc64 (didn't try this yet on other archs) and run config -x on the resulting file. Kind Regards -- Michael Moll ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SVN rev 206755 breakage
On 04/19/10 02:30, Alexander Motin wrote:
Rui Paulo wrote:
On 18 Apr 2010, at 14:05, Alexander Motin wrote:
Most of AHCI controllers could also work as usual PCI ATA, but not every
PCI ATA could work as AHCI. It would be nice to compare `pciconf -lvbc`
output in both working (Rui) and not working (Michael) cases.
ah...@pci0:0:31:2: class=0x01018f card=0x72708086 chip=0x27c48086 rev=0x02
hdr=0x00
vendor = 'Intel Corporation'
device = '82801GBM/GHM (ICH7-M Family) Serial ATA Storage Controller'
class = mass storage
subclass = ATA
^^^
It doesn't report itself as AHCI.
bar [10] = type I/O Port, range 32, base 0x20d8, size 8, enabled
bar [14] = type I/O Port, range 32, base 0x20fc, size 4, enabled
bar [18] = type I/O Port, range 32, base 0x20d0, size 8, enabled
bar [1c] = type I/O Port, range 32, base 0x20f8, size 4, enabled
bar [20] = type I/O Port, range 32, base 0x2020, size 16, enabled
bar [24] = type Memory, range 32, base 0x90445000, size 1024, enabled
This resource (BAR(5)) is absent on Michael's system. It is needed to
work in AHCI mode, but not required for legacy PCI ATA. Probably some
kind of BIOS magic in your case makes it appear in this mode with this
chip ID.
More for my own amusement than anything, I came up with an _horrible_
patch to force my ICH7M into AHCI mode (attached). It has two issues:
1) I haven't figured out how to automagically determine which
address(es) I can use without colliding with anything else. Simply
letting bus_allocate_any() decide where to point BAR(5) doesn't appear
to work. I suspect I have to dig through the SMAP stuff to find out what
the BIOS has already claimed and use something outside of those ranges.
2) Since my laptop has both a SATA drive and a PATA DVD-R/W, the
manufacturer commissioned a BIOS which brings the ICH7M up in combined
mode with D31-F1 completely disabled. Since it can't (per Intel spec)
be re-enabled without a platform reset, flipping into AHCI mode
effectively removes the DVD.
However - on the up side, I now get NCQ ;-)
ahci0: Intel ICH7M AHCI SATA controller port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18b0-0x18bf
at device 31.2 on pci0
ahci0: BAR(5): 0xf0d44400 AHCI_CAP: 0xdf12ff03 PI: 0x1
pcib0: matched entry for 0.31.INTB
pcib0: slot 31 INTB hardwired to IRQ 19
ahci0: [MPSAFE]
ahci0: [ITHREAD]
ahci0: AHCI v1.10 with 4 1.5Gbps ports, Port Multiplier supported
ahci0: Caps: 64bit NCQ MPS SS ALP AL CLO 1.5Gbps PM PMD SSC PSC
32cmd 4ports
ahci0: Caps2:
ahcich0: AHCI channel at channel 0 on ahci0
ahcich0: [MPSAFE]
ahcich0: [ITHREAD]
ahcich0: Caps:
[ .. ]
ada0 at ahcich0 bus 0 scbus1 target 0 lun 0
ada0: FUJITSU MHZ2320BJ G2 001E ATA-8 SATA 2.x device
ada0: Serial Number K82BT89256VDGEOM: new disk ada0
ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C)
*** sys/dev/ahci/ahci.c.origSat Apr 24 21:36:42 2010
--- sys/dev/ahci/ahci.c Sun Apr 25 21:30:57 2010
***
*** 126,131
--- 126,132
{0x26838086, 0x00, Intel ESB2,0},
{0x27c18086, 0x00, Intel ICH7,0},
{0x27c38086, 0x00, Intel ICH7,0},
+ {0x27c48086, 0x00, Intel ICH7M, 0},
{0x27c58086, 0x00, Intel ICH7M, 0},
{0x27c68086, 0x00, Intel ICH7M, 0},
{0x28218086, 0x00, Intel ICH8,0},
***
*** 321,331
--- 322,353
ctlr-quirks = ahci_ids[i].quirks;
resource_int_value(device_get_name(dev),
device_get_unit(dev), ccc, ctlr-ccc);
+
+ #define AHCI_MEM_HACK 0xF0D44400 /* 0xf0d443ff is the last used by
others on Toshiba A105 */
+
+ /* Need to set the SCRAE bit and ensure SCRD not set */
+ pci_write_config(dev, 0x94, (pci_read_config(dev, 0x94, 4) | 0x200)
~0x4000, 4);
+ /* enable MSE */
+ pci_write_config(dev, 0x4, (pci_read_config(dev, 0x4, 2) | 2), 2);
+ pci_write_config(dev, 0x24, AHCI_MEM_HACK, 4);
+ pci_write_config(dev, 0x90, 0x40, 1); /* AHCI + non-combined */
+
+ /* allocate a free memory window for BAR(5) */
+ ctlr-r_rid = PCIR_BAR(5);
+ bus_set_resource(dev, SYS_RES_MEMORY, ctlr-r_rid, AHCI_MEM_HACK,
0x400);
+
/* if we have a memory BAR(5) we are likely on an AHCI part */
ctlr-r_rid = PCIR_BAR(5);
if (!(ctlr-r_mem = bus_alloc_resource_any(dev, SYS_RES_MEMORY,
ctlr-r_rid, RF_ACTIVE)))
return ENXIO;
+
+ /* enable ICH7M ports in AHCI space */
+ ATA_OUTL(ctlr-r_mem, AHCI_PI, ATA_INL(ctlr-r_mem, AHCI_PI) | 5);
+ #if 0
+ device_printf(dev, BAR(5): 0x%lx AHCI_CAP: 0x%lx PI: 0x%lx\n,
(unsigned long)pci_read_config(dev, 0x24, 4),
+ (unsigned long)ATA_INL(ctlr-r_mem, 0), (unsigned
long)ATA_INL(ctlr-r_mem, AHCI_PI));
+ #endif
Re: SPOOFED: Re: SVN rev 206755 breakage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/18/10 01:57, Alexander Motin wrote: More important probably would be `pciconf -lvcb`. Intel controllers after ICH6 change both ID and set of resources, depending on AHCI enabled in BIOS. There is separate set of IDs for controllers with AHCI enabled. As I can see, Linux handles ID 0x27c4 as non-AHCI SATA. If for some reason this ID could be used for both modes (I have doubts), we may try to set AHCI_Q_NOFORCE flag to make driver check PCI class/subclass, if it is correct there. atap...@pci0:0:31:2:class=0x010180 card=0xff101179 chip=0x27c48086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801GBM/GHM (ICH7-M Family) Serial ATA Storage Controller' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0x1f0, size 8, enabled bar [14] = type I/O Port, range 32, base 0x3f4, size 1, enabled bar [18] = type I/O Port, range 32, base 0x170, size 8, enabled bar [1c] = type I/O Port, range 32, base 0x374, size 1, enabled bar [20] = type I/O Port, range 32, base 0x18b0, size 16, enabled cap 01[70] = powerspec 2 supports D0 D3 current D0 When AHCI is enabled, the device ID changes to 0x27c5. In this case, the probe succeeds but, since MSE is not set, the allocation of memory-IO space to BAR(5) is futile and the reset fails since it addresses undecoded space. Thus the attach fails, imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvLCyoACgkQQv9rrgRC1JK3UQCfXG1K3B7kOo35koBWdTohYt7/ qygAoM0kn0ZSYeD5P0Hu7kr3ci+otV3m =sk9Y -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
SVN rev 206755 breakage
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The revision labeled:
SVN rev 206755 on 2010-04-17 11:40:39Z by rpaulo
Add another ICH7M chipset that works.
.. is incorrect and will cause some laptops to not boot.
Of the following identifiers:
{0x27c48086, 0x00, Intel ICH7M, 0},
.. is the ICH7M in legacy and/or combined mode, i.e. *not* AHCI
{0x27c58086, 0x00, Intel ICH7M, 0},
.. is the *same* chipset in AHCI mode,
imb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (FreeBSD)
iEYEARECAAYFAkvKKW4ACgkQQv9rrgRC1JIMUQCeKmCz2USYE2SSyb1X5f6tes7G
DtsAoKkjFHhlPdESsziKO92LCaxK6EI5
=JAg8
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SVN rev 206755 breakage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/17/10 18:05, Rui Paulo wrote: On 17 Apr 2010, at 22:34, Michael Butler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The revision labeled: SVN rev 206755 on 2010-04-17 11:40:39Z by rpaulo Add another ICH7M chipset that works. .. is incorrect and will cause some laptops to not boot. So, in AHCI mode it doesn't find the disks? No - the driver fails to attach (ENXIO). I'm looking into which resource(s) it either couldn't allocate or gain control. The BIOS on my Toshiba does not initialize BAR(5) and, in the most general case, combined mode (MAP.SMS=0b, MAP.MV=10b) is required as the hard-drive is SATA but the DVD+RW is PATA :-( imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvKMloACgkQQv9rrgRC1JJ4FACdHxDzzfGIwBS4XEnfPWGCs2Qb wSsAoJAV6q/b16joC9MylPS8ZbT2JB/b =IeOp -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Enabling AHCI on ICH7M
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My laptop manufacturer decided not to have AHCI included in the BIOS for this device, so I've been looking at what needs to happen in order to make this work. On this device, the BIOS doesn't even initialize BAR(5), so I need to start at that point .. from the Intel specs, it seemed fairly straight-forward: Give the AHCI sub-system a chunk of memory by initializing BAR(5), tell the PCI bridge(s) about it, reset the various config bits to flip from legacy to AHCI mode and leave the rest to what already exists in the ata-intel driver. My question, however, relates to the choice of memory: Can I simply call contigmalloc() to get a chunk of memory space whose physical address I can get with vtophys and leave the mapping for the PCI bridge to the existing call to bus_alloc_resource_any()? Is there a better method of finding some free physical space into which to put the ICH7M AHCI registers? imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAku6hhQACgkQQv9rrgRC1JJ9TgCghkR8j9xy2MbSNW1LSRMhzX6h AdAAnR6Ctnvyng4W9qRbP0vtM352SYSo =t6V3 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/22/10 17:27, Xin LI wrote: Just a heads-up that zlib in base system (libz) has been updated to 1.2.4. We tried to keep -HEAD as close as possible to the vendor version, but there is some changes in its internal data structure, and we did not use versioned symbols in the past, making shared library version bump unavoidable. This breaks most (if not all) of the QT4-dependent ports for the lack of a definition of off64_t. Adding .. /* * This is hard-configured for FreeBSD. */ #include sys/types.h #define z_off_t off_t #define off64_t off_t - #ifndef _FILE_OFFSET_BITS #define _FILE_OFFSET_BITS 64 #endif .. to /usr/include/zconf.h seems to resolve this breakage, imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuuK08ACgkQQv9rrgRC1JLsIwCeKKG6GT60PzaB1loO78R2S9Rr B10An3N/a8h6AZsHGQyoJQ5XBZgpFXP0 =9z9H -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic @r205276 (Fatal trap 12: page fault while in kernel mode)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/18/10 09:35, David Wolfskill wrote: On first reboot after building installing; yesterday (@r205249) was OK: [ .. ] --- trap 0xc, eip = 0xc08853d6, esp = 0xc1420bb0, ebp = 0xc1420bd0 --- _mtx_lock_flags(f000ff53,0,c0cd0df2,9a2,0,...) at _mtx_lock_flags+0x46 zone_alloc_item(c0d9b5fc,c0cd12d4,c0cd11fb,c15ba000,c1420c88,...) at zone_alloc_item+0x33 hash_alloc(c15ba008,c0cd12d4,c0cd11fb,10,df,...) at hash_alloc+0x54 keg_ctor(c15ba000,80,c1420c88,2,c1420c88,...) at keg_ctor+0x234 zone_alloc_item(c0f7d380,180,c1420c88,c0d9b5fc,2000,...) at zone_alloc_item+0x176 zone_ctor(c0f7d380,180,c1420cd8,2,c0cd33f3,...) at zone_ctor+0x1d2 uma_startup(c158b000,30,7ff6,3,c158b000,...) at uma_startup+0x1db vm_page_startup(c15bb000,a,c1420d88,c084f0b6,0,...) at vm_page_startup+0x1d0 vm_mem_init(0,141ec00,141ec00,141e000,1425000,...) at vm_mem_init+0x18 mi_startup() at mi_startup+0x96 begin() at begin+0x2c db I suspect SVN 205266 (cache-line-size padding) has something to do with this but I'm still in the process of rebuilding with this change backed out .. imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuiL4kACgkQQv9rrgRC1JL5lQCeNyquBrUROs5vLw628/5pmXeF 09IAnjx2XyyQH/GuuGXB3R7CwtSZcWOf =wgGB -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic @r205276 (Fatal trap 12: page fault while in kernel mode)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/18/10 18:15, K. Macy wrote: On Thu, Mar 18, 2010 at 1:38 PM, K. Macy km...@freebsd.org wrote: I have the same panic. I'll try to revert 205266. Yes, 205266 is the culprit. Try updating. I've made the change a no-op until I can track the problem down. Do you all have either out-of-tree modules or modules that you did not re-build when re-compiling your kernel? I did 'rm -rf /usr/obj/*' prior to building the kernel, rebuilt fusefs-kmod and all virtualbox modules as I didn't know what, if anything, may have been dependent on the knowledge of the kernel's structures, imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuiq+oACgkQQv9rrgRC1JKDkgCfQqWTnLP8b63zEr+z5f9KfiVA 7eIAnR3guDIEY54VwPMA+TL0l6kUFyoi =B+08 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Error 127.0.0.1: no route to host
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/11/10 05:52, Li, Qing wrote: I spent some time looking into the issue and found the problem is the if_tap interface turns out to be one of those interfaces that claims to be of IFT_ETHER type, but does not touch the if_link_state variable. [ .. ] Please try the new patch at http://people.freebsd.org/~qingli/ecmp-tap.diff Let me know how it works out for you. This solves all the noted issues - thanks! imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuY/BAACgkQQv9rrgRC1JLoxACeLApgw4GJzTpukzV4AHzp9ffm 4XwAn1GbXEojETUiXgAze7hIfgNcJSDF =5iWa -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Error 127.0.0.1: no route to host
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/09/10 21:00, Doug Barton wrote: On 03/09/10 12:14, Li, Qing wrote: This error was caused by my commit r204902 from yesterday. Please try patch at http://people.freebsd.org/~qingli/route.h.diff This doesn't appear to be committed yet, is it still the best fix? Even with this patch, I can't ping the ipv4 address at the other end of an openvpn tunnel :-( imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuXjkAACgkQQv9rrgRC1JLSgwCeP1DbEdkiI4tLyteNhHS4q1yM u4YAn0qdGCZLPDRsiRWlXRzyG1Wl4wlA =L4+B -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Error 127.0.0.1: no route to host
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/10 12:18, Li, Qing wrote: Could you please provide me with more information, such as your ifconfig and netstat output? What's the error message? With or without r204902, I do not see any difference in ifconfig or netstat output. Addresses and routes are added as normal. Without the route.h patch, I can't ping 127.0.0.1 or the local or remote address of the OpenVPN tunnel (on tap0). In fact, you can't even build OpenVPN from ports as it'll fail its self-test. With the route.h patch, I can ping all local addresses but not the far end of the tunnel. Backing out r204902 restores normal operation of the tunnel. Asking the obvious question, you updated to r204902? FreeBSD toshi.auburn.protected-networks.net 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r204949M: Wed Mar 10 07:22:22 EST 2010 The 'M' signifies only that I've added my Nikon camera to the usbdev list and added aquirk for it, imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuYA0cACgkQQv9rrgRC1JL0bgCgqte+e7snRtr9uA/u0q5XaYLm OvoAn0o6Att5R8I2da8HyNiZnDCT/NHQ =BW8c -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
sys/dev/siba/siba_core.c fails compilation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If compiling -current without debugging enabled, this module fails with
a warning about unused variables (warnings treated as errors).
The attached patch allows compilation to proceed although I'm not
convinced that it's entirely correct (duplicate evaluation of
device_get_ivars()),
imb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (FreeBSD)
iEYEARECAAYFAkuYO2QACgkQQv9rrgRC1JIuOQCfYzduyb55+itgjs7tLu4Y0EzE
u5oAoLu66AManNJuzvHl/B7eBECOVHfB
=wo8h
-END PGP SIGNATURE-
Index: sys/dev/siba/siba_core.c
===
--- sys/dev/siba/siba_core.c (revision 204990)
+++ sys/dev/siba/siba_core.c (working copy)
@@ -2031,11 +2031,8 @@
uint32_t
siba_dma_translation(device_t dev)
{
- struct siba_dev_softc *sd = device_get_ivars(dev);
- struct siba_softc *siba = sd-sd_bus;
-
- KASSERT(siba-siba_type == SIBA_TYPE_PCI,
- (unsupported bustype %d\n, siba-siba_type));
+ KASSERT(device_get_ivars(dev)-sd_bus-siba_type == SIBA_TYPE_PCI,
+ (unsupported bustype %d\n, device_get_ivars(dev)-sd_bus-siba_type));
return (SIBA_PCI_DMA);
}
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Virtualbox
On Wed, February 24, 2010 10:38, Bernhard Froehlich wrote: I've got the new patch from Alexander Eichner now. It's currently untested on newer kernels so could someone please test it on an affected kernel? http://pastebin.ca/1808177 (linefeeds from the patch are dos so beware!) beat@ has already commited it to our vbox testing repository so you can get the virtualbox 3.1.4 port with the new patch included from: I grabbed it from SVN and it works just fine here - thanks! imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
rpcbind compilation problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It appears that SVN rev 203972 added this .. @@ -185,6 +178,8 @@ addrmerge(struct netbuf *caller, char *s if (ifsa == NULL || ifsa-sa_family != hint_sa-sa_family || !(ifap-ifa_flags IFF_UP)) continue; + if (!addr_is_bound(ifsa)) + continue; if (!(ifap-ifa_flags IFF_LOOPBACK) !listen_addr(ifsa)) continue; .. which breaks the compilation as there is no prototype for addr_is_bound(), imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkt7LpMACgkQQv9rrgRC1JKMAgCfcg359BXTEnXIbkzKydnrZGbN 5bYAoJ5XbrMtNlHfWJ9nxKkxEz2QTtUG =FOvd -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
libradius - missing defines
Hi, could someone please add these defines to radlib.h #define RAD_ACCT_INPUT_GIGAWORDS 52 #define RAD_ACCT_OUTPUT_GIGAWORDS 53 #define RAD_ACCT_INTERIM_INTERVAL 85 there is also a missing ACCT-Status-Type (RAD_ACCT_STATUS_TYPE) #define RAD_UPDATE 3 see also RFC 2869, thanx, bye, -- --- -- Michael Bretterklieber - http://www.bretterklieber.com A-Quadrat Automation GmbH - http://www.a-quadrat.at Tel: ++43-(0)3172-41679 - GSM: ++43-(0)699 12861847 --- -- ...the number of UNIX installations has grown to 10, with more expected... - Dennis Ritchie and Ken Thompson, June 1972 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
* Robert Watson [EMAIL PROTECTED] [031130 11:36]: On Sun, 30 Nov 2003, Andreas Klemm wrote: I have a better idea, then we perhaps need something like a wrapper script that is part of the FreeBSD basic system under /etc/rc.d that checks for the start script under $LOCALBASE/etc/rc.d and starts it very early. Hmm. I talked with Gordon about this issue some last night, but he pointed out a snag: most installs of FreeBSD place /usr on a separate partition from /. The rcNG ordering decision is made before /usr is mounted, as /usr is mounted as part of the pieces kicked off by rc.d. So it would be a fairly large departure from the current implementation of the rcNG code to reevaluate the ordering once more directories were available in which to find scripts to run. Not that it's not doable, but we need to think about it carefully (and, unfortunately, it's not as easy as simply adding /usr/local/etc/rc.d to the list..) Having wrapper Since this issue only comes up for a small number of ports, mostly those ports which can behave as back-end services for things that are in the base, wouldn't in be sufficient to have certain checkpoints in the rcNG code that simple scanned for and ran anything in a given location? You wouldn't need to reorder anything, simply have clearly defined pre-whatever or post-whatever steps that did something like: for i in `grep RUNAT: post-mount-usr /usr/local/etc/rc.d/*.sh` ; do [ -x $i ] sh $1; done --Mike pgp0.pgp Description: PGP signature
Re: Time jumping on both 4.x and 5.x ...
On Saturday 29 November 2003 09:19, Kris Kennaway wrote: Are all affected machines multi-processor? None. Both are i386 UP (although the 4.9-RELEASE box is running an SMP-enabled kernel). -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp0.pgp Description: signature
Re: Time jumping on both 4.x and 5.x ...
On Saturday 29 November 2003 11:43, Kris Kennaway wrote: I didn't think 4.x SMP kernels could run on a UP machine. It's a pretty decent Pentium4 Mobo, I guess it meets the requirements for an SMP-Board running one CPU. From dmesg: Timecounter i8254 frequency 1193182 Hz CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2421.83-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf27 Stepping = 7 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE real memory = 536805376 (524224K bytes) avail memory = 515989504 (503896K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 IOAPIC #0 intpin 16 - irq 11 IOAPIC #0 intpin 17 - irq 10 IOAPIC #0 intpin 18 - irq 3 IOAPIC #0 intpin 19 - irq 5 FreeBSD/SMP: Multiprocessor motherboard: 1 CPUs cpu0 (BSP): apic id: 0, version: 0x00050014, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178020, at 0xfec0 Warning: Pentium 4 CPU: PSE disabled bktr_mem: memory holder loaded Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 10 entries at 0xc00f7c80 acpi0: AMIINT INTEL845 on motherboard acpi0: power button is handled as a fixed feature programming model. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp0.pgp Description: signature
Re: 5.2-BETA + netatalk = crash
On Thursday 27 November 2003 06:35 pm, Leo Bicknell wrote: Since applying your patch I'd have IPv4 stop working 4 times. No panic, no console errors, just IPv4 traffic no longer does anything. Can't forward through the box. Can't ping the box, can't do anything. Logging in on console everything appears fine, and a reboot clears it up. I just reverted to the old kernel, we'll see if it happens again. The change I gave you should have nothing to do with IPv4. There is a change pending commit that appears to fix certain system lockups. I completed a make buildworld on a portable which NFS mounts /usr/src on the 5.2-BETA box which also runs netatalk, no obvious problems. Network hardware is a Compaq/Intel Pro100+ card using the fxp driver. Mike Squires ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.2-BETA and related ports issues
Things are actually looking pretty good at this point; I'm probably going to move from 4.9-STABLE to 5.2-RELEASE on my main home server, but I'm seeing the following with 5.2-BETA at this point: I'm running 5.2-BETA cvsup'd at about 9 PM 11/25 on two systems; one is a Supermicro P6DGH, dual PIII/850, SCSI disks, Compaq/Intel Pro100+ NIC; the other is a Toshiba 8100 Tecra using the built-in 3Com 10/100 port in the docking station (xl driver). The P6DGH is running netatalk with the (apparently) as yet uncommitted patch to the netatalk kernel interface, which appears to be running fine. I am not seeing any IP lockups (just finished a buildword/buildkernel/ installkernel/installword cycle with the portable NFS mounting the P6DGH). The following appeared before 5.2-BETA but are continuing with that version. On the portable I'm getting the following lock order reversal: Nov 28 10:32:33 mikes-port kernel: lock order reversal Nov 28 10:32:33 mikes-port kernel: 1st 0xc340eb00 pcm0 (sound softc) @ /usr/src/sys/dev/sound/pci/ds1.c:734 Nov 28 10:32:33 mikes-port kernel: 2nd 0xc340e740 pcm0:play:0 (pcm channel) @ /usr/src/sys/dev/sound/pcm/channel.c:440 Nov 28 10:32:33 mikes-port kernel: Stack backtrace: The related parts of dmesg are as follows (an improvement from 5.1-CURRENT, where the AC97 driver didn't load): pcm0: Yamaha DS-1E (YMF744) port 0xbf3c-0xbf3f,0xbf40-0xbf7f mem 0xefdf8000-0x efdf irq 11 at device 12.0 on pci0 ds1: setmap (226000, 3de4), nseg=1, error=0 pcm0: Unknown AC97 Codec (id = 0x414b4d05) pcm0: Codec features headphone, 18 bit DAC, 18 bit ADC, 5 bit master volume, AKM 3D Audio pcm0: Primary codec extended features variable rate PCM, AMAP pcm0: sndbuf_setmap 135db000, 1000; 0xc3407000 - 135db000 pcm0: sndbuf_setmap 13579000, 1000; 0xc3405000 - 13579000 pcm0: sndbuf_setmap 13134000, 1000; 0xc340 - 13134000 pcm0: sndbuf_setmap 134b2000, 1000; 0xc341e000 - 134b2000 pcm0: sndbuf_setmap 134d, 1000; 0xc341c000 - 134d pcm0: sndbuf_setmap 1348e000, 1000; 0xc341a000 - 1348e000 postgreSQL startup called twice On both systems I'm running postgreSQL7 from ports. In both cases the pgctl (the startup script) is called twice, and obviously it fails the second time. It is called both by /etc/rc.d/localdaemons and by /etc/rc.d/localpkg. I haven't looked any deeper than that, yet. On the portable the IP number, netmask, and router address are set in /etc/rc.conf. Both /etc/rc.d/netoptions and /etc/rc.d/network3 appear to be execuring (I see 'Additional TCP options: twice) and one of them is trying to reset the router address set by rc.conf, resulting in an error. The plus side is that a lot of the ACPI errors I used to get on the admittedly wierd P6DGH (11 PCI slots, onboard I2O, etc) have gone away. I'm not adding anything else at this point, since I don't know if these have been already reported (or fixed), but I can provide other info if necessary. Mike Squires UN*X at home since 1986 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Time jumping on both 4.x and 5.x ...
On Saturday 29 November 2003 05:57, Dag-Erling Smørgrav wrote: Marc G. Fournier [EMAIL PROTECTED] writes: as to ntpd/timed ... don't run either ... run ntpdate twice a day (11:59 and 23:59) Don't Do That. It will lead to all kinds of trouble that will take you ages to figure out. Really, ntpd is so ridiculously easy to set up (especially if you already have ntpdate working) that there is no reason not to use it. FWIW, it can reproduce this on two machines (one 4.9-RELEASE, one 5.1-RELEASE) which both run ntpd. Takes some 10 minutes on both before the first steps backwards turn up. Unfortunately, both machines aren't very good datapoints because both have pretty customized kernels and have -Os and -march optimized worlds/kernels... Both have kern.timecounter.hardware: ACPI-fast, too. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp0.pgp Description: signature
Re: 5.2-BETA + netatalk = crash
Sam Leffler On Wednesday 26 November 2003 06:51 am, Michael L. Squires wrote: On my dual CPU P6DGH the 11/22 cvsup of 5.2-BETA and netatalk crashes on boot. Stopping netatalk from starting stops the crash. I wasn't able to catch any crash information, but am currently recompiling with sources from last night to see if it's repeatable. Please try the attached patch, it should fix at least one problem in the netatalk code (Leo this should fix the panics you've seen during shutdown). Michael, hopefully this will also fix your problem--whatever it is. The patch certainly fixes the panic, thanks. I'm running a make buildworla, etc., on my notebook which NFS mounts the box running netatalk, which should trigger the IPv4 bug if I have it. Mike Squires ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.x DOS against NFS server
Guy Van Sanden I just ran nmap host... Nessus has the same effect. When running nmap host (nmap 2.53 on a 4.9-STABLE box)) against a 5.2-BETA host on the host I see Nove 27 13:06:24 mikes sm-mta[483]: NOQUEUE: SYSERR(root): getrequests: accept: Software caused connection abort Nove 27 13:06:24 mikes nfsd[392]: accept failed: Software caused connection abort between messages about response rate limits to nmap queries. On the client running 5.1-CURRENT with bonnie using a 100MB file on a volume NFS mounted from the 5.2-BETA server there are no log messages and no obvious error messages; bonnie finishes normally. Mike Squires ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Turkeys and dynamic linking
* Kent Stewart [EMAIL PROTECTED] [031127 17:50]: On Thursday 27 November 2003 12:31 pm, Bill Moran wrote: walt wrote: To all of you who celebrate Thanksgiving today, I wish you a happy one! And speaking of turkeys, does anyone know how Microsoft handles the performance issues associated with dynamic linking? Do they do anything special, or just ignore the whole thing? Don't they fix the performance hit by moving performance-critical parts of the application into kernel space (such as IIS and MSSQL)? At least, that's what Eric Raymond claims in his latest book. I don't think that's an approach I would like to see FreeBSD take. It all depends because if you only have 1 dll loaded for multiple applications, which is one of the features I understand is built into Windows, you have real savings. You share the code and own the data. Windows' dynamic linker works in a similar way to what Apple does in terms of sharing dll code. It makes an attempt to load libraries at the same base address in all processes, so that one DLL can be easily mapped into multiple processes. When you build a DLL, you supply a preferred address where it should be loaded. If Windows can load the library there, it does so. It also tries to load DLL's in thh same order each time. Since every process in the system likely relies on kernel32.dll, and probably user32.dll and gdi32.dll and others, Windows is almost always able to put those libraries at the same place in each process. So it doesn't have to read kernel32.dll from disk, since the OS itself has it loaded from the beginning. It just needs to do the fixups. For user-defined libraries, there's a decent chance that the same thing will happen. If not, then you have to pay the penalty to remap the library from scratch into a new location. As far as moving things into the kernel, I'm not sure what ESR is referring to. It's easy to get code into kernel-space by making it a device driver, but AFAIK SQL Server code comes all from normal DLL libraries, all in user space. --Mike pgp0.pgp Description: PGP signature
current freezing with sendmail-msp sumitting to ipv6 ::1.25
Hi, yesterday I tried to make the system's sendmail-msp submit to ::1.25 instead of 127.0.0.1:25 on an up-to-date FreeBSD-current installation . When injecting a lot of messages via bsmtp (rsmtp command) the system freezes solid after putting about 10 to 20 into the mail queue and doesn't even get as far as delivering them into the user's mailbox. There are no messages on the console or in the log files, the console doesn't respond any more and only way to revive the system is a hard reboot. Reverting to the old setting makes everything work fine again. Am I just doing it the wrong way round[tm] or is there some instability with IPv6 in FreeBSD-current? -- bye, Micha I hate forms! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
* M. Warner Losh [EMAIL PROTECTED] [031126 00:43]: In message: [EMAIL PROTECTED] Michael Edenfield [EMAIL PROTECTED] writes: : * M. Warner Losh [EMAIL PROTECTED] [031125 12:07]: : In message: [EMAIL PROTECTED] : boyd, rounin [EMAIL PROTECTED] writes: : : i see that there some doubt about whether running lots of : : shell scripts ever happens. what happens when you : : use make? lots of shells get run and they run small : : (one line?) scripts. : : make buildworld slows down 1% when you switch from static /bin/sh to : dynamic. : : I'm all for dynamic / and dynamic /bin/sh, but this doesn't even come : close to what I observed on my systems. I see anywhere from 15% to 20% : slowdown in buildworld, depending on how bad my hardware already is. I : posted my most recent numbers earlier. My dual athlon make -j 4 buildworld differed by about 16-20 seconds on a 36 minute buildworld. : It's difficult to get lots of these numbers, unfortunately, because it : takes a good 6-8 hours just to complete one build. But the numbers are : fairly consistant across the different degrees of old crappy hardware I : have. So you are seeing a about an hour slowdown (16% slowdown on 6 hours is 1 hour) from before/after? Or are you seeing an hour slowdown from 4.x - 5.2-beta? I have two 5.x systems, both with dynamic / that were built within the past month. One's a bit older, probably a month or so, as I was waiting for the statfs changes to settle before upgrading it. The other was built about 3 days ago. The first one is pretty old, I only use it for a firewall because no one will let me spring for a replacement: CPU: Pentium II/Pentium II Xeon/Celeron (399.10-MHz 686-class CPU) Origin = GenuineIntel Id = 0x665 Stepping = 5 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 66977792 (63 MB) avail memory = 60477440 (57 MB) ad0: 19470MB QUANTUM FIREBALLlct20 20 [39560/16/63] at ata0-master UDMA33 This machine usually takes 10-12 hours to do a full buildworld with -j 3 (which somehow seems to be the fastest). With static /bin/sh it was took just about an hour and a half less, but again, I could only do one pair since that took the whole day :) The other is slightly better and is my personal FreeBSD workstation, which I run -CURRENT on for test purposes and cuz I like it better :) CPU: AMD-K7(tm) Processor (499.04-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x612 Stepping = 2 Features=0x81f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,MMX AMD Features=0xc040AMIE,DSP,3DNow! real memory = 335478784 (319 MB) avail memory = 316243968 (301 MB) ad0: 16603MB Maxtor 91731U4 [33735/16/63] at ata0-master UDMA66 This one completes a buildworld in about 7-8 hours, the static /bin/sh run took about an hour less. I posted those numbers here earlier. I don't have any decent hardware running 5.x, all the new machines in real user are still using 4.8, so these are the only numbers I can come up with. Again, I *like* the ability to have NSS in /bin/sh, and the idea of dynamic linking in general appeals to me. The hour to hour-and-a-half slowdown might seem huge, but `make buildworld` really is the worst case scenario I could come up with, and 15% slowdown in the *worst* real-world case is certainly much better than 40%. --Mike pgp0.pgp Description: PGP signature
Re: 40% slowdown with dynamic /bin/sh
* Garance A Drosihn [EMAIL PROTECTED] [031126 06:56]:
At 12:23 AM -0500 11/26/03, Michael Edenfield wrote:
Just to provide some real-world numbers, here's what I got
out of a buildworld:
I have reformatted the numbers that Michael reported,
into the following table:
Static /bin/sh: Dynamic /bin/sh:
real385m29.977s real455m44.852s = 18.22%
user111m58.508s user113m17.807s = 1.18%
sys 93m14.450s sys 103m16.509s = 10.76%
user+sys = 5.53%
Since I forgot to include this information (sorry!):
Both runs were done by doing:
rm -rf /usr/obj
sync
script logfile
cp -f /bin/sh.{dynamic,static} /bin/sh
file /bin/sh
time make -j 4 buildworld
They were on a single CPU Athlon 500 with 320MB of RAM. I actually
don't normally do -j 4 on this system, only -j 2, but I'm use to
building on the dual Athlons we use to make production kernels and it
slipped in. Since it takes hours to run once it's started I just let it
run. :)
--Mike
pgp0.pgp
Description: PGP signature
5.2-BETA + netatalk = crash
On my dual CPU P6DGH the 11/22 cvsup of 5.2-BETA and netatalk crashes on boot. Stopping netatalk from starting stops the crash. I wasn't able to catch any crash information, but am currently recompiling with sources from last night to see if it's repeatable. Mike Squires ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: df: negative overflow?
* Melvyn Sopacua [EMAIL PROTECTED] [031126 13:23]: /dev/ad0s2e ? 989M ? 947M -36.4M ? 104% ? ?/var This is normal. Each filesystem has a chunk of reserved space for root-only, for disaster recovery and such. Your /var filesystem is full, and has begun overflowing into that reserved space by 36.4MB. Essentially, there is no free space left in the file system, and you must get rid of 36.4MB of data before you can begin to get any free space. --Mike pgp0.pgp Description: PGP signature
Re: 40% slowdown with dynamic /bin/sh
* M. Warner Losh [EMAIL PROTECTED] [031126 14:51]: In message: [EMAIL PROTECTED] Michael Edenfield [EMAIL PROTECTED] writes: : They were on a single CPU Athlon 500 with 320MB of RAM. 320MB is not enough RAM not to swap. However, having said that, I think everybody realizes the following: 1) Dynamic linking is slower. 2) Speed improvements in this area are possible, as demonstrated by other projects. 3) PIC code is slower than non-PIC code, in general, and also gcc runs about 5-10% slower depending on if you are running out of a shared library or a static one. shared libraries must use PIC code (at this time). 4) People like to complain. Just for the record, I've been running WITH_DYNAMICROOT since nearly the day it came out and don't *notice* any problems. Mostly because the noise of dynamic linking overhead gets lost in the noise of my hardware sucks so bad I have to take a vacation during buildworlds. My startup takes upwards of 5 minutes anyway, another 45 seconds won't even make me blink. I'm certainly not complaining about the performance :) I only posted those numbers to: 1) Give real world numbers, not interesting but unrealistic numbers 2) Show that even worst-case numbers weren't on the level of 40% slowdown. 3) Hopefully help someone figure out where to best improve the dynamic linker. --Mike pgp0.pgp Description: PGP signature
Re: 40% slowdown with dynamic /bin/sh
* boyd, rounin [EMAIL PROTECTED] [031125 05:16]: i see that there some doubt about whether running lots of shell scripts ever happens. what happens when you use make? lots of shells get run and they run small (one line?) scripts. Just to provide some real-world numbers, here's what I got out of a buildworld: Static /bin/sh: real385m29.977s user111m58.508s sys 93m14.450s Dynamic /bin/sh: real455m44.852s user113m17.807s sys 103m16.509s The dynamic /bin/sh caused just over an 18% performance hit on the make process, everything else being equal (the rest of my / is dynamically linked). It may seem like a pretty large performance hit, but to my the difference between a 6-hour and a 7-hour world build is just an extra hour of Quake :\ --Mike pgp0.pgp Description: PGP signature
Re: 40% slowdown with dynamic /bin/sh
* M. Warner Losh [EMAIL PROTECTED] [031125 12:07]: In message: [EMAIL PROTECTED] boyd, rounin [EMAIL PROTECTED] writes: : i see that there some doubt about whether running lots of : shell scripts ever happens. what happens when you : use make? lots of shells get run and they run small : (one line?) scripts. make buildworld slows down 1% when you switch from static /bin/sh to dynamic. I'm all for dynamic / and dynamic /bin/sh, but this doesn't even come close to what I observed on my systems. I see anywhere from 15% to 20% slowdown in buildworld, depending on how bad my hardware already is. I posted my most recent numbers earlier. It's difficult to get lots of these numbers, unfortunately, because it takes a good 6-8 hours just to complete one build. But the numbers are fairly consistant across the different degrees of old crappy hardware I have. -Mike pgp0.pgp Description: PGP signature
Re: HEADS UP: /bin and /sbin are now dynamically linked
* Garance A Drosihn [EMAIL PROTECTED] [031124 14:11]: I doubt there is any perfect answer which will satisfy everyone, but perhaps we can recognize that and figure out some flexible middle ground. Would it be possible, through some make.conf magic, for the end-user to set extra programs to be put into /rescue that are not typically there? RESCUE_EXTRAPRGS= usr.bin/vi usr.bin/fetch ?? --Mike pgp0.pgp Description: PGP signature
Re: How to fix this in 5.1-REL??
/usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such= file or directory mkdep: compile failed *** Error code 1 =20 Stop in /usr/src/gnu/lib/libstdc++. *** Error code 1 I'm running 5.1-CURRENT now, but I was able to build 5.1-RELEASE-p10. I suspect you need to re-cvsup your sources, which I've had to do several times. Mike Squires ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
* Tim Kientzle [EMAIL PROTECTED] [031121 18:40]: Leo Bicknell wrote: To boot a machine into single user mode you need a kernel, init, and /bin/sh (minimally). It would seem to me that alone is a good argument for those three things to be static. * Rewrite dlopen() to not require dynamic linking. There were some patches for this submitted at one point. As I recall, the people who looked at them were not entirely comfortable with them. (I'd be concerned about version conflict problems with this approach: what happens when a dynamically-loaded NSS module refers to a libc function? Does that get resolved to the already statically-linked version? Or does another copy of libc get dynamically linked with potential version conflicts? Does anyone know?) I personally think this is worth researching, though I have my doubts. I took a look at the glibc implementation of dlopen() breifly, since that does function from within libc.a. It appears that you *do* get more than one loaded copy of libc. The copy of dlopen() that is built when #ifndef SHARED includes a flag: __libc_multiple_libcs that is set to 1. Additionally, I was reading comments from some of the glibc developers who basically claim that dlopen() in a static binary *only* works if you dlopen() a NSS module. It isn't guaranteed to work in the general case because the static binary has no DYNAMIC elf section to resolve external references etc. I suspect this means NSS modules are limited in what they are allowed to reference and still work? I haven't looked in much detail on their implementation but it certainly looks like a hack just to make NSS work, which I don't think is a good long-term solution. --Mike pgp0.pgp Description: PGP signature
Re: ppp RADIUS accounting bug
Hi, On Wed, 19 Nov 2003, Boris Kovalenko wrote: Hello! Yes, unsigned, so we have 4G limit, which may simple be overflowed by (for example) PPPoE connection. Yes, RADIUS standard defines new attributes for big words, but current PPP does not supports it (it, so our knowledge about RFC is useless :) Again, rad_put_int defined u_int32_t parameter, so if a have dowloaded 4.5G (for example) what number will send to radius? How about sending periodic RADIUS accounting updates? After each accounting update the counters could be reset, but I'm not sure whether this is RFC compliant, i.e. whether allways the complete value has to be send or whether the counters could be reset, after each update. For Mpd we implemented it without resetting the counters, but maybe that's not 100% right. bye, -- --- -- Michael Bretterklieber - http://www.bretterklieber.com A-Quadrat Automation GmbH - http://www.a-quadrat.at Tel: ++43-(0)3172-41679 - GSM: ++43-(0)699 12861847 --- -- ...the number of UNIX installations has grown to 10, with more expected... - Dennis Ritchie and Ken Thompson, June 1972 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ppp RADIUS accounting bug
Hi Boris, On Wed, 19 Nov 2003, Boris Kovalenko wrote: Hello! Standard PPP does not support UPDATE packets, and of course (as my but a patch could be written :-) RADIUS knowledge) the counters should not be resetted, because RADIUS updates the same record. The RFC says: 5.4. Acct-Output-Octets blabla can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop. It looks like, that these counters must not present in accounting updates. bye, -- --- -- Michael Bretterklieber - http://www.bretterklieber.com A-Quadrat Automation GmbH - http://www.a-quadrat.at Tel: ++43-(0)3172-41679 - GSM: ++43-(0)699 12861847 --- -- ...the number of UNIX installations has grown to 10, with more expected... - Dennis Ritchie and Ken Thompson, June 1972 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ppp RADIUS accounting bug
Hi, On Wed, 19 Nov 2003, Boris Kovalenko wrote: The RFC says: 5.4. Acct-Output-Octets blabla can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop. It looks like, that these counters must not present in accounting updates. You are right, but your words - but a patch could be written :-). Again, I'm talking not about UPDATE packets and presence of any attributes in RADIUS requests. I'm talking about wrong handling of Acct-Input-Octets Acct-Output-Octets with current PPP RADIUS implementation. How this will be done, by implementing RFC2869 support IMHO this would be the right way, because RFC 2869 definitely says: Note that all information in an interim message is cumulative (i.e. number of packets sent is the total since the beginning of the session, not since the last interim message). So sending interim update packets won't help. looking for someone who supervises my patch and commit it if no problems will be founded. this can be a problem :-) bye, -- --- -- Michael Bretterklieber - http://www.bretterklieber.com A-Quadrat Automation GmbH - http://www.a-quadrat.at Tel: ++43-(0)3172-41679 - GSM: ++43-(0)699 12861847 --- -- ...the number of UNIX installations has grown to 10, with more expected... - Dennis Ritchie and Ken Thompson, June 1972 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
