Re: status of flash9/flash10 support in RELENG_7 ?

2009-08-07 Thread Marc Fonvieille
On Fri, Aug 07, 2009 at 02:52:10AM +0400, Boris Samorodov wrote:
 On Thu, 6 Aug 2009 23:14:01 +0200 Harald Weis wrote:
 
  Portmaster is unable to fetch install_flash_player_9.tar.gz and I
 
 Anyway it's not a portmaster...
 
  cannot find the file manually. Seems to have disappeared from earth.
 
 Something (system, ports, network or else) is broken:
 -
 tba% LANG=C date
 Fri Aug  7 02:50:06 MSD 2009
 tba% fetch 
 http://download.macromedia.com/pub/flashplayer/installers/current/9/install_flash_player_9.tar.gz
 install_flash_player_9.tar.gz 100% of 2986 kB 1542 kBps
 -


To add something to Boris' words, the methods given in the Handbook are
reliable and tested methods (many times on various systems).  If they do
not work, it's either a port problem (vulnerabilities, ports tree, etc.)
or a system problem.

Regarding the distfile, it seems they changed the file:
= Attempting to fetch from
http://download.macromedia.com/pub/flashplayer/installers/current/9/.
fetch: 
http://download.macromedia.com/pub/flashplayer/installers/current/9/install_flash_player_9.tar.gz:
 size mismatch: expected 3057882, actual 3057910


-- 
Marc
___
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: status of flash9/flash10 support in RELENG_7 ?

2009-08-07 Thread Boris Samorodov
On Fri, 7 Aug 2009 09:18:40 +0200 Marc Fonvieille wrote:
 On Fri, Aug 07, 2009 at 02:52:10AM +0400, Boris Samorodov wrote:
  On Thu, 6 Aug 2009 23:14:01 +0200 Harald Weis wrote:
  
   Portmaster is unable to fetch install_flash_player_9.tar.gz and I
  
  Anyway it's not a portmaster...
  
   cannot find the file manually. Seems to have disappeared from earth.
  
  Something (system, ports, network or else) is broken:
  -
  tba% LANG=C date
  Fri Aug  7 02:50:06 MSD 2009
  tba% fetch 
  http://download.macromedia.com/pub/flashplayer/installers/current/9/install_flash_player_9.tar.gz
  install_flash_player_9.tar.gz 100% of 2986 kB 1542 kBps
  -
[...]
 Regarding the distfile, it seems they changed the file:
 = Attempting to fetch from
 http://download.macromedia.com/pub/flashplayer/installers/current/9/.
 fetch: 
 http://download.macromedia.com/pub/flashplayer/installers/current/9/install_flash_player_9.tar.gz:
  size mismatch: expected 3057882, actual 3057910

Yep, here is the difference between just a plain moan and strict
miagnostic message. ;-) It's as simple as a new version was released!

I've posted a patch to freebsd-emulation@ ML. Please, give it a try:
http://lists.freebsd.org/pipermail/freebsd-emulation/2009-August/006622.html


-- 
WBR, bsam
___
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


panic in vgonel()

2009-08-07 Thread pluknet
This is on 7.2-R amd64.

I'm curious if it might be due to glusterfs on it.

Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 03
fault virtual address   = 0x0
fault code  = supervisor write data, page not present
instruction pointer = 0x8:0x805a52ba
stack pointer   = 0x10:0xfffefc3474a0
frame pointer   = 0x10:0xfffefc347510
code segment= base 0x0, limit 0xf, type
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 35425 (find)

db bt
Tracing pid 35425 tid 100194 td 0xff003c165370
vgonel() at vgonel+0x1aa
vnlru_free() at vnlru_free+0x36c
getnewvnode() at getnewvnode+0x281
ffs_vgetf() at ffs_vgetf+0xdf
ufs_lookup() at ufs_lookup+0x2dd
vfs_cache_lookup() at vfs_cache_lookup+0xf3
VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x40
lookup() at lookup+0x598
namei() at namei+0x33e
kern_lstat() at kern_lstat+0x5e
lstat() at lstat+0x2a
syscall() at syscall+0x256
Xfast_syscall() at Xfast_syscall+0xab
--- syscall (190, FreeBSD ELF64, lstat), rip = 0x80071063c, rsp =
0x7fffea48, rbp = 0x800a06910 ---
db show pcpu
cpuid= 3
curthread= 0xff003c165370: pid 35425 find
curpcb   = 0xfffefc347d40
fpcurthread  = none
idlethread   = 0xff000143c370: pid 15 idle: cpu3
db show proc 35425
Process 35425 (find) at 0xff003c1868f0:
 state: NORMAL
 uid: 0  gids: 0, 0, 5
 parent: pid 35421 at 0xff0004855000
 ABI: FreeBSD ELF64
 arguments: find
 threads: 1
100194   Run CPU 3   find
db show allpcpu
Current CPU: 3

cpuid= 0
curthread= 0xff00014306e0: pid 18 idle: cpu0
curpcb   = 0xfffe80064d40
fpcurthread  = none
idlethread   = 0xff00014306e0: pid 18 idle: cpu0

cpuid= 1
curthread= 0xff0001430a50: pid 17 idle: cpu1
curpcb   = 0xfffe8005fd40
fpcurthread  = none
idlethread   = 0xff0001430a50: pid 17 idle: cpu1

cpuid= 2
curthread= 0xff000143c000: pid 16 idle: cpu2
curpcb   = 0xfffe8005ad40
fpcurthread  = none
idlethread   = 0xff000143c000: pid 16 idle: cpu2

cpuid= 3
curthread= 0xff003c165370: pid 35425 find
curpcb   = 0xfffefc347d40
fpcurthread  = none
idlethread   = 0xff000143c370: pid 15 idle: cpu3

cpuid= 4
curthread= 0xff000143c6e0: pid 14 idle: cpu4
curpcb   = 0xfffe80050d40
fpcurthread  = none
idlethread   = 0xff000143c6e0: pid 14 idle: cpu4

cpuid= 5
curthread= 0xff000142e000: pid 13 idle: cpu5
curpcb   = 0xfffe8004bd40
fpcurthread  = none
idlethread   = 0xff000142e000: pid 13 idle: cpu5

cpuid= 6
curthread= 0xff000142e370: pid 12 idle: cpu6
fpcurthread  = none
idlethread   = 0xff000142e370: pid 12 idle: cpu6

cpuid= 7
curthread= 0xff000142e6e0: pid 11 idle: cpu7
curpcb   = 0xfffe80041d40
fpcurthread  = none
idlethread   = 0xff000142e6e0: pid 11 idle: cpu7
db show lockedvnods
Locked vnodes

0xff0033b6a1f8: tag ufs, type VDIR
usecount 3, writecount 0, refcount 6 mountedhere 0
flags ()
v_object 0xff001a78ebc8 ref 0 pages 1
 lock type ufs: EXCL (count 1) by thread 0xff003c165370 (pid 35425)
ino 143271749, on dev aacd0s1g

db ps
  pid  ppid  pgrp   uid   state   wmesg wchancmd
35428 35426 35316 0  S   piperd   0xff00180802e8 cat
35426 35421 35316 0  S   wait 0xff0004dee8f0 sh
35425 35421 35316 0  R   CPU 3   find
35421 35418 35316 0  S   wait 0xff0004855000 sh
35420 35419 35316 0  S   piperd   0xff003c16d000 mail
35419 35411 35316 0  S   wait 0xff003c68a478 sh
35418 35411 35316 0  S   wait 0xff003cabe000 sh
35411 35410 35316 0  S   wait 0xff001856c478 sh
35410 35325 35316 0  S   wait 0xff00048568f0 sh
35327 35326 35316 0  S   piperd   0xff003c16e000 mail
35326 35318 35316 0  S   wait 0xff0004698478 sh
35325 35318 35316 0  S   wait 0xff003c331478 sh
35318 35316 35316 0  S   wait 0xff00181628f0 sh
35316 35314 35316 0  Ss  wait 0xff0004975478 sh
35314   685   685 0  S   piperd   0xff00184d92e8 cron
34062 1 34062 0  Ss  (threaded)  glusterfsd
100361   S   fu_msg   0xff00183f2c00 glusterfsd
100216   S   nanslp   0x80b681a8 glusterfsd
100073   S   select   0x80b808d0 glusterfsd
34050 1 34050 0  Rs  (threaded)  glusterfsd
100086   S   nanslp   0x80b681a8 glusterfsd
100322   RunQglusterfsd
33886 1 33886 0  Ss  select   0x80b808d0 mountd
31645 31611 3161180  S   

Re: panic in vgonel()

2009-08-07 Thread Kostik Belousov
On Fri, Aug 07, 2009 at 03:37:11PM +0400, pluknet wrote:
 This is on 7.2-R amd64.
 
 I'm curious if it might be due to glusterfs on it.
 
 Fatal trap 12: page fault while in kernel mode
 cpuid = 3; apic id = 03
 fault virtual address   = 0x0
 fault code  = supervisor write data, page not present
 instruction pointer = 0x8:0x805a52ba
 stack pointer   = 0x10:0xfffefc3474a0
 frame pointer   = 0x10:0xfffefc347510
 code segment= base 0x0, limit 0xf, type
 = DPL 0, pres 1, long 1, def32 0, gran 1
 processor eflags= interrupt enabled, resume, IOPL = 0
 current process = 35425 (find)
 
 db bt
 Tracing pid 35425 tid 100194 td 0xff003c165370
 vgonel() at vgonel+0x1aa
 vnlru_free() at vnlru_free+0x36c
 getnewvnode() at getnewvnode+0x281
 ffs_vgetf() at ffs_vgetf+0xdf
 ufs_lookup() at ufs_lookup+0x2dd
 vfs_cache_lookup() at vfs_cache_lookup+0xf3
 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x40
 lookup() at lookup+0x598
 namei() at namei+0x33e
 kern_lstat() at kern_lstat+0x5e
 lstat() at lstat+0x2a
 syscall() at syscall+0x256
 Xfast_syscall() at Xfast_syscall+0xab
 --- syscall (190, FreeBSD ELF64, lstat), rip = 0x80071063c, rsp =
 0x7fffea48, rbp = 0x800a06910 ---

Did you got the vmcore ? If yes, please find the value for vgonel()
argument, vp, and print the vnode content.

Regardless of this, look up the source line for vgonel+0x1aa. 


pgpr8VVxntTxR.pgp
Description: PGP signature


Re: status of flash9/flash10 support in RELENG_7 ?

2009-08-07 Thread Boris Samorodov
On Fri, 07 Aug 2009 14:00:02 +0400 Boris Samorodov wrote:

 I've posted a patch to freebsd-emulation@ ML. Please, give it a try:
 http://lists.freebsd.org/pipermail/freebsd-emulation/2009-August/006622.html

Already committed. Please, give it a try.

-- 
WBR, Boris Samorodov (bsam)
Research Engineer, http://www.ipt.ru Telephone  Internet SP
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: panic in vgonel()

2009-08-07 Thread pluknet
2009/8/7 Kostik Belousov kostik...@gmail.com:
 On Fri, Aug 07, 2009 at 03:37:11PM +0400, pluknet wrote:
 This is on 7.2-R amd64.

 I'm curious if it might be due to glusterfs on it.

 Fatal trap 12: page fault while in kernel mode
 cpuid = 3; apic id = 03
 fault virtual address   = 0x0
 fault code              = supervisor write data, page not present
 instruction pointer     = 0x8:0x805a52ba
 stack pointer           = 0x10:0xfffefc3474a0
 frame pointer           = 0x10:0xfffefc347510
 code segment            = base 0x0, limit 0xf, type
                         = DPL 0, pres 1, long 1, def32 0, gran 1
 processor eflags        = interrupt enabled, resume, IOPL = 0
 current process         = 35425 (find)

 db bt
 Tracing pid 35425 tid 100194 td 0xff003c165370
 vgonel() at vgonel+0x1aa
 vnlru_free() at vnlru_free+0x36c
 getnewvnode() at getnewvnode+0x281
 ffs_vgetf() at ffs_vgetf+0xdf
 ufs_lookup() at ufs_lookup+0x2dd
 vfs_cache_lookup() at vfs_cache_lookup+0xf3
 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x40
 lookup() at lookup+0x598
 namei() at namei+0x33e
 kern_lstat() at kern_lstat+0x5e
 lstat() at lstat+0x2a
 syscall() at syscall+0x256
 Xfast_syscall() at Xfast_syscall+0xab
 --- syscall (190, FreeBSD ELF64, lstat), rip = 0x80071063c, rsp =
 0x7fffea48, rbp = 0x800a06910 ---

 Did you got the vmcore ? If yes, please find the value for vgonel()
 argument, vp, and print the vnode content.

I didn't. Same problem as in my another mail. :(


 Regardless of this, look up the source line for vgonel+0x1aa.


I could resolve only address which belongs to instruction pointer
= 0x8:0x805a52ba
(eh, I don't know if I should sum these numbers, so I did this for both cases):

dev2# addr2line -e /boot/kernel/kernel.symbols 0x805a52ba
/usr/src/sys/kern/vfs_subr.c:979
delmntque():TAILQ_REMOVE(mp-mnt_nvnodelist, vp, v_nmntvnodes);

dev2# addr2line -e /boot/kernel/kernel.symbols 0x805a52c2
/usr/src/sys/kern/vfs_subr.c:981
delmntque():MNT_REL(mp);

-- 
wbr,
pluknet
___
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


nsswitch.conf bad configuration?

2009-08-07 Thread Jordi Espasa Clofent

Hi all,

I've a lot of servers (6.3,6.4, 7.1, 7.2...) login against centralized 
LDAP account server.  All works fine, but I can see in LDAP logs:


# cat /var/log/syslog | grep uid= | awk '{print $12}'
filter=((objectClass=posixAccount)(uid=mailer-daemon))
filter=((objectClass=posixAccount)(uid=mailer-daemon))
filter=((objectClass=posixAccount)(uid=mailer-daemon))
filter=((objectClass=posixAccount)(uid=mailer-daemon))
filter=((objectClass=posixAccount)(uid=nobody))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=nobody))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=nobody))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=nobody))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=xatlantax))
filter=((objectClass=posixAccount)(uid=nobody))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=oscar))
filter=((objectClass=posixGroup)(|(memberUid=oscar)(uniqueMember=uid=oscar,ou=cat,ou=tecnic,dc=mycompany,dc=com)))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=bambinnos))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=skateria))
filter=((objectClass=posixAccount)(uid=verom_40))
filter=((objectClass=posixAccount)(uid=iticlab))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=mailnull))
filter=((objectClass=posixAccount)(uid=mailnull))
filter=((objectClass=posixAccount)(uid=sendmail))
filter=((objectClass=posixAccount)(uid=sendmail))
filter=((objectClass=posixAccount)(uid=nobody))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=nobody))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=nobody))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=cdmon))
filter=((objectClass=posixAccount)(uid=nobody))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=nobody))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=nobody))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=nobody))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=nobody))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=nobody))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=cdmon))
filter=((objectClass=posixAccount)(uid=paola))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=mailnull))
filter=((objectClass=posixAccount)(uid=mailnull))
filter=((objectClass=posixAccount)(uid=mailnull))
filter=((objectClass=posixAccount)(uid=sendmail))
filter=((objectClass=posixAccount)(uid=sendmail))
filter=((objectClass=posixAccount)(uid=sendmail))
filter=((objectClass=posixAccount)(uid=mailnull))
filter=((objectClass=posixAccount)(uid=sendmail))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=root))
filter=((objectClass=posixAccount)(uid=nobody))
filter=((objectClass=posixAccount)(uid=postfix))
filter=((objectClass=posixAccount)(uid=root))

Re: panic in vgonel()

2009-08-07 Thread Kostik Belousov
On Fri, Aug 07, 2009 at 04:37:07PM +0400, pluknet wrote:
 2009/8/7 Kostik Belousov kostik...@gmail.com:
  On Fri, Aug 07, 2009 at 03:37:11PM +0400, pluknet wrote:
  This is on 7.2-R amd64.
 
  I'm curious if it might be due to glusterfs on it.
 
  Fatal trap 12: page fault while in kernel mode
  cpuid = 3; apic id = 03
  fault virtual address   = 0x0
  fault code              = supervisor write data, page not present
  instruction pointer     = 0x8:0x805a52ba
  stack pointer           = 0x10:0xfffefc3474a0
  frame pointer           = 0x10:0xfffefc347510
  code segment            = base 0x0, limit 0xf, type
                          = DPL 0, pres 1, long 1, def32 0, gran 1
  processor eflags        = interrupt enabled, resume, IOPL = 0
  current process         = 35425 (find)
 
  db bt
  Tracing pid 35425 tid 100194 td 0xff003c165370
  vgonel() at vgonel+0x1aa
  vnlru_free() at vnlru_free+0x36c
  getnewvnode() at getnewvnode+0x281
  ffs_vgetf() at ffs_vgetf+0xdf
  ufs_lookup() at ufs_lookup+0x2dd
  vfs_cache_lookup() at vfs_cache_lookup+0xf3
  VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x40
  lookup() at lookup+0x598
  namei() at namei+0x33e
  kern_lstat() at kern_lstat+0x5e
  lstat() at lstat+0x2a
  syscall() at syscall+0x256
  Xfast_syscall() at Xfast_syscall+0xab
  --- syscall (190, FreeBSD ELF64, lstat), rip = 0x80071063c, rsp =
  0x7fffea48, rbp = 0x800a06910 ---
 
  Did you got the vmcore ? If yes, please find the value for vgonel()
  argument, vp, and print the vnode content.
 
 I didn't. Same problem as in my another mail. :(
 
 
  Regardless of this, look up the source line for vgonel+0x1aa.
 
 
 I could resolve only address which belongs to instruction pointer
 = 0x8:0x805a52ba
 (eh, I don't know if I should sum these numbers, so I did this for both 
 cases):
 
 dev2# addr2line -e /boot/kernel/kernel.symbols 0x805a52ba
 /usr/src/sys/kern/vfs_subr.c:979
 delmntque():TAILQ_REMOVE(mp-mnt_nvnodelist, vp, v_nmntvnodes);
 
 dev2# addr2line -e /boot/kernel/kernel.symbols 0x805a52c2
 /usr/src/sys/kern/vfs_subr.c:981
 delmntque():MNT_REL(mp);

load kernel.debug into gdb, and then do list *(vgonel+0x1aa)


pgpXkzFnQ7IWj.pgp
Description: PGP signature


Re: panic in vgonel()

2009-08-07 Thread pluknet
2009/8/7 Kostik Belousov kostik...@gmail.com:
 On Fri, Aug 07, 2009 at 04:37:07PM +0400, pluknet wrote:
 2009/8/7 Kostik Belousov kostik...@gmail.com:
  On Fri, Aug 07, 2009 at 03:37:11PM +0400, pluknet wrote:
  This is on 7.2-R amd64.
 
  I'm curious if it might be due to glusterfs on it.
 
  Fatal trap 12: page fault while in kernel mode
  cpuid = 3; apic id = 03
  fault virtual address   = 0x0
  fault code              = supervisor write data, page not present
  instruction pointer     = 0x8:0x805a52ba
  stack pointer           = 0x10:0xfffefc3474a0
  frame pointer           = 0x10:0xfffefc347510
  code segment            = base 0x0, limit 0xf, type
                          = DPL 0, pres 1, long 1, def32 0, gran 1
  processor eflags        = interrupt enabled, resume, IOPL = 0
  current process         = 35425 (find)
 
  db bt
  Tracing pid 35425 tid 100194 td 0xff003c165370
  vgonel() at vgonel+0x1aa
  vnlru_free() at vnlru_free+0x36c
  getnewvnode() at getnewvnode+0x281
  ffs_vgetf() at ffs_vgetf+0xdf
  ufs_lookup() at ufs_lookup+0x2dd
  vfs_cache_lookup() at vfs_cache_lookup+0xf3
  VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x40
  lookup() at lookup+0x598
  namei() at namei+0x33e
  kern_lstat() at kern_lstat+0x5e
  lstat() at lstat+0x2a
  syscall() at syscall+0x256
  Xfast_syscall() at Xfast_syscall+0xab
  --- syscall (190, FreeBSD ELF64, lstat), rip = 0x80071063c, rsp =
  0x7fffea48, rbp = 0x800a06910 ---
 
  Did you got the vmcore ? If yes, please find the value for vgonel()
  argument, vp, and print the vnode content.

 I didn't. Same problem as in my another mail. :(

 
  Regardless of this, look up the source line for vgonel+0x1aa.
 

 I could resolve only address which belongs to instruction pointer
 = 0x8:0x805a52ba
 (eh, I don't know if I should sum these numbers, so I did this for both 
 cases):

 dev2# addr2line -e /boot/kernel/kernel.symbols 0x805a52ba
 /usr/src/sys/kern/vfs_subr.c:979
 delmntque():        TAILQ_REMOVE(mp-mnt_nvnodelist, vp, v_nmntvnodes);

 dev2# addr2line -e /boot/kernel/kernel.symbols 0x805a52c2
 /usr/src/sys/kern/vfs_subr.c:981
 delmntque():        MNT_REL(mp);

 load kernel.debug into gdb, and then do list *(vgonel+0x1aa)


Ah, of course. Sorry.

(gdb) list *(vgonel+0x1aa)
0x805a52ba is in vgonel (/usr/src/sys/kern/vfs_subr.c:979).
974 return;
975 MNT_ILOCK(mp);
976 vp-v_mount = NULL;
977 VNASSERT(mp-mnt_nvnodelistsize  0, vp,
978 (bad mount point vnode list size));
979 TAILQ_REMOVE(mp-mnt_nvnodelist, vp, v_nmntvnodes);
980 mp-mnt_nvnodelistsize--;
981 MNT_REL(mp);
982 MNT_IUNLOCK(mp);
983 }


-- 
wbr,
pluknet
___
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: nsswitch.conf bad configuration?

2009-08-07 Thread Dan Nelson
In the last episode (Aug 07), Jordi Espasa Clofent said:
 Hi all,
 
 I've a lot of servers (6.3,6.4, 7.1, 7.2...) login against centralized 
 LDAP account server.  All works fine, but I can see in LDAP logs:
 
 # cat /var/log/syslog | grep uid= | awk '{print $12}'
[...]
 filter=((objectClass=posixAccount)(uid=root))
 filter=((objectClass=posixAccount)(uid=oscar))
 filter=((objectClass=posixGroup)(|(memberUid=oscar)(uniqueMember=uid=oscar,ou=cat,ou=tecnic,dc=mycompany,dc=com)))
 filter=((objectClass=posixAccount)(uid=root))
 filter=((objectClass=posixAccount)(uid=root))
 
 You can see the difference between user 'oscar? (exists in LDAP ddbb) and
 the others (doesn't exist in LDAP ddbb).
 
 The main question is ¿why appears users 'postfix', 'root', 'paola',
 'sendmail' or even 'devnull' in LDAP log if they doesn't exist in LDAP
 database?  Obviosly, they appears because there're query under this
 UID/username.
 
 Maybe the commented lines do that the diferents users/daemons (like
 postfix, nobody or mailer-daemon) always look at group and passwd
 directives, which has files and ldap.  So, they ask something in files
 (/etc/passwd and /etc/groups) and de default nsswitch.conf behaviour is,
 I don't know, please ask for to the next source and the query is passed
 to ldap resource.

nsswitch is probably checking LDAP for group memberships.  You can see that
for the oscar user that is in LDAP, the posixAccount query is immediately
followed by a query looking up all groups that the user is a member of. 
This lets you add local users to groups that exist only in LDAP, by creating
a shadow user in LDAP with the same name and adding it to groups.

If you're worried about overloading your ldap server with queries for
nonexistant users (which is unlikely), you can enable nscd which will cache
negative responses for 60 seconds (see the nscd and nscd.conf manpages).

-- 
Dan Nelson
dnel...@allantgroup.com
___
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


FreeBSD 7-STABLE - ath, Atheros 5212 - crash on network activity

2009-08-07 Thread parv
Hi,

I am in the process of upgrading from 6-STABLE to 7-STABLE, but have
been stymied due to FreeBSD/i386 7 crashing on network activity.
Machine is Thinkpad T61 with Atheros 5212 (IBM 802.11 [abg]) card.

Machine information (under FreeBSD 6.X) can be obtained from ...

  http://www103.pair.com/parv/comp//unix/freebsd/thinkpad-t61-8897-cto/sys/dmesg
  
http://www103.pair.com/parv/comp//unix/freebsd/thinkpad-t61-8897-cto/sys/pciconf-lcv


... until I do the disk replacement dance again ( get the 7-STABLE
specific dmesg  pciconf data).  I had updated the 7-STABLE sources
around Aug 7, 2pm UTC from cvsup5 before I bothered with getting a
crash dump.  A backtrace of FreeBSD/i386 7-STABLE follows ...


  - Parv


GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i386-marcel-freebsd...

Unread portion of the kernel message buffer:
panic: operating mode 1
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper(c0c260f0,e8fbc8fc,c0852763,c0c5338d,1,...) at 
db_trace_self_wrapper+0x26
kdb_backtrace(c0c5338d,1,c0c3326f,e8fbc908,1,...) at kdb_backtrace+0x29
panic(c0c3326f,1,4,c0c21ab3,ce,...) at panic+0x114
ieee80211_set_tim(c7aac000,1,c0c345ca,c7,0,c7aad510,c670d22c) at 
ieee80211_set_tim+0x2d
ieee80211_pwrsave(c7aac000,c7b1ab00,c0be15cd,62c,c0c30884,...) at 
ieee80211_pwrsave+0x1f3
ath_start(c6709000,c6709108,e8fbca08,c08ed81f,c6709000,...) at ath_start+0x4e3
if_start(c6709000,0,c0c30884,195,2,...) at if_start+0x4f
ether_output_frame(c6709000,c7b1ab00,6,0,e8fbca2a,...) at 
ether_output_frame+0x1ce
ether_output(c6709000,c7b1ab00,e8fbcac0,c6b45e0c,0,...) at ether_output+0x48d
ieee80211_output(c6709000,c7b1ab00,e8fbcac0,c6b45e0c,c6b402d0,...) at 
ieee80211_output+0x38
ip_output(c7b1ab00,0,e8fbcabc,0,0,...) at ip_output+0xa10
udp_send(c6b051a0,0,c7b1ab00,0,0,...) at udp_send+0x89b
sosend_dgram(c6b051a0,0,e8fbcbe0,c7b1ab00,0,...) at sosend_dgram+0x359
sosend(c6b051a0,0,e8fbcbe0,0,0,...) at sosend+0x3f
kern_sendit(c6b49b40,4,e8fbcc5c,0,0,...) at kern_sendit+0x107
sendit(0,7844401d,0,0,0,...) at sendit+0xad
sendto(c6b49b40,e8fbccfc,18,c0c3ea41,c,...) at sendto+0x48
syscall(e8fbcd38) at syscall+0x2a1
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (133, FreeBSD ELF32, sendto), eip = 0x782d2e83, esp = 0xbfbfccdc, 
ebp = 0xbfbfcd08 ---
KDB: enter: panic
Physical memory: 3034 MB
Dumping 156 MB: 141 125 109 93 77 61 45 29 13

Reading symbols from /boot/kernel/speaker.ko...Reading symbols from 
/boot/kernel/speaker.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/speaker.ko
Reading symbols from /boot/kernel/acpi.ko...Reading symbols from 
/boot/kernel/acpi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/acpi.ko
#0  doadump () at pcpu.h:196
196 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0  doadump () at pcpu.h:196
#1  0xc04db4eb in db_fncall (dummy1=1, dummy2=0, dummy3=-1059146496,
dummy4=0xe8fbc6e0 ) at /usr/src7/sys/ddb/db_command.c:516
#2  0xc04dba4c in db_command (last_cmdp=0xc0d3b014, cmd_table=0x0, dopager=1)
at /usr/src7/sys/ddb/db_command.c:413
#3  0xc04dbb4d in db_command_loop () at /usr/src7/sys/ddb/db_command.c:466
#4  0xc04dd20f in db_trap (type=3, code=0) at /usr/src7/sys/ddb/db_main.c:228
#5  0xc087e4fe in kdb_trap (type=3, code=0, tf=0xe8fbc888)
at /usr/src7/sys/kern/subr_kdb.c:524
#6  0xc0b5976b in trap (frame=0xe8fbc888)
at /usr/src7/sys/i386/i386/trap.c:687
#7  0xc0b3f73b in calltrap () at /usr/src7/sys/i386/i386/exception.s:166
#8  0xc087e65f in kdb_enter_why (why=0xc0c2320a panic,
msg=0xc0c2320a panic) at cpufunc.h:60
#9  0xc0852780 in panic (fmt=0xc0c3326f operating mode %u)
at /usr/src7/sys/kern/kern_shutdown.c:557
#10 0xc09226e6 in ieee80211_set_tim (ni=0xc0c2320a, set=1)
at /usr/src7/sys/net80211/ieee80211_power.c:140
#11 0xc0922401 in ieee80211_pwrsave (ni=0xc7aac000, m=0xc7b1ab00)
at /usr/src7/sys/net80211/ieee80211_power.c:206
#12 0xc0583a45 in ath_start (ifp=0xc6709000)
at /usr/src7/sys/dev/ath/if_ath.c:1618
#13 0xc08e75fb in if_start (ifp=0xc6709000) at /usr/src7/sys/net/if.c:2837
#14 0xc08ed81f in ether_output_frame (ifp=0xc6709000, m=0xc7b1ab00)
---Type return to continue, or q return to quit---
at /usr/src7/sys/net/if_ethersubr.c:405
#15 0xc08edde1 in ether_output (ifp=0xc6709000, m=0xc7b1ab00, dst=0xe8fbcac0,
rt0=0xc6b45e0c) at /usr/src7/sys/net/if_ethersubr.c:374
#16 0xc0920299 in ieee80211_output (ifp=0xc6709000, m=0xc7b1ab00,
dst=0xe8fbcac0, rt0=0xc6b45e0c)
at /usr/src7/sys/net80211/ieee80211_output.c:261
#17 0xc093969c in ip_output (m=0xc7b1ab00, opt=0x0, ro=0xe8fbcabc, 
flags=Variable flags is not available.
)
at /usr/src7/sys/netinet/ip_output.c:554
#18 0xc09a734a in