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 adr...@freebsd.org 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, 乔楚 honestq...@gmail.com 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: Intel Centrino Wireless-N 1000 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
Re: General Protection Fault in prelist_remove()
On 09/16/13 19:33, Hans Petter Selasky wrote: Hi Mark, -Original message- From:Mark Johnston ma...@freebsd.org mailto:ma...@freebsd.org Sent: Monday 16th September 2013 19:09 To: Hans Petter Selasky hans.petter.sela...@bitfrost.no mailto:hans.petter.sela...@bitfrost.no Cc: freebsd-current@freebsd.org mailto: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: [HEADS UP] xorg version switch in CURRENT
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: [HEADS UP] enabling LLDB debugger by default on amd64
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 ema...@freebsd.org 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: new Xorg (KMS, etc.) for Radeon 9600
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: 10-RC unable to build kernel without INET (i.e. IPv6-only)
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: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter
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
ZFS Boot patch
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
makefs enhancement for better rock-ridge support
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
root-on-zfs /var/empty
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
Re: ZFS Boot patch
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
Re: FreeBSD 10 and zfsd
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: FreeBSD 10 and zfsd
On Wed, Dec 18, 2013 at 12:39 PM, Mark Felder f...@freebsd.org 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: new Xorg (KMS, etc.) for Radeon 9600
[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: ZFS Boot patch
-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
svn ports, or the hen egg
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, g...@unixarea.de, 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
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
Re: svn ports, or the hen egg
On Wed, Dec 18, 2013 at 12:50 PM, Matthias Apitz g...@unixarea.de 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=revisionrevision=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
On 18 Dec 2013, at 21:50, Matthias Apitz g...@unixarea.de 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
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, g...@unixarea.de, 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
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 g...@unixarea.de 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=revisionrevision=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, g...@unixarea.de, 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: FreeBSD 10 and zfsd
On Wed, Dec 18, 2013 at 11:47 AM, Outback Dingo outbackdi...@gmail.com wrote: On Wed, Dec 18, 2013 at 12:39 PM, Mark Felder f...@freebsd.org 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
On Wed, Dec 18, 2013 at 1:09 PM, Matthias Apitz g...@unixarea.de 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 g...@unixarea.de 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=revisionrevision=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
On Wed, Dec 18, 2013 at 4:40 PM, Alan Somers asom...@freebsd.org wrote: On Wed, Dec 18, 2013 at 11:47 AM, Outback Dingo outbackdi...@gmail.com wrote: On Wed, Dec 18, 2013 at 12:39 PM, Mark Felder f...@freebsd.org 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: r259072 is not a happy camper...
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: r259072 is not a happy camper...
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: RFC: less chatty system builds
On Mon, Dec 16, 2013 at 10:35 PM, Dimitry Andric d...@freebsd.org wrote:
On 16 Dec 2013, at 19:46, Luigi Rizzo ri...@iet.unipi.it 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 how big
is the dependency tree
Re: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter
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
panic with deactivated geom mirror (both 9.2 and 10.0-RC2)
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=value optimized out) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=value optimized out) 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=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0x80c8e612 in trap_fatal (frame=value optimized out, eva=value optimized out) 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=value optimized out, file=0x2beff0 Address 0x2beff0 out of bounds, line=0) at /usr/src/sys/kern/kern_sx.c:556 #8 0x808b7442 in _sx_xlock (sx=0x2beff0, opts=0, file=value optimized out, line=2879472) at sx.h:152 #9 0x81a371bf in g_mirror_dumpconf (sb=0xf80018310540, indent=0x80ea9f7d \t, gp=value optimized out, cp=value optimized out, pp=value optimized out) 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 g_event_procbody, arg=0x0, frame=0xfe001ddfec00) at /usr/src/sys/kern/kern_fork.c:995 #13 0x80c7584e in fork_trampoline ()
Re: svn ports, or the hen egg
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 g...@unixarea.de 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=revisionrevision=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
ral(4) panic. head, r257837
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=value optimized out, dummy2=0, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:543 #2 0x80301e8d in db_command (cmd_table=value optimized out) 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=value optimized out, code=0) at /usr/src/sys/ddb/db_main.c:231 #5 0x8072e9d3 in kdb_trap (type=12, code=0, tf=value optimized out) at /usr/src/sys/kern/subr_kdb.c:656 #6 0x80a81bb2 in trap_fatal (frame=0xfe011fe61cf0, eva=value optimized out) 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=value optimized out, m=value optimized out) at /usr/src/sys/net/if.c:3352 #14 0x807fbd96 in ieee80211_vap_pkt_send_dest ( vap=value optimized out, m=value optimized out, ni=0xfe0003bae000) at /usr/src/sys/net80211/ieee80211_output.c:243 #15 0x807fce09 in ieee80211_vap_transmit (ifp=value optimized out, m=value optimized out) outat /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=value optimized out) at
Re: ral(4) panic. head, r257837
What's at frame 10? And list the IP, ie: list *0x817da911 -a On 18 December 2013 23:04, Sergey V. Dyatko sergey.dya...@gmail.com 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=value optimized out, dummy2=0, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:543 #2 0x80301e8d in db_command (cmd_table=value optimized out) 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=value optimized out, code=0) at /usr/src/sys/ddb/db_main.c:231 #5 0x8072e9d3 in kdb_trap (type=12, code=0, tf=value optimized out) at /usr/src/sys/kern/subr_kdb.c:656 #6 0x80a81bb2 in trap_fatal (frame=0xfe011fe61cf0, eva=value optimized out) 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=value optimized out, m=value optimized out) at /usr/src/sys/net/if.c:3352 #14 0x807fbd96 in ieee80211_vap_pkt_send_dest ( vap=value optimized out, m=value optimized out, ni=0xfe0003bae000) at /usr/src/sys/net80211/ieee80211_output.c:243 #15 0x807fce09 in ieee80211_vap_transmit (ifp=value optimized out, m=value optimized out) outat /usr/src/sys/net80211/ieee80211_output.c:393 #16 0x8261d91f in lagg_transmit
Re: makefs enhancement for better rock-ridge support
Would you mind filing a PR? -a On 18 December 2013 09:27, Kurt Lidl l...@pix.net 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
