Re: makefs enhancement for better rock-ridge support

[Adrian Chadd]

Would you mind filing a PR?

-a

On 18 December 2013 09:27, Kurt Lidl  wrote:
> A while ago, it was reported that the ISO images that FreeBSD generates
> have a variety of problems (thread starts here):
>
> http://lists.freebsd.org/pipermail/freebsd-stable/2013-April/073050.html
>
> And again for the 10.0 releases:
>
> http://lists.freebsd.org/pipermail/freebsd-stable/2013-December/076284.html
>
> Looking into this, it appears that the various bugs in the Rock Ridge
> extensions have been fixed, except for the actual lack of recording
> the "serial" numbers in the correct place of the Rock Ridge data.
>
> As it turns out, it is almost trivial to fix this.
>
> Patch is attached to this message, which will probably be stripped
> out by the mailing list, but should be available as an attachment
> from the mail server.
>
> -Kurt
>
> ___
> 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"
___
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: ral(4) panic. head, r257837

[Adrian Chadd]

What's at frame 10?

And list the IP, ie:

list *0x817da911

-a

On 18 December 2013 23:04, Sergey V. Dyatko  wrote:
> Hi,
>
> I have following setup:
>
> wlans_ral0="wlan0"
> ifconfig_wlan0="WPA"
>
> cloned_interfaces="lagg0 bridge0 tap0"
> ifconfig_lagg0="laggproto failover laggport alc0 laggport wlan0 DHCP"
> ifconfig_bridge0="addm tap0 addm lagg0"
>
> When system boot I have reproducible panic after messages
> Waiting 30s for the default route interface: .
> ral0: need multicast update callback
> ral0: need multicast update callback
>  :
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x0
> fault code  = supervisor read data, page not present
> instruction pointer = 0x20:0x817da911
> stack pointer   = 0x28:0xfe011fe61da0
> frame pointer   = 0x28:0xfe011fe62630
> <118>.
> 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 = 1815 (dhclient)
>
> Reading symbols from /boot/kernel/zfs.ko.symbols...done.
> Loaded symbols for /boot/kernel/zfs.ko.symbols
> Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
> Loaded symbols for /boot/kernel/opensolaris.ko.symbols
> Reading symbols from /boot/kernel/linux.ko.symbols...done.
> Loaded symbols for /boot/kernel/linux.ko.symbols
> Reading symbols from /boot/kernel/if_alc.ko.symbols...done.
> Loaded symbols for /boot/kernel/if_alc.ko.symbols
> Reading symbols from /boot/kernel/if_ral.ko.symbols...done.
> Loaded symbols for /boot/kernel/if_ral.ko.symbols
> Reading symbols from /boot/kernel/snd_hda.ko.symbols...done.
> Loaded symbols for /boot/kernel/snd_hda.ko.symbols
> Reading symbols from /boot/kernel/sound.ko.symbols...done.
> Loaded symbols for /boot/kernel/sound.ko.symbols
> Reading symbols from /boot/kernel/acpi_video.ko.symbols...done.
> Loaded symbols for /boot/kernel/acpi_video.ko.symbols
> Reading symbols from /boot/modules/nvidia.ko...done.
> Loaded symbols for /boot/modules/nvidia.ko
> Reading symbols from /boot/modules/cuse4bsd.ko...done.
> Loaded symbols for /boot/modules/cuse4bsd.ko
> Reading symbols from /boot/kernel/sem.ko.symbols...done.
> Loaded symbols for /boot/kernel/sem.ko.symbols
> Reading symbols from /boot/kernel/linprocfs.ko.symbols...done.
> Loaded symbols for /boot/kernel/linprocfs.ko.symbols
> Reading symbols from /boot/kernel/if_lagg.ko.symbols...done.
> Loaded symbols for /boot/kernel/if_lagg.ko.symbols
> Reading symbols from /boot/kernel/if_bridge.ko.symbols...done.
> Loaded symbols for /boot/kernel/if_bridge.ko.symbols
> Reading symbols from /boot/kernel/bridgestp.ko.symbols...done.
> Loaded symbols for /boot/kernel/bridgestp.ko.symbols
> Reading symbols from /boot/kernel/if_tap.ko.symbols...done.
> Loaded symbols for /boot/kernel/if_tap.ko.symbols
>
> #0  doadump (textdump=0) at pcpu.h:219
> 219 pcpu.h: No such file or directory.
> in pcpu.h
> (kgdb) #0  doadump (textdump=0) at pcpu.h:219
> #1  0x803023ae in db_dump (dummy=,
> dummy2=0, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:543
> #2  0x80301e8d in db_command (cmd_table=)
> at /usr/src/sys/ddb/db_command.c:449
> #3  0x80301c04 in db_command_loop ()
> at /usr/src/sys/ddb/db_command.c:502
> #4  0x80304570 in db_trap (type=, code=0)
> at /usr/src/sys/ddb/db_main.c:231
> #5  0x8072e9d3 in kdb_trap (type=12, code=0, tf= optimized out>) at /usr/src/sys/kern/subr_kdb.c:656
> #6  0x80a81bb2 in trap_fatal (frame=0xfe011fe61cf0,
> eva=) at /usr/src/sys/amd64/amd64/trap.c:870
> #7  0x80a81ec9 in trap_pfault (frame=0xfe011fe61cf0,
> usermode=0) at /usr/src/sys/amd64/amd64/trap.c:692
> #8  0x80a8165b in trap (frame=0xfe011fe61cf0)
> at /usr/src/sys/amd64/amd64/trap.c:456
> #9  0x80a68222 in calltrap ()
> at /usr/src/sys/amd64/amd64/exception.S:232
> #10 0x817da911 in rt2860_tx (sc=0xfe9bd000,
> m=0xf80004c6dd00, ni=0x0)
> at /usr/src/sys/modules/ral/../../dev/ral/rt2860.c:1472
> #11 0x817da89e in rt2860_start_locked (ifp=0xf80003bed800)
> at /usr/src/sys/modules/ral/../../dev/ral/rt2860.c:1998
> #12 0x817d57b0 in rt2860_start (ifp=0xf80003bed800)
> at /usr/src/sys/modules/ral/../../dev/ral/rt2860.c:1972
> #13 0x807b5f35 in if_transmit (ifp=,
> m=) at /usr/src/sys/net/if.c:3352
> #14 0x807fbd96 in ieee80211_vap_pkt_send_dest (
> vap=, m=,
> ni=0xfe0003bae000) at /usr/src/sys/net80211/ieee80211_output.c:243
> #15 0x807fce09 in ieee80211_vap_transmit (ifp= out>, m=)
> out>at /usr/src/sys/net80211/ieee80211_output.c:393
> #16 0x8261d91f in lagg_transmit (ifp=0xf80003bec000,
> m=0xf80004c6dd00)
> at /usr/src/sys/modules/if_lagg/../../net/if_lagg.c:1314
> 

ral(4) panic. head, r257837

[Sergey V. Dyatko]

Hi,

I have following setup:

wlans_ral0="wlan0"
ifconfig_wlan0="WPA"

cloned_interfaces="lagg0 bridge0 tap0"
ifconfig_lagg0="laggproto failover laggport alc0 laggport wlan0 DHCP"
ifconfig_bridge0="addm tap0 addm lagg0"

When system boot I have reproducible panic after messages
Waiting 30s for the default route interface: .
ral0: need multicast update callback
ral0: need multicast update callback
 :

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x0
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x817da911
stack pointer   = 0x28:0xfe011fe61da0
frame pointer   = 0x28:0xfe011fe62630
<118>.
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 = 1815 (dhclient)

Reading symbols from /boot/kernel/zfs.ko.symbols...done.
Loaded symbols for /boot/kernel/zfs.ko.symbols
Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
Loaded symbols for /boot/kernel/opensolaris.ko.symbols
Reading symbols from /boot/kernel/linux.ko.symbols...done.
Loaded symbols for /boot/kernel/linux.ko.symbols
Reading symbols from /boot/kernel/if_alc.ko.symbols...done.
Loaded symbols for /boot/kernel/if_alc.ko.symbols
Reading symbols from /boot/kernel/if_ral.ko.symbols...done.
Loaded symbols for /boot/kernel/if_ral.ko.symbols
Reading symbols from /boot/kernel/snd_hda.ko.symbols...done.
Loaded symbols for /boot/kernel/snd_hda.ko.symbols
Reading symbols from /boot/kernel/sound.ko.symbols...done.
Loaded symbols for /boot/kernel/sound.ko.symbols
Reading symbols from /boot/kernel/acpi_video.ko.symbols...done.
Loaded symbols for /boot/kernel/acpi_video.ko.symbols
Reading symbols from /boot/modules/nvidia.ko...done.
Loaded symbols for /boot/modules/nvidia.ko
Reading symbols from /boot/modules/cuse4bsd.ko...done.
Loaded symbols for /boot/modules/cuse4bsd.ko
Reading symbols from /boot/kernel/sem.ko.symbols...done.
Loaded symbols for /boot/kernel/sem.ko.symbols
Reading symbols from /boot/kernel/linprocfs.ko.symbols...done.
Loaded symbols for /boot/kernel/linprocfs.ko.symbols
Reading symbols from /boot/kernel/if_lagg.ko.symbols...done.
Loaded symbols for /boot/kernel/if_lagg.ko.symbols
Reading symbols from /boot/kernel/if_bridge.ko.symbols...done.
Loaded symbols for /boot/kernel/if_bridge.ko.symbols
Reading symbols from /boot/kernel/bridgestp.ko.symbols...done.
Loaded symbols for /boot/kernel/bridgestp.ko.symbols
Reading symbols from /boot/kernel/if_tap.ko.symbols...done.
Loaded symbols for /boot/kernel/if_tap.ko.symbols

#0  doadump (textdump=0) at pcpu.h:219
219 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) #0  doadump (textdump=0) at pcpu.h:219
#1  0x803023ae in db_dump (dummy=,
dummy2=0, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:543
#2  0x80301e8d in db_command (cmd_table=)
at /usr/src/sys/ddb/db_command.c:449
#3  0x80301c04 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:502
#4  0x80304570 in db_trap (type=, code=0)
at /usr/src/sys/ddb/db_main.c:231
#5  0x8072e9d3 in kdb_trap (type=12, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:656
#6  0x80a81bb2 in trap_fatal (frame=0xfe011fe61cf0, 
eva=) at /usr/src/sys/amd64/amd64/trap.c:870
#7  0x80a81ec9 in trap_pfault (frame=0xfe011fe61cf0,
usermode=0) at /usr/src/sys/amd64/amd64/trap.c:692
#8  0x80a8165b in trap (frame=0xfe011fe61cf0)
at /usr/src/sys/amd64/amd64/trap.c:456
#9  0x80a68222 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:232
#10 0x817da911 in rt2860_tx (sc=0xfe9bd000, 
m=0xf80004c6dd00, ni=0x0)
at /usr/src/sys/modules/ral/../../dev/ral/rt2860.c:1472
#11 0x817da89e in rt2860_start_locked (ifp=0xf80003bed800)
at /usr/src/sys/modules/ral/../../dev/ral/rt2860.c:1998
#12 0x817d57b0 in rt2860_start (ifp=0xf80003bed800)
at /usr/src/sys/modules/ral/../../dev/ral/rt2860.c:1972
#13 0x807b5f35 in if_transmit (ifp=, 
m=) at /usr/src/sys/net/if.c:3352
#14 0x807fbd96 in ieee80211_vap_pkt_send_dest (
vap=, m=,
ni=0xfe0003bae000) at /usr/src/sys/net80211/ieee80211_output.c:243
#15 0x807fce09 in ieee80211_vap_transmit (ifp=, m=)
out>at /usr/src/sys/net80211/ieee80211_output.c:393
#16 0x8261d91f in lagg_transmit (ifp=0xf80003bec000, 
m=0xf80004c6dd00)
at /usr/src/sys/modules/if_lagg/../../net/if_lagg.c:1314
#17 0x8262b11d in bridge_enqueue (sc=0xf80006597c00, 
dst_ifp=0xf80003bec000, m=)
at /usr/src/sys/modules/if_bridge/../../net/if_bridge.c:1864
#18 0x8262a2e0 in bridge_output (ifp=0xf80003bec000, 
m=, sa=, rt=0x1)
at /usr/src/sys/modules/if_bridge/../../net/if_bridge.c:2009
#19 0x807b8

Re: svn && ports, or the hen && egg

[olli hauer]

On 2013-12-18 22:09, Matthias Apitz wrote:
> El día Wednesday, December 18, 2013 a las 12:59:16PM -0800, Freddie Cash 
> escribió:
> 
>> On Wed, Dec 18, 2013 at 12:50 PM, Matthias Apitz  wrote:
>>
>>> As ports are now for some time are to be pulled out via SVN (and not
>>> CVS) and the svn client is only in the ports tree and not in the base
>>> system, how is this thought to work in a clean way, without dusting the
>>> system before with some binary packages, only based on base system and
>>> sources?
>>>
>>> svnlite is included in the base OS for 10.0.
>>
>> See https://wiki.freebsd.org/WhatsNew/FreeBSD10 for details.  And
>> http://svnweb.freebsd.org/base?view=revision&revision=251886 for the commit
>> message.
> 
> Ok, thanks; but see this:
> 
> $ uname -a
> FreeBSD tiny-r255948 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #1: Fri Oct 18 12:10:57 
> CEST 2013 g...@aurora.sisis.de:/usr/obj/usr/src/sys/GENERIC/i386
> $ svnlite
> Type 'svn help' for usage.
> $ svn help
> svn: not found
> 
> :-)
> 

One of my first commands until svn is is installed
$ alias svn svnlite

-- 
olli
___
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"

panic with deactivated geom mirror (both 9.2 and 10.0-RC2)

[Kurt Lidl]

Greetings all -

I've got a completely reproducible panic when issuing a
'gmirror status' command on a recently deactivated gmirror.

NOTE:  This only happens on a machine with more than 1 CPU.

I filed a bug report on it:

http://www.freebsd.org/cgi/query-pr.cgi?pr=184985

Script to reproduce the panic:
(assumes /dev/ada0p3 is a scratch partition)

while :
do
  gmirror label -v scratch /dev/ada0p3
  newfs /dev/mirror/scratch
  mount /dev/mirror/scratch /mnt
  umount -f /mnt
  gmirror deactivate scratch /dev/ada0p3
  gmirror status scratch
done

I've attached the core.txt.0 file from the crash under 10.0-RC2.
Probably stripped by the mailing list. A copy is at
http://www.pix.net/staff/lidl/freebsd/core.txt.0

-Kurt
b524-fbsd10rc2.pix.net dumped core - see /var/crash/vmcore.0

Wed Dec 18 23:23:12 UTC 2013

FreeBSD b524-fbsd10rc2.pix.net 10.0-RC2 FreeBSD 10.0-RC2 #0 r259404: Sun Dec 15 
08:18:20 UTC 2013 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

panic: page fault

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
GEOM_MIRROR: Device scratch: provider ada0p3 disconnected.
GEOM_MIRROR: Device scratch: provider mirror/scratch destroyed.
GEOM_MIRROR: Device scratch destroyed.


Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address   = 0x378
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x808b78c6
stack pointer   = 0x28:0xfe001ddfea10
frame pointer   = 0x28:0xfe001ddfeab0
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 = 13 (g_event)
trap number = 12
panic: page fault
cpuid = 1
KDB: stack backtrace:
#0 0x808e7d60 at kdb_backtrace+0x60
#1 0x808af845 at panic+0x155
#2 0x80c8e612 at trap_fatal+0x3a2
#3 0x80c8e8e9 at trap_pfault+0x2c9
#4 0x80c8e076 at trap+0x5e6
#5 0x80c75312 at calltrap+0x8
#6 0x808b7442 at _sx_xlock+0x62
#7 0x81a371bf at g_mirror_dumpconf+0x12f
#8 0x8081a35c at g_conf_specific+0x14c
#9 0x8081acd6 at g_run_events+0x166
#10 0x8088191a at fork_exit+0x9a
#11 0x80c7584e at fork_trampoline+0xe
Uptime: 33s
Dumping 78 out of 487 MB:..21%..41%..61%..82%

Reading symbols from /boot/kernel/zfs.ko.symbols...done.
Loaded symbols for /boot/kernel/zfs.ko.symbols
Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
Loaded symbols for /boot/kernel/opensolaris.ko.symbols
Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done.
Loaded symbols for /boot/kernel/geom_mirror.ko.symbols
#0  doadump (textdump=) at pcpu.h:219
219 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) #0  doadump (textdump=) at pcpu.h:219
#1  0x808af4c0 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:447
#2  0x808af884 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:754
#3  0x80c8e612 in trap_fatal (frame=, 
eva=) at /usr/src/sys/amd64/amd64/trap.c:882
#4  0x80c8e8e9 in trap_pfault (frame=0xfe001ddfe960, usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:699
#5  0x80c8e076 in trap (frame=0xfe001ddfe960)
at /usr/src/sys/amd64/amd64/trap.c:463
#6  0x80c75312 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:232
#7  0x808b78c6 in _sx_xlock_hard (sx=0xf80018321240, 
tid=18446735277652013056, opts=, 
file=0x2beff0 , line=0)
at /usr/src/sys/kern/kern_sx.c:556
#8  0x808b7442 in _sx_xlock (sx=0x2beff0, opts=0, 
file=, line=2879472) at sx.h:152
#9  0x81a371bf in g_mirror_dumpconf (sb=0xf80018310540, 
indent=0x80ea9f7d "\t", gp=, 
cp=, pp=)
at 
/usr/src/sys/modules/geom/geom_mirror/../../../geom/mirror/g_mirror.c:3202
#10 0x8081a35c in g_conf_specific (sb=0xf80018310540, mp=0x0, 
gp=0x0, pp=0x0, cp=0x0) at /usr/src/sys/geom/geom_dump.c:238
#11 0x8081acd6 in g_run_events ()
at /usr/src/sys/geom/geom_event.c:257
#12 0x8088191a in fork_exit (
callout=0x8081c8e0 , arg=0x0, 
frame=0xfe001ddfec00) at /usr/src/sys/kern/kern_fork.c:995
#13 0x80c7584e in fork_trampoline ()
at /usr/src/sys/amd64/amd64/exception.S:606
#14 0x in ?? ()
Current language:  auto; currently minimal
(kgdb) 


ps -axl

UID PID PPID CPU PR

Re: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter

[Kevin Lo]

On 2013/12/18 23:48, Alexey Dokuchaev wrote:

On Sun, Oct 06, 2013 at 10:24:09AM -0700, Alfred Perlstein wrote:

I got one of these (if_urtwn) and it works enough to download about a meg
or so before the watchdog kicks in and I have to ifconfig down/up it to
get it to respond again.

I even have a patch pending to add the usb identifier for this.

Same here; someone at $work bought couple of these teeny dongles.  I've
applied small id patch (attached), and tried to use it (it reportedly
works flawlessly under Linux using this [*] driver).  I could load the
module, but MAC address was clearly bogus (00:00:30:34:43:30); yet I've
created wlan0 just to find out that there is no list scan results, and
wpa_supplicant(8) gives me this in an endless loop (GENERIC kernel, so
I presume all wlan-related stuff should be in place):

Successfully initialized wpa_supplicant
ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Device not configured
wlan0: Failed to initiate AP scan

This is on relatively fresh 11-CURRENT as of Oct 18th, i386.  Any clues?
It would be nice to get more of these little guys to work, esp. there is
working Linux driver available for reference.


Your usb wlan dongles use RTL8188EU chip which is currently not
supported by any of drivers.



./danfe

[*] https://github.com/liwei/rpi-rtl8188eu


Kevin
___
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: RFC: less chatty system builds

[Luigi Rizzo]

On Mon, Dec 16, 2013 at 10:35 PM, Dimitry Andric  wrote:

> On 16 Dec 2013, at 19:46, Luigi Rizzo  wrote:
> > The following is a proof-of-concept patch to make system builds
> > less chatty.
> >
> > It also has the nice side effect of showing more clearly
> > which rules are used during the build and possibly help
> > debugging the share/mk files and the individual Makefiles.
> >
> > The logic is the following:
> > the environment/make variable SILENT (or any other name we may want
> > to use; linux defaults to quiet mode and uses V=1 to be as verbose
> > as we are),
>
> I cannot imagine I am the only one that dislikes Linux's approach of not
> showing exactly what it is doing, so I have no objection, as long as it
> is not the default.  (I really hate having to hunt around for the magic
> option to enable verbose output if I want to know how a program is
> compiled...)
>

thanks for the feedback.

Sure, default should remain unchanged per POLA.

As for the 'magic option to enable verbose output', i think
it is just a matter of being familiar with the specific system.

We have far less mnemonic options in FreeBSD (MAKEOBJDIRPREFIX,
KERNFAST) than the V=1 required by linux.



> Also, if you want "silent" builds, you should use make -s instead.  That
> is much less chatty than (IMHO) useless "CC foo", "LD bar" messages.


The issue with verbosity is that depending on the circumstances
you need different levels.

Definitely there must be something moving in all cases
(progress bar or percentage or scrolling text);
then in case of errors you may need to know the exact command line,
perhaps with something more such as what rule was used etc;
and maybe an intermediate output in other cases.

Our default is extremely verbose, even without -v, as
it shows the full command line for almost every command
(the mk files have relatively few @ prefixes).

It is extremely hard to spot warnings in the output.

In fact, it is so verbose that make -v is very similar.
The following is the output of "make toolchain" with and without -v

> ls -l /tmp/build*
-rw-r--r--  1 luigi  wheel  13058140 Dec 19 01:07 /tmp/build-gcc-v.out
-rw-r--r--  1 luigi  wheel  12360113 Dec 19 01:23 /tmp/build-gcc.out
> wc /tmp/build-gcc.out
   24825  478479 12360113 /tmp/build-gcc.out
> wc /tmp/build-gcc-v.out
   57676  576964 13058140 /tmp/build-gcc-v.out

as you can see the difference in size is only 10% (though there
are twice as many lines).


make -s as you suggest is more silent, but in some places it can be
minutes between individual lines. Below is the output with a small
modification to print a timestamp on each ECHODIR line:

...
00:02:18 ===> lib/clang (all)
00:02:18 ===> lib/clang/libclanganalysis (all)
00:02:59 ===> lib/clang/libclangarcmigrate (all)
00:04:54 ===> lib/clang/libclangast (all)
00:07:27 ===> lib/clang/libclangbasic (all)
00:07:40 ===> lib/clang/libclangcodegen (all)
00:10:16 ===> lib/clang/libclangdriver (all)
00:10:30 ===> lib/clang/libclangedit (all)
00:10:34 ===> lib/clang/libclangfrontend (all)
00:11:29 ===> lib/clang/libclangfrontendtool (all)
00:11:30 ===> lib/clang/libclanglex (all)
00:11:55 ===> lib/clang/libclangparse (all)
00:12:33 ===> lib/clang/libclangrewritecore (all)
00:12:36 ===> lib/clang/libclangrewritefrontend (all)
00:13:00 ===> lib/clang/libclangsema (all)
00:16:35 ===> lib/clang/libclangserialization (all)
00:17:19 ===> lib/clang/libclangstaticanalyzercheckers (all)
00:20:51 ===> lib/clang/libclangstaticanalyzercore (all)
00:22:36 ===> lib/clang/libclangstaticanalyzerfrontend (all)
00:22:47 ===> lib/clang/libllvmanalysis (all)
... (and we are not done yet)...

The following patch might be of some help to indicate progress:

Index: /home/luigi/FreeBSD/head/share/mk/sys.mk
===
--- /home/luigi/FreeBSD/head/share/mk/sys.mk(revision 259578)
+++ /home/luigi/FreeBSD/head/share/mk/sys.mk(working copy)
@@ -84,12 +84,12 @@
 CPP?=  cpp

 .if empty(.MAKEFLAGS:M-s)
-ECHO   ?=  echo
-ECHODIR?=  echo
+ECHO   ?=  echo `date +%H:%M:%S `
+ECHODIR?=  echo `date +%H:%M:%S `
 .else
 ECHO   ?=  true
 .if ${.MAKEFLAGS:M-s} == "-s"
-ECHODIR?=  echo
+ECHODIR?=  echo `date +%H:%M:%S `
 .else
 ECHODIR?=  true
 .endif

So coming back to my original proposal, I was suggesting the intermediate
mode to give people a better idea of what is going on during the build,
and make warnings and error messages stand out in the output.

In any case, if anything like this is implemented, I would really prefer
> something like CMake does, e.g. give you a percentage counter that
> provides some information about how 'far' the build is progressing.
>

Sure it would be great to also have that (as another extreme,
even less verbose than -s), but I believe it is impossible to
implement it, because the build system has no idea of

Re: r259072 is not a happy camper...

[Poul-Henning Kamp]

In message <201312181458.20649@freebsd.org>, John Baldwin writes:

>> >Does it get a crashdump if you try?
>> 
>> No :-(
>> 
>> There may be a connection to unclean UFS filesystems (SU + TRIM, no J).
>
>Is this reproducible?

Not really.

It seems to happen at random, usually shortly after boot and as I
mentioned, there is some indications of it being related to munged
filesystems.

Amongst these indications:

Booting single-user and running fsck (without -p) almost always
prevents it from happening until after next crash, and I think all
the backtraces I've see have been UFS or maybe even WITNESS+UFS
related.

If it is WITNESS related, the serial console is obviously a
prime suspect...

But all that said, I havn't seen it for a couple of days...

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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: r259072 is not a happy camper...

[John Baldwin]

On Saturday, December 14, 2013 3:44:39 am Poul-Henning Kamp wrote:
> In message <201312131620.25107@freebsd.org>, John Baldwin writes:
> 
> >> >Hmmm.  Maybe do 'show lapic' and 'show apic' in ddb and paste that here?
> >> 
> >> sorry about the delay...
> >> 
> >> db> show lapic
> >> lapic ID = 2
> >> version  = 1.0
> >> max LVT  = 5
> >> SVR  = ff (enabled)
> >> TPR  = 00
> >> In-service Interrupts:
> >
> >Hmm, this is empty.  It should not be empty. :(
> >
> >Never the less, the panic is further down than I thought it was.  The system 
> >thinks it had a valid IRQ that required an ithread to be scheduled, but when
> >it went to schedule the ithread, there was no thread to schedule:
> 
> >Does it get a crashdump if you try?
> 
> No :-(
> 
> There may be a connection to unclean UFS filesystems (SU + TRIM, no J).

Is this reproducible?  If so, build with KTR enabled and KTR_INTR set in
KTR_COMPILE and KTR_MASK.  That should at least let us see which interrupt
it thinks it is triggering.  'show irqs' from DDB combined with 'show ktr'
would then be useful.

-- 
John Baldwin
___
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: FreeBSD 10 and zfsd

[Outback Dingo]

On Wed, Dec 18, 2013 at 4:40 PM, Alan Somers  wrote:

> On Wed, Dec 18, 2013 at 11:47 AM, Outback Dingo 
> wrote:
> >
> >
> > On Wed, Dec 18, 2013 at 12:39 PM, Mark Felder  wrote:
> >>
> >> On Thu, Oct 10, 2013, at 11:26, Alan Somers wrote:
> >> >
> >> > Due to popular demand, I have located a round toit.  I'm currently
> >> > working on rebasing the zfsd project branch to head, after which I'll
> >> > push SpectraLogic's recent changes.
> >> >
> >>
> >> Just thought I'd ping the list about the situation here... would love to
> >> see this in HEAD soon :)
> >
> >
> >
> > Id love to see an updated patch from the zfsd tree against head itself
> so we
> > could continue using and testing it
>
> Coming up ...
>
>
Sweet..!!!



> >
> >>
> >> ___
> >> 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"
> >
> >
>
___
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 && ports, or the hen && egg

[Freddie Cash]

On Wed, Dec 18, 2013 at 1:09 PM, Matthias Apitz  wrote:

> El día Wednesday, December 18, 2013 a las 12:59:16PM -0800, Freddie Cash
> escribió:
>
> > On Wed, Dec 18, 2013 at 12:50 PM, Matthias Apitz 
> wrote:
> >
> > > As ports are now for some time are to be pulled out via SVN (and not
> > > CVS) and the svn client is only in the ports tree and not in the base
> > > system, how is this thought to work in a clean way, without dusting the
> > > system before with some binary packages, only based on base system and
> > > sources?
> > >
> > > svnlite is included in the base OS for 10.0.
> >
> > See https://wiki.freebsd.org/WhatsNew/FreeBSD10 for details.  And
> > http://svnweb.freebsd.org/base?view=revision&revision=251886 for the
> commit
> > message.
>
> Ok, thanks; but see this:
>
> $ uname -a
> FreeBSD tiny-r255948 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #1: Fri Oct 18
> 12:10:57 CEST 2013 g...@aurora.sisis.de:/usr/obj/usr/src/sys/GENERIC/i386
> $ svnlite
> Type 'svn help' for usage.
> $ svn help
> svn: not found
>

​And ... if you type "svnlite help" what happens?  The name of the command
is svnlite, not svn, so you may have to mentally swap the terms in terminal
messages.  :)​


-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 10 and zfsd

[Alan Somers]

On Wed, Dec 18, 2013 at 11:47 AM, Outback Dingo  wrote:
>
>
> On Wed, Dec 18, 2013 at 12:39 PM, Mark Felder  wrote:
>>
>> On Thu, Oct 10, 2013, at 11:26, Alan Somers wrote:
>> >
>> > Due to popular demand, I have located a round toit.  I'm currently
>> > working on rebasing the zfsd project branch to head, after which I'll
>> > push SpectraLogic's recent changes.
>> >
>>
>> Just thought I'd ping the list about the situation here... would love to
>> see this in HEAD soon :)
>
>
>
> Id love to see an updated patch from the zfsd tree against head itself so we
> could continue using and testing it

Coming up ...

>
>>
>> ___
>> 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"
>
>
___
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 && ports, or the hen && egg

[Matthias Apitz]

El día Wednesday, December 18, 2013 a las 12:59:16PM -0800, Freddie Cash 
escribió:

> On Wed, Dec 18, 2013 at 12:50 PM, Matthias Apitz  wrote:
> 
> > As ports are now for some time are to be pulled out via SVN (and not
> > CVS) and the svn client is only in the ports tree and not in the base
> > system, how is this thought to work in a clean way, without dusting the
> > system before with some binary packages, only based on base system and
> > sources?
> >
> > svnlite is included in the base OS for 10.0.
> 
> See https://wiki.freebsd.org/WhatsNew/FreeBSD10 for details.  And
> http://svnweb.freebsd.org/base?view=revision&revision=251886 for the commit
> message.

Ok, thanks; but see this:

$ uname -a
FreeBSD tiny-r255948 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #1: Fri Oct 18 12:10:57 
CEST 2013 g...@aurora.sisis.de:/usr/obj/usr/src/sys/GENERIC/i386
$ svnlite
Type 'svn help' for usage.
$ svn help
svn: not found

:-)

matthias
-- 
Sent from my FreeBSD netbook

Matthias Apitz, , http://www.unixarea.de/ f: +49-170-4527211
UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370)
UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5
___
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 && ports, or the hen && egg

[Baptiste Daroussin]

On Wed, Dec 18, 2013 at 09:50:27PM +0100, Matthias Apitz wrote:
> 
> Hi,
> 
> As ports are now for some time are to be pulled out via SVN (and not
> CVS) and the svn client is only in the ports tree and not in the base
> system, how is this thought to work in a clean way, without dusting the
> system before with some binary packages, only based on base system and
> sources?
> 
> Thanks
> 
>   matthias
> -- 
> Sent from my FreeBSD netbook
> 
> Matthias Apitz, , http://www.unixarea.de/ f: +49-170-4527211
> UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370)
> UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5
> ___
> 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"

First svn is in base named svnlite since 10, then the recommanded way to get the
ports tree is to use portsnap which is also in base.

regards,
Bapt


pgp0U7nk0bMpB.pgp
Description: PGP signature

Re: svn && ports, or the hen && egg

[Dimitry Andric]

On 18 Dec 2013, at 21:50, Matthias Apitz  wrote:
> 
> As ports are now for some time are to be pulled out via SVN (and not
> CVS) and the svn client is only in the ports tree and not in the base
> system, how is this thought to work in a clean way, without dusting the
> system before with some binary packages, only based on base system and
> sources?

Use portsnap, or if you use 10.x or later, the base system has svnlite.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: svn && ports, or the hen && egg

[Freddie Cash]

On Wed, Dec 18, 2013 at 12:50 PM, Matthias Apitz  wrote:

> As ports are now for some time are to be pulled out via SVN (and not
> CVS) and the svn client is only in the ports tree and not in the base
> system, how is this thought to work in a clean way, without dusting the
> system before with some binary packages, only based on base system and
> sources?
>
> svnlite is included in the base OS for 10.0.

See https://wiki.freebsd.org/WhatsNew/FreeBSD10 for details.  And
http://svnweb.freebsd.org/base?view=revision&revision=251886 for the commit
message.

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: svn && ports, or the hen && egg

[Nathan Whitehorn]

On 12/18/13 14:50, Matthias Apitz wrote:

Hi,

As ports are now for some time are to be pulled out via SVN (and not
CVS) and the svn client is only in the ports tree and not in the base
system, how is this thought to work in a clean way, without dusting the
system before with some binary packages, only based on base system and
sources?

Thanks

matthias


There's svnlite in -CURRENT now.
-Nathan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

svn && ports, or the hen && egg

[Matthias Apitz]

Hi,

As ports are now for some time are to be pulled out via SVN (and not
CVS) and the svn client is only in the ports tree and not in the base
system, how is this thought to work in a clean way, without dusting the
system before with some binary packages, only based on base system and
sources?

Thanks

matthias
-- 
Sent from my FreeBSD netbook

Matthias Apitz, , http://www.unixarea.de/ f: +49-170-4527211
UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370)
UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5
___
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: ZFS Boot patch

[Teske, Devin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


On Dec 18, 2013, at 9:34 AM, Allan Jude wrote:

On 2013-12-18 12:27, Allan Jude wrote:
An issue we thought we had fixed, was not actually fixed.

When doing a GELI based Root-on-ZFS install, the 'bootpool' is not
always properly mounted in the installed system.

The lines added to loader.conf to make it use the zpool.cache file and
learn of the existence of the 2nd pool are required, and have the
desired effect.

However, it seems that the 2nd pool is not always listed in the cache file.

The attached patch should fix this issue.

Hopefully this can get MFCd in time for the next RC


A note for the release notes. If you have an existing install, it can be
'repaired' easily:

zpool import -f bootpool

Yes, I too had noticed this. Figured it was a minor annoyance.



zpool set cachefile=/boot/zfs/zpool.cache bootpool


I'll have to re-test, but I didn't find this to be necessary. After importing
the bootpool and rebooting, I noticed it always came back.

The explanation I told myself was:

1. You boot into the new system
2. You import the bootpool
3. That adds an entry to /boot/zfs/zpool.cache
4. Next time you reboot, that entry is still in there

But what I was trying to figure out was how exactly to get the bootpool
to auto-import into the newline installed system -- I think the above line
you shared shows me precisely how we can accomplish that (I see it
in the patch you submitted).


This will add the bootpool to the existing zpool.cache (which contains
the data for your main pool)

This only applies to users who opted to encrypt their zpool.


Minor nit... not only for geli; now all MBR layouts use a bootpool. I found
this to be required for the edge-case of MBR+NOSWAP (which I fiddled
with for almost a week and got nowhere without using a bootpool).
- -- 
Devin
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJSsgTUAAoJEKrMn5R9npq5SwEH/2iCbpkLaYcKOpn8ibMAxY7k
CUvpP8A5r3LEIxrf6lSIuiF0UpavTBQDZLS0n4mjAsQDQh2nyvXp8URpbjFUoHtS
CKCP8MlaNit5xEnnIx3nCOuU7yelBkTUUqzSGfKFZc0GHO1uhV9OTvuwNvyrNce2
y4/6l5ieUH4deoLTNQDIS4p6BoJr94JIopWLx/A+jF3SOlt34Z/LxeVEvQGeUaZ7
7YeAfg/NxeAGSnmRBNPox+HloGJvrHXzAhZLmXZI0cUUwvue/icmYH/hth9bmNYZ
NGMJckMyAZm600Vi9OoDqJf8y+sHjrYmLAuyXu1hfDb6CBfZD9S49CsTWV40W54=
=rP4m
-END PGP SIGNATURE-

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: new Xorg (KMS, etc.) for Radeon 9600

[Adrian Chadd]

[snip]

So the standard trop of UNLOCK/WORK/RELOCK is pretty dangerous.
There's no state re-validation going on when you re-acquire that lock.
So, although it meets the lock requirements, it may not be 'correct'.

It's scattered throughout the code base (wifi drivers aren't an
exception here either, sigh.)

Just something to keep in mind when you validate the 'correctness' of
this kind of lock hack.


-adrian
___
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: FreeBSD 10 and zfsd

[Outback Dingo]

On Wed, Dec 18, 2013 at 12:39 PM, Mark Felder  wrote:

> On Thu, Oct 10, 2013, at 11:26, Alan Somers wrote:
> >
> > Due to popular demand, I have located a round toit.  I'm currently
> > working on rebasing the zfsd project branch to head, after which I'll
> > push SpectraLogic's recent changes.
> >
>
> Just thought I'd ping the list about the situation here... would love to
> see this in HEAD soon :)
>


Id love to see an updated patch from the zfsd tree against head itself so
we could continue using and testing it


> ___
> 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"
>
___
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: FreeBSD 10 and zfsd

[Mark Felder]

On Thu, Oct 10, 2013, at 11:26, Alan Somers wrote:
> 
> Due to popular demand, I have located a round toit.  I'm currently
> working on rebasing the zfsd project branch to head, after which I'll
> push SpectraLogic's recent changes.
>

Just thought I'd ping the list about the situation here... would love to
see this in HEAD soon :)
___
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: ZFS Boot patch

[Allan Jude]

On 2013-12-18 12:27, Allan Jude wrote:
> An issue we thought we had fixed, was not actually fixed.
>
> When doing a GELI based Root-on-ZFS install, the 'bootpool' is not
> always properly mounted in the installed system.
>
> The lines added to loader.conf to make it use the zpool.cache file and
> learn of the existence of the 2nd pool are required, and have the
> desired effect.
>
> However, it seems that the 2nd pool is not always listed in the cache file.
>
> The attached patch should fix this issue.
>
> Hopefully this can get MFCd in time for the next RC
>
>
A note for the release notes. If you have an existing install, it can be
'repaired' easily:

zpool import -f bootpool
zpool set cachefile=/boot/zfs/zpool.cache bootpool

This will add the bootpool to the existing zpool.cache (which contains
the data for your main pool)

This only applies to users who opted to encrypt their zpool.

-- 
Allan Jude




signature.asc
Description: OpenPGP digital signature

root-on-zfs /var/empty

[Allan Jude]

I've seen a number of comments about the /var/empty dataset

The reason this is not set readonly=on during the installation is that
this causes the installation to fail (when the installer tries to
create/set flags).

This can be set during the post install, or it might be worth
considering Colin Percival's firstboot script as a way to set this after
the fact.


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

makefs enhancement for better rock-ridge support

[Kurt Lidl]

A while ago, it was reported that the ISO images that FreeBSD generates
have a variety of problems (thread starts here):

http://lists.freebsd.org/pipermail/freebsd-stable/2013-April/073050.html

And again for the 10.0 releases:

http://lists.freebsd.org/pipermail/freebsd-stable/2013-December/076284.html

Looking into this, it appears that the various bugs in the Rock Ridge
extensions have been fixed, except for the actual lack of recording
the "serial" numbers in the correct place of the Rock Ridge data.

As it turns out, it is almost trivial to fix this.

Patch is attached to this message, which will probably be stripped
out by the mailing list, but should be available as an attachment
from the mail server.

-Kurt
diff --git a/usr.sbin/makefs/cd9660/iso9660_rrip.c 
b/usr.sbin/makefs/cd9660/iso9660_rrip.c
--- a/usr.sbin/makefs/cd9660/iso9660_rrip.c
+++ b/usr.sbin/makefs/cd9660/iso9660_rrip.c
@@ -629,28 +629,29 @@ cd9660_createSL(cd9660node *node)
}
}
}
 }
 
 int
 cd9660node_rrip_px(struct ISO_SUSP_ATTRIBUTES *v, fsnode *pxinfo)
 {
-   v->attr.rr_entry.PX.h.length[0] = 36;
+   v->attr.rr_entry.PX.h.length[0] = 44;
v->attr.rr_entry.PX.h.version[0] = 1;
cd9660_bothendian_dword(pxinfo->inode->st.st_mode,
v->attr.rr_entry.PX.mode);
cd9660_bothendian_dword(pxinfo->inode->st.st_nlink,
v->attr.rr_entry.PX.links);
cd9660_bothendian_dword(pxinfo->inode->st.st_uid,
v->attr.rr_entry.PX.uid);
cd9660_bothendian_dword(pxinfo->inode->st.st_gid,
v->attr.rr_entry.PX.gid);
+   cd9660_bothendian_dword(pxinfo->inode->st.st_ino,
+   v->attr.rr_entry.PX.serial);
 
-   /* Ignoring the serial number for now */
return 1;
 }
 
 int
 cd9660node_rrip_pn(struct ISO_SUSP_ATTRIBUTES *pn_field, fsnode *fnode)
 {
pn_field->attr.rr_entry.PN.h.length[0] = 20;
pn_field->attr.rr_entry.PN.h.version[0] = 1;
diff --git a/usr.sbin/makefs/cd9660/iso9660_rrip.h 
b/usr.sbin/makefs/cd9660/iso9660_rrip.h
--- a/usr.sbin/makefs/cd9660/iso9660_rrip.h
+++ b/usr.sbin/makefs/cd9660/iso9660_rrip.h
@@ -98,17 +98,17 @@
 #define SL_FLAGS_ROOT  8
 
 typedef struct {
ISO_SUSP_HEADER  h;
u_char mode [ISODCL(5,12)];
u_char links[ISODCL(13,20)];
u_char uid  [ISODCL(21,28)];
u_char gid  [ISODCL(29,36)];
-   u_char serial   [ISODCL(37,44)];/* Not used */
+   u_char serial   [ISODCL(37,44)];
 } ISO_RRIP_PX;
 
 typedef struct {
ISO_SUSP_HEADER  h;
u_char high [ISODCL(5,12)];
u_char low  [ISODCL(13,20)];
 } ISO_RRIP_PN;
 
___
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"

ZFS Boot patch

[Allan Jude]

An issue we thought we had fixed, was not actually fixed.

When doing a GELI based Root-on-ZFS install, the 'bootpool' is not
always properly mounted in the installed system.

The lines added to loader.conf to make it use the zpool.cache file and
learn of the existence of the 2nd pool are required, and have the
desired effect.

However, it seems that the 2nd pool is not always listed in the cache file.

The attached patch should fix this issue.

Hopefully this can get MFCd in time for the next RC


-- 
Allan Jude
Index: usr.sbin/bsdinstall/scripts/zfsboot
===
--- usr.sbin/bsdinstall/scripts/zfsboot (revision 259561)
+++ usr.sbin/bsdinstall/scripts/zfsboot (working copy)
@@ -1156,6 +1156,11 @@
f_eval_catch $funcname zpool "$ZPOOL_SET" \
 "cachefile=\"$BSDINSTALL_CHROOT/boot/zfs/zpool.cache\"" \
 "$zroot_name" || return $FAILURE
+   if [ "$ZFSBOOT_BOOT_POOL" ]; then
+   f_eval_catch $funcname zpool "$ZPOOL_SET" \
+
"cachefile=\"$BSDINSTALL_CHROOT/boot/zfs/zpool.cache\"" \
+"$bootpool_name" || return $FAILURE
+   fi
 
# Last, but not least... required lines for rc.conf(5)/loader.conf(5)
# NOTE: We later concatenate these into their destination


signature.asc
Description: OpenPGP digital signature

Re: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter

[Alexey Dokuchaev]

On Sun, Oct 06, 2013 at 10:24:09AM -0700, Alfred Perlstein wrote:
> I got one of these (if_urtwn) and it works enough to download about a meg
> or so before the watchdog kicks in and I have to ifconfig down/up it to
> get it to respond again.
> 
> I even have a patch pending to add the usb identifier for this.

Same here; someone at $work bought couple of these teeny dongles.  I've
applied small id patch (attached), and tried to use it (it reportedly
works flawlessly under Linux using this [*] driver).  I could load the
module, but MAC address was clearly bogus (00:00:30:34:43:30); yet I've
created wlan0 just to find out that there is no list scan results, and
wpa_supplicant(8) gives me this in an endless loop (GENERIC kernel, so
I presume all wlan-related stuff should be in place):

   Successfully initialized wpa_supplicant
   ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Device not configured
   wlan0: Failed to initiate AP scan

This is on relatively fresh 11-CURRENT as of Oct 18th, i386.  Any clues?
It would be nice to get more of these little guys to work, esp. there is
working Linux driver available for reference.

./danfe

[*] https://github.com/liwei/rpi-rtl8188eu
Index: usbdevs
===
--- usbdevs	(revision 256716)
+++ usbdevs	(working copy)
@@ -3602,6 +3602,7 @@
 product REALTEK RTL8188CU_COMBO	0x8754	RTL8188CU
 product REALTEK RTL8191CU	0x8177	RTL8191CU
 product REALTEK RTL8192CU	0x8178	RTL8192CU
+product REALTEK RTL8188EU	0x8179	RTL8188EU
 product REALTEK RTL8192CE	0x817c	RTL8192CE
 product REALTEK RTL8188RU_1	0x817d	RTL8188RU
 product REALTEK RTL8712		0x8712	RTL8712
Index: wlan/if_urtwn.c
===
--- wlan/if_urtwn.c	(revision 256716)
+++ wlan/if_urtwn.c	(working copy)
@@ -138,6 +138,7 @@
 	URTWN_DEV(REALTEK,	RTL8191CU),
 	URTWN_DEV(REALTEK,	RTL8192CE),
 	URTWN_DEV(REALTEK,	RTL8192CU),
+	URTWN_DEV(REALTEK,	RTL8188EU),
 	URTWN_DEV(SITECOMEU,	RTL8188CU_1),
 	URTWN_DEV(SITECOMEU,	RTL8188CU_2),
 	URTWN_DEV(SITECOMEU,	RTL8192CU),
___
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: 10-RC unable to build kernel without INET (i.e. IPv6-only)

[Mark Martinec]

Gleb,

> On Tue, Dec 17, 2013 at 08:13:20PM +0100, Mark Martinec wrote:
> M> Under 9.2 the following could be used to build an IPv6-only kernel:
> M>   include GENERIC
> M>   makeoptions   MKMODULESENV+="WITHOUT_INET_SUPPORT="
> M>   nooptions   INET
> M> Now with stable/10 ... fails while building xen support:
> 
> Just fixed that in stable/10.
> I expect we will merge the patch to release branch as well.

Perfect, builds and works very well now!
Thank you for a very quick response!

  Mark
___
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: new Xorg (KMS, etc.) for Radeon 9600

[Jean-Sébastien Pédron]

On 18.12.2013 07:41, d...@gmx.com wrote:
> Jean-Sébastien Pédron wrote, On 12/17/2013 22:20:
>> On 16.12.2013 08:36, d...@gmx.com wrote:
>>> Still nobody wants to apply Robert Noland's DRM patch?
>>
>> What problem(s) does this patch fix?
> 
> It fixes non-deterministic lockups when the (old, drm1) r300 drivers are
> used.
> 
> According to John Baldwin [1]: "The drm code is doing a copyin() while
> holding a mutex (which is not allowed)." The latest version of the patch
> (also the one I used for years) is at [2], linked from [3].
> 
> [1]
> http://lists.freebsd.org/pipermail/freebsd-current/2009-April/005988.html
> [2] http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch
> [3]
> http://lists.freebsd.org/pipermail/freebsd-current/2009-April/006080.html

Oh, I didn't notice that the patch targets the old driver, not the new
KMS one. I must admit this part isn't my priority and I'm already busy
with the new driver.

Robert, you worked on this patch a few years ago. Could you please look
at it again and maybe commit?

-- 
Jean-Sébastien Pédron



signature.asc
Description: OpenPGP digital signature

Re: [HEADS UP] enabling LLDB debugger by default on amd64

[David Chisnall]

Hi Ed,

How are you planning on building the LLVM / Clang libraries?  Will they be 
statically linked to the compiler and the debugger, or do you intend to make 
them dynamic too?  I found about a small slowdown with a dynamic clang, but the 
link times were much lower when building.  

Currently, the LLVM build is one of the big serialisation points in our build 
system (we build each of the individual libraries entirely independently), so 
if you're hacking on the build system it would perhaps be nice to build a 
single libLLVM (in /lib/private) that could compile all of the LLVM sources in 
parallel and then be used by Clang and LLDB (and any LLVM-based binutils 
replacements we start to add).  This would likely more than offset the 
increased build time for LLDB on any multicore system.

David

On 17 Dec 2013, at 22:15, Ed Maste  wrote:

> The in-tree snapshot of LLDB is at a point where it's usable and
> suitable for wider testing on amd64, and so I intend to enable it by
> default in the near future.
> 
> Further information on the FreeBSD port of LLDB is on the wiki, at
> https://wiki.freebsd.org/lldb
> 
> On my desktop LLDB added about 5 minutes to a buildworld and 80MB to
> objdir (over a baseline of about an hour and 1.8GB).  If you wish to
> avoid building it, you can add 'WITHOUT_LLDB=' to src.conf.
> 
> -Ed
> ___
> 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"

___
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: [HEADS UP] xorg version switch in CURRENT

[Koop Mast]

On 18-12-2013 5:22, J M wrote:

Following this list:
http://lists.freebsd.org/pipermail/freebsd-x11/2013-December/013911.html

Rebuild xorg again on FreeBSD 10.0 rc2:
WITH_NEW_XORG=
WITH_KMS=
WITH_GALLIUM=

Build es2tri.c in mesa demos
http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengles2/es2tri.c
#
J@build:~ % clang es2tri.c -o es2tri `pkgconf --cflags --libs x11 egl
glesv2 gl`
J@build:~ % ./es2tri
#
A window with a triangle is shown.

It is on an Intel video card.

But when I built nvidia driver and found this error again.
#
root@build:~ # cd /usr/ports/x11/nvidia-driver-304
root@build:/usr/ports/x11/nvidia-driver-304 # make install clean

J@build:~ % clang es2tri.c -o es2tri `pkgconf --cflags --libs x11 egl
glesv2 gl`
/usr/local/lib/libGLESv2.so: undefined reference to `_glapi_get_dispatch'
/usr/local/lib/libGLESv2.so: undefined reference to `_glapi_Dispatch'
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
J@build:~ % clang es2tri.c -o es2tri `pkgconf --cflags --libs x11 egl
glesv2`
/usr/local/lib/libGLESv2.so: undefined reference to `_glapi_get_dispatch'
/usr/local/lib/libGLESv2.so: undefined reference to `_glapi_Dispatch'
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
J@build:~ % clang es2tri.c -o es2tri `pkgconf --cflags --libs x11 egl gl`
J@build:~ % ./es2tri
Bus error (core dumped)
#

I think it is because a mismatch configure, and also because gles driver is
incomplete.


I will take a look at making the libglesv2 port to work. I think I 
already know what I need to do to make this work. Thank you for testing 
the libEGL and libglesv2 ports.


-Koop

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com

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

Re: General Protection Fault in prelist_remove()

[Hans Petter Selasky]

On 09/16/13 19:33, Hans Petter Selasky wrote:

Hi Mark,

-Original message-

From:Mark Johnston mailto:ma...@freebsd.org> >
Sent: Monday 16th September 2013 19:09
To: Hans Petter Selasky mailto:hans.petter.sela...@bitfrost.no> >
Cc: freebsd-current@freebsd.org 
Subject: Re: General Protection Fault in prelist_remove()

On Mon, Sep 16, 2013 at 05:27:30PM +0200, Hans Petter Selasky wrote:

Hi,

I caught a General protection fault in prelist_remove. Any clues what
this might be?


Any chance you were creating or destroying interfaces around the time
this crash happened?


Yes, I have some tunneling software running, which create and destroy tunX 
nodes regularly.


Hi Mark,

I've now been running your patch for some months, and the quite regular 
GPF panics have disappeared. Any chance how to go forward to get a fix 
upstream?


--HPS

___
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 Wireless-N 1000 can't connect to AP

[乔楚]

Will I need to tie debug?

Not wifi, laptop use is indeed very painful


2013/12/11 Adrian Chadd 

> OK, I'll see if my centrino 1xx / 1xxx units match yours and are
> problematic.
>
> Please file a PR!
>
>
> -a
>
> On 7 December 2013 05:34, 乔楚  wrote:
> > Today ,I upgrade my freebsd from 10-beta4 to current.
> > Now, my freebsd can't connect to wireless AP. Wireless LAN strike.
> >
> > iwn0 in /var/log/message:
> > Dec  7 08:02:00 x201i kernel: iwn0:  mem
> > 0xf240-0xf2401fff irq 16 at device 0.0 on pci2
> >
> > Dec  7 08:02:00 x201i kernel: iwn0: attempting to allocate 1 MSI vectors
> (1
> > supported)
> > Dec  7 08:02:00 x201i kernel: msi: routing MSI IRQ 266 to local APIC 0
> > vector 62
> > Dec  7 08:02:00 x201i kernel: iwn0: using IRQ 266 for MSI
> > Dec  7 08:02:00 x201i kernel: iwn0: MIMO 1T2R, BGS, address
> > 8c:a9:82:5a:41:58
> > Dec  7 08:02:00 x201i kernel: iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
> > Dec  7 08:02:00 x201i kernel: iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
> > 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
> > Dec  7 08:02:00 x201i kernel: iwn0: 1T2R
> > Dec  7 08:02:00 x201i kernel: iwn0: 11ng MCS 20MHz
> > Dec  7 08:02:00 x201i kernel: iwn0: MCS 0-7: 6.5Mbps - 65Mbps
> > Dec  7 08:02:00 x201i kernel: iwn0: 11ng MCS 20MHz SGI
> > Dec  7 08:02:00 x201i kernel: iwn0: MCS 0-7: 7Mbps - 72Mbps
> > Dec  7 08:02:00 x201i kernel: iwn0: 11ng MCS 40MHz:
> > Dec  7 08:02:00 x201i kernel: iwn0: MCS 0-7: 13.5Mbps - 135Mbps
> > Dec  7 08:02:00 x201i kernel: iwn0: 11ng MCS 40MHz SGI:
> > Dec  7 08:02:00 x201i kernel: iwn0: MCS 0-7: 15Mbps - 150Mbps
> > ..
> > Dec  7 08:02:00 x201i kernel: wlan0: Ethernet address: f0:de:f1:52:cf:16
> > Dec  7 08:02:00 x201i kernel: iwn0: iwn_intr: fatal firmware error
> > Dec  7 08:02:00 x201i kernel: firmware error log:
> > Dec  7 08:02:00 x201i kernel: error type  = "SYSASSERT" (0x0005)
> > Dec  7 08:02:00 x201i kernel: program counter = 0x00018DBC
> > Dec  7 08:02:00 x201i kernel: source line = 0x0032
> > Dec  7 08:02:00 x201i kernel: error data  = 0x0001
> > Dec  7 08:02:00 x201i kernel: branch link = 0x00018D6E00018D6E
> > Dec  7 08:02:00 x201i kernel: interrupt link  = 0x0826
> > Dec  7 08:02:00 x201i kernel: time= 1538064582
> > Dec  7 08:02:00 x201i kernel: driver status:
> > Dec  7 08:02:00 x201i kernel: tx ring  0: qid=0  cur=0   queued=0--
> > Dec  7 08:02:00 x201i kernel: tx ring  1: qid=1  cur=0   queued=0--
> > Dec  7 08:02:00 x201i kernel: tx ring  2: qid=2  cur=0   queued=0--
> > Dec  7 08:02:00 x201i kernel: tx ring  3: qid=3  cur=2   queued=0--
> > Dec  7 08:02:00 x201i kernel: tx ring  4: qid=4  cur=57  queued=0--
> > Dec  7 08:02:00 x201i kernel: tx ring  5: qid=5  cur=0   queued=0--
> > Dec  7 08:02:00 x201i kernel: tx ring  6: qid=6  cur=0   queued=0--
> > Dec  7 08:02:00 x201i kernel: tx ring  7: qid=7  cur=0   queued=0--
> > Dec  7 08:02:00 x201i kernel: tx ring  8: qid=8  cur=0   queued=0--
> > Dec  7 08:02:00 x201i kernel: tx ring  9: qid=9  cur=0   queued=0--
> > Dec  7 08:02:00 x201i kernel: tx ring 10: qid=10 cur=0   queued=0--
> > Dec  7 08:02:00 x201i kernel: tx ring 11: qid=11 cur=0   queued=0--
> > Dec  7 08:02:00 x201i kernel: tx ring 12: qid=12 cur=0   queued=0--
> > Dec  7 08:02:00 x201i kernel: tx ring 13: qid=13 cur=0   queued=0--
> > Dec  7 08:02:00 x201i kernel: tx ring 14: qid=14 cur=0   queued=0--
> > Dec  7 08:02:00 x201i kernel: tx ring 15: qid=15 cur=0   queued=0--
> > Dec  7 08:02:00 x201i kernel: tx ring 16: qid=16 cur=0   queued=0--
> > Dec  7 08:02:00 x201i kernel: tx ring 17: qid=17 cur=0   queued=0--
> > Dec  7 08:02:00 x201i kernel: tx ring 18: qid=18 cur=0   queued=0--
> > Dec  7 08:02:00 x201i kernel: tx ring 19: qid=19 cur=0   queued=0--
> > Dec  7 08:02:00 x201i kernel: rx ring: cur=29
> > ..
> > Dec  7 08:02:01 x201i wpa_supplicant[667]: ioctl[SIOCS80211, op=103,
> val=0,
> > arg_len=128]: Device not configured
> > Dec  7 08:02:01 x201i wpa_supplicant[667]: wlan0: Failed to initiate AP
> scan
> >
> > I do not know where the problem is?
> > If necessary, I can tie debugging.
> > ___
> > 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"
>
___
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"