Juergen Schoew <[EMAIL PROTECTED]> writes:
> Hi,
> On 15-Feb-01 Thomas Lau wrote:
> > hey, I found this driver on mandrake kernel sources, it's ac3, but I
> > need ac14 code, also, why still not port this driver into kernel?
> > the patch file already released 1 years ago
>
> Have you checked
The "ld" program in binutils-2.10.1.0.7 and in
binutils-2.10.91.0.2 now requires "--oformat" instead of "-oformat".
This breaks linux-2.4.2-pre3/arch/i386/boot/Makefile. I have attached
the fix below. I am running a kernel built with this updated Makefile.
--
Adam J. Richter __
Hello!
acpi_idle is disabled on SMP systems with more then 1 cpu. The boot
message sais otherwise. This patch corrects the message.
--- linux-2.4.2/drivers/acpi/cpu.c.orig Sat Feb 10 12:01:52 2001
+++ linux-2.4.2/drivers/acpi/cpu.c Thu Feb 15 08:54:16 2001
@@ -335,13 +335,12 @@
On Mon, Feb 12, 2001 at 08:10:01AM +0100, Elena Labruna wrote:
> I'm working with a C package written by other
> on a linux machine with kernel version 2.2.14,
> often in a calls of longjmp routine
> the system crash with a SIGSEGV signal.
>
> Anyone can tell me if it can be a kernel problem ?
Hi David,
Just to let you and the rest of the world in on a secret, 'ASL, Inc.' is
the premier ATA server system builder. Jeff Nguyen is the only person
that I knew two years ago that was a pioneer and I have shared some
information with him before in the past, but here is ATA and it it here
Thank you all for your response.
Andre (ASL), thanks for the assist. Laurie and Janine took care of me.
Asus CUV4X-D mobo with 1GB of buffered ECC RAM. I'm in the process of
transfering all the hardware to the new board. I'll let you know if this
new board solves the APIC errors and the random
Chris Friesen wrote:
> The kicker is that the NIC with the MAC address in question happened to be in my
> G4 box running linux (yellowdog, 2.2.17 kernel). It was a D-Link 530TX NIC, if
> it matters. The linux box was not configured as a DHCP server or client, and
> both interfaces on the box
I am trying to get some ideas on what the heck caused a problem with the network
at work, and I was hoping someone might have some ideas.
Yesterday we were having some major network problems, many machines were
completely bogged down. This morning I came in to work to find my linux box
On Thu, Feb 15 2001, Adam Schrotenboer wrote:
> What's the current status of the loop-# patch? Haven't seen anything
> since loop-4, which doesn't apply clean to 2.4.1-ac14 (one hunk is
> rejected in loop.c, many others apply with fuzz).
>
> I am waiting in anticipation of the folding of this
> Recently I got some more detailed information on Japanese keyboards
> and their scancodes. Maybe there are Japanese readers here who
> can look at
> http://www.win.tue.nl/~aeb/linux/kbd/scancodes-3.html#ss3.3
> and correct what is wrong?
>
> Andries
Well, I can read Japanese, but what
We have a problem here that make the filesystem crash during big files
transfer (>1M). It only happens with kernel 2.4.x ; with 2.2.18, it is
very stable and fast.
I have seen a thread some time ago concerning such problem but is there
a solution against it now ?
I should add that the behaviour
On Wed, 14 Feb 2001, Tom Sightler wrote:
> Quoting "Gord R. Lamb" <[EMAIL PROTECTED]>:
>
> > On Wed, 14 Feb 2001, Jeremy Jackson wrote:
> >
> > > "Gord R. Lamb" wrote:
> > > > in etherchannel bond, running
> > linux-2.4.1+smptimers+zero-copy+lowlatency)
>
> Not related to network, but why would
What is believed to be the current status of the typical mke2fs
crashes/hangs due to vm issues? I can reliably reproduce the issue on a
heavily modifed VA kernel based on 2.2.18. Is there a kernel which is
believed to be a known good kernel? (both 2.2.x and 2.4.x)
Failure pattern:
System:
On Thu, 15 Feb 2001, Manfred Spraul wrote:
>
> > Now, I will agree that I suspect most x86 _implementations_ will not do
> > this. TLB's are too timing-critical, and nobody tends to want to make
> > them bigger than necessary - so saving off the source address is
> > unlikely. Also, setting
I haven't received any emails from any vger lists since Jan. 29. Do they
still work? Would anyone who gets this message please email
"[EMAIL PROTECTED]" to let me know if my message gets to the list? I have
to figure out why I can't see anything *from* the list...
-
To unsubscribe from this
On Fri, 16 Feb 2001, Jamie Lokier wrote:
>
> If you want to take it really far, it _could_ be that the TLB data
> contains both the pointer and the original pte contents. Then "mark
> dirty" becomes
>
>val |= D
>write *ptr
No. This is forbidden by the intel documentation.
Anyone have a recommendation for a motherboard for a homebased SMP box?
I've tried the Abit VP6 and the MSI 6321 (694D Pro). Both give me the APIC
errors with system lockups on heavy I/O using the 2.4.1-ac1# and the
2.4.2-pre# kernels. (The ac-## line doesn't die ANYWHERE near as often as
the
On Thursday February 15, [EMAIL PROTECTED] wrote:
>
> Here I am again! NFSD died at 11h23, ~12 hours after the last reboot, a
> record :-)
I'm guessing you don't have many symlinks on the exported
filesystem
> I'll try to best answer your questions.
>
> > This trace seems to make sense,
You have junk for cables or they are noe sheilded correctly from
crosstalk. But I do not think this is the case.
Go check your power-supply for stality and load.
Then do a ripple noise test to make sure that underload, it does not cause
the clock on the drives to fail.
On Thu, 15 Feb 2001,
2.4.1-ac breaks parport_pc in PCI-less configs.
Attempting to 'make vmlinux' in 2.4.1-ac14 with
# CONFIG_MODULES is not set
# CONFIG_PCI is not set
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
results in
drivers/parport/driver.o: In function `parport_pc_init_superio':
Linus Torvalds wrote:
> It _could_ be that the TLB data actually also contains the pointer to
> the place where it was fetched, and a "mark dirty" becomes
>
> read *ptr locked
> val |= D
> write *ptr unlock
If you want to take it really far, it _could_ be that the TLB data
On 02.15 Chip Salzenberg wrote:
> According to J . A . Magallon:
>
> Might I suggest that Justin imitate the maintainers of lm_sensors, and
> create a program (shell script, Perl program, whatever) that *creates*
> a patch against any given Linux source tree? Obviously it could break
> in the
>>I've not changed anything related to DMA handling specifically. The current
>>-ac does have a fix for a couple of cases where an IDE reset on the promise
>>could hang the box dead. That may be the problem.
I tried the new patches (2.4.1-ac13) and it seemed very stable. After
moving about
On Thu, 15 Feb 2001 15:57:09 -0500 (EST), Richard A Nelson <[EMAIL PROTECTED]> wrote:
> The machine boots and runs for some time without problems, but then
> something makes the clock *very* jittery:
>
> * xscreensaver kicks in after almost no time (even betwixt quick
>keystrokes and in the
Hello linux kernel listees
I remember reading that doing 32-bit writes to VRAM is not a good
idea because it somehow interferes with audio. Is this true or
still the case?
Thanks all,
Daniel
_
Get your FREE download of MSN Explorer
Ok this one should fix the non booting CPUs problem.
Question of the day for the VM folks:
If CPU1 is loading the exception tables for a module and
CPU2 faults.. what happens 8)
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
2.4.1-ac15
o
German Gomez Garcia wrote:
> I've got Plexwriter 12x10x32S attached to an onbard AIC7890
> (besides other things as three IBM UWSCSI harddisks, an SCSI ZIP and a
> Pioneer DVD) and sometimes when recording a CD the Plexwriter fails at the
> very end of the process (although the CD is
Andres Salomon wrote:
> I'm getting the following oopses, both apparently in the same place of
> create_virtual_node():
>
> Feb 15 16:03:32 infinity kernel: printing eip:
> Feb 15 16:03:32 infinity kernel: c015aeaa
> Feb 15 16:03:32 infinity kernel: Oops:
> Feb 15 16:03:32 infinity kernel:
Recently I got some more detailed information on Japanese keyboards
and their scancodes. Maybe there are Japanese readers here who
can look at
http://www.win.tue.nl/~aeb/linux/kbd/scancodes-3.html#ss3.3
and correct what is wrong?
Andries
-
To unsubscribe from this list: send the line
> Samba appears to be broken in 2.4.1-ac14
> No odd dmesg, modules load fine just nothing is there.
Umm thats not enough info to help. What file system are you serving, explain
'nothing there'
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Samba appears to be broken in 2.4.1-ac14
No odd dmesg, modules load fine just nothing is there.
Works in 2.4.1-ac7 just fine.
Versions follow
Samba version 2.0.7
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in
Hello,
when trying to boot kernel 2.4.1, 2.4.1-ac9 or 2.4.1-ac13,
I get lockups right after the message "now booting kernel".
Kernel 2.4.0-test10 ist booting ok on the machine.
Rik van Riel suspected on #kernelnewbies this might be a bug in
the CPU detection routine.
The system in question
On Thu, 15 Feb 2001, Bill Wendling wrote:
> With the horrid (pro-Microsoft) Aschroft in office, who knows what MS
> can get away with. Not to mention all of the pro-business, anti-human
> cronies in Washington running the Presidency (cause \/\/ just can't do
> it).
Most of the pro-business
Also sprach Alan Olsen:
} I expect the next thing that will happen is that they will get patents on
} key portions of their protocols and then start enforcing them.
}
Which protocols would that be? TCP/IP wasn't invented by them.
} I wonder what kind of law they will try to push to outlaw Open
David Hinds wrote:
>
> On Thu, Feb 15, 2001 at 10:49:22PM +1100, Andrew Morton wrote:
> >
> > Now, the thing I don't understand about David's design is the
> > final one. What 3c575_cb does is:
> >
> > CONFIG_HOTPLUG=y, MODULE=true
> > If the hardware isn't there, register the driver
it's final version, but why it's not work ?
diff -urN linux-2.4.1-p8-pristine/Documentation/Configure.help
linux-2.4.1-p8/Documentation/Configure.help
--- linux-2.4.1-p8-pristine/Documentation/Configure.helpThu Jan 18 01:20:48
2001
+++ linux-2.4.1-p8/Documentation/Configure.help Thu
This is mostly again to make sure everyone is in sync across the various
ports and those that are fully merged all compile.
Alan
2.2.19pre13
o Fix up missing bits of Soohoon Lee's exec patch (Michael Jaegerman)
| not sure where some bits of it escaped too...
o Revert serial
Hi,
On 15-Feb-01 Thomas Lau wrote:
> hey, I found this driver on mandrake kernel sources, it's ac3, but I
> need ac14 code, also, why still not port this driver into kernel?
> the patch file already released 1 years ago
Have you checked http://www.garloff.de/kurt/linux/dc395/index.html
there ist
anyone know how?
-
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/
Manfred Spraul wrote:
>
> I just benchmarked a single flush_tlb_page().
>
> Pentium II 350: ~ 2000 cpu ticks.
> Pentium III 850: ~ 3000 cpu ticks.
>
I forgot the important part:
SMP, including a smp_call_function() IPI.
IIRC Ingo wrote that a local 'invplg' is around 100 ticks.
--
Linus Torvalds wrote:
>
> In article <[EMAIL PROTECTED]>,
> Jamie Lokier <[EMAIL PROTECTED]> wrote:
> >> > << lock;
> >> > read pte
> >> > if (!present(pte))
> >> >do_page_fault();
> >> > pte |= dirty
> >> > write pte.
> >> > >> end lock;
> >>
> >> No, it is a little more complicated. You
On Thu, 15 Feb 2001 [EMAIL PROTECTED] wrote:
>
> "I'm an American, I believe in the American Way, I worry if the
> government encourages open source, and I don't think we've done
> enough education of policy makers to understand the threat."
>
It is not American to steal. The first "Flight
Update on the "unregister_netdevice" bug ...
Arnaldo Carvalho de Melo has been valiantly trying in his
scarce free time to find the cause. I haven't been able to
hunt effectively because I don't really understand the networking
code; however I have been experimenting to see what are the
exact
> > I ran DNS reliably over AX.25 networks. They have an MTU of 216. They work.
>
> 512 is maximal message size, which is transmitted without troubles,
> hardwired to almost all the datagram protocols.
Message size != MTU. DNS doesnt use DF. In fact DNS can even fall back to
TCP.
> > > B.
On Thu, 15 Feb 2001, Michal Jaegermann wrote:
> Like I wrote - I did not get to locks on fsck but then stuff was weird
> and if I would press sufficiently long maybe I would. I still had some
> use for my file systems so I did not try hard enough. Maybe we need
> black hens on the top of the
Rick Jones wrote:
>
> > Default of 536 is sadistic (and apaprently will be changed eventually
> > to stop tears of poor people whose providers not only supply them
> > with bogus mtu values sort of 552 or even 296, but also jailed them
> > to some proxy or masquearding domain), but it is still
On Thu, Feb 15, 2001, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I'm using the usb-uhci core with the 8200e storage drivers. I don't why
> the kernel logs the next message:
>
> uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4
> uhci.c: root-hub INT complete: port1: 495
On Thu, Feb 15, 2001 at 03:15:01PM -0500, John Jasen wrote:
>
> I retried the mysticism and incantations (d -l 801feac d) at the srm
> prompt, and the machine locked on fsck, under kernel 2.4.1-ac13.
Like I wrote - I did not get to locks on fsck but then stuff was weird
and if I would press
On Thu, 15 Feb 2001, Alan Olsen wrote:
> I expect the next thing that will happen is that they will get patents on
> key portions of their protocols and then start enforcing them.
>
They can only patent their own creations. I'd like to see them try to get
patents for their "extensions" to TCP
Hello!
> I ran DNS reliably over AX.25 networks. They have an MTU of 216. They work.
Please, Alan, distinguish two things: "works" and "works, until
I ask X". The second is equal to "does not".
512 is maximal message size, which is transmitted without troubles,
hardwired to almost all the
"I'm an American, I believe in the American Way, I worry if the
government encourages open source, and I don't think we've done
enough education of policy makers to understand the threat."
He believes in the "Golden Rule" too...
Can you say "NSA" or "Secure Linux"?
I believe they are truly
- Forwarded message from [EMAIL PROTECTED] -
Date: Thu, 15 Feb 2001 21:40:28 +0100
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: USB mass storage and USB message
I'm using the usb-uhci core with the 8200e storage drivers. I don't why
the kernel logs the next message:
> Default of 536 is sadistic (and apaprently will be changed eventually
> to stop tears of poor people whose providers not only supply them
> with bogus mtu values sort of 552 or even 296, but also jailed them
> to some proxy or masquearding domain), but it is still right: IP
> with mtu lower 576
hey, I found this driver on mandrake kernel sources, it's ac3, but I
need ac14 code, also, why still not port this driver into kernel?
the patch file already released 1 years ago
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Hi all,
How it's the support of ATA100 in the linux kernel? Do I need to use 2.4
to get full speed or is enough to configure the drive with hdparm? When i
use hdparm several modes supported appear. Is udma5 equivalent to the
standard ATA100 ? And sorry if my questions are maybe too simple for
> I haven't tried 2.4.1-ac13 on that machine yet, but I did attempt to boot
> 2.4.1-ac13 on an Winchip-C6 machine. It froze at the same place, i.e.
> "Checking if this processor honours the WP bit even in supervisor
> mode...". 2.4.1-ac12 works quite nicely on this machine, although I still
Alan Cox wrote:
>
> > Peter pointed out that the contents of the CSR12-14 registers are
> > initialized from the EEPROM, so reading the EEPROM is superfluous--we
> > should just read the CSRs and not read the EEPROM. I think he has a
> > point, so I'll make that change and submit yet another
In article <[EMAIL PROTECTED]>,
Jamie Lokier <[EMAIL PROTECTED]> wrote:
>> > << lock;
>> > read pte
>> > if (!present(pte))
>> >do_page_fault();
>> > pte |= dirty
>> > write pte.
>> > >> end lock;
>>
>> No, it is a little more complicated. You also have to include in the
>> tlb state into
According to J . A . Magallon:
> Please, I think it would be much more useful a patch against the latest
> 2.2.19-pre (if that one for 2.2.18 does not work, I have not tried)
> and the latest 2.4.1-ac14, that is what people experiments with.
There's no end of versions that people use.
Might I
On Thu, 15 Feb 2001, Alan Cox wrote:
> > Calibrating delay loop... 466.94 BogoMIPS
> > Memory: 62836k/65536k available (712k kernel code, 2312k reserved, 188k
> > data, 56k init, 0k highmem)
> > Checking if this processor honours the WP bit even in supervisor mode...
> >
> > Here it freezes
> A. Datagram protocols do not work with mtus not allowing to send
>512 byte frames (even DNS).
I ran DNS reliably over AX.25 networks. They have an MTU of 216. They work.
Please explain your claim in more detail. Please explain why the real world
is violating your version of the laws of
On 02.15 Justin T. Gibbs wrote:
> >All of my boxes with that card are on 2.2.16. The rest are on 2.4.1, so I
> >don't really have a need to test 2.2.18 as I would rather be on 2.4.x for
> >all of my boxes.
>
> Well, I'll try and generate patches against 2.2.16 soon. I probably
> need to
> Calibrating delay loop... 466.94 BogoMIPS
> Memory: 62836k/65536k available (712k kernel code, 2312k reserved, 188k
> data, 56k init, 0k highmem)
> Checking if this processor honours the WP bit even in supervisor mode...
>
> Here it freezes forever... My cpu:
>
> vendor_id : CyrixInstead
In article <[EMAIL PROTECTED]>,
Kanoj Sarcar <[EMAIL PROTECTED]> wrote:
>>
>> Will you please go off and prove that this "problem" exists on some x86
>> processor before continuing this rant? None of the PII, PIII, Athlon,
>
>And will you please stop behaving like this is not an issue?
This
On Thu, 15 Feb 2001, Michal Jaegermann wrote:
> > Well, the situation is improving, I suppose ...
> >
> > Under kernel 2.4.0 and 2.4.1, a dd of about 1 4k blocks would cause
> > the system to go technicolor and lock up.
>
> On UP1100 which I have here somehow this looks a bit different
On Thu, 15 Feb 2001, David D.W. Downey wrote:
> Seriously though folks, look at who's doing this!
>
> They've already tried once to sue 'Linux', were told they couldn't because
> Linux is a non-entity (or at least one that they can not effectively sue
> due to the classification Linux holds),
Hello!
> Maybe someone want to say me what does it mean and how serious it is?
It means that debugging messages are still not disabled in 2.4.x 8)
> Any fixes?
These ones can be ignored.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Seriously though folks, look at who's doing this!
They've already tried once to sue 'Linux', were told they couldn't because
Linux is a non-entity (or at least one that they can not effectively sue
due to the classification Linux holds), and now they can't use their
second favorite tactic for
On Thu, Feb 15, 2001 at 12:49:29PM -0500, John Jasen wrote:
>
> Well, the situation is improving, I suppose ...
>
> Under kernel 2.4.0 and 2.4.1, a dd of about 1 4k blocks would cause
> the system to go technicolor and lock up.
On UP1100 which I have here somehow this looks a bit different
Hi,
I have a HP Pavilon 5290 laptop. It has a a mini-pci modem/ethernet combo
integrated card.
Searching in the Internet I found a patch for the ethernet to work with the
tulip driver for kernel 2.2.x series, However, I found no patch for the 2.4.x
kernel series, so I made one.
Here is what
http://linux24.sourceforge.net/ is a good place to start.
> I am not subscribed to the list yet, please CC to me your reply.
> Thank you very much,
You should be.
Also I suggest you read the lkml FAQ at http://www.tux.org/lkml/ . It should
give quite a few starting points.
-gabi
>
Hello!
> Please cite an exact RFC reference.
No need to cite RFC, this is plain sillogism.
A. Datagram protocols do not work with mtus not allowing to send
512 byte frames (even DNS).
B. Accoutning, classification, resource reervation does not work on
fragmented packets.
-> IP suite is
Hi!
I think that this is a bug. The buffer is always released except in this
case.
Bye.
*** /usr/src/linux-2.4.1/fs/ext2/namei.cTue Dec 12 16:48:22 2000
--- namei.c.new Thu Feb 15 20:42:45 2001
***
*** 235,240
---
>
> On Thu, 15 Feb 2001, Kanoj Sarcar wrote:
>
> > No. All architectures do not have this problem. For example, if the
> > Linux "dirty" (not the pte dirty) bit is managed by software, a fault
> > will actually be taken when processor 2 tries to do the write. The fault
> > is solely to make
Kanoj Sarcar wrote:
> > Is the sequence
> > << lock;
> > read pte
> > pte |= dirty
> > write pte
> > >> end lock;
> > or
> > << lock;
> > read pte
> > if (!present(pte))
> > do_page_fault();
> > pte |= dirty
> > write pte.
> > >> end lock;
>
> No, it is a little more complicated. You also
Alan Cox wrote:
> I'd rather keep the existing initialisation behaviour of using the eeprom
> for 2.2. There are also some power management cases where I am not sure
> the values are restored on the pcnet/pci.
>
> For 2.2 conservatism is the key. For 2.4 by all means default to CSR12-14 and
>
>
> Kanoj Sarcar wrote:
> >
> > Okay, I will quote from Intel Architecture Software Developer's Manual
> > Volume 3: System Programming Guide (1997 print), section 3.7, page 3-27:
> >
> > "Bus cycles to the page directory and page tables in memory are performed
> > only when the TLBs do not
Manfred Spraul <[EMAIL PROTECTED]> writes:
> "Eric W. Biederman" wrote:
> >
> > But the gcc bounds checking work is the ultimate buffer overflow fix.
> > You can recompile all of your trusted applications, and libraries with
> > it and be safe from one source of bugs.
> >
>
> void main(int
Manfred Spraul wrote:
> Is the sequence
> << lock;
> read pte
> pte |= dirty
> write pte
> >> end lock;
> or
> << lock;
> read pte
> if (!present(pte))
> do_page_fault();
> pte |= dirty
> write pte.
> >> end lock;
or more generally
<< lock;
read pte
if (!present(pte) || !writable(pte))
On Thu, 15 Feb 2001, Kanoj Sarcar wrote:
> No. All architectures do not have this problem. For example, if the
> Linux "dirty" (not the pte dirty) bit is managed by software, a fault
> will actually be taken when processor 2 tries to do the write. The fault
> is solely to make sure that the
Hi
I have't seen any posts about this, maybe nobody haveing
problems? I can't boot ac13/ac14 on my machine. 2.4.1ac12 was ok.
Linux version 2.4.1-ac13 (root@singular) (gcc version 2.95.3 20010125
(prerelease)) #2 Thu Feb 15 02:23:31 CET 2001
BIOS-provided physical RAM map:
BIOS-e820:
Hey, just found this one out.
I've got a sony vaio 505tx, running linux-2.4.1-ac1, and I've got all
the good stuff turned.
With APM turned, and using USB uhci-alt driver (all as modules), if you
put the laptop to sleep with any (and I mean *any*) usb devices plugged
in, it will hard lock upon
>
> Kanoj Sarcar wrote:
> > > Here's the important part: when processor 2 wants to set the pte's dirty
> > > bit, it *rereads* the pte and *rechecks* the permission bits again.
> > > Even though it has a non-dirty TLB entry for that pte.
> > >
> > > That is how I read Ben LaHaise's description,
Kanoj Sarcar wrote:
>
> Okay, I will quote from Intel Architecture Software Developer's Manual
> Volume 3: System Programming Guide (1997 print), section 3.7, page 3-27:
>
> "Bus cycles to the page directory and page tables in memory are performed
> only when the TLBs do not contain the
To discover possible locking limitations to scalability, I have collected
locking statistics on a 2-way, 4-way, and 8-way performing as networked
database servers. I patched the [48]-way kernels with Kravetz's multiqueue
patch in the hope that mitigating runqueue_lock contention might better
> with bogus mtu values sort of 552 or even 296, but also jailed them
> to some proxy or masquearding domain), but it is still right: IP
> with mtu lower 576 is not full functional.
Please cite an exact RFC reference.
The 576 byte requirement is for reassembled packets handled by the host.
That
Kanoj Sarcar wrote:
> > Here's the important part: when processor 2 wants to set the pte's dirty
> > bit, it *rereads* the pte and *rechecks* the permission bits again.
> > Even though it has a non-dirty TLB entry for that pte.
> >
> > That is how I read Ben LaHaise's description, and his test
Nathan Walp wrote:
>
> The fix in ac14 for the ac13 patch that killed the tulip driver doesn't
> quite work either:
>
I need more details:
does it immediately time out (after a few seconds), or a after a few
minutes.
Which network speed do you use? 100MBit half duplex?
Could you please run
On Thu, Feb 15, 2001 at 06:33:36AM -0500, safemode wrote:
> > What's the nature of the VIA chipset problems? I want to get a new system
>
> There are no problems with 2.2.x.
I'm very glad to hear that because the AMD chips are the obvious
choice for a lot of people(all?).
> (classic), get the
>
> [Added Linus and linux-kernel as I think it's of general interest]
>
> Kanoj Sarcar wrote:
> > Whether Jamie was trying to illustrate a different problem, I am not
> > sure.
>
> Yes, I was talking about pte_test_and_clear_dirty in the earlier post.
>
> > Look in mm/mprotect.c. Look at the
Hello!
> Kernel 2.4.x apparently disregards my ppp options MTU setting of 552
> and sets mss=536 (=> MTU=576).
Yes, default configuration is not allowed to advertise mss<536.
The limit is controlled via /proc/sys/net/ipv4/route/min_adv_mss,
you can change it to 256.
Default of 536 is sadistic
Messages in my kernel log:
node1 kernel: sending pkt_too_big to self
node1 kernel: KERNEL: assertion (tp->lost_out == 0) failed at
tcp_input.c(1202):tcp_remove_reno_sacks
Kernel 2.4.1-ac13.
Maybe someone want to say me what does it mean and how serious it is?
Any fixes?
Thanks.
--
Andrius
I'm trying to update some patches of Harald's to work
with the official 2.4.0 international patches. He had
a very nice unofficial patch set that doesn't use a
table, it just sees what is in /proc/crypto. I fixed
a few bugs and it worked marvelously with unofficial
test9 patches all the way up to
The fix in ac14 for the ac13 patch that killed the tulip driver doesn't
quite work either:
Feb 15 13:04:16 patience kernel: LDT allocated for cloned task!
Feb 15 13:04:55 patience kernel: NETDEV WATCHDOG: eth0: transmit timed
out
Feb 15 13:05:27 patience last message repeated 4 times
Feb 15
>
> [Added Linus and linux-kernel as I think it's of general interest]
>
> Kanoj Sarcar wrote:
> > Whether Jamie was trying to illustrate a different problem, I am not
> > sure.
>
> Yes, I was talking about pte_test_and_clear_dirty in the earlier post.
>
> > Look in mm/mprotect.c. Look at the
>> repeated exposition to Linux...
Hey isn't that _exposure_ to Linux? Or one of Dubya's words? Like
strategery?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of fsnchzjr
Sent: Thursday, February 15, 2001 12:49 PM
To: '[EMAIL PROTECTED]'
Subject: Linux
* fsnchzjr ([EMAIL PROTECTED]) wrote:
> Watch Microsoft's Jim Allchin go Linux-bashing!!!
> Nice little article on how we're all going to die of herpes from our
> repeated exposition to Linux...
> http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?tag=ltnc
Just
Well, the situation is improving, I suppose ...
Under kernel 2.4.0 and 2.4.1, a dd of about 1 4k blocks would cause
the system to go technicolor and lock up.
Now, under 2.4.1-ac13, at about 11000 blocks, it goes technicolor, but
doesn't lock up until somewhere between 13000 and 2.
Watch Microsoft's Jim Allchin go Linux-bashing!!!
Nice little article on how we're all going to die of herpes from our
repeated exposition to Linux...
http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?ta
g=ltnc
-
To unsubscribe from this list: send the line "unsubscribe
What's the current status of the loop-# patch? Haven't seen anything
since loop-4, which doesn't apply clean to 2.4.1-ac14 (one hunk is
rejected in loop.c, many others apply with fuzz).
I am waiting in anticipation of the folding of this patch into the
mainline kernel.
IIRC, Jens said he was
1 - 100 of 332 matches
Mail list logo
