On Tue, Jan 05, 2021 at 12:41:04AM +0100, Arnd Bergmann wrote:
> Phil Oester reported that a fix for a possible buffer overrun that I
> sent caused a regression that manifests in this output:
>
> Event Message: A PCI parity error was detected on a component at bus 0
> devi
On Sun, Jan 03, 2021 at 05:26:29PM +0100, Arnd Bergmann wrote:
> Thank you for the report and bisecting the issue, and sorry this broke
> your system!
>
> Fortunately, the patch is fairly small, so there are only a limited number
> of things that could go wrong. I haven't tried to analyze that
ice 5
function 0.
Severity: Critical
Message ID: PCI1308
I reverted this single patch and the errors went away.
Thoughts?
Phil Oester
Got the below on -rc3. Tried applying the "more info" patch from Arjan
(http://marc.info/?l=linux-kernel=120336371506283=2), but that just
made the warning go away.
Phil
ACPI: EC: Look up EC in DSDT
[ cut here ]
WARNING: at arch/x86/mm/ioremap.c:137
Got the below on -rc3. Tried applying the more info patch from Arjan
(http://marc.info/?l=linux-kernelm=120336371506283w=2), but that just
made the warning go away.
Phil
ACPI: EC: Look up EC in DSDT
[ cut here ]
WARNING: at arch/x86/mm/ioremap.c:137
On Mon, Feb 04, 2008 at 07:27:53PM -0800, Linus Torvalds wrote:
> kgdb? Not so interesting. We have many more hard problems happening at
> user sites, not in developer hands.
FWIW, I'm not a fulltime developer by any means, but on occasion
I have fixed a few bugs in the netfilter area of the
On Mon, Feb 04, 2008 at 07:27:53PM -0800, Linus Torvalds wrote:
kgdb? Not so interesting. We have many more hard problems happening at
user sites, not in developer hands.
FWIW, I'm not a fulltime developer by any means, but on occasion
I have fixed a few bugs in the netfilter area of the
On Sun, Jul 29, 2007 at 06:59:26AM +0100, Darryl L. Miles wrote:
> The problems start around time index 09:21:39.860302 when the CLIENT issues
> a TCP packet with SACK option set (seemingly for a data segment which has
> already been seen) from that point on the connection hangs.
I'd say most
On Sun, Jul 29, 2007 at 06:59:26AM +0100, Darryl L. Miles wrote:
The problems start around time index 09:21:39.860302 when the CLIENT issues
a TCP packet with SACK option set (seemingly for a data segment which has
already been seen) from that point on the connection hangs.
I'd say most
On Sun, Jul 08, 2007 at 04:52:52PM -0700, Linus Torvalds wrote:
> Anybody? Should I make just the shortlogs available instead (I don't save
> those, but I post those for the later -rc's - usually the -rc1 and -rc2's
> are too big for the mailing list, but they are still a lot smaller and
> more
On Sun, Jul 08, 2007 at 04:52:52PM -0700, Linus Torvalds wrote:
Anybody? Should I make just the shortlogs available instead (I don't save
those, but I post those for the later -rc's - usually the -rc1 and -rc2's
are too big for the mailing list, but they are still a lot smaller and
more
On Sat, Apr 28, 2007 at 10:38:45PM +0200, Alessandro Suardi wrote:
> skb_set_timestamp I can figure out, but the rest is a bit
> too hard for me... if anyone has already an idea of how
> to fix this, I'd be most grateful.
Did you ask Cisco?
Phil
-
To unsubscribe from this list: send the line
On Sat, Apr 28, 2007 at 10:38:45PM +0200, Alessandro Suardi wrote:
skb_set_timestamp I can figure out, but the rest is a bit
too hard for me... if anyone has already an idea of how
to fix this, I'd be most grateful.
Did you ask Cisco?
Phil
-
To unsubscribe from this list: send the line
On Sat, Dec 02, 2006 at 04:40:54PM +0100, Helge Deller wrote:
> > The bug happens when gentoo wants to bring up eth0 (starting the lo
> > device works fine), even a simple 'ifconfig eth0 192.168.0.11' will
> > crash the kernel.
> I just faced the same problem, but on a HPPA (PARISC) box with
On Sat, Dec 02, 2006 at 04:40:54PM +0100, Helge Deller wrote:
The bug happens when gentoo wants to bring up eth0 (starting the lo
device works fine), even a simple 'ifconfig eth0 192.168.0.11' will
crash the kernel.
I just faced the same problem, but on a HPPA (PARISC) box with 32bit
Getting an oops on boot here, caused by commit
e81c73596704793e73e6dbb478f41686f15a4b34 titled
"[NET]: Fix MAX_HEADER setting".
Reverting that patch fixes things up for me. Dave?
Phil
Bringing up interface eth0:
skb_over_panic: text:c02af809 len:56 put:16 head:d7e213c0
data:d7e213d0
Getting an oops on boot here, caused by commit
e81c73596704793e73e6dbb478f41686f15a4b34 titled
[NET]: Fix MAX_HEADER setting.
Reverting that patch fixes things up for me. Dave?
Phil
Bringing up interface eth0:
skb_over_panic: text:c02af809 len:56 put:16 head:d7e213c0
data:d7e213d0
I am seeing some odd behaviour from a dual port Intel e1000
nic. When I have only one port of the dual port nic
plugged in, all is well. But when I plug the 2nd port in,
the box goes to pieces. The counters for the interfaces on the
nic start moving in reverse, and the interfaces start spewing
I am seeing some odd behaviour from a dual port Intel e1000
nic. When I have only one port of the dual port nic
plugged in, all is well. But when I plug the 2nd port in,
the box goes to pieces. The counters for the interfaces on the
nic start moving in reverse, and the interfaces start spewing
On Tue, Aug 09, 2005 at 12:34:10AM +0200, Petr Vandrovec wrote:
> It looks like that ACPI is gone... Can you recheck your .config that
> you still have ACPI enabled?
> Petr
Hmmff...yup, you are correct. Which is interesting, since I just
Just booted a box on 2.6.13-rc6, and noticed that it now only reports
a single processor, whereas on 2.6.12.4 it reports two. While there
is only one physical processor, I wonder if this change was intentional,
since I can't find anything in the changelog about SMT changes.
Below is dmesg output
Just booted a box on 2.6.13-rc6, and noticed that it now only reports
a single processor, whereas on 2.6.12.4 it reports two. While there
is only one physical processor, I wonder if this change was intentional,
since I can't find anything in the changelog about SMT changes.
Below is dmesg output
On Tue, Aug 09, 2005 at 12:34:10AM +0200, Petr Vandrovec wrote:
It looks like that ACPI is gone... Can you recheck your .config that
you still have ACPI enabled?
Petr
Hmmff...yup, you are correct. Which is interesting, since I just copied
On Fri, Jul 08, 2005 at 11:25:08PM +0200, Alexander Nyberg wrote:
> fre 2005-07-08 klockan 23:12 +0200 skrev Rudo Thomas:
> > Hello, guys.
> >
> > Time started to pass faster with 2.6.12.2 (actually, it was 2.6.12-ck3
> > which is based on it). I have isolated the cause of the problem:
>
> I bet
On Fri, Jul 08, 2005 at 11:25:08PM +0200, Alexander Nyberg wrote:
fre 2005-07-08 klockan 23:12 +0200 skrev Rudo Thomas:
Hello, guys.
Time started to pass faster with 2.6.12.2 (actually, it was 2.6.12-ck3
which is based on it). I have isolated the cause of the problem:
I bet you this
On Wed, Apr 13, 2005 at 12:45:51PM +, Paul Slootman wrote:
> We have a variety of Dell rackmount systems, also on Cyclades, and see
> this mess everywhere.
>
> I had reported this problem a little while ago, see
> http://marc.theaimsgroup.com/?l=linux-kernel=111036598927105=2
> but
On Wed, Apr 13, 2005 at 12:45:51PM +, Paul Slootman wrote:
We have a variety of Dell rackmount systems, also on Cyclades, and see
this mess everywhere.
I had reported this problem a little while ago, see
http://marc.theaimsgroup.com/?l=linux-kernelm=111036598927105w=2
but unfortunately
On Sat, Mar 26, 2005 at 03:10:05PM +, Russell King wrote:
> Doesn't matter. The problem is that dwmw2's NS16550A patch (from ages
> ago) changes the prescaler setting for this device so we can use the
> higher speed baud rates. This means any programmed divisor (programmed
> at early serial
On Sat, Mar 26, 2005 at 03:10:05PM +, Russell King wrote:
Doesn't matter. The problem is that dwmw2's NS16550A patch (from ages
ago) changes the prescaler setting for this device so we can use the
higher speed baud rates. This means any programmed divisor (programmed
at early serial
On Sat, Mar 26, 2005 at 04:37:29PM +, Russell King wrote:
> > serio: i8042 AUX port at 0x60,0x64 irq 12
> > serio: i8042 KBD port at 0x60,0x64 irq 1
> > Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
Garbage here
Sorry -- I was relying upon my (flawed) memory of
On Sat, Mar 26, 2005 at 04:37:29PM +, Russell King wrote:
> > But intererstingly, on identical boxes, the garbage only appears on
> > those hooked up to a PortMaster device - those using a Cyclades never
> > display this problem. (???)
>
> Sorry, I don't understand your scenarios. Can you
On Sat, Mar 26, 2005 at 03:10:05PM +, Russell King wrote:
> Doesn't matter. The problem is that dwmw2's NS16550A patch (from ages
> ago) changes the prescaler setting for this device so we can use the
> higher speed baud rates. This means any programmed divisor (programmed
> at early serial
On Sat, Mar 26, 2005 at 03:10:05PM +, Russell King wrote:
Doesn't matter. The problem is that dwmw2's NS16550A patch (from ages
ago) changes the prescaler setting for this device so we can use the
higher speed baud rates. This means any programmed divisor (programmed
at early serial
On Sat, Mar 26, 2005 at 04:37:29PM +, Russell King wrote:
But intererstingly, on identical boxes, the garbage only appears on
those hooked up to a PortMaster device - those using a Cyclades never
display this problem. (???)
Sorry, I don't understand your scenarios. Can you explain
On Sat, Mar 26, 2005 at 04:37:29PM +, Russell King wrote:
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
Garbage here
Sorry -- I was relying upon my (flawed) memory of the
On Tue, Mar 22, 2005 at 10:39:43AM +0200, [EMAIL PROTECTED] wrote:
>
> computer's main job is to be router on small LAN with 10 users and some
> services like qmail, apache, proftpd, shoutcast, squid, and ices on slack
> 10.1. Iptables and tc are used to limit bandwiwdth and the two bandwidthd
On Tue, Mar 22, 2005 at 10:39:43AM +0200, [EMAIL PROTECTED] wrote:
computer's main job is to be router on small LAN with 10 users and some
services like qmail, apache, proftpd, shoutcast, squid, and ices on slack
10.1. Iptables and tc are used to limit bandwiwdth and the two bandwidthd
On Mon, Feb 21, 2005 at 02:21:50PM +0100, Piotr Kowalczyk wrote:
> Hi all,
>
> I'm suffering from destination cache overflow on router running kernel
> 2.6.10. This wouldn't be anything special if not different numbers
> reported by slabinfo and the real state. It's worth to mention that
>
On Mon, Feb 21, 2005 at 02:21:50PM +0100, Piotr Kowalczyk wrote:
Hi all,
I'm suffering from destination cache overflow on router running kernel
2.6.10. This wouldn't be anything special if not different numbers
reported by slabinfo and the real state. It's worth to mention that
there was
On Sun, Jan 30, 2005 at 06:01:46PM +, Russell King wrote:
> > OTOH, if conntrack isn't loaded forwarded packet are never defragmented,
> > so frag_list should be empty. So probably false alarm, sorry.
>
> I've just checked Phil's mails - both Phil and myself are using
> netfilter on the
On Sun, Jan 30, 2005 at 03:34:49PM +, Russell King wrote:
> I think the case against the IPv4 fragmentation code is mounting.
> However, without knowing what the expected conditions for this code,
> (eg, are skbs on the fraglist supposed to have NULL skb->dst?) I'm
> unable to progress this
On Fri, Jan 28, 2005 at 12:17:01AM +, Russell King wrote:
> On Thu, Jan 27, 2005 at 12:33:26PM -0800, David S. Miller wrote:
> > So they won't be listed in /proc/net/rt_cache (since they've been
> > removed from the lookup table) but they will be accounted for in
> > /proc/net/stat/rt_cache
On Thu, Jan 27, 2005 at 07:25:04PM +, Russell King wrote:
> Can you provide some details, eg kernel configuration, loaded modules
> and a brief overview of any netfilter modules you may be using.
>
> Maybe we can work out what's common between our setups.
Vanilla 2.6.10, though I've been
On Thu, Jan 27, 2005 at 04:49:18PM +, Russell King wrote:
> so obviously the GC does appear to be working - as can be seen from the
> number of entries in /proc/net/rt_cache. However, the number of objects
> in the slab cache does grow day on day. About 4 days ago, it was only
> about 600
On Thu, Jan 27, 2005 at 04:49:18PM +, Russell King wrote:
so obviously the GC does appear to be working - as can be seen from the
number of entries in /proc/net/rt_cache. However, the number of objects
in the slab cache does grow day on day. About 4 days ago, it was only
about 600 active
On Thu, Jan 27, 2005 at 07:25:04PM +, Russell King wrote:
Can you provide some details, eg kernel configuration, loaded modules
and a brief overview of any netfilter modules you may be using.
Maybe we can work out what's common between our setups.
Vanilla 2.6.10, though I've been seeing
On Fri, Jan 28, 2005 at 12:17:01AM +, Russell King wrote:
On Thu, Jan 27, 2005 at 12:33:26PM -0800, David S. Miller wrote:
So they won't be listed in /proc/net/rt_cache (since they've been
removed from the lookup table) but they will be accounted for in
/proc/net/stat/rt_cache until the
reverted to 2.2.19 on the boxes (which are RedHat 7.1 incidentally), and
these problems went away.
Any ideas why this is happening?
-Phil Oester
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
reverted to 2.2.19 on the boxes (which are RedHat 7.1 incidentally), and
these problems went away.
Any ideas why this is happening?
-Phil Oester
-
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
Works for me. Running cerberus on a machine w/2gb RAM - deadlocks on 2.4.5
vanilla, keeps running on 2.4.5aa1.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Andrea Arcangeli
Sent: Saturday, May 26, 2001 10:33 AM
To: [EMAIL PROTECTED]
Subject: 2.4.5aa1
Works for me. Running cerberus on a machine w/2gb RAM - deadlocks on 2.4.5
vanilla, keeps running on 2.4.5aa1.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Andrea Arcangeli
Sent: Saturday, May 26, 2001 10:33 AM
To: [EMAIL PROTECTED]
Subject: 2.4.5aa1
configured using proc fs.
This is particularly useful in load-balanced server farms where loopback
addresses are configured for direct client-server traffic. Without this
patch, Linux will respond to arp requests for the virtual IPs, making
effective load balancing difficult.
-Phil Oester
diff -r
configured using proc fs.
This is particularly useful in load-balanced server farms where loopback
addresses are configured for direct client-server traffic. Without this
patch, Linux will respond to arp requests for the virtual IPs, making
effective load balancing difficult.
-Phil Oester
diff -r
This may not matter in terms of performance, but many devices on Intel 815
chipset machines show up as unknown. Any ideas when (or if) full support
for the 815 is planned?
-Phil
Output of lspci:
00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and
Memory Controller Hub
This may not matter in terms of performance, but many devices on Intel 815
chipset machines show up as unknown. Any ideas when (or if) full support
for the 815 is planned?
-Phil
Output of lspci:
00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and
Memory Controller Hub
I've been having continual unexplained lockup problems since converting one
of my outgoing qmail servers to 2.4.x. This has been discussed before on
this list, where the symptoms are that anything typed on console takes
forever to actually come up, and after a few minutes the machine is so
I've been having continual unexplained lockup problems since converting one
of my outgoing qmail servers to 2.4.x. This has been discussed before on
this list, where the symptoms are that anything typed on console takes
forever to actually come up, and after a few minutes the machine is so
at this time, even though it goes hours without any
profile captures.
Upon powercycling, the qmail partition is loaded with thousands of errors -
which could be caused by the power cycling, or by something kernel related.
In the meantime, I've had to revert to 2.2.19 any time I do intense
mailings.
-Phil
at this time, even though it goes hours without any
profile captures.
Upon powercycling, the qmail partition is loaded with thousands of errors -
which could be caused by the power cycling, or by something kernel related.
In the meantime, I've had to revert to 2.2.19 any time I do intense
mailings.
-Phil
I actually had the problem with lack-of-lex also, but worked through that...
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Alan Cox
Sent: Tuesday, March 06, 2001 4:51 PM
To: J . A . Magallon
Cc: Phil Oester; [EMAIL PROTECTED]
Subject: Re: Error
one more try...
anyone else get the following:
make[5]: Entering directory
`/usr/src/linux-2.4.2-ac13/drivers/scsi/aic7xxx/aicasm'
lex -t aicasm_scan.l > aicasm_scan.c
gcc -I/usr/include -ldb aicasm_gram.c aicasm_scan.c aicasm.c
aicasm_symbol.c -o aicasm
aicasm_symbol.c:39: db/db_185.h: No
anyone else get the following:
make[5]: Entering directory `
-
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/
anyone else get the following:
make[5]: Entering directory `
-
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/
one more try...
anyone else get the following:
make[5]: Entering directory
`/usr/src/linux-2.4.2-ac13/drivers/scsi/aic7xxx/aicasm'
lex -t aicasm_scan.l aicasm_scan.c
gcc -I/usr/include -ldb aicasm_gram.c aicasm_scan.c aicasm.c
aicasm_symbol.c -o aicasm
aicasm_symbol.c:39: db/db_185.h: No such
I actually had the problem with lack-of-lex also, but worked through that...
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Alan Cox
Sent: Tuesday, March 06, 2001 4:51 PM
To: J . A . Magallon
Cc: Phil Oester; [EMAIL PROTECTED]
Subject: Re: Error
65 matches
Mail list logo
