Re: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well
Hi, you guys were right, I was wrong. It is the hardware. I increased ram voltage by 0.15V on the 22nd and hadn't any oopses since then. And I did torture the system. I am deeply sorry that I wasted your time (but still puzzled that the oopses started after kernel update - maybe I should buy a new psu... ). So it is not reiser4 nor the kernel, just the ram needs a little more 'juice' than the board delivers on 'auto' settings. Glück Auf Volker -- 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: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well
Hi, you guys were right, I was wrong. It is the hardware. I increased ram voltage by 0.15V on the 22nd and hadn't any oopses since then. And I did torture the system. I am deeply sorry that I wasted your time (but still puzzled that the oopses started after kernel update - maybe I should buy a new psu... ). So it is not reiser4 nor the kernel, just the ram needs a little more 'juice' than the board delivers on 'auto' settings. Glück Auf Volker -- 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: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well
On Freitag, 21. Dezember 2007, Mike Galbraith wrote: > On Thu, 2007-12-20 at 19:14 +0100, Hemmann, Volker Armin wrote: > > It is just.. I could be the hardware - but I should have seen the > > same 'problem' with earlier kernels - and the 'almost daily oops' only > > started with 2.6.23. > > Nonetheless, the oopsen _suggest_ hardware. If it were my box, I'd move > ram modules as a first step. It costs about two minutes to eliminate > that possibility, but you seem reluctant to take that step. Heck, I'd > _hope_ it's something as simple bad ram, because otherwise, quest for > stability could become a time consuming and/or expensive undertaking... > It costs a little bit more, but it will be part of the 'past holiday special'. As an intermediate step I incresed the voltages of the ram - looks good so far. > If that didn't change anything, I'd go back and stress test a previously > stable configuration to gain confidence in my hardware. you mean like playing ut2004 with reduced fans or several instances of cpuburn, or compiling something big like kdepim with kdeenablefinal? Done all that ... > If 'uhoh, not > as stable as I thought' happened, and nothing is getting obviously hot > [1], I'd pray that it's an electrically noisy power supply, because > that's also easy and cheap. yeah, it would be the least annoying variant. After one PSU ate two computers, this one is just two and a half month old - I had my share of bad PSUs. That is why I increased the voltages. Maybe it helps. > In any case, once I was very very confident > that my hardware was indeed sound, I'd move on to an agonizingly tedious > bisection, with no out of tree modules ever loaded, to narrow down when > this memory corruption that nobody else appears to be hitting appeared. > > -Mike > > 1. Crappy heatsink compound can dry out and fracture, leaving hot chip > under a relatively cool heatsink. This is exactly what I found when I > disassembled my suddenly unstable under heavy load P4 box a while back. still this would show up with the temps. And the temps are ok. Glück Auf, Volker -- 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: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well
On Freitag, 21. Dezember 2007, Mike Galbraith wrote: On Thu, 2007-12-20 at 19:14 +0100, Hemmann, Volker Armin wrote: It is just.. I could be the hardware - but I should have seen the same 'problem' with earlier kernels - and the 'almost daily oops' only started with 2.6.23. Nonetheless, the oopsen _suggest_ hardware. If it were my box, I'd move ram modules as a first step. It costs about two minutes to eliminate that possibility, but you seem reluctant to take that step. Heck, I'd _hope_ it's something as simple bad ram, because otherwise, quest for stability could become a time consuming and/or expensive undertaking... It costs a little bit more, but it will be part of the 'past holiday special'. As an intermediate step I incresed the voltages of the ram - looks good so far. If that didn't change anything, I'd go back and stress test a previously stable configuration to gain confidence in my hardware. you mean like playing ut2004 with reduced fans or several instances of cpuburn, or compiling something big like kdepim with kdeenablefinal? Done all that ... If 'uhoh, not as stable as I thought' happened, and nothing is getting obviously hot [1], I'd pray that it's an electrically noisy power supply, because that's also easy and cheap. yeah, it would be the least annoying variant. After one PSU ate two computers, this one is just two and a half month old - I had my share of bad PSUs. That is why I increased the voltages. Maybe it helps. In any case, once I was very very confident that my hardware was indeed sound, I'd move on to an agonizingly tedious bisection, with no out of tree modules ever loaded, to narrow down when this memory corruption that nobody else appears to be hitting appeared. -Mike 1. Crappy heatsink compound can dry out and fracture, leaving hot chip under a relatively cool heatsink. This is exactly what I found when I disassembled my suddenly unstable under heavy load P4 box a while back. still this would show up with the temps. And the temps are ok. Glück Auf, Volker -- 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: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well
Ok, so after the holidays I will do the following: let memtest86+ run several hours. do a full backup to switch to r3 and build an unpatched kernel. see if I can reproduce the oops with .21 and .22 (because AFAIR no oops with 21.. but I might be wrong). Not exactly in that order. Glück Auf Volker ps: please cc me. I am not subscribed to lkml. -- 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: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well
On Donnerstag, 20. Dezember 2007, Ingo Molnar wrote: > * Hemmann, Volker Armin <[EMAIL PROTECTED]> wrote: > > On Donnerstag, 20. Dezember 2007, you wrote: > > > Hemmann, Volker Armin wrote: > > > > [ 5194.131014] Pid: 22490, comm: sleep Tainted: P > > > > 2.6.23.11reiser4 #4 > > > > > > The subject line is wrong. > > > You apparently run Linux, but not Linux 2.6.23.y. > > > > first of all, apart from this oops all other oopses I reported were > > with a not-tainted kernel. You might want to read the other mails I > > have sent. > > > > Also, besides of the reiser4 patch there is no other patch added to > > the kernel. And since people have had successfully reported problems > > with heavily distro-patched kernels in the past it looks a little bit > > hypocritical to put my reports aside because of one single patch - > > don't you think? > > reiser4 isnt just a single random patch, it's a huge patch with lots of > interactions with file and memory management. Would it be hard for you > to reproduce the crash without reiser4? (or is all your stuff on > reiser4?) /home (and /var, /tmp) is on reiser4 and my biggest partition. And since it needs up to 3 days to reproduce this - yes, hard to do without r4. Glück Auf, Volker -- 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: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well
On Donnerstag, 20. Dezember 2007, David Newall wrote: > >>> On Montag, 17. Dezember 2007, you wrote: > >>> > >>> and another one, this time tainted with the nvidia module: > >>> 5194.130985] Unable to handle kernel paging request at 0300 > >>> RIP: > > Numbers like that don't suggest hardware faults. All those zeros: It's > far too round. Sounds very like software. In fact, it sounds like the > start of significant hardware region. And lo! there's a closed-source, > possibly buggy nvidia module. Try another; older or newer are equally > good. and this one was without the nvidia module: http://marc.info/?l=linux-kernel=119790371708690=2 and the first one I reported, was without nvidia and not-tainted too: http://marc.info/?l=linux-kernel=119776365425514=2 I am not a complete idiot. If I have a problem, I try to reproduce without nvidia first (after a clean shutdown and boot, with the module not even on harddisk). And I reproduced it without the module. The last oops with the module was just an example that it does not matter if the module is loaded or not and to (maybe) give some additional information. Glück Auf, Volker -- 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: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well
On Donnerstag, 20. Dezember 2007, you wrote: > On Thu, 2007-12-20 at 06:53 +0100, Hemmann, Volker Armin wrote: > > On Donnerstag, 20. Dezember 2007, you wrote: > > > On Thu, 2007-12-20 at 03:13 +0100, Hemmann, Volker Armin wrote: > > > > On Montag, 17. Dezember 2007, you wrote: > > > > > > > > and another one, this time tainted with the nvidia module: > > > > 5194.130985] Unable to handle kernel paging request at > > > > 0300 RIP: > > > > > > This really sounds like bad hardware. Either memory or the mobo/riser > > > card the memory is on. You might try lowering the memory timings of > > > your memory in BIOS. Try removing 1/2 of your memory. If it still > > > remove the other 1/2 and put the first 1/2 back and try again. > > > > if this is bad hardware why: > > > > - didn't this show up earlier? > > > > - did a several hour memtest run couple of weeks ago didn't show up > > anything? > > > > - and does stuff like compiling all of kde 3.5.8 or the latest kde4 rc > > finish without any problems? > > Because bad hardware can be highly sensitive to exact load patterns. > Don't be so skeptical of the suggestion that your hardware may be > flakey, in the last 30+ years as a hardware guy in the design lab and in > the field, I've seen very much hardware which passed extensive > diagnostics, but turn out to be flakey nonetheless. > > I would suggest that you rearrange your ram modules, and see if the bit > pattern changes. Memtest may not show a problem with bitflips... if > that's happening. I would also suggest that you check your case > temperature as someone else suggested - lmsensors may say that the CPU > temperature is fine, but that isn't the whole picture. by a long shot. > > -Mike case temp: 25°C measured near a warm harddisk by a digital thermometer. mainboard temp: 31°C measured by lmsensors (mobo bios agrees) cpu temp: 29-50°C (load dependent) measured by lmsensors, bios puts on two additional degrees. I have 4 'big' fans installed to have a constant air stream in the case. This really does not look like overheating. And I did have flaky ram in the past. The thing is, apart from the oops the system is completly, perfectly stable. That really does not smell like flaky hardware. At least not in my experience. Flaky PSU = sudden reboots, boot problems, crashes under load. Flaky mobo = see flaky psu. Flaky Ram: crashes, crashes, more crashes, segfaults here and there, especially when updating glibc, qt or kde. And I don't get this. I only get oopses. It is just.. I could be the hardware - but I should have seen the same 'problem' with earlier kernels - and the 'almost daily oops' only started with 2.6.23. -- 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: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well
On Donnerstag, 20. Dezember 2007, you wrote: > Hemmann, Volker Armin wrote: > > [ 5194.131014] Pid: 22490, comm: sleep Tainted: P2.6.23.11reiser4 > > #4 > > The subject line is wrong. > You apparently run Linux, but not Linux 2.6.23.y. first of all, apart from this oops all other oopses I reported were with a not-tainted kernel. You might want to read the other mails I have sent. Also, besides of the reiser4 patch there is no other patch added to the kernel. And since people have had successfully reported problems with heavily distro-patched kernels in the past it looks a little bit hypocritical to put my reports aside because of one single patch - don't you think? Glück Auf, Volker -- 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: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well
On Donnerstag, 20. Dezember 2007, you wrote: Hemmann, Volker Armin wrote: [ 5194.131014] Pid: 22490, comm: sleep Tainted: P2.6.23.11reiser4 #4 The subject line is wrong. You apparently run Linux, but not Linux 2.6.23.y. first of all, apart from this oops all other oopses I reported were with a not-tainted kernel. You might want to read the other mails I have sent. Also, besides of the reiser4 patch there is no other patch added to the kernel. And since people have had successfully reported problems with heavily distro-patched kernels in the past it looks a little bit hypocritical to put my reports aside because of one single patch - don't you think? Glück Auf, Volker -- 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: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well
On Donnerstag, 20. Dezember 2007, you wrote: On Thu, 2007-12-20 at 06:53 +0100, Hemmann, Volker Armin wrote: On Donnerstag, 20. Dezember 2007, you wrote: On Thu, 2007-12-20 at 03:13 +0100, Hemmann, Volker Armin wrote: On Montag, 17. Dezember 2007, you wrote: and another one, this time tainted with the nvidia module: 5194.130985] Unable to handle kernel paging request at 0300 RIP: This really sounds like bad hardware. Either memory or the mobo/riser card the memory is on. You might try lowering the memory timings of your memory in BIOS. Try removing 1/2 of your memory. If it still remove the other 1/2 and put the first 1/2 back and try again. if this is bad hardware why: - didn't this show up earlier? - did a several hour memtest run couple of weeks ago didn't show up anything? - and does stuff like compiling all of kde 3.5.8 or the latest kde4 rc finish without any problems? Because bad hardware can be highly sensitive to exact load patterns. Don't be so skeptical of the suggestion that your hardware may be flakey, in the last 30+ years as a hardware guy in the design lab and in the field, I've seen very much hardware which passed extensive diagnostics, but turn out to be flakey nonetheless. I would suggest that you rearrange your ram modules, and see if the bit pattern changes. Memtest may not show a problem with bitflips... if that's happening. I would also suggest that you check your case temperature as someone else suggested - lmsensors may say that the CPU temperature is fine, but that isn't the whole picture. by a long shot. -Mike case temp: 25°C measured near a warm harddisk by a digital thermometer. mainboard temp: 31°C measured by lmsensors (mobo bios agrees) cpu temp: 29-50°C (load dependent) measured by lmsensors, bios puts on two additional degrees. I have 4 'big' fans installed to have a constant air stream in the case. This really does not look like overheating. And I did have flaky ram in the past. The thing is, apart from the oops the system is completly, perfectly stable. That really does not smell like flaky hardware. At least not in my experience. Flaky PSU = sudden reboots, boot problems, crashes under load. Flaky mobo = see flaky psu. Flaky Ram: crashes, crashes, more crashes, segfaults here and there, especially when updating glibc, qt or kde. And I don't get this. I only get oopses. It is just.. I could be the hardware - but I should have seen the same 'problem' with earlier kernels - and the 'almost daily oops' only started with 2.6.23. -- 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: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well
On Donnerstag, 20. Dezember 2007, David Newall wrote: On Montag, 17. Dezember 2007, you wrote: and another one, this time tainted with the nvidia module: 5194.130985] Unable to handle kernel paging request at 0300 RIP: Numbers like that don't suggest hardware faults. All those zeros: It's far too round. Sounds very like software. In fact, it sounds like the start of significant hardware region. And lo! there's a closed-source, possibly buggy nvidia module. Try another; older or newer are equally good. and this one was without the nvidia module: http://marc.info/?l=linux-kernelm=119790371708690w=2 and the first one I reported, was without nvidia and not-tainted too: http://marc.info/?l=linux-kernelm=119776365425514w=2 I am not a complete idiot. If I have a problem, I try to reproduce without nvidia first (after a clean shutdown and boot, with the module not even on harddisk). And I reproduced it without the module. The last oops with the module was just an example that it does not matter if the module is loaded or not and to (maybe) give some additional information. Glück Auf, Volker -- 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: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well
On Donnerstag, 20. Dezember 2007, Ingo Molnar wrote: * Hemmann, Volker Armin [EMAIL PROTECTED] wrote: On Donnerstag, 20. Dezember 2007, you wrote: Hemmann, Volker Armin wrote: [ 5194.131014] Pid: 22490, comm: sleep Tainted: P 2.6.23.11reiser4 #4 The subject line is wrong. You apparently run Linux, but not Linux 2.6.23.y. first of all, apart from this oops all other oopses I reported were with a not-tainted kernel. You might want to read the other mails I have sent. Also, besides of the reiser4 patch there is no other patch added to the kernel. And since people have had successfully reported problems with heavily distro-patched kernels in the past it looks a little bit hypocritical to put my reports aside because of one single patch - don't you think? reiser4 isnt just a single random patch, it's a huge patch with lots of interactions with file and memory management. Would it be hard for you to reproduce the crash without reiser4? (or is all your stuff on reiser4?) /home (and /var, /tmp) is on reiser4 and my biggest partition. And since it needs up to 3 days to reproduce this - yes, hard to do without r4. Glück Auf, Volker -- 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: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well
Ok, so after the holidays I will do the following: let memtest86+ run several hours. do a full backuprestore to switch to r3 and build an unpatched kernel. see if I can reproduce the oops with .21 and .22 (because AFAIR no oops with 21.. but I might be wrong). Not exactly in that order. Glück Auf Volker ps: please cc me. I am not subscribed to lkml. -- 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: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well
On Donnerstag, 20. Dezember 2007, you wrote: > On Thu, 2007-12-20 at 03:13 +0100, Hemmann, Volker Armin wrote: > > On Montag, 17. Dezember 2007, you wrote: > > > > and another one, this time tainted with the nvidia module: > > 5194.130985] Unable to handle kernel paging request at 0300 > > RIP: > > This really sounds like bad hardware. Either memory or the mobo/riser > card the memory is on. You might try lowering the memory timings of your > memory in BIOS. Try removing 1/2 of your memory. If it still remove the > other 1/2 and put the first 1/2 back and try again. if this is bad hardware why: - didn't this show up earlier? - did a several hour memtest run couple of weeks ago didn't show up anything? - and does stuff like compiling all of kde 3.5.8 or the latest kde4 rc finish without any problems? If it would be bad hardware, I should see segfaults left and right, right? but I don't see them. In fact, apart from the oopses the system works fine - even with the oopses the system works fine, apart from the occasional stuck ps aux And this messages: [41160.823959] kio_http_cache_[25229] general protection rip:32621f1fe9 rsp:7fff59a3d270 error:0 show up on closing konqueror tabs/Konqueror. There are no surprising exits, no apps vanishing. But I will run memtest86+ (or should I use memtest86?). Glück Auf, Volker -- 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: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well
On Montag, 17. Dezember 2007, you wrote: and another one, this time tainted with the nvidia module: 5194.130985] Unable to handle kernel paging request at 0300 RIP: [ 5194.130988] [] _spin_lock+0x0/0xf [ 5194.130993] PGD 0 [ 5194.130994] Oops: 0002 [1] SMP [ 5194.130996] CPU 1 [ 5194.130997] Modules linked in: rfcomm l2cap hci_usb bluetooth snd_usb_audio ohci1394 snd_usb_lib ieee1394 aic7xxx i2c_nforce2 nvidia(P) k8temp w83627ehf hwmon_vid hwmon i2c_core snd_seq_midi snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem snd_hwdep snd r8169 [ 5194.131014] Pid: 22490, comm: sleep Tainted: P2.6.23.11reiser4 #4 [ 5194.131015] RIP: 0010:[] [] _spin_lock+0x0/0xf [ 5194.131018] RSP: 0018:81009278be70 EFLAGS: 00010206 [ 5194.131020] RAX: 2ab90bfb5000 RBX: 810117d44db0 RCX: 2ab90bdb5000 [ 5194.131021] RDX: 81011519f810 RSI: 00388aa08fff RDI: 0300 [ 5194.131023] RBP: 0300 R08: 81012f190ea0 R09: [ 5194.131024] R10: 0008 R11: 0246 R12: 810117d44db0 [ 5194.131026] R13: 2ab90bdb R14: R15: [ 5194.131028] FS: 2ab90bde3070() GS:81012fc6cec0() knlGS:f7f756c0 [ 5194.131030] CS: 0010 DS: ES: CR0: 8005003b [ 5194.131031] CR2: 0300 CR3: 93605000 CR4: 06e0 [ 5194.131033] DR0: DR1: DR2: [ 5194.131034] DR3: DR6: 0ff0 DR7: 0400 [ 5194.131036] Process sleep (pid: 22490, threadinfo 81009278a000, task 8100960630c0) [ 5194.131037] Stack: 8026afbc 810117d44db0 810115e2cbb8 810117d44db0 [ 5194.131040] 80265ec3 81009278bee0 81009278bee0 810115e2c3d8 [ 5194.131043] 8100a076cb80 0002 7fff9ecf7808 7fff9ecf7810 [ 5194.131045] Call Trace: [ 5194.131048] [] anon_vma_unlink+0x1a/0x64 [ 5194.131051] [] free_pgtables+0x64/0xc4 [ 5194.131054] [] exit_mmap+0x91/0xeb [ 5194.131057] [] mmput+0x28/0xa0 [ 5194.131060] [] do_exit+0x211/0x786 [ 5194.131063] [] sys_exit_group+0x0/0xe [ 5194.131065] [] system_call+0x7e/0x83 [ 5194.131069] [ 5194.131070] [ 5194.131070] Code: f0 ff 0f 79 09 f3 90 83 3f 00 7e f9 eb f2 c3 f0 81 2f 00 00 [ 5194.131076] RIP [] _spin_lock+0x0/0xf [ 5194.131078] RSP [ 5194.131079] CR2: 0300 [ 5194.131101] Fixing recursive fault but reboot is needed! -- 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: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well
On Montag, 17. Dezember 2007, you wrote: and another one, this time tainted with the nvidia module: 5194.130985] Unable to handle kernel paging request at 0300 RIP: [ 5194.130988] [804449fa] _spin_lock+0x0/0xf [ 5194.130993] PGD 0 [ 5194.130994] Oops: 0002 [1] SMP [ 5194.130996] CPU 1 [ 5194.130997] Modules linked in: rfcomm l2cap hci_usb bluetooth snd_usb_audio ohci1394 snd_usb_lib ieee1394 aic7xxx i2c_nforce2 nvidia(P) k8temp w83627ehf hwmon_vid hwmon i2c_core snd_seq_midi snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem snd_hwdep snd r8169 [ 5194.131014] Pid: 22490, comm: sleep Tainted: P2.6.23.11reiser4 #4 [ 5194.131015] RIP: 0010:[804449fa] [804449fa] _spin_lock+0x0/0xf [ 5194.131018] RSP: 0018:81009278be70 EFLAGS: 00010206 [ 5194.131020] RAX: 2ab90bfb5000 RBX: 810117d44db0 RCX: 2ab90bdb5000 [ 5194.131021] RDX: 81011519f810 RSI: 00388aa08fff RDI: 0300 [ 5194.131023] RBP: 0300 R08: 81012f190ea0 R09: [ 5194.131024] R10: 0008 R11: 0246 R12: 810117d44db0 [ 5194.131026] R13: 2ab90bdb R14: R15: [ 5194.131028] FS: 2ab90bde3070() GS:81012fc6cec0() knlGS:f7f756c0 [ 5194.131030] CS: 0010 DS: ES: CR0: 8005003b [ 5194.131031] CR2: 0300 CR3: 93605000 CR4: 06e0 [ 5194.131033] DR0: DR1: DR2: [ 5194.131034] DR3: DR6: 0ff0 DR7: 0400 [ 5194.131036] Process sleep (pid: 22490, threadinfo 81009278a000, task 8100960630c0) [ 5194.131037] Stack: 8026afbc 810117d44db0 810115e2cbb8 810117d44db0 [ 5194.131040] 80265ec3 81009278bee0 81009278bee0 810115e2c3d8 [ 5194.131043] 8100a076cb80 0002 7fff9ecf7808 7fff9ecf7810 [ 5194.131045] Call Trace: [ 5194.131048] [8026afbc] anon_vma_unlink+0x1a/0x64 [ 5194.131051] [80265ec3] free_pgtables+0x64/0xc4 [ 5194.131054] [80267174] exit_mmap+0x91/0xeb [ 5194.131057] [80230191] mmput+0x28/0xa0 [ 5194.131060] [802353db] do_exit+0x211/0x786 [ 5194.131063] [802359cf] sys_exit_group+0x0/0xe [ 5194.131065] [8020b66e] system_call+0x7e/0x83 [ 5194.131069] [ 5194.131070] [ 5194.131070] Code: f0 ff 0f 79 09 f3 90 83 3f 00 7e f9 eb f2 c3 f0 81 2f 00 00 [ 5194.131076] RIP [804449fa] _spin_lock+0x0/0xf [ 5194.131078] RSP 81009278be70 [ 5194.131079] CR2: 0300 [ 5194.131101] Fixing recursive fault but reboot is needed! -- 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: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well
On Donnerstag, 20. Dezember 2007, you wrote: On Thu, 2007-12-20 at 03:13 +0100, Hemmann, Volker Armin wrote: On Montag, 17. Dezember 2007, you wrote: and another one, this time tainted with the nvidia module: 5194.130985] Unable to handle kernel paging request at 0300 RIP: This really sounds like bad hardware. Either memory or the mobo/riser card the memory is on. You might try lowering the memory timings of your memory in BIOS. Try removing 1/2 of your memory. If it still remove the other 1/2 and put the first 1/2 back and try again. if this is bad hardware why: - didn't this show up earlier? - did a several hour memtest run couple of weeks ago didn't show up anything? - and does stuff like compiling all of kde 3.5.8 or the latest kde4 rc finish without any problems? If it would be bad hardware, I should see segfaults left and right, right? but I don't see them. In fact, apart from the oopses the system works fine - even with the oopses the system works fine, apart from the occasional stuck ps aux And this messages: [41160.823959] kio_http_cache_[25229] general protection rip:32621f1fe9 rsp:7fff59a3d270 error:0 show up on closing konqueror tabs/Konqueror. There are no surprising exits, no apps vanishing. But I will run memtest86+ (or should I use memtest86?). Glück Auf, Volker -- 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: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well
On Montag, 17. Dezember 2007, you wrote: > On Mon, 17 Dec 2007, Hemmann, Volker Armin wrote: > > I got another crash, now with 2.6.23.11 on logout from KDE (two > > differences, new kernel, 4gb ram instead of 2gb): > > also I got some strange message yesterday before increasing ramsize: > > [19546.639528] swap_free: Bad swap offset entry 0400 > > [27999.370777] swap_free: Bad swap offset entry 0400 > > [27999.434282] swap_free: Bad swap offset entry 0400 > > [27999.466035] swap_free: Bad swap offset entry 0400 > > [27999.521132] swap_free: Bad swap offset entry 0400 > > [27999.561621] VM: killing process ld-linux-x86-64 > > [27999.561719] swap_free: Bad swap offset entry 0400 > > You're seeing a single bit set where it shouldn't be: please give > memtest86+ a good try; if it's not actually your memory that's bad, > then I'd guess it's something like overheating (please correct me, > ye who know better). > > Hugh first of all, the 2 with which I was seeing that have had their memtest run for some hours some weeks ago, without problems. I can compile stuff - like the latest kde4 rc without segfaults or problems (except when the oops is happening), and this mess only started recently. To be more correct: the swap-mess only started with 2.6.23.11. With 2.6.23.9 I get the kio_http... rip's, but no swap related messages. Overheating is very unlikely. I made sure that my computer is very well cooled. Even under high load I get something like 50°C from lmsensors and bios - and the errors are completly unrelated to load. Or temperature. Without load my cpu idles at ~30°C. Again, lmsensors and bios are very close about that. Glück Auf, Volker -- 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: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well
Hi. I got another crash, now with 2.6.23.11 on logout from KDE (two differences, new kernel, 4gb ram instead of 2gb): [ 1771.063731] Unable to handle kernel paging request at 0400 RIP: [ 1771.063735] [] _spin_lock+0x0/0xf [ 1771.063740] PGD 0 [ 1771.063741] Oops: 0002 [1] SMP [ 1771.063743] CPU 0 [ 1771.063744] Modules linked in: k8temp w83627ehf hwmon_vid hwmon i2c_core snd_seq_midi snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem snd_hwdep snd r8169 [ 1771.063756] Pid: 4418, comm: kdm Not tainted 2.6.23.11reiser4 #1 [ 1771.063758] RIP: 0010:[] [] _spin_lock+0x0/0xf [ 1771.063760] RSP: 0018:81012937de10 EFLAGS: 00010206 [ 1771.063762] RAX: 81012bd78870 RBX: 0400 RCX: [ 1771.063764] RDX: RSI: 81012c549e58 RDI: 0400 [ 1771.063765] RBP: 81012bd78870 R08: 80012c52c045 R09: 0005 [ 1771.063767] R10: 8100050df9f8 R11: 0002 R12: 8101280c3760 [ 1771.063768] R13: 81012f05fac0 R14: 81012c549db0 R15: 81012f05fac0 [ 1771.063770] FS: 2b438009bb40() GS:80533000() knlGS: [ 1771.063772] CS: 0010 DS: ES: CR0: 8005003b [ 1771.063773] CR2: 0400 CR3: 00012d689000 CR4: 06e0 [ 1771.063775] DR0: DR1: DR2: [ 1771.063776] DR3: DR6: 0ff0 DR7: 0400 [ 1771.063778] Process kdm (pid: 4418, threadinfo 81012937c000, task 81012fca7860) [ 1771.063779] Stack: 8026b084 81012ba17138 81012bd78870 [ 1771.063782] 80230d0c 2b438009bbd0 81012937df58 [ 1771.063785] 7fff2aa3d9d0 01200011 8101280c3760 [ 1771.063787] Call Trace: [ 1771.063790] [] anon_vma_link+0x1a/0x40 [ 1771.063793] [] copy_process+0xb03/0x1301 [ 1771.063798] [] do_fork+0xb1/0x1fc [ 1771.063802] [] recalc_sigpending+0xe/0x25 [ 1771.063804] [] system_call+0x7e/0x83 [ 1771.063806] [] ptregscall_common+0x67/0xb0 [ 1771.063810] [ 1771.063811] [ 1771.063811] Code: f0 ff 0f 79 09 f3 90 83 3f 00 7e f9 eb f2 c3 f0 81 2f 00 00 [ 1771.063816] RIP [] _spin_lock+0x0/0xf [ 1771.063819] RSP [ 1771.063820] CR2: 0400 also I got some strange message yesterday before increasing ramsize: 19546.639528] swap_free: Bad swap offset entry 0400 [19733.026587] kio_http_cache_[9814] general protection rip:3919ff1fe9 rsp:7fff7e1b59f0 error:0 I did swapoff - a, mkswap /dev/sda, swapon -a: [20105.297668] Adding 1951888k swap on /dev/sda2. Priority:-2 extents:1 across:1951888k [21013.797335] kio_http_cache_[10921] general protection rip:3919ff1fe9 rsp:7fff39a6d2a0 error:0 [22381.409172] kio_http_cache_[11459] general protection rip:3919ff1fe9 rsp:7fffd84c4d00 error:0 [23877.759927] kio_http_cache_[11959] general protection rip:3919ff1fe9 rsp:7fff9895c190 error:0 [25080.581142] kio_http_cache_[13146] general protection rip:3919ff1fe9 rsp:7fff790e0920 error:0 [26483.315522] kio_http_cache_[13746] general protection rip:3919ff1fe9 rsp:7fff51933170 error:0 [27696.301584] kio_http_cache_[14417] general protection rip:3919ff1fe9 rsp:7fff8f38abc0 error:0 [27999.370777] swap_free: Bad swap offset entry 0400 [27999.434282] swap_free: Bad swap offset entry 0400 [27999.466035] swap_free: Bad swap offset entry 0400 [27999.521132] swap_free: Bad swap offset entry 0400 [27999.561621] VM: killing process ld-linux-x86-64 [27999.561719] swap_free: Bad swap offset entry 0400 complete dmesg: [0.00] Linux version 2.6.23.11reiser4 ([EMAIL PROTECTED]) (gcc version 4.2.2 (Gentoo 4.2.2 p1.0)) #1 SMP Sun Dec 16 05:14:21 CET 2007 [0.00] Command line: root=/dev/sda3 nmi_watchdog=0 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e6000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - cffb (usable) [0.00] BIOS-e820: cffb - cffc (ACPI data) [0.00] BIOS-e820: cffc - cfff (ACPI NVS) [0.00] BIOS-e820: cfff - d000 (reserved) [0.00] BIOS-e820: fec0 - fec01000 (reserved) [0.00] BIOS-e820: fee0 - fef0 (reserved) [0.00] BIOS-e820: ff38 - 0001 (reserved) [0.00] BIOS-e820: 0001 - 00013000 (usable) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256,
Re: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well
Hi. I got another crash, now with 2.6.23.11 on logout from KDE (two differences, new kernel, 4gb ram instead of 2gb): [ 1771.063731] Unable to handle kernel paging request at 0400 RIP: [ 1771.063735] [8044256a] _spin_lock+0x0/0xf [ 1771.063740] PGD 0 [ 1771.063741] Oops: 0002 [1] SMP [ 1771.063743] CPU 0 [ 1771.063744] Modules linked in: k8temp w83627ehf hwmon_vid hwmon i2c_core snd_seq_midi snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem snd_hwdep snd r8169 [ 1771.063756] Pid: 4418, comm: kdm Not tainted 2.6.23.11reiser4 #1 [ 1771.063758] RIP: 0010:[8044256a] [8044256a] _spin_lock+0x0/0xf [ 1771.063760] RSP: 0018:81012937de10 EFLAGS: 00010206 [ 1771.063762] RAX: 81012bd78870 RBX: 0400 RCX: [ 1771.063764] RDX: RSI: 81012c549e58 RDI: 0400 [ 1771.063765] RBP: 81012bd78870 R08: 80012c52c045 R09: 0005 [ 1771.063767] R10: 8100050df9f8 R11: 0002 R12: 8101280c3760 [ 1771.063768] R13: 81012f05fac0 R14: 81012c549db0 R15: 81012f05fac0 [ 1771.063770] FS: 2b438009bb40() GS:80533000() knlGS: [ 1771.063772] CS: 0010 DS: ES: CR0: 8005003b [ 1771.063773] CR2: 0400 CR3: 00012d689000 CR4: 06e0 [ 1771.063775] DR0: DR1: DR2: [ 1771.063776] DR3: DR6: 0ff0 DR7: 0400 [ 1771.063778] Process kdm (pid: 4418, threadinfo 81012937c000, task 81012fca7860) [ 1771.063779] Stack: 8026b084 81012ba17138 81012bd78870 [ 1771.063782] 80230d0c 2b438009bbd0 81012937df58 [ 1771.063785] 7fff2aa3d9d0 01200011 8101280c3760 [ 1771.063787] Call Trace: [ 1771.063790] [8026b084] anon_vma_link+0x1a/0x40 [ 1771.063793] [80230d0c] copy_process+0xb03/0x1301 [ 1771.063798] [80231670] do_fork+0xb1/0x1fc [ 1771.063802] [8023aa56] recalc_sigpending+0xe/0x25 [ 1771.063804] [8020b66e] system_call+0x7e/0x83 [ 1771.063806] [8020b987] ptregscall_common+0x67/0xb0 [ 1771.063810] [ 1771.063811] [ 1771.063811] Code: f0 ff 0f 79 09 f3 90 83 3f 00 7e f9 eb f2 c3 f0 81 2f 00 00 [ 1771.063816] RIP [8044256a] _spin_lock+0x0/0xf [ 1771.063819] RSP 81012937de10 [ 1771.063820] CR2: 0400 also I got some strange message yesterday before increasing ramsize: 19546.639528] swap_free: Bad swap offset entry 0400 [19733.026587] kio_http_cache_[9814] general protection rip:3919ff1fe9 rsp:7fff7e1b59f0 error:0 I did swapoff - a, mkswap /dev/sda, swapon -a: [20105.297668] Adding 1951888k swap on /dev/sda2. Priority:-2 extents:1 across:1951888k [21013.797335] kio_http_cache_[10921] general protection rip:3919ff1fe9 rsp:7fff39a6d2a0 error:0 [22381.409172] kio_http_cache_[11459] general protection rip:3919ff1fe9 rsp:7fffd84c4d00 error:0 [23877.759927] kio_http_cache_[11959] general protection rip:3919ff1fe9 rsp:7fff9895c190 error:0 [25080.581142] kio_http_cache_[13146] general protection rip:3919ff1fe9 rsp:7fff790e0920 error:0 [26483.315522] kio_http_cache_[13746] general protection rip:3919ff1fe9 rsp:7fff51933170 error:0 [27696.301584] kio_http_cache_[14417] general protection rip:3919ff1fe9 rsp:7fff8f38abc0 error:0 [27999.370777] swap_free: Bad swap offset entry 0400 [27999.434282] swap_free: Bad swap offset entry 0400 [27999.466035] swap_free: Bad swap offset entry 0400 [27999.521132] swap_free: Bad swap offset entry 0400 [27999.561621] VM: killing process ld-linux-x86-64 [27999.561719] swap_free: Bad swap offset entry 0400 complete dmesg: [0.00] Linux version 2.6.23.11reiser4 ([EMAIL PROTECTED]) (gcc version 4.2.2 (Gentoo 4.2.2 p1.0)) #1 SMP Sun Dec 16 05:14:21 CET 2007 [0.00] Command line: root=/dev/sda3 nmi_watchdog=0 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e6000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - cffb (usable) [0.00] BIOS-e820: cffb - cffc (ACPI data) [0.00] BIOS-e820: cffc - cfff (ACPI NVS) [0.00] BIOS-e820: cfff - d000 (reserved) [0.00] BIOS-e820: fec0 - fec01000 (reserved) [0.00] BIOS-e820: fee0 - fef0 (reserved) [0.00] BIOS-e820: ff38 - 0001 (reserved) [0.00]
Re: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well
On Montag, 17. Dezember 2007, you wrote: On Mon, 17 Dec 2007, Hemmann, Volker Armin wrote: I got another crash, now with 2.6.23.11 on logout from KDE (two differences, new kernel, 4gb ram instead of 2gb): also I got some strange message yesterday before increasing ramsize: [19546.639528] swap_free: Bad swap offset entry 0400 [27999.370777] swap_free: Bad swap offset entry 0400 [27999.434282] swap_free: Bad swap offset entry 0400 [27999.466035] swap_free: Bad swap offset entry 0400 [27999.521132] swap_free: Bad swap offset entry 0400 [27999.561621] VM: killing process ld-linux-x86-64 [27999.561719] swap_free: Bad swap offset entry 0400 You're seeing a single bit set where it shouldn't be: please give memtest86+ a good try; if it's not actually your memory that's bad, then I'd guess it's something like overheating (please correct me, ye who know better). Hugh first of all, the 2 with which I was seeing that have had their memtest run for some hours some weeks ago, without problems. I can compile stuff - like the latest kde4 rc without segfaults or problems (except when the oops is happening), and this mess only started recently. To be more correct: the swap-mess only started with 2.6.23.11. With 2.6.23.9 I get the kio_http... rip's, but no swap related messages. Overheating is very unlikely. I made sure that my computer is very well cooled. Even under high load I get something like 50°C from lmsensors and bios - and the errors are completly unrelated to load. Or temperature. Without load my cpu idles at ~30°C. Again, lmsensors and bios are very close about that. Glück Auf, Volker -- 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: question about sata-error on boot.
Hi, On Mittwoch, 7. November 2007, Andrew Morton wrote: > > On Fri, 2 Nov 2007 19:34:20 +0100 "Hemmann, Volker Armin" > > <[EMAIL PROTECTED]> wrote: Hi, > > (cc linux-ide) > > > for some time (and I can't say for how long, but the board is less than a > > month old) I get this error on boot: > > > > [ 42.116273] ahci :00:0a.0: version 2.2 > > [ 42.116482] ACPI: PCI Interrupt Link [LSA0] enabled at IRQ 23 > > [ 42.116653] ACPI: PCI Interrupt :00:0a.0[A] -> Link [LSA0] -> GSI > > 23 (level, low) -> IRQ 23 > > [ 43.119478] ahci :00:0a.0: AHCI 0001.0100 32 slots 4 ports 3 Gbps > > 0xf impl IDE mode > > [ 43.119778] ahci :00:0a.0: flags: 64bit led clo pmp pio > > [ 43.119943] PCI: Setting latency timer of device :00:0a.0 to 64 > > [ 43.120149] scsi0 : ahci > > [ 43.120365] scsi1 : ahci > > [ 43.120556] scsi2 : ahci > > [ 43.120741] scsi3 : ahci > > [ 43.120927] ata1: SATA max UDMA/133 cmd 0xc2014100 ctl > > 0x bmdma 0x irq 315 > > [ 43.121227] ata2: SATA max UDMA/133 cmd 0xc2014180 ctl > > 0x bmdma 0x irq 315 > > [ 43.121526] ata3: SATA max UDMA/133 cmd 0xc2014200 ctl > > 0x bmdma 0x irq 315 > > [ 43.121826] ata4: SATA max UDMA/133 cmd 0xc2014280 ctl > > 0x bmdma 0x irq 315 > > [ 43.934296] ata1: softreset failed (1st FIS failed) > > [ 43.934461] ata1: reset failed (errno=-5), retrying in 10 secs > > [ 53.885194] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > > [ 53.885890] ata1.00: ATA-7: WDC WD1600JS-00MHB1, 10.02E01, max > > UDMA/133 [ 53.886056] ata1.00: 312581808 sectors, multi 16: LBA48 > > [ 53.886804] ata1.00: configured for UDMA/133 > > [ 54.201147] ata2: SATA link down (SStatus 0 SControl 300) > > [ 54.517101] ata3: SATA link down (SStatus 0 SControl 300) > > [ 54.833055] ata4: SATA link down (SStatus 0 SControl 300) this is gone with 2.6.22.13 an 2.6.23.9: [ 33.277039] scsi0 : ahci [ 33.277262] scsi1 : ahci [ 33.277454] scsi2 : ahci [ 33.277645] scsi3 : ahci [ 33.277826] ata1: SATA max UDMA/133 cmd 0xc2020100 ctl 0x bmdma 0x irq 315 [ 33.278120] ata2: SATA max UDMA/133 cmd 0xc2020180 ctl 0x bmdma 0x irq 315 [ 33.278414] ata3: SATA max UDMA/133 cmd 0xc2020200 ctl 0x bmdma 0x irq 315 [ 33.278708] ata4: SATA max UDMA/133 cmd 0xc2020280 ctl 0x bmdma 0x irq 315 [ 33.751855] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 33.752659] ata1.00: ATA-7: WDC WD1600JS-00MHB1, 10.02E01, max UDMA/133 [ 33.752821] ata1.00: 312581808 sectors, multi 16: LBA48 [ 33.753574] ata1.00: configured for UDMA/133 [ 34.067809] ata2: SATA link down (SStatus 0 SControl 300) [ 34.383762] ata3: SATA link down (SStatus 0 SControl 300) [ 34.699717] ata4: SATA link down (SStatus 0 SControl 300) [ 34.700029] scsi 0:0:0:0: Direct-Access ATA WDC WD1600JS-00M 10.0 PQ: 0 ANSI: 5 [ 34.700377] sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB) [ 34.700544] sd 0:0:0:0: [sda] Write Protect is off [ 34.700703] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 34.700712] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 34.701026] sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB) [ 34.701191] sd 0:0:0:0: [sda] Write Protect is off [ 34.701350] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 34.701358] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 34.701651] sda: sda1 sda2 sda3 sda4 < sda5 sda6 > -- 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: question about sata-error on boot.
Hi, On Mittwoch, 7. November 2007, Andrew Morton wrote: On Fri, 2 Nov 2007 19:34:20 +0100 Hemmann, Volker Armin [EMAIL PROTECTED] wrote: Hi, (cc linux-ide) for some time (and I can't say for how long, but the board is less than a month old) I get this error on boot: [ 42.116273] ahci :00:0a.0: version 2.2 [ 42.116482] ACPI: PCI Interrupt Link [LSA0] enabled at IRQ 23 [ 42.116653] ACPI: PCI Interrupt :00:0a.0[A] - Link [LSA0] - GSI 23 (level, low) - IRQ 23 [ 43.119478] ahci :00:0a.0: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl IDE mode [ 43.119778] ahci :00:0a.0: flags: 64bit led clo pmp pio [ 43.119943] PCI: Setting latency timer of device :00:0a.0 to 64 [ 43.120149] scsi0 : ahci [ 43.120365] scsi1 : ahci [ 43.120556] scsi2 : ahci [ 43.120741] scsi3 : ahci [ 43.120927] ata1: SATA max UDMA/133 cmd 0xc2014100 ctl 0x bmdma 0x irq 315 [ 43.121227] ata2: SATA max UDMA/133 cmd 0xc2014180 ctl 0x bmdma 0x irq 315 [ 43.121526] ata3: SATA max UDMA/133 cmd 0xc2014200 ctl 0x bmdma 0x irq 315 [ 43.121826] ata4: SATA max UDMA/133 cmd 0xc2014280 ctl 0x bmdma 0x irq 315 [ 43.934296] ata1: softreset failed (1st FIS failed) [ 43.934461] ata1: reset failed (errno=-5), retrying in 10 secs [ 53.885194] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 53.885890] ata1.00: ATA-7: WDC WD1600JS-00MHB1, 10.02E01, max UDMA/133 [ 53.886056] ata1.00: 312581808 sectors, multi 16: LBA48 [ 53.886804] ata1.00: configured for UDMA/133 [ 54.201147] ata2: SATA link down (SStatus 0 SControl 300) [ 54.517101] ata3: SATA link down (SStatus 0 SControl 300) [ 54.833055] ata4: SATA link down (SStatus 0 SControl 300) this is gone with 2.6.22.13 an 2.6.23.9: [ 33.277039] scsi0 : ahci [ 33.277262] scsi1 : ahci [ 33.277454] scsi2 : ahci [ 33.277645] scsi3 : ahci [ 33.277826] ata1: SATA max UDMA/133 cmd 0xc2020100 ctl 0x bmdma 0x irq 315 [ 33.278120] ata2: SATA max UDMA/133 cmd 0xc2020180 ctl 0x bmdma 0x irq 315 [ 33.278414] ata3: SATA max UDMA/133 cmd 0xc2020200 ctl 0x bmdma 0x irq 315 [ 33.278708] ata4: SATA max UDMA/133 cmd 0xc2020280 ctl 0x bmdma 0x irq 315 [ 33.751855] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 33.752659] ata1.00: ATA-7: WDC WD1600JS-00MHB1, 10.02E01, max UDMA/133 [ 33.752821] ata1.00: 312581808 sectors, multi 16: LBA48 [ 33.753574] ata1.00: configured for UDMA/133 [ 34.067809] ata2: SATA link down (SStatus 0 SControl 300) [ 34.383762] ata3: SATA link down (SStatus 0 SControl 300) [ 34.699717] ata4: SATA link down (SStatus 0 SControl 300) [ 34.700029] scsi 0:0:0:0: Direct-Access ATA WDC WD1600JS-00M 10.0 PQ: 0 ANSI: 5 [ 34.700377] sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB) [ 34.700544] sd 0:0:0:0: [sda] Write Protect is off [ 34.700703] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 34.700712] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 34.701026] sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB) [ 34.701191] sd 0:0:0:0: [sda] Write Protect is off [ 34.701350] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 34.701358] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 34.701651] sda: sda1 sda2 sda3 sda4 sda5 sda6 -- 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/
question about sata-error on boot.
Hi, for some time (and I can't say for how long, but the board is less than a month old) I get this error on boot: [ 42.116273] ahci :00:0a.0: version 2.2 [ 42.116482] ACPI: PCI Interrupt Link [LSA0] enabled at IRQ 23 [ 42.116653] ACPI: PCI Interrupt :00:0a.0[A] -> Link [LSA0] -> GSI 23 (level, low) -> IRQ 23 [ 43.119478] ahci :00:0a.0: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl IDE mode [ 43.119778] ahci :00:0a.0: flags: 64bit led clo pmp pio [ 43.119943] PCI: Setting latency timer of device :00:0a.0 to 64 [ 43.120149] scsi0 : ahci [ 43.120365] scsi1 : ahci [ 43.120556] scsi2 : ahci [ 43.120741] scsi3 : ahci [ 43.120927] ata1: SATA max UDMA/133 cmd 0xc2014100 ctl 0x bmdma 0x irq 315 [ 43.121227] ata2: SATA max UDMA/133 cmd 0xc2014180 ctl 0x bmdma 0x irq 315 [ 43.121526] ata3: SATA max UDMA/133 cmd 0xc2014200 ctl 0x bmdma 0x irq 315 [ 43.121826] ata4: SATA max UDMA/133 cmd 0xc2014280 ctl 0x bmdma 0x irq 315 [ 43.934296] ata1: softreset failed (1st FIS failed) [ 43.934461] ata1: reset failed (errno=-5), retrying in 10 secs [ 53.885194] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 53.885890] ata1.00: ATA-7: WDC WD1600JS-00MHB1, 10.02E01, max UDMA/133 [ 53.886056] ata1.00: 312581808 sectors, multi 16: LBA48 [ 53.886804] ata1.00: configured for UDMA/133 [ 54.201147] ata2: SATA link down (SStatus 0 SControl 300) [ 54.517101] ata3: SATA link down (SStatus 0 SControl 300) [ 54.833055] ata4: SATA link down (SStatus 0 SControl 300) The board has four ports and I use the first one. After that, the computer boots and works fine. Harddisk-speed is normal. Kernel is 2.6.22.9 with cfs patches. Is this something to worry about? Following is lspci -v and dmesg, config is attached. lspci -v 00:00.0 RAM memory: nVidia Corporation MCP65 Memory Controller (rev a1) Subsystem: ASRock Incorporation Unknown device 0444 Flags: bus master, 66MHz, fast devsel, latency 0 Capabilities: [44] HyperTransport: Slave or Primary Interface Capabilities: [dc] HyperTransport: MSI Mapping Enable+ Fixed- 00:01.0 ISA bridge: nVidia Corporation MCP65 LPC Bridge (rev a2) Subsystem: ASRock Incorporation Unknown device 0441 Flags: bus master, 66MHz, fast devsel, latency 0 I/O ports at 2f00 [size=256] 00:01.1 SMBus: nVidia Corporation MCP65 SMBus (rev a1) Subsystem: ASRock Incorporation Unknown device 0446 Flags: 66MHz, fast devsel, IRQ 11 I/O ports at ac00 [size=64] I/O ports at 2d00 [size=64] I/O ports at 2e00 [size=64] Capabilities: [44] Power Management version 2 00:01.2 RAM memory: nVidia Corporation MCP65 Memory Controller (rev a1) Subsystem: ASRock Incorporation Unknown device 0446 Flags: 66MHz, fast devsel 00:02.0 USB Controller: nVidia Corporation MCP65 USB Controller (rev a1) (prog-if 10 [OHCI]) Subsystem: ASRock Incorporation Unknown device 0454 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 21 Memory at f9dff000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00:02.1 USB Controller: nVidia Corporation MCP65 USB Controller (rev a1) (prog-if 20 [EHCI]) Subsystem: ASRock Incorporation Unknown device 0455 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22 Memory at f9dfec00 (32-bit, non-prefetchable) [size=256] Capabilities: [44] Debug port Capabilities: [80] Power Management version 2 00:08.0 PCI bridge: nVidia Corporation MCP65 PCI bridge (rev a1) (prog-if 01 [Subtractive decode]) Flags: bus master, 66MHz, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=128 I/O behind bridge: c000-dfff Memory behind bridge: f9f0-f9ff Prefetchable memory behind bridge: 8800-880f Capabilities: [b8] Subsystem: ASRock Incorporation Unknown device 0449 Capabilities: [8c] HyperTransport: MSI Mapping Enable- Fixed- 00:09.0 IDE interface: nVidia Corporation MCP65 IDE (rev a1) (prog-if 8a [Master SecP PriP]) Subsystem: ASRock Incorporation Unknown device 0448 Flags: bus master, 66MHz, fast devsel, latency 0 [virtual] Memory at 01f0 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 03f0 (type 3, non-prefetchable) [disabled] [size=1] [virtual] Memory at 0170 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 0370 (type 3, non-prefetchable) [disabled] [size=1] I/O ports at ffa0 [size=16] Capabilities: [44] Power Management version 2 00:0a.0 IDE interface: nVidia Corporation MCP65 SATA Controller (rev a1) (prog-if 85 [Master SecO PriO])
question about sata-error on boot.
Hi, for some time (and I can't say for how long, but the board is less than a month old) I get this error on boot: [ 42.116273] ahci :00:0a.0: version 2.2 [ 42.116482] ACPI: PCI Interrupt Link [LSA0] enabled at IRQ 23 [ 42.116653] ACPI: PCI Interrupt :00:0a.0[A] - Link [LSA0] - GSI 23 (level, low) - IRQ 23 [ 43.119478] ahci :00:0a.0: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl IDE mode [ 43.119778] ahci :00:0a.0: flags: 64bit led clo pmp pio [ 43.119943] PCI: Setting latency timer of device :00:0a.0 to 64 [ 43.120149] scsi0 : ahci [ 43.120365] scsi1 : ahci [ 43.120556] scsi2 : ahci [ 43.120741] scsi3 : ahci [ 43.120927] ata1: SATA max UDMA/133 cmd 0xc2014100 ctl 0x bmdma 0x irq 315 [ 43.121227] ata2: SATA max UDMA/133 cmd 0xc2014180 ctl 0x bmdma 0x irq 315 [ 43.121526] ata3: SATA max UDMA/133 cmd 0xc2014200 ctl 0x bmdma 0x irq 315 [ 43.121826] ata4: SATA max UDMA/133 cmd 0xc2014280 ctl 0x bmdma 0x irq 315 [ 43.934296] ata1: softreset failed (1st FIS failed) [ 43.934461] ata1: reset failed (errno=-5), retrying in 10 secs [ 53.885194] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 53.885890] ata1.00: ATA-7: WDC WD1600JS-00MHB1, 10.02E01, max UDMA/133 [ 53.886056] ata1.00: 312581808 sectors, multi 16: LBA48 [ 53.886804] ata1.00: configured for UDMA/133 [ 54.201147] ata2: SATA link down (SStatus 0 SControl 300) [ 54.517101] ata3: SATA link down (SStatus 0 SControl 300) [ 54.833055] ata4: SATA link down (SStatus 0 SControl 300) The board has four ports and I use the first one. After that, the computer boots and works fine. Harddisk-speed is normal. Kernel is 2.6.22.9 with cfsreiser4 patches. Is this something to worry about? Following is lspci -v and dmesg, config is attached. lspci -v 00:00.0 RAM memory: nVidia Corporation MCP65 Memory Controller (rev a1) Subsystem: ASRock Incorporation Unknown device 0444 Flags: bus master, 66MHz, fast devsel, latency 0 Capabilities: [44] HyperTransport: Slave or Primary Interface Capabilities: [dc] HyperTransport: MSI Mapping Enable+ Fixed- 00:01.0 ISA bridge: nVidia Corporation MCP65 LPC Bridge (rev a2) Subsystem: ASRock Incorporation Unknown device 0441 Flags: bus master, 66MHz, fast devsel, latency 0 I/O ports at 2f00 [size=256] 00:01.1 SMBus: nVidia Corporation MCP65 SMBus (rev a1) Subsystem: ASRock Incorporation Unknown device 0446 Flags: 66MHz, fast devsel, IRQ 11 I/O ports at ac00 [size=64] I/O ports at 2d00 [size=64] I/O ports at 2e00 [size=64] Capabilities: [44] Power Management version 2 00:01.2 RAM memory: nVidia Corporation MCP65 Memory Controller (rev a1) Subsystem: ASRock Incorporation Unknown device 0446 Flags: 66MHz, fast devsel 00:02.0 USB Controller: nVidia Corporation MCP65 USB Controller (rev a1) (prog-if 10 [OHCI]) Subsystem: ASRock Incorporation Unknown device 0454 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 21 Memory at f9dff000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00:02.1 USB Controller: nVidia Corporation MCP65 USB Controller (rev a1) (prog-if 20 [EHCI]) Subsystem: ASRock Incorporation Unknown device 0455 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22 Memory at f9dfec00 (32-bit, non-prefetchable) [size=256] Capabilities: [44] Debug port Capabilities: [80] Power Management version 2 00:08.0 PCI bridge: nVidia Corporation MCP65 PCI bridge (rev a1) (prog-if 01 [Subtractive decode]) Flags: bus master, 66MHz, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=128 I/O behind bridge: c000-dfff Memory behind bridge: f9f0-f9ff Prefetchable memory behind bridge: 8800-880f Capabilities: [b8] Subsystem: ASRock Incorporation Unknown device 0449 Capabilities: [8c] HyperTransport: MSI Mapping Enable- Fixed- 00:09.0 IDE interface: nVidia Corporation MCP65 IDE (rev a1) (prog-if 8a [Master SecP PriP]) Subsystem: ASRock Incorporation Unknown device 0448 Flags: bus master, 66MHz, fast devsel, latency 0 [virtual] Memory at 01f0 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 03f0 (type 3, non-prefetchable) [disabled] [size=1] [virtual] Memory at 0170 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 0370 (type 3, non-prefetchable) [disabled] [size=1] I/O ports at ffa0 [size=16] Capabilities: [44] Power Management version 2 00:0a.0 IDE interface: nVidia Corporation MCP65 SATA Controller (rev a1) (prog-if 85 [Master SecO PriO])
Re: libata-bug in 2.6.21.5 on amd64 with ali chipset
On Mittwoch, 27. Juni 2007, you wrote: > It has worked in the past. I will try different kernels in the next > 24hours. I tried this kernels: 2.6.20 2.6.20.1 2.6.21 2.6.21.1 2.6.21.3 2.6.21.5 2.6.21.5 with and without cfs. Every other kernel without cfs. Patched with reiser4, nvidia not loaded nor used. All of them locked up. I tried two different cdrtools 2.01.01_alpha27 and alpha25. No change. The strange thing: 2.6.21.1 has worked in the past. At the 21.May I tried (successfully) to burn a dvd. The only real change I could find since then: I recompiled the whole system to remove 'ricer' cflags. Glück Auf Volker - 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: libata-bug in 2.6.21.5 on amd64 with ali chipset
On Mittwoch, 27. Juni 2007, you wrote: It has worked in the past. I will try different kernels in the next 24hours. I tried this kernels: 2.6.20 2.6.20.1 2.6.21 2.6.21.1 2.6.21.3 2.6.21.5 2.6.21.5 with and without cfs. Every other kernel without cfs. Patched with reiser4, nvidia not loaded nor used. All of them locked up. I tried two different cdrtools 2.01.01_alpha27 and alpha25. No change. The strange thing: 2.6.21.1 has worked in the past. At the 21.May I tried (successfully) to burn a dvd. The only real change I could find since then: I recompiled the whole system to remove 'ricer' cflags. Glück Auf Volker - 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/
libata-bug in 2.6.21.5 on amd64 with ali chipset
Hi, this is on an amd64 gentoo system (with march=k8 -02 msse3 -pipe as CFLAGS aka sane ones). with kernel 2.6.21.5 my dvd burner locks up the computer when k3b starts. k3b (this is of course captured without libata) [EMAIL PROTECTED] ~ $ kdecore (KAction): WARNING: KActionCollection::KActionCollection( QObject *parent, const char *name, KInstance *instance ) /dev/hdc resolved to /dev/hdc /dev/hdc is block device (0) /dev/hdc seems to be cdrom (K3bDevice::Device) /dev/hdc: init() (K3bDevice::Device) /dev/hdc feature: CD Mastering (K3bDevice::Device) /dev/hdc feature: CD Track At Once (K3bDevice::Device) /dev/hdc feature: CD-RW Media Write Support (K3bDevice::Device) /dev/hdc feature: DVD+R (K3bDevice::Device) /dev/hdc feature: DVD+RW (K3bDevice::Device) /dev/hdc feature: DVD+R Double Layer (K3bDevice::Device) /dev/hdc feature: DVD-R/-RW Write (K3bDevice::Device) /dev/hdc feature: Rigid Restricted Overwrite (K3bDevice::Device) /dev/hdc: dataLen: 60 (K3bDevice::Device) /dev/hdc: checking for TAO (K3bDevice::Device) /dev/hdc: checking for SAO (K3bDevice::Device) /dev/hdc: checking for SAO_R96P (K3bDevice::Device) /dev/hdc: checking for SAO_R96R (K3bDevice::Device) /dev/hdc: checking for RAW_R16 (K3bDevice::Device) /dev/hdc: checking for RAW_R96P (K3bDevice::Device) /dev/hdc: checking for RAW_R96R at this point it locks up. Everything is dead. Keyboard, mouse, - I have acpid running, when the pwbutton is hit, it changes to vt2 and it does not work too. Without libata and the 'normal' ide drivers the burner works. The 2.6.21.5 is patched with cfs v18 and reiser4. ver_linux Linux energy 2.6.21.5-cfs-v18reiser4OS #4 SMP Wed Jun 27 11:09:51 CEST 2007 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ AuthenticAMD GNU/Linux Gnu C 4.1.2 Gnu make 3.81 binutils Binutils util-linux 2.12r mount 2.12r module-init-tools 3.2.2 e2fsprogs 1.40-WIP reiserfsprogs 3.6.19 reiser4progs 1.0.6 PPP2.4.4 Linux C Library> libc.2.5 Dynamic linker (ldd) 2.5 Procps 3.2.7 Net-tools 1.60 Kbd1.12 Sh-utils 6.9 udev 112 Modules Loaded w83627hf hwmon_vid i2c_isa k8temp eeprom i2c_ali1563 snd_seq_midi snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem snd_hwdep tuner bttv video_buf ir_common compat_ioctl32 i2c_algo_bit btcx_risc tveeprom i2c_core videodev v4l2_common v4l1_compat uli526x Here is dmesg without libata: dmesg [0.00] Linux version 2.6.21.5-cfs-v18reiser4OS ([EMAIL PROTECTED]) (gcc version 4.1.2 (Gentoo 4.1.2)) #4 SMP Wed Jun 27 11:09:51 CEST 2007 [0.00] Command line: root=/dev/sda3 nmi_watchdog=0 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e8000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - 3ffb (usable) [0.00] BIOS-e820: 3ffb - 3ffc (ACPI data) [0.00] BIOS-e820: 3ffc - 3fff (ACPI NVS) [0.00] BIOS-e820: 3fff - 4000 (reserved) [0.00] BIOS-e820: ff7c - 0001 (reserved) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 262064) 1 entries of 256 used [0.00] end_pfn_map = 1048576 [0.00] DMI 2.3 present. [0.00] ACPI: RSDP 000F9A50, 0014 (r0 ACPIAM) [0.00] ACPI: RSDT 3FFB, 0034 (r1 A M I OEMRSDT 9000625 MSFT 97) [0.00] ACPI: FACP 3FFB0200, 0084 (r2 A M I OEMFACP 9000625 MSFT 97) [0.00] ACPI: DSDT 3FFB0440, 474D (r1 939M2 939M 222 INTL 2002026) [0.00] ACPI: FACS 3FFC, 0040 [0.00] ACPI: APIC 3FFB0390, 0068 (r1 A M I OEMAPIC 9000625 MSFT 97) [0.00] ACPI: MCFG 3FFB0400, 003C (r1 A M I OEMMCFG 9000625 MSFT 97) [0.00] ACPI: OEMB 3FFC0040, 0057 (r1 A M I AMI_OEM 9000625 MSFT 97) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 262064) 1 entries of 256 used [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] DMA324096 -> 1048576 [0.00] Normal1048576 -> 1048576 [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 -> 159 [0.00] 0: 256 -> 262064 [0.00] On node 0 totalpages: 261967 [0.00] DMA zone: 56 pages
libata-bug in 2.6.21.5 on amd64 with ali chipset
Hi, this is on an amd64 gentoo system (with march=k8 -02 msse3 -pipe as CFLAGS aka sane ones). with kernel 2.6.21.5 my dvd burner locks up the computer when k3b starts. k3b (this is of course captured without libata) [EMAIL PROTECTED] ~ $ kdecore (KAction): WARNING: KActionCollection::KActionCollection( QObject *parent, const char *name, KInstance *instance ) /dev/hdc resolved to /dev/hdc /dev/hdc is block device (0) /dev/hdc seems to be cdrom (K3bDevice::Device) /dev/hdc: init() (K3bDevice::Device) /dev/hdc feature: CD Mastering (K3bDevice::Device) /dev/hdc feature: CD Track At Once (K3bDevice::Device) /dev/hdc feature: CD-RW Media Write Support (K3bDevice::Device) /dev/hdc feature: DVD+R (K3bDevice::Device) /dev/hdc feature: DVD+RW (K3bDevice::Device) /dev/hdc feature: DVD+R Double Layer (K3bDevice::Device) /dev/hdc feature: DVD-R/-RW Write (K3bDevice::Device) /dev/hdc feature: Rigid Restricted Overwrite (K3bDevice::Device) /dev/hdc: dataLen: 60 (K3bDevice::Device) /dev/hdc: checking for TAO (K3bDevice::Device) /dev/hdc: checking for SAO (K3bDevice::Device) /dev/hdc: checking for SAO_R96P (K3bDevice::Device) /dev/hdc: checking for SAO_R96R (K3bDevice::Device) /dev/hdc: checking for RAW_R16 (K3bDevice::Device) /dev/hdc: checking for RAW_R96P (K3bDevice::Device) /dev/hdc: checking for RAW_R96R at this point it locks up. Everything is dead. Keyboard, mouse, - I have acpid running, when the pwbutton is hit, it changes to vt2 and it does not work too. Without libata and the 'normal' ide drivers the burner works. The 2.6.21.5 is patched with cfs v18 and reiser4. ver_linux Linux energy 2.6.21.5-cfs-v18reiser4OS #4 SMP Wed Jun 27 11:09:51 CEST 2007 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ AuthenticAMD GNU/Linux Gnu C 4.1.2 Gnu make 3.81 binutils Binutils util-linux 2.12r mount 2.12r module-init-tools 3.2.2 e2fsprogs 1.40-WIP reiserfsprogs 3.6.19 reiser4progs 1.0.6 PPP2.4.4 Linux C Library libc.2.5 Dynamic linker (ldd) 2.5 Procps 3.2.7 Net-tools 1.60 Kbd1.12 Sh-utils 6.9 udev 112 Modules Loaded w83627hf hwmon_vid i2c_isa k8temp eeprom i2c_ali1563 snd_seq_midi snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem snd_hwdep tuner bttv video_buf ir_common compat_ioctl32 i2c_algo_bit btcx_risc tveeprom i2c_core videodev v4l2_common v4l1_compat uli526x Here is dmesg without libata: dmesg [0.00] Linux version 2.6.21.5-cfs-v18reiser4OS ([EMAIL PROTECTED]) (gcc version 4.1.2 (Gentoo 4.1.2)) #4 SMP Wed Jun 27 11:09:51 CEST 2007 [0.00] Command line: root=/dev/sda3 nmi_watchdog=0 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e8000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - 3ffb (usable) [0.00] BIOS-e820: 3ffb - 3ffc (ACPI data) [0.00] BIOS-e820: 3ffc - 3fff (ACPI NVS) [0.00] BIOS-e820: 3fff - 4000 (reserved) [0.00] BIOS-e820: ff7c - 0001 (reserved) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 262064) 1 entries of 256 used [0.00] end_pfn_map = 1048576 [0.00] DMI 2.3 present. [0.00] ACPI: RSDP 000F9A50, 0014 (r0 ACPIAM) [0.00] ACPI: RSDT 3FFB, 0034 (r1 A M I OEMRSDT 9000625 MSFT 97) [0.00] ACPI: FACP 3FFB0200, 0084 (r2 A M I OEMFACP 9000625 MSFT 97) [0.00] ACPI: DSDT 3FFB0440, 474D (r1 939M2 939M 222 INTL 2002026) [0.00] ACPI: FACS 3FFC, 0040 [0.00] ACPI: APIC 3FFB0390, 0068 (r1 A M I OEMAPIC 9000625 MSFT 97) [0.00] ACPI: MCFG 3FFB0400, 003C (r1 A M I OEMMCFG 9000625 MSFT 97) [0.00] ACPI: OEMB 3FFC0040, 0057 (r1 A M I AMI_OEM 9000625 MSFT 97) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 262064) 1 entries of 256 used [0.00] Zone PFN ranges: [0.00] DMA 0 - 4096 [0.00] DMA324096 - 1048576 [0.00] Normal1048576 - 1048576 [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 - 159 [0.00] 0: 256 - 262064 [0.00] On node 0 totalpages: 261967 [0.00] DMA zone: 56 pages used for
Re: [patch] CFS scheduler, -v13
Hi, I wanted to mail earlier, but I had always something get in my way. I used cfs v13 since you announced it. Since patching the kernel (2.6.21.1) with cfs v13 I did the following things; - big backup of home onto tape and restoring it after changing to reiser4 (yes, I know the threads about its problems, but I always wanted to try it - and when fragmentation reached the point of unbearable, I switched. The really important stuff is still on a different fs, and I figured that using an experimental fs might be the kick I need to do frequently updates again..). - lots and lots and lots of compiling. And then some more compiling. - burning dvds (I also switched to libata - if you go experimental, why don't do it completly... only the dvd drive and a 'data dump' harddisk are affected.. but hey, since then no surprise-pio-mode anymore...) - some ut2004 - assorted desktop stuff. typing, surfing, video, music, - most of it in parallel. some 'minor' games like freeciv, wesnoth, lgeneral. - some vegastrike-svn So far I am pretty satisfied. I can't see any regressions, music is skip-free, videos play nice, burning dvds is fast, ut2004 and vegastrike play well. The other games can't be better and did not get worse. Everything else behaves like always. Glück Auf, Volker - 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] CFS scheduler, -v13
Hi, I wanted to mail earlier, but I had always something get in my way. I used cfs v13 since you announced it. Since patching the kernel (2.6.21.1) with cfs v13 I did the following things; - big backup of home onto tape and restoring it after changing to reiser4 (yes, I know the threads about its problems, but I always wanted to try it - and when fragmentation reached the point of unbearable, I switched. The really important stuff is still on a different fs, and I figured that using an experimental fs might be the kick I need to do frequently updates again..). - lots and lots and lots of compiling. And then some more compiling. - burning dvds (I also switched to libata - if you go experimental, why don't do it completly... only the dvd drive and a 'data dump' harddisk are affected.. but hey, since then no surprise-pio-mode anymore...) - some ut2004 - assorted desktop stuff. typing, surfing, video, music, - most of it in parallel. some 'minor' games like freeciv, wesnoth, lgeneral. - some vegastrike-svn So far I am pretty satisfied. I can't see any regressions, music is skip-free, videos play nice, burning dvds is fast, ut2004 and vegastrike play well. The other games can't be better and did not get worse. Everything else behaves like always. Glück Auf, Volker - 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/
cfs works fine for me
Hello, I have tried the cfs patches with 2.6.20.7 in the last days. I am using KDE 3.5.6, gentoo unstable and have a dual core AMD64 system with 1GB ram and a nvidia card (using the closed source drivers, yes I suck, but I love playing 3d games once in a while). I don't have interactivity problems with plain kernel.org kernels (except when swapping a lot, swapping really sucks) My system works well and is stable. With the cfs patches, my system continues to work well. I have not seen any regressions, desktop is snappy, emerge'ing stuff (niced to +19), does not hurt and unreal tournament 2004 is as fast (or slow, depends on the situation) as always. It even looks like FPS under heavy stress (like onslaught torlan when lots of bots and me are fighting at a powernode), don't go down as low as with the mainline scheduler. Not a big difference, but it is there (20-25 with plain kernel.org kernel in extrem situations compared to >30 with the cfs patches). Maybe I did not hit the worst case, playing is a little bit restricted at the moment - my wrist and ellbow hate me, but it looks promising. Apart from the worst case scenrios, FPS are more or less the same. My usage consisted of surfing the web with konqueror, watching videos with xine and mplayer, using kmail (with tens of thousands of mails in different folders), looking at pictures with kuickshow, installing XFCE, asorted updates, typing lots and lots of stuff in kate and web forums, listening to mp3/ogg with amarok, playing pysol/kpat/lgeneral/wesnoth/ut2004/freecol, a lot of that parallel (not ut2004... I don't want to hurt my precious fps...). Again, my system worked fine with the 'normal' scheduler, from the stuff I read in the lkml archives I must be some special kind of guy, so there was no improvement on the 'feels snappy or not' front, but there are also no regressions. So from my point of view, everything is fine with cfs and I would not mind having it as default scheduler. If you want specs of my hardware, my kernel config or any other information, just send me an email. I am not subscribed to lkml, nor can I read any of its archives in the next couple of days, which is one reason why I don't answer to one at the existing threads (I don't even know if there are some at the moment), so in case of an answer cc'ing me would be nice. Glück Auf Volker - 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/
cfs works fine for me
Hello, I have tried the cfs patches with 2.6.20.7 in the last days. I am using KDE 3.5.6, gentoo unstable and have a dual core AMD64 system with 1GB ram and a nvidia card (using the closed source drivers, yes I suck, but I love playing 3d games once in a while). I don't have interactivity problems with plain kernel.org kernels (except when swapping a lot, swapping really sucks) My system works well and is stable. With the cfs patches, my system continues to work well. I have not seen any regressions, desktop is snappy, emerge'ing stuff (niced to +19), does not hurt and unreal tournament 2004 is as fast (or slow, depends on the situation) as always. It even looks like FPS under heavy stress (like onslaught torlan when lots of bots and me are fighting at a powernode), don't go down as low as with the mainline scheduler. Not a big difference, but it is there (20-25 with plain kernel.org kernel in extrem situations compared to 30 with the cfs patches). Maybe I did not hit the worst case, playing is a little bit restricted at the moment - my wrist and ellbow hate me, but it looks promising. Apart from the worst case scenrios, FPS are more or less the same. My usage consisted of surfing the web with konqueror, watching videos with xine and mplayer, using kmail (with tens of thousands of mails in different folders), looking at pictures with kuickshow, installing XFCE, asorted updates, typing lots and lots of stuff in kate and web forums, listening to mp3/ogg with amarok, playing pysol/kpat/lgeneral/wesnoth/ut2004/freecol, a lot of that parallel (not ut2004... I don't want to hurt my precious fps...). Again, my system worked fine with the 'normal' scheduler, from the stuff I read in the lkml archives I must be some special kind of guy, so there was no improvement on the 'feels snappy or not' front, but there are also no regressions. So from my point of view, everything is fine with cfs and I would not mind having it as default scheduler. If you want specs of my hardware, my kernel config or any other information, just send me an email. I am not subscribed to lkml, nor can I read any of its archives in the next couple of days, which is one reason why I don't answer to one at the existing threads (I don't even know if there are some at the moment), so in case of an answer cc'ing me would be nice. Glück Auf Volker - 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/
