I am running bfs kernel... Only 2 bugs, HD got stuck once, and that flickery opera...

Using kernel-bfs7, i can't seem to use i2cget (and related things) properly. Executed properly (as root), it gives error "Could not set adress to 0x55: Device or resource busy".

It's just me overlooking something obvious, or "fixing/breaking" mainstream version from bfs6->bfs7 was pushed a little too far, and i2c access was disabled totally?

Will try with garage version (I installed repos one - I hoped that changes were not introduced already, so a side-trip to garage is waiting for me anyway...), and report back.

// Edit

Erm, I've just checked - before going to garage, so with mainstream bfs7 version - and either I'm going crazy,. or bq27200 is already enabled *without* echoing magic thing. i can cat sys/clas/power_supply/bq27200-0/whatever (everything there), and advanced-power-monitor is able to suck info from bq27200 module, giving correct results.

Not that I'm not happy with that *evil laugh*, but wasn't it supposed to work a little different way?

It is possible that I've misunderstood something - mind that I'm not coder, unfortunately. Still, after disabling infamous path in kp48, every thing mentioned by me earlier was non-funcional, and with bfs7 it magically work again. Is it something wrong with this bfs build, or I'm wrong and mainstream kp48 was just screwed in this matter?

Either way, it would be great to regain possibility of using i2cget (and derivatives, like famous shadowjk/joerg_rw bq27200.sh script).

// Edit 2

In all ironical glory, it seems that in bfs7 bq27x00.ko is loaded out-of-box, without need for echoing magic and modprobing in startup script. while it is working flawlessly for me, like it worked for months in kp45-47, I strongly advise for *not* using it, due to mentioned earlier possible hardware damage risk.

Of course, it's only valid if I'm not (unintentionally) spreading FUD.

// Edit 3

Other than bq27x00_battery.ko saga, everything seems fine. To avoid 'goddamnit' reports about worse/improved battery life, I've measured it and it's same as with kp - 6-7 mA in offline locked, ~3 mA in hardest sleep, 11 mA with 2G and WiFi (connected to 'g' rate AP) idle locked.

fCam - after installing drivers for bfs - works flawlessly.


It seems to me, that resource-heavy things (like Easy Debian's Iceweasel) run considerably faster. During normal tasks, I don't see much difference, except for fact that many programs startup time was reduced (some times to instant, like Conky). Mind that I have not tested giving hildon-home a real time - idon't could You elaborate more on which maemo things especially deserve real-time, or idle priority?

// Edit 4

All fCam related applications (fCam itself, lowlight, HDR Capture) seem to work fine *without* installing fcam-drivers-bfs. Furthermore, using fcam-drivers-bfs - even after installing with --auto-reconfigure - result in broken dependencies for 'lowlight'. fCam and HDR Capture do not complaing, but lowlight force us to apt-get -f install, which restores original fcam-drivers.

/Estel

Sorry for double posting, but last one is already over-edited. I *might* have found first serious issue with kernel-bfs.

being connected to AP with 25 mb/s downstream and 1,5 mb/s upstream, I got *much* worse effective internet connection speed (at least, via browser) with kernel-bfs. I know it's strange, but it's 100% reproduceable, and disappear, when I use kp48 (via multiboot, tested few times in row, switching to bfs and back to kp48)

Using kp48, I got 12 mb/s bulk download (probably limited by flash write capabilities) and ~1,4 mb/s bulk upload. With kernel-bfs, it's all of the time ~0,8 mb/s download and ~1 mb/s upload. The worst thing is that it's not only benchmark numerology - perceptive timer of loading pages (especially heavy ones) is also *much* slower than normal.

No idea what may be causing this. Writing downloaded data is scheduled with lower priority, or what?

Thanks for your valuable feedback, Estel!

Regarding the bq27x00_battery subject, we're on the exact same line as kernel-power at the moment (on all subjects like: module blacklisting magic, the module itself, absence of i2c-dev modifications, ..).

Kernel-power v49 introduced changes to the module, which weren't included in kernel-bfs' initial i2c-battery-sysfs test build on our garage page (when kernel-bfs wasn't released yet). That's most likely where any variety in behaviour came from. The fact that we hadn't changed our version string made this change go unnoticed I guess. Rationale behind not updating the version string was that the build on the garage page was a snapshot, not an official release.

To summarize the different builds:

• Kernel-bfs -bfs7 in the repositories is kernel-power v49 plus BFS, BFQ, -ck, and a few extra patches
• Kernel-bfs -bfs6 on our garage page is same as above, plus the i2c-battery-sysfs patch.
• Kernel-bfs -bfs6 on our garage page before kernel-bfs got released is the same as above, but based on kernel-power v48 instead of v49 (note: this build has been removed already from the garage page since it's obselete).

I haven't confirmed this yet, but I'm pretty much 100% sure this is a valid bug: I have the feeling too that browsing the internet is noticeably slower, e.g. downloading bigger files seems not to use all of the available bandwidth. Conky displays low download/upload speeds too.

I'm currently a bit time restrained, but looking into this issue has been put high on my TODO list

Thanks for quick answer, iDont, and sorry for my holy wall of text

so, it seems that kp49 is "broken" in part concerning "evil" i2c path, and nobody found this up to date? Interesting, and quite ironically. I haven't been using kp49, so I can't confirm this - can anyone knowledgeable check how kp49 behaves here?

AFAIK, it's relatively easy to test - fool-proof method would be to execute famous bq27200.sh script as root.

It's not off-topic here, because it would be great to know, that this bug exist also in mainstream kp49, and wasn't ''magically" introduced only on bfs. Yea, unlikely scenario, but it would be great to check just in case.

Also, could anyone confirm, that fCam related applications don't need fcam-drivers-bfs, just regular fcam-drivers? It's working in my case, so maybe fcam-drivers-bfs are unneeded?

/Estel

// Edit

Regarding bq27x00_battery.ko, I was wrong a little. Module is indeed loaded "out of the box", but dangerous path is *not* enabled. It result that, after stopping and enabling bme (for example, using HEN and closing it), we get instant reboot.

Blacklisting bq(...).ko module solves problem.

After using kernel-bfs for a few days I don't have any serius issues and the responsiveness improved a lot.

Great work. Respect!

very good so far, no issues for me except for 1.

with touch screen vibration on, its not consistant. the length and strength(?) varies.

I have noticed three bugs:

Besides from kpv49:

1. "Flickering" Opera
2. Non-consistant vibration (from 1ms to 1s, so as the intensity of vibration)
And here's the big problem:

No camera apps worked for me without fcam-drivers-bfs (using CSSU), but they work if both fcam-drivers and fcam-drivers-bfs installed (-bfs with --auto-deconfigure)

Erm, doesn't fcam-drivers-bfs replace (and provide) fcam-drivers, so You can't have both? Correct me if I'm wrong...

In the previous thread of kernel-bfs, there was a some sort of solution - to install fcam-drivers-bfs with dpkg --auto-deconfigure, so it will not delete packages, just deconfigures. In my case, fcam-drivers-bfs only conflicts with fcam-drivers, not replaces and not provides it, so blessn900 appears to be broken(but fCam works fine).

Update:
Uh-oh, i have just got an unexpected reboot. What even could cause it?