Re: [PATCH 2.6.12-rc1-mm2] x86_64: fix vsyscall.c syntax error
Mikael Pettersson <[EMAIL PROTECTED]> writes: Can you please cc me on all x86-64 patches? > Compiling 2.6.12-rc1-mm2 on x86_64 with gcc-4.0 fails with: > > arch/x86_64/kernel/vsyscall.c:193: error: syntax error before > 'vsyscall_sysctl_change' > > Fix: repair the syntax error Looks ok thanks. I wish gcc folks wouldnt change the language in each revision like this. -Andi - 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: x86-64 preemption fix from IRQ and BKL in 2.6.12-rc1-mm2
On Sun, Mar 27, 2005 at 08:05:13PM +0200, Christophe Saout wrote: > Am Sonntag, den 27.03.2005, 19:26 +0200 schrieb Andi Kleen: > > > > preempt_schedule_irq is not an i386 specific function and seems to take > > > special care of BKL preemption and since reiserfs does use the BKL to do > > > certain things I think this actually might be the problem...? > > > > Hmm, preempt_schedule_irq is not in mainline as far as I can see. > > My patches are always for mainline; i dont do a special > > patch kit for -mm* > > PREEMPT_BKL has been in mainline since 2.6.11-rc1, preempt_schedule_irq > made it in 2.6.11-rc3. Please look here: > http://linux.bkbits.net:8080/linux-2.6/search/?expr=preempt_schedule_irq=ChangeSet+comments Hmm, true. I must have missed it with the last merge. Looking at the changeset your simple patch is probably ok. > > Now that I looked into it I think that it's obviously the correct > solution. Agreed. -Andi - 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: x86-64 preemption fix from IRQ and BKL in 2.6.12-rc1-mm2
On Sun, Mar 27, 2005 at 08:05:13PM +0200, Christophe Saout wrote: Am Sonntag, den 27.03.2005, 19:26 +0200 schrieb Andi Kleen: preempt_schedule_irq is not an i386 specific function and seems to take special care of BKL preemption and since reiserfs does use the BKL to do certain things I think this actually might be the problem...? Hmm, preempt_schedule_irq is not in mainline as far as I can see. My patches are always for mainline; i dont do a special patch kit for -mm* PREEMPT_BKL has been in mainline since 2.6.11-rc1, preempt_schedule_irq made it in 2.6.11-rc3. Please look here: http://linux.bkbits.net:8080/linux-2.6/search/?expr=preempt_schedule_irqsearch=ChangeSet+comments Hmm, true. I must have missed it with the last merge. Looking at the changeset your simple patch is probably ok. Now that I looked into it I think that it's obviously the correct solution. Agreed. -Andi - 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: [PATCH 2.6.12-rc1-mm2] x86_64: fix vsyscall.c syntax error
Mikael Pettersson [EMAIL PROTECTED] writes: Can you please cc me on all x86-64 patches? Compiling 2.6.12-rc1-mm2 on x86_64 with gcc-4.0 fails with: arch/x86_64/kernel/vsyscall.c:193: error: syntax error before 'vsyscall_sysctl_change' Fix: repair the syntax error Looks ok thanks. I wish gcc folks wouldnt change the language in each revision like this. -Andi - 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: x86-64 preemption fix from IRQ and BKL in 2.6.12-rc1-mm2
Am Sonntag, den 27.03.2005, 19:26 +0200 schrieb Andi Kleen: > > preempt_schedule_irq is not an i386 specific function and seems to take > > special care of BKL preemption and since reiserfs does use the BKL to do > > certain things I think this actually might be the problem...? > > Hmm, preempt_schedule_irq is not in mainline as far as I can see. > My patches are always for mainline; i dont do a special > patch kit for -mm* PREEMPT_BKL has been in mainline since 2.6.11-rc1, preempt_schedule_irq made it in 2.6.11-rc3. Please look here: http://linux.bkbits.net:8080/linux-2.6/search/?expr=preempt_schedule_irq=ChangeSet+comments For i386 the first change was to switch to preempt_schedule in this code path: http://linux.bkbits.net:8080/linux-2.6/[EMAIL PROTECTED] preempt_schedule takes care of setting PREEMPT_ACTIVE and resetting it afterwards, so I removed that from the assembler code. Then preempt_schedule_irq has been introduced to move the sti/cli back around the call to schedule: http://linux.bkbits.net:8080/linux-2.6/[EMAIL PROTECTED] So in the end the only thing that the patch I proposed was doing is to *additionally* handle the PREEMPT_BKL case so that schedule doesn't accidentally release the BKL semaphore when it shouldn't because we are preempting and nobody explicitly called schedule. Several other archs have done the same. No bug has shown up until the recent -mm kernel where the execution of this code path actually became possible (the "jc -> jnc" fix some lines above). > It looks like a unfortunate interaction with some other patches > in mm. Andrew, can you disable CONFIG_PREEMPT on x86-64 in > mm for now? These things are in 2.6.11 (except that they never got called because of the wrong interrupt flag check in the IRQ handler). > > Unfortunately I don't have a amd64 machine to play with, so can somebody > > please check this? > > How did you generate the crash dumps above then? Well, nobody minds if I play with a webserver in the middle of the night, as long as it works during the day. Shoot me. :) Both servers are running fine since I applied my patch last night. Now that I looked into it I think that it's obviously the correct solution. signature.asc Description: This is a digitally signed message part
Re: x86-64 preemption fix from IRQ and BKL in 2.6.12-rc1-mm2
On Fri, Mar 25, 2005 at 08:26:25PM +0100, Christophe Saout wrote: > Fortunately the kernel locked up and there was no data corruption. > > I've got PREEMPT and PREEMPT_BKL enabled under UP. > > I just took a look at the change and found this: > > x86-64 does this (in entry.S): > > bt $9,EFLAGS-ARGOFFSET(%rsp) /* interrupts off? */ > jnc retint_restore_args > movl $PREEMPT_ACTIVE,threadinfo_preempt_count(%rcx) > sti > call schedule > cli > GET_THREAD_INFO(%rcx) > movl $0,threadinfo_preempt_count(%rcx) > jmp exit_intr > > while i386 does this: > > testl $IF_MASK,EFLAGS(%esp) # interrupts off (exception path) ? > jz restore_all > call preempt_schedule_irq > jmp need_resched > > preempt_schedule_irq is not an i386 specific function and seems to take > special care of BKL preemption and since reiserfs does use the BKL to do > certain things I think this actually might be the problem...? Hmm, preempt_schedule_irq is not in mainline as far as I can see. My patches are always for mainline; i dont do a special patch kit for -mm* It looks like a unfortunate interaction with some other patches in mm. Andrew, can you disable CONFIG_PREEMPT on x86-64 in mm for now? Just calling preempt_schedule_irq may also work, but most likely the patch that introduces that function needs careful reading if it does not require more support from architectures. BTW I suspect it will break other archs too... > Unfortunately I don't have a amd64 machine to play with, so can somebody > please check this? How did you generate the crash dumps above then? -Andi - 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: x86-64 preemption fix from IRQ and BKL in 2.6.12-rc1-mm2
On Fri, Mar 25, 2005 at 08:26:25PM +0100, Christophe Saout wrote: Fortunately the kernel locked up and there was no data corruption. I've got PREEMPT and PREEMPT_BKL enabled under UP. I just took a look at the change and found this: x86-64 does this (in entry.S): bt $9,EFLAGS-ARGOFFSET(%rsp) /* interrupts off? */ jnc retint_restore_args movl $PREEMPT_ACTIVE,threadinfo_preempt_count(%rcx) sti call schedule cli GET_THREAD_INFO(%rcx) movl $0,threadinfo_preempt_count(%rcx) jmp exit_intr while i386 does this: testl $IF_MASK,EFLAGS(%esp) # interrupts off (exception path) ? jz restore_all call preempt_schedule_irq jmp need_resched preempt_schedule_irq is not an i386 specific function and seems to take special care of BKL preemption and since reiserfs does use the BKL to do certain things I think this actually might be the problem...? Hmm, preempt_schedule_irq is not in mainline as far as I can see. My patches are always for mainline; i dont do a special patch kit for -mm* It looks like a unfortunate interaction with some other patches in mm. Andrew, can you disable CONFIG_PREEMPT on x86-64 in mm for now? Just calling preempt_schedule_irq may also work, but most likely the patch that introduces that function needs careful reading if it does not require more support from architectures. BTW I suspect it will break other archs too... Unfortunately I don't have a amd64 machine to play with, so can somebody please check this? How did you generate the crash dumps above then? -Andi - 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: x86-64 preemption fix from IRQ and BKL in 2.6.12-rc1-mm2
Am Sonntag, den 27.03.2005, 19:26 +0200 schrieb Andi Kleen: preempt_schedule_irq is not an i386 specific function and seems to take special care of BKL preemption and since reiserfs does use the BKL to do certain things I think this actually might be the problem...? Hmm, preempt_schedule_irq is not in mainline as far as I can see. My patches are always for mainline; i dont do a special patch kit for -mm* PREEMPT_BKL has been in mainline since 2.6.11-rc1, preempt_schedule_irq made it in 2.6.11-rc3. Please look here: http://linux.bkbits.net:8080/linux-2.6/search/?expr=preempt_schedule_irqsearch=ChangeSet+comments For i386 the first change was to switch to preempt_schedule in this code path: http://linux.bkbits.net:8080/linux-2.6/[EMAIL PROTECTED] preempt_schedule takes care of setting PREEMPT_ACTIVE and resetting it afterwards, so I removed that from the assembler code. Then preempt_schedule_irq has been introduced to move the sti/cli back around the call to schedule: http://linux.bkbits.net:8080/linux-2.6/[EMAIL PROTECTED] So in the end the only thing that the patch I proposed was doing is to *additionally* handle the PREEMPT_BKL case so that schedule doesn't accidentally release the BKL semaphore when it shouldn't because we are preempting and nobody explicitly called schedule. Several other archs have done the same. No bug has shown up until the recent -mm kernel where the execution of this code path actually became possible (the jc - jnc fix some lines above). It looks like a unfortunate interaction with some other patches in mm. Andrew, can you disable CONFIG_PREEMPT on x86-64 in mm for now? These things are in 2.6.11 (except that they never got called because of the wrong interrupt flag check in the IRQ handler). Unfortunately I don't have a amd64 machine to play with, so can somebody please check this? How did you generate the crash dumps above then? Well, nobody minds if I play with a webserver in the middle of the night, as long as it works during the day. Shoot me. :) Both servers are running fine since I applied my patch last night. Now that I looked into it I think that it's obviously the correct solution. signature.asc Description: This is a digitally signed message part
Re: OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
On Fri, 25 Mar 2005 20:50:35 +0100, Jean Delvare <[EMAIL PROTECTED]> wrote: > > > [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls > > > ./ ../ device@ > > > [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls -l > > > Segmentation fault > > > > What device is that, and which driver is handling it? > > If I am allowed a wild guess here... Isn't by any chance i2c-1 one the > the 3 i2c adapters exported by the nvidiafb driver, which we know isn't > playing nicely with the i2c core? To me, it is simply a different > expression of the same bug Miles hit some days ago when loading the > i2c-dev or eeprom modules [1]. You are exactly right. The /sys issues had to do with i2c stuff associated the nvidiafb driver. Miles - 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: [PATCH] make Documentation/oops-tracing.txt relevant to 2.6 [was Re: OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2]
On Fri, 2005-03-25 at 21:52 +, Russell King wrote: > On Fri, Mar 25, 2005 at 04:45:32PM -0500, Lee Revell wrote: > > On Fri, 2005-03-25 at 21:07 +, Russell King wrote: > > > On Fri, Mar 25, 2005 at 03:53:42PM -0500, Lee Revell wrote: > > > > On Fri, 2005-03-25 at 07:38 +, Russell King wrote: > > > > > Users need to be re-educated _not_ to use ksymoops. > > > > > > > > How about changing the fscking docs to not tell users to use it? > > > > > > Would be useful. The "fscking" problem is that no one actually owns the > > > documents, so there's no central focus to keep them up to date. > > > > > > > Are you serious? So Documentation/sound/alsa/* isn't maintained by the > > ALSA maintainers? > > Last I checked, Documentation/oops-tracking.txt wasn't under > Documentation/sound/alsa. It seems obvious to me, but maybe it isn't > obvious to others, as your message appears to suggest. > No, I just misread your message as "none of the docs are maintained" rather than "oops-tracking.txt is not maintained". > As far as the question of ALSA documentation being up to date, that's > one set of directories in the kernel tree I've _never_ looked at, so > can't comment. Sorry. > The ALSA docs are in fact up to date. Lee - 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: [PATCH] make Documentation/oops-tracing.txt relevant to 2.6 [was Re: OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2]
On Fri, Mar 25, 2005 at 04:45:32PM -0500, Lee Revell wrote: > On Fri, 2005-03-25 at 21:07 +, Russell King wrote: > > On Fri, Mar 25, 2005 at 03:53:42PM -0500, Lee Revell wrote: > > > On Fri, 2005-03-25 at 07:38 +, Russell King wrote: > > > > Users need to be re-educated _not_ to use ksymoops. > > > > > > How about changing the fscking docs to not tell users to use it? > > > > Would be useful. The "fscking" problem is that no one actually owns the > > documents, so there's no central focus to keep them up to date. > > > > Are you serious? So Documentation/sound/alsa/* isn't maintained by the > ALSA maintainers? Last I checked, Documentation/oops-tracking.txt wasn't under Documentation/sound/alsa. It seems obvious to me, but maybe it isn't obvious to others, as your message appears to suggest. As far as the question of ALSA documentation being up to date, that's one set of directories in the kernel tree I've _never_ looked at, so can't comment. Sorry. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - 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/
[PATCH] make Documentation/oops-tracing.txt relevant to 2.6 [was Re: OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2]
On Fri, 2005-03-25 at 21:07 +, Russell King wrote: > On Fri, Mar 25, 2005 at 03:53:42PM -0500, Lee Revell wrote: > > On Fri, 2005-03-25 at 07:38 +, Russell King wrote: > > > Users need to be re-educated _not_ to use ksymoops. > > > > How about changing the fscking docs to not tell users to use it? > > Would be useful. The "fscking" problem is that no one actually owns the > documents, so there's no central focus to keep them up to date. > Are you serious? So Documentation/sound/alsa/* isn't maintained by the ALSA maintainers? Wow, this would explain why all Linux documentation is at least 2 years out of date. > Maybe we need a docfsck? 8) > > I certainly don't have authority to tell x86 people not to use ksymoops. > Therefore, I think my suggested change (which up until recently I thought > was an ARM only problem) should be done by someone else. > At least from my experience, ksymoops is useless on x86 for 2.6 kernels. Here is a patch to finally bring oops-tracing.txt into the 2.6 era. :-P Sugned-Off-By: Lee Revell <[EMAIL PROTECTED]> Lee --- Documentation/oops-tracing.txt~ 2005-03-17 20:34:06.0 -0500 +++ Documentation/oops-tracing.txt 2005-03-25 16:41:07.0 -0500 @@ -1,23 +1,22 @@ +NOTE: ksymoops is useless on 2.6. Please use the Oops in its original format +(from dmesg, etc). Ignore any references in this or other docs to "decoding +the Oops" or "running it through ksymoops". If you post an Oops fron 2.6 that +has been run through ksymoops, people will just tell you to repost it. + Quick Summary - -Install ksymoops from -ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops -Read the ksymoops man page. -ksymoops < the_oops.txt - -and send the output the maintainer of the kernel area that seems to be -involved with the problem, not to the ksymoops maintainer. Don't worry -too much about getting the wrong person. If you are unsure send it to -the person responsible for the code relevant to what you were doing. -If it occurs repeatably try and describe how to recreate it. Thats -worth even more than the oops +Find the Oops and send it to the maintainer of the kernel area that seems to be +involved with the problem. Don't worry too much about getting the wrong person. +If you are unsure send it to the person responsible for the code relevant to +what you were doing. If it occurs repeatably try and describe how to recreate +it. That's worth even more than the oops. If you are totally stumped as to whom to send the report, send it to [EMAIL PROTECTED] Thanks for your help in making Linux as stable as humanly possible. -Where is the_oops.txt? +Where is the Oops? -- Normally the Oops text is read from the kernel buffers by klogd and @@ -43,15 +42,14 @@ them yourself. Search kernel archives for kmsgdump, lkcd and oops+smram. -No matter how you capture the log output, feed the resulting file to -ksymoops along with /proc/ksyms and /proc/modules that applied at the -time of the crash. /var/log/ksymoops can be useful to capture the -latter, man ksymoops for details. - Full Information +NOTE: the message from Linus below applies to 2.4 kernel. I have preserved it +for historical reasons, and because some of the information in it still +applies. Especially, please ignore any references to ksymoops. + From: Linus Torvalds <[EMAIL PROTECTED]> How to track down an Oops.. [originally a mail to linux-kernel] - 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 running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
On Fri, Mar 25, 2005 at 03:53:42PM -0500, Lee Revell wrote: > On Fri, 2005-03-25 at 07:38 +, Russell King wrote: > > Users need to be re-educated _not_ to use ksymoops. > > How about changing the fscking docs to not tell users to use it? Would be useful. The "fscking" problem is that no one actually owns the documents, so there's no central focus to keep them up to date. Maybe we need a docfsck? 8) I certainly don't have authority to tell x86 people not to use ksymoops. Therefore, I think my suggested change (which up until recently I thought was an ARM only problem) should be done by someone else. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - 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 running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
On Fri, 2005-03-25 at 07:38 +, Russell King wrote: > Users need to be re-educated _not_ to use ksymoops. > How about changing the fscking docs to not tell users to use it? Seems like lots of stuff in Documentation/ is stuck in 2.4 land. How about purging it? Incorrect docs are worse than nothing. Lee - 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 running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
Hi Andrew, Miles, > > Andrew, this command causes the Oops for me: > > > > [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls > > ./ ../ device@ > > [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls -l > > Segmentation fault > > What device is that, and which driver is handling it? If I am allowed a wild guess here... Isn't by any chance i2c-1 one the the 3 i2c adapters exported by the nvidiafb driver, which we know isn't playing nicely with the i2c core? To me, it is simply a different expression of the same bug Miles hit some days ago when loading the i2c-dev or eeprom modules [1]. Miles, do you have the same problem with i2c-0 and i2c-2, or only i2c-1? Can you please confirm that with CONFIG_FB_NVIDIA_I2C unset, the oops vanishes? [1] http://archives.andrew.net.au/lm-sensors/msg29974.html Thanks, -- Jean Delvare - 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/
x86-64 preemption fix from IRQ and BKL in 2.6.12-rc1-mm2
Hi,
> +x86_64-fix-config_preempt.patch
>
> x86_64-fix-config_preempt.patch
> x86_64: Fix CONFIG_PREEMPT
Has this one been stress-tested?
I've got the impression that things have become a lot worse.
I've been seeing things like these:
Mar 25 01:00:48 websrv2 REISERFS: panic (device dm-1): clm-6000: do_balance, fs
generation has changed
Mar 25 01:00:48 websrv2
Mar 25 01:00:48 websrv2 --- [cut here ] - [please bite here ]
-
Mar 25 01:00:48 websrv2 Kernel BUG at prints:362
Mar 25 01:00:48 websrv2 invalid operand: [1] PREEMPT
Mar 25 01:00:48 websrv2 CPU 0
Mar 25 01:00:48 websrv2 Modules linked in: iptable_nat ipt_MARK iptable_mangle
ipt_LOG ipt_multiport ipt_owner ipt_mark ipt_state ipt_REJECT iptable_filter
ip_tables twofish serpent blowfish ext3 jbd reiser4 sha256 aes dm_crypt
ip_conntrack_irc ip_conntrack_ftp ip_conntrack via_rhine 8139too crc32
Mar 25 01:00:48 websrv2 Pid: 25172, comm: rm Not tainted 2.6.12-rc1-cs1
Mar 25 01:00:48 websrv2 RIP: 0010:[]
{reiserfs_panic+211}
Mar 25 01:00:48 websrv2 RSP: 0018:81001efe37b8 EFLAGS: 00010292
Mar 25 01:00:48 websrv2 RAX: 0059 RBX: 803fbcac RCX:
c100
Mar 25 01:00:48 websrv2 RDX: RSI: 81007d0b31f0 RDI:
Mar 25 01:00:48 websrv2 RBP: 81004f960060 R08: 81001efe2000 R09:
0002
Mar 25 01:00:48 websrv2 R10: R11: 80340ef0 R12:
81007f850230
Mar 25 01:00:48 websrv2 R13: 81007f85 R14: R15:
81004f9565d0
Mar 25 01:00:48 websrv2 FS: 2aabaae0() GS:805be800()
knlGS:55563dc0
Mar 25 01:00:48 websrv2 CS: 0010 DS: ES: CR0: 8005003b
Mar 25 01:00:48 websrv2 CR2: 2aaff008 CR3: 1ebbd000 CR4:
06e0
Mar 25 01:00:48 websrv2 Process rm (pid: 25172, threadinfo 81001efe2000,
task 81007d0b31f0)
Mar 25 01:00:48 websrv2 Stack: 00300010 81001efe38a8
81001efe37d8 81001c041530
Mar 25 01:00:48 websrv2 81001efe39d8 801d4e42 81007e659a00
0063
Mar 25 01:00:48 websrv2 0063
Mar 25 01:00:48 websrv2 Call Trace:{pathrelse_and_restore+66}
{retint_kernel+46}
Mar 25 01:00:48 websrv2 {do_balance+39}
{do_balance+6901}
Mar 25 01:00:48 websrv2 {unfix_nodes+128}
{do_balance+10555}
Mar 25 01:00:48 websrv2 {reiserfs_cut_from_item+1673}
{reiserfs_unlink+362}
Mar 25 01:00:48 websrv2 {vfs_unlink+462}
{sys_unlink+233}
Mar 25 01:00:48 websrv2 {sys_getdents+232}
{error_exit+0}
Mar 25 01:00:48 websrv2 {system_call+126}
Mar 25 01:00:48 websrv2
Mar 25 01:00:48 websrv2 Code: 0f 0b b8 c1 3f 80 ff ff ff ff 6a 01 4d 85 ed 48
c7 c2 40 ba
Mar 25 01:00:48 websrv2 RIP {reiserfs_panic+211} RSP
or
Mar 25 16:39:21 websrv2 VFS: brelse: Trying to free free buffer
Mar 25 16:39:21 websrv2 Badness in __brelse at fs/buffer.c:1295
Mar 25 16:39:21 websrv2
Mar 25 16:39:21 websrv2 Call Trace:{__find_get_block+479}
{__getblk+37}
Mar 25 16:39:21 websrv2 {do_journal_end+2181}
{keventd_create_kthread+0}
Mar 25 16:39:21 websrv2 {reiserfs_sync_fs+64}
{sync_supers+211}
Mar 25 16:39:21 websrv2 {wb_kupdate+42}
{pdflush+399}
Mar 25 16:39:21 websrv2 {wb_kupdate+0}
{keventd_create_kthread+0}
Mar 25 16:39:21 websrv2 {pdflush+0}
{kthread+205}
Mar 25 16:39:21 websrv2 {child_rip+8}
{keventd_create_kthread+0}
Mar 25 16:39:21 websrv2 {kthread+0}
{child_rip+0}
Fortunately the kernel locked up and there was no data corruption.
I've got PREEMPT and PREEMPT_BKL enabled under UP.
I just took a look at the change and found this:
x86-64 does this (in entry.S):
bt $9,EFLAGS-ARGOFFSET(%rsp) /* interrupts off? */
jnc retint_restore_args
movl $PREEMPT_ACTIVE,threadinfo_preempt_count(%rcx)
sti
call schedule
cli
GET_THREAD_INFO(%rcx)
movl $0,threadinfo_preempt_count(%rcx)
jmp exit_intr
while i386 does this:
testl $IF_MASK,EFLAGS(%esp) # interrupts off (exception path) ?
jz restore_all
call preempt_schedule_irq
jmp need_resched
preempt_schedule_irq is not an i386 specific function and seems to take
special care of BKL preemption and since reiserfs does use the BKL to do
certain things I think this actually might be the problem...?
I'm not saying that this fix is wrong (it is obviously the right fix)
but it causes another problem to show up.
Unfortunately I don't have a amd64 machine to play with, so can somebody
please check this?
signature.asc
Description: This is a digitally signed message part
Re: OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
Miles Lane <[EMAIL PROTECTED]> wrote: > > Ahem. In this case, I think it was operator error. I reproduced the > problem and have included the entire output of ksymoops below. Please don't use ksymoops. 2.6 kernels decode oopses internally and ksymoops actually removes a little info. > Andrew, this command causes the Oops for me: > > [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls > ./ ../ device@ > [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls -l > Segmentation fault What device is that, and which driver is handling it? - 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.6.12-rc1-mm2
Le 25.03.2005 02:00, Patrick Mochel a écrit : On Thu, 24 Mar 2005, Andrew Morton wrote: Laurent Riffard <[EMAIL PROTECTED]> wrote: hello, Same kinds of problem here. It depends on the removed module. I mean: "rmmod loop" or "rmmod pcspkr" works. But "rmmod snd_ens1371" or "rmmod ohci1394" hangs. Sysrq-T when rmmoding snd_ens1371 : It looks like we're getting stuck in the wait_for_completion() in the new klist_remove(). D'oh! It's getting hung while waiting to remove the current node from the list (which it can't remove because it's being used). The patch below should fix it. Pat = drivers/base/dd.c 1.3 vs edited = --- 1.3/drivers/base/dd.c 2005-03-21 12:25:04 -08:00 +++ edited/drivers/base/dd.c2005-03-24 16:55:21 -08:00 @@ -177,7 +177,7 @@ sysfs_remove_link(>kobj, kobject_name(>kobj)); sysfs_remove_link(>kobj, "driver"); - klist_remove(>knode_driver); + klist_del(>knode_driver); down(>sem); device_detach_shutdown(dev); Ok, I can confirm this patch solved the problem. Thanks for your help. -- laurent signature.asc Description: OpenPGP digital signature
Re: OOPS running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
Ahem. In this case, I think it was operator error. I reproduced the problem and have included the entire output of ksymoops below. Andrew, this command causes the Oops for me: [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls ./ ../ device@ [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls -l Segmentation fault [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# dmesg|ksymoops -o /lib/modules/2.6.12-rc1-mm2 -m /boot/System.map-2.6.12-rc1-mm2 ksymoops 2.4.9 on i686 2.6.12-rc1-mm2. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.6.12-rc1-mm2 (specified) -m /boot/System.map-2.6.12-rc1-mm2 (specified) Error (regular_file): read_ksyms stat /proc/ksyms failed ksymoops: No such file or directory No modules in ksyms, skipping objects No ksyms, skipping lsmod [] dump_stack+0x1e/0x20 [] kref_get+0x42/0x50 [] kobject_get+0x1b/0x30 [] sysfs_getlink+0x41/0x150 [] sysfs_follow_link+0x4f/0x60 [] generic_readlink+0x2f/0x90 [] sys_readlink+0x86/0x90 [] syscall_call+0x7/0xb [] dump_stack+0x1e/0x20 [] kref_get+0x42/0x50 [] kobject_get+0x1b/0x30 [] sysfs_getlink+0x9d/0x150 [] sysfs_follow_link+0x4f/0x60 [] generic_readlink+0x2f/0x90 [] sys_readlink+0x86/0x90 [] syscall_call+0x7/0xb Unable to handle kernel paging request at virtual address 1000 c0198479 *pde = Oops: [#1] CPU:0 EIP:0060:[]Not tainted VLI Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00210246 (2.6.12-rc1-mm2) eax: ebx: ecx: edx: f7c0181c esi: 0001 edi: 1000 ebp: e7519e94 esp: e7519e88 ds: 007b es: 007b ss: 0068 Stack: 0002 e4fdea1c f7c0181c e7519eb8 c0198651 f7c0181c 0020 f7c0181c e7519eb8 c039f820 e4fdea1c f7c0181c e7519edc c0198790 f7c018cc f7c0181c e46a3000 f7c018cc e46a3000 fff4 e7519f10 e7519ef8 c019884f e4fdea1c Call Trace: [] show_stack+0x7f/0xa0 [] show_registers+0x15a/0x1c0 [] die+0xfc/0x190 [] do_page_fault+0x31b/0x670 [] error_code+0x4f/0x54 [] sysfs_get_target_path+0x21/0x80 [] sysfs_getlink+0xe0/0x150 [] sysfs_follow_link+0x4f/0x60 [] generic_readlink+0x2f/0x90 [] sys_readlink+0x86/0x90 [] syscall_call+0x7/0xb Code: 75 f8 c9 c3 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 55 89 e5 57 56 8b 55 08 be 01 00 00 00 53 31 db 8b 3a b9 ff ff ff ff 89 d8 ae f7 d1 49 8b 52 24 8d 74 31 01 85 d2 75 e7 5b 89 f0 5e 5f >>EIP; c0198479<= >>ecx; <__kernel_rt_sigreturn+1bbf/> >>edx; f7c0181c >>ebp; e7519e94 >>esp; e7519e88 Trace; c010410f Trace; c01042aa Trace; c01044ac Trace; c011450b Trace; c0103cf3 Trace; c0198651 Trace; c0198790 Trace; c019884f Trace; c016b46f Trace; c01635b6 Trace; c0103249 This architecture has variable length instructions, decoding before eip is unreliable, take these instructions with a pinch of salt. Code; c019844e <_EIP>: Code; c019844e 0: 75 f8 jnefffa <_EIP+0xfffa> Code; c0198450 2: c9leave Code; c0198451 3: c3ret Code; c0198452 4: 8d b4 26 00 00 00 00 lea0x0(%esi),%esi Code; c0198459 b: 8d bc 27 00 00 00 00 lea0x0(%edi),%edi Code; c0198460 12: 55push %ebp Code; c0198461 13: 89 e5 mov%esp,%ebp Code; c0198463 15: 57push %edi Code; c0198464 16: 56push %esi Code; c0198465 17: 8b 55 08 mov0x8(%ebp),%edx Code; c0198468 1a: be 01 00 00 00mov$0x1,%esi Code; c019846d 1f: 53push %ebx Code; c019846e 20: 31 db xor%ebx,%ebx Code; c0198470 22: 8b 3a mov(%edx),%edi Code; c0198472 24: b9 ff ff ff ffmov$0x,%ecx Code; c0198477 29: 89 d8 mov%ebx,%eax This decode from eip onwards should be reliable Code; c0198479 <_EIP>: Code; c0198479<= 0: f2 ae repnz scas %es:(%edi),%al <= Code; c019847b 2: f7 d1 not%ecx Code; c019847d 4: 49dec%ecx Code; c019847e 5: 8b 52 24 mov0x24(%edx),%edx Code; c0198481 8: 8d 74 31 01 lea0x1(%ecx,%esi,1),%esi Code; c0198485 c: 85 d2 test %edx,%edx Code; c0198487 e: 75 e7 jnefff7 <_EIP+0xfff7> Code; c0198489 10: 5bpop%ebx Code; c019848a 11: 89 f0 mov%esi,%eax Code; c019848c 13: 5epop%esi Code; c019848d 14: 5fpop%edi - To unsubscribe from this list: send the line "un
Re: 2.6.12-rc1-mm2: crash in drm_agp_init
> (Why does -mm2 kernel have > tendency to appear within hour from me downloading -mm1? It happened > two times now...) you just need a faster internet link :) - 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.6.12-rc1-mm2: crash in drm_agp_init
Hi! > > ..with -rc1-mm2 I get crash during bootup, in some function called > > from drm_agp_init. I'm turned off CONFIG_AGP for now, and machine now > > boots as expected. > > try -mm3 we had a bit of a patch clash between myself, Davej and > Adrian, I think -mm3 has all the fixes in it .. Thanks for the info and sorry for the noise. (Why does -mm2 kernel have tendency to appear within hour from me downloading -mm1? It happened two times now...) Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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.6.12-rc1-mm2: crash in drm_agp_init
> > ..with -rc1-mm2 I get crash during bootup, in some function called > from drm_agp_init. I'm turned off CONFIG_AGP for now, and machine now > boots as expected. try -mm3 we had a bit of a patch clash between myself, Davej and Adrian, I think -mm3 has all the fixes in it .. Dave. - 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/
2.6.12-rc1-mm2: crash in drm_agp_init
Hi! ..with -rc1-mm2 I get crash during bootup, in some function called from drm_agp_init. I'm turned off CONFIG_AGP for now, and machine now boots as expected. -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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 running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
On Fri, Mar 25, 2005 at 07:50:32AM +, Russell King wrote:
> On Thu, Mar 24, 2005 at 11:45:44PM -0800, Andrew Morton wrote:
> > Russell King <[EMAIL PROTECTED]> wrote:
> > > On Thu, Mar 24, 2005 at 08:22:15PM -0800, Andrew Morton wrote:
> > > > Miles Lane <[EMAIL PROTECTED]> wrote:
> > > > > Unable to handle kernel paging request at virtual address 24fc1024
> > > > > c0198448
> > > > > *pde =
> > > > > Oops: [#1]
> > > > > CPU:0
> > > > > EIP:0060:[]Not tainted VLI
> > > >
> > > > I wonder why the EIP sometimes doesn't get decoded.
> > > >
> > > > > Using defaults from ksymoops -t elf32-i386 -a i386
> > > > > EFLAGS: 00210206 (2.6.12-rc1-mm2)
> > >
> > > ksymoops seems to remove lines from the kernel output that it doesn't
> > > like.
> >
> > but. but. There used to be a symbol+0xN/0xM in the EIP: line. Are you
> > saying that ksymoops rubbed that out and stuck a hex number in there?
>
> The kernel's x86 format is:
>
> printk("EIP: %04x:[<%08lx>] CPU: %d\n",0x & regs->xcs,regs->eip,
> smp_processor_id());
> print_symbol("EIP is at %s\n", regs->eip);
Argh, wrong one, it's supposed to be:
print_modules();
printk("CPU:%d\nEIP:%04x:[<%08lx>]%s VLI\nEFLAGS: %08lx"
" (%s) \n",
smp_processor_id(), 0x & regs->xcs, regs->eip,
print_tainted(), regs->eflags, system_utsname.release);
print_symbol("EIP is at %s\n", regs->eip);
but the result is the same. Also note that the modules line is also
missing from the posted oops.
(Why does x86 duplicate the register dumping between process.c and
traps.c ?)
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
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 running ls -l /sys/class/i2c-adapter/*-- 2.6.12-rc1-mm2
On Fri, Mar 25, 2005 at 07:50:32AM +, Russell King wrote: On Thu, Mar 24, 2005 at 11:45:44PM -0800, Andrew Morton wrote: Russell King [EMAIL PROTECTED] wrote: On Thu, Mar 24, 2005 at 08:22:15PM -0800, Andrew Morton wrote: Miles Lane [EMAIL PROTECTED] wrote: Unable to handle kernel paging request at virtual address 24fc1024 c0198448 *pde = Oops: [#1] CPU:0 EIP:0060:[c0198448]Not tainted VLI I wonder why the EIP sometimes doesn't get decoded. Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00210206 (2.6.12-rc1-mm2) ksymoops seems to remove lines from the kernel output that it doesn't like. but. but. There used to be a symbol+0xN/0xM in the EIP: line. Are you saying that ksymoops rubbed that out and stuck a hex number in there? The kernel's x86 format is: printk(EIP: %04x:[%08lx] CPU: %d\n,0x regs-xcs,regs-eip, smp_processor_id()); print_symbol(EIP is at %s\n, regs-eip); Argh, wrong one, it's supposed to be: print_modules(); printk(CPU:%d\nEIP:%04x:[%08lx]%s VLI\nEFLAGS: %08lx (%s) \n, smp_processor_id(), 0x regs-xcs, regs-eip, print_tainted(), regs-eflags, system_utsname.release); print_symbol(EIP is at %s\n, regs-eip); but the result is the same. Also note that the modules line is also missing from the posted oops. (Why does x86 duplicate the register dumping between process.c and traps.c ?) -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - 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/
2.6.12-rc1-mm2: crash in drm_agp_init
Hi! ..with -rc1-mm2 I get crash during bootup, in some function called from drm_agp_init. I'm turned off CONFIG_AGP for now, and machine now boots as expected. -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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.6.12-rc1-mm2: crash in drm_agp_init
..with -rc1-mm2 I get crash during bootup, in some function called from drm_agp_init. I'm turned off CONFIG_AGP for now, and machine now boots as expected. try -mm3 we had a bit of a patch clash between myself, Davej and Adrian, I think -mm3 has all the fixes in it .. Dave. - 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.6.12-rc1-mm2: crash in drm_agp_init
Hi! ..with -rc1-mm2 I get crash during bootup, in some function called from drm_agp_init. I'm turned off CONFIG_AGP for now, and machine now boots as expected. try -mm3 we had a bit of a patch clash between myself, Davej and Adrian, I think -mm3 has all the fixes in it .. Thanks for the info and sorry for the noise. (Why does -mm2 kernel have tendency to appear within hour from me downloading -mm1? It happened two times now...) Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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.6.12-rc1-mm2: crash in drm_agp_init
(Why does -mm2 kernel have tendency to appear within hour from me downloading -mm1? It happened two times now...) you just need a faster internet link :) - 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.6.12-rc1-mm2
Le 25.03.2005 02:00, Patrick Mochel a écrit : On Thu, 24 Mar 2005, Andrew Morton wrote: Laurent Riffard [EMAIL PROTECTED] wrote: hello, Same kinds of problem here. It depends on the removed module. I mean: rmmod loop or rmmod pcspkr works. But rmmod snd_ens1371 or rmmod ohci1394 hangs. Sysrq-T when rmmoding snd_ens1371 : snip It looks like we're getting stuck in the wait_for_completion() in the new klist_remove(). D'oh! It's getting hung while waiting to remove the current node from the list (which it can't remove because it's being used). The patch below should fix it. Pat = drivers/base/dd.c 1.3 vs edited = --- 1.3/drivers/base/dd.c 2005-03-21 12:25:04 -08:00 +++ edited/drivers/base/dd.c2005-03-24 16:55:21 -08:00 @@ -177,7 +177,7 @@ sysfs_remove_link(drv-kobj, kobject_name(dev-kobj)); sysfs_remove_link(dev-kobj, driver); - klist_remove(dev-knode_driver); + klist_del(dev-knode_driver); down(dev-sem); device_detach_shutdown(dev); Ok, I can confirm this patch solved the problem. Thanks for your help. -- laurent signature.asc Description: OpenPGP digital signature
Re: OOPS running ls -l /sys/class/i2c-adapter/*-- 2.6.12-rc1-mm2
Miles Lane [EMAIL PROTECTED] wrote: Ahem. In this case, I think it was operator error. I reproduced the problem and have included the entire output of ksymoops below. Please don't use ksymoops. 2.6 kernels decode oopses internally and ksymoops actually removes a little info. Andrew, this command causes the Oops for me: [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls ./ ../ device@ [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls -l Segmentation fault What device is that, and which driver is handling it? - 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/
x86-64 preemption fix from IRQ and BKL in 2.6.12-rc1-mm2
Hi,
+x86_64-fix-config_preempt.patch
x86_64-fix-config_preempt.patch
x86_64: Fix CONFIG_PREEMPT
Has this one been stress-tested?
I've got the impression that things have become a lot worse.
I've been seeing things like these:
Mar 25 01:00:48 websrv2 REISERFS: panic (device dm-1): clm-6000: do_balance, fs
generation has changed
Mar 25 01:00:48 websrv2
Mar 25 01:00:48 websrv2 --- [cut here ] - [please bite here ]
-
Mar 25 01:00:48 websrv2 Kernel BUG at prints:362
Mar 25 01:00:48 websrv2 invalid operand: [1] PREEMPT
Mar 25 01:00:48 websrv2 CPU 0
Mar 25 01:00:48 websrv2 Modules linked in: iptable_nat ipt_MARK iptable_mangle
ipt_LOG ipt_multiport ipt_owner ipt_mark ipt_state ipt_REJECT iptable_filter
ip_tables twofish serpent blowfish ext3 jbd reiser4 sha256 aes dm_crypt
ip_conntrack_irc ip_conntrack_ftp ip_conntrack via_rhine 8139too crc32
Mar 25 01:00:48 websrv2 Pid: 25172, comm: rm Not tainted 2.6.12-rc1-cs1
Mar 25 01:00:48 websrv2 RIP: 0010:[801cfe13]
801cfe13{reiserfs_panic+211}
Mar 25 01:00:48 websrv2 RSP: 0018:81001efe37b8 EFLAGS: 00010292
Mar 25 01:00:48 websrv2 RAX: 0059 RBX: 803fbcac RCX:
c100
Mar 25 01:00:48 websrv2 RDX: RSI: 81007d0b31f0 RDI:
Mar 25 01:00:48 websrv2 RBP: 81004f960060 R08: 81001efe2000 R09:
0002
Mar 25 01:00:48 websrv2 R10: R11: 80340ef0 R12:
81007f850230
Mar 25 01:00:48 websrv2 R13: 81007f85 R14: R15:
81004f9565d0
Mar 25 01:00:48 websrv2 FS: 2aabaae0() GS:805be800()
knlGS:55563dc0
Mar 25 01:00:48 websrv2 CS: 0010 DS: ES: CR0: 8005003b
Mar 25 01:00:48 websrv2 CR2: 2aaff008 CR3: 1ebbd000 CR4:
06e0
Mar 25 01:00:48 websrv2 Process rm (pid: 25172, threadinfo 81001efe2000,
task 81007d0b31f0)
Mar 25 01:00:48 websrv2 Stack: 00300010 81001efe38a8
81001efe37d8 81001c041530
Mar 25 01:00:48 websrv2 81001efe39d8 801d4e42 81007e659a00
0063
Mar 25 01:00:48 websrv2 0063
Mar 25 01:00:48 websrv2 Call Trace:801d4e42{pathrelse_and_restore+66}
8010efe6{retint_kernel+46}
Mar 25 01:00:48 websrv2 801bb847{do_balance+39}
801bd315{do_balance+6901}
Mar 25 01:00:48 websrv2 801cbd90{unfix_nodes+128}
801be15b{do_balance+10555}
Mar 25 01:00:48 websrv2 801d7bf9{reiserfs_cut_from_item+1673}
801bfcfa{reiserfs_unlink+362}
Mar 25 01:00:48 websrv2 801873ae{vfs_unlink+462}
801874f9{sys_unlink+233}
Mar 25 01:00:48 websrv2 8018a268{sys_getdents+232}
8010f221{error_exit+0}
Mar 25 01:00:48 websrv2 8010e906{system_call+126}
Mar 25 01:00:48 websrv2
Mar 25 01:00:48 websrv2 Code: 0f 0b b8 c1 3f 80 ff ff ff ff 6a 01 4d 85 ed 48
c7 c2 40 ba
Mar 25 01:00:48 websrv2 RIP 801cfe13{reiserfs_panic+211} RSP
81001efe37b8
or
Mar 25 16:39:21 websrv2 VFS: brelse: Trying to free free buffer
Mar 25 16:39:21 websrv2 Badness in __brelse at fs/buffer.c:1295
Mar 25 16:39:21 websrv2
Mar 25 16:39:21 websrv2 Call Trace:8017787f{__find_get_block+479}
8017a175{__getblk+37}
Mar 25 16:39:21 websrv2 801de3d5{do_journal_end+2181}
80147d70{keventd_create_kthread+0}
Mar 25 16:39:21 websrv2 801cbf50{reiserfs_sync_fs+64}
8017c0b3{sync_supers+211}
Mar 25 16:39:21 websrv2 8015a22a{wb_kupdate+42}
8015ae8f{pdflush+399}
Mar 25 16:39:21 websrv2 8015a200{wb_kupdate+0}
80147d70{keventd_create_kthread+0}
Mar 25 16:39:21 websrv2 8015ad00{pdflush+0}
80147d2d{kthread+205}
Mar 25 16:39:21 websrv2 8010f3d7{child_rip+8}
80147d70{keventd_create_kthread+0}
Mar 25 16:39:21 websrv2 80147c60{kthread+0}
8010f3cf{child_rip+0}
Fortunately the kernel locked up and there was no data corruption.
I've got PREEMPT and PREEMPT_BKL enabled under UP.
I just took a look at the change and found this:
x86-64 does this (in entry.S):
bt $9,EFLAGS-ARGOFFSET(%rsp) /* interrupts off? */
jnc retint_restore_args
movl $PREEMPT_ACTIVE,threadinfo_preempt_count(%rcx)
sti
call schedule
cli
GET_THREAD_INFO(%rcx)
movl $0,threadinfo_preempt_count(%rcx)
jmp exit_intr
while i386 does this:
testl $IF_MASK,EFLAGS(%esp) # interrupts off (exception path) ?
jz restore_all
call preempt_schedule_irq
jmp need_resched
preempt_schedule_irq is not an i386 specific function and seems to take
special care of BKL preemption and since reiserfs does use the BKL to do
certain things I think this actually might be the problem...?
I'm not saying that this fix is wrong (it is obviously the right fix)
but it causes another problem to show up.
Unfortunately I don't have
Re: OOPS running ls -l /sys/class/i2c-adapter/*-- 2.6.12-rc1-mm2
Hi Andrew, Miles, Andrew, this command causes the Oops for me: [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls ./ ../ device@ [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls -l Segmentation fault What device is that, and which driver is handling it? If I am allowed a wild guess here... Isn't by any chance i2c-1 one the the 3 i2c adapters exported by the nvidiafb driver, which we know isn't playing nicely with the i2c core? To me, it is simply a different expression of the same bug Miles hit some days ago when loading the i2c-dev or eeprom modules [1]. Miles, do you have the same problem with i2c-0 and i2c-2, or only i2c-1? Can you please confirm that with CONFIG_FB_NVIDIA_I2C unset, the oops vanishes? [1] http://archives.andrew.net.au/lm-sensors/msg29974.html Thanks, -- Jean Delvare - 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 running ls -l /sys/class/i2c-adapter/*-- 2.6.12-rc1-mm2
On Fri, 2005-03-25 at 07:38 +, Russell King wrote: Users need to be re-educated _not_ to use ksymoops. How about changing the fscking docs to not tell users to use it? Seems like lots of stuff in Documentation/ is stuck in 2.4 land. How about purging it? Incorrect docs are worse than nothing. Lee - 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 running ls -l /sys/class/i2c-adapter/*-- 2.6.12-rc1-mm2
On Fri, Mar 25, 2005 at 03:53:42PM -0500, Lee Revell wrote: On Fri, 2005-03-25 at 07:38 +, Russell King wrote: Users need to be re-educated _not_ to use ksymoops. How about changing the fscking docs to not tell users to use it? Would be useful. The fscking problem is that no one actually owns the documents, so there's no central focus to keep them up to date. Maybe we need a docfsck? 8) I certainly don't have authority to tell x86 people not to use ksymoops. Therefore, I think my suggested change (which up until recently I thought was an ARM only problem) should be done by someone else. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - 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/
[PATCH] make Documentation/oops-tracing.txt relevant to 2.6 [was Re: OOPS running ls -l /sys/class/i2c-adapter/*-- 2.6.12-rc1-mm2]
On Fri, 2005-03-25 at 21:07 +, Russell King wrote: On Fri, Mar 25, 2005 at 03:53:42PM -0500, Lee Revell wrote: On Fri, 2005-03-25 at 07:38 +, Russell King wrote: Users need to be re-educated _not_ to use ksymoops. How about changing the fscking docs to not tell users to use it? Would be useful. The fscking problem is that no one actually owns the documents, so there's no central focus to keep them up to date. Are you serious? So Documentation/sound/alsa/* isn't maintained by the ALSA maintainers? Wow, this would explain why all Linux documentation is at least 2 years out of date. Maybe we need a docfsck? 8) I certainly don't have authority to tell x86 people not to use ksymoops. Therefore, I think my suggested change (which up until recently I thought was an ARM only problem) should be done by someone else. At least from my experience, ksymoops is useless on x86 for 2.6 kernels. Here is a patch to finally bring oops-tracing.txt into the 2.6 era. :-P Sugned-Off-By: Lee Revell [EMAIL PROTECTED] Lee --- Documentation/oops-tracing.txt~ 2005-03-17 20:34:06.0 -0500 +++ Documentation/oops-tracing.txt 2005-03-25 16:41:07.0 -0500 @@ -1,23 +1,22 @@ +NOTE: ksymoops is useless on 2.6. Please use the Oops in its original format +(from dmesg, etc). Ignore any references in this or other docs to decoding +the Oops or running it through ksymoops. If you post an Oops fron 2.6 that +has been run through ksymoops, people will just tell you to repost it. + Quick Summary - -Install ksymoops from -ftp://ftp.country.kernel.org/pub/linux/utils/kernel/ksymoops -Read the ksymoops man page. -ksymoops the_oops.txt - -and send the output the maintainer of the kernel area that seems to be -involved with the problem, not to the ksymoops maintainer. Don't worry -too much about getting the wrong person. If you are unsure send it to -the person responsible for the code relevant to what you were doing. -If it occurs repeatably try and describe how to recreate it. Thats -worth even more than the oops +Find the Oops and send it to the maintainer of the kernel area that seems to be +involved with the problem. Don't worry too much about getting the wrong person. +If you are unsure send it to the person responsible for the code relevant to +what you were doing. If it occurs repeatably try and describe how to recreate +it. That's worth even more than the oops. If you are totally stumped as to whom to send the report, send it to [EMAIL PROTECTED] Thanks for your help in making Linux as stable as humanly possible. -Where is the_oops.txt? +Where is the Oops? -- Normally the Oops text is read from the kernel buffers by klogd and @@ -43,15 +42,14 @@ them yourself. Search kernel archives for kmsgdump, lkcd and oops+smram. -No matter how you capture the log output, feed the resulting file to -ksymoops along with /proc/ksyms and /proc/modules that applied at the -time of the crash. /var/log/ksymoops can be useful to capture the -latter, man ksymoops for details. - Full Information +NOTE: the message from Linus below applies to 2.4 kernel. I have preserved it +for historical reasons, and because some of the information in it still +applies. Especially, please ignore any references to ksymoops. + From: Linus Torvalds [EMAIL PROTECTED] How to track down an Oops.. [originally a mail to linux-kernel] - 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: [PATCH] make Documentation/oops-tracing.txt relevant to 2.6 [was Re: OOPS running ls -l /sys/class/i2c-adapter/*-- 2.6.12-rc1-mm2]
On Fri, Mar 25, 2005 at 04:45:32PM -0500, Lee Revell wrote: On Fri, 2005-03-25 at 21:07 +, Russell King wrote: On Fri, Mar 25, 2005 at 03:53:42PM -0500, Lee Revell wrote: On Fri, 2005-03-25 at 07:38 +, Russell King wrote: Users need to be re-educated _not_ to use ksymoops. How about changing the fscking docs to not tell users to use it? Would be useful. The fscking problem is that no one actually owns the documents, so there's no central focus to keep them up to date. Are you serious? So Documentation/sound/alsa/* isn't maintained by the ALSA maintainers? Last I checked, Documentation/oops-tracking.txt wasn't under Documentation/sound/alsa. It seems obvious to me, but maybe it isn't obvious to others, as your message appears to suggest. As far as the question of ALSA documentation being up to date, that's one set of directories in the kernel tree I've _never_ looked at, so can't comment. Sorry. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - 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: [PATCH] make Documentation/oops-tracing.txt relevant to 2.6 [was Re: OOPS running ls -l /sys/class/i2c-adapter/*-- 2.6.12-rc1-mm2]
On Fri, 2005-03-25 at 21:52 +, Russell King wrote: On Fri, Mar 25, 2005 at 04:45:32PM -0500, Lee Revell wrote: On Fri, 2005-03-25 at 21:07 +, Russell King wrote: On Fri, Mar 25, 2005 at 03:53:42PM -0500, Lee Revell wrote: On Fri, 2005-03-25 at 07:38 +, Russell King wrote: Users need to be re-educated _not_ to use ksymoops. How about changing the fscking docs to not tell users to use it? Would be useful. The fscking problem is that no one actually owns the documents, so there's no central focus to keep them up to date. Are you serious? So Documentation/sound/alsa/* isn't maintained by the ALSA maintainers? Last I checked, Documentation/oops-tracking.txt wasn't under Documentation/sound/alsa. It seems obvious to me, but maybe it isn't obvious to others, as your message appears to suggest. No, I just misread your message as none of the docs are maintained rather than oops-tracking.txt is not maintained. As far as the question of ALSA documentation being up to date, that's one set of directories in the kernel tree I've _never_ looked at, so can't comment. Sorry. The ALSA docs are in fact up to date. Lee - 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 running ls -l /sys/class/i2c-adapter/*-- 2.6.12-rc1-mm2
On Fri, 25 Mar 2005 20:50:35 +0100, Jean Delvare [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls ./ ../ device@ [EMAIL PROTECTED]:/sys/class/i2c-adapter/i2c-1# ls -l Segmentation fault What device is that, and which driver is handling it? If I am allowed a wild guess here... Isn't by any chance i2c-1 one the the 3 i2c adapters exported by the nvidiafb driver, which we know isn't playing nicely with the i2c core? To me, it is simply a different expression of the same bug Miles hit some days ago when loading the i2c-dev or eeprom modules [1]. You are exactly right. The /sys issues had to do with i2c stuff associated the nvidiafb driver. Miles - 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 running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
On Thu, Mar 24, 2005 at 11:45:44PM -0800, Andrew Morton wrote:
> Russell King <[EMAIL PROTECTED]> wrote:
> > On Thu, Mar 24, 2005 at 08:22:15PM -0800, Andrew Morton wrote:
> > > Miles Lane <[EMAIL PROTECTED]> wrote:
> > > > Unable to handle kernel paging request at virtual address 24fc1024
> > > > c0198448
> > > > *pde =
> > > > Oops: [#1]
> > > > CPU:0
> > > > EIP:0060:[]Not tainted VLI
> > >
> > > I wonder why the EIP sometimes doesn't get decoded.
> > >
> > > > Using defaults from ksymoops -t elf32-i386 -a i386
> > > > EFLAGS: 00210206 (2.6.12-rc1-mm2)
> >
> > ksymoops seems to remove lines from the kernel output that it doesn't
> > like.
>
> but. but. There used to be a symbol+0xN/0xM in the EIP: line. Are you
> saying that ksymoops rubbed that out and stuck a hex number in there?
The kernel's x86 format is:
printk("EIP: %04x:[<%08lx>] CPU: %d\n",0x & regs->xcs,regs->eip,
smp_processor_id());
print_symbol("EIP is at %s\n", regs->eip);
so what you have there is the first EIP: line. The "EIP is at
symbol+0xN/0xM" is produced by the print_symbol statement, which
ksymoops decided to omit from the output.
It can be clearly seen from the rest of the oops (the call trace)
that print_symbol definitely does produce output, so kallsyms hasn't
been disabled.
> I wonder if there's something clever we could do to the kallsymsised oops
> output so that ksymoops would simply cease to recognise it.
I have been wondering why we still mark the addresses with [< >]
even though we've decoded them ourselves. Maybe omitting these
would be sufficient in the kallsyms-decoded case?
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
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 running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
Russell King <[EMAIL PROTECTED]> wrote: > > On Thu, Mar 24, 2005 at 08:22:15PM -0800, Andrew Morton wrote: > > Miles Lane <[EMAIL PROTECTED]> wrote: > > > Unable to handle kernel paging request at virtual address 24fc1024 > > > c0198448 > > > *pde = > > > Oops: [#1] > > > CPU:0 > > > EIP:0060:[]Not tainted VLI > > > > I wonder why the EIP sometimes doesn't get decoded. > > > > > Using defaults from ksymoops -t elf32-i386 -a i386 > > > EFLAGS: 00210206 (2.6.12-rc1-mm2) > > ksymoops seems to remove lines from the kernel output that it doesn't > like. but. but. There used to be a symbol+0xN/0xM in the EIP: line. Are you saying that ksymoops rubbed that out and stuck a hex number in there? > I've seen this many times on ARM, and each time I see an oops > from a 2.6 kernel which has been ksymoopsed, I always ask the submitter > to send the original non-ksymoopsed version. > > Users need to be re-educated _not_ to use ksymoops. I wonder if there's something clever we could do to the kallsymsised oops output so that ksymoops would simply cease to recognise it. - 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 running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
On Thu, Mar 24, 2005 at 08:22:15PM -0800, Andrew Morton wrote: > Miles Lane <[EMAIL PROTECTED]> wrote: > > Unable to handle kernel paging request at virtual address 24fc1024 > > c0198448 > > *pde = > > Oops: [#1] > > CPU:0 > > EIP:0060:[]Not tainted VLI > > I wonder why the EIP sometimes doesn't get decoded. > > > Using defaults from ksymoops -t elf32-i386 -a i386 > > EFLAGS: 00210206 (2.6.12-rc1-mm2) ksymoops seems to remove lines from the kernel output that it doesn't like. I've seen this many times on ARM, and each time I see an oops from a 2.6 kernel which has been ksymoopsed, I always ask the submitter to send the original non-ksymoopsed version. Users need to be re-educated _not_ to use ksymoops. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - 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.6.12-rc1-mm2
On Thu, Mar 24, 2005 at 05:00:18PM -0800, Patrick Mochel wrote: > > On Thu, 24 Mar 2005, Andrew Morton wrote: > > > Laurent Riffard <[EMAIL PROTECTED]> wrote: > > > > > > hello, > > > > > > Same kinds of problem here. It depends on the removed module. I mean: > > > "rmmod loop" or "rmmod pcspkr" works. But "rmmod snd_ens1371" or "rmmod > > > ohci1394" hangs. > > > > > > Sysrq-T when rmmoding snd_ens1371 : > > > > > It looks like we're getting stuck in the wait_for_completion() in the new > > klist_remove(). > > D'oh! It's getting hung while waiting to remove the current node from the > list (which it can't remove because it's being used). The patch below > should fix it. Thanks, I've added this to my bk trees. greg k-h - 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: Error building ndiswrapper-1.0rc1 against 2.6.12-rc1-mm2 sources
On Mar 24, 2005, at 23:15, Miles Lane wrote: Hi, Was this change intentional or accidental? I have successfully built ndiswrapper-1.0rc1 with the other recent kernel trees. warning: passing arg 4 of `call_usermodehelper' makes pointer from integer without a cast error: too few arguments to function `call_usermodehelper' call_usermodehelper was extended with a parameters to allow a keyring environment to be passed. As this is -mm, who knows whether the patch will make it into mainline or not. I suspect it will, though, due to its utility at which point external modules will need to be converted. Cheers, Kyle Moffett -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$ L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r !y?(-) --END GEEK CODE BLOCK-- - 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 running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
Miles Lane <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED]:/sys/class/i2c-adapter# ls * -l > [EMAIL PROTECTED]:/sys# cat */*/*/* > > ksymoops 2.4.9 on i686 2.6.12-rc1-mm2. Options used > -o /lib/modules/2.6.12-rc1-mm2 (specified) > -m /boot/System.map-2.6.12-rc1-mm2 (specified) > > Unable to handle kernel paging request at virtual address 24fc1024 > c0198448 > *pde = > Oops: [#1] > CPU:0 > EIP:0060:[]Not tainted VLI I wonder why the EIP sometimes doesn't get decoded. > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00210206 (2.6.12-rc1-mm2) > eax: 0001 ebx: c039f820 ecx: 0001 edx: 24fc1000 > esi: e75b6cc4 edi: f7c015e4 ebp: e7b93e94 esp: e7b93e94 > ds: 007b es: 007b ss: 0068 > Stack: e7b93eb8 c0198644 f7c01694 f7c015e4 e7b93eb8 c039f820 > e75b6cc4 > f7c015e4 e7b93edc c0198790 f7c01694 f7c015e4 e712a000 f7c01694 > e712a000 > fff4 e7b93f10 e7b93ef8 c019884f e75b6cc4 e712a000 ffea > e75b6cc4 > Call Trace: > [] show_stack+0x7f/0xa0 > [] show_registers+0x15a/0x1c0 > [] die+0xfc/0x190 > [] do_page_fault+0x31b/0x670 > [] error_code+0x4f/0x54 > [] sysfs_get_target_path+0x14/0x80 > [] sysfs_getlink+0xe0/0x150 > [] sysfs_follow_link+0x4f/0x60 > [] generic_readlink+0x2f/0x90 > [] sys_readlink+0x86/0x90 > [] syscall_call+0x7/0xb > Code: 42 70 e8 a4 fc 19 00 e9 f3 fe ff ff 90 90 90 90 90 90 90 90 90 > 90 90 90 90 90 90 90 90 90 90 90 90 90 90 55 31 c0 89 e5 8b 55 08<8b> > 52 24 40 85 d2 75 f8 c9 c3 8d b4 26 00 00 00 00 8d bc 27 00 > > > >>EIP; c0198448<= I can't repeat it here. Are you able to narrow it down to a specific sysfs file? The .config might help. - 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/
Error building ndiswrapper-1.0rc1 against 2.6.12-rc1-mm2 sources
Hi, Was this change intentional or accidental? I have successfully built ndiswrapper-1.0rc1 with the other recent kernel trees. /usr/src/ndiswrapper-1.0rc1/driver/wrapper.c: In function `wrapper_init': /usr/src/ndiswrapper-1.0rc1/driver/wrapper.c:1485: warning: passing arg 4 of `call_usermodehelper' makes pointer from integer without a cast /usr/src/ndiswrapper-1.0rc1/driver/wrapper.c:1485: error: too few arguments to function `call_usermodehelper' make[3]: *** [/usr/src/ndiswrapper-1.0rc1/driver/wrapper.o] Error 1 - 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 running "ls -l /sys/class/i2c-adapter/*"-- 2.6.12-rc1-mm2
[EMAIL PROTECTED]:/sys/class/i2c-adapter# ls * -l [EMAIL PROTECTED]:/sys# cat */*/*/* ksymoops 2.4.9 on i686 2.6.12-rc1-mm2. Options used -o /lib/modules/2.6.12-rc1-mm2 (specified) -m /boot/System.map-2.6.12-rc1-mm2 (specified) Unable to handle kernel paging request at virtual address 24fc1024 c0198448 *pde = Oops: [#1] CPU:0 EIP:0060:[]Not tainted VLI Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00210206 (2.6.12-rc1-mm2) eax: 0001 ebx: c039f820 ecx: 0001 edx: 24fc1000 esi: e75b6cc4 edi: f7c015e4 ebp: e7b93e94 esp: e7b93e94 ds: 007b es: 007b ss: 0068 Stack: e7b93eb8 c0198644 f7c01694 f7c015e4 e7b93eb8 c039f820 e75b6cc4 f7c015e4 e7b93edc c0198790 f7c01694 f7c015e4 e712a000 f7c01694 e712a000 fff4 e7b93f10 e7b93ef8 c019884f e75b6cc4 e712a000 ffea e75b6cc4 Call Trace: [] show_stack+0x7f/0xa0 [] show_registers+0x15a/0x1c0 [] die+0xfc/0x190 [] do_page_fault+0x31b/0x670 [] error_code+0x4f/0x54 [] sysfs_get_target_path+0x14/0x80 [] sysfs_getlink+0xe0/0x150 [] sysfs_follow_link+0x4f/0x60 [] generic_readlink+0x2f/0x90 [] sys_readlink+0x86/0x90 [] syscall_call+0x7/0xb Code: 42 70 e8 a4 fc 19 00 e9 f3 fe ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 55 31 c0 89 e5 8b 55 08<8b> 52 24 40 85 d2 75 f8 c9 c3 8d b4 26 00 00 00 00 8d bc 27 00 >>EIP; c0198448<= >>ebx; c039f820 >>edx; 24fc1000 >>esi; e75b6cc4 >>edi; f7c015e4 >>ebp; e7b93e94 >>esp; e7b93e94 Trace; c010410f Trace; c01042aa Trace; c01044ac Trace; c011450b Trace; c0103cf3 Trace; c0198644 Trace; c0198790 Trace; c019884f Trace; c016b46f Trace; c01635b6 Trace; c0103249 This architecture has variable length instructions, decoding before eip is unreliable, take these instructions with a pinch of salt. Code; c019841d <.text.lock.dir+d7/fa> <_EIP>: Code; c019841d <.text.lock.dir+d7/fa> 0: 42inc%edx Code; c019841e <.text.lock.dir+d8/fa> 1: 70 e8 jo ffeb <_EIP+0xffeb> Code; c0198420 <.text.lock.dir+da/fa> 3: a4movsb %ds:(%esi),%es:(%edi) Code; c0198421 <.text.lock.dir+db/fa> 4: fccld Code; c0198422 <.text.lock.dir+dc/fa> 5: 19 00 sbb%eax,(%eax) Code; c0198424 <.text.lock.dir+de/fa> 7: e9 f3 fe ff ffjmpfeff <_EIP+0xfeff> Code; c0198429 <.text.lock.dir+e3/fa> c: 90nop Code; c019842a <.text.lock.dir+e4/fa> d: 90nop Code; c019842b <.text.lock.dir+e5/fa> e: 90nop Code; c019842c <.text.lock.dir+e6/fa> f: 90nop Code; c019842d <.text.lock.dir+e7/fa> 10: 90nop Code; c019842e <.text.lock.dir+e8/fa> 11: 90nop Code; c019842f <.text.lock.dir+e9/fa> 12: 90nop Code; c0198430 <.text.lock.dir+ea/fa> 13: 90nop Code; c0198431 <.text.lock.dir+eb/fa> 14: 90nop Code; c0198432 <.text.lock.dir+ec/fa> 15: 90nop Code; c0198433 <.text.lock.dir+ed/fa> 16: 90nop Code; c0198434 <.text.lock.dir+ee/fa> 17: 90nop Code; c0198435 <.text.lock.dir+ef/fa> 18: 90nop Code; c0198436 <.text.lock.dir+f0/fa> 19: 90nop Code; c0198437 <.text.lock.dir+f1/fa> 1a: 90nop Code; c0198438 <.text.lock.dir+f2/fa> 1b: 90nop Code; c0198439 <.text.lock.dir+f3/fa> 1c: 90nop Code; c019843a <.text.lock.dir+f4/fa> 1d: 90nop Code; c019843b <.text.lock.dir+f5/fa> 1e: 90nop Code; c019843c <.text.lock.dir+f6/fa> 1f: 90nop Code; c019843d <.text.lock.dir+f7/fa> 20: 90nop Code; c019843e <.text.lock.dir+f/60> Trace; c01681de <__link_path_walk+8ce/ec0> Trace; c016885f Trace; c0168c45 Trace; c01693ef Trace; c015823c Trace; c01586e8 Trace; c0103249 This architecture has variable length instructions, decoding before eip is unreliable, take these instructions with a pinch of salt. Code; c019841d <.text.lock.dir+d7/fa> <_EIP>: Code; c019841d <.text.lock.dir+d7/fa> 0: 42inc%edx Code; c019841e <.text.lock.dir+d8/fa> 1: 70 e8 jo ffeb <_EIP+0xffeb> Code; c0198420 <.text.lock.dir+da/fa> 3: a4
Re: 2.6.12-rc1-mm2
On Thursday 24 March 2005 23:21, Brice Goglin wrote: > Andrew Morton a écrit : > > Stefano Rivoir <[EMAIL PROTECTED]> wrote: > >>>--- linux-mm/include/linux/agp_backend.h.old > >>>+++ linux-mm/include/linux/agp_backend.h > >>>+extern struct agp_bridge_data * (*agp_find_bridge)(struct pci_dev *); > >>Right, that fixed it for me. > > > > There were contradictory patches in flight and I stuck the latest drm > > tree into rc1-mm2 at the last minute, alas. You should revert > > agp-make-some-code-static.patch. > > > > But I assume that fixing the compile warnings does not fix the oopses > > which Stefano and Brice are seeing? > > My patch does fix both the compile warnings and my oops on my Radeon > laptop. It also allows my machine to boot. Alexey ... drm_agp_init+0x30/0x8e drm_fill_in_dev+0xe7/0x195 drm_get_dev+0x4a/0xba kobject_get+0xf/0x13 do_initcalls+0x54/0xb0 init+0x0/0x100 init+0x0/0x100 kernel_thread_helper+0x0/0x0b kernel_thread_helper+0x5/0x0b ... <0>Kernel panic - not syncing: Attempted to kill init! - 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.6.12-rc1-mm2
On Thu, 24 Mar 2005, Andrew Morton wrote: > Laurent Riffard <[EMAIL PROTECTED]> wrote: > > > > hello, > > > > Same kinds of problem here. It depends on the removed module. I mean: > > "rmmod loop" or "rmmod pcspkr" works. But "rmmod snd_ens1371" or "rmmod > > ohci1394" hangs. > > > > Sysrq-T when rmmoding snd_ens1371 : > It looks like we're getting stuck in the wait_for_completion() in the new > klist_remove(). D'oh! It's getting hung while waiting to remove the current node from the list (which it can't remove because it's being used). The patch below should fix it. Pat = drivers/base/dd.c 1.3 vs edited = --- 1.3/drivers/base/dd.c 2005-03-21 12:25:04 -08:00 +++ edited/drivers/base/dd.c2005-03-24 16:55:21 -08:00 @@ -177,7 +177,7 @@ sysfs_remove_link(>kobj, kobject_name(>kobj)); sysfs_remove_link(>kobj, "driver"); - klist_remove(>knode_driver); + klist_del(>knode_driver); down(>sem); device_detach_shutdown(dev); - 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.6.12-rc1-mm2
Hi, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.6.12-rc1-mm2/ - Added David Miller's networking tree to the -mm lineup as bk-net.patch. - Added Herbert Xu's crypto development tree to the -mm lineup as bk-cryptodev.patch. -mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually they are pulled 3-4 hours before the release of the -mm kernel. Usually it is possible to determine the latest cset from each tree by looking at the first couple of lines of the relevant patch in the broken-out/ directory. Although sometimes it isn't there if I had to massage the diff. - There may be an x86_64 problem here, although it works for me. If it fails early in boot, try reverting x86_64-separate-amd-cmp-detection-from-hyper-threading.patch - There's some work here on the recent USB PM resume bugs. If you had problems there, please test and be sure to cc linux-usb-devel@lists.sourceforge.net in any reports. - Some fixes for the recent DRM problems. - Big DVB update - md updates - nfs4 server updates - Lots more fixes - Lots more bugs. Fails to compile for me: CC [M] fs/nfs/dir.o CC [M] fs/nfs/inode.o CC [M] fs/nfs/nfs4proc.o fs/nfs/nfs4proc.c:2976: error: static declaration of 'nfs4_file_inode_operations' follows non-static declaration fs/nfs/nfs4_fs.h:179: error: previous declaration of 'nfs4_file_inode_operations' was here make[2]: *** [fs/nfs/nfs4proc.o] Error 1 make[1]: *** [fs/nfs] Error 2 make: *** [fs] Error 2 I needed to remove this line: extern struct inode_operations nfs4_file_inode_operations; from fs/nfs/nfs4_fs.h. Patch attached. Reuben --- fs/nfs/nfs4_fs.h2005-03-25 11:40:51.0 +1200 +++ fs/nfs/nfs4_fs.h2005-03-25 11:44:28.0 +1200 @@ -176,7 +176,6 @@ extern struct dentry_operations nfs4_dentry_operations; extern struct inode_operations nfs4_dir_inode_operations; -extern struct inode_operations nfs4_file_inode_operations; /* inode.c */ extern ssize_t nfs4_getxattr(struct dentry *, const char *, void *, size_t);
Re: 2.6.12-rc1-mm2
Laurent Riffard <[EMAIL PROTECTED]> wrote: > > hello, > > Same kinds of problem here. It depends on the removed module. I mean: > "rmmod loop" or "rmmod pcspkr" works. But "rmmod snd_ens1371" or "rmmod > ohci1394" hangs. > > Sysrq-T when rmmoding snd_ens1371 : > > rmmod D C92EBE8C 0 8231 8159 (NOTLB) > c92ebea0 0082 0003 c92ebe8c 5685fc00 000f4253 cd624530 > cd624658 cff60874 cff60844 c92ebebc c92ebef0 c02618c7 > cd624530 > c0113137 0282 cd248c20 cd248c07 0001 > cd624530 > Call Trace: >[wait_for_completion+124/193] wait_for_completion+0x7c/0xc1 >[] wait_for_completion+0x7c/0xc1 >[device_release_driver+52/116] device_release_driver+0x34/0x74 >[] device_release_driver+0x34/0x74 >[__remove_driver+8/12] __remove_driver+0x8/0xc >[] __remove_driver+0x8/0xc >[driver_for_each_device+50/87] driver_for_each_device+0x32/0x57 >[] driver_for_each_device+0x32/0x57 >[driver_detach+17/19] driver_detach+0x11/0x13 >[] driver_detach+0x11/0x13 >[bus_remove_driver+76/130] bus_remove_driver+0x4c/0x82 >[] bus_remove_driver+0x4c/0x82 >[driver_unregister+14/23] driver_unregister+0xe/0x17 >[] driver_unregister+0xe/0x17 >[pci_unregister_driver+14/23] pci_unregister_driver+0xe/0x17 >[] pci_unregister_driver+0xe/0x17 >[sys_delete_module+322/379] sys_delete_module+0x142/0x17b >[] sys_delete_module+0x142/0x17b It looks like we're getting stuck in the wait_for_completion() in the new klist_remove(). - 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.6.12-rc1-mm2
Le 24.03.2005 23:31, Rafael J. Wysocki a écrit : Hi, On Thursday, 24 of March 2005 21:17, Andrew Morton wrote: Lee Revell <[EMAIL PROTECTED]> wrote: On Thu, 2005-03-24 at 04:41 -0800, Andrew Morton wrote: -mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually they are pulled 3-4 hours before the release of the -mm kernel. Andrew, Do you notify the subsystem maintainers ahead of time so that critical fixes can be pushed to BK? Occasionally I'll go out and ping people, but almost always the subsystem guys know what the development cycle is, and they appropriately decide which code should go in, and when. I am thinking of the recent ALSA example, where the emu10k1 driver was b0rked in 2.6.12-mm1, but the fix had been in ALSA CVS for a week. We've been discussing how to get ALSA CVS into ALSA bk more promptly. BTW, on 2.6.12-rc1-mm2 I can't rmmod the snd_intel8x0 module (the process goes into the D state immediately), which did not happen before. This is 100% reproducible, on two different AMD64-based boxes, with different sound chips. Greets, Rafael hello, Same kinds of problem here. It depends on the removed module. I mean: "rmmod loop" or "rmmod pcspkr" works. But "rmmod snd_ens1371" or "rmmod ohci1394" hangs. Sysrq-T when rmmoding snd_ens1371 : rmmod D C92EBE8C 0 8231 8159 (NOTLB) c92ebea0 0082 0003 c92ebe8c 5685fc00 000f4253 cd624530 cd624658 cff60874 cff60844 c92ebebc c92ebef0 c02618c7 cd624530 c0113137 0282 cd248c20 cd248c07 0001 cd624530 Call Trace: [wait_for_completion+124/193] wait_for_completion+0x7c/0xc1 [] wait_for_completion+0x7c/0xc1 [device_release_driver+52/116] device_release_driver+0x34/0x74 [] device_release_driver+0x34/0x74 [__remove_driver+8/12] __remove_driver+0x8/0xc [] __remove_driver+0x8/0xc [driver_for_each_device+50/87] driver_for_each_device+0x32/0x57 [] driver_for_each_device+0x32/0x57 [driver_detach+17/19] driver_detach+0x11/0x13 [] driver_detach+0x11/0x13 [bus_remove_driver+76/130] bus_remove_driver+0x4c/0x82 [] bus_remove_driver+0x4c/0x82 [driver_unregister+14/23] driver_unregister+0xe/0x17 [] driver_unregister+0xe/0x17 [pci_unregister_driver+14/23] pci_unregister_driver+0xe/0x17 [] pci_unregister_driver+0xe/0x17 [sys_delete_module+322/379] sys_delete_module+0x142/0x17b [] sys_delete_module+0x142/0x17b Sysrq-T when rmmoding ohci1394 : rmmod D 0001 0 12353 10401 (NOTLB) cefa9ea0 0082 c012f3d9 0001 0001e848 e88bbbc0 000f426d cb613570 cb613698 cff60074 cff60044 cefa9ebc cefa9ef0 c02618d7 cb613570 c0113137 0286 cd379e60 cd379e47 0001 cb613570 Call Trace: [wait_for_completion+124/193] wait_for_completion+0x7c/0xc1 [] wait_for_completion+0x7c/0xc1 [device_release_driver+52/116] device_release_driver+0x34/0x74 [] device_release_driver+0x34/0x74 [__remove_driver+8/12] __remove_driver+0x8/0xc [] __remove_driver+0x8/0xc [driver_for_each_device+50/87] driver_for_each_device+0x32/0x57 [] driver_for_each_device+0x32/0x57 [driver_detach+17/19] driver_detach+0x11/0x13 [] driver_detach+0x11/0x13 [bus_remove_driver+76/130] bus_remove_driver+0x4c/0x82 [] bus_remove_driver+0x4c/0x82 [driver_unregister+14/23] driver_unregister+0xe/0x17 [] driver_unregister+0xe/0x17 [pci_unregister_driver+14/23] pci_unregister_driver+0xe/0x17 [] pci_unregister_driver+0xe/0x17 [sys_delete_module+322/379] sys_delete_module+0x142/0x17b [] sys_delete_module+0x142/0x17b [sysenter_past_esp+84/117] sysenter_past_esp+0x54/0x75 .config attached ~~ laurent # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-rc1-mm2 # Thu Mar 24 23:38:31 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_CLEAR_PAGES=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set CONFIG_EMBEDDED=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CO
Re: 2.6.12-rc1-mm2
On Thursday, 24 of March 2005 23:31, Rafael J. Wysocki wrote: > Hi, > > On Thursday, 24 of March 2005 21:17, Andrew Morton wrote: > > Lee Revell <[EMAIL PROTECTED]> wrote: > > > > > > On Thu, 2005-03-24 at 04:41 -0800, Andrew Morton wrote: > > > > -mm kernels now aggregate Linus's tree and 34 subsystem trees. > > > > Usually > > > > they are pulled 3-4 hours before the release of the -mm kernel. > > > > > > > > > > Andrew, > > > > > > Do you notify the subsystem maintainers ahead of time so that critical > > > fixes can be pushed to BK? > > > > Occasionally I'll go out and ping people, but almost always the subsystem > > guys know what the development cycle is, and they appropriately decide > > which code should go in, and when. > > > > > I am thinking of the recent ALSA example, where the emu10k1 driver was > > > b0rked in 2.6.12-mm1, but the fix had been in ALSA CVS for a week. > > > > > > > We've been discussing how to get ALSA CVS into ALSA bk more promptly. > > BTW, on 2.6.12-rc1-mm2 I can't rmmod the snd_intel8x0 module (the process > goes into the D state immediately), which did not happen before. This is 100% > reproducible, on two different AMD64-based boxes, with different sound chips. Er, sorry for the noise on alsa-devel. Actually, rmmod doesn't work for me at all on x86-64 (on two different boxes). Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - 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.6.12-rc1-mm2
Hi, On Thursday, 24 of March 2005 21:17, Andrew Morton wrote: > Lee Revell <[EMAIL PROTECTED]> wrote: > > > > On Thu, 2005-03-24 at 04:41 -0800, Andrew Morton wrote: > > > -mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually > > > they are pulled 3-4 hours before the release of the -mm kernel. > > > > > > > Andrew, > > > > Do you notify the subsystem maintainers ahead of time so that critical > > fixes can be pushed to BK? > > Occasionally I'll go out and ping people, but almost always the subsystem > guys know what the development cycle is, and they appropriately decide > which code should go in, and when. > > > I am thinking of the recent ALSA example, where the emu10k1 driver was > > b0rked in 2.6.12-mm1, but the fix had been in ALSA CVS for a week. > > > > We've been discussing how to get ALSA CVS into ALSA bk more promptly. BTW, on 2.6.12-rc1-mm2 I can't rmmod the snd_intel8x0 module (the process goes into the D state immediately), which did not happen before. This is 100% reproducible, on two different AMD64-based boxes, with different sound chips. Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - 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/
[PATCH 2.6.12-rc1-mm2] relayfs: properly handle oversized events
This patch fails writes larger than the sub-buffer size and prints a
warning and stack trace when it happens. I chose this over BUG_ON()
or silently failing since while it could probably be considered a bug
for an application to let this happen, it's not fatal and the user
would probably want to know (and change buffer sizes).
Andrew, please apply.
Thanks,
Tom
Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.12-rc1-mm2/fs/relayfs/relay.c
linux-2.6.12-rc1-mm2-cur/fs/relayfs/relay.c
--- linux-2.6.12-rc1-mm2/fs/relayfs/relay.c 2005-03-20 22:26:47.0
-0600
+++ linux-2.6.12-rc1-mm2-cur/fs/relayfs/relay.c 2005-03-20 23:32:50.0
-0600
@@ -378,7 +378,10 @@ unsigned relay_switch_subbuf(struct rcha
int new, old, produced = atomic_read(>subbufs_produced);
unsigned padding;
- if (atomic_read(>unfull)) {
+ if (unlikely(length > buf->chan->subbuf_size))
+ goto toobig;
+
+ if (unlikely(atomic_read(>unfull))) {
atomic_set(>unfull, 0);
new = produced % buf->chan->n_subbufs;
old = (produced - 1) % buf->chan->n_subbufs;
@@ -410,7 +413,15 @@ unsigned relay_switch_subbuf(struct rcha
new = (produced + 1) % buf->chan->n_subbufs;
do_switch(buf, new, old);
+ if (unlikely(length + buf->offset > buf->chan->subbuf_size))
+ goto toobig;
+
return length;
+
+toobig:
+ printk(KERN_WARNING "relayfs: event too large (%u)\n", length);
+ WARN_ON(1);
+ return 0;
}
/**
-
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.6.12-rc1-mm2 (patch to fix build error In function `zft_init')
Greg KH <[EMAIL PROTECTED]> wrote: > > > I glanced at the code, and this little patch fixes the problem: > > Ick, sorry, that was my fault. I've applied this patch to my trees, > thanks. > > Hm, I wonder how I missed this, I did do a 'make allmodconfig' build to > try to catch this kind of stuff... allmodconfig doesn't catch BROKEN_ON_SMP code. I've been caught out by that a few times. - 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.6.12-rc1-mm2 (patch to fix build error In function `zft_init')
On Thu, Mar 24, 2005 at 08:55:13AM -0700, Steven Cole wrote: > Steven Cole wrote: > >I'm getting the following build error with 2.6.12-rc1-mm2: > > > > CC init/version.o > > LD init/built-in.o > > LD .tmp_vmlinux1 > >drivers/built-in.o(.init.text+0x4323): In function `zft_init': > >: undefined reference to `class_device_creat' > >make: *** [.tmp_vmlinux1] Error 1 > > > > I glanced at the code, and this little patch fixes the problem: Ick, sorry, that was my fault. I've applied this patch to my trees, thanks. Hm, I wonder how I missed this, I did do a 'make allmodconfig' build to try to catch this kind of stuff... thanks, greg k-h - 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.6.12-rc1-mm2 - ppc32 build fails.
On Thu, 24 Mar 2005 12:28:08 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > cliff white <[EMAIL PROTECTED]> wrote: > > > > > > Error message: > > > > CC arch/ppc/kernel/setup.o > > In file included from arch/ppc/kernel/setup.c:43: > > include/asm/ppc_sys.h:29:2: #error "need definition of ppc_sys_devices" > > In file included from arch/ppc/kernel/setup.c:43: > > include/asm/ppc_sys.h:61: warning: parameter has incomplete type > > include/asm/ppc_sys.h:64: warning: parameter has incomplete type > > This should fix it. Fixes that problem, now i hit the kernel OOPS at drm initalization. Thought i saw a patch somewhere already for that... cliffw > > > From: Kumar Gala <[EMAIL PROTECTED]> > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > --- > > 25-akpm/arch/ppc/kernel/setup.c |5 - > 1 files changed, 4 insertions(+), 1 deletion(-) > > diff -puN > arch/ppc/kernel/setup.c~ppc32-report-chipset-version-in-common-proc-cpuinfo-handling-fix > arch/ppc/kernel/setup.c > --- > 25/arch/ppc/kernel/setup.c~ppc32-report-chipset-version-in-common-proc-cpuinfo-handling-fix >2005-03-24 12:27:39.0 -0800 > +++ 25-akpm/arch/ppc/kernel/setup.c 2005-03-24 12:27:39.0 -0800 > @@ -40,7 +40,10 @@ > #include > #include > #include > + > +#if defined(CONFIG_85xx) || defined(CONFIG_83xx) > #include > +#endif > > #if defined CONFIG_KGDB > #include > @@ -247,7 +250,7 @@ int show_cpuinfo(struct seq_file *m, voi > seq_printf(m, "bogomips\t: %lu.%02lu\n", > lpj / (50/HZ), (lpj / (5000/HZ)) % 100); > > -#if defined (CONFIG_85xx) || defined (CONFIG_83xx) > +#if defined(CONFIG_85xx) || defined(CONFIG_83xx) > if (cur_ppc_sys_spec->ppc_sys_name) > seq_printf(m, "chipset\t\t: %s\n", > cur_ppc_sys_spec->ppc_sys_name); > _ > > - > 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/ > -- "Ive always gone through periods where I bolt upright at four in the morning; now at least theres a reason." -Michael Feldman - 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.6.12-rc1-mm2 - ppc32 build fails.
cliff white <[EMAIL PROTECTED]> wrote: > > > Error message: > > CC arch/ppc/kernel/setup.o > In file included from arch/ppc/kernel/setup.c:43: > include/asm/ppc_sys.h:29:2: #error "need definition of ppc_sys_devices" > In file included from arch/ppc/kernel/setup.c:43: > include/asm/ppc_sys.h:61: warning: parameter has incomplete type > include/asm/ppc_sys.h:64: warning: parameter has incomplete type This should fix it. From: Kumar Gala <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- 25-akpm/arch/ppc/kernel/setup.c |5 - 1 files changed, 4 insertions(+), 1 deletion(-) diff -puN arch/ppc/kernel/setup.c~ppc32-report-chipset-version-in-common-proc-cpuinfo-handling-fix arch/ppc/kernel/setup.c --- 25/arch/ppc/kernel/setup.c~ppc32-report-chipset-version-in-common-proc-cpuinfo-handling-fix 2005-03-24 12:27:39.0 -0800 +++ 25-akpm/arch/ppc/kernel/setup.c 2005-03-24 12:27:39.0 -0800 @@ -40,7 +40,10 @@ #include #include #include + +#if defined(CONFIG_85xx) || defined(CONFIG_83xx) #include +#endif #if defined CONFIG_KGDB #include @@ -247,7 +250,7 @@ int show_cpuinfo(struct seq_file *m, voi seq_printf(m, "bogomips\t: %lu.%02lu\n", lpj / (50/HZ), (lpj / (5000/HZ)) % 100); -#if defined (CONFIG_85xx) || defined (CONFIG_83xx) +#if defined(CONFIG_85xx) || defined(CONFIG_83xx) if (cur_ppc_sys_spec->ppc_sys_name) seq_printf(m, "chipset\t\t: %s\n", cur_ppc_sys_spec->ppc_sys_name); _ - 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.6.12-rc1-mm2
Andrew Morton a écrit : Stefano Rivoir <[EMAIL PROTECTED]> wrote: --- linux-mm/include/linux/agp_backend.h.old2005-03-24 16:17:25.0 +0100 +++ linux-mm/include/linux/agp_backend.h2005-03-24 16:10:25.0 +0100 @@ -100,6 +100,7 @@ extern int agp_bind_memory(struct agp_memory *, off_t); extern int agp_unbind_memory(struct agp_memory *); extern void agp_enable(struct agp_bridge_data *, u32); +extern struct agp_bridge_data * (*agp_find_bridge)(struct pci_dev *); extern struct agp_bridge_data *agp_backend_acquire(struct pci_dev *); extern void agp_backend_release(struct agp_bridge_data *); Right, that fixed it for me. There were contradictory patches in flight and I stuck the latest drm tree into rc1-mm2 at the last minute, alas. You should revert agp-make-some-code-static.patch. But I assume that fixing the compile warnings does not fix the oopses which Stefano and Brice are seeing? My patch does fix both the compile warnings and my oops on my Radeon laptop. Brice - 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.6.12-rc1-mm2
Lee Revell <[EMAIL PROTECTED]> wrote: > > On Thu, 2005-03-24 at 04:41 -0800, Andrew Morton wrote: > > -mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually > > they are pulled 3-4 hours before the release of the -mm kernel. > > > > Andrew, > > Do you notify the subsystem maintainers ahead of time so that critical > fixes can be pushed to BK? Occasionally I'll go out and ping people, but almost always the subsystem guys know what the development cycle is, and they appropriately decide which code should go in, and when. > I am thinking of the recent ALSA example, where the emu10k1 driver was > b0rked in 2.6.12-mm1, but the fix had been in ALSA CVS for a week. > We've been discussing how to get ALSA CVS into ALSA bk more promptly. - 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.6.12-rc1-mm2
Stefano Rivoir <[EMAIL PROTECTED]> wrote: > > Alle 16:18, giovedì 24 marzo 2005, Brice Goglin ha scritto: > > Stefano Rivoir a écrit : > > > Alle 13:41, giovedì 24 marzo 2005, Andrew Morton ha scritto: > > >>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/ > > >>2. 6.12-rc1-mm2/ > > >> > > >> > > >>- Some fixes for the recent DRM problems. > > > > > > Hi Andrew, > > > > > > While I was OK with DRM up to 2.6.12-rc1-mm1, now I get this at startup, > > > and Xorg fails to enable DRI (attached, lspci and .config): > > > --- linux-mm/include/linux/agp_backend.h.old2005-03-24 > > 16:17:25.0 +0100 > > +++ linux-mm/include/linux/agp_backend.h2005-03-24 > > 16:10:25.0 +0100 > > @@ -100,6 +100,7 @@ > > extern int agp_bind_memory(struct agp_memory *, off_t); > > extern int agp_unbind_memory(struct agp_memory *); > > extern void agp_enable(struct agp_bridge_data *, u32); > > +extern struct agp_bridge_data * (*agp_find_bridge)(struct pci_dev *); > > extern struct agp_bridge_data *agp_backend_acquire(struct pci_dev *); > > extern void agp_backend_release(struct agp_bridge_data *); > > Right, that fixed it for me. > There were contradictory patches in flight and I stuck the latest drm tree into rc1-mm2 at the last minute, alas. You should revert agp-make-some-code-static.patch. But I assume that fixing the compile warnings does not fix the oopses which Stefano and Brice are seeing? - 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/
2.6.12-rc1-mm2 - ppc32 build fails.
Error message: CC arch/ppc/kernel/setup.o In file included from arch/ppc/kernel/setup.c:43: include/asm/ppc_sys.h:29:2: #error "need definition of ppc_sys_devices" In file included from arch/ppc/kernel/setup.c:43: include/asm/ppc_sys.h:61: warning: parameter has incomplete type include/asm/ppc_sys.h:64: warning: parameter has incomplete type make[1]: *** [arch/ppc/kernel/setup.o] Error 1 make: *** [arch/ppc/kernel] Error 2 This fails for my config, and also for a defconfig build. We're thinking the patch "[PATCH] ppc32: PowerQUICC II Pro subarch support" ( http://seclists.org/lists/linux-kernel/2005/Mar/1661.html ) may have hosed up the config, but haven't got that patch to cleanly revert yet. cliffw -- "Ive always gone through periods where I bolt upright at four in the morning; now at least theres a reason." -Michael Feldman - 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/
[PATCH 2.6.12-rc1-mm2] x86_64: fix vsyscall.c syntax error
Compiling 2.6.12-rc1-mm2 on x86_64 with gcc-4.0 fails with:
arch/x86_64/kernel/vsyscall.c:193: error: syntax error before
'vsyscall_sysctl_change'
Fix: repair the syntax error
Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm2/arch/x86_64/kernel/vsyscall.c.~1~ 2005-03-24
16:33:50.0 +0100
+++ linux-2.6.12-rc1-mm2/arch/x86_64/kernel/vsyscall.c 2005-03-24
19:31:40.0 +0100
@@ -190,7 +190,7 @@ static ctl_table kernel_table2[] = {
{ .ctl_name = 99, .procname = "vsyscall64",
.data = _vsyscall, .maxlen = sizeof(int), .mode = 0644,
.strategy = vsyscall_sysctl_nostrat,
- .proc_handler vsyscall_sysctl_change },
+ .proc_handler = vsyscall_sysctl_change },
{ 0, }
};
-
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.6.12-rc1-mm2
On Thu, 2005-03-24 at 04:41 -0800, Andrew Morton wrote: > -mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually > they are pulled 3-4 hours before the release of the -mm kernel. > Andrew, Do you notify the subsystem maintainers ahead of time so that critical fixes can be pushed to BK? I am thinking of the recent ALSA example, where the emu10k1 driver was b0rked in 2.6.12-mm1, but the fix had been in ALSA CVS for a week. Lee - 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/
[PATCH 2.6.12-rc1-mm2] update VR41xx RTC support
This patch updates NEC VR4100 series RTC support. Yoichi Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]> diff -urN -X dontdiff rc1-mm2-orig/arch/mips/vr41xx/common/Makefile rc1-mm2/arch/mips/vr41xx/common/Makefile --- rc1-mm2-orig/arch/mips/vr41xx/common/Makefile Fri Mar 25 00:42:00 2005 +++ rc1-mm2/arch/mips/vr41xx/common/MakefileFri Mar 25 00:53:32 2005 @@ -2,7 +2,7 @@ # Makefile for common code of the NEC VR4100 series. # -obj-y += bcu.o cmu.o giu.o icu.o init.o int-handler.o ksyms.o pmu.o rtc.o +obj-y += bcu.o cmu.o giu.o icu.o init.o int-handler.o pmu.o obj-$(CONFIG_VRC4173) += vrc4173.o EXTRA_AFLAGS := $(CFLAGS) diff -urN -X dontdiff rc1-mm2-orig/arch/mips/vr41xx/common/ksyms.c rc1-mm2/arch/mips/vr41xx/common/ksyms.c --- rc1-mm2-orig/arch/mips/vr41xx/common/ksyms.cFri Mar 25 00:42:00 2005 +++ rc1-mm2/arch/mips/vr41xx/common/ksyms.c Thu Jan 1 09:00:00 1970 @@ -1,30 +0,0 @@ -/* - * ksyms.c, Export NEC VR4100 series specific functions needed for loadable modules. - * - * Copyright (C) 2003 Yoichi Yuasa <[EMAIL PROTECTED]> - * Copyright (C) 2005 Ralf Baechle ([EMAIL PROTECTED]) - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - */ -#include - -#include - -EXPORT_SYMBOL(vr41xx_set_rtclong1_cycle); -EXPORT_SYMBOL(vr41xx_read_rtclong1_counter); -EXPORT_SYMBOL(vr41xx_set_rtclong2_cycle); -EXPORT_SYMBOL(vr41xx_read_rtclong2_counter); -EXPORT_SYMBOL(vr41xx_set_tclock_cycle); -EXPORT_SYMBOL(vr41xx_read_tclock_counter); diff -urN -X dontdiff rc1-mm2-orig/arch/mips/vr41xx/common/rtc.c rc1-mm2/arch/mips/vr41xx/common/rtc.c --- rc1-mm2-orig/arch/mips/vr41xx/common/rtc.c Wed Mar 2 16:38:34 2005 +++ rc1-mm2/arch/mips/vr41xx/common/rtc.c Thu Jan 1 09:00:00 1970 @@ -1,321 +0,0 @@ -/* - * rtc.c, RTC(has only timer function) routines for NEC VR4100 series. - * - * Copyright (C) 2003-2004 Yoichi Yuasa <[EMAIL PROTECTED]> - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - */ -#include -#include -#include -#include - -#include -#include -#include - -static uint32_t rtc1_base; -static uint32_t rtc2_base; - -static uint64_t previous_elapsedtime; -static unsigned int remainder_per_sec; -static unsigned int cycles_per_sec; -static unsigned int cycles_per_jiffy; -static unsigned long epoch_time; - -#define CYCLES_PER_JIFFY (CLOCK_TICK_RATE / HZ) -#define REMAINDER_PER_SEC (CLOCK_TICK_RATE - (CYCLES_PER_JIFFY * HZ)) -#define CYCLES_PER_100USEC ((CLOCK_TICK_RATE + (1 / 2)) / 1) - -#define ETIMELREG_TYPE1KSEG1ADDR(0x0bc0) -#define TCLKLREG_TYPE1 KSEG1ADDR(0x0b0001c0) - -#define ETIMELREG_TYPE2KSEG1ADDR(0x0f000100) -#define TCLKLREG_TYPE2 KSEG1ADDR(0x0f000120) - -/* RTC 1 registers */ -#define ETIMELREG 0x00 -#define ETIMEMREG 0x02 -#define ETIMEHREG 0x04 -/* RFU */ -#define ECMPLREG 0x08 -#define ECMPMREG 0x0a -#define ECMPHREG 0x0c -/* RFU */ -#define RTCL1LREG 0x10 -#define RTCL1HREG 0x12 -#define RTCL1CNTLREG 0x14 -#define RTCL1CNTHREG 0x16 -#define RTCL2LREG 0x18 -#define RTCL2HREG 0x1a -#define RTCL2CNTLREG 0x1c -#define RTCL2CNTHREG 0x1e - -/* RTC 2 registers */ -#define TCLKLREG 0x00 -#define TCLKHREG 0x02 -#define TCLKCNTLREG0x04 -#define TCLKCNTHREG0x06 -/* RFU */ -#define RTCINTREG 0x1e - #define TCLOCK_INT0x08 - #define
Re: 2.6.12-rc1-mm2 (patch to fix build error In function `zft_init')
Steven Cole wrote:
I'm getting the following build error with 2.6.12-rc1-mm2:
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
drivers/built-in.o(.init.text+0x4323): In function `zft_init':
: undefined reference to `class_device_creat'
make: *** [.tmp_vmlinux1] Error 1
I glanced at the code, and this little patch fixes the problem:
Steven
Signed-off by: Steven Cole <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm2/drivers/char/ftape/zftape/zftape-init.c.orig
2005-03-24 08:43:30.0 -0700
+++ linux-2.6.12-rc1-mm2/drivers/char/ftape/zftape/zftape-init.c
2005-03-24 08:43:56.0 -0700
@@ -331,7 +331,7 @@
zft_class = class_create(THIS_MODULE, "zft");
for (i = 0; i < 4; i++) {
- class_device_creat(zft_class, MKDEV(QIC117_TAPE_MAJOR, i),
NULL, "qft%i", i);
+ class_device_create(zft_class, MKDEV(QIC117_TAPE_MAJOR, i),
NULL, "qft%i", i);
devfs_mk_cdev(MKDEV(QIC117_TAPE_MAJOR, i),
S_IFCHR | S_IRUSR | S_IWUSR,
"qft%i", i);
Re: 2.6.12-rc1-mm2
Alle 16:18, giovedì 24 marzo 2005, Brice Goglin ha scritto: > Stefano Rivoir a écrit : > > Alle 13:41, giovedì 24 marzo 2005, Andrew Morton ha scritto: > >>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/ > >>2. 6.12-rc1-mm2/ > >> > >> > >>- Some fixes for the recent DRM problems. > > > > Hi Andrew, > > > > While I was OK with DRM up to 2.6.12-rc1-mm1, now I get this at startup, > > and Xorg fails to enable DRI (attached, lspci and .config): > --- linux-mm/include/linux/agp_backend.h.old2005-03-24 > 16:17:25.0 +0100 > +++ linux-mm/include/linux/agp_backend.h2005-03-24 > 16:10:25.0 +0100 > @@ -100,6 +100,7 @@ > extern int agp_bind_memory(struct agp_memory *, off_t); > extern int agp_unbind_memory(struct agp_memory *); > extern void agp_enable(struct agp_bridge_data *, u32); > +extern struct agp_bridge_data * (*agp_find_bridge)(struct pci_dev *); > extern struct agp_bridge_data *agp_backend_acquire(struct pci_dev *); > extern void agp_backend_release(struct agp_bridge_data *); Right, that fixed it for me. Thank you. -- Stefano Rivoir - 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.6.12-rc1-mm2
Stefano Rivoir a écrit : Alle 13:41, giovedì 24 marzo 2005, Andrew Morton ha scritto: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2. 6.12-rc1-mm2/ - Some fixes for the recent DRM problems. Hi Andrew, While I was OK with DRM up to 2.6.12-rc1-mm1, now I get this at startup, and Xorg fails to enable DRI (attached, lspci and .config): Same problem on my Radeon M6 LY here. This seems to be due to agp_find_bridge not being exported anymore in agp_backend.h. Dave might have forgotten it when reworking my patch. Patch attached. Brice Signoff-by: Brice Goglin <[EMAIL PROTECTED]> --- linux-mm/include/linux/agp_backend.h.old2005-03-24 16:17:25.0 +0100 +++ linux-mm/include/linux/agp_backend.h2005-03-24 16:10:25.0 +0100 @@ -100,6 +100,7 @@ extern int agp_bind_memory(struct agp_memory *, off_t); extern int agp_unbind_memory(struct agp_memory *); extern void agp_enable(struct agp_bridge_data *, u32); +extern struct agp_bridge_data * (*agp_find_bridge)(struct pci_dev *); extern struct agp_bridge_data *agp_backend_acquire(struct pci_dev *); extern void agp_backend_release(struct agp_bridge_data *); - 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.6.12-rc1-mm2
Stefano Rivoir wrote: > Alle 13:41, giovedì 24 marzo 2005, Andrew Morton ha scritto: > >>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2. >>6.12-rc1-mm2/ > > >>- Some fixes for the recent DRM problems. > > > Hi Andrew, > > While I was OK with DRM up to 2.6.12-rc1-mm1, now I get this at startup, and > Xorg fails to enable DRI (attached, lspci and .config): > > Unable to handle kernel paging request at virtual address 72ff64d7 > printing eip: > e087eb44 > *pde = > Oops: 0002 [#1] > PREEMPT > Modules linked in: radeon drm sd_mod scsi_mod lp hotkey fan container button > ide_cd 8250_pnp parport_pc parport floppy pcspkr sk98lin yenta_socket > rsrc_nonstatic pcmcia_core ehci_hcd usbhid ohci_hcd snd_intel8x0m 8250_pci > 8250 serial_core ohci1394 ieee1394 sis_agp agpgart vfat fat video thermal > processor ac battery snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss > snd_pcm snd_timer snd soundcore snd_page_alloc skge evdev > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00013286 (2.6.12-rc1-mm2) > EIP is at agp_find_bridge+0x0/0xc77f [agpgart] > eax: dff1d000 ebx: de228400 ecx: edx: 00d0 > esi: dd86 edi: de228450 ebp: e1a4bd90 esp: dd811f48 > ds: 007b es: 007b ss: 0068 > Process modprobe (pid: 4698, threadinfo=dd81 task=dfca3030) > Stack: e1a085fb dd86 e1a4c240 e1a06ed0 dd86 e1a4c240 dff1d000 >dd86 e1a071ce e1a4c240 c01abfaf e1a4bd90 dff1d000 e1a4c240 0310 >e1a03adf 0310 fffc e1a4e180 dd81 dd81 > Call Trace: > [] drm_agp_init+0x3b/0xb0 [drm] > [] drm_fill_in_dev+0xf0/0x1b0 [drm] > [] drm_get_dev+0x4e/0xc0 [drm] > [] kobject_get+0xf/0x20 > [] drm_init+0x6f/0xb0 [drm] > [] sys_init_module+0x139/0x1e0 > [] sysenter_past_esp+0x54/0x75 > Code: 6e 66 69 67 5f 62 79 74 65 00 61 67 70 5f 70 75 74 5f 62 72 69 64 67 65 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 65 00 a7 87 e0 dc 94 > cd de dc 94 cd de 00 00 00 00 00 00 00 00 00 I get a similar Oops at boot; I noticed this warning during compilation: drivers/char/drm/drm_agpsupport.c: In function `drm_agp_init': drivers/char/drm/drm_agpsupport.c:391: warning: implicit declaration of function `agp_find_bridge' drivers/char/drm/drm_agpsupport.c:391: warning: assignment makes pointer from integer without a cast I dont know what header to include/modify to make it go away. DRM and AGP are compiled into the kernel (no modules). -- Manuel Lauss - 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.6.12-rc1-mm2 (build error In function `zft_init')
I'm getting the following build error with 2.6.12-rc1-mm2: CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 drivers/built-in.o(.init.text+0x4323): In function `zft_init': : undefined reference to `class_device_creat' make: *** [.tmp_vmlinux1] Error 1 2.6.12-rc1-mm1 built and is running just fine. I used the -rc1-mm1 .config, did make oldconfig, make bzImage. Here is the .config: [EMAIL PROTECTED] linux-2.6.12-rc1-mm2]$ grep ^CONFIG .config CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_CLEAR_PAGES=y CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="-GX110" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KALLSYMS=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 CONFIG_BASE_SMALL=0 CONFIG_X86_PC=y CONFIG_MPENTIUMIII=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_P4THERMAL=y CONFIG_MICROCODE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_EDD=y CONFIG_NOHIGHMEM=y CONFIG_MTRR=y CONFIG_PHYSICAL_START=0x10 CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_LEGACY_PROC=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=32000 CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_AOE_PARTITIONS=16 CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_BLK_DEV_IDECD=y CONFIG_IDE_GENERIC=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_PIIX=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_IDEDMA_AUTO=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_NET_KEY=y CONFIG_INET=y CONFIG_IP_TCPDIAG=y CONFIG_XFRM=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_MII=y CONFIG_NET_VENDOR_3COM=y CONFIG_VORTEX=y CONFIG_INPUT=y CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y CONFIG_SERIO_LIBPS2=y CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_FTAPE=y CONFIG_ZFTAPE=y CONFIG_ZFT_DFLT_BLK_SZ=10240 CONFIG_ZFT_COMPRESSOR=y CONFIG_FT_NR_BUFFERS=3 CONFIG_FT_PROC_FS=y CONFIG_FT_NORMAL_DEBUG=y CONFIG_FT_STD_FDC=y CONFIG_FT_FDC_THR=8 CONFIG_FT_FDC_MAX_RATE=2000 CONFIG_FT_ALPHA_CLOCK=0 CONFIG_AGP=y CONFIG_AGP_INTEL=y CONFIG_VIDEO_DEV=y CONFIG_VIDEO_SELECT=y CONFIG_VGA_CONSOLE=y CONFIG_DUMMY_CONSOLE=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT3_FS=y CONFIG_JBD=y CONFIG_FS_MBCACHE=y CONFIG_REISER4_FS=y CONFIG_REISERFS_FS=y CONFIG_DNOTIFY=y CONFIG_ISO9660_FS=y CONFIG_FAT_FS=y CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" CONFIG_NTFS_FS=y CONFIG_NTFS_RW=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y CONFIG_DEVFS_FS=y CONFIG_TMPFS=y CONFIG_RAMFS=y CONFIG_PARTITION_ADVANCED=y CONFIG_MSDOS_PARTITION=y CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_CODEPAGE_850=y CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_UTF8=y CONFIG_PRINTK_TIME=y CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_DEBUG_BUGVERBOSE=y CONFIG_FRAME_POINTER=y CONFIG_EARLY_PRINTK=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y CONFIG_SECURITY=y CONFIG_SECURITY_NETWORK=y CONFIG_SECURITY_CAPABILITIES=y CONFIG_CRC_CCITT=y CONFIG_CRC32=y CONFIG_LIBCRC32C=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_PC=y Steven - 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.6.12-rc1-mm2
Alle 13:41, giovedì 24 marzo 2005, Andrew Morton ha scritto: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2. >6.12-rc1-mm2/ > - Some fixes for the recent DRM problems. Hi Andrew, While I was OK with DRM up to 2.6.12-rc1-mm1, now I get this at startup, and Xorg fails to enable DRI (attached, lspci and .config): Unable to handle kernel paging request at virtual address 72ff64d7 printing eip: e087eb44 *pde = Oops: 0002 [#1] PREEMPT Modules linked in: radeon drm sd_mod scsi_mod lp hotkey fan container button ide_cd 8250_pnp parport_pc parport floppy pcspkr sk98lin yenta_socket rsrc_nonstatic pcmcia_core ehci_hcd usbhid ohci_hcd snd_intel8x0m 8250_pci 8250 serial_core ohci1394 ieee1394 sis_agp agpgart vfat fat video thermal processor ac battery snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc skge evdev CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00013286 (2.6.12-rc1-mm2) EIP is at agp_find_bridge+0x0/0xc77f [agpgart] eax: dff1d000 ebx: de228400 ecx: edx: 00d0 esi: dd86 edi: de228450 ebp: e1a4bd90 esp: dd811f48 ds: 007b es: 007b ss: 0068 Process modprobe (pid: 4698, threadinfo=dd81 task=dfca3030) Stack: e1a085fb dd86 e1a4c240 e1a06ed0 dd86 e1a4c240 dff1d000 dd86 e1a071ce e1a4c240 c01abfaf e1a4bd90 dff1d000 e1a4c240 0310 e1a03adf 0310 fffc e1a4e180 dd81 dd81 Call Trace: [] drm_agp_init+0x3b/0xb0 [drm] [] drm_fill_in_dev+0xf0/0x1b0 [drm] [] drm_get_dev+0x4e/0xc0 [drm] [] kobject_get+0xf/0x20 [] drm_init+0x6f/0xb0 [drm] [] sys_init_module+0x139/0x1e0 [] sysenter_past_esp+0x54/0x75 Code: 6e 66 69 67 5f 62 79 74 65 00 61 67 70 5f 70 75 74 5f 62 72 69 64 67 65 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 65 00 a7 87 e0 dc 94 cd de dc 94 cd de 00 00 00 00 00 00 00 00 00 -- Stefano Rivoir # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-rc1-mm2 # Thu Mar 24 14:26:36 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_CLEAR_PAGES=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # CONFIG_CLEAN_COMPILE is not set CONFIG_BROKEN=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_HPET_TIMER is not set # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y # CONFIG_X86_UP_APIC is not set CONFIG_X86_TSC=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_HAVE_DEC_LOCK
Re: 2.6.12-rc1-mm2
Alle 13:41, giovedì 24 marzo 2005, Andrew Morton ha scritto: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2. 6.12-rc1-mm2/ - Some fixes for the recent DRM problems. Hi Andrew, While I was OK with DRM up to 2.6.12-rc1-mm1, now I get this at startup, and Xorg fails to enable DRI (attached, lspci and .config): Unable to handle kernel paging request at virtual address 72ff64d7 printing eip: e087eb44 *pde = Oops: 0002 [#1] PREEMPT Modules linked in: radeon drm sd_mod scsi_mod lp hotkey fan container button ide_cd 8250_pnp parport_pc parport floppy pcspkr sk98lin yenta_socket rsrc_nonstatic pcmcia_core ehci_hcd usbhid ohci_hcd snd_intel8x0m 8250_pci 8250 serial_core ohci1394 ieee1394 sis_agp agpgart vfat fat video thermal processor ac battery snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc skge evdev CPU:0 EIP:0060:[e087eb44]Not tainted VLI EFLAGS: 00013286 (2.6.12-rc1-mm2) EIP is at agp_find_bridge+0x0/0xc77f [agpgart] eax: dff1d000 ebx: de228400 ecx: edx: 00d0 esi: dd86 edi: de228450 ebp: e1a4bd90 esp: dd811f48 ds: 007b es: 007b ss: 0068 Process modprobe (pid: 4698, threadinfo=dd81 task=dfca3030) Stack: e1a085fb dd86 e1a4c240 e1a06ed0 dd86 e1a4c240 dff1d000 dd86 e1a071ce e1a4c240 c01abfaf e1a4bd90 dff1d000 e1a4c240 0310 e1a03adf 0310 fffc e1a4e180 dd81 dd81 Call Trace: [e1a085fb] drm_agp_init+0x3b/0xb0 [drm] [e1a06ed0] drm_fill_in_dev+0xf0/0x1b0 [drm] [e1a071ce] drm_get_dev+0x4e/0xc0 [drm] [c01abfaf] kobject_get+0xf/0x20 [e1a03adf] drm_init+0x6f/0xb0 [drm] [c0130589] sys_init_module+0x139/0x1e0 [c0102fdb] sysenter_past_esp+0x54/0x75 Code: 6e 66 69 67 5f 62 79 74 65 00 61 67 70 5f 70 75 74 5f 62 72 69 64 67 65 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 65 00 c0 a7 87 e0 dc 94 cd de dc 94 cd de 00 00 00 00 00 00 00 00 00 -- Stefano Rivoir # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-rc1-mm2 # Thu Mar 24 14:26:36 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_CLEAR_PAGES=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # CONFIG_CLEAN_COMPILE is not set CONFIG_BROKEN=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_HPET_TIMER is not set # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y # CONFIG_X86_UP_APIC is not set CONFIG_X86_TSC=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI
Re: 2.6.12-rc1-mm2 (build error In function `zft_init')
I'm getting the following build error with 2.6.12-rc1-mm2: CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 drivers/built-in.o(.init.text+0x4323): In function `zft_init': : undefined reference to `class_device_creat' make: *** [.tmp_vmlinux1] Error 1 2.6.12-rc1-mm1 built and is running just fine. I used the -rc1-mm1 .config, did make oldconfig, make bzImage. Here is the .config: [EMAIL PROTECTED] linux-2.6.12-rc1-mm2]$ grep ^CONFIG .config CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_CLEAR_PAGES=y CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION=-GX110 CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KALLSYMS=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 CONFIG_BASE_SMALL=0 CONFIG_X86_PC=y CONFIG_MPENTIUMIII=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_P4THERMAL=y CONFIG_MICROCODE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_EDD=y CONFIG_NOHIGHMEM=y CONFIG_MTRR=y CONFIG_PHYSICAL_START=0x10 CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_LEGACY_PROC=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=32000 CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_AOE_PARTITIONS=16 CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_BLK_DEV_IDECD=y CONFIG_IDE_GENERIC=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_PIIX=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_IDEDMA_AUTO=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_NET_KEY=y CONFIG_INET=y CONFIG_IP_TCPDIAG=y CONFIG_XFRM=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_MII=y CONFIG_NET_VENDOR_3COM=y CONFIG_VORTEX=y CONFIG_INPUT=y CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y CONFIG_SERIO_LIBPS2=y CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_FTAPE=y CONFIG_ZFTAPE=y CONFIG_ZFT_DFLT_BLK_SZ=10240 CONFIG_ZFT_COMPRESSOR=y CONFIG_FT_NR_BUFFERS=3 CONFIG_FT_PROC_FS=y CONFIG_FT_NORMAL_DEBUG=y CONFIG_FT_STD_FDC=y CONFIG_FT_FDC_THR=8 CONFIG_FT_FDC_MAX_RATE=2000 CONFIG_FT_ALPHA_CLOCK=0 CONFIG_AGP=y CONFIG_AGP_INTEL=y CONFIG_VIDEO_DEV=y CONFIG_VIDEO_SELECT=y CONFIG_VGA_CONSOLE=y CONFIG_DUMMY_CONSOLE=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT3_FS=y CONFIG_JBD=y CONFIG_FS_MBCACHE=y CONFIG_REISER4_FS=y CONFIG_REISERFS_FS=y CONFIG_DNOTIFY=y CONFIG_ISO9660_FS=y CONFIG_FAT_FS=y CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET=iso8859-1 CONFIG_NTFS_FS=y CONFIG_NTFS_RW=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y CONFIG_DEVFS_FS=y CONFIG_TMPFS=y CONFIG_RAMFS=y CONFIG_PARTITION_ADVANCED=y CONFIG_MSDOS_PARTITION=y CONFIG_NLS=y CONFIG_NLS_DEFAULT=iso8859-1 CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_CODEPAGE_850=y CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_UTF8=y CONFIG_PRINTK_TIME=y CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_DEBUG_BUGVERBOSE=y CONFIG_FRAME_POINTER=y CONFIG_EARLY_PRINTK=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y CONFIG_SECURITY=y CONFIG_SECURITY_NETWORK=y CONFIG_SECURITY_CAPABILITIES=y CONFIG_CRC_CCITT=y CONFIG_CRC32=y CONFIG_LIBCRC32C=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_PC=y Steven - 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.6.12-rc1-mm2
Stefano Rivoir wrote: Alle 13:41, giovedì 24 marzo 2005, Andrew Morton ha scritto: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2. 6.12-rc1-mm2/ - Some fixes for the recent DRM problems. Hi Andrew, While I was OK with DRM up to 2.6.12-rc1-mm1, now I get this at startup, and Xorg fails to enable DRI (attached, lspci and .config): Unable to handle kernel paging request at virtual address 72ff64d7 printing eip: e087eb44 *pde = Oops: 0002 [#1] PREEMPT Modules linked in: radeon drm sd_mod scsi_mod lp hotkey fan container button ide_cd 8250_pnp parport_pc parport floppy pcspkr sk98lin yenta_socket rsrc_nonstatic pcmcia_core ehci_hcd usbhid ohci_hcd snd_intel8x0m 8250_pci 8250 serial_core ohci1394 ieee1394 sis_agp agpgart vfat fat video thermal processor ac battery snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc skge evdev CPU:0 EIP:0060:[e087eb44]Not tainted VLI EFLAGS: 00013286 (2.6.12-rc1-mm2) EIP is at agp_find_bridge+0x0/0xc77f [agpgart] eax: dff1d000 ebx: de228400 ecx: edx: 00d0 esi: dd86 edi: de228450 ebp: e1a4bd90 esp: dd811f48 ds: 007b es: 007b ss: 0068 Process modprobe (pid: 4698, threadinfo=dd81 task=dfca3030) Stack: e1a085fb dd86 e1a4c240 e1a06ed0 dd86 e1a4c240 dff1d000 dd86 e1a071ce e1a4c240 c01abfaf e1a4bd90 dff1d000 e1a4c240 0310 e1a03adf 0310 fffc e1a4e180 dd81 dd81 Call Trace: [e1a085fb] drm_agp_init+0x3b/0xb0 [drm] [e1a06ed0] drm_fill_in_dev+0xf0/0x1b0 [drm] [e1a071ce] drm_get_dev+0x4e/0xc0 [drm] [c01abfaf] kobject_get+0xf/0x20 [e1a03adf] drm_init+0x6f/0xb0 [drm] [c0130589] sys_init_module+0x139/0x1e0 [c0102fdb] sysenter_past_esp+0x54/0x75 Code: 6e 66 69 67 5f 62 79 74 65 00 61 67 70 5f 70 75 74 5f 62 72 69 64 67 65 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 65 00 c0 a7 87 e0 dc 94 cd de dc 94 cd de 00 00 00 00 00 00 00 00 00 I get a similar Oops at boot; I noticed this warning during compilation: drivers/char/drm/drm_agpsupport.c: In function `drm_agp_init': drivers/char/drm/drm_agpsupport.c:391: warning: implicit declaration of function `agp_find_bridge' drivers/char/drm/drm_agpsupport.c:391: warning: assignment makes pointer from integer without a cast I dont know what header to include/modify to make it go away. DRM and AGP are compiled into the kernel (no modules). -- Manuel Lauss - 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.6.12-rc1-mm2
Stefano Rivoir a écrit : Alle 13:41, giovedì 24 marzo 2005, Andrew Morton ha scritto: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2. 6.12-rc1-mm2/ - Some fixes for the recent DRM problems. Hi Andrew, While I was OK with DRM up to 2.6.12-rc1-mm1, now I get this at startup, and Xorg fails to enable DRI (attached, lspci and .config): Same problem on my Radeon M6 LY here. This seems to be due to agp_find_bridge not being exported anymore in agp_backend.h. Dave might have forgotten it when reworking my patch. Patch attached. Brice Signoff-by: Brice Goglin [EMAIL PROTECTED] --- linux-mm/include/linux/agp_backend.h.old2005-03-24 16:17:25.0 +0100 +++ linux-mm/include/linux/agp_backend.h2005-03-24 16:10:25.0 +0100 @@ -100,6 +100,7 @@ extern int agp_bind_memory(struct agp_memory *, off_t); extern int agp_unbind_memory(struct agp_memory *); extern void agp_enable(struct agp_bridge_data *, u32); +extern struct agp_bridge_data * (*agp_find_bridge)(struct pci_dev *); extern struct agp_bridge_data *agp_backend_acquire(struct pci_dev *); extern void agp_backend_release(struct agp_bridge_data *); - 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.6.12-rc1-mm2
Alle 16:18, giovedì 24 marzo 2005, Brice Goglin ha scritto: Stefano Rivoir a écrit : Alle 13:41, giovedì 24 marzo 2005, Andrew Morton ha scritto: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/ 2. 6.12-rc1-mm2/ - Some fixes for the recent DRM problems. Hi Andrew, While I was OK with DRM up to 2.6.12-rc1-mm1, now I get this at startup, and Xorg fails to enable DRI (attached, lspci and .config): --- linux-mm/include/linux/agp_backend.h.old2005-03-24 16:17:25.0 +0100 +++ linux-mm/include/linux/agp_backend.h2005-03-24 16:10:25.0 +0100 @@ -100,6 +100,7 @@ extern int agp_bind_memory(struct agp_memory *, off_t); extern int agp_unbind_memory(struct agp_memory *); extern void agp_enable(struct agp_bridge_data *, u32); +extern struct agp_bridge_data * (*agp_find_bridge)(struct pci_dev *); extern struct agp_bridge_data *agp_backend_acquire(struct pci_dev *); extern void agp_backend_release(struct agp_bridge_data *); Right, that fixed it for me. Thank you. -- Stefano Rivoir - 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.6.12-rc1-mm2 (patch to fix build error In function `zft_init')
Steven Cole wrote:
I'm getting the following build error with 2.6.12-rc1-mm2:
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
drivers/built-in.o(.init.text+0x4323): In function `zft_init':
: undefined reference to `class_device_creat'
make: *** [.tmp_vmlinux1] Error 1
I glanced at the code, and this little patch fixes the problem:
Steven
Signed-off by: Steven Cole [EMAIL PROTECTED]
--- linux-2.6.12-rc1-mm2/drivers/char/ftape/zftape/zftape-init.c.orig
2005-03-24 08:43:30.0 -0700
+++ linux-2.6.12-rc1-mm2/drivers/char/ftape/zftape/zftape-init.c
2005-03-24 08:43:56.0 -0700
@@ -331,7 +331,7 @@
zft_class = class_create(THIS_MODULE, zft);
for (i = 0; i 4; i++) {
- class_device_creat(zft_class, MKDEV(QIC117_TAPE_MAJOR, i),
NULL, qft%i, i);
+ class_device_create(zft_class, MKDEV(QIC117_TAPE_MAJOR, i),
NULL, qft%i, i);
devfs_mk_cdev(MKDEV(QIC117_TAPE_MAJOR, i),
S_IFCHR | S_IRUSR | S_IWUSR,
qft%i, i);
[PATCH 2.6.12-rc1-mm2] update VR41xx RTC support
This patch updates NEC VR4100 series RTC support. Yoichi Signed-off-by: Yoichi Yuasa [EMAIL PROTECTED] diff -urN -X dontdiff rc1-mm2-orig/arch/mips/vr41xx/common/Makefile rc1-mm2/arch/mips/vr41xx/common/Makefile --- rc1-mm2-orig/arch/mips/vr41xx/common/Makefile Fri Mar 25 00:42:00 2005 +++ rc1-mm2/arch/mips/vr41xx/common/MakefileFri Mar 25 00:53:32 2005 @@ -2,7 +2,7 @@ # Makefile for common code of the NEC VR4100 series. # -obj-y += bcu.o cmu.o giu.o icu.o init.o int-handler.o ksyms.o pmu.o rtc.o +obj-y += bcu.o cmu.o giu.o icu.o init.o int-handler.o pmu.o obj-$(CONFIG_VRC4173) += vrc4173.o EXTRA_AFLAGS := $(CFLAGS) diff -urN -X dontdiff rc1-mm2-orig/arch/mips/vr41xx/common/ksyms.c rc1-mm2/arch/mips/vr41xx/common/ksyms.c --- rc1-mm2-orig/arch/mips/vr41xx/common/ksyms.cFri Mar 25 00:42:00 2005 +++ rc1-mm2/arch/mips/vr41xx/common/ksyms.c Thu Jan 1 09:00:00 1970 @@ -1,30 +0,0 @@ -/* - * ksyms.c, Export NEC VR4100 series specific functions needed for loadable modules. - * - * Copyright (C) 2003 Yoichi Yuasa [EMAIL PROTECTED] - * Copyright (C) 2005 Ralf Baechle ([EMAIL PROTECTED]) - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - */ -#include linux/module.h - -#include asm/vr41xx/vr41xx.h - -EXPORT_SYMBOL(vr41xx_set_rtclong1_cycle); -EXPORT_SYMBOL(vr41xx_read_rtclong1_counter); -EXPORT_SYMBOL(vr41xx_set_rtclong2_cycle); -EXPORT_SYMBOL(vr41xx_read_rtclong2_counter); -EXPORT_SYMBOL(vr41xx_set_tclock_cycle); -EXPORT_SYMBOL(vr41xx_read_tclock_counter); diff -urN -X dontdiff rc1-mm2-orig/arch/mips/vr41xx/common/rtc.c rc1-mm2/arch/mips/vr41xx/common/rtc.c --- rc1-mm2-orig/arch/mips/vr41xx/common/rtc.c Wed Mar 2 16:38:34 2005 +++ rc1-mm2/arch/mips/vr41xx/common/rtc.c Thu Jan 1 09:00:00 1970 @@ -1,321 +0,0 @@ -/* - * rtc.c, RTC(has only timer function) routines for NEC VR4100 series. - * - * Copyright (C) 2003-2004 Yoichi Yuasa [EMAIL PROTECTED] - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - */ -#include linux/init.h -#include linux/irq.h -#include linux/smp.h -#include linux/types.h - -#include asm/io.h -#include asm/time.h -#include asm/vr41xx/vr41xx.h - -static uint32_t rtc1_base; -static uint32_t rtc2_base; - -static uint64_t previous_elapsedtime; -static unsigned int remainder_per_sec; -static unsigned int cycles_per_sec; -static unsigned int cycles_per_jiffy; -static unsigned long epoch_time; - -#define CYCLES_PER_JIFFY (CLOCK_TICK_RATE / HZ) -#define REMAINDER_PER_SEC (CLOCK_TICK_RATE - (CYCLES_PER_JIFFY * HZ)) -#define CYCLES_PER_100USEC ((CLOCK_TICK_RATE + (1 / 2)) / 1) - -#define ETIMELREG_TYPE1KSEG1ADDR(0x0bc0) -#define TCLKLREG_TYPE1 KSEG1ADDR(0x0b0001c0) - -#define ETIMELREG_TYPE2KSEG1ADDR(0x0f000100) -#define TCLKLREG_TYPE2 KSEG1ADDR(0x0f000120) - -/* RTC 1 registers */ -#define ETIMELREG 0x00 -#define ETIMEMREG 0x02 -#define ETIMEHREG 0x04 -/* RFU */ -#define ECMPLREG 0x08 -#define ECMPMREG 0x0a -#define ECMPHREG 0x0c -/* RFU */ -#define RTCL1LREG 0x10 -#define RTCL1HREG 0x12 -#define RTCL1CNTLREG 0x14 -#define RTCL1CNTHREG 0x16 -#define RTCL2LREG 0x18 -#define RTCL2HREG 0x1a -#define RTCL2CNTLREG 0x1c -#define RTCL2CNTHREG 0x1e - -/* RTC 2 registers */ -#define TCLKLREG 0x00 -#define TCLKHREG 0x02 -#define TCLKCNTLREG0x04 -#define TCLKCNTHREG
Re: 2.6.12-rc1-mm2
On Thu, 2005-03-24 at 04:41 -0800, Andrew Morton wrote: -mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually they are pulled 3-4 hours before the release of the -mm kernel. Andrew, Do you notify the subsystem maintainers ahead of time so that critical fixes can be pushed to BK? I am thinking of the recent ALSA example, where the emu10k1 driver was b0rked in 2.6.12-mm1, but the fix had been in ALSA CVS for a week. Lee - 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/
[PATCH 2.6.12-rc1-mm2] x86_64: fix vsyscall.c syntax error
Compiling 2.6.12-rc1-mm2 on x86_64 with gcc-4.0 fails with:
arch/x86_64/kernel/vsyscall.c:193: error: syntax error before
'vsyscall_sysctl_change'
Fix: repair the syntax error
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
--- linux-2.6.12-rc1-mm2/arch/x86_64/kernel/vsyscall.c.~1~ 2005-03-24
16:33:50.0 +0100
+++ linux-2.6.12-rc1-mm2/arch/x86_64/kernel/vsyscall.c 2005-03-24
19:31:40.0 +0100
@@ -190,7 +190,7 @@ static ctl_table kernel_table2[] = {
{ .ctl_name = 99, .procname = vsyscall64,
.data = sysctl_vsyscall, .maxlen = sizeof(int), .mode = 0644,
.strategy = vsyscall_sysctl_nostrat,
- .proc_handler vsyscall_sysctl_change },
+ .proc_handler = vsyscall_sysctl_change },
{ 0, }
};
-
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/
2.6.12-rc1-mm2 - ppc32 build fails.
Error message: CC arch/ppc/kernel/setup.o In file included from arch/ppc/kernel/setup.c:43: include/asm/ppc_sys.h:29:2: #error need definition of ppc_sys_devices In file included from arch/ppc/kernel/setup.c:43: include/asm/ppc_sys.h:61: warning: parameter has incomplete type include/asm/ppc_sys.h:64: warning: parameter has incomplete type make[1]: *** [arch/ppc/kernel/setup.o] Error 1 make: *** [arch/ppc/kernel] Error 2 This fails for my config, and also for a defconfig build. We're thinking the patch [PATCH] ppc32: PowerQUICC II Pro subarch support ( http://seclists.org/lists/linux-kernel/2005/Mar/1661.html ) may have hosed up the config, but haven't got that patch to cleanly revert yet. cliffw -- Ive always gone through periods where I bolt upright at four in the morning; now at least theres a reason. -Michael Feldman - 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.6.12-rc1-mm2
Stefano Rivoir [EMAIL PROTECTED] wrote: Alle 16:18, giovedì 24 marzo 2005, Brice Goglin ha scritto: Stefano Rivoir a écrit : Alle 13:41, giovedì 24 marzo 2005, Andrew Morton ha scritto: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/ 2. 6.12-rc1-mm2/ - Some fixes for the recent DRM problems. Hi Andrew, While I was OK with DRM up to 2.6.12-rc1-mm1, now I get this at startup, and Xorg fails to enable DRI (attached, lspci and .config): --- linux-mm/include/linux/agp_backend.h.old2005-03-24 16:17:25.0 +0100 +++ linux-mm/include/linux/agp_backend.h2005-03-24 16:10:25.0 +0100 @@ -100,6 +100,7 @@ extern int agp_bind_memory(struct agp_memory *, off_t); extern int agp_unbind_memory(struct agp_memory *); extern void agp_enable(struct agp_bridge_data *, u32); +extern struct agp_bridge_data * (*agp_find_bridge)(struct pci_dev *); extern struct agp_bridge_data *agp_backend_acquire(struct pci_dev *); extern void agp_backend_release(struct agp_bridge_data *); Right, that fixed it for me. There were contradictory patches in flight and I stuck the latest drm tree into rc1-mm2 at the last minute, alas. You should revert agp-make-some-code-static.patch. But I assume that fixing the compile warnings does not fix the oopses which Stefano and Brice are seeing? - 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.6.12-rc1-mm2
Lee Revell [EMAIL PROTECTED] wrote: On Thu, 2005-03-24 at 04:41 -0800, Andrew Morton wrote: -mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually they are pulled 3-4 hours before the release of the -mm kernel. Andrew, Do you notify the subsystem maintainers ahead of time so that critical fixes can be pushed to BK? Occasionally I'll go out and ping people, but almost always the subsystem guys know what the development cycle is, and they appropriately decide which code should go in, and when. I am thinking of the recent ALSA example, where the emu10k1 driver was b0rked in 2.6.12-mm1, but the fix had been in ALSA CVS for a week. We've been discussing how to get ALSA CVS into ALSA bk more promptly. - 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.6.12-rc1-mm2
Andrew Morton a écrit : Stefano Rivoir [EMAIL PROTECTED] wrote: --- linux-mm/include/linux/agp_backend.h.old2005-03-24 16:17:25.0 +0100 +++ linux-mm/include/linux/agp_backend.h2005-03-24 16:10:25.0 +0100 @@ -100,6 +100,7 @@ extern int agp_bind_memory(struct agp_memory *, off_t); extern int agp_unbind_memory(struct agp_memory *); extern void agp_enable(struct agp_bridge_data *, u32); +extern struct agp_bridge_data * (*agp_find_bridge)(struct pci_dev *); extern struct agp_bridge_data *agp_backend_acquire(struct pci_dev *); extern void agp_backend_release(struct agp_bridge_data *); Right, that fixed it for me. There were contradictory patches in flight and I stuck the latest drm tree into rc1-mm2 at the last minute, alas. You should revert agp-make-some-code-static.patch. But I assume that fixing the compile warnings does not fix the oopses which Stefano and Brice are seeing? My patch does fix both the compile warnings and my oops on my Radeon laptop. Brice - 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.6.12-rc1-mm2 - ppc32 build fails.
cliff white [EMAIL PROTECTED] wrote: Error message: CC arch/ppc/kernel/setup.o In file included from arch/ppc/kernel/setup.c:43: include/asm/ppc_sys.h:29:2: #error need definition of ppc_sys_devices In file included from arch/ppc/kernel/setup.c:43: include/asm/ppc_sys.h:61: warning: parameter has incomplete type include/asm/ppc_sys.h:64: warning: parameter has incomplete type This should fix it. From: Kumar Gala [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- 25-akpm/arch/ppc/kernel/setup.c |5 - 1 files changed, 4 insertions(+), 1 deletion(-) diff -puN arch/ppc/kernel/setup.c~ppc32-report-chipset-version-in-common-proc-cpuinfo-handling-fix arch/ppc/kernel/setup.c --- 25/arch/ppc/kernel/setup.c~ppc32-report-chipset-version-in-common-proc-cpuinfo-handling-fix 2005-03-24 12:27:39.0 -0800 +++ 25-akpm/arch/ppc/kernel/setup.c 2005-03-24 12:27:39.0 -0800 @@ -40,7 +40,10 @@ #include asm/nvram.h #include asm/xmon.h #include asm/ocp.h + +#if defined(CONFIG_85xx) || defined(CONFIG_83xx) #include asm/ppc_sys.h +#endif #if defined CONFIG_KGDB #include asm/kgdb.h @@ -247,7 +250,7 @@ int show_cpuinfo(struct seq_file *m, voi seq_printf(m, bogomips\t: %lu.%02lu\n, lpj / (50/HZ), (lpj / (5000/HZ)) % 100); -#if defined (CONFIG_85xx) || defined (CONFIG_83xx) +#if defined(CONFIG_85xx) || defined(CONFIG_83xx) if (cur_ppc_sys_spec-ppc_sys_name) seq_printf(m, chipset\t\t: %s\n, cur_ppc_sys_spec-ppc_sys_name); _ - 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.6.12-rc1-mm2 - ppc32 build fails.
On Thu, 24 Mar 2005 12:28:08 -0800 Andrew Morton [EMAIL PROTECTED] wrote: cliff white [EMAIL PROTECTED] wrote: Error message: CC arch/ppc/kernel/setup.o In file included from arch/ppc/kernel/setup.c:43: include/asm/ppc_sys.h:29:2: #error need definition of ppc_sys_devices In file included from arch/ppc/kernel/setup.c:43: include/asm/ppc_sys.h:61: warning: parameter has incomplete type include/asm/ppc_sys.h:64: warning: parameter has incomplete type This should fix it. Fixes that problem, now i hit the kernel OOPS at drm initalization. Thought i saw a patch somewhere already for that... cliffw From: Kumar Gala [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- 25-akpm/arch/ppc/kernel/setup.c |5 - 1 files changed, 4 insertions(+), 1 deletion(-) diff -puN arch/ppc/kernel/setup.c~ppc32-report-chipset-version-in-common-proc-cpuinfo-handling-fix arch/ppc/kernel/setup.c --- 25/arch/ppc/kernel/setup.c~ppc32-report-chipset-version-in-common-proc-cpuinfo-handling-fix 2005-03-24 12:27:39.0 -0800 +++ 25-akpm/arch/ppc/kernel/setup.c 2005-03-24 12:27:39.0 -0800 @@ -40,7 +40,10 @@ #include asm/nvram.h #include asm/xmon.h #include asm/ocp.h + +#if defined(CONFIG_85xx) || defined(CONFIG_83xx) #include asm/ppc_sys.h +#endif #if defined CONFIG_KGDB #include asm/kgdb.h @@ -247,7 +250,7 @@ int show_cpuinfo(struct seq_file *m, voi seq_printf(m, bogomips\t: %lu.%02lu\n, lpj / (50/HZ), (lpj / (5000/HZ)) % 100); -#if defined (CONFIG_85xx) || defined (CONFIG_83xx) +#if defined(CONFIG_85xx) || defined(CONFIG_83xx) if (cur_ppc_sys_spec-ppc_sys_name) seq_printf(m, chipset\t\t: %s\n, cur_ppc_sys_spec-ppc_sys_name); _ - 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/ -- Ive always gone through periods where I bolt upright at four in the morning; now at least theres a reason. -Michael Feldman - 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.6.12-rc1-mm2 (patch to fix build error In function `zft_init')
On Thu, Mar 24, 2005 at 08:55:13AM -0700, Steven Cole wrote: Steven Cole wrote: I'm getting the following build error with 2.6.12-rc1-mm2: CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 drivers/built-in.o(.init.text+0x4323): In function `zft_init': : undefined reference to `class_device_creat' make: *** [.tmp_vmlinux1] Error 1 I glanced at the code, and this little patch fixes the problem: Ick, sorry, that was my fault. I've applied this patch to my trees, thanks. Hm, I wonder how I missed this, I did do a 'make allmodconfig' build to try to catch this kind of stuff... thanks, greg k-h - 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.6.12-rc1-mm2 (patch to fix build error In function `zft_init')
Greg KH [EMAIL PROTECTED] wrote: I glanced at the code, and this little patch fixes the problem: Ick, sorry, that was my fault. I've applied this patch to my trees, thanks. Hm, I wonder how I missed this, I did do a 'make allmodconfig' build to try to catch this kind of stuff... allmodconfig doesn't catch BROKEN_ON_SMP code. I've been caught out by that a few times. - 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/
[PATCH 2.6.12-rc1-mm2] relayfs: properly handle oversized events
This patch fails writes larger than the sub-buffer size and prints a
warning and stack trace when it happens. I chose this over BUG_ON()
or silently failing since while it could probably be considered a bug
for an application to let this happen, it's not fatal and the user
would probably want to know (and change buffer sizes).
Andrew, please apply.
Thanks,
Tom
Signed-off-by: Tom Zanussi [EMAIL PROTECTED]
diff -urpN -X dontdiff linux-2.6.12-rc1-mm2/fs/relayfs/relay.c
linux-2.6.12-rc1-mm2-cur/fs/relayfs/relay.c
--- linux-2.6.12-rc1-mm2/fs/relayfs/relay.c 2005-03-20 22:26:47.0
-0600
+++ linux-2.6.12-rc1-mm2-cur/fs/relayfs/relay.c 2005-03-20 23:32:50.0
-0600
@@ -378,7 +378,10 @@ unsigned relay_switch_subbuf(struct rcha
int new, old, produced = atomic_read(buf-subbufs_produced);
unsigned padding;
- if (atomic_read(buf-unfull)) {
+ if (unlikely(length buf-chan-subbuf_size))
+ goto toobig;
+
+ if (unlikely(atomic_read(buf-unfull))) {
atomic_set(buf-unfull, 0);
new = produced % buf-chan-n_subbufs;
old = (produced - 1) % buf-chan-n_subbufs;
@@ -410,7 +413,15 @@ unsigned relay_switch_subbuf(struct rcha
new = (produced + 1) % buf-chan-n_subbufs;
do_switch(buf, new, old);
+ if (unlikely(length + buf-offset buf-chan-subbuf_size))
+ goto toobig;
+
return length;
+
+toobig:
+ printk(KERN_WARNING relayfs: event too large (%u)\n, length);
+ WARN_ON(1);
+ return 0;
}
/**
-
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.6.12-rc1-mm2
Hi, On Thursday, 24 of March 2005 21:17, Andrew Morton wrote: Lee Revell [EMAIL PROTECTED] wrote: On Thu, 2005-03-24 at 04:41 -0800, Andrew Morton wrote: -mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually they are pulled 3-4 hours before the release of the -mm kernel. Andrew, Do you notify the subsystem maintainers ahead of time so that critical fixes can be pushed to BK? Occasionally I'll go out and ping people, but almost always the subsystem guys know what the development cycle is, and they appropriately decide which code should go in, and when. I am thinking of the recent ALSA example, where the emu10k1 driver was b0rked in 2.6.12-mm1, but the fix had been in ALSA CVS for a week. We've been discussing how to get ALSA CVS into ALSA bk more promptly. BTW, on 2.6.12-rc1-mm2 I can't rmmod the snd_intel8x0 module (the process goes into the D state immediately), which did not happen before. This is 100% reproducible, on two different AMD64-based boxes, with different sound chips. Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll Alice's Adventures in Wonderland - 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.6.12-rc1-mm2
On Thursday, 24 of March 2005 23:31, Rafael J. Wysocki wrote: Hi, On Thursday, 24 of March 2005 21:17, Andrew Morton wrote: Lee Revell [EMAIL PROTECTED] wrote: On Thu, 2005-03-24 at 04:41 -0800, Andrew Morton wrote: -mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually they are pulled 3-4 hours before the release of the -mm kernel. Andrew, Do you notify the subsystem maintainers ahead of time so that critical fixes can be pushed to BK? Occasionally I'll go out and ping people, but almost always the subsystem guys know what the development cycle is, and they appropriately decide which code should go in, and when. I am thinking of the recent ALSA example, where the emu10k1 driver was b0rked in 2.6.12-mm1, but the fix had been in ALSA CVS for a week. We've been discussing how to get ALSA CVS into ALSA bk more promptly. BTW, on 2.6.12-rc1-mm2 I can't rmmod the snd_intel8x0 module (the process goes into the D state immediately), which did not happen before. This is 100% reproducible, on two different AMD64-based boxes, with different sound chips. Er, sorry for the noise on alsa-devel. Actually, rmmod doesn't work for me at all on x86-64 (on two different boxes). Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll Alice's Adventures in Wonderland - 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.6.12-rc1-mm2
Le 24.03.2005 23:31, Rafael J. Wysocki a crit : Hi, On Thursday, 24 of March 2005 21:17, Andrew Morton wrote: Lee Revell [EMAIL PROTECTED] wrote: On Thu, 2005-03-24 at 04:41 -0800, Andrew Morton wrote: -mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually they are pulled 3-4 hours before the release of the -mm kernel. Andrew, Do you notify the subsystem maintainers ahead of time so that critical fixes can be pushed to BK? Occasionally I'll go out and ping people, but almost always the subsystem guys know what the development cycle is, and they appropriately decide which code should go in, and when. I am thinking of the recent ALSA example, where the emu10k1 driver was b0rked in 2.6.12-mm1, but the fix had been in ALSA CVS for a week. We've been discussing how to get ALSA CVS into ALSA bk more promptly. BTW, on 2.6.12-rc1-mm2 I can't rmmod the snd_intel8x0 module (the process goes into the D state immediately), which did not happen before. This is 100% reproducible, on two different AMD64-based boxes, with different sound chips. Greets, Rafael hello, Same kinds of problem here. It depends on the removed module. I mean: rmmod loop or rmmod pcspkr works. But rmmod snd_ens1371 or rmmod ohci1394 hangs. Sysrq-T when rmmoding snd_ens1371 : rmmod D C92EBE8C 0 8231 8159 (NOTLB) c92ebea0 0082 0003 c92ebe8c 5685fc00 000f4253 cd624530 cd624658 cff60874 cff60844 c92ebebc c92ebef0 c02618c7 cd624530 c0113137 0282 cd248c20 cd248c07 0001 cd624530 Call Trace: [wait_for_completion+124/193] wait_for_completion+0x7c/0xc1 [c02618c7] wait_for_completion+0x7c/0xc1 [device_release_driver+52/116] device_release_driver+0x34/0x74 [c01f0ae3] device_release_driver+0x34/0x74 [__remove_driver+8/12] __remove_driver+0x8/0xc [c01f0b2b] __remove_driver+0x8/0xc [driver_for_each_device+50/87] driver_for_each_device+0x32/0x57 [c01f0bd8] driver_for_each_device+0x32/0x57 [driver_detach+17/19] driver_detach+0x11/0x13 [c01f0b40] driver_detach+0x11/0x13 [bus_remove_driver+76/130] bus_remove_driver+0x4c/0x82 [c01f05eb] bus_remove_driver+0x4c/0x82 [driver_unregister+14/23] driver_unregister+0xe/0x17 [c01f0cb2] driver_unregister+0xe/0x17 [pci_unregister_driver+14/23] pci_unregister_driver+0xe/0x17 [c019b242] pci_unregister_driver+0xe/0x17 [sys_delete_module+322/379] sys_delete_module+0x142/0x17b [c0128356] sys_delete_module+0x142/0x17b Sysrq-T when rmmoding ohci1394 : rmmod D 0001 0 12353 10401 (NOTLB) cefa9ea0 0082 c012f3d9 0001 0001e848 e88bbbc0 000f426d cb613570 cb613698 cff60074 cff60044 cefa9ebc cefa9ef0 c02618d7 cb613570 c0113137 0286 cd379e60 cd379e47 0001 cb613570 Call Trace: [wait_for_completion+124/193] wait_for_completion+0x7c/0xc1 [c02618d7] wait_for_completion+0x7c/0xc1 [device_release_driver+52/116] device_release_driver+0x34/0x74 [c01f0aeb] device_release_driver+0x34/0x74 [__remove_driver+8/12] __remove_driver+0x8/0xc [c01f0b33] __remove_driver+0x8/0xc [driver_for_each_device+50/87] driver_for_each_device+0x32/0x57 [c01f0be0] driver_for_each_device+0x32/0x57 [driver_detach+17/19] driver_detach+0x11/0x13 [c01f0b48] driver_detach+0x11/0x13 [bus_remove_driver+76/130] bus_remove_driver+0x4c/0x82 [c01f05f3] bus_remove_driver+0x4c/0x82 [driver_unregister+14/23] driver_unregister+0xe/0x17 [c01f0cba] driver_unregister+0xe/0x17 [pci_unregister_driver+14/23] pci_unregister_driver+0xe/0x17 [c019b242] pci_unregister_driver+0xe/0x17 [sys_delete_module+322/379] sys_delete_module+0x142/0x17b [c0128356] sys_delete_module+0x142/0x17b [sysenter_past_esp+84/117] sysenter_past_esp+0x54/0x75 .config attached ~~ laurent # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-rc1-mm2 # Thu Mar 24 23:38:31 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_CLEAR_PAGES=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set CONFIG_EMBEDDED=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set
Re: 2.6.12-rc1-mm2
Laurent Riffard [EMAIL PROTECTED] wrote: hello, Same kinds of problem here. It depends on the removed module. I mean: rmmod loop or rmmod pcspkr works. But rmmod snd_ens1371 or rmmod ohci1394 hangs. Sysrq-T when rmmoding snd_ens1371 : rmmod D C92EBE8C 0 8231 8159 (NOTLB) c92ebea0 0082 0003 c92ebe8c 5685fc00 000f4253 cd624530 cd624658 cff60874 cff60844 c92ebebc c92ebef0 c02618c7 cd624530 c0113137 0282 cd248c20 cd248c07 0001 cd624530 Call Trace: [wait_for_completion+124/193] wait_for_completion+0x7c/0xc1 [c02618c7] wait_for_completion+0x7c/0xc1 [device_release_driver+52/116] device_release_driver+0x34/0x74 [c01f0ae3] device_release_driver+0x34/0x74 [__remove_driver+8/12] __remove_driver+0x8/0xc [c01f0b2b] __remove_driver+0x8/0xc [driver_for_each_device+50/87] driver_for_each_device+0x32/0x57 [c01f0bd8] driver_for_each_device+0x32/0x57 [driver_detach+17/19] driver_detach+0x11/0x13 [c01f0b40] driver_detach+0x11/0x13 [bus_remove_driver+76/130] bus_remove_driver+0x4c/0x82 [c01f05eb] bus_remove_driver+0x4c/0x82 [driver_unregister+14/23] driver_unregister+0xe/0x17 [c01f0cb2] driver_unregister+0xe/0x17 [pci_unregister_driver+14/23] pci_unregister_driver+0xe/0x17 [c019b242] pci_unregister_driver+0xe/0x17 [sys_delete_module+322/379] sys_delete_module+0x142/0x17b [c0128356] sys_delete_module+0x142/0x17b It looks like we're getting stuck in the wait_for_completion() in the new klist_remove(). - 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.6.12-rc1-mm2
Hi, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.6.12-rc1-mm2/ - Added David Miller's networking tree to the -mm lineup as bk-net.patch. - Added Herbert Xu's crypto development tree to the -mm lineup as bk-cryptodev.patch. -mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually they are pulled 3-4 hours before the release of the -mm kernel. Usually it is possible to determine the latest cset from each tree by looking at the first couple of lines of the relevant patch in the broken-out/ directory. Although sometimes it isn't there if I had to massage the diff. - There may be an x86_64 problem here, although it works for me. If it fails early in boot, try reverting x86_64-separate-amd-cmp-detection-from-hyper-threading.patch - There's some work here on the recent USB PM resume bugs. If you had problems there, please test and be sure to cc linux-usb-devel@lists.sourceforge.net in any reports. - Some fixes for the recent DRM problems. - Big DVB update - md updates - nfs4 server updates - Lots more fixes - Lots more bugs. Fails to compile for me: CC [M] fs/nfs/dir.o CC [M] fs/nfs/inode.o CC [M] fs/nfs/nfs4proc.o fs/nfs/nfs4proc.c:2976: error: static declaration of 'nfs4_file_inode_operations' follows non-static declaration fs/nfs/nfs4_fs.h:179: error: previous declaration of 'nfs4_file_inode_operations' was here make[2]: *** [fs/nfs/nfs4proc.o] Error 1 make[1]: *** [fs/nfs] Error 2 make: *** [fs] Error 2 I needed to remove this line: extern struct inode_operations nfs4_file_inode_operations; from fs/nfs/nfs4_fs.h. Patch attached. Reuben --- fs/nfs/nfs4_fs.h2005-03-25 11:40:51.0 +1200 +++ fs/nfs/nfs4_fs.h2005-03-25 11:44:28.0 +1200 @@ -176,7 +176,6 @@ extern struct dentry_operations nfs4_dentry_operations; extern struct inode_operations nfs4_dir_inode_operations; -extern struct inode_operations nfs4_file_inode_operations; /* inode.c */ extern ssize_t nfs4_getxattr(struct dentry *, const char *, void *, size_t);
Re: 2.6.12-rc1-mm2
On Thu, 24 Mar 2005, Andrew Morton wrote: Laurent Riffard [EMAIL PROTECTED] wrote: hello, Same kinds of problem here. It depends on the removed module. I mean: rmmod loop or rmmod pcspkr works. But rmmod snd_ens1371 or rmmod ohci1394 hangs. Sysrq-T when rmmoding snd_ens1371 : snip It looks like we're getting stuck in the wait_for_completion() in the new klist_remove(). D'oh! It's getting hung while waiting to remove the current node from the list (which it can't remove because it's being used). The patch below should fix it. Pat = drivers/base/dd.c 1.3 vs edited = --- 1.3/drivers/base/dd.c 2005-03-21 12:25:04 -08:00 +++ edited/drivers/base/dd.c2005-03-24 16:55:21 -08:00 @@ -177,7 +177,7 @@ sysfs_remove_link(drv-kobj, kobject_name(dev-kobj)); sysfs_remove_link(dev-kobj, driver); - klist_remove(dev-knode_driver); + klist_del(dev-knode_driver); down(dev-sem); device_detach_shutdown(dev); - 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.6.12-rc1-mm2
On Thursday 24 March 2005 23:21, Brice Goglin wrote: Andrew Morton a écrit : Stefano Rivoir [EMAIL PROTECTED] wrote: --- linux-mm/include/linux/agp_backend.h.old +++ linux-mm/include/linux/agp_backend.h +extern struct agp_bridge_data * (*agp_find_bridge)(struct pci_dev *); Right, that fixed it for me. There were contradictory patches in flight and I stuck the latest drm tree into rc1-mm2 at the last minute, alas. You should revert agp-make-some-code-static.patch. But I assume that fixing the compile warnings does not fix the oopses which Stefano and Brice are seeing? My patch does fix both the compile warnings and my oops on my Radeon laptop. It also allows my machine to boot. Alexey ... drm_agp_init+0x30/0x8e drm_fill_in_dev+0xe7/0x195 drm_get_dev+0x4a/0xba kobject_get+0xf/0x13 do_initcalls+0x54/0xb0 init+0x0/0x100 init+0x0/0x100 kernel_thread_helper+0x0/0x0b kernel_thread_helper+0x5/0x0b ... 0Kernel panic - not syncing: Attempted to kill init! - 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 running ls -l /sys/class/i2c-adapter/*-- 2.6.12-rc1-mm2
[EMAIL PROTECTED]:/sys/class/i2c-adapter# ls * -l [EMAIL PROTECTED]:/sys# cat */*/*/* ksymoops 2.4.9 on i686 2.6.12-rc1-mm2. Options used -o /lib/modules/2.6.12-rc1-mm2 (specified) -m /boot/System.map-2.6.12-rc1-mm2 (specified) Unable to handle kernel paging request at virtual address 24fc1024 c0198448 *pde = Oops: [#1] CPU:0 EIP:0060:[c0198448]Not tainted VLI Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00210206 (2.6.12-rc1-mm2) eax: 0001 ebx: c039f820 ecx: 0001 edx: 24fc1000 esi: e75b6cc4 edi: f7c015e4 ebp: e7b93e94 esp: e7b93e94 ds: 007b es: 007b ss: 0068 Stack: e7b93eb8 c0198644 f7c01694 f7c015e4 e7b93eb8 c039f820 e75b6cc4 f7c015e4 e7b93edc c0198790 f7c01694 f7c015e4 e712a000 f7c01694 e712a000 fff4 e7b93f10 e7b93ef8 c019884f e75b6cc4 e712a000 ffea e75b6cc4 Call Trace: [c010410f] show_stack+0x7f/0xa0 [c01042aa] show_registers+0x15a/0x1c0 [c01044ac] die+0xfc/0x190 [c011450b] do_page_fault+0x31b/0x670 [c0103cf3] error_code+0x4f/0x54 [c0198644] sysfs_get_target_path+0x14/0x80 [c0198790] sysfs_getlink+0xe0/0x150 [c019884f] sysfs_follow_link+0x4f/0x60 [c016b46f] generic_readlink+0x2f/0x90 [c01635b6] sys_readlink+0x86/0x90 [c0103249] syscall_call+0x7/0xb Code: 42 70 e8 a4 fc 19 00 e9 f3 fe ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 55 31 c0 89 e5 8b 55 088b 52 24 40 85 d2 75 f8 c9 c3 8d b4 26 00 00 00 00 8d bc 27 00 EIP; c0198448 object_depth+8/20 = ebx; c039f820 sysfs_rename_sem+0/c edx; 24fc1000 phys_startup_32+24ec1000/c000 esi; e75b6cc4 pg0+270ebcc4/3fb33400 edi; f7c015e4 pg0+377365e4/3fb33400 ebp; e7b93e94 pg0+276c8e94/3fb33400 esp; e7b93e94 pg0+276c8e94/3fb33400 Trace; c010410f show_stack+7f/a0 Trace; c01042aa show_registers+15a/1c0 Trace; c01044ac die+fc/190 Trace; c011450b do_page_fault+31b/670 Trace; c0103cf3 error_code+4f/54 Trace; c0198644 sysfs_get_target_path+14/80 Trace; c0198790 sysfs_getlink+e0/150 Trace; c019884f sysfs_follow_link+4f/60 Trace; c016b46f generic_readlink+2f/90 Trace; c01635b6 sys_readlink+86/90 Trace; c0103249 syscall_call+7/b This architecture has variable length instructions, decoding before eip is unreliable, take these instructions with a pinch of salt. Code; c019841d .text.lock.dir+d7/fa _EIP: Code; c019841d .text.lock.dir+d7/fa 0: 42inc%edx Code; c019841e .text.lock.dir+d8/fa 1: 70 e8 jo ffeb _EIP+0xffeb Code; c0198420 .text.lock.dir+da/fa 3: a4movsb %ds:(%esi),%es:(%edi) Code; c0198421 .text.lock.dir+db/fa 4: fccld Code; c0198422 .text.lock.dir+dc/fa 5: 19 00 sbb%eax,(%eax) Code; c0198424 .text.lock.dir+de/fa 7: e9 f3 fe ff ffjmpfeff _EIP+0xfeff Code; c0198429 .text.lock.dir+e3/fa c: 90nop Code; c019842a .text.lock.dir+e4/fa d: 90nop Code; c019842b .text.lock.dir+e5/fa e: 90nop Code; c019842c .text.lock.dir+e6/fa f: 90nop Code; c019842d .text.lock.dir+e7/fa 10: 90nop Code; c019842e .text.lock.dir+e8/fa 11: 90nop Code; c019842f .text.lock.dir+e9/fa 12: 90nop Code; c0198430 .text.lock.dir+ea/fa 13: 90nop Code; c0198431 .text.lock.dir+eb/fa 14: 90nop Code; c0198432 .text.lock.dir+ec/fa 15: 90nop Code; c0198433 .text.lock.dir+ed/fa 16: 90nop Code; c0198434 .text.lock.dir+ee/fa 17: 90nop Code; c0198435 .text.lock.dir+ef/fa 18: 90nop Code; c0198436 .text.lock.dir+f0/fa 19: 90nop Code; c0198437 .text.lock.dir+f1/fa 1a: 90nop Code; c0198438 .text.lock.dir+f2/fa 1b: 90nop Code; c0198439 .text.lock.dir+f3/fa 1c: 90nop Code; c019843a .text.lock.dir+f4/fa 1d: 90nop Code; c019843b .text.lock.dir+f5/fa 1e: 90nop Code; c019843c .text.lock.dir+f6/fa 1f: 90nop Code; c019843d .text.lock.dir+f7/fa 20: 90nop Code; c019843e .text.lock.dir+f/60 Trace; c01681de __link_path_walk+8ce/ec0 Trace; c016885f link_path_walk+8f/190 Trace; c0168c45 path_lookup+95/170 Trace; c01693ef open_namei+7f/650 Trace; c015823c filp_open+3c/60 Trace; c01586e8 sys_open+48/d0 Trace; c0103249 syscall_call+7/b This architecture has variable length instructions, decoding before eip is unreliable, take these instructions with a pinch of salt. Code; c019841d .text.lock.dir+d7/fa _EIP: Code; c019841d .text.lock.dir+d7/fa 0: 42
Error building ndiswrapper-1.0rc1 against 2.6.12-rc1-mm2 sources
Hi, Was this change intentional or accidental? I have successfully built ndiswrapper-1.0rc1 with the other recent kernel trees. /usr/src/ndiswrapper-1.0rc1/driver/wrapper.c: In function `wrapper_init': /usr/src/ndiswrapper-1.0rc1/driver/wrapper.c:1485: warning: passing arg 4 of `call_usermodehelper' makes pointer from integer without a cast /usr/src/ndiswrapper-1.0rc1/driver/wrapper.c:1485: error: too few arguments to function `call_usermodehelper' make[3]: *** [/usr/src/ndiswrapper-1.0rc1/driver/wrapper.o] Error 1 - 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 running ls -l /sys/class/i2c-adapter/*-- 2.6.12-rc1-mm2
Miles Lane [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]:/sys/class/i2c-adapter# ls * -l [EMAIL PROTECTED]:/sys# cat */*/*/* ksymoops 2.4.9 on i686 2.6.12-rc1-mm2. Options used -o /lib/modules/2.6.12-rc1-mm2 (specified) -m /boot/System.map-2.6.12-rc1-mm2 (specified) Unable to handle kernel paging request at virtual address 24fc1024 c0198448 *pde = Oops: [#1] CPU:0 EIP:0060:[c0198448]Not tainted VLI I wonder why the EIP sometimes doesn't get decoded. Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00210206 (2.6.12-rc1-mm2) eax: 0001 ebx: c039f820 ecx: 0001 edx: 24fc1000 esi: e75b6cc4 edi: f7c015e4 ebp: e7b93e94 esp: e7b93e94 ds: 007b es: 007b ss: 0068 Stack: e7b93eb8 c0198644 f7c01694 f7c015e4 e7b93eb8 c039f820 e75b6cc4 f7c015e4 e7b93edc c0198790 f7c01694 f7c015e4 e712a000 f7c01694 e712a000 fff4 e7b93f10 e7b93ef8 c019884f e75b6cc4 e712a000 ffea e75b6cc4 Call Trace: [c010410f] show_stack+0x7f/0xa0 [c01042aa] show_registers+0x15a/0x1c0 [c01044ac] die+0xfc/0x190 [c011450b] do_page_fault+0x31b/0x670 [c0103cf3] error_code+0x4f/0x54 [c0198644] sysfs_get_target_path+0x14/0x80 [c0198790] sysfs_getlink+0xe0/0x150 [c019884f] sysfs_follow_link+0x4f/0x60 [c016b46f] generic_readlink+0x2f/0x90 [c01635b6] sys_readlink+0x86/0x90 [c0103249] syscall_call+0x7/0xb Code: 42 70 e8 a4 fc 19 00 e9 f3 fe ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 55 31 c0 89 e5 8b 55 088b 52 24 40 85 d2 75 f8 c9 c3 8d b4 26 00 00 00 00 8d bc 27 00 EIP; c0198448 object_depth+8/20 = I can't repeat it here. Are you able to narrow it down to a specific sysfs file? The .config might help. - 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/
