Patch to sys/i386/isa/vesa.c (Need check before submit pls)
This is the first patch I've ever submitted.
In fact, I can't even take credit for it - some body submitted it to a
newsgroup last year. But I think it should be integrated into the vesa.c
code.
If anyone has time to read over it, I'd appreciate any suggestions, an
help with the one question below.
Tested on FreeBSD 4.7-STABLE (as of a week or so ago). I would have used a
-CURRENT box but I don't have one any more :-/ Sorry if this causes
problems.
The code is designed to set the default refresh rate for the console to
100Hz, when you set the resolution with vidcontrol to VESA_800x600.
It first flips to 1024x768, and saves some registers, then flips back to
800x600 and applies those to get the 100Hz.
I'm wanting to request this patch be included into FreeBSD, because I've
started using FreeBSD on a daily basis in console-only mode, and at
resolutions about the default 600x400 that is run a 70Hz, the refresh rate
drops to 60Hz which hurts the eyes for a while.
As you have to compile SC_PIXEL_MODE into the kernel, and do 'vidcontrol
VESA_800x600' for this to work, we're not changing any defaults that will
effect everyone.
I would really have loved it if the default driver or vidcontrol could let
you set whatever refresh rate you want, but I have no idea why they do
not. to me it seems like an obvious extension of what is present.
The question is: Does anyone know how this code can be changed to set the
refresh rate to something a little saner like 85Hz, which is a good
standard that most recent made in the last 5 years can support?
Finally, the code diff:
--- src,orig/sys/i386/isa/vesa.cSat Jan 29 18:08:40 2000
+++ src/sys/i386/isa/vesa.c Thu Mar 16 11:44:31 2000
@@ -1019,7 +1016,25 @@
if (!(info.vi_flags V_INFO_GRAPHICS))
info.vi_flags = ~V_INFO_LINEAR;
- if (vesa_bios_set_mode(mode | ((info.vi_flags V_INFO_LINEAR) ? 0x4000 : 0)))
+ if (mode == M_VESA_800x600) { /* XXX ignores V_INFO_LINEAR */
+ unsigned char crtc[0x19];
+ unsigned char reg;
+ if (vesa_bios_set_mode(mode))
+ return 1;
+ for (reg=0;reg0x19;++reg) {
+ outb(0x3d4,reg);
+ crtc[reg]=inb(0x3d5);
+ }
+ if (!vesa_bios_set_mode(M_VESA_1024x768)) {
+ outb(0x3d4,0x11);
+ outb(0x3d5,crtc[0x11]0x7f);
+ for (reg=0;reg0x19;++reg) {
+ outb(0x3d4,reg);
+ outb(0x3d5,crtc[reg]);
+ }
+ }
+ } else
+ if (vesa_bios_set_mode(mode | ((info.vi_flags V_INFO_LINEAR) ? 0x4000 :
+0)))
return 1;
if (adp-va_info.vi_flags V_INFO_LINEAR)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Re[2]: 80386 out of GENERIC
On Sat, 14 Dec 2002, [EMAIL PROTECTED] wrote: FreeBSD still runs on all 386 family CPUs, the only difference is that if you want to run it on a 80386 you need to enable an option in your kernel config file. It will out of the box run on 486 and anything later. It means that you can not install FreeBSD on a 386 unless you have a 486+ machine that can compile a new FreeBSD system and have a way to get that version to the 386. Too bad. Harsh, but understandable. How difficult would the following be to develop, in your opinion? A boot disk image (like the sets of images on the website tm) that will boot on 386's as well as more modern CPU's that can newfs and disklabel your drives, download the source, and let you compile from that point. That way you don't need to transfer from one box to another, and you get the compiled install you want right away. I'd maybe like ot help with something like this but my abilities and experience are somewhat limited :-) It shouldn't really be that hard should it? You just need the boot disks, with utilities that are: newfs disklabel ifconfig something to download with (fetch? wget?) something to compile with - which can be downloaded with the source all precompile so the do work on all x86 CPU's. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: about freebsd current version
Prasad, I'm glad to see that you have taken an interest in FreeBSD. Unfortunately the -CURRENT branch is a development branch. This means it it known to have many many bugs and is garaunteed not to be stable for everyday use. As an example, I installed the -CURRENT software two days ago and have had crashes every few hours! This branch is to help develop the next release of FreeBSD. I would recommend you install the -STABLE branch (the most stanble) or -RELEASE (fairly stable with the probability of a few bugs here and there). Instructions for this and a lot of other good documentation on getting started with FreeBSD can be found at: http://www.freebsd.org/handbook I hope this help Avleen Vig US, originally UK, nativally India also :P On Tue, 25 Jun 2002, Prasad Iyer wrote: Sir, I have recently downloaded freebsd Current Version. I am new to Freebsd. I am installing Freebsd from DOS media. During the installation it is not able to find bin directory I search your FTP site for this directory but wasn't able to find it. Can you please help me with this. Your early reply would be highly appreciated. As a programmer I am very restless. Thanks regards Prasad Iyer (india) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Panic: ffs_mapsearch, ffs_alloccg: map corrupted
Hey folks,
First off, please excuse me if I've missed any detail here. I'm not a
programmer but I do want to help find and eliminate bugs in -CURRENT.
I'm using DP1, downloaded and installed just yesterday.
While executing: pkg_add -vf
ftp://ftp2.freebsd.org/pub/FreeBSD/ports/i386/packages-4-stable/net/gaim-0.58.tgz
the system panics. I kgdb'd the cores (following the instructions at
http://www.onlamp.com/lpt/a/bsd/2002/04/04/Big_Scary_Daemons.html), and
got the data included at the end of this mail.
The small digs I've made here and there show this problem (or some very
similar ones) around for the last few years?
Note: I can consistantly reproduce this problem with the above command.
Here are the specifics of my hardware:
Intel P233MMX, 128Mb PC66 SDRAM, Seagate 4Gb UDMA33 Hard Drive, Intel
Triton TX chipset, ASUS TX97-L motherboard, D-Link 530TX+ 10/100 NIC
(Realtek 8139B chipset).
Thanks!
Core data:
#0 dumpsys () at ../../../kern/kern_shutdown.c:505
505 ../../../kern/kern_shutdown.c: No such file or directory.
(kgdb) where
#0 dumpsys () at ../../../kern/kern_shutdown.c:505
#1 0xc023fd13 in boot (howto=260) at ../../../kern/kern_shutdown.c:337
#2 0xc024019d in panic (fmt=0xc03b6799 bremfree: bp %p not locked) at
../../../kern/kern_shutdown.c:647
#3 0xc026f3e5 in bremfree (bp=0xc400efd8) at ../../../kern/vfs_bio.c:619
#4 0xc0270b07 in vfs_bio_awrite (bp=0xc400efd8) at ../../../kern/vfs_bio.c:1596
#5 0xc021c664 in spec_fsync (ap=0xc9a8c970) at ../../../fs/specfs/spec_vnops.c:403
#6 0xc021c251 in spec_vnoperate (ap=0xc9a8c970) at ../../../fs/specfs/spec_vnops.c:121
#7 0xc031edc1 in ffs_sync (mp=0xc1889600, waitfor=2, cred=0xc0b39980, td=0xc0407b60)
at vnode_if.h:441
#8 0xc027c3a7 in sync (td=0xc0407b60, uap=0x0) at ../../../kern/vfs_syscalls.c:669
#9 0xc023f9a3 in boot (howto=256) at ../../../kern/kern_shutdown.c:246
#10 0xc024019d in panic (fmt=0xc03c835f ffs_alloccg: map corrupted) at
../../../kern/kern_shutdown.c:647
#11 0xc03121fa in ffs_mapsearch (fs=0xc189d000, cgp=0xc4897000, bpref=364552,
allocsiz=5)
at ../../../ufs/ffs/ffs_alloc.c:1735
#12 0xc0310d6e in ffs_alloccg (ip=0xc1929000, cg=4, bpref=364552, size=6144) at
../../../ufs/ffs/ffs_alloc.c:1075
#13 0xc031084b in ffs_hashalloc (ip=0xc1929000, cg=4, pref=364552, size=6144,
allocator=0xc0310b44 ffs_alloccg)
at ../../../ufs/ffs/ffs_alloc.c:888
#14 0xc030f8f5 in ffs_alloc (ip=0xc1929000, lbn=0, bpref=364552, size=6144,
cred=0xc18ef580, bnp=0xc9a8cb30)
at ../../../ufs/ffs/ffs_alloc.c:145
#15 0xc0312c63 in ffs_balloc (a_vp=0xc9ac9fe0, a_startoffset=0, a_size=4335,
a_cred=0xc18ef580, a_flags=1, a_bpp=0xc9a8cc00)
at ../../../ufs/ffs/ffs_balloc.c:163
#16 0xc031fb29 in ffs_write (ap=0xc9a8cc24) at ../../../ufs/ufs/ufs_readwrite.c:506
#17 0xc0282513 in vn_write (fp=0xc191f4c0, uio=0xc9a8cc90, cred=0xc18ef580, flags=0,
td=0xc9a46c60) at vnode_if.h:303
#18 0xc0257716 in dofilewrite (td=0xc9a46c60, fp=0xc191f4c0, fd=4, buf=0x80c6200,
nbyte=4335, offset=-1, flags=0)
at ../../../sys/file.h:191
#19 0xc02575cf in write (td=0xc9a46c60, uap=0xc9a8cd20) at
../../../kern/sys_generic.c:332
#20 0xc0360e33 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi =
135029248, tf_esi = 4335,
tf_ebp = -1077937304, tf_isp = -911684236, tf_ebx = 1549, tf_edx = -1, tf_ecx =
2, tf_eax = 4, tf_trapno = 12,
tf_err = 2, tf_eip = 134593523, tf_cs = 31, tf_eflags = 647, tf_esp =
-1077937668, tf_ss = 47})
at ../../../i386/i386/trap.c:1049
#21 0xc03547ad in syscall_with_err_pushed ()
#22 0x8050b71 in ?? ()
#23 0x8052f26 in ?? ()
#24 0x8048135 in ?? ()
(kgdb) up 11
#11 0xc03121fa in ffs_mapsearch (fs=0xc189d000, cgp=0xc4897000, bpref=364552,
allocsiz=5)
at ../../../ufs/ffs/ffs_alloc.c:1735
1735../../../ufs/ffs/ffs_alloc.c: No such file or directory.
(kgdb) p fs
$1 = (struct fs *) 0xc189d000
(kgdb) p cgp
$2 = (struct cg *) 0xc4897000
(kgdb) p bpref
$3 = 0
(kgdb) p allocsiz
$4 = 5
(kgdb) p *fs
$5 = {fs_firstfield = 0, fs_unused_1 = 0, fs_sblkno = 8, fs_cblkno = 16, fs_iblkno =
24, fs_dblkno = 1368,
fs_cgoffset = 1024, fs_cgmask = -1, fs_time = 1024945463, fs_size = 1649527,
fs_dsize = 1623678, fs_ncg = 19,
fs_bsize = 16384, fs_fsize = 2048, fs_frag = 8, fs_minfree = 8, fs_rotdelay = 0,
fs_rps = 60, fs_bmask = -16384,
fs_fmask = -2048, fs_bshift = 14, fs_fshift = 11, fs_maxcontig = 7, fs_maxbpg =
4096, fs_fragshift = 3, fs_fsbtodb = 2,
fs_sbsize = 2048, fs_csmask = -1024, fs_csshift = 10, fs_nindir = 4096, fs_inopb =
128, fs_nspf = 4, fs_optim = 0,
fs_npsect = 4096, fs_interleave = 1, fs_trackskew = 0, fs_id = {1024840762,
641071059}, fs_csaddr = 1368,
fs_cssize = 2048, fs_cgsize = 16384, fs_ntrak = 1, fs_nsect = 4096, fs_spc = 4096,
fs_ncyl = 1611, fs_cpg = 89,
fs_ipg = 21504, fs_fpg = 91136, fs_cstotal = {cs_ndir = 12710, cs_nbfree = 174479,
cs_nifree = 325467, cs_nffree = 18859},
fs_fmod = 1 '\001', fs_clean = 0 '\000', fs_ronly = 0 '\000', fs_flags = 2 '\002',
