-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
----------------------------------------------------------------------
Related
found this doc in the root of the ftp server
my mail exchange with a person from microsoft.
.... ( and no, i won't post his email address )
------------------------------------------
Dear itsme,
I am a Software Design Engineer with Microsoft on the Windows Mobile product
team. We recently discovered that your site has an unauthorized copy of our
Windows Mobile 5.0 software. These files are proprietary to Microsoft, and
include internal test items that are not intended to be released to the public.
Microsoft would greatly appreciate it if you would quickly remove and destroy
these files from your site. If you have any questions, please feel free to
contact me.
XXXXXXX ( name removed by itsme )
Mobile and Embedded Devices Security
------------------------------------------
you say 'an unauthorized copy'?
which of the wm2005 copies is unauthorized?
a quick look reveals these files or directories with wm2005 versions:
BlueAngel/Programs/win_mobile_2005_beta
Win2k5
Himalaya2005
Uploads/Blueangel/Win_Mobile_2005
Uploads/Himalaya/Uploads2005
Uploads/smartphone/SmartphoneC500Magnetofixedbyrosebud.rar
smartphones/Typhoon/SmartphoneC500Magneto.zip
smartphones/Typhoon/SmartphoneC500Magneto-other-tools.zip
( i will move them now to a temporary inaccessible directory, and delete the unauthorized ones as soon as i read your reply )
and, can you provide my with some proof that you are in fact from microsoft?
and not someone with a hotmail address.
by sending a real email to my [email protected] address
------------------------------------------
Received: from mxdrop46.xs4all.nl (mxdrop46.xs4all.nl [194.109.24.223])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mail.nah6.com (Postfix) with ESMTP id 14699C6186D
for <[email protected]>; Sun, 19 Jun 2005 02:09:17 +0200 (CEST)
Received: from mail1.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.76.156])
by mxdrop46.xs4all.nl (8.13.3/8.13.3) with ESMTP id j5J09O9m056648
for <[email protected]>; Sun, 19 Jun 2005 02:09:26 +0200 (CEST)
Received: from DF-GWY-01.Exchange.Corp.Microsoft.com ([157.54.54.62]) by mail1.exchange.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830);
Sat, 18 Jun 2005 17:08:19 -0700
Received: from df-hub-01.exchange.corp.microsoft.com (157.54.8.109) by
DF-GWY-01.Exchange.Corp.microsoft.com (157.54.54.62) with Microsoft SMTP
Server id 8.0.324.9; Sun, 19 Jun 2005 00:08:19 +0000
Received: from DF-CLIFFORD-MSG.exchange.corp.microsoft.com ([157.54.6.246]) by
df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830);
Sat, 18 Jun 2005 17:08:19 -0700
Hi Willem,
Thanks for following up. We have been trying to make contact on some of the
older files; however I personally have just started assisting our legal and PR
team as I actively monitor select forums. Currently there are no devices
publicly available with Windows Mobile 5.0 software. All files containing
Windows Mobile 5.0 images should be considered proprietary. These files should
be removed and destroyed.
Please feel free to contact me if you have any questions.
this is old news... check the dates of those emails...
or is there a reason you're bringing this topic up?
tony2win said:
this is old news... check the dates of those emails...
or is there a reason you're bringing this topic up?
Click to expand...
Click to collapse
it may be old news but the reason am posting is that the roms are no longer in the ftp site.unless i missing something.
Switching between two separate settings for a backlight brightness based on your specified times and settings.
I am using, and tested, it on Kaiser, but should work with any htc
It include program bl05.exe (for Kaiser backlight change) which is free and all glory for it goes to Vit Lobster Bernatik (send thnx and $ to bernatikv[at]gmail[dot]com)
I am using version of Mortscript 4.2 – it’s included in cabs but not in OEM downloads. Didn't test it with prev vers
MortScript is great project and all Glory and $ for using scripts with Mortscript must go to Mortscript program author: (c) Mirko Schenk [email protected] http://www.sto-helit.de
in OEM package, are actually 2 tools. The other is Backup and is posted separately in development forum.
Mmm if someone would be interested I would welcome any hints/bugs rep
Prime Numbers and 2012 Danger Latitudes
-------------------------------------
Prime Numbers and Cryptology
-------------------------------------
Prime numbers are used in cryptology. Cryptology is the study of using secret writing.
When you buy something on the Internet with a credit card, two large prime numbers are used to send your card details to the online store to keep your credit card number safe and prevent other people from steeling your money.
-------------------------------------
Quran and Prime Numbers
-------------------------------------
Almighty God also used prime numbers to hide information behind the holy text of "The Quran" (Islam's book) which literally means "The Readable" despite being encrypted or encoded into cipher text.
-------------------------------------
The Key
-------------------------------------
Glory to God who built the first chapter of the Quran using prime numbers and named it Al-Fatihah not because it is the opening of the book but the opener or The Key to the Book.
This chapter (The Key) consists of 7 verses, 29 words, and 139 letters. All are prime numbers and their digit sums (7=7, 2+9=11 and 1+3+9=13) are primes too, and the sum of these sums (7+11+13=31) is yet another prime!
What's more, joining these numbers left-to-right 729139 and right-to-left 139297 also produces prime numbers!
-------------------------------------
The Message
-------------------------------------
Although the number of chapters (114) and the total number of verses (6236) are not prime numbers, if the Quran is considered to be two parts, a Key and a Message then the number of chapters and verses also follow this amazing pattern of prime numbers as follows:
Quran = Key + Message
114 = 1 + 113 chapters
6236 = 7 + 6229 verses
where 1, 113, 7, and 6229 are primes with their digit sums (1=1, 1+1+3=5, 7=7, 6+2+2+9=19) are primes too.
This new numbering system puts chapter The Iron (Al-Hadeed) in its correct position of #56 instead of #57 to match its atomic weight of 56.
It also puts chapter Oneness of Allah (Al-Ikhlaass) in #111 instead of #112 which is more aesthetically beautiful.
But above all, it reveals the quantities (or abundance ratios) of the chemical elements in the Universe as verses per chapter. So chapter #1 The Cow with its 286 verses tells us about the abundance ratio of Hydrogen, chapter #2 The Family of Umraan with its 200 verses tells us about the abundance ratio of Helium, and so on for all 113 chapters of The Message.
-------------------------------------
Quran and 2012
-------------------------------------
Quran chapter #55 (The Merciful) has 31 repetitions of:
“رَبِّكُمَا تُكَذِّبَانِ فَبِأَىِّ ءَالَآءِ”
“What other bounties of your God do you still deny?”
In addition to 31 being a prime number, the sum of the verse numbers:
13 + 16 + 18 + 21 + 23 + 25 + 28 + 30 + 32 + 34 + 36 + 38 + 40 + 42 + 45 + 47 + 49 + 51 + 53 + 55 + 57 + 59 + 61 + 63 + 65 + 67 + 69 + 71 + 73 + 75 + 77 = 1433 is also a prime number and its digit sum (1+4+3+3=11) is yet another prime!
But once you know that God Almighty made the chapter to have exactly 355 words and the number of days in the Islamic year is exactly the same 355 days, then this sum of 1433 could be a reference the Islamic year 1433AH (or 2012AD).
Every word in chapter #55 (The Merciful) maps to a day in the Islamic year 1433AH and because there are 31 repetitions of the above verse which consists of four Arabic words, then each repetition maps to four days.
-------------------------------------
2012 Events
-------------------------------------
Therefore, it is possibly that God All-knowing is warning us about 31 events to occur between 7 January 2012 and 7 November 2012 each lasting four days.
If these events are meteorite showers for example (Sijjeel Stones) then each event would leave a 4-fold trail along specific latitude as the Earth spins 4 times in 4 days.
That means, there would be 31 danger latitudes that people should avoid and God, The Merciful, is giving us these danger latitudes as the numbers of the repeated verse themselves:
13˚ 16˚ 18˚ 21˚ 23˚ 25˚ 28˚ 30˚ 32˚ 34˚ 36˚ 38˚ 40˚ 42˚ 45˚ 47˚ 49˚ 51˚ 53˚ 55˚ 57˚ 59˚ 61˚ 63˚ 65˚ 67˚ 69˚ 71˚ 73˚ 75˚ 77˚
If indeed the first event occurs at latitude 13˚, then all people must be evacuated from latitude 16˚within 11 days because there are 11 words to the next verse repetition and so on.
Full list of dates and latitudes can be found at "heliwave dot com".
-------------------------------------
And God knows best and controls all at real time.
Ali Adams
God > infinity
Aliaadams, I think you have a really bad latitude!
Mike
OP is uneducated and naive. Sorry, but it is true.
that adds up to being lost in space
GPS Calculator is a Swiss army knife tool for working with GPS coordinates. It is free and has no ads. New version released today is completely globalized and localized to English, Russian and French. Based on most recent 2004 revision of the world geodesic system earth model, this app allows you to accurately project locations on earth surface, calculate distances and view real geodesic shortest lines on a map. It also does GPS coordinates conversion between different formats; calculates area of any closed polygon; allows you to access detailed GPS settings and manage favorite locations; reverse and forward geocode; and with the help of the large database of build-in locations works even offline. If you would like to know more, head in directly to windows phone marketplace and read the more detailed description there:
http://windowsphone.com/s?appid=4e06928a-de12-e011-9264-00237de2db9e
This final version was released with the help of all suggestions and comments I got on xda. My deepest thanks go to this wonderful community.
[APP] GPS Calculator [U] 04 FEB 2012 [V] 4.3
GPS Caculator updated! Interface cleanup and finally full UTM coordinates support. All old great features are still there too.
zune://navigate/?appID=4e06928a-de12-e011-9264-00237de2db9e
All perfectly works. Anything superfluous
as per a request by potissimus, i have some drivers i was hoping someone could compile for me.
The drivers are for USB-wireless 3g adapters that I'm trying to get working on the Touchpad through ICS (cm9).
Thanks
can anyone assist?
So i've spent the last few days playing with building from CM9 from source and the kernel too.
I've managed to compile both successfully or so it seems.
upon pushing them to the touchpad and attempting to insmod, i get the error "Device or resource busy"
i have done a power off/reboot and hasnt had any effect. I cant find any other information to explain why it wont let me load them now.
i performed a modinfo check on both sierra.ko and sierra_net.ko, and received these details back:
description: USB Driver for Sierra Wireless USB modems
author: Kevin Lloyd, Elina Pasheva, Matthew Safar, Rory Filer
srcversion: C58D9EB6D295B757AA65F22
depends:
vermagic: 2.6.35-palm-tenderloin SMP preempt mod_unload ARMv7
parm: nmea:NMEA streaming (bool)
parm: debugebug messages (bool)
i checked this against the included cifs.ko that is standard in the CM9 build and got:
version: 1.64
description: VFS to access servers complying with the SNIA CIFS Specification e.g. Samba and Windows
license: GPL
author: Steve French <[email protected]>
srcversion: 3E08663B86EDD76112AB79C
depends:
vermagic: 2.6.35-palm-tenderloin SMP preempt mod_unload ARMv7
parm: CIFSMaxBufSize:Network buffer size (not including header). Default: 16384 Range: 8192 to 130048 (int)
parm: cifs_min_rcv:Network buffers in pool. Default: 4 Range: 1 to 64 (int)
parm: cifs_min_small:Small network buffers in pool. Default: 30 Range: 2 to 256 (int)
parm: cifs_max_pending:Simultaneous requests to server. Default: 50 Range: 2 to 256 (int)
so it looks to have compiled correctly and against the correct kernel version.
I've attached the 2 .ko files. hopefully someone may be able to see what is going on there.
The dongle will not function properly without an OTG Y-cable connection to AC. Unfortunately, our microUSB ports cannot generate enough power to feed USB devices properly without it.
Sent from my Galaxy Nexus using Tapatalk 2
Hope someone helps this guy out
Sent from my cm_tenderloin using XDA
MikeyCriggz said:
The dongle will not function properly without an OTG Y-cable connection to AC. Unfortunately, our microUSB ports cannot generate enough power to feed USB devices properly without it.
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
I am aware that the touchpad will not generate power for the dongle, hence why i would be using OTG & Y cables. i should have mentioned that.
I have had no luck with this, and with my limited knowledge cannot take it any further. I should note however that i have begun researching building the kernel from source and there appears to be some form of sierra driver embedded or available, however may not be compiled in the CM9 kernel. If anyone has any idea of how to "activate" additional drivers available in the source that'd be greatly appreciated.
Hi,
Have you tried to manualy "power on" your dongle interface?
You can do this with this command line on your terminal emulator :
Code:
ip link set "interface_name" up
please put a guide with full advanced
thanks