Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr)
On Thu, 13 Dec 2012 02:08:50 +0900 Daisuke Aoyama aoy...@peach.ne.jp wrote: Hi, I've created FreeBSD clang world for RPI based on svn 244112 + eabi.diff(NOT USE) + few NetBSD code. I didn't test with -mfloat-abi=softfp but it might work. If you haven't seen there is the start of FreeBSD ARM support in clang: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20121210/069693.html I'm testing this with the version of clang we have in head and hope to bring in support for clang and ARM soon. Andrew ___ 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: auditdistd config file location
On Tue, Dec 04, 2012 at 04:38:13PM +0100, Johan Hendriks wrote: Hello all. I had some spare time so i thought it was a good moment to look at auditdistd . One thing i noticed was the default config file location. The man page and the wiki tells me it is /etc/security/auditdistd I enabled audistd by placing the following in the rc.conf file auditdistd_enable=YES However if i want to start the deamon, it tells me the config file is not present. And that is correct, because my config is in /etc/security/ and not /etc/ [root@smb-filer01 ~]# /etc/rc.d/auditdistd start /etc/rc.d/auditdistd: WARNING: /etc/auditdistd.conf is not readable. /etc/rc.d/auditdistd: WARNING: failed precmd routine for auditdistd [root@smb-filer01 ~]# I think the default location of the config file needs to be modified to match that of the wiki page and the man page. The one in the man page is correct (/etc/security/auditdistd.conf). This was last minute change, which I just fixed (r244181). Thank you for the report! If you have any other questions, don't hesitate to ask. Feel free to CC me when sending a question to the mailing list. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgp59eN4q5ojB.pgp Description: PGP signature
Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr)
I've created FreeBSD clang world for RPI based on svn 244112 + eabi.diff(NOT USE) + few NetBSD code. I didn't test with -mfloat-abi=softfp but it might work. If you haven't seen there is the start of FreeBSD ARM support in clang: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20121210/069693.html I'm testing this with the version of clang we have in head and hope to bring in support for clang and ARM soon. I didn't see this, but it's not enough. I already adjusted clang for your EABI patch, so the patched version of clang can be compiled for both OABI(apcs-gnu) and EABI(aapcs). Note that some world code is still broken for EABI w/clang. -- Daisuke Aoyama ___ 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: clang compiled kernel panic when mounting zfs root on i386
on 12/12/2012 21:35 Dimitry Andric said the following: Especially the recursive spa_load and traverse_visitbp calls are scary, because that can grow out of hand very quickly. It is probably tricky to remove the recursion... Re-entering spa_load once is normal and is expected. traverse_visitbp is also expected to recurse depending on data layout. So yeah, it's probably even trickier than teaching clang to allocate smaller stack frames ;-) -- Andriy Gapon ___ 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: Reproduceable hang
2012/12/13 Alexander Yerenkow yeren...@gmail.com Hello there. I have here 100% reproduceable hangs when run one custom java program. Can someone look into? I can give some more info (some other trace) if required. If someone didn't get attachment - here's link to screenshot https://www.box.com/s/fir8ntjc4rjq5xv0vbyl -- Regards, Alexander Yerenkow ___ 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: Reproduceable hang
on 13/12/2012 12:46 Alexander Yerenkow said the following: 2012/12/13 Alexander Yerenkow yeren...@gmail.com Hello there. I have here 100% reproduceable hangs when run one custom java program. Can someone look into? I can give some more info (some other trace) if required. If someone didn't get attachment - here's link to screenshot https://www.box.com/s/fir8ntjc4rjq5xv0vbyl Looks like either a bug or an out-of-sync issue in whatever (virtualization?) driver that has function OS_ReservedPageAlloc. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADSUP] zfs root pool mounting
on 07/12/2012 02:33 Garrett Cooper said the following: On Thu, Dec 6, 2012 at 3:08 PM, Garrett Cooper yaneg...@gmail.com wrote: ... Please document the process to make this work in UPDATING (or at least the fact that this behavior was changed). I'm debugging moving from 9.1-RC2 to CURRENT [as of Tuesday] as it hasn't been as smooth as some of the other upgrades I've done; my zpool -- root -- is setup with a non-legacy mountpoint, I noticed that the cachefile attribute is now None, etc. I have limited capability with my installed system to debug this because unfortunately there aren't a ton of CURRENT based livecds around to run from (I might look into one of gjb's livecds later on if I get super stuck, but I'm trying to avoid having to do that). gptzfsboot sees the pool with lsdev, but it gets stuck at the mountroot prompt trying to find the filesystem. I'll wipe my /boot/kernel directory and try building/installing the kernel again, but right now I'm kind of dead in the water on the system I'm upgrading :/. One thing that I recommend to all ZFS users is to make use of boot environments. They are very easy, very convenient and may save a lot of trouble. Use either any of the tool available in ports (e.g. sysutils/beadm) or just do boot environments in an ad hoc fashion: snapshot and clone your current / known good boot+root filesystem and you have a safe environment to fall back to. I thought r236884 requiring a zpool upgrade was the culprit, but it wasn't. Still stuck at a mountroot prompt (but now I have gjb's liveCD so I can do something about it). Something looks off with zdb -l on CURRENT and STABLE/9. Example on my 9-stable box: # uname -a FreeBSD forza.west.isilon.com 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0 r+2fd0a57: Mon Dec 3 12:02:18 PST 2012 gcoo...@forza.west.isilon.com:/usr/obj/usr/src/sys/FORZA amd64 # zdb -l sac2 cannot open 'sac2': No such file or directory # zpool list NAME SIZE ALLOC FREECAP DEDUP HEALTH ALTROOT sac 95G 69.7G 25.3G73% 1.00x ONLINE - sac2 232G 117G 115G50% 1.00x ONLINE - Proper zdb -l usage was described in the HEADSUP posting. It's also available in zdb(8). zdb -l should be used with disks/partitions/etc, not with pool names. I'm running into the same behavior before and after I upgraded sac/sac2. My git branch is a lightly modified version of FreeBSD, but doesn't contain any ZFS specific changes (I can point you to it if you like to look at it). Would appreciate some pointers on what to do next. Try to get a working environment (using livecd, another disk, backups, etc), try to follow the original instructions. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADSUP] zfs root pool mounting
on 07/12/2012 02:55 Garrett Cooper said the following: If I try and let it import the pool at boot it claims the pool is in a FAULTED state when I point mountroot to /dev/cd0 (one of gjb's snapshot CDs -- thanks!), run service hostid onestart, etc. If I export and try to reimport the pool it claims it's not available (!). However, if I boot, run service hostid onestart, _then_ import the pool, then the pool is imported properly. This sounds messy, not sure if it has any informative value. I think I've seen something like this after some reason ZFS import from upsteam when my kernel and userland were out of sync. Do you do a full boot from the livecd? Or do you boot your kernel but then mount userland from the cd? In any case, not sure if this is relevan to your main trouble. While I was mucking around with the pool trying to get the system to boot I set the cachefile attribute to /boot/zfs/zpool.cache before upgrading. In order to diagnose whether or not that was at fault, I set that back to none and I'm still running into the same issue. I'm going to try backing out your commit and rebuild my kernel in order to determine whether or not that's at fault. One other thing: both my machines have more than one ZFS-only zpool, and it might be probing the pools in the wrong order; one of the pools has bootfs set, the other doesn't, and the behavior is sort of resembling it not being set properly. bootfs property should not better. Multi-pool configurations has been tested before the commit. -- Andriy Gapon ___ 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: clang compiled kernel panic when mounting zfs root on i386
12.12.2012 21:35, Dimitry Andric: On 2012-12-12 14:04, Volodymyr Kostyrko wrote: 04.12.2012 00:41, Konstantin Belousov: Please try the patch below. It might give an immediate relief, but still there are many offenders in the backtrace. I'm having almost the same issue and the patch doesn't work for me. ... Looking at the stack frame addresses, it seems some of them are mangled. Did you type this by hand? The differences between subsequent frames are a bit strange because of it (and because of awk's integer processing): Yes, I had typed that by hand. I attached link to the pictures just in case. The kernel stack is just 8,192 bytes; since you can see these routines are all consuming massive amounts of stack, and the calls are very deeply nested, it is almost inevitable that it would crash. Especially the recursive spa_load and traverse_visitbp calls are scary, because that can grow out of hand very quickly. It is probably tricky to remove the recursion... After playing more with this kernel I also found it can crash not only by this scenario. There are different possible ways. I actually don't think there's a point fixing it right now. New clang is coming anyway... -- Sphinx of black quartz, judge my vow. ___ 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: r244036 kernel hangs under load.
Konstantin Belousov wrote: On Wed, Dec 12, 2012 at 10:01:39PM -0500, Rick Macklem wrote: Konstantin Belousov wrote: On Tue, Dec 11, 2012 at 08:58:47PM -0500, Rick Macklem wrote: Ok, I'll test r243598 and then r243599 and r243835, just to see if it really is this. I'll email when I have done this. If you test only r243598, I am sure that you would experience corruption. The r243599 should cause the deadlocks. I think you meant r243599 will result in corruptions and r243835 deadlocks. I have run r243598 for a while without a hang. (r243599 doesn't build) I haven't tried r243835 yet. Also, do you use the post-r244095 kernel ? Before and after. The most recent tests were post-r244095. (If anything the more recent kernels hang more easily.) Is your machine SMP ? Old, slow single core i386. Try this. Please note that this is mostly a debugging facility. It seemed to help, but didn't stop the hangs completely. r244125 without the patch would hang somewhere in a kernel build. r244125 plus this patch ran almost 2 kernel builds before it got hung. Can you try to look into the system state on the hang (on the kernel with the if (1 || patch applied) ? Using the ddb and recipe from the web page. Basically watch for a thread looping in the mnt_active iterator and threads owning vnode interlocks. Ok, there is only one process in the mnt_active iterator and its trace is as follows (syncer): dle+0x12d/frame 0xdfe33adc (I suspect the screen lost an 'I') intr_execute_handlers(c5e3d064,dfe33b20,0,dfe33b64,c0ec2115,...) at intr_execute_handlers+0x49/frame 0xdfe33afc lapic_handle_intr(3c,dfe33b20) at lapic_handle_intr+0x36/frame 0xdfe33b10 Xapic_isr1() at Xapic_isr1+0x35/frame 0xdfe33b10 --- interrupt, eip = 0xc0eca8db, esp = 0xdfe33b60, ebp = 0xdfe33b64 --- spinlock_exit(c128be90,4,c10b5017,130,1710,...) at spinlock_exit+0x2b/frame 0xdfe33b64 __mtx_unlock_spin_flags(c128be90,0,c10b80be,25d,0,...) at __mtx_unlock_spin_flags+0x112/frame 0xdfe33b90 kern_yield(,0,c10c75c9,127b,c8b05238,...) at kern_yield+0x125/frame 0xdfe33bbc __mnt_vnode_next_active(dfe33c08,c857ba80,c10c75c9,dac,5d7,...) at __mnt_vnode_next_active+0xda/frame 0xdfe33be0 vfs_msync(c857ba80,2,2,e6b,c857ba80,...) at vfs_msync+0x175/frame 0xdfe33c18 sync_fsync(dfe33ca8,c85cf470,80400,c10c75c9,6f4,...) at sync_fsync+0x141/frame 0xdfe33c64 VOP_FSYNC_APV(c12008a0,dfe33ca8,c10c75c9,6f4,4e20,...) at VOP_FSYNC_APV+0xb4/frame 0xdfe33c64 sched_sync(0,dfe33d08,c10b0e10,3db,c85395a0,...) at sched_sync+0x399/frame 0xdfe33cc8 fork_exit(c0b79420,0,dfe33d08) at fork_exit+0xc0/frame 0xdfe33cf4 fork_trampoline() at fork_trampoline+0x8/frame 0xdfe33cf4 --- trap 0, eip = 0, esp = 0xdfe33d40, ebp = 0 --- This process holds: exclusive lockmgr syncer (syncer) r = 0 (0xc85cf4c8) locked @ kern/vfs_subr.c:1780 The only other process that is doing anything in the VFS subsystem holds the vnode interlock. It's trace is: dle+0x12d/frame 0xdfe6a850 intr_execute_handlers(c5f721c0,dfe6a894,0,dfe6a908,c0ec2115,...) at intr_execute_handlers+0x49/frame 0xdfe6a870 lapic_handle_intr(31,dfe6a894) at lapic_handle_intr+0x36/frame 0xdfe6a884 Xapic_isr1() at Xapic_isr1+0x35/frame 0xdfe6a884 --- interrupt, eip = 0xc0b2206a, esp = 0xdfe6a8d4, ebp = 0xdfe6a908 --- witness_unlock(c8972a74,8,c10c75c9,965,0,...) at witness_unlock+0x3a/frame 0xdfe6a908 __mtx_unlock_flags(c8972a84,0,c10c75c9,965,c89729fc,...) at __mtx_unlock_flags+0x9f/frame 0xdfe6a938 vdropl(c89729fc,dfe6a974,c10c75c9,8e7,c1238020,...) at vdropl+0x63/frame 0xdfe6a95c vputx(dfe6aa04,c0b67acc,c89729fc,dfe6a9e4,dfe6abc4,...) at vputx+0x300/frame 0xdfe6a994 vput(c89729fc,dfe6a9e4,dfe6abc4,31d,dfe6a9e4,...) at vput+0x10/frame 0xdfe6a99c lookup(dfe6ab84,c857e000,0,ce,c13c83c8,...) at lookup+0x9bc/frame 0xdfe6aa04 namei(dfe6ab84,0,0,246,0,...) at namei+0x4fe/frame 0xdfe6aa80 vn_open_cred(dfe6ab84,dfe6ac24,1a4,0,c5dd4580,...) at vn_open_cred+0x2c0/frame 0xdfe6ab40 vn_open(dfe6ab84,dfe6ac24,1a4,c85922a0,c853a2d0,...) at vn_open+0x3b/frame 0xdfe6ab60 kern_openat(c85c55e0,ff9c,2882dcc0,0,8001,...) at kern_openat+0x1e2/frame 0xdfe6ac0c kern_open(c85c55e0,2882dcc0,0,8000,1b6,...) at kern_open+0x35/frame 0xdfe6ac2c sys_open(c85c55e0,dfe6accc,c02acde7,7307f55d,5e5b00,...) at sys_open+0x30/frame 0xdfe6ac48 syscall(dfe6ad08) at syscall+0x2e5/frame 0xdfe6acfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xdfe6acfc --- syscall (5, FreeBSD ELF32, sys_open), eip = 0x84a1667, esp = 0xbfbfcffc, ebp = 0xbfbfd018 --- The locks this process holds are: exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0x8972a74) locked @ kern/vfs_subr.c:2513 shared lockmgr ufs (ufs) r = 0 (0xc8bd181c) locked @ kern/vfs_subr.c:2161
Re: /usr/src/sys/conf/newvers.sh, SYSDIR set to wrong directory.
On Wed, 2012-12-12 at 20:52 +0200, Kimmo Paasiala wrote:
On Wed, Dec 12, 2012 at 6:53 PM, Ian Lepore
free...@damnhippie.dyndns.org wrote:
On Wed, 2012-12-12 at 18:14 +0200, Kimmo Paasiala wrote:
Hello,
My 9-STABLE buildworld broke in a very inexplicable way, I was
getting an error on /usr/src/include/osreldate.h that I couldn't
figure out until I started looking at the sys/conf/newvers.sh and what
it does. It turned out that the thing that broke my buildworld was
having .git directory at the root directory of the system because I
recently started using GIT to track the configuration files.
I added some debug echos to the newvers.sh and I found out it's
setting SYSDIR to /bin/.. which in turn causes the newvers.sh to set
the gitdir to /.git and that seems to break the logic in newvers.sh.
Isn't SYSDIR supposed to be set to the sys -subdirectory of the source
tree (/usr/src/sys default)?
I'm guessing the reason the SYSDIR gets set to /bin/.. is the line in
newvers.sh:
SYSDIR=$(dirname $0)/..
$0 is actually /bin/sh and not the path to newver.sh because the
newvers.sh is sourced by the Makefile in /usr/src/include instead of
executing it:
osreldate.h: ${.CURDIR}/../sys/conf/newvers.sh
${.CURDIR}/../sys/sys/param.h \
${.CURDIR}/Makefile
@${ECHO} creating osreldate.h from newvers.sh
@MAKE=${MAKE}; \
PARAMFILE=${.CURDIR}/../sys/sys/param.h; \
. ${.CURDIR}/../sys/conf/newvers.sh; \
Now the question is how to fix this?
-Kimmo
Perhaps it could be handled similar to PARAMFILE, something like this in
the makefile:
PARAMFILE=${.CURDIR}/../sys/sys/param.h; \
SYSDIR=${.CURDIR}/../sys; \
. ${.CURDIR}/../sys/conf/newvers.sh; \
I'm not sure if newvers.sh needs to work in ways that don't involve
being invoked from that makefile rule, so to be safe it could have
default handling, something like:
: ${SYSDIR:=$(dirname $0)/..}
-- Ian
Thanks, that works. Should I file a PR about this?
-Kimmo
I think that would probably be a good idea, since no committer has
chimed in on this thread saying they're about to commit a fix.
-- Ian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd))
On Sun, Dec 02, 2012 at 03:43:22PM +, Robert N. M. Watson wrote: On 2 Dec 2012, at 15:34, Ryan Stone wrote: On Sun, Dec 2, 2012 at 8:05 AM, Robert Watson rwat...@freebsd.org wrote: Just to follow up on this thread, since the question has come up a number of times. mergemaser -p should be run prior to installworld always, but most of the time will do very little. One of its responsibilities is to add any necessary accounts and groups depended on by base system components -- e.g., that will be referenced during installworld as part of setting file ownership and groups. I often use make installworld installkernel distribution DESTDIR=... to create bootable images (e.g. for a USB stick). What's the recommendation for that case? Manually create the auditdistd user on the build host? Yes, that's probably the best short-term bet. In the longer term, it would be nice of installworld could not only generate an mtree on the side rather than directly chmod/chowning the files (Brooks Davis has patches for this), but also use UIDs/GIDs from a user database directly rather than assuming that the host where you are constructing the image has the same notion of users and groups. This is especially important if we want to support cross-building embedded images from Linux, Mac OS X, etc, in the future. One useful feature of NetBSD's install is that we can use passwd and group databases other than the one in /. You would obviously use this when doing an unprivileged install, but you might also want to do it for a privileged install as well which would fix this bootstrapping problem. -- Brooks pgpUbMFTNvAMt.pgp Description: PGP signature
Re: new pc-bios/bios.bin breaks freebsd booting
On Wed, Dec 12, 2012 at 09:01:01AM -0800, Adrian Chadd wrote: Yes, the qemu bios people decided that they could change the ACPI setup, in order to make Linux boot slightly (1 line) quieter. http://git.qemu.org/?p=seabios.git;a=commit;h=4540409d19a4baeec5006d925cfca19f8038a96e the qemu folks are actually being very responsive in trying to fix this for FreeBSD. See http://lists.nongnu.org/archive/html/qemu-devel/2012-12/msg01703.html and also the message below cheers luigi - Forwarded message from Paolo Bonzini pbonz...@redhat.com - Date: Thu, 13 Dec 2012 14:38:45 +0100 From: Paolo Bonzini pbonz...@redhat.com Subject: Re: [SeaBIOS] [PATCH] acpi: reintroduce LNKS To: Laszlo Ersek ler...@redhat.com CC: seab...@seabios.org, ri...@iet.unipi.it, Marcelo Tosatti mtosa...@redhat.com Il 13/12/2012 14:33, Laszlo Ersek ha scritto: Unfortunately, the code after the patch is also against the spec, and it breaks FreeBSD because it treats IRQ 9 polarity as active low without the Interrupt() entry. Actually, numeric _PRT entries are handled the same in Linux and FreeBSD (as active-low). However, under Linux it just happens to trigger another special casing of SCI which sets SCI up from its override entry in the MADT, ignoring the DSDT completely. I won't pretend I understand what I'm talking about, but the ACPI spec 5.0 says in 5.2.12.5 Interrupt Source Override Structure, Interrupt Source Overrides are also necessary when an identity mapped interrupt input has a non-standard polarity. Hence necessary but not sufficient, is that it? The MADT is about 8259 pins, while the _PRT entry identifies a GSI. So we have the same GSI (9) specified twice. Linux ignores the settings of the second entry and reuses those that came from the GSI. The important bit here is this: /* Don't set up the ACPI SCI because it's already set up */ if (acpi_gbl_FADT.sci_interrupt == gsi) return gsi; (And as you can see it's wrong, sci_interrupt is an 8259 interrupt not a GSI). SCI_INT in the FADT is explained as [...] OSPM is required to treat the ACPI SCI interrupt as a sharable, level, active low interrupt. which is then overridden in the MADT, stating active-high polarity. Yes, but this doesn't affect the definition of this GSI in the _PRT. It is always level/active-low for a numeric entry. Among the two conflicting choices, Linux happens to favor the MADT. FreeBSD doesn't. Paolo - End forwarded message - Adrian On 12 December 2012 08:07, Luigi Rizzo ri...@iet.unipi.it wrote: it seems that qemu-1.3.0 is broken for freebsd... cheers luigi -- Forwarded message -- From: Luigi Rizzo ri...@iet.unipi.it Date: Wed, Dec 12, 2012 at 8:04 AM Subject: new pc-bios/bios.bin breaks freebsd booting To: qemu-de...@nongnu.org, kra...@redhat.com I am not sure if it has been reported already but this commit http://git.qemu.org/?p=qemu.git;a=commitdiff;h=d7a51dbbaa70677846453f8c961590913052dd86 (replacing pc-bios/bios.bin with a newer version) breaks booting of FreeBSD on recent qemu (starting roughly with qemu- 1.3.0-rc2). Using a FreeBSD host, and a FreeBSD guest, the qemu thread runs at 100% and the console is stuck after the 'pci0' probe: ... hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 1 Hz quality 950 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0xb008-0xb00b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 Reverting the bios fixes things. I wonder if it isn't the case of reverting this change ? cheers luigi -- -+--- Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/. Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -+--- -- -+--- Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/. Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -+--- ___ 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
Re: new pc-bios/bios.bin breaks freebsd booting
Oh, phew. :) adrian On 13 December 2012 08:29, Luigi Rizzo ri...@iet.unipi.it wrote: On Wed, Dec 12, 2012 at 09:01:01AM -0800, Adrian Chadd wrote: Yes, the qemu bios people decided that they could change the ACPI setup, in order to make Linux boot slightly (1 line) quieter. http://git.qemu.org/?p=seabios.git;a=commit;h=4540409d19a4baeec5006d925cfca19f8038a96e the qemu folks are actually being very responsive in trying to fix this for FreeBSD. See http://lists.nongnu.org/archive/html/qemu-devel/2012-12/msg01703.html and also the message below cheers luigi - Forwarded message from Paolo Bonzini pbonz...@redhat.com - Date: Thu, 13 Dec 2012 14:38:45 +0100 From: Paolo Bonzini pbonz...@redhat.com Subject: Re: [SeaBIOS] [PATCH] acpi: reintroduce LNKS To: Laszlo Ersek ler...@redhat.com CC: seab...@seabios.org, ri...@iet.unipi.it, Marcelo Tosatti mtosa...@redhat.com Il 13/12/2012 14:33, Laszlo Ersek ha scritto: Unfortunately, the code after the patch is also against the spec, and it breaks FreeBSD because it treats IRQ 9 polarity as active low without the Interrupt() entry. Actually, numeric _PRT entries are handled the same in Linux and FreeBSD (as active-low). However, under Linux it just happens to trigger another special casing of SCI which sets SCI up from its override entry in the MADT, ignoring the DSDT completely. I won't pretend I understand what I'm talking about, but the ACPI spec 5.0 says in 5.2.12.5 Interrupt Source Override Structure, Interrupt Source Overrides are also necessary when an identity mapped interrupt input has a non-standard polarity. Hence necessary but not sufficient, is that it? The MADT is about 8259 pins, while the _PRT entry identifies a GSI. So we have the same GSI (9) specified twice. Linux ignores the settings of the second entry and reuses those that came from the GSI. The important bit here is this: /* Don't set up the ACPI SCI because it's already set up */ if (acpi_gbl_FADT.sci_interrupt == gsi) return gsi; (And as you can see it's wrong, sci_interrupt is an 8259 interrupt not a GSI). SCI_INT in the FADT is explained as [...] OSPM is required to treat the ACPI SCI interrupt as a sharable, level, active low interrupt. which is then overridden in the MADT, stating active-high polarity. Yes, but this doesn't affect the definition of this GSI in the _PRT. It is always level/active-low for a numeric entry. Among the two conflicting choices, Linux happens to favor the MADT. FreeBSD doesn't. Paolo - End forwarded message - Adrian On 12 December 2012 08:07, Luigi Rizzo ri...@iet.unipi.it wrote: it seems that qemu-1.3.0 is broken for freebsd... cheers luigi -- Forwarded message -- From: Luigi Rizzo ri...@iet.unipi.it Date: Wed, Dec 12, 2012 at 8:04 AM Subject: new pc-bios/bios.bin breaks freebsd booting To: qemu-de...@nongnu.org, kra...@redhat.com I am not sure if it has been reported already but this commit http://git.qemu.org/?p=qemu.git;a=commitdiff;h=d7a51dbbaa70677846453f8c961590913052dd86 (replacing pc-bios/bios.bin with a newer version) breaks booting of FreeBSD on recent qemu (starting roughly with qemu- 1.3.0-rc2). Using a FreeBSD host, and a FreeBSD guest, the qemu thread runs at 100% and the console is stuck after the 'pci0' probe: ... hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 1 Hz quality 950 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0xb008-0xb00b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 Reverting the bios fixes things. I wonder if it isn't the case of reverting this change ? cheers luigi -- -+--- Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/. Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -+--- -- -+--- Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/. Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -+--- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to
new xorg segfault 11 with KMS
Dear all, I lately see xorg segfault 11s with CURRENT, WITH_NEW_XORG=yes and WITH_KMS=yes. Interestingly, gdm loads fine but xfce4 at login directly causes the segfault (log attached), gnome survives a bit longer but starting any bigger application (e.g. firefox) causes it to crash with the same log. I have a Xorg.core file, but since it is without debug symbols the backtrace makes little sense to me. Unfortunately, I cannot tell what is the root cause of the problems as I first got bitten by the pcre update and also did the world update to the clang3.2 import. Needless to say that everything worked prior and the configuration (no xorg.conf here) did not change. uname -a: FreeBSD X 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r244180: Thu Dec 13 09:46:06 EST 2012 root@X:/usr/obj/usr/src/sys/GENERIC amd64. Xorg.0.log: [88.021] X.Org X Server 1.10.6 Release Date: 2012-02-10 [88.021] X Protocol Version 11, Revision 0 [88.021] Build Operating System: FreeBSD 10.0-CURRENT amd64 [88.021] Current Operating System: FreeBSD X 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r244180: Thu Dec 13 09:46:06 EST 2012 root@XXX:/usr/obj/usr/src/sys/GENERIC amd64 [88.021] Build Date: 13 December 2012 06:30:07AM [88.021] [88.021] Current version of pixman: 0.24.2 [88.021]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [88.021] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [88.022] (==) Log file: /var/log/Xorg.0.log, Time: Thu Dec 13 15:01:42 2012 [88.024] (II) Loader magic: 0x7c1930 [88.024] (II) Module ABI versions: [88.024]X.Org ANSI C Emulation: 0.4 [88.024]X.Org Video Driver: 10.0 [88.024]X.Org XInput driver : 12.2 [88.024]X.Org Server Extension : 5.0 [88.025] (--) PCI:*(0:0:2:0) 8086:0166:17aa:2200 rev 9, Mem @ 0xf000/4194304, 0xe000/268435456, I/O @ 0x5000/64, BIOS @ 0x/65536 [88.025] (==) Using default built-in configuration (30 lines) [88.025] (==) --- Start of built-in configuration --- [88.025]Section Device [88.025]Identifier Builtin Default intel Device 0 [88.025]Driver intel [88.025]EndSection [88.025]Section Screen [88.025]Identifier Builtin Default intel Screen 0 [88.025]Device Builtin Default intel Device 0 [88.025]EndSection [88.025]Section Device [88.025]Identifier Builtin Default vesa Device 0 [88.025]Driver vesa [88.025]EndSection [88.025]Section Screen [88.025]Identifier Builtin Default vesa Screen 0 [88.025]Device Builtin Default vesa Device 0 [88.025]EndSection [88.025]Section Device [88.025]Identifier Builtin Default fbdev Device 0 [88.025]Driver fbdev [88.025]EndSection [88.025]Section Screen [88.025]Identifier Builtin Default fbdev Screen 0 [88.025]Device Builtin Default fbdev Device 0 [88.026]EndSection [88.026]Section ServerLayout [88.026]Identifier Builtin Default Layout [88.026]Screen Builtin Default intel Screen 0 [88.026]Screen Builtin Default vesa Screen 0 [88.026]Screen Builtin Default fbdev Screen 0 [88.026]EndSection [88.026] (==) --- End of built-in configuration --- [88.026] (==) ServerLayout Builtin Default Layout [88.026] (**) |--Screen Builtin Default intel Screen 0 (0) [88.026] (**) | |--Monitor default monitor [88.026] (**) | |--Device Builtin Default intel Device 0 [88.026] (==) No monitor specified for screen Builtin Default intel Screen 0. Using a default monitor configuration. [88.026] (**) |--Screen Builtin Default vesa Screen 0 (1) [88.026] (**) | |--Monitor default monitor [88.026] (**) | |--Device Builtin Default vesa Device 0 [88.026] (==) No monitor specified for screen Builtin Default vesa Screen 0. Using a default monitor configuration. [88.026] (**) |--Screen Builtin Default fbdev Screen 0 (2) [88.027] (**) | |--Monitor default monitor [88.027] (**) | |--Device Builtin Default fbdev Device 0 [88.027] (==) No monitor specified for screen Builtin Default fbdev Screen 0. Using a default monitor configuration. [88.027] (==) Automatically adding devices [88.027] (==) Automatically enabling devices [88.027] (WW) The directory /usr/local/lib/X11/fonts/misc/ does not exist. [88.027]Entry deleted from font path. [88.028] (WW) The directory /usr/local/lib/X11/fonts/Type1/ does not exist. [88.029]Entry deleted from font
Re: new xorg segfault 11 with KMS
I have a similar problem when running firefox On Thursday 13 December 2012 15:49:38 Johannes Dieterich wrote: Dear all, I lately see xorg segfault 11s with CURRENT, WITH_NEW_XORG=yes and WITH_KMS=yes. Interestingly, gdm loads fine but xfce4 at login directly causes the segfault (log attached), gnome survives a bit longer but starting any bigger application (e.g. firefox) causes it to crash with the same log. I have a Xorg.core file, but since it is without debug symbols the backtrace makes little sense to me. Unfortunately, I cannot tell what is the root cause of the problems as I first got bitten by the pcre update and also did the world update to the clang3.2 import. Needless to say that everything worked prior and the configuration (no xorg.conf here) did not change. uname -a: FreeBSD X 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r244180: Thu Dec 13 09:46:06 EST 2012 root@X:/usr/obj/usr/src/sys/GENERIC amd64. Xorg.0.log: [88.021] X.Org X Server 1.10.6 Release Date: 2012-02-10 [88.021] X Protocol Version 11, Revision 0 [88.021] Build Operating System: FreeBSD 10.0-CURRENT amd64 [88.021] Current Operating System: FreeBSD X 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r244180: Thu Dec 13 09:46:06 EST 2012 root@XXX:/usr/obj/usr/src/sys/GENERIC amd64 [88.021] Build Date: 13 December 2012 06:30:07AM [88.021] [88.021] Current version of pixman: 0.24.2 [88.021]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [88.021] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [88.022] (==) Log file: /var/log/Xorg.0.log, Time: Thu Dec 13 15:01:42 2012 [88.024] (II) Loader magic: 0x7c1930 [88.024] (II) Module ABI versions: [88.024]X.Org ANSI C Emulation: 0.4 [88.024]X.Org Video Driver: 10.0 [88.024]X.Org XInput driver : 12.2 [88.024]X.Org Server Extension : 5.0 [88.025] (--) PCI:*(0:0:2:0) 8086:0166:17aa:2200 rev 9, Mem @ 0xf000/4194304, 0xe000/268435456, I/O @ 0x5000/64, BIOS @ 0x/65536 [88.025] (==) Using default built-in configuration (30 lines) [88.025] (==) --- Start of built-in configuration --- [88.025]Section Device [88.025]Identifier Builtin Default intel Device 0 [88.025]Driver intel [88.025]EndSection [88.025]Section Screen [88.025]Identifier Builtin Default intel Screen 0 [88.025]Device Builtin Default intel Device 0 [88.025]EndSection [88.025]Section Device [88.025]Identifier Builtin Default vesa Device 0 [88.025]Driver vesa [88.025]EndSection [88.025]Section Screen [88.025]Identifier Builtin Default vesa Screen 0 [88.025]Device Builtin Default vesa Device 0 [88.025]EndSection [88.025]Section Device [88.025]Identifier Builtin Default fbdev Device 0 [88.025]Driver fbdev [88.025]EndSection [88.025]Section Screen [88.025]Identifier Builtin Default fbdev Screen 0 [88.025]Device Builtin Default fbdev Device 0 [88.026]EndSection [88.026]Section ServerLayout [88.026]Identifier Builtin Default Layout [88.026]Screen Builtin Default intel Screen 0 [88.026]Screen Builtin Default vesa Screen 0 [88.026]Screen Builtin Default fbdev Screen 0 [88.026]EndSection [88.026] (==) --- End of built-in configuration --- [88.026] (==) ServerLayout Builtin Default Layout [88.026] (**) |--Screen Builtin Default intel Screen 0 (0) [88.026] (**) | |--Monitor default monitor [88.026] (**) | |--Device Builtin Default intel Device 0 [88.026] (==) No monitor specified for screen Builtin Default intel Screen 0. Using a default monitor configuration. [88.026] (**) |--Screen Builtin Default vesa Screen 0 (1) [88.026] (**) | |--Monitor default monitor [88.026] (**) | |--Device Builtin Default vesa Device 0 [88.026] (==) No monitor specified for screen Builtin Default vesa Screen 0. Using a default monitor configuration. [88.026] (**) |--Screen Builtin Default fbdev Screen 0 (2) [88.027] (**) | |--Monitor default monitor [88.027] (**) | |--Device Builtin Default fbdev Device 0 [88.027] (==) No monitor specified for screen Builtin Default fbdev Screen 0. Using a default monitor configuration. [88.027] (==) Automatically adding devices [88.027] (==) Automatically enabling devices [88.027] (WW) The
Re: new xorg segfault 11 with KMS
Rebuilding xorg-server with gcc resolves the problem, bt points at libdrm2. On Thu, Dec 13, 2012 at 10:51 PM, Artyom Mirgorodskiy art...@ijminteractive.net wrote: I have a similar problem when running firefox On Thursday 13 December 2012 15:49:38 Johannes Dieterich wrote: Dear all, I lately see xorg segfault 11s with CURRENT, WITH_NEW_XORG=yes and WITH_KMS=yes. Interestingly, gdm loads fine but xfce4 at login directly causes the segfault (log attached), gnome survives a bit longer but starting any bigger application (e.g. firefox) causes it to crash with the same log. I have a Xorg.core file, but since it is without debug symbols the backtrace makes little sense to me. Unfortunately, I cannot tell what is the root cause of the problems as I first got bitten by the pcre update and also did the world update to the clang3.2 import. Needless to say that everything worked prior and the configuration (no xorg.conf here) did not change. uname -a: FreeBSD X 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r244180: Thu Dec 13 09:46:06 EST 2012 root@X:/usr/obj/usr/src/sys/GENERIC amd64. Xorg.0.log: [88.021] X.Org X Server 1.10.6 Release Date: 2012-02-10 [88.021] X Protocol Version 11, Revision 0 [88.021] Build Operating System: FreeBSD 10.0-CURRENT amd64 [88.021] Current Operating System: FreeBSD X 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r244180: Thu Dec 13 09:46:06 EST 2012 root@XXX:/usr/obj/usr/src/sys/GENERIC amd64 [88.021] Build Date: 13 December 2012 06:30:07AM [88.021] [88.021] Current version of pixman: 0.24.2 [88.021]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [88.021] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [88.022] (==) Log file: /var/log/Xorg.0.log, Time: Thu Dec 13 15:01:42 2012 [88.024] (II) Loader magic: 0x7c1930 [88.024] (II) Module ABI versions: [88.024]X.Org ANSI C Emulation: 0.4 [88.024]X.Org Video Driver: 10.0 [88.024]X.Org XInput driver : 12.2 [88.024]X.Org Server Extension : 5.0 [88.025] (--) PCI:*(0:0:2:0) 8086:0166:17aa:2200 rev 9, Mem @ 0xf000/4194304, 0xe000/268435456, I/O @ 0x5000/64, BIOS @ 0x/65536 [88.025] (==) Using default built-in configuration (30 lines) [88.025] (==) --- Start of built-in configuration --- [88.025]Section Device [88.025]Identifier Builtin Default intel Device 0 [88.025]Driver intel [88.025]EndSection [88.025]Section Screen [88.025]Identifier Builtin Default intel Screen 0 [88.025]Device Builtin Default intel Device 0 [88.025]EndSection [88.025]Section Device [88.025]Identifier Builtin Default vesa Device 0 [88.025]Driver vesa [88.025]EndSection [88.025]Section Screen [88.025]Identifier Builtin Default vesa Screen 0 [88.025]Device Builtin Default vesa Device 0 [88.025]EndSection [88.025]Section Device [88.025]Identifier Builtin Default fbdev Device 0 [88.025]Driver fbdev [88.025]EndSection [88.025]Section Screen [88.025]Identifier Builtin Default fbdev Screen 0 [88.025]Device Builtin Default fbdev Device 0 [88.026]EndSection [88.026]Section ServerLayout [88.026]Identifier Builtin Default Layout [88.026]Screen Builtin Default intel Screen 0 [88.026]Screen Builtin Default vesa Screen 0 [88.026]Screen Builtin Default fbdev Screen 0 [88.026]EndSection [88.026] (==) --- End of built-in configuration --- [88.026] (==) ServerLayout Builtin Default Layout [88.026] (**) |--Screen Builtin Default intel Screen 0 (0) [88.026] (**) | |--Monitor default monitor [88.026] (**) | |--Device Builtin Default intel Device 0 [88.026] (==) No monitor specified for screen Builtin Default intel Screen 0. Using a default monitor configuration. [88.026] (**) |--Screen Builtin Default vesa Screen 0 (1) [88.026] (**) | |--Monitor default monitor [88.026] (**) | |--Device Builtin Default vesa Device 0 [88.026] (==) No monitor specified for screen Builtin Default vesa Screen 0. Using a default monitor configuration. [88.026] (**) |--Screen Builtin Default fbdev Screen 0 (2) [88.027] (**) | |--Monitor default monitor [88.027] (**) | |--Device Builtin Default fbdev
Re: new xorg segfault 11 with KMS
On Thu, Dec 13, 2012 at 12:51 PM, Artyom Mirgorodskiy art...@ijminteractive.net wrote: I have a similar problem when running firefox I don't run into this problem with CURRENT and fluxbox/Firefox on my Netbook. There's just a nasty misprogrammed region across my screen that I've been meaning to file a bug about... My Netbook has a Pineview chipset. Thanks! -Garrett ___ 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 segfault 11 with KMS
On Thu, Dec 13, 2012 at 4:01 PM, George Liaskos geo.lias...@gmail.com wrote: Rebuilding xorg-server with gcc resolves the problem, bt points at libdrm2. So basically this is a regression from the previous clang3.1 to the clang3.2 import then? Is anyone of the clang guys aware of this? On Thu, Dec 13, 2012 at 10:51 PM, Artyom Mirgorodskiy art...@ijminteractive.net wrote: I have a similar problem when running firefox On Thursday 13 December 2012 15:49:38 Johannes Dieterich wrote: Dear all, I lately see xorg segfault 11s with CURRENT, WITH_NEW_XORG=yes and WITH_KMS=yes. Interestingly, gdm loads fine but xfce4 at login directly causes the segfault (log attached), gnome survives a bit longer but starting any bigger application (e.g. firefox) causes it to crash with the same log. I have a Xorg.core file, but since it is without debug symbols the backtrace makes little sense to me. Unfortunately, I cannot tell what is the root cause of the problems as I first got bitten by the pcre update and also did the world update to the clang3.2 import. Needless to say that everything worked prior and the configuration (no xorg.conf here) did not change. uname -a: FreeBSD X 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r244180: Thu Dec 13 09:46:06 EST 2012 root@X:/usr/obj/usr/src/sys/GENERIC amd64. Xorg.0.log: [88.021] X.Org X Server 1.10.6 Release Date: 2012-02-10 [88.021] X Protocol Version 11, Revision 0 [88.021] Build Operating System: FreeBSD 10.0-CURRENT amd64 [88.021] Current Operating System: FreeBSD X 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r244180: Thu Dec 13 09:46:06 EST 2012 root@XXX:/usr/obj/usr/src/sys/GENERIC amd64 [88.021] Build Date: 13 December 2012 06:30:07AM [88.021] [88.021] Current version of pixman: 0.24.2 [88.021]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [88.021] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [88.022] (==) Log file: /var/log/Xorg.0.log, Time: Thu Dec 13 15:01:42 2012 [88.024] (II) Loader magic: 0x7c1930 [88.024] (II) Module ABI versions: [88.024]X.Org ANSI C Emulation: 0.4 [88.024]X.Org Video Driver: 10.0 [88.024]X.Org XInput driver : 12.2 [88.024]X.Org Server Extension : 5.0 [88.025] (--) PCI:*(0:0:2:0) 8086:0166:17aa:2200 rev 9, Mem @ 0xf000/4194304, 0xe000/268435456, I/O @ 0x5000/64, BIOS @ 0x/65536 [88.025] (==) Using default built-in configuration (30 lines) [88.025] (==) --- Start of built-in configuration --- [88.025]Section Device [88.025]Identifier Builtin Default intel Device 0 [88.025]Driver intel [88.025]EndSection [88.025]Section Screen [88.025]Identifier Builtin Default intel Screen 0 [88.025]Device Builtin Default intel Device 0 [88.025]EndSection [88.025]Section Device [88.025]Identifier Builtin Default vesa Device 0 [88.025]Driver vesa [88.025]EndSection [88.025]Section Screen [88.025]Identifier Builtin Default vesa Screen 0 [88.025]Device Builtin Default vesa Device 0 [88.025]EndSection [88.025]Section Device [88.025]Identifier Builtin Default fbdev Device 0 [88.025]Driver fbdev [88.025]EndSection [88.025]Section Screen [88.025]Identifier Builtin Default fbdev Screen 0 [88.025]Device Builtin Default fbdev Device 0 [88.026]EndSection [88.026]Section ServerLayout [88.026]Identifier Builtin Default Layout [88.026]Screen Builtin Default intel Screen 0 [88.026]Screen Builtin Default vesa Screen 0 [88.026]Screen Builtin Default fbdev Screen 0 [88.026]EndSection [88.026] (==) --- End of built-in configuration --- [88.026] (==) ServerLayout Builtin Default Layout [88.026] (**) |--Screen Builtin Default intel Screen 0 (0) [88.026] (**) | |--Monitor default monitor [88.026] (**) | |--Device Builtin Default intel Device 0 [88.026] (==) No monitor specified for screen Builtin Default intel Screen 0. Using a default monitor configuration. [88.026] (**) |--Screen Builtin Default vesa Screen 0 (1) [88.026] (**) | |--Monitor default monitor [88.026] (**) | |--Device Builtin Default vesa Device 0 [88.026] (==) No monitor specified for screen Builtin Default vesa Screen 0.
Re: new xorg segfault 11 with KMS
On Thu, Dec 13, 2012 at 1:03 PM, Garrett Cooper yaneg...@gmail.com wrote: On Thu, Dec 13, 2012 at 12:51 PM, Artyom Mirgorodskiy art...@ijminteractive.net wrote: I have a similar problem when running firefox I don't run into this problem with CURRENT and fluxbox/Firefox on my Netbook. There's just a nasty misprogrammed region across my screen that I've been meaning to file a bug about... My Netbook has a Pineview chipset. Good point -- my ports were last built with gcc before I upgraded recently; haven't tried with clang. Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ath0: unable to attach hardware
Hello everyone, I'm afraid I still don't know what exactly BAR is, or how I get its value that I'm supposed to plug into the line John provided: dd if=/dev/mem bs=4 iseek=((start of bar + reg offset)/4) count=1 | hd I assumed that start of bar is 0xfdee in my case, since dmesg reports ath0: Atheros 5413 mem 0xfdee-0xfdee irq 16 at device 4.0 on pci2 This is what I get: # dd if=/dev/mem bs=4 iseek=`echo ibase=16; (FDEE+4004)/4 | bc` count=1 | hd 00 00 01 00 # dd if=/dev/mem bs=4 iseek=`echo ibase=16; (FDEE+4010)/4 | bc` count=1 | hd 14 00 01 00 Please correct me if my assumption about start of bar was wrong and/or I made some other mistake. Also, please don't hesitate to ask me to do anything else that might help you during debugging. Thank you very much for the effort. On 11 December 2012 12:49, John Baldwin j...@freebsd.org wrote: Look, it's up to you to look at more registers if you want to debug this further. PCI says everything is ok, so the ball is in your court. Right, that's why I've asked for those two above registers. There are other things that could be wrong - eg, the device may actually not have reset correctly. This isn't the first time that someone's come to me with a linux works, freebsd doesn't for an AR5212 era NIC. ath5k and FreeBSD do the same thing at probe/attach time. I believe they do the same thing during device power-on time too. There's some corner cases where the chip doesn't reset right because the BIOS PCI bus reset code does things in a brain dead manner (eg doing two PCI bus resets back to back with not enough time in between for the MAC to settle.) There may be PCI code differences in how Linux and FreeBSD does things like reset the PCI bus. 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: ath0: unable to attach hardware
On 13 December 2012 13:11, hu...@hush.com wrote: Hello everyone, I'm afraid I still don't know what exactly BAR is, or how I get its value that I'm supposed to plug into the line John provided: dd if=/dev/mem bs=4 iseek=((start of bar + reg offset)/4) count=1 | hd I assumed that start of bar is 0xfdee in my case, since dmesg reports ath0: Atheros 5413 mem 0xfdee-0xfdee irq 16 at device 4.0 on pci2 Yup. This is what I get: # dd if=/dev/mem bs=4 iseek=`echo ibase=16; (FDEE+4004)/4 | bc` count=1 | hd 00 00 01 00 # dd if=/dev/mem bs=4 iseek=`echo ibase=16; (FDEE+4010)/4 | bc` count=1 | hd 14 00 01 00 Please correct me if my assumption about start of bar was wrong and/or I made some other mistake. Also, please don't hesitate to ask me to do anything else that might help you during debugging. Thank you very much for the effort. Hm. Wait, what's the rest of the ath0: output? 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: new xorg segfault 11 with KMS
On 2012-12-13 21:49, Johannes Dieterich wrote: I lately see xorg segfault 11s with CURRENT, WITH_NEW_XORG=yes and WITH_KMS=yes. Interestingly, gdm loads fine but xfce4 at login directly causes the segfault (log attached), gnome survives a bit longer but starting any bigger application (e.g. firefox) causes it to crash with the same log. I have a Xorg.core file, but since it is without debug symbols the backtrace makes little sense to me. Please post the backtrace anyway. :-) Or recompile xorg-server with WITH_DEBUG=yes in your environment, and reproduce the crash. ___ 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 segfault 11 with KMS
On 12/13/12 16:36, Dimitry Andric wrote: On 2012-12-13 21:49, Johannes Dieterich wrote: I lately see xorg segfault 11s with CURRENT, WITH_NEW_XORG=yes and WITH_KMS=yes. Interestingly, gdm loads fine but xfce4 at login directly causes the segfault (log attached), gnome survives a bit longer but starting any bigger application (e.g. firefox) causes it to crash with the same log. I have a Xorg.core file, but since it is without debug symbols the backtrace makes little sense to me. Please post the backtrace anyway. :-) Or recompile xorg-server with WITH_DEBUG=yes in your environment, and reproduce the crash. Here we go: 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. Core was generated by `Xorg'. Program terminated with signal 6, Aborted. #0 0x000802c4520a in ?? () (gdb) bt #0 0x000802c4520a in ?? () #1 0x000802cf72bc in ?? () #2 0x000802cf85ca in ?? () #3 0x007cdd5c in ?? () #4 0xffdf in ?? () #5 0x in ?? () #6 0x in ?? () #7 0x00575f06 in ?? () #8 0x7fffce50 in ?? () #9 0x00472c9e in ?? () #10 0x7fffce60 in ?? () #11 0x0047e034 in ?? () #12 0x7fffce70 in ?? () #13 0x004704ed in ?? () #14 0x7fffcf50 in ?? () #15 0x0046fd26 in ?? () #16 0x3246 in ?? () #17 0x000b in ?? () #18 0x000802f31a10 in ?? () #19 0xf801 in ?? () #20 0x0101010101010101 in ?? () #21 0x8080808080808080 in ?? () #22 0x in ?? () #23 0x0001 in ?? () #24 0x6e7dec389dd25e4d in ?? () #25 0x000802c60f9e in ?? () #26 0x000802f31a10 in ?? () #27 0x000802f31a10 in ?? () #28 0x in ?? () #29 0x000b in ?? () #30 0x7fffcf50 in ?? () #31 0x000802c19662 in ?? () #32 0x0006 in ?? () #33 0x00470e50 in ?? () #34 0x000b in ?? () #35 0x7fffd730 in ?? () #36 0x6e7dec389dd25e4d in ?? () #37 0x000b in ?? () #38 0x00300018 in ?? () #39 0x7fffcf60 in ?? () ---Type return to continue, or q return to quit--- #40 0x7fffce80 in ?? () #41 0x000b in ?? () #42 0x7fffcf70 in ?? () #43 0x00470ee3 in ?? () #44 0x7fffd358 in ?? () #45 0x7fffd3c0 in ?? () #46 0x7fffd330 in ?? () #47 0x0008029ca2e6 in ?? () #48 0x in ?? () I also rebuild xorg with debug enabled. Interestingly, I cannot reproduce the crash anymore. Either I forgot to rebuild something (seems unlikely) or the crash has to do with optimizations or flags not present in a debug build. Hope this helps. Johannes ___ 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 segfault 11 with KMS
On 13 Dec 2012, at 21:48, Johannes Dieterich wrote: GNU gdb 6.1.1 [FreeBSD] You might try with gdb 7.x from ports. gdb 6.1.1 from the base system doesn't do a good job of understanding the newer version of DWARF that clang emits. David ___ 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 segfault 11 with KMS
On 12/13/12 22:48, Johannes Dieterich wrote: On 12/13/12 16:36, Dimitry Andric wrote: On 2012-12-13 21:49, Johannes Dieterich wrote: I lately see xorg segfault 11s with CURRENT, WITH_NEW_XORG=yes and WITH_KMS=yes. Interestingly, gdm loads fine but xfce4 at login directly causes the segfault (log attached), gnome survives a bit longer but starting any bigger application (e.g. firefox) causes it to crash with the same log. I have a Xorg.core file, but since it is without debug symbols the backtrace makes little sense to me. Please post the backtrace anyway. :-) Or recompile xorg-server with WITH_DEBUG=yes in your environment, and reproduce the crash. Here we go: I also rebuild xorg with debug enabled. Interestingly, I cannot reproduce the crash anymore. Either I forgot to rebuild something (seems unlikely) or the crash has to do with optimizations or flags not present in a debug build. This is not unlikely. There are probably places in the X codebase which depends on gcc specific behavior, or undefined behavior, by accident or by chance. Regards -- Niclas Zeising ___ 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 segfault 11 with KMS
On 12/13/12 16:53, David Chisnall wrote: On 13 Dec 2012, at 21:48, Johannes Dieterich wrote: GNU gdb 6.1.1 [FreeBSD] You might try with gdb 7.x from ports. gdb 6.1.1 from the base system doesn't do a good job of understanding the newer version of DWARF that clang emits. Did that but it doesn't change much: GNU gdb (GDB) 7.5 [GDB v7.5 for FreeBSD] Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-portbld-freebsd10.0. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. [New process 100714] Core was generated by `Xorg'. Program terminated with signal 6, Aborted. #0 0x000802c4520a in ?? () (gdb) bt #0 0x000802c4520a in ?? () #1 0x000802cf72bc in ?? () #2 0x000802cf85ca in ?? () #3 0x007cdd5c in ?? () #4 0xffdf in ?? () #5 0x in ?? () #6 0x in ?? () #7 0x00575f06 in ?? () #8 0x7fffce50 in ?? () #9 0x00472c9e in ?? () #10 0x7fffce60 in ?? () #11 0x0047e034 in ?? () #12 0x7fffce70 in ?? () #13 0x004704ed in ?? () #14 0x7fffcf50 in ?? () #15 0x0046fd26 in ?? () #16 0x3246 in ?? () #17 0x000b in ?? () #18 0x000802f31a10 in ?? () #19 0xf801 in ?? () #20 0x0101010101010101 in ?? () #21 0x8080808080808080 in ?? () #22 0x in ?? () #23 0x0001 in ?? () #24 0x6e7dec389dd25e4d in ?? () #25 0x000802c60f9e in ?? () #26 0x000802f31a10 in ?? () #27 0x000802f31a10 in ?? () #28 0x in ?? () #29 0x000b in ?? () #30 0x7fffcf50 in ?? () #31 0x000802c19662 in ?? () #32 0x0006 in ?? () #33 0x00470e50 in ?? () #34 0x000b in ?? () #35 0x7fffd730 in ?? () #36 0x6e7dec389dd25e4d in ?? () #37 0x000b in ?? () #38 0x00300018 in ?? () #39 0x7fffcf60 in ?? () ---Type return to continue, or q return to quit--- #40 0x7fffce80 in ?? () #41 0x000b in ?? () #42 0x7fffcf70 in ?? () #43 0x00470ee3 in ?? () #44 0x7fffd358 in ?? () #45 0x7fffd3c0 in ?? () #46 0x7fffd330 in ?? () #47 0x0008029ca2e6 in ?? () #48 0x in ?? () I guess marking xorg-server to require USE_GCC=4.2+ would be a reasonable workaround for the time being? Best Johannes ___ 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 segfault 11 with KMS
I have recompile xorg-server with WITH_DEBUG=yes and did not get crash On Thursday 13 December 2012 22:36:24 Dimitry Andric wrote: On 2012-12-13 21:49, Johannes Dieterich wrote: I lately see xorg segfault 11s with CURRENT, WITH_NEW_XORG=yes and WITH_KMS=yes. Interestingly, gdm loads fine but xfce4 at login directly causes the segfault (log attached), gnome survives a bit longer but starting any bigger application (e.g. firefox) causes it to crash with the same log. I have a Xorg.core file, but since it is without debug symbols the backtrace makes little sense to me. Please post the backtrace anyway. :-) Or recompile xorg-server with WITH_DEBUG=yes in your environment, and reproduce the crash. ___ 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 -- This message is for the person(s) named above only and may contain privileged, proprietary, or otherwise private information. If you received this transmission in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADSUP] zfs root pool mounting
On Thu, Dec 13, 2012 at 3:20 AM, Andriy Gapon a...@freebsd.org wrote: ... One thing that I recommend to all ZFS users is to make use of boot environments. They are very easy, very convenient and may save a lot of trouble. Use either any of the tool available in ports (e.g. sysutils/beadm) or just do boot environments in an ad hoc fashion: snapshot and clone your current / known good boot+root filesystem and you have a safe environment to fall back to. Looks interesting (this page has a slightly more in-depth description of what beadm tries to achieve for the layman like me that doesn't use *Solaris: http://www.linuxquestions.org/questions/*bsd-17/howto-zfs-madness-beadm-on-freebsd-4175412036/ ). Proper zdb -l usage was described in the HEADSUP posting. It's also available in zdb(8). zdb -l should be used with disks/partitions/etc, not with pool names. I realized that mistake after the fact :/. I'm running into the same behavior before and after I upgraded sac/sac2. My git branch is a lightly modified version of FreeBSD, but doesn't contain any ZFS specific changes (I can point you to it if you like to look at it). Would appreciate some pointers on what to do next. Try to get a working environment (using livecd, another disk, backups, etc), try to follow the original instructions. Ok. That's sort of what I'm trying. Given that I didn't do a *ton* of customizations, I might just tar up the root pool's contents and basic configuration, wipe it out, and try creating a new one from scratch and restore the contents after the fact. However, thinking back I could turn on terse debugging in ZFS after building it with that (I've done it once before -- forgot about it until now). That would probably be the best way to get the official story from ZFS as to what it thinks is going south when importing the pool. Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADSUP] zfs root pool mounting
On Thu, Dec 13, 2012 at 3:24 AM, Andriy Gapon a...@freebsd.org wrote: ... This sounds messy, not sure if it has any informative value. I think I've seen something like this after some reason ZFS import from upsteam when my kernel and userland were out of sync. Do you do a full boot from the livecd? Or do you boot your kernel but then mount userland from the cd? In any case, not sure if this is relevan to your main trouble. I tried booting from a custom kernel, ran into the mountroot prompt and then chose cd9660:/dev/cd0 instead of zfs:root (my root pool's name). ... bootfs property should not better. Multi-pool configurations has been tested before the commit. That's what I thought, but I was unsure... Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADSUP] zfs root pool mounting
On Thu, Dec 13, 2012 at 2:49 PM, Garrett Cooper yaneg...@gmail.com wrote: On Thu, Dec 13, 2012 at 3:20 AM, Andriy Gapon a...@freebsd.org wrote: ... One thing that I recommend to all ZFS users is to make use of boot environments. They are very easy, very convenient and may save a lot of trouble. Use either any of the tool available in ports (e.g. sysutils/beadm) or just do boot environments in an ad hoc fashion: snapshot and clone your current / known good boot+root filesystem and you have a safe environment to fall back to. Looks interesting (this page has a slightly more in-depth description of what beadm tries to achieve for the layman like me that doesn't use *Solaris: http://www.linuxquestions.org/questions/*bsd-17/howto-zfs-madness-beadm-on-freebsd-4175412036/ ). You could at least point to the FreeBSD Forums version of that post. :) https://forums.freebsd.org/showthread.php?t=31662 -- 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: /usr/src/sys/conf/newvers.sh, SYSDIR set to wrong directory.
On Thu, Dec 13, 2012 at 4:13 PM, Ian Lepore
free...@damnhippie.dyndns.org wrote:
On Wed, 2012-12-12 at 20:52 +0200, Kimmo Paasiala wrote:
On Wed, Dec 12, 2012 at 6:53 PM, Ian Lepore
free...@damnhippie.dyndns.org wrote:
On Wed, 2012-12-12 at 18:14 +0200, Kimmo Paasiala wrote:
Hello,
My 9-STABLE buildworld broke in a very inexplicable way, I was
getting an error on /usr/src/include/osreldate.h that I couldn't
figure out until I started looking at the sys/conf/newvers.sh and what
it does. It turned out that the thing that broke my buildworld was
having .git directory at the root directory of the system because I
recently started using GIT to track the configuration files.
I added some debug echos to the newvers.sh and I found out it's
setting SYSDIR to /bin/.. which in turn causes the newvers.sh to set
the gitdir to /.git and that seems to break the logic in newvers.sh.
Isn't SYSDIR supposed to be set to the sys -subdirectory of the source
tree (/usr/src/sys default)?
I'm guessing the reason the SYSDIR gets set to /bin/.. is the line in
newvers.sh:
SYSDIR=$(dirname $0)/..
$0 is actually /bin/sh and not the path to newver.sh because the
newvers.sh is sourced by the Makefile in /usr/src/include instead of
executing it:
osreldate.h: ${.CURDIR}/../sys/conf/newvers.sh
${.CURDIR}/../sys/sys/param.h \
${.CURDIR}/Makefile
@${ECHO} creating osreldate.h from newvers.sh
@MAKE=${MAKE}; \
PARAMFILE=${.CURDIR}/../sys/sys/param.h; \
. ${.CURDIR}/../sys/conf/newvers.sh; \
Now the question is how to fix this?
-Kimmo
Perhaps it could be handled similar to PARAMFILE, something like this in
the makefile:
PARAMFILE=${.CURDIR}/../sys/sys/param.h; \
SYSDIR=${.CURDIR}/../sys; \
. ${.CURDIR}/../sys/conf/newvers.sh; \
I'm not sure if newvers.sh needs to work in ways that don't involve
being invoked from that makefile rule, so to be safe it could have
default handling, something like:
: ${SYSDIR:=$(dirname $0)/..}
-- Ian
Thanks, that works. Should I file a PR about this?
-Kimmo
I think that would probably be a good idea, since no committer has
chimed in on this thread saying they're about to commit a fix.
-- Ian
Submitted as misc/174422.
-Kimmo
___
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 segfault 11 with KMS
On 12/13/12 23:03, Johannes Dieterich wrote: On 12/13/12 16:53, David Chisnall wrote: On 13 Dec 2012, at 21:48, Johannes Dieterich wrote: GNU gdb 6.1.1 [FreeBSD] You might try with gdb 7.x from ports. gdb 6.1.1 from the base system doesn't do a good job of understanding the newer version of DWARF that clang emits. Did that but it doesn't change much: I guess marking xorg-server to require USE_GCC=4.2+ would be a reasonable workaround for the time being? I have a shot in the dark before we try that, I just need to finish the patch. I'll let you all know when it's ready. Regards -- Niclas -- Niclas Zeising ___ 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
fifolog_writer
Yesterday I updated source and when running installkernel it complained about no auditdistd user, so I ran 'mergemaster -p'. Then the kernel installed and I rebooted. Before running installworld I ran 'mergemaster -p' again and this time, if I recall correctly, it produced a new group. I ran installworld and am stuck here: === /usr.sbin/fifolog/fifolog_writer (install) This is amd64 and has been stuck like this for 9 hours. Any suggestions? Thank you, Darrel ___ 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
[RFC/RFT] calloutng
Hi. This patch takes callout(9) and redesign the KPI and the implementation. The main objective of this work is making the subsystem tickless. In the last several years, this possibility has been discussed widely (http://markmail.org/message/q3xmr2ttlzpqkmae), but until now noone really implemented that. If you want a complete history of what has been done in the last months you can check the calloutng project repository http://svnweb.freebsd.org/base/projects/calloutng/ For lazy people, here's a summary: 1) callout(9) is not anymore constrained to the resolution a periodic hz clock can give. In order to do that, the eventtimers(4) subsystem is used as backend. 2) Conversely from what discussed in past, we maintained the callwheel as underlying data structure for keeping track of the outstading timeouts. This choice has a couple of advantages, in particular we can still take benefits from the O(1) average complexity of the wheel for all the operations. Also, we thought the code duplication that would arise from the use of a two-staged backend for callout (e.g. use wheel for coarse resolution event and another data structure, such as an heap for high resolution events), is unacceptable. In fact, as long as callout gained the ability to migrate from a cpu to another having a double backend would mean doubling the code for the migration path. 3) A way to dispatch interrupts from hardware interrupt context has been implemented, using special callout flag. This has limited applicability, but avoid the dispatching of a SWI thread for handling specific callouts, avoiding the wake up of another CPU for processing and a (relatively useless) context switch 4) As long as new callout mechanism deals with bintime and not anymore with ticks, time is specified as absolute and not relative anymore. In order to get current time binuptime() or getbinuptime() is used, and a sysctl is introduced to selectively choose the function to use, based on a precision threshold. 5) A mechanism for specifying precision tolerance has been implemented. The callout processing mechanism has been adapted and the callout data structure augmented so that the codepath can take advantage and aggregate events which overlap in time. The new proposed KPI for callout is the following: callout_reset_bt_on(..., struct bintime time, struct bintime pr, ..., int flags) where ‘time’ argument represets the time at which the callout should fire, ‘pr’ represents the precision tolerance expressed as an absolute value, and ‘flags’, which could be used to specify new features, i.e. for now, the possibility to run the callout from fast interrupt context. The old KPI has been extended introducing the callout_reset_flags() function, which is the same of callout_reset*(), but takes an additional argument ‘int flags’ that can be used in the same fashion of the ‘flags’ argument for the new KPI. Using the ‘flags’ consumers can also specify relative precision tolerance in terms of power-of-two portion of the timeout passed as ticks. Using this strategy, the new precision mechanism can be used for the existing services without major modifications. Some consumers have been ported to the new KPI, in particular nanosleep(), poll(), select(), because they take immediate advantage from the arbitrary precision offered by the new infrastructure. For some statistics about the outcome of the conversion to the new service, please refer to the end of this e-mail: http://lists.freebsd.org/pipermail/freebsd-arch/2012-July/012756.html We didn't measure any significant performance regressions with hwmpc(4), using some benckmarks programs: http://people.freebsd.org/~davide/poll_test/poll_test.c http://people.freebsd.org/~mav/testsleep.c http://people.freebsd.org/~mav/testidle.c We tested the code on amd64, MIPS and arm. Any kind of testing or comment would be really appreciated. The full diff of the work against HEAD can be found at: http://people.freebsd.org/~davide/calloutng.diff If noone have objections, we plan to merge the repository to HEAD in a week or so. Thanks, Davide ___ 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 segfault 11 with KMS
Can you please try the attached patch, against x11-servers/xorg-server.
Apply it and recompile xorg-server with normal flags (that is, no
debugging) and let me and the list know the result when starting X.
Regards!
--
Niclas Zeising
Index: x11-servers/xorg-server/Makefile
===
--- x11-servers/xorg-server/Makefile (revision 308805)
+++ x11-servers/xorg-server/Makefile (working copy)
@@ -29,7 +29,8 @@
XORG_REVISION= 1
PLIST_SUB+= OLD=@comment NEW=
EXTRA_PATCHES+= ${FILESDIR}/extra-hw_dmx_glxProxy_compsize.h \
- ${FILESDIR}/extra-hw_dmx_glxProxy_glxcmds.h
+ ${FILESDIR}/extra-hw_dmx_glxProxy_glxcmds.h \
+ ${FILESDIR}/extra-clang
.else
XORG_VERSION= 1.7.7
XORG_REVISION= 6
Index: x11-servers/xorg-server/files/extra-clang
===
--- x11-servers/xorg-server/files/extra-clang (revision 0)
+++ x11-servers/xorg-server/files/extra-clang (working copy)
@@ -0,0 +1,53 @@
+--- hw/xfree86/common/xf86Xinput.c.orig 2012-12-13 23:58:55.673738569 +0100
hw/xfree86/common/xf86Xinput.c 2012-12-13 23:59:52.528738525 +0100
+@@ -479,7 +479,7 @@
+ MatchAttrToken(const char *attr, struct list *patterns,
+int (*compare)(const char *attr, const char *pattern))
+ {
+-const xf86MatchGroup *group;
++const xf86MatchGroup *group = NULL;
+
+ /* If there are no patterns, accept the match */
+ if (list_is_empty(patterns))
+--- hw/xfree86/parser/InputClass.c.orig 2012-12-14 00:03:07.149734651 +0100
hw/xfree86/parser/InputClass.c 2012-12-14 00:04:09.522735172 +0100
+@@ -338,7 +338,8 @@
+ XF86ConfInputClassPtr prev;
+
+ while (ptr) {
+-xf86MatchGroup *group, *next;
++xf86MatchGroup *group = NULL;
++xf86MatchGroup *next;
+ char **list;
+
+ TestFree(ptr-identifier);
+--- hw/xfree86/dri2/dri2.c.orig 2012-12-14 00:06:39.680738243 +0100
hw/xfree86/dri2/dri2.c 2012-12-14 00:08:14.310729622 +0100
+@@ -201,7 +201,7 @@
+ static DRI2DrawableRefPtr
+ DRI2LookupDrawableRef(DRI2DrawablePtr pPriv, XID id)
+ {
+-DRI2DrawableRefPtr ref;
++DRI2DrawableRefPtr ref = NULL;
+
+ list_for_each_entry(ref, pPriv-reference_list, link) {
+ if (ref-id == id)
+@@ -267,7 +267,8 @@
+ {
+ DRI2DrawablePtr pPriv = p;
+ DRI2ScreenPtr ds = pPriv-dri2_screen;
+-DRI2DrawableRefPtr ref, next;
++DRI2DrawableRefPtr ref = NULL;
++DRI2DrawableRefPtr next;
+ WindowPtr pWin;
+ PixmapPtr pPixmap;
+ DrawablePtr pDraw;
+@@ -534,7 +535,7 @@
+ DRI2InvalidateDrawable(DrawablePtr pDraw)
+ {
+ DRI2DrawablePtr pPriv = DRI2GetDrawable(pDraw);
+-DRI2DrawableRefPtr ref;
++DRI2DrawableRefPtr ref = NULL;
+
+ if (!pPriv)
+ return;
___
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 segfault 11 with KMS
This patch work for me. Thanks. On Friday 14 December 2012 00:30:52 Niclas Zeising wrote: Can you please try the attached patch, against x11-servers/xorg-server. Apply it and recompile xorg-server with normal flags (that is, no debugging) and let me and the list know the result when starting X. Regards! -- This message is for the person(s) named above only and may contain privileged, proprietary, or otherwise private information. If you received this transmission in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. ___ 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 segfault 11 with KMS
On Thu, Dec 13, 2012 at 6:51 PM, Artyom Mirgorodskiy art...@ijminteractive.net wrote: This patch work for me. Thanks. I can confirm that it also works for me. Thanks a lot! On Friday 14 December 2012 00:30:52 Niclas Zeising wrote: Can you please try the attached patch, against x11-servers/xorg-server. Apply it and recompile xorg-server with normal flags (that is, no debugging) and let me and the list know the result when starting X. Regards! -- This message is for the person(s) named above only and may contain privileged, proprietary, or otherwise private information. If you received this transmission in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. ___ 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: r244036 kernel hangs under load.
Konstantin Belousov wrote: On Wed, Dec 12, 2012 at 10:01:39PM -0500, Rick Macklem wrote: Konstantin Belousov wrote: On Tue, Dec 11, 2012 at 08:58:47PM -0500, Rick Macklem wrote: Ok, I'll test r243598 and then r243599 and r243835, just to see if it really is this. I'll email when I have done this. If you test only r243598, I am sure that you would experience corruption. The r243599 should cause the deadlocks. I think you meant r243599 will result in corruptions and r243835 deadlocks. I have run r243598 for a while without a hang. (r243599 doesn't build) I haven't tried r243835 yet. Also, do you use the post-r244095 kernel ? Before and after. The most recent tests were post-r244095. (If anything the more recent kernels hang more easily.) Is your machine SMP ? Old, slow single core i386. Try this. Please note that this is mostly a debugging facility. It seemed to help, but didn't stop the hangs completely. r244125 without the patch would hang somewhere in a kernel build. r244125 plus this patch ran almost 2 kernel builds before it got hung. Can you try to look into the system state on the hang (on the kernel with the if (1 || patch applied) ? Using the ddb and recipe from the web page. Basically watch for a thread looping in the mnt_active iterator and threads owning vnode interlocks. Ok, there is only one process in the mnt_active iterator and its trace is as follows (syncer): dle+0x12d/frame 0xdfe33adc (I suspect the screen lost an 'I') intr_execute_handlers(c5e3d064,dfe33b20,0,dfe33b64,c0ec2115,...) at intr_execute_handlers+0x49/frame 0xdfe33afc lapic_handle_intr(3c,dfe33b20) at lapic_handle_intr+0x36/frame 0xdfe33b10 Xapic_isr1() at Xapic_isr1+0x35/frame 0xdfe33b10 --- interrupt, eip = 0xc0eca8db, esp = 0xdfe33b60, ebp = 0xdfe33b64 --- spinlock_exit(c128be90,4,c10b5017,130,1710,...) at spinlock_exit+0x2b/frame 0xdfe33b64 __mtx_unlock_spin_flags(c128be90,0,c10b80be,25d,0,...) at __mtx_unlock_spin_flags+0x112/frame 0xdfe33b90 kern_yield(,0,c10c75c9,127b,c8b05238,...) at kern_yield+0x125/frame 0xdfe33bbc __mnt_vnode_next_active(dfe33c08,c857ba80,c10c75c9,dac,5d7,...) at __mnt_vnode_next_active+0xda/frame 0xdfe33be0 vfs_msync(c857ba80,2,2,e6b,c857ba80,...) at vfs_msync+0x175/frame 0xdfe33c18 sync_fsync(dfe33ca8,c85cf470,80400,c10c75c9,6f4,...) at sync_fsync+0x141/frame 0xdfe33c64 VOP_FSYNC_APV(c12008a0,dfe33ca8,c10c75c9,6f4,4e20,...) at VOP_FSYNC_APV+0xb4/frame 0xdfe33c64 sched_sync(0,dfe33d08,c10b0e10,3db,c85395a0,...) at sched_sync+0x399/frame 0xdfe33cc8 fork_exit(c0b79420,0,dfe33d08) at fork_exit+0xc0/frame 0xdfe33cf4 fork_trampoline() at fork_trampoline+0x8/frame 0xdfe33cf4 --- trap 0, eip = 0, esp = 0xdfe33d40, ebp = 0 --- This process holds: exclusive lockmgr syncer (syncer) r = 0 (0xc85cf4c8) locked @ kern/vfs_subr.c:1780 The only other process that is doing anything in the VFS subsystem holds the vnode interlock. It's trace is: dle+0x12d/frame 0xdfe6a850 intr_execute_handlers(c5f721c0,dfe6a894,0,dfe6a908,c0ec2115,...) at intr_execute_handlers+0x49/frame 0xdfe6a870 lapic_handle_intr(31,dfe6a894) at lapic_handle_intr+0x36/frame 0xdfe6a884 Xapic_isr1() at Xapic_isr1+0x35/frame 0xdfe6a884 --- interrupt, eip = 0xc0b2206a, esp = 0xdfe6a8d4, ebp = 0xdfe6a908 --- witness_unlock(c8972a74,8,c10c75c9,965,0,...) at witness_unlock+0x3a/frame 0xdfe6a908 __mtx_unlock_flags(c8972a84,0,c10c75c9,965,c89729fc,...) at __mtx_unlock_flags+0x9f/frame 0xdfe6a938 vdropl(c89729fc,dfe6a974,c10c75c9,8e7,c1238020,...) at vdropl+0x63/frame 0xdfe6a95c vputx(dfe6aa04,c0b67acc,c89729fc,dfe6a9e4,dfe6abc4,...) at vputx+0x300/frame 0xdfe6a994 vput(c89729fc,dfe6a9e4,dfe6abc4,31d,dfe6a9e4,...) at vput+0x10/frame 0xdfe6a99c lookup(dfe6ab84,c857e000,0,ce,c13c83c8,...) at lookup+0x9bc/frame 0xdfe6aa04 namei(dfe6ab84,0,0,246,0,...) at namei+0x4fe/frame 0xdfe6aa80 vn_open_cred(dfe6ab84,dfe6ac24,1a4,0,c5dd4580,...) at vn_open_cred+0x2c0/frame 0xdfe6ab40 vn_open(dfe6ab84,dfe6ac24,1a4,c85922a0,c853a2d0,...) at vn_open+0x3b/frame 0xdfe6ab60 kern_openat(c85c55e0,ff9c,2882dcc0,0,8001,...) at kern_openat+0x1e2/frame 0xdfe6ac0c kern_open(c85c55e0,2882dcc0,0,8000,1b6,...) at kern_open+0x35/frame 0xdfe6ac2c sys_open(c85c55e0,dfe6accc,c02acde7,7307f55d,5e5b00,...) at sys_open+0x30/frame 0xdfe6ac48 syscall(dfe6ad08) at syscall+0x2e5/frame 0xdfe6acfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xdfe6acfc --- syscall (5, FreeBSD ELF32, sys_open), eip = 0x84a1667, esp = 0xbfbfcffc, ebp = 0xbfbfd018 --- The locks this process holds are: exclusive sleep mutex vnode interlock (vnode interlock) r = 0 (0x8972a74) locked @ kern/vfs_subr.c:2513 shared lockmgr ufs (ufs) r = 0 (0xc8bd181c) locked @ kern/vfs_subr.c:2161
Re: r244036 kernel hangs under load.
On Thu, Dec 13, 2012 at 10:14:29PM -0500, Rick Macklem wrote:
Good work. This patch seems to have done the trick. I've run
quite a few kernel build cycles without a hang. I'll keep running
them, but I would have expected to see a hang by now.
Maybe Tim can test the patch as well?
(I needed to add #include sys/smp.h btw.)
Below is the current version of the patch, it is being tested by Peter Holm.
Compared to what I sent you earlier, it contain a bug fix only relevant if
you use quotas.
diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c
index 67e078d..64d75fb 100644
--- a/sys/kern/vfs_subr.c
+++ b/sys/kern/vfs_subr.c
@@ -69,6 +69,7 @@ __FBSDID($FreeBSD$);
#include sys/reboot.h
#include sys/sched.h
#include sys/sleepqueue.h
+#include sys/smp.h
#include sys/stat.h
#include sys/sysctl.h
#include sys/syslog.h
@@ -4710,32 +4711,54 @@ __mnt_vnode_markerfree_all(struct vnode **mvp, struct
mount *mp)
* These are helper functions for filesystems to traverse their
* active vnodes. See MNT_VNODE_FOREACH_ACTIVE() in sys/mount.h
*/
-struct vnode *
-__mnt_vnode_next_active(struct vnode **mvp, struct mount *mp)
+static void
+mnt_vnode_markerfree_active(struct vnode **mvp, struct mount *mp)
+{
+
+ KASSERT((*mvp)-v_mount == mp, (marker vnode mount list mismatch));
+
+ MNT_ILOCK(mp);
+ MNT_REL(mp);
+ MNT_IUNLOCK(mp);
+ free(*mvp, M_VNODE_MARKER);
+ *mvp = NULL;
+}
+
+#ifdef SMP
+#defineALWAYS_YIELD(mp_ncpus == 1)
+#else
+#defineALWAYS_YIELD1
+#endif
+
+static struct vnode *
+mnt_vnode_next_active(struct vnode **mvp, struct mount *mp)
{
struct vnode *vp, *nvp;
- if (should_yield())
- kern_yield(PRI_UNCHANGED);
- mtx_lock(vnode_free_list_mtx);
-restart:
+ mtx_assert(vnode_free_list_mtx, MA_OWNED);
KASSERT((*mvp)-v_mount == mp, (marker vnode mount list mismatch));
+restart:
vp = TAILQ_NEXT(*mvp, v_actfreelist);
+ TAILQ_REMOVE(mp-mnt_activevnodelist, *mvp, v_actfreelist);
while (vp != NULL) {
if (vp-v_type == VMARKER) {
vp = TAILQ_NEXT(vp, v_actfreelist);
continue;
}
if (!VI_TRYLOCK(vp)) {
- if (should_yield()) {
+ if (ALWAYS_YIELD || should_yield()) {
+ TAILQ_INSERT_BEFORE(vp, *mvp, v_actfreelist);
mtx_unlock(vnode_free_list_mtx);
- kern_yield(PRI_UNCHANGED);
+ kern_yield(PRI_USER);
mtx_lock(vnode_free_list_mtx);
+ goto restart;
}
- goto restart;
+ continue;
}
- if (vp-v_mount == mp vp-v_type != VMARKER
- (vp-v_iflag VI_DOOMED) == 0)
+ KASSERT(vp-v_type != VMARKER, (locked marker %p, vp));
+ KASSERT(vp-v_mount == mp || vp-v_mount == NULL,
+ (alien vnode on the active list %p %p, vp, mp));
+ if (vp-v_mount == mp (vp-v_iflag VI_DOOMED) == 0)
break;
nvp = TAILQ_NEXT(vp, v_actfreelist);
VI_UNLOCK(vp);
@@ -4745,22 +4768,31 @@ restart:
/* Check if we are done */
if (vp == NULL) {
mtx_unlock(vnode_free_list_mtx);
- __mnt_vnode_markerfree_active(mvp, mp);
- mtx_assert(MNT_MTX(mp), MA_NOTOWNED);
+ mnt_vnode_markerfree_active(mvp, mp);
return (NULL);
}
- TAILQ_REMOVE(mp-mnt_activevnodelist, *mvp, v_actfreelist);
TAILQ_INSERT_AFTER(mp-mnt_activevnodelist, vp, *mvp, v_actfreelist);
mtx_unlock(vnode_free_list_mtx);
ASSERT_VI_LOCKED(vp, active iter);
KASSERT((vp-v_iflag VI_ACTIVE) != 0, (Non-active vp %p, vp));
return (vp);
}
+#undef ALWAYS_YIELD
+
+struct vnode *
+__mnt_vnode_next_active(struct vnode **mvp, struct mount *mp)
+{
+
+ if (should_yield())
+ kern_yield(PRI_UNCHANGED);
+ mtx_lock(vnode_free_list_mtx);
+ return (mnt_vnode_next_active(mvp, mp));
+}
struct vnode *
__mnt_vnode_first_active(struct vnode **mvp, struct mount *mp)
{
- struct vnode *vp, *nvp;
+ struct vnode *vp;
*mvp = malloc(sizeof(struct vnode), M_VNODE_MARKER, M_WAITOK | M_ZERO);
MNT_ILOCK(mp);
@@ -4770,44 +4802,14 @@ __mnt_vnode_first_active(struct vnode **mvp, struct
mount *mp)
(*mvp)-v_mount = mp;
mtx_lock(vnode_free_list_mtx);
-restart:
vp = TAILQ_FIRST(mp-mnt_activevnodelist);
- while (vp != NULL) {
- if (vp-v_type == VMARKER) {
- vp = TAILQ_NEXT(vp, v_actfreelist);
- continue;
- }
- if (!VI_TRYLOCK(vp)) {
-
[head tinderbox] failure on i386/i386
TB --- 2012-12-13 22:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-13 22:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-13 22:40:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-12-13 22:40:00 - cleaning the object tree TB --- 2012-12-13 22:40:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-13 22:40:00 - cd /tinderbox/HEAD/i386/i386 TB --- 2012-12-13 22:40:00 - /usr/local/bin/svn cleanup /src TB --- 2012-12-13 22:43:23 - /usr/local/bin/svn update /src TB --- 2012-12-13 22:43:44 - At svn revision 244194 TB --- 2012-12-13 22:43:45 - building world TB --- 2012-12-13 22:43:45 - CROSS_BUILD_TESTING=YES TB --- 2012-12-13 22:43:45 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-13 22:43:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-13 22:43:45 - SRCCONF=/dev/null TB --- 2012-12-13 22:43:45 - TARGET=i386 TB --- 2012-12-13 22:43:45 - TARGET_ARCH=i386 TB --- 2012-12-13 22:43:45 - TZ=UTC TB --- 2012-12-13 22:43:45 - __MAKE_CONF=/dev/null TB --- 2012-12-13 22:43:45 - cd /src TB --- 2012-12-13 22:43:45 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Dec 13 22:43:57 UTC 2012 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Fri Dec 14 01:57:37 UTC 2012 TB --- 2012-12-14 01:57:37 - generating LINT kernel config TB --- 2012-12-14 01:57:37 - cd /src/sys/i386/conf TB --- 2012-12-14 01:57:37 - /usr/bin/make -B LINT TB --- 2012-12-14 01:57:37 - cd /src/sys/i386/conf TB --- 2012-12-14 01:57:37 - /usr/sbin/config -m LINT TB --- 2012-12-14 01:57:37 - building LINT kernel TB --- 2012-12-14 01:57:37 - CROSS_BUILD_TESTING=YES TB --- 2012-12-14 01:57:37 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-14 01:57:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-14 01:57:37 - SRCCONF=/dev/null TB --- 2012-12-14 01:57:37 - TARGET=i386 TB --- 2012-12-14 01:57:37 - TARGET_ARCH=i386 TB --- 2012-12-14 01:57:37 - TZ=UTC TB --- 2012-12-14 01:57:37 - __MAKE_CONF=/dev/null TB --- 2012-12-14 01:57:37 - cd /src TB --- 2012-12-14 01:57:37 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Fri Dec 14 01:57:37 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Fri Dec 14 02:31:38 UTC 2012 TB --- 2012-12-14 02:31:38 - cd /src/sys/i386/conf TB --- 2012-12-14 02:31:38 - /usr/sbin/config -m LINT-NOINET TB --- 2012-12-14 02:31:38 - building LINT-NOINET kernel TB --- 2012-12-14 02:31:38 - CROSS_BUILD_TESTING=YES TB --- 2012-12-14 02:31:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-14 02:31:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-14 02:31:38 - SRCCONF=/dev/null TB --- 2012-12-14 02:31:38 - TARGET=i386 TB --- 2012-12-14 02:31:38 - TARGET_ARCH=i386 TB --- 2012-12-14 02:31:38 - TZ=UTC TB --- 2012-12-14 02:31:38 - __MAKE_CONF=/dev/null TB --- 2012-12-14 02:31:38 - cd /src TB --- 2012-12-14 02:31:38 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Fri Dec 14 02:31:38 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Fri Dec 14 03:02:33 UTC 2012 TB --- 2012-12-14 03:02:33 - cd /src/sys/i386/conf TB --- 2012-12-14 03:02:33 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-12-14 03:02:33 - building LINT-NOINET6 kernel TB --- 2012-12-14 03:02:33 - CROSS_BUILD_TESTING=YES TB --- 2012-12-14 03:02:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-14 03:02:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-14 03:02:33 - SRCCONF=/dev/null TB --- 2012-12-14 03:02:33 - TARGET=i386 TB --- 2012-12-14 03:02:33 - TARGET_ARCH=i386 TB --- 2012-12-14 03:02:33 - TZ=UTC TB --- 2012-12-14 03:02:33 - __MAKE_CONF=/dev/null TB --- 2012-12-14 03:02:33 - cd /src TB --- 2012-12-14 03:02:33 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Fri Dec 14 03:02:34 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET6 completed on Fri Dec 14 03:32:41 UTC 2012 TB --- 2012-12-14 03:32:41 - cd /src/sys/i386/conf TB ---
[head tinderbox] failure on amd64/amd64
TB --- 2012-12-13 22:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-13 22:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-13 22:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-12-13 22:40:00 - cleaning the object tree TB --- 2012-12-13 22:40:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-13 22:40:00 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2012-12-13 22:40:00 - /usr/local/bin/svn cleanup /src TB --- 2012-12-13 22:43:58 - /usr/local/bin/svn update /src TB --- 2012-12-13 22:44:11 - At svn revision 244194 TB --- 2012-12-13 22:44:12 - building world TB --- 2012-12-13 22:44:12 - CROSS_BUILD_TESTING=YES TB --- 2012-12-13 22:44:12 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-13 22:44:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-13 22:44:12 - SRCCONF=/dev/null TB --- 2012-12-13 22:44:12 - TARGET=amd64 TB --- 2012-12-13 22:44:12 - TARGET_ARCH=amd64 TB --- 2012-12-13 22:44:12 - TZ=UTC TB --- 2012-12-13 22:44:12 - __MAKE_CONF=/dev/null TB --- 2012-12-13 22:44:12 - cd /src TB --- 2012-12-13 22:44:12 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Dec 13 22:44:20 UTC 2012 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Fri Dec 14 02:36:03 UTC 2012 TB --- 2012-12-14 02:36:03 - generating LINT kernel config TB --- 2012-12-14 02:36:03 - cd /src/sys/amd64/conf TB --- 2012-12-14 02:36:03 - /usr/bin/make -B LINT TB --- 2012-12-14 02:36:04 - cd /src/sys/amd64/conf TB --- 2012-12-14 02:36:04 - /usr/sbin/config -m LINT TB --- 2012-12-14 02:36:04 - building LINT kernel TB --- 2012-12-14 02:36:04 - CROSS_BUILD_TESTING=YES TB --- 2012-12-14 02:36:04 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-14 02:36:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-14 02:36:04 - SRCCONF=/dev/null TB --- 2012-12-14 02:36:04 - TARGET=amd64 TB --- 2012-12-14 02:36:04 - TARGET_ARCH=amd64 TB --- 2012-12-14 02:36:04 - TZ=UTC TB --- 2012-12-14 02:36:04 - __MAKE_CONF=/dev/null TB --- 2012-12-14 02:36:04 - cd /src TB --- 2012-12-14 02:36:04 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Fri Dec 14 02:36:04 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Fri Dec 14 03:08:06 UTC 2012 TB --- 2012-12-14 03:08:06 - cd /src/sys/amd64/conf TB --- 2012-12-14 03:08:06 - /usr/sbin/config -m LINT-NOINET TB --- 2012-12-14 03:08:06 - building LINT-NOINET kernel TB --- 2012-12-14 03:08:06 - CROSS_BUILD_TESTING=YES TB --- 2012-12-14 03:08:06 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-14 03:08:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-14 03:08:06 - SRCCONF=/dev/null TB --- 2012-12-14 03:08:06 - TARGET=amd64 TB --- 2012-12-14 03:08:06 - TARGET_ARCH=amd64 TB --- 2012-12-14 03:08:06 - TZ=UTC TB --- 2012-12-14 03:08:06 - __MAKE_CONF=/dev/null TB --- 2012-12-14 03:08:06 - cd /src TB --- 2012-12-14 03:08:06 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Fri Dec 14 03:08:06 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Fri Dec 14 03:36:54 UTC 2012 TB --- 2012-12-14 03:36:54 - cd /src/sys/amd64/conf TB --- 2012-12-14 03:36:54 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-12-14 03:36:54 - building LINT-NOINET6 kernel TB --- 2012-12-14 03:36:54 - CROSS_BUILD_TESTING=YES TB --- 2012-12-14 03:36:54 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-14 03:36:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-14 03:36:54 - SRCCONF=/dev/null TB --- 2012-12-14 03:36:54 - TARGET=amd64 TB --- 2012-12-14 03:36:54 - TARGET_ARCH=amd64 TB --- 2012-12-14 03:36:54 - TZ=UTC TB --- 2012-12-14 03:36:54 - __MAKE_CONF=/dev/null TB --- 2012-12-14 03:36:54 - cd /src TB --- 2012-12-14 03:36:54 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Fri Dec 14 03:36:55 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET6 completed on Fri Dec 14 04:06:21 UTC 2012 TB
Re: [RFC/RFT] calloutng
On Fri, Dec 14, 2012 at 12:12 AM, Davide Italiano dav...@freebsd.orgwrote:
Hi.
This patch takes callout(9) and redesign the KPI and the
implementation. The main objective of this work is making the
subsystem tickless. In the last several years, this possibility has
been discussed widely (http://markmail.org/message/q3xmr2ttlzpqkmae),
but until now noone really implemented that.
If you want a complete history of what has been done in the last
months you can check the calloutng project repository
http://svnweb.freebsd.org/base/projects/calloutng/
For lazy people, here's a summary:
thanks for the work and the detailed summary.
Perhaps it would be useful if you could provide a few high level
details on the use and performance of the new scheme, such as:
- is the old callout KPI still available ? (i am asking because it would
help maintaining third party kernel modules that are expected to
work on different FreeBSD releases)
- do you have numbers on what is the fastest rate at which callouts
can be fired (e.g. say you have a callout which increments a
counter and schedules the next callout in (struct bintime){0,1} ) ?
- is there a possibility that if callout requests are too close to each
other (e.g. the above test) the thread dispatching callouts will
run forever ? if so, is there a way to make such thread yield
after a while ?
- since you mentioned nanosleep() poll() and select() have been
ported to the new callout, is there a way to guarantee that user
using these functions with a very short timeout are actually
descheduled as opposed to interval too short, don't bother ?
- do you have numbers on how many calls per second we can
have for a process that does
for (;;) { nanosleep(min_value_that_causes_descheduling);
I also have some comments on the diff:
- can you provide a diff -p ?
- for several functions the only change is the name of an argument
from busy to us. Can you elaborate the reason for the change,
and whether us means microseconds or the pronoun ?)
Finally, a more substantial comment:
- a lot of functions which formerly had only a timo argument
now have timo, bt, precision, flags. Take seltdwait() as an example.
It seems that you have been undecided between two approaches:
for some of these functions you have preserved the original function
that deals with ticks and introduced a new one that deals with the
bintime,
whereas in other cases you have modified the original function to add
bt, precision, flags.
I would suggest a more uniform approach, namely:
- preserve all the existing functions (T) that take a timeout in ticks;
- add a new set of corresponding functions (BT) that take
bt, precision, flags _instead_ of the ticks
- the functions (T) make immediately the conversion from ticks to
bintime(s), using macros or inline
- optionally, convert kernel components to the new (BT) functions
where this makes sense (e.g. we can exploit the finer-granularity
of the new calls, etc.)
cheers
luigi
1) callout(9) is not anymore constrained to the resolution a periodic
hz clock can give. In order to do that, the eventtimers(4) subsystem
is used as backend.
2) Conversely from what discussed in past, we maintained the callwheel
as underlying data structure for keeping track of the outstading
timeouts. This choice has a couple of advantages, in particular we can
still take benefits from the O(1) average complexity of the wheel for
all the operations. Also, we thought the code duplication that would
arise from the use of a two-staged backend for callout (e.g. use wheel
for coarse resolution event and another data structure, such as an
heap for high resolution events), is unacceptable. In fact, as long as
callout gained the ability to migrate from a cpu to another having a
double backend would mean doubling the code for the migration path.
3) A way to dispatch interrupts from hardware interrupt context has
been implemented, using special callout flag. This has limited
applicability, but avoid the dispatching of a SWI thread for handling
specific callouts, avoiding the wake up of another CPU for processing
and a (relatively useless) context switch
4) As long as new callout mechanism deals with bintime and not anymore
with ticks, time is specified as absolute and not relative anymore. In
order to get current time binuptime() or getbinuptime() is used, and a
sysctl is introduced to selectively choose the function to use, based
on a precision threshold.
5) A mechanism for specifying precision tolerance has been
implemented. The callout processing mechanism has been adapted and the
callout data structure augmented so that the codepath can take
advantage and aggregate events which overlap in time.
The new proposed KPI for callout is the following:
callout_reset_bt_on(..., struct bintime time, struct bintime pr, ..., int
flags)
where ‘time’ argument represets the time at which the callout
