-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is the original problem (OHCI constantly attempting and failing to suspend root hub) supposed to be fixed in 2.6.20? Currently in rc3 I have ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1 ohci_hcd 0000:00:02.0: created debug files ohci_hcd 0000:00:02.0: irq 11, io mem 0xf7eff000 ohci_hcd 0000:00:02.0: resetting from state 'reset', control = 0x0 ohci_hcd 0000:00:02.0: enabling initreset quirk ohci_hcd 0000:00:02.0: OHCI controller state ohci_hcd 0000:00:02.0: OHCI 1.0, NO legacy support registers ohci_hcd 0000:00:02.0: control 0x083 HCFS=operational CBSR=3 ohci_hcd 0000:00:02.0: cmdstatus 0x00000 SOC=0 ohci_hcd 0000:00:02.0: intrstatus 0x00000044 RHSC SF ohci_hcd 0000:00:02.0: intrenable 0x8000000a MIE RD WDH ohci_hcd 0000:00:02.0: hcca frame #0003 ohci_hcd 0000:00:02.0: roothub.a 01000203 POTPGT=1 NPS NDP=3(3) ohci_hcd 0000:00:02.0: roothub.b 00000000 PPCM=0000 DR=0000 ohci_hcd 0000:00:02.0: roothub.status 00008000 DRWE ohci_hcd 0000:00:02.0: roothub.portstatus [0] 0x00000100 PPS ohci_hcd 0000:00:02.0: roothub.portstatus [1] 0x00000100 PPS ohci_hcd 0000:00:02.0: roothub.portstatus [2] 0x00000100 PPS usb usb1: default language 0x0409 usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: OHCI Host Controller usb usb1: Manufacturer: Linux 2.6.20-rc3-1avb ohci_hcd usb usb1: SerialNumber: 0000:00:02.0 usb usb1: uevent usb usb1: usb_probe_device usb usb1: configuration #1 chosen from 1 choice usb usb1: adding 1-0:1.0 (config #1, interface 0) usb 1-0:1.0: uevent hub 1-0:1.0: usb_probe_interface hub 1-0:1.0: usb_probe_interface - got id hub 1-0:1.0: USB hub found hub 1-0:1.0: 3 ports detected hub 1-0:1.0: standalone hub hub 1-0:1.0: no power switching (usb 1.0) hub 1-0:1.0: global over-current protection hub 1-0:1.0: power on to power good time: 2ms hub 1-0:1.0: local power source is good hub 1-0:1.0: no over-current condition exists hub 1-0:1.0: trying to enable port power ...
Simple transition to work_on_cpu(), rather than cpumask games.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/cpu/intel_cacheinfo.c | 38 ++++++++++++++++------------------
1 file changed, 18 insertions(+), 20 deletions(-)
diff -r 6f4737048b99 arch/x86/kernel/cpu/intel_cacheinfo.c
--- a/arch/x86/kernel/cpu/intel_cacheinfo.c Thu Oct 23 00:06:30 2008 +1100
+++ b/arch/x86/kernel/cpu/intel_cacheinfo.c Thu Oct 23 00:20:57 2008 +1100
@@ -534,28 +534,13 @@ static void __cpuinit free_cache_attribu
per_cpu(cpuid4_info, cpu) = NULL;
}
-static int __cpuinit detect_cache_attributes(unsigned int cpu)
+static long get_cpu_leaves(void *unused)
{
- struct _cpuid4_info *this_leaf;
- unsigned long j;
- int retval;
- cpumask_t oldmask;
-
- if (num_cache_leaves == 0)
- return -ENOENT;
-
- per_cpu(cpuid4_info, cpu) = kzalloc(
- sizeof(struct _cpuid4_info) * num_cache_leaves, GFP_KERNEL);
- if (per_cpu(cpuid4_info, cpu) == NULL)
- return -ENOMEM;
-
- oldmask = current->cpus_allowed;
- retval = set_cpus_allowed_ptr(current, &cpumask_of_cpu(cpu));
- if (retval)
- goto out;
+ int j, retval = 0, cpu = smp_processor_id();
/* Do cpuid and store the results */
for (j = 0; j < num_cache_leaves; j++) {
+ struct _cpuid4_info *this_leaf;
this_leaf = CPUID4_INFO_IDX(cpu, j);
retval = cpuid4_cache_lookup(j, this_leaf);
if (unlikely(retval < 0)) {
@@ -567,9 +552,22 @@ static int __cpuinit detect_cache_attrib
}
cache_shared_cpu_map_setup(cpu, j);
}
- set_cpus_allowed_ptr(current, &oldmask);
+ return retval;
+}
-out:
+static int __cpuinit detect_cache_attributes(unsigned int cpu)
+{
+ int retval;
+
+ if (num_cache_leaves == 0)
+ return -ENOENT;
+
+ per_cpu(cpuid4_info, cpu) = kzalloc(
+ sizeof(struct _cpuid4_info) * num_cache_leaves, GFP_KERNEL);
+ if (per_cpu(cpuid4_info, cpu) == NULL)
+ return -ENOMEM;
+
+ retval = work_on_cpu(cpu, get_cpu_leaves, NULL);
if ...The patch mentioned above allows the manual method to work. Without the patch you would not be able to stop these messages at all, as you already have seen. Alan Stern -
I'm curious though: did older kernels, say 2.6.18, have such issues? If not, it may still be a software issue ... if you had to use the Not just that ... it also fixed the problem where quirk entries saying "don't even try using remote wakeup" stopped working. Once some pending PPC-related OHCI patches merge (support for PS3 and other CELL systems), there will be infrastructure that makes it easier to add quirk entries that say "this board can't do remote wakeup properly". At that point, we can start to collect quirks for boards like this one. - Dave -
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes. It is hardware problem all right. Exactly. I am sorry for being unclear - actually the question was, whether quirks are implemented in 2.6.20 (because I remember them being mentioned OK so this answers the question - it is not yet being implemented. thank you - -andrey -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFnMQ1R6LMutpd94wRAqayAKDQrqfpERc4F5LjqWMQgI6oxqqOmACdH++H r6aDgoAQDw2SHRq+2yLaoyw= =95Oh -----END PGP SIGNATURE----- -
This doesn't look right. cache_add_dev()->cpuid4_cache_sysfs_init()->detect_cache_attributes() is called by CPU_ONLINE under cpu_hotplug_begin(), this is deadlockable. Yes, the caller (cpu_hotplug.active_writer) can safely take get_online_cpus(), but if we have another pending work which needs get_online_cpus(), we have the deadlock. Oleg. --
Hi Oleg, Nice catch. Can we use smp_call_function here instead? --
I think you are right, smp_call_function_single() should be fine. But please note I don't really understand this code ;) Oleg. --
