* Is this a Bug?
@ 2011-06-21 21:57 Christian Deussen
2011-06-21 22:49 ` Greg Freemyer
2011-06-23 18:49 ` Jonathan Neuschäfer
0 siblings, 2 replies; 41+ messages in thread
From: Christian Deussen @ 2011-06-21 21:57 UTC (permalink / raw)
To: kernelnewbies
Hi,
I just compiled my first Kernel from linus' tree and saw a warning in "sound/soc/codecs/wm8958-dsp2.c".
I think a found a bug, but I am not sure. And I don`t want to waste the Kernel-dev's time on the lkml.
In function wm8958_dsp2_fw(), at line 64, there is an uninitialized variable used.
u32 data 32;
...
/*not related code*/
...
if (memcmp(fw->data, "WMFW", 4) != 0) {
dev_err(codec->dev, "%s: firmware has bad file magic %08x\n",
name, data32); //shouldn't fw->data be used?
goto err;
}
Am I right? And does this detail matter anyway?
I made several small fixes for warnings and added some #ifdef CONFIG_BLA when code wasnt used. Are those changes welcome on the LKML?
Thanks for your time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110621/f2281b8e/attachment.html
^ permalink raw reply [flat|nested] 41+ messages in thread* Is this a Bug?
2011-06-21 21:57 Is this a Bug? Christian Deussen
@ 2011-06-21 22:49 ` Greg Freemyer
2011-06-22 7:28 ` Wilson Felipe
2011-06-23 18:49 ` Jonathan Neuschäfer
1 sibling, 1 reply; 41+ messages in thread
From: Greg Freemyer @ 2011-06-21 22:49 UTC (permalink / raw)
To: kernelnewbies
On Tue, Jun 21, 2011 at 5:57 PM, Christian Deussen
<chrisudeussen@googlemail.com> wrote:
>
> Hi,
> I just?compiled?my first Kernel from linus' tree and saw a warning in
> "sound/soc/codecs/wm8958-dsp2.c".
> I think a found a bug, but I am not sure. And I don`t want to waste the
> Kernel-dev's time on the lkml.
> In function?wm8958_dsp2_fw(),?at line 64, there is an?uninitialized?variable
> used.
>
> u32 data 32;
> ? ...
> ?/*not related code*/
> ...
> if (memcmp(fw->data, "WMFW", 4) != 0) {
> dev_err(codec->dev, "%s: firmware has bad file magic %08x\n",
> name, data32); //shouldn't?fw->data be used?
> goto err;
> }
> Am I right? And does this detail matter anyway?
> I made several small fixes for warnings and added some #ifdef CONFIG_BLA
> when code wasnt used. Are those changes welcome on the LKML?
> Thanks for your time.
First, every part of the kernel has a maintainer. You can look in the
maintainers file to see who it is and which mailinglist to use for the
code in question.
Your find it in the root of your kernel source directory. Or online
at http://lxr.linux.no/#linux+v2.6.39/MAINTAINERS
So any patches need to go the right maintainer and the right mailing
list. I for one avoid LKML itself due to the massive traffic. But I
follow libata and ext4 and a couple others. That makes the process
reasonable.
Note your email should be to the right list and to the right
maintainer. Both should be on the TO: line of your email.
As to your question, I think it varies by the maintainer.
If the maintainer is carrying a lot of out of tree patches for the
part of the kernel he maintains, then every time he accepts a patch,
it has the potential to cause those patches to no longer apply.
As an example, the ext4 filesystem currently has dozens or even
hundreds of patches that have been submitted fro review, or which are
in the process of being developed, but which are not yet in the main
kernel.
A proposed patch to fix a compile warning or the code indention, etc.
is likely not welcome on its own.
On the other hand, if you are making a real code change which is an
improvement, then submitting a patch series with the first patch or
two addressing code style issues, etc. at the start of the series
would be welcome.
The reason being any other patches that are going to effect that same
part of the code are going to need to re-based anyway due to the
functional change, so putting in a cosmetic change at the same causes
little extra work in the re-basing process.
Hope that makes sense, even if it doesn't answer your question.
At the end of the day, you might just want to send the maintainer (and
the right list) a email asking if a patch like that is welcome, etc.
Greg
^ permalink raw reply [flat|nested] 41+ messages in thread* Is this a Bug?
2011-06-21 22:49 ` Greg Freemyer
@ 2011-06-22 7:28 ` Wilson Felipe
2011-06-22 19:50 ` julie Sullivan
0 siblings, 1 reply; 41+ messages in thread
From: Wilson Felipe @ 2011-06-22 7:28 UTC (permalink / raw)
To: kernelnewbies
you can use the get_maintainer.pl script:
~/linux-2.6 $ ./scripts/get_maintainer.pl -f sound/soc/codecs/wm8958-dsp2.c
it will give you the maintainers names and emails
On Wed, Jun 22, 2011 at 12:49 AM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
> On Tue, Jun 21, 2011 at 5:57 PM, Christian Deussen
> <chrisudeussen@googlemail.com> wrote:
>>
>> Hi,
>> I just?compiled?my first Kernel from linus' tree and saw a warning in
>> "sound/soc/codecs/wm8958-dsp2.c".
>> I think a found a bug, but I am not sure. And I don`t want to waste the
>> Kernel-dev's time on the lkml.
>> In function?wm8958_dsp2_fw(),?at line 64, there is an?uninitialized?variable
>> used.
>>
>> u32 data 32;
>> ? ...
>> ?/*not related code*/
>> ...
>> if (memcmp(fw->data, "WMFW", 4) != 0) {
>> dev_err(codec->dev, "%s: firmware has bad file magic %08x\n",
>> name, data32); //shouldn't?fw->data be used?
>> goto err;
>> }
>> Am I right? And does this detail matter anyway?
>> I made several small fixes for warnings and added some #ifdef CONFIG_BLA
>> when code wasnt used. Are those changes welcome on the LKML?
>> Thanks for your time.
>
> First, every part of the kernel has a maintainer. ?You can look in the
> maintainers file to see who it is and which mailinglist to use for the
> code in question.
>
> Your find it in the root of your kernel source directory. ?Or online
> at http://lxr.linux.no/#linux+v2.6.39/MAINTAINERS
>
> So any patches need to go the right maintainer and the right mailing
> list. ?I for one avoid LKML itself due to the massive traffic. ?But I
> follow libata and ext4 and a couple others. ?That makes the process
> reasonable.
>
> Note your email should be to the right list and to the right
> maintainer. ?Both should be on the TO: line of your email.
>
> As to your question, I think it varies by the maintainer.
>
> If the maintainer is carrying a lot of out of tree patches for the
> part of the kernel he maintains, then every time he accepts a patch,
> it has the potential to cause those patches to no longer apply.
>
> As an example, the ext4 filesystem currently has dozens or even
> hundreds of patches that have been submitted fro review, or which are
> in the process of being developed, but which are not yet in the main
> kernel.
>
> A proposed patch to fix a compile warning or the code indention, etc.
> is likely not welcome on its own.
>
> On the other hand, if you are making a real code change which is an
> improvement, then submitting a patch series with the first patch or
> two addressing code style issues, etc. at the start of the series
> would be welcome.
>
> The reason being any other patches that are going to effect that same
> part of the code are going to need to re-based anyway due to the
> functional change, so putting in a cosmetic change at the same causes
> little extra work in the re-basing process.
>
> Hope that makes sense, even if it doesn't answer your question.
>
> At the end of the day, you might just want to send the maintainer (and
> the right list) a email asking if a patch like that is welcome, etc.
>
> Greg
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
^ permalink raw reply [flat|nested] 41+ messages in thread* Is this a Bug?
2011-06-22 7:28 ` Wilson Felipe
@ 2011-06-22 19:50 ` julie Sullivan
2011-06-22 21:21 ` julie Sullivan
0 siblings, 1 reply; 41+ messages in thread
From: julie Sullivan @ 2011-06-22 19:50 UTC (permalink / raw)
To: kernelnewbies
Hi Christian,
Here's the most recent conversation I found (last month) on LKML
regarding this file where someone sent a patch, you may find it
helpful to read through the thread to see what the maintainers said.
https://lkml.org/lkml/2011/5/6/353
HTH,
Julie
^ permalink raw reply [flat|nested] 41+ messages in thread
* Is this a Bug?
2011-06-22 19:50 ` julie Sullivan
@ 2011-06-22 21:21 ` julie Sullivan
2011-06-23 12:16 ` Christian D.
0 siblings, 1 reply; 41+ messages in thread
From: julie Sullivan @ 2011-06-22 21:21 UTC (permalink / raw)
To: kernelnewbies
Hmm, I just enabled the 'Build all ASoC CODEC drivers' option (I don't
have the hardware) to build-test to see if I could get the same
warning as Christian and I didn't, but I did get this in the same
tree:
sound/soc/codecs/ak4641.c: In function ?ak4641_probe?:
sound/soc/codecs/ak4641.c:524:6: error: ?GPIOF_OUT_INIT_LOW?
undeclared (first use in this function)
sound/soc/codecs/ak4641.c:524:6: note: each undeclared identifier is
reported only once for each function it appears in
make[3]: *** [sound/soc/codecs/ak4641.o] Error 1
make[2]: *** [sound/soc/codecs] Error 2
make[1]: *** [sound/soc] Error 2
make: *** [sound] Error 2
make: *** Waiting for unfinished jobs....
Odd.
Is there some other CONFIG_ I'm not setting that I need to for your
driver, Christian? (I'm using -rc3, -rc4 won't boot but that's another
problem...)
---
btw if you _are_ sending a patch and it's your first one:
remember you can avoid the embarrassment of maintainers experiencing
your tabs to space conversion, word-wrapping and other
reformatting/corruption horrors by sending yourself the patch first to
check it applies - or send it to us, I'm happy to 'apply check' it for
you if you can let me know what kernel version to check out (can't
promise I'll do it the same day though) :-)
If you are thinking of using the Gmail web gui to send a patch be sure
to read Documentation/email-clients.txt with special reference to the
bit at the bottom of that file...
Cheers
Julie
^ permalink raw reply [flat|nested] 41+ messages in thread
* Is this a Bug?
2011-06-22 21:21 ` julie Sullivan
@ 2011-06-23 12:16 ` Christian D.
2011-06-23 13:03 ` Jonathan Neuschäfer
0 siblings, 1 reply; 41+ messages in thread
From: Christian D. @ 2011-06-23 12:16 UTC (permalink / raw)
To: kernelnewbies
Hi,
thanks for your help. I a m using -rc3 on an Ubuntu system. I used "make
loadmodconfig" to create my .config. I then enabled Kernel debugging. Should
I append my .config file?
The bug/warning seems to be added by this commit.
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=fbbf592002ee46ed14d5bd88f1150c604b34e705
.
I would love to contribute a patch but it I think I better wait until I
found a bigger/more problem.
2011/6/22 julie Sullivan <kernelmail.jms@gmail.com>
> Hmm, I just enabled the 'Build all ASoC CODEC drivers' option (I don't
> have the hardware) to build-test to see if I could get the same
> warning as Christian and I didn't, but I did get this in the same
> tree:
>
> sound/soc/codecs/ak4641.c: In function ?ak4641_probe?:
> sound/soc/codecs/ak4641.c:524:6: error: ?GPIOF_OUT_INIT_LOW?
> undeclared (first use in this function)
> sound/soc/codecs/ak4641.c:524:6: note: each undeclared identifier is
> reported only once for each function it appears in
> make[3]: *** [sound/soc/codecs/ak4641.o] Error 1
> make[2]: *** [sound/soc/codecs] Error 2
> make[1]: *** [sound/soc] Error 2
> make: *** [sound] Error 2
> make: *** Waiting for unfinished jobs....
>
> In my config 'Build all ASoC CODEC drivers' is selected to be build as
module, but I can not reproduce your error.
Isn't it bad that more than 20 warnings are produced during a kernel build?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110623/245235b5/attachment.html
^ permalink raw reply [flat|nested] 41+ messages in thread
* Is this a Bug?
2011-06-23 12:16 ` Christian D.
@ 2011-06-23 13:03 ` Jonathan Neuschäfer
0 siblings, 0 replies; 41+ messages in thread
From: Jonathan Neuschäfer @ 2011-06-23 13:03 UTC (permalink / raw)
To: kernelnewbies
On Thu, Jun 23, 2011 at 02:16:05PM +0200, Christian D. wrote:
> Hi,
> thanks for your help. I a m using -rc3 on an Ubuntu system. I used "make
> loadmodconfig" to create my .config. I then enabled Kernel debugging. Should
> I append my .config file?
> The bug/warning seems to be added by this commit.
> http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=fbbf592002ee46ed14d5bd88f1150c604b34e705
> .
> I would love to contribute a patch but it I think I better wait until I
> found a bigger/more problem.
Well, I think, you don't need to. I have seven patches in the kernel, four
of which are just spelling fixes [1]. What you need is an explanation
coming with every patch you send; again, if you're not sure just send
your patch to this list (kernelnewbies) and someone will comment on it.
[1] http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git&a=search&h=HEAD&st=author&s=neusch
HTH,
Jonathan Neusch?fer
^ permalink raw reply [flat|nested] 41+ messages in thread
* Is this a Bug?
2011-06-21 21:57 Is this a Bug? Christian Deussen
2011-06-21 22:49 ` Greg Freemyer
@ 2011-06-23 18:49 ` Jonathan Neuschäfer
1 sibling, 0 replies; 41+ messages in thread
From: Jonathan Neuschäfer @ 2011-06-23 18:49 UTC (permalink / raw)
To: kernelnewbies
On Tue, Jun 21, 2011 at 11:57:02PM +0200, Christian Deussen wrote:
>
> Hi,
> I just compiled my first Kernel from linus' tree and saw a warning in "sound/soc/codecs/wm8958-dsp2.c".
> I think a found a bug, but I am not sure. And I don`t want to waste the Kernel-dev's time on the lkml.
> In function wm8958_dsp2_fw(), at line 64, there is an uninitialized variable used.
>
>
> u32 data 32;
> ...
> /*not related code*/
> ...
>
> if (memcmp(fw->data, "WMFW", 4) != 0) {
> dev_err(codec->dev, "%s: firmware has bad file magic %08x\n",
> name, data32); //shouldn't fw->data be used?
> goto err;
> }
Unfortunately, printk("%08x", fw->data) will print 32 bit of the pointer
fw->data, not the first 4 bytes of where it points. (CMIIW).
One (somewhat unelegant) solution would be:
dev_err(codec->dev, "%s: firmware has bad file magic %02x%02x%02x%02x\n",
name, fw->data[0], fw->data[1], fw->data[2], fw->data[3]);
Maybe a fix like this would be appropriate:
diff --git a/sound/soc/codecs/wm8958-dsp2.c b/sound/soc/codecs/wm8958-dsp2.c
index 0293763..9d92de5 100644
--- a/sound/soc/codecs/wm8958-dsp2.c
+++ b/sound/soc/codecs/wm8958-dsp2.c
@@ -59,6 +59,9 @@ static int wm8958_dsp2_fw(struct snd_soc_codec *codec, const char *name,
goto err;
}
+ memcpy(&data32, fw->data, sizeof(data32));
+ data32 = be32_to_cpu(data32);
+
if (memcmp(fw->data, "WMFW", 4) != 0) {
dev_err(codec->dev, "%s: firmware has bad file magic %08x\n",
name, data32);
HTH,
Jonathan Neusch?fer
^ permalink raw reply related [flat|nested] 41+ messages in thread
* Is this a bug?
@ 2017-06-21 3:08 Peter Teoh
0 siblings, 0 replies; 41+ messages in thread
From: Peter Teoh @ 2017-06-21 3:08 UTC (permalink / raw)
To: LKML
I got this crashdump inside QEMU (running 4.11.0 stable):
[ 0.588497] pci 0000:00:01.0: Activating ISA DMA hang workarounds
[ 1.778428] ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
[ 2.991744] pci 0000:00:02.0: Video device with shadowed ROM at
[mem 0x000c0000-0x000dffff]
[ 2.992993] Unpacking initramfs...
[ 453.628449] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 21s!
[swapper/0:1]
[ 453.629130] Modules linked in:
[ 453.629370] irq event stamp: 6845090
[ 453.629710] hardirqs last enabled at (6845089):
[<ffffffff816b8c6c>] mem_cgroup_commit_charge+0x15c/0x2f0
[ 453.630462] hardirqs last disabled at (6845090):
[<ffffffff82cf51ee>] apic_timer_interrupt+0x8e/0xa0
[ 453.631147] softirqs last enabled at (6844578):
[<ffffffff82cf9dd4>] __do_softirq+0x664/0x883
[ 453.631780] softirqs last disabled at (6844571):
[<ffffffff8118cc53>] irq_exit+0x1a3/0x1d0
[ 453.632359] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0syz #7
[ 453.632890] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[ 453.633605] task: ffff880064a48040 task.stack: ffff880064a50000
[ 453.634113] RIP: 0010:__memset+0x24/0x30
[ 453.634384] RSP: 0000:ffff880064a576a0 EFLAGS: 00010206 ORIG_RAX:
ffffffffffffff10
[ 453.634901] RAX: 0000000000000000 RBX: ffff8800378001e0 RCX: 00000000000001c4
[ 453.635366] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8800378001e0
[ 453.635829] RBP: ffff880064a576c0 R08: 0000000000000000 R09: ffff8800378001e0
[ 453.636290] R10: ffff880037800fff R11: 0000000000000000 R12: 0000000000000e20
[ 453.636826] R13: 0000000000000000 R14: ffff880064a48040 R15: 00000000000001e0
[ 453.637320] FS: 0000000000000000(0000) GS:ffff880065400000(0000)
knlGS:0000000000000000
[ 453.637835] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 453.638208] CR2: 0000000000000000 CR3: 0000000003613000 CR4: 00000000000006f0
[ 453.638684] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 453.639339] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 453.639944] Call Trace:
[ 453.640119] ? memset+0x31/0x40
[ 453.640436] simple_write_begin+0x18f/0x2b0
[ 453.640799] generic_perform_write+0x274/0x520
[ 453.641204] ? __page_cache_alloc+0x310/0x310
[ 453.641532] ? file_update_time+0xce/0x3d0
[ 453.641821] ? current_time+0xd0/0xd0
[ 453.642135] ? lock_acquire+0x17d/0x350
[ 453.642457] __generic_file_write_iter+0x32f/0x5b0
[ 453.642806] generic_file_write_iter+0x2ea/0x600
[ 453.643162] __vfs_write+0x3d4/0x650
[ 453.643435] ? vfs_iter_write+0x550/0x550
[ 453.643772] ? rcu_sync_lockdep_assert+0x78/0xb0
[ 453.644092] ? __sb_start_write+0x1ed/0x2b0
[ 453.644499] vfs_write+0x175/0x4e0
[ 453.644741] SyS_write+0xe8/0x1d0
[ 453.644996] ? SyS_read+0x1d0/0x1d0
[ 453.645275] ? zlib_inflate+0x282/0x5d40
[ 453.645574] xwrite+0x36/0x8a
[ 453.645831] do_copy+0xb5/0xf6
[ 453.646070] write_buffer+0x5d/0x77
[ 453.646387] flush_buffer+0x3a/0xff
[ 453.646658] __gunzip+0x64e/0x7e6
[ 453.646929] ? bunzip2+0x980/0x980
[ 453.647164] ? write_buffer+0x77/0x77
[ 453.647461] ? write_buffer+0x77/0x77
[ 453.647721] gunzip+0x43/0x52
[ 453.647942] ? md_run_setup+0xad/0xad
[ 453.648225] ? __gunzip+0x7e6/0x7e6
[ 453.648535] unpack_to_rootfs+0x284/0x527
[ 453.648822] ? md_run_setup+0xad/0xad
[ 453.649091] ? do_reset+0x91/0x91
[ 453.649377] populate_rootfs+0x116/0x344
[ 453.649657] ? maybe_link.part.5+0x31c/0x31c
[ 453.650089] do_one_initcall+0xb9/0x290
[ 453.650384] ? initcall_blacklisted+0x1b0/0x1b0
[ 453.650732] ? parse_args+0x228/0xb60
[ 453.651008] kernel_init_freeable+0x49a/0x54e
[ 453.651348] ? rest_init+0x190/0x190
[ 453.651650] kernel_init+0x18/0x180
[ 453.651965] ? rest_init+0x190/0x190
[ 453.652223] ret_from_fork+0x31/0x40
[ 453.652543] Code: 90 90 90 90 90 90 90 0f 1f 44 00 00 49 89 f9 48
89 d1 83 e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01
48 0f af c6 <f3> 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48
89 d1
[ 530.660850] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 21s!
[swapper/0:1]
[ 530.661442] Modules linked in:
[ 530.661679] irq event stamp: 6876482
[ 530.661939] hardirqs last enabled at (6876481):
[<ffffffff816b8c6c>] mem_cgroup_commit_charge+0x15c/0x2f0
[ 530.662715] hardirqs last disabled at (6876482):
[<ffffffff82cf51ee>] apic_timer_interrupt+0x8e/0xa0
[ 530.663385] softirqs last enabled at (6876448):
[<ffffffff82cf9dd4>] __do_softirq+0x664/0x883
[ 530.664000] softirqs last disabled at (6876441):
[<ffffffff8118cc53>] irq_exit+0x1a3/0x1d0
[ 530.664728] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G L
4.11.0syz #7
[ 530.665360] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[ 530.666139] task: ffff880064a48040 task.stack: ffff880064a50000
[ 530.666649] RIP: 0010:__memcpy+0x12/0x20
[ 530.667065] RSP: 0000:ffff880064a57670 EFLAGS: 00010246 ORIG_RAX:
ffffffffffffff10
[ 530.668093] RAX: ffff8800aac00000 RBX: 0000000000001000 RCX: 0000000000000200
[ 530.668694] RDX: 0000000000000000 RSI: ffff8800627fc394 RDI: ffff8800aac00000
[ 530.669348] RBP: ffff880064a57690 R08: 0000000000000000 R09: ffffed00155801ff
[ 530.669978] R10: ffff8800aac00fff R11: 0000000000000000 R12: ffff8800aac00000
[ 530.670715] R13: ffff8800627fc394 R14: ffffffff82f737c0 R15: ffff880064a57948
[ 530.671329] FS: 0000000000000000(0000) GS:ffff880065400000(0000)
knlGS:0000000000000000
[ 530.672049] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 530.672560] CR2: 0000000000000000 CR3: 0000000003613000 CR4: 00000000000006f0
[ 530.673212] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 530.673818] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 530.674432] Call Trace:
[ 530.674717] ? memcpy+0x45/0x50
[ 530.675051] iov_iter_copy_from_user_atomic+0x67d/0x8a0
[ 530.675537] ? grab_cache_page_write_begin+0x8b/0xa0
[ 530.675999] generic_perform_write+0x2df/0x520
[ 530.676397] ? __mark_inode_dirty+0x2c0/0xe90
[ 530.676816] ? __page_cache_alloc+0x310/0x310
[ 530.677269] ? __mnt_drop_write_file+0x12/0x70
[ 530.677686] ? file_update_time+0xce/0x3d0
[ 530.678047] ? current_time+0xd0/0xd0
[ 530.678422] ? lock_acquire+0x17d/0x350
[ 530.678795] __generic_file_write_iter+0x32f/0x5b0
[ 530.679240] generic_file_write_iter+0x2ea/0x600
[ 530.679643] __vfs_write+0x3d4/0x650
[ 530.680038] ? vfs_iter_write+0x550/0x550
[ 530.680440] ? rcu_sync_lockdep_assert+0x78/0xb0
[ 530.680900] ? __sb_start_write+0x1ed/0x2b0
[ 530.681313] vfs_write+0x175/0x4e0
[ 530.681676] SyS_write+0xe8/0x1d0
[ 530.681966] ? SyS_read+0x1d0/0x1d0
[ 530.682306] ? zlib_inflate+0x282/0x5d40
[ 530.682684] xwrite+0x36/0x8a
[ 530.682988] do_copy+0xb5/0xf6
[ 530.683396] write_buffer+0x5d/0x77
[ 530.683741] flush_buffer+0x3a/0xff
[ 530.684264] __gunzip+0x64e/0x7e6
[ 530.684741] ? bunzip2+0x980/0x980
[ 530.685084] ? write_buffer+0x77/0x77
[ 530.685481] ? write_buffer+0x77/0x77
[ 530.685840] gunzip+0x43/0x52
[ 530.686152] ? md_run_setup+0xad/0xad
[ 530.686559] ? __gunzip+0x7e6/0x7e6
[ 530.686897] unpack_to_rootfs+0x284/0x527
[ 530.687279] ? md_run_setup+0xad/0xad
[ 530.687628] ? do_reset+0x91/0x91
[ 530.688028] populate_rootfs+0x116/0x344
[ 530.688429] ? maybe_link.part.5+0x31c/0x31c
[ 530.688874] do_one_initcall+0xb9/0x290
[ 530.689244] ? initcall_blacklisted+0x1b0/0x1b0
[ 530.689760] ? parse_args+0x228/0xb60
[ 530.690138] kernel_init_freeable+0x49a/0x54e
[ 530.690542] ? rest_init+0x190/0x190
[ 530.690916] kernel_init+0x18/0x180
[ 530.691320] ? rest_init+0x190/0x190
[ 530.691762] ret_from_fork+0x31/0x40
[ 530.692127] Code: 90 ff e9 4d ff ff ff e8 ad bb 90 ff eb 8f e8 a6
bb 90 ff e9 66 ff ff ff 90 0f 1f 44 00 00 48 89 f8 48 89 d1 48 c1 e9
03 83 e2 07 <f3> 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89
d1 f3
Not sure if the QEMU reboot itself or not
--
Regards,
Peter Teoh
^ permalink raw reply [flat|nested] 41+ messages in thread
* RE: Is this a bug?
@ 2013-02-19 9:32 David Wade
2013-02-19 9:42 ` Andreas Ericsson
2013-02-19 9:47 ` Erik Faye-Lund
0 siblings, 2 replies; 41+ messages in thread
From: David Wade @ 2013-02-19 9:32 UTC (permalink / raw)
To: git
Hi,
I wrote a commit message beginning with a hash (#) character, like this: 'git commit -m "#ifdef ...." '
Everything went okay when committing, but then I tried 'git commit -amend' and without editing the commit message I was told I had an empty commit message.
Is this a problem with my text editor (vim 7.2) or git itself? (git version 1.7.2.2 under RedHat 5.8) Or something I'm not supposed to do ;-) ?
Thanks!
David Wade
Analyst, Seismic Imaging Development
ITC SUB RES
Statoil ASA
Mobile: +47 97572157
Email: dawad@statoil.com
Visitor address: Vassbotnen 23, Forus, Norway
Incorporation number: NO 923 609 016 MVA
www.statoil.com
Please consider the environment before printing this e-mail.
-------------------------------------------------------------------
The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorised use, dissemination of the
information or copying of this message is prohibited. If you are not the
addressee, please notify the sender immediately by return e-mail and delete
this message.
Thank you
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Is this a bug?
2013-02-19 9:32 David Wade
@ 2013-02-19 9:42 ` Andreas Ericsson
2013-02-19 9:47 ` Erik Faye-Lund
1 sibling, 0 replies; 41+ messages in thread
From: Andreas Ericsson @ 2013-02-19 9:42 UTC (permalink / raw)
To: David Wade; +Cc: git
On 02/19/2013 10:32 AM, David Wade wrote:
> Hi,
>
> I wrote a commit message beginning with a hash (#) character, like
> this: 'git commit -m "#ifdef ...." '
>
> Everything went okay when committing, but then I tried 'git commit
> -amend' and without editing the commit message I was told I had an
> empty commit message.
>
> Is this a problem with my text editor (vim 7.2) or git itself? (git
> version 1.7.2.2 under RedHat 5.8) Or something I'm not supposed to do
> ;-) ?
>
Lines starting with a hash sign are considered comments by git commit.
If you fire it up without '-m' you'll see that git puts all its own
notes about the commit in commented-out lines.
While empty commit messages aren't really unacceptable by git's model,
they're considered "almost certainly user errors". I expect the -m
flag being present when running 'git commit' causes the check for empty
message to be skipped, which isn't the case when amending the commit.
Btw, when I write messages probably similar to the one you just did, I
tend to write:
Use compat-layer __builtin_clz() #ifndef __GNUC__
precisely to avoid this issue. It also puts the imperative first,
which I find makes for smoother reading. Putting the condition first
screams for a comma and a slight stagger in reading flow, like so:
Unless built with gcc, use compat-layer __builtin_clz()
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Is this a bug?
2013-02-19 9:32 David Wade
2013-02-19 9:42 ` Andreas Ericsson
@ 2013-02-19 9:47 ` Erik Faye-Lund
2013-02-19 11:02 ` Duy Nguyen
1 sibling, 1 reply; 41+ messages in thread
From: Erik Faye-Lund @ 2013-02-19 9:47 UTC (permalink / raw)
To: David Wade; +Cc: git
On Tue, Feb 19, 2013 at 10:32 AM, David Wade <DAWAD@statoil.com> wrote:
> Hi,
>
> I wrote a commit message beginning with a hash (#) character, like this: 'git commit -m "#ifdef ...." '
>
> Everything went okay when committing, but then I tried 'git commit -amend' and without editing the commit message I was told I had an empty commit message.
>
> Is this a problem with my text editor (vim 7.2) or git itself? (git version 1.7.2.2 under RedHat 5.8) Or something I'm not supposed to do ;-) ?
The problem is that when doing interactive editing of messages (like
'git commit --amend' does), git considers '#' as a comment-character.
You can disable this by using the --cleanup=verbatim switch (or some
other suiting cleanup-setting, see 'git help commit').
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Is this a bug?
2013-02-19 9:47 ` Erik Faye-Lund
@ 2013-02-19 11:02 ` Duy Nguyen
2013-02-22 19:29 ` Phil Hord
0 siblings, 1 reply; 41+ messages in thread
From: Duy Nguyen @ 2013-02-19 11:02 UTC (permalink / raw)
To: kusmabite; +Cc: David Wade, git
On Tue, Feb 19, 2013 at 4:47 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> On Tue, Feb 19, 2013 at 10:32 AM, David Wade <DAWAD@statoil.com> wrote:
>> Hi,
>>
>> I wrote a commit message beginning with a hash (#) character, like this: 'git commit -m "#ifdef ...." '
>>
>> Everything went okay when committing, but then I tried 'git commit -amend' and without editing the commit message I was told I had an empty commit message.
>>
>> Is this a problem with my text editor (vim 7.2) or git itself? (git version 1.7.2.2 under RedHat 5.8) Or something I'm not supposed to do ;-) ?
>
> The problem is that when doing interactive editing of messages (like
> 'git commit --amend' does), git considers '#' as a comment-character.
> You can disable this by using the --cleanup=verbatim switch (or some
> other suiting cleanup-setting, see 'git help commit').
Nobody is always conscious about the leading # in commit message to do
that. I once edited a commit message and the auto-wrap feature put '#'
at the beginning of the line. I saved and went on without noticing one
line was lost until much later :( Perhaps we should change the comment
signature a bit to reduce accidents, like only recognize '#' lines as
comments after a special line like
# this is not a comment
### START OF COMMENT ###
# this is a comment
--
Duy
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Is this a bug?
2013-02-19 11:02 ` Duy Nguyen
@ 2013-02-22 19:29 ` Phil Hord
2013-02-22 21:48 ` Junio C Hamano
0 siblings, 1 reply; 41+ messages in thread
From: Phil Hord @ 2013-02-22 19:29 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Erik Faye-Lund, David Wade, git
On Tue, Feb 19, 2013 at 6:02 AM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Tue, Feb 19, 2013 at 4:47 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
>> On Tue, Feb 19, 2013 at 10:32 AM, David Wade <DAWAD@statoil.com> wrote:
>>> Hi,
>>>
>>> I wrote a commit message beginning with a hash (#) character, like this: 'git commit -m "#ifdef ...." '
>>>
>>> Everything went okay when committing, but then I tried 'git commit -amend' and without editing the commit message I was told I had an empty commit message.
>>>
>>> Is this a problem with my text editor (vim 7.2) or git itself? (git version 1.7.2.2 under RedHat 5.8) Or something I'm not supposed to do ;-) ?
>>
>> The problem is that when doing interactive editing of messages (like
>> 'git commit --amend' does), git considers '#' as a comment-character.
>> You can disable this by using the --cleanup=verbatim switch (or some
>> other suiting cleanup-setting, see 'git help commit').
>
> Nobody is always conscious about the leading # in commit message to do
> that. I once edited a commit message and the auto-wrap feature put '#'
> at the beginning of the line. I saved and went on without noticing one
> line was lost until much later :( Perhaps we should change the comment
> signature a bit to reduce accidents, like only recognize '#' lines as
> comments after a special line like
>
> # this is not a comment
> ### START OF COMMENT ###
> # this is a comment
Or maybe --amend should imply --cleanup=whitespace.
--
Phil
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Is this a bug?
2013-02-22 19:29 ` Phil Hord
@ 2013-02-22 21:48 ` Junio C Hamano
0 siblings, 0 replies; 41+ messages in thread
From: Junio C Hamano @ 2013-02-22 21:48 UTC (permalink / raw)
To: Phil Hord; +Cc: Duy Nguyen, Erik Faye-Lund, David Wade, git
Phil Hord <phil.hord@gmail.com> writes:
> Or maybe --amend should imply --cleanup=whitespace.
I am fairly negative on that.
Such a hidden linkage, even if it is documented, is just one more
thing people need to learn.
It _might_ be interesting (note: I did not say "worthwhile" here) to
think what happens if we scanned the message (either coming from the
commit being amended, -F file option, or -m message option), picked
a punctuation character that does not appear at the beginning of the
lines in it, and automatically adjusted core.commentchar if '#'
appears at the beginning of one of the lines, though.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Is this a bug?
@ 2011-04-02 8:05 Ding Dinghua
2011-04-02 16:32 ` Amir Goldstein
0 siblings, 1 reply; 41+ messages in thread
From: Ding Dinghua @ 2011-04-02 8:05 UTC (permalink / raw)
To: linux-ext4
When truncate files and free blocks, the following codes make me puzzled:
void ext4_free_blocks(handle_t *handle, struct inode *inode,
struct buffer_head *bh, ext4_fsblk_t block,
unsigned long count, int flags)
{
if (flags & EXT4_FREE_BLOCKS_FORGET) {
struct buffer_head *tbh = bh;
int i;
BUG_ON(bh && (count > 1));
for (i = 0; i < count; i++) {
if (!bh)
tbh = sb_find_get_block(inode->i_sb,
block + i);
if (unlikely(!tbh))
continue;
ext4_forget(handle, flags & EXT4_FREE_BLOCKS_METADATA,
inode, tbh, block + i);
}
}
}
I notice that ext4_forget mainly do two things:
a) call jbd2_journa_forget to forget the modification of some buffer head
b) or deal with the revoke issue
however, if we are freeing data blocks && ext4_forget get into branch a),
tbh is not the buffer_head which journal took care of in ext4_write_begin,
so i'm puzzled with this.
Could anyone explain it to me? Thanks.
--
Ding Dinghua
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: Is this a bug?
2011-04-02 8:05 Ding Dinghua
@ 2011-04-02 16:32 ` Amir Goldstein
2011-04-03 9:24 ` Ding Dinghua
0 siblings, 1 reply; 41+ messages in thread
From: Amir Goldstein @ 2011-04-02 16:32 UTC (permalink / raw)
To: Ding Dinghua; +Cc: linux-ext4
On Sat, Apr 2, 2011 at 1:05 AM, Ding Dinghua <dingdinghua85@gmail.com> wrote:
> When truncate files and free blocks, the following codes make me puzzled:
>
> void ext4_free_blocks(handle_t *handle, struct inode *inode,
> struct buffer_head *bh, ext4_fsblk_t block,
> unsigned long count, int flags)
> {
> if (flags & EXT4_FREE_BLOCKS_FORGET) {
> struct buffer_head *tbh = bh;
> int i;
>
> BUG_ON(bh && (count > 1));
>
> for (i = 0; i < count; i++) {
> if (!bh)
> tbh = sb_find_get_block(inode->i_sb,
> block + i);
> if (unlikely(!tbh))
> continue;
> ext4_forget(handle, flags & EXT4_FREE_BLOCKS_METADATA,
> inode, tbh, block + i);
> }
> }
> }
>
> I notice that ext4_forget mainly do two things:
> a) call jbd2_journa_forget to forget the modification of some buffer head
> b) or deal with the revoke issue
> however, if we are freeing data blocks && ext4_forget get into branch a),
Simple. we don't pass the FORGET flag when freeing data blocks,
only when freeing metadata blocks, which may have been journalled
already.
I am not sure about the journal=data case through.
> tbh is not the buffer_head which journal took care of in ext4_write_begin,
> so i'm puzzled with this.
>
> Could anyone explain it to me? Thanks.
>
> --
> Ding Dinghua
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: Is this a bug?
2011-04-02 16:32 ` Amir Goldstein
@ 2011-04-03 9:24 ` Ding Dinghua
2011-04-03 14:51 ` Yongqiang Yang
0 siblings, 1 reply; 41+ messages in thread
From: Ding Dinghua @ 2011-04-03 9:24 UTC (permalink / raw)
To: Amir Goldstein; +Cc: linux-ext4
2011/4/3 Amir Goldstein <amir73il@gmail.com>:
> On Sat, Apr 2, 2011 at 1:05 AM, Ding Dinghua <dingdinghua85@gmail.com> wrote:
>> When truncate files and free blocks, the following codes make me puzzled:
>>
>> void ext4_free_blocks(handle_t *handle, struct inode *inode,
>> struct buffer_head *bh, ext4_fsblk_t block,
>> unsigned long count, int flags)
>> {
>> if (flags & EXT4_FREE_BLOCKS_FORGET) {
>> struct buffer_head *tbh = bh;
>> int i;
>>
>> BUG_ON(bh && (count > 1));
>>
>> for (i = 0; i < count; i++) {
>> if (!bh)
>> tbh = sb_find_get_block(inode->i_sb,
>> block + i);
>> if (unlikely(!tbh))
>> continue;
>> ext4_forget(handle, flags & EXT4_FREE_BLOCKS_METADATA,
>> inode, tbh, block + i);
>> }
>> }
>> }
>>
>> I notice that ext4_forget mainly do two things:
>> a) call jbd2_journa_forget to forget the modification of some buffer head
>> b) or deal with the revoke issue
>> however, if we are freeing data blocks && ext4_forget get into branch a),
>
> Simple. we don't pass the FORGET flag when freeing data blocks,
> only when freeing metadata blocks, which may have been journalled
> already.
> I am not sure about the journal=data case through.
Thanks for reply. The reason for me to dip into this issue is journal=data mode.
>
>> tbh is not the buffer_head which journal took care of in ext4_write_begin,
>> so i'm puzzled with this.
>>
>> Could anyone explain it to me? Thanks.
>>
>> --
>> Ding Dinghua
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
--
Ding Dinghua
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: Is this a bug?
2011-04-03 9:24 ` Ding Dinghua
@ 2011-04-03 14:51 ` Yongqiang Yang
2011-04-03 15:44 ` Amir Goldstein
0 siblings, 1 reply; 41+ messages in thread
From: Yongqiang Yang @ 2011-04-03 14:51 UTC (permalink / raw)
To: Ding Dinghua; +Cc: Amir Goldstein, linux-ext4
On Sun, Apr 3, 2011 at 5:24 PM, Ding Dinghua <dingdinghua85@gmail.com> wrote:
> 2011/4/3 Amir Goldstein <amir73il@gmail.com>:
>> On Sat, Apr 2, 2011 at 1:05 AM, Ding Dinghua <dingdinghua85@gmail.com> wrote:
>>> When truncate files and free blocks, the following codes make me puzzled:
>>>
>>> void ext4_free_blocks(handle_t *handle, struct inode *inode,
>>> struct buffer_head *bh, ext4_fsblk_t block,
>>> unsigned long count, int flags)
>>> {
>>> if (flags & EXT4_FREE_BLOCKS_FORGET) {
>>> struct buffer_head *tbh = bh;
>>> int i;
>>>
>>> BUG_ON(bh && (count > 1));
>>>
>>> for (i = 0; i < count; i++) {
>>> if (!bh)
>>> tbh = sb_find_get_block(inode->i_sb,
>>> block + i);
>>> if (unlikely(!tbh))
>>> continue;
>>> ext4_forget(handle, flags & EXT4_FREE_BLOCKS_METADATA,
>>> inode, tbh, block + i);
>>> }
>>> }
>>> }
>>>
>>> I notice that ext4_forget mainly do two things:
>>> a) call jbd2_journa_forget to forget the modification of some buffer head
>>> b) or deal with the revoke issue
>>> however, if we are freeing data blocks && ext4_forget get into branch a),
>>
>> Simple. we don't pass the FORGET flag when freeing data blocks,
>> only when freeing metadata blocks, which may have been journalled
>> already.
>> I am not sure about the journal=data case through.
> Thanks for reply. The reason for me to dip into this issue is journal=data mode.
I think data processing in journal=data mode is similar to metadata
processing in joutnal=ordered mode.
>>
>>> tbh is not the buffer_head which journal took care of in ext4_write_begin,
>>> so i'm puzzled with this.
>>>
>>> Could anyone explain it to me? Thanks.
>>>
>>> --
>>> Ding Dinghua
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>
>
>
> --
> Ding Dinghua
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Best Wishes
Yongqiang Yang
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: Is this a bug?
2011-04-03 14:51 ` Yongqiang Yang
@ 2011-04-03 15:44 ` Amir Goldstein
0 siblings, 0 replies; 41+ messages in thread
From: Amir Goldstein @ 2011-04-03 15:44 UTC (permalink / raw)
To: Ding Dinghua; +Cc: Yongqiang Yang, Ext4 Developers List
On Sun, Apr 3, 2011 at 7:51 AM, Yongqiang Yang <xiaoqiangnk@gmail.com> wrote:
> On Sun, Apr 3, 2011 at 5:24 PM, Ding Dinghua <dingdinghua85@gmail.com> wrote:
>> 2011/4/3 Amir Goldstein <amir73il@gmail.com>:
>>> On Sat, Apr 2, 2011 at 1:05 AM, Ding Dinghua <dingdinghua85@gmail.com> wrote:
>>>> When truncate files and free blocks, the following codes make me puzzled:
>>>>
>>>> void ext4_free_blocks(handle_t *handle, struct inode *inode,
>>>> struct buffer_head *bh, ext4_fsblk_t block,
>>>> unsigned long count, int flags)
>>>> {
>>>> if (flags & EXT4_FREE_BLOCKS_FORGET) {
>>>> struct buffer_head *tbh = bh;
>>>> int i;
>>>>
>>>> BUG_ON(bh && (count > 1));
>>>>
>>>> for (i = 0; i < count; i++) {
>>>> if (!bh)
>>>> tbh = sb_find_get_block(inode->i_sb,
>>>> block + i);
>>>> if (unlikely(!tbh))
>>>> continue;
>>>> ext4_forget(handle, flags & EXT4_FREE_BLOCKS_METADATA,
>>>> inode, tbh, block + i);
>>>> }
>>>> }
>>>> }
>>>>
>>>> I notice that ext4_forget mainly do two things:
>>>> a) call jbd2_journa_forget to forget the modification of some buffer head
>>>> b) or deal with the revoke issue
>>>> however, if we are freeing data blocks && ext4_forget get into branch a),
>>>
>>> Simple. we don't pass the FORGET flag when freeing data blocks,
>>> only when freeing metadata blocks, which may have been journalled
>>> already.
>>> I am not sure about the journal=data case through.
>> Thanks for reply. The reason for me to dip into this issue is journal=data mode.
> I think data processing in journal=data mode is similar to metadata
> processing in joutnal=ordered mode.
not exactly. Ding is right to be puzzled, because journal=data
journals inode page cache buffers and not block device buffers, like
metadata.
However, I think what happens is that prior to ext4_clear_blocks, which
invokes ext4_free_blocks with the FORGET flag, ext4_invalidatepage
will have been called already and forget about data buffers which were modified
in the current running transaction.
ext4_free_blocks will then handle revoke of data blocks which were modified in
previous transaction. for example, in orphan cleanup, ext4_free_blocks will be
will be called from ext4_truncate, but there will be no pages to invalidate.
this is my guess. I haven't studied this case thoroughly.
>>>
>>>> tbh is not the buffer_head which journal took care of in ext4_write_begin,
>>>> so i'm puzzled with this.
>>>>
>>>> Could anyone explain it to me? Thanks.
>>>>
>>>> --
>>>> Ding Dinghua
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>
>>
>>
>> --
>> Ding Dinghua
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
>
> --
> Best Wishes
> Yongqiang Yang
>
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 41+ messages in thread
* is this a bug?
@ 2011-03-24 0:46 Jay
2011-03-25 15:18 ` Steven Rostedt
0 siblings, 1 reply; 41+ messages in thread
From: Jay @ 2011-03-24 0:46 UTC (permalink / raw)
To: linux-kernel
Hi,
Assuming vmscan is doing its job to steal the last page from an
inode's namespace, so:
shrink_page_list -> remove_mapping -> __remove_from_page_cache:
void __remove_from_page_cache(struct page *page)
{
...
radix_tree_delete(&mapping->page_tree, page->index);
page->mapping = NULL;
>>> after removing the page from radix tree, it stuck at here.
mapping->nrpages--;
...
}
then another process just calls iput_final to release the inode, so
iput_final -> evict:
static void evict(struct inode *inode)
{
...
} else {
if (inode->i_data.nrpages)
>>> here it finds that nrpage is 1, so go into truncate_inode_pages() but it won't find any page in the page tree.
truncate_inode_pages(&inode->i_data, 0);
>>> here nrpages remains 1.
end_writeback(inode);
>>> hit BUG_ON(inode->i_data.nrpages) in end_writeback().
}
...
}
The root cause of this problem is that nrpages is accessed w/o holding
mapping->page_tree. The fix is also easy, just grab ->tree_lock inside
truncate_inode_pages_range:
+ spin_lock_irq(&mapping->tree_lock);
- if (mapping->nrpages == 0)
+ if (mapping->nrpages == 0) {
+ spin_unlock_irq(&mapping->tree_lock);
return;
+ }
+ spin_unlock_irq(&mapping->tree_lock);
Am I missed anything?
Thanks
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: is this a bug?
2011-03-24 0:46 is " Jay
@ 2011-03-25 15:18 ` Steven Rostedt
0 siblings, 0 replies; 41+ messages in thread
From: Steven Rostedt @ 2011-03-25 15:18 UTC (permalink / raw)
To: Jay; +Cc: linux-kernel
Strange mail client you have.
On Wed, Mar 23, 2011 at 05:46:56PM -0700, Jay wrote:
> Hi,
>
> Assuming vmscan is doing its job to steal the last page from an
> inode's namespace, so:
>
> shrink_page_list -> remove_mapping -> __remove_from_page_cache:
>
> void __remove_from_page_cache(struct page *page)
>
> {
>
> ...
>
> radix_tree_delete(&mapping->page_tree, page->index);
>
> page->mapping = NULL;
>
> >>> after removing the page from radix tree, it stuck at here.
>
> mapping->nrpages--;
>
> ...
>
> }
>
> then another process just calls iput_final to release the inode, so
> iput_final -> evict:
>
> static void evict(struct inode *inode)
>
> {
>
> ...
>
> } else {
>
> if (inode->i_data.nrpages)
>
> >>> here it finds that nrpage is 1, so go into truncate_inode_pages() but it won't find any page in the page tree.
>
> truncate_inode_pages(&inode->i_data, 0);
>
> >>> here nrpages remains 1.
>
> end_writeback(inode);
>
> >>> hit BUG_ON(inode->i_data.nrpages) in end_writeback().
Did you actually hit this bug?
>
> }
>
> ...
>
> }
>
> The root cause of this problem is that nrpages is accessed w/o holding
> mapping->page_tree. The fix is also easy, just grab ->tree_lock inside
> truncate_inode_pages_range:
>
> + spin_lock_irq(&mapping->tree_lock);
>
> - if (mapping->nrpages == 0)
>
> + if (mapping->nrpages == 0) {
>
> + spin_unlock_irq(&mapping->tree_lock);
>
> return;
>
> + }
>
> + spin_unlock_irq(&mapping->tree_lock);
>
> Am I missed anything?
Perhaps the comment before the __remove_from_page_cache()
/*
* Remove a page from the page cache and free it. Caller has to make
* sure the page is locked and that nobody else uses it - or that usage
* is safe. The caller must hold the mapping's tree_lock.
*/
-- Steve
^ permalink raw reply [flat|nested] 41+ messages in thread
* is this a bug ?
@ 2005-08-20 0:14 Ashwin Chaugule
2005-08-19 13:19 ` Thomas Gleixner
0 siblings, 1 reply; 41+ messages in thread
From: Ashwin Chaugule @ 2005-08-20 0:14 UTC (permalink / raw)
To: linux-mtd
Hi,
Im using 2.4.19-rmk7-pxa1, on a pxa255. Recently I mounted jffs2
as rootfs. While doing this the conventional way, I found that
it was being mounted readonly. Since I'm using M28W640 (ST flash) which
needs to be unlocked upon every reboot, I thought the readonly
was because of this locking thing. So, I integrated the flash_unlock
code into the mtd subsystem, but I still got the readonly mount.
After digging into init/do_mounts.c , I found root_mountflags was by
default readonly, and is sent to mount_block_root("/dev/root",
root_mountflags); only to be later reassigned somewhere in fs/super.c !
(s->s_flags = flags;)
The following addition to do_mounts.c , did the trick.
+ root_mountflags &= ~MS_RDONLY;
mount_block_root("/dev/root", root_mountflags);
Now jffs2 mounts nice and clean, with readwrite !
I know you guys have dropped support for 2.4.x, but just for
clarification, might even help several others struggling to get jffs2
working as rootfs :)
Cheers,
Ashwin Chaugule
Embedded Systems Engineer
Aftek Infosys Ltd.
[Embedded Division]
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: is this a bug ?
2005-08-20 0:14 is this a bug ? Ashwin Chaugule
@ 2005-08-19 13:19 ` Thomas Gleixner
2005-08-20 1:36 ` Ashwin Chaugule
0 siblings, 1 reply; 41+ messages in thread
From: Thomas Gleixner @ 2005-08-19 13:19 UTC (permalink / raw)
To: Ashwin Chaugule; +Cc: linux-mtd
On Sat, 2005-08-20 at 05:44 +0530, Ashwin Chaugule wrote:
> The following addition to do_mounts.c , did the trick.
>
> + root_mountflags &= ~MS_RDONLY;
> mount_block_root("/dev/root", root_mountflags);
Uurg. RTFM !
There are at least two sane ways to do that without touching the kernel
code.
- Documentation/kernel-parameters.txt (hint: rootflags)
- man mount (hint: remount)
tglx
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: is this a bug ?
2005-08-19 13:19 ` Thomas Gleixner
@ 2005-08-20 1:36 ` Ashwin Chaugule
2005-08-19 18:25 ` Thomas Gleixner
0 siblings, 1 reply; 41+ messages in thread
From: Ashwin Chaugule @ 2005-08-20 1:36 UTC (permalink / raw)
To: tglx, linux-mtd
Thomas Gleixner wrote:
>Uurg. RTFM !
>
>There are at least two sane ways to do that without touching the kernel
>code.
>
>- Documentation/kernel-parameters.txt (hint: rootflags)
>
>
In 2.6.12-2 my cmdline is ..
CONFIG_CMDLINE="root=/dev/mtdblock1 rootfstype=jffs2 init=/bin/sh console=ttyS0,38400 mem=32M"
Jffs2 mounts just fine. No rootflags changes anywhere !
Cheers,
Ashwin
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: is this a bug ?
2005-08-20 1:36 ` Ashwin Chaugule
@ 2005-08-19 18:25 ` Thomas Gleixner
2005-08-19 19:31 ` ashwinc
0 siblings, 1 reply; 41+ messages in thread
From: Thomas Gleixner @ 2005-08-19 18:25 UTC (permalink / raw)
To: Ashwin Chaugule; +Cc: linux-mtd
On Sat, 2005-08-20 at 07:06 +0530, Ashwin Chaugule wrote:
> >
> In 2.6.12-2 my cmdline is ..
>From your previous mail
> Im using 2.4.19-rmk7-pxa1, on a pxa255. .....
>
> After digging into init/do_mounts.c , I found root_mountflags was by
> default readonly,
So what ? You were asking a question about 2.4.19 and you got an answer
related to that. It's coded that way in the ancient, broken and obsolete
2.4.19... kernel and there are two ways to solve that without hacking
the kernel code.
Where is the bug ?
tglx
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: is this a bug ?
2005-08-19 18:25 ` Thomas Gleixner
@ 2005-08-19 19:31 ` ashwinc
0 siblings, 0 replies; 41+ messages in thread
From: ashwinc @ 2005-08-19 19:31 UTC (permalink / raw)
To: tglx; +Cc: linux-mtd
> So what ? You were asking a question about 2.4.19 and you got an answer
> related to that. It's coded that way in the ancient, broken and obsolete
> 2.4.19...
Couldnt agree more. But the deadlines prohibit us from upgrading it right
now. In fact I have already fired up the board with 2.6.12-2 as stated
earlier, but theres still a while till I get everything we have running on
it.
>
> Where is the bug ?
Well, the fact that it works without any changes in 2.6.x, and that I had
to change it in 2.4. Basically, it seemed strange that rootflags is just
passed in from do_mount, remains unchanged, and later reassigned to
sb->flags in super.c.... seemed strange thats all. BTW I still need to
find out whats done differently in 2.6.x. I'm not implying this is a jffs2
bug anywhere, I just posted this to see if anyone else observed this,
since there are several others still using 2.4.19. Also, I didnt know of
the cmdline way of doing this without hacking into the source. Call me a
rookie if you want.
Well, now I know :)
Cheers,
Ashwin
**************************Disclaimer************************************
Information contained in this E-MAIL being proprietary to Aftek Infosys Limited
is 'privileged' and 'confidential' and intended for use only by the individual
or entity to which it is addressed. You are notified that any use, copying
or dissemination of the information contained in the E-MAIL in any manner
whatsoever is strictly prohibited.
***************************************************************************
http://www.aftek.com/
^ permalink raw reply [flat|nested] 41+ messages in thread
* Is this a bug?
@ 2002-07-15 13:57 Tisserand Patrice
2002-07-15 14:08 ` Takashi Iwai
0 siblings, 1 reply; 41+ messages in thread
From: Tisserand Patrice @ 2002-07-15 13:57 UTC (permalink / raw)
To: alsa-devel
Hi,
I wasn't enable to get poll descriptors for a sequencer opened for
output only,
so I checked alsa-lib/seq/seq.c and found on line 320 in function
snd_seq_poll_descriptors:
if ((events & POLLOUT) && space >= 1) {
assert(seq->streams & SND_SEQ_OPEN_INPUT);
revents |= POLLOUT|POLLERR;
}
Shouldn't it read: assert(seq->streams & SND_SEQ_OPEN_OUTPUT); ?
Regards,
--
Patrice Tisserand --- email:mailto:Patrice.Tisserand@ircam.fr
IRCAM 1 place Stravinsky 75004 Paris FRANCE
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: Is this a bug?
2002-07-15 13:57 Is this a bug? Tisserand Patrice
@ 2002-07-15 14:08 ` Takashi Iwai
0 siblings, 0 replies; 41+ messages in thread
From: Takashi Iwai @ 2002-07-15 14:08 UTC (permalink / raw)
To: Tisserand Patrice; +Cc: alsa-devel
At Mon, 15 Jul 2002 15:57:35 +0200,
Tisserand Patrice wrote:
>
> Hi,
>
> I wasn't enable to get poll descriptors for a sequencer opened for
> output only,
> so I checked alsa-lib/seq/seq.c and found on line 320 in function
> snd_seq_poll_descriptors:
>
> if ((events & POLLOUT) && space >= 1) {
> assert(seq->streams & SND_SEQ_OPEN_INPUT);
> revents |= POLLOUT|POLLERR;
> }
>
> Shouldn't it read: assert(seq->streams & SND_SEQ_OPEN_OUTPUT); ?
yep, an obvious typo. now fixed on cvs.
thanks,
Takashi
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
^ permalink raw reply [flat|nested] 41+ messages in thread
* is this a bug?
@ 2001-08-07 11:51 Thodoris Pitikaris
2001-08-07 13:51 ` Andrzej Krzysztofowicz
` (2 more replies)
0 siblings, 3 replies; 41+ messages in thread
From: Thodoris Pitikaris @ 2001-08-07 11:51 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 357 bytes --]
As you will see in the attached file (it's a dmesg from the boot)
I have an 1Ghz athlon cpu with a VIA KT133 on a gigabyte GA-7ZX
motherboard with 100mhz SDRAM.When I compiled the kernel with
cputype=Athlon I continiusly experienced this crash.When I compiled with
cputype=i686 everything went smooth (OS is Redhat 7.1)
Yours
Theodore Pitikaris
[-- Attachment #2: 1 --]
[-- Type: text/plain, Size: 9274 bytes --]
Linux version 2.4.8-pre4 (root@feidias.kerkyra.gr) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81)) #1 Ôñé Áýã 7 13:28:12 EEST 2001
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000000bff0000 (usable)
BIOS-e820: 000000000bff0000 - 000000000bff8000 (ACPI data)
BIOS-e820: 000000000bff8000 - 000000000c000000 (ACPI NVS)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
On node 0 totalpages: 49136
zone(0): 4096 pages.
zone(1): 45040 pages.
zone(2): 0 pages.
Kernel command line: auto BOOT_IMAGE=new ro root=306 BOOT_FILE=/boot/2.4.8 lba32
Initializing CPU#0
Detected 1002.302 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1998.84 BogoMIPS
Memory: 191352k/196544k available (834k kernel code, 4804k reserved, 286k data, 188k init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
CPU: Before vendor init, caps: 0183f9ff c1c7f9ff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU: After generic, caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU: Common caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU: AMD Athlon(tm) Processor stepping 02
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfdb71, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router VIA [1106/0686] at 00:07.0
Applying VIA PCI latency patch (found VT82C686B).
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
block: 128 slots per queue, batch=16
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:DMA
hda: QUANTUM FIREBALLlct08 17, ATA DISK drive
hdb: ST39140A, ATA DISK drive
hdc: ASUS DVD-ROM E608, ATAPI CD/DVD-ROM drive
hdd: SONY CDU4811, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 33906432 sectors (17360 MB) w/418KiB Cache, CHS=2110/255/63, UDMA(33)
hdb: 17803440 sectors (9115 MB) w/448KiB Cache, CHS=1108/255/63, UDMA(33)
hdc: ATAPI 40X DVD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
hdd: ATAPI 48X CD-ROM drive, 120kB Cache, UDMA(33)
Partition check:
hda: hda1 hda2 < hda5 hda6 >
hdb: hdb1
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
loop: loaded (max 8 devices)
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 149M
agpgart: Detected Via Apollo Pro KT133 chipset
agpgart: AGP aperture is 64M @ 0xe0000000
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 188k freed
Adding Swap: 248968k swap-space (priority -1)
memory.c:83: bad pmd c5e77b40.
memory.c:83: bad pmd c5e5e000.
memory.c:83: bad pmd c020ac74.
memory.c:83: bad pmd c117f59c.
memory.c:83: bad pmd c020ac98.
memory.c:83: bad pmd 00000001.
memory.c:83: bad pmd 00000002.
kernel BUG at page_alloc.c:73!
invalid operand: 0000
CPU: 0
EIP: 0010:[<c0129603>]
EFLAGS: 00010282
eax: 0000001f ebx: c1324048 ecx: 00000001 edx: c02099e4
esi: c1324048 edi: 00000000 ebp: c675e1d8 esp: cbc2de7c
ds: 0018 es: 0018 ss: 0018
Process ifup-aliases (pid: 161, stackpage=cbc2d000)
Stack: c01d98a6 c01d997a 00000049 c01cbf4f c11b0ac8 c117f844 c011fc7c c65ce000
c1324048 c1324048 00048000 c675e1d8 c012a535 4015dcbc ffffffff 00000001
c13cd440 c1324048 0000004a c011ef04 c1324048 0000002c 00000000 000c0000
Call Trace: [<c01cbf4f>] [<c011fc7c>] [<c012a535>] [<c011ef04>] [<c010fd50>] [<c010fec6>] [<c0121638>]
[<c01385ba>] [<c0111a66>] [<c0115832>] [<c01109a4>] [<c010fd50>] [<c0106ecb>]
Code: 0f 0b 83 c4 0c 8b 46 08 85 c0 74 16 6a 4b 68 7a 99 1d c0 68
kernel BUG at page_alloc.c:73!
invalid operand: 0000
CPU: 0
EIP: 0010:[<c0129603>]
EFLAGS: 00010282
eax: 0000001f ebx: c1324048 ecx: 00000001 edx: c02099e4
esi: c1324048 edi: 00000000 ebp: c66fb1d8 esp: cbc2de7c
ds: 0018 es: 0018 ss: 0018
Process ifup-aliases (pid: 163, stackpage=cbc2d000)
Stack: c01d98a6 c01d997a 00000049 c01cbf4f c11d34e0 c117f844 c011fc7c c6df4000
c1324048 c1324048 00048000 c66fb1d8 c012a535 4015dcbc ffffffff 00000001
c13cd380 c1324048 0000004a c011ef04 c1324048 0000002c 00000000 000c0000
Call Trace: [<c01cbf4f>] [<c011fc7c>] [<c012a535>] [<c011ef04>] [<c010fd50>] [<c010fec6>] [<c0121638>]
[<c01385ba>] [<c0111a66>] [<c0115832>] [<c01109a4>] [<c010fd50>] [<c0106ecb>]
Code: 0f 0b 83 c4 0c 8b 46 08 85 c0 74 16 6a 4b 68 7a 99 1d c0 68
kernel BUG at page_alloc.c:73!
invalid operand: 0000
CPU: 0
EIP: 0010:[<c0129603>]
EFLAGS: 00010286
eax: 0000001f ebx: c1324048 ecx: 00000001 edx: c02099e4
esi: c1324048 edi: 00000000 ebp: c6f511d8 esp: c4ab5b80
ds: 0018 es: 0018 ss: 0018
Process ifup-post (pid: 170, stackpage=c4ab5000)
Stack: c01d98a6 c01d997a 00000049 c4ab5c88 cbfe56c0 c01398ac cbfe55c0 00000001
c1324048 c1324048 00048000 c6f511d8 c012a535 08054b88 00000001 40016000
c4ab4000 c1324048 0000004a c011ef04 c1324048 0000002c 00000000 000c0000
Call Trace: [<c01398ac>] [<c012a535>] [<c011ef04>] [<c0142cba>] [<c0122c43>] [<c0121638>] [<c0122d10>]
[<c01375a3>] [<c0137710>] [<c01454ff>] [<c01c5507>] [<c01450c0>] [<c0137c6f>] [<c0137efb>] [<c0138dad>]
[<c0105b4d>] [<c0106ecb>]
Code: 0f 0b 83 c4 0c 8b 46 08 85 c0 74 16 6a 4b 68 7a 99 1d c0 68
exit_mmap: map count is 25
PCI: Found IRQ 10 for device 00:0d.0
3c59x.c:LK1.1.15 6 June 2001 Donald Becker and others. http://www.scyld.com/network/vortex.html
See Documentation/networking/vortex.txt
00:0d.0: 3Com PCI 3c905 Boomerang 100baseTx at 0xd400, 00:60:08:7e:13:4b, IRQ 10
product code 4b4b rev 00.0 date 01-25-98
8K word-wide RAM 3:5 Rx:Tx split, autoselect/MII interface.
MII transceiver found at address 24, status 786f.
Enabling bus-master transmits and whole-frame receives.
00:0d.0: scatter/gather enabled. h/w checksums disabled
eth0: first available media type: MII
kernel BUG at page_alloc.c:73!
invalid operand: 0000
CPU: 0
EIP: 0010:[<c0129603>]
EFLAGS: 00010286
eax: 0000001f ebx: c1324048 ecx: 00000001 edx: c02099e4
esi: c1324048 edi: 00000000 ebp: c609a1d8 esp: cbbafb80
ds: 0018 es: 0018 ss: 0018
Process S10network (pid: 256, stackpage=cbbaf000)
Stack: c01d98a6 c01d997a 00000049 cbbafc88 cbfe56c0 c01398ac cbfe55c0 00000001
c1324048 c1324048 00048000 c609a1d8 c012a535 cbbae000 080c5dd4 c0144a2c
080c5dd4 c1324048 0000004a c011ef04 c1324048 0000002c 00000000 000c0000
Call Trace: [<c01398ac>] [<c012a535>] [<c0144a2c>] [<c011ef04>] [<c0142cba>] [<c0122c43>] [<c0121638>]
[<c0122d10>] [<c01375a3>] [<c0137710>] [<c01454ff>] [<c0137caf>] [<c01450c0>] [<c0137c6f>] [<c0137efb>]
[<c0138dad>] [<c0105b4d>] [<c0106ecb>]
Code: 0f 0b 83 c4 0c 8b 46 08 85 c0 74 16 6a 4b 68 7a 99 1d c0 68
exit_mmap: map count is 25
kernel BUG at page_alloc.c:168!
invalid operand: 0000
CPU: 0
EIP: 0010:[<c0129a84>]
EFLAGS: 00010082
eax: 00000020 ebx: c11600a4 ecx: 00000001 edx: c02099e4
esi: c020ac98 edi: 00000001 ebp: 00000000 esp: c9f97e54
ds: 0018 es: 0018 ss: 0018
Process S85gpm (pid: 365, stackpage=c9f97000)
Stack: c01d98a6 c01d997a 000000a8 000042d5 00000286 00000000 c020ac74 c020ac74
c020ae00 00000000 000000d2 c0129c74 00000001 c020adfc bfffefe0 c1312168
0b8f6065 c13cda40 c011fc41 c020ac74 c020ac74 c020ade0 00000000 bfffefe0
Call Trace: [<c0129c74>] [<c011fc41>] [<c01202f0>] [<c01cbe3d>] [<c010fd50>] [<c010fec6>] [<c0111d4a>]
[<c0112757>] [<c012ef22>] [<c010fd50>] [<c0106fbc>]
Code: 0f 0b 83 c4 0c ff 74 24 04 9d c7 43 14 01 00 00 00 8b 44 24
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: is this a bug?
2001-08-07 11:51 is " Thodoris Pitikaris
@ 2001-08-07 13:51 ` Andrzej Krzysztofowicz
2001-08-08 2:19 ` Dr. Kelsey Hudson
2001-08-08 16:51 ` jury gerold
2 siblings, 0 replies; 41+ messages in thread
From: Andrzej Krzysztofowicz @ 2001-08-07 13:51 UTC (permalink / raw)
To: Thodoris Pitikaris; +Cc: linux-kernel
"Thodoris Pitikaris wrote:"
> As you will see in the attached file (it's a dmesg from the boot)
> I have an 1Ghz athlon cpu with a VIA KT133 on a gigabyte GA-7ZX
> motherboard with 100mhz SDRAM.When I compiled the kernel with
> cputype=Athlon I continiusly experienced this crash.When I compiled with
> cputype=i686 everything went smooth (OS is Redhat 7.1)
Try the newest -ac patches. They contain discussed on the list workaround
for a VIA chipset bug.
VIA chipsets seem to be unstable when processing fast memory-to-memory
copy.
It is definitely not an Athlon processor problem.
Andrzej
--
=======================================================================
Andrzej M. Krzysztofowicz ankry@mif.pg.gda.pl
phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math., Technical University of Gdansk
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: is this a bug?
2001-08-07 11:51 is " Thodoris Pitikaris
2001-08-07 13:51 ` Andrzej Krzysztofowicz
@ 2001-08-08 2:19 ` Dr. Kelsey Hudson
2001-08-08 3:15 ` J Sloan
` (2 more replies)
2001-08-08 16:51 ` jury gerold
2 siblings, 3 replies; 41+ messages in thread
From: Dr. Kelsey Hudson @ 2001-08-08 2:19 UTC (permalink / raw)
To: Thodoris Pitikaris; +Cc: linux-kernel
On Tue, 7 Aug 2001, Thodoris Pitikaris wrote:
> As you will see in the attached file (it's a dmesg from the boot)
> I have an 1Ghz athlon cpu with a VIA KT133 on a gigabyte GA-7ZX
> motherboard with 100mhz SDRAM.When I compiled the kernel with
> cputype=Athlon I continiusly experienced this crash.When I compiled with
> cputype=i686 everything went smooth (OS is Redhat 7.1)
It's a bug in that screwed up compiler redhat shipped with 7.1. AFAIK, the
only difference between an athlon-specific kernel and an i686-specific
kernel are the options in the compiler command line when compiling the
kernel.
Is gcc 3.0 binary compatible with the stupid redhat compiler? If it is, I
would upgrade to that. I haven't, myself, because I simply don't know (and
can't find any information one way or the other) if binaries from the two
compilers are compatible. Someone who knows better, could you shed some
light on the subject?
Kelsey Hudson khudson@ctica.com
Software Engineer
Compendium Technologies, Inc (619) 725-0771
---------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: is this a bug?
2001-08-08 2:19 ` Dr. Kelsey Hudson
@ 2001-08-08 3:15 ` J Sloan
2001-08-08 3:45 ` Dr. Kelsey Hudson
2001-08-08 11:05 ` Alan Cox
2001-08-08 12:59 ` Ron Flory
2 siblings, 1 reply; 41+ messages in thread
From: J Sloan @ 2001-08-08 3:15 UTC (permalink / raw)
To: Dr. Kelsey Hudson; +Cc: Thodoris Pitikaris, linux-kernel
"Dr. Kelsey Hudson" wrote:
> It's a bug in that screwed up compiler redhat shipped with 7.1.
Oh please, not this FUD again.....
jjs
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: is this a bug?
2001-08-08 3:15 ` J Sloan
@ 2001-08-08 3:45 ` Dr. Kelsey Hudson
2001-08-08 10:53 ` David Weinehall
0 siblings, 1 reply; 41+ messages in thread
From: Dr. Kelsey Hudson @ 2001-08-08 3:45 UTC (permalink / raw)
To: linux-kernel
On Tue, 7 Aug 2001, J Sloan wrote:
> "Dr. Kelsey Hudson" wrote:
> > It's a bug in that screwed up compiler redhat shipped with 7.1.
> Oh please, not this FUD again.....
Call it what you wish -- But, if I see something break when using a
certain compiler option versus another compiler option that does not
cause a break, chances are it's a bug in the compiler. After all, the
Athlon support *is* a new feature, is it not?
I don't even know why I bothered replying. Don't feed the trolls... Gotta
watch for those signs....
Kelsey Hudson khudson@ctica.com
Software Engineer
Compendium Technologies, Inc (619) 725-0771
---------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: is this a bug?
2001-08-08 3:45 ` Dr. Kelsey Hudson
@ 2001-08-08 10:53 ` David Weinehall
0 siblings, 0 replies; 41+ messages in thread
From: David Weinehall @ 2001-08-08 10:53 UTC (permalink / raw)
To: Dr. Kelsey Hudson; +Cc: linux-kernel
On Tue, Aug 07, 2001 at 08:45:15PM -0700, Dr. Kelsey Hudson wrote:
> On Tue, 7 Aug 2001, J Sloan wrote:
>
> > "Dr. Kelsey Hudson" wrote:
>
> > > It's a bug in that screwed up compiler redhat shipped with 7.1.
>
> > Oh please, not this FUD again.....
>
> Call it what you wish -- But, if I see something break when using a
> certain compiler option versus another compiler option that does not
> cause a break, chances are it's a bug in the compiler. After all, the
> Athlon support *is* a new feature, is it not?
>
> I don't even know why I bothered replying. Don't feed the trolls... Gotta
> watch for those signs....
Ah, but if you'd been observant you'd have noticed what kind of motherboard
he has (a VIA) and if you have been reading your kernel-list lately,
you'd have known that almost noone has been able to get a Athlon-optimized
kernel to work in a stable manner on those; probably because of the
Athlon-optimizations stressing the hardware too much.
I'd say flakey hardware is the problem here, not the compiler.
/David Weinehall
_ _
// David Weinehall <tao@acc.umu.se> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: is this a bug?
2001-08-08 2:19 ` Dr. Kelsey Hudson
2001-08-08 3:15 ` J Sloan
@ 2001-08-08 11:05 ` Alan Cox
2001-08-08 12:59 ` Ron Flory
2 siblings, 0 replies; 41+ messages in thread
From: Alan Cox @ 2001-08-08 11:05 UTC (permalink / raw)
To: Dr. Kelsey Hudson; +Cc: Thodoris Pitikaris, linux-kernel
> > cputype=Athlon I continiusly experienced this crash.When I compiled with
> > cputype=i686 everything went smooth (OS is Redhat 7.1)
>
> It's a bug in that screwed up compiler redhat shipped with 7.1. AFAIK, the
> only difference between an athlon-specific kernel and an i686-specific
> kernel are the options in the compiler command line when compiling the
> kernel.
Please stop deliberately spreading misinformation. The last thing an end
user with a problem needs is a bigot with an axe to grind lying to them to
make a political point.
Its the classic 'bought the wrong VIA chipset mainboard' problem
Alan
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: is this a bug?
2001-08-08 2:19 ` Dr. Kelsey Hudson
2001-08-08 3:15 ` J Sloan
2001-08-08 11:05 ` Alan Cox
@ 2001-08-08 12:59 ` Ron Flory
2 siblings, 0 replies; 41+ messages in thread
From: Ron Flory @ 2001-08-08 12:59 UTC (permalink / raw)
To: Dr. Kelsey Hudson; +Cc: linux-kernel
"Dr. Kelsey Hudson" wrote:
>
> On Tue, 7 Aug 2001, Thodoris Pitikaris wrote:
>
> > As you will see in the attached file (it's a dmesg from the boot)
> > I have an 1Ghz athlon cpu with a VIA KT133 on a gigabyte GA-7ZX
> > motherboard with 100mhz SDRAM.When I compiled the kernel with
> > cputype=Athlon I continiusly experienced this crash.When I compiled with
> > cputype=i686 everything went smooth (OS is Redhat 7.1)
>
> It's a bug in that screwed up compiler redhat shipped with 7.1. AFAIK, the
> only difference between an athlon-specific kernel and an i686-specific
> kernel are the options in the compiler command line when compiling the
> kernel.
RH has posted updates to many of the gcc-xxx tools, have you installed
the updated compilers and libraries ?
ron
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: is this a bug?
2001-08-07 11:51 is " Thodoris Pitikaris
2001-08-07 13:51 ` Andrzej Krzysztofowicz
2001-08-08 2:19 ` Dr. Kelsey Hudson
@ 2001-08-08 16:51 ` jury gerold
2001-08-10 9:12 ` Eric W. Biederman
2 siblings, 1 reply; 41+ messages in thread
From: jury gerold @ 2001-08-08 16:51 UTC (permalink / raw)
To: Thodoris Pitikaris; +Cc: linux-kernel
I have the same motherboard, same chipset, same CPU and the same crash.
No memory test cpu burn UDMA on/off, replace or remove of components
did any good.
Then i replaced the 100mhz SDRAM with a 133mhz and it is 100 % stable
since then.
No matter which compiler, kernel version, cputype.
It simply works now.
Gerold
Thodoris Pitikaris wrote:
> As you will see in the attached file (it's a dmesg from the boot)
> I have an 1Ghz athlon cpu with a VIA KT133 on a gigabyte GA-7ZX
> motherboard with 100mhz SDRAM.When I compiled the kernel with
> cputype=Athlon I continiusly experienced this crash.When I compiled
> with cputype=i686 everything went smooth (OS is Redhat 7.1) Yours
>
> Theodore Pitikaris
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: is this a bug?
2001-08-08 16:51 ` jury gerold
@ 2001-08-10 9:12 ` Eric W. Biederman
2001-08-10 12:22 ` jury gerold
0 siblings, 1 reply; 41+ messages in thread
From: Eric W. Biederman @ 2001-08-10 9:12 UTC (permalink / raw)
To: jury gerold; +Cc: Thodoris Pitikaris, linux-kernel
jury gerold <geroldj@grips.com> writes:
> I have the same motherboard, same chipset, same CPU and the same crash.
> No memory test cpu burn UDMA on/off, replace or remove of components
> did any good.
> Then i replaced the 100mhz SDRAM with a 133mhz and it is 100 % stable since
> then.
>
> No matter which compiler, kernel version, cputype.
> It simply works now.
Do you happen to have the SDRAM timings of the two sets of DIMMS?
It would be interesting to see what changed besides the clock speed on
the DIMMS. I'm assuming your PC133 DIMMs are running at at 133Mhz,
and you aren't over clocking anything.
Eric
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: is this a bug?
2001-08-10 9:12 ` Eric W. Biederman
@ 2001-08-10 12:22 ` jury gerold
2001-08-10 16:22 ` Eric W. Biederman
0 siblings, 1 reply; 41+ messages in thread
From: jury gerold @ 2001-08-10 12:22 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Thodoris Pitikaris, linux-kernel
Hi Eric
The CPU is a 1.1GHz tbird 200MHz FSB and i am running it this way.
The motherboard can do 100 and 133 MHz but i run
the SDRAM at 100MHz from the beginning, since i have seen lot's
of boards with memory problems and i wanted to be on the good side.
Both, the old 128MB and the new 256MB SDRAM where sold as PC133.
It is a single DIMM in both cases.
When i started to sue the SDRAM for the trouble i checked the SPD and found
the 128MB-PC133 was actually a PC100 with a few steps towards PC66
(major brand).
So i tried a new one that, at least from the SPD, is a real PC133 and
suddenly ...
I have tried to kill it
kernel 2.4.7-xfs from cvs at the moment
athlon optimisations
UDMA on ide0 and ide1
2 harddrives, 1 cdrom, 1 cd/rw
since then, but it works, works, works.
This weekend does not see me at home.
I will send the timings on sunday/monday.
What do you expect to get out of this ?
Gerold
Eric W. Biederman wrote:
>jury gerold <geroldj@grips.com> writes:
>
>>I have the same motherboard, same chipset, same CPU and the same crash.
>>No memory test cpu burn UDMA on/off, replace or remove of components
>>did any good.
>>Then i replaced the 100mhz SDRAM with a 133mhz and it is 100 % stable since
>>then.
>>
>>No matter which compiler, kernel version, cputype.
>>It simply works now.
>>
>
>Do you happen to have the SDRAM timings of the two sets of DIMMS?
>It would be interesting to see what changed besides the clock speed on
>the DIMMS. I'm assuming your PC133 DIMMs are running at at 133Mhz,
>and you aren't over clocking anything.
>
>Eric
>
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: is this a bug?
2001-08-10 12:22 ` jury gerold
@ 2001-08-10 16:22 ` Eric W. Biederman
0 siblings, 0 replies; 41+ messages in thread
From: Eric W. Biederman @ 2001-08-10 16:22 UTC (permalink / raw)
To: jury gerold; +Cc: Thodoris Pitikaris, linux-kernel
jury gerold <geroldj@grips.com> writes:
> Hi Eric
>
> The CPU is a 1.1GHz tbird 200MHz FSB and i am running it this way.
> The motherboard can do 100 and 133 MHz but i run
> the SDRAM at 100MHz from the beginning, since i have seen lot's
> of boards with memory problems and i wanted to be on the good side.
> Both, the old 128MB and the new 256MB SDRAM where sold as PC133.
> It is a single DIMM in both cases.
>
> When i started to sue the SDRAM for the trouble i checked the SPD and found
> the 128MB-PC133 was actually a PC100 with a few steps towards PC66 (major
> brand).
>
> So i tried a new one that, at least from the SPD, is a real PC133 and suddenly
> ...
>
> I have tried to kill it
>
> kernel 2.4.7-xfs from cvs at the moment
> athlon optimisations
> UDMA on ide0 and ide1
> 2 harddrives, 1 cdrom, 1 cd/rw
>
> since then, but it works, works, works.
>
>
> This weekend does not see me at home.
> I will send the timings on sunday/monday.
>
> What do you expect to get out of this ?
Mostly I am curious about what is going on. I work on linuxBIOS so
(a) I might just have to figure out if there are software work arounds
if/when I port to this platform.
(b) I have written enough memory setup code that does SPD on the fly,
to compute the DIMM timings, that understanding DIMMS and memory
controllers is one of my areas of competence.
If the ram was really PC100 mislabeled, as PC133 and it was being run
at 133Mhz I can see the problem. If it was only being run as PC100
I have a problem seeing, why you would have a problem.
Eric
^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2017-06-21 3:08 UTC | newest]
Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-21 21:57 Is this a Bug? Christian Deussen
2011-06-21 22:49 ` Greg Freemyer
2011-06-22 7:28 ` Wilson Felipe
2011-06-22 19:50 ` julie Sullivan
2011-06-22 21:21 ` julie Sullivan
2011-06-23 12:16 ` Christian D.
2011-06-23 13:03 ` Jonathan Neuschäfer
2011-06-23 18:49 ` Jonathan Neuschäfer
-- strict thread matches above, loose matches on Subject: below --
2017-06-21 3:08 Is this a bug? Peter Teoh
2013-02-19 9:32 David Wade
2013-02-19 9:42 ` Andreas Ericsson
2013-02-19 9:47 ` Erik Faye-Lund
2013-02-19 11:02 ` Duy Nguyen
2013-02-22 19:29 ` Phil Hord
2013-02-22 21:48 ` Junio C Hamano
2011-04-02 8:05 Ding Dinghua
2011-04-02 16:32 ` Amir Goldstein
2011-04-03 9:24 ` Ding Dinghua
2011-04-03 14:51 ` Yongqiang Yang
2011-04-03 15:44 ` Amir Goldstein
2011-03-24 0:46 is " Jay
2011-03-25 15:18 ` Steven Rostedt
2005-08-20 0:14 is this a bug ? Ashwin Chaugule
2005-08-19 13:19 ` Thomas Gleixner
2005-08-20 1:36 ` Ashwin Chaugule
2005-08-19 18:25 ` Thomas Gleixner
2005-08-19 19:31 ` ashwinc
2002-07-15 13:57 Is this a bug? Tisserand Patrice
2002-07-15 14:08 ` Takashi Iwai
2001-08-07 11:51 is " Thodoris Pitikaris
2001-08-07 13:51 ` Andrzej Krzysztofowicz
2001-08-08 2:19 ` Dr. Kelsey Hudson
2001-08-08 3:15 ` J Sloan
2001-08-08 3:45 ` Dr. Kelsey Hudson
2001-08-08 10:53 ` David Weinehall
2001-08-08 11:05 ` Alan Cox
2001-08-08 12:59 ` Ron Flory
2001-08-08 16:51 ` jury gerold
2001-08-10 9:12 ` Eric W. Biederman
2001-08-10 12:22 ` jury gerold
2001-08-10 16:22 ` Eric W. Biederman
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.