From: Punit Agrawal <punitagrawal@gmail.com>
To: Bin Meng <bmeng.cn@gmail.com>
Cc: Patrick Wildt <patrick@blueri.se>,
linux-rockchip@lists.infradead.org,
Kever Yang <kever.yang@rock-chips.com>,
Aaron Williams <awilliams@marvell.com>,
U-Boot Mailing List <u-boot@lists.denx.de>,
Jagan Teki <jagan@amarulasolutions.com>
Subject: Re: NVMe boot issues on RockPro64
Date: Sun, 30 Aug 2020 09:16:30 +0900 [thread overview]
Message-ID: <87o8mtyom9.fsf@tinker> (raw)
In-Reply-To: <CAEUhbmV3fAa-j6-QR1Y3NvmfGRX38PmvjtVpUUtxZehuABN_yg@mail.gmail.com> (Bin Meng's message of "Sat, 29 Aug 2020 15:03:02 +0800")
Hi Bin,
Bin Meng <bmeng.cn@gmail.com> writes:
> Hi Punit,
>
> On Sat, Aug 29, 2020 at 8:30 AM Punit Agrawal <punitagrawal@gmail.com> wrote:
>>
>> Hi,
>>
>> I get the following errors when booting Linux from an ADATA XPG SX8200
>> NVMe on a RockPro64.
>>
>> [ 3.705205] rockchip-pcie f8000000.pcie: unexpected IRQ, INT0
>> [ 3.705226] rockchip-pcie f8000000.pcie: unexpected IRQ, INT0
>> [ 3.705247] rockchip-pcie f8000000.pcie: unexpected IRQ, INT0
>> [ 3.705331] rockchip-pcie f8000000.pcie: unexpected IRQ, INT0
>> [ 3.705352] rockchip-pcie f8000000.pcie: unexpected IRQ, INT0
>> [ 3.705373] rockchip-pcie f8000000.pcie: unexpected IRQ, INT0
>>
>> At which point boot hangs. Has anybody come across these errors when
>> using NVMe?
>>
>> Using an alternate device (sd card) to load the kernel / initrd doesn't
>> cause the issue and the drive works fine when used as a root device in
>> Linux subsequently.
>>
>> On digging further, I found that uboot exits with the NVME interrupt
>> line (PCI legacy interrupt) active when making any access to the
>> device. Even just running "nvme scan" leads to the active interrupt
>> line.
>>
>> After sprinkling some prints in the uboot NVMe driver, it seems that the
>> interrupt goes active right at the beginning of setting up the IO queues
>> (nvme_setup_io_queues). This is also the first time the admin queue is
>> used; when issuing the command to setup the number of queues
>> (NVME_FEAT_NUM_QUEUES). For some reason, updating the CQ head doorbell
>> doesn't clear the interrupt.
>>
>> The active interrupt doesn't bother uboot as it ignores the device
>> interrupt but causes an issue latter when linux boots.
>>
>> Has anybody faced similar issues with NVMe and uboot? Any idea on how to
>> stop the interrupt line from triggering? Or de-activating it on exit?
>>
>> Let me know if there's anything I can provide to help debug the
>> problem. Also, happy to try any patches or suggestions.
>>
>
> Is this a specific behavior of the NVMe card you are using? Could you
> please switch to another card for testing?
I suspect this behaviour is down to the ADATA NVMe card but I don't have
any others at hand to test. Bought this as a reasonably priced addition
to personal computing environment - I was hoping to avoid having to buy
another one.
Thinking about it, I can try hacking the Linux driver to use legacy
interrupts. Maybe it can help identify hardware vs software issue. I
will give this a shot.
Let me know if you think of anything else I should try.
Thanks,
Punit
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
WARNING: multiple messages have this Message-ID (diff)
From: Punit Agrawal <punitagrawal@gmail.com>
To: u-boot@lists.denx.de
Subject: NVMe boot issues on RockPro64
Date: Sun, 30 Aug 2020 09:16:30 +0900 [thread overview]
Message-ID: <87o8mtyom9.fsf@tinker> (raw)
In-Reply-To: <CAEUhbmV3fAa-j6-QR1Y3NvmfGRX38PmvjtVpUUtxZehuABN_yg@mail.gmail.com> (Bin Meng's message of "Sat, 29 Aug 2020 15:03:02 +0800")
Hi Bin,
Bin Meng <bmeng.cn@gmail.com> writes:
> Hi Punit,
>
> On Sat, Aug 29, 2020 at 8:30 AM Punit Agrawal <punitagrawal@gmail.com> wrote:
>>
>> Hi,
>>
>> I get the following errors when booting Linux from an ADATA XPG SX8200
>> NVMe on a RockPro64.
>>
>> [ 3.705205] rockchip-pcie f8000000.pcie: unexpected IRQ, INT0
>> [ 3.705226] rockchip-pcie f8000000.pcie: unexpected IRQ, INT0
>> [ 3.705247] rockchip-pcie f8000000.pcie: unexpected IRQ, INT0
>> [ 3.705331] rockchip-pcie f8000000.pcie: unexpected IRQ, INT0
>> [ 3.705352] rockchip-pcie f8000000.pcie: unexpected IRQ, INT0
>> [ 3.705373] rockchip-pcie f8000000.pcie: unexpected IRQ, INT0
>>
>> At which point boot hangs. Has anybody come across these errors when
>> using NVMe?
>>
>> Using an alternate device (sd card) to load the kernel / initrd doesn't
>> cause the issue and the drive works fine when used as a root device in
>> Linux subsequently.
>>
>> On digging further, I found that uboot exits with the NVME interrupt
>> line (PCI legacy interrupt) active when making any access to the
>> device. Even just running "nvme scan" leads to the active interrupt
>> line.
>>
>> After sprinkling some prints in the uboot NVMe driver, it seems that the
>> interrupt goes active right at the beginning of setting up the IO queues
>> (nvme_setup_io_queues). This is also the first time the admin queue is
>> used; when issuing the command to setup the number of queues
>> (NVME_FEAT_NUM_QUEUES). For some reason, updating the CQ head doorbell
>> doesn't clear the interrupt.
>>
>> The active interrupt doesn't bother uboot as it ignores the device
>> interrupt but causes an issue latter when linux boots.
>>
>> Has anybody faced similar issues with NVMe and uboot? Any idea on how to
>> stop the interrupt line from triggering? Or de-activating it on exit?
>>
>> Let me know if there's anything I can provide to help debug the
>> problem. Also, happy to try any patches or suggestions.
>>
>
> Is this a specific behavior of the NVMe card you are using? Could you
> please switch to another card for testing?
I suspect this behaviour is down to the ADATA NVMe card but I don't have
any others at hand to test. Bought this as a reasonably priced addition
to personal computing environment - I was hoping to avoid having to buy
another one.
Thinking about it, I can try hacking the Linux driver to use legacy
interrupts. Maybe it can help identify hardware vs software issue. I
will give this a shot.
Let me know if you think of anything else I should try.
Thanks,
Punit
next prev parent reply other threads:[~2020-08-30 0:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-29 0:30 NVMe boot issues on RockPro64 Punit Agrawal
2020-08-29 0:30 ` Punit Agrawal
2020-08-29 7:03 ` Bin Meng
2020-08-29 7:03 ` Bin Meng
2020-08-30 0:16 ` Punit Agrawal [this message]
2020-08-30 0:16 ` Punit Agrawal
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=87o8mtyom9.fsf@tinker \
--to=punitagrawal@gmail.com \
--cc=awilliams@marvell.com \
--cc=bmeng.cn@gmail.com \
--cc=jagan@amarulasolutions.com \
--cc=kever.yang@rock-chips.com \
--cc=linux-rockchip@lists.infradead.org \
--cc=patrick@blueri.se \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.