FORUMS
Remove All Ads from XDA

[DEVS-ONLY] SuperSU developer discussion

11,010 posts
Thanks Meter: 83,881
 
By Chainfire, Senior Moderator / Senior Recognized Developer - Where is my shirt? on 5th September 2014, 03:57 PM
Post Reply Email Thread
13th January 2016, 09:02 AM |#11  
Chainfire's Avatar
OP Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 83,881
 
Donate to Me
More
Quote:
Originally Posted by garyd9

So far, all indications are that the change suggested would work.

Can I have your permission to modify the superSU 2.66 archive to change the deepsleep script to use the script above and forward it to a couple people to validate? (Or, I can just wait until tomorrow night and do it on my own device.)

Knock yourself out. I'm not in a rush though. I don't expect to release another update for another few days at least.
 
 
13th January 2016, 09:02 AM |#12  
dr.ketan's Avatar
Recognized Developer / Recognized Contributor
Flag Gujarat
Thanks Meter: 56,464
 
Donate to Me
More
Quote:
Originally Posted by Chainfire


Code:
for i in `ls /sys/class/scsi_disk/`; do 
  cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
  if [ $? -eq 0 ]; then
    echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
  fi
done

Confirmed working for all cache_types 1,2 and 3 but sorry I have patched kernel myself to fix so I have tested reverse just to prevent kernel swap.
Code:
echo 'write back' > /sys/class/scsi_disk/$i/cache_type
and it was write back for all 3. Indeed four including cache_type 0.0.0.0 as well)

So if i had test with
Code:
 echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
then 0000 also get cached right?
It shouldn't be problem right? Just references to this post last line.
Regards
13th January 2016, 09:46 AM |#13  
Chainfire's Avatar
OP Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 83,881
 
Donate to Me
More
Quote:
Originally Posted by dr.ketan

Confirmed working for all cache_types 1,2 and 3 but sorry I have patched kernel myself to fix so I have tested reverse just to prevent kernel swap.

Code:
echo 'write back' > /sys/class/scsi_disk/$i/cache_type
and it was write back for all 3. Indeed four including cache_type 0.0.0.0 as well)

So if i had test with
Code:
 echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
then 0000 also get cached right?
It shouldn't be problem right? Just references to this post last line.
Regards

I don't know, since you changed it up, and your statement is a bit confusing.

Try this:

Code:
for i in `ls /sys/class/scsi_disk/`; do 
  cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
  if [ $? -eq 0 ]; then
    echo Write protected: $i
  else
    echo Write enabled: $i
  fi
done
Copy/paste the output.
13th January 2016, 09:52 AM |#14  
dr.ketan's Avatar
Recognized Developer / Recognized Contributor
Flag Gujarat
Thanks Meter: 56,464
 
Donate to Me
More
No problem. I will go to office in couple of hrs. Remove deep sleep fix from kernel and then test script as per said.
13th January 2016, 09:53 AM |#15  
Chainfire's Avatar
OP Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 83,881
 
Donate to Me
More
Quote:
Originally Posted by dr.ketan

No problem. I will go to office in couple of hrs. Remove deep sleep fix from kernel and then test script as per said.

That's not needed, just run the other script I pasted above. It'll show what we need to know regardless of your kernel being patched or not.
13th January 2016, 10:10 AM |#16  
dr.ketan's Avatar
Recognized Developer / Recognized Contributor
Flag Gujarat
Thanks Meter: 56,464
 
Donate to Me
More
u0_a259@noblelte:/ $ su
root@noblelte:/ # ls -l /sys/class/scsi_disk/
lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:0 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:1 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:1/scsi_disk/0:0:0:1lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:2 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:2/scsi_disk/0:0:0:2lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:3 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:3/scsi_disk/0:0:0:3root@noblelte:/ # cat /sys/class/scsi_disk/*/write_protect
0
1
1
1
root@noblelte:/ #
13th January 2016, 10:21 AM |#17  
Chainfire's Avatar
OP Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 83,881
 
Donate to Me
More
Quote:
Originally Posted by dr.ketan

...

Seems fine!
The Following 2 Users Say Thank You to Chainfire For This Useful Post: [ View ]
13th January 2016, 07:47 PM |#18  
nkk71's Avatar
Recognized Developer / Recognized Contributor
Flag Beirut
Thanks Meter: 6,766
 
More
I had some time to check a few things, so please find below my findings / possibly solutions

Quote:
Originally Posted by Chainfire

Quote:

a) line 1170: dd if=/dev/zero of=$BOOTIMAGE bs=4096
since MultiROM creates a symlink, the above command actually starts nulling out a "dummy boot.img" file, which basically continues on, untill all free space in internal storage (or external sdcard where applicable) is filled out

I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...

Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?

Fixed it by using the following code (perhaps the readlink -f is redundant, but it worked fine)
(at line 1199 of SuperSU 2.66 updater-binary):
Code:
        if [ -b `readlink -f $BOOTIMAGE` ]; then
            dd if=/dev/zero of=$BOOTIMAGE bs=4096
        fi


Quote:
Originally Posted by Chainfire

Quote:

b) when MultiROM-TWRP finishes installing SuperSU, the fake /data is still "busy" (some open file or something else keeping it busy), since it's busy, it can't be unmounted properly, and the real mount points don't get restored
at that point mrom injection will fail
using a lazy unmount helped alleviate that (as a workaround), but obviously not the best solution

Complete guesswork, but the backing file may need to be released for the loop device.

Turns out the loop device was in fact the problem; after umount /su, it still showed:
Code:
~ # [6nlosetup -a
losetup -a
/dev/block/loop0: 0 /data/su.img

so I just used/added (at line 1218 of SuperSU 2.66 updater-binary)
Code:
  umount /su
  losetup -d /dev/block/loop0


I know it was on loop0 so I didnt need to account for anything else, but maybe using
Code:
LOOPDEVICE=`losetup -f`
or something similar, and continuing from there could be an option


Haven't tried checking on the other issues, but will report back when I have something on those
14th January 2016, 01:44 AM |#19  
garyd9's Avatar
Recognized Developer
Flag Pittsburgh, PA
Thanks Meter: 2,732
 
More
@Chainfire, early results on the deep sleep script change are 100% positive for both the Note5 and the edge+ devices.
14th January 2016, 09:26 AM |#20  
Chainfire's Avatar
OP Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 83,881
 
Donate to Me
More
Quote:
Originally Posted by nkk71

I had some time to check a few things, so please find below my findings / possibly solutions

Thanks for the update. I'll have a look at those commands. losetup -f is specifically not used because I have already encountered devices/recoveries where the built-in losetup does not support this flag. So just loop0 and loop1 are tried, on failure, too bad (guess that could use improvement, hehe). The same goes for the -b test for if, and the -f flag for readlink. While I have not specifically tested the block device test, I know the symlink test fails on some devices. So I need to do some testing.

This is why some things in the ZIP are done is such weird ways instead of just using standard command, they're all work-arounds for encounted recovery versions that didn't support command X or flag Y ...

Quote:
Originally Posted by garyd9

@Chainfire, early results on the deep sleep script change are 100% positive for both the Note5 and the edge+ devices.

Good news, as expected.
14th January 2016, 12:27 PM |#21  
nkk71's Avatar
Recognized Developer / Recognized Contributor
Flag Beirut
Thanks Meter: 6,766
 
More
Quote:
Originally Posted by Chainfire

Thanks for the update. I'll have a look at those commands. losetup -f is specifically not used because I have already encountered devices/recoveries where the built-in losetup does not support this flag. So just loop0 and loop1 are tried, on failure, too bad (guess that could use improvement, hehe). The same goes for the -b test for if, and the -f flag for readlink. While I have not specifically tested the block device test, I know the symlink test fails on some devices. So I need to do some testing.

This is why some things in the ZIP are done is such weird ways instead of just using standard command, they're all work-arounds for encounted recovery versions that didn't support command X or flag Y ...

If it's just regarding MultiROM Recovery versions, then I believe I can fix the loop device release, even without touching your script; MultiROM Recovery does indeed release loop devices, but after it tries to unmount the partitions first; I could rewrite that, to release /data/su.img before starting the other unmounts.

But regarding the dd command, that's going to be an issue... we could work around it with some kind of specific check just for this, but that is not ideal; I'm sure you have your reasons why to first null out the partition (not needed on my devices), before flashing the real kernel, but if the readlink & block device checks are unreliable, perhaps just limit the amount of data dd nulls out
giving dd "free reign" to null out as much as it possible can, could also be potentially unwanted for other recoveries/devices
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes