* Re: i2c-powermac fails
From: Jean Delvare @ 2009-10-15 14:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Paul Mackerras, Tim Shepard, linuxppc-dev
In-Reply-To: <1255605559.2347.102.camel@pasglop>
On Thu, 15 Oct 2009 22:19:19 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2009-10-15 at 12:49 +0200, Jean Delvare wrote:
> > Oh. Well, if that was the case, we would see errors all the time, not
> > just during initialization, right? Or does the I2C clock frequency
> > change over time somehow?
>
> No but maybe we are a bit on the "limit" of the device and some
> registers take long to respond than others ?
Unlikely. The ADT7460 can run at I2C clock rates up to 400 kHz while
the Keywest I2C runs at 25, 50 or 100 kHz if I read the code properly.
I don't know what exact speed is used on Tim's system, apparently it is
read from the hardware in the device tree directly?
We could have low_i2c.c log the I2C clock frequency and/or try to force
the lowest speed (25 kHz) and see if it helps, but I very much doubt
it. And I'd rather wait for Tim to report the result with my last patch
first.
--
Jean Delvare
^ permalink raw reply
* kernel oops issue in localbus driver
From: Fathi Boudra @ 2009-10-15 13:36 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc-embedded
Hi,
I have a FPGA connected to a MPC8347 through localbus.
The following kernel oops occurs sometimes:
Unable to handle kernel paging request for data at address 0x7ddfecb0
Faulting instruction address: 0xc00145f4
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT
Modules linked in: ath_pci ath_rate_minstrel ath_hal wlan_acl
wlan_ccmp wlan_scan_ap wlan_scan_sta wlan_tkip wlan_wep wlan_xauth
wlan gpio localbus
NIP: C00145F4 LR: D1083C74 CTR: 000001C3
REGS: c700ddb0 TRAP: 0300 Tainted: P (2.6.18)
MSR: 00009032 <EE,ME,IR,DR> CR: 20024042 XER: 20000000
DAR: 7DDFECB0, DSISR: 22000000
TASK = c7786810[345] 'femain' THREAD: c700c000
GPR00: 00000000 C700DE60 C7786810 7DDFEBC8 C90620EC 00000F00 7DDFECAC
7196E7E0
GPR08: 0EECA261 D1090000 0021ED00 C00145D0 00001000 704C6206 00000000
1005924D
GPR16: C0034D7C 7DDFEBC8 C700DE9C 00000F00 00000000 C787A3C0 D1090000
00000000
GPR24: 00000000 D1090000 7DDFEBC8 D1090000 000003C0 C9062000 7DDFEBC8
D108E954
NIP [C00145F4] memcpy+0x24/0x9c
LR [D1083C74] lbp_memcpy32_fromio+0x54/0x98 [localbus]
Call Trace:
[C700DE60] [C019B780] preempt_schedule_irq+0x64/0xa4 (unreliable)
[C700DE80] [D10813C0] fpgadecenc_read+0x3ac/0x4b0 [localbus]
--- Exception: 7ddfebc8 at 0xc700df40
LR = _start+0x40000000/0xc
[C700DEF0] [C005F4DC] vfs_read+0x9c/0x140 (unreliable)
[C700DF10] [C005F840] sys_read+0x4c/0x90
[C700DF40] [C000F89C] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0x300bb7dc
LR = 0x3001ed40
Instruction dump:
4e800020 7c032040 418100a0 54a7e8ff 38c3fffc 3884fffc 41820028
70c00003
7ce903a6 40820054 80e40004 85040008 <90e60004> 95060008 4200fff0 70a50007
It seems there's an issue in the localbus driver (lbp_memcpy32_fromio
is a wrapper function for the localbus memory access):
ssize_t lbp_memcpy_fromio(void *dest, void *source, __u32 count32)
{
/* attempt to acquire the semaphore */
down(&sem_lb);
/* critical region */
mb();
memcpy_fromio(dest, source, count32 * 4);
mb();
/* release the given semaphore */
up(&sem_lb);
}
Aren't we supposed to use down_interruptible() instead ?
I didn't write the driver and would like to fix it.
Any hints will be appreciated.
cheers,
Fathi
^ permalink raw reply
* Re: UBIFS problem on MPC8536DS
From: Felix Radensky @ 2009-10-15 12:49 UTC (permalink / raw)
To: Norbert van Bolhuis; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <4AD6F172.6030407@aimvalley.nl>
Hi, Norbert
Norbert van Bolhuis wrote:
> Hi Felix,
>
> do you have CONFIG_NO_HZ defined ?
>
> I've seen similar problems with powerpc + CONFIG_NO_HZ. In my case the
> low-level
> do_write_buffer (cfi_cmdset_0002.c) timed out too early. See
> http://lkml.org/lkml/2009/9/3/84
>
> Maybe in your case it's the do_erase_chip timing out too early.
>
> ---
> NvBolhuis.
>
Thanks for suggestion.
I have CONFIG_NO_HZ defined, but disabling it doesn't help.
I my case timeouts occur in NAND driver, fsl_elbc_nand.c
Felix.
^ permalink raw reply
* RE: [PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.
From: Richard Cochran @ 2009-10-15 12:19 UTC (permalink / raw)
To: 'Scott Wood'; +Cc: 'linuxppc-dev@lists.ozlabs.org'
In-Reply-To: <20091014152722.GA17867@b07421-ec1.am.freescale.net>
>-----Original Message----- From: Scott Wood [mailto:scottwood@freescale.co=
m]
>Because that would be three times the device trees to maintain, and a
>source of user confusion.
I wonder which is more confusing for the user:
1. Choosing one of three dts files.
2. Having only one dts for his board, but Ethernet doesn't work.
Richard
^ permalink raw reply
* Re: MPC5121 CAN and USB
From: Kári Davíðsson @ 2009-10-15 11:36 UTC (permalink / raw)
To: paul.gibson2074@gmail.com; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <4AD70585.40302@gmail.com>
Thank you Paul,
The kernel from the BSP on Freescale site is crashing on the CAN in my case=
(might be a hardware bug).
I could not find the source for the kernel in the BSP or on the freescale s=
ite.
I had not looked at http://git.denx.de/?p=3Dlinux-2.6-denx.git;a=3Dshortlog=
;h=3Drefs/heads/ltib-mpc5121ads-20090602
I am now in the progress of cloning the linux-mpc512x git from denx and bui=
lding from it.
Hopefully that will help me.
rg
kd
Paul Gibson wrote:
> In my opinion the best place is the BSP available on the MPC5121e page=20
> on the Freescale site.
>=20
> I actually use the kernel in the git repository here which is similar to=
=20
> the BSP:
> http://git.denx.de/?p=3Dlinux-2.6-denx.git;a=3Dshortlog;h=3Drefs/heads/lt=
ib-mpc5121ads-20090602=20
> or here:
> http://git.denx.de/?p=3Dlinux-mpc512x.git;a=3Dsummary
>=20
> I have found both to be very stable, also with the CAN and USB.
>=20
> Paul
>=20
> K=E1ri Dav=ED=F0sson wrote:
>> Hello,
>>
>> Where is the most current linux work for the Freescale MPC5121 cpu=20
>> stored.
>> What I am specifically interested in at this time is the CAN and USB=20
>> subsystems.
>>
>> rg
>> kd
>>
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>=20
^ permalink raw reply
* Re: MPC5121 CAN and USB
From: Paul Gibson @ 2009-10-15 11:20 UTC (permalink / raw)
Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <4AD6FD4E.9060507@marel.com>
In my opinion the best place is the BSP available on the MPC5121e page
on the Freescale site.
I actually use the kernel in the git repository here which is similar to
the BSP:
http://git.denx.de/?p=linux-2.6-denx.git;a=shortlog;h=refs/heads/ltib-mpc5121ads-20090602
or here:
http://git.denx.de/?p=linux-mpc512x.git;a=summary
I have found both to be very stable, also with the CAN and USB.
Paul
Kári Davíðsson wrote:
> Hello,
>
> Where is the most current linux work for the Freescale MPC5121 cpu
> stored.
> What I am specifically interested in at this time is the CAN and USB
> subsystems.
>
> rg
> kd
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: i2c-powermac fails
From: Benjamin Herrenschmidt @ 2009-10-15 11:19 UTC (permalink / raw)
To: Jean Delvare; +Cc: Paul Mackerras, Tim Shepard, linuxppc-dev
In-Reply-To: <20091015124923.23863a94@hyperion.delvare>
On Thu, 2009-10-15 at 12:49 +0200, Jean Delvare wrote:
> Oh. Well, if that was the case, we would see errors all the time, not
> just during initialization, right? Or does the I2C clock frequency
> change over time somehow?
No but maybe we are a bit on the "limit" of the device and some
registers take long to respond than others ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] hvc_console: returning 0 from put_chars is not an error
From: Christian Borntraeger @ 2009-10-15 11:05 UTC (permalink / raw)
To: Timur Tabi
Cc: scottwood, linuxppc-dev, brueckner, Linux Kernel Mailing List,
Alan Cox
In-Reply-To: <1255557226-4403-1-git-send-email-timur@freescale.com>
Am Mittwoch 14 Oktober 2009 23:53:46 schrieben Sie:
> hvc_console_print() calls the HVC client driver's put_chars() callback
> to write some characters to the console. If the callback returns 0, that
> indicates that no characters were written (perhaps the output buffer is
> full), but hvc_console_print() treats that as an error and discards the
> rest of the buffer.
>
> So change hvc_console_print() to just loop and call put_chars() again if it
> returns a 0 return code.
>
> This change makes hvc_console_print() behave more like hvc_push(), which
> does check for a 0 return code and re-schedules itself.
There is a difference between console and tty, if the console call does not
return, it might bring the full system to a stop. (if its the preferred console,
init will stop)
> This patch might fix drivers that return 0 to indicate that they're busy, such
> as arch/powerpc/platforms/pseries/hvconsole.c. It will break drivers that
> return 0 if their output buffer is full, but where those buffers cannot be
> emptied while the kernel is in a loop.
Yep. I think it really depends on the backend if looping will result in any
progress or not. My experience wth hvc_console is, that its quite hard to get
changes tested on all backends. (e.g. XEN, pseries, iseries, virtio_console,
s390_iucv...), so even if this change turns out to be correct, it should
probably sit in linux-next for a while. In additon I really dont oversee, what
backends wil break due to this patch.
The fact that struct console->write returns void indicates that the console
layer is not interested in errors. We have two policies we can implement:
1. drop console messages if case of congestion but keep the system going
2. dont drop messages and wait, even if the system might come to a complete stop
Looking at drivers/char/vt.c
/* console busy or not yet initialized */
if (!printable)
return;
if (!spin_trylock(&printing_lock))
return;
could mean that Linux consoles should not block.
Maybe its time to ask some of the elder magicians (CCing Alan Cox and linux-
kernel) about blocking and error handling in console code.
> --- a/drivers/char/hvc_console.c
> +++ b/drivers/char/hvc_console.c
> @@ -161,7 +161,7 @@ static void hvc_console_print(struct console *co, const
> char *b, }
> } else {
> r = cons_ops[index]->put_chars(vtermnos[index], c, i);
> - if (r <= 0) {
> + if (r < 0) {
> /* throw away chars on error */
> i = 0;
> } else if (r > 0) {
>
^ permalink raw reply
* MPC5121 CAN and USB
From: Kári Davíðsson @ 2009-10-15 10:45 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
In-Reply-To: <4AD6F172.6030407@aimvalley.nl>
Hello,
Where is the most current linux work for the Freescale MPC5121 cpu stored.
What I am specifically interested in at this time is the CAN and USB subsystems.
rg
kd
^ permalink raw reply
* Re: i2c-powermac fails
From: Jean Delvare @ 2009-10-15 10:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Paul Mackerras, Tim Shepard, linuxppc-dev
In-Reply-To: <1255555575.2347.56.camel@pasglop>
On Thu, 15 Oct 2009 08:26:15 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2009-10-14 at 23:02 +0200, Jean Delvare wrote:
> > Hi all,
> >
> > On Tue, 13 Oct 2009 11:49:48 +0200, Jean Delvare wrote:
> > > I2C bus being setup too fast sounds more likely. It might be worth
> > > adding an arbitrary delay after initialization, just to see if it
> > > helps. Not sure where though, as I'm not familiar with the Powermac
> > > initialization steps. Maybe right before i2c_add_adapter() in
> > > i2c_powermac_probe?
> >
> > Tim, can you please give a try to this patch? Obviously your machine
> > will take 5 additional seconds to boot, and this isn't meant as a real
> > fix, but if it helps, this will be an interesting hint for further
> > debugging attempts.
>
> Oh, I was actually thinking about the frequency of the I2C clock :-)
Oh. Well, if that was the case, we would see errors all the time, not
just during initialization, right? Or does the I2C clock frequency
change over time somehow?
--
Jean Delvare
^ permalink raw reply
* Instable kernel (2.6.29 or 2.6.31) on MPC8548 with 2 GByte RAM
From: willy jacobs @ 2009-10-15 10:13 UTC (permalink / raw)
To: Linuxppc-dev
On our MPC8548 (latest die revision) based boards with 2 GByte DDR2 RAM we see an stable kernel when
CONFIG_HIGHMEM is not set
In this case only the first 768 MB will be used (as reported by /proc/cpuinfo).
Tested with/without the RT-patches for 2.6.29.6(-rt23) and 2.6.31.2(-rt13) kernels.
With CONFIG_HIGHMEM=y (2048 MB reported) we see (under "heavy" load conditions) regulary page
errors like this (with/without RT patches):
BUG: Bad page state in process loadgen pfn:7e31d
page:c17c23a0 flags:80000000 count:0 mapcount:-128 mapping:(null) index:48105
Call Trace:
[ef867d20] [c00072ac] show_stack+0x34/0x160 (unreliable)
[ef867d50] [c006fcd0] bad_page+0x90/0x13c
[ef867d70] [c0070d94] get_page_from_freelist+0x424/0x45c
[ef867de0] [c0070ea4] __alloc_pages_nodemask+0xd8/0x48c
[ef867e40] [c0082bf0] handle_mm_fault+0x404/0x740
[ef867e90] [c00131bc] do_page_fault+0x150/0x460
[ef867f40] [c001017c] handle_page_fault+0xc/0x80
With the RT-patches we see already during Linux startup at lot of these errors (from several processes):
BUG: scheduling while atomic: pam_console_app/0x00000001/802, CPU#0
Modules linked in:
Call Trace:
[ef28dce0] [c00072ac] show_stack+0x34/0x160 (unreliable)
[ef28dd10] [c002fa90] __schedule_bug+0x6c/0x80
[ef28dd30] [c02660fc] __schedule+0x264/0x338
[ef28dd60] [c0266400] schedule+0x1c/0x40
[ef28dd70] [c0267898] rt_spin_lock_slowlock+0x124/0x264
[ef28dde0] [c0079154] __lru_cache_add+0x24/0xa8
[ef28de00] [c008ee04] page_add_new_anon_rmap+0x58/0x88
[ef28de20] [c0086ff8] handle_mm_fault+0x5a4/0x804
[ef28de80] [c0013590] do_page_fault+0x14c/0x49c
[ef28df40] [c00101c4] handle_page_fault+0xc/0x80
BUG: scheduling while atomic: pam_console_app/0x00000001/807, CPU#0
Modules linked in:
Call Trace:
[ef323a30] [c00072ac] show_stack+0x34/0x160 (unreliable)
[ef323a60] [c002fa90] __schedule_bug+0x6c/0x80
[ef323a80] [c02660fc] __schedule+0x264/0x338
[ef323ab0] [c0266400] schedule+0x1c/0x40
[ef323ac0] [c0267898] rt_spin_lock_slowlock+0x124/0x264
[ef323b30] [c0079154] __lru_cache_add+0x24/0xa8
[ef323b50] [c008ee04] page_add_new_anon_rmap+0x58/0x88
[ef323b70] [c0086ff8] handle_mm_fault+0x5a4/0x804
[ef323bd0] [c0013590] do_page_fault+0x14c/0x49c
[ef323c90] [c00101c4] handle_page_fault+0xc/0x80
[ef323d50] [00000007] 0x7
[ef323d80] [c0071320] generic_file_aio_read+0x2d4/0x6bc
[ef323e00] [c00ffe98] nfs_file_read+0x124/0x178
[ef323e30] [c009d56c] do_sync_read+0xc4/0x138
[ef323ef0] [c009e0a4] vfs_read+0xc4/0x188
[ef323f10] [c009e514] sys_read+0x4c/0x90
[ef323f40] [c000fd84] ret_from_syscall+0x0/0x3c
Anyone experience with MPC8548 with 2 GByte RAM (HIGHMEM)?
Regards,
--
willy
Unclassified
------------------------------------------------------------------------------------------------------------
Disclaimer:
If you are not the intended recipient of this email, please notify the sender and delete it.
Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden.
Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s).
Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578.
------------------------------------------------------------------------------------------------------------
^ permalink raw reply
* Re: UBIFS problem on MPC8536DS
From: Norbert van Bolhuis @ 2009-10-15 9:54 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <4AD5ADC9.30503@embedded-sol.com>
Hi Felix,
do you have CONFIG_NO_HZ defined ?
I've seen similar problems with powerpc + CONFIG_NO_HZ. In my case the low-level
do_write_buffer (cfi_cmdset_0002.c) timed out too early. See
http://lkml.org/lkml/2009/9/3/84
Maybe in your case it's the do_erase_chip timing out too early.
---
NvBolhuis.
Felix Radensky wrote:
> Hi,
>
> I have a strange problem in linux-2.6.31 running on MPC8536DS board.
> It is 100% reproducible, by opening a 350MB tar file into ubifs volume
> on NAND flash, and starting erase of NOR flash partition right after that.
>
> If I don't start NOR erase, everything works fine. Also, If I run sync
> after
> tar, no problem occurs. The NOR flash is 32MB Spansion, NAND is
> 4GB Samsung.
>
> The error messages are as follows:
>
> UBI error: ubi_io_write: error -5 while writing 2048 bytes to PEB
> 5812:12288, written 0 bytes
> UBI warning: ubi_eba_write_leb: failed to write data to PEB 5812
> UBI: recover PEB 5812, move data to PEB 19400
> UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB
> 5812:512, read 512 bytes
> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
> 19400:512, written 0 bytes
> UBI warning: recover_peb: failed to write to PEB 19400
> UBI: try again
> UBI: recover PEB 5812, move data to PEB 19401
> UBI: run torture test for PEB 19400
> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
> 19401:512, written 0 bytes
> UBI warning: recover_peb: failed to write to PEB 19401
> UBI: try again
> UBI: recover PEB 5812, move data to PEB 19402
> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
> 19402:512, written 0 bytes
> UBI warning: recover_peb: failed to write to PEB 19402
> UBI: try again
> UBI: recover PEB 5812, move data to PEB 19403
> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
> 19403:512, written 0 bytes
> UBI warning: recover_peb: failed to write to PEB 19403
> UBI warning: ubi_ro_mode: switch to read-only mode
> UBIFS error (pid 1149): ubifs_wbuf_write_nolock: cannot write 2522 bytes
> to LEB 389:10240, error -5
> UBIFS warning (pid 1149): ubifs_ro_mode: switched to read-only mode,
> error -5
> UBIFS error (pid 1149): do_writepage: cannot write page 0 of inode
> 30708, error -5
> UBIFS error (pid 1149): make_reservation: cannot reserve 858 bytes in
> jhead 2, error -30
> UBIFS error (pid 1149): do_writepage: cannot write page 2 of inode
> 29486, error -30
> UBIFS error (pid 1149): make_reservation: cannot reserve 721 bytes in
> jhead 2, error -30
> UBIFS error (pid 1149): do_writepage: cannot write page 1 of inode
> 30070, error -30
> UBI error: ubi_io_write: error -5 while writing 2048 bytes to PEB
> 5022:88064, written 0 bytes
> UBI warning: ubi_eba_write_leb: failed to write data to PEB 5022
> UBI: recover PEB 5022, move data to PEB 19404
> UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB
> 5022:512, read 512 bytes
> UBI error: ubi_io_write: read-only mode
> UBI warning: recover_peb: failed to write to PEB 19404
> UBI: try again
> UBI: recover PEB 5022, move data to PEB 19405
> UBI error: ubi_io_write: read-only mode
> UBI warning: recover_peb: failed to write to PEB 19405
> UBI: try again
> UBI: recover PEB 5022, move data to PEB 19406
> UBI error: ubi_io_write: read-only mode
> UBI warning: recover_peb: failed to write to PEB 19406
> UBI: try again
> UBI: recover PEB 5022, move data to PEB 19407
> UBI error: ubi_io_write: read-only mode
> UBI warning: recover_peb: failed to write to PEB 19407
> UBIFS error (pid 1044): ubifs_wbuf_sync_nolock: cannot write 2048 bytes
> to LEB 788:86016
> UBIFS error (pid 1044): ubifs_bg_wbufs_sync: cannot sync write-buffer,
> error -30
> UBIFS warning (pid 1044): ubifs_ro_mode: switched to read-only mode,
> error -30
> UBI error: ubi_io_write: error -5 while writing 2048 bytes to PEB
> 5817:26624, written 0 bytes
> UBI warning: ubi_eba_write_leb: failed to write data to PEB 5817
> UBI: recover PEB 5817, move data to PEB 19408
> UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB
> 5817:512, read 512 bytes
> UBI error: ubi_io_write: read-only mode
> UBI warning: recover_peb: failed to write to PEB 19408
> UBI: try again
> UBI: recover PEB 5817, move data to PEB 19409
> UBI error: ubi_io_write: read-only mode
> UBI warning: recover_peb: failed to write to PEB 19409
> UBI: try again
> UBI: recover PEB 5817, move data to PEB 19410
> UBI error: ubi_io_write: read-only mode
> UBI warning: recover_peb: failed to write to PEB 19410
> UBI: try again
> UBI: recover PEB 5817, move data to PEB 19411
> UBI error: ubi_io_write: read-only mode
> UBI warning: recover_peb: failed to write to PEB 19411
> UBIFS error (pid 1047): ubifs_wbuf_sync_nolock: cannot write 2048 bytes
> to LEB 385:24576
> UBIFS error (pid 1047): ubifs_bg_wbufs_sync: cannot sync write-buffer,
> error -30
> UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
> jhead 1, error -30
> UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30709,
> error -30
> UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
> jhead 1, error -30
> UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30710,
> error -30
> UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
> jhead 1, error -30
> UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30698,
> error -30
> UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in
> jhead 1, error -30
> UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30711,
> error -30
>
> I'd appreciate any hints on what can cause this. Is it a hardware
> problem, mtd layer problem
> or UBI problem ?
>
> Thanks a lot in advance.
>
> Felix.
>
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* [PATCH 6/8] 8xx: Restore _PAGE_WRITETHRU
From: Joakim Tjernlund @ 2009-10-15 9:04 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
In-Reply-To: <1255597466-30976-6-git-send-email-Joakim.Tjernlund@transmode.se>
8xx has not had WRITETHRU due to lack of bits in the pte.
After the recent rewrite of the 8xx TLB code, there are
two bits left. Use one of them to WRITETHRU.
Perhaps use the last SW bit to PAGE_SPECIAL or PAGE_FILE?
---
arch/powerpc/include/asm/pte-8xx.h | 5 +++--
arch/powerpc/kernel/head_8xx.S | 8 ++++++++
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/pte-8xx.h b/arch/powerpc/include/asm/pte-8xx.h
index f23cd15..9349d83 100644
--- a/arch/powerpc/include/asm/pte-8xx.h
+++ b/arch/powerpc/include/asm/pte-8xx.h
@@ -34,12 +34,13 @@
#define _PAGE_SHARED 0x0004 /* No ASID (context) compare */
#define _PAGE_DIRTY 0x0100 /* C: page changed */
-/* These 3 software bits must be masked out when the entry is loaded
- * into the TLB, 2 SW bits left.
+/* These 4 software bits must be masked out when the entry is loaded
+ * into the TLB, 1 SW bit left(0x0080).
*/
#define _PAGE_EXEC 0x0008 /* software: i-cache coherency required */
#define _PAGE_GUARDED 0x0010 /* software: guarded access */
#define _PAGE_ACCESSED 0x0020 /* software: page referenced */
+#define _PAGE_WRITETHRU 0x0040 /* software: caching is write through */
/* Setting any bits in the nibble with the follow two controls will
* require a TLB exception handler change. It is assumed unused bits
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index a1512e9..6fadc44 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -422,6 +422,10 @@ DataStoreTLBMiss:
* above.
*/
rlwimi r11, r10, 0, 27, 27
+ /* Insert the WriteThru flag into the TWC from the Linux PTE.
+ * It is bit 25 in the Linux PTE and bit 30 in the TWC
+ */
+ rlwimi r11, r10, 32-5, 30, 30
DO_8xx_CPU6(0x3b80, r3)
mtspr SPRN_MD_TWC, r11
@@ -559,6 +563,10 @@ DARFixed:/* Return from dcbx instruction bug workaround, r10 holds value of DAR
* It is bit 27 of both the Linux PTE and the TWC
*/
rlwimi r11, r10, 0, 27, 27
+ /* Insert the WriteThru flag into the TWC from the Linux PTE.
+ * It is bit 25 in the Linux PTE and bit 30 in the TWC
+ */
+ rlwimi r11, r10, 32-5, 30, 30
DO_8xx_CPU6(0x3b80, r3)
mtspr SPRN_MD_TWC, r11
mfspr r11, SPRN_MD_TWC /* get the pte address again */
--
1.6.4.4
^ permalink raw reply related
* [PATCH 5/8] 8xx: Add missing Guarded setting in DTLB Error.
From: Joakim Tjernlund @ 2009-10-15 9:04 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
In-Reply-To: <1255597466-30976-5-git-send-email-Joakim.Tjernlund@transmode.se>
only DTLB Miss did set this bit, DTLB Error needs too otherwise
the setting is lost when the page becomes dirty.
---
arch/powerpc/kernel/head_8xx.S | 13 ++++++++++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 320f333..a1512e9 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -552,9 +552,16 @@ DARFixed:/* Return from dcbx instruction bug workaround, r10 holds value of DAR
*/
ori r11, r11, 1 /* Set valid bit in physical L2 page */
DO_8xx_CPU6(0x3b80, r3)
- mtspr SPRN_MD_TWC, r11 /* Load pte table base address */
- mfspr r11, SPRN_MD_TWC /* ....and get the pte address */
- lwz r10, 0(r11) /* Get the pte */
+ mtspr SPRN_MD_TWC, r11 /* Load pte table base address */
+ mfspr r10, SPRN_MD_TWC /* ....and get the pte address */
+ lwz r10, 0(r10) /* Get the pte */
+ /* Insert the Guarded flag into the TWC from the Linux PTE.
+ * It is bit 27 of both the Linux PTE and the TWC
+ */
+ rlwimi r11, r10, 0, 27, 27
+ DO_8xx_CPU6(0x3b80, r3)
+ mtspr SPRN_MD_TWC, r11
+ mfspr r11, SPRN_MD_TWC /* get the pte address again */
ori r10, r10, _PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_HWWRITE
stw r10, 0(r11) /* and update pte in table */
--
1.6.4.4
^ permalink raw reply related
* [PATCH 8/8] 8xx: Remove DIRTY pte handling in DTLB Error.
From: Joakim Tjernlund @ 2009-10-15 9:04 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
In-Reply-To: <1255597466-30976-8-git-send-email-Joakim.Tjernlund@transmode.se>
There is no need to do set the DIRTY bit directly in DTLB Error.
Trap to do_page_fault() and let the generic MM code do the work.
---
arch/powerpc/kernel/head_8xx.S | 96 ----------------------------------------
1 files changed, 0 insertions(+), 96 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 6fadc44..c60636e 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -500,102 +500,6 @@ DataTLBError:
cmpwi cr0, r10, 0x00f0
beq- FixupDAR /* must be a buggy dcbX, icbi insn. */
DARFixed:/* Return from dcbx instruction bug workaround, r10 holds value of DAR */
- mfspr r11, SPRN_DSISR
- /* As the DAR fixup may clear store we may have all 3 states zero.
- * Make sure only 0x0200(store) falls down into DIRTY handling
- */
- andis. r11, r11, 0x4a00 /* !translation, protection or store */
- srwi r11, r11, 16
- cmpwi cr0, r11, 0x0200 /* just store ? */
- bne 2f
- /* Only Change bit left now, do it here as it is faster
- * than trapping to the C fault handler.
- */
-
- /* The EA of a data TLB miss is automatically stored in the MD_EPN
- * register. The EA of a data TLB error is automatically stored in
- * the DAR, but not the MD_EPN register. We must copy the 20 most
- * significant bits of the EA from the DAR to MD_EPN before we
- * start walking the page tables. We also need to copy the CASID
- * value from the M_CASID register.
- * Addendum: The EA of a data TLB error is _supposed_ to be stored
- * in DAR, but it seems that this doesn't happen in some cases, such
- * as when the error is due to a dcbi instruction to a page with a
- * TLB that doesn't have the changed bit set. In such cases, there
- * does not appear to be any way to recover the EA of the error
- * since it is neither in DAR nor MD_EPN. As a workaround, the
- * _PAGE_HWWRITE bit is set for all kernel data pages when the PTEs
- * are initialized in mapin_ram(). This will avoid the problem,
- * assuming we only use the dcbi instruction on kernel addresses.
- */
-
- /* DAR is in r10 already */
- rlwinm r11, r10, 0, 0, 19
- ori r11, r11, MD_EVALID
- mfspr r10, SPRN_M_CASID
- rlwimi r11, r10, 0, 28, 31
- DO_8xx_CPU6(0x3780, r3)
- mtspr SPRN_MD_EPN, r11
-
- mfspr r10, SPRN_M_TWB /* Get level 1 table entry address */
-
- /* If we are faulting a kernel address, we have to use the
- * kernel page tables.
- */
- andi. r11, r10, 0x0800
- beq 3f
- lis r11, swapper_pg_dir@h
- ori r11, r11, swapper_pg_dir@l
- rlwimi r10, r11, 0, 2, 19
-3:
- lwz r11, 0(r10) /* Get the level 1 entry */
- rlwinm. r10, r11,0,0,19 /* Extract page descriptor page address */
- beq 2f /* If zero, bail */
-
- /* We have a pte table, so fetch the pte from the table.
- */
- ori r11, r11, 1 /* Set valid bit in physical L2 page */
- DO_8xx_CPU6(0x3b80, r3)
- mtspr SPRN_MD_TWC, r11 /* Load pte table base address */
- mfspr r10, SPRN_MD_TWC /* ....and get the pte address */
- lwz r10, 0(r10) /* Get the pte */
- /* Insert the Guarded flag into the TWC from the Linux PTE.
- * It is bit 27 of both the Linux PTE and the TWC
- */
- rlwimi r11, r10, 0, 27, 27
- /* Insert the WriteThru flag into the TWC from the Linux PTE.
- * It is bit 25 in the Linux PTE and bit 30 in the TWC
- */
- rlwimi r11, r10, 32-5, 30, 30
- DO_8xx_CPU6(0x3b80, r3)
- mtspr SPRN_MD_TWC, r11
- mfspr r11, SPRN_MD_TWC /* get the pte address again */
-
- ori r10, r10, _PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_HWWRITE
- stw r10, 0(r11) /* and update pte in table */
- xori r10, r10, _PAGE_RW /* RW bit is inverted */
-
- /* The Linux PTE won't go exactly into the MMU TLB.
- * Software indicator bits 22 and 28 must be clear.
- * Software indicator bits 24, 25, 26, and 27 must be
- * set. All other Linux PTE bits control the behavior
- * of the MMU.
- */
- li r11, 0x00f0
- mtspr SPRN_DAR,r11 /* Tag DAR */
- rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
- DO_8xx_CPU6(0x3d80, r3)
- mtspr SPRN_MD_RPN, r10 /* Update TLB entry */
-
- mfspr r10, SPRN_M_TW /* Restore registers */
- lwz r11, 0(r0)
- mtcr r11
- lwz r11, 4(r0)
-#ifdef CONFIG_8xx_CPU6
- lwz r3, 8(r0)
-#endif
- rfi
-2:
mfspr r10, SPRN_M_TW /* Restore registers */
lwz r11, 0(r0)
mtcr r11
--
1.6.4.4
^ permalink raw reply related
* [PATCH 7/8] 8xx: start using dcbX instructions in various copy routines
From: Joakim Tjernlund @ 2009-10-15 9:04 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
In-Reply-To: <1255597466-30976-7-git-send-email-Joakim.Tjernlund@transmode.se>
Now that 8xx can fixup dcbX instructions, start using them
where possible like every other PowerPc arch do.
---
arch/powerpc/kernel/misc_32.S | 18 ------------------
arch/powerpc/lib/copy_32.S | 24 ------------------------
2 files changed, 0 insertions(+), 42 deletions(-)
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index 15f28e0..b92095e 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -495,15 +495,7 @@ _GLOBAL(clear_pages)
li r0,PAGE_SIZE/L1_CACHE_BYTES
slw r0,r0,r4
mtctr r0
-#ifdef CONFIG_8xx
- li r4, 0
-1: stw r4, 0(r3)
- stw r4, 4(r3)
- stw r4, 8(r3)
- stw r4, 12(r3)
-#else
1: dcbz 0,r3
-#endif
addi r3,r3,L1_CACHE_BYTES
bdnz 1b
blr
@@ -528,15 +520,6 @@ _GLOBAL(copy_page)
addi r3,r3,-4
addi r4,r4,-4
-#ifdef CONFIG_8xx
- /* don't use prefetch on 8xx */
- li r0,4096/L1_CACHE_BYTES
- mtctr r0
-1: COPY_16_BYTES
- bdnz 1b
- blr
-
-#else /* not 8xx, we can prefetch */
li r5,4
#if MAX_COPY_PREFETCH > 1
@@ -577,7 +560,6 @@ _GLOBAL(copy_page)
li r0,MAX_COPY_PREFETCH
li r11,4
b 2b
-#endif /* CONFIG_8xx */
/*
* void atomic_clear_mask(atomic_t mask, atomic_t *addr)
diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32.S
index c657de5..74a7f41 100644
--- a/arch/powerpc/lib/copy_32.S
+++ b/arch/powerpc/lib/copy_32.S
@@ -98,20 +98,7 @@ _GLOBAL(cacheable_memzero)
bdnz 4b
3: mtctr r9
li r7,4
-#if !defined(CONFIG_8xx)
10: dcbz r7,r6
-#else
-10: stw r4, 4(r6)
- stw r4, 8(r6)
- stw r4, 12(r6)
- stw r4, 16(r6)
-#if CACHE_LINE_SIZE >= 32
- stw r4, 20(r6)
- stw r4, 24(r6)
- stw r4, 28(r6)
- stw r4, 32(r6)
-#endif /* CACHE_LINE_SIZE */
-#endif
addi r6,r6,CACHELINE_BYTES
bdnz 10b
clrlwi r5,r8,32-LG_CACHELINE_BYTES
@@ -200,9 +187,7 @@ _GLOBAL(cacheable_memcpy)
mtctr r0
beq 63f
53:
-#if !defined(CONFIG_8xx)
dcbz r11,r6
-#endif
COPY_16_BYTES
#if L1_CACHE_BYTES >= 32
COPY_16_BYTES
@@ -356,14 +341,6 @@ _GLOBAL(__copy_tofrom_user)
li r11,4
beq 63f
-#ifdef CONFIG_8xx
- /* Don't use prefetch on 8xx */
- mtctr r0
- li r0,0
-53: COPY_16_BYTES_WITHEX(0)
- bdnz 53b
-
-#else /* not CONFIG_8xx */
/* Here we decide how far ahead to prefetch the source */
li r3,4
cmpwi r0,1
@@ -416,7 +393,6 @@ _GLOBAL(__copy_tofrom_user)
li r3,4
li r7,0
bne 114b
-#endif /* CONFIG_8xx */
63: srwi. r0,r5,2
mtctr r0
--
1.6.4.4
^ permalink raw reply related
* [PATCH 2/8] 8xx: Update TLB asm so it behaves as linux mm expects.
From: Joakim Tjernlund @ 2009-10-15 9:04 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
In-Reply-To: <1255597466-30976-2-git-send-email-Joakim.Tjernlund@transmode.se>
Update the TLB asm to make proper use of _PAGE_DIRY and _PAGE_ACCESSED.
Get rid of _PAGE_HWWRITE too.
Pros:
- I/D TLB Miss never needs to write to the linux pte.
- _PAGE_ACCESSED is only set on TLB Error fixing accounting
- _PAGE_DIRTY is mapped to 0x100, the changed bit, and is set directly
when a page has been made dirty.
- Proper RO/RW mapping of user space.
- Free up 2 SW TLB bits in the linux pte(add back _PAGE_WRITETHRU ?)
- kernel RO/user NA support.
Cons:
- A few more instructions in the TLB Miss routines.
---
arch/powerpc/include/asm/pte-8xx.h | 13 ++---
arch/powerpc/kernel/head_8xx.S | 99 ++++++++++++++++++-----------------
2 files changed, 57 insertions(+), 55 deletions(-)
diff --git a/arch/powerpc/include/asm/pte-8xx.h b/arch/powerpc/include/asm/pte-8xx.h
index 8c6e312..f23cd15 100644
--- a/arch/powerpc/include/asm/pte-8xx.h
+++ b/arch/powerpc/include/asm/pte-8xx.h
@@ -32,22 +32,21 @@
#define _PAGE_FILE 0x0002 /* when !present: nonlinear file mapping */
#define _PAGE_NO_CACHE 0x0002 /* I: cache inhibit */
#define _PAGE_SHARED 0x0004 /* No ASID (context) compare */
+#define _PAGE_DIRTY 0x0100 /* C: page changed */
-/* These five software bits must be masked out when the entry is loaded
- * into the TLB.
+/* These 3 software bits must be masked out when the entry is loaded
+ * into the TLB, 2 SW bits left.
*/
#define _PAGE_EXEC 0x0008 /* software: i-cache coherency required */
#define _PAGE_GUARDED 0x0010 /* software: guarded access */
-#define _PAGE_DIRTY 0x0020 /* software: page changed */
-#define _PAGE_RW 0x0040 /* software: user write access allowed */
-#define _PAGE_ACCESSED 0x0080 /* software: page referenced */
+#define _PAGE_ACCESSED 0x0020 /* software: page referenced */
/* Setting any bits in the nibble with the follow two controls will
* require a TLB exception handler change. It is assumed unused bits
* are always zero.
*/
-#define _PAGE_HWWRITE 0x0100 /* h/w write enable: never set in Linux PTE */
-#define _PAGE_USER 0x0800 /* One of the PP bits, the other is USER&~RW */
+#define _PAGE_RW 0x0400 /* lsb PP bits, inverted in HW */
+#define _PAGE_USER 0x0800 /* msb PP bits */
#define _PMD_PRESENT 0x0001
#define _PMD_BAD 0x0ff0
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 52ff8c5..2011230 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -333,26 +333,20 @@ InstructionTLBMiss:
mfspr r11, SPRN_MD_TWC /* ....and get the pte address */
lwz r10, 0(r11) /* Get the pte */
-#ifdef CONFIG_SWAP
- /* do not set the _PAGE_ACCESSED bit of a non-present page */
- andi. r11, r10, _PAGE_PRESENT
- beq 4f
- ori r10, r10, _PAGE_ACCESSED
- mfspr r11, SPRN_MD_TWC /* get the pte address again */
- stw r10, 0(r11)
-4:
-#else
- ori r10, r10, _PAGE_ACCESSED
- stw r10, 0(r11)
-#endif
+ andi. r11, r10, _PAGE_ACCESSED | _PAGE_PRESENT
+ cmpwi cr0, r11, _PAGE_ACCESSED | _PAGE_PRESENT
+ bne- cr0, 2f
+
+ /* Clear PP lsb, 0x400 */
+ rlwinm r10, r10, 0, 22, 20
/* The Linux PTE won't go exactly into the MMU TLB.
- * Software indicator bits 21, 22 and 28 must be clear.
+ * Software indicator bits 22 and 28 must be clear.
* Software indicator bits 24, 25, 26, and 27 must be
* set. All other Linux PTE bits control the behavior
* of the MMU.
*/
-2: li r11, 0x00f0
+ li r11, 0x00f0
rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
DO_8xx_CPU6(0x2d80, r3)
mtspr SPRN_MI_RPN, r10 /* Update TLB entry */
@@ -365,6 +359,22 @@ InstructionTLBMiss:
lwz r3, 8(r0)
#endif
rfi
+2:
+ mfspr r11, SPRN_SRR1
+ /* clear all error bits as TLB Miss
+ * sets a few unconditionally
+ */
+ rlwinm r11, r11, 0, 0xffff
+ mtspr SPRN_SRR1, r11
+
+ mfspr r10, SPRN_M_TW /* Restore registers */
+ lwz r11, 0(r0)
+ mtcr r11
+ lwz r11, 4(r0)
+#ifdef CONFIG_8xx_CPU6
+ lwz r3, 8(r0)
+#endif
+ b InstructionAccess
. = 0x1200
DataStoreTLBMiss:
@@ -409,21 +419,27 @@ DataStoreTLBMiss:
DO_8xx_CPU6(0x3b80, r3)
mtspr SPRN_MD_TWC, r11
-#ifdef CONFIG_SWAP
- /* do not set the _PAGE_ACCESSED bit of a non-present page */
- andi. r11, r10, _PAGE_PRESENT
- beq 4f
- ori r10, r10, _PAGE_ACCESSED
-4:
- /* and update pte in table */
-#else
- ori r10, r10, _PAGE_ACCESSED
-#endif
- mfspr r11, SPRN_MD_TWC /* get the pte address again */
- stw r10, 0(r11)
+ /* Both _PAGE_ACCESSED and _PAGE_PRESENT has to be set.
+ * We also need to know if the insn is a load/store, so:
+ * Clear _PAGE_PRESENT and load that which will
+ * trap into DTLB Error with store bit set accordinly.
+ */
+ /* PRESENT=0x1, ACCESSED=0x20
+ * r11 = ((r10 & PRESENT) & ((r10 & ACCESSED) >> 5));
+ * r10 = (r10 & ~PRESENT) | r11;
+ */
+ rlwinm r11, r10, 32-5, 31, 31
+ and r11, r11, r10
+ rlwimi r10, r11, 0, 31, 31
+
+ /* Honour kernel RO, User NA */
+ andi. r11, r10, _PAGE_USER | _PAGE_RW
+ bne- cr0, 5f
+ ori r10,r10, 0x200 /* Extended encoding, bit 22 */
+5: xori r10, r10, _PAGE_RW /* invert RW bit */
/* The Linux PTE won't go exactly into the MMU TLB.
- * Software indicator bits 21, 22 and 28 must be clear.
+ * Software indicator bits 22 and 28 must be clear.
* Software indicator bits 24, 25, 26, and 27 must be
* set. All other Linux PTE bits control the behavior
* of the MMU.
@@ -469,11 +485,12 @@ DataTLBError:
stw r10, 0(r0)
stw r11, 4(r0)
- /* First, make sure this was a store operation.
+ mfspr r11, SPRN_DSISR
+ andis. r11, r11, 0x4800 /* !translation or protection */
+ bne 2f /* branch if either is set */
+ /* Only Change bit left now, do it here as it is faster
+ * than trapping to the C fault handler.
*/
- mfspr r10, SPRN_DSISR
- andis. r11, r10, 0x0200 /* If set, indicates store op */
- beq 2f
/* The EA of a data TLB miss is automatically stored in the MD_EPN
* register. The EA of a data TLB error is automatically stored in
@@ -522,26 +539,12 @@ DataTLBError:
mfspr r11, SPRN_MD_TWC /* ....and get the pte address */
lwz r10, 0(r11) /* Get the pte */
- andi. r11, r10, _PAGE_RW /* Is it writeable? */
- beq 2f /* Bail out if not */
-
- /* Update 'changed', among others.
- */
-#ifdef CONFIG_SWAP
- ori r10, r10, _PAGE_DIRTY|_PAGE_HWWRITE
- /* do not set the _PAGE_ACCESSED bit of a non-present page */
- andi. r11, r10, _PAGE_PRESENT
- beq 4f
- ori r10, r10, _PAGE_ACCESSED
-4:
-#else
- ori r10, r10, _PAGE_DIRTY|_PAGE_ACCESSED|_PAGE_HWWRITE
-#endif
- mfspr r11, SPRN_MD_TWC /* Get pte address again */
+ ori r10, r10, _PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_HWWRITE
stw r10, 0(r11) /* and update pte in table */
+ xori r10, r10, _PAGE_RW /* RW bit is inverted */
/* The Linux PTE won't go exactly into the MMU TLB.
- * Software indicator bits 21, 22 and 28 must be clear.
+ * Software indicator bits 22 and 28 must be clear.
* Software indicator bits 24, 25, 26, and 27 must be
* set. All other Linux PTE bits control the behavior
* of the MMU.
--
1.6.4.4
^ permalink raw reply related
* [PATCH 3/8] 8xx: Tag DAR with 0x00f0 to catch buggy instructions.
From: Joakim Tjernlund @ 2009-10-15 9:04 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
In-Reply-To: <1255597466-30976-3-git-send-email-Joakim.Tjernlund@transmode.se>
dcbz, dcbf, dcbi, dcbst and icbi do not set DAR when they
cause a DTLB Error. Dectect this by tagging DAR with 0x00f0
at every exception exit that modifies DAR.
Test for DAR=0x00f0 in DataTLBError and bail
to handle_page_fault().
---
arch/powerpc/kernel/head_8xx.S | 15 ++++++++++++++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 2011230..bca22fa 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -206,6 +206,8 @@ MachineCheck:
EXCEPTION_PROLOG
mfspr r4,SPRN_DAR
stw r4,_DAR(r11)
+ li r5,0x00f0
+ mtspr SPRN_DAR,r5 /* Tag DAR, to be used in DTLB Error */
mfspr r5,SPRN_DSISR
stw r5,_DSISR(r11)
addi r3,r1,STACK_FRAME_OVERHEAD
@@ -222,6 +224,8 @@ DataAccess:
stw r10,_DSISR(r11)
mr r5,r10
mfspr r4,SPRN_DAR
+ li r10,0x00f0
+ mtspr SPRN_DAR,r10 /* Tag DAR, to be used in DTLB Error */
EXC_XFER_EE_LITE(0x300, handle_page_fault)
/* Instruction access exception.
@@ -244,6 +248,8 @@ Alignment:
EXCEPTION_PROLOG
mfspr r4,SPRN_DAR
stw r4,_DAR(r11)
+ li r5,0x00f0
+ mtspr SPRN_DAR,r5 /* Tag DAR, to be used in DTLB Error */
mfspr r5,SPRN_DSISR
stw r5,_DSISR(r11)
addi r3,r1,STACK_FRAME_OVERHEAD
@@ -445,6 +451,7 @@ DataStoreTLBMiss:
* of the MMU.
*/
2: li r11, 0x00f0
+ mtspr SPRN_DAR,r11 /* Tag DAR */
rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
DO_8xx_CPU6(0x3d80, r3)
mtspr SPRN_MD_RPN, r10 /* Update TLB entry */
@@ -485,6 +492,10 @@ DataTLBError:
stw r10, 0(r0)
stw r11, 4(r0)
+ mfspr r10, SPRN_DAR
+ cmpwi cr0, r10, 0x00f0
+ beq- 2f /* must be a buggy dcbX, icbi insn. */
+
mfspr r11, SPRN_DSISR
andis. r11, r11, 0x4800 /* !translation or protection */
bne 2f /* branch if either is set */
@@ -508,7 +519,8 @@ DataTLBError:
* are initialized in mapin_ram(). This will avoid the problem,
* assuming we only use the dcbi instruction on kernel addresses.
*/
- mfspr r10, SPRN_DAR
+
+ /* DAR is in r10 already */
rlwinm r11, r10, 0, 0, 19
ori r11, r11, MD_EVALID
mfspr r10, SPRN_M_CASID
@@ -550,6 +562,7 @@ DataTLBError:
* of the MMU.
*/
li r11, 0x00f0
+ mtspr SPRN_DAR,r11 /* Tag DAR */
rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
DO_8xx_CPU6(0x3d80, r3)
mtspr SPRN_MD_RPN, r10 /* Update TLB entry */
--
1.6.4.4
^ permalink raw reply related
* [PATCH 4/8] 8xx: Fixup DAR from buggy dcbX instructions.
From: Joakim Tjernlund @ 2009-10-15 9:04 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
In-Reply-To: <1255597466-30976-4-git-send-email-Joakim.Tjernlund@transmode.se>
This is an assembler version to fixup DAR not being set
by dcbX, icbi instructions. There are two versions, one
uses selfmodifing code, the other uses a
jump table but is much bigger(default).
---
arch/powerpc/kernel/head_8xx.S | 180 +++++++++++++++++++++++++++++++++++++++-
1 files changed, 176 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index bca22fa..320f333 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -494,11 +494,16 @@ DataTLBError:
mfspr r10, SPRN_DAR
cmpwi cr0, r10, 0x00f0
- beq- 2f /* must be a buggy dcbX, icbi insn. */
-
+ beq- FixupDAR /* must be a buggy dcbX, icbi insn. */
+DARFixed:/* Return from dcbx instruction bug workaround, r10 holds value of DAR */
mfspr r11, SPRN_DSISR
- andis. r11, r11, 0x4800 /* !translation or protection */
- bne 2f /* branch if either is set */
+ /* As the DAR fixup may clear store we may have all 3 states zero.
+ * Make sure only 0x0200(store) falls down into DIRTY handling
+ */
+ andis. r11, r11, 0x4a00 /* !translation, protection or store */
+ srwi r11, r11, 16
+ cmpwi cr0, r11, 0x0200 /* just store ? */
+ bne 2f
/* Only Change bit left now, do it here as it is faster
* than trapping to the C fault handler.
*/
@@ -604,6 +609,173 @@ DataTLBError:
. = 0x2000
+/* This is the procedure to calculate the data EA for buggy dcbx,dcbi instructions
+ * by decoding the registers used by the dcbx instruction and adding them.
+ * DAR is set to the calculated address and r10 also holds the EA on exit.
+ */
+#define NO_SELF_MODIFYING_CODE /* define if you don't want to use self modifying code */
+ nop /* A few nops to make the modified_instr: space below cache line aligned */
+ nop
+139: /* fetch instruction from userspace memory */
+ DO_8xx_CPU6(0x3780, r3)
+ mtspr SPRN_MD_EPN, r10
+ mfspr r11, SPRN_M_TWB /* Get level 1 table entry address */
+ lwz r11, 0(r11) /* Get the level 1 entry */
+ tophys (r11, r11)
+ DO_8xx_CPU6(0x3b80, r3)
+ mtspr SPRN_MD_TWC, r11 /* Load pte table base address */
+ mfspr r11, SPRN_MD_TWC /* ....and get the pte address */
+ lwz r11, 0(r11) /* Get the pte */
+ /* concat physical page address(r11) and page offset(r10) */
+ rlwimi r11, r10, 0, 20, 31
+ b 140f
+FixupDAR: /* Entry point for dcbx workaround. */
+ /* fetch instruction from memory. */
+ mfspr r10, SPRN_SRR0
+ andis. r11, r10, 0x8000
+ tophys (r11, r10)
+ beq- 139b /* Branch if user space address */
+140: lwz r11,0(r11)
+/* Check if it really is a dcbx instruction. */
+/* dcbt and dcbtst does not generate DTLB Misses/Errors,
+ * no need to include them here */
+ srwi r10, r11, 26 /* check if major OP code is 31 */
+ cmpwi cr0, r10, 31
+ bne- 141f
+ rlwinm r10, r11, 0, 21, 30
+ cmpwi cr0, r10, 2028 /* Is dcbz? */
+ beq+ 142f
+ cmpwi cr0, r10, 940 /* Is dcbi? */
+ beq+ 142f
+ cmpwi cr0, r10, 108 /* Is dcbst? */
+ beq+ 144f /* Fix up store bit! */
+ cmpwi cr0, r10, 172 /* Is dcbf? */
+ beq+ 142f
+ cmpwi cr0, r10, 1964 /* Is icbi? */
+ beq+ 142f
+141: mfspr r10, SPRN_DAR /* r10 must hold DAR at exit */
+ b DARfix /* Nope, go back to normal TLB processing */
+
+144: mfspr r10, SPRN_DSISR
+ rlwinm r10, r10,0,7,5 /* Clear store bit for buggy dcbst insn */
+ mtspr SPRN_DSISR, r10
+142: /* continue, it was a dcbx, dcbi instruction. */
+#ifdef CONFIG_8xx_CPU6
+ lwz r3, 8(r0) /* restore r3 from memory */
+#endif
+#ifndef NO_SELF_MODIFYING_CODE
+ andis. r10,r11,0x1f /* test if reg RA is r0 */
+ li r10,modified_instr@l
+ dcbtst r0,r10 /* touch for store */
+ rlwinm r11,r11,0,0,20 /* Zero lower 10 bits */
+ oris r11,r11,640 /* Transform instr. to a "add r10,RA,RB" */
+ ori r11,r11,532
+ stw r11,0(r10) /* store add/and instruction */
+ dcbf 0,r10 /* flush new instr. to memory. */
+ icbi 0,r10 /* invalidate instr. cache line */
+ lwz r11, 4(r0) /* restore r11 from memory */
+ mfspr r10, SPRN_M_TW /* restore r10 from M_TW */
+ isync /* Wait until new instr is loaded from memory */
+modified_instr:
+ .space 4 /* this is where the add/and instr. is stored */
+ bne+ 143f
+ subf r10,r0,r10 /* r10=r10-r0, only if reg RA is r0 */
+143: mtdar r10 /* store faulting EA in DAR */
+ b DARFixed /* Go back to normal TLB handling */
+#else
+ mfctr r10
+ mtdar r10 /* save ctr reg in DAR */
+ rlwinm r10, r11, 24, 24, 28 /* offset into jump table for reg RB */
+ addi r10, r10, 150f@l /* add start of table */
+ mtctr r10 /* load ctr with jump address */
+ xor r10, r10, r10 /* sum starts at zero */
+ bctr /* jump into table */
+150:
+ add r10, r10, r0
+ b 151f
+ add r10, r10, r1
+ b 151f
+ add r10, r10, r2
+ b 151f
+ add r10, r10, r3
+ b 151f
+ add r10, r10, r4
+ b 151f
+ add r10, r10, r5
+ b 151f
+ add r10, r10, r6
+ b 151f
+ add r10, r10, r7
+ b 151f
+ add r10, r10, r8
+ b 151f
+ add r10, r10, r9
+ b 151f
+ add r10, r10, r10
+ b 151f
+ add r10, r10, r11
+ b 151f
+ add r10, r10, r12
+ b 151f
+ add r10, r10, r13
+ b 151f
+ add r10, r10, r14
+ b 151f
+ add r10, r10, r15
+ b 151f
+ add r10, r10, r16
+ b 151f
+ add r10, r10, r17
+ b 151f
+ add r10, r10, r18
+ b 151f
+ add r10, r10, r19
+ b 151f
+ mtctr r11 /* r10 needs special handling */
+ b 154f
+ mtctr r11 /* r11 needs special handling */
+ b 153f
+ add r10, r10, r22
+ b 151f
+ add r10, r10, r23
+ b 151f
+ add r10, r10, r24
+ b 151f
+ add r10, r10, r25
+ b 151f
+ add r10, r10, r25
+ b 151f
+ add r10, r10, r27
+ b 151f
+ add r10, r10, r28
+ b 151f
+ add r10, r10, r29
+ b 151f
+ add r10, r10, r30
+ b 151f
+ add r10, r10, r31
+151:
+ rlwinm. r11,r11,19,24,28 /* offset into jump table for reg RA */
+ beq 152f /* if reg RA is zero, don't add it */
+ addi r11, r11, 150b@l /* add start of table */
+ mtctr r11 /* load ctr with jump address */
+ rlwinm r11,r11,0,16,10 /* make sure we don't execute this more than once */
+ bctr /* jump into table */
+152:
+ mfdar r11
+ mtctr r11 /* restore ctr reg from DAR */
+ mtdar r10 /* save fault EA to DAR */
+ b DARFixed /* Go back to normal TLB handling */
+
+ /* special handling for r10,r11 since these are modified already */
+153: lwz r11, 4(r0) /* load r11 from memory */
+ b 155f
+154: mfspr r11, SPRN_M_TW /* load r10 from M_TW */
+155: add r10, r10, r11 /* add it */
+ mfctr r11 /* restore r11 */
+ b 151b
+#endif
+
.globl giveup_fpu
giveup_fpu:
blr
--
1.6.4.4
^ permalink raw reply related
* [PATCH 0/8] Fix 8xx MMU/TLB
From: Joakim Tjernlund @ 2009-10-15 9:04 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
Now updated with Scott's remarks.
There is still(probably) a trivial conflict in pte-8xx.h
Joakim Tjernlund (8):
8xx: invalidate non present TLBs
8xx: Update TLB asm so it behaves as linux mm expects.
8xx: Tag DAR with 0x00f0 to catch buggy instructions.
8xx: Fixup DAR from buggy dcbX instructions.
8xx: Add missing Guarded setting in DTLB Error.
8xx: Restore _PAGE_WRITETHRU
8xx: start using dcbX instructions in various copy routines
8xx: Remove DIRTY pte handling in DTLB Error.
arch/powerpc/include/asm/pte-8xx.h | 14 +-
arch/powerpc/kernel/head_8xx.S | 341 +++++++++++++++++++++++------------
arch/powerpc/kernel/misc_32.S | 18 --
arch/powerpc/lib/copy_32.S | 24 ---
arch/powerpc/mm/fault.c | 8 +-
5 files changed, 238 insertions(+), 167 deletions(-)
^ permalink raw reply
* [PATCH 1/8] 8xx: invalidate non present TLBs
From: Joakim Tjernlund @ 2009-10-15 9:04 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
In-Reply-To: <1255597466-30976-1-git-send-email-Joakim.Tjernlund@transmode.se>
8xx sometimes need to load a invalid/non-present TLBs in
it DTLB asm handler.
These must be invalidated separaly as linux mm don't.
---
arch/powerpc/mm/fault.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 7699394..071e0ca 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -39,7 +39,7 @@
#include <asm/uaccess.h>
#include <asm/tlbflush.h>
#include <asm/siginfo.h>
-
+#include <mm/mmu_decl.h>
#ifdef CONFIG_KPROBES
static inline int notify_page_fault(struct pt_regs *regs)
@@ -243,6 +243,12 @@ good_area:
goto bad_area;
#endif /* CONFIG_6xx */
#if defined(CONFIG_8xx)
+ /* 8xx sometimes need to load a invalid/non-present TLBs.
+ * These must be invalidated separately as linux mm don't.
+ */
+ if (error_code & 0x40000000) /* no translation? */
+ _tlbil_va(address, 0, 0, 0);
+
/* The MPC8xx seems to always set 0x80000000, which is
* "undefined". Of those that can be set, this is the only
* one which seems bad.
--
1.6.4.4
^ permalink raw reply related
* [patch 3/3] powerpc: Mark init code __init in nvram_64
From: Thomas Gleixner @ 2009-10-15 8:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20091015085253.295880694@linutronix.de>
Mark all functions which are only called from nvram_init() __init.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org
---
arch/powerpc/kernel/nvram_64.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
Index: linux-2.6-tip/arch/powerpc/kernel/nvram_64.c
===================================================================
--- linux-2.6-tip.orig/arch/powerpc/kernel/nvram_64.c
+++ linux-2.6-tip/arch/powerpc/kernel/nvram_64.c
@@ -184,7 +184,7 @@ static struct miscdevice nvram_dev = {
#ifdef DEBUG_NVRAM
-static void nvram_print_partitions(char * label)
+static void __init nvram_print_partitions(char * label)
{
struct list_head * p;
struct nvram_partition * tmp_part;
@@ -202,7 +202,7 @@ static void nvram_print_partitions(char
#endif
-static int nvram_write_header(struct nvram_partition * part)
+static int __init nvram_write_header(struct nvram_partition * part)
{
loff_t tmp_index;
int rc;
@@ -214,7 +214,7 @@ static int nvram_write_header(struct nvr
}
-static unsigned char nvram_checksum(struct nvram_header *p)
+static unsigned char __init nvram_checksum(struct nvram_header *p)
{
unsigned int c_sum, c_sum2;
unsigned short *sp = (unsigned short *)p->name; /* assume 6 shorts */
@@ -228,7 +228,7 @@ static unsigned char nvram_checksum(stru
return c_sum;
}
-static int nvram_remove_os_partition(void)
+static int __init nvram_remove_os_partition(void)
{
struct list_head *i;
struct list_head *j;
@@ -294,7 +294,7 @@ static int nvram_remove_os_partition(voi
* Will create a partition starting at the first free
* space found if space has enough room.
*/
-static int nvram_create_os_partition(void)
+static int __init nvram_create_os_partition(void)
{
struct nvram_partition *part;
struct nvram_partition *new_part;
@@ -397,7 +397,7 @@ static int nvram_create_os_partition(voi
* 5.) If the max chunk cannot be allocated then try finding a chunk
* that will satisfy the minum needed (NVRAM_MIN_REQ).
*/
-static int nvram_setup_partition(void)
+static int __init nvram_setup_partition(void)
{
struct list_head * p;
struct nvram_partition * part;
@@ -455,7 +455,7 @@ static int nvram_setup_partition(void)
}
-static int nvram_scan_partitions(void)
+static int __init nvram_scan_partitions(void)
{
loff_t cur_index = 0;
struct nvram_header phead;
^ permalink raw reply
* [patch 2/3] powerpc: Check nvram_error_log_index in nvram_clear_error_log()
From: Thomas Gleixner @ 2009-10-15 8:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20091015085253.295880694@linutronix.de>
nvram_clear_error_log() calls ppc_md.nvram_write() even when
nvram_error_log_index is -1 (invalid). The nvram_write() function does
not check for a negative offset.
Check nvram_error_log_index as the other nvram log functions do.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org
---
arch/powerpc/kernel/nvram_64.c | 3 +++
1 file changed, 3 insertions(+)
Index: linux-2.6-tip/arch/powerpc/kernel/nvram_64.c
===================================================================
--- linux-2.6-tip.orig/arch/powerpc/kernel/nvram_64.c
+++ linux-2.6-tip/arch/powerpc/kernel/nvram_64.c
@@ -681,6 +681,9 @@ int nvram_clear_error_log(void)
int clear_word = ERR_FLAG_ALREADY_LOGGED;
int rc;
+ if (nvram_error_log_index == -1)
+ return -1;
+
tmp_index = nvram_error_log_index;
rc = ppc_md.nvram_write((char *)&clear_word, sizeof(int), &tmp_index);
^ permalink raw reply
* [patch 1/3] powerpc: Remove unused code
From: Thomas Gleixner @ 2009-10-15 8:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20091015085253.295880694@linutronix.de>
nvram_find_partition() has no user. The call site was removed in the
arch/powerpc move, but the function stayed. Remove it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org
---
arch/powerpc/include/asm/nvram.h | 1 -
arch/powerpc/kernel/nvram_64.c | 25 -------------------------
2 files changed, 26 deletions(-)
Index: linux-2.6-tip/arch/powerpc/include/asm/nvram.h
===================================================================
--- linux-2.6-tip.orig/arch/powerpc/include/asm/nvram.h
+++ linux-2.6-tip/arch/powerpc/include/asm/nvram.h
@@ -73,7 +73,6 @@ extern int nvram_write_error_log(char *
extern int nvram_read_error_log(char * buff, int length,
unsigned int * err_type, unsigned int *err_seq);
extern int nvram_clear_error_log(void);
-extern struct nvram_partition *nvram_find_partition(int sig, const char *name);
extern int pSeries_nvram_init(void);
Index: linux-2.6-tip/arch/powerpc/kernel/nvram_64.c
===================================================================
--- linux-2.6-tip.orig/arch/powerpc/kernel/nvram_64.c
+++ linux-2.6-tip/arch/powerpc/kernel/nvram_64.c
@@ -228,31 +228,6 @@ static unsigned char nvram_checksum(stru
return c_sum;
}
-
-/*
- * Find an nvram partition, sig can be 0 for any
- * partition or name can be NULL for any name, else
- * tries to match both
- */
-struct nvram_partition *nvram_find_partition(int sig, const char *name)
-{
- struct nvram_partition * part;
- struct list_head * p;
-
- list_for_each(p, &nvram_part->partition) {
- part = list_entry(p, struct nvram_partition, partition);
-
- if (sig && part->header.signature != sig)
- continue;
- if (name && 0 != strncmp(name, part->header.name, 12))
- continue;
- return part;
- }
- return NULL;
-}
-EXPORT_SYMBOL(nvram_find_partition);
-
-
static int nvram_remove_os_partition(void)
{
struct list_head *i;
^ permalink raw reply
* [patch 0/3] powerpc: Fixes for nvram_64
From: Thomas Gleixner @ 2009-10-15 8:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Ben,
while looking at the ioctl in nvram_64.c I noticed a couple of issues
which are addressed by the folling patch series.
Thanks,
tglx
^ 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