This commit removed probe_superio from v2. It has not been referenced as svn:externals, so none of the v2 and v3 trees have probe_superio or superiotool. As of revision 2762, the v2 repository is still BROKEN and superiotool doesn't appear in v3 either (checked revision 486).
Such commits are one reason why I think self-acked commits should not be allowed.
Carl-Daniel
On 01.09.2007 21:44, svn@openbios.org wrote:
Author: uwe Date: 2007-09-01 21:44:36 +0200 (Sat, 01 Sep 2007) New Revision: 2758
Added: trunk/util/superiotool/ Removed: trunk/LinuxBIOSv2/util/probe_superio/ Log: Move probe_superio into the global util/ directory. Rename it to superiotool while we're at it.
Signed-off-by: Uwe Hermann uwe@hermann-uwe.de Acked-by: Uwe Hermann uwe@hermann-uwe.de
Copied: trunk/util/superiotool (from rev 2757, trunk/LinuxBIOSv2/util/probe_superio)
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [070903 20:36]:
This commit removed probe_superio from v2. It has not been referenced as svn:externals, so none of the v2 and v3 trees have probe_superio or superiotool. As of revision 2762, the v2 repository is still BROKEN and superiotool doesn't appear in v3 either (checked revision 486).
Such commits are one reason why I think self-acked commits should not be allowed.
Well. Half-hearted code reviews are an illusion of safety, too.
The current code's lar handling is pretty much broken even though that code was reviewed, but obviously nobody even tested it:
Wrote LinuxBIOS table at: 0x00000500 - 0x00000a54 checksum 401f Show all devs... cpus: Unknown device path type: 0 Stage2 code done. LAR: Attempting to open 'normal/payload'. LAR: Attempting to open 'normal/payload/segment0'. LAR: load_file: No such file 'normal/payload/segment0'
It just hangs somewhere bogus and never gets to the defined error in
arch/x86/stage1.c:194: die("FATAL: No usable payload found.\n");
also the current code contains quite some warnings again regarding int-to-pointer casts in lar.c and pointer-to-int cast and uninitialized variable use in stage1.c
Stefan
Hi,
As of revision 2762, the v2 repository is still BROKEN and superiotool doesn't appear in v3 either (checked revision 486).
Such commits are one reason why I think self-acked commits should not be allowed.
Well. Half-hearted code reviews are an illusion of safety, too.
The current code's lar handling is pretty much broken even though that code was reviewed, but obviously nobody even tested it:
Wrote LinuxBIOS table at: 0x00000500 - 0x00000a54 checksum 401f Show all devs... cpus: Unknown device path type: 0 Stage2 code done. LAR: Attempting to open 'normal/payload'. LAR: Attempting to open 'normal/payload/segment0'. LAR: load_file: No such file 'normal/payload/segment0'
It just hangs somewhere bogus and never gets to the defined error in
arch/x86/stage1.c:194: die("FATAL: No usable payload found.\n");
also the current code contains quite some warnings again regarding int-to-pointer casts in lar.c and pointer-to-int cast and uninitialized variable use in stage1.c
run_address gets called with entry=0.
Attached patch fixes it.
(If thread hi-jacking is forbidden, sorry)
-- Alex
* Alex Beregszaszi alex@rtfs.hu [070905 02:09]:
LAR: Attempting to open 'normal/payload'. LAR: Attempting to open 'normal/payload/segment0'. LAR: load_file: No such file 'normal/payload/segment0'
run_address gets called with entry=0.
Attached patch fixes it.
r491.
On 9/4/07, Alex Beregszaszi alex@rtfs.hu wrote:
The current code's lar handling is pretty much broken even though that code was reviewed, but obviously nobody even tested it:
I did test it before each commit, with a full rebuild. This is a case where testing can miss a bug.
(Alex, I know you did not write that, I lost track who wrote it).
also the current code contains quite some warnings again regarding int-to-pointer casts in lar.c and pointer-to-int cast and uninitialized variable use in stage1.c
let's fix it.
ron
On 05.09.2007 01:52, Stefan Reinauer wrote:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [070903 20:36]:
This commit removed probe_superio from v2. It has not been referenced as svn:externals, so none of the v2 and v3 trees have probe_superio or superiotool. As of revision 2762, the v2 repository is still BROKEN and superiotool doesn't appear in v3 either (checked revision 486).
Such commits are one reason why I think self-acked commits should not be allowed.
Well. Half-hearted code reviews are an illusion of safety, too.
Yes.
The current code's lar handling is pretty much broken even though that code was reviewed, but obviously nobody even tested it:
It seems I tested without a payload. Apologies.
Wrote LinuxBIOS table at: 0x00000500 - 0x00000a54 checksum 401f Show all devs... cpus: Unknown device path type: 0 Stage2 code done. LAR: Attempting to open 'normal/payload'. LAR: Attempting to open 'normal/payload/segment0'. LAR: load_file: No such file 'normal/payload/segment0'
It just hangs somewhere bogus and never gets to the defined error in
arch/x86/stage1.c:194: die("FATAL: No usable payload found.\n");
also the current code contains quite some warnings again regarding int-to-pointer casts in lar.c and pointer-to-int cast and uninitialized variable use in stage1.c
Which gcc? I seem to have trouble getting my gcc to warn about anything on i386. "gcc (GCC) 4.1.0 (SUSE Linux)". On my other machine, I get a few warnings:
/sources/LinuxBIOSv3/lib/lar.c: In function ‘find_file’: /sources/LinuxBIOSv3/lib/lar.c:110: warning: cast to pointer from integer of different size /sources/LinuxBIOSv3/lib/lar.c:111: warning: cast to pointer from integer of different size
resulting from this code:
result->entry = (void *)ntohl(header->entry); result->loadaddress = (void *)ntohl(header->loadaddress);
Because we switched these lar header entries to u64 and struct mem_file uses void * for the related entries, we are stuck. There are two ways out of this problem:
struct mem_file { void *start; int len; u32 reallen; u32 compression; u64 entry; u64 loadaddress; };
But that means we can't use ->entry and ->loadaddress as pointers anymore. Sucks.
Or explicitly check if any of the upper 32 bits are set and if not, convert to void *. That "solution" breaks as soon as we want to make use of 64 bits. Sucks even more.
So I fear we have to go for the first route and work with PAE once we have an entry above 32 bits.
/sources/LinuxBIOSv3/arch/x86/stage1.c: In function ‘legacy’: /sources/LinuxBIOSv3/arch/x86/stage1.c:66: warning: ‘result.reallen’ is used uninitialized in this function
resulting from this code:
ret = elfboot_mem(mem, where, result.reallen);
Not a problem right now because elfboot_mem doesn't use its third parameter. But Ron might want to fix this in a future commit.
/sources/LinuxBIOSv3/arch/x86/stage1.c: In function ‘stage1_main’: /sources/LinuxBIOSv3/arch/x86/stage1.c:185: warning: passing argument 1 of ‘printk’ makes integer from pointer without a cast
printk prefix was forgotten. Alex Beregszaszi has already sent a patch for that: "[PATCH] stage1 multi-segment lar bug"
Carl-Daniel
On Wed, Sep 05, 2007 at 02:37:56AM +0200, Carl-Daniel Hailfinger wrote:
Wrote LinuxBIOS table at: 0x00000500 - 0x00000a54 checksum 401f Show all devs... cpus: Unknown device path type: 0 Stage2 code done. LAR: Attempting to open 'normal/payload'. LAR: Attempting to open 'normal/payload/segment0'. LAR: load_file: No such file 'normal/payload/segment0'
It just hangs somewhere bogus and never gets to the defined error in
arch/x86/stage1.c:194: die("FATAL: No usable payload found.\n");
also the current code contains quite some warnings again regarding int-to-pointer casts in lar.c and pointer-to-int cast and uninitialized variable use in stage1.c
Which gcc? I seem to have trouble getting my gcc to warn about anything on i386. "gcc (GCC) 4.1.0 (SUSE Linux)". On my other machine, I get a few warnings:
Hm, I don't see any warnings either at the moment (r495), neither on i386 nor on amd64, but maybe they were fixed inbetween; I'll have to catch up with all the recent patches...
Uwe.
Hi,
On Fri, 2007-09-07 at 21:01 +0200, Uwe Hermann wrote:
On Wed, Sep 05, 2007 at 02:37:56AM +0200, Carl-Daniel Hailfinger wrote:
Wrote LinuxBIOS table at: 0x00000500 - 0x00000a54 checksum 401f Show all devs... cpus: Unknown device path type: 0 Stage2 code done. LAR: Attempting to open 'normal/payload'. LAR: Attempting to open 'normal/payload/segment0'. LAR: load_file: No such file 'normal/payload/segment0'
It just hangs somewhere bogus and never gets to the defined error in
arch/x86/stage1.c:194: die("FATAL: No usable payload found.\n");
also the current code contains quite some warnings again regarding int-to-pointer casts in lar.c and pointer-to-int cast and uninitialized variable use in stage1.c
Which gcc? I seem to have trouble getting my gcc to warn about anything on i386. "gcc (GCC) 4.1.0 (SUSE Linux)". On my other machine, I get a few warnings:
Hm, I don't see any warnings either at the moment (r495), neither on i386 nor on amd64, but maybe they were fixed inbetween; I'll have to catch up with all the recent patches...
Fixed with r488.
-- Alex
On Mon, Sep 03, 2007 at 08:36:59PM +0200, Carl-Daniel Hailfinger wrote:
This commit removed probe_superio from v2. It has not been referenced as svn:externals, so none of the v2 and v3 trees have probe_superio or superiotool.
Yes, and that was by design. I don't think we _really_ need them in either of the repositories (v2 or v3), you can easily get the tool via
svn co svn://linuxbios.org/repos/trunk/util/superiotool
But it seems several people prefer to have it in both repos, so why not... It's in v2 and v3 now via svn:externals.
As of revision 2762, the v2 repository is still BROKEN and superiotool doesn't appear in v3 either (checked revision 486).
It's not broken, I guess you had local modifications thus the v2 directory ended up crappy. A fresh checkout has no problems at all.
Uwe.
On 07.09.2007 21:19, Uwe Hermann wrote:
On Mon, Sep 03, 2007 at 08:36:59PM +0200, Carl-Daniel Hailfinger wrote:
This commit removed probe_superio from v2. It has not been referenced as svn:externals, so none of the v2 and v3 trees have probe_superio or superiotool.
Yes, and that was by design. I don't think we _really_ need them in either of the repositories (v2 or v3), you can easily get the tool via
svn co svn://linuxbios.org/repos/trunk/util/superiotool
But it seems several people prefer to have it in both repos, so why not... It's in v2 and v3 now via svn:externals.
As of revision 2762, the v2 repository is still BROKEN and superiotool doesn't appear in v3 either (checked revision 486).
It's not broken, I guess you had local modifications thus the v2 directory ended up crappy. A fresh checkout has no problems at all.
A fresh checkout of 2762 in an empty directory was empty as well, that's why I complained. Anyway, this seems to be resolved right now.
Carl-Daniel
-
Alex Beregszaszi -
Carl-Daniel Hailfinger -
ron minnich -
Stefan Reinauer -
Uwe Hermann