http://blog.gmane.org/gmane.linux.ports.ppc64.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/91025 <pre>The only reason uaccess routines might sleep is if they fault. Make this explicit. Arnd Bergmann suggested that the following code if (!is_kernel_addr((unsigned long)__pu_addr)) might_fault(); can be further simplified by adding a version of might_fault that includes the kernel addr check. Will be considered as a further optimization in future. Signed-off-by: Michael S. Tsirkin &lt;mst&lt; at &gt;redhat.com&gt; --- arch/powerpc/include/asm/uaccess.h | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h index 4db4959..9485b43 100644 --- a/arch/powerpc/include/asm/uaccess.h +++ b/arch/powerpc/include/asm/uaccess.h &lt; at &gt;&lt; at &gt; -178,7 +178,7 &lt; at &gt;&lt; at &gt; do {\ long __pu_err;\ __typeof__(*(ptr)) __user *__pu_addr = (ptr);\ if (!is_kernel_addr((unsigned long)__pu_addr))\ -might_sleep();\ +might_fault();\ __chk_user_ptr(ptr);\ __put_user_size((x), __pu_addr, (size), __pu_err);\ __pu_err;\ &lt; at &gt;&lt; at &gt; -188,7 +188,7 &lt; at &gt;&lt; at &gt; do {\ ({\ long __pu_err = -EFAULT;\ __typeof__(*(ptr)) __user *__pu_addr = (ptr);\ -might_sleep();\ +might_fault();\ if (access_ok(VERIFY_WRITE, __pu_addr, size))\ __put_user_size((x), __pu_addr, (size), __pu_err);\ __pu_err;\ &lt; at &gt;&lt; at &gt; -268,7 +268,7 &lt; at &gt;&lt; at &gt; do {\ const __typeof__(*(ptr)) __user *__gu_addr = (ptr);\ __chk_user_ptr(ptr);\ if (!is_kernel_addr((unsigned long)__gu_addr))\ -might_sleep();\ +might_fault();\ __get_user_size(__gu_val, __gu_addr, (size), __gu_err);\ (x) = (__typeof__(*(ptr)))__gu_val;\ __gu_err;\ &lt; at &gt;&lt; at &gt; -282,7 +282,7 &lt; at &gt;&lt; at &gt; do {\ const __typeof__(*(ptr)) __user *__gu_addr = (ptr);\ __chk_user_ptr(ptr);\ if (!is_kernel_addr((unsigned long)__gu_addr))\ -might_sleep();\ +might_fault();\ __get_user_size(__gu_val, __gu_addr, (size), __gu_err);\ (x) = (__typeof__(*(ptr)))__gu_val;\ __gu_err;\ &lt; at &gt;&lt; at &gt; -294,7 +294,7 &lt; at &gt;&lt; at &gt; do {\ long __gu_err = -EFAULT;\ unsigned long __gu_val = 0;\ const __typeof__(*(ptr)) __user *__gu_addr = (ptr);\ -might_sleep();\ +might_fault();\ if (access_ok(VERIFY_READ, __gu_addr, (size)))\ __get_user_size(__gu_val, __gu_addr, (size), __gu_err);\ (x) = (__typeof__(*(ptr)))__gu_val;\ &lt; at &gt;&lt; at &gt; -419,14 +419,14 &lt; at &gt;&lt; at &gt; static inline unsigned long __copy_to_user_inatomic(void __user *to, static inline unsigned long __copy_from_user(void *to, const void __user *from, unsigned long size) { -might_sleep(); +might_fault(); return __copy_from_user_inatomic(to, from, size); } static inline unsigned long __copy_to_user(void __user *to, const void *from, unsigned long size) { -might_sleep(); +might_fault(); return __copy_to_user_inatomic(to, from, size); } &lt; at &gt;&lt; at &gt; -434,7 +434,7 &lt; at &gt;&lt; at &gt; extern unsigned long __clear_user(void __user *addr, unsigned long size); static inline unsigned long clear_user(void __user *addr, unsigned long size) { -might_sleep(); +might_fault(); if (likely(access_ok(VERIFY_WRITE, addr, size))) return __clear_user(addr, size); if ((unsigned long)addr &lt; TASK_SIZE) { </pre> Michael S. Tsirkin 2013-05-24T14:18:20 http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/91016 <pre>Thanks anton. </pre> Wang Dongsheng-B40534 2013-05-24T05:21:51 http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/91015 <pre> In fact: if enable CONFIG_BUG, but not enable HAVE_ARCH_BUG, the default implementation is: 47 #ifndef HAVE_ARCH_BUG 48 #define BUG() do { \ 49 printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __func__); \ 50 panic("BUG!"); \ 51 } while (0) 52 #endif So if we delete CONFIG_BUG, the default implementation will be almost like panic(), and in panic() itself, also calls printk() !! So... :-) </pre> Chen Gang 2013-05-24T04:17:26 http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/91012 <pre> After read the arch/*/include/asm/bug.h, It seems panic() is not suitable for NOMMU platforms (only m68k use it, also need CONFIG_BUG and CONFIG_SUN3 enabled). And unreachable() is need followed with an asm inline instruction (arm, x86, powerpc mips...). And __builtin_trap() is "the mechanism used may vary from release to release so should not rely on any particular implementation" (ref to "http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html", used by m68k, sparc, ia64). I can not find any *trap*() and *unreachable*() in "include/asm-generic/" I can not find any suitable implementation which 'generic' enough to add in "include/asm-generic/" (and in fact, CONFIG_BUG itself is not 'generic' enough to be in "include/asm-generic/"). At last, I still suggest to delete CONFIG_BUG, so most of architectures can skip this issue firstly. Then for specific architectures, also can get 3 benefits: a. the related maintainers can implement it as their own willing (not need discus it with another platform maintainers again); b. the related maintainers can free use the platform specific features (which can not be used in "include/asm-generic/"); c. the related maintainers are more familiar their own architectures demands and requirements. ----------- arch/m68k/include/asm/bug.h -------------------------------- 1 #ifndef _M68K_BUG_H 2 #define _M68K_BUG_H 3 4 #ifdef CONFIG_MMU 5 #ifdef CONFIG_BUG 6 #ifdef CONFIG_DEBUG_BUGVERBOSE 7 #ifndef CONFIG_SUN3 8 #define BUG() do { \ 9 printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \ 10 __builtin_trap(); \ 11 } while (0) 12 #else 13 #define BUG() do { \ 14 printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \ 15 panic("BUG!"); \ 16 } while (0) 17 #endif 18 #else 19 #define BUG() do { \ 20 __builtin_trap(); \ 21 } while (0) 22 #endif 23 24 #define HAVE_ARCH_BUG 25 #endif 26 #endif /* CONFIG_MMU */ 27 28 #include &lt;asm-generic/bug.h&gt; 29 30 #endif Thanks. </pre> Chen Gang 2013-05-24T02:13:35 http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/91009 <pre>Hi! On Tue, May 14, 2013 at 08:59:13AM +0000, Wang Dongsheng-B40534 wrote: I don't have any means to test it, but the patch itself looks good and the description makes sense. So, Reviewed-by: Anton Vorontsov &lt;anton&lt; at &gt;enomsg.org&gt; Thanks! </pre> Anton Vorontsov 2013-05-23T17:33:32 http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/91003 <pre>Sebastian, On Wed, May 22, 2013 at 02:16:07PM -0600, Jason Gunthorpe wrote: Is there a model number variation between IP that needs this and IP that doesn't? If not, I'm fine with of_machine_is_compatible(). thx, Jason. </pre> Jason Cooper 2013-05-23T16:01:11 http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/91002 <pre>Shaohui -- Apologies, a minor clarification is needed: Anthony Foiani &lt;tkil&lt; at &gt;scrye.com&gt; writes: In this case, it would recover *even as the NOR write continued*. Here's an example where it froze and recovered twice. The application starts about 12s after the kernel, so 945s for the kernel should be 933s for the application. Also, note that this case already has the speed limit code included (see message at 945.928702), so I don't think I need to do a separate test. [console] [ 945.902543] ata2: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe frozen [ 945.909584] ata2: PHY RDY changed [ 945.913048] ata2: hard resetting link [ 945.928702] ata2: setting speed (in hard reset) [ 945.939864] ata2: Signature Update detected &lt; at &gt; 0 msecs [ 946.115888] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 946.128548] ata2.00: configured for UDMA/133 [ 946.133021] ata2: EH complete [ 952.537180] ata2: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe frozen [ 952.544208] ata2: PHY RDY changed [ 952.547626] ata2: hard resetting link [ 952.558319] ata2: setting speed (in hard reset) [ 953.076730] ata2: Signature Update detected &lt; at &gt; 508 msecs [ 953.251866] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 953.259389] ata2.00: configured for UDMA/133 [ 953.263892] ata2: EH complete [application] +924.152278 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x100000 from buf[0x0]; attempt 1/3 +925.599739 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x110000 from buf[0x10000]; attempt 1/3 +927.018239 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x120000 from buf[0x20000]; attempt 1/3 +928.414069 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x130000 from buf[0x30000]; attempt 1/3 +929.872850 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x140000 from buf[0x40000]; attempt 1/3 +931.341634 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x150000 from buf[0x50000]; attempt 1/3 +932.724024 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x160000 from buf[0x60000]; attempt 1/3 [first freeze is about here] +934.146203 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x170000 from buf[0x70000]; attempt 1/3 +935.569069 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x180000 from buf[0x80000]; attempt 1/3 +936.875275 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x190000 from buf[0x90000]; attempt 1/3 +938.205302 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x1a0000 from buf[0xa0000]; attempt 1/3 +939.519662 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x1b0000 from buf[0xb0000]; attempt 1/3 +940.873656 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x1c0000 from buf[0xc0000]; attempt 1/3 [second freeze is about here] +942.230740 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x1d0000 from buf[0xd0000]; attempt 1/3 +943.641994 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x1e0000 from buf[0xe0000]; attempt 1/3 +944.938454 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x1f0000 from buf[0xf0000]; attempt 1/3 +946.236491 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x200000 from buf[0x100000]; attempt 1/3 +947.607673 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x210000 from buf[0x110000]; attempt 1/3 +948.919213 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x220000 from buf[0x120000]; attempt 1/3 +950.151386 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x230000 from buf[0x130000]; attempt 1/3 +951.502522 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x240000 from buf[0x140000]; attempt 1/3 +952.851177 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x250000 from buf[0x150000]; attempt 1/3 +954.082897 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x260000 from buf[0x160000]; attempt 1/3 +955.315338 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x270000 from buf[0x170000]; attempt 1/3 +956.559639 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x280000 from buf[0x180000]; attempt 1/3 +957.845503 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x290000 from buf[0x190000]; attempt 1/3 +959.100007 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x2a0000 from buf[0x1a0000]; attempt 1/3 +960.347982 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x2b0000 from buf[0x1b0000]; attempt 1/3 +961.545344 sw-upd.0 [29]: fm: nor0: write: writing 0x10000 &lt; at &gt;0x2c0000 from buf[0x1c0000]; attempt 1/3 Best regards, Anthony Foiani </pre> Anthony Foiani 2013-05-23T15:49:34 http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/91001 <pre>Shaohui -- Xie Shaohui-B21989 &lt;B21989&lt; at &gt;freescale.com&gt; writes: You're very welcome. I'll have to pass these questions on to my hardware vendor; I'm not equipped to do this level of hardware debugging (neither hardware nor knowledge!). Earlier in my development, I was seeing this error and it would recover: ata2: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe frozen ata2: PHY RDY changed ata2: hard resetting link ata2: Signature Update detected &lt; at &gt; 0 msecs ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata2.00: configured for UDMA/133 ata2: EH complete At the current time, however, it seems that it does not recover. I don't know whether this is due to the speed limiting code, or if it's because we are doing more disk accesses (when the actual product is up and running). I can re-do the tests with the speed limit disabled, but I won't be able to get to that for a few hours yet. You can read about the speed limit issues in this thread: http://article.gmane.org/gmane.linux.ports.ppc.embedded/50652 And my final patch (yes, a year later): http://article.gmane.org/gmane.linux.ports.ppc.embedded/58969 Please don't laugh too hard when you read it. :) Thanks again for your help. I'll try to get the results of testing w/o speed limit to you within a day or two. Best regards, Anthony Foiani </pre> Anthony Foiani 2013-05-23T15:10:57 http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/91000 <pre> These look ok to me, how do you want to integrate them? Should I provide Acks on patches 2 &amp; 3 and let them get pushed through the ppc tree or should I wait for patch 1 then push 2 &amp; 3 through my tree? Thanks, Alex </pre> Alex Williamson 2013-05-23T14:56:24 http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/90999 <pre>On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux &lt;linux&lt; at &gt;arm.linux.org.uk&gt; wrote: I agree it's best to e.g. trap and reboot. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert&lt; at &gt;linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds </pre> Geert Uytterhoeven 2013-05-23T14:10:04 http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/90990 <pre> I must be missing something, to me the two descriptions mean the same thing. I think this all comes from the 'linux-tiny' project that tried to squeeze out the last bits of kernel object code size at some point. The idea was that if you have code like BUG_ON(something_unexpected_happened()); or switch (my_enum) { case FOO: return f1(); case BAR: return f2(); default: BUG(); } You don't just want to avoid the code for printing the bug message and the invalid instruction, we also want the compiler to not emit the function call or check the enum for unexpected values. The meaning of BUG() is really that person writing that statement was sure it cannot happen unless there is a bug in the kernel, which has likely already corrupted data. Printing a diagnostic at this point is nice if someone is there to look at it, but letting the kernel do further actions that may be undefined is not going to make things worse. Arnd </pre> Arnd Bergmann 2013-05-23T10:59:43 http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/90989 <pre> But I still suggest to delete CONFIG_BUG in common kernel. Since currently, disable 'CONFIG_BUG' is not a common features (most of architectures are always enable it), it is only belongs to some architectures specific features (may some embedded systems). It is not suitable to still let 'CONFIG_BUG' exist in "asm-generic/bug.h" which is only for common features. And each architecture can customize their own BUG(), if one architecture wants to Disabling this option, let it specify its own BUG(). So, most of architectures need not consider this issue again. Thanks. </pre> Chen Gang 2013-05-23T10:41:34 http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/90987 <pre> Are you sure this isn't allowed for when the structure is allocated? Otherwise you also need to use strlcpy() as well. This looks like what c99 allows 'char name[0]' be used for. But ensure the \0 is allowed for before changing to 1 to 0. David </pre> David Laight 2013-05-23T10:21:19 http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/90984 <pre> In fact, using __builtin_unreachable() is a standard way for architectures to implemented their own BUG() (e.g. x86, s390, powerpc, arm ...) Before __builtin_unreachable(), must need an inline asm instruction which architecture specific. I have test using __builtin_unreachable() without an related asm instruction before, it prints many unexpected things (please see the attachment). So I think, it is not suitable to use it in "asm-generic/bug.h" Thanks. </pre> Chen Gang 2013-05-23T10:05:10 http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/90982 <pre>On Thu, May 23, 2013 at 11:05 AM, Russell King - ARM Linux &lt;linux&lt; at &gt;arm.linux.org.uk&gt; wrote: Is __builtin_unreachable() working well these days? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert&lt; at &gt;linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds </pre> Geert Uytterhoeven 2013-05-23T09:12:56 http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/90980 <pre> Agreed. The one annoying property of disabling BUG() support is that it causes a large number of build warnings since the compiler now has to assume that a lot of code is reachable when it is normally annotate as unreachable. When I do "randconfig" tests, I always turn on CONFIG_BUG because of this. Arnd </pre> Arnd Bergmann 2013-05-23T08:54:10 http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/90978 <pre> Sorry, but we don't. I think you don't get the meaning of the BUG config symbol (see below). What do you mean by "already implemented it"? E.g. on m68k, I can disable or enable CONFIG_BUG. Both work. This is not about providing an implementation or not... ... It's about reducing memory size on devices where you can't show bug or warning messages. So please keep it. Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert&lt; at &gt;linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds </pre> Geert Uytterhoeven 2013-05-23T08:40:29 http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/90976 <pre>strcpy(ssi_private-&gt;name, p) in probe() sets "name" by "p", gotten from dts, while the length of "p", if the devicetree node name of SSI is commonly set, would always be larger than 1 char size, so need a larger size for "name". Signed-off-by: Nicolin Chen &lt;b42378&lt; at &gt;freescale.com&gt; --- sound/soc/fsl/fsl_ssi.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c index 2f2d837..b6a5f94 100644 --- a/sound/soc/fsl/fsl_ssi.c +++ b/sound/soc/fsl/fsl_ssi.c &lt; at &gt;&lt; at &gt; -152,5 +152,5 &lt; at &gt;&lt; at &gt; struct fsl_ssi_private { } stats; -char name[1]; +char name[32]; }; </pre> Nicolin Chen 2013-05-23T06:26:36 http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/90975 <pre>Hi, Anthony Foiani, Thanks for the confirmation. So it seems the NOR write break the signal Integrity of SATA. I don't have schematic and board right now, could you please measure signals related to NOR write to see if anything abnormal? Is the board use FPGA or CPLD to control signal? If stop NOR write, could the SATA recover and work? Best Regards, Shaohui Xie </pre> Xie Shaohui-B21989 2013-05-23T06:04:15 http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/90974 <pre> Shaohui -- Thanks for the quick reply! Please find my investigation and results below. Xie Shaohui-B21989 &lt;B21989&lt; at &gt;freescale.com&gt; writes: It seems that I can do this without any errors: / # flash_erase /dev/mtd1 0 0 Erasing 64 Kibyte &lt; at &gt; 7f0000 -- 100 % complete / # dd if=/dev/zero of=/dev/mtd1 dd: writing '/dev/mtd1': No space left on device 16385+0 records in 16384+0 records out 8388608 bytes (8.0MB) copied, 62.399439 seconds, 131.3KB/s Again, no problem: /ssd # ls -al biggie.bin -rw-r--r-- 1 root root 2330607084 May 22 19:34 biggie.bin /ssd # ls -alh biggie.bin -rw-r--r-- 1 root root 2.2G May 22 19:34 biggie.bin /ssd # time cp biggie.bin biggie2.bin real 3m 27.55s user 0m 2.60s sys 2m 16.13s Doing a NOR read during heavy SATA r/w seems to succeed, with no errors on the console: [window 1] /ssd # time cp biggie.bin biggie2.bin [window 2] / # dd if=/dev/mtd1 of=/dev/null 16384+0 records in 16384+0 records out 8388608 bytes (8.0MB) copied, 6.380613 seconds, 1.3MB/s Doing a NOR write fails almost instantly (within a second): [window 1] /ssd # time cp biggie.bin biggie2.bin [window 2] / # dd if=/dev/zero of=/dev/mtd1 [console] [ 5160.269106] ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x6 frozen [ 5160.276387] ata2.00: failed command: READ DMA [ 5160.280905] ata2.00: cmd c8/00:00:60:f3:01/00:00:00:00:00/e0 tag 0 dma 131072 in [ 5160.280928] res 50/00:00:f0:c0:48/00:00:00:00:00/e0 Emask 0x10 (ATA bus error) [ 5160.296386] ata2.00: status: { DRDY } [ 5160.300195] ata2: hard resetting link [ 5160.347858] ata2: setting speed (in hard reset) [ 5170.439981] ata2: No Signature Update [ 5170.611901] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 5170.618204] ata2.00: link online but device misclassified [ 5175.623918] ata2.00: qc timeout (cmd 0xec) [ 5175.628147] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 5175.634347] ata2.00: revalidation failed (errno=-5) [ 5175.639373] ata2: hard resetting link [ 5176.143847] ata2: Hardreset failed, not off-lined 0 [ 5176.155867] ata2: setting speed (in hard reset) [ 5185.743871] ata2: No Signature Update [ 5185.915900] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 5185.922203] ata2.00: link online but device misclassified [ 5195.927910] ata2.00: qc timeout (cmd 0xec) [ 5195.932140] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 5195.938342] ata2.00: revalidation failed (errno=-5) [ 5195.943430] ata2: hard resetting link [ 5196.443885] ata2: Hardreset failed, not off-lined 0 ... At this point, a hard reset / full power cycle is needed to recover. The board is an MPC8315ERDB derivative, and I'm running a patched 3.4.36 kernel. I've uploaded some (possibly) relevant files to: http://foiani.home.dyndns.org/~tony/linux/ppc-sata-issues-201305/ There is a diff from 3.4.36, a devtree, and a kernel config. Please let me know if there is any more information that I can contribute. Best regards, Anthony Foiani </pre> Anthony Foiani 2013-05-23T05:52:23 http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/90970 <pre> Recent commit e61133dda480062d221f09e4fc18f66763f8ecd0 added support for a new firmware feature to force an adapter to use 32 bit MSIs. However, this firmware is not available for all systems. The hack below allows devices needing 32 bit MSIs to work on these systems as well. It is careful to only enable this on Gen2 slots, which should limit this to configurations where this hack is needed and tested to work. Signed-off-by: Brian King &lt;brking&lt; at &gt;linux.vnet.ibm.com&gt; --- arch/powerpc/platforms/pseries/msi.c | 35 ++++++++++++++++++++++++++++++++--- 1 file changed, 32 insertions(+), 3 deletions(-) diff -puN arch/powerpc/platforms/pseries/msi.c~powerpc_32bit_msi_hack_on_papr arch/powerpc/platforms/pseries/msi.c --- linux/arch/powerpc/platforms/pseries/msi.c~powerpc_32bit_msi_hack_on_papr2013-05-15 10:44:46.000000000 -0500 +++ linux-bjking1/arch/powerpc/platforms/pseries/msi.c2013-05-22 10:51:17.000000000 -0500 &lt; at &gt;&lt; at &gt; -401,6 +401,7 &lt; at &gt;&lt; at &gt; static int rtas_setup_msi_irqs(struct pc struct msi_desc *entry; struct msi_msg msg; int nvec = nvec_in; +int use_32bit_msi_hack = 0; pdn = get_pdn(pdev); if (!pdn) &lt; at &gt;&lt; at &gt; -428,15 +429,43 &lt; at &gt;&lt; at &gt; static int rtas_setup_msi_irqs(struct pc */ again: if (type == PCI_CAP_ID_MSI) { -if (pdn-&gt;force_32bit_msi) +if (pdn-&gt;force_32bit_msi) { rc = rtas_change_msi(pdn, RTAS_CHANGE_32MSI_FN, nvec); -else +if (rc &lt; 0) { +/* + * We only want to run the 32 bit MSI hack below if + * the max bus speed is Gen2 speed + */ +if (pdev-&gt;bus-&gt;max_bus_speed != PCIE_SPEED_5_0GT) +return rc; + +use_32bit_msi_hack = 1; +} +} else +rc = -1; + +if (rc &lt; 0) rc = rtas_change_msi(pdn, RTAS_CHANGE_MSI_FN, nvec); -if (rc &lt; 0 &amp;&amp; !pdn-&gt;force_32bit_msi) { +if (rc &lt; 0) { pr_debug("rtas_msi: trying the old firmware call.\n"); rc = rtas_change_msi(pdn, RTAS_CHANGE_FN, nvec); } + +if (use_32bit_msi_hack &amp;&amp; rc &gt; 0) { +u32 addr_hi, addr_lo; + +/* + * We should only get in here for IODA1 configs. This is based on the + * fact that we using RTAS for MSIs, we don't have the 32 bit MSI RTAS + * support, and we are in a PCIe Gen2 slot. + */ +dev_info(&amp;pdev-&gt;dev, "rtas_msi: No 32 bit MSI firmware support, forcing 32 bit MSI\n"); +pci_read_config_dword(pdev, pdev-&gt;msi_cap + PCI_MSI_ADDRESS_HI, &amp;addr_hi); +addr_lo = 0xffff0000 | ((addr_hi &gt;&gt; (48 - 32)) &lt;&lt; 4); +pci_write_config_dword(pdev, pdev-&gt;msi_cap + PCI_MSI_ADDRESS_LO, addr_lo); +pci_write_config_dword(pdev, pdev-&gt;msi_cap + PCI_MSI_ADDRESS_HI, 0); +} } else rc = rtas_change_msi(pdn, RTAS_CHANGE_MSIX_FN, nvec); _ </pre> Brian King 2013-05-22T21:07:46 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.ports.ppc64.devel