On Tuesday 16 March 2010 08:24 pm, barbara wrote: > > On Tuesday 16 March 2010 06:32 pm, barbara wrote: > > > > On Monday 15 March 2010 08:19 pm, barbara wrote: > > > > > > On Monday 15 March 2010 02:41 pm, Jung-uk Kim wrote: > > > > > > > Can you please try the attached patch? > > > > > > > > > > > > Oops, it attached a wrong patch. Please try this > > > > > > instead. > > > > > > > > > > > > Sorry for the inconvenience, > > > > > > > > > > > > Jung-uk Kim > > > > > > > > > > I had the same problem on RELENG_8 since yesterday (prev. > > > > > buildworld on Feb. 28). I've tried rebuilding the kernel > > > > > with your patch but no luck. > > > > > > > > Your problem may be different. Different VESA BIOS has > > > > different quirks. Your BIOS actually sets non-VGA compatible > > > > bits correctly. However, there is no standard VGA graphic > > > > mode at all, which is pretty strange. > > > > > > Just for my personal understanding, can you explain me what > > > does it means that "there is no standard VGA graphic mode at > > > all" and what make you say that? > > > > Your "vidcontrol -i mode" output from the previous e-mail, i.e., > > all graphic mode belong to VESA mode (starting from 0x100). > > Thanks for explaining! > > > Are you sure you have SC_PIXEL_MODE in your kernel configuration? > > Yes, as you can seen from my reply to the other question. > > > > > What's your graphics card? > > > > > > vgap...@pci0:2:0:0: class=0x030000 card=0x00000000 > > > chip=0x042110de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' > > > device = 'GeForce 8500 GT (G86)' > > > class = display > > > subclass = VGA > > > > Thanks. I guess I have to buy one of those nVidia thingies. :-( > > > > > > > I had to comment the 'allscreens_flags="MODE_280"' line in > > > > > my /etc/rc.conf as the monitor was going black with 'NO > > > > > SIGNAL' on OSD. You asked to the OP if the box is pingable. > > > > > I think that you want to know if the kernel is still alive, > > > > > am I right? I can "blindly" login and reboot the pc while > > > > > the screen is black. > > > > > > > > So, it is not rendering anything on screen. Hmm... Can you > > > > please try the attached patch? > > > > > > No luck also with the new patch. > > > I've applied it to the original file, not to the one with your > > > previous patch, is that correct? > > > > Either way is fine. > > > > > It's not rendering anything because the led of the monitor > > > turns from blue to orange, just like when the pc is turned off > > > and the monitor is on. This happens running vidcontrol -i > > > MODE_X where X is one of the modes of type "G" (as I've said I > > > had to comment the allscreens_flags line in /etc/rc.conf). And > > > if I subsequently switch to another ttyv with alt+f[1-8], the > > > mode is not the default 80x25 as normally expected and the led > > > is still orange and sometimes the speaker plays a beep! > > > > Okay, something is very wrong. Can you please try the following? > > > > sysctl debug.x86bios.call=1 > > sysctl debug.x86bios.int=1 > > vidcontrol MODE_X > > vidcontrol MODE_24 <- Sorry, you will have to blindly type it. > > > > And please send me the dmesg output. > > I did that with a script, so no blindly typing was necessary. > I used MODE_280, which is the one I normally use.
:-) > I see the following two lines appended to dmesg: > Calling int 0x10 (ax=0x4f02 bx=0x4118 cx=0x0000 dx=0x0000 es=0x0000 > di=0x0000) Exiting int 0x10 (ax=0xc470 bx=0x0000 cx=0x52e4 > dx=0x0000 es=0xc000 di=0x0000) Is the output of the test ok? I mean > is it what did you expected in terms of quantity? No, I didn't expect it. It seems the real mode emulator has terminated execution abruptly. We need to gather more information off the list. Jung-uk Kim _______________________________________________ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
