Re: [PATCH] OHCI: disallow autostop when wakeup is not available

Previous thread: [BUG] panic 2.6.20-rc3 in nf_conntrack by Malte on Monday, January 1, 2007 - 9:53 am. (2 messages)

Next thread: Re: [PATCH 2.6.19] mmc: Add support for SDHC cards by Pierre Ossman on Monday, January 1, 2007 - 10:49 am. (21 messages)
From: Andrey Borzenkov
Date: Monday, January 1, 2007 - 10:07 am

-----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 ...
From: Rusty Russell
Date: Wednesday, December 31, 1969 - 5:00 pm

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 ...
From: Alan Stern
Date: Tuesday, January 2, 2007 - 8:16 am

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

-

From: David Brownell
Date: Wednesday, January 3, 2007 - 2:50 pm

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

-

From: Andrey Borzenkov
Date: Thursday, January 4, 2007 - 2:09 am

-----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-----
-

From: Oleg Nesterov
Date: Thursday, October 23, 2008 - 2:46 am

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.

--

From: Rusty Russell
Date: Thursday, October 23, 2008 - 8:10 am

Hi Oleg,

   Nice catch.  Can we use smp_call_function here instead?





--

From: Oleg Nesterov
Date: Thursday, October 23, 2008 - 9:16 am

I think you are right, smp_call_function_single() should be fine.

But please note I don't really understand this code ;)

Oleg.

--

Previous thread: [BUG] panic 2.6.20-rc3 in nf_conntrack by Malte on Monday, January 1, 2007 - 9:53 am. (2 messages)

Next thread: Re: [PATCH 2.6.19] mmc: Add support for SDHC cards by Pierre Ossman on Monday, January 1, 2007 - 10:49 am. (21 messages)