Apologies for resurrecting a very old thread, but...
On 05/30/2012 02:14 PM, Anthony Foiani wrote:
Maybe someone who knows devtree really well could crank that out in a
few minutes... but I'm not that person. :)
Well, I wasn't last year, but this year I decided that I didn't
Please use standard Linux coding style,
Huh. I thought I had. I'll double-check.
and submit the patch inline rather than as an attachment (e.g. use git
send-email).
Will see if I can do so. I don't actually have any sort of MTA set up
on this machine, hence these Thunderbirde
Scott --
On 04/30/2013 06:42 PM, Scott Wood wrote:
I just meant that, for whatever boards you would have put this in the
device tree, put it in platform code instead (if the platform file
supports more than one board type, then check the compatible at the
top of the device tree).
I think I
x27;*_spd*' -print | xargs grep .
./ata2/link2/ata_link/link2/sata_spd:1.5 Gbps
./ata2/link2/ata_link/link2/hw_sata_spd_limit:1.5 Gbps
./ata2/link2/ata_link/link2/sata_spd_limit:1.5 Gbps
Thanks for any pointers. Patch below.
Thanks again,
Anthony Foiani
(Pardon the extra context, but it
Anthony Foiani writes:
> Maybe I need to call ata_set_sata_spd as well. Can I do that before
> discovery, or should it be a part of the port_start callback? And
> if the latter, shouldn't it be handled within the ata core, instead
> of expecting each host driver to do tha
8.484562] ata2.00: configured for UDMA/133
As always, any further hints would be very welcome.
Best regards,
Anthony Foiani
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Scott --
Scott Wood writes:
> On 05/15/2013 03:12:21 AM, Anthony Foiani wrote:
>> At this point, /dev/sda is pretty much unusable, and I have to do
>> at least a reboot to recover. (I don't recall if I had to do a
>> power cycle at this point, though.)
For whatev
f 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
.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
___
Linuxppc-dev mailing list
Shaohui --
Apologies, a minor clarification is needed:
Anthony Foiani writes:
> Shaohui --
>
> Xie Shaohui-B21989 writes:
>
>> If stop NOR write, could the SATA recover and work?
>
> Earlier in my development, I was seeing this error and it would
> recover:
>
it later.
Either way, thanks again. I'll try to put together a package for my
vendor to test with; once I have demonstrated that there is a problem
with their hardware, they have been gracious about accepting that
result and pursuing it with Freescale if necessary.
Thanks again for yo
mely
helpful and have provided excellent support. Apologies if it turns
out that it was all due to a wiring error. :(
Best regards,
Anthony Foiani
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
form_get_drvdata and adding the rx_watermark.
I did see that dev_set_drvdata was removed from sata_fsl_probe's exit
path; not sure if that could cause this sort of error.
If anyone has ideas on how to avoid the reboot lockup, I would greatly
appreciate it.
Thank you for your time!
Best regards
linux-next before it'd be accepted there, I fear.)
Either way, I'll definitely report if it fixes the splat on my 3.9.7
system.
Thanks again!
Best regards,
Anthony Foiani
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
(or: http://preview.tinyurl.com/mpd4e9h )
Unfortunately, the hang on reboot was not easily repeatable; I'll
report whether it happens in the next few days or not.
Thanks again,
Anthony Foiani
-- >8 --
>From 2abb6df770c95eb4103476c70847a78f816fe5e3 Mon Sep 17 00:00:00 2001
From: Anthony
Bhushan Bharat-R65777 writes:
> Anthony, I would prefer if you can send the patch (In case not then
> let me know)
Sure, I'll get it sent in a few minutes.
Would you like me to put an Acked-by on it for you?
Best regards,
Anthony Foiani
_
tested on hardware.
This patch is based off linux-next tag next-20130819
(which is commit 66a01bae29d11916c09f9f5a937cafe7d402e4a5 )
Signed-off-by: Anthony Foiani
---
drivers/ata/sata_fsl.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers
t-failure-lockdep-splat-possibly-related-tp75162.html
Same patch successfully tested with 3.9.7. linux-next compiled but
not tested on hardware.
This patch is based off linux-next tag next-20130819
(which is commit 66a01bae29d11916c09f9f5a937cafe7d402e4a5 )
Signed-off-by: Anthony Foiani
---
dri
Let me know how you'd like to
proceed on the above points, and I can resubmit (as a proper patch for
easier tracking).
Best regards,
Anthony Foiani
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Scott Wood writes:
> On Fri, 2013-08-23 at 17:41 -0600, Anthony Foiani wrote:
> > In my original patch [...] I used "fsl,sata-max-gen". I thought
> > Jeff disliked it, so I changed it be more generic -- but maybe I
> > misread his complaint. (And while his o
s a bit obscure, but it's barely used in
the kernel, and it makes a certain amount of sense in this context.
Thanks to everyone that's contributed to the PPC Linux stack; it's
made this project (and my current livelihood!)
where I can go from here?
I could try the latest kernels, but due to our vendor not upstreaming
their patches, there could be some pain in that transition.
Thanks in advance for any suggestions.
Best regards,
Anthony Foiani
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Greetings.
I was occasionally running into problems at boot time on an
MPC8315-based board (derived from the MPC831xRDB, apparently), using
SATA to talk to an SSD. My vendor suggested that I enable
CONFIG_MPC8315_DS.
That symbol is only found once in the entire kernel codebase:
$ git checkou
Li Yang-R58472 writes:
> Thanks for bringing [CONFIG_MPC8315_DS] up again. Looks like we do
> have a problem here.
My impression is that the simplest fix is Adrian's patch, which simply
keys off CONFIG_MPC831x_RDB. It's not very satisfying, but I'll take
"working" vs. "rare lockups at boot".
Scott Wood writes:
> CONFIG_MPC831x_RDB doesn't mean that you're running on such a board,
> only that the kernel supports those boards. It should be a runtime
> test.
Point taken.
If that SATA check is CPU/SOC-based, then it should be easy enough to
test. The cpuinfo for my board is:
# cat
drian's patch) so I don't have any actual urgency for fixing
this.
I was hoping that someone might know the "correct" answer offhand, but
I honestly think that this isn't worth spending too much time on.
(But I do think that Adrian's patch is an improvement over t
at we don't
have undocumented / unconnected kconfig symbols in the tree. If we
ever do find out more details about the workaround, we can at least
add some comments at the code site.
Thanks again!
Best regards,
Anthony Foiani
___
Linuxppc-dev mailing lis
Scott Wood writes:
> We currently support building one kernel that supports a bunch of
> different boards. The hardcoding of this workaround was harmless so
> far because it was conditional on a symbol that was never defined,
> but now you'll be enabling this workaround on any kernel that simply
28 matches
Mail list logo
