* Re: Recommendations for supported 4-port SATA PCI card ?
From: Brad Campbell @ 2006-04-01 0:28 UTC (permalink / raw)
To: Christopher Smith; +Cc: linux-raid
In-Reply-To: <442D22CD.3010602@nighthawkrad.net>
Christopher Smith wrote:
> Ian Thurlbeck wrote:
>>
>> Dear All
>>
>> I have 4x500GB Maxtor SATA drives and I want to attach
>> these to a 4-port SATA PCI card and RAID5 them using "md"
>>
>> Could anybody recommend a card that will have out of
>> box support on a Fedora system ?
>
> I have had a lot of success with Promise TX4 cards, with the caveat that
> more than two controllers can't be in the same box (or couldn't as of a
> few months ago - this may have been fixed). They're fairly cheap and
I've been running 3 together in one box for about 18 months, and four in another for a year now...
the on board BIOS will only pickup 8 drives, but they work just fine under Linux and recognise all
connected drives.
I have 11 drives in one box (on promise.. 2 on the on-board VIA and 1 on PATA) and 15 drives in
another (all across 4 promise cards).. all on SATA150-TX4 cards..
Performance sucks.. but then when you put 15 drives on a single PCI 33Mhz bus what do you expect ?
Great for streaming media though.. (and cheap, and very reliable). The only media errors I get are
on the VIA controller. The promise controllers have not had a single media error since they were
installed.
Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
^ permalink raw reply
* Re: [ck] Re: Staircase test patch
From: Peter Williams @ 2006-04-01 0:22 UTC (permalink / raw)
To: Con Kolivas; +Cc: ck, Thorsten Will, linux list
In-Reply-To: <200604010917.09413.kernel@kolivas.org>
Con Kolivas wrote:
> On Saturday 01 April 2006 07:31, Thorsten Will wrote:
>> On Friday 31 March 2006 23:07 +1000, Con Kolivas wrote:
>>> Hi Thorsten et al
>> Hi, Con.
>>
>>> Thorsten could you please test to see if this fixes the problem for you?
>> Oh boy, oh boy, oh boy.
>>
>> Against a bash loop:
>> |# dd bs=1M count=2048 </dev/hdb >/dev/null
>> |2048+0 records in
>> |2048+0 records out
>> |2147483648 bytes transferred in 35.497603 seconds (60496582 bytes/sec)
>>
>> Yes! Success! And the crowd goes wild! :-)
>>
>> I think you finally nailed it. Thank you so much!
>
> No, thank _you_ for bringing it to my attention and testing :)
Should I apply this to staircase in PlugSched?
Peter
--
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
^ permalink raw reply
* Re: Avoid excessive time spend on concurrent slab shrinking
From: Christoph Lameter @ 2006-04-01 0:22 UTC (permalink / raw)
To: Andrew Morton; +Cc: nickpiggin, linux-mm
In-Reply-To: <20060331160032.6e437226.akpm@osdl.org>
On Fri, 31 Mar 2006, Andrew Morton wrote:
> > A build server. Lots of scripts running, compilers etc etc.
>
> Interesting. Many CPUs?
12 processors. 6 nodes.
> A plain old sysrq-T would be great. That'll tell us who owns iprune_sem,
> and what he's up to while holding it. Actually five-odd sysrq-T's would be
> better.
Some traces:
Stack traceback for pid 16836
0xe00000380bc68000 16836 1 1 6 R
0xa00000020b8e6050 [xfs]xfs_iextract+0x190
0xa00000020b8e63a0 [xfs]xfs_ireclaim+0x80
0xa00000020b921c70 [xfs]xfs_finish_reclaim+0x330
0xa00000020b921fa0 [xfs]xfs_reclaim+0x140
0xa00000020b93f820 [xfs]linvfs_clear_inode+0x260
0xa0000001001855f0 clear_inode+0x310
0xa000000100185f70 dispose_list+0x90
0xa000000100186c40 shrink_icache_memory+0x480
0xa000000100105bb0 shrink_slab+0x290
0xa000000100107cc0 try_to_free_pages+0x380
0xa0000001000f9f70 __alloc_pages+0x330
0xa0000001000ed940 page_cache_alloc_cold+0x160
0xa0000001000fe3a0 __do_page_cache_readahead+0x120
0xa0000001000fe820 blockable_page_cache_readahead+0xe0
0xa0000001000fea50 make_ahead_window+0x150
0xa0000001000fee30 page_cache_readahead+0x390
0xa0000001000ee730 do_generic_mapping_read+0x190
0xa0000001000efd80 __generic_file_aio_read+0x2c0
0xa00000020b93c190 [xfs]xfs_read+0x3b0
0xa00000020b934170 [xfs]linvfs_aio_read+0x130
Stack traceback for pid 19357
0xe000003815dc0000 19357 19108 0 10 D
0xa000000100524b80 schedule+0x2940
0xa000000100521ee0 __down+0x260
0xa000000100186880 shrink_icache_memory+0xc0
0xa000000100105bb0 shrink_slab+0x290
0xa000000100107cc0 try_to_free_pages+0x380
0xa0000001000f9f70 __alloc_pages+0x330
0xa00000010012e7d0 alloc_page_vma+0x150
0xa0000001001108d0 __handle_mm_fault+0x390
0xa00000010052c520 ia64_do_page_fault+0x280
0xa00000010000caa0 ia64_leave_kernel
0xa0000001000f29b0 file_read_actor+0xb0
0xa0000001000ee830 do_generic_mapping_read+0x290
0xa0000001000efd80 __generic_file_aio_read+0x2c0
0xa00000020b93c190 [xfs]xfs_read+0x3b0
0xa00000020b934170 [xfs]linvfs_aio_read+0x130
0xa000000100146430 do_sync_read+0x170
0xa000000100147f20 vfs_read+0x200
0xa000000100148790 sys_read+0x70
0xa00000010000c830 ia64_trace_syscall+0xd0
Stack traceback for pid 12033
0xe000003414cd0000 12033 18401 0 10 D
0xa000000100524b80 schedule+0x2940
0xa000000100521ee0 __down+0x260
0xa000000100186880 shrink_icache_memory+0xc0
0xa000000100105bb0 shrink_slab+0x290
0xa000000100107cc0 try_to_free_pages+0x380
0xa0000001000f9f70 __alloc_pages+0x330
0xa00000010012e7d0 alloc_page_vma+0x150
0xa0000001001108d0 __handle_mm_fault+0x390
0xa00000010052c520 ia64_do_page_fault+0x280
0xa00000010000caa0 ia64_leave_kernel
0xa0000001000f29b0 file_read_actor+0xb0
0xa0000001000ee830 do_generic_mapping_read+0x290
0xa0000001000efd80 __generic_file_aio_read+0x2c0
0xa00000020b93c190 [xfs]xfs_read+0x3b0
0xa00000020b934170 [xfs]linvfs_aio_read+0x130
0xa000000100146430 do_sync_read+0x170
0xa000000100147f20 vfs_read+0x200
0xa000000100148790 sys_read+0x70
0xa00000010000c830 ia64_trace_syscall+0xd0
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [patch] PI-futex patchset: -V4
From: Peter Williams @ 2006-04-01 0:19 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Andrew Morton, linux-kernel, tglx, torvalds, Esben Nielsen
In-Reply-To: <20060331191445.GA2250@elte.hu>
Ingo Molnar wrote:
> this is version -V4 of the PI-futex patchset (ontop of current -mm2,
> which includes -V3.)
>
> A clean queue of split-up patches can be found at:
>
> http://redhat.com/~mingo/PI-futex-patches/PI-futex-patches-V4.tar.gz
>
> the -V4 codebase has been tested on the glibc code (all testcases pass)
> and under load as well. (The -V4 code is included in the 2.6.16-rt12
> code as well that i released earlier today.)
>
> Changes since -V3:
>
> - added Esben Nielsen's PI locking code, Thomas Gleixner made it
> work in cornercases and under load. This is significantly simpler (it
> removes 50 lines of code from rtmutex.c). The main difference is that
> instead of holding all locks along a dependency chain, this code
> propagates PI priorities (and detects deadlocks) by holding at most
> two locks at once, and by being preemptible between such steps.
>
> - Jakub Jelinek did a detailed review of the new futex code and found
> some new races, which Thomas Gleixner fixed.
>
> - to fix a pthread_mutex_trylock() related race, FUTEX_TRYLOCK_PI has
> been added (Thomas Gleixner)
>
> - documentation fixes based on feedback from Tim Bird
>
> - added Documentation/pi-futex.txt (in addition to rt-mutex.txt)
>
> - added the plist debugging patch (which was part of -rt but wasnt part
> of the pi-futex queue before). This caught a couple of SMP bugs in
> the past.
>
> - implemented more scalable held-locks debugging - it's now a per-task
> list of held locks, instead of a global list. This is similarly
> effective to the global list, but much more scalable. (This approach
> will also be added to the stock kernel/mutex.c code.)
>
> - do not fiddle with irq flags in rtmutex.c - it's not needed.
>
> - clone/fork fix: do not let parent's potential PI priority 'leak' into
> child threads or processes.
>
> - added /proc/sys/kernel/max_lock_depth with a default limit of 1024,
> to limit the amount of deadlock-checking the kernel will do.
>
> - small enhancement to the t3-l1-pi-signal.tst testcase.
Wouldn't this be a good opportunity to redefine SCHED_BATCH as 4 instead
of 3 so that you can use ((p->policy & (SCHED_FIFO|SCHED_RR)) == 0)
instead of (p->policy != SCHED_NORMAL && p->policy != SCHED_BATCH)?
That expression will be called fairly frequently and SCHED_BATCH hasn't
been around long enough for a change of value to break very much use
space code.
Peter
--
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
^ permalink raw reply
* Re: kernel config repository
From: Adrian Bunk @ 2006-04-01 0:18 UTC (permalink / raw)
To: Eric Persson; +Cc: Jesper Juhl, linux-kernel
In-Reply-To: <442C4FFC.2040109@persson.tm>
On Thu, Mar 30, 2006 at 11:39:08PM +0200, Eric Persson wrote:
>...
> I have experienced a very tough testing phase to make myself believe and
> thrust a new kernel config, before I put it to live use. I only use HP
> machines, most of them the same model and the difference in hardware are
> usually just disks, memory and speed of cpu, which affects the config
> inself very minmial, otherwise theyre all the same.
> And to hook up and see other HP(replace with any brand/model) users and
> see what configs they use, so all can benefit from config testing, would
> be a great idea, thats what I think at least.
>
> People compiling custom kernels for whatever piece of hardware they can
> find will most likely not benefit, but the overall "community wisdom"
> that this might generate would perhaps everyone benefit from.
Even excluding the case that many computers are more or less unique
combinations of half a dozen different components, everyone will use
different settings for most hardware-independent things like e.g. file
systems, preemption or networking options. Even if I had the same
hardware as you have, my config settings would therefore most likely be
completely different from yours.
> Today, I find it hard find information about all the different configs,
> more than whats in the help function in make menuconfig, but thats me.
> And I think its a waste if good kernel development get ignored since
> people dont know what config options to turn on. ;)
>
> Well, I hope I might inspired or given some clarity on the topic, any
> new input from this?
The help texts for the config options should be enough for an
experienced system administrator to set the right options.
If you know about help texts that could be improved, patches to improve
them are welcome.
> Best regards,
> Eric
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: Avoid excessive time spend on concurrent slab shrinking
From: Andrew Morton @ 2006-04-01 0:14 UTC (permalink / raw)
To: clameter, nickpiggin, linux-mm
In-Reply-To: <20060331160032.6e437226.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> wrote:
>
> A plain old sysrq-T would be great.
>
Really great.
We do potentially-vast gobs of waiting for I/O in
prune_icache->dispose_list->truncate_inode_pages().
But then, why would dispose_list() run truncate_inode_pages()? Reclaiming
an inode which has no links to it, perhaps - it's been a while since I was
in there <wishes he added more comments last time he understood that stuff>
clear_inode() does wait_on_inode()...
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [DNX#2006040142001231] [U-Boot-Users] [PATCH 03/04] Add Flat Dev Tree con [...]
From: Grant Likely @ 2006-04-01 0:13 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1143845420.61660.7048698376@castor.denx.de>
I'm getting an awful lot of traffic from the support system. Do these
messages need to be on the u-boot mailing list?
Thanks,
g.
On 3/31/06, DENX Support System <support@denx.de> wrote:
> Hello list,
>
> inside the automatic U-Boot patch tracking system a new ticket
> [DNX#2006040142001231] was created:
>
> <snip>
> > * Add Flat Dev Tree construction for MPC85xx ADS and CDS boards.
> > Patch by Jon Loeliger 17-Jan-2006
> >
> > Signed-off-by: Jon Loeliger <jdl@freescale.com>
> >
> > ---
> >
> > board/cds/common/ft_board.c | 37 +++++++++
> > board/cds/mpc8541cds/Makefile | 14 +++-
> > board/cds/mpc8541cds/oftree.dts | 137
> > +++++++++++++++++++++++++++++++++++
> > board/cds/mpc8548cds/Makefile | 14 +++-
> > board/cds/mpc8548cds/oftree.dts | 137
> > +++++++++++++++++++++++++++++++++++
> > board/cds/mpc8555cds/Makefile | 14 +++-
> > board/cds/mpc8555cds/oftree.dts | 137
> > +++++++++++++++++++++++++++++++++++
> > board/mpc8540ads/Makefile | 13 +++
> > board/mpc8540ads/mpc8540ads.c | 15 ++++
> > board/mpc8540ads/oftree.dts | 137
> > +++++++++++++++++++++++++++++++++++
> > board/mpc8560ads/Makefile | 12 +++
> > board/mpc8560ads/mpc8560ads.c | 9 ++
> > board/mpc8560ads/oftree.dts | 153
> > +++++++++++++++++++++++++++++++++++++++
> > cpu/mpc85xx/cpu.c | 50 ++++++++++++-
> > cpu/mpc85xx/cpu_init.c | 1
> > include/configs/MPC8540ADS.h | 15 ++++
> > include/configs/MPC8541CDS.h | 12 +++
> > include/configs/MPC8548CDS.h | 12 +++
> > include/configs/MPC8555CDS.h | 12 +++
> > include/configs/MPC8560ADS.h | 12 +++
> > 20 files changed, 932 insertions(+), 11 deletions(-)
> >
> >
> > diff --git a/board/cds/common/ft_board.c b/board/cds/common/ft_board.c
> > new file mode 100644
> > index 0000000..8c4ef0c
> > --- /dev/null
> > +++ b/board/cds/common/ft_board.c
> > @@ -0,0 +1,37 @@
> > +/*
> > + * Copyright 2004 Freescale Semiconductor.
> > + *
> > + * See file CREDITS for list of people who contributed to this
> > + * project.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation; either version 2 of
> > + * the License, or (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program; if not, write to the Free Software
> > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> > + * MA 02111-1307 USA
> > + */
> > +
> > +#include <common.h>
> > +
> > +#if defined(CONFIG_OF_FLAT_TREE)
> > +#include <ft_build.h>
> > +extern void ft_cpu_setup(void *blob, bd_t *bd);
> > +#endif
> > +
> > +
> > +#if defined(CONFIG_OF_FLAT_TREE) && defined(CONFIG_OF_BOARD_SETUP)
> > +void
> > +ft_board_setup(void *blob, bd_t *bd)
> > +{
> > + ft_cpu_setup(blob, bd);
> > +}
> > +#endif
> > diff --git a/board/cds/mpc8541cds/Makefile
> > b/board/cds/mpc8541cds/Makefile
> > index 1161532..34bc410 100644
> > --- a/board/cds/mpc8541cds/Makefile
> > +++ b/board/cds/mpc8541cds/Makefile
> > @@ -28,15 +28,25 @@ LIB = lib$(BOARD).a
> >
> > OBJS := $(BOARD).o \
> > ../common/cadmus.o \
> > - ../common/eeprom.o
> > + ../common/eeprom.o \
> > + ../common/ft_board.o \
> > + oftree.o
> >
> > SOBJS := init.o
> >
> > $(LIB): $(OBJS) $(SOBJS)
> > $(AR) crv $@ $(OBJS)
> >
> > +%.dtb: %.dts
> > + dtc -f -V 0x10 -I dts -O dtb $< >$@
> > +
> </snip>
>
> Your U-Boot support team
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid\x110944&bid$1720&dat\x121642
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 09/15] libata: implement ata_down_xfermask_limit()
From: Tejun Heo @ 2006-04-01 0:11 UTC (permalink / raw)
To: Alan Cox; +Cc: jgarzik, albertcc, linux-ide
In-Reply-To: <1143844292.15646.4.camel@localhost.localdomain>
Alan Cox wrote:
> On Sad, 2006-04-01 at 01:38 +0900, Tejun Heo wrote:
>> Implement ata_down_xfermask_limit(). This function manipulates
>> @dev->pio/mwdma/udma_mask such that the next lower transfer mode is
>> selected. This will be used by ata_bus_probe() rewrite and later by
>> EH speeding down.
>
> This will need care. If it is called during a transfer mode change on
> error we should document that this function will only be called after
> the host_set has been quiesced, otherwise drivers that peek a lot at
> their ap-> mode settings at runtime (eg on an IRQ occuring during a
> speed change down) are going to burned badly.
>
> It would be nice to see a description of the locking model for a
> changedown at this point.
>
For new EH, every driver is responsible to freeze itself whenever it
enters an unknown state. While frozen, a low level driver is required to
either 1. plug interrupt completely from the port or 2. ignore interrupt
from the port without any side effect (ACK and clear interrupts
unconditionally). Once frozen, only reset can thaw the frozen state.
So, if anything which violates HSM occurs, LLDD freezes the port and EH
gets invoked. EH kicks in, resets the port and reconfigure transfer mode
if necessary. The EH revive routine looks pretty much like the new
ata_bus_probe() except that it uses ata_dev_revalidate in place of
ata_dev_read_id().
Thanks.
--
tejun
^ permalink raw reply
* RFC replace some locking of i_sem wiht atomic_t
From: Joshua Hudson @ 2006-04-01 0:08 UTC (permalink / raw)
To: linux-kernel
This might be a way to decrease complexity of locking in vfs.
Basic idea: for local filesystems, i_sem gets taken on several objects
only to protect i_nlink.
These can be removed if i_nlink is atomic.
For network filesystems, no amount of locking would ensure atomic
operations anyway, so
probably no loss there.
inode operations would then lock:
lookup: parent
create: parent
link: both parents
mknod: parent
symlink: parent
mkdir: parent
unlink: parent
rmdir: parent
truncate: item
rename: both parents
A new per-superblock semaphore vfs_link_sem would be created, to be taken
first on both link and rename, dropped as soon as all other locks are taken.
This prevents deadlocks in pathelogical cases. vfs_rename_sem is still needed
(taken after vfs_link_sem) to prevent cycles from being created.
Grabbing the target on link doesn't do much for most filesystems
because the operation
is (or should be) syncronized by the page lock for each directory
pages. If this change
is made, it is possible to remove this locking from all the filesystems.
Note that locking of source or target is no longer necessary. Except
for i_nlink, nothing
can change the source or target anyway.
Comment as you will. I am competent to write this if it is wanted. I
expect however
that I will be flamed to ashes for this suggestion.
^ permalink raw reply
* Re: Avoid excessive time spend on concurrent slab shrinking
From: Andrew Morton @ 2006-04-01 0:00 UTC (permalink / raw)
To: Christoph Lameter; +Cc: nickpiggin, linux-mm
In-Reply-To: <Pine.LNX.4.64.0603311541260.8948@schroedinger.engr.sgi.com>
Christoph Lameter <clameter@sgi.com> wrote:
>
> On Fri, 31 Mar 2006, Andrew Morton wrote:
>
> > > System sluggish in general. cscope takes 20 minutes to start etc. Dropping
> > > the caches restored performance.
> >
> > OK. What sort of system was it, and what was the workload? FIlesystem types?
>
> A build server. Lots of scripts running, compilers etc etc.
Interesting. Many CPUs?
> > It's been like that for an awful long time. Can you think why this has
> > only just now been noticed?
>
> Testing has reached new level of thoroughness because of the new releases
> that are due soon...
>
> > > We just noticed general sluggishness and took some stackdumps to see what
> > > the system was up to.
> >
> > OK. But was it D-state sleep (semaphore lock contention) or what?
>
> Yes, lots of processes waiting on semaphores in
> shrink_slab->shrink_icache_memory. Need to look at this in more detail it
> seems.
Please. Or at least suggest a means-of-reproducing.
A plain old sysrq-T would be great. That'll tell us who owns iprune_sem,
and what he's up to while holding it. Actually five-odd sysrq-T's would be
better.
If the lock holder is stuck on disk I/O or a congested queue or something
then that's very different from the lock holder being in a
pointlessly-burn-CPU-scanning-stuff condition.
> I looked at the old release that worked. Seems that it did the same thing
> in terms of slab shrinking. Concurrent slab shrinking was no problem. So
> you may be right. Its something unrelated to the code in vmscan.c. Maybe
> Nick knows something about this?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [DNX#2006040142001463] [U-Boot-Users] i386 multi_image.
From: DENX Support System @ 2006-04-01 0:00 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001463] was created:
<snip>
> Hi.
>
> I think this is needed to correctly boot multi-part images if you are
> unfortuanate enough to be working on an i386 platform.
>
> -dbu.
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001454] [U-Boot-Users] ft_build.c #include asm/errno.h bre [...]
From: DENX Support System @ 2006-04-01 0:00 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001454] was created:
<snip>
> I updated from git today and building on MIPS is broken like so:
>
> ft_build.c:9:23: asm/errno.h: No such file or directory
> make[1]: *** [.depend] Error 1
> make[1]: Leaving directory `/home/adyer/Projects/u-boot/common'
> make: *** [common/libcommon.a] Error 2
>
> There is currently no include/asm-mips/errno.h (only for ppc and
> arm). I assume this will hit the other archs, too. Copying the
> include/asm-ppc/errno.h file over to asm-mips and changing the
> _PPC_ERRNO_H to _MIPS_ERRNO_H makes the build work.
>
> --
> Hardware, n.:
> The parts of a computer system that can be kicked.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001445] [U-Boot-Users] Patch to show address definition ba [...]
From: DENX Support System @ 2006-04-01 0:00 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001445] was created:
<snip>
>
>
> --- Detlev Zundel <dzu@denx.de> wrote:
>
> > Hi,
> >
> > > at the top level directory:
> > > find . -name "*.[sSch]" -print >cscope.files
> >
> > Why doesn't someone take the time to prepare a patch for a
> > "cscope"
> > target in the Makefile so that "make cscope" does the correct
> > thing?
> > There are already "tags" and "etags" targets by the way...
> >
> > Cheers
> > Detlev
>
> Forgot the target:
>
> cscope: cscope.files
> find . -name "*.[sSch]" -print >cscope.files
>
>
>
>
>
> __________________________________
> Yahoo! Mail - PC Magazine Editors' Choice 2005
> http://mail.yahoo.com
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001436] [U-Boot-Users] [PATCH 1/7] Flat device tree suppor [...]
From: DENX Support System @ 2006-04-01 0:00 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001436] was created:
<snip>
> * Made sure the code which disables prefetch for PCI devices
> sets the size of the prefetch region to 0
> Patch by Andy Fleming on 17-Mar-2006
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
>
> ---
>
> drivers/pci_auto.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> fce2eb3a591a61d9a4a77c027b148d4acaeb3fc2
> diff --git a/drivers/pci_auto.c b/drivers/pci_auto.c
> index 15f7432..8fde330 100644
> --- a/drivers/pci_auto.c
> +++ b/drivers/pci_auto.c
> @@ -186,7 +186,7 @@ static void pciauto_prescan_setup_bridge
> } else {
> /* We don't support prefetchable memory for now, so disable */
> pci_hose_write_config_word(hose, dev, PCI_PREF_MEMORY_BASE, 0x1000);
> - pci_hose_write_config_word(hose, dev, PCI_PREF_MEMORY_LIMIT, 0x1000);
> + pci_hose_write_config_word(hose, dev, PCI_PREF_MEMORY_LIMIT, 0x0);
> }
>
> if (pci_io) {
> --
> 1.2.4
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001427] [U-Boot-Users] Minor patch to 'pxa-regs.h'
From: DENX Support System @ 2006-04-01 0:00 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001427] was created:
<snip>
> Hi Wolfgang,
>
> On 10/21/05, Wolfgang Denk <wd@denx.de> wrote:
> > Only if somebody submits a patch.
>
> Please find patch below..
>
> --- linux-2.6.13.orig/include/asm-arm/arch-pxa/pxa-regs.h 2005-08-29
> 09:11:01.000000000 +0930
> +++ linux-2.6.13/include/asm-arm/arch-pxa/pxa-regs.h 2005-10-18
> 17:16:11.000000000 +0930
> @@ -652,7 +652,7 @@
>
> #define UDCCS_IO_RFS (1 << 0) /* Receive FIFO service */
> #define UDCCS_IO_RPC (1 << 1) /* Receive packet complete */
> -#define UDCCS_IO_ROF (1 << 3) /* Receive overflow */
> +#define UDCCS_IO_ROF (1 << 2) /* Receive overflow */
> #define UDCCS_IO_DME (1 << 3) /* DMA enable */
> #define UDCCS_IO_RNE (1 << 6) /* Receive FIFO not empty */
> #define UDCCS_IO_RSP (1 << 7) /* Receive short packet */
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001392] [U-Boot-Users] Re: Re: Rx-buffer overlow
From: DENX Support System @ 2006-04-01 0:00 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001392] was created:
<snip>
>
> > In message <20060228081735.GA4849@false> you wrote:
> > >=20
> > > fec_recv[249] err: 802
> > > fec_recv[249] err: 2802
> > > fec_recv[249] err: 802
> > >=20
> > > According to the Rx-buffer-status bits, an overlow takes place. So ping
> > > just works if there is less network traffic. But why ? - is the receiv=
> > e
> > > buffer to small, the CPU to slow ?=20
>
> > At which clock frequency are you running your CPU?
>
> the MPC875 is running at 40MHz!
>
> Btw, ethernet just works in 10MB half duplex mode (probably failure in
> hardware). Maybe this is also related to that problem!
>
> U-Boot 1.1.3 (Feb 28 2006 - 09:27:50)
>
> CPU: MPC885ZPnn at 40 MHz [40.0...50.0 MHz]
> 8 kB I-Cache 8 kB D-Cache FEC present
> You made sure it's an ESM this is running on, right?
> DRAM: 64 MB
> FLASH: 16 MB
> In: serial
> Out: serial
> Err: serial
> Net: FEC ETHERNET
>
> > Best regards,
> > Wolfgang Denk
>
> Best regards,
> Josef
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001418] [U-Boot-Users] [PATCH] rename platform Vibren PXA2 [...]
From: DENX Support System @ 2006-04-01 0:00 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001418] was created:
<snip>
> Patch for DevKitIDP PXA255 against pull from cvs 2005-09-27
> - change Platform Vibren PXA255 IDP renamed to DevKitIDP PXA255
> - changed maintainer name
> - modified to use lowlevel_init.S
> - corrected flash memory map values for platform
>
> Thanks, David Plentovich
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001409] [U-Boot-Users] PATCH - Coldfire gcc3.4 compiling f [...]
From: DENX Support System @ 2006-04-01 0:00 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001409] was created:
<snip>
> I have been searching the archives for the solution to this problem when
> compiling u-boot for the M5282EVB with GCC 3.4.0:
>
> /home/jate/tim-firmware/u-boot/cpu/mcf52x2/start.S:345: Fatal error:
> Tried to convert PC relative conditional branch to absolute jump
>
> Turning on the -S option fixes this. This led to this error:
>
> flash.c: In function `flash_print_info':
> flash.c:69: error: label at end of compound statement
>
> This is also fixed below. I do not have an M5282EVB board, so I cannot
> test the binaries generated. Can anyone help test?
>
> - Jate S.
>
> Index: config.mk
> ===================================================================
> RCS file: /cvsroot/u-boot/u-boot/config.mk,v
> retrieving revision 1.14
> diff -u -r1.14 config.mk
> --- config.mk 4 Oct 2005 21:11:34 -0000 1.14
> +++ config.mk 6 Dec 2005 16:57:10 -0000
> @@ -139,7 +139,14 @@
> endif
> endif
>
> +# turn jbsr into jsr for m68k
> +ifeq ($(ARCH),m68k)
> +ifeq ($(findstring 3.4,$(shell $(CC) --version)),3.4)
> +AFLAGS_DEBUG := -Wa,-gstabs,-S
> +endif
> +else
> AFLAGS_DEBUG := -Wa,-gstabs
> +endif
> AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS)
>
> LDFLAGS += -Bstatic -T $(LDSCRIPT) -Ttext $(TEXT_BASE)
> $(PLATFORM_LDFLAGS)
>
> Index: flash.c
> ===================================================================
> RCS file: /cvsroot/u-boot/u-boot/board/m5282evb/flash.c,v
> retrieving revision 1.1
> diff -u -r1.1 flash.c
> --- flash.c 8 Dec 2003 01:34:37 -0000 1.1
> +++ flash.c 6 Dec 2005 16:30:08 -0000
> @@ -65,6 +65,7 @@
> printf ("\n");
>
> Done:
> + ; /* for gcc3.4.0 compiling */
> }
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001383] [U-Boot-Users] [PATCH 6/7] Flat device tree suppor [...]
From: DENX Support System @ 2006-04-01 0:00 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001383] was created:
<snip>
> * Added PCI and I2C support to CDS flat device tree
> * Added VIA configuration table
> * Added support for PCI2 on CDS
> Patch by Andy Fleming 17-Mar-2006
> * Fixed a bug where 8555 PCI code used the old variable and
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
>
> ---
>
> board/cds/common/ft_board.c | 3 +
> board/cds/common/via.c | 99 +++++++++++++++++++++++++++
> board/cds/common/via.h | 18 +++++
> board/cds/mpc8541cds/Makefile | 1
> board/cds/mpc8541cds/init.S | 12 ++-
> board/cds/mpc8541cds/mpc8541cds.c | 32 ++++-----
> board/cds/mpc8541cds/oftree.dts | 99 +++++++++++++++++++++++++--
> board/cds/mpc8548cds/Makefile | 1
> board/cds/mpc8548cds/init.S | 12 ++-
> board/cds/mpc8548cds/mpc8548cds.c | 32 ++++-----
> board/cds/mpc8548cds/oftree.dts | 131
> ++++++++++++++++++++++++++++++++++--
> board/cds/mpc8555cds/Makefile | 1
> board/cds/mpc8555cds/init.S | 12 ++-
> board/cds/mpc8555cds/mpc8555cds.c | 39 ++++++-----
> board/cds/mpc8555cds/oftree.dts | 135
> +++++++++++++++++++++++++++++++++++--
> include/configs/MPC8541CDS.h | 21 ++----
> include/configs/MPC8548CDS.h | 23 ++----
> include/configs/MPC8555CDS.h | 23 ++----
> create mode 100644 board/cds/common/via.c
> create mode 100644 board/cds/common/via.h
>
> 7fa801f3ea1d0fe73a2aec55965aa0cf58a1997a
> diff --git a/board/cds/common/ft_board.c b/board/cds/common/ft_board.c
> index 8c4ef0c..f167e5f 100644
> --- a/board/cds/common/ft_board.c
> +++ b/board/cds/common/ft_board.c
> @@ -32,6 +32,9 @@ extern void ft_cpu_setup(void *blob, bd_
> void
> ft_board_setup(void *blob, bd_t *bd)
> {
> +#ifdef CONFIG_PCI
> + ft_pci_setup(blob, bd);
> +#endif
> ft_cpu_setup(blob, bd);
> }
> #endif
> diff --git a/board/cds/common/via.c b/board/cds/common/via.c
> new file mode 100644
> index 0000000..68c8d21
> --- /dev/null
> +++ b/board/cds/common/via.c
> @@ -0,0 +1,99 @@
> +/*
> + * Copyright 2006 Freescale Semiconductor.
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include <common.h>
> +#include <pci.h>
> +
> +/* Config the VIA chip */
> +void mpc85xx_config_via(struct pci_controller* hose, pci_dev_t dev,
> struct pci_config_table *tab)
> +{
> + pci_dev_t bridge;
> +
> + /* Enable USB and IDE functions */
> + pci_hose_write_config_byte(hose, dev, 0x48, 0x08);
> +
> + pciauto_config_device(hose, dev);
> +
> + /*
> + * Force the backplane P2P bridge to have a window
> + * open from 0x00000000-0x00001fff in PCI I/O space.
> + * This allows legacy I/O (i8259, etc) on the VIA
> + * southbridge to be accessed.
> + */
> + bridge = PCI_BDF(0,17,0);
> + pci_hose_write_config_byte(hose, bridge, PCI_IO_BASE, 0);
> + pci_hose_write_config_word(hose, bridge, PCI_IO_BASE_UPPER16, 0);
> + pci_hose_write_config_byte(hose, bridge, PCI_IO_LIMIT, 0x10);
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001374] [U-Boot-Users] [PATCH] New support for the Xilinx [...]
From: DENX Support System @ 2006-04-01 0:00 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001374] was created:
<snip>
> Attached is a patch and a CHANGELOG entry that adds new support for the
> Xilinx ML310 board.
>
> Please apply to the repository after the "Major overhaul for Xilinx
> ML300 board support" patch and the CM.patch in that same email.
>
> Thanks,
> - Peter
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001365] [U-Boot-Users] [PATCH 4/7] Flat device tree suppor [...]
From: DENX Support System @ 2006-04-01 0:00 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001365] was created:
<snip>
> * Added support for initializing second PCI bus on 85xx
> Patch by Andy Fleming 17-Mar-2006
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
>
> ---
>
> cpu/mpc85xx/pci.c | 182
> ++++++++++++++++++++++++++++++++++--------
> include/asm-ppc/immap_85xx.h | 25 +++++-
>
> 8f02a97700fadd9e37efdc926f69f6d99e74854b
> diff --git a/cpu/mpc85xx/pci.c b/cpu/mpc85xx/pci.c
> index a94493e..ca11bce 100644
> --- a/cpu/mpc85xx/pci.c
> +++ b/cpu/mpc85xx/pci.c
> @@ -32,66 +32,90 @@
>
> #if defined(CONFIG_PCI)
>
> +static struct pci_controller *pci_hose;
> +
> void
> -pci_mpc85xx_init(struct pci_controller *hose)
> +pci_mpc85xx_init(struct pci_controller *board_hose)
> {
> + u16 reg16;
> + u32 dev;
> +
> volatile immap_t *immap = (immap_t *)CFG_CCSRBAR;
> volatile ccsr_pcix_t *pcix = &immap->im_pcix;
> + volatile ccsr_pcix_t *pcix2 = &immap->im_pcix2;
> + volatile ccsr_gur_t *gur = &immap->im_gur;
> + struct pci_controller * hose;
>
> - u16 reg16;
> + pci_hose = board_hose;
> +
> + hose = &pci_hose[0];
>
> hose->first_busno = 0;
> hose->last_busno = 0xff;
>
> - pci_set_region(hose->regions + 0,
> - CFG_PCI1_MEM_BASE,
> - CFG_PCI1_MEM_PHYS,
> - CFG_PCI1_MEM_SIZE,
> - PCI_REGION_MEM);
> -
> - pci_set_region(hose->regions + 1,
> - CFG_PCI1_IO_BASE,
> - CFG_PCI1_IO_PHYS,
> - CFG_PCI1_IO_SIZE,
> - PCI_REGION_IO);
> -
> - hose->region_count = 2;
> -
> pci_setup_indirect(hose,
> (CFG_IMMR+0x8000),
> (CFG_IMMR+0x8004));
>
> + /*
> + * Hose scan.
> + */
> + dev = PCI_BDF(hose->first_busno, 0, 0);
> + pci_hose_read_config_word (hose, dev, PCI_COMMAND, ®16);
> + reg16 |= PCI_COMMAND_SERR | PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY;
> + pci_hose_write_config_word(hose, dev, PCI_COMMAND, reg16);
> +
> + /*
> + * Clear non-reserved bits in status register.
> + */
> + pci_hose_write_config_word(hose, dev, PCI_STATUS, 0xffff);
> +
> + if (!(gur->pordevsr & PORDEVSR_PCI)) {
> + /* PCI-X init */
> + reg16 = PCI_X_CMD_MAX_SPLIT | PCI_X_CMD_MAX_READ
> + | PCI_X_CMD_ERO | PCI_X_CMD_DPERR_E;
> + pci_hose_write_config_word(hose, dev, PCIX_COMMAND, reg16);
> + }
> +
> pcix->potar1 = (CFG_PCI1_MEM_BASE >> 12) & 0x000fffff;
> pcix->potear1 = 0x00000000;
> - pcix->powbar1 = (CFG_PCI1_MEM_BASE >> 12) & 0x000fffff;
> + pcix->powbar1 = (CFG_PCI1_MEM_PHYS >> 12) & 0x000fffff;
> pcix->powbear1 = 0x00000000;
> - pcix->powar1 = 0x8004401c; /* 512M MEM space */
> + pcix->powar1 = (POWAR_EN | POWAR_MEM_READ |
> + POWAR_MEM_WRITE | POWAR_MEM_512M);
>
> - pcix->potar2 = 0x00000000;
> + pcix->potar2 = (CFG_PCI1_IO_BASE >> 12) & 0x000fffff;
> pcix->potear2 = 0x00000000;
> - pcix->powbar2 = (CFG_PCI1_IO_BASE >> 12) & 0x000fffff;
> + pcix->powbar2 = (CFG_PCI1_IO_PHYS >> 12) & 0x000fffff;
> pcix->powbear2 = 0x00000000;
> - pcix->powar2 = 0x80088017; /* 16M IO space */
> + pcix->powar2 = (POWAR_EN | POWAR_IO_READ |
> + POWAR_IO_WRITE | POWAR_IO_1M);
>
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001356] [U-Boot-Users] [PATCH] Remove warnings & clean bet [...]
From: DENX Support System @ 2006-04-01 0:00 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001356] was created:
<snip>
> On Tue, Nov 01, 2005 at 11:13:18AM -0000, Peter Pearse wrote:
> > The attached gzipped file contains my patch number 014 against the GIT
> > head of
> > Nov 1st 22005.
> >
> > This patch depends on all my outstanding previous patches 009 - 013.
> >
> > It removes some warnings, and adds to the clean target.
> >
> > diff --git a/Makefile b/Makefile
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1819,6 +1819,7 @@ clean:
> > rm -f board/cray/L1/bootscript.c board/cray/L1/bootscript.image
> > rm -f board/trab/trab_fkt board/voiceblue/eeprom
> > rm -f board/integratorap/u-boot.lds board/integratorcp/u-boot.lds
> > + rm -f board/integratorap/u-boot.lds board/realview_eb/u-boot.lds
>
> Why are you removing board/integratorap/u-boot.lds twice?
>
> > find include/configs -lname \*integratorap\* | xargs rm -fr
> > find include/configs -lname \*integratorcp\* | xargs rm -fr
> > find include/configs -lname \*versatile\* | xargs rm -fr
>
> Best regards,
> ladis
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001347] [U-Boot-Users] [PATCH] Fixing 'pci' command output [...]
From: DENX Support System @ 2006-04-01 0:00 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001347] was created:
<snip>
> hi!
>
> currently a series of 'pci_bus_to_hose() failed' messages are printed
> when
> pciinfo() is called with a invalid (out-of-bounds) bus number.
>
> this patch fixes the output of the 'pci' command by
> *) checking that the given bus number is actually a number
> *) checking that the given bus number is not out-of-bounds before doing
> a
> scan
> *) printing 'pci_bus_to_hose() failed' only when DEBUG is defined
>
>
> Signed-off-by: Horst Kronstorfer <hkronsto <at> frequentis.com>
>
> CHANGELOG
>
> * Fixing 'pci' command output:
> Patch by Horst Kronstorfer, 26 Jan 2006
>
> diff --git a/common/cmd_pci.c b/common/cmd_pci.c
> index 4508546..e0e166c 100644
> --- a/common/cmd_pci.c
> +++ b/common/cmd_pci.c
> @@ -71,6 +71,11 @@ void pciinfo(int BusNum, int ShortPCILis
> unsigned short VendorID;
> pci_dev_t dev;
>
> + if (pci_bus_to_hose(BusNum) == NULL) {
> + printf("Error: bus no. %d does not exist\n", BusNum);
> + return;
> + }
> +
> printf("Scanning PCI devices on bus %d\n", BusNum);
>
> if (ShortPCIListing) {
> @@ -511,9 +516,17 @@ int do_pci (cmd_tbl_t *cmdtp, int flag,
> if (argv[argc-1][0] == 'l') {
> value = 0;
> argc--;
> + } else if (argv[argc-1][0] == 's')
> + argc--;
> + if (argc > 1) {
> + char *endp;
> + bdf = simple_strtoul(argv[1], &endp,
> 16);
> + if (*endp != '\0') {
> + printf("Error: \`%s\' is not a
> valid
> "
> + "bus no.\n", argv[1]);
> + return 0;
> + }
> }
> - if (argc > 1)
> - bdf = simple_strtoul(argv[1], NULL, 16);
> }
> pciinfo(bdf, value);
> return 0;
> diff --git a/drivers/pci.c b/drivers/pci.c
> index 5360030..34b4055 100644
> --- a/drivers/pci.c
> +++ b/drivers/pci.c
> @@ -142,7 +142,7 @@ struct pci_controller *pci_bus_to_hose (
> if (bus >= hose->first_busno && bus <= hose->last_busno)
> return hose;
>
> - printf("pci_bus_to_hose() failed\n");
> + debug("pci_bus_to_hose() failed\n");
> return NULL;
> }
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001338] [U-Boot-Users] [PATCH]Fix cc-option macro in confi [...]
From: DENX Support System @ 2006-04-01 0:00 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001338] was created:
<snip>
> Paolo Broggini wrote:
> >
> > The following patch fix the compilation problem discussed in thread
> > "Problem building U-Boot for ARM target"
> >
> > Best regards
> > -P.Broggini
>
> Bump & resubmit...
>
> This particular issue broke cross-compilation for all of our ARM-based
> projects following a repository sync yesterday.
>
> The attached patch was generated against a 2005.11.29 CVS pull.
>
> CHANGELOG:
> * Patch by Cory Tusar, 30 Nov 2005:
> * Original patch by Paolo Broggini, 12 Oct 2005:
> Fix cc-option macro in config.mk, $(CFLAGS) dropped.
>
> -Cory
>
>
> --
> Cory T. Tusar
> Embedded Systems Engineer
> Videon Central, Inc.
> 2171 Sandy Drive
> State College, PA 16801
> (814) 235-1111 x316
> (814) 235-1118 fax
>
> "Debugging is twice as hard as writing the code in the first place.
> Therefore, if you write the code as cleverly as possible, you are,
> by definition, not smart enough to debug it." --Brian W. Kernighan
</snip>
Your U-Boot support team
^ permalink raw reply
* [DNX#2006040142001329] [U-Boot-Users] [PATCH] FAT32 access on USB memory [...]
From: DENX Support System @ 2006-04-01 0:00 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142001329] was created:
<snip>
> Hi,
>
> I have had following problem with ARM9 CPUs NS9360, NS9750, S3C2410 and
> S3C2440:
>
> Using fatload command with 2GB USB memory stick lead to data abort and
> reset of CPU.
>
> The reason herefor is, that the access to the variable fatbuf produces
> an alignment error, if FAT32 is used.
>
> Attached patch moves the variable fatbuf to top of the structure, where
> it is defined, so that accesses to this variable are always aligned.
>
> CHANGELOG:
> Fix access via fatload command on FAT32 formatted partitions
> Patch by Joachim Jaeger, 18 Nov 2005
>
> Signed-off-by: Joachim Jaeger <joachim_jaeger@digi.com>
>
>
> Best regards
> Joachim Jaeger
>
> --
> FS FORTH-SYSTEME GmbH
> A Digi International Company
> Kueferstr. 8, D-79206 Breisach
> Phone: +49 (7667) 908-0, FAX +49 (7667) 908-200
</snip>
Your U-Boot support team
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.