New Installtion on 5Big - Trouble adding disks

[mattenwright]

Not a problem at all! And I'm happy to help!

Its not a critical thing by any stretch, but let me know what you need next :-)

[fvdw]

Not a problem at all! And I'm happy to help!

Its not a critical thing by any stretch, but let me know what you need next :-)

Oke for the moment could you post output of this command when you 5big1 is running

Code: Select all

cat /proc/interrupts

It seems that the gpio_keys driver is making a conflict with irq used for hard disk

If IRQ for stat_mv is 52 I understand why boot hangs, becuase it than disables access to the hard disks
The value in the first column is the irq number

And what is inside the folder /proc/irq/52 ?

[mattenwright]

Here's the output from interrupts:

Code: Select all

root@LaCie5Big1-fvdw:/ # cat /proc/interrupts
           CPU0       
  0:     172707  orion_irq  orion_tick
  3:        358  orion_irq  serial
  5:        580  orion_irq  mv64xxx_i2c
 17:          0  orion_irq  ehci_hcd:usb1
 21:      22975  orion_irq  eth0
 22:       5422  orion_irq  orion-mdio
 29:          0  orion_irq  sata_mv
 52:       9022  orion_gpio0  52  sata_mv
Err:          0


And the contents of proc/irq/52

Code: Select all

root@LaCie5Big1-fvdw:/ # ls /proc/irq/52 -lah
total 0
dr-xr-xr-x   3 root root 0 2020-09-27 19:54 .
dr-xr-xr-x  66 root root 0 2020-09-27 19:54 ..
dr-xr-xr-x   2 root root 0 2020-09-27 19:54 sata_mv
-r--r--r--   1 root root 0 2020-09-27 19:54 spurious


So that does seem to make sense... indeed it does look like its conflicting.

[fvdw]

:thumbup thanks
Indeed this confirms that if irq 52 is disbaled to access to the disk is gone. Now we need to find out why the kernel wants to disable it

Lets go back to a kernel from which we know that it runs fine with gpio_keys driver and see which irq's we have there

Attached a kernel from the past UIMAGE-26394-5BIG1-39
This kernel has the gpio_keys driver activate and seems to run fine.
Could you try to load as external kernel using fvdw-sl console and post output of

Code: Select all

cat /proc/interrupts

and the content of corresponding folders of the irq related to sata_mv and buttons
This to see which irq's are used in that kernel

ps the kernel modules for this kernel are not included in the firmware so you will get some errors in boot.log however for this test it should not be a problem

[uelpenich]

What kind of info do you need?
. . .
I have a little experience with JTAG (I would need some guidance), and I'm up for soldering if need be.
. . .
I also run a few Linux machines and some windows machines.
Feel free to PM me or email me.

This is the way I did a Jtag interface for my 5BIG1:
You'll find the Jtag interface as J29 pins beside the off - auto - on switch:
Pin 2 - common (common on jack)
Pin 7 - transmit (right channel on jack)
Pin 8 - receive (left channel on jack)
Speed 115000

I installed a earphone jack for easy connection.

[mattenwright]

Sorry about the delay... hellish past week and a half.

Here's the output of cat /proc/interrupts from the older kernel:

Code: Select all


root@LaCie5Big1-fvdw:/ # cat /proc/interrupts
           CPU0
  0:      11119  orion_irq  orion_tick
  3:        492  orion_irq  serial
  5:        138  orion_irq  mv64xxx_i2c
 17:          0  orion_irq  ehci_hcd:usb1
 21:       4538  orion_irq  eth0
 22:         67  orion_irq  mv643xx_eth
 29:          0  orion_irq  sata_mv
 36:          0  orion_gpio_irq  Front Push Button
 40:          0  orion_gpio_irq  Power rocker switch (on|auto)
 41:          0  orion_gpio_irq  Power rocker switch (auto|off)
 52:       5772  orion_gpio_irq  sata_mv
Err:          0



[mattenwright]

@uelpenich

Thanks for the JTAG info!
That's a rather handy jack you've setup

[fvdw]

thank you, so assignement of irq to the buttons gpio pins is not causing a conflict.

After some more reading on the internet
The message "nobody cared (try booting with the "irqpoll" option) " is a result of a bad irq request, meanaing irq not assigned to appropioate gpio in this case.
gpio pins of 5big1 get irq number : 32 + gpio number,
the first 32 irqs are reseved for other purposes
Because it is irq 52 that fails and gpio used for PCI initialization is 20 it means it should be link to irq 52
We see this message in serial ouput when booting the kernel

Code: Select all

net5big_pci_preinit failed to gpio_request 20

(thanks to Uelpenich for the test with serial interface)

Therefor it is likely that the irq 52 issue is a result from a failing prei-init pcie call in 5big setup file in which irq will be assigned to this pin when the function gives no error (like in 2.6.39.4 kernel).

PS. Why the 3.14.2 kernel doesn't has this problem when no gpio_keys driver is added is still a question mark for me.

Anyhow, to see if we are on the right trak, please test attached kernel, it has a modified setup file for 5big1 that might solve the pre-init PCI error, and if not print some info what is going on in the pre-init function call and what error code makes it fail.

Note This output will probably only visible when using serial console (jtag) output, the net console will not show this output because netconsole activation in the kernel is after initialization routines.

[fvdw]

Thank you for testing Uelpenich :thumbup
@mattenwright are you able to hook the serial port ?


Some progress with kernel 18 the pci pre-init error is gone, (return value is 0, that means succeeded

Code: Select all

[   17.485565] 5big1 init end
[   17.486605] fvdw 1 net5big: net5big_pci_preinit for pin 20
[   17.486631] fvdw 2 net5big: net5big_pci_preinit gpio_request returned 0
[   17.486647] fvdw gpiolib offset 20 =gpio nr

so failing of the pre-init can no longer be a reason, I will add a printk to see which irq is assigned to this pin. (I expect 52).

However still failure that irq 52 is disabled.

Code: Select all

[   20.527710] sd 4:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   20.536760] fvdw sd_read_cache_type 1
[   20.540415] fvdw sd_probe_async 3
[   20.543730] fvdw sd_probe_async 4
[   20.547489] fvdw genhd add_disk 5
[   20.551126] fvdw register_disk 8
[   20.555498] fvdw sd_read_cache_type 1
[   20.607779] random: nonblocking pool is initialized
[   21.035904] irq 52: nobody cared (try booting with the "irqpoll" option)

It seems to happen in a function called in sd.c (scsi driver) sd_revalidate_disk
As it is the only place where function sd_read_cache is called which seems to be the last activity reported in kernel output before it disables irq52, the function call register_disk called in genhd.c never returns otherwise we would have seen fvdw register_disk 9 in the output.
I have put some additional printk's in the revalidate function to try get closer to the place were the disabling takes place.
Attached kernel 19

[mattenwright]

@Uelpenich and @fvdw

Again, sorry about the delay, life seems to find a way to get in the way :hammerhead

I'm having some difficulty with the serial interface it may be my soldering, it may just be something else... I will have to re-check to be sure. But I'm not getting anything to my FT232 adapter. I've also tried with a couple other tools, and I still get nothing to it. I have a panel mount jack on order (thought I had one in my parts bin... but I do not) to eliminate any weird wire glitches, and to tidy everything up.

I'm still getting the same output on the netconsole... and as soon as I have double checked everything and added a panel mount jack, I will see if I can get something out of the serial port.