Re: [jhb@FreeBSD.org: RE: Panic in -current]
I would like to see full dump of 'vidcontrol -i adapter', 'vidcontrol -i mode' and dmesg after the vesa module is loaded (you get very verbose output from the vesa module init code if you boot the kernel with 'boot -v'). I think this is what you asked for, otherwise please let me know. Bye, Andrea -- 0 and 1. Now what could be so hard about that? fb0: vga0, type:VESA VGA (5), flags:0x700ff initial mode:24, current mode:24, BIOS mode:3 frame buffer window:0xb8000, buffer size:0x8000 window size:0x8000, origin:0x0 display start address (0, 0), scan line width:80 reserved:0x0 mode# flags typesize font window linear buffer -- 0 (0x000) 0x0001 T 40x25 8x8 0xb8000 32k 32k 0x 32k 1 (0x001) 0x0001 T 40x25 8x8 0xb8000 32k 32k 0x 32k 2 (0x002) 0x0001 T 80x25 8x8 0xb8000 32k 32k 0x 32k 3 (0x003) 0x0001 T 80x25 8x8 0xb8000 32k 32k 0x 32k 4 (0x004) 0x0003 G 320x200x2 1 8x8 0xb8000 32k 32k 0x 32k 5 (0x005) 0x0003 G 320x200x2 1 8x8 0xb8000 32k 32k 0x 32k 6 (0x006) 0x0003 G 640x200x1 1 8x8 0xb8000 32k 32k 0x 32k 13 (0x00d) 0x0003 G 320x200x4 4 8x8 0xa 64k 64k 0x 256k 14 (0x00e) 0x0003 G 640x200x4 4 8x8 0xa 64k 64k 0x 256k 16 (0x010) 0x0003 G 640x350x2 2 8x14 0xa 64k 64k 0x 128k 18 (0x012) 0x0003 G 640x350x4 4 8x14 0xa 64k 64k 0x 256k 19 (0x013) 0x0001 T 40x25 8x14 0xb8000 32k 32k 0x 32k 20 (0x014) 0x0001 T 40x25 8x14 0xb8000 32k 32k 0x 32k 21 (0x015) 0x0001 T 80x25 8x14 0xb8000 32k 32k 0x 32k 22 (0x016) 0x0001 T 80x25 8x14 0xb8000 32k 32k 0x 32k 23 (0x017) 0x0001 T 40x25 8x16 0xb8000 32k 32k 0x 32k 24 (0x018) 0x0001 T 80x25 8x16 0xb8000 32k 32k 0x 32k 26 (0x01a) 0x0003 G 640x480x4 4 8x16 0xa 64k 64k 0x 256k 27 (0x01b) 0x0003 G 640x480x4 4 8x16 0xa 64k 64k 0x 256k 28 (0x01c) 0x0003 G 320x200x8 1 8x8 0xa 64k 64k 0x 64k 30 (0x01e) 0x0001 T 80x50 8x8 0xb8000 32k 32k 0x 32k 32 (0x020) 0x0001 T 80x30 8x16 0xb8000 32k 32k 0x 32k 34 (0x022) 0x0001 T 80x60 8x8 0xb8000 32k 32k 0x 32k 37 (0x025) 0x0003 G 320x240x8 4 8x8 0xa 64k 64k 0x 256k 112 (0x070) 0x T 80x43 8x8 0xb8000 32k 32k 0x 32k 113 (0x071) 0x0001 T 80x43 8x8 0xb8000 32k 32k 0x 32k 256 (0x100) 0x000f G 640x400x8 1 8x16 0xa 64k 64k 0xf500 2496k 257 (0x101) 0x000f G 640x480x8 1 8x16 0xa 64k 64k 0xf500 2496k 258 (0x102) 0x000b G 800x600x4 4 8x16 0xa 64k 64k 0x 2496k 259 (0x103) 0x000f G 800x600x8 1 8x16 0xa 64k 64k 0xf500 2496k 260 (0x104) 0x000b G 1024x768x4 48x16 0xa 64k 64k 0x 2496k 261 (0x105) 0x000f G 1024x768x8 18x16 0xa 64k 64k 0xf500 2496k 263 (0x107) 0x000f G 1280x1024x8 1 8x16 0xa 64k 64k 0xf500 2496k 264 (0x108) 0x000f G 640x400x16 18x16 0xa 64k 64k 0xf500 2496k 269 (0x10d) 0x000f G 320x200x15 18x8 0xa 64k 64k 0xf500 2496k 270 (0x10e) 0x000f G 320x200x16 18x8 0xa 64k 64k 0xf500 2496k 272 (0x110) 0x000f G 640x480x15 18x16 0xa 64k 64k 0xf500 2496k 273 (0x111) 0x000f G 640x480x16 18x16 0xa 64k 64k 0xf500 2496k 274 (0x112) 0x000f G 640x480x24 18x16 0xa 64k 64k 0xf500 2496k 275 (0x113) 0x000f G 800x600x15 18x16 0xa 64k 64k 0xf500 2496k 276 (0x114) 0x000f G 800x600x16 18x16 0xa 64k 64k 0xf500 2496k 277 (0x115) 0x000f G 800x600x24 18x16 0xa 64k 64k 0xf500 2496k 278 (0x116) 0x000f G 1024x768x15 1 8x16 0xa 64k 64k 0xf500 2496k 279 (0x117) 0x000f G 1024x768x16 1 8x16 0xa 64k 64k 0xf500 2496k 280 (0x118) 0x000f G 1024x768x24 1 8x16 0xa 64k 64k 0xf500 2496k 288 (0x120) 0x000f G 320x240x8 1 8x8 0xa 64k 64k 0xf500 2496k 289 (0x121) 0x000f G 320x240x16 18x8 0xa 64k 64k 0xf500 2496k 290 (0x122) 0x000f G 400x300x8 1 8x8 0xa 64k 64k 0xf500 2496k 291 (0x123) 0x000f G 400x300x16 18x8 0xa 64k 64k 0xf500 2496k 292 (0x124) 0x000f G 512x384x8 1 8x8 0xa 64k 64k 0xf500 2496k 293 (0x125) 0x000f G 512x384x16 18x8 0xa 64k 64k 0xf500 2496k Dec 11 23:20:41 brian /boot/kernel/kernel: VESA: information block Dec 11 23:20:41 brian /boot/kernel/kernel: 56 45 53 41 00 02 20 01 00 01 00 00 00 00 22 00 Dec 11
Re: [jhb@FreeBSD.org: RE: Panic in -current]
Andrea Campi [EMAIL PROTECTED] writes: Ok, I will try each one. At the moment, I'm using logo_saver. I will let you know. Take a long hard look at vesa_set_mode() and vesa_set_origin() in sys/i386/isa/vesa.c. If the panic occurs while the console is still in text mode, the bug is in vesa_set_mode(); if it occurs after the console has switched to graphics mode, it's probably in vesa_set_origin(). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
Andrea Campi [EMAIL PROTECTED] writes: Ok, I will try each one. At the moment, I'm using logo_saver. I will let you know. Take a long hard look at vesa_set_mode() and vesa_set_origin() in sys/i386/isa/vesa.c. If the panic occurs while the console is still in text mode, the bug is in vesa_set_mode(); if it occurs after the console has switched to graphics mode, it's probably in vesa_set_origin(). The may be in the VESA BIOS on the video card :-) The vesa module calls the VESA BIOS to change video modes. The bug may not necessarily be in the BIOS "code", but the VESA video mode "table" to which the vesa module refers, when it sets up a new video mode, and calculates and initializes variables in the vesa module. I would like to see full dump of 'vidcontrol -i adapter', 'vidcontrol -i mode' and dmesg after the vesa module is loaded (you get very verbose output from the vesa module init code if you boot the kernel with 'boot -v'). You see, the VESA BIOS support on some video cards is not so complete. For example, we saw in the mailing list recently that the "VGA compatible" bit is somewhat turned off for VESA high resolution modes, didn't we? That possibly was a bug in that VESA BIOS. (OR, those mode ARE genuinely VGA-incompatible and we shouldn't use them the way the vesa modules accesses them...) Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
db x/i,10 0xc025ad3c scrn_timer: pushl %ebp [...] nm just confirmed this, so it definitely looks like scrn_timer is to blame here. Any other instructions? ;-) For the time being, vidcontrol -t off (seems to) keep the machine up. Bye, Andrea Weird, I don't see anything offhand that syscons is doing that would cause it to leak Giant. Hmm. Can you add a the same code before the mtx_enter() of Having gone through yet another series of cvsup - make kernel - panics, I can now confirm this happens if and only if I have VESA defined. A vidcontrol -t off stops the panics. Now I will try to understand what's up, but I should warn you that I'm not really confident with this part of the kernel yet. More details: this is an IBM Thinkpad laptop with APM enabled and in the kernel. As usual, any hint is more than welcome. This used to work... Bye, Andrea -- The three Rs of Microsoft support: Retry, Reboot, Reinstall. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
On 05-Dec-00 Andrea Campi wrote: db x/i,10 0xc025ad3c scrn_timer: pushl %ebp [...] nm just confirmed this, so it definitely looks like scrn_timer is to blame here. Any other instructions? ;-) For the time being, vidcontrol -t off (seems to) keep the machine up. Bye, Andrea Weird, I don't see anything offhand that syscons is doing that would cause it to leak Giant. Hmm. Can you add a the same code before the mtx_enter() of Having gone through yet another series of cvsup - make kernel - panics, I can now confirm this happens if and only if I have VESA defined. A vidcontrol -t off stops the panics. Now I will try to understand what's up, but I should warn you that I'm not really confident with this part of the kernel yet. More details: this is an IBM Thinkpad laptop with APM enabled and in the kernel. As usual, any hint is more than welcome. This used to work... Which screen saver? Does it do it with all of them? Just graphical ones, just text ones, just green_saver, etc.? Bye, Andrea -- John Baldwin [EMAIL PROTECTED] -- 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/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
More details: this is an IBM Thinkpad laptop with APM enabled and in the kernel. As usual, any hint is more than welcome. This used to work... Which screen saver? Does it do it with all of them? Just graphical ones, just text ones, just green_saver, etc.? Rrrright... I can assure you I would never have thought this could make a difference... Ok, I will try each one. At the moment, I'm using logo_saver. I will let you know. Bye, Andrea -- Weird enough for government work. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
On 05-Dec-00 Andrea Campi wrote: More details: this is an IBM Thinkpad laptop with APM enabled and in the kernel. As usual, any hint is more than welcome. This used to work... Which screen saver? Does it do it with all of them? Just graphical ones, just text ones, just green_saver, etc.? Rrrright... I can assure you I would never have thought this could make a difference... That's ok, it didn't occur to me either at first. However, the green_saver calls into APM, and the graphical ones will call into VESA, so it might make a difference. Ok, I will try each one. At the moment, I'm using logo_saver. I will let you know. Bye, Andrea -- Weird enough for government work. -- John Baldwin [EMAIL PROTECTED] -- 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/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
Just as a data point, I just tried this as well... The daemon saver was ok, the fire saver was ok, but as soon as I loaded logo_saver and it activated, I got a 'dc0 timeout'(?) and I was unable to access any of the vtys after that... I could switch vtys, but could not type anything. The fire_saver module is obviously using a VESA mode, but I had no problem problem with it... On Mon, Dec 04, 2000 at 06:41:55PM -0800, John Baldwin wrote: On 05-Dec-00 Andrea Campi wrote: More details: this is an IBM Thinkpad laptop with APM enabled and in the kernel. As usual, any hint is more than welcome. This used to work... Which screen saver? Does it do it with all of them? Just graphical ones, just text ones, just green_saver, etc.? Rrrright... I can assure you I would never have thought this could make a difference... That's ok, it didn't occur to me either at first. However, the green_saver calls into APM, and the graphical ones will call into VESA, so it might make a difference. Ok, I will try each one. At the moment, I'm using logo_saver. I will let you know. Bye, Andrea -- Weird enough for government work. -- John Baldwin [EMAIL PROTECTED] -- 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/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
Sorry, I guess I should specify that this is a desktop with APM enabled in the BIOS, but not being used otherwise... VESA module loaded. #uname -a FreeBSD cae88-102-101.sc.rr.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sat Dec 2 16:07:54 EST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/RHIANNON i386 #kldstat Id Refs AddressSize Name 19 0xc010 234878 kernel 21 0xc0335000 5540 vesa.ko 31 0xc033b000 9eb4 cd9660.ko 41 0xc0345000 eb44 msdos.ko 51 0xc0354000 7a98 procfs.ko 61 0xc035c000 158eclinux.ko 71 0xc0372000 b2cc if_dc.ko 82 0xc037e000 10004miibus.ko 91 0xc038f000 76e0 linprocfs.ko On Mon, Dec 04, 2000 at 09:59:31PM -0500, Donald J . Maddox wrote: Just as a data point, I just tried this as well... The daemon saver was ok, the fire saver was ok, but as soon as I loaded logo_saver and it activated, I got a 'dc0 timeout'(?) and I was unable to access any of the vtys after that... I could switch vtys, but could not type anything. The fire_saver module is obviously using a VESA mode, but I had no problem problem with it... On Mon, Dec 04, 2000 at 06:41:55PM -0800, John Baldwin wrote: On 05-Dec-00 Andrea Campi wrote: More details: this is an IBM Thinkpad laptop with APM enabled and in the kernel. As usual, any hint is more than welcome. This used to work... Which screen saver? Does it do it with all of them? Just graphical ones, just text ones, just green_saver, etc.? Rrrright... I can assure you I would never have thought this could make a difference... That's ok, it didn't occur to me either at first. However, the green_saver calls into APM, and the graphical ones will call into VESA, so it might make a difference. Ok, I will try each one. At the moment, I'm using logo_saver. I will let you know. Bye, Andrea -- Weird enough for government work. -- John Baldwin [EMAIL PROTECTED] -- 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/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
Bad callout handler: c_func = 0xc025ad3c, c_arg=0xc0338460, c_flags=7 First I tried a db x/i,10 0xc025ad3c scrn_timer: pushl %ebp [...] nm just confirmed this, so it definitely looks like scrn_timer is to blame here. Any other instructions? ;-) For the time being, vidcontrol -t off (seems to) keep the machine up. Bye, Andrea Weird, I don't see anything offhand that syscons is doing that would cause it to leak Giant. Hmm. Can you add a the same code before the mtx_enter() of Giant? (But after the mtx_exit() of callout_lock to be on the safe side). Also, add in a 'mtx_assert(Giant, MA_NOTOWNED);' in between teh splx() and splhigh() right below the "Give interrupts a chance" comment up about 15 lines or so. I used a slightly different printf and panic text in order to distinguish between the two. It's still panicing at the lower one, still pointing to scrn_timer. Andrea -- Andrea Campi mailto:[EMAIL PROTECTED] I.NET S.p.A. http://www.inet.it Direzione Tecnica - Gruppo Security Phone :+39.02.40906.1 v. Caldera, 21/d - I-20153 Milano, Italy Fax :+39.02.40906.303 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
We want mtxd_file and mtxd_line. If you look at the output of the last command, it will probably look something like this: ../../kern/kern_timeout.c, line 139 Hope it helps, Andrea -- Andrea Campi mailto:[EMAIL PROTECTED] I.NET S.p.A. http://www.inet.it Direzione Tecnica - Gruppo Security Phone :+39.02.40906.1 v. Caldera, 21/d - I-20153 Milano, Italy Fax :+39.02.40906.303 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
On 29-Nov-00 Andrea Campi wrote:
We want mtxd_file and mtxd_line. If you look at the output of the last
command, it will probably look something like this:
../../kern/kern_timeout.c, line 139
Hmm, and the failed assertion was:
panic: mutex Giant owned at ../../kern/kern_intr.c:238
So it looks like we aren't releasing Giant, or that one of the callouts we
called is getting giant but not releasing it. In sys/kern/kern_timeout.c, add
in this: (at around line 139)
if (!(c_flags CALLOUT_MPSAFE))
mtx_enter(Giant, MTX_DEF);
splx(s);
c_func(c_arg);
s = splhigh();
if (!(c_flags CALLOUT_MPSAFE))
mtx_exit(Giant, MTX_DEF);
/* add if statement below this */
if (mtx_owned(Giant)) {
printf("Bad callout handler: c_func = %p, c_arg = %p, c_flags = %d\n",
c_func, c_arg, c_flags);
panic("bad callout");
}
Then when it panics write down the values that get printed out. Next,
do 'nm /sys/compile/MYKERNEL/kernel.debug | sort' and look for the function
whose address matches the c_func address printed out, then send this info back
please. :)
Hope it helps,
Andrea
--
John Baldwin [EMAIL PROTECTED] -- 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/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
Then when it panics write down the values that get printed out. Next, do 'nm /sys/compile/MYKERNEL/kernel.debug | sort' and look for the function whose address matches the c_func address printed out, then send this info back please. :) This time it took me 1 hour to get the panic, compared to a few minutes of earlier panics. So, I got: Bad callout handler: c_func = 0xc025ad3c, c_arg=0xc0338460, c_flags=7 First I tried a db x/i,10 0xc025ad3c scrn_timer: pushl %ebp [...] nm just confirmed this, so it definitely looks like scrn_timer is to blame here. Any other instructions? ;-) For the time being, vidcontrol -t off (seems to) keep the machine up. Bye, Andrea -- Andrea Campi mailto:[EMAIL PROTECTED] I.NET S.p.A. http://www.inet.it Direzione Tecnica - Gruppo Security Phone :+39.02.40906.1 v. Caldera, 21/d - I-20153 Milano, Italy Fax :+39.02.40906.303 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
On 29-Nov-00 Andrea Campi wrote: Then when it panics write down the values that get printed out. Next, do 'nm /sys/compile/MYKERNEL/kernel.debug | sort' and look for the function whose address matches the c_func address printed out, then send this info back please. :) This time it took me 1 hour to get the panic, compared to a few minutes of earlier panics. So, I got: Bad callout handler: c_func = 0xc025ad3c, c_arg=0xc0338460, c_flags=7 First I tried a db x/i,10 0xc025ad3c scrn_timer: pushl %ebp [...] nm just confirmed this, so it definitely looks like scrn_timer is to blame here. Any other instructions? ;-) For the time being, vidcontrol -t off (seems to) keep the machine up. Bye, Andrea Weird, I don't see anything offhand that syscons is doing that would cause it to leak Giant. Hmm. Can you add a the same code before the mtx_enter() of Giant? (But after the mtx_exit() of callout_lock to be on the safe side). Also, add in a 'mtx_assert(Giant, MA_NOTOWNED);' in between teh splx() and splhigh() right below the "Give interrupts a chance" comment up about 15 lines or so. -- John Baldwin [EMAIL PROTECTED] -- 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/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
