Database Develop

[Howto] Use your desktop keyboard & mouse on the webtop

While this may not be something that most people may want to do, it's something that I wanted to figure out here at work since I have a tri-monitor setup and wanted to use my existing keyboard & mouse on my Atrix's webtop without having to get the HD dock and use a physical KVM. Another obstacle to overcome was the fact that my linux workstation (main machine) is on a separate, wired network from my Atrix, which is connected via a 3G/4G MiFi device. You'll want to make sure you're rooted in both android OS and the webtop OS. You'll also need lxterminal working in the webtop.
So you'll need to get a couple of Jaunty packages compiled for arm:
x11vnc
libvncserver0
Once downloaded, you'll need to get them onto the /osh partition for installation. I do this via adb:
adb push x11vncfiles/ /sdcard/tmp/
adb shell
su
mkdir /osh/tmp
cd /sdcard/tmp
cp *.deb /osh/tmp
sudo -H -u adas bash (switch you to adas user in webtop)
sudo /bin/bash (switches you to root in webtop; you may need to use sulogin)
chroot /osh
cd /tmp
dpkg -i *.deb
exit
Now on to testing...
If you are like me and need to be able to get to the webtop but it isn't on the same network that your desktop/laptop machine is on, you can use the USB cable and adb forward to handle the connectivity. A positive side-effect of this limitation is that x11vnc only needs to listen on the lo (localhost) interface, which helps keep that connection more secure.
LOCAL USB CONNECTION
In lxterminal in the webtop, run the following (as adas) for testing:
export DISPLAY=:0.0
x11vnc -noncache -nolookup -localhost
On your desktop/laptop, run the following:
adb forward tcp:5900 tcp:5900
Using a vnc viewing application (vncviewer, tightvnc, etc), connect to localhost:5900
If all worked out, you should see a remote view of your webtop
REMOTE WIFI CONNECTION
If your Atrix and desktop/laptop are on the same network (or can reach each other via routing), you can do the following steps to test:
In lxterminal in the webtop, run the following (as adas) for testing:
export DISPLAY=:0.0
ifconfig (notate the IP address for eth0)
x11vnc -noncache -nolookup -listen ip_addr_from_prev_step
On your desktop/laptop, run the following:
Using a vnc viewing application (vncviewer, tightvnc, etc), connect to ip_addr_of_atrix:5900
If all worked out, you should see a remote view of your webtop
AUTOMATING THE PROCESS
In order for the x11vnc process to spawn automatically, we need to add it to the lxsession autostart file. This file is read when lxsession starts up and in turn fires off whatever scripts are listed in there. The file is located at:
/etc/xdg/lxsession/LXDE/autostart
By default, the only thing listed in that file is start-oshwt-1.sh, which is a script located at /usr/local/bin. So to get x11vnc working, we add an additional entry into that file:
(as root in webtop): echo start-x11vnc.sh >> /etc/xdg/lxsession/LXDE/autostart
Then we need to create that script in /usr/local/bin:
vi /usr/local/bin/start-x11vnc.sh
Code:
#!/bin/sh
export DISPLAY=:0.0
cd ~
nohup /usr/bin/x11vnc -usepw -forever -nossl -logappend /home/adas/.vnc/x11vnc.log -noncache -nolookup -localhost -nofb -bg
(If you're using it on the same network, replace -localhost with -listen ip_addr like the example above)
Save that file, and make it executable:
chmod +x /usr/local/bin/start-x11vnc.sh
Also, we need to modify Tomoyo to allow it to run that script. Edit /etc/tomoyo/domain_policy.conf and around line 1440:
Code:
<kernel> /osh/usr/bin/lxsession
use_profile 3
Change the 3 to a 2.
Add the following lines to that section:
Code:
allow_execute /osh/usr/bin/x11vnc
allow_execute /osh/usr/local/bin/start-x11vnc.sh
FINAL TOUCHES
I wanted to be able to just move my mouse cursor to the right edge of my desktop machine and have it magiaclly jump to the atrix monitor. To do this, I use a piece of software called x2vnc. If you're using Windows, there's also a package called Win2VNC that will accomplish the same thing. With either software, you run the client (in my case, it's x2vnc) and tell it which direction your vnc server is located at. So to the right of my linux desktop would be east, so I run x2vnc like so:
x2vnc -east localhost:5900
And this connects me to the x11vnc instance running on the atrix. By moving my mouse to the right edge of my main screen, the cursor now appears on the webtop, and I'm able to mouse around and type using my desktop's keyboard.
USING X2X INSTEAD OF X2VNC/WIN2VNC
For anyone that would rather not install any additional packages, and are already running a local X server (XFree/Xorg/Cygwin) you can use x2x to directly connect to the X server running on the Atrix. In order to do this, you'd need to modify /etc/init.d/startXServer.sh and remove the -nolisten tcp from the startx lines and reboot. Then X will listen on port 6000 (for the first display) and that can be used via adb forward on your host machine. The keyboard entry still doesn't work in the Mobile View for some reason...still investigating this. But the mouse seems to function a lot better over native X; selecting text and dragging windows works fine, as does copy & paste.
The top section still applies (you'll need double-root), but the changes are rather minimal:
Code:
adb shell
su
sudo -H -u adas bash
sudo /bin/bash
vi /etc/init.d/startXServer.sh
At the bottom of this script you'll find the lines:
Code:
sudo -u adas -i /usr/bin/startx -- -nolisten tcp -layout HDMI vt2 &
else
sudo -u adas -i /usr/bin/startx /usr/local/bin/xnull -- -nolisten tcp -layout HDMI vt2 &
Remove the -nolisten tcp from both of those lines. Save that file.
You'll also need a method of giving your localhost access via xhost. This has to run under the user context that has the primary display (adas). Since I went to this method after the x11vnc method, I already have the /usr/local/bin/start-x11vnc.sh script setup. I modified this to not run x11vnc but to instead disable access controls for X connections:
Code:
cat /usr/local/bin/start-x11vnc.sh
#!/bin/sh export DISPLAY=:0.0
xhost +
With those set, reboot your phone. When ready, relaunch the webtop and either fire up x2x directly or via forwarding over adb like so:
adb forward tcp:6001 tcp:6000
x2x -east -to localhost:1 &
You should now be able to mouse around on your webtop. Typing in terminal, browser, etc works, but Mobile View is still not working. I think I have it narrowed down to that app (aiw) not responding to XKEYBOARD events. I'll know more once I get my usb hub working and can plug in a keyboard.

This is awesome. I noticed that everything works great but then when I try to click into my mobile view and use my keyboard it wont work there. So for instance once my vnc is up, i can type in firefox, lxterminal, etc etc. But once I click into the phones mobile view the keyboard just isnt recognized. Its pretty odd.
Again though. This is great. Thanks.

EDIT: After poking around some more, I guess I was mistaken. I must've been using my BT keyboard when I was typing in Handcent. The keyboard via vnc isn't being passed to the aiw (Mobile View) window. I'll try and get that resolved.

Awesome work. This is sweet.

Synergy?
Has anyone tried installing a program called Synergy?
It's a software KVM that lets you "place" another screen beside your current screen and lets you control it by moving your mouse beyond the edge of your screen. For example, you have a desktop monitor in front of you and a laptop to the left. Running the server program on the desktop (where the mouse and keyboard are plugged in) and the client program on the laptop, after a quick setup, you can move your desktop mouse+keyboard to control the laptop. You can't drag windows or files across but copy+paste does work for text between computers, which is very useful.
It's open source and runs on Linux so I don't see any reason the client software couldn't be installed on the webtop (may have to be compiled from source).
I can't post links in the forum yet but the software is at www dot synergy-foss dot org.
I don't have an Atrix (yet) so I can't test it but if VNC works then I don't see any reason that this shouldn't work.
The default port on Synergy is 24800, so substituting that in the tutorial should allow the same thing to be achieved.
If this works it would be one more reason to get the phone when it comes out in Canada (2 days)!

Yep, I tried synergy first, but unfortunately, it wouldn't work in my situation since the synergyc (client) runs on the phone and tries to connect to the syngerys (server) on my PC. I can't redirect ports in that direction over USB, so x11vnc it was.
For those on the same network, there's no reason it wouldn't work just fine. I actually use synergy on the other side of my tri-monitor setup to control our 50" plasma when doing demos and whatnot.

D'oh
I was hoping this was a "got usb host working" thread
Oh well...
/me begins learning about his phone to get that project started.

Does the hdmi cable need to be connected to phone after we setup vnc server to run automatically ? What happens after reboot without cable plugged in ..

The x11vnc server will autostart whenever the webtop is started for the first time. After that, I believe that entire X instance runs in the background. It's just idle, waiting for the next time you connect the hdmi cable/dock.
x2vnc auto reconnects by default, but for those that are forwarding tcp ports via adb, you'll have to recreate the port forward prior to it reconnecting.

agentdr8 said:
The x11vnc server will autostart whenever the webtop is started for the first time. After that, I believe that entire X instance runs in the background. It's just idle, waiting for the next time you connect the hdmi cable/dock.
Click to expand...
Click to collapse
Was your hdmi cable always plugged in your testing ?

I just tested this right now; disconnected both cables and rebooted. Once the phone was fully up, I plugged in usb and adb shell'd in:
Code:
[email protected]:~# ps aux | grep x11vnc
Unknown HZ value! (176) Assume 100.
root 4351 0.0 0.0 1648 528 ? S+ 08:42 0:00 grep x11vnc
[email protected]:~# uptime
Unknown HZ value! (171) Assume 100.
08:42:39 up 2 min, 0 users, load average: 2.29, 1.29, 0.50
[email protected]:~#
And then I plugged the hdmi in, selected Webtop from the popup, and reran that above:
Code:
[email protected]:~# !ps
ps aux | grep x11vnc
adas 4645 0.2 0.2 9832 2020 ? Ss 08:44 0:00 /usr/bin/x11vnc -usepw -forever -nossl -logappend /home/adas/.vnc/x11vnc.log -noncache -nolookup -localhost -nofb -bg
root 5258 0.0 0.0 1652 548 ? S+ 08:44 0:00 grep x11vnc
[email protected]:~# uptime
08:44:36 up 4 min, 0 users, load average: 1.26, 1.16, 0.53
[email protected]:~#

Not sure if usb host without a Motorola media hub / lapdock has been mentioned. I managed to get my Atrix working with full usb host by applying 5vdc to the usb power rail. Seems to work with any usb hub and keyboard / mouse combo long as 5vdc is present on the host side(phone microusb connector). This works in both webtop and normal android shell.

agentdr8 said:
EDIT: For anyone that would rather not install any additional packages, and are already running a local X server (XFree/Xorg/Cygwin) you can use x2x to directly connect to the X server running on the Atrix. In order to do this, you'd need to modify /etc/init.d/startXServer.sh and remove the -nolisten tcp from the startx lines and reboot. Then X will listen on port 6000 (for the first display) and that can be used via adb forward on your host machine. The keyboard entry still doesn't work in the Mobile View for some reason...still investigating this. But the mouse seems to function a lot better over native X; selecting text and dragging windows works fine, as does copy & paste.
Click to expand...
Click to collapse
Hey, this is great. I was wondering if you could make more of a step by step guide for this portion. I'm currently in the middle of getting Cygwin but just in case anything goes wrong haha. Thanks.

^^ Sure thing. I'll update the first post tomorrow.

usb host...?
@callen81 - You got USB host working?! I am highly interested in how this would work, but by applying 5v DC to USB, I don't exactly get what you mean. Could you possibly post a guide? I know a TON of people on this forum would love to hear how exactly you did it.

It's as easy as it sounds; you just connect a micro usb togo cable to a hub and make sure power goes back to the phone. Usually most hubs have a diode to make sure power can only come from the host port not to it. So I just hardwired +5vdc from the hub power socket.

Great work callen. Will give it a try. You may want to draw up a simple schematic or maybe some pics and start a new post in Dev or Accessories so others can benefit from your discovery.

agentdr8 said:
Great work callen. Will give it a try. You may want to draw up a simple schematic or maybe some pics and start a new post in Dev or Accessories so others can benefit from your discovery.
Click to expand...
Click to collapse
I just made a small film.
http://www.youtube.com/watch?v=shvFmLRUNGA

so agentdr8, great guide but im just havin to much trouble with tryin to get x2x workin. its bein a pain with cygwin on my windows box, and too much work for my osx box. im wonderin, would it be hard to just get X workin forwardin the webtop session straight over like ssh or even telnet :/

I haven't tried redirecting the entire webtop X session to a different X server...not sure how that would work out.
I did try some simple ssh forwarding and that works fine. You'd need to install openssh-server, openssh-client, and grep packages (use -i --force-overwrite for grep). You can then tunnel whatever you want over that ssh connection to the phone.

LGOB opens TCP/UDP port via UPNP

Hi,
just noticed in my router web interface that our LGOBs open a TCP and UDP port in the firewall via UPnP.
We have two LGOBs, one with stock LG rom and one with Zeus. Both devices show this behavior. Its 2 entries in the high ports > 12000 each and looks like this:
LGOB 1 TCP Port 12345
LGOB 1 UDP Port 12345
LGOB 2 TCP Port 25345
LGOB 2 UDP Port 25345
What could this be? Skype maybe?
Thanks
JO

Maybe onscreen phone?

Have you googled fot the specific port that is opened?
EDIT: http://www.networksorcery.com/enp/protocol/ip/ports12000.htm

No, I did not find any info on those specific port numbers.
According to your website the range 25605-25792 is not assigned to s.th. specific, for example.
Since both phones have different ports with the same pattern, I assume that it is just some random high port that is chosen.

dumping a code

Greetings everyone
I have worked on 8051(atmel), processor.
in those processors we need to dump codes using a dumper.
The question is how do we need to dump the code in the raspberry pi.
My project is to control a small bulb or an LED just to switch it on and off,
and if i need to do that wirelessly how do i do that. i mean if i give an input using my mobile(android) i want that light to be switched off.
P.S : i am using WI-FI.

Php?
Android app or web server -> php request -> MySQL -> c or python -> GPIO -> resistor -> transistor ?
That's one way to do it.
Sent from my iPad using Tapatalk HD

No vinodmadhu6, the CPU on the Raspberry Pi is nothing like the Atmel AVR chips, you can program using a range of modern programming languages.
I'd say Python would be a good way to go, especially if AVR has been your main experience of programming up until now, as it is an easier language to learn

An 8 bit 8051 it definitely isn't! It is a full 32 bit ARM processor capable of running various flavours of Linux.
It is possible to pull the voltages high and low on the pins on the header of the main board, referred to as the GPIO.
Have a read of this:-
http://elinux.org/RPi_Low-level_peripherals

[Kernel][Samsung JB 4.1.2][3.0.90][12/08]Stock/Update11/crt-off support

-This kernel is only for Samsung 4.1.2 ROMs-
Changelog:
Code:
Built from Update11 SamsungOpenSource
Patched to Linux 3.0.90
initramfs from Stock XXEMF1
Fix for crt-off msleep(200) you still need a crt-off mod
----------------------------------------------------------------------
How to flash:
Flash with Pc Odin, Mobile Odin, or heimdall
CWM file in a custom recovery
----------------------------------------------------------------------
Credit:
Xda
Samsung
thewadegeek Link
codeworkx
Linus Torvalds
----------------------------------------------------------------------
Kernel_Shark_B8.tar
726d54c1be9ad1f9631149096fd3841f
----------------------------------------------------------------------
Kernel_Shark_B8.CWM.zip
2746480be490b9de020f8c407a3efdfc
----------------------------------------------------------------------
Older kernels can be found in my file stash
----------------------------------------------------------------------
If you want to support me press the thx button
----------------------------------------------------------------------
My Git:
https://github.com/perkarom
----------------------------------------------------------------------​

So I made a new thread for this kernel as it was causing confusion having 2 different kernels in the same thread

Awesome
Send from my i9300 Marble White powered by XDA with Tapatalk²

Will update to latest Linux patch, soon I hope

Perka said:
Will update to latest Linux patch, soon I hope
Click to expand...
Click to collapse
I dont like CRT

hwjrmrm said:
I dont like CRT
Click to expand...
Click to collapse
So dont use it.

The major difference being Update 10...
and wat else sorry if being a noob..!!

geekynoob said:
The major difference being Update 10...
and wat else sorry if being a noob..!!
Click to expand...
Click to collapse
Difference from what?

Perka said:
Difference from what?
Click to expand...
Click to collapse
Ur other kernel mate.. Which m using since 3 days

geekynoob said:
Ur other kernel mate.. Which m using since 3 days
Click to expand...
Click to collapse
Both is build from u10, this kernel is stock with crt-off support.

An important question :
Does it have Boefla Sound support?
Enviado de meu GT-I9300 usando o Tapatalk 2

criscan said:
An important question :
Does it have Boefla Sound support?
Enviado de meu GT-I9300 usando o Tapatalk 2
Click to expand...
Click to collapse
no.

OP updated, now kernel is updated to Linux 3.0.73
Enjoy

Perka said:
OP updated, now kernel is updated to Linux 3.0.73
Enjoy
Click to expand...
Click to collapse
Last update of this kernel , no Perka ?

I can compile a new tomorrow with 3.0.74
Sent from my GT-I9300 using xda app-developers app

Kernel updated to 3.0.74
Code:
commit f97ddf68ad209d6767249bd6852ce053588adfbd
Author: Greg Kroah-Hartman <[email protected]>
Date: Tue Apr 16 21:17:25 2013 -0700
Linux 3.0.74
commit c6c8807630f086872b446cc66752a1835df5e9d7
Author: David Woodhouse <[email protected]>
Date: Tue Oct 9 15:08:10 2012 +0100
mtd: Disable mtdchar mmap on MMU systems
commit f5cf8f07423b2677cebebcebc863af77223a4972 upstream.
This code was broken because it assumed that all MTD devices were map-based.
Disable it for now, until it can be fixed properly for the next merge window.
Signed-off-by: David Woodhouse <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit f0776cdd7c35a4b4ca7b80e6afc4ecd0d26831d7
Author: Hayes Wang <[email protected]>
Date: Sat Apr 13 12:26:55 2013 +0200
r8169: fix auto speed down issue
commit e2409d83434d77874b461b78af6a19cd6e6a1280 upstream.
It would cause no link after suspending or shutdowning when the
nic changes the speed to 10M and connects to a link partner which
forces the speed to 100M.
Check the link partner ability to determine which speed to set.
The link speed down code path is not factored in this kernel version.
Signed-off-by: Hayes Wang <[email protected]>
Acked-by: Francois Romieu <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit fcea984b4ded553023858d55afcf5e782462af1c
Author: Linus Torvalds <[email protected]>
Date: Sat Sep 8 12:57:30 2012 -0700
mtdchar: fix offset overflow detection
commit 9c603e53d380459fb62fec7cd085acb0b74ac18f upstream.
Sasha Levin has been running trinity in a KVM tools guest, and was able
to trigger the BUG_ON() at arch/x86/mm/pat.c:279 (verifying the range of
the memory type). The call trace showed that it was mtdchar_mmap() that
created an invalid remap_pfn_range().
The problem is that mtdchar_mmap() does various really odd and subtle
things with the vma page offset etc, and uses the wrong types (and the
wrong overflow) detection for it.
For example, the page offset may well be 32-bit on a 32-bit
architecture, but after shifting it up by PAGE_SHIFT, we need to use a
potentially 64-bit resource_size_t to correctly hold the full value.
Also, we need to check that the vma length plus offset doesn't overflow
before we check that it is smaller than the length of the mtdmap region.
This fixes things up and tries to make the code a bit easier to read.
Reported-and-tested-by: Sasha Levin <[email protected]>
Acked-by: Suresh Siddha <[email protected]>
Acked-by: Artem Bityutskiy <[email protected]>
Cc: David Woodhouse <[email protected]>
Cc: [email protected]
Signed-off-by: Linus Torvalds <[email protected]>
Cc: Ben Hutchings <[email protected]>
Cc: Brad Spengler <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit b1cf3728932d0e6beb0a09812cbc71618939069a
Author: Boris Ostrovsky <[email protected]>
Date: Sat Mar 23 09:36:36 2013 -0400
x86, mm: Patch out arch_flush_lazy_mmu_mode() when running on bare metal
commit 511ba86e1d386f671084b5d0e6f110bb30b8eeb2 upstream.
Invoking arch_flush_lazy_mmu_mode() results in calls to
preempt_enable()/disable() which may have performance impact.
Since lazy MMU is not used on bare metal we can patch away
arch_flush_lazy_mmu_mode() so that it is never called in such
environment.
[ hpa: the previous patch "Fix vmalloc_fault oops during lazy MMU
updates" may cause a minor performance regression on
bare metal. This patch resolves that performance regression. It is
somewhat unclear to me if this is a good -stable candidate. ]
Signed-off-by: Boris Ostrovsky <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Tested-by: Josh Boyer <[email protected]>
Tested-by: Konrad Rzeszutek Wilk <[email protected]>
Acked-by: Borislav Petkov <[email protected]>
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit cfe9f98bf529186fa6365127f089ea69dafb84d5
Author: Samu Kallio <[email protected]>
Date: Sat Mar 23 09:36:35 2013 -0400
x86, mm, paravirt: Fix vmalloc_fault oops during lazy MMU updates
commit 1160c2779b826c6f5c08e5cc542de58fd1f667d5 upstream.
In paravirtualized x86_64 kernels, vmalloc_fault may cause an oops
when lazy MMU updates are enabled, because set_pgd effects are being
deferred.
One instance of this problem is during process mm cleanup with memory
cgroups enabled. The chain of events is as follows:
- zap_pte_range enables lazy MMU updates
- zap_pte_range eventually calls mem_cgroup_charge_statistics,
which accesses the vmalloc'd mem_cgroup per-cpu stat area
- vmalloc_fault is triggered which tries to sync the corresponding
PGD entry with set_pgd, but the update is deferred
- vmalloc_fault oopses due to a mismatch in the PUD entries
The OOPs usually looks as so:
------------[ cut here ]------------
kernel BUG at arch/x86/mm/fault.c:396!
invalid opcode: 0000 [#1] SMP
.. snip ..
CPU 1
Pid: 10866, comm: httpd Not tainted 3.6.10-4.fc18.x86_64 #1
RIP: e030:[<ffffffff816271bf>] [<ffffffff816271bf>] vmalloc_fault+0x11f/0x208
.. snip ..
Call Trace:
[<ffffffff81627759>] do_page_fault+0x399/0x4b0
[<ffffffff81004f4c>] ? xen_mc_extend_args+0xec/0x110
[<ffffffff81624065>] page_fault+0x25/0x30
[<ffffffff81184d03>] ? mem_cgroup_charge_statistics.isra.13+0x13/0x50
[<ffffffff81186f78>] __mem_cgroup_uncharge_common+0xd8/0x350
[<ffffffff8118aac7>] mem_cgroup_uncharge_page+0x57/0x60
[<ffffffff8115fbc0>] page_remove_rmap+0xe0/0x150
[<ffffffff8115311a>] ? vm_normal_page+0x1a/0x80
[<ffffffff81153e61>] unmap_single_vma+0x531/0x870
[<ffffffff81154962>] unmap_vmas+0x52/0xa0
[<ffffffff81007442>] ? pte_mfn_to_pfn+0x72/0x100
[<ffffffff8115c8f8>] exit_mmap+0x98/0x170
[<ffffffff810050d9>] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
[<ffffffff81059ce3>] mmput+0x83/0xf0
[<ffffffff810624c4>] exit_mm+0x104/0x130
[<ffffffff8106264a>] do_exit+0x15a/0x8c0
[<ffffffff810630ff>] do_group_exit+0x3f/0xa0
[<ffffffff81063177>] sys_exit_group+0x17/0x20
[<ffffffff8162bae9>] system_call_fastpath+0x16/0x1b
Calling arch_flush_lazy_mmu_mode immediately after set_pgd makes the
changes visible to the consistency checks.
RedHat-Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=914737
Tested-by: Josh Boyer <[email protected]>
Reported-and-Tested-by: Krishna Raman <[email protected]>
Signed-off-by: Samu Kallio <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Tested-by: Konrad Rzeszutek Wilk <[email protected]>
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 074ca07eff0e6f5ead1a1c688739c5bf960ca7c4
Author: Thomas Gleixner <[email protected]>
Date: Sat Apr 6 10:10:27 2013 +0200
sched_clock: Prevent 64bit inatomicity on 32bit systems
commit a1cbcaa9ea87b87a96b9fc465951dcf36e459ca2 upstream.
The sched_clock_remote() implementation has the following inatomicity
problem on 32bit systems when accessing the remote scd->clock, which
is a 64bit value.
CPU0 CPU1
sched_clock_local() sched_clock_remote(CPU0)
...
remote_clock = scd[CPU0]->clock
read_low32bit(scd[CPU0]->clock)
cmpxchg64(scd->clock,...)
read_high32bit(scd[CPU0]->clock)
While the update of scd->clock is using an atomic64 mechanism, the
readout on the remote cpu is not, which can cause completely bogus
readouts.
It is a quite rare problem, because it requires the update to hit the
narrow race window between the low/high readout and the update must go
across the 32bit boundary.
The resulting misbehaviour is, that CPU1 will see the sched_clock on
CPU1 ~4 seconds ahead of it's own and update CPU1s sched_clock value
to this bogus timestamp. This stays that way due to the clamping
implementation for about 4 seconds until the synchronization with
CLOCK_MONOTONIC undoes the problem.
The issue is hard to observe, because it might only result in a less
accurate SCHED_OTHER timeslicing behaviour. To create observable
damage on realtime scheduling classes, it is necessary that the bogus
update of CPU1 sched_clock happens in the context of an realtime
thread, which then gets charged 4 seconds of RT runtime, which results
in the RT throttler mechanism to trigger and prevent scheduling of RT
tasks for a little less than 4 seconds. So this is quite unlikely as
well.
The issue was quite hard to decode as the reproduction time is between
2 days and 3 weeks and intrusive tracing makes it less likely, but the
following trace recorded with trace_clock=global, which uses
sched_clock_local(), gave the final hint:
<idle>-0 0d..30 400269.477150: hrtimer_cancel: hrtimer=0xf7061e80
<idle>-0 0d..30 400269.477151: hrtimer_start: hrtimer=0xf7061e80 ...
irq/20-S-587 1d..32 400273.772118: sched_wakeup: comm= ... target_cpu=0
<idle>-0 0dN.30 400273.772118: hrtimer_cancel: hrtimer=0xf7061e80
What happens is that CPU0 goes idle and invokes
sched_clock_idle_sleep_event() which invokes sched_clock_local() and
CPU1 runs a remote wakeup for CPU0 at the same time, which invokes
sched_remote_clock(). The time jump gets propagated to CPU0 via
sched_remote_clock() and stays stale on both cores for ~4 seconds.
There are only two other possibilities, which could cause a stale
sched clock:
1) ktime_get() which reads out CLOCK_MONOTONIC returns a sporadic
wrong value.
2) sched_clock() which reads the TSC returns a sporadic wrong value.
#1 can be excluded because sched_clock would continue to increase for
one jiffy and then go stale.
#2 can be excluded because it would not make the clock jump
forward. It would just result in a stale sched_clock for one jiffy.
After quite some brain twisting and finding the same pattern on other
traces, sched_clock_remote() remained the only place which could cause
such a problem and as explained above it's indeed racy on 32bit
systems.
So while on 64bit systems the readout is atomic, we need to verify the
remote readout on 32bit machines. We need to protect the local->clock
readout in sched_clock_remote() on 32bit as well because an NMI could
hit between the low and the high readout, call sched_clock_local() and
modify local->clock.
Thanks to Siegfried Wulsch for bearing with my debug requests and
going through the tedious tasks of running a bunch of reproducer
systems to generate the debug information which let me decode the
issue.
Reported-by: Siegfried Wulsch <[email protected]>
Acked-by: Peter Zijlstra <[email protected]>
Cc: Steven Rostedt <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 3d91fc30b72e90319f1bb35905e284b58b976d6f
Author: Nicholas Bellinger <[email protected]>
Date: Wed Apr 10 15:00:27 2013 -0700
target: Fix incorrect fallthrough of ALUA Standby/Offline/Transition CDBs
commit 30f359a6f9da65a66de8cadf959f0f4a0d498bba upstream.
This patch fixes a bug where a handful of informational / control CDBs
that should be allowed during ALUA access state Standby/Offline/Transition
where incorrectly returning CHECK_CONDITION + ASCQ_04H_ALUA_TG_PT_*.
This includes INQUIRY + REPORT_LUNS, which would end up preventing LUN
registration when LUN scanning occured during these ALUA access states.
Signed-off-by: Nicholas Bellinger <[email protected]>
Cc: Hannes Reinecke <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 44a44be00a8a547855c4265d96b1a42261f26e8a
Author: Huacai Chen <[email protected]>
Date: Sun Apr 7 02:14:14 2013 +0000
PM / reboot: call syscore_shutdown() after disable_nonboot_cpus()
commit 6f389a8f1dd22a24f3d9afc2812b30d639e94625 upstream.
As commit 40dc166c (PM / Core: Introduce struct syscore_ops for core
subsystems PM) say, syscore_ops operations should be carried with one
CPU on-line and interrupts disabled. However, after commit f96972f2d
(kernel/sys.c: call disable_nonboot_cpus() in kernel_restart()),
syscore_shutdown() is called before disable_nonboot_cpus(), so break
the rules. We have a MIPS machine with a 8259A PIC, and there is an
external timer (HPET) linked at 8259A. Since 8259A has been shutdown
too early (by syscore_shutdown()), disable_nonboot_cpus() runs without
timer interrupt, so it hangs and reboot fails. This patch call
syscore_shutdown() a little later (after disable_nonboot_cpus()) to
avoid reboot failure, this is the same way as poweroff does.
For consistency, add disable_nonboot_cpus() to kernel_halt().
Signed-off-by: Huacai Chen <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit e16fe8625f041b56b2d6866e2bc8abd0284499d0
Author: Namhyung Kim <[email protected]>
Date: Mon Apr 1 21:46:23 2013 +0900
tracing: Fix double free when function profile init failed
commit 83e03b3fe4daffdebbb42151d5410d730ae50bd1 upstream.
On the failure path, stat->start and stat->pages will refer same page.
So it'll attempt to free the same page again and get kernel panic.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Namhyung Kim <[email protected]>
Cc: Frederic Weisbecker <[email protected]>
Cc: Namhyung Kim <[email protected]>
Signed-off-by: Steven Rostedt <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit da60065417ee775999fd05d2a4ea0c268e4ec30b
Author: Alban Bedel <[email protected]>
Date: Tue Apr 9 17:13:59 2013 +0200
ASoC: wm8903: Fix the bypass to HP/LINEOUT when no DAC or ADC is running
commit f1ca493b0b5e8f42d3b2dc8877860db2983f47b6 upstream.
The Charge Pump needs the DSP clock to work properly, without it the
bypass to HP/LINEOUT is not working properly. This requirement is not
mentioned in the datasheet but has been confirmed by Mark Brown from
Wolfson.
Signed-off-by: Alban Bedel <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit facbcede9edd28f9f3290a83fdb6ea4b781ffcd6
Author: Dave Hansen <[email protected]>
Date: Wed Jan 30 16:56:16 2013 -0800
x86-32, mm: Rip out x86_32 NUMA remapping code
commit f03574f2d5b2d6229dcdf2d322848065f72953c7 upstream.
[was already included in 3.0, but I missed the patch hunk for
arch/x86/mm/numa_32.c - gregkh]
This code was an optimization for 32-bit NUMA systems.
It has probably been the cause of a number of subtle bugs over
the years, although the conditions to excite them would have
been hard to trigger. Essentially, we remap part of the kernel
linear mapping area, and then sometimes part of that area gets
freed back in to the bootmem allocator. If those pages get
used by kernel data structures (say mem_map[] or a dentry),
there's no big deal. But, if anyone ever tried to use the
linear mapping for these pages _and_ cared about their physical
address, bad things happen.
For instance, say you passed __GFP_ZERO to the page allocator
and then happened to get handed one of these pages, it zero the
remapped page, but it would make a pte to the _old_ page.
There are probably a hundred other ways that it could screw
with things.
We don't need to hang on to performance optimizations for
these old boxes any more. All my 32-bit NUMA systems are long
dead and buried, and I probably had access to more than most
people.
This code is causing real things to break today:
https://lkml.org/lkml/2013/1/9/376
I looked in to actually fixing this, but it requires surgery
to way too much brittle code, as well as stuff like
per_cpu_ptr_to_phys().
[ hpa: Cc: this for -stable, since it is a memory corruption issue.
However, an alternative is to simply mark NUMA as depends BROKEN
rather than EXPERIMENTAL in the X86_32 subclause... ]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: H. Peter Anvin <[email protected]>
Cc: Jiri Slaby <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 09d11b951936e52dc1d1513f67d605830f720928
Author: Eldad Zack <[email protected]>
Date: Fri Apr 5 20:49:46 2013 +0200
ALSA: usb-audio: fix endianness bug in snd_nativeinstruments_*
commit 889d66848b12d891248b03abcb2a42047f8e172a upstream.
The usb_control_msg() function expects __u16 types and performs
the endianness conversions by itself.
However, in three places, a conversion is performed before it is
handed over to usb_control_msg(), which leads to a double conversion
(= no conversion):
* snd_usb_nativeinstruments_boot_quirk()
* snd_nativeinstruments_control_get()
* snd_nativeinstruments_control_put()
Caught by sparse:
sound/usb/mixer_quirks.c:512:38: warning: incorrect type in argument 6 (different base types)
sound/usb/mixer_quirks.c:512:38: expected unsigned short [unsigned] [usertype] index
sound/usb/mixer_quirks.c:512:38: got restricted __le16 [usertype] <noident>
sound/usb/mixer_quirks.c:543:35: warning: incorrect type in argument 5 (different base types)
sound/usb/mixer_quirks.c:543:35: expected unsigned short [unsigned] [usertype] value
sound/usb/mixer_quirks.c:543:35: got restricted __le16 [usertype] <noident>
sound/usb/mixer_quirks.c:543:56: warning: incorrect type in argument 6 (different base types)
sound/usb/mixer_quirks.c:543:56: expected unsigned short [unsigned] [usertype] index
sound/usb/mixer_quirks.c:543:56: got restricted __le16 [usertype] <noident>
sound/usb/quirks.c:502:35: warning: incorrect type in argument 5 (different base types)
sound/usb/quirks.c:502:35: expected unsigned short [unsigned] [usertype] value
sound/usb/quirks.c:502:35: got restricted __le16 [usertype] <noident>
Signed-off-by: Eldad Zack <[email protected]>
Acked-by: Daniel Mack <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

Any update?
Enviado desde mi GT-I9300 usando Tapatalk 2

alonso444 said:
Any update?
Enviado desde mi GT-I9300 usando Tapatalk 2
Click to expand...
Click to collapse
Later today.

updated to Linux 3.0.78

As I now use this kernel it will be updated more often
-This kernel is only for Samsung 4.1.2 ROMs-
Changelog:
Code:
Built from Update10 SamsungOpenSource
[COLOR="Blue"]Patched to Linux 3.0.87[/COLOR]
initramfs from Stock [COLOR="blue"]XXEMF6[/COLOR]
Fix for crt-off msleep(200) you still need a crt-off mod
----------------------------------------------------------------------
How to flash:
Flash with Pc Odin, Mobile Odin, or heimdall
CWM file in a custom recovery
----------------------------------------------------------------------
Credit:
Xda
Samsung
thewadegeek Link
codeworkx
Linus Torvalds
----------------------------------------------------------------------
Kernel_Shark_B5.tar
bce32b63ccd2c848b7cbab2aaf5afaac
----------------------------------------------------------------------
Kernel_Shark_B5.CWM.zip
64a6e99813724fb2cdbb49b6d53808da
----------------------------------------------------------------------
Older kernels can be found in my file stash
----------------------------------------------------------------------
If you want to support me press the thx button
----------------------------------------------------------------------
My Git:
https://github.com/perkarom
----------------------------------------------------------------------​

BLE beacon profile: Port Eddystone for Mbed to Raspbian

Hello,
Could you please help me to port the Mbed implementation of Google Eddyston Bluetooth Low Energy beacon profile to Raspbian on the Raspberry Pi 3b+. Sorry I can't link to the implementation now as I haven't written 10 posts yet.
But on Github it is under the directory...
google/eddystone/implementations/mbed/
Porting instructions from Google:
1. Edit Eddystone_config.h, most boards should work with changes only to this file.
2. There are #defines for each target board, just add your own #define to the list
Click to expand...
Click to collapse