Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #53231 > unrolled thread

Bug#818598: src:linux: MTD device probe failed after migrating kernel variant from -orion5x to -marvell

Back to article view | Back to linux.debian.kernel

Contents

  Bug#818598: src:linux: MTD device probe failed after migrating kernel variant from -orion5x to -marvell Roger Shimizu <rogershimizu@gmail.com> - 2016-03-18 15:20 +0100
    Processed: src:linux: MTD device probe failed after migrating  kernel variant from -orion5x to -marvell owner@bugs.debian.org (Debian Bug Tracking System) - 2016-03-18 15:20 +0100
    Bug#818598: src:linux: MTD device probe failed after migrating kernel variant from -orion5x to -marvell Roger Shimizu <rogershimizu@gmail.com> - 2016-03-20 16:50 +0100
      Bug#818598: src:linux: MTD device probe failed after migrating kernel variant from -orion5x to -marvell Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org> - 2016-03-22 13:30 +0100
        Bug#818598: src:linux: MTD device probe failed after migrating kernel variant from -orion5x to -marvell Roger Shimizu <rogershimizu@gmail.com> - 2016-03-22 14:10 +0100
          Bug#818598: src:linux: MTD device probe failed after migrating kernel variant from -orion5x to -marvell Roger Shimizu <rogershimizu@gmail.com> - 2016-03-23 10:40 +0100
            Bug#818598: src:linux: MTD device probe failed after migrating kernel variant from -orion5x to -marvell Ben Hutchings <ben@decadent.org.uk> - 2016-03-23 19:20 +0100
              Bug#818598: src:linux: MTD device probe failed after migrating kernel variant from -orion5x to -marvell Roger Shimizu <rogershimizu@gmail.com> - 2016-03-24 00:40 +0100
    Processed: Re: Bug#818598: src:linux: MTD device probe failed  after migrating kernel variant from -orion5x to -marvell owner@bugs.debian.org (Debian Bug Tracking System) - 2016-03-30 12:40 +0200

#53231 — Bug#818598: src:linux: MTD device probe failed after migrating kernel variant from -orion5x to -marvell

Package: src:linux
Version: 4.4.6-1
Severity: normal
Control: notfound -1 4.4-1~exp1
Control: found -1 4.4.1-1~exp1
X-Debbugs-Cc: rogershimizu@gmail.com

Dear Maintainer,

I found my orion5x based Linkstation started to fail probing MTD
device, which stores u-boot binary and environment, after variant
migration from -orion5x to -marvell.

Kernel log with version info is like the following:

Linux LS-GL 4.4.0-trunk-orion5x #1 Debian 4.4-1~exp1 (2016-01-19)
armv5tel GNU/Linux
====
[    1.838495] Found: SST 39LF020
[    1.841662] f4000000.flash: Found 1 x8 devices at 0x0 in 8-bit bank
[    1.847985] number of JEDEC chips: 1
[    1.868437] 3 ofpart partitions found on MTD device f4000000.flash
[    1.874705] Creating 3 MTD partitions on "f4000000.flash":
[    1.880288] 0x000000000000-0x000000030000 : "header"
[    1.888806] 0x000000030000-0x00000003f000 : "uboot"
[    1.897299] 0x00000003f000-0x000000040000 : "uboot_env"
====


Linux LS-GL 4.4.0-trunk-marvell #1 Debian 4.4.1-1~exp1 (2016-02-10)
armv5tel GNU/Linux
====
[    1.716090] Found: SST 39LF020
[    1.719184] f4000000.flash: Found 1 x8 devices at 0x0 in 8-bit bank
[    1.742133] Support for command set 0002 not present
[    1.747188] gen_probe: No supported Vendor Command Set found
[    1.752919] of-flash f4000000.flash: do_map_probe() failed for type
jedec_probe
[    1.771450] of-flash f4000000.flash: do_map_probe() failed
====

I uses the same DTB, which ships with latest sid kernel, to do previous test.
(I put the DTB in /etc/flash-kernel/dtbs/)
It with the patches I applied:
- https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian/patches/features/arm/device-tree?h=sid

I also checked the diff of kernel config for the two kernels, but found no clue.
And, the kirkwood based Linkstation doesn't have this issue.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1

[toc] | [next] | [standalone]

#53232 — Processed: src:linux: MTD device probe failed after migrating kernel variant from -orion5x to -marvell

Processing control commands:

> notfound -1 4.4-1~exp1
Bug #818598 [src:linux] src:linux: MTD device probe failed after migrating kernel variant from -orion5x to -marvell
Ignoring request to alter found versions of bug #818598 to the same values previously set
> found -1 4.4.1-1~exp1
Bug #818598 [src:linux] src:linux: MTD device probe failed after migrating kernel variant from -orion5x to -marvell
Marked as found in versions linux/4.4.1-1~exp1.

-- 
818598: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818598
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#53258

Dear Ian, Martin,

May I know your comment regarding to this armel/orion5x related bug?
I don't know whether qnap also uses MTD to store u-boot related stuff
or not. Just guessing it may have the same issue.
Thank you!

On Fri, Mar 18, 2016 at 11:08 PM, Roger Shimizu <rogershimizu@gmail.com> wrote:
> Package: src:linux
> Version: 4.4.6-1
> Severity: normal
> Control: notfound -1 4.4-1~exp1
> Control: found -1 4.4.1-1~exp1
> X-Debbugs-Cc: rogershimizu@gmail.com
>
> Dear Maintainer,
>
> I found my orion5x based Linkstation started to fail probing MTD
> device, which stores u-boot binary and environment, after variant
> migration from -orion5x to -marvell.
>
> Kernel log with version info is like the following:
>
> Linux LS-GL 4.4.0-trunk-orion5x #1 Debian 4.4-1~exp1 (2016-01-19)
> armv5tel GNU/Linux
> ====
> [    1.838495] Found: SST 39LF020
> [    1.841662] f4000000.flash: Found 1 x8 devices at 0x0 in 8-bit bank
> [    1.847985] number of JEDEC chips: 1
> [    1.868437] 3 ofpart partitions found on MTD device f4000000.flash
> [    1.874705] Creating 3 MTD partitions on "f4000000.flash":
> [    1.880288] 0x000000000000-0x000000030000 : "header"
> [    1.888806] 0x000000030000-0x00000003f000 : "uboot"
> [    1.897299] 0x00000003f000-0x000000040000 : "uboot_env"
> ====
>
>
> Linux LS-GL 4.4.0-trunk-marvell #1 Debian 4.4.1-1~exp1 (2016-02-10)
> armv5tel GNU/Linux
> ====
> [    1.716090] Found: SST 39LF020
> [    1.719184] f4000000.flash: Found 1 x8 devices at 0x0 in 8-bit bank
> [    1.742133] Support for command set 0002 not present
> [    1.747188] gen_probe: No supported Vendor Command Set found
> [    1.752919] of-flash f4000000.flash: do_map_probe() failed for type
> jedec_probe
> [    1.771450] of-flash f4000000.flash: do_map_probe() failed
> ====
>
> I uses the same DTB, which ships with latest sid kernel, to do previous test.
> (I put the DTB in /etc/flash-kernel/dtbs/)
> It with the patches I applied:
> - https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian/patches/features/arm/device-tree?h=sid
>
> I also checked the diff of kernel config for the two kernels, but found no clue.
> And, the kirkwood based Linkstation doesn't have this issue.

-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1

[toc] | [prev] | [next] | [standalone]

#53287

Roger Shimizu <rogershimizu@gmail.com> writes:

Hi,

> Dear Ian, Martin,
>
> May I know your comment regarding to this armel/orion5x related bug?
> I don't know whether qnap also uses MTD to store u-boot related stuff
> or not. Just guessing it may have the same issue.

From a quick look at your logs, your mtd device is needing support for
cmdset 2, provided by cfi_cmdset_0002.ko (CONFIG_MTD_CFI_AMDSTD). Maybe
it's not available when the mtd chip is probed ?
Eg missing in the initrd or should be built-in or something like that ?

Arnaud

[toc] | [prev] | [next] | [standalone]

#53289

Dear Arnaud,

Thanks for your information!

On Tue, Mar 22, 2016 at 9:25 PM, Arnaud Patard
<arnaud.patard@rtp-net.org> wrote:
> Roger Shimizu <rogershimizu@gmail.com> writes:
>
> Hi,
>
>> Dear Ian, Martin,
>>
>> May I know your comment regarding to this armel/orion5x related bug?
>> I don't know whether qnap also uses MTD to store u-boot related stuff
>> or not. Just guessing it may have the same issue.
>
> From a quick look at your logs, your mtd device is needing support for
> cmdset 2, provided by cfi_cmdset_0002.ko (CONFIG_MTD_CFI_AMDSTD). Maybe
> it's not available when the mtd chip is probed ?
> Eg missing in the initrd or should be built-in or something like that ?

I haven't tried your idea yet.
But I did confirm that for 4.4.0-trunk-orion5x (4.4-1~exp1),
cfi_cmdset_0002.ko is never loaded, but MTD is OK.

Please also be noted that both kernel (-orion5x and -marvell) are
doing the MTD probe in around 1.7-1.8 second after kernel boots, at
which time the modules are not loaded yet.
So the driver compiled in the module should be irrelevant. I think the
root cause may be something else.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1

[toc] | [prev] | [next] | [standalone]

#53291

[add Ben to CC list]

Dear Arnaud,

My apology to my previous email.
You were absolutely right!

On Tue, Mar 22, 2016 at 10:07 PM, Roger Shimizu <rogershimizu@gmail.com> wrote:
> Dear Arnaud,
>
> Thanks for your information!
>
> On Tue, Mar 22, 2016 at 9:25 PM, Arnaud Patard
> <arnaud.patard@rtp-net.org> wrote:
>> Roger Shimizu <rogershimizu@gmail.com> writes:
>>
>> Hi,
>>
>>> Dear Ian, Martin,
>>>
>>> May I know your comment regarding to this armel/orion5x related bug?
>>> I don't know whether qnap also uses MTD to store u-boot related stuff
>>> or not. Just guessing it may have the same issue.
>>
>> From a quick look at your logs, your mtd device is needing support for
>> cmdset 2, provided by cfi_cmdset_0002.ko (CONFIG_MTD_CFI_AMDSTD). Maybe
>> it's not available when the mtd chip is probed ?
>> Eg missing in the initrd or should be built-in or something like that ?

Yes. After appending "cfi_cmdset_0002" to /etc/initramfs-tools/modules,
do an "update-initramfs -u", then the MTD becomes probing OK.

And -kirkwood flavour usually takes CONFIG_MTD_CFI_AMDSTD=m
while -orion5x flavour usually takes CONFIG_MTD_CFI_AMDSTD=y

After merging to -marvell, it should take the superset [0],
and set CONFIG_MTD_CFI_AMDSTD=y

I'll make this change if nobody is against with it.

> I haven't tried your idea yet.
> But I did confirm that for 4.4.0-trunk-orion5x (4.4-1~exp1),
> cfi_cmdset_0002.ko is never loaded, but MTD is OK.
>
> Please also be noted that both kernel (-orion5x and -marvell) are
> doing the MTD probe in around 1.7-1.8 second after kernel boots, at
> which time the modules are not loaded yet.
> So the driver compiled in the module should be irrelevant. I think the
> root cause may be something else.

Sorry for my bad human memory.
And thanks again for your favour!

[0] https://lists.debian.org/debian-arm/2016/03/msg00036.html

-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1

[toc] | [prev] | [next] | [standalone]

#53293

[Multipart message — attachments visible in raw view] — view raw

On Wed, 2016-03-23 at 18:29 +0900, Roger Shimizu wrote:
> [add Ben to CC list]
> 
> Dear Arnaud,
> 
> My apology to my previous email.
> You were absolutely right!
> 
> On Tue, Mar 22, 2016 at 10:07 PM, Roger Shimizu  wrote:
> > 
> > Dear Arnaud,
> > 
> > Thanks for your information!
> > 
> > On Tue, Mar 22, 2016 at 9:25 PM, Arnaud Patard
> > <arnaud.patard@rtp-net.org> wrote:
> > > 
> > > Roger Shimizu <rogershimizu@gmail.com> writes:
> > > 
> > > Hi,
> > > 
> > > > 
> > > > Dear Ian, Martin,
> > > > 
> > > > May I know your comment regarding to this armel/orion5x related bug?
> > > > I don't know whether qnap also uses MTD to store u-boot related stuff
> > > > or not. Just guessing it may have the same issue.
> > > From a quick look at your logs, your mtd device is needing support for
> > > cmdset 2, provided by cfi_cmdset_0002.ko (CONFIG_MTD_CFI_AMDSTD). Maybe
> > > it's not available when the mtd chip is probed ?
> > > Eg missing in the initrd or should be built-in or something like that ?
> Yes. After appending "cfi_cmdset_0002" to /etc/initramfs-tools/modules,
> do an "update-initramfs -u", then the MTD becomes probing OK.

I wonder if there's any way we can discover which of these cfi_cmdset
modules is needed...

> And -kirkwood flavour usually takes CONFIG_MTD_CFI_AMDSTD=m
> while -orion5x flavour usually takes CONFIG_MTD_CFI_AMDSTD=y
> 
> After merging to -marvell, it should take the superset [0],
> and set CONFIG_MTD_CFI_AMDSTD=y
> 
> I'll make this change if nobody is against with it.
[...]

Please go ahead.  In the longer term I think we ought to make
initramfs-tools include these, but I don't want the kernel to be tied
to newer initramfs-tools as that will make backporting very difficult..

Ben.

-- 
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.

[toc] | [prev] | [next] | [standalone]

#53300

Dear Ben,

Thanks for your comments!

On Wed, Mar 23, 2016 at 8:47 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Wed, 2016-03-23 at 18:29 +0900, Roger Shimizu wrote:
>> > On Tue, Mar 22, 2016 at 9:25 PM, Arnaud Patard
>> > <arnaud.patard@rtp-net.org> wrote:
>> > > Roger Shimizu <rogershimizu@gmail.com> writes:
>> > > >
>> > > > May I know your comment regarding to this armel/orion5x related bug?
>> > > > I don't know whether qnap also uses MTD to store u-boot related stuff
>> > > > or not. Just guessing it may have the same issue.
>> > > From a quick look at your logs, your mtd device is needing support for
>> > > cmdset 2, provided by cfi_cmdset_0002.ko (CONFIG_MTD_CFI_AMDSTD). Maybe
>> > > it's not available when the mtd chip is probed ?
>> > > Eg missing in the initrd or should be built-in or something like that ?
>> Yes. After appending "cfi_cmdset_0002" to /etc/initramfs-tools/modules,
>> do an "update-initramfs -u", then the MTD becomes probing OK.
>
> I wonder if there's any way we can discover which of these cfi_cmdset
> modules is needed...

I agree.
If initramfs-tools can help to do this, we can safely make those all
to modules without issue.

>
>> And -kirkwood flavour usually takes CONFIG_MTD_CFI_AMDSTD=m
>> while -orion5x flavour usually takes CONFIG_MTD_CFI_AMDSTD=y
>>
>> After merging to -marvell, it should take the superset [0],
>> and set CONFIG_MTD_CFI_AMDSTD=y
>>
>> I'll make this change if nobody is against with it.
> [...]
>
> Please go ahead.  In the longer term I think we ought to make
> initramfs-tools include these, but I don't want the kernel to be tied
> to newer initramfs-tools as that will make backporting very difficult..

Thanks for your understanding!
I know this is just a quick fix. Your initramfs-tools way is final
solution, which just need some time to sort out.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1

[toc] | [prev] | [next] | [standalone]

#53384 — Processed: Re: Bug#818598: src:linux: MTD device probe failed after migrating kernel variant from -orion5x to -marvell

Processing control commands:

> tags -1 +pending
Bug #818598 [src:linux] src:linux: MTD device probe failed after migrating kernel variant from -orion5x to -marvell
Added tag(s) pending.

-- 
818598: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818598
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web