From: Jan Engelhardt <[EMAIL PROTECTED]>
Date: Thu, 7 Feb 2008 00:42:52 +0100 (CET)
>
> On Feb 6 2008 15:26, David Miller wrote:
> >Subject: partition sysfs OOPS in current GIT
> >
> >
> >I get the following OOPS from udevd during bootup
On Feb 6 2008 15:26, David Miller wrote:
>Subject: partition sysfs OOPS in current GIT
>
>
>I get the following OOPS from udevd during bootup on
>sparc64:
>
>[0.982046] \|/ \|/
>[0.982054] &qu
From: Daniel Smolik <[EMAIL PROTECTED]>
Date: Thu, 31 Jan 2008 21:24:06 +0100
> Hi,
> I today work on my E450 and get this :-(. I run vanilla 2.6.20.
There were several TCP bugs fixes in 2.6.20.1 and later,
any one of which could have caused your OOPS.
-
To unsubscribe from this li
karotka kernel: /_| \__/ |_\
Jan 31 15:25:09 karotka kernel: \__U_/
Jan 31 15:25:09 karotka kernel: swapper(0): Oops [#1]
Jan 31 15:25:09 karotka kernel: TSTATE: 004480009606 TPC:
0062486c TNPC: 00624870 Y: 0024Not tainted
Jan 31 15:25:09 karo
karotka kernel: \__U_/
Jan 31 15:25:09 karotka kernel: swapper(0): Oops [#1]
Jan 31 15:25:09 karotka kernel: TSTATE: 004480009606 TPC: 0062486c TNPC: 00624870 Y: 0024Not
tainted
Jan 31 15:25:09 karotka kernel: TPC:
Jan 31 15:25:09 karotka kernel: g0:
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Mon, 14 Jan 2008 07:09:22 +0100
> But I agree to your suggestion, that will allow us to properly
> handle packets with IP options. I'll take care of this.
Thanks a lot Patrick.
-
To unsubscribe from this list: send the line "unsubscribe sparclinux"
Herbert Xu wrote:
Patrick, please have a look at the former. In fact it's not just
that ihl may be bogus (which might be harmless as long as the REJECT
hook only gets called from within the IP stack), I think REJECT would
also do the wrong thing if the packet had IP options. So perhaps we
shoul
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sun, 06 Jan 2008 11:22:04 +1100
> [IPV4] raw: Strengthen check on validity of iph->ihl
>
> We currently check that iph->ihl is bounded by the real length and that
> the real length is greater than the minimum IP header length. However,
> we did not che
On Sun, Jan 06, 2008 at 02:02:14AM +, Al Viro wrote:
>
> E.g. what about ipt_REJECT.c::send_reset()? Or myri10ge_get_frag_header()?
Yes both look wrong.
Patrick, please have a look at the former. In fact it's not just
that ihl may be bogus (which might be harmless as long as the REJECT
hoo
On Sun, Jan 06, 2008 at 11:22:04AM +1100, Herbert Xu wrote:
> Actually if you read the code for ip_fast_csum it's obvious what has
> happened. %o1 == iph->ihl contains the value 2 which is bogus.
>
> [IPV4] raw: Strengthen check on validity of iph->ihl
>
> We currently check that iph->ihl is bo
On Sun, Jan 06, 2008 at 01:57:13AM +0100, Jan Engelhardt wrote:
>
> >@@ -304,7 +305,8 @@ static int raw_send_hdrinc(struct sock *sk, void *from,
> >size_t length,
> > goto error_fault;
> >
> > /* We don't modify invalid header */
> >-if (length >= sizeof(*iph) && iph->ihl * 4U
On Jan 6 2008 11:22, Herbert Xu wrote:
>@@ -271,6 +271,7 @@ static int raw_send_hdrinc(struct sock *sk, void *from,
>size_t length,
> int hh_len;
> struct iphdr *iph;
> struct sk_buff *skb;
>+ unsigned int iphlen;
> int err;
>
> if (length > rt->u.dst.dev->mtu)
Al Viro <[EMAIL PROTECTED]> wrote:
>
> ip_fast_csum() called from raw_send_hdrinc() from raw_sendmsg() ran through
> the page boundary into unmapped page... Bloody odd, that, seeing that
> we have checked iph->ihl * 4U <= length and had done
>err = memcpy_fromiovecend((void *)iph, from, 0
On Fri, Jan 04, 2008 at 06:37:36PM +0100, Mariusz Kozlowski wrote:
> Hello,
>
> This comes from the Linus latest linux-2.6 tree. Randomly happened.
> Can't reproduce that. More info below.
ip_fast_csum() called from raw_send_hdrinc() from raw_sendmsg() ran through
the page boundary into u
f800be0e4000
\|/ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
isic(9009): Oops [#1]
TSTATE: 008811009606 TPC: 00572f00 TNPC: 00572f04 Y:
Not tainted
TPC:
g0: f800bf729d40 g1:
Hello,
My U2E (without any hardware trouble, I have tested it with SUN vts)
randomly oopses (an oops by week...). I use a debian/testing with
2.6.23.8 official kernel.
fermat:[~] > uptime
14:41:03 up 11 days, 3:25, 5 users, load average: 1.24, 0.70, 0.35
fermat:[~] > un
ewire: fw-ohci: flush MMIO write before msleep
firewire: fw-ohci: dma_free_coherent needs IRQs enabled
They are all obviously unrelated to the bug.
[EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9160
>
>Summary: kernel oops in
From: "Tom \"spot\" Callaway" <[EMAIL PROTECTED]>
Date: Wed, 22 Aug 2007 17:44:41 -0400
> I'm not. Fedora is still on gcc 4.1.
>
> System.map says:
>
> 004778bc t rcu_start_batch
> 00477928 t __rcu_process_callbacks
> 00477b98 t rcu_process_callbacks
> 00477bd4 t
On Wed, 2007-08-22 at 13:39 -0700, David Miller wrote:
> From: "Tom \"spot\" Callaway" <[EMAIL PROTECTED]>
> Date: Wed, 22 Aug 2007 16:31:58 -0400
>
> > Got this oops with the attached config very quickly after init, threw me
> > back to the pro
From: "Tom \"spot\" Callaway" <[EMAIL PROTECTED]>
Date: Wed, 22 Aug 2007 16:31:58 -0400
> Got this oops with the attached config very quickly after init, threw me
> back to the prom. Firmware is fully updated on the box, latest SILO too.
>
> Starting udev: O
From: Meelis Roos <[EMAIL PROTECTED]>
Date: Tue, 21 Aug 2007 18:47:16 +0300 (EEST)
> I switched fro Ultra 1 to Ultra 5 with my intermittent boot hang
> debugging because of faster compilation. However, the "booting" kernel
> hangs later in boot process with this oops
> atyfb: 3D RAGE PRO (Mach64 GP, PQFP, PCI) [0x4750 rev 0x7c]
> atyfb: 4M SGRAM (1:1), 14.31818 MHz XTAL, 230 MHz PLL, 100 Mhz MCLK, 100 MHz
> XCLK
> Console: switching to colour frame buffer device 144x56
> atyfb: fb0: ATY Mach64 frame buffer device on PCI
> /[EMAIL PROTECTED],0/[EMAIL PROTECTED]
I switched fro Ultra 1 to Ultra 5 with my intermittent boot hang
debugging because of faster compilation. However, the "booting" kernel
hangs later in boot process with this oops after switching away from
serial console (? - I do use serial console actually, why is it telling
about
.
firewire-core loads ok but firewire-ohci gets the oops below. I tried
some traces that suggest the oops actually happens at
dma_sync_single_for_device but don't know if that is reliable.
A kernel with these modules included will not boot, as it cannot find
/dev/hda2 after the oops.
Hello,
Not sure this is still important as the kernel is a bit old
(2.6.18-4-sparc64-smp)
but I run into an oops on dual sparc64. The box is SUN ULTRA 60 - USII 2 x
450MHZ.
Unable to handle kernel paging request at virtual address 703ce000
tsk->{mm,active_mm}->c
]: Fix OOPS in all SBUS framebuffer drivers.
All of these drivers use a silly:
struct all_info {
struct fb_info info;
struct foo_par par;
};
struct all_info *all = kzalloc(sizeof(*all), GFP_KERNEL);
all->info.par = &all->par;
From: Narayan Newton <[EMAIL PROTECTED]>
Date: Tue, 20 Mar 2007 13:41:10 -0700
> Hi,
>
> I have been running netcat since around 10 AM yesterday morning on a
> patched kernel with netfilter enabled and have been unable to trigger
> this bug. Thank you for your work on this issue!
Thank you for t
On Tue, Mar 20, 2007 at 04:28:54PM -0500, Tom spot Callaway wrote:
> On Tue, 2007-03-20 at 19:52 +0100, BERTRAND =?utf-8?Q?Jo=EBl?= wrote:
> > Hello,
> >
> > I have tried to untar the sources of 2.6.21-rc4 kernel. My SS20 runs
> > with
> > 2.6.20.3/SMP.
>
> As Dave has recently point
On Tue, 2007-03-20 at 19:52 +0100, BERTRAND =?utf-8?Q?Jo=EBl?= wrote:
> Hello,
>
> I have tried to untar the sources of 2.6.21-rc4 kernel. My SS20 runs
> with
> 2.6.20.3/SMP.
As Dave has recently pointed out, sparc32 is unmaintained.
sparc32 SMP is known to be broken. And bug r
Hi,
I have been running netcat since around 10 AM yesterday morning on a
patched kernel with netfilter enabled and have been unable to trigger
this bug. Thank you for your work on this issue!
--
Narayan Newton
OSU Open Source Lab
David Miller wrote:
> From: Narayan Newton <[EMAIL PROTECTED]>
mm,active_mm}->pgd = fc10c800
\|/ \|/
"@'/ ,. \`@"
/_| \__/ |_\
\__U_/
bzip2(3097): Oops [#1]
PSR: 40c4 PC: f00862a4 NPC: f00862a8 Y: Not tainted
PC:
%G: fb04dd08 00d8 1000 0001 fb04de14
From: Gustavo Zacarias <[EMAIL PROTECTED]>
Date: Mon, 19 Mar 2007 13:40:36 -0300
> Been running some intensive network loads on our T2000 for the last
> couple of hours and indeed this patch seems to fix it. Previously it
> would trigger an oops in less than 10 minutes.
> T
would trigger an oops in less than 10 minutes.
Thanks.
--
Gustavo Zacarias
Gentoo/SPARC monkey
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Narayan Newton <[EMAIL PROTECTED]>
Date: Mon, 12 Mar 2007 16:58:56 -0700
> I have been working on the same server/issue as Mike. We have found that
> our kernel without Netfilter support does not have this issue, but the
> moment you enable it in the kernel config this bug is triggered.
> At
From: Narayan Newton <[EMAIL PROTECTED]>
Date: Mon, 12 Mar 2007 16:58:56 -0700
> I have been working on the same server/issue as Mike. We have found that
> our kernel without Netfilter support does not have this issue, but the
> moment you enable it in the kernel config this bug is triggered.
> At
From: Narayan Newton <[EMAIL PROTECTED]>
Date: Mon, 12 Mar 2007 16:58:56 -0700
> I have been working on the same server/issue as Mike. We have found that
> our kernel without Netfilter support does not have this issue, but the
> moment you enable it in the kernel config this bug is triggered.
> At
Hi,
I have been working on the same server/issue as Mike. We have found that
our kernel without Netfilter support does not have this issue, but the
moment you enable it in the kernel config this bug is triggered.
Attached are the two kernel configs. The only difference is
CONFIG_NETFILTER=y
Kerne
From: "Michael Marineau" <[EMAIL PROTECTED]>
Date: Tue, 6 Mar 2007 11:48:50 -0800
> I twiddled with my kernel configuration a bit to remove the need for
> any modules to make building elsewhere and copying it over easier.
> With this new config I am no longer able to trigger the bug (ran the
> tes
On 3/5/07, David Miller <[EMAIL PROTECTED]> wrote:
From: "Michael Marineau" <[EMAIL PROTECTED]>
Date: Mon, 5 Mar 2007 22:41:31 -0800
> On 3/5/07, David Miller <[EMAIL PROTECTED]> wrote:
> > I'd be even more interested if you could reproduce it under
> > Debian or Ubuntu, any release :-)
>
> I'd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 5 Mar 2007, Corey Shields wrote:
On 3/5/07, Michael Marineau <[EMAIL PROTECTED]> wrote:
Built the kernel with gcc 4.1.1 and I got the oops in just a few
minutes, trying a second time now and it is lasting longer this time
around.
Once upon a time Tuesday 06 March 2007, David Miller wrote:
> I'm very suspicious of this bug because there are no reports of it
> on Debian or Ubuntu systems, and that's also the environment
> under which I've been beating the crap out of Niagara with 2.6.x
> kernels.
since i reported the proble
David Miller napsal(a):
From: "Michael Marineau" <[EMAIL PROTECTED]>
Date: Mon, 5 Mar 2007 22:41:31 -0800
On 3/5/07, David Miller <[EMAIL PROTECTED]> wrote:
I'd be even more interested if you could reproduce it under
Debian or Ubuntu, any release :-)
I'd rather not have to rebuild the box,
On 3/5/07, Michael Marineau <[EMAIL PROTECTED]> wrote:
Built the kernel with gcc 4.1.1 and I got the oops in just a few
minutes, trying a second time now and it is lasting longer this time
around.
Why not try and recreate this on bender (Gentoo's T2000)? Weeve?
-C
--
Corey Sh
From: "Michael Marineau" <[EMAIL PROTECTED]>
Date: Mon, 5 Mar 2007 22:41:31 -0800
> On 3/5/07, David Miller <[EMAIL PROTECTED]> wrote:
> > I'd be even more interested if you could reproduce it under
> > Debian or Ubuntu, any release :-)
>
> I'd rather not have to rebuild the box, but I suppose th
d. :-)
this is running Gentoo, but yes the
> compiler is 3.4.6. Newer versions haven't been marked stable in Gentoo
> on sparc yet for some reason. I'll give gcc 4.1.2 a try and see if I
> can still reproduce it.
Built the kernel with gcc 4.1.1 and I got the oops in just a f
From: "Michael Marineau" <[EMAIL PROTECTED]>
Date: Mon, 5 Mar 2007 21:22:22 -0800
> I'm not sure where you saw Fedora,
Sorry, that wasn't you, that was from Dennis Gilmore in
the original T1000 crash thread. :-)
this is running Gentoo, but yes the
> compiler is 3.4.6. Newer versions haven't been
>
> On a T2000 I am able to trigger the Oops in 5 to 50 minutes by pushing
> a ton of traffic over lo with netcat:
> nc -l -p 9000 >/dev/null
> nc localhost
I'm not sure where you saw Fedora, this is running Gentoo, but yes the
compiler is 3.4.6. Newer versions haven't b
From: "Michael Marineau" <[EMAIL PROTECTED]>
Date: Wed, 28 Feb 2007 23:13:20 -0800
> This bug was originally reported for a T1000 a while back:
> http://thread.gmane.org/gmane.linux.ports.sparc/6361/focus=6413
>
> On a T2000 I am able to trigger the Oops in 5 to 50 m
From: "Michael Marineau" <[EMAIL PROTECTED]>
Date: Wed, 28 Feb 2007 23:13:20 -0800
> This bug was originally reported for a T1000 a while back:
> http://thread.gmane.org/gmane.linux.ports.sparc/6361/focus=6413
>
> On a T2000 I am able to trigger the Oops in 5 to 50 m
This bug was originally reported for a T1000 a while back:
http://thread.gmane.org/gmane.linux.ports.sparc/6361/focus=6413
On a T2000 I am able to trigger the Oops in 5 to 50 minutes by pushing
a ton of traffic over lo with netcat:
nc -l -p 9000 >/dev/null
nc localhost nohdr, word[58080
Hi,
> Richard Mortimer (CC'd) reported an oops when booting 2.6.18 on
> Netra X1. Richard writes:
>
>> I believe that the problem is due to a null pointer being returned
>> from of_get_property in isa_dev_get_resource()
>> arch/sparc64/kernel/isa.c. Enclosed is a d
Hi,
Richard Mortimer (CC'd) reported an oops when booting 2.6.18 on
Netra X1. Richard writes:
> I believe that the problem is due to a null pointer being returned
> from of_get_property in isa_dev_get_resource()
> arch/sparc64/kernel/isa.c. Enclosed is a disassembly of the
>
Installing a bad disk in a Sun D1000 (JBOD 12 disk scsi 2 array)
attached to a Sun E4500 (8proc, 8Gb ram) running a 64bit sparc64
2.6.18.3 SMP kernel causes this or similar oops when accessing the bad
disk:
sda: Current: sense key: Recovered Error
Additional sense: Address mark not found for
On Wed, 23 Mar 2005 22:41:59 +0100
Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> I stopped when the build told me:
Someone looked into this and discussed it on linux-kernel not
2 weeks ago, it was an involved thread and the result was
"mark as non-modular on sparc and other platforms with similar
is
On Wed, Mar 23, 2005 at 10:17:48AM -0800, David S. Miller wrote:
> On Wed, 23 Mar 2005 15:53:26 +0200 (EET)
> Meelis Roos <[EMAIL PROTECTED]> wrote:
>
> > floppy module in 2.6.12-rc1 has an unresolved symbol floppy_hardint.
>
> Yes, this is known not to work. The floppy driver can only
> work no
On Wed, 23 Mar 2005 15:53:26 +0200 (EET)
Meelis Roos <[EMAIL PROTECTED]> wrote:
> floppy module in 2.6.12-rc1 has an unresolved symbol floppy_hardint.
Yes, this is known not to work. The floppy driver can only
work non-modular on sparc systems.
What you're getting is another one of those tty_wa
floppy module in 2.6.12-rc1 has an unresolved symbol floppy_hardint. I
forgot that and did "modprobe floppy" nonetheless on my Sparcstation 20.
The result is an oops and panic. This tty_wakeup oops seems similar to
the oops from "modprobe sg".
floppy: Unknown symbol flop
I'm not sure on what is causing it but looking at the Ooops it seems
like there is some form of memory/register corruption.
Feb 28 08:17:54 oekalux08 kernel: CPU[1]: local_irq_count[0]
irqs_running[0]
Feb 28 08:17:54 oekalux08 kernel: TSTATE: 11f09605 TPC:
0044fba8 TNPC: 00
Dear listmembers,
any ideas, comments on this? The only thing I actually did was running xosview
from *userland* and I can crash my system within a very short time.
[EMAIL PROTECTED] MHz, SMP, Kernel 2.4.29-SMP.
Thanks for any efforts in advance,
take care
Dieter Jurzitza
--
___
59 matches
Mail list logo
