On Mon, 7 May 2001, Lorenzo Marcantonio wrote:
> On Mon, 7 May 2001, Rob Turk wrote:
> > Have you ruled out hardware failures? There's been a few isolated reports
>
> That tape drive (Sony SDT-9000, less than 2 years of service) works
> perfectly on Windows NT (were it was before) and even on Lin
COOL...
We can take a look and see.
On Mon, 7 May 2001, Wilfried Weissmann wrote:
> Hi!
>
> I just put my highpoint-tech raid hack on a website:
> http://www.rug-rats.org/~wilfried/
> So if you want to play around with it you can download it from there +
> get a mininum of doc
Eric S. Raymond wrote:
> Tom Rini <[EMAIL PROTECTED]>:
> > Only sort-of. There are some cases where you can get away with that.
> > Probably. eg If you ask for PARPORT, on x86 that means yes to PARPORT_PC,
> > always (right?)
>
> Yes. So the right answer there isn't to use a derivation but t
David Weinehall <[EMAIL PROTECTED]>:
> > require X86 and PARPORT implies PARPORT_PC
> > unless X86==n suppress PARPORT_PC
> >
> > which forces PARPORT_PC==y and makes the question invisible on X86
> > machines, but leaves the question visible on all others.
>
> Yes, but there are quite a lot of
On Mon, May 07, 2001 at 09:56:18PM -0400, Eric S. Raymond wrote:
> Tom Rini <[EMAIL PROTECTED]>:
> > Only sort-of. There are some cases where you can get away with
> > that. Probably. eg If you ask for PARPORT, on x86 that means yes
> > to PARPORT_PC, always (right?)
>
> Yes. So the right ans
Hi ,
I am getting the following log in my kernel trace .
"kmem_grow : Called nonatomically from int - size 32"
What is the cause for this .??
Looking forward to your reply . As i am not in the mailist list kindly mark
a copy to me when you respond .
Warm Regards
bala
*
On Mon, May 07, 2001 at 10:45:59PM -0600, Andreas Dilger wrote:
> > May 8 01:11:29 pervalidus kernel: EXT2-fs error (device ide0(3,3)): ext2_readdir:
>bad entry in
> > directory #162813: directory entry across blocks - offset=92, inode=45,
>rec_len=16404,
> > name_len=9
> Since it is al
Federic Meunier writes:
> ==> /var/log/syslog <==
> May 8 00:25:52 pervalidus kernel: EXT2-fs error (device ide0(3,3)): ext2_readdir:
>bad entry in
> directory #162813: directory entry across blocks - offset=92, inode=45,
>rec_len=16404,
> name_len=9
> May 8 00:25:52 pervalidus kernel: EXT
This may be what you are looking for:
http://oss.sgi.com/projects/fam/
--
Rafael
-
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
Is there a way in linux to montior file writes?
I have something that is writing to the disk every 5:th second (approx.)
And I don't know what it is.. In windows I had a small program called
FileMonitor that where quite good in this situation.
Is there such a program i linux? If not, is it becau
On Sun, 6 May 2001, Pierre Rousselet wrote:
> Fred Fleck wrote:
> >
> > Sorry for asking on this mailing list.
> >
> > Can someone please tell me where to find the source
> > code for the ps command?
> >
> > Thanks
> >
> > Fred
>
> http://www.cs.uml.edu/~acahalan/procps/
>
>From the procps man p
Hi. I received the following error while updating my Mozilla
sources from MOZILLA_0_8_1_20010326_RELEASE to
MOZILLA_0_9_RELEASE via CVS:
==> /var/log/syslog <==
May 8 00:25:52 pervalidus kernel: EXT2-fs error (device ide0(3,3)): ext2_readdir: bad
entry in
directory #162813: directory entry acro
On Mon, 7 May 2001, Marcelo Tosatti wrote:
>
> So what about moving the check for a dead swap cache page from
> swap_writepage() to page_launder() (+ PageSwapCache() check) just before
> the "if (!launder_loop)" ?
>
> Yes, its ugly special casing. Any other suggestion ?
My most favourite app
Hi,
If I have to make modifications to TCP congestion handling, like congestion
window size where do I start? For examples if I need to modify the reset value
for CWND (when a tx timeout accurs). It seems like the function tcp_enter_loss
does something but I am not sure. So I was wondering if any
Marcelo Tosatti writes:
> > Hmmm, can't this happen without my patch?
>
> No. We will never call writepage() without __GFP_IO without your patch.
>
I see, because launder_loop never progresses to 1 in that case.
My patch is crap and can cause corruptions, there is not argument
about it no
On Mon, 7 May 2001, David S. Miller wrote:
>
> Marcelo Tosatti writes:
> > I just thought about this case:
> >
> > We find a dead swap cache page, so dead_swap_page goes to 1.
> >
> > We call swap_writepage(), but in the meantime the swapin readahead code
> > got a reference on the
On Mon, 7 May 2001, David S. Miller wrote:
>
> Marcelo Tosatti writes:
> > I was wrong. The patch is indeed buggy because of the __GFP_IO thing.
>
> What about the __GFP_IO thing?
>
> Specifically, what protects the __GFP_IO thing from happening without
> my patch?
This:
On Mon, 7 May 2001, David S. Miller wrote:
>
> Marcelo Tosatti writes:
> > I just thought about this case:
> >
> > We find a dead swap cache page, so dead_swap_page goes to 1.
> >
> > We call swap_writepage(), but in the meantime the swapin readahead code
> > got a reference on the
Marcelo Tosatti writes:
> I was wrong. The patch is indeed buggy because of the __GFP_IO thing.
What about the __GFP_IO thing?
Specifically, what protects the __GFP_IO thing from happening without
my patch?
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the lin
Marcelo Tosatti writes:
> I just thought about this case:
>
> We find a dead swap cache page, so dead_swap_page goes to 1.
>
> We call swap_writepage(), but in the meantime the swapin readahead code
> got a reference on the swap map for the page.
>
> We write the page out because
We have a RAID 5 system thats had 2 of 6 disks in the RAID go into thermal
shutdown. (Air-con failure).
The disks are functional, but the RAID won't restart because the superblock
timestamps on those two disks are now out of step with the rest of the array and
there aren't enough "good" disks to
Linus Torvalds writes:
> YOUR HEURISTIC IS WRONG!
Please start the conversation this way next time.
> I call that a bug. You don't. Fine.
You made it sound like a data corrupter, a kernel crasher, and that
any bug against a kernel with that patch indicates my patch caused it.
There is an imp
Can anybody explain what does "mm: critical shortage of bounce buffers"
mean?
I have a 2xP-III/850 system with 2Gbyte of RAM. I'm trying to run
ImageMagick on this system with quite big files (convert consumes 1+ Gbyte
of RAM). The system crushes immediately with that message in log file and a
wh
On Mon, 7 May 2001, David S. Miller wrote:
>
> Here, let's talk code a little bit so there are no misunderstandings,
> I really want to put this to rest:
>
> Calculate dead_swap_page outside of lock.
NO. That's not what you're doing at all. You're calculating something
completely different tha
On Mon, 7 May 2001, Marcelo Tosatti wrote:
>
> So lets fix it and make it look for the swap counts.
Ehh.
Which you MUST NOT do without holding the page lock.
Hint: it needs "page->index", and without holding the page lock you don't
know what it could be. An out-of-bounds page index could do
Tom Rini <[EMAIL PROTECTED]>:
> Only sort-of. There are some cases where you can get away with that.
> Probably. eg If you ask for PARPORT, on x86 that means yes to PARPORT_PC,
> always (right?)
Yes. So the right answer there isn't to use a derivation but to say:
require X86 and PARPORT imp
I kind of carelessly deleted /tmp/.X11-unix/X0. Now the thing is that
some programs which had not opened the socket before, can't connect to X.
The simplest solution would be just restart X, but that's too much effort
to me.
So I'm wondering, is there a way, kind of like "relink" system call wh
Zack Brown wrote:
>
> Can someone help this guy?
>
> --
> Zack Brown
>
> On Mon, 7 May 2001, Phillipus Gunawan wrote:
>
> > I'm having problem with iptables...
> > I just upgrade my kernel from 2.2.16 to 2.4.3
> > I also upgrade the iptables with: iptables-1.2.1a-1.i386.rpm
> > After the insta
On Mon, May 07, 2001 at 09:31:40PM -0400, Eric S. Raymond wrote:
> Tom Rini <[EMAIL PROTECTED]>:
[snip]
> Exactly. In fact we can be more specific -- the "Macintoshes" in
> question are the old-fashioned NuBus-based 68k toaster boxes, not the
> more recent designs with a PCI bus. Relevant stuff
Tom Rini <[EMAIL PROTECTED]>:
> On Sun, May 06, 2001 at 01:58:49PM +0100, Alan Cox wrote:
> > > # These were separate questions in CML1
> > > derive MAC_SCC from MAC & SERIAL
> > > derive MAC_SCSI from MAC & SCSI
> > > derive SUN3_SCSI from (SUN3 | SUN3X) & SCSI
> >
> > Not all Mac's use the SCC
Hi
After 4 days of uptime I got the following oops. Nothing special was happening
at the time.
Ideas?
Ed Tomlinson <[EMAIL PROTECTED]>
ksymoops 2.4.1 on i586 2.4.5-pre1. Options used
-V (default)
-k 20010507195318.ksyms (specified)
-l 20010507195318.modules (specified)
[trimming CC's. Recommend [EMAIL PROTECTED] for followups]
As you mentioned, the ACPI driver does something similar, and I think the
approach is generally sound (or at least we haven't been able to come up
with anything better ;-) I do have the following comments:
- It's probably easier to put t
Hi,
I've just tried 2.4.4ac5, and it stopped with an ext2fs error (Block
bitmap for group 16 not in...) Reiserfs was compiled in the kernel too,
and it too was complaining (they weren't able to mount my (ext2) root
partition for some reason)
I've gone back to ac4, with an identical kernel con
Marcelo Tosatti writes:
> My point is that its _ok_ for us to check if the page is a dead swap cache
> page _without_ the lock since writepage() will recheck again with the page
> _locked_. Quoting you two messages back:
>
> "But it is important to re-calculate the deadness after getting t
Linus Torvalds writes:
> What do you expect me to do? The patch is buggy. It should be reverted.
> What's your problem?
I think the problem he has is that you are acting as if the patch
causes corruptions and will end in failures. This is how you are
coming across, at least.
Really, your pro
On Mon, 7 May 2001, Linus Torvalds wrote:
>
> On Mon, 7 May 2001, Marcelo Tosatti wrote:
> >
> > So the "dead_swap_page" logic is _not_ buggy and you are full of shit when
> > telling Alan to revert the change. (sorry, I could not avoid this one)
>
> Well, the problem is that the patch _is_
On Mon, 7 May 2001, Marcelo Tosatti wrote:
>
> So the "dead_swap_page" logic is _not_ buggy and you are full of shit when
> telling Alan to revert the change. (sorry, I could not avoid this one)
Well, the problem is that the patch _is_ buggy.
swap_writepage() does it right. And dead_swap_page
It looks like tha 8139too, at least in 2.2.19, works fine when there
is one such card around but with NICs it detects both but fails to
set the second one correctly (complaints about incorrect IRQ, memory,
... - you name it). Does anybody has some ideas what is going on here?
This was observed o
Linus Torvalds writes:
>
> On Mon, 7 May 2001, Marcelo Tosatti wrote:
> > And thats what swap_writepage() is doing:
>
> Ehh.. swap_writepage() is called with the page locked. So it _can_ depend
> on it.
>
> If the page isn't locked there, then THAT is a bug. A major one.
Linus, he's t
On Mon, 7 May 2001, Linus Torvalds wrote:
>
> On Mon, 7 May 2001, Marcelo Tosatti wrote:
> >
> > On 7 May 2001, Linus Torvalds wrote:
> >
> > > But it is important to re-calculate the deadness after getting the
> > > lock. Before, it was just an informed guess. After the lock, it is
> > > kn
On Mon, 7 May 2001, Marcelo Tosatti wrote:
>
> On 7 May 2001, Linus Torvalds wrote:
>
> > But it is important to re-calculate the deadness after getting the
> > lock. Before, it was just an informed guess. After the lock, it is
> > knowledge. And you can use informed guesses for heuristics, but
Hi.
I have added
kernel.coredump_suid_enabled
which will allow the generation of core dumps for SUID processes. (Defaults
to off).
Also I changed the default logging to off, as suggested to avoid
a posible DOS.
Finally I have changed the logging messages to include EUID and EGID if
differ
H. Peter Anvin wrote:
>Larry McVoy wrote:
>
>>On Mon, May 07, 2001 at 12:33:57PM -0700, H. Peter Anvin wrote:
>>
>>>Larry McVoy wrote:
>>>
>Because your original post was "yeah, Bitkeeper is a memory hog but you
>can get really cheap non-ECC RAM so just stuff your system with crappy
>
Ben LaHaise writes:
> and then use a map_mm_kiobuf (which is
> map_user_kiobuf but with an mm parameter) for the portion of the buffer
> that's currently being copied. That improves code reuse and gives us a
> few primatives that are quite useful elsewhere.
If it has roughly the same cost a
I'm working on a new SMP mips port, and tripped over a strange
bug. Am not quite sure how to attack it.
I'm running 2.4.2 from oss.sgi.com's cvs repositry, booting with
the root filesystem being over NFS with two cores active in
the system. The port is actually fairly stable at the moment, but
On 7 May 2001, Linus Torvalds wrote:
> But it is important to re-calculate the deadness after getting the
> lock. Before, it was just an informed guess. After the lock, it is
> knowledge. And you can use informed guesses for heuristics, but you
> must _not_ use them for any serious decisions.
Sean Jones writes:
> In compiling 2.4.4-ac5 for my SPARCStation 20, I had an error in the
> compile resulting from the inability to find a hw_irq.h in the
> include/asm directory. Do you know where I may be able to find such a
> file?
How did you find this problem if the build couldn't find
Try "make vmlinux"
Later,
David S. Miller
[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/
Linus Torvalds wrote:
>
> In particular, does anybody have a buggy Pentium to test with the F0 0F
> lock-up bug? It _should_ be caught with the error-code test (it's a
> protection fault, not a non-present fault and thus the F0 0F case never
> enters the vmalloc path), but it's been several year
Linus Torvalds writes:
> The whole "dead_swap_page" optimization in the -ac tree is apparentrly
> completely bogus. It caches a value that is not valid: you cannot
> reliably look at whether the page has buffers etc without holding the
> page locked.
It caches a value controlling heuristic
Linus Torvalds wrote:
>
> On Mon, 7 May 2001, Brian Gerst wrote:
> >
> > Keep in mind that regs->eflags could be from user space, and could have
> > some undesirable flags set. That's why I did a test/sti instead of
> > reloading eflags. Plus my patch leaves interrupts disabled for the
> > mini
On 2001.05.08 01:04:57 +0200 Jesper Juhl wrote:
>
> static inline int sock_rcvlowat(struct sock *sk, int waitall, int len)
> {
> int r = len;
> if (!waitall)
> r = min(sk->rcvlowat, len);
> return max(1,r);
> }
>
return max(1, waitall ? len : min(sk-
At 18:12 07/05/2001, Linus Torvalds wrote:
>In particular, does anybody have a buggy Pentium to test with the F0 0F
>lock-up bug?
[snip]
>If anybody has such a beast, please try this kernel patch _and_ running
Still works ok (2.4.5-pre1 + patch). SIGILL is sent.
Best regards,
Anton
--
Anton
I have been unable to make bzImage on my SPARCStation 20 because it can
not find any rules to make it. Any suggestions are welcome.
Sean Jones
-
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://vge
In compiling 2.4.4-ac5 for my SPARCStation 20, I had an error in the
compile resulting from the inability to find a hw_irq.h in the
include/asm directory. Do you know where I may be able to find such a
file?
Thank you
Sean Jones
-
To unsubscribe from this list: send the line "unsubscribe linux-k
On Mon, 7 May 2001, Brian Gerst wrote:
> Nigel Gamble wrote:
> >
> > On Mon, 7 May 2001, Linus Torvalds wrote:
> > > On Mon, 7 May 2001, Brian Gerst wrote:
> > > > This patch will still cause the user process to seg fault: The error
> > > > code on the stack will not match the address in %cr2.
>
Alan Cox wrote:
>
> > The main problem is that map_user_kiobuf() locks pages into memory.
> > It's a bad idea for pipes. Either we must severely limit the maximum
>
> You only have to map them for the actual copy.
The current map_user_kiobuf() doesn't have an 'mm' parameter, I can only
use it f
On Mon, 7 May 2001, Brian Gerst wrote:
>
> Keep in mind that regs->eflags could be from user space, and could have
> some undesirable flags set. That's why I did a test/sti instead of
> reloading eflags. Plus my patch leaves interrupts disabled for the
> minimum time possible.
The plain "popf
On Mon, 7 May 2001, Larry McVoy wrote:
> For the record, however, I never stated that BitKeeper is a
> memory hog, that's a conclusion you drew.
I read it that way in your message, but it's good to have
the situation clarified ;)
Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml
Vir
> The main problem is that map_user_kiobuf() locks pages into memory.
> It's a bad idea for pipes. Either we must severely limit the maximum
You only have to map them for the actual copy.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Hi all,
Some time ago I posted about a question about some cleanup of what I
thought looked like some strange code in the kernel - specifically about
the sock_rcvlowat() function in linux/include/net/sock.h
static inline int sock_rcvlowat(struct sock *sk, int waitall, int len)
{
retu
On Mon, 7 May 2001, Linus Torvalds wrote:
> On Mon, 7 May 2001, Brian Gerst wrote:
> > This patch will still cause the user process to seg fault: The error
> > code on the stack will not match the address in %cr2.
>
> You've convinced me. Good thinking. Let's do the irq thing.
I've actually seen
Nigel Gamble wrote:
>
> On Mon, 7 May 2001, Linus Torvalds wrote:
> > On Mon, 7 May 2001, Brian Gerst wrote:
> > > This patch will still cause the user process to seg fault: The error
> > > code on the stack will not match the address in %cr2.
> >
> > You've convinced me. Good thinking. Let's do
The attached patch, against 2.4.5-pre1, fixes a chipset wakeup bug which
occurred on a popular 8139 chip.
--
Jeff Garzik | Game called on account of naked chick
Building 1024|
MandrakeSoft |
Index: linux_2_4/drivers/net/8139too.c
diff -u linux_2_4/drivers/net/8139too.c:1.1.1.34
lin
On Mon, 7 May 2001, Richard B. Johnson wrote:
> When we get to media that can sink data as fast as we can generate
> them (it), then we have to worry about memory copy speed. However,
> these new devices are actually an IP subsystem. They generate and
> receive entire datagrams. To fully utilize
On Mon, 7 May 2001, Brian Gerst wrote:
>
> This patch will still cause the user process to seg fault: The error
> code on the stack will not match the address in %cr2.
You've convinced me. Good thinking. Let's do the irq thing.
Linus
-
To unsubscribe from this list: send the l
Hi!
I just put my highpoint-tech raid hack on a website:
http://www.rug-rats.org/~wilfried/
So if you want to play around with it you can download it from there +
get a mininum of documentation.
Andre Hedric, Ajran van de Ven, ...:
I am sorry that I did not had much time lately to get some infor
Has anyone had a Rockwell (Context) Winmodem working with kernel
series v2.4.x?
It appears the only module is for kernel v2.2.x. Is there anyway to
get a port to v2.4.x? Anyone ping the company that released the
precompiled binary?
Thanks.
--
- Nick
-
To unsubscribe from this list: send the
Larry McVoy wrote:
>
> On Mon, May 07, 2001 at 12:33:57PM -0700, H. Peter Anvin wrote:
> > Larry McVoy wrote:
> > > > Because your original post was "yeah, Bitkeeper is a memory hog but you
> > > > can get really cheap non-ECC RAM so just stuff your system with crappy
> > > > RAM and be happy."
>
Linus Torvalds wrote:
>
> On Mon, 7 May 2001, Alan Cox wrote:
> >
> > That is nice. I hadn't thought about doing it that way. It still has the problem
> > if %cr2 is corrupted by a vmalloc fault but it cleans up my other code paths
> > nicely.
>
> See about "corruption" in previous email. It doe
On Mon, 7 May 2001, dean gaudet wrote:
> On Mon, 7 May 2001, Richard B. Johnson wrote:
>
> > when the hardware I/O is used. This shows that the network code, alone,
> > cannot be improved very much to provide an improvement in throughput.
>
> doesn't your analysis assume that we've got nothing
On Mon, May 07, 2001 at 12:33:57PM -0700, H. Peter Anvin wrote:
> Larry McVoy wrote:
> > > Because your original post was "yeah, Bitkeeper is a memory hog but you
> > > can get really cheap non-ECC RAM so just stuff your system with crappy
> > > RAM and be happy."
> I wasn't the one who said it
Larry McVoy wrote:
>
> On Mon, May 07, 2001 at 12:21:28PM -0700, H. Peter Anvin wrote:
> > Larry McVoy wrote:
> > > What does BitKeeper have to do with this conversation?
> >
> > Because your original post was "yeah, Bitkeeper is a memory hog but you
> > can get really cheap non-ECC RAM so just s
On Mon, May 07, 2001 at 12:21:28PM -0700, H. Peter Anvin wrote:
> Larry McVoy wrote:
> > What does BitKeeper have to do with this conversation?
>
> Because your original post was "yeah, Bitkeeper is a memory hog but you
> can get really cheap non-ECC RAM so just stuff your system with crappy
> RA
Larry McVoy wrote:
> > >
> > > A) Fast has nothing to do with it, ECC runs at the same speed as non-ECC;
> >
> > "It" meaning BitKeeper.
>
> What does BitKeeper have to do with this conversation?
>
> s/BitKeeper/any_app_which_has_integrity_checks/
>
> Whether that app runs fast or not has nothi
On Mon, May 07, 2001 at 12:01:50PM -0700, H. Peter Anvin wrote:
> Larry McVoy wrote:
> > > Isn't this pretty much saying "if you're willing to dedicate your
> > > system to running nothing but Bitkeeper, you can run it really fast?"
> >
> > A) Fast has nothing to do with it, ECC runs at the same
On Mon, 7 May 2001, Rob Turk wrote:
> Lorenzo,
>
> Have you ruled out hardware failures? There's been a few isolated reports
That tape drive (Sony SDT-9000, less than 2 years of service) works
perfectly on Windows NT (were it was before) and even on Linux 2.2
Also the cartridge was brand new.
Here is a patch to deal with PM events (e.g. button presses) in a
system independent way. Could people with the applicable hardware test
out or comment on the changes?
The files affected are
arch/i386/kernel/apm.c
arch/mips/sgi/kernel/reset.c
arch/mips64/sgi-ip22/ip22
On 05.07 Helge Hafting wrote:
> Tobias Ringstrom wrote:
> >
> > On Sun, 6 May 2001, David S. Miller wrote:
> > > It is the most straightforward way to make a '1' or '0'
> > > integer from the NULL state of a pointer.
> >
> > But is it really specified in the C "standards" to be exctly zero or o
Larry McVoy wrote:
> > >
> > > On the other hand, if your apps don't have built in integrity checks then
> > > ECC is pretty much a requirement.
> >
> > Isn't this pretty much saying "if you're willing to dedicate your
> > system to running nothing but Bitkeeper, you can run it really fast?"
>
>
See this program:
int main(int argc, char *argv[])
{
int h;
char buffer[16];
int nbytes=16,nbits=16*8;
int nin;
h=open("/dev/random", O_RDONLY);
if (h==-1) exit(1);
/* see how many bits there are in it */
printf("returned: %d\n", i
> Then there's the interrupt problem, which someone will have to solve
> before they start shipping 10gigE NICs that use 1500-byte frames, 85
> interrupts/s without mitigation. Wh
In this situations polling helps rather than interrupt driven IO. When there
is heavy IO(read more interr
Christian Bornträger wrote:
>
> Can you try and mail me if the Kernel 2.4.3 (without any ac patch) is
> stable with your system even if you use autotune? "Downgrade" to this
> kernel works fine for me.
At least RedHat's 2.4.2-2 doesn't seem to lockup. I'll compile and try 2.4.3
tomorrow.
- J
On Mon, May 07, 2001 at 11:47:34AM -0700, H. Peter Anvin wrote:
> Followup to: <[EMAIL PROTECTED]>
> By author:Larry McVoy <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > On Sun, May 06, 2001 at 02:20:43PM +1200, Chris Wedgwood wrote:
> > > 1.5GB without ECC? Seems like a disater
Erik Mouw <[EMAIL PROTECTED]> writes:
> Try linux-2.2.19, it contains BIOS e820 support. If you don't want to
> compile a kernel, check if Red Hat has RPMs available somewhere on
> their site.
They do; there was a kernel errata release of 2.2.19 for security
reasons. On updates.redhat.com or a
On Mon, 7 May 2001, Dan Hollis wrote:
> > Erm, it was bad RAM everytime it happened to me. On standard PCs, you
> > don't see those because you don't have ECC and the error is simply not
> > detected.
> So a 440bx motherboard with ECC ram is a non-standard PC?
I bet the board doesn't force you
Followup to: <[EMAIL PROTECTED]>
By author:Larry McVoy <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> On Sun, May 06, 2001 at 02:20:43PM +1200, Chris Wedgwood wrote:
> > 1.5GB without ECC? Seems like a disater waiting to happen? Is ECC
> > memory much more expensive?
>
> Almost twice
The thing that confused me here was the help text in menuconfig. The help for
CONFIG_I82365 says, "Say Y here to include support for PCMCIA and CardBus host
bridges that are register compatible with the Intel i82365 and/or the Yenta
specification: this includes virtually all modern PCMCIA bridg
On Mon, May 07, 2001 at 08:06:52PM +0300, Bohdan Vlasyuk wrote:
> Hi !! I'm running linux on Compaq Presario 1215 Laptop. Kernel is,
> as shipped with RH 7.0, 2.2.16. So, every time I press any of
> sound<+-> buttons [of + { = functional button, used in
> conjunction with F1-F8 to alter various
At 18:12 07/05/2001, Linus Torvalds wrote:
>Untested.
>
>In particular, does anybody have a buggy Pentium to test with the F0 0F
>lock-up bug?
Yes, I have one. 2.4.3-ac6 (plus a few patches) detects the bug on boot up
and enables the work around. Running the f00f test program from SGI results
i
Yep, totally. I've worked on hundreds of systems and less than 20 of the
workstations or PCs have been useing ECC. Most servers do, but not even
all of them.
Nick
On Mon, 7 May 2001, Dan Hollis wrote:
> On Mon, 7 May 2001, Simon Richter wrote:
> > On Mon, 7 May 2001, Bene, Martin wrote
On Mon, May 07, 2001 at 12:12:57PM -0400, Richard B. Johnson wrote:
> you can perform network speed tests using "lo", removing the network
> board from the speed test. You will note that the network speed, due
> to software, is over 10 times faster, 30 times on some machines) than
> when the hardw
On Mon, 7 May 2001, Richard B. Johnson wrote:
> when the hardware I/O is used. This shows that the network code, alone,
> cannot be improved very much to provide an improvement in throughput.
doesn't your analysis assume that we've got nothing else interesting to do
while doing the network i/o?
On Mon, 7 May 2001, David Balazic wrote:
>
> Andre , you promised ATA/IDE hot-swap on "normal" hardware
> several weeks ( months ? ) ago. What happened ?
>
> --
> David Balazic
> --
> "Be excellent to each other." - Bill & Ted
> - - - - - - - - - - - - - - - - - - - - - -
>
Wel
On Mon, 7 May 2001, Simon Richter wrote:
> On Mon, 7 May 2001, Bene, Martin wrote:
> > Definitely not caused by:
> > Bad Rams, mb-chipset.
> Erm, it was bad RAM everytime it happened to me. On standard PCs, you
> don't see those because you don't have ECC and the error is simply not
> detected
On Mon, 7 May 2001, Alan Cox wrote:
> > documented so far) detailed description of the newly
> > implemented zero-copy mechanisms in the network-stack.
> > We are interested in how to use it (changed network-API?)
> > and also in the internal architecture.
>
> It is built around sendfile. Trying
On Mon, May 07, 2001, Shane Wegner <[EMAIL PROTECTED]> wrote:
> On Mon, May 07, 2001 at 11:02:50AM -0700, Johannes Erdfelt wrote:
> > On Mon, May 07, 2001, Shane Wegner <[EMAIL PROTECTED]> wrote:
> > >
> > > That does indeed correct the problem. 2.2.20pre1 now works
> > > as expected.
> >
> > H
Hi,
This patch fixes a minor bug the Kernel API book: it should include the
functions in kernel/module.c as well. The patch is against linux-2.4.4,
but should work as well against 2.4.5-pre1 and 2.4.4-ac5. Please apply.
Erik
PS: Thanks to Timur Tabi for pointing out this "bug".
Index: Documen
On Mon, May 07, 2001 at 11:02:50AM -0700, Johannes Erdfelt wrote:
> On Mon, May 07, 2001, Shane Wegner <[EMAIL PROTECTED]> wrote:
> >
> > That does indeed correct the problem. 2.2.20pre1 now works
> > as expected.
>
> Hmm, that uses a VIA based chipset. I didn't know they did SMP yet. Does
> 2.
On Mon, 7 May 2001, Bene, Martin wrote:
[MCE caused by bad RAM]
> I don't think there is a way a machine check exception can be triggered by
> software - which it would have to be in order to be caused by bad RAMs.
A MCE is triggered by an ECC error - no software involved. A good trap
handler w
1 - 100 of 168 matches
Mail list logo
