Re: Change in loader or kernel: won't boot with kfreebsd in grub2
Some updates: I could see what happens if I try to boot the FreeBSD boot partition on the hard drive using the Super Grub Disk with chainloader. If that works, it would boot FreeBSD 9.0-BETA1, but I would see if it works. That failed (invalid signature). I could also try kfreebsd /boot/kernel/kernel That failed to boot the proper partition, went to the debugger (db>), whereupon all I could type was "reboot". Now can I safely install boot into the partition to be booted, as I did with NetBSD on USB stick? gpart -p /boot/boot -i 3 That would be for /dev/ada0p3, but I am afraid of damaging something. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: NFS deadlock on 9.2-Beta1
Kostik wrote:
> On Sat, Aug 24, 2013 at 01:08:05PM -0400, J David wrote:
> > The requested information about the deadlock was finally obtained
> > and
> > provided off-list to the requested parties due to size.
>
> Thank you, the problem is clear now.
>
> The problematic process backtrace is
>
> Tracing command httpd pid 86383 tid 100138 td 0xfe000b7b2900
> sched_switch() at sched_switch+0x234/frame 0xff834c442360
> mi_switch() at mi_switch+0x15c/frame 0xff834c4423a0
> sleepq_switch() at sleepq_switch+0x17d/frame 0xff834c4423e0
> sleepq_wait() at sleepq_wait+0x43/frame 0xff834c442410
> sleeplk() at sleeplk+0x11a/frame 0xff834c442460
> __lockmgr_args() at __lockmgr_args+0x9a9/frame 0xff834c442580
> nfs_lock1() at nfs_lock1+0x87/frame 0xff834c4425b0
> VOP_LOCK1_APV() at VOP_LOCK1_APV+0xbe/frame 0xff834c4425e0
> _vn_lock() at _vn_lock+0x63/frame 0xff834c442640
> ncl_upgrade_vnlock() at ncl_upgrade_vnlock+0x5e/frame
> 0xff834c442670
> ncl_bioread() at ncl_bioread+0x195/frame 0xff834c4427e0
> VOP_READ_APV() at VOP_READ_APV+0xd1/frame 0xff834c442810
> vn_rdwr() at vn_rdwr+0x2bc/frame 0xff834c4428d0
> kern_sendfile() at kern_sendfile+0xa90/frame 0xff834c442ac0
> do_sendfile() at do_sendfile+0x92/frame 0xff834c442b20
> amd64_syscall() at amd64_syscall+0x259/frame 0xff834c442c30
> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xff834c442c30
> --- syscall (393, FreeBSD ELF64, sys_sendfile), rip = 0x801b24f4c,
> rsp = 0x7fffce98, rbp = 0x7fffd1d0 ---
>
> It tries to do the upgrade of the nfs vnode lock, and for this, the
> lock
> is dropped and re-acquired. Since this happens with the vnode vm
> object'
> page busied, we get a reversal between vnode lock and page busy
> state.
> So effectively, my suspicion that NFS read path drops vnode lock was
> true, and in fact I knew about the upgrade.
>
Ouch. I had forgotten that LK_UPGRADE could result in the shared lock
being dropped.
I'll admit I've never liked the lock upgrade in nfs_read(), but I'm
not sure how to avoid it. I just looked at the commit log message
for r138469, which is where this appeared in the old NFS client.
(The new NFS client just cloned this code.)
It basically notes that with a shared lock, new pages can be faulted
in for the vnode while vinvalbuf() is in progress, causing it to fail
(I suspect "fail" means never completed?).
At the very least, I don't think the lock upgrade is needed unless
a call to vinvalbuf() is going to be done. (I'm wondering is a dedicated
lock used to serialize this case might be better than using a node LK_UPGRADE?)
I think I'll take a closer look at the vinvalbuf() code in head.
Do others have any comments on this? (I added jhb@ to the cc list, since he
may be familiar with this?)
But none of this can happen quickly, so it wouldn't be feasible for stable/9
or even 10.0 at this point in time.
rick
> I think the easiest route is to a partial merge of the r253927 from
> HEAD.
>
> Index: fs
> ===
> --- fs(revision 254800)
> +++ fs(working copy)
>
> Property changes on: fs
> ___
> Modified: svn:mergeinfo
>Merged /head/sys/fs:r253927
> Index: kern/uipc_syscalls.c
> ===
> --- kern/uipc_syscalls.c (revision 254800)
> +++ kern/uipc_syscalls.c (working copy)
> @@ -2124,11 +2124,6 @@
> else {
> ssize_t resid;
>
> - /*
> - * Ensure that our page is still around
> - * when the I/O completes.
> - */
> - vm_page_io_start(pg);
> VM_OBJECT_UNLOCK(obj);
>
> /*
> @@ -2144,10 +2139,8 @@
> IO_VMIO | ((MAXBSIZE / bsize) <<
> IO_SEQSHIFT),
> td->td_ucred, NOCRED, &resid, td);
> VFS_UNLOCK_GIANT(vfslocked);
> - VM_OBJECT_LOCK(obj);
> - vm_page_io_finish(pg);
> - if (!error)
> - VM_OBJECT_UNLOCK(obj);
> + if (error)
> + VM_OBJECT_LOCK(obj);
> mbstat.sf_iocnt++;
> }
> if (error) {
> Index: .
> ===
> --- . (revision 254800)
> +++ . (working copy)
>
> Property changes on: .
> ___
> Modified: svn:mergeinfo
>Merged /head/sys:r253927
>
___
freebsd-stable@freebsd.org
Re: NFS deadlock on 9.2-Beta1
On Sat, Aug 24, 2013 at 4:55 PM, Konstantin Belousov wrote: > On Sat, Aug 24, 2013 at 04:11:09PM -0400, J David wrote: >> On Sat, Aug 24, 2013 at 3:38 PM, Konstantin Belousov >> wrote: >> > No, at least not without reverting the r254754 first. The IGN_SBUSY patch >> > is not critical there. >> >> There is lots of other stuff in r250907 / reverted by r254754. Some >> of it looks important for sendfile() performance. If testing this >> extensively in the next few days could help get that work back into >> 9.2 we are happy to do it, but if it's too late then we can leave it >> for those on stable/9. > > The revert in the r254754 is only a workaround for your workload, it does > not fix the real issue, which can be reproduced by other means. > > I am not sure would re allow to merge the proper fix, since we are already > somewhere in RC3. Well, let's ask them. :) Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: NFS deadlock on 9.2-Beta1
On Sat, Aug 24, 2013 at 04:11:09PM -0400, J David wrote: > On Sat, Aug 24, 2013 at 3:38 PM, Konstantin Belousov > wrote: > > No, at least not without reverting the r254754 first. The IGN_SBUSY patch > > is not critical there. > > There is lots of other stuff in r250907 / reverted by r254754. Some > of it looks important for sendfile() performance. If testing this > extensively in the next few days could help get that work back into > 9.2 we are happy to do it, but if it's too late then we can leave it > for those on stable/9. The revert in the r254754 is only a workaround for your workload, it does not fix the real issue, which can be reproduced by other means. I am not sure would re allow to merge the proper fix, since we are already somewhere in RC3. pgpLSIemB6rTj.pgp Description: PGP signature
Re: NFS deadlock on 9.2-Beta1
On Sat, Aug 24, 2013 at 3:38 PM, Konstantin Belousov wrote: > No, at least not without reverting the r254754 first. The IGN_SBUSY patch > is not critical there. There is lots of other stuff in r250907 / reverted by r254754. Some of it looks important for sendfile() performance. If testing this extensively in the next few days could help get that work back into 9.2 we are happy to do it, but if it's too late then we can leave it for those on stable/9. Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [HEADS UP] change in devfs path matching logic
Hello! On Fri, 23 Aug 2013 Andriy Gapon wrote: This change is about to be MFC-ed. on 26/07/2013 17:39 Andriy Gapon said the following: I have just committed a significant change to devfs path matching logic http://svnweb.freebsd.org/changeset/base/253677 I just rebuilt my 8-STABLE i386 system to r254796 and now receive a kernel panic on boot. If I remove my /etc/devfs.rules file, the panic does not happen. Can anyone point out what is wrong with my devfs.rules what the new path matching logic doesn't like? $ cat /etc/devfs.rules.old [localrules=10] add path "da*" mode 0660 group operator add path "usb/1.2.0" mode 0660 group uucp add path "usb/4.3.0" mode 0660 group operator The panic, as transcribed from screen: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code= supervisor read, page not present instruction pointer = 0x20:0xc06dde21 stack pointer = 0x28:0xe8690a48 frame pointer = 0x28:0xe8690a80 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, iopl = 0 current process = 577 (ln) trap number = 12 panic: page fault KDB: stack backtrace: #0 0xc0670ece at kdb_backtrace+0x50 #1 0xc06449fa at panic+0x132 #2 0xc07eb1d2 at trap_fatal+0x21e #3 0xc07eb4e0 at trap_pfault+0x1c2 #4 0xc07ec251 at trap+0x3c1 #5 0xc07d95fc at calltrap+0x6 #6 0xc05c7001 at devfs_rule_run+0x13d #7 0xc05c70c3 at devfs_ruleset_applyde+0x25 #8 0xc05c71b3 at devfs_rules_apply+0x73 #9 0xc05cad51 at devfs_symlink+0x124 #10 0xc080d084 at VOP_SYMLINK_APV+0x4a #11 0xc06d2985 at kern_symlinkat+0x38b #12 0xc06d29da at kern_symlink+0x2e #13 0xc06d2a05 at symlink+0x29 #14 0xc07eb7c7 at syscall+0x1a1 #15 0xc07d9661 at Xint0x80_syscall+0x21 Thanks in advance! -- Toomas Aas Tartu linnakantselei arvutivõrgu peaspetsialist tel 736 1274 mob 513 6493 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: NFS deadlock on 9.2-Beta1
On Sat, Aug 24, 2013 at 02:03:50PM -0400, J David wrote: > On Sat, Aug 24, 2013 at 1:41 PM, Konstantin Belousov > wrote: > > I think the easiest route is to a partial merge of the r253927 from HEAD. > > Is it helpful if we restart testing releng/9.2 using your suggested > fix? And if so, the IGN_SBUSY patch you posted earlier be applied as > well or no? No, at least not without reverting the r254754 first. The IGN_SBUSY patch is not critical there. > > If it ran successfully on a bunch of machines for next few days, maybe > that would still be in time to be useful feedback for 9.2. > > Thanks! pgp3JVF_QAbg0.pgp Description: PGP signature
Re: NFS deadlock on 9.2-Beta1
On Sat, Aug 24, 2013 at 1:41 PM, Konstantin Belousov wrote: > I think the easiest route is to a partial merge of the r253927 from HEAD. Is it helpful if we restart testing releng/9.2 using your suggested fix? And if so, the IGN_SBUSY patch you posted earlier be applied as well or no? If it ran successfully on a bunch of machines for next few days, maybe that would still be in time to be useful feedback for 9.2. Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: NFS deadlock on 9.2-Beta1
On Sat, Aug 24, 2013 at 01:08:05PM -0400, J David wrote:
> The requested information about the deadlock was finally obtained and
> provided off-list to the requested parties due to size.
Thank you, the problem is clear now.
The problematic process backtrace is
Tracing command httpd pid 86383 tid 100138 td 0xfe000b7b2900
sched_switch() at sched_switch+0x234/frame 0xff834c442360
mi_switch() at mi_switch+0x15c/frame 0xff834c4423a0
sleepq_switch() at sleepq_switch+0x17d/frame 0xff834c4423e0
sleepq_wait() at sleepq_wait+0x43/frame 0xff834c442410
sleeplk() at sleeplk+0x11a/frame 0xff834c442460
__lockmgr_args() at __lockmgr_args+0x9a9/frame 0xff834c442580
nfs_lock1() at nfs_lock1+0x87/frame 0xff834c4425b0
VOP_LOCK1_APV() at VOP_LOCK1_APV+0xbe/frame 0xff834c4425e0
_vn_lock() at _vn_lock+0x63/frame 0xff834c442640
ncl_upgrade_vnlock() at ncl_upgrade_vnlock+0x5e/frame 0xff834c442670
ncl_bioread() at ncl_bioread+0x195/frame 0xff834c4427e0
VOP_READ_APV() at VOP_READ_APV+0xd1/frame 0xff834c442810
vn_rdwr() at vn_rdwr+0x2bc/frame 0xff834c4428d0
kern_sendfile() at kern_sendfile+0xa90/frame 0xff834c442ac0
do_sendfile() at do_sendfile+0x92/frame 0xff834c442b20
amd64_syscall() at amd64_syscall+0x259/frame 0xff834c442c30
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xff834c442c30
--- syscall (393, FreeBSD ELF64, sys_sendfile), rip = 0x801b24f4c, rsp =
0x7fffce98, rbp = 0x7fffd1d0 ---
It tries to do the upgrade of the nfs vnode lock, and for this, the lock
is dropped and re-acquired. Since this happens with the vnode vm object'
page busied, we get a reversal between vnode lock and page busy state.
So effectively, my suspicion that NFS read path drops vnode lock was
true, and in fact I knew about the upgrade.
I think the easiest route is to a partial merge of the r253927 from HEAD.
Index: fs
===
--- fs (revision 254800)
+++ fs (working copy)
Property changes on: fs
___
Modified: svn:mergeinfo
Merged /head/sys/fs:r253927
Index: kern/uipc_syscalls.c
===
--- kern/uipc_syscalls.c(revision 254800)
+++ kern/uipc_syscalls.c(working copy)
@@ -2124,11 +2124,6 @@
else {
ssize_t resid;
- /*
-* Ensure that our page is still around
-* when the I/O completes.
-*/
- vm_page_io_start(pg);
VM_OBJECT_UNLOCK(obj);
/*
@@ -2144,10 +2139,8 @@
IO_VMIO | ((MAXBSIZE / bsize) <<
IO_SEQSHIFT),
td->td_ucred, NOCRED, &resid, td);
VFS_UNLOCK_GIANT(vfslocked);
- VM_OBJECT_LOCK(obj);
- vm_page_io_finish(pg);
- if (!error)
- VM_OBJECT_UNLOCK(obj);
+ if (error)
+ VM_OBJECT_LOCK(obj);
mbstat.sf_iocnt++;
}
if (error) {
Index: .
===
--- . (revision 254800)
+++ . (working copy)
Property changes on: .
___
Modified: svn:mergeinfo
Merged /head/sys:r253927
pgp75rUqLWx27.pgp
Description: PGP signature
Re: NFS deadlock on 9.2-Beta1
The requested information about the deadlock was finally obtained and provided off-list to the requested parties due to size. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: wpi fatal firmware error with country de
On Mon, Aug 19, 2013 at 12:27:04AM +0200, Dominic Fandrey wrote: > On 19/08/2013 00:13, Adrian Chadd wrote: > > That's really odd. But then, it's a firmware driven NIC, who knows what > > kind of weird crap is going on under the hood. > > Yes, it's a black box. So how do I get in contact with intel support and > dump that in their laps? > > > Maybe you could experiment by looking at what changing the regulatory > > domain does when programming the firmware and see if it's a channel thing, > > a regulatory domain thing or something else. > > It looks like anything that results in regdomain FCC is all right. > Everything else blows up. I've reported the same issue nearly a year ago: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/172706 If you get to find additional information, please add it to the PR so it doesn't get lost. I didn't actually find any way to fix it. Regards. Victor. -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
