Date: Tue, 07 Mar 2000 11:15:34 -0700 From: Warner Losh <imp@village.org> To: new-bus@freebsd.org Subject: Interrupt context and newbus Message-ID: <200003071815.LAA95578@harmony.village.org>
next in thread | raw e-mail | index | archive | help
OK. I'm trying to track down a crash that I get sometimes (not
always, but 80% of the time) when I remove/insert a pccard and the
question of newbus and interrupt safety came up. The issue has come
up twice now. Once when I was having Bruce review some safety changes
to sio and now with my current bug.
I have a CF card that has two slices on it. Slice 1 is DOS, slice 2
is FreeBSD. I insert the card, copy files to the FreeBSD slice and to
the DOS slice (via mount both cases), unmount everything and pop the
card out. I then use the card for its purpose (booting NetBSD on my
Everex Freestyle A-10 Associate) and then find that I need to modify
the card, so in it goes into my laptop (or test gig).
When I mount the FreeBSD partition (well, the first one, which usually
has been the FreeBSD one), I get a panic:
l trap 12: page fault while in kernel mode
fault virtual address = 0x28
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc018cfa6
stack pointer = 0x10:0xc626bbf8
frame pointer = 0x10:0xc626bc10
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 1243 (mount)
interrupt mask = none
kernel: type 12 trap, code=0
Stopped at dscheck+0x62: movl 0xc(%eax),%esi
db> trace
dscheck(c1c8a308,0) at dscheck+0x62
diskstrategy(c1c8a308,c08b3800,200,c08ec600,c09b4000) at
diskstrategy+0xad
readdisklabel(c08b3800,c08ec600,c09410d4,c08b3980,c08e9c80) at
readdisklabel+0x53
dsopen(c08e9c80,2000,0,c09410e4,c09410e8) at dsopen+0x258
diskopen(c08e9c80,3,2000,c5d4c560,c626bd48) at diskopen+0x10b
spec_open(c626bd48,c626bd00,c025d1c9,c626bd48,c626bd6c) at
spec_open+0xfd
spec_vnoperate(c626bd48,c626bd6c,c0254a1d,c626bd48,44) at
spec_vnoperate+0x15
ufs_vnoperatespec(c626bd48,44,c08eca00,c6296a20,c0980980) at
ufs_vnoperatespec+0x15
ffs_mountfs(c6296a20,c08eca00,c5d4c560,c031c740,c08ecafa) at
ffs_mountfs+0x1a5
ffs_mount(c08eca00,bfbfeff0,bfbfef3c,c626be94,c5d4c560) at
ffs_mount+0x53c
mount(c5d4c560,c626bf80,0,bfbfeff0,806c876) at mount+0x507
syscall(2f,2f,2f,806c876,bfbfeff0) at syscall+0x176
Xint0x80_syscall() at Xint0x80_syscall+0x26
So, I did some poking around. The dscheck+0x62 is most likely
sp = &ssp->dss_slices[dkslice(bp->b_dev)];
==> lp = sp->ds_label;
if (ssp->dss_secmult == 1) {
ssp is NULL in the traceback, so this is a good guess. How can ssp be
NULL? Well, if diskstrategy passes it a NULL pointer.
So I'm a bit sumped about how this can happen.
The ad_attach function appears to always create the disk when it
prints the probe line. The ad_detach runction appears to invalidate
the disk and then destroy the disk devices. So I'm confused. All of
this happens from an interrupt context, especially the delete.
Could this be an interrupt safety issue with newbus? Or am I barking
up the wrong tree? More generally, how safe is newbus from an
interrupt context?
Warner
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-new-bus" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003071815.LAA95578>