Linux Kernel 6.10.11 Kirkwood package and Debian rootfs

safarik,

Try

NSA325> setenv bootargs 'console=ttyS0,115200 earlyprintk=serial root=/dev/md0 rw rootwait loglevel=8 print_fatal_signals=1 mtdparts=nand_mtd:0x100000(uboot),0x80000(uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kernel_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2)'

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bodhi Thanks for tip, but adding =serial does not change anything. It stops at "Calibrating delay loop...".

@davidebg Yes I disabled CODA via menuconfig and after that (and applying bodhis patch correctly) it compiles with CodeBench and also with debian gcc (gcc-arm-none-eabi package).

My config -> http://pastebin.com/RcQKkzd5

When I search on internet about simillar problem. People often solve it by "recompiling device tree" -> http://forums.xilinx.com/t5/Embedded-Linux/Got-stuck-on-Calibrating-delay-loop/td-p/259874 .

I see that this is something about the .dtb file that is describing the device for kernel. But I have no idea how to do it. Might that be relevant?

safarik,

Something about your earlyprintk that does not seems to work. I would expect to see more in serial console (I could have remembered incorrectly, though).

> When I search on internet about simillar problem.
> People often solve it by "recompiling device tree"
> ->
> http://forums.xilinx.com/t5/Embedded-Linux/Got-stu
> ck-on-Calibrating-delay-loop/td-p/259874 .
>
> I see that this is something about the .dtb file
> that is describing the device for kernel. But I
> have no idea how to do it. Might that be relevant?

Ah. I remember now. That could be one of the reasons. Yes, make sure you have a good DTB. Just look at the build tree in ./arch/arm/boot/dts for the DTBs. You should have the DTB for your box compiled there while the kernel is built (timestamp is new or not).

PS.

Does uImage.raid1 has the DTB embedded to it?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 03/20/2015 03:56AM by bodhi.

@bodhi DTB has the time when I compiled the kernel. If I understand it correctly DTB is included in the uImage.

safarik@ts-n:~/00zyxel/vanilla/linux-3.18.5/arch/arm/boot/dts$ ls -la kirkwood-nsa325*
-rw-r--r-- 1 root root 14262 bře 19 14:37 kirkwood-nsa325.dtb
-rw-r--r-- 1 root root  6768 bře 19 11:02 kirkwood-nsa325.dts

safarik Wrote:
-------------------------------------------------------
> @bodhi DTB has the time when I compiled the
> kernel. If I understand it correctly DTB is
> included in the uImage.
>
>

> safarik@ts-n:~/00zyxel/vanilla/linux-3.18.5/arch/a
> rm/boot/dts$ ls -la kirkwood-nsa325*
> -rw-r--r-- 1 root root 14262 bře 19 14:37
> kirkwood-nsa325.dtb
> -rw-r--r-- 1 root root  6768 bře 19 11:02
> kirkwood-nsa325.dts
>

It has to be embedded manually after built (not automatically).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------
> It has to be embedded manually after built (not
> automatically).

That was the missing piece. Now it boots.

cat dts/kirkwood-nsa325.dtb >> zImage
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n "Linux kernel" -d zImage uImage

Thanks

And the md autodetection does not work as davidbg mentioned :)

[    2.270045] md: Waiting for all devices to be available before autodetect
[    2.276914] md: If you don't use raid, use raid=noautodetect
[    2.283243] md: Autodetecting RAID arrays.
[    2.287361] md: Scanned 0 and added 0 devices.
[    2.291814] md: autorun ...
[    2.294656] md: ... autorun DONE.

My next step will be testing if the autodetection works with 0.90 superblocks as some documentation suggest this. Will inform about the results.

Thanks for your help so far.



Edited 1 time(s). Last edit at 03/20/2015 07:12AM by safarik.

Still no luck, but I have a feeling that my kernel is missing something that may be compiled as module in bodhis and my SATA disks are not fully initialized.

Bacuse in bodhis boot I can see:

[    5.494017] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
[    5.534043] ata1.00: ATA-9: ST3000DM001-1CH166, CC27, max UDMA/133
[    5.540250] ata1.00: 5860533168 sectors, multi 0: LBA48 NCQ (depth 31/32)
[    5.604041] ata1.00: configured for UDMA/133
[    5.624308] scsi 1:0:0:0: Direct-Access     ATA      ST3000DM001-1CH1 CC27 PQ: 0 ANSI: 5
[    5.885112] scsi 0:0:0:0: Direct-Access     iT1167   USB Flash Disk   0.00 PQ: 0 ANSI: 2
[    5.917421] sd 1:0:0:0: [sda] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[    5.926940] sd 1:0:0:0: [sda] 4096-byte physical blocks
[    5.932347] sd 0:0:0:0: [sdb] 7793544 512-byte logical blocks: (3.99 GB/3.71 GiB)
[    5.940129] sd 1:0:0:0: [sda] Write Protect is off
[    5.945028] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    5.950241] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    5.960482] sd 0:0:0:0: [sdb] Write Protect is off
[    5.966145] sd 0:0:0:0: [sdb] Mode Sense: 00 00 00 00
[    5.971688] sd 0:0:0:0: [sdb] Asking for cache data failed
[    5.977304] sd 0:0:0:0: [sdb] Assuming drive cache: write through
[    6.025017]  sda: sda1
[    6.028873] sd 1:0:0:0: [sda] Attached SCSI disk
[    6.134020] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
[    6.174043] ata2.00: ATA-9: ST3000DM001-1CH166, CC27, max UDMA/133
[    6.180254] ata2.00: 5860533168 sectors, multi 0: LBA48 NCQ (depth 31/32)
[    6.244043] ata2.00: configured for UDMA/133
[    6.264307] scsi 2:0:0:0: Direct-Access     ATA      ST3000DM001-1CH1 CC27 PQ: 0 ANSI: 5
[    6.273734] sd 2:0:0:0: [sdc] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[    6.282206] sd 2:0:0:0: [sdc] 4096-byte physical blocks
[    6.287705] sd 2:0:0:0: [sdc] Write Protect is off
[    6.292517] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[    6.297691] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    6.365512]  sdc: sdc1
[    6.369367] sd 2:0:0:0: [sdc] Attached SCSI disk
[    6.438788]  sdb: sdb1
[    6.444559] sd 0:0:0:0: [sdb] Attached SCSI removable disk
[    6.493630] sd 1:0:0:0: Attached scsi generic sg0 type 0
[    6.508492] sd 0:0:0:0: Attached scsi generic sg1 type 0
[    6.517821] sd 2:0:0:0: Attached scsi generic sg2 type 0

But my boot has only:

[    2.490839] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
[    2.497235] usb 1-1: new high-speed USB device number 2 using orion-ehci
[    2.520868] ata1.00: ATA-9: ST3000DM001-1CH166, CC27, max UDMA/133
[    2.527089] ata1.00: 5860533168 sectors, multi 0: LBA48 NCQ (depth 31/32)
[    2.652281] usb 1-1: New USB device found, idVendor=05e3, idProduct=0608
[    2.659022] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[    2.666213] usb 1-1: Product: USB2.0 Hub
[    2.671083] hub 1-1:1.0: USB hub found
[    2.675156] hub 1-1:1.0: 4 ports detected
[    2.750874] ata1.00: configured for UDMA/133
[    2.771100] scsi 0:0:0:0: Direct-Access     ATA      ST3000DM001-1CH1 CC27 PQ: 0 ANSI: 5
[    2.961156] usb 1-1.2: new high-speed USB device number 3 using orion-ehci
[    3.147407] usb 1-1.2: New USB device found, idVendor=048d, idProduct=1167
[    3.154329] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    3.161691] usb 1-1.2: Product: USB Mass Storage Device
[    3.166936] usb 1-1.2: Manufacturer: ITE Technology
[    3.171850] usb 1-1.2: SerialNumber: 100530d2123118
[    3.280838] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
[    3.320861] ata2.00: ATA-9: ST3000DM001-1CH166, CC27, max UDMA/133
[    3.327071] ata2.00: 5860533168 sectors, multi 0: LBA48 NCQ (depth 31/32)
[    3.570863] ata2.00: configured for UDMA/133
[    3.591057] scsi 1:0:0:0: Direct-Access     ATA      ST3000DM001-1CH1 CC27 PQ: 0 ANSI: 5
[    3.599836] md: Waiting for all devices to be available before autodetect
[    3.606694] md: If you don't use raid, use raid=noautodetect
[    3.613003] md: Autodetecting RAID arrays.
[    3.617112] md: Scanned 0 and added 0 devices.
[    3.621601] md: autorun ...
[    3.624401] md: ... autorun DONE.

So if anyone could help me identify what part of kernel is responsible for:

[    6.264307] scsi 2:0:0:0: Direct-Access     ATA      ST3000DM001-1CH1 CC27 PQ: 0 ANSI: 5
[    6.273734] sd 2:0:0:0: [sdc] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[    6.282206] sd 2:0:0:0: [sdc] 4096-byte physical blocks
[    6.287705] sd 2:0:0:0: [sdc] Write Protect is off
[    6.292517] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[    6.297691] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    6.365512]  sdc: sdc1
[    6.369367] sd 2:0:0:0: [sdc] Attached SCSI disk

That might help me to find out what I am missing...

Thanks in advance.

EDIT: I already compiled in sata_mv that seem necessary for marvell board. But that is probably not all.



Edited 1 time(s). Last edit at 03/20/2015 08:49AM by safarik.

@safarik:

I compared your attached .config with bodhi's (config-3.18.5-kirkwood-tld-2).
Only differences are: (Bodhi's -> Safarik):

CONFIG_ASYNC_CORE=m -> y
CONFIG_ASYNC_MEMCPY=m -> y
CONFIG_ASYNC_PQ=m -> y
CONFIG_ASYNC_RAID6_RECOV=m -> y
CONFIG_ASYNC_XOR=m -> y
CONFIG_BLK_DEV_MD=m -> y
CONFIG_CODA_FS=m -> n
CONFIG_MD_AUTODETECT=n -> y
CONFIG_MD_FAULTY=m -> y
CONFIG_MD_LINEAR=m -> y
CONFIG_MD_MULTIPATH=m -> y
CONFIG_MD_RAID0=m -> y
CONFIG_MD_RAID10=m -> y
CONFIG_MD_RAID1=m -> y
CONFIG_MD_RAID456=m -> y
CONFIG_RAID6_PQ=m -> y
CONFIG_XOR_BLOCKS=m -> y

OTOH, of these settings, none seem to be related to your error.
Anyway, just to rule out if there's smth else, please try to compile with Bodhi's .config and see if kernel boots - it should at least arrive to the point where it tries to mount rootfs.
If you already tried this, and changed nothing else (except these settings above), then I would say you should try to reintroduce just what you really need:

CONFIG_BLK_DEV_MD=y
CONFIG_MD_AUTODETECT=y
CONFIG_MD_RAID1=y

and see if it boots any farther.

--
DavideDG
My NAS userspace configs
My Zyxel NSA325 mod
My D-Link DNS325 mod
My Lacie NS2MAX mod

@davidedg

My .config is based on bodhis but main difference is that bodhis kernel has also initrd. And I don't use initrd at all. So if there is something compiled as module (=m) it is not available for me.

Tomas

@Tomas,

I'd suggest it's time to move this MD-related booting problem to a new thread! you can repost or point to the starting point of try to bring up run MD.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

As I couldn't make kernel 3.18.5 boot from an Intenso 8GB stick (though one of the same batch worked with Arch's 3.19) and resorted to 3.16 instead in http://forum.doozan.com/read.php?3,19419,20577#msg-20577, I am happy to report that with one more Xlyne stick of similar speed and capacity (and less of a Blinkenlight :)) that had been in the mail, going through the steps for method 4b as su (re-arranged for minimal input & risk of error) worked just fine:

umount /dev/sdl1
mkfs.ext3 /dev/sdl1 -L rootfs
mount /dev/sdl1 /media/sdl1
cd /media/sdl1
tar -xjvf /home/user/Downloads/Pogoplug_E02/Downloads/Debian-3.18.5-kirkwood-tld-1-rootfs-bodhi.tar.bz2
sed -i s/ext2/ext3/ etc/fstab
cd boot
cp -a zImage-3.18.5-kirkwood-tld-1 zImage.fdt
cat dts/kirkwood-pogo_e02.dtb >>zImage.fdt
cp uImage uImage.orig
cp uInitrd uInitrd.orig
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-3.18.5-kirkwood-tld-1 -d zImage.fdt uImage
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-3.18.5-kirkwood-tld-1 -d initrd.img-3.18.5-kirkwood-tld-1 uInitrd
sync
cd ~
umount /dev/sdl1
sync

YMMV as regards paths, filenames for machines other than -potentially picky- E02, and IP addresses of course.

nc -up 6666 192.168.2.94 6666


U-Boot 2014.07-tld-2 (Sep 20 2014 - 00:52:18)
Pogo E02
gcc (Debian 4.6.3-14) 4.6.3
GNU ld (GNU Binutils for Debian) 2.22
Hit any key to stop autoboot:  0 
(Re)start USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80008c80
5 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
Unknown command 'mmc' - try 'help'
Unknown command 'ide' - try 'help'

Partition Map for USB device 0  --   Partition Type: DOS

Part	Start Sector	Num Sectors	UUID		Type
  1	2528      	15480352  	384eb3b0-01	0b
loading envs from usb 0 ...
** File not found /boot/uEnv.txt **
Unknown command 'mmc' - try 'help'
Unknown command 'ide' - try 'help'
(Re)start USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80008c80
5 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
2875892 bytes read in 453 ms (6.1 MiB/s)
6535284 bytes read in 613 ms (10.2 MiB/s)
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Linux-3.18.5-kirkwood-tld-1
   Created:      2015-03-28  19:29:29 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2875828 Bytes = 2.7 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 01100000 ...
   Image Name:   initramfs-3.18.5-kirkwood-tld-1
   Created:      2015-03-28  19:29:43 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    6535220 Bytes = 6.2 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK


Starting kernel ...

TEN Wrote:

> -20577, I am happy to report that with one more
> Xlyne stick of similar speed and capacity (and
> less of a Blinkenlight :)) that had been in the
> mail, going through the steps for method 4b as su
> (re-arranged for minimal input & risk of error)
> worked just fine

Cool! and to make boot log less noisy and help with low "spinnup" USB devices (EHCI timeout), these u-boot envs can be set, respectively:

devices=usb
usb_ready_retry=15

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi wrote:
> TEN wrote:
> > happy to report that with one more Xlyne stick
> > of similar speed and capacity [...] method 4b as
> > su (re-arranged for minimal input & risk of error)
> > worked just fine

Sadly kernel 3.18.5's implementation of LIRC seems way too crash-prone for production, cf. http://forum.doozan.com/read.php?2,20609,20753#msg-20753 while I got 3.16 to work very well.

> Cool! and to make boot log less noisy and help
> with low "spinnup" USB devices (EHCI timeout),
> these u-boot envs can be set, respectively:

devices=usb
usb_ready_retry=15

Is NAND is always included no matter what "devices" says?

The EHCI timeout makes no perceptible difference as the unhandled devices are "spinning media" of a very different kind: http://www.dacal.com.tw/cd-library-ii/ and their built-in USB hubs (with only one more out of their logical 4 ports each actually exposed on the case, hosting the PL2302 and mceusb respectively).



Edited 2 time(s). Last edit at 03/29/2015 04:40AM by TEN.

TEN,

> Is NAND is always
> included no matter what "devices" says?

Yes, devices here only meant to include storage devices type for booting.

> The EHCI timeout makes no perceptible difference
> as the unhandled devices are "spinning media" of a
> very different kind:
> http://www.dacal.com.tw/cd-library-ii/ and their
> built-in USB hubs (with only one more out of their
> logical 4 ports each actually exposed on the case,
> hosting the PL2302 and mceusb respectively).

Is the link above correct? :) in any case the USB detection retry env only meant to help the usb disk and hub. We don't really mind if other devices did not get enumerated.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi wrote:
> Is the link above correct? :)

Not exactly, mine are as black (with a nod to Henry Ford ;-)) as my "Pink" Pogos, rather than white as in http://www.dacal.com.tw/cd-library-ii/

Thanks to the unchanged form factor, what they really host are all-seasons BluRays (liberated from their often unreasonably damage-prone cardboard sleeves) or DVDs of everything I should have seen on TV and intend to catch up on Really Soon Now.

There are http://git.cryptocrack.de/cdlib-eject.git/ and http://codeflow.org/entries/2010/aug/18/cdlibrary-a-driver-to-dacal-cd-library-2-devices/ to control them - though unfortunately no way to read out the current disc number (or panel events users might trigger to rotate it) and possibly door status has been found yet.

Being in "radio shadow" for quite a while is actually what inspired me to put a streaming VDR for DVB-T on the Dockstar that wasn't.



Edited 3 time(s). Last edit at 03/29/2015 07:53AM by TEN.

@bodhi,

sorry for posting unrelated stuff to this thread. But as I managed to solve the problem (I was missing built-in SCSI support) and I don't want to open new thread just for one post.

To sum up:
- loading kernel image from RAID parition works
(superblock version 0.90 + ext4)

- autodetection and assemble of RAID1 device works at boot time without initrd
(superblock version 0.90 + ext4 + krnel builtin SCSI, SD, MARVELL SATA, MD, RAID1)

I did not finish my installation yet but I plan to install standard debian with debian installer image with modified kernel (as mentioned above) with root and boot partition placed on one RAID1 array with superblock version 0.90 and ext4.

EDIT: I did the planned installation without any problem and now I am running standard debian booting from HDD RAID1 partition.

Thanks so far for all the help,

Tomas

bodhi Wrote:
-------------------------------------------------------
> @Tomas,
>
> I'd suggest it's time to move this MD-related
> booting problem to a new thread! you can repost or
> point to the starting point of try to bring up run
> MD.



Edited 1 time(s). Last edit at 03/30/2015 06:32PM by safarik.

@davidedg,

I vaguely remember you've asked about if I would include MDADM support in initrd. I believe you have done that in your customed initramfs. Do you have a simple hook script in there or is it something more elaborate? if it is just some simple steps then I think it would be OK to add it to the kernel release.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------
> I vaguely remember you've asked about if I would
> include MDADM support in initrd. I believe you
> have done that in your customed initramfs. Do you
> have a simple hook script in there or is it
> something more elaborate? if it is just some
> simple steps then I think it would be OK to add it
> to the kernel release.

When you install mdadm package, it installs a hook file for update-initramfs script.
This hook file is: /usr/share/initramfs-tools/hooks/mdadm
So when update-initramfs is called, some new files get included in the initrd:
- Kernel Modules ("modules" variable in hook file)
- scripts/local-top/mdadm (from /usr/share/initramfs-tools/scripts/local-top/mdadm)
- configuration files

If config is missing, I believe that the mdadm script will try and build a new one (using --scan).
So I think we'd just need to incude mdadm in rootfs and to let it update initrd.

Is your initrd the standard Debian's one (i refer to 7.x, not Jessie).
I might try it but should think of a good test scenario (in qemu/similar - as I can't destroy my nas right now :P).

--
DavideDG
My NAS userspace configs
My Zyxel NSA325 mod
My D-Link DNS325 mod
My Lacie NS2MAX mod

davidedg,

> Is your initrd the standard Debian's one (i refer
> to 7.x, not Jessie).

Yes, it is generated automatically from the build. So according to what you stated above, it will be standard and we can make use of it without doing anything extra. Thanks! I'll create a test rootfs for this purpose and see how it goes.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I searched for mention of this issue, but didn't see anything mentioning any problems with mounting through the usb3 connections. I had a roots failure and updated to the last release. February I believe. Has anyone had problems with no other disk being recognized? I've updated and upgraded, but fdisk doesn't pick up on any other disks. I've installed several times with different flash drives to find the same result. Also have gone to another release where the hardware shows up, so I've eliminated the plug series 4. If there is an easy fix or a post I missed, please point me in the right direction. Thanks

t3ch42,

> I've eliminated the plug series 4. If there is an
> easy fix or a post I missed, please point me in
> the right direction. Thanks

There is nothing special done to the Pogo V4 to access USB 3.0 ports. The only thing you can't do is to boot with the rootfs attached to USB3 (the top port USB 2.0 must be used for booting). Once in Debian, the USB 3.0 ports are fully accessible.

If you have problem, it is best to post output of

- if there is serial console then post the serial boot log.
- dmesg output (the entire log)
- lsub -v
- dmesg output when the USB 3.0 disk is plugged in.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 04/11/2015 07:44PM by bodhi.

FYI,

I'm going to release kernel 4.0.0-kirkwood and 4.0.0-oxnas. However, there is a caveat: USB 3.0 is broken again in Linux kernel 4.0 ;) I don't know if any "quirks" is available to work around this problem with initialing the 3.0 root hub.

Because a majority number of Kirkwood and Oxnas Pogoplugs don't have USB 3.0, I thought it's a minor problem, where one can stay with kernel 3.18.5 if USB 3.0 is currently used in their boxes.

If anybody knows a quirk that can get around this, please post. I'd figure people will start reporting this bug soon and we'll have a patch.

[   22.745342] xhci_hcd 0000:01:00.0: xHCI Host Controller
[   22.750641] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 3
[   22.961456] xhci_hcd 0000:01:00.0: Host took too long to start, waited 16000 microseconds.
[   22.975043] xhci_hcd 0000:01:00.0: startup error -19
[   22.980168] xhci_hcd 0000:01:00.0: USB bus 3 deregistered
[   22.990077] xhci_hcd 0000:01:00.0: remove, state 4
[   22.995532] usb usb2: USB disconnect, device number 1

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 04/14/2015 11:28PM by bodhi.

Kernel 4.0.0-kirkwood-tld-1 package has been uploaded. Please see 1st post for download link.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

updated to 4.0.0 kernel on two iConnect devices and WIFI doesn't work anymore.

On both devices, the problem seens to be the same:

[   16.121022] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 3071, rev 0213 detected
[   16.129860] ieee80211 phy0: rt2800_init_eeprom: Error - Invalid RF chipset 0x0000 detected
[   16.138326] ieee80211 phy0: rt2x00lib_probe_dev: Error - Failed to allocate device

[   15.952714] rt2800pci 0000:01:00.0: enabling device (0140 -> 0142)
[   15.996673] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 3090, rev 3212 detected
[   16.042870] ieee80211 phy0: rt2800_init_eeprom: Error - Invalid RF chipset 0x0000 detected
[   16.053360] ieee80211 phy0: rt2x00lib_probe_dev: Error - Failed to allocate device

No problems before (Kernel 3.18.5)

Hi,

sorry but the same situation here after updating one of two iconnects, this one with
an AR9285 Wireless Network Adapter (PCI-Express) which was fine with 3.18.5, same problem,..
there is something wrong with pcie,.. and initialisation of socs attached to pcie,..

[   17.580843] pci 0000:00:01.0: enabling device (0140 -> 0142)
[   17.772134] ath: phy0: Couldn't reset chip
[   17.776435] ath: phy0: Unable to initialize hardware; initialization status: -5
[   17.795882] ath9k 0000:01:00.0: Failed to initialize device
[   17.801574] ath9k: probe of 0000:01:00.0 failed with error -5

best wishes pbg4

p.s.

@bodhi,

I am currently testing the dvb-usb-dw2102 patch for the tt-s2-4600 included
in your kernel since 3.14 with 4.0.0 which may become superfluous
from version linux-kernel 4.1 onwards,.. I am going to comment this more here in the forum
if I have finished the testing phase,
I have contact with Olli Salonen who brings the necessary patches in linux-media git upstream,..
for the testing it would be extremely helpfull to have
CONFIG_DYNAMIC_DEBUG=y enabled to use dynamic debuging with kernel modules,
so just in case you rebuild because of the wlan problem, please be so kind and include it :)

it does not make too much a size difference, I have recompiled 3.18.5 and the size of uImage
went only up from 2877018 to 3030786, the kernel in the ubuntu mainline ppa also have dynamic
debugging enabled,

pbg4 & pengu,

Yes, I've confirmed seeing this error on iConnect also. Please downgrade to 3.18.5 until we can debug this problem.

@pbg4,

Regarding CONFIG_DYNAMIC_DEBUG, sure, I think we will need Linux 4.1 anyway. But if we can figure out this iConnect wifi problem then I'll release another version earlier.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@pbg4,

This iConnect wifi regression and the USB 3.0 on the Pogoplug V4 and NSA325 might have the same cause: PCI. Too much of coincidence?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi,

@bodhi

yes, that's what I would suspect also, something went wrong after the initialisation of pci/pcie
and the probing of devices afterwards, according to dmesg messages of kernel 3.18.5 and
4.0.0 its all identical, only difference is, the probing after:

pci 0000:00:01.0: enabling device (0140 -> 0142)

goes wrong with kernel 4.0.0, and the usb 3.0 chip of Pogoplug V4 and NSA325 are most likely also attached via
pci, so its not a regression with wifi, but with pci, I have already tried to diff all the relevant pci.c and pcie.c routines
of 3.18.5 and 4.0.0, .. but perhaps not thorough enough, a search in lkml also did not give any clues,
perhaps its a timing problem with armv5,

best wishes pbg4