Tried to boot using SLUB under lguest with 2.6.21-mm2. Got the
following:
...
[0.388000] NET: Registered protocol family 17
[0.388000] Using IPI Shortcut mode
[0.42] EXT2-fs warning: mounting unchecked fs, running e2fsck
is recommended
[0.42] VFS: Mounted root (ext2
Tried to boot using SLUB under lguest with 2.6.21-mm2. Got the
following:
...
[0.388000] NET: Registered protocol family 17
[0.388000] Using IPI Shortcut mode
[0.42] EXT2-fs warning: mounting unchecked fs, running e2fsck
is recommended
[0.42] VFS: Mounted root (ext2
On 8 Jun 2001, Linus Torvalds wrote:
> The basic issue is that the kernel will _refuse_ to follow the
> "namespace of the day" rules of C89, C99, POSIX, BSD, SuS, GNU .. the
> list goes on. The kernel headers are not meant to be used in user space,
> and will not have the strict namespace rules
On 8 Jun 2001, Linus Torvalds wrote:
The basic issue is that the kernel will _refuse_ to follow the
namespace of the day rules of C89, C99, POSIX, BSD, SuS, GNU .. the
list goes on. The kernel headers are not meant to be used in user space,
and will not have the strict namespace rules that a
On Wed, 30 May 2001, David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > drivers/mtd/docprobe.c:195:DoC_Probe: ERROR:INIT: non-init fn
> > 'DoC_Probe' calling init fn 'doccheck'
>
> Strictly speaking, not actually a bug. DoC_Probe() itself is only ever
> called from __init code. But it's
On Wed, 30 May 2001, David Woodhouse wrote:
[EMAIL PROTECTED] said:
drivers/mtd/docprobe.c:195:DoC_Probe: ERROR:INIT: non-init fn
'DoC_Probe' calling init fn 'doccheck'
Strictly speaking, not actually a bug. DoC_Probe() itself is only ever
called from __init code. But it's probably not
On Thu, 24 May 2001, Marko Kreen wrote:
> On Thu, May 24, 2001 at 02:23:27AM +0200, Edgar Toernig wrote:
> > Daniel Phillips wrote:
> > > > > It's going to be marked 'd', it's a directory, not a file.
> > > >
> > > > Aha. So you lose the S_ISCHR/BLK attribute.
> > >
> > > Readdir fills in a
On Thu, 24 May 2001, Marko Kreen wrote:
On Thu, May 24, 2001 at 02:23:27AM +0200, Edgar Toernig wrote:
Daniel Phillips wrote:
It's going to be marked 'd', it's a directory, not a file.
Aha. So you lose the S_ISCHR/BLK attribute.
Readdir fills in a directory type, so ls
On Wed, 23 May 2001, Daniel Phillips wrote:
> > > > *boggle*
> > > >
> > > >[general sense of unease]
> >
> > I fully agree with Oliver. It's an abomination.
>
> We are, or at least, I am, investigating this question purely on
> technical grounds - name calling is a noop. I'd be happy to find
On Wed, 23 May 2001, Daniel Phillips wrote:
*boggle*
[general sense of unease]
I fully agree with Oliver. It's an abomination.
We are, or at least, I am, investigating this question purely on
technical grounds - name calling is a noop. I'd be happy to find a
real reason why
On Tue, 22 May 2001, Guest section DW wrote:
> On Tue, May 22, 2001 at 11:08:16AM -0500, Oliver Xymoron wrote:
>
> > > >+ struct list_headhash;
>
> > > Why not name consistently with the struct block_device?
> > > struct list_
On Tue, 22 May 2001, Daniel Phillips wrote:
> > I don't think it's likely to be even workable. Just consider the
> > directory entry for a moment - is it going to be marked d or [cb]?
>
> It's going to be marked 'd', it's a directory, not a file.
Are we talking about the same proposal? The one
On Tue, 22 May 2001, Alexander Viro wrote:
> On Tue, 22 May 2001, Oliver Xymoron wrote:
>
> > Because foo_ is a throwback to the days when C compilers had a single
> > namespace for all structure elements, not a readability aid. If you need
> > foo_ to know what type of
On Tue, 22 May 2001, Anton Altaparmakov wrote:
> Hello,
>
> At 15:18 22/05/01, Alexander Viro wrote:
> [snip cool stuff]
> >+struct char_device {
> >+ struct list_headhash;
> >+ atomic_tcount;
> >+ dev_t dev;
> >+ atomic_t
On Mon, 21 May 2001, Alexander Viro wrote:
> On Mon, 21 May 2001, Linus Torvalds wrote:
>
> > It shouldn't be impossible to do the same thing to ioctl numbers. Nastier,
> > yes. No question about it. But we don't necessarily have to redesign the
> > whole approach - we only want to re-design the
On Mon, 21 May 2001, Daniel Phillips wrote:
> On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
> > What I'd like to see:
> >
> > - An interface for registering an array of related devices (almost
> > always two: raw and ctl) and their legacy device numbers with a
&
On Mon, 21 May 2001, Daniel Phillips wrote:
On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
What I'd like to see:
- An interface for registering an array of related devices (almost
always two: raw and ctl) and their legacy device numbers with a
single userspace callout that does
On Mon, 21 May 2001, Alexander Viro wrote:
On Mon, 21 May 2001, Linus Torvalds wrote:
It shouldn't be impossible to do the same thing to ioctl numbers. Nastier,
yes. No question about it. But we don't necessarily have to redesign the
whole approach - we only want to re-design the
On Tue, 22 May 2001, Anton Altaparmakov wrote:
Hello,
At 15:18 22/05/01, Alexander Viro wrote:
[snip cool stuff]
+struct char_device {
+ struct list_headhash;
+ atomic_tcount;
+ dev_t dev;
+ atomic_t
On Tue, 22 May 2001, Alexander Viro wrote:
On Tue, 22 May 2001, Oliver Xymoron wrote:
Because foo_ is a throwback to the days when C compilers had a single
namespace for all structure elements, not a readability aid. If you need
foo_ to know what type of structure you're futzing
On Tue, 22 May 2001, Guest section DW wrote:
On Tue, May 22, 2001 at 11:08:16AM -0500, Oliver Xymoron wrote:
+ struct list_headhash;
Why not name consistently with the struct block_device?
struct list_headcd_hash;
Because foo_ is a throwback
On Tue, 22 May 2001, Daniel Phillips wrote:
I don't think it's likely to be even workable. Just consider the
directory entry for a moment - is it going to be marked d or [cb]?
It's going to be marked 'd', it's a directory, not a file.
Are we talking about the same proposal? The one where
On Mon, 21 May 2001, Alexander Viro wrote:
> On Mon, 21 May 2001, Oliver Xymoron wrote:
>
> > K - so what? I'm guessing what you want me to see is that these
> > implement multiple channels. Is there a reason that eia001stat couldn't be
> > implemented as
> >
>
On Mon, 21 May 2001, Alexander Viro wrote:
> On Mon, 21 May 2001, Oliver Xymoron wrote:
>
> > If you've got side channels that are of a packet nature (aka commands),
> > then they can all happily coexist on one device. If you've got channels
> > that are streams or intend
ake sense. Opening a floppy at
different densities with magic filenames was an example Linus used earlier
in the thread. Surely there can be more than one drive and more than one
serial port.
> On Mon, 21 May 2001, Oliver Xymoron wrote:
>
> > On Sat, 19 May 2001, Alexander Viro wrote:
On Sun, 20 May 2001, Alexander Viro wrote:
> On Sun, 20 May 2001, Abramo Bagnara wrote:
>
> > > It may have several. Which one?
> >
> > Can you explain better this?
>
> Example: console. You want to be able to pass font changes. I'm
> less than sure that putting them on the same channel as,
On Sat, 19 May 2001, Jeff Garzik wrote:
> Why are LVM and EVMS(competing LVM project) needed at all?
>
> Surely the same can be accomplished with
> * md
> * snapshot blkdev (attached in previous e-mail)
> * giving partitions and blkdevs the ability to grow and shrink
> * giving filesystems the
On Sat, 19 May 2001, Alexander Viro wrote:
> Let's distinguish between per-fd effects (that's what name in
> open(name, flags) is for - you are asking for descriptor and telling
> what behaviour do you want for IO on it) and system-wide side effects.
>
> IMO encoding the former into name is
On Sun, 20 May 2001, Alexander Viro wrote:
On Sun, 20 May 2001, Abramo Bagnara wrote:
It may have several. Which one?
Can you explain better this?
Example: console. You want to be able to pass font changes. I'm
less than sure that putting them on the same channel as, e.g.,
keyboard
On Mon, 21 May 2001, Alexander Viro wrote:
On Mon, 21 May 2001, Oliver Xymoron wrote:
If you've got side channels that are of a packet nature (aka commands),
then they can all happily coexist on one device. If you've got channels
that are streams or intended for mmap, those ought
On Mon, 21 May 2001, Alexander Viro wrote:
On Mon, 21 May 2001, Oliver Xymoron wrote:
K - so what? I'm guessing what you want me to see is that these
implement multiple channels. Is there a reason that eia001stat couldn't be
implemented as
f=open(/dev/eia001ctl,O_RDWR);
write(f
sense. Opening a floppy at
different densities with magic filenames was an example Linus used earlier
in the thread. Surely there can be more than one drive and more than one
serial port.
On Mon, 21 May 2001, Oliver Xymoron wrote:
On Sat, 19 May 2001, Alexander Viro wrote:
Let's distinguish
On Sat, 19 May 2001, Jeff Garzik wrote:
Why are LVM and EVMS(competing LVM project) needed at all?
Surely the same can be accomplished with
* md
* snapshot blkdev (attached in previous e-mail)
* giving partitions and blkdevs the ability to grow and shrink
* giving filesystems the ability
On Sat, 19 May 2001, Alexander Viro wrote:
Let's distinguish between per-fd effects (that's what name in
open(name, flags) is for - you are asking for descriptor and telling
what behaviour do you want for IO on it) and system-wide side effects.
IMO encoding the former into name is perfectly
It seems to me that Linus' idea of making device nodes work like
directories is a little too clever and probably overkill but the only
alternative I've seen suggested is Al's per-device filesystems which seems
similarly excessive.
Few devices will have a need for multiple streamable interfaces
It seems to me that Linus' idea of making device nodes work like
directories is a little too clever and probably overkill but the only
alternative I've seen suggested is Al's per-device filesystems which seems
similarly excessive.
Few devices will have a need for multiple streamable interfaces
On Sat, 14 Apr 2001, Eric S. Raymond wrote:
> > * the colors are hard to see (red/blue on black). Probably
> > matter of terminal settings. I do not have any productive
> > ideas tho... Probably to get best experience to as much
> > people as possible the less colors are used the
On Sat, 14 Apr 2001, Eric S. Raymond wrote:
* the colors are hard to see (red/blue on black). Probably
matter of terminal settings. I do not have any productive
ideas tho... Probably to get best experience to as much
people as possible the less colors are used the better.
On Mon, 9 Apr 2001, Alan Cox wrote:
> > > Its worth doing even on the ancient x86 boards with the PIT.
> >
> > Note that programming the PIT is slw and doing it on every timer
> > add_timer/del_timer would be a pain.
>
> You only have to do it occasionally.
>
> When you add a timer newer
On Mon, 9 Apr 2001, Alan Cox wrote:
Its worth doing even on the ancient x86 boards with the PIT.
Note that programming the PIT is slw and doing it on every timer
add_timer/del_timer would be a pain.
You only have to do it occasionally.
When you add a timer newer than the
On Mon, 2 Apr 2001, Jeff Garzik wrote:
> Oliver Xymoron wrote:
> > On Mon, 2 Apr 2001, Tom Leete wrote:
> > > How about /lib/modules/$(uname -r)/build/.config ? It's already there.
>
> > It'd be great if we got away from the config being hidden too.
>
> When exp
On Mon, 2 Apr 2001, Tom Leete wrote:
> Oliver Xymoron wrote:
> >
> > On Sun, 1 Apr 2001, Jeff Garzik wrote:
> >
> > > On Sun, 1 Apr 2001, David Lang wrote:
> > > > if we want to get the .config as part of the report then we need to make
> > > &g
On Sun, 1 Apr 2001, Jeff Garzik wrote:
> On Sun, 1 Apr 2001, David Lang wrote:
> > if we want to get the .config as part of the report then we need to make
> > it part of the kernel in some standard way (the old /proc/config flamewar)
> > it's difficult enough sometimes for the sysadmin of a box
On Sun, 1 Apr 2001, Jeff Garzik wrote:
On Sun, 1 Apr 2001, David Lang wrote:
if we want to get the .config as part of the report then we need to make
it part of the kernel in some standard way (the old /proc/config flamewar)
it's difficult enough sometimes for the sysadmin of a box to
On Mon, 2 Apr 2001, Tom Leete wrote:
Oliver Xymoron wrote:
On Sun, 1 Apr 2001, Jeff Garzik wrote:
On Sun, 1 Apr 2001, David Lang wrote:
if we want to get the .config as part of the report then we need to make
it part of the kernel in some standard way (the old /proc/config
On Mon, 2 Apr 2001, Jeff Garzik wrote:
Oliver Xymoron wrote:
On Mon, 2 Apr 2001, Tom Leete wrote:
How about /lib/modules/$(uname -r)/build/.config ? It's already there.
It'd be great if we got away from the config being hidden too.
When exporting it outside the kernel tree
On Mon, 12 Mar 2001, Keith Owens wrote:
> On Mon, 12 Mar 2001 03:53:07 -0500,
> "Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
> >But if we're going to push Linus and the kernel crew to switch to
> >CML2, then why invite the political tsuris of trying to get a large
> >patch into 2.4 now? Maybe
On Mon, 12 Mar 2001, Keith Owens wrote:
On Mon, 12 Mar 2001 03:53:07 -0500,
"Eric S. Raymond" [EMAIL PROTECTED] wrote:
But if we're going to push Linus and the kernel crew to switch to
CML2, then why invite the political tsuris of trying to get a large
patch into 2.4 now? Maybe I'm missing
On Fri, 9 Mar 2001, Rogier Wolff wrote:
> Quicksort however is an algorithm that is recursive. This means that
> it can use unbounded amounts of stack -> This is not for the kernel.
It is of course bounded by the input size, but yes, it can use O(n)
additional memory in the worst case. There's
On Fri, 9 Mar 2001, Alan Cox wrote:
> > Quicksort works just fine on a linked list, as long as you broaden
> > your view beyond the common array-based implementations. See
> > "http://www.cs.cmu.edu/~jbruce/sort.cc" for an example, although I
> > would recommend using a radix sort for linked
On Fri, 9 Mar 2001, Helge Hafting wrote:
> Manoj Sontakke wrote:
> >
> > 1. Is quicksort on doubly linked list is implemented anywhere? I need it
> > for sk_buff queues.
>
> I cannot see how the quicksort algorithm could work on a doubly
> linked list, as it relies on being able to look
> up
On Fri, 9 Mar 2001, Helge Hafting wrote:
Manoj Sontakke wrote:
1. Is quicksort on doubly linked list is implemented anywhere? I need it
for sk_buff queues.
I cannot see how the quicksort algorithm could work on a doubly
linked list, as it relies on being able to look
up elements
On Fri, 9 Mar 2001, Alan Cox wrote:
Quicksort works just fine on a linked list, as long as you broaden
your view beyond the common array-based implementations. See
"http://www.cs.cmu.edu/~jbruce/sort.cc" for an example, although I
would recommend using a radix sort for linked lists in
On Fri, 9 Mar 2001, Rogier Wolff wrote:
Quicksort however is an algorithm that is recursive. This means that
it can use unbounded amounts of stack - This is not for the kernel.
It is of course bounded by the input size, but yes, it can use O(n)
additional memory in the worst case. There's no
On Thu, 8 Mar 2001, Geert Uytterhoeven wrote:
> Patches (for both 2.4.3-pre3 and 2.4.2-ac14) can be downloaded from:
>
> http://home.tvd.be/cr26864/Linux/fbdev/logo.html
>
> This page also shows the old and new logos, and includes a tool to extract
> logos in PNM format from the kernel
On Wed, 7 Mar 2001, Ben Greear wrote:
> For the power/insane user, there could be a --really-do-stupid-thing-i-told-you-to
> option, and it should be that hard to type!!
There is, though historically it's undocumented. It's called "root
password".
Pause. Reflect.
--
"Love the dolphins," she
On Wed, 7 Mar 2001, Rik van Riel wrote:
> I've taken today to write some documentation for
> include/linux/mm.h, as used in 2.4.x
Mostly good.
> + pgprot_t vm_page_prot; /* Access permissions of this VMA. */
But a lot of the comments are trivial = deadweight. Comments are best
On Wed, 7 Mar 2001, Rik van Riel wrote:
I've taken today to write some documentation for
include/linux/mm.h, as used in 2.4.x
Mostly good.
+ pgprot_t vm_page_prot; /* Access permissions of this VMA. */
But a lot of the comments are trivial = deadweight. Comments are best used
On Thu, 8 Mar 2001, Geert Uytterhoeven wrote:
Patches (for both 2.4.3-pre3 and 2.4.2-ac14) can be downloaded from:
http://home.tvd.be/cr26864/Linux/fbdev/logo.html
This page also shows the old and new logos, and includes a tool to extract
logos in PNM format from the kernel sources (in
On Fri, 2 Mar 2001, David S. Miller wrote:
> > On PPC, we don't have an "IO" space neither, all we have is a range of
> > memory addresses that will cause IO cycles to happen on the PCI bus.
>
> This is precisely what the "next MMAP is XXX space" ioctl I've
> suggested is for. I think I've
On Fri, 2 Mar 2001, David S. Miller wrote:
On PPC, we don't have an "IO" space neither, all we have is a range of
memory addresses that will cause IO cycles to happen on the PCI bus.
This is precisely what the "next MMAP is XXX space" ioctl I've
suggested is for. I think I've addressed
On Fri, 5 Jan 2001, Alan Cox wrote:
> > Once the comments are unweirded, they become completely superfluous. At
> > which point its best not to have them - when someone next comes along and
> > changes the delay, it might end up disagreeing with the comment and
> > causing confusion.
>
> Before
On Thu, 4 Jan 2001, Marko Kreen wrote:
> On Wed, Jan 03, 2001 at 11:32:52PM +0200, Marko Kreen wrote:
> > -udelay(15000); /* delay for 50 (15) ms */
> > +mdelay(15); /* delay for 50 (15) ms */
>
> Per Mark Hahn suggestion here is a patch that fixes the weird
> comments too. This is
On Thu, 4 Jan 2001, Alexander Viro wrote:
> > I bet it long predates dcache though..
>
> Not too likely. It went in in 2.1.93. Apr 2 1998...
> Dcache was there ~50 versions before that.
Huh. Is there anything that prevents fragmentation in, say, growing
maildirs, where there's nothing but
On Tue, 2 Jan 2001, Rich Baum wrote:
> Here is a patch that removes more compile warnings from 2.4.0-
> prerelease. I left out files that have been fixed by Alan or myself in
> the ac kernels. I'll add more options to my config tomorrow to try to
> find more of these warnings.
> -#endif
On Wed, 3 Jan 2001, Alexander Viro wrote:
> On Wed, 3 Jan 2001, Stephen C. Tweedie wrote:
>
> > Having preallocated blocks allocated immediately is deliberate:
> > directories grow slowly and remain closed most of the time, so the
> > normal preallocation regime of only preallocating open files
On Wed, 3 Jan 2001, Alexander Viro wrote:
On Wed, 3 Jan 2001, Stephen C. Tweedie wrote:
Having preallocated blocks allocated immediately is deliberate:
directories grow slowly and remain closed most of the time, so the
normal preallocation regime of only preallocating open files and
On Tue, 2 Jan 2001, Rich Baum wrote:
Here is a patch that removes more compile warnings from 2.4.0-
prerelease. I left out files that have been fixed by Alan or myself in
the ac kernels. I'll add more options to my config tomorrow to try to
find more of these warnings.
-#endif
On Thu, 4 Jan 2001, Alexander Viro wrote:
I bet it long predates dcache though..
Not too likely. checking CVS It went in in 2.1.93. Apr 2 1998...
Dcache was there ~50 versions before that.
Huh. Is there anything that prevents fragmentation in, say, growing
maildirs, where there's nothing
On Sun, 31 Dec 2000, Oliver Xymoron wrote:
> My VAIO PCG-Z505SX locks up at "Uncompressing kernel", power cycling
> required to reboot. Unpatched test12 works fine with same config. System
> is debian-testing with gcc 2.95.2, kernel built with make-kpkg.
Ok, I lied. Loo
a few as well.
Considering that the rest of the code is already in the standard kernel
and appears to work, there's no reason not to make it available.
> On Sun, Dec 31, 2000 at 11:50:14AM -0600, Oliver Xymoron wrote:
> > This patchlet lets me use my HP CDRW.
> >
> > --- linux/dr
My VAIO PCG-Z505SX locks up at "Uncompressing kernel", power cycling
required to reboot. Unpatched test12 works fine with same config. System
is debian-testing with gcc 2.95.2, kernel built with make-kpkg.
BTW, my USB camera (Canon S100), controlled through usbdevfs with gphoto2,
stopped working
This patchlet lets me use my HP CDRW.
--- linux/drivers/usb/Config.in~Mon Nov 27 20:10:35 2000
+++ linux/drivers/usb/Config.in Tue Dec 19 12:21:56 2000
@@ -32,6 +32,9 @@
if [ "$CONFIG_USB_STORAGE" != "n" ]; then
bool 'USB Mass Storage verbose debug'
This patchlet lets me use my HP CDRW.
--- linux/drivers/usb/Config.in~Mon Nov 27 20:10:35 2000
+++ linux/drivers/usb/Config.in Tue Dec 19 12:21:56 2000
@@ -32,6 +32,9 @@
if [ "$CONFIG_USB_STORAGE" != "n" ]; then
bool 'USB Mass Storage verbose debug'
My VAIO PCG-Z505SX locks up at "Uncompressing kernel", power cycling
required to reboot. Unpatched test12 works fine with same config. System
is debian-testing with gcc 2.95.2, kernel built with make-kpkg.
BTW, my USB camera (Canon S100), controlled through usbdevfs with gphoto2,
stopped working
as well.
Considering that the rest of the code is already in the standard kernel
and appears to work, there's no reason not to make it available.
On Sun, Dec 31, 2000 at 11:50:14AM -0600, Oliver Xymoron wrote:
This patchlet lets me use my HP CDRW.
--- linux/drivers/usb/Config.in~Mon Nov 27
On Sun, 31 Dec 2000, Oliver Xymoron wrote:
My VAIO PCG-Z505SX locks up at "Uncompressing kernel", power cycling
required to reboot. Unpatched test12 works fine with same config. System
is debian-testing with gcc 2.95.2, kernel built with make-kpkg.
Ok, I lied. Looks like the workin
On Tue, 19 Dec 2000, Russell King wrote:
> Oliver Xymoron writes:
> > On Mon, 18 Dec 2000, Russell King wrote:
> > > So, why don't we update the hours and be done with it? We would have to
> > > play the same game with the days of the month vs hours. Also, we don't
&
On Mon, 18 Dec 2000, Russell King wrote:
> Matthew Dharm writes:
> > Ahh... I think I see. While the math says "if the diference between the
> > real time and the cmos time is less than 30 min", it doesn't recognize that
> > the time difference between 2:59 and 3:00 is only 1 min.
>
> Which is
On Mon, 18 Dec 2000, Russell King wrote:
Matthew Dharm writes:
Ahh... I think I see. While the math says "if the diference between the
real time and the cmos time is less than 30 min", it doesn't recognize that
the time difference between 2:59 and 3:00 is only 1 min.
Which is
On Tue, 19 Dec 2000, Russell King wrote:
Oliver Xymoron writes:
On Mon, 18 Dec 2000, Russell King wrote:
So, why don't we update the hours and be done with it? We would have to
play the same game with the days of the month vs hours. Also, we don't
know if the CMOS clock
On Fri, 15 Dec 2000, Stephen Frost wrote:
> * Oliver Xymoron ([EMAIL PROTECTED]) wrote:
> > On Thu, 14 Dec 2000, Linus Torvalds wrote:
> >
> > > A 100ms delay sounds like some interrupt shut up or similar (and then
> > > timer handling makes it limp along).
&
On Fri, 15 Dec 2000, Stephen Frost wrote:
* Oliver Xymoron ([EMAIL PROTECTED]) wrote:
On Thu, 14 Dec 2000, Linus Torvalds wrote:
A 100ms delay sounds like some interrupt shut up or similar (and then
timer handling makes it limp along).
Possibly related datapoint: after several
On Thu, 14 Dec 2000, Linus Torvalds wrote:
> On Thu, 14 Dec 2000, Stephen Frost wrote:
> >
> > Any idea if these issues would cause a general slow-down of a
> > machine? For no apparent reason after 5 days running 2.4.0test12
> > everything going through my firewall (set up using iptables)
On Thu, 14 Dec 2000, Linus Torvalds wrote:
On Thu, 14 Dec 2000, Stephen Frost wrote:
Any idea if these issues would cause a general slow-down of a
machine? For no apparent reason after 5 days running 2.4.0test12
everything going through my firewall (set up using iptables) I got
On Wed, 22 Nov 2000, Alan Cox wrote:
> > > |> > > #define __bad_udelay() panic("Udelay called with too large a constant")
> > > |>
> > > |> Can't we change that to :
> > > |> #error "Udelay..."
> > >
> > > No.
> >
> > ?? I think I'm missing something here.
>
> preprocessor stuff is done too
On Wed, 22 Nov 2000, Matti Aarnio wrote:
> On Tue, Nov 21, 2000 at 11:34:45PM +0100, Tobias Ringstrom wrote:
> > The subject says it all. Is there any particular (technical) reason
> > why I must have both the generic pcmcia code and the controller support
> > built-in, or build all of them as
On Tue, 21 Nov 2000, Tigran Aivazian wrote:
> On 21 Nov 2000, Jes Sorensen wrote:
>
> > > "Tigran" == Tigran Aivazian <[EMAIL PROTECTED]> writes:
> >
> > Tigran> Hi, Some processes get stuck in page fault handler for ages
> > Tigran> (like for 10 minutes!). The machine still has plenty
On Tue, 21 Nov 2000, Tigran Aivazian wrote:
On 21 Nov 2000, Jes Sorensen wrote:
"Tigran" == Tigran Aivazian [EMAIL PROTECTED] writes:
Tigran Hi, Some processes get stuck in page fault handler for ages
Tigran (like for 10 minutes!). The machine still has plenty (3.5G) of
Tigran
On Wed, 22 Nov 2000, Matti Aarnio wrote:
On Tue, Nov 21, 2000 at 11:34:45PM +0100, Tobias Ringstrom wrote:
The subject says it all. Is there any particular (technical) reason
why I must have both the generic pcmcia code and the controller support
built-in, or build all of them as modules?
On Wed, 22 Nov 2000, Alan Cox wrote:
| #define __bad_udelay() panic("Udelay called with too large a constant")
|
| Can't we change that to :
| #error "Udelay..."
No.
?? I think I'm missing something here.
preprocessor stuff is done too early for this
You could
On Mon, 6 Nov 2000, Jeff Garzik wrote:
> Oliver Xymoron wrote:
> >
> > On Mon, 6 Nov 2000, David Woodhouse wrote:
> >
> > > The point here is that although I've put up with just keeping the sound
> > > driver loaded for the last few years, permanentl
On Mon, 6 Nov 2000, David Woodhouse wrote:
> The point here is that although I've put up with just keeping the sound
> driver loaded for the last few years, permanently taking up a large amount
> of DMA memory, the inter_module_xxx stuff that Keith is proposing would
> give us a simple way of
On Mon, 6 Nov 2000, David Woodhouse wrote:
The point here is that although I've put up with just keeping the sound
driver loaded for the last few years, permanently taking up a large amount
of DMA memory, the inter_module_xxx stuff that Keith is proposing would
give us a simple way of
On Mon, 6 Nov 2000, David Woodhouse wrote:
> On Mon, 6 Nov 2000, Oliver Xymoron wrote:
>
> > If I understand you correctly:
> >
> > process 1 process 2
...
>
> > Is there any reason we ever want to unblock process 1 before process 2
> > termi
On Sun, 5 Nov 2000, Barry K. Nathan wrote:
> +CONFIG_INET_ECN
> + Explicit Congestion Notification (ECN) allows routers to notify
> + clients about network congestion, resulting in fewer dropped packets
> + and increased network performance. This option adds ECN support to the
> + Linux
On Mon, 6 Nov 2000, David Woodhouse wrote:
> On Mon, 6 Nov 2000, Oliver Xymoron wrote:
>
> > Hopefully not. The standard examples (mixer levels, etc) are better
> > handled with a userspace tool hooked by modprobe. This even gets
> > persistence across reboots
On Mon, 6 Nov 2000, Keith Owens wrote:
> What do people think, do we need module persistent storage?
Hopefully not. The standard examples (mixer levels, etc) are better
handled with a userspace tool hooked by modprobe. This even gets
persistence across reboots if that's what's wanted.
--
On Mon, 6 Nov 2000, Keith Owens wrote:
What do people think, do we need module persistent storage?
Hopefully not. The standard examples (mixer levels, etc) are better
handled with a userspace tool hooked by modprobe. This even gets
persistence across reboots if that's what's wanted.
--
"Love
On Mon, 6 Nov 2000, David Woodhouse wrote:
On Mon, 6 Nov 2000, Oliver Xymoron wrote:
Hopefully not. The standard examples (mixer levels, etc) are better
handled with a userspace tool hooked by modprobe. This even gets
persistence across reboots if that's what's wanted.
Implement
1 - 100 of 138 matches
Mail list logo
