*** Bug 16474 has been marked as a duplicate of this bug. ***

Sorry - bit confused. My problem started with the Touch firmware release before firmware 9056 (whatever that was). It persists with 9056.
Reverting to 8837 repairs the problem.

same with me since about 4 weeks - at least every second nightly fw-update has this issue.
Factory reset helps - till the next update comes... :(

http://forums.slimdevices.com/showthread.php?t=80571

Just tried again today with latest nightly 7.6 SBS and latest firmware 9056 - same semi-bricked effect. Going back to 8837 fixes the problem.
I'm pretty sure I can't be the only person affected by this...

IS there ANY way to take the Touch back to its virgin shipped state? - obviously factory reset doeesn't do that...

Sorry, I meant 9057 firmware...

Hi guys

Just to rule that out: Are you having this issues with production level SB Touch units or are you using beta units? Same question for the power supply. Are you using the original power supply or something different.

I am not saying that has anything to do with it, just gathering more information to help understanding the issue.

I've tested r9062 and r9065 on two SB Touch (late beta and production) units and I am _not_ seeing the issue you describe.

Please add the following information to this bug:

- SB Touch PID number of the units affected
- Power supply model number

Thanks
Felix

Hi Felix. Thanks for looking at this.
Just to reconfirm, the problem for me started at some firmware after version 8837.
My Touch is  a beta unit, PID: LZ98201
PSU: I've tried it last week with 3 different ones with no difference. It's currently connected to the one supplied with the Beta unit. It's buried under my rack at the moment.

I'm running wired ethernet + latest 7.6 SBS by the way.

If I can locate the post 8837 firmwares, I'm willing to try to incrementally upgrade to see exactly which version it was that introduced my problem...
regards
Phil

I am pretty sure you tried that, but I am going to ask anyways. Have you tried without any USB devices attached?

Yes - evenwith no USB devices attached I lose both IR and Touchscreen capability either immediately at bootup or within a few seconds of bootup. With a USB keyboard attached I still lose the capabilities, but the keyboard works OK. A USB mouse also works.

This might be a complete red herring?


I found this post from Caleb - relates to the Radio but vaguely similar symptoms - and I have the same error logged in DMESG...
http://forums.slimdevices.com/showpost.php?p=469491&postcount=17

i2c-adapter i2c-0: ACK not received
lm75: probe of 0-0048 failed with error -1


see below:

Linux version 2.6.26.8-rt16-332-g5849bfa (parabuild@vdc01b01centos01) (gcc versi                                              on 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #1 PREEMPT RT Mon May 17 15:10:46 MDT 2                                              010
CPU: ARMv6-compatible processor [4117b363] revision 3 (ARMv6TEJ), cr=00c5387f
Machine: Logitech Fab4 Board
Memory policy: ECC disabled, Data cache writeback
On node 0 totalpages: 32768
  DMA zone: 48 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 6096 pages, LIFO batch:0
  Normal zone: 208 pages used for memmap
  Normal zone: 26416 pages, LIFO batch:7
  Movable zone: 0 pages used for memmap
CPU0: D VIPT write-back cache
CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets
CPU0: D cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets
Real-Time Preemption Support (C) 2004-2007 Ingo Molnar
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
Kernel command line: console=ttymxc0,115200 noinitrd init=/linuxrc ubi.mtd=1 roo                                              t=/dev/mtdblock:cramfs
Preemptible RCU implementation.
MXC IRQ initialized
PID hash table entries: 512 (order: 9, 2048 bytes)
MXC GPT timer initialized, rate = 16625000
WARNING: Clock divider has been truncated, clock error 150 [ps] per 60 [ns]
Console: colour dummy device 80x30
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB = 128MB total
Memory: 125672KB available (3756K code, 316K data, 152K init)
Calibrating delay loop... 530.84 BogoMIPS (lpj=2654208)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
net_namespace: 276 bytes
NET: Registered protocol family 16
L2X0 cache controller enabled
CPU is i.MX0 Revision 0.5
Clock input source is 24000000
MXC GPIO hardware
Reset status: Watchdog timeout
Using SDMA I.API
MXC DMA API initialized
SCSI subsystem initialized
CSPI: mxc_spi-0 probed
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
MXC I2C driver
clk: Unable to get requested clock: dfm_clk
ASoC version 0.20
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 4, 114688 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
NET: Registered protocol family 1
usb: DR host (utmi) registered
krcupreemptd setsched 0
  prio = 98
Registering unionfs 2.5.1 (for 2.6.26.8)
fuse init (API version 7.9)
msgmni has been set to 245
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
mxc_ipu mxc_ipu: Channel already uninitialized 14
Console: switching to colour frame buffer device 60x34
mxc_ipu mxc_ipu: Channel already uninitialized 15
mxcfb: fb registered, using mode <NULL>
fsl_rngc fsl_rngc: FSL RNGC Registered.
Serial: MXC Internal UART driver
mxcintuart.0: ttymxc0 at MMIO 0x43f90000 (irq = 45) is a Freescale MXC
console [ttymxc0] enabled
mxcintuart.1: ttymxc1 at MMIO 0x43f94000 (irq = 32) is a Freescale MXC
loop: module loaded
FEC ENET Version 0.2
fec: PHY @ 0x1, ID 0x00008201 -- RTL8210CP
eth0: ethernet 00:04:20:22:01:8e
Driver 'sd' needs updating - please use bus_type methods
MXC MTD nand Driver 2.5
NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 3,3V 8-bi                                              t)
Bad block table found at page 65472, version 0x01
Bad block table found at page 65408, version 0x01
nand_read_bbt: Bad block at 0x011a0000
nand_read_bbt: Bad block at 0x022e0000
nand_read_bbt: Bad block at 0x02700000
nand_read_bbt: Bad block at 0x02860000
nand_read_bbt: Bad block at 0x07440000
RedBoot partition parsing not available
cmdlinepart partition parsing not available
Creating 2 MTD partitions on "NAND 128MiB 3,3V 8-bit":
0x00000000-0x00080000 : "redboot"
0x00080000-0x07f40000 : "ubi"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    129024 bytes
UBI: smallest flash I/O unit:    2048
UBI: sub-page size:              512
UBI: VID header offset:          512 (aligned 512)
UBI: data offset:                2048
UBI: attached mtd1 to ubi0
UBI: MTD device name:            "ubi"
UBI: MTD device size:            126 MiB
UBI: number of good PEBs:        1009
UBI: number of bad PEBs:         5
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     5
UBI: available PEBs:             308
UBI: total number of reserved PEBs: 701
UBI: number of PEBs reserved for bad PEB handling: 10
UBI: max/mean erase counter: 1122/58
UBI: background thread "ubi_bgt0d" started, PID 300
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
eth0: status: link up, 100MBit Full Duplex, auto-negotiation complete.
fsl-ehci fsl-ehci.0: irq 37, io mem 0x53ff4000
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
Initializing USB Mass Storage driver...
usb 1-1: new low speed USB device using fsl-ehci and address 2
usb 1-1: configuration #1 chosen from 1 choice
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver usbserial
usbserial: USB Serial support registered for generic
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial Driver core
usbserial: USB Serial support registered for FTDI USB Serial Device
usbcore: registered new interface driver ftdi_sio
ftdi_sio: v1.4.3:USB FTDI Serial Converters Driver
usbserial: USB Serial support registered for Keyspan - (without firmware)
usbserial: USB Serial support registered for Keyspan 1 port adapter
usbserial: USB Serial support registered for Keyspan 2 port adapter
usbserial: USB Serial support registered for Keyspan 4 port adapter
usbcore: registered new interface driver keyspan
keyspan: v1.1.5:Keyspan USB to Serial Converter Driver
usbserial: USB Serial support registered for pl2303
usbcore: registered new interface driver pl2303
pl2303: Prolific PL2303 USB to serial adaptor driver
mice: PS/2 mouse device common for all mice
i2c /dev entries driver
Clearpad: TM1199Logitech (7552,4248)
input: Synaptics ClearPad as /class/input/input0
tsl2569 0-0039: support ver. 1.0 enabled
i2c-adapter i2c-0: ACK not received
lm75: probe of 0-0048 failed with error -1
MXC WatchDog Driver 2.0
MXC Watchdog # 0 Timer: initial timeout 60 sec
IPU Post-filter loading
mxc_asrc registered
input: FAB4 IR as /class/input/input1
firmware: requesting ir_controller_21323.hex
mxsdhci: MXC Secure Digital Host Controller Interface driver
mxsdhci: MXC SDHCI Controller Driver.
mmc0: SDHCI detect irq 0 irq 7 INTERNAL DMA
mxsdhci: MXC SDHCI Controller Driver.
mmc1: SDHCI detect irq 102 irq 8 INTERNAL DMA
mmc0: new SDIO card at address 0001
input: Logitech Logitech USB Keyboard as /class/input/input2
input: USB HID v1.10 Keyboard [Logitech Logitech USB Keyboard] on usb-fsl-ehci.0                                              -1
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
Advanced Linux Sound Architecture Driver Version 1.0.16.
MXC spdif support initialized
usbcore: registered new interface driver snd-usb-audio
AK4420 Audio Codec 0.1<6>DMA Sound Buffers Allocated:UseIram=0 buf->addr=87ea000                                              0 buf->area=fe004000 size=65536
asoc: ak4420-dai <-> imx-ssi-1 mapping ok
WM8974 Audio Codec 0.1
DMA Sound Buffers Allocated:UseIram=0 buf->addr=87ed0000 buf->area=fe014000 size                                              =65536
DMA Sound Buffers Allocated:UseIram=0 buf->addr=87ee0000 buf->area=fe024000 size                                              =65536
asoc: wm8974-hifi-dai <-> imx-ssi-3 mapping ok
fab4 WM8974 Audio Driver
ALSA device list:
  #0: MXC Freescale with SPDIF
  #1: fab4 (ak4420)
  #2: fab4 (wm8974)
oprofile: using arm/armv6
TCP cubic registered
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
ieee80211: 802.11 data/management/control stack, git-1.1.13
ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>
ieee80211_crypt: registered algorithm 'NULL'
mxc_rtc mxc_rtc.0: rtc core: registered mxc_rtc as rtc0
No external RTC clock
Real TIme clock Driver v1.0
mxc_rtc: probe of mxc_rtc.0 failed with error -2
Static Power Management for Freescale i.MX35
VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 3
MXC Backlight Device mxc_ipu_bl.0 Initialized.
platform mxc_rtc.0: setting system clock to 1970-01-01 15:39:46 UTC (56386)
VFS: Mounted root (cramfs filesystem) readonly.
Freeing init memory: 152K
UBIFS: recovery needed
UBIFS: recovery completed
UBIFS: mounted UBI device 0, volume 2, name "ubifs"
UBIFS: file system size:   19869696 bytes (19404 KiB, 18 MiB, 154 LEBs)
UBIFS: journal size:       1032193 bytes (1008 KiB, 0 MiB, 8 LEBs)
UBIFS: media format:       w4/r0 (latest is w4/r0)
UBIFS: default compressor: lzo
UBIFS: reserved for root:  938494 bytes (916 KiB)
FAB4 IR: fw checksum ok aa33
firmware: requesting helper_sd.bin
firmware: requesting sd8686.bin
eth0: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX.
eth0: status: link down.
eth0: status: link up, 100MBit Full Duplex, auto-negotiation complete.
tsl2569: set timing: (1,2): 12
Store Gain: 1
Store Factor: 40

Tried to load 7.6.0 r 8984 - same problem - reverted to 7.5.1 r 8837.

if ssh is unaffected, we should have a look at the syslog

from a *nix command-line (presuming you have one at your disposal)
scp root@<touchIPaddress>:/var/log/messages messages.txt

then attach the messages.txt file to the bug as text/plain

Created attachment 6942 [details]
messages.log just after booting - IR + screen non-functional

Ben - messages.log attached (7.6.0 9066 f/w)
thanks
Phil

Jan  3 01:13:02 kernel: input: Logitech Logitech USB Keyboard as /class/input/input2
Jan  3 01:13:02 kernel: input: USB HID v1.10 Keyboard [Logitech Logitech USB Keyboard] on usb-fsl-ehci.0-1

Do you have a USB keyboard plugged into the Touch?

Nothing jumps out at me in the log other than that...there are some kernel messages about IR, etc., but they aren't indications that anything is going wrong. A buffer underrun message is in there too, but I don't see how that kills IR and Touch.

Yes I have a USB keyboard plugged in (otherwise I have NO control over the Touch!) but the problem is the same with or without the keyboard plugged in.
What about the DMESG log?

Sure, can't hurt. I'm not particularly qualified to analyze dmesg output, but someone else cc:ed here might be.

Created attachment 6943 [details]
DMESG output

dmesg attached...

I have diffed the messages.log file with firmware thatdoes & doesn't work - the only difference I can see (apart from a newer version of Busybox and the Watchdog daemon starting in a different sequence is that with firmware that DOESN'T WORK these lines are present:

Jan  3 01:13:13 kernel: fab4 ir: set proximity control: (4,0): 40
Jan  3 01:13:13 kernel: i2c-adapter i2c-0: ACK not received

Hi Phil

Not sure, but maybe you've found something here. In r8915 I added code to turn off proximity since we are not using it. That seems to fail on your unit. Why I don't know yet. I tested 7.6.0 r9062 on a current (hw rev 5) and the oldest (hw rev 3) Fab4 I have without issue.

What hardware revision is your Fab4? See in: Diagnostics - General Info

Could you comment out line 138: i.e.

-- self:initProximity()

in /usr/share/jive/applets/SqueezeboxFab4/SqueezeboxFab4Applet.lua

And let me know if that helps.

Thanks
Felix

Created attachment 6944 [details]
Diff of DMESG output - Good f/w on left, Bad on Right

Diff of DMESG output - Good f/w on left, Bad on Right

(In reply to comment #20)
> Hi Phil
> Not sure, but maybe you've found something here. In r8915 I added code to turn
> off proximity since we are not using it. That seems to fail on your unit. Why I
> don't know yet. I tested 7.6.0 r9062 on a current (hw rev 5) and the oldest (hw
> rev 3) Fab4 I have without issue.
> What hardware revision is your Fab4? See in: Diagnostics - General Info
> Could you comment out line 138: i.e.
> -- self:initProximity()
> in /usr/share/jive/applets/SqueezeboxFab4/SqueezeboxFab4Applet.lua
> And let me know if that helps.
> Thanks
> Felix

Felix - genius!
I can confirm that commenting-out that line of code restores full operation of my Touch with f/w 9066 (and probably all versions >=8915).
My Touch is a Beta unit (HW rev 5) with a functioning Proximity sensor - it works OK in the Factory Test area AFAICT.

No idea why I alone have this problem -  Maybe my proximity sensor is slightly defective?

thanks
Phil

Great!

My current guess is that it has to do with the sequence. When it works this line:

- FAB4 IR: fw checksum ok aa33

is much earlier in the log and therefore before the code turning off proximity.

- fab4 ir: set proximity control: (4,0): 40

On your Fab4 though with the latest firmware the sequence is:

fab4 ir: set proximity control: (4,0): 40
...
FAB4 IR: fw checksum ok aa33

Disabling proximity then fails because the microcontroller isn't ready / busy and from then on communication with the microcontroller is down.

There is no dedicated proximity sensor, proximity is done by sending out short IR signals and then receiving them via IR receiver. All this is part of the code in the microcontroller. So no, your proximity 'sensor' isn't broken.

Right now I can only speculate as to why on your unit it takes longer than on the three Fab4s I tried until the microcontroller is ready. I even tried the case when the microcontroller gets reprogrammed, but it still was done before the code for disabling proximity was called. But I must assume that that might just be some kind of tolerance and might happen on other units in the field too.

So, for now I remove the code disabling proximity from lua. I guess the correct way to do this is from within the microcontroller code anyways.

Anyways, Phil, thanks for being so persistent and willing to do all the test.

Felix

(In reply to comment #23)
> Great!
> My current guess is that it has to do with the sequence. When it works this
> line:
> - FAB4 IR: fw checksum ok aa33
> is much earlier in the log and therefore before the code turning off proximity.
> - fab4 ir: set proximity control: (4,0): 40
> On your Fab4 though with the latest firmware the sequence is:
> fab4 ir: set proximity control: (4,0): 40
> ...
> FAB4 IR: fw checksum ok aa33
> Disabling proximity then fails because the microcontroller isn't ready / busy
> and from then on communication with the microcontroller is down.
> There is no dedicated proximity sensor, proximity is done by sending out short
> IR signals and then receiving them via IR receiver. All this is part of the
> code in the microcontroller. So no, your proximity 'sensor' isn't broken.
> Right now I can only speculate as to why on your unit it takes longer than on
> the three Fab4s I tried until the microcontroller is ready. I even tried the
> case when the microcontroller gets reprogrammed, but it still was done before
> the code for disabling proximity was called. But I must assume that that might
> just be some kind of tolerance and might happen on other units in the field
> too.
> So, for now I remove the code disabling proximity from lua. I guess the correct
> way to do this is from within the microcontroller code anyways.
> Anyways, Phil, thanks for being so persistent and willing to do all the test.
> Felix

No problems - happy to help. By the way, I hacked the code slightly and did some more tests... It's only if you set the "sensor" to "0" (disabled) that I get a problem... if you let initProximity write 1, 2 or 3 everything is fine!

Must be something special about the 0 (disabled) value.

Will your fix go into a nightly?
I'd like to update the Forum posts to show Good News :-)
many thanks again
Phil

Confirmed fixed in firmware 9075

Loose end cleanup in bug 16332