Re: ichwd0: unable to reserve GCS registers

2012-01-28 Thread Doug Barton 
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:  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:  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

2012-01-28 Thread Andriy Gapon 
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:  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

2012-01-28 Thread Alexander Motin 

On 28.01.2012 04:58, Mickaël Maillot wrote:

2012/1/25 Alexander Motin 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


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



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

2012-01-28 Thread Doug Barton 
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:  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

2012-01-28 Thread Andriy Gapon 
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:  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

2012-01-28 Thread Andriy Gapon 

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-01-28 Thread Mickaël Maillot 
2012/1/28 Alexander Motin 

>
> You are right. Fixed: 
> http://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

2012-01-28 Thread Alexander Motin 

On 28.01.2012 13:39, Mickaël Maillot wrote:

2012/1/28 Alexander Motin mailto:m...@freebsd.org>>
You are right. Fixed: 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?

2012-01-28 Thread Kohji Okuno 
Hi HPS,

Do you have better idea?

From: Kohji Okuno 
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?

2012-01-28 Thread Hans Petter Selasky 
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 ?

2012-01-28 Thread Daniel Shafaf 
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  
> 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-01-28 Thread Attilio Rao 
2012/1/19 John Baldwin :
> 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

2012-01-28 Thread Attilio Rao 
2011/11/8 Attilio Rao :
> 2011/11/8 Attilio Rao :
>> 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 ?

2012-01-28 Thread Bjoern A. Zeeb 

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  
>> 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

2012-01-28 Thread Florian Smeets 
[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: 
 
  0, 1, 2, 3, 4, 5, 6, 7
  
   
0, 1, 2, 3
   
   
4, 5, 6, 7
   
  
 


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 ?

2012-01-28 Thread Daniel Shahaf 
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  
> >> 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

2012-01-28 Thread Doug Barton 
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:  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

2012-01-28 Thread Kostik Belousov 
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