Re: Crash Dump

On Monday, 30 May 2005 at 23:28:38 -0700, Kevin Downey wrote:
> first off:
> FreeBSD zifnab 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Mon May 30 07:53:44
> PDT 2005     kevin <at> zifnab:/usr/obj/usr/src/sys/SEE_NO_EVIL  i386
> built from sources cvsuped yesterday (the 29th of May) ontop of the
> SNAP002 or whatever it was called from March.
>
> Now, I am getting what seem to me, to be random crashes. Of course
> there are many things in this world which seem random to me because I
> do not know what is going on. These crashes indubitably fall in to
> this category of things.
> I figure the best way to learn more about this is to ask other people.
> And I also know that when asking other people, particular this list,
> it is a good idea to be in possession of various background
> information. But, and here is the twist, when the panic happens, the
> 'dumping X megabytes of memory`, or whatever the exact wording is,
> message pops up, and then just sits there for however long I am
> willing to let the machine sit(2 hours is the upper limit on that).
> The IDE activity LED does not blink(I assume it should be blinking if
> the memory is being dumped to swap on an IDE drive), it does blink
> when I hit keys on the keyboard.

Sounds like the crash involves block I/O, so you're not able to dump.
Try remote debugging.  See the handbook or
http://www.lemis.com/grog/Papers/Debug-tutorial/tutorial.pdf for
details.

> dmesg from the machine: http://kevin.is.a.zombie.org/dmesg
> kernel config: http://kevin.is.a.zombie.org/SEE_NO_EVIL
>

[RFC] [PATCH] VM & VFS changes

Hi,

I would like to present a unified set of VM and VFS diffs for wider 
scrutiny and testing. I have been running these diffs since May 10th 
across daily reboots with no issues.

What this patch does:
- Adds code that cleanly unmounts swaps (Forcing page-in first) after the 
final sync but before all of the filesystems are unmounted. This causes 
references to swap slices in devfs to not be dangling when the machine is 
rebooted.
- Defers unmounting of devfs until all other filesystems are unmounted.
- Prints diagnostic messages when non-free dangling vnodes are still 
active on shutdown.

What it doesn't:
- Fix the EBUSY error code that is returned on reboot (But it sharply 
reduces the amount of dangling vnodes. I am still working on this issue).
- Vacuum your apartment (Sorry...).

The patch is attached to this email. Just in case it doesn't make it to 
the list, it can also be found online at:
http://bling.properkernel.com/freebsd/vm+vfs.shutdown.changes.patch

Comments and constructive criticism very welcome. 

Cheers,
Andy

PS: This work was sponsored by my employer, Silicon Landmark. If you like 

Jun Kuriyama <kuriyama <at> imgsrc.co.jp>

Subject: Hang in NFS client operation

Hang in NFS client operation

Since 2005-04-09 (*), my (-current) box sometimes hang at NFS client
operation (usually CVS update from readonly NFS mounted repository.
Server is 5.3R).

Is there something I can help debugging about this issue?

-----
db> ps
  pid   proc     uid  ppid  pgrp  flag   stat  wmesg    wchan  cmd
 7778 c3b73e00  103  7776  7767 0004000 [SLPQ nfsreq 0xc3d87e80][SLP] cvs
...
db> trace 7778
Tracing pid 7778 tid 100124 td 0xc3b6b300
sched_switch(c3b6b300,0,1) at sched_switch+0x14f
mi_switch(1,0,c3b6b300,1,c3b6b300) at mi_switch+0x1ba
sleepq_switch(c3d87e80) at sleepq_switch+0x133
sleepq_wait(c3d87e80,0,c3bc5298,0,c3d87e80) at sleepq_wait+0xb
msleep(c3d87e80,c0721a60,53,c06c28fc,0) at msleep+0x356
nfs_reply(c3d87e80,0,f,0,c3b6b300) at nfs_reply+0x23c
nfs_request(c4d69aa0,c3eb1200,3,c3b6b300,c3bf0d80) at nfs_request+0x3c1
nfs_lookup(ecf93bd8) at nfs_lookup+0x2d8
VOP_LOOKUP_APV(c06f8ba0,ecf93bd8) at VOP_LOOKUP_APV+0x38
lookup(ecf93c68,ecf93c14,0,c3b6b300,ecf93c90) at lookup+0x431
namei(ecf93c68,c3bf0d80,c3dd8e00,80c3080,0) at namei+0x396
kern_access(c3b6b300,80c3080,0,4,ecf93d30) at kern_access+0x6a
access(c3b6b300,ecf93d04,2,2d7,286) at access+0x15
syscall(3b,bfbf003b,bfbf003b,80c3080,80de8c0) at syscall+0x2b3
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (33, FreeBSD ELF32, access), eip = 0x282e6bc7, esp = 0xbfbfe47c, ebp = 0xbfbfe498 ---

Re: cannot alloc 19968 bytes for inoinfo

On 31 May, Eric Anderson wrote:
> One of my filesystems won't fsck.  I'm not sure how to fix it, or what 
> it's really trying to tell me.
> 
> # fsck -y /vol1
> ** /dev/da0s1d
> ** Last Mounted on /vol1
> ** Phase 1 - Check Blocks and Sizes
> fsck_ufs: cannot alloc 19968 bytes for inoinfo
> 
> 
> df -i /vol1 output:
> Filesystem  1K-blocks        Used    Avail Capacity  iused     ifree 
> %iused  Mounted on
> /dev/da0s1d 1891668564 1684163832 56171248    97% 55109756 189360002 
> 23%   /vol1
> 
> 
> Any help would be very appreciated!

You're probably running into the default 512MB data size limit.  Try
setting kern.maxdsiz to a larger value in /boot/loader.conf and
rebooting.  I've got mine set to 1GB.
	kern.maxdsiz="1073741824"

_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

Re: [RFC] [PATCH] VM & VFS changes

On  1 Jun, Andre Guibert de Bruet wrote:
> Hi,
> 
> I would like to present a unified set of VM and VFS diffs for wider 
> scrutiny and testing. I have been running these diffs since May 10th 
> across daily reboots with no issues.
> 
> What this patch does:
> - Adds code that cleanly unmounts swaps (Forcing page-in first) after the 
> final sync but before all of the filesystems are unmounted. This causes 
> references to swap slices in devfs to not be dangling when the machine is 
> rebooted.

What if there is not enough RAM it page in the swap contents?  This may
be likely to happen if swap-backed md(4) devices are used.

This problem is a bit complicated because there can be various
combinations of:

	mounted file systems that reside on swap-backed memory disks

	mounted file systems that reside on vnode-backed memory disks

	vnode-backed memory disks used as swap devices

so that there is no simple ordering of operations that can be used on
shutdown.  I think that even some wierd cases like a mounted file system
that resides on a vnode-backed memory disk, whose backing file resides
in a file system that resides on a swap-backed memory disk, might be
legitimate.

Re: wpa_supplicant + NDIS (broadcom) + linksys WRT54G possible?

Sam Leffler wrote:

> What "latest sources" did you use?  wpa_supplicant or the ndis driver? 

-current. I already had the latest wpa_supplicant.

> Your log shows a completed handshake and both PTK and GTK plumbed so in 
> theory traffic should flow.  You may not see the keys with ifconfig 
> unless the ndis layer installs them in the net80211 data structures 
> (don't recall what it does).

I tried this again, and even tried configuring the network by hand. Still no 
packets were passed. Also, I tried this on a different AP, and it never 
completed the WPA-PSK handshake, the log looked just like the first one I 
published.

> You would probably better off setting up an ap where you can see what's 
> happening on the ap side.  Since you have an ath card you could use that 
> to test with (even in the same laptop).

I can try that, be a couple days before I get to it though. I'm hoping that 
wpaul has an epiphany first, but if not, I'll see what I can do.

Thanks,

Doug

--

-- 

     This .signature sanitized for your protection

Re: Hang in NFS client operation

On Wed, 1 Jun 2005, Jun Kuriyama wrote:

> Since 2005-04-09 (*), my (-current) box sometimes hang at NFS client 
> operation (usually CVS update from readonly NFS mounted repository. 
> Server is 5.3R).
>
> Is there something I can help debugging about this issue?

While it sounds like you've found the culprit, with NFS hangs it's always 
worth sitting down with a packet sniffer and making sure the wire protocol 
looks good.  Ethereal actually has quite a nice NFS RPC decoder.  What you 
want to do is attach Ethereal to the interface and make sure that the last 
lookup RPC in the sequence gets a valid looking reply.  This probably just 
means making sure there was a reply.

Robert N M Watson

>
> -----
> db> ps
>  pid   proc     uid  ppid  pgrp  flag   stat  wmesg    wchan  cmd
> 7778 c3b73e00  103  7776  7767 0004000 [SLPQ nfsreq 0xc3d87e80][SLP] cvs
> ...
> db> trace 7778
> Tracing pid 7778 tid 100124 td 0xc3b6b300
> sched_switch(c3b6b300,0,1) at sched_switch+0x14f
> mi_switch(1,0,c3b6b300,1,c3b6b300) at mi_switch+0x1ba
> sleepq_switch(c3d87e80) at sleepq_switch+0x133
> sleepq_wait(c3d87e80,0,c3bc5298,0,c3d87e80) at sleepq_wait+0xb

UP kernel build -- broken by bus/interrupt-related changes?

When building a 6.x UP kernel on a 5.x build box, I get the following 
build problem.  Adding an explicit include of <sys/bus.h> to sched_4bsd.c 
fixes the problem, but probably isn't the right answer.  Presumably, 
interrupt.h relies on the definition of interrupt-related types by means 
of prior includes, and it worked for sched_4bsd.c due to pollution earlier 
in the include chain.  I've not tracked this down to a specific commit, 
but presumably it was one of the recent changes to the busspace API 
include files, and works in the SMP case due to conditional pollution. 
If someone who is at one with the include files and types in question 
could fix this, that would be great!

zoo:/zoo/rwatson/p4/vendor/freebsd/src/sys/i386/compile/UP> make 
sched_4bsd.o
cc -c -O -pipe  -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
-Wcast-qual  -fformat-extensions -std=c99 -g -nostdinc -I-  -I. -I../../.. 
-I../../../contrib/dev/acpica -I../../../contrib/altq 
-I../../../contrib/ipfilter -I../../../contrib/pf 
-I../../../contrib/dev/ath -I../../../contrib/dev/ath/freebsd 
-I../../../contrib/ngatm -I../../../dev/twa -D_KERNEL -include 
opt_global.h -fno-common -finline-limit=8000 --param 
inline-unit-growth=100 --param large-function-growth=1000 
-mno-align-long-strings -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow 
-mno-sse -mno-sse2 -ffreestanding -Werror  ../../../kern/sched_4bsd.c
In file included from ../../../kern/sched_4bsd.c:303:
../../../sys/interrupt.h:42: error: syntax error before "driver_intr_t"
../../../sys/interrupt.h:121: warning: "enum intr_type" declared inside 
parameter list
../../../sys/interrupt.h:121: warning: its scope is only this definition 

Re: Error whlie making release

# gabor.kovesdan <at> t-hosting.hu / 2005-05-30 22:30:31 +0200:
> + cd /usr/ports^M
> + rm -f INDEX*^M
> + make index -DINDEX_PRISTINE^M
> Generating INDEX-5 - please wait..at-spi-1.6.4: 
> "/usr/ports/x11-toolkits/gtk20" non-existent -- dependency lis
> ===> accessibility/at-spi failed^M
> *** Error code 1^M
> deepforest-1.0a: "/usr/ports/x11-toolkits/tkstep80" non-existent -- 
> dependency list incomplete^M
> ===> archivers/deepforest failed^M
> *** Error code 1^M
> 2 errors^M
> ^M
> ********************************************************************^M
> Before reporting this error, verify that you are running a supported^M
  ********************************************
> have a complete and up-to-date ports collection.  (INDEX builds are^M
  ***********************************************

    Is that condition met?

--

-- 
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man.  You don't KNOW.
Cause you weren't THERE.             http://bash.org/?255991
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net

Hi,

>>>>> On Wed, 01 Jun 2005 03:00:10 +0900
>>>>> Hajimu UMEMOTO <ume <at> freebsd.org> said:

ume> In anyway, there is one more issue in my patch.  We cannot correct 1st
ume> argument of getnetbyaddr(3) without breaking ABI compatibility.
ume> Fortunately, getnetbyaddr(3) is not refered else where in our
ume> libraries.  So, I'll fix getnetbyaddr(3).

I've attached the patch to correct 1st argument of getnetbyaddr(3) in
this mail.  It is subset of my previous patch.  Since it breaks ABI
compatibility of getnetbyaddr(3), I think it is better to correct
n_net member of struct netent, too.  Since there is objection, the
patch leaves struct addrinfo as is.  So, it doesn't need to bump any
shlib major.  Is it okay?

Sincerely,

--
Hajimu UMEMOTO  <at>  Internet Mutual Aid Society Yokohama, Japan
ume <at> mahoroba.org  ume <at> {,jp.}FreeBSD.org
http://www.imasy.org/~ume/

_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current