Re: [Bug #14942] gkrellm no longer shows all the temperatures on thinkpad x60
On Sun, 10 Jan 2010, Rafael J. Wysocki wrote: Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14942 Subject : gkrellm no longer shows all the temperatures on thinkpad x60 Submitter : Pavel Machek pa...@ucw.cz Date: 2009-12-27 21:57 (15 days old) References : http://marc.info/?l=linux-kernelm=126195107005565w=4 Handled-By : Henrique de Moraes Holschuh h...@hmh.eng.br Patch : http://patchwork.kernel.org/patch/69809/ Waiting for Pavel to confirm whether this can be closed or not. There could be more than one bug involved, and I only fixed one. Can be closed; it seems that gkrellm removed the graphs after it failed once, or something like that. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe kernel-testers in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug #15196] kmem_cache_create: duplicate cache ccid2_h
On Sun, Jan 31, 2010 at 11:20:50PM -0800, David Miller wrote: From: Xiaotian Feng xtf...@gmail.com Date: Mon, 1 Feb 2010 11:30:02 +0800 On Mon, Feb 1, 2010 at 8:22 AM, Rafael J. Wysocki r...@sisk.pl wrote: This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15196 Subject : kmem_cache_create: duplicate cache ccid2_h Submitter : Heinz Diehl h...@fancy-poultry.org Date : 2010-01-30 18:33 (2 days old) References : http://marc.info/?l=linux-kernelm=126487640324942w=4 Cced Neil, I think this one is introduced by commit de4ef86cfce60d2250111f34f8a084e769f23b16, passing char *slab_name_fmt as function parameter, but vsnprintf is using sizeof(slab_name_fmt), which is 8 (or 4 in 32bit kernel) instead of 32 as old version. Does following patch resolve this bug, Heinz? There seems to be even more to this than that. Neils patch seems to need completely reverting. See the patch set posted by Gerrit Renker: http://marc.info/?l=linux-netdevm=126500585823775w=2 http://marc.info/?l=linux-netdevm=126500591923880w=2 Dave, some of this doesn't make the least bit of sense to me. I get the sizeof error, thats clear (and I apologize, I should have seen that), but Gerrits revert of the dccp_probe changes is non-sensical. I'm not sure I even follow the comments: Previously (during about 4 years of this module's history) there had never been a problem with the 'silent dependency' that the commit tried to fix: this dependency is deliberate and required, since dccp_probe performs probing of dccp connections and hence needs to know about dccp internals. He claims this dependency is deliberate and requires, to which I agree, but he would seem to fix that by making the dccp_probe module error out in the event that dccp wasn't loaded. Why bother with that? Neil -- To unsubscribe from this list: send the line unsubscribe kernel-testers in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug #15196] kmem_cache_create: duplicate cache ccid2_h
From: Neil Horman nhor...@tuxdriver.com Date: Mon, 1 Feb 2010 06:55:18 -0500 He claims this dependency is deliberate and requires, to which I agree, but he would seem to fix that by making the dccp_probe module error out in the event that dccp wasn't loaded. Why bother with that? Neil, please get into the thread Gerrit started so he can see your questions and responses too. I already chided him for not CC:'ing you in the first place, guys stop hiding from eachother :-) -- To unsubscribe from this list: send the line unsubscribe kernel-testers in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ACPI: Remove old blacklist entries
On Wed, Jan 27, 2010 at 11:35:20AM +0800, Feng Tang wrote:
Which only enforces the acpi_disabled check and should have no
logical problem.
And I guess your platform is blacklisted and acpi_disabled is set to 1,
while it still need parse ACPI tables to get SMP info. So I would suggest
to add a acpi=force for your case.
It's actually set to force_ht, so it sounds like some blacklisting is
now stricter than it used to be. However, given that acpi=force seems to
work, how about just doing the following?
commit a8d9241dad684f7dda46889f00c9e627773e868e
Author: Matthew Garrett m...@redhat.com
Date: Mon Feb 1 09:51:44 2010 -0500
ACPI: Remove old blacklist entries
The kernel has a set of blacklist entries that disable ACPI functionality
on various machines. These all seem to date from pre-git days and most
have no indication of what they were meant to fix. Let's work on the
assumption that we've fixed whatever it was that was broken before and so
remove most of the entries.
Signed-off-by: Matthew Garrett m...@redhat.com
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index fb1035c..086f0b6 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1256,35 +1256,6 @@ static int __init disable_acpi_pci(const struct
dmi_system_id *d)
return 0;
}
-static int __init dmi_disable_acpi(const struct dmi_system_id *d)
-{
- if (!acpi_force) {
- printk(KERN_NOTICE %s detected: acpi off\n, d-ident);
- disable_acpi();
- } else {
- printk(KERN_NOTICE
- Warning: DMI blacklist says broken, but acpi forced\n);
- }
- return 0;
-}
-
-/*
- * Limit ACPI to CPU enumeration for HT
- */
-static int __init force_acpi_ht(const struct dmi_system_id *d)
-{
- if (!acpi_force) {
- printk(KERN_NOTICE %s detected: force use of acpi=ht\n,
- d-ident);
- disable_acpi();
- acpi_ht = 1;
- } else {
- printk(KERN_NOTICE
- Warning: acpi=force overrules DMI blacklist:
acpi=ht\n);
- }
- return 0;
-}
-
/*
* Force ignoring BIOS IRQ0 pin2 override
*/
@@ -1308,116 +1279,6 @@ static int __init dmi_ignore_irq0_timer_override(const
struct dmi_system_id *d)
* works for you, please contact linux-a...@vger.kernel.org
*/
static struct dmi_system_id __initdata acpi_dmi_table[] = {
- /*
-* Boxes that need ACPI disabled
-*/
- {
-.callback = dmi_disable_acpi,
-.ident = IBM Thinkpad,
-.matches = {
-DMI_MATCH(DMI_BOARD_VENDOR, IBM),
-DMI_MATCH(DMI_BOARD_NAME, 2629H1G),
-},
-},
-
- /*
-* Boxes that need acpi=ht
-*/
- {
-.callback = force_acpi_ht,
-.ident = FSC Primergy T850,
-.matches = {
-DMI_MATCH(DMI_SYS_VENDOR, FUJITSU SIEMENS),
-DMI_MATCH(DMI_PRODUCT_NAME, PRIMERGY T850),
-},
-},
- {
-.callback = force_acpi_ht,
-.ident = HP VISUALIZE NT Workstation,
-.matches = {
-DMI_MATCH(DMI_BOARD_VENDOR, Hewlett-Packard),
-DMI_MATCH(DMI_PRODUCT_NAME, HP VISUALIZE NT Workstation),
-},
-},
- {
-.callback = force_acpi_ht,
-.ident = Compaq Workstation W8000,
-.matches = {
-DMI_MATCH(DMI_SYS_VENDOR, Compaq),
-DMI_MATCH(DMI_PRODUCT_NAME, Workstation W8000),
-},
-},
- {
-.callback = force_acpi_ht,
-.ident = ASUS P2B-DS,
-.matches = {
-DMI_MATCH(DMI_BOARD_VENDOR, ASUSTeK Computer INC.),
-DMI_MATCH(DMI_BOARD_NAME, P2B-DS),
-},
-},
- {
-.callback = force_acpi_ht,
-.ident = ASUS CUR-DLS,
-.matches = {
-DMI_MATCH(DMI_BOARD_VENDOR, ASUSTeK Computer INC.),
-DMI_MATCH(DMI_BOARD_NAME, CUR-DLS),
-},
-},
- {
-.callback = force_acpi_ht,
-.ident = ABIT i440BX-W83977,
-.matches = {
-DMI_MATCH(DMI_BOARD_VENDOR, ABIT http://www.abit.com),
-DMI_MATCH(DMI_BOARD_NAME, i440BX-W83977 (BP6)),
-},
-},
- {
-.callback = force_acpi_ht,
-.ident = IBM Bladecenter,
-.matches = {
-DMI_MATCH(DMI_BOARD_VENDOR, IBM),
-DMI_MATCH(DMI_BOARD_NAME, IBM eServer BladeCenter HS20),
-},
-},
- {
-.callback = force_acpi_ht,
-.ident = IBM eServer xSeries 360,
-.matches = {
-DMI_MATCH(DMI_BOARD_VENDOR, IBM),
-
Re: [Bug #15127] Bluetooth: sleeping function called from invalid context
Hi David,
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.31 and 2.6.32.
The following bug entry is on the current list of known regressions
introduced between 2.6.31 and 2.6.32. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15127
Subject: Bluetooth: sleeping function called from invalid
context
Submitter : David John david...@xenontk.org
Date : 2010-01-12 9:19 (20 days old)
First-Bad-Commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9e726b17422bade75fba94e625cd35fd1353e682
References : http://marc.info/?l=linux-kernelm=126328727021949w=4
you have an outdated email from Luiz and I change it to the right one
now.
I looked with him at the patch and I think this will fix it:
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index fc5ee32..2b50637 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -252,7 +252,6 @@ static void rfcomm_session_timeout(unsigned long
arg)
BT_DBG(session %p state %ld, s, s-state);
set_bit(RFCOMM_TIMED_OUT, s-flags);
- rfcomm_session_put(s);
rfcomm_schedule(RFCOMM_SCHED_TIMEO);
}
@@ -1920,6 +1919,7 @@ static inline void rfcomm_process_sessions(void)
if (test_and_clear_bit(RFCOMM_TIMED_OUT, s-flags)) {
s-state = BT_DISCONN;
rfcomm_send_disc(s, 0);
+ rfcomm_session_put(s);
continue;
}
We need some extra testing on this with the actual hardware we did the
patch for. So this will take at least a few days before we get our hands
on it.
FWIW, your patch fixes the issue.
nice. So I can add a tested-by line to the final patch?
Just our of curiosity, which hardware did you test this with. We only
know about one headset that should cause this issue.
Regards
Marcel
--
To unsubscribe from this list: send the line unsubscribe kernel-testers in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ohci1394_dma=early crash since 2.6.32 (was Re: [Bug #14487] PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0)
On 02/01/10 11:57, Stefan Richter wrote:
Justin P. Mattock wrote:
On 02/01/10 04:54, Dan Carpenter wrote:
On Sun, Jan 31, 2010 at 05:39:22PM -0800, Justin P. Mattock wrote:
On 01/31/10 16:43, Rafael J. Wysocki wrote:
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.31 and 2.6.32.
The following bug entry is on the current list of known regressions
introduced between 2.6.31 and 2.6.32. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14487
Subject : PANIC: early exception 08 rip 246:10 error 810251b5 cr2 0
Submitter : Justin P. Mattockjustinmatt...@gmail.com
Date: 2009-10-23 16:45 (101 days old)
References : http://lkml.org/lkml/2009/10/23/252
[...]
yeah still hitting this.
[...]
I've added the linux1394-devel people to the CC list.
Thanks. Alas the original author is MIA, and the bug seems to be tied
to the early platform setup code (rather than OHCI 1394 device specific
code) about which I for one am clueless.
The listed MAINTAINERS contact of init_ohci1394_dma.c is linux1394-devel
and me, but a good deal of this driver is very x86 platform specific.
(There was some interest in making useful for other architectures, but
this would merely mean that the respective architecture people need to
keep an eye on their parts of this driver.)
Justin has found an issue that when he boots with: ohci1394_dma=early
his computer
crashes.
He can get it to boot by modifying drivers/ieee1394/init_ohci1394_dma.c:
[...]
This modification and some others in the LKML thread from October simply
cause init_ohci1394_controller() to be skipped for all devices.
init_ohci1394_controller() is simple enough:
static inline void __init init_ohci1394_controller(int num, int slot,
int func)
{
unsigned long ohci_base;
struct ti_ohci ohci;
printk(KERN_INFO init_ohci1394_dma: initializing OHCI-1394
at %02x:%02x.%x\n, num, slot, func);
ohci_base = read_pci_config(num, slot, func,
PCI_BASE_ADDRESS_0+(02)) PCI_BASE_ADDRESS_MEM_MASK;
set_fixmap_nocache(FIX_OHCI1394_BASE, ohci_base);
ohci.registers = (void *)fix_to_virt(FIX_OHCI1394_BASE);
init_ohci1394_reset_and_init_dma(ohci);
}
Justin, you already established that read_pci_config is not the point
where it crashes, right?
set_fixmap_nocache() and fix_to_virt() frighten me because I don't know
what they do. :-)
The rest, init_ohci1394_reset_and_init_dma(), is something which I can
easily follow. There is just a bunch of register reads and writes with
occasional mdelays. This /could/ be a cause of the crash too if the
controller is inspired to do something dangerous in there --- meaning,
if the OHCI 1394 controller starts to write something per DMA into
memory. However, we do not switch on any DMA context except for the
so-called physical DMA unit which only springs into action if a remote
FireWire-attached console instructs it to do so.
I am noticing one point where init_ohci1394_dma.c violates the OHCI 1394
specification: OHCI1394_HCControl_linkEnable is witched on while the
OHCI1394_ConfigROMmap register is still invalid. This register needs to
contain a physical address of a 1kB sized, 1kB aligned memory region
which allows DMA_TO_DEVICE. So, since this is a read-only DMA, I am
tempted to say that this potential issue should not be a cause for a
kernel crash.
(Sinde note, the OHCI 1394 spec is freely available, see
http://ieee1394.wiki.kernel.org/index.php/Specifications#OHCI_Release_1.1.2C_January_6.2C_2000
)
Justin Mattock wrote on 2009-10-27 in http://lkml.org/lkml/2009/10/27/335:
o.k. you should be able to view
this:(let me know if you can't and I can
manually write out, and in time find a public
photo sharing suite to make things easier).
http://www.flickr.com/photos/44066...@n08/4050317695
When this happens I see lots of messages from the print
during boot, then this happens.
(Now that a bugzilla.kernel.org ticket exists for this you can also use
bugzilla.kernel.org to publish screenshots if you have an account there.)
This screenshot looks like ___alloc_bootmem_node is the issue here, or
am I mistaken of what the order of functions in the backtrace means?
cool, thanks for the assistance and info on this.
(I'll have to read through the specification for ohci1394);
as for __alloc_bootmem_node I have not looked into that yet.
(I can read up on this today).
what I was looking at was:
set_fixmap_nocache(FIX_OHCI1394_BASE, ohci_base);
which led me to arch/x86/include/asm/fixmap.h
leading me to believe I was hitting something with
FIXADDR_TOP because the system is a pure64.
(reading through fixmap.h there is mention that
vsyscall only covers 32bit making me think this might
be it).
and also:
init_ohci1394_reset_and_init_dma(ohci);
(on the bugreport I have a temporary patch
Re: [Bug #14943] nfs regression?
Hi Rafael, Sorry, I haven't had time to test newer kernels lately :(, but according to changelogs, no related problems were fixed till 2.6.32.7... I'll update problematic machine on wednesday though... regards nik On Mon, Feb 01, 2010 at 01:43:18AM +0100, Rafael J. Wysocki wrote: This message has been generated automatically as a part of a report of regressions introduced between 2.6.31 and 2.6.32. The following bug entry is on the current list of known regressions introduced between 2.6.31 and 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14943 Subject : nfs regression? Submitter : Nikola Ciprich extmaill...@linuxbox.cz Date : 2009-12-28 12:10 (35 days old) References: http://marc.info/?l=linux-kernelm=126200276223524w=4 -- - Nikola CIPRICH LinuxBox.cz, s.r.o. 28. rijna 168, 709 01 Ostrava tel.: +420 596 603 142 fax:+420 596 621 273 mobil: +420 777 093 799 www.linuxbox.cz mobil servis: +420 737 238 656 email servis: ser...@linuxbox.cz - -- To unsubscribe from this list: send the line unsubscribe kernel-testers in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug #15127] Bluetooth: sleeping function called from invalid context
Hi,
On Mon, Feb 1, 2010 at 11:14 AM, Marcel Holtmann mar...@holtmann.org wrote:
Hi David,
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.31 and 2.6.32.
The following bug entry is on the current list of known regressions
introduced between 2.6.31 and 2.6.32. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15127
Subject : Bluetooth: sleeping function called from invalid
context
Submitter : David John david...@xenontk.org
Date : 2010-01-12 9:19 (20 days old)
First-Bad-Commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9e726b17422bade75fba94e625cd35fd1353e682
References : http://marc.info/?l=linux-kernelm=126328727021949w=4
you have an outdated email from Luiz and I change it to the right one
now.
I looked with him at the patch and I think this will fix it:
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index fc5ee32..2b50637 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -252,7 +252,6 @@ static void rfcomm_session_timeout(unsigned long
arg)
BT_DBG(session %p state %ld, s, s-state);
set_bit(RFCOMM_TIMED_OUT, s-flags);
- rfcomm_session_put(s);
rfcomm_schedule(RFCOMM_SCHED_TIMEO);
}
@@ -1920,6 +1919,7 @@ static inline void rfcomm_process_sessions(void)
if (test_and_clear_bit(RFCOMM_TIMED_OUT, s-flags)) {
s-state = BT_DISCONN;
rfcomm_send_disc(s, 0);
+ rfcomm_session_put(s);
continue;
}
We need some extra testing on this with the actual hardware we did the
patch for. So this will take at least a few days before we get our hands
on it.
FWIW, your patch fixes the issue.
nice. So I can add a tested-by line to the final patch?
Just our of curiosity, which hardware did you test this with. We only
know about one headset that should cause this issue.
Just in case, here is the hcidump of the Nokia HS-12W, the one that
has problem when we connection authorization is denied:
ACL data: handle 11 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): SABM: cr 1 dlci 26 pf 1 ilen 0 fcs 0xe7
ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0042 scid 0x0040
ACL data: handle 11 flags 0x02 dlen 8
L2CAP(d): cid 0x0044 len 4 [psm 3]
RFCOMM(s): DM: cr 1 dlci 26 pf 1 ilen 0 fcs 0xcd
HCI Event: Number of Completed Packets (0x13) plen 5
ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0042 scid 0x0040
ACL data: handle 11 flags 0x02 dlen 8
L2CAP(d): cid 0x0044 len 4 [psm 3]
RFCOMM(s): DISC: cr 0 dlci 0 pf 1 ilen 0 fcs 0x9c
ACL data: handle 11 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): UA: cr 0 dlci 0 pf 1 ilen 0 fcs 0xb6
ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0044 scid 0x0041
HCI Event: Number of Completed Packets (0x13) plen 5
ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0044 scid 0x0041
HCI Command: Disconnect (0x01|0x0006) plen 3
HCI Event: Command Status (0x0f) plen 4
HCI Event: Disconn Complete (0x05) plen 4
So this means the patch works. DISC 0 is send from our side (due to
the session timeout) when normally it should be other end that
disconnects right away when we respond with DM.
--
Luiz Augusto von Dentz
Engenheiro de Computação
--
To unsubscribe from this list: send the line unsubscribe kernel-testers in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ohci1394_dma=early crash since 2.6.32 (was Re: [Bug #14487] PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0)
On 02/01/10 14:27, Stefan Richter wrote: Justin P. Mattock wrote: (as for yesterdays 0x(just experimenting)Google gives me no info on the differences between 8f's to 16f's, I was under the impression that it's x86_32 and x86_64 for the pci address). As Dan noted, (class == 0x || 0x) is always true because it is logically the same as (class == whatever) || true If you really meant class == 0x || class == 0x yeah that's what I was going for(just to see). then the latter half will never become true because class is declared as u32 and got its value from read_pci_config() which also returns u32. That's what I was afraid of. I'm guessing there probably would be a lot of things to change for(if this correct) u64. BTW, whether a PCI device is capable of accessing 32 bit bus addresses or also 64 bit bus addresses depends on the device, not on the CPU. Originally, PCI only had a 32 bit addressing model. OHCI 1394 1.0/1.1 implementations only deal with 32 bit local bus addresses. I haven't even looked at what the device was capable of doing. The 'class' however is not an address but merely a register value with 24 bits width. (Defined in the PCI Local Bus spec which is not freely available, cited in OHCI 1394 annex A.3.) This register is read as a 32 bits wide register from which the excess byte is later discarded. If all bits read are 1, the bus:slot:function is not actually populated. So(correct me if I'm wrong), I'm generating a 64 bit register and the kernel is looking for a 32 bit register causing the crash. Justin P. Mattock -- To unsubscribe from this list: send the line unsubscribe kernel-testers in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug #15198] Radeon KMS regression
On Mon, 2010-02-01 at 01:22 +0100, Rafael J. Wysocki wrote: This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15198 Subject : Radeon KMS regression Submitter : Kevin Winchester kjwinches...@gmail.com Date : 2010-01-30 17:18 (2 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=42590a75019a50012f25a962246498dead428433 References: http://marc.info/?l=linux-kernelm=126487191019612w=4 Handled-By: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp Patch : http://patchwork.kernel.org/patch/75023/ This is fixed by the patch from FUJITA Tomonori - I just confirmed with my latest build of Linus' tree (which has the patch). Thanks, -- Kevin Winchester -- To unsubscribe from this list: send the line unsubscribe kernel-testers in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug #15127] Bluetooth: sleeping function called from invalid context
On 02/02/2010 12:44 AM, Marcel Holtmann wrote:
Hi David,
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.31 and 2.6.32.
The following bug entry is on the current list of known regressions
introduced between 2.6.31 and 2.6.32. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15127
Subject: Bluetooth: sleeping function called from invalid
context
Submitter : David John david...@xenontk.org
Date : 2010-01-12 9:19 (20 days old)
First-Bad-Commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9e726b17422bade75fba94e625cd35fd1353e682
References : http://marc.info/?l=linux-kernelm=126328727021949w=4
you have an outdated email from Luiz and I change it to the right one
now.
I looked with him at the patch and I think this will fix it:
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index fc5ee32..2b50637 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -252,7 +252,6 @@ static void rfcomm_session_timeout(unsigned long
arg)
BT_DBG(session %p state %ld, s, s-state);
set_bit(RFCOMM_TIMED_OUT, s-flags);
- rfcomm_session_put(s);
rfcomm_schedule(RFCOMM_SCHED_TIMEO);
}
@@ -1920,6 +1919,7 @@ static inline void rfcomm_process_sessions(void)
if (test_and_clear_bit(RFCOMM_TIMED_OUT, s-flags)) {
s-state = BT_DISCONN;
rfcomm_send_disc(s, 0);
+ rfcomm_session_put(s);
continue;
}
We need some extra testing on this with the actual hardware we did the
patch for. So this will take at least a few days before we get our hands
on it.
FWIW, your patch fixes the issue.
nice. So I can add a tested-by line to the final patch?
Sure,
Tested-by: David John david...@xenontk.org
Just our of curiosity, which hardware did you test this with.
I have an inbuilt (laptop) USB Dell Wireless 365 Bluetooth Module
(413c:8160). I can send more info about the device if you want.
We only know about one headset that should cause this issue.
That's weird. I assumed it would happen for any device, since
rfcomm_session_add is called from multiple places and it adds
rfcomm_session_timeout on a timer which will cause the trace
if the timer fires.
I could be wrong though.
Regards,
David.
Regards
Marcel
--
To unsubscribe from this list: send the line unsubscribe kernel-testers in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug #15127] Bluetooth: sleeping function called from invalid context
Hi David,
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.31 and 2.6.32.
The following bug entry is on the current list of known regressions
introduced between 2.6.31 and 2.6.32. Please verify if it still should
be listed and let me know (either way).
Bug-Entry: http://bugzilla.kernel.org/show_bug.cgi?id=15127
Subject : Bluetooth: sleeping function called from invalid
context
Submitter: David John david...@xenontk.org
Date : 2010-01-12 9:19 (20 days old)
First-Bad-Commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9e726b17422bade75fba94e625cd35fd1353e682
References : http://marc.info/?l=linux-kernelm=126328727021949w=4
you have an outdated email from Luiz and I change it to the right one
now.
I looked with him at the patch and I think this will fix it:
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index fc5ee32..2b50637 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -252,7 +252,6 @@ static void rfcomm_session_timeout(unsigned long
arg)
BT_DBG(session %p state %ld, s, s-state);
set_bit(RFCOMM_TIMED_OUT, s-flags);
- rfcomm_session_put(s);
rfcomm_schedule(RFCOMM_SCHED_TIMEO);
}
@@ -1920,6 +1919,7 @@ static inline void rfcomm_process_sessions(void)
if (test_and_clear_bit(RFCOMM_TIMED_OUT, s-flags)) {
s-state = BT_DISCONN;
rfcomm_send_disc(s, 0);
+ rfcomm_session_put(s);
continue;
}
We need some extra testing on this with the actual hardware we did the
patch for. So this will take at least a few days before we get our hands
on it.
FWIW, your patch fixes the issue.
nice. So I can add a tested-by line to the final patch?
Sure,
Tested-by: David John david...@xenontk.org
Just our of curiosity, which hardware did you test this with.
I have an inbuilt (laptop) USB Dell Wireless 365 Bluetooth Module
(413c:8160). I can send more info about the device if you want.
I meant which device you are connection to. Is it a headset or another
computer.
We only know about one headset that should cause this issue.
That's weird. I assumed it would happen for any device, since
rfcomm_session_add is called from multiple places and it adds
rfcomm_session_timeout on a timer which will cause the trace
if the timer fires.
The timer will only fire for non-behaving remote stacks. With a proper
stack following the RFCOMM specification it should never fire.
Regards
Marcel
--
To unsubscribe from this list: send the line unsubscribe kernel-testers in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ohci1394_dma=early crash since 2.6.32 (was Re: [Bug #14487] PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0)
Justin P. Mattock wrote: So(correct me if I'm wrong), I'm generating a 64 bit register and the kernel is looking for a 32 bit register causing the crash. No, the class = read_pci_config(); if (class == ...) ... parts of the code are entirely innocent as far as I can tell. This is just the FireWire--PCI chip detection. It is the subsequent driver setup for the chip that crashes somewhere. When you modified that chip detection code earlier, you only prevented crashes when your modifications ended up as ignore all PCI devices, also FireWire ones == do nothing at all. Perhaps the bootup sequence of the x86(-64) platform was changed from 2.6.31 to .32 thus that some assumptions in init_ohci1394_dma about when are what resources available are not true anymore. According to your screenshot in http://lkml.org/lkml/2009/10/27/335 the issue is about memory allocation, not about PCI bus access. -- Stefan Richter -=-==-=- --=- ---=- http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line unsubscribe kernel-testers in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug #15127] Bluetooth: sleeping function called from invalid context
On 02/02/2010 11:11 AM, Marcel Holtmann wrote:
Hi David,
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.31 and 2.6.32.
The following bug entry is on the current list of known regressions
introduced between 2.6.31 and 2.6.32. Please verify if it still should
be listed and let me know (either way).
Bug-Entry: http://bugzilla.kernel.org/show_bug.cgi?id=15127
Subject : Bluetooth: sleeping function called from invalid
context
Submitter: David John david...@xenontk.org
Date : 2010-01-12 9:19 (20 days old)
First-Bad-Commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9e726b17422bade75fba94e625cd35fd1353e682
References : http://marc.info/?l=linux-kernelm=126328727021949w=4
you have an outdated email from Luiz and I change it to the right one
now.
I looked with him at the patch and I think this will fix it:
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index fc5ee32..2b50637 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -252,7 +252,6 @@ static void rfcomm_session_timeout(unsigned long
arg)
BT_DBG(session %p state %ld, s, s-state);
set_bit(RFCOMM_TIMED_OUT, s-flags);
- rfcomm_session_put(s);
rfcomm_schedule(RFCOMM_SCHED_TIMEO);
}
@@ -1920,6 +1919,7 @@ static inline void rfcomm_process_sessions(void)
if (test_and_clear_bit(RFCOMM_TIMED_OUT, s-flags)) {
s-state = BT_DISCONN;
rfcomm_send_disc(s, 0);
+ rfcomm_session_put(s);
continue;
}
We need some extra testing on this with the actual hardware we did the
patch for. So this will take at least a few days before we get our hands
on it.
FWIW, your patch fixes the issue.
nice. So I can add a tested-by line to the final patch?
Sure,
Tested-by: David John david...@xenontk.org
Just our of curiosity, which hardware did you test this with.
I have an inbuilt (laptop) USB Dell Wireless 365 Bluetooth Module
(413c:8160). I can send more info about the device if you want.
I meant which device you are connection to. Is it a headset or another
computer.
We only know about one headset that should cause this issue.
That's weird. I assumed it would happen for any device, since
rfcomm_session_add is called from multiple places and it adds
rfcomm_session_timeout on a timer which will cause the trace
if the timer fires.
The timer will only fire for non-behaving remote stacks. With a proper
stack following the RFCOMM specification it should never fire.
Regards
Marcel
Ah. It's a Sony Ericsson W800i phone. I noticed a new problem while
testing yesterday: Transferring a file to the phone seems to happen
correctly, but at the end of the transfer, the phone reports that the
connection was lost and I get this in the log:
btusb_bulk_complete: hci0 urb 88007a5b59c0 failed to resubmit (19)
btusb_bulk_complete: hci0 urb 880077a200c0 failed to resubmit (19)
btusb_intr_complete: hci0 urb 88007a5b5780 failed to resubmit (19)
btusb_send_frame: hci0 urb 88004db809c0 submission failed
To remove btusb, I have to shutdown the laptop Bluetooth. I'll check and
see if I can reproduce and track down the issue. Note that the phone was
working okay pre 2.3.32.
Regards,
David.
--
To unsubscribe from this list: send the line unsubscribe kernel-testers in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ohci1394_dma=early crash since 2.6.32 (was Re: [Bug #14487] PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0)
On 02/01/10 21:45, Stefan Richter wrote:
Justin P. Mattock wrote:
So(correct me if I'm wrong), I'm generating a 64 bit register
and the kernel is looking for a 32 bit register causing the crash.
No, the class = read_pci_config(); if (class == ...) ... parts of the
code are entirely innocent as far as I can tell. This is just the
FireWire--PCI chip detection. It is the subsequent driver setup for the
chip that crashes somewhere.
When you modified that chip detection code earlier, you only prevented
crashes when your modifications ended up as ignore all PCI devices,
also FireWire ones == do nothing at all.
Perhaps the bootup sequence of the x86(-64) platform was changed from
2.6.31 to .32 thus that some assumptions in init_ohci1394_dma about when
are what resources available are not true anymore. According to your
screenshot in http://lkml.org/lkml/2009/10/27/335 the issue is about
memory allocation, not about PCI bus access.
Alright.. I'll keep focus on that
and see if I can figure this out.
As for anything changed in the kernel
(2.6.31 - present), tough to say
from what I remember I had created a new fresh
lfs system using these CFLAGS:
CFLAGS=-mtune=core2 -march=core2 -O2 -pipe -fomit-frame-pointer
CXXFLAGS=${CFLAGS} MAKEOPTS={-j3}
(without -m option gcc defaults(I think)to -m32).
which booted with ohci1394_dma=early just fine.
then decided to build another lfs system with the same CFLAGS except
added -m64 (pure64) to the build process.
(then this showed up).
What I can try is do a git revert to 2.6.29/27 to see if this thing
fires off(before going any further). if the system boots then do a bisect.
Justin P. Mattock
--
To unsubscribe from this list: send the line unsubscribe kernel-testers in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ohci1394_dma=early crash since 2.6.32 (was Re: [Bug #14487] PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0)
Justin P. Mattock wrote:
As for anything changed in the kernel
(2.6.31 - present), tough to say
from what I remember I had created a new fresh
lfs system using these CFLAGS:
CFLAGS=-mtune=core2 -march=core2 -O2 -pipe -fomit-frame-pointer
CXXFLAGS=${CFLAGS} MAKEOPTS={-j3}
(without -m option gcc defaults(I think)to -m32).
which booted with ohci1394_dma=early just fine.
then decided to build another lfs system with the same CFLAGS except
added -m64 (pure64) to the build process.
(then this showed up).
What I can try is do a git revert to 2.6.29/27 to see if this thing
fires off(before going any further). if the system boots then do a bisect.
Do I understand correctly that at this moment it is only known that the
bug could be
- *either* a 2.6.31 - 2.6.32 regression
- *or* an x86-64 specific bug that does not occur on x86-32,
right?
I have an Core 2 Duo based PC with x86-32 kernel and userland and an AMD
based x86-64 PC and could give ohci1394_dma=early a try on both (never
tested it myself before). I could furthermore attempt to build and
install an x86-64 kernel on the Core 2 Duo PC but I am afraid I am far
too short of spare time for that.
--
Stefan Richter
-=-==-=- --=- ---=-
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line unsubscribe kernel-testers in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ohci1394_dma=early crash since 2.6.32 (was Re: [Bug #14487] PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0)
Stefan Richter wrote: Do I understand correctly that at this moment it is only known that the bug could be - *either* a 2.6.31 - 2.6.32 regression - *or* an x86-64 specific bug that does not occur on x86-32, right? (OK, according to your other post it /is/ a regression, at least on x86-64 and definitely between 2.6.27 (good) and 2.6.32 (bad).) -- Stefan Richter -=-==-=- --=- ---=- http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line unsubscribe kernel-testers in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ohci1394_dma=early crash since 2.6.32 (was Re: [Bug #14487] PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0)
On 02/01/10 22:55, Stefan Richter wrote:
Justin P. Mattock wrote:
As for anything changed in the kernel
(2.6.31 - present), tough to say
from what I remember I had created a new fresh
lfs system using these CFLAGS:
CFLAGS=-mtune=core2 -march=core2 -O2 -pipe -fomit-frame-pointer
CXXFLAGS=${CFLAGS} MAKEOPTS={-j3}
(without -m option gcc defaults(I think)to -m32).
which booted with ohci1394_dma=early just fine.
then decided to build another lfs system with the same CFLAGS except
added -m64 (pure64) to the build process.
(then this showed up).
What I can try is do a git revert to 2.6.29/27 to see if this thing
fires off(before going any further). if the system boots then do a bisect.
Do I understand correctly that at this moment it is only known that the
bug could be
- *either* a 2.6.31 - 2.6.32 regression
- *or* an x86-64 specific bug that does not occur on x86-32,
right?
at first I was under the impression this was an arch thing because of
building an x86_32, and then building x86_64(and hitting this). but now
after reverting to 2.6.27 I'm thinking other wise.(my bad, should of
done this at first but didn't even think too);
I have an Core 2 Duo based PC with x86-32 kernel and userland and an AMD
based x86-64 PC and could give ohci1394_dma=early a try on both (never
tested it myself before). I could furthermore attempt to build and
install an x86-64 kernel on the Core 2 Duo PC but I am afraid I am far
too short of spare time for that.
no..
I need to do a bisect from 2.6.27 to present to see
(just need to crash for a few hrs, then can start);
then I'll go from there.
Justin P. Mattock
--
To unsubscribe from this list: send the line unsubscribe kernel-testers in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
