Re: Heavy I/O blocks FreeBSD box for several seconds
on 26/07/2011 00:44 Rick Macklem said the following: > hrs sent me this panic. I'm wondering if it might be relevant to this? To 'this' what? A panic is a panic. > spin lock 0x80cb52c0 (sched lock 1) held by 0xff0012c7f8c0 (tid > 100317) too long > panic: spin lock held too long I guess it's more related to the thread on stable@ which has the panic message as its subject. > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > kdb_backtrace() at kdb_backtrace+0x37 > panic() at panic+0x187 > _mtx_lock_spin_failed() at _mtx_lock_spin_failed+0x39 > _mtx_lock_spin() at _mtx_lock_spin+0x9e > sched_add() at sched_add+0x117 > setrunnable() at setrunnable+0x78 > sleepq_signal() at sleepq_signal+0x7a > cv_signal() at cv_signal+0x3b > xprt_active() at xprt_active+0xe3 > svc_vc_soupcall() at svc_vc_soupcall+0xc > sowakeup() at sowakeup+0x69 > tcp_do_segment() at tcp_do_segment+0x2cbd > tcp_input() at tcp_input+0xcdd > ip_input() at ip_input+0xac > netisr_dispatch_src() at netisr_dispatch_src+0x7e > ether_demux() at ether_demux+0x14d > ether_input() at ether_input+0x17d > em_rxeof() at em_rxeof+0x1ca > em_handle_que() at em_handle_que+0x5b > taskqueue_run_locked() at taskqueue_run_locked+0x85 > taskqueue_thread_loop() at taskqueue_thread_loop+0x4e > fork_exit() at fork_exit+0x11f > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xff8000160d00, rbp = 0 --- > KDB: enter: panic > [thread pid 0 tid 100033 ] > Stopped at kdb_enter+0x3b: movq$0,0x6b4e62(%rip) > db> ps > -- 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: ichwd0: unable to reserve GCS registers
On Saturday, July 30, 2011 02:49:52 AM Andriy Gapon wrote: > on 19/07/2011 18:16 John Baldwin said the following: > > Hmm, can you get devinfo -r output from a working kernel with ichwd > > loaded? You might be able to just build the kernel with 'nooptions > > NEW_PCIB'. > > I believe that I've got a similar problem with amdsbwd(4). > It needs some resources (I/O ports) that belong to ACPI. > The problem is that the driver attaches to isa bus which is under > isab->pci->pcib and those particular resources are not assigned to the > Host-PCI bridge. > > I think that you already made a suggestion that perhaps isa bus should > directly attach to acpi bus when acpi is available. Not sure if there are > any alternative approaches. Actually, my suggestion was the other way around (we should move certain ACPI devices down behind isab so they are behind the Host-PCI bridge as they are in hardware). In this case the BIOS clearly does not list the reosurces for the GCS as valid resources for the Host-PCI bridge. This is part of the reason that I added the 'debug.acpi.disable="hostres"'. One thing we may be able to do is allow non-wildcard requests that are outside the range to still pass if they are in ACPI's system resource range perhaps. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] updated /etc/rc.d/jail and added ZFS support
On Thu, 28 Jul 2011 16:11:37 +0200 Martin Matuska wrote: > The attached patch allows better fine-tuning of jails started via > /etc/rc.d, uses the new jail(8) flags (-c -m), the persist parameter > and adds ZFS support. > Patch is fully backward compatible. > > Please review, comment and/or test my attached patch. Can you please have a look at the jail part of http://www.leidinger.net/FreeBSD/current-patches/etc:rc.d.diff and take some parts which you didn't take care about (jailname/securelevel/correctness check for fstab entries)? Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] updated /etc/rc.d/jail and added ZFS support
Yes, that looks good. It keeps what I'd call expected behavior for
persist (at least on the startup side).
- Jamie
On 07/29/11 14:53, Martin Matuska wrote:
So what do you think about this updated patch (attached)?
Here we leave everything possible for jail_example_params.
Btw. you can also set jid=xxx in params to have a "static" jail id for
this jail.
Also stopping a persistent jail doesn't delete it (but you cannot start
it again).
Dňa 28. 7. 2011 20:47, Jamie Gritton wrote / napísal(a):
Yes, it was intentional to move away from the global sysctls and to
the per-jail parameters instead. It makes more sense once config
files come into play, which can do a better job of providing global
defaults as well as per-jail parameters.
The connection between ZFS and persist makes sense. So for ZFS-based
jail you'd want to set (and then reset) persist. For others, this
could be left to the user. The changes to jail(8) for config files
also sets persist when creating jails, and then clears it at a later
stage unless the user specifies to keep it set. It looks like I might
want to add some ZFS support to the new jail(8).
I would prefer to keep things simpler regarding create/start and
remove/stop, and keep them tied together.
- Jamie
On 07/28/11 12:00, Martin Matuska wrote:
If you start jail(8) witth "-c" (the new "param" way,) the values of the
actual security.jail. variables are not initialized inside the jail,
default values are used instead. I don't know if this is intentional,
but probably yes. Default enforce_statfs=2, allow.mount=0.
As of me we can leave everything for ${_params}, but then ${_zfs} makes
sense only if enforce_statfs<2 and allow.mount=1.
Regarding zfs, if you want to operate zfs from the very start of a jail
(and e.g. make use of /etc/rc.d/zfs which has jail support), you have to
pair datasets with an existing jail. In simple words, you have to create
a process-less jail (persist=1), attach zfs datasets and then run the
command. The persist option can be made optional - but we always start
with persist=1, then we can set (or not) persist=0 depending on user
setting.
The question that opens, should we remove a persisting jail on "stop"?
Or should we support new commands "create" and "remove" in addition to
"start" and "stop"? Create would just make a processless jail, remove
would wipe out a jail and start/stop would just deal with the processes
(if persist=0 the old way, of course)?
Cheers,
mm
Dňa 28. 7. 2011 18:25, Jamie Gritton wrote / napísal(a):
Since I missed the 9.0 boat with jail config file capability, something
like this seems necessary; rc.d/jail has long been unable to handle the
full scale of what jail(8) can do.
I gather that setting persist is necessary for the ZFS operation. As
long as we're making the parameter setting more generic from rc, we
should handle the case where persist is specified in ${_params}, and
not
always set/reset it around the jail creation unless ZFS is used.
Also, why the specific inclusion of the security-related parameters?
They could just be folded into ${_params}, and if left unspecified then
jail(8) should by default do the right thing.
- Jamie
On 07/28/11 08:11, Martin Matuska wrote:
The attached patch allows better fine-tuning of jails started via
/etc/rc.d, uses the new jail(8) flags (-c -m), the persist
parameter and
adds ZFS support.
Patch is fully backward compatible.
Please review, comment and/or test my attached patch.
Cheers,
mm
___
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: Heavy I/O blocks FreeBSD box for several seconds
Andriv Gapon wrote: > on 26/07/2011 00:44 Rick Macklem said the following: > > hrs sent me this panic. I'm wondering if it might be relevant to > > this? > > To 'this' what? Well, my thinking was (and it is quite likely completely incorrect) is that, since this panic is a result of holding the spin lock too long, that it might be another symptom of the same problem as when the scheduler seems to "lock up" for several seconds. --> The bug might be some case where the spin lock isn't being released when it should be, and that "could" result in "Heavy I/O blocks FreeBSD box for several seconds". Note that the server was under heavy I/O load when this panic occurred. > A panic is a panic. > > > spin lock 0x80cb52c0 (sched lock 1) held by > > 0xff0012c7f8c0 (tid 100317) too long > > panic: spin lock held too long > > I guess it's more related to the thread on stable@ which has the panic > message > as its subject. > > > cpuid = 0 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > kdb_backtrace() at kdb_backtrace+0x37 > > panic() at panic+0x187 > > _mtx_lock_spin_failed() at _mtx_lock_spin_failed+0x39 > > _mtx_lock_spin() at _mtx_lock_spin+0x9e > > sched_add() at sched_add+0x117 > > setrunnable() at setrunnable+0x78 > > sleepq_signal() at sleepq_signal+0x7a > > cv_signal() at cv_signal+0x3b > > xprt_active() at xprt_active+0xe3 > > svc_vc_soupcall() at svc_vc_soupcall+0xc > > sowakeup() at sowakeup+0x69 > > tcp_do_segment() at tcp_do_segment+0x2cbd > > tcp_input() at tcp_input+0xcdd > > ip_input() at ip_input+0xac > > netisr_dispatch_src() at netisr_dispatch_src+0x7e > > ether_demux() at ether_demux+0x14d > > ether_input() at ether_input+0x17d > > em_rxeof() at em_rxeof+0x1ca > > em_handle_que() at em_handle_que+0x5b > > taskqueue_run_locked() at taskqueue_run_locked+0x85 > > taskqueue_thread_loop() at taskqueue_thread_loop+0x4e > > fork_exit() at fork_exit+0x11f > > fork_trampoline() at fork_trampoline+0xe > > --- trap 0, rip = 0, rsp = 0xff8000160d00, rbp = 0 --- > > KDB: enter: panic > > [thread pid 0 tid 100033 ] > > Stopped at kdb_enter+0x3b: movq $0,0x6b4e62(%rip) > > db> ps > > > > -- > 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" ___ 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: ichwd0: unable to reserve GCS registers
On 07/30/2011 05:34, John Baldwin wrote: > On Saturday, July 30, 2011 02:49:52 AM Andriy Gapon wrote: >> on 19/07/2011 18:16 John Baldwin said the following: >>> Hmm, can you get devinfo -r output from a working kernel with ichwd >>> loaded? You might be able to just build the kernel with 'nooptions >>> NEW_PCIB'. So is this still relevant? I'm sorry I haven't had a chance to get this done, but I may be able to this weekend if you still think it's useful. Doug >> I believe that I've got a similar problem with amdsbwd(4). >> It needs some resources (I/O ports) that belong to ACPI. >> The problem is that the driver attaches to isa bus which is under >> isab->pci->pcib and those particular resources are not assigned to the >> Host-PCI bridge. >> >> I think that you already made a suggestion that perhaps isa bus should >> directly attach to acpi bus when acpi is available. Not sure if there are >> any alternative approaches. > > Actually, my suggestion was the other way around (we should move certain ACPI > devices down behind isab so they are behind the Host-PCI bridge as they are > in > hardware). In this case the BIOS clearly does not list the reosurces for the > GCS as valid resources for the Host-PCI bridge. This is part of the reason > that I added the 'debug.acpi.disable="hostres"'. One thing we may be able to > do is allow non-wildcard requests that are outside the range to still pass if > they are in ACPI's system resource range perhaps. > -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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: ichwd0: unable to reserve GCS registers
On 7/30/11 7:55 PM, Doug Barton wrote: On 07/30/2011 05:34, John Baldwin wrote: On Saturday, July 30, 2011 02:49:52 AM Andriy Gapon wrote: on 19/07/2011 18:16 John Baldwin said the following: Hmm, can you get devinfo -r output from a working kernel with ichwd loaded? You might be able to just build the kernel with 'nooptions NEW_PCIB'. So is this still relevant? I'm sorry I haven't had a chance to get this done, but I may be able to this weekend if you still think it's useful. No, I was able to get that info from someone else with the same issue. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ichwd0: unable to reserve GCS registers
On 07/30/2011 19:35, John Baldwin wrote: > On 7/30/11 7:55 PM, Doug Barton wrote: >> On 07/30/2011 05:34, John Baldwin wrote: >>> On Saturday, July 30, 2011 02:49:52 AM Andriy Gapon wrote: on 19/07/2011 18:16 John Baldwin said the following: > Hmm, can you get devinfo -r output from a working kernel with ichwd > loaded? You might be able to just build the kernel with 'nooptions > NEW_PCIB'. >> >> So is this still relevant? I'm sorry I haven't had a chance to get this >> done, but I may be able to this weekend if you still think it's useful. > > No, I was able to get that info from someone else with the same issue. Awesome. Let me know if there is anything else I can not do to help. :) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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"
