From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] crash in usb_stor_get_info using pre-relocation address for ss->transport
Date: Thu, 13 Jun 2013 07:43:59 +0200 [thread overview]
Message-ID: <20130613074359.7df74fae@lilith> (raw)
In-Reply-To: <CAFOYHZAeAs8_a7Hvnd3urfQjaT5Nc5VBn=PcZOWoC50EAQXwGQ@mail.gmail.com>
Hi Chris,
On Thu, 13 Jun 2013 13:16:17 +1200, Chris Packham
<judge.packham@gmail.com> wrote:
> On Thu, Jun 13, 2013 at 12:02 PM, Chris Packham <judge.packham@gmail.com> wrote:
> > Hi,
> >
> > I've just found a crash in usb_stor_get_info (actually usb_inquiry
> > which gets auto-inlined). The cause seems to be that ss->transport is
> > set to the pre-relocation address of usb_stor_BBB_transport. Yet
> > ss->transport_reset is set to the correct relocated address of.
> >
> > The difference between the two is that usb_stor_BBB_reset is declared
> > static and usb_stor_BBB_transport is not. Changing
> > usb_stor_BBB_transport to a static makes things work but I notice that
> > none of the other transport functions are static either so I'm
> > thinking I haven't actually fixed the problem rather just masked it.
>
> Actually I see commit 199adb60 (common/misc: sparse fixes) does change
> the transport functions to static. Which is the change I was looking
> at. I still don't know if it is fixing a problem or masking a
> different one but this is probably why no-one else is complaining that
> their usb mass storage devices are causing crashes. I'll cherry-pick
> this to fix my problem.
>
> >
> > I did some poking with a lauterbach and from the disassembly it looks
> > like there is a translation table being used when the function
> > pointers are setup by usb_storage_probe and when declared normally
> > usb_stor_BBB_transport ends up at the end. Everything else has the
> > correct relocated address so I wonder if there is an off-by-one error
> > in whatever creates that table.
Can you elaborate? The only relocation-related table that I know of is
the one used in relocate_code(), and no other relocation-fix table
exists or is used anywhere else.
> > Does this sound familiar to anyone.
Familiar, no, but it does set in my mind, if not a blaring alarm with
flashing beacons, at least a blinking red light with a beep, so let's
analyize this.
Amicalement,
--
Albert.
next prev parent reply other threads:[~2013-06-13 5:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-13 0:02 [U-Boot] crash in usb_stor_get_info using pre-relocation address for ss->transport Chris Packham
2013-06-13 1:16 ` Chris Packham
2013-06-13 5:43 ` Albert ARIBAUD [this message]
2013-06-13 10:19 ` Chris Packham
2013-06-13 11:24 ` Albert ARIBAUD
2013-06-13 22:48 ` Chris Packham
2013-06-14 2:21 ` Chris Packham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130613074359.7df74fae@lilith \
--to=albert.u.boot@aribaud.net \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox