Re: 1GB system working with 64MB
Add this: append="mem=1024M" to your lilo boot profiles. ... 2.4 correctly detects memory size more often than 2.2.16 ... - Original Message - From: "Edouard Soriano" <[EMAIL PROTECTED]> Subject: 1GB system working with 64MB > Hello Folks, > Environment: linux 2.2.16smp > RedHat 7.0 > > My problem are the 63892K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 1GB system working with 64MB
Add this: append=mem=1024M to your lilo boot profiles. ... 2.4 correctly detects memory size more often than 2.2.16 ... - Original Message - From: Edouard Soriano [EMAIL PROTECTED] Subject: 1GB system working with 64MB Hello Folks, Environment: linux 2.2.16smp RedHat 7.0 My problem are the 63892K - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
I re-subscribed for this? Blarg. When did the LKML turn into slashdot? On 01 Jul 2001 17:33:38 -0700, Ted Unangst wrote: > On Sun, 1 Jul 2001, Ben Ford wrote: > > > Name a single tech company anywhere in the world that doesn't have to > > deal with microsoftisms. > > http://www.wasabisystems.com/ > > > Well, when you realize that Bill Gates (not MS, just Bill Gates > > personally) has enough money to give every person in the world $10 out > > of his pocket, then you see this argument in a different light. > > that's called capitalism. > > ted > > -- > "First, it was not a strip bar, it was an erotic club. And second, > what can I say? I'm a night owl." > - M. Barry, Mayor of Washington, DC > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Michael Rothwell [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Soft updates for 2.5?
While on the topic of reslilent, high-performance filesystems, what ever became of "Tux", Daniel Philip's mythical WAFL-type filesystem? On 01 Jul 2001 23:33:52 -0300, Rik van Riel wrote: > On Sat, 30 Jun 2001, Alex Khripin wrote: > > > There was a discussion in October, 2000, about the Granger and > > McKusick paper on soft updates for the BSD FFS. Reading the thread, > > nothing conclusive seemed to come out of it. > > What you want is ext3. > > It is a journaling version of ext2, which basically > means you get all the advantages of soft updates and > a bit more (due to the atomicity that journaled > transactions can give you). > > It should be superior to softupdates in both the > consistency area and the performance area (due to > the fact that stuff is in the journal, you have > more freedom to reorder the writes to the "main" > part of the filesystem). > > regards, > > Rik > -- > Virtual memory is like a game you can't win; > However, without VM there's truly nothing to lose... > > http://www.surriel.com/ http://distro.conectiva.com/ > > Send all your spam to [EMAIL PROTECTED] (spam digging piggy) > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Michael Rothwell [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Soft updates for 2.5?
While on the topic of reslilent, high-performance filesystems, what ever became of Tux, Daniel Philip's mythical WAFL-type filesystem? On 01 Jul 2001 23:33:52 -0300, Rik van Riel wrote: On Sat, 30 Jun 2001, Alex Khripin wrote: There was a discussion in October, 2000, about the Granger and McKusick paper on soft updates for the BSD FFS. Reading the thread, nothing conclusive seemed to come out of it. What you want is ext3. It is a journaling version of ext2, which basically means you get all the advantages of soft updates and a bit more (due to the atomicity that journaled transactions can give you). It should be superior to softupdates in both the consistency area and the performance area (due to the fact that stuff is in the journal, you have more freedom to reorder the writes to the main part of the filesystem). regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Michael Rothwell [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
I re-subscribed for this? Blarg. When did the LKML turn into slashdot? On 01 Jul 2001 17:33:38 -0700, Ted Unangst wrote: On Sun, 1 Jul 2001, Ben Ford wrote: Name a single tech company anywhere in the world that doesn't have to deal with microsoftisms. http://www.wasabisystems.com/ Well, when you realize that Bill Gates (not MS, just Bill Gates personally) has enough money to give every person in the world $10 out of his pocket, then you see this argument in a different light. that's called capitalism. ted -- First, it was not a strip bar, it was an erotic club. And second, what can I say? I'm a night owl. - M. Barry, Mayor of Washington, DC - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Michael Rothwell [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
On 20 Jun 2001 10:14:48 +0100, Alan Cox wrote: > It does. ... not > They are always readable. That's not very useful. Not in the sense of supporting aync, non-blocking i/o to disk files without using threads. -- Michael Rothwell [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
On 20 Jun 2001 10:14:48 +0100, Alan Cox wrote: It does. ... not They are always readable. That's not very useful. Not in the sense of supporting aync, non-blocking i/o to disk files without using threads. -- Michael Rothwell [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
On 19 Jun 2001 20:01:56 +0100, Alan Cox wrote: > Linux inherits several unix properties which are not friendly to good state > based programming - lack of good AIO for one. Oh, how I would love for select() and poll() to work on files... or for any other working AIO mothods to be present. What would get broken if things were changed to let select() work for filesystem fds? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
On 19 Jun 2001 20:01:56 +0100, Alan Cox wrote: Linux inherits several unix properties which are not friendly to good state based programming - lack of good AIO for one. Oh, how I would love for select() and poll() to work on files... or for any other working AIO mothods to be present. What would get broken if things were changed to let select() work for filesystem fds? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: threading question
Try this:
http://lecker.essen.de/~froese/coro/
-M
On 16 Jun 2001 14:33:50 -0400, Russell Leighton wrote:
>
> Is there a user-space implemenation (library?) for coroutines that would work from C?
>
>
> Alan Cox wrote:
>
> > > Can you provide any info and/or examples of co-routines? I'm curious to
> > > see a good example of co-routines' "betterness."
> >
> > With co-routines you don't need
> >
> > 8K of kernel stack
> > Scheduler overhead
> > Fancy locking
> >
> > You don't get the automatic thread switching stuff though.
> >
> > So you might get code that reads like this (note that aio_ stuff works rather
> > well combined with co-routines as it fixes a lack of asynchronicity in the
> > unix disk I/O world)
> >
> > select()
> >
> > if(FD_ISSET(copier_fd))
> > run_coroutine(_state);
> >
> > ...
> >
> > and the copier might be something like
> >
> > while(1)
> > {
> > // Yes 1 at a time is dumb but this is an example..
> > // Yes Im ignoring EOF for this
> > if(read(copier_fd, buf[bufptr], 1)==-1)
> > {
> > if(errno==-EWOULDBLOCK)
> > {
> > coroutine_return();
> > continue;
> > }
> > }
> > if(bufptr==255 || buf[bufptr]=='\n')
> > {
> > run_coroutine(run_command, buf);
> > bufptr=0;
> > }
> > else
> > bufptr++;
> > }
> >
> > it lets you express a state machine as a set of multiple such small state
> > machines instead. run_coroutine() will continue a routine where it last
> > coroutine_return()'d from. Thus in the above case we are expressing read
> > bytes until you see a new line cleanly - not mangled in with keeping state
> > in global structures but by using natural C local variables and code flow
> >
> > Alan
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
> --
> -------
> Russell Leighton[EMAIL PROTECTED]
> ---
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Michael Rothwell
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ps2 keyboard filter hook
On 15 Jun 2001 16:03:32 -0400, [EMAIL PROTECTED] wrote: > > IBM Retail Store Solutions dept has certain PS/2 keyboards which extend the > standard PS/2 specification in order to support addition hardware built into the > keyboard (such as a Magnetic Strip Reader, Keylock, Tone generator, extra keys, > -Dan I'm facing a similar problem with the "Qoder" barcode scanner. I have to have a keyboard hook. The "right" way seem to be to use the input api. Unfortunately, this means that current kernels can't use the driver w/o a patch (the input api patch). The ugly way is to patch the keyboard driver. I'm doing both. However, I wrote a REALLY SIMPLE hook tht supported exactly my needs, since it's in the category of "ugly hack waiting for input api." Maybe I'll write a version for your hook. I wonder when the input api stuff for ps/2 devices will be a part of the mainstream kernel... -- Michael Rothwell [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ps2 keyboard filter hook
On 15 Jun 2001 16:03:32 -0400, [EMAIL PROTECTED] wrote: IBM Retail Store Solutions dept has certain PS/2 keyboards which extend the standard PS/2 specification in order to support addition hardware built into the keyboard (such as a Magnetic Strip Reader, Keylock, Tone generator, extra keys, -Dan I'm facing a similar problem with the Qoder barcode scanner. I have to have a keyboard hook. The right way seem to be to use the input api. Unfortunately, this means that current kernels can't use the driver w/o a patch (the input api patch). The ugly way is to patch the keyboard driver. I'm doing both. However, I wrote a REALLY SIMPLE hook tht supported exactly my needs, since it's in the category of ugly hack waiting for input api. Maybe I'll write a version for your hook. I wonder when the input api stuff for ps/2 devices will be a part of the mainstream kernel... -- Michael Rothwell [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: threading question
Try this:
http://lecker.essen.de/~froese/coro/
-M
On 16 Jun 2001 14:33:50 -0400, Russell Leighton wrote:
Is there a user-space implemenation (library?) for coroutines that would work from C?
Alan Cox wrote:
Can you provide any info and/or examples of co-routines? I'm curious to
see a good example of co-routines' betterness.
With co-routines you don't need
8K of kernel stack
Scheduler overhead
Fancy locking
You don't get the automatic thread switching stuff though.
So you might get code that reads like this (note that aio_ stuff works rather
well combined with co-routines as it fixes a lack of asynchronicity in the
unix disk I/O world)
select()
if(FD_ISSET(copier_fd))
run_coroutine(copier_state);
...
and the copier might be something like
while(1)
{
// Yes 1 at a time is dumb but this is an example..
// Yes Im ignoring EOF for this
if(read(copier_fd, buf[bufptr], 1)==-1)
{
if(errno==-EWOULDBLOCK)
{
coroutine_return();
continue;
}
}
if(bufptr==255 || buf[bufptr]=='\n')
{
run_coroutine(run_command, buf);
bufptr=0;
}
else
bufptr++;
}
it lets you express a state machine as a set of multiple such small state
machines instead. run_coroutine() will continue a routine where it last
coroutine_return()'d from. Thus in the above case we are expressing read
bytes until you see a new line cleanly - not mangled in with keeping state
in global structures but by using natural C local variables and code flow
Alan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
---
Russell Leighton[EMAIL PROTECTED]
---
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Michael Rothwell
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: keyboard hook?
Thanks, I'm loking through your driver now. Does the input api already/currently support ps2 keyboards? -M On Sat, Jun 02, 2001 at 08:40:04PM -0700, James Simmons wrote: > > Hi! > >Your best bet for a kernel driver is to use the linux input api like > the usb keyboard do. The drivers are pretty simple to write and since all > the keyboard drivers will be port over to this api it will save a lot of > work done the road. If you need help let me know. I will be glad to help. > It sounds alot alike the p2 to serial driver just placed in our CVS. You > can access our CVS by doing > > cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/linuxconsole login > > cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/linuxconsole >co ruby > > The driver is in ruby/linux/drivers/input as ps2serkbd.c. > > > I'm beginning the process of writing a driver for the "Qoder" > > keyboard-fob barcode scanner made by InterMec. It communicates with the > > host computer using the PS/2 port by way of a "dock" that sits in > > between the keyboard and the computer. > > > One of them is "turn > > numlock light on," which I can do with an ioctl from userspace (as root, > > anyway), but also caps lock, num lock and carriage-return scancodes. > > EV_LED > > > The CueCat driver written by Pierre Coupard also modifies the keyboard > > driver. It would be nice if it was possible to load modules that hook > > into keyboard processing without requiring a kernel patch. And perhaps > > there is, but I haven't run across it yet. > > input api :-) > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: keyboard hook?
Input API looks nice. For now, I'll write a patch against pc_keyb.c to add a hook for my qoder stuff, and a loadable module for the meat of the driver. Then I'll port up to the input API. The Qoder is strictly ps/2 keyboard, as far as its interface goes, so I cannot use the input API for now. I have a Sparc here; does it have drivers you wish to have ported? On Sun, Jun 03, 2001 at 09:02:18PM -0700, James Simmons wrote: > > > Thanks, I'm loking through your driver now. Does the input api > > already/currently support ps2 keyboards? > > With the current tree no. The work around is to make input api keyboards > behave as PS/2 keyboards. In 2.5.X ps2 keyboards will be input api based. > As you can see we already have PS/2 input api driver (i8042.c and atkbd.c). > I have been using it for several months now. It is just a matter of making > sure it works on other platforms besides intel. > > P.S >I also need to port other keyboard drivers on other platforms over to > the input api and test these drivers. If anyone would like to help out > contact me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: keyboard hook?
Input API looks nice. For now, I'll write a patch against pc_keyb.c to add a hook for my qoder stuff, and a loadable module for the meat of the driver. Then I'll port up to the input API. The Qoder is strictly ps/2 keyboard, as far as its interface goes, so I cannot use the input API for now. I have a Sparc here; does it have drivers you wish to have ported? On Sun, Jun 03, 2001 at 09:02:18PM -0700, James Simmons wrote: Thanks, I'm loking through your driver now. Does the input api already/currently support ps2 keyboards? With the current tree no. The work around is to make input api keyboards behave as PS/2 keyboards. In 2.5.X ps2 keyboards will be input api based. As you can see we already have PS/2 input api driver (i8042.c and atkbd.c). I have been using it for several months now. It is just a matter of making sure it works on other platforms besides intel. P.S I also need to port other keyboard drivers on other platforms over to the input api and test these drivers. If anyone would like to help out contact me. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: keyboard hook?
Thanks, I'm loking through your driver now. Does the input api already/currently support ps2 keyboards? -M On Sat, Jun 02, 2001 at 08:40:04PM -0700, James Simmons wrote: Hi! Your best bet for a kernel driver is to use the linux input api like the usb keyboard do. The drivers are pretty simple to write and since all the keyboard drivers will be port over to this api it will save a lot of work done the road. If you need help let me know. I will be glad to help. It sounds alot alike the p2 to serial driver just placed in our CVS. You can access our CVS by doing cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/linuxconsole login cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/linuxconsole co ruby The driver is in ruby/linux/drivers/input as ps2serkbd.c. I'm beginning the process of writing a driver for the Qoder keyboard-fob barcode scanner made by InterMec. It communicates with the host computer using the PS/2 port by way of a dock that sits in between the keyboard and the computer. One of them is turn numlock light on, which I can do with an ioctl from userspace (as root, anyway), but also caps lock, num lock and carriage-return scancodes. EV_LED The CueCat driver written by Pierre Coupard also modifies the keyboard driver. It would be nice if it was possible to load modules that hook into keyboard processing without requiring a kernel patch. And perhaps there is, but I haven't run across it yet. input api :-) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
keyboard hook?
I'm beginning the process of writing a driver for the "Qoder"
keyboard-fob barcode scanner made by InterMec. It communicates with the
host computer using the PS/2 port by way of a "dock" that sits in
between the keyboard and the computer.
The dock does handshaking with the host computer, which means that it
listens for specific signals sent from the host. One of them is "turn
numlock light on," which I can do with an ioctl from userspace (as root,
anyway), but also caps lock, num lock and carriage-return scancodes.
I will have to modify the keyboard driver to capture and process data
from the barcode scanner cleanly, and without requiring root access for
the client programs.
The CueCat driver written by Pierre Coupard also modifies the keyboard
driver. It would be nice if it was possible to load modules that hook
into keyboard processing without requiring a kernel patch. And perhaps
there is, but I haven't run across it yet.
I just need to scan the keystroke stream for an attention signal
(shift,shift,shift,alt,ctrl) and then respond ("turn on numlock light")
to initiate the data transfer; then, of course, capture and format that
data and make it available via /proc, or something.
Does anyone have any suggestions before I go ugly-up the keyboard
driver?
Thanks,
--
Michael Rothwell
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
keyboard hook?
I'm beginning the process of writing a driver for the Qoder keyboard-fob barcode scanner made by InterMec. It communicates with the host computer using the PS/2 port by way of a dock that sits in between the keyboard and the computer. The dock does handshaking with the host computer, which means that it listens for specific signals sent from the host. One of them is turn numlock light on, which I can do with an ioctl from userspace (as root, anyway), but also caps lock, num lock and carriage-return scancodes. I will have to modify the keyboard driver to capture and process data from the barcode scanner cleanly, and without requiring root access for the client programs. The CueCat driver written by Pierre Coupard also modifies the keyboard driver. It would be nice if it was possible to load modules that hook into keyboard processing without requiring a kernel patch. And perhaps there is, but I haven't run across it yet. I just need to scan the keystroke stream for an attention signal (shift,shift,shift,alt,ctrl) and then respond (turn on numlock light) to initiate the data transfer; then, of course, capture and format that data and make it available via /proc, or something. Does anyone have any suggestions before I go ugly-up the keyboard driver? Thanks, -- Michael Rothwell [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OOPS - 2.2.19, USB, Scanner
Just your friendly neighborhood oops report. Unfortunately, the kernel didn't log very much: May 14 18:00:49 gateway kernel: scanner.c: read_scanner(0): funky result:-32. Please notify the maintainer. May 14 18:01:13 gateway PAM_pwdb[10338]: (login) session opened for user rothwell by (uid=0) May 14 18:01:21 gateway PAM_pwdb[10364]: (su) session opened for user root by rothwell(uid=500) May 14 18:01:46 gateway kernel: usb.c: USB disconnect on device 2 May 14 18:02:00 gateway kernel: usb.c: USB new device connect, assigned device number 2 May 14 18:02:09 gateway kernel: usb.c: deregistering driver ibmcam May 14 18:02:09 gateway kernel: usb.c: USB disconnect on device 1 May 14 18:02:09 gateway kernel: usb.c: USB disconnect on device 2 May 14 18:02:09 gateway kernel: usb.c: USB bus 1 deregistered May 14 18:02:09 gateway kernel: kmem_destroy: Can't free all objects c7fffb00 May 14 18:02:09 gateway kernel: uhci: not all urb_priv's were freed May 14 18:02:09 gateway kernel: kmem_destroy: Can't free all objects c7fffaa0 May 14 18:02:09 gateway kernel: uhci: not all QH's were freed May 14 18:02:09 gateway kernel: kmem_destroy: Can't free all objects c7fffa40 May 14 18:02:09 gateway kernel: uhci: not all TD's were freed May 14 18:02:30 gateway kernel: usb_control/bulk_msg: timeout May 14 18:02:30 gateway kernel: Unable to handle kernel paging request at virtual address c886f350 May 14 18:02:30 gateway kernel: current->tss.cr3 = 00101000, %%cr3 = 00101000 May 14 18:02:30 gateway kernel: *pde = 07ffa063 May 14 18:02:30 gateway kernel: *pte = May 14 18:02:30 gateway kernel: Oops: May 14 18:02:30 gateway kernel: CPU:0 ... the scanner appeared to hang while using SANE. I attempted to rmmod the usb modules, including scanner.o, and uhci.o. Oops. -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OOPS - 2.2.19, USB, Scanner
Just your friendly neighborhood oops report. Unfortunately, the kernel didn't log very much: May 14 18:00:49 gateway kernel: scanner.c: read_scanner(0): funky result:-32. Please notify the maintainer. May 14 18:01:13 gateway PAM_pwdb[10338]: (login) session opened for user rothwell by (uid=0) May 14 18:01:21 gateway PAM_pwdb[10364]: (su) session opened for user root by rothwell(uid=500) May 14 18:01:46 gateway kernel: usb.c: USB disconnect on device 2 May 14 18:02:00 gateway kernel: usb.c: USB new device connect, assigned device number 2 May 14 18:02:09 gateway kernel: usb.c: deregistering driver ibmcam May 14 18:02:09 gateway kernel: usb.c: USB disconnect on device 1 May 14 18:02:09 gateway kernel: usb.c: USB disconnect on device 2 May 14 18:02:09 gateway kernel: usb.c: USB bus 1 deregistered May 14 18:02:09 gateway kernel: kmem_destroy: Can't free all objects c7fffb00 May 14 18:02:09 gateway kernel: uhci: not all urb_priv's were freed May 14 18:02:09 gateway kernel: kmem_destroy: Can't free all objects c7fffaa0 May 14 18:02:09 gateway kernel: uhci: not all QH's were freed May 14 18:02:09 gateway kernel: kmem_destroy: Can't free all objects c7fffa40 May 14 18:02:09 gateway kernel: uhci: not all TD's were freed May 14 18:02:30 gateway kernel: usb_control/bulk_msg: timeout May 14 18:02:30 gateway kernel: Unable to handle kernel paging request at virtual address c886f350 May 14 18:02:30 gateway kernel: current-tss.cr3 = 00101000, %%cr3 = 00101000 May 14 18:02:30 gateway kernel: *pde = 07ffa063 May 14 18:02:30 gateway kernel: *pte = May 14 18:02:30 gateway kernel: Oops: May 14 18:02:30 gateway kernel: CPU:0 ... the scanner appeared to hang while using SANE. I attempted to rmmod the usb modules, including scanner.o, and uhci.o. Oops. -M - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux syscall speed -- was X15 rootin-tootin webserver
There seems to be a contingent of people on the LKML who think that it is appropriate to flame people off-list, in order to bask in their own superiority, or prove that they are smarter by pointing out that someone is an idiot, etc. I would figure that most intelligent people would simply ignore posts they don't like, rather than investing time and bandwidth compounding the perceived offense. But I'm apparently too optimistic on that point; any group of people the size of the LKML will always contain some juviniles. A great many of us have suffered their attention. -M On 04 May 2001 11:21:48 +1000, Rusty Russell wrote: > In message <988856961.6355.1.camel@gromit> you write: > > According to tests performed at IBM: > > > > http://www-106.ibm.com/developerworks/linux/library/l-rt1/ > > > > Linux's sycalls are a little more than twice as fast as those of Windows > > This post was pretty much a waste of space, wasn't it? > > > 2000. 0.75usec vs 2.0msec. > > That would be 2,666 times. > > Rusty. > -- > Premature optmztion is rt of all evl. --DK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux syscall speed -- was X15 rootin-tootin webserver
There seems to be a contingent of people on the LKML who think that it is appropriate to flame people off-list, in order to bask in their own superiority, or prove that they are smarter by pointing out that someone is an idiot, etc. I would figure that most intelligent people would simply ignore posts they don't like, rather than investing time and bandwidth compounding the perceived offense. But I'm apparently too optimistic on that point; any group of people the size of the LKML will always contain some juviniles. A great many of us have suffered their attention. -M On 04 May 2001 11:21:48 +1000, Rusty Russell wrote: In message 988856961.6355.1.camel@gromit you write: According to tests performed at IBM: http://www-106.ibm.com/developerworks/linux/library/l-rt1/ Linux's sycalls are a little more than twice as fast as those of Windows This post was pretty much a waste of space, wasn't it? 2000. 0.75usec vs 2.0msec. That would be 2,666 times. Rusty. -- Premature optmztion is rt of all evl. --DK - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux syscall speed -- was X15 rootin-tootin webserver
According to tests performed at IBM: http://www-106.ibm.com/developerworks/linux/library/l-rt1/ Linux's sycalls are a little more than twice as fast as those of Windows 2000. 0.75usec vs 2.0msec. Not too shabby. And this "magic page" idea means it may get faster. -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux syscall speed -- was X15 rootin-tootin webserver
According to tests performed at IBM: http://www-106.ibm.com/developerworks/linux/library/l-rt1/ Linux's sycalls are a little more than twice as fast as those of Windows 2000. 0.75usec vs 2.0msec. Not too shabby. And this magic page idea means it may get faster. -M - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Common GUI Config for All Users
To whom are you referring? -M On 30 Apr 2001 10:11:04 -0600, [EMAIL PROTECTED] wrote: > Thank you for the =constructive= answer Mohammad. I have thusfar only received >criticism for my question, with no further information, which I think is destructive >to the spirit of the list, and to the culture. > > Those who act like pricks toward newcomers should be treated as such, and I will >remember them. > -- > C. > > The best way out is always through. > - Robert Frost A Servant to Servants, 1914 > > > "Mohammad A. Haque" wrote: > > > On Mon, 30 Apr 2001 [EMAIL PROTECTED] wrote: > > > > > Looking for the best way to give all users a common desktop, which comes from >one source (for easy administration). > > > > This list doesn't deal with what you are asking. Try > > http://www.linux.com and see if anything/anyone there can help you. > > > > -- > > > > = > > Mohammad A. Haque http://www.haque.net/ > >[EMAIL PROTECTED] > > > > "Alcohol and calculus don't mix. Project Lead > >Don't drink and derive." --Unknown http://wm.themes.org/ > >[EMAIL PROTECTED] > > = > > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Common GUI Config for All Users
To whom are you referring? -M On 30 Apr 2001 10:11:04 -0600, [EMAIL PROTECTED] wrote: Thank you for the =constructive= answer Mohammad. I have thusfar only received criticism for my question, with no further information, which I think is destructive to the spirit of the list, and to the culture. Those who act like pricks toward newcomers should be treated as such, and I will remember them. -- C. The best way out is always through. - Robert Frost A Servant to Servants, 1914 Mohammad A. Haque wrote: On Mon, 30 Apr 2001 [EMAIL PROTECTED] wrote: Looking for the best way to give all users a common desktop, which comes from one source (for easy administration). This list doesn't deal with what you are asking. Try http://www.linux.com and see if anything/anyone there can help you. -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] Alcohol and calculus don't mix. Project Lead Don't drink and derive. --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #define HZ 1024 -- negative effects?
Great. I'm running 4.02. How do I enable "silken mouse"? Thanks, -Michael On 29 Apr 2001 14:44:11 -0700, Jim Gettys wrote: > The biggest single issue in GUI responsiveness on Linux has been caused > by XFree86's implementation of mouse tracking in user space. > > On typical UNIX systems, the mouse was often controlled in the kernel > driver. Until recently (XFree86 4.0 days), the XFree86 server's reads > of mouse/keyboard events were not signal driven, so that if the X server > was loaded, the cursor stopped moving. > > On most (but not all) current XFree86 implementations, this is now > signal drive, and further the internal X schedular has been reworked to > make it difficult for a single client to monopolize the X server. > > So the first thing you should try is to make sure you are using an X server > with this "silken mouse" enabled; anotherwords, run XFree86 4.0x and make > sure the implementation has it enabled > > There may be more to do in Linux thereafter, but until you've done this, you > don't get to discuss the matter further > - Jim Gettys > > -- > Jim Gettys > Technology and Corporate Development > Compaq Computer Corporation > [EMAIL PROTECTED] > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #define HZ 1024 -- negative effects?
Great. I'm running 4.02. How do I enable silken mouse? Thanks, -Michael On 29 Apr 2001 14:44:11 -0700, Jim Gettys wrote: The biggest single issue in GUI responsiveness on Linux has been caused by XFree86's implementation of mouse tracking in user space. On typical UNIX systems, the mouse was often controlled in the kernel driver. Until recently (XFree86 4.0 days), the XFree86 server's reads of mouse/keyboard events were not signal driven, so that if the X server was loaded, the cursor stopped moving. On most (but not all) current XFree86 implementations, this is now signal drive, and further the internal X schedular has been reworked to make it difficult for a single client to monopolize the X server. So the first thing you should try is to make sure you are using an X server with this silken mouse enabled; anotherwords, run XFree86 4.0x and make sure the implementation has it enabled There may be more to do in Linux thereafter, but until you've done this, you don't get to discuss the matter further - Jim Gettys -- Jim Gettys Technology and Corporate Development Compaq Computer Corporation [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sony Memory stick format funnies...
From: "H. Peter Anvin" <[EMAIL PROTECTED]> > "dcim" probably stands for "digital camera images". At least Canon > digital cameras always put their data in a directory named dcim. Makes sense. FAT's root directory is limited in the number of entries it can contain, to something like 32. Cameras can easily produce more than that number of images. -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Common GUI Config for All Users
Hmmm... this is the kernel list... not only the wrong place to ask UI questions, but lots of people here don't even like UIs. :) http://www.gnome.org -M - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, April 28, 2001 2:13 PM Subject: Common GUI Config for All Users > Looking for the best way to give all users a common desktop, which comes from one source (for easy administration). > > Found copying my /root/.gnome & .sawfish directories to a user home breaks the user's GUI, implying a symlink wouldn't work. I am told .gnome & .sawfish can be copied to /etc/skel to give common look for new users, but need ongoing single-source control. Besides, I tried copying root's config files to skel & it broke user GUIs. > > Security is also a concern, so couldn't symlink into root anyway. > > Recommendations welcomed, please. > -- > C. > > The best way out is always through. > - Robert Frost A Servant to Servants, 1914 > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Common GUI Config for All Users
Hmmm... this is the kernel list... not only the wrong place to ask UI questions, but lots of people here don't even like UIs. :) http://www.gnome.org -M - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, April 28, 2001 2:13 PM Subject: Common GUI Config for All Users Looking for the best way to give all users a common desktop, which comes from one source (for easy administration). Found copying my /root/.gnome .sawfish directories to a user home breaks the user's GUI, implying a symlink wouldn't work. I am told .gnome .sawfish can be copied to /etc/skel to give common look for new users, but need ongoing single-source control. Besides, I tried copying root's config files to skel it broke user GUIs. Security is also a concern, so couldn't symlink into root anyway. Recommendations welcomed, please. -- C. The best way out is always through. - Robert Frost A Servant to Servants, 1914 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sony Memory stick format funnies...
From: H. Peter Anvin [EMAIL PROTECTED] dcim probably stands for digital camera images. At least Canon digital cameras always put their data in a directory named dcim. Makes sense. FAT's root directory is limited in the number of entries it can contain, to something like 32. Cameras can easily produce more than that number of images. -M - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #define HZ 1024 -- negative effects
Well, for kicks, I tried setting HZ to 1024 with 2.2.19. It seemed a
little more responsive, but that could be psychosomatic. :) I did notice
that I was unable to sync my palm pilot until I set it back to 100.
YMMV. The most useful "performace" tweak for a GUI that I've come across is:
#define _SHM_ID_BITS10
... if y ou're running Gnome and/or Gtk, because of its appetite for
lots of SHM segments.
-Michael
Mark Hahn wrote:
>>> Are there any negative effects of editing include/asm/param.h to change
>>> HZ from 100 to 1024? Or any other number? This has been suggested as a
>>> way to improve the responsiveness of the GUI on a Linux system. Does it
>>
> ...
>
>> Why not just run the X server at a realtime priority? Then it will get
>> to respond to existing events, such as keyboard and mouse input,
>> promptly without creating lots of superfluous extra clock interrupts.
>> I think you will find this is a better solution.
>
>
> it's surprisingly ineffective; usually, if someone thinks responsiveness
> is bad, there's a problem with the system. for instance, if the system
> is swapping, setting X (and wm, and clients) to RT makes little difference,
> since the kernel is stealing pages from them, regardless of their scheduling
> priority.
>
> if you're curious, you might be interested in two toy programs
> I've attached. one is "setrealtime", which will make a pid RT, or else act
> as a wrapper (ala /bin/time). I have it installed suid root on my system,
> though this is rather dangerous if your have lusers around. the second is a
> simple memory-hog: mmaps a bunch of ram, and keeps it active (printing out a
> handy measure of how long it took to touch its pages...)
>
> regards, mark hahn.
>
>
>
>
> #include
> #include
> #include
> #include
> #include
>
> volatile unsigned sink;
>
> double second() {
> struct timeval tv;
> gettimeofday(,0);
> return tv.tv_sec + 1e-6 * tv.tv_usec;
> }
>
> int
> main(int argc, char *argv[]) {
> int doWrite = 1;
> unsigned size = 80 * 1024 * 1024;
>
> int letter;
> while ((letter = getopt(argc, argv, "s:wrvh?" )) != -1) {
> switch(letter) {
> case 's': size = atoi(optarg) * 1024 * 1024; break;
> case 'w': doWrite = 1; break;
> default:
> fprintf(stderr,"useup [-s mb][-w]\n");
> exit(1);
> }
> }
> int *base = (int*) mmap(0, size,
> PROT_READ|PROT_WRITE,
> MAP_ANONYMOUS|MAP_PRIVATE, 0, 0);
> if (base == MAP_FAILED) {
> perror("mmap failed");
> exit(1);
> }
>
> int *end = base + size/4;
>
> while (1) {
> double start = second();
> if (doWrite)
> for (int *p = base; p < end; p += 1024)
> *p = 0;
> else {
> unsigned sum = 0;
> for (int *p = base; p < end; p += 1024)
> sum += *p;
> sink = sum;
> }
> printf("%f\n",1000*(second() - start));
> }
> }
>
>
>
>
> #include
> #include
> #include
> #include
>
> int
> main(int argc, char *argv[]) {
> int uid = getuid();
> int pid = atoi(argv[1]);
> int sched_fifo_min, sched_fifo_max;
> static struct sched_param sched_parms;
>
> if (!pid)
> pid = getpid();
>
> sched_fifo_min = sched_get_priority_min(SCHED_FIFO);
> sched_fifo_max = sched_get_priority_max(SCHED_FIFO);
> sched_parms.sched_priority = sched_fifo_min + 1;
>
> if (sched_setscheduler(pid, SCHED_FIFO, _parms) == -1)
> perror("cannot set realtime scheduling policy");
>
> if (uid)
> setuid(uid);
>
> if (pid == getpid())
> execvp(argv[1],[1]);
> return 0;
> }
> useup.c
>
> Content-Description:
>
> useup.c
> Content-Type:
>
> TEXT/PLAIN
> Content-Encoding:
>
> BASE64
>
>
>
> setrealtime.c
>
> Content-Description:
>
> setrealtime.c
> Content-Type:
>
> TEXT/PLAIN
> Content-Encoding:
>
> BASE64
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: #define HZ 1024 -- negative effects
Well, for kicks, I tried setting HZ to 1024 with 2.2.19. It seemed a
little more responsive, but that could be psychosomatic. :) I did notice
that I was unable to sync my palm pilot until I set it back to 100.
YMMV. The most useful performace tweak for a GUI that I've come across is:
#define _SHM_ID_BITS10
... if y ou're running Gnome and/or Gtk, because of its appetite for
lots of SHM segments.
-Michael
Mark Hahn wrote:
Are there any negative effects of editing include/asm/param.h to change
HZ from 100 to 1024? Or any other number? This has been suggested as a
way to improve the responsiveness of the GUI on a Linux system. Does it
...
Why not just run the X server at a realtime priority? Then it will get
to respond to existing events, such as keyboard and mouse input,
promptly without creating lots of superfluous extra clock interrupts.
I think you will find this is a better solution.
it's surprisingly ineffective; usually, if someone thinks responsiveness
is bad, there's a problem with the system. for instance, if the system
is swapping, setting X (and wm, and clients) to RT makes little difference,
since the kernel is stealing pages from them, regardless of their scheduling
priority.
if you're curious, you might be interested in two toy programs
I've attached. one is setrealtime, which will make a pid RT, or else act
as a wrapper (ala /bin/time). I have it installed suid root on my system,
though this is rather dangerous if your have lusers around. the second is a
simple memory-hog: mmaps a bunch of ram, and keeps it active (printing out a
handy measure of how long it took to touch its pages...)
regards, mark hahn.
#include unistd.h
#include stdlib.h
#include stdio.h
#include sys/time.h
#include sys/mman.h
volatile unsigned sink;
double second() {
struct timeval tv;
gettimeofday(tv,0);
return tv.tv_sec + 1e-6 * tv.tv_usec;
}
int
main(int argc, char *argv[]) {
int doWrite = 1;
unsigned size = 80 * 1024 * 1024;
int letter;
while ((letter = getopt(argc, argv, s:wrvh? )) != -1) {
switch(letter) {
case 's': size = atoi(optarg) * 1024 * 1024; break;
case 'w': doWrite = 1; break;
default:
fprintf(stderr,useup [-s mb][-w]\n);
exit(1);
}
}
int *base = (int*) mmap(0, size,
PROT_READ|PROT_WRITE,
MAP_ANONYMOUS|MAP_PRIVATE, 0, 0);
if (base == MAP_FAILED) {
perror(mmap failed);
exit(1);
}
int *end = base + size/4;
while (1) {
double start = second();
if (doWrite)
for (int *p = base; p end; p += 1024)
*p = 0;
else {
unsigned sum = 0;
for (int *p = base; p end; p += 1024)
sum += *p;
sink = sum;
}
printf(%f\n,1000*(second() - start));
}
}
#include unistd.h
#include stdlib.h
#include stdio.h
#include sched.h
int
main(int argc, char *argv[]) {
int uid = getuid();
int pid = atoi(argv[1]);
int sched_fifo_min, sched_fifo_max;
static struct sched_param sched_parms;
if (!pid)
pid = getpid();
sched_fifo_min = sched_get_priority_min(SCHED_FIFO);
sched_fifo_max = sched_get_priority_max(SCHED_FIFO);
sched_parms.sched_priority = sched_fifo_min + 1;
if (sched_setscheduler(pid, SCHED_FIFO, sched_parms) == -1)
perror(cannot set realtime scheduling policy);
if (uid)
setuid(uid);
if (pid == getpid())
execvp(argv[1],argv[1]);
return 0;
}
useup.c
Content-Description:
useup.c
Content-Type:
TEXT/PLAIN
Content-Encoding:
BASE64
setrealtime.c
Content-Description:
setrealtime.c
Content-Type:
TEXT/PLAIN
Content-Encoding:
BASE64
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
#define HZ 1024 -- negative effects?
Are there any negative effects of editing include/asm/param.h to change HZ from 100 to 1024? Or any other number? This has been suggested as a way to improve the responsiveness of the GUI on a Linux system. Does it throw off anything else, like serial port timing, etc.? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
usb insmod hang w/2.4.2
I'm installing Linux onto a Compaq iPaq IA-1 -- the little "MSN
Companion" thing. I wish Compaq didn't feel compelled to name everything
"iPaq." This device is essentially a laptop with a strange case, no hard
drive, and 32MB of RAM. It has a VIA chipset and four USB ports. The
southbridge is a VT82C686 ("Apollo Super South"). It sports to UHCI USB
controllers sharing IRQ 11.
I have patched a long, thin logo into the kernel to replace the Tux
logo, but that is the only change I made.
When I insmod usb-uhci.o or uhci.o, it gets as far as ":
detected 2 ports" and then hangs, terminally. It does t his whether I
have usbcore compiled in or loaded as a module.
I have attached my .config file. Any help would be appreciated!
-M
#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y
#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
CONFIG_MK6=y
# CONFIG_MK7 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_TSC=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_TOSHIBA is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_SMP is not set
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
#
# General setup
#
CONFIG_NET=y
# CONFIG_VISWS is not set
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
CONFIG_HOTPLUG=y
#
# PCMCIA/CardBus support
#
CONFIG_PCMCIA=y
CONFIG_CARDBUS=y
CONFIG_I82365=y
# CONFIG_TCIC is not set
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_PM=y
# CONFIG_ACPI is not set
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
# CONFIG_APM_CPU_IDLE is not set
CONFIG_APM_DISPLAY_BLANK=y
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set
CONFIG_APM_REAL_MODE_POWER_OFF=y
#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC1000 is not set
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOCPROBE is not set
#
# RAM/ROM Device Drivers
#
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_MTDRAM is not set
#
# Linearly Mapped Flash Device Drivers
#
CONFIG_MTD_CFI=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_JEDEC is not set
# CONFIG_MTD_PHYSMAP is not set
#
# Drivers for chip mappings
#
# CONFIG_MTD_NORA is not set
# CONFIG_MTD_PNC2000 is not set
# CONFIG_MTD_RPXLITE is not set
#
# User modules and translation layers for MTD devices
#
# CONFIG_MTD_CHAR is not set
# CONFIG_MTD_BLOCK is not set
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
#
# Parallel port support
#
# CONFIG_PARPORT is not set
#
# Plug and Play configuration
#
CONFIG_PNP=y
# CONFIG_ISAPNP is not set
#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_NETLINK=y
# CONFIG_RTNETLINK is not set
# CONFIG_NETLINK_DEV is not set
# CONFIG_NETFILTER is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_INET_ECN is not set
CONFIG_SYN_COOKIES=y
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set
# CONFIG_ATM is not set
#
#
#
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER
usb insmod hang w/2.4.2
I'm installing Linux onto a Compaq iPaq IA-1 -- the little "MSN
Companion" thing. I wish Compaq didn't feel compelled to name everything
"iPaq." This device is essentially a laptop with a strange case, no hard
drive, and 32MB of RAM. It has a VIA chipset and four USB ports. The
southbridge is a VT82C686 ("Apollo Super South"). It sports to UHCI USB
controllers sharing IRQ 11.
I have patched a long, thin logo into the kernel to replace the Tux
logo, but that is the only change I made.
When I insmod usb-uhci.o or uhci.o, it gets as far as "driver:
detected 2 ports" and then hangs, terminally. It does t his whether I
have usbcore compiled in or loaded as a module.
I have attached my .config file. Any help would be appreciated!
-M
#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y
#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
CONFIG_MK6=y
# CONFIG_MK7 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_TSC=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_TOSHIBA is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_SMP is not set
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
#
# General setup
#
CONFIG_NET=y
# CONFIG_VISWS is not set
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
CONFIG_HOTPLUG=y
#
# PCMCIA/CardBus support
#
CONFIG_PCMCIA=y
CONFIG_CARDBUS=y
CONFIG_I82365=y
# CONFIG_TCIC is not set
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_PM=y
# CONFIG_ACPI is not set
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
# CONFIG_APM_CPU_IDLE is not set
CONFIG_APM_DISPLAY_BLANK=y
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set
CONFIG_APM_REAL_MODE_POWER_OFF=y
#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC1000 is not set
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOCPROBE is not set
#
# RAM/ROM Device Drivers
#
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_MTDRAM is not set
#
# Linearly Mapped Flash Device Drivers
#
CONFIG_MTD_CFI=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_JEDEC is not set
# CONFIG_MTD_PHYSMAP is not set
#
# Drivers for chip mappings
#
# CONFIG_MTD_NORA is not set
# CONFIG_MTD_PNC2000 is not set
# CONFIG_MTD_RPXLITE is not set
#
# User modules and translation layers for MTD devices
#
# CONFIG_MTD_CHAR is not set
# CONFIG_MTD_BLOCK is not set
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
#
# Parallel port support
#
# CONFIG_PARPORT is not set
#
# Plug and Play configuration
#
CONFIG_PNP=y
# CONFIG_ISAPNP is not set
#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_NETLINK=y
# CONFIG_RTNETLINK is not set
# CONFIG_NETLINK_DEV is not set
# CONFIG_NETFILTER is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_INET_ECN is not set
CONFIG_SYN_COOKIES=y
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set
# CONFIG_ATM is not set
#
#
#
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
#
Re: opening files in /proc, and modules
Sweet! Thanks!
I'm working on 2.2 for now, but the 2.4 API looks nicer... :)
-M
On 08 Mar 2001 11:43:24 -0500, Alexander Viro wrote:
>
>
> On 8 Mar 2001, Michael Rothwell wrote:
>
> > Figured it out -- I think. This appears to be the answer:
> >
> > In struct proc_dir_entry,set the fill_inode function pointer to a
> > callback to handle refcounts.
> >
> > struct proc_dir_entry
> > {
> > ...
> > void (*fill_inode)(struct inode *, int);
> > ...
> > };
> [snip]
> > ... right? :)
>
> Right for 2.2, wrong for 2.4. There you just set ->owner to THIS_MODULE
> and forget about the whole mess with callbacks.
> Cheers,
> Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: opening files in /proc, and modules
Figured it out -- I think. This appears to be the answer:
In struct proc_dir_entry,set the fill_inode function pointer to a
callback to handle refcounts.
struct proc_dir_entry
{
...
void (*fill_inode)(struct inode *, int);
...
};
void fill_inode_cb(struct inode *i, int v)
{
if (v==0)
{
MOD_DEC_USE_COUNT;
return;
};
if (v==1)
{
MOD_INC_USE_COUNT;
return;
};
};
... right? :)
On 08 Mar 2001 11:01:28 -0500, Michael Rothwell wrote:
> How can I detect that open() has been called on a file in procfs that a
> module provides? If I modprobe my module, open one or more if its proc
> entries, then rmmod the module while the proc files are still open, then
> the deletion of those entries is deferred. When I close the file(s), the
> kernel oopses. I need to be able to detect open() and close() in order
> to increment/decrement the reference count for my module, to prevent it
> from being rmmoded when in use. Any tips?
>
> Thanks!
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
opening files in /proc, and modules
How can I detect that open() has been called on a file in procfs that a module provides? If I modprobe my module, open one or more if its proc entries, then rmmod the module while the proc files are still open, then the deletion of those entries is deferred. When I close the file(s), the kernel oopses. I need to be able to detect open() and close() in order to increment/decrement the reference count for my module, to prevent it from being rmmoded when in use. Any tips? Thanks! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
opening files in /proc, and modules
How can I detect that open() has been called on a file in procfs that a module provides? If I modprobe my module, open one or more if its proc entries, then rmmod the module while the proc files are still open, then the deletion of those entries is deferred. When I close the file(s), the kernel oopses. I need to be able to detect open() and close() in order to increment/decrement the reference count for my module, to prevent it from being rmmoded when in use. Any tips? Thanks! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: opening files in /proc, and modules
Figured it out -- I think. This appears to be the answer:
In struct proc_dir_entry,set the fill_inode function pointer to a
callback to handle refcounts.
struct proc_dir_entry
{
...
void (*fill_inode)(struct inode *, int);
...
};
void fill_inode_cb(struct inode *i, int v)
{
if (v==0)
{
MOD_DEC_USE_COUNT;
return;
};
if (v==1)
{
MOD_INC_USE_COUNT;
return;
};
};
... right? :)
On 08 Mar 2001 11:01:28 -0500, Michael Rothwell wrote:
How can I detect that open() has been called on a file in procfs that a
module provides? If I modprobe my module, open one or more if its proc
entries, then rmmod the module while the proc files are still open, then
the deletion of those entries is deferred. When I close the file(s), the
kernel oopses. I need to be able to detect open() and close() in order
to increment/decrement the reference count for my module, to prevent it
from being rmmoded when in use. Any tips?
Thanks!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: opening files in /proc, and modules
Sweet! Thanks!
I'm working on 2.2 for now, but the 2.4 API looks nicer... :)
-M
On 08 Mar 2001 11:43:24 -0500, Alexander Viro wrote:
On 8 Mar 2001, Michael Rothwell wrote:
Figured it out -- I think. This appears to be the answer:
In struct proc_dir_entry,set the fill_inode function pointer to a
callback to handle refcounts.
struct proc_dir_entry
{
...
void (*fill_inode)(struct inode *, int);
...
};
[snip]
... right? :)
Right for 2.2, wrong for 2.4. There you just set -owner to THIS_MODULE
and forget about the whole mess with callbacks.
Cheers,
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
physmem w/o proc
physmem= `head -10 /var/log/dmesg | grep Memory: | cut -d" " -f2 | cut -d "/" -f1 | cut -d"k" -f1` - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Q: How to get physical memory size from user space without procfs
pyhsmem = `free | grep Mem | tr -s "/ / /" | cut -f2 -d" "` On 03 Mar 2001 13:37:42 -0500, Denis Perchine wrote: > Hello, > > actually the question is in subj. > Problem is that there is a program which needs to know physical memory > size. This information is used to justify memory consumption as after some > swapping performance is drops dramatically, and it is better to finish. > > I know that this is not the best idea, but it is assumed that this program > is the only one running on the machine. > > I do not want to use proc as some people can just do not mount it. > > Any comments, suggestions? > > Thanks in advance. > > Denis Perchine. > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C586B USB PCI card, Linux USB
On 03 Mar 2001 12:54:36 +0100, Vojtech Pavlik wrote: > No, they have a separate USB chip, but it has the same PCI ID as the > builtin silicon in the southbridge. Ah. I went and looked up that chip ID at via's website, and saw only southbridge chips, no USB-only chips at all. But, my real question was, is there a way to get it to work right under Linux? I have two machines; one is an Athlon with built-in (Via) USB support, and it seems to work ok. I also have a P-200 that's my print server, file server and (hopefully) scanner server. It is an old HX-chipset pre-USB socket-7 intel machine, but I've put a Via-chipset 2-port USB card into it. I keep getting timeouts on it. I've looked all over the net for clues as to what I can do to get it to work, and nothing has. Both uhci and usb-uhci have the same problems. Is there a generic cause for timeout problems when doing bulk transfers? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C586B USB PCI card, Linux USB
On 03 Mar 2001 12:54:36 +0100, Vojtech Pavlik wrote: No, they have a separate USB chip, but it has the same PCI ID as the builtin silicon in the southbridge. Ah. I went and looked up that chip ID at via's website, and saw only southbridge chips, no USB-only chips at all. But, my real question was, is there a way to get it to work right under Linux? I have two machines; one is an Athlon with built-in (Via) USB support, and it seems to work ok. I also have a P-200 that's my print server, file server and (hopefully) scanner server. It is an old HX-chipset pre-USB socket-7 intel machine, but I've put a Via-chipset 2-port USB card into it. I keep getting timeouts on it. I've looked all over the net for clues as to what I can do to get it to work, and nothing has. Both uhci and usb-uhci have the same problems. Is there a generic cause for timeout problems when doing bulk transfers? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
physmem w/o proc
physmem= `head -10 /var/log/dmesg | grep Memory: | cut -d" " -f2 | cut -d "/" -f1 | cut -d"k" -f1` - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VT82C586B USB PCI card, Linux USB
I have a USB PCI card, which shows up as this in `lspci`: 00:09.0 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 04) ... it appears that they tossed the whole southbridge chip onto a pci board, and disabled everything but USB. Anyway, this device seems to be semi-functional under 2.2.18 USB. I have a cheapie IBM usb camera that works, but a USB scanner that does not -- always gives the following errors: usb_control/bulk_msg: timeout scanner.c: write_scanner: NAK received. The firmware upload seems to work ok, but nothing else does. The sane tools actually segfault, and once the kernel oopsed (didn't manage to get the output :( ). I noticed a config setting for that chipset, but it was under block devices, so I left it turned off. Judging form reading the LKML, VIA chipsets are problematic. Has anyone has any positive experiences getting this device to do the thing it's supposed to do under Linux? Any tips? -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VT82C586B USB PCI card, Linux USB
I have a USB PCI card, which shows up as this in `lspci`: 00:09.0 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 04) ... it appears that they tossed the whole southbridge chip onto a pci board, and disabled everything but USB. Anyway, this device seems to be semi-functional under 2.2.18 USB. I have a cheapie IBM usb camera that works, but a USB scanner that does not -- always gives the following errors: usb_control/bulk_msg: timeout scanner.c: write_scanner: NAK received. The firmware upload seems to work ok, but nothing else does. The sane tools actually segfault, and once the kernel oopsed (didn't manage to get the output :( ). I noticed a config setting for that chipset, but it was under block devices, so I left it turned off. Judging form reading the LKML, VIA chipsets are problematic. Has anyone has any positive experiences getting this device to do the thing it's supposed to do under Linux? Any tips? -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CPRM is dead; Thanks Andre!
> IBM withdrew the proposal. ... from public view - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CPRM is dead; Thanks Andre!
IBM withdrew the proposal. ... from public view - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LILO and serial speeds over 9600
> Then HPA may ask: but why do you want to run the serial console at
> 115200?? The answer is simple: because we ...
... don't want to drag out debugging the kernel on a 38400 connection.
Because printks are our only debugging option ("thanks", Linus), and a slow
serial port block and can change the timing of when code runs, I need the
serial port to run as fast as possible. It would be keen to be able to use
an ethernet debugging console rather than (or in addition to) serial,
because it would be even faster, and if I'm debugging (for instance) a
serial driver, I won't have to use the system I'm debugging to debug the
system I'm debugging.
Of course, a supported kernel debugger would make a nice addition to faster
console output, but I won't hold my breath waiting for Linux to acquire what
pretty much every other operating system already has.
-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://vger.kernel.org/lkml/
Re: "kaweth" usb ethernet driver in 2.4?
Thanks. Has Brad Hards made his version available somewhere? -M - Original Message - From: "Eric Sandeen" <[EMAIL PROTECTED]> To: "Michael Rothwell" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, February 04, 2001 9:30 AM Subject: Re: "kaweth" usb ethernet driver in 2.4? > Michael Rothwell wrote: > > > > It also doesn't seem to work in 2.2. :) The original development of > > > this driver was going on at http://drivers.rd.ilan.net/kaweth/ but there > > > have been no updates for quite some time. > > > > Well, it doesn't work you _you_ on 2.2, obviously. But it works for us > > and other people. Can you provide any information to diagnose the > > problem you're having? > > I'm sorry, I should have provided that info. I searched the 'net, and > saw many people with problems on several mailing lists, and saw no > solutions, or reports of success, so I assumed that it was a widespread, > possibly even known, problem with the driver. > > I'll preface this by saying that Brad Hards sent me an updated version > that works much better, at least as long as the module is loaded before > the device is plugged in. > > But here's what I get with a 2.2 kernel and the stock driver: > > Kawasaki USB->Ethernet Driver loading... > usb.c: registered new driver kaweth > usb.c: USB new device connect, assigned device number 2 > Kawasaki Device Probe (Device number:2): 0x0846:0x1001 > Device at c2192600 > Descriptor length: 12 type: 1 > NetGear EA-101 connected... > Reading kaweth configuration > Request type: c0 Request: 0 Value: 0 Index: 0 Length: 12 > usb-uhci.c: interrupt, status 2, frame# 1929 > kaweth control message failed (urb addr: c2c05ca0) > usb_control/bulk_msg: timeout > usb-uhci.c: interrupt, status 2, frame# 851 > Actual length: 0, length 18 > Resetting... > usb-uhci.c: interrupt, status 2, frame# 854 > Downloading firmware at c48abb6c to kaweth device at c31be000... > Firmware length: 3838 > Request type: 40 Request: ff Value: 0 Index: 0 Length: efe > usb-uhci.c: interrupt, status 2, frame# 871 > kaweth control message failed (urb addr: c213ab60) > usb-uhci.c: interrupt, status 2, frame# 877 > usb-uhci.c: interrupt, status 2, frame# 882 > Actual length: 0, length 3838 > Error downloading firmware (-110), no net device created > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kaweth usb ethernet driver in 2.4?
Thanks. Has Brad Hards made his version available somewhere? -M - Original Message - From: "Eric Sandeen" [EMAIL PROTECTED] To: "Michael Rothwell" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, February 04, 2001 9:30 AM Subject: Re: "kaweth" usb ethernet driver in 2.4? Michael Rothwell wrote: It also doesn't seem to work in 2.2. :) The original development of this driver was going on at http://drivers.rd.ilan.net/kaweth/ but there have been no updates for quite some time. Well, it doesn't work you _you_ on 2.2, obviously. But it works for us and other people. Can you provide any information to diagnose the problem you're having? I'm sorry, I should have provided that info. I searched the 'net, and saw many people with problems on several mailing lists, and saw no solutions, or reports of success, so I assumed that it was a widespread, possibly even known, problem with the driver. I'll preface this by saying that Brad Hards sent me an updated version that works much better, at least as long as the module is loaded before the device is plugged in. But here's what I get with a 2.2 kernel and the stock driver: Kawasaki USB-Ethernet Driver loading... usb.c: registered new driver kaweth usb.c: USB new device connect, assigned device number 2 Kawasaki Device Probe (Device number:2): 0x0846:0x1001 Device at c2192600 Descriptor length: 12 type: 1 NetGear EA-101 connected... Reading kaweth configuration Request type: c0 Request: 0 Value: 0 Index: 0 Length: 12 usb-uhci.c: interrupt, status 2, frame# 1929 kaweth control message failed (urb addr: c2c05ca0) usb_control/bulk_msg: timeout usb-uhci.c: interrupt, status 2, frame# 851 Actual length: 0, length 18 Resetting... usb-uhci.c: interrupt, status 2, frame# 854 Downloading firmware at c48abb6c to kaweth device at c31be000... Firmware length: 3838 Request type: 40 Request: ff Value: 0 Index: 0 Length: efe usb-uhci.c: interrupt, status 2, frame# 871 kaweth control message failed (urb addr: c213ab60) usb-uhci.c: interrupt, status 2, frame# 877 usb-uhci.c: interrupt, status 2, frame# 882 Actual length: 0, length 3838 Error downloading firmware (-110), no net device created - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: "kaweth" usb ethernet driver in 2.4?
On 03 Feb 2001 14:22:02 -0600, Eric Sandeen wrote: > The driver is included with the USB stuff for 2.2, but not in 2.4. That's because we stopped fooling with 2.4 around the middle of the pre-test-ac series of releases. We'll probably pick it back up around 2.4.7 or so. > It also doesn't seem to work in 2.2. :) The original development of > this driver was going on at http://drivers.rd.ilan.net/kaweth/ but there > have been no updates for quite some time. Well, it doesn't work you _you_ on 2.2, obviously. But it works for us and other people. Can you provide any information to diagnose the problem you're having? And, truthfully, you'd be better off tossing it in the trash and buying a better product. It's VERY lossy with packets and slow. And it's not just our driver; it's the device itself. It sucks on Windows as well. :) However, if you post some info about your experience with it, perhaps we can get it working for you. But not on 2.4 for awhile. -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kaweth usb ethernet driver in 2.4?
On 03 Feb 2001 14:22:02 -0600, Eric Sandeen wrote: The driver is included with the USB stuff for 2.2, but not in 2.4. That's because we stopped fooling with 2.4 around the middle of the pre-test-ac series of releases. We'll probably pick it back up around 2.4.7 or so. It also doesn't seem to work in 2.2. :) The original development of this driver was going on at http://drivers.rd.ilan.net/kaweth/ but there have been no updates for quite some time. Well, it doesn't work you _you_ on 2.2, obviously. But it works for us and other people. Can you provide any information to diagnose the problem you're having? And, truthfully, you'd be better off tossing it in the trash and buying a better product. It's VERY lossy with packets and slow. And it's not just our driver; it's the device itself. It sucks on Windows as well. :) However, if you post some info about your experience with it, perhaps we can get it working for you. But not on 2.4 for awhile. -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
Mo McKinlay wrote: > I would too, but POSIX won't let us unless we start enforcing side-effect > rules for all filesystems. Hence why I came up with openstream() :) So, openstream() is probably the most painless way to get named streams support into Linux in the immediate future. Openstream() will have to fail on filesystems that do not support streams, ideally without changing those filesystems. And as long as we're adding a system call to deal with streams, we should consider adding the functions for extended attributes at the same time. >From http://www.flyingbuttmonkeys.com/streams-on-posix.txt ... Minimum VFS Support vop_eattr_get - read an EA vop_eattr_set - set an EA vop_eattr_remove - remove an EA vop_eattr_list - list the EAs like vop_readdir would a directory. Optional Support vop_eattr_create - Create an EA or error if it exists. vop_eattr_multi - perform a sequence of EA vops atomically. vop_eattr_rename - change the name of an EA vop_eattr_serialize - export all the EAs as a stream of entries. Thoughts? You mught want to refer back to the paper to get the whole EAs proposal... -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
Mo McKinlay wrote: I would too, but POSIX won't let us unless we start enforcing side-effect rules for all filesystems. Hence why I came up with openstream() :) So, openstream() is probably the most painless way to get named streams support into Linux in the immediate future. Openstream() will have to fail on filesystems that do not support streams, ideally without changing those filesystems. And as long as we're adding a system call to deal with streams, we should consider adding the functions for extended attributes at the same time. From http://www.flyingbuttmonkeys.com/streams-on-posix.txt ... Minimum VFS Support vop_eattr_get - read an EA vop_eattr_set - set an EA vop_eattr_remove - remove an EA vop_eattr_list - list the EAs like vop_readdir would a directory. Optional Support vop_eattr_create - Create an EA or error if it exists. vop_eattr_multi - perform a sequence of EA vops atomically. vop_eattr_rename - change the name of an EA vop_eattr_serialize - export all the EAs as a stream of entries. Thoughts? You mught want to refer back to the paper to get the whole EAs proposal... -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
unmapping inode?
>From within a filesystem driver, how would I completely remove a page cache mapping for an inode in 2.2.18? -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
unmapping inode?
From within a filesystem driver, how would I completely remove a page cache mapping for an inode in 2.2.18? -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
What you say is true; but Win32 -- which pretty much all Windows apps use -- disallows the following: \/:*?"<>| ... from that, they chose ":" as the stream delimiter, since the only other place it is used is with the drive letters. For the user, and most (non-native, i.e., Win32) apps, there are limitations on what a filename can contain. -M - Original Message - From: "Albert D. Cahalan" <[EMAIL PROTECTED]> To: "Michael Rothwell" <[EMAIL PROTECTED]> Cc: "Mo McKinlay" <[EMAIL PROTECTED]>; "Peter Samuelson" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Saturday, January 20, 2001 11:27 PM Subject: Re: named streams, extended attributes, and posix > Michael Rothwell writes: > > ... > >> Today, Michael Rothwell ([EMAIL PROTECTED]) wrote: > > >>> The filesystem, when registering that it supports the "named streams" > >>> namespace, could specify its preferred delimiter to the VFS as well. > >>> Ext4 could use /directory/file/stream, and NTFS could use > >>> /directory/file:stream. > ... > > Oh, undoubtedly. But NTFS already disallows several characters > > in valid filenames. > > NTFS allows all 16-bit characters in filenames, including 0x. > Nothing is disallowed. The NT kernel's native API uses counted > Unicode strings. The strings can be huge too, like 128 kB. > > So there isn't _any_ safe delimiter. > > Win32 will choke on 0x and a few other things, allowing a > clever person to create apparently inaccessible files. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
What you say is true; but Win32 -- which pretty much all Windows apps use -- disallows the following: \/:*?"| ... from that, they chose ":" as the stream delimiter, since the only other place it is used is with the drive letters. For the user, and most (non-native, i.e., Win32) apps, there are limitations on what a filename can contain. -M - Original Message - From: "Albert D. Cahalan" [EMAIL PROTECTED] To: "Michael Rothwell" [EMAIL PROTECTED] Cc: "Mo McKinlay" [EMAIL PROTECTED]; "Peter Samuelson" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, January 20, 2001 11:27 PM Subject: Re: named streams, extended attributes, and posix Michael Rothwell writes: ... Today, Michael Rothwell ([EMAIL PROTECTED]) wrote: The filesystem, when registering that it supports the "named streams" namespace, could specify its preferred delimiter to the VFS as well. Ext4 could use /directory/file/stream, and NTFS could use /directory/file:stream. ... Oh, undoubtedly. But NTFS already disallows several characters in valid filenames. NTFS allows all 16-bit characters in filenames, including 0x. Nothing is disallowed. The NT kernel's native API uses counted Unicode strings. The strings can be huge too, like 128 kB. So there isn't _any_ safe delimiter. Win32 will choke on 0x and a few other things, allowing a clever person to create apparently inaccessible files. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.18 and mkraid
What version of the raidtools to I need for 2.2.18 software raid? Documentation/md.txt has a non-functional URL in it. Thanks. -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
Mo McKinlay wrote: > Nono, that's not what I mean - each of the filesystems fails if it > doesn't support what you're trying to do, that's given - but having a > different delimeter registered by the filesystem (and hence the > possibility of every single filesystem using a different delimeter) brings > about a completely different kind of inconsistency. True. Which is why I'd prefer a standard delimiter. ":" seems to be the top candidate. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
Mo McKinlay wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Today, Michael Rothwell ([EMAIL PROTECTED]) wrote: > > > The filesystem, when registering that it supports the "named streams" > > namespace, could specify its preferred delimiter to the VFS as well. > > Ext4 could use /directory/file/stream, and NTFS could use > > /directory/file:stream. > > Erk - nice from a programming point of view, horrible from a consistency > one. The nice thing about VFS is that it provides a consistent abstract > interface - I'd place a small amount of money on the fact that Al Viro > would probably flame you to high heaven for that last suggestion if he was > paying much attention to this thread :-) Oh, undoubtedly. But NTFS already disallows several characters in valid filenames. This also violates the "consistent abstract interface." But it's reality. -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
Mo McKinlay wrote: > (Take symbolic linking, for example - if you ln -s on VFAT, you get > 'operation not permitted' - named stream/EA operations on a filesystem > that doesn't support them should return the same, IMHO). And they would, if the chosen namespace was not supported. > Also, I don't like the idea of bypassing POSIX in this manner (using ':' > as a delimeter), even if the underlying filesystem *may* not support it. > > What's to say that ext4 (or whatever) won't support named streams, but > still allow ':'? Your solution as it stands would break in that situation > (assuming I've not missed something :) The filesystem, when registering that it supports the "named streams" namespace, could specify its preferred delimiter to the VFS as well. Ext4 could use /directory/file/stream, and NTFS could use /directory/file:stream. -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
Mo McKinlay wrote: > openstream(file, stream, flags) > > Where 'file' should be an fd (although i'm sure the VFS gods will think of > plenty of reasons why this is a bad idea, at which point I'll > conventiently change my mind ;). Stream is simply the name of the stream, > flags are as with open() (O_RDONLY, et al). openstream() then returns an > fd which can be read/written/sendfiled/closed as the programmer wishes. I'm not opposed to that, and think it is even a useful idea. Sort of like fdopen(). > Apart from the additional of a new open()-type call, your paper seems to > be fairly solid. Thanks. I think having the option of the namespace augmentation would be useful, in terms of supporting existing filesystems. On NTFS, ":" is not a legal filename character anyway. The namespace augmentation suggested in the paper would allow filesystems like NTFS to work as they should, and all other filesystems to ignore it. -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
Mo McKinlay wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Today, Michael Rothwell ([EMAIL PROTECTED]) wrote: > > > Unfortunately, unix allows everything but "/" in filenames. This was > > probably a mistake, as it makes it nearly impossible to augment the > > namespace, but it is the reality. > > > Did you read the "new namespace" section of the paper? > > I've not, so pardon me if I make a bad assumption (and slap me for it, > too), but doesn't introducing a new namespace segregate the streams from > the files/directories, thus introducing an artifical separation which > isn't really there? (Pretty much why I'm more in favour of a specific API > for reading streams, extended attributes and whatnot, over any of the > other solutions thus suggested). Well, EAs are accessed via a special API. The paper also covers that. Streams, however, are by nature accessed as files; this is what makes them not EAs. EAs are set and retrieved atomically. Streams can be used with open(), seek(), read(), write(), etc. This is actually more "unixy" than EAs, as the usual set of Unix functions and tools can work with streams unmodified; i.e., without knowledge of a special API. Of course, cp() is the exception. It would have to be able to enumerate and copy all the streams. If you have time, please read over the paper so we don't get into the same rut we got into last time. :) http://www.flyingbuttmonkeys.com/streams-on-posix.txt http://www.flyingbuttmonkeys.com/streams-on-posix.pdf -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re:
Robert Kaiser wrote: > > On Thu Jan 18 16:30:30 2001 [EMAIL PROTECTED] wrote > > Has anyone had any luck getting a 2.4 kernel to run on Cobalt x86 > > hardware? It doesn't even seem to start (I get nothing on the screen from > >t he kernel, it just sits there and does nothing). :( > > What processor does it use ? (386 or 486 perchance?) AMD K6. New ones will use Athlon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re:
Robert Kaiser wrote: On Thu Jan 18 16:30:30 2001 [EMAIL PROTECTED] wrote Has anyone had any luck getting a 2.4 kernel to run on Cobalt x86 hardware? It doesn't even seem to start (I get nothing on the screen from t he kernel, it just sits there and does nothing). :( What processor does it use ? (386 or 486 perchance?) AMD K6. New ones will use Athlon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
Mo McKinlay wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today, Michael Rothwell ([EMAIL PROTECTED]) wrote: Unfortunately, unix allows everything but "/" in filenames. This was probably a mistake, as it makes it nearly impossible to augment the namespace, but it is the reality. Did you read the "new namespace" section of the paper? I've not, so pardon me if I make a bad assumption (and slap me for it, too), but doesn't introducing a new namespace segregate the streams from the files/directories, thus introducing an artifical separation which isn't really there? (Pretty much why I'm more in favour of a specific API for reading streams, extended attributes and whatnot, over any of the other solutions thus suggested). Well, EAs are accessed via a special API. The paper also covers that. Streams, however, are by nature accessed as files; this is what makes them not EAs. EAs are set and retrieved atomically. Streams can be used with open(), seek(), read(), write(), etc. This is actually more "unixy" than EAs, as the usual set of Unix functions and tools can work with streams unmodified; i.e., without knowledge of a special API. Of course, cp() is the exception. It would have to be able to enumerate and copy all the streams. If you have time, please read over the paper so we don't get into the same rut we got into last time. :) http://www.flyingbuttmonkeys.com/streams-on-posix.txt http://www.flyingbuttmonkeys.com/streams-on-posix.pdf -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
Mo McKinlay wrote: openstream(file, stream, flags) Where 'file' should be an fd (although i'm sure the VFS gods will think of plenty of reasons why this is a bad idea, at which point I'll conventiently change my mind ;). Stream is simply the name of the stream, flags are as with open() (O_RDONLY, et al). openstream() then returns an fd which can be read/written/sendfiled/closed as the programmer wishes. I'm not opposed to that, and think it is even a useful idea. Sort of like fdopen(). Apart from the additional of a new open()-type call, your paper seems to be fairly solid. Thanks. I think having the option of the namespace augmentation would be useful, in terms of supporting existing filesystems. On NTFS, ":" is not a legal filename character anyway. The namespace augmentation suggested in the paper would allow filesystems like NTFS to work as they should, and all other filesystems to ignore it. -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
Mo McKinlay wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today, Michael Rothwell ([EMAIL PROTECTED]) wrote: The filesystem, when registering that it supports the "named streams" namespace, could specify its preferred delimiter to the VFS as well. Ext4 could use /directory/file/stream, and NTFS could use /directory/file:stream. Erk - nice from a programming point of view, horrible from a consistency one. The nice thing about VFS is that it provides a consistent abstract interface - I'd place a small amount of money on the fact that Al Viro would probably flame you to high heaven for that last suggestion if he was paying much attention to this thread :-) Oh, undoubtedly. But NTFS already disallows several characters in valid filenames. This also violates the "consistent abstract interface." But it's reality. -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
Mo McKinlay wrote: Nono, that's not what I mean - each of the filesystems fails if it doesn't support what you're trying to do, that's given - but having a different delimeter registered by the filesystem (and hence the possibility of every single filesystem using a different delimeter) brings about a completely different kind of inconsistency. True. Which is why I'd prefer a standard delimiter. ":" seems to be the top candidate. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.18 and mkraid
What version of the raidtools to I need for 2.2.18 software raid? Documentation/md.txt has a non-functional URL in it. Thanks. -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
Unfortunately, unix allows everything but "/" in filenames. This was
probably a mistake, as it makes it nearly impossible to augment the
namespace, but it is the reality.
Did you read the "new namespace" section of the paper?
It also talked a bit about supporting Extended Attributes, which are access
via an API and not with a filename separator. We could, perhaps, begin by
supporting EAs. That would take care of HFS, HPFS, XFS, and BeFS, and half
of NTFS. Then we could go on to tackle the Named Streams problem.
-M
- Original Message -
From: "Mo McKinlay" <[EMAIL PROTECTED]>
To: "Peter Samuelson" <[EMAIL PROTECTED]>
Cc: "Mo McKinlay" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, January 18, 2001 1:30 PM
Subject: Re: named streams, extended attributes, and posix
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Yesterday, Peter Samuelson ([EMAIL PROTECTED]) wrote:
>
> > Yeah, I agree, 'file/stream' is lousy syntax as well. If it weren't
> > for the possibility of having streams on directories, it would almost
> > be acceptible. I still don't know which (':' or '/') is the worse
> > hack.
>
> Me neither :/
>
> > As I've said elsewhere in this thread, I can't think of *any* clean
way
> > to shoehorn forks into nice, transparent posix calls. It really wants
> > a new API.
>
> Likewise. This was my standpoint the last time around - a clear concise
> portable API for accessing streams (even if it *started out*
> Linux-specific) - without imposing silly semantics on existing
> applications which currently ignore streams anyway.
>
> Mo.
>
> - --
> Mo McKinlay
> [EMAIL PROTECTED]
> -
-
> GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22
>
>
>
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iEYEARECAAYFAjpnYGQACgkQRcGgB3aidfmWBQCfXgNq/vqltt76mApoDiNI9HnH
> ws8AoJZ2vvlH1iCAeUu7yktWWN0Bncc3
> =gEmD
> -END PGP SIGNATURE-
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
Unfortunately, unix allows everything but "/" in filenames. This was
probably a mistake, as it makes it nearly impossible to augment the
namespace, but it is the reality.
Did you read the "new namespace" section of the paper?
It also talked a bit about supporting Extended Attributes, which are access
via an API and not with a filename separator. We could, perhaps, begin by
supporting EAs. That would take care of HFS, HPFS, XFS, and BeFS, and half
of NTFS. Then we could go on to tackle the Named Streams problem.
-M
- Original Message -
From: "Mo McKinlay" [EMAIL PROTECTED]
To: "Peter Samuelson" [EMAIL PROTECTED]
Cc: "Mo McKinlay" [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, January 18, 2001 1:30 PM
Subject: Re: named streams, extended attributes, and posix
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yesterday, Peter Samuelson ([EMAIL PROTECTED]) wrote:
Yeah, I agree, 'file/stream' is lousy syntax as well. If it weren't
for the possibility of having streams on directories, it would almost
be acceptible. I still don't know which (':' or '/') is the worse
hack.
Me neither :/
As I've said elsewhere in this thread, I can't think of *any* clean
way
to shoehorn forks into nice, transparent posix calls. It really wants
a new API.
Likewise. This was my standpoint the last time around - a clear concise
portable API for accessing streams (even if it *started out*
Linux-specific) - without imposing silly semantics on existing
applications which currently ignore streams anyway.
Mo.
- --
Mo McKinlay
[EMAIL PROTECTED]
-
-
GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjpnYGQACgkQRcGgB3aidfmWBQCfXgNq/vqltt76mApoDiNI9HnH
ws8AoJZ2vvlH1iCAeUu7yktWWN0Bncc3
=gEmD
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
> What if you copy both 'filename' and 'filename:ext' onto the same fs? > Do they get combined into one file? ON Ext2, you get two files. On NTFS, you get one file, and a stream on that file. > Any semantics by which 'filename:stream' and 'filename' refer to the > same file would be b0rken. If instead you use 'filename/stream' That does not allow streams on directories, otherwise I agree. -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
"James H. Cloos Jr." wrote: > > Michael> Please read and comment! :) > > There should be some discussion on what to do about filenames which > contain colons in such a setup. Moving a file w/ a colon from a fs > which does not support named streams to one which does should DTRT; > exactly what TRT is should be discussed. It seems that if you move a file with a colon -- "file:colon" -- in the name from Ext2 to "StreamFS," you would end up with a file named "file" with a stream named "colon". When copying back, you would get "file:colon" back. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
"James H. Cloos Jr." wrote: Michael Please read and comment! :) There should be some discussion on what to do about filenames which contain colons in such a setup. Moving a file w/ a colon from a fs which does not support named streams to one which does should DTRT; exactly what TRT is should be discussed. It seems that if you move a file with a colon -- "file:colon" -- in the name from Ext2 to "StreamFS," you would end up with a file named "file" with a stream named "colon". When copying back, you would get "file:colon" back. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
What if you copy both 'filename' and 'filename:ext' onto the same fs? Do they get combined into one file? ON Ext2, you get two files. On NTFS, you get one file, and a stream on that file. Any semantics by which 'filename:stream' and 'filename' refer to the same file would be b0rken. If instead you use 'filename/stream' That does not allow streams on directories, otherwise I agree. -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: O_NONBLOCK, read(), select(), NFS, Ext2, etc.
Alan Cox wrote: > > > using the O_NONBLOCK flag, then read() and write() will always return > > immediately and not block the calling process. This does not appear to > > be true; but perhaps I am doing something wrong. If I open() a file (on > > 2.2.18) from a floppy or NFS mount (to test in a slow environment) with > > O_NONBLOCK|O_RDONLY, read() will still block. If I try to select() on > > the file descriptor, select() always returns 0. > > The definition of immediate is not 'instant'. Otherwise no I/O system would > ever return anything but -EWOULDBLOCK. Its that it won't wait when there is > no data pending. On a floppy there is always data pending How about using fcntl(), O_ASYNC and SIGIO? Or maybe a broader question: what's the preferred/working way to do async file i/o on Linux? -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: O_NONBLOCK, read(), select(), NFS, Ext2, etc.
Alan Cox wrote: using the O_NONBLOCK flag, then read() and write() will always return immediately and not block the calling process. This does not appear to be true; but perhaps I am doing something wrong. If I open() a file (on 2.2.18) from a floppy or NFS mount (to test in a slow environment) with O_NONBLOCK|O_RDONLY, read() will still block. If I try to select() on the file descriptor, select() always returns 0. The definition of immediate is not 'instant'. Otherwise no I/O system would ever return anything but -EWOULDBLOCK. Its that it won't wait when there is no data pending. On a floppy there is always data pending How about using fcntl(), O_ASYNC and SIGIO? Or maybe a broader question: what's the preferred/working way to do async file i/o on Linux? -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
O_NONBLOCK, read(), select(), NFS, Ext2, etc.
The man pages for open, read and write say that if a file is opened using the O_NONBLOCK flag, then read() and write() will always return immediately and not block the calling process. This does not appear to be true; but perhaps I am doing something wrong. If I open() a file (on 2.2.18) from a floppy or NFS mount (to test in a slow environment) with O_NONBLOCK|O_RDONLY, read() will still block. If I try to select() on the file descriptor, select() always returns 0. Is there a way to make open(), read() and write() live up to their manpages? -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
CORRECTION: > existing, widely-deployed filesystems (e.g., NFS, XFS, BeFS, HFS, etc.), NTFS---^ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
named streams, extended attributes, and posix
Now that 2.4 is out, it will probably be a few .x releases until 2.5 begins. A discussion on Named Streams and Extended Attributes was put off until 2.5 earlier in the 2.4 development cycle. For compatibility with existing, widely-deployed filesystems (e.g., NFS, XFS, BeFS, HFS, etc.), Linux needs a standard way to expose and interact with these filesystem features. A draft of a paper proposing a methd for accomplishing this on Posix systems is available at: http://www.flyingbuttmonkeys.com/streams-on-posix.txt http://www.flyingbuttmonkeys.com/streams-on-posix.pdf Please read and comment! :) -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
named streams, extended attributes, and posix
Now that 2.4 is out, it will probably be a few .x releases until 2.5 begins. A discussion on Named Streams and Extended Attributes was put off until 2.5 earlier in the 2.4 development cycle. For compatibility with existing, widely-deployed filesystems (e.g., NFS, XFS, BeFS, HFS, etc.), Linux needs a standard way to expose and interact with these filesystem features. A draft of a paper proposing a methd for accomplishing this on Posix systems is available at: http://www.flyingbuttmonkeys.com/streams-on-posix.txt http://www.flyingbuttmonkeys.com/streams-on-posix.pdf Please read and comment! :) -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
CORRECTION: existing, widely-deployed filesystems (e.g., NFS, XFS, BeFS, HFS, etc.), NTFS---^ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
O_NONBLOCK, read(), select(), NFS, Ext2, etc.
The man pages for open, read and write say that if a file is opened using the O_NONBLOCK flag, then read() and write() will always return immediately and not block the calling process. This does not appear to be true; but perhaps I am doing something wrong. If I open() a file (on 2.2.18) from a floppy or NFS mount (to test in a slow environment) with O_NONBLOCK|O_RDONLY, read() will still block. If I try to select() on the file descriptor, select() always returns 0. Is there a way to make open(), read() and write() live up to their manpages? -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Journaling: Surviving or allowing unclean shutdown?
> On Wed, 3 Jan 2001, Dr. David Gilbert wrote: > > > I got wondering as to whether the various journaling file > > system activities were designed to survive the occasional > > unclean shutdown or were designed to allow the user to just pull > > the plug as a regular means of shutting down. > > > Thoughts? Journaling filesystems only guarantee consistancy of filesystem metadata. Data that has not been flushed from buffers will be lost, and applications not given a chance to shut themselves down may do bad things if you just unplug the box. Journaling mostly means not having to run FSCK. -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Journaling: Surviving or allowing unclean shutdown?
On Wed, 3 Jan 2001, Dr. David Gilbert wrote: I got wondering as to whether the various journaling file system activities were designed to survive the occasional unclean shutdown or were designed to allow the user to just pull the plug as a regular means of shutting down. Thoughts? Journaling filesystems only guarantee consistancy of filesystem metadata. Data that has not been flushed from buffers will be lost, and applications not given a chance to shut themselves down may do bad things if you just unplug the box. Journaling mostly means not having to run FSCK. -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: high load & poor interactivity on fast thread creation
Ruth Ivimey-Cook wrote: > No. Java on NT uses proper NT threads. However, a thread on NT is a rather > different beast to a cloned thread on Linux. I don't know whether the > differences are important. On Linux, threads are processes. On NT, processes are distinct from threads, and usually have at least one thread within them. On Linux, the process and the initial (sole) thread are the same thing. On NT, they are distinct. CreateProcess() creates a process and its initial thread (because that is what you would expect to happen). On Linux, clone() creates a new process; sometimes that process can be construed as a thread, because of shared memory, file descriptors, or whatever. On NT, because a process contains threads and is not itself a thread, you can use CreateProcess() to create a process whose only thread is suspended. I don't know if that kind of thing is possible with clone(). You might have to clone() then suspend. You use CreateThread() to create more threads inside an existing process. CreateRemoteThread() creates new threads inside a different process. A process is more of a virtual memory environment and container for threads than a context of execution itself. With clone() on Linux you can mimic a lot of the behavior of NT processes and threads, but not all of it. One notable difference between Linux and NT threads and processes is that it is more expensive to create new processes on NT than on Linux, and on NT thread creation is cheaper than process creation. Typically Windows programs use multiple threads rather than multiple processes, whereas on Unix the reverse is true. http://www.byte.com/art/9511/sec11/art3.htm http://msdn.microsoft.com/library/winresource/dnwinnt/S7FC7.HTM http://msdn.microsoft.com/library/psdk/winbase/prothred_9dpv.htm http://msdn.microsoft.com/library/psdk/winbase/prothred_4084.htm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: high load poor interactivity on fast thread creation
Ruth Ivimey-Cook wrote: No. Java on NT uses proper NT threads. However, a thread on NT is a rather different beast to a cloned thread on Linux. I don't know whether the differences are important. On Linux, threads are processes. On NT, processes are distinct from threads, and usually have at least one thread within them. On Linux, the process and the initial (sole) thread are the same thing. On NT, they are distinct. CreateProcess() creates a process and its initial thread (because that is what you would expect to happen). On Linux, clone() creates a new process; sometimes that process can be construed as a thread, because of shared memory, file descriptors, or whatever. On NT, because a process contains threads and is not itself a thread, you can use CreateProcess() to create a process whose only thread is suspended. I don't know if that kind of thing is possible with clone(). You might have to clone() then suspend. You use CreateThread() to create more threads inside an existing process. CreateRemoteThread() creates new threads inside a different process. A process is more of a virtual memory environment and container for threads than a context of execution itself. With clone() on Linux you can mimic a lot of the behavior of NT processes and threads, but not all of it. One notable difference between Linux and NT threads and processes is that it is more expensive to create new processes on NT than on Linux, and on NT thread creation is cheaper than process creation. Typically Windows programs use multiple threads rather than multiple processes, whereas on Unix the reverse is true. http://www.byte.com/art/9511/sec11/art3.htm http://msdn.microsoft.com/library/winresource/dnwinnt/S7FC7.HTM http://msdn.microsoft.com/library/psdk/winbase/prothred_9dpv.htm http://msdn.microsoft.com/library/psdk/winbase/prothred_4084.htm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: iptables: "stateful inspection?"
Felix von Leitner wrote: > > > IPChains is essentially useless as a firewall due to its lack of > > stateful packet filering. > > Bullshit. > Go back to the bowels or Redmond where you belong, luser. Thanks. I appreciate that. -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: iptables: stateful inspection?
Felix von Leitner wrote: IPChains is essentially useless as a firewall due to its lack of stateful packet filering. Bullshit. Go back to the bowels or Redmond where you belong, luser. Thanks. I appreciate that. -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: iptables: "stateful inspection?"
Alan Cox wrote: > There have been at least five holes found in pile that _could_ have been > [speech] > safe is the day you end up hurt. Your specific example of an executable (windows) attachment, not buffer overflows, etc. what what I was replying to. In general, you are correct. Now, how about including that procfs cleanup patch that I sent, and maybe the 64-bit printk patch? :) -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: iptables: "stateful inspection?"
Alan Cox wrote: > It does SYN checking. If you are running 'serious' security you wouldnt be > allowing outgoing connections anyway. One windows christmascard.exe virus that > connects back to an irc server to take input and you are hosed. Thankfully, pine and mutt are, to date, immune to that kind of thing. :) -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
