Re: [PATCH 0/8 V5] Many fixes for in-kernel decoding and for the ENE driver
On Tue, 2010-09-07 at 00:26 +0300, Maxim Levitsky wrote: Hi, Here is full overview of my patches: Patch #1 fixes races in ir thread. It fixes the case when ktherad_stop waits forever for the thread. This happens on module unload and therefore it never finishes. Sorry for introducing this bug. Patch #2, fixes a crash on my module load. It happens because ir core initializes the input device a bit early, therefore it could be accessed while still not set up. Patch #3 fixes a small typo in lirc code that makes it impossible to use tx duty cycle setting. Patch #4 fixes a problem seen on my system that results in stuck down forever key. Patch #5 adds few keys to MCE keymap that were found on laptop of an user I tested this driver with Patch #6, is a combined update ti my driver. It contains lot of refactoring thanks to docs I have now, and lot of fixes, and supports latest version of firmware (and I have 4 users asking for that) It is quite huge, but it would be a tedios job to break it up. This can't introduce regressions because the ene_ir was never released. In addition to that it was tested by me and another two users. Patch #7 the really only patch that touches drivers I don't have does touch the ir-core. It is quite small, and it adds a proper solution to dilema about what to do with huge space between keypresses. Now this space is just truncated by the driver with timeout flag. The lirc codec then ensures that right sample is send to the lircd. Please review and test it. Patch #8 is very simple. It just builds on top of patch #7 and adds carrier reports to ene driver. Any update? Should I resent these (didn't change anything I think). What about other work that conflicts with this? What are the plans for (very close) merge window? Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8 V5] Many fixes for in-kernel decoding and for the ENE driver
On Thu, 2010-09-09 at 22:01 -0400, Jarod Wilson wrote:
On Thu, Sep 09, 2010 at 12:34:27AM -0400, Jarod Wilson wrote:
...
For now, I've applied patches 3, 4 and 5, as it is nice to have Jarod's
review also.
I've finally got them all applied atop current media_tree staging/v2.6.37,
though none of the streamzap bits in patch 7 are applicable any longer.
Will try to get through looking and commenting (and testing) of the rest
of them tonight.
Also had to make a minor addition to the rc5-sz decoder (same change
as in the other decoders). Almost have all the requisite test kernels
for David's, Maxim's and Dmitry's patchsets built and installed, wish
my laptop was faster... Probably would have been faster to use a lab
box and copy data over. Oh well. So functional testing to hopefully
commence tomorrow morning.
Wuff. None of the three builds is at all stable on my laptop, but I can't
actually point the finger at any of the three patchsets, since I'm getting
spontaneous lockups doing nothing at all before even plugging in a
receiver. I did however get occasional periods of a non-panicking (not
starting X seems to help a lot). Initial results:
Btw, my printk blackbox patch could help you a lot.
I can't count how many times it helped me.
I just enable softlockup, hardlockup, and nmi watchdog, and let system
panic on oopses, and reboot. Or if you have hardware reboot button, you
can just use it. The point is that most BIOSES don't clear the ram, and
I take advantage of that.
Recently in an attempt to make it reserve only small portion of memory
(before I would use mem=) I also made this work out of box.
After a reboot, to get crash dmesg, just do
sudo cat /sys/kernel/debug/printk/crash_dmesg | strings
Note that kernel contains now a ramoops module that does similar things.
It doesn't reserve the memory automatically, and (this is the reason I
still don't use it) is only called by kernel to save oopses/panicks.
It should be enough though too, but my patch actually places the printk
buffer itself in the fixed area in the ram.
Best regards,
Maxim Levitsky
commit 8f1c423046c22dad6aaeca04bfcb0ab301843c36
Author: Maxim Levitsky maximlevit...@gmail.com
Date: Sat Jul 31 13:43:03 2010 +0300
printk: Allow to fix the physical address of printk buffer
Allows to put printk buffer at fixed location of ram (default 128M).
If debugfs is enabled, log of last boot is copied into
system ram, and can be accessed via debugfs, for example
cat /sys/kernel/debug/printk/crash_dmesg
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index ef292c7..a6eaf40 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -46,6 +46,7 @@ extern unsigned long saved_video_mode;
extern void reserve_standard_io_resources(void);
extern void i386_reserve_resources(void);
extern void setup_default_timer_irq(void);
+extern void early_reserve_printk_buffer(void);
#ifdef CONFIG_X86_MRST
extern void x86_mrst_early_setup(void);
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index c3a4fbb..6fbf2a0 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -843,6 +843,7 @@ void __init setup_arch(char **cmdline_p)
/* after early param, so could get panic from serial */
reserve_early_setup_data();
+ early_reserve_printk_buffer();
if (acpi_mps_check()) {
#ifdef CONFIG_X86_LOCAL_APIC
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 3ba6e06..8854a91 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -106,7 +106,6 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
if (is_ram pfn_valid(pfn) !PageReserved(pfn_to_page(pfn)))
return NULL;
- WARN_ON_ONCE(is_ram);
}
/*
diff --git a/kernel/printk.c b/kernel/printk.c
index 8fe465a..a6fff63 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -41,6 +41,7 @@
#include linux/notifier.h
#include asm/uaccess.h
+#include linux/debugfs.h
/*
* for_each_console() allows you to iterate on each console
@@ -167,6 +168,7 @@ void log_buf_kexec_setup(void)
}
#endif
+#ifndef CONFIG_HWMEM_PRINTK
static int __init log_buf_len_setup(char *str)
{
unsigned size = memparse(str, str);
@@ -207,6 +209,93 @@ out:
}
__setup(log_buf_len=, log_buf_len_setup);
+#endif
+
+#ifdef CONFIG_HWMEM_PRINTK
+
+char *old_log_buf;
+struct debugfs_blob_wrapper crash_dmesg_wrapper;
+static unsigned int printk_phys_address = CONFIG_HWMEM_PRINTK_DEFAULT_ADDRESS;
+
+
+static int __init printk_address_setup(char *p)
+{
+ char *tmp;
+
+ if (!strncmp(p, off, 3))
+ printk_phys_address = 0;
+ else
+ printk_phys_address = memparse(p, tmp);
+ return 0;
+}
+early_param(printk_address, printk_address_setup);
+
+
+void early_reserve_printk_buffer(void)
+{
+ if (printk_phys_address)
+ reserve_early(printk_phys_address,
+ printk_phys_address
Re: [PATCH 0/8 V5] Many fixes for in-kernel decoding and for the ENE driver
On Fri, Sep 10, 2010 at 10:08:24AM +0200, David Härdeman wrote: On Fri, September 10, 2010 04:01, Jarod Wilson wrote: Wuff. None of the three builds is at all stable on my laptop, but I can't actually point the finger at any of the three patchsets, since I'm getting spontaneous lockups doing nothing at all before even plugging in a receiver. I did however get occasional periods of a non-panicking (not starting X seems to help a lot). Initial results: If you get lockups without even plugging in a receiver, does that mean that the rc-core driver hasn't even been loaded at that point? Correct, no rc-core bits loaded at all at this point. -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8 V5] Many fixes for in-kernel decoding and for the ENE driver
On Thu, Sep 09, 2010 at 12:34:27AM -0400, Jarod Wilson wrote: ... For now, I've applied patches 3, 4 and 5, as it is nice to have Jarod's review also. I've finally got them all applied atop current media_tree staging/v2.6.37, though none of the streamzap bits in patch 7 are applicable any longer. Will try to get through looking and commenting (and testing) of the rest of them tonight. Also had to make a minor addition to the rc5-sz decoder (same change as in the other decoders). Almost have all the requisite test kernels for David's, Maxim's and Dmitry's patchsets built and installed, wish my laptop was faster... Probably would have been faster to use a lab box and copy data over. Oh well. So functional testing to hopefully commence tomorrow morning. Wuff. None of the three builds is at all stable on my laptop, but I can't actually point the finger at any of the three patchsets, since I'm getting spontaneous lockups doing nothing at all before even plugging in a receiver. I did however get occasional periods of a non-panicking (not starting X seems to help a lot). Initial results: Dmitry's patchset: - all good for imon, streamzap and mceusb David's patchset: - all good for mceusb, as expected, since David has mce hardware himself, did not try the others yet Maxim's patchset: - all good for mceusb and imon - streamzap decoding fails miserably. I have an inkling why, but will need to get a stable testing platform before I can really properly dig into it. Still working on that stable testing platform, which is backport current ir-core to the latest Fedora 14 kernel, which is 2.6.35.4-based and rock-solid on this machine. After that, will start applying patchsets. (I have yet to really look at the lockups, they look like random memory corruption though). -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8 V5] Many fixes for in-kernel decoding and for the ENE driver
Em 06-09-2010 18:26, Maxim Levitsky escreveu: Hi, Here is full overview of my patches: Patch #1 fixes races in ir thread. It fixes the case when ktherad_stop waits forever for the thread. This happens on module unload and therefore it never finishes. Sorry for introducing this bug. Patch #2, fixes a crash on my module load. It happens because ir core initializes the input device a bit early, therefore it could be accessed while still not set up. Patch #3 fixes a small typo in lirc code that makes it impossible to use tx duty cycle setting. Patch #4 fixes a problem seen on my system that results in stuck down forever key. Patch #5 adds few keys to MCE keymap that were found on laptop of an user I tested this driver with Patch #6, is a combined update ti my driver. It contains lot of refactoring thanks to docs I have now, and lot of fixes, and supports latest version of firmware (and I have 4 users asking for that) It is quite huge, but it would be a tedios job to break it up. This can't introduce regressions because the ene_ir was never released. In addition to that it was tested by me and another two users. Patch #7 the really only patch that touches drivers I don't have does touch the ir-core. It is quite small, and it adds a proper solution to dilema about what to do with huge space between keypresses. Now this space is just truncated by the driver with timeout flag. The lirc codec then ensures that right sample is send to the lircd. Please review and test it. Patch #8 is very simple. It just builds on top of patch #7 and adds carrier reports to ene driver. For now, I've applied patches 3, 4 and 5, as it is nice to have Jarod's review also. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8 V5] Many fixes for in-kernel decoding and for the ENE driver
On Wed, Sep 08, 2010 at 06:54:02PM -0300, Mauro Carvalho Chehab wrote: Em 06-09-2010 18:26, Maxim Levitsky escreveu: Hi, Here is full overview of my patches: Patch #1 fixes races in ir thread. It fixes the case when ktherad_stop waits forever for the thread. This happens on module unload and therefore it never finishes. Sorry for introducing this bug. Patch #2, fixes a crash on my module load. It happens because ir core initializes the input device a bit early, therefore it could be accessed while still not set up. Patch #3 fixes a small typo in lirc code that makes it impossible to use tx duty cycle setting. Patch #4 fixes a problem seen on my system that results in stuck down forever key. Patch #5 adds few keys to MCE keymap that were found on laptop of an user I tested this driver with Patch #6, is a combined update ti my driver. It contains lot of refactoring thanks to docs I have now, and lot of fixes, and supports latest version of firmware (and I have 4 users asking for that) It is quite huge, but it would be a tedios job to break it up. This can't introduce regressions because the ene_ir was never released. In addition to that it was tested by me and another two users. Patch #7 the really only patch that touches drivers I don't have does touch the ir-core. It is quite small, and it adds a proper solution to dilema about what to do with huge space between keypresses. Now this space is just truncated by the driver with timeout flag. The lirc codec then ensures that right sample is send to the lircd. Please review and test it. Patch #8 is very simple. It just builds on top of patch #7 and adds carrier reports to ene driver. For now, I've applied patches 3, 4 and 5, as it is nice to have Jarod's review also. I've finally got them all applied atop current media_tree staging/v2.6.37, though none of the streamzap bits in patch 7 are applicable any longer. Will try to get through looking and commenting (and testing) of the rest of them tonight. -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8 V5] Many fixes for in-kernel decoding and for the ENE driver
On Wed, Sep 8, 2010 at 6:42 PM, Jarod Wilson ja...@redhat.com wrote: On Wed, Sep 08, 2010 at 06:54:02PM -0300, Mauro Carvalho Chehab wrote: Em 06-09-2010 18:26, Maxim Levitsky escreveu: Hi, Here is full overview of my patches: Patch #1 fixes races in ir thread. It fixes the case when ktherad_stop waits forever for the thread. This happens on module unload and therefore it never finishes. Sorry for introducing this bug. Patch #2, fixes a crash on my module load. It happens because ir core initializes the input device a bit early, therefore it could be accessed while still not set up. Patch #3 fixes a small typo in lirc code that makes it impossible to use tx duty cycle setting. Patch #4 fixes a problem seen on my system that results in stuck down forever key. Patch #5 adds few keys to MCE keymap that were found on laptop of an user I tested this driver with Patch #6, is a combined update ti my driver. It contains lot of refactoring thanks to docs I have now, and lot of fixes, and supports latest version of firmware (and I have 4 users asking for that) It is quite huge, but it would be a tedios job to break it up. This can't introduce regressions because the ene_ir was never released. In addition to that it was tested by me and another two users. Patch #7 the really only patch that touches drivers I don't have does touch the ir-core. It is quite small, and it adds a proper solution to dilema about what to do with huge space between keypresses. Now this space is just truncated by the driver with timeout flag. The lirc codec then ensures that right sample is send to the lircd. Please review and test it. Patch #8 is very simple. It just builds on top of patch #7 and adds carrier reports to ene driver. For now, I've applied patches 3, 4 and 5, as it is nice to have Jarod's review also. I've finally got them all applied atop current media_tree staging/v2.6.37, though none of the streamzap bits in patch 7 are applicable any longer. Will try to get through looking and commenting (and testing) of the rest of them tonight. Also had to make a minor addition to the rc5-sz decoder (same change as in the other decoders). Almost have all the requisite test kernels for David's, Maxim's and Dmitry's patchsets built and installed, wish my laptop was faster... Probably would have been faster to use a lab box and copy data over. Oh well. So functional testing to hopefully commence tomorrow morning. -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8 V5] Many fixes for in-kernel decoding and for the ENE driver
Hi, Here is full overview of my patches: Patch #1 fixes races in ir thread. It fixes the case when ktherad_stop waits forever for the thread. This happens on module unload and therefore it never finishes. Sorry for introducing this bug. Patch #2, fixes a crash on my module load. It happens because ir core initializes the input device a bit early, therefore it could be accessed while still not set up. Patch #3 fixes a small typo in lirc code that makes it impossible to use tx duty cycle setting. Patch #4 fixes a problem seen on my system that results in stuck down forever key. Patch #5 adds few keys to MCE keymap that were found on laptop of an user I tested this driver with Patch #6, is a combined update ti my driver. It contains lot of refactoring thanks to docs I have now, and lot of fixes, and supports latest version of firmware (and I have 4 users asking for that) It is quite huge, but it would be a tedios job to break it up. This can't introduce regressions because the ene_ir was never released. In addition to that it was tested by me and another two users. Patch #7 the really only patch that touches drivers I don't have does touch the ir-core. It is quite small, and it adds a proper solution to dilema about what to do with huge space between keypresses. Now this space is just truncated by the driver with timeout flag. The lirc codec then ensures that right sample is send to the lircd. Please review and test it. Patch #8 is very simple. It just builds on top of patch #7 and adds carrier reports to ene driver. Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8 V5] Many fixes for in-kernel decoding and for the ENE driver
On Tue, Sep 07, 2010 at 12:26:05AM +0300, Maxim Levitsky wrote: Hi, Here is full overview of my patches: What changed from V4? -- David Härdeman -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8 V5] Many fixes for in-kernel decoding and for the ENE driver
On Mon, 2010-09-06 at 23:56 +0200, David Härdeman wrote: On Tue, Sep 07, 2010 at 12:26:05AM +0300, Maxim Levitsky wrote: Hi, Here is full overview of my patches: What changed from V4? Nothing other that 2 build fixes that I forgot to include. I also cced linux-media because I was asked to. Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
