Bug 33143
| Summary: | Kernel panic in uhci_abort_xfer_end | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Russell Vincent <rv> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.5-PRERELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Russell Vincent
2001-12-24 12:40:00 UTC
On Tue, 25 Dec 2001 12:34:59 GMT, Russell Vincent wrote:
> >Number: 33143
> >Category: kern
> >Synopsis: Kernel panic in uhci_abort_xfer_end
Soren, you recently closed a PR that reported problems with second
panics while trying to dump.
Here's another example of one, from someone equipped to provide
debugging info.
Perhaps you could take a look? bde seems to think there's a problem
with addump() that causes these, and they really get in the way of
debugging other problems.
Ciao,
Sheldon.
The second panic is caused in /sys/ufs/ffs/ffs_softdep.c:acquire_lock
(i.e. soft updates are on):
acquire_lock(lk)
struct lockit *lk;
{
pid_t holder;
if (lk->lkt_held !=3D -1) {
holder =3D lk->lkt_held;
FREE_LOCK(lk);
if (holder =3D=3D CURPROC->p_pid)
panic("softdep_lock: locking against myself");
else
panic("softdep_lock: lock held by %d", holder);
}
lk->lkt_spl =3D splbio();
(*) lk->lkt_held =3D CURPROC->p_pid;
lockcnt++;
}
The second panic happens at the line indicated (*) when CURPROC =3D=3D =
NULL (i.e. there is no current process)
David
--
Dr David Hedley, R&D Director,
intY Ltd, Bristol, UK
http://www.inty.net/
intY has scanned this email for all known viruses (www.inty.com)
State Changed From-To: open->feedback Does the USB panic still occur on more recent releases? State Changed From-To: feedback->closed The submitter no longer uses the hardware on which the problem occurred. |
