* Re: 8xx bus monitoring
From: Pantelis Antoniou @ 2005-01-31 7:09 UTC (permalink / raw)
To: robin.gilks; +Cc: ppc embedded list
In-Reply-To: <41FD5C91.404@tait.co.nz>
Robin Gilks wrote:
> Pantelis Antoniou wrote:
>
>> Robin Gilks wrote:
>>
>>> Greetings
>>>
>>> System is a MPC859 based controller.
>>>
>>> I'm trying to determine whether a peripheral is not responding to
>>> memory fetches by using the bus monitor feature on the Transfer
>>> Acknowledge (TA) signal. This is set to the maximum count in the Bus
>>> Monitor Timeout (BMT) in the System Protect Control Register (SYPCR).
>>> The monitoring is enabled by setting the Bus Monitor Enable (BME) bit
>>> in SYPCR as well.
>>>
>>> I understand that I can use the Transfer Error Status Register (TESR)
>>> to read the fact that I have had a timeout by checking the Data
>>> Transfer Monitor Timeout (DTMT) bit in this register.
>>>
>>> The problem is, how do I know any error has occured so I know to look
>>> at the TESR. I can't see a way of generating an exception from this
>>> condition.
>>>
>>> Any help appreciated.
>>>
>>
>> You get a machine check exception.
>>
>> It's pretty obvious then :)
>>
>
> Using a 2.4.22 based kernel, as far as I can see a machine check should
> be trapped (its only allowed to cause a reset in the reboot code I
> think). Assuming I got it right and it really is trapped, how come I
> always get a reset:-((
>
> Any pointers to the code that does setup for causing an exception
> (rather than reset) would be appreciated.
>
Check the MSR register at the time of the access.
Is RI set? If not instead of an exception you get a reset...
Regards
Pantelis
^ permalink raw reply
* Re: 8xx bus monitoring
From: Robin Gilks @ 2005-01-30 22:15 UTC (permalink / raw)
To: ppc embedded list
In-Reply-To: <41F74169.9050006@intracom.gr>
Pantelis Antoniou wrote:
> Robin Gilks wrote:
>
>> Greetings
>>
>> System is a MPC859 based controller.
>>
>> I'm trying to determine whether a peripheral is not responding to
>> memory fetches by using the bus monitor feature on the Transfer
>> Acknowledge (TA) signal. This is set to the maximum count in the Bus
>> Monitor Timeout (BMT) in the System Protect Control Register (SYPCR).
>> The monitoring is enabled by setting the Bus Monitor Enable (BME) bit
>> in SYPCR as well.
>>
>> I understand that I can use the Transfer Error Status Register (TESR)
>> to read the fact that I have had a timeout by checking the Data
>> Transfer Monitor Timeout (DTMT) bit in this register.
>>
>> The problem is, how do I know any error has occured so I know to look
>> at the TESR. I can't see a way of generating an exception from this
>> condition.
>>
>> Any help appreciated.
>>
>
> You get a machine check exception.
>
> It's pretty obvious then :)
>
Using a 2.4.22 based kernel, as far as I can see a machine check should
be trapped (its only allowed to cause a reset in the reboot code I
think). Assuming I got it right and it really is trapped, how come I
always get a reset:-((
Any pointers to the code that does setup for causing an exception
(rather than reset) would be appreciated.
--
Robin Gilks
Senior Design Engineer Phone: (+64)(3) 357 1569
Tait Electronics Fax : (+64)(3) 359 4632
PO Box 1645 Christchurch Email : robin.gilks@tait.co.nz
New Zealand
=======================================================================
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
=======================================================================
^ permalink raw reply
* ppc 8260 ethernet driver fails to put port into promiscuous or mu lticast modes
From: Eyal Ofer-R55413 @ 2005-01-30 5:50 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
hello,
1. the function in the ppc 8260 ethernet driver that's suppose to put the interface into promiscuous or multicast modes contains a 'return' statement immediately at the beginning. this prevents running an 8260-based system as a bridge for example. the 'return' statement is not indented, and there's no comment to explain it. it is unclear if it was forgotten there by the writer or whether it serves some functional role (improve performance for other modes of operations, cover up for untested code later, etc.). removing it does not seem to hurt the operation of the system though. unless there's a known use for this 'return', i would like to suggest the following patch (demonstrated here for 2.4.22):
--- fcc_enet.c.orig Thu Jan 27 07:56:35 2005
+++ fcc_enet.c Thu Jan 27 07:57:00 2005
@@ -1080,7 +1080,6 @@
cep = (struct fcc_enet_private *)dev->priv;
-return;
/* Get pointer to FCC area in parameter RAM.
*/
ep = (fcc_enet_t *)dev->base_addr;
problem persists ever since the driver's introduction into the 2.4.0-test9-pre2 kernel and up to it's latest version in 2.6.10
path to problem:
early 2.4.x and all 2.6.x:
arch/ppc/8260_io/fcc_enet.c
later 2.4.2x (at least 2.4.26 and on):
arc/ppc/cpm_io/fcc_enet.c
problem in function: set_multicast_list()
2. please CC me personally on answer as i'm not a subscriber on the lkml.
best regards,
ofer eyal
Metrowerks - Freescale Semiconductor Israel
Tel +972-9-952-2504 Fax +972-9-952-2890
freescale semiconductor general business use
^ permalink raw reply
* mmap on Virtex-II Pro
From: Joshua Lamorie @ 2005-01-30 0:54 UTC (permalink / raw)
To: linuxppc-embedded
Gidday there,
I have Linux running on a Virtex-II Pro system (with a second FPGA
connected by a custom OPB/PLB bridge).
I have a device on the OPB bus that I want to provide to applications
through mmap. However, with my current implementation there are some
strange behaviours.
If I mmap in my application, I can read everything in the device memory
(in blockram and other registers) with no problems.
However if I write only a few bytes, they don't seem to go through to
the memory area, and instead some of the memory is cleared. When I
write a large number of values (e.g. the counter in a for loop). The
values show up, but the first 4 bytes are missing, and it only writes
every other 4 bytes. For example...
0000:0000 | 04 05 06 07 00 00 00 00 0c 0d 0e 0f 00 00 00 00
0000:0010 | 14 15 16 17 00 00 00 00 1c 1d 1e 1f 00 00 00 00
I'm using Rubini's Linux Device Drivers 2nd edition as a reference and
inside the mmap function of my module I simply do
remap_page_range(vm_start,physical_address, vm_end-vm_start,vm_page_prot)
I did a quick search through the archives and I noticed that there was a
call io_remap_page_range but that is just a macro pointing to
remap_page_ranger. I also noticed that pgprot_noncached was used in a
64 bit instance, but that doesn't exist in my kernel.
I'm using 2.4.26, probably almost a year old now.
Are there any simple examples of mapping OPB memory to user space?
I'm also setting a couple of vm_flags such as VM_IO and VM_RESERVED.
Could there be a magic one that I'm missing? I know that there are some
elements of the busses connected to the PPC405 in the Virtex-II Pro that
are 64-bit... is it possible that I'm mapping a 64-bit area and nothing
is correctly written?
Thanks in advance for any advice.
Joshua
--
Xiphos Technologies
(514) 848-9640 x227
(514) 848-9644 fax
www.xiplink.com
_______________________________________________
The information transmitted is intended only for the
person or entity to which it is addressed and may contain
confidential and/or privileged material. If you have
received this in error, please contact the sender and delete
this communication and any copy immediately. Thank you.
^ permalink raw reply
* IDE DMA info part 2
From: John F Davis @ 2005-01-29 18:20 UTC (permalink / raw)
To: linuxppc-embedded
Hello
I almost forgot. Here is some additional output from the VIA chipset proc
file and the weirdness as reported by hdparm concerning this disk.
hdparm -i /dev/hda
-------------------------------
/dev/hda:
Model=FUJITSU MHT2020AT, FwRev=009B, SerialNo=NN11T451AP9S
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=39070080
IORDY=yes, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 *udma2 udma3 udma4 udma5
AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled
Drive conforms to: ATA/ATAPI-6 T13 1410D revision 3a:
* signifies the current active mode
What is weird about this is that currently hdparm -d /dev/hda shows this:
---------------------------------------------------------------------------------------------------------
/dev/hda:
using_dma = 0 (off)
hdparm -I /dev/hda
----------------------------------
/dev/hda:
ATA device, with non-removable media
powers-up in standby; SET FEATURES subcmd spins-up.
WARNING: ID response incomplete.
WARNING: Following data may be incorrect.
Model Number: UFIJST UHM2T20A0 T
Serial Number: NN114T15PAS9
Firmware Revision: 00B9
Standards:
Supported: 14 13 12 11
Likely used: 14
Configuration:
Logical max current
cylinders 65343 0
heads 4096 0
sectors/track 16128 0
--
device size with M = 1024*1024: 2107703808 MBytes
device size with M = 1000*1000: 2210087628 MBytes (2210087 GB)
Capabilities:
IORDY(may be)(cannot be disabled)
Queue depth: 1
Standby timer values: spec'd by Vendor
R/W multiple sector transfer: Max = 128 Current = ?
Advanced power management level: unknown setting (0x8040)
Recommended acoustic management value: 254, current value: 254
DMA: not supported
PIO: unknown
Security:
Master password revision code = 65279
supported
not enabled
not locked
not frozen
not expired: security count
not supported: enhanced erase
Checksum: correct
cat /proc/ide/via
----------VIA BusMastering IDE Configuration----------------
Driver Version: 3.37
South Bridge: VIA vt82c686b
Revision: ISA 0x40 IDE 0x6
Highest DMA rate: UDMA100
BM-DMA base: 0xffd0
PCI clock: 33.3MHz
Master Read Cycle IRDY: 0ws
Master Write Cycle IRDY: 0ws
BM IDE Status Register Read Retry: yes
Max DRDY Pulse Width: No limit
-----------------------Primary IDE-------Secondary IDE------
Read DMA FIFO flush: yes yes
End Sector FIFO flush: no no
Prefetch Buffer: no no
Post Write Buffer: no no
Enabled: yes yes
Simplex only: no no
Cable Type: 40w 40w
-------------------drive0----drive1----drive2----drive3-----
Transfer Mode: PIO PIO PIO PIO
Address Setup: 30ns 120ns 120ns 120ns
Cmd Active: 90ns 90ns 480ns 480ns
Cmd Recovery: 30ns 30ns 480ns 480ns
Data Active: 90ns 330ns 330ns 330ns
Data Recovery: 30ns 270ns 270ns 270ns
Cycle Time: 120ns 600ns 600ns 600ns
Transfer Rate: 16.6MB/s 3.3MB/s 3.3MB/s 3.3MB/s
cat /proc/dma
-------------------------
4: cascade
^ permalink raw reply
* ppc405 core, VIA VT82C686A chipset, linux_2.4.22_pre5, and IDE DMA woes
From: John F Davis @ 2005-01-29 18:12 UTC (permalink / raw)
To: linuxppc-embedded
Hello
I am trying to get DMA working on a ppc405 core on a custom SOC with IDE
DMA using a VIA VT82C686A southbridge. I apologize for the length of this
note.
Here is my environment, configuration, attempts at fixing the system, what
works, and what doesn't.
o Using linux 2.4.22 pre5 kernel from ppc devel bitkeeper tree. Using
cross compiler gcc version 3.2.3
o On this box non dma IDE works flawlessy with and without 405 data
caching.
o DMA IDE works when caching is disabled. When caching is enabled and
DMA ide is enabled, the system works for a while and then it gets a Data
Storage Exception when it tries to do a write. The exception is usually
involves writing to a very similar address no matter how and when the
exception occurs.
o I am using hdparm to enable and disable the IDE DMA at the command
line. I ususally cause the oops by running consecutive hdparm tests from
two different TTY logins. If that does not cause it to oops then starting
X windows, playing a movie from disk and then issuing the hdparm test most
certainly will.
o Here are some sample oops messages and ksymoops interpetations. (There
is more info after the oops messages.)
# Oops: kernel access of bad area, sig: 11
NIP: A002EC04 XER: 20000000 LR: A002EB84 SP: ACBC5D60 REGS: acbc5cb0 TRAP:
0800 Tainted: P
MSR: 00001030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
DEAR: 5459545D, ESR: 00800000
TASK = acbc4000[156] 'xine' Last syscall: 4
last math 00000000 last altivec 00000000
PLB0: bear= 0x00000000 acr= 0x00000000 besr= 0x00000000
PLB0 to OPB: bear= 0xc27e3183 besr0= 0xc0000000 besr1= 0x00000000
GPR00: 00000000 ACBC5D60 ACBC4000 00000001 00009030 00000001 000009B0
AB126000
GPR08: FFFFFFFF AB14F020 54595459 A02E9DDC 24044082 10115790 00000000
100E10B0
GPR16: ACBC5EA0 AB0FE000 A007ACA8 ACBC5E08 AEB3F080 AEB3F080 000009B0
00001000
GPR24: 00000000 A04D2BA8 00000001 00000000 00001000 000000F0 AB126F60
A02E9DD4
Call backtrace:
00000003 A002E3E4 A003A084 A003A1C0 A003A504 A003AC90 A003B4D8
A007B000 A002A874 A002AECC A0037564 A000279C 0FECCD18 0EFC53BC
0FF50A48 0FEC7914 0FC0B408
produces:*************************
>>NIP; a002ec04 <kmem_find_general_cachep+6ec/2614> <=====
>>GPR1; acbc5d60 <_end+c925038/12618420>
>>GPR2; acbc4000 <_end+c9232d8/12618420>
>>GPR7; ab126000 <_end+ae852d8/12618420>
>>GPR9; ab14f020 <_end+aeae2f8/12618420>
>>GPR11; a02e9ddc <_end+490b4/12618420>
>>GPR16; acbc5ea0 <_end+c925178/12618420>
>>GPR17; ab0fe000 <_end+ae5d2d8/12618420>
>>GPR18; a007aca8 <journal_blocks_per_page+4340/87fc>
>>GPR19; acbc5e08 <_end+c9250e0/12618420>
>>GPR20; aeb3f080 <_end+e89e358/12618420>
>>GPR21; aeb3f080 <_end+e89e358/12618420>
>>GPR25; a04d2ba8 <_end+231e80/12618420>
>>GPR30; ab126f60 <_end+ae86238/12618420>
>>GPR31; a02e9dd4 <_end+490ac/12618420>
Trace; 00000003 Before first symbol
Trace; a002e3e4 <kmem_cache_alloc+10/20>
Trace; a003a084 <get_unused_buffer_head+68/c8>
Trace; a003a1c0 <set_bh_page+dc/334>
Trace; a003a504 <create_empty_buffers+24/908>
Trace; a003ac90 <create_empty_buffers+7b0/908>
Trace; a003b4d8 <block_prepare_write+34/a8>
Trace; a007b000 <journal_blocks_per_page+4698/87fc>
Trace; a002a874 <read_cache_page+5f4/aac>
Trace; a002aecc <generic_file_write+1a0/2400>
Trace; a0037564 <default_llseek+490/e10>
Trace; a000279c <set_context+3b4/5e0>
Trace; 0feccd18 Before first symbol
Trace; 0efc53bc Before first symbol
Trace; 0ff50a48 Before first symbol
Trace; 0fec7914 Before first symbol
Trace; 0fc0b408 Before first symbol
5 warnings and 2 errors issued. Results may not be reliable.
===========================================================
>>NIP; a002ec40 <kmem_find_general_cachep+728/2614> <=====
>>GPR1; ab53dd10 <_end+b29cfe8/125fe420>
>>GPR2; ab53c000 <_end+b29b2d8/125fe420>
>>GPR7; ad4f0000 <_end+d24f2d8/125fe420>
>>GPR8; a0270000 <ide_register_driver+9e3c/be50>
>>GPR9; a02e9ddc <_end+490b4/125fe420>
>>GPR11; a02e9de4 <_end+490bc/125fe420>
>>GPR18; a00284d0 <do_generic_file_read+73c/804>
>>GPR19; ada5ff60 <_end+d7bf238/125fe420>
>>GPR20; ab53ded8 <_end+b29d1b0/125fe420>
>>GPR21; a003ea04 <sb_min_blocksize+60/4c8>
>>GPR25; a052bd04 <_end+28afdc/125fe420>
>>GPR30; a02e9ddc <_end+490b4/125fe420>
>>GPR31; a02e9dd4 <_end+490ac/125fe420>
Trace; 00000000 Before first symbol
Trace; a002e3e4 <kmem_cache_alloc+10/20>
Trace; a003a084 <get_unused_buffer_head+68/c8>
Trace; a003a1c0 <set_bh_page+dc/334>
Trace; a003a504 <create_empty_buffers+24/908>
Trace; a003b094 <block_read_full_page+2ac/2d8>
Trace; a003ead0 <sb_min_blocksize+12c/4c8>
Trace; a00272b4 <filemap_fdatawait+414/4dc>
Trace; a0027c40 <grab_cache_page_nowait+22c/380>
Trace; a0028108 <do_generic_file_read+374/804>
Trace; a0028640 <generic_file_read+a8/9d4>
Trace; a0037414 <default_llseek+340/e10>
Trace; a000279c <set_context+3b8/5e4>
Trace; 00000000 Before first symbol
Trace; 10001dcc Before first symbol
Trace; 10002ba4 Before first symbol
Trace; 10003f94 Before first symbol
Trace; 0fee4920 Before first symbol
Trace; 00000000 Before first symbol
=======================================================
Trace; a00190dc <__tasklet_hi_schedule+204/250>
Trace; a002e3e4 <kmem_cache_alloc+10/20>
Trace; a003a084 <get_unused_buffer_head+68/c8>
Trace; a003a1c0 <set_bh_page+dc/334>
Trace; a003a504 <create_empty_buffers+24/908>
Trace; a003b094 <block_read_full_page+2ac/2d8>
Trace; a003ead0 <sb_min_blocksize+12c/4c8>
Trace; a00272b4 <filemap_fdatawait+414/4dc>
Trace; a0027c40 <grab_cache_page_nowait+22c/380>
Trace; a0027f3c <do_generic_file_read+1a8/804>
Trace; a0028640 <generic_file_read+a8/9d4>
Trace; a0037414 <default_llseek+340/e10>
Trace; a000279c <set_context+3b8/5e4>
Trace; 00000000 Before first symbol
Trace; 10001dcc Before first symbol
Trace; 10002ba4 Before first __ide_dma_write
symbol
Trace; 1__ide_dma_write
0003f94 Before first symbol
Trace; 0fee4920 Before first symbol
Trace; 00000000 Before first symbol
i========================================
# Oops: kernel access of bad area, sig: 11
NIP: A002EC40 XER: 20000000 LR: A002EB84 SP: AF40BD10 REGS: af40bc60 TRAP:
0800 Tainted: P
MSR: 00001030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
DEAR: 54D954DD, ESR: 00800000
TASK = af40a000[292] 'hdparm' Last syscall: 3
last math 00000000 last altivec 00000000
PLB0: bear= 0x60000000 acr= 0x00000000 besr= 0x00000000
PLB0 to OPB: bear= 0xc27e3183 besr0= 0xc0000000 besr1= 0x00000000
GPR00: 00000000 AF40BD10 AF40A000 00000001 00009030 00000001 0000000A
AC091000
GPR08: A0270000 A02E9DDC 54D954D9 A02E9DE4 84002082 101EDDE4 00000000
00000000
GPR16: 00000000 00000000 A00284D0 ADC0E760 AF40BED8 A003EA04 00000001
00000000
GPR24: 00000C00 A045BBA0 00000001 00000000 00000400 000000F0 A02E9DDC
A02E9DD4
Call backtrace:
A045FED4 A002E3E4 A003A084 A003A1C0 A003A504 A003B094 A003EAD0
A00272B4 A0027C40 A0028108 A0028640 A0037414 A000279C 00000000
10001DCC 10002BA4 10003F94 0FEE4920 00000000
# Oops: kernel access of bad area, sig: 11
NIP: A002EC40 XER: 20000000 LR: A002EB84 SP: AF40BD10 REGS: af40bc60 TRAP:
0800 Tainted: P
MSR: 00001030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
DEAR: 54D954DD, ESR: 00800000
TASK = af40a000[292] 'hdparm' Last syscall: 3
last math 00000000 last altivec 00000000
PLB0: bear= 0x60000000 acr= 0x00000000 besr= 0x00000000
PLB0 to OPB: bear= 0xc27e3183 besr0= 0xc0000000 besr1= 0x00000000
GPR00: 00000000 AF40BD10 AF40A000 00000001 00009030 00000001 0000000A
AC091000
GPR08: A0270000 A02E9DDC 54D954D9 A02E9DE4 84002082 101EDDE4 00000000
00000000
GPR16: 00000000 00000000 A00284D0 ADC0E760 AF40BED8 A003EA04 00000001
00000000
GPR24: 00000C00 A045BBA0 00000001 00000000 00000400 000000F0 A02E9DDC
A02E9DD4
Call backtrace:
A045FED4 A002E3E4 A003A084 A003A1C0 A003A504 A003B094 A003EAD0
A00272B4 A0027C40 A0028108 A0028640 A0037414 A000279C 00000000
10001DCC 10002BA4 10003F94 0FEE4920 00000000
>>NIP; a002ec40 <kmem_find_general_cachep+728/2614> <=====
>>GPR1; af40bd10 <_end+f16afe8/125fe420>
>>GPR2; af40a000 <_end+f1692d8/125fe420>
>>GPR7; ac091000 <_end+bdf02d8/125fe420>
>>GPR8; a0270000 <ide_register_driver+9e3c/be50>
>>GPR9; a02e9ddc <_end+490b4/125fe420>
>>GPR11; a02e9de4 <_end+490bc/125fe420>
>>GPR18; a00284d0 <do_generic_file_read+73c/804>
>>GPR19; adc0e760 <_end+d96da38/125fe420>
>>GPR20; af40bed8 <_end+f16b1b0/125fe420>
>>GPR21; a003ea04 <sb_min_blocksize+60/4c8>
>>GPR25; a045bba0 <_end+1bae78/125fe420>
>>GPR30; a02e9ddc <_end+490b4/125fe420>
>>GPR31; a02e9dd4 <_end+490ac/125fe420>
Trace; a045fed4 <_end+1bf1ac/125fe420>
Trace; a002e3e4 <kmem_cache_alloc+10/20>
Trace; a003a084 <get_unused_buffer_head+68/c8>
Trace; a003a1c0 <set_bh_page+dc/334>
Trace; a003a504 <create_empty_buffers+24/908>
Trace; a003b094 <block_read_full_page+2ac/2d8>
Trace; a003ead0 <sb_min_blocksize+12c/4c8>
Trace; a00272b4 <filemap_fdatawait+414/4dc>
Trace; a0027c40 <grab_cache_page_nowait+22c/380>
Trace; a0028108 <do_generic_file_read+374/804>
Trace; a0028640 <generic_file_read+a8/9d4>
Trace; a0037414 <default_llseek+340/e10>
Trace; a000279c <set_context+3b8/5e4>
Trace; 00000000 Before first symbol
Trace; 10001dcc Before first symbol
Trace; 10002ba4 Before first symbol
Trace; 10003f94 Before first symbol
Trace; 0fee4920 Before first symbol
Trace; 00000000 Before first symbol
==========================================================
added the debug code to drivers/block/ll_rw_blk.c
#Oops: kernel access of bad area, sig: 11
NIP: A002EC04 XER: 20000000 LR: A002EB84 SP: ACF25D60 REGS: acf25cb0 TRAP:
0800 Tainted: P
MSR: 00001030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
DEAR: 54D954DD, ESR: 00800000
TASK = acf24000[139] 'xine' Last syscall: 4
last math 00000000 last altivec 00000000
PLB0: bear= 0x60000000 acr= 0x00000000 besr= 0x00000000
PLB0 to OPB: bear= 0xc27e3183 besr0= 0xc0000000 besr1= 0x00000000
GPR00: 00000000 ACF25D60 ACF24000 00000001 00009030 00000001 0000042C
AB9F1000
GPR08: FFFFFFFF ABA1A020 54D954D9 A02E9DDC 24044082 10115790 00000000
100E10B0
GPR16: ACF25EA0 AB9CE000 A007ACA8 ACF25E08 AC58F680 AC58F680 0000042C
00001000
GPR24: 00000000 A04EAF68 00000001 00000000 00001000 000000F0 AB9F1F60
A02E9DD4
Call backtrace:
00000003 A002E3E4 A003A084 A003A1C0 A003A504 A003AC90 A003B4D8
A007B000 A002A874 A002AECC A0037564 A000279C 0FECCD18 0EFC53BC
0FF50A48 0FEC7914 0FC0B408
Was so hosed I could not run ksymoops.
================================
Timing buffered disk reads: Oops: kernel access of bad area, sig: 11
NIP: A002EC28 XER: 20000000 LR: A002EB84 SP: AE1F7D10 REGS: ae1f7c60 TRAP:
0800 Tainted: P
MSR: 00001030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
DEAR: 54D954D9, ESR: 00000000
TASK = ae1f6000[131] 'hdparm' Last syscall: 3
last math 00000000 last altivec 00000000
PLB0: bear= 0x60000000 acr= 0x00000000 besr= 0x00000000
PLB0 to OPB: bear= 0xc27e3183 besr0= 0xc0000000 besr1= 0x00000000
GPR00: A02E9DE4 AE1F7D10 AE1F6000 00000001 00009030 00000002 00000003
54D954D9
GPR08: A0270000 00000000 A0270000 00000001 84002042 10025468 00000000
00000000
GPR16: 00000000 00000000 A00284D0 AC3CE760 AE1F7ED8 A003EA1C 00000000
00000000
GPR24: 00000C00 A054755C 00000001 00000000 00000400 000000F0 A02E9DDC
A02E9DD4
Call backtrace:
A00190DC A002E3E4 A003A09C A003A1D8 A003A51C A003B0AC A003EAE8
A00272B4 A0027C40 A0027F3C A0028640 A0037414 A000279C 00000000
10001DCC 10002BA4 10003F94 0FEE4920 00000000
Segmentation fault
Warning (Oops_read): Code line not seen, dumping what data is available
>>NIP; a002ec28 <kmem_find_general_cachep+710/2614> <=====
>>GPR0; a02e9de4 <_end+490bc/125fe420>
>>GPR1; ae1f7d10 <_end+df56fe8/125fe420>
>>GPR2; ae1f6000 <_end+df552d8/125fe420>
>>GPR8; a0270000 <ide_register_driver+9e3c/be50>
>>GPR10; a0270000 <ide_register_driver+9e3c/be50>
>>GPR18; a00284d0 <do_generic_file_read+73c/804>
>>GPR19; ac3ce760 <_end+c12da38/125fe420>
>>GPR20; ae1f7ed8 <_end+df571b0/125fe420>
>>GPR21; a003ea1c <sb_min_blocksize+60/4c8>
>>GPR25; a054755c <_end+2a6834/125fe420>
>>GPR30; a02e9ddc <_end+490b4/125fe420>
>>GPR31; a02e9dd4 <_end+490ac/125fe420>
Trace; a00190dc <__tasklet_hi_schedule+204/250>
Trace; a002e3e4 <kmem_cache_alloc+10/20>
Trace; a003a09c <get_unused_buffer_head+80/e0>
Trace; a003a1d8 <set_bh_page+dc/334>
Trace; a003a51c <create_empty_buffers+24/908>
Trace; a003b0ac <block_read_full_page+2ac/2d8>
Trace; a003eae8 <sb_min_blocksize+12c/4c8>
Trace; a00272b4 <filemap_fdatawait+414/4dc>
Trace; a0027c40 <grab_cache_page_nowait+22c/380>
Trace; a0027f3c <do_generic_file_read+1a8/804>
Trace; a0028640 <generic_file_read+a8/9d4>
Trace; a0037414 <default_llseek+340/e10>
Trace; a000279c <set_context+3b8/5e4>
Trace; 00000000 Before first symbol
Trace; 10001dcc Before first symbol
Trace; 10002ba4 Before first symbol
Trace; 10003f94 Before first symbol
Trace; 0fee4920 Before first symbol
Here is a dump of the configuration space for the isa bridge and ide
interface on the VIA chipset in both human readable form and raw form.
The ISA bridge:
0000:00:01.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super
South] (rev 40)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin ? routed to IRQ 46
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
and in raw form
0000:00:01.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super
South] (rev 40)
00: 06 11 86 06 87 00 10 02 40 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00
40: 08 01 00 00 00 00 00 00 05 01 84 00 00 00 00 03
50: 0e 00 34 00 0f 90 ba 00 00 04 bf 00 00 00 00 00
60: d8 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 88 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 01 00 00 00 60 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 42 00 00 00 00 00 00 00 00 00
The IDE Interface:
0000:00:01.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if
8f [Master SecP SecO PriP PriO])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 128
Interrupt: pin ? routed to IRQ 46
Region 0: I/O ports at fff8 [size=8]
Region 1: I/O ports at fff4 [size=4]
Region 2: I/O ports at ffe8 [size=8]
Region 3: I/O ports at ffe4 [size=4]
Region 4: I/O ports at ffd0 [size=16]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
and in raw form
0000:00:01.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00: 06 11 71 05 07 00 90 02 06 8f 01 01 00 80 00 00
10: f9 ff 00 00 f5 ff 00 00 e9 ff 00 00 e5 ff 00 00
20: d1 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 c0 00 00 00 00 00 00 00 0e 00 00 00
40: 0b 02 c9 3a 08 00 c0 00 a8 a8 a8 20 3f 00 ff 20
50: 07 07 07 e4 04 00 00 00 a8 a8 a8 a8 00 00 00 00
60: 00 02 00 00 00 00 00 00 00 02 00 00 00 00 00 00
70: 02 01 00 00 00 00 00 00 02 01 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 06 00 71 05 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Here is a summary of what I have tried in the kernel code.
o I tried the unaligned buffer patch to see if I had alignment problems.
I dont.
o I tried to flush the cache instead of invalidating it in the
consistent_sync PCI_DMA_FROMDEVICE case.
o I tried to flush the consistent sync the memory in the ide_build_sglist
routine in a manner similar to Dan Malek in his 4xx OCP IDE driver.
o I tried to flush the cache based upon the dma table after the
ide_build_dmatable call as done in the Amiga One port which also uses the
VIA chipset.
o I tried converting the kmalloc calls for the sg_table to non cacheable
as well.
Here is the cleaned up diff with the debug printk's and my comments
removed.
diff -Naur orig/arch/ppc/mm/cachemap.c mod/arch/ppc/mm/cachemap.c
--- orig/arch/ppc/mm/cachemap.c 2005-01-29 13:06:41.000000000 -0500
+++ mod/arch/ppc/mm/cachemap.c 2005-01-29 13:04:10.000000000 -0500
@@ -146,10 +146,28 @@
unsigned long start = (unsigned long)vaddr;
unsigned long end = start + size;
switch (direction) {
case PCI_DMA_NONE:
BUG();
case PCI_DMA_FROMDEVICE: /* invalidate only */
+// printk("consistent sync: PCI_DMA_FROMDEVICE\n");
+
+#ifdef CONFIG_DEBUG_CONSISTENT_SYNC
+ if (unlikely(start & (L1_CACHE_LINE_SIZE - 1)) ||
+ unlikely(end & (L1_CACHE_LINE_SIZE - 1)))
+ {
+ static unsigned int count = 0;
+ if (++count < 10)
+ //printk(KERN_WARNING
+ printk(
+ "consistent_sync: 0x%08lx-0x%08lx "
+ "is not properly aligned, lr 0x%p\n",
+ start, end, __builtin_return_address(0));
+ }
+#endif
+
flush_dcache_range(start, end);
+// invalidate_dcache_range(start, end);
break;
case PCI_DMA_TODEVICE: /* writeback only */
+// printk("consistent sync: PCI_DMA_TODEVICE\n");
clean_dcache_range(start, end);
break;
case PCI_DMA_BIDIRECTIONAL: /* writeback and invalidate */
+// printk("consistent sync: PCI_DMA_BIDIRECTIONAL\n");
flush_dcache_range(start, end);
break;
}
diff -Naur orig/drivers/ide/ide-dma.c mod/drivers/ide/ide-dma.c
--- orig/drivers/ide/ide-dma.c 2005-01-29 13:06:53.000000000 -0500
+++ mod/drivers/ide/ide-dma.c 2005-01-29 12:55:15.000000000 -0500
static int ide_build_sglist (ide_hwif_t *hwif, struct request *rq, int
ddir)
{
struct buffer_head *bh;
unsigned long lastdataend = ~0UL;
int nents = 0;
if (hwif->sg_dma_active)
BUG();
@@ -270,6 +291,17 @@
}
if (contig) {
+ unsigned int size, addr;
+
+ addr = virt_to_bus(bh->b_data);
+ size = bh->b_size;
+ if (ddir)
+ consistent_sync(bh->b_data, size,
PCI_DMA_TODEVICE);
+ else
+ consistent_sync(bh->b_data, size,
PCI_DMA_FROMDEVICE);
+
+
+
sg[nents - 1].length += bh->b_size;
lastdataend += bh->b_size;
continue;
@@ -281,10 +313,26 @@
memset(&sg[nents], 0, sizeof(*sg));
if (bh->b_page) {
+ unsigned int size, addr;
+
+
+ addr = virt_to_bus(bh->b_data);
+ size = bh->b_size;
+ if (ddir)
+ consistent_sync(bh->b_data, size,
PCI_DMA_TODEVICE);
+ else
+ consistent_sync(bh->b_data, size,
PCI_DMA_FROMDEVICE);
+
+
sg[nents].page = bh->b_page;
sg[nents].offset = bh_offset(bh);
lastdataend = bh_phys(bh) + bh->b_size;
+ //printk("we are using pages\n");
+
+
+
} else {
+ printk("we are using datas\n");
if ((unsigned long) bh->b_data < PAGE_SIZE)
BUG();
@@ -300,6 +348,8 @@
BUG();
hwif->sg_dma_direction = ddir;
return pci_map_sg(hwif->pci_dev, sg, nents, ddir);
}
@@ -686,9 +751,18 @@
u8 dma_stat = 0, lba48 = (drive->addressing == 1) ? 1 : 0;
task_ioreg_t command = WIN_NOP;
if (!(count = ide_build_dmatable(drive, rq, PCI_DMA_FROMDEVICE)))
/* try PIO instead of DMA */
return 1;
+#if 1 /* MAI: make sure RAM's copy of dma table is up to date */
+ /* flush (start, stop) */
+// printk("ide_dma_read\n");
+// printk("\tflush_dcache_range start=%x
size=%x\n",hwif->dmatable_cpu, hwif->dmatable_cpu +(count << 3));
+ flush_dcache_range (hwif->dmatable_cpu, hwif->dmatable_cpu +
(count << 3));
+#endif
/* PRD table */
hwif->OUTL(hwif->dmatable_dma, hwif->dma_prdtable);
/* specify r/w */
@@ -732,9 +806,18 @@
u8 dma_stat = 0, lba48 = (drive->addressing == 1) ? 1 : 0;
task_ioreg_t command = WIN_NOP;
+// printk("__ide_dma_write\n");
+
+
if (!(count = ide_build_dmatable(drive, rq, PCI_DMA_TODEVICE)))
/* try PIO instead of DMA */
return 1;
+#if 1 /* MAI: make sure RAM's copy of dma table is up to date */
+ // This is flushing the virt address table.
+// printk("ide_dma_write\n");
+// printk("\tflush_dcache_range start=%x
size=%x\n",hwif->dmatable_cpu, hwif->dmatable_cpu +(count << 3));
+ flush_dcache_range (hwif->dmatable_cpu, hwif->dmatable_cpu +
(count << 3));
+#endif
/* PRD table */
hwif->OUTL(hwif->dmatable_dma, hwif->dma_prdtable);
/* specify r/w */
@@ -994,12 +1077,14 @@
hwif->dmatable_cpu = NULL;
}
if (hwif->sg_table) {
- kfree(hwif->sg_table);
+/* jfd kfree(hwif->sg_table); */
+ pci_free_consistent(NULL, sizeof(struct scatterlist) *
PRD_ENTRIES, hwif->sg_table,NULL);
hwif->sg_table = NULL;
}
return 1;
}
+
int ide_release_mmio_dma (ide_hwif_t *hwif)
{
if ((hwif->dma_extra) && (hwif->channel == 0))
@@ -1039,11 +1124,26 @@
int ide_allocate_dma_engine (ide_hwif_t *hwif)
{
+
+ printk("ide_allocate_dma_engine\n");
+
hwif->dmatable_cpu = pci_alloc_consistent(hwif->pci_dev,
PRD_ENTRIES * PRD_BYTES,
&hwif->dmatable_dma);
+
+ printk("\t dma table bus addr %x\n",hwif->dmatable_dma);
+ printk("\t dma table virt addr %x\n",hwif->dmatable_cpu);
+ printk("\t size
%x*%x=%x\n",PRD_ENTRIES,PRD_BYTES,PRD_ENTRIES*PRD_BYTES);
+
+
+
+ hwif->sg_table = pci_alloc_consistent(NULL,sizeof(struct
scatterlist) * PRD_ENTRIES,
+ &hwif->sg_table);
+#if 0
hwif->sg_table = kmalloc(sizeof(struct scatterlist) * PRD_ENTRIES,
GFP_KERNEL);
+jfd
+#endif
^ permalink raw reply
* Re: [PATCH] ppc32: Add support for Pegasos machines
From: Olaf Hering @ 2005-01-29 15:53 UTC (permalink / raw)
To: Linux Kernel Mailing List, Andrew Morton; +Cc: linuxppc-dev
In-Reply-To: <200501260514.j0Q5E5iq017078@hera.kernel.org>
On Wed, Jan 26, Linux Kernel Mailing List wrote:
> ChangeSet 1.2046, 2005/01/25 20:33:08-08:00, benh@kernel.crashing.org
>
> [PATCH] ppc32: Add support for Pegasos machines
>
> This patch, mostly from Sven Luther and reworked by me, adds support for
> Pegasos machines to the ppc32 arch. The patch contains all of the arch
> code. I'll send separately a few driver changes as well.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
>
>
>
> arch/ppc/platforms/chrp_pci.c | 38 +++++++++++++++++---
> diff -Nru a/arch/ppc/platforms/chrp_pci.c b/arch/ppc/platforms/chrp_pci.c
> --- a/arch/ppc/platforms/chrp_pci.c 2005-01-25 21:14:21 -08:00
> +++ b/arch/ppc/platforms/chrp_pci.c 2005-01-25 21:14:21 -08:00
> @@ -195,7 +215,7 @@
> struct pci_controller *hose;
> unsigned int *dma;
> char *model, *machine;
> - int is_longtrail = 0, is_mot = 0;
> + int is_longtrail = 0, is_mot = 0, is_pegasos = 0;
> struct device_node *root = find_path_device("/");
>
> /*
> @@ -207,6 +227,10 @@
> if (machine != NULL) {
> is_longtrail = strncmp(machine, "IBM,LongTrail", 13) == 0;
> is_mot = strncmp(machine, "MOT", 3) == 0;
> + if (strncmp(machine, "Pegasos2", 8) == 0)
> + is_pegasos = 2;
> + else if (strncmp(machine, "Pegasos", 7) == 0)
> + is_pegasos = 1;
> }
> for (dev = root->child; dev != NULL; dev = dev->sibling) {
> if (dev->type == NULL || strcmp(dev->type, "pci") != 0)
> @@ -275,5 +303,7 @@
> }
> }
>
> - ppc_md.pcibios_fixup = chrp_pcibios_fixup;
> + /* Do not fixup interrupts from OF tree on pegasos */
> + if (is_pegasos != 0)
> + ppc_md.pcibios_fixup = chrp_pcibios_fixup;
> }
This breaks other chrp boards, like a B50.
PCI: Enabling device 0000:00:10.0 (0140 -> 0143)
sym0: <875> rev 0x4 at pci 0000:00:10.0 irq 7
sym0: No NVRAM, ID 7, Fast-20, SE, parity checking
sym0: SCSI BUS has been reset.
scsi0 : sym-2.1.18n
sym0:0:0: ABORT operation started.
sym0:0:0: ABORT operation timed-out.
sym0:0:0: DEVICE RESET operation started.
sym0:0:0: DEVICE RESET operation timed-out.
sym0:0:0: BUS RESET operation started.
sym0:0:0: BUS RESET operation timed-out.
sym0:0:0: HOST RESET operation started.
Uninitialised timer!
This is just a warning. Your computer is OK
function=0xc02a0000, data=0x28000028
Call trace:
[c0028028] check_timer_failed+0x7c/0x9c
[c0028074] del_timer+0x2c/0xb0
[c0111c68] __sym_eh_done+0x8c/0x98
[c0110654] sym_xpt_done+0x2c/0x40
[c0117930] sym_flush_comp_queue+0x160/0x190
[c0117fd0] sym_start_up+0x194/0x7d8
[c0111994] sym_eh_handler+0x1bc/0x2d0
[c0107644] scsi_try_host_reset+0x8c/0x104
[c0108ac0] scsi_error_handler+0x8c0/0xe68
[c0006e14] kernel_thread+0x44/0x60
sym0: SCSI BUS has been reset.
sym0:0:0: HOST RESET operation timed-out.
scsi: Device offlined - not ready after error recovery: host 0 channel 0 id 0 lun 0
Signed-off-by: Olaf Hering <olh@suse.de>
--- ./arch/ppc/platforms/chrp_pci.c~ 2005-01-29 16:22:09.288047704 +0100
+++ ./arch/ppc/platforms/chrp_pci.c 2005-01-29 16:44:03.905193820 +0100
@@ -304,6 +304,6 @@
}
/* Do not fixup interrupts from OF tree on pegasos */
- if (is_pegasos != 0)
+ if (!is_pegasos)
ppc_md.pcibios_fixup = chrp_pcibios_fixup;
}
^ permalink raw reply
* Re: networking-related oopses on 2.6.9
From: Herbert Xu @ 2005-01-28 22:25 UTC (permalink / raw)
To: Marco d'Itri; +Cc: linuxppc-dev, netdev
In-Reply-To: <20050128140836.GA10777@wonderland.linux.it>
Marco d'Itri <md@linux.it> wrote:
>
> I have been able to capture the latest two oopses from the serial
> console, is this a known problem?
>
> KERNEL: assertion (!skb_queue_empty(&sk->sk_write_queue)) failed at net/ipv4/tc
Yes these are known problems which should be fixed in 2.6.10. However,
there is at least one other similar issue in 2.6.10 so you'll either
want to stay with 2.6.6 or go up to the latest bk snapshot.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Regarding Your Paypal Account
From: service @ 2005-01-28 22:04 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 7680 bytes --]
^ permalink raw reply
* [PATCH][PPC32] MPC8245 erratum 28 workaround
From: Mark A. Greer @ 2005-01-28 21:27 UTC (permalink / raw)
To: akpm; +Cc: Embedded PPC Linux list
[-- Attachment #1: Type: text/plain, Size: 282 bytes --]
The 8241/8245 have an erratum where PCI reads from local memory may
return stale data. One of the two workarounds is to set PICR2[0]. This
patch does that.
This patch assumes that the previous mpc10x patch has been applied.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
--
[-- Attachment #2: mpc10x_2.patch --]
[-- Type: text/plain, Size: 1470 bytes --]
diff -Nru a/arch/ppc/syslib/mpc10x_common.c b/arch/ppc/syslib/mpc10x_common.c
--- a/arch/ppc/syslib/mpc10x_common.c 2005-01-28 14:23:25 -07:00
+++ b/arch/ppc/syslib/mpc10x_common.c 2005-01-28 14:23:25 -07:00
@@ -323,6 +323,24 @@
MPC10X_CFG_PICR1_REG, picr1);
}
+ /*
+ * 8241/8245 erratum 28: PCI reads from local memory may return
+ * stale data. Workaround by setting PICR2[0] to disable copyback
+ * optimization. Oddly, the latest available user manual for the
+ * 8245 (Rev 2., dated 10/2003) says PICR2[0] is reserverd.
+ */
+ if (host_bridge == MPC10X_BRIDGE_8245) {
+ ulong picr2;
+
+ early_read_config_dword(hose, 0, PCI_DEVFN(0,0),
+ MPC10X_CFG_PICR2_REG, &picr2);
+
+ picr2 |= MPC10X_CFG_PICR2_COPYBACK_OPT;
+
+ early_write_config_dword(hose, 0, PCI_DEVFN(0,0),
+ MPC10X_CFG_PICR2_REG, picr2);
+ }
+
if (ppc_md.progress) ppc_md.progress("mpc10x:exit", 0x100);
return 0;
}
diff -Nru a/include/asm-ppc/mpc10x.h b/include/asm-ppc/mpc10x.h
--- a/include/asm-ppc/mpc10x.h 2005-01-28 14:23:25 -07:00
+++ b/include/asm-ppc/mpc10x.h 2005-01-28 14:23:25 -07:00
@@ -108,6 +108,9 @@
#define MPC10X_CFG_PICR1_SPEC_PCI_RD 0x00000004
#define MPC10X_CFG_PICR1_ST_GATH_EN 0x00000040
+#define MPC10X_CFG_PICR2_REG 0xac
+#define MPC10X_CFG_PICR2_COPYBACK_OPT 0x00000001
+
#define MPC10X_CFG_MAPB_OPTIONS_REG 0xe0
#define MPC10X_CFG_MAPB_OPTIONS_CFAE 0x80 /* CPU_FD_ALIAS_EN */
#define MPC10X_CFG_MAPB_OPTIONS_PFAE 0x40 /* PCI_FD_ALIAS_EN */
^ permalink raw reply
* Re: Linuxppc-embedded Digest, Vol 5, Issue 52
From: Srinivasa Kanduru @ 2005-01-28 18:45 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050128030429.70F0267ABB@ozlabs.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 2261 bytes --]
Hi Alex,
I wouldn't suspect the serial driver because it printed 3 characters correctly.
It might be better to look at where the kernel is being loaded. I guess somehow
the image is getting corrupted. Maybe you could move it farther away.
Regards,
Srini.
> ATTACHMENT part 3.2 message/rfc822
> From: "Povolotsky, Alexander" <Alexander.Povolotsky@marconi.com>
> To: "'linuxppc-dev@lists.linuxppc.org'" <linuxppc-dev@lists.linuxppc.org>,
> "'linuxppc-embedded@ozlabs.org'" <linuxppc-embedded@ozlabs.org>
> Date: Thu, 27 Jan 2005 21:07:26 -0500
> Subject: console_init() question
>
> > Hi,
> >
> I am struggling with bringing up the MPC 880 board on Linux 2.6-10.rc3 ...
> I could see that only 3 characters (see below) from the linux_banner are
> printed
> in __init start_kernel() (init/main.c) upon booting.
> Then a lot of garbage is outputted and eventually kernel hangs ...
> ...
> after gunzip
> done.
> Now booting the kernel
> LinÿÿÿÿÿÿÿÿÀÿÿÿÿÿÿÿÿÀ8ÀÿÿÿÿÿÿÿÿÀXÀÿÿÿÿÿÿÿÿÀxÀÿÿÿÿÿÿÿÿÀ~ÀÿÿÿÿÿÿÿÿÀ¸ÀÿÿÿÿÿÿÿÿÀ
> ØÀÿÿ
> <more garbage>
> <hangs> ...
> ...
>
> Very laborious debugging (without BDM and soft reset button - but with great
> help) shows that the hang is caused by the console
> serial driver at about (or just soon after)
>
> console_drivers = console;
>
> statement in
>
> register_console(struct console * console)
>
> function (in kernel/printk.c )
>
> I can not find (so far ) any specific error in values supplied vi bd_info
> from the ("custom" modified pSOS bootloader) causing above problem.
> >
> The debug output showing my serial settings was saved into log buffer and
> read at "bootloader time" after
> "software stimulated" "soft reboot" - it is listed here.
> Could someone kindly spare 5 min examining supplied debug output from both
> cpm_uart_set_termios()
> > (in drivers/serial/cpm_uart/cpm_uart_core.c) and cpm_setbrg() (in
> > arch/ppc/8xx_io/commproc.c) and tell
> me what is wrong there ?
> > The output is supplied at the end of my e-mail after the listings of
> > functions (with my print statements)
> >
> > Thanks,
> > Alex
> >
__________________________________
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250
^ permalink raw reply
* Re: atkbd_init lockup with 2.6.11-rc1
From: Olaf Hering @ 2005-01-28 19:00 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev
In-Reply-To: <20050128132202.GA27323@suse.de>
On Fri, Jan 28, Olaf Hering wrote:
>
> My IBM RS/6000 B50 locks up with 2.6.11rc1, it dies in atkbd_init():
>
> Calling initcall 0xc03c272c: atkbd_init+0x0/0x38()
> ps2_init(224) swapper(1):c0,j4294680939 enter
> atkbd_connect(793) swapper(1):c0,j4294680993 type 1000000
> serio_open(606) swapper(1):c0,j4294681061 enter
> serio_set_drv(594) swapper(1):c0,j4294681117 enter
> serio_set_drv(600) swapper(1):c0,j4294681176 leave
> i8042_write_command(69) swapper(1):c0,j4294681236 enter
> i8042_write_data(62) swapper(1):c0,j4294681236 enter
> serio_open(614) swapper(1):c0,j4294681363 leave0
> atkbd_probe(497) swapper(1):c0,j4294681421 enter
> ps2_command(91) swapper(1):c0,j4294681478 enter
> ps2_sendbyte(57) swapper(1):c0,j4294681534 enter
> serio_write(95) swapper(1):c0,j4294681591 write c01b65ac
> i8042_aux_write(253) swapper(1):c0,j4294681658 enter
> i8042_write_command(69) swapper(1):c0,j4294681720 enter
> i8042_write_data(62) swapper(1):c0,j4294681720 enter
If I remove this patch from 2.6.10-bk12, it works again.
No drivers were changed, I see lots of "mm" which is scary.
Any takers?
http://penguinppc.org/~olaf/bk12.diff.gz
.config contains just enough to get to the atkbd_init() function.
^ permalink raw reply
* Re: [PATCH]PPC4XX Dma fixes, burst and sg improvements
From: Matt Porter @ 2005-01-28 18:57 UTC (permalink / raw)
To: Colin Wernham; +Cc: linuxppc-embedded
In-Reply-To: <41EF8E33.9090909@airspan.com>
On Thu, Jan 20, 2005 at 10:55:47AM +0000, Colin Wernham wrote:
> I have DMA fixes and improvements to the following PPC4XX files [2.6.10]:
>
> ppc4xx_dma.h
> ppc4xx_dma.c
> ppc4xx_sgdma.c
>
> The fixes/improvements are:
<snip>
Thanks for the changes. Can you resubmit such that your mailer
does not mangle the patch? I can't apply it to a tree in the
current state. If you absolutely can't fix your mailer, then
just attach it.
-Matt
^ permalink raw reply
* [PATCH] PPC32: Use platform device style initialization for 85xx serial8250 ports
From: Kumar Gala @ 2005-01-28 18:34 UTC (permalink / raw)
To: akpm; +Cc: linux-kernel, linuxppc-embedded
Converts the initialization of serial8250 ports on various 85xx parts from
using the old ISA style to a platform device.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
diff -Nru a/arch/ppc/platforms/85xx/mpc8540_ads.c b/arch/ppc/platforms/85xx/mpc8540_ads.c
--- a/arch/ppc/platforms/85xx/mpc8540_ads.c 2005-01-28 12:26:45 -06:00
+++ b/arch/ppc/platforms/85xx/mpc8540_ads.c 2005-01-28 12:26:45 -06:00
@@ -147,10 +147,25 @@
#ifdef CONFIG_SERIAL_TEXT_DEBUG
{
bd_t *binfo = (bd_t *) __res;
+ struct uart_port p;
/* Use the last TLB entry to map CCSRBAR to allow access to DUART regs */
settlbcam(NUM_TLBCAMS - 1, binfo->bi_immr_base,
binfo->bi_immr_base, MPC85xx_CCSRBAR_SIZE, _PAGE_IO, 0);
+
+ memset(&p, 0, sizeof (p));
+ p.iotype = SERIAL_IO_MEM;
+ p.membase = (void *) binfo->bi_immr_base + MPC85xx_UART0_OFFSET;
+ p.uartclk = binfo->bi_busfreq;
+
+ gen550_init(0, &p);
+
+ memset(&p, 0, sizeof (p));
+ p.iotype = SERIAL_IO_MEM;
+ p.membase = (void *) binfo->bi_immr_base + MPC85xx_UART1_OFFSET;
+ p.uartclk = binfo->bi_busfreq;
+
+ gen550_init(1, &p);
}
#endif
diff -Nru a/arch/ppc/platforms/85xx/mpc8540_ads.h b/arch/ppc/platforms/85xx/mpc8540_ads.h
--- a/arch/ppc/platforms/85xx/mpc8540_ads.h 2005-01-28 12:26:45 -06:00
+++ b/arch/ppc/platforms/85xx/mpc8540_ads.h 2005-01-28 12:26:45 -06:00
@@ -22,8 +22,4 @@
#include <syslib/ppc85xx_setup.h>
#include <platforms/85xx/mpc85xx_ads_common.h>
-#define SERIAL_PORT_DFNS \
- STD_UART_OP(0) \
- STD_UART_OP(1)
-
#endif /* __MACH_MPC8540ADS_H__ */
diff -Nru a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
--- a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c 2005-01-28 12:26:45 -06:00
+++ b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c 2005-01-28 12:26:45 -06:00
@@ -396,11 +396,25 @@
#ifdef CONFIG_SERIAL_TEXT_DEBUG
{
bd_t *binfo = (bd_t *) __res;
+ struct uart_port p;
/* Use the last TLB entry to map CCSRBAR to allow access to DUART regs */
settlbcam(NUM_TLBCAMS - 1, binfo->bi_immr_base,
- binfo->bi_immr_base, MPC85xx_CCSRBAR_SIZE, _PAGE_IO, 0);
-
+ binfo->bi_immr_base, MPC85xx_CCSRBAR_SIZE, _PAGE_IO, 0);
+
+ memset(&p, 0, sizeof (p));
+ p.iotype = SERIAL_IO_MEM;
+ p.membase = (void *) binfo->bi_immr_base + MPC85xx_UART0_OFFSET;
+ p.uartclk = binfo->bi_busfreq;
+
+ gen550_init(0, &p);
+
+ memset(&p, 0, sizeof (p));
+ p.iotype = SERIAL_IO_MEM;
+ p.membase = (void *) binfo->bi_immr_base + MPC85xx_UART1_OFFSET;
+ p.uartclk = binfo->bi_busfreq;
+
+ gen550_init(1, &p);
}
#endif
diff -Nru a/arch/ppc/platforms/85xx/mpc85xx_cds_common.h b/arch/ppc/platforms/85xx/mpc85xx_cds_common.h
--- a/arch/ppc/platforms/85xx/mpc85xx_cds_common.h 2005-01-28 12:26:45 -06:00
+++ b/arch/ppc/platforms/85xx/mpc85xx_cds_common.h 2005-01-28 12:26:45 -06:00
@@ -73,8 +73,4 @@
#define MPC85XX_PCI2_IO_SIZE 0x01000000
-#define SERIAL_PORT_DFNS \
- STD_UART_OP(0) \
- STD_UART_OP(1)
-
#endif /* __MACH_MPC85XX_CDS_H__ */
diff -Nru a/arch/ppc/platforms/85xx/mpc85xx_devices.c b/arch/ppc/platforms/85xx/mpc85xx_devices.c
--- a/arch/ppc/platforms/85xx/mpc85xx_devices.c 2005-01-28 12:26:45 -06:00
+++ b/arch/ppc/platforms/85xx/mpc85xx_devices.c 2005-01-28 12:26:45 -06:00
@@ -16,6 +16,7 @@
#include <linux/init.h>
#include <linux/module.h>
#include <linux/device.h>
+#include <linux/serial_8250.h>
#include <linux/fsl_devices.h>
#include <asm/mpc85xx.h>
#include <asm/irq.h>
@@ -47,6 +48,21 @@
.device_flags = FSL_I2C_DEV_SEPARATE_DFSRR,
};
+static struct plat_serial8250_port serial_platform_data[] = {
+ [0] = {
+ .mapbase = 0x4500,
+ .irq = MPC85xx_IRQ_DUART,
+ .iotype = UPIO_MEM,
+ .flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | UPF_SHARE_IRQ,
+ },
+ [1] = {
+ .mapbase = 0x4600,
+ .irq = MPC85xx_IRQ_DUART,
+ .iotype = UPIO_MEM,
+ .flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | UPF_SHARE_IRQ,
+ },
+};
+
struct platform_device ppc_sys_platform_devices[] = {
[MPC85xx_TSEC1] = {
.name = "fsl-gianfar",
@@ -222,6 +238,11 @@
.flags = IORESOURCE_IRQ,
},
},
+ },
+ [MPC85xx_DUART] = {
+ .name = "serial8250",
+ .id = 0,
+ .dev.platform_data = serial_platform_data,
},
[MPC85xx_PERFMON] = {
.name = "fsl-perfmon",
diff -Nru a/arch/ppc/platforms/85xx/mpc85xx_sys.c b/arch/ppc/platforms/85xx/mpc85xx_sys.c
--- a/arch/ppc/platforms/85xx/mpc85xx_sys.c 2005-01-28 12:26:45 -06:00
+++ b/arch/ppc/platforms/85xx/mpc85xx_sys.c 2005-01-28 12:26:45 -06:00
@@ -24,12 +24,12 @@
.ppc_sys_name = "MPC8540",
.mask = 0xFFFF0000,
.value = 0x80300000,
- .num_devices = 9,
+ .num_devices = 10,
.device_list = (enum ppc_sys_devices[])
{
MPC85xx_TSEC1, MPC85xx_TSEC2, MPC85xx_FEC, MPC85xx_IIC1,
MPC85xx_DMA0, MPC85xx_DMA1, MPC85xx_DMA2, MPC85xx_DMA3,
- MPC85xx_PERFMON,
+ MPC85xx_PERFMON, MPC85xx_DUART,
},
},
{
@@ -52,12 +52,12 @@
.ppc_sys_name = "MPC8541",
.mask = 0xFFFF0000,
.value = 0x80720000,
- .num_devices = 12,
+ .num_devices = 13,
.device_list = (enum ppc_sys_devices[])
{
MPC85xx_TSEC1, MPC85xx_TSEC2, MPC85xx_IIC1,
MPC85xx_DMA0, MPC85xx_DMA1, MPC85xx_DMA2, MPC85xx_DMA3,
- MPC85xx_PERFMON,
+ MPC85xx_PERFMON, MPC85xx_DUART,
MPC85xx_CPM_SPI, MPC85xx_CPM_I2C,
MPC85xx_CPM_FCC1, MPC85xx_CPM_FCC2,
},
@@ -66,12 +66,12 @@
.ppc_sys_name = "MPC8541E",
.mask = 0xFFFF0000,
.value = 0x807A0000,
- .num_devices = 13,
+ .num_devices = 14,
.device_list = (enum ppc_sys_devices[])
{
MPC85xx_TSEC1, MPC85xx_TSEC2, MPC85xx_IIC1,
MPC85xx_DMA0, MPC85xx_DMA1, MPC85xx_DMA2, MPC85xx_DMA3,
- MPC85xx_PERFMON, MPC85xx_SEC2,
+ MPC85xx_PERFMON, MPC85xx_DUART, MPC85xx_SEC2,
MPC85xx_CPM_SPI, MPC85xx_CPM_I2C,
MPC85xx_CPM_FCC1, MPC85xx_CPM_FCC2,
},
@@ -80,12 +80,12 @@
.ppc_sys_name = "MPC8555",
.mask = 0xFFFF0000,
.value = 0x80710000,
- .num_devices = 19,
+ .num_devices = 20,
.device_list = (enum ppc_sys_devices[])
{
MPC85xx_TSEC1, MPC85xx_TSEC2, MPC85xx_IIC1,
MPC85xx_DMA0, MPC85xx_DMA1, MPC85xx_DMA2, MPC85xx_DMA3,
- MPC85xx_PERFMON,
+ MPC85xx_PERFMON, MPC85xx_DUART,
MPC85xx_CPM_SPI, MPC85xx_CPM_I2C, MPC85xx_CPM_SCC1,
MPC85xx_CPM_SCC2, MPC85xx_CPM_SCC3,
MPC85xx_CPM_FCC1, MPC85xx_CPM_FCC2, MPC85xx_CPM_FCC3,
@@ -97,12 +97,12 @@
.ppc_sys_name = "MPC8555E",
.mask = 0xFFFF0000,
.value = 0x80790000,
- .num_devices = 20,
+ .num_devices = 21,
.device_list = (enum ppc_sys_devices[])
{
MPC85xx_TSEC1, MPC85xx_TSEC2, MPC85xx_IIC1,
MPC85xx_DMA0, MPC85xx_DMA1, MPC85xx_DMA2, MPC85xx_DMA3,
- MPC85xx_PERFMON, MPC85xx_SEC2,
+ MPC85xx_PERFMON, MPC85xx_DUART, MPC85xx_SEC2,
MPC85xx_CPM_SPI, MPC85xx_CPM_I2C, MPC85xx_CPM_SCC1,
MPC85xx_CPM_SCC2, MPC85xx_CPM_SCC3,
MPC85xx_CPM_FCC1, MPC85xx_CPM_FCC2, MPC85xx_CPM_FCC3,
diff -Nru a/arch/ppc/syslib/ppc85xx_setup.c b/arch/ppc/syslib/ppc85xx_setup.c
--- a/arch/ppc/syslib/ppc85xx_setup.c 2005-01-28 12:26:45 -06:00
+++ b/arch/ppc/syslib/ppc85xx_setup.c 2005-01-28 12:26:45 -06:00
@@ -21,12 +21,14 @@
#include <linux/serial.h>
#include <linux/tty.h> /* for linux/serial_core.h */
#include <linux/serial_core.h>
+#include <linux/serial_8250.h>
#include <asm/prom.h>
#include <asm/time.h>
#include <asm/mpc85xx.h>
#include <asm/immap_85xx.h>
#include <asm/mmu.h>
+#include <asm/ppc_sys.h>
#include <asm/kgdb.h>
#include <syslib/ppc85xx_setup.h>
@@ -72,40 +74,39 @@
void __init
mpc85xx_early_serial_map(void)
{
+#if defined(CONFIG_SERIAL_TEXT_DEBUG) || defined(CONFIG_KGDB)
struct uart_port serial_req;
+#endif
+ struct plat_serial8250_port *pdata;
bd_t *binfo = (bd_t *) __res;
- phys_addr_t duart_paddr = binfo->bi_immr_base + MPC85xx_UART0_OFFSET;
+ pdata = (struct plat_serial8250_port *) ppc_sys_get_pdata(MPC85xx_DUART);
/* Setup serial port access */
+ pdata[0].uartclk = binfo->bi_busfreq;
+ pdata[0].mapbase += binfo->bi_immr_base;
+ pdata[0].membase = ioremap(pdata[0].mapbase, MPC85xx_UART0_SIZE);
+
+#if defined(CONFIG_SERIAL_TEXT_DEBUG) || defined(CONFIG_KGDB)
memset(&serial_req, 0, sizeof (serial_req));
- serial_req.uartclk = binfo->bi_busfreq;
- serial_req.line = 0;
- serial_req.irq = MPC85xx_IRQ_DUART;
- serial_req.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
serial_req.iotype = SERIAL_IO_MEM;
- serial_req.membase = ioremap(duart_paddr, MPC85xx_UART0_SIZE);
- serial_req.mapbase = duart_paddr;
+ serial_req.mapbase = pdata[0].mapbase;
+ serial_req.membase = pdata[0].membase;
serial_req.regshift = 0;
-#if defined(CONFIG_SERIAL_TEXT_DEBUG) || defined(CONFIG_KGDB)
gen550_init(0, &serial_req);
#endif
- if (early_serial_setup(&serial_req) != 0)
- printk("Early serial init of port 0 failed\n");
-
- /* Assume early_serial_setup() doesn't modify serial_req */
- duart_paddr = binfo->bi_immr_base + MPC85xx_UART1_OFFSET;
- serial_req.line = 1;
- serial_req.mapbase = duart_paddr;
- serial_req.membase = ioremap(duart_paddr, MPC85xx_UART1_SIZE);
+ pdata[1].uartclk = binfo->bi_busfreq;
+ pdata[1].mapbase += binfo->bi_immr_base;
+ pdata[1].membase = ioremap(pdata[1].mapbase, MPC85xx_UART0_SIZE);
#if defined(CONFIG_SERIAL_TEXT_DEBUG) || defined(CONFIG_KGDB)
+ /* Assume gen550_init() doesn't modify serial_req */
+ serial_req.mapbase = pdata[1].mapbase;
+ serial_req.membase = pdata[1].membase;
+
gen550_init(1, &serial_req);
#endif
-
- if (early_serial_setup(&serial_req) != 0)
- printk("Early serial init of port 1 failed\n");
}
#endif
diff -Nru a/arch/ppc/syslib/ppc85xx_setup.h b/arch/ppc/syslib/ppc85xx_setup.h
--- a/arch/ppc/syslib/ppc85xx_setup.h 2005-01-28 12:26:45 -06:00
+++ b/arch/ppc/syslib/ppc85xx_setup.h 2005-01-28 12:26:45 -06:00
@@ -43,9 +43,6 @@
#define PCIX_STATUS 0x64
/* Serial Config */
-#define MPC85XX_0_SERIAL (CCSRBAR + 0x4500)
-#define MPC85XX_1_SERIAL (CCSRBAR + 0x4600)
-
#ifdef CONFIG_SERIAL_MANY_PORTS
#define RS_TABLE_SIZE 64
#else
@@ -55,12 +52,6 @@
#ifndef BASE_BAUD
#define BASE_BAUD 115200
#endif
-
-#define STD_UART_OP(num) \
- { 0, BASE_BAUD, num, MPC85xx_IRQ_DUART, \
- (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST), \
- iomem_base: (u8 *)MPC85XX_##num##_SERIAL, \
- io_type: SERIAL_IO_MEM},
/* Offset of CPM register space */
#define CPM_MAP_ADDR (CCSRBAR + MPC85xx_CPM_OFFSET)
^ permalink raw reply
* [PATCH][PPC32] Add platform specific machine check output handlers
From: Matt Porter @ 2005-01-28 18:06 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-embedded
Patch adds generic way for platform port to extend
MachineCheckException print-out and adds 44x bus error registers
output. It also removes 40x #ifdefs from show_regs and makes
40x use this new platform extension.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
===== arch/ppc/kernel/process.c 1.59 vs edited =====
--- 1.59/arch/ppc/kernel/process.c 2004-12-14 13:59:07 -08:00
+++ edited/arch/ppc/kernel/process.c 2004-12-18 12:12:04 -08:00
@@ -325,17 +325,6 @@
current, current->pid, current->comm, current->thread_info);
printk("Last syscall: %ld ", current->thread.last_syscall);
-#if defined(CONFIG_4xx) && defined(DCRN_PLB0_BEAR)
- printk("\nPLB0: bear= 0x%8.8x acr= 0x%8.8x besr= 0x%8.8x\n",
- mfdcr(DCRN_PLB0_BEAR), mfdcr(DCRN_PLB0_ACR),
- mfdcr(DCRN_PLB0_BESR));
-#endif
-#if defined(CONFIG_4xx) && defined(DCRN_POB0_BEAR)
- printk("PLB0 to OPB: bear= 0x%8.8x besr0= 0x%8.8x besr1= 0x%8.8x\n",
- mfdcr(DCRN_POB0_BEAR), mfdcr(DCRN_POB0_BESR0),
- mfdcr(DCRN_POB0_BESR1));
-#endif
-
#ifdef CONFIG_SMP
printk(" CPU: %d", smp_processor_id());
#endif /* CONFIG_SMP */
===== arch/ppc/kernel/traps.c 1.36 vs edited =====
--- 1.36/arch/ppc/kernel/traps.c 2004-11-02 06:40:33 -08:00
+++ edited/arch/ppc/kernel/traps.c 2004-12-18 13:26:33 -08:00
@@ -199,6 +199,15 @@
#define clear_single_step(regs) ((regs)->msr &= ~MSR_SE)
#endif
+/*
+ * This is "fall-back" implementation for configurations
+ * which don't provide platform-specific machine check info
+ */
+void __attribute__ ((weak))
+platform_machine_check(struct pt_regs *regs)
+{
+}
+
void MachineCheckException(struct pt_regs *regs)
{
unsigned long reason = get_mc_reason(regs);
@@ -322,6 +331,12 @@
printk("Unknown values in msr\n");
}
#endif /* CONFIG_4xx */
+
+ /*
+ * Optional platform-provided routine to print out
+ * additional info, e.g. bus error registers.
+ */
+ platform_machine_check(regs);
debugger(regs);
die("machine check", regs, SIGBUS);
===== arch/ppc/syslib/ibm44x_common.c 1.6 vs edited =====
--- 1.6/arch/ppc/syslib/ibm44x_common.c 2004-11-07 16:00:31 -08:00
+++ edited/arch/ppc/syslib/ibm44x_common.c 2004-12-18 12:07:37 -08:00
@@ -170,3 +170,16 @@
#endif
}
+/* Called from MachineCheckException */
+void platform_machine_check(struct pt_regs *regs)
+{
+ printk("PLB0: BEAR=0x%08x%08x ACR= 0x%08x BESR= 0x%08x\n",
+ mfdcr(DCRN_PLB0_BEARH), mfdcr(DCRN_PLB0_BEARL),
+ mfdcr(DCRN_PLB0_ACR), mfdcr(DCRN_PLB0_BESR));
+ printk("POB0: BEAR=0x%08x%08x BESR0=0x%08x BESR1=0x%08x\n",
+ mfdcr(DCRN_POB0_BEARH), mfdcr(DCRN_POB0_BEARL),
+ mfdcr(DCRN_POB0_BESR0), mfdcr(DCRN_POB0_BESR1));
+ printk("OPB0: BEAR=0x%08x%08x BSTAT=0x%08x\n",
+ mfdcr(DCRN_OPB0_BEARH), mfdcr(DCRN_OPB0_BEARL),
+ mfdcr(DCRN_OPB0_BSTAT));
+}
===== arch/ppc/syslib/ppc4xx_setup.c 1.17 vs edited =====
--- 1.17/arch/ppc/syslib/ppc4xx_setup.c 2004-11-07 16:00:31 -08:00
+++ edited/arch/ppc/syslib/ppc4xx_setup.c 2004-12-18 12:11:45 -08:00
@@ -303,3 +303,19 @@
ppc_ide_md.ide_init_hwif = ppc4xx_ide_init_hwif_ports;
#endif /* defined(CONFIG_PCI) && defined(CONFIG_IDE) */
}
+
+/* Called from MachineCheckException */
+void platform_machine_check(struct pt_regs *regs)
+{
+#if defined(DCRN_PLB0_BEAR)
+ printk("PLB0: BEAR= 0x%08x ACR= 0x%08x BESR= 0x%08x\n",
+ mfdcr(DCRN_PLB0_BEAR), mfdcr(DCRN_PLB0_ACR),
+ mfdcr(DCRN_PLB0_BESR));
+#endif
+#if defined(DCRN_POB0_BEAR)
+ printk("PLB0 to OPB: BEAR= 0x%08x BESR0= 0x%08x BESR1= 0x%08x\n",
+ mfdcr(DCRN_POB0_BEAR), mfdcr(DCRN_POB0_BESR0),
+ mfdcr(DCRN_POB0_BESR1));
+#endif
+
+}
===== include/asm-ppc/ibm44x.h 1.6 vs edited =====
--- 1.6/include/asm-ppc/ibm44x.h 2004-11-07 16:00:31 -08:00
+++ edited/include/asm-ppc/ibm44x.h 2004-12-18 12:28:26 -08:00
@@ -244,13 +244,24 @@
#define MALOBISR_CH0 0x80000000 /* EOB channel 1 bit */
#define MALOBISR_CH2 0x40000000 /* EOB channel 2 bit */
-/* 440GP PLB Arbiter DCRs */
+/* 440GP/GX PLB Arbiter DCRs */
#define DCRN_PLB0_REVID 0x082 /* PLB Arbiter Revision ID */
#define DCRN_PLB0_ACR 0x083 /* PLB Arbiter Control */
#define DCRN_PLB0_BESR 0x084 /* PLB Error Status */
#define DCRN_PLB0_BEARL 0x086 /* PLB Error Address Low */
#define DCRN_PLB0_BEAR DCRN_PLB0_BEARL /* 40x compatibility */
#define DCRN_PLB0_BEARH 0x087 /* PLB Error Address High */
+
+/* 440GP/GX PLB to OPB bridge DCRs */
+#define DCRN_POB0_BESR0 0x090
+#define DCRN_POB0_BESR1 0x094
+#define DCRN_POB0_BEARL 0x092
+#define DCRN_POB0_BEARH 0x093
+
+/* 440GP/GX OPB to PLB bridge DCRs */
+#define DCRN_OPB0_BSTAT 0x0a9
+#define DCRN_OPB0_BEARL 0x0aa
+#define DCRN_OPB0_BEARH 0x0ab
/* 440GP Clock, PM, chip control */
#define DCRN_CPC0_SR 0x0b0
^ permalink raw reply
* Re: atkbd_init lockup with 2.6.11-rc1
From: Olaf Hering @ 2005-01-28 17:37 UTC (permalink / raw)
To: dtor_core; +Cc: linuxppc-dev, Vojtech Pavlik, linux-kernel
In-Reply-To: <d120d500050128093472935f8a@mail.gmail.com>
On Fri, Jan 28, Dmitry Torokhov wrote:
> On Fri, 28 Jan 2005 11:43:44 -0500, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > This time keyboard does not hang but NAKs everything instead...
>
> Probably stupid question - does this box have AT keyboard? Or NAKs are
> perfectly valid?
There is nothing connected. 2.6.10-bk11 works, -bk12 not. Thats a
starting point, will look at the differences now.
^ permalink raw reply
* Re: MPC8272ADS and frame buffer
From: Federico Lucifredi @ 2005-01-28 17:31 UTC (permalink / raw)
To: Bora Þahin, Linux-ppc [mailing list]
In-Reply-To: <551817263.20050128123639@ttnet.net.tr>
Bora Þahin wrote:
>Hi Federico,
>
>FL> I meant that you have to stress-test the bus connection that you are
>FL> going to use to whatever graphic hardware you
>FL> select - you cannot count on embedded hardware being bleeding-edge
>FL> performance, and you are going to play 25 or 30 frames a second over
>FL> that bus -- it is a lot of data, and you have bandwidth (hopefully not a
>FL> problem with pci) and jitter (delay variance) constraints.
>
>Sory for the late answer...
>
>I see you. In fact I know it but some blurry situations is matter. We use IBM-PPC. It has
>CoreConnect bus. I dont know implementation details of it but it has three different buses. One is
>PLB. This is for speedy ones. PCI bridge is in this bus also. AFAIK, data and addres bus of it is
>decoupled. Clock speed is also high. I think it also support burst mode. So in the light of these
>infos it seems enough. So PCI is enough, this one sholud be enough also.
>
>But as you said, we should take into consideration that these cpus and buses are embedded and at
>some points, may have clipped version of desktop brothers.
>
>
>
Exactly. And even when the cpu is not clipped, the board might be (I am
handling right now a fully complete Motorola MPC8272 based design, the
chip supports PCI burst, the board design, however, does not).
-Federico
--
_________________________________________
-- "'Problem' is a bleak word for challenge" - Richard Fish
Muad'Dib of Caladan (Federico L. Lucifredi)- Harvard University & BU
http://metcs.bu.edu/~lucifred
^ permalink raw reply
* Re: atkbd_init lockup with 2.6.11-rc1
From: Dmitry Torokhov @ 2005-01-28 17:34 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Vojtech Pavlik, linux-kernel
In-Reply-To: <d120d500050128084345bb1abd@mail.gmail.com>
On Fri, 28 Jan 2005 11:43:44 -0500, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> This time keyboard does not hang but NAKs everything instead...
Probably stupid question - does this box have AT keyboard? Or NAKs are
perfectly valid?
--
Dmitry
^ permalink raw reply
* Re: atkbd_init lockup with 2.6.11-rc1
From: Olaf Hering @ 2005-01-28 16:47 UTC (permalink / raw)
To: dtor_core; +Cc: linuxppc-dev, Vojtech Pavlik, linux-kernel
In-Reply-To: <d120d500050128084345bb1abd@mail.gmail.com>
On Fri, Jan 28, Dmitry Torokhov wrote:
> > i8042_write_data(56) swapper(1):c0,j4294674787 enter 96
> > i8042_write_data(58) swapper(1):c0,j4294674787 leave 96
>
> So this trace is without printk but with udelay, right? This time
> keyboard does not hang but NAKs everything instead... What if you aso
> add udelay(20) after calls to i8042_write_data()?
Its with 2 printk in i8042_write_data(), just adding a printk after outb
in i8042_write_data fixes the hang.
> > md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27
> > NET: Registered protocol family 2
> > .. here it hangs again.
>
> Do you know where exactly? Is it some IO port access again?
Havent debugged that one, yet. Hopefully a different issue. According to
the logs from 2.6.5, the next message would be
NET: Registered protocol family 2
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
NET: Registered protocol family 1
NET: Registered protocol family 17
^ permalink raw reply
* Re: atkbd_init lockup with 2.6.11-rc1
From: Dmitry Torokhov @ 2005-01-28 16:43 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Vojtech Pavlik, linux-kernel
In-Reply-To: <20050128161746.GA1092@suse.de>
On Fri, 28 Jan 2005 17:17:46 +0100, Olaf Hering <olh@suse.de> wrote:
> On Fri, Jan 28, Dmitry Torokhov wrote:
>
> > Fixes as in "it reports that reset fails" again or it resets the
> > keyboard cleanly and works fine?
>
> It doesnt hang if I add printk around the outb.
>
> > > Do you have a version of that i8042 delay patch for 2.6.11-rc2-bk6?
> > > Maybe it will help.
> > >
> >
> > No I don't, and I don't think you need all of it. What happens if you
> > edit drivers/input/serio/i8042.c manually and stick udelay(7); in
> > front of calls to i8042_write_data() in i8042_kbd_write() and
> > i8042_aux_write()?
>
> Doesnt help either, adding printk fixes it.
>
> /home/olaf/kernel/b50/linux-2.6.11-rc2-bk6-olh/drivers/input/serio/i8042.c: 60 -> i8042 (command) [2264]
> /home/olaf/kernel/b50/linux-2.6.11-rc2-bk6-olh/drivers/input/serio/i8042.c: 61 -> i8042 (parameter) [2264]
> i8042_write_data(56) swapper(1):c0,j4294673158 enter 97
> i8042_write_data(58) swapper(1):c0,j4294673158 leave 97
> /home/olaf/kernel/b50/linux-2.6.11-rc2-bk6-olh/drivers/input/serio/i8042.c: ff -> i8042 (kbd-data) [2640]
> i8042_write_data(56) swapper(1):c0,j4294673534 enter 255
> i8042_write_data(58) swapper(1):c0,j4294673534 leave 255
> /home/olaf/kernel/b50/linux-2.6.11-rc2-bk6-olh/drivers/input/serio/i8042.c: fe <- i8042 (interrupt, kbd, 1, timeout) [2895]
> atkbd.c: keyboard reset failed on isa0060/serio0
> /home/olaf/kernel/b50/linux-2.6.11-rc2-bk6-olh/drivers/input/serio/i8042.c: f2 -> i8042 (kbd-data) [3096]
> i8042_write_data(56) swapper(1):c0,j4294673990 enter 242
> i8042_write_data(58) swapper(1):c0,j4294673990 leave 242
> /home/olaf/kernel/b50/linux-2.6.11-rc2-bk6-olh/drivers/input/serio/i8042.c: fe <- i8042 (interrupt, kbd, 1, timeout) [3351]
> /home/olaf/kernel/b50/linux-2.6.11-rc2-bk6-olh/drivers/input/serio/i8042.c: ed -> i8042 (kbd-data) [3494]
> i8042_write_data(56) swapper(1):c0,j4294674388 enter 237
> i8042_write_data(58) swapper(1):c0,j4294674388 leave 237
> /home/olaf/kernel/b50/linux-2.6.11-rc2-bk6-olh/drivers/input/serio/i8042.c: fe <- i8042 (interrupt, kbd, 1, timeout) [3750]
> /home/olaf/kernel/b50/linux-2.6.11-rc2-bk6-olh/drivers/input/serio/i8042.c: 60 -> i8042 (command) [3893]
> /home/olaf/kernel/b50/linux-2.6.11-rc2-bk6-olh/drivers/input/serio/i8042.c: 60 -> i8042 (parameter) [3893]
> i8042_write_data(56) swapper(1):c0,j4294674787 enter 96
> i8042_write_data(58) swapper(1):c0,j4294674787 leave 96
So this trace is without printk but with udelay, right? This time
keyboard does not hang but NAKs everything instead... What if you aso
add udelay(20) after calls to i8042_write_data()?
> md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27
> NET: Registered protocol family 2
> .. here it hangs again.
Do you know where exactly? Is it some IO port access again?
--
Dmitry
^ permalink raw reply
* Re: atkbd_init lockup with 2.6.11-rc1
From: Olaf Hering @ 2005-01-28 16:17 UTC (permalink / raw)
To: dtor_core; +Cc: linuxppc-dev, Vojtech Pavlik, linux-kernel
In-Reply-To: <d120d500050128072268a5c2f0@mail.gmail.com>
On Fri, Jan 28, Dmitry Torokhov wrote:
> Fixes as in "it reports that reset fails" again or it resets the
> keyboard cleanly and works fine?
It doesnt hang if I add printk around the outb.
> > Do you have a version of that i8042 delay patch for 2.6.11-rc2-bk6?
> > Maybe it will help.
> >
>
> No I don't, and I don't think you need all of it. What happens if you
> edit drivers/input/serio/i8042.c manually and stick udelay(7); in
> front of calls to i8042_write_data() in i8042_kbd_write() and
> i8042_aux_write()?
Doesnt help either, adding printk fixes it.
/home/olaf/kernel/b50/linux-2.6.11-rc2-bk6-olh/drivers/input/serio/i8042.c: 60 -> i8042 (command) [2264]
/home/olaf/kernel/b50/linux-2.6.11-rc2-bk6-olh/drivers/input/serio/i8042.c: 61 -> i8042 (parameter) [2264]
i8042_write_data(56) swapper(1):c0,j4294673158 enter 97
i8042_write_data(58) swapper(1):c0,j4294673158 leave 97
/home/olaf/kernel/b50/linux-2.6.11-rc2-bk6-olh/drivers/input/serio/i8042.c: ff -> i8042 (kbd-data) [2640]
i8042_write_data(56) swapper(1):c0,j4294673534 enter 255
i8042_write_data(58) swapper(1):c0,j4294673534 leave 255
/home/olaf/kernel/b50/linux-2.6.11-rc2-bk6-olh/drivers/input/serio/i8042.c: fe <- i8042 (interrupt, kbd, 1, timeout) [2895]
atkbd.c: keyboard reset failed on isa0060/serio0
/home/olaf/kernel/b50/linux-2.6.11-rc2-bk6-olh/drivers/input/serio/i8042.c: f2 -> i8042 (kbd-data) [3096]
i8042_write_data(56) swapper(1):c0,j4294673990 enter 242
i8042_write_data(58) swapper(1):c0,j4294673990 leave 242
/home/olaf/kernel/b50/linux-2.6.11-rc2-bk6-olh/drivers/input/serio/i8042.c: fe <- i8042 (interrupt, kbd, 1, timeout) [3351]
/home/olaf/kernel/b50/linux-2.6.11-rc2-bk6-olh/drivers/input/serio/i8042.c: ed -> i8042 (kbd-data) [3494]
i8042_write_data(56) swapper(1):c0,j4294674388 enter 237
i8042_write_data(58) swapper(1):c0,j4294674388 leave 237
/home/olaf/kernel/b50/linux-2.6.11-rc2-bk6-olh/drivers/input/serio/i8042.c: fe <- i8042 (interrupt, kbd, 1, timeout) [3750]
/home/olaf/kernel/b50/linux-2.6.11-rc2-bk6-olh/drivers/input/serio/i8042.c: 60 -> i8042 (command) [3893]
/home/olaf/kernel/b50/linux-2.6.11-rc2-bk6-olh/drivers/input/serio/i8042.c: 60 -> i8042 (parameter) [3893]
i8042_write_data(56) swapper(1):c0,j4294674787 enter 96
i8042_write_data(58) swapper(1):c0,j4294674787 leave 96
md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27
NET: Registered protocol family 2
.. here it hangs again.
^ permalink raw reply
* Re: How to enable TAH on PPC 440GX un lk 2.4.x?
From: Matt Porter @ 2005-01-28 16:12 UTC (permalink / raw)
To: Sanjay Bajaj; +Cc: linuxppc-embedded
In-Reply-To: <0007F077BB3476449151699150E8FEA2059230@exchange.tsi-telsys.com>
[Please fix your mailer to wrap lines properly]
On Fri, Jan 28, 2005 at 10:33:09AM -0500, Sanjay Bajaj wrote:
> Please share any information on enabling TCP/IP Acceleration Hardware
> on IBM PPC 440GX processor based board for lk 2.4.x.
You can backport the driver from 2.6 with this support.
-Matt
^ permalink raw reply
* How to enable TAH on PPC 440GX un lk 2.4.x?
From: Sanjay Bajaj @ 2005-01-28 15:33 UTC (permalink / raw)
To: linuxppc-embedded
Please share any information on enabling TCP/IP Acceleration Hardware on =
IBM PPC 440GX processor based board for lk 2.4.x.
Thanks
Sanjay
^ permalink raw reply
* How to enable TAH on PPC 440GX un lk 2.4.x?
From: Sanjay Bajaj @ 2005-01-28 15:32 UTC (permalink / raw)
To: linuxppc-dev
Please share any information on enabling TCP/IP Acceleration Hardware on =
IBM PPC 440GX processor based board.
^ permalink raw reply
* Re: atkbd_init lockup with 2.6.11-rc1
From: Dmitry Torokhov @ 2005-01-28 15:22 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Vojtech Pavlik, linux-kernel
In-Reply-To: <20050128145511.GA29340@suse.de>
On Fri, 28 Jan 2005 15:55:11 +0100, Olaf Hering <olh@suse.de> wrote:
> On Fri, Jan 28, Dmitry Torokhov wrote:
>
> > On Fri, 28 Jan 2005 14:58:27 +0100, Olaf Hering <olh@suse.de> wrote:
> > > On Fri, Jan 28, Olaf Hering wrote:
> > >
> > > >
> > > > My IBM RS/6000 B50 locks up with 2.6.11rc1, it dies in atkbd_init():
> > >
> > > It fails also on PReP, not only on CHRP. 2.6.10 looks like this:
> > >
> > > Calling initcall 0xc03bc430: atkbd_init+0x0/0x2c()
> > > atkbd.c: keyboard reset failed on isa0060/serio1
> > > atkbd.c: keyboard reset failed on isa0060/serio0
> > >
> >
> > So it could not reset it even before, but it was not getting stuch
> > tough... What about passing atkbd.reset=0?
>
> I will try that.
> Adding a printk after the outb() fixes it as well.
Fixes as in "it reports that reset fails" again or it resets the
keyboard cleanly and works fine?
> Do you have a version of that i8042 delay patch for 2.6.11-rc2-bk6?
> Maybe it will help.
>
No I don't, and I don't think you need all of it. What happens if you
edit drivers/input/serio/i8042.c manually and stick udelay(7); in
front of calls to i8042_write_data() in i8042_kbd_write() and
i8042_aux_write()?
--
Dmitry
^ 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