On Sat, 7 Oct 2000, Mike A. Harris wrote:
> After the problems I experienced though, I wondered just how many
> problems would I be in for if I bought a brand new Athlon 800
> system? Would it run like a P100 due to lack of Linux hardware
> support? After reading stuff on lkml here, I'm startin
On Mon, 9 Oct 2000, Guest section DW wrote:
> > -static inline struct user_struct *uid_hash_find(uid_t uid, unsigned int hashent)
> > +static inline struct user_struct *uid_hash_find(unsigned short uid, unsigned int
>hashent)
>
> Your labeling is confusing. linux.vanilla? linux-2.4.0-test9?
> W
Hi Rik,
Rik van Riel <[EMAIL PROTECTED]> writes:
>
> I have the idea we should really fix this dirty accounting
> thing and properly account kapmd time to idle time.
I got thinking about this and think I went slightly insane :-)
How does the following look ... it makes kapmd equivalent to
the
[1.] One line summary of the problem:
Can't boot compaq proliant 7000 with 2.4.0-test9
[2.] Full description of the problem/report:
I upgraded kernel version 2.2.12(redhat 6.0) to 2.4.0-test9.
It was only kernel upgrade.
Can't boot compaq proliant 7000 (Intel P-III 5
[EMAIL PROTECTED] wrote:
> 4. Boot Time Failures
[...]
> * IBM Thinkpad 390 won't boot since 2.3.11 (See Decklin Foster for
>more info)
I _highly_ suspect that this is not a 2.4 bug but is instead user error.
I've seen it several times.
On all kernel versions prior to 2.3.11 if you
On Sun, 8 Oct 2000, David Ford wrote:
> > > Linux 2.4 Status/TODO Page
> > > * RTL 8139 cards sometimes stop responding.
> > (2.2.18pre) Both drivers oops a lot for me, so there seems to be a more
> > serious problem here.
> This is the 2.4 status/todo page, see t
Simon Richter wrote:
> On Mon, 9 Oct 2000 [EMAIL PROTECTED] wrote:
>
> > Linux 2.4 Status/TODO Page
>
> > * RTL 8139 cards sometimes stop responding. Both drivers don't
> >handle this quite good enough yet. (reported by Rogier Wolff,
> >tentatively re
On Mon, 9 Oct 2000 [EMAIL PROTECTED] wrote:
> Linux 2.4 Status/TODO Page
> * RTL 8139 cards sometimes stop responding. Both drivers don't
>handle this quite good enough yet. (reported by Rogier Wolff,
>tentatively reported as fixed by David Ford.)
(
On Mon, Oct 09, 2000 at 05:21:19AM +0200, Daniel Phillips wrote:
> "Albert D. Cahalan" wrote:
> >
> > > The main goal is to encourage NetApp management to do the right thing.
> >
> > They are required to run the business in a profit seeking manner.
> > I think they can even go to jail... so "do
[EMAIL PROTECTED] said:
> __restore(): 764
> do_execve:340
> load_elf_binary: 324
> segv: 180
> sigio_handler:176
> load_script: 172
> ext2_get_block: 160
> set_signals: 156
> block_read_full_page: 124
There's nothing re
OK, I've finally caught up (mostly) with my e-mail since Linux
Kongress. So, here's an updated 2.4 TODO list.This list hasn't been
updated on Sourceforge yet, because the sshd on shells1.sourceforge.net
is failing to let anyone in, and it hasn't been fixed yet.
There are probably a few bugs
On Mon, 09 Oct 2000 14:35:45 +1100,
Keith Owens <[EMAIL PROTECTED]> wrote:
>Solution 2:
>
>struct isapnp_card_id {
> unsigned short card_vendor, card_device;
> unsigned long driver_data; /* data private to the driver */
> struct {
> unsigned short vendor, func
On Sun, 8 Oct 2000 23:50:43 +0200 (MEST),
Jaroslav Kysela <[EMAIL PROTECTED]> wrote:
> this patch contains following fixes and enhancements to export ISA
>PnP IDs outside the kernel module:
>
>* module.h - added MODULE_GENERIC_TABLE
>* isapnp.h - added 'struct isapnp_device_id' for single d
Hello Kernel World
Would someone please tell me where to find docs on the PCI kernel
functions (specifically for 2.2 and 2.4 kernels)?
Thanks,
Daniel
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
"Albert D. Cahalan" wrote:
>
> > The main goal is to encourage NetApp management to do the right thing.
>
> They are required to run the business in a profit seeking manner.
> I think they can even go to jail... so "do the right thing" is not
> an option for them.
Rubbish. By this argument, th
On Mon, Oct 09, 2000 at 02:45:54AM +0100, Kenn Humborg wrote:
> On Mon, Oct 09, 2000 at 02:21:09AM +0100, Kenn Humborg wrote:
> > On Mon, Oct 09, 2000 at 02:20:27AM +0200, Andi Kleen wrote:
> > > 2.4 TCP code relies on current being valid in a softirq.
> >
> > And what the hell does TCP need curr
On Mon, Oct 09, 2000 at 02:21:09AM +0100, Kenn Humborg wrote:
> On Mon, Oct 09, 2000 at 02:20:27AM +0200, Andi Kleen wrote:
> > 2.4 TCP code relies on current being valid in a softirq.
>
> And what the hell does TCP need current for anyway?
I think the only reference is in tcp_input.c, tcp_data_
On Mon, Oct 09, 2000 at 02:21:09AM +0100, Kenn Humborg wrote:
> On Mon, Oct 09, 2000 at 02:20:27AM +0200, Andi Kleen wrote:
> > 2.4 TCP code relies on current being valid in a softirq.
>
> Well, then as long as Linux guarantees that there is always a
> valid 'current task' on a CPU, then I can s
On Mon, Oct 09, 2000 at 03:17:04AM +0200, Martin Diehl wrote:
> Well, taken together, this doesn't seem to be a big thing to do - probably
> above is a little bit of overkill. Anyway, it would remove two bugs by one
> patch (by allowing to choose which one to have ;-)
>
> Comments? Suggestions? O
On Mon, Oct 09, 2000 at 02:09:49AM +0100, Kenn Humborg wrote:
> > 2.4 TCP code relies on current being valid in a softirq.
> >
> > The m68k port which has a interrupt stack solves the problem by
> > loading current into a global register variable on all kernel entries.
> > x86-64 will likely do
On Mon, Oct 09, 2000 at 02:20:27AM +0200, Andi Kleen wrote:
> 2.4 TCP code relies on current being valid in a softirq.
Well, then as long as Linux guarantees that there is always a
valid 'current task' on a CPU, then I can special-case the
called-from-interrupt case. The previous kernel stack
Hi,
just thinking about the RFC1122 vs. BSD compliance issue wrt error
reporting on unconnected udp sockets i'd like to make a proposal for some
kind of solution:
Synopsis:
Approach to have a default policy whether error reporting on udp
sockets follows the official internet standard from
On Mon, Oct 09, 2000 at 01:02:21AM +0200, Jamie Lokier wrote:
> [EMAIL PROTECTED] wrote:
> > BTW: there is an implicit reference to "current" in smp_processor_id.
>
> Yes I forgot about that. (Self-flagellate). However that is
> architecture specific. If it's not an SMP Vax port, no big deal
On Mon, Oct 09, 2000 at 02:20:27AM +0200, Andi Kleen wrote:
> On Mon, Oct 09, 2000 at 12:30:17AM +0200, Jamie Lokier wrote:
> > Kenn Humborg wrote:
> > > My feeling is that interrupt code has no business calling current(),
> > > but I don't know the kernel well enough to be sure. Is there any
> >
> The main goal is to encourage NetApp management to do the right thing.
They are required to run the business in a profit seeking manner.
I think they can even go to jail... so "do the right thing" is not
an option for them.
You can trade patent licenses for other patent licenses.
You can trad
On Mon, Oct 09, 2000 at 01:45:46AM -0200, Dan Aloni wrote:
>
> I noticed I forgot a ; somewhere there. Here's the right patch:
>
> --- linux-2.4.0-test9/kernel/user.c Mon Oct 9 01:37:35 2000
> +++ linux.vanilla/kernel/user.c Sun Oct 8 22:33:55 2000
> @@ -51,22 +51,18 @@
> *up->pp
"Richard B. Johnson" wrote:
>
> Hello!
>
> Has anybody written a driver for the Western Digital (or similar)
> PCI / Firewire adapter?
>
> If not, I'm going to have to write one. If it doesn't exist yet, should
> the device be a block device or a character device? There are some new
> very-fast
On Mon, Oct 09, 2000 at 12:30:17AM +0200, Jamie Lokier wrote:
> Kenn Humborg wrote:
> > My feeling is that interrupt code has no business calling current(),
> > but I don't know the kernel well enough to be sure. Is there any
> > interrupt-level code that calls current() or is it a design
> > pri
I noticed I forgot a ; somewhere there. Here's the right patch:
--- linux-2.4.0-test9/kernel/user.c Mon Oct 9 01:37:35 2000
+++ linux.vanilla/kernel/user.c Sun Oct 8 22:33:55 2000
@@ -51,22 +51,18 @@
*up->pprev = up->next;
}
-static inline struct user_struct *uid_hash_find(uid_t
On Sun, 8 Oct 2000, Mitchell Blank Jr wrote:
> Dan Aloni wrote:
> >
> > I've been touring around the kernel sources when I stumbled
> > across the uid_hash_find() function (kernel/user.c):
> >
> > static inline struct user_struct *uid_hash_find(unsigned short uid, unsigned int
>hashent)
>
> I
Hello!
Has anybody written a driver for the Western Digital (or similar)
PCI / Firewire adapter?
If not, I'm going to have to write one. If it doesn't exist yet, should
the device be a block device or a character device? There are some new
very-fast disks that now use Firewire so this would seem
Dan Aloni wrote:
>
> I've been touring around the kernel sources when I stumbled
> across the uid_hash_find() function (kernel/user.c):
>
> static inline struct user_struct *uid_hash_find(unsigned short uid, unsigned int
>hashent)
Is it just me, or should that be "uid_t" not "unsigned short"?
[EMAIL PROTECTED] wrote:
> > Yes, on architectures that use current->processor that is an exception
> > to the rule. After all, you know for sure that you're still on the
> > same CPU as the task currently running.
>
> This makes sense. And I wish cpu architects would put a cpu-id
> register som
On Mon, Oct 09, 2000 at 01:02:21AM +0200, Jamie Lokier wrote:
> [EMAIL PROTECTED] wrote:
> > Looking at the [network] code, I don't see any places where "current"
> > is not valid.
> > Got some examples?
>
> Damn I'm being dense tonight. No, that bug was due to calling "current"
> from the wron
On Sun, Oct 08, 2000 at 03:58:55PM -0700, Mitchell Blank Jr wrote:
> [EMAIL PROTECTED] wrote:
> > Looking at the code, I don't see any places where "current" is not valid.
> > Got some examples?
>
> It's not that its invalid, it just doesn't make much sense. It points to
> whatever task happene
[EMAIL PROTECTED] wrote:
> Looking at the [network] code, I don't see any places where "current"
> is not valid.
> Got some examples?
Damn I'm being dense tonight. No, that bug was due to calling "current"
from the wrong process context, not from an invalid context.
(Self-flagellate, self-flagg
On Sat, Oct 07, 2000 at 11:07:18PM -0700, Gerhard Mack wrote:
> [root@innerfire /root]# ifconfig sit0 tunnel ::206.123.31.102
> SIOCSIFDSTADDR: No buffer space available
what are you trying to do with this command? In case you want to set the
IPv4 Endpoint of the Tunnel you should set the IPv4 Ad
There are a few things missing from the x86 setup code in test9
which have been present in 2.2.18pre for a while.
I've forward ported these, and added some extra missing things
and put up a patch at..
ftp.suse.com/pub/people/davej/kernel/2.4/test9/setupfixes-1.diff
It contains..
: Pentium IV d
[EMAIL PROTECTED] wrote:
> Looking at the code, I don't see any places where "current" is not valid.
> Got some examples?
It's not that its invalid, it just doesn't make much sense. It points to
whatever task happened to be running when the interrupt happened. So
any attempt to access it is 99
Looking at the code, I don't see any places where "current" is not valid.
Got some examples?
BTW: there is an implicit reference to "current" in smp_processor_id.
On Mon, Oct 09, 2000 at 12:30:17AM +0200, Jamie Lokier wrote:
> Kenn Humborg wrote:
> > My feeling is that interrupt code has no
On Sun, Oct 08, 2000 at 11:21:01AM -0500, Jeff Dike wrote:
> Also, could you look at the stack pointer at each frame, to see if you are
> encountering any stack hogs in the generic kernel? In a different situation,
> I found devfs putting a 3K structure on the stack.
OK, top candidates on that
On Sun, Oct 08, 2000 at 08:27:24AM -0700, Linus Torvalds wrote:
> Why? Think NUMA. The global freepages number is NOT USABLE. Never will be.
> Because it's fundamentally a non-valid number to use - it has nothing to
> do with any reality, and never will.
>
> This is exactly my argument and beef w
Kenn Humborg wrote:
> My feeling is that interrupt code has no business calling current(),
> but I don't know the kernel well enough to be sure. Is there any
> interrupt-level code that calls current() or is it a design
> principle that it cannot be called?
It's a design principle that you must
Hi,
I am looking for a solution for the following problem.
We have installed some new promise 100 cards and ibm ata 100 disks
on some of the servers, assembled the 2.2.17 + ide + raid kernel.
Since then we had several crashes on those machines, we get lots of
VM: try_to_free_memory_failed for
> +#define MODULE_DEVICE_TABLE(type,name) \
> + MODULE_GENERIC_TABLE(type##_device,name)
It looks like that should be "type##_device_id"...
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read th
On Sun, 08 Oct 2000 16:37:03 safemode wrote:
> I know this passed by the list before but i missed it. How do you get
> ide
> - scsi cdrecording to work again? or is this a cdrecord incompatibility
> issue now? This worked a couple sub-versions ago in test8. anyone
> know?
>
Forgot to menti
On Sun, Oct 08, 2000 at 09:58:15PM +, Frank de Lange wrote:
> Hi'all,
>
> Trying to get nfsroot to work on 2.4.0-test9 with my pegasus-based USB nic, I
> got the following Oops (copied values by hand from screen, this is a diskless
> (iopener) system which does not save logfiles... sorry no c
Hello,
this patch contains following fixes and enhancements to export ISA
PnP IDs outside the kernel module:
* module.h - added MODULE_GENERIC_TABLE
* isapnp.h - added 'struct isapnp_device_id' for single devices
- added ISAPNP_CARD_TABLE for complex devices
* isapnp.c - fixed
Hi,
I dunno for the first poster but unloading ns558 causes
problems for me too (SB 128 PCI gameport). Some dmesg exerpts :
Linux version 2.4.0-test9-rous6
([EMAIL PROTECTED]) (gcc version 2.96 2731
(Red Hat Linux 7.0)) #12 sam oct 7 02:01:57 CEST 2000
[...]
es1371: version v0.26 time 01:
On Fri, 6 Oct 2000, Andi Kleen wrote:
[icmp errors on unconnected udp sockets not passed to application layer]
>
> Alexey Kuznetsov ([EMAIL PROTECTED]) changed it. Ask him why he did it,
> I agree with you that it would make more sense to keep the old behaviour
> (even though it is differing fr
Alexander Viro wrote:
>
> On Sun, 8 Oct 2000, Daniel Phillips wrote:
>
> > Linus Torvalds wrote:
> > > This, btw, is why Linux returns error numbers as -Exxx instead of using
> > > "-1" and "errno" - I dislike the latter enormously.
> >
> > It's not just a matter of disliking it, it's also not r
On Sun, Oct 08, 2000 at 11:21:01AM -0500, Jeff Dike wrote:
> [EMAIL PROTECTED] said:
> > Even with this patch, the overflow is 808 bytes (without the patch
> > it's 1232 bytes).
>
> I was mulling over some other changes that would have saved another 256 bytes,
> but those don't look like they wo
I know this passed by the list before but i missed it. How do you get ide
- scsi cdrecording to work again? or is this a cdrecord incompatibility
issue now? This worked a couple sub-versions ago in test8. anyone know?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Sorry if you received this twice, the first copy was sent to the old
vger address :(((
> "marcelo" == Marcelo de Paula Bezerra <[EMAIL PROTECTED]> writes:
Hi
sorry for the delay (this problem has been posted some
time^Wmonths ago).
marcelo> I have noticed what looks like a
I'd just like to confirm that it's illegal to call current()
from interrupt-handling code.
I'm working on the VAX port and the reason I ask is that the
VAX has separate stack pointers for user, kernel and interrupt
contexts. Therefore, the current = (SP & ~8192) hack will give
completely bogus
Stanislav Meduna writes:
> I am asking this because I am able to get reproducible hard
> lockups with IrCOMM using vanilla 2.4.0-test8. However,
> if I apply the patch-2.4-test6-irda3 from Dag Brattli's
> site, all works fine (well, at least what I have tested),
> so there is probably no need to r
Hi'all,
Trying to get nfsroot to work on 2.4.0-test9 with my pegasus-based USB nic, I
got the following Oops (copied values by hand from screen, this is a diskless
(iopener) system which does not save logfiles... sorry no call trace):
[and, by the way, this is the usb-uhci driver. The other (uhc
On Sun, Oct 08 2000, Linus Torvalds wrote:
>
>
> On Thu, 5 Oct 2000, Torben Mathiasen wrote:
> >
> > This patch is a resend of my other link fix patch that didn't get
> > in test9-pre9. I assume this is because of some other changes
> > to upper layer scsi drivers.
>
> No, I just felt it was t
Henning P. Schmiedehausen wrote:
> >Hey, colour ls is _useful_!
> Use white background Xterm. Come again?
Ugh!
> One of the biggest mistakes RH ever did was happily jumping off _that_
> cliff to follow SuSE.
Colour ls predates both Red Hat and SuSE.
-- Jamie
-
To unsubscribe from this list: se
On Sun, 8 Oct 2000, Daniel Phillips wrote:
> >
> > It's not worth changing at this point, but for future reference it would
> > probably be much preferable to return the error code instead of the
> > horrible "error value through pointer access" method, which is usually
> > rather inefficient t
On Sun, 8 Oct 2000, Daniel Phillips wrote:
> Linus Torvalds wrote:
> > This, btw, is why Linux returns error numbers as -Exxx instead of using
> > "-1" and "errno" - I dislike the latter enormously.
>
> It's not just a matter of disliking it, it's also not reentrant.
??? Yes it is, if pointer
Linus Torvalds wrote:
> This, btw, is why Linux returns error numbers as -Exxx instead of using
> "-1" and "errno" - I dislike the latter enormously.
It's not just a matter of disliking it, it's also not reentrant.
> This is also why the VFS layer tends to use ERR_PTR/PTR_ERR/IS_ERR: it
> makes
Hello,
what is the status of IrDA in the 2.4.0-test* kernels?
I am asking this because I am able to get reproducible hard
lockups with IrCOMM using vanilla 2.4.0-test8. However,
if I apply the patch-2.4-test6-irda3 from Dag Brattli's
site, all works fine (well, at least what I have tested),
so t
I've been touring around the kernel sources when I stumbled
across the uid_hash_find() function (kernel/user.c):
static inline struct user_struct *uid_hash_find(unsigned short uid, unsigned int
hashent)
{
struct user_struct *up, *next;
next = uidhash[hashent];
for (;;)
On Sun, 8 Oct 2000, Russell King wrote:
>
> The only time that minix_new_inode sets *error is if it succeeds! The
> same applies to minix_mknod, minix_mkdir, and minix_symlink. With this
> fixed, the above oops no longer happens. Here is a patch to fix this.
> This makes minix follow the sam
On Sun, 8 Oct 2000, Rik van Riel wrote:
> On Sun, 8 Oct 2000, Rui Sousa wrote:
>
> > After starting 2 processes that scan a lot of files (diff, find,
> > slocate, ...) it's impossible to run any other processes that
> > touch the disk, they will stall until one of the first two stop.
> > Could t
On Thu, 5 Oct 2000, Torben Mathiasen wrote:
>
> This patch is a resend of my other link fix patch that didn't get
> in test9-pre9. I assume this is because of some other changes
> to upper layer scsi drivers.
No, I just felt it was too big, and with not enough reason for it at all.
At this po
> the original process on a system fast enough to wrap the
> pid counter in < 1 sec?
on a recent, entry-level system (duron/600, 128M PC133)
I see ~13000 fork/child-exit/wait cycles per second.
clone is even worse (better): ~42K/second!
-
To unsubscribe from this list: send the line "unsubscribe
On Sun, Oct 08, 2000 at 03:49:20PM +, John Alvord wrote:
> On Thu, 5 Oct 2000 22:00:58 +, Alain Williams <[EMAIL PROTECTED]>
> wrote:
>
> >Hi,
> >
> >I remember when at the University of Cambridge (in England) about 25 years ago
> >seeing some work then about the Jackdaw (or was is Jackar
On Sat, Oct 07, 2000 at 09:00:15PM -0500, Diamon wrote:
>
> I hope this is going to the right list/group/etc, as I got this email
> address from someone on #kernelnewbies...
linux-raid is better for RAID problems.
>
> Attempting to mkraid /dev/md0 a raid5 array using a Buslogic Flashpo
On Thu, 5 Oct 2000 22:00:58 +, Alain Williams <[EMAIL PROTECTED]>
wrote:
>Hi,
>
>I remember when at the University of Cambridge (in England) about 25 years ago
>seeing some work then about the Jackdaw (or was is Jackard) database system
>that had the great feature of being immune to OS crashe
On Wed, 4 Oct 2000, Rik van Riel wrote:
>
> The potential for this bug has been around since 2.3.51, when
> different balance_ratios for different zones became possible.
No, the bug has been around since your VM.
You must NOT depend on some global "freepages" thing.
You MUST do your freepage
[EMAIL PROTECTED] said:
> Even with this patch, the overflow is 808 bytes (without the patch
> it's 1232 bytes).
I was mulling over some other changes that would have saved another 256 bytes,
but those don't look like they would help. Try the patch below. It
essentially gives up and lets the
On Tue, 3 Oct 2000, Matti Aarnio wrote:
>
> Linus, please use MUTT or PINE -- hmm... you do use PINE, so what
> is the problem at receiving MIME attachments, or QP encoded material
> at all ? (Aside of pine possibly saving/piping non-decoded QP
> text/plain message int
Hi,
There appears to be a nasty problem when a minix filesystem runs out of
inodes 2.4.0-test9. I've spotted this because I'm using a small ramdisk
(about 128k with 42 inodes) which contains the contents of /var/run and
/var/lock on a NFS rooted machine. I've recently changed the user-space
bin
After mounting; Doing 1 or 2 ls, works fine. However if you do a cat * >
/dev/null, it oopses.
I'm not sure if this is the real evil-doer since it spews a couple of oopses
out of scrollback reach, but the last point appears to be in d_lookup, in
the for.
0xc013bfc6 : movl 0x0(
On Sun, 8 Oct 2000 17:20:35 +0530,
[EMAIL PROTECTED] wrote:
>is there anything exported for kernel for use with modules that does
>coversion from alphnumeric to interger or anything like sscanf()
simple_strtol, simple_strtoul.
-
To unsubscribe from this list: send the line "unsubscribe linux-ke
Koos Vriezen wrote:
> Hi,
>
> Since i2c was added to the kernel, I have sometimes trouble with my bttv
> card. Before that, I never had any trouble with bttv since kernel 2.2.0.
Pick up a newer version from http://www.strusel007.de/linux/bttv/
Gerd
--e98APlP24773.971000747/einhorn.in-berlin
OK, yes the problem was a configuration one ...
CONFIG_VT and CONFIG_VT_CONSOLE were set to y, but CONFIG_VGA_CONSOLE
was set to n. It was this last one which was causing the problem.
I now have the 386 kernel loading into the netstation, starting up,
mounting rootfs, starting init and init star
hi!
is there anything exported for kernel for use with modules that does
coversion from alphnumeric to interger or anything like sscanf()
-
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.
On On Tue, 13 Jun 2000, Rik van Riel wrote:
> On Tue, 13 Jun 2000 [EMAIL PROTECTED] wrote:
>
> > I get these messages on the root console:
> >
> > VM: do_try_to_free_pages failed for kswapd...
> > VM: do_try_to_free_pages failed for syslog-ng...
> > VM: do_try_to_free_pages failed for rxvt...
>
On Saturday October 7, [EMAIL PROTECTED] wrote:
> Matt Stegman writes:
> > A few weeks ago Alan Cox mentioned, in reply to someone asking about
> > building an enourmous RAID array,
> >
> > "Right now 2.2 doesnt support journalling over software raid so that would
> > stop you using reiserfs and
On Sat, Oct 07, 2000 at 11:16:30AM -0700, Andre Hedrick wrote:
> On Sat, 7 Oct 2000, Jeff V. Merkey wrote:
>
> > append "hdd=ide-scsi"
>
> append "hdd=scsi" is better.
Care to explain why?
--
/| Ragnar Højland Freedom - Linux - OpenGL Fingerprint 94C4B
\ o.O|
On Sat, Oct 07, 2000 at 11:07:18PM -0700, Gerhard Mack wrote:
> I would call this a bug:
> [root@innerfire /root]# ifconfig sit0 tunnel ::206.123.31.102
> SIOCSIFDSTADDR: No buffer space available
I noticed the same problem over here with Linux 2.4 (haven't tried test9 yet).
BTW with Linux 2.2.17
Has everyone forgotten the old coda_fs-security discussion and
the question of how to be sure that you are still talking to
the original process on a system fast enough to wrap the
pid counter in < 1 sec?
(That question doesn't have to be solved with the pid, you can
use a wide cookie, but if cod
On Sun, Oct 08, 2000 at 12:35:48AM -0500, Jeff Dike wrote:
> I've been waiting for someone to send me that stack. There aren't any real
> smoking guns there. I'm guessing that the difference between your laptop and
> the machine it works on is that your laptop is running a fairly recent kernel
86 matches
Mail list logo
