Re: virtualbox status on 8.0-STABLE i386

2010-03-08 Thread Mikolaj Golub 
On Sun, 07 Mar 2010 15:28:48 +0100 Alexander Eichner wrote:

> Hi,
>
> can you try the attached patch please?
> This should fix the panic you encountered. Please undo your kernel
> changes befoer testing.

Unfortunately, the same panic:

(kgdb) bt
#0  doadump () at pcpu.h:246
#1  0xc04ec379 in db_fncall (dummy1=-1064468854, dummy2=0, dummy3=-1, 
dummy4=0xe866b5b4 "х╣fХ")
at /usr/src/sys/ddb/db_command.c:548
#2  0xc04ec7af in db_command (last_cmdp=0xc0e04c9c, cmd_table=0x0, dopager=0)
at /usr/src/sys/ddb/db_command.c:445
#3  0xc04ec864 in db_command_script (command=0xc0e05bc4 "call doadump")
at /usr/src/sys/ddb/db_command.c:516
#4  0xc04f09a0 in db_script_exec (scriptname=0xe866b6c0 "kdb.enter.panic", 
warnifnotfound=Variable "warnifnotfound" is not available.
)
at /usr/src/sys/ddb/db_script.c:302
#5  0xc04f0a87 in db_script_kdbenter (eventname=0xc0cc246d "panic") at 
/usr/src/sys/ddb/db_script.c:324
#6  0xc04ee768 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:228
#7  0xc08d7d06 in kdb_trap (type=3, code=0, tf=0xe866b7fc) at 
/usr/src/sys/kern/subr_kdb.c:535
#8  0xc0beb38b in trap (frame=0xe866b7fc) at /usr/src/sys/i386/i386/trap.c:690
#9  0xc0bcccfb in calltrap () at /usr/src/sys/i386/i386/exception.s:165
#10 0xc08d7e8a in kdb_enter (why=0xc0cc246d "panic", msg=0xc0cc246d "panic") at 
cpufunc.h:71
#11 0xc08a88b6 in panic (fmt=0xc0cecba4 "vm_fault: fault on nofault entry, 
addr: %lx")
at /usr/src/sys/kern/kern_shutdown.c:562
#12 0xc0b0c3c7 in vm_fault (map=0xc199, vaddr=3244318720, 
fault_type=Variable "fault_type" is not available.
)
at /usr/src/sys/vm/vm_fault.c:283
#13 0xc0bea7c6 in trap_pfault (frame=0xe866bab8, usermode=0, eva=3244322776)
at /usr/src/sys/i386/i386/trap.c:840
#14 0xc0beb215 in trap (frame=0xe866bab8) at /usr/src/sys/i386/i386/trap.c:533
#15 0xc0bcccfb in calltrap () at /usr/src/sys/i386/i386/exception.s:165
#16 0xc12beef3 in rtR0MemObjNativeGetPagePhysAddr () from 
/boot/modules/vboxdrv.ko
#17 0xc12ac374 in SUPR0LockMem () from /boot/modules/vboxdrv.ko
#18 0xc12ac8eb in supdrvIOCtl () from /boot/modules/vboxdrv.ko
#19 0xc12b0c5a in VBoxDrvFreeBSDIOCtl () from /boot/modules/vboxdrv.ko
#20 0xc0829658 in devfs_ioctl_f (fp=0xc5f1c8c0, com=3321378576, 
data=0xe866bd00, cred=0xc6972a00, 
td=0xc728e250) at /usr/src/sys/fs/devfs/devfs_vnops.c:659
#21 0xc08eec8d in kern_ioctl (td=0xc728e250, fd=7, com=536892942, 
data=0xe866bd00 "@г\023)Ь\023Эю8╫fХЬ\023Эю,╫fХ\005\\╫ю\001") at file.h:262
#22 0xc08eee14 in ioctl (td=0xc728e250, uap=0xe866bcf8) at 
/usr/src/sys/kern/sys_generic.c:678
#23 0xc0beaac0 in syscall (frame=0xe866bd38) at 
/usr/src/sys/i386/i386/trap.c:
#24 0xc0bccd90 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261
#25 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)

(this time I built the modules without debugging symbols).

Just to be sure that I did all thing properly below the steps I did:

1) returned original pmap.h (with KPTmap), rebuilt the kernel and rebooted
2) rebuilt with the patch virtualbox drivers and virtualbox (not sure this last 
was 
   needed bu just in case...):
 cd emulators/virtualbox-ose-kmod && make patch
 applied this patch and your previous patch ("Patch to fix VirtualBox with 
recent kernel versions")
 built and reinstall
 the same for emulators/virtualbox-ose
3) rebooted and started vm guest

virtualbox-ose-3.1.2_1 A general-purpose full virtualizer for x86 hardware
virtualbox-ose-kmod-3.1.2_1 VirtualBox kernel module for FreeBSD

-- 
Mikolaj Golub
___
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: ntpd multicast TTL

2010-03-08 Thread John Marshall 
On Sun, 07 Mar 2010, 16:19 +, Christian Weisgerber wrote:
> ntpd is a convenient source of multicast packets for testing purposes.
> When I add
> 
> broadcast 224.0.1.1
> 
> to my ntp.conf, ntpd sends a multicast packet with TTL 1 every 64
> seconds.  Just as expected.  However, when I explicitly specify the
> TTL as in
> 
> broadcast 224.0.1.1 ttl 1
> 
> it sends packets with TTL 32.  Trying a few other numbers confirms
> that it multiplies the specified TTL by 32.  That is not expected.
> (I also don't recall this happening the last time I tried it, but
> that may have been years ago.)
> 
> Is this simply a bug in ntpd?

No, it's just that the ntp's server configuration statements don't use
their ttl option to specify network ttl value, but as zero-based index
into ntp's ttl value array.  The default array is as you describe
[1,32,64,96,128,160,192,224] but can be overridden by the ttl
configuration statement.

So the following lines in your ntp.conf would result in your multicast
server transmitting packets with ttl=4.

  ttl 2 4 6 8
  broadcast 224.0.1.1 ttl 1

I tripped over this last year when experimenting with ntp multicast.
I had to resort to the source code to understand what was happening.
It is actually documented.



-- 
John Marshall


pgphHtuoRs2TY.pgp
Description: PGP signature

powerd on 8.0, is it considered safe?

2010-03-08 Thread Dan Naumov 
Hello

Is powerd finally considered stable and safe to use on 8.0? At least
on 7.2, it consistently caused panics when used on Atom systems with
Hyper-Threading enabled, but I recall that Attilio Rao was looking
into it.


- Sincerely,
Dan Naumov
___
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: powerd on 8.0, is it considered safe?

2010-03-08 Thread Jeremy Chadwick 
On Mon, Mar 08, 2010 at 12:47:37PM +0200, Dan Naumov wrote:
> Is powerd finally considered stable and safe to use on 8.0? At least
> on 7.2, it consistently caused panics when used on Atom systems with
> Hyper-Threading enabled, but I recall that Attilio Rao was looking
> into it.

I didn't realise it was unsafe to use on RELENG_8 or RELENG_7...?

I've been using powerd(8) without any problems on my Supermicro X7SBA
system (CPU = Core2Duo E8400) for quite some time, including back to the
RELENG_7 days.

I should note that on RELENG_7, EIST/SpeedStep didn't appear to work
properly (cpufreq(4) driver reporting that the est piece wouldn't
attach), which historically (for me) has resulted in ACPI throttling
being done (which works).  Based on the sysctl output below, I believe
acpi_perf is in use, but I'm not 100% certain.  The man page doesn't
really disclose how to determine which driver is in use.

The X7SBA system in question is below.  Be aware I limit the lowest
clock frequency to 1500MHz using debug.cpufreq.lowest="1500" in
/boot/loader.conf, which is why you don't see anything lower in
freq_levels.

$ uname -a
FreeBSD icarus.home.lan 8.0-STABLE FreeBSD 8.0-STABLE #0: Mon Mar  1 11:51:38 
PST 2010 r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64  
amd64

$ kenv | grep smbios.planar.product
smbios.planar.product="X7SBA"

$ uptime
 3:00am  up 6 days, 14:38, 1 user, load averages: 0.00, 0.00, 0.00

$ ps -aux | grep powerd
root  991  0.0  0.0  6836  1284  ??  Ss   Mon12pm   2:42.21 /usr/sbin/powerd
jdc 71353  0.0  0.0  9036  1524   0  S+3:00am   0:00.00 grep powerd

$ sysctl dev.cpu dev.est dev.cpufreq dev.p4tcc debug.cpufreq kern.timecounter
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.temperature: 41.0C
dev.cpu.0.freq: 1500
dev.cpu.0.freq_levels: 3000/35000 2667/28000 2333/22000 2041/19250 2000/16000 
1750/14000 1500/12000
dev.cpu.0.cx_supported: C1/0 C2/85
dev.cpu.0.cx_lowest: C1
dev.cpu.0.cx_usage: 100.00% 0.00% last 500us
dev.cpu.1.%desc: ACPI CPU
dev.cpu.1.%driver: cpu
dev.cpu.1.%location: handle=\_PR_.CPU1
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%parent: acpi0
dev.cpu.1.temperature: 41.0C
dev.cpu.1.cx_supported: C1/0 C2/85
dev.cpu.1.cx_lowest: C1
dev.cpu.1.cx_usage: 100.00% 0.00% last 500us
dev.est.0.%desc: Enhanced SpeedStep Frequency Control
dev.est.0.%driver: est
dev.est.0.%parent: cpu0
dev.est.0.freq_settings: 3000/35000 2667/28000 2333/22000 2000/16000
dev.est.1.%desc: Enhanced SpeedStep Frequency Control
dev.est.1.%driver: est
dev.est.1.%parent: cpu1
dev.est.1.freq_settings: 3000/35000 2667/28000 2333/22000 2000/16000
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0
dev.cpufreq.1.%driver: cpufreq
dev.cpufreq.1.%parent: cpu1
dev.p4tcc.0.%desc: CPU Frequency Thermal Control
dev.p4tcc.0.%driver: p4tcc
dev.p4tcc.0.%parent: cpu0
dev.p4tcc.0.freq_settings: 1/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 
2500/-1 1250/-1
dev.p4tcc.1.%desc: CPU Frequency Thermal Control
dev.p4tcc.1.%driver: p4tcc
dev.p4tcc.1.%parent: cpu1
dev.p4tcc.1.freq_settings: 1/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 
2500/-1 1250/-1
debug.cpufreq.verbose: 0
debug.cpufreq.lowest: 1500
kern.timecounter.tick: 1
kern.timecounter.choice: TSC(-100) ACPI-fast(1000) i8254(0) dummy(-100)
kern.timecounter.hardware: ACPI-fast
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.i8254.counter: 7127
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.ACPI-fast.mask: 16777215
kern.timecounter.tc.ACPI-fast.counter: 3275901
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.quality: 1000
kern.timecounter.tc.TSC.mask: 4294967295
kern.timecounter.tc.TSC.counter: 1458979861
kern.timecounter.tc.TSC.frequency: 2992512852
kern.timecounter.tc.TSC.quality: -100
kern.timecounter.smp_tsc: 0
kern.timecounter.invariant_tsc: 1

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
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: 8.0-RELEASE-p2: boot0cfg yields "vnode_pager_getpages: I/O read error"

2010-03-08 Thread Maciej Milewski 
Dnia poniedziałek, 8 marca 2010 o 04:00:02 Brian Conway napisał(a):
> Greetings.  I'm testing NanoBSD images for eventual use in an Alix board
> and have run into an issue with the boot0cfg lines in the update scripts,
> in multiple environments.  Specifically, any use of boot0cfg yields a
> successful output[1], followed by:
> ...
> Any ideas?  Bug or
> user error?  Thanks.
> 
> Brian Conway

Brian,
try changing in updatep1 and updatep2 to use gpart not boot0cfg:

#boot0cfg -s 1 -v ${NANO_DRIVE}
gpart set -a active -i 1 ${NANO_DRIVE}

I think is the problem. I was having similar errors as you while I was using 
boot0cfg.

Maciej Milewski
___
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: powerd on 8.0, is it considered safe?

2010-03-08 Thread Dan Naumov 
Okay, now I am baffled.

Up until this point, I wasn't using powerd on this new Atom D510
system. I ran sysctl and noticed that dev.cpu.0.freq: is actually 1249
and doesn't change no matter what kind of load the system is under. If
I boot to BIOS, under BIOS CPU is shown as 1,66 Ghz. Okayy... I guess
this explains why my buildworld and buildkernel took over 5 hours if
by default, it gets stuck at 1249 Mhz for no obvious reason. I enabled
powerd and now according to dev.cpu.0.freq:, the system is permanently
stuck at 1666 Mhz, regardless of whether the system is under load or
not.

atombsd# uname -a
FreeBSD atombsd.localdomain 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0:
Tue Jan  5 21:11:58 UTC 2010
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

atombsd# kenv | grep smbios.planar.product
smbios.planar.product="X7SPA-H"

atombsd# sysctl dev.cpu dev.est dev.cpufreq dev.p4tcc debug.cpufreq
kern.timecounter
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.P001
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 1666
dev.cpu.0.freq_levels: 1666/-1 1457/-1 1249/-1 1041/-1 833/-1 624/-1
416/-1 208/-1
dev.cpu.0.cx_supported: C1/0
dev.cpu.0.cx_lowest: C1
dev.cpu.0.cx_usage: 100.00% last 500us
dev.cpu.1.%desc: ACPI CPU
dev.cpu.1.%driver: cpu
dev.cpu.1.%location: handle=\_PR_.P002
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%parent: acpi0
dev.cpu.1.cx_supported: C1/0
dev.cpu.1.cx_lowest: C1
dev.cpu.1.cx_usage: 100.00% last 500us
dev.cpu.2.%desc: ACPI CPU
dev.cpu.2.%driver: cpu
dev.cpu.2.%location: handle=\_PR_.P003
dev.cpu.2.%pnpinfo: _HID=none _UID=0
dev.cpu.2.%parent: acpi0
dev.cpu.2.cx_supported: C1/0
dev.cpu.2.cx_lowest: C1
dev.cpu.2.cx_usage: 100.00% last 500us
dev.cpu.3.%desc: ACPI CPU
dev.cpu.3.%driver: cpu
dev.cpu.3.%location: handle=\_PR_.P004
dev.cpu.3.%pnpinfo: _HID=none _UID=0
dev.cpu.3.%parent: acpi0
dev.cpu.3.cx_supported: C1/0
dev.cpu.3.cx_lowest: C1
dev.cpu.3.cx_usage: 100.00% last 500us
sysctl: unknown oid 'dev.est'

Right. So how do I investigate why does the CPU get stuck at 1249 Mhz
after boot by default when not using powerd and why it gets stuck at
1666 Mhz with powerd enabled and doesn't scale back down when IDLE?
Out of curiosity, I stopped powerd but the CPU remained at 1666 Mhz.


- Sincerely,
Dan Naumov
___
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: powerd on 8.0, is it considered safe?

2010-03-08 Thread Dan Naumov 
>Up until this point, I wasn't using powerd on this new Atom D510
>system. I ran sysctl and noticed that dev.cpu.0.freq: is actually 1249
>and doesn't change no matter what kind of load the system is under. If
>I boot to BIOS, under BIOS CPU is shown as 1,66 Ghz. Okayy... I guess
>this explains why my buildworld and buildkernel took over 5 hours if
>by default, it gets stuck at 1249 Mhz for no obvious reason. I enabled
>powerd and now according to dev.cpu.0.freq:, the system is permanently
>stuck at 1666 Mhz, regardless of whether the system is under load or
>not.

OK, a reboot somehow fixed the powerd issue:

1) Disabled powerd
2) Rebooted
3) Upon bootup, checked dev.cpu.0.freq - it's stuck at 1249 (should be
1666 by default)
4) Enabled and started powerd - CPU scales correctly according to load

There is some bug somewhere though, because something puts my CPU to
1249 Mhz upon boot with powerd disabled and it gets stuck there, this
shouldn't happen.


- Sincerely,
Dan Naumov
___
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"

Supplementary groups on LDAP cannot work with RELENG_8 + nss_ldap

2010-03-08 Thread Ling-hua Tseng 
Today I upgraded 2 of my 4 machines from RELENG_7 to RELENG_8.
Both of the 2 machines are just LDAP clients.
My LDAP server is still running on RELENG_7,
and the remained one is also a LDAP client.
All of them were installed OpenLDAP-2.4.21 and nss_ldap-1.265_3.

Before I upgrades my system, everything works properly.
I added a group named `group1' on LDAP server,
and then add a user named `user1' to this group.
I can type `id user1' to see the following line:
  uid=3000(user1) gid=3000(user1) groups=3000(user1),1(gorup1)

Of course, now the following record is already my LDAP server:
--
dn: cn=group,ou=group,dc=mydomain,dc=org
objectClass: posixGroup
cn: group1
gidNumber: 1
memberUid: user1
--

After I upgraded these 2 machines from RELENG_7 to RELENG_8,
to type `id user1' could only show the following information:
  uid=3000(user1) gid=3000(user1) groups=3000(user1)
This user's supplementary group was gone,
and he couldn't write any group-writable files which had gid 1 one the 2 
machines.
But in my other 2 machines that running on RELENG_7,
this problem is still not occured.

I have logged the behaviors of RELENG_7 & RELENG_8.
Here is the behavior when I type `id user1' on RELENG_7:
--
conn=1007 op=2 SRCH base="ou=people,dc=mydomain,dc=org" scope=1 deref=0 
filter="(&(objectClass=posixAccount)(uid=user1))"
conn=1007 op=2 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory 
loginShell gecos description objectClass shadowLastChange shadowMax 
shadowExpire loginClass

conn=1007 op=3 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0 
filter="(&(objectClass=posixGroup))"
conn=1007 op=3 SRCH attr=cn userPassword memberUid uniqueMember gidNumber

conn=1007 op=4 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0 
filter="(&(objectClass=posixGroup)(gidNumber=3000))"
conn=1007 op=4 SRCH attr=cn userPassword memberUid uniqueMember gidNumber

conn=1007 op=4 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0 
filter="(&(objectClass=posixGroup)(gidNumber=3000))"
conn=1007 op=4 SRCH attr=cn userPassword memberUid uniqueMember gidNumber

conn=1007 op=4 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0 
filter="(&(objectClass=posixGroup)(gidNumber=1))"
conn=1007 op=4 SRCH attr=cn userPassword memberUid uniqueMember gidNumber
--
In step 2, it tries to fetch out the full group list from my LDAP server.
According to this information, it can know what user1's supplementary groups 
are.

RELENG_8:
--
conn=1008 op=2 SRCH base="ou=people,dc=mydomain,dc=org" scope=1 deref=0 
filter="(&(objectClass=posixAccount)(uid=user1))"
conn=1008 op=2 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory 
loginShell gecos description objectClass shadowLastChange shadowMax 
shadowExpire loginClass

conn=1008 op=3 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0 
filter="(&(objectClass=posixGroup)(gidNumber=3000))"
conn=1008 op=3 SRCH attr=cn userPassword memberUid uniqueMember gidNumber

conn=1008 op=3 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0 
filter="(&(objectClass=posixGroup)(gidNumber=3000))"
conn=1008 op=3 SRCH attr=cn userPassword memberUid uniqueMember gidNumber
--
It never tried to get the group list from LDAP server,
hence it's impossible to know user1's supplementary groups.

The client settings on RELENG_7 & RELENG_8 are fully consistent,
so I don't think it's the problem of my config files.
Since my 4 machines use the same version of nss_ldap,
to downgrade nss_ldap's version for testing is meaningless.

Should this problem is a base system's bug?
___
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: powerd on 8.0, is it considered safe?

2010-03-08 Thread Tim Judd 


I've been running powerd for a while.  Been running it on an ASUS
B202.  It brought my freq down to 100mhz when I checked on it.
Stopping powerd brought the freq up to 1600, and restarting powerd
brought it back to 100mhz eventually.

You might need to load an ACPI module for your system.  Mine would be
acpi_asus.ko if I choose to run it.


I've never seen powerd to cause panics. I'm sure it's possible, but
I've never seen it.


Mark +1 for the success here on this side.
___
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: 8.0-RELEASE-p2: boot0cfg yields "vnode_pager_getpages: I/O read error"

2010-03-08 Thread Brian Conway 

On Mon, 8 Mar 2010, Maciej Milewski wrote:


Dnia poniedziałek, 8 marca 2010 o 04:00:02 Brian Conway napisał(a):

Greetings.  I'm testing NanoBSD images for eventual use in an Alix board
and have run into an issue with the boot0cfg lines in the update scripts,
in multiple environments.  Specifically, any use of boot0cfg yields a
successful output[1], followed by:
...
Any ideas?  Bug or
user error?  Thanks.

Brian Conway


Brian,
try changing in updatep1 and updatep2 to use gpart not boot0cfg:

#boot0cfg -s 1 -v ${NANO_DRIVE}
gpart set -a active -i 1 ${NANO_DRIVE}

I think is the problem. I was having similar errors as you while I was using
boot0cfg.

Maciej Milewski



Maciej,

Thanks, that resolved it and I've updated the scripts on my end.  It looks 
like nanobsd.sh is using boot0cfg successfully when it builds the images, 
so I'll submit a PR.


Brian Conway___
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"

Survey results very helpful, thanks! (was: Re: net.inet.tcp.timer_race: does anyone have a non-zero value?)

2010-03-08 Thread Robert Watson 


On Sun, 7 Mar 2010, Robert Watson wrote:

If your system shows a non-zero value, please send me a *private e-mail* 
with the output of that command, plus also the output of "sysctl kern.smp", 
"uptime", and a brief description of the workload and network interface 
configuration.  For example: it's a busy 8-core web server with roughly X 
connections/second, and that has three em network interfaces used to load 
balance from an upstream source.  IPSEC is used for management purposes (but 
not bulk traffic), and there's a local MySQL database.


I've now received a number of reports that confirm our suspicion that the race 
does occur, albeit very rarely, and particularly on systems with many cores or 
multiple network interfaces.  Fixing it is definitely on the TODO for 9.0, 
both to improve our ability to do multiple virtual network stacks, but with an 
appropriately scalable fix in mind given our improved TCP scalability for 9.0 
as well.


Thanks for all the responses,

Robert N M Watson
Computer Laboratory
University of Cambridge
___
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: powerd on 8.0, is it considered safe?

2010-03-08 Thread Alexander Motin 
Jeremy Chadwick wrote:
> I should note that on RELENG_7, EIST/SpeedStep didn't appear to work
> properly (cpufreq(4) driver reporting that the est piece wouldn't
> attach), which historically (for me) has resulted in ACPI throttling
> being done (which works).  Based on the sysctl output below, I believe
> acpi_perf is in use, but I'm not 100% certain.  The man page doesn't
> really disclose how to determine which driver is in use.
> 
> The X7SBA system in question is below.  Be aware I limit the lowest
> clock frequency to 1500MHz using debug.cpufreq.lowest="1500" in
> /boot/loader.conf, which is why you don't see anything lower in
> freq_levels.
> 
> dev.est.0.freq_settings: 3000/35000 2667/28000 2333/22000 2000/16000

This is the real set of EIST supported levels.

> dev.cpu.0.freq_levels: 3000/35000 2667/28000 2333/22000 2041/19250
2000/16000 1750/14000 1500/12000

All the rest of these are throttling.

I would recommend you to disable it by setting:
hint.p4tcc.0.disabled=1
hint.acpi_throttle.0.disabled=1

-- 
Alexander Motin
___
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: powerd on 8.0, is it considered safe?

2010-03-08 Thread Alexander Motin 
Alexander Motin wrote:
> Jeremy Chadwick wrote:
>> I should note that on RELENG_7, EIST/SpeedStep didn't appear to work
>> properly (cpufreq(4) driver reporting that the est piece wouldn't
>> attach), which historically (for me) has resulted in ACPI throttling
>> being done (which works).  Based on the sysctl output below, I believe
>> acpi_perf is in use, but I'm not 100% certain.  The man page doesn't
>> really disclose how to determine which driver is in use.
>>
>> The X7SBA system in question is below.  Be aware I limit the lowest
>> clock frequency to 1500MHz using debug.cpufreq.lowest="1500" in
>> /boot/loader.conf, which is why you don't see anything lower in
>> freq_levels.
>>
>> dev.est.0.freq_settings: 3000/35000 2667/28000 2333/22000 2000/16000
> 
> This is the real set of EIST supported levels.
> 
>> dev.cpu.0.freq_levels: 3000/35000 2667/28000 2333/22000 2041/19250
> 2000/16000 1750/14000 1500/12000
> 
> All the rest of these are throttling.
> 
> I would recommend you to disable it by setting:
> hint.p4tcc.0.disabled=1
> hint.acpi_throttle.0.disabled=1

> dev.cpu.1.cx_supported: C1/0 C2/85

And you may also enable C2 state, as your ACPI reports it, and it should
be safe now. To get maximum effect from it you may wish to reduce HZ.

-- 
Alexander Motin
___
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: is dtrace usable?

2010-03-08 Thread John Baldwin 
On Saturday 06 March 2010 11:00:12 am Robert Watson wrote:
> On Sat, 6 Mar 2010, Alexander Leidinger wrote:
> 
> >> Take a look at the DTrace configuration information here:
> >>
> >>http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/dtrace.html
> >
> > I've just reread it (despite the fact that I already used it). Some
> > comments:
> >
> > Last time I tried, I didn't see any problems by adding
> >  makeoptions WITH_CTF=yes
> > to the kernel config instead of doing
> >  make WITH_CTF=1 kernel
> >
> > Did I miss something, and if not, shouldn't we tell about the
> > makeoptions part instead (a kernel rebuild later will not cause
> > trouble when someone forgets to do the WITH_CTF part as it is already
> > in the kernel makefile)?
> 
> I'll leave John to answer this one, CC line broadended.

I would be very surprised if 'makeoptions WITH_CTF=yes' worked.  The many
times I and others have tried it it did not work.  Do you have a log of your
build showing the ctfconvert and ctfmerge command lines?

-- 
John Baldwin
___
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: powerd on 8.0, is it considered safe?

2010-03-08 Thread Dan Naumov 
OK, now I feel a bit stupid. The second half of my PR at
http://www.freebsd.org/cgi/query-pr.cgi?pr=144551 (anything related to
powerd behaviour) can be ignored. For testing purposes, I started
powerd in the foreground and observed it's behaviour. It works exactly
as advertised and apparently the very act of issuing a "sysctl -a |
grep dev.cpu.0.freq" command uses up a high % of CPU time for a
fraction of a second, resulting in confusing output, I was always
getting the highest cpu frequency state as the output. Testing powerd
in foreground however, shows correct behaviour, CPU is downclocked
both before and after issuing that command :)

Still doesn't explain why the system boots up at 1249 Mhz, but that's
not that big of an issue at this point now I see that powerd is
behaving correctly.

- Sincerely,
Dan Naumov
___
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"

ZFS hot spares

2010-03-08 Thread Steve Polyack 
ZFS in FreeBSD lacks at least one major feature from the Solaris 
version: hot spares.   There is a PR open at 
http://www.freebsd.org/cgi/query-pr.cgi?pr=134491, but there hasn't been 
any motion/thoughts posted on it since its creation almost one year ago.


I'm aware that on Solaris, hot spare replacement is handled by a few 
Solaris-specific daemons, zfs-retire and zfs-diagnose, which both plug 
into the Solaris FMA (Fault Management Architecture).  Have there been 
any thoughts on porting these over or getting something similar running 
within FreeBSD?  With all of the recent SATA/SAS CAM hotplug work now 
committed, it would be nice to have automatic replacement of hot spares 
with a future hot-replacement of the failed drive.


On the other side, I'd be interested in hearing if anyone has had 
success in rolling their own scripted solution: i.e. something which 
polls 'zpool status' looking for failed drives and performing hot-spare 
replacements automatically.


Thanks,
Steve Polyack

___
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: 8.0-RELEASE-p2: boot0cfg yields "vnode_pager_getpages: I/O read error"

2010-03-08 Thread Eugene Grosbein 
On Sun, Mar 07, 2010 at 10:00:02PM -0500, Brian Conway wrote:

> Greetings.  I'm testing NanoBSD images for eventual use in an Alix board
> and have run into an issue with the boot0cfg lines in the update scripts,
> in multiple environments.  Specifically, any use of boot0cfg yields a
> successful output[1], followed by:
> 
> vnode_pager_getpages: I/O read error
> 
> At this point, it looks like the command succeeded, but all reads and
> writes to disk fail:
> 
> # man init
> /usr/bin/man: Device not configured.
> 
> # touch /var/tmp/test
> /usr/bin/touch: Input/output error.

boot0cfg is broken since RELENG_6 (at least) for unknown reason.

For RELENG_6, there was a workaround (use kern.geom.debugflags=16)
but it does not work for RELENG_8 anymore.

Eugene Grosbein
___
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: Survey results very helpful, thanks! (was: Re: net.inet.tcp.timer_race: does anyone have a non-zero value?)

2010-03-08 Thread Doug Hardie 

On 8 March 2010, at 06:53, Robert Watson wrote:

> 
> On Sun, 7 Mar 2010, Robert Watson wrote:
> 
>> If your system shows a non-zero value, please send me a *private e-mail* 
>> with the output of that command, plus also the output of "sysctl kern.smp", 
>> "uptime", and a brief description of the workload and network interface 
>> configuration.  For example: it's a busy 8-core web server with roughly X 
>> connections/second, and that has three em network interfaces used to load 
>> balance from an upstream source.  IPSEC is used for management purposes (but 
>> not bulk traffic), and there's a local MySQL database.
> 
> I've now received a number of reports that confirm our suspicion that the 
> race does occur, albeit very rarely, and particularly on systems with many 
> cores or multiple network interfaces.  Fixing it is definitely on the TODO 
> for 9.0, both to improve our ability to do multiple virtual network stacks, 
> but with an appropriately scalable fix in mind given our improved TCP 
> scalability for 9.0 as well.

I run a number of 4 core systems with em interfaces.  These are production 
systems that are unmanned and located a long way from me.  Under unusual 
conditions it can take up to 6 hours to get there.  I have been waiting to 
switch to 8.0 because of the discussions on the em device and now it sounds 
like I had better just skip 8.x and wait for 9.  7.2 is working just 
fine.___
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: Survey results very helpful, thanks! (was: Re: net.inet.tcp.timer_race: does anyone have a non-zero value?)

2010-03-08 Thread Robert Watson 


On Mon, 8 Mar 2010, Doug Hardie wrote:

I run a number of 4 core systems with em interfaces.  These are production 
systems that are unmanned and located a long way from me.  Under unusual 
conditions it can take up to 6 hours to get there.  I have been waiting to 
switch to 8.0 because of the discussions on the em device and now it sounds 
like I had better just skip 8.x and wait for 9.  7.2 is working just fine.


Not sure that any information in this survey thread should be relevant to that 
decision.  This race has existed since before FreeBSD, having appeared in the 
original BSD network stack, and is just as present in FreeBSD 7.x as 8.x or 
9.x.  When I learned about the race during the early 7.x development cycle, I 
added a counter/statistic to measure how much it happened in practice, but was 
not able to exercise it in my testing, and so left the counter in to appear in 
7.0 and later so that we could perform this survey as core counts/etc 
increase.


The two likely outcomes were "it is never exercised" and "it is exercised but 
only very infrequently", neither really justifying the quite complex change to 
correct it given requirements at the time.  On-going development work on the 
virtual network stack is what justifies correcting the bug at this point, 
moving from detecting and handling the race to preventing it from occuring as 
an invariant.  The motivation here, BTW, is that we'd like to eliminate the 
type-stable storage requirement for connection state (which ensures that 
memory once used for a connection block is only ever used for connection 
blocks in the future), allowing memory to be fully freed when a virtual 
network stack is destroyed.  Using type-stable storage helped address this 
bug, but was primarily present to reduce the overhead of monitoring using 
netstat(1).  We'll now need to use a slightly more expensive solution (true 
reference counts) in that context, although in practice it will almost 
certainly be an unmeasurable cost.


Which is to say that while there might be something in the em/altq/... thread 
to reasonably lead you to avoid 8.0, nothing in the TCP timer race thread 
should do so, since it affects 7.2 just as much as 8.0.  Even if you do see a 
non-zero counter, that's not a matter for operational concern, just useful 
from the perspective of a network stack developer to understanding timing and 
behaviors in the stack.  :-)


Robert
___
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: Survey results very helpful, thanks!

2010-03-08 Thread Karl Denninger 
Doug Hardie wrote:
> On 8 March 2010, at 06:53, Robert Watson wrote:
>
>   
>> On Sun, 7 Mar 2010, Robert Watson wrote:
>>
>> 
>>> If your system shows a non-zero value, please send me a *private e-mail* 
>>> with the output of that command, plus also the output of "sysctl kern.smp", 
>>> "uptime", and a brief description of the workload and network interface 
>>> configuration.  For example: it's a busy 8-core web server with roughly X 
>>> connections/second, and that has three em network interfaces used to load 
>>> balance from an upstream source.  IPSEC is used for management purposes 
>>> (but not bulk traffic), and there's a local MySQL database.
>>>   
>> I've now received a number of reports that confirm our suspicion that the 
>> race does occur, albeit very rarely, and particularly on systems with many 
>> cores or multiple network interfaces.  Fixing it is definitely on the TODO 
>> for 9.0, both to improve our ability to do multiple virtual network stacks, 
>> but with an appropriately scalable fix in mind given our improved TCP 
>> scalability for 9.0 as well.
>> 
>
> I run a number of 4 core systems with em interfaces.  These are production 
> systems that are unmanned and located a long way from me.  Under unusual 
> conditions it can take up to 6 hours to get there.  I have been waiting to 
> switch to 8.0 because of the discussions on the em device and now it sounds 
> like I had better just skip 8.x and wait for 9.  7.2 is working just 
> fine.___
>   
I don't think its that simple.

I run a number of production systems with "em" interfaces, and they get
POUNDED.

None have had any trouble with 8.x.

$ ifconfig em0
em0: flags=8843 metric 0 mtu 1500
options=19b
ether 00:30:48:d2:5a:24
inet 67.23.181.70 netmask 0xff00 broadcast 67.23.181.255
media: Ethernet autoselect (100baseTX )
status: active

$ uptime
 3:27PM  up 61 days, 22:34, 1 user, load averages: 5.08, 4.48, 4.28

That's one of the busier ones; it's kinda loafing right now on network
I/O (running about 3mbps sustained) but typically operates in the
15-20mbps range to the wild wild net for 6-8 hours in the evening doing
what its doing now (handling a very busy forum) plus a few hundred
videocast streams

The last reboot was to replace a power strip in the colo rack with one
that had remote management capability.  It hasn't actually crashed
since, well, pretty much forever (it was running 7.x before 8.x went to
production status)

The box is a dual quad-core Xeon running the amd64 codebase.

-- Karl


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

ahci errors on 8-stable

2010-03-08 Thread Nenhum_de_Nos 
hail,

I've seen these errors in a production machine in deep disk load (scp and
bsdtar in heavy use):

ahcich0: Timeout on slot 1
ahcich0: is  cs  ss  rs  tfd 40 serr 
ahcich0: Timeout on slot 16
ahcich0: is  cs e000 ss  rs  tfd c0 serr 
tun0: link state changed to DOWN
tun0: link state changed to UP
ahcich0: Timeout on slot 13
ahcich0: is  cs  ss  rs  tfd 40 serr 
ahcich0: Timeout on slot 9
ahcich0: is  cs  ss  rs  tfd 40 serr 
tun0: link state changed to DOWN
tun0: link state changed to UP
tun0: link state changed to DOWN
tun0: link state changed to UP
tun0: link state changed to DOWN
tun0: link state changed to UP
ahcich0: Timeout on slot 30
ahcich0: is  cs 3800 ss  rs  tfd c0 serr 
ahcich0: Timeout on slot 11
ahcich0: is  cs  ss  rs  tfd 40 serr 
swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3, size: 4096
ahcich0: Timeout on slot 14
ahcich0: is  cs  ss  rs  tfd 40 serr 
tun0: link state changed to DOWN
tun0: link state changed to UP
ahcich0: Timeout on slot 9
ahcich0: is  cs  ss  rs  tfd 40 serr 
tun0: link state changed to DOWN
tun0: link state changed to UP
ahcich0: Timeout on slot 15
ahcich0: is  cs fc007fff ss  rs  tfd c0 serr 
ahcich0: Timeout on slot 14
ahcich0: is  cs 3ff8 ss  rs  tfd c0 serr 
ahcich0: Timeout on slot 6
ahcich0: is  cs 803f ss  rs  tfd c0 serr 
ahcich0: Timeout on slot 1
ahcich0: is  cs  ss  rs  tfd 40 serr 
ahcich0: Timeout on slot 1
ahcich0: is  cs  ss  rs  tfd 40 serr 
ahcich0: Timeout on slot 1
ahcich0: is  cs  ss  rs  tfd 40 serr 

[math...@optimus ~]$ uname -a
FreeBSD xxx 8.0-STABLE FreeBSD 8.0-STABLE #3: Wed Feb 10 11:09:34 BRT 2010
r...@xxx:/usr/obj/usr/src/sys/optimus  amd64

this machine has 6GB ram, but just around 5GB are available:

Copyright (c) 1992-2010 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.0-STABLE #3: Wed Feb 10 11:09:34 BRT 2010
r...@xxx:/usr/obj/usr/src/sys/optimus amd64
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Core(TM)2 Quad CPUQ9400  @ 2.66GHz (2666.38-MHz K8-class
CPU)
  Origin = "GenuineIntel"  Id = 0x1067a  Stepping = 10
  
Features=0xbfebfbff
[r...@optimus /var/log]# head -20 dmesg.yesterday
Copyright (c) 1992-2010 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.0-STABLE #3: Wed Feb 10 11:09:34 BRT 2010
r...@xxx:/usr/obj/usr/src/sys/optimus amd64
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Core(TM)2 Quad CPUQ9400  @ 2.66GHz (2666.38-MHz K8-class
CPU)
  Origin = "GenuineIntel"  Id = 0x1067a  Stepping = 10
  
Features=0xbfebfbff
  
Features2=0x408e3fd
  AMD Features=0x20100800
  AMD Features2=0x1
  TSC: P-state invariant
real memory  = 6442450944 (6144 MB)
avail memory = 6058479616 (5777 MB)
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s)
 cpu0 (BSP): APIC ID:  0

I use a small ZFS pool:

[r...@optimus /var/log]# zpool status
  pool: pool
 state: ONLINE
 scrub: none requested
config:

NAME  STATE READ WRITE CKSUM
pool  ONLINE   0 0 0
  label/zfs1  ONLINE   0 0 0
  label/zfs2  ONLINE   0 0 0

errors: No known data errors

using two 1TB disks.

should I fear these errors ?

thanks,

matheus


-- 
We will call you cygnus,
The God of balance you shall be

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

http://en.wikipedia.org/wiki/Posting_style
___
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: ahci errors on 8-stable

2010-03-08 Thread Jeremy Chadwick 
On Mon, Mar 08, 2010 at 06:38:02PM -0300, Nenhum_de_Nos wrote:
> I've seen these errors in a production machine in deep disk load (scp and
> bsdtar in heavy use):

Please provide the output from the following commands:

vmstat -i
pciconf -lvc

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
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: ahci errors on 8-stable

2010-03-08 Thread Nenhum_de_Nos 
On Mon, 8 Mar 2010 14:26:53 -0800
Jeremy Chadwick  wrote:

> On Mon, Mar 08, 2010 at 06:38:02PM -0300, Nenhum_de_Nos wrote:
> > I've seen these errors in a production machine in deep disk load (scp and
> > bsdtar in heavy use):
> 
> Please provide the output from the following commands:

As I had huge disk activity when those messages appeared, I did reboot after 
and now no more are there. I think the vmstat command should be issued when the 
problem was happening right ? (if so I can run the backup tar's and see what 
happens).

> vmstat -i
[math...@optimus /usr/home/matheus]$ vmstat -i
interrupt  total   rate
irq16: vgapci0+25054  1
irq18: uhci2 ehci0+   587787 23
irq21: ral0 uhci1 963763 39
irq22: fwohci0 1  0
irq23: uhci3 ehci1157584  6
cpu0: timer 49659956   2012
irq256: em0 55035142   2229
irq257: hdac01444588 58
irq258: ahci0 358695 14
cpu1: timer 49649636   2011
cpu2: timer 49722440   2014
cpu3: timer 49722444   2014
Total  257327090  10426

> pciconf -lvc
[r...@optimus ~]# pciconf -lvc
hos...@pci0:0:0:0:  class=0x06 card=0x50028086 chip=0x2e208086 rev=0x03 
hdr=0x00
vendor = 'Intel Corporation'
class  = bridge
subclass   = HOST-PCI
cap 09[e0] = vendor (length 12) Intel cap 1 version 1
 features: Quick Resume, SATA RAID-5, 4 PCI-e x1 slots, SATA 
RAID-0/1/10
pc...@pci0:0:1:0:   class=0x060400 card=0x50028086 chip=0x2e218086 rev=0x03 
hdr=0x01
vendor = 'Intel Corporation'
class  = bridge
subclass   = PCI-PCI
cap 0d[88] = PCI Bridge card=0x50028086
cap 01[80] = powerspec 3  supports D0 D3  current D0
cap 05[90] = MSI supports 1 message
cap 10[a0] = PCI-Express 2 root port max data 128(128) link x16(x16)
no...@pci0:0:3:0:   class=0x078000 card=0x50028086 chip=0x2e248086 rev=0x03 
hdr=0x00
vendor = 'Intel Corporation'
class  = simple comms
cap 01[50] = powerspec 3  supports D0 D3  current D0
cap 05[8c] = MSI supports 1 message, 64 bit
e...@pci0:0:25:0:class=0x02 card=0x50028086 chip=0x10cd8086 
rev=0x00 hdr=0x00
vendor = 'Intel Corporation'
class  = network
subclass   = ethernet
cap 01[c8] = powerspec 2  supports D0 D3  current D0
cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
cap 09[e0] = vendor (length 6) Intel cap 2 version 0
uh...@pci0:0:26:0:  class=0x0c0300 card=0x50028086 chip=0x3a378086 rev=0x00 
hdr=0x00
vendor = 'Intel Corporation'
device = 'USB UHCI Controller *4'
class  = serial bus
subclass   = USB
cap 09[50] = vendor (length 6) Intel cap 2 version 0
uh...@pci0:0:26:1:  class=0x0c0300 card=0x50028086 chip=0x3a388086 rev=0x00 
hdr=0x00
vendor = 'Intel Corporation'
device = 'USB UHCI Controller *5'
class  = serial bus
subclass   = USB
cap 09[50] = vendor (length 6) Intel cap 2 version 0
uh...@pci0:0:26:2:  class=0x0c0300 card=0x50028086 chip=0x3a398086 rev=0x00 
hdr=0x00
vendor = 'Intel Corporation'
device = 'USB UHCI Controller *6'
class  = serial bus
subclass   = USB
cap 09[50] = vendor (length 6) Intel cap 2 version 0
eh...@pci0:0:26:7:  class=0x0c0320 card=0x50028086 chip=0x3a3c8086 rev=0x00 
hdr=0x00
vendor = 'Intel Corporation'
device = 'USB EHCI Controller *2'
class  = serial bus
subclass   = USB
cap 01[50] = powerspec 2  supports D0 D3  current D0
cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14
cap 09[98] = vendor (length 6) Intel cap 2 version 0
hd...@pci0:0:27:0:  class=0x040300 card=0x50028086 chip=0x3a3e8086 rev=0x00 
hdr=0x00
vendor = 'Intel Corporation'
device = 'HD Audio Controller'
class  = multimedia
subclass   = HDA
cap 01[50] = powerspec 2  supports D0 D3  current D0
cap 05[60] = MSI supports 1 message, 64 bit enabled with 1 message
cap 10[70] = PCI-Express 1 root endpoint max data 128(128) link x0(x0)
uh...@pci0:0:29:0:  class=0x0c0300 card=0x50028086 chip=0x3a348086 rev=0x00 
hdr=0x00
vendor = 'Intel Corporation'
device = 'USB UHCI Controller *1'
class  = serial bus
subclass   = USB
cap 09[50] = vendor (length 6) Intel cap 2 version 0
uh...@pci0:0:29:1:  class=0x0c0300 card=0x50028086 chip=0x3a358086 rev=0x00 
hdr=0x00
vendor = 'Intel Corporation'
device = 'USB UHCI Controller *2'
class  = serial bus
subclass   = USB
cap 09[50] = vendor (length 6) Intel cap 2 version 0
uh...@pci0:0:29:2:  class=0x0c0300 card=0x50028086 chip=0x3a368086 rev=0x00 
hdr=0x00
vendor

Re: Supplementary groups on LDAP cannot work with RELENG_8 + nss_ldap

2010-03-08 Thread Peter C. Lai 
Unable to reproduce, at least on a brand new 8-R install.
Did you make sure you correctly merged /etc/nsswitch.conf during mergemaster?

On 2010-03-08 09:07:12PM +0800, Ling-hua Tseng wrote:
> Today I upgraded 2 of my 4 machines from RELENG_7 to RELENG_8.
> Both of the 2 machines are just LDAP clients.
> My LDAP server is still running on RELENG_7,
> and the remained one is also a LDAP client.
> All of them were installed OpenLDAP-2.4.21 and nss_ldap-1.265_3.
> 
> Before I upgrades my system, everything works properly.
> I added a group named `group1' on LDAP server,
> and then add a user named `user1' to this group.
> I can type `id user1' to see the following line:
>   uid=3000(user1) gid=3000(user1) groups=3000(user1),1(gorup1)
> 
> Of course, now the following record is already my LDAP server:
> --
> dn: cn=group,ou=group,dc=mydomain,dc=org
> objectClass: posixGroup
> cn: group1
> gidNumber: 1
> memberUid: user1
> --
> 
> After I upgraded these 2 machines from RELENG_7 to RELENG_8,
> to type `id user1' could only show the following information:
>   uid=3000(user1) gid=3000(user1) groups=3000(user1)
> This user's supplementary group was gone,
> and he couldn't write any group-writable files which had gid 1 one the 2 
> machines.
> But in my other 2 machines that running on RELENG_7,
> this problem is still not occured.
> 
> I have logged the behaviors of RELENG_7 & RELENG_8.
> Here is the behavior when I type `id user1' on RELENG_7:
> --
> conn=1007 op=2 SRCH base="ou=people,dc=mydomain,dc=org" scope=1 deref=0 
> filter="(&(objectClass=posixAccount)(uid=user1))"
> conn=1007 op=2 SRCH attr=uid userPassword uidNumber gidNumber cn 
> homeDirectory loginShell gecos description objectClass shadowLastChange 
> shadowMax shadowExpire loginClass
> 
> conn=1007 op=3 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0 
> filter="(&(objectClass=posixGroup))"
> conn=1007 op=3 SRCH attr=cn userPassword memberUid uniqueMember gidNumber
> 
> conn=1007 op=4 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0 
> filter="(&(objectClass=posixGroup)(gidNumber=3000))"
> conn=1007 op=4 SRCH attr=cn userPassword memberUid uniqueMember gidNumber
> 
> conn=1007 op=4 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0 
> filter="(&(objectClass=posixGroup)(gidNumber=3000))"
> conn=1007 op=4 SRCH attr=cn userPassword memberUid uniqueMember gidNumber
> 
> conn=1007 op=4 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0 
> filter="(&(objectClass=posixGroup)(gidNumber=1))"
> conn=1007 op=4 SRCH attr=cn userPassword memberUid uniqueMember gidNumber
> --
> In step 2, it tries to fetch out the full group list from my LDAP server.
> According to this information, it can know what user1's supplementary groups 
> are.
> 
> RELENG_8:
> --
> conn=1008 op=2 SRCH base="ou=people,dc=mydomain,dc=org" scope=1 deref=0 
> filter="(&(objectClass=posixAccount)(uid=user1))"
> conn=1008 op=2 SRCH attr=uid userPassword uidNumber gidNumber cn 
> homeDirectory loginShell gecos description objectClass shadowLastChange 
> shadowMax shadowExpire loginClass
> 
> conn=1008 op=3 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0 
> filter="(&(objectClass=posixGroup)(gidNumber=3000))"
> conn=1008 op=3 SRCH attr=cn userPassword memberUid uniqueMember gidNumber
> 
> conn=1008 op=3 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0 
> filter="(&(objectClass=posixGroup)(gidNumber=3000))"
> conn=1008 op=3 SRCH attr=cn userPassword memberUid uniqueMember gidNumber
> --
> It never tried to get the group list from LDAP server,
> hence it's impossible to know user1's supplementary groups.
> 
> The client settings on RELENG_7 & RELENG_8 are fully consistent,
> so I don't think it's the problem of my config files.
> Since my 4 machines use the same version of nss_ldap,
> to downgrade nss_ldap's version for testing is meaningless.
> 
> Should this problem is a base system's bug?
> ___
> 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"

-- 
===
Peter C. Lai | Bard College at Simon's Rock
Systems Administrator| 84 Alford Rd.
Information Technology Svcs. | Gt. Barrington, MA 01230 USA
peter AT simons-rock.edu | (413) 528-7428
===

___
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: Supplementary groups on LDAP cannot work with RELENG_8 +nss_ldap

2010-03-08 Thread Linghua Tseng 

Yes, I'm sure.

Here is the output of `diff -u /usr/src/etc/nsswitch.conf /etc/nsswitch.conf'.
--- /usr/src/etc/nsswitch.conf  2010-03-08 09:04:25.0 +0800
+++ /etc/nsswitch.conf  2010-03-08 18:01:08.0 +0800
@@ -1,13 +1,13 @@
#
# nsswitch.conf(5) - name service switch configuration file
-# $FreeBSD: src/etc/nsswitch.conf,v 1.1.10.1 2009/08/03 08:13:06 kensmith Exp $
+# $FreeBSD: src/etc/nsswitch.conf,v 1.1 2006/05/03 15:14:47 ume Exp $
#
group: compat
-group_compat: nis
+group_compat: ldap nis
hosts: files dns
networks: files
passwd: compat
-passwd_compat: nis
+passwd_compat: ldap nis
shells: files
services: compat
services_compat: nis

The line `+:*' has already put into /etc/master.passwd,
and the line `+:*::' has already put into /etc/group.

In fact, my 2 machines were upgraded on different days.
The 1st one's uname: 8.0-STABLE FreeBSD 8.0-STABLE #0: Mon Mar  8 10:21:45 CST 
2010
The 2nd one's uname: 8.0-STABLE FreeBSD 8.0-STABLE #0: Wed Feb 24 03:46:38 CST 
2010
Both of them cannot work properly.
It can prove that this problem can be reproduced since 2/24 or earlier.

Besides, I precisely followed the 11-step instructions that described in 
/usr/src/Makefile for upgrading my systems.
To do mergemaster is never a big problem for me because I've used it since this 
script was born.

/usr/local/etc/ldap.conf & /usr/local/etc/nss_ldap.conf are also consistent on 
my 4 machines.
These settings works properly for my RELENG_7 machines, but RELENG_8 ones.
By the way, I don't use nscd because it always caches users' login shell so 
that users cannot update it immediately.

I also installed pam_ldap, and I have read this old topic:
 http://lists.freebsd.org/pipermail/freebsd-stable/2008-March/041393.html
It says to set `bind_policy' to `hard' can resolve this issue, but it cannot 
work for me.



--
From: "Peter C. Lai" 
Sent: Tuesday, March 09, 2010 8:08 AM
To: "Ling-hua Tseng" 
Cc: 
Subject: Re: Supplementary groups on LDAP cannot work with RELENG_8 +nss_ldap


Unable to reproduce, at least on a brand new 8-R install.
Did you make sure you correctly merged /etc/nsswitch.conf during mergemaster?

On 2010-03-08 09:07:12PM +0800, Ling-hua Tseng wrote:

Today I upgraded 2 of my 4 machines from RELENG_7 to RELENG_8.
Both of the 2 machines are just LDAP clients.
My LDAP server is still running on RELENG_7,
and the remained one is also a LDAP client.
All of them were installed OpenLDAP-2.4.21 and nss_ldap-1.265_3.

Before I upgrades my system, everything works properly.
I added a group named `group1' on LDAP server,
and then add a user named `user1' to this group.
I can type `id user1' to see the following line:
  uid=3000(user1) gid=3000(user1) groups=3000(user1),1(gorup1)

Of course, now the following record is already my LDAP server:
--
dn: cn=group,ou=group,dc=mydomain,dc=org
objectClass: posixGroup
cn: group1
gidNumber: 1
memberUid: user1
--

After I upgraded these 2 machines from RELENG_7 to RELENG_8,
to type `id user1' could only show the following information:
  uid=3000(user1) gid=3000(user1) groups=3000(user1)
This user's supplementary group was gone,
and he couldn't write any group-writable files which had gid 1 one the 2 
machines.
But in my other 2 machines that running on RELENG_7,
this problem is still not occured.

I have logged the behaviors of RELENG_7 & RELENG_8.
Here is the behavior when I type `id user1' on RELENG_7:
--
conn=1007 op=2 SRCH base="ou=people,dc=mydomain,dc=org" scope=1 deref=0 
filter="(&(objectClass=posixAccount)(uid=user1))"
conn=1007 op=2 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass 
shadowLastChange shadowMax shadowExpire loginClass


conn=1007 op=3 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0 
filter="(&(objectClass=posixGroup))"
conn=1007 op=3 SRCH attr=cn userPassword memberUid uniqueMember gidNumber

conn=1007 op=4 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0 
filter="(&(objectClass=posixGroup)(gidNumber=3000))"
conn=1007 op=4 SRCH attr=cn userPassword memberUid uniqueMember gidNumber

conn=1007 op=4 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0 
filter="(&(objectClass=posixGroup)(gidNumber=3000))"
conn=1007 op=4 SRCH attr=cn userPassword memberUid uniqueMember gidNumber

conn=1007 op=4 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0 
filter="(&(objectClass=posixGroup)(gidNumber=1))"
conn=1007 op=4 SRCH attr=cn userPassword memberUid uniqueMember gidNumber
--
In step 2, it tries to fetch out the full group list from my LDAP server.
According to this information, it can know what user1's supplementary groups 
are.

RELENG_8:
--
conn=1008 op=2 SRCH base="ou=people,dc=mydomain,dc=org" scope=1 deref=0 
filter="(&(objectClass=posixAccount)(uid=user1))"
conn=1008 op=2 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass 
shadowLastChange shadow

Please unsubscribe

2010-03-08 Thread Thomas Jepsen 

Den 08-03-2010 13:00, freebsd-stable-requ...@freebsd.org skrev:

Send freebsd-stable mailing list submissions to
freebsd-stable@freebsd.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
or, via email, send a message with subject or body 'help' to
freebsd-stable-requ...@freebsd.org

You can reach the person managing the list at
freebsd-stable-ow...@freebsd.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-stable digest..."


Today's Topics:

1. Re: net.inet.tcp.timer_race: does anyone have a non-zero
   value? (Mikolaj Golub)
2. Re: net.inet.tcp.timer_race: does anyone have a non-zero
   value? (Robert N. M. Watson)
3. Re: virtualbox status on 8.0-STABLE i386 (Alexander Eichner)
4. Reminder about your invitation from Igor Lyapin
   (Igor Lyapin (LinkedIn Invitations))
5. ntpd multicast TTL (Christian Weisgerber)
6. Re: FreeBSD-8.0 802.11n support with ath/mwl (Sam Leffler)
7. Re: FreeBSD-8.0 802.11n support with ath/mwl (Jim Pingle)
8. Re: em(4) interface hangs under 8.0-RELEASE (Max Laier)
9. Re: em(4) interface hangs under 8.0-RELEASE (Thomas Hurst)
   10. FBSD 8.0&  ZFS Issue..   default_perms_for_dir (Howard Leadmon)
   11. 8.0-RELEASE-p2: boot0cfg yields "vnode_pager_getpages: I/O
   read error" (Brian Conway)
   12. Re: virtualbox status on 8.0-STABLE i386 (Mikolaj Golub)
   13. Re: ntpd multicast TTL (John Marshall)
   14. powerd on 8.0, is it considered safe? (Dan Naumov)
   15. Re: powerd on 8.0, is it considered safe? (Jeremy Chadwick)
   16. Re: 8.0-RELEASE-p2: boot0cfg yields "vnode_pager_getpages:
   I/O read error" (Maciej Milewski)


--

Message: 1
Date: Sun, 07 Mar 2010 14:33:40 +0200
From: Mikolaj Golub
Subject: Re: net.inet.tcp.timer_race: does anyone have a non-zero
value?
To: Robert Watson
Cc: sta...@freebsd.org, curr...@freebsd.org
Message-ID:<86d3zgcnvf@kopusha.onet>
Content-Type: text/plain; charset=us-ascii

On Sun, 7 Mar 2010 11:59:35 + (GMT) Robert Watson wrote:

   

Please check the results of the following command:

   % sysctl net.inet.tcp.timer_race
   net.inet.tcp.timer_race: 0
 

Are the results for FreeBSD7 look interesting for you? Because currently we
have mostly FreeBSD7.1 hosts in production and I observe nonzero values on 8
hosts (about 15%). I would send more details to you privately if you are
interested.

   




No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.733 / Virus Database: 271.1.1/2730 - Release Date: 03/08/10 
08:34:00

   


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