Thread: Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.
Brought to you by:
marty_connor,
stefanhajnoczi
Menu
▾
▴
etherboot-developers
|
From: <ke...@us...> - 2002-08-25 10:10:49
|
>The fun part. With nic and network drivers compiled in I had >etherboot booting itself over the network, then unplugged my nic >cable and instantly booted from my IDE disk. So the boot order code >now works. Is it time for me to release another testing tarball, Eric? |
|
From: <ke...@us...> - 2002-08-26 00:38:54
|
>> Is it time for me to release another testing tarball, Eric? > >It couldn't hurt. This is certainly one of those stable >points. Ok, testers can find it in http://www.etherboot.org/etherboot-5.1.2rc3.tar.bz2 |
|
From: Timothy L. <tl...@ro...> - 2002-08-27 01:54:55
|
Hi No time for extensive testing, but just a couple of things. I get an error: segment [00092800,00094000) does not fit in any memory region I am assuming that this is because the ltsp kernel is not tagged with the correct version of mknbi. Is that correct? Also, on my old 486, the 3c515 driver with isa_pnp defined stops at: .000041.0000 done R I will try another card (3c509) in that PC and I will try the 3c515 in another PC when I get a chance. Tim > -----Original Message----- > From: eth...@li... > [mailto:eth...@li...]On Behalf Of > Ken Yap > Sent: Sunday, August 25, 2002 9:38 PM > To: Etherboot developers list > Subject: Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk. > > > >> Is it time for me to release another testing tarball, Eric? > > > >It couldn't hurt. This is certainly one of those stable > >points. > > Ok, testers can find it in > http://www.etherboot.org/etherboot-5.1.2rc3.tar.bz2 ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ Etherboot-developers mailing list Eth...@li... https://lists.sourceforge.net/lists/listinfo/etherboot-developers |
|
From: <ke...@us...> - 2002-08-27 02:31:38
|
>No time for extensive testing, but just a couple of things. I get an error: > >segment [00092800,00094000) does not fit in any memory region > >I am assuming that this is because the ltsp kernel is not tagged with the >correct version of mknbi. Is that correct? No, it ought to be legal. >Also, on my old 486, the 3c515 driver with isa_pnp defined stops at: > >.000041.0000 done >R > >I will try another card (3c509) in that PC and I will try the 3c515 in >another PC when I get a chance. If the same thing happens too it's the entry point at loader.S:6. It used to copy the body to RELOCADDR for execution. Haven't looked at the new code to see what happens now. |
|
From: Eric W B. <ebi...@ln...> - 2002-08-27 04:28:17
|
ke...@us... (Ken Yap) writes: > >No time for extensive testing, but just a couple of things. I get an error: > > > >segment [00092800,00094000) does not fit in any memory region > > > >I am assuming that this is because the ltsp kernel is not tagged with the > >correct version of mknbi. Is that correct? > > No, it ought to be legal. The warning happens now because we check, (only the ELF code used to). But etherboot should get out of the way. I would have to see some more boot messages to see where etherboot is living. Possibly this is because I don't define RELOCATE by default because the drivers need to be looked at. Still I would have though etherboot would have loaded much loader than that by default. Which rom image did you build? > >Also, on my old 486, the 3c515 driver with isa_pnp defined stops at: > > > >.000041.0000 done > >R > > > >I will try another card (3c509) in that PC and I will try the 3c515 in > >another PC when I get a chance. > > If the same thing happens too it's the entry point at loader.S:6. It > used to copy the body to RELOCADDR for execution. Haven't looked at the > new code to see what happens now. It still does though the decompressor can put it some place else. I moved RELOCADDR down a ways so we could build larger images. Eric |
|
From: <ke...@us...> - 2002-08-27 07:02:25
|
>Also, on my old 486, the 3c515 driver with isa_pnp defined stops at: > >.000041.0000 done >R > >I will try another card (3c509) in that PC and I will try the 3c515 in >another PC when I get a chance. I got a bit further than you. I'm using a 3c509. I got my Etherboot ROM to load another ROM image and that worked, the 5.1.2rc3 image started executing, and prompted me for N or L. I chose N and it said Probing pci, no BIOS32\n Probing isa...[3c5x9] blah blah, and then froze after printing the MAC address. |
|
From: <ke...@us...> - 2002-08-27 07:16:02
|
>I got a bit further than you. I'm using a 3c509. I got my Etherboot ROM >to load another ROM image and that worked, the 5.1.2rc3 image started >executing, and prompted me for N or L. I chose N and it said Probing >pci, no BIOS32\n Probing isa...[3c5x9] blah blah, and then froze after >printing the MAC address. Oh and the 3 second timeout didn't work so the PCBIOS timer is probably not working. That may be the same reason for the freeze actually. |
|
From: <ebi...@ln...> - 2002-08-27 08:00:15
|
ke...@us... (Ken Yap) writes: > >I got a bit further than you. I'm using a 3c509. I got my Etherboot ROM > >to load another ROM image and that worked, the 5.1.2rc3 image started > >executing, and prompted me for N or L. I chose N and it said Probing > >pci, no BIOS32\n Probing isa...[3c5x9] blah blah, and then froze after > >printing the MAC address. > > Oh and the 3 second timeout didn't work so the PCBIOS timer is probably > not working. That may be the same reason for the freeze actually. Hmm? 3 second timeout. Was it a compressed rom image? At the moment I would only expect non-compressed images which still run at RELOCADDR to work reliably. The compressed case relies on being relocatable, and decompreses from RELOCADDR to a little further down. Eric |
|
From: <ebi...@ln...> - 2002-08-27 08:40:49
|
ebi...@ln... (Eric W. Biederman) writes: > ke...@us... (Ken Yap) writes: > > > >I got a bit further than you. I'm using a 3c509. I got my Etherboot ROM > > >to load another ROM image and that worked, the 5.1.2rc3 image started > > >executing, and prompted me for N or L. I chose N and it said Probing > > >pci, no BIOS32\n Probing isa...[3c5x9] blah blah, and then froze after > > >printing the MAC address. > > > > Oh and the 3 second timeout didn't work so the PCBIOS timer is probably > > not working. That may be the same reason for the freeze actually. > > Hmm? 3 second timeout. Eric the ASK_BOOT=3 timeout. I usually set it to 1, and forgot the default was 3. So the BIOS based currticks is running at the wrong speed, interesting. Given that you chose N I assume it was running slow? O.k. A slow timer would certain give a freeze. Sounds like I made a small bug in pcbios.S Looking at the code.... O.k. The BIOS based currticks is definitely bugging in the presence of relocation. The absolute BIOS addresses are not fixed up, so if any amount of relocation is applied the will read the wrong address. Please, Please, Please when testing the new etherboot tell me if what image you are testing. And if you can test the non relocated case. I suspect there will be a bazillion little bugs when etherboot is running relocated that is going to take a while to track down. That is the big hunt before 5.2. Anyway I believe the untested patch below should fix the timer problem. Eric /************************************************************************** CURRTICKS - Get Time Use direct memory access to BIOS variables, longword 0040:006C (ticks today) and byte 0040:0070 (midnight crossover flag) instead of calling timeofday BIOS interrupt. **************************************************************************/ .globl currticks currticks: pushl %ebp pushl %ebx pushl %esi pushl %edi #ifdef FREEBSD_PXEEMU cmpb $0, pxeemu_nbp_active jne currticks_postswitch #endif pushl $ 10f pushl $ 20f - 10f call _real_call .section ".text16" 10: .code16 ret 20: .code32 .previous #ifdef FREEBSD_PXEEMU currticks_postswitch: #endif - movl 0x46C, %eax - movb 0x470, %bl + movl virt_offset, %ebp + negl %ebp /* Physical address 0 */ + movl 0x46C(%ebp), %eax + movb 0x470(%ebp), %bl cmpb $0, %bl je notmidnite - movb $0, 0x470 /* clear the flag */ + movb $0, 0x470(%ebp) /* clear the flag */ addl $0x1800b0,days /* 0x1800b0 ticks per day */ notmidnite: addl days,%eax popl %edi popl %esi popl %ebx popl %ebp ret |
|
From: <ke...@us...> - 2002-08-27 08:42:26
|
>Was it a compressed rom image? Yes. >At the moment I would only expect non-compressed images which still >run at RELOCADDR to work reliably. The compressed case relies on >being relocatable, and decompreses from RELOCADDR to a little further >down. Ok, a .rom image works, but unfortunately it can't load the NFL menu which uses 0x20000 also. Which would also be a problem for zImage kernels. I thought you were going to relocate Etherboot to the top of the 32-bit address space? |
|
From: <ebi...@ln...> - 2002-08-27 09:11:47
|
ke...@us... (Ken Yap) writes: > >Was it a compressed rom image? > > Yes. > > >At the moment I would only expect non-compressed images which still > >run at RELOCADDR to work reliably. The compressed case relies on > >being relocatable, and decompreses from RELOCADDR to a little further > >down. > > Ok, a .rom image works, but unfortunately it can't load the NFL menu > which uses 0x20000 also. Which would also be a problem for zImage > kernels. I thought you were going to relocate Etherboot to the top of > the 32-bit address space? Right the code is there to do that but it takes a while to weed out the dependencies on code that uses absolute addresses. 0x20000 is just the initial load address. If you specify -DRELOCATE etherboot will relocate itself up to the top of memory. I have just left the default set so people can build drivers and then see if there are relocation fixes that must be handled. Relocation fixes. Mostly it is a matter of adding: virt_to_bus, bus_to_virt, and ioremap in the drivers. In some of the other code calling phys_to_virt, and virt_to_phys are appropriate. For the most part the pointers just need to be fixed up and the code will work. Straight forward but work that needs to be done a small piece at a time. We should probably compile a list of drivers that have not yet been converted to work when relocated. Then walk through fixing and testing them. I'd like to add the ability to test multicast at the same time so my next generic step will be to get the multicast sever going. Then I can convert as many drivers as possible, but I don't have a lot of the hardware so there are a lot of cases I can't test. If you can think of a better way to handle it. I am all ears. Eric |
|
From: Ronald G M. <rmi...@la...> - 2002-08-27 09:30:26
|
FYI, Erik hendriks (here) just REMOVED multicast support from his beoboot code. There were just enough problems with switches etc. that in the end he decided it was a net loss performance-wise. This may or may not affect what you want to do with multicast. ron |
|
From: Eric W B. <ebi...@ln...> - 2002-08-27 16:36:35
|
Ronald G Minnich <rmi...@la...> writes: > FYI, Erik hendriks (here) just REMOVED multicast support from his beoboot > code. There were just enough problems with switches etc. that in the end > he decided it was a net loss performance-wise. > > This may or may not affect what you want to do with multicast. We have to uses a full install, and booting. For booting except on a large system it isn't very significant as the files are generally small. For booting you start to notice a scalability limit somewhere around 200+ nodes, at which point you need another server, patience or multicast support. For a full install multicast is very helpful. For the MCR FSU (96 nodes) we can do a full install on all of the nodes in something like twice the time it takes to do a full install on 1 node. So about 10 minutes. And I expect the numbers will hang in somewhere around there for the whole cluster. Right now, getting work arounds for all of the hardware defects, and LinuxBIOS bugs is the priority so we can reboot the FSU and have the majority of the nodes come back up. Eric |
|
From: Eric W B. <ebi...@ln...> - 2002-08-27 19:32:50
|
Ronald G Minnich <rmi...@la...> writes: > FYI, Erik hendriks (here) just REMOVED multicast support from his beoboot > code. There were just enough problems with switches etc. that in the end > he decided it was a net loss performance-wise. > > This may or may not affect what you want to do with multicast. Hmm. I hadn't realized this was on the list. A little more general answer then. For most drivers opening up the nic level filter to accept multicast packets is about 2 or 3 lines of code. So it is worth writing the code, and setting the precedent even if multicast booting does not prove a general purpose win. Except for those 2 or 3 lines there is no overhead for a multicast capable etherboot if you don't compile in the support. As for how worthwhile the project is. I coded the support after watching the unicast traffic for booting several hundred computers simultaneously be a human visble bottleneck. Taking something like 15minutes and with atftp-0.3 showing up in top. Beyond that we will be running a full scale test on MCR a 1000 node cluster, in a couple of weeks, and I can give a report on how useful it is. So far all I have heard is, that it works and is boring. I don't plan to reevaluate that until To date I have not encoutered any fatal switch problems, and requesting that switches that work on a large cluster where it is needed is not a real problem. When I use multicast I would be perfectly happy to use broadcast, the multicast is just a hint to the hardware to not send the packets to everyone. Finally what was Erik doing that made multicast support less performant than unicast? Did he have a bad retransmission algorithm? Even in the case the switch drops 50% of the packets, if you have 3 receivers for the same data you have gained performance. Unless the multicast traffic is jamming up your network between nodes doing other things, in which case multicast is quite definitely not the tool for the job. Eric |
|
From: Ronald G M. <rmi...@la...> - 2002-08-27 21:20:32
|
I basically agree with you, I like multicast ... I think one reason was that myrinet does not do it well :-) ron |
|
From: <ke...@us...> - 2002-08-27 09:25:26
|
>O.k. The BIOS based currticks is definitely bugging in the >presence of relocation. The absolute BIOS addresses are not >fixed up, so if any amount of relocation is applied the will >read the wrong address. Ok, that fix works, thanks. And the .lzrom version has no problem with loading to 0x20000. The 3c509 is a nice card to start with as it only uses I/O instructions. There is a small glitch though. After the second bootloader runs, sometimes it's unable to find the NIC the next time around and has to wait for a full reset. Slightly related, but in main.c there's a static int card_retries = 0 which will not be reset by a longjmp. Probably needs to be made non-static and (re)set to 0 during initialisation. |
|
From: Eric W B. <ebi...@ln...> - 2002-08-27 18:17:39
|
ke...@us... (Ken Yap) writes: > >O.k. The BIOS based currticks is definitely bugging in the > >presence of relocation. The absolute BIOS addresses are not > >fixed up, so if any amount of relocation is applied the will > >read the wrong address. > > Ok, that fix works, thanks. Welcome, then I will get that change committed. > And the .lzrom version has no problem with loading to 0x20000. You might want to try the .nrv2brom variant as well. I probably should just totally switch so we don't have an excess of compressors, something else to do before 5.2. > The 3c509 is a nice card to start with as it only uses I/O instructions. O.k. So the 3c509 is done. Cool. > There is a small glitch though. After the second > bootloader runs, sometimes it's unable to find the NIC the next time > around and has to wait for a full reset. Ouch. I wonder what causes that. I'm pretty certain the init path didn't change. > Slightly related, but in main.c there's a static int card_retries = 0 > which will not be reset by a longjmp. Probably needs to be made > non-static and (re)set to 0 during initialisation. Probably correct. That piece hasn't changed since 5.0. Basically all it does is give an increasingly longer timeout every time it is hit, so it shouldn't be a correctness problem. Eric |
|
From: Eric W B. <ebi...@ln...> - 2002-08-27 17:52:28
|
"Timothy Legge" <tl...@ro...> writes: > Hi > > > Which rom image did you build? > > I built both the 3c515 and the 3c509. This morning I verified that neither > the 3c515 or the 3c509 driver gets past: > > .000041.0000 done > R Compressed? or Uncompressed. That message does not seem at all familiar, so if you could give some more boot context. Console dump from a serial port perhaps, it would really help. > on my old 486. I will have to pull the 3c515 and toss it in the Pentium PC > (the one that reported the error: > > segment [00092800,00094000) does not fit in any memory region Again I don't have enough context to do anything with just that message. But it would have take a fairly large image to make that work. Eric |
|
From: Timothy L. <tl...@ro...> - 2002-08-27 23:27:20
|
What I did: cd etherboot-5.0/src make bin32/3c509.fd0 make bin32/3c509.rom mknbi-linux bin32/3c509.rom > /tftpboot/lts/bootrom reconfigured /etc/dhcpd.conf for the nic in question to grab the bootrom file I booted with the 3c509.fd0 floppy from above and verified that version 5.0 could load itself. Then I reconfigured /etc/dhcpd.conf while the bootrom was looping and booting itself and picked up the ltsp vmlinuz kernel and restarted dhcpd. It worked, it transfered the kernel and boot as far as dhclient. Then I: cd etherboot-5.1.2rc3/src make bin32/3c509.fd0 when booting from the floppy I received the following: blah.. Searching for server (DHCP)... ..Me:192.168.2.11, Server 192.168.2.6, Gateway 192.168.2.6 Laoding 192.168.2.6:lts/vmlinuz-2.4.9-ltsp-5 ...(NBI) segment [00092800,00094000) does not fit in an memory region error: not a valid image Unable to load file. <sleep> I reconfigured /etc/dhcpd.conf to point to the bootrom file that worked with 5.0 and received the following: Searching for server (DHCP)... ..Me:192.168.2.11, Server 192.168.2.6, Gateway 192.168.2.6 Laoding 192.168.2.6:/lts/bootrom ...(NBI)...............Unable to load file. <sleep> I hope this helps. BTW, the current cvs will not compile for me, it complains about a missing separator at Roms:370 Tim > -----Original Message----- > From: eth...@li... > [mailto:eth...@li...]On Behalf Of > Eric W Biederman > Sent: Tuesday, August 27, 2002 2:52 PM > To: Etherboot Developers > Cc: Timothy Legge > Subject: Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk. > > > "Timothy Legge" <tl...@ro...> writes: > > > Hi > > > > > Which rom image did you build? > > > > I built both the 3c515 and the 3c509. This morning I verified > that neither > > the 3c515 or the 3c509 driver gets past: > > > > .000041.0000 done > > R > > Compressed? or Uncompressed. > > That message does not seem at all familiar, so if you could give some > more boot context. Console dump from a serial port perhaps, > it would really help. > > > on my old 486. I will have to pull the 3c515 and toss it in > the Pentium PC > > (the one that reported the error: > > > > segment [00092800,00094000) does not fit in any memory region > > Again I don't have enough context to do anything with just that message. > But it would have take a fairly large image to make that work. > > Eric > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Etherboot-developers mailing list > Eth...@li... > https://lists.sourceforge.net/lists/listinfo/etherboot-developers > |
|
From: Eric W B. <ebi...@ln...> - 2002-08-28 00:25:20
|
"Timothy Legge" <tl...@ro...> writes:
> What I did:
>
> cd etherboot-5.0/src
> make bin32/3c509.fd0
> make bin32/3c509.rom
> mknbi-linux bin32/3c509.rom > /tftpboot/lts/bootrom
>
> reconfigured /etc/dhcpd.conf for the nic in question to grab the bootrom
> file
>
> I booted with the 3c509.fd0 floppy from above and verified that version 5.0
> could load itself. Then I reconfigured /etc/dhcpd.conf while the bootrom
> was looping and booting itself and picked up the ltsp vmlinuz kernel and
> restarted dhcpd. It worked, it transfered the kernel and boot as far as
> dhclient.
>
> Then I:
>
> cd etherboot-5.1.2rc3/src
> make bin32/3c509.fd0
>
> when booting from the floppy I received the following:
>
> blah..
>
> Searching for server (DHCP)...
> ..Me:192.168.2.11, Server 192.168.2.6, Gateway 192.168.2.6
> Laoding 192.168.2.6:lts/vmlinuz-2.4.9-ltsp-5 ...(NBI)
> segment [00092800,00094000) does not fit in an memory region
> error: not a valid image
> Unable to load file.
> <sleep>
>
> I reconfigured /etc/dhcpd.conf to point to the bootrom file that worked with
> 5.0 and received the following:
>
> Searching for server (DHCP)...
> ..Me:192.168.2.11, Server 192.168.2.6, Gateway 192.168.2.6
> Laoding 192.168.2.6:/lts/bootrom ...(NBI)...............Unable to load file.
> <sleep>
>
> I hope this helps.
>
> BTW, the current cvs will not compile for me, it complains about a missing
> separator at Roms:370
The Roms file at least works for me. I just verified it.
O.k. Looking at bin32/3c509.tmp it lives from 0x20000 to 0x2d644.
So we do not have an overlap, of images.
I think tagged images worked for Ken, so it is probably not a tagged image, problem.
There are two problems
1) Etherboot doesn't think you have memory up to 0x940000
2) The bootrom image appears short, so load_kernel returns without doing anything.
I can think of two software possibilities.
1) I may be stressing your version of binutils and the compiler
into compiling incorrect code. If you could run
ld --version and gcc --version we can compare, I have:
ld --version
GNU ld version 2.12.90.0.9 20020526
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
gcc --version
2.95.2
2) Etherboot appears to be incorrectly deteceting your available memory.
At line 360 of osloader.c could you change.
if (!fit) {
printf("\nsegment [%X,%X) does not fit in any memory region\n",
start, end);
-#if ELF_DEBUG
+#if 1
printf("Memory regions(%d):\n", meminfo.map_count);
for(i = 0; i < meminfo.map_count; i++) {
unsigned long long r_start, r_end;
if (meminfo.map[i].type != E820_RAM)
continue;
r_start = meminfo.map[i].addr;
r_end = r_start + meminfo.map[i].size;
printf("[%X%X, %X%X) type %d\n",
(unsigned long)(r_start >> 32),
(unsigned long)r_start,
(unsigned long)(r_end >> 32),
(unsigned long)r_end,
meminfo.map[i].type);
}
#endif
return 0;
}
This will report what memory etherboot thinks you do have available. Which
should at least explain why etherboot is complaining about using 0x92800 - 0x94000.
Eric
|
|
From: <ebi...@ln...> - 2002-08-28 01:13:28
|
"Timothy Legge" <tl...@ro...> writes:
> > The Roms file at least works for me. I just verified it.
>
> Strange, I will try another update.
>
> > I can think of two software possibilities.
> > 1) I may be stressing your version of binutils and the compiler
> > into compiling incorrect code. If you could run
>
> It seems that there is no comparison. I am usin Mandrake kgcc
>
> ld --version
> GNU ld 2.10.91
> Copyright 2000 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License. This program has absolutely no warranty.
> Supported emulations:
> elf_i386
> i386linux
This is probably o.k. There is a bug fixed and I believe introduced
somewhere between 2.10 and 2.12.90.0.9 that puts junk at the end of
assembly files. So be careful. If you had earlier than 2.9 I might
worry but you are probably o.k.
> kgcc --version
> egcs-2.91.66
I would be surprised if the compiler version makes a difference.
I use roughly the same compiler for compiling LinuxBIOS because
the later ones appear to introduce code bloat.
> > 2) Etherboot appears to be incorrectly deteceting your available memory.
> > At line 360 of osloader.c could you change.
>
> I receive
>
> Memory regions(32)
Ouch! The e820 map worked found 32 memory regions, none of them
with ram!
> I guess I should update my compiler etc.
Carefully. At this point I think it is interesting information but
I wouldn't jump terribly fast.
I would start with memsizes.c
The following patch should work around the immediate problem.
A little more investigation is probably called for to see
what is actually in the returned e820 map.
void get_memsizes(void)
{
int i;
+ int e820_ram;
meminfo.basememsize = basememsize();
meminfo.memsize = memsize();
meminfo.map_count = meme820(meminfo.map, E820MAX);
+ e820_ram = 0;
+ for(i = 0; i < meminfo.map_count; i++) {
+ if (meminfo.map[i].type == E820_RAM) {
+ e820_ram = 1;
+ break;
+ }
+ }
- if (meminfo.map_count == 0) {
+ if (!e820_ram) {
/* If we don't have an e820 memory map fake it */
meminfo.map_count = 2;
meminfo.map[0].addr = 0;
meminfo.map[0].size = meminfo.basememsize << 10;
meminfo.map[0].type = E820_RAM;
meminfo.map[1].addr = 1024*1024;
meminfo.map[1].size = meminfo.memsize << 10;
meminfo.map[1].type = E820_RAM;
}
/* Allocate the real mode stack */
real_mode_stack = (meminfo.basememsize << 10);
}
Eric
|
|
From: Timothy L. <tl...@ro...> - 2002-08-28 01:35:04
|
Hi Eric > I would start with memsizes.c > The following patch should work around the immediate problem. I applied both the pcbios patch and the the memsizes patch. Now, I just get: Searching for server (DHCP)... ..Me:192.168.2.11, Server 192.168.2.6, Gateway 192.168.2.6 Loading 192.168.2.6:lts/vmlinuz-2.4.9-ltsp-5 ...(NBI) It now freezes at this point, requiring a hard reboot. Tim |
|
From: Timothy L. <tl...@ro...> - 2002-08-28 01:40:55
|
> I applied both the pcbios patch and the the memsizes patch. Now, I just > get: > > Searching for server (DHCP)... > ..Me:192.168.2.11, Server 192.168.2.6, Gateway 192.168.2.6 > Loading 192.168.2.6:lts/vmlinuz-2.4.9-ltsp-5 ...(NBI) > > It now freezes at this point, requiring a hard reboot. I then modified the /etc/dhcpd.conf file to grab the 3c509.fd0 and received the following: Searching for server (DHCP)... ..Me:192.168.2.11, Server 192.168.2.6, Gateway 192.168.2.6 Loading 192.168.2.6:lts/bootrom ...(NBI)...........Unable to Load file <sleep> <abort> There were no hard frezes with this file. Tim |
|
From: <ebi...@ln...> - 2002-08-28 04:59:22
|
"Timothy Legge" <tl...@ro...> writes: > > I applied both the pcbios patch and the the memsizes patch. Now, I just > > get: > > > > Searching for server (DHCP)... > > ..Me:192.168.2.11, Server 192.168.2.6, Gateway 192.168.2.6 > > Loading 192.168.2.6:lts/vmlinuz-2.4.9-ltsp-5 ...(NBI) > > > > It now freezes at this point, requiring a hard reboot. Hmm. So it dies before transmitting any packets. > I then modified the /etc/dhcpd.conf file to grab the 3c509.fd0 and received > the following: The rom image? > Searching for server (DHCP)... > ..Me:192.168.2.11, Server 192.168.2.6, Gateway 192.168.2.6 > Loading 192.168.2.6:lts/bootrom ...(NBI)...........Unable to Load file > <sleep> > <abort> > > There were no hard frezes with this file. So no change with that file at all... Very strange. I have sent you some romimages in a seperate message, ( I don't want to spam the list with them) but testing them will confirm if there is something in your toolchain that is causing problems. Eric |
|
From: Michael B. <mb...@fe...> - 2002-08-29 11:01:51
|
On 27 Aug 2002, Eric W. Biederman wrote: > > > I applied both the pcbios patch and the the memsizes patch. Now, I just > > > get: > > > Searching for server (DHCP)... > > > ..Me:192.168.2.11, Server 192.168.2.6, Gateway 192.168.2.6 > > > Loading 192.168.2.6:lts/vmlinuz-2.4.9-ltsp-5 ...(NBI) > > > It now freezes at this point, requiring a hard reboot. > Hmm. So it dies before transmitting any packets. > > I then modified the /etc/dhcpd.conf file to grab the 3c509.fd0 and received > > the following: > The rom image? > > Searching for server (DHCP)... > > ..Me:192.168.2.11, Server 192.168.2.6, Gateway 192.168.2.6 > > Loading 192.168.2.6:lts/bootrom ...(NBI)...........Unable to Load file > > <sleep> > > <abort> > > There were no hard frezes with this file. > So no change with that file at all... > Very strange. > I have sent you some romimages in a seperate message, ( > I don't want to spam the list with them) but testing them > will confirm if there is something in your toolchain that is > causing problems. I think I'm seeing the same problem. I'm getting total garbage in the E820 map. I added a config option IGNORE_E820_MAP that forces use of the "fake" memory map used when the e820 calls fail, which gets it to the point of "Loading 10.1.0.1:boot-8139too.nbi ...(NBI)" at which point it locks up and requires a hard reset. Ideas, toolchain test, etc. welcome. Michael Brown http://www.fensystems.co.uk |
