On Thu, 15 Dec 2016, Jason A. Donenfeld wrote:
> > I'd still drop the "24" unless you really think we're going to have
> > multiple variants coming into the kernel.
>
> Okay. I don't have a problem with this, unless anybody has some reason
> to the contrary.
What if the 2/4-round version falls an
On Tue, 10 May 2016, David Miller wrote:
> Every single variable name and function name dealing with this IP
> option uses "srr", therefore I don't think we should adjust the
> documentation either.
>
> "srr" covers both the loose source route option and the strict source
> route option.
Now that
s
meant here? If so, RFC791 then refers to the same as "SSRR", as in "strict
source and record route". Does the patch below clears that up or did I
confuse it with something else?
Thanks,
Christian.
Signed-off-by: Christian Kujau
diff --git a/Documentation/networking/ip-s
On Sun, 2 Sep 2007, Stephen Hemminger wrote:
Vendor module calls kernel api incorrectly. dev_set_promiscuity requires
that the calling thread hold rtnl mutex (ie call rtnl_lock). It's their bug,
netdev doesn't want to hear about it.
OK, that's all I needed to know. Thank you both for your comme
Wow, I should really update more often. Skipping the last -rc versions
AND adding a new device (zd1211rw) to the box turns out to be quite
interesting ([0],[1]).
However, this time loading of a (proprietary) module is involved. Knowing
that lkml cannot really help here (and I should contact vmw
Hi,
after upgrading to 2.6.23-rc5 (and applying davem's fix [0]), lockdep
was quite noisy when I tried to shape my external (wireless) interface:
[ 6400.534545] FahCore_78.exe/3552 just changed the state of lock:
[ 6400.534713] (&dev->ingress_lock){-+..}, at: []
netif_receive_skb+0x2d5/0x3c0
On Sun, 2 Sep 2007, Herbert Xu wrote:
You want this patch (by davem).
I applied the patch and the box is up for 1hr now. Since I was able to
reproduce the oops pretty reliable with this bittorrent thingy, I
did the same a few times now, but the box did NOT crash :)
Unfortunately people are
Hi,
today I switched from 2.6.22.3 to 2.6.23-rc5 (skipped quite a few -rc
versions due to lack of time), and the box keeps panicking under certain
circumstances. I suspected disk related problems, because: when the box
is up, I usually resume ~10 bittorrent files. When doing this, each
file (
On Fri, 6 Apr 2007, Christian Kujau wrote:
but yes, this seem to be different problems, for the curious among you I've
put details here: http://nerdbynature.de/bits/2.6.20.4/db2/
that's http://nerdbynature.de/bits/2.6.20.4/db1/2/ sorry.
--
BOFH excuse #270:
Someone has mes
On Wed, 4 Apr 2007, Christian Kujau wrote:
Maybe it's a real locking problem. Here are some more
suggestions for testing (if you don't find anything better):
- try without SMP, so: 'acpi=off lapic nosmp'
We were able to have our hosting provider to replace the 8139too with
On Wed, 4 Apr 2007, Jarek Poplawski wrote:
So, it's a lot sooner than before. (BTW, isn't there anything
in debug log?)
No, nothing. I've set up remote-syslgging to the other node (node1
logging to node2 and vice versa) - nothing :(
I see both CPUs did interrupt handling again.
Yes, when
On Tue, 3 Apr 2007, Francois Romieu wrote:
Christian Kujau <[EMAIL PROTECTED]> :
If the apic voodoo makes no difference, you can:
1 - leave it enabled
Well, we tried to boot with ACPI compiled in again, but disabled during
boot:
- acpi=off lapic, crashed after 1h (almost exactly) of s
On Tue, 3 Apr 2007, Jarek Poplawski wrote:
Did you try with 8139cp instead of 8139too?
Tried that, 8139cp could not be loaded :(
(Maybe even try some other card to narrow the problem?)
You could also try to test without ehci, if it's possible.
USB has been disabled completely. After booting
On Mon, 2 Apr 2007, Chuck Ebbert wrote:
Where is the info from before you changed to "noapic"? Or were the
machines always using XT-PIC for all the interrupts???
We booted with 'acpi=off lapic' (with ACPI options compiled in, to be
able to boot with acpi=on later on) and the box locked up agai
On Tue, 3 Apr 2007, Jarek Poplawski wrote:
Did you try with 8139cp instead of 8139too?
I forgot about that, thanks.
(Maybe even try some other card to narrow the problem?)
We're try to convince our hosting provider to replace the NIC with a
e1000.
You could also try to test without ehci
On Tue, 3 Apr 2007, Len Brown wrote:
Which increased stability, disabling ACPI, or disabling the IOAPIC?
To be honest, we're not sure. See below.
Your box has MPS, so you should be able to use the IOAPIC in either mode.
MPS - Multiprocessor Specification? SMP? Yes, it'd be good to use the
On Mon, 2 Apr 2007, Chuck Ebbert wrote:
Where is the info from before you changed to "noapic"? Or were the
machines always using XT-PIC for all the interrupts???
XT-PIC is only used since we switched to noapic, before there was
IO-APIC-fasteoi on both ethernet cards and interrupts were balance
On Mon, 2 Apr 2007, Chuck Ebbert wrote:
Please see http://nerdbynature.de/bits/2.6.20.4/ for details for both
hosts and feel free to ask for more details. Although both boxes are in
production we'll be happy test more bootoptions/patches and the like.
Where is the info from before you changed t
Hi there,
we have serious problems with 2 of our servers: both shiny new amd64
dual core, with both 2GB RAM, 32bit kernel+userland (Debian/testing).
Both servers have 2 NICs, RTL8139 (eth0, irq10) and RTL8169s
(eth1, irq11).
Both boxes are running fine but after "a while" they lock up and
ev
19 matches
Mail list logo
