* Re: [PATCH 4/4] powerpc/mpic: FSL MPIC error interrupt support.
From: Scott Wood @ 2012-06-18 19:23 UTC (permalink / raw)
To: Sethi Varun-B16395; +Cc: Wood Scott-B07421, Linuxppc-dev@lists.ozlabs.org
In-Reply-To: <C5ECD7A89D1DC44195F34B25E172658D11E224@039-SN2MPN1-012.039d.mgd.msft.net>
On 06/18/2012 02:19 PM, Sethi Varun-B16395 wrote:
>
>
>> -----Original Message-----
>> From: Wood Scott-B07421
>> Sent: Tuesday, June 19, 2012 12:47 AM
>> To: Sethi Varun-B16395
>> Cc: Kumar Gala; Wood Scott-B07421; Linuxppc-dev@lists.ozlabs.org
>> Subject: Re: [PATCH 4/4] powerpc/mpic: FSL MPIC error interrupt support.
>>
>> On 06/18/2012 02:12 PM, Sethi Varun-B16395 wrote:
>>>
>>>
>>>>>> +/*
>>>>>>> + * Error interrupt registers
>>>>>>> + */
>>>>>>> +
>>>>>>> +#define MPIC_ERR_INT_BASE 0x3900
>>>>>>> +#define MPIC_ERR_INT_EISR 0x0000
>>>>>>> +#define MPIC_ERR_INT_EIMR 0x0010
>>>>>>> +
>>>>>>> #define MPIC_MAX_IRQ_SOURCES 2048
>>>>>>> #define MPIC_MAX_CPUS 32
>>>>>>> #define MPIC_MAX_ISU 32
>>>>>>>
>>>>>>> #define MPIC_MAX_TIMER 8
>>>>>>> #define MPIC_MAX_IPI 4
>>>>>>> +#define MPIC_MAX_ERR 32
>>>>>>
>>>>>> Should probably be 64
>>>>>
>>>>> This patch supports MPIC 4.1 and EISR0. When support is added for
>>>>> EISR1 (didn't realize this was coming until your comment prompted me
>>>>> to check...), this should be updated, but this change alone would
>>>>> not make it work.
>>>>
>>>> Would prefer we handle this now rather than later (T4240 is going to
>>>> need
>>>> EISR1 support).
>>> Hi Kumar,
>>> As of now I don't have a proper mechanism to test this functionality.
>>> I will submit a follow up patch for EISR1/EIMR1 support once I have a
>>> mechanism to test this functionality.
>>
>> You could still write the code in a way that scales to multiple EISRs,
>> and test that it works with EISR0.
>>
> Yes, but I would like to submit the patch once I have tested it.
So test it the way I described, and submit. :-P
-Scott
^ permalink raw reply
* RE: [PATCH 4/4] powerpc/mpic: FSL MPIC error interrupt support.
From: Sethi Varun-B16395 @ 2012-06-18 19:19 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: Linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4FDF7EBC.8090604@freescale.com>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Tuesday, June 19, 2012 12:47 AM
> To: Sethi Varun-B16395
> Cc: Kumar Gala; Wood Scott-B07421; Linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH 4/4] powerpc/mpic: FSL MPIC error interrupt support.
>=20
> On 06/18/2012 02:12 PM, Sethi Varun-B16395 wrote:
> >
> >
> >>>> +/*
> >>>>> + * Error interrupt registers
> >>>>> + */
> >>>>> +
> >>>>> +#define MPIC_ERR_INT_BASE 0x3900
> >>>>> +#define MPIC_ERR_INT_EISR 0x0000
> >>>>> +#define MPIC_ERR_INT_EIMR 0x0010
> >>>>> +
> >>>>> #define MPIC_MAX_IRQ_SOURCES 2048
> >>>>> #define MPIC_MAX_CPUS 32
> >>>>> #define MPIC_MAX_ISU 32
> >>>>>
> >>>>> #define MPIC_MAX_TIMER 8
> >>>>> #define MPIC_MAX_IPI 4
> >>>>> +#define MPIC_MAX_ERR 32
> >>>>
> >>>> Should probably be 64
> >>>
> >>> This patch supports MPIC 4.1 and EISR0. When support is added for
> >>> EISR1 (didn't realize this was coming until your comment prompted me
> >>> to check...), this should be updated, but this change alone would
> >>> not make it work.
> >>
> >> Would prefer we handle this now rather than later (T4240 is going to
> >> need
> >> EISR1 support).
> > Hi Kumar,
> > As of now I don't have a proper mechanism to test this functionality.
> > I will submit a follow up patch for EISR1/EIMR1 support once I have a
> > mechanism to test this functionality.
>=20
> You could still write the code in a way that scales to multiple EISRs,
> and test that it works with EISR0.
>=20
Yes, but I would like to submit the patch once I have tested it.
-Varun
^ permalink raw reply
* Re: [PATCH 4/4] powerpc/mpic: FSL MPIC error interrupt support.
From: Scott Wood @ 2012-06-18 19:17 UTC (permalink / raw)
To: Sethi Varun-B16395; +Cc: Wood Scott-B07421, Linuxppc-dev@lists.ozlabs.org
In-Reply-To: <C5ECD7A89D1DC44195F34B25E172658D11E1F1@039-SN2MPN1-012.039d.mgd.msft.net>
On 06/18/2012 02:12 PM, Sethi Varun-B16395 wrote:
>
>
>>>> +/*
>>>>> + * Error interrupt registers
>>>>> + */
>>>>> +
>>>>> +#define MPIC_ERR_INT_BASE 0x3900
>>>>> +#define MPIC_ERR_INT_EISR 0x0000
>>>>> +#define MPIC_ERR_INT_EIMR 0x0010
>>>>> +
>>>>> #define MPIC_MAX_IRQ_SOURCES 2048
>>>>> #define MPIC_MAX_CPUS 32
>>>>> #define MPIC_MAX_ISU 32
>>>>>
>>>>> #define MPIC_MAX_TIMER 8
>>>>> #define MPIC_MAX_IPI 4
>>>>> +#define MPIC_MAX_ERR 32
>>>>
>>>> Should probably be 64
>>>
>>> This patch supports MPIC 4.1 and EISR0. When support is added for
>>> EISR1 (didn't realize this was coming until your comment prompted me
>>> to check...), this should be updated, but this change alone would not
>>> make it work.
>>
>> Would prefer we handle this now rather than later (T4240 is going to need
>> EISR1 support).
> Hi Kumar,
> As of now I don't have a proper mechanism to test this functionality. I will
> submit a follow up patch for EISR1/EIMR1 support once I have a mechanism to
> test this functionality.
You could still write the code in a way that scales to multiple EISRs,
and test that it works with EISR0.
-Scott
^ permalink raw reply
* RE: [PATCH 4/4] powerpc/mpic: FSL MPIC error interrupt support.
From: Sethi Varun-B16395 @ 2012-06-18 19:12 UTC (permalink / raw)
To: Kumar Gala, Wood Scott-B07421; +Cc: Linuxppc-dev@lists.ozlabs.org
In-Reply-To: <7376AC30-8A8F-4A3E-A025-C8F92AFE23E5@kernel.crashing.org>
>>> +/*
> >>> + * Error interrupt registers
> >>> + */
> >>> +
> >>> +#define MPIC_ERR_INT_BASE 0x3900
> >>> +#define MPIC_ERR_INT_EISR 0x0000
> >>> +#define MPIC_ERR_INT_EIMR 0x0010
> >>> +
> >>> #define MPIC_MAX_IRQ_SOURCES 2048
> >>> #define MPIC_MAX_CPUS 32
> >>> #define MPIC_MAX_ISU 32
> >>>
> >>> #define MPIC_MAX_TIMER 8
> >>> #define MPIC_MAX_IPI 4
> >>> +#define MPIC_MAX_ERR 32
> >>
> >> Should probably be 64
> >
> > This patch supports MPIC 4.1 and EISR0. When support is added for
> > EISR1 (didn't realize this was coming until your comment prompted me
> > to check...), this should be updated, but this change alone would not
> > make it work.
>=20
> Would prefer we handle this now rather than later (T4240 is going to need
> EISR1 support).
Hi Kumar,
As of now I don't have a proper mechanism to test this functionality. I wil=
l
submit a follow up patch for EISR1/EIMR1 support once I have a mechanism to
test this functionality.
Regards
Varun
=20
^ permalink raw reply
* Re: [PATCH 3/7][TRIVIAL][resend] drivers/pci: cleanup kernel-doc warning
From: Bjorn Helgaas @ 2012-06-18 18:22 UTC (permalink / raw)
To: Wanpeng Li
Cc: Christoph Lameter, Srikar Dronamraju, linux-pci, Jesse Barnes,
David Howells, Paul Gortmaker, H. Peter Anvin, Larry Woodman,
Andrea Arcangeli, Stephen Rothwell, Gavin Shan, x86, Hugh Dickins,
Ingo Molnar, KOSAKI Motohiro, Jan Kiszka, Nishanth Aravamudan,
Peter Zijlstra, Mel Gorman, Jason Wessel, Al Viro, cgroups,
Thomas Gleixner, KAMEZAWA Hiroyuki, Michal Hocko, trivial,
linux-mm, linux-kernel, Milton Miller, Minchan Kim, Li Zefan,
Johannes Weiner, Tejun Heo, David Rientjes, Andrew Morton,
linuxppc-dev
In-Reply-To: <1339766154-7470-1-git-send-email-liwp.linux@gmail.com>
On Fri, Jun 15, 2012 at 7:15 AM, Wanpeng Li <liwp.linux@gmail.com> wrote:
> From: Wanpeng Li <liwp@linux.vnet.ibm.com>
>
> Warning(drivers/pci/setup-bus.c:277): No description found for parameter =
'fail_head'
> Warning(drivers/pci/setup-bus.c:277): Excess function parameter 'failed_l=
ist' description in 'assign_requested_resources_sorted'
>
> Signed-off-by: Wanpeng Li <liwp.linux@gmail.com>
> ---
> =A0drivers/pci/setup-bus.c | =A0 =A02 +-
> =A01 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index 8fa2d4b..9165d25 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
> @@ -265,7 +265,7 @@ out:
> =A0* assign_requested_resources_sorted() - satisfy resource requests
> =A0*
> =A0* @head : head of the list tracking requests for resources
> - * @failed_list : head of the list tracking requests that could
> + * @fail_head : head of the list tracking requests that could
> =A0* =A0 =A0 =A0 =A0 =A0 =A0 not be allocated
> =A0*
> =A0* Satisfy resource requests of each element in the list. Add
I applied this; it should appear in my "next" branch tomorrow.
^ permalink raw reply
* Re: [RFC PATCH 09/10] POWERPC: smp: remove call to ipi_call_lock()/ipi_call_unlock()
From: Paul E. McKenney @ 2012-06-18 17:05 UTC (permalink / raw)
To: Yong Zhang
Cc: axboe, nikunj, sshtylyov, david.daney, peterz, linux-kernel, ralf,
akpm, Paul Mackerras, srivatsa.bhat, tglx, linuxppc-dev, mingo
In-Reply-To: <20120618025159.GA24420@zhy>
On Mon, Jun 18, 2012 at 10:51:59AM +0800, Yong Zhang wrote:
> On Sat, Jun 16, 2012 at 09:32:19AM -0700, Paul E. McKenney wrote:
> > On Tue, May 29, 2012 at 03:16:04PM +0800, Yong Zhang wrote:
> > > From: Yong Zhang <yong.zhang@windriver.com>
> > >
> > > 1) call_function.lock used in smp_call_function_many() is just to protect
> > > call_function.queue and &data->refs, cpu_online_mask is outside of the
> > > lock. And it's not necessary to protect cpu_online_mask,
> > > because data->cpumask is pre-calculate and even if a cpu is brougt up
> > > when calling arch_send_call_function_ipi_mask(), it's harmless because
> > > validation test in generic_smp_call_function_interrupt() will take care
> > > of it.
> > >
> > > 2) For cpu down issue, stop_machine() will guarantee that no concurrent
> > > smp_call_fuction() is processing.
> >
> > However, there is an effort to get rid of stop_machine() from the
> > CPU-down path... So something else will be needed.
>
> Yeah. So Thomas changed the commit log like below:
> [
> ipi_call_lock/unlock() lock resp. unlock call_function.lock. This lock
> protects only the call_function data structure itself, but it's
> completely unrelated to cpu_online_mask. The mask to which the IPIs
> are sent is calculated before call_function.lock is taken in
> smp_call_function_many(), so the locking around set_cpu_online() is
> pointless and can be removed.
>
> [ tglx: Massaged changelog ]
> ]
>
> in tip/smp/hotplug.
Got it, thank you!
Thanx, Paul
> Thanks,
> Yong
>
> >
> > Thanx, Paul
> >
> > > Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
> > > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > > Cc: Paul Mackerras <paulus@samba.org>
> > > Cc: linuxppc-dev@lists.ozlabs.org
> > > ---
> > > arch/powerpc/kernel/smp.c | 2 --
> > > 1 files changed, 0 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> > > index e4cb343..e1417c4 100644
> > > --- a/arch/powerpc/kernel/smp.c
> > > +++ b/arch/powerpc/kernel/smp.c
> > > @@ -571,7 +571,6 @@ void __devinit start_secondary(void *unused)
> > > if (system_state == SYSTEM_RUNNING)
> > > vdso_data->processorCount++;
> > > #endif
> > > - ipi_call_lock();
> > > notify_cpu_starting(cpu);
> > > set_cpu_online(cpu, true);
> > > /* Update sibling maps */
> > > @@ -601,7 +600,6 @@ void __devinit start_secondary(void *unused)
> > > of_node_put(np);
> > > }
> > > of_node_put(l2_cache);
> > > - ipi_call_unlock();
> > >
> > > local_irq_enable();
> > >
> > > --
> > > 1.7.5.4
> > >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
> --
> Only stand for myself
>
^ permalink raw reply
* Re: RCU stalls on 32-bit pmac SMP
From: Paul E. McKenney @ 2012-06-18 17:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1339979746.2372.6.camel@pasglop>
On Mon, Jun 18, 2012 at 10:35:46AM +1000, Benjamin Herrenschmidt wrote:
> Hi Paul !
>
> I was about to go debug something else when I hit that with -rc3 (plus
> the patch to fix the current bug.h breakage) on a 32-bit PowerMac G4 SMP
> (2 CPUs): About 1mn pause at boot followed by a bunch of RCU stall
> messages. Log below. Any idea where to start looking ?
>
> pci 0002:20:0f.0: reg 30: [mem 0xf5100000-0xf51fffff pref]
> PCI 0000:00 Cannot reserve Legacy IO [io 0x802000-0x802fff]
> PCI 0001:10 Cannot reserve Legacy IO [io 0x0000-0x0fff]
> pci_bus 0000:00: resource 4 [io 0x802000-0x1001fff]
> pci_bus 0000:00: resource 5 [mem 0xf1000000-0xf1ffffff]
> pci_bus 0000:00: resource 6 [mem 0x90000000-0x9fffffff]
> pci_bus 0001:10: resource 4 [io 0x0000-0x7fffff]
> pci_bus 0001:10: resource 5 [mem 0xf3000000-0xf3ffffff]
> pci_bus 0001:10: resource 6 [mem 0x80000000-0x8fffffff]
> pci_bus 0002:20: resource 4 [io 0xff7fe000-0xffffdfff]
> pci_bus 0002:20: resource 5 [mem 0xf5000000-0xf5ffffff]
> bio: create slab <bio-0> at 0
> vgaarb: device added: PCI:0000:00:10.0,decodes=io+mem,owns=io+mem,locks=none
> vgaarb: loaded
> vgaarb: bridge control possible 0000:00:10.0
> SCSI subsystem initialized
> libata version 3.00 loaded.
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> Switching to clocksource timebase
> NET: Registered protocol family 2
> IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
> TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
> TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
> TCP: Hash tables configured (established 131072 bind 65536)
> TCP: reno registered
> UDP hash table entries: 512 (order: 2, 16384 bytes)
> UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
> NET: Registered protocol family 1
> RPC: Registered named UNIX socket transport module.
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> RPC: Registered tcp NFSv4.1 backchannel transport module.
> pci 0001:10:18.0: enabling device (0000 -> 0002)
> pci 0001:10:19.0: enabling device (0000 -> 0002)
> PCI: CLS mismatch (32 != 1020), using 32 bytes
> highmem bounce pool size: 64 pages
> NFS: Registering the id_resolver key type
> Key type id_resolver registered
> msgmni has been set to 1500
> Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
> io scheduler noop registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> Using unsupported 1680x1050 ATY,BlueStone_A at 9c008000, depth=8, pitch=1792
> Console: switching to colour frame buffer device 210x65
> fb0: Open Firmware frame buffer device on /pci@f0000000/ATY,BlueStoneParent@10/ATY,BlueStone_A
> Using unsupported 640x480 ATY,BlueStone_B at 99008000, depth=8, pitch=768
> checking generic (9c008000 1cb600) vs hw (99008000 5a000)
> fb1: Open Firmware frame buffer device on /pci@f0000000/ATY,BlueStoneParent@10/ATY,BlueStone_B
> Generic RTC Driver v1.07
> Generic non-volatile memory driver v1.1
> brd: module loaded
> loop: module loaded
> MacIO PCI driver attached to Keylargo chipset
> adb: starting probe task...
> adb: finished probe task...
> mesh: configured for synchronous 5 MB/s
> st: Version 20101219, fixed bufsize 32768, s/g segs 256
> pata-macio 0.0001f000:ata-4: Activating pata-macio chipset KeyLargo ATA-4, Apple bus ID 2
> scsi0 : pata_macio
> ata1: PATA max UDMA/66 irq 19
> ata1.00: ATA-5: ST380021A, 5.05, max UDMA/100
> ata1.00: 156301488 sectors, multi 16: LBA
> ata1.01: ATA-5: ST380021A, 3.75, max UDMA/100
> ata1.01: 156301488 sectors, multi 16: LBA
> ata1.00: configured for UDMA/66
> ata1.01: configured for UDMA/66
> scsi 0:0:0:0: Direct-Access ATA ST380021A 5.05 PQ: 0 ANSI: 5
> sd 0:0:0:0: [sda] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> sd 0:0:0:0: Attached scsi generic sg0 type 0
> sda: [mac] sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda12 sda13 sda14 sda15
> sd 0:0:0:0: [sda] Attached SCSI disk
> scsi 0:0:1:0: Direct-Access ATA ST380021A 3.75 PQ: 0 ANSI: 5
> sd 0:0:1:0: [sdb] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB)
> sd 0:0:1:0: [sdb] Write Protect is off
> sd 0:0:1:0: Attached scsi generic sg1 type 0
> sd 0:0:1:0: [sdb] Mode Sense: 00 3a 00 00
> sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> INFO: rcu_sched self-detected stall on CPU { 0} (t=16163 jiffies)
> Call Trace:
> INFO: rcu_sched self-detected stall on CPU { 1} (t=16163 jiffies)
> Call Trace:
> [ef877d30] [c0008d04] show_stack+0x50/0x158 (unreliable)
> [ef877d70] [c0097fe4] __rcu_pending+0x184/0x46c
> [ef877da0] [c00991a0] rcu_check_callbacks+0x7c/0x168
> [ef877dc0] [c0044a40] update_process_times+0x3c/0x70
> [ef877de0] [c0083a3c] tick_sched_timer+0x88/0x100
> [ef877e10] [c005b11c] __run_hrtimer.clone.29+0x54/0x104
> [ef877e30] [c005bf44] hrtimer_interrupt+0x158/0x3f8
> [ef877ea0] [c000b5c4] timer_interrupt+0x1cc/0x204
> [ef877ed0] [c0011b88] ret_from_except+0x0/0x1c
> --- Exception: 901 at cpu_idle+0xe4/0x188
Am I reading this correctly? Did the system really take a scheduling-clock
interrupt from within another scheduling-clock interrupt?
If so, my first question is "Why did the scheduling-clock interrupt
run for so long?" ;-)
Thanx, Paul
> LR = cpu_idle+0xc8/0x188
> [ef877f90] [c00097e8] cpu_idle+0x60/0x188 (unreliable)
> [ef877fc0] [c046531c] start_secondary+0x2c8/0x2cc
> [ef877ff0] [00003278] 0x3278
> [ef873b60] [c0008d04] show_stack+0x50/0x158 (unreliable)
> [ef873ba0] [c0097fe4] __rcu_pending+0x184/0x46c
> [ef873bd0] [c0099240] rcu_check_callbacks+0x11c/0x168
> [ef873bf0] [c0044a40] update_process_times+0x3c/0x70
> [ef873c10] [c0083a3c] tick_sched_timer+0x88/0x100
> [ef873c40] [c005b11c] __run_hrtimer.clone.29+0x54/0x104
> [ef873c60] [c005bf44] hrtimer_interrupt+0x158/0x3f8
> [ef873cd0] [c000b5c4] timer_interrupt+0x1cc/0x204
> [ef873d00] [c0011b88] ret_from_except+0x0/0x1c
> --- Exception: 901 at wake_up_new_task+0x134/0x16c
> LR = wake_up_new_task+0x134/0x16c
> [ef873dc0] [c0065f08] wake_up_new_task+0xfc/0x16c (unreliable)
> [ef873df0] [c0035530] do_fork+0xe8/0x2bc
> [ef873e30] [c0008a4c] sys_clone+0x50/0x90
> [ef873e50] [c00114b8] ret_from_syscall+0x0/0x40
> --- Exception: c00 at kernel_thread+0x28/0x68
> LR = __call_usermodehelper+0x40/0xdc
> [ef873f10] [c005f5c8] async_run_entry_fn+0x128/0x1e4 (unreliable)
> [ef873f20] [ef878c00] 0xef878c00
> [ef873f40] [c004e668] process_one_work+0x150/0x3f0
> [ef873f70] [c00514f0] worker_thread+0x18c/0x37c
> [ef873fb0] [c00567bc] kthread+0x84/0x88
> [ef873ff0] [c000f514] kernel_thread+0x4c/0x68
> pata-macio 0.00020000:ata-3: Activating pata-macio chipset KeyLargo ATA-3, Apple bus ID 0
> scsi1 : pata_macio
> ata2: PATA max MWDMA2 irq 20
> sdb: [mac] sdb1 sdb2 sdb3 sdb4 sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 sdb12 sdb13
> sd 0:0:1:0: [sdb] Attached SCSI disk
> ata2.00: ATAPI: PIONEER DVD-RW DVR-104, A227, max UDMA/33
> ata2.00: configured for MWDMA2
> scsi 1:0:0:0: CD-ROM PIONEER DVD-RW DVR-104 A227 PQ: 0 ANSI: 5
> pata-macio 0.00021000:ata-3: Activating pata-macio chipset KeyLargo ATA-3, Apple bus ID 1
> scsi2 : pata_macio
> ata3: PATA max MWDMA2 irq 21
> sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray
> cdrom: Uniform CD-ROM driver Revision: 3.20
> sr 1:0:0:0: Attached scsi CD-ROM sr0
> pcnet32: pcnet32.c:v1.35 21.Apr.2008 tsbogend@alpha.franken.de
> sr 1:0:0:0: Attached scsi generic sg2 type 5
> sungem.c:v1.0 David S. Miller <davem@redhat.com>
> gem 0002:20:0f.0: eth0: Sun GEM (PCI) 10/100/1000BaseT Ethernet 00:03:93:6f:04:b2
> PPP generic driver version 2.4.2
> PPP Deflate Compression module registered
> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> ohci_hcd 0001:10:18.0: OHCI Host Controller
> ohci_hcd 0001:10:18.0: new USB bus registered, assigned bus number 1
> ohci_hcd 0001:10:18.0: irq 27, io mem 0x80081000
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 2 ports detected
> ohci_hcd 0001:10:19.0: OHCI Host Controller
> ohci_hcd 0001:10:19.0: new USB bus registered, assigned bus number 2
> ohci_hcd 0001:10:19.0: irq 28, io mem 0x80080000
> hub 2-0:1.0: USB hub found
> hub 2-0:1.0: 2 ports detected
> mousedev: PS/2 mouse device common for all mice
> usbcore: registered new interface driver appletouch
> PowerMac i2c bus pmu 2 registered
> i2c i2c-0: i2c-powermac: invalid reg on /pci@f2000000/mac-io@17/via-pmu@16000/rtc
> i2c i2c-0: i2c-powermac: invalid reg on /pci@f2000000/mac-io@17/via-pmu@16000/power-mgt
> PowerMac i2c bus pmu 1 registered
> i2c i2c-1: i2c-powermac: invalid reg on /pci@f2000000/mac-io@17/via-pmu@16000/rtc
> i2c i2c-1: i2c-powermac: invalid reg on /pci@f2000000/mac-io@17/via-pmu@16000/power-mgt
> PowerMac i2c bus mac-io 0 registered
> i2c i2c-2: i2c-powermac: invalid reg on /pci@f2000000/mac-io@17/i2c@18000/cereal
> i2c i2c-2: i2c-powermac: invalid reg on /pci@f2000000/mac-io@17/i2c@18000/deq
> i2c i2c-2: i2c-powermac: invalid reg on /pci@f2000000/mac-io@17/i2c@18000/i2c-modem
> PowerMac i2c bus uni-n 1 registered
> i2c i2c-3: i2c-powermac: invalid reg on /uni-n@f8000000/i2c@f8001000/cereal
> PowerMac i2c bus uni-n 0 registered
> i2c i2c-4: i2c-powermac: invalid reg on /uni-n@f8000000/i2c@f8001000/cereal
> APM Battery Driver
> usbcore: registered new interface driver usbhid
> usbhid: USB HID core driver
> oprofile: using ppc/7450 performance monitoring.
> TCP: cubic registered
> Initializing XFRM netlink socket
> NET: Registered protocol family 17
> NET: Registered protocol family 15
> Key type dns_resolver registered
> PM: Hibernation image not present or could not be loaded.
> input: PMU as /devices/virtual/input/input0
> kjournald starting. Commit interval 5 seconds
> EXT3-fs (sda15): mounted filesystem with writeback data mode
> VFS: Mounted root (ext3 filesystem) readonly on device 8:15.
> usb 1-1: new full-speed USB device number 2 using ohci_hcd
> devtmpfs: mounted
> Freeing unused kernel memory: 240k freed
> hub 1-1:1.0: USB hub found
> hub 1-1:1.0: 3 ports detected
> usb 1-2: new full-speed USB device number 3 using ohci_hcd
> hub 1-2:1.0: USB hub found
> hub 1-2:1.0: 3 ports detected
> usb 1-1.3: new full-speed USB device number 4 using ohci_hcd
> input: Mitsumi Electric Apple Extended USB Keyboard as /devices/pci0001:10/0001:10:18.0/usb1/1-1/1-1.3/1-1.3:1.0/input/input1
> hid-generic 0003:05AC:020B.0001: input: USB HID v1.10 Keyboard [Mitsumi Electric Apple Extended USB Keyboard] on usb-0001:10:18.0-1.3/input0
> input: Mitsumi Electric Apple Extended USB Keyboard as /devices/pci0001:10/0001:10:18.0/usb1/1-1/1-1.3/1-1.3:1.1/input/input2
> hid-generic 0003:05AC:020B.0002: input: USB HID v1.10 Device [Mitsumi Electric Apple Extended USB Keyboard] on usb-0001:10:18.0-1.3/input1
> usb 1-2.3: new low-speed USB device number 5 using ohci_hcd
> hid-generic 0003:05AC:9219.0003: claimed by neither input, hiddev nor hidraw
> udevd[1209]: starting version 175
> EXT3-fs (sda15): using internal journal
> sungem_phy: PHY ID: 2060e1, addr: 0
> gem 0002:20:0f.0: eth0: Found BCM5421 PHY
> gem 0002:20:0f.0: eth0: Link is up at 100 Mbps, full-duplex
> gem 0002:20:0f.0: eth0: Pause is enabled (rxfifo: 10240 off: 7168 on: 5632)
> sshd (2042): /proc/2042/oom_adj is deprecated, please use /proc/2042/oom_score_adj instead.
>
>
^ permalink raw reply
* Re: [PATCH] PPC: PCI: Fix pcibios_io_space_offset() so it works for 32-bit ptr/64-bit rsrcs
From: Bjorn Helgaas @ 2012-06-18 15:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras, Ben Collins
In-Reply-To: <1338959744.7150.153.camel@pasglop>
On Tue, Jun 5, 2012 at 11:15 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Tue, 2012-06-05 at 23:50 -0400, Ben Collins wrote:
>> The commit introducing pcibios_io_space_offset() was ignoring 32-bit to
>> 64-bit sign extention, which is the case on ppc32 with 64-bit resource
>> addresses. This only seems to have shown up while running under QEMU for
>> e500mc target. It may or may be suboptimal that QEMU has an IO base
>> address > 32-bits for the e500-pci implementation, but 1) it's still a
>> regression and 2) it's more correct to handle things this way.
>
> See Bjorn, we both did end up getting it wrong :-)
Ooh, sorry about that. Who's going to push this fix? I don't see it
in Linus' tree yet. If you want me to, please forward me the original
patch.
>> Signed-off-by: Ben Collins <bcollins@ubuntu.com>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
>> =A0arch/powerpc/kernel/pci-common.c | =A0 =A08 +++++++-
>> =A01 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-=
common.c
>> index 8e78e93..be9ced7 100644
>> --- a/arch/powerpc/kernel/pci-common.c
>> +++ b/arch/powerpc/kernel/pci-common.c
>> @@ -1477,9 +1477,15 @@ int pcibios_enable_device(struct pci_dev *dev, in=
t mask)
>> =A0 =A0 =A0 return pci_enable_resources(dev, mask);
>> =A0}
>>
>> +/* Before assuming too much here, take care to realize that we need sig=
n
>> + * extension from 32-bit pointers to 64-bit resource addresses to work.
>> + */
>> =A0resource_size_t pcibios_io_space_offset(struct pci_controller *hose)
>> =A0{
>> - =A0 =A0 return (unsigned long) hose->io_base_virt - _IO_BASE;
>> + =A0 =A0 long vbase =3D (long)hose->io_base_virt;
>> + =A0 =A0 long io_base =3D _IO_BASE;
>> +
>> + =A0 =A0 return (resource_size_t)(vbase - io_base);
>> =A0}
>>
>> =A0static void __devinit pcibios_setup_phb_resources(struct pci_controll=
er *hose, struct list_head *resources)
>
>
^ permalink raw reply
* Re: Questions on Hugetlb for bookE and PHYS_64BIT
From: Becky Bruce @ 2012-06-18 14:22 UTC (permalink / raw)
To: Scott Wood; +Cc: telenn barz, linuxppc-dev
In-Reply-To: <4FDB7AEC.2010102@freescale.com>
On Jun 15, 2012, at 1:11 PM, Scott Wood wrote:
> On 06/15/2012 09:43 AM, telenn barz wrote:
>> Hi all,
>>=20
>> CONFIG_PHYS_64BIT enables kernel support for larger than 32-bit =
physical
>> addresses. Is it this configuration option we have to enable for the
>> support of 36-bit real memory (as are capable the Freescale e500v2 or
>> e500mc cores family) ?
>=20
> Yes.
>=20
>> The Hugetlb patch for BookE
>> =
(https://lists.ozlabs.org/pipermail/linuxppc-dev/2011-June/091315.html)
>> seems to be surbordinated to CONFIG_PHYS_64BIT. Is there any good =
reason
>> why it is not supported when CONFIG_PHYS_64BIT is disabled ?
>=20
> Because it would be extra work to support that configuration, and
> nobody's felt enough of a need for it to put in that work.
Most of the use-cases we had demanding hugetlb were *also* cases that =
had large amounts of memory, so this is the model we adopted. Plus, we =
need some of the code from the 36-bit implementation, including the part =
that causes the lowest level of the page table to widen to 64 bits; =
additionally we did not measure much, if any, of a perf hit when =
enabling PHYS_64BIT.=20
Obviously, it could be made to work without it, although there are real =
code changes required. But unless you have a case where you have a =
noticeable performance drop from enabling CONFIG_PHYS_64BIT, it's not =
worth the effort.
-Becky
>=20
> -Scott
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [RFC/PATCH] i2c/powermac: Improve detection of devices from device-tree
From: Andreas Schwab @ 2012-06-18 12:57 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1340014606.2372.13.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> This patch adds a number of workarounds for broken Apple device-trees
> mostly around sound chips. It handles creating the missing audio codec
> devices and works around various issues with missing addresses or
> missing compatible properties.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> Andreas, this is what I've been cooking up today. Still mostly untested
> though, so handle with care :-) But it gives you the basic premises.
Sucessfully tested on PowerBook6,7 and PowerMac7,3 (both tas3004, the
latter with the deq workaround).
These are the remaining failures on PowerMac7,3:
i2c i2c-5: No i2c address for /ht@0,f2000000/pci@1/mac-io@7/i2c@18000/i2c-modem
i2c i2c-6: i2c-powermac: modalias failure on /u3@0,f8000000/i2c@f8001000/cereal@1c0
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [RFC/PATCH] i2c/powermac: Improve detection of devices from device-tree
From: Benjamin Herrenschmidt @ 2012-06-18 10:16 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
This patch adds a number of workarounds for broken Apple device-trees
mostly around sound chips. It handles creating the missing audio codec
devices and works around various issues with missing addresses or
missing compatible properties.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Andreas, this is what I've been cooking up today. Still mostly untested
though, so handle with care :-) But it gives you the basic premises.
>From there I intend to look into moving over at least some of sound/ppc/pmac
to aoa (at least the tumbler bits which is the tas3001) which would get rid
of all i2c gunk in that older driver.
However that means adding a "fabric" module for pre-"layout-id" stuff so
it will be a bit of work ... but I do have access to a machine (windtunnel G4
second generation).
Cheers,
Ben.
drivers/i2c/busses/i2c-powermac.c | 157 +++++++++++++++++++++++++++++++------
1 file changed, 133 insertions(+), 24 deletions(-)
diff --git a/drivers/i2c/busses/i2c-powermac.c b/drivers/i2c/busses/i2c-powermac.c
index 31c47e1..5285f85 100644
--- a/drivers/i2c/busses/i2c-powermac.c
+++ b/drivers/i2c/busses/i2c-powermac.c
@@ -227,28 +227,138 @@ static int __devexit i2c_powermac_remove(struct platform_device *dev)
return 0;
}
+static u32 __devinit i2c_powermac_get_addr(struct i2c_adapter *adap,
+ struct pmac_i2c_bus *bus,
+ struct device_node *node)
+{
+ const __be32 *prop;
+ int len;
+
+ /* First check for valid "reg" */
+ prop = of_get_property(node, "reg", &len);
+ if (prop && (len >= sizeof(int)))
+ return (be32_to_cpup(prop) & 0xff) >> 1;
+
+ /* Then check old-style "i2c-address" */
+ prop = of_get_property(node, "i2c-address", &len);
+ if (prop && (len >= sizeof(int)))
+ return (be32_to_cpup(prop) & 0xff) >> 1;
+
+ /* Now handle some devices with missing "reg" properties */
+ if (!strcmp(node->name, "cereal"))
+ return 0x60;
+ else if (!strcmp(node->name, "deq"))
+ return 0x34;
+
+ dev_warn(&adap->dev, "No i2c address for %s\n", node->full_name);
+
+ return 0xffffffff;
+}
+
+static void __devinit i2c_powermac_create_one(struct i2c_adapter *adap,
+ const char *type,
+ u32 addr)
+{
+ struct i2c_board_info info = {};
+ struct i2c_client *newdev;
+
+ strncpy(info.type, type, sizeof(info.type));
+ info.addr = addr;
+ newdev = i2c_new_device(adap, &info);
+ if (!newdev)
+ dev_err(&adap->dev,
+ "i2c-powermac: Failure to register missing %s\n",
+ type);
+}
+
+static void __devinit i2c_powermac_add_missing(struct i2c_adapter *adap,
+ struct pmac_i2c_bus *bus,
+ bool found_onyx)
+{
+ struct device_node *busnode = pmac_i2c_get_bus_node(bus);
+ int rc;
+
+ /* Check for the onyx audio codec */
+#define ONYX_REG_CONTROL 67
+ if (of_device_is_compatible(busnode, "k2-i2c") && !found_onyx) {
+ union i2c_smbus_data data;
+
+ rc = i2c_smbus_xfer(adap, 0x46, 0, I2C_SMBUS_READ,
+ ONYX_REG_CONTROL, I2C_SMBUS_BYTE_DATA,
+ &data);
+ if (rc >= 0)
+ i2c_powermac_create_one(adap, "MAC,pcm3052", 0x46);
+
+ rc = i2c_smbus_xfer(adap, 0x47, 0, I2C_SMBUS_READ,
+ ONYX_REG_CONTROL, I2C_SMBUS_BYTE_DATA,
+ &data);
+ if (rc >= 0)
+ i2c_powermac_create_one(adap, "MAC,pcm3052", 0x47);
+ }
+}
+
+static bool __devinit i2c_powermac_get_type(struct i2c_adapter *adap,
+ struct device_node *node,
+ u32 addr, char *type, int type_size)
+{
+ char tmp[16];
+
+ /* Note: we to _NOT_ want the standard
+ * i2c drivers to match with any of our powermac stuff
+ * unless they have been specifically modified to handle
+ * it on a case by case basis. For example, for thermal
+ * control, things like lm75 etc... shall match with their
+ * corresponding windfarm drivers, _NOT_ the generic ones,
+ * so we force a prefix of AAPL, onto the modalias to
+ * make that happen
+ */
+
+ /* First try proper modalias */
+ if (of_modalias_node(node, tmp, sizeof(tmp)) >= 0) {
+ snprintf(type, type_size, "MAC,%s", tmp);
+ return true;
+ }
+
+ /* Now look for known workarounds */
+ if (!strcmp(node->name, "deq")) {
+ /* Apple uses address 0x34 for TAS3001 and 0x35 for TAS3004 */
+ if (addr == 0x34) {
+ snprintf(type, type_size, "MAC,tas3001");
+ return true;
+ } else if (addr == 0x35) {
+ snprintf(type, type_size, "MAC,tas3004");
+ return true;
+ }
+ }
+
+ dev_err(&adap->dev, "i2c-powermac: modalias failure"
+ " on %s\n", node->full_name);
+ return false;
+}
+
static void __devinit i2c_powermac_register_devices(struct i2c_adapter *adap,
struct pmac_i2c_bus *bus)
{
struct i2c_client *newdev;
struct device_node *node;
+ bool found_onyx = 0;
+
+ /*
+ * In some cases we end up with the via-pmu node itself, in this
+ * case we skip this function completely as the device-tree will
+ * not contain anything useful.
+ */
+ if (!strcmp(adap->dev.of_node->name, "via-pmu"))
+ return;
for_each_child_of_node(adap->dev.of_node, node) {
struct i2c_board_info info = {};
- struct dev_archdata dev_ad = {};
- const __be32 *reg;
- char tmp[16];
u32 addr;
- int len;
/* Get address & channel */
- reg = of_get_property(node, "reg", &len);
- if (!reg || (len < sizeof(int))) {
- dev_err(&adap->dev, "i2c-powermac: invalid reg on %s\n",
- node->full_name);
+ addr = i2c_powermac_get_addr(adap, bus, node);
+ if (addr == 0xffffffff)
continue;
- }
- addr = be32_to_cpup(reg);
/* Multibus setup, check channel */
if (!pmac_i2c_match_adapter(node, adap))
@@ -257,27 +367,23 @@ static void __devinit i2c_powermac_register_devices(struct i2c_adapter *adap,
dev_dbg(&adap->dev, "i2c-powermac: register %s\n",
node->full_name);
- /* Make up a modalias. Note: we to _NOT_ want the standard
- * i2c drivers to match with any of our powermac stuff
- * unless they have been specifically modified to handle
- * it on a case by case basis. For example, for thermal
- * control, things like lm75 etc... shall match with their
- * corresponding windfarm drivers, _NOT_ the generic ones,
- * so we force a prefix of AAPL, onto the modalias to
- * make that happen
+ /*
+ * Keep track of some device existence to handle
+ * workarounds later.
*/
- if (of_modalias_node(node, tmp, sizeof(tmp)) < 0) {
- dev_err(&adap->dev, "i2c-powermac: modalias failure"
- " on %s\n", node->full_name);
+ if (of_device_is_compatible(node, "pcm3052"))
+ found_onyx = true;
+
+ /* Make up a modalias */
+ if (!i2c_powermac_get_type(adap, node, addr,
+ info.type, sizeof(info.type))) {
continue;
}
- snprintf(info.type, sizeof(info.type), "MAC,%s", tmp);
/* Fill out the rest of the info structure */
- info.addr = (addr & 0xff) >> 1;
+ info.addr = addr;
info.irq = irq_of_parse_and_map(node, 0);
info.of_node = of_node_get(node);
- info.archdata = &dev_ad;
newdev = i2c_new_device(adap, &info);
if (!newdev) {
@@ -292,6 +398,9 @@ static void __devinit i2c_powermac_register_devices(struct i2c_adapter *adap,
continue;
}
}
+
+ /* Additional workarounds */
+ i2c_powermac_add_missing(adap, bus, found_onyx);
}
static int __devinit i2c_powermac_probe(struct platform_device *dev)
--
1.7.10
^ permalink raw reply related
* [PATCH] sound/aoa: remove i2c attach_adapter method
From: Andreas Schwab @ 2012-06-18 7:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1339984980.2372.9.camel@pasglop>
Since i2c-powermac now creates all i2c devices on its own, remove the
attach_adapter methods from the TAS and Onyx drivers, and adjust the
module aliases to match the names used by i2c-powermac.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
sound/aoa/codecs/onyx.c | 75 ++--------------------------------------------
sound/aoa/codecs/tas.c | 80 ++-----------------------------------------------
2 files changed, 6 insertions(+), 149 deletions(-)
diff --git a/sound/aoa/codecs/onyx.c b/sound/aoa/codecs/onyx.c
index 270790d..4cedc69 100644
--- a/sound/aoa/codecs/onyx.c
+++ b/sound/aoa/codecs/onyx.c
@@ -997,45 +997,10 @@ static void onyx_exit_codec(struct aoa_codec *codec)
onyx->codec.soundbus_dev->detach_codec(onyx->codec.soundbus_dev, onyx);
}
-static int onyx_create(struct i2c_adapter *adapter,
- struct device_node *node,
- int addr)
-{
- struct i2c_board_info info;
- struct i2c_client *client;
-
- memset(&info, 0, sizeof(struct i2c_board_info));
- strlcpy(info.type, "aoa_codec_onyx", I2C_NAME_SIZE);
- info.addr = addr;
- info.platform_data = node;
- client = i2c_new_device(adapter, &info);
- if (!client)
- return -ENODEV;
-
- /*
- * We know the driver is already loaded, so the device should be
- * already bound. If not it means binding failed, which suggests
- * the device doesn't really exist and should be deleted.
- * Ideally this would be replaced by better checks _before_
- * instantiating the device.
- */
- if (!client->driver) {
- i2c_unregister_device(client);
- return -ENODEV;
- }
-
- /*
- * Let i2c-core delete that device on driver removal.
- * This is safe because i2c-core holds the core_lock mutex for us.
- */
- list_add_tail(&client->detected, &client->driver->clients);
- return 0;
-}
-
static int onyx_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
- struct device_node *node = client->dev.platform_data;
+ struct device_node *node = client->dev.of_node;
struct onyx *onyx;
u8 dummy;
@@ -1071,40 +1036,6 @@ static int onyx_i2c_probe(struct i2c_client *client,
return -ENODEV;
}
-static int onyx_i2c_attach(struct i2c_adapter *adapter)
-{
- struct device_node *busnode, *dev = NULL;
- struct pmac_i2c_bus *bus;
-
- bus = pmac_i2c_adapter_to_bus(adapter);
- if (bus == NULL)
- return -ENODEV;
- busnode = pmac_i2c_get_bus_node(bus);
-
- while ((dev = of_get_next_child(busnode, dev)) != NULL) {
- if (of_device_is_compatible(dev, "pcm3052")) {
- const u32 *addr;
- printk(KERN_DEBUG PFX "found pcm3052\n");
- addr = of_get_property(dev, "reg", NULL);
- if (!addr)
- return -ENODEV;
- return onyx_create(adapter, dev, (*addr)>>1);
- }
- }
-
- /* if that didn't work, try desperate mode for older
- * machines that have stuff missing from the device tree */
-
- if (!of_device_is_compatible(busnode, "k2-i2c"))
- return -ENODEV;
-
- printk(KERN_DEBUG PFX "found k2-i2c, checking if onyx chip is on it\n");
- /* probe both possible addresses for the onyx chip */
- if (onyx_create(adapter, NULL, 0x46) == 0)
- return 0;
- return onyx_create(adapter, NULL, 0x47);
-}
-
static int onyx_i2c_remove(struct i2c_client *client)
{
struct onyx *onyx = i2c_get_clientdata(client);
@@ -1117,16 +1048,16 @@ static int onyx_i2c_remove(struct i2c_client *client)
}
static const struct i2c_device_id onyx_i2c_id[] = {
- { "aoa_codec_onyx", 0 },
+ { "MAC,pcm3052", 0 },
{ }
};
+MODULE_DEVICE_TABLE(i2c,onyx_i2c_id);
static struct i2c_driver onyx_driver = {
.driver = {
.name = "aoa_codec_onyx",
.owner = THIS_MODULE,
},
- .attach_adapter = onyx_i2c_attach,
.probe = onyx_i2c_probe,
.remove = onyx_i2c_remove,
.id_table = onyx_i2c_id,
diff --git a/sound/aoa/codecs/tas.c b/sound/aoa/codecs/tas.c
index 8e63d1f..c491ae0 100644
--- a/sound/aoa/codecs/tas.c
+++ b/sound/aoa/codecs/tas.c
@@ -883,43 +883,10 @@ static void tas_exit_codec(struct aoa_codec *codec)
}
-static int tas_create(struct i2c_adapter *adapter,
- struct device_node *node,
- int addr)
-{
- struct i2c_board_info info;
- struct i2c_client *client;
-
- memset(&info, 0, sizeof(struct i2c_board_info));
- strlcpy(info.type, "aoa_codec_tas", I2C_NAME_SIZE);
- info.addr = addr;
- info.platform_data = node;
-
- client = i2c_new_device(adapter, &info);
- if (!client)
- return -ENODEV;
- /*
- * We know the driver is already loaded, so the device should be
- * already bound. If not it means binding failed, and then there
- * is no point in keeping the device instantiated.
- */
- if (!client->driver) {
- i2c_unregister_device(client);
- return -ENODEV;
- }
-
- /*
- * Let i2c-core delete that device on driver removal.
- * This is safe because i2c-core holds the core_lock mutex for us.
- */
- list_add_tail(&client->detected, &client->driver->clients);
- return 0;
-}
-
static int tas_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
- struct device_node *node = client->dev.platform_data;
+ struct device_node *node = client->dev.of_node;
struct tas *tas;
tas = kzalloc(sizeof(struct tas), GFP_KERNEL);
@@ -953,47 +920,6 @@ static int tas_i2c_probe(struct i2c_client *client,
return -EINVAL;
}
-static int tas_i2c_attach(struct i2c_adapter *adapter)
-{
- struct device_node *busnode, *dev = NULL;
- struct pmac_i2c_bus *bus;
-
- bus = pmac_i2c_adapter_to_bus(adapter);
- if (bus == NULL)
- return -ENODEV;
- busnode = pmac_i2c_get_bus_node(bus);
-
- while ((dev = of_get_next_child(busnode, dev)) != NULL) {
- if (of_device_is_compatible(dev, "tas3004")) {
- const u32 *addr;
- printk(KERN_DEBUG PFX "found tas3004\n");
- addr = of_get_property(dev, "reg", NULL);
- if (!addr)
- continue;
- return tas_create(adapter, dev, ((*addr) >> 1) & 0x7f);
- }
- /* older machines have no 'codec' node with a 'compatible'
- * property that says 'tas3004', they just have a 'deq'
- * node without any such property... */
- if (strcmp(dev->name, "deq") == 0) {
- const u32 *_addr;
- u32 addr;
- printk(KERN_DEBUG PFX "found 'deq' node\n");
- _addr = of_get_property(dev, "i2c-address", NULL);
- if (!_addr)
- continue;
- addr = ((*_addr) >> 1) & 0x7f;
- /* now, if the address doesn't match any of the two
- * that a tas3004 can have, we cannot handle this.
- * I doubt it ever happens but hey. */
- if (addr != 0x34 && addr != 0x35)
- continue;
- return tas_create(adapter, dev, addr);
- }
- }
- return -ENODEV;
-}
-
static int tas_i2c_remove(struct i2c_client *client)
{
struct tas *tas = i2c_get_clientdata(client);
@@ -1011,16 +937,16 @@ static int tas_i2c_remove(struct i2c_client *client)
}
static const struct i2c_device_id tas_i2c_id[] = {
- { "aoa_codec_tas", 0 },
+ { "MAC,tas3004", 0 },
{ }
};
+MODULE_DEVICE_TABLE(i2c,tas_i2c_id);
static struct i2c_driver tas_driver = {
.driver = {
.name = "aoa_codec_tas",
.owner = THIS_MODULE,
},
- .attach_adapter = tas_i2c_attach,
.probe = tas_i2c_probe,
.remove = tas_i2c_remove,
.id_table = tas_i2c_id,
--
1.7.11
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related
* Re: [PATCH] [ppc] Do not reserve cpu spin-table for crash kernel
From: Suzuki K. Poulose @ 2012-06-18 6:27 UTC (permalink / raw)
To: Simon Horman; +Cc: B29882, linuxppc-dev, kexec
In-Reply-To: <20120524060933.14035.42732.stgit@suzukikp.in.ibm.com>
On 05/24/2012 11:39 AM, Suzuki K. Poulose wrote:
> As of now, the kexec reserves the spin-table for all the CPUs
> on an SMP machine. The spin-table is pointed to by the
> cpu-release-addr property in the device-tree. Reserving the
> spin-table in the crash kernel will cause a BUG(), if the table
> lies outside the memory reserved for the crashkernel.
>
> Disable reserving the spin-table regions and use maxcpus=1 to
> use only the crashing CPU to boot the crash kernel.
>
> Signed-off-by: Suzuki K. Poulose<suzuki@in.ibm.com>
Simon,
Any response on this one ?
I have tested this on a Currituck board (476, SMP) with a UP kernel.
Without this patch, the secondary kernel hits 'PANIC' in boot while
trying to reserve a memory(the spin table), outside the memory
range(crash reserve).
Thanks
Suzuki
> ---
>
> kexec/arch/ppc/crashdump-powerpc.c | 19 +++++++++++++------
> kexec/arch/ppc/fixup_dtb.c | 4 ++++
> 2 files changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/kexec/arch/ppc/crashdump-powerpc.c b/kexec/arch/ppc/crashdump-powerpc.c
> index 1bef69b..4c8c75d 100644
> --- a/kexec/arch/ppc/crashdump-powerpc.c
> +++ b/kexec/arch/ppc/crashdump-powerpc.c
> @@ -262,10 +262,19 @@ static void ulltoa(unsigned long long i, char *str)
> }
> }
>
> +/* Append str to cmdline */
> +static void add_cmdline(char *cmdline, char *str)
> +{
> + int cmdlen = strlen(cmdline) + strlen(str);
> + if (cmdlen> (COMMAND_LINE_SIZE - 1))
> + die("Command line overflow\n");
> + strcat(cmdline, str);
> +}
> +
> static int add_cmdline_param(char *cmdline, unsigned long long addr,
> char *cmdstr, char *byte)
> {
> - int cmdlen, len, align = 1024;
> + int align = 1024;
> char str[COMMAND_LINE_SIZE], *ptr;
>
> /* Passing in =xxxK / =xxxM format. Saves space required in cmdline.*/
> @@ -284,11 +293,8 @@ static int add_cmdline_param(char *cmdline, unsigned long long addr,
> ptr += strlen(str);
> ulltoa(addr, ptr);
> strcat(str, byte);
> - len = strlen(str);
> - cmdlen = strlen(cmdline) + len;
> - if (cmdlen> (COMMAND_LINE_SIZE - 1))
> - die("Command line overflow\n");
> - strcat(cmdline, str);
> +
> + add_cmdline(cmdline, str);
>
> dbgprintf("Command line after adding elfcorehdr: %s\n", cmdline);
>
> @@ -365,6 +371,7 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline,
> */
> add_cmdline_param(mod_cmdline, elfcorehdr, " elfcorehdr=", "K");
> add_cmdline_param(mod_cmdline, saved_max_mem, " savemaxmem=", "M");
> + add_cmdline(mod_cmdline, " maxcpus=1");
> return 0;
> }
>
> diff --git a/kexec/arch/ppc/fixup_dtb.c b/kexec/arch/ppc/fixup_dtb.c
> index e9890a4..f832026 100644
> --- a/kexec/arch/ppc/fixup_dtb.c
> +++ b/kexec/arch/ppc/fixup_dtb.c
> @@ -172,6 +172,9 @@ static void fixup_reserve_regions(struct kexec_info *info, char *blob_buf)
> }
> }
>
> +#if 0
> + /* XXX: Do not reserve spin-table for CPUs. */
> +
> /* Add reserve regions for cpu-release-addr */
> nodeoffset = fdt_node_offset_by_prop_value(blob_buf, -1, "device_type", "cpu", 4);
> while (nodeoffset != -FDT_ERR_NOTFOUND) {
> @@ -201,6 +204,7 @@ static void fixup_reserve_regions(struct kexec_info *info, char *blob_buf)
> nodeoffset = fdt_node_offset_by_prop_value(blob_buf, nodeoffset,
> "device_type", "cpu", 4);
> }
> +#endif
>
> out:
> print_fdt_reserve_regions(blob_buf);
>
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
^ permalink raw reply
* Re: [RFC PATCH 09/10] POWERPC: smp: remove call to ipi_call_lock()/ipi_call_unlock()
From: Yong Zhang @ 2012-06-18 2:51 UTC (permalink / raw)
To: Paul E. McKenney
Cc: axboe, nikunj, sshtylyov, david.daney, peterz, linux-kernel, ralf,
akpm, Paul Mackerras, srivatsa.bhat, tglx, linuxppc-dev, mingo
In-Reply-To: <20120616163219.GI2420@linux.vnet.ibm.com>
On Sat, Jun 16, 2012 at 09:32:19AM -0700, Paul E. McKenney wrote:
> On Tue, May 29, 2012 at 03:16:04PM +0800, Yong Zhang wrote:
> > From: Yong Zhang <yong.zhang@windriver.com>
> >
> > 1) call_function.lock used in smp_call_function_many() is just to protect
> > call_function.queue and &data->refs, cpu_online_mask is outside of the
> > lock. And it's not necessary to protect cpu_online_mask,
> > because data->cpumask is pre-calculate and even if a cpu is brougt up
> > when calling arch_send_call_function_ipi_mask(), it's harmless because
> > validation test in generic_smp_call_function_interrupt() will take care
> > of it.
> >
> > 2) For cpu down issue, stop_machine() will guarantee that no concurrent
> > smp_call_fuction() is processing.
>
> However, there is an effort to get rid of stop_machine() from the
> CPU-down path... So something else will be needed.
Yeah. So Thomas changed the commit log like below:
[
ipi_call_lock/unlock() lock resp. unlock call_function.lock. This lock
protects only the call_function data structure itself, but it's
completely unrelated to cpu_online_mask. The mask to which the IPIs
are sent is calculated before call_function.lock is taken in
smp_call_function_many(), so the locking around set_cpu_online() is
pointless and can be removed.
[ tglx: Massaged changelog ]
]
in tip/smp/hotplug.
Thanks,
Yong
>
> Thanx, Paul
>
> > Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Cc: Paul Mackerras <paulus@samba.org>
> > Cc: linuxppc-dev@lists.ozlabs.org
> > ---
> > arch/powerpc/kernel/smp.c | 2 --
> > 1 files changed, 0 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> > index e4cb343..e1417c4 100644
> > --- a/arch/powerpc/kernel/smp.c
> > +++ b/arch/powerpc/kernel/smp.c
> > @@ -571,7 +571,6 @@ void __devinit start_secondary(void *unused)
> > if (system_state == SYSTEM_RUNNING)
> > vdso_data->processorCount++;
> > #endif
> > - ipi_call_lock();
> > notify_cpu_starting(cpu);
> > set_cpu_online(cpu, true);
> > /* Update sibling maps */
> > @@ -601,7 +600,6 @@ void __devinit start_secondary(void *unused)
> > of_node_put(np);
> > }
> > of_node_put(l2_cache);
> > - ipi_call_unlock();
> >
> > local_irq_enable();
> >
> > --
> > 1.7.5.4
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Only stand for myself
^ permalink raw reply
* Re: [PATCH 01/15] i2c/powermac: Register i2c devices from device-tree
From: Benjamin Herrenschmidt @ 2012-06-18 2:03 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <m2r4tofuxr.fsf@igel.home>
On Sat, 2012-06-09 at 15:58 +0200, Andreas Schwab wrote:
> That breaks the tas3004 driver (and most likely the pcm3052 driver as
> well), since it wants to create its own i2c device. I'm using the
> attached patch as a workaround (only tas3004 driver tested on iBook G4),
> but that needs to move the workarounds for the older systems that don't
> have proper compatible properties somewhere else, which I don't know
> where.
>
> Andreas.
Can I put your signed-off-by: on that one ?
Cheers,
Ben.
> ---
> sound/aoa/codecs/onyx.c | 75 ++------------------------------------------
> sound/aoa/codecs/tas.c | 80 ++---------------------------------------------
> 2 files changed, 6 insertions(+), 149 deletions(-)
>
> diff --git a/sound/aoa/codecs/onyx.c b/sound/aoa/codecs/onyx.c
> index 270790d..4cedc69 100644
> --- a/sound/aoa/codecs/onyx.c
> +++ b/sound/aoa/codecs/onyx.c
> @@ -997,45 +997,10 @@ static void onyx_exit_codec(struct aoa_codec *codec)
> onyx->codec.soundbus_dev->detach_codec(onyx->codec.soundbus_dev, onyx);
> }
>
> -static int onyx_create(struct i2c_adapter *adapter,
> - struct device_node *node,
> - int addr)
> -{
> - struct i2c_board_info info;
> - struct i2c_client *client;
> -
> - memset(&info, 0, sizeof(struct i2c_board_info));
> - strlcpy(info.type, "aoa_codec_onyx", I2C_NAME_SIZE);
> - info.addr = addr;
> - info.platform_data = node;
> - client = i2c_new_device(adapter, &info);
> - if (!client)
> - return -ENODEV;
> -
> - /*
> - * We know the driver is already loaded, so the device should be
> - * already bound. If not it means binding failed, which suggests
> - * the device doesn't really exist and should be deleted.
> - * Ideally this would be replaced by better checks _before_
> - * instantiating the device.
> - */
> - if (!client->driver) {
> - i2c_unregister_device(client);
> - return -ENODEV;
> - }
> -
> - /*
> - * Let i2c-core delete that device on driver removal.
> - * This is safe because i2c-core holds the core_lock mutex for us.
> - */
> - list_add_tail(&client->detected, &client->driver->clients);
> - return 0;
> -}
> -
> static int onyx_i2c_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> - struct device_node *node = client->dev.platform_data;
> + struct device_node *node = client->dev.of_node;
> struct onyx *onyx;
> u8 dummy;
>
> @@ -1071,40 +1036,6 @@ static int onyx_i2c_probe(struct i2c_client *client,
> return -ENODEV;
> }
>
> -static int onyx_i2c_attach(struct i2c_adapter *adapter)
> -{
> - struct device_node *busnode, *dev = NULL;
> - struct pmac_i2c_bus *bus;
> -
> - bus = pmac_i2c_adapter_to_bus(adapter);
> - if (bus == NULL)
> - return -ENODEV;
> - busnode = pmac_i2c_get_bus_node(bus);
> -
> - while ((dev = of_get_next_child(busnode, dev)) != NULL) {
> - if (of_device_is_compatible(dev, "pcm3052")) {
> - const u32 *addr;
> - printk(KERN_DEBUG PFX "found pcm3052\n");
> - addr = of_get_property(dev, "reg", NULL);
> - if (!addr)
> - return -ENODEV;
> - return onyx_create(adapter, dev, (*addr)>>1);
> - }
> - }
> -
> - /* if that didn't work, try desperate mode for older
> - * machines that have stuff missing from the device tree */
> -
> - if (!of_device_is_compatible(busnode, "k2-i2c"))
> - return -ENODEV;
> -
> - printk(KERN_DEBUG PFX "found k2-i2c, checking if onyx chip is on it\n");
> - /* probe both possible addresses for the onyx chip */
> - if (onyx_create(adapter, NULL, 0x46) == 0)
> - return 0;
> - return onyx_create(adapter, NULL, 0x47);
> -}
> -
> static int onyx_i2c_remove(struct i2c_client *client)
> {
> struct onyx *onyx = i2c_get_clientdata(client);
> @@ -1117,16 +1048,16 @@ static int onyx_i2c_remove(struct i2c_client *client)
> }
>
> static const struct i2c_device_id onyx_i2c_id[] = {
> - { "aoa_codec_onyx", 0 },
> + { "MAC,pcm3052", 0 },
> { }
> };
> +MODULE_DEVICE_TABLE(i2c,onyx_i2c_id);
>
> static struct i2c_driver onyx_driver = {
> .driver = {
> .name = "aoa_codec_onyx",
> .owner = THIS_MODULE,
> },
> - .attach_adapter = onyx_i2c_attach,
> .probe = onyx_i2c_probe,
> .remove = onyx_i2c_remove,
> .id_table = onyx_i2c_id,
> diff --git a/sound/aoa/codecs/tas.c b/sound/aoa/codecs/tas.c
> index 8e63d1f..c491ae0 100644
> --- a/sound/aoa/codecs/tas.c
> +++ b/sound/aoa/codecs/tas.c
> @@ -883,43 +883,10 @@ static void tas_exit_codec(struct aoa_codec *codec)
> }
>
>
> -static int tas_create(struct i2c_adapter *adapter,
> - struct device_node *node,
> - int addr)
> -{
> - struct i2c_board_info info;
> - struct i2c_client *client;
> -
> - memset(&info, 0, sizeof(struct i2c_board_info));
> - strlcpy(info.type, "aoa_codec_tas", I2C_NAME_SIZE);
> - info.addr = addr;
> - info.platform_data = node;
> -
> - client = i2c_new_device(adapter, &info);
> - if (!client)
> - return -ENODEV;
> - /*
> - * We know the driver is already loaded, so the device should be
> - * already bound. If not it means binding failed, and then there
> - * is no point in keeping the device instantiated.
> - */
> - if (!client->driver) {
> - i2c_unregister_device(client);
> - return -ENODEV;
> - }
> -
> - /*
> - * Let i2c-core delete that device on driver removal.
> - * This is safe because i2c-core holds the core_lock mutex for us.
> - */
> - list_add_tail(&client->detected, &client->driver->clients);
> - return 0;
> -}
> -
> static int tas_i2c_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> - struct device_node *node = client->dev.platform_data;
> + struct device_node *node = client->dev.of_node;
> struct tas *tas;
>
> tas = kzalloc(sizeof(struct tas), GFP_KERNEL);
> @@ -953,47 +920,6 @@ static int tas_i2c_probe(struct i2c_client *client,
> return -EINVAL;
> }
>
> -static int tas_i2c_attach(struct i2c_adapter *adapter)
> -{
> - struct device_node *busnode, *dev = NULL;
> - struct pmac_i2c_bus *bus;
> -
> - bus = pmac_i2c_adapter_to_bus(adapter);
> - if (bus == NULL)
> - return -ENODEV;
> - busnode = pmac_i2c_get_bus_node(bus);
> -
> - while ((dev = of_get_next_child(busnode, dev)) != NULL) {
> - if (of_device_is_compatible(dev, "tas3004")) {
> - const u32 *addr;
> - printk(KERN_DEBUG PFX "found tas3004\n");
> - addr = of_get_property(dev, "reg", NULL);
> - if (!addr)
> - continue;
> - return tas_create(adapter, dev, ((*addr) >> 1) & 0x7f);
> - }
> - /* older machines have no 'codec' node with a 'compatible'
> - * property that says 'tas3004', they just have a 'deq'
> - * node without any such property... */
> - if (strcmp(dev->name, "deq") == 0) {
> - const u32 *_addr;
> - u32 addr;
> - printk(KERN_DEBUG PFX "found 'deq' node\n");
> - _addr = of_get_property(dev, "i2c-address", NULL);
> - if (!_addr)
> - continue;
> - addr = ((*_addr) >> 1) & 0x7f;
> - /* now, if the address doesn't match any of the two
> - * that a tas3004 can have, we cannot handle this.
> - * I doubt it ever happens but hey. */
> - if (addr != 0x34 && addr != 0x35)
> - continue;
> - return tas_create(adapter, dev, addr);
> - }
> - }
> - return -ENODEV;
> -}
> -
> static int tas_i2c_remove(struct i2c_client *client)
> {
> struct tas *tas = i2c_get_clientdata(client);
> @@ -1011,16 +937,16 @@ static int tas_i2c_remove(struct i2c_client *client)
> }
>
> static const struct i2c_device_id tas_i2c_id[] = {
> - { "aoa_codec_tas", 0 },
> + { "MAC,tas3004", 0 },
> { }
> };
> +MODULE_DEVICE_TABLE(i2c,tas_i2c_id);
>
> static struct i2c_driver tas_driver = {
> .driver = {
> .name = "aoa_codec_tas",
> .owner = THIS_MODULE,
> },
> - .attach_adapter = tas_i2c_attach,
> .probe = tas_i2c_probe,
> .remove = tas_i2c_remove,
> .id_table = tas_i2c_id,
> --
> 1.7.10.4
>
>
^ permalink raw reply
* Re: [PATCH 01/15] i2c/powermac: Register i2c devices from device-tree
From: Benjamin Herrenschmidt @ 2012-06-18 1:27 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <1339312981.24838.98.camel@pasglop>
On Sun, 2012-06-10 at 17:23 +1000, Benjamin Herrenschmidt wrote:
> Ah, excellent, so a small quirk in i2c_powermac is the way to go then,
> we can detect it by name and hack up something. Either that or even
> better, in prom_init, we could add the missing property to the
> device-tree.
>
> Any chance you can try that ? (Look at other examples of DT fixups in
> prom_init.c and don't forget the RELOC() around strings :-)
Ok, don't bother. I've been looking into it more closely and I think
the best solution here is actually self contained in i2c-powermac.
I found a couple more device-tree oddities in older machines that
I'm adding workarounds for as well. I'll send a couple of patches
later today including your original one.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 0/7][TRIVIAL][resend] trivial patches
From: Michael Ellerman @ 2012-06-18 1:16 UTC (permalink / raw)
To: Wanpeng Li
Cc: Christoph Lameter, Srikar Dronamraju, linux-pci, Jesse Barnes,
David Howells, Paul Gortmaker, H. Peter Anvin, Larry Woodman,
Andrea Arcangeli, Stephen Rothwell, Gavin Shan, x86, Hugh Dickins,
Ingo Molnar, KOSAKI Motohiro, Jan Kiszka, Nishanth Aravamudan,
Peter Zijlstra, Mel Gorman, Johannes Weiner, Al Viro,
Bjorn Helgaas, cgroups, Thomas Gleixner, KAMEZAWA Hiroyuki,
Michal Hocko, trivial, linux-mm, linux-kernel, Milton Miller,
Minchan Kim, Li Zefan, Jason Wessel, Tejun Heo, David Rientjes,
Andrew Morton, linuxppc-dev
In-Reply-To: <1339766499-7891-1-git-send-email-liwp.linux@gmail.com>
On Fri, 2012-06-15 at 21:21 +0800, Wanpeng Li wrote:
> From: Wanpeng Li <liwp@linux.vnet.ibm.com>
>
> Since these patches has already send more than one week and
> doesn't get any response, I collect them and send out a patch set.
These patches are all trivial cleanups, so I would not expect to get any
response. Just look to see if they appear in the -next branches of the
various maintainers before the next merge window, ie. in the next few
weeks.
If they haven't been picked up before the next merge window, then you
should resend them.
cheers
^ permalink raw reply
* RCU stalls on 32-bit pmac SMP
From: Benjamin Herrenschmidt @ 2012-06-18 0:35 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: linuxppc-dev
Hi Paul !
I was about to go debug something else when I hit that with -rc3 (plus
the patch to fix the current bug.h breakage) on a 32-bit PowerMac G4 SMP
(2 CPUs): About 1mn pause at boot followed by a bunch of RCU stall
messages. Log below. Any idea where to start looking ?
pci 0002:20:0f.0: reg 30: [mem 0xf5100000-0xf51fffff pref]
PCI 0000:00 Cannot reserve Legacy IO [io 0x802000-0x802fff]
PCI 0001:10 Cannot reserve Legacy IO [io 0x0000-0x0fff]
pci_bus 0000:00: resource 4 [io 0x802000-0x1001fff]
pci_bus 0000:00: resource 5 [mem 0xf1000000-0xf1ffffff]
pci_bus 0000:00: resource 6 [mem 0x90000000-0x9fffffff]
pci_bus 0001:10: resource 4 [io 0x0000-0x7fffff]
pci_bus 0001:10: resource 5 [mem 0xf3000000-0xf3ffffff]
pci_bus 0001:10: resource 6 [mem 0x80000000-0x8fffffff]
pci_bus 0002:20: resource 4 [io 0xff7fe000-0xffffdfff]
pci_bus 0002:20: resource 5 [mem 0xf5000000-0xf5ffffff]
bio: create slab <bio-0> at 0
vgaarb: device added: PCI:0000:00:10.0,decodes=io+mem,owns=io+mem,locks=none
vgaarb: loaded
vgaarb: bridge control possible 0000:00:10.0
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Switching to clocksource timebase
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP: reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
pci 0001:10:18.0: enabling device (0000 -> 0002)
pci 0001:10:19.0: enabling device (0000 -> 0002)
PCI: CLS mismatch (32 != 1020), using 32 bytes
highmem bounce pool size: 64 pages
NFS: Registering the id_resolver key type
Key type id_resolver registered
msgmni has been set to 1500
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Using unsupported 1680x1050 ATY,BlueStone_A at 9c008000, depth=8, pitch=1792
Console: switching to colour frame buffer device 210x65
fb0: Open Firmware frame buffer device on /pci@f0000000/ATY,BlueStoneParent@10/ATY,BlueStone_A
Using unsupported 640x480 ATY,BlueStone_B at 99008000, depth=8, pitch=768
checking generic (9c008000 1cb600) vs hw (99008000 5a000)
fb1: Open Firmware frame buffer device on /pci@f0000000/ATY,BlueStoneParent@10/ATY,BlueStone_B
Generic RTC Driver v1.07
Generic non-volatile memory driver v1.1
brd: module loaded
loop: module loaded
MacIO PCI driver attached to Keylargo chipset
adb: starting probe task...
adb: finished probe task...
mesh: configured for synchronous 5 MB/s
st: Version 20101219, fixed bufsize 32768, s/g segs 256
pata-macio 0.0001f000:ata-4: Activating pata-macio chipset KeyLargo ATA-4, Apple bus ID 2
scsi0 : pata_macio
ata1: PATA max UDMA/66 irq 19
ata1.00: ATA-5: ST380021A, 5.05, max UDMA/100
ata1.00: 156301488 sectors, multi 16: LBA
ata1.01: ATA-5: ST380021A, 3.75, max UDMA/100
ata1.01: 156301488 sectors, multi 16: LBA
ata1.00: configured for UDMA/66
ata1.01: configured for UDMA/66
scsi 0:0:0:0: Direct-Access ATA ST380021A 5.05 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: Attached scsi generic sg0 type 0
sda: [mac] sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda12 sda13 sda14 sda15
sd 0:0:0:0: [sda] Attached SCSI disk
scsi 0:0:1:0: Direct-Access ATA ST380021A 3.75 PQ: 0 ANSI: 5
sd 0:0:1:0: [sdb] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB)
sd 0:0:1:0: [sdb] Write Protect is off
sd 0:0:1:0: Attached scsi generic sg1 type 0
sd 0:0:1:0: [sdb] Mode Sense: 00 3a 00 00
sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
INFO: rcu_sched self-detected stall on CPU { 0} (t=16163 jiffies)
Call Trace:
INFO: rcu_sched self-detected stall on CPU { 1} (t=16163 jiffies)
Call Trace:
[ef877d30] [c0008d04] show_stack+0x50/0x158 (unreliable)
[ef877d70] [c0097fe4] __rcu_pending+0x184/0x46c
[ef877da0] [c00991a0] rcu_check_callbacks+0x7c/0x168
[ef877dc0] [c0044a40] update_process_times+0x3c/0x70
[ef877de0] [c0083a3c] tick_sched_timer+0x88/0x100
[ef877e10] [c005b11c] __run_hrtimer.clone.29+0x54/0x104
[ef877e30] [c005bf44] hrtimer_interrupt+0x158/0x3f8
[ef877ea0] [c000b5c4] timer_interrupt+0x1cc/0x204
[ef877ed0] [c0011b88] ret_from_except+0x0/0x1c
--- Exception: 901 at cpu_idle+0xe4/0x188
LR = cpu_idle+0xc8/0x188
[ef877f90] [c00097e8] cpu_idle+0x60/0x188 (unreliable)
[ef877fc0] [c046531c] start_secondary+0x2c8/0x2cc
[ef877ff0] [00003278] 0x3278
[ef873b60] [c0008d04] show_stack+0x50/0x158 (unreliable)
[ef873ba0] [c0097fe4] __rcu_pending+0x184/0x46c
[ef873bd0] [c0099240] rcu_check_callbacks+0x11c/0x168
[ef873bf0] [c0044a40] update_process_times+0x3c/0x70
[ef873c10] [c0083a3c] tick_sched_timer+0x88/0x100
[ef873c40] [c005b11c] __run_hrtimer.clone.29+0x54/0x104
[ef873c60] [c005bf44] hrtimer_interrupt+0x158/0x3f8
[ef873cd0] [c000b5c4] timer_interrupt+0x1cc/0x204
[ef873d00] [c0011b88] ret_from_except+0x0/0x1c
--- Exception: 901 at wake_up_new_task+0x134/0x16c
LR = wake_up_new_task+0x134/0x16c
[ef873dc0] [c0065f08] wake_up_new_task+0xfc/0x16c (unreliable)
[ef873df0] [c0035530] do_fork+0xe8/0x2bc
[ef873e30] [c0008a4c] sys_clone+0x50/0x90
[ef873e50] [c00114b8] ret_from_syscall+0x0/0x40
--- Exception: c00 at kernel_thread+0x28/0x68
LR = __call_usermodehelper+0x40/0xdc
[ef873f10] [c005f5c8] async_run_entry_fn+0x128/0x1e4 (unreliable)
[ef873f20] [ef878c00] 0xef878c00
[ef873f40] [c004e668] process_one_work+0x150/0x3f0
[ef873f70] [c00514f0] worker_thread+0x18c/0x37c
[ef873fb0] [c00567bc] kthread+0x84/0x88
[ef873ff0] [c000f514] kernel_thread+0x4c/0x68
pata-macio 0.00020000:ata-3: Activating pata-macio chipset KeyLargo ATA-3, Apple bus ID 0
scsi1 : pata_macio
ata2: PATA max MWDMA2 irq 20
sdb: [mac] sdb1 sdb2 sdb3 sdb4 sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 sdb12 sdb13
sd 0:0:1:0: [sdb] Attached SCSI disk
ata2.00: ATAPI: PIONEER DVD-RW DVR-104, A227, max UDMA/33
ata2.00: configured for MWDMA2
scsi 1:0:0:0: CD-ROM PIONEER DVD-RW DVR-104 A227 PQ: 0 ANSI: 5
pata-macio 0.00021000:ata-3: Activating pata-macio chipset KeyLargo ATA-3, Apple bus ID 1
scsi2 : pata_macio
ata3: PATA max MWDMA2 irq 21
sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray
cdrom: Uniform CD-ROM driver Revision: 3.20
sr 1:0:0:0: Attached scsi CD-ROM sr0
pcnet32: pcnet32.c:v1.35 21.Apr.2008 tsbogend@alpha.franken.de
sr 1:0:0:0: Attached scsi generic sg2 type 5
sungem.c:v1.0 David S. Miller <davem@redhat.com>
gem 0002:20:0f.0: eth0: Sun GEM (PCI) 10/100/1000BaseT Ethernet 00:03:93:6f:04:b2
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd 0001:10:18.0: OHCI Host Controller
ohci_hcd 0001:10:18.0: new USB bus registered, assigned bus number 1
ohci_hcd 0001:10:18.0: irq 27, io mem 0x80081000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ohci_hcd 0001:10:19.0: OHCI Host Controller
ohci_hcd 0001:10:19.0: new USB bus registered, assigned bus number 2
ohci_hcd 0001:10:19.0: irq 28, io mem 0x80080000
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
mousedev: PS/2 mouse device common for all mice
usbcore: registered new interface driver appletouch
PowerMac i2c bus pmu 2 registered
i2c i2c-0: i2c-powermac: invalid reg on /pci@f2000000/mac-io@17/via-pmu@16000/rtc
i2c i2c-0: i2c-powermac: invalid reg on /pci@f2000000/mac-io@17/via-pmu@16000/power-mgt
PowerMac i2c bus pmu 1 registered
i2c i2c-1: i2c-powermac: invalid reg on /pci@f2000000/mac-io@17/via-pmu@16000/rtc
i2c i2c-1: i2c-powermac: invalid reg on /pci@f2000000/mac-io@17/via-pmu@16000/power-mgt
PowerMac i2c bus mac-io 0 registered
i2c i2c-2: i2c-powermac: invalid reg on /pci@f2000000/mac-io@17/i2c@18000/cereal
i2c i2c-2: i2c-powermac: invalid reg on /pci@f2000000/mac-io@17/i2c@18000/deq
i2c i2c-2: i2c-powermac: invalid reg on /pci@f2000000/mac-io@17/i2c@18000/i2c-modem
PowerMac i2c bus uni-n 1 registered
i2c i2c-3: i2c-powermac: invalid reg on /uni-n@f8000000/i2c@f8001000/cereal
PowerMac i2c bus uni-n 0 registered
i2c i2c-4: i2c-powermac: invalid reg on /uni-n@f8000000/i2c@f8001000/cereal
APM Battery Driver
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
oprofile: using ppc/7450 performance monitoring.
TCP: cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 17
NET: Registered protocol family 15
Key type dns_resolver registered
PM: Hibernation image not present or could not be loaded.
input: PMU as /devices/virtual/input/input0
kjournald starting. Commit interval 5 seconds
EXT3-fs (sda15): mounted filesystem with writeback data mode
VFS: Mounted root (ext3 filesystem) readonly on device 8:15.
usb 1-1: new full-speed USB device number 2 using ohci_hcd
devtmpfs: mounted
Freeing unused kernel memory: 240k freed
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 3 ports detected
usb 1-2: new full-speed USB device number 3 using ohci_hcd
hub 1-2:1.0: USB hub found
hub 1-2:1.0: 3 ports detected
usb 1-1.3: new full-speed USB device number 4 using ohci_hcd
input: Mitsumi Electric Apple Extended USB Keyboard as /devices/pci0001:10/0001:10:18.0/usb1/1-1/1-1.3/1-1.3:1.0/input/input1
hid-generic 0003:05AC:020B.0001: input: USB HID v1.10 Keyboard [Mitsumi Electric Apple Extended USB Keyboard] on usb-0001:10:18.0-1.3/input0
input: Mitsumi Electric Apple Extended USB Keyboard as /devices/pci0001:10/0001:10:18.0/usb1/1-1/1-1.3/1-1.3:1.1/input/input2
hid-generic 0003:05AC:020B.0002: input: USB HID v1.10 Device [Mitsumi Electric Apple Extended USB Keyboard] on usb-0001:10:18.0-1.3/input1
usb 1-2.3: new low-speed USB device number 5 using ohci_hcd
hid-generic 0003:05AC:9219.0003: claimed by neither input, hiddev nor hidraw
udevd[1209]: starting version 175
EXT3-fs (sda15): using internal journal
sungem_phy: PHY ID: 2060e1, addr: 0
gem 0002:20:0f.0: eth0: Found BCM5421 PHY
gem 0002:20:0f.0: eth0: Link is up at 100 Mbps, full-duplex
gem 0002:20:0f.0: eth0: Pause is enabled (rxfifo: 10240 off: 7168 on: 5632)
sshd (2042): /proc/2042/oom_adj is deprecated, please use /proc/2042/oom_score_adj instead.
^ permalink raw reply
* Re: Build regressions/improvements in v3.5-rc3
From: Andreas Schwab @ 2012-06-17 22:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linux MIPS Mailing List, Linux-sh list, linux-kernel,
Linuxppc-dev, Geert Uytterhoeven, Chris Zankel
In-Reply-To: <1339969995.9220.242.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Sun, 2012-06-17 at 21:56 +0200, Geert Uytterhoeven wrote:
>> Truckloads of powerpc "Unrecognized opcode" breakage, and
>
> Where ? The boot wrappers again ?
<http://permalink.gmane.org/gmane.linux.kernel/1312778>
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Build regressions/improvements in v3.5-rc3
From: Benjamin Herrenschmidt @ 2012-06-17 21:53 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linuxppc-dev, Linux-sh list, Linux MIPS Mailing List,
linux-kernel, Chris Zankel
In-Reply-To: <CAMuHMdVfLjgrtWoPpvbLf12+=ApE6W9dNcweqD-_2Benr-D7NQ@mail.gmail.com>
On Sun, 2012-06-17 at 21:56 +0200, Geert Uytterhoeven wrote:
> Truckloads of powerpc "Unrecognized opcode" breakage, and
Where ? The boot wrappers again ?
Cheers,
Ben.
^ permalink raw reply
* Re: Build regressions/improvements in v3.5-rc3
From: Geert Uytterhoeven @ 2012-06-17 19:56 UTC (permalink / raw)
To: linux-kernel
Cc: Linuxppc-dev, Chris Zankel, Linux-sh list,
Linux MIPS Mailing List
In-Reply-To: <1339962373-3224-1-git-send-email-geert@linux-m68k.org>
On Sun, Jun 17, 2012 at 9:46 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> JFYI, when comparing v3.5-rc3 to v3.5-rc2[3], the summaries are:
> =C2=A0- build errors: +235/-10
Truckloads of powerpc "Unrecognized opcode" breakage, and
+ arch/mips/include/asm/bitops.h: error: static declaration of 'fls'
follows non-static declaration: =3D> 615:50
+ include/asm-generic/bitops/fls64.h: error: static declaration of
'fls64' follows non-static declaration: =3D> 26:81, 18:81
+ include/linux/bitops.h: error: conflicting types for 'fls_long': =3D> =
160:55
various mips
+ drivers/edac/mpc85xx_edac.c: error: too few arguments to function
'edac_mc_alloc': =3D> 983:90
powerpc-randconfig
+ drivers/net/ethernet/dlink/de600.c: error: expected expression
before 'do': =3D> 146:2, 301:3, 210:3, 150:2, 468:2, 404:2, 208:3,
495:3, 328:2, 138:2, 499:2, 217:3, 417:2, 136:2, 300:3, 464:2, 501:2,
493:2, 206:2, 216:3, 254:4, 350:2, 196:3, 137:2, 405:2, 463:2
+ drivers/scsi/pcmcia/sym53c500_cs.c: error: expected expression
before 'do': =3D> 453:4, 434:4, 574:2, 371:2
+ drivers/scsi/qlogicfas408.c: error: expected expression before
'do': =3D> 234:2, 221:2, 312:3, 583:2, 535:2, 324:3, 85:2, 406:2,
316:5, 569:9, 89:3, 230:2, 546:2
+ drivers/staging/wlags49_h2/hcf.c: error: expected expression
before 'do': =3D> 3375:4, 3592:3, 4378:3, 1135:3, 1203:3, 3593:3,
4731:3, 3653:3, 704:4, 3802:3, 1150:2, 1209:2, 3645:10, 4178:2,
3699:5, 3007:5, 4033:2, 787:3, 2646:4, 1190:2, 3797:3, 717:3, 2630:3,
4732:3, 703:4, 3582:2, 751:5, 2629:3, 755:5, 3507:3, 1153:2, 750:5,
3057:4, 781:4, 2654:4, 3700:5
+ drivers/staging/wlags49_h25/../wlags49_h2/hcf.c: error: expected
expression before 'do': =3D> 3375:4, 3592:3, 4378:3, 1135:3, 1203:3,
3593:3, 4731:3, 3653:3, 704:4, 3802:3, 1150:2, 1209:2, 3645:10,
3699:5, 4033:2, 787:3, 2646:4, 1190:2, 717:3, 2630:3, 4732:3, 703:4,
3582:2, 751:5, 2629:3, 755:5, 3507:3, 1153:2, 750:5, 3057:4, 781:4,
2654:4, 3700:5
sh-allyesconfig/sh-allmodconfig
+ drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c: error: implicit
declaration of function 'pci_iomap'
[-Werror=3Dimplicit-function-declaration]: =3D> 90:3
+ drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c: error: implicit
declaration of function 'pci_iounmap'
[-Werror=3Dimplicit-function-declaration]: =3D> 142:2
xtensa
+ error: "__ashrdi3" [fs/ntfs/ntfs.ko] undefined!: =3D> N/A
+ error: "__lshrdi3" [fs/ntfs/ntfs.ko] undefined!: =3D> N/A
sh4/landisk_defconfig
+ error: "__ashrdi3" [fs/xfs/xfs.ko] undefined!: =3D> N/A
+ error: "__lshrdi3" [drivers/mtd/mtd.ko] undefined!: =3D> N/A
+ error: "__lshrdi3" [fs/xfs/xfs.ko] undefined!: =3D> N/A
sh4/titan_defconfig
+ error: No rule to make target include/config/auto.conf: =3D> N/A
x86_64-randconfig
+ kernel/sys.c: error: 'mmap_min_addr' undeclared (first use in this
function): =3D> 1864:34, 1864:2
+ security/security.c: error: 'BDI_CAP_EXEC_MAP' undeclared (first
use in this function): =3D> 688:16, 688:3
+ security/security.c: error: dereferencing pointer to incomplete
type: =3D> 687:36
sh-allyesconfig/sh-allmodconfig/sh-randconfig
Gr{oetje,eeting}s,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org
In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds
^ permalink raw reply
* Re: [RFC PATCH 09/10] POWERPC: smp: remove call to ipi_call_lock()/ipi_call_unlock()
From: Paul E. McKenney @ 2012-06-16 20:57 UTC (permalink / raw)
To: Peter Zijlstra
Cc: axboe, sshtylyov, nikunj, david.daney, linux-kernel, ralf, akpm,
Yong Zhang, Paul Mackerras, srivatsa.bhat, tglx, linuxppc-dev,
mingo
In-Reply-To: <1339867858.15222.12.camel@twins>
On Sat, Jun 16, 2012 at 07:30:58PM +0200, Peter Zijlstra wrote:
> On Sat, 2012-06-16 at 09:32 -0700, Paul E. McKenney wrote:
> > However, there is an effort to get rid of stop_machine() from the
> > CPU-down path... So something else will be needed.
>
> Elsewhere in this thread I mentioned we could do a synchronize_sched().
> I think that covers most of what stop-machine is doing these days.
Ah, apologies for the noise!
Thanx, Paul
^ permalink raw reply
* Re: [RFC PATCH 09/10] POWERPC: smp: remove call to ipi_call_lock()/ipi_call_unlock()
From: Peter Zijlstra @ 2012-06-16 17:30 UTC (permalink / raw)
To: paulmck
Cc: axboe, sshtylyov, nikunj, david.daney, linux-kernel, ralf, akpm,
Yong Zhang, Paul Mackerras, srivatsa.bhat, tglx, linuxppc-dev,
mingo
In-Reply-To: <20120616163219.GI2420@linux.vnet.ibm.com>
On Sat, 2012-06-16 at 09:32 -0700, Paul E. McKenney wrote:
> However, there is an effort to get rid of stop_machine() from the
> CPU-down path... So something else will be needed.=20
Elsewhere in this thread I mentioned we could do a synchronize_sched().
I think that covers most of what stop-machine is doing these days.
^ permalink raw reply
* Re: [RFC PATCH 09/10] POWERPC: smp: remove call to ipi_call_lock()/ipi_call_unlock()
From: Paul E. McKenney @ 2012-06-16 16:32 UTC (permalink / raw)
To: Yong Zhang
Cc: axboe, nikunj, sshtylyov, david.daney, peterz, linux-kernel, ralf,
akpm, Paul Mackerras, srivatsa.bhat, tglx, linuxppc-dev, mingo
In-Reply-To: <1338275765-3217-10-git-send-email-yong.zhang0@gmail.com>
On Tue, May 29, 2012 at 03:16:04PM +0800, Yong Zhang wrote:
> From: Yong Zhang <yong.zhang@windriver.com>
>
> 1) call_function.lock used in smp_call_function_many() is just to protect
> call_function.queue and &data->refs, cpu_online_mask is outside of the
> lock. And it's not necessary to protect cpu_online_mask,
> because data->cpumask is pre-calculate and even if a cpu is brougt up
> when calling arch_send_call_function_ipi_mask(), it's harmless because
> validation test in generic_smp_call_function_interrupt() will take care
> of it.
>
> 2) For cpu down issue, stop_machine() will guarantee that no concurrent
> smp_call_fuction() is processing.
However, there is an effort to get rid of stop_machine() from the
CPU-down path... So something else will be needed.
Thanx, Paul
> Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> ---
> arch/powerpc/kernel/smp.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index e4cb343..e1417c4 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -571,7 +571,6 @@ void __devinit start_secondary(void *unused)
> if (system_state == SYSTEM_RUNNING)
> vdso_data->processorCount++;
> #endif
> - ipi_call_lock();
> notify_cpu_starting(cpu);
> set_cpu_online(cpu, true);
> /* Update sibling maps */
> @@ -601,7 +600,6 @@ void __devinit start_secondary(void *unused)
> of_node_put(np);
> }
> of_node_put(l2_cache);
> - ipi_call_unlock();
>
> local_irq_enable();
>
> --
> 1.7.5.4
>
^ permalink raw reply
* [PATCH] Disable /dev/port interface on powerpc systems
From: Haren Myneni @ 2012-06-16 6:42 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, anton
Michael, Thanks for the comment. Here it is the updated patch which
fixes x86 build.
Thanks
Haren
Some power systems do not have legacy ISA devices. So, /dev/port is not
a valid interface on these systems. User level tools such as kbdrate is
trying to access the device using this interface which is causing the
system crash.
This patch will fix this issue by not creating this interface on these
powerpc systems.
Signed-off-by: Haren Myneni <haren@us.ibm.com>
diff -Naurp linux.orig/arch/powerpc/include/asm/io.h linux/arch/powerpc/include/asm/io.h
--- linux.orig/arch/powerpc/include/asm/io.h 2012-06-16 01:15:11.000000000 -0500
+++ linux/arch/powerpc/include/asm/io.h 2012-06-16 01:15:20.000000000 -0500
@@ -20,6 +20,14 @@ extern int check_legacy_ioport(unsigned
#define _PNPWRP 0xa79
#define PNPBIOS_BASE 0xf000
+#ifdef CONFIG_PPC64
+extern struct pci_dev *isa_bridge_pcidev;
+/*
+ * has legacy ISA devices ?
+ */
+#define arch_has_dev_port() (isa_bridge_pcidev != NULL)
+#endif
+
#include <linux/device.h>
#include <linux/io.h>
diff -Naurp linux.orig/drivers/char/mem.c linux/drivers/char/mem.c
--- linux.orig/drivers/char/mem.c 2012-06-16 01:15:42.000000000 -0500
+++ linux/drivers/char/mem.c 2012-06-16 01:15:53.000000000 -0500
@@ -27,14 +27,16 @@
#include <linux/splice.h>
#include <linux/pfn.h>
#include <linux/export.h>
+#include <linux/io.h>
#include <asm/uaccess.h>
-#include <asm/io.h>
#ifdef CONFIG_IA64
# include <linux/efi.h>
#endif
+#define DEVPORT_MINOR 4
+
static inline unsigned long size_inside_page(unsigned long start,
unsigned long size)
{
@@ -894,6 +896,13 @@ static int __init chr_dev_init(void)
for (minor = 1; minor < ARRAY_SIZE(devlist); minor++) {
if (!devlist[minor].name)
continue;
+
+ /*
+ * Create /dev/port?
+ */
+ if ((minor == DEVPORT_MINOR) && !arch_has_dev_port())
+ continue;
+
device_create(mem_class, NULL, MKDEV(MEM_MAJOR, minor),
NULL, devlist[minor].name);
}
diff -Naurp linux.orig/include/linux/io.h linux/include/linux/io.h
--- linux.orig/include/linux/io.h 2012-06-16 01:16:13.000000000 -0500
+++ linux/include/linux/io.h 2012-06-16 01:16:24.000000000 -0500
@@ -67,4 +67,13 @@ int check_signature(const volatile void
const unsigned char *signature, int length);
void devm_ioremap_release(struct device *dev, void *res);
+/*
+ * Some systems do not have legacy ISA devices.
+ * /dev/port is not a valid interface on these systems.
+ * So for those archs, <asm/io.h> should define the following symbol.
+ */
+#ifndef arch_has_dev_port
+#define arch_has_dev_port() (1)
+#endif
+
#endif /* _LINUX_IO_H */
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox