Re: 2.6.20-rc5: known unfixed regressions
On Sat, 13 Jan 2007, Adrian Bunk wrote:
On Sat, Jan 13, 2007 at 04:51:36PM +0100, Damien Wyart wrote:
* Adrian Bunk <[EMAIL PROTECTED]> [070113 08:11]:
This still leaves the old regressions we have not yet fixed...
This email lists some known regressions in 2.6.20-rc5 compared to 2.6.19.
Subject: BUG: scheduling while atomic: hald-addon-stor/...
cdrom_{open,release,ioctl} in trace
References : http://lkml.org/lkml/2006/12/26/105
http://lkml.org/lkml/2006/12/29/22
http://lkml.org/lkml/2006/12/31/133
Submitter : Jon Smirl <[EMAIL PROTECTED]>
Damien Wyart <[EMAIL PROTECTED]>
Aaron Sethman <[EMAIL PROTECTED]>
Status : unknown
I have not seen the problem since using rc3, so I guess it is ok now.
Maybe the commit 9414232fa0cc28e2f51b8c76d260f2748f7953fc has fixed the
problem, but I am not 100% sure.
Thanks for this information.
Jon, Aaron, can you confirm it's fixed in -rc5?
I haven't seen it in a while anyways, fwiw.
-Aaron
-
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/
BUG: scheduling while atomic on 2.6.20-rc2-git1 on x86-64
Got the following trace on 2.6.20-rc2-git2 on x86-64. Let me know if there is additional details that is needed. -Aaron BUG: scheduling while atomic: hald-addon-stor/0x2000/2902 Call Trace: [] __sched_text_start+0x5d/0x834 [] __wake_up+0x43/0x70 [] scsi_done+0x0/0x20 [] atapi_xlat+0x0/0x120 [] __cond_resched+0x1c/0x50 [] cond_resched+0x29/0x40 [] __reacquire_kernel_lock+0x26/0x47 [] thread_return+0xa4/0xec [] scsi_done+0x0/0x20 [] __cond_resched+0x1c/0x50 [] cond_resched+0x29/0x40 [] wait_for_completion+0x17/0xf0 [] blk_execute_rq_nowait+0x88/0xb0 [] blk_execute_rq+0xbe/0x110 [] get_request_wait+0x37/0x170 [] scsi_execute+0xed/0x120 [] scsi_execute_req+0xcf/0x110 [] ioctl_internal_command+0x74/0x1a0 [] scsi_set_medium_removal+0x4f/0x90 [] bd_claim+0x18/0x80 [] blkdev_open+0x0/0x80 [] cdrom_release+0x1ba/0x240 [] __dentry_open+0x115/0x1e0 [] sr_block_release+0x29/0x50 [] __blkdev_put+0x7e/0x160 [] __fput+0xc5/0x1c0 [] filp_close+0x71/0x90 [] sys_close+0x92/0xf0 [] system_call+0x7e/0x83 - 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/
Re: [OOPS] bcm43xx oops on 2.6.20-rc1 on x86_64
On Sat, 30 Dec 2006, Adrian Bunk wrote: On Sun, Dec 17, 2006 at 03:15:28PM -0500, Aaron Sethman wrote: Just was loading the bcm43xx module and got the following oops. Note that this card is one of the newer PCI-E cards. If any other info is needed let me know. Is this issue still present in 2.6.10-rc2-git1? If yes, was 2.6.19 working fine? This seems to be fixed in 2.6.20-rc2-git1. Still having other issues with the driver, but the oops in the SoftMAC code is resolved now at least. -Aaron - 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/
[OOPS] bcm43xx oops on 2.6.20-rc1 on x86_64
Just was loading the bcm43xx module and got the following oops. Note that
this card is one of the newer PCI-E cards. If any other info is needed
let me know.
-Aaron
ACPI: PCI Interrupt :0c:00.0[A] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device :0c:00.0 to 64
bcm43xx: Chip ID 0x4311, rev 0x1
bcm43xx: Number of cores: 4
bcm43xx: Core 0: ID 0x800, rev 0x11, vendor 0x4243
bcm43xx: Core 1: ID 0x812, rev 0xa, vendor 0x4243
bcm43xx: Core 2: ID 0x817, rev 0x3, vendor 0x4243
bcm43xx: Core 3: ID 0x820, rev 0x1, vendor 0x4243
bcm43xx: PHY connected
bcm43xx: Detected PHY: Version: 4, Type 2, Revision 8
bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)
bcm43xx: Radio turned off
bcm43xx: Radio turned off
Unable to handle kernel NULL pointer dereference at 0011 RIP:
[] :ieee80211:ieee80211_wx_set_encode+0x14a/0x4a7
PGD 33a22067 PUD 3469b067 PMD 0
Oops: [1] SMP
CPU 0
Modules linked in: bcm43xx rng_core ieee80211softmac ieee80211
ieee80211_crypt
Pid: 4088, comm: iwconfig Not tainted 2.6.20-rc1 #2
RIP: 0010:[] []
:ieee80211:ieee80211_wx_set_encode+0x14a/0x4a7
RSP: 0018:810032d3fc28 EFLAGS: 00010202
RAX: 0001 RBX: 81003332ebf8 RCX:
RDX: RSI: RDI: 810032d3fcd5
RBP: 81003332ebf8 R08: 0005 R09: 810032d3fc48
R10: R11: 0202 R12: 81003332e4c0
R13: R14: R15: 810032d3fe58
FS: 2b7863a2d6d0() GS:80697000()
knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 0011 CR3: 3427 CR4: 26e0
Process iwconfig (pid: 4088, threadinfo 810032d3e000, task
810037c4f690)
Stack: 81003d87ecc0 0001
80290ede
0404
Call Trace:
[] touch_atime+0xde/0x130
[] ioctl_standard_call+0x26b/0x3b0
[] :bcm43xx:bcm43xx_wx_set_encoding+0x0/0x10
[] find_get_page+0x29/0x60
[] filemap_nopage+0x194/0x350
[] :bcm43xx:bcm43xx_wx_set_encoding+0x0/0x10
[] wireless_process_ioctl+0x105/0x3d0
[] __handle_mm_fault+0x465/0xad0
[] dev_ioctl+0x346/0x3c0
[] __up_read+0x21/0xb0
[] sock_ioctl+0x220/0x240
[] do_ioctl+0x2f/0xa0
[] vfs_ioctl+0x2a3/0x2e0
[] sys_ioctl+0x49/0x80
[] error_exit+0x0/0x84
[] system_call+0x7e/0x83
Code: 48 8b 40 10 48 85 c0 0f 84 01 01 00 00 48 8b 30 b9 04 00 00
RIP [] :ieee80211:ieee80211_wx_set_encode+0x14a/0x4a7
RSP
CR2: 0011
-
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/
Re: 2.4.5 kernel on Sparc32
I've seen the exact same problem when trying to compile for sparc. I might try and fix it myself, as it doesn't seemed to be fixed in the vger cvs tree, or any other patch for that matter. Regards, Aaron On Tue, 29 May 2001, John wrote: > Sorry if this is a repeat. Can't find anything on it. My guess is that > I don't know where to look. I am trying to build the 2.4.5 kernel on a > Sparc LX. I get numerous error messages when trying to build the > kernel: > > > > make[1]: Entering directory `/usr/src/linux-2.4.5/mm' > > make all_targets > > make[2]: Entering directory `/usr/src/linux-2.4.5/mm' > > gcc -D__KERNEL__ -I/usr/src/linux-2.4.5/include -Wall -Wstrict-prototypes -O2 >-fomit-frame-pointer -fno-strict-aliasing -m32 -pipe -mno-fpu -fcall-used-g5 >-fcall-used-g7-c -o memory.o memory.c > > memory.c:183: macro `pmd_alloc' used with too many (3) args > > memory.c:204: macro `pte_alloc' used with too many (3) args > > memory.c:725: macro `pte_alloc' used with too many (3) args > > memory.c:750: macro `pmd_alloc' used with too many (3) args > > memory.c:805: macro `pte_alloc' used with too many (3) args > > memory.c:832: macro `pmd_alloc' used with too many (3) args > > memory.c:1339: macro `pmd_alloc' used with too many (3) args > > memory.c:1342: macro `pte_alloc' used with too many (3) args > > memory.c:1392: macro `pte_alloc' used with too many (3) args > > memory.c: In function `copy_page_range': > > memory.c:183: warning: passing arg 1 of `___f_pmd_alloc' from incompatible pointer >type > > memory.c:183: warning: passing arg 2 of `___f_pmd_alloc' makes integer from >pointer without a cast > > memory.c:204: warning: passing arg 1 of `___f_pte_alloc' from incompatible pointer >type > > memory.c:204: warning: passing arg 2 of `___f_pte_alloc' makes integer from >pointer without a cast > > memory.c: In function `zeromap_pmd_range': > > memory.c:725: warning: passing arg 1 of `___f_pte_alloc' from incompatible pointer >type > > memory.c:725: warning: passing arg 2 of `___f_pte_alloc' makes integer from >pointer without a cast > > memory.c: In function `zeromap_page_range': > > memory.c:750: warning: passing arg 1 of `___f_pmd_alloc' from incompatible pointer >type > > memory.c:750: warning: passing arg 2 of `___f_pmd_alloc' makes integer from >pointer without a cast > > memory.c: In function `remap_pmd_range': > > memory.c:805: warning: passing arg 1 of `___f_pte_alloc' from incompatible pointer >type > > memory.c:805: warning: passing arg 2 of `___f_pte_alloc' makes integer from >pointer without a cast > > memory.c: In function `remap_page_range': > > memory.c:832: warning: passing arg 1 of `___f_pmd_alloc' from incompatible pointer >type > > memory.c:832: warning: passing arg 2 of `___f_pmd_alloc' makes integer from >pointer without a cast > > memory.c: In function `handle_mm_fault': > > memory.c:1339: warning: passing arg 1 of `___f_pmd_alloc' from incompatible >pointer type > > memory.c:1339: warning: passing arg 2 of `___f_pmd_alloc' makes integer from >pointer without a cast > > memory.c:1342: warning: passing arg 1 of `___f_pte_alloc' from incompatible >pointer type > > memory.c:1342: warning: passing arg 2 of `___f_pte_alloc' makes integer from >pointer without a cast > > memory.c: In function `__pmd_alloc': > > memory.c:1364: warning: implicit declaration of function `pmd_alloc_one_fast' > > memory.c:1364: warning: assignment makes pointer from integer without a cast > > memory.c:1367: warning: implicit declaration of function `pmd_alloc_one' > > memory.c:1367: warning: assignment makes pointer from integer without a cast > > memory.c:1381: warning: implicit declaration of function `pgd_populate' > > memory.c: At top level: > > memory.c:1393: conflicting types for `___f_pte_alloc' > > /usr/src/linux-2.4.5/include/asm/pgalloc.h:125: previous declaration of >`___f_pte_alloc' > > memory.c: In function `___f_pte_alloc': > > memory.c:1398: warning: implicit declaration of function `pte_alloc_one_fast' > > memory.c:1398: `address' undeclared (first use in this function) > > memory.c:1398: (Each undeclared identifier is reported only once > > memory.c:1398: for each function it appears in.) > > memory.c:1398: warning: assignment makes pointer from integer without a cast > > memory.c:1401: warning: implicit declaration of function `pte_alloc_one' > > memory.c:1401: warning: assignment makes pointer from integer without a cast > > memory.c:1415: warning: implicit declaration of function `pmd_populate' > > make[2]: *** [memory.o] Error 1 > > make[2]: Leaving directory `/usr/src/linux-2.4.5/mm' > > make[1]: *** [first_rule] Error 2 > > make[1]: Leaving directory `/usr/src/linux-2.4.5/mm' > > make: *** [_dir_mm] Error 2 > > > > -- tia > > - > 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
Odd error message..
__alloc_pages: 2-order allocation failed. I get many of these across the console when testing a network application that. Basically the client opens up a bunch of connections to the server and starts firing off data as quickly as it can. If you need further information please let me know. Regards, Aaron - 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/
Re: pre5 VM feedback..
On 15 Jan 2001, Linus Torvalds wrote: > Now, I'm not saying your filesystem is toast. I'm just saying that if > you booted up in pre6, I'd suggest a quick reboot into a better kernel > might be a good idea (be a jock, and do a sync and just push the reset > button to force a proper fsck when it comes up - just in case). > > (And yes, I renamed the pre6's really quickly, so you had to be unlucky > to see them.) Alas, I was one of those poor saps who got his / filesystem mangled a bit by pre6. Luckly nothing too horrid happened...just /etc/inittab happened to not exist and other strangeness. At least I know I am not losing my mind now :) Aaron - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux 2.2.19pre and thttpd (VM-global problem?)
On Fri, 29 Dec 2000, Daniel R. Kegel wrote: > Andrea Arcangeli wrote: > > Petru Paler wrote: > > > This is one of the main thttpd design points: run in a select() loop. Since > > > it is intended for mainly static workloads, it performs quite well... > > > > It can't scale in SMP. > > thttpd is i/o bound, not CPU bound, so there's no need for SMP scaling. > It's an effective little server as long as the active document > tree fits in RAM. > > If it ain't broke, don't tell people how to fix it :-) > > (If for some reason SMP scaling was desirable, the thttpd > way to do it would be to introduce one thread for each > CPU, and have each thread run the same select() loop.) One could possibly cheat and use fork() instead of using threads. Do your listen() before forking..then both get the listener socket.. Threads aren't always the answer, in this case it wouldn't probably gain you anything over just doing a fork() on SMP. Especially if you got not good reason to be sharing data that closely, which I don't think thttpd would. Aaron - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Oops with microcode update driver on 2.2.19pre3
I am getting the following oops while trying to update the microcode of a PII@266mhz using the microcode update driver. Below is the output of ksymoops. This was built using egcs-1.1.2. Also in case it matters I've applied the ide-2.2.18 patch so I can use my Promise ATA66 controller and the latest reiserfs patch.. Regards, Aaron ksymoops 0.7c on i686 2.2.19pre3. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.2.19pre3/ (default) -m /usr/src/linux/System.map (default) No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? Unable to handle kernel paging request at virtual address c823e12c current->tss.cr3 = 05e9b000, %cr3 = 05e9b000 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 0006 ebx: ecx: edx: bf87933c esi: c023e120 edi: c6c31000 ebp: c5e9c000 esp: c5e9df4c ds: 0018 es: 0018 ss: 0018 Process microcode_ctl (pid: 1011, process nr: 48, stackpage=c5e9d000) Stack: c6c31000 c5e9c000 0025 06101c8c c8a5 c8a34000 c010782d 0001b800 c5e84540 c6c31000 c5e9c000 c0107c21 c5bcabb0 ffea c01245c9 c5e84540 bf85db3c 0001b800 c5e84554 c5e9c000 0003 Call Trace: [] [] [] [] [] [] [] Code: a1 2c e1 23 c8 a8 01 74 5a 6a 00 68 20 78 20 c0 e8 d2 bc 00 >>EIP; c01078b1<= Trace; c8a5 Trace; c8a34000 Trace; c010782d Trace; c0107c21 Trace; c01245c9 Trace; c0107b38 Trace; c01094e8 Code; c01078b1 <_EIP>: Code; c01078b1<= 0: a1 2c e1 23 c8mov0xc823e12c,%eax <= Code; c01078b6 5: a8 01 test $0x1,%al Code; c01078b8 7: 74 5a je 63 <_EIP+0x63> c0107914 Code; c01078ba 9: 6a 00 push $0x0 Code; c01078bc b: 68 20 78 20 c0push $0xc0207820 Code; c01078c1 10: e8 d2 bc 00 00call bce7 <_EIP+0xbce7> c0113598 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Ext2 & Performances
You might want to take a look at using reiserfs on the 130GB partition, as its is journalled and doesn't need to be fsck'ed. Take a look a http://devlinux.com/namesys/ Aaron On Tue, 21 Nov 2000, Roberto Fichera wrote: > At 19.00 21/11/00 +0100, Jakob Østergaard wrote: > > >On Tue, Nov 21, 2000 at 05:58:58PM +0100, Roberto Fichera wrote: > > > Hi All, > > > > > > I need to know if there are some differences, in performances, between > > > a ext2 filesystem in a 10Gb partition and another that reside in a 130Gb, > > > each one have 4Kb block size. > > > > > > I'm configuring a Compaq ML350 2x800PIII, 1Gb RAM, 5x36Gb UWS3 RAID 5 > > > with Smart Array 4300, as database SQL server. So I need to chose > > between a > > > single > > > partition of 130Gb or multiple small partitions, depending by the > > performances. > > > >Does your database *require* a filesystem ? At least Oracle can do without, > >but I don't know about others... > > Currently I'm using PostgreSQL. > > >Usually, if you want performance, you let the database use the block device > >without putting a filesystem on top of it. > > Yes! I know! Oracle should be a good choice for that. > > >You probably don't want a 130G ext2 if there is any chance that a power > >surge etc. can cause the machine to reboot without umount()'ing the > >filesystem. A fsck on a 130G filesystem is going to take a *long* time. > > Yes! I know :-((!!! I'm looking for other fs that are journaled like ext3 > or raiserfs > but I don't know which are a good choice for stability and performances. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)
On Thu, 2 Nov 2000, Andi Kleen wrote: > On Thu, Nov 02, 2000 at 07:07:12PM +, Alan Cox wrote: > > > 1. There are architectures where some other compiler may do better > > > optimizations than gcc. I will cite some examples here, no need to argue > > > > I think we only care about this when they become free software. > > SGI's pro64 is free software and AFAIK is able to compile a kernel on IA64. > It is also not clear if gcc will ever produce good code on IA64. Well if its compiling the kernel just fine without alterations to the code, then fine. If not, if the SGI compiler is GPL'd pillage its sources and get that code working in gcc. Otherwise, trying to get linux to work with other C compilers doesn't seem worth the effort. Aaron - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.2.17 with RedHat 7 Problem !
Try compiling the said code with -fno-strict-aliasing, and your problems
will be solved. gcc is doing the right thing, just not what you expected.
The kernel already checks to see if gcc can grok -fno-strict-aliasing
Aaron
On 23 Oct 2000, David Wragg wrote:
> Gregory Maxwell <[EMAIL PROTECTED]> writes:
> > If 2.96 is broken, I'd appreciate it if you would describe the breakage.
>
> As in the RedHat 2.96? Try compiling the following on RedHat 7.0 x86
> with "gcc -O2" and take a look at the generated code. Nice, isn't it?
>
>
> #include
>
> void foo(void)
> {
> struct itimerval iv;
>
> iv.it_interval.tv_sec = 0;
> iv.it_interval.tv_usec = 25;
> iv.it_value = iv.it_interval;
>
> setitimer(ITIMER_REAL, &iv, NULL);
> }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 & OOM handler
On Mon, 9 Oct 2000, James Sutherland wrote: > On Mon, 9 Oct 2000, Ingo Molnar wrote: > > > On Mon, 9 Oct 2000, Rik van Riel wrote: > > > > > > so dns helper is killed first, then netscape. (my idea might not > > > > make sense though.) > > > > > > It makes some sense, but I don't think OOM is something that > > > occurs often enough to care about it /that/ much... > > > > i'm trying to handle Andrea's case, the init=/bin/bash manual-bootup case, > > with 4MB RAM and no swap, where the admin tries to exec a 2MB process. I > > think it's a legitimate concern - i cannot know in advance whether a > > freshly started process would trigger an OOM or not. > > Shouldn't the runtime factor handle this, making sure the new process is > killed? (Maybe not if you're almost OOM right from the word go, and run > this process straight off... Hrm.) I think the run time should probably be accounted into to this as well. Basically start knocking off recent processes first, which are likely to be childless, and start working your way up in age. The reasoning here is that your less likely an important, long running service. Of course you could probably account for whether the process is childless or not as well. Just my $0.02 on it.. Aaron - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
