Re: syscons screensaver
Nice. Perhaps it might be better to make an ioctl/sysctl that took a list
of the types of activity to wake on (e.g. tty output, kernel print, writes
to dev console, mouse movement, and keypress).
Olivier Houchard [[EMAIL PROTECTED]] wrote :
> Hi,
> Here is a small patch to re-add the hw.syscons.saver.timeout using SYSCTL_PROC as
>suggested by jhb.
> It adds a CONS_SAVER_KBD_ONLY ioctl too that does the same that the
>hw.syscons.saver.keybonly.
> --- /sys/dev/syscons/syscons.cFri Apr 5 20:17:49 2002
> +++ /root/syscons.c Fri Apr 5 22:18:59 2002
> @@ -240,6 +240,30 @@
> }
>
> /* probe video adapters, return TRUE if found */
> +static int
> +sysctl_saver_timeout(SYSCTL_HANDLER_ARGS)
> +{
> +long saver_timeout = scrn_blank_time;
> +int error;
> +int s;
> +
> +if (!(error = sysctl_handle_long(oidp, &saver_timeout,
> + sizeof(saver_timeout), req))) {
> + if (saver_timeout < 0 || saver_timeout > MAX_BLANKTIME)
> + error = EINVAL;
> + else {
> + s = spltty();
> + scrn_blank_time = saver_timeout;
> +run_scrn_saver = (scrn_blank_time != 0);
> + splx(s);
> + }
> +}
> +return error;
> +}
> +
> +SYSCTL_PROC(_hw_syscons_saver, OID_AUTO, timeout, CTLTYPE_LONG | CTLFLAG_RW,
> + 0, sizeof(long), sysctl_saver_timeout, "L", "screen saver time");
> +
> static int
> scvidprobe(int unit, int flags, int cons)
> {
> @@ -701,6 +725,9 @@
> splx(s);
> return 0;
>
> +case CONS_SAVER_KBD_ONLY:
> + sc_saver_keyb_only = *(int *)data;
> + return (0);
> case CONS_CURSORTYPE:/* set cursor type (obsolete) */
> s = spltty();
> *(int *)data &= CONS_CURSOR_ATTRS;
> --- /sys/sys/consio.h Sun Mar 17 00:31:14 2002
> +++ /root/consio.hFri Apr 5 22:19:46 2002
> @@ -286,6 +286,7 @@
>
> #define CONS_GETTERM _IOWR('c', 112, term_info_t)
> #define CONS_SETTERM _IOW('c', 113, term_info_t)
> +#define CONS_SAVER_KBD_ONLY _IOW('c', 114, int)
>
> #ifdef PC98
> #define ADJUST_CLOCK _IO('t',100)/* for 98note resume */
--
Jonathan Mini
[EMAIL PROTECTED]
desolation... despair... plastic forks...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Is a debug kernel slower than a non-debug one ?
On Friday, 5 April 2002 at 14:18:38 -0800, Doug White wrote: > On Fri, 5 Apr 2002, Alessandro de Manzano wrote: > >> On Fri, Apr 05, 2002 at 12:00:05PM -0800, Alfred Perlstein wrote: >> >> Wow, thanks for the super-fast answer! :)) >> >> on my production servers' kernel so in the very rare case of crash I'll got a crash dump ( I'ld use also options DDB_UNATTENDED) and could immediately have a backtrace report. ..Am I crazy ? :-)) >>> >>> I don't think you'll notice a difference for most stuff, this is how >> >> does the "-g" option (GCC option I guess) disable the "-O" optimizing >> option ? >> If "-g" simply attach the symbols and similar debug info to the >> executable I guess the kernel should not be slower, but I don't know >> GCC very well... > > Note that the kernel binary with debugging symbols is left in > /sys/compile/MYKERNEL/kernel.debug while the actual kernel is stripped > before installation into /kernel. > > If the debugging kernel was actually loaded it would be gigantic :) No, since the transition to ELF, none of the debugging information gets loaded into core. Try it. > This is all detailed in the Handbook section on kernel debugging, > btw. Hmm, that needs to be fixed, then. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
make world .depend error?
system: 4.2-release, generic kernel src tree: -stable via cvsup, 4.5-release via sysinstall...same problem: snip ===> gnu/usr.bin/binutils/gdbserver ".depend", line 23: Need an operator ".depend", line 282: Need an operator make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /usr/src/gnu/usr.bin/binutils. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 Stop in /usr/src/gnu. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. snip i tried completely deleting the source tree and cvsup'ing from scratch. same problem. any ideas? this is reminiscent of a make rule with spaces instead of tabs. am i missing something? thanks. -Anthony. --- PGP key at: http://www.keyserver.net/ http://www.anthonydotcom.com/gpgkey/key.txt Home: http://www.anthonydotcom.com --- msg33383/pgp0.pgp Description: PGP signature
Re: read a file from a driver
Michael Smith wrote: > > For drivers which must be active in the boot path, it is > > generally necessary to embed the firmware in the driver as > > data. This is what FreeBSD does for the Adaptec SCSI > > drivers. > > > > For drivers that need to be active after boot time, but before > > the mi_startup() is complete, you can load the data in a module > > that contains the data. THis is similar to compiling the data > > into the kernel, but puts it at a minor level of abstraction. > > These two are the same case. See eg. the isp_fw module. I made the distinction because I could make up a situation where they were different, or where you could replace low performance firmware with higher performance firmware. The Adaptec firmware that comes from the POST is good enough to load enough of the OS for the OS driver to take over, and the OS driver replaces the firmware. You could also consider the case where the firmware module was loaded, the firmware shoved down to the card by the driver, and then the module containing it was unloaded (recovering the data space). This is a tiny amount of space for modern systems, but it's a possibility. You could also think about booting with one set of Tigon II firmware, replacing it, and then resetting the driver, which would result in the replacement firmware being shoved down. There's also the possibility of updating the firmware for a driver using a module that's loaded at boot time, but having firmware compiled into it. These are all really border cases, and the distinction is really slight, though... just trying to dot the I's and cross the T's. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is a debug kernel slower than a non-debug one ?
On Fri, 5 Apr 2002, Alessandro de Manzano wrote: > On Fri, Apr 05, 2002 at 12:00:05PM -0800, Alfred Perlstein wrote: > > Wow, thanks for the super-fast answer! :)) > > > > > on my production servers' kernel so in the very rare case of crash I'll > > > got a crash dump ( I'ld use also options DDB_UNATTENDED) and could > > > immediately have a backtrace report. > > > > > > ..Am I crazy ? :-)) > > > > I don't think you'll notice a difference for most stuff, this is how > > does the "-g" option (GCC option I guess) disable the "-O" optimizing > option ? > If "-g" simply attach the symbols and similar debug info to the > executable I guess the kernel should not be slower, but I don't know > GCC very well... Note that the kernel binary with debugging symbols is left in /sys/compile/MYKERNEL/kernel.debug while the actual kernel is stripped before installation into /kernel. If the debugging kernel was actually loaded it would be gigantic :) This is all detailed in the Handbook section on kernel debugging, btw. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
IP fragmentation (was Re: Fatal trap 12: page fault while in kernel mode)
[Moving to -net] If memory serves me right, Andrew Gallatin wrote: > > Alternately, it would be a good idea to have a "ip_maxpacketfrags" > > instead of an "ip_maxfragpackets", to put a hard limit on the > > number of mbufs that can be consumed by the fragment reassembly > > process. > > I think this is the best solution. Just for the heck of it, I started reading through ip_input.c to see how hard this would be to do. Haven't got there yet, I saw something odd: the variables ip_nfragpackets and nipq look *awfully* similar. It looks like they both track the number of reassembly queues, because they're initialized to zero, and incremented and decremented at the same time. Their limits (ip_maxfragpackets and maxnipq respectively) are even initialized on consecutive lines. The only difference I can see is that in ip_input(), if nipq > maxnipq, all of the fragments for some other packet in the current hash bucket get dropped (with the wonderfully descriptive comment "gak"). The check for ip_nfragpackets comes in ip_reass(), where if ip_nfragpackets >= ip_maxfragpackets, then we drop the current fragment. (Is it possible that the second check masks the effects of the first?) I couldn't find any obvious explanation in the CVS log for ip_input.c. Am I missing something, or are these two variables basically doing the same thing? Thanks, Bruce. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64-bit compiling on a 32-bit FreeBSD machine
Thanks for the answer. I thought this was a FreeBSD gcc interaction
question, but it turns out it was just a coding question. Thanks though!
> This is gcc question, you can also try [EMAIL PROTECTED]
>
> main()
> {
> long long ll;
> ll = 1234567890123456LL;
> printf("%lld\n", ll);
> }
>
> % ./a.out
> 1234567890123456
>
> I looked at the assembly dump, it looks OK:
> main:
> pushl %ebp
> movl %esp,%ebp
> subl $8,%esp
> movl $1015724736,-8(%ebp)
> movl $287445,-4(%ebp)
> movl -8(%ebp),%eax
> movl -4(%ebp),%edx
> pushl %edx
> pushl %eax
> pushl $.LC0
> call printf
> addl $12,%esp
>
> Rayson
>
> --- Jason Borkowsky <[EMAIL PROTECTED]> wrote:
> > I have a FreeBSD 4.5-RELEASE box that I recently installed gcc-3.0.4.
> > Is there any support for compiling 64-bit source code on this 32-bit
> > set-up?
>
> > (ie, a sort of emulation mode in that if the compiler sees a "long
> > long
> > int", it creates 2 32-bit registers for it instead of a 64-bit
> > register).
> > Currently gcc-3.0.4 understands "long long int", but if you try to
> > assign
> > it a 64-bit value, it just gets set to the largest 32-bit value (4
> > billion).
> > If gcc cannot handle this, are there any other compilers that can
> > made
> > 64-bit code work on a 32-bit machine?
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-hackers" in the body of the message
>
>
> __
> Do You Yahoo!?
> Yahoo! Tax Center - online filing with TurboTax
> http://taxes.yahoo.com/
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
syscons screensaver
Hi,
Here is a small patch to re-add the hw.syscons.saver.timeout using SYSCTL_PROC as
suggested by jhb.
It adds a CONS_SAVER_KBD_ONLY ioctl too that does the same that the
hw.syscons.saver.keybonly.
--- /sys/dev/syscons/syscons.c Fri Apr 5 20:17:49 2002
+++ /root/syscons.c Fri Apr 5 22:18:59 2002
@@ -240,6 +240,30 @@
}
/* probe video adapters, return TRUE if found */
+static int
+sysctl_saver_timeout(SYSCTL_HANDLER_ARGS)
+{
+long saver_timeout = scrn_blank_time;
+int error;
+int s;
+
+if (!(error = sysctl_handle_long(oidp, &saver_timeout,
+ sizeof(saver_timeout), req))) {
+ if (saver_timeout < 0 || saver_timeout > MAX_BLANKTIME)
+ error = EINVAL;
+ else {
+ s = spltty();
+ scrn_blank_time = saver_timeout;
+run_scrn_saver = (scrn_blank_time != 0);
+ splx(s);
+ }
+}
+return error;
+}
+
+SYSCTL_PROC(_hw_syscons_saver, OID_AUTO, timeout, CTLTYPE_LONG | CTLFLAG_RW,
+ 0, sizeof(long), sysctl_saver_timeout, "L", "screen saver time");
+
static int
scvidprobe(int unit, int flags, int cons)
{
@@ -701,6 +725,9 @@
splx(s);
return 0;
+case CONS_SAVER_KBD_ONLY:
+ sc_saver_keyb_only = *(int *)data;
+ return (0);
case CONS_CURSORTYPE: /* set cursor type (obsolete) */
s = spltty();
*(int *)data &= CONS_CURSOR_ATTRS;
--- /sys/sys/consio.h Sun Mar 17 00:31:14 2002
+++ /root/consio.h Fri Apr 5 22:19:46 2002
@@ -286,6 +286,7 @@
#define CONS_GETTERM _IOWR('c', 112, term_info_t)
#define CONS_SETTERM _IOW('c', 113, term_info_t)
+#define CONS_SAVER_KBD_ONLY_IOW('c', 114, int)
#ifdef PC98
#define ADJUST_CLOCK _IO('t',100)/* for 98note resume */
Re: Is a debug kernel slower than a non-debug one ?
* Alessandro de Manzano <[EMAIL PROTECTED]> [020405 12:08] wrote: > On Fri, Apr 05, 2002 at 12:00:05PM -0800, Alfred Perlstein wrote: > > Wow, thanks for the super-fast answer! :)) > > > > > on my production servers' kernel so in the very rare case of crash I'll > > > got a crash dump ( I'ld use also options DDB_UNATTENDED) and could > > > immediately have a backtrace report. > > > > > > ..Am I crazy ? :-)) > > > > I don't think you'll notice a difference for most stuff, this is how > > does the "-g" option (GCC option I guess) disable the "-O" optimizing > option ? > If "-g" simply attach the symbols and similar debug info to the > executable I guess the kernel should not be slower, but I don't know > GCC very well... no it shouldn't however higher levels of optimization may obfuscate the tracebacks you get because of the way the compiler reorders code. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64-bit compiling on a 32-bit FreeBSD machine
On Fri, Apr 05, 2002 at 02:36:41PM -0500, Jason Borkowsky wrote: > > I have a FreeBSD 4.5-RELEASE box that I recently installed gcc-3.0.4. Is > there any support for compiling 64-bit source code on this 32-bit set-up? > (ie, a sort of emulation mode in that if the compiler sees a "long long > int", it creates 2 32-bit registers for it instead of a 64-bit register). > Currently gcc-3.0.4 understands "long long int", but if you try to assign > it a 64-bit value, it just gets set to the largest 32-bit value (4 billion). > If gcc cannot handle this, are there any other compilers that can made > 64-bit code work on a 32-bit machine? Numeric constants are int by default. Add LL directly after the number to make them long long. E.g.: long long x; x = 332478632478624LL; -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is a debug kernel slower than a non-debug one ?
On Fri, Apr 05, 2002 at 12:00:05PM -0800, Alfred Perlstein wrote: Wow, thanks for the super-fast answer! :)) > > on my production servers' kernel so in the very rare case of crash I'll > > got a crash dump ( I'ld use also options DDB_UNATTENDED) and could > > immediately have a backtrace report. > > > > ..Am I crazy ? :-)) > > I don't think you'll notice a difference for most stuff, this is how does the "-g" option (GCC option I guess) disable the "-O" optimizing option ? If "-g" simply attach the symbols and similar debug info to the executable I guess the kernel should not be slower, but I don't know GCC very well... > I ran my production boxes for quite a while when I was doing admin > work. It helped a _lot_ if a problem happened. Exactly my intentions... Actually till now I had just one crash and for hardware reasons, but better safe than sorry... :-) Thanks again! -- bye! Ale [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64-bit compiling on a 32-bit FreeBSD machine
This is gcc question, you can also try [EMAIL PROTECTED]
main()
{
long long ll;
ll = 1234567890123456LL;
printf("%lld\n", ll);
}
% ./a.out
1234567890123456
I looked at the assembly dump, it looks OK:
main:
pushl %ebp
movl %esp,%ebp
subl $8,%esp
movl $1015724736,-8(%ebp)
movl $287445,-4(%ebp)
movl -8(%ebp),%eax
movl -4(%ebp),%edx
pushl %edx
pushl %eax
pushl $.LC0
call printf
addl $12,%esp
Rayson
--- Jason Borkowsky <[EMAIL PROTECTED]> wrote:
> I have a FreeBSD 4.5-RELEASE box that I recently installed gcc-3.0.4.
> Is there any support for compiling 64-bit source code on this 32-bit
> set-up?
> (ie, a sort of emulation mode in that if the compiler sees a "long
> long
> int", it creates 2 32-bit registers for it instead of a 64-bit
> register).
> Currently gcc-3.0.4 understands "long long int", but if you try to
> assign
> it a 64-bit value, it just gets set to the largest 32-bit value (4
> billion).
> If gcc cannot handle this, are there any other compilers that can
> made
> 64-bit code work on a 32-bit machine?
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
__
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Is a debug kernel slower than a non-debug one ?
* Alessandro de Manzano <[EMAIL PROTECTED]> [020405 11:57] wrote: > Hello! > > Well, the subj says more or less all.. ;-) > > On 4.x-STABLE systems, a kernel compiled with "options DDB" and > "makeoptions DEBUG=-g" is, at execution, slower than one compiled > without that two settings ? > Or is it "only" bigger on disk and, maybe, in memory ? > > I ask you this because I'm evaluating the possibility of enabling DDB > on my production servers' kernel so in the very rare case of crash I'll > got a crash dump ( I'ld use also options DDB_UNATTENDED) and could > immediately have a backtrace report. > > ..Am I crazy ? :-)) I don't think you'll notice a difference for most stuff, this is how I ran my production boxes for quite a while when I was doing admin work. It helped a _lot_ if a problem happened. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Junior Kernel Task: syscons screensavers
* Coleman Kane <[EMAIL PROTECTED]> [020405 11:06] wrote: > Or maybe make it only come out of screensaver if there is a console > message (i.e.: kernel messages, etc...), but stay there during tty > activity. That would be nice also, but I'm more interested in having the screen saver work like a real screensaver. :) -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Is a debug kernel slower than a non-debug one ?
Hello! Well, the subj says more or less all.. ;-) On 4.x-STABLE systems, a kernel compiled with "options DDB" and "makeoptions DEBUG=-g" is, at execution, slower than one compiled without that two settings ? Or is it "only" bigger on disk and, maybe, in memory ? I ask you this because I'm evaluating the possibility of enabling DDB on my production servers' kernel so in the very rare case of crash I'll got a crash dump ( I'ld use also options DDB_UNATTENDED) and could immediately have a backtrace report. ..Am I crazy ? :-)) thanks in advance! -- bye! Ale To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
64-bit compiling on a 32-bit FreeBSD machine
I have a FreeBSD 4.5-RELEASE box that I recently installed gcc-3.0.4. Is there any support for compiling 64-bit source code on this 32-bit set-up? (ie, a sort of emulation mode in that if the compiler sees a "long long int", it creates 2 32-bit registers for it instead of a 64-bit register). Currently gcc-3.0.4 understands "long long int", but if you try to assign it a 64-bit value, it just gets set to the largest 32-bit value (4 billion). If gcc cannot handle this, are there any other compilers that can made 64-bit code work on a 32-bit machine? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Junior Kernel Task: syscons screensavers
Or maybe make it only come out of screensaver if there is a console message (i.e.: kernel messages, etc...), but stay there during tty activity. -- coleman On Fri, Apr 05, 2002 at 12:18:28AM -0800, Alfred Perlstein wrote: > Can someone (for the love of god) make it an option for the > syscons screen savers to turn on when there's no keyboard > activity but there is actual output on the screen? > > Basically, I'd like to be able to run top(1) but still have > my screen blank if i don't touch any keys after 5 minutes. > > thanks, > -- > -Alfred Perlstein [[EMAIL PROTECTED]] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' > Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: read a file from a driver
> For drivers which must be active in the boot path, it is > generally necessary to embed the firmware in the driver as > data. This is what FreeBSD does for the Adaptec SCSI > drivers. > > For drivers that need to be active after boot time, but before > the mi_startup() is complete, you can load the data in a module > that contains the data. THis is similar to compiling the data > into the kernel, but puts it at a minor level of abstraction. These two are the same case. See eg. the isp_fw module. -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fatal trap 12: page fault while in kernel mode
Terry Lambert writes: > Andrew Gallatin wrote: > > The problem is that ip_maxfragpackets is: > > "Maximum number of IPv4 fragment reassembly queue entries" > > > > You (& I, & most people probably) took that number to mean the cap on > > the number of mbufs sitting on reassembly queues. However, its really > > a cap on the number of fragmented packets sitting on reassembly > > queues: > > [ ... ] > > > Since the linux host is sending 16K packets, that means that each > > packet is made up of 11 cluster mbufs (assuming a 1500 byte mtu). > > There can be as many as 10 cluster mbufs on the reassembly queue for > > for each packet. > > > > Lets say we have 2048 cluster mbufs. That makes maxfragpackets 512. > > However, 512 * 10 mbufs = 5120 mbufs. Oops. > > > > I think the limit should probably be something much smaller, like > > maybe nmbclusters / (net.inet.udp.recvspace / 1472). Or the > > implementation & name should be changed to "maxfragmbufs" > > > This suggests that one could fragment as large a UDP packet > as one chooses into "n" fragments, and then supply only "n-1" > elements of the whole packet, as an attack, in order to use > up system resources. Essentially what a linux NFS client is already doing.. ;-( > I think we are better off with my suggestion, where udp packets > above a certain size are intentionally dropped as "not supported". Depending on what the "certain size" is, that might be reasonable. > Alternately, it would be a good idea to have a "ip_maxpacketfrags" > instead of an "ip_maxfragpackets", to put a hard limit on the > number of mbufs that can be consumed by the fragment reassembly > process. I think this is the best solution. > Of course, this also suggests that using TCP instead of UDP for > the NFS would result in the problem "just going away", for the > original poster, which is probably all the opriginal poster > really cares about... Considering that a modern linux NFS client is going to be a common scenario, we should probably be able to interroperate with it, no matter how broken its defaults are. BTW, 16K UDP packets are legal according to the NFS V3 spec, if I remember it correctly. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fatal trap 12: page fault while in kernel mode
Andrew Gallatin wrote: > The problem is that ip_maxfragpackets is: > "Maximum number of IPv4 fragment reassembly queue entries" > > You (& I, & most people probably) took that number to mean the cap on > the number of mbufs sitting on reassembly queues. However, its really > a cap on the number of fragmented packets sitting on reassembly > queues: [ ... ] > Since the linux host is sending 16K packets, that means that each > packet is made up of 11 cluster mbufs (assuming a 1500 byte mtu). > There can be as many as 10 cluster mbufs on the reassembly queue for > for each packet. > > Lets say we have 2048 cluster mbufs. That makes maxfragpackets 512. > However, 512 * 10 mbufs = 5120 mbufs. Oops. > > I think the limit should probably be something much smaller, like > maybe nmbclusters / (net.inet.udp.recvspace / 1472). Or the > implementation & name should be changed to "maxfragmbufs" This suggests that one could fragment as large a UDP packet as one chooses into "n" fragments, and then supply only "n-1" elements of the whole packet, as an attack, in order to use up system resources. I think we are better off with my suggestion, where udp packets above a certain size are intentionally dropped as "not supported". Alternately, it would be a good idea to have a "ip_maxpacketfrags" instead of an "ip_maxfragpackets", to put a hard limit on the number of mbufs that can be consumed by the fragment reassembly process. Of course, this also suggests that using TCP instead of UDP for the NFS would result in the problem "just going away", for the original poster, which is probably all the opriginal poster really cares about... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cdcontrol(1) speed command
Philipp Mergenthaler wrote: > > +.It Cm speed Ar s > > +Set the highest speed that the drive should use. This command is currently > > +only supported on ATAPI drives. > > Maybe we should mention the unit for speed here, i.e. "kB/s" or > "multiples of single speed", but that depends on whether kern/35512 > will be accepted or not. I think it's the same units that the manufacturers use, which is "x", as in "48x". 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cdcontrol(1) speed command
In the last episode (Apr 05), Maxim Konovalov said: > > Hello, > > Here is a patch for cdcontrol(1) to allow set maximum CD drive speed. > It comes from kern/35512. Are there any comments/objections? > > Index: cdcontrol.1 ... > +.It Cm speed Ar s > +Set the highest speed that the drive should use. This command is > +currently only supported on ATAPI drives. Wouldn't this be better off in burncd? cdcontrol is for driving audio CDs, and I don't think you want to play them at anything except 1x :) DESCRIPTION Cdcontrol is a program to control audio features of a CD drive. The device is a name such as cd0 or mcd0. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Perl thing
Ilia Chipitsine wrote: > > Salut, Bernd Walter ! > > On Fri, 5 Apr 2002, Bernd Walter wrote: > > > On Fri, Apr 05, 2002 at 07:56:53PM +0600, Ilia Chipitsine wrote: > > > Dear Sirs, > > > > > > Perl has very useful "split" function, it "split"s a string according > > > arbitrary regular expression. Is there's such a C function ? > > > I'm moving few programs from Perl to C. > > > > strsep(3) > > Especially the exmaple in the manpage should be interesting for you. > > : > > it doesn't help with > > @t = split(/from=<|>/,$a); > > where "from<|>" is regex. strsep knows nothing about regex. As someone wrote a regex thingy for Perl (in C I pressume), then you should be able to use the str-functions in the C-libraries to write your own very specialized function for splitting up the string. It might not be general, it might not be as nice as split, but it should work. Good luck! Best regards, Paul To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Perl thing
On Fri, Apr 05, 2002 at 09:14:46PM +0600, Ilia Chipitsine wrote: > Salut, Bernd Walter ! > > > On Fri, 5 Apr 2002, Bernd Walter wrote: > > > On Fri, Apr 05, 2002 at 07:56:53PM +0600, Ilia Chipitsine wrote: > > > Dear Sirs, > > > > > > Perl has very useful "split" function, it "split"s a string according > > > arbitrary regular expression. Is there's such a C function ? > > > I'm moving few programs from Perl to C. > > > > strsep(3) > > Especially the exmaple in the manpage should be interesting for you. > > : > > it doesn't help with > > @t = split(/from=<|>/,$a); > > where "from<|>" is regex. strsep knows nothing about regex. this does not belong on -hackers. please keep the basic programming questions on -questions, if you insist on discussing them on freebsd mailing lists. thanks, -garrett -- garrett rooneyRemember, any design flaw you're [EMAIL PROTECTED] sufficiently snide about becomes http://electricjellyfish.net/ a feature. -- Dan Sugalski To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Perl thing
Salut, Bernd Walter ! On Fri, 5 Apr 2002, Bernd Walter wrote: > On Fri, Apr 05, 2002 at 07:56:53PM +0600, Ilia Chipitsine wrote: > > Dear Sirs, > > > > Perl has very useful "split" function, it "split"s a string according > > arbitrary regular expression. Is there's such a C function ? > > I'm moving few programs from Perl to C. > > strsep(3) > Especially the exmaple in the manpage should be interesting for you. : it doesn't help with @t = split(/from=<|>/,$a); where "from<|>" is regex. strsep knows nothing about regex. > > -- > B.Walter COSMO-Project http://www.cosmo-project.de > [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] > Regards, (îÁÉÌÕÞÛÉÅ ÐÏÖÅÌÁÎÉÑ) Ilia Chipitsine (éÌØÑ ûÉÐÉÃÉÎ) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Perl thing
On Fri, Apr 05, 2002 at 07:56:53PM +0600, Ilia Chipitsine wrote: > Dear Sirs, > > Perl has very useful "split" function, it "split"s a string according > arbitrary regular expression. Is there's such a C function ? > I'm moving few programs from Perl to C. strsep(3) Especially the exmaple in the manpage should be interesting for you. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cdcontrol(1) speed command
It seems Philipp Mergenthaler wrote: > > @@ -24,6 +24,7 @@ > > #endif /* not lint */ > > > #include > > +#include > > Jörg Wunsch commented that adding "include " would be > wrong and that this ioctl should be moved to sys/cdio.h instead. > (I guess then it should be renamed to CDIOCREADSPEED, too.) > This would then have to be changed in src/sys/dev/ata/atapi-cd.c, too. Hmm, then the functionality should be added to the SCSI CD driver first, until then its only for ATAPI CDROM's, and should stay where it is, to not break binary compatibility.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fatal trap 12: page fault while in kernel mode
Bruce A. Mah writes:
>
> I was discussing this with some of my cow-orkers, as we've had a similar
> situation (cluster mbufs getting temporarily depleted on a
> 4.5-RELEASE-p2 NFS server with Linux and FreeBSD clients, but no kernel
> panics). Shouldn't the net.inet.ip.maxfragpackets sysctl variable
> (introduced in 4.4-RELEASE) limit the number of fragments on the
> reassembly queue(s)? This value looks to be about 1/4 the number of
> cluster mbufs, by default.
That's a good point. When I was bitten by this, I didn't have time to
mess with things & I cranked down the read/write size on the linux
clients.
The problem is that ip_maxfragpackets is:
"Maximum number of IPv4 fragment reassembly queue entries"
You (& I, & most people probably) took that number to mean the cap on
the number of mbufs sitting on reassembly queues. However, its really
a cap on the number of fragmented packets sitting on reassembly
queues:
/*
* If first fragment to arrive, create a reassembly queue.
*/
if (fp == 0) {
/*
* Enforce upper bound on number of fragmented packets
* for which we attempt reassembly;
* If maxfrag is 0, never accept fragments.
* If maxfrag is -1, accept all fragments without limitation.
<...>
Since the linux host is sending 16K packets, that means that each
packet is made up of 11 cluster mbufs (assuming a 1500 byte mtu).
There can be as many as 10 cluster mbufs on the reassembly queue for
for each packet.
Lets say we have 2048 cluster mbufs. That makes maxfragpackets 512.
However, 512 * 10 mbufs = 5120 mbufs. Oops.
I think the limit should probably be something much smaller, like
maybe nmbclusters / (net.inet.udp.recvspace / 1472). Or the
implementation & name should be changed to "maxfragmbufs"
Drew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Perl thing
Dear Sirs, Perl has very useful "split" function, it "split"s a string according arbitrary regular expression. Is there's such a C function ? I'm moving few programs from Perl to C. Regards, (îÁÉÌÕÞÛÉÅ ÐÏÖÅÌÁÎÉÑ) Ilia Chipitsine (éÌØÑ ûÉÐÉÃÉÎ) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cdcontrol(1) speed command
In article <[EMAIL PROTECTED]> you wrote: > Here is a patch for cdcontrol(1) to allow set maximum CD drive speed. > It comes from kern/35512. Are there any comments/objections? > Index: cdcontrol.1 > === > RCS file: /home/ncvs/src/usr.sbin/cdcontrol/cdcontrol.1,v > retrieving revision 1.32 > diff -u -r1.32 cdcontrol.1 > --- cdcontrol.1 15 Jul 2001 08:01:46 - 1.32 > +++ cdcontrol.1 27 Mar 2002 10:57:34 - > @@ -154,6 +154,9 @@ > Set minute-second-frame ioctl mode (default). > .It Cm set Ar lba > Set LBA ioctl mode. > +.It Cm speed Ar s > +Set the highest speed that the drive should use. This command is currently > +only supported on ATAPI drives. Maybe we should mention the unit for speed here, i.e. "kB/s" or "multiples of single speed", but that depends on whether kern/35512 will be accepted or not. [...] > +++ cdcontrol.c 27 Mar 2002 10:58:12 - > @@ -24,6 +24,7 @@ > #endif /* not lint */ > #include > +#include Jörg Wunsch commented that adding "include " would be wrong and that this ioctl should be moved to sys/cdio.h instead. (I guess then it should be renamed to CDIOCREADSPEED, too.) This would then have to be changed in src/sys/dev/ata/atapi-cd.c, too. Bye, Philipp -- http://www.uni-karlsruhe.de/~un1i/ (,.) \\\@@ ) \= ) cc_|\_,^ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
cdcontrol(1) speed command
Hello,
Here is a patch for cdcontrol(1) to allow set maximum CD drive speed.
It comes from kern/35512. Are there any comments/objections?
Index: cdcontrol.1
===
RCS file: /home/ncvs/src/usr.sbin/cdcontrol/cdcontrol.1,v
retrieving revision 1.32
diff -u -r1.32 cdcontrol.1
--- cdcontrol.1 15 Jul 2001 08:01:46 - 1.32
+++ cdcontrol.1 27 Mar 2002 10:57:34 -
@@ -154,6 +154,9 @@
Set minute-second-frame ioctl mode (default).
.It Cm set Ar lba
Set LBA ioctl mode.
+.It Cm speed Ar s
+Set the highest speed that the drive should use. This command is currently
+only supported on ATAPI drives.
.It Cm quit
Quit the program.
.El
Index: cdcontrol.c
===
RCS file: /home/ncvs/src/usr.sbin/cdcontrol/cdcontrol.c,v
retrieving revision 1.37
diff -u -r1.37 cdcontrol.c
--- cdcontrol.c 18 Feb 2002 20:35:27 - 1.37
+++ cdcontrol.c 27 Mar 2002 10:58:12 -
@@ -24,6 +24,7 @@
#endif /* not lint */
#include
+#include
#include
#include
#include
@@ -32,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -73,6 +75,7 @@
#define CMD_CDID 15
#define CMD_NEXT 16
#define CMD_PREVIOUS 17
+#define CMD_SPEED 18
#define STATUS_AUDIO 0x1
#define STATUS_MEDIA 0x2
#define STATUS_VOLUME 0x4
@@ -105,6 +108,7 @@
{ CMD_VOLUME, "volume", 1,
" | left | right | mute | mono | stereo" },
{ CMD_CDID,"cdid", 2, "" },
+{ CMD_SPEED, "speed",2, "speed" },
{ 0, NULL, 0, NULL }
};
@@ -277,7 +281,9 @@
int run (int cmd, char *arg)
{
+ long speed;
int l, r, rc;
+ char *ep;
switch (cmd) {
@@ -424,6 +430,19 @@
}
return setvol (l, r);
+
+ case CMD_SPEED:
+ if (fd < 0 && ! open_cd ())
+ return (0);
+
+ errno = 0;
+ speed = strtol(arg, &ep, 0);
+ if (*ep || ep == arg || speed < 0 || speed > INT_MAX ||
+ errno != 0) {
+ warnx("invalid command arguments %s", arg);
+ return (0);
+ }
+ return ioctl(fd, CDRIOCREADSPEED, &speed);
default:
case CMD_HELP:
%%%
--
Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer
phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
