SuperZaxxon v1.73 - maintenance release

[notaz]

Or use FAT16.

It's unlikely to help. From what I've seen, the new large cards (128GB+) take longer time to initialize and the bootloader doesn't wait long enough for them to respond. The updated bootloader waits more and does more command retries, but to flash it you still need another card that responds fast enough, the old small cards usually can do it.

 

[Yoyobuae]

Yeah, don't.

Use a smaller SD card.

D.

Worked with a 2GB SD card, thanks.

 

[levi]

I've booted of a 64GB card fine in the past. Though it was a medium-high-end Sandisc is that matters, and I had partitioned it so it was only booting the first 512MB partition, if that makes a difference.

 

[ZXDunny]

I've booted of a 64GB card fine in the past. Though it was a medium-high-end Sandisc is that matters, and I had partitioned it so it was only booting the first 512MB partition, if that makes a difference.

Yeah, the only way I could get my Sandisk 64GBs to boot was to partition to two 32GBs. Worked a treat after that. It's a pain though, having to do that every time I want to update firmware so I keep an old slow 16GB around for that job.

D.

 

[dgame]

Works fine here, I think your SD card (or at least palemoon PND) is actually corrupt.

Tried different SD cards and had same Squashfs problem with Palemoon.
Full Flashed back to 1.71 to get rid of the problem using same PND on the same SD card.
Anything past 1.71 and the problem comes back.

 

[notaz]

Tried different SD cards and had same Squashfs problem with Palemoon.
Full Flashed back to 1.71 to get rid of the problem using same PND on the same SD card.
Anything past 1.71 and the problem comes back.

Any consistent way to reproduce it?
I can guess you have a CC unit and use the left slot?

 

[dgame]

It is a 1Ghz Pandora using the left slot. I use Pale Moon (25.8.1.18) a lot and when I load pages with a lot of pictures it sometimes segfaults. Usually it comes right up but post 1.71 I get the squashfs errors and the PND won't restart. Restarting the Pandora fixes it temporarily. I can sometimes get it to work without restarting the Pandora by copying the PND over itself.

Before I went back to 1.71 I tried the right SD slot and was worse in that a restart didn't fix it.
This same card that the PND would not start in 1.73u1 worked in the same right SD slot after the Reflash to 1.71 without modifications. In fact I have never seen the Squashfs error in 1.71.

Now I vaguely remember 'Seb writing something about Squashfs changes, perhaps this is related:

Just a small precision, lately, following Notaz' advise, I started using "xz" compression variant of SquashFS to gain some extra space...

I am able to flash back to 1.73u1 if you want me to test something.

I notice Pale Moon 25.8.1.19 in the Repo so I am one release behind. I may reflash 1.73u1 and try it again with 25.8.1.19.

Please advise.

Thanks for all of your help over the years!

 

[ptitSeb]

@dgame are you saying that your issue is the re-start of Palemoon with firmware 1.73 (after a crash), and not the 1st start of the PND?

 

[dgame]

@ptitSeb Yes. That is a valid description. The first start is fine. After it crashes sometimes there are problems re-starting with 1.73u1 (works in 1.71).

Thanks!

 

[notaz]

I am able to flash back to 1.73u1 if you want me to test something.

Could you flash 1.73u1 again and try it with this kernel:
http://notaz.gp2x.de/tmp/uImage-3
just copy it to /boot/ and reboot. If that doesn't help I'll build another kernel to try.
Thanks.

 

[dgame]

Using that uImage-3 with 1.73u1 now and so far it is working. Have to test longer to see if the problem is gone.

Thanks


:~$ cat /proc/version
Linux version 3.2.74 (notaz@pixelinis) (gcc version 4.9.4 20151014 (prerelease) (crosstool-NG 1.20.0) ) #1136 Wed Jan 6 22:57:22 EET 2016

 

[dgame]

@notaz The squashfs problem (palemoon PND won't restart after a segfault) happens with that that uImage-3 and 1.73u1. Restart fixes it until it happens again. Updated to latest Pale Moon (.19) in repo.

Thanks!

 

[Galaxis]

Hmm without grep it will change old behavior (having something like /dev/mmcblk in blacklist won't affect all cards), which may break some's setup.

This might work without breaking anything:

--- /etc/udev/scripts/mount.sh.old  2015-12-25 01:45:46.468753107 +0100
+++ /etc/udev/scripts/mount.sh  2016-01-10 00:02:44.328124023 +0100
@@ -12,11 +12,12 @@
name="`basename "$DEVNAME"`"
name2="`$blkid "$DEVNAME" -c /dev/null -o value -s LABEL | sed 's/ /_/g'`"
name3=$(echo $DEVNAME | sed 's/.*dev.//g')
+name4="`$blkid "$DEVNAME" -c /dev/null -o value -s UUID`"
uid=$(cat /tmp/currentuid)

for line in `grep -v ^# /etc/udev/mount.blacklist`
do
-  if ( echo "$DEVNAME" | grep -q "$line" )
+  if { ( echo "$DEVNAME" | grep -q "$line" ) || ( echo "$name4" | grep -q "$line" ) };
  then
  logger "udev/mount.sh" "[$DEVNAME] is blacklisted, ignoring"
  exit 0

 

[notaz]

@notaz The squashfs problem (palemoon PND won't restart after a segfault) happens with that that uImage-3 and 1.73u1. Restart fixes it until it happens again. Updated to latest Pale Moon (.19) in repo.

Let's try again, http://notaz.gp2x.de/tmp/uImage-3 updated.

Unfortunately it might take a while until we can isolate the issue. There was a kernel version change, compiler change, compiler flag change, also some driver changes that I did myself. Is 1.72 also affected by this?

This might work without breaking anything

Ok I guess I can take that.

 

[dgame]

This seems to happen in anything past 1.71.

Testing the new version now:

:~$ cat /proc/version
Linux version 3.2.74 (notaz@pixelinis) (gcc version 4.9.4 20151014 (prerelease) (crosstool-NG 1.20.0) ) #1137 Sun Jan 10 18:56:38 EET 2016

Thanks!

 

[dgame]

Okay, this #1137 version fixed it. No more squashfs errors and the system seems more stable. Have to try hard to get PaleMoon to pagefault and it works again every time, no reboot needed. So thanks again!

 

[notaz]

Okay, this #1137 version fixed it. No more squashfs errors and the system seems more stable. Have to try hard to get PaleMoon to pagefault and it works again every time, no reboot needed. So thanks again!

Thanks for testing. OK, so this kernel had 3 older different changes reverted at once, so I now know that one or several of them is causing the issue, but have no idea which one(s). Those changes are improving wifi performance for me, so I wouldn't want to keep them all reverted, if possible. It would be best if you could do some more tests, with just 2 more kernels we could isolate the problematic change.

If you are interested, here are the changes that were reverted in #1137:

• checksum preload - unlikely to be the cause but who knows...
• SD card DMA parameters - likely since the problem is very SD card related
  
• removed redundant SD card timeout programming - somewhat likely

I've uploaded http://notaz.gp2x.de/tmp/uImage-3 with just the SD card DMA parameter revert, would be great if you could test it, thanks.

I wish I could reproduce this myself...

 

[FBnil]

@dgame: Any luck with testing?

 

[notaz]

I've spent multiple hours trying to reproduce it, loading demanding pages in palemoon to make it crash. 6+ crashes later I had no ill effects. The bad thing is that when the memory runs out, palemoon begins to crawl until it starts to take minutes to respond to any input; it stays in such state until after random time it finally crashes, and that random time is sometimes really long. So it's not something I can stress hundreds of times. without help from someone who has this issue I won't be able to debug this.

 

[dgame]

#1138 also works like #1137. No squashfs errors. PaleMoon recovers every time. Thanks!