BIOS SATA legacy mode failure
PATCH 1/1 BIOS SATA legacy mode failure
Hi,
I have been testing the Linux Kernel on a two year Toshiba NB100 netbook of mine, however when I enabled SATA compatibility/legacy mode instead of AHCI mode in the BIOS, the kernel got stuck. I have pasted the relevant dmesg piece along with a patch that fixes it temporarily. What I suspect to be the cause is that the BIOS sets the device into IDE mode, but it will report it as a SATA device and hence libata tries to send ATA commands to it, which obviously makes it go bad. The patch fixes it, by adding a new field to ata_device called exce_cnt, which counts how many exceptions have occured. After three exceptions, it automatically disables the device. Also, please note this is my first ever patch for the kernel :-)
The following dmesg is stuck in an infinite loop. dmesg:
ata3: lost interrupt (Status 0x50)
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33 (no error)
ata3.00: device reported invalid CHS sector 0
ata3: EH complete
Patch that fixes the infinite loop:
drivers/ata/libata-eh.c +8 -0
@@ -2437,6 +2437,14 @@ static void ata_eh_link_report(struct ata_link *link) ehc->i.action, frozen, tries_buf);if (desc)ata_dev_err (ehc->i.dev,"%s\n" , desc); + ehc->i.dev->exce_cnt ++; +ata_dev_warn (ehc->i.dev,"Number of exceptions: %d\n" , ehc->i.dev->exce_cnt); +/** +* The device is failing terribly, +* disable it to prevent damage. +*/ +if (ehc->i.dev->exce_cnt >2 ) +ata_dev_disable (ehc->i.dev); }else { ata_link_err(link, "exception Emask 0x%x " "SAct 0x%x SErr 0x%x action 0x%x%s%s\n",
include/linux/libata.h +2 -1
@@ -660,7 +660,8 @@ struct ata_device {u8 devslp_timing[ATA_LOG_DEVSLP_SIZE ];/* error history */ -int spdn_cnt; +int spdn_cnt;/* Number of speed_downs */ +int exce_cnt;/* Number of exceptions that happenned */ /* ering is CLEAR_END, read comment above CLEAR_END */ struct ata_ering ering; };
Regards,
Levente Kurusa
Quoted 9 lines · Levente Kurusa
Hi,
I have been testing the Linux Kernel on a two year Toshiba NB100 netbook of mine, however when I enabled SATA compatibility/legacy mode instead of AHCI mode in the BIOS, the kernel got stuck. I have pasted the relevant dmesg piece along with a patch that fixes it temporarily. What I suspect to be the cause is that the BIOS sets the device into IDE mode, but it will report it as a SATA device and hence libata tries to send ATA commands to it, which obviously makes it go bad. The patch
No, the commands are the same whichever mode the controller is in. The problem is presumably something else, like maybe some kind of interrupt routing problem when the controller is in legacy mode.
Quoted 52 lines
fixes it, by adding a new field to
ata_devicecalledexce_cnt, which counts how many exceptions have occured. After three exceptions, it automatically disables the device. Also, please note this is my first ever patch for the kernel :-)The following dmesg is stuck in an infinite loop. dmesg:
ata3: lost interrupt (Status0x50)
ata3.00: exception Emask0x0SAct0x0SErr0x0action0x6frozen ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 inres 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33 (no error)
ata3.00: device reported invalid CHS sector 0
ata3: EH completePatch that fixes the infinite loop:
drivers/ata/libata-eh.c +8
-0@@ -2437,6 +2437,14 @@ static void ata_eh_link_report(struct ata_link *link) ehc->i.action, frozen, tries_buf);if (desc)ata_dev_err (ehc->i.dev,"%s\n" , desc); + ehc->i.dev->exce_cnt ++; +ata_dev_warn (ehc->i.dev,"Number of exceptions: %d\n" , ehc->i.dev->exce_cnt); +/** +* The device is failing terribly, +* disable it to prevent damage. +*/ +if (ehc->i.dev->exce_cnt >2 ) +ata_dev_disable (ehc->i.dev); }else {ata_link_err(link, "exception Emask 0x%x " "SAct 0x%x SErr 0x%x action 0x%x%s%s\n",include/linux/libata.h +2
-1@@ -660,7 +660,8 @@ struct ata_device {u8 devslp_timing[ATA_LOG_DEVSLP_SIZE ];/* error history */ -int spdn_cnt; +int spdn_cnt;/* Number of speed_downs */ +int exce_cnt;/* Number of exceptions that happenned */
Quoted 4 lines
/* ering is CLEAR_END, read comment above CLEAR_END */ struct ata_ering ering;};
This doesn't seem like a very good fix. It may prevent the apparent infinite loop but will just prevent that device from functioning at all. It would be better if we could figure out what was actually going wrong.
2013-09-10 06:01 keltezéssel, Robert Hancock írta:
Quoted 11 lines · Levente Kurusa
Quoted 9 lines
Hi,
I have been testing the Linux Kernel on a two year Toshiba NB100 netbook of mine, however when I enabled SATA compatibility/legacy mode instead of AHCI mode in the BIOS, the kernel got stuck. I have pasted the relevant dmesg piece along with a patch that fixes it temporarily. What I suspect to be the cause is that the BIOS sets the device into IDE mode, but it will report it as a SATA device and hence libata tries to send ATA commands to it, which obviously makes it go bad. The patch
Quoted 4 lines
No, the commands are the same whichever mode the controller is in. The problem is presumably something else, like maybe some kind of interrupt routing problem when the controller is in legacy mode.
Yes, I see now.
Quoted 48 lines
Quoted 48 lines
fixes it, by adding a new field to
ata_devicecalledexce_cnt, which counts how many exceptions have occured. After three exceptions, it automatically disables the device. Also, please note this is my first ever patch for the kernel :-)The following dmesg is stuck in an infinite loop. dmesg:
ata3: lost interrupt (Status0x50)
ata3.00: exception Emask0x0SAct0x0SErr0x0action0x6frozen ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 inres 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4(timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33 (no error)
ata3.00: device reported invalid CHS sector 0
ata3: EH completePatch that fixes the infinite loop:
drivers/ata/libata-eh.c +8
-0@@ -2437,6 +2437,14 @@ static void ata_eh_link_report(struct ata_link *link) ehc->i.action, frozen, tries_buf);if (desc)ata_dev_err (ehc->i.dev,"%s\n" , desc); + ehc->i.dev->exce_cnt ++; +ata_dev_warn (ehc->i.dev,"Number of exceptions: %d\n" , ehc->i.dev->exce_cnt); +/** +* The device is failing terribly, +* disable it to prevent damage. +*/ +if (ehc->i.dev->exce_cnt >2 ) +ata_dev_disable (ehc->i.dev); }else {ata_link_err(link, "exception Emask 0x%x " "SAct 0x%x SErr 0x%x action 0x%x%s%s\n",include/linux/libata.h +0
-0@@ -660,7 +660,8 @@ struct ata_device {u8 devslp_timing[ATA_LOG_DEVSLP_SIZE ];
Quoted 15 lines
Quoted 9 lines
include/linux/libata.h +2
-1/* error history */ -int spdn_cnt; +int spdn_cnt;/* Number of speed_downs */ +int exce_cnt;/* Number of exceptions that happenned */
/* ering is CLEAR_END, read comment above CLEAR_END */ struct ata_ering ering;};
This doesn't seem like a very good fix. It may prevent the apparent infinite loop but will just prevent that device from functioning at all. It would be better if we could figure out what was actually going wrong.
I have tested the problem with three different computers, all switched
to legacy/IDE/compatibility mode, and they didn't have this problem. Of course, they could have been set to AHCI mode, and there the kernel would boot normally. Feels strange, but so far I was only able to reproduce the problem with a Toshiba MK8052GSX. On the topic of my patch, I still don't see why a device which fails so terribly that it reports 3 exceptions shouldn't be disabled. Like in this case, it could cause infinite loops.
Signature · 2 lines
Regards, Levente Kurusa
Quoted 85 lines · Levente Kurusa
2013-09-10 06:01 keltezéssel, Robert Hancock írta:
Quoted 13 lines · Levente Kurusa
Quoted 10 lines
Hi,
I have been testing the Linux Kernel on a two year Toshiba NB100 netbook of mine, however when I enabled SATA compatibility/legacy mode instead of AHCI mode in the BIOS, the kernel got stuck. I have pasted the relevant dmesg piece along with a patch that fixes it temporarily. What I suspect to be the cause is that the BIOS sets the device into IDE mode, but it will report it as a SATA device and hence libata tries to send ATA commands to it, which obviously makes it go bad. The patch
Quoted 4 lines
No, the commands are the same whichever mode the controller is in. The problem is presumably something else, like maybe some kind of interrupt routing problem when the controller is in legacy mode.
Yes, I see now.
Quoted 48 lines
Quoted 48 lines
fixes it, by adding a new field to
ata_devicecalledexce_cnt, which counts how many exceptions have occured. After three exceptions, it automatically disables the device. Also, please note this is my first ever patch for the kernel :-)The following dmesg is stuck in an infinite loop. dmesg:
ata3: lost interrupt (Status0x50)
ata3.00: exception Emask0x0SAct0x0SErr0x0action0x6frozen ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 inres 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4(timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33 (no error)
ata3.00: device reported invalid CHS sector 0
ata3: EH completePatch that fixes the infinite loop:
drivers/ata/libata-eh.c +8
-0@@ -2437,6 +2437,14 @@ static void ata_eh_link_report(struct ata_link *link) ehc->i.action, frozen, tries_buf);if (desc)ata_dev_err (ehc->i.dev,"%s\n" , desc); + ehc->i.dev->exce_cnt ++; +ata_dev_warn (ehc->i.dev,"Number of exceptions: %d\n" , ehc->i.dev->exce_cnt); +/** +* The device is failing terribly, +* disable it to prevent damage. +*/ +if (ehc->i.dev->exce_cnt >2 ) +ata_dev_disable (ehc->i.dev); }else {ata_link_err(link, "exception Emask 0x%x " "SAct 0x%x SErr 0x%x action 0x%x%s%s\n",include/linux/libata.h +0
-0@@ -660,7 +660,8 @@ struct ata_device {u8 devslp_timing[ATA_LOG_DEVSLP_SIZE ];Quoted 15 lines
Quoted 9 lines
include/linux/libata.h +2
-1/* error history */ -int spdn_cnt; +int spdn_cnt;/* Number of speed_downs */ +int exce_cnt;/* Number of exceptions that happenned */
/* ering is CLEAR_END, read comment above CLEAR_END */ struct ata_ering ering;};
This doesn't seem like a very good fix. It may prevent the apparent infinite loop but will just prevent that device from functioning at all. It would be better if we could figure out what was actually going wrong.
Quoted 7 lines
I have tested the problem with three different computers, all switched to legacy/IDE/compatibility mode, and they didn't have this problem. Of course, they could have been set to AHCI mode, and there the kernel would boot normally. Feels strange, but so far I was only able to reproduce the problem with a Toshiba MK8052GSX. On the topic of my patch, I still don't see why a device which fails so terribly that it reports 3 exceptions shouldn't be disabled. Like in this case, it could cause infinite loops.
The problem is that this could happen in some cases when you wouldn't want to disable the device, like an error that just happens sporadically and works on retry, or a device you're trying to recover data from.
2013-09-16 06:37 keltezéssel, Robert Hancock írta:
Quoted 94 lines · Levente Kurusa
Quoted 85 lines
2013-09-10 06:01 keltezéssel, Robert Hancock írta:
Quoted 13 lines · Levente Kurusa
Quoted 10 lines
Hi,
I have been testing the Linux Kernel on a two year Toshiba NB100 netbook of mine, however when I enabled SATA compatibility/legacy mode instead of AHCI mode in the BIOS, the kernel got stuck. I have pasted the relevant dmesg piece along with a patch that fixes it temporarily. What I suspect to be the cause is that the BIOS sets the device into IDE mode, but it will report it as a SATA device and hence libata tries to send ATA commands to it, which obviously makes it go bad. The patch
Quoted 4 lines
No, the commands are the same whichever mode the controller is in. The problem is presumably something else, like maybe some kind of interrupt routing problem when the controller is in legacy mode.
Yes, I see now.
Quoted 48 lines
Quoted 48 lines
fixes it, by adding a new field to
ata_devicecalledexce_cnt, which counts how many exceptions have occured. After three exceptions, it automatically disables the device. Also, please note this is my first ever patch for the kernel :-)The following dmesg is stuck in an infinite loop. dmesg:
ata3: lost interrupt (Status0x50)
ata3.00: exception Emask0x0SAct0x0SErr0x0action0x6frozen ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 inres 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4(timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33 (no error)
ata3.00: device reported invalid CHS sector 0
ata3: EH completePatch that fixes the infinite loop:
drivers/ata/libata-eh.c +8
-0@@ -2437,6 +2437,14 @@ static void ata_eh_link_report(struct ata_link *link) ehc->i.action, frozen, tries_buf);if (desc)ata_dev_err (ehc->i.dev,"%s\n" , desc); + ehc->i.dev->exce_cnt ++; +ata_dev_warn (ehc->i.dev,"Number of exceptions: %d\n" , ehc->i.dev->exce_cnt); +/** +* The device is failing terribly, +* disable it to prevent damage. +*/ +if (ehc->i.dev->exce_cnt >2 ) +ata_dev_disable (ehc->i.dev); }else {ata_link_err(link, "exception Emask 0x%x " "SAct 0x%x SErr 0x%x action 0x%x%s%s\n",include/linux/libata.h +0
-0@@ -660,7 +660,8 @@ struct ata_device {u8 devslp_timing[ATA_LOG_DEVSLP_SIZE ];Quoted 15 lines
Quoted 9 lines
include/linux/libata.h +2
-1/* error history */ -int spdn_cnt; +int spdn_cnt;/* Number of speed_downs */ +int exce_cnt;/* Number of exceptions that happenned */
/* ering is CLEAR_END, read comment above CLEAR_END */ struct ata_ering ering;};
This doesn't seem like a very good fix. It may prevent the apparent infinite loop but will just prevent that device from functioning at all. It would be better if we could figure out what was actually going wrong.
Quoted 7 lines
I have tested the problem with three different computers, all switched to legacy/IDE/compatibility mode, and they didn't have this problem. Of course, they could have been set to AHCI mode, and there the kernel would boot normally. Feels strange, but so far I was only able to reproduce the problem with a Toshiba MK8052GSX. On the topic of my patch, I still don't see why a device which fails so terribly that it reports 3 exceptions shouldn't be disabled. Like in this case, it could cause infinite loops.
Quoted 5 lines
The problem is that this could happen in some cases when you wouldn't want to disable the device, like an error that just happens sporadically and works on retry, or a device you're trying to recover data from.
What do you think if I edit the patch in a way, that when an operation successfully completes, it resets exce_cnt to zero. Might as well add a module_param, which can set the maximum value of exce_cnt, while having zero as an option to never disable the device. Please don't think me wrong, I don't want to force this patch, I just want to learn how all this works, and in the process try to make it better. :-)
Signature · 2 lines
Regards, Levente Kurusa
Quoted 105 lines · Levente Kurusa
2013-09-16 06:37 keltezéssel, Robert Hancock írta:
Quoted 98 lines · Levente Kurusa
Quoted 88 lines
2013-09-10 06:01 keltezéssel, Robert Hancock írta:
Quoted 15 lines · Levente Kurusa
Quoted 11 lines
Hi,
I have been testing the Linux Kernel on a two year Toshiba NB100 netbook of mine, however when I enabled SATA compatibility/legacy mode instead of AHCI mode in the BIOS, the kernel got stuck. I have pasted the relevant dmesg piece along with a patch that fixes it temporarily. What I suspect to be the cause is that the BIOS sets the device into IDE mode, but it will report it as a SATA device and hence libata tries to send ATA commands to it, which obviously makes it go bad. The patch
Quoted 4 lines
No, the commands are the same whichever mode the controller is in. The problem is presumably something else, like maybe some kind of interrupt routing problem when the controller is in legacy mode.
Yes, I see now.
Quoted 48 lines
Quoted 48 lines
fixes it, by adding a new field to
ata_devicecalledexce_cnt, which counts how many exceptions have occured. After three exceptions, it automatically disables the device. Also, please note this is my first ever patch for the kernel :-)The following dmesg is stuck in an infinite loop. dmesg:
ata3: lost interrupt (Status0x50)
ata3.00: exception Emask0x0SAct0x0SErr0x0action0x6frozen ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 inres 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4(timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33 (no error)
ata3.00: device reported invalid CHS sector 0
ata3: EH completePatch that fixes the infinite loop:
drivers/ata/libata-eh.c +8
-0@@ -2437,6 +2437,14 @@ static void ata_eh_link_report(struct ata_link *link) ehc->i.action, frozen, tries_buf);if (desc)ata_dev_err (ehc->i.dev,"%s\n" , desc); + ehc->i.dev->exce_cnt ++; +ata_dev_warn (ehc->i.dev,"Number of exceptions: %d\n" , ehc->i.dev->exce_cnt); +/** +* The device is failing terribly, +* disable it to prevent damage. +*/ +if (ehc->i.dev->exce_cnt >2 ) +ata_dev_disable (ehc->i.dev); }else {ata_link_err(link, "exception Emask 0x%x " "SAct 0x%x SErr 0x%x action 0x%x%s%s\n",include/linux/libata.h +0
-0@@ -660,7 +660,8 @@ struct ata_device {u8 devslp_timing[ATA_LOG_DEVSLP_SIZE ];Quoted 15 lines
Quoted 9 lines
include/linux/libata.h +2
-1/* error history */ -int spdn_cnt; +int spdn_cnt;/* Number of speed_downs */ +int exce_cnt;/* Number of exceptions that happenned */
/* ering is CLEAR_END, read comment above CLEAR_END */ struct ata_ering ering;};
This doesn't seem like a very good fix. It may prevent the apparent infinite loop but will just prevent that device from functioning at all. It would be better if we could figure out what was actually going wrong.
Quoted 7 lines
I have tested the problem with three different computers, all switched to legacy/IDE/compatibility mode, and they didn't have this problem. Of course, they could have been set to AHCI mode, and there the kernel would boot normally. Feels strange, but so far I was only able to reproduce the problem with a Toshiba MK8052GSX. On the topic of my patch, I still don't see why a device which fails so terribly that it reports 3 exceptions shouldn't be disabled. Like in this case, it could cause infinite loops.
Quoted 5 lines
The problem is that this could happen in some cases when you wouldn't want to disable the device, like an error that just happens sporadically and works on retry, or a device you're trying to recover data from.
Quoted 6 lines
What do you think if I edit the patch in a way, that when an operation successfully completes, it resets
exce_cntto zero. Might as well add amodule_param, which can set the maximum value ofexce_cnt, while having zero as an option to never disable the device. Please don't think me wrong, I don't want to force this patch, I just want to learn how all this works, and in the process try to make it better. :-)
That would be better, but I think you're still going to have an issue with what magic number to pick to avoid disabling devices inappropriately.
Conceptually, disabling the device doesn't really make sense anyway. If someone in userspace wants to keep trying to read from that device, why would you stop them because of some arbitrary judgement? The kernel itself isn't "locked up" during this process, anything not blocked on I/O to that device should be able to continue running, so that process is only hurting itself. If the system fails to boot from another device due to this, this would likely point out some kind of problem in userspace or the distro boot process being overly serialized.
2013-09-18 03:35 keltezéssel, Robert Hancock írta:
Quoted 117 lines · Levente Kurusa
Quoted 105 lines
2013-09-16 06:37 keltezéssel, Robert Hancock írta:
Quoted 98 lines · Levente Kurusa
Quoted 88 lines
2013-09-10 06:01 keltezéssel, Robert Hancock írta:
Quoted 15 lines · Levente Kurusa
Quoted 11 lines
Hi,
I have been testing the Linux Kernel on a two year Toshiba NB100 netbook of mine, however when I enabled SATA compatibility/legacy mode instead of AHCI mode in the BIOS, the kernel got stuck. I have pasted the relevant dmesg piece along with a patch that fixes it temporarily. What I suspect to be the cause is that the BIOS sets the device into IDE mode, but it will report it as a SATA device and hence libata tries to send ATA commands to it, which obviously makes it go bad. The patch
Quoted 4 lines
No, the commands are the same whichever mode the controller is in. The problem is presumably something else, like maybe some kind of interrupt routing problem when the controller is in legacy mode.
Yes, I see now.
Quoted 48 lines
Quoted 48 lines
fixes it, by adding a new field to
ata_devicecalledexce_cnt, which counts how many exceptions have occured. After three exceptions, it automatically disables the device. Also, please note this is my first ever patch for the kernel :-)The following dmesg is stuck in an infinite loop. dmesg:
ata3: lost interrupt (Status0x50)
ata3.00: exception Emask0x0SAct0x0SErr0x0action0x6frozen ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 inres 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4(timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33 (no error)
ata3.00: device reported invalid CHS sector 0
ata3: EH completePatch that fixes the infinite loop:
drivers/ata/libata-eh.c +8
-0@@ -2437,6 +2437,14 @@ static void ata_eh_link_report(struct ata_link *link) ehc->i.action, frozen, tries_buf);if (desc)ata_dev_err (ehc->i.dev,"%s\n" , desc); + ehc->i.dev->exce_cnt ++; +ata_dev_warn (ehc->i.dev,"Number of exceptions: %d\n" , ehc->i.dev->exce_cnt); +/** +* The device is failing terribly, +* disable it to prevent damage. +*/ +if (ehc->i.dev->exce_cnt >2 ) +ata_dev_disable (ehc->i.dev); }else {ata_link_err(link, "exception Emask 0x%x " "SAct 0x%x SErr 0x%x action 0x%x%s%s\n",include/linux/libata.h +0
-0@@ -660,7 +660,8 @@ struct ata_device {u8 devslp_timing[ATA_LOG_DEVSLP_SIZE ];Quoted 15 lines
Quoted 9 lines
include/linux/libata.h +2
-1/* error history */ -int spdn_cnt; +int spdn_cnt;/* Number of speed_downs */ +int exce_cnt;/* Number of exceptions that happenned */
/* ering is CLEAR_END, read comment above CLEAR_END */ struct ata_ering ering; };This doesn't seem like a very good fix. It may prevent the apparent infinite loop but will just prevent that device from functioning at all. It would be better if we could figure out what was actually going wrong.
Quoted 7 lines
I have tested the problem with three different computers, all switched to legacy/IDE/compatibility mode, and they didn't have this problem. Of course, they could have been set to AHCI mode, and there the kernel would boot normally. Feels strange, but so far I was only able to reproduce the problem with a Toshiba MK8052GSX. On the topic of my patch, I still don't see why a device which fails so terribly that it reports 3 exceptions shouldn't be disabled. Like in this case, it could cause infinite loops.
Quoted 5 lines
The problem is that this could happen in some cases when you wouldn't want to disable the device, like an error that just happens sporadically and works on retry, or a device you're trying to recover data from.
Quoted 6 lines
What do you think if I edit the patch in a way, that when an operation successfully completes, it resets
exce_cntto zero. Might as well add amodule_param, which can set the maximum value ofexce_cnt, while having zero as an option to never disable the device. Please don't think me wrong, I don't want to force this patch, I just want to learn how all this works, and in the process try to make it better. :-)That would be better, but I think you're still going to have an issue with what magic number to pick to avoid disabling devices inappropriately.
Quoted 10 lines
Conceptually, disabling the device doesn't really make sense anyway. If someone in userspace wants to keep trying to read from that device, why would you stop them because of some arbitrary judgement? The kernel itself isn't "locked up" during this process, anything not blocked on I/O to that device should be able to continue running, so that process is only hurting itself. If the system fails to boot from another device due to this, this would likely point out some kind of problem in userspace or the distro boot process being overly serialized.
I have been booting up with the initramfs from ubuntu 13.04, and I have also tried to boot with the ubuntu install cd. They couldn't continue the boot process. I'm gonna spend the weekend trying to figure out where and why the interrupts don't happen. Whether it be a routing or a hardware issue, which I highly doubt due to the fact that Windows XP SP2 was able to boot up without errors.
Signature · 2 lines
Regards, Levente Kurusa
Quoted 108 lines · Levente Kurusa
Quoted 97 lines
Quoted 83 lines
Quoted 78 lines
Quoted 64 lines
Quoted 46 lines
Quoted 46 lines
The following dmesg is stuck in an infinite loop. dmesg:
ata3: lost interrupt (Status0x50)
ata3.00: exception Emask0x0SAct0x0SErr0x0action0x6frozen ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 inres 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4(timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33 (no error)
ata3.00: device reported invalid CHS sector 0
ata3: EH completePatch that fixes the infinite loop:
drivers/ata/libata-eh.c +8
-0@@ -2437,6 +2437,14 @@ static void ata_eh_link_report(struct ata_link *link) ehc->i.action, frozen, tries_buf);if (desc)ata_dev_err (ehc->i.dev,"%s\n" , desc); + ehc->i.dev->exce_cnt ++; + ata_dev_warn(ehc->i.dev, "Number of exceptions: %d\n", ehc->i.dev->exce_cnt); +/** +* The device is failing terribly, +* disable it to prevent damage. +*/ +if (ehc->i.dev->exce_cnt >2 ) +ata_dev_disable (ehc->i.dev);} else { ata_link_err(link, "exception Emask 0x%x " "SAct 0x%x SErr 0x%x action0x%x%s%s\n",
include/linux/libata.h +0
-0@@ -660,7 +660,8 @@ struct ata_device {u8 devslp_timing[ATA_LOG_DEVSLP_SIZE ];Quoted 18 lines
Quoted 10 lines
include/linux/libata.h +2
-1/* error history */ -int spdn_cnt; +int spdn_cnt;/* Number of speed_downs */ +int exce_cnt;/* Number of exceptions that
happenned *//* ering is CLEAR_END, read comment above CLEAR_END */ struct ata_ering ering; };This doesn't seem like a very good fix. It may prevent the apparent infinite loop but will just prevent that device from functioning at all.
It would be better if we could figure out what was actually going wrong.Quoted 11 lines
I have tested the problem with three different computers, all switched to legacy/IDE/compatibility mode, and they didn't have this problem. Of course, they could have been set to AHCI mode, and there the kernel would
boot normally. Feels strange, but so far I was only able to reproduce the
problem with a Toshiba MK8052GSX. On the topic of my patch, I still don't
see why a device which fails so terribly that it reports 3 exceptions shouldn't be disabled. Like in this case, it could cause infinite loops.Quoted 5 lines
The problem is that this could happen in some cases when you wouldn't want to disable the device, like an error that just happens sporadically and works on retry, or a device you're trying to recover data from.
Quoted 8 lines
What do you think if I edit the patch in a way, that when an operation successfully completes, it resets
exce_cntto zero. Might as well add amodule_param, which can set the maximum value ofexce_cnt, while having zero
as an option to never disable the device. Please don't think me wrong, I don't want to force this patch, I just want to learn how all this works, and
in the process try to make it better. :-)That would be better, but I think you're still going to have an issue with what magic number to pick to avoid disabling devices inappropriately.
Quoted 10 lines
Conceptually, disabling the device doesn't really make sense anyway. If someone in userspace wants to keep trying to read from that device, why would you stop them because of some arbitrary judgement? The kernel itself isn't "locked up" during this process, anything not blocked on I/O to that device should be able to continue running, so that process is only hurting itself. If the system fails to boot from another device due to this, this would likely point out some kind of problem in userspace or the distro boot process being overly serialized.
Quoted 6 lines
I have been booting up with the initramfs from ubuntu 13.04, and I have also tried to boot with the ubuntu install cd. They couldn't continue the boot process. I'm gonna spend the weekend trying to figure out where and why the interrupts don't happen. Whether it be a routing or a hardware issue, which I highly doubt due to the fact that Windows XP SP2 was able to boot up without errors.
Are you able to get out full dmesg output from a boot attempt and the contents of /proc/interrupts?
2013-09-21 19:04 keltezéssel, Robert Hancock írta:
Quoted 116 lines · Levente Kurusa
Quoted 108 lines
Quoted 97 lines
Quoted 83 lines
Quoted 78 lines
Quoted 64 lines
Quoted 46 lines
Quoted 46 lines
The following dmesg is stuck in an infinite loop. dmesg:
ata3: lost interrupt (Status0x50)
ata3.00: exception Emask0x0SAct0x0SErr0x0action0x6frozen ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 inres 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4(timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33 (no error)
ata3.00: device reported invalid CHS sector 0
ata3: EH completePatch that fixes the infinite loop:
drivers/ata/libata-eh.c +8
-0@@ -2437,6 +2437,14 @@ static void ata_eh_link_report(struct ata_link *link) ehc->i.action, frozen, tries_buf);if (desc)ata_dev_err (ehc->i.dev,"%s\n" , desc); + ehc->i.dev->exce_cnt ++; + ata_dev_warn(ehc->i.dev, "Number of exceptions: %d\n", ehc->i.dev->exce_cnt); +/** +* The device is failing terribly, +* disable it to prevent damage. +*/ +if (ehc->i.dev->exce_cnt >2 ) +ata_dev_disable (ehc->i.dev);} else { ata_link_err(link, "exception Emask 0x%x " "SAct 0x%x SErr 0x%x action0x%x%s%s\n",
include/linux/libata.h +0
-0@@ -660,7 +660,8 @@ struct ata_device {u8 devslp_timing[ATA_LOG_DEVSLP_SIZE ];Quoted 18 lines
Quoted 10 lines
include/linux/libata.h +2
-1/* error history */ -int spdn_cnt; +int spdn_cnt;/* Number of speed_downs */ +int exce_cnt;/* Number of exceptions that
happenned *//* ering is CLEAR_END, read comment above CLEAR_END */ struct ata_ering ering; };This doesn't seem like a very good fix. It may prevent the apparent infinite loop but will just prevent that device from functioning at all.
It would be better if we could figure out what was actually going wrong.Quoted 11 lines
I have tested the problem with three different computers, all switched to legacy/IDE/compatibility mode, and they didn't have this problem. Of course, they could have been set to AHCI mode, and there the kernel would
boot normally. Feels strange, but so far I was only able to reproduce the
problem with a Toshiba MK8052GSX. On the topic of my patch, I still don't
see why a device which fails so terribly that it reports 3 exceptions shouldn't be disabled. Like in this case, it could cause infinite loops.Quoted 5 lines
The problem is that this could happen in some cases when you wouldn't want to disable the device, like an error that just happens sporadically and works on retry, or a device you're trying to recover data from.
Quoted 8 lines
What do you think if I edit the patch in a way, that when an operation successfully completes, it resets
exce_cntto zero. Might as well add amodule_param, which can set the maximum value ofexce_cnt, while having zero
as an option to never disable the device. Please don't think me wrong, I don't want to force this patch, I just want to learn how all this works, and
in the process try to make it better. :-)That would be better, but I think you're still going to have an issue with what magic number to pick to avoid disabling devices inappropriately.
Quoted 10 lines
Conceptually, disabling the device doesn't really make sense anyway. If someone in userspace wants to keep trying to read from that device, why would you stop them because of some arbitrary judgement? The kernel itself isn't "locked up" during this process, anything not blocked on I/O to that device should be able to continue running, so that process is only hurting itself. If the system fails to boot from another device due to this, this would likely point out some kind of problem in userspace or the distro boot process being overly serialized.
Quoted 6 lines
I have been booting up with the initramfs from ubuntu 13.04, and I have also tried to boot with the ubuntu install cd. They couldn't continue the boot process. I'm gonna spend the weekend trying to figure out where and why the interrupts don't happen. Whether it be a routing or a hardware issue, which I highly doubt due to the fact that Windows XP SP2 was able to boot up without errors.
Quoted 3 lines
Are you able to get out full dmesg output from a boot attempt and the contents of
/proc/interrupts?
As I said before, I am not able to get to the shell, without my 'symptom cure'. With my patch I get the following dmesg output, with some of my debug messages turned off:
http://pastebin.com/5eb5G3Dx/proc/interrupts is here:
http://pastebin.com/84CJey2D
After yesterday's research, I have come to ata_piix.c . That file looks like the real culprit, as my netbook's controller is an Intel ICH7M one, The values I am getting from the device are very different than those
that are expected.
Things I have noticed, but ignored in dmesg:
There is a stack dump, because nobody cared about IRQ#20. I have ignored
this because it is the EHCI IRQ, and I suppose it has nothing to do with ata. The problem is with ata3 or /dev/sdc, while the IRQ happens with /dev/sda, which works fine.
Things I have not noticed before, but did now:
The ACPI errors at ~0.1329
Signature · 2 lines
Regards, Levente Kurusa
Quoted 142 lines · Levente Kurusa
2013-09-21 19:04 keltezéssel, Robert Hancock írta:
Quoted 126 lines · Levente Kurusa
Quoted 117 lines
Quoted 106 lines
Quoted 89 lines
Quoted 84 lines
Quoted 67 lines
Quoted 57 lines
Quoted 57 lines
The following dmesg is stuck in an infinite loop. dmesg:
ata3: lost interrupt (Status0x50)
ata3.00: exception Emask0x0SAct0x0SErr0x0action0x6frozen ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 inres 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4(timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33 (no error)
ata3.00: device reported invalid CHS sector 0
ata3: EH completePatch that fixes the infinite loop:
drivers/ata/libata-eh.c +0
-0@@ -2437,6 +2437,14 @@ static void ata_eh_link_report(struct
ata_link
*link)ehc->i.action, frozen, tries_buf); if (desc) ata_dev_err(ehc->i.dev, "%s\n", desc);drivers/ata/libata-eh.c +2
-0+ ehc->i.dev->exce_cnt ++; + ata_dev_warn(ehc->i.dev, "Number of exceptions:%d\n",
ehc->i.dev->exce_cnt);drivers/ata/libata-eh.c +6
-0+/** +* The device is failing terribly, +* disable it to prevent damage. +*/ +if (ehc->i.dev->exce_cnt >2 ) +ata_dev_disable (ehc->i.dev); } else { ata_link_err(link, "exception Emask 0x%x " "SAct 0x%x SErr 0x%x action0x%x%s%s\n",
include/linux/libata.h +2
-1@@ -660,7 +660,8 @@ struct ata_device {u8 devslp_timing[ATA_LOG_DEVSLP_SIZE ];/* error history */ -int spdn_cnt; +int spdn_cnt;/* Number of speed_downs */ +int exce_cnt;/* Number of exceptions that
happenned *//* ering is CLEAR_END, read comment above CLEAR_END */ struct ata_ering ering;Quoted 10 lines
Quoted 2 lines
};This doesn't seem like a very good fix. It may prevent the apparent infinite loop but will just prevent that device from functioning at all.
It would be better if we could figure out what was actually going wrong.Quoted 13 lines
I have tested the problem with three different computers, all switched
to legacy/IDE/compatibility mode, and they didn't have this problem. Of
course, they could have been set to AHCI mode, and there the kernel would
boot normally. Feels strange, but so far I was only able to reproduce the
problem with a Toshiba MK8052GSX. On the topic of my patch, I still don't
see why a device which fails so terribly that it reports 3 exceptions shouldn't be disabled. Like in this case, it could cause infinite loops.Quoted 5 lines
The problem is that this could happen in some cases when you wouldn't want to disable the device, like an error that just happens sporadically and works on retry, or a device you're trying to recover data from.
Quoted 10 lines
What do you think if I edit the patch in a way, that when an operation successfully completes, it resets
exce_cntto zero. Might as well add amodule_param, which can set the maximum value ofexce_cnt, while having zero
as an option to never disable the device. Please don't think me wrong, I
don't want to force this patch, I just want to learn how all this works,
and
in the process try to make it better. :-)That would be better, but I think you're still going to have an issue with what magic number to pick to avoid disabling devices inappropriately.
Quoted 10 lines
Conceptually, disabling the device doesn't really make sense anyway. If someone in userspace wants to keep trying to read from that device, why would you stop them because of some arbitrary judgement? The kernel itself isn't "locked up" during this process, anything not blocked on I/O to that device should be able to continue running, so that process is only hurting itself. If the system fails to boot from another device due to this, this would likely point out some kind of problem in userspace or the distro boot process being overly serialized.
Quoted 6 lines
I have been booting up with the initramfs from ubuntu 13.04, and I have also tried to boot with the ubuntu install cd. They couldn't continue the boot process. I'm gonna spend the weekend trying to figure out where and why the interrupts don't happen. Whether it be a routing or a hardware issue, which I highly doubt due to the fact that Windows XP SP2 was able to boot up without errors.
Quoted 3 lines
Are you able to get out full dmesg output from a boot attempt and the contents of
/proc/interrupts?As I said before, I am not able to get to the shell, without my 'symptom cure'. With my patch I get the following dmesg output, with
some of my debug messages turned off:
http://pastebin.com/5eb5G3Dx/proc/interruptsis here:
http://pastebin.com/84CJey2D
After yesterday's research, I have come toata_piix.c. That file looks like the real culprit, as my netbook's controller is an Intel ICH7M one, The values I am getting from the device are very different than those that are expected.
Quoted 5 lines
Things I have noticed, but ignored in dmesg:
There is a stack dump, because nobody cared about IRQ#20. I have ignored this because it is the EHCI IRQ, and I suppose it has nothing to do with ata. The problem is with ata3 or/dev/sdc, while the IRQ happens with/dev/sda, which works fine.
I think it is likely related to the problem. The kernel thinks this controller is on IRQ 16, but apparently something is raising un-acknowledged interrupts on IRQ 20 and nothing is coming in on IRQ
16. It seems quite likely that this is actually the ATA controller.
You mentioned that Windows XP was able to work in this mode. I wonder if it was using the IOAPIC, as if not then the IRQ routing is different which might mask the problem. Do you know what IRQ Device Manager reported for this controller in Windows? And was it using any IRQs over 15 (which would indicate the IOAPIC was in use)?
Quoted 3 lines
Things I have not noticed before, but did now:
The ACPI errors at ~0.1329
2013-09-25 08:31 keltezéssel, Robert Hancock írta:
Quoted 154 lines · Levente Kurusa
Quoted 142 lines
2013-09-21 19:04 keltezéssel, Robert Hancock írta:
Quoted 126 lines · Levente Kurusa
Quoted 117 lines
Quoted 106 lines
Quoted 89 lines
Quoted 84 lines
Quoted 67 lines
Quoted 57 lines
Quoted 57 lines
The following dmesg is stuck in an infinite loop. dmesg:
ata3: lost interrupt (Status0x50)
ata3.00: exception Emask0x0SAct0x0SErr0x0action0x6frozen ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 inres 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4(timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33 (no error)
ata3.00: device reported invalid CHS sector 0
ata3: EH completePatch that fixes the infinite loop:
drivers/ata/libata-eh.c +0
-0@@ -2437,6 +2437,14 @@ static void ata_eh_link_report(struct
ata_link
*link)ehc->i.action, frozen, tries_buf); if (desc) ata_dev_err(ehc->i.dev, "%s\n", desc);drivers/ata/libata-eh.c +2
-0+ ehc->i.dev->exce_cnt ++; + ata_dev_warn(ehc->i.dev, "Number of exceptions:%d\n",
ehc->i.dev->exce_cnt);drivers/ata/libata-eh.c +6
-0+/** +* The device is failing terribly, +* disable it to prevent damage. +*/ +if (ehc->i.dev->exce_cnt >2 ) +ata_dev_disable (ehc->i.dev); } else { ata_link_err(link, "exception Emask 0x%x " "SAct 0x%x SErr 0x%x action0x%x%s%s\n",
include/linux/libata.h +2
-1@@ -660,7 +660,8 @@ struct ata_device {u8 devslp_timing[ATA_LOG_DEVSLP_SIZE ];/* error history */ -int spdn_cnt; +int spdn_cnt;/* Number of speed_downs */ +int exce_cnt;/* Number of exceptions that
happenned *//* ering is CLEAR_END, read comment above CLEAR_END */ struct ata_ering ering;Quoted 10 lines
Quoted 2 lines
};This doesn't seem like a very good fix. It may prevent the apparent infinite loop but will just prevent that device from functioning at all.
It would be better if we could figure out what was actually going wrong.Quoted 13 lines
I have tested the problem with three different computers, all switched
to legacy/IDE/compatibility mode, and they didn't have this problem. Of
course, they could have been set to AHCI mode, and there the kernel would
boot normally. Feels strange, but so far I was only able to reproduce the
problem with a Toshiba MK8052GSX. On the topic of my patch, I still don't
see why a device which fails so terribly that it reports 3 exceptions shouldn't be disabled. Like in this case, it could cause infinite loops.Quoted 5 lines
The problem is that this could happen in some cases when you wouldn't want to disable the device, like an error that just happens sporadically and works on retry, or a device you're trying to recover data from.
Quoted 10 lines
What do you think if I edit the patch in a way, that when an operation successfully completes, it resets
exce_cntto zero. Might as well add amodule_param, which can set the maximum value ofexce_cnt, while having zero
as an option to never disable the device. Please don't think me wrong, I
don't want to force this patch, I just want to learn how all this works,
and
in the process try to make it better. :-)That would be better, but I think you're still going to have an issue with what magic number to pick to avoid disabling devices inappropriately.
Quoted 10 lines
Conceptually, disabling the device doesn't really make sense anyway. If someone in userspace wants to keep trying to read from that device, why would you stop them because of some arbitrary judgement? The kernel itself isn't "locked up" during this process, anything not blocked on I/O to that device should be able to continue running, so that process is only hurting itself. If the system fails to boot from another device due to this, this would likely point out some kind of problem in userspace or the distro boot process being overly serialized.
Quoted 6 lines
I have been booting up with the initramfs from ubuntu 13.04, and I have also tried to boot with the ubuntu install cd. They couldn't continue the boot process. I'm gonna spend the weekend trying to figure out where and why the interrupts don't happen. Whether it be a routing or a hardware issue, which I highly doubt due to the fact that Windows XP SP2 was able to boot up without errors.
Quoted 3 lines
Are you able to get out full dmesg output from a boot attempt and the contents of
/proc/interrupts?As I said before, I am not able to get to the shell, without my 'symptom cure'. With my patch I get the following dmesg output, with
some of my debug messages turned off:
http://pastebin.com/5eb5G3Dx/proc/interruptsis here:
http://pastebin.com/84CJey2D
After yesterday's research, I have come toata_piix.c. That file looks like the real culprit, as my netbook's controller is an Intel ICH7M one, The values I am getting from the device are very different than those that are expected.Quoted 5 lines
Things I have noticed, but ignored in dmesg:
There is a stack dump, because nobody cared about IRQ#20. I have ignored this because it is the EHCI IRQ, and I suppose it has nothing to do with ata. The problem is with ata3 or/dev/sdc, while the IRQ happens with/dev/sda, which works fine.I think it is likely related to the problem. The kernel thinks this controller is on IRQ 16, but apparently something is raising un-acknowledged interrupts on IRQ 20 and nothing is coming in on IRQ
16. It seems quite likely that this is actually the ATA controller.
Quoted 5 lines
You mentioned that Windows XP was able to work in this mode. I wonder if it was using the IOAPIC, as if not then the IRQ routing is different which might mask the problem. Do you know what IRQ Device Manager reported for this controller in Windows? And was it using any IRQs over 15 (which would indicate the IOAPIC was in use)?
Hmm, according to WinXP's Device manager for this controller,
it listens to IRQ# 20, and therefore it is using the I/O APIC.
Now, one question remains where is the error that mismaps
controller?
I have created a simple patch which seems to fix this:
---
@@ -1704,6 +1767,8 @@ static int piix_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
hpriv->map = piix_init_sata_map(pdev, port_info,
piix_map_db_table[ent->driver_data]);
+ if(pdev->vendor == 0x8086 && pdev->device == 0x27C4)
+ pdev->irq = 20;
rc = ata_pci_bmdma_prepare_host(pdev, ppi, &host); if (rc)
return rc;
However, I am more than sure that this is not the way to solve this problem. Do you have any idea on where the ideal place would be to implement a fix? According to specs of ICH7M, which is essentially the same as ICH6M, we need to check on what interrupt pin is the SATA controller, and after that check which IRQ line is connected to the I/O APIC and decide the IRQ's number on those findings.
Specs of ICH7: http://www.intel.com/content/dam/doc/datasheet/i-o-controller-hub-7-datasheet.pdf
Device 31 Interrupt Route Register: Chapter 7.1.46
Device 31 Interrupt Pin Register: Chapter 7.1.41
The SATA controller is always Device 31.
Signature · 2 lines
Regards, Levente Kurusa
Quoted 214 lines · Levente Kurusa
2013-09-25 08:31 keltezéssel, Robert Hancock írta:
Quoted 178 lines · Levente Kurusa
Quoted 165 lines
2013-09-21 19:04 keltezéssel, Robert Hancock írta:
Quoted 147 lines · Levente Kurusa
Quoted 137 lines
Quoted 126 lines
Quoted 104 lines
Quoted 97 lines
Quoted 76 lines
Quoted 67 lines
Quoted 61 lines
The following dmesg is stuck in an infinite loop. dmesg:
ata3: lost interrupt (Status0x50)
ata3.00: exception Emask0x0SAct0x0SErr0x0action0x6frozen ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 inres 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4
(timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33 (no error)
ata3.00: device reported invalid CHS sector 0
ata3: EH completePatch that fixes the infinite loop:
drivers/ata/libata-eh.c +0
-0@@ -2437,6 +2437,14 @@ static void ata_eh_link_report(struct
ata_link
*link)ehc->i.action, frozen, tries_buf); if (desc) ata_dev_err(ehc->i.dev, "%s\n",desc);
drivers/ata/libata-eh.c +2
-0+ ehc->i.dev->exce_cnt ++; + ata_dev_warn(ehc->i.dev, "Number of exceptions:%d\n",
ehc->i.dev->exce_cnt);drivers/ata/libata-eh.c +6
-0+/** +* The device is failing terribly, +* disable it to prevent damage. +*/ +if (ehc->i.dev->exce_cnt >2 ) +ata_dev_disable (ehc->i.dev); } else { ata_link_err(link, "exception Emask 0x%x " "SAct 0x%x SErr 0x%x action0x%x%s%s\n",
include/linux/libata.h +1
-1@@ -660,7 +660,8 @@ struct ata_device {u8 devslp_timing[ATA_LOG_DEVSLP_SIZE ];/* error history */ -int spdn_cnt; +int spdn_cnt;/* Number of
speed_downs
*/
+ intexce_cnt; /* Number of exceptions
that
happenned */Quoted 5 lines
/* ering is CLEAR_END, read comment above CLEAR_END */ struct ata_ering ering; };Quoted 9 lines
This doesn't seem like a very good fix. It may prevent the apparent
infinite loop but will just prevent that device from functioning at
all.
It would be better if we could figure out what was actually going wrong.Quoted 16 lines
I have tested the problem with three different computers, all switched
to legacy/IDE/compatibility mode, and they didn't have this problem.
Of
course, they could have been set to AHCI mode, and there the kernel would
boot normally. Feels strange, but so far I was only able to reproduce
the
problem with a Toshiba MK8052GSX. On the topic of my patch, I still don't
see why a device which fails so terribly that it reports 3 exceptions
shouldn't be disabled. Like in this case, it could cause infinite loops.Quoted 7 lines
The problem is that this could happen in some cases when you wouldn't
want to disable the device, like an error that just happens sporadically and works on retry, or a device you're trying to recover
data from.Quoted 14 lines
What do you think if I edit the patch in a way, that when an operation
successfully completes, it resetsexce_cntto zero. Might as well add amodule_param, which can set the maximum value ofexce_cnt, while having
zero
as an option to never disable the device. Please don't think me wrong,
I
don't want to force this patch, I just want to learn how all this works,
and
in the process try to make it better. :-)That would be better, but I think you're still going to have an issue with what magic number to pick to avoid disabling devices inappropriately.
Quoted 10 lines
Conceptually, disabling the device doesn't really make sense anyway. If someone in userspace wants to keep trying to read from that device, why would you stop them because of some arbitrary judgement? The kernel itself isn't "locked up" during this process, anything not blocked on I/O to that device should be able to continue running, so that process is only hurting itself. If the system fails to boot from another device due to this, this would likely point out some kind of problem in userspace or the distro boot process being overly serialized.
Quoted 6 lines
I have been booting up with the initramfs from ubuntu 13.04, and I have also tried to boot with the ubuntu install cd. They couldn't continue the boot process. I'm gonna spend the weekend trying to figure out where and why the interrupts don't happen. Whether it be a routing or a hardware issue, which I highly doubt due to the fact that Windows XP SP2 was able to boot up without errors.
Quoted 3 lines
Are you able to get out full dmesg output from a boot attempt and the contents of
/proc/interrupts?As I said before, I am not able to get to the shell, without my 'symptom cure'. With my patch I get the following dmesg output, with some of my debug messages turned off:
http://pastebin.com/5eb5G3Dx/proc/interruptsis here:
http://pastebin.com/84CJey2D
After yesterday's research, I have come toata_piix.c. That file looks like
the real culprit, as my netbook's controller is an Intel ICH7M one, The values I am getting from the device are very different than those that are expected.Quoted 5 lines
Things I have noticed, but ignored in dmesg:
There is a stack dump, because nobody cared about IRQ#20. I have ignored this because it is the EHCI IRQ, and I suppose it has nothing to do with ata. The problem is with ata3 or/dev/sdc, while the IRQ happens with/dev/sda, which works fine.I think it is likely related to the problem. The kernel thinks this controller is on IRQ 16, but apparently something is raising un-acknowledged interrupts on IRQ 20 and nothing is coming in on IRQ
16. It seems quite likely that this is actually the ATA controller.Quoted 5 lines
You mentioned that Windows XP was able to work in this mode. I wonder if it was using the IOAPIC, as if not then the IRQ routing is different which might mask the problem. Do you know what IRQ Device Manager reported for this controller in Windows? And was it using any IRQs over 15 (which would indicate the IOAPIC was in use)?
Hmm, according to WinXP's Device manager for this controller, it listens to IRQ# 20, and therefore it is using the I/O APIC. Now, one question remains where is the error that mismaps controller?
I have created a simple patch which seems to fix this:
---(quoted diff) +2
-0@@ -1704,6 +1767,8 @@ static int piix_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) hpriv->map = piix_init_sata_map(pdev, port_info, piix_map_db_table[ent->driver_data]); + if(pdev->vendor == 0x8086 && pdev->device == 0x27C4) + pdev->irq = 20; rc = ata_pci_bmdma_prepare_host(pdev, ppi, &host);if (rc) return rc;However, I am more than sure that this is not the way to solve this problem. Do you have any idea on where the ideal place would be to implement a fix? According to specs of ICH7M, which is essentially the same as ICH6M, we need to check on what interrupt pin is the SATA controller, and after that check which IRQ line is connected to the I/O APIC and decide the IRQ's number on those findings.
Quoted 6 lines
Specs of ICH7:
http://www.intel.com/content/dam/doc/datasheet/i-o-controller-hub-7-datasheet.pdf
Device 31 Interrupt Route Register: Chapter 7.1.46 Device 31 Interrupt Pin Register: Chapter 7.1.41The SATA controller is always Device 31.
It would appear that something is messing up with the ACPI IRQ routing on this machine that's causing us to think the controller is on the wrong IRQ. CCing the linux-acpi list to see if anyone has some additional debugging suggestions. I suspect that dumping the DSDT is likely the first step though. If you can get IASL installed, you can do something like:
cat /sys/firmware/acpi/tables/DSDT > dsdt.aml
iasl -d dsdt.aml
That should spit out a dsdt.dsl file which would hopefully have the info needed to figure out what's going on.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
2013-09-28 06:55 keltezéssel, Robert Hancock írta:
Quoted 229 lines · Levente Kurusa
Quoted 214 lines
2013-09-25 08:31 keltezéssel, Robert Hancock írta:
Quoted 178 lines · Levente Kurusa
Quoted 165 lines
2013-09-21 19:04 keltezéssel, Robert Hancock írta:
Quoted 147 lines · Levente Kurusa
Quoted 137 lines
Quoted 126 lines
Quoted 104 lines
Quoted 97 lines
Quoted 76 lines
Quoted 67 lines
Quoted 61 lines
The following dmesg is stuck in an infinite loop. dmesg:
ata3: lost interrupt (Status0x50)
ata3.00: exception Emask0x0SAct0x0SErr0x0action0x6frozen ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 inres 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4
(timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33 (no error)
ata3.00: device reported invalid CHS sector 0
ata3: EH completePatch that fixes the infinite loop:
drivers/ata/libata-eh.c +0
-0@@ -2437,6 +2437,14 @@ static void ata_eh_link_report(struct
ata_link
*link)ehc->i.action, frozen, tries_buf); if (desc) ata_dev_err(ehc->i.dev, "%s\n",desc);
drivers/ata/libata-eh.c +2
-0+ ehc->i.dev->exce_cnt ++; + ata_dev_warn(ehc->i.dev, "Number of exceptions:%d\n",
ehc->i.dev->exce_cnt);drivers/ata/libata-eh.c +6
-0+/** +* The device is failing terribly, +* disable it to prevent damage. +*/ +if (ehc->i.dev->exce_cnt >2 ) +ata_dev_disable (ehc->i.dev); } else { ata_link_err(link, "exception Emask 0x%x " "SAct 0x%x SErr 0x%x action0x%x%s%s\n",
include/linux/libata.h +1
-1@@ -660,7 +660,8 @@ struct ata_device {u8 devslp_timing[ATA_LOG_DEVSLP_SIZE ];/* error history */ -int spdn_cnt; +int spdn_cnt;/* Number of
speed_downs
*/
+ intexce_cnt; /* Number of exceptions
that
happenned */Quoted 5 lines
/* ering is CLEAR_END, read comment above CLEAR_END */ struct ata_ering ering; };Quoted 9 lines
This doesn't seem like a very good fix. It may prevent the apparent
infinite loop but will just prevent that device from functioning at
all.
It would be better if we could figure out what was actually going wrong.Quoted 16 lines
I have tested the problem with three different computers, all switched
to legacy/IDE/compatibility mode, and they didn't have this problem.
Of
course, they could have been set to AHCI mode, and there the kernel would
boot normally. Feels strange, but so far I was only able to reproduce
the
problem with a Toshiba MK8052GSX. On the topic of my patch, I still don't
see why a device which fails so terribly that it reports 3 exceptions
shouldn't be disabled. Like in this case, it could cause infinite loops.Quoted 7 lines
The problem is that this could happen in some cases when you wouldn't
want to disable the device, like an error that just happens sporadically and works on retry, or a device you're trying to recover
data from.Quoted 14 lines
What do you think if I edit the patch in a way, that when an operation
successfully completes, it resetsexce_cntto zero. Might as well add amodule_param, which can set the maximum value ofexce_cnt, while having
zero
as an option to never disable the device. Please don't think me wrong,
I
don't want to force this patch, I just want to learn how all this works,
and
in the process try to make it better. :-)That would be better, but I think you're still going to have an issue with what magic number to pick to avoid disabling devices inappropriately.
Quoted 10 lines
Conceptually, disabling the device doesn't really make sense anyway. If someone in userspace wants to keep trying to read from that device, why would you stop them because of some arbitrary judgement? The kernel itself isn't "locked up" during this process, anything not blocked on I/O to that device should be able to continue running, so that process is only hurting itself. If the system fails to boot from another device due to this, this would likely point out some kind of problem in userspace or the distro boot process being overly serialized.
Quoted 6 lines
I have been booting up with the initramfs from ubuntu 13.04, and I have also tried to boot with the ubuntu install cd. They couldn't continue the boot process. I'm gonna spend the weekend trying to figure out where and why the interrupts don't happen. Whether it be a routing or a hardware issue, which I highly doubt due to the fact that Windows XP SP2 was able to boot up without errors.
Quoted 3 lines
Are you able to get out full dmesg output from a boot attempt and the contents of
/proc/interrupts?As I said before, I am not able to get to the shell, without my 'symptom cure'. With my patch I get the following dmesg output, with some of my debug messages turned off:
http://pastebin.com/5eb5G3Dx/proc/interruptsis here:
http://pastebin.com/84CJey2D
After yesterday's research, I have come toata_piix.c. That file looks like
the real culprit, as my netbook's controller is an Intel ICH7M one, The values I am getting from the device are very different than those that are expected.Quoted 5 lines
Things I have noticed, but ignored in dmesg:
There is a stack dump, because nobody cared about IRQ#20. I have ignored this because it is the EHCI IRQ, and I suppose it has nothing to do with ata. The problem is with ata3 or/dev/sdc, while the IRQ happens with/dev/sda, which works fine.I think it is likely related to the problem. The kernel thinks this controller is on IRQ 16, but apparently something is raising un-acknowledged interrupts on IRQ 20 and nothing is coming in on IRQ
16. It seems quite likely that this is actually the ATA controller.Quoted 5 lines
You mentioned that Windows XP was able to work in this mode. I wonder if it was using the IOAPIC, as if not then the IRQ routing is different which might mask the problem. Do you know what IRQ Device Manager reported for this controller in Windows? And was it using any IRQs over 15 (which would indicate the IOAPIC was in use)?
Hmm, according to WinXP's Device manager for this controller, it listens to IRQ# 20, and therefore it is using the I/O APIC. Now, one question remains where is the error that mismaps controller?
I have created a simple patch which seems to fix this:
---(quoted diff) +2
-0@@ -1704,6 +1767,8 @@ static int piix_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) hpriv->map = piix_init_sata_map(pdev, port_info, piix_map_db_table[ent->driver_data]); + if(pdev->vendor == 0x8086 && pdev->device == 0x27C4) + pdev->irq = 20; rc = ata_pci_bmdma_prepare_host(pdev, ppi, &host);if (rc) return rc;However, I am more than sure that this is not the way to solve this problem. Do you have any idea on where the ideal place would be to implement a fix? According to specs of ICH7M, which is essentially the same as ICH6M, we need to check on what interrupt pin is the SATA controller, and after that check which IRQ line is connected to the I/O APIC and decide the IRQ's number on those findings.
Quoted 6 lines
Specs of ICH7:
http://www.intel.com/content/dam/doc/datasheet/i-o-controller-hub-7-datasheet.pdf
Device 31 Interrupt Route Register: Chapter 7.1.46 Device 31 Interrupt Pin Register: Chapter 7.1.41The SATA controller is always Device 31.
It would appear that something is messing up with the ACPI IRQ routing on this machine that's causing us to think the controller is on the wrong IRQ. CCing the linux-acpi list to see if anyone has some additional debugging suggestions. I suspect that dumping the DSDT is likely the first step though. If you can get IASL installed, you can do something like:
Quoted 6 lines
cat
/sys/firmware/acpi/tables/DSDT> dsdt.aml
iasl -d dsdt.amlThat should spit out a dsdt.dsl file which would hopefully have the info needed to figure out what's going on.
Here is the disassembled DSDT table:
http://pastebin.com/LWNVht9H
The SATA controller is at line 5206.
I also disassembled the SSDT, but nothing interesting was there:
http://pastebin.com/fus5sxU8
I disabled the usage of ACPI for IRQs with acpi=noirq, and it successfully booted up setting itself to IRQ#3. This makes me think that this is the BIOS's fault. I think it would be possible to create a DMI check and forcibly set the irq to 20 if the DMI matches. Any comments on this?
Signature · 6 lines
Regards, Levente Kurusa -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 275 lines · Levente Kurusa
2013-09-28 06:55 keltezéssel, Robert Hancock írta:
Quoted 260 lines · Levente Kurusa
Quoted 243 lines
2013-09-25 08:31 keltezéssel, Robert Hancock írta:
Quoted 204 lines · Levente Kurusa
Quoted 188 lines
2013-09-21 19:04 keltezéssel, Robert Hancock írta:
Quoted 168 lines
Quoted 152 lines · Levente Kurusa
Quoted 139 lines
Quoted 114 lines
Quoted 107 lines
Quoted 93 lines
Quoted 73 lines
Quoted 72 lines
The following dmesg is stuck in an infinite loop.
dmesg:
ata3: lost interrupt (Status 0x50)
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096
in
res 40/00:00:00:00:00/00:00:00:00:00/00
Emask
0x4
(timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33 (no error)
ata3.00: device reported invalid CHS sector 0
ata3: EH completePatch that fixes the infinite loop:
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index f9476fb..eeedf80 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -2437,6 +2437,14 @@ static void ata_eh_link_report(struct
ata_link
*link)
ehc->i.action, frozen,
tries_buf);
if (desc)
ata_dev_err(ehc->i.dev, "%s\n",
desc);
+ ehc->i.dev->exce_cnt ++;
+ ata_dev_warn(ehc->i.dev, "Number of exceptions:
%d\n",
ehc->i.dev->exce_cnt);
+ /**
+ * The device is failing terribly,
+ * disable it to prevent damage.
+ */
+ if(ehc->i.dev->exce_cnt > 2)
+ ata_dev_disable(ehc->i.dev);
} else {
ata_link_err(link, "exception Emask 0x%x
"
"SAct 0x%x SErr 0x%x action
0x%x%s%s\n",
diff --git a/include/linux/libata.h b/include/linux/libata.h
index eae7a05..fa52ee6 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -660,7 +660,8 @@ struct ata_device {
u8
devslp_timing[ATA_LOG_DEVSLP_SIZE];/* error history */
- int spdn_cnt;
+ int spdn_cnt; /* Number of
speed_downs
*/
+ int exce_cnt; /* Number of
exceptions
that
happenned */
/* ering is CLEAR_END, read comment above
CLEAR_END
*/
struct ata_ering ering;
};Quoted 10 lines
This doesn't seem like a very good fix. It may prevent the apparent
infinite loop but will just prevent that device from functioning at
all.
It would be better if we could figure out what was actually going
wrong.I have tested the problem with three different computers, all switched
to legacy/IDE/compatibility mode, and they didn't have this problem.
Of
course, they could have been set to AHCI mode, and there the kernel
would
boot normally. Feels strange, but so far I was only able to reproduceQuoted 8 lines
the
problem with a Toshiba MK8052GSX. On the topic of my patch, I still
don't
see why a device which fails so terribly that it reports 3 exceptions
shouldn't be disabled. Like in this case, it could cause infinite loops.Quoted 7 lines
The problem is that this could happen in some cases when you wouldn't
want to disable the device, like an error that just happens sporadically and works on retry, or a device you're trying to recover
data from.Quoted 15 lines
What do you think if I edit the patch in a way, that when an operation
successfully completes, it resetsexce_cntto zero. Might as well add
amodule_param, which can set the maximum value ofexce_cnt, while having
zero
as an option to never disable the device. Please don't think me wrong,
I
don't want to force this patch, I just want to learn how all this works,
and
in the process try to make it better. :-)That would be better, but I think you're still going to have an issue
with what magic number to pick to avoid disabling devices inappropriately.Quoted 12 lines
Conceptually, disabling the device doesn't really make sense anyway. If someone in userspace wants to keep trying to read from that device,
why would you stop them because of some arbitrary judgement? The kernel itself isn't "locked up" during this process, anything not blocked on I/O to that device should be able to continue running, so that process is only hurting itself. If the system fails to boot from
another device due to this, this would likely point out some kind of problem in userspace or the distro boot process being overly serialized.Quoted 10 lines
I have been booting up with the initramfs from ubuntu 13.04, and I have also tried to boot with the ubuntu install cd. They couldn't
continue the boot process. I'm gonna spend the weekend trying to figure
out where and why the interrupts don't happen. Whether it be a routing
or a hardware issue, which I highly doubt due to the fact that Windows
XP SP2 was able to boot up without errors.Quoted 3 lines
Are you able to get out full dmesg output from a boot attempt and the contents of
/proc/interrupts?As I said before, I am not able to get to the shell, without my 'symptom
cure'. With my patch I get the following dmesg output, with some of my debug messages turned off:
http://pastebin.com/5eb5G3Dx/proc/interruptsis here:
http://pastebin.com/84CJey2D
After yesterday's research, I have come toata_piix.c. That file looks like
the real culprit, as my netbook's controller is an Intel ICH7M one, The values I am getting from the device are very different than those that are expected.Quoted 7 lines
Things I have noticed, but ignored in dmesg:
There is a stack dump, because nobody cared about IRQ#20. I have ignored
this because it is the EHCI IRQ, and I suppose it has nothing to do with
ata. The problem is with ata3 or/dev/sdc, while the IRQ happens with/dev/sda, which works fine.I think it is likely related to the problem. The kernel thinks this controller is on IRQ 16, but apparently something is raising un-acknowledged interrupts on IRQ 20 and nothing is coming in on IRQ
16. It seems quite likely that this is actually the ATA controller.Quoted 5 lines
You mentioned that Windows XP was able to work in this mode. I wonder if it was using the IOAPIC, as if not then the IRQ routing is different which might mask the problem. Do you know what IRQ Device Manager reported for this controller in Windows? And was it using any IRQs over 15 (which would indicate the IOAPIC was in use)?
Hmm, according to WinXP's Device manager for this controller, it listens to IRQ# 20, and therefore it is using the I/O APIC. Now, one question remains where is the error that mismaps controller?
I have created a simple patch which seems to fix this:
---(quoted diff) +0
-0@@ -1704,6 +1767,8 @@ static int piix_init_one(struct pci_dev *pdev,const
structpci_device_id*ent)hpriv->map = piix_init_sata_map(pdev, port_info,piix_map_db_table[ent->driver_data]);
(quoted diff) +2
-0+ if(pdev->vendor == 0x8086 && pdev->device == 0x27C4) + pdev->irq = 20; rc = ata_pci_bmdma_prepare_host(pdev, ppi, &host); if (rc) return rc;However, I am more than sure that this is not the way to solve this problem. Do you have any idea on where the ideal place would be to implement a fix? According to specs of ICH7M, which is essentially the same as ICH6M, we need to check on what interrupt pin is the SATA controller, and after that check which IRQ line is connected to the I/O APIC and decide the IRQ's number on those findings.
Quoted 7 lines
Specs of ICH7:
http://www.intel.com/content/dam/doc/datasheet/i-o-controller-hub-7-datasheet.pdf
Device 31 Interrupt Route Register: Chapter 7.1.46 Device 31 Interrupt Pin Register: Chapter 7.1.41The SATA controller is always Device 31.
It would appear that something is messing up with the ACPI IRQ routing on this machine that's causing us to think the controller is on the wrong IRQ. CCing the linux-acpi list to see if anyone has some additional debugging suggestions. I suspect that dumping the DSDT is likely the first step though. If you can get IASL installed, you can do something like:
Quoted 6 lines
cat
/sys/firmware/acpi/tables/DSDT> dsdt.aml
iasl -d dsdt.amlThat should spit out a dsdt.dsl file which would hopefully have the info needed to figure out what's going on.
Here is the disassembled DSDT table:
http://pastebin.com/LWNVht9H
The SATA controller is at line 5206.
I also disassembled the SSDT, but nothing interesting was there:
http://pastebin.com/fus5sxU8
Quoted 6 lines
I disabled the usage of ACPI for IRQs with acpi=noirq, and it successfully booted up setting itself to IRQ#3. This makes me think that this is the BIOS's fault. I think it would be possible to create a DMI check and forcibly set the irq to 20 if the DMI matches. Any comments on this?
The BIOS may be doing something funky, but since Windows apparently can figure out it's on IRQ 20, Linux presumably should be able to as well. DMI checks should be the last resort - Windows almost certainly doesn't have any machine-specific logic here, and it's hard to tell what other machine models could be affected. With ACPI stuff, we generally just need to do the same thing Windows does for things to work reliably, and DMI checks are more of a hack workaround than a real fix.
I'll try and have a look at the DSDT within the next few days and see if I can figure anything out, unless someone beats me to it. --
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 292 lines · Robert Hancock
Quoted 275 lines · Levente Kurusa
2013-09-28 06:55 keltezéssel, Robert Hancock írta:
Quoted 260 lines · Levente Kurusa
Quoted 243 lines
2013-09-25 08:31 keltezéssel, Robert Hancock írta:
Quoted 204 lines · Levente Kurusa
Quoted 188 lines
2013-09-21 19:04 keltezéssel, Robert Hancock írta:
Quoted 168 lines
Quoted 152 lines · Levente Kurusa
Quoted 139 lines
Quoted 114 lines
Quoted 107 lines
Quoted 93 lines
Quoted 83 lines
The following dmesg is stuck in an infinite loop.
dmesg:
ata3: lost interrupt (Status 0x50)
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096
in
res 40/00:00:00:00:00/00:00:00:00:00/00
Emask
0x4
(timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33 (no error)
ata3.00: device reported invalid CHS sector 0
ata3: EH completePatch that fixes the infinite loop:
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index f9476fb..eeedf80 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -2437,6 +2437,14 @@ static void ata_eh_link_report(struct
ata_link
*link)
ehc->i.action, frozen,
tries_buf);
if (desc)
ata_dev_err(ehc->i.dev, "%s\n",
desc);
+ ehc->i.dev->exce_cnt ++;
+ ata_dev_warn(ehc->i.dev, "Number of exceptions:
%d\n",
ehc->i.dev->exce_cnt);
+ /**
+ * The device is failing terribly,
+ * disable it to prevent damage.
+ */
+ if(ehc->i.dev->exce_cnt > 2)
+ ata_dev_disable(ehc->i.dev);
} else {
ata_link_err(link, "exception Emask 0x%x
"
"SAct 0x%x SErr 0x%x action
0x%x%s%s\n",
diff --git a/include/linux/libata.h b/include/linux/libata.h
index eae7a05..fa52ee6 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -660,7 +660,8 @@ struct ata_device {
u8
devslp_timing[ATA_LOG_DEVSLP_SIZE];/* error history */
- int spdn_cnt;
+ int spdn_cnt; /* Number of
speed_downs
*/
+ int exce_cnt; /* Number of
exceptions
that
happenned */
/* ering is CLEAR_END, read comment above
CLEAR_END
*/
struct ata_ering ering;
};This doesn't seem like a very good fix. It may prevent the
apparent
infinite loop but will just prevent that device from functioning
at
all.
It would be better if we could figure out what was actually
going
wrong.I have tested the problem with three different computers, all switched
to legacy/IDE/compatibility mode, and they didn't have this problem.
Of
course, they could have been set to AHCI mode, and there the kernel
would
boot normally. Feels strange, but so far I was only able to reproduceQuoted 8 lines
the
problem with a Toshiba MK8052GSX. On the topic of my patch, I still
don't
see why a device which fails so terribly that it reports 3 exceptions
shouldn't be disabled. Like in this case, it could cause infinite loops.Quoted 7 lines
The problem is that this could happen in some cases when you wouldn't
want to disable the device, like an error that just happens sporadically and works on retry, or a device you're trying to recover
data from.Quoted 15 lines
What do you think if I edit the patch in a way, that when an operation
successfully completes, it resetsexce_cntto zero. Might as well add
amodule_param, which can set the maximum value ofexce_cnt, while having
zero
as an option to never disable the device. Please don't think me wrong,
I
don't want to force this patch, I just want to learn how all this works,
and
in the process try to make it better. :-)That would be better, but I think you're still going to have an issue
with what magic number to pick to avoid disabling devices inappropriately.Quoted 12 lines
Conceptually, disabling the device doesn't really make sense anyway. If someone in userspace wants to keep trying to read from that device,
why would you stop them because of some arbitrary judgement? The kernel itself isn't "locked up" during this process, anything not blocked on I/O to that device should be able to continue running, so that process is only hurting itself. If the system fails to boot from
another device due to this, this would likely point out some kind of problem in userspace or the distro boot process being overly serialized.Quoted 10 lines
I have been booting up with the initramfs from ubuntu 13.04, and I have also tried to boot with the ubuntu install cd. They couldn't
continue the boot process. I'm gonna spend the weekend trying to figure
out where and why the interrupts don't happen. Whether it be a routing
or a hardware issue, which I highly doubt due to the fact that Windows
XP SP2 was able to boot up without errors.Quoted 3 lines
Are you able to get out full dmesg output from a boot attempt and the contents of
/proc/interrupts?As I said before, I am not able to get to the shell, without my 'symptom
cure'. With my patch I get the following dmesg output, with some of my debug messages turned off:
http://pastebin.com/5eb5G3Dx/proc/interruptsis here:
http://pastebin.com/84CJey2D
After yesterday's research, I have come toata_piix.c. That file looks like
the real culprit, as my netbook's controller is an Intel ICH7M one, The values I am getting from the device are very different than those that are expected.Quoted 7 lines
Things I have noticed, but ignored in dmesg:
There is a stack dump, because nobody cared about IRQ#20. I have ignored
this because it is the EHCI IRQ, and I suppose it has nothing to do with
ata. The problem is with ata3 or/dev/sdc, while the IRQ happens with/dev/sda, which works fine.I think it is likely related to the problem. The kernel thinks this controller is on IRQ 16, but apparently something is raising un-acknowledged interrupts on IRQ 20 and nothing is coming in on IRQ
16. It seems quite likely that this is actually the ATA controller.Quoted 5 lines
You mentioned that Windows XP was able to work in this mode. I wonder if it was using the IOAPIC, as if not then the IRQ routing is different which might mask the problem. Do you know what IRQ Device Manager reported for this controller in Windows? And was it using any IRQs over 15 (which would indicate the IOAPIC was in use)?
Hmm, according to WinXP's Device manager for this controller, it listens to IRQ# 20, and therefore it is using the I/O APIC. Now, one question remains where is the error that mismaps controller?
I have created a simple patch which seems to fix this:
---(quoted diff) +0
-0@@ -1704,6 +1767,8 @@ static int piix_init_one(struct pci_dev *pdev,const
structpci_device_id*ent)hpriv->map = piix_init_sata_map(pdev, port_info,piix_map_db_table[ent->driver_data]);
(quoted diff) +2
-0+ if(pdev->vendor == 0x8086 && pdev->device == 0x27C4) + pdev->irq = 20; rc = ata_pci_bmdma_prepare_host(pdev, ppi, &host); if (rc) return rc;However, I am more than sure that this is not the way to solve this problem. Do you have any idea on where the ideal place would be to implement a fix? According to specs of ICH7M, which is essentially the same as ICH6M, we need to check on what interrupt pin is the SATA controller, and after that check which IRQ line is connected to the I/O APIC and decide the IRQ's number on those findings.
Quoted 7 lines
Specs of ICH7:
http://www.intel.com/content/dam/doc/datasheet/i-o-controller-hub-7-datasheet.pdf
Device 31 Interrupt Route Register: Chapter 7.1.46 Device 31 Interrupt Pin Register: Chapter 7.1.41The SATA controller is always Device 31.
It would appear that something is messing up with the ACPI IRQ routing on this machine that's causing us to think the controller is on the wrong IRQ. CCing the linux-acpi list to see if anyone has some additional debugging suggestions. I suspect that dumping the DSDT is likely the first step though. If you can get IASL installed, you can do something like:
Quoted 6 lines
cat
/sys/firmware/acpi/tables/DSDT> dsdt.aml
iasl -d dsdt.amlThat should spit out a dsdt.dsl file which would hopefully have the info needed to figure out what's going on.
Here is the disassembled DSDT table:
http://pastebin.com/LWNVht9H
The SATA controller is at line 5206.
I also disassembled the SSDT, but nothing interesting was there:
http://pastebin.com/fus5sxU8Quoted 6 lines
I disabled the usage of ACPI for IRQs with acpi=noirq, and it successfully booted up setting itself to IRQ#3. This makes me think that this is the BIOS's fault. I think it would be possible to create a DMI check and forcibly set the irq to 20 if the DMI matches. Any comments on this?
The BIOS may be doing something funky, but since Windows apparently can figure out it's on IRQ 20, Linux presumably should be able to as well. DMI checks should be the last resort - Windows almost certainly doesn't have any machine-specific logic here, and it's hard to tell what other machine models could be affected. With ACPI stuff, we generally just need to do the same thing Windows does for things to work reliably, and DMI checks are more of a hack workaround than a real fix.
Quoted 2 lines
I'll try and have a look at the DSDT within the next few days and see if I can figure anything out, unless someone beats me to it.
I haven't gone into too much detail, but one thing I noticed with the DSDT is that there appear to be some _OSI checks for Windows 2006 (i.e. Vista) that seem to affect various things, including potentially the PCI IRQ routing table. It's possible that their IRQ routing table is broken for legacy mode with an ACPI OS supporting Vista (as current Linux versions do). Could be this slipped through testing if they only tested AHCI mode with Vista installed.
You can try booting with the kernel parameters
acpi_osi=! acpi_osi="Windows 2001 SP3"
That should make the BIOS think we are Windows XP and bypass the Vista code path. If that works, then you might want to check for a BIOS update on this machine.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
2013-10-01 06:25 keltezéssel, Robert Hancock írta:
Quoted 304 lines · Robert Hancock
Quoted 292 lines · Levente Kurusa
Quoted 275 lines
2013-09-28 06:55 keltezéssel, Robert Hancock írta:
Quoted 260 lines · Levente Kurusa
Quoted 243 lines
2013-09-25 08:31 keltezéssel, Robert Hancock írta:
Quoted 204 lines · Levente Kurusa
Quoted 188 lines
2013-09-21 19:04 keltezéssel, Robert Hancock írta:
Quoted 168 lines
Quoted 152 lines · Levente Kurusa
Quoted 139 lines
Quoted 114 lines
Quoted 107 lines
Quoted 101 lines
The following dmesg is stuck in an infinite loop.
dmesg:
ata3: lost interrupt (Status 0x50)
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096
in
res 40/00:00:00:00:00/00:00:00:00:00/00
Emask
0x4
(timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33 (no error)
ata3.00: device reported invalid CHS sector 0
ata3: EH completePatch that fixes the infinite loop:
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index f9476fb..eeedf80 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -2437,6 +2437,14 @@ static void ata_eh_link_report(struct
ata_link
*link)
ehc->i.action, frozen,
tries_buf);
if (desc)
ata_dev_err(ehc->i.dev, "%s\n",
desc);
+ ehc->i.dev->exce_cnt ++;
+ ata_dev_warn(ehc->i.dev, "Number of exceptions:
%d\n",
ehc->i.dev->exce_cnt);
+ /**
+ * The device is failing terribly,
+ * disable it to prevent damage.
+ */
+ if(ehc->i.dev->exce_cnt > 2)
+ ata_dev_disable(ehc->i.dev);
} else {
ata_link_err(link, "exception Emask 0x%x
"
"SAct 0x%x SErr 0x%x action
0x%x%s%s\n",
diff --git a/include/linux/libata.h b/include/linux/libata.h
index eae7a05..fa52ee6 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -660,7 +660,8 @@ struct ata_device {
u8
devslp_timing[ATA_LOG_DEVSLP_SIZE];/* error history */
- int spdn_cnt;
+ int spdn_cnt; /* Number of
speed_downs
*/
+ int exce_cnt; /* Number of
exceptions
that
happenned */
/* ering is CLEAR_END, read comment above
CLEAR_END
*/
struct ata_ering ering;
};This doesn't seem like a very good fix. It may prevent the
apparent
infinite loop but will just prevent that device from functioning
at
all.
It would be better if we could figure out what was actually
going
wrong.I have tested the problem with three different computers, all
switched
to legacy/IDE/compatibility mode, and they didn't have this
problem.
Of
course, they could have been set to AHCI mode, and there the
kernel
would
boot normally. Feels strange, but so far I was only able to
reproduce
the
problem with a Toshiba MK8052GSX. On the topic of my patch, I
still
don't
see why a device which fails so terribly that it reports 3
exceptions
shouldn't be disabled. Like in this case, it could cause infinite
loops.Quoted 7 lines
The problem is that this could happen in some cases when you wouldn't
want to disable the device, like an error that just happens sporadically and works on retry, or a device you're trying to recover
data from.Quoted 15 lines
What do you think if I edit the patch in a way, that when an operation
successfully completes, it resetsexce_cntto zero. Might as well add
amodule_param, which can set the maximum value ofexce_cnt, while having
zero
as an option to never disable the device. Please don't think me wrong,
I
don't want to force this patch, I just want to learn how all this works,
and
in the process try to make it better. :-)That would be better, but I think you're still going to have an issue
with what magic number to pick to avoid disabling devices inappropriately.Quoted 12 lines
Conceptually, disabling the device doesn't really make sense anyway. If someone in userspace wants to keep trying to read from that device,
why would you stop them because of some arbitrary judgement? The kernel itself isn't "locked up" during this process, anything not blocked on I/O to that device should be able to continue running, so that process is only hurting itself. If the system fails to boot from
another device due to this, this would likely point out some kind of problem in userspace or the distro boot process being overly serialized.Quoted 10 lines
I have been booting up with the initramfs from ubuntu 13.04, and I have also tried to boot with the ubuntu install cd. They couldn't
continue the boot process. I'm gonna spend the weekend trying to figure
out where and why the interrupts don't happen. Whether it be a routing
or a hardware issue, which I highly doubt due to the fact that Windows
XP SP2 was able to boot up without errors.Quoted 3 lines
Are you able to get out full dmesg output from a boot attempt and the contents of
/proc/interrupts?As I said before, I am not able to get to the shell, without my 'symptom
cure'. With my patch I get the following dmesg output, with some of my debug messages turned off:
http://pastebin.com/5eb5G3Dx/proc/interruptsis here:
http://pastebin.com/84CJey2D
After yesterday's research, I have come toata_piix.c. That file looks like
the real culprit, as my netbook's controller is an Intel ICH7M one, The values I am getting from the device are very different than those that are expected.Quoted 7 lines
Things I have noticed, but ignored in dmesg:
There is a stack dump, because nobody cared about IRQ#20. I have ignored
this because it is the EHCI IRQ, and I suppose it has nothing to do with
ata. The problem is with ata3 or/dev/sdc, while the IRQ happens with/dev/sda, which works fine.I think it is likely related to the problem. The kernel thinks this controller is on IRQ 16, but apparently something is raising un-acknowledged interrupts on IRQ 20 and nothing is coming in on IRQ
16. It seems quite likely that this is actually the ATA controller.Quoted 5 lines
You mentioned that Windows XP was able to work in this mode. I wonder if it was using the IOAPIC, as if not then the IRQ routing is different which might mask the problem. Do you know what IRQ Device Manager reported for this controller in Windows? And was it using any IRQs over 15 (which would indicate the IOAPIC was in use)?
Hmm, according to WinXP's Device manager for this controller, it listens to IRQ# 20, and therefore it is using the I/O APIC. Now, one question remains where is the error that mismaps controller?
I have created a simple patch which seems to fix this:
---(quoted diff) +0
-0@@ -1704,6 +1767,8 @@ static int piix_init_one(struct pci_dev *pdev,const
structpci_device_id*ent)hpriv->map = piix_init_sata_map(pdev, port_info,piix_map_db_table[ent->driver_data]);
(quoted diff) +2
-0+ if(pdev->vendor == 0x8086 && pdev->device == 0x27C4) + pdev->irq = 20; rc = ata_pci_bmdma_prepare_host(pdev, ppi, &host); if (rc) return rc;However, I am more than sure that this is not the way to solve this problem. Do you have any idea on where the ideal place would be to implement a fix? According to specs of ICH7M, which is essentially the same as ICH6M, we need to check on what interrupt pin is the SATA controller, and after that check which IRQ line is connected to the I/O APIC and decide the IRQ's number on those findings.
Quoted 7 lines
Specs of ICH7:
http://www.intel.com/content/dam/doc/datasheet/i-o-controller-hub-7-datasheet.pdf
Device 31 Interrupt Route Register: Chapter 7.1.46 Device 31 Interrupt Pin Register: Chapter 7.1.41The SATA controller is always Device 31.
It would appear that something is messing up with the ACPI IRQ routing on this machine that's causing us to think the controller is on the wrong IRQ. CCing the linux-acpi list to see if anyone has some additional debugging suggestions. I suspect that dumping the DSDT is likely the first step though. If you can get IASL installed, you can do something like:
Quoted 6 lines
cat
/sys/firmware/acpi/tables/DSDT> dsdt.aml
iasl -d dsdt.amlThat should spit out a dsdt.dsl file which would hopefully have the info needed to figure out what's going on.
Here is the disassembled DSDT table:
http://pastebin.com/LWNVht9H
The SATA controller is at line 5206.
I also disassembled the SSDT, but nothing interesting was there:
http://pastebin.com/fus5sxU8Quoted 6 lines
I disabled the usage of ACPI for IRQs with acpi=noirq, and it successfully booted up setting itself to IRQ#3. This makes me think that this is the BIOS's fault. I think it would be possible to create a DMI check and forcibly set the irq to 20 if the DMI matches. Any comments on this?
The BIOS may be doing something funky, but since Windows apparently can figure out it's on IRQ 20, Linux presumably should be able to as well. DMI checks should be the last resort - Windows almost certainly doesn't have any machine-specific logic here, and it's hard to tell what other machine models could be affected. With ACPI stuff, we generally just need to do the same thing Windows does for things to work reliably, and DMI checks are more of a hack workaround than a real fix.
Quoted 2 lines
I'll try and have a look at the DSDT within the next few days and see if I can figure anything out, unless someone beats me to it.
I haven't gone into too much detail, but one thing I noticed with the DSDT is that there appear to be some
_OSIchecks for Windows 2006 (i.e. Vista) that seem to affect various things, including potentially the PCI IRQ routing table. It's possible that their IRQ routing table is broken for legacy mode with an ACPI OS supporting Vista (as current Linux versions do). Could be this slipped through testing if they only tested AHCI mode with Vista installed.
Quoted 8 lines
You can try booting with the kernel parameters
acpi_osi=! acpi_osi="Windows 2001 SP3"
That should make the BIOS think we are Windows XP and bypass the Vista code path. If that works, then you might want to check for a BIOS update on this machine.
First of all, sorry for the late reply. I was kinda busy.
I tried what you suggested but unfortunately the problem persists. This makes me believe that Windows XP does have somekind of DMI check here. Of course, while a BIOS update may solve this, I would prefer that Linux should also be able to boot up with this broken BIOS as well.
If you are certain that WinXP doesn't use DMI checks, it could be that WinXP's driver of ICH7M's SATA controller applies a quirk and sets that irq line to #20.
Signature · 2 lines
Regards, Levente Kurusa
Quoted 316 lines · Levente Kurusa
2013-10-01 06:25 keltezéssel, Robert Hancock írta:
Quoted 304 lines · Robert Hancock
Quoted 292 lines · Levente Kurusa
Quoted 275 lines
2013-09-28 06:55 keltezéssel, Robert Hancock írta:
Quoted 260 lines · Levente Kurusa
Quoted 243 lines
2013-09-25 08:31 keltezéssel, Robert Hancock írta:
Quoted 204 lines · Levente Kurusa
Quoted 188 lines
2013-09-21 19:04 keltezéssel, Robert Hancock írta:
Quoted 168 lines
Quoted 152 lines · Levente Kurusa
Quoted 139 lines
Quoted 114 lines
Quoted 114 lines
The following dmesg is stuck in an infinite loop.
dmesg:
ata3: lost interrupt (Status 0x50)
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096
in
res 40/00:00:00:00:00/00:00:00:00:00/00
Emask
0x4
(timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33 (no error)
ata3.00: device reported invalid CHS sector 0
ata3: EH completePatch that fixes the infinite loop:
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index f9476fb..eeedf80 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -2437,6 +2437,14 @@ static void ata_eh_link_report(struct
ata_link
*link)
ehc->i.action, frozen,
tries_buf);
if (desc)
ata_dev_err(ehc->i.dev, "%s\n",
desc);
+ ehc->i.dev->exce_cnt ++;
+ ata_dev_warn(ehc->i.dev, "Number of exceptions:
%d\n",
ehc->i.dev->exce_cnt);
+ /**
+ * The device is failing terribly,
+ * disable it to prevent damage.
+ */
+ if(ehc->i.dev->exce_cnt > 2)
+ ata_dev_disable(ehc->i.dev);
} else {
ata_link_err(link, "exception Emask 0x%x
"
"SAct 0x%x SErr 0x%x action
0x%x%s%s\n",
diff --git a/include/linux/libata.h b/include/linux/libata.h
index eae7a05..fa52ee6 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -660,7 +660,8 @@ struct ata_device {
u8
devslp_timing[ATA_LOG_DEVSLP_SIZE];/* error history */
- int spdn_cnt;
+ int spdn_cnt; /* Number of
speed_downs
*/
+ int exce_cnt; /* Number of
exceptions
that
happenned */
/* ering is CLEAR_END, read comment above
CLEAR_END
*/
struct ata_ering ering;
};This doesn't seem like a very good fix. It may prevent the
apparent
infinite loop but will just prevent that device from functioning
at
all.
It would be better if we could figure out what was actually
going
wrong.I have tested the problem with three different computers, all
switched
to legacy/IDE/compatibility mode, and they didn't have this
problem.
Of
course, they could have been set to AHCI mode, and there the
kernel
would
boot normally. Feels strange, but so far I was only able to
reproduce
the
problem with a Toshiba MK8052GSX. On the topic of my patch, I
still
don't
see why a device which fails so terribly that it reports 3
exceptions
shouldn't be disabled. Like in this case, it could cause infinite
loops.The problem is that this could happen in some cases when you
wouldn't
want to disable the device, like an error that just happens
sporadically and works on retry, or a device you're trying to
recover
data from.Quoted 15 lines
What do you think if I edit the patch in a way, that when an operation
successfully completes, it resetsexce_cntto zero. Might as well add
amodule_param, which can set the maximum value ofexce_cnt, while having
zero
as an option to never disable the device. Please don't think me wrong,
I
don't want to force this patch, I just want to learn how all this works,
and
in the process try to make it better. :-)That would be better, but I think you're still going to have an issue
with what magic number to pick to avoid disabling devices inappropriately.Quoted 12 lines
Conceptually, disabling the device doesn't really make sense anyway. If someone in userspace wants to keep trying to read from that device,
why would you stop them because of some arbitrary judgement? The kernel itself isn't "locked up" during this process, anything not blocked on I/O to that device should be able to continue running, so that process is only hurting itself. If the system fails to boot from
another device due to this, this would likely point out some kind of problem in userspace or the distro boot process being overly serialized.Quoted 10 lines
I have been booting up with the initramfs from ubuntu 13.04, and I have also tried to boot with the ubuntu install cd. They couldn't
continue the boot process. I'm gonna spend the weekend trying to figure
out where and why the interrupts don't happen. Whether it be a routing
or a hardware issue, which I highly doubt due to the fact that Windows
XP SP2 was able to boot up without errors.Quoted 3 lines
Are you able to get out full dmesg output from a boot attempt and the contents of
/proc/interrupts?As I said before, I am not able to get to the shell, without my 'symptom
cure'. With my patch I get the following dmesg output, with some of my debug messages turned off:
http://pastebin.com/5eb5G3Dx/proc/interruptsis here:
http://pastebin.com/84CJey2D
After yesterday's research, I have come toata_piix.c. That file looks like
the real culprit, as my netbook's controller is an Intel ICH7M one, The values I am getting from the device are very different than those that are expected.Quoted 7 lines
Things I have noticed, but ignored in dmesg:
There is a stack dump, because nobody cared about IRQ#20. I have ignored
this because it is the EHCI IRQ, and I suppose it has nothing to do with
ata. The problem is with ata3 or/dev/sdc, while the IRQ happens with/dev/sda, which works fine.I think it is likely related to the problem. The kernel thinks this controller is on IRQ 16, but apparently something is raising un-acknowledged interrupts on IRQ 20 and nothing is coming in on IRQ
16. It seems quite likely that this is actually the ATA controller.Quoted 5 lines
You mentioned that Windows XP was able to work in this mode. I wonder if it was using the IOAPIC, as if not then the IRQ routing is different which might mask the problem. Do you know what IRQ Device Manager reported for this controller in Windows? And was it using any IRQs over 15 (which would indicate the IOAPIC was in use)?
Hmm, according to WinXP's Device manager for this controller, it listens to IRQ# 20, and therefore it is using the I/O APIC. Now, one question remains where is the error that mismaps controller?
I have created a simple patch which seems to fix this:
---(quoted diff) +0
-0@@ -1704,6 +1767,8 @@ static int piix_init_one(struct pci_dev *pdev,const
structpci_device_id*ent)hpriv->map = piix_init_sata_map(pdev, port_info,piix_map_db_table[ent->driver_data]);
(quoted diff) +2
-0+ if(pdev->vendor == 0x8086 && pdev->device == 0x27C4) + pdev->irq = 20; rc = ata_pci_bmdma_prepare_host(pdev, ppi, &host); if (rc) return rc;However, I am more than sure that this is not the way to solve this problem. Do you have any idea on where the ideal place would be to implement a fix? According to specs of ICH7M, which is essentially the same as ICH6M, we need to check on what interrupt pin is the SATA controller, and after that check which IRQ line is connected to the I/O APIC and decide the IRQ's number on those findings.
Quoted 7 lines
Specs of ICH7:
http://www.intel.com/content/dam/doc/datasheet/i-o-controller-hub-7-datasheet.pdf
Device 31 Interrupt Route Register: Chapter 7.1.46 Device 31 Interrupt Pin Register: Chapter 7.1.41The SATA controller is always Device 31.
It would appear that something is messing up with the ACPI IRQ routing on this machine that's causing us to think the controller is on the wrong IRQ. CCing the linux-acpi list to see if anyone has some additional debugging suggestions. I suspect that dumping the DSDT is likely the first step though. If you can get IASL installed, you can do something like:
Quoted 6 lines
cat
/sys/firmware/acpi/tables/DSDT> dsdt.aml
iasl -d dsdt.amlThat should spit out a dsdt.dsl file which would hopefully have the info needed to figure out what's going on.
Here is the disassembled DSDT table:
http://pastebin.com/LWNVht9H
The SATA controller is at line 5206.
I also disassembled the SSDT, but nothing interesting was there:
http://pastebin.com/fus5sxU8Quoted 6 lines
I disabled the usage of ACPI for IRQs with acpi=noirq, and it successfully booted up setting itself to IRQ#3. This makes me think that this is the BIOS's fault. I think it would be possible to create a DMI check and forcibly set the irq to 20 if the DMI matches. Any comments on this?
The BIOS may be doing something funky, but since Windows apparently can figure out it's on IRQ 20, Linux presumably should be able to as well. DMI checks should be the last resort - Windows almost certainly doesn't have any machine-specific logic here, and it's hard to tell what other machine models could be affected. With ACPI stuff, we generally just need to do the same thing Windows does for things to work reliably, and DMI checks are more of a hack workaround than a real fix.
Quoted 2 lines
I'll try and have a look at the DSDT within the next few days and see if I can figure anything out, unless someone beats me to it.
I haven't gone into too much detail, but one thing I noticed with the DSDT is that there appear to be some
_OSIchecks for Windows 2006 (i.e. Vista) that seem to affect various things, including potentially the PCI IRQ routing table. It's possible that their IRQ routing table is broken for legacy mode with an ACPI OS supporting Vista (as current Linux versions do). Could be this slipped through testing if they only tested AHCI mode with Vista installed.Quoted 8 lines
You can try booting with the kernel parameters
acpi_osi=! acpi_osi="Windows 2001 SP3"
That should make the BIOS think we are Windows XP and bypass the Vista code path. If that works, then you might want to check for a BIOS update on this machine.
First of all, sorry for the late reply. I was kinda busy.
Quoted 8 lines
I tried what you suggested but unfortunately the problem persists. This makes me believe that Windows XP does have somekind of DMI check here. Of course, while a BIOS update may solve this, I would prefer that Linux should also be able to boot up with this broken BIOS as well.
If you are certain that WinXP doesn't use DMI checks, it could be that WinXP's driver of ICH7M's SATA controller applies a quirk and sets that irq line to #20.
Can you post the dmesg output from a bootup attempt with those options?
You may also want to try adding just: acpi_osi=!
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
2013-10-12 04:06 keltezéssel, Robert Hancock írta:
Quoted 322 lines · Levente Kurusa
Quoted 321 lines
2013-10-01 06:25 keltezéssel, Robert Hancock írta:
Quoted 304 lines · Robert Hancock
Quoted 292 lines · Levente Kurusa
Quoted 275 lines
2013-09-28 06:55 keltezéssel, Robert Hancock írta:
Quoted 260 lines · Levente Kurusa
Quoted 243 lines
2013-09-25 08:31 keltezéssel, Robert Hancock írta:
Quoted 204 lines · Levente Kurusa
Quoted 188 lines
2013-09-21 19:04 keltezéssel, Robert Hancock írta:
Quoted 168 lines
Quoted 152 lines · Levente Kurusa
Quoted 139 lines
Quoted 129 lines
The following dmesg is stuck in an infinite loop.
dmesg:
ata3: lost interrupt (Status 0x50)
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096
in
res 40/00:00:00:00:00/00:00:00:00:00/00
Emask
0x4
(timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33 (no error)
ata3.00: device reported invalid CHS sector 0
ata3: EH completePatch that fixes the infinite loop:
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index f9476fb..eeedf80 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -2437,6 +2437,14 @@ static void ata_eh_link_report(struct
ata_link
*link)
ehc->i.action, frozen,
tries_buf);
if (desc)
ata_dev_err(ehc->i.dev, "%s\n",
desc);
+ ehc->i.dev->exce_cnt ++;
+ ata_dev_warn(ehc->i.dev, "Number of exceptions:
%d\n",
ehc->i.dev->exce_cnt);
+ /**
+ * The device is failing terribly,
+ * disable it to prevent damage.
+ */
+ if(ehc->i.dev->exce_cnt > 2)
+ ata_dev_disable(ehc->i.dev);
} else {
ata_link_err(link, "exception Emask 0x%x
"
"SAct 0x%x SErr 0x%x action
0x%x%s%s\n",
diff --git a/include/linux/libata.h b/include/linux/libata.h
index eae7a05..fa52ee6 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -660,7 +660,8 @@ struct ata_device {
u8
devslp_timing[ATA_LOG_DEVSLP_SIZE];/* error history */
- int spdn_cnt;
+ int spdn_cnt; /* Number of
speed_downs
*/
+ int exce_cnt; /* Number of
exceptions
that
happenned */
/* ering is CLEAR_END, read comment above
CLEAR_END
*/
struct ata_ering ering;
};This doesn't seem like a very good fix. It may prevent the
apparent
infinite loop but will just prevent that device from functioning
at
all.
It would be better if we could figure out what was actually
going
wrong.I have tested the problem with three different computers, all
switched
to legacy/IDE/compatibility mode, and they didn't have this
problem.
Of
course, they could have been set to AHCI mode, and there the
kernel
would
boot normally. Feels strange, but so far I was only able to
reproduce
the
problem with a Toshiba MK8052GSX. On the topic of my patch, I
still
don't
see why a device which fails so terribly that it reports 3
exceptions
shouldn't be disabled. Like in this case, it could cause infinite
loops.The problem is that this could happen in some cases when you
wouldn't
want to disable the device, like an error that just happens
sporadically and works on retry, or a device you're trying to
recover
data from.What do you think if I edit the patch in a way, that when an
operation
successfully completes, it resets exce_cnt to zero. Might as well
add
a
module_param, which can set the maximum value of exce_cnt, while
having
zero
as an option to never disable the device. Please don't think me
wrong,
I
don't want to force this patch, I just want to learn how all this
works,
and
in the process try to make it better. :-)That would be better, but I think you're still going to have an issue
with what magic number to pick to avoid disabling devices inappropriately.Quoted 12 lines
Conceptually, disabling the device doesn't really make sense anyway. If someone in userspace wants to keep trying to read from that device,
why would you stop them because of some arbitrary judgement? The kernel itself isn't "locked up" during this process, anything not blocked on I/O to that device should be able to continue running, so that process is only hurting itself. If the system fails to boot from
another device due to this, this would likely point out some kind of problem in userspace or the distro boot process being overly serialized.Quoted 10 lines
I have been booting up with the initramfs from ubuntu 13.04, and I have also tried to boot with the ubuntu install cd. They couldn't
continue the boot process. I'm gonna spend the weekend trying to figure
out where and why the interrupts don't happen. Whether it be a routing
or a hardware issue, which I highly doubt due to the fact that Windows
XP SP2 was able to boot up without errors.Quoted 3 lines
Are you able to get out full dmesg output from a boot attempt and the contents of
/proc/interrupts?As I said before, I am not able to get to the shell, without my 'symptom
cure'. With my patch I get the following dmesg output, with some of my debug messages turned off:
http://pastebin.com/5eb5G3Dx/proc/interruptsis here:
http://pastebin.com/84CJey2D
After yesterday's research, I have come toata_piix.c. That file looks like
the real culprit, as my netbook's controller is an Intel ICH7M one, The values I am getting from the device are very different than those that are expected.Quoted 7 lines
Things I have noticed, but ignored in dmesg:
There is a stack dump, because nobody cared about IRQ#20. I have ignored
this because it is the EHCI IRQ, and I suppose it has nothing to do with
ata. The problem is with ata3 or/dev/sdc, while the IRQ happens with/dev/sda, which works fine.I think it is likely related to the problem. The kernel thinks this controller is on IRQ 16, but apparently something is raising un-acknowledged interrupts on IRQ 20 and nothing is coming in on IRQ
16. It seems quite likely that this is actually the ATA controller.Quoted 5 lines
You mentioned that Windows XP was able to work in this mode. I wonder if it was using the IOAPIC, as if not then the IRQ routing is different which might mask the problem. Do you know what IRQ Device Manager reported for this controller in Windows? And was it using any IRQs over 15 (which would indicate the IOAPIC was in use)?
Hmm, according to WinXP's Device manager for this controller, it listens to IRQ# 20, and therefore it is using the I/O APIC. Now, one question remains where is the error that mismaps controller?
I have created a simple patch which seems to fix this:
---(quoted diff) +0
-0@@ -1704,6 +1767,8 @@ static int piix_init_one(struct pci_dev *pdev,const
structpci_device_id*ent)hpriv->map = piix_init_sata_map(pdev, port_info,piix_map_db_table[ent->driver_data]);
(quoted diff) +2
-0+ if(pdev->vendor == 0x8086 && pdev->device == 0x27C4) + pdev->irq = 20; rc = ata_pci_bmdma_prepare_host(pdev, ppi, &host); if (rc) return rc;However, I am more than sure that this is not the way to solve this problem. Do you have any idea on where the ideal place would be to implement a fix? According to specs of ICH7M, which is essentially the same as ICH6M, we need to check on what interrupt pin is the SATA controller, and after that check which IRQ line is connected to the I/O APIC and decide the IRQ's number on those findings.
Quoted 7 lines
Specs of ICH7:
http://www.intel.com/content/dam/doc/datasheet/i-o-controller-hub-7-datasheet.pdf
Device 31 Interrupt Route Register: Chapter 7.1.46 Device 31 Interrupt Pin Register: Chapter 7.1.41The SATA controller is always Device 31.
It would appear that something is messing up with the ACPI IRQ routing on this machine that's causing us to think the controller is on the wrong IRQ. CCing the linux-acpi list to see if anyone has some additional debugging suggestions. I suspect that dumping the DSDT is likely the first step though. If you can get IASL installed, you can do something like:
Quoted 6 lines
cat
/sys/firmware/acpi/tables/DSDT> dsdt.aml
iasl -d dsdt.amlThat should spit out a dsdt.dsl file which would hopefully have the info needed to figure out what's going on.
Here is the disassembled DSDT table:
http://pastebin.com/LWNVht9H
The SATA controller is at line 5206.
I also disassembled the SSDT, but nothing interesting was there:
http://pastebin.com/fus5sxU8Quoted 6 lines
I disabled the usage of ACPI for IRQs with acpi=noirq, and it successfully booted up setting itself to IRQ#3. This makes me think that this is the BIOS's fault. I think it would be possible to create a DMI check and forcibly set the irq to 20 if the DMI matches. Any comments on this?
The BIOS may be doing something funky, but since Windows apparently can figure out it's on IRQ 20, Linux presumably should be able to as well. DMI checks should be the last resort - Windows almost certainly doesn't have any machine-specific logic here, and it's hard to tell what other machine models could be affected. With ACPI stuff, we generally just need to do the same thing Windows does for things to work reliably, and DMI checks are more of a hack workaround than a real fix.
Quoted 2 lines
I'll try and have a look at the DSDT within the next few days and see if I can figure anything out, unless someone beats me to it.
I haven't gone into too much detail, but one thing I noticed with the DSDT is that there appear to be some
_OSIchecks for Windows 2006 (i.e. Vista) that seem to affect various things, including potentially the PCI IRQ routing table. It's possible that their IRQ routing table is broken for legacy mode with an ACPI OS supporting Vista (as current Linux versions do). Could be this slipped through testing if they only tested AHCI mode with Vista installed.Quoted 8 lines
You can try booting with the kernel parameters
acpi_osi=! acpi_osi="Windows 2001 SP3"
That should make the BIOS think we are Windows XP and bypass the Vista code path. If that works, then you might want to check for a BIOS update on this machine.
First of all, sorry for the late reply. I was kinda busy.
I tried what you suggested but unfortunately the problem persists. This makes me believe that Windows XP does have somekind of DMI check here. Of course, while a BIOS update may solve this, I would prefer that Linux should also be able to boot up with this broken BIOS as well.
Quoted 8 lines
Quoted 3 lines
If you are certain that WinXP doesn't use DMI checks, it could be that WinXP's driver of ICH7M's SATA controller applies a quirk and sets that irq line to #20.
Can you post the dmesg output from a bootup attempt with those options?
You may also want to try adding just: acpi_osi=!
None of the 3 possible combinations succeeded to boot.
Here are a couple of dmesgs:
Params: acpi_osi="Windows 2001 SP3"
http://pastebin.com/vF3BSuhc
Params: acpi_osi=! acpi_osi="Windows 2001 SP3"
http://pastebin.com/BuUzc3es
Params: acpi_osi=!
http://pastebin.com/u7uRx8Ru
Signature · 2 lines
Regards, Levente Kurusa
Quoted 336 lines · Levente Kurusa
2013-10-12 04:06 keltezéssel, Robert Hancock írta:
Quoted 322 lines · Levente Kurusa
Quoted 321 lines
2013-10-01 06:25 keltezéssel, Robert Hancock írta:
Quoted 304 lines · Robert Hancock
Quoted 292 lines · Levente Kurusa
Quoted 275 lines
2013-09-28 06:55 keltezéssel, Robert Hancock írta:
Quoted 260 lines · Levente Kurusa
Quoted 243 lines
2013-09-25 08:31 keltezéssel, Robert Hancock írta:
Quoted 204 lines · Levente Kurusa
Quoted 188 lines
2013-09-21 19:04 keltezéssel, Robert Hancock írta:
Quoted 168 lines
Quoted 152 lines · Levente Kurusa
Quoted 151 lines
The following dmesg is stuck in an infinite loop.
dmesg:
ata3: lost interrupt (Status 0x50)
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096
in
res 40/00:00:00:00:00/00:00:00:00:00/00
Emask
0x4
(timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33 (no error)
ata3.00: device reported invalid CHS sector 0
ata3: EH completePatch that fixes the infinite loop:
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index f9476fb..eeedf80 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -2437,6 +2437,14 @@ static void ata_eh_link_report(struct
ata_link
*link)
ehc->i.action, frozen,
tries_buf);
if (desc)
ata_dev_err(ehc->i.dev, "%s\n",
desc);
+ ehc->i.dev->exce_cnt ++;
+ ata_dev_warn(ehc->i.dev, "Number of exceptions:
%d\n",
ehc->i.dev->exce_cnt);
+ /**
+ * The device is failing terribly,
+ * disable it to prevent damage.
+ */
+ if(ehc->i.dev->exce_cnt > 2)
+ ata_dev_disable(ehc->i.dev);
} else {
ata_link_err(link, "exception Emask 0x%x
"
"SAct 0x%x SErr 0x%x action
0x%x%s%s\n",
diff --git a/include/linux/libata.h b/include/linux/libata.h
index eae7a05..fa52ee6 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -660,7 +660,8 @@ struct ata_device {
u8
devslp_timing[ATA_LOG_DEVSLP_SIZE];/* error history */
- int spdn_cnt;
+ int spdn_cnt; /* Number of
speed_downs
*/
+ int exce_cnt; /* Number of
exceptions
that
happenned */
/* ering is CLEAR_END, read comment above
CLEAR_END
*/
struct ata_ering ering;
};This doesn't seem like a very good fix. It may prevent the
apparent
infinite loop but will just prevent that device from functioning
at
all.
It would be better if we could figure out what was actually
going
wrong.I have tested the problem with three different computers, all
switched
to legacy/IDE/compatibility mode, and they didn't have this
problem.
Of
course, they could have been set to AHCI mode, and there the
kernel
would
boot normally. Feels strange, but so far I was only able to
reproduce
the
problem with a Toshiba MK8052GSX. On the topic of my patch, I
still
don't
see why a device which fails so terribly that it reports 3
exceptions
shouldn't be disabled. Like in this case, it could cause infinite
loops.The problem is that this could happen in some cases when you
wouldn't
want to disable the device, like an error that just happens
sporadically and works on retry, or a device you're trying to
recover
data from.What do you think if I edit the patch in a way, that when an
operation
successfully completes, it resets exce_cnt to zero. Might as well
add
a
module_param, which can set the maximum value of exce_cnt, while
having
zero
as an option to never disable the device. Please don't think me
wrong,
I
don't want to force this patch, I just want to learn how all this
works,
and
in the process try to make it better. :-)That would be better, but I think you're still going to have an
issue
with what magic number to pick to avoid disabling devices
inappropriately.Conceptually, disabling the device doesn't really make sense anyway.
If someone in userspace wants to keep trying to read from that
device,
why would you stop them because of some arbitrary judgement? The
kernel itself isn't "locked up" during this process, anything not
blocked on I/O to that device should be able to continue running, so
that process is only hurting itself. If the system fails to boot
from
another device due to this, this would likely point out some kind of
problem in userspace or the distro boot process being overly
serialized.Quoted 10 lines
I have been booting up with the initramfs from ubuntu 13.04, and I have also tried to boot with the ubuntu install cd. They couldn't
continue the boot process. I'm gonna spend the weekend trying to figure
out where and why the interrupts don't happen. Whether it be a routing
or a hardware issue, which I highly doubt due to the fact that Windows
XP SP2 was able to boot up without errors.Quoted 3 lines
Are you able to get out full dmesg output from a boot attempt and the contents of
/proc/interrupts?As I said before, I am not able to get to the shell, without my 'symptom
cure'. With my patch I get the following dmesg output, with some of my debug messages turned off:
http://pastebin.com/5eb5G3Dx/proc/interruptsis here:
http://pastebin.com/84CJey2D
After yesterday's research, I have come toata_piix.c. That file looks like
the real culprit, as my netbook's controller is an Intel ICH7M one, The values I am getting from the device are very different than those that are expected.Quoted 7 lines
Things I have noticed, but ignored in dmesg:
There is a stack dump, because nobody cared about IRQ#20. I have ignored
this because it is the EHCI IRQ, and I suppose it has nothing to do with
ata. The problem is with ata3 or/dev/sdc, while the IRQ happens with/dev/sda, which works fine.I think it is likely related to the problem. The kernel thinks this controller is on IRQ 16, but apparently something is raising un-acknowledged interrupts on IRQ 20 and nothing is coming in on IRQ
16. It seems quite likely that this is actually the ATA controller.Quoted 5 lines
You mentioned that Windows XP was able to work in this mode. I wonder if it was using the IOAPIC, as if not then the IRQ routing is different which might mask the problem. Do you know what IRQ Device Manager reported for this controller in Windows? And was it using any IRQs over 15 (which would indicate the IOAPIC was in use)?
Hmm, according to WinXP's Device manager for this controller, it listens to IRQ# 20, and therefore it is using the I/O APIC. Now, one question remains where is the error that mismaps controller?
I have created a simple patch which seems to fix this:
---(quoted diff) +0
-0@@ -1704,6 +1767,8 @@ static int piix_init_one(struct pci_dev *pdev,const
structpci_device_id*ent)hpriv->map = piix_init_sata_map(pdev, port_info,piix_map_db_table[ent->driver_data]);
(quoted diff) +2
-0+ if(pdev->vendor == 0x8086 && pdev->device == 0x27C4) + pdev->irq = 20; rc = ata_pci_bmdma_prepare_host(pdev, ppi, &host); if (rc) return rc;However, I am more than sure that this is not the way to solve this problem. Do you have any idea on where the ideal place would be to implement a fix? According to specs of ICH7M, which is essentially the same as ICH6M, we need to check on what interrupt pin is the SATA controller, and after that check which IRQ line is connected to the I/O APIC and decide the IRQ's number on those findings.
Quoted 7 lines
Specs of ICH7:
http://www.intel.com/content/dam/doc/datasheet/i-o-controller-hub-7-datasheet.pdf
Device 31 Interrupt Route Register: Chapter 7.1.46 Device 31 Interrupt Pin Register: Chapter 7.1.41The SATA controller is always Device 31.
It would appear that something is messing up with the ACPI IRQ routing on this machine that's causing us to think the controller is on the wrong IRQ. CCing the linux-acpi list to see if anyone has some additional debugging suggestions. I suspect that dumping the DSDT is likely the first step though. If you can get IASL installed, you can do something like:
Quoted 6 lines
cat
/sys/firmware/acpi/tables/DSDT> dsdt.aml
iasl -d dsdt.amlThat should spit out a dsdt.dsl file which would hopefully have the info needed to figure out what's going on.
Here is the disassembled DSDT table:
http://pastebin.com/LWNVht9H
The SATA controller is at line 5206.
I also disassembled the SSDT, but nothing interesting was there:
http://pastebin.com/fus5sxU8Quoted 6 lines
I disabled the usage of ACPI for IRQs with acpi=noirq, and it successfully booted up setting itself to IRQ#3. This makes me think that this is the BIOS's fault. I think it would be possible to create a DMI check and forcibly set the irq to 20 if the DMI matches. Any comments on this?
The BIOS may be doing something funky, but since Windows apparently can figure out it's on IRQ 20, Linux presumably should be able to as well. DMI checks should be the last resort - Windows almost certainly doesn't have any machine-specific logic here, and it's hard to tell what other machine models could be affected. With ACPI stuff, we generally just need to do the same thing Windows does for things to work reliably, and DMI checks are more of a hack workaround than a real fix.
Quoted 2 lines
I'll try and have a look at the DSDT within the next few days and see if I can figure anything out, unless someone beats me to it.
I haven't gone into too much detail, but one thing I noticed with the DSDT is that there appear to be some
_OSIchecks for Windows 2006 (i.e. Vista) that seem to affect various things, including potentially the PCI IRQ routing table. It's possible that their IRQ routing table is broken for legacy mode with an ACPI OS supporting Vista (as current Linux versions do). Could be this slipped through testing if they only tested AHCI mode with Vista installed.Quoted 8 lines
You can try booting with the kernel parameters
acpi_osi=! acpi_osi="Windows 2001 SP3"
That should make the BIOS think we are Windows XP and bypass the Vista code path. If that works, then you might want to check for a BIOS update on this machine.
First of all, sorry for the late reply. I was kinda busy.
I tried what you suggested but unfortunately the problem persists. This makes me believe that Windows XP does have somekind of DMI check here. Of course, while a BIOS update may solve this, I would prefer that Linux should also be able to boot up with this broken BIOS as well.
Quoted 8 lines
Quoted 3 lines
If you are certain that WinXP doesn't use DMI checks, it could be that WinXP's driver of ICH7M's SATA controller applies a quirk and sets that irq line to #20.
Can you post the dmesg output from a bootup attempt with those options?
You may also want to try adding just: acpi_osi=!
None of the 3 possible combinations succeeded to boot.
Here are a couple of dmesgs:
Quoted 8 lines
Params: acpi_osi="Windows 2001 SP3"
http://pastebin.com/vF3BSuhcParams: acpi_osi=! acpi_osi="Windows 2001 SP3"
http://pastebin.com/BuUzc3esParams: acpi_osi=!
http://pastebin.com/u7uRx8Ru
I'm not sure the option is actually taking effect properly. There should be a message "Disabled all _OSI OS vendors" that shows up in dmesg with the ! option. Can you try:
acpi_osi="!" acpi_osi="Windows 2001 SP3"
(with the quotes around the ! character).
2013-10-13 07:57 keltezéssel, Robert Hancock írta:
Quoted 346 lines · Levente Kurusa
Quoted 336 lines
2013-10-12 04:06 keltezéssel, Robert Hancock írta:
Quoted 322 lines · Levente Kurusa
Quoted 321 lines
2013-10-01 06:25 keltezéssel, Robert Hancock írta:
Quoted 304 lines · Robert Hancock
Quoted 292 lines · Levente Kurusa
Quoted 275 lines
2013-09-28 06:55 keltezéssel, Robert Hancock írta:
Quoted 260 lines · Levente Kurusa
Quoted 243 lines
2013-09-25 08:31 keltezéssel, Robert Hancock írta:
Quoted 204 lines · Levente Kurusa
Quoted 188 lines
2013-09-21 19:04 keltezéssel, Robert Hancock írta:
Quoted 168 lines
Quoted 162 lines · Levente Kurusa
The following dmesg is stuck in an infinite loop.
dmesg:
ata3: lost interrupt (Status 0x50)
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096
in
res 40/00:00:00:00:00/00:00:00:00:00/00
Emask
0x4
(timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33 (no error)
ata3.00: device reported invalid CHS sector 0
ata3: EH completePatch that fixes the infinite loop:
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index f9476fb..eeedf80 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -2437,6 +2437,14 @@ static void ata_eh_link_report(struct
ata_link
*link)
ehc->i.action, frozen,
tries_buf);
if (desc)
ata_dev_err(ehc->i.dev, "%s\n",
desc);
+ ehc->i.dev->exce_cnt ++;
+ ata_dev_warn(ehc->i.dev, "Number of exceptions:
%d\n",
ehc->i.dev->exce_cnt);
+ /**
+ * The device is failing terribly,
+ * disable it to prevent damage.
+ */
+ if(ehc->i.dev->exce_cnt > 2)
+ ata_dev_disable(ehc->i.dev);
} else {
ata_link_err(link, "exception Emask 0x%x
"
"SAct 0x%x SErr 0x%x action
0x%x%s%s\n",
diff --git a/include/linux/libata.h b/include/linux/libata.h
index eae7a05..fa52ee6 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -660,7 +660,8 @@ struct ata_device {
u8
devslp_timing[ATA_LOG_DEVSLP_SIZE];/* error history */
- int spdn_cnt;
+ int spdn_cnt; /* Number of
speed_downs
*/
+ int exce_cnt; /* Number of
exceptions
that
happenned */
/* ering is CLEAR_END, read comment above
CLEAR_END
*/
struct ata_ering ering;
};This doesn't seem like a very good fix. It may prevent the
apparent
infinite loop but will just prevent that device from functioning
at
all.
It would be better if we could figure out what was actually
going
wrong.I have tested the problem with three different computers, all
switched
to legacy/IDE/compatibility mode, and they didn't have this
problem.
Of
course, they could have been set to AHCI mode, and there the
kernel
would
boot normally. Feels strange, but so far I was only able to
reproduce
the
problem with a Toshiba MK8052GSX. On the topic of my patch, I
still
don't
see why a device which fails so terribly that it reports 3
exceptions
shouldn't be disabled. Like in this case, it could cause infinite
loops.The problem is that this could happen in some cases when you
wouldn't
want to disable the device, like an error that just happens
sporadically and works on retry, or a device you're trying to
recover
data from.What do you think if I edit the patch in a way, that when an
operation
successfully completes, it resets exce_cnt to zero. Might as well
add
a
module_param, which can set the maximum value of exce_cnt, while
having
zero
as an option to never disable the device. Please don't think me
wrong,
I
don't want to force this patch, I just want to learn how all this
works,
and
in the process try to make it better. :-)That would be better, but I think you're still going to have an
issue
with what magic number to pick to avoid disabling devices
inappropriately.Conceptually, disabling the device doesn't really make sense anyway.
If someone in userspace wants to keep trying to read from that
device,
why would you stop them because of some arbitrary judgement? The
kernel itself isn't "locked up" during this process, anything not
blocked on I/O to that device should be able to continue running, so
that process is only hurting itself. If the system fails to boot
from
another device due to this, this would likely point out some kind of
problem in userspace or the distro boot process being overly
serialized.I have been booting up with the initramfs from ubuntu 13.04,
and I have also tried to boot with the ubuntu install cd. They
couldn't
continue the boot process. I'm gonna spend the weekend trying to
figure
out where and why the interrupts don't happen. Whether it be a
routing
or a hardware issue, which I highly doubt due to the fact that
Windows
XP SP2 was able to boot up without errors.Quoted 3 lines
Are you able to get out full dmesg output from a boot attempt and the contents of
/proc/interrupts?As I said before, I am not able to get to the shell, without my 'symptom
cure'. With my patch I get the following dmesg output, with some of my debug messages turned off:
http://pastebin.com/5eb5G3Dx/proc/interruptsis here:
http://pastebin.com/84CJey2D
After yesterday's research, I have come toata_piix.c. That file looks like
the real culprit, as my netbook's controller is an Intel ICH7M one, The values I am getting from the device are very different than those that are expected.Quoted 7 lines
Things I have noticed, but ignored in dmesg:
There is a stack dump, because nobody cared about IRQ#20. I have ignored
this because it is the EHCI IRQ, and I suppose it has nothing to do with
ata. The problem is with ata3 or/dev/sdc, while the IRQ happens with/dev/sda, which works fine.I think it is likely related to the problem. The kernel thinks this controller is on IRQ 16, but apparently something is raising un-acknowledged interrupts on IRQ 20 and nothing is coming in on IRQ
16. It seems quite likely that this is actually the ATA controller.Quoted 5 lines
You mentioned that Windows XP was able to work in this mode. I wonder if it was using the IOAPIC, as if not then the IRQ routing is different which might mask the problem. Do you know what IRQ Device Manager reported for this controller in Windows? And was it using any IRQs over 15 (which would indicate the IOAPIC was in use)?
Hmm, according to WinXP's Device manager for this controller, it listens to IRQ# 20, and therefore it is using the I/O APIC. Now, one question remains where is the error that mismaps controller?
I have created a simple patch which seems to fix this:
---(quoted diff) +0
-0@@ -1704,6 +1767,8 @@ static int piix_init_one(struct pci_dev *pdev,const
structpci_device_id*ent)hpriv->map = piix_init_sata_map(pdev, port_info,piix_map_db_table[ent->driver_data]);
(quoted diff) +2
-0+ if(pdev->vendor == 0x8086 && pdev->device == 0x27C4) + pdev->irq = 20; rc = ata_pci_bmdma_prepare_host(pdev, ppi, &host); if (rc) return rc;However, I am more than sure that this is not the way to solve this problem. Do you have any idea on where the ideal place would be to implement a fix? According to specs of ICH7M, which is essentially the same as ICH6M, we need to check on what interrupt pin is the SATA controller, and after that check which IRQ line is connected to the I/O APIC and decide the IRQ's number on those findings.
Quoted 7 lines
Specs of ICH7:
http://www.intel.com/content/dam/doc/datasheet/i-o-controller-hub-7-datasheet.pdf
Device 31 Interrupt Route Register: Chapter 7.1.46 Device 31 Interrupt Pin Register: Chapter 7.1.41The SATA controller is always Device 31.
It would appear that something is messing up with the ACPI IRQ routing on this machine that's causing us to think the controller is on the wrong IRQ. CCing the linux-acpi list to see if anyone has some additional debugging suggestions. I suspect that dumping the DSDT is likely the first step though. If you can get IASL installed, you can do something like:
Quoted 6 lines
cat
/sys/firmware/acpi/tables/DSDT> dsdt.aml
iasl -d dsdt.amlThat should spit out a dsdt.dsl file which would hopefully have the info needed to figure out what's going on.
Here is the disassembled DSDT table:
http://pastebin.com/LWNVht9H
The SATA controller is at line 5206.
I also disassembled the SSDT, but nothing interesting was there:
http://pastebin.com/fus5sxU8Quoted 6 lines
I disabled the usage of ACPI for IRQs with acpi=noirq, and it successfully booted up setting itself to IRQ#3. This makes me think that this is the BIOS's fault. I think it would be possible to create a DMI check and forcibly set the irq to 20 if the DMI matches. Any comments on this?
The BIOS may be doing something funky, but since Windows apparently can figure out it's on IRQ 20, Linux presumably should be able to as well. DMI checks should be the last resort - Windows almost certainly doesn't have any machine-specific logic here, and it's hard to tell what other machine models could be affected. With ACPI stuff, we generally just need to do the same thing Windows does for things to work reliably, and DMI checks are more of a hack workaround than a real fix.
Quoted 2 lines
I'll try and have a look at the DSDT within the next few days and see if I can figure anything out, unless someone beats me to it.
I haven't gone into too much detail, but one thing I noticed with the DSDT is that there appear to be some
_OSIchecks for Windows 2006 (i.e. Vista) that seem to affect various things, including potentially the PCI IRQ routing table. It's possible that their IRQ routing table is broken for legacy mode with an ACPI OS supporting Vista (as current Linux versions do). Could be this slipped through testing if they only tested AHCI mode with Vista installed.Quoted 8 lines
You can try booting with the kernel parameters
acpi_osi=! acpi_osi="Windows 2001 SP3"
That should make the BIOS think we are Windows XP and bypass the Vista code path. If that works, then you might want to check for a BIOS update on this machine.
First of all, sorry for the late reply. I was kinda busy.
I tried what you suggested but unfortunately the problem persists. This makes me believe that Windows XP does have somekind of DMI check here. Of course, while a BIOS update may solve this, I would prefer that Linux should also be able to boot up with this broken BIOS as well.
Quoted 8 lines
Quoted 3 lines
If you are certain that WinXP doesn't use DMI checks, it could be that WinXP's driver of ICH7M's SATA controller applies a quirk and sets that irq line to #20.
Can you post the dmesg output from a bootup attempt with those options?
You may also want to try adding just: acpi_osi=!
None of the 3 possible combinations succeeded to boot.
Here are a couple of dmesgs:
Quoted 8 lines
Params: acpi_osi="Windows 2001 SP3"
http://pastebin.com/vF3BSuhcParams: acpi_osi=! acpi_osi="Windows 2001 SP3"
http://pastebin.com/BuUzc3esParams: acpi_osi=!
http://pastebin.com/u7uRx8Ru
Quoted 8 lines
I'm not sure the option is actually taking effect properly. There should be a message "Disabled all
_OSIOS vendors" that shows up in dmesg with the ! option. Can you try:acpi_osi="!" acpi_osi="Windows 2001 SP3"
(with the quotes around the ! character).
The following command line worked:
acpi_osi= acpi_osi="Windows 2001 SP3"
So, it seems that the BIOS is broken. Is there any way to fix this, without resorting to the hackish DMI checks?
Signature · 2 lines
Regards, Levente Kurusa
Quoted 353 lines · Levente Kurusa
2013-10-13 07:57 keltezéssel, Robert Hancock írta:
Quoted 352 lines · Levente Kurusa
Quoted 336 lines
2013-10-12 04:06 keltezéssel, Robert Hancock írta:
Quoted 322 lines · Levente Kurusa
Quoted 321 lines
2013-10-01 06:25 keltezéssel, Robert Hancock írta:
Quoted 304 lines · Robert Hancock
Quoted 292 lines · Levente Kurusa
Quoted 275 lines
2013-09-28 06:55 keltezéssel, Robert Hancock írta:
Quoted 260 lines · Levente Kurusa
Quoted 243 lines
2013-09-25 08:31 keltezéssel, Robert Hancock írta:
Quoted 204 lines · Levente Kurusa
Quoted 188 lines
2013-09-21 19:04 keltezéssel, Robert Hancock írta:
Quoted 171 lines
On Sat, Sep 21, 2013 at 1:35 AM, Levente Kurusa <[email protected]>
wrote:The following dmesg is stuck in an infinite loop.
dmesg:
ata3: lost interrupt (Status 0x50)
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096
in
res 40/00:00:00:00:00/00:00:00:00:00/00
Emask
0x4
(timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33 (no error)
ata3.00: device reported invalid CHS sector 0
ata3: EH completePatch that fixes the infinite loop:
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index f9476fb..eeedf80 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -2437,6 +2437,14 @@ static void ata_eh_link_report(struct
ata_link
*link)
ehc->i.action, frozen,
tries_buf);
if (desc)
ata_dev_err(ehc->i.dev, "%s\n",
desc);
+ ehc->i.dev->exce_cnt ++;
+ ata_dev_warn(ehc->i.dev, "Number of exceptions:
%d\n",
ehc->i.dev->exce_cnt);
+ /**
+ * The device is failing terribly,
+ * disable it to prevent damage.
+ */
+ if(ehc->i.dev->exce_cnt > 2)
+ ata_dev_disable(ehc->i.dev);
} else {
ata_link_err(link, "exception Emask 0x%x
"
"SAct 0x%x SErr 0x%x action
0x%x%s%s\n",
diff --git a/include/linux/libata.h b/include/linux/libata.h
index eae7a05..fa52ee6 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -660,7 +660,8 @@ struct ata_device {
u8
devslp_timing[ATA_LOG_DEVSLP_SIZE];/* error history */
- int spdn_cnt;
+ int spdn_cnt; /* Number of
speed_downs
*/
+ int exce_cnt; /* Number of
exceptions
that
happenned */
/* ering is CLEAR_END, read comment above
CLEAR_END
*/
struct ata_ering ering;
};This doesn't seem like a very good fix. It may prevent the
apparent
infinite loop but will just prevent that device from functioning
at
all.
It would be better if we could figure out what was actually
going
wrong.I have tested the problem with three different computers, all
switched
to legacy/IDE/compatibility mode, and they didn't have this
problem.
Of
course, they could have been set to AHCI mode, and there the
kernel
would
boot normally. Feels strange, but so far I was only able to
reproduce
the
problem with a Toshiba MK8052GSX. On the topic of my patch, I
still
don't
see why a device which fails so terribly that it reports 3
exceptions
shouldn't be disabled. Like in this case, it could cause infinite
loops.The problem is that this could happen in some cases when you
wouldn't
want to disable the device, like an error that just happens
sporadically and works on retry, or a device you're trying to
recover
data from.What do you think if I edit the patch in a way, that when an
operation
successfully completes, it resets exce_cnt to zero. Might as well
add
a
module_param, which can set the maximum value of exce_cnt, while
having
zero
as an option to never disable the device. Please don't think me
wrong,
I
don't want to force this patch, I just want to learn how all this
works,
and
in the process try to make it better. :-)That would be better, but I think you're still going to have an
issue
with what magic number to pick to avoid disabling devices
inappropriately.Conceptually, disabling the device doesn't really make sense anyway.
If someone in userspace wants to keep trying to read from that
device,
why would you stop them because of some arbitrary judgement? The
kernel itself isn't "locked up" during this process, anything not
blocked on I/O to that device should be able to continue running, so
that process is only hurting itself. If the system fails to boot
from
another device due to this, this would likely point out some kind of
problem in userspace or the distro boot process being overly
serialized.I have been booting up with the initramfs from ubuntu 13.04,
and I have also tried to boot with the ubuntu install cd. They
couldn't
continue the boot process. I'm gonna spend the weekend trying to
figure
out where and why the interrupts don't happen. Whether it be a
routing
or a hardware issue, which I highly doubt due to the fact that
Windows
XP SP2 was able to boot up without errors.Are you able to get out full dmesg output from a boot attempt and the
contents of /proc/interrupts?As I said before, I am not able to get to the shell, without my 'symptom
cure'. With my patch I get the following dmesg output, with some of my debug messages turned off:
http://pastebin.com/5eb5G3Dx/proc/interruptsis here:
http://pastebin.com/84CJey2D
After yesterday's research, I have come toata_piix.c. That file looks like
the real culprit, as my netbook's controller is an Intel ICH7M one, The values I am getting from the device are very different than those that are expected.Quoted 7 lines
Things I have noticed, but ignored in dmesg:
There is a stack dump, because nobody cared about IRQ#20. I have ignored
this because it is the EHCI IRQ, and I suppose it has nothing to do with
ata. The problem is with ata3 or/dev/sdc, while the IRQ happens with/dev/sda, which works fine.I think it is likely related to the problem. The kernel thinks this controller is on IRQ 16, but apparently something is raising un-acknowledged interrupts on IRQ 20 and nothing is coming in on IRQ
16. It seems quite likely that this is actually the ATA controller.Quoted 5 lines
You mentioned that Windows XP was able to work in this mode. I wonder if it was using the IOAPIC, as if not then the IRQ routing is different which might mask the problem. Do you know what IRQ Device Manager reported for this controller in Windows? And was it using any IRQs over 15 (which would indicate the IOAPIC was in use)?
Hmm, according to WinXP's Device manager for this controller, it listens to IRQ# 20, and therefore it is using the I/O APIC. Now, one question remains where is the error that mismaps controller?
I have created a simple patch which seems to fix this:
---(quoted diff) +0
-0@@ -1704,6 +1767,8 @@ static int piix_init_one(struct pci_dev *pdev,const
structpci_device_id*ent)hpriv->map = piix_init_sata_map(pdev, port_info,piix_map_db_table[ent->driver_data]);
(quoted diff) +2
-0+ if(pdev->vendor == 0x8086 && pdev->device == 0x27C4) + pdev->irq = 20; rc = ata_pci_bmdma_prepare_host(pdev, ppi, &host); if (rc) return rc;However, I am more than sure that this is not the way to solve this problem. Do you have any idea on where the ideal place would be to implement a fix? According to specs of ICH7M, which is essentially the same as ICH6M, we need to check on what interrupt pin is the SATA controller, and after that check which IRQ line is connected to the I/O APIC and decide the IRQ's number on those findings.
Quoted 7 lines
Specs of ICH7:
http://www.intel.com/content/dam/doc/datasheet/i-o-controller-hub-7-datasheet.pdf
Device 31 Interrupt Route Register: Chapter 7.1.46 Device 31 Interrupt Pin Register: Chapter 7.1.41The SATA controller is always Device 31.
It would appear that something is messing up with the ACPI IRQ routing on this machine that's causing us to think the controller is on the wrong IRQ. CCing the linux-acpi list to see if anyone has some additional debugging suggestions. I suspect that dumping the DSDT is likely the first step though. If you can get IASL installed, you can do something like:
Quoted 6 lines
cat
/sys/firmware/acpi/tables/DSDT> dsdt.aml
iasl -d dsdt.amlThat should spit out a dsdt.dsl file which would hopefully have the info needed to figure out what's going on.
Here is the disassembled DSDT table:
http://pastebin.com/LWNVht9H
The SATA controller is at line 5206.
I also disassembled the SSDT, but nothing interesting was there:
http://pastebin.com/fus5sxU8Quoted 6 lines
I disabled the usage of ACPI for IRQs with acpi=noirq, and it successfully booted up setting itself to IRQ#3. This makes me think that this is the BIOS's fault. I think it would be possible to create a DMI check and forcibly set the irq to 20 if the DMI matches. Any comments on this?
The BIOS may be doing something funky, but since Windows apparently can figure out it's on IRQ 20, Linux presumably should be able to as well. DMI checks should be the last resort - Windows almost certainly doesn't have any machine-specific logic here, and it's hard to tell what other machine models could be affected. With ACPI stuff, we generally just need to do the same thing Windows does for things to work reliably, and DMI checks are more of a hack workaround than a real fix.
Quoted 2 lines
I'll try and have a look at the DSDT within the next few days and see if I can figure anything out, unless someone beats me to it.
I haven't gone into too much detail, but one thing I noticed with the DSDT is that there appear to be some
_OSIchecks for Windows 2006 (i.e. Vista) that seem to affect various things, including potentially the PCI IRQ routing table. It's possible that their IRQ routing table is broken for legacy mode with an ACPI OS supporting Vista (as current Linux versions do). Could be this slipped through testing if they only tested AHCI mode with Vista installed.Quoted 8 lines
You can try booting with the kernel parameters
acpi_osi=! acpi_osi="Windows 2001 SP3"
That should make the BIOS think we are Windows XP and bypass the Vista code path. If that works, then you might want to check for a BIOS update on this machine.
First of all, sorry for the late reply. I was kinda busy.
I tried what you suggested but unfortunately the problem persists. This makes me believe that Windows XP does have somekind of DMI check here. Of course, while a BIOS update may solve this, I would prefer that Linux should also be able to boot up with this broken BIOS as well.
Quoted 8 lines
Quoted 3 lines
If you are certain that WinXP doesn't use DMI checks, it could be that WinXP's driver of ICH7M's SATA controller applies a quirk and sets that irq line to #20.
Can you post the dmesg output from a bootup attempt with those options?
You may also want to try adding just: acpi_osi=!
None of the 3 possible combinations succeeded to boot.
Here are a couple of dmesgs:
Quoted 8 lines
Params: acpi_osi="Windows 2001 SP3"
http://pastebin.com/vF3BSuhcParams: acpi_osi=! acpi_osi="Windows 2001 SP3"
http://pastebin.com/BuUzc3esParams: acpi_osi=!
http://pastebin.com/u7uRx8RuI'm not sure the option is actually taking effect properly. There should be a message "Disabled all
_OSIOS vendors" that shows up in dmesg with the ! option. Can you try:acpi_osi="!" acpi_osi="Windows 2001 SP3"
Quoted 8 lines
Quoted 2 lines
(with the quotes around the ! character).
The following command line worked:
acpi_osi= acpi_osi="Windows 2001 SP3"So, it seems that the BIOS is broken. Is there any way to fix this, without resorting to the hackish DMI checks?
Probably not really. Have you checked for a newer BIOS version on this machine?
If not, this is likely similar to a number of other systems listed in acpi_osi_dmi_table in drivers/acpi/blacklist.c which need to disable reporting Vista support.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
2013-10-16 02:16 keltezéssel, Robert Hancock írta:
Quoted 360 lines · Levente Kurusa
Quoted 359 lines
2013-10-13 07:57 keltezéssel, Robert Hancock írta:
Quoted 346 lines · Levente Kurusa
Quoted 336 lines
2013-10-12 04:06 keltezéssel, Robert Hancock írta:
Quoted 322 lines · Levente Kurusa
Quoted 321 lines
2013-10-01 06:25 keltezéssel, Robert Hancock írta:
Quoted 304 lines · Robert Hancock
Quoted 292 lines · Levente Kurusa
Quoted 275 lines
2013-09-28 06:55 keltezéssel, Robert Hancock írta:
Quoted 260 lines · Levente Kurusa
Quoted 243 lines
2013-09-25 08:31 keltezéssel, Robert Hancock írta:
Quoted 204 lines · Levente Kurusa
Quoted 195 lines
2013-09-21 19:04 keltezéssel, Robert Hancock írta:
On Sat, Sep 21, 2013 at 1:35 AM, Levente Kurusa <[email protected]>
wrote:The following dmesg is stuck in an infinite loop.
dmesg:
ata3: lost interrupt (Status 0x50)
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096
in
res 40/00:00:00:00:00/00:00:00:00:00/00
Emask
0x4
(timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33 (no error)
ata3.00: device reported invalid CHS sector 0
ata3: EH completePatch that fixes the infinite loop:
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index f9476fb..eeedf80 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -2437,6 +2437,14 @@ static void ata_eh_link_report(struct
ata_link
*link)
ehc->i.action, frozen,
tries_buf);
if (desc)
ata_dev_err(ehc->i.dev, "%s\n",
desc);
+ ehc->i.dev->exce_cnt ++;
+ ata_dev_warn(ehc->i.dev, "Number of exceptions:
%d\n",
ehc->i.dev->exce_cnt);
+ /**
+ * The device is failing terribly,
+ * disable it to prevent damage.
+ */
+ if(ehc->i.dev->exce_cnt > 2)
+ ata_dev_disable(ehc->i.dev);
} else {
ata_link_err(link, "exception Emask 0x%x
"
"SAct 0x%x SErr 0x%x action
0x%x%s%s\n",
diff --git a/include/linux/libata.h b/include/linux/libata.h
index eae7a05..fa52ee6 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -660,7 +660,8 @@ struct ata_device {
u8
devslp_timing[ATA_LOG_DEVSLP_SIZE];/* error history */
- int spdn_cnt;
+ int spdn_cnt; /* Number of
speed_downs
*/
+ int exce_cnt; /* Number of
exceptions
that
happenned */
/* ering is CLEAR_END, read comment above
CLEAR_END
*/
struct ata_ering ering;
};This doesn't seem like a very good fix. It may prevent the
apparent
infinite loop but will just prevent that device from functioning
at
all.
It would be better if we could figure out what was actually
going
wrong.I have tested the problem with three different computers, all
switched
to legacy/IDE/compatibility mode, and they didn't have this
problem.
Of
course, they could have been set to AHCI mode, and there the
kernel
would
boot normally. Feels strange, but so far I was only able to
reproduce
the
problem with a Toshiba MK8052GSX. On the topic of my patch, I
still
don't
see why a device which fails so terribly that it reports 3
exceptions
shouldn't be disabled. Like in this case, it could cause infinite
loops.The problem is that this could happen in some cases when you
wouldn't
want to disable the device, like an error that just happens
sporadically and works on retry, or a device you're trying to
recover
data from.What do you think if I edit the patch in a way, that when an
operation
successfully completes, it resets exce_cnt to zero. Might as well
add
a
module_param, which can set the maximum value of exce_cnt, while
having
zero
as an option to never disable the device. Please don't think me
wrong,
I
don't want to force this patch, I just want to learn how all this
works,
and
in the process try to make it better. :-)That would be better, but I think you're still going to have an
issue
with what magic number to pick to avoid disabling devices
inappropriately.Conceptually, disabling the device doesn't really make sense anyway.
If someone in userspace wants to keep trying to read from that
device,
why would you stop them because of some arbitrary judgement? The
kernel itself isn't "locked up" during this process, anything not
blocked on I/O to that device should be able to continue running, so
that process is only hurting itself. If the system fails to boot
from
another device due to this, this would likely point out some kind of
problem in userspace or the distro boot process being overly
serialized.I have been booting up with the initramfs from ubuntu 13.04,
and I have also tried to boot with the ubuntu install cd. They
couldn't
continue the boot process. I'm gonna spend the weekend trying to
figure
out where and why the interrupts don't happen. Whether it be a
routing
or a hardware issue, which I highly doubt due to the fact that
Windows
XP SP2 was able to boot up without errors.Are you able to get out full dmesg output from a boot attempt and the
contents of /proc/interrupts?As I said before, I am not able to get to the shell, without my
'symptom
cure'. With my patch I get the following dmesg output, with
some of my debug messages turned off:
http://pastebin.com/5eb5G3Dx
/proc/interrupts is here:
http://pastebin.com/84CJey2D
After yesterday's research, I have come to ata_piix.c . That file looks
like
the real culprit, as my netbook's controller is an Intel ICH7M one,
The values I am getting from the device are very different than those
that are expected.Things I have noticed, but ignored in dmesg:
There is a stack dump, because nobody cared about IRQ#20. I have
ignored
this because it is the EHCI IRQ, and I suppose it has nothing to do
with
ata. The problem is with ata3 or /dev/sdc, while the IRQ happens
with /dev/sda, which works fine.I think it is likely related to the problem. The kernel thinks this controller is on IRQ 16, but apparently something is raising un-acknowledged interrupts on IRQ 20 and nothing is coming in on IRQ
16. It seems quite likely that this is actually the ATA controller.Quoted 5 lines
You mentioned that Windows XP was able to work in this mode. I wonder if it was using the IOAPIC, as if not then the IRQ routing is different which might mask the problem. Do you know what IRQ Device Manager reported for this controller in Windows? And was it using any IRQs over 15 (which would indicate the IOAPIC was in use)?
Hmm, according to WinXP's Device manager for this controller, it listens to IRQ# 20, and therefore it is using the I/O APIC. Now, one question remains where is the error that mismaps controller?
I have created a simple patch which seems to fix this:
---(quoted diff) +0
-0@@ -1704,6 +1767,8 @@ static int piix_init_one(struct pci_dev *pdev,const
structpci_device_id*ent)hpriv->map = piix_init_sata_map(pdev, port_info,piix_map_db_table[ent->driver_data]);
(quoted diff) +2
-0+ if(pdev->vendor == 0x8086 && pdev->device == 0x27C4) + pdev->irq = 20; rc = ata_pci_bmdma_prepare_host(pdev, ppi, &host); if (rc) return rc;However, I am more than sure that this is not the way to solve this problem. Do you have any idea on where the ideal place would be to implement a fix? According to specs of ICH7M, which is essentially the same as ICH6M, we need to check on what interrupt pin is the SATA controller, and after that check which IRQ line is connected to the I/O APIC and decide the IRQ's number on those findings.
Quoted 7 lines
Specs of ICH7:
http://www.intel.com/content/dam/doc/datasheet/i-o-controller-hub-7-datasheet.pdf
Device 31 Interrupt Route Register: Chapter 7.1.46 Device 31 Interrupt Pin Register: Chapter 7.1.41The SATA controller is always Device 31.
It would appear that something is messing up with the ACPI IRQ routing on this machine that's causing us to think the controller is on the wrong IRQ. CCing the linux-acpi list to see if anyone has some additional debugging suggestions. I suspect that dumping the DSDT is likely the first step though. If you can get IASL installed, you can do something like:
Quoted 6 lines
cat
/sys/firmware/acpi/tables/DSDT> dsdt.aml
iasl -d dsdt.amlThat should spit out a dsdt.dsl file which would hopefully have the info needed to figure out what's going on.
Here is the disassembled DSDT table:
http://pastebin.com/LWNVht9H
The SATA controller is at line 5206.
I also disassembled the SSDT, but nothing interesting was there:
http://pastebin.com/fus5sxU8Quoted 6 lines
I disabled the usage of ACPI for IRQs with acpi=noirq, and it successfully booted up setting itself to IRQ#3. This makes me think that this is the BIOS's fault. I think it would be possible to create a DMI check and forcibly set the irq to 20 if the DMI matches. Any comments on this?
The BIOS may be doing something funky, but since Windows apparently can figure out it's on IRQ 20, Linux presumably should be able to as well. DMI checks should be the last resort - Windows almost certainly doesn't have any machine-specific logic here, and it's hard to tell what other machine models could be affected. With ACPI stuff, we generally just need to do the same thing Windows does for things to work reliably, and DMI checks are more of a hack workaround than a real fix.
Quoted 2 lines
I'll try and have a look at the DSDT within the next few days and see if I can figure anything out, unless someone beats me to it.
I haven't gone into too much detail, but one thing I noticed with the DSDT is that there appear to be some
_OSIchecks for Windows 2006 (i.e. Vista) that seem to affect various things, including potentially the PCI IRQ routing table. It's possible that their IRQ routing table is broken for legacy mode with an ACPI OS supporting Vista (as current Linux versions do). Could be this slipped through testing if they only tested AHCI mode with Vista installed.Quoted 8 lines
You can try booting with the kernel parameters
acpi_osi=! acpi_osi="Windows 2001 SP3"
That should make the BIOS think we are Windows XP and bypass the Vista code path. If that works, then you might want to check for a BIOS update on this machine.
First of all, sorry for the late reply. I was kinda busy.
I tried what you suggested but unfortunately the problem persists. This makes me believe that Windows XP does have somekind of DMI check here. Of course, while a BIOS update may solve this, I would prefer that Linux should also be able to boot up with this broken BIOS as well.
Quoted 8 lines
Quoted 3 lines
If you are certain that WinXP doesn't use DMI checks, it could be that WinXP's driver of ICH7M's SATA controller applies a quirk and sets that irq line to #20.
Can you post the dmesg output from a bootup attempt with those options?
You may also want to try adding just: acpi_osi=!
None of the 3 possible combinations succeeded to boot.
Here are a couple of dmesgs:
Quoted 8 lines
Params: acpi_osi="Windows 2001 SP3"
http://pastebin.com/vF3BSuhcParams: acpi_osi=! acpi_osi="Windows 2001 SP3"
http://pastebin.com/BuUzc3esParams: acpi_osi=!
http://pastebin.com/u7uRx8RuQuoted 8 lines
I'm not sure the option is actually taking effect properly. There should be a message "Disabled all
_OSIOS vendors" that shows up in dmesg with the ! option. Can you try:acpi_osi="!" acpi_osi="Windows 2001 SP3"
(with the quotes around the ! character).
The following command line worked:
acpi_osi= acpi_osi="Windows 2001 SP3"
Quoted 9 lines
Quoted 2 lines
So, it seems that the BIOS is broken. Is there any way to fix this, without resorting to the hackish DMI checks?
Probably not really. Have you checked for a newer BIOS version on this machine?
If not, this is likely similar to a number of other systems listed in
acpi_osi_dmi_tableindrivers/acpi/blacklist.cwhich need to disable reporting Vista support.
Yup, the attached patch fixed it.
I will post it a little bit later, mind if I add your signed-off-by line? :)
I would do a BIOS update and see if it was fixed there, but it seems that Toshiba's BIOS updater and the BIOS itself causes more trouble than the problems fixed.
---
drivers/acpi/blacklist.c +8 -0
@@ -267,6 +267,14 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = { DMI_MATCH(DMI_PRODUCT_NAME, "Satellite P305D"), }, }, + { + .callback = dmi_disable_osi_vista, + .ident = "Toshiba NB100", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"), + DMI_MATCH(DMI_PRODUCT_NAME, "NB100"), + }, + },/* * BIOS invocation of _OSI(Linux) is almost always a BIOS bug.
Signature · 2 lines
Regards, Levente Kurusa
Robert Hancock
Reviewed-byQuoted 372 lines · Levente Kurusa
2013-10-16 02:16 keltezéssel, Robert Hancock írta:
Quoted 360 lines · Levente Kurusa
Quoted 359 lines
2013-10-13 07:57 keltezéssel, Robert Hancock írta:
Quoted 346 lines · Levente Kurusa
Quoted 336 lines
2013-10-12 04:06 keltezéssel, Robert Hancock írta:
Quoted 322 lines · Levente Kurusa
Quoted 321 lines
2013-10-01 06:25 keltezéssel, Robert Hancock írta:
Quoted 304 lines · Robert Hancock
Quoted 292 lines · Levente Kurusa
Quoted 275 lines
2013-09-28 06:55 keltezéssel, Robert Hancock írta:
Quoted 260 lines · Levente Kurusa
Quoted 243 lines
2013-09-25 08:31 keltezéssel, Robert Hancock írta:
Quoted 209 lines · Levente Kurusa
2013-09-21 19:04 keltezéssel, Robert Hancock írta:
On Sat, Sep 21, 2013 at 1:35 AM, Levente Kurusa <[email protected]>
wrote:The following dmesg is stuck in an infinite loop.
dmesg:
ata3: lost interrupt (Status 0x50)
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096
in
res 40/00:00:00:00:00/00:00:00:00:00/00
Emask
0x4
(timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33 (no error)
ata3.00: device reported invalid CHS sector 0
ata3: EH completePatch that fixes the infinite loop:
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index f9476fb..eeedf80 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -2437,6 +2437,14 @@ static void ata_eh_link_report(struct
ata_link
*link)
ehc->i.action, frozen,
tries_buf);
if (desc)
ata_dev_err(ehc->i.dev, "%s\n",
desc);
+ ehc->i.dev->exce_cnt ++;
+ ata_dev_warn(ehc->i.dev, "Number of exceptions:
%d\n",
ehc->i.dev->exce_cnt);
+ /**
+ * The device is failing terribly,
+ * disable it to prevent damage.
+ */
+ if(ehc->i.dev->exce_cnt > 2)
+ ata_dev_disable(ehc->i.dev);
} else {
ata_link_err(link, "exception Emask 0x%x
"
"SAct 0x%x SErr 0x%x action
0x%x%s%s\n",
diff --git a/include/linux/libata.h b/include/linux/libata.h
index eae7a05..fa52ee6 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -660,7 +660,8 @@ struct ata_device {
u8
devslp_timing[ATA_LOG_DEVSLP_SIZE];/* error history */
- int spdn_cnt;
+ int spdn_cnt; /* Number of
speed_downs
*/
+ int exce_cnt; /* Number of
exceptions
that
happenned */
/* ering is CLEAR_END, read comment above
CLEAR_END
*/
struct ata_ering ering;
};This doesn't seem like a very good fix. It may prevent the
apparent
infinite loop but will just prevent that device from functioning
at
all.
It would be better if we could figure out what was actually
going
wrong.I have tested the problem with three different computers, all
switched
to legacy/IDE/compatibility mode, and they didn't have this
problem.
Of
course, they could have been set to AHCI mode, and there the
kernel
would
boot normally. Feels strange, but so far I was only able to
reproduce
the
problem with a Toshiba MK8052GSX. On the topic of my patch, I
still
don't
see why a device which fails so terribly that it reports 3
exceptions
shouldn't be disabled. Like in this case, it could cause infinite
loops.The problem is that this could happen in some cases when you
wouldn't
want to disable the device, like an error that just happens
sporadically and works on retry, or a device you're trying to
recover
data from.What do you think if I edit the patch in a way, that when an
operation
successfully completes, it resets exce_cnt to zero. Might as well
add
a
module_param, which can set the maximum value of exce_cnt, while
having
zero
as an option to never disable the device. Please don't think me
wrong,
I
don't want to force this patch, I just want to learn how all this
works,
and
in the process try to make it better. :-)That would be better, but I think you're still going to have an
issue
with what magic number to pick to avoid disabling devices
inappropriately.Conceptually, disabling the device doesn't really make sense anyway.
If someone in userspace wants to keep trying to read from that
device,
why would you stop them because of some arbitrary judgement? The
kernel itself isn't "locked up" during this process, anything not
blocked on I/O to that device should be able to continue running, so
that process is only hurting itself. If the system fails to boot
from
another device due to this, this would likely point out some kind of
problem in userspace or the distro boot process being overly
serialized.I have been booting up with the initramfs from ubuntu 13.04,
and I have also tried to boot with the ubuntu install cd. They
couldn't
continue the boot process. I'm gonna spend the weekend trying to
figure
out where and why the interrupts don't happen. Whether it be a
routing
or a hardware issue, which I highly doubt due to the fact that
Windows
XP SP2 was able to boot up without errors.Are you able to get out full dmesg output from a boot attempt and the
contents of /proc/interrupts?As I said before, I am not able to get to the shell, without my
'symptom
cure'. With my patch I get the following dmesg output, with
some of my debug messages turned off:
http://pastebin.com/5eb5G3Dx
/proc/interrupts is here:
http://pastebin.com/84CJey2D
After yesterday's research, I have come to ata_piix.c . That file looks
like
the real culprit, as my netbook's controller is an Intel ICH7M one,
The values I am getting from the device are very different than those
that are expected.Things I have noticed, but ignored in dmesg:
There is a stack dump, because nobody cared about IRQ#20. I have
ignored
this because it is the EHCI IRQ, and I suppose it has nothing to do
with
ata. The problem is with ata3 or /dev/sdc, while the IRQ happens
with /dev/sda, which works fine.I think it is likely related to the problem. The kernel thinks this
controller is on IRQ 16, but apparently something is raising
un-acknowledged interrupts on IRQ 20 and nothing is coming in on IRQ
16. It seems quite likely that this is actually the ATA controller.You mentioned that Windows XP was able to work in this mode. I wonder
if it was using the IOAPIC, as if not then the IRQ routing is
different which might mask the problem. Do you know what IRQ Device
Manager reported for this controller in Windows? And was it using any
IRQs over 15 (which would indicate the IOAPIC was in use)?Hmm, according to WinXP's Device manager for this controller, it listens to IRQ# 20, and therefore it is using the I/O APIC. Now, one question remains where is the error that mismaps controller?
I have created a simple patch which seems to fix this:
---(quoted diff) +0
-0@@ -1704,6 +1767,8 @@ static int piix_init_one(struct pci_dev *pdev,const
structpci_device_id*ent)hpriv->map = piix_init_sata_map(pdev, port_info,piix_map_db_table[ent->driver_data]);
(quoted diff) +2
-0+ if(pdev->vendor == 0x8086 && pdev->device == 0x27C4) + pdev->irq = 20; rc = ata_pci_bmdma_prepare_host(pdev, ppi, &host); if (rc) return rc;However, I am more than sure that this is not the way to solve this problem. Do you have any idea on where the ideal place would be to implement a fix? According to specs of ICH7M, which is essentially the same as ICH6M, we need to check on what interrupt pin is the SATA controller, and after that check which IRQ line is connected to the I/O APIC and decide the IRQ's number on those findings.
Quoted 7 lines
Specs of ICH7:
http://www.intel.com/content/dam/doc/datasheet/i-o-controller-hub-7-datasheet.pdf
Device 31 Interrupt Route Register: Chapter 7.1.46 Device 31 Interrupt Pin Register: Chapter 7.1.41The SATA controller is always Device 31.
It would appear that something is messing up with the ACPI IRQ routing on this machine that's causing us to think the controller is on the wrong IRQ. CCing the linux-acpi list to see if anyone has some additional debugging suggestions. I suspect that dumping the DSDT is likely the first step though. If you can get IASL installed, you can do something like:
Quoted 6 lines
cat
/sys/firmware/acpi/tables/DSDT> dsdt.aml
iasl -d dsdt.amlThat should spit out a dsdt.dsl file which would hopefully have the info needed to figure out what's going on.
Here is the disassembled DSDT table:
http://pastebin.com/LWNVht9H
The SATA controller is at line 5206.
I also disassembled the SSDT, but nothing interesting was there:
http://pastebin.com/fus5sxU8Quoted 6 lines
I disabled the usage of ACPI for IRQs with acpi=noirq, and it successfully booted up setting itself to IRQ#3. This makes me think that this is the BIOS's fault. I think it would be possible to create a DMI check and forcibly set the irq to 20 if the DMI matches. Any comments on this?
The BIOS may be doing something funky, but since Windows apparently can figure out it's on IRQ 20, Linux presumably should be able to as well. DMI checks should be the last resort - Windows almost certainly doesn't have any machine-specific logic here, and it's hard to tell what other machine models could be affected. With ACPI stuff, we generally just need to do the same thing Windows does for things to work reliably, and DMI checks are more of a hack workaround than a real fix.
Quoted 2 lines
I'll try and have a look at the DSDT within the next few days and see if I can figure anything out, unless someone beats me to it.
I haven't gone into too much detail, but one thing I noticed with the DSDT is that there appear to be some
_OSIchecks for Windows 2006 (i.e. Vista) that seem to affect various things, including potentially the PCI IRQ routing table. It's possible that their IRQ routing table is broken for legacy mode with an ACPI OS supporting Vista (as current Linux versions do). Could be this slipped through testing if they only tested AHCI mode with Vista installed.Quoted 8 lines
You can try booting with the kernel parameters
acpi_osi=! acpi_osi="Windows 2001 SP3"
That should make the BIOS think we are Windows XP and bypass the Vista code path. If that works, then you might want to check for a BIOS update on this machine.
First of all, sorry for the late reply. I was kinda busy.
I tried what you suggested but unfortunately the problem persists. This makes me believe that Windows XP does have somekind of DMI check here. Of course, while a BIOS update may solve this, I would prefer that Linux should also be able to boot up with this broken BIOS as well.
Quoted 8 lines
Quoted 3 lines
If you are certain that WinXP doesn't use DMI checks, it could be that WinXP's driver of ICH7M's SATA controller applies a quirk and sets that irq line to #20.
Can you post the dmesg output from a bootup attempt with those options?
You may also want to try adding just: acpi_osi=!
None of the 3 possible combinations succeeded to boot.
Here are a couple of dmesgs:
Quoted 8 lines
Params: acpi_osi="Windows 2001 SP3"
http://pastebin.com/vF3BSuhcParams: acpi_osi=! acpi_osi="Windows 2001 SP3"
http://pastebin.com/BuUzc3esParams: acpi_osi=!
http://pastebin.com/u7uRx8RuQuoted 8 lines
I'm not sure the option is actually taking effect properly. There should be a message "Disabled all
_OSIOS vendors" that shows up in dmesg with the ! option. Can you try:acpi_osi="!" acpi_osi="Windows 2001 SP3"
(with the quotes around the ! character).
The following command line worked:
acpi_osi= acpi_osi="Windows 2001 SP3"Quoted 9 lines
Quoted 2 lines
So, it seems that the BIOS is broken. Is there any way to fix this, without resorting to the hackish DMI checks?
Probably not really. Have you checked for a newer BIOS version on this machine?
If not, this is likely similar to a number of other systems listed in
acpi_osi_dmi_tableindrivers/acpi/blacklist.cwhich need to disable reporting Vista support.
Quoted 5 lines
Yup, the attached patch fixed it.
I will post it a little bit later, mind if I add your signed-off-by line? :)I would do a BIOS update and see if it was fixed there, but it seems that Toshiba's BIOS updater and the BIOS itself causes more trouble than the problems fixed.
Sorry for the delay. Seems OK to me. When you submit the patch you should include a link to this thread to the commit message, so someone in the future would have a hope of knowing why this quirk is in here.
You can add my:
Quoted 11 lines
---
drivers/acpi/blacklist.c +1
-0@@ -267,6 +267,14 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = { DMI_MATCH(DMI_PRODUCT_NAME, "Satellite P305D"), }, }, + {
drivers/acpi/blacklist.c static struct dmi_system_id acpi_osi_dmi_table[] __initdata = { · line 280
Quoted 10 lines
drivers/acpi/blacklist.c +7
-0+ .callback = dmi_disable_osi_vista, + .ident = "Toshiba NB100", + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"TOSHIBA" ), + DMI_MATCH(DMI_PRODUCT_NAME, "NB100"), + }, + },/* * BIOS invocation of _OSI(Linux) is almost always a BIOS bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 376 lines · Robert Hancock
Quoted 375 lines · Levente Kurusa
2013-10-16 02:16 keltezéssel, Robert Hancock írta:
Quoted 360 lines · Levente Kurusa
Quoted 359 lines
2013-10-13 07:57 keltezéssel, Robert Hancock írta:
Quoted 346 lines · Levente Kurusa
Quoted 336 lines
2013-10-12 04:06 keltezéssel, Robert Hancock írta:
Quoted 322 lines · Levente Kurusa
Quoted 321 lines
2013-10-01 06:25 keltezéssel, Robert Hancock írta:
Quoted 304 lines · Robert Hancock
Quoted 292 lines · Levente Kurusa
Quoted 275 lines
2013-09-28 06:55 keltezéssel, Robert Hancock írta:
Quoted 260 lines · Levente Kurusa
Quoted 250 lines
2013-09-25 08:31 keltezéssel, Robert Hancock írta:
On Sun, Sep 22, 2013 at 1:13 AM, Levente Kurusa <[email protected]> wrote:
2013-09-21 19:04 keltezéssel, Robert Hancock írta:
On Sat, Sep 21, 2013 at 1:35 AM, Levente Kurusa <[email protected]>
wrote:The following dmesg is stuck in an infinite loop.
dmesg:
ata3: lost interrupt (Status 0x50)
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096
in
res 40/00:00:00:00:00/00:00:00:00:00/00
Emask
0x4
(timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33 (no error)
ata3.00: device reported invalid CHS sector 0
ata3: EH completePatch that fixes the infinite loop:
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index f9476fb..eeedf80 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -2437,6 +2437,14 @@ static void ata_eh_link_report(struct
ata_link
*link)
ehc->i.action, frozen,
tries_buf);
if (desc)
ata_dev_err(ehc->i.dev, "%s\n",
desc);
+ ehc->i.dev->exce_cnt ++;
+ ata_dev_warn(ehc->i.dev, "Number of exceptions:
%d\n",
ehc->i.dev->exce_cnt);
+ /**
+ * The device is failing terribly,
+ * disable it to prevent damage.
+ */
+ if(ehc->i.dev->exce_cnt > 2)
+ ata_dev_disable(ehc->i.dev);
} else {
ata_link_err(link, "exception Emask 0x%x
"
"SAct 0x%x SErr 0x%x action
0x%x%s%s\n",
diff --git a/include/linux/libata.h b/include/linux/libata.h
index eae7a05..fa52ee6 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -660,7 +660,8 @@ struct ata_device {
u8
devslp_timing[ATA_LOG_DEVSLP_SIZE];/* error history */
- int spdn_cnt;
+ int spdn_cnt; /* Number of
speed_downs
*/
+ int exce_cnt; /* Number of
exceptions
that
happenned */
/* ering is CLEAR_END, read comment above
CLEAR_END
*/
struct ata_ering ering;
};This doesn't seem like a very good fix. It may prevent the
apparent
infinite loop but will just prevent that device from functioning
at
all.
It would be better if we could figure out what was actually
going
wrong.I have tested the problem with three different computers, all
switched
to legacy/IDE/compatibility mode, and they didn't have this
problem.
Of
course, they could have been set to AHCI mode, and there the
kernel
would
boot normally. Feels strange, but so far I was only able to
reproduce
the
problem with a Toshiba MK8052GSX. On the topic of my patch, I
still
don't
see why a device which fails so terribly that it reports 3
exceptions
shouldn't be disabled. Like in this case, it could cause infinite
loops.The problem is that this could happen in some cases when you
wouldn't
want to disable the device, like an error that just happens
sporadically and works on retry, or a device you're trying to
recover
data from.What do you think if I edit the patch in a way, that when an
operation
successfully completes, it resets exce_cnt to zero. Might as well
add
a
module_param, which can set the maximum value of exce_cnt, while
having
zero
as an option to never disable the device. Please don't think me
wrong,
I
don't want to force this patch, I just want to learn how all this
works,
and
in the process try to make it better. :-)That would be better, but I think you're still going to have an
issue
with what magic number to pick to avoid disabling devices
inappropriately.Conceptually, disabling the device doesn't really make sense anyway.
If someone in userspace wants to keep trying to read from that
device,
why would you stop them because of some arbitrary judgement? The
kernel itself isn't "locked up" during this process, anything not
blocked on I/O to that device should be able to continue running, so
that process is only hurting itself. If the system fails to boot
from
another device due to this, this would likely point out some kind of
problem in userspace or the distro boot process being overly
serialized.I have been booting up with the initramfs from ubuntu 13.04,
and I have also tried to boot with the ubuntu install cd. They
couldn't
continue the boot process. I'm gonna spend the weekend trying to
figure
out where and why the interrupts don't happen. Whether it be a
routing
or a hardware issue, which I highly doubt due to the fact that
Windows
XP SP2 was able to boot up without errors.Are you able to get out full dmesg output from a boot attempt and the
contents of /proc/interrupts?As I said before, I am not able to get to the shell, without my
'symptom
cure'. With my patch I get the following dmesg output, with
some of my debug messages turned off:
http://pastebin.com/5eb5G3Dx
/proc/interrupts is here:
http://pastebin.com/84CJey2D
After yesterday's research, I have come to ata_piix.c . That file looks
like
the real culprit, as my netbook's controller is an Intel ICH7M one,
The values I am getting from the device are very different than those
that are expected.Things I have noticed, but ignored in dmesg:
There is a stack dump, because nobody cared about IRQ#20. I have
ignored
this because it is the EHCI IRQ, and I suppose it has nothing to do
with
ata. The problem is with ata3 or /dev/sdc, while the IRQ happens
with /dev/sda, which works fine.I think it is likely related to the problem. The kernel thinks this
controller is on IRQ 16, but apparently something is raising
un-acknowledged interrupts on IRQ 20 and nothing is coming in on IRQ
16. It seems quite likely that this is actually the ATA controller.You mentioned that Windows XP was able to work in this mode. I wonder
if it was using the IOAPIC, as if not then the IRQ routing is
different which might mask the problem. Do you know what IRQ Device
Manager reported for this controller in Windows? And was it using any
IRQs over 15 (which would indicate the IOAPIC was in use)?Hmm, according to WinXP's Device manager for this controller,
it listens to IRQ# 20, and therefore it is using the I/O APIC.
Now, one question remains where is the error that mismaps
controller?
I have created a simple patch which seems to fix this:
---
@@ -1704,6 +1767,8 @@ static int piix_init_one(struct pci_dev *pdev,
const
struct pci_device_id *ent)
hpriv->map = piix_init_sata_map(pdev, port_info,piix_map_db_table[ent->driver_data]);
+ if(pdev->vendor == 0x8086 && pdev->device == 0x27C4)
+ pdev->irq = 20;
rc = ata_pci_bmdma_prepare_host(pdev, ppi, &host);
if (rc)
return rc;However, I am more than sure that this is not the way
to solve this problem. Do you have any idea on where
the ideal place would be to implement a fix?
According to specs of ICH7M, which is essentially the
same as ICH6M, we need to check on what interrupt pin
is the SATA controller, and after that check which IRQ line
is connected to the I/O APIC and decide the IRQ's number
on those findings.Specs of ICH7:
http://www.intel.com/content/dam/doc/datasheet/i-o-controller-hub-7-datasheet.pdf
Device 31 Interrupt Route Register: Chapter 7.1.46
Device 31 Interrupt Pin Register: Chapter 7.1.41The SATA controller is always Device 31.
It would appear that something is messing up with the ACPI IRQ routing on this machine that's causing us to think the controller is on the wrong IRQ. CCing the linux-acpi list to see if anyone has some additional debugging suggestions. I suspect that dumping the DSDT is likely the first step though. If you can get IASL installed, you can do something like:
Quoted 6 lines
cat
/sys/firmware/acpi/tables/DSDT> dsdt.aml
iasl -d dsdt.amlThat should spit out a dsdt.dsl file which would hopefully have the info needed to figure out what's going on.
Here is the disassembled DSDT table:
http://pastebin.com/LWNVht9H
The SATA controller is at line 5206.
I also disassembled the SSDT, but nothing interesting was there:
http://pastebin.com/fus5sxU8Quoted 6 lines
I disabled the usage of ACPI for IRQs with acpi=noirq, and it successfully booted up setting itself to IRQ#3. This makes me think that this is the BIOS's fault. I think it would be possible to create a DMI check and forcibly set the irq to 20 if the DMI matches. Any comments on this?
The BIOS may be doing something funky, but since Windows apparently can figure out it's on IRQ 20, Linux presumably should be able to as well. DMI checks should be the last resort - Windows almost certainly doesn't have any machine-specific logic here, and it's hard to tell what other machine models could be affected. With ACPI stuff, we generally just need to do the same thing Windows does for things to work reliably, and DMI checks are more of a hack workaround than a real fix.
Quoted 2 lines
I'll try and have a look at the DSDT within the next few days and see if I can figure anything out, unless someone beats me to it.
I haven't gone into too much detail, but one thing I noticed with the DSDT is that there appear to be some
_OSIchecks for Windows 2006 (i.e. Vista) that seem to affect various things, including potentially the PCI IRQ routing table. It's possible that their IRQ routing table is broken for legacy mode with an ACPI OS supporting Vista (as current Linux versions do). Could be this slipped through testing if they only tested AHCI mode with Vista installed.Quoted 8 lines
You can try booting with the kernel parameters
acpi_osi=! acpi_osi="Windows 2001 SP3"
That should make the BIOS think we are Windows XP and bypass the Vista code path. If that works, then you might want to check for a BIOS update on this machine.
First of all, sorry for the late reply. I was kinda busy.
I tried what you suggested but unfortunately the problem persists. This makes me believe that Windows XP does have somekind of DMI check here. Of course, while a BIOS update may solve this, I would prefer that Linux should also be able to boot up with this broken BIOS as well.
Quoted 8 lines
Quoted 3 lines
If you are certain that WinXP doesn't use DMI checks, it could be that WinXP's driver of ICH7M's SATA controller applies a quirk and sets that irq line to #20.
Can you post the dmesg output from a bootup attempt with those options?
You may also want to try adding just: acpi_osi=!
None of the 3 possible combinations succeeded to boot.
Here are a couple of dmesgs:
Quoted 8 lines
Params: acpi_osi="Windows 2001 SP3"
http://pastebin.com/vF3BSuhcParams: acpi_osi=! acpi_osi="Windows 2001 SP3"
http://pastebin.com/BuUzc3esParams: acpi_osi=!
http://pastebin.com/u7uRx8RuQuoted 8 lines
I'm not sure the option is actually taking effect properly. There should be a message "Disabled all
_OSIOS vendors" that shows up in dmesg with the ! option. Can you try:acpi_osi="!" acpi_osi="Windows 2001 SP3"
(with the quotes around the ! character).
The following command line worked:
acpi_osi= acpi_osi="Windows 2001 SP3"Quoted 9 lines
Quoted 2 lines
So, it seems that the BIOS is broken. Is there any way to fix this, without resorting to the hackish DMI checks?
Probably not really. Have you checked for a newer BIOS version on this machine?
If not, this is likely similar to a number of other systems listed in
acpi_osi_dmi_tableindrivers/acpi/blacklist.cwhich need to disable reporting Vista support.Yup, the attached patch fixed it.
I will post it a little bit later, mind if I add your signed-off-by line? :)
Quoted 6 lines
Quoted 2 lines
I would do a BIOS update and see if it was fixed there, but it seems that Toshiba's BIOS updater and the BIOS itself causes more trouble than the problems fixed.
Sorry for the delay. Seems OK to me. When you submit the patch you should include a link to this thread to the commit message, so someone in the future would have a hope of knowing why this quirk is in here.
Yes, a comment explainning why this blacklist is needed and if that whole system _OSI change has any other negative effect on this system, e.g. does the hotkey for backlight/bluetooth/suspend/etc. still work?
Thanks,
Aaron
Quoted 32 lines
You can add my:
Reviewed-by Robert Hancock <[email protected]>Quoted 11 lines
---
drivers/acpi/blacklist.c +1
-0@@ -267,6 +267,14 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = { DMI_MATCH(DMI_PRODUCT_NAME, "Satellite P305D"), }, }, + {drivers/acpi/blacklist.c static struct dmi_system_id acpi_osi_dmi_table[] __initdata = { · line 280
Quoted 10 lines
drivers/acpi/blacklist.c +7
-0+ .callback = dmi_disable_osi_vista, + .ident = "Toshiba NB100", + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"TOSHIBA" ), + DMI_MATCH(DMI_PRODUCT_NAME, "NB100"), + }, + },/* * BIOS invocation of _OSI(Linux) is almost always a BIOS bug. --
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
2013-10-22 04:12 keltezéssel, Aaron Lu írta:
Quoted 380 lines · Robert Hancock
Quoted 379 lines · Levente Kurusa
Quoted 377 lines
2013-10-16 02:16 keltezéssel, Robert Hancock írta:
Quoted 360 lines · Levente Kurusa
Quoted 359 lines
2013-10-13 07:57 keltezéssel, Robert Hancock írta:
Quoted 346 lines · Levente Kurusa
Quoted 336 lines
2013-10-12 04:06 keltezéssel, Robert Hancock írta:
Quoted 322 lines · Levente Kurusa
Quoted 321 lines
2013-10-01 06:25 keltezéssel, Robert Hancock írta:
Quoted 304 lines · Robert Hancock
Quoted 292 lines · Levente Kurusa
Quoted 275 lines
2013-09-28 06:55 keltezéssel, Robert Hancock írta:
Quoted 266 lines · Levente Kurusa
2013-09-25 08:31 keltezéssel, Robert Hancock írta:
On Sun, Sep 22, 2013 at 1:13 AM, Levente Kurusa <[email protected]> wrote:
2013-09-21 19:04 keltezéssel, Robert Hancock írta:
On Sat, Sep 21, 2013 at 1:35 AM, Levente Kurusa <[email protected]>
wrote:The following dmesg is stuck in an infinite loop.
dmesg:
ata3: lost interrupt (Status 0x50)
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
ata3.00: failed command: READ DMA
ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096
in
res 40/00:00:00:00:00/00:00:00:00:00/00
Emask
0x4
(timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33 (no error)
ata3.00: device reported invalid CHS sector 0
ata3: EH completePatch that fixes the infinite loop:
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index f9476fb..eeedf80 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -2437,6 +2437,14 @@ static void ata_eh_link_report(struct
ata_link
*link)
ehc->i.action, frozen,
tries_buf);
if (desc)
ata_dev_err(ehc->i.dev, "%s\n",
desc);
+ ehc->i.dev->exce_cnt ++;
+ ata_dev_warn(ehc->i.dev, "Number of exceptions:
%d\n",
ehc->i.dev->exce_cnt);
+ /**
+ * The device is failing terribly,
+ * disable it to prevent damage.
+ */
+ if(ehc->i.dev->exce_cnt > 2)
+ ata_dev_disable(ehc->i.dev);
} else {
ata_link_err(link, "exception Emask 0x%x
"
"SAct 0x%x SErr 0x%x action
0x%x%s%s\n",
diff --git a/include/linux/libata.h b/include/linux/libata.h
index eae7a05..fa52ee6 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -660,7 +660,8 @@ struct ata_device {
u8
devslp_timing[ATA_LOG_DEVSLP_SIZE];/* error history */
- int spdn_cnt;
+ int spdn_cnt; /* Number of
speed_downs
*/
+ int exce_cnt; /* Number of
exceptions
that
happenned */
/* ering is CLEAR_END, read comment above
CLEAR_END
*/
struct ata_ering ering;
};This doesn't seem like a very good fix. It may prevent the
apparent
infinite loop but will just prevent that device from functioning
at
all.
It would be better if we could figure out what was actually
going
wrong.I have tested the problem with three different computers, all
switched
to legacy/IDE/compatibility mode, and they didn't have this
problem.
Of
course, they could have been set to AHCI mode, and there the
kernel
would
boot normally. Feels strange, but so far I was only able to
reproduce
the
problem with a Toshiba MK8052GSX. On the topic of my patch, I
still
don't
see why a device which fails so terribly that it reports 3
exceptions
shouldn't be disabled. Like in this case, it could cause infinite
loops.The problem is that this could happen in some cases when you
wouldn't
want to disable the device, like an error that just happens
sporadically and works on retry, or a device you're trying to
recover
data from.What do you think if I edit the patch in a way, that when an
operation
successfully completes, it resets exce_cnt to zero. Might as well
add
a
module_param, which can set the maximum value of exce_cnt, while
having
zero
as an option to never disable the device. Please don't think me
wrong,
I
don't want to force this patch, I just want to learn how all this
works,
and
in the process try to make it better. :-)That would be better, but I think you're still going to have an
issue
with what magic number to pick to avoid disabling devices
inappropriately.Conceptually, disabling the device doesn't really make sense anyway.
If someone in userspace wants to keep trying to read from that
device,
why would you stop them because of some arbitrary judgement? The
kernel itself isn't "locked up" during this process, anything not
blocked on I/O to that device should be able to continue running, so
that process is only hurting itself. If the system fails to boot
from
another device due to this, this would likely point out some kind of
problem in userspace or the distro boot process being overly
serialized.I have been booting up with the initramfs from ubuntu 13.04,
and I have also tried to boot with the ubuntu install cd. They
couldn't
continue the boot process. I'm gonna spend the weekend trying to
figure
out where and why the interrupts don't happen. Whether it be a
routing
or a hardware issue, which I highly doubt due to the fact that
Windows
XP SP2 was able to boot up without errors.Are you able to get out full dmesg output from a boot attempt and the
contents of /proc/interrupts?As I said before, I am not able to get to the shell, without my
'symptom
cure'. With my patch I get the following dmesg output, with
some of my debug messages turned off:
http://pastebin.com/5eb5G3Dx
/proc/interrupts is here:
http://pastebin.com/84CJey2D
After yesterday's research, I have come to ata_piix.c . That file looks
like
the real culprit, as my netbook's controller is an Intel ICH7M one,
The values I am getting from the device are very different than those
that are expected.Things I have noticed, but ignored in dmesg:
There is a stack dump, because nobody cared about IRQ#20. I have
ignored
this because it is the EHCI IRQ, and I suppose it has nothing to do
with
ata. The problem is with ata3 or /dev/sdc, while the IRQ happens
with /dev/sda, which works fine.I think it is likely related to the problem. The kernel thinks this
controller is on IRQ 16, but apparently something is raising
un-acknowledged interrupts on IRQ 20 and nothing is coming in on IRQ
16. It seems quite likely that this is actually the ATA controller.You mentioned that Windows XP was able to work in this mode. I wonder
if it was using the IOAPIC, as if not then the IRQ routing is
different which might mask the problem. Do you know what IRQ Device
Manager reported for this controller in Windows? And was it using any
IRQs over 15 (which would indicate the IOAPIC was in use)?Hmm, according to WinXP's Device manager for this controller,
it listens to IRQ# 20, and therefore it is using the I/O APIC.
Now, one question remains where is the error that mismaps
controller?
I have created a simple patch which seems to fix this:
---
@@ -1704,6 +1767,8 @@ static int piix_init_one(struct pci_dev *pdev,
const
struct pci_device_id *ent)
hpriv->map = piix_init_sata_map(pdev, port_info,piix_map_db_table[ent->driver_data]);
+ if(pdev->vendor == 0x8086 && pdev->device == 0x27C4)
+ pdev->irq = 20;
rc = ata_pci_bmdma_prepare_host(pdev, ppi, &host);
if (rc)
return rc;However, I am more than sure that this is not the way
to solve this problem. Do you have any idea on where
the ideal place would be to implement a fix?
According to specs of ICH7M, which is essentially the
same as ICH6M, we need to check on what interrupt pin
is the SATA controller, and after that check which IRQ line
is connected to the I/O APIC and decide the IRQ's number
on those findings.Specs of ICH7:
http://www.intel.com/content/dam/doc/datasheet/i-o-controller-hub-7-datasheet.pdf
Device 31 Interrupt Route Register: Chapter 7.1.46
Device 31 Interrupt Pin Register: Chapter 7.1.41The SATA controller is always Device 31.
It would appear that something is messing up with the ACPI IRQ routing
on this machine that's causing us to think the controller is on the
wrong IRQ. CCing the linux-acpi list to see if anyone has some
additional debugging suggestions. I suspect that dumping the DSDT is
likely the first step though. If you can get IASL installed, you can
do something like:cat /sys/firmware/acpi/tables/DSDT > dsdt.aml
iasl -d dsdt.amlThat should spit out a dsdt.dsl file which would hopefully have the
info needed to figure out what's going on.Here is the disassembled DSDT table:
http://pastebin.com/LWNVht9H
The SATA controller is at line 5206.
I also disassembled the SSDT, but nothing interesting was there:
http://pastebin.com/fus5sxU8Quoted 6 lines
I disabled the usage of ACPI for IRQs with acpi=noirq, and it successfully booted up setting itself to IRQ#3. This makes me think that this is the BIOS's fault. I think it would be possible to create a DMI check and forcibly set the irq to 20 if the DMI matches. Any comments on this?
The BIOS may be doing something funky, but since Windows apparently can figure out it's on IRQ 20, Linux presumably should be able to as well. DMI checks should be the last resort - Windows almost certainly doesn't have any machine-specific logic here, and it's hard to tell what other machine models could be affected. With ACPI stuff, we generally just need to do the same thing Windows does for things to work reliably, and DMI checks are more of a hack workaround than a real fix.
Quoted 2 lines
I'll try and have a look at the DSDT within the next few days and see if I can figure anything out, unless someone beats me to it.
I haven't gone into too much detail, but one thing I noticed with the DSDT is that there appear to be some
_OSIchecks for Windows 2006 (i.e. Vista) that seem to affect various things, including potentially the PCI IRQ routing table. It's possible that their IRQ routing table is broken for legacy mode with an ACPI OS supporting Vista (as current Linux versions do). Could be this slipped through testing if they only tested AHCI mode with Vista installed.Quoted 8 lines
You can try booting with the kernel parameters
acpi_osi=! acpi_osi="Windows 2001 SP3"
That should make the BIOS think we are Windows XP and bypass the Vista code path. If that works, then you might want to check for a BIOS update on this machine.
First of all, sorry for the late reply. I was kinda busy.
I tried what you suggested but unfortunately the problem persists. This makes me believe that Windows XP does have somekind of DMI check here. Of course, while a BIOS update may solve this, I would prefer that Linux should also be able to boot up with this broken BIOS as well.
Quoted 8 lines
Quoted 3 lines
If you are certain that WinXP doesn't use DMI checks, it could be that WinXP's driver of ICH7M's SATA controller applies a quirk and sets that irq line to #20.
Can you post the dmesg output from a bootup attempt with those options?
You may also want to try adding just: acpi_osi=!
None of the 3 possible combinations succeeded to boot.
Here are a couple of dmesgs:
Quoted 8 lines
Params: acpi_osi="Windows 2001 SP3"
http://pastebin.com/vF3BSuhcParams: acpi_osi=! acpi_osi="Windows 2001 SP3"
http://pastebin.com/BuUzc3esParams: acpi_osi=!
http://pastebin.com/u7uRx8RuQuoted 8 lines
I'm not sure the option is actually taking effect properly. There should be a message "Disabled all
_OSIOS vendors" that shows up in dmesg with the ! option. Can you try:acpi_osi="!" acpi_osi="Windows 2001 SP3"
(with the quotes around the ! character).
The following command line worked:
acpi_osi= acpi_osi="Windows 2001 SP3"Quoted 9 lines
Quoted 2 lines
So, it seems that the BIOS is broken. Is there any way to fix this, without resorting to the hackish DMI checks?
Probably not really. Have you checked for a newer BIOS version on this machine?
If not, this is likely similar to a number of other systems listed in
acpi_osi_dmi_tableindrivers/acpi/blacklist.cwhich need to disable reporting Vista support.Yup, the attached patch fixed it.
I will post it a little bit later, mind if I add your signed-off-by line? :)I would do a BIOS update and see if it was fixed there, but it seems that Toshiba's BIOS updater and the BIOS itself causes more trouble than the problems fixed.
Quoted 8 lines
Quoted 3 lines
Sorry for the delay. Seems OK to me. When you submit the patch you should include a link to this thread to the commit message, so someone in the future would have a hope of knowing why this quirk is in here.
Yes, a comment explainning why this blacklist is needed and if that whole system
_OSIchange has any other negative effect on this system, e.g. does the hotkey for backlight/bluetooth/suspend/etc. still work?
Yes, everything is in the same state as it was pre-patch, but now IDE mode also works.
Quoted 3 lines
Quoted 3 lines
You can add my:
Reviewed-by Robert Hancock <[email protected]>
Thank you, will add.
Signature · 6 lines
Regards, Levente Kurusa -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html