Page 5 of 8 « First 34 5 67 Last »
Reply
Thread Tools
Mentalist Traceur is offline Mentalist Traceur
2011-05-14 , 05:51
Posts: 2,225 | Thanked: 3,822 times | Joined on Jun 2010 @ Florida
#41
Originally Posted by hawaii View Post
IMHO, anybody inclined enough to be running swap on the external microsd, has the ability to swapoff before yanking the back cover.

Can anybody confirm this is actually controlled by the driver? It makes no sense that it would be.
The question - at least for me - isn't about intentional, thought out battery cover removals. It's about when it gets popped off because the N900 got dropped the wrong way, or when someone who doesn't know the intricacies of your swap-on-sd-card set-up pulls the battery cover off for whatever reason, while your device is off. I suppose the same people might have the genius to pull out the microSD card right after that too, but the ideal being asked for isn't even leaving the card powered, but allowing the power user to hook their own scripts into the process before the OS completely unmounts the SD card. At the end of the day, the N900 can swapon a backup swap on-eMMC and swapoff the SD card in seconds even under heavy use - ample time that even in the most extreme of shitty corner cases (somebody gets the desire to pull out your SD card and goes for it while the N900 is on, and you're not around to slap them), you're likely to succesfully finish swapoff-ing the SD-card and unmounting it right after.
 

The Following User Says Thank You to Mentalist Traceur For This Useful Post:
hawaii's Avatar
hawaii is offline hawaii
2011-05-14 , 18:59
Posts: 1,030 | Thanked: 792 times | Joined on Jun 2009
#42
Well, if it's controlled by the kernel or userspace, then we can hijack it before it's unmounted.

Are the pins in the slot "off circuited" when the magnet is not present?
 
Estel's Avatar
Estel is offline Estel
2011-05-15 , 09:49
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#43
Would be glad to test, if You could give some more directions - what exactly to check with multimeter gun?

We know that power is cutoff, when magnet is not present - but how checking it could prove if its controlled by software or hardware?
 
retsaw is offline retsaw
2011-05-16 , 10:27
Posts: 701 | Thanked: 585 times | Joined on Sep 2010 @ London, England
#44
Originally Posted by Estel View Post
Would be glad to test, if You could give some more directions - what exactly to check with multimeter gun?

We know that power is cutoff, when magnet is not present - but how checking it could prove if its controlled by software or hardware?
Look at some micro sd pinouts and check to see if there is any voltage between the power line and ground. I've checked mine and the power does indeed seem to be off when the back cover is open, but it would be good for someone to double check.

I suppose it could be controlled in hardware, but it makes sense to me that it would done at the driver level because that gives more flexibility should the designers want to make changes and if it is done by the driver I expect it would be simple to disable, I imagine it would just be commenting out a few lines that check to see if the back cover is open or not, but I haven't looked yet (and I'm not a coder so I wouldn't be able to make any complicated changes myself should it not be as simple as I think).
 
Estel's Avatar
Estel is offline Estel
2011-05-16 , 12:18
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#45
I think i wasn't too clear about what i mean... We KNOW already that voltage is cut-off from microSD cards pin, but i don't know how we can prove if it's controlled by hardware or software.

That was why i asked for additional directions what to test (in which circumstances), to prove or not software controlling upon that behavior.
 
retsaw is offline retsaw
2011-05-16 , 12:45
Posts: 701 | Thanked: 585 times | Joined on Sep 2010 @ London, England
#46
Sorry, I guess you weren't, I didn't think anybody had tested whether it was actually off or was just inaccessible from Maemo. Since you were asking for something to check with a multimeter that is about all you can check with a multimeter. Although, perhaps try testing it at boot time, if it is software controlled it might be powered briefly early in the boot cycle, then again it may not. The only real way of proving it is software controlled without detailed technical info on the hardware is by finding a way to control it through software (e.g. looking at the patched kernel sources for relevant code and modifying it).
 
hawaii's Avatar
hawaii is offline hawaii
2011-05-16 , 14:58
Posts: 1,030 | Thanked: 792 times | Joined on Jun 2009
#47
It has to be software controlled, at least partially, in order to safely unmount the filesystem before cutting power.

Right off the bat, it seems a bit backasswards to build that into the driver when there are numerous daemons that can watch for those triggers - HALd comes to mind.
Last edited by hawaii; 2011-05-16 at 15:00.
 

The Following User Says Thank You to hawaii For This Useful Post:
vi_ is offline vi_
2011-05-17 , 15:52
Posts: 1,680 | Thanked: 3,685 times | Joined on Jan 2011
#48
Originally Posted by stlpaul View Post
There is of course the possibility that the dto change itself doesn't get along with your device for some reason. Based on everything I've read I doubt that is the case, but you never know. So far 3 people here had success with it, including me. 2 had the boot loop.

In the past (not with this particular change) I've gotten the boot loop when I flashed a kernel but forgot to install the modules first. So encoiuntering that after messing with a module does seem to point to something gone awry.

I'm using the power47 from extras-devel, I'm also using multiboot and the modified backupmenu in multiboot, I don't know if those things change how the boot process works as far as kernel module loading goes... I don't think it should make a difference, but obviously something is not working the same for you guys.

I downloaded the module I attached here and it is indeed the one I am using:

Code:
user@N900 ~/MyDocs/Downloads $ unzip sdfix-power47.zip 
Archive:  sdfix-power47.zip
  inflating: 2.6.28.10power47/omap_hsmmc.ko  
user@N900 ~/MyDocs/Downloads $ md5sum 2.6.28.10power47/omap_hsmmc.ko 
1db1e654a8daf86687c2247356e1d6fb  2.6.28.10power47/omap_hsmmc.ko
user@N900 ~/MyDocs/Downloads $ md5sum /lib/modules/2.6.28.10-power47/omap_hsmmc.ko
1db1e654a8daf86687c2247356e1d6fb  /lib/modules/2.6.28.10-power47/omap_hsmmc.ko
user@N900 ~/MyDocs/Downloads $ uname -a
Linux N900 2.6.28.10-power47 #1 PREEMPT Tue May 3 20:40:52 EEST 2011 armv7l GNU/Linux
I've also compiled & successfully used the modified module with the PR1.3 stock kernel, power46 and power46-wl1, and possibly-successfully for the nitdroid kernel from e-yes' git repository (nitdroid spazzed because of my previous installation, but did not self-destruct like it does with the unmodified kernel). In all cases I'm leaving the installed kernel and modules unchanged, with the exception of my new omap_hsmmc which I just copy over the old one.

Hope someone else can perhaps detect what might be going on.
After downloading the module you posted, I modinfo'ed and md5'd it. I got the same results as you. I have just flashed my system to latest cssu+kernel47 (Gotta have a perfect lean system with no hangovers from broken experimentation!) Anyways I modprobed that mthrfkr and it seemed to run ok. So I copied to /lib/modules/power47 AND /lib/modules/current, crossed my fingers and rebooted.

It worked! So I do not know what happened the last time I tried. Thank you for this.

As for the unmount at backcover removal, joerg said he believed it was controlled at a driver level. does somone care to post a link to the omap_hsmmc.ko source?
__________________
N900: One of God's own prototypes. A high-powered mutant of some kind never even considered for mass production. Too weird to live, and too rare to die.
 

The Following 2 Users Say Thank You to vi_ For This Useful Post:
stlpaul is offline stlpaul
2011-05-17 , 18:33
Posts: 1,141 | Thanked: 781 times | Joined on Dec 2009 @ Magical Unicorn Land
#49
Originally Posted by vi_ View Post
After downloading the module you posted, I modinfo'ed and md5'd it. I got the same results as you. I have just flashed my system to latest cssu+kernel47 (Gotta have a perfect lean system with no hangovers from broken experimentation!) Anyways I modprobed that mthrfkr and it seemed to run ok. So I copied to /lib/modules/power47 AND /lib/modules/current, crossed my fingers and rebooted.

It worked! So I do not know what happened the last time I tried. Thank you for this.
Haha, great to hear it worked this time. I still have no idea what could have happened the other time but I'm glad we can move you over to the "working" column.

Originally Posted by vi_ View Post
As for the unmount at backcover removal, joerg said he believed it was controlled at a driver level. does somone care to post a link to the omap_hsmmc.ko source?
in scratchbox with extras-devel enabled:
apt-get source kernel-power

Or view your local linux sources on your PC as it is in the latest mainline kernel.
 
Estel's Avatar
Estel is offline Estel
2011-05-17 , 22:36
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#50
On side line, just to clarify things - vi_, you're successful with getting the module to work at all, but did it do the trick with microSD class 10 for You? Or you never had problems, but wanted it to be used ''correct way'' by kernel, just to be on safe side?

I ask, cause I'm highly interested in buying class10 microSD card, BUT if there is no 100% sure solution to get it working in N900, i would rather wait - every 3 months make them (class10, not N900) lost big portion of price, so no much sense in buying and place it in drawer
 
Reply
Page 5 of 8 « First 34 5 67 Last »

« Previous Thread | Next Thread »
Thread Tools

 
Forum Jump


All times are GMT. The time now is 23:02.

Contact Us - Home - Archive - Top