* Re: [U-Boot-Users] Re: FT u-boot shim
From: Pantelis Antoniou @ 2006-04-27 21:25 UTC (permalink / raw)
To: u-boot-users; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <44512C25.2080105@smiths-aerospace.com>
On Thursday 27 April 2006 23:40, Jerry Van Baren wrote:
> Wolfgang Denk wrote:
> > In message <44511C88.1010107@smiths-aerospace.com> you wrote:
> >> A thought that keeps recurring (but I've suppressed because I don't have
> >> time to play...) is that it would be Really Cool[tm] to store the u-boot
> >> env variables in a flat tree and then pass the env/tree to linux. It
> >
> > If somebody wants to read the environment variables, you don't need
> > to create a flat tree from it.
>
> Understood. That is why it is Really Cool[tm] rather than Really
> Useful[tm] ;-)
>
> > Also, it doesn't solve the original problem as most of the informa-
> > tion you need to pass is NOT part of the environment (and shall not
> > become such a part).
> >
> > Best regards,
> > Wolfgang Denk
>
> I agree and disagree with the parenthetical part of your statement.
> Agree because it _wouldn't_ be a part of u-boot (technically it would be
> if someone put it in their default env for their specific board, but why
> would denx.de care?).
>
> Disagree because, while u-boot needs/uses some env variables,
> engineers/companies/end users are free to add variables and, I dare say,
> most do. If a given board needs to pass certain non u-boot parameters
> to linux, it would simply add that to its env (which already happens).
>
> I'm not sure you (Wolfgang and Kumar) are following my thought fully (or
> my ignorance is showing to everybody but me). The thought is to change
> the native format of the u-boot environment storage from the
> key-string/value-string pairs to the flat tree (OpenFirmware) format
> which still supports the same key-string/value-string capability (but
> can do more than that).
>
> The advantage, as I see it, is that it would be unifying and thus easier
> to maintain the common variables (call it the GRand Unifying Flat Tree
> (GRAFT) ;-). One language (flat tree), no shims, equivalent key/value
> utility (but a different underlying storage format), no visible
> difference for the users (but potentially an upgrade challenge for
> existing boards and env variables).
>
> The disadvantage is that it would be disruptive to u-boot and may cause
> some bloating and discomfort.
>
> gvb
> (the naive)
>
> P.S. For the non-USA readers: "may cause some bloating and discomfort"
> is a standard disclaimer on medicines advertised on TV over here.
>
Since I'm the guy responsible let me weigh in a bit.
For starters, yes it's possible to pass the whole env using the FT tree.
Use CONFIG_OF_HAS_UBOOT_ENV to pass the u-boot env to the FT tree.
As for the rest of the cat-fight, I'm afraid I don't have the energy
to jump in at the moment.
Perhaps tomorrow :)
Regards
Pantelis
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Mark A. Greer @ 2006-04-27 21:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1145594285.28014.12.camel@localhost.localdomain>
On Fri, Apr 21, 2006 at 02:38:05PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2006-04-20 at 14:55 -0700, Eugene Surovegin wrote:
> > On Thu, Apr 20, 2006 at 11:10:55PM +0200, Gerhard Pircher wrote:
> > > Well, Freescale's PPC programming environment manual clearly states that
> > > this will not work on G4 CPUs (74xx). Also Benjamin Herrenschmidt told me,
> > > that this implementation will not work for the reasons I mentioned before.
> > > The approach I'm trying to implement was his idea, so I have to trust in
> > > him.
> >
> > Well, you aren't the first person who tries to run G4 with
> > CONFIG_NOT_COHERENT_CACHE. This was done before and I don't remember
> > that those people had to implement anything as complex as you are
> > trying to do.
> >
> > You can try asking on #mklinux. It always better to ask people who
> > actually _did_ this :).
> >
> > In fact, I just grepped 2.6 and found
> > #ifdef(CONFIG_NOT_COHERENT_CACHE) in syslib/mv64x60.c. Guess what
> > systems usually have this type of bridge? Not 4xx/8xx, that's for sure.
>
> I think some folks tried ... and failed.
Who has tried and failed?
There are many mv64x60 based platforms working just fine today with
CONFIG_NOT_COHERENT_CACHE defined. The reason for turning coherency off
is that there is a bug in the bridge requiring a hardware workaround.
Unfortunately, not all of the hardware vendors have implemented that
workaround and I know of one that considers it infeasible and will
not implement it.
I expect that the pegasos has that hardware workaround implemented so
the kernel maintainers for that platform have the good fortune of being
able to run with coherency on.
What Ben says is correct, there is that issue. However, AFAIK, I have
not yet to run into it.
If that hardware workaround is not implemented, the options are:
a) 100% chance of a system hang with coherency on
or
b) < 0.0..1% chance of a system hang with coherency off (at least in my
experience to far).
The choice is simple.
Mark
^ permalink raw reply
* Re: FT u-boot shim
From: Wolfgang Denk @ 2006-04-27 21:34 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, U-Boot Users
In-Reply-To: <9F5CC364-8FC8-48BA-8D12-E524815B6537@kernel.crashing.org>
In message <9F5CC364-8FC8-48BA-8D12-E524815B6537@kernel.crashing.org> you wrote:
>
> Hmm, I guess. There really isn't anything about the device tree that
> is Linux specific. Other OSes could choice to use it. But lets
I guess there are VxWorks BSP's for most of the boards we are talking
about, right? Do they use the device tree? I would be *very*
surprised.
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
Microsoft Multimedia:
You have nice graphics, sound and animations when the system crashes.
^ permalink raw reply
* Re: FT u-boot shim
From: Wolfgang Denk @ 2006-04-27 21:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, U-Boot Users
In-Reply-To: <7BC50BA2-D657-4907-94AA-DB5926F22504@kernel.crashing.org>
In message <7BC50BA2-D657-4907-94AA-DB5926F22504@kernel.crashing.org> you wrote:
>
> > NEW: bootm <kernel_addr> - <dts_addr>
> > or bootm <kernel_addr> <ramdisk_addr> <dts_addr>
>
> do you mean a literal '-' char for the no ramdisk, but dts case?
Yes. We could write "bootm <kernel_addr> NULL <dts_addr>" or "bootm
<kernel_addr> none <dts_addr>" or anythingl ike that as well, but I'm
a lazy typist :-)
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
"...this does not mean that some of us should not want, in a rather
dispassionate sort of way, to put a bullet through csh's head."
- Larry Wall in <1992Aug6.221512.5963@netlabs.com>
^ permalink raw reply
* Re: [PATCH 01/16] ehca: integration in Linux kernel build system
From: Heiko J Schick @ 2006-04-27 21:26 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel, openib-general
In-Reply-To: <200604271307.36987.arnd.bergmann@de.ibm.com>
On 2006-04-27 13:07:36 +0200, Arnd Bergmann <arnd.bergmann@de.ibm.com> said:
> It would be more practical to put this patch last instead of
> first so you don't break the build system with partial applies.
I agree. I Will change set for the next patchset.
^ permalink raw reply
* Re: [PATCH 06/16] ehca: common include files
From: Heiko J Schick @ 2006-04-27 21:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel, openib-general
In-Reply-To: <200604271319.06844.arnd.bergmann@de.ibm.com>
On 2006-04-27 13:19:06 +0200, Arnd Bergmann <arnd.bergmann@de.ibm.com> said:
> Well, you should also remove this for submission, I guess ;-)
Yeah, I've planed to remove this lines when 2.6.17 official came out.
It is still included because we don't want to introduce unnecessary
dependencies.
I will remove it for the next patchset.
Regards,
Heiko
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Benjamin Herrenschmidt @ 2006-04-27 21:53 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <20060427213134.GA12572@mag.az.mvista.com>
> There are many mv64x60 based platforms working just fine today with
> CONFIG_NOT_COHERENT_CACHE defined. The reason for turning coherency off
> is that there is a bug in the bridge requiring a hardware workaround.
> Unfortunately, not all of the hardware vendors have implemented that
> workaround and I know of one that considers it infeasible and will
> not implement it.
Define "working fine" ... With the current implementation, and according
to the spec, it will randomly crap out or checkstop due to the same page
beging accessed via the NCU and being in the L2 unless you disabled
speculative loads and made sure it can't prefetch accross page
boundaries maybe ? Or set the G bit all over the BAT mapping (ouch !).
> I expect that the pegasos has that hardware workaround implemented so
> the kernel maintainers for that platform have the good fortune of being
> able to run with coherency on.
I suppose so...
> What Ben says is correct, there is that issue. However, AFAIK, I have
> not yet to run into it.
Hrm... well, I wouldn't rely on that tho.
> If that hardware workaround is not implemented, the options are:
> a) 100% chance of a system hang with coherency on
> or
> b) < 0.0..1% chance of a system hang with coherency off (at least in my
> experience to far).
>
> The choice is simple.
I disagree. A solution that is known to have a hole in it is no good
even if you haven't managed to trigger it so far. Now it's Gerhard's
choice.
Ben.
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Mark A. Greer @ 2006-04-27 22:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1146174809.30710.14.camel@localhost.localdomain>
On Fri, Apr 28, 2006 at 07:53:29AM +1000, Benjamin Herrenschmidt wrote:
>
> > There are many mv64x60 based platforms working just fine today with
> > CONFIG_NOT_COHERENT_CACHE defined. The reason for turning coherency off
> > is that there is a bug in the bridge requiring a hardware workaround.
> > Unfortunately, not all of the hardware vendors have implemented that
> > workaround and I know of one that considers it infeasible and will
> > not implement it.
>
> Define "working fine" ... With the current implementation, and according
> to the spec, it will randomly crap out or checkstop due to the same page
> beging accessed via the NCU and being in the L2 unless you disabled
> speculative loads and made sure it can't prefetch accross page
> boundaries maybe ? Or set the G bit all over the BAT mapping (ouch !).
"working fine" == running in a production environment for
weeks/months without crapping out.
> > If that hardware workaround is not implemented, the options are:
> > a) 100% chance of a system hang with coherency on
> > or
> > b) < 0.0..1% chance of a system hang with coherency off (at least in my
> > experience to far).
> >
> > The choice is simple.
>
> I disagree. A solution that is known to have a hole in it is no good
> even if you haven't managed to trigger it so far. Now it's Gerhard's
> choice.
TBH, I haven't really looked at what Gerhard is doing yet so I can't
comment. No matter what, though, its certainly his choice.
Mark
^ permalink raw reply
* Re: [U-Boot-Users] Re: FT u-boot shim
From: Tolunay Orkun @ 2006-04-27 21:55 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev@ozlabs.org list, U-Boot Users
In-Reply-To: <20060427194055.3EED1353A57@atlas.denx.de>
Wolfgang Denk wrote:
> In message <D358E665-60E4-48C0-82FD-7A1C16DAF00C@kernel.crashing.org> you wrote:
>> The problem is that there are somethings that u-boot knows that needs
>> to go into the blob (memory size, boot args, initrd info,
>> frequencies, etc.)
>
> Yes. Can we append auch variable data to the fixed part of the dts?
>
>> How would we distinguish the bootm command that takes a blob versus
>> the ones we have today?
>
> Arg count. For example:
>
> OLD: bootm <kernel_addr>
> or bootm <kernel_addr> <ramdisk_addr>
>
> NEW: bootm <kernel_addr> - <dts_addr>
> or bootm <kernel_addr> <ramdisk_addr> <dts_addr>
How would you like to handle the case when dts is packed into
multi-image file? Is bootm going to assume that the 3rd Image is dts?
Since dts is tightly coupled to kernel I would prefer something like:
bootm <kernel_addr>[:<dts_addr>] <ramdisk_addr>
Best regards,
Tolunay
^ permalink raw reply
* Re: [PATCH 04/16] ehca: userspace support
From: Michael Ellerman @ 2006-04-27 22:36 UTC (permalink / raw)
To: Jörn Engel
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <20060427114355.GB32127@wohnheim.fh-wedel.de>
[-- Attachment #1: Type: text/plain, Size: 709 bytes --]
On Thu, 2006-04-27 at 13:43 +0200, Jörn Engel wrote:
> More minors.
>
> On Thu, 27 April 2006 12:48:22 +0200, Heiko J Schick wrote:
> > +
> > + EDEB_EN(7,
> > + "vm_start=%lx vm_end=%lx vm_page_prot=%lx vm_fileoff=%lx "
> > + "address=%lx",
> > + vma->vm_start, vma->vm_end, vma->vm_page_prot, fileoffset,
> > + address);
>
> Gesundheit! Seriously, I suspect "EDEB_EN" is not the best possible
> name to pick.
Try pr_debug() in include/linux/kernel.h
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH 13/16] ehca: firmware InfiniBand interface
From: Paul Mackerras @ 2006-04-27 22:42 UTC (permalink / raw)
To: Jörn Engel
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <20060427123701.GG32127@wohnheim.fh-wedel.de>
J=F6rn Engel writes:
> 25 parameters=3F If you tell me which drugs were involved in this co=
de,
> I know what to stay away from.
You really need to ask the firmware architects that, since this is
basically a single firmware call.
Mind you, since a lot of the parameters are used to return individual
bytes or half-words, which are then put into structures, it might be
better to pass the pointers to the structures and let the wrapper put
the values straight into the structures.
Paul.
^ permalink raw reply
* Re: do_mmap_pgoff issue...
From: Paul Mackerras @ 2006-04-27 22:47 UTC (permalink / raw)
To: Gerhard Jaeger; +Cc: linuxppc-dev
In-Reply-To: <200604271559.19818.g.jaeger@sysgo.com>
Gerhard Jaeger writes:
> The facts:
> - mmap the last page @ 0xFFFFF000, len 4K
> - result: mmap says EOVERFLOW...
> - the function that failed was do_mmap_pgoff()
>
> Here's the pice of code
>
> /* offset overflow? */
> if ((pgoff + (len >> PAGE_SHIFT)) < pgoff)
> return -EOVERFLOW;
>
> It's quite clear why it fails in my case:
> pgoff + (len >> PAGE_SHIFT) will be 0
No, pgoff will be 0xfffff, len will be 1, the sum is 0x100000. You
need to look elsewhere for the problem.
Paul.
^ permalink raw reply
* Re: [PATCH 10/16] ehca: event queue
From: Segher Boessenkool @ 2006-04-27 22:55 UTC (permalink / raw)
To: Jörn Engel
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <20060427114828.GC32127@wohnheim.fh-wedel.de>
>> + if (ret != H_SUCCESS) {
>
> Common convention is to return 0 on success and -ESOMETHING on eror.
> You might want to follow that and remove H_SUCCESS from the complete
> code.
This return code doesn't come from anywhere within the kernel, though.
If we change this, we should get rid of _every_ #define bladibla 0
Do we want that? (I do ;-) )
>> + if (!(vpage = ipz_qpageit_get_inc(&eq->ipz_queue))) {
>
> I personally despise assignments in conditionals. Not sure if this is
> documented in CodingStyle, but IME most kernel hackers tend to dislike
> it as well.
In this case it's obvious; put it on a separate line.
Segher
^ permalink raw reply
* Re: [PATCH 06/16] ehca: common include files
From: Kyle Moffett @ 2006-04-28 5:11 UTC (permalink / raw)
To: Heiko J Schick
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <4450A183.6030405@de.ibm.com>
On Apr 27, 2006, at 06:48:35, Heiko J Schick wrote:
> +#define EHCA_EDEB_TRACE_MASK_SIZE 32
> +extern u8 ehca_edeb_mask[EHCA_EDEB_TRACE_MASK_SIZE];
> +#define EDEB_ID_TO_U32(str4) (str4[3] | (str4[2] << 8) | (str4[1]
> << 16) | \
> + (str4[0] << 24))
> +
> +inline static u64 ehca_edeb_filter(const u32 level,
> + const u32 id, const u32 line)
> +{
> + u64 ret = 0;
> + u32 filenr = 0;
> + u32 filter_level = 9;
> + u32 dynamic_level = 0;
> +
> + /* This is code written for the gcc -O2 optimizer which should
> colapse
> + * to two single ints filter_level is the first level kicked out by
> + * compiler means trace everythin below 6. */
> + if (id == EDEB_ID_TO_U32("ehav")) {
> + filenr = 0x01;
> + filter_level = 8;
> + }
> [...]
This whole mess should be a simpler with a table and a loop
struct edeb_filter_entry {
u32 filenr;
u32 filter_level;
};
# define EDEB_FILTER_ENTRY(name,nr,level) { .id = name, .filenr =
nr, .filter_level = level }
static const struct edeb_filter_entry edeb_filter_table[] = {
EDEB_FILTER_ENTRY("clas", 0x02, 8),
[...]
};
Then just iterate over that table in a loop. The end result is much
smaller code and data, and much clearer as to intent as well.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: [openib-general] Re: [PATCH 04/16] ehca: userspace support
From: Heiko J Schick @ 2006-04-28 6:11 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder, Jörn Engel
In-Reply-To: <1146177388.19236.1.camel@localhost.localdomain>
Hello Michael,
On 28.04.2006, at 00:36, Michael Ellerman wrote:
> Try pr_debug() in include/linux/kernel.h
The problem I see with pr_debug() is that it could only activated via
a compile flag. To use the debug outputs you have to re-compile /
compile
your own kernel.
Regards,
Heiko
^ permalink raw reply
* Re: [openib-general] Re: [PATCH 04/16] ehca: userspace support
From: Pekka Enberg @ 2006-04-28 6:32 UTC (permalink / raw)
To: Heiko J Schick
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder, Jörn Engel
In-Reply-To: <6C4A3B96-4752-4FF9-8FBE-C383B00AE014@schihei.de>
Hi Heiko,
On 4/28/06, Heiko J Schick <info@schihei.de> wrote:
> The problem I see with pr_debug() is that it could only activated via
> a compile flag. To use the debug outputs you have to re-compile /
> compile your own kernel.
Do you really need this heavy debug logging in the first place? You
can use kprobes for arbitrary run-time inspection anyway, so logging
everything seems wasteful.
Pekka
^ permalink raw reply
* [PATCH] yaboot: enable boot from iscsi target via ethernet devices on js20.
From: Doug Maxey @ 2006-04-28 6:05 UTC (permalink / raw)
To: yaboot-devel; +Cc: Linux PowerPC List, Doug Maxey
Certain levels of JS20 firmware will allow the system to boot from an
iscsi target. System OFW accomplishes this by setting up a virtual
disk device with parameters. These parameters, when passed back to
OFW by yaboot, directs the FW to use virtual device over the ethernet
port that will then access iscsi target as a block device. This patch
extracts those parameters from the property of the virtual device and
passes them back to OFW to indicate the kernel is to be retrieved via
the iscsi protocol.
Signed-off-by: Doug Maxey <dwm@austin.ibm.com>
---
Makefile | 2 +-
include/errors.h | 1 +
include/prom.h | 1 +
second/file.c | 47 +++++++++++++++++++++++++++++++++++++++++------
second/prom.c | 3 +++
second/yaboot.c | 6 +++---
ybin/ybin | 2 +-
7 files changed, 51 insertions(+), 11 deletions(-)
5ad3702f0585f73834f8c66b78091184a125c2d2
diff --git a/Makefile b/Makefile
index 39f8633..72ec680 100644
--- a/Makefile
+++ b/Makefile
@@ -2,7 +2,7 @@ ## Setup
include Config
-VERSION = 1.3.13
+VERSION = 1.3.14rc1-iscsi
# Debug mode (spam/verbose)
DEBUG = 0
# make install vars
diff --git a/include/errors.h b/include/errors.h
index dfe7e5f..e994dd5 100644
--- a/include/errors.h
+++ b/include/errors.h
@@ -38,3 +38,4 @@ #define FILE_ERR_BADDEV -12
/* Device kind */
#define FILE_DEVICE_BLOCK 1
#define FILE_DEVICE_NET 2
+#define FILE_DEVICE_ISCSI 3
diff --git a/include/prom.h b/include/prom.h
index 9700803..194b927 100644
--- a/include/prom.h
+++ b/include/prom.h
@@ -34,6 +34,7 @@ typedef void *ihandle;
typedef void *phandle;
#define PROM_INVALID_HANDLE ((prom_handle)-1UL)
+#define BOOTDEVSZ (2048) /* iscsi args can be in excess of 1040 bytes */
struct prom_args;
typedef int (*prom_entry)(struct prom_args *);
diff --git a/second/file.c b/second/file.c
index 0e58286..0ab3623 100644
--- a/second/file.c
+++ b/second/file.c
@@ -1,6 +1,9 @@
/*
* file.c - Filesystem related interfaces
*
+ * Copyright (C) IBM Corporation, 2006
+ * Doug Maxey <dwm@austin.ibm.com>
+ *
* Copyright (C) 2001, 2002 Ethan Benson
*
* parse_device_path()
@@ -36,7 +39,7 @@ #include "fs.h"
#include "errors.h"
#include "debug.h"
-extern char bootdevice[1024];
+extern char bootdevice[];
static char *netdev_path_to_filename(const char *path)
{
@@ -177,7 +180,7 @@ parse_device_path(char *imagepath, char
char *ptr;
char *ipath = NULL;
char *defdev = NULL;
- int device_kind;
+ int device_kind = -1;
result->dev = NULL;
result->part = -1;
@@ -185,16 +188,45 @@ parse_device_path(char *imagepath, char
if (!imagepath)
return 0;
+
+ /*
+ * Do preliminary checking for an iscsi device; it may appear as
+ * pure a network device (device_type == "network") if this is
+ * ISWI. This is the case on IBM systems doing an iscsi OFW
+ * boot.
+ */
+ if (strstr(imagepath, ",iscsi")) {
+ /*
+ * get the virtual device information from the
+ * "nas-bootdevice" property.
+ */
+ if (! prom_get_chosen("nas-bootdevice", bootdevice, BOOTDEVSZ)) {
+ DEBUG_F("reset boot-device to"
+ " /chosen/nas-bootdevice = %s\n", bootdevice);
+ device_kind = FILE_DEVICE_ISCSI;
+ ipath = strdup(bootdevice);
+ if (!ipath)
+ return 0;
+ }
+ else
+ return 0;
+ }
else if (!(ipath = strdup(imagepath)))
return 0;
if (defdevice) {
defdev = strdup(defdevice);
device_kind = prom_get_devtype(defdev);
- } else
+ } else if (device_kind == -1)
device_kind = prom_get_devtype(ipath);
- if (device_kind != FILE_DEVICE_NET && strchr(defdev, ':') != NULL) {
+ /*
+ * When an iscsi iqn is present, it may have embedded colons, so
+ * don't parse off anything.
+ */
+ if (device_kind != FILE_DEVICE_NET &&
+ device_kind != FILE_DEVICE_ISCSI &&
+ strchr(defdev, ':') != NULL) {
if ((ptr = strrchr(defdev, ':')) != NULL)
*ptr = 0; /* remove trailing : from defdevice if necessary */
}
@@ -202,7 +234,9 @@ parse_device_path(char *imagepath, char
/* This will not properly handle an obp-tftp argument list
* with elements after the filename; that is handled below.
*/
- if (device_kind != FILE_DEVICE_NET && strchr(ipath, ':') != NULL) {
+ if (device_kind != FILE_DEVICE_NET &&
+ device_kind != FILE_DEVICE_ISCSI &&
+ strchr(ipath, ':') != NULL) {
if ((ptr = strrchr(ipath, ',')) != NULL) {
char *colon = strrchr(ipath, ':');
/* If a ':' occurs *after* a ',', then we assume that there is
@@ -223,7 +257,8 @@ parse_device_path(char *imagepath, char
if (!defdev)
result->dev = netdev_path_to_dev(ipath);
- } else if ((ptr = strchr(ipath, ':')) != NULL) {
+ } else if (device_kind != FILE_DEVICE_ISCSI &&
+ (ptr = strrchr(ipath, ':')) != NULL) {
*ptr = 0;
result->dev = strdup(ipath);
if (*(ptr+1))
diff --git a/second/prom.c b/second/prom.c
index 5ec06b8..9bc5415 100644
--- a/second/prom.c
+++ b/second/prom.c
@@ -174,6 +174,9 @@ prom_get_devtype (char *device)
int result;
char tmp[64];
+ if (strstr(device, ",iscsi"))
+ device = strcpy(tmp, "/vdevice/gscsi/disk");
+
/* Find OF device phandle */
dev = prom_finddevice(device);
if (dev == PROM_INVALID_HANDLE) {
diff --git a/second/yaboot.c b/second/yaboot.c
index d7a3a20..bf10b01 100644
--- a/second/yaboot.c
+++ b/second/yaboot.c
@@ -111,7 +111,7 @@ static void setup_display(void);
/* Locals & globals */
int useconf = 0;
-char bootdevice[1024];
+char bootdevice[BOOTDEVSZ];
char *password = NULL;
struct boot_fspec_t boot;
int _machine = _MACH_Pmac;
@@ -1474,10 +1474,10 @@ yaboot_main(void)
if (_machine == _MACH_Pmac)
setup_display();
- prom_get_chosen("bootpath", bootdevice, sizeof(bootdevice));
+ prom_get_chosen("bootpath", bootdevice, BOOTDEVSZ);
DEBUG_F("/chosen/bootpath = %s\n", bootdevice);
if (bootdevice[0] == 0) {
- prom_get_options("boot-device", bootdevice, sizeof(bootdevice));
+ prom_get_options("boot-device", bootdevice, BOOTDEVSZ);
DEBUG_F("boot-device = %s\n", bootdevice);
}
if (bootdevice[0] == 0) {
diff --git a/ybin/ybin b/ybin/ybin
index 210711f..224b50e 100755
--- a/ybin/ybin
+++ b/ybin/ybin
@@ -29,7 +29,7 @@ fi
PRG="${0##*/}"
ABSPRG="$0"
SIGINT="$PRG: Interrupt caught ... exiting"
-VERSION=1.3.13
+VERSION=1.3.14rc1-iscsi
DEBUG=0
VERBOSE=0
TMP="${TMPDIR:-/tmp}"
--
1.3.0
^ permalink raw reply related
* Re: [Fastboot] [PATCH] Reserve crashkernel memory region
From: Michael Neuling @ 2006-04-28 7:06 UTC (permalink / raw)
To: mohan; +Cc: fastboot, linuxppc-dev
In-Reply-To: <20060424061015.GA31320@in.ibm.com>
> Now kexec'ed kernel in a PPC64 machine does not reserve memory for
> crashkernel region. So kexec'ed kernel can not load kdump kernel
> reliably.
Owww 3 boots... scary :-)
> Attached kexec-tools patch reserves memory for kdump kernel by adding
> an entry in the reserve memory table. So while kexec'ed kernel is
> booting, it reserves memory for crashkernel region.
This logic is duplicated in prom_init.c.
It'd be cool if the kernel parsed the command line early on (after
prom_init.c) and did the memory reserves there. Then we wouldn't need
this logic in both the kexec tools and prom_init.c.
Mikey
^ permalink raw reply
* Re: [openib-general] Re: [PATCH 04/16] ehca: userspace support
From: Michael Ellerman @ 2006-04-28 7:11 UTC (permalink / raw)
To: Pekka Enberg
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder, Jörn Engel
In-Reply-To: <84144f020604272332s6101032cy6936096230f3637c@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 924 bytes --]
On Fri, 2006-04-28 at 09:32 +0300, Pekka Enberg wrote:
> Hi Heiko,
>
> On 4/28/06, Heiko J Schick <info@schihei.de> wrote:
> > The problem I see with pr_debug() is that it could only activated via
> > a compile flag. To use the debug outputs you have to re-compile /
> > compile your own kernel.
>
> Do you really need this heavy debug logging in the first place? You
> can use kprobes for arbitrary run-time inspection anyway, so logging
> everything seems wasteful.
Yeah, I really don't think you want to be running with that kind of
debugging gunk in a production kernel. Is someone who can't build their
own kernel really going to be able to make sense of the output?
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH] Wire up *at syscalls
From: Paul Mackerras @ 2006-04-28 7:31 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1145924011.16166.465.camel@shinybook.infradead.org>
David Woodhouse writes:
> Hm, do we really need that? How about something based on this instead...
> note that I used CONFIG_PPC_CELL because dependencies on CONFIG_*_MODULE
> in the static kernel are evil.
Nice idea, but you didn't change the syscall entry path to multiply
the syscall number by 24 instead of 16. It would be nice to have a
way to do something like that but generate two separate tables instead
of a single table with 3 entries per syscall.
Paul.
^ permalink raw reply
* Re: 2.6.17-rc2-mm1
From: Andrew Morton @ 2006-04-28 8:20 UTC (permalink / raw)
To: Martin Bligh; +Cc: linuxppc64-dev, linux-kernel
In-Reply-To: <4450F5AD.9030200@google.com>
(I did s/linux-kernel@google.com/linux-kernel@vger.kernel.org/)
Martin Bligh <mbligh@google.com> wrote:
>
> Still crashes in LTP on x86_64:
> (introduced in previous release)
>
> http://test.kernel.org/abat/29674/debug/console.log
What a mess. A doublefault inside an NMI watchdog timeout. I think. It's
hard to see. Some CPUs are stuck on a CPU scheduler lock, others seem to
be stuck in flush_tlb_others. One of these could be a consequence of the
other, or both could be a consequence of something else.
> Different panic on 2-way ppp64 blade, again during LTP.
>
> http://test.kernel.org/abat/29675/debug/console.log
>
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=128 NUMA
> Modules linked in: evdev joydev st sr_mod ipv6 usbcore sg dm_mod
> NIP: C000000000048F0C LR: C0000000000AF854 CTR: 800000000000A984
> REGS: c0000000074af560 TRAP: 0300 Not tainted (2.6.17-rc2-mm1-autokern1)
> MSR: 8000000000001032 <ME,IR,DR> CR: 24002024 XER: 00000010
> DAR: C00001800056B0B0, DSISR: 0000000040010000
> TASK = c000000007460800[84] 'kswapd0' THREAD: c0000000074ac000 CPU: 1
> GPR00: 8000000000001032 C0000000074AF7E0 C000000000691420 C0000000007586A8
> GPR04: 000000000000000F 0000000000000000 0000000000000000 0000000000000000
> GPR08: C0000000FE80AAD8 C00001800056B080 0000000000000001 C0000000007586A8
> GPR12: 0000000024002024 C00000000056B280 0000000000000020 0000000000000020
> GPR16: 0000000000000020 0000000000000000 0000000000000000 000000000000000F
> GPR20: C0000000074AF860 0000000000000000 C0000000FFFF3098 0000000000000001
> GPR24: C0000000074AFE00 C00000000059FCC0 0000000000000001 C0000000007586A8
> GPR28: C000000000545680 0000000000000022 C0000000005A4DA8 C00000000056B080
> NIP [C000000000048F0C] .try_to_wake_up+0x98/0x598
> LR [C0000000000AF854] .add_to_swapped_list+0x23c/0x264
> Call Trace:
> [C0000000074AF7E0] [C0000000005A4DA8] 0xc0000000005a4da8 (unreliable)
> [C0000000074AF8F0] [C0000000000AF854] .add_to_swapped_list+0x23c/0x264
> [C0000000074AF990] [C000000000098290] .remove_mapping+0x88/0x174
> [C0000000074AFA20] [C000000000099340] .shrink_zone+0xc74/0xf9c
> [C0000000074AFD30] [C00000000009A008] .kswapd+0x3e4/0x54c
> [C0000000074AFED0] [C0000000000705C8] .kthread+0x174/0x1c4
> [C0000000074AFF90] [C000000000024AB0] .kernel_thread+0x4c/0x68
> Instruction dump:
> 3a810080 7d2000a6 79208042 f9340000 78008000 7c010164 e97b0008 ebfe8008
> eb9e8000 812b0010 79294da4 7d29fa14 <e8090030> 7fbc0214 7fa3eb78 4841f615
> -- 0:conmux-control -- time-stamp -- Apr/27/06 5:10:48 --
Well that's silly. kswapd died trying to wake up kprefetchd. That code's
bog-simple, so I'd assume something's gone wrong with a CPU scheduler data
structure. So if there's a common strand here, it's breakage of sched data
structures by mtest01. Let me see if I can provoke it here.
^ permalink raw reply
* patches for 2.6.18
From: Paul Mackerras @ 2006-04-28 10:17 UTC (permalink / raw)
To: linuxppc-dev
If you have patches that aren't 2.6.17 material, but you would like to
see them in 2.6.18, now is the time to be posting them to the list, so
that I can put them in the powerpc.git tree, and they can get some
testing before 2.6.17 comes out. Please don't wait for the 2-week
merge window to send them. That 2-week merge window is the window for
me to send stuff to Linus, not the window for you to send stuff to me.
Paul.
^ permalink raw reply
* Re: [PATCH] Wire up *at syscalls
From: David Woodhouse @ 2006-04-28 10:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17489.50396.320494.589703@cargo.ozlabs.ibm.com>
On Fri, 2006-04-28 at 17:31 +1000, Paul Mackerras wrote:
> Nice idea, but you didn't change the syscall entry path to multiply
> the syscall number by 24 instead of 16.
Indeed. Neither did I wire up the spu callbacks. It wasn't meant to be
applied as-is.
> It would be nice to have a way to do something like that but generate
> two separate tables instead of a single table with 3 entries per
> syscall.
Arnd apparently tried that once and it was icky. Perhaps we could do
something like this though...
.macro SPU adr
.section .spu_callbacks,"a"
.llong \adr
.previous
.endm
--
dwmw2
^ permalink raw reply
* Re: alignment exceptionhandler sleeps in invalid context
From: Paul Mackerras @ 2006-04-28 11:02 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060424173246.GA22318@suse.de>
Olaf Hering writes:
> I'm not sure where the bug is. Does it mean the network stack does
> something nasty, or is the exception handler itself broken? (probably the latter)
> This is 2.6.16.9 on a p270.
This patch should fix it, I hope. If you can verify that it fixes it
I'll send it to Linus.
Paul.
diff --git a/include/asm-powerpc/uaccess.h b/include/asm-powerpc/uaccess.h
index 3872e92..b02d858 100644
--- a/include/asm-powerpc/uaccess.h
+++ b/include/asm-powerpc/uaccess.h
@@ -179,7 +179,8 @@ do { \
#define __put_user_nocheck(x, ptr, size) \
({ \
long __pu_err; \
- might_sleep(); \
+ if ((unsigned long)ptr < PAGE_OFFSET) \
+ might_sleep(); \
__chk_user_ptr(ptr); \
__put_user_size((x), (ptr), (size), __pu_err); \
__pu_err; \
@@ -259,7 +260,8 @@ ({ \
long __gu_err; \
unsigned long __gu_val; \
__chk_user_ptr(ptr); \
- might_sleep(); \
+ if ((unsigned long)ptr < PAGE_OFFSET) \
+ might_sleep(); \
__get_user_size(__gu_val, (ptr), (size), __gu_err); \
(x) = (__typeof__(*(ptr)))__gu_val; \
__gu_err; \
@@ -271,7 +273,8 @@ ({ \
long __gu_err; \
long long __gu_val; \
__chk_user_ptr(ptr); \
- might_sleep(); \
+ if ((unsigned long)ptr < PAGE_OFFSET) \
+ might_sleep(); \
__get_user_size(__gu_val, (ptr), (size), __gu_err); \
(x) = (__typeof__(*(ptr)))__gu_val; \
__gu_err; \
^ permalink raw reply related
* Re: alignment exceptionhandler sleeps in invalid context
From: Olaf Hering @ 2006-04-28 11:19 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17489.63055.968862.256370@cargo.ozlabs.ibm.com>
On Fri, Apr 28, Paul Mackeras wrote:
> Olaf Hering writes:
>
> > I'm not sure where the bug is. Does it mean the network stack does
> > something nasty, or is the exception handler itself broken? (probably the latter)
> > This is 2.6.16.9 on a p270.
>
> This patch should fix it, I hope. If you can verify that it fixes it
> I'll send it to Linus.
I dont have a testcase, it just happend once on the p270.
^ 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