Well I think I have worked around my other panic that I posted a few days ago by updating the modems firmware, atleast it doesn't panic under the situation it did last time. I still believe the bug exists somewhere though and i'm sure I could still reproduce it if anyone is interested. Just now I was playing about with /dev/speaker for a script I want to beep. I did an `echo a > /dev/speaker` and it worked, but I decided I wanted it longer or some kind of pattern. I followed this by an `echo aaa > /dev/speaker` and it worked :o) I then went on to read the man page and found out about raising and lowering octaves and pauses, so next I tried `echo aPa > /dev/speaker` and indeed there was a pause. However, when I tried `echo aP>a > /dev/speaker` (which I think is wrong anyhow but never mind) my SSH session froze and I knew something had gone wrong. Unfortuantly the monitor had become unplugged from when I was fiddling about so I didn't get to see anything on screen, but I did get a coredump for what it's worth. It isn't from a debugging kernel either, if need be I can load a debugging kernel and see if I can reproduce it. ( I am beginning to think I never should have upgraded :o) ) Anyway, here goes nothing: --- IdlePTD at phsyical address 0x00361000 initial pcb at physical address 0x002bb620 panicstr: getnewbuf: locked buf panic messages: --- panic: lockmgr: pid 8486, not exclusive lock holder 7018 unlocking syncing disks... panic: getnewbuf: locked buf Uptime: 3d13h40m34s dumping to dev #ad/0x20001, offset 65664 dump ata0: resetting devices .. done 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0 0xc015bea2 in dumpsys () (kgdb) bt #0 0xc015bea2 in dumpsys () #1 0xc015bc6c in boot () #2 0xc015c0a0 in poweroff_wait () #3 0xc0183d4f in getnewbuf () #4 0xc01849cf in geteblk () #5 0xc0182b8d in bwrite () #6 0xc018869f in vop_stdbwrite () #7 0xc01884b5 in vop_defaultop () #8 0xc0183006 in bawrite () #9 0xc01965b0 in spec_fsync () #10 0xc0214d48 in ffs_sync () #11 0xc018d74b in sync () #12 0xc015ba06 in boot () #13 0xc015c0a0 in poweroff_wait () #14 0xc0155e48 in lockmgr () #15 0xc0183698 in brelse () #16 0xc0260bea in spkrclose () #17 0xc019687f in spec_close () #18 0xc021cb06 in ufsspec_close () #19 0xc021d101 in ufs_vnoperatespec () #20 0xc01921a7 in vn_close () #21 0xc0192afe in vn_closefile () #22 0xc0150eb8 in fdrop () ---Type <return> to continue, or q <return> to quit--- #23 0xc0150dfc in closef () #24 0xc0150931 in fdfree () #25 0xc015381a in exit1 () #26 0xc015368d in sys_exit () #27 0xc0255361 in syscall2 () #28 0xc02466f5 in Xint0x80_syscall () #29 0x28084887 in ?? () #30 0x28082185 in ?? () #31 0x2808182f in ?? () #32 0x280812bf in ?? () #33 0x2808101a in ?? () #34 0x280940e3 in ?? () #35 0x28096958 in ?? () #36 0x8048502 in ?? () #37 0x8048442 in ?? () (kgdb) --- I'm not sure if this should goto hackers or current or bugs or... what, so i'll send it to all of them (although I am not subscribed to hackers and current or bugs anymore). It's a 4.9-R-p3 machine... sorry if I am annoying you all :o)Received on Sun Mar 07 2004 - 01:44:35 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:46 UTC