On Sat, Nov 23, 2002 at 10:17:14AM -0500, Robert Watson wrote: > > On Sat, 23 Nov 2002, Christian Brueffer wrote: > > > just got this panic on my notebook. Had to manually shut it down after a > > acpiconf -s 4. At the next bootup, the panic occured. At the moment I'm > > trying to boot into my system again to reproduce it. > > In general, this panic occurs in the following situation: each mbuf packet > header has a label structure in it, and the Biba policy stores a per-label > allocated label blob using malloc'd memory. If the packet header is > copied using the copypacket abstractions, then the reference will be > duplicated as will the label data, so each resulting reference will be > separately handled and free'd. However, if the packet header data is > blindly copied without invoking the normal header replication code, then > the same pointer will sit in the new packet header as the old one. When > the two mbufs are free'd, the first one goes fine, but the second one is a > duplicate free. So somehow you managed to trigger a code path that > improperly copies packet headers. Do you have any information on what > process it was that was performing the recvfrom()? One of the code paths > that may present a problem in the base system implementation is a packet > copy for alignment purposes in the KAME code. Another possibility is that > we've seen a regression in existing handling of something like the > fragmentation code, broadcast/multicast, etc. Knowing what's in the > packet and what process it is would help a lot in debugging this. Also, > it would be useful to know what interface this mbuf originated from, if > possible. > > So if it's reproduceable, you want to show the pcpu data to find the pid, > then us ps to identify the process. If you have gdb set up (either live > or a dump), seeing the mbuf ifnet pointer value would be valuable, as well > as knowing the domain, type, etc of the socket in question. > > Thanks, > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > [EMAIL PROTECTED] Network Associates Laboratories >
Hi, seems like I'm finally able to reproduce the panic. It seems to happen when I play around with acpi stuff, especially the hw.acpi.cpu* settings. Unfortunately this has the side effect, that the panic occurs at every boot, so I haven't found a way to get back into the system yet (unset acpi_load at the loader prompt doesn't help). I'm not too familiar with kernel debugging too, so you would probably have to tell me what to type in. - Christian -- http://www.unixpages.org [EMAIL PROTECTED] GPG Pub-Key : www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D
msg47352/pgp00000.pgp
Description: PGP signature
