Re: ichwd0: unable to reserve GCS registers
On 01/27/2012 10:21, John Baldwin wrote: On Wednesday, January 04, 2012 2:37:55 am Doug Barton wrote: On 01/03/2012 14:14, John Baldwin wrote: On Wednesday, August 03, 2011 3:55:17 am Doug Barton wrote: On 08/02/2011 15:06, John Baldwin wrote: On Saturday, July 30, 2011 2: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. Can you try this: Not so much. :) the first and last patches I can apply to HEAD by hand, but /sys/dev/acpica/acpi_pcib_acpi.c is only 387 lines long, so I'm not even sure where to start. Any chance you could diff against HEAD? I believe this should be fixed (well, worked-around) by my most recent commit to sys/dev/acpica/acpi_pcib_acpi.c in HEAD. Funny you should ask. :) I saw that, and took a look. I'm getting the following error, from a verbose dmesg: isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer ichwd0: Intel ICH10DO watchdog timer on isa0 isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer pcib0: allocated type 4 (0x830-0x837) for rid 0 of ichwd0 pcib0: allocated type 4 (0x860-0x87f) for rid 1 of ichwd0 ichwd0: ICH WDT present but disabled in BIOS or hardware device_attach: ichwd0 attach returned 6 That's different than the error message I got before, but watchdogd still fails. I didn't have a chance to check the BIOS settings until today, and there is no entry for anything even closely resembling this. The only things I actually have disabled are the parallel port, and the Dell Trusted Platform Module, neither of which I can imagine would be relevant. I'm happy to provide more info. Does it operate fully with NEW_PCIB disabled entirely, or do you get this same message in that case? I put nooptions NEW_PCIB in my kernel config, and got basically the same: isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer ichwd0: Intel ICH10DO watchdog timer on isa0 isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer ichwd0: ICH WDT present but disabled in BIOS or hardware device_attach: ichwd0 attach returned 6 -- It's always a long day; 86400 doesn't fit into a short. 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 28/01/2012 11:13 Doug Barton said the following: On 01/27/2012 10:21, John Baldwin wrote: Does it operate fully with NEW_PCIB disabled entirely, or do you get this same message in that case? I put nooptions NEW_PCIB in my kernel config, and got basically the same: isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer ichwd0: Intel ICH10DO watchdog timer on isa0 isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer ichwd0: ICH WDT present but disabled in BIOS or hardware device_attach: ichwd0 attach returned 6 The next logical question is has ichwd ever worked on this system? With any version of FreeBSD. And, perhaps, if there is any watchdog-related knob in the BIOS. -- 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: [RFT] Major snd_hda rewrite
On 28.01.2012 04:58, Mickaël Maillot wrote: 2012/1/25 Alexander Motin m...@freebsd.org mailto:m...@freebsd.org Commenting it appeared not good, as at least mplayer doesn't sets channels for AC3. That makes sound(4) use default 1 channel for AC3, that is definitely not supported. I believe this should be better: http://svn.freebsd.org/__changeset/base/230537 http://svn.freebsd.org/changeset/base/230537 Also, as soon as sound(4) interprets 8 channel as 7.1 by default, I've changed previous patch a bit to allow both 8.0 and 7.1 AC3 formats: http://svn.freebsd.org/__changeset/base/230513 http://svn.freebsd.org/changeset/base/230513 thank, i can set 8 channels without vchan now. For me this at least doesn't break normal AC3 operation and when I hacked mplayer to set 8 channels, I can see predictable codec configuration and time in mplayer predictably running 4 times faster. Unluckily mplayer seems doesn't support TrueHD passthrough to ckeck closer -- it always does decoding. ok i think i found the problem: in http://svn.freebsd.org/changeset/base/230511 cchn is equal to 7 for me if i set SNDCTL_DSP_CHANNELS to 8. and it's why HBR bit is not set. it's confirmed in my /v/l/messages where chan_count=0x7: Jan 28 03:23:53 htpc kernel: hdac1: 24576Kbps of 92160Kbps bandwidth used Jan 28 03:23:53 htpc kernel: pcm4: PCMDIR_PLAY: Stream setup fmt=02800400 (7.1) speed=192000 Jan 28 03:23:53 htpc kernel: pcm4: PCMDIR_PLAY: Stream setup nid=4: fmt=0x1817, dfmt=0x0021, chan=0x0010, chan_count=0x07, stripe=1 You are right. Fixed: http://svn.freebsd.org/changeset/base/230641 Thank you! -- Alexander Motin ___ 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 01/28/2012 01:21, Andriy Gapon wrote: on 28/01/2012 11:13 Doug Barton said the following: On 01/27/2012 10:21, John Baldwin wrote: Does it operate fully with NEW_PCIB disabled entirely, or do you get this same message in that case? I put nooptions NEW_PCIB in my kernel config, and got basically the same: isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer ichwd0: Intel ICH10DO watchdog timer on isa0 isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer ichwd0: ICH WDT present but disabled in BIOS or hardware device_attach: ichwd0 attach returned 6 The next logical question is has ichwd ever worked on this system? With any version of FreeBSD. I have a vague recollection that it did, but I just tried 8.1-RELEASE on the same system and got the same message about it being disabled. OTOH, on my laptop I know that it used to work, and then it didn't. And, perhaps, if there is any watchdog-related knob in the BIOS. That was answered in the part of the message that you snipped. Doug -- It's always a long day; 86400 doesn't fit into a short. 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 28/01/2012 11:37 Doug Barton said the following: On 01/28/2012 01:21, Andriy Gapon wrote: on 28/01/2012 11:13 Doug Barton said the following: On 01/27/2012 10:21, John Baldwin wrote: Does it operate fully with NEW_PCIB disabled entirely, or do you get this same message in that case? I put nooptions NEW_PCIB in my kernel config, and got basically the same: isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer ichwd0: Intel ICH10DO watchdog timer on isa0 isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer ichwd0: ICH WDT present but disabled in BIOS or hardware device_attach: ichwd0 attach returned 6 The next logical question is has ichwd ever worked on this system? With any version of FreeBSD. I have a vague recollection that it did, but I just tried 8.1-RELEASE on the same system and got the same message about it being disabled. Then I'd guess that it has never actually worked (with FreeBSD). OTOH, on my laptop I know that it used to work, and then it didn't. But that's a different system and, as such, a different problem? Have you fixed it or debugged it in a similar fashion to this !laptop system? And, perhaps, if there is any watchdog-related knob in the BIOS. That was answered in the part of the message that you snipped. Oops. -- 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: locks under printf(9) and WITNESS
BTW, I see another LOR with spinlocks, maybe harmless. o sysbeep() is called from syscons code and it calls timeout() which introduces the following order: scrlock - callout. o The callout code programming of event timers introduces the following order (via callout_new_inserted == cpu_new_callout): callout - et_hw_mtx o Eventtimers' doconfigtimer calls loadtimer with et_hw_mtx held, loadtimer calls et_start method of a configured event timer and, e.g. in the case of lapic_et_start and bootverbose it calls printf(9), which gives: et_hw_mtx - scrlock This is just for the information. -- 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: [RFT] Major snd_hda rewrite
2012/1/28 Alexander Motin m...@freebsd.org You are right. Fixed: http://svn.freebsd.org/**changeset/base/230641http://svn.freebsd.org/changeset/base/230641 Thank you! -- Alexander Motin And i can play DTS-HDMA en Dolby TrueHD ! thanks for all your work :) ___ 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: [RFT] Major snd_hda rewrite
On 28.01.2012 13:39, Mickaël Maillot wrote: 2012/1/28 Alexander Motin m...@freebsd.org mailto:m...@freebsd.org You are right. Fixed: http://svn.freebsd.org/__changeset/base/230641 http://svn.freebsd.org/changeset/base/230641 And i can play DTS-HDMA en Dolby TrueHD ! thanks for all your work :) Hooray! We did it! :) Thank you very much for testing it! -- Alexander Motin ___ 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: Is UPS_PORT_POWER wrong?
Hi HPS,
Do you have better idea?
From: Kohji Okuno okuno.ko...@jp.panasonic.com
Date: Tue, 24 Jan 2012 09:53:29 +0900 (JST)
Hi HPS,
On Monday 23 January 2012 09:12:46 Kohji Okuno wrote:
Hi HPS,
I think that UPS_PORT_POWER and UPS_PORT_LINK_STATE overlap.
And, in xhci.c you set UPS_PORT_POWER as folows.
When UPS_PORT_POWER is set, UPS_PORT_LINK_STATE_GET() macro will
return incorrect value.
if (v XHCI_PS_PP) {
/*
* The USB 3.0 RH is using the
* USB 2.0's power bit
*/
i |= UPS_PORT_POWER;
}
Hi,
The USB 3.0 root HUB is special because it defines FULL/HIGH and LOW speed,
so
I had to merge that into the port status register of the XHCI root HUB like
this:
0: CONNECT_STATUS
1: PORT_ENABLED
2: SUSPEND
3: OVERCURRENT_INDICATOR
4: LINK STATE (USB 3.0)
5: -
6: -
7: -
8: PORT_POWER (USB 2.0)
# Bit 9+10 have 4 combinations which are defined: FS, LW, HS, SS
9: LOW_SPEED (USB 2.0)
10: HIGH_SPEED (USB 2.0)
11: not implemented
12: PORT_INDICATOR
13:
14:
15: MODE_DEVICE (FreeBSD specific)
If you have a better idea, it is possible to change this.
I have a idea.
-#define UPS_PORT_LINK_STATE_GET(x) (((x) 5) 0xF)
-#define UPS_PORT_LINK_STATE_SET(x) (((x) 0xF) 5)
+#define UPS_PORT_LINK_STATE_GET(x) x) 5) 0x7)|(((x) 11)
0x8))
+#define UPS_PORT_LINK_STATE_SET(x) x) 0x7) 5)|(((x) 0x8)
11))
+#define UPS_PORT_LS_SS 0x4000 /* currently FreeBSD
specific */
But, this is not cool.
Regards,
Kohji Okuno
___
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: Is UPS_PORT_POWER wrong?
On Saturday 28 January 2012 12:53:39 Kohji Okuno wrote: Hi HPS, Do you have better idea? It might be we should implement a separate control request to get the information we need? Though that needs to be standardized. What do you think about that? --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: jid and jname are numberic by default why? Can we change it ?
Matt Mullins wrote on Fri, Jan 27, 2012 at 12:06:48 -0800:
On Fri, Jan 27, 2012 at 9:08 AM, Philip M. Gollucci pgollu...@gmail.com
wrote:
All,
$ jls -nq | tail -1 | xargs -n1 | egrep '^(name|jid)='| xargs
jid=17 name=17
# jubilee/chef
jail_jubilee_hostname=jubilee.dca1.rws
jail_jubilee_ip=192.168.2.41
jail_jubilee_ip_multi0=192.168.2.42
jail_jubilee_interface=bge1
jail_jubilee_rootdir=/jubilee
jail_jubilee_devfs_enable=YES
The default flags that /etc/rc.d/jail passes to jail(8) are -l -U
root. Failing to give jail(8) a name results in name==jid, as you
found above.
You can make the rc script name the jail by setting:
jail_jubilee_flags=-n jubilee -l -U root
Good point. Would it make sense to have rc.d/jail behave this way by
default?
% diff -u /etc/rc.d/jail jail
--- /etc/rc.d/jail 2012-01-21 18:22:26.0 +0200
+++ jail2012-01-28 10:13:03.0 +0200
@@ -112,7 +112,7 @@
eval _fstab=\\${jail_${_j}_fstab:-${jail_fstab}}\
[ -z ${_fstab} ] _fstab=/etc/fstab.${_j}
eval _flags=\\${jail_${_j}_flags:-${jail_flags}}\
- [ -z ${_flags} ] _flags=-l -U root
+ [ -z ${_flags} ] _flags=-n ${_j} -l -U root
eval _consolelog=\\${jail_${_j}_consolelog:-${jail_consolelog}}\
[ -z ${_consolelog} ] _consolelog=/var/log/jail_${_j}_console.log
eval _fib=\\${jail_${_j}_fib:-${jail_fib}}\
Notice the rc script uses the second form of syntax listed in jail(8),
at least on 9.0-RELEASE.
___
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: [panic] intr_event_execute_handlers() - Corrupted DWARF expression
2012/1/19 John Baldwin j...@freebsd.org: On Thursday, January 19, 2012 11:02:57 am Glen Barber wrote: On Thu, Jan 19, 2012 at 10:50:45AM -0500, John Baldwin wrote: On Wednesday, January 18, 2012 5:01:37 pm Glen Barber wrote: Hi, I'm running -CURRENT from about 5 days ago: nucleus# uname -a FreeBSD nucleus 10.0-CURRENT FreeBSD 10.0-CURRENT #3 r230037M: Fri Jan 13 17:48:14 EST 2012 gjb@nucleus:/usr/obj/usr/src/sys/NUCLEUS amd64 (The 'M' is kib's DRM patches for Intel GPU.) So far, I haven't had much problem with this laptop, but just had the machine panic. I have kgdb output attached, and I'll be happy to provide whatever additional information that may be needed. I have core.txt.N available here: http://people.freebsd.org/~gjb/core.txt In kgdb, can you go to frame 6 and 'p td-td_lock'. If that is non-null, can you do 'p *td-td_lock'? Sure, script(1) output is attached. Hmm, I don't think td-td_lock is ever supposed to be NULL. No, never, it is initialized in sched_fork_thread() and can point to containers lock or blocked_lock. I think the memory page of the pointer could have been zeroed or it is an hw bug. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: svn commit: r227333 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/kern sys/mips/conf sys/pc98/conf sys/powerpc/conf sys/sparc64/conf
2011/11/8 Attilio Rao atti...@freebsd.org: 2011/11/8 Attilio Rao atti...@freebsd.org: Author: attilio Date: Tue Nov 8 10:18:07 2011 New Revision: 227333 URL: http://svn.freebsd.org/changeset/base/227333 Log: Introduce the option VFS_ALLOW_NONMPSAFE and turn it on by default on all the architectures. The option allows to mount non-MPSAFE filesystem. Without it, the kernel will refuse to mount a non-MPSAFE filesytem. This patch is part of the effort of killing non-MPSAFE filesystems from the tree. This is just a gentle reminder in order to point you further to the official page: http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS and encourage once again people in adopting a dying FS if it really matters to them. So far, unfortunately, I didn't see a lot of activity in this area but I hope that this would change soon. This is a further reminder. So far I've not seen any improvement over the locking of any of our 'legacy' filesystems. I remind you that this may be meaning disconnecting them from the tree on 1st Semptember 2012, accordingly with this road-map: http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS In one month I'm going to disable VFS_ALLOW_NONMPSAFE by defaults in order to see how well the users do with this option down. At the present times this means that from 1st March you won't be able to mount smbfs or ntfs volumes, for example. Please step up and fix your favourite filesystem. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: jid and jname are numberic by default why? Can we change it ?
On 28. Jan 2012, at 08:19 , Daniel Shafaf wrote:
Matt Mullins wrote on Fri, Jan 27, 2012 at 12:06:48 -0800:
On Fri, Jan 27, 2012 at 9:08 AM, Philip M. Gollucci pgollu...@gmail.com
wrote:
All,
$ jls -nq | tail -1 | xargs -n1 | egrep '^(name|jid)='| xargs
jid=17 name=17
# jubilee/chef
jail_jubilee_hostname=jubilee.dca1.rws
jail_jubilee_ip=192.168.2.41
jail_jubilee_ip_multi0=192.168.2.42
jail_jubilee_interface=bge1
jail_jubilee_rootdir=/jubilee
jail_jubilee_devfs_enable=YES
The default flags that /etc/rc.d/jail passes to jail(8) are -l -U
root. Failing to give jail(8) a name results in name==jid, as you
found above.
You can make the rc script name the jail by setting:
jail_jubilee_flags=-n jubilee -l -U root
Good point. Would it make sense to have rc.d/jail behave this way by
default?
% diff -u /etc/rc.d/jail jail
--- /etc/rc.d/jail 2012-01-21 18:22:26.0 +0200
+++ jail2012-01-28 10:13:03.0 +0200
@@ -112,7 +112,7 @@
eval _fstab=\\${jail_${_j}_fstab:-${jail_fstab}}\
[ -z ${_fstab} ] _fstab=/etc/fstab.${_j}
eval _flags=\\${jail_${_j}_flags:-${jail_flags}}\
- [ -z ${_flags} ] _flags=-l -U root
+ [ -z ${_flags} ] _flags=-n ${_j} -l -U root
eval _consolelog=\\${jail_${_j}_consolelog:-${jail_consolelog}}\
[ -z ${_consolelog} ]
_consolelog=/var/log/jail_${_j}_console.log
eval _fib=\\${jail_${_j}_fib:-${jail_fib}}\
No. rc.d/jail shall not be extended anymore; please see the framework Jamie
posted
on freebsd-jail last year and test/review/report back there.
See http://lists.freebsd.org/pipermail/freebsd-jail/2011-July/thread.html#1568
You get a config file etc and get rid of all the shell magic and nightmare.
/bz
Notice the rc script uses the second form of syntax listed in jail(8),
at least on 9.0-RELEASE.
___
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
--
Bjoern A. Zeeb You have to have visions!
It does not matter how good you are. It matters what good you do!
___
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
ULE vs. 4BSD scheduler benchmarks
[current@ bcc'ed to get a wider audience, please discuss on performance@]
Hi,
in recent times i saw a lot of threads where it was suggested people
should switch from the ULE to the 4BSD scheduler. That got me thinking
and i decided to run a few benchmarks. I looked through all the stuff
Kris and Jeff did a few years ago and tried to follow their example. The
main motivation is however that we (Attilio Rao and I) want to set a
baseline for future reference, mainly for the work that's going on in
the vmcontention branch right now, that is the reason why all tests were
run on head@r229659. All debugging was disabled (WITNESS and friends for
the kernel and MALLOC_PRODUCTION=yes for libc).
For now i ran 3 different things. MySQL/sysbench, PostgreSQL/pgbench and
pbzip2.
All software was installed from ports with the default system gcc (gcc
version 4.2.1 20070831 patched [FreeBSD]), with the exception of
PostgreSQL. I created new postgres92-{server,client} ports with a
snapshot of PostgreSQL 9.2dev from 16.01.2012, as a lot of scalability
work was done in PostgreSQL 9.2.
MySQL version 5.5.20
sysbench version 0.4.12
PostgreSQL/pgbench version 9.2dev
PBZIP2 version v1.1.6
The machine these test were run on is a 2x4 core Xeon L5310 @ 1.60GHz
with 4GB RAM. Here is the complete topology:
kern.sched.topology_spec: groups
group level=1 cache-level=0
cpu count=8 mask=ff0, 1, 2, 3, 4, 5, 6, 7/cpu
children
group level=2 cache-level=2
cpu count=4 mask=f0, 1, 2, 3/cpu
/group
group level=2 cache-level=2
cpu count=4 mask=f04, 5, 6, 7/cpu
/group
/children
/group
/groups
The database benchmarks were all run with a work set that fit into the
configured database memory, so after the warmup phase no disk io was
involved. sysbench was run with 1 million rows, innodb was the engine we
used as Kris work already showed that it scales much better than myisam
(also innodb is the default in MySQL's 5.5 branch). Pgbench was run
using a scaling factor of 100. The connection to the databases was using
a unix socket, also only read only tests were run.
The input and output files for the pbzip2 test were on tmpfs.
The results are available in this Google docs spreadsheet, if you scroll
down there are also some nice graphs.
https://docs.google.com/spreadsheet/ccc?key=0Ai0N1xDe3uNAdDRxcVFiYjNMSnJWOTZhUWVWWlBlemc
Over time i will add more benchmarks to the doc (i.e nginx/php-fpm and
so on). I tried to run some nginx benchmarks, but those are limited by
netisr, as i did not find a web server benchmark tool which can use unix
sockets, any suggestions welcome.
The conclusion right now seems to be that ULE is faster for database
workload, but for strongly CPU-bound workloads 4BSD can be a better
choice. I can provide KTR traces and/or schedgraph output for cases
where 4BSD is better than ULE.
I want to thank Sean Bruno and Yahoo for setting up / providing the
machines to run these test on, and Attilio for suggestions and his
general helpfulness.
Florian
signature.asc
Description: OpenPGP digital signature
Re: jid and jname are numberic by default why? Can we change it ?
Bjoern A. Zeeb wrote on Sat, Jan 28, 2012 at 21:06:59 +:
On 28. Jan 2012, at 08:19 , Daniel Shafaf wrote:
Matt Mullins wrote on Fri, Jan 27, 2012 at 12:06:48 -0800:
On Fri, Jan 27, 2012 at 9:08 AM, Philip M. Gollucci pgollu...@gmail.com
wrote:
All,
$ jls -nq | tail -1 | xargs -n1 | egrep '^(name|jid)='| xargs
jid=17 name=17
# jubilee/chef
jail_jubilee_hostname=jubilee.dca1.rws
jail_jubilee_ip=192.168.2.41
jail_jubilee_ip_multi0=192.168.2.42
jail_jubilee_interface=bge1
jail_jubilee_rootdir=/jubilee
jail_jubilee_devfs_enable=YES
The default flags that /etc/rc.d/jail passes to jail(8) are -l -U
root. Failing to give jail(8) a name results in name==jid, as you
found above.
You can make the rc script name the jail by setting:
jail_jubilee_flags=-n jubilee -l -U root
Good point. Would it make sense to have rc.d/jail behave this way by
default?
% diff -u /etc/rc.d/jail jail
--- /etc/rc.d/jail 2012-01-21 18:22:26.0 +0200
+++ jail2012-01-28 10:13:03.0 +0200
@@ -112,7 +112,7 @@
eval _fstab=\\${jail_${_j}_fstab:-${jail_fstab}}\
[ -z ${_fstab} ] _fstab=/etc/fstab.${_j}
eval _flags=\\${jail_${_j}_flags:-${jail_flags}}\
- [ -z ${_flags} ] _flags=-l -U root
+ [ -z ${_flags} ] _flags=-n ${_j} -l -U root
eval _consolelog=\\${jail_${_j}_consolelog:-${jail_consolelog}}\
[ -z ${_consolelog} ]
_consolelog=/var/log/jail_${_j}_console.log
eval _fib=\\${jail_${_j}_fib:-${jail_fib}}\
No. rc.d/jail shall not be extended anymore; please see the framework Jamie
posted
on freebsd-jail last year and test/review/report back there.
See http://lists.freebsd.org/pipermail/freebsd-jail/2011-July/thread.html#1568
It appears that the problem is already solved in that framework:
a jail.conf(5) block defining a jail is required to be preceded by
a jailname{}, which is documented to set the jail(8)'s name. In other
words, it won't be possible to define in jail.conf(5) a jail that will
end up nameless (and thus implicitly named as its jid).
Thanks for the pointer,
Daniel
[1] http://svn.freebsd.org/base/projects/jailconf/usr.sbin/jail/jail.conf.5
P.S. As an aside, the provision in projects/jailconf/'s jail(8) that
it's not possible for 'jail -r' to remove all jails _unless_ the '*'
syntax is used seems unusual to me: I expect 'jail -r foo bar' to remove
those two jails regardless of whether any other jails exist. (Sorry if
this has been discussed already -- it's just an issue I ran across while
examining the jail(8) man page in Jamie's framework.)
You get a config file etc and get rid of all the shell magic and
nightmare.
/bz
Notice the rc script uses the second form of syntax listed in jail(8),
at least on 9.0-RELEASE.
___
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
--
Bjoern A. Zeeb You have to have visions!
It does not matter how good you are. It matters what good you do!
___
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 01/28/2012 01:41, Andriy Gapon wrote: on 28/01/2012 11:37 Doug Barton said the following: On 01/28/2012 01:21, Andriy Gapon wrote: on 28/01/2012 11:13 Doug Barton said the following: On 01/27/2012 10:21, John Baldwin wrote: Does it operate fully with NEW_PCIB disabled entirely, or do you get this same message in that case? I put nooptions NEW_PCIB in my kernel config, and got basically the same: isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer ichwd0: Intel ICH10DO watchdog timer on isa0 isab0: found ICH10 or equivalent chipset: Intel ICH10DO watchdog timer ichwd0: ICH WDT present but disabled in BIOS or hardware device_attach: ichwd0 attach returned 6 The next logical question is has ichwd ever worked on this system? With any version of FreeBSD. I have a vague recollection that it did, but I just tried 8.1-RELEASE on the same system and got the same message about it being disabled. Then I'd guess that it has never actually worked (with FreeBSD). It's possible, sure. What I find interesting is that the message I'm seeing on -current is different after John's recent commit. OTOH I'm now seeing the same message on 8 as I am on -current, so you're probably right. OTOH, on my laptop I know that it used to work, and then it didn't. But that's a different system and, as such, a different problem? Have you fixed it or debugged it in a similar fashion to this !laptop system? I did in the past, yes. But I haven't had a chance to do that since John's latest commit. I'll do that when I can. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ signature.asc Description: OpenPGP digital signature
Re: [ptrace] please review follow fork/exec changes
On Fri, Jan 27, 2012 at 10:12:13AM -0800, Dmitry Mikulin wrote:
Attached are 4 separate patches for each somewhat independent portion of
the kernel work related to the follow-fork implementation.
Ok, as I said, I think that vfork-fork.patch is just wrong.
Lets postpone discussion of the orphan.patch for later.
The follow-fork.patch and follow-exec.patch make me wonder, and I
already expressed my doubts. IMO, all features, except one bug, are
already presented in the stock src.
More, suggested follow-{fork,exec} patches break the SCE/SCX tracers
notification of fork and exec events, since TDB_FORK and TBD_EXEC flags
are consumed before syscall returns (I also said this previously).
Namely, if the process is being debugged, the successfull [f]execve()
causes unconditional stop even. This makes PT_FOLLOW_EXEC unneccessary.
Existing PT_FOLLOW_FORK implementation indeed has a bug, which was not
revealed by my testing during the development, because I only tested
SCE/SCX scenario. Namely, if PT_FOLLOW_FORK is requested, but the next
stop is not SCX, then follow-fork notification is not sent. After this
nit is fixed, PT_FOLLOW_FORK caller gets stops for the child creation.
Child is put into stop state as needed to not loose it.
I updated the test program I use to test this functionality, see
http://people.freebsd.org/~kib/misc/scescx.c
The default or -s flag causes it to use SCE/SCX tracing, while -c flag
switches it to use PT_CONTINUE tracing, which should be the kind of loop
performed by normal debuggers. You can see the exec/fork events and
child auto-attach illustrated with this test.
Can you, please, provide the test-case which illustrates the omissions
in the existing API (with the patch below applied), if any ?
diff --git a/sys/kern/subr_syscall.c b/sys/kern/subr_syscall.c
index bba4479..75328f6 100644
--- a/sys/kern/subr_syscall.c
+++ b/sys/kern/subr_syscall.c
@@ -212,7 +212,8 @@ syscallret(struct thread *td, int error, struct
syscall_args *sa __unused)
* executes. If debugger requested tracing of syscall
* returns, do it now too.
*/
- if (traced ((td-td_dbgflags TDB_EXEC) != 0 ||
+ if (traced
+ ((td-td_dbgflags (TDB_FORK | TDB_EXEC)) != 0 ||
(p-p_stops S_PT_SCX) != 0))
ptracestop(td, SIGTRAP);
td-td_dbgflags = ~(TDB_SCX | TDB_EXEC | TDB_FORK);
pgp116s22XAVu.pgp
Description: PGP signature
