Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

Bug Report

 

 

Linux kernel RSS feed   Index | Next | Previous | View Threaded


briang at microlite

Jan 8, 1999, 11:48 AM

Post #1 of 17 (521 views)
Permalink
Bug Report

While using linux/genhd.h I received several compiler errors. I wasn't
sure who to mail, I figured Linus probably wouldn't want this clutter in
his mail box, but maybe I'm wrong - who cares. Here's the problem. (kernel
2.2.0pre5)
After the struct partition (ending on line ~56) there is an
} __attribute__((packed));
My gcc definitely doesn't like this. (gcc 2.7.2.1, I think 2.8.1 hates it
also):
/usr/include/linux/genhd.h:56: semicolon missing after declaration of
`partition'
Then it gives me a ton of errors regarding the lack of linux/types.h. I
don't know if these are my problems or if linux/types.h is a prerequisite
for genhd.h. I just figured I'd lay it out there and hopefully someone
much more informed than myself can add these lines, or hopefully correct my
error.
thanx
Brian Geisel
Please CC to me, thanx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
Please read the FAQ at http://www.tux.org/lkml/


katz at advanced

Feb 23, 1999, 3:08 PM

Post #2 of 17 (490 views)
Permalink
RE: bug report [In reply to]

Turn off socket filtering under Networking Options in the kernel config ..
this bug has been there since the later 2.2.2pre's
Terry
> Hello,
> A friend told me to send this cuase he thinks its a bug it happened when
> i ran bzImage
>
> make all_targets
> make[3]: Entering directory `/usr/src/linux-2.2.2/drivers/net'
> gcc -D__KERNEL__ -I/usr/src/linux-2.2.2/include -Wall
> -Wstrict-prototypes -O2 -f
> omit-frame-pointer -pipe -fno-strength-reduce -m486 -malign-loops=2
> -malign-jump
> s=2 -malign-functions=2 -DCPU=586 -c -o loopback.o loopback.c
> /usr/src/linux-2.2.2/include/net/sock.h: In function `sk_filter':
> In file included from loopback.c:51:
> /usr/src/linux-2.2.2/include/net/sock.h:796: dereferencing pointer to
> incomplete
> type
> /usr/src/linux-2.2.2/include/net/sock.h:796: dereferencing pointer to
> incomplete
> type
> /usr/src/linux-2.2.2/include/net/sock.h:796: warning: passing arg 1 of
> `sk_run_f
> ilter' from incompatible pointer type
> /usr/src/linux-2.2.2/include/net/sock.h:796: too few arguments to
> function `sk_r
> un_filter'
> /usr/src/linux-2.2.2/include/net/sock.h: In function
> `sk_filter_release':
> /usr/src/linux-2.2.2/include/net/sock.h:807: warning: implicit
> declaration of fu
> nction `sk_filter_len'
> /usr/src/linux-2.2.2/include/net/sock.h:811: dereferencing pointer to
> incomplete
> type
> /usr/src/linux-2.2.2/include/net/sock.h: In function `sk_filter_charge':
>
> /usr/src/linux-2.2.2/include/net/sock.h:817: dereferencing pointer to
> incomplete
> type
> make[3]: *** [loopback.o] Error 1
> make[3]: Leaving directory `/usr/src/linux-2.2.2/drivers/net'
> make[2]: *** [first_rule] Error 2
> make[2]: Leaving directory `/usr/src/linux-2.2.2/drivers/net'
> make[1]: *** [_subdir_net] Error 2
> make[1]: Leaving directory `/usr/src/linux-2.2.2/drivers'
> make: *** [_dir_drivers] Error 2
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo [at] vger
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
Please read the FAQ at http://www.tux.org/lkml/


zinx at linuxfreak

Jul 9, 1999, 11:49 PM

Post #3 of 17 (494 views)
Permalink
Re: bug report [In reply to]

Are you by any change using the Matrox frame buffer acceleration?
I believe this bug was fixed, though I'm not certain..
What version of the kernel are you using?
--
Zinx Verituse (finger @bliss.penguinpowered.com for pgp/gpg keys)
pgp9FE5C9747EB8FF329BB13199C4008E67 gpgB907847462E334322EBC2197A2454F1993140EFD
0"2-1=0>0:1(2<192:0?0;0A0@2=0<0=1.0A2=0<2A0-">:#v_52*,@
55*-3*\68*-+, v >
destructive mind wrote:
> The way I found/recreated this (bug?) is while trying to paste using gpm.
> It only happens if I have scrolled up using shift+pageup. After scrolling
> up if I start to select text with the mouse, it will kill gpm and output an
> oops message. I ran this output through ksymoops and the output that it had
> is listed below. I believe that this has to do with fbcon and buffering,
> but that is just a weak guess. I have vesafb compiled into my kernel and I
> use vga 773 mode for my console. If any other information about my system or
> the way i created this, feel free to contact me. I would also like to thank
> everyone for making linux as stable as possible.
>
[oops snipped]
>
> thanks,
>
> Brad Bailey
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
Please read the FAQ at http://www.tux.org/lkml/


dstrctive at hotmail

Jul 14, 1999, 9:45 PM

Post #4 of 17 (497 views)
Permalink
Re: bug report [In reply to]

I am running kernel 2.2.10 and I am not using the Matrox frame buffer accel.
I am just using vesafb. I also have the vga mode set to 773.
-Brad
>From: "Forever shall I be." <zinx [at] linuxfreak>
>Are you by any change using the Matrox frame buffer acceleration?
>
>I believe this bug was fixed, though I'm not certain..
>What version of the kernel are you using?
>
>--
>Zinx Verituse (finger @bliss.penguinpowered.com for pgp/gpg keys)
>destructive mind wrote:
> > The way I found/recreated this (bug?) is while trying to paste using
>gpm.
> > It only happens if I have scrolled up using shift+pageup. After
>scrolling
> > up if I start to select text with the mouse, it will kill gpm and output
>an
> > oops message. I ran this output through ksymoops and the output that it
>had
> > is listed below. I believe that this has to do with fbcon and
>buffering,
> > but that is just a weak guess. I have vesafb compiled into my kernel
>and I
> > use vga 773 mode for my console. If any other information about my
>system or
> > the way i created this, feel free to contact me. I would also like to
>thank
> > everyone for making linux as stable as possible.
> >
>
>[oops snipped]
_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
Please read the FAQ at http://www.tux.org/lkml/


hedrick at Astro

Jul 31, 1999, 10:27 PM

Post #5 of 17 (496 views)
Permalink
Re: Bug Report [In reply to]

On Sun, 1 Aug 1999, jocke @master.domain wrote:
> 1.When i upgrading to kernel 2.3.10, 2.3.11, 2.3.12 from 2.3.6 i can't use
> udma. I get a error msg about the fat or vfat....
Did you check the differences in the configurations?
If you did not compile in DMA............
> 2. When i upgrading to kernel 2.3.10, 2.3.11, 2.3.12 from 2.3.6 i can't use udma
> . I use the
> command "hdparm -d1 /dev/hda" and i get this messages:
> /dev/hda:
> setting using_dma to 1 (on)
> HDIO_SET_DMA failed: Operation not permitted
> using_dma = 0 (off)
>
> in kernel 2.3.6 i can use udma,
> /dev/hda:
> setting using_dma to 1 (on)
> using_dma = 1 (on)
>
> what a hell can't I not use this in kernel 2.3.10, 2.3.11, 2.3.12 ?
>
> I know this (2.3.x) is a devel kernel and kernels >2.3.9 use a new vfs, i
> think this beta vfs testing now (and this is a reason I talking about this
> problem) but...they should work. Another
> problem whith this kernel is I can't use the fat or vfat, i get a error
> message when i compile the kernel. Like this:
>
> fs/filesystems.a(fat.o): In function ^Fat_file_write':
> fat.o(.text+0x2bac): undefined reference to ^Update_vm_cache'
> make: *** [vmlinux] Error 1
>
> 3. Kernel, Drivers and Filesystems
>
> 4. Linux version 2.3.9, 2.3.10, 2.3.11, 2.3.12 (root [at] Maste) (gcc version 2.7.2.
> 3)
>
> 5.
>
> 6. A) like hdparm -d1 /dev/hda B) make dep, make clean, make bzImage (or make
> zImage) for the error i get when i try to compile the kernel and use the fat
> or vfat
>
> 7.1 Linux 2.3.9, 2.3.10, 2.3.11, 2.3.12 i586 unknown
> Kernel modules 2.1.121
> Gnu C 2.7.2.3
> Binutils 2.9.1.0.19
> Linux C Library 5.4.46
> Dynamic linker ldd: version 1.9.9
> Linux C++ Library 2.9.0
> Procps 2.0.2
> Mount 2.9i
> Net-tools 1.52
> Kbd 0.94
> Sh-utils 1.16
> Modules Loaded
>
> 7.2 processor : 0
> vendor_id : AuthenticAMD
> cpu family : 5
> model : 7
> model name : AMD-K6tm w/ multimedia extensions
> stepping : 0
> cpu MHz : 300.689771
> fdiv_bug : no
> hlt_bug : no
> sep_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 1
> wp : yes
> flags : fpu vme de pse tsc msr mce cx8 10 mmx
> bogomips : 599.65
>
> 7.3 note: it's empty
>
> 7.4 note: it's emtpy
>
> /jocke jocke_ [at] linuxmail
>
>
> __________________________
> Get Your Private, Free Email at http://www.linuxmail.org
>
> Powered by OutBlaze
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo [at] vger
> Please read the FAQ at http://www.tux.org/lkml/
>
Andre Hedrick
The Linux IDE guy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
Please read the FAQ at http://www.tux.org/lkml/


axboe at suse

Feb 2, 2001, 6:44 PM

Post #6 of 17 (497 views)
Permalink
Re: Bug report [In reply to]

On Thu, Feb 01 2001, Anders S. Buch wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> It seems that the ide/cdrom/amd756 code can cause some bad lockups, at
> least on my system. I have an Athlon 500 system running the 2.4.1 kernel
> with Redhat 6.1 + updated modutils, etc.
Have you tried disabling DMA on the atapi drive, not all do atapi
dma in an orderly fashion (yet)?
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
Please read the FAQ at http://www.tux.org/lkml/


tewalberg at mediaone

Mar 22, 2001, 2:43 PM

Post #7 of 17 (500 views)
Permalink
Re: Bug report [In reply to]

"User does not understand how *NIX systems utilize memory" is
not the same thing as "bug". What you are seeing is the kernel
using memory for file system cache.
On 03/22/2001 12:58 -0800, Craig Cummings wrote:
>> Hi there,
>>
>> I think this qualifies as a bug but let me know if this could be a
>> configuration or hardware issue.
>>
>> I've been having problems with memory leaks when I run programs on
>> large--up to 250MB text files. (I know this is huge, but that's the 3
>> billion base human genome for you.) At first I though it was a Perl
>> problem but I later found that a completely unrelated C program also
>> caused memory leaks. I recently upgraded to the 2.4 kernel, hoping to
>> solve these problems (see below). However, the memory leaks are still
>> happening and this time I know the problem is at a deeper level than my
>> programs. Some standard UNIX programs are leaking a lot of memory. I
>> would appreciate some advice and ultimately, a fix. Unfortunately, My
>> programming skills are not sufficient for tinkering with the kernel
>> source. Thank you, in advance for your help. Details follow.
>>
>> Regards,
>>
>> Craig Cummings
>>
>>
>> Here are the specs for my system:
>> Dell Precision XPSt700, Pentium III, 512 MB RAM
>> I've recently upgraded from Red Hat 6.2 with the 2.2.14 kernel to
>> Red Hat 7, then built the 2.4.2 kernel on my own.
>>
>> Here's what happens with grep:
>>
>> Output of free, freshly booted system:
>>
>> total used free shared buffers cached
>> Mem: 513616 47516 466100 0 2476 27048
>> -/+ buffers/cache: 17992 495624
>> Swap: 128480 0 128480
>>
>> Output of free after grep 'NT_005289' Data/hs_chr12.fa:
>>
>> total used free shared buffers cached
>> Mem: 513616 183548 330068 0 2624 159616
>> -/+ buffers/cache: 21308 492308
>> Swap: 128480 0 128480
>>
>> Output of grep 'NT_005289' Data/hs_chr2.fa:
>>
>> >gi|12728771|ref|NT_005289.2|Hs2_5446 Homo sapiens chromosome 2 working draft sequence segment
>>
>> Output of free after this grep:
>>
>> total used free shared buffers cached
>> Mem: 513616 424272 89344 0 2860 394232
>> -/+ buffers/cache: 27180 486436
>> Swap: 128480 0 128480
>>
>> Output of grep 'NT_005289' Data/hs_chr2.fa:
>>
>> >gi|12728771|ref|NT_005289.2|Hs2_5446 Homo sapiens chromosome 2 working draft sequence segment
>>
>> Output of free after this grep:
>>
>> total used free shared buffers cached
>> Mem: 513616 424272 89344 0 2860 394232
>> -/+ buffers/cache: 27180 486436
>> Swap: 128480 0 128480
>>
>> File sizes of the two files grep'ed:
>>
>> -rw-rw-r-- 1 cummings genomics 135744469 Mar 12 22:09 Data/hs_chr12.fa
>> -rw-rw-r-- 1 cummings genomics 240244039 Mar 12 22:24 Data/hs_chr2.fa
>>
>> Note that these file sizes are equivalent to the amount of memory leaked
>> when grep is called on that file.
>>
>> When I grep the same file a second time, very little additional memory is
>> leaked.
>>
>>
>> This same phenomenon occurs when I run a different UNIX program, e.g. wc:
>>
>> Output of wc -l Data/hs_chr3.fa:
>>
>> 2915465 Data/hs_chr3.fa
>>
>> Output of free:
>>
>> total used free shared buffers cached
>> Mem: 513616 511520 2096 0 1252 481020
>> -/+ buffers/cache: 29248 484368
>> Swap: 128480 0 128480
>>
>> Interestingly, after running wc a second time on the same file, it goes
>> very fast and very little additional memory is leaked:
>>
>> total used free shared buffers cached
>> Mem: 513616 510732 2884 0 1204 480948
>> -/+ buffers/cache: 28580 485036
>> Swap: 128480 40 128440
>>
>>
>> -------------------------------------------
>> Craig Cummings, Ph.D.
>>
>> Relman Laboratory
>> Stanford University School of Medicine
>> Department of Microbiology and Immunology
>>
>> e-mail: cummings [at] cmgm
>> phone: 650-498-5998
>> fax: 650-852-3291
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo [at] vger
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
End of included message
--
+--------------------------+------------------------------+
| Tim Walberg | tewalberg [at] mediaone |
| 828 Marshall Ct. | www.concentric.net/~twalberg |
| Palatine, IL 60074 | |
+--------------------------+------------------------------+
<HR NOSHADE>
<UL>
<LI>application/pgp-signature attachment: stored
</UL>
<!-- attachment="01-part" -->
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


alan at lxorguk

Nov 10, 2001, 12:08 PM

Post #8 of 17 (502 views)
Permalink
Re: Bug Report [In reply to]

> 3. kernel, video, frame buffer, X, VESA, crash, lock
> 4. Linux 2.4.13-ac8
2.4.13-ac8 isnt stable. See the release notes.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


mrechberger at gmail

Jul 12, 2006, 3:56 AM

Post #9 of 17 (495 views)
Permalink
Re: BUG report [In reply to]

Hi,

this very likely has nothing to do with the TV tuner.
There's an issue if you access an usbaudio device and unplug it the
system might lock up the keyboard.
Also mozilla caused that issue on your side, so I only know that dumb
written mozilla plugins directly access /dev/dsp* /dev/mixer* devices
and don't release them (especially the mixer one)
This causes problems in the alsa framework...
I think the pinnacle 50e supports digital audio -> a part of that
device acts as a usb audio device.
You could also blame the firefox guys to document their plugin
interface once in this century rather than adding more new bugged
code... (I made some experience with that part a while ago)

Markus

On 7/9/06, Antonio Mignolli <antoniomignolli [at] gmail> wrote:
> I'm on a Slackware with kernel 2.6.17.3 obtained by applying patch-2.6.17.3
> to kernel 2.6.17.
> I plugged a Pinnacle pctv 50e USB tv card.
> It works correctly, I was trying it.
> After a while, I disconnected it and after very few seconds
> I plugged an external USB hard drive.
> For a couple of minutes, USB hub seemed to be not working.
> No messages on dmesg indicating a new device (usually /dev/sda,
> I have all the modules for that.)
> After about two minutes, the USB hub woke up (/dev/sda created, USB
> mouse working)
> and on syslog and on every terminal on my
> desktop appeared some messages.
>
> TERMINAL MESSAGES:
>
> Message from syslogd [at] slack at Wed Jul 5 23:38:39 2006 ...
> slacky kernel: Oops: 0002 [#1]
>
> Message from syslogd [at] slack at Wed Jul 5 23:38:39 2006 ...
> slacky kernel: PREEMPT
>
> Message from syslogd [at] slack at Wed Jul 5 23:38:39 2006 ...
> slacky kernel: CPU: 0
>
> Message from syslogd [at] slack at Wed Jul 5 23:38:39 2006 ...
> slacky kernel: EIP is at __fput+0xab/0x140
>
> Message from syslogd [at] slack at Wed Jul 5 23:38:39 2006 ...
> slacky kernel: eax: 00000007 ebx: d613c000 ecx: d61cc030 edx: c01ebbf7
>
> Message from syslogd [at] slack at Wed Jul 5 23:38:39 2006 ...
> slacky kernel: esi: d3ba2780 edi: d9548184 ebp: d94ede14 esp: d613df6c
>
> Message from syslogd [at] slack at Wed Jul 5 23:38:39 2006 ...
> slacky kernel: ds: 007b es: 007b ss: 0068
>
> Message from syslogd [at] slack at Wed Jul 5 23:38:39 2006 ...
> slacky kernel: Process firefox-bin (pid: 5500, threadinfo=d613c000
> task=d61cc030)
>
> Message from syslogd [at] slack at Wed Jul 5 23:38:39 2006 ...
> slacky kernel: Stack: df7c4f40 d3ba2780 df68c5c0 00000000 d613c000
> c0147fda d3ba2780 df68c5c0
>
> Message from syslogd [at] slack at Wed Jul 5 23:38:39 2006 ...
> slacky kernel: d3ba2780 df68c5c0 d613c000 df68c5c0 d3ba2780
> c014803c d3ba2780 df68c5c0
>
> Message from syslogd [at] slack at Wed Jul 5 23:38:39 2006 ...
> slacky kernel: 00000030 00000002 09557fb0 c01025d7 00000030
> 00000000 b68c7600 00000002
>
> Message from syslogd [at] slack at Wed Jul 5 23:38:39 2006 ...
> slacky kernel: Call Trace:
>
> Message from syslogd [at] slack at Wed Jul 5 23:38:39 2006 ...
> slacky kernel: <c0147fda> filp_close+0x4c/0x55 <c014803c> sys_close+0x59/0x7c
>
> Message from syslogd [at] slack at Wed Jul 5 23:38:39 2006 ...
> slacky kernel: <c01025d7> syscall_call+0x7/0xb
>
> Message from syslogd [at] slack at Wed Jul 5 23:38:39 2006 ...
> slacky kernel: Code: 38 58 5a 8b 87 f4 00 00 00 85 c0 74 07 50 e8 6a
> 6e 00 00 58 8b 46 10 85 c0
> 74 35 8b 00 85 c0 74 2f bb 00 e0 ff ff 21 e3 ff 43 14 <ff> 88 00 01
> 00 00 83 38 02 75 0b 8b 80
> 88 01 00 00 e8 08 67 fc
>
> Message from syslogd [at] slack at Wed Jul 5 23:38:39 2006 ...
> slacky kernel: EIP: [<c01493c9>] __fput+0xab/0x140 SS:ESP 0068:d613df6c
>
>
> SYSLOG MESSAGES:
>
> Jul 5 23:38:39 slacky kernel: BUG: unable to handle kernel NULL
> pointer dereference at virtual
> address 00000107
> Jul 5 23:38:39 slacky kernel: printing eip:
> Jul 5 23:38:39 slacky kernel: c01493c9
> Jul 5 23:38:39 slacky kernel: *pde = 00000000
> Jul 5 23:38:39 slacky kernel: Oops: 0002 [#1]
> Jul 5 23:38:39 slacky kernel: PREEMPT
> Jul 5 23:38:39 slacky kernel: Modules linked in: vfat fat snd_pcm_oss
> snd_mixer_oss snd_usb_au
> dio snd_usb_lib snd_rawmidi snd_seq_device snd_hwdep tda9887 tuner
> saa7115 em28xx compat_ioctl3
> 2 v4l1_compat v4l2_common ir_common videodev tveeprom i2c_core eth1394
> snd_intel8x0 snd_intel8x
> 0m snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd snd_page_alloc
> yenta_socket rsrc_nonstatic
> pcmcia_core ohci1394 b44 joydev fuse evdev
> Jul 5 23:38:39 slacky kernel: CPU: 0
> Jul 5 23:38:39 slacky kernel: EIP: 0060:[<c01493c9>] Not tainted VLI
> Jul 5 23:38:39 slacky kernel: EFLAGS: 00010202 (2.6.17.3 #7)
> Jul 5 23:38:39 slacky kernel: EIP is at __fput+0xab/0x140
> Jul 5 23:38:39 slacky kernel: eax: 00000007 ebx: d613c000 ecx:
> d61cc030 edx: c01ebbf7
> Jul 5 23:38:39 slacky kernel: esi: d3ba2780 edi: d9548184 ebp:
> d94ede14 esp: d613df6c
> Jul 5 23:38:39 slacky kernel: ds: 007b es: 007b ss: 0068
> Jul 5 23:38:39 slacky kernel: Process firefox-bin (pid: 5500,
> threadinfo=d613c000 task=d61cc03
> 0)
> Jul 5 23:38:39 slacky kernel: Stack: df7c4f40 d3ba2780 df68c5c0
> 00000000 d613c000 c0147fda d3b
> a2780 df68c5c0
> Jul 5 23:38:39 slacky kernel: d3ba2780 df68c5c0 d613c000
> df68c5c0 d3ba2780 c014803c d3b
> a2780 df68c5c0
> Jul 5 23:38:39 slacky kernel: 00000030 00000002 09557fb0
> c01025d7 00000030 00000000 b68
> c7600 00000002
> Jul 5 23:38:39 slacky kernel: Call Trace:
> Jul 5 23:38:39 slacky kernel: <c0147fda> filp_close+0x4c/0x55
> <c014803c> sys_close+0x59/0x7c
> Jul 5 23:38:39 slacky kernel: <c01025d7> syscall_call+0x7/0xb
> Jul 5 23:38:39 slacky kernel: Code: 38 58 5a 8b 87 f4 00 00 00 85 c0
> 74 07 50 e8 6a 6e 00 00 5
> 8 8b 46 10 85 c0 74 35 8b 00 85 c0 74 2f bb 00 e0 ff ff 21 e3 ff 43 14
> <ff> 88 00 01 00 00 83 3
> 8 02 75 0b 8b 80 88 01 00 00 e8 08 67 fc
> Jul 5 23:38:39 slacky kernel: EIP: [<c01493c9>] __fput+0xab/0x140
> SS:ESP 0068:d613df6c
> Jul 5 23:38:39 slacky kernel: <6>note: firefox-bin[5500] exited with
> preempt_count 1
> Jul 5 23:38:39 slacky kernel: hub 1-0:1.0: over-current change on port 2
> Jul 5 23:38:39 slacky kernel: hub 2-0:1.0: over-current change on port 1
> Jul 5 23:38:39 slacky kernel: hub 2-0:1.0: over-current change on port 2
> Jul 5 23:38:40 slacky kernel: hub 1-0:1.0: over-current change on port 1
> Jul 5 23:40:37 slacky kernel: hub 1-0:1.0: over-current change on port 1
> Jul 5 23:40:37 slacky kernel: hub 2-0:1.0: over-current change on port 1
> Jul 5 23:40:44 slacky kernel: sda: assuming drive cache: write through
> Jul 5 23:40:44 slacky kernel: sda: assuming drive cache: write through
>
>
>
> Hope it helps.
> Bye.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo [at] vger
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>


--
Markus Rechberger
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


oliver.pntr at gmail

Jun 6, 2008, 6:45 PM

Post #10 of 17 (437 views)
Permalink
Re: bug report [In reply to]

Sorry, s/Ingon/Ingo/

On 6/7/08, Oliver Pinter <oliver.pntr [at] gmail> wrote:
> Add Ingon and netdev to CC
>
>
> On 6/6/08, Zsiros Attila <zsirmo [at] gmail> wrote:
>> Hy!
>>
>> I have a problem.
>>
>> http://www.cyberszeg.hu/log/kern.log
>> http://www.cyberszeg.hu/log/config-2.6.25.4
>> http://www.cyberszeg.hu/log/lspci.txt
>> http://www.cyberszeg.hu/log/ifconfig.txt
>>
>> Best regards Zsirmo
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo [at] vger
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
>
> --
> Thanks,
> Oliver
>


--
Thanks,
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


akpm at linux-foundation

Jun 6, 2008, 10:56 PM

Post #11 of 17 (434 views)
Permalink
Re: bug report [In reply to]

On Sat, 7 Jun 2008 03:44:32 +0200 "Oliver Pinter" <oliver.pntr [at] gmail> wrote:

> Add Ingon and netdev to CC
>
>
> On 6/6/08, Zsiros Attila <zsirmo [at] gmail> wrote:
> > Hy!
> >
> > I have a problem.
> >
> > http://www.cyberszeg.hu/log/kern.log
> > http://www.cyberszeg.hu/log/config-2.6.25.4
> > http://www.cyberszeg.hu/log/lspci.txt
> > http://www.cyberszeg.hu/log/ifconfig.txt
> >

: Jun 6 14:03:07 www kernel: [ 5897.660390] NETDEV WATCHDOG: eth0: transmit timed out
: Jun 6 14:03:07 www kernel: [ 5897.660398] tg3: eth0: transmit timed out, resetting
: Jun 6 14:03:07 www kernel: [ 5897.660432] tg3: DEBUG: MAC_TX_STATUS[0000001e] MAC_RX_STATUS[0000000e]
: Jun 6 14:03:07 www kernel: [ 5897.660454] tg3: DEBUG: RDMAC_STATUS[00000000] WDMAC_STATUS[00000000]
: Jun 6 14:03:07 www kernel: [ 5897.762983] tg3: tg3_stop_block timed out, ofs=1800 enable_bit=2
: Jun 6 14:03:07 www kernel: [ 5897.864168] tg3: tg3_stop_block timed out, ofs=c00 enable_bit=2
: Jun 6 14:03:07 www kernel: [ 5897.965619] tg3: tg3_stop_block timed out, ofs=4800 enable_bit=2

That looks like a driver failure.

: Jun 6 14:03:07 www kernel: [ 5898.096689] tg3: eth0: Link is down.
: Jun 6 14:03:11 www kernel: [ 5901.633931] tg3: eth0: Link is up at 1000 Mbps, full duplex.
: Jun 6 14:03:11 www kernel: [ 5901.633937] tg3: eth0: Flow control is on for TX and on for RX.
: Jun 6 14:04:11 www kernel: [ 6464.556309] clamscan: page allocation failure. order:3, mode:0x4020
: Jun 6 14:04:11 www kernel: [ 6464.556319] Pid: 24139, comm: clamscan Not tainted 2.6.25.4 #1
: Jun 6 14:04:11 www kernel: [ 6464.556325]
: Jun 6 14:04:11 www kernel: [ 6464.556326] Call Trace:
: Jun 6 14:04:11 www kernel: [ 6464.556329] <IRQ> [__alloc_pages+544/890] __alloc_pages+0x220/0x37a
: Jun 6 14:04:11 www kernel: [ 6464.556353] [tcp_v4_do_rcv+186/504] tcp_v4_do_rcv+0xba/0x1f8
: Jun 6 14:04:11 www kernel: [ 6464.556359] [ktime_get+12/98] ktime_get+0xc/0x62
: Jun 6 14:04:11 www kernel: [ 6464.556364] [__netdev_alloc_skb+23/49] __netdev_alloc_skb+0x17/0x31
: Jun 6 14:04:11 www kernel: [ 6464.556370] [__slab_alloc+330/1403] __slab_alloc+0x14a/0x57b
: Jun 6 14:04:11 www kernel: [ 6464.556374] [__netdev_alloc_skb+23/49] __netdev_alloc_skb+0x17/0x31
: Jun 6 14:04:11 www kernel: [ 6464.556379] [__netdev_alloc_skb+23/49] __netdev_alloc_skb+0x17/0x31
: Jun 6 14:04:11 www kernel: [ 6464.556384] [__kmalloc_track_caller+185/190] __kmalloc_track_caller+0xb9/0xbe
: Jun 6 14:04:11 www kernel: [ 6464.556391] [__alloc_skb+86/305] __alloc_skb+0x56/0x131
: Jun 6 14:04:11 www kernel: [ 6464.556395] [__netdev_alloc_skb+23/49] __netdev_alloc_skb+0x17/0x31
: Jun 6 14:04:11 www kernel: [ 6464.556408] [_end+128472975/2130444940] :tg3:tg3_alloc_rx_skb+0x8f/0x17e
: Jun 6 14:04:11 www kernel: [ 6464.556418] [_end+128493403/2130444940] :tg3:tg3_poll+0x6e8/0x922
: Jun 6 14:04:11 www kernel: [ 6464.556426] [net_rx_action+134/309] net_rx_action+0x86/0x135
: Jun 6 14:04:11 www kernel: [ 6464.556433] [__do_softirq+102/212] __do_softirq+0x66/0xd4
: Jun 6 14:04:11 www kernel: [ 6464.556439] [call_softirq+28/48] call_softirq+0x1c/0x30
: Jun 6 14:04:11 www kernel: [ 6464.556444] [do_softirq+48/107] do_softirq+0x30/0x6b
: Jun 6 14:04:11 www kernel: [ 6464.556448] [do_IRQ+114/212] do_IRQ+0x72/0xd4
: Jun 6 14:04:11 www kernel: [ 6464.556453] [ret_from_intr+0/10] ret_from_intr+0x0/0xa

The driver is trying to do a 32 kbyte GFP_ATOMIC memory allocation.
rofl, good luck with that.

But the netwoking code sould survive this.

<12 billion more page allocation failures>

Are you using jumbo frames or have you manually set the MTU to
something enormous? Because 32k is a pretty crazy amount of memory for
the driver to be trying to allocate - it's going to fail all over the
place, as you have discovered.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


ilpo.jarvinen at helsinki

Jun 7, 2008, 1:47 AM

Post #12 of 17 (428 views)
Permalink
Re: bug report [In reply to]

...Added Brian Vowell.

On Fri, 6 Jun 2008, Andrew Morton wrote:

> On Sat, 7 Jun 2008 03:44:32 +0200 "Oliver Pinter" <oliver.pntr [at] gmail> wrote:
>
> > Add Ingon and netdev to CC
> >
> >
> > On 6/6/08, Zsiros Attila <zsirmo [at] gmail> wrote:
> > > Hy!
> > >
> > > I have a problem.
> > >
> > > http://www.cyberszeg.hu/log/kern.log
> > > http://www.cyberszeg.hu/log/config-2.6.25.4
> > > http://www.cyberszeg.hu/log/lspci.txt
> > > http://www.cyberszeg.hu/log/ifconfig.txt
> > >
>
> : Jun 6 14:03:07 www kernel: [ 5897.660390] NETDEV WATCHDOG: eth0: transmit timed out
> : Jun 6 14:03:07 www kernel: [ 5897.660398] tg3: eth0: transmit timed out, resetting
> : Jun 6 14:03:07 www kernel: [ 5897.660432] tg3: DEBUG: MAC_TX_STATUS[0000001e] MAC_RX_STATUS[0000000e]
> : Jun 6 14:03:07 www kernel: [ 5897.660454] tg3: DEBUG: RDMAC_STATUS[00000000] WDMAC_STATUS[00000000]
> : Jun 6 14:03:07 www kernel: [ 5897.762983] tg3: tg3_stop_block timed out, ofs=1800 enable_bit=2
> : Jun 6 14:03:07 www kernel: [ 5897.864168] tg3: tg3_stop_block timed out, ofs=c00 enable_bit=2
> : Jun 6 14:03:07 www kernel: [ 5897.965619] tg3: tg3_stop_block timed out, ofs=4800 enable_bit=2
>
> That looks like a driver failure.
>
> : Jun 6 14:03:07 www kernel: [ 5898.096689] tg3: eth0: Link is down.
> : Jun 6 14:03:11 www kernel: [ 5901.633931] tg3: eth0: Link is up at 1000 Mbps, full duplex.
> : Jun 6 14:03:11 www kernel: [ 5901.633937] tg3: eth0: Flow control is on for TX and on for RX.
> : Jun 6 14:04:11 www kernel: [ 6464.556309] clamscan: page allocation failure. order:3, mode:0x4020
> : Jun 6 14:04:11 www kernel: [ 6464.556319] Pid: 24139, comm: clamscan Not tainted 2.6.25.4 #1
> : Jun 6 14:04:11 www kernel: [ 6464.556325]
> : Jun 6 14:04:11 www kernel: [ 6464.556326] Call Trace:
> : Jun 6 14:04:11 www kernel: [ 6464.556329] <IRQ> [__alloc_pages+544/890] __alloc_pages+0x220/0x37a
> : Jun 6 14:04:11 www kernel: [ 6464.556353] [tcp_v4_do_rcv+186/504] tcp_v4_do_rcv+0xba/0x1f8
> : Jun 6 14:04:11 www kernel: [ 6464.556359] [ktime_get+12/98] ktime_get+0xc/0x62
> : Jun 6 14:04:11 www kernel: [ 6464.556364] [__netdev_alloc_skb+23/49] __netdev_alloc_skb+0x17/0x31
> : Jun 6 14:04:11 www kernel: [ 6464.556370] [__slab_alloc+330/1403] __slab_alloc+0x14a/0x57b
> : Jun 6 14:04:11 www kernel: [ 6464.556374] [__netdev_alloc_skb+23/49] __netdev_alloc_skb+0x17/0x31
> : Jun 6 14:04:11 www kernel: [ 6464.556379] [__netdev_alloc_skb+23/49] __netdev_alloc_skb+0x17/0x31
> : Jun 6 14:04:11 www kernel: [ 6464.556384] [__kmalloc_track_caller+185/190] __kmalloc_track_caller+0xb9/0xbe
> : Jun 6 14:04:11 www kernel: [ 6464.556391] [__alloc_skb+86/305] __alloc_skb+0x56/0x131
> : Jun 6 14:04:11 www kernel: [ 6464.556395] [__netdev_alloc_skb+23/49] __netdev_alloc_skb+0x17/0x31
> : Jun 6 14:04:11 www kernel: [ 6464.556408] [_end+128472975/2130444940] :tg3:tg3_alloc_rx_skb+0x8f/0x17e
> : Jun 6 14:04:11 www kernel: [ 6464.556418] [_end+128493403/2130444940] :tg3:tg3_poll+0x6e8/0x922
> : Jun 6 14:04:11 www kernel: [ 6464.556426] [net_rx_action+134/309] net_rx_action+0x86/0x135
> : Jun 6 14:04:11 www kernel: [ 6464.556433] [__do_softirq+102/212] __do_softirq+0x66/0xd4
> : Jun 6 14:04:11 www kernel: [ 6464.556439] [call_softirq+28/48] call_softirq+0x1c/0x30
> : Jun 6 14:04:11 www kernel: [ 6464.556444] [do_softirq+48/107] do_softirq+0x30/0x6b
> : Jun 6 14:04:11 www kernel: [ 6464.556448] [do_IRQ+114/212] do_IRQ+0x72/0xd4
> : Jun 6 14:04:11 www kernel: [ 6464.556453] [ret_from_intr+0/10] ret_from_intr+0x0/0xa
>
> The driver is trying to do a 32 kbyte GFP_ATOMIC memory allocation.
> rofl, good luck with that.
>
> But the netwoking code sould survive this.
>
> <12 billion more page allocation failures>
>
> Are you using jumbo frames or have you manually set the MTU to
> something enormous? Because 32k is a pretty crazy amount of memory for
> the driver to be trying to allocate - it's going to fail all over the
> place, as you have discovered.

Same allocation failed problem (among an TCP issue that is nowadays
fixed) was also reported by Brian Vowell:
http://bugzilla.kernel.org/show_bug.cgi?id=10767


--
i.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


oliver.pntr at gmail

Jun 7, 2008, 5:50 AM

Post #13 of 17 (419 views)
Permalink
Re: bug report [In reply to]

[snip]
Jun 6 14:04:11 www kernel: [ 6464.556309] clamscan: page allocation
failure. order:3, mode:0x4020 <------------- this
Jun 6 14:04:11 www kernel: [ 6464.556319] Pid: 24139, comm: clamscan
Not tainted 2.6.25.4 #1
Jun 6 14:04:11 www kernel: [ 6464.556325]
Jun 6 14:04:11 www kernel: [ 6464.556326] Call Trace:
Jun 6 14:04:11 www kernel: [ 6464.556329] <IRQ>
[__alloc_pages+544/890] __alloc_pages+0x220/0x37a
Jun 6 14:04:11 www kernel: [ 6464.556353] [tcp_v4_do_rcv+186/504]
tcp_v4_do_rcv+0xba/0x1f8
[snip]

...

[snip]
Jun 6 14:04:11 www kernel: [ 6464.558231] Pid: 24139, comm: clamscan
Not tainted 2.6.25.4 #1
Jun 6 14:04:11 www kernel: [ 6464.558234]
Jun 6 14:04:11 www kernel: [ 6464.558235] Call Trace:
Jun 6 14:04:11 www kernel: [ 6464.558239] <IRQ>
[__alloc_pages+544/890] __alloc_pages+0x220/0x37a
Jun 6 14:04:11 www kernel: [ 6464.558257] [tcp_v4_do_rcv+186/504]
tcp_v4_do_rcv+0xba/0x1f8
Jun 6 14:04:11 www kernel: [ 6464.558263]
[apic_timer_interrupt+102/112] apic_timer_interrupt+0x6
[snip]

On 6/7/08, Ilpo Järvinen <ilpo.jarvinen [at] helsinki> wrote:
> ...Added Brian Vowell.
>
> On Fri, 6 Jun 2008, Andrew Morton wrote:
>
>> On Sat, 7 Jun 2008 03:44:32 +0200 "Oliver Pinter" <oliver.pntr [at] gmail>
>> wrote:
>>
>> > Add Ingon and netdev to CC
>> >
>> >
>> > On 6/6/08, Zsiros Attila <zsirmo [at] gmail> wrote:
>> > > Hy!
>> > >
>> > > I have a problem.
>> > >
>> > > http://www.cyberszeg.hu/log/kern.log
>> > > http://www.cyberszeg.hu/log/config-2.6.25.4
>> > > http://www.cyberszeg.hu/log/lspci.txt
>> > > http://www.cyberszeg.hu/log/ifconfig.txt
>> > >
>>
>> : Jun 6 14:03:07 www kernel: [ 5897.660390] NETDEV WATCHDOG: eth0:
>> transmit timed out
>> : Jun 6 14:03:07 www kernel: [ 5897.660398] tg3: eth0: transmit timed
>> out, resetting
>> : Jun 6 14:03:07 www kernel: [ 5897.660432] tg3: DEBUG:
>> MAC_TX_STATUS[0000001e] MAC_RX_STATUS[0000000e]
>> : Jun 6 14:03:07 www kernel: [ 5897.660454] tg3: DEBUG:
>> RDMAC_STATUS[00000000] WDMAC_STATUS[00000000]
>> : Jun 6 14:03:07 www kernel: [ 5897.762983] tg3: tg3_stop_block timed
>> out, ofs=1800 enable_bit=2
>> : Jun 6 14:03:07 www kernel: [ 5897.864168] tg3: tg3_stop_block timed
>> out, ofs=c00 enable_bit=2
>> : Jun 6 14:03:07 www kernel: [ 5897.965619] tg3: tg3_stop_block timed
>> out, ofs=4800 enable_bit=2
>>
>> That looks like a driver failure.
>>
>> : Jun 6 14:03:07 www kernel: [ 5898.096689] tg3: eth0: Link is down.
>> : Jun 6 14:03:11 www kernel: [ 5901.633931] tg3: eth0: Link is up at 1000
>> Mbps, full duplex.
>> : Jun 6 14:03:11 www kernel: [ 5901.633937] tg3: eth0: Flow control is on
>> for TX and on for RX.
>> : Jun 6 14:04:11 www kernel: [ 6464.556309] clamscan: page allocation
>> failure. order:3, mode:0x4020
>> : Jun 6 14:04:11 www kernel: [ 6464.556319] Pid: 24139, comm: clamscan
>> Not tainted 2.6.25.4 #1
>> : Jun 6 14:04:11 www kernel: [ 6464.556325]
>> : Jun 6 14:04:11 www kernel: [ 6464.556326] Call Trace:
>> : Jun 6 14:04:11 www kernel: [ 6464.556329] <IRQ>
>> [__alloc_pages+544/890] __alloc_pages+0x220/0x37a
>> : Jun 6 14:04:11 www kernel: [ 6464.556353] [tcp_v4_do_rcv+186/504]
>> tcp_v4_do_rcv+0xba/0x1f8
>> : Jun 6 14:04:11 www kernel: [ 6464.556359] [ktime_get+12/98]
>> ktime_get+0xc/0x62
>> : Jun 6 14:04:11 www kernel: [ 6464.556364] [__netdev_alloc_skb+23/49]
>> __netdev_alloc_skb+0x17/0x31
>> : Jun 6 14:04:11 www kernel: [ 6464.556370] [__slab_alloc+330/1403]
>> __slab_alloc+0x14a/0x57b
>> : Jun 6 14:04:11 www kernel: [ 6464.556374] [__netdev_alloc_skb+23/49]
>> __netdev_alloc_skb+0x17/0x31
>> : Jun 6 14:04:11 www kernel: [ 6464.556379] [__netdev_alloc_skb+23/49]
>> __netdev_alloc_skb+0x17/0x31
>> : Jun 6 14:04:11 www kernel: [ 6464.556384]
>> [__kmalloc_track_caller+185/190] __kmalloc_track_caller+0xb9/0xbe
>> : Jun 6 14:04:11 www kernel: [ 6464.556391] [__alloc_skb+86/305]
>> __alloc_skb+0x56/0x131
>> : Jun 6 14:04:11 www kernel: [ 6464.556395] [__netdev_alloc_skb+23/49]
>> __netdev_alloc_skb+0x17/0x31
>> : Jun 6 14:04:11 www kernel: [ 6464.556408] [_end+128472975/2130444940]
>> :tg3:tg3_alloc_rx_skb+0x8f/0x17e
>> : Jun 6 14:04:11 www kernel: [ 6464.556418] [_end+128493403/2130444940]
>> :tg3:tg3_poll+0x6e8/0x922
>> : Jun 6 14:04:11 www kernel: [ 6464.556426] [net_rx_action+134/309]
>> net_rx_action+0x86/0x135
>> : Jun 6 14:04:11 www kernel: [ 6464.556433] [__do_softirq+102/212]
>> __do_softirq+0x66/0xd4
>> : Jun 6 14:04:11 www kernel: [ 6464.556439] [call_softirq+28/48]
>> call_softirq+0x1c/0x30
>> : Jun 6 14:04:11 www kernel: [ 6464.556444] [do_softirq+48/107]
>> do_softirq+0x30/0x6b
>> : Jun 6 14:04:11 www kernel: [ 6464.556448] [do_IRQ+114/212]
>> do_IRQ+0x72/0xd4
>> : Jun 6 14:04:11 www kernel: [ 6464.556453] [ret_from_intr+0/10]
>> ret_from_intr+0x0/0xa
>>
>> The driver is trying to do a 32 kbyte GFP_ATOMIC memory allocation.
>> rofl, good luck with that.
>>
>> But the netwoking code sould survive this.
>>
>> <12 billion more page allocation failures>
>>
>> Are you using jumbo frames or have you manually set the MTU to
>> something enormous? Because 32k is a pretty crazy amount of memory for
>> the driver to be trying to allocate - it's going to fail all over the
>> place, as you have discovered.
>
> Same allocation failed problem (among an TCP issue that is nowadays
> fixed) was also reported by Brian Vowell:
> http://bugzilla.kernel.org/show_bug.cgi?id=10767
>
>
> --
> i.
>


--
Thanks,
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


kernel at linuxace

Jun 7, 2008, 8:09 AM

Post #14 of 17 (419 views)
Permalink
Re: bug report [In reply to]

On Sat, Jun 07, 2008 at 02:50:06PM +0200, Oliver Pinter wrote:
> [snip]
> Jun 6 14:04:11 www kernel: [ 6464.556309] clamscan: page allocation
> failure. order:3, mode:0x4020 <------------- this

"Me too". Lots of order 3 allocation failures on e1000 nics
since upgrading some heavy traffic boxes to 2.6.25 (though from 2.6.21,
so unclear on when it began).

Phil

Jun 2 11:11:24 px01 kernel: swapper: page allocation failure. order:3, mode:0x4020
Jun 2 11:11:24 px01 kernel: Pid: 0, comm: swapper Not tainted 2.6.25.2-x86_64.1 #1
Jun 2 11:11:24 px01 kernel:
Jun 2 11:11:24 px01 kernel: Call Trace:
Jun 2 11:11:24 px01 kernel: <IRQ> [<ffffffff8024ce51>] __alloc_pages+0x2dd/0x2f6
Jun 2 11:11:24 px01 kernel: [<ffffffff8026578d>] __slab_alloc+0x16e/0x4f9
Jun 2 11:11:24 px01 kernel: [<ffffffff80394e84>] tcp_collapse+0x164/0x394
Jun 2 11:11:25 px01 kernel: [<ffffffff802656d0>] __slab_alloc+0xb1/0x4f9
Jun 2 11:11:25 px01 kernel: [<ffffffff80394e84>] tcp_collapse+0x164/0x394
Jun 2 11:11:25 px01 kernel: [<ffffffff8026685d>] __kmalloc_track_caller+0x82/0xb8
Jun 2 11:11:25 px01 kernel: [<ffffffff8036a124>] __alloc_skb+0x5b/0x121
Jun 2 11:11:25 px01 kernel: [<ffffffff80394e84>] tcp_collapse+0x164/0x394
Jun 2 11:11:25 px01 kernel: [<ffffffff80395261>] tcp_prune_queue+0x1ad/0x21e
Jun 2 11:11:25 px01 kernel: [<ffffffff803954ba>] tcp_data_queue+0x1e8/0xbab
Jun 2 11:11:25 px01 kernel: [<ffffffff803974e8>] tcp_rcv_established+0x64c/0x6fc
Jun 2 11:11:25 px01 kernel: [<ffffffff8039c76f>] tcp_v4_do_rcv+0x2c/0x1b4
Jun 2 11:11:25 px01 kernel: [<ffffffff8039e43e>] tcp_v4_rcv+0x6b3/0x705
Jun 2 11:11:25 px01 kernel: [<ffffffff80384cdc>] ip_local_deliver_finish+0xf6/0x1b3
Jun 2 11:11:25 px01 kernel: [<ffffffff80384bc3>] ip_rcv_finish+0x2bf/0x2e2
Jun 2 11:11:25 px01 kernel: [<ffffffff8023ada3>] getnstimeofday+0x2f/0x83
Jun 2 11:11:25 px01 kernel: [<ffffffff8036e6b2>] netif_receive_skb+0x1af/0x21b
Jun 2 11:11:25 px01 kernel: [<ffffffff8032da6d>] e1000_clean_rx_irq+0x3f3/0x4e7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


oliver.pntr at gmail

Jun 7, 2008, 11:53 AM

Post #15 of 17 (397 views)
Permalink
Re: bug report [In reply to]

Hi!

Attila first use one other nic (rtl8169), and after one other (3com
BCM570). All NIC producted this error...
the full thread in Hungarian Unix Portal: http://hup.hu/node/56295

On 6/7/08, Phil Oester <kernel [at] linuxace> wrote:
> On Sat, Jun 07, 2008 at 02:50:06PM +0200, Oliver Pinter wrote:
>> [snip]
>> Jun 6 14:04:11 www kernel: [ 6464.556309] clamscan: page allocation
>> failure. order:3, mode:0x4020 <------------- this
>
> "Me too". Lots of order 3 allocation failures on e1000 nics
> since upgrading some heavy traffic boxes to 2.6.25 (though from 2.6.21,
> so unclear on when it began).
>
> Phil
>
> Jun 2 11:11:24 px01 kernel: swapper: page allocation failure. order:3,
> mode:0x4020
> Jun 2 11:11:24 px01 kernel: Pid: 0, comm: swapper Not tainted
> 2.6.25.2-x86_64.1 #1
> Jun 2 11:11:24 px01 kernel:
> Jun 2 11:11:24 px01 kernel: Call Trace:
> Jun 2 11:11:24 px01 kernel: <IRQ> [<ffffffff8024ce51>]
> __alloc_pages+0x2dd/0x2f6
> Jun 2 11:11:24 px01 kernel: [<ffffffff8026578d>] __slab_alloc+0x16e/0x4f9
> Jun 2 11:11:24 px01 kernel: [<ffffffff80394e84>] tcp_collapse+0x164/0x394
> Jun 2 11:11:25 px01 kernel: [<ffffffff802656d0>] __slab_alloc+0xb1/0x4f9
> Jun 2 11:11:25 px01 kernel: [<ffffffff80394e84>] tcp_collapse+0x164/0x394
> Jun 2 11:11:25 px01 kernel: [<ffffffff8026685d>]
> __kmalloc_track_caller+0x82/0xb8
> Jun 2 11:11:25 px01 kernel: [<ffffffff8036a124>] __alloc_skb+0x5b/0x121
> Jun 2 11:11:25 px01 kernel: [<ffffffff80394e84>] tcp_collapse+0x164/0x394
> Jun 2 11:11:25 px01 kernel: [<ffffffff80395261>]
> tcp_prune_queue+0x1ad/0x21e
> Jun 2 11:11:25 px01 kernel: [<ffffffff803954ba>]
> tcp_data_queue+0x1e8/0xbab
> Jun 2 11:11:25 px01 kernel: [<ffffffff803974e8>]
> tcp_rcv_established+0x64c/0x6fc
> Jun 2 11:11:25 px01 kernel: [<ffffffff8039c76f>] tcp_v4_do_rcv+0x2c/0x1b4
> Jun 2 11:11:25 px01 kernel: [<ffffffff8039e43e>] tcp_v4_rcv+0x6b3/0x705
> Jun 2 11:11:25 px01 kernel: [<ffffffff80384cdc>]
> ip_local_deliver_finish+0xf6/0x1b3
> Jun 2 11:11:25 px01 kernel: [<ffffffff80384bc3>] ip_rcv_finish+0x2bf/0x2e2
> Jun 2 11:11:25 px01 kernel: [<ffffffff8023ada3>] getnstimeofday+0x2f/0x83
> Jun 2 11:11:25 px01 kernel: [<ffffffff8036e6b2>]
> netif_receive_skb+0x1af/0x21b
> Jun 2 11:11:25 px01 kernel: [<ffffffff8032da6d>]
> e1000_clean_rx_irq+0x3f3/0x4e7
>
>


--
Thanks,
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


zsirmo at zsirmo

Jun 8, 2008, 4:56 AM

Post #16 of 17 (386 views)
Permalink
Re: bug report [In reply to]

Hy!

Newer log
http://www.cyberszeg.hu/log/kern2.log

Zsirmo

Oliver Pinter írta:
> Hi!
>
> Attila first use one other nic (rtl8169), and after one other (3com
> BCM570). All NIC producted this error...
> the full thread in Hungarian Unix Portal: http://hup.hu/node/56295
>
> On 6/7/08, Phil Oester <kernel [at] linuxace> wrote:
>
>> On Sat, Jun 07, 2008 at 02:50:06PM +0200, Oliver Pinter wrote:
>>
>>> [snip]
>>> Jun 6 14:04:11 www kernel: [ 6464.556309] clamscan: page allocation
>>> failure. order:3, mode:0x4020 <------------- this
>>>
>> "Me too". Lots of order 3 allocation failures on e1000 nics
>> since upgrading some heavy traffic boxes to 2.6.25 (though from 2.6.21,
>> so unclear on when it began).
>>
>> Phil
>>
>> Jun 2 11:11:24 px01 kernel: swapper: page allocation failure. order:3,
>> mode:0x4020
>> Jun 2 11:11:24 px01 kernel: Pid: 0, comm: swapper Not tainted
>> 2.6.25.2-x86_64.1 #1
>> Jun 2 11:11:24 px01 kernel:
>> Jun 2 11:11:24 px01 kernel: Call Trace:
>> Jun 2 11:11:24 px01 kernel: <IRQ> [<ffffffff8024ce51>]
>> __alloc_pages+0x2dd/0x2f6
>> Jun 2 11:11:24 px01 kernel: [<ffffffff8026578d>] __slab_alloc+0x16e/0x4f9
>> Jun 2 11:11:24 px01 kernel: [<ffffffff80394e84>] tcp_collapse+0x164/0x394
>> Jun 2 11:11:25 px01 kernel: [<ffffffff802656d0>] __slab_alloc+0xb1/0x4f9
>> Jun 2 11:11:25 px01 kernel: [<ffffffff80394e84>] tcp_collapse+0x164/0x394
>> Jun 2 11:11:25 px01 kernel: [<ffffffff8026685d>]
>> __kmalloc_track_caller+0x82/0xb8
>> Jun 2 11:11:25 px01 kernel: [<ffffffff8036a124>] __alloc_skb+0x5b/0x121
>> Jun 2 11:11:25 px01 kernel: [<ffffffff80394e84>] tcp_collapse+0x164/0x394
>> Jun 2 11:11:25 px01 kernel: [<ffffffff80395261>]
>> tcp_prune_queue+0x1ad/0x21e
>> Jun 2 11:11:25 px01 kernel: [<ffffffff803954ba>]
>> tcp_data_queue+0x1e8/0xbab
>> Jun 2 11:11:25 px01 kernel: [<ffffffff803974e8>]
>> tcp_rcv_established+0x64c/0x6fc
>> Jun 2 11:11:25 px01 kernel: [<ffffffff8039c76f>] tcp_v4_do_rcv+0x2c/0x1b4
>> Jun 2 11:11:25 px01 kernel: [<ffffffff8039e43e>] tcp_v4_rcv+0x6b3/0x705
>> Jun 2 11:11:25 px01 kernel: [<ffffffff80384cdc>]
>> ip_local_deliver_finish+0xf6/0x1b3
>> Jun 2 11:11:25 px01 kernel: [<ffffffff80384bc3>] ip_rcv_finish+0x2bf/0x2e2
>> Jun 2 11:11:25 px01 kernel: [<ffffffff8023ada3>] getnstimeofday+0x2f/0x83
>> Jun 2 11:11:25 px01 kernel: [<ffffffff8036e6b2>]
>> netif_receive_skb+0x1af/0x21b
>> Jun 2 11:11:25 px01 kernel: [<ffffffff8032da6d>]
>> e1000_clean_rx_irq+0x3f3/0x4e7
>>
>>
>>
>
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


oliver.pntr at gmail

Jun 9, 2008, 10:04 AM

Post #17 of 17 (380 views)
Permalink
Re: bug report [In reply to]

an other case, but with nvidia

http://frugalware.org/paste/2639

On 6/8/08, Zsiros Attila <zsirmo [at] zsirmo> wrote:
> Hy!
>
> Newer log
> http://www.cyberszeg.hu/log/kern2.log
>
> Zsirmo
>
> Oliver Pinter írta:
>> Hi!
>>
>> Attila first use one other nic (rtl8169), and after one other (3com
>> BCM570). All NIC producted this error...
>> the full thread in Hungarian Unix Portal: http://hup.hu/node/56295
>>
>> On 6/7/08, Phil Oester <kernel [at] linuxace> wrote:
>>
>>> On Sat, Jun 07, 2008 at 02:50:06PM +0200, Oliver Pinter wrote:
>>>
>>>> [snip]
>>>> Jun 6 14:04:11 www kernel: [ 6464.556309] clamscan: page allocation
>>>> failure. order:3, mode:0x4020 <------------- this
>>>>
>>> "Me too". Lots of order 3 allocation failures on e1000 nics
>>> since upgrading some heavy traffic boxes to 2.6.25 (though from 2.6.21,
>>> so unclear on when it began).
>>>
>>> Phil
>>>
>>> Jun 2 11:11:24 px01 kernel: swapper: page allocation failure. order:3,
>>> mode:0x4020
>>> Jun 2 11:11:24 px01 kernel: Pid: 0, comm: swapper Not tainted
>>> 2.6.25.2-x86_64.1 #1
>>> Jun 2 11:11:24 px01 kernel:
>>> Jun 2 11:11:24 px01 kernel: Call Trace:
>>> Jun 2 11:11:24 px01 kernel: <IRQ> [<ffffffff8024ce51>]
>>> __alloc_pages+0x2dd/0x2f6
>>> Jun 2 11:11:24 px01 kernel: [<ffffffff8026578d>]
>>> __slab_alloc+0x16e/0x4f9
>>> Jun 2 11:11:24 px01 kernel: [<ffffffff80394e84>]
>>> tcp_collapse+0x164/0x394
>>> Jun 2 11:11:25 px01 kernel: [<ffffffff802656d0>]
>>> __slab_alloc+0xb1/0x4f9
>>> Jun 2 11:11:25 px01 kernel: [<ffffffff80394e84>]
>>> tcp_collapse+0x164/0x394
>>> Jun 2 11:11:25 px01 kernel: [<ffffffff8026685d>]
>>> __kmalloc_track_caller+0x82/0xb8
>>> Jun 2 11:11:25 px01 kernel: [<ffffffff8036a124>] __alloc_skb+0x5b/0x121
>>> Jun 2 11:11:25 px01 kernel: [<ffffffff80394e84>]
>>> tcp_collapse+0x164/0x394
>>> Jun 2 11:11:25 px01 kernel: [<ffffffff80395261>]
>>> tcp_prune_queue+0x1ad/0x21e
>>> Jun 2 11:11:25 px01 kernel: [<ffffffff803954ba>]
>>> tcp_data_queue+0x1e8/0xbab
>>> Jun 2 11:11:25 px01 kernel: [<ffffffff803974e8>]
>>> tcp_rcv_established+0x64c/0x6fc
>>> Jun 2 11:11:25 px01 kernel: [<ffffffff8039c76f>]
>>> tcp_v4_do_rcv+0x2c/0x1b4
>>> Jun 2 11:11:25 px01 kernel: [<ffffffff8039e43e>] tcp_v4_rcv+0x6b3/0x705
>>> Jun 2 11:11:25 px01 kernel: [<ffffffff80384cdc>]
>>> ip_local_deliver_finish+0xf6/0x1b3
>>> Jun 2 11:11:25 px01 kernel: [<ffffffff80384bc3>]
>>> ip_rcv_finish+0x2bf/0x2e2
>>> Jun 2 11:11:25 px01 kernel: [<ffffffff8023ada3>]
>>> getnstimeofday+0x2f/0x83
>>> Jun 2 11:11:25 px01 kernel: [<ffffffff8036e6b2>]
>>> netif_receive_skb+0x1af/0x21b
>>> Jun 2 11:11:25 px01 kernel: [<ffffffff8032da6d>]
>>> e1000_clean_rx_irq+0x3f3/0x4e7
>>>
>>>
>>>
>>
>>
>>
>
>


--
Thanks,
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.