Bug 21929

Summary: lpd cause system crash
Product: Base System Reporter: wkwu <wkwu>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 5.0-CURRENT   
Hardware: Any   
OS: Any   

Description wkwu 2000-10-12 11:40:01 UTC
lpd often causes system crash: 

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x17a
fault code              = supervisor write, page not present
instruction pointer     = 0x8:0xc01dd7f7
stack pointer           = 0x10:0xc9dc5c70
frame pointer           = 0x10:0xc9dc5c8c
code segment            = base rx0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def 32 1, gran 1
processor eflags        = interrupt enable, resume, IOPL = 0
current process         = 149(lpd)
trap number             = 12
panic: page fault

How-To-Repeat: 
send a large file (>10MB) to printer. system often crashes...
Comment 1 Johan Karlsson freebsd_committer freebsd_triage 2000-10-14 15:41:49 UTC
State Changed
From-To: open->feedback

To be able to help you debug this problem we need some 
more information. 

Please see the FAQ (http://www.FreeBSD.org/FAQ/FAQ.html) 
section 'For serious FreeBSD hackers only' 
question 'Making the most of a kernel panic' 
for info how you can help us getting the info we need. 

Please send the info as a follow-up to this PR 
by sending a mail to  
'freebsd-gnats-submit@FreeBSD.org' 
with the subject of this mail as subject. 

Thanks 
Johan
Comment 2 wkwu 2000-10-15 02:39:47 UTC
% nm /boot/kernel/kernel | grep c01dd
c01dd300 t atpic_attach
c01dd298 t atpic_probe
c01dd290 t attimer_attach
c01dd228 t attimer_probe
c01dd1a0 t i8254_get_timecount
c01dd5c0 T icu_setup
c01dd660 T icu_unset
c01dd6f0 T inthand_add
c01dda1c T inthand_remove
c01dde44 T intr_soft
c01dd3c4 T isa_defaultirq
c01dd468 T isa_irq_pending
c01dd308 T isa_nmi
c01dd418 t isa_strayintr
c01ddbb4 T ithd_loop
c01dda90 T sched_ithd
c01ddf84 T setdelayed
c01ddfb8 T setsoftcambio
c01ddfa0 T setsoftcamnet
c01ddfd0 T setsoftclock
c01ddfe8 T setsoftnet
c01dd084 T setstatclockrate
c01ddcf4 T start_softintr
c01dd0cc t sysctl_machdep_i8254_freq
c01dd13c t sysctl_machdep_tsc_freq
c01dd220 t tsc_get_timecount
c01dd480 t update_intrname
Comment 3 k 2000-10-15 13:01:51 UTC
At Sun, 15 Oct 2000 09:39:47 +0800, Wei-Kai Wu wrote:
> c01dd6f0 T inthand_add
> c01dda1c T inthand_remove

Hello again.

The address of the panic is from the inthand_add function which is 
located in src/sys/i386/isa/intr_machdep.c.
Which version of src/sys/i386/isa/intr_machdep.c are you using?

And if possible can you please compile a debug kernel and trie to get a 
crash dump and analyze it as described in the FAQ. I think that will
help us track this panic alot easier.

Thanks
Johan K
Comment 4 wkwu 2000-10-16 03:12:48 UTC
I add 'options DDB' in the kernel.

When panic, it shows:
...
instruction pointer:  0xc01e8637
...

db> panic

stop at: inthand_add+0x107   movw %ax,0x172(%edx)

Hope the info is helpful.
Comment 5 paulz 2000-10-22 10:26:45 UTC
I am having the same problem, code in inthand_add causes a trap 12.
This happens regularly when printing a file.

I also noted that when I run systat -vm some interrupt vectors are marked as
stray and used by a device. Look at irq 0 and 6 in the output below.
Might this be related to the changes in intr_machdep.? made in september ??
I never had these panics before I built and installed a new current about 3 
weeks ago.

	Paul

Mem:KB    REAL            VIRTUAL                     VN PAGER  SWAP PAGER
        Tot   Share      Tot    Share    Free         in  out     in  out
Act   24780    7944    46508    14640    3112 count   16           5
All   61560    9360  2644744    18368         pages  154          30
                                                      159 zfod   Interrupts
Proc:r  p  d  s  w    Csw  Trp  Sys  Int  Sof  Flt    144 cow    1035 total
     2  1  4 19       876  707 2345 1333  405  457  14948 wire        stray irq0
                                                    35792 act         stray irq6
15.9%Sys   0.3%Intr 25.7%User 57.6%Nice  0.5%Idl     8060 inact       ata0 irq14
|    |    |    |    |    |    |    |    |    |       2704 cache    81 ahc0 irq9
========>>>>>>>>>>>>>---------------------------      408 free        atkbd0 irq
                                                          daefr       fdc0 irq6
Namei         Name-cache    Dir-cache                  96 prcfr       sio0 irq4
    Calls     hits    %     hits    %                  22 react       sio1 irq3
     5541     4958   89        9    0                   1 pdwak   685 sio2 irq10
                                                      358 pdpgs   100 clk irq0
Disks   ad0   da0   da1   da2  acd0   fd0 pass0         5 intrn   128 rtc irq8
KB/t   0.00 18.78 19.50  6.94  0.00  0.00  0.00     14832 buf      41 fxp0 irq11
tps       0    32     3    46     0     0     0       213 dirty       lpt0 irq7
MB/s   0.00  0.58  0.05  0.31  0.00  0.00  0.00      4405 desiredvnodes
% busy    0    43     2    88     0     0     0      4183 numvnodes


-- 
Paul van der Zwan		paulz @ trantor.xs4all.nl
"I think I'll move to theory, everything works in theory..."
Comment 6 John Baldwin freebsd_committer freebsd_triage 2000-10-22 21:34:37 UTC
On 22-Oct-00 Paul van der Zwan wrote:
> 
> I am having the same problem, code in inthand_add causes a trap 12.
> This happens regularly when printing a file.
> 
> I also noted that when I run systat -vm some interrupt vectors are marked as
> stray and used by a device. Look at irq 0 and 6 in the output below.
> Might this be related to the changes in intr_machdep.? made in september ??
> I never had these panics before I built and installed a new current about 3 
> weeks ago.

Notice the stray counts are 0.  I.e., you are't having any stray counts at
the moment.  If you have 1 stray interrupt during boot then these stray
entries will show up forever in vmstat even thugh you aren't getting any
more stray interrupts.  How do you know that the code in inthand_add() is
causing a trap 12 btw?  A stack trace and the trap message would be
most helpful.

-- 

John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
Comment 7 Kris Kennaway freebsd_committer freebsd_triage 2001-05-25 10:57:07 UTC
State Changed
From-To: feedback->closed

Timeout waiting for feedback