[PATCH v6 1/1] applesmc: Re-work SMC comms

[Brad Campbell]

Commit fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
introduced an issue whereby communication with the SMC became
unreliable with write errors like :

[  120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40
[  120.378621] applesmc: LKSB: write data fail
[  120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40
[  120.512787] applesmc: LKSB: write data fail

The original code appeared to be timing sensitive and was not reliable
with the timing changes in the aforementioned commit.

This patch re-factors the SMC communication to remove the timing
dependencies and restore function with the changes previously
committed.

Tested on : MacbookAir6,2 MacBookPro11,1 iMac12,2, MacBookAir1,1,
MacBookAir3,1

Fixes: fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
Reported-by: Andreas Kemnade 
Tested-by: Andreas Kemnade  # MacBookAir6,2
Acked-by: Arnd Bergmann 
Signed-off-by: Brad Campbell 
Signed-off-by: Henrik Rydberg 

---
Changelog : 
v1 : Initial attempt
v2 : Address logic and coding style based on comments received
v3 : Removed some debug hangover. Added tested-by. Modifications for 
MacBookAir1,1
- Significant rework of wait logic by Henrik Rydberg  to
  make it function at all on the MacBookAir1,1.

v4 : Re-factored logic based on Apple driver. Simplified wait_status loop
- Re-factored the logic again, this time based on the Apple driver. This
  functioned without error on all tested Macs. wait_status() contributed
  by Henrik Rydberg 

v5 : Re-wrote status loop. Simplified busy check in send_byte()
- Re-wrote wait_status() based on feedback from Guenter Roeck 

- Added additional comments to explain multiple tests in send_byte()
- Addressed repeated indentation issues

v6 : Reverted simplification of busy check in send_byte()
- The logic simplification in v5 send_byte() caused a few read failures in
  stress testing on a fast SMC (3 in 5.6million). Reverting that change passed 
  5 million reads with 0 errors.

Index: linux-stable/drivers/hwmon/applesmc.c
===
--- linux-stable.orig/drivers/hwmon/applesmc.c
+++ linux-stable/drivers/hwmon/applesmc.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* data port used by Apple SMC */
 #define APPLESMC_DATA_PORT 0x300
@@ -42,10 +43,13 @@
 
 #define APPLESMC_MAX_DATA_LENGTH 32
 
-/* wait up to 128 ms for a status change. */
-#define APPLESMC_MIN_WAIT  0x0010
-#define APPLESMC_RETRY_WAIT0x0100
-#define APPLESMC_MAX_WAIT  0x2
+/* Apple SMC status bits */
+#define SMC_STATUS_AWAITING_DATA  BIT(0) /* SMC has data waiting to be read */
+#define SMC_STATUS_IB_CLOSED  BIT(1) /* Will ignore any input */
+#define SMC_STATUS_BUSY   BIT(2) /* Command in progress */
+
+/* Initial wait is 8us */
+#define APPLESMC_MIN_WAIT  0x0008
 
 #define APPLESMC_READ_CMD  0x10
 #define APPLESMC_WRITE_CMD 0x11
@@ -151,65 +155,84 @@ static unsigned int key_at_index;
 static struct workqueue_struct *applesmc_led_wq;
 
 /*
- * wait_read - Wait for a byte to appear on SMC port. Callers must
- * hold applesmc_lock.
+ * Wait for specific status bits with a mask on the SMC.
+ * Used before all transactions.
+ * This does 10 fast loops of 8us then exponentially backs off for a
+ * minimum total wait of 262ms. Depending on usleep_range this could
+ * run out past 500ms.
  */
-static int wait_read(void)
+
+static int wait_status(u8 val, u8 mask)
 {
-   unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
u8 status;
int us;
+   int i;
 
-   for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
-   usleep_range(us, us * 16);
+   us = APPLESMC_MIN_WAIT;
+   for (i = 0; i < 24 ; i++) {
status = inb(APPLESMC_CMD_PORT);
-   /* read: wait for smc to settle */
-   if (status & 0x01)
+   if ((status & mask) == val)
return 0;
-   /* timeout: give up */
-   if (time_after(jiffies, end))
-   break;
+   usleep_range(us, us * 2);
+   if (i > 9)
+   us <<= 1;
}
-
-   pr_warn("wait_read() fail: 0x%02x\n", status);
return -EIO;
 }
 
-/*
- * send_byte - Write to SMC port, retrying when necessary. Callers
- * must hold applesmc_lock.
- */
+/* send_byte - Write to SMC data port. Callers must hold applesmc_lock. */
+
 static int send_byte(u8 cmd, u16 port)
 {
-   u8 status;
-   int us;
-   unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
+   int status;
 
-   outb(cmd, port);
-   for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
-   usleep_range(us, us * 16);
-   status = inb(APPLESMC_CMD_PORT);
-   /* write: wait for smc to settle */

Re: [PATCH v5 1/1] applesmc: Re-work SMC comms

[Brad Campbell]

On 12/11/20 7:05 am, Henrik Rydberg wrote:
> On 2020-11-11 14:06, Brad Campbell wrote:
>> Commit fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
>> introduced an issue whereby communication with the SMC became
>> unreliable with write errors like :
>>
>> [  120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40
>> [  120.378621] applesmc: LKSB: write data fail
>> [  120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40
>> [  120.512787] applesmc: LKSB: write data fail
>>
>> The original code appeared to be timing sensitive and was not reliable
>> with the timing changes in the aforementioned commit.
>>
>> This patch re-factors the SMC communication to remove the timing
>> dependencies and restore function with the changes previously
>> committed. Logic changes based on inspection of the Apple SMC kext.
>>
>> Tested on : MacbookAir6,2 MacBookPro11,1 iMac12,2, MacBookAir1,1,
>> MacBookAir3,1
>>
>> Fixes: fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
>> Reported-by: Andreas Kemnade 
>> Tested-by: Andreas Kemnade  # MacBookAir6,2
>> Acked-by: Arnd Bergmann 
>> Signed-off-by: Brad Campbell 
>> Signed-off-by: Henrik Rydberg 
>>
>> ---
>> Changelog :
>> v1 : Initial attempt
>> v2 : Address logic and coding style
>> v3 : Removed some debug hangover. Added tested-by. Modifications for 
>> MacBookAir1,1
>> v4 : Re-factored logic based on Apple driver. Simplified wait_status loop
>> v5 : Re-wrote status loop. Simplified busy check in send_byte(). Fixed 
>> formatting
> 
> Hi Brad,
> 
> This version is still working fine on the MBA1,1, at 50 reads per second.
> 

Cheers Henrik,

I did 5.6 million reads overnight and had 3 failures.
I suspect it's this :
status = inb(APPLESMC_CMD_PORT) & SMC_STATUS_BUSY;
if (!status)
return -EIO;

When I used wait_status() previously I didn't see any read errors.
With hindsight I probably shouldn't have made that simplification.

I'll do some more testing and probably submit a v6 with just this change.
I think it's just about right provided that wait_status loop gets across the
line.

Regards,
Brad

[PATCH v5 1/1] applesmc: Re-work SMC comms

[Brad Campbell]

Commit fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
introduced an issue whereby communication with the SMC became
unreliable with write errors like :

[  120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40
[  120.378621] applesmc: LKSB: write data fail
[  120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40
[  120.512787] applesmc: LKSB: write data fail

The original code appeared to be timing sensitive and was not reliable
with the timing changes in the aforementioned commit.

This patch re-factors the SMC communication to remove the timing
dependencies and restore function with the changes previously
committed. Logic changes based on inspection of the Apple SMC kext.

Tested on : MacbookAir6,2 MacBookPro11,1 iMac12,2, MacBookAir1,1,
MacBookAir3,1

Fixes: fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
Reported-by: Andreas Kemnade 
Tested-by: Andreas Kemnade  # MacBookAir6,2
Acked-by: Arnd Bergmann 
Signed-off-by: Brad Campbell 
Signed-off-by: Henrik Rydberg 

---
Changelog : 
v1 : Initial attempt
v2 : Address logic and coding style
v3 : Removed some debug hangover. Added tested-by. Modifications for 
MacBookAir1,1
v4 : Re-factored logic based on Apple driver. Simplified wait_status loop
v5 : Re-wrote status loop. Simplified busy check in send_byte(). Fixed 
formatting

Index: linux-stable/drivers/hwmon/applesmc.c
===
--- linux-stable.orig/drivers/hwmon/applesmc.c
+++ linux-stable/drivers/hwmon/applesmc.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* data port used by Apple SMC */
 #define APPLESMC_DATA_PORT 0x300
@@ -42,10 +43,13 @@
 
 #define APPLESMC_MAX_DATA_LENGTH 32
 
-/* wait up to 128 ms for a status change. */
-#define APPLESMC_MIN_WAIT  0x0010
-#define APPLESMC_RETRY_WAIT0x0100
-#define APPLESMC_MAX_WAIT  0x2
+/* Apple SMC status bits */
+#define SMC_STATUS_AWAITING_DATA  BIT(0) /* SMC has data waiting to be read */
+#define SMC_STATUS_IB_CLOSED  BIT(1) /* Will ignore any input */
+#define SMC_STATUS_BUSY   BIT(2) /* Command in progress */
+
+/* Initial wait is 8us */
+#define APPLESMC_MIN_WAIT  0x0008
 
 #define APPLESMC_READ_CMD  0x10
 #define APPLESMC_WRITE_CMD 0x11
@@ -151,65 +155,84 @@ static unsigned int key_at_index;
 static struct workqueue_struct *applesmc_led_wq;
 
 /*
- * wait_read - Wait for a byte to appear on SMC port. Callers must
- * hold applesmc_lock.
+ * Wait for specific status bits with a mask on the SMC.
+ * Used before all transactions.
+ * This does 10 fast loops of 8us then exponentially backs off for a
+ * minimum total wait of 262ms. Depending on usleep_range this could
+ * run out past 500ms.
  */
-static int wait_read(void)
+
+static int wait_status(u8 val, u8 mask)
 {
-   unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
u8 status;
int us;
+   int i;
 
-   for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
-   usleep_range(us, us * 16);
+   us = APPLESMC_MIN_WAIT;
+   for (i = 0; i < 24 ; i++) {
status = inb(APPLESMC_CMD_PORT);
-   /* read: wait for smc to settle */
-   if (status & 0x01)
+   if ((status & mask) == val)
return 0;
-   /* timeout: give up */
-   if (time_after(jiffies, end))
-   break;
+   usleep_range(us, us * 2);
+   if (i > 9)
+   us <<= 1;
}
-
-   pr_warn("wait_read() fail: 0x%02x\n", status);
return -EIO;
 }
 
-/*
- * send_byte - Write to SMC port, retrying when necessary. Callers
- * must hold applesmc_lock.
- */
+/* send_byte - Write to SMC data port. Callers must hold applesmc_lock. */
+
 static int send_byte(u8 cmd, u16 port)
 {
-   u8 status;
-   int us;
-   unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
+   int status;
 
-   outb(cmd, port);
-   for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
-   usleep_range(us, us * 16);
-   status = inb(APPLESMC_CMD_PORT);
-   /* write: wait for smc to settle */
-   if (status & 0x02)
-   continue;
-   /* ready: cmd accepted, return */
-   if (status & 0x04)
-   return 0;
-   /* timeout: give up */
-   if (time_after(jiffies, end))
-   break;
-   /* busy: long wait and resend */
-   udelay(APPLESMC_RETRY_WAIT);
-   outb(cmd, port);
-   }
+   status = wait_status(0, SMC_STATUS_IB_CLOSED);
+   if (status)
+   return status;
+   /*
+* This needs to be a separate read looking for bit 0x04
+* after bit 0x02 falls. I

Re: [PATCH v4 1/1] applesmc: Re-work SMC comms

[Brad Campbell]

On 11/11/20 4:56 pm, Guenter Roeck wrote:
> On 11/10/20 7:38 PM, Brad Campbell wrote:
>> Commit fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
>> introduced an issue whereby communication with the SMC became
>> unreliable with write errors like :
>>
>> [  120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40
>> [  120.378621] applesmc: LKSB: write data fail
>> [  120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40
>> [  120.512787] applesmc: LKSB: write data fail
>>
>> The original code appeared to be timing sensitive and was not reliable
>> with the timing changes in the aforementioned commit.
>>
>> This patch re-factors the SMC communication to remove the timing
>> dependencies and restore function with the changes previously
>> committed.
>>
>> Tested on : MacbookAir6,2 MacBookPro11,1 iMac12,2, MacBookAir1,1,
>> MacBookAir3,1
>>
>> Fixes: fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
>> Reported-by: Andreas Kemnade 
>> Tested-by: Andreas Kemnade  # MacBookAir6,2
>> Acked-by: Arnd Bergmann 
>> Signed-off-by: Brad Campbell 
>> Signed-off-by: Henrik Rydberg 
>>
>> ---
>> Changelog : 
>> v1 : Initial attempt
>> v2 : Address logic and coding style
>> v3 : Removed some debug hangover. Added tested-by. Modifications for 
>> MacBookAir1,1
>> v4 : Re-factored logic based on Apple driver. Simplified wait_status loop
>> Index: linux-stable/drivers/hwmon/applesmc.c
>> ===
>> --- linux-stable.orig/drivers/hwmon/applesmc.c
>> +++ linux-stable/drivers/hwmon/applesmc.c
>> @@ -32,6 +32,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  /* data port used by Apple SMC */
>>  #define APPLESMC_DATA_PORT  0x300
>> @@ -42,10 +43,14 @@
>>  
>>  #define APPLESMC_MAX_DATA_LENGTH 32
>>  
>> -/* wait up to 128 ms for a status change. */
>> -#define APPLESMC_MIN_WAIT   0x0010
>> -#define APPLESMC_RETRY_WAIT 0x0100
>> -#define APPLESMC_MAX_WAIT   0x2
>> +/* Apple SMC status bits */
>> +#define SMC_STATUS_AWAITING_DATA  BIT(0) /* SMC has data waiting to be read 
>> */
>> +#define SMC_STATUS_IB_CLOSED  BIT(1) /* Will ignore any input */
>> +#define SMC_STATUS_BUSY   BIT(2) /* Command in progress */
>> +
>> +/* Exponential delay boundaries */
>> +#define APPLESMC_MIN_WAIT   0x0008
>> +#define APPLESMC_MAX_WAIT   0x10
> 
> This is a substantial increase in wait time which should be documented.
> 0x2 was explained (it translated to 128 ms), but this isn't,
> and no reason is provided why it was increased to one second.
> Is there any evidence that this is needed ? The only "benefit" I
> can see is that a stuck SMC will now hang everything 8 times longer.
> 
> There really should be some evidence suggesting that the longer
> timeout is really needed, better than "the apple driver does it".
> The timeout was increased to 128 ms back in 2012, according to
> the commit because timeouts were observed on MacBookPro6,1.
> I would expect something similar here. In other words, describe
> the circumstances of observed timeouts and the affected system(s).
> 
G'day Guenter,

The wait timer turns out to be the most contentious part of the whole patch.

That particular algorithm was put forward off list, and in testing it was as
fast as {while true ; do stuff; udelay(10)}. The reason for the larger max value
isn't actually for timing purposes. It was to allow a minimum of 16 times 
around the hedge.

I've probably had 10 chops at this timeout trying to balance performance with a 
sane
algorithm. 

How does this look? This performs pretty well.

/* Minimum sleep time is 8uS */
#define APPLESMC_MIN_WAIT  0x0008

/*
 * Wait for specific status bits with a mask on the SMC.
 * Used before all transactions.
 * This does 10 fast loops of 8us then exponentially backs off for a 
 * minimum total wait of 262ms. Depending on usleep_range this could
 * run out past 500ms. 
 */

static int wait_status(u8 val, u8 mask)
{
u8 status;
int us;
int i;

us=APPLESMC_MIN_WAIT;
for (i = 0; i < 24 ; i++) {
status = inb(APPLESMC_CMD_PORT);
if ((status & mask) == val)
return 0;
usleep_range(us, us * 2);
if (i > 9)
us <<= 1;
}
return -EIO;
}

Regards,
Brad

[PATCH v1] applesmc: Cleanups on top of re-work comms

[Brad Campbell]

A few small cleanups on top of the comms changes for applesmc.c :

send_byte() is always called with APPLESMC_CMD_PORT, so simplify.
Remove redundant check from smc_sane().
Consolidate writing length with other setup parameters.
Consolidate read and write error messages to a single statement each.

Length and error consolidation suggested by Henrik Rydberg 

Signed-off-by: Brad Campbell 

Index: linux-stable/drivers/hwmon/applesmc.c
===
--- linux-stable.orig/drivers/hwmon/applesmc.c
+++ linux-stable/drivers/hwmon/applesmc.c
@@ -176,7 +176,7 @@ static int wait_status(u8 val, u8 mask)
 
 /* send_byte - Write to SMC data port. Callers must hold applesmc_lock. */
 
-static int send_byte(u8 cmd, u16 port)
+static int send_byte(u8 cmd)
 {
int status;
 
@@ -186,7 +186,7 @@ static int send_byte(u8 cmd, u16 port)
status = wait_status(SMC_STATUS_BUSY, SMC_STATUS_BUSY);
if (status)
return status;
-   outb(cmd, port);
+   outb(cmd, APPLESMC_DATA_PORT);
return 0;
 }
 
@@ -219,10 +219,7 @@ static int smc_sane(void)
ret = send_command(APPLESMC_READ_CMD);
if (ret)
return ret;
-   ret = wait_status(0, SMC_STATUS_BUSY);
-   if (!ret)
-   return ret;
-   return -EIO;
+   return wait_status(0, SMC_STATUS_BUSY);
 }
 
 static int send_argument(const char *key)
@@ -230,7 +227,7 @@ static int send_argument(const char *key
int i;
 
for (i = 0; i < 4; i++)
-   if (send_byte(key[i], APPLESMC_DATA_PORT))
+   if (send_byte(key[i]))
return -EIO;
return 0;
 }
@@ -245,23 +242,14 @@ static int read_smc(u8 cmd, const char *
if (ret)
return ret;
 
-   if (send_command(cmd) || send_argument(key)) {
-   pr_warn("%.4s: read arg fail\n", key);
-   return -EIO;
-   }
-
-   /* This has no effect on newer (2012) SMCs */
-   if (send_byte(len, APPLESMC_DATA_PORT)) {
-   pr_warn("%.4s: read len fail\n", key);
-   return -EIO;
-   }
+   if (send_command(cmd) || send_argument(key) || send_byte(len))
+   goto err;
 
for (i = 0; i < len; i++) {
if (wait_status(SMC_STATUS_AWAITING_DATA | SMC_STATUS_BUSY,
-   SMC_STATUS_AWAITING_DATA | SMC_STATUS_BUSY) < 
0) {
-   pr_warn("%.4s: read data[%d] fail\n", key, i);
-   return -EIO;
-   }
+   SMC_STATUS_AWAITING_DATA | SMC_STATUS_BUSY))
+   goto err;
+
buffer[i] = inb(APPLESMC_DATA_PORT);
}
 
@@ -277,6 +265,9 @@ static int read_smc(u8 cmd, const char *
pr_warn("flushed %d bytes, last value is: %d\n", i, data);
 
return wait_status(0, SMC_STATUS_BUSY);
+err:
+   pr_warn("read cmd fail: %x %.4s %d\n", cmd, key, len);
+   return -EIO;
 }
 
 static int write_smc(u8 cmd, const char *key, const u8 *buffer, u8 len)
@@ -288,24 +279,17 @@ static int write_smc(u8 cmd, const char
if (ret)
return ret;
 
-   if (send_command(cmd) || send_argument(key)) {
-   pr_warn("%s: write arg fail\n", key);
-   return -EIO;
-   }
+   if (send_command(cmd) || send_argument(key) || send_byte(len))
+   goto err;
 
-   if (send_byte(len, APPLESMC_DATA_PORT)) {
-   pr_warn("%.4s: write len fail\n", key);
-   return -EIO;
-   }
-
-   for (i = 0; i < len; i++) {
-   if (send_byte(buffer[i], APPLESMC_DATA_PORT)) {
-   pr_warn("%s: write data fail\n", key);
-   return -EIO;
-   }
-   }
+   for (i = 0; i < len; i++)
+   if (send_byte(buffer[i]))
+   goto err;
 
return wait_status(0, SMC_STATUS_BUSY);
+err:
+   pr_warn("write cmd fail: %x %.4s %d\n", cmd, key, len);
+   return -EIO;
 }
 
 static int read_register_count(unsigned int *count)

[PATCH v4 1/1] applesmc: Re-work SMC comms

[Brad Campbell]

Commit fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
introduced an issue whereby communication with the SMC became
unreliable with write errors like :

[  120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40
[  120.378621] applesmc: LKSB: write data fail
[  120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40
[  120.512787] applesmc: LKSB: write data fail

The original code appeared to be timing sensitive and was not reliable
with the timing changes in the aforementioned commit.

This patch re-factors the SMC communication to remove the timing
dependencies and restore function with the changes previously
committed.

Tested on : MacbookAir6,2 MacBookPro11,1 iMac12,2, MacBookAir1,1,
MacBookAir3,1

Fixes: fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
Reported-by: Andreas Kemnade 
Tested-by: Andreas Kemnade  # MacBookAir6,2
Acked-by: Arnd Bergmann 
Signed-off-by: Brad Campbell 
Signed-off-by: Henrik Rydberg 

---
Changelog : 
v1 : Initial attempt
v2 : Address logic and coding style
v3 : Removed some debug hangover. Added tested-by. Modifications for 
MacBookAir1,1
v4 : Re-factored logic based on Apple driver. Simplified wait_status loop
Index: linux-stable/drivers/hwmon/applesmc.c
===
--- linux-stable.orig/drivers/hwmon/applesmc.c
+++ linux-stable/drivers/hwmon/applesmc.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* data port used by Apple SMC */
 #define APPLESMC_DATA_PORT 0x300
@@ -42,10 +43,14 @@
 
 #define APPLESMC_MAX_DATA_LENGTH 32
 
-/* wait up to 128 ms for a status change. */
-#define APPLESMC_MIN_WAIT  0x0010
-#define APPLESMC_RETRY_WAIT0x0100
-#define APPLESMC_MAX_WAIT  0x2
+/* Apple SMC status bits */
+#define SMC_STATUS_AWAITING_DATA  BIT(0) /* SMC has data waiting to be read */
+#define SMC_STATUS_IB_CLOSED  BIT(1) /* Will ignore any input */
+#define SMC_STATUS_BUSY   BIT(2) /* Command in progress */
+
+/* Exponential delay boundaries */
+#define APPLESMC_MIN_WAIT  0x0008
+#define APPLESMC_MAX_WAIT  0x10
 
 #define APPLESMC_READ_CMD  0x10
 #define APPLESMC_WRITE_CMD 0x11
@@ -151,65 +156,73 @@ static unsigned int key_at_index;
 static struct workqueue_struct *applesmc_led_wq;
 
 /*
- * wait_read - Wait for a byte to appear on SMC port. Callers must
- * hold applesmc_lock.
+ * Wait for specific status bits with a mask on the SMC
+ * Used before all transactions
  */
-static int wait_read(void)
+
+static int wait_status(u8 val, u8 mask)
 {
-   unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
u8 status;
int us;
 
-   for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
-   usleep_range(us, us * 16);
+   for (us = APPLESMC_MIN_WAIT; us <= APPLESMC_MAX_WAIT; us <<= 1) {
status = inb(APPLESMC_CMD_PORT);
-   /* read: wait for smc to settle */
-   if (status & 0x01)
+   if ((status & mask) == val)
return 0;
-   /* timeout: give up */
-   if (time_after(jiffies, end))
-   break;
+   usleep_range(APPLESMC_MIN_WAIT, us);
}
-
-   pr_warn("wait_read() fail: 0x%02x\n", status);
return -EIO;
 }
 
-/*
- * send_byte - Write to SMC port, retrying when necessary. Callers
- * must hold applesmc_lock.
- */
+/* send_byte - Write to SMC data port. Callers must hold applesmc_lock. */
+
 static int send_byte(u8 cmd, u16 port)
 {
-   u8 status;
-   int us;
-   unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
+   int status;
 
+   status = wait_status(0, SMC_STATUS_IB_CLOSED);
+   if (status)
+   return status;
+   status = wait_status(SMC_STATUS_BUSY, SMC_STATUS_BUSY);
+   if (status)
+   return status;
outb(cmd, port);
-   for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
-   usleep_range(us, us * 16);
-   status = inb(APPLESMC_CMD_PORT);
-   /* write: wait for smc to settle */
-   if (status & 0x02)
-   continue;
-   /* ready: cmd accepted, return */
-   if (status & 0x04)
-   return 0;
-   /* timeout: give up */
-   if (time_after(jiffies, end))
-   break;
-   /* busy: long wait and resend */
-   udelay(APPLESMC_RETRY_WAIT);
-   outb(cmd, port);
-   }
-
-   pr_warn("send_byte(0x%02x, 0x%04x) fail: 0x%02x\n", cmd, port, status);
-   return -EIO;
+   return 0;
 }
 
+/* send_command - Write a command to the SMC. Callers must hold applesmc_lock. 
*/
+
 static int send_command(u8 cmd)
 {
-   return send_byte(cmd, APPLESMC_CMD_PORT);
+  

[PATCH v4 0/1] applesmc: Re-work SMC comms

[Brad Campbell]

G'day All,

Versions 1-3 of this patch were various attempts to try and simplify/clarify 
the communication to the SMC in order to remove the timing sensitivity which 
was exposed by Commit fff2d0f701e6 ("hwmon: (applesmc) avoid overlong 
udelay()"). As with the original author(s), we were limited in not having any 
documentation and relying on a "poke it and see what happens".

Whilst version 3 ticked all the boxes from a performance and reliability 
standpoint it still wasn't clear why it worked and why retries were required 
when sending a command to the SMC. I dug into the OSX driver to try and seek 
some clarity around that and found a very simple "state corrector" for want of 
a better word, whereby any interaction with the SMC was preceded by a simple 3 
step process (found in smc_sane()) which ensured the SMC was in the right state 
to accept a transaction (or ultimately reported as broken). My testing has 
shown this routine is generally only required once on driver load to sync up 
the state machine, however it's purpose is to pull the SMC back into line if 
its internal state machine gets out of sync. This was likely happening with the 
command retry loop in the earlier versions, however due to the way the status 
bits were being checked it was unclear.

The other thing that was clear is outside of the "state corrector", all 
checking of SMC status bits happened before a read/write, not after. By 
re-working the comms to follow this protocol I believe we've simplified the 
code, made the actual operation clearer and removed *all* timing dependencies. 
This has also allowed a simplification of the timing in wait_status and a 
reduction in the waits incurred.

Henrik further simplified wait_status by leaving the minimum wait in 
usleep_range as 8uS. Testing on multiple machines has borne this out resulting 
in less loops/sleeps and no apparent impact in the performance of the driver 
(and in fact an increase on my iMac12,2 with a _very_ slow SMC). It also 
allowed for the removal of the jiffy based timeout as worst case it's going to 
sleep for a couple of seconds. The OSX driver puts a 10s timeout on every wait.

So, after much testing I'll submit v4 for comment and further testing.

Regards,
Brad

Re: [PATCH v3] applesmc: Re-work SMC comms

[Brad Campbell]

On 10/11/20 3:55 pm, Guenter Roeck wrote:
> On Tue, Nov 10, 2020 at 01:04:04PM +1100, Brad Campbell wrote:
>> On 9/11/20 3:06 am, Guenter Roeck wrote:
>>> On 11/8/20 2:14 AM, Henrik Rydberg wrote:
>>>> On Sun, Nov 08, 2020 at 09:35:28AM +0100, Henrik Rydberg wrote:
>>>>> Hi Brad,
>>>>>
>>>>> On 2020-11-08 02:00, Brad Campbell wrote:
>>>>>> G'day Henrik,
>>>>>>
>>>>>> I noticed you'd also loosened up the requirement for SMC_STATUS_BUSY in 
>>>>>> read_smc(). I assume
>>>>>> that causes problems on the early Macbook. This is revised on the one 
>>>>>> sent earlier.
>>>>>> If you could test this on your Air1,1 it'd be appreciated.
>>>>>
>>>>> No, I managed to screw up the patch; you can see that I carefully added 
>>>>> the
>>>>> same treatment for the read argument, being unsure if the BUSY state would
>>>>> remain during the AVAILABLE data phase. I can check that again, but
>>>>> unfortunately the patch in this email shows the same problem.
>>>>>
>>>>> I think it may be worthwhile to rethink the behavior of wait_status() 
>>>>> here.
>>>>> If one machine shows no change after a certain status bit change, then
>>>>> perhaps the others share that behavior, and we are waiting in vain. Just
>>>>> imagine how many years of cpu that is, combined. ;-)
>>>>
>>>> Here is a modification along that line.
>>>>
>>>
>>> Please resend this patch as stand-alone v4 patch. If sent like it was sent 
>>> here,
>>> it doesn't make it into patchwork, and is thus not only difficult to apply 
>>> but
>>> may get lost, and it is all but impossible to find and apply all tags.
>>> Also, prior to Henrik's Signed=off-by: there should be a one-line 
>>> explanation
>>> of the changes made.
>>>
>>> Thanks,
>>> Guenter
>>>
>>>> Compared to your latest version, this one has wait_status() return the
>>>> actual status on success. Instead of waiting for BUSY, it waits for
>>>> the other status bits, and checks BUSY afterwards. So as not to wait
>>>> unneccesarily, the udelay() is placed together with the single
>>>> outb(). The return value of send_byte_data() is augmented with
>>>> -EAGAIN, which is then used in send_command() to create the resend
>>>> loop.
>>>>
>>>> I reach 41 reads per second on the MBA1,1 with this version, which is
>>>> getting close to the performance prior to the problems.
>>>>
>>
>> Can I get an opinion on this wait statement please?
>>
>> The apple driver uses a loop with a million (1,000,000) retries spaced with 
>> a 10uS delay.
>>
>> In my testing on 2 machines, we don't busy wait more than about 2 loops.
>> Replacing a small udelay with the usleep_range kills performance.
>> With the following (do 10 fast checks before we start sleeping) I nearly 
>> triple the performance
>> of the driver on my laptop, and double it on my iMac. This is on an 
>> otherwise unmodified version of
>> Henriks v4 submission.
>>
>> Yes, given the timeouts I know it's a ridiculous loop condition.
>>
>> static int wait_status(u8 val, u8 mask)
>> {
>>  unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
>>  u8 status;
>>  int i;
>>
>>  for (i=1; i < 100; i++) {
> 
> The minimum wait time is 10 us, or 16uS after the first 10
> attempts. 100 * 10 = 10 seconds. I mean, it would make
> some sense to limit the loop to APPLESMC_MAX_WAIT /
> APPLESMC_MIN_WAIT iterations, but why 1,000,000 ?

I had to pick a big number and it was easy to punch in 6 zeros as that is what 
is in
the OSX driver. In this instance it's more a proof of concept rather than sane 
example
because it'll either abort on timeout or return the correct status anyway.
Could also have been a while (true) {} but then I'd need to manually increment 
i.

>>  status = inb(APPLESMC_CMD_PORT);
>>  if ((status & mask) == val)
>>  return status;
>>  /* timeout: give up */
>>  if (time_after(jiffies, end))
>>  break;
>>  if (i < 10)
>>  udelay(10);
>>  else
>>  usleep_range(APPLESMC_MIN_WAIT, APPLESMC_MIN_WAIT * 16);
>

Re: [PATCH v3] applesmc: Re-work SMC comms

[Brad Campbell]

On 9/11/20 3:06 am, Guenter Roeck wrote:
> On 11/8/20 2:14 AM, Henrik Rydberg wrote:
>> On Sun, Nov 08, 2020 at 09:35:28AM +0100, Henrik Rydberg wrote:
>>> Hi Brad,
>>>
>>> On 2020-11-08 02:00, Brad Campbell wrote:
>>>> G'day Henrik,
>>>>
>>>> I noticed you'd also loosened up the requirement for SMC_STATUS_BUSY in 
>>>> read_smc(). I assume
>>>> that causes problems on the early Macbook. This is revised on the one sent 
>>>> earlier.
>>>> If you could test this on your Air1,1 it'd be appreciated.
>>>
>>> No, I managed to screw up the patch; you can see that I carefully added the
>>> same treatment for the read argument, being unsure if the BUSY state would
>>> remain during the AVAILABLE data phase. I can check that again, but
>>> unfortunately the patch in this email shows the same problem.
>>>
>>> I think it may be worthwhile to rethink the behavior of wait_status() here.
>>> If one machine shows no change after a certain status bit change, then
>>> perhaps the others share that behavior, and we are waiting in vain. Just
>>> imagine how many years of cpu that is, combined. ;-)
>>
>> Here is a modification along that line.
>>
> 
> Please resend this patch as stand-alone v4 patch. If sent like it was sent 
> here,
> it doesn't make it into patchwork, and is thus not only difficult to apply but
> may get lost, and it is all but impossible to find and apply all tags.
> Also, prior to Henrik's Signed=off-by: there should be a one-line explanation
> of the changes made.
> 
> Thanks,
> Guenter
> 
>> Compared to your latest version, this one has wait_status() return the
>> actual status on success. Instead of waiting for BUSY, it waits for
>> the other status bits, and checks BUSY afterwards. So as not to wait
>> unneccesarily, the udelay() is placed together with the single
>> outb(). The return value of send_byte_data() is augmented with
>> -EAGAIN, which is then used in send_command() to create the resend
>> loop.
>>
>> I reach 41 reads per second on the MBA1,1 with this version, which is
>> getting close to the performance prior to the problems.
>>

Can I get an opinion on this wait statement please?

The apple driver uses a loop with a million (1,000,000) retries spaced with a 
10uS delay.

In my testing on 2 machines, we don't busy wait more than about 2 loops.
Replacing a small udelay with the usleep_range kills performance.
With the following (do 10 fast checks before we start sleeping) I nearly triple 
the performance
of the driver on my laptop, and double it on my iMac. This is on an otherwise 
unmodified version of
Henriks v4 submission.

Yes, given the timeouts I know it's a ridiculous loop condition.

static int wait_status(u8 val, u8 mask)
{
unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
u8 status;
int i;

for (i=1; i < 100; i++) {
status = inb(APPLESMC_CMD_PORT);
if ((status & mask) == val)
return status;
/* timeout: give up */
if (time_after(jiffies, end))
break;
if (i < 10)
udelay(10);
else
usleep_range(APPLESMC_MIN_WAIT, APPLESMC_MIN_WAIT * 16);
}
return -EIO;
}

Regards,
Brad

Re: [PATCH v3] applesmc: Re-work SMC comms

[Brad Campbell]

On 10/11/20 4:08 am, Henrik Rydberg wrote:
> Hi Brad,
> 
>> Out of morbid curiosity I grabbed an older MacOS AppleSMC.kext (10.7) and 
>> ran it through the disassembler.
>>
>> Every read/write to the SMC starts the same way with a check to make sure 
>> the SMC is in a sane state. If it's not, a read command is sent to try and 
>> kick it back into line :
>> Wait for 0x04 to clear. This is 1,000,000 iterations of "read status, check 
>> if 0x04 is set, delay 10uS".
>> If it clears, move on. If it doesn't, try and send a read command (just the 
>> command 0x10) and wait for the busy flag to clear again with the same loop.
>>
>> So in theory if the SMC was locked up, it'd be into the weeds for 20 seconds 
>> before it pushed the error out.
>>
>> So, lets say we've waited long enough and the busy flag dropped :
>>
>> Each command write is :
>> Wait for 0x02 to clear. This is 1,000,000 iterations of "read status, check 
>> if 0x02 is set, delay 10uS".
>> Send command
>>
>> Each data byte write is :
>> Wait for 0x02 to clear. This is 1,000,000 iterations of "read status, check 
>> if 0x02 is set, delay 10uS".
>> Immediate and single status read, check 0x04. If not set, abort.
>> Send data byte
>>
>> Each data byte read is :
>> read staus, wait for 0x01 and 0x04 to be set. delay 10uS and repeat. Abort 
>> if fail.
>>
>> Each timeout is 1,000,000 loops with a 10uS delay.
>>
>> So aside from the startup set which occurs on *every* read or write set, 
>> status checks happen before a command or data write, and not at all after.
>> Under no circumstances are writes of any kind re-tried, but these timeouts 
>> are up to 10 seconds!
> 
> Great findings here. But from this, it would seem we are doing almost the 
> right thing already, no? The essential difference seems to be that where the 
> kext does a read to wake up the SMC, while we retry the first command until 
> it works. If would of course be very interesting to know if that makes a 
> difference.

It does make a significant difference here. It doesn't use the read to wake up 
the SMC as such. It appears to use the read to get the SMC in sync with the 
driver. It only performs the extra read if the busy line is still active when 
it shouldn't be and provided the driver plays by the rules it only seems to do 
it once on init and only if the SMC thinks it's mid command (so has been left 
in an undefined state).

Re-working the driver to use the logic described my MacbookPro11,1 goes from 40 
reads/sec to 125 reads/sec. My iMac12,2 goes from 17 reads/sec to 30.

I have one issue to understand before I post a patch.

If the SMC is in an inconsistent state (as in busy persistently high) then the 
driver issues a read command and waits for busy to drop (and it does, and bit 
0x08 goes high on my laptop but nothing checks that). That is to a point 
expected based on the poking I did early on in this process.
On the other hand, when we perform a read or a write, the driver issues a read 
or write command and the following commands to send the key rely on the busy 
bit being set.

Now, in practice this works, and I've sent spurious commands to get things out 
of sync and after a long wait it syncs back up. I just want to try and 
understand the state machine inside the SMC a bit better before posting another 
patch.

 
>> That would indicate that the requirement for retries on the early Mac means 
>> we're not waiting long enough somewhere. Not that I'm suggesting we do 
>> another re-work, but when I get back in front of my iMac which does 17 
>> transactions per second with this driver, I might re-work it similar to the 
>> Apple driver and see what happens.
>>
>> Oh, and it looks like the 0x40 flag that is on mine is the "I have an 
>> interrupt pending" flag, and the result should be able to be read from 
>> 0x31F. I'll play with that when I get time. That probably explains why IRQ9 
>> screams until the kernel gags it on this machine as it's not being given any 
>> love.
> 
> Sounds good, getting interrupts working would have been nice.

I've put it on my list of things to look at. There's a lot of magic constants 
in the interrupt handler.

Regards,
Brad

Re: [PATCH v3] applesmc: Re-work SMC comms

[Brad Campbell]

On 8/11/20 11:04 pm, Henrik Rydberg wrote:
> On 2020-11-08 12:57, Brad Campbell wrote:
>> On 8/11/20 9:14 pm, Henrik Rydberg wrote:
>>> On Sun, Nov 08, 2020 at 09:35:28AM +0100, Henrik Rydberg wrote:
>>>> Hi Brad,
>>>>
>>>> On 2020-11-08 02:00, Brad Campbell wrote:
>>>>> G'day Henrik,
>>>>>
>>>>> I noticed you'd also loosened up the requirement for SMC_STATUS_BUSY in 
>>>>> read_smc(). I assume
>>>>> that causes problems on the early Macbook. This is revised on the one 
>>>>> sent earlier.
>>>>> If you could test this on your Air1,1 it'd be appreciated.
>>>>
>>>> No, I managed to screw up the patch; you can see that I carefully added the
>>>> same treatment for the read argument, being unsure if the BUSY state would
>>>> remain during the AVAILABLE data phase. I can check that again, but
>>>> unfortunately the patch in this email shows the same problem.
>>>>
>>>> I think it may be worthwhile to rethink the behavior of wait_status() here.
>>>> If one machine shows no change after a certain status bit change, then
>>>> perhaps the others share that behavior, and we are waiting in vain. Just
>>>> imagine how many years of cpu that is, combined. ;-)
>>>
>>> Here is a modification along that line.
>>>
>>> Compared to your latest version, this one has wait_status() return the
>>> actual status on success. Instead of waiting for BUSY, it waits for
>>> the other status bits, and checks BUSY afterwards. So as not to wait
>>> unneccesarily, the udelay() is placed together with the single
>>> outb(). The return value of send_byte_data() is augmented with
>>> -EAGAIN, which is then used in send_command() to create the resend
>>> loop.
>>>
>>> I reach 41 reads per second on the MBA1,1 with this version, which is
>>> getting close to the performance prior to the problems.
>>
>> G'day Henrik,
>>
>> I like this one. It's slower on my laptop (40 rps vs 50 on the 
>> MacbookPro11,1) and the same 17 rps on the iMac 12,2 but it's as reliable
>> and if it works for both of yours then I think it's a winner. I can't really 
>> diagnose the iMac properly as I'm 2,800KM away and have
>> nobody to reboot it if I kill it. 5.7.2 gives 20 rps, so 17 is ok for me.
>>
>> Andreas, could I ask you to test this one?
>>
>> Odd my original version worked on your Air3,1 and the other 3 machines 
>> without retry.
>> I wonder how many commands require retries, how many retires are actually 
>> required, and what we are going wrong on the Air1,1 that requires
>> one or more retries.
>>
>> I just feels like a brute force approach because there's something we're 
>> missing.
> 
> I would think you are right. There should be a way to follow the status 
> changes in realtime, so one can determine handshake and processing from that 
> information. At least, with this change, we are making the blunt instrument a 
> little smaller.

G'day Henrik,

Out of morbid curiosity I grabbed an older MacOS AppleSMC.kext (10.7) and ran 
it through the disassembler.

Every read/write to the SMC starts the same way with a check to make sure the 
SMC is in a sane state. If it's not, a read command is sent to try and kick it 
back into line :
Wait for 0x04 to clear. This is 1,000,000 iterations of "read status, check if 
0x04 is set, delay 10uS".
If it clears, move on. If it doesn't, try and send a read command (just the 
command 0x10) and wait for the busy flag to clear again with the same loop.

So in theory if the SMC was locked up, it'd be into the weeds for 20 seconds 
before it pushed the error out.

So, lets say we've waited long enough and the busy flag dropped :

Each command write is :
Wait for 0x02 to clear. This is 1,000,000 iterations of "read status, check if 
0x02 is set, delay 10uS".
Send command

Each data byte write is :
Wait for 0x02 to clear. This is 1,000,000 iterations of "read status, check if 
0x02 is set, delay 10uS".
Immediate and single status read, check 0x04. If not set, abort.
Send data byte

Each data byte read is :
read staus, wait for 0x01 and 0x04 to be set. delay 10uS and repeat. Abort if 
fail.

Each timeout is 1,000,000 loops with a 10uS delay.

So aside from the startup set which occurs on *every* read or write set, status 
checks happen before a command or data write, and not at all after.
Under no circumstances are writes of any kind re-tried, but these timeouts are 
up to 10 seconds!

That would indicate that the requirement for retries on the early Mac means 
we're not waiting long enough somewhere. Not that I'm suggesting we do another 
re-work, but when I get back in front of my iMac which does 17 transactions per 
second with this driver, I might re-work it similar to the Apple driver and see 
what happens.

Oh, and it looks like the 0x40 flag that is on mine is the "I have an interrupt 
pending" flag, and the result should be able to be read from 0x31F. I'll play 
with that when I get time. That probably explains why IRQ9 screams until the 
kernel gags it on this machine as it's not being given any love.

Regards,
Brad

Re: [PATCH v3] applesmc: Re-work SMC comms

[Brad Campbell]

On 9/11/20 7:44 pm, Andreas Kemnade wrote:
> On Sun, 8 Nov 2020 11:14:29 +0100
> Henrik Rydberg  wrote:
> 
>> On Sun, Nov 08, 2020 at 09:35:28AM +0100, Henrik Rydberg wrote:
>>> Hi Brad,
>>>
>>> On 2020-11-08 02:00, Brad Campbell wrote:  
>>>> G'day Henrik,
>>>>
>>>> I noticed you'd also loosened up the requirement for SMC_STATUS_BUSY in 
>>>> read_smc(). I assume
>>>> that causes problems on the early Macbook. This is revised on the one sent 
>>>> earlier.
>>>> If you could test this on your Air1,1 it'd be appreciated.  
>>>
>>> No, I managed to screw up the patch; you can see that I carefully added the
>>> same treatment for the read argument, being unsure if the BUSY state would
>>> remain during the AVAILABLE data phase. I can check that again, but
>>> unfortunately the patch in this email shows the same problem.
>>>
>>> I think it may be worthwhile to rethink the behavior of wait_status() here.
>>> If one machine shows no change after a certain status bit change, then
>>> perhaps the others share that behavior, and we are waiting in vain. Just
>>> imagine how many years of cpu that is, combined. ;-)  
>>
>> Here is a modification along that line.
>>
>> Compared to your latest version, this one has wait_status() return the
>> actual status on success. Instead of waiting for BUSY, it waits for
>> the other status bits, and checks BUSY afterwards. So as not to wait
>> unneccesarily, the udelay() is placed together with the single
>> outb(). The return value of send_byte_data() is augmented with
>> -EAGAIN, which is then used in send_command() to create the resend
>> loop.
>>
>> I reach 41 reads per second on the MBA1,1 with this version, which is
>> getting close to the performance prior to the problems.
>>
>> From b4405457f4ba07cff7b7e4f48c47668bee176a25 Mon Sep 17 00:00:00 2001
>> From: Brad Campbell 
>> Date: Sun, 8 Nov 2020 12:00:03 +1100
>> Subject: [PATCH] hwmon: (applesmc) Re-work SMC comms
>>
>> Commit fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
>> introduced an issue whereby communication with the SMC became
>> unreliable with write errors like :
>>
>> [  120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40
>> [  120.378621] applesmc: LKSB: write data fail
>> [  120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40
>> [  120.512787] applesmc: LKSB: write data fail
>>
>> The original code appeared to be timing sensitive and was not reliable
>> with the timing changes in the aforementioned commit.
>>
>> This patch re-factors the SMC communication to remove the timing
>> dependencies and restore function with the changes previously
>> committed.
>>
>> Tested on : MacbookAir6,2 MacBookPro11,1 iMac12,2, MacBookAir1,1,
>> MacBookAir3,1
>>
>> Fixes: fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
>> Reported-by: Andreas Kemnade 
>> Tested-by: Andreas Kemnade  # MacBookAir6,2
>> Acked-by: Arnd Bergmann 
>> Signed-off-by: Brad Campbell 
>> Signed-off-by: Henrik Rydberg 
>>
>> ---
>> Changelog : 
>> v1 : Inital attempt
>> v2 : Address logic and coding style
>> v3 : Removed some debug hangover. Added tested-by. Modifications for 
>> MacBookAir1,1
>> v4 : Do not expect busy state to appear without other state changes
>>
> 
> still works here (MacBookAir6,2)

Much appreciated Andreas.

Regards,
Brad

Re: [PATCH v3] applesmc: Re-work SMC comms

[Brad Campbell]

On 9/11/20 3:06 am, Guenter Roeck wrote:
> On 11/8/20 2:14 AM, Henrik Rydberg wrote:
>> On Sun, Nov 08, 2020 at 09:35:28AM +0100, Henrik Rydberg wrote:
>>> Hi Brad,
>>>
>>> On 2020-11-08 02:00, Brad Campbell wrote:
>>>> G'day Henrik,
>>>>
>>>> I noticed you'd also loosened up the requirement for SMC_STATUS_BUSY in 
>>>> read_smc(). I assume
>>>> that causes problems on the early Macbook. This is revised on the one sent 
>>>> earlier.
>>>> If you could test this on your Air1,1 it'd be appreciated.
>>>
>>> No, I managed to screw up the patch; you can see that I carefully added the
>>> same treatment for the read argument, being unsure if the BUSY state would
>>> remain during the AVAILABLE data phase. I can check that again, but
>>> unfortunately the patch in this email shows the same problem.
>>>
>>> I think it may be worthwhile to rethink the behavior of wait_status() here.
>>> If one machine shows no change after a certain status bit change, then
>>> perhaps the others share that behavior, and we are waiting in vain. Just
>>> imagine how many years of cpu that is, combined. ;-)
>>
>> Here is a modification along that line.
>>
> 
> Please resend this patch as stand-alone v4 patch. If sent like it was sent 
> here,
> it doesn't make it into patchwork, and is thus not only difficult to apply but
> may get lost, and it is all but impossible to find and apply all tags.
> Also, prior to Henrik's Signed=off-by: there should be a one-line explanation
> of the changes made.

G'day Guenter,

Yes, I'll do that. I still have some more testing to do before it's pushed 
forwards.

Regards,
Brad
> 
>> Compared to your latest version, this one has wait_status() return the
>> actual status on success. Instead of waiting for BUSY, it waits for
>> the other status bits, and checks BUSY afterwards. So as not to wait
>> unneccesarily, the udelay() is placed together with the single
>> outb(). The return value of send_byte_data() is augmented with
>> -EAGAIN, which is then used in send_command() to create the resend
>> loop.
>>
>> I reach 41 reads per second on the MBA1,1 with this version, which is
>> getting close to the performance prior to the problems.
>>
>> >From b4405457f4ba07cff7b7e4f48c47668bee176a25 Mon Sep 17 00:00:00 2001
>> From: Brad Campbell 
>> Date: Sun, 8 Nov 2020 12:00:03 +1100
>> Subject: [PATCH] hwmon: (applesmc) Re-work SMC comms
>>
>> Commit fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
>> introduced an issue whereby communication with the SMC became
>> unreliable with write errors like :
>>
>> [  120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40
>> [  120.378621] applesmc: LKSB: write data fail
>> [  120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40
>> [  120.512787] applesmc: LKSB: write data fail
>>
>> The original code appeared to be timing sensitive and was not reliable
>> with the timing changes in the aforementioned commit.
>>
>> This patch re-factors the SMC communication to remove the timing
>> dependencies and restore function with the changes previously
>> committed.
>>
>> Tested on : MacbookAir6,2 MacBookPro11,1 iMac12,2, MacBookAir1,1,
>> MacBookAir3,1
>>
>> Fixes: fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
>> Reported-by: Andreas Kemnade 
>> Tested-by: Andreas Kemnade  # MacBookAir6,2
>> Acked-by: Arnd Bergmann 
>> Signed-off-by: Brad Campbell 
>> Signed-off-by: Henrik Rydberg 
>>
>> ---
>> Changelog : 
>> v1 : Inital attempt
>> v2 : Address logic and coding style
>> v3 : Removed some debug hangover. Added tested-by. Modifications for 
>> MacBookAir1,1
>> v4 : Do not expect busy state to appear without other state changes
>>
>> diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
>> index a18887990f4a..ea7c66d5788e 100644
>> --- a/drivers/hwmon/applesmc.c
>> +++ b/drivers/hwmon/applesmc.c
>> @@ -32,6 +32,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  /* data port used by Apple SMC */
>>  #define APPLESMC_DATA_PORT  0x300
>> @@ -42,6 +43,11 @@
>>  
>>  #define APPLESMC_MAX_DATA_LENGTH 32
>>  
>> +/* Apple SMC status bits */
>> +#define SMC_STATUS_AWAITING_DATA  BIT(0) /* SMC has data waiting */
>> +#define SMC_STATUS_IB_CLOSED  BIT(1) /* Will ignore any input */
>> +#define SMC_STATUS_BUSY   BIT(2) /* Command in p

Re: [PATCH v3] applesmc: Re-work SMC comms

[Brad Campbell]

On 8/11/20 9:14 pm, Henrik Rydberg wrote:
> On Sun, Nov 08, 2020 at 09:35:28AM +0100, Henrik Rydberg wrote:
>> Hi Brad,
>>
>> On 2020-11-08 02:00, Brad Campbell wrote:
>>> G'day Henrik,
>>>
>>> I noticed you'd also loosened up the requirement for SMC_STATUS_BUSY in 
>>> read_smc(). I assume
>>> that causes problems on the early Macbook. This is revised on the one sent 
>>> earlier.
>>> If you could test this on your Air1,1 it'd be appreciated.
>>
>> No, I managed to screw up the patch; you can see that I carefully added the
>> same treatment for the read argument, being unsure if the BUSY state would
>> remain during the AVAILABLE data phase. I can check that again, but
>> unfortunately the patch in this email shows the same problem.
>>
>> I think it may be worthwhile to rethink the behavior of wait_status() here.
>> If one machine shows no change after a certain status bit change, then
>> perhaps the others share that behavior, and we are waiting in vain. Just
>> imagine how many years of cpu that is, combined. ;-)
> 
> Here is a modification along that line.
> 
> Compared to your latest version, this one has wait_status() return the
> actual status on success. Instead of waiting for BUSY, it waits for
> the other status bits, and checks BUSY afterwards. So as not to wait
> unneccesarily, the udelay() is placed together with the single
> outb(). The return value of send_byte_data() is augmented with
> -EAGAIN, which is then used in send_command() to create the resend
> loop.
> 
> I reach 41 reads per second on the MBA1,1 with this version, which is
> getting close to the performance prior to the problems.

G'day Henrik,

I like this one. It's slower on my laptop (40 rps vs 50 on the MacbookPro11,1) 
and the same 17 rps on the iMac 12,2 but it's as reliable
and if it works for both of yours then I think it's a winner. I can't really 
diagnose the iMac properly as I'm 2,800KM away and have
nobody to reboot it if I kill it. 5.7.2 gives 20 rps, so 17 is ok for me.

Andreas, could I ask you to test this one?

Odd my original version worked on your Air3,1 and the other 3 machines without 
retry.
I wonder how many commands require retries, how many retires are actually 
required, and what we are going wrong on the Air1,1 that requires
one or more retries. 

I just feels like a brute force approach because there's something we're 
missing.

> From b4405457f4ba07cff7b7e4f48c47668bee176a25 Mon Sep 17 00:00:00 2001
> From: Brad Campbell 
> Date: Sun, 8 Nov 2020 12:00:03 +1100
> Subject: [PATCH] hwmon: (applesmc) Re-work SMC comms
> 
> Commit fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
> introduced an issue whereby communication with the SMC became
> unreliable with write errors like :
> 
> [  120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40
> [  120.378621] applesmc: LKSB: write data fail
> [  120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40
> [  120.512787] applesmc: LKSB: write data fail
> 
> The original code appeared to be timing sensitive and was not reliable
> with the timing changes in the aforementioned commit.
> 
> This patch re-factors the SMC communication to remove the timing
> dependencies and restore function with the changes previously
> committed.
> 
> Tested on : MacbookAir6,2 MacBookPro11,1 iMac12,2, MacBookAir1,1,
> MacBookAir3,1
> 
> Fixes: fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
> Reported-by: Andreas Kemnade 
> Tested-by: Andreas Kemnade  # MacBookAir6,2
> Acked-by: Arnd Bergmann 
> Signed-off-by: Brad Campbell 
> Signed-off-by: Henrik Rydberg 
> 
> ---
> Changelog : 
> v1 : Inital attempt
> v2 : Address logic and coding style
> v3 : Removed some debug hangover. Added tested-by. Modifications for 
> MacBookAir1,1
> v4 : Do not expect busy state to appear without other state changes
> 
> diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
> index a18887990f4a..ea7c66d5788e 100644
> --- a/drivers/hwmon/applesmc.c
> +++ b/drivers/hwmon/applesmc.c
> @@ -32,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /* data port used by Apple SMC */
>  #define APPLESMC_DATA_PORT   0x300
> @@ -42,6 +43,11 @@
>  
>  #define APPLESMC_MAX_DATA_LENGTH 32
>  
> +/* Apple SMC status bits */
> +#define SMC_STATUS_AWAITING_DATA  BIT(0) /* SMC has data waiting */
> +#define SMC_STATUS_IB_CLOSED  BIT(1) /* Will ignore any input */
> +#define SMC_STATUS_BUSY   BIT(2) /* Command in progress */
> +
>  /* wait up to 128 ms for a status change. */
>  #define APPLESMC_MIN_WAIT0x0010
>  #define APPLESMC_RETRY_WAIT  0x0100
> @@ -151,65 +157

[PATCH v3] applesmc: Re-work SMC comms

[Brad Campbell]

G'day Henrik,

I noticed you'd also loosened up the requirement for SMC_STATUS_BUSY in 
read_smc(). I assume
that causes problems on the early Macbook. This is revised on the one sent 
earlier.
If you could test this on your Air1,1 it'd be appreciated.


Commit fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()") introduced
an issue whereby communication with the SMC became unreliable with write
errors like :

[  120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40
[  120.378621] applesmc: LKSB: write data fail
[  120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40
[  120.512787] applesmc: LKSB: write data fail

The original code appeared to be timing sensitive and was not reliable with
the timing changes in the aforementioned commit.

This patch re-factors the SMC communication to remove the timing 
dependencies and restore function with the changes previously committed.

Tested on : MacbookAir6,2 MacBookPro11,1 iMac12,2

Fixes: fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
Reported-by: Andreas Kemnade 
Tested-by: Andreas Kemnade  # MacBookAir6,2
Acked-by: Arnd Bergmann 
Signed-off-by: Brad Campbell 
Signed-off-by: Henrik Rydberg 

---
Changelog : 
v1 : Inital attempt
v2 : Address logic and coding style
v3 : Removed some debug hangover. Added tested-by. Modifications for 
MacBookAir1,1

diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
index a18887990f4a..3e968abb37aa 100644
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* data port used by Apple SMC */
 #define APPLESMC_DATA_PORT 0x300
@@ -42,6 +43,11 @@
 
 #define APPLESMC_MAX_DATA_LENGTH 32
 
+/* Apple SMC status bits */
+#define SMC_STATUS_AWAITING_DATA  BIT(0) /* SMC has data waiting */
+#define SMC_STATUS_IB_CLOSED  BIT(1) /* Will ignore any input */
+#define SMC_STATUS_BUSY   BIT(2) /* Command in progress */
+
 /* wait up to 128 ms for a status change. */
 #define APPLESMC_MIN_WAIT  0x0010
 #define APPLESMC_RETRY_WAIT0x0100
@@ -151,65 +157,73 @@ static unsigned int key_at_index;
 static struct workqueue_struct *applesmc_led_wq;
 
 /*
- * wait_read - Wait for a byte to appear on SMC port. Callers must
- * hold applesmc_lock.
+ * Wait for specific status bits with a mask on the SMC
+ * Used before and after writes, and before reads
  */
-static int wait_read(void)
+
+static int wait_status(u8 val, u8 mask)
 {
unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
u8 status;
int us;
 
+   udelay(APPLESMC_MIN_WAIT);
for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
-   usleep_range(us, us * 16);
status = inb(APPLESMC_CMD_PORT);
-   /* read: wait for smc to settle */
-   if (status & 0x01)
+   if ((status & mask) == val)
return 0;
/* timeout: give up */
if (time_after(jiffies, end))
break;
+   usleep_range(us, us * 16);
}
-
-   pr_warn("wait_read() fail: 0x%02x\n", status);
return -EIO;
 }
 
 /*
- * send_byte - Write to SMC port, retrying when necessary. Callers
+ * send_byte_data - Write to SMC data port. Callers
  * must hold applesmc_lock.
+ * Parameter skip must be true on the last write of any
+ * command or it'll time out.
  */
-static int send_byte(u8 cmd, u16 port)
+
+static int send_byte_data(u8 cmd, u16 port, bool skip)
 {
-   u8 status;
-   int us;
-   unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
+   int ret;
 
+   ret = wait_status(SMC_STATUS_BUSY, SMC_STATUS_BUSY | 
SMC_STATUS_IB_CLOSED);
+   if (ret)
+   return ret;
outb(cmd, port);
-   for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
-   usleep_range(us, us * 16);
-   status = inb(APPLESMC_CMD_PORT);
-   /* write: wait for smc to settle */
-   if (status & 0x02)
-   continue;
-   /* ready: cmd accepted, return */
-   if (status & 0x04)
-   return 0;
-   /* timeout: give up */
-   if (time_after(jiffies, end))
-   break;
-   /* busy: long wait and resend */
-   udelay(APPLESMC_RETRY_WAIT);
-   outb(cmd, port);
-   }
+   return wait_status(skip ? 0 : SMC_STATUS_BUSY, SMC_STATUS_BUSY);
+}
 
-   pr_warn("send_byte(0x%02x, 0x%04x) fail: 0x%02x\n", cmd, port, status);
-   return -EIO;
+static int send_byte(u8 cmd, u16 port)
+{
+   return send_byte_data(cmd, port, false);
 }
 
+/*
+ * send_command - Write a command to the SMC. Callers must hold applesmc_lock.
+ * If SMC is in undefined state, any new command write resets the state 
machin

Re: [PATCH] applesmc: Re-work SMC comms v2

[Brad Campbell]

On 8/11/20 5:31 am, Henrik Rydberg wrote:
> On 2020-11-06 21:02, Henrik Rydberg wrote:
>>> So as it stands, it does not work at all. I will continue to check another 
>>> machine, and see if I can get something working.
>>
>> On the MacBookAir3,1 the situation is somewhat better.
>>
>> The first three tree positions result in zero failures and 10 reads per 
>> second. The fourth yields zero failues and 11 reads per second, within the 
>> margin of similarity.
>>
>> So, the patch appears to have no apparent effect on the 3,1 series.
>>
>> Now onto fixing the 1,1 behavior.
> 
> Hi again,
> 
> This patch, v3, works for me, on both MBA1,1 and MBA3,1. Both machines yields 
> 25 reads per second.
> 
> It turns out that the origin code has a case that was not carried over to the 
> v2 patch; the command byte needs to be resent upon the wrong status code. I 
> added that back. Also, there seems to be a basic response time that needs to 
> be respected, so I added back a small fixed delay after each write operation. 
> I also took the liberty to reduce the number of status reads, and clean up 
> error handling. Checkpatch is happy with this version.
> 
> The code obviously needs to be retested on the other machines, but the logic 
> still follows what you wrote, Brad, and I have also checked it against the 
> VirtualSMC code. It appears to make sense, so hopefully there wont be 
> additional issues.
> 
> Thanks,
> Henrik
> 

G'day Henrik,

Which kernel was this based on? It won't apply to my 5.9 tree.

I assume the sprinkling of udelay(APPLESMC_MIN_WAIT) means the SMC is
slow in getting its status register set up. Could we instead just put
a single one of those up-front in wait_status?

Any chance you could try this one? I've added a retry to send_command and 
added a single global APPLESMC_MIN_WAIT before each status read.

>From looking at your modified send_command, it appears the trigger for a 
retry is sending a command and the SMC doing absolutely nothing. This
should do the same thing.

Interestingly enough, by adding the udelay to wait_status on my machine I've
gone from 24 reads/s to 50 reads/s.

I've left out the remainder of the cleanups. Once we get a minimally working
patch I was going to look at a few cleanups, and I have some patches pending
to allow writing to the SMC from userspace (for setting BCLM and BFCL mainly)


diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
index a18887990f4a..2190de78b5f5 100644
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* data port used by Apple SMC */
 #define APPLESMC_DATA_PORT 0x300
@@ -42,6 +43,11 @@
 
 #define APPLESMC_MAX_DATA_LENGTH 32
 
+/* Apple SMC status bits */
+#define SMC_STATUS_AWAITING_DATA  BIT(0) /* SMC has data waiting */
+#define SMC_STATUS_IB_CLOSED  BIT(1) /* Will ignore any input */
+#define SMC_STATUS_BUSY   BIT(2) /* Command in progress */
+
 /* wait up to 128 ms for a status change. */
 #define APPLESMC_MIN_WAIT  0x0010
 #define APPLESMC_RETRY_WAIT0x0100
@@ -151,65 +157,73 @@ static unsigned int key_at_index;
 static struct workqueue_struct *applesmc_led_wq;
 
 /*
- * wait_read - Wait for a byte to appear on SMC port. Callers must
- * hold applesmc_lock.
+ * Wait for specific status bits with a mask on the SMC
+ * Used before and after writes, and before reads
  */
-static int wait_read(void)
+
+static int wait_status(u8 val, u8 mask)
 {
unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
u8 status;
int us;
 
+   udelay(APPLESMC_MIN_WAIT);
for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
-   usleep_range(us, us * 16);
status = inb(APPLESMC_CMD_PORT);
-   /* read: wait for smc to settle */
-   if (status & 0x01)
+   if ((status & mask) == val)
return 0;
/* timeout: give up */
if (time_after(jiffies, end))
break;
+   usleep_range(us, us * 16);
}
-
-   pr_warn("wait_read() fail: 0x%02x\n", status);
return -EIO;
 }
 
 /*
- * send_byte - Write to SMC port, retrying when necessary. Callers
+ * send_byte_data - Write to SMC data port. Callers
  * must hold applesmc_lock.
+ * Parameter skip must be true on the last write of any
+ * command or it'll time out.
  */
-static int send_byte(u8 cmd, u16 port)
+
+static int send_byte_data(u8 cmd, u16 port, bool skip)
 {
-   u8 status;
-   int us;
-   unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
+   int ret;
 
+   ret = wait_status(SMC_STATUS_BUSY, SMC_STATUS_BUSY | 
SMC_STATUS_IB_CLOSED);
+   if (ret)
+   return ret;
outb(cmd, port);
-   for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
-   usleep_range(us, us * 16);
-   status = 

Re: [PATCH] applesmc: Re-work SMC comms v2

[Brad Campbell]

On 7/11/20 3:26 am, Henrik Rydberg wrote:
>>> I can't guarantee it won't break older machines which is why I've asked for 
>>> help testing it. I only have a MacbookPro 11,1 and an iMac 12,2. It fixes 
>>> both of those.
>>>
>>> Help testing would be much appreciated.
>>
>> I see, this makes much more sense. I may be able to run some tests tonight. 
>> Meanwhile, looking at the patch, the status variable in send_command looks 
>> superfluous now that there is a wait_status() before it.
> 
> Ok, it took some time to get the machines up to speed, but so far I have 
> managed to run some tests on an MacBookAir1,1. I only managed to upgrade up 
> to 4.15, so I had to revert the inputdev polling patch, but the rest applied 
> without problems. I recovered an old test program I used to use (attached), 
> and checked for failures and reads per second
> 
> *** hwmon: (applesmc) switch to using input device polling mode
> 
> At this point in the tree, with this reverted, I see 0 failures and 55 reads 
> per second.
> 
> *** hwmon: (applesmc) avoid overlong udelay()
> 
> With this applied, I see 0 failures and 16 reads per second.
> 
> *** hwmon: (applesmc) check status earlier.
> 
> With this applied, I see 0 failures and 16 reads per second.
> 
> *** (HEAD -> stable) applesmc: Re-work SMC comms v2
> 
> With this applied, the kernel hangs in module probe, and the kernel log is 
> flooded with read failures.
> 
> So as it stands, it does not work at all. I will continue to check another 
> machine, and see if I can get something working.
> 
> Henrik


G'day Heinrik,

If you could try this earlier version which still had all the failure logging 
it in we might be able to get a handle on the failure.

Regards,
Brad

---
diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
index a18887990f4a..22cc5122ce9a 100644
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -42,6 +42,11 @@
 
 #define APPLESMC_MAX_DATA_LENGTH 32
 
+/* Apple SMC status bits from VirtualSMC */
+#define SMC_STATUS_AWAITING_DATA  0x01  ///< Data waiting to be read
+#define SMC_STATUS_IB_CLOSED  0x02  /// A write is pending / will ignore 
input
+#define SMC_STATUS_BUSY   0x04  ///< Busy in the middle of a command.
+
 /* wait up to 128 ms for a status change. */
 #define APPLESMC_MIN_WAIT  0x0010
 #define APPLESMC_RETRY_WAIT0x0100
@@ -151,65 +156,77 @@ static unsigned int key_at_index;
 static struct workqueue_struct *applesmc_led_wq;
 
 /*
- * wait_read - Wait for a byte to appear on SMC port. Callers must
- * hold applesmc_lock.
+ * Wait for specific status bits with a mask on the SMC
+ * Used before and after writes, and before reads
  */
-static int wait_read(void)
+
+static int wait_status(u8 val, u8 mask)
 {
unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
u8 status;
int us;
 
for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
-   usleep_range(us, us * 16);
status = inb(APPLESMC_CMD_PORT);
-   /* read: wait for smc to settle */
-   if (status & 0x01)
+   if ((status & mask) == val)
return 0;
/* timeout: give up */
if (time_after(jiffies, end))
break;
-   }
-
-   pr_warn("wait_read() fail: 0x%02x\n", status);
+   usleep_range(us, us * 16);
+   }
+   pr_warn("wait_status timeout: 0x%02x, 0x%02x, 0x%02x\n", status, val, 
mask);
return -EIO;
 }
 
 /*
- * send_byte - Write to SMC port, retrying when necessary. Callers
+ * send_byte_data - Write to SMC data port. Callers
  * must hold applesmc_lock.
+ * Parameter skip must be true on the last write of any
+ * command or it'll time out.
  */
-static int send_byte(u8 cmd, u16 port)
+
+static int send_byte_data(u8 cmd, u16 port, bool skip)
 {
-   u8 status;
-   int us;
-   unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
+   u8 wstat = SMC_STATUS_BUSY;
 
+   if (skip)
+   wstat = 0;
+   if (wait_status(SMC_STATUS_BUSY,
+   SMC_STATUS_BUSY | SMC_STATUS_IB_CLOSED))
+   goto fail;
outb(cmd, port);
-   for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
-   usleep_range(us, us * 16);
-   status = inb(APPLESMC_CMD_PORT);
-   /* write: wait for smc to settle */
-   if (status & 0x02)
-   continue;
-   /* ready: cmd accepted, return */
-   if (status & 0x04)
-   return 0;
-   /* timeout: give up */
-   if (time_after(jiffies, end))
-   break;
-   /* busy: long wait and resend */
-   udelay(APPLESMC_RETRY_WAIT);
-   outb(cmd, port);
-   }
-
-   pr_warn("send_byte(0x%02x, 0x%04x) fail: 0x%02x\n", cmd, port, status);
+   

Re: [PATCH] applesmc: Re-work SMC comms v2

[Brad Campbell]

On 6/11/20 3:12 am, Guenter Roeck wrote:
> On 11/4/20 11:26 PM, Brad Campbell wrote:
>> Commit fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()") introduced
>> an issue whereby communication with the SMC became unreliable with write
>> errors like :
>>
>> [  120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40
>> [  120.378621] applesmc: LKSB: write data fail
>> [  120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40
>> [  120.512787] applesmc: LKSB: write data fail
>>
>> The original code appeared to be timing sensitive and was not reliable with
>> the timing changes in the aforementioned commit.
>>
>> This patch re-factors the SMC communication to remove the timing 
>> dependencies and restore function with the changes previously committed.
>>
> 
> Still a few formatting problems, but I like this version. Id take
> care of the formatting myself, but send_command() will need a change.

Nope, I'm more than happy to sort it all out. It's a learning process.

I'd still like this to get some wider testing before I consider it ready to go
so extra revisions don't worry me.

> Subject should be
>   [PATCH v] hwmon: (applesmc) ...

Thanks.
 
>> v2 : Address logic and coding style
> 
> Change log should be after '---'

No worries, can do.

> 
>>
>> Reported-by: Andreas Kemnade 
>> Fixes: fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
>> Signed-off-by: Brad Campbell 
>>
>> ---
>> diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
>> index a18887990f4a..de890f3ec12f 100644
>> --- a/drivers/hwmon/applesmc.c
>> +++ b/drivers/hwmon/applesmc.c
>> @@ -42,6 +42,11 @@
>>  
>>  #define APPLESMC_MAX_DATA_LENGTH 32
>>  
>> +/* Apple SMC status bits */
>> +#define SMC_STATUS_AWAITING_DATA  BIT(0) /* SMC has data waiting */
>> +#define SMC_STATUS_IB_CLOSED  BIT(1) /* Will ignore any input */
>> +#define SMC_STATUS_BUSY   BIT(2) /* Command in progress */
>> +
> 
> Hah, tricked you here ;-). Using "BIT()" requires
> 
> #include 

"requires" ?? 
It compiles and tests without warning, but I'll certainly add it in.


>>  /* wait up to 128 ms for a status change. */
>>  #define APPLESMC_MIN_WAIT   0x0010
>>  #define APPLESMC_RETRY_WAIT 0x0100
>> @@ -151,65 +156,69 @@ static unsigned int key_at_index;
>>  static struct workqueue_struct *applesmc_led_wq;
>>  
>>  /*
>> - * wait_read - Wait for a byte to appear on SMC port. Callers must
>> - * hold applesmc_lock.
>> + * Wait for specific status bits with a mask on the SMC
>> + * Used before and after writes, and before reads
>>   */
>> -static int wait_read(void)
>> +
>> +static int wait_status(u8 val, u8 mask)
>>  {
>>  unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
>>  u8 status;
>>  int us;
>>  
>>  for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
>> -usleep_range(us, us * 16);
>>  status = inb(APPLESMC_CMD_PORT);
>> -/* read: wait for smc to settle */
>> -if (status & 0x01)
>> +if ((status & mask) == val)
>>  return 0;
>>  /* timeout: give up */
>>  if (time_after(jiffies, end))
>>  break;
>> -}
>> -
>> -pr_warn("wait_read() fail: 0x%02x\n", status);
>> +usleep_range(us, us * 16);
>> +}
> 
> Bad indentation of "}"

Yeah, I've found my editor "less than optimal" and I've had to correct a few
tab related indent problems manually. Thanks.
 
>>  return -EIO;
>>  }
>>  
>>  /*
>> - * send_byte - Write to SMC port, retrying when necessary. Callers
>> + * send_byte_data - Write to SMC data port. Callers
>>   * must hold applesmc_lock.
>> + * Parameter skip must be true on the last write of any
>> + * command or it'll time out.
>>   */
>> -static int send_byte(u8 cmd, u16 port)
>> +
>> +static int send_byte_data(u8 cmd, u16 port, bool skip)
>>  {
>> -u8 status;
>> -int us;
>> -unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
>> +int ret;
>>  
>> +ret = wait_status(SMC_STATUS_BUSY, SMC_STATUS_BUSY | 
>> SMC_STATUS_IB_CLOSED);
>> +if (ret)
>> +return ret;
>>  outb(cmd, port);
>> -for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
>> - 

Re: [PATCH] applesmc: Re-work SMC comms v2

[Brad Campbell]

On 5/11/20 6:56 pm, Henrik Rydberg wrote:
> Hi Brad,
> 
> Great to see this effort, it is certainly an area which could be improved. 
> After having seen several generations of Macbooks while modifying much of 
> that code, it became clear that the SMC communication got refreshed a few 
> times over the years. Every tiny change had to be tested on all machines, or 
> kept separate for a particular generation, or something would break.
> 
> I have not followed the back story here, but I imagine the need has arisen 
> because of a new refresh, and so this patch only needs to strictly apply to a 
> new generation. I would therefore advice that you write the patch in that 
> way, reducing the actual change to zero for earlier generations. It also 
> makes it easier to test the effect of the new approach on older systems. I 
> should be able to help testing on a 2008 and 2011 model once we get to that 
> stage.

G'day Henrik,

Unfortunately I didn't make these changes to accommodate a "new generation". 
Changes made in kernel 5.9 broke it on my machine and in looking at why didn't 
identify any obvious causes, so I re-worked some of the comms.

I can't guarantee it won't break older machines which is why I've asked for 
help testing it. I only have a MacbookPro 11,1 and an iMac 12,2. It fixes both 
of those.

Help testing would be much appreciated.

Regards,
Brad

[PATCH] applesmc: Re-work SMC comms v2

[Brad Campbell]

Commit fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()") introduced
an issue whereby communication with the SMC became unreliable with write
errors like :

[  120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40
[  120.378621] applesmc: LKSB: write data fail
[  120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40
[  120.512787] applesmc: LKSB: write data fail

The original code appeared to be timing sensitive and was not reliable with
the timing changes in the aforementioned commit.

This patch re-factors the SMC communication to remove the timing 
dependencies and restore function with the changes previously committed.

v2 : Address logic and coding style

Reported-by: Andreas Kemnade 
Fixes: fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
Signed-off-by: Brad Campbell 

---
diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
index a18887990f4a..de890f3ec12f 100644
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -42,6 +42,11 @@
 
 #define APPLESMC_MAX_DATA_LENGTH 32
 
+/* Apple SMC status bits */
+#define SMC_STATUS_AWAITING_DATA  BIT(0) /* SMC has data waiting */
+#define SMC_STATUS_IB_CLOSED  BIT(1) /* Will ignore any input */
+#define SMC_STATUS_BUSY   BIT(2) /* Command in progress */
+
 /* wait up to 128 ms for a status change. */
 #define APPLESMC_MIN_WAIT  0x0010
 #define APPLESMC_RETRY_WAIT0x0100
@@ -151,65 +156,69 @@ static unsigned int key_at_index;
 static struct workqueue_struct *applesmc_led_wq;
 
 /*
- * wait_read - Wait for a byte to appear on SMC port. Callers must
- * hold applesmc_lock.
+ * Wait for specific status bits with a mask on the SMC
+ * Used before and after writes, and before reads
  */
-static int wait_read(void)
+
+static int wait_status(u8 val, u8 mask)
 {
unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
u8 status;
int us;
 
for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
-   usleep_range(us, us * 16);
status = inb(APPLESMC_CMD_PORT);
-   /* read: wait for smc to settle */
-   if (status & 0x01)
+   if ((status & mask) == val)
return 0;
/* timeout: give up */
if (time_after(jiffies, end))
break;
-   }
-
-   pr_warn("wait_read() fail: 0x%02x\n", status);
+   usleep_range(us, us * 16);
+   }
return -EIO;
 }
 
 /*
- * send_byte - Write to SMC port, retrying when necessary. Callers
+ * send_byte_data - Write to SMC data port. Callers
  * must hold applesmc_lock.
+ * Parameter skip must be true on the last write of any
+ * command or it'll time out.
  */
-static int send_byte(u8 cmd, u16 port)
+
+static int send_byte_data(u8 cmd, u16 port, bool skip)
 {
-   u8 status;
-   int us;
-   unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
+   int ret;
 
+   ret = wait_status(SMC_STATUS_BUSY, SMC_STATUS_BUSY | 
SMC_STATUS_IB_CLOSED);
+   if (ret)
+   return ret;
outb(cmd, port);
-   for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
-   usleep_range(us, us * 16);
-   status = inb(APPLESMC_CMD_PORT);
-   /* write: wait for smc to settle */
-   if (status & 0x02)
-   continue;
-   /* ready: cmd accepted, return */
-   if (status & 0x04)
-   return 0;
-   /* timeout: give up */
-   if (time_after(jiffies, end))
-   break;
-   /* busy: long wait and resend */
-   udelay(APPLESMC_RETRY_WAIT);
-   outb(cmd, port);
-   }
+   return wait_status(skip ? 0 : SMC_STATUS_BUSY, SMC_STATUS_BUSY);
+}
 
-   pr_warn("send_byte(0x%02x, 0x%04x) fail: 0x%02x\n", cmd, port, status);
-   return -EIO;
+static int send_byte(u8 cmd, u16 port)
+{
+   return send_byte_data(cmd, port, false);
 }
 
+/*
+ * send_command - Write a command to the SMC. Callers must hold applesmc_lock.
+ * If SMC is in undefined state, any new command write resets the state 
machine.
+ */
+
 static int send_command(u8 cmd)
 {
-   return send_byte(cmd, APPLESMC_CMD_PORT);
+   u8 status;
+   int ret;
+
+   ret = wait_status(0, SMC_STATUS_IB_CLOSED);
+   if (ret)
+   return ret;
+
+   status = inb(APPLESMC_CMD_PORT);
+
+   outb(cmd, APPLESMC_CMD_PORT);
+   return wait_status(SMC_STATUS_BUSY, SMC_STATUS_BUSY);
 }
 
 static int send_argument(const char *key)
@@ -239,7 +248,9 @@ static int read_smc(u8 cmd, const char *key, u8 *buffer, u8 
len)
}
 
for (i = 0; i < len; i++) {
-   if (wait_read()) {
+   if (wait_status(SMC_STATUS_AWAITING_DATA | SMC_STATUS_BUS

[PATCH] applesmc: Re-work SMC comms v1

[Brad Campbell]

Commit fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()") introduced
an issue whereby communication with the SMC became unreliable with write
errors :

[  120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40
[  120.378621] applesmc: LKSB: write data fail
[  120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40
[  120.512787] applesmc: LKSB: write data fail

The original code appeared to be timing sensitive and was not reliable with
the timing changes in the aforementioned commit.

This patch re-factors the SMC communication to remove the timing 
dependencies and restore function with the changes previously committed.

Reported-by: Andreas Kemnade 
Signed-off-by: Brad Campbell 

---
diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
index a18887990f4a..22cc5122ce9a 100644
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -42,6 +42,11 @@
 
 #define APPLESMC_MAX_DATA_LENGTH 32
 
+/* Apple SMC status bits from VirtualSMC */
+#define SMC_STATUS_AWAITING_DATA  0x01  ///< Data waiting to be read
+#define SMC_STATUS_IB_CLOSED  0x02  /// A write is pending / will ignore 
input
+#define SMC_STATUS_BUSY   0x04  ///< Busy in the middle of a command.
+
 /* wait up to 128 ms for a status change. */
 #define APPLESMC_MIN_WAIT  0x0010
 #define APPLESMC_RETRY_WAIT0x0100
@@ -151,65 +156,77 @@ static unsigned int key_at_index;
 static struct workqueue_struct *applesmc_led_wq;
 
 /*
- * wait_read - Wait for a byte to appear on SMC port. Callers must
- * hold applesmc_lock.
+ * Wait for specific status bits with a mask on the SMC
+ * Used before and after writes, and before reads
  */
-static int wait_read(void)
+
+static int wait_status(u8 val, u8 mask)
 {
unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
u8 status;
int us;
 
for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
-   usleep_range(us, us * 16);
status = inb(APPLESMC_CMD_PORT);
-   /* read: wait for smc to settle */
-   if (status & 0x01)
+   if ((status & mask) == val)
return 0;
/* timeout: give up */
if (time_after(jiffies, end))
break;
-   }
-
-   pr_warn("wait_read() fail: 0x%02x\n", status);
+   usleep_range(us, us * 16);
+   }
+   pr_warn("wait_status timeout: 0x%02x, 0x%02x, 0x%02x\n", status, val, 
mask);
return -EIO;
 }
 
 /*
- * send_byte - Write to SMC port, retrying when necessary. Callers
+ * send_byte_data - Write to SMC data port. Callers
  * must hold applesmc_lock.
+ * Parameter skip must be true on the last write of any
+ * command or it'll time out.
  */
-static int send_byte(u8 cmd, u16 port)
+
+static int send_byte_data(u8 cmd, u16 port, bool skip)
 {
-   u8 status;
-   int us;
-   unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
+   u8 wstat = SMC_STATUS_BUSY;
 
+   if (skip)
+   wstat = 0;
+   if (wait_status(SMC_STATUS_BUSY,
+   SMC_STATUS_BUSY | SMC_STATUS_IB_CLOSED))
+   goto fail;
outb(cmd, port);
-   for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
-   usleep_range(us, us * 16);
-   status = inb(APPLESMC_CMD_PORT);
-   /* write: wait for smc to settle */
-   if (status & 0x02)
-   continue;
-   /* ready: cmd accepted, return */
-   if (status & 0x04)
-   return 0;
-   /* timeout: give up */
-   if (time_after(jiffies, end))
-   break;
-   /* busy: long wait and resend */
-   udelay(APPLESMC_RETRY_WAIT);
-   outb(cmd, port);
-   }
-
-   pr_warn("send_byte(0x%02x, 0x%04x) fail: 0x%02x\n", cmd, port, status);
+   if (!wait_status(wstat,
+   SMC_STATUS_BUSY))
+   return 0;
+fail:
+   pr_warn("send_byte_data(0x%02x, 0x%04x) fail\n", cmd, 
APPLESMC_CMD_PORT);
return -EIO;
 }
 
+/*
+ * send_command - Write a command to the SMC. Callers must hold applesmc_lock.
+ * If SMC is in undefined state, any new command write resets the state 
machine.
+ */
+
 static int send_command(u8 cmd)
 {
-   return send_byte(cmd, APPLESMC_CMD_PORT);
+   u8 status;
+
+   if (wait_status(0,
+   SMC_STATUS_IB_CLOSED)) {
+   pr_warn("send_command SMC was busy\n");
+   goto fail; }
+
+   status = inb(APPLESMC_CMD_PORT);
+
+   outb(cmd, APPLESMC_CMD_PORT);
+   if (!wait_status(SMC_STATUS_BUSY,
+   SMC_STATUS_BUSY))
+   return 0;
+fail:
+   pr_warn("send_cmd(0x%02x, 0x%04x) fail\n", cmd, APPLESMC_CMD_PORT);
+   return -EIO;
 }
 
 static 

Re: [REGRESSION] hwmon: (applesmc) avoid overlong udelay()

[Brad Campbell]

On 5/11/20 3:43 pm, Guenter Roeck wrote:

On 11/4/20 6:18 PM, Brad Campbell wrote:

On 5/11/20 12:20 am, Andreas Kemnade wrote:

On Tue, 3 Nov 2020 16:56:32 +1100
Brad Campbell  wrote:



If anyone with a Mac having a conventional SMC and seeing issues on 5.9 could test this it'd be 
appreciated. I'm not saying this code is "correct", but it "works for me".


Seems to work here.
   dmesg  | grep applesmc

[    1.350782] applesmc: key=561 fan=1 temp=33 index=33 acc=0 lux=2 kbd=1
[    1.350922] applesmc applesmc.768: hwmon_device_register() is deprecated. 
Please convert the driver to use hwmon_device_register_with_info().
[   17.748504] applesmc: wait_status looping 2: 0x4a, 0x4c, 0x4f
[  212.008952] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e
[  213.033930] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e
[  213.167908] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e
[  219.087854] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e

Tested it on top of 5.9


Much appreciated Andreas.

I'm not entirely sure where to go from here. I'd really like some wider testing 
before cleaning this up and submitting it. It puts extra checks & constraints 
on the comms with the SMC that weren't there previously.

I guess given there doesn't appear to have been a major outcry that the driver 
broke in 5.9 might indicate that nobody is using it, or that it only broke on 
certain machines?

Can we get some guidance from the hwmon maintainers on what direction they'd 
like to take? I don't really want to push this forward without broader testing 
only to find it breaks a whole heap of machines on the basis that it fixes mine.



Trick question ;-).

I'd suggest to keep it simple. Your patch seems to be quite complicated
and checks a lot of bits. Reducing that to a minimum would help limiting
the risk that some of those bits are interpreted differently on other
systems.

Guenter



Appreciate the feedback.

This would be the bare minimum based on the bits use in the original code. If the 
original code worked "well enough" then this should be relatively safe.

Tested on both machines I have access to.

Regards,
Brad
diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
index a18887990f4a..22cc5122ce9a 100644
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -42,6 +42,11 @@
 
 #define APPLESMC_MAX_DATA_LENGTH 32
 
+/* Apple SMC status bits from VirtualSMC */
+#define SMC_STATUS_AWAITING_DATA  0x01  ///< Data waiting to be read
+#define SMC_STATUS_IB_CLOSED  0x02  /// A write is pending / will ignore 
input
+#define SMC_STATUS_BUSY   0x04  ///< Busy in the middle of a command.
+
 /* wait up to 128 ms for a status change. */
 #define APPLESMC_MIN_WAIT  0x0010
 #define APPLESMC_RETRY_WAIT0x0100
@@ -151,65 +156,77 @@ static unsigned int key_at_index;
 static struct workqueue_struct *applesmc_led_wq;
 
 /*
- * wait_read - Wait for a byte to appear on SMC port. Callers must
- * hold applesmc_lock.
+ * Wait for specific status bits with a mask on the SMC
+ * Used before and after writes, and before reads
  */
-static int wait_read(void)
+
+static int wait_status(u8 val, u8 mask)
 {
unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
u8 status;
int us;
 
for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
-   usleep_range(us, us * 16);
status = inb(APPLESMC_CMD_PORT);
-   /* read: wait for smc to settle */
-   if (status & 0x01)
+   if ((status & mask) == val)
return 0;
/* timeout: give up */
if (time_after(jiffies, end))
break;
-   }
-
-   pr_warn("wait_read() fail: 0x%02x\n", status);
+   usleep_range(us, us * 16);
+   }
+   pr_warn("wait_status timeout: 0x%02x, 0x%02x, 0x%02x\n", status, val, 
mask);
return -EIO;
 }
 
 /*
- * send_byte - Write to SMC port, retrying when necessary. Callers
+ * send_byte_data - Write to SMC data port. Callers
  * must hold applesmc_lock.
+ * Parameter skip must be true on the last write of any
+ * command or it'll time out.
  */
-static int send_byte(u8 cmd, u16 port)
+
+static int send_byte_data(u8 cmd, u16 port, bool skip)
 {
-   u8 status;
-   int us;
-   unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
+   u8 wstat = SMC_STATUS_BUSY;
 
+   if (skip)
+   wstat = 0;
+   if (wait_status(SMC_STATUS_BUSY,
+   SMC_STATUS_BUSY | SMC_STATUS_IB_CLOSED))
+   goto fail;
outb(cmd, port);
-   for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
-   usleep_range(us, us * 16);
-   status = inb(APPLESMC_CMD_PORT);
-   /* write: wait for smc to settle */
-   if (status &a

Re: [REGRESSION] hwmon: (applesmc) avoid overlong udelay()

[Brad Campbell]

On 5/11/20 1:18 pm, Brad Campbell wrote:

I'm not entirely sure where to go from here. I'd really like some wider testing 
before cleaning this up and submitting it. It puts extra checks & constraints 
on the comms with the SMC that weren't there previously.

I guess given there doesn't appear to have been a major outcry that the driver 
broke in 5.9 might indicate that nobody is using it, or that it only broke on 
certain machines?

Can we get some guidance from the hwmon maintainers on what direction they'd 
like to take? I don't really want to push this forward without broader testing 
only to find it breaks a whole heap of machines on the basis that it fixes mine.



I managed to find an iMac 12,2 to test with. Had to remove the check for bit 
0x40 (that machine sets bit 0x10). Updated patch with debugging code removed 
attached for comment.

Regards,
Brad
diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
index a18887990f4a..2e7dc820bb2e 100644
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -42,6 +42,16 @@
 
 #define APPLESMC_MAX_DATA_LENGTH 32
 
+/* Apple SMC status bits from VirtualSMC */
+#define SMC_STATUS_AWAITING_DATA  0x01  ///< Data waiting to be read
+#define SMC_STATUS_IB_CLOSED  0x02  /// A write is pending / will ignore 
input
+#define SMC_STATUS_BUSY   0x04  ///< Busy in the middle of a command.
+#define SMC_STATUS_GOT_COMMAND0x08  ///< The last input was a command.
+#define SMC_STATUS_UKN_0x16   0x10
+#define SMC_STATUS_KEY_DONE   0x20
+#define SMC_STATUS_READY  0x40  // Ready to work
+#define SMC_STATUS_UKN_0x80   0x80  // error
+
 /* wait up to 128 ms for a status change. */
 #define APPLESMC_MIN_WAIT  0x0010
 #define APPLESMC_RETRY_WAIT0x0100
@@ -151,65 +161,78 @@ static unsigned int key_at_index;
 static struct workqueue_struct *applesmc_led_wq;
 
 /*
- * wait_read - Wait for a byte to appear on SMC port. Callers must
- * hold applesmc_lock.
+ * Wait for specific status bits with a mask on the SMC
+ * Used before and after writes, and before reads
  */
-static int wait_read(void)
+
+static int wait_status(u8 val, u8 mask)
 {
unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
u8 status;
int us;
 
for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
-   usleep_range(us, us * 16);
status = inb(APPLESMC_CMD_PORT);
-   /* read: wait for smc to settle */
-   if (status & 0x01)
+   if ((status & mask) == val)
return 0;
/* timeout: give up */
if (time_after(jiffies, end))
break;
-   }
-
-   pr_warn("wait_read() fail: 0x%02x\n", status);
+   usleep_range(us, us * 16);
+   }
+   pr_warn("wait_status timeout: 0x%02x, 0x%02x, 0x%02x\n", status, val, 
mask);
return -EIO;
 }
 
 /*
- * send_byte - Write to SMC port, retrying when necessary. Callers
+ * send_byte_data - Write to SMC data port. Callers
  * must hold applesmc_lock.
+ * Parameter skip must be true on the last write of any
+ * command or it'll time out.
  */
-static int send_byte(u8 cmd, u16 port)
+
+static int send_byte_data(u8 cmd, u16 port, bool skip)
 {
-   u8 status;
-   int us;
-   unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
+   u8 wstat = SMC_STATUS_BUSY;
 
+   if (skip)
+   wstat = 0;
+   if (wait_status(SMC_STATUS_BUSY,
+   SMC_STATUS_BUSY | SMC_STATUS_IB_CLOSED))
+   goto fail;
outb(cmd, port);
-   for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
-   usleep_range(us, us * 16);
-   status = inb(APPLESMC_CMD_PORT);
-   /* write: wait for smc to settle */
-   if (status & 0x02)
-   continue;
-   /* ready: cmd accepted, return */
-   if (status & 0x04)
-   return 0;
-   /* timeout: give up */
-   if (time_after(jiffies, end))
-   break;
-   /* busy: long wait and resend */
-   udelay(APPLESMC_RETRY_WAIT);
-   outb(cmd, port);
-   }
-
-   pr_warn("send_byte(0x%02x, 0x%04x) fail: 0x%02x\n", cmd, port, status);
+   if (!wait_status(wstat,
+   SMC_STATUS_READY | SMC_STATUS_GOT_COMMAND | SMC_STATUS_BUSY | 
SMC_STATUS_IB_CLOSED))
+   return 0;
+fail:
+   pr_warn("send_byte_data(0x%02x, 0x%04x) fail\n", cmd, 
APPLESMC_CMD_PORT);
return -EIO;
 }
 
+/*
+ * send_command - Write a command to the SMC. Callers must hold applesmc_lock.
+ * If SMC is in undefined state, any new command write resets the state 
machine.
+ */
+
 static int send_command(u8 cmd)
 {
-   return send_byte(cmd, APPLESMC_

Re: [REGRESSION] hwmon: (applesmc) avoid overlong udelay()

[Brad Campbell]

On 5/11/20 12:20 am, Andreas Kemnade wrote:

On Tue, 3 Nov 2020 16:56:32 +1100
Brad Campbell  wrote:



If anyone with a Mac having a conventional SMC and seeing issues on 5.9 could test this it'd be 
appreciated. I'm not saying this code is "correct", but it "works for me".


Seems to work here.
  dmesg  | grep applesmc

[1.350782] applesmc: key=561 fan=1 temp=33 index=33 acc=0 lux=2 kbd=1
[1.350922] applesmc applesmc.768: hwmon_device_register() is deprecated. 
Please convert the driver to use hwmon_device_register_with_info().
[   17.748504] applesmc: wait_status looping 2: 0x4a, 0x4c, 0x4f
[  212.008952] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e
[  213.033930] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e
[  213.167908] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e
[  219.087854] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e

Tested it on top of 5.9


Much appreciated Andreas.

I'm not entirely sure where to go from here. I'd really like some wider testing 
before cleaning this up and submitting it. It puts extra checks & constraints 
on the comms with the SMC that weren't there previously.

I guess given there doesn't appear to have been a major outcry that the driver 
broke in 5.9 might indicate that nobody is using it, or that it only broke on 
certain machines?

Can we get some guidance from the hwmon maintainers on what direction they'd 
like to take? I don't really want to push this forward without broader testing 
only to find it breaks a whole heap of machines on the basis that it fixes mine.

Regards,
Brad

Re: [REGRESSION] hwmon: (applesmc) avoid overlong udelay()

[Brad Campbell]

On 3/11/20 10:56 am, Brad Campbell wrote:



I've examined the code in VirtualSMC and I'm not convinced we were not waiting 
on the wrong bits.

#define SMC_STATUS_AWAITING_DATA  BIT0  ///< Ready to read data.
#define SMC_STATUS_IB_CLOSED  BIT1  /// A write is pending.
#define SMC_STATUS_BUSY   BIT2  ///< Busy processing a command.
#define SMC_STATUS_GOT_COMMAND    BIT3  ///< The last input was a command.
#define SMC_STATUS_UKN_0x16   BIT4
#define SMC_STATUS_KEY_DONE   BIT5
#define SMC_STATUS_READY  BIT6  // Ready to work
#define SMC_STATUS_UKN_0x80   BIT7  // error

Any chance you could try this patch? It's ugly, hacked together and currently 
fairly undocumented, but if it works I'll figure out how to clean it up 
(suggestions welcome).
It works on my MacbookPro 11,1.


I had some time so I spent a bit of time refactoring and trying to clarify the 
magic numbers.

I also did some fuzzing of the SMC and figured out where we can loosen the 
masks.
This has some debug code in it to identify if any wait loops exceed 1 loop and if the SMC 
is reporting anything other than a clear "I'm waiting" prior to each command.

You might see some of these :
[   51.316202] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e
[   60.002547] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e
[   60.130754] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e

I did some heavy tests and found that with the delays at the bottom of the loop 
about 50% of calls required no delay at all before a read or write and the 
other 50% require a single delay.
I can count on one hand the number of times it's exceeded 1 loop, and the max 
thus far has been 5 loops.

We've been treating bit 0x04 as an ack, but from my testing on the machine and what I've seen in 
the SMC emulator code it actually means "I'm busy in the middle of a command". Bit 0x02 
seems to mean "I'm doing something and I *will* ignore anything you send me".
Bit 0x08 means "The last thing I got was a valid command, so start sending me 
data".

By testing and waiting for 0x02 to clear before sending or reading I haven't 
seen any need for retries.

On my unit bit 0x40 is always active. It may not be on others. The emulator 
calls it a status ready, so it's tested for but that is consolidated in 
wait_status so it can be commented out if it doesn't work on your machine.

The thing with bit 0x04 is the SMC clears it when it's no longer busy. So the last byte of data 
sent for a command sees it clear that bit. That explains the timeouts but the command still works. 
As far as the SMC is concerned it's got all the data and gone off to do its thing, but applesmc was 
waiting for the bit to be set. When it's in the middle of a command (from the first command byte 
until the last data byte is received) I've never seen bit 0x04 cleared, so using it as an 
"ack" works, but as said upward in the thread "probably by accident".

So this code tests for an "idle" SMC before it sends a command. In this context 
idle just means bit 0x02 isn't set. If the SMC gets into an undefined state it can leave 
other bits set, but a new write with a valid command will reset the internal state 
machine and bring it back into line. Bit 0x08 should always be set after it has received 
a valid command.

I've gone belt and braces by checking the status before and after each command, 
but with the intention of trying to catch and log anything that goes awry. Like 
I said above, in 50% of cases I see zero delays required so I thought testing 
before the delay was a worthwhile win.

If anyone with a Mac having a conventional SMC and seeing issues on 5.9 could test this it'd be 
appreciated. I'm not saying this code is "correct", but it "works for me".

If anyone actually knows what they're doing and wants to "correct" me, it'd be 
appreciated also.

Regards,
Brad
diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
index a18887990f4a..abb06fbe7bc1 100644
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -42,6 +42,16 @@
 
 #define APPLESMC_MAX_DATA_LENGTH 32
 
+/* Apple SMC status bits */
+#define SMC_STATUS_AWAITING_DATA  0x01  ///< Data waiting to be read
+#define SMC_STATUS_IB_CLOSED  0x02  /// A write is pending / will ignore 
input
+#define SMC_STATUS_BUSY   0x04  ///< Busy in the middle of a command.
+#define SMC_STATUS_GOT_COMMAND0x08  ///< The last input was a command.
+#define SMC_STATUS_UKN_0x16   0x10
+#define SMC_STATUS_KEY_DONE   0x20
+#define SMC_STATUS_READY  0x40  // Ready to work
+#define SMC_STATUS_UKN_0x80   0x80  // error
+
 /* wait up to 128 ms for a status change. */
 #define APPLESMC_MIN_WAIT  0x0010
 #define APPLESMC_RETRY_WAIT0x0100
@@ -151,65 +161,88 @@ static unsigned int key_at_index;
 static struct workqueue_struct *applesmc_led_wq;
 
 /*
- * wait_read - Wai

Re: [REGRESSION] hwmon: (applesmc) avoid overlong udelay()

[Brad Campbell]

On 6/10/20 6:02 pm, Andreas Kemnade wrote:

On Thu, 1 Oct 2020 21:07:51 -0700
Guenter Roeck  wrote:


On 10/1/20 3:22 PM, Andreas Kemnade wrote:

On Wed, 30 Sep 2020 22:00:09 +0200
Arnd Bergmann  wrote:
   

On Wed, Sep 30, 2020 at 6:44 PM Guenter Roeck  wrote:


On Wed, Sep 30, 2020 at 10:54:42AM +0200, Andreas Kemnade wrote:

Hi,

after the $subject patch I get lots of errors like this:


For reference, this refers to commit fff2d0f701e6 ("hwmon: (applesmc)
avoid overlong udelay()").


[  120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40
[  120.378621] applesmc: LKSB: write data fail
[  120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40
[  120.512787] applesmc: LKSB: write data fail

CPU sticks at low speed and no fan is turning on.
Reverting this patch on top of 5.9-rc6 solves this problem.

Some information from dmidecode:

Base Board Information
 Manufacturer: Apple Inc.
 Product Name: Mac-7DF21CB3ED6977E5
 Version: MacBookAir6,2

Handle 0x0020, DMI type 11, 5 bytes OEM Strings String 1: Apple ROM 
Version.  Model:   …,
Handle 0x0020, DMI type 11, 5 bytes
OEM Strings
 String 1: Apple ROM Version.  Model:MBA61.  EFI Version:  
122.0.0
 String 2: .0.0.  Built by: root@saumon.  Date: Wed Jun 10 
18:
 String 3: 10:36 PDT 2020.  Revision: 122 (B).  ROM Version:  
F000_B
 String 4: 00.  Build Type:   Official Build, Release.  Compiler: 
Appl
 String 5: e clang version 3.0 (tags/Apple/clang-211.10.1) (based on 
LLVM
 String 6: 3.0svn).

Writing to things in /sys/devices/platform/applesmc.768 gives also the
said errors.
But writing 1 to fan1_maunal and 5000 to fan1_output turns the fan on
despite error messages.


Not really sure what to do here. I could revert the patch, but then we'd gain
clang compile failures. Arnd, any idea ?


It seems that either I made a mistake in the conversion and it sleeps for
less time than before, or my assumption was wrong that converting a delay to
a sleep is safe here.

The error message indicates that the write fails, not the read, so that
is what I'd look at first. Right away I can see that the maximum time to
retry is only half of what it used to be, as we used to wait for
0x10, 0x20, 0x40, 0x80, ..., 0x2 microseconds for a total of
0x3fff0 microseconds (262ms), while my patch went with the 131ms
total delay based on the comment saying "/* wait up to 128 ms for a
status change. */".
  

Yes, that is also what I read from the code. I just thought there must
be something simple, which just needs a short look from another pair of
eyes.
   

Since there is sleeping wait, I see no reason the timeout couldn't
be extended a lot, e.g. to a second, as in

#define APPLESMC_MAX_WAIT 0x10

If that doesn't work, I'd try using mdelay() in place of
usleep_range(), such as

mdelay(DIV_ROUND_UP(us, USEC_PER_MSEC)));

This adds back a really nasty latency, but it should avoid the
compile-time problem.

Andreas, can you try those two things? (one at a time,
not both)


Ok, I tried. None of them works. I rechecked my work and created real
git commits out of them and CONFIG_LOCALVERSION_AUTO is also set so
the usual stupid things are rules out.
In detail:
On top of 5.9-rc6 + *reverted* patch:
diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
index fd99c9df8a00..2a9bd7f2b71b 100644
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -45,7 +45,7 @@
  /* wait up to 128 ms for a status change. */
  #define APPLESMC_MIN_WAIT 0x0010
  #define APPLESMC_RETRY_WAIT   0x0100
-#define APPLESMC_MAX_WAIT  0x2
+#define APPLESMC_MAX_WAIT  0x8000
  
  #define APPLESMC_READ_CMD	0x10

  #define APPLESMC_WRITE_CMD0x11
   


Oh man, that code is so badlys broken.

send_byte() repeats sending the data if it was not immediately successful.
That is done for both data and commands. Effectively that happens if
the command is not immediately accepted. However, send_argument()
clearly assumes that each data byte is sent exactly once. Sending
it more than once will mess up the key that is supposed to be sent.
The Apple SMC emulation code in qemu confirms that data bytes can not
be written more than once.

Of course, theoretically it may be that the first data byte was not
accepted (after all, the ACK bit is not set), but the ACK bit is
not checked again after udelay(APPLESMC_RETRY_WAIT), so it may
well have been set in the 256 uS between its check and re-writing
the data.

In other words, this entire code only works accidentally to start with.

If you like, you could play around with the code and find out if and
when exactly bit 1 (busy) is set, if and when bit 2 (ack) is set, and
if and when any other bit is set. We could also try to read port 0x31e
(the error port). Maybe the we can figure out what the error actually
is. But then I don't really know what we could do with that information.


Smoe research results: the 

Re: [PATCH] x86/cpu: Reinitialize IA32_FEAT_CTL MSR on BSP during wakeup

[Brad Campbell]

G'day Sean,

With the addition of this patch on a vanilla v5.7 :
Tested-by: Brad Campbell 

On 8/6/20 12:34 am, Sean Christopherson wrote:

On Sat, Jun 06, 2020 at 05:08:38AM +0800, kernel test robot wrote:
  arch/x86/kernel/cpu/centaur.c: In function 'init_centaur':

arch/x86/kernel/cpu/centaur.c:219:2: error: implicit declaration of function 
'init_ia32_feat_ctl' [-Werror=implicit-function-declaration]

219 |  init_ia32_feat_ctl(c);
|  ^~
cc1: some warnings being treated as errors
--
arch/x86/kernel/cpu/zhaoxin.c: In function 'init_zhaoxin':

arch/x86/kernel/cpu/zhaoxin.c:110:2: error: implicit declaration of function 
'init_ia32_feat_ctl' [-Werror=implicit-function-declaration]

110 |  init_ia32_feat_ctl(c);
|  ^~
cc1: some warnings being treated as errors


Blech, zhaoxin.c an centaur.c don't include asm/cpu.h, and I (obviously)
don't have them enabled in my configs.  I'll wait a day or two more before
sending v2.
diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index 426792565d86..c5cf336e5077 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -3,6 +3,7 @@
  #include 
  #include 

+#include 
  #include 
  #include 
  #include 
diff --git a/arch/x86/kernel/cpu/zhaoxin.c b/arch/x86/kernel/cpu/zhaoxin.c
index df1358ba622b..05fa4ef63490 100644
--- a/arch/x86/kernel/cpu/zhaoxin.c
+++ b/arch/x86/kernel/cpu/zhaoxin.c
@@ -2,6 +2,7 @@
  #include 
  #include 

+#include 
  #include 

  #include "cpu.h"

Re: KVM broken after suspend in most recent kernels.

[Brad Campbell]

On 25/5/20 7:46 pm, Maxim Levitsky wrote:

On Sun, 2020-05-24 at 18:43 +0800, Brad Campbell wrote:


On 24/5/20 12:50 pm, Brad Campbell wrote:

G'day all.

Machine is a Macbook Pro Retina ~ 2014. Kernels are always vanilla kernel and 
compiled on the machine. No additional patches.

vendor_id: GenuineIntel
cpu family: 6
model: 69
model name: Intel(R) Core(TM) i5-4278U CPU @ 2.60GHz
stepping: 1
microcode: 0x25
cpu MHz: 2795.034
cache size: 3072 KB
physical id: 0
siblings: 4
core id: 1
cpu cores: 2
apicid: 3
initial apicid: 3
fpu: yes
fpu_exception: yes
cpuid level: 13
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 
ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm cpuid_fault epb 
invpcid_single ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid 
ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida 
arat pln pts md_clear flush_l1d
vmx flags: vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb 
flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple
bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds 
swapgs itlb_multihit
bogomips: 5199.87
clflush size: 64
cache_alignment: 64
address sizes: 39 bits physical, 48 bits virtual


KVM worked fine in kernels somewhere prior to 5.4-5.5.

KVM works fine in later kernels up to and including 5.7.0-rc6 after a clean 
boot. It does not work after a suspend.

I can't actually bisect this because there is a bug in earlier kernels that 
breaks the suspend method used which requires manual patching to work around.

This is using qemu version 5.0.0, but also happens with 4.2.0.

In kernels earlier than 5.7 it results in either an immediate hard lock, or a 
GPF that results in progressive system freeze until a hard reboot is required 
(won't flush to disk so no logs get recorded and I have no serial or netconsole 
ability). In 5.7-rc6 it results in the following trace and thankfully no 
further issues (so I can get the logs and report it).

I can and will perform any required testing and debugging, but this machine 
suspends with pm-utils s2both, and that is broken between about 5.4 & 5.6 due 
to swapfile locking issues, which makes actual bisection very, very difficult as it 
*requires* a suspend/resume to trigger the bug.

[  227.715173] [ cut here ]
[  227.715176] VMXON faulted, MSR_IA32_FEAT_CTL (0x3a) = 0x4
[  227.715194] WARNING: CPU: 0 PID: 5502 at arch/x86/kvm/vmx/vmx.c:2239 
hardware_enable+0x167/0x180 [kvm_intel]
[  227.715195] Modules linked in: brcmfmac xhci_pci xhci_hcd cmac bnep 
iptable_nat xt_MASQUERADE nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables 
nfsd bridge stp llc appletouch brcmutil snd_hda_codec_hdmi sha256_ssse3 
snd_hda_codec_cirrus snd_hda_codec_generic sha256_generic libsha256 
x86_pkg_temp_thermal coretemp btusb kvm_intel btrtl kvm btbcm btintel irqbypass 
bluetooth cfg80211 snd_hda_intel ecdh_generic ecc snd_intel_dspcfg bcm5974 
rfkill snd_hda_codec snd_hwdep snd_hda_core snd_pcm_oss snd_pcm snd_seq_midi 
snd_seq_midi_event snd_rawmidi i915 snd_seq snd_seq_device snd_timer 
i2c_algo_bit iosf_mbi drm_kms_helper syscopyarea sysfillrect sysimgblt 
fb_sys_fops snd drm intel_gtt agpgart evdev apple_bl video soundcore hid_apple 
usb_storage hid_generic usbhid hid dm_crypt dm_mod i2c_i801 i2c_core sg usbcore 
usb_common [last unloaded: xhci_hcd]
[  227.715221] CPU: 0 PID: 5502 Comm: qemu Not tainted 5.7.0-rc6+ #15
[  227.715222] Hardware name: Apple Inc. MacBookPro11,1/Mac-189A3D4F975D5FFC, 
BIOS 159.0.0.0.0 02/05/2020
[  227.715225] RIP: 0010:hardware_enable+0x167/0x180 [kvm_intel]
[  227.715227] Code: 01 00 01 b9 3a 00 00 00 0f 32 31 c9 48 c1 e2 20 be ef be ad de 
48 c7 c7 68 fd bb c0 48 09 c2 85 c9 48 0f 44 f2 e8 43 78 4f dc <0f> 0b eb 8a 48 
8b 15 ce 89 06 dd e9 c7 fe ff ff 66 0f 1f 84 00 00
[  227.715228] RSP: 0018:97091d873df8 EFLAGS: 00010092
[  227.715229] RAX: 002d RBX: 0046 RCX: 0007
[  227.715230] RDX: 0007 RSI: 0082 RDI: 97091f2187a0
[  227.715231] RBP: 97091d873e10 R08: 0008 R09: 0495
[  227.715232] R10: 0010 R11: 97091d873c6d R12: 
[  227.715233] R13: 0286 R14: b5d08015e010 R15: 
[  227.715234] FS:  7f1468fd33c0() GS:97091f20() 
knlGS:
[  227.715235] CS:  0010 DS:  ES:  CR0: 80050033
[  227.715236] CR2: 563b54c7201d CR3: 00043f43f001 CR4: 00

Re: KVM broken after suspend in most recent kernels.

[Brad Campbell]

On 24/5/20 12:50 pm, Brad Campbell wrote:

G'day all.

Machine is a Macbook Pro Retina ~ 2014. Kernels are always vanilla kernel and 
compiled on the machine. No additional patches.

vendor_id    : GenuineIntel
cpu family    : 6
model    : 69
model name    : Intel(R) Core(TM) i5-4278U CPU @ 2.60GHz
stepping    : 1
microcode    : 0x25
cpu MHz    : 2795.034
cache size    : 3072 KB
physical id    : 0
siblings    : 4
core id    : 1
cpu cores    : 2
apicid    : 3
initial apicid    : 3
fpu    : yes
fpu_exception    : yes
cpuid level    : 13
wp    : yes
flags    : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 
ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm cpuid_fault epb 
invpcid_single ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid 
ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida 
arat pln pts md_clear flush_l1d
vmx flags    : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb 
flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple
bugs    : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds 
swapgs itlb_multihit
bogomips    : 5199.87
clflush size    : 64
cache_alignment    : 64
address sizes    : 39 bits physical, 48 bits virtual


KVM worked fine in kernels somewhere prior to 5.4-5.5.

KVM works fine in later kernels up to and including 5.7.0-rc6 after a clean 
boot. It does not work after a suspend.

I can't actually bisect this because there is a bug in earlier kernels that 
breaks the suspend method used which requires manual patching to work around.

This is using qemu version 5.0.0, but also happens with 4.2.0.

In kernels earlier than 5.7 it results in either an immediate hard lock, or a 
GPF that results in progressive system freeze until a hard reboot is required 
(won't flush to disk so no logs get recorded and I have no serial or netconsole 
ability). In 5.7-rc6 it results in the following trace and thankfully no 
further issues (so I can get the logs and report it).

I can and will perform any required testing and debugging, but this machine 
suspends with pm-utils s2both, and that is broken between about 5.4 & 5.6 due 
to swapfile locking issues, which makes actual bisection very, very difficult as it 
*requires* a suspend/resume to trigger the bug.

[  227.715173] [ cut here ]
[  227.715176] VMXON faulted, MSR_IA32_FEAT_CTL (0x3a) = 0x4
[  227.715194] WARNING: CPU: 0 PID: 5502 at arch/x86/kvm/vmx/vmx.c:2239 
hardware_enable+0x167/0x180 [kvm_intel]
[  227.715195] Modules linked in: brcmfmac xhci_pci xhci_hcd cmac bnep 
iptable_nat xt_MASQUERADE nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables 
nfsd bridge stp llc appletouch brcmutil snd_hda_codec_hdmi sha256_ssse3 
snd_hda_codec_cirrus snd_hda_codec_generic sha256_generic libsha256 
x86_pkg_temp_thermal coretemp btusb kvm_intel btrtl kvm btbcm btintel irqbypass 
bluetooth cfg80211 snd_hda_intel ecdh_generic ecc snd_intel_dspcfg bcm5974 
rfkill snd_hda_codec snd_hwdep snd_hda_core snd_pcm_oss snd_pcm snd_seq_midi 
snd_seq_midi_event snd_rawmidi i915 snd_seq snd_seq_device snd_timer 
i2c_algo_bit iosf_mbi drm_kms_helper syscopyarea sysfillrect sysimgblt 
fb_sys_fops snd drm intel_gtt agpgart evdev apple_bl video soundcore hid_apple 
usb_storage hid_generic usbhid hid dm_crypt dm_mod i2c_i801 i2c_core sg usbcore 
usb_common [last unloaded: xhci_hcd]
[  227.715221] CPU: 0 PID: 5502 Comm: qemu Not tainted 5.7.0-rc6+ #15
[  227.715222] Hardware name: Apple Inc. MacBookPro11,1/Mac-189A3D4F975D5FFC, 
BIOS 159.0.0.0.0 02/05/2020
[  227.715225] RIP: 0010:hardware_enable+0x167/0x180 [kvm_intel]
[  227.715227] Code: 01 00 01 b9 3a 00 00 00 0f 32 31 c9 48 c1 e2 20 be ef be ad de 
48 c7 c7 68 fd bb c0 48 09 c2 85 c9 48 0f 44 f2 e8 43 78 4f dc <0f> 0b eb 8a 48 
8b 15 ce 89 06 dd e9 c7 fe ff ff 66 0f 1f 84 00 00
[  227.715228] RSP: 0018:97091d873df8 EFLAGS: 00010092
[  227.715229] RAX: 002d RBX: 0046 RCX: 0007
[  227.715230] RDX: 0007 RSI: 0082 RDI: 97091f2187a0
[  227.715231] RBP: 97091d873e10 R08: 0008 R09: 0495
[  227.715232] R10: 0010 R11: 97091d873c6d R12: 
[  227.715233] R13: 0286 R14: b5d08015e010 R15: 
[  227.715234] FS:  7f1468fd33c0() GS:97091f20() 
knlGS:
[  227.715235] CS:  0010 DS:  ES:  CR0: 80050033
[  227.715236] CR2: 563b54c7201d CR3: 00043f43f001 CR4: 001626f0
[  227.715237] DR0:  DR1:  DR2: 
[  227.7

KVM broken after suspend in most recent kernels.

[Brad Campbell]

G'day all.

Machine is a Macbook Pro Retina ~ 2014. Kernels are always vanilla kernel and 
compiled on the machine. No additional patches.

vendor_id   : GenuineIntel
cpu family  : 6
model   : 69
model name  : Intel(R) Core(TM) i5-4278U CPU @ 2.60GHz
stepping: 1
microcode   : 0x25
cpu MHz : 2795.034
cache size  : 3072 KB
physical id : 0
siblings: 4
core id : 1
cpu cores   : 2
apicid  : 3
initial apicid  : 3
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 
ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm cpuid_fault epb 
invpcid_single ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid 
ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida 
arat pln pts md_clear flush_l1d
vmx flags   : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb 
flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple
bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds 
swapgs itlb_multihit
bogomips: 5199.87
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual


KVM worked fine in kernels somewhere prior to 5.4-5.5.

KVM works fine in later kernels up to and including 5.7.0-rc6 after a clean 
boot. It does not work after a suspend.

I can't actually bisect this because there is a bug in earlier kernels that 
breaks the suspend method used which requires manual patching to work around.

This is using qemu version 5.0.0, but also happens with 4.2.0.

In kernels earlier than 5.7 it results in either an immediate hard lock, or a 
GPF that results in progressive system freeze until a hard reboot is required 
(won't flush to disk so no logs get recorded and I have no serial or netconsole 
ability). In 5.7-rc6 it results in the following trace and thankfully no 
further issues (so I can get the logs and report it).

I can and will perform any required testing and debugging, but this machine 
suspends with pm-utils s2both, and that is broken between about 5.4 & 5.6 due 
to swapfile locking issues, which makes actual bisection very, very difficult as it 
*requires* a suspend/resume to trigger the bug.

[  227.715173] [ cut here ]
[  227.715176] VMXON faulted, MSR_IA32_FEAT_CTL (0x3a) = 0x4
[  227.715194] WARNING: CPU: 0 PID: 5502 at arch/x86/kvm/vmx/vmx.c:2239 
hardware_enable+0x167/0x180 [kvm_intel]
[  227.715195] Modules linked in: brcmfmac xhci_pci xhci_hcd cmac bnep 
iptable_nat xt_MASQUERADE nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables 
nfsd bridge stp llc appletouch brcmutil snd_hda_codec_hdmi sha256_ssse3 
snd_hda_codec_cirrus snd_hda_codec_generic sha256_generic libsha256 
x86_pkg_temp_thermal coretemp btusb kvm_intel btrtl kvm btbcm btintel irqbypass 
bluetooth cfg80211 snd_hda_intel ecdh_generic ecc snd_intel_dspcfg bcm5974 
rfkill snd_hda_codec snd_hwdep snd_hda_core snd_pcm_oss snd_pcm snd_seq_midi 
snd_seq_midi_event snd_rawmidi i915 snd_seq snd_seq_device snd_timer 
i2c_algo_bit iosf_mbi drm_kms_helper syscopyarea sysfillrect sysimgblt 
fb_sys_fops snd drm intel_gtt agpgart evdev apple_bl video soundcore hid_apple 
usb_storage hid_generic usbhid hid dm_crypt dm_mod i2c_i801 i2c_core sg usbcore 
usb_common [last unloaded: xhci_hcd]
[  227.715221] CPU: 0 PID: 5502 Comm: qemu Not tainted 5.7.0-rc6+ #15
[  227.715222] Hardware name: Apple Inc. MacBookPro11,1/Mac-189A3D4F975D5FFC, 
BIOS 159.0.0.0.0 02/05/2020
[  227.715225] RIP: 0010:hardware_enable+0x167/0x180 [kvm_intel]
[  227.715227] Code: 01 00 01 b9 3a 00 00 00 0f 32 31 c9 48 c1 e2 20 be ef be ad de 
48 c7 c7 68 fd bb c0 48 09 c2 85 c9 48 0f 44 f2 e8 43 78 4f dc <0f> 0b eb 8a 48 
8b 15 ce 89 06 dd e9 c7 fe ff ff 66 0f 1f 84 00 00
[  227.715228] RSP: 0018:97091d873df8 EFLAGS: 00010092
[  227.715229] RAX: 002d RBX: 0046 RCX: 0007
[  227.715230] RDX: 0007 RSI: 0082 RDI: 97091f2187a0
[  227.715231] RBP: 97091d873e10 R08: 0008 R09: 0495
[  227.715232] R10: 0010 R11: 97091d873c6d R12: 
[  227.715233] R13: 0286 R14: b5d08015e010 R15: 
[  227.715234] FS:  7f1468fd33c0() GS:97091f20() 
knlGS:
[  227.715235] CS:  0010 DS:  ES:  CR0: 80050033
[  227.715236] CR2: 563b54c7201d CR3: 00043f43f001 CR4: 001626f0
[  227.715237] DR0:  DR1:  DR2: 
[  227.715238] DR3: 

Re: [PATCH 1/3] thunderbolt: Read DP IN adapter first two dwords in one go

[Brad Campbell]

On 1/10/19 6:29 pm, Mika Westerberg wrote:

When we discover existing DP tunnels the code checks whether DP IN
adapter port is enabled by calling tb_dp_port_is_enabled() before it
continues the discovery process. On Light Ridge (gen 1) controller
reading only the first dword of the DP IN config space causes subsequent
access to the same DP IN port path config space to fail or return
invalid data as can be seen in the below splat:

   thunderbolt :07:00.0: CFG_ERROR(0:d): Invalid config space or offset
   Call Trace:
tb_cfg_read+0xb9/0xd0
__tb_path_deactivate_hop+0x98/0x210
tb_path_activate+0x228/0x7d0
tb_tunnel_restart+0x95/0x200
tb_handle_hotplug+0x30e/0x630
process_one_work+0x1b4/0x340
worker_thread+0x44/0x3d0
kthread+0xeb/0x120
? process_one_work+0x340/0x340
? kthread_park+0xa0/0xa0
ret_from_fork+0x1f/0x30

If both DP In adapter config dwords are read in one go the issue does
not reproduce. This is likely firmware bug but we can work it around by
always reading the two dwords in one go. There should be no harm for
other controllers either so can do it unconditionally.

Link: https://lkml.org/lkml/2019/8/28/160
Reported-by: Brad Campbell 


Tested-by: Brad Campbell 


Signed-off-by: Mika Westerberg 
---
  drivers/thunderbolt/switch.c | 19 +++
  1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index 410bf1bc..8e712fbf8233 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -896,12 +896,13 @@ int tb_dp_port_set_hops(struct tb_port *port, unsigned 
int video,
   */
  bool tb_dp_port_is_enabled(struct tb_port *port)
  {
-   u32 data;
+   u32 data[2];
  
-	if (tb_port_read(port, , TB_CFG_PORT, port->cap_adap, 1))

+   if (tb_port_read(port, data, TB_CFG_PORT, port->cap_adap,
+ARRAY_SIZE(data)))
return false;
  
-	return !!(data & (TB_DP_VIDEO_EN | TB_DP_AUX_EN));

+   return !!(data[0] & (TB_DP_VIDEO_EN | TB_DP_AUX_EN));
  }
  
  /**

@@ -914,19 +915,21 @@ bool tb_dp_port_is_enabled(struct tb_port *port)
   */
  int tb_dp_port_enable(struct tb_port *port, bool enable)
  {
-   u32 data;
+   u32 data[2];
int ret;
  
-	ret = tb_port_read(port, , TB_CFG_PORT, port->cap_adap, 1);

+   ret = tb_port_read(port, data, TB_CFG_PORT, port->cap_adap,
+  ARRAY_SIZE(data));
if (ret)
return ret;
  
  	if (enable)

-   data |= TB_DP_VIDEO_EN | TB_DP_AUX_EN;
+   data[0] |= TB_DP_VIDEO_EN | TB_DP_AUX_EN;
else
-   data &= ~(TB_DP_VIDEO_EN | TB_DP_AUX_EN);
+   data[0] &= ~(TB_DP_VIDEO_EN | TB_DP_AUX_EN);
  
-	return tb_port_write(port, , TB_CFG_PORT, port->cap_adap, 1);

+   return tb_port_write(port, data, TB_CFG_PORT, port->cap_adap,
+ARRAY_SIZE(data));
  }
  
  /* switch utility functions */

Re: Thunderbolt DP oddity on v5.2.9 on iMac 12,2

[Brad Campbell]

On 28/8/19 21:19, Mika Westerberg wrote:

On Wed, Aug 28, 2019 at 06:43:35PM +0800, Brad Campbell wrote:

On 28/8/19 6:23 pm, Mika Westerberg wrote:


On Wed, Aug 28, 2019 at 05:12:00PM +0800, Brad Campbell wrote:

Apart from the warning in the log (which is not fatal, I'll look into
it) to me the second path setup looks fine.

Can you do one more experiment? Boot the system up without anything
connected and then plug both monitors. Does it work?


Aside from head ordering issues in X it works just fine.
I've attached the dmesg. Boot with nothing plugged in, then plug in 0-1 and
0-3 in that order.

OK, thanks for checking. So when Linux is in complete control both DP
tunnels get created properly. I suspect there is something different
what the firmware does compared to other Macs I've been using and that
causes the driver to fail to discover all the paths. I will take a look
at this but I'm away tomorrow and friday so it goes to next week.


It wouldn't surprise me if the firmware was doing something funky. It 
was one of the first Thunderbolt equipped models and the support docs 
explicitly say only one Thunderbolt display in Windows and two in later 
versions of OSX. It almost needs a quirk to say "firmware does something 
we don't like, reset the controller and re-discover from scratch".


Anyway, I'm not in any hurry. It doesn't get rebooted often and it's not 
in any way preventing me using the machine. In fact, upgrading the third 
head from an old 24" 1920x1200 to the second Thunderbolt display has 
been invaluable.



BTW, have you tried to chain the two monitors?


Not yet, but it was something I've been considering. I'll give it a go 
tomorrow. Due to cable length vs display dimensions it'll require me 
cleaning my desk, and that takes some forward planning.


--

An expert is a person who has found out by his own painful
experience all the mistakes that one can make in a very
narrow field. - Niels Bohr

Re: Thunderbolt DP oddity on v5.2.9 on iMac 12,2

[Brad Campbell]

On 28/8/19 6:23 pm, Mika Westerberg wrote:


On Wed, Aug 28, 2019 at 05:12:00PM +0800, Brad Campbell wrote:

Apart from the warning in the log (which is not fatal, I'll look into
it) to me the second path setup looks fine.

Can you do one more experiment? Boot the system up without anything
connected and then plug both monitors. Does it work?



Aside from head ordering issues in X it works just fine.
I've attached the dmesg. Boot with nothing plugged in, then plug in 0-1 
and 0-3 in that order.


Regards,
Brad
[0.00] Linux version 5.2.9 (brad@bkmac) (gcc version 6.3.0 20170516 
(Debian 6.3.0-18+deb9u1)) #6 SMP Wed Aug 28 16:51:39 AWST 2019
[0.00] Command line: \\boot\vmlinuz-5.2.9.efi ro 
root=UUID=de35d1a6-e0e1-40b0-b46a-3974a04adf4b libata.allow_tpm=1 
initrd=boot\initrd.img-5.2.9
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0008dfff] usable
[0.00] BIOS-e820: [mem 0x0008e000-0x0008] reserved
[0.00] BIOS-e820: [mem 0x0009-0x0009] usable
[0.00] BIOS-e820: [mem 0x000a-0x000b] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1fff] usable
[0.00] BIOS-e820: [mem 0x2000-0x201f] reserved
[0.00] BIOS-e820: [mem 0x2020-0x3fff] usable
[0.00] BIOS-e820: [mem 0x4000-0x401f] reserved
[0.00] BIOS-e820: [mem 0x4020-0x8ed32fff] usable
[0.00] BIOS-e820: [mem 0x8ed33000-0x8ed5efff] ACPI NVS
[0.00] BIOS-e820: [mem 0x8ed5f000-0x8ed70fff] usable
[0.00] BIOS-e820: [mem 0x8ed71000-0x8ed8efff] ACPI data
[0.00] BIOS-e820: [mem 0x8ed8f000-0x8ee5afff] usable
[0.00] BIOS-e820: [mem 0x8ee5b000-0x8ee8efff] reserved
[0.00] BIOS-e820: [mem 0x8ee8f000-0x8eed6fff] usable
[0.00] BIOS-e820: [mem 0x8eed7000-0x8eefefff] reserved
[0.00] BIOS-e820: [mem 0x8eeff000-0x8efa2fff] usable
[0.00] BIOS-e820: [mem 0x8efa3000-0x8f8f] reserved
[0.00] BIOS-e820: [mem 0xe00f8000-0xe00f8fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xffed8000-0xffef] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00046fef] usable
[0.00] NX (Execute Disable) protection: active
[0.00] e820: update [mem 0x8977c018-0x89796e57] usable ==> usable
[0.00] e820: update [mem 0x8977c018-0x89796e57] usable ==> usable
[0.00] e820: update [mem 0x8986b018-0x8987c33f] usable ==> usable
[0.00] e820: update [mem 0x8986b018-0x8987c33f] usable ==> usable
[0.00] extended physical RAM map:
[0.00] reserve setup_data: [mem 0x-0x0008dfff] 
usable
[0.00] reserve setup_data: [mem 0x0008e000-0x0008] 
reserved
[0.00] reserve setup_data: [mem 0x0009-0x0009] 
usable
[0.00] reserve setup_data: [mem 0x000a-0x000b] 
reserved
[0.00] reserve setup_data: [mem 0x0010-0x1fff] 
usable
[0.00] reserve setup_data: [mem 0x2000-0x201f] 
reserved
[0.00] reserve setup_data: [mem 0x2020-0x3fff] 
usable
[0.00] reserve setup_data: [mem 0x4000-0x401f] 
reserved
[0.00] reserve setup_data: [mem 0x4020-0x8977c017] 
usable
[0.00] reserve setup_data: [mem 0x8977c018-0x89796e57] 
usable
[0.00] reserve setup_data: [mem 0x89796e58-0x8986b017] 
usable
[0.00] reserve setup_data: [mem 0x8986b018-0x8987c33f] 
usable
[0.00] reserve setup_data: [mem 0x8987c340-0x8ed32fff] 
usable
[0.00] reserve setup_data: [mem 0x8ed33000-0x8ed5efff] 
ACPI NVS
[0.00] reserve setup_data: [mem 0x8ed5f000-0x8ed70fff] 
usable
[0.00] reserve setup_data: [mem 0x8ed71000-0x8ed8efff] 
ACPI data
[0.00] reserve setup_data: [mem 0x8ed8f000-0x8ee5afff] 
usable
[0.00] reserve setup_data: [mem 0x8ee5b000-0x8ee8efff] 
reserved
[0.00] reserv

Re: Thunderbolt DP oddity on v5.2.9 on iMac 12,2

[Brad Campbell]

On 28/8/19 5:12 pm, Brad Campbell wrote:

On 28/8/19 3:33 pm, Mika Westerberg wrote:



I'm suspecting that the boot firmware does configure second DP path also
and we either fail to discover it properly or the boot firmware fails to
set it up.

Also if you boot with one monitor connected and then connect another
(when the system is up) does it work then?


Umm.. so this is where it gets weird. No it doesn't. Apparently it fails 
to configure the first monitor it finds. This is the one the Apple 
bootcamp firmware configures at boot.




Ok just to clarify it appears I've been booting EFI and bypassing the 
Bootcamp BIOS emulation for a few years. So, that made no difference.

Re: 4.11.0-rc5-00011-g08e4e0d oops in mpt3sas driver

[Brad Campbell]

On 06/04/17 08:30, Brad Campbell wrote:

G'day All,

This is a vaguely current git head kernel compiled yesterday.

Oopsed and rebooted itself, and then oopsed and rebooted again. There
was no sign of a raid rebuild in the kernel logs, and it's a staging
machine so there is nothing running after a reboot that goes near these
disks. They should have been completely idle the second time around.

This box suffered from bad rcu stalls on 4.10.x stable kernels, so I
upgraded to git head. It's all new hardware (the CPU, Chipset and
board), so I expected some issues with the board, but the LSI cards have
been around for a while now.


Further investigation indicates it might be a deeper problem. This is 
the first oops captured and it has nothing to do with the mpt3 driver.


[49580.533852] BUG: unable to handle kernel paging request at 
817cddfe

[49580.533875] IP: queued_spin_lock_slowpath+0xe7/0x170
[49580.533879] PGD 180a067
[49580.533879] PUD 180b063
[49580.533882] PMD 816001e1
[49580.533885]
[49580.533890] Oops: 0003 [#1] SMP
[49580.533894] Modules linked in: it87(O) deflate zlib_deflate ctr 
des_generic cbc cmac sha1_generic md5 hmac af_key xfrm_algo nfsd 
auth_rpcgss oid_registry nfs_acl nfs lockd grace sunrpc bonding 
sha256_generic dm_crypt aesni_intel aes_x86_64 crypto_simd cryptd 
glue_helper hwmon_vid netconsole configfs vhost_net vhost kvm_amd kvm 
irqbypass usbhid usb_storage nouveau video drm_kms_helper cfbfillrect 
syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea ttm 
drm mxm_wmi xhci_pci i2c_piix4 xhci_hcd usbcore usb_common wmi 
acpi_cpufreq mpt3sas igb i2c_algo_bit raid_class scsi_transport_sas ahci 
libahci
[49580.533929] CPU: 6 PID: 114 Comm: kswapd0 Tainted: G   O 
4.11.0-rc5-00011-g08e4e0d-dirty #39
[49580.533933] Hardware name: System manufacturer System Product 
Name/PRIME X370-PRO, BIOS 0515 03/30/2017

[49580.534045] task: 8807f9ad task.stack: c943
[49580.534049] RIP: 0010:queued_spin_lock_slowpath+0xe7/0x170
[49580.534052] RSP: 0018:c9433a50 EFLAGS: 00010082
[49580.534056] RAX: 34e1 RBX: 0292 RCX: 
001c
[49580.534059] RDX: 817cddfe RSI: 88081ed99900 RDI: 
8806ddb860e0
[49580.534063] RBP: 8806ddb860e0 R08: 0101 R09: 
dead0200
[49580.534119] R10: ea001c000700 R11: 880006b457b9 R12: 
8806ddb860c8
[49580.534122] R13: 0001 R14: c9433b40 R15: 
8806ddb860c8
[49580.534179] FS:  () GS:88081ed8() 
knlGS:

[49580.534183] CS:  0010 DS:  ES:  CR0: 80050033
[49580.534186] CR2: 817cddfe CR3: 01809000 CR4: 
003406e0

[49580.534190] Call Trace:
[49580.534247]  ? _raw_spin_lock_irqsave+0x1f/0x30
[49580.534253]  ? __remove_mapping+0x65/0x1b0
[49580.534258]  ? page_mkclean_one+0x100/0x100
[49580.534313]  ? page_get_anon_vma+0xa0/0xa0
[49580.534317]  ? shrink_page_list+0x6aa/0xda0
[49580.534321]  ? shrink_inactive_list+0x1f6/0x4b0
[49580.534325]  ? es_reclaim_extents+0x55/0xe0
[49580.534328]  ? inactive_list_is_low.isra.70+0x10e/0x1c0
[49580.534332]  ? shrink_node_memcg.isra.75+0x58c/0x6b0
[49580.534531]  ? shrink_node+0x4a/0x190
[49580.534705]  ? kswapd+0x2b7/0x5d0
[49580.535076]  ? kthread+0xf1/0x130
[49580.535477]  ? shrink_node+0x190/0x190
[49580.535869]  ? __kthread_init_worker+0xa0/0xa0
[49580.536257]  ? ret_from_fork+0x23/0x30
[49580.53] Code: 47 02 c1 e0 10 0f 84 93 00 00 00 48 89 c2 c1 e8 12 
48 c1 ea 0c ff c8 83 e2 30 48 98 48 81 c2 00 99 01 00 48 03 14 c5 20 54 
77 81 <48> 89 32 8b 46 08 85 c0 75 09 f3 90 8b 46 08 85 c0 74 f7 4c 8b
[49580.537489] RIP: queued_spin_lock_slowpath+0xe7/0x170 RSP: 
c9433a50

[49580.537904] CR2: 817cddfe
[49580.540107] ---[ end trace f58d3bdd0830f2bf ]---
[49580.540642] Kernel panic - not syncing: Fatal exception
[49580.541212] Kernel Offset: disabled
[49580.541493] Rebooting in 10 seconds..
[49590.501026] ACPI MEMORY or I/O RESET_REG.


This box survives days of memtest, but I'm not above suspecting the 
underlying hardware if it points to that.

Re: 4.11.0-rc5-00011-g08e4e0d oops in mpt3sas driver

[Brad Campbell]

On 06/04/17 08:30, Brad Campbell wrote:

G'day All,

This is a vaguely current git head kernel compiled yesterday.

Oopsed and rebooted itself, and then oopsed and rebooted again. There
was no sign of a raid rebuild in the kernel logs, and it's a staging
machine so there is nothing running after a reboot that goes near these
disks. They should have been completely idle the second time around.

This box suffered from bad rcu stalls on 4.10.x stable kernels, so I
upgraded to git head. It's all new hardware (the CPU, Chipset and
board), so I expected some issues with the board, but the LSI cards have
been around for a while now.


Further investigation indicates it might be a deeper problem. This is 
the first oops captured and it has nothing to do with the mpt3 driver.


[49580.533852] BUG: unable to handle kernel paging request at 
817cddfe

[49580.533875] IP: queued_spin_lock_slowpath+0xe7/0x170
[49580.533879] PGD 180a067
[49580.533879] PUD 180b063
[49580.533882] PMD 816001e1
[49580.533885]
[49580.533890] Oops: 0003 [#1] SMP
[49580.533894] Modules linked in: it87(O) deflate zlib_deflate ctr 
des_generic cbc cmac sha1_generic md5 hmac af_key xfrm_algo nfsd 
auth_rpcgss oid_registry nfs_acl nfs lockd grace sunrpc bonding 
sha256_generic dm_crypt aesni_intel aes_x86_64 crypto_simd cryptd 
glue_helper hwmon_vid netconsole configfs vhost_net vhost kvm_amd kvm 
irqbypass usbhid usb_storage nouveau video drm_kms_helper cfbfillrect 
syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea ttm 
drm mxm_wmi xhci_pci i2c_piix4 xhci_hcd usbcore usb_common wmi 
acpi_cpufreq mpt3sas igb i2c_algo_bit raid_class scsi_transport_sas ahci 
libahci
[49580.533929] CPU: 6 PID: 114 Comm: kswapd0 Tainted: G   O 
4.11.0-rc5-00011-g08e4e0d-dirty #39
[49580.533933] Hardware name: System manufacturer System Product 
Name/PRIME X370-PRO, BIOS 0515 03/30/2017

[49580.534045] task: 8807f9ad task.stack: c943
[49580.534049] RIP: 0010:queued_spin_lock_slowpath+0xe7/0x170
[49580.534052] RSP: 0018:c9433a50 EFLAGS: 00010082
[49580.534056] RAX: 34e1 RBX: 0292 RCX: 
001c
[49580.534059] RDX: 817cddfe RSI: 88081ed99900 RDI: 
8806ddb860e0
[49580.534063] RBP: 8806ddb860e0 R08: 0101 R09: 
dead0200
[49580.534119] R10: ea001c000700 R11: 880006b457b9 R12: 
8806ddb860c8
[49580.534122] R13: 0001 R14: c9433b40 R15: 
8806ddb860c8
[49580.534179] FS:  () GS:88081ed8() 
knlGS:

[49580.534183] CS:  0010 DS:  ES:  CR0: 80050033
[49580.534186] CR2: 817cddfe CR3: 01809000 CR4: 
003406e0

[49580.534190] Call Trace:
[49580.534247]  ? _raw_spin_lock_irqsave+0x1f/0x30
[49580.534253]  ? __remove_mapping+0x65/0x1b0
[49580.534258]  ? page_mkclean_one+0x100/0x100
[49580.534313]  ? page_get_anon_vma+0xa0/0xa0
[49580.534317]  ? shrink_page_list+0x6aa/0xda0
[49580.534321]  ? shrink_inactive_list+0x1f6/0x4b0
[49580.534325]  ? es_reclaim_extents+0x55/0xe0
[49580.534328]  ? inactive_list_is_low.isra.70+0x10e/0x1c0
[49580.534332]  ? shrink_node_memcg.isra.75+0x58c/0x6b0
[49580.534531]  ? shrink_node+0x4a/0x190
[49580.534705]  ? kswapd+0x2b7/0x5d0
[49580.535076]  ? kthread+0xf1/0x130
[49580.535477]  ? shrink_node+0x190/0x190
[49580.535869]  ? __kthread_init_worker+0xa0/0xa0
[49580.536257]  ? ret_from_fork+0x23/0x30
[49580.53] Code: 47 02 c1 e0 10 0f 84 93 00 00 00 48 89 c2 c1 e8 12 
48 c1 ea 0c ff c8 83 e2 30 48 98 48 81 c2 00 99 01 00 48 03 14 c5 20 54 
77 81 <48> 89 32 8b 46 08 85 c0 75 09 f3 90 8b 46 08 85 c0 74 f7 4c 8b
[49580.537489] RIP: queued_spin_lock_slowpath+0xe7/0x170 RSP: 
c9433a50

[49580.537904] CR2: 817cddfe
[49580.540107] ---[ end trace f58d3bdd0830f2bf ]---
[49580.540642] Kernel panic - not syncing: Fatal exception
[49580.541212] Kernel Offset: disabled
[49580.541493] Rebooting in 10 seconds..
[49590.501026] ACPI MEMORY or I/O RESET_REG.


This box survives days of memtest, but I'm not above suspecting the 
underlying hardware if it points to that.

4.11.0-rc5-00011-g08e4e0d oops in mpt3sas driver

[Brad Campbell]

G'day All,

This is a vaguely current git head kernel compiled yesterday.

Oopsed and rebooted itself, and then oopsed and rebooted again. There 
was no sign of a raid rebuild in the kernel logs, and it's a staging 
machine so there is nothing running after a reboot that goes near these 
disks. They should have been completely idle the second time around.


This box suffered from bad rcu stalls on 4.10.x stable kernels, so I 
upgraded to git head. It's all new hardware (the CPU, Chipset and 
board), so I expected some issues with the board, but the LSI cards have 
been around for a while now.


I'm pretty sure this is the second time it has done this, but the first 
where I had netconsole set up to capture it.


It is hard to hit and I've had 2 instances in about 5 days of very heavy 
I/O loads. Having said that, the second oops last night happened when 
idle, so I'm now out of ideas.


The only thing that might have been hitting these disks is smartmontools 
routine polling, but inspecting the logs it appears the reboot happened 
well between polls. No sign of anything in the logs, but got it on 
netconsole.


System is a new AMD Ryzen.
Controllers are :
27:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic 
SAS2116 PCI-Express Fusion-MPT SAS-2 [Meteor] (rev 02)
28:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic 
SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 03)


Only the 2116 has drives on it, and it has 8 6TB WD Red disks on SATA. 
Nothing else. The 2008 is just sitting taking up a slot.


Kernel is tainted by an out of tree build of the it87 driver, however 
nothing polls or uses that driver unless I'm at the console manually 
checking.


This machine originally oopsed after some heavy load and rebooted :
[49580.533852] BUG: unable to handle kernel paging request at 
817cddfe

[49580.533875] IP: queued_spin_lock_slowpath+0xe7/0x170

Tree is dirty due to this md patch :

diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index c523fd69a7bc..2eb45d57226c 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -3618,8 +3618,9 @@ static int fetch_block(struct stripe_head *sh, 
struct stripe_head_state *s,

BUG_ON(test_bit(R5_Wantread, >flags));
BUG_ON(sh->batch_head);
if ((s->uptodate == disks - 1) &&
+   ((sh->qd_idx >= 0 && sh->pd_idx == disk_idx) ||
(s->failed && (disk_idx == s->failed_num[0] ||
-  disk_idx == s->failed_num[1]))) {
+  disk_idx == s->failed_num[1] {
/* have disk failed, and we're requested to fetch it;
 * do compute it
 */


[ 4433.138683] BUG: unable to handle kernel paging request at 
9807cd621d60

[ 4433.138802] IP: _scsih_set_satl_pending+0x0/0x50 [mpt3sas]
[ 4433.138875] PGD 0
[ 4433.138875]
[ 4433.138928] Oops:  [#1] SMP
[ 4433.138976] Modules linked in: deflate zlib_deflate ctr des_generic 
cbc cmac sha1_generic md5 hmac af_key xfrm_algo nfsd auth_rpcgss 
oid_registry nfs_acl nfs lockd grace sunrpc bonding sha256_generic 
dm_crypt aesni_intel aes_x86_64 crypto_simd cryptd glue_helper it87(O) 
hwmon_vid netconsole configfs vhost_net vhost kvm_amd kvm irqbypass 
usbhid usb_storage nouveau video drm_kms_helper cfbfillrect syscopyarea 
cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea ttm drm mxm_wmi 
xhci_pci i2c_piix4 xhci_hcd usbcore usb_common wmi acpi_cpufreq mpt3sas 
raid_class scsi_transport_sas igb i2c_algo_bit ahci libahci
[ 4433.139831] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G   O 
4.11.0-rc5-00011-g08e4e0d-dirty #39
[ 4433.140032] Hardware name: System manufacturer System Product 
Name/PRIME X370-PRO, BIOS 0515 03/30/2017

[ 4433.140164] task: 8180e4c0 task.stack: 8180
[ 4433.140257] RIP: 0010:_scsih_set_satl_pending+0x0/0x50 [mpt3sas]
[ 4433.140349] RSP: 0018:88081ec03da0 EFLAGS: 00010046
[ 4433.140429] RAX: 0001 RBX: 8807f66585b0 RCX: 

[ 4433.140540] RDX:  RSI:  RDI: 
9807cd621d30
[ 4433.140651] RBP: 9807cd621d30 R08: 0001 R09: 
1594
[ 4433.140762] R10:  R11: 0018 R12: 

[ 4433.140872] R13: 8807f5c10bd0 R14: 0048 R15: 
0048
[ 4433.140984] FS:  () GS:88081ec0() 
knlGS:

[ 4433.141109] CS:  0010 DS:  ES:  CR0: 80050033
[ 4433.141198] CR2: 9807cd621d60 CR3: 0007da667000 CR4: 
003406f0

[ 4433.141309] Call Trace:
[ 4433.141399]  
[ 4433.141416]  ? _scsih_io_done+0xa2/0xa30 [mpt3sas]
[ 4433.141494]  ? load_balance+0x152/0x870
[ 4433.141549]  ? _base_interrupt+0x116/0xa30 [mpt3sas]
[ 4433.141627]  ? del_timer+0x60/0x60
[ 4433.141680]  ? __handle_irq_event_percpu+0x51/0x1c0
[ 4433.141752]  ? 

4.11.0-rc5-00011-g08e4e0d oops in mpt3sas driver

[Brad Campbell]

G'day All,

This is a vaguely current git head kernel compiled yesterday.

Oopsed and rebooted itself, and then oopsed and rebooted again. There 
was no sign of a raid rebuild in the kernel logs, and it's a staging 
machine so there is nothing running after a reboot that goes near these 
disks. They should have been completely idle the second time around.


This box suffered from bad rcu stalls on 4.10.x stable kernels, so I 
upgraded to git head. It's all new hardware (the CPU, Chipset and 
board), so I expected some issues with the board, but the LSI cards have 
been around for a while now.


I'm pretty sure this is the second time it has done this, but the first 
where I had netconsole set up to capture it.


It is hard to hit and I've had 2 instances in about 5 days of very heavy 
I/O loads. Having said that, the second oops last night happened when 
idle, so I'm now out of ideas.


The only thing that might have been hitting these disks is smartmontools 
routine polling, but inspecting the logs it appears the reboot happened 
well between polls. No sign of anything in the logs, but got it on 
netconsole.


System is a new AMD Ryzen.
Controllers are :
27:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic 
SAS2116 PCI-Express Fusion-MPT SAS-2 [Meteor] (rev 02)
28:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic 
SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 03)


Only the 2116 has drives on it, and it has 8 6TB WD Red disks on SATA. 
Nothing else. The 2008 is just sitting taking up a slot.


Kernel is tainted by an out of tree build of the it87 driver, however 
nothing polls or uses that driver unless I'm at the console manually 
checking.


This machine originally oopsed after some heavy load and rebooted :
[49580.533852] BUG: unable to handle kernel paging request at 
817cddfe

[49580.533875] IP: queued_spin_lock_slowpath+0xe7/0x170

Tree is dirty due to this md patch :

diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index c523fd69a7bc..2eb45d57226c 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -3618,8 +3618,9 @@ static int fetch_block(struct stripe_head *sh, 
struct stripe_head_state *s,

BUG_ON(test_bit(R5_Wantread, >flags));
BUG_ON(sh->batch_head);
if ((s->uptodate == disks - 1) &&
+   ((sh->qd_idx >= 0 && sh->pd_idx == disk_idx) ||
(s->failed && (disk_idx == s->failed_num[0] ||
-  disk_idx == s->failed_num[1]))) {
+  disk_idx == s->failed_num[1] {
/* have disk failed, and we're requested to fetch it;
 * do compute it
 */


[ 4433.138683] BUG: unable to handle kernel paging request at 
9807cd621d60

[ 4433.138802] IP: _scsih_set_satl_pending+0x0/0x50 [mpt3sas]
[ 4433.138875] PGD 0
[ 4433.138875]
[ 4433.138928] Oops:  [#1] SMP
[ 4433.138976] Modules linked in: deflate zlib_deflate ctr des_generic 
cbc cmac sha1_generic md5 hmac af_key xfrm_algo nfsd auth_rpcgss 
oid_registry nfs_acl nfs lockd grace sunrpc bonding sha256_generic 
dm_crypt aesni_intel aes_x86_64 crypto_simd cryptd glue_helper it87(O) 
hwmon_vid netconsole configfs vhost_net vhost kvm_amd kvm irqbypass 
usbhid usb_storage nouveau video drm_kms_helper cfbfillrect syscopyarea 
cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea ttm drm mxm_wmi 
xhci_pci i2c_piix4 xhci_hcd usbcore usb_common wmi acpi_cpufreq mpt3sas 
raid_class scsi_transport_sas igb i2c_algo_bit ahci libahci
[ 4433.139831] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G   O 
4.11.0-rc5-00011-g08e4e0d-dirty #39
[ 4433.140032] Hardware name: System manufacturer System Product 
Name/PRIME X370-PRO, BIOS 0515 03/30/2017

[ 4433.140164] task: 8180e4c0 task.stack: 8180
[ 4433.140257] RIP: 0010:_scsih_set_satl_pending+0x0/0x50 [mpt3sas]
[ 4433.140349] RSP: 0018:88081ec03da0 EFLAGS: 00010046
[ 4433.140429] RAX: 0001 RBX: 8807f66585b0 RCX: 

[ 4433.140540] RDX:  RSI:  RDI: 
9807cd621d30
[ 4433.140651] RBP: 9807cd621d30 R08: 0001 R09: 
1594
[ 4433.140762] R10:  R11: 0018 R12: 

[ 4433.140872] R13: 8807f5c10bd0 R14: 0048 R15: 
0048
[ 4433.140984] FS:  () GS:88081ec0() 
knlGS:

[ 4433.141109] CS:  0010 DS:  ES:  CR0: 80050033
[ 4433.141198] CR2: 9807cd621d60 CR3: 0007da667000 CR4: 
003406f0

[ 4433.141309] Call Trace:
[ 4433.141399]  
[ 4433.141416]  ? _scsih_io_done+0xa2/0xa30 [mpt3sas]
[ 4433.141494]  ? load_balance+0x152/0x870
[ 4433.141549]  ? _base_interrupt+0x116/0xa30 [mpt3sas]
[ 4433.141627]  ? del_timer+0x60/0x60
[ 4433.141680]  ? __handle_irq_event_percpu+0x51/0x1c0
[ 4433.141752]  ? 

Re: 3.12: raid-1 mismatch_cnt question

[Brad Campbell]

On 11/07/2013 06:54 PM, Justin Piszcz wrote:

On Mon, Nov 4, 2013 at 5:25 AM, Justin Piszcz  wrote:

Hi,

I run two SSDs in a RAID-1 configuration and I have a swap partition on a
third SSD.  Over time, the mismatch_cnt between the two devices grows higher
and higher.



Are both SSD's identical? Do you have discard enabled on the filesystem?

The reason I ask is I have a RAID10 comprised of 3 Intel and 3 Samsung 
SSD's. The Intel return 0 after TRIM while the Samsung don't, so I 
_always_ have a massive mismatch_cnt after I run fstrim. I never use a 
repair operation as it's just going to re-write the already trimmed sectors.



Just a thought.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.12: raid-1 mismatch_cnt question

[Brad Campbell]

On 11/07/2013 06:54 PM, Justin Piszcz wrote:

On Mon, Nov 4, 2013 at 5:25 AM, Justin Piszcz jpis...@lucidpixels.com wrote:

Hi,

I run two SSDs in a RAID-1 configuration and I have a swap partition on a
third SSD.  Over time, the mismatch_cnt between the two devices grows higher
and higher.



Are both SSD's identical? Do you have discard enabled on the filesystem?

The reason I ask is I have a RAID10 comprised of 3 Intel and 3 Samsung 
SSD's. The Intel return 0 after TRIM while the Samsung don't, so I 
_always_ have a massive mismatch_cnt after I run fstrim. I never use a 
repair operation as it's just going to re-write the already trimmed sectors.



Just a thought.


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.10: discard/trim support on md-raid1?

[Brad Campbell]

On 13/07/13 18:34, Justin Piszcz wrote:

And possibly:
discard_zeroes_data: 1


Does it though?

Here's my 6 x SSD RAID10 that definitely discards.

brad@srv:~$ grep . /sys/block/md2/queue/*
/sys/block/md2/queue/add_random:0
/sys/block/md2/queue/discard_granularity:33553920
/sys/block/md2/queue/discard_max_bytes:65536
/sys/block/md2/queue/discard_zeroes_data:0
/sys/block/md2/queue/hw_sector_size:512
/sys/block/md2/queue/iostats:0
/sys/block/md2/queue/logical_block_size:512
/sys/block/md2/queue/max_hw_sectors_kb:16383
/sys/block/md2/queue/max_integrity_segments:0
/sys/block/md2/queue/max_sectors_kb:512
/sys/block/md2/queue/max_segments:128
/sys/block/md2/queue/max_segment_size:65536
/sys/block/md2/queue/minimum_io_size:65536
/sys/block/md2/queue/nomerges:0
/sys/block/md2/queue/nr_requests:128
/sys/block/md2/queue/optimal_io_size:196608
/sys/block/md2/queue/physical_block_size:512
/sys/block/md2/queue/read_ahead_kb:384
/sys/block/md2/queue/rotational:1
/sys/block/md2/queue/rq_affinity:0
/sys/block/md2/queue/scheduler:none
/sys/block/md2/queue/write_same_max_bytes:0

Mine does not have discard_zeroes_data == 1 which is correct as 3 of the drives are Samsung 830's 
and they don't return deterministic after trim.


I can verify that discard gets passed down the stack as I get a non-zero mismatch count after 
running a trim on the filesystem. Checking the mirrors manually sees 0 returned from the Intel 
330's, and apparently random data returned from the 830's.


Regards,
Brad
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.10: discard/trim support on md-raid1?

[Brad Campbell]

On 13/07/13 18:34, Justin Piszcz wrote:

And possibly:
discard_zeroes_data: 1


Does it though?

Here's my 6 x SSD RAID10 that definitely discards.

brad@srv:~$ grep . /sys/block/md2/queue/*
/sys/block/md2/queue/add_random:0
/sys/block/md2/queue/discard_granularity:33553920
/sys/block/md2/queue/discard_max_bytes:65536
/sys/block/md2/queue/discard_zeroes_data:0
/sys/block/md2/queue/hw_sector_size:512
/sys/block/md2/queue/iostats:0
/sys/block/md2/queue/logical_block_size:512
/sys/block/md2/queue/max_hw_sectors_kb:16383
/sys/block/md2/queue/max_integrity_segments:0
/sys/block/md2/queue/max_sectors_kb:512
/sys/block/md2/queue/max_segments:128
/sys/block/md2/queue/max_segment_size:65536
/sys/block/md2/queue/minimum_io_size:65536
/sys/block/md2/queue/nomerges:0
/sys/block/md2/queue/nr_requests:128
/sys/block/md2/queue/optimal_io_size:196608
/sys/block/md2/queue/physical_block_size:512
/sys/block/md2/queue/read_ahead_kb:384
/sys/block/md2/queue/rotational:1
/sys/block/md2/queue/rq_affinity:0
/sys/block/md2/queue/scheduler:none
/sys/block/md2/queue/write_same_max_bytes:0

Mine does not have discard_zeroes_data == 1 which is correct as 3 of the drives are Samsung 830's 
and they don't return deterministic after trim.


I can verify that discard gets passed down the stack as I get a non-zero mismatch count after 
running a trim on the filesystem. Checking the mirrors manually sees 0 returned from the Intel 
330's, and apparently random data returned from the 830's.


Regards,
Brad
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Advice on a userspace tty serial driver

[Brad Campbell]

G'day all,

I'm building a bit of hardware. It's basically a serial multiplexer that communicates to the PC 
using a single usb-serial port. It has the ability to run between 2 and 8 standard async ports over 
this single interface.


I'd rather not write a kernel driverif possible as I figure this would be a perfect application for 
a userspace daemon to do the control and mux/demux. I'd prefer to present standard serial style 
devices (/dev/ttySxx) to userspace giving me the ability to run unmodified software to talk to the 
multiplexed ports.


I think tty/pty pairs looks roughly what I'm after, but will they allow me to use standard IOCTLS 
for conveying baud rate and other standard serial parameters to the daemon?


I've spotted several userspace serial driver projects in the last 7 or so years, but I can't seem to 
find any that made it into the kernel.


Am I on the right track with tty/pty or is there a better way?

Regards,
Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Advice on a userspace tty serial driver

[Brad Campbell]

G'day all,

I'm building a bit of hardware. It's basically a serial multiplexer that communicates to the PC 
using a single usb-serial port. It has the ability to run between 2 and 8 standard async ports over 
this single interface.


I'd rather not write a kernel driverif possible as I figure this would be a perfect application for 
a userspace daemon to do the control and mux/demux. I'd prefer to present standard serial style 
devices (/dev/ttySxx) to userspace giving me the ability to run unmodified software to talk to the 
multiplexed ports.


I think tty/pty pairs looks roughly what I'm after, but will they allow me to use standard IOCTLS 
for conveying baud rate and other standard serial parameters to the daemon?


I've spotted several userspace serial driver projects in the last 7 or so years, but I can't seem to 
find any that made it into the kernel.


Am I on the right track with tty/pty or is there a better way?

Regards,
Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Standalone swap prefetch patch for mainline

[Brad Campbell]

Paolo Ciarrocchi wrote:


Brad, is it possible for you to do some more test with the latest
version of both SD and CFS  and post some more detailed feedbacks?
That would help a lot.


Err.. Ok. I have the latest version of SD (that I know about). I could upgrade CFS, but unlike those 
doing real scientific testing, I'm just getting a feel with my usual usage patterns (thunderbird, 
firefox, openoffice, gimp, x-chat and gnome). I don't have any hard fast metrics I can measure 
against really.


Anything I post would be subjective at best. (And to be honest, once I get a stable and usable 
kernel I tend to stick with it for a month or so as I don't reboot - suspend2 regularly goes 100 
suspend/resume cycles to S3 between reboots for me)


I'm a little more willing to experiment on my desktop box, but I really live 
from the laptop.

Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Standalone swap prefetch patch for mainline

[Brad Campbell]

Con Kolivas wrote:
I've had a few requests for a standalone patch implementing swap prefetch for 
mainline.


Here is a patch that is a current rollup that should apply and work for 
vanilla 2.6.21 (ie not a -ck kernel):


http://ck.kolivas.org/patches/swap-prefetch/2.6.21-swap_prefetch-38.patch



Heh.. 20 mins after I finished scraping the relevant bits from -ck1 and 
patching my kernel this arrives!



I don't normally get/take the time to pass personal comment, but I have to say Con I've just taken a 
2.6.21 kernel, applied your 0.48 SD scheduler and swap-prefetch from -ck1 (needed to separate them 
out so I could also apply suspend2) and it's like I've bought a new machine.


I'm running on a tiny Vaio with a 4800RPM 1.8" drive, so it's not fast by any stretch of the 
imagination. But the combination of SD and swap-prefetch has given it a new lease on life completely.


Really, you have done a great job with SD. I was so impressed I built a new kernel for my Core Duo 
Mac Mini with the full 2.6.21-ck1 patchset. I wish I'd tried it years ago!


This also prompted me to have a play with CFS, but for my desktop workload on either machine, SD 
just "felt" better (for whatever that may be worth).


+1 for SD
+1 for swap-prefetch

Regards,
Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Standalone swap prefetch patch for mainline

[Brad Campbell]

Con Kolivas wrote:
I've had a few requests for a standalone patch implementing swap prefetch for 
mainline.


Here is a patch that is a current rollup that should apply and work for 
vanilla 2.6.21 (ie not a -ck kernel):


http://ck.kolivas.org/patches/swap-prefetch/2.6.21-swap_prefetch-38.patch



Heh.. 20 mins after I finished scraping the relevant bits from -ck1 and 
patching my kernel this arrives!

WARNING - Fanboy rant ahead

I don't normally get/take the time to pass personal comment, but I have to say Con I've just taken a 
2.6.21 kernel, applied your 0.48 SD scheduler and swap-prefetch from -ck1 (needed to separate them 
out so I could also apply suspend2) and it's like I've bought a new machine.


I'm running on a tiny Vaio with a 4800RPM 1.8 drive, so it's not fast by any stretch of the 
imagination. But the combination of SD and swap-prefetch has given it a new lease on life completely.


Really, you have done a great job with SD. I was so impressed I built a new kernel for my Core Duo 
Mac Mini with the full 2.6.21-ck1 patchset. I wish I'd tried it years ago!


This also prompted me to have a play with CFS, but for my desktop workload on either machine, SD 
just felt better (for whatever that may be worth).


+1 for SD
+1 for swap-prefetch

Regards,
Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Standalone swap prefetch patch for mainline

[Brad Campbell]

Paolo Ciarrocchi wrote:


Brad, is it possible for you to do some more test with the latest
version of both SD and CFS  and post some more detailed feedbacks?
That would help a lot.


Err.. Ok. I have the latest version of SD (that I know about). I could upgrade CFS, but unlike those 
doing real scientific testing, I'm just getting a feel with my usual usage patterns (thunderbird, 
firefox, openoffice, gimp, x-chat and gnome). I don't have any hard fast metrics I can measure 
against really.


Anything I post would be subjective at best. (And to be honest, once I get a stable and usable 
kernel I tend to stick with it for a month or so as I don't reboot - suspend2 regularly goes 100 
suspend/resume cycles to S3 between reboots for me)


I'm a little more willing to experiment on my desktop box, but I really live 
from the laptop.

Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Degraded RAID performance - Was : Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

Neil Brown wrote:

I wonder if we should avoid bypassing the stripe cache if the needed stripes
are already in the cache... or if at least one needed stripe is or
if the array is degraded...
Probably in the degraded case we should never bypass the cache, as if
we do, then a sequential read of a full stripe will read every block
twice.  I'd better to some performance measurements.


Ok, that would explain some odd performance issues I've noticed.
Let's say I run

dstat -D sda,sdb,sdc,sdd,md0 5
total-cpu-usage --disk/sdadisk/sdbdisk/sdcdisk/sdddisk/md0- -net/total- 
---paging-- ---system--
usr sys idl wai hiq siq|_read write _read write _read write _read write _read write|_recv 
_send|__in_ _out_|_int_ _csw_
 25  22   0  47   0   6|20.1M0 :20.2M0 :20.1M0 :   0 0 :40.2M0 | 146B  662B| 
0 0 |1186   661
 26  20   0  46   0   8|19.4M0 :19.4M0 :19.4M0 :   0 0 :38.9M0 | 160B  549B| 
0 0 |1365   650


Given I'm doing a read, I would have expected a read to consist of 2 direct reads, one parity read 
and some calculation. The numbers I'm seeing however show 3 reads for 2 reads worth of bandwidth.


[EMAIL PROTECTED]:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sda[0] sdc[2] sdb[1]
  585934080 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_]

(Dropped Jens and Chuck from the cc as this likely has little interest for them)

Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

Neil Brown wrote:



You could test this theory by putting a
   WARN_ON(cfqq->next_rq == NULL);
at the end of cfq_reposition_rq_rb, just after the cfq_add_rq_rb call.




[  756.311074] BUG: at block/cfq-iosched.c:543 cfq_reposition_rq_rb()
[  756.329615]  [] cfq_merged_request+0x71/0x80
[  756.345046]  [] cfq_merged_request+0x0/0x80
[  756.360216]  [] elv_merged_request+0x4e/0x50
[  756.375647]  [] __make_request+0x1a7/0x2f0
[  756.390557]  [] generic_make_request+0x127/0x190
[  756.407025]  [] chunk_aligned_read+0x111/0x1c0
[  756.422974]  [] generic_make_request+0x127/0x190
[  756.439443]  [] make_request+0x388/0x3b0
[  756.453834]  [] __bio_add_page+0x147/0x1c0
[  756.468742]  [] bio_alloc_bioset+0x7f/0x150
[  756.483913]  [] raid5_mergeable_bvec+0x0/0x90
[  756.499604]  [] bio_add_page+0x37/0x50
[  756.513473]  [] generic_make_request+0x127/0x190
[  756.529943]  [] mempool_free+0x2a/0x60
[  756.543812]  [] bio_free+0x1d/0x40
[  756.556645]  [] submit_bio+0x46/0xc0
[  756.571389]  [] radix_tree_node_alloc+0x16/0x60
[  756.587610]  [] radix_tree_insert+0xe2/0x130
[  756.603039]  [] __pagevec_lru_add+0x75/0x80
[  756.618207]  [] mpage_bio_submit+0x11/0x20
[  756.633117]  [] mpage_readpages+0x100/0x140
[  756.648287]  [] ext3_get_block+0x0/0xe0
[  756.662419]  [] scsi_end_request+0x9b/0xc0
[  756.677329]  [] scsi_delete_timer+0xb/0x20
[  756.692240]  [] ext3_readpages+0x0/0x20
[  756.706369]  [] read_pages+0xd1/0xe0
[  756.719719]  [] ext3_get_block+0x0/0xe0
[  756.733853]  [] __alloc_pages+0x54/0x2d0
[  756.748242]  [] scsi_softirq_done+0x6f/0xe0
[  756.763413]  [] sil_interrupt+0x81/0x90
[  756.777544]  [] blk_done_softirq+0x58/0x70
[  756.792454]  [] __do_page_cache_readahead+0xa8/0x110
[  756.809961]  [] blockable_page_cache_readahead+0x51/0xd0
[  756.828508]  [] make_ahead_window+0x74/0xc0
[  756.843679]  [] page_cache_readahead+0x9a/0x180
[  756.859886]  [] file_read_actor+0xc4/0xd0
[  756.874537]  [] do_generic_mapping_read+0x467/0x470
[  756.891786]  [] generic_file_aio_read+0x183/0x1c0
[  756.908514]  [] file_read_actor+0x0/0xd0
[  756.922903]  [] scsi_next_command+0x30/0x50
[  756.938073]  [] do_sync_read+0xc0/0x100
[  756.952204]  [] autoremove_wake_function+0x0/0x50
[  756.968934]  [] scsi_finish_command+0x40/0x60
[  756.984622]  [] schedule+0x2e5/0x590
[  756.997972]  [] vfs_read+0x86/0x110
[  757.011065]  [] sys_read+0x47/0x80
[  757.023897]  [] syscall_call+0x7/0xb
[  757.037250]  ===


I know this is late given a fix has been issued, but just got this in the logs with no other debug 
info at all. This kernel has *all* Jens debugging patches + the snippet from Neil above.


I'll apply the fix now and run it for a couple of days.

Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

Jens Axboe wrote:


It looks to be extremely rare. Aliases are extremely rare, front merges
are rare. And you need both to happen with the details you outlined. But
it's a large user base, and we've had 3-4 reports on this in the past
months. So it obviously does happen. I could not make it trigger without
doctoring the unplug code when I used aio.


Well, not that rare on this particular machine (I had a case where I could reproduce it in less than 
an hour of normal use previously on this box), and I've had it occur a number of times on my 
servers, I just never reported it before as I never took the time to set up a serial console and 
capture the oops.



Here's a fix for it, confirmed.


Shall I leave the other debugging in, apply this and run it for a few hard days?

Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

Neil Brown wrote:

On Wednesday April 25, [EMAIL PROTECTED] wrote:

BUT... That may explain while we are only seeing it on md. Would md
ever be issuing such requests that trigger this condition?


Can someone remind me which raid level(s) was/were involved?


Raid-5 gegraded here, But I've had it on my server on a fully functioning raid-5 also. Don't think 
I've seen it on any of my raid-6 yet.



I guess it could happen with raid4/5/6.  A read request that was
properly aligned (and we do encourage proper alignment) will be passed
directly to the underlying device.  A concurrent write elsewhere could
require the same block to be read into the stripe-cache to enable a
parity calculation.  So you could get two reads at the same block
address.


Except all the filesystems I've had this occur on are Ext3 and all are mounted noatime, with no 
processes ever writing to the filesystems. So here it occurs with reads only.


Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

Neil Brown wrote:


How likely it would be to get two requests with the same sector number
I don't know.  I wouldn't expect it to ever happen - I have seen it
before, but it was due to a bug in ext3.  Maybe XFS does it
intentionally some times?


It certainly sounds like an odd thing to occur.

Even stranger that it's easier to hit on a degraded array or an array being 
checked.

I *am* using ext3 on this box (and all my boxes in fact)


You could test this theory by putting a
   WARN_ON(cfqq->next_rq == NULL);
at the end of cfq_reposition_rq_rb, just after the cfq_add_rq_rb call.


I've done that.. now to wait for it to hit again.

Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

Neil Brown wrote:


How likely it would be to get two requests with the same sector number
I don't know.  I wouldn't expect it to ever happen - I have seen it
before, but it was due to a bug in ext3.  Maybe XFS does it
intentionally some times?


It certainly sounds like an odd thing to occur.

Even stranger that it's easier to hit on a degraded array or an array being 
checked.

I *am* using ext3 on this box (and all my boxes in fact)


You could test this theory by putting a
   WARN_ON(cfqq-next_rq == NULL);
at the end of cfq_reposition_rq_rb, just after the cfq_add_rq_rb call.


I've done that.. now to wait for it to hit again.

Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

Neil Brown wrote:

On Wednesday April 25, [EMAIL PROTECTED] wrote:

BUT... That may explain while we are only seeing it on md. Would md
ever be issuing such requests that trigger this condition?


Can someone remind me which raid level(s) was/were involved?


Raid-5 gegraded here, But I've had it on my server on a fully functioning raid-5 also. Don't think 
I've seen it on any of my raid-6 yet.



I guess it could happen with raid4/5/6.  A read request that was
properly aligned (and we do encourage proper alignment) will be passed
directly to the underlying device.  A concurrent write elsewhere could
require the same block to be read into the stripe-cache to enable a
parity calculation.  So you could get two reads at the same block
address.


Except all the filesystems I've had this occur on are Ext3 and all are mounted noatime, with no 
processes ever writing to the filesystems. So here it occurs with reads only.


Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

Jens Axboe wrote:


It looks to be extremely rare. Aliases are extremely rare, front merges
are rare. And you need both to happen with the details you outlined. But
it's a large user base, and we've had 3-4 reports on this in the past
months. So it obviously does happen. I could not make it trigger without
doctoring the unplug code when I used aio.


Well, not that rare on this particular machine (I had a case where I could reproduce it in less than 
an hour of normal use previously on this box), and I've had it occur a number of times on my 
servers, I just never reported it before as I never took the time to set up a serial console and 
capture the oops.



Here's a fix for it, confirmed.


Shall I leave the other debugging in, apply this and run it for a few hard days?

Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

Neil Brown wrote:



You could test this theory by putting a
   WARN_ON(cfqq-next_rq == NULL);
at the end of cfq_reposition_rq_rb, just after the cfq_add_rq_rb call.




[  756.311074] BUG: at block/cfq-iosched.c:543 cfq_reposition_rq_rb()
[  756.329615]  [c0204fa1] cfq_merged_request+0x71/0x80
[  756.345046]  [c0204f30] cfq_merged_request+0x0/0x80
[  756.360216]  [c01fb4ae] elv_merged_request+0x4e/0x50
[  756.375647]  [c01ff1a7] __make_request+0x1a7/0x2f0
[  756.390557]  [c01ff497] generic_make_request+0x127/0x190
[  756.407025]  [c02bb011] chunk_aligned_read+0x111/0x1c0
[  756.422974]  [c01ff497] generic_make_request+0x127/0x190
[  756.439443]  [c02bb448] make_request+0x388/0x3b0
[  756.453834]  [c016e027] __bio_add_page+0x147/0x1c0
[  756.468742]  [c016dbff] bio_alloc_bioset+0x7f/0x150
[  756.483913]  [c02bac50] raid5_mergeable_bvec+0x0/0x90
[  756.499604]  [c016e107] bio_add_page+0x37/0x50
[  756.513473]  [c01ff497] generic_make_request+0x127/0x190
[  756.529943]  [c013586a] mempool_free+0x2a/0x60
[  756.543812]  [c016dadd] bio_free+0x1d/0x40
[  756.556645]  [c01ff546] submit_bio+0x46/0xc0
[  756.571389]  [c020a396] radix_tree_node_alloc+0x16/0x60
[  756.587610]  [c020a5c2] radix_tree_insert+0xe2/0x130
[  756.603039]  [c0139575] __pagevec_lru_add+0x75/0x80
[  756.618207]  [c0171971] mpage_bio_submit+0x11/0x20
[  756.633117]  [c01720e0] mpage_readpages+0x100/0x140
[  756.648287]  [c0187d50] ext3_get_block+0x0/0xe0
[  756.662419]  [c026fc0b] scsi_end_request+0x9b/0xc0
[  756.677329]  [c026dd2b] scsi_delete_timer+0xb/0x20
[  756.692240]  [c0188ae0] ext3_readpages+0x0/0x20
[  756.706369]  [c0138ac1] read_pages+0xd1/0xe0
[  756.719719]  [c0187d50] ext3_get_block+0x0/0xe0
[  756.733853]  [c0136e24] __alloc_pages+0x54/0x2d0
[  756.748242]  [c02704ff] scsi_softirq_done+0x6f/0xe0
[  756.763413]  [c02861a1] sil_interrupt+0x81/0x90
[  756.777544]  [c01ffa78] blk_done_softirq+0x58/0x70
[  756.792454]  [c0138b78] __do_page_cache_readahead+0xa8/0x110
[  756.809961]  [c0138d21] blockable_page_cache_readahead+0x51/0xd0
[  756.828508]  [c0138e14] make_ahead_window+0x74/0xc0
[  756.843679]  [c0138efa] page_cache_readahead+0x9a/0x180
[  756.859886]  [c0133704] file_read_actor+0xc4/0xd0
[  756.874537]  [c0133637] do_generic_mapping_read+0x467/0x470
[  756.891786]  [c0133893] generic_file_aio_read+0x183/0x1c0
[  756.908514]  [c0133640] file_read_actor+0x0/0xd0
[  756.922903]  [c026fb20] scsi_next_command+0x30/0x50
[  756.938073]  [c014e250] do_sync_read+0xc0/0x100
[  756.952204]  [c0124120] autoremove_wake_function+0x0/0x50
[  756.968934]  [c026bf00] scsi_finish_command+0x40/0x60
[  756.984622]  [c03319a5] schedule+0x2e5/0x590
[  756.997972]  [c014e316] vfs_read+0x86/0x110
[  757.011065]  [c014e5f7] sys_read+0x47/0x80
[  757.023897]  [c0102894] syscall_call+0x7/0xb
[  757.037250]  ===


I know this is late given a fix has been issued, but just got this in the logs with no other debug 
info at all. This kernel has *all* Jens debugging patches + the snippet from Neil above.


I'll apply the fix now and run it for a couple of days.

Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Degraded RAID performance - Was : Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

Neil Brown wrote:

I wonder if we should avoid bypassing the stripe cache if the needed stripes
are already in the cache... or if at least one needed stripe is or
if the array is degraded...
Probably in the degraded case we should never bypass the cache, as if
we do, then a sequential read of a full stripe will read every block
twice.  I'd better to some performance measurements.


Ok, that would explain some odd performance issues I've noticed.
Let's say I run

dstat -D sda,sdb,sdc,sdd,md0 5
total-cpu-usage --disk/sdadisk/sdbdisk/sdcdisk/sdddisk/md0- -net/total- 
---paging-- ---system--
usr sys idl wai hiq siq|_read write _read write _read write _read write _read write|_recv 
_send|__in_ _out_|_int_ _csw_
 25  22   0  47   0   6|20.1M0 :20.2M0 :20.1M0 :   0 0 :40.2M0 | 146B  662B| 
0 0 |1186   661
 26  20   0  46   0   8|19.4M0 :19.4M0 :19.4M0 :   0 0 :38.9M0 | 160B  549B| 
0 0 |1365   650


Given I'm doing a read, I would have expected a read to consist of 2 direct reads, one parity read 
and some calculation. The numbers I'm seeing however show 3 reads for 2 reads worth of bandwidth.


[EMAIL PROTECTED]:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sda[0] sdc[2] sdb[1]
  585934080 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_]

(Dropped Jens and Chuck from the cc as this likely has little interest for them)

Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

Jens Axboe wrote:


Ok, can you try and reproduce with this one applied? It'll keep the
system running (unless there are other corruptions going on), so it
should help you a bit as well. It will dump some cfq state info when the
condition triggers that can perhaps help diagnose this. So if you can
apply this patch and reproduce + send the output, I'd much appreciate
it!



I think I'm wearing holes in my platters. This is being a swine to hit, but I 
finally got some..
It seems to respond to a combination of high cpu usage and relatively high disk 
utilisation.

I tried all sorts of acrobatics with multiple readers and hammering the array while reading from 
individual drives..


The only reliable way I can reproduce this seems to be on a degraded array running a "while true ; 
do md5sum -c md5 ; done" on about a 180GB directory of files. It is taking anywhere from 4 to 96 
hours to hit it though.. but at least it's reproducible.



[105449.653682] cfq: rbroot not empty, but ->next_rq == NULL! Fixing up, report the issue to 
[EMAIL PROTECTED]

[105449.683646] cfq: busy=1,drv=0,timer=0
[105449.694871] cfq rr_list:
[105449.702715]   3108: sort=0,next=,q=0/1,a=1/0,d=0/0,f=69
[105449.720693] cfq busy_list:
[105449.729054] cfq idle_list:
[105449.737418] cfq cur_rr:
[115435.022192] cfq: rbroot not empty, but ->next_rq == NULL! Fixing up, report the issue to 
[EMAIL PROTECTED]

[115435.052160] cfq: busy=1,drv=0,timer=0
[115435.063383] cfq rr_list:
[115435.071227]   3196: sort=0,next=,q=0/1,a=1/0,d=0/0,f=69
[115435.089205] cfq busy_list:
[115435.097566] cfq idle_list:
[115435.105930] cfq cur_rr:
[115616.651883] cfq: rbroot not empty, but ->next_rq == NULL! Fixing up, report the issue to 
[EMAIL PROTECTED]

[115616.681848] cfq: busy=1,drv=0,timer=0
[115616.693071] cfq rr_list:
[115616.700916]   3196: sort=0,next=,q=0/1,a=1/0,d=0/0,f=61
[115616.718893] cfq busy_list:
[115616.727253] cfq idle_list:
[115616.735617] cfq cur_rr:
[119679.564753] cfq: rbroot not empty, but ->next_rq == NULL! Fixing up, report the issue to 
[EMAIL PROTECTED]

[119679.594732] cfq: busy=1,drv=0,timer=0
[119679.605955] cfq rr_list:
[119679.613799]   3241: sort=0,next=,q=0/1,a=1/0,d=0/0,f=69
[119679.631778] cfq busy_list:
[119679.640136] cfq idle_list:
[119679.648502] cfq cur_rr:

Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

Jens Axboe wrote:


Ok, can you try and reproduce with this one applied? It'll keep the
system running (unless there are other corruptions going on), so it
should help you a bit as well. It will dump some cfq state info when the
condition triggers that can perhaps help diagnose this. So if you can
apply this patch and reproduce + send the output, I'd much appreciate
it!



I think I'm wearing holes in my platters. This is being a swine to hit, but I 
finally got some..
It seems to respond to a combination of high cpu usage and relatively high disk 
utilisation.

I tried all sorts of acrobatics with multiple readers and hammering the array while reading from 
individual drives..


The only reliable way I can reproduce this seems to be on a degraded array running a while true ; 
do md5sum -c md5 ; done on about a 180GB directory of files. It is taking anywhere from 4 to 96 
hours to hit it though.. but at least it's reproducible.



[105449.653682] cfq: rbroot not empty, but -next_rq == NULL! Fixing up, report the issue to 
[EMAIL PROTECTED]

[105449.683646] cfq: busy=1,drv=0,timer=0
[105449.694871] cfq rr_list:
[105449.702715]   3108: sort=0,next=,q=0/1,a=1/0,d=0/0,f=69
[105449.720693] cfq busy_list:
[105449.729054] cfq idle_list:
[105449.737418] cfq cur_rr:
[115435.022192] cfq: rbroot not empty, but -next_rq == NULL! Fixing up, report the issue to 
[EMAIL PROTECTED]

[115435.052160] cfq: busy=1,drv=0,timer=0
[115435.063383] cfq rr_list:
[115435.071227]   3196: sort=0,next=,q=0/1,a=1/0,d=0/0,f=69
[115435.089205] cfq busy_list:
[115435.097566] cfq idle_list:
[115435.105930] cfq cur_rr:
[115616.651883] cfq: rbroot not empty, but -next_rq == NULL! Fixing up, report the issue to 
[EMAIL PROTECTED]

[115616.681848] cfq: busy=1,drv=0,timer=0
[115616.693071] cfq rr_list:
[115616.700916]   3196: sort=0,next=,q=0/1,a=1/0,d=0/0,f=61
[115616.718893] cfq busy_list:
[115616.727253] cfq idle_list:
[115616.735617] cfq cur_rr:
[119679.564753] cfq: rbroot not empty, but -next_rq == NULL! Fixing up, report the issue to 
[EMAIL PROTECTED]

[119679.594732] cfq: busy=1,drv=0,timer=0
[119679.605955] cfq rr_list:
[119679.613799]   3241: sort=0,next=,q=0/1,a=1/0,d=0/0,f=69
[119679.631778] cfq busy_list:
[119679.640136] cfq idle_list:
[119679.648502] cfq cur_rr:

Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

Jens Axboe wrote:


Thanks for testing Brad, be sure to use the next patch I sent instead.
The one from this mail shouldn't even get you booted. So double check
that you are still using CFQ :-)



[184901.576773] BUG: unable to handle kernel NULL pointer dereference at 
virtual address 005c
[184901.602612]  printing eip:
[184901.610990] c0205399
[184901.617796] *pde = 
[184901.626421] Oops:  [#1]
[184901.635044] Modules linked in:
[184901.644500] CPU:0
[184901.644501] EIP:0060:[]Not tainted VLI
[184901.644503] EFLAGS: 00010082   (2.6.21-rc7 #7)
[184901.681294] EIP is at cfq_dispatch_insert+0x19/0x70
[184901.696168] eax: f7f078e0   ebx: f7ca2794   ecx: 0004   edx: 
[184901.716743] esi: c1acaa1c   edi: f7c9c6c0   ebp:    esp: dbaefde0
[184901.737316] ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
[184901.755032] Process md5sum (pid: 4268, ti=dbaee000 task=f794a5a0 
task.ti=dbaee000)
[184901.777422] Stack:  c1acaa1c f7c9c6c0  c0205509 e6b61bd8 
c0133451 1000
[184901.803121]0008  0004 0e713800 c1acaa1c f7c9c6c0 
c1acaa1c 
[184901.828837]c0205749 f7ca2794 f7ca2794 f79bc000 0282 c01fb829 
 c016ea8d
[184901.854552] Call Trace:
[184901.862723]  [] __cfq_dispatch_requests+0x79/0x170
[184901.879971]  [] do_generic_mapping_read+0x281/0x470
[184901.897478]  [] cfq_dispatch_requests+0x69/0x90
[184901.913946]  [] elv_next_request+0x39/0x130
[184901.929375]  [] bio_endio+0x5d/0x90
[184901.942725]  [] scsi_request_fn+0x45/0x280
[184901.957896]  [] blk_run_queue+0x32/0x70
[184901.972286]  [] scsi_next_command+0x30/0x50
[184901.987716]  [] scsi_end_request+0x9b/0xc0
[184902.002886]  [] scsi_io_completion+0x81/0x330
[184902.018835]  [] scsi_delete_timer+0xb/0x20
[184902.034006]  [] ata_scsi_qc_complete+0x65/0xd0
[184902.050214]  [] sd_rw_intr+0x8b/0x220
[184902.064085]  [] ata_altstatus+0x1c/0x20
[184902.078475]  [] ata_hsm_move+0x14d/0x3f0
[184902.093126]  [] scsi_finish_command+0x40/0x60
[184902.109075]  [] scsi_softirq_done+0x6f/0xe0
[184902.124506]  [] sil_interrupt+0x81/0x90
[184902.138895]  [] blk_done_softirq+0x58/0x70
[184902.154066]  [] __do_softirq+0x6f/0x80
[184902.181806]  [] do_IRQ+0x3e/0x80
[184902.194380]  [] common_interrupt+0x23/0x28
[184902.209551]  ===
[184902.220512] Code: 0e e3 ef ff e9 47 ff ff ff 89 f6 8d bc 27 00 00 00 00 83 ec 10 89 1c 24 89 6c 
24 0c 89 74 24 04 89 7c 24 08 89 c3 89 d5 8b 40 0c <8b> 72 5c 8b 78

04 89 d0 e8 1a fa ff ff 8b 45 14 89 ea 25 01 80
[184902.280564] EIP: [] cfq_dispatch_insert+0x19/0x70 SS:ESP 
0068:dbaefde0
[184902.303418] Kernel panic - not syncing: Fatal exception in interrupt
[184902.322746] Rebooting in 60 seconds..

Ok, it's taken be _ages_ to get the system to a point I can reproduce this, but I think it's now 
reproducible with a couple of hours beating. The bad news is it looks like it has not tickled any of 
your debugging markers! This was the 1st thing printed on a clean serial console, so nothing above 
that for days.


I did double check and I was/am certainly running the kernel with the debug 
patch compiled in.

Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

Jens Axboe wrote:


Thanks for testing Brad, be sure to use the next patch I sent instead.
The one from this mail shouldn't even get you booted. So double check
that you are still using CFQ :-)



[184901.576773] BUG: unable to handle kernel NULL pointer dereference at 
virtual address 005c
[184901.602612]  printing eip:
[184901.610990] c0205399
[184901.617796] *pde = 
[184901.626421] Oops:  [#1]
[184901.635044] Modules linked in:
[184901.644500] CPU:0
[184901.644501] EIP:0060:[c0205399]Not tainted VLI
[184901.644503] EFLAGS: 00010082   (2.6.21-rc7 #7)
[184901.681294] EIP is at cfq_dispatch_insert+0x19/0x70
[184901.696168] eax: f7f078e0   ebx: f7ca2794   ecx: 0004   edx: 
[184901.716743] esi: c1acaa1c   edi: f7c9c6c0   ebp:    esp: dbaefde0
[184901.737316] ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
[184901.755032] Process md5sum (pid: 4268, ti=dbaee000 task=f794a5a0 
task.ti=dbaee000)
[184901.777422] Stack:  c1acaa1c f7c9c6c0  c0205509 e6b61bd8 
c0133451 1000
[184901.803121]0008  0004 0e713800 c1acaa1c f7c9c6c0 
c1acaa1c 
[184901.828837]c0205749 f7ca2794 f7ca2794 f79bc000 0282 c01fb829 
 c016ea8d
[184901.854552] Call Trace:
[184901.862723]  [c0205509] __cfq_dispatch_requests+0x79/0x170
[184901.879971]  [c0133451] do_generic_mapping_read+0x281/0x470
[184901.897478]  [c0205749] cfq_dispatch_requests+0x69/0x90
[184901.913946]  [c01fb829] elv_next_request+0x39/0x130
[184901.929375]  [c016ea8d] bio_endio+0x5d/0x90
[184901.942725]  [c0270375] scsi_request_fn+0x45/0x280
[184901.957896]  [c01fde92] blk_run_queue+0x32/0x70
[184901.972286]  [c026f8e0] scsi_next_command+0x30/0x50
[184901.987716]  [c026f9cb] scsi_end_request+0x9b/0xc0
[184902.002886]  [c026fb31] scsi_io_completion+0x81/0x330
[184902.018835]  [c026daeb] scsi_delete_timer+0xb/0x20
[184902.034006]  [c027ee35] ata_scsi_qc_complete+0x65/0xd0
[184902.050214]  [c02751bb] sd_rw_intr+0x8b/0x220
[184902.064085]  [c0280c0c] ata_altstatus+0x1c/0x20
[184902.078475]  [c027b68d] ata_hsm_move+0x14d/0x3f0
[184902.093126]  [c026bcc0] scsi_finish_command+0x40/0x60
[184902.109075]  [c02702bf] scsi_softirq_done+0x6f/0xe0
[184902.124506]  [c0285f61] sil_interrupt+0x81/0x90
[184902.138895]  [c01ffa78] blk_done_softirq+0x58/0x70
[184902.154066]  [c011721f] __do_softirq+0x6f/0x80
[184902.181806]  [c0104cee] do_IRQ+0x3e/0x80
[184902.194380]  [c010322f] common_interrupt+0x23/0x28
[184902.209551]  ===
[184902.220512] Code: 0e e3 ef ff e9 47 ff ff ff 89 f6 8d bc 27 00 00 00 00 83 ec 10 89 1c 24 89 6c 
24 0c 89 74 24 04 89 7c 24 08 89 c3 89 d5 8b 40 0c 8b 72 5c 8b 78

04 89 d0 e8 1a fa ff ff 8b 45 14 89 ea 25 01 80
[184902.280564] EIP: [c0205399] cfq_dispatch_insert+0x19/0x70 SS:ESP 
0068:dbaefde0
[184902.303418] Kernel panic - not syncing: Fatal exception in interrupt
[184902.322746] Rebooting in 60 seconds..

Ok, it's taken be _ages_ to get the system to a point I can reproduce this, but I think it's now 
reproducible with a couple of hours beating. The bad news is it looks like it has not tickled any of 
your debugging markers! This was the 1st thing printed on a clean serial console, so nothing above 
that for days.


I did double check and I was/am certainly running the kernel with the debug 
patch compiled in.

Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [mmc] alternative TI FM MMC/SD driver for 2.6.21-rc7

[Brad Campbell]

Alex Dubov wrote:

Have you looked at the last version (0.8)? It fixed all outstanding issues (as 
far as I know).



Seconded. I've been running Alex's latest driver since its release. I routinely suspend/resume 
60-100 times between boots to S3 and disk, I've suspended with cards in the socket and I've tested 
it using SD and MMC .. I've not been able to fault it now. In fact, checking my mail archives, my 
last reported bug was on the 17th of Feb and it has been rock solid since. I just don't think about 
it anymore, it simply works...


Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [mmc] alternative TI FM MMC/SD driver for 2.6.21-rc7

[Brad Campbell]

Alex Dubov wrote:

Have you looked at the last version (0.8)? It fixed all outstanding issues (as 
far as I know).



Seconded. I've been running Alex's latest driver since its release. I routinely suspend/resume 
60-100 times between boots to S3 and disk, I've suspended with cards in the socket and I've tested 
it using SD and MMC .. I've not been able to fault it now. In fact, checking my mail archives, my 
last reported bug was on the 17th of Feb and it has been rock solid since. I just don't think about 
it anymore, it simply works...


Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

Jens Axboe wrote:


I had something similar for generic_unplug_request() as well, but didn't
see/hear any reports of it being tried out. Here's a complete debugging
patch for this and other potential dangers.



I had a clean 2.6.21-rc7 that I forgot to change the default sched on take down my main server last 
night. Another oops of the same variety. Unfortunately only a digital photo to go by though.


I've removed Neil's patch, applied yours and fired it up on my 4 drive test box (the one that was 
causing the trouble before). I've finally scrounged another machine for a serial logger and I'll 
beat it until it breaks. Perhaps if I can get this to reliably trigger again we can track it down.


Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

Jens Axboe wrote:


I had something similar for generic_unplug_request() as well, but didn't
see/hear any reports of it being tried out. Here's a complete debugging
patch for this and other potential dangers.



I had a clean 2.6.21-rc7 that I forgot to change the default sched on take down my main server last 
night. Another oops of the same variety. Unfortunately only a digital photo to go by though.


I've removed Neil's patch, applied yours and fired it up on my 4 drive test box (the one that was 
causing the trouble before). I've finally scrounged another machine for a serial logger and I'll 
beat it until it breaks. Perhaps if I can get this to reliably trigger again we can track it down.


Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

Neil Brown wrote:

On Monday April 16, [EMAIL PROTECTED] wrote:

cfq_dispatch_insert() was called with rq == 0. This one is getting really
annoying... and md is involved again (RAID0 this time.)


Yeah... weird.
RAID0 is so light-weight and so different from RAID1 or RAID5 that I
feel fairly safe concluding that the problem isn't in or near md.


Just a quick thought. Could this issue in any way cause silent data corruption 
on write to the md?

I've been chasing a bug for months now on this box which resulted in a small bit of seemingly random 
corruption in large copies to /dev/md0. Problem is, I changed the PSU in the box (which appeared to 
help a little) but then about the same time I discovered the oops was in cfq so changed the 
scheduler also. I've not been able to oops or reproduce the data corruption since.


I've now got to go back to cfq and see if I can get it to panic reproducibly again, but I'm 
wondering now if there may have been another issue there.


Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

Neil Brown wrote:

On Monday April 16, [EMAIL PROTECTED] wrote:

cfq_dispatch_insert() was called with rq == 0. This one is getting really
annoying... and md is involved again (RAID0 this time.)


Yeah... weird.
RAID0 is so light-weight and so different from RAID1 or RAID5 that I
feel fairly safe concluding that the problem isn't in or near md.
But that doesn't help you.


It's raid-5 here and it was degraded. I've just added the extra disk now and I've been running with 
the deadline scheduler to work around the issue. I'll add Neil's patch and try some tests with cfq 
tonight if I get the chance.


Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

Neil Brown wrote:

On Monday April 16, [EMAIL PROTECTED] wrote:

cfq_dispatch_insert() was called with rq == 0. This one is getting really
annoying... and md is involved again (RAID0 this time.)


Yeah... weird.
RAID0 is so light-weight and so different from RAID1 or RAID5 that I
feel fairly safe concluding that the problem isn't in or near md.
But that doesn't help you.


It's raid-5 here and it was degraded. I've just added the extra disk now and I've been running with 
the deadline scheduler to work around the issue. I'll add Neil's patch and try some tests with cfq 
tonight if I get the chance.


Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

Neil Brown wrote:

On Monday April 16, [EMAIL PROTECTED] wrote:

cfq_dispatch_insert() was called with rq == 0. This one is getting really
annoying... and md is involved again (RAID0 this time.)


Yeah... weird.
RAID0 is so light-weight and so different from RAID1 or RAID5 that I
feel fairly safe concluding that the problem isn't in or near md.


Just a quick thought. Could this issue in any way cause silent data corruption 
on write to the md?

I've been chasing a bug for months now on this box which resulted in a small bit of seemingly random 
corruption in large copies to /dev/md0. Problem is, I changed the PSU in the box (which appeared to 
help a little) but then about the same time I discovered the oops was in cfq so changed the 
scheduler also. I've not been able to oops or reproduce the data corruption since.


I've now got to go back to cfq and see if I can get it to panic reproducibly again, but I'm 
wondering now if there may have been another issue there.


Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

Adrian Bunk wrote:

[ Cc's added, additional information is in http://lkml.org/lkml/2007/4/15/32 ]

On Sun, Apr 15, 2007 at 02:49:29PM +0400, Brad Campbell wrote:

Brad Campbell wrote:

G'day all,

All I have is a digital photo of this oops. (It's 3.5mb). I have serial 
console configured, but Murphy is watching me carefully and I just can't 
seem to reproduce it while logging the console output.


And as usual, after trying to capture one for 4 days, I get one 10 mins 
after I've sent the E-mail :)


I think I've just found a way to make this easier to reproduce as /dev/sdd 
was not even mounted this
time. I just cold booted and started an md5sum -c run on a directory of 
about 180GB.



Is this also present with kernel 2.6.20 or is it a regression?



Yes, I reproduced it with 2.6.20 but appear to be unable to do so with 2.6.19.



--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

Brad Campbell wrote:

G'day all,

All I have is a digital photo of this oops. (It's 3.5mb). I have serial 
console configured, but Murphy is watching me carefully and I just can't 
seem to reproduce it while logging the console output.




And as usual, after trying to capture one for 4 days, I get one 10 mins after 
I've sent the E-mail :)

I think I've just found a way to make this easier to reproduce as /dev/sdd was 
not even mounted this
time. I just cold booted and started an md5sum -c run on a directory of about 
180GB.

[ 2566.192665] BUG: unable to handle kernel NULL pointer dereference at virtual 
address 005c
[ 2566.218242]  printing eip:
[ 2566.226362] c0203169
[ 2566.232906] *pde = 
[ 2566.241274] Oops:  [#1]
[ 2566.249637] Modules linked in:
[ 2566.258832] CPU:0
[ 2566.258833] EIP:0060:[]Not tainted VLI
[ 2566.258834] EFLAGS: 00010082   (2.6.21-rc6-git5 #1)
[ 2566.296146] EIP is at cfq_dispatch_insert+0x19/0x70
[ 2566.310761] eax: f7a0eae0   ebx: f7a0cb28   ecx: e2f869e8   edx: 
[ 2566.331076] esi: f79fea7c   edi: f7d04ac0   ebp:    esp: f6945de0
[ 2566.351388] ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
[ 2566.368843] Process md5sum (pid: 2875, ti=f6944000 task=f68f4ad0 
task.ti=f6944000)
[ 2566.390975] Stack:  f79fea7c f7d04ac0  c02032d9 f6ae5ef0 
c0133411 1000
[ 2566.416414]0008  0004 0b582fd4 f79fea7c f7d04ac0 
f79fea7c 
[ 2566.441870]c0203519 f7a0cb28 f7a0cb28 f79e 0282 c01fb7a9 
 c016ea4d
[ 2566.467326] Call Trace:
[ 2566.475236]  [] __cfq_dispatch_requests+0x79/0x170
[ 2566.492224]  [] do_generic_mapping_read+0x281/0x470
[ 2566.509473]  [] cfq_dispatch_requests+0x69/0x90
[ 2566.525681]  [] elv_next_request+0x39/0x130
[ 2566.540850]  [] bio_endio+0x5d/0x90
[ 2566.553942]  [] scsi_request_fn+0x45/0x280
[ 2566.568851]  [] blk_run_queue+0x32/0x70
[ 2566.582982]  [] scsi_next_command+0x30/0x50
[ 2566.598154]  [] scsi_end_request+0x9b/0xc0
[ 2566.613063]  [] scsi_io_completion+0x81/0x330
[ 2566.628751]  [] scsi_delete_timer+0xb/0x20
[ 2566.643661]  [] ata_scsi_qc_complete+0x65/0xd0
[ 2566.659613]  [] sd_rw_intr+0x8b/0x220
[ 2566.673222]  [] ata_altstatus+0x1c/0x20
[ 2566.687352]  [] ata_hsm_move+0x14d/0x3f0
[ 2566.701744]  [] scsi_finish_command+0x40/0x60
[ 2566.717434]  [] scsi_softirq_done+0x6f/0xe0
[ 2566.732604]  [] sil_interrupt+0x81/0x90
[ 2566.746733]  [] blk_done_softirq+0x58/0x70
[ 2566.761644]  [] __do_softirq+0x6f/0x80
[ 2566.775516]  [] do_softirq+0x27/0x30
[ 2566.788866]  [] do_IRQ+0x3e/0x80
[ 2566.801177]  [] common_interrupt+0x23/0x28
[ 2566.816090]  ===
[ 2566.826793] Code: 3e 05 f0 ff e9 47 ff ff ff 89 f6 8d bc 27 00 00 00 00 83 
ec 10 89 1c 24 89 6c
24 0c 89 74 24 04 89 7c 24 08 89 c3 89 d5 8b 40 0c <8b> 72 5c 8b 78 04 89 d0 e8 
4a fa ff ff 8b 45 14
89 ea 25 01 80
[ 2566.886586] EIP: [] cfq_dispatch_insert+0x19/0x70 SS:ESP 
0068:f6945de0
[ 2566.909179] Kernel panic - not syncing: Fatal exception in interrupt

--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

G'day all,

All I have is a digital photo of this oops. (It's 3.5mb). I have serial console configured, but 
Murphy is watching me carefully and I just can't seem to reproduce it while logging the console output.


http://www.fnarfbargle.com/CIMG0736.JPG

I had it die the same way using plain 2.6.21-rc6 also.

This has happened about 7 times on this box now, it's always pretty much the same oops. The box has 
passed memtest and I've used it for a while in a slightly different configuration.


This oops is very difficult to reproduce and generally involves me running rsync -c or md5sum on a 
large series of files (usually 80-180GB) before it'll go *pop*.


The box is booted with PXE and runs an nfsroot. It's Debian 3.1. It has 2 SIL 3112 controllers in it 
with 4 WD 200GB ATA drives all on PATA->SATA bridges.


sd[abc] are all part of md0. md0 is ext3. sdd1 is formatted ext2. sdd has 5 bad blocks currently and 
I'm in the process of copying the data from sdd to md0 prior to reallocating those blocks. It's 
usually in rsync runs or post copy md5 checks that the box dies, but it can take 24 hours of beating 
to get it to panic. Unfortunately, it only panics when I'm not about and have my laptop with me 
(which I use to log the serial console).


dmesg, config and other hardware details attached.

I kinda need to get this box in service, but if there is any testing I can perform to help chase 
this down I'll leave it as-is.


Regards,
Brad


[0.00] Linux version 2.6.21-rc6-git5 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #1 
Sat Apr 14 12:09:50 GST 2007

[0.00] BIOS-provided physical RAM map:
[0.00] sanitize start
[0.00] sanitize end
[0.00] copy_e820_map() start:  size: 0009f400 end: 0009f400 
type: 1

[0.00] copy_e820_map() type is E820_RAM
[0.00] copy_e820_map() start: 0009f400 size: 0c00 end: 000a 
type: 2
[0.00] copy_e820_map() start: 000f size: 0001 end: 0010 
type: 2
[0.00] copy_e820_map() start: 0010 size: 3fef end: 3fff 
type: 1

[0.00] copy_e820_map() type is E820_RAM
[0.00] copy_e820_map() start: 3fff size: 3000 end: 3fff3000 
type: 4
[0.00] copy_e820_map() start: 3fff3000 size: d000 end: 4000 
type: 3
[0.00] copy_e820_map() start: fec0 size: 1000 end: fec01000 
type: 2
[0.00] copy_e820_map() start: fee0 size: 1000 end: fee01000 
type: 2
[0.00] copy_e820_map() start:  size: 0001 end: 0001 
type: 2

[0.00]  BIOS-e820:  - 0009f400 (usable)
[0.00]  BIOS-e820: 0009f400 - 000a (reserved)
[0.00]  BIOS-e820: 000f - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - 3fff (usable)
[0.00]  BIOS-e820: 3fff - 3fff3000 (ACPI NVS)
[0.00]  BIOS-e820: 3fff3000 - 4000 (ACPI data)
[0.00]  BIOS-e820: fec0 - fec01000 (reserved)
[0.00]  BIOS-e820: fee0 - fee01000 (reserved)
[0.00]  BIOS-e820:  - 0001 (reserved)
[0.00] 127MB HIGHMEM available.
[0.00] 896MB LOWMEM available.
[0.00] found SMP MP-table at 000f52d0
[0.00] Entering add_active_range(0, 0, 262128) 0 entries of 256 used
[0.00] Zone PFN ranges:
[0.00]   DMA 0 -> 4096
[0.00]   Normal   4096 ->   229376
[0.00]   HighMem229376 ->   262128
[0.00] early_node_map[1] active PFN ranges
[0.00] 0:0 ->   262128
[0.00] On node 0 totalpages: 262128
[0.00]   DMA zone: 32 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 4064 pages, LIFO batch:0
[0.00]   Normal zone: 1760 pages used for memmap
[0.00]   Normal zone: 223520 pages, LIFO batch:31
[0.00]   HighMem zone: 255 pages used for memmap
[0.00]   HighMem zone: 32497 pages, LIFO batch:7
[0.00] DMI 2.3 present.
[0.00] ACPI: RSDP 000F6D90, 0014 (r0 KM266 )
[0.00] ACPI: RSDT 3FFF3000, 002C (r1 KM266  AWRDACPI 42302E31 AWRD   0)
[0.00] ACPI: FACP 3FFF3040, 0074 (r1 KM266  AWRDACPI 42302E31 AWRD   0)
[0.00] ACPI: DSDT 3FFF30C0, 4E67 (r1 KM266  AWRDACPI 1000 MSFT  
10E)
[0.00] ACPI: FACS 3FFF, 0040
[0.00] ACPI: APIC 3FFF7F40, 005A (r1 KM266  AWRDACPI 42302E31 AWRD   0)
[0.00] ACPI: PM-Timer IO Port: 0x4008
[0.00] ACPI: Local APIC address 0xfee0
[0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[0.00] Processor #0 6:8 APIC 

Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

Adrian Bunk wrote:

[ Cc's added, additional information is in http://lkml.org/lkml/2007/4/15/32 ]

On Sun, Apr 15, 2007 at 02:49:29PM +0400, Brad Campbell wrote:

Brad Campbell wrote:

G'day all,

All I have is a digital photo of this oops. (It's 3.5mb). I have serial 
console configured, but Murphy is watching me carefully and I just can't 
seem to reproduce it while logging the console output.


And as usual, after trying to capture one for 4 days, I get one 10 mins 
after I've sent the E-mail :)


I think I've just found a way to make this easier to reproduce as /dev/sdd 
was not even mounted this
time. I just cold booted and started an md5sum -c run on a directory of 
about 180GB.



Is this also present with kernel 2.6.20 or is it a regression?



Yes, I reproduced it with 2.6.20 but appear to be unable to do so with 2.6.19.



--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

G'day all,

All I have is a digital photo of this oops. (It's 3.5mb). I have serial console configured, but 
Murphy is watching me carefully and I just can't seem to reproduce it while logging the console output.


http://www.fnarfbargle.com/CIMG0736.JPG

I had it die the same way using plain 2.6.21-rc6 also.

This has happened about 7 times on this box now, it's always pretty much the same oops. The box has 
passed memtest and I've used it for a while in a slightly different configuration.


This oops is very difficult to reproduce and generally involves me running rsync -c or md5sum on a 
large series of files (usually 80-180GB) before it'll go *pop*.


The box is booted with PXE and runs an nfsroot. It's Debian 3.1. It has 2 SIL 3112 controllers in it 
with 4 WD 200GB ATA drives all on PATA-SATA bridges.


sd[abc] are all part of md0. md0 is ext3. sdd1 is formatted ext2. sdd has 5 bad blocks currently and 
I'm in the process of copying the data from sdd to md0 prior to reallocating those blocks. It's 
usually in rsync runs or post copy md5 checks that the box dies, but it can take 24 hours of beating 
to get it to panic. Unfortunately, it only panics when I'm not about and have my laptop with me 
(which I use to log the serial console).


dmesg, config and other hardware details attached.

I kinda need to get this box in service, but if there is any testing I can perform to help chase 
this down I'll leave it as-is.


Regards,
Brad


[0.00] Linux version 2.6.21-rc6-git5 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #1 
Sat Apr 14 12:09:50 GST 2007

[0.00] BIOS-provided physical RAM map:
[0.00] sanitize start
[0.00] sanitize end
[0.00] copy_e820_map() start:  size: 0009f400 end: 0009f400 
type: 1

[0.00] copy_e820_map() type is E820_RAM
[0.00] copy_e820_map() start: 0009f400 size: 0c00 end: 000a 
type: 2
[0.00] copy_e820_map() start: 000f size: 0001 end: 0010 
type: 2
[0.00] copy_e820_map() start: 0010 size: 3fef end: 3fff 
type: 1

[0.00] copy_e820_map() type is E820_RAM
[0.00] copy_e820_map() start: 3fff size: 3000 end: 3fff3000 
type: 4
[0.00] copy_e820_map() start: 3fff3000 size: d000 end: 4000 
type: 3
[0.00] copy_e820_map() start: fec0 size: 1000 end: fec01000 
type: 2
[0.00] copy_e820_map() start: fee0 size: 1000 end: fee01000 
type: 2
[0.00] copy_e820_map() start:  size: 0001 end: 0001 
type: 2

[0.00]  BIOS-e820:  - 0009f400 (usable)
[0.00]  BIOS-e820: 0009f400 - 000a (reserved)
[0.00]  BIOS-e820: 000f - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - 3fff (usable)
[0.00]  BIOS-e820: 3fff - 3fff3000 (ACPI NVS)
[0.00]  BIOS-e820: 3fff3000 - 4000 (ACPI data)
[0.00]  BIOS-e820: fec0 - fec01000 (reserved)
[0.00]  BIOS-e820: fee0 - fee01000 (reserved)
[0.00]  BIOS-e820:  - 0001 (reserved)
[0.00] 127MB HIGHMEM available.
[0.00] 896MB LOWMEM available.
[0.00] found SMP MP-table at 000f52d0
[0.00] Entering add_active_range(0, 0, 262128) 0 entries of 256 used
[0.00] Zone PFN ranges:
[0.00]   DMA 0 - 4096
[0.00]   Normal   4096 -   229376
[0.00]   HighMem229376 -   262128
[0.00] early_node_map[1] active PFN ranges
[0.00] 0:0 -   262128
[0.00] On node 0 totalpages: 262128
[0.00]   DMA zone: 32 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 4064 pages, LIFO batch:0
[0.00]   Normal zone: 1760 pages used for memmap
[0.00]   Normal zone: 223520 pages, LIFO batch:31
[0.00]   HighMem zone: 255 pages used for memmap
[0.00]   HighMem zone: 32497 pages, LIFO batch:7
[0.00] DMI 2.3 present.
[0.00] ACPI: RSDP 000F6D90, 0014 (r0 KM266 )
[0.00] ACPI: RSDT 3FFF3000, 002C (r1 KM266  AWRDACPI 42302E31 AWRD   0)
[0.00] ACPI: FACP 3FFF3040, 0074 (r1 KM266  AWRDACPI 42302E31 AWRD   0)
[0.00] ACPI: DSDT 3FFF30C0, 4E67 (r1 KM266  AWRDACPI 1000 MSFT  
10E)
[0.00] ACPI: FACS 3FFF, 0040
[0.00] ACPI: APIC 3FFF7F40, 005A (r1 KM266  AWRDACPI 42302E31 AWRD   0)
[0.00] ACPI: PM-Timer IO Port: 0x4008
[0.00] ACPI: Local APIC address 0xfee0
[0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[0.00] Processor #0 6:8 APIC version 16

Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert

[Brad Campbell]

Brad Campbell wrote:

G'day all,

All I have is a digital photo of this oops. (It's 3.5mb). I have serial 
console configured, but Murphy is watching me carefully and I just can't 
seem to reproduce it while logging the console output.




And as usual, after trying to capture one for 4 days, I get one 10 mins after 
I've sent the E-mail :)

I think I've just found a way to make this easier to reproduce as /dev/sdd was 
not even mounted this
time. I just cold booted and started an md5sum -c run on a directory of about 
180GB.

[ 2566.192665] BUG: unable to handle kernel NULL pointer dereference at virtual 
address 005c
[ 2566.218242]  printing eip:
[ 2566.226362] c0203169
[ 2566.232906] *pde = 
[ 2566.241274] Oops:  [#1]
[ 2566.249637] Modules linked in:
[ 2566.258832] CPU:0
[ 2566.258833] EIP:0060:[c0203169]Not tainted VLI
[ 2566.258834] EFLAGS: 00010082   (2.6.21-rc6-git5 #1)
[ 2566.296146] EIP is at cfq_dispatch_insert+0x19/0x70
[ 2566.310761] eax: f7a0eae0   ebx: f7a0cb28   ecx: e2f869e8   edx: 
[ 2566.331076] esi: f79fea7c   edi: f7d04ac0   ebp:    esp: f6945de0
[ 2566.351388] ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
[ 2566.368843] Process md5sum (pid: 2875, ti=f6944000 task=f68f4ad0 
task.ti=f6944000)
[ 2566.390975] Stack:  f79fea7c f7d04ac0  c02032d9 f6ae5ef0 
c0133411 1000
[ 2566.416414]0008  0004 0b582fd4 f79fea7c f7d04ac0 
f79fea7c 
[ 2566.441870]c0203519 f7a0cb28 f7a0cb28 f79e 0282 c01fb7a9 
 c016ea4d
[ 2566.467326] Call Trace:
[ 2566.475236]  [c02032d9] __cfq_dispatch_requests+0x79/0x170
[ 2566.492224]  [c0133411] do_generic_mapping_read+0x281/0x470
[ 2566.509473]  [c0203519] cfq_dispatch_requests+0x69/0x90
[ 2566.525681]  [c01fb7a9] elv_next_request+0x39/0x130
[ 2566.540850]  [c016ea4d] bio_endio+0x5d/0x90
[ 2566.553942]  [c0268635] scsi_request_fn+0x45/0x280
[ 2566.568851]  [c01fdde2] blk_run_queue+0x32/0x70
[ 2566.582982]  [c0267ba0] scsi_next_command+0x30/0x50
[ 2566.598154]  [c0267c8b] scsi_end_request+0x9b/0xc0
[ 2566.613063]  [c0267df1] scsi_io_completion+0x81/0x330
[ 2566.628751]  [c0265dab] scsi_delete_timer+0xb/0x20
[ 2566.643661]  [c02770f5] ata_scsi_qc_complete+0x65/0xd0
[ 2566.659613]  [c026d47b] sd_rw_intr+0x8b/0x220
[ 2566.673222]  [c0278ecc] ata_altstatus+0x1c/0x20
[ 2566.687352]  [c027394d] ata_hsm_move+0x14d/0x3f0
[ 2566.701744]  [c0263f80] scsi_finish_command+0x40/0x60
[ 2566.717434]  [c026857f] scsi_softirq_done+0x6f/0xe0
[ 2566.732604]  [c027d521] sil_interrupt+0x81/0x90
[ 2566.746733]  [c01ff9b8] blk_done_softirq+0x58/0x70
[ 2566.761644]  [c011721f] __do_softirq+0x6f/0x80
[ 2566.775516]  [c0117257] do_softirq+0x27/0x30
[ 2566.788866]  [c0104cee] do_IRQ+0x3e/0x80
[ 2566.801177]  [c010322f] common_interrupt+0x23/0x28
[ 2566.816090]  ===
[ 2566.826793] Code: 3e 05 f0 ff e9 47 ff ff ff 89 f6 8d bc 27 00 00 00 00 83 
ec 10 89 1c 24 89 6c
24 0c 89 74 24 04 89 7c 24 08 89 c3 89 d5 8b 40 0c 8b 72 5c 8b 78 04 89 d0 e8 
4a fa ff ff 8b 45 14
89 ea 25 01 80
[ 2566.886586] EIP: [c0203169] cfq_dispatch_insert+0x19/0x70 SS:ESP 
0068:f6945de0
[ 2566.909179] Kernel panic - not syncing: Fatal exception in interrupt

--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add a norecovery option to ext3/4?

[Brad Campbell]

Eric Sandeen wrote:

Samuel Thibault wrote:

Hi,

Distribution installers usually try to probe OSes for building a suited
grub menu.  Unfortunately, mounting an ext3 partition, even in read-only
mode, does perform some operations on the filesystem (log recovery).
This is not a good idea since it may silently garbage data.  


Can you elaborate?  Under what circumstances is log replay going to harm 
data?  Do you mean that the installer mounts partitions, looking for 
what OS is installed?  How is that harmful?




It'll wreak havoc on my hibernated system when I've suspended it to do a test OS install on one of 
my spare partitions. The log replay will go fine, but then when the system resumes it's idea of 
what's on the disk won't match what is really there and ugly, ugly things happen.



Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add a norecovery option to ext3/4?

[Brad Campbell]

Eric Sandeen wrote:

Samuel Thibault wrote:

Hi,

Distribution installers usually try to probe OSes for building a suited
grub menu.  Unfortunately, mounting an ext3 partition, even in read-only
mode, does perform some operations on the filesystem (log recovery).
This is not a good idea since it may silently garbage data.  


Can you elaborate?  Under what circumstances is log replay going to harm 
data?  Do you mean that the installer mounts partitions, looking for 
what OS is installed?  How is that harmful?




It'll wreak havoc on my hibernated system when I've suspended it to do a test OS install on one of 
my spare partitions. The log replay will go fine, but then when the system resumes it's idea of 
what's on the disk won't match what is really there and ugly, ugly things happen.



Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NAK new drivers without proper power management?

[Brad Campbell]

Willy Tarreau wrote:


Probably that you got the wrong laptop. If you buy an ultra-thin with highly
proprietary hardware, it may be hard. But if you choose in profesionnal ranges,
there is rarely any problem. I have a compaq nc8000 on which everything works
fine, and it boots in about 20 seconds. Other people I know have Toshibas,
NECs, Dells and IBMs and are happy with them. My previous VAIO was a dirty
crap that I would never recommend to anybody though.


Whereas my "ultru-thin" VAIO works perfectly with both S2D and S2R and the only thing I have some 
difficulty with is the SD reader. Would not hesitate to recommend it to anyone.


I often hibernate linux to boot into a hibernated windows session, then go back the other way as 
required, and my machine might do 80-100 "suspend2both" sessions a month between reboots. 30-40 
seconds to suspend mostly (1.5GB of RAM) and about 15 to come back. That's what I call highly useful.


Different strokes and all that I guess..

Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NAK new drivers without proper power management?

[Brad Campbell]

Willy Tarreau wrote:


Probably that you got the wrong laptop. If you buy an ultra-thin with highly
proprietary hardware, it may be hard. But if you choose in profesionnal ranges,
there is rarely any problem. I have a compaq nc8000 on which everything works
fine, and it boots in about 20 seconds. Other people I know have Toshibas,
NECs, Dells and IBMs and are happy with them. My previous VAIO was a dirty
crap that I would never recommend to anybody though.


Whereas my ultru-thin VAIO works perfectly with both S2D and S2R and the only thing I have some 
difficulty with is the SD reader. Would not hesitate to recommend it to anyone.


I often hibernate linux to boot into a hibernated windows session, then go back the other way as 
required, and my machine might do 80-100 suspend2both sessions a month between reboots. 30-40 
seconds to suspend mostly (1.5GB of RAM) and about 15 to come back. That's what I call highly useful.


Different strokes and all that I guess..

Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent and not-so problems with tifm_sd driver - one more

[Brad Campbell]

Pierre Ossman wrote:

Brad Campbell wrote:

[EMAIL PROTECTED]:/sys/block/mmcblk0$ ls -laR
.:
total 0
drwxr-xr-x  6 root root0 2007-02-11 23:29 .
drwxr-xr-x 13 root root0 2007-02-11 23:27 ..
-r--r--r--  1 root root 4096 2007-02-11 23:28 dev
lrwxrwxrwx  1 root root0 2007-02-11 23:27 device ->
../../class/mmc_host/mmc0/mmc0:b368


Is this with CONFIG_SYSFS_DEPRECATED off? It should be pointing to the
../../devices tree.

Rgds


No, it's currently on. I'll recompile and do a dump with it off this evening. Either way, it's still 
broken and in 2.6.19 it wasn't.


Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent and not-so problems with tifm_sd driver - one more

[Brad Campbell]

Pierre Ossman wrote:

Brad Campbell wrote:

[EMAIL PROTECTED]:/sys/block/mmcblk0$ ls -laR
.:
total 0
drwxr-xr-x  6 root root0 2007-02-11 23:29 .
drwxr-xr-x 13 root root0 2007-02-11 23:27 ..
-r--r--r--  1 root root 4096 2007-02-11 23:28 dev
lrwxrwxrwx  1 root root0 2007-02-11 23:27 device -
../../class/mmc_host/mmc0/mmc0:b368


Is this with CONFIG_SYSFS_DEPRECATED off? It should be pointing to the
../../devices tree.

Rgds


No, it's currently on. I'll recompile and do a dump with it off this evening. Either way, it's still 
broken and in 2.6.19 it wasn't.


Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent and not-so problems with tifm_sd driver - one more

[Brad Campbell]

Pierre Ossman wrote:

Brad Campbell wrote:

[EMAIL PROTECTED]:/$ find sys/devices | grep mmc
sys/devices/pci:00/:00:1e.0/:06:05.3/tifm_sd0:3/mmc_host:mmc0



This is strange. You should be getting more entries below that.


I believe that should be the case..


/sys/block/mmcblk0/device



[EMAIL PROTECTED]:/sys/block/mmcblk0$ ls -laR
.:
total 0
drwxr-xr-x  6 root root0 2007-02-11 23:29 .
drwxr-xr-x 13 root root0 2007-02-11 23:27 ..
-r--r--r--  1 root root 4096 2007-02-11 23:28 dev
lrwxrwxrwx  1 root root0 2007-02-11 23:27 device -> 
../../class/mmc_host/mmc0/mmc0:b368
drwxr-xr-x  2 root root0 2007-02-11 23:27 holders
drwxr-xr-x  3 root root0 2007-02-11 23:29 mmcblk0p1
drwxr-xr-x  3 root root0 2007-02-11 23:27 queue
-r--r--r--  1 root root 4096 2007-02-11 23:29 range
-r--r--r--  1 root root 4096 2007-02-11 23:27 removable
-r--r--r--  1 root root 4096 2007-02-11 23:29 size
drwxr-xr-x  2 root root0 2007-02-11 23:27 slaves
-r--r--r--  1 root root 4096 2007-02-11 23:29 stat
lrwxrwxrwx  1 root root0 2007-02-11 23:27 subsystem -> ../../block
--w---  1 root root 4096 2007-02-11 23:29 uevent

./holders:
total 0
drwxr-xr-x 2 root root 0 2007-02-11 23:27 .
drwxr-xr-x 6 root root 0 2007-02-11 23:29 ..

./mmcblk0p1:
total 0
drwxr-xr-x 3 root root0 2007-02-11 23:29 .
drwxr-xr-x 6 root root0 2007-02-11 23:29 ..
-r--r--r-- 1 root root 4096 2007-02-11 23:29 dev
drwxr-xr-x 2 root root0 2007-02-11 23:27 holders
-r--r--r-- 1 root root 4096 2007-02-11 23:29 size
-r--r--r-- 1 root root 4096 2007-02-11 23:29 start
-r--r--r-- 1 root root 4096 2007-02-11 23:29 stat
lrwxrwxrwx 1 root root0 2007-02-11 23:29 subsystem -> ../../../block
--w--- 1 root root 4096 2007-02-11 23:29 uevent

./mmcblk0p1/holders:
total 0
drwxr-xr-x 2 root root 0 2007-02-11 23:27 .
drwxr-xr-x 3 root root 0 2007-02-11 23:29 ..

./queue:
total 0
drwxr-xr-x 3 root root0 2007-02-11 23:27 .
drwxr-xr-x 6 root root0 2007-02-11 23:29 ..
drwxr-xr-x 2 root root0 2007-02-11 23:27 iosched
-r--r--r-- 1 root root 4096 2007-02-11 23:29 max_hw_sectors_kb
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 max_sectors_kb
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 nr_requests
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 read_ahead_kb
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 scheduler

./queue/iosched:
total 0
drwxr-xr-x 2 root root0 2007-02-11 23:27 .
drwxr-xr-x 3 root root0 2007-02-11 23:29 ..
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 back_seek_max
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 back_seek_penalty
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 fifo_expire_async
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 fifo_expire_sync
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 quantum
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 slice_async
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 slice_async_rq
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 slice_idle
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 slice_sync

./slaves:
total 0
drwxr-xr-x 2 root root 0 2007-02-11 23:27 .
drwxr-xr-x 6 root root 0 2007-02-11 23:29 ..

[EMAIL PROTECTED]:/sys/block/mmcblk0$ cd device
[EMAIL PROTECTED]:/sys/block/mmcblk0/device$ ls -laR
.:
total 0
drwxr-xr-x 3 root root0 2007-02-11 23:30 .
drwxr-xr-x 4 root root0 2007-02-11 23:27 ..
lrwxrwxrwx 1 root root0 2007-02-11 23:30 block:mmcblk0 -> 
../../../../block/mmcblk0
lrwxrwxrwx 1 root root0 2007-02-11 23:30 bus -> ../../../../bus/mmc
-r--r--r-- 1 root root 4096 2007-02-11 23:30 cid
-r--r--r-- 1 root root 4096 2007-02-11 23:30 csd
-r--r--r-- 1 root root 4096 2007-02-11 23:30 date
lrwxrwxrwx 1 root root0 2007-02-11 23:27 driver -> 
../../../../bus/mmc/drivers/mmcblk
-r--r--r-- 1 root root 4096 2007-02-11 23:30 fwrev
-r--r--r-- 1 root root 4096 2007-02-11 23:30 hwrev
-r--r--r-- 1 root root 4096 2007-02-11 23:30 manfid
-r--r--r-- 1 root root 4096 2007-02-11 23:30 name
-r--r--r-- 1 root root 4096 2007-02-11 23:30 oemid
drwxr-xr-x 2 root root0 2007-02-11 23:27 power
-r--r--r-- 1 root root 4096 2007-02-11 23:30 scr
-r--r--r-- 1 root root 4096 2007-02-11 23:30 serial
lrwxrwxrwx 1 root root0 2007-02-11 23:27 subsystem -> ../../../../bus/mmc
--w--- 1 root root 4096 2007-02-11 23:30 uevent

./power:
total 0
drwxr-xr-x 2 root root0 2007-02-11 23:27 .
drwxr-xr-x 3 root root0 2007-02-11 23:30 ..
-rw-r--r-- 1 root root 4096 2007-02-11 23:30 wakeup

Alex, it's still hit and miss getting this card detected. I had to insert/remove the card over 10 
times with random driver load/unloads until it created the device entries..


Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
P

Re: Recent and not-so problems with tifm_sd driver - one more

[Brad Campbell]

Pierre Ossman wrote:

Brad Campbell wrote:

I've tested both with and without CONFIG_SYSFS_DEPRECATED on, both fail
the same way.
hald reports that the device has no parent and decides to ignore it.



Works fine here. The device tree is:

/sys/devices/pnp0/00:02/mmc0/mmc0:0001/block:mmcblk0/mmcblk0p1/


Ok, following from that on my machine currently...

[EMAIL PROTECTED]:/$ ls /dev/mmc*
/dev/mmcblk0  /dev/mmcblk0p1

[EMAIL PROTECTED]:/$ find sys/devices | grep mmc
sys/devices/pci:00/:00:1e.0/:06:05.3/tifm_sd0:3/mmc_host:mmc0

[EMAIL PROTECTED]:/$ find /sys/block/ | grep mmc
/sys/block/mmcblk0
/sys/block/mmcblk0/queue
/sys/block/mmcblk0/queue/iosched
/sys/block/mmcblk0/queue/iosched/slice_idle
/sys/block/mmcblk0/queue/iosched/slice_async_rq
/sys/block/mmcblk0/queue/iosched/slice_async
/sys/block/mmcblk0/queue/iosched/slice_sync
/sys/block/mmcblk0/queue/iosched/back_seek_penalty
/sys/block/mmcblk0/queue/iosched/back_seek_max
/sys/block/mmcblk0/queue/iosched/fifo_expire_async
/sys/block/mmcblk0/queue/iosched/fifo_expire_sync
/sys/block/mmcblk0/queue/iosched/quantum
/sys/block/mmcblk0/queue/scheduler
/sys/block/mmcblk0/queue/max_sectors_kb
/sys/block/mmcblk0/queue/max_hw_sectors_kb
/sys/block/mmcblk0/queue/read_ahead_kb
/sys/block/mmcblk0/queue/nr_requests
/sys/block/mmcblk0/mmcblk0p1
/sys/block/mmcblk0/mmcblk0p1/holders
/sys/block/mmcblk0/mmcblk0p1/subsystem
/sys/block/mmcblk0/mmcblk0p1/stat
/sys/block/mmcblk0/mmcblk0p1/size
/sys/block/mmcblk0/mmcblk0p1/start
/sys/block/mmcblk0/mmcblk0p1/dev
/sys/block/mmcblk0/mmcblk0p1/uevent
/sys/block/mmcblk0/slaves
/sys/block/mmcblk0/holders
/sys/block/mmcblk0/subsystem
/sys/block/mmcblk0/device
/sys/block/mmcblk0/stat
/sys/block/mmcblk0/size
/sys/block/mmcblk0/removable
/sys/block/mmcblk0/range
/sys/block/mmcblk0/dev
/sys/block/mmcblk0/uevent

[EMAIL PROTECTED]:~$ zcat /proc/config.gz | grep CONFIG_SYSFS_DEPRECATED
CONFIG_SYSFS_DEPRECATED=y

[EMAIL PROTECTED]:~$ uname -a
Linux bklaptop2 2.6.20-git4-bkc1 #5 Sat Feb 10 23:49:52 GST 2007 i686 GNU/Linux

Not sure if any of this is relevant info, but none the less, I'm not a sysfs or 
hal guru.

Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent and not-so problems with tifm_sd driver - one more

[Brad Campbell]

Pierre Ossman wrote:

Brad Campbell wrote:

I've tested both with and without CONFIG_SYSFS_DEPRECATED on, both fail
the same way.
hald reports that the device has no parent and decides to ignore it.



Works fine here. The device tree is:

/sys/devices/pnp0/00:02/mmc0/mmc0:0001/block:mmcblk0/mmcblk0p1/


Ok, following from that on my machine currently...

[EMAIL PROTECTED]:/$ ls /dev/mmc*
/dev/mmcblk0  /dev/mmcblk0p1

[EMAIL PROTECTED]:/$ find sys/devices | grep mmc
sys/devices/pci:00/:00:1e.0/:06:05.3/tifm_sd0:3/mmc_host:mmc0

[EMAIL PROTECTED]:/$ find /sys/block/ | grep mmc
/sys/block/mmcblk0
/sys/block/mmcblk0/queue
/sys/block/mmcblk0/queue/iosched
/sys/block/mmcblk0/queue/iosched/slice_idle
/sys/block/mmcblk0/queue/iosched/slice_async_rq
/sys/block/mmcblk0/queue/iosched/slice_async
/sys/block/mmcblk0/queue/iosched/slice_sync
/sys/block/mmcblk0/queue/iosched/back_seek_penalty
/sys/block/mmcblk0/queue/iosched/back_seek_max
/sys/block/mmcblk0/queue/iosched/fifo_expire_async
/sys/block/mmcblk0/queue/iosched/fifo_expire_sync
/sys/block/mmcblk0/queue/iosched/quantum
/sys/block/mmcblk0/queue/scheduler
/sys/block/mmcblk0/queue/max_sectors_kb
/sys/block/mmcblk0/queue/max_hw_sectors_kb
/sys/block/mmcblk0/queue/read_ahead_kb
/sys/block/mmcblk0/queue/nr_requests
/sys/block/mmcblk0/mmcblk0p1
/sys/block/mmcblk0/mmcblk0p1/holders
/sys/block/mmcblk0/mmcblk0p1/subsystem
/sys/block/mmcblk0/mmcblk0p1/stat
/sys/block/mmcblk0/mmcblk0p1/size
/sys/block/mmcblk0/mmcblk0p1/start
/sys/block/mmcblk0/mmcblk0p1/dev
/sys/block/mmcblk0/mmcblk0p1/uevent
/sys/block/mmcblk0/slaves
/sys/block/mmcblk0/holders
/sys/block/mmcblk0/subsystem
/sys/block/mmcblk0/device
/sys/block/mmcblk0/stat
/sys/block/mmcblk0/size
/sys/block/mmcblk0/removable
/sys/block/mmcblk0/range
/sys/block/mmcblk0/dev
/sys/block/mmcblk0/uevent

[EMAIL PROTECTED]:~$ zcat /proc/config.gz | grep CONFIG_SYSFS_DEPRECATED
CONFIG_SYSFS_DEPRECATED=y

[EMAIL PROTECTED]:~$ uname -a
Linux bklaptop2 2.6.20-git4-bkc1 #5 Sat Feb 10 23:49:52 GST 2007 i686 GNU/Linux

Not sure if any of this is relevant info, but none the less, I'm not a sysfs or 
hal guru.

Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent and not-so problems with tifm_sd driver - one more

[Brad Campbell]

Pierre Ossman wrote:

Brad Campbell wrote:

[EMAIL PROTECTED]:/$ find sys/devices | grep mmc
sys/devices/pci:00/:00:1e.0/:06:05.3/tifm_sd0:3/mmc_host:mmc0



This is strange. You should be getting more entries below that.


I believe that should be the case..


/sys/block/mmcblk0/device



[EMAIL PROTECTED]:/sys/block/mmcblk0$ ls -laR
.:
total 0
drwxr-xr-x  6 root root0 2007-02-11 23:29 .
drwxr-xr-x 13 root root0 2007-02-11 23:27 ..
-r--r--r--  1 root root 4096 2007-02-11 23:28 dev
lrwxrwxrwx  1 root root0 2007-02-11 23:27 device - 
../../class/mmc_host/mmc0/mmc0:b368
drwxr-xr-x  2 root root0 2007-02-11 23:27 holders
drwxr-xr-x  3 root root0 2007-02-11 23:29 mmcblk0p1
drwxr-xr-x  3 root root0 2007-02-11 23:27 queue
-r--r--r--  1 root root 4096 2007-02-11 23:29 range
-r--r--r--  1 root root 4096 2007-02-11 23:27 removable
-r--r--r--  1 root root 4096 2007-02-11 23:29 size
drwxr-xr-x  2 root root0 2007-02-11 23:27 slaves
-r--r--r--  1 root root 4096 2007-02-11 23:29 stat
lrwxrwxrwx  1 root root0 2007-02-11 23:27 subsystem - ../../block
--w---  1 root root 4096 2007-02-11 23:29 uevent

./holders:
total 0
drwxr-xr-x 2 root root 0 2007-02-11 23:27 .
drwxr-xr-x 6 root root 0 2007-02-11 23:29 ..

./mmcblk0p1:
total 0
drwxr-xr-x 3 root root0 2007-02-11 23:29 .
drwxr-xr-x 6 root root0 2007-02-11 23:29 ..
-r--r--r-- 1 root root 4096 2007-02-11 23:29 dev
drwxr-xr-x 2 root root0 2007-02-11 23:27 holders
-r--r--r-- 1 root root 4096 2007-02-11 23:29 size
-r--r--r-- 1 root root 4096 2007-02-11 23:29 start
-r--r--r-- 1 root root 4096 2007-02-11 23:29 stat
lrwxrwxrwx 1 root root0 2007-02-11 23:29 subsystem - ../../../block
--w--- 1 root root 4096 2007-02-11 23:29 uevent

./mmcblk0p1/holders:
total 0
drwxr-xr-x 2 root root 0 2007-02-11 23:27 .
drwxr-xr-x 3 root root 0 2007-02-11 23:29 ..

./queue:
total 0
drwxr-xr-x 3 root root0 2007-02-11 23:27 .
drwxr-xr-x 6 root root0 2007-02-11 23:29 ..
drwxr-xr-x 2 root root0 2007-02-11 23:27 iosched
-r--r--r-- 1 root root 4096 2007-02-11 23:29 max_hw_sectors_kb
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 max_sectors_kb
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 nr_requests
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 read_ahead_kb
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 scheduler

./queue/iosched:
total 0
drwxr-xr-x 2 root root0 2007-02-11 23:27 .
drwxr-xr-x 3 root root0 2007-02-11 23:29 ..
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 back_seek_max
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 back_seek_penalty
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 fifo_expire_async
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 fifo_expire_sync
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 quantum
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 slice_async
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 slice_async_rq
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 slice_idle
-rw-r--r-- 1 root root 4096 2007-02-11 23:29 slice_sync

./slaves:
total 0
drwxr-xr-x 2 root root 0 2007-02-11 23:27 .
drwxr-xr-x 6 root root 0 2007-02-11 23:29 ..

[EMAIL PROTECTED]:/sys/block/mmcblk0$ cd device
[EMAIL PROTECTED]:/sys/block/mmcblk0/device$ ls -laR
.:
total 0
drwxr-xr-x 3 root root0 2007-02-11 23:30 .
drwxr-xr-x 4 root root0 2007-02-11 23:27 ..
lrwxrwxrwx 1 root root0 2007-02-11 23:30 block:mmcblk0 - 
../../../../block/mmcblk0
lrwxrwxrwx 1 root root0 2007-02-11 23:30 bus - ../../../../bus/mmc
-r--r--r-- 1 root root 4096 2007-02-11 23:30 cid
-r--r--r-- 1 root root 4096 2007-02-11 23:30 csd
-r--r--r-- 1 root root 4096 2007-02-11 23:30 date
lrwxrwxrwx 1 root root0 2007-02-11 23:27 driver - 
../../../../bus/mmc/drivers/mmcblk
-r--r--r-- 1 root root 4096 2007-02-11 23:30 fwrev
-r--r--r-- 1 root root 4096 2007-02-11 23:30 hwrev
-r--r--r-- 1 root root 4096 2007-02-11 23:30 manfid
-r--r--r-- 1 root root 4096 2007-02-11 23:30 name
-r--r--r-- 1 root root 4096 2007-02-11 23:30 oemid
drwxr-xr-x 2 root root0 2007-02-11 23:27 power
-r--r--r-- 1 root root 4096 2007-02-11 23:30 scr
-r--r--r-- 1 root root 4096 2007-02-11 23:30 serial
lrwxrwxrwx 1 root root0 2007-02-11 23:27 subsystem - ../../../../bus/mmc
--w--- 1 root root 4096 2007-02-11 23:30 uevent

./power:
total 0
drwxr-xr-x 2 root root0 2007-02-11 23:27 .
drwxr-xr-x 3 root root0 2007-02-11 23:30 ..
-rw-r--r-- 1 root root 4096 2007-02-11 23:30 wakeup

Alex, it's still hit and miss getting this card detected. I had to insert/remove the card over 10 
times with random driver load/unloads until it created the device entries..


Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent and not-so problems with tifm_sd driver - one more

[Brad Campbell]

Pierre Ossman wrote:

Alex Dubov wrote:

One more problem (you may already know about it) - I was contacted by somebody 
from the hald
project and indeed I can confirm that on 2.6.20 kernel hald fails to take 
action on card
insertion. I can't see anything in my code so this may be a general mmc problem.
The problem is described here:
http://lists.freedesktop.org/archives/hal/2007-January/006960.html



Odd. This might be the whole sysfs restructuring thing causing problems. Can you
check if that user has CONFIG_SYSFS_DEPRECATED on?


I've tested both with and without CONFIG_SYSFS_DEPRECATED on, both fail the 
same way.
hald reports that the device has no parent and decides to ignore it.

I've also tested both combinations against hal from ubuntu 6.06LTS and a more 
recent version

[EMAIL PROTECTED]:~$ hald --version
HAL package version: 0.5.8.1

Again with and without CONFIG_SYSFS_DEPRECATED and all combinations fail.
Hal appears to go looking for /sys/block/mmcblk0/mmcblk0p1/range

When it can't find it, it then looks for the parent of that to check what would be 
/sys/block/mmcblk0/range, Complains it can't find a parent for /sys/block/mmcblk0/mmcblk0p1 and just 
proceeds to ignore the event.


Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent and not-so problems with tifm_sd driver - one more

[Brad Campbell]

Pierre Ossman wrote:

Alex Dubov wrote:

One more problem (you may already know about it) - I was contacted by somebody 
from the hald
project and indeed I can confirm that on 2.6.20 kernel hald fails to take 
action on card
insertion. I can't see anything in my code so this may be a general mmc problem.
The problem is described here:
http://lists.freedesktop.org/archives/hal/2007-January/006960.html



Odd. This might be the whole sysfs restructuring thing causing problems. Can you
check if that user has CONFIG_SYSFS_DEPRECATED on?


I've tested both with and without CONFIG_SYSFS_DEPRECATED on, both fail the 
same way.
hald reports that the device has no parent and decides to ignore it.

I've also tested both combinations against hal from ubuntu 6.06LTS and a more 
recent version

[EMAIL PROTECTED]:~$ hald --version
HAL package version: 0.5.8.1

Again with and without CONFIG_SYSFS_DEPRECATED and all combinations fail.
Hal appears to go looking for /sys/block/mmcblk0/mmcblk0p1/range

When it can't find it, it then looks for the parent of that to check what would be 
/sys/block/mmcblk0/range, Complains it can't find a parent for /sys/block/mmcblk0/mmcblk0p1 and just 
proceeds to ignore the event.


Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: tifm_sd: Development website/mailing list?

[Brad Campbell]

Michael McConnell wrote:

Hello,

Is there a mailing list and/or a website tracing the development of the 
tifm_* drivers?  I've got a new Vaio that has this chipset for its SD 
card reader and would like to track this driver development (and maybe 
help with its development).




From the bottom of an E-mail from that list..
___
Tifm21-devel mailing list
[EMAIL PROTECTED]
https://lists.berlios.de/mailman/listinfo/tifm21-devel

Hope that helps.

Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: tifm_sd: Development website/mailing list?

[Brad Campbell]

Michael McConnell wrote:

Hello,

Is there a mailing list and/or a website tracing the development of the 
tifm_* drivers?  I've got a new Vaio that has this chipset for its SD 
card reader and would like to track this driver development (and maybe 
help with its development).




From the bottom of an E-mail from that list..
___
Tifm21-devel mailing list
[EMAIL PROTECTED]
https://lists.berlios.de/mailman/listinfo/tifm21-devel

Hope that helps.

Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problem with pata_hpt37x ...

[Brad Campbell]

Brad Campbell wrote:

Herbert Poetzl wrote:


sounds great! where can I get that version?
should it be in 2.6.20-rc* or is there a separate
patch available somewhere?


The patch was contained in the message from Alan to you that I replied 
to. I just applied it to a vanilla 2.6.20-rc3 tree and fired it up.




Just a warning. I'm seeing data corruption on this system. I need to try and narrow it down, but on 
transferring 100 files totalling about 80GB from a USB drive to the drives on this controller I'm 
seeing repeatable and apparently random corruption on the data reaching the disks. I don't recall 
seeing this when I used SIL controllers in place of the HPT but I now have an easily repeatable test 
case so I'll keep testing until I peg it.



Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problem with pata_hpt37x ...

[Brad Campbell]

Brad Campbell wrote:

Herbert Poetzl wrote:


sounds great! where can I get that version?
should it be in 2.6.20-rc* or is there a separate
patch available somewhere?


The patch was contained in the message from Alan to you that I replied 
to. I just applied it to a vanilla 2.6.20-rc3 tree and fired it up.




Just a warning. I'm seeing data corruption on this system. I need to try and narrow it down, but on 
transferring 100 files totalling about 80GB from a USB drive to the drives on this controller I'm 
seeing repeatable and apparently random corruption on the data reaching the disks. I don't recall 
seeing this when I used SIL controllers in place of the HPT but I now have an easily repeatable test 
case so I'll keep testing until I peg it.



Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problem with pata_hpt37x ...

[Brad Campbell]

Herbert Poetzl wrote:


sounds great! where can I get that version?
should it be in 2.6.20-rc* or is there a separate
patch available somewhere?


The patch was contained in the message from Alan to you that I replied to. I just applied it to a 
vanilla 2.6.20-rc3 tree and fired it up.


(I've pasted it inline here for you but I'm using thunderbird and it's likely the resulting mess may 
not apply - not hard to manually change the required lines however)


--- linux.vanilla-2.6.20-rc3/drivers/ata/pata_hpt37x.c  2007-01-01 
21:43:27.0 +
+++ linux-2.6.20-rc3/drivers/ata/pata_hpt37x.c  2007-01-02 14:30:18.122801920 
+
@@ -25,7 +25,7 @@
 #include 

 #define DRV_NAME   "pata_hpt37x"
-#define DRV_VERSION"0.5.1"
+#define DRV_VERSION"0.5.2"

 struct hpt_clock {
u8  xfer_speed;
@@ -749,7 +749,7 @@
 {
struct ata_port *ap = qc->ap;
struct pci_dev *pdev = to_pci_dev(ap->host->dev);
-   int mscreg = 0x50 + 2 * ap->port_no;
+   int mscreg = 0x50 + 4 * ap->port_no;
u8 bwsr_stat, msc_stat;

pci_read_config_byte(pdev, 0x6A, _stat);




Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problem with pata_hpt37x ...

[Brad Campbell]

Alan wrote:

On Tue, 2 Jan 2007 08:01:45 +0100
Herbert Poetzl <[EMAIL PROTECTED]> wrote:


if you are interested in investigating this, please
let me know what kind of data you would like to see
and/or what kind of tests would be appreciated.


I reviewed the 374 code a bit further to see what might be causing this
and found the slave channel end of DMA handling was using the wrong port
I think.


This now passes all my stress tests Alan. No more "Interrupt disabled" or dmesg 
storms.
I put the HPT Rocketraid 1540 (HPT374) back in a box and connected 4 200GB ata drives to it using 
SATA-PATA bridgeboards as before. It looks to be rock solid now.


Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problem with pata_hpt37x ...

[Brad Campbell]

Alan wrote:

On Tue, 2 Jan 2007 08:01:45 +0100
Herbert Poetzl [EMAIL PROTECTED] wrote:


if you are interested in investigating this, please
let me know what kind of data you would like to see
and/or what kind of tests would be appreciated.


I reviewed the 374 code a bit further to see what might be causing this
and found the slave channel end of DMA handling was using the wrong port
I think.


This now passes all my stress tests Alan. No more Interrupt disabled or dmesg 
storms.
I put the HPT Rocketraid 1540 (HPT374) back in a box and connected 4 200GB ata drives to it using 
SATA-PATA bridgeboards as before. It looks to be rock solid now.


Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problem with pata_hpt37x ...

[Brad Campbell]

Herbert Poetzl wrote:


sounds great! where can I get that version?
should it be in 2.6.20-rc* or is there a separate
patch available somewhere?


The patch was contained in the message from Alan to you that I replied to. I just applied it to a 
vanilla 2.6.20-rc3 tree and fired it up.


(I've pasted it inline here for you but I'm using thunderbird and it's likely the resulting mess may 
not apply - not hard to manually change the required lines however)


--- linux.vanilla-2.6.20-rc3/drivers/ata/pata_hpt37x.c  2007-01-01 
21:43:27.0 +
+++ linux-2.6.20-rc3/drivers/ata/pata_hpt37x.c  2007-01-02 14:30:18.122801920 
+
@@ -25,7 +25,7 @@
 #include linux/libata.h

 #define DRV_NAME   pata_hpt37x
-#define DRV_VERSION0.5.1
+#define DRV_VERSION0.5.2

 struct hpt_clock {
u8  xfer_speed;
@@ -749,7 +749,7 @@
 {
struct ata_port *ap = qc-ap;
struct pci_dev *pdev = to_pci_dev(ap-host-dev);
-   int mscreg = 0x50 + 2 * ap-port_no;
+   int mscreg = 0x50 + 4 * ap-port_no;
u8 bwsr_stat, msc_stat;

pci_read_config_byte(pdev, 0x6A, bwsr_stat);




Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LBD/filesystems over 2TB: is it safe?

[Brad Campbell]

[EMAIL PROTECTED] wrote:
Running x86-32 using kernel 2.6.8 (from Debian sarge), although can always
roll my own if necessary. Preferred filesystem would be ext3, and I
anticipate no need to grow beyond the initial 2.5TB.
I'm running 2.1TB and 3TB filesystems on ext3 here. It's probably not fast or optimal, however it's 
been solidly reliable. The 2.1 has been running since May 2004 with a reasonable workload. The 3TB 
is only 4 weeks old, but has been beaten pretty hard during burn-in testing.

x86-32 with 2.6.[5 6 9 10] on the 2.1 and 2.6.11-bk's on the 3.
Both filesystems have been filled to capacity during testing and real use. I unmount them and e2fsck 
-f them weekly just for a laugh also. Never a hitch.

Regards,
Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LBD/filesystems over 2TB: is it safe?

[Brad Campbell]

[EMAIL PROTECTED] wrote:
Running x86-32 using kernel 2.6.8 (from Debian sarge), although can always
roll my own if necessary. Preferred filesystem would be ext3, and I
anticipate no need to grow beyond the initial 2.5TB.
I'm running 2.1TB and 3TB filesystems on ext3 here. It's probably not fast or optimal, however it's 
been solidly reliable. The 2.1 has been running since May 2004 with a reasonable workload. The 3TB 
is only 4 weeks old, but has been beaten pretty hard during burn-in testing.

x86-32 with 2.6.[5 6 9 10] on the 2.1 and 2.6.11-bk's on the 3.
Both filesystems have been filled to capacity during testing and real use. I unmount them and e2fsck 
-f them weekly just for a laugh also. Never a hitch.

Regards,
Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA Promise TX4 Crash

[Brad Campbell]

Neil Whelchel wrote:
Hello,
I have two Promise SATA TX4 cards connected to a total of 6 Maxtor 250 GB
drives (7Y250M0) configured into a RAID 5. All works well with small
disk load, but when a large number of requests are issued, it causes crash
similar to the attached, except that the errors before the crash are on a

EFLAGS: 00010046   (2.6.11.2)
EIP is at scsi_put_command+0xbb/0x100
Oooh Oooh Oooh, pick me Mr Kotter!
I have seen this repeatedly, fought it and "apparently" beat it by upgrading my 
PSU.
I could reliably reproduce it by running a raid resync and issuing SMART queries
to the drives, but after a PSU upgrade it has gone away.
I have tried hard to reproduce it recently but I just can't get it to crash 
anymore.
I have a similar setup 4x SATA-TX4 cards and 15x 7Y250M0 drives. I'm thought it 
was actually
a bug, but as I can't reproduce it anymore it's making it a bit hard to track 
down.
Not much help, sorry.
Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA Promise TX4 Crash

[Brad Campbell]

Neil Whelchel wrote:
Hello,
I have two Promise SATA TX4 cards connected to a total of 6 Maxtor 250 GB
drives (7Y250M0) configured into a RAID 5. All works well with small
disk load, but when a large number of requests are issued, it causes crash
similar to the attached, except that the errors before the crash are on a

EFLAGS: 00010046   (2.6.11.2)
EIP is at scsi_put_command+0xbb/0x100
Oooh Oooh Oooh, pick me Mr Kotter!
I have seen this repeatedly, fought it and apparently beat it by upgrading my 
PSU.
I could reliably reproduce it by running a raid resync and issuing SMART queries
to the drives, but after a PSU upgrade it has gone away.
I have tried hard to reproduce it recently but I just can't get it to crash 
anymore.
I have a similar setup 4x SATA-TX4 cards and 15x 7Y250M0 drives. I'm thought it 
was actually
a bug, but as I can't reproduce it anymore it's making it a bit hard to track 
down.
Not much help, sorry.
Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/