Re: Panic changing screen mode with vidcontrol
+---[ Peter Jeremy ]-- | Having installed a new kernel and userland from sources about a day | old, my vidcontrol command now causes a panic: [snip] | The command I used was vidcontrol 132x60 after confirming that | this was listed in vidcontrol -i mode. I have previously been | using VESA_132x60, but that also panics now. Was X running ? I get a panic on changing to VESA modes when X is already running. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Bug in libalias (firewall manipulating)
On Mon, Nov 26, 2001 at 04:40:19AM +0100, Daniel Rock wrote: Hi, just noticed: adding dynamic rules to ipfw via PKT_ALIAS_PUNCH_FW (or the command nat punch_fw in ppp) doesn't work: For adding firewall rules, IP_FW_ADD requires getsockopt() instead of setsockopt(). This should also be reflected in the manual page. Below is my fix and a quick test suggest it is indeed working now. Fixed in 5.0-CURRENT, sys/netinet/raw_ip.c,v 1.88. Fixed in 4.4-STABLE, sys/netinet/raw_ip.c,v 1.64.2.10. Thanks for the report! Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df -l broken
In my dual Pentium3/1GHz box: % uname -a FreeBSD mako.kobe1995.net 5.0-CURRENT-20010830-JPSNAP FreeBSD 5.0-CURRENT-20010830-JPSNAP #9: Sat Nov 3 17:05:25 JST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KOBE5SMP i386 % df -l Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/da0s1a127023572155964749%/ devfs 110 100%/dev /dev/da0s1e 3935347 112806 3507714 3%/usr /dev/da0s2a127023346898217330%/altroot procfs 440 100%/proc % In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: If my patch is exact, then the bug should manifest itself only if there are no network filesystems mounted. Do you have any network fs mounted on your box ? % df Filesystem1K-blocks UsedAvail Capacity Mounted on /dev/da0s1a 127023572155964749%/ devfs 110 100%/dev /dev/da0s1e 3935347 112806 3507714 3%/usr /dev/da0s2a 127023346898217330%/altroot procfs440 100%/proc ace:/home 2318686 1079119 105407351%/home ace:/var/mail 63567 6558417 0%/var/mail safa:/mnt 113956615 1048400860 100%/mnt safa:/usr/local 1016047 9605325551595%/usr/local safa:/usr/X11R6 1016047 9605325551595%/usr/X11R6 safa:/mnt/ftp/pub/obj 113956615 1048400860 100%/usr/obj -- mailto:[EMAIL PROTECTED] NAKAMURA Kazushi@KOBE http://kobe1995.net/~kaz/index-e.html - Break the hate chain. No more kill! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 3CXFE575CT-JP with NEWCARD doesn't work
In message [EMAIL PROTECTED] Yoichi NAKAYAMA writes: : I think this trouble can be easily solved if we can controll : PCCBB_START_IO as we can controll PCCBB_START_MEM by last change: Yes. That would be true. I didn't do it with that commit. I'll go ahead and do it for I/O. It may change because pccbb uses a different I/O address range for 16-bit vs 32-bit. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Still panic() with userland binary on CURRENT
On 24-Nov-01 Martin Blapp wrote: Hi DES, - realitexpire, td); + realitexpire, td-td_proc); Fixes the panic 100%. Thanks a lot ! Martin Ouch, something this simple definitely caused a warning, it looks like warnings are being ignored. :( Time for another warning sweep of LINT perhaps. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ 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: where is the idle_loop in current ?
On 23-Nov-01 Luigi Rizzo wrote: In order to port my network polling stuff to current, I was looking at ways to do things within the idle loop, and was pointed to the idle_proc() or vm_pagezero() . I am listing below the code for these kernel threads (I hope the name is the correct one). I do not follow, however, the reason why these two threads periodically give up the CPU, given that their priority is (i guess) lower than any other thread in the system, so any event that should wake up a thread would immediately cause their preemption. Where am i wrong ? We don't do preemption in the kernel yet, so they need to yield the CPU when another thread is available. The page zeroing thread does this wrong as it should check procrunnable() instead of switching after doing N pages. The idle loop idle_proc() can't do any work w/o breaking priority propagation. If you wish to do low priority work, create a idle priority kthread to do it and make sure it yields when there is other work to do of higher priority. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ 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: send_packet: No buffer space available
So this means the output queue on my net card is full, right? And I guess there is no easy solution... Oh well, I'll have to cope. That's correct; the pipe is full, and you can't put any more bits in it. Typically you run into this situation when your app is generating more data than can squirt out the hole in your network card, or the card is stalled for some reason. Any app using socket I/O should be ready to handle ENOBUFS gracefully; it typically needs to pause and then retry the I/O. So, no solution, right? :( If the card is stalled (possible), then you may have a driver problem. But otherwise, it's not a problem except in the application. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: send_packet: No buffer space available
On Mon, Nov 26, 2001 at 05:49:01PM +0100, Andrea Campi wrote:
OK, I traced it to sys/netinet/ip_output.c:
/*
* Verify that we have any chance at all of being able to queue
* the packet or packet fragments
*/
if ((ifp-if_snd.ifq_len + ip-ip_len / ifp-if_mtu + 1) =
ifp-if_snd.ifq_maxlen) {
error = ENOBUFS;
ipstat.ips_odropped++;
goto bad;
}
So this means the output queue on my net card is full, right? And I guess
It means that the interface output queue is full, yes.
there is no easy solution... Oh well, I'll have to cope. But I still wonder,
shouldn't this show up on netstat -i? netstat -s does show the dropped packets,
anyway...
I'm not sure about this. In fact, that's a good question. Usually,
if the queue is full, we should increment ifp-if_snd.ifq_drops as well
as ipstat.ips_odropped. Perhaps this test ought to be more like:
[lock ifp-if_snd]
if ((ifp-if_snd.ifq_len + ip-ip_len / ifp-if_mtu + 1)
ifp-if_snd.ifq_maxlen) {
error = ENOBUFS;
_IFQ_DROP(ifp-if_snd);
ipstat.ips_odropped++;
goto bad;
}
[queue packet...]
[etc...]
[unlock ifp-if_snd]
Note that we presently don't lock anything (this is expected, we
haven't gotten there yet). However, note also that in the new version we
also do an _IFQ_DROP() if we have exceeded the ifq_maxlen, and
finally, also note that the new test is and not = - I don't know
why it is = to begin with. One would think that we should be testing
for whether we are going to _exceed_ ifq_maxlen, not if we're going to
reach it (we should be allowed to reach it).
You should take my suggestion here with a grain of salt, and I think
the best person to comment on this is Jonathan Lemon. summons jlemon
So, no solution, right? :(
Well, you're sending out packets faster than your hardware can
transmit them. You can `artificially' define IFQ_MAXLEN to something
greater than 50 but practically, you probably won't get much besides for
consuming more memory for the output queue.
Bye,
Andrea
--
The best things in life are free, but the
expensive ones are still worth a look.
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: send_packet: No buffer space available
Note that we presently don't lock anything (this is expected, we haven't gotten there yet). However, note also that in the new version we also do an _IFQ_DROP() if we have exceeded the ifq_maxlen, and finally, also note that the new test is and not = - I don't know why it is = to begin with. One would think that we should be testing for whether we are going to _exceed_ ifq_maxlen, not if we're going to reach it (we should be allowed to reach it). OK, this makes a lot of sense. So, no solution, right? :( Well, you're sending out packets faster than your hardware can transmit them. You can `artificially' define IFQ_MAXLEN to something greater than 50 but practically, you probably won't get much besides for consuming more memory for the output queue. Well, my main worry is to make sure FreeBSD works at least as well as any other OS our customers may be using or familiar with; I'm not really worried about performance of my -CURRENT laptop (or I'd run -STABLE ;-). Given that it's more of an hardware issue, I'm not really tempted to hack around it, expecially given that you admit it won't do much. So, at least now we know what to answer if the question arises again (I has several people who send 'me too' emails to me). Thanks for helping, 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
LINT fails due to '/bin/sh:Argument list too long'
Decided to run a LINT build on my POSIX.1e capability tree in p4 today, and ran into something a bit unusual: make buildkernel KERNCONF=LINT ... boss/p4/rwatson/trustedbsd/cap/sys/kern/link_aout.c /cboss/p4/rwatson/trustedbsd/cap/sys/kern/subr_diskmbr.c /cboss/p4/rwatson/trustedbsd/cap/sys/libkern/divdi3.c /cboss/p4/rwatson/trustedbsd/cap/sys/libkern/moddi3.c /cboss/p4/rwatson/trustedbsd/cap/sys/libkern/qdivrem.c /cboss/p4/rwatson/trustedbsd/cap/sys/libkern/ucmpdi2.c /cboss/p4/rwatson/trustedbsd/cap/sys/libkern/udivdi3.c /cboss/p4/rwatson/trustedbsd/cap/sys/libkern/umoddi3.c vnode_if.c hints.c env.c config.c /cboss/p4/rwatson/trustedbsd/cap/sys/i386/i386/genassym.c /bin/sh:Argument list too long *** Error code 1 Stop in /usr/obj/cboss/p4/rwatson/trustedbsd/cap/sys/LINT. *** Error code 1 Stop in /usr/obj/cboss/p4/rwatson/trustedbsd/cap/sys/LINT. *** Error code 1 Stop in /cboss/p4/rwatson/trustedbsd/cap. *** Error code 1 Stop in /cboss/p4/rwatson/trustedbsd/cap. Looks like the number of C files in the kernel was finally too much for the make depend :-). Haven't seen this on my other trees I built LINT on lately, so my guess is we're just at the threshold, and one or two more files (such as in my p4 tree) bumps you over. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kvm_getswapinfo() not backwards compatible?
Hey gang,
I have the following piece of code:
extern void
getswapload()
{
struct kvm_swap swap[1];
int pgsize,
swapused, n;
kd = kvm_open(/dev/null, /dev/null, /dev/null, O_RDONLY, kvm_open);
n = kvm_getswapinfo(kd, swap, 1, 0);
if (n 0 || swap[0].ksw_total == 0) {
perror(kvm_getswapinfo);
exit(1);
}
pgsize = getpagesize();
swapused = swap[0].ksw_used * pgsize / 1024;
snprintf(result, sizeof(result), %d, swapused);
kvm_close(kd);
return;
}
As you all can see, this puts the amount of swap used in KB in the
global variable result. It's not unlike the top(1) utility does it.
But... it doesn't seem to work on STABLE, but it does fine on CURRENT.
My STABLE machine yields the following:
kvm_open: short read
getinfo: cannot read nswdev:
kvm_open: short read
getinfo: cannot read dmmax:
kvm_open: short read
getinfo: cannot read sw:
kvm_open: short read
getinfo: cannot read sw:
kvm_open: short read
getinfo: cannot read swapblist:
kvm_getswapinfo: Undefined error: 0
I checked the top(1) source on a STABLE machine for reference. No luck
there, It does it the same way. What am I doing wrong? In what way are
the two calls different on CURRENT and STABLE?
Cheers,
Emiel
--
Concept, n.:
Any idea for which an outside consultant billed you more than
$25,000.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Still panic() with userland binary on CURRENT
On Mon, 26 Nov 2001 09:43:31 -0800 (PST), John Baldwin [EMAIL PROTECTED] said: - realitexpire, td); + realitexpire, td-td_proc); Ouch, something this simple definitely caused a warning, it looks like warnings are being ignored. :( Nope. Look at the prototype for callout_reset() and then think about why the last two parameters have the type that they do. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: df -l broken
Paul van der Zwan wrote: I noticed the -l option of the df command is broken. It is supposed to print df for local filesystems but on my system it prints nothing at all. I had a quick look at the code , as far as I can tell it uses sysctl to figure out the mounted filesystems but thinks all of them are non-local and ignores them. Using sysctl -a I could not find any entries which looked vaguely like describing a mount.. Paul Could you please test the attached patch ? I did it in a hurry but it may fix the problem. It looks ok to me, just the local mounts show up.. Paul -- Paul van der Zwan paulz @ trantor.xs4all.nl I think I'll move to theory, everything works in theory... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic changing screen mode with vidcontrol
On 2001-Nov-26 18:26:14 +1000, Andrew Kenneth Milton [EMAIL PROTECTED] wrote: +---[ Peter Jeremy ]-- | Having installed a new kernel and userland from sources about a day | old, my vidcontrol command now causes a panic: [snip] | The command I used was vidcontrol 132x60 after confirming that | this was listed in vidcontrol -i mode. I have previously been | using VESA_132x60, but that also panics now. Was X running ? No. The problem originally surfaced in the vidcontrol triggered by the allscreens_flags in my rc.conf. I confirmed it in single user mode without any alse running. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Still panic() with userland binary on CURRENT
On 26-Nov-01 Garrett Wollman wrote: On Mon, 26 Nov 2001 09:43:31 -0800 (PST), John Baldwin [EMAIL PROTECTED] said: - realitexpire, td); + realitexpire, td-td_proc); Ouch, something this simple definitely caused a warning, it looks like warnings are being ignored. :( Nope. Look at the prototype for callout_reset() and then think about why the last two parameters have the type that they do. Bah, you're right. -GAWollman -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ 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
nfsclient and amd
It looks like using amd to mount remote hosts on /net will not cause the nfsclient.ko module to be loaded. This causes the mounts to fail. Maybe rc.network kan be changed to kldload the nfsclient.ko module if it is not built into the kernel, just like it does for the server module ?? Paul -- Paul van der Zwan paulz @ trantor.xs4all.nl I think I'll move to theory, everything works in theory... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdrecord produces broken CDs on -CURRENT
On Mon, Nov 26, 2001 at 16:26:18 +0100, Christoph Herrmann wrote: Hi, Im running -STABLE and -CURRENT from different disks on the same box. And with -STABLE there are no problems burning CDs with a YAMAHA CRW6416S on an Adaptec 2940. But withs -CURRENT all CDs are broken. Cdrecord produces no Error messages and exits normaly, but there are areas with binary zeros on the CD. I tested several versions of cdrecord, the newest out of the ports, I compiled a staticly linked cdrecord on -STABLE which is running fine there. But the result on -CURRENT is always the same: The CDs are broken and they are identical, no matter which version of cdrecord I use. Are there any known problems with /dev/pass* ? What else could be the problem? So did you try the statically linked -stable binary on -current? Is it completely static? (i.e. ldd cdrecord should report that it isn't a dynamic executable) That may help narrow the problem down somewhat. I'm not sure, though, whether the -stable binary will work with the pass interface on -current. Are there any areas with good data on the CD? i.e. can you see any pattern to the corruption? If you compare the same CD burned from -current and -stable you might begin to see a patern. Is the table of contents correct? Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libfetch kqueue patch
On Mon, 26 Nov 2001 15:27:45 -0500 (EST), Andrew R. Reiter [EMAIL PROTECTED] said: As from OpenBSD (in shorter form): fd_set *fds = calloc(howmany(fd+1, NFDBITS), sizeof(fd_mask)); But this is not portable. The application is not allowed to assume anything about the structure of an fd_set, or the existence of a type `fd_mask', or the existence of a macro `howmany' (which is actually prohibited). The only portable (in the sense of officially standardized) interface that doesn't suffer from this problem is poll(). -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kvm_getswapinfo() not backwards compatible?
On Mon, 26 Nov 2001, Emiel Kollof wrote:
Hey gang,
I have the following piece of code:
extern void
getswapload()
{
struct kvm_swap swap[1];
int pgsize,
swapused, n;
kd = kvm_open(/dev/null, /dev/null, /dev/null, O_RDONLY, kvm_open);
This looks wrong I think you want the first three arguments to be
NULL, not /dev/null.
/dev/null is not a kernel image. :-)
Doug White| FreeBSD: The Power to Serve
[EMAIL PROTECTED] | www.FreeBSD.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
[PATCH] - categorizing (XXX Lines) in NOTES
hi all, this patch will put an end to those XXX lines in the NOTES file, which were regarding uncategorized options.. such as USERCONFIG etc. I am also attaching a tar.gz package which has the patch compressed and archived. thanks.. regards... Hiten Pandya [EMAIL PROTECTED] [EMAIL PROTECTED] PATCH is below... *** NOTES.old Sun Nov 25 12:54:58 2001 --- NOTES Sun Nov 25 13:11:35 2001 *** *** 292,298 # # Implement system calls compatible with 4.3BSD and older versions of # FreeBSD. You probably do NOT want to remove this as much current code ! # still relies on the 4.3 emulation. # options COMPAT_43 --- 292,299 # # Implement system calls compatible with 4.3BSD and older versions of # FreeBSD. You probably do NOT want to remove this as much current code ! # still relies on the 4.3 emulation.# XXX - this doesn't belong here. ! # options COMPAT_43 *** *** 420,435 # options COMPILING_LINT - - # XXX - this doesn't belong here. - # Allow ordinary users to take the console - this is useful for X. - options UCONSOLE - - # XXX - this doesn't belong here either - #options USERCONFIG #boot -c editor - #options INTRO_USERCONFIG#imply -c and show intro screen - #options VISUAL_USERCONFIG #visual boot -c editor - # # NETWORKING OPTIONS --- 421,426 *** *** 1150,1158 # EISA, MCA, PCI and pccard are self identifying buses, so no hints # are needed. ! # # Mandatory devices: ! # # The keyboard controller; it controls the keyboard and the PS/2 mouse. deviceatkbdc 1 --- 1141,1149 # EISA, MCA, PCI and pccard are self identifying buses, so no hints # are needed. ! #-- # Mandatory devices: ! #-- # The keyboard controller; it controls the keyboard and the PS/2 mouse. deviceatkbdc 1 *** *** 1189,1194 --- 1180,1189 #for some laptops options PSM_RESETAFTERSUSPEND #reset the device at the resume event + #-- + # Video/Display Related Configuration Options + #-- + # The video card driver. devicevga hint.vga.0.at=isa *** *** 1231,1236 --- 1226,1238 devicestar_saver devicewarp_saver + #-- + # Console Related Configuration Options + #-- + + # Allow ordinary users to take the console - this is useful for X. + options UCONSOLE + # The pcvt console driver (vt220 compatible). devicevt hint.vt.0.at=isa *** *** 1347,1355 deviceacpica options ACPI_DEBUG ! # # Optional devices: ! # # # SCSI host adapters: --- 1349,1357 deviceacpica options ACPI_DEBUG ! #-- # Optional devices: ! #-- # # SCSI host adapters: *** *** 2891,2897 --- 2893,2905 options PANIC_REBOOT_WAIT_TIME=16 # + # MISCELLENEOUS OPTIONS + #options USERCONFIG #boot -c editor + #options INTRO_USERCONFIG#imply -c and show intro screen + #options VISUAL_USERCONFIG #visual boot -c editor + + # # More undocumented options for linting. # Note that documenting these are not considered an affront. *** *** 2955,2958 options VM_KMEM_SIZE options VM_KMEM_SIZE_MAX ! options VM_KMEM_SIZE_SCALE --- 2963,2966 options VM_KMEM_SIZE options VM_KMEM_SIZE_MAX ! options VM_KMEM_SIZE_SCALE __ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[PATCH] - categorizing (XXX Lines) in NOTES
hi all, this patch will put an end to those XXX lines in the NOTES file, which were regarding uncategorized options.. such as USERCONFIG etc. I am also attaching a tar.gz package which has the patch compressed and archived. thanks.. regards... Hiten Pandya [EMAIL PROTECTED] [EMAIL PROTECTED] PATCH is below... *** NOTES.old Sun Nov 25 12:54:58 2001 --- NOTES Sun Nov 25 13:11:35 2001 *** *** 292,298 # # Implement system calls compatible with 4.3BSD and older versions of # FreeBSD. You probably do NOT want to remove this as much current code ! # still relies on the 4.3 emulation. # options COMPAT_43 --- 292,299 # # Implement system calls compatible with 4.3BSD and older versions of # FreeBSD. You probably do NOT want to remove this as much current code ! # still relies on the 4.3 emulation.# XXX - this doesn't belong here. ! # options COMPAT_43 *** *** 420,435 # options COMPILING_LINT - - # XXX - this doesn't belong here. - # Allow ordinary users to take the console - this is useful for X. - options UCONSOLE - - # XXX - this doesn't belong here either - #options USERCONFIG #boot -c editor - #options INTRO_USERCONFIG#imply -c and show intro screen - #options VISUAL_USERCONFIG #visual boot -c editor - # # NETWORKING OPTIONS --- 421,426 *** *** 1150,1158 # EISA, MCA, PCI and pccard are self identifying buses, so no hints # are needed. ! # # Mandatory devices: ! # # The keyboard controller; it controls the keyboard and the PS/2 mouse. deviceatkbdc 1 --- 1141,1149 # EISA, MCA, PCI and pccard are self identifying buses, so no hints # are needed. ! #-- # Mandatory devices: ! #-- # The keyboard controller; it controls the keyboard and the PS/2 mouse. deviceatkbdc 1 *** *** 1189,1194 --- 1180,1189 #for some laptops options PSM_RESETAFTERSUSPEND #reset the device at the resume event + #-- + # Video/Display Related Configuration Options + #-- + # The video card driver. devicevga hint.vga.0.at=isa *** *** 1231,1236 --- 1226,1238 devicestar_saver devicewarp_saver + #-- + # Console Related Configuration Options + #-- + + # Allow ordinary users to take the console - this is useful for X. + options UCONSOLE + # The pcvt console driver (vt220 compatible). devicevt hint.vt.0.at=isa *** *** 1347,1355 deviceacpica options ACPI_DEBUG ! # # Optional devices: ! # # # SCSI host adapters: --- 1349,1357 deviceacpica options ACPI_DEBUG ! #-- # Optional devices: ! #-- # # SCSI host adapters: *** *** 2891,2897 --- 2893,2905 options PANIC_REBOOT_WAIT_TIME=16 # + # MISCELLENEOUS OPTIONS + #options USERCONFIG #boot -c editor + #options INTRO_USERCONFIG#imply -c and show intro screen + #options VISUAL_USERCONFIG #visual boot -c editor + + # # More undocumented options for linting. # Note that documenting these are not considered an affront. *** *** 2955,2958 options VM_KMEM_SIZE options VM_KMEM_SIZE_MAX ! options VM_KMEM_SIZE_SCALE --- 2963,2966 options VM_KMEM_SIZE options VM_KMEM_SIZE_MAX ! options VM_KMEM_SIZE_SCALE = regards, Hiten Pandya [EMAIL PROTECTED] http://geocities.com/hitmaster2k MOTD: I just like _pumping_ the daylights out of a PENGUIN!!! __ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdrecord produces broken CDs on -CURRENT
Kenneth D. Merry [EMAIL PROTECTED] wrote: Are there any areas with good data on the CD? i.e. can you see any pattern to the corruption? If you compare the same CD burned from -current and -stable you might begin to see a patern. I tried a test-burn with a FreeBSD-current from yesterday, on a YAMAHA CRW2100S 1.0H writer (writing a CD-RW), and can't see any failure. It's only a small directory tree, but MD5-comparing the tree on the CD-RW with the original on UFS only reveals the added TRANS.TBL files, no other differences. # cdrecord -version Cdrecord 1.9 (i386-unknown-freebsd5.0) Copyright (C) 1995-2000 Jörg Schilling # ls -l `which cdrecord` -r-xr-xr-x 1 root wheel - 163392 Apr 4 2001 /usr/local/bin/cdrecord* # ldd `which cdrecord` /usr/local/bin/cdrecord: libcam.so.2 = /usr/lib/libcam.so.2 (0x2808a000) libc.so.5 = /usr/lib/libc.so.5 (0x2809a000) libsbuf.so.2 = /usr/lib/libsbuf.so.2 (0x2814e000) (I haven't rebuilt the binary after upgrading -current, for months as you can see.) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kvm_getswapinfo() not backwards compatible?
* Doug White ([EMAIL PROTECTED]) wrote: kd = kvm_open(/dev/null, /dev/null, /dev/null, O_RDONLY, kvm_open); This looks wrong I think you want the first three arguments to be NULL, not /dev/null. /dev/null is not a kernel image. :-) I could've sworn I saw it done like that in the sources for top(1), but after checking again, you are right. It seems to work though on CURRENT. Is it a feature? :-) Cheers, Emiel -- When the government bureau's remedies don't match your problem, you modify the problem, not the remedy. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] - categorizing (XXX Lines) in NOTES
hi all, this patch will put an end to those XXX lines in the NOTES file, which were regarding uncategorized options.. such as USERCONFIG etc. I am also attaching a tar.gz package which has the patch compressed and archived. This is NOT how to do this. File a PR containing the patch, and then post a reference to the PR. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386/32269: [PATCH] - categorizing (XXX Lines) in NOTES
hi all, i am attaching the pointer to the PR of this... thanks.. and i am very sorry for any misbehavment i have caused and i will see to it so that it does not happen again, regards... Hiten Pandya [EMAIL PROTECTED] Note: forwarded message attached. __ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 ---BeginMessage--- Thank you very much for your problem report. It has the internal identification `i386/32269'. The individual assigned to look at your report is: freebsd-bugs. You can access the state of your problem report at any time via this link: http://www.freebsd.org/cgi/query-pr.cgi?pr=32269 Category: i386 Responsible:freebsd-bugs Synopsis: [PATCH] - categorizing (XXX Lines) in NOTES Arrival-Date: Sun Nov 25 06:50:00 PST 2001 ---End Message---
Re: cardbus help
In message [EMAIL PROTECTED] John McCullough writes: : pcib2: routed slot 15 INTA to irq 255 : pccbb: Unable to map IRQ... : panic: resouce_list_release:can't find resource : Debugger(panic) This is a bug in pcibus issue. IRQ 255 should be treated as unallocated, so please route. : Is this also an issue with pci_pci assigning resouces properly? Also : where might I find information on pci-cardbus behavior if I do find : time to tinker with the code? I'd try the pcmcia standard, the pci standard or the mindshare books. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic handle_written_inodeblock: live inodedep
Running -CURRENT from Sunday. Background: I had been building various ports and then deleting the work directories. Some time later, I unmounted that filesystem and ran fsck. The fsck reported about 190 files and 4 directories disconnected and reconnected them. Looking through lost+found, I recognized most of the files as belonging to the ports I had deleted. When I deleted the files, the system panic'd as above (and then panic'd again trying to sync). The disk in question probes as WDMA2. The backtrace from the crash dump is: #0 dumpsys () at /3.0/cvs/src/sys/kern/kern_shutdown.c:492 #1 0xc01a289f in boot (howto=260) at /3.0/cvs/src/sys/kern/kern_shutdown.c:335 #2 0xc01a2cd9 in panic (fmt=0xc0298358 bwrite: buffer is not busy???) at /3.0/cvs/src/sys/kern/kern_shutdown.c:634 #3 0xc01d0bf3 in bwrite (bp=0xc32b5488) at /3.0/cvs/src/sys/kern/vfs_bio.c:670 #4 0xc01d117a in bawrite (bp=0xc32b5488) at /3.0/cvs/src/sys/kern/vfs_bio.c:983 #5 0xc0181e4e in spec_fsync (ap=0xc79b1bac) at /3.0/cvs/src/sys/fs/specfs/spec_vnops.c:409 #6 0xc0181961 in spec_vnoperate (ap=0xc79b1bac) at /3.0/cvs/src/sys/fs/specfs/spec_vnops.c:119 #7 0xc0230ad5 in ffs_sync (mp=0xc0a98a00, waitfor=2, cred=0xc0730c00, td=0xc0343844) at vnode_if.h:441 #8 0xc01dc865 in sync (td=0xc0343844, uap=0x0) at /3.0/cvs/src/sys/kern/vfs_syscalls.c:657 #9 0xc01a2504 in boot (howto=256) at /3.0/cvs/src/sys/kern/kern_shutdown.c:244 #10 0xc01a2cd9 in panic ( fmt=0xc02a0fe0 handle_written_inodeblock: live inodedep) at /3.0/cvs/src/sys/kern/kern_shutdown.c:634 #11 0xc022cfb6 in handle_written_inodeblock (inodedep=0xc0f35500, bp=0xc32ac0a8) at /3.0/cvs/src/sys/ufs/ffs/ffs_softdep.c:3798 #12 0xc022c892 in softdep_disk_write_complete (bp=0xc32ac0a8) at /3.0/cvs/src/sys/ufs/ffs/ffs_softdep.c:3442 #13 0xc01d338d in bufdone (bp=0xc32ac0a8) at /3.0/cvs/src/sys/sys/buf.h:451 #14 0xc01d32c6 in bufdonebio (bp=0xc32ac0a8) at /3.0/cvs/src/sys/kern/vfs_bio.c:2726 #15 0xc012eaf5 in ad_interrupt (request=0xc0deff40) at /3.0/cvs/src/sys/sys/bio.h:107 #16 0xc0124fea in ata_intr (data=0xc0a3cc00) at /3.0/cvs/src/sys/dev/ata/ata-all.c:588 #17 0xc0196c0e in ithread_loop (arg=0xc0a3cb80) at /3.0/cvs/src/sys/kern/kern_intr.c:532 #18 0xc01961a5 in fork_exit (callout=0xc0196afc ithread_loop, arg=0xc0a3cb80, frame=0xc79b1d48) at /3.0/cvs/src/sys/kern/kern_fork.c:786 The fsck after the panic again found lots of unconnected files, but this time they could all be deleted successfully. Has anyone else seen this? Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libfetch kqueue patch
On Thu, 22 Nov 2001 13:02:23 +0200, Maxim Sobolev [EMAIL PROTECTED] said: For what it's worth, it also makes code less portable. On the other hand, it would also make libfetch useful in a larger variety of applications; viz., those which have so many file descriptors open that the one used by libfetch will overflow the default fd_set. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libfetch kqueue patch
On Mon, Nov 26, 2001 at 03:04:56PM -0500, Andrew R. Reiter wrote: Agreed, or people could code with select in a nice manner and dynamically allocate the fd_set arrays. Is there a portable way to allocate dynamically sized fd_sets? It could easily be one of those things that you're not supposed to know how it works inside. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libfetch kqueue patch
As from OpenBSD (in shorter form): fd_set *fds = calloc(howmany(fd+1, NFDBITS), sizeof(fd_mask)); FD_SET(fd, fds); select(fd+1, fds...); As for being portable, the only thing I've seen that is nice and neat is libevent from Niels Provos, but I think some people had issues with the way it handled kqueue support. On Mon, 26 Nov 2001, David Malone wrote: :On Mon, Nov 26, 2001 at 03:04:56PM -0500, Andrew R. Reiter wrote: : Agreed, or people could code with select in a nice manner and dynamically : allocate the fd_set arrays. : :Is there a portable way to allocate dynamically sized fd_sets? It :could easily be one of those things that you're not supposed to :know how it works inside. : : David. : -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Still panic() with userland binary on CURRENT
John Baldwin [EMAIL PROTECTED] writes: On 24-Nov-01 Martin Blapp wrote: - realitexpire, td); + realitexpire, td-td_proc); Fixes the panic 100%. Ouch, something this simple definitely caused a warning, it looks like warnings are being ignored. :( No, the last argument is a void * (it's a cookie that's passed to the function specified by the second-last argument) so it escapes normal compiler diagnostics. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
lomac import broke world
cc -O -pipe -march=pentiumpro -DSETPROCTITLE -DLOGIN_CAP -DVIRTUAL_HOSTING -Wall -DINET6 -I/usr/src/libexec/ftpd -Dmain=ls_main -I/usr/src/libexec/ftpd/../../bin/ls -DUSE_PAM -o ftpd ftpd.o ftpcmd.o logwtmp.o popen.o ls.o cmp.o print.o util.o -lmd -lcrypt -lutil -lopie -lpam ls.o: In function `display': ls.o(.text+0x9b0): undefined reference to `lomac_start' ls.o(.text+0xd02): undefined reference to `get_lattr' ls.o(.text+0xfe2): undefined reference to `lomac_stop' *** Error code 1 -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lomac import broke world
On Tue, Nov 27, 2001 at 08:13:38 +0300, Andrey A. Chernov wrote: cc -O -pipe -march=pentiumpro -DSETPROCTITLE -DLOGIN_CAP -DVIRTUAL_HOSTING -Wall -DINET6 -I/usr/src/libexec/ftpd -Dmain=ls_main -I/usr/src/libexec/ftpd/../../bin/ls -DUSE_PAM -o ftpd ftpd.o ftpcmd.o logwtmp.o popen.o ls.o cmp.o print.o util.o -lmd -lcrypt -lutil -lopie -lpam ls.o: In function `display': ls.o(.text+0x9b0): undefined reference to `lomac_start' ls.o(.text+0xd02): undefined reference to `get_lattr' ls.o(.text+0xfe2): undefined reference to `lomac_stop' *** Error code 1 me too. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
