Andrew Morton wrote:
> On Thu, 30 Aug 2007 09:24:18 + Nigel Kukard <[EMAIL PROTECTED]> wrote:
>
>> Hrmmm,
>>
>
> > > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
> > > 0x0001c807
> > > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status
Andrew Morton wrote:
On Thu, 30 Aug 2007 09:24:18 + Nigel Kukard [EMAIL PROTECTED] wrote:
Hrmmm,
Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
0x0001c807
Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
0x0001c807
On Thu, 30 Aug 2007 09:24:18 + Nigel Kukard <[EMAIL PROTECTED]> wrote:
> Hrmmm,
>
> >> >
> >> > > > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
> >> > > > 0x0001c807
> >> > > > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
> >> > > >
On Thu, 30 Aug 2007 09:24:18 + Nigel Kukard [EMAIL PROTECTED] wrote:
Hrmmm,
Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
0x0001c807
Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
0x0001c807
Unrelated to
Hrmmm,
>> >
>> > > > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
>> > > > 0x0001c807
>> > > > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
>> > > > 0x0001c807
>> >
>> > Unrelated to the other error, but I've been meaning to ask for a
Hrmmm,
Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
0x0001c807
Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
0x0001c807
Unrelated to the other error, but I've been meaning to ask for a while..
If this is
> >
> > > > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
> > > > 0x0001c807
> > > > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
> > > > 0x0001c807
> >
> > Unrelated to the other error, but I've been meaning to ask for a while..
> > If
On Thu, Jun 14, 2007 at 02:28:54PM -0400, Dave Jones wrote:
> On Thu, Jun 14, 2007 at 12:21:49PM -0400, Jeff Garzik wrote:
>
> > > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
> > > 0x0001c807
> > > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
Hi Jeff,
Ok ... second part of my problem. Where should I look in trying to debug
the below problem...
Regards
Nigel
Jun 18 07:59:56 nigel-m2v kernel: ata2.00: exception Emask 0x0 SAct 0x0
SErr 0x0 action 0x2 frozen
Jun 18 07:59:56 nigel-m2v kernel: ata2.00: cmd
Hi Jeff,
Ok ... second part of my problem. Where should I look in trying to debug
the below problem...
Regards
Nigel
Jun 18 07:59:56 nigel-m2v kernel: ata2.00: exception Emask 0x0 SAct 0x0
SErr 0x0 action 0x2 frozen
Jun 18 07:59:56 nigel-m2v kernel: ata2.00: cmd
On Thu, Jun 14, 2007 at 02:28:54PM -0400, Dave Jones wrote:
On Thu, Jun 14, 2007 at 12:21:49PM -0400, Jeff Garzik wrote:
Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
0x0001c807
Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
0x0001c807
Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
0x0001c807
Unrelated to the other error, but I've been meaning to ask for a while..
If this is 'abnormal', why
On Thu, Jun 14, 2007 at 12:21:49PM -0400, Jeff Garzik wrote:
> > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
> > 0x0001c807
> > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
> > 0x0001c807
Unrelated to the other error, but I've been meaning to
Nigel Kukard wrote:
I'm stumped trying to track down the below intermittent problem.
I've confirmed this problem on 2.6.19, 2.6.20 and 2.6.21.
Jun 14 07:55:52 nigel-m2v kernel: ata2.00: exception Emask 0x0 SAct 0x0
SErr 0x0 action 0x2 frozen
Jun 14 07:55:52 nigel-m2v kernel: ata2.00: cmd
>> I'm stumped trying to track down the below intermittent problem.
>>
>> I've confirmed this problem on 2.6.19, 2.6.20 and 2.6.21.
>>
>> Any help greatly appreciated!
>>
>> Regards
>> Nigel
>>
>>
>> Jun 14 07:55:52 nigel-m2v kernel: ata2.00: exception Emask 0x0 SAct 0x0
>> SErr 0x0 action
Nigel Kukard wrote:
I'm stumped trying to track down the below intermittent problem.
I've confirmed this problem on 2.6.19, 2.6.20 and 2.6.21.
Any help greatly appreciated!
Regards
Nigel
Jun 14 07:55:52 nigel-m2v kernel: ata2.00: exception Emask 0x0 SAct 0x0
SErr 0x0 action 0x2 frozen
Nigel Kukard wrote:
I'm stumped trying to track down the below intermittent problem.
I've confirmed this problem on 2.6.19, 2.6.20 and 2.6.21.
Any help greatly appreciated!
Regards
Nigel
Jun 14 07:55:52 nigel-m2v kernel: ata2.00: exception Emask 0x0 SAct 0x0
SErr 0x0 action 0x2 frozen
I'm stumped trying to track down the below intermittent problem.
I've confirmed this problem on 2.6.19, 2.6.20 and 2.6.21.
Any help greatly appreciated!
Regards
Nigel
Jun 14 07:55:52 nigel-m2v kernel: ata2.00: exception Emask 0x0 SAct 0x0
SErr 0x0 action 0x2 frozen
Jun 14
Nigel Kukard wrote:
I'm stumped trying to track down the below intermittent problem.
I've confirmed this problem on 2.6.19, 2.6.20 and 2.6.21.
Jun 14 07:55:52 nigel-m2v kernel: ata2.00: exception Emask 0x0 SAct 0x0
SErr 0x0 action 0x2 frozen
Jun 14 07:55:52 nigel-m2v kernel: ata2.00: cmd
On Thu, Jun 14, 2007 at 12:21:49PM -0400, Jeff Garzik wrote:
Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
0x0001c807
Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
0x0001c807
Unrelated to the other error, but I've been meaning to ask for a
Christian wrote:
I'm seeing the same here since a few days. Before it worked great (even with
NCQ). I've been getting those messages since 2.6.21-rc3-mm1 and with the
latest Ubuntu feisty kernel (2.6.20-11-generic #2 SMP Thu Mar 15 03:43:56 UTC
2007 x86_64 GNU/Linux)
System is Athlon64 X2,
I'm seeing the same here since a few days. Before it worked great (even with
NCQ). I've been getting those messages since 2.6.21-rc3-mm1 and with the
latest Ubuntu feisty kernel (2.6.20-11-generic #2 SMP Thu Mar 15 03:43:56 UTC
2007 x86_64 GNU/Linux)
System is Athlon64 X2, Nforce4, 3x Samsung
I'm seeing the same here since a few days. Before it worked great (even with
NCQ). I've been getting those messages since 2.6.21-rc3-mm1 and with the
latest Ubuntu feisty kernel (2.6.20-11-generic #2 SMP Thu Mar 15 03:43:56 UTC
2007 x86_64 GNU/Linux)
System is Athlon64 X2, Nforce4, 3x Samsung
Christian wrote:
I'm seeing the same here since a few days. Before it worked great (even with
NCQ). I've been getting those messages since 2.6.21-rc3-mm1 and with the
latest Ubuntu feisty kernel (2.6.20-11-generic #2 SMP Thu Mar 15 03:43:56 UTC
2007 x86_64 GNU/Linux)
System is Athlon64 X2,
On Fri, 16 Mar 2007 17:44:25 -0600
Robert Hancock <[EMAIL PROTECTED]> wrote:
> Charles Shannon Hendrix wrote:
> > I normally run a modified 2.6.19 kernel and it works great.
> >
> > I recently tried 2.6.20 and had severe SATA problems with it.
> >
> > Yesterday I tried 2.6.20.3, and the
On Friday 16 March 2007 23:44, you wrote:
> Charles Shannon Hendrix wrote:
> > I normally run a modified 2.6.19 kernel and it works great.
> >
> > I recently tried 2.6.20 and had severe SATA problems with it.
> >
> > Yesterday I tried 2.6.20.3, and the problems are still there.
>
> Can you try
Charles Shannon Hendrix wrote:
I normally run a modified 2.6.19 kernel and it works great.
I recently tried 2.6.20 and had severe SATA problems with it.
Yesterday I tried 2.6.20.3, and the problems are still there.
Can you try 2.6.21-rc and see if the problem is fixed in those kernels?
--
On Fri, 16 Mar 2007 11:58:21 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Charles Shannon Hendrix wrote:
> > I normally run a modified 2.6.19 kernel and it works great.
> >
> > I recently tried 2.6.20 and had severe SATA problems with it.
> >
> > Yesterday I tried 2.6.20.3, and the problems
Charles Shannon Hendrix wrote:
I normally run a modified 2.6.19 kernel and it works great.
I recently tried 2.6.20 and had severe SATA problems with it.
Yesterday I tried 2.6.20.3, and the problems are still there.
Setting the module parameter 'adma' to zero fixes this, yes?
Jeff
Charles Shannon Hendrix wrote:
I normally run a modified 2.6.19 kernel and it works great.
I recently tried 2.6.20 and had severe SATA problems with it.
Yesterday I tried 2.6.20.3, and the problems are still there.
Setting the module parameter 'adma' to zero fixes this, yes?
Jeff
On Fri, 16 Mar 2007 11:58:21 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:
Charles Shannon Hendrix wrote:
I normally run a modified 2.6.19 kernel and it works great.
I recently tried 2.6.20 and had severe SATA problems with it.
Yesterday I tried 2.6.20.3, and the problems are still
Charles Shannon Hendrix wrote:
I normally run a modified 2.6.19 kernel and it works great.
I recently tried 2.6.20 and had severe SATA problems with it.
Yesterday I tried 2.6.20.3, and the problems are still there.
Can you try 2.6.21-rc and see if the problem is fixed in those kernels?
--
On Friday 16 March 2007 23:44, you wrote:
Charles Shannon Hendrix wrote:
I normally run a modified 2.6.19 kernel and it works great.
I recently tried 2.6.20 and had severe SATA problems with it.
Yesterday I tried 2.6.20.3, and the problems are still there.
Can you try 2.6.21-rc and
On Fri, 16 Mar 2007 17:44:25 -0600
Robert Hancock [EMAIL PROTECTED] wrote:
Charles Shannon Hendrix wrote:
I normally run a modified 2.6.19 kernel and it works great.
I recently tried 2.6.20 and had severe SATA problems with it.
Yesterday I tried 2.6.20.3, and the problems are still
Tejun Heo wrote:
Pablo Sebastian Greco wrote:
Tejun Heo wrote:
* Pablo, the bug you saw was bad interaction between blacklisted NCQ
device and dynamic queue depth adjustment. Patches are submitted to fix
the problem. Just drop the blacklist patch. Your drives should work
fine in NCQ
Tejun Heo wrote:
Pablo Sebastian Greco wrote:
Tejun Heo wrote:
* Pablo, the bug you saw was bad interaction between blacklisted NCQ
device and dynamic queue depth adjustment. Patches are submitted to fix
the problem. Just drop the blacklist patch. Your drives should work
fine in NCQ
Heo
> Cc: Pablo Sebastian Greco; linux-kernel@vger.kernel.org
> Subject: Re: SATA problems
>
> Tejun,
>
> I checked out the kernel 2.6.19 to 2.6.20 Changelog. Seems like you
> fixed a problem with the JMB363. The Asus P5B-Deluxe I am using has a
> JMB363 - besides an Intel
Tejun,
I checked out the kernel 2.6.19 to 2.6.20 Changelog. Seems like you
fixed a problem with the JMB363. The Asus P5B-Deluxe I am using has a
JMB363 - besides an Intel ICH8R - with the SATA ports set to AHCI as
well. Looks like that might have been the source of the problem in
2.6.19.
Tejun,
thanks. In preparation of your patch I installed a vanilla 2.6.20.1
kernel on my FC6
system. Amazingly the problem went away with the vanilla(!) kernel and NCQ
is enabled at boot time (queue_depth is 31). I guess I should have
tried that kernel
earlier.
The patches you sent earlier apply
Marcus Haebler wrote:
> thanks for the patches! I am on an Intel P965/ICH8R.
I see. That can happen too. There was a race window where in-flight
r/w command which left SCSI midlayer but pending on libata gets executed
in the wrong mode. If possible, please verify that it doesn't happen
with
Pablo Sebastian Greco wrote:
> Tejun Heo wrote:
>> * Pablo, the bug you saw was bad interaction between blacklisted NCQ
>> device and dynamic queue depth adjustment. Patches are submitted to fix
>> the problem. Just drop the blacklist patch. Your drives should work
>> fine in NCQ mode. My gut
Tejun,
thanks for the patches! I am on an Intel P965/ICH8R.
Best,
Marcus
On 2/20/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
* Pablo, the bug you saw was bad interaction between blacklisted NCQ
device and dynamic queue depth adjustment. Patches are submitted to fix
the problem. Just drop the
Tejun Heo wrote:
* Pablo, the bug you saw was bad interaction between blacklisted NCQ
device and dynamic queue depth adjustment. Patches are submitted to fix
the problem. Just drop the blacklist patch. Your drives should work
fine in NCQ mode. My gut feeling is that your problem is power
* Pablo, the bug you saw was bad interaction between blacklisted NCQ
device and dynamic queue depth adjustment. Patches are submitted to fix
the problem. Just drop the blacklist patch. Your drives should work
fine in NCQ mode. My gut feeling is that your problem is power related
from the
* Pablo, the bug you saw was bad interaction between blacklisted NCQ
device and dynamic queue depth adjustment. Patches are submitted to fix
the problem. Just drop the blacklist patch. Your drives should work
fine in NCQ mode. My gut feeling is that your problem is power related
from the
Tejun Heo wrote:
* Pablo, the bug you saw was bad interaction between blacklisted NCQ
device and dynamic queue depth adjustment. Patches are submitted to fix
the problem. Just drop the blacklist patch. Your drives should work
fine in NCQ mode. My gut feeling is that your problem is power
Tejun,
thanks for the patches! I am on an Intel P965/ICH8R.
Best,
Marcus
On 2/20/07, Tejun Heo [EMAIL PROTECTED] wrote:
* Pablo, the bug you saw was bad interaction between blacklisted NCQ
device and dynamic queue depth adjustment. Patches are submitted to fix
the problem. Just drop the
Pablo Sebastian Greco wrote:
Tejun Heo wrote:
* Pablo, the bug you saw was bad interaction between blacklisted NCQ
device and dynamic queue depth adjustment. Patches are submitted to fix
the problem. Just drop the blacklist patch. Your drives should work
fine in NCQ mode. My gut feeling
Marcus Haebler wrote:
thanks for the patches! I am on an Intel P965/ICH8R.
I see. That can happen too. There was a race window where in-flight
r/w command which left SCSI midlayer but pending on libata gets executed
in the wrong mode. If possible, please verify that it doesn't happen
with the
Tejun,
thanks. In preparation of your patch I installed a vanilla 2.6.20.1
kernel on my FC6
system. Amazingly the problem went away with the vanilla(!) kernel and NCQ
is enabled at boot time (queue_depth is 31). I guess I should have
tried that kernel
earlier.
The patches you sent earlier apply
Tejun,
I checked out the kernel 2.6.19 to 2.6.20 Changelog. Seems like you
fixed a problem with the JMB363. The Asus P5B-Deluxe I am using has a
JMB363 - besides an Intel ICH8R - with the SATA ports set to AHCI as
well. Looks like that might have been the source of the problem in
2.6.19.
@vger.kernel.org
Subject: Re: SATA problems
Tejun,
I checked out the kernel 2.6.19 to 2.6.20 Changelog. Seems like you
fixed a problem with the JMB363. The Asus P5B-Deluxe I am using has a
JMB363 - besides an Intel ICH8R - with the SATA ports set to AHCI as
well. Looks like that might have been
Marcus Haebler wrote:
I opened a bug report (228979) on bugzilla.redhat.com on this one because
I have the same issue under FC6 2.6.19-1.2895. Here is the link:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228979
Do you have any more updates on this problem? Is there a way I can
I opened a bug report (228979) on bugzilla.redhat.com on this one because
I have the same issue under FC6 2.6.19-1.2895. Here is the link:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228979
Do you have any more updates on this problem? Is there a way I can help
by providing debug
I opened a bug report (228979) on bugzilla.redhat.com on this one because
I have the same issue under FC6 2.6.19-1.2895. Here is the link:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228979
Do you have any more updates on this problem? Is there a way I can help
by providing debug
Marcus Haebler wrote:
I opened a bug report (228979) on bugzilla.redhat.com on this one because
I have the same issue under FC6 2.6.19-1.2895. Here is the link:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228979
Do you have any more updates on this problem? Is there a way I can
Pablo Sebastian Greco wrote:
> Well, it took me a few days, but I think I'm ready to report back. One
> of the drives was failing, and it stopped after rewiring power supply so
> the last problem seems to be corrected.
> OTOH, your blacklist seems to be needed too, now I'm running FC6
>
Tejun Heo wrote:
Hello, Pablo.
Please apply common hardware debugging method. You know, swap drives.
Use separate power supply for disks, swap cables, etc...
It seems more like a hardware problem at this point.
Thanks.
Well, it took me a few days, but I think I'm ready to report back.
Tejun Heo wrote:
Hello, Pablo.
Please apply common hardware debugging method. You know, swap drives.
Use separate power supply for disks, swap cables, etc...
It seems more like a hardware problem at this point.
Thanks.
Well, it took me a few days, but I think I'm ready to report back.
Pablo Sebastian Greco wrote:
Well, it took me a few days, but I think I'm ready to report back. One
of the drives was failing, and it stopped after rewiring power supply so
the last problem seems to be corrected.
OTOH, your blacklist seems to be needed too, now I'm running FC6
distribution
Hello, Pablo.
Please apply common hardware debugging method. You know, swap drives.
Use separate power supply for disks, swap cables, etc...
It seems more like a hardware problem at this point.
Thanks.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Pablo Sebastian Greco wrote:
Tejun Heo wrote:
Pablo Sebastian Greco wrote:
After an uptime of 13:34 under heavy load and no errors, I'm pretty
sure your patch is correct. Is there a way to backport this to
2.6.18.x?
I forgot this (even though I implemented it) but you can turn off
Pablo Sebastian Greco wrote:
Tejun Heo wrote:
Pablo Sebastian Greco wrote:
After an uptime of 13:34 under heavy load and no errors, I'm pretty
sure your patch is correct. Is there a way to backport this to
2.6.18.x?
I forgot this (even though I implemented it) but you can turn off
Hello, Pablo.
Please apply common hardware debugging method. You know, swap drives.
Use separate power supply for disks, swap cables, etc...
It seems more like a hardware problem at this point.
Thanks.
--
tejun
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
Tejun Heo wrote:
Pablo Sebastian Greco wrote:
After an uptime of 13:34 under heavy load and no errors, I'm pretty
sure your patch is correct. Is there a way to backport this to 2.6.18.x?
I forgot this (even though I implemented it) but you can turn off NCQ by
doing the following.
#
Tejun Heo wrote:
Pablo Sebastian Greco wrote:
After an uptime of 13:34 under heavy load and no errors, I'm pretty
sure your patch is correct. Is there a way to backport this to 2.6.18.x?
I forgot this (even though I implemented it) but you can turn off NCQ by
doing the following.
#
Tejun Heo wrote:
Pablo Sebastian Greco wrote:
After an uptime of 13:34 under heavy load and no errors, I'm pretty
sure your patch is correct. Is there a way to backport this to 2.6.18.x?
I forgot this (even though I implemented it) but you can turn off NCQ by
doing the following.
# echo 1 >
Pablo Sebastian Greco wrote:
> After an uptime of 13:34 under heavy load and no errors, I'm pretty
> sure your patch is correct. Is there a way to backport this to 2.6.18.x?
I forgot this (even though I implemented it) but you can turn off NCQ by
doing the following.
# echo 1 >
Pablo Sebastian Greco wrote:
After an uptime of 13:34 under heavy load and no errors, I'm pretty
sure your patch is correct. Is there a way to backport this to 2.6.18.x?
I forgot this (even though I implemented it) but you can turn off NCQ by
doing the following.
# echo 1
Tejun Heo wrote:
Pablo Sebastian Greco wrote:
After an uptime of 13:34 under heavy load and no errors, I'm pretty
sure your patch is correct. Is there a way to backport this to 2.6.18.x?
I forgot this (even though I implemented it) but you can turn off NCQ by
doing the following.
# echo 1
Pablo Sebastian Greco wrote:
Tejun Heo wrote:
Pablo Sebastian Greco wrote:
By crash I mean the whole system going down, having to reset the entire
machine.
I'm sending you 4 files:
dmesg: current boot dmesg, just a boot, because no errors appeared
after
last crash, since the server is out
Tejun Heo wrote:
Pablo Sebastian Greco wrote:
By crash I mean the whole system going down, having to reset the entire
machine.
I'm sending you 4 files:
dmesg: current boot dmesg, just a boot, because no errors appeared after
last crash, since the server is out of production right now (errors
Tejun Heo wrote:
Pablo Sebastian Greco wrote:
By crash I mean the whole system going down, having to reset the entire
machine.
I'm sending you 4 files:
dmesg: current boot dmesg, just a boot, because no errors appeared after
last crash, since the server is out of production right now (errors
Pablo Sebastian Greco wrote:
Tejun Heo wrote:
Pablo Sebastian Greco wrote:
By crash I mean the whole system going down, having to reset the entire
machine.
I'm sending you 4 files:
dmesg: current boot dmesg, just a boot, because no errors appeared
after
last crash, since the server is out
Pablo Sebastian Greco wrote:
> By crash I mean the whole system going down, having to reset the entire
> machine.
> I'm sending you 4 files:
> dmesg: current boot dmesg, just a boot, because no errors appeared after
> last crash, since the server is out of production right now (errors
> usually
Pablo Sebastian Greco wrote:
> First of all, thanks for everything, and my excuses if I'm doing
> anything wrong, this is my first lkml mail, but I've read all the faq,
> so should be OK.
> This is the machine with the problem:
>
> Intel ServerBoard S5000VSA
> Dual Core Xeon 2.66 (Intel(R)
Pablo Sebastian Greco wrote:
First of all, thanks for everything, and my excuses if I'm doing
anything wrong, this is my first lkml mail, but I've read all the faq,
so should be OK.
This is the machine with the problem:
Intel ServerBoard S5000VSA
Dual Core Xeon 2.66 (Intel(R) Xeon(TM) CPU
Pablo Sebastian Greco wrote:
By crash I mean the whole system going down, having to reset the entire
machine.
I'm sending you 4 files:
dmesg: current boot dmesg, just a boot, because no errors appeared after
last crash, since the server is out of production right now (errors
usually appear
78 matches
Mail list logo
