* Re: Unable to boot kernel 2.6 from u-boot 1.1.4 in Xilinx ML403
From: Wolfgang Denk @ 2006-09-01 7:35 UTC (permalink / raw)
To: Aleck Lin; +Cc: linuxppc-embedded
In-Reply-To: <000a01c6cd6e$5e1970a0$800101df@monstertop>
In message <000a01c6cd6e$5e1970a0$800101df@monstertop> you wrote:
>
> 1. When I directly download zImage.elf to the RAM and boot from there, I see
...
> 2. When I tried to boot the zImage (sitting in the flash) from u-boot file
When you use U-Boot, you should use the correct image (uImage).
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Every little picofarad has a nanohenry all its own. - Don Vonada
^ permalink raw reply
* Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
From: Mel Gorman @ 2006-09-01 8:33 UTC (permalink / raw)
To: Keith Mannthey
Cc: akpm, tony.luck, linuxppc-dev, ak, bob.picco,
Linux Kernel Mailing List, Linux Memory Management List
In-Reply-To: <a762e240608312008v3e35b63ay46c95fbb6c3f15ec@mail.gmail.com>
On Thu, 31 Aug 2006, Keith Mannthey wrote:
> On 8/31/06, Mel Gorman <mel@csn.ul.ie> wrote:
>> On Thu, 31 Aug 2006, Keith Mannthey wrote:
>> > On 8/31/06, Mel Gorman <mel@skynet.ie> wrote:
>> >> On (30/08/06 13:57), Keith Mannthey didst pronounce:
>> >> > On 8/21/06, Mel Gorman <mel@csn.ul.ie> wrote:
>> >> > >
>
>> Can you confirm that happens by applying the patch I sent to you and
>> checking the output? When the reserve fails, it should print out what
>> range it actually checked. I want to be sure it's not checking the
>> addresses 0->0x1070000000
>
> See below
>
Perfect, thanks a lot. I should have enough to reproduce without a test
machine what is going on and develop the required patches.
>> >> > >@@ -329,6 +330,8 @@ acpi_numa_memory_affinity_init(struct ac
>> >> > >
>> >> > > printk(KERN_INFO "SRAT: Node %u PXM %u %Lx-%Lx\n", node, pxm,
>> >> > > nd->start, nd->end);
>> >> > >+ e820_register_active_regions(node, nd->start >> PAGE_SHIFT,
>> >> > >+ nd->end >>
>> PAGE_SHIFT);
>> >> >
>> >> > A node chunk in this section of code may be a hot-pluggable zone. With
>> >> > MEMORY_HOTPLUG_SPARSE we don't want to register these regions.
>> >> >
>> >>
>> >> The ranges should not get registered as active memory by
>> >> e820_register_active_regions() unless they are marked E820_RAM. My
>> >> understanding is that the regions for hotadd would be marked "reserved"
>> >> in the e820 map. Is that wrong?
>> >
>> > This is wrong. In a mult-node system that last node add area will not
>> > be marked reserved by the e820. The e820 only defines memory <
>> > end_pfn. the last node add area is > end_pfn.
>> >
>>
>> ok, that should still be fine. As long as the ranges are not marked
>> "usable", add_active_range() will not be called and the holes should be
>> counted correctly with the patch I sent you.
>>
>> > With RESERVE based add-memory you want the add-areas repored by the
>> > srat to be setup during boot like all the other pages.
>> >
>>
>> So, do you actally expect a lot of unused mem_map to be allocated with
>> struct pages that are inactive until memory is hot-added in an
>> x86_64-specific manner? The arch-independent stuff currently will not do
>> that. It sets up memmap for where memory really exists. If that is not
>> what you expect, it will hit issues at hotadd time which is not the
>> current issue but one that can be fixed.
>
> Yes. RESERVED based is a big waste of mem_map space.
Right, it's all very clear now. At some point in the future, I'd like to
visit why SPARSEMEM-based hot-add is not always used but it's a separate
issue.
> The add areas
> are marked as RESERVED during boot and then later onlined during add.
That explains the reserve_bootmem_node()
> It might be ok. I will play with tomorrow. I might just need to
> call add_active_range in the right spot :)
>
I'll play with this from the opposite perspective - what is required for
any arch using this API to have spare memmap for reserve-based hot-add.
>> >> > > if (ma->flags.hot_pluggable && !reserve_hotadd(node, start,
>> end)
>> >> <
>> >> > > 0) {
>> >> > > /* Ignore hotadd region. Undo damage */
>> >> >
>> >> > I have but the e820_register_active_regions as a else to this
>> >> > statment the absent pages check fails.
>> >> >
>> >>
>> >> The patch below omits this change because I think
>> >> e820_register_active_regions() will still have got called by the time
>> >> you encounter a hotplug area.
>> >
>> > called but then removed in setup arch.
>>
>> By "removed", I assume you mean the active regions removed by the call
>> to remove_all_active_regions() in setup_arch(). Before reserve_hotadd() is
>> called, e820_register_active_regions() will have reregistered the active
>> regions with the NUMA node id.
>
> I see e820_register_active_regions is acting as a filter against the e820
>
Yes. A range of pfn's in given to e820_register_active_regions() and it
reads the e820 for E820_RAM sections within that range.
>> >> > Also nodes_cover_memory and alot of these check were based against
>> >> > comparing the srat data against the e820. Now all this code is
>> >> > comparing SRAT against SRAT....
>> >> >
>> >>
>> >> I don't see why. The SRAT table passes a range to
>> >> e820_register_active_regions() so should be comparing SRAT to e820
>> >
>> > let me go off and look at e820_register_active_regions() some more.
> Things get clear :)
>
> Should be ok.
>
nice.
>> > Sure thing. It is just the hot-add area I am guessing it is an off by
>> > one error of some sort.
>> >
> See below. I do my e820_register_active_area as an else to to if
> (hotplug.....!reserve) and the prink is easy to sort out.
>
yep, it should be easy to put this into a test program.
> I see your pfn are in base 10. Looks like it considers the last
> addres to be a present page. (off by one thing).
>
Probably. I'll start poking now. Thanks a lot.
> Thanks,
> Keith
>
> Output below
> disabling early console
> Linux version 2.6.18-rc4-mm3-smp (root@elm3a153) (gcc version 4.1.0
> (SUSE Linux)) #6 SMP Thu Aug 31 22:06:00 EDT 2006
> Command line: root=/dev/sda3
> ip=9.47.66.153:9.47.66.169:9.47.66.1:255.255.255.0 resume=/dev/sda2
> showopts earlyprintk=ttyS0,115200 console=ttyS0,115200 console=tty0
> debug numa=hotadd=100
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 0000000000098400 (usable)
> BIOS-e820: 0000000000098400 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 000000007ff85e00 (usable)
> BIOS-e820: 000000007ff85e00 - 000000007ff98880 (ACPI data)
> BIOS-e820: 000000007ff98880 - 0000000080000000 (reserved)
> BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
> BIOS-e820: 0000000100000000 - 0000000470000000 (usable)
> BIOS-e820: 0000001070000000 - 0000001160000000 (usable)
> Entering add_active_range(0, 0, 152) 0 entries of 3200 used
> Entering add_active_range(0, 256, 524165) 1 entries of 3200 used
> Entering add_active_range(0, 1048576, 4653056) 2 entries of 3200 used
> Entering add_active_range(0, 17235968, 18219008) 3 entries of 3200 used
> end_pfn_map = 18219008
> DMI 2.3 present.
> ACPI: RSDP (v000 IBM ) @ 0x00000000000fdcf0
> ACPI: RSDT (v001 IBM EXA01ZEU 0x00001000 IBM 0x45444f43) @
> 0x000000007ff98800
> ACPI: FADT (v001 IBM EXA01ZEU 0x00001000 IBM 0x45444f43) @
> 0x000000007ff98780
> ACPI: MADT (v001 IBM EXA01ZEU 0x00001000 IBM 0x45444f43) @
> 0x000000007ff98600
> ACPI: SRAT (v001 IBM EXA01ZEU 0x00001000 IBM 0x45444f43) @
> 0x000000007ff983c0
> ACPI: HPET (v001 IBM EXA01ZEU 0x00001000 IBM 0x45444f43) @
> 0x000000007ff98380
> ACPI: SSDT (v001 IBM VIGSSDT0 0x00001000 INTL 0x20030122) @
> 0x000000007ff90780
> ACPI: SSDT (v001 IBM VIGSSDT1 0x00001000 INTL 0x20030122) @
> 0x000000007ff88bc0
> ACPI: DSDT (v001 IBM EXA01ZEU 0x00001000 INTL 0x20030122) @
> 0x0000000000000000
> SRAT: PXM 0 -> APIC 0 -> Node 0
> SRAT: PXM 0 -> APIC 1 -> Node 0
> SRAT: PXM 0 -> APIC 2 -> Node 0
> SRAT: PXM 0 -> APIC 3 -> Node 0
> SRAT: PXM 0 -> APIC 38 -> Node 0
> SRAT: PXM 0 -> APIC 39 -> Node 0
> SRAT: PXM 0 -> APIC 36 -> Node 0
> SRAT: PXM 0 -> APIC 37 -> Node 0
> SRAT: PXM 1 -> APIC 64 -> Node 1
> SRAT: PXM 1 -> APIC 65 -> Node 1
> SRAT: PXM 1 -> APIC 66 -> Node 1
> SRAT: PXM 1 -> APIC 67 -> Node 1
> SRAT: PXM 1 -> APIC 102 -> Node 1
> SRAT: PXM 1 -> APIC 103 -> Node 1
> SRAT: PXM 1 -> APIC 100 -> Node 1
> SRAT: PXM 1 -> APIC 101 -> Node 1
> SRAT: Node 0 PXM 0 0-80000000
> Entering add_active_range(0, 0, 152) 0 entries of 3200 used
> Entering add_active_range(0, 256, 524165) 1 entries of 3200 used
> SRAT: Node 0 PXM 0 0-470000000
> Entering add_active_range(0, 0, 152) 2 entries of 3200 used
> Entering add_active_range(0, 256, 524165) 2 entries of 3200 used
> Entering add_active_range(0, 1048576, 4653056) 2 entries of 3200 used
> SRAT: Node 0 PXM 0 0-1070000000
> reserve_hotadd called with node 0 sart 470000000 end 1070000000
> SRAT: Hotplug area has existing memory
> Entering add_active_range(0, 0, 152) 3 entries of 3200 used
> Entering add_active_range(0, 256, 524165) 3 entries of 3200 used
> Entering add_active_range(0, 1048576, 4653056) 3 entries of 3200 used
> SRAT: Node 1 PXM 1 1070000000-1160000000
> Entering add_active_range(1, 17235968, 18219008) 3 entries of 3200 used
> SRAT: Node 1 PXM 1 1070000000-3200000000
> reserve_hotadd called with node 1 sart 1160000000 end 3200000000
> SRAT: Hotplug area has existing memory
> Entering add_active_range(1, 17235968, 18219008) 4 entries of 3200 used
> NUMA: Using 28 for the hash shift.
> Bootmem setup node 0 0000000000000000-0000001070000000
> Bootmem setup node 1 0000001070000000-0000001160000000
> Zone PFN ranges:
> DMA 0 -> 4096
> DMA32 4096 -> 1048576
> Normal 1048576 -> 18219008
> early_node_map[4] active PFN ranges
> 0: 0 -> 152
> 0: 256 -> 524165
> 0: 1048576 -> 4653056
> 1: 17235968 -> 18219008
> On node 0 totalpages: 4128541
> 0 pages used for SPARSE memmap
> 1149 pages DMA reserved
> DMA zone: 2843 pages, LIFO batch:0
> 0 pages used for SPARSE memmap
> DMA32 zone: 520069 pages, LIFO batch:31
> 0 pages used for SPARSE memmap
> Normal zone: 3604480 pages, LIFO batch:31
> On node 1 totalpages: 983040
> 0 pages used for SPARSE memmap
> 0 pages used for SPARSE memmap
> 0 pages used for SPARSE memmap
> Normal zone: 983040 pages, LIFO batch:31
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* RE: Unable to boot kernel 2.6 from u-boot 1.1.4 in Xilinx ML403
From: Ming Liu @ 2006-09-01 8:45 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <000a01c6cd6e$5e1970a0$800101df@monstertop>
Hi Aleck,
>1. When I directly download zImage.elf to the RAM and boot from there, I
see
>the kernel starts booting, but it complains about not being able to mount
>/dev/sysace/disc0/part2 and thus kernel panic happens.
>
>The following is the output
>---------------------------------------------------------------
>loaded at: 00400000 004D313C
>board data at: 004D1124 004D113C
>relocated to: 004050F8 00405110
>zimage at: 0040580D 004D0AA8
>avail ram: 004D4000 04000000
>
>Linux/PPC load: console=ttyS0,9600 ip=off root=/dev/xsysace/disc0/part2 rw
>Uncompressing Linux...done.
>Now booting the kernel
>[ 0.000000] Linux version 2.6.17.8 (aleck@sac.gdatech.com) (gcc version
>4.0.0 (DENX ELDK 4.0 4.0.0)) #2 Thu Aug 31 11:49:40 PDT 2006
>[ 0.000000] Xilinx ML403 Reference System (Virtex-4 FX)
>[ 0.000000] Built 1 zonelists
>[ 0.000000] Kernel command line: console=ttyS0,9600 ip=off
>root=/dev/xsysace/disc0/part2 rw
>[ 0.000000] Xilinx INTC #0 at 0xD1000FC0 mapped to 0xFDFFEFC0
>[ 0.000000] PID hash table entries: 512 (order: 9, 2048 bytes)
>[ 0.000176] Console: colour dummy device 80x25
>[ 0.000676] Dentry cache hash table entries: 8192 (order: 3, 32768
bytes)
>[ 0.001452] Inode-cache hash table entries: 4096 (order: 2, 16384
bytes)
>[ 0.015453] Memory: 63104k available (1268k kernel code, 468k data, 80k
>init, 0k highmem)
>[ 0.204374] Mount-cache hash table entries: 512
>[ 0.209943] NET: Registered protocol family 16
>[ 0.218843] NET: Registered protocol family 2
>[ 0.264481] IP route cache hash table entries: 512 (order: -1, 2048
>bytes)
>[ 0.265267] TCP established hash table entries: 2048 (order: 1, 8192
>bytes)
>[ 0.265465] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
>[ 0.265569] TCP: Hash tables configured (established 2048 bind 1024)
>[ 0.265599] TCP reno registered
>[ 0.272471] io scheduler noop registered
>[ 0.272558] io scheduler anticipatory registered (default)
>[ 0.272626] io scheduler deadline registered
>[ 0.272759] io scheduler cfq registered
>[ 0.318755] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ
>sharing disabled
>[ 0.323749] serial8250.0: ttyS0 at MMIO 0xa0001003 (irq = 9) is a 16450
>[ 2.026296] RAMDISK driver initialized: 16 RAM disks of 65536K size
1024
>blocksize
>[ 2.117598] tun: Universal TUN/TAP device driver, 1.6
>[ 2.177338] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
>[ 2.252474] mice: PS/2 mouse device common for all mice
>[ 2.314381] TCP bic registered
>[ 2.350802] NET: Registered protocol family 1
>[ 2.402825] NET: Registered protocol family 17
>[ 2.458051] VFS: Cannot open root device "xsysace/disc0/part2" or
>unknown-block(0,0)
>[ 2.549979] Please append a correct "root=" boot option
>[ 2.612426] Kernel panic - not syncing: VFS: Unable to mount root fs on
>unknown-block(0,0)
>[ 2.711373] <0>Rebooting in 180 seconds..<NULL>
>-----------------------------------------------------------
>
Try this:
mount the CF card onto your PC and then goto the /dev folder on your
root filesystem in the card. Here run the following commands as root:
# mknod -m 660 console c 5 1
# mknod -m 660 xsa b 254 0
# mknod -m 660 xsa1 b 254 1
# mknod -m 660 xsa2 b 254 2
# mknod -m 660 xsa3 b 254 3
Now there should be a directory tts in your dev. If not create one
"mkdir tts". Then do this in the dev/tts folder,
# mknod -m 660 0 c 4 64
If you don't need CF card at all, the easiest method to solve it is to
remove it from the linux kernel configuration.
Regards
Ming
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
^ permalink raw reply
* pdata->phy_id
From: Fredrik Roubert @ 2006-09-01 8:56 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]
Hi!
When running a newer kernel on the MPC8349E-mITX development board, I do
the following changes to mpc834x_sys.c in order to get the PHY working:
diff -urN linux-2.6.17.4.orig/arch/ppc/platforms/83xx/mpc834x_sys.c linux-2.6.17.4/arch/ppc/platforms/83xx/mpc834x_sys.c
--- linux-2.6.17.4.orig/arch/ppc/platforms/83xx/mpc834x_sys.c 2006-07-06 22:02:28.000000000 +0200
+++ linux-2.6.17.4/arch/ppc/platforms/83xx/mpc834x_sys.c 2006-07-24 10:10:36.000000000 +0200
@@ -130,7 +130,7 @@
if (pdata) {
pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
pdata->bus_id = 0;
- pdata->phy_id = 0;
+ pdata->phy_id = 0x1c;
memcpy(pdata->mac_addr, binfo->bi_enetaddr, 6);
}
@@ -138,7 +138,7 @@
if (pdata) {
pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
pdata->bus_id = 0;
- pdata->phy_id = 1;
+ pdata->phy_id = 0x1f;
memcpy(pdata->mac_addr, binfo->bi_enet1addr, 6);
}
Is this really the best way to do it, or would it be preferable to do it
some other way?
Cheers // Fredrik Roubert
--
Visserij 192 | +32 473 344527 / +46 708 776974
BE-9000 Gent | http://www.df.lth.se/~roubert/
[-- Attachment #2: Type: application/pgp-signature, Size: 303 bytes --]
^ permalink raw reply
* Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
From: Mika Penttilä @ 2006-09-01 8:46 UTC (permalink / raw)
To: Mel Gorman
Cc: akpm, tony.luck, linuxppc-dev, ak, bob.picco,
Linux Kernel Mailing List, Linux Memory Management List,
Keith Mannthey
In-Reply-To: <Pine.LNX.4.64.0609010928010.25057@skynet.skynet.ie>
>
> Right, it's all very clear now. At some point in the future, I'd like
> to visit why SPARSEMEM-based hot-add is not always used but it's a
> separate issue.
>
>> The add areas
>> are marked as RESERVED during boot and then later onlined during add.
>
> That explains the reserve_bootmem_node()
>
But pages are marked reserved by default. You still have to alloc the
bootmem map for the the whole node range, including reserve hot add
areas and areas beyond e820-end-of-ram. So all the areas are already
reserved, until freed.
--Mika
^ permalink raw reply
* Re: pci error recovery procedure
From: Zhang, Yanmin @ 2006-09-01 9:04 UTC (permalink / raw)
To: Linas Vepstas
Cc: linuxppc-dev, linux-pci maillist, Yanmin Zhang, LKML, Rajesh Shah
In-Reply-To: <1157082169.20092.174.camel@ymzhang-perf.sh.intel.com>
On Fri, 2006-09-01 at 11:42, Zhang, Yanmin wrote:
> On Fri, 2006-09-01 at 01:50, Linas Vepstas wrote:
> > On Thu, Aug 31, 2006 at 03:10:12PM +0800, Zhang, Yanmin wrote:
> > > Linas,
> > >
> > > I am reviewing the error handlers of e1000 driver and got some ideas. My
> > > startpoint is to simplify the err handler implementations for drivers, or
> > > driver developers are *not willing* to add it if it's too complicated.
> >
> > I don't see that its to complicated ...
> Originally, I didn't think so, but after I try to add err_handlers to some
> drivers, I feel it's too complicated.
>
> >
> > > 1) Callback mmio_enabled looks useless. Documentation/pci-error-recovery.txt
> > > says the current powerpc implementation does not implement this callback.
> >
> > I don't know if its useless or not. I have not needed it yet for the
> > symbios, ipr and e1000 drivers, but its possible that some more
> > sophisticated device may want it. I'm tempted to keep it a while
> > longer befoe discarding it.
> >
> > The scenario is this: the device driver decides that, rather than asking
> > for a full electical reset of the card, instead, it wants to perform
> > its own recovery. It can do this as follows:
> >
> > a) enable MMIO
> > b) issue reset command to adapter
> > c) enable DMA.
> >
> > If we enabled both DMA and MMIO at the same time, there are mnay cases
> > where the card will immediately trap again -- for example, if its
> > DMA'ing to some crazy address. Thus, typically, one wants DMA disabled
> > until after the card reset. Withouth the mmio_enabled() reset, there
> > is no way of doing this.
> The new error_resume, or the old slot_reset could take care of it. The specific
> device driver knows all the details about how to initiate the devices. The
> error_resume could call the step a) b) c) sequencially while doing checking among
> steps.
>
> If there is really a device having specific requirement to reinitiate it (very rarely),
> it could use walkaround, such like schedule a WORKER. No need to provide a generic
> mmio_enabled.
>
> >
> > > 2) Callback slot_reset could be merged with resume. The new resume could be:
> > > int (*error_resume)(struct pci_dev *dev); I checked e1000 and e100 drivers and
> > > think there is no actual reason to have both slot_reset and resume.
> >
> > The idea here was to handle multi-function cards. On a multi-function card,
> > *all* devices need to indicate that they were able to reset. Once all devices
> > have been successfuly reset, then operation can be resumed. If the reset
> > of one function fails, then operation is not resumed for any f the
> > functions.
> I don't think we need slot_reset to coordinate multi-function devices. The new
> error_resume could take care of multi-function card. 'reset' here means driver
> need do I/O to detect if the device (function) still works well. If a function
> of a multi-function device couldn't reset while other functions could reset,
> other functions could just go on to reinitiate. In the end, the error recovery
> procedure (handle_eeh_events in PowerPC implementation) could check all the
> returning values of error_resume. If there is a failure value, then removes
> all the functions' pci_dev of the device from the bus.
>
> >
> > > 3) link_reset is not used in pci express aer implementation, so it could be
> > > deleted also.
> >
> > OK. Link reset was added explicitly to support PCI-E, so if its not wanted,
> > we can eliminate it.
> >
> > > How did you test e1000 err_handler?
> >
> > We have three methods (I thought these were documented). In one, a
> > technician brushes a grounding strap to some of the signal pins.
> > In the second, slots are populated with known-bad cards. The third test
> > involes sending a command down to the pci bridge chip, telling it to
> > behave as if it detected an error. For development, the last is
> > quick-n-easy.
> Thanks for your explanation.
>
> >
> > > In the simulated enviroment, the testing might be
> > > incorrect.
> >
> > Why would it be incorrect? I mean, we don't simulate having someone pour a
> > cup of coffee into the guts of the machine ... but my understanding is
> > the machines do get standard vibration/thermal/humidity testing, which
> > is good enough for me.
> >
> > > For example, e1000_io_error_detected would call e1000_down to reset NIC.
> >
> > Why would that be incorrect?
> >
> > > During
> > > our last discussion on LKML, you said PowerPC will block further I/O if the platform captures
> > > a pci error, so the all I/O in e1000_down will be blocked. Later on, e1000_io_slot_reset
> > > will reenable pci device and initiate NIC. I guess late initiate might fail because prior
> > > e1000_down I/O don't reach NIC.
> >
> > Why would it fail? The e1000_down serves primarily to get the Linux
> > kernel into a known state. It doesn't matter what happens to the card,
> > since the next step will be to perform an electrical reset of the card.
> Who will perform the electrical reset of the card? Function e1000_reset or the platform?
> If it's the platform, I agree with you, but if it's e1000_reset, it might not work because
> e1000_reset uses a e1000-specific approach to reset the card. I'm not sure if the e1000_reset
> will restore the NIC to fresh system power-on state. At least, from the source codes, e1000_reset
> couldn't.
One more comment: The second parameter of error_detected also could be deleted
because recovery procedures will save error to pci_dev->error_state.
So, the err_handler pci_error_handlers could be:
struct pci_error_handlers
{
pci_ers_result_t (*error_detected)(struct pci_dev *dev);
pci_ers_result_t (*error_resume)(struct pci_dev *dev);
};
Yanmin
^ permalink raw reply
* Re: Simple module, but won't build
From: Josu Onandia @ 2006-09-01 6:35 UTC (permalink / raw)
To: Steven Kaiser; +Cc: linuxppc-embedded
In-Reply-To: <000001c6cd50$8c0196f0$6e4ec880@volt>
Steven Kaiser wrote:
>Hi gurus:
>
>Newbie here. I am using ELDK 3.1.1, 2.4.25 kernel, and a Lite5200b board.
>I run the kernel in RAM, and mount a filesystem via NFS. So far so good,
>and I move on to trying to build a simple module to write to a few LEDs.
>
>Simple hello world modules compile and insmod/rmmod fine, but when I try to
>#include <asm/io.h>, here I have the exact same problem as Richard Danter
>did: CONFIG_KERNEL_START and CONFIG_TASK_SIZE are not defined anywhere in
>any headers-- just in the config files.
>
>http://ozlabs.org/pipermail/linuxppc-embedded/2004-May/014037.html
>
>My little wrinkle to add to this problem is I have recompiled the kernel, as
>advised in the replies to Richard's post, with the 'Set Custom Kernel Base
>Address' and 'Set Custom user task size' options enabled, but in my case I
>still I cannot find CONFIG_KERNEL_START and CONFIG_TASK_SIZE defined
>anywhere noteworthy.
>
>My 'include/linux/autoconf.h' file is empty, and I don't even have an
>'include/config/' directory at all. Where in the steps of recompiling the
>kernel should these files and directories get generated?
>
>My process for building the kernel is:
>
>$ cd /opt/eldk/usr/src/linuxppc_2_4_devel
>$ make mrproper
>$ make lite5200b_config
>$ make menuconfig
>$ make dep
>$ make uImage
>$ cp arch/ppc/boot/images/uImage /tftpboot/MPC5200/uImage
>
>I can manually include CONFIG_KERNEL_START and CONFIG_TASK_SIZE in my module
>source, compile, insmod, and all goes well (except my LEDs don't light up
>but first things first).
>
>When my kernel boots, I get a few gripes which I think are related to this
>issue:
>
>Finding module dependencies: depmod: Can't open
>/lib/modules/2.4.25/modules.deg [FAILED]
>modprobe: Can't open dependencies file /lib/modules/2.4.25/modules.dep (No
>such)
>
>Young and foolish, I figured maybe I should try:
>
>$ make modules
>$ make modules_install
>
>Oops. That was bad. Now I cannot even compile the simplest hello.c module
>without a page of errors, the first being a complaint of not being able to
>find linux/autoconf.h. Before I only had trouble when I tried to #include
><asm/io.h>, now it happens 100% of the time.
>
>So I went back and turned off module support, recompiled the kernel, and
>still cannot compile hello.c. I also tried recompiling the kernel after
>doing a "make oldconfig", and still cannot compile a simple module anymore.
>I think I am going to have to go back to square 1 and reinstall ELDK and
>everything from scratch. But before I do:
>
>Any insight into the generation of autoconf.h, and whereabouts this file
>should come from? I will watch for it when I redo the whole process.
>
>Steven Kaiser
>Chemistry Electronics Facility
>University of California, Irvine
>2347 Natural Sciences 2
>Irvine, CA 92697-2025
>(949)824-7520
>
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
I can help you with the leds part of your problem. Below is some simple
code to manage the leds in a Lite5200b.
About the rest of the problem, I can't tell, because my linux/autoconf.h
is OK, and I can include asm/io.h in my modules without problem. To
reinstall everything from scratch is a good idea.
I'm writing modules for a Lite5200b right now, using RTAI. I use the
leds to do some 'visual debugging'. You can contact me directly if you want.
#include <asm/mpc5xxx.h>
struct mpc5xxx_wu_gpio {
volatile u32 enable;
volatile u32 ode;
volatile u32 dir;
volatile u32 data; };
static void configure_leds(void)
{
struct mpc5xxx_gpio *gpio;
struct mpc5xxx_wu_gpio *wu_gpio;
gpio = (struct mpc5xxx_gpio*) MPC5xxx_GPIO;
wu_gpio = (struct mpc5xxx_wu_gpio*)MPC5xxx_WU_GPIO;
gpio->port_config &= ~(0x00f00000);
gpio->simple_gpioe |= 0x30000000;
gpio->simple_ddr |= 0x30000000;
gpio->simple_dvo |= 0x30000000;
wu_gpio->enable |= 0x30000000;
wu_gpio->ode &= ~0x30000000;
wu_gpio->dir |= 0x30000000;
}
static void led_off(int led)
{
struct mpc5xxx_gpio *gpio;
struct mpc5xxx_wu_gpio *wu_gpio;
gpio = (struct mpc5xxx_gpio*) MPC5xxx_GPIO;
wu_gpio = (struct mpc5xxx_wu_gpio*)MPC5xxx_WU_GPIO;
switch( led)
{
case 1:
wu_gpio->data |= 0x20000000;
break;
case 2:
gpio->simple_dvo |= 0x10000000;
break;
case 3:
wu_gpio->data |= 0x10000000;
break;
case 4:
gpio->simple_dvo |= 0x20000000;
break;
default:
break;
}
}
static void led_on(int led)
{
struct mpc5xxx_gpio *gpio;
struct mpc5xxx_wu_gpio *wu_gpio;
gpio = (struct mpc5xxx_gpio*) MPC5xxx_GPIO;
wu_gpio = (struct mpc5xxx_wu_gpio*)MPC5xxx_WU_GPIO;
switch(led)
{
case 1:
wu_gpio->data &= ~0x20000000;
break;
case 2:
gpio->simple_dvo &= ~0x10000000;
break;
case 3:
wu_gpio->data &= ~0x10000000;
break;
case 4:
gpio->simple_dvo &= ~0x20000000;
break;
default:
break;
}
}
^ permalink raw reply
* Backtrace
From: Matias Sundman (AS/EAB) @ 2006-09-01 6:48 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 558 bytes --]
Comrades,
I would like to do a backtrace in kernel space similar to an oops but then continue the code flow as before i.e. without a crash.
If someone has done anything similar, help and/or tips would be much appreciated!
Cheers //
Matias Sundman
Senior Sw Designer
Ericssonl
IS Ethernet Switch, DIPN
Ericsson AB
Box 1505 Office: +46 8 719 86 83
SE-125 25 ÄLVSJÖ ECN: 850 98683
SWEDEN Mobile: +46 70 267 2405
Visiting address: E-mail: Matias.Sundman@ericsson.com
Armborstvägen 14 Web: http://www.ericsson.com
Älvsjö, STOCKHOLM
[-- Attachment #2: Type: text/html, Size: 2741 bytes --]
^ permalink raw reply
* RE: pdata->phy_id
From: Claus Gindhart @ 2006-09-01 9:49 UTC (permalink / raw)
To: Fredrik Roubert, linuxppc-embedded
In-Reply-To: <20060901085602.GD15795@igloo.df.lth.se>
Hi Frederick,
if your board is somehow similiar to the MPC834x-SYS, but not exactly =
identical, i would copy the file mpc834x_sys.c and .h to .e.g =
mpc8349_mitx.c and .h; add a config option to the Kconfig within this =
directory, and an entry to the Makefile.
Then, you can add all the HW-specific modifications here.
--=20
Mit freundlichen Gruessen / Best regards
Claus Gindhart
SW R&D
Kontron Modular Computers
phone :++49 (0)8341-803-374
mailto:claus.gindhart@kontron-modular.com
http://www.kontron.com
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GU d- s++:>++:+ a+ C++$ !U !P L++>$ E-- W+(-) N- o?
K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++
D-- G e++> h--- !r x+++
------END GEEK CODE BLOCK------
=20
-----Original Message-----
From: linuxppc-embedded-bounces+claus.gindhart=3Dkontron.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+claus.gindhart=3Dkontron.com@ozlabs.org=
]
On Behalf Of Fredrik Roubert
Sent: Freitag, 1. September 2006 10:56
To: linuxppc-embedded@ozlabs.org
Subject: pdata->phy_id
Hi!
When running a newer kernel on the MPC8349E-mITX development board, I do
the following changes to mpc834x_sys.c in order to get the PHY working:
diff -urN linux-2.6.17.4.orig/arch/ppc/platforms/83xx/mpc834x_sys.c =
linux-2.6.17.4/arch/ppc/platforms/83xx/mpc834x_sys.c
--- linux-2.6.17.4.orig/arch/ppc/platforms/83xx/mpc834x_sys.c 2006-07-06 =
22:02:28.000000000 +0200
+++ linux-2.6.17.4/arch/ppc/platforms/83xx/mpc834x_sys.c 2006-07-24 =
10:10:36.000000000 +0200
@@ -130,7 +130,7 @@
if (pdata) {
pdata->board_flags =3D FSL_GIANFAR_BRD_HAS_PHY_INTR;
pdata->bus_id =3D 0;
- pdata->phy_id =3D 0;
+ pdata->phy_id =3D 0x1c;
memcpy(pdata->mac_addr, binfo->bi_enetaddr, 6);
}
@@ -138,7 +138,7 @@
if (pdata) {
pdata->board_flags =3D FSL_GIANFAR_BRD_HAS_PHY_INTR;
pdata->bus_id =3D 0;
- pdata->phy_id =3D 1;
+ pdata->phy_id =3D 0x1f;
memcpy(pdata->mac_addr, binfo->bi_enet1addr, 6);
}
Is this really the best way to do it, or would it be preferable to do it
some other way?
Cheers // Fredrik Roubert
--=20
Visserij 192 | +32 473 344527 / +46 708 776974
BE-9000 Gent | http://www.df.lth.se/~roubert/
^ permalink raw reply
* Re: Backtrace
From: KokHow Teh @ 2006-09-01 10:12 UTC (permalink / raw)
To: matias.sundman; +Cc: linuxppc-embedded
Hi;
Is using hardware/software breakpoint with a hardware debugger wh=
at
you are looking for?
Regards,
Teh
"Matias Sundman \(AS/EAB\)" <matias.sundman@ericsson.com>@ozlabs.org on=
09/01/2006 02:48:43 PM
Sent by: linuxppc-embedded-bounces+kokhow.teh=3Dmarconi.com@ozlabs.o=
rg
To: <linuxppc-embedded@ozlabs.org>
cc:
Subject: Backtrace
Comrades,
I would like to do a backtrace in kernel space similar to an oops but t=
hen
continue the code flow as before i.e. without a crash.
If someone has done anything similar, help and/or tips would be much
appreciated!
Cheers //
Matias Sundman
Senior Sw Designer
Ericssonl
IS Ethernet Switch, DIPN
Ericsson AB
Box 1505=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=
Office: +46=A0 8 719 86 83
SE-125 25 =C4LVSJ=D6=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 ECN:=A0=
=A0=A0 850 98683
SWEDEN=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 Mobile: +46 70 26=
7 2405
Visiting address:=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0E-mail: Matias=
.Sundman@ericsson.com
Armborstv=E4gen 14=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 Web:=A0=A0=
=A0 http://www.ericsson.com
=C4lvsj=F6, STOCKHOLM
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
=
^ permalink raw reply
* RE: Backtrace
From: Matias Sundman (AS/EAB) @ 2006-09-01 10:49 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Örjan Gustavsson (AS/EAB)
In-Reply-To: <OFAC529115.08187271-ON482571DC.003802B3@uk.marconicomms.com>
=20
Hello,
We have HW debuggers ; Windriver ICE and BDI2000 , but in our specific =
scenario the system is up=20
and running and we cannot be breakpoint intrusive, other parts of the =
system would be affected ( and our own blade ).
No, what we would like to do is that when a specific condition is met a =
backtrace printout
is performed and after that the system runs as designed.
:
[Existing code]
:=20
:
if ( some_variable =3D=3D my_condition )
{
print_out_backtrace();
}
:
:
[Existing code]
:=20
:
We have implemented "forced" kernel ooops:es in "print_out_backtrace();" =
but we would like to=20
have controlled backtraces ;-))
This is in Kernel space on a ppc8270.=20
Cheers // Matias
-----Original Message-----
From: KokHow Teh [mailto:KokHow.Teh@marconi.com]=20
Sent: den 1 september 2006 12:13
To: Matias Sundman (AS/EAB)
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Backtrace
Hi;
Is using hardware/software breakpoint with a hardware debugger =
what
you are looking for?
Regards,
Teh
"Matias Sundman \(AS/EAB\)" <matias.sundman@ericsson.com>@ozlabs.org on
09/01/2006 02:48:43 PM
Sent by: =
linuxppc-embedded-bounces+kokhow.teh=3Dmarconi.com@ozlabs.org
To: <linuxppc-embedded@ozlabs.org>
cc:
Subject: Backtrace
Comrades,
I would like to do a backtrace in kernel space similar to an oops but =
then
continue the code flow as before i.e. without a crash.
If someone has done anything similar, help and/or tips would be much
appreciated!
Cheers //
Matias Sundman
Senior Sw Designer
Ericssonl
IS Ethernet Switch, DIPN
Ericsson AB
Box 1505=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =
=A0=A0=A0=A0=A0=A0=A0 Office: +46=A0 8 719 86 83
SE-125 25 =C4LVSJ=D6=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =
ECN:=A0=A0=A0 850 98683
SWEDEN=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 Mobile: +46 70 267 =
2405
Visiting address:=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0E-mail: =
Matias.Sundman@ericsson.com
Armborstv=E4gen 14=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =
Web:=A0=A0=A0 http://www.ericsson.com
=C4lvsj=F6, STOCKHOLM
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: 82xx fcc_enet problem between Linux 2.4 and 2.6
From: Bastos Fernandez Alexandre @ 2006-09-01 11:43 UTC (permalink / raw)
To: Laurent Lagrange; +Cc: linuxppc-embedded
In-Reply-To: <002101c6cd25$6945e470$5201a8c0@GEG2400>
Laurent,
>
> I work on several custom 82xx boards with Linux 2.4 and 2.6.
>
> I have ported Linux 2.6.9 on different boards and I noticed
> that I have tx carrier errors on my FCC ports. Almost one
> error per xmit.
>
I have experienced same problem. I suppose you are using the old
fcc driver in /arch/ppc
> I reinstalled Linux 2.4.18 on these boards and I have NO ERROR.
>
> The errors arise with PHY configured in 100M full duplex (or autoneg).
> The FCC has the same duplex as PHY.
Are you sure? In my case, the problem was that while the PHY had autoneg
to full-duplex, the MAC kept in half-duplex mode
> [...]
>
> I think this is not a phy or hardware problem but rather a FCC configuration
> mismatch in fcc_enet.c.
>
Yes. But I thing the driver has been obsoleted by fs_enet one,
so modifiying it now has no sense.
Best regards,
Alex BASTOS
^ permalink raw reply
* Re: Unable to boot kernel 2.6 from u-boot 1.1.4 in Xilinx ML403
From: Jeff Angielski @ 2006-09-01 13:49 UTC (permalink / raw)
To: Aleck Lin; +Cc: linuxppc-embedded
In-Reply-To: <000a01c6cd6e$5e1970a0$800101df@monstertop>
On Thu, 2006-08-31 at 19:28 -0700, Aleck Lin wrote:
> Hi,
>
> I'm working on booting kernel 2.6 on Xilinx. And I'm encountering a few
> problems.
>
> 1. When I directly download zImage.elf to the RAM and boot from there, I see
> the kernel starts booting, but it complains about not being able to mount
> /dev/sysace/disc0/part2 and thus kernel panic happens.
Can u-boot access the systemace CF?
Do the kernel statup messages show that the system ace driver is loaded
and has successfully initialized? I don't see this in your boot message
dump.
Jeff Angielski
The PTR Group
^ permalink raw reply
* RE: 82xx fcc_enet problem between Linux 2.4 and 2.6
From: Laurent Lagrange @ 2006-09-01 14:26 UTC (permalink / raw)
To: 'Bastos Fernandez Alexandre'; +Cc: linuxppc-embedded
In-Reply-To: <1157111000.44f81cd8cb6d6@webmail.televes.com:443>
Hello Alex,
> > I have ported Linux 2.6.9 on different boards and I noticed
> > that I have tx carrier errors on my FCC ports. Almost one
> > error per xmit.
> I have experienced same problem. I suppose you are using the old
> fcc driver in /arch/ppc
Yes that's right.
> > I reinstalled Linux 2.4.18 on these boards and I have NO ERROR.
> > The errors arise with PHY configured in 100M full duplex (or autoneg).
> > The FCC has the same duplex as PHY.
> Are you sure? In my case, the problem was that while the PHY had autoneg
> to full-duplex, the MAC kept in half-duplex mode
I have modified some code in fcc_enet.c for Linux 2.4 to manage PHY as I
wanted.
Perhaps was I in luck to correct something wrong. I checked that the duplex
were identical for FCC and PHY and I had no carrier error.
> > I think this is not a phy or hardware problem but rather a
> FCC configuration mismatch in fcc_enet.c.
> Yes. But I think the driver has been obsoleted by fs_enet one,
> so modifiying it now has no sense.
Yes I retreived fs_enet in Linux 2.6.15 and I'll try it.
This driver seems to appear in Linux 2.6.11 tree not before.
Is it right ?
Thanks very much for your reply.
Best regards
Laurent
^ permalink raw reply
* [PATCH] Add new, missing argument to of_irq_map_raw().
From: Jon Loeliger @ 2006-09-01 15:17 UTC (permalink / raw)
To: linuxppc-dev
Ben speaks; we follow.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
Paul,
This patch is needed in the 2.6.18 release for 86xx.
Ben's recent changes to of_irq_map_raw() missed one caller.
This patch cleans that up.
Thanks,
jdl
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index 4a33d95..cdaf668 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -154,7 +154,7 @@ get_pci_irq_from_of(struct pci_controlle
laddr[0] = (hose->first_busno << 16) | (PCI_DEVFN(slot, 0) << 8);
laddr[1] = laddr[2] = 0;
- of_irq_map_raw(hosenode, &pin, laddr, &oirq);
+ of_irq_map_raw(hosenode, &pin, 1, laddr, &oirq);
DBG("mpc86xx_hpcn: pci irq addr %x, slot %d, pin %d, irq %d\n",
laddr[0], slot, pin, oirq.specifier[0]);
return oirq.specifier[0];
--
1.4.2.rc2.g85d6c-dirty
^ permalink raw reply related
* Re: Backtrace
From: Carlos Munoz @ 2006-09-01 16:42 UTC (permalink / raw)
To: Matias Sundman (AS/EAB); +Cc: linuxppc-embedded
In-Reply-To: <24521B9781EAC745A4BE65966F69C9BE02BACDA8@esealmw115.eemea.ericsson.se>
Matias Sundman (AS/EAB) wrote:
> Comrades,
> I would like to do a backtrace in kernel space similar to an oops but
> then continue the code flow as before i.e. without a crash.
>
Try dump_stack(). It should do what you want.
Carlos
^ permalink raw reply
* Unable to boot kernel 2.6 from u-boot 1.1.4 in Xilinx ML403
From: Aleck Lin @ 2006-09-01 17:35 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.3.1157101919.2423.linuxppc-embedded@ozlabs.org>
Sorry ,that was a typo, I did use "uImage"
Thanks,
Aleck
>
> 1. When I directly download zImage.elf to the RAM and boot from there, I
see
...
> 2. When I tried to boot the zImage (sitting in the flash) from u-boot file
When you use U-Boot, you should use the correct image (uImage).
Best regards,
Wolfgang Denk
^ permalink raw reply
* Re: pci error recovery procedure
From: Linas Vepstas @ 2006-09-01 21:25 UTC (permalink / raw)
To: Zhang, Yanmin
Cc: linuxppc-dev, linux-pci maillist, Yanmin Zhang, linux-kernel,
Rajesh Shah
In-Reply-To: <1157081629.20092.167.camel@ymzhang-perf.sh.intel.com>
On Fri, Sep 01, 2006 at 11:33:49AM +0800, Zhang, Yanmin wrote:
> On Fri, 2006-09-01 at 01:50, Linas Vepstas wrote:
> > On Thu, Aug 31, 2006 at 03:10:12PM +0800, Zhang, Yanmin wrote:
> > > Linas,
> > >
> > > I am reviewing the error handlers of e1000 driver and got some ideas. My
> > > startpoint is to simplify the err handler implementations for drivers, or
> > > driver developers are *not willing* to add it if it's too complicated.
> >
> > I don't see that its to complicated ...
> Originally, I didn't think so, but after I try to add err_handlers to some
> drivers, I feel it's too complicated.
Which drivers are you working on?
> > > 1) Callback mmio_enabled looks useless. Documentation/pci-error-recovery.txt
> > > says the current powerpc implementation does not implement this callback.
> >
> > I don't know if its useless or not. I have not needed it yet for the
> > symbios, ipr and e1000 drivers, but its possible that some more
> > sophisticated device may want it. I'm tempted to keep it a while
> > longer befoe discarding it.
> >
> > The scenario is this: the device driver decides that, rather than asking
> > for a full electical reset of the card, instead, it wants to perform
> > its own recovery. It can do this as follows:
> >
> > a) enable MMIO
> > b) issue reset command to adapter
> > c) enable DMA.
> >
> > If we enabled both DMA and MMIO at the same time, there are mnay cases
> > where the card will immediately trap again -- for example, if its
> > DMA'ing to some crazy address. Thus, typically, one wants DMA disabled
> > until after the card reset. Withouth the mmio_enabled() reset, there
> > is no way of doing this.
> The new error_resume, or the old slot_reset could take care of it. The specific
> device driver knows all the details about how to initiate the devices. The
> error_resume could call the step a) b) c) sequencially while doing checking among
> steps.
Again, consider the multi-function cards. On pSeries, I can only enable
DMA on a er-slot basis, not a per-function basis. So if one driver
enables DMA before some other driver has reset appropriately, everything
breaks.
> If there is really a device having specific requirement to reinitiate it (very rarely),
> it could use walkaround, such like schedule a WORKER. No need to provide a generic
> mmio_enabled.
I don't understand. Enabling MMIO and enabling DMA both require specific
commands to be sent to the PCI-host bridge. These commands are not a
part of the PCI spec.
> > > 2) Callback slot_reset could be merged with resume. The new resume could be:
> > > int (*error_resume)(struct pci_dev *dev); I checked e1000 and e100 drivers and
> > > think there is no actual reason to have both slot_reset and resume.
> >
> > The idea here was to handle multi-function cards. On a multi-function card,
> > *all* devices need to indicate that they were able to reset. Once all devices
> > have been successfuly reset, then operation can be resumed. If the reset
> > of one function fails, then operation is not resumed for any f the
> > functions.
> I don't think we need slot_reset to coordinate multi-function devices. The new
> error_resume could take care of multi-function card.
How?
> 'reset' here means driver
> need do I/O to detect if the device (function) still works well. If a function
> of a multi-function device couldn't reset while other functions could reset,
> other functions could just go on to reinitiate. In the end, the error recovery
> procedure (handle_eeh_events in PowerPC implementation) could check all the
> returning values of error_resume. If there is a failure value, then removes
> all the functions' pci_dev of the device from the bus.
I can only enable or disable an entire PCI slot, and not individual PCI
functions. If there are some pins that are shorted, or parity errors or
whatever, I can only turn off the whole card.
> > > During
> > > our last discussion on LKML, you said PowerPC will block further I/O if the platform captures
> > > a pci error, so the all I/O in e1000_down will be blocked. Later on, e1000_io_slot_reset
> > > will reenable pci device and initiate NIC. I guess late initiate might fail because prior
> > > e1000_down I/O don't reach NIC.
> >
> > Why would it fail? The e1000_down serves primarily to get the Linux
> > kernel into a known state. It doesn't matter what happens to the card,
> > since the next step will be to perform an electrical reset of the card.
> Who will perform the electrical reset of the card? Function e1000_reset or the platform?
The platform. By "electrical reset", I mean "dropping the #RST pin low
for 200mS". Only the platform can do this.
> If it's the platform, I agree with you, but if it's e1000_reset, it might not work because
> e1000_reset uses a e1000-specific approach to reset the card.
The driver has to choices: it can ask for the electrical reset, by
returning PCI_ERS_RESULT_NEED_RESET. But if the driver doesn't need
the electrical reset, then it can return PCI_ERS_RESULT_CAN_RECOVER,
and issue whatever device-specific commands it needs to reset.
> I'm not sure if the e1000_reset
> will restore the NIC to fresh system power-on state. At least, from the source codes, e1000_reset
> couldn't.
I have no idea. That's why this driver issues PCI_ERS_RESULT_NEED_RESET,
which will get it into a fresh system power-on state. Its easy, its
brute-force, it works.
--linas
^ permalink raw reply
* Re: pci error recovery procedure
From: Linas Vepstas @ 2006-09-01 21:32 UTC (permalink / raw)
To: Zhang, Yanmin
Cc: linuxppc-dev, linux-pci maillist, Yanmin Zhang, LKML, Rajesh Shah
In-Reply-To: <1157101449.20092.180.camel@ymzhang-perf.sh.intel.com>
On Fri, Sep 01, 2006 at 05:04:09PM +0800, Zhang, Yanmin wrote:
> One more comment: The second parameter of error_detected also could be deleted
> because recovery procedures will save error to pci_dev->error_state.
Yes, I beleive so.
> So, the err_handler pci_error_handlers could be:
> struct pci_error_handlers
> {
> pci_ers_result_t (*error_detected)(struct pci_dev *dev);
> pci_ers_result_t (*error_resume)(struct pci_dev *dev);
> };
No, as per other email, we still need a multi-step process for
multi-function cards, and for cards that may not want to get
a full electrical reset. Finally, there might be platforms
that cannot perform a per-slot electrical reset, and would
therefore require drivers that can recover on thier own.
--linas
^ permalink raw reply
* RE: PPC405 system slow boot
From: Clint Thomas @ 2006-09-01 22:57 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Jason Lamb, Peter Ryser
In-Reply-To: <44F38E28.9020201@xilinx.com>
[-- Attachment #1: Type: text/plain, Size: 2520 bytes --]
The xparameters.h file is generated by the Xilinx EDK for our FPGA, so I
don't see how there could be a mismatch. Using Chipscope, we were able
to find that the interrupt controller is triggered on kernel
initialization, but after the kernel has finished loading, the system
moves to a snail's pace at login.
Does Linux use a different set of code to handle the UART, INTC, etc.
after the kernel is loaded? The system appears to work perfectly up
until after the kernel is done loading.
________________________________
From: Peter Ryser [mailto:peter.ryser@xilinx.com]
Sent: Monday, August 28, 2006 8:45 PM
To: Clint Thomas
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: PPC405 system slow boot
Clint,
check the interrupt sub-system of your design. What you describe
typically happens when the PPC does not get any interrupts from the
UART. It's most likely a mismatch between your hardware and the
xparameters.h.
- Peter
Clint Thomas wrote:
Hey guys,
I've run through the loops to try and figure what could be wrong
with this system. The board in question is modeled after the Xilinx
ML300 board. It uses a Xilinx System ACE chip to load a FPGA / Kernel
image from compact flash. Originally, I was trying to use the
CompactFlash as the root file system, but because of issues in either
the design or software, this would only work if SysAce was in polled I/O
mode. To circumvent this, I built my root filesystem into an initrd
image and built a single ELF file with the Kernel and RFS, then strapped
that to the FPGA bit file to make a single FPGA/Kernel/RFS SysAce file.
Upon decompression, the Linux kernel boots quickly and loads all
of the device drivers. However when it gets to the prompt, it starts
slowing down. Output and input to and from the board becomes very very
slow (it displays 2 characters roughly every 20 seconds). Originally I
believed this to be the CPU still polling SystemAce, so I disabled the
Linux System ACE drivers to remove that as a possibility, however after
doing this, the problem still persists, even with the RFS in ram! Has
anybody encountered a similar situation to this before, with possible
insight towards a solution? Thank you for your time.
Clinton Thomas
cthomas@soneticom.com
________________________________
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 3970 bytes --]
^ permalink raw reply
* Re: [PATCH] Add new, missing argument to of_irq_map_raw().
From: Benjamin Herrenschmidt @ 2006-09-02 3:29 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1GJAlk-00053S-3U@jdl.com>
On Fri, 2006-09-01 at 10:17 -0500, Jon Loeliger wrote:
> Ben speaks; we follow.
Ooops, sorry. I din't grep around thinking nobody would need to use that
low level function but it looks like you do have a good reason to do
so.
Ben.
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
> ---
>
> Paul,
>
> This patch is needed in the 2.6.18 release for 86xx.
> Ben's recent changes to of_irq_map_raw() missed one caller.
> This patch cleans that up.
>
> Thanks,
> jdl
>
>
> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
> index 4a33d95..cdaf668 100644
> --- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
> +++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
> @@ -154,7 +154,7 @@ get_pci_irq_from_of(struct pci_controlle
>
> laddr[0] = (hose->first_busno << 16) | (PCI_DEVFN(slot, 0) << 8);
> laddr[1] = laddr[2] = 0;
> - of_irq_map_raw(hosenode, &pin, laddr, &oirq);
> + of_irq_map_raw(hosenode, &pin, 1, laddr, &oirq);
> DBG("mpc86xx_hpcn: pci irq addr %x, slot %d, pin %d, irq %d\n",
> laddr[0], slot, pin, oirq.specifier[0]);
> return oirq.specifier[0];
^ permalink raw reply
* A question about POST
From: enorm @ 2006-09-02 13:29 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 162 bytes --]
Hi,
I want to know after poweron, how can cpu(etc. e500) know how many bits he can get when reading flash.
would some one pls tell me?
Best regards
enorm
[-- Attachment #2: Type: text/html, Size: 675 bytes --]
^ permalink raw reply
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
From: Stefan Richter @ 2006-09-02 19:18 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev, billfink, linux1394-devel
In-Reply-To: <20060824192200.GA2715@localhost>
Wolfgang Pfeiffer wrote on 2006-08-24:
> On Wed, Aug 23, 2006 at 02:28:01AM +0200, Wolfgang Pfeiffer wrote:
>> Some tests on the Alubook:
>
>
> .. but this time with "modprobe ieee1394 disable_irm=1". 2 logs were be
> created:
> www.wolfgangpfeiffer.com/disable-irm.kern.log.when.fw.disk.is.switched.on.txt
> www.wolfgangpfeiffer.com/disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt
Thanks for all the logs, and sorry for the delay.
What happens is that the ieee1394 base driver or gscanbus via raw1394
are able to read from the beginning of the ROM, but the disk's bridge
does not send response packets anymore at some random point. In the
first log, it happens at ROM offset ffff f000 0448, in the second at
ffff f000 0414, in the third at ffff f000 042c, in the fourth at ffff
f000 0494. The bridge still ack'ed the last attempted read requests with
"ack_pending" like each previous successful read request, but suddenly
it does not follow up with a response.
Unfortunately I cannot see how to cure the problem. There is no
indication at all why the disk stops to respond at random points after
the first chunks of the ROM were transferred OK. It is not extremely
surprising; after all the Datafab's bridge is a pretty old one from
before IEEE 1394a-2000. Nevertheless it should work OK with the
1394b-2002 PowerBook since the enclosure even has a 1394a-2000 PHY. I
think I already mentioned that I have a similar pre-1394a CD-RW which
works well on a 1394b card.
Alas I am out of ideas. Perhaps you should purchase a new enclosure.
Before you do that, you could test the AluBook running Linux and TiBook
in target disk mode again to exclude the possibility of problems at the
AluBook's side. Use "hdparm -tT /dev/sda" to try a few actual block read
operations. This should show about 20 MByte/s. It is a read-only test
and therefore safe.
BTW, I saw one thing in your logs which you are certainly not interested
in at all. :-) We seem to have an endianess bug in
ohci1394.c::dma_rcv_tasklet's DBGMSG. My attempt to fix the printout of
tlabels last year didn't get it completely right.
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=dfe547ab872951949a1a2fcc5cedbedad27a2fe5
I think the cond_le32_to_cpu has to be omitted there.
--
Stefan Richter
-=====-=-==- =--= ---=-
http://arcgraph.de/sr/
^ permalink raw reply
* MPC8245 reset register
From: Reeve Yang @ 2006-09-02 22:46 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 186 bytes --]
Can anyone tell me which register should I use to do soft reset on MPC8241/5
CPU? I searched its manuall but only find EPIC to send SRESET exception on
offset 0x41090.
Thanks.
- Reeve
[-- Attachment #2: Type: text/html, Size: 206 bytes --]
^ permalink raw reply
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
From: Wolfgang Pfeiffer @ 2006-09-02 23:08 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, billfink, linux1394-devel
In-Reply-To: <44F9D8EF.6010101@s5r6.in-berlin.de>
On Sat, Sep 02, 2006 at 09:18:07PM +0200, Stefan Richter wrote:
> Wolfgang Pfeiffer wrote on 2006-08-24:
> >On Wed, Aug 23, 2006 at 02:28:01AM +0200, Wolfgang Pfeiffer wrote:
> >>Some tests on the Alubook:
> >
> >
> >.. but this time with "modprobe ieee1394 disable_irm=1". 2 logs were be
> >created:
> >www.wolfgangpfeiffer.com/disable-irm.kern.log.when.fw.disk.is.switched.on.txt
> >www.wolfgangpfeiffer.com/disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt
>
> Thanks for all the logs, and sorry for the delay.
>
> What happens is that the ieee1394 base driver or gscanbus via raw1394
> are able to read from the beginning of the ROM, but the disk's bridge
> does not send response packets anymore at some random point. In the
> first log, it happens at ROM offset ffff f000 0448, in the second at
> ffff f000 0414, in the third at ffff f000 042c, in the fourth at ffff
> f000 0494. The bridge still ack'ed the last attempted read requests with
> "ack_pending" like each previous successful read request, but suddenly
> it does not follow up with a response.
>
> Unfortunately I cannot see how to cure the problem.
Sorry to hear that ..
> There is no indication at all why the disk stops to respond at
> random points after the first chunks of the ROM were transferred
> OK. It is not extremely surprising; after all the Datafab's bridge
> is a pretty old one from before IEEE 1394a-2000. Nevertheless it
> should work OK with the 1394b-2002 PowerBook since the enclosure
> even has a 1394a-2000 PHY. I think I already mentioned that I have a
> similar pre-1394a CD-RW which works well on a 1394b card.
>
> Alas I am out of ideas. Perhaps you should purchase a new enclosure.
I'll be very careful before doing that: Yesterday I was at a computer
shop downtown for a little test whether the FW 800 port could detect
the enclosure. The service guy was really helpful, perhaps even
interested when I explained the FW problem we have with this
alubook. So we connected via a 9:6 (?) pin cable the enclosure to the
FW800 of the alubook. To no avail.
He then proposed to connect the disk instead via the FW enclosure via
a USB case. Didn't work, too. And this although any USB device (USB stick,
a camera, mouse) I connected to the USB ports was detected correctly.
> Before you do that, you could test the AluBook running Linux and TiBook
> in target disk mode again to exclude the possibility of problems at the
> AluBook's side. Use "hdparm -tT /dev/sda" to try a few actual block read
> operations.
I do not have to mount /dev/sda for the test. Correct?
> This should show about 20 MByte/s. It is a read-only test
> and therefore safe.
>
> BTW, I saw one thing in your logs which you are certainly not interested
> in at all. :-)
Not quite true :) ... The only frustrating thing for me is my lacking
knowledge when it comes to understand code like the one on the
kernel.org page below .. but I hope I find a way to change that
situation .. :)
> We seem to have an endianess bug in
> ohci1394.c::dma_rcv_tasklet's DBGMSG. My attempt to fix the printout of
> tlabels last year didn't get it completely right.
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=dfe547ab872951949a1a2fcc5cedbedad27a2fe5
> I think the cond_le32_to_cpu has to be omitted there.
Please let me know if I can help with tests if you want to patch
ohci1394.
And thanks for all your efforts; for your explanations, too, for my
scsi.start.sh script in your email from Aug 19. It helped me a lot ...
Nice week-end
Best Regards
Wolfgang
--
Wolfgang Pfeiffer: /ICQ: 286585973/ + + + /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer
Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on
^ 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