Re: make delete-old broken

[Andreas Tobler]

- Original Message 
From: Ivan Klymenko fi...@ukr.net
To: freebsd-current@freebsd.org freebsd-current@freebsd.org
Subject: make delete-old broken
Date: 29/08/13 12:16

 Hello.
 In the interval between revisions gt;= r254887 to r255016
 make delete-old broken
 
 root@nonamehost:/ # cd /usr/src/
 root@nonamehost:/usr/src # yes|make delete-old
 make[1]:
quot;tools/build/mk/tools/build/mk/OptionalObsoleteFiles.incquot; line
 1603: Malformed conditional (${MK_GNU_PATCH} == no) make[1]: Fatal
 errors encountered -- cannot continue make[1]: stopped in /usr/src
 *** Error code 1
 
 Stop.
 make: stopped in /usr/src
 
 I can not say exactly at what revision it happened - but it was noticed
 in revision r255016


Should be fixed now, 255018.

Gruss,
Andreas


___
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

WEAK_REFERENCE?

[Andreas Tobler]

Hi all,

anyone interested in this patch to remove the WEAK_ALIAS and introduce
the WEAK_REFERENCE?

http://people.freebsd.org/~andreast/weak_ref.amd64.diff

I have this running since months on amd64 and I have no issues with.

I remember having had a communication with bde@ that he is in favour in
doing that but I lacked the time to complete.
A similar thing is pending for i386 and sparc64. The ppc stuff is
already committed since a longer time.

If no one is interested, I'm happy to clean up my tree and skip this.

Thanks,
Andreas

___
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: WEAK_REFERENCE?

[Andreas Tobler]

On 11.11.13 08:47, Konstantin Belousov wrote:
 On Sat, Nov 09, 2013 at 11:16:08PM +0100, Andreas Tobler wrote:
 Hi all,

 anyone interested in this patch to remove the WEAK_ALIAS and introduce
 the WEAK_REFERENCE?

 http://people.freebsd.org/~andreast/weak_ref.amd64.diff

 I have this running since months on amd64 and I have no issues with.

 I remember having had a communication with bde@ that he is in favour in
 doing that but I lacked the time to complete.
 A similar thing is pending for i386 and sparc64. The ppc stuff is
 already committed since a longer time.

 If no one is interested, I'm happy to clean up my tree and skip this.
 
 I am not sure why do you include the changes to END() in the same patch.
 Did you looked over the all END() usages on amd64, is it always paired
 with ENTRY() ?  The CNAME() for ELF is the pedantism anyway.
 
 Other than the somewhat questionable inclusion of the END() change, which
 should be committed separately, if ever, I think the change is fine.

Am I correct, without this line in sys/amd64/include/asm.h?

#define END(name)   .size CNAME(name), . - CNAME(name)

If so, I just need a usable dot.emacs file to match the formatting
expectations from bde. Sounds easy, but I didn't succeed so far.

Thank you for the feedback!

Andreas


___
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: WEAK_REFERENCE?

[Andreas Tobler]

On 14.11.13 07:00, Konstantin Belousov wrote:
 On Wed, Nov 13, 2013 at 10:18:27PM +0100, Andreas Tobler wrote:
 On 11.11.13 08:47, Konstantin Belousov wrote:
 On Sat, Nov 09, 2013 at 11:16:08PM +0100, Andreas Tobler wrote:
 Hi all,

 anyone interested in this patch to remove the WEAK_ALIAS and introduce
 the WEAK_REFERENCE?

 http://people.freebsd.org/~andreast/weak_ref.amd64.diff

 I have this running since months on amd64 and I have no issues with.

 I remember having had a communication with bde@ that he is in favour in
 doing that but I lacked the time to complete.
 A similar thing is pending for i386 and sparc64. The ppc stuff is
 already committed since a longer time.

 If no one is interested, I'm happy to clean up my tree and skip this.

 I am not sure why do you include the changes to END() in the same patch.
 Did you looked over the all END() usages on amd64, is it always paired
 with ENTRY() ?  The CNAME() for ELF is the pedantism anyway.

 Other than the somewhat questionable inclusion of the END() change, which
 should be committed separately, if ever, I think the change is fine.

 Am I correct, without this line in sys/amd64/include/asm.h?

 #define END(name)   .size CNAME(name), . - CNAME(name)
 Yes.  If committing it, please make separate commit.

Ok, thanks!

 If so, I just need a usable dot.emacs file to match the formatting
 expectations from bde. Sounds easy, but I didn't succeed so far.
 Nah, cannot be.  Emacs source code has too many inconsistencies, the
 code does not follow its own style.  I doubt Bruce would use it.

:) I asked and learned, (n)vi(m) it is much simpler than I thought.
Keep it simple

I prepared two patches, see below. The amd64 one is reviewed by bde@ and
the i386 is compile tested by me (runtime is theoretically also done,
but I'm not sure since I do not have 32-bit apps on my amd64).

The amd64 is compile and runtime tested. The tools, nm, shows that we
have the weak_references as before.

If you agree I'd like to commit both within a few days to -CURRENT. If
someone steps up and confirms that the i386 part also runs, would be
great, but I expect it to work.

If I'm correct, there is some similar work to be done on arm, mips and
sparc64, I'm happy to do this if the people like to have it done. But I
do not own either of them to test in native config. Except sparc64.
Here I have blech ;)


Here the two patches
amd64:
http://people.freebsd.org/~andreast/weak_ref_amd64.diff
i386:
http://people.freebsd.org/~andreast/weak_ref_i386.diff

Thanks for feedback.
Andreas
___
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: WEAK_REFERENCE?

[Andreas Tobler]

On 18.11.13 23:56, Adrian Chadd wrote:
 [snip]
 
 wiki.freebsd.org/FreeBSD/mips has links to the MIPS emulator setups.
 
 There's no excuse to avoid testing on MIPS. :-)

Np, wasn't aware of that.. :) And I do not shy the work.

Thanks,
Andreas

___
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: WEAK_REFERENCE?

[Andreas Tobler]

On 19.11.13 08:23, Konstantin Belousov wrote:
 On Mon, Nov 18, 2013 at 11:00:55PM +0100, Andreas Tobler wrote:
 I prepared two patches, see below. The amd64 one is reviewed by bde@ and
 the i386 is compile tested by me (runtime is theoretically also done,
 but I'm not sure since I do not have 32-bit apps on my amd64).
 Use cc -m32.
 

 The amd64 is compile and runtime tested. The tools, nm, shows that we
 have the weak_references as before.

 If you agree I'd like to commit both within a few days to -CURRENT. If
 someone steps up and confirms that the i386 part also runs, would be
 great, but I expect it to work.

 If I'm correct, there is some similar work to be done on arm, mips and
 sparc64, I'm happy to do this if the people like to have it done. But I
 do not own either of them to test in native config. Except sparc64.
 Here I have blech ;)


 Here the two patches
 amd64:
 http://people.freebsd.org/~andreast/weak_ref_amd64.diff
 i386:
 http://people.freebsd.org/~andreast/weak_ref_i386.diff
 
 Amd64 patch is fine. For i386, I do not see a definition of the
 WEAK_REFERENCE in the patch, and quick search of the pre-existing
 definition in sys/i386 or lib/libc/i386 does not reveal anything.

It's there now. Updated the diff.

Thanks,
Andreas

___
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: i386 update to latest -HEAD broke things

[Andreas Tobler]

- Original Message 
From: Adrian Chadd adr...@freebsd.org
To: freebsd-current freebsd-current@freebsd.org
Subject: Re: i386 update to latest -HEAD broke things
Date: 22/11/13 10:05

 r258446 built, installed and booted fine. I'll try a more recent i386
 in a chroot soon.
 
 Would someone please double-check -HEAD on i386 and see if it's ok?

Rebuild on i386 is in progress. Native, will take some time.

Andreas


___
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 with -CURRENT @Boot [r259130]

[Andreas Tobler]

On 10.12.13 03:52, Larry Rosenman wrote:
 On 2013-12-09 16:04, Aleksandr Rybalko wrote:
 On Mon, 9 Dec 2013 10:36:34 -0600
 Larry Rosenman l...@lerctr.org wrote:


 Path: .
 Working Copy Root Path: /usr/src
 URL: svn://svn.freebsd.org/base/head
 Relative URL: ^/head
 Repository Root: svn://svn.freebsd.org/base
 Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
 Revision: 259130
 Node Kind: directory
 Schedule: normal
 Last Changed Author: ray
 Last Changed Rev: 259130
 Last Changed Date: 2013-12-09 09:28:34 -0600 (Mon, 09 Dec 2013)

 [[cut]]

 Can you please share core and kernel with modules.
 I'm not sure, but looks like it is related to vt (newcons).
 So I have to investigate.

 Thanks!

 WBW
 I've passed ray@ credentials to get at the core/kernel/etc on the system 
 that generated it.

I have a +2, the same panic as Larry plus another one on my Thinkpads.

The second panic looks like this:


Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0x807b8147
stack pointer   = 0x28:0xfe00dd97f8e0
frame pointer   = 0x28:0x333231302f2e2d2c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1132 (vidcontrol)


I 'fixed' this with the attached patch. I have to test tomorrow if the
first panic (the one Larry sees) on my Dell also goes away with this 'fix'.

I compared with syscons.c and there the ival/data assigment is always
done inside the case label and not at the end.

maybe I'm papering over ... but at least a starting point to investigate.

Andreas


Index: dev/vt/vt_core.c
===
--- dev/vt/vt_core.c(revision 259154)
+++ dev/vt/vt_core.c(working copy)
@@ -1294,37 +1295,55 @@
switch (cmd) {
case _IO('v', 4):
cmd = VT_RELDISP;
+   ival = IOCPARM_IVAL(data);
+   data = (caddr_t)ival;
break;
case _IO('v', 5):
cmd = VT_ACTIVATE;
+   ival = IOCPARM_IVAL(data);
+   data = (caddr_t)ival;
break;
case _IO('v', 6):
cmd = VT_WAITACTIVE;
+   ival = IOCPARM_IVAL(data);
+   data = (caddr_t)ival;
break;
case _IO('K', 20):
cmd = KDSKBSTATE;
+   ival = IOCPARM_IVAL(data);
+   data = (caddr_t)ival;
break;
case _IO('K', 67):
cmd = KDSETRAD;
+   ival = IOCPARM_IVAL(data);
+   data = (caddr_t)ival;
break;
case _IO('K', 7):
cmd = KDSKBMODE;
+   ival = IOCPARM_IVAL(data);
+   data = (caddr_t)ival;
break;
case _IO('K', 8):
cmd = KDMKTONE;
+   ival = IOCPARM_IVAL(data);
+   data = (caddr_t)ival;
break;
case _IO('K', 63):
cmd = KIOCSOUND;
+   ival = IOCPARM_IVAL(data);
+   data = (caddr_t)ival;
break;
case _IO('K', 66):
cmd = KDSETLED;
+   ival = IOCPARM_IVAL(data);
+   data = (caddr_t)ival;
break;
case _IO('c', 110):
cmd = CONS_SETKBD;
+   ival = IOCPARM_IVAL(data);
+   data = (caddr_t)ival;
break;
}
-   ival = IOCPARM_IVAL(data);
-   data = (caddr_t)ival;
 #endif
 
switch (cmd) {
___
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: Fwd: r259154 panics

[Andreas Tobler]

On 13.12.13 05:34, Eitan Adler wrote:
 Since I got no reply on -hackers...
 
 

Have you tried after 259221? I had a similar panic where the process was
vidcontrol and doing the IOCPARM_IVAL part only for the COMPAT_XX helped me.

Andreas

___
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 armv6/arm

[Andreas Tobler]

On 03.01.14 19:46, FreeBSD Tinderbox wrote:

 machine - /src/sys/arm/include
 cc  -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs 
 -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual 
 -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs 
 -fdiagnostics-show-option -Wno-error-tautological-compare 
 -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. 
 -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter 
 -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal 
 -I/src/sys/contrib/dev/ath/ath_hal -I/src/sys/contrib/ngatm 
 -I/src/sys/dev/twa -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe 
 -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
 opt_global.h -funwind-tables -ffreestanding /src/sys/arm/arm/genassym.c
 In file included from /src/sys/arm/arm/genassym.c:48:
 In file included from ./machine/intr.h:71:
 /src/sys/sys/bus.h:585:10: fatal error: 'device_if.h' file not found
 #include device_if.h

The attached fixes this breakage (and the one on arm:arm). Ok to commit?

Andreas


Index: arm/arm/trap.c
===
--- arm/arm/trap.c  (revision 260220)
+++ arm/arm/trap.c  (working copy)
@@ -85,6 +85,7 @@
 __FBSDID($FreeBSD$);
 
 #include sys/param.h
+#include sys/bus.h
 #include sys/systm.h
 #include sys/proc.h
 #include sys/kernel.h
Index: arm/include/intr.h
===
--- arm/include/intr.h  (revision 260220)
+++ arm/include/intr.h  (working copy)
@@ -67,8 +67,6 @@
 #define NIRQ   32
 #endif
 
-#include machine/psl.h
-#include sys/bus.h
 
 int arm_get_next_irq(int);
 void arm_mask_irq(uintptr_t);
Index: arm/include/psl.h
===
--- arm/include/psl.h   (revision 260220)
+++ arm/include/psl.h   (working copy)
@@ -46,7 +46,6 @@
 
 #ifndef _MACHINE_PSL_H_
 #define _MACHINE_PSL_H_
-#include machine/intr.h
 
 /*
  * These are the different SPL states
___
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: kernel broken: run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config

[Andreas Tobler]

On 23.06.11 09:54, O. Hartmann wrote:

With today's update of sources
(Revision: 223466
Node Kind: directory
Schedule: normal
Last Changed Author: adrian
Last Changed Rev: 223466
Last Changed Date: 2011-06-23 08:55:29 +0200 (Do, 23 Jun 2011))

FreeBSD 9.0-CURRENT/amd64 won't boot anymore. The box gets stuck in
booting the kernel and ending up with the message (repeated every 60
seconds):

run_interrupt_driven_hooks: still waiting after XXX seconds for xpt_config

What's up?



+1, powerpc64.

Would be nice if this could be fixed.

Thanks,
Andreas
___
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

pcib1: failed to allocate initial memory window

[Andreas Tobler]

Hi all,

Built a fresh kernel today (-CURRENT) on my DELL workstation (amd64).
The network card does not get detected. Booted the old kernel again.

Are there any chances to get this fixed or is this a candidate for a 
buggy BIOS?

Attached the devinfo -r from the running kernel. Also the acpidump -dt.

Any help would be appreciated.

TIA,
Andreas

kernel: pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0
 kernel: pcib1: failed to allocate initial memory window: 
0xe800-0xefef
 kernel: pcib1: failed to allocate initial prefetch window: 
0xd800-0xdfff

 kernel: pci1: ACPI PCI bus on pcib1
 kernel: vgapci0: VGA-compatible display irq 16 at device 0.0 on pci1
 kernel: hdac0: Intel 82801G High Definition Audio Controller irq 16 
at device 27.0 on pci0

 kernel: pcib2: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0
 kernel: pcib2: failed to allocate initial memory window: 
0xe7f0-0xe7ff

 kernel: pci2: ACPI PCI bus on pcib2
 kernel: pcib3: ACPI PCI-PCI bridge irq 16 at device 28.4 on pci0
 kernel: pci3: ACPI PCI bus on pcib3
 kernel: pcib4: ACPI PCI-PCI bridge irq 17 at device 28.5 on pci0
 kernel: pcib4: failed to allocate initial memory window: 
0xe7e0-0xe7ef

 kernel: pci4: ACPI PCI bus on pcib4
 kernel: bge0: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC 
rev. 0x00b002 irq 17 at device 0.0 on pci4
 kernel: bge0: 0x1 bytes of rid 0x10 res 3 failed (0, 
0x).

 kernel: bge0: couldn't map memory
 kernel: device_attach: bge0 attach returned 6
___
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: pcib1: failed to allocate initial memory window

[Andreas Tobler]

On 20.07.11 22:25, Andreas Tobler wrote:

Hi all,

Built a fresh kernel today (-CURRENT) on my DELL workstation (amd64).
The network card does not get detected. Booted the old kernel again.

Are there any chances to get this fixed or is this a candidate for a
buggy BIOS?
Attached the devinfo -r from the running kernel. Also the acpidump -dt.


They got eaten 

Here they are:

http://people.freebsd.org/~andreast/acpidump_optiplex.txt
http://people.freebsd.org/~andreast/devinfo_optiplex.txt

Thanks,
Andreas
___
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: pcib1: failed to allocate initial memory window

[Andreas Tobler]

On 21.07.11 17:53, John Baldwin wrote:

On Wednesday, July 20, 2011 4:25:03 pm Andreas Tobler wrote:

Hi all,

Built a fresh kernel today (-CURRENT) on my DELL workstation (amd64).
The network card does not get detected. Booted the old kernel again.

Are there any chances to get this fixed or is this a candidate for a
buggy BIOS?
Attached the devinfo -r from the running kernel. Also the acpidump -dt.

Any help would be appreciated.


Ah, this case is similar to the issue with VirtualBox.  Try this patch:


John, thank you very much!

http://people.freebsd.org/~andreast/dmesg_optiplex.txt

Gruss,
Andreas
___
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: Intel Centrino Advanced-N + WiMAX 6250 doesn't work

[Andreas Tobler]

- Original Message 
From: Tz-Huan Huang tzh...@gmail.com
To: freebsd-current@freebsd.org freebsd-current@freebsd.org
Subject: Re: Intel Centrino Advanced-N + WiMAX 6250 doesn't work
Date: 07/09/11 09:40

 On Wed, Sep 7, 2011 at 14:10, Tz-Huan Huang lt;tzh...@gmail.comgt;
wrote:
 gt; Hi,
 gt;
 gt; I have a lenovo X201s with a quot;Intel Centrino Advanced-N + WiMAX
6250quot; bundled.
 gt; The device seems recognized as iwn0 correctly but it just doesn't
work.
 gt; The command quot;ifconfig wlan0 up scanquot; return immediately and
nothing showed.
 gt;
 gt; Is the device not supported, or do I miss something?
 gt; Any suggestion is welcome, thanks.
 gt;
 gt; Here is some information:
 gt;
 gt; $ uname -a
 gt; FreeBSD bud 9.0-BETA2 FreeBSD 9.0-BETA2 #2: Tue Sep  6 16:50:09 CST
 gt; 2011     root@bud:/usr/obj/usr/src/sys/BUD  amd64
 gt;
 gt; dmesg -a:
 gt; http://www.csie.ntu.edu.tw/~b90093/tmp/dmesg.txt
 gt;
 gt; rc.conf:
 gt; http://www.csie.ntu.edu.tw/~b90093/tmp/rc.conf
 gt;
 gt; kldstat -v
 gt; http://www.csie.ntu.edu.tw/~b90093/tmp/kldstat.txt
 
 When loading acpi_ibm, I got more error information:
 
 $ kldload acpi_ibm
 acpi_ibm0: lt;IBM ThinkPad ACPI Extrasgt; on acpi0
 $ ifconfig wlan0 up
 iwn0: iwn5000_send_calibration: could not send calibration result, error
22
 iwn0: iwn_init_locked: could not initialize hardware, error 22
 
 
 Any suggestion? Thanks.

Maybe, is the wlan switch on? (on the left side?) I recently had such an
experience with a t60 where the switch was off. Took a while until I
realized that I can switch on the wlan

Gruss,
Andreas


___
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: ath0 no longer attaches, cardbus problems?

[Andreas Tobler]

Hi Daniel!

On 09.09.11 21:22, Daniel Eischen wrote:

I found the commit that broke ath for me, r222753,
specifically, the change to /dev/cardbus/cardbus_cis.c.

To be sure, I updated to head using svn, and applied
the patch included below.  ath attaches and works.  Without
the patch, ath does not attach.

On another note, I've no idea why updating from a local
CVS repo lead me down a wrong path.  It seems wrong that
a 'cvs update -P -d -A -D 31 Mar 2011' works and
a 'cvs update -P -d -A -D 1 Apr 2011' does not work.
r222753 did not occur until much later (June 6).
Once John asked me to try r220195, I switched to using
svn.  When that worked, it seemed strange to me because
nothing else committed after that on Mar 31 should have
broke ath.

Anyway, culprit found.  Now what is the correct fix?


THANK you very much!

I was following this thread with big interest since last weekend.
Here I found a Wireless card in the trash. An MSI card with a 'Ralink 
Technology RT2560, RT2525'.
Under 8.2 it worked perfectly while under current I got a crappy 
ethernet address.


Went back to 220194 and could prove that it was working there.
During this process your message came in and I immediately tried the 
below patch:


ral0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 2290
ether 00:13:d3:7f:f8:48
nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
media: IEEE 802.11 Wireless Ethernet autoselect mode 11g
status: associated

Whee!!! Again, thanks a lot.

I do not know if it is the right solution, but it works.

Gruss,
Andreas




Index: sys/dev/cardbus/cardbus_cis.c
===
--- sys/dev/cardbus/cardbus_cis.c   (revision 225463)
+++ sys/dev/cardbus/cardbus_cis.c   (working copy)
@@ -441,6 +441,7 @@
   {
if (res != CIS_CONFIG_SPACE) {
bus_release_resource(child, SYS_RES_MEMORY, rid, res);
+   bus_delete_resource(child, SYS_RES_MEMORY, rid);
}
   }

@@ -477,7 +478,11 @@
}

/* allocate the memory space to read CIS */
+#if 0
res = bus_alloc_resource_any(child, SYS_RES_MEMORY, rid,
+#else
+   res = bus_alloc_resource(child, SYS_RES_MEMORY, rid, 0, ~0, 1,
+#endif
rman_make_alignment_flags(4096) | RF_ACTIVE);
if (res == NULL) {
device_printf(cbdev, Unable to allocate resource 



___
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

buildworld race?

[Andreas Tobler]

Anyone seen this too?

make: don't know how to make 
/usr/obj/export/devel/fbsd/src/tmp/usr/lib/libkrb5.a. Stop

*** Error code 2

Happens on amd64 and powerpc64 while doing a make -j4 buildworld.
Continuing with -DNO_CLEAN -j1 completes the build.

Thanks,
Andreas
___
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: 0 Re: buildworld race?

[Andreas Tobler]

On 22.11.11 22:26, Ivan Klymenko wrote:

В Tue, 22 Nov 2011 19:35:22 +0100
Andreas Toblerandreast-l...@fgznet.ch  пишет:


Anyone seen this too?

make: don't know how to make
/usr/obj/export/devel/fbsd/src/tmp/usr/lib/libkrb5.a. Stop
*** Error code 2

Happens on amd64 and powerpc64 while doing a make -j4 buildworld.
Continuing with -DNO_CLEAN -j1 completes the build.

Thanks,
Andreas


Problem is solved in revision 227841
http://svn.freebsd.org/changeset/base/227841


Confirmed and seen, thanks :)

Andreas

___
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: csup ends up in sigwai after Shutting down connection to server, never exits

[Andreas Tobler]

On 14.06.12 17:04, Anton Shterenlikht wrote:

On Thu, Jun 14, 2012 at 03:20:16PM +0200, Jeremie Le Hen wrote:

Hi Anton,

On Thu, Jun 14, 2012 at 11:57:38AM +0100, Anton Shterenlikht wrote:

On ia64 r235474 and r235163 I get:

# csup -L2 /root/ports-supfile
Parsing supfile /root/ports-supfile
Connecting to cvsup.uk.FreeBSD.org
Connected to 131.111.8.41
Server software version: SNAP_16_1h
MD5 authentication started
MD5 authentication successful
Negotiating file attribute support
Exchanging collection information
Establishing multiplexed-mode data connection
Running
Updating collection ports-all/cvs
Shutting down connection to server

csup never exits.

From top:

   PID USERNAMETHR PRI NICE   SIZERES STATE   C   TIME   WCPU COMMAND
33822 root  2  200 37496K 23352K sigwai  1   0:32  0.00% csup


On amd64 r236740M I don't see this problem.


mux@ fixed many bugs in his bitbucket source tree [1], would you mind
giving it a spin?  I may import the latest code into the tree when I
have enough free time.

[1] https://bitbucket.org/mux/csup


no, this doesn't help.
I get exactly the same behaviour.
Perhaps the problem is not in csup.

Any ideas on how to debug this further?



Not really debugging, but did you try to fetch a fresh ports-tree?
Had something similar yesterday (afair on ppc64) and ended with a fresh 
csup.


Gruss,
Andreas
___
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

[Andreas Tobler]

On 17.10.12 02:06, FreeBSD Tinderbox wrote:

TB --- 2012-10-16 18:50:00 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-10-16 18:50:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2012-10-16 18:50:00 - starting HEAD tinderbox run for amd64/amd64
TB --- 2012-10-16 18:50:00 - cleaning the object tree
TB --- 2012-10-16 18:50:00 - checking out /src from 
svn://svn.freebsd.org/base/head
TB --- 2012-10-16 18:50:00 - cd /tinderbox/HEAD/amd64/amd64
TB --- 2012-10-16 18:50:00 - /usr/local/bin/svn cleanup /src
TB --- 2012-10-16 18:52:40 - /usr/local/bin/svn update /src
TB --- 2012-10-16 18:53:00 - At svn revision 241613
TB --- 2012-10-16 18:53:01 - building world
TB --- 2012-10-16 18:53:01 - CROSS_BUILD_TESTING=YES
TB --- 2012-10-16 18:53:01 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-10-16 18:53:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-10-16 18:53:01 - SRCCONF=/dev/null
TB --- 2012-10-16 18:53:01 - TARGET=amd64
TB --- 2012-10-16 18:53:01 - TARGET_ARCH=amd64
TB --- 2012-10-16 18:53:01 - TZ=UTC
TB --- 2012-10-16 18:53:01 - __MAKE_CONF=/dev/null
TB --- 2012-10-16 18:53:01 - cd /src
TB --- 2012-10-16 18:53:01 - /usr/bin/make -B buildworld

Building an up-to-date make(1)
World build started on Tue Oct 16 18:53:09 UTC 2012
Rebuilding the temporary build tree
stage 1.1: legacy release compatibility shims
stage 1.2: bootstrap tools
stage 2.1: cleaning up the object tree
stage 2.2: rebuilding the object tree
stage 2.3: build tools
stage 3: cross tools
stage 4.1: building includes
stage 4.2: building libraries
stage 4.3: make dependencies
stage 4.4: building everything
stage 5.1: building 32 bit shim libraries
World build completed on Tue Oct 16 21:56:29 UTC 2012

TB --- 2012-10-16 21:56:29 - generating LINT kernel config
TB --- 2012-10-16 21:56:29 - cd /src/sys/amd64/conf
TB --- 2012-10-16 21:56:29 - /usr/bin/make -B LINT
TB --- 2012-10-16 21:56:29 - cd /src/sys/amd64/conf
TB --- 2012-10-16 21:56:29 - /usr/sbin/config -m LINT
TB --- 2012-10-16 21:56:29 - building LINT kernel
TB --- 2012-10-16 21:56:29 - CROSS_BUILD_TESTING=YES
TB --- 2012-10-16 21:56:29 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-10-16 21:56:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-10-16 21:56:29 - SRCCONF=/dev/null
TB --- 2012-10-16 21:56:29 - TARGET=amd64
TB --- 2012-10-16 21:56:29 - TARGET_ARCH=amd64
TB --- 2012-10-16 21:56:29 - TZ=UTC
TB --- 2012-10-16 21:56:29 - __MAKE_CONF=/dev/null
TB --- 2012-10-16 21:56:29 - cd /src
TB --- 2012-10-16 21:56:29 - /usr/bin/make -B buildkernel KERNCONF=LINT

Kernel build for LINT started on Tue Oct 16 21:56:29 UTC 2012
stage 1: configuring the kernel
stage 2.1: cleaning up the object tree
stage 2.2: rebuilding the object tree
stage 2.3: build tools
stage 3.1: making dependencies
stage 3.2: building everything
Kernel build for LINT completed on Tue Oct 16 22:27:43 UTC 2012

TB --- 2012-10-16 22:27:43 - cd /src/sys/amd64/conf
TB --- 2012-10-16 22:27:43 - /usr/sbin/config -m LINT-NOINET
TB --- 2012-10-16 22:27:43 - building LINT-NOINET kernel
TB --- 2012-10-16 22:27:43 - CROSS_BUILD_TESTING=YES
TB --- 2012-10-16 22:27:43 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-10-16 22:27:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-10-16 22:27:43 - SRCCONF=/dev/null
TB --- 2012-10-16 22:27:43 - TARGET=amd64
TB --- 2012-10-16 22:27:43 - TARGET_ARCH=amd64
TB --- 2012-10-16 22:27:43 - TZ=UTC
TB --- 2012-10-16 22:27:43 - __MAKE_CONF=/dev/null
TB --- 2012-10-16 22:27:43 - cd /src
TB --- 2012-10-16 22:27:43 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET

Kernel build for LINT-NOINET started on Tue Oct 16 22:27:43 UTC 2012
stage 1: configuring the kernel
stage 2.1: cleaning up the object tree
stage 2.2: rebuilding the object tree
stage 2.3: build tools
stage 3.1: making dependencies
stage 3.2: building everything
Kernel build for LINT-NOINET completed on Tue Oct 16 22:57:00 UTC 2012

TB --- 2012-10-16 22:57:00 - cd /src/sys/amd64/conf
TB --- 2012-10-16 22:57:00 - /usr/sbin/config -m LINT-NOINET6
TB --- 2012-10-16 22:57:01 - building LINT-NOINET6 kernel
TB --- 2012-10-16 22:57:01 - CROSS_BUILD_TESTING=YES
TB --- 2012-10-16 22:57:01 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-10-16 22:57:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-10-16 22:57:01 - SRCCONF=/dev/null
TB --- 2012-10-16 22:57:01 - TARGET=amd64
TB --- 2012-10-16 22:57:01 - TARGET_ARCH=amd64
TB --- 2012-10-16 22:57:01 - TZ=UTC
TB --- 2012-10-16 22:57:01 - __MAKE_CONF=/dev/null
TB --- 2012-10-16 22:57:01 - cd /src
TB --- 2012-10-16 22:57:01 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6

Kernel build for LINT-NOINET6 started on Tue Oct 16 22:57:01 UTC 2012
stage 1: configuring the kernel
stage 2.1: cleaning up the object tree
stage 2.2: rebuilding the object tree
stage 2.3: build tools
stage 3.1: making dependencies
stage 3.2: building everything
Kernel build for LINT-NOINET6 completed on Tue Oct 16 23:26:08 

Re: weird network problems on current since 10/28/2012

[Andreas Tobler]

On 04.11.12 14:57, Andre Oppermann wrote:
 On 04.11.2012 13:11, Kim Culhan wrote:
 On Sun, November 4, 2012 6:21 am, Dimitry Andric wrote:
 On 2012-11-04 02:13, Manfred Antar wrote:
 At 03:29 PM 11/3/2012, Adrian Chadd wrote:
 On 3 November 2012 10:40, Manfred Antar n...@pozo.com wrote:
 i have problem connecting to freebsd box on local network since last 
 sunday.
 the last kernel that works:
FreeBSD 10.0-CURRENT #0: Sun Oct 28 12:14:38 PDT 2012
 anything after that, sometimes i can connect, other times just hangs.
 any network connection hangs = pop httpd ssh etc etc.
 anyone have any ideas ?
 i can checkout different sources and see if i can locate the changes 
 that cause
 this.

 Please do!
 ...
 Here is what I found doing :
 setenv CVSROOT /usr/home/ncvs

 cvs co -DOctober 28, 2012 12:14:38 PDT sys

 A kernel from that time works fine.

 doing:

 cvs up -DOctober 28, 2012 13:14:38 PDT sys1 hour 
 later
 the following files were changed:
 sys/netinet/tcp_input.c
 sys/netinet/tcp_timer.c
 sys/netinet/tcp_var.h

 Building a kernel from these new files is when the problem starts.

 So, your problems seem to have been introduced by this commit by Andre:

 http://svn.freebsd.org/changeset/base/242266

 Increase the initial CWND to 10 segments as defined in IETF TCPM
 draft-ietf-tcpm-initcwnd-05. It explains why the increased initial
 window improves the overall performance of many web services without
 risking congestion collapse.

 As long as it remains a draft it is placed under a sysctl marking it
 as experimental:
  net.inet.tcp.experimental.initcwnd10 = 1
 When it becomes an official RFC soon the sysctl will be changed to
 the RFC number and moved to net.inet.tcp.

 This implementation differs from the RFC draft in that it is a bit
 more conservative in the case of packet loss on SYN or SYN|ACK because
 we haven't reduced the default RTO to 1 second yet.  Also the restart
 window isn't yet increased as allowed.  Both will be adjusted with
 upcoming changes.

 Is is enabled by default.  In Linux it is enabled since kernel 3.0.

 After the commit, there was a small discussion thread on svn-src-head@
 about the possible problems with the approach.  Maybe you are
 experiencing those?

 As the commit message says, you should be able to turn the feature off
 using:

 sysctl net.inet.tcp.experimental.initcwnd10=0

 Can you please try that, and see if the problems go away?

 FWIW this did not make the problem go away on 2 machines.
 
 Yes, this very much looks like the same problem as in PR/173309.
 
 Please try the attached patch.  It fixes the connection hang issue.
 There may be a second issue I debugging currently base on the feedback
 from Fabian Keil.

I jump into this thread since I have a similar network issue.

My scenario:

'make installkernel DESTDIR=/netboot/test' to a nfs mounted drive.
The nfs drive on the server is an ufs fs. No zfs.

Up to r242261 I can install the kernel (or world) in a fluent way to the
nfs destination.

From r242262 it doesn't work smooth. I have stalls, sometimes my
patience is not enough and I kill the process.

I tried 242266 with the above mentioned patch. No real success.

How can I help/test?

TIA,
Andreas

___
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: weird network problems on current since 10/28/2012

[Andreas Tobler]

On 04.11.12 22:57, Andre Oppermann wrote:
 On 04.11.2012 21:15, Andreas Tobler wrote:
 On 04.11.12 14:57, Andre Oppermann wrote:
 On 04.11.2012 13:11, Kim Culhan wrote:
 On Sun, November 4, 2012 6:21 am, Dimitry Andric wrote:
 On 2012-11-04 02:13, Manfred Antar wrote:
 At 03:29 PM 11/3/2012, Adrian Chadd wrote:
 After the commit, there was a small discussion thread on svn-src-head@
 about the possible problems with the approach.  Maybe you are
 experiencing those?

 As the commit message says, you should be able to turn the feature off
 using:

  sysctl net.inet.tcp.experimental.initcwnd10=0

 Can you please try that, and see if the problems go away?

 FWIW this did not make the problem go away on 2 machines.

 Yes, this very much looks like the same problem as in PR/173309.

 Please try the attached patch.  It fixes the connection hang issue.
 There may be a second issue I debugging currently base on the feedback
 from Fabian Keil.

 I jump into this thread since I have a similar network issue.

 My scenario:

 'make installkernel DESTDIR=/netboot/test' to a nfs mounted drive.
 The nfs drive on the server is an ufs fs. No zfs.

 Up to r242261 I can install the kernel (or world) in a fluent way to the
 nfs destination.

 From r242262 it doesn't work smooth. I have stalls, sometimes my
 patience is not enough and I kill the process.

 I tried 242266 with the above mentioned patch. No real success.

 How can I help/test?
 
 Please try the attach patch instead of the above mentioned one.

Test run based on 242266. It starts much smoother. But it stalls later
on. Continues, stalls for several seconds, cont.

thx so far.

Andreas

1391  0  D+   0:00.00 install -o root -g wheel -m 555 crypto.ko
/netboot/test_install

procstat -kk 1391
  PIDTID COMM TDNAME   KSTACK
 1391 100099 install  -mi_switch+0x186
sleepq_timedwait+0x42 _sleep+0x1c9 clnt_vc_call+0x763
clnt_reconnect_call+0xfb newnfs_request+0xadb nfscl_request+0x72
nfsrpc_setattr+0x28f nfs_setattr+0x2b0 VOP_SETATTR_APV+0x31
setfmode+0x101 vn_chmod+0x8a sys_fchmod+0x8b amd64_syscall+0x55f
Xfast_syscall+0xf7

___
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: softdep: out of journaling space for softdep!

[Andreas Tobler]

- Original Message 
From: O. Hartmann ohart...@zedat.fu-berlin.de
To: Current FreeBSD freebsd-current@freebsd.org
Subject: softdep: out of journaling space for softdep!
Date: 09/11/12 09:05

 I just received since two days from now on one of my FreeBSD 10-CUR
 boxes a kernel message after syncing disks, just the moment when the
 system is supposed to switch off or reboot, like
 
 softdep: out of journaling space for softdep
 
 or something similar. I checked the /var/log for more details, but
 nothing has been logged there so far regarding this subject.
 
 The box in question has buildworld and kernel most recent as
 
 FreeBSD 10.0-CURRENT #0 r242747M: Thu Nov  8 10:40:09 CET 2012 amd64
 
 The system is CLANG compiled, as it is now the standard and with
 
 CXXFLAGS+=  -stdlib=libc++ -std=c++11
 
 The box has its root filesystem on a SAMSUNG 830 SSD with a capacity of
 120 GB, GPT partitions, UFS2 formated.
 
 The box is the only one of a bunch of other FBSD 10 boxes with the very
 same software revision and a similar setup, but with traditional
harddrives.
 
 I can not reboot the box, the box is spinning with the above mentioned
 error message forever (did so for day on the unattended box).
 
 A 'hard' reboot is quit with a kernel dump due to quot;sleeping
threadquot;.


I saw something similar last night.

This morning I tried:

http://svnweb.freebsd.org/base?view=revisionrevision=242815

And it seemed fixed.
Though I did not do a stress test.

Andreas


___
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: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd))

[Andreas Tobler]

On 01.12.12 16:15, Robert Watson wrote:
 
 Dear all:
 
 I've now committed the build glue required to install the recently merged 
 Audit Distribution Daemon (auditdistd) contributed by the Pawel Dawidek, and 
 sponsored by the FreeBSD Foundation.  This allows individual hosts generating 
 audit trails to submit trails to a central audit server for review and safe 
 keeping.  Part of the goal is to ensure that a host submitting trail data 
 can't later modify the trails.  Pawel uses a variety of useful security- and 
 resilience-related features such as TLS, Capsicum, etc, in auditdistd.  As 
 the 
 recent security incident in the FreeBSD.org cluster illustrated, having 
 reliable and detailed audit trails makes a big difference in forensic work, 
 and hopefully this will allow the FreeBSD Project (and our users) to do that 
 better in the future.

Aehm, hope it is ok to 'complain' here.

Happens when installing world.

cd /export/devel/fbsd/head/src;
/usr/obj/export/devel/fbsd/head/src/make.amd64/make -f Makefile.inc1
LOCAL_MTREE= hierarchy
cd /export/devel/fbsd/head/src/etc; 
/usr/obj/export/devel/fbsd/head/src/make.amd64/make distrib-dirs
mtree -eU  -f /export/devel/fbsd/head/src/etc/mtree/BSD.root.dist -p /
mtree -eU  -f /export/devel/fbsd/head/src/etc/mtree/BSD.var.dist -p /var
mtree: line 22: unknown user auditdistd
*** [distrib-dirs] Error code 1

Andreas
___
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: Distributed audit daemon committed

[Andreas Tobler]

On 01.12.12 22:53, Chris Rees wrote:
 
 On 1 Dec 2012 21:51, Andreas Tobler andreast-l...@fgznet.ch
 mailto:andreast-l...@fgznet.ch wrote:

 On 01.12.12 16:15, Robert Watson wrote:
 
  Dear all:
 
  I've now committed the build glue required to install the recently
 merged
  Audit Distribution Daemon (auditdistd) contributed by the Pawel
 Dawidek, and
  sponsored by the FreeBSD Foundation.  This allows individual hosts
 generating
  audit trails to submit trails to a central audit server for review
 and safe
  keeping.  Part of the goal is to ensure that a host submitting trail
 data
  can't later modify the trails.  Pawel uses a variety of useful
 security- and
  resilience-related features such as TLS, Capsicum, etc, in
 auditdistd.  As the
  recent security incident in the FreeBSD.org cluster illustrated, having
  reliable and detailed audit trails makes a big difference in
 forensic work,
  and hopefully this will allow the FreeBSD Project (and our users) to
 do that
  better in the future.

 Aehm, hope it is ok to 'complain' here.

 Happens when installing world.

 cd /export/devel/fbsd/head/src;
 /usr/obj/export/devel/fbsd/head/src/make.amd64/make -f Makefile.inc1
 LOCAL_MTREE= hierarchy
 cd /export/devel/fbsd/head/src/etc;
 /usr/obj/export/devel/fbsd/head/src/make.amd64/make distrib-dirs
 mtree -eU  -f /export/devel/fbsd/head/src/etc/mtree/BSD.root.dist -p /
 mtree -eU  -f /export/devel/fbsd/head/src/etc/mtree/BSD.var.dist -p /var
 mtree: line 22: unknown user auditdistd
 *** [distrib-dirs] Error code 1
 
 Does mergemaster -p help?

Hey, thank you! I'm now able to installworld.

Andreas

___
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 powerpc64/powerpc

[Andreas Tobler]

On 25.12.11 00:59, Justin Hibbits wrote:

On Dec 24, 2011 6:46 PM, FreeBSD Tinderboxtinder...@freebsd.org  wrote:


TB --- 2011-12-24 21:13:44 - tinderbox 2.8 running on

freebsd-current.sentex.ca

TB --- 2011-12-24 21:13:44 - starting HEAD tinderbox run for

powerpc64/powerpc

TB --- 2011-12-24 21:13:44 - cleaning the object tree
TB --- 2011-12-24 21:13:56 - cvsupping the source tree
TB --- 2011-12-24 21:13:56 - /usr/bin/csup -z -r 3 -g -L 1 -h

cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile

TB --- 2011-12-24 21:14:08 - building world
TB --- 2011-12-24 21:14:08 - CROSS_BUILD_TESTING=YES
TB --- 2011-12-24 21:14:08 - MAKEOBJDIRPREFIX=/obj
TB --- 2011-12-24 21:14:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2011-12-24 21:14:08 - SRCCONF=/dev/null
TB --- 2011-12-24 21:14:08 - TARGET=powerpc
TB --- 2011-12-24 21:14:08 - TARGET_ARCH=powerpc64
TB --- 2011-12-24 21:14:08 - TZ=UTC
TB --- 2011-12-24 21:14:08 - __MAKE_CONF=/dev/null
TB --- 2011-12-24 21:14:08 - cd /src
TB --- 2011-12-24 21:14:08 - /usr/bin/make -B buildworld

World build started on Sat Dec 24 21:14:08 UTC 2011
Rebuilding the temporary build tree
stage 1.1: legacy release compatibility shims
stage 1.2: bootstrap tools
stage 2.1: cleaning up the object tree
stage 2.2: rebuilding the object tree
stage 2.3: build tools
stage 3: cross tools
stage 4.1: building includes
stage 4.2: building libraries
stage 4.3: make dependencies
stage 4.4: building everything
stage 5.1: building 32 bit shim libraries
World build completed on Sat Dec 24 23:35:25 UTC 2011

TB --- 2011-12-24 23:35:25 - generating LINT kernel config
TB --- 2011-12-24 23:35:25 - cd /src/sys/powerpc/conf
TB --- 2011-12-24 23:35:25 - /usr/bin/make -B LINT
TB --- 2011-12-24 23:35:25 - cd /src/sys/powerpc/conf
TB --- 2011-12-24 23:35:25 - /usr/sbin/config -m LINT
TB --- 2011-12-24 23:35:25 - building LINT kernel
TB --- 2011-12-24 23:35:25 - CROSS_BUILD_TESTING=YES
TB --- 2011-12-24 23:35:25 - MAKEOBJDIRPREFIX=/obj
TB --- 2011-12-24 23:35:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2011-12-24 23:35:25 - SRCCONF=/dev/null
TB --- 2011-12-24 23:35:25 - TARGET=powerpc
TB --- 2011-12-24 23:35:25 - TARGET_ARCH=powerpc64
TB --- 2011-12-24 23:35:25 - TZ=UTC
TB --- 2011-12-24 23:35:25 - __MAKE_CONF=/dev/null
TB --- 2011-12-24 23:35:25 - cd /src
TB --- 2011-12-24 23:35:25 - /usr/bin/make -B buildkernel KERNCONF=LINT

Kernel build for LINT started on Sat Dec 24 23:35:25 UTC 2011
stage 1: configuring the kernel
stage 2.1: cleaning up the object tree
stage 2.2: rebuilding the object tree
stage 2.3: build tools
stage 3.1: making dependencies
stage 3.2: building everything

[...]
cc -c -O -pipe  -std=c99  -Wall -Wredundant-decls -Wnested-externs

-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions
  -Wmissing-include-dirs -fdiagnostics-show-option   -nostdinc  -I.
-I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -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 -msoft-float -Wa,-many
-fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc
-ffreestanding -fstack-protector -Werror  /src/sys/dev/fb/fb.c

cc -c -O -pipe  -std=c99  -Wall -Wredundant-decls -Wnested-externs

-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions
  -Wmissing-include-dirs -fdiagnostics-show-option   -nostdinc  -I.
-I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -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 -msoft-float -Wa,-many
-fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc
-ffreestanding -fstack-protector -Werror  /src/sys/dev/hwpmc/hwpmc_powerpc.c

/src/sys/dev/hwpmc/hwpmc_powerpc.c: In function 'powerpc_intr':
/src/sys/dev/hwpmc/hwpmc_powerpc.c:689: error: 'AMD_PMC_ENABLE'

undeclared (first use in this function)

/src/sys/dev/hwpmc/hwpmc_powerpc.c:689: error: (Each undeclared

identifier is reported only once

/src/sys/dev/hwpmc/hwpmc_powerpc.c:689: error: for each function it

appears in.)

/src/sys/dev/hwpmc/hwpmc_powerpc.c:689: error: 'union pmc_md_pmc' has no

member named 'pm_amd'

/src/sys/dev/hwpmc/hwpmc_powerpc.c:689: error: 'union pmc_md_pmc' has no

member named 'pm_amd'

*** Error code 1

Stop in /obj/powerpc.powerpc64/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2011-12-24 23:45:43 - WARNING: /usr/bin/make returned exit code  1
TB --- 2011-12-24 23:45:43 - ERROR: failed to build LINT kernel
TB --- 2011-12-24 23:45:43 - 7497.27 user 1367.80 system 9118.84 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full
___
freebsd-current@freebsd.org mailing list

Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value

[Andreas Tobler]

On 28.12.11 17:31, Rainer Hurling wrote:

On 28.12.2011 15:29 (UTC+1), Kostik Belousov wrote:

On Wed, Dec 28, 2011 at 03:10:12PM +0100, O. Hartmann wrote:

Am 12/28/11 14:58, schrieb Kostik Belousov:

On Wed, Dec 28, 2011 at 11:48:28AM +0100, O. Hartmann wrote:

Hello out here.

I run into a problem since one of the last portupdates and I do not know
whether this has to do with binutils or gcc46 or even FreeBSD 9.0/10.0
AMD64.

Background:
We use a scientific graphical toolset for planetary research called
ISIS3, which is provided by the USGS. We patched ISIS3 to run on FreeBSD
8/9/10 so far and it ran well with FreeBSD 8.2-STABLE and 9.0-PRE a
couple of weeks ago.
On all of my boxes, I do frequently a portupgrade, so I saw binutils got
bumped up and gcc 4.6 is also getting really frequently changed these days.
After a some portupdates within the last weeks, I just decided to
compile ISIS3 again to keep it fresh and on track, but it won't
compile anymore.

On all FreeBSD 9.0-PRERELEASE and FreeBSD 10.0-CURRENT (all AMD64 and
CLANG built) I receive in some subfolders containing sources the
follwoing error:

[...]
  Adding API object [UniqueIOCachingAlgorithm]
  Adding API object [UniversalGroundMap]
  Adding API object [UserInterface]
  Adding API object [VariableLineScanCameraDetectorMap]
  Adding API object [VecFilter]
  Adding API object [WorldMapper]
  Adding API object [iException]
  Adding API object [iString]
  Adding API object [iTime]
Working on Package [mex] (11:30:15)
  Adding API object [HrscCamera]
/usr/local/bin/ld:
/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a(functexcept.o):
relocation R_X86_64_32 against `std::bad_exception::~bad_exception()'
can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a:
could not read symbols: Bad value
collect2: ld returned 1 exit status
gmake[5]: *** [plugin] Error 1
cp: libHrscCamera.so: No such file or directory
gmake[4]: *** [install] Error 1

The error is completely clear as it is: the build tries to link static
library libstdc++.so into shared object. This is not supported.


Thanks, Kostik, for the fast response.
The error isn't so clear to me, sorry. I thought libstdc++.a is the
static library and it is taken to be referenced/compiled into a shared

Linked in.


object created by the application I try to compile.

Right, and this is not supported. Code linked into shared object must
be compiled PIC. An .a library usually does not contain objects compiled
by PIC, ld just dutifully reported back.



I'm much more confused now, since I thought the last time I compiled
that piece of software, I never got any error like that. Well, clang
fails with some obscure errors on the code itself and I'm unwilling to
correct them, I'll try the legacy gcc 4.2.1 and will report what's
happening.


It might have worked by accident (because libstdc++.a objects referenced
during the link did not carried unsupported relocations), or, much more
likely, the build system has changed and started doing stupid things.
It must not link static libraries into shared objects.

You should examine why it does this, and fix it. Changing compilers is
just wasting a time.



Hmm, I get a similar error when trying to build lang/gcc46 on recent
10-CURRENT:


[..snip..]
Making all in include
gmake[4]: Entering directory
`/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include'
mkdir -p ./x86_64-portbld-freebsd10.0/bits/stdc++.h.gch
/usr/ports/lang/gcc46/work/build/./gcc/xgcc -shared-libgcc
-B/usr/ports/lang/gcc46/work/build/./gcc -nostdinc++
-L/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/src
-L/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/src/.libs
-B/usr/local/x86_64-portbld-freebsd10.0/bin/
-B/usr/local/x86_64-portbld-freebsd10.0/lib/ -isystem
/usr/local/x86_64-portbld-freebsd10.0/include -isystem
/usr/local/x86_64-portbld-freebsd10.0/sys-include-x c++-header
-nostdinc++ -g -O2 -pipe -I/usr/local/include -fno-strict-aliasing
-I/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include/x86_64-portbld-freebsd10.0
-I/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include
-I/usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/libsupc++ -O2
-g -std=gnu++0x
/usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h
\
-o x86_64-portbld-freebsd10.0/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from
/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include/chrono:38:0,
   from
/usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h:100:
/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libstdc++-v3/include/ratio:133:31:
error: 

disable GUPROF for archs other than i386 and amd64

[Andreas Tobler]

Hi,

I'm working on profiling support for powerpc64 and I struggled over the 
mprofiler-epilogue option not being known on the ppc gcc.
Disabling this option for ppc uncovered the next thing, MCOUNT_OVERHEAD, 
MEXITCOUNT_OVERHEAD and MEXITCOUNT_OVERHEAD_GETLABEL are also not 
defined. Not only on ppc but everywhere except on i386 and amd64.


So for the time being, would it be ok if I disable GUPROF on archs other 
than i386 and amd64?


The patch below would be a candidate.

Thoughts?

TIA,
Andreas


Index: conf/kern.pre.mk
===
--- conf/kern.pre.mk(revision 229741)
+++ conf/kern.pre.mk(working copy)
@@ -103,13 +103,16 @@

 .if defined(PROFLEVEL)  ${PROFLEVEL} = 1
 CFLAGS+=   -DGPROF -falign-functions=16
+PROF=  -pg
 .if ${PROFLEVEL} = 2
 CFLAGS+=   -DGPROF4 -DGUPROF
-PROF=  -pg -mprofiler-epilogue
+.if ${MACHINE_CPUARCH} == i386 || ${MACHINE_CPUARCH} == amd64
+PROF+= -mprofiler-epilogue
 .else
-PROF=  -pg
+.error GUPROF not supported on ${MACHINE_CPUARCH}.
 .endif
 .endif
+.endif
 DEFINED_PROF=  ${PROF}

 # Put configuration-specific C flags last (except for ${PROF}) so that 
they

___
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 enabling iwi due to sysctl

[Andreas Tobler]

On 01/22/12 15:51, Super Bisquit wrote:

# sysctl  legal.intel_iwi.license_ack=1
sysctl: unknown oid 'legal.intel_iwi.license_ack'


You should put it in your loader.conf.

[t43:~] andreast% cat /boot/loader.conf
legal.intel_iwi.license_ack=1

Given that your were looking on how to make iwi work...

Gruss,
Andreas
___
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: nullfs broken on powerpc

[Andreas Tobler]

On 25.01.12 21:29, Eitan Adler wrote:

On Wed, Jan 25, 2012 at 2:50 PM, Milan Obuchfreebsd-curr...@dino.sk  wrote:

On Wed, 25 Jan 2012 14:21:23 +0200
Kostik Belousovkostik...@gmail.com  wrote:


On Tue, Jan 24, 2012 at 06:31:52PM +0100, Milan Obuch wrote:

Hi,



[ snip ]


This does not work with powerpc for me. With sources csup'ped this
morning, full system rebuild with GENERIC kernel, it is enough for
me to issue

mount_nullfs /data/src10 /usr/src
csup /usr/share/examples/cvsup/standard-supfile

and system panic occurs, with following on system console:

panic: mtx_lock() of spin mutex (null)
@ /usr/src/sys/kern/vfs_subr.c:2670 cpuid = 0
KDB: enter: panic
[ thread pid 1442 tid 100095 ]
Stopped at 0x40f734: addi r0, r0, 0x0
db

At this point, I am able to interact with system, the question for
me is what I want to get from it :) I tried bt with following
result:

Tracing pid 1442 tid 100095 td 0x2d6b000
0xe22c26d0: at panic+0x274
0xe22c2730: at _mtx_lock_flags+0xc4
0xe22c2760: at vgonel+0x330
0xe22c27b0: at vrecycle+0x54
0xe22c27d0: at null_inactive+0x30
0xe22c27f0: at VOP_INACTIVE_APV+0xdc
0xe22c2810: at vinactive+0x98
0xe22c2850: at vputx+0x344
0xe22c28a0: at vput+0x18
0xe22c28c0: at kern_statat_vnhook+0x108
0xe22c29d0: at kern_statat+0x18
0xe22c29f0: at kern_lstat+0x2c
0xe22c2a10: at sys_lstat+0x30
0xe22c2a90: at trap+0x388
0xe22c2b60: at powerpc_interrupt+0x108
0xe22c2b90: user SC trap by _end+0x40d88c70: srr1=0xd032
 r1=0xffaf9a70 cr=0x28004044 xer=0x2000
ctr=0x41a0ac40
db

Does this shed any light for someone with more knowledge here? My
gut feeling is there is some endianness issue at play, the same
nullfs usage works for me flawlessly on both i386 and amd64
systems, so it could not be 32 vs 64 bit issue at least.

At line 2670 of /usr/src/sys/kern/vfs_subr.c I see end of function
void vgonel(struct vnode *vp)

 VI_LOCK(vp);
 vp-v_vnlock =vp-v_lock;
 vp-v_op =dead_vnodeops;
 vp-v_tag = none;
 vp-v_type = VBAD;
}

so the question seems to be reduced to 'why is vp null?' or is my
small attempt on analyse flawed...



I do not think that the vp is null. It more look like the *vp memory
was zeroed. This has very low chances of being related to endianess,
and more like a kernel memory corruption.

Take a dump and print the content of *vp.


How could I look into memory? I found page
http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-ddb.html
and I can see registers (show reg), use x with absolute addresses, but
something like 'x vp' tells just 'Symbol not known' - should I somehow
load symbol table into memory? But backtrace shows function names... or
should I somehow modify GENERIC kernel to include more debugging info?
Kernel debugging is a bit new for me, even if I can write simple
modification into kernel, but only in some special (and narrow) area of
code...



From ddb write 'call doadump'. Provided you have a proper dump device

set up in rc.conf it should work. You could then use kgdb from a
running computer to analyze the dump in more detail.


This only works if your target is booke, AIM (Apple based machines) do 
not have the 'call doadump' implemented yet. It is somewhere on my long 
todo list.


Gruss,
Andreas

___
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: [PATCH] ACPI object refcount fix

[Andreas Tobler]

On 28.03.12 00:13, Jung-uk Kim wrote:

The upstream maintainer just e-mailed me a possible fix for the
problem and it looks very promising.  Please try the attached patch.
Note the patch reverts r233555 and applies the fix.  This patch is
also available from here:

http://people.freebsd.org/~jkim/acpi_refcnt.diff

Thanks!


Thank you very much, T60 is up and running!

Gruss,
Andreas
___
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: pw is broken?

[Andreas Tobler]

On 09.03.13 15:52, Hartmann, O. wrote:
 Am 03/09/13 15:34, schrieb hiren panchasara:
 On Mar 8, 2013 9:44 PM, KT Sin kt...@acm.org wrote:

 pw is crashing with seg fault due to this change?


 http://svnweb.freebsd.org/base/head/lib/libutil/gr_util.c?r1=245390r2=247919

 I think the correct fix is committed with:
 http://svnweb.freebsd.org/changeset/base/248102

 Hiren

 # gdb ./pw
 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 amd64-marcel-freebsd...
 (gdb) run groupadd test123 -g 12345
 Starting program: /usr/src/usr.sbin/pw/pw groupadd test123 -g 12345

 Program received signal SIGSEGV, Segmentation fault.
 0x80d84a4f in stpcpy () from /lib/libc.so.7
 (gdb) bt full
 #0  0x80d84a4f in stpcpy () from /lib/libc.so.7
 No symbol table info available.
 #1  0x80a5c00a in grcopy (gr=0x612ce0, newgr=0x81409100, name=0x0,
 ndx=0) at /usr/src/lib/libutil/gr_util.c:496
 dst = 0x8 Error reading address 0x8: Bad address
 i = 1090277153
 #2  0x80a5bdc6 in gr_add (gr=0x612ce0, newmember=0x0)
 at /usr/src/lib/libutil/gr_util.c:451
 newgr = (struct group *) 0x81409100
 len = 0
 num_mem = 0
 #3  0x80a5bd4f in gr_dup (gr=0x612ce0)
 at /usr/src/lib/libutil/gr_util.c:434
 No locals.
 #4  0x0040bad7 in gr_update (grp=0x612ce0, group=0x0) at
 grupd.c:78
 pfd = 0
 tfd = 4244492
 gr = (struct group *) 0x0
 old_gr = (struct group *) 0x0
 #5  0x0040ba8f in addgrent (grp=0x612ce0) at grupd.c:111
 No locals.
 #6  0x0040a83d in pw_group (cnf=0x612bf0, mode=0, args=0x613e78)
 at pw_group.c:258
 ---Type return to continue, or q return to quit---
 grp = (struct group *) 0x612ce0
 members = (char **) 0x81485d00
 rc = 0
 a_name = (struct carg *) 0x8144c0a0
 a_gid = (struct carg *) 0x8144c0c0
 arg = (struct carg *) 0x0
 grmembers = 200
 fakegroup = {gr_name = 0x7fffdcb9 test123,
   gr_passwd = 0x40fbc9 *, gr_gid = 12345, gr_mem = 0x81485d00}
 #7  0x004037fb in main (argc=3, argv=0x7fffd9f0) at pw.c:230
 which = 1
 config = 0x0
 cnf = (struct userconf *) 0x612bf0
 ch = -1
 mode = 0
 opts = {{0x40e150
 V:C:qn:u:c:d:e:p:g:G:mM:k:s:oL:i:w:h:H:Db:NPy:Y,
 0x40e180 V:C:qn:u:rY,
 0x40e18c V:C:qn:u:c:d:e:p:g:G:mM:l:k:s:w:L:h:H:FNPY,
 0x40e1b7 V:C:qn:u:FPa7, 0x40e1c5 V:C:q, 0x40e1c5 V:C:q,
 0x40e1c5 V:C:q}, {0x40e1cb V:C:qn:g:h:H:M:opNPY,
 0x40e1e0 V:C:qn:g:Y, 0x40e1eb V:C:qn:d:g:l:h:H:FM:m:NPY,
 0x40e205 V:C:qn:g:FPa, 0x40e1c5 V:C:q, 0x0, 0x0}}
 funcs = {0x405270 pw_user, 0x409b60 pw_group}
 (gdb)
 
 But neither r248102 nor r248103 compile!
 
 /usr/src/sys/net80211/ieee80211_output.c:600:23: error: unused variable
 'ic' [-Werror,-Wunused-variable]
 struct ieee80211com *ic = ni-ni_ic;)
 (


Try this the below.

Andreas


Index: sys/net80211/ieee80211_output.c
===
--- sys/net80211/ieee80211_output.c (revision 248096)
+++ sys/net80211/ieee80211_output.c (working copy)
@@ -597,10 +597,9 @@
struct ieee80211vap *vap = ni-ni_vap;
struct ieee80211_tx_ampdu *tap;
struct ieee80211_frame *wh = mtod(m, struct ieee80211_frame *);
-   struct ieee80211com *ic = ni-ni_ic;
ieee80211_seq seqno;

-   IEEE80211_TX_LOCK_ASSERT(ic);
+   IEEE80211_TX_LOCK_ASSERT(ni-ni_ic);

wh-i_fc[0] = IEEE80211_FC0_VERSION_0 | type;
if ((type  IEEE80211_FC0_TYPE_MASK) == IEEE80211_FC0_TYPE_DATA) {

___
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

buildworld with WITHOUT_CLANG_IS_CC= ?

[Andreas Tobler]

Hello,

how do I do a buildworld these days with this option set:
WITHOUT_CLANG_IS_CC=

iow, without clang as default compiler?

I fail on amd64 and powerpc64 when it comes to build the 32-bit libs. It
fails because it can not find header files like math.h

The behaviour started with

http://svnweb.freebsd.org/changeset/base/250659

Any ideas how to solve that?

TIA,
Andreas
___
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: kernel compile broken in latest HEAD

[Andreas Tobler]

On 09.07.13 22:33, Alexander Leidinger wrote:
 On Tue, 9 Jul 2013 17:32:33 +0200
 Gary Jennejohn gljennj...@googlemail.com wrote:
 
 I just saw this breakage while compiling a kernel on HEAD updated
 minutes ago:

So did I.


 Is your cc a gcc or clang? My one is clang and I didn't get build
 errors when I tested the commit. I was told there are those errors with
 gcc. My question in the corresponding thread is so far unanswered.

My cc is gcc, stock.

 Here's what I wrote as a reference:
 ---snip---
 Does someone know what this is supposed to result in?
 
 I would assume as the unions are unnamed and no variable is declared
 inside the struct with it, that the size of the struct is the same as
 not having those unions inside the structs.
 
 If this is correct I would assume the correct fix would be to #if-0
 them out.
 ---snip---

I did so and my kernelbuild is happy now. Yes, I do not use this header
at all.

 These line numbers all point at nameless unions.

 Seems to me that a union needs a name, otherwise one cannot
 access its contents.

 I simply named them all x to get the kernel to compile, which
 succeeded.
 
 Did you name it x (union x {...};), or did you declare a variable
 x with it (union {...} x;)?

___
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: world build stuck in gnu for about a week for me.

[Andreas Tobler]

On 14.11.10 16:40, eculp wrote:

I build world several times a week on this machine:
9.0-CURRENT FreeBSD 9.0-CURRENT #126: Mon Nov  8 07:22:49 CST 2010

Since the above build I have not been able to get past gnu.

Today it broke at gdb :


===  gnu/usr.bin/dialog (cleandir)
===  gnu/usr.bin/dialog/TESTS (cleandir)
===  gnu/usr.bin/diff (cleandir)
===  gnu/usr.bin/diff/doc (cleandir)
rm -f diff.info diff.info.gz
===  gnu/usr.bin/diff3 (cleandir)
===  gnu/usr.bin/gdb (cleandir)
===  gnu/usr.bin/gdb/doc (cleandir)
===  gnu/usr.bin/gdb/libgdb (cleandir)
Unclosed substitution for TARGET_ARCH (/ missing)


This one was fixed today:

http://svn.freebsd.org/viewvc/base?view=revisionrevision=215292

Gruss,
Andreas
___
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: drm.ko does not build on powerpc

[Andreas Tobler]

On 20.11.10 19:00, Super Biscuit wrote:

I'm using SNAPSHOT-9 (Current) powerpc from people.freebsd.org/~whitehorn.


Can you update the src to something after 16.11?

Nathan did commit a (build) fix around the 16.11.

Gruss,
Andreas
___
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: PING: Re: HEADS UP: utmp.h gone. All welcome utmpx.h.

[Andreas Tobler]

Ping again.

Tia,
Andreas

On 07.02.10 21:54, Andreas Tobler wrote:

Hi all,

On 17.01.10 13:11, Andreas Tobler wrote:


On 17.01.10 02:36, Ed Schouten wrote:


* Andreas Toblerandreast-l...@fgznet.chwrote:

So far everything went smooth. But one issue I have, I use mlterm
(/usr/ports/x11/mlterm) and here I fail to build it.

kik_utmp_bsd.c:28:2: error: #error UT_LINESIZE is not defined.
kik_utmp_bsd.c:32:2: error: #error _PATH_UTMP is not defined.
kik_utmp_bsd.c:36:2: error: #error _PATH_WTMP is not defined.
kik_utmp_bsd.c:40:2: error: #error _PATH_LASTLOG is not defined.

I see they where defined in utmp.h, but I do not see how to
handle/patch this with the current situation.

Would you mind giving me a hand on how to fix this? I'm willing to
hack/test.


Could you try the attached patch? Nobutaka, if the patch works properly,
could you commit it to CVS, please?


Thanks a lot!

Works here so far.


I use the patch you sent me with success. Everytime I sync the ports
tree it is gone :(

Is there something we forgot to test? Or why is this patch not committed
to the ports tree?

If you'd need some help/test from my side, please tell me.



___
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

How to disable CLANG co build in buildworld?

[Andreas Tobler]

Hello,

how can I disable the build of CLANG in a buildworld?

I have a sparc64 machine which is quite slow. And for my purpose I do 
not need CLANG etc. atm.


Thanks for any pointer.

Andreas
___
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 to disable CLANG co build in buildworld?

[Andreas Tobler]

Hi Ed, and all the others,

On 11.06.10 20:52, Ed Schouten wrote:


* Andreas Toblerandreast-l...@fgznet.ch  wrote:

I have a sparc64 machine which is quite slow. And for my purpose I
do not need CLANG etc. atm.


Clang is not enabled on sparc64, so there is no need to disable
anything. If you do want to disable Clang on i386, amd64, pc98 or
powerpc, add WITHOUT_CLANG=yes to /etc/src.conf, as described in
src.conf(5).


I must have missed this.

Well it is not only sparc64, also powerpc(64).


Thank you very much for the quick reply.

Gruss,
Andreas
___
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 to disable CLANG co build in buildworld?

[Andreas Tobler]

On 11.06.10 21:56, M. Warner Losh wrote:

In message:20100611.132052.271446115462387749@bsdimp.com
 M. Warner Loshi...@bsdimp.com  writes:
: In message:20100611185237.gl56...@hoeg.nl
: Ed Schoutene...@80386.nl  writes:
: : Hello Andreas,
: :
: : * Andreas Toblerandreast-l...@fgznet.ch  wrote:
: :  I have a sparc64 machine which is quite slow. And for my purpose I
: :  do not need CLANG etc. atm.
: :
: : Clang is not enabled on sparc64, so there is no need to disable
: : anything. If you do want to disable Clang on i386, amd64, pc98 or
: : powerpc, add WITHOUT_CLANG=yes to /etc/src.conf, as described in
: : src.conf(5).
:
: Except that clang isn't quite disabled when cross-building, due to the
: issue I pointed out when the commit went in wrt bsd.own.mk.
: MACHINE_ARCH is still amd64 until we start to build the sparc64
: binaries, so anything in the bootstrapping part of the build will not
: be disabled.  that's one of many reasons disabling things in
: bsd.own.mk based on architecture is going to fail.

And even if you add WITHOUT_CLANG to your src.conf, we still always
build some of the clang infrastructure in the bootstrap tools
phase...  But we have to do that to avoid getting not being able to
build clang on an architecture that doesn't have it for an
architecture that does.


I can confirm that. I just set up a build for powerpc with WITHOUT_CLANG 
and in the first building steps I saw this.


I don't care if it is only a few minutes of building time, but I 
disagree if it is going to be  10 minutes/hours in case of multilib 
builds (32-bit libs and 64-bit libs) as it is on powerpc64. On powerpc64 
the WITHOUT_CLANG helped to avoid the build of the multilib.


I do not have anything against CLANG. I only want to be able to steer 
what I want.


Gruss,
Andreas



___
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 powerpc/powerpc

[Andreas Tobler]

On 12.06.10 12:59, FreeBSD Tinderbox wrote:

TB --- 2010-06-12 09:19:14 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-06-12 09:19:14 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2010-06-12 09:19:15 - cleaning the object tree
TB --- 2010-06-12 09:19:27 - cvsupping the source tree
TB --- 2010-06-12 09:19:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/powerpc/powerpc/supfile
TB --- 2010-06-12 09:19:57 - building world
TB --- 2010-06-12 09:19:57 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-06-12 09:19:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-06-12 09:19:57 - TARGET=powerpc
TB --- 2010-06-12 09:19:57 - TARGET_ARCH=powerpc
TB --- 2010-06-12 09:19:57 - TZ=UTC
TB --- 2010-06-12 09:19:57 - __MAKE_CONF=/dev/null
TB --- 2010-06-12 09:19:57 - cd /src
TB --- 2010-06-12 09:19:57 - /usr/bin/make -B buildworld

World build started on Sat Jun 12 09:19:57 UTC 2010
Rebuilding the temporary build tree
stage 1.1: legacy release compatibility shims
stage 1.2: bootstrap tools
stage 2.1: cleaning up the object tree
stage 2.2: rebuilding the object tree
stage 2.3: build tools
stage 3: cross tools
stage 4.1: building includes
stage 4.2: building libraries
stage 4.3: make dependencies
stage 4.4: building everything

[...]
cc -O2 -pipe  -DUSE_GZIP=1 -fno-strict-aliasing 
-I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 
-fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k 
-Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/index.c
cc -O2 -pipe  -DUSE_GZIP=1 -fno-strict-aliasing 
-I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 
-fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k 
-Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/install.c
cc1: warnings being treated as errors
/src/usr.sbin/sysinstall/install.c: In function 'installStandard':
/src/usr.sbin/sysinstall/install.c:632: warning: unused variable 'devs'
/src/usr.sbin/sysinstall/install.c:631: warning: unused variable 'tries'
/src/usr.sbin/sysinstall/install.c: In function 'installFixupBase':
/src/usr.sbin/sysinstall/install.c:877: warning: unused variable 'fp'
*** Error code 1


Index: install.c
===
--- install.c   (revision 209106)
+++ install.c   (working copy)
@@ -874,7 +874,9 @@
 int
 installFixupBase(dialogMenuItem *self)
 {
+#if defined(__i386__) || defined(__amd64__)
 FILE *fp;
+#endif
 #ifdef __ia64__
 const char *efi_mntpt;
 #endif

Gruss,
Andreas

___
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 powerpc/powerpc

[Andreas Tobler]

On 12.06.10 15:57, Andreas Tobler wrote:

On 12.06.10 12:59, FreeBSD Tinderbox wrote:

TB --- 2010-06-12 09:19:14 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-06-12 09:19:14 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2010-06-12 09:19:15 - cleaning the object tree
TB --- 2010-06-12 09:19:27 - cvsupping the source tree
TB --- 2010-06-12 09:19:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/powerpc/powerpc/supfile
TB --- 2010-06-12 09:19:57 - building world
TB --- 2010-06-12 09:19:57 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-06-12 09:19:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-06-12 09:19:57 - TARGET=powerpc
TB --- 2010-06-12 09:19:57 - TARGET_ARCH=powerpc
TB --- 2010-06-12 09:19:57 - TZ=UTC
TB --- 2010-06-12 09:19:57 - __MAKE_CONF=/dev/null
TB --- 2010-06-12 09:19:57 - cd /src
TB --- 2010-06-12 09:19:57 - /usr/bin/make -B buildworld

World build started on Sat Jun 12 09:19:57 UTC 2010
Rebuilding the temporary build tree
stage 1.1: legacy release compatibility shims
stage 1.2: bootstrap tools
stage 2.1: cleaning up the object tree
stage 2.2: rebuilding the object tree
stage 2.3: build tools
stage 3: cross tools
stage 4.1: building includes
stage 4.2: building libraries
stage 4.3: make dependencies
stage 4.4: building everything

[...]
cc -O2 -pipe  -DUSE_GZIP=1 -fno-strict-aliasing 
-I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 
-fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k 
-Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/index.c
cc -O2 -pipe  -DUSE_GZIP=1 -fno-strict-aliasing 
-I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 
-fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k 
-Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/install.c
cc1: warnings being treated as errors
/src/usr.sbin/sysinstall/install.c: In function 'installStandard':
/src/usr.sbin/sysinstall/install.c:632: warning: unused variable 'devs'
/src/usr.sbin/sysinstall/install.c:631: warning: unused variable 'tries'
/src/usr.sbin/sysinstall/install.c: In function 'installFixupBase':
/src/usr.sbin/sysinstall/install.c:877: warning: unused variable 'fp'
*** Error code 1




Here the complete one:
Index: install.c
===
--- install.c   (revision 209106)
+++ install.c   (working copy)
@@ -628,8 +628,11 @@
 int
 installStandard(dialogMenuItem *self)
 {
-int i, tries = 0;
+int i;
+#ifdef WITH_SLICES
+int tries = 0;
 Device **devs;
+#endif

 variable_set2(SYSTEM_STATE, standard, 0);
 dialog_clear_norefresh();
@@ -874,7 +877,9 @@
 int
 installFixupBase(dialogMenuItem *self)
 {
+#if defined(__i386__) || defined(__amd64__)
 FILE *fp;
+#endif
 #ifdef __ia64__
 const char *efi_mntpt;
 #endif


Gruss,
Andreas

___
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

only 3 of 4GB memory available on amd64 8.1-RC1

[Andreas Tobler]

Hi all,

I got my hands on a t60 with 4GB of RAM (BIOS displays it)

And I installed 8.1-RC1 on it:

FreeBSD 8.1-RC1 #0: Mon Jun 14 13:40:28 UTC 2010
r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Intel(R) Core(TM)2 CPU T5600  @ 1.83GHz (1828.76-MHz 
K8-class CPU)

  Origin = GenuineIntel  Id = 0x6f6  Family = 6  Model = f  Stepping = 6

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
  Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
  AMD Features=0x20100800SYSCALL,NX,LM
  AMD Features2=0x1LAHF
  TSC: P-state invariant
real memory  = 4294967296 (4096 MB)
avail memory = 3092344832 (2949 MB)
ACPI APIC Table: LENOVO TP-79   
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1



Do I need to configure something special to get the full 4GB of memory?

I only found the PAE hint, but this is for x86 machines, right?

Thanks for any hint.
Andreas
___
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: only 3 of 4GB memory available on amd64 8.1-RC1

[Andreas Tobler]

On 19.06.10 19:27, Andrey Fesenko wrote:

On Sat, Jun 19, 2010 at 9:16 PM, Andreas Toblerandreast-l...@fgznet.ch  wrote:

Hi all,

I got my hands on a t60 with 4GB of RAM (BIOS displays it)

And I installed 8.1-RC1 on it:

FreeBSD 8.1-RC1 #0: Mon Jun 14 13:40:28 UTC 2010
r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Intel(R) Core(TM)2 CPU T5600  @ 1.83GHz (1828.76-MHz K8-class
CPU)
  Origin = GenuineIntel  Id = 0x6f6  Family = 6  Model = f  Stepping = 6

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
  Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
  AMD Features=0x20100800SYSCALL,NX,LM
  AMD Features2=0x1LAHF
  TSC: P-state invariant
real memory  = 4294967296 (4096 MB)
avail memory = 3092344832 (2949 MB)
ACPI APIC Table:LENOVO TP-79
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
  cpu0 (BSP): APIC ID:  0
  cpu1 (AP): APIC ID:  1



Do I need to configure something special to get the full 4GB of memory?

I only found the PAE hint, but this is for x86 machines, right?


I think this BIOS specific, may be video rezerv


FreeBSD 9.0-CURRENT #0 r208284: Wed May 19 09:34:15 MSD 2010
 and...@my_book:/home/andrey/obj/obj/home/andrey/src_head/sys/MY_BOOK amd64
WARNING: WITNESS option enabled, expect reduced performance.
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Intel(R) Core(TM)2 CPU T5600  @ 1.83GHz (1828.77-MHz K8-class CPU)
   Origin = GenuineIntel  Id = 0x6f2  Family = 6  Model = f  Stepping = 2
   
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
   Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
   AMD Features=0x20100800SYSCALL,NX,LM
   AMD Features2=0x1LAHF
   TSC: P-state invariant
real memory  = 4294967296 (4096 MB)
avail memory = 3339923456 (3185 MB)


Thanks. I'll explore the bios a bit more then.

Andreas
___
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: only 3 of 4GB memory available on amd64 8.1-RC1

[Andreas Tobler]

On 19.06.10 22:26, Andriy Gapon wrote:

on 19/06/2010 20:16 Andreas Tobler said the following:

Hi all,

I got my hands on a t60 with 4GB of RAM (BIOS displays it)

And I installed 8.1-RC1 on it:

FreeBSD 8.1-RC1 #0: Mon Jun 14 13:40:28 UTC 2010
 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Intel(R) Core(TM)2 CPU T5600  @ 1.83GHz (1828.76-MHz
K8-class CPU)
   Origin = GenuineIntel  Id = 0x6f6  Family = 6  Model = f  Stepping = 6

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

   Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
   AMD Features=0x20100800SYSCALL,NX,LM
   AMD Features2=0x1LAHF
   TSC: P-state invariant
real memory  = 4294967296 (4096 MB)
avail memory = 3092344832 (2949 MB)
ACPI APIC Table:LENOVO TP-79
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
  cpu0 (BSP): APIC ID:  0
  cpu1 (AP): APIC ID:  1



Do I need to configure something special to get the full 4GB of memory?

I only found the PAE hint, but this is for x86 machines, right?


Yes, PAE is for what we call in FreeBSD land i386.
x86 we use for both i386 and amd64.

Now, to the rest.
I recently investigated this topic myself, so I can share what I learned.
The first thing you'd want to have is SMAP information.
You can get it at the loader prompt with 'smap' command.
It is also reported by kernel during a verbose boot, but it is only printed to
console; it is not saved to dmesg, because it is printed before msgbuf is 
created.

Example of how SMAP information looks:
SMAP type=01 base= end=0009f800
SMAP type=02 base=000f end=0010
SMAP type=02 base=fec0 end=0001
SMAP type=02 base=e000 end=f000
SMAP type=02 base=0009f800 end=000a
SMAP type=02 base=bfdf end=bfe0
SMAP type=01 base=0010 end=bfde
SMAP type=03 base=bfde3000 end=bfdf
SMAP type=04 base=bfde end=bfde3000
SMAP type=01 base=0001 end=00013000

Type 1 ('01') is memory ranges free for OS use.
Note that the ranges could be unsorted.

SMAP would give you an idea what is free for OS use and what is taken away for
BIOS and hardware needs.  Also note that what's reported as avail memory is
smaller than sum of sizes of all unreserved regions.  Some space is taken away
by FreeBSD virtual memory code to store some core page/memory management
information (~3%).  Memory used by kernel and preloaded modules is also not
included into avail memory.

If you discover that your system reserves, in your opinion, too much memory,
then consider the following things.
1. Some memory might be allocated as video adapter's aperture and/or video
adapter's memory in case of some integrated graphics solutions.
2. Some memory addresses below 4GB are used for MMIO (memory mapped
input/output) - accessing those addresses is actually communicating with some
hardware rather than accessing DRAM.  Some hardware+firmware combinations can
hoist (or remap) DRAM that corresponds to such an address range to a different
address range above 4G.  If you examine last line of my sample SMAP output, then
you'll see that there is 756MB of type 01 RAM above 4GB and that machine has
exactly 4GB of DRAM installed - this is MMIO range 0xd000-0x1
hoisted to 0x1-0x13000.
If your hardware doesn't support that option, then too bad - the memory is
overshadowed by MMIO and is effectively lost.
Sometimes hoisting option (under whatever name) has to be explicitly set in BIOS
configuration.


Thanks for the explanation!


That's about all.
I am curious as to what you would discover about your system - please share 
with us.


I'd like to, but how do I get this information out of my box? There is 
no serial line. The only way I know is getting a screen shot. Do you 
know another way?
Unfortunately I do not have a docking station, there I guess I'd have a 
serial line.


Also, sorry for the delay, I had to upgrade the bios in hope that the 
em0 is recognized properly, but no chance:


em0: Intel(R) PRO/1000 Network Connection 7.0.5 port 0x3000-0x301f mem 
0xee00-0xee01 irq 16 at device 0.0 on pci2

em0: attempting to allocate 1 MSI vectors (1 supported)
msi: routing MSI IRQ 256 to local APIC 0 vector 49
em0: using IRQ 256 for MSI
em0: Using MSI interrupt
em0: The EEPROM Checksum Is Not Valid

Thanks again!
Andreas


___
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: only 3 of 4GB memory available on amd64 8.1-RC1

[Andreas Tobler]

On 21.06.10 21:35, Andriy Gapon wrote:

on 21/06/2010 22:19 Andreas Tobler said the following:

On 19.06.10 22:26, Andriy Gapon wrote:
I'd like to, but how do I get this information out of my box? There is
no serial line. The only way I know is getting a screen shot. Do you
know another way?
Unfortunately I do not have a docking station, there I guess I'd have a
serial line.


Screenshot is fine by today's standards :-) Especially if you can OCR it by 
hand.


It will end up in a png :)


Or large enough (very large!) SC_HISTORY_SIZE in kernel options (start with
1000) and moused.


I'll try that.


Or a tiny kernel module that I wrote that can reproduce SMAP info upon loading:
http://people.freebsd.org/~avg/smap.diff
Comes with no guarantee or warranty :)



This one too, I'll try it. But nevertheless my interest in this piece of 
HW has dropped.


I got this t60 because the display is broken, someone broke the glass.
This is no problem so far, but the issue that I can only access it via 
cardbus netif is boring me.


Thanks for your hints!
Andreas
___
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 commit: r210194 - head/sys/fs/unionfs

[Andreas Tobler]

On 17.07.10 17:45, Edward Tomasz Napierala wrote:

Author: trasz
Date: Sat Jul 17 15:45:20 2010
New Revision: 210194
URL: http://svn.freebsd.org/changeset/base/210194

Log:
   Remove updating process count by unionfs.  It serves no purpose, unionfs just
   needs root credentials for a moment.

Modified:
   head/sys/fs/unionfs/union_subr.c

Modified: head/sys/fs/unionfs/union_subr.c
==
--- head/sys/fs/unionfs/union_subr.cSat Jul 17 13:34:01 2010
(r210193)
+++ head/sys/fs/unionfs/union_subr.cSat Jul 17 15:45:20 2010
(r210194)
@@ -50,7 +50,6 @@
  #includesys/fcntl.h
  #includesys/filedesc.h
  #includesys/stat.h
-#includesys/resourcevar.h

  #includesecurity/mac/mac_framework.h

@@ -775,7 +774,6 @@ unionfs_mkshadowdir(struct unionfs_mount
/* Authority change to root */
rootinfo = uifind((uid_t)0);
cred = crdup(cnp-cn_cred);
-   chgproccnt(cred-cr_ruidinfo, 1, 0);
change_euid(cred, rootinfo);
change_ruid(cred, rootinfo);
change_svuid(cred, (uid_t)0);
@@ -825,7 +823,6 @@ unionfs_mkshadowdir_free_out:

  unionfs_mkshadowdir_abort:
cnp-cn_cred = credbk;
-   chgproccnt(cred-cr_ruidinfo, -1, 0);
crfree(cred);

return (error);
___
svn-src-h...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org



cc1: warnings being treated as errors
/export/devel/fbsd/head/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c: 
In function 'unionfs_mkshadowdir':
/export/devel/fbsd/head/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:775: 
warning: implicit declaration of function 'uifind'
/export/devel/fbsd/head/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:775: 
warning: nested extern declaration of 'uifind'
/export/devel/fbsd/head/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:775: 
warning: assignment makes pointer from integer without a cast
/export/devel/fbsd/head/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:780: 
warning: implicit declaration of function 'uifree'
/export/devel/fbsd/head/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:780: 
warning: nested extern declaration of 'uifree'


Hm, I'd like to include this one again:

[tc:fbsd/head/src] andreast% svn diff sys/fs/unionfs/union_subr.c
Index: sys/fs/unionfs/union_subr.c
===
--- sys/fs/unionfs/union_subr.c (revision 210200)
+++ sys/fs/unionfs/union_subr.c (working copy)
@@ -50,6 +50,7 @@
 #include sys/fcntl.h
 #include sys/filedesc.h
 #include sys/stat.h
+#include sys/resourcevar.h

 #include security/mac/mac_framework.h


Gruss,
Andreas

___
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: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition!

[Andreas Tobler]

On 31.10.14 22:23, Dag-Erling Smørgrav wrote:

Can you all please tell me which revision(s) you were running before you
upgraded?  Something like bzgrep 11.0-CURRENT /var/log/messages*
should do the trick.


+1 here. 'Corrupted' /usr. Changed entry in fstab to not check fs.

[zrhws131:/boot/kernel.old] andreast% strings kernel | grep CURRENT
@(#)FreeBSD 11.0-CURRENT #33 r273767M: Tue Oct 28 11:20:32 CET 2014

Andreas

___
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: CURRENT breaks loading of nvidia.so

[Andreas Tobler]

On 17.01.15 16:18, Bob Willcox wrote:

Yesterday when I upgraded my current box I encountered this failure when
attempting to load the nvidia-driver (nvidia.so):

link_elf_obj: symbol _callout_stop_safe undefined
linker_load_file: Unsupported file type

So, today I updtated my system again today hoping it might be fixed but the
problem persists.

System info:

FreeBSD han.immure.com 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r277299: Sat Jan 17 
08:52:41 CST 2015 b...@han.immure.com:/usr/obj/usr/src/sys/HAN  amd64


I think you have to rebuild the nvidia-driver against your fresh built 
system. At least I had and my T510 s working again with the nvidia.ko.


Gruss,
Andreas

___
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: powerpc and powerpc64 builds broken

[Andreas Tobler]

On 28.06.15 21:32, Konstantin Belousov wrote:

On Sun, Jun 28, 2015 at 12:09:25PM -0700, Justin Hibbits wrote:

On Sun, Jun 28, 2015 at 11:36 AM, Garrett Cooper yaneurab...@gmail.com wrote:



On Jun 28, 2015, at 10:48, Justin Hibbits jhibb...@freebsd.org wrote:

Both powerpc and powerpc64 builds are broken in the same way, in
usr.bin/mkesdb.  It was working correctly as of just before BSDCan, I
successfully built world and kernel on June 6.

The error seen at this point is:

cc  -O2 -pipe   -I/home/chmeee/freebsd/head/usr.bin/mkesdb
-I/home/chmeee/freebsd/head/usr.bin/mkesdb/../mkesdb
-I/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc/iconv
-std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
-Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
-Wold-style-definition -Wno-pointer-sign
-L/home/chmeee/world/zhabar/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc
-o mkesdb lex.o yacc.o
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/usr/bin/ld:
undefined reference to symbol `_end' (try adding -lc)
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so.7:
could not read symbols: Bad value

I've seen this both locally on my G5, and on the Power8 in the FreeBSD cluster.


- What does file say when you run it on libc.so.7?


/usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit MSB shared object,
64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked,
not stripped

I think a libc linker could try for that command line lives in
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/lib/libc/libc.so
or in
/home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so

But, the reason for your troubles seems to come from the
usr.bin/mkesdb/Makefile.  Why does it explicitely adds LDFLAGS to point
to objdir/.../libc, I have no idea.



Neither me.

Here with this mods it compiles:

Either:

--- Makefile(revision 284911)
+++ Makefile(working copy)
@@ -3,7 +3,7 @@
 .PATH: ${.CURDIR}/../../lib/libc/iconv

 PROG=  mkesdb
-LDFLAGS+= -L${.OBJDIR}/../../lib/libc
+LDFLAGS+= -L${.OBJDIR}/../../lib/libc/libc

 NO_WMISSING_VARIABLE_DECLARATIONS=


Or:

Index: Makefile
===
--- Makefile(revision 284911)
+++ Makefile(working copy)
@@ -3,7 +3,7 @@
 .PATH: ${.CURDIR}/../../lib/libc/iconv

 PROG=  mkesdb
-LDFLAGS+= -L${.OBJDIR}/../../lib/libc
+LDFLAGS+= -L${.CURDIR}/../../lib/libc

 NO_WMISSING_VARIABLE_DECLARATIONS=

Andreas

___
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: [CFT] Unicode collation string and reworked locale definitions

[Andreas Tobler]

On 01.11.15 22:30, Baptiste Daroussin wrote:

On Wed, Oct 14, 2015 at 12:23:06AM +0200, Baptiste Daroussin wrote:

Hi all,

I have been working for a while on bringing in Unicode string collation
support by merging code from Illumos (by Garrett D'Amore who kindly made sure
his work was made under BSD license) and Dragonfly (by John Marino), and some
ancient work done on FreeBSD by edwin@ but never merged.

The result is available in the projects/collation branch.

As a result of this work, is:
- Locales are now generated with the new localedef(1) tool from CLDR POSIX files
- The generated files are now identified as "BSD 1.0" format
- Only "BSD 1.0" locales files are now read, all other version will be set to
   "C"
- The localedef(1) tool has been imported from Illumos and modidied to use
   tree(3) instead of the CDDL avl(3)
- A set of tool created by edwin@ and extended by marino@ for dragonfly has been
   added to be able to generate locales
- Given our regex(3) does not support multibyte yet (actually it does not
   support some single-byte codeset) it has been forced to always use locale C
- Remove colldef(1) and mklocale(1)
- Finish implementing the numeric BSD extension for ctypes
- Add a bunch of new locales: some arabian locales, hebrew locales, some
   regional locales, etc.
- Make a bunch of ISO-8859-1 locales simple aliase on ISO-8859-15 where it makes
   sense
- Add short version of locales
- Add @euro aliases on the locales where that make sense

Please test the branch and report issues.

Note that yes that means the COLLATION_FIX patch on glib2 will not be necessary
anymore
and yes the icu patch on postgresql will not be necessary anymore

Best regards,
Bapt


All issues reported has been fixed, except if more issues are reported, this
will be merged into head next saturday: November 7th



Cool! Waiting for it!

Thanks,
Andreas

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: powerpc64-gcc 5.2 vintages get L". . ." type wrong compared to Char for FreeBSD for lib32 compiling

[Andreas Tobler]

On 06.12.15 22:34, Mark Millard wrote:

[I picked the lists that I did because powerpc64-gcc is the external
toolchain created to allow modern powerpc64 builds.]

For the powerpc64-gcc 5.2 vintages. . . (using my environment's path
as an example)

/usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-5.2.0/gcc/config/rs6000/freebsd64.h
has:


/* rs6000.h gets this wrong for FreeBSD.  We use the GCC defaults
instead.  */ #undef WCHAR_TYPE #define WCHAR_TYPE
(TARGET_64BIT ? "int" : "long int") #undef  WCHAR_TYPE_SIZE #define
WCHAR_TYPE_SIZE 32


That type in quotes ends up being the base type for L". . ."
notation, for example. Probably the char notation as well (L'?').

For FreeBSD Char compatibility in a powerpc64 lib32 context that
"long int" should effectively instead be "int", making the
conditional above technically unnecessary.

This blocks compiling lib32 source code that uses such notations as
L". . .": "long int" is not compatible with FreeBSD's Char in the
powerpc64 environment's 32 bit environment. Some compiler message are
explicit about the base types of pointers that result for the
mismatches: that is how I know that "long int" is in use for L". . ."
and "int" is the other base type involved.

(Yes, freebsd64.h appears to be used for lib32, at least on
powerpc64.  By contrast freebsd.h agrees for the WCHAR_TYPE_SIZE but
only undef's WCHAR_TYPE, presuming gcc defaults are correct for
FreeBSD as far as the type goes. It might need a more explicit type
to be sure of a Char match for that freebsd.h file's context.)

The 4.9 vintages of powerpc64-gcc were messed up the same way, as was
noted at the time.


I'll take care.

Andreas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Segfault in _Unwind_* code called from pthread_exit

[Andreas Tobler]

On 05.11.17 21:31, Gerald Pfeifer wrote:

On Sun, 5 Nov 2017, Andreas Tobler wrote:

Pushed on all active branches, 8/7/6.


Saw that, thank you.  Very well done, Andreas!

I should have gcc8-devel updated in the next 24 hours, gcc7-devel
and gcc6-devel over the week as new snapshots are released.


Cool thx!


If you could do the gcc* branches, yes please.


Once the respective -devel ports are updated, I'll take care of
the corresponding stable ports.


Patch available if you want. (applicable to all gcc* ports, 5-8)


I got one request to have the patch also in gcc5


Let's see.  First I want to address the five newer ports, then
possibly this one (though gcc5 is hardly used).


Sure, but I can understand comment #13 of the pr mentioned. Even if 
hardly used, consistency is always good :)


Andreas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Segfault in _Unwind_* code called from pthread_exit

[Andreas Tobler]

On 01.11.17 14:21, Gerald Pfeifer wrote:

On Wed, 1 Nov 2017, Tijl Coosemans wrote:

Please commit it to the ports tree as well, because there are reports
that ftp/curl can trigger the problem.


What Andreas and me usually are doing is that he commits fixes
upstream (from HEAD down to release branches), I pick them up when
updating the gcc*-devel ports, and if important he temporarily adds
patches to the gcc* ports until the next release obsoletes them.

Andreas, I can take of the gcc* ports this time once you have
pushed things upstream.


Pushed on all active branches, 8/7/6.

If you could do the gcc* branches, yes please. I got one request to have 
the patch also in gcc5, see in the original 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635).
It's up on you if we will support this. I don't mind running a test on 
gcc-5.5. Let me know.


Gruss,
Andreas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Segfault in _Unwind_* code called from pthread_exit

[Andreas Tobler]

On 26.08.17 20:40, Konstantin Belousov wrote:

On Sat, Aug 26, 2017 at 08:28:13PM +0200, Tijl Coosemans wrote:

On Sat, 26 Aug 2017 02:44:42 +0300 Konstantin Belousov  
wrote:

How does llvm unwinder detects that the return address is a garbage ?


It just stops unwinding when it can't find frame information (stored in
.eh_frame sections).  GCC unwinder doesn't give up yet and checks if the
return address points to the signal trampoline (which means the current
frame is that of a signal handler).  It has built-in knowledge of how to
unwind to the signal trampoline frame.

So llvm just gives up on signal frames ?


A noreturn attribute isn't enough.  You can still unwind such functions.
They are allowed to throw exceptions for example.

Ok.


I did consider using
a CFI directive (see patch below) and it works, but it's architecture
specific and it's inserted after the function prologue so there's still
a window of a few instructions where a stack unwinder will try to use
the return address.

Index: lib/libthr/thread/thr_create.c
===
--- lib/libthr/thread/thr_create.c  (revision 322802)
+++ lib/libthr/thread/thr_create.c  (working copy)
@@ -251,6 +251,7 @@ create_stack(struct pthread_attr *pattr)
  static void
  thread_start(struct pthread *curthread)
  {
+   __asm(".cfi_undefined %rip");
 sigset_t set;
  
 if (curthread->attr.suspend == THR_CREATE_SUSPENDED)


I like this approach much more than the previous patch.  What can be
done is to provide asm trampoline which calls thread_start().  There you
can add the .cfi_undefined right at the entry.

It is somewhat more work than just setting the return address on the
kernel-constructed pseudo stack frame, but I believe this is ultimately
correct way.  You still can do it only on some arches, if you do not
have incentive to code asm for all of them.

Also crt1 probably should get the same treatment, despite we already set
%rbp to zero AFAIR.


Did some commit result out of this discussion or is this subject still 
under investigation?


Curious because I got this gcc PR:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635

Tia,
Andreas

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Segfault in _Unwind_* code called from pthread_exit

[Andreas Tobler]

On 30.10.17 15:32, Tijl Coosemans wrote:

On Sun, 29 Oct 2017 20:40:46 +0100 Andreas Tobler <andreast-l...@fgznet.ch> 
wrote:

Attached what I have for libgcc. It can be applied to gcc5-8, should
give no issues. The mentioned tc from this thread and mine,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635 do pass.

What do you think?


Like I said before the return address can be anything.  It could for
instance point to some instruction in a random function and then the
stack unwinder will think thread_start was called from that function.
There's no check you can add to libgcc to distinguish that from a
normal valid return address.

Maybe not, and most probably I do not understand what is happening. But 
with my modification I survive the test case.


If no objections from your or Konstantin's side come up I will commit it 
to the gcc repo. It will not 'fix' the issue, but it will improve the 
gcc behavior.


Andreas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Segfault in _Unwind_* code called from pthread_exit

[Andreas Tobler]

On 31.10.17 10:28, Konstantin Belousov wrote:

On Mon, Oct 30, 2017 at 10:54:05PM +0100, Andreas Tobler wrote:

On 30.10.17 15:32, Tijl Coosemans wrote:

On Sun, 29 Oct 2017 20:40:46 +0100 Andreas Tobler <andreast-l...@fgznet.ch> 
wrote:

Attached what I have for libgcc. It can be applied to gcc5-8, should
give no issues. The mentioned tc from this thread and mine,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635 do pass.

What do you think?


Like I said before the return address can be anything.  It could for
instance point to some instruction in a random function and then the
stack unwinder will think thread_start was called from that function.
There's no check you can add to libgcc to distinguish that from a
normal valid return address.


Maybe not, and most probably I do not understand what is happening. But
with my modification I survive the test case.

If no objections from your or Konstantin's side come up I will commit it
to the gcc repo. It will not 'fix' the issue, but it will improve the
gcc behavior.


I posted something similar when the discussion thread started. From the
cursory look, your patch is better than mine. The only difference that
makes me wonder is that I used #ifdef KERN_PROC_SIGTRAMP around the
block because I believe gcc has more relaxed policy about supporting
obsoleted OS versions.


I am aware about KERN_PROC_SIGTRAMP and older OS releases, that's why I 
asked for feedback.
Do we, FreeBSD'ers, want to have gcc unwind support on older than 
FreeBSD 9.3 releases? I think the gcc folks do not care, but we are the 
ones who might have an need for such a support?

@Gerald, do you have an opinion?

I can 'ifdef' the new code and in the 'else' case we fall back to the 
already existing path.


Thank you both for the feedback.
Andreas

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Segfault in _Unwind_* code called from pthread_exit

[Andreas Tobler]

On 31.10.17 22:36, Gerald Pfeifer wrote:

On Tue, 31 Oct 2017, Andreas Tobler wrote:

Do we, FreeBSD'ers, want to have gcc unwind support on older than
FreeBSD 9.3 releases? I think the gcc folks do not care, but we are the
ones who might have an need for such a support?
@Gerald, do you have an opinion?


Yes. No. :-)

Those possibly still stuck on obsolete versions of FreeBSD don't
need/want fancy new compilers and GCC 4.9 is still available for
use and does not exhibit this issue, correct?  (If it does, nobody
reported any problems.)


It is limited to gcc >=5, gcc-4.9 does not have the 
MD_FALLBACK_FRAME_STATE_FOR defined.



I can 'ifdef' the new code and in the 'else' case we fall back to
the already existing path.


If it's "cheap", that might be nice.


Attached, the test is running on gcc trunk and gcc-6. gcc-6 is the last 
one with java support and there we have quite extensive test cases which 
really test for this MD_FALLBACK_FRAME_STATE_FOR macro. These test 
cases, Throw_2 and co do pass. So I think the new bits should be fine.

Also some coming asan test cases do pass with this addition too.


Thanks to the three of you - Tijl, Konstantin, and Andreas!


Gruss,
Andreas

Index: libgcc/config/i386/freebsd-unwind.h
===
--- libgcc/config/i386/freebsd-unwind.h (revision 254205)
+++ libgcc/config/i386/freebsd-unwind.h (working copy)
@@ -28,7 +28,10 @@
 
 #include 
 #include 
+#include 
+#include 
 #include 
+#include 
 #include 
 
 #define REG_NAME(reg)  sf_uc.uc_mcontext.mc_## reg
@@ -36,6 +39,39 @@
 #ifdef __x86_64__
 #define MD_FALLBACK_FRAME_STATE_FOR x86_64_freebsd_fallback_frame_state
 
+#ifdef KERN_PROC_SIGTRAMP
+ /* Newer versions of FreeBSD, > FreeBSD 9.3, provide a
+kern.proc.sigtramp. sysctl that returns the location of the
+signal trampoline. We use this information to find out if we're in
+a trampoline or not.
+ */
+static int
+x86_64_outside_sigtramp_range (unsigned char *pc)
+{
+  static int sigtramp_range_determined = 0;
+  static unsigned char *sigtramp_start, *sigtramp_end;
+
+  if (sigtramp_range_determined == 0)
+{
+  struct kinfo_sigtramp kst = {0};
+  size_t len = sizeof (kst);
+  int mib[4] = { CTL_KERN, KERN_PROC, KERN_PROC_SIGTRAMP, getpid() };
+
+  sigtramp_range_determined = 1;
+  if (sysctl (mib, 4, , , NULL, 0) == 0)
+  {
+sigtramp_range_determined = 2;
+sigtramp_start = kst.ksigtramp_start;
+sigtramp_end   = kst.ksigtramp_end;
+  }
+}
+  if (sigtramp_range_determined < 2)  /* sysctl failed if < 2 */
+return 1;
+
+  return (pc < sigtramp_start || pc >= sigtramp_end);
+}
+#endif
+
 static _Unwind_Reason_Code
 x86_64_freebsd_fallback_frame_state
 (struct _Unwind_Context *context, _Unwind_FrameState *fs)
@@ -43,6 +79,7 @@
   struct sigframe *sf;
   long new_cfa;
 
+#ifndef KERN_PROC_SIGTRAMP
   /* Prior to FreeBSD 9, the signal trampoline was located immediately
  before the ps_strings.  To support non-executable stacks on AMD64,
  the sigtramp was moved to a shared page for FreeBSD 9.  Unfortunately
@@ -62,12 +99,15 @@
 && *(unsigned int *)(context->ra +  8) == 0x01a1c0c7
 && *(unsigned int *)(context->ra + 12) == 0x050f ))
 return _URC_END_OF_STACK;
+#else
+  if (x86_64_outside_sigtramp_range(context->ra))
+return _URC_END_OF_STACK;
+#endif
 
   sf = (struct sigframe *) context->cfa;
   new_cfa = sf->REG_NAME(rsp);
   fs->regs.cfa_how = CFA_REG_OFFSET;
-  /* Register 7 is rsp  */
-  fs->regs.cfa_reg = 7;
+  fs->regs.cfa_reg =  __LIBGCC_STACK_POINTER_REGNUM__;
   fs->regs.cfa_offset = new_cfa - (long) context->cfa;
 
   /* The SVR4 register numbering macros aren't usable in libgcc.  */
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Segfault in _Unwind_* code called from pthread_exit

[Andreas Tobler]

On 29.10.17 20:13, Konstantin Belousov wrote:

On Sun, Oct 29, 2017 at 06:23:51PM +0100, Tijl Coosemans wrote:

On Sat, 26 Aug 2017 21:40:34 +0300 Konstantin Belousov  
wrote:

On Sat, Aug 26, 2017 at 08:28:13PM +0200, Tijl Coosemans wrote:

I did consider using
a CFI directive (see patch below) and it works, but it's architecture
specific and it's inserted after the function prologue so there's still
a window of a few instructions where a stack unwinder will try to use
the return address.

Index: lib/libthr/thread/thr_create.c
===
--- lib/libthr/thread/thr_create.c  (revision 322802)
+++ lib/libthr/thread/thr_create.c  (working copy)
@@ -251,6 +251,7 @@ create_stack(struct pthread_attr *pattr)
  static void
  thread_start(struct pthread *curthread)
  {
+   __asm(".cfi_undefined %rip");
 sigset_t set;
  
 if (curthread->attr.suspend == THR_CREATE_SUSPENDED)


I like this approach much more than the previous patch.  What can be
done is to provide asm trampoline which calls thread_start().  There you
can add the .cfi_undefined right at the entry.

It is somewhat more work than just setting the return address on the
kernel-constructed pseudo stack frame, but I believe this is ultimately
correct way.  You still can do it only on some arches, if you do not
have incentive to code asm for all of them.


Ok, but then there are two ways to implement the trampoline:

1)
movq $0,(%rsp)
jmp thread_start
2)
subq $8,%rsp
call thread_start
/* NOTREACHED */

With 1) you're setting the return address to zero anyway, so you might
as well do that in the kernel like my first patch.  With 2) you're
setting up a new call frame, basically redoing what the kernel already
did and on i386 this also means copying the function argument.

I do not quite understand the second variant, because the stack is not
guaranteed to be zeroed, and it is often not if reused after the previously
exited thread.

The first variant is what I like, but perhaps we need to emulate the
frame as well, i.e. push two zero longs.

Currently kernel does not access the usermode stack for the new thread
unless dictated by ABI (i.e. it does not touch it for 64bit process
on amd64, but have to for 32bit).  I like this property.  Also, the
previous paragraph is indicative: we do not really know in kernel
what ABI the userspace follows.  It might want frame, may be it does
not need it.  It could use other register than %rbp as the frame base,
etc.



Do you have any preference (or better alternatives), because I think I
still prefer my first patch.  It's the caller's job to set up the call
frame, in this case the kernel.  And if the kernel handles it then it
also works with (hypothetical) implementations other than libthr.


Also crt1 probably should get the same treatment, despite we already set
%rbp to zero AFAIR.


I haven't checked but I imagine the return address of the process entry
point is always zero because the stack is all zeros.

Stack is not zero. The environment and argument strings and auxv are copied
at top, and at the bottom the ps_strings structure is located, so it
is not.

If you commit your existing patch as is, I will not resent.  But I do think
that stuff that can be done in usermode, should be done in usermode, esp.
when the amount of efforts is same.


Attached what I have for libgcc. It can be applied to gcc5-8, should 
give no issues. The mentioned tc from this thread and mine, 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635 do pass.


What do you think?

Andreas

Index: libgcc/config/i386/freebsd-unwind.h
===
--- libgcc/config/i386/freebsd-unwind.h (revision 254205)
+++ libgcc/config/i386/freebsd-unwind.h (working copy)
@@ -28,7 +28,10 @@
 
 #include 
 #include 
+#include 
+#include 
 #include 
+#include 
 #include 
 
 #define REG_NAME(reg)  sf_uc.uc_mcontext.mc_## reg
@@ -36,38 +39,46 @@
 #ifdef __x86_64__
 #define MD_FALLBACK_FRAME_STATE_FOR x86_64_freebsd_fallback_frame_state
 
+static int
+x86_64_outside_sigtramp_range (unsigned char *pc)
+{
+  static int sigtramp_range_determined = 0;
+  static unsigned char *sigtramp_start, *sigtramp_end;
+
+  if (sigtramp_range_determined == 0)
+{
+  struct kinfo_sigtramp kst = {0};
+  size_t len = sizeof (kst);
+  int mib[4] = { CTL_KERN, KERN_PROC, KERN_PROC_SIGTRAMP, getpid() };
+
+  sigtramp_range_determined = 1;
+  if (sysctl (mib, 4, , , NULL, 0) == 0)
+  {
+sigtramp_range_determined = 2;
+sigtramp_start = kst.ksigtramp_start;
+sigtramp_end   = kst.ksigtramp_end;
+  }
+}
+  if (sigtramp_range_determined < 2)  /* sysctl failed if < 2 */
+return 1;
+
+  return (pc < sigtramp_start || pc >= sigtramp_end);
+}
+
 static _Unwind_Reason_Code
 x86_64_freebsd_fallback_frame_state
 (struct _Unwind_Context *context, 

Re: Segfault in _Unwind_* code called from pthread_exit

[Andreas Tobler]

On 22.10.17 02:18, Tijl Coosemans wrote:

On Sat, 21 Oct 2017 22:02:38 +0200 Andreas Tobler <andre...@freebsd.org> wrote:

On 26.08.17 20:40, Konstantin Belousov wrote:

On Sat, Aug 26, 2017 at 08:28:13PM +0200, Tijl Coosemans wrote:

On Sat, 26 Aug 2017 02:44:42 +0300 Konstantin Belousov <kostik...@gmail.com> 
wrote:

How does llvm unwinder detects that the return address is a garbage ?


It just stops unwinding when it can't find frame information (stored in
.eh_frame sections).  GCC unwinder doesn't give up yet and checks if the
return address points to the signal trampoline (which means the current
frame is that of a signal handler).  It has built-in knowledge of how to
unwind to the signal trampoline frame.

So llvm just gives up on signal frames ?
   

A noreturn attribute isn't enough.  You can still unwind such functions.
They are allowed to throw exceptions for example.

Ok.
   

I did consider using
a CFI directive (see patch below) and it works, but it's architecture
specific and it's inserted after the function prologue so there's still
a window of a few instructions where a stack unwinder will try to use
the return address.

Index: lib/libthr/thread/thr_create.c
===
--- lib/libthr/thread/thr_create.c  (revision 322802)
+++ lib/libthr/thread/thr_create.c  (working copy)
@@ -251,6 +251,7 @@ create_stack(struct pthread_attr *pattr)
   static void
   thread_start(struct pthread *curthread)
   {
+   __asm(".cfi_undefined %rip");
  sigset_t set;
   
  if (curthread->attr.suspend == THR_CREATE_SUSPENDED)


I like this approach much more than the previous patch.  What can be
done is to provide asm trampoline which calls thread_start().  There you
can add the .cfi_undefined right at the entry.

It is somewhat more work than just setting the return address on the
kernel-constructed pseudo stack frame, but I believe this is ultimately
correct way.  You still can do it only on some arches, if you do not
have incentive to code asm for all of them.

Also crt1 probably should get the same treatment, despite we already set
%rbp to zero AFAIR.


Did some commit result out of this discussion or is this subject still
under investigation?

Curious because I got this gcc PR:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635


If I add the above to lib/libthr/thread/thr_create.c the mentioned PR works.


Sorry, but I didn't and won't have time to work on this.


Np.


Ideally I think there should be a function attribute to mark functions
as entry points.  The compiler would add ".cfi_undefined %rip" to such
functions (and maybe optimise the function prologue because there are
no caller registers that need to be preserved).  If you have connections
in the GCC community maybe you could discuss that with them.


Well, from my understanding I'd have to teach every compiler to do so, 
right? (Beside that I do not know how to.)


I think we need another solution to find out if an unwind context is 
garbage.


I'll take a look at how llvm does this w/o segfaulting.

Thx,
Andreas

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 12 PowerPC won’t boot at all.

[Andreas Tobler]

On 04.10.18 13:34, Alex McKeever wrote:

Subject says it all, that and it inverts the boot selector when selected. 
Tested it on my eMac G4 1.25 GHz (Retail). Last version of FreeBSD that works 
for me is 11.1, as 11.2 doesn’t boot all the way (hangs on cryptosoft0)


What image did you try? ALPHA8 should boot, but is not stable yet. If 
there will be an APLHA9, it should boot and should be stable, at least 
it is here.


Andreas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r342378 fails sometimes on boot mounting root (error 2)

[Andreas Tobler]

On 28.12.18 19:45, Matthias Apitz wrote:

El día viernes, diciembre 28, 2018 a las 09:07:49a. m. -0700, Ian Lepore 
escribió:


Try setting vfs.mountroot.timeout= in loader.conf to a value long
enough to let the usb drive get probed reliably. The default is 3
seconds, maybe a value like 5 or 10 would work better for you.

-- Ian


Thanks. I did so, but this does not help. When I does not work even
after 20 secs it fails to mount. After a lot of boot attempts I have the
following picture:

1. It always mounts fine when verbose message is selected.

2. It mounts fine when the line below about 'umass0:1:0: Attached to ... ' is
printed, if it is not, the mount fails later after 20 secs waiting;



Hm, here on my rpi3b+, with an attached usb disk I have to use this 
setting in loader.conf:


kern.cam.boot_delay="15000"

With the vfs.mountroot.timeout="xx" I end up in a shell because I'm not 
able to mount the partition in time. With the cam.boot_delay things are 
working fine.


Maybe this helps?

Andreas


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Loading DRM kills computer

[Andreas Tobler]

On 06.05.19 19:54, Hans Petter Selasky wrote:

On 2019-05-06 19:48, Hans Petter Selasky wrote:

On 2019-05-06 19:20, Thomas Laus wrote:

Farias Martinez [aaronfar...@att.net] wrote:

I’m using current on both of my laptop one with the module i915kms
and the other laptop uses radeonkms both work fine without a problem
on my laptop. Which module are you having issues with.


The i915kms on both.


Hi,

Can you try updating the kernel to the latest revision and build DRM
firmware+kmods from source. Some regression issues were introduced in
r346645 and were not fixed before r347089, but I cannot see that your
revision lies between those.



Hi,

Some sanity checking:

Kernel sources are in /usr/src

And latest version DRM module is built from
/usr/ports/graphics/drm-current-kmod ?

Can you check that /boot/modules gets cleaned after you deinstall
drm-current-kmod and gpu-firmware-kmod (both needs to be rebuilt).


Thanks, now at 347192 and my T430 works again with X. Before it was 
freezing under major load with X. It was only freezing when X was started.


Andreas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"