The replacement system is completely OK.
The faulty system shows symptoms of random crash even after replacing the
CPU. Of course the kernel panic manifest itself in a form of a sync error.
And the HDD is absolutely OK.
There are some flaws with the motherboard or some other core components
other t
Hi!
On Sun, Jan 09, 2011 at 03:55:14PM +0100, "Tóth Attila" wrote:
> What would you guys suggest to test the system with besides emerging
> qt-gui? Are there any memtest equivalent for checking the CPU?
You can try app-benchmarks/cpuburn. It's not memtest equivalent, of
course, but it may help yo
I'd like to give a feedback regarding the crashes I've reported.
I transferred my system to my spare laptop (exactly the same model). I
haven't experienced any hangups or file systems problems so far, using the
same kernel (hardened-sources-2.6.36-r7) and performing the same tasks -
including a reg
On 4 Jan 2011 at 19:38, "Tóth Attila" wrote:
> Would it be possible that the CPU itself is actually failing (opcode )?
not in this case, always look at the first problem, everything else may very
well be just collateral damage. and that's a BUG_ON so it's the kernel that
detects some bad cond
I see. Now I fired up my spare notebook and transferred the system in the
mean time. :P
I'm currently suffering of crashes occuring while I'm transcoding a
scientific event's DVD content. It became very frustrating.
Would it be possible that the CPU itself is actually failing (opcode )?
The t
On 4 Jan 2011 at 14:52, "Tóth Attila" wrote:
> No errors were found after 12 hours of memtest.
>
> However some serious crashes still occur.
>
> I attach snippets of kern.log.
>
> Is it still suggests a hardware error?
when i said memory corruption, i didn't mean a hw error but a sw one
that caus
On 4 Jan 2011 at 14:52, "Tóth Attila" wrote:
> Forgotten attachment
ok, i think it's time to try vanilla if you can as this seems to be
a problem in code we don't really touch directly...
No errors were found after 12 hours of memtest.
However some serious crashes still occur.
I attach snippets of kern.log.
Is it still suggests a hardware error?
I have to try out another laptop. That is not convenient...
Dw.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiolo
2010.December 30.(Cs) 21:35 időpontban pagee...@freemail.hu ezt írta:
> On 30 Dec 2010 at 20:29, "Tóth Attila" wrote:
>
>> There were two screen shots attached. The older one was outdated related
>> to 2.6.32 kernel.
>>
>> But the other was a recent panic.
>
> unfortunately this one had the first
On 30 Dec 2010 at 20:29, "Tóth Attila" wrote:
> There were two screen shots attached. The older one was outdated related
> to 2.6.32 kernel.
>
> But the other was a recent panic.
unfortunately this one had the first oops scroll away already, so i can't tell
much about it...
> So here is another
There were two screen shots attached. The older one was outdated related
to 2.6.32 kernel.
But the other was a recent panic.
So here is another one. This time I could paste it from the log:
last sysfs file:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:00/PNP0C09:00/PNP0C0A:00/power_sup
On 27 Dec 2010 at 1:05, klondike wrote:
> looking at ./Documentation/kernel-parameters.txt only found these:
> pax_nouderef[X86-32] disables UDEREF. Most likely needed under
> certain
> virtualization environments that don't cope well with
> the
>
On 12/26/2010 03:00 PM, pagee...@freemail.hu wrote:
> On 26 Dec 2010 at 14:09, Michael Orlitzky wrote:
>
>> Challenge accepted. I'm dressed, the car's cleaned off, and I'm
>> recompiling with UDEREF=n.
>
> passing pax_nouderef on the kernel cmdline should be enough ;)
>
This doesn't seem to wor
El 26/12/10 21:00, pagee...@freemail.hu escribió:
> On 26 Dec 2010 at 14:09, Michael Orlitzky wrote:
>
>> Challenge accepted. I'm dressed, the car's cleaned off, and I'm
>> recompiling with UDEREF=n.
> passing pax_nouderef on the kernel cmdline should be enough ;
looking at ./Documentation/kernel-p
El 26/12/10 21:00, pagee...@freemail.hu escribió:
> On 26 Dec 2010 at 14:09, Michael Orlitzky wrote:
>
>> Challenge accepted. I'm dressed, the car's cleaned off, and I'm
>> recompiling with UDEREF=n.
> passing pax_nouderef on the kernel cmdline should be enough ;)
This should be documented in the F
El 26/12/10 21:06, pagee...@freemail.hu escribió:
> On 26 Dec 2010 at 19:59, "Tóth Attila" wrote:
>
>> I don't know if it is related or not. I don't use ext4 and have no
>> symptoms of disappearing root. I attach a photo taken using a recent
>> kernel. The latest crashes I've experienced for the pa
On 26 Dec 2010 at 19:59, "Tóth Attila" wrote:
> I don't know if it is related or not. I don't use ext4 and have no
> symptoms of disappearing root. I attach a photo taken using a recent
> kernel. The latest crashes I've experienced for the past few months
> prevented syncing, so didn't get logged.
On 26 Dec 2010 at 14:09, Michael Orlitzky wrote:
> Challenge accepted. I'm dressed, the car's cleaned off, and I'm
> recompiling with UDEREF=n.
passing pax_nouderef on the kernel cmdline should be enough ;)
On 12/26/2010 12:57 PM, pagee...@freemail.hu wrote:
> On 26 Dec 2010 at 12:06, Michael Orlitzky wrote:
>
>> I do have UDEREF enabled:
>>
>> # grep UDEREF .config
>> CONFIG_PAX_MEMORY_UDEREF=y
>>
>> I can try disabling it when I'd be willing to drive to work and reboot
>> the thing.
>
> ok, in
On 12/26/2010 12:57 PM, pagee...@freemail.hu wrote:
> On 26 Dec 2010 at 12:06, Michael Orlitzky wrote:
>
>> I do have UDEREF enabled:
>>
>> # grep UDEREF .config
>> CONFIG_PAX_MEMORY_UDEREF=y
>>
>> I can try disabling it when I'd be willing to drive to work and reboot
>> the thing.
>
> ok, in
On 26 Dec 2010 at 12:06, Michael Orlitzky wrote:
> I do have UDEREF enabled:
>
> # grep UDEREF .config
> CONFIG_PAX_MEMORY_UDEREF=y
>
> I can try disabling it when I'd be willing to drive to work and reboot
> the thing.
ok, in this case don't worry about it as i'm sure it's a known bug.
if
On 12/26/2010 03:46 AM, pagee...@freemail.hu wrote:
> On 26 Dec 2010 at 1:59, Michael Orlitzky wrote:
>
>> I've got (at least) two servers that lose their root partition after
>> this upgrade. One of them has an HP cciss SCSI RAID controller; the
>> other has a single IDE hard drive. Assuming the
On 12/26/2010 03:46 AM, pagee...@freemail.hu wrote:
> On 26 Dec 2010 at 1:59, Michael Orlitzky wrote:
>
>> I've got (at least) two servers that lose their root partition after
>> this upgrade. One of them has an HP cciss SCSI RAID controller; the
>> other has a single IDE hard drive. Assuming the
On 12/26/2010 03:46 AM, pagee...@freemail.hu wrote:
> On 26 Dec 2010 at 1:59, Michael Orlitzky wrote:
>
>> I've got (at least) two servers that lose their root partition after
>> this upgrade. One of them has an HP cciss SCSI RAID controller; the
>> other has a single IDE hard drive. Assuming the
On 26 Dec 2010 at 1:59, Michael Orlitzky wrote:
> I've got (at least) two servers that lose their root partition after
> this upgrade. One of them has an HP cciss SCSI RAID controller; the
> other has a single IDE hard drive. Assuming the problem is something
> common, I'll stick to describing the
25 matches
Mail list logo
