* 答复: [RFC PATCH] powerpc/fsl: add timer wakeup source
From: Wang Dongsheng-B40534 @ 2012-10-09 13:56 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: linux-pm@vger.kernel.org, Wang Dongsheng,
linuxppc-dev@lists.ozlabs.org list, Li Yang-R58472
In-Reply-To: <1349729705.3721.8@snotra>
DQo+ID4gPiA+IEknbSBwcmV0dHkgc3VyZSAvcHJvYy8gaXMgTk9UIHdoZXJlIHdlIHdhbnQgdGhp
cyBleHBvc2VkLg0KPiA+ID4NCj4gPiA+IFNob3VsZCBwcm9iYWJseSBnbyB1bmRlciB0aGUgc3lz
ZnMgZGlyZWN0b3J5IG9mIHRoZSBtcGljIGRldmljZS4gIE9yDQo+ID4gPiBiZXR0ZXIsIG1ha2Ug
YSBnZW5lcmljIGludGVyZmFjZSBmb3IgdGltZXItYmFzZWQgc3VzcGVuZCB3YWtldXAgKGlmDQo+
ID4gdGhlcmUNCj4gPiA+IGlzbid0IG9uZSBhbHJlYWR5KS4gIFRoaXMgY3VycmVudCBhcHByb2Fj
aCBzaXRzIGluIGFuIHVucGxlYXNhbnQNCj4gbWlkZGxlDQo+ID4gPiBncm91bmQgYmV0d2VlbiBn
ZW5lcmljIGFuZCBkZXZpY2Utc3BlY2lmaWMuDQo+ID4gPg0KPiA+IC9zeXMvcG93ZXIvd2FrZXVw
X3RpbWVyX3NlY29uZHMgaG93IGFib3V0IHRoaXM/DQo+ID4gSSB0aGluayBpdCBpcyBhIGZyZWVz
Y2FsZSBnZW5lcmljIGludGVyZmFjZSwgdGhpcyBpbnRlcmZhY2UgY29udHJvbCBieQ0KPiA+IEZT
TF9TT0MgJiYgU1VTUEVORC4NCg0KPiBUaGVyZSdzIG5vIHN1Y2ggdGhpbmcgYXMgYSAiRnJlZXNj
YWxlIGdlbmVyaWMgaW50ZXJmYWNlIi4gIExpbnV4IEFQSXMNCj4gYXJlIG5vdCBvcmdhbml6ZWQg
YnkgaGFyZHdhcmUgdmVuZG9yLiAgRWl0aGVyIG1ha2UgYSB0cnVseSBnZW5lcmljDQo+IGludGVy
ZmFjZSwgcmV1c2UgYW4gZXhpc3Rpbmcgb25lLCBvciBkbyBzb21ldGhpbmcgdGhhdCBpcyBhdHRh
Y2hlZCB0bw0KPiB0aGUgc3BlY2lmaWMgZHJpdmVyLg0KVGhhbmtzLCBJIHRoaW5rIGkgY2FuIGNo
YW5nZSBtcGljIHRpbWVyIHJlZ2lzdHJhdGlvbiwgaSB3aWxsIHVzZSBwbGF0Zm9ybV9kcml2ZXJf
cmVnaXN0ZXIuDQpJIHdpbGwgbWVyZ2UgIm1waWMgdGltZXIiIGFuZCAidGltZXIgd2FrZXVwIi4g
SW4gIm1waWMgdGltZXIiIHRoZSB3YWtldXAgZnVuY3Rpb24NCmNvbnRyb2xzIGJ5IFNVU1BFTkQu
IFRoZSBzeXMgcGF0aCBpcyAiL3N5cy9kZXZpY2VzL3NvYzg1NzIuNC9mZmU0MTEwMC50aW1lci93
YWtldXBfc2Vjb25kcyIuDQpkbyB5b3UgaGF2ZSBhbnkgc3VnZ2VzdGlvbnMgZm9yIHRoaXM/IG9y
IGhhdmUgYSBiZXR0ZXIgaWRlYSBhYm91dCB0aGUgc3lzIHBhdGg/DQoNCj4gPiA+IFVzZSBkZXBl
bmRzIHJhdGhlciB0aGFuIGlmL2Vsc2UuICBXaHkgZG8geW91IG5lZWQgRlNMX1dBS0VVUF9TT1VS
Q0U/DQo+ID4gPg0KPiA+IEl0IGxpc3RzIGFsbCB3YWtlIHVwIHNvdXJjZS4gSWYgbGF0ZXIgaGF2
ZSB3YWtldXAgc291cmNlIGNhbiBiZQ0KPiA+IGltcHJvdmVkIGJ5DQo+ID4gaXQgdG8gY29udHJv
bC4gQnV0dG9ucyBldmVudCB3YWtldXAgc291cmNlIHdpbGwgYmUgYWRkZWQgYWZ0ZXIgdGhlDQo+
ID4gdGltZXIuDQoNCj4gSXQgZG9lcyBub3QgbGlzdCBhbGwgd2FrZSB1cCBzb3VyY2VzIC0tIHRo
ZXJlJ3MgYWxzbyBldGhlcm5ldCwgVVNCLCBldGMuDQpmaW5lLCBjaGFuZ2UgdG8gZGVwZW5kcy4g
dGhhbmtzLg0KDQo+ID4gPg0KPiA+ID4gSWYgdGhlIG5ldyB0aW1lIGlzIHplcm8sIGNvbnNpZGVy
IHRoYXQgYSBjYW5jZWxsYXRpb24gb2YgdGhlIHRpbWVyDQo+ID4gYW5kDQo+ID4gPiBkb24ndCBy
ZXF1ZXN0IGEgbmV3IG9uZSBvciByZXR1cm4gLUVJTlZBTC4NCj4gPiA+DQo+ID4gVGhhbmtzLCBJ
IHRoaW5rIGkgc2hvdWxkIGFkZCBjb21tZW50cy4gTGV0IHRoaXMgcGF0Y2ggZWFzeSB0byByZWFk
Lg0KPiA+IEhlcmUgaXMgZ2V0IGEgbmV3IHRpbWVyLg0KPiA+IElmIHRoZSBuZXcgdGltZSBpcyB6
ZXJvLCBjb25zaWRlciB0aGF0IGhhcyBiZWVuIGNoZWNrZWQuDQo+ID4NCj4gPiBpZiAoIXRpbWUu
dHZfc2VjKSB7Li4ufSB0aGlzIGlzIGNoZWNrIHplcm8uDQo+ID4gVGhlICJtcGljX3JlcXVlc3Rf
dGltZXIiIGJlZm9yZSB0aGlzIGNvZGUuDQoNCj4gQWgsIEkgc2VlLiAgV291bGRuJ3QgaXQgYmUg
c2ltcGxlciB0byByZW1vdmUgdGhhdCBibG9jayBhbmQganVzdCB0ZXN0DQo+IHRpbWUudHZfc2Vj
IHdoZW4gcmVxdWVzdGluZyB0aGUgbmV3IHRpbWVyPw0KWWVzLCB3YWtlIHVwIGZ1bmN0aW9uIG9u
bHkgbmVlZCBzZWNvbmRzIGxldmVsLCBhbmQgaXQncyBqdXN0IGhvbGQgYSB0aW1lci4NCmVjaG8g
emVybyB0byBjYW5jZWwsIGFuZCBlY2hvIGEgbmV3IHRpbWUgdG8gdXBkYXRlIHRoZSB0aW1lciB0
aW1lLg==
^ permalink raw reply
* Re: gianfar driver crash on P1020
From: Avi Tsarfati @ 2012-10-09 12:22 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 494 bytes --]
Hi,
I have the same problem as you do.
Have you found the CPU stuck reason (or fix) in P1020RDB board ?
Thanks,
Avi Tsarfati.
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(187).
************************************************************************************
[-- Attachment #2: Type: text/html, Size: 2608 bytes --]
^ permalink raw reply
* [m68k,powerpc,dma,ethernet,freescale RFA] Coldfire m54xx FEC ethernet driver
From: Philippe De Muyter @ 2012-10-09 9:07 UTC (permalink / raw)
To: Greg Ungerer
Cc: uClinux development list, netdev, linux-kernel, linux-m68k,
stany.marcel, linuxppc-dev
In-Reply-To: <5073C05C.2080809@snapgear.com>
[CCing lkml, linux-ppc, netdev, linux-m68k]
Hello kernel sources architects
I have a working driver for the m54xx FEC ethernet driver that I
would like to integrate in the kernel tree. Problems are that
- this driver needs an associated DMA driver (provided by FreeScale)
wich is not dma-engine enabled
- they're are already many fec drivers in the kernel tree, and
at least one, fec_mpc52xx.c, seems to be very similar (information
below), to the one for the mcf54xx, except it uses a differently
named associated DMA driver (BestComm/SmartDma/SDMA) which is also
not dma-engine enabled, and even kept hidden in /arch/powerpc where
it is inaccessible when compiling for m68k. The underlying DMA part
from Freescale however seems similar to the one used in the
m54xx. (again, see information below)
So, now I am lost, what should I do ?
The current state of my patches
[http://mailman.uclinux.org/pipermail/uclinux-dev/2012-September/052147.html]
is pushing the freescale provided MCD_DMA dma driver to /drivers/dma,
without adding the dma-engine compatibility layer, and adding the specific
fec_m54xx ethernet driver to /drivers/net/ethernet/freescale
Best regards
Philippe
On Tue, Oct 09, 2012 at 04:12:44PM +1000, Greg Ungerer wrote:
> Hi Philippe,
>
> On 05/10/12 01:03, Philippe De Muyter wrote:
>> On Thu, Oct 04, 2012 at 04:56:01PM +0200, Philippe De Muyter wrote:
>>> On Thu, Oct 04, 2012 at 11:33:32PM +1000, Greg Ungerer wrote:
>>>>
>>>> My biggest concern is the amount of MCD/DMA support code. And it is
>>>> all done quite differently to everything else in the kernel. We may
>>>> get a bit of push back from kernel folk who look after DMA.
>>>
>>> Actually, there is already a similar code in arch/powerpc/sysdev/bestcomm
>>> (also from freescale, maybe an identical part, but I did not find any
>>> usable doc), but the powerpc folks kept that hidden in the arch/powerpc
>>> tree, instead of installing it in drivers/dma.
>>
>> The MCD DMA or DMA FEC code from freescale has a comment implying that
>> this
>> was first used in the MPC8220 part. And Montavista has a MPC8220 port,
>> but
>> I did not find it, so I do not know where they installed the MCD DMA
>> driver.
>
> Ok, looks like there is a bit a variance in all this.
I also began to read the mpc5200 user's guide parts about the fec and
BestComm/SmartDma/SDMA (not sure which one is the official FreeScale name)
and they look very similar, but not identical, to their m54xx counterparts.
It seems possible to make the fec_mpc52xx.c driver work for the m54xx
but that needs at least:
- moving some files or part of them from /arch/powerpc/sysdev and
/arch/powerpc/include/asm to /drivers/dma and /include/linux,
- renaming the fec_mpc52xx files to a more sensible name,
- providing out_be32 and in_be32 in /arch/m68k/include/asm/io.h,
- and then unifying the interface to BestComm/SmartDma/SDMA and MCD_DMA
in mcf_52xx.c.
An additional problem is that the freescale docs for powerpcs and for
coldfires do not use the same mnemonics for the same registers.
e.g. FEC registers
offset MPC5200 MCF5484
====== ======= =======
000 FEC_ID n/a
004 IEVENT EIR
008 IMASK EIMR
010 R_DES_ACTIVE n/a
014 X_DES_ACTIVE n/a
024 ECNTRL ECR
040 MII_DATA MDATA
044 MII_SPEED MSCR
064 MIB_CONTROL MIBC
084 R_CNTRL RCR
088 R_HASH RHR
0C4 X_CNTRL TCR
0E4 PADDR1 PALR
0E8 PADDR2 PAHR
0EC OP_PAUSE OPD
118 IADDR1 IAUR
11C IADDR1 IALR
120 GADDR1 GAUR
124 GADDR2 GALR
144 X_WMRK FECTFWR
184 RFIFO_DATA FECRFDR
188 RFIFO_STATUS FECRFSR
18C RFIFO_CONTROL FECRFCR
190 RFIFO_LRF_PTR FECRLRFP
194 RFIFO_LWF_PTR FECRLWFP
198 RFIFO_ALARM FECRFAR
19C RFIFO_RDPTR FECRFRP
1A0 RFIFO_WRPTR FECRFWP
1A4 TFIFO_DATA FECTFDR
1A8 TFIFO_STATUS FECTFSR
1AC TFIFO_CONTROL FECTFCR
1B0 TFIFO_LRF_PTR FECTLRFP
1B4 TFIFO_LWF_PTR FECTLWFP
1B8 TFIFO_ALARM FECTFAR
1BC TFIFO_RDPTR FECTFRP
1C0 TFIFO_WRPTR FECTFWP
1C4 RESET_CNTRL FECFRST
1C8 XMIT_FSM FECCTCWR
> Probably the best thing to do is post the patches on the linux kernel
> mailing list then, asking for direction on a dma driver.
>
> I have no problem with it going into the arch/m68k area. So that is
> always an option.
For the dma engines, the similarity is also obvious. For example, find
below side by side mpc52xx and m54xx definitions for the
main DMA registers :
from mpc52xx.h from MCD_dma.h
/* SDMA */ /* MCD_DMA */
struct mpc52xx_sdma { struct dmaRegs {
u32 taskBar; /* 0x00 */ u32 taskbar;
u32 currentPointer; /* 0x04 */ u32 currPtr;
u32 endPointer; /* 0x08 */ u32 endPtr;
u32 variablePointer; /* 0x0c */ u32 varTablePtr;
u8 IntVect1; /* 0x10 */ u16 dma_rsvd0;
u8 IntVect2; /* 0x11 */
u16 PtdCntrl; /* 0x12 */ u16 ptdControl;
u32 IntPend; /* 0x14 */ u32 intPending;
u32 IntMask; /* 0x18 */ u32 intMask;
u16 tcr[16]; /* 0x1c .. 0x3a */ u16 taskControl[16];
u8 ipr[32]; /* 0x3c .. 0x5b */ u8 priority[32];
u32 cReqSelect; /* 0x5c */ u32 initiatorMux;
u32 task_size0; /* 0x60 */ u32 taskSize0;
u32 task_size1; /* 0x64 */ u32 taskSize1;
u32 MDEDebug; /* 0x68 */ u32 dma_rsvd1;
u32 ADSDebug; /* 0x6c */ u32 dma_rsvd2;
u32 Value1; /* 0x70 */ u32 debugComp1;
u32 Value2; /* 0x74 */ u32 debugComp2;
u32 Control; /* 0x78 */ u32 debugControl;
u32 Status; /* 0x7c */ u32 debugStatus;
u32 PTDDebug; /* 0x80 */ u32 ptdDebug;
}; };
^ permalink raw reply
* [GIT PULL] Disintegrate UAPI for powerpc [ver #2]
From: David Howells @ 2012-10-09 9:15 UTC (permalink / raw)
To: benh; +Cc: dhowells, linuxppc-dev, linux-kernel
Can you merge the following branch into the powerpc tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
Now that the fixups and the asm-generic chunk have been merged, I've
regenerated the patches to get rid of those dependencies and to take account of
any changes made so far in the merge window. If you have already pulled the
older version of the branch aimed at you, then please feel free to ignore this
request.
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-powerpc-20121009
for you to fetch changes up to c3617f72036c909e1f6086b5b9e364e0ef90a6da:
UAPI: (Scripted) Disintegrate arch/powerpc/include/asm (2012-10-09 09:47:26 +0100)
----------------------------------------------------------------
UAPI Disintegration 2012-10-09
----------------------------------------------------------------
David Howells (1):
UAPI: (Scripted) Disintegrate arch/powerpc/include/asm
arch/powerpc/include/asm/Kbuild | 35 --
arch/powerpc/include/asm/bootx.h | 123 +------
arch/powerpc/include/asm/cputable.h | 35 +-
arch/powerpc/include/asm/elf.h | 311 +-----------------
arch/powerpc/include/asm/kvm_para.h | 70 +---
arch/powerpc/include/asm/mman.h | 27 +-
arch/powerpc/include/asm/nvram.h | 55 +---
arch/powerpc/include/asm/ptrace.h | 242 +-------------
arch/powerpc/include/asm/signal.h | 143 +-------
arch/powerpc/include/asm/spu_info.h | 29 +-
arch/powerpc/include/asm/swab.h | 15 +-
arch/powerpc/include/asm/termios.h | 69 +---
arch/powerpc/include/asm/types.h | 30 +-
arch/powerpc/include/asm/unistd.h | 374 +--------------------
arch/powerpc/include/uapi/asm/Kbuild | 41 +++
arch/powerpc/include/{ => uapi}/asm/auxvec.h | 0
arch/powerpc/include/{ => uapi}/asm/bitsperlong.h | 0
arch/powerpc/include/uapi/asm/bootx.h | 132 ++++++++
arch/powerpc/include/{ => uapi}/asm/byteorder.h | 0
arch/powerpc/include/uapi/asm/cputable.h | 36 ++
arch/powerpc/include/uapi/asm/elf.h | 307 +++++++++++++++++
arch/powerpc/include/{ => uapi}/asm/errno.h | 0
arch/powerpc/include/{ => uapi}/asm/fcntl.h | 0
arch/powerpc/include/{ => uapi}/asm/ioctl.h | 0
arch/powerpc/include/{ => uapi}/asm/ioctls.h | 0
arch/powerpc/include/{ => uapi}/asm/ipcbuf.h | 0
arch/powerpc/include/{ => uapi}/asm/kvm.h | 0
arch/powerpc/include/uapi/asm/kvm_para.h | 90 +++++
arch/powerpc/include/{ => uapi}/asm/linkage.h | 0
arch/powerpc/include/uapi/asm/mman.h | 31 ++
arch/powerpc/include/{ => uapi}/asm/msgbuf.h | 0
arch/powerpc/include/uapi/asm/nvram.h | 62 ++++
arch/powerpc/include/{ => uapi}/asm/param.h | 0
arch/powerpc/include/{ => uapi}/asm/poll.h | 0
arch/powerpc/include/{ => uapi}/asm/posix_types.h | 0
arch/powerpc/include/{ => uapi}/asm/ps3fb.h | 0
arch/powerpc/include/uapi/asm/ptrace.h | 259 +++++++++++++++
arch/powerpc/include/{ => uapi}/asm/resource.h | 0
arch/powerpc/include/{ => uapi}/asm/seccomp.h | 0
arch/powerpc/include/{ => uapi}/asm/sembuf.h | 0
arch/powerpc/include/{ => uapi}/asm/setup.h | 0
arch/powerpc/include/{ => uapi}/asm/shmbuf.h | 0
arch/powerpc/include/{ => uapi}/asm/sigcontext.h | 0
arch/powerpc/include/{ => uapi}/asm/siginfo.h | 0
arch/powerpc/include/uapi/asm/signal.h | 145 +++++++++
arch/powerpc/include/{ => uapi}/asm/socket.h | 0
arch/powerpc/include/{ => uapi}/asm/sockios.h | 0
arch/powerpc/include/uapi/asm/spu_info.h | 53 +++
arch/powerpc/include/{ => uapi}/asm/stat.h | 0
arch/powerpc/include/{ => uapi}/asm/statfs.h | 0
arch/powerpc/include/uapi/asm/swab.h | 23 ++
arch/powerpc/include/{ => uapi}/asm/termbits.h | 0
arch/powerpc/include/uapi/asm/termios.h | 76 +++++
arch/powerpc/include/uapi/asm/types.h | 40 +++
arch/powerpc/include/{ => uapi}/asm/ucontext.h | 0
arch/powerpc/include/uapi/asm/unistd.h | 380 ++++++++++++++++++++++
56 files changed, 1705 insertions(+), 1528 deletions(-)
rename arch/powerpc/include/{ => uapi}/asm/auxvec.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/bitsperlong.h (100%)
create mode 100644 arch/powerpc/include/uapi/asm/bootx.h
rename arch/powerpc/include/{ => uapi}/asm/byteorder.h (100%)
create mode 100644 arch/powerpc/include/uapi/asm/cputable.h
create mode 100644 arch/powerpc/include/uapi/asm/elf.h
rename arch/powerpc/include/{ => uapi}/asm/errno.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/fcntl.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/ioctl.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/ioctls.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/ipcbuf.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/kvm.h (100%)
create mode 100644 arch/powerpc/include/uapi/asm/kvm_para.h
rename arch/powerpc/include/{ => uapi}/asm/linkage.h (100%)
create mode 100644 arch/powerpc/include/uapi/asm/mman.h
rename arch/powerpc/include/{ => uapi}/asm/msgbuf.h (100%)
create mode 100644 arch/powerpc/include/uapi/asm/nvram.h
rename arch/powerpc/include/{ => uapi}/asm/param.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/poll.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/posix_types.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/ps3fb.h (100%)
create mode 100644 arch/powerpc/include/uapi/asm/ptrace.h
rename arch/powerpc/include/{ => uapi}/asm/resource.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/seccomp.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/sembuf.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/setup.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/shmbuf.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/sigcontext.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/siginfo.h (100%)
create mode 100644 arch/powerpc/include/uapi/asm/signal.h
rename arch/powerpc/include/{ => uapi}/asm/socket.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/sockios.h (100%)
create mode 100644 arch/powerpc/include/uapi/asm/spu_info.h
rename arch/powerpc/include/{ => uapi}/asm/stat.h (100%)
rename arch/powerpc/include/{ => uapi}/asm/statfs.h (100%)
create mode 100644 arch/powerpc/include/uapi/asm/swab.h
rename arch/powerpc/include/{ => uapi}/asm/termbits.h (100%)
create mode 100644 arch/powerpc/include/uapi/asm/termios.h
create mode 100644 arch/powerpc/include/uapi/asm/types.h
rename arch/powerpc/include/{ => uapi}/asm/ucontext.h (100%)
create mode 100644 arch/powerpc/include/uapi/asm/unistd.h
.
^ permalink raw reply
* Re: [PATCH 8/10] memory-hotplug : remove page table of x86_64 architecture
From: wujianguo @ 2012-10-09 8:26 UTC (permalink / raw)
To: Yasuaki Ishimatsu
Cc: linux-s390, jiang.liu, linux-ia64, wency, len.brown, linux-acpi,
linux-sh, wujianguo, x86, linux-kernel, cmetcalf, linux-mm,
minchan.kim, kosaki.motohiro, rientjes, sparclinux, qiuxishi, cl,
linuxppc-dev, akpm, liuj97
In-Reply-To: <506E4799.30407@jp.fujitsu.com>
Hi Congyang,
I think we should also free pages which are used by page tables after removing
page tables of the memory.
From: Jianguo Wu <wujianguo@huawei.com>
Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
---
arch/x86/mm/init_64.c | 110 +++++++++++++++++++++++++++++++++++++++---------
1 files changed, 89 insertions(+), 21 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 5596dfa..81f9c3b 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -675,6 +675,74 @@ int arch_add_memory(int nid, u64 start, u64 size)
}
EXPORT_SYMBOL_GPL(arch_add_memory);
+static inline void free_pagetable(struct page *page)
+{
+ struct zone *zone;
+
+ __ClearPageReserved(page);
+ __free_page(page);
+
+ zone = page_zone(page);
+ zone_span_writelock(zone);
+ zone->present_pages++;
+ zone_span_writeunlock(zone);
+ totalram_pages++;
+}
+
+static void free_pte_table(pte_t *pte_start, pmd_t *pmd)
+{
+ pte_t *pte;
+ int i;
+
+ for (i = 0; i < PTRS_PER_PTE; i++) {
+ pte = pte_start + i;
+ if (pte_val(*pte))
+ break;
+ }
+
+ /* free a pte talbe */
+ if (i == PTRS_PER_PTE) {
+ free_pagetable(pmd_page(*pmd));
+ pmd_clear(pmd);
+ }
+}
+
+static void free_pmd_table(pmd_t *pmd_start, pud_t *pud)
+{
+ pmd_t *pmd;
+ int i;
+
+ for (i = 0; i < PTRS_PER_PMD; i++) {
+ pmd = pmd_start + i;
+ if (pmd_val(*pmd))
+ break;
+ }
+
+ /* free a pmd talbe */
+ if (i == PTRS_PER_PMD) {
+ free_pagetable(pud_page(*pud));
+ pud_clear(pud);
+ }
+}
+
+static void free_pud_table(pud_t *pud_start, pgd_t *pgd)
+{
+ pud_t *pud;
+ int i;
+
+ for (i = 0; i < PTRS_PER_PUD; i++) {
+ pud = pud_start + i;
+ if (pud_val(*pud))
+ break;
+ }
+
+ /* free a pud table */
+ if (i == PTRS_PER_PUD) {
+ free_pagetable(pgd_page(*pgd));
+ pgd_clear(pgd);
+ }
+}
+
static void __meminit
phys_pte_remove(pte_t *pte_page, unsigned long addr, unsigned long end)
{
@@ -704,21 +772,19 @@ phys_pmd_remove(pmd_t *pmd_page, unsigned long addr, unsigned long end)
unsigned long pages = 0, next;
int i = pmd_index(addr);
- for (; i < PTRS_PER_PMD; i++, addr = next) {
+ for (; i < PTRS_PER_PMD && addr < end; i++, addr = next) {
unsigned long pte_phys;
pmd_t *pmd = pmd_page + pmd_index(addr);
pte_t *pte;
- if (addr >= end)
- break;
-
- next = (addr & PMD_MASK) + PMD_SIZE;
+ next = pmd_addr_end(addr, end);
if (!pmd_present(*pmd))
continue;
if (pmd_large(*pmd)) {
- if ((addr & ~PMD_MASK) == 0 && next <= end) {
+ if (IS_ALIGNED(addr, PMD_SIZE) &&
+ IS_ALIGNED(next, PMD_SIZE)) {
set_pmd(pmd, __pmd(0));
pages++;
continue;
@@ -729,7 +795,8 @@ phys_pmd_remove(pmd_t *pmd_page, unsigned long addr, unsigned long end)
* so split 2M page to 4K page.
*/
pte = alloc_low_page(&pte_phys);
- __split_large_page((pte_t *)pmd, addr, pte);
+ __split_large_page((pte_t *)pmd,
+ (unsigned long)__va(addr), pte);
spin_lock(&init_mm.page_table_lock);
pmd_populate_kernel(&init_mm, pmd, __va(pte_phys));
@@ -738,7 +805,8 @@ phys_pmd_remove(pmd_t *pmd_page, unsigned long addr, unsigned long end)
spin_lock(&init_mm.page_table_lock);
pte = map_low_page((pte_t *)pmd_page_vaddr(*pmd));
- phys_pte_remove(pte, addr, end);
+ phys_pte_remove(pte, addr, next);
+ free_pte_table(pte, pmd);
unmap_low_page(pte);
spin_unlock(&init_mm.page_table_lock);
}
@@ -751,21 +819,19 @@ phys_pud_remove(pud_t *pud_page, unsigned long addr, unsigned long end)
unsigned long pages = 0, next;
int i = pud_index(addr);
- for (; i < PTRS_PER_PUD; i++, addr = next) {
+ for (; i < PTRS_PER_PUD && addr < end; i++, addr = next) {
unsigned long pmd_phys;
pud_t *pud = pud_page + pud_index(addr);
pmd_t *pmd;
- if (addr >= end)
- break;
-
- next = (addr & PUD_MASK) + PUD_SIZE;
+ next = pud_addr_end(addr, end);
if (!pud_present(*pud))
continue;
if (pud_large(*pud)) {
- if ((addr & ~PUD_MASK) == 0 && next <= end) {
+ if (IS_ALIGNED(addr, PUD_SIZE) &&
+ IS_ALIGNED(next, PUD_SIZE)) {
set_pud(pud, __pud(0));
pages++;
continue;
@@ -776,15 +842,18 @@ phys_pud_remove(pud_t *pud_page, unsigned long addr, unsigned long end)
* so split 1G page to 2M page.
*/
pmd = alloc_low_page(&pmd_phys);
- __split_large_page((pte_t *)pud, addr, (pte_t *)pmd);
+ __split_large_page((pte_t *)pud,
+ (unsigned long)__va(addr),
+ (pte_t *)pmd);
spin_lock(&init_mm.page_table_lock);
pud_populate(&init_mm, pud, __va(pmd_phys));
spin_unlock(&init_mm.page_table_lock);
}
- pmd = map_low_page(pmd_offset(pud, 0));
- phys_pmd_remove(pmd, addr, end);
+ pmd = map_low_page((pmd_t *)pud_page_vaddr(*pud));
+ phys_pmd_remove(pmd, addr, next);
+ free_pmd_table(pmd, pud);
unmap_low_page(pmd);
__flush_tlb_all();
}
@@ -805,15 +874,14 @@ kernel_physical_mapping_remove(unsigned long start, unsigned long end)
pgd_t *pgd = pgd_offset_k(start);
pud_t *pud;
- next = (start + PGDIR_SIZE) & PGDIR_MASK;
- if (next > end)
- next = end;
+ next = pgd_addr_end(start, end);
if (!pgd_present(*pgd))
continue;
pud = map_low_page((pud_t *)pgd_page_vaddr(*pgd));
- phys_pud_remove(pud, __pa(start), __pa(end));
+ phys_pud_remove(pud, __pa(start), __pa(next));
+ free_pud_table(pud, pgd);
unmap_low_page(pud);
}
-- 1.7.6.1 .
On 2012-10-5 10:36, Yasuaki Ishimatsu wrote:
> From: Wen Congyang <wency@cn.fujitsu.com>
>
> For hot removing memory, we sholud remove page table about the memory.
> So the patch searches a page table about the removed memory, and clear
> page table.
>
> CC: David Rientjes <rientjes@google.com>
> CC: Jiang Liu <liuj97@gmail.com>
> CC: Len Brown <len.brown@intel.com>
> CC: Christoph Lameter <cl@linux.com>
> Cc: Minchan Kim <minchan.kim@gmail.com>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> CC: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> ---
> arch/x86/include/asm/pgtable_types.h | 1
> arch/x86/mm/init_64.c | 147 +++++++++++++++++++++++++++++++++++
> arch/x86/mm/pageattr.c | 47 +++++------
> 3 files changed, 173 insertions(+), 22 deletions(-)
>
> Index: linux-3.6/arch/x86/mm/init_64.c
> ===================================================================
> --- linux-3.6.orig/arch/x86/mm/init_64.c 2012-10-04 18:30:21.171698416 +0900
> +++ linux-3.6/arch/x86/mm/init_64.c 2012-10-04 18:30:27.317704652 +0900
> @@ -675,6 +675,151 @@ int arch_add_memory(int nid, u64 start,
> }
> EXPORT_SYMBOL_GPL(arch_add_memory);
>
> +static void __meminit
> +phys_pte_remove(pte_t *pte_page, unsigned long addr, unsigned long end)
> +{
> + unsigned pages = 0;
> + int i = pte_index(addr);
> +
> + pte_t *pte = pte_page + pte_index(addr);
> +
> + for (; i < PTRS_PER_PTE; i++, addr += PAGE_SIZE, pte++) {
> +
> + if (addr >= end)
> + break;
> +
> + if (!pte_present(*pte))
> + continue;
> +
> + pages++;
> + set_pte(pte, __pte(0));
> + }
> +
> + update_page_count(PG_LEVEL_4K, -pages);
> +}
> +
> +static void __meminit
> +phys_pmd_remove(pmd_t *pmd_page, unsigned long addr, unsigned long end)
> +{
> + unsigned long pages = 0, next;
> + int i = pmd_index(addr);
> +
> + for (; i < PTRS_PER_PMD; i++, addr = next) {
> + unsigned long pte_phys;
> + pmd_t *pmd = pmd_page + pmd_index(addr);
> + pte_t *pte;
> +
> + if (addr >= end)
> + break;
> +
> + next = (addr & PMD_MASK) + PMD_SIZE;
> +
> + if (!pmd_present(*pmd))
> + continue;
> +
> + if (pmd_large(*pmd)) {
> + if ((addr & ~PMD_MASK) == 0 && next <= end) {
> + set_pmd(pmd, __pmd(0));
> + pages++;
> + continue;
> + }
> +
> + /*
> + * We use 2M page, but we need to remove part of them,
> + * so split 2M page to 4K page.
> + */
> + pte = alloc_low_page(&pte_phys);
> + __split_large_page((pte_t *)pmd, addr, pte);
> +
> + spin_lock(&init_mm.page_table_lock);
> + pmd_populate_kernel(&init_mm, pmd, __va(pte_phys));
> + spin_unlock(&init_mm.page_table_lock);
> + }
> +
> + spin_lock(&init_mm.page_table_lock);
> + pte = map_low_page((pte_t *)pmd_page_vaddr(*pmd));
> + phys_pte_remove(pte, addr, end);
> + unmap_low_page(pte);
> + spin_unlock(&init_mm.page_table_lock);
> + }
> + update_page_count(PG_LEVEL_2M, -pages);
> +}
> +
> +static void __meminit
> +phys_pud_remove(pud_t *pud_page, unsigned long addr, unsigned long end)
> +{
> + unsigned long pages = 0, next;
> + int i = pud_index(addr);
> +
> + for (; i < PTRS_PER_PUD; i++, addr = next) {
> + unsigned long pmd_phys;
> + pud_t *pud = pud_page + pud_index(addr);
> + pmd_t *pmd;
> +
> + if (addr >= end)
> + break;
> +
> + next = (addr & PUD_MASK) + PUD_SIZE;
> +
> + if (!pud_present(*pud))
> + continue;
> +
> + if (pud_large(*pud)) {
> + if ((addr & ~PUD_MASK) == 0 && next <= end) {
> + set_pud(pud, __pud(0));
> + pages++;
> + continue;
> + }
> +
> + /*
> + * We use 1G page, but we need to remove part of them,
> + * so split 1G page to 2M page.
> + */
> + pmd = alloc_low_page(&pmd_phys);
> + __split_large_page((pte_t *)pud, addr, (pte_t *)pmd);
> +
> + spin_lock(&init_mm.page_table_lock);
> + pud_populate(&init_mm, pud, __va(pmd_phys));
> + spin_unlock(&init_mm.page_table_lock);
> + }
> +
> + pmd = map_low_page(pmd_offset(pud, 0));
> + phys_pmd_remove(pmd, addr, end);
> + unmap_low_page(pmd);
> + __flush_tlb_all();
> + }
> + __flush_tlb_all();
> +
> + update_page_count(PG_LEVEL_1G, -pages);
> +}
> +
> +void __meminit
> +kernel_physical_mapping_remove(unsigned long start, unsigned long end)
> +{
> + unsigned long next;
> +
> + start = (unsigned long)__va(start);
> + end = (unsigned long)__va(end);
> +
> + for (; start < end; start = next) {
> + pgd_t *pgd = pgd_offset_k(start);
> + pud_t *pud;
> +
> + next = (start + PGDIR_SIZE) & PGDIR_MASK;
> + if (next > end)
> + next = end;
> +
> + if (!pgd_present(*pgd))
> + continue;
> +
> + pud = map_low_page((pud_t *)pgd_page_vaddr(*pgd));
> + phys_pud_remove(pud, __pa(start), __pa(end));
> + unmap_low_page(pud);
> + }
> +
> + __flush_tlb_all();
> +}
> +
> #ifdef CONFIG_MEMORY_HOTREMOVE
> int __ref arch_remove_memory(u64 start, u64 size)
> {
> @@ -687,6 +832,8 @@ int __ref arch_remove_memory(u64 start,
> ret = __remove_pages(zone, start_pfn, nr_pages);
> WARN_ON_ONCE(ret);
>
> + kernel_physical_mapping_remove(start, start + size);
> +
> return ret;
> }
> #endif
> Index: linux-3.6/arch/x86/include/asm/pgtable_types.h
> ===================================================================
> --- linux-3.6.orig/arch/x86/include/asm/pgtable_types.h 2012-10-04 18:26:51.925486954 +0900
> +++ linux-3.6/arch/x86/include/asm/pgtable_types.h 2012-10-04 18:30:27.322704656 +0900
> @@ -334,6 +334,7 @@ static inline void update_page_count(int
> * as a pte too.
> */
> extern pte_t *lookup_address(unsigned long address, unsigned int *level);
> +extern int __split_large_page(pte_t *kpte, unsigned long address, pte_t *pbase);
>
> #endif /* !__ASSEMBLY__ */
>
> Index: linux-3.6/arch/x86/mm/pageattr.c
> ===================================================================
> --- linux-3.6.orig/arch/x86/mm/pageattr.c 2012-10-04 18:26:51.923486952 +0900
> +++ linux-3.6/arch/x86/mm/pageattr.c 2012-10-04 18:30:27.328704662 +0900
> @@ -501,21 +501,13 @@ out_unlock:
> return do_split;
> }
>
> -static int split_large_page(pte_t *kpte, unsigned long address)
> +int __split_large_page(pte_t *kpte, unsigned long address, pte_t *pbase)
> {
> unsigned long pfn, pfninc = 1;
> unsigned int i, level;
> - pte_t *pbase, *tmp;
> + pte_t *tmp;
> pgprot_t ref_prot;
> - struct page *base;
> -
> - if (!debug_pagealloc)
> - spin_unlock(&cpa_lock);
> - base = alloc_pages(GFP_KERNEL | __GFP_NOTRACK, 0);
> - if (!debug_pagealloc)
> - spin_lock(&cpa_lock);
> - if (!base)
> - return -ENOMEM;
> + struct page *base = virt_to_page(pbase);
>
> spin_lock(&pgd_lock);
> /*
> @@ -523,10 +515,11 @@ static int split_large_page(pte_t *kpte,
> * up for us already:
> */
> tmp = lookup_address(address, &level);
> - if (tmp != kpte)
> - goto out_unlock;
> + if (tmp != kpte) {
> + spin_unlock(&pgd_lock);
> + return 1;
> + }
>
> - pbase = (pte_t *)page_address(base);
> paravirt_alloc_pte(&init_mm, page_to_pfn(base));
> ref_prot = pte_pgprot(pte_clrhuge(*kpte));
> /*
> @@ -579,17 +572,27 @@ static int split_large_page(pte_t *kpte,
> * going on.
> */
> __flush_tlb_all();
> + spin_unlock(&pgd_lock);
>
> - base = NULL;
> + return 0;
> +}
>
> -out_unlock:
> - /*
> - * If we dropped out via the lookup_address check under
> - * pgd_lock then stick the page back into the pool:
> - */
> - if (base)
> +static int split_large_page(pte_t *kpte, unsigned long address)
> +{
> + pte_t *pbase;
> + struct page *base;
> +
> + if (!debug_pagealloc)
> + spin_unlock(&cpa_lock);
> + base = alloc_pages(GFP_KERNEL | __GFP_NOTRACK, 0);
> + if (!debug_pagealloc)
> + spin_lock(&cpa_lock);
> + if (!base)
> + return -ENOMEM;
> +
> + pbase = (pte_t *)page_address(base);
> + if (__split_large_page(kpte, address, pbase))
> __free_page(base);
> - spin_unlock(&pgd_lock);
>
> return 0;
> }
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
^ permalink raw reply related
* Re: [RFC v9 PATCH 00/21] memory-hotplug: hot-remove physical memory
From: Wen Congyang @ 2012-10-09 8:11 UTC (permalink / raw)
To: Vasilis Liaskovitis
Cc: linux-s390, linux-ia64, len.brown, linux-acpi, linux-sh, x86,
linux-kernel, cmetcalf, linux-mm, isimatu.yasuaki, paulus,
minchan.kim, kosaki.motohiro, rientjes, sparclinux, cl,
linuxppc-dev, akpm, liuj97
In-Reply-To: <20120926164649.GA7559@dhcp-192-168-178-175.profitbricks.localdomain>
At 09/27/2012 12:46 AM, Vasilis Liaskovitis Wrote:
> Hi,
>
> I am testing 3.6.0-rc7 with this v9 patchset plus more recent fixes [1],[2],[3]
> Running in a guest (qemu+seabios from [4]).
> CONFIG_SLAB=y
> CONFIG_DEBUG_SLAB=y
>
> After succesfull hot-add and online, I am doing a hot-remove with "echo 1 > /sys/bus/acpi/devices/PNP/eject"
> When I do the OSPM-eject, I often get slab corruption in "acpi-state" cache, or in other caches
The following patch can fix this problem:
https://lkml.org/lkml/2012/7/12/186
Thanks
Wen Congyang
>
> [ 170.566995] Slab corruption (Not tainted): Acpi-State start=ffff88009fc1e548, len=80
> [ 170.567265] Redzone: 0x0/0x0.
> [ 170.567399] Last user: [< (null)>](0x0)
> [ 170.567667] 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 170.568078] 010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 170.568487] 020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 170.568894] 030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 170.569302] 040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 170.569712] Prev obj: start=000000009fc1e4d0, len=80
> [ 170.569869] BUG: unable to handle kernel paging request at 000000009fc1e520
> [ 170.570171] IP: [<ffffffff8112803c>] print_objinfo+0x9c/0x110
> [ 170.570397] PGD 7cf37067 PUD 0
> [ 170.570619] Oops: 0000 [#1] SMP
> [ 170.570843] Modules linked in: netconsole acpiphp pci_hotplug acpi_memhotplug loop kvm_amd kvm tpm_tis microcode tpm tpm_bios psmouse parport_pc serio_raw evdev parport i2c_piix4 processor thermal_sys i2c_core button ext3 jbd mbcache sg sr_mod cdrom ata_generic virtio_net virtio_blk ata_piix libata scsi_mod virtio_pci virtio_ring virtio
> [ 170.573474] CPU 0
> [ 170.573568] Pid: 29, comm: kworker/0:1 Not tainted 3.6.0-rc7-guest #12 Bochs Bochs
> [ 170.573830] RIP: 0010:[<ffffffff8112803c>] [<ffffffff8112803c>] print_objinfo+0x9c/0x110
> [ 170.574106] RSP: 0018:ffff88003eaf3a70 EFLAGS: 00010202
> [ 170.574268] RAX: 000000009fc1e4c8 RBX: 0000000000000002 RCX: 00000000000024b8
> [ 170.574468] RDX: 000000009fc1e4c8 RSI: 000000009fc1e4c8 RDI: ffff88003e9bb980
> [ 170.574668] RBP: ffff88003e9bb980 R08: ffff880037964078 R09: 0000000000000000
> [ 170.574870] R10: 000000000000021e R11: 0000000000000002 R12: 000000009fc1e4c8
> [ 170.575070] R13: 000000009fc1e520 R14: 000000000000004f R15: 00000000ffffffa5
> [ 170.575274] FS: 00007fc6b7530700(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
> [ 170.575494] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 170.575665] CR2: 000000009fc1e520 CR3: 000000007c9c1000 CR4: 00000000000006f0
> [ 170.575870] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 170.576075] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 170.576276] Process kworker/0:1 (pid: 29, threadinfo ffff88003eaf2000, task ffff88003ea941c0)
> [ 170.576507] Stack:
> [ 170.576599] 0000000000000010 0000000001893fbe ffff88009fc1e000 0000000000000050
> [ 170.576938] 000000009fc1e4c8 000000000000004f 00000000ffffffa5 ffffffff8112899f
> [ 170.576938] ffff88003eb309d8 ffffffff81712d6d ffff88003e9bb980 ffff88009fc1e540
> [ 170.576938] Call Trace:
> [ 170.576938] [<ffffffff8112899f>] ? check_poison_obj+0x1df/0x1f0
> [ 170.576938] [<ffffffff813047d0>] ? acpi_ut_create_generic_state+0x2f/0x4c
> [ 170.576938] [<ffffffff813047d0>] ? acpi_ut_create_generic_state+0x2f/0x4c
> [ 170.576938] [<ffffffff81128a9d>] ? cache_alloc_debugcheck_after.isra.52+0xed/0x220
> [ 170.576938] [<ffffffff813047d0>] ? acpi_ut_create_generic_state+0x2f/0x4c
> [ 170.576938] [<ffffffff8112beb5>] ? kmem_cache_alloc+0xb5/0x1e0
> [ 170.576938] [<ffffffff813047d0>] ? acpi_ut_create_generic_state+0x2f/0x4c
> [ 170.576938] [<ffffffff812edf2d>] ? acpi_ds_result_push+0x5d/0x12e
> [ 170.576938] [<ffffffff812ed127>] ? acpi_ds_exec_end_op+0x28e/0x3d3
> [ 170.576938] [<ffffffff812fd86a>] ? acpi_ps_parse_loop+0x79f/0x931
> [ 170.576938] [<ffffffff812fdd6c>] ? acpi_ps_parse_aml+0x89/0x261
> [ 170.576938] [<ffffffff812fe50c>] ? acpi_ps_execute_method+0x1be/0x266
> [ 170.576938] [<ffffffff812f91f7>] ? acpi_ns_evaluate+0xd3/0x19a
> [ 170.576938] [<ffffffff812fb93e>] ? acpi_evaluate_object+0xf3/0x1f4
> [ 170.576938] [<ffffffff812e1104>] ? acpi_os_wait_events_complete+0x1b/0x1b
> [ 170.576938] [<ffffffff812e4782>] ? acpi_bus_hot_remove_device+0xeb/0x123
> [ 170.576938] [<ffffffff812e1121>] ? acpi_os_execute_deferred+0x1d/0x29
> [ 170.576938] [<ffffffff81058ec5>] ? process_one_work+0x125/0x560
> [ 170.576938] [<ffffffff81059e7a>] ? worker_thread+0x16a/0x4e0
> [ 170.576938] [<ffffffff81059d10>] ? manage_workers+0x310/0x310
> [ 170.576938] [<ffffffff8105e6c5>] ? kthread+0x85/0x90
> [ 170.576938] [<ffffffff814eb2c4>] ? kernel_thread_helper+0x4/0x10
> [ 170.576938] [<ffffffff8105e640>] ? flush_kthread_worker+0xa0/0xa0
> [ 170.576938] [<ffffffff814eb2c0>] ? gs_change+0x13/0x13
> [ 170.576938] Code: cb 75 dc 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 8b 7f 0c 4c 89 e2 e8 02 fd ff ff 4c 89 e6 49 89 c5 48 89 ef e8 d4 fc ff ff <49> 8b 55 00 48 8b 30 48 c7 c7 8c 39 6f 81 31 c0 e8 3e 34 3b 00
>
> Other times, the problem happens on a slab object free:
>
> [ 52.313366] Offlined Pages 32768
> [ 52.800232] slab error in verify_redzone_free(): cache `Acpi-ParseExt': memory outside object was overwritten
> [ 52.801298] Pid: 29, comm: kworker/0:1 Not tainted 3.6.0-rc7-guest #12
> [ 52.802039] Call Trace:
> [ 52.802443] [<ffffffff811280cb>] ? __slab_error.isra.46+0x1b/0x30
> [ 52.803199] [<ffffffff811287b6>] ? cache_free_debugcheck+0x256/0x260
> [ 52.803940] [<ffffffff812e1b0e>] ? acpi_os_release_object+0x7/0xc
> [ 52.804645] [<ffffffff81128fe3>] ? kmem_cache_free+0x63/0x260
> [ 52.805321] [<ffffffff812e1b0e>] ? acpi_os_release_object+0x7/0xc
> [ 52.806023] [<ffffffff812fe298>] ? acpi_ps_delete_parse_tree+0x34/0x58
> [ 52.806762] [<ffffffff812fe517>] ? acpi_ps_execute_method+0x1c9/0x266
> [ 52.807499] [<ffffffff812f91f7>] ? acpi_ns_evaluate+0xd3/0x19a
> [ 52.808183] [<ffffffff812fb93e>] ? acpi_evaluate_object+0xf3/0x1f4
> [ 52.808897] [<ffffffff812e1104>] ? acpi_os_wait_events_complete+0x1b/0x1b
> [ 52.809659] [<ffffffff812e4782>] ? acpi_bus_hot_remove_device+0xeb/0x123
> [ 52.810032] [<ffffffff812e1121>] ? acpi_os_execute_deferred+0x1d/0x29
> [ 52.810032] [<ffffffff81058ec5>] ? process_one_work+0x125/0x560
> [ 52.810032] [<ffffffff81059e7a>] ? worker_thread+0x16a/0x4e0
> [ 52.810032] [<ffffffff81059d10>] ? manage_workers+0x310/0x310
> [ 52.810032] [<ffffffff8105e6c5>] ? kthread+0x85/0x90
> [ 52.810032] [<ffffffff814eb2c4>] ? kernel_thread_helper+0x4/0x10
> [ 52.810032] [<ffffffff8105e640>] ? flush_kthread_worker+0xa0/0xa0
> [ 52.810032] [<ffffffff814eb2c0>] ? gs_change+0x13/0x13
> [ 52.810032] ffff88008f809670: redzone 1:0x0, redzone 2:0x0.
> [ 52.810032] ------------[ cut here ]------------
> [ 52.810032] kernel BUG at mm/slab.c:3125!
> [ 52.810032] invalid opcode: 0000 [#1] SMP
> [ 52.810032] Modules linked in: netconsole acpiphp pci_hotplug acpi_memhotplug loop kvm_amd kvm tpm_tis tpm tpm_bios microcode parport_pc parport evdev processor thermal_sys psmouse i2c_piix4 serio_raw i2c_core button ext3 jbd mbcache sg sr_mod cdrom virtio_net ata_generic virtio_blk virtio_pci virtio_ring virtio ata_piix libata scsi_mod
> [ 52.810032] CPU 0
> [ 52.810032] Pid: 29, comm: kworker/0:1 Not tainted 3.6.0-rc7-guest #12 Bochs Bochs
> [ 52.810032] RIP: 0010:[<ffffffff81128733>] [<ffffffff81128733>] cache_free_debugcheck+0x1d3/0x260
> [ 52.810032] RSP: 0018:ffff88003eaf3bc0 EFLAGS: 00010093
> [ 52.810032] RAX: 00000000017eac3c RBX: ffff88003e9bb700 RCX: 0000000002aaaaab
> [ 52.810032] RDX: 0000000000000000 RSI: 0000000000010000 RDI: 0000000000000060
> [ 52.810032] RBP: ffff88008f809670 R08: 09f911029d74e35b R09: 0000000000000000
> [ 52.810032] R10: 00000000000001d3 R11: 0000000000000002 R12: ffff88008f809000
> [ 52.810032] R13: ffffffff812e1b0e R14: 0000000000000000 R15: 0000000000010c00
> [ 52.810032] FS: 00007f63fc263700(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
> [ 52.810032] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 52.810032] CR2: 00007fff8d895b78 CR3: 000000007c866000 CR4: 00000000000006f0
> [ 52.810032] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 52.810032] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 52.810032] Process kworker/0:1 (pid: 29, threadinfo ffff88003eaf2000, task ffff88003ea941c0)
> [ 52.810032] Stack:
> [ 52.810032] ffff88003e9bb980 ffff88008f809670 ffff880037ba8e18 ffff88008f809678
> [ 52.810032] ffff88003e9bb700 0000000000000282 ffff88003e9bf270 ffffffff812e1b0e
> [ 52.810032] 0000000000000001 ffffffff81128fe3 ffff88003e80f5e8 ffff88003eb31748
> [ 52.810032] Call Trace:
> [ 52.810032] [<ffffffff812e1b0e>] ? acpi_os_release_object+0x7/0xc
> [ 52.810032] [<ffffffff81128fe3>] ? kmem_cache_free+0x63/0x260
> [ 52.810032] [<ffffffff812e1b0e>] ? acpi_os_release_object+0x7/0xc
> [ 52.810032] [<ffffffff812fe298>] ? acpi_ps_delete_parse_tree+0x34/0x58
> [ 52.810032] [<ffffffff812fe517>] ? acpi_ps_execute_method+0x1c9/0x266
> [ 52.810032] [<ffffffff812f91f7>] ? acpi_ns_evaluate+0xd3/0x19a
> [ 52.810032] [<ffffffff812fb93e>] ? acpi_evaluate_object+0xf3/0x1f4
> [ 52.810032] [<ffffffff812e1104>] ? acpi_os_wait_events_complete+0x1b/0x1b
> [ 52.810032] [<ffffffff812e4782>] ? acpi_bus_hot_remove_device+0xeb/0x123
> [ 52.810032] [<ffffffff812e1121>] ? acpi_os_execute_deferred+0x1d/0x29
> [ 52.810032] [<ffffffff81058ec5>] ? process_one_work+0x125/0x560
> [ 52.810032] [<ffffffff81059e7a>] ? worker_thread+0x16a/0x4e0
> [ 52.810032] [<ffffffff81059d10>] ? manage_workers+0x310/0x310
> [ 52.810032] [<ffffffff8105e6c5>] ? kthread+0x85/0x90
> [ 52.810032] [<ffffffff814eb2c4>] ? kernel_thread_helper+0x4/0x10
> [ 52.810032] [<ffffffff8105e640>] ? flush_kthread_worker+0xa0/0xa0
> [ 52.810032] [<ffffffff814eb2c0>] ? gs_change+0x13/0x13
> [ 52.810032] Code: 89 ea 49 89 38 8b 73 14 8b 7b 0c e8 18 f6 ff ff 49 b8 5b e3 74 9d 02 11 f9 09 4c 89 00 44 8b 7b 14 44 89 f8 e9 fa fe ff ff 0f 0b <0f> 0b 48 8b 40 30 e9 d9 fe ff ff e8 c6 43 3b 00 0f 0b 48 8b 40
> [ 52.810032] RIP [<ffffffff81128733>] cache_free_debugcheck+0x1d3/0x260
> [ 52.810032] RSP <ffff88003eaf3bc0>
> [ 52.810032] ---[ end trace c699c8cecd5870a3 ]---
>
>
> And other times, I see a filesystem related slab corruption when doing the eject.
> Here I have also seen a bad rss-counter state message.
>
> [ 232.114232] BUG: Bad rss-counter state mm:ffff88007d9c1f80 idx:0 val:1
> [ 232.115214] BUG: unable to handle kernel NULL pointer dereference at (null)
> [ 232.115807] IP: [<ffffffffa00cfce3>] do_get_write_access+0x43/0x480 [jbd]
> [ 232.116186] PGD 7cdec067 PUD 7c946067 PMD 0
> [ 232.116627] Oops: 0000 [#3] SMP
> [ 232.116990] Modules linked in: netconsole acpiphp pci_hotplug acpi_memhotplug loop kvm_amd kvm microcode tpm_tis tpm tpm_bios evdev psmouse serio_raw i2c_piix4 i2c_core parport_pc parport processor thermal_sys button ext3 jbd mbcache virtio_net sg sr_mod cdrom virtio_blk ata_generic virtio_pci virtio_ring virtio ata_piix libata scsi_mod
> [ 232.120013] CPU 2
> [ 232.120013] Pid: 880, comm: dhclient Tainted: G D 3.6.0-rc7-guest #1 Bochs Bochs
> [ 232.120013] RIP: 0010:[<ffffffffa00cfce3>] [<ffffffffa00cfce3>] do_get_write_access+0x43/0x480 [jbd]
> [ 232.120013] RSP: 0018:ffff88007cd6fab8 EFLAGS: 00010246
> [ 232.120013] RAX: ffff88003e513f50 RBX: ffff88003e513f50 RCX: 0000000000000000
> [ 232.120013] RDX: 0000000000000000 RSI: ffff88003e513f50 RDI: ffff880097800000
> [ 232.120013] RBP: ffff88003e513f50 R08: 000000003e513f01 R09: 0000000180240024
> [ 232.120013] R10: ffff88003e513f50 R11: 00000000000198e0 R12: 0000000000000000
> [ 232.120013] R13: ffffffffa00eb437 R14: ffff880097800000 R15: 000000000000027a
> [ 232.120013] FS: 00007f082638d700(0000) GS:ffff88003ec80000(0000) knlGS:0000000000000000
> [ 232.120013] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 232.120013] CR2: 0000000000000000 CR3: 000000007c94c000 CR4: 00000000000006e0
> [ 232.120013] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 232.120013] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 232.120013] Process dhclient (pid: 880, threadinfo ffff88007cd6e000, task ffff88007ca46800)
> [ 232.120013] Stack:
> [ 232.120013] ffff88007dc205b0 ffffffff8116645f ffff88007dc205b0 ffff88007dc205b0
> [ 232.120013] ffff88007cf58800 0000000000000000 000000000000000e 0000000000000000
> [ 232.120013] 000000000000027a ffffffff8112b934 0000005000000003 0000000000000fff
> [ 232.120013] Call Trace:
> [ 232.120013] [<ffffffff8116645f>] ? __find_get_block+0x7f/0x200
> [ 232.120013] [<ffffffff8112b934>] ? kmem_cache_alloc+0xe4/0x140
> [ 232.120013] [<ffffffffa00eb437>] ? ext3_dirty_inode+0x57/0xb0 [ext3]
> [ 232.120013] [<ffffffffa00d0279>] ? journal_get_write_access+0x29/0x50 [jbd]
> [ 232.120013] [<ffffffffa00eaeef>] ? __ext3_get_inode_loc+0xcf/0x360 [ext3]
> [ 232.120013] [<ffffffffa0101317>] ? __ext3_journal_get_write_access+0x27/0x60 [ext3]
> [ 232.120013] [<ffffffffa00eb213>] ? ext3_reserve_inode_write+0x73/0xa0 [ext3]
> [ 232.120013] [<ffffffffa00eb27b>] ? ext3_mark_inode_dirty+0x3b/0xa0 [ext3]
> [ 232.120013] [<ffffffffa00eb437>] ? ext3_dirty_inode+0x57/0xb0 [ext3]
> [ 232.120013] [<ffffffff8115ded6>] ? __mark_inode_dirty+0x36/0x230
> [ 232.120013] [<ffffffff811504a1>] ? update_time+0x71/0xb0
> [ 232.120013] [<ffffffff811536c9>] ? mnt_clone_write+0x9/0x20
> [ 232.120013] [<ffffffff81150581>] ? file_update_time+0xa1/0xf0
> [ 232.120013] [<ffffffff8103385c>] ? ptep_set_access_flags+0x6c/0x70
> [ 232.120013] [<ffffffff810e3f30>] ? __generic_file_aio_write+0x1a0/0x3c0
> [ 232.120013] [<ffffffff811396fb>] ? __sb_start_write+0x6b/0x130
> [ 232.120013] [<ffffffff810e41ce>] ? generic_file_aio_write+0x7e/0x100
> [ 232.120013] [<ffffffff81137484>] ? do_sync_write+0x94/0xd0
> [ 232.120013] [<ffffffff81137caa>] ? vfs_write+0xaa/0x160
> [ 232.120013] [<ffffffff81137f87>] ? sys_write+0x47/0x90
> [ 232.120013] [<ffffffff814e5765>] ? async_page_fault+0x25/0x30
> [ 232.120013] [<ffffffff814eca79>] ? system_call_fastpath+0x16/0x1b
> [ 232.120013] Code: 54 24 2c f6 47 14 04 74 1f 41 bc e2 ff ff ff 48 81 c4 98 00 00 00 44 89 e0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f 1f 40 00 4c 8b 27 <4d> 8b 3c 24 41 f6 07 02 75 d4 65 48 8b 04 25 80 b9 00 00 48 89
>
> Is this a known issue? If yes, can you point me to any relevant patches?
>
> When I do an SCI(hardware) eject, I have not seen corruptions. The acpi driver is
> evaluating fewer objects in this path I think, but I don't see why corruption can't
> happen here as well.
>
> I have seen similar problems with CONFIG_SLUB (I did not have debug_options
> there but I can also provide those if helpful)
>
> [1] https://lkml.org/lkml/2012/9/6/635
> [2] https://lkml.org/lkml/2012/9/11/542
> [3] https://lkml.org/lkml/2012/9/20/37
> [4] http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/98691
>
> thanks,
>
> - Vasilis
>
^ permalink raw reply
* support for Xilinx PCIe BUS IP core
From: Bashar Romanous @ 2012-10-09 7:38 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 553 bytes --]
Dear All,
This is the first thread in the list, I'm working on research project that
requires me to have "PCI Express Bus Support" for Xilinx FPGA board
ML605 running PetaLinux (kernel 2.6.37.6) on MicroBlaze. I'm using Xilinx
soft IP core "PLB2PCIe bridge" configured as Root Complex. the problem is
that on the Linux Kernel side, in the "Bus Options", there is no support
for Xilinx PCIe Bus.
Has anybody written Linux Driver for this IP core? what about Xilinx' (*AXI
RC*/*EP* Bridge for *PCI Express)? any drivers for this?*
Best Regards,
Bashar
[-- Attachment #2: Type: text/html, Size: 1994 bytes --]
^ permalink raw reply
* [RFC Patch] 405gp IBM EMAC Phy probe fails with no link
From: Andrew May @ 2012-10-09 6:23 UTC (permalink / raw)
To: linuxppc-dev, netdev
[-- Attachment #1: Type: text/plain, Size: 732 bytes --]
I have an older PPC 405GP board with a 2.6.33 kernel that fails to
install a eth0 instance because the phy probe fails when there is no
good ethernet link.
I have looked at the latest kernel code and it seems just about the same
in this area, but I have not tried it.
Does anyone else still have a 405GP board to try and see if eth0 comes
up with not enet cable?
I tried to probe the phy earlier and skip the emac_configure() call in
emac_init_phy() to avoid doing the MR0_SRST bit set.
But the phy read still times out.
I then went with this approach to re-call emac_init_phy() after the
emac_reset() finally completes when a cable is plugged in.
Does anyone else have any ideas why the phy probe fails on the first pass?
[-- Attachment #2: ibm_phyprobe.patch --]
[-- Type: text/x-patch, Size: 2450 bytes --]
diff -ur linux.orig/drivers/net/ibm_newemac/core.c linux/drivers/net/ibm_newemac/core.c
--- linux.orig/drivers/net/ibm_newemac/core.c 2012-10-08 12:38:33.000000000 -0700
+++ linux/drivers/net/ibm_newemac/core.c 2012-10-08 14:31:35.797089192 -0700
@@ -106,6 +106,7 @@
*/
static DECLARE_WAIT_QUEUE_HEAD(emac_probe_wait);
+static int emac_init_phy(struct emac_instance *dev);
/* Having stable interface names is a doomed idea. However, it would be nice
* if we didn't have completely random interface names at boot too :-) It's
* just a matter of making everybody's life easier. Since we are doing
@@ -135,7 +136,7 @@
EMAC_FTR_440EP_PHY_CLK_FIX))
DBG(dev, "%s" NL, error);
else if (net_ratelimit())
- printk(KERN_ERR "%s: %s\n", dev->ofdev->node->full_name, error);
+ printk(KERN_INFO "%s: %s\n", dev->ofdev->node->full_name, error);
}
/* EMAC PHY clock workaround:
@@ -161,6 +162,7 @@
}
/* PHY polling intervals */
+#define PHY_POLL_NO_PHY (5 * HZ)
#define PHY_POLL_LINK_ON HZ
#define PHY_POLL_LINK_OFF (HZ / 5)
@@ -1156,8 +1158,12 @@
/* Start PHY polling now.
*/
- if (dev->phy.address >= 0) {
+ if (dev->phy.address >= 0 || dev->phy.address == -2) {
int link_poll_interval;
+ if (dev->phy.address == -2) {
+ netif_carrier_off(dev->ndev);
+ link_poll_interval = PHY_POLL_NO_PHY;
+ }else
if (dev->phy.def->ops->poll_link(&dev->phy)) {
dev->phy.def->ops->read_link(&dev->phy);
emac_rx_clk_default(dev);
@@ -1243,7 +1249,17 @@
if (!dev->opened)
goto bail;
- if (dev->phy.def->ops->poll_link(&dev->phy)) {
+
+ if (!dev->phy.def) {
+ /* If the reset finally clears, because the phy now
+ * has a link, then reprobe for the phy.
+ */
+ if (emac_reset(dev) == 0)
+ {
+ emac_init_phy(dev);
+ }
+ link_poll_interval = PHY_POLL_NO_PHY;
+ }else if (dev->phy.def->ops->poll_link(&dev->phy)) {
if (!netif_carrier_ok(dev->ndev)) {
emac_rx_clk_default(dev);
/* Get new link parameters */
@@ -2376,7 +2392,7 @@
return 0;
}
-static int __devinit emac_init_phy(struct emac_instance *dev)
+static int emac_init_phy(struct emac_instance *dev)
{
struct device_node *np = dev->ofdev->node;
struct net_device *ndev = dev->ndev;
@@ -2470,7 +2486,9 @@
mutex_unlock(&emac_phy_map_lock);
if (i == 0x20) {
printk(KERN_WARNING "%s: can't find PHY!\n", np->full_name);
- return -ENXIO;
+ busy_phy_map = 0;
+ dev->phy.address = -2;
+ return 0;
}
/* Init PHY */
^ permalink raw reply
* Re: [RFC v9 PATCH 00/21] memory-hotplug: hot-remove physical memory
From: Wen Congyang @ 2012-10-09 6:16 UTC (permalink / raw)
To: Vasilis Liaskovitis
Cc: linux-s390, linux-ia64, len.brown, linux-acpi, linux-sh, x86,
linux-kernel, cmetcalf, linux-mm, isimatu.yasuaki, paulus,
minchan.kim, kosaki.motohiro, rientjes, sparclinux, cl,
linuxppc-dev, akpm, liuj97
In-Reply-To: <20120926164649.GA7559@dhcp-192-168-178-175.profitbricks.localdomain>
At 09/27/2012 12:46 AM, Vasilis Liaskovitis Wrote:
> Hi,
>
> I am testing 3.6.0-rc7 with this v9 patchset plus more recent fixes [1],[2],[3]
> Running in a guest (qemu+seabios from [4]).
> CONFIG_SLAB=y
> CONFIG_DEBUG_SLAB=y
>
> After succesfull hot-add and online, I am doing a hot-remove with "echo 1 > /sys/bus/acpi/devices/PNP/eject"
> When I do the OSPM-eject, I often get slab corruption in "acpi-state" cache, or in other caches
I found the reason: when you do OSPM-eject, the kernel will auto offline and remove the memory.
But, offlining memory fails, and the memory is still used by the kernel. But device_release_driver()
doesn't tell this error to the caller acpi_bus_remove(). The kernel will poweroff and eject
the device by emulate _PS3 and _EJ0. The kernel uses some memory which doesn't exist. It's
very dangerous.
Thanks
Wen Conyang
>
> [ 170.566995] Slab corruption (Not tainted): Acpi-State start=ffff88009fc1e548, len=80
> [ 170.567265] Redzone: 0x0/0x0.
> [ 170.567399] Last user: [< (null)>](0x0)
> [ 170.567667] 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 170.568078] 010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 170.568487] 020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 170.568894] 030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 170.569302] 040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 170.569712] Prev obj: start=000000009fc1e4d0, len=80
> [ 170.569869] BUG: unable to handle kernel paging request at 000000009fc1e520
> [ 170.570171] IP: [<ffffffff8112803c>] print_objinfo+0x9c/0x110
> [ 170.570397] PGD 7cf37067 PUD 0
> [ 170.570619] Oops: 0000 [#1] SMP
> [ 170.570843] Modules linked in: netconsole acpiphp pci_hotplug acpi_memhotplug loop kvm_amd kvm tpm_tis microcode tpm tpm_bios psmouse parport_pc serio_raw evdev parport i2c_piix4 processor thermal_sys i2c_core button ext3 jbd mbcache sg sr_mod cdrom ata_generic virtio_net virtio_blk ata_piix libata scsi_mod virtio_pci virtio_ring virtio
> [ 170.573474] CPU 0
> [ 170.573568] Pid: 29, comm: kworker/0:1 Not tainted 3.6.0-rc7-guest #12 Bochs Bochs
> [ 170.573830] RIP: 0010:[<ffffffff8112803c>] [<ffffffff8112803c>] print_objinfo+0x9c/0x110
> [ 170.574106] RSP: 0018:ffff88003eaf3a70 EFLAGS: 00010202
> [ 170.574268] RAX: 000000009fc1e4c8 RBX: 0000000000000002 RCX: 00000000000024b8
> [ 170.574468] RDX: 000000009fc1e4c8 RSI: 000000009fc1e4c8 RDI: ffff88003e9bb980
> [ 170.574668] RBP: ffff88003e9bb980 R08: ffff880037964078 R09: 0000000000000000
> [ 170.574870] R10: 000000000000021e R11: 0000000000000002 R12: 000000009fc1e4c8
> [ 170.575070] R13: 000000009fc1e520 R14: 000000000000004f R15: 00000000ffffffa5
> [ 170.575274] FS: 00007fc6b7530700(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
> [ 170.575494] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 170.575665] CR2: 000000009fc1e520 CR3: 000000007c9c1000 CR4: 00000000000006f0
> [ 170.575870] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 170.576075] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 170.576276] Process kworker/0:1 (pid: 29, threadinfo ffff88003eaf2000, task ffff88003ea941c0)
> [ 170.576507] Stack:
> [ 170.576599] 0000000000000010 0000000001893fbe ffff88009fc1e000 0000000000000050
> [ 170.576938] 000000009fc1e4c8 000000000000004f 00000000ffffffa5 ffffffff8112899f
> [ 170.576938] ffff88003eb309d8 ffffffff81712d6d ffff88003e9bb980 ffff88009fc1e540
> [ 170.576938] Call Trace:
> [ 170.576938] [<ffffffff8112899f>] ? check_poison_obj+0x1df/0x1f0
> [ 170.576938] [<ffffffff813047d0>] ? acpi_ut_create_generic_state+0x2f/0x4c
> [ 170.576938] [<ffffffff813047d0>] ? acpi_ut_create_generic_state+0x2f/0x4c
> [ 170.576938] [<ffffffff81128a9d>] ? cache_alloc_debugcheck_after.isra.52+0xed/0x220
> [ 170.576938] [<ffffffff813047d0>] ? acpi_ut_create_generic_state+0x2f/0x4c
> [ 170.576938] [<ffffffff8112beb5>] ? kmem_cache_alloc+0xb5/0x1e0
> [ 170.576938] [<ffffffff813047d0>] ? acpi_ut_create_generic_state+0x2f/0x4c
> [ 170.576938] [<ffffffff812edf2d>] ? acpi_ds_result_push+0x5d/0x12e
> [ 170.576938] [<ffffffff812ed127>] ? acpi_ds_exec_end_op+0x28e/0x3d3
> [ 170.576938] [<ffffffff812fd86a>] ? acpi_ps_parse_loop+0x79f/0x931
> [ 170.576938] [<ffffffff812fdd6c>] ? acpi_ps_parse_aml+0x89/0x261
> [ 170.576938] [<ffffffff812fe50c>] ? acpi_ps_execute_method+0x1be/0x266
> [ 170.576938] [<ffffffff812f91f7>] ? acpi_ns_evaluate+0xd3/0x19a
> [ 170.576938] [<ffffffff812fb93e>] ? acpi_evaluate_object+0xf3/0x1f4
> [ 170.576938] [<ffffffff812e1104>] ? acpi_os_wait_events_complete+0x1b/0x1b
> [ 170.576938] [<ffffffff812e4782>] ? acpi_bus_hot_remove_device+0xeb/0x123
> [ 170.576938] [<ffffffff812e1121>] ? acpi_os_execute_deferred+0x1d/0x29
> [ 170.576938] [<ffffffff81058ec5>] ? process_one_work+0x125/0x560
> [ 170.576938] [<ffffffff81059e7a>] ? worker_thread+0x16a/0x4e0
> [ 170.576938] [<ffffffff81059d10>] ? manage_workers+0x310/0x310
> [ 170.576938] [<ffffffff8105e6c5>] ? kthread+0x85/0x90
> [ 170.576938] [<ffffffff814eb2c4>] ? kernel_thread_helper+0x4/0x10
> [ 170.576938] [<ffffffff8105e640>] ? flush_kthread_worker+0xa0/0xa0
> [ 170.576938] [<ffffffff814eb2c0>] ? gs_change+0x13/0x13
> [ 170.576938] Code: cb 75 dc 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 8b 7f 0c 4c 89 e2 e8 02 fd ff ff 4c 89 e6 49 89 c5 48 89 ef e8 d4 fc ff ff <49> 8b 55 00 48 8b 30 48 c7 c7 8c 39 6f 81 31 c0 e8 3e 34 3b 00
>
> Other times, the problem happens on a slab object free:
>
> [ 52.313366] Offlined Pages 32768
> [ 52.800232] slab error in verify_redzone_free(): cache `Acpi-ParseExt': memory outside object was overwritten
> [ 52.801298] Pid: 29, comm: kworker/0:1 Not tainted 3.6.0-rc7-guest #12
> [ 52.802039] Call Trace:
> [ 52.802443] [<ffffffff811280cb>] ? __slab_error.isra.46+0x1b/0x30
> [ 52.803199] [<ffffffff811287b6>] ? cache_free_debugcheck+0x256/0x260
> [ 52.803940] [<ffffffff812e1b0e>] ? acpi_os_release_object+0x7/0xc
> [ 52.804645] [<ffffffff81128fe3>] ? kmem_cache_free+0x63/0x260
> [ 52.805321] [<ffffffff812e1b0e>] ? acpi_os_release_object+0x7/0xc
> [ 52.806023] [<ffffffff812fe298>] ? acpi_ps_delete_parse_tree+0x34/0x58
> [ 52.806762] [<ffffffff812fe517>] ? acpi_ps_execute_method+0x1c9/0x266
> [ 52.807499] [<ffffffff812f91f7>] ? acpi_ns_evaluate+0xd3/0x19a
> [ 52.808183] [<ffffffff812fb93e>] ? acpi_evaluate_object+0xf3/0x1f4
> [ 52.808897] [<ffffffff812e1104>] ? acpi_os_wait_events_complete+0x1b/0x1b
> [ 52.809659] [<ffffffff812e4782>] ? acpi_bus_hot_remove_device+0xeb/0x123
> [ 52.810032] [<ffffffff812e1121>] ? acpi_os_execute_deferred+0x1d/0x29
> [ 52.810032] [<ffffffff81058ec5>] ? process_one_work+0x125/0x560
> [ 52.810032] [<ffffffff81059e7a>] ? worker_thread+0x16a/0x4e0
> [ 52.810032] [<ffffffff81059d10>] ? manage_workers+0x310/0x310
> [ 52.810032] [<ffffffff8105e6c5>] ? kthread+0x85/0x90
> [ 52.810032] [<ffffffff814eb2c4>] ? kernel_thread_helper+0x4/0x10
> [ 52.810032] [<ffffffff8105e640>] ? flush_kthread_worker+0xa0/0xa0
> [ 52.810032] [<ffffffff814eb2c0>] ? gs_change+0x13/0x13
> [ 52.810032] ffff88008f809670: redzone 1:0x0, redzone 2:0x0.
> [ 52.810032] ------------[ cut here ]------------
> [ 52.810032] kernel BUG at mm/slab.c:3125!
> [ 52.810032] invalid opcode: 0000 [#1] SMP
> [ 52.810032] Modules linked in: netconsole acpiphp pci_hotplug acpi_memhotplug loop kvm_amd kvm tpm_tis tpm tpm_bios microcode parport_pc parport evdev processor thermal_sys psmouse i2c_piix4 serio_raw i2c_core button ext3 jbd mbcache sg sr_mod cdrom virtio_net ata_generic virtio_blk virtio_pci virtio_ring virtio ata_piix libata scsi_mod
> [ 52.810032] CPU 0
> [ 52.810032] Pid: 29, comm: kworker/0:1 Not tainted 3.6.0-rc7-guest #12 Bochs Bochs
> [ 52.810032] RIP: 0010:[<ffffffff81128733>] [<ffffffff81128733>] cache_free_debugcheck+0x1d3/0x260
> [ 52.810032] RSP: 0018:ffff88003eaf3bc0 EFLAGS: 00010093
> [ 52.810032] RAX: 00000000017eac3c RBX: ffff88003e9bb700 RCX: 0000000002aaaaab
> [ 52.810032] RDX: 0000000000000000 RSI: 0000000000010000 RDI: 0000000000000060
> [ 52.810032] RBP: ffff88008f809670 R08: 09f911029d74e35b R09: 0000000000000000
> [ 52.810032] R10: 00000000000001d3 R11: 0000000000000002 R12: ffff88008f809000
> [ 52.810032] R13: ffffffff812e1b0e R14: 0000000000000000 R15: 0000000000010c00
> [ 52.810032] FS: 00007f63fc263700(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
> [ 52.810032] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 52.810032] CR2: 00007fff8d895b78 CR3: 000000007c866000 CR4: 00000000000006f0
> [ 52.810032] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 52.810032] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 52.810032] Process kworker/0:1 (pid: 29, threadinfo ffff88003eaf2000, task ffff88003ea941c0)
> [ 52.810032] Stack:
> [ 52.810032] ffff88003e9bb980 ffff88008f809670 ffff880037ba8e18 ffff88008f809678
> [ 52.810032] ffff88003e9bb700 0000000000000282 ffff88003e9bf270 ffffffff812e1b0e
> [ 52.810032] 0000000000000001 ffffffff81128fe3 ffff88003e80f5e8 ffff88003eb31748
> [ 52.810032] Call Trace:
> [ 52.810032] [<ffffffff812e1b0e>] ? acpi_os_release_object+0x7/0xc
> [ 52.810032] [<ffffffff81128fe3>] ? kmem_cache_free+0x63/0x260
> [ 52.810032] [<ffffffff812e1b0e>] ? acpi_os_release_object+0x7/0xc
> [ 52.810032] [<ffffffff812fe298>] ? acpi_ps_delete_parse_tree+0x34/0x58
> [ 52.810032] [<ffffffff812fe517>] ? acpi_ps_execute_method+0x1c9/0x266
> [ 52.810032] [<ffffffff812f91f7>] ? acpi_ns_evaluate+0xd3/0x19a
> [ 52.810032] [<ffffffff812fb93e>] ? acpi_evaluate_object+0xf3/0x1f4
> [ 52.810032] [<ffffffff812e1104>] ? acpi_os_wait_events_complete+0x1b/0x1b
> [ 52.810032] [<ffffffff812e4782>] ? acpi_bus_hot_remove_device+0xeb/0x123
> [ 52.810032] [<ffffffff812e1121>] ? acpi_os_execute_deferred+0x1d/0x29
> [ 52.810032] [<ffffffff81058ec5>] ? process_one_work+0x125/0x560
> [ 52.810032] [<ffffffff81059e7a>] ? worker_thread+0x16a/0x4e0
> [ 52.810032] [<ffffffff81059d10>] ? manage_workers+0x310/0x310
> [ 52.810032] [<ffffffff8105e6c5>] ? kthread+0x85/0x90
> [ 52.810032] [<ffffffff814eb2c4>] ? kernel_thread_helper+0x4/0x10
> [ 52.810032] [<ffffffff8105e640>] ? flush_kthread_worker+0xa0/0xa0
> [ 52.810032] [<ffffffff814eb2c0>] ? gs_change+0x13/0x13
> [ 52.810032] Code: 89 ea 49 89 38 8b 73 14 8b 7b 0c e8 18 f6 ff ff 49 b8 5b e3 74 9d 02 11 f9 09 4c 89 00 44 8b 7b 14 44 89 f8 e9 fa fe ff ff 0f 0b <0f> 0b 48 8b 40 30 e9 d9 fe ff ff e8 c6 43 3b 00 0f 0b 48 8b 40
> [ 52.810032] RIP [<ffffffff81128733>] cache_free_debugcheck+0x1d3/0x260
> [ 52.810032] RSP <ffff88003eaf3bc0>
> [ 52.810032] ---[ end trace c699c8cecd5870a3 ]---
>
>
> And other times, I see a filesystem related slab corruption when doing the eject.
> Here I have also seen a bad rss-counter state message.
>
> [ 232.114232] BUG: Bad rss-counter state mm:ffff88007d9c1f80 idx:0 val:1
> [ 232.115214] BUG: unable to handle kernel NULL pointer dereference at (null)
> [ 232.115807] IP: [<ffffffffa00cfce3>] do_get_write_access+0x43/0x480 [jbd]
> [ 232.116186] PGD 7cdec067 PUD 7c946067 PMD 0
> [ 232.116627] Oops: 0000 [#3] SMP
> [ 232.116990] Modules linked in: netconsole acpiphp pci_hotplug acpi_memhotplug loop kvm_amd kvm microcode tpm_tis tpm tpm_bios evdev psmouse serio_raw i2c_piix4 i2c_core parport_pc parport processor thermal_sys button ext3 jbd mbcache virtio_net sg sr_mod cdrom virtio_blk ata_generic virtio_pci virtio_ring virtio ata_piix libata scsi_mod
> [ 232.120013] CPU 2
> [ 232.120013] Pid: 880, comm: dhclient Tainted: G D 3.6.0-rc7-guest #1 Bochs Bochs
> [ 232.120013] RIP: 0010:[<ffffffffa00cfce3>] [<ffffffffa00cfce3>] do_get_write_access+0x43/0x480 [jbd]
> [ 232.120013] RSP: 0018:ffff88007cd6fab8 EFLAGS: 00010246
> [ 232.120013] RAX: ffff88003e513f50 RBX: ffff88003e513f50 RCX: 0000000000000000
> [ 232.120013] RDX: 0000000000000000 RSI: ffff88003e513f50 RDI: ffff880097800000
> [ 232.120013] RBP: ffff88003e513f50 R08: 000000003e513f01 R09: 0000000180240024
> [ 232.120013] R10: ffff88003e513f50 R11: 00000000000198e0 R12: 0000000000000000
> [ 232.120013] R13: ffffffffa00eb437 R14: ffff880097800000 R15: 000000000000027a
> [ 232.120013] FS: 00007f082638d700(0000) GS:ffff88003ec80000(0000) knlGS:0000000000000000
> [ 232.120013] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 232.120013] CR2: 0000000000000000 CR3: 000000007c94c000 CR4: 00000000000006e0
> [ 232.120013] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 232.120013] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 232.120013] Process dhclient (pid: 880, threadinfo ffff88007cd6e000, task ffff88007ca46800)
> [ 232.120013] Stack:
> [ 232.120013] ffff88007dc205b0 ffffffff8116645f ffff88007dc205b0 ffff88007dc205b0
> [ 232.120013] ffff88007cf58800 0000000000000000 000000000000000e 0000000000000000
> [ 232.120013] 000000000000027a ffffffff8112b934 0000005000000003 0000000000000fff
> [ 232.120013] Call Trace:
> [ 232.120013] [<ffffffff8116645f>] ? __find_get_block+0x7f/0x200
> [ 232.120013] [<ffffffff8112b934>] ? kmem_cache_alloc+0xe4/0x140
> [ 232.120013] [<ffffffffa00eb437>] ? ext3_dirty_inode+0x57/0xb0 [ext3]
> [ 232.120013] [<ffffffffa00d0279>] ? journal_get_write_access+0x29/0x50 [jbd]
> [ 232.120013] [<ffffffffa00eaeef>] ? __ext3_get_inode_loc+0xcf/0x360 [ext3]
> [ 232.120013] [<ffffffffa0101317>] ? __ext3_journal_get_write_access+0x27/0x60 [ext3]
> [ 232.120013] [<ffffffffa00eb213>] ? ext3_reserve_inode_write+0x73/0xa0 [ext3]
> [ 232.120013] [<ffffffffa00eb27b>] ? ext3_mark_inode_dirty+0x3b/0xa0 [ext3]
> [ 232.120013] [<ffffffffa00eb437>] ? ext3_dirty_inode+0x57/0xb0 [ext3]
> [ 232.120013] [<ffffffff8115ded6>] ? __mark_inode_dirty+0x36/0x230
> [ 232.120013] [<ffffffff811504a1>] ? update_time+0x71/0xb0
> [ 232.120013] [<ffffffff811536c9>] ? mnt_clone_write+0x9/0x20
> [ 232.120013] [<ffffffff81150581>] ? file_update_time+0xa1/0xf0
> [ 232.120013] [<ffffffff8103385c>] ? ptep_set_access_flags+0x6c/0x70
> [ 232.120013] [<ffffffff810e3f30>] ? __generic_file_aio_write+0x1a0/0x3c0
> [ 232.120013] [<ffffffff811396fb>] ? __sb_start_write+0x6b/0x130
> [ 232.120013] [<ffffffff810e41ce>] ? generic_file_aio_write+0x7e/0x100
> [ 232.120013] [<ffffffff81137484>] ? do_sync_write+0x94/0xd0
> [ 232.120013] [<ffffffff81137caa>] ? vfs_write+0xaa/0x160
> [ 232.120013] [<ffffffff81137f87>] ? sys_write+0x47/0x90
> [ 232.120013] [<ffffffff814e5765>] ? async_page_fault+0x25/0x30
> [ 232.120013] [<ffffffff814eca79>] ? system_call_fastpath+0x16/0x1b
> [ 232.120013] Code: 54 24 2c f6 47 14 04 74 1f 41 bc e2 ff ff ff 48 81 c4 98 00 00 00 44 89 e0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f 1f 40 00 4c 8b 27 <4d> 8b 3c 24 41 f6 07 02 75 d4 65 48 8b 04 25 80 b9 00 00 48 89
>
> Is this a known issue? If yes, can you point me to any relevant patches?
>
> When I do an SCI(hardware) eject, I have not seen corruptions. The acpi driver is
> evaluating fewer objects in this path I think, but I don't see why corruption can't
> happen here as well.
>
> I have seen similar problems with CONFIG_SLUB (I did not have debug_options
> there but I can also provide those if helpful)
>
> [1] https://lkml.org/lkml/2012/9/6/635
> [2] https://lkml.org/lkml/2012/9/11/542
> [3] https://lkml.org/lkml/2012/9/20/37
> [4] http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/98691
>
> thanks,
>
> - Vasilis
>
^ permalink raw reply
* Re: net: fix typo in freescale/ucc_geth.c
From: Eric Dumazet @ 2012-10-09 6:04 UTC (permalink / raw)
To: Michael Neuling
Cc: Stephen Rothwell, LKML, linuxppc-dev, Eric Dumazet, linux-next,
Maxime Bizon, David S. Miller
In-Reply-To: <23452.1349740345@neuling.org>
On Tue, 2012-10-09 at 10:52 +1100, Michael Neuling wrote:
> The following patch:
> acb600d net: remove skb recycling
> added dev_free_skb() to drivers/net/ethernet/freescale/ucc_geth.c
>
> This is a typo and should be dev_kfree_skb(). This fixes this.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> ---
> This hit as a compile error in next-20121008 with mpc85xx_defconfig.
>
> diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
> index dfa0aaa..0a70bb5 100644
> --- a/drivers/net/ethernet/freescale/ucc_geth.c
> +++ b/drivers/net/ethernet/freescale/ucc_geth.c
> @@ -3268,7 +3268,7 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
> if (netif_msg_rx_err(ugeth))
> ugeth_err("%s, %d: ERROR!!! skb - 0x%08x",
> __func__, __LINE__, (u32) skb);
> - dev_free_skb(skb);
> + dev_kfree_skb(skb);
>
> ugeth->rx_skbuff[rxQ][ugeth->skb_currx[rxQ]] = NULL;
>
Oops, thanks Michael !
^ permalink raw reply
* Re: net: fix typo in freescale/ucc_geth.c
From: David Miller @ 2012-10-09 4:21 UTC (permalink / raw)
To: mikey; +Cc: sfr, linux-kernel, linuxppc-dev, edumazet, linux-next, mbizon
In-Reply-To: <23452.1349740345@neuling.org>
From: Michael Neuling <mikey@neuling.org>
Date: Tue, 09 Oct 2012 10:52:25 +1100
> The following patch:
> acb600d net: remove skb recycling
> added dev_free_skb() to drivers/net/ethernet/freescale/ucc_geth.c
>
> This is a typo and should be dev_kfree_skb(). This fixes this.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
Applied, thanks a lot.
^ permalink raw reply
* Re: memory-hotplug : suppres "Trying to free nonexistent resource <XXXXXXXXXXXXXXXX-YYYYYYYYYYYYYYYY>" warning
From: Yasuaki Ishimatsu @ 2012-10-09 2:51 UTC (permalink / raw)
To: Andrew Morton
Cc: len.brown, wency, linux-acpi, x86, linux-kernel, dave, linux-mm,
paulus, minchan.kim, kosaki.motohiro, rientjes, cl, linuxppc-dev,
liuj97
In-Reply-To: <20121005140938.e3e1e196.akpm@linux-foundation.org>
Hi Andrew,
2012/10/06 6:09, Andrew Morton wrote:
> On Thu, 4 Oct 2012 14:31:09 +0900
> Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> wrote:
>
>> When our x86 box calls __remove_pages(), release_mem_region() shows
>> many warnings. And x86 box cannot unregister iomem_resource.
>>
>> "Trying to free nonexistent resource <XXXXXXXXXXXXXXXX-YYYYYYYYYYYYYYYY>"
>>
>> release_mem_region() has been changed as called in each PAGES_PER_SECTION
>> chunk since applying a patch(de7f0cba96786c). Because powerpc registers
>> iomem_resource in each PAGES_PER_SECTION chunk. But when I hot add memory
>> on x86 box, iomem_resource is register in each _CRS not PAGES_PER_SECTION
>> chunk. So x86 box unregisters iomem_resource.
>>
>> The patch fixes the problem.
>>
>> --- linux-3.6.orig/arch/powerpc/platforms/pseries/hotplug-memory.c 2012-10-04 14:22:59.833520792 +0900
>> +++ linux-3.6/arch/powerpc/platforms/pseries/hotplug-memory.c 2012-10-04 14:23:05.150521411 +0900
>> @@ -77,7 +77,8 @@ static int pseries_remove_memblock(unsig
>> {
>> unsigned long start, start_pfn;
>> struct zone *zone;
>> - int ret;
>> + int i, ret;
>> + int sections_to_remove;
>>
>> start_pfn = base >> PAGE_SHIFT;
>>
>> @@ -97,9 +98,13 @@ static int pseries_remove_memblock(unsig
>> * to sysfs "state" file and we can't remove sysfs entries
>> * while writing to it. So we have to defer it to here.
>> */
>> - ret = __remove_pages(zone, start_pfn, memblock_size >> PAGE_SHIFT);
>> - if (ret)
>> - return ret;
>> + sections_to_remove = (memblock_size >> PAGE_SHIFT) / PAGES_PER_SECTION;
>> + for (i = 0; i < sections_to_remove; i++) {
>> + unsigned long pfn = start_pfn + i * PAGES_PER_SECTION;
>> + ret = __remove_pages(zone, start_pfn, PAGES_PER_SECTION);
>> + if (ret)
>> + return ret;
>> + }
>
> It is inappropriate that `i' have a signed 32-bit type. I doubt if
> there's any possibility of an overflow bug here, but using a consistent
> and well-chosen type would eliminate all doubt.
>
> Note that __remove_pages() does use an unsigned long for this, although
> it stupidly calls that variable "i", despite the C programmers'
> expectation that a variable called "i" has type "int".
>
> The same applies to `sections_to_remove', but __remove_pages() went and
> decided to use an `int' for that variable. Sigh.
>
> Anyway, please have a think, and see if we can come up with the best
> and most accurate choice of types and identifiers in this code.
Your concern is right. Overflow bug may occur in the future.
So I changed type of "i" and "sections_to_remove" to "unsigned long".
Please merge it into your tree instead of previous patch.
__remove_pages() also has same concern. So I'll fix it.
-----------------------------------------------------------------------
When our x86 box calls __remove_pages(), release_mem_region() shows
many warnings. And x86 box cannot unregister iomem_resource.
"Trying to free nonexistent resource <XXXXXXXXXXXXXXXX-YYYYYYYYYYYYYYYY>"
release_mem_region() has been changed as called in each PAGES_PER_SECTION
chunk since applying a patch(de7f0cba96786c). Because powerpc registers
iomem_resource in each PAGES_PER_SECTION chunk. But when I hot add memory
on x86 box, iomem_resource is register in each _CRS not PAGES_PER_SECTION
chunk. So x86 box unregisters iomem_resource.
The patch fixes the problem.
CC: David Rientjes <rientjes@google.com>
CC: Jiang Liu <liuj97@gmail.com>
CC: Len Brown <len.brown@intel.com>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Paul Mackerras <paulus@samba.org>
CC: Christoph Lameter <cl@linux.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
CC: Wen Congyang <wency@cn.fujitsu.com>
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 11 ++++++++---
mm/memory_hotplug.c | 4 ++--
2 files changed, 10 insertions(+), 5 deletions(-)
Index: linux-3.6/arch/powerpc/platforms/pseries/hotplug-memory.c
===================================================================
--- linux-3.6.orig/arch/powerpc/platforms/pseries/hotplug-memory.c 2012-10-05 14:33:09.516197839 +0900
+++ linux-3.6/arch/powerpc/platforms/pseries/hotplug-memory.c 2012-10-09 11:27:50.555709827 +0900
@@ -78,6 +78,7 @@ static int pseries_remove_memblock(unsig
unsigned long start, start_pfn;
struct zone *zone;
int ret;
+ unsigned long i, sections_to_remove;
start_pfn = base >> PAGE_SHIFT;
@@ -97,9 +98,13 @@ static int pseries_remove_memblock(unsig
* to sysfs "state" file and we can't remove sysfs entries
* while writing to it. So we have to defer it to here.
*/
- ret = __remove_pages(zone, start_pfn, memblock_size >> PAGE_SHIFT);
- if (ret)
- return ret;
+ sections_to_remove = (memblock_size >> PAGE_SHIFT) / PAGES_PER_SECTION;
+ for (i = 0; i < sections_to_remove; i++) {
+ unsigned long pfn = start_pfn + i * PAGES_PER_SECTION;
+ ret = __remove_pages(zone, start_pfn, PAGES_PER_SECTION);
+ if (ret)
+ return ret;
+ }
/*
* Update memory regions for memory remove
Index: linux-3.6/mm/memory_hotplug.c
===================================================================
--- linux-3.6.orig/mm/memory_hotplug.c 2012-10-05 15:21:42.856325965 +0900
+++ linux-3.6/mm/memory_hotplug.c 2012-10-05 15:21:43.047326148 +0900
@@ -596,11 +596,11 @@ int __remove_pages(struct zone *zone, un
BUG_ON(phys_start_pfn & ~PAGE_SECTION_MASK);
BUG_ON(nr_pages % PAGES_PER_SECTION);
+ release_mem_region(phys_start_pfn << PAGE_SHIFT, nr_pages * PAGE_SIZE);
+
sections_to_remove = nr_pages / PAGES_PER_SECTION;
for (i = 0; i < sections_to_remove; i++) {
unsigned long pfn = phys_start_pfn + i*PAGES_PER_SECTION;
- release_mem_region(pfn << PAGE_SHIFT,
- PAGES_PER_SECTION << PAGE_SHIFT);
ret = __remove_section(zone, __pfn_to_section(pfn));
if (ret)
break;
^ permalink raw reply
* Re: [PATCH 0/5] Move some OF functionality from pseries to generic OF code
From: Michael Ellerman @ 2012-10-08 23:54 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: cbe-oss-dev, devicetree-discuss, linuxppc-dev, LKML
In-Reply-To: <506B2E63.5090900@linux.vnet.ibm.com>
On Tue, 2012-10-02 at 13:11 -0500, Nathan Fontenot wrote:
> This set of patches moves some OF code that has been living
> in the pseries tree over to the generic OF code base. The
> functionality being migrated over is something that, I believe,
> should live in the generic code base. The specific functionality
> being migrated to generic OF code is;
Your changes collide with commit 475d0094293:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=475d0094293b51353e342d1198377967dbc48169
At a quick glance they don't look like they conflict in concept, just
textually.
cheers
^ permalink raw reply
* net: fix typo in freescale/ucc_geth.c
From: Michael Neuling @ 2012-10-08 23:52 UTC (permalink / raw)
To: Eric Dumazet
Cc: Stephen Rothwell, LKML, linuxppc-dev, linux-next, Maxime Bizon,
David S. Miller
In-Reply-To: <20121008173653.1d17895964980c98af59c8ea@canb.auug.org.au>
The following patch:
acb600d net: remove skb recycling
added dev_free_skb() to drivers/net/ethernet/freescale/ucc_geth.c
This is a typo and should be dev_kfree_skb(). This fixes this.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
This hit as a compile error in next-20121008 with mpc85xx_defconfig.
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
index dfa0aaa..0a70bb5 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -3268,7 +3268,7 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
if (netif_msg_rx_err(ugeth))
ugeth_err("%s, %d: ERROR!!! skb - 0x%08x",
__func__, __LINE__, (u32) skb);
- dev_free_skb(skb);
+ dev_kfree_skb(skb);
ugeth->rx_skbuff[rxQ][ugeth->skb_currx[rxQ]] = NULL;
dev->stats.rx_dropped++;
^ permalink raw reply related
* [PATCH] powerpc/usb: fix build warning
From: Kim Phillips @ 2012-10-08 21:47 UTC (permalink / raw)
To: linuxppc-dev, linux-usb; +Cc: Shengzhou Liu
commit 3735ba8db8e6ea22ad3ff524328926d8d780a884 "powerpc/usb: fix bug of
CPU hang when missing USB PHY clock" introduced a new build warning:
In file included from linux/drivers/usb/host/ehci-hcd.c:1208:0:
linux/drivers/usb/host/ehci-fsl.c: In function 'ehci_fsl_setup_phy':
linux/drivers/usb/host/ehci-fsl.c:225:3: warning: 'return' with no value, in function returning non-void [-Wreturn-type]
this fixes it.
Cc: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
drivers/usb/host/ehci-fsl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 9bfde82..968f751 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -222,7 +222,7 @@ static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
if (pdata->controller_ver < 0) {
dev_warn(hcd->self.controller, "Could not get controller version\n");
- return;
+ return -EINVAL;
}
portsc = ehci_readl(ehci, &ehci->regs->port_status[port_offset]);
--
1.7.12.2
^ permalink raw reply related
* Re: [RFC PATCH] powerpc/fsl: add timer wakeup source
From: Scott Wood @ 2012-10-08 20:55 UTC (permalink / raw)
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421, Li Yang-R58472, linux-pm@vger.kernel.org,
Wang Dongsheng, linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <ABB05CD9C9F68C46A5CEDC7F15439259DF1A14@039-SN2MPN1-021.039d.mgd.msft.net>
On 10/08/2012 02:13:26 AM, Wang Dongsheng-B40534 wrote:
>=20
>=20
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Thursday, October 04, 2012 6:20 AM
> > To: Kumar Gala
> > Cc: Wang Dongsheng; Wood Scott-B07421; =20
> linuxppc-dev@lists.ozlabs.org list;
> > Wang Dongsheng-B40534; Li Yang-R58472; linux-pm@vger.kernel.org
> > Subject: Re: [RFC PATCH] powerpc/fsl: add timer wakeup source
> >
> > On 10/03/2012 08:35:58 AM, Kumar Gala wrote:
> > >
> > > On Oct 3, 2012, at 5:42 AM, Wang Dongsheng wrote:
> > >
> > > > This is only for freescale powerpc platform. The driver =20
> provides a
> > > way
> > > > to wake up system. Proc
> > > interface(/proc/powerpc/wakeup_timer_seconds).
> > > >
> > > > eg: "echo 5 > /proc/powerpc/wakeup_timer_seconds", 5 seconds =20
> after
> > > > the system will be woken up. echo another time into proc
> > > interface
> > > > to update the time.
> > > >
> > > > Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
> > > > Signed-off-by: Li Yang <leoli@freescale.com>
> > > > ---
> > > > arch/powerpc/platforms/Kconfig | 23 +++
> > > > arch/powerpc/platforms/Makefile | 1 +
> > > > arch/powerpc/platforms/fsl_timer_wakeup.c | 217
> > > +++++++++++++++++++++++++++++
> > > > 3 files changed, 241 insertions(+)
> > > > create mode 100644 arch/powerpc/platforms/fsl_timer_wakeup.c
> > >
> > > Adding the Linux PM list to see if there is some existing support =20
> for
> > > this on other arch's in kernel.
> > >
> > > I'm pretty sure /proc/ is NOT where we want this exposed.
> >
> > Should probably go under the sysfs directory of the mpic device. Or
> > better, make a generic interface for timer-based suspend wakeup (if =20
> there
> > isn't one already). This current approach sits in an unpleasant =20
> middle
> > ground between generic and device-specific.
> > =09
> /sys/power/wakeup_timer_seconds how about this?
> I think it is a freescale generic interface, this interface control by
> FSL_SOC && SUSPEND.
There's no such thing as a "Freescale generic interface". Linux APIs =20
are not organized by hardware vendor. Either make a truly generic =20
interface, reuse an existing one, or do something that is attached to =20
the specific driver.
> > > > diff --git a/arch/powerpc/platforms/Kconfig
> > > b/arch/powerpc/platforms/Kconfig
> > > > index b190a6e..7b9232a 100644
> > > > --- a/arch/powerpc/platforms/Kconfig
> > > > +++ b/arch/powerpc/platforms/Kconfig
> > > > @@ -99,6 +99,29 @@ config MPIC_TIMER
> > > > only tested on fsl chip, but it can potentially =20
> support
> > > > other global timers complying to Open-PIC standard.
> > > >
> > > > +menuconfig FSL_WAKEUP_SOURCE
> > > > + bool "Freescale wakeup source"
> > > > + depends on FSL_SOC && SUSPEND
> > > > + default n
> > > > + help
> > > > + This option enables wakeup source for wake up system
> > > > + features. This is only for freescale powerpc platform.
> > > > +
> > > > +if FSL_WAKEUP_SOURCE
> > > > +
> > > > +config FSL_TIMER_WAKEUP
> > > > + tristate "Freescale mpic global timer wakeup event"
> > > > + default n
> > > > + help
> > > > + This is only for freescale powerpc platform. The =20
> driver
> > > > + provides a way to wake up system.
> > > > + Proc interface(/proc/powerpc/wakeup_timer_seconds).
> > > > + eg: "echo 5 > /proc/powerpc/wakeup_timer_seconds",
> > > > + 5 seconds after the system will be woken up. echo =20
> another
> > > > + time into proc interface to update the time.
> > > > +
> > > > +endif
> >
> > Use depends rather than if/else. Why do you need FSL_WAKEUP_SOURCE?
> >
> It lists all wake up source. If later have wakeup source can be =20
> improved by
> it to control. Buttons event wakeup source will be added after the =20
> timer.
It does not list all wake up sources -- there's also ethernet, USB, etc.
> > These names are overly broad -- this is only for FSL MPIC, not for =20
> other
> > FSL chips (e.g. mpc83xx has a different global timer =20
> implementation, and
> > there's FSL ARM chips, etc).
> >
> Yes, thanks. Change to FSL_MPIC_TIMER_WAKEUP.
>=20
> > > > +static ssize_t timer_wakeup_write(struct file *file, const char
> > > __user *buf,
> > > > + size_t count, loff_t *off)
> > > > +{
> > > > + struct fsl_timer_wakeup *priv;
> > > > + struct inode *inode =3D file->f_path.dentry->d_inode;
> > > > + struct proc_dir_entry *dp;
> > > > + struct timeval time;
> > > > + char *kbuf;
> > > > +
> > > > + dp =3D PDE(inode);
> > > > + priv =3D dp->data;
> > > > +
> > > > + kbuf =3D kzalloc(count + 1, GFP_KERNEL);
> > > > + if (!kbuf)
> > > > + return -ENOMEM;
> > > > +
> > > > + if (copy_from_user(kbuf, buf, count)) {
> > > > + kfree(kbuf);
> > > > + return -EFAULT;
> > > > + }
> > > > +
> > > > + kbuf[count] =3D '\0';
> > > > +
> > > > + if (kstrtol(kbuf, 0, &time.tv_sec)) {
> > > > + kfree(kbuf);
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > + kfree(kbuf);
> > > > +
> > > > + time.tv_usec =3D 0;
> > > > +
> > > > + mutex_lock(&priv->mutex);
> > > > +
> > > > + if (!time.tv_sec) {
> > > > + if (priv->timer) {
> > > > + mpic_free_timer(priv->timer);
> > > > + priv->timer =3D NULL;
> > > > + }
> > > > + mutex_unlock(&priv->mutex);
> > > > +
> > > > + return count;
> > > > + }
> > > > +
> > > > + if (priv->timer) {
> > > > + mpic_free_timer(priv->timer);
> > > > + priv->timer =3D NULL;
> > > > + }
> > > > +
> > > > + priv->timer =3D mpic_request_timer(timer_event_interrupt, =20
> priv,
> > > &time);
> >
> > If the new time is zero, consider that a cancellation of the timer =20
> and
> > don't request a new one or return -EINVAL.
> >
> Thanks, I think i should add comments. Let this patch easy to read.
> Here is get a new timer.
> If the new time is zero, consider that has been checked.
>=20
> if (!time.tv_sec) {...} this is check zero.
> The "mpic_request_timer" before this code.
Ah, I see. Wouldn't it be simpler to remove that block and just test =20
time.tv_sec when requesting the new timer?
-Scott=
^ permalink raw reply
* Re: [Qemu-ppc] [RFC PATCH 05/17] KVM: PPC: booke: Extend MAS2 EPN mask for 64-bit
From: Alexander Graf @ 2012-10-08 13:10 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008
Cc: qemu-ppc@nongnu.org, linuxppc-dev@lists.ozlabs.org,
kvm@vger.kernel.org, kvm-ppc@vger.kernel.org
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF20D198@039-SN2MPN1-012.039d.mgd.msft.net>
On 08.10.2012, at 15:06, Caraman Mihai Claudiu-B02008 wrote:
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf@suse.de]
>> Sent: Monday, October 08, 2012 1:11 PM
>> To: Caraman Mihai Claudiu-B02008
>> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
>> dev@lists.ozlabs.org; qemu-ppc@nongnu.org
>> Subject: Re: [Qemu-ppc] [RFC PATCH 05/17] KVM: PPC: booke: Extend =
MAS2
>> EPN mask for 64-bit
>>=20
>>=20
>> On 05.07.2012, at 13:14, Caraman Mihai Claudiu-B02008 wrote:
>>=20
>>>=20
>>>=20
>>>> -----Original Message-----
>>>> From: Alexander Graf [mailto:agraf@suse.de]
>>>> Sent: Wednesday, July 04, 2012 4:50 PM
>>>> To: Caraman Mihai Claudiu-B02008
>>>> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
>>>> dev@lists.ozlabs.org; qemu-ppc@nongnu.org
>>>> Subject: Re: [Qemu-ppc] [RFC PATCH 05/17] KVM: PPC: booke: Extend =
MAS2
>>>> EPN mask for 64-bit
>>>>=20
>>>>=20
>>>> On 25.06.2012, at 14:26, Mihai Caraman wrote:
>>>>=20
>>>>> Extend MAS2 EPN mask for 64-bit hosts, to retain most significant
>> bits.
>>>>> Change get tlb eaddr to use this mask.
>>>>=20
>>>> Please see section 6.11.4.8 in the PowerISA 2.06b:
>>>>=20
>>>> MMU behavior is largely unaffected by whether the thread is in =
32-bit
>>>> computation mode (MSRCM=3D0) or 64- bit computation mode (MSRCM=3D1).=
The
>>>> only differ- ences occur in the EPN field of the TLB entry and the =
EPN
>>>> field of MAS2. The differences are summarized here.
>>>>=20
>>>> * Executing a tlbwe instruction in 32-bit mode will set bits =
0:31
>>>> of the TLB EPN field to zero unless MAS0ATSEL is set, in which case
>> those
>>>> bits are not written to zero.
>>>> * In 32-bit implementations, MAS2U can be used to read or write
>>>> EPN0:31 of MAS2.
>>>>=20
>>>> So if MSR.CM is not set tlbwe should mask the upper 32 bits out -
>> which
>>>> can happen regardless of CONFIG_64BIT.
>>>=20
>>> MAS2_EPN reflects EPN field of MAS2 aka bits 0:51 (for MAV =3D 1.0)
>> according
>>> to section 6.10.3.10 in the PowerISA 2.06b.
>>>=20
>>> MAS2_EPN is not used in tlbwe execution emulation, we have MAS2_VAL
>> define
>>> for this case.
>>=20
>> So tlbe->mas2 is guaranteed to have the upper bits be 0 when =
MSR.CM=3D0?
>=20
> We chose to mask out mas2 upper bits on tlbwe emulation so gtlbe->mas2 =
will
> respect this but vcpu->arch.shared->mas2 will not. tlb entry selection =
does not
> require this treatment since EPN upper bits are not taken into =
consideration anyway.
That's fine. We don't control the contents of shared->mas2 anyway.
>=20
>>=20
>>>=20
>>>> Also, we need to implement MAS2U, to potentially make the upper =
32bits
>> of
>>>> MAS2 available, right? But that one isn't as important as the first
>> bit.
>>>=20
>>> MAS2U is guest privileged why does it need special care?
>>=20
>> Maybe it's mapped to the upper bits of GMAS2 automatically?
>=20
> GMAS2?
Ah. The guest has direct control over the real MAS2. Oh well.
>=20
>>=20
>>> Freescale core Manuals and EREF does not mention MAS2U so I think I =
our
>> case
>>> it is not implemented.
>>=20
>> Please check with a simple mfspr() test on real hw to see if it =
really
>> isn't implemented.
>=20
> I will try this with SPR number 0x277.
Thanks :)
Alex
^ permalink raw reply
* RE: [Qemu-ppc] [RFC PATCH 05/17] KVM: PPC: booke: Extend MAS2 EPN mask for 64-bit
From: Caraman Mihai Claudiu-B02008 @ 2012-10-08 13:06 UTC (permalink / raw)
To: Alexander Graf
Cc: qemu-ppc@nongnu.org, linuxppc-dev@lists.ozlabs.org,
kvm@vger.kernel.org, kvm-ppc@vger.kernel.org
In-Reply-To: <0A87124F-B5D0-475C-A33C-A1F36C1B56D9@suse.de>
> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Monday, October 08, 2012 1:11 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org; qemu-ppc@nongnu.org
> Subject: Re: [Qemu-ppc] [RFC PATCH 05/17] KVM: PPC: booke: Extend MAS2
> EPN mask for 64-bit
>=20
>=20
> On 05.07.2012, at 13:14, Caraman Mihai Claudiu-B02008 wrote:
>=20
> >
> >
> >> -----Original Message-----
> >> From: Alexander Graf [mailto:agraf@suse.de]
> >> Sent: Wednesday, July 04, 2012 4:50 PM
> >> To: Caraman Mihai Claudiu-B02008
> >> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> >> dev@lists.ozlabs.org; qemu-ppc@nongnu.org
> >> Subject: Re: [Qemu-ppc] [RFC PATCH 05/17] KVM: PPC: booke: Extend MAS2
> >> EPN mask for 64-bit
> >>
> >>
> >> On 25.06.2012, at 14:26, Mihai Caraman wrote:
> >>
> >>> Extend MAS2 EPN mask for 64-bit hosts, to retain most significant
> bits.
> >>> Change get tlb eaddr to use this mask.
> >>
> >> Please see section 6.11.4.8 in the PowerISA 2.06b:
> >>
> >> MMU behavior is largely unaffected by whether the thread is in 32-bit
> >> computation mode (MSRCM=3D0) or 64- bit computation mode (MSRCM=3D1). =
The
> >> only differ- ences occur in the EPN field of the TLB entry and the EPN
> >> field of MAS2. The differences are summarized here.
> >>
> >> * Executing a tlbwe instruction in 32-bit mode will set bits 0:31
> >> of the TLB EPN field to zero unless MAS0ATSEL is set, in which case
> those
> >> bits are not written to zero.
> >> * In 32-bit implementations, MAS2U can be used to read or write
> >> EPN0:31 of MAS2.
> >>
> >> So if MSR.CM is not set tlbwe should mask the upper 32 bits out -
> which
> >> can happen regardless of CONFIG_64BIT.
> >
> > MAS2_EPN reflects EPN field of MAS2 aka bits 0:51 (for MAV =3D 1.0)
> according
> > to section 6.10.3.10 in the PowerISA 2.06b.
> >
> > MAS2_EPN is not used in tlbwe execution emulation, we have MAS2_VAL
> define
> > for this case.
>=20
> So tlbe->mas2 is guaranteed to have the upper bits be 0 when MSR.CM=3D0?
We chose to mask out mas2 upper bits on tlbwe emulation so gtlbe->mas2 will
respect this but vcpu->arch.shared->mas2 will not. tlb entry selection does=
not
require this treatment since EPN upper bits are not taken into consideratio=
n anyway.
>=20
> >
> >> Also, we need to implement MAS2U, to potentially make the upper 32bits
> of
> >> MAS2 available, right? But that one isn't as important as the first
> bit.
> >
> > MAS2U is guest privileged why does it need special care?
>=20
> Maybe it's mapped to the upper bits of GMAS2 automatically?
GMAS2?
>=20
> > Freescale core Manuals and EREF does not mention MAS2U so I think I our
> case
> > it is not implemented.
>=20
> Please check with a simple mfspr() test on real hw to see if it really
> isn't implemented.
I will try this with SPR number 0x277.
-Mike
^ permalink raw reply
* [PATCH] powerpc/windfarm: use module_i2c_driver to simplify the code
From: Wei Yongjun @ 2012-10-08 13:00 UTC (permalink / raw)
To: benh; +Cc: yongjun_wei, linuxppc-dev, linux-kernel
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Use the module_i2c_driver() macro to make the code smaller
and a bit simpler.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/macintosh/windfarm_smu_sat.c | 13 +------------
drivers/macintosh/windfarm_max6690_sensor.c | 13 +------------
drivers/macintosh/windfarm_lm75_sensor.c | 14 +-------------
drivers/macintosh/windfarm_fcu_controls.c | 14 +-------------
4 files changed, 4 insertions(+), 50 deletions(-)
diff --git a/drivers/macintosh/windfarm_smu_sat.c b/drivers/macintosh/windfarm_smu_sat.c
index 426e810..d87f5ee 100644
--- a/drivers/macintosh/windfarm_smu_sat.c
+++ b/drivers/macintosh/windfarm_smu_sat.c
@@ -364,18 +364,7 @@ static struct i2c_driver wf_sat_driver = {
.id_table = wf_sat_id,
};
-static int __init sat_sensors_init(void)
-{
- return i2c_add_driver(&wf_sat_driver);
-}
-
-static void __exit sat_sensors_exit(void)
-{
- i2c_del_driver(&wf_sat_driver);
-}
-
-module_init(sat_sensors_init);
-module_exit(sat_sensors_exit);
+module_i2c_driver(wf_sat_driver);
MODULE_AUTHOR("Paul Mackerras <paulus@samba.org>");
MODULE_DESCRIPTION("SMU satellite sensors for PowerMac thermal control");
diff --git a/drivers/macintosh/windfarm_max6690_sensor.c b/drivers/macintosh/windfarm_max6690_sensor.c
index 371b058..945a25b 100644
--- a/drivers/macintosh/windfarm_max6690_sensor.c
+++ b/drivers/macintosh/windfarm_max6690_sensor.c
@@ -130,18 +130,7 @@ static struct i2c_driver wf_max6690_driver = {
.id_table = wf_max6690_id,
};
-static int __init wf_max6690_sensor_init(void)
-{
- return i2c_add_driver(&wf_max6690_driver);
-}
-
-static void __exit wf_max6690_sensor_exit(void)
-{
- i2c_del_driver(&wf_max6690_driver);
-}
-
-module_init(wf_max6690_sensor_init);
-module_exit(wf_max6690_sensor_exit);
+module_i2c_driver(wf_max6690_driver);
MODULE_AUTHOR("Paul Mackerras <paulus@samba.org>");
MODULE_DESCRIPTION("MAX6690 sensor objects for PowerMac thermal control");
diff --git a/drivers/macintosh/windfarm_lm75_sensor.c b/drivers/macintosh/windfarm_lm75_sensor.c
index b0c2d36..9ef32b3 100644
--- a/drivers/macintosh/windfarm_lm75_sensor.c
+++ b/drivers/macintosh/windfarm_lm75_sensor.c
@@ -174,19 +174,7 @@ static struct i2c_driver wf_lm75_driver = {
.id_table = wf_lm75_id,
};
-static int __init wf_lm75_sensor_init(void)
-{
- return i2c_add_driver(&wf_lm75_driver);
-}
-
-static void __exit wf_lm75_sensor_exit(void)
-{
- i2c_del_driver(&wf_lm75_driver);
-}
-
-
-module_init(wf_lm75_sensor_init);
-module_exit(wf_lm75_sensor_exit);
+module_i2c_driver(wf_lm75_driver);
MODULE_AUTHOR("Benjamin Herrenschmidt <benh@kernel.crashing.org>");
MODULE_DESCRIPTION("LM75 sensor objects for PowerMacs thermal control");
diff --git a/drivers/macintosh/windfarm_fcu_controls.c b/drivers/macintosh/windfarm_fcu_controls.c
index b3411ed..fd6ed15 100644
--- a/drivers/macintosh/windfarm_fcu_controls.c
+++ b/drivers/macintosh/windfarm_fcu_controls.c
@@ -593,19 +593,7 @@ static struct i2c_driver wf_fcu_driver = {
.id_table = wf_fcu_id,
};
-static int __init wf_fcu_init(void)
-{
- return i2c_add_driver(&wf_fcu_driver);
-}
-
-static void __exit wf_fcu_exit(void)
-{
- i2c_del_driver(&wf_fcu_driver);
-}
-
-
-module_init(wf_fcu_init);
-module_exit(wf_fcu_exit);
+module_i2c_driver(wf_fcu_driver);
MODULE_AUTHOR("Benjamin Herrenschmidt <benh@kernel.crashing.org>");
MODULE_DESCRIPTION("FCU control objects for PowerMacs thermal control");
^ permalink raw reply related
* [PATCH] powerpc/83xx: use module_i2c_driver to simplify the code
From: Wei Yongjun @ 2012-10-08 12:39 UTC (permalink / raw)
To: galak, benh, paulus, grant.likely, rob.herring
Cc: yongjun_wei, linuxppc-dev, devicetree-discuss, linux-kernel
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Use the module_i2c_driver() macro to make the code smaller
and a bit simpler.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
index ef6537b..d91799e 100644
--- a/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
+++ b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
@@ -232,17 +232,7 @@ static struct i2c_driver mcu_driver = {
.id_table = mcu_ids,
};
-static int __init mcu_init(void)
-{
- return i2c_add_driver(&mcu_driver);
-}
-module_init(mcu_init);
-
-static void __exit mcu_exit(void)
-{
- i2c_del_driver(&mcu_driver);
-}
-module_exit(mcu_exit);
+module_i2c_driver(mcu_driver);
MODULE_DESCRIPTION("Power Management and GPIO expander driver for "
"MPC8349E-mITX-compatible MCU");
^ permalink raw reply related
* Re: [Qemu-ppc] [RFC PATCH 05/17] KVM: PPC: booke: Extend MAS2 EPN mask for 64-bit
From: Alexander Graf @ 2012-10-08 10:10 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008
Cc: qemu-ppc@nongnu.org, linuxppc-dev@lists.ozlabs.org,
kvm@vger.kernel.org, kvm-ppc@vger.kernel.org
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF15B15F@039-SN2MPN1-013.039d.mgd.msft.net>
On 05.07.2012, at 13:14, Caraman Mihai Claudiu-B02008 wrote:
>=20
>=20
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf@suse.de]
>> Sent: Wednesday, July 04, 2012 4:50 PM
>> To: Caraman Mihai Claudiu-B02008
>> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
>> dev@lists.ozlabs.org; qemu-ppc@nongnu.org
>> Subject: Re: [Qemu-ppc] [RFC PATCH 05/17] KVM: PPC: booke: Extend =
MAS2
>> EPN mask for 64-bit
>>=20
>>=20
>> On 25.06.2012, at 14:26, Mihai Caraman wrote:
>>=20
>>> Extend MAS2 EPN mask for 64-bit hosts, to retain most significant =
bits.
>>> Change get tlb eaddr to use this mask.
>>=20
>> Please see section 6.11.4.8 in the PowerISA 2.06b:
>>=20
>> MMU behavior is largely unaffected by whether the thread is in 32-bit
>> computation mode (MSRCM=3D0) or 64- bit computation mode (MSRCM=3D1). =
The
>> only differ- ences occur in the EPN field of the TLB entry and the =
EPN
>> field of MAS2. The differences are summarized here.
>>=20
>> * Executing a tlbwe instruction in 32-bit mode will set bits =
0:31
>> of the TLB EPN field to zero unless MAS0ATSEL is set, in which case =
those
>> bits are not written to zero.
>> * In 32-bit implementations, MAS2U can be used to read or write
>> EPN0:31 of MAS2.
>>=20
>> So if MSR.CM is not set tlbwe should mask the upper 32 bits out - =
which
>> can happen regardless of CONFIG_64BIT.
>=20
> MAS2_EPN reflects EPN field of MAS2 aka bits 0:51 (for MAV =3D 1.0) =
according
> to section 6.10.3.10 in the PowerISA 2.06b.
>=20
> MAS2_EPN is not used in tlbwe execution emulation, we have MAS2_VAL =
define
> for this case.
So tlbe->mas2 is guaranteed to have the upper bits be 0 when MSR.CM=3D0?
>=20
>> Also, we need to implement MAS2U, to potentially make the upper =
32bits of
>> MAS2 available, right? But that one isn't as important as the first =
bit.
>=20
> MAS2U is guest privileged why does it need special care?
Maybe it's mapped to the upper bits of GMAS2 automatically?
> Freescale core Manuals and EREF does not mention MAS2U so I think I =
our case
> it is not implemented.
Please check with a simple mfspr() test on real hw to see if it really =
isn't implemented.
Alex
^ permalink raw reply
* RE: [RFC PATCH] powerpc/fsl: add timer wakeup source
From: Wang Dongsheng-B40534 @ 2012-10-08 7:13 UTC (permalink / raw)
To: Wood Scott-B07421, Kumar Gala
Cc: Wang Dongsheng, linuxppc-dev@lists.ozlabs.org list,
Li Yang-R58472, linux-pm@vger.kernel.org
In-Reply-To: <1349302807.31013.20@snotra>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Thursday, October 04, 2012 6:20 AM
> To: Kumar Gala
> Cc: Wang Dongsheng; Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org list=
;
> Wang Dongsheng-B40534; Li Yang-R58472; linux-pm@vger.kernel.org
> Subject: Re: [RFC PATCH] powerpc/fsl: add timer wakeup source
>=20
> On 10/03/2012 08:35:58 AM, Kumar Gala wrote:
> >
> > On Oct 3, 2012, at 5:42 AM, Wang Dongsheng wrote:
> >
> > > This is only for freescale powerpc platform. The driver provides a
> > way
> > > to wake up system. Proc
> > interface(/proc/powerpc/wakeup_timer_seconds).
> > >
> > > eg: "echo 5 > /proc/powerpc/wakeup_timer_seconds", 5 seconds after
> > > the system will be woken up. echo another time into proc
> > interface
> > > to update the time.
> > >
> > > Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
> > > Signed-off-by: Li Yang <leoli@freescale.com>
> > > ---
> > > arch/powerpc/platforms/Kconfig | 23 +++
> > > arch/powerpc/platforms/Makefile | 1 +
> > > arch/powerpc/platforms/fsl_timer_wakeup.c | 217
> > +++++++++++++++++++++++++++++
> > > 3 files changed, 241 insertions(+)
> > > create mode 100644 arch/powerpc/platforms/fsl_timer_wakeup.c
> >
> > Adding the Linux PM list to see if there is some existing support for
> > this on other arch's in kernel.
> >
> > I'm pretty sure /proc/ is NOT where we want this exposed.
>=20
> Should probably go under the sysfs directory of the mpic device. Or
> better, make a generic interface for timer-based suspend wakeup (if there
> isn't one already). This current approach sits in an unpleasant middle
> ground between generic and device-specific.
> =09
/sys/power/wakeup_timer_seconds how about this?
I think it is a freescale generic interface, this interface control by
FSL_SOC && SUSPEND.
> > > diff --git a/arch/powerpc/platforms/Kconfig
> > b/arch/powerpc/platforms/Kconfig
> > > index b190a6e..7b9232a 100644
> > > --- a/arch/powerpc/platforms/Kconfig
> > > +++ b/arch/powerpc/platforms/Kconfig
> > > @@ -99,6 +99,29 @@ config MPIC_TIMER
> > > only tested on fsl chip, but it can potentially support
> > > other global timers complying to Open-PIC standard.
> > >
> > > +menuconfig FSL_WAKEUP_SOURCE
> > > + bool "Freescale wakeup source"
> > > + depends on FSL_SOC && SUSPEND
> > > + default n
> > > + help
> > > + This option enables wakeup source for wake up system
> > > + features. This is only for freescale powerpc platform.
> > > +
> > > +if FSL_WAKEUP_SOURCE
> > > +
> > > +config FSL_TIMER_WAKEUP
> > > + tristate "Freescale mpic global timer wakeup event"
> > > + default n
> > > + help
> > > + This is only for freescale powerpc platform. The driver
> > > + provides a way to wake up system.
> > > + Proc interface(/proc/powerpc/wakeup_timer_seconds).
> > > + eg: "echo 5 > /proc/powerpc/wakeup_timer_seconds",
> > > + 5 seconds after the system will be woken up. echo another
> > > + time into proc interface to update the time.
> > > +
> > > +endif
>=20
> Use depends rather than if/else. Why do you need FSL_WAKEUP_SOURCE?
>
It lists all wake up source. If later have wakeup source can be improved by
it to control. Buttons event wakeup source will be added after the timer.
> These names are overly broad -- this is only for FSL MPIC, not for other
> FSL chips (e.g. mpc83xx has a different global timer implementation, and
> there's FSL ARM chips, etc).
>=20
Yes, thanks. Change to FSL_MPIC_TIMER_WAKEUP.
> > > +static ssize_t timer_wakeup_write(struct file *file, const char
> > __user *buf,
> > > + size_t count, loff_t *off)
> > > +{
> > > + struct fsl_timer_wakeup *priv;
> > > + struct inode *inode =3D file->f_path.dentry->d_inode;
> > > + struct proc_dir_entry *dp;
> > > + struct timeval time;
> > > + char *kbuf;
> > > +
> > > + dp =3D PDE(inode);
> > > + priv =3D dp->data;
> > > +
> > > + kbuf =3D kzalloc(count + 1, GFP_KERNEL);
> > > + if (!kbuf)
> > > + return -ENOMEM;
> > > +
> > > + if (copy_from_user(kbuf, buf, count)) {
> > > + kfree(kbuf);
> > > + return -EFAULT;
> > > + }
> > > +
> > > + kbuf[count] =3D '\0';
> > > +
> > > + if (kstrtol(kbuf, 0, &time.tv_sec)) {
> > > + kfree(kbuf);
> > > + return -EINVAL;
> > > + }
> > > +
> > > + kfree(kbuf);
> > > +
> > > + time.tv_usec =3D 0;
> > > +
> > > + mutex_lock(&priv->mutex);
> > > +
> > > + if (!time.tv_sec) {
> > > + if (priv->timer) {
> > > + mpic_free_timer(priv->timer);
> > > + priv->timer =3D NULL;
> > > + }
> > > + mutex_unlock(&priv->mutex);
> > > +
> > > + return count;
> > > + }
> > > +
> > > + if (priv->timer) {
> > > + mpic_free_timer(priv->timer);
> > > + priv->timer =3D NULL;
> > > + }
> > > +
> > > + priv->timer =3D mpic_request_timer(timer_event_interrupt, priv,
> > &time);
>=20
> If the new time is zero, consider that a cancellation of the timer and
> don't request a new one or return -EINVAL.
>=20
Thanks, I think i should add comments. Let this patch easy to read.
Here is get a new timer.
If the new time is zero, consider that has been checked.
if (!time.tv_sec) {...} this is check zero.
The "mpic_request_timer" before this code.
- Dongsheng
^ permalink raw reply
* Re: [PATCH 0/10] memory-hotplug: hot-remove physical memory
From: Wen Congyang @ 2012-10-08 5:26 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: linux-s390, linux-ia64, len.brown, linux-acpi, linux-sh, x86,
linux-kernel, cmetcalf, linux-mm, Yasuaki Ishimatsu, minchan.kim,
rientjes, sparclinux, cl, linuxppc-dev, akpm, liuj97
In-Reply-To: <CAHGf_=qCZvL7xcOkea80Y995sZWkOMQLLVnuvLUto4W+qpUbWA@mail.gmail.com>
At 10/06/2012 03:06 AM, KOSAKI Motohiro Wrote:
>> Known problems:
>> 1. memory can't be offlined when CONFIG_MEMCG is selected.
>> For example: there is a memory device on node 1. The address range
>> is [1G, 1.5G). You will find 4 new directories memory8, memory9, memory10,
>> and memory11 under the directory /sys/devices/system/memory/.
>> If CONFIG_MEMCG is selected, we will allocate memory to store page cgroup
>> when we online pages. When we online memory8, the memory stored page cgroup
>> is not provided by this memory device. But when we online memory9, the memory
>> stored page cgroup may be provided by memory8. So we can't offline memory8
>> now. We should offline the memory in the reversed order.
>> When the memory device is hotremoved, we will auto offline memory provided
>> by this memory device. But we don't know which memory is onlined first, so
>> offlining memory may fail. In such case, you should offline the memory by
>> hand before hotremoving the memory device.
>
> Just iterate twice. 1st iterate: offline every non primary memory
> block. 2nd iterate:
> offline primary (i.e. first added) memory block. It may work.
>
OK, I will try it.
Thanks
Wen Congyang
^ permalink raw reply
* Re: [PATCH 8/10] memory-hotplug : remove page table of x86_64 architecture
From: Wen Congyang @ 2012-10-08 5:23 UTC (permalink / raw)
To: Andi Kleen
Cc: linux-s390, linux-ia64, len.brown, linux-acpi, linux-sh, x86,
linux-kernel, cmetcalf, linux-mm, Yasuaki Ishimatsu, minchan.kim,
kosaki.motohiro, rientjes, sparclinux, cl, linuxppc-dev, akpm,
liuj97
In-Reply-To: <m2d30tvatv.fsf@firstfloor.org>
At 10/08/2012 12:37 PM, Andi Kleen Wrote:
> Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> writes:
>> + }
>> +
>> + /*
>> + * We use 2M page, but we need to remove part of them,
>> + * so split 2M page to 4K page.
>> + */
>> + pte = alloc_low_page(&pte_phys);
>
> What happens when the allocation fails?
>
> alloc_low_page seems to be buggy there too, it would __pa a NULL
> pointer.
Yes, it will cause kernek panicked in __pa() if CONFI_DEBUG_VIRTUAL is set.
Otherwise, it will return a NULL pointer. I will update this patch to deal
with NULL pointer.
>
>> + if (pud_large(*pud)) {
>> + if ((addr & ~PUD_MASK) == 0 && next <= end) {
>> + set_pud(pud, __pud(0));
>> + pages++;
>> + continue;
>> + }
>> +
>> + /*
>> + * We use 1G page, but we need to remove part of them,
>> + * so split 1G page to 2M page.
>> + */
>> + pmd = alloc_low_page(&pmd_phys);
>
> Same here
>
>> + __split_large_page((pte_t *)pud, addr, (pte_t *)pmd);
>> +
>> + spin_lock(&init_mm.page_table_lock);
>> + pud_populate(&init_mm, pud, __va(pmd_phys));
>> + spin_unlock(&init_mm.page_table_lock);
>> + }
>> +
>> + pmd = map_low_page(pmd_offset(pud, 0));
>> + phys_pmd_remove(pmd, addr, end);
>> + unmap_low_page(pmd);
>> + __flush_tlb_all();
>> + }
>> + __flush_tlb_all();
>
> This doesn't flush the other CPUs doesn't it?
How to flush the other CPU's tlb? use on_each_cpu() to run __flush_tlb_all()
on each online cpu?
Thanks
Wen Congyang
>
> -Andi
>
^ permalink raw reply
* Re: [PATCH 8/10] memory-hotplug : remove page table of x86_64 architecture
From: Andi Kleen @ 2012-10-08 4:37 UTC (permalink / raw)
To: Yasuaki Ishimatsu
Cc: linux-s390, linux-ia64, wency, len.brown, linux-acpi, linux-sh,
x86, linux-kernel, cmetcalf, linux-mm, minchan.kim,
kosaki.motohiro, rientjes, sparclinux, cl, linuxppc-dev, akpm,
liuj97
In-Reply-To: <506E4799.30407@jp.fujitsu.com>
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> writes:
> + }
> +
> + /*
> + * We use 2M page, but we need to remove part of them,
> + * so split 2M page to 4K page.
> + */
> + pte = alloc_low_page(&pte_phys);
What happens when the allocation fails?
alloc_low_page seems to be buggy there too, it would __pa a NULL
pointer.
> + if (pud_large(*pud)) {
> + if ((addr & ~PUD_MASK) == 0 && next <= end) {
> + set_pud(pud, __pud(0));
> + pages++;
> + continue;
> + }
> +
> + /*
> + * We use 1G page, but we need to remove part of them,
> + * so split 1G page to 2M page.
> + */
> + pmd = alloc_low_page(&pmd_phys);
Same here
> + __split_large_page((pte_t *)pud, addr, (pte_t *)pmd);
> +
> + spin_lock(&init_mm.page_table_lock);
> + pud_populate(&init_mm, pud, __va(pmd_phys));
> + spin_unlock(&init_mm.page_table_lock);
> + }
> +
> + pmd = map_low_page(pmd_offset(pud, 0));
> + phys_pmd_remove(pmd, addr, end);
> + unmap_low_page(pmd);
> + __flush_tlb_all();
> + }
> + __flush_tlb_all();
This doesn't flush the other CPUs doesn't it?
-Andi
--
ak@linux.intel.com -- Speaking for myself only
^ 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