etherboot-developers Mailing List for Etherboot (Page 230)
Brought to you by:
marty_connor,
stefanhajnoczi
Menu
▾
▴
etherboot-developers — Discussion of developer issues
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(10) |
Sep
(3) |
Oct
(10) |
Nov
(47) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(41) |
Feb
(107) |
Mar
(76) |
Apr
(103) |
May
(66) |
Jun
(72) |
Jul
(27) |
Aug
(31) |
Sep
(33) |
Oct
(18) |
Nov
(33) |
Dec
(67) |
| 2002 |
Jan
(25) |
Feb
(62) |
Mar
(79) |
Apr
(74) |
May
(67) |
Jun
(104) |
Jul
(155) |
Aug
(234) |
Sep
(87) |
Oct
(93) |
Nov
(54) |
Dec
(114) |
| 2003 |
Jan
(146) |
Feb
(104) |
Mar
(117) |
Apr
(189) |
May
(96) |
Jun
(40) |
Jul
(133) |
Aug
(136) |
Sep
(113) |
Oct
(142) |
Nov
(99) |
Dec
(185) |
| 2004 |
Jan
(233) |
Feb
(151) |
Mar
(109) |
Apr
(96) |
May
(200) |
Jun
(175) |
Jul
(162) |
Aug
(118) |
Sep
(107) |
Oct
(77) |
Nov
(121) |
Dec
(114) |
| 2005 |
Jan
(201) |
Feb
(271) |
Mar
(113) |
Apr
(119) |
May
(69) |
Jun
(46) |
Jul
(21) |
Aug
(37) |
Sep
(13) |
Oct
(4) |
Nov
(19) |
Dec
(46) |
| 2006 |
Jan
(10) |
Feb
(18) |
Mar
(85) |
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(10) |
Jul
(20) |
Aug
(9) |
Sep
(11) |
Oct
(4) |
Nov
(1) |
Dec
(40) |
| 2008 |
Jan
(19) |
Feb
(8) |
Mar
(37) |
Apr
(28) |
May
(38) |
Jun
(63) |
Jul
(31) |
Aug
(22) |
Sep
(37) |
Oct
(38) |
Nov
(49) |
Dec
(24) |
| 2009 |
Jan
(48) |
Feb
(51) |
Mar
(80) |
Apr
(55) |
May
(34) |
Jun
(57) |
Jul
(20) |
Aug
(83) |
Sep
(17) |
Oct
(81) |
Nov
(53) |
Dec
(40) |
| 2010 |
Jan
(55) |
Feb
(28) |
Mar
(36) |
Apr
(7) |
May
|
Jun
|
Jul
(7) |
Aug
|
Sep
|
Oct
(1) |
Nov
(3) |
Dec
|
| 2011 |
Jan
(1) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
(10) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ronald G M. <rmi...@la...> - 2002-10-04 19:07:45
|
OK, I have the smartcore PIII sending out packets at last. They seem to be right (dhcpd thinks they're dhcp packets anyway) but things don't go well on the receive side. The in-memory descriptor is never filled in, and the frame received bit in the status word is never set. Anybody got a hint :-) ron |
|
From: Marty C. <ma...@et...> - 2002-10-04 10:24:04
|
Hello Everyone, I wanted to let you know that because of a change of ISPs, rom-o- matic.net might be off the net for a few hours this weekend. I will do everything I can to minimize downtime, and if things go particularly well, noone will notice a thing. I will be running ISP both routers concurrently and multi-homing rom, so even after the address is changed in the nameservers, the old address should still respond. So, theoretically, while we wait for the cached memory of the old address to expire in nameservers around the world, service should continue undisturbed. Thats the theory :) Thanks for all the kind comments about rom-o-matic.net. It is a pleasure to provide this service to the community. Marty -- Try: http://rom-o-matic.net/ to make Etherboot images instantly. Name: Marty Connor US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA Voice: (617) 491-6935; Fax: (617) 491-7046 Email: ma...@et... Web: http://www.etherboot.org/ |
|
From: Clinic <GH_...@ex...> - 2002-10-03 10:09:56
|
TXl0aDogYWxsIEhHSCBwcm9kdWN0cyBhcmUgdGhlIHNhbWUNCg0KPGh0bWw+ DQoNCjxoZWFkPg0KDQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD13aW5kb3dzLTEyNTIiPg0K DQo8bWV0YSBuYW1lPSJHRU5FUkFUT1IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBG cm9udFBhZ2UgNC4wIj4NCg0KPG1ldGEgbmFtZT0iUHJvZ0lkIiBjb250ZW50 PSJGcm9udFBhZ2UuRWRpdG9yLkRvY3VtZW50Ij4NCg0KPHRpdGxlPlRoZXJl IGFyZSB0aHJlZSBkaWZmZXJlbnQgdHlwZXMgb2YgSEdIIHByb2R1Y3RzPC90 aXRsZT4NCg0KPC9oZWFkPg0KDQo8Ym9keSBiYWNrZ3JvdW5kPSJjbG91ZHMu anBnIj4NCg0KPHA+PGZvbnQgc2l6ZT0iNCI+PGZvbnQgY29sb3I9IiM4MDAw MDAiPjxiPlRoZXJlIGFyZSB0aHJlZSBkaWZmZXJlbnQgdHlwZXMgb2YNCg0K SEdIIHByb2R1Y3RzLjwvYj48L2ZvbnQ+PGJyPg0KDQpUaGUgY29uZnVzaW9u IGlzIHRoYXQgYWxsIHRocmVlIGFyZTxicj4NCg0KYWR2ZXJ0aXNlZCBhcyBp ZiB0aGV5IHdlcmUgdGhlIHNhbWUuPC9mb250Pjxicj4NCg0KJm5ic3A7PGJy Pg0KDQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPHU+VGhlIHRocmVlIHR5cGVzIGFyZTo8L3U+PGJyPg0KDQombmJzcDs8 YnI+DQoNCjxiPjEpPC9iPiAtLS0gPGZvbnQgY29sb3I9IiMwMDAwRkYiPjxi PkhvbWVvcGF0aGljIEhHSDwvYj48L2ZvbnQ+PGJyPg0KDQo8Yj4yKTwvYj4g LS0tIDxmb250IGNvbG9yPSIjMDAwMEZGIj48Yj5QcmUtY3Vyc29yIEhHSDwv Yj48L2ZvbnQ+PGJyPg0KDQo8Yj4zKTwvYj4gLS0tIDxmb250IGNvbG9yPSIj MDAwMEZGIj48Yj5SZWFsIG9yIHN5bnRoZXRpYyBIR0g8L2I+PC9mb250Pg0K DQooZGVsaXZlcmVkIGJ5IGluamVjdGlvbjxicj4NCg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9yLCBieSBhbiBvcmFs IHNwcmF5IG1ldGhvZCkuPGJyPg0KDQombmJzcDs8YnI+DQoNCkRvIHlvdSBr bm93IGRpZmZlcmVuY2VzPzxicj4NCg0KJm5ic3A7PGJyPg0KDQpDYWxsIHVz IGFuZCB3ZSdsbCBleHBsYWluIHRoZW0gdG8geW91Ljxicj4NCg0KJm5ic3A7 PGJyPg0KDQpPdXIgdG9sbCBmcmVlIG51bWJlciBpcyA8Zm9udCBjb2xvcj0i IzAwMDA4MCI+PGI+MS04ODgtNjIxLTczMDA8L2I+PC9mb250Pjxicj4NCg0K QW4gSEdIIHN0YWZmIG1lbWJlciBpcyBhdmFpbGFibGU8YnI+DQoNCjkgdG8g NSBQYWNpZmljIFRpbWUuPGJyPg0KDQpJZiBhZnRlciBob3VycywgcGxlYXNl IGxlYXZlIHlvdSBuYW1lPGJyPg0KDQphbmQgZGF5IGFuZCBldmVuaW5nIHBo b25lIG51bWJlcnMuPGJyPg0KDQpXZSB3aWxsIGNhbGwgeW91IGJhY2sgaW4g YSBubyBwcmVzc3VyZSw8YnI+DQoNCmVkdWNhdGlvbmFsIG1hbm5lci48YnI+ DQoNCklmIHlvdSBhcmUgb3ZlcnNlYXMgY2FsbCB5b3VyIGxvbmcgZGlzdGFu Y2U8YnI+DQoNCm9wZXJhdG9yIGFuZCBhc2sgdG8gYmUgY29ubmVjdGVkIHRv IG91cjxicj4NCg0KcGhvbmUgbnVtYmVyLiZuYnNwOyBXZSB3aWxsIGNhbGwg eW91IGJhY2sgc288YnI+DQoNCndlIGNhbiBwYXkgZm9yIHRoZSBsb25nIGRp c3RhbmNlIGNoYXJnZXMuPGJyPg0KDQombmJzcDs8YnI+DQoNCjxmb250IGNv bG9yPSIjRkYwMDAwIj5Gb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiBIR0ggcmVh ZCBvbi4uLi4uLi4uLi4uLjwvZm9udD48YnI+DQoNCiZuYnNwOzxicj4NCg0K SEFWRSBZT1UgSEVBUkQgT0Y8YnI+DQoNCkhVTUFOIEdST1dUSCBIT1JNT05F IChIR0gpPz8/PGJyPg0KDQombmJzcDs8YnI+DQoNCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBSZWxlYXNlZCBieSB5b3VyIG93biBwaXR1aXRhcnkgZ2xh bmQsIEhHSCBzdGFydHMNCg0KZGVjbGluaW5nPGJyPg0KDQppbiB5b3VyIDIw cywgZXZlbiBtb3JlIGluIHlvdXIgMzBzIGFuZCA0MHMsIGV2ZW50dWFsbHkg cmVzdWx0aW5nPGJyPg0KDQppbiB0aGUgc2hyaW5rYWdlIG9mIG1ham9yIG9y Z2FucyAtLSBwbHVzLCBhbGw8YnI+DQoNCm90aGVyIHN5bXB0b21zIHJlbGF0 ZWQgdG8gb2xkIGFnZS48YnI+DQoNCiZuYnNwOzxicj4NCg0KJm5ic3A7PGJy Pg0KDQpJTiBUSE9VU0FORFMgT0YgQ0xJTklDQUwgU1RVRElFUyw8YnI+DQoN CkhHSCBIQVMgQkVFTiBTSE9XTiBUTyBBQ0NPTVBMSVNIIFRIRSBGT0xMT1dJ Tkc6PGJyPg0KDQombmJzcDs8YnI+DQoNCiogUmVkdWNlIEJvZHkgRmF0IGFu ZCBCdWlsZCBMZWFuIE11c2NsZTxicj4NCg0KJm5ic3A7Jm5ic3A7IFdJVEhP VVQgRVhFUkNJU0UhPGJyPg0KDQombmJzcDs8YnI+DQoNCiogRW5oYW5jZSBT ZXh1YWwgUGVyZm9ybWFuY2U8YnI+DQoNCiZuYnNwOzxicj4NCg0KKiBSZW1v dmUgV3JpbmtsZXMgYW5kIENlbGx1bGl0ZTxicj4NCg0KJm5ic3A7PGJyPg0K DQoqIExvd2VyIEJsb29kIFByZXNzdXJlIGFuZCBJbXByb3ZlIENob2xlc3Rl cm9sIFByb2ZpbGU8YnI+DQoNCiZuYnNwOzxicj4NCg0KKiBJbXByb3ZlIFNs ZWVwLCBWaXNpb24gYW5kIE1lbW9yeTxicj4NCg0KJm5ic3A7PGJyPg0KDQoq IFJlc3RvcmUgSGFpciBDb2xvciBhbmQgR3Jvd3RoPGJyPg0KDQombmJzcDs8 YnI+DQoNCiogU3RyZW5ndGhlbiB0aGUgSW1tdW5lIFN5c3RlbTxicj4NCg0K Jm5ic3A7PGJyPg0KDQoqIEluY3JlYXNlIEVuZXJneSBhbmQgQ2FyZGlhYyBP dXRwdXQ8YnI+DQoNCiZuYnNwOzxicj4NCg0KKiBUdXJuIGJhY2sgeW91ciBi b2R5J3MgQmlvbG9naWNhbCBUaW1lIENsb2NrIDEwIC0gMjAgeWVhcnM8YnI+ DQoNCiZuYnNwOzxicj4NCg0KKiBMaXZlIExvbmdlciBBTkQgU3Ryb25nZXI8 YnI+DQoNCiZuYnNwOzxicj4NCg0KQWxsIG5hdHVyYWwgYW5kIG9yZ2FuaWMg cGxhbnQgYmFzZWQ8YnI+DQoNCiZuYnNwOzxicj4NCg0KPGZvbnQgY29sb3I9 IiMwMDAwRkYiPjxiPkZFRUwgMTAgWUVBUlMgWU9VTkdFUiBXSVRIIE9SQUwg U1BSQVkgSEdILjxicj4NCg0KR1VBUkFOVEVFRDwvYj48L2ZvbnQ+PGJyPg0K DQombmJzcDs8YnI+DQoNCiZuYnNwOyZuYnNwOyZuYnNwOyBXZSBhcmUgdGhl IG1hbnVmYWN0dXJlciBhbmQgd2Ugc2VsbCBkaXJlY3RseSB0byBEb2N0b3Jz LDxicj4NCg0KQ2hpcm9wcmFjdG9ycywgYW5kIGNvbnN1bWVycyB3b3JsZCB3 aWRlIHRoZSBoaWdoZXN0IGdyYWRlPGJyPg0KDQombmJzcDtIR0ggT3JhbCBT cHJheSBhdmFpbGFibGUuJm5ic3A7PGJyPg0KDQombmJzcDs8YnI+DQoNCiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBXaXRoIGludGVybmV0IG1hcmtldGlu Zywgd2UgYXJlIGFibGUgdG8gc2F2ZQ0KDQphZHZlcnRpc2luZzxicj4NCg0K Y29zdCBhbmQgcGFzcyB0aG9zZSBzYXZpbmdzIGFsb25nIHRvIHlvdS48YnI+ DQoNCkJ1dCB5b3UgbXVzdCBhY3Qgbm93LiZuYnNwOzxicj4NCg0KJm5ic3A7 PGJyPg0KDQpUbyByZWNlaXZlIG1vcmUgaW5mb3JtYXRpb24gY2FsbCZuYnNw OyB1cyBub3cuPGJyPg0KDQombmJzcDs8YnI+DQoNCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBUT0xMIEZSRUUgPGI+PGZvbnQgY29sb3I9IiMwMDAwODAiPjEt ODg4LTYyMS03MzAwPC9mb250PjwvYj48YnI+DQoNCiZuYnNwOzxicj4NCg0K V2UgbXVzdCBzcGVhayB0byB5b3UgaW4gcGVyc29uIHRvIHF1YWxpZnkgeW91 ciB1c2FnZS48YnI+DQoNCiZuYnNwOzxicj4NCg0KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEFsbCBvZiB5b3VyIHF1ZXN0aW9ucyB3aWxsIGJlIGFkZHJl c3NlZCBhbmQgYW5zd2VyZWQgaW4NCg0KYSBmcmllbmRseSw8YnI+DQoNCm5v IHByZXNzdXJlIG1hbm5lci4mbmJzcDsgT3VyIG1haW4gcHVycG9zZSBpcyB0 byBwcm92aWRlIHlvdSB3aXRoPGJyPg0KDQombmJzcDtpbmZvcm1hdGlvbiBz byB5b3UgY2FuIG1ha2UgYW4gZWR1Y2F0ZWQgZGVjaXNpb24uPGJyPg0KDQom bmJzcDs8YnI+DQoNCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGb3IgbW9y ZSBpbmZvcm1hdGlvbiBjYWxsPGJyPg0KDQombmJzcDs8YnI+DQoNCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8Yj48Zm9udCBjb2xvcj0iIzAwMDA4MCI+MS04 ODgtNjIxLTczMDA8L2ZvbnQ+PC9iPjxicj4NCg0KJm5ic3A7PGJyPg0KDQom bmJzcDtJZiB5b3UgYXJlIG9uIGxpbmUgd3JpdGUgZG93biBvdXI8YnI+DQoN CnBob25lIG51bWJlciBhbmQgY2FsbCB1cyB3aGVuIHlvdSBjYW4uPGJyPg0K DQombmJzcDs8YnI+DQoNClNvb24sIHlvdSBhbmQgeW91ciBsb3ZlZCBvbmVz IHdpbGwgYmUgdmVyeSBnbGFkIHlvdSBkaWQuPGJyPg0KDQombmJzcDs8YnI+ DQoNClJlYWQgd2hhdCBwZW9wbGUgYXJlIHNheWluZzo8YnI+DQoNCiZuYnNw Ozxicj4NCg0KJnF1b3Q7VGhlIGVmZmVjdHMgb2YgNiBtb250aHMgb2YgR0gg b248YnI+DQoNCmxlYW4gYm9keSBtYXNzIGFuZCBmYXQgd2VyZSBlcXVpdmFs ZW50PGJyPg0KDQppbiBtYWduaXR1ZGUgdG8gdGhlIGNoYW5nZXMgaW5jdXJy ZWQ8YnI+DQoNCmR1cmluZyAxMC0yMCB5ZWFycyBvZiBhZ2luZy4mcXVvdDs8 YnI+DQoNCkRyLiBEYW5pZWwgUnVkbWFuLCBNRCw8YnI+DQoNCk5ldyBFbmds YW5kIEpvdXJuYWwgb2YgTWVkaWNpbmUuPGJyPg0KDQombmJzcDs8YnI+DQoN CiZxdW90O1dpdGhpbiBmb3VyIG1vbnRocywgbXkgYm9keSBmYXQgZGVjcmVh c2VkPGJyPg0KDQombmJzcDtmb3JtIDMwJSBkb3duIHRvIDIxJSEgSSBub3Rp Y2VkIG15IHNraW48YnI+DQoNCiZuYnNwO2lzIG1vcmUgc3VwcGxlIGFuZCBt eSBvdmVyYWxsIG1lbnRhbDxicj4NCg0KJm5ic3A7b3V0bG9vayBpbXByb3Zl ZCBzaWduaWZpY2FudGx5LiZxdW90Ozxicj4NCg0KJm5ic3A7RC5XLiwgTmV3 IEplcnNleTxicj4NCg0KJm5ic3A7PGJyPg0KDQomcXVvdDtXZSBoYXZlIGJl ZW4gb24gdGhlIHNwcmF5IGZvciBqdXN0IDMgd2Vla3M8YnI+DQoNCm5vdywg YW5kIGJlc2lkZXMgdGhlIHRyZW1lbmRvdXMgZW5lcmd5IHdlPGJyPg0KDQpi b3RoIGZlZWwsIG15IGh1c2JhbmRzIGFsbGVyZ2llcyBhbmQgc3BlbGxzPGJy Pg0KDQpvZiBkZXByZXNzaW9uIGhhdmUgbGlmdGVkLiBJIGFtIGhlYWxpbmc8 YnI+DQoNCmV4dHJlbWVseSBmYXN0IGFmdGVyIGFuIGFjY2lkZW50IGFuZCBo YXZlPGJyPg0KDQpsb3N0IDcgbGJzLiB3aXRob3V0IHRyeWluZyEmcXVvdDs8 YnI+DQoNCkMuQi4sIEZsYWdzdGFmZi4gQVo8YnI+DQoNCiZuYnNwOzxicj4N Cg0KVGhhbmtzIGZvciByZWFkaW5nIG91ciBsZXR0ZXIsPGJyPg0KDQpUaGUg SEdIIFN0YWZmPGJyPg0KDQpVU0EgRGl2aXNpb248YnI+DQoNCiZuYnNwOzxi cj4NCg0KUFM6Jm5ic3A7IFRoZSBIR0ggU3RhZmYgZ3VhcmFudGVlcyB0aGU8 YnI+DQoNCmhpZ2hlc3QgcXVhbGl0eSBhbmQgbG93ZXN0IHByaWNlLjxicj4N Cg0KJm5ic3A7PGJyPg0KDQombmJzcDtXZSBtYW51ZmFjdHVyZSBhbmQgc2hp cCBkaXJlY3RseSB0byB5b3VyIGRvb3IuPGJyPg0KDQombmJzcDs8YnI+DQoN CkNhbGwgdXMgbm93IDxiPjxmb250IGNvbG9yPSIjMDAwMDgwIj4xLTg4OC02 MjEtNzMwMDwvZm9udD48L2I+PGJyPg0KDQombmJzcDs8YnI+DQoNCj09PT09 PT0mbmJzcDsmbmJzcDsgRW5kIG9mIG1lc3NhZ2UgPT09PT09PT0mbmJzcDs8 YnI+DQoNCiZuYnNwOzxicj4NCg0KJm5ic3A7Jm5ic3A7IFRoZSBmb2xsb3dp bmcgc3RhdGVtZW50IGlzIHByb3ZpZGVkIHRvIGJlPGJyPg0KDQppbiBjb21w bGlhbmNlIHdpdGggY29tbWVyY2lhbCBlbWFpbCBsYXdzLjxicj4NCg0KJm5i c3A7PGJyPg0KDQombmJzcDsmbmJzcDsgSWYgeW91IGRvIG5vdCB3aXNoIHRv IHJlY2VpdmUgZnVydGhlcjxicj4NCg0KbWFpbGluZ3MsIHBsZWFzZSBjbGlj ayByZXBseSB0bzogcGxzcmVtaGdoMzRAYnRhbWFpbC5uZXQuY24gIGFuZCB0 eXBlIHJlbW92ZSBpbiB0aGUgc3ViamVjdCBib3guPGJyPg0KDQpUaGVuIGNs aWNrIHNlbmQuPGJyPg0KDQombmJzcDs8YnI+DQoNCiZuYnNwOyZuYnNwOyBU aGlzIG1lc3NhZ2UgaXMgaW4gZnVsbCBjb21wbGlhbmNlIHdpdGg8YnI+DQoN ClUuUy4gRmVkZXJhbCByZXF1aXJlbWVudHMgZm9yIGNvbW1lcmNpYWw8YnI+ DQoNCmVtYWlsIHVuZGVyIGJpbGwgUy4xNjE4IFRpdGxlIGxsbCwgU2VjdGlv biAzMDEsPGJyPg0KDQpQYXJhZ3JhcGggKGEpKDIpKEMpIHBhc3NlZCBieSB0 aGUgMTA1dGggVS5TLjxicj4NCg0KQ29uZ3Jlc3MgYW5kIGlzIG5vdCBjb25z aWRlcmVkIFNQQU08YnI+DQoNCnNpbmNlIGl0IGluY2x1ZGVzIGEgcmVtb3Zl IG1lY2hhbmlzbS4qPGJyPg0KDQpUaGlzIG1lc3NhZ2UgaXMgbm90IGludGVu ZGVkIGZvciByZXNpZGVudHMgaW4gdGhlPGJyPg0KDQpzdGF0ZXMgb2YgQ0Es IE5DLCBOViwgUkksIFROLCBWQSAmYW1wOyBXQS48YnI+DQoNClNjcmVlbmlu ZyBvZiBhZGRyZXNzZXMgaGFzIGJlZW4gZG9uZSB0byB0aGUgYmVzdDxicj4N Cg0Kb2Ygb3VyIHRlY2huaWNhbCBhYmlsaXR5Ljxicj4NCg0KJm5ic3A7PGJy Pg0KDQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2FsbCB1cw0KDQpu b3cgPGI+PGZvbnQgY29sb3I9IiMwMDAwODAiPjEtODg4LTYyMS03MzAwPC9m b250PjwvYj4gZm9yIHlvdXI8YnI+DQoNCiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBmcmVlDQoNCkhHSCBjb25zdWx0YXRpb24uPC9wPg0KDQo8cD48 YnI+DQoNClRoYW5rIHlvdTwvcD4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+DQoN CiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiAN CiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiAN CiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiAN Cg0KLS0NCg0KNzA1M2pOY1UzLTYyOUt0WXUyNTM5VVhTTjUtMzY5SGtTeDQ5 NTJ4SE1hNS0xOTNIa0JSMzI2NVZVdFM1LTYwMU5XUXYxOTIzQWFzZ2w3Mg== |
|
From: Boris <bo...@th...> - 2002-10-02 17:12:36
|
Yes, its true. You can make $500can [Because I live in canada] just to get the Prism2_pci driver working properly. Yes, The prism2_pci driver works but *only* for small bootable images. Anything larger then around 18-20mb's causes errors to occur. Im sure you are asking why not just make smaller images but thats not what we want to do. The Realtek 8029 and Realtek 8139 driver boots up our 42mb images no problem but the Prism2_pci driver doesn't. We will pay for anyone to properly correct this issue. Not a quick hack but a proper fix. If the driver is working properly then what is causing it stop working. [Check out our specs]. More information can be found on our website [Just a quick website ]. Check out http://www.thinovations.com/wireless/ Thank you for your time. |
|
From: Claudio G. <cla...@fa...> - 2002-10-01 09:42:54
|
Alle Saturday 21 September 2002 13:30, Ken Yap ha scritto: > Ok, I think I have fixed start32.S/first32.c to use its own stack and > thus work properly when relocated, whether by --relocseg or 5.1.2rc3. I > have booted tomsrtbt with 5.0.7 and also 5.1.2rc3 on a 3c509. This fix > is only for the ELF or --first32pm images. I'm not sure I want to > support FIRST32RM much longer. See below. > > The new mknbi can be found at www.etherboot.org/mknbi-1.2-10rc1.tar.bz2 > Please give it a whirl. Don't know if this can help, but this is my scenario: * Old System (works!) [without DiskOnChip] Etherboot 5.0.6 mknbi 1.2.6 linux kernel 2.4.18 I builded the nbi with: mknbi-linux --ip=rom --append="root=/dev/ram ramdisk=1 ramdisk_size=10240 vga=769 console=ttyS4 sb=0x220,9,1,5 init=/sbin/quickinit" --output linux.nbi bzImage RamDisk When the system boots up on the commandline I'll find the network informations provided from our DHCP server (I use this information extracting form /proc/cmdline) * New System (DOES'NT work) [with DiskOnChip] Etherboot 5.0.6 (the same as above, but builded with RELOCADDR=0x84000) mknbi 1.2.10rc1 linux kernel 2.4.18 (the same) I builded the nbi with: mknbi-linux --ip=rom --append="root=/dev/ram ramdisk=1 ramdisk_size=10240 vga=769 console=ttyS4 sb=0x220,9,1,5 init=/sbin/quickinit" --output linux.nbi --relocseg=0x8000 --first32pm= bzImage RamDisk The system boots up, but on the commandline I find "ip=255.255.255.255:255.255.255.255:::" (that is not the informations my DHCP provide!) I've tried the same nbi image on the old system (the one without DiskOnChip and with Etherboot builded with the default RELOCADDR) and obtained the very same behaviour. Do you have some idea? Thanks! Claudio -- "Only two things are infinite: the universe and human stupidity, and I'm not so sure about the Universe." Albert Einstein ---------------------------------------------------------------- // Claudio Granatiero ICQ 16725435 \\|soft PGP: 74F0 52C0 75A1 4CAA B3E8 13CE DA7A C86E 2EBA 9F75 |
|
From: Eric W B. <ebi...@ln...> - 2002-09-28 06:20:08
|
ke...@us... (Ken Yap) writes: > >In 5.1 I have already moved the pci_ids into the driver files so > >auto-generating config.c would be moving in the opposite direction, > >and it would would make it very hard to have a multiple driver etherboot. > > I know, but I'm not autogenerating config.c, just include files called > $family_ids.c containing the table so you can just as easily include the > file in $family.c and ignore config.c. I agree that it makes more sense > to have the table in $family.c, all you need is a Perl fragment to scan > for a known pattern indicating a table and to turn that into NIC lines. I will have to see what can be done. For now I am knocking off bugs as I come to them. And manually maintaining NIC for a little while longer isn't a huge problem. > BTW are you keeping track of which drivers are working in 5.1? All of the drivers should still be working minimally in 5.1. Though I may have fat fingered the prism driver. I know I touched it just a little bit, adding/updating the virt_to_bus/bus_to_virt code. The drivers that work with multicast are marked as such. I have don't anything as far as testing which drivers work with relocation. I suppose I should go through the drivers and add: #ifdef RELOCATION #warning this driver has not yet been tested with relocation enabled. #endif And then we can remove those lines as the drivers are tested. And I should probably update LOG as well to note all of the other things that have happened in the development branch. At the moment, I am going home for bed. The multicast code it has been working solidly on a 960 node cluster, with no real complains. On Wednesday I am scheduled to go through and do some reboot testing. To test BIOS stability. But if I have missed anything in the multicast slam protocol it will show up there as well. Eric |
|
From: Eric W B. <ebi...@ln...> - 2002-09-28 06:09:37
|
There are several noticeable steps forward. - The serial code is now in C making it more maintainable, there were a few lines in serial_init that were just wrong. - The bios32 pci code is now relocatable. - I have abstracted out the timer code a bit more for those people with weird timers. I haven't implemented any new timers but weird timers should fit in much more cleanly now. - The liloprefix and comprefix code is updated. I changed the build just a little bit to ensure all segment relative offsets were marked as such. And then I forgot to problems revealed in liloprefix. Besides drivers that don't do multicast or handle relocation it looks like only the old boot from disk code remains broken. I am getting an e1000 driver finished that must run under the pcbios, so I should catch most of the pcbios bugs. And my CVS commit comments.... - Replace serial.S with serial.c - Cleanup the com preserve code - Make the pci code relocateable - Fix the comprefix and the liloprefix to compile again - Make relocation the default for the non LinuxBIOS code - Added a bios32_call function to pcbios.S - Update the boot from disk code, adding the concept of a failsafe image. - Fix linuxbios.c so we actually pay attention to the boot order specified - Minor timer cleanup, now when we switch timers we can replace all of the timer functions. Eric |
|
From: <ke...@us...> - 2002-09-26 17:02:03
|
>Posting another message again but this time about the latest etherboot 5.0 cv >s tree. I just downloaded it and tried compiling it and the following error h >as occured > >gcc -DPCBIOS -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DBACKOFF_LIMIT=7 -DCONGE >STED -DTAGGED_IMAGE -DELF_IMAGE -Os -ffreestanding -fstrength-reduce -fomit-f >rame-pointer -mcpu=i386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 - >Wall -W -Wno-format -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION >=\"5.0.7\" -DRELOC=0x94000 -DINCLUDE_3C595 -o bin32/config-3c595.o -c confi >g.c >cc1: warning: -malign-loops is obsolete, use -falign-loops >cc1: warning: -malign-jumps is obsolete, use -falign-jumps >cc1: warning: -malign-functions is obsolete, use -falign-functions Ok, looks like I need to update the flags. Anybody know if -falign-loops, etc is supported in older versions of gcc? >config.c:25:23: 3c595_ids.h: No such file or directory >config.c:131: `a3c595_nics' undeclared here (not in a function) >config.c:131: initializer element is not constant >config.c:131: (near initialization for `NIC[0].pci_ids') >config.c:131: `a3c595_nics' undeclared here (not in a function) >config.c:131: `a3c595_nics' undeclared here (not in a function) >config.c:131: warning: missing initializer >config.c:131: warning: (near initialization for `NIC[0].pci_ids') >config.c:131: initializer element is not constant >config.c:131: (near initialization for `NIC[0]') >config.c:214: initializer element is not constant >config.c:214: (near initialization for `NIC[1]') >make: *** [bin32/config-3c595.o] Error 1 You should delete Roms which will cause genrule.pl to be run which will generate the include files needed from NIC. Or touch NIC which will cause that to happen. |
|
From: <ke...@us...> - 2002-09-26 16:57:42
|
>I just downloaded the latest CVS of mknbi and I did a make and it compiled pr >operly but when I did a make install, the following error occured > >mkdir -p /usr/lib/mknbi >install mknbi disnbi dismbr disdosbb /usr/lib/mknbi/ >install -m 644 Nbi.pm Elf.pm TruncFD.pm first16.linux fi...@0x... f >irs...@0x... fir...@0x... fi...@0x... first32 >pm...@0x... fir...@0x... first.dos first.fdos menu nfl altbo >ot.bin rmrd.com /usr/lib/mknbi/ >install: cannot stat `altboot.bin': No such file or directory >make: *** [install] Error 1 > >I checked and their wasnt a altboot.bin file either. Sorry, my mistake. Add $(ALTBOOT) to the dependency list of install: or get the corrected Makefile from CVS. You'll need nasm to compile from altboot.S. Or just remove altboot.bin from the install list, you probably don't need it. Oh you'll also find first-dos broken. Get first-dos.h from CVS again. |
|
From: Boris <bo...@th...> - 2002-09-26 16:54:15
|
Posting another message again but this time about the latest etherboot 5.0 cvs tree. I just downloaded it and tried compiling it and the following error has occured gcc -DPCBIOS -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DBACKOFF_LIMIT=7 -DCONGESTED -DTAGGED_IMAGE -DELF_IMAGE -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer -mcpu=i386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.7\" -DRELOC=0x94000 -DINCLUDE_3C595 -o bin32/config-3c595.o -c config.c cc1: warning: -malign-loops is obsolete, use -falign-loops cc1: warning: -malign-jumps is obsolete, use -falign-jumps cc1: warning: -malign-functions is obsolete, use -falign-functions config.c:25:23: 3c595_ids.h: No such file or directory config.c:131: `a3c595_nics' undeclared here (not in a function) config.c:131: initializer element is not constant config.c:131: (near initialization for `NIC[0].pci_ids') config.c:131: `a3c595_nics' undeclared here (not in a function) config.c:131: `a3c595_nics' undeclared here (not in a function) config.c:131: warning: missing initializer config.c:131: warning: (near initialization for `NIC[0].pci_ids') config.c:131: initializer element is not constant config.c:131: (near initialization for `NIC[0]') config.c:214: initializer element is not constant config.c:214: (near initialization for `NIC[1]') make: *** [bin32/config-3c595.o] Error 1 |
|
From: Boris <bo...@th...> - 2002-09-26 16:42:06
|
I just downloaded the latest CVS of mknbi and I did a make and it compiled properly but when I did a make install, the following error occured mkdir -p /usr/lib/mknbi install mknbi disnbi dismbr disdosbb /usr/lib/mknbi/ install -m 644 Nbi.pm Elf.pm TruncFD.pm first16.linux fi...@0x... fir...@0x... fir...@0x... fi...@0x... fir...@0x... fir...@0x... first.dos first.fdos menu nfl altboot.bin rmrd.com /usr/lib/mknbi/ install: cannot stat `altboot.bin': No such file or directory make: *** [install] Error 1 I checked and their wasnt a altboot.bin file either. |
|
From: <ke...@us...> - 2002-09-26 12:55:56
|
>In 5.1 I have already moved the pci_ids into the driver files so >auto-generating config.c would be moving in the opposite direction, >and it would would make it very hard to have a multiple driver etherboot. I know, but I'm not autogenerating config.c, just include files called $family_ids.c containing the table so you can just as easily include the file in $family.c and ignore config.c. I agree that it makes more sense to have the table in $family.c, all you need is a Perl fragment to scan for a known pattern indicating a table and to turn that into NIC lines. BTW are you keeping track of which drivers are working in 5.1? |
|
From: Peter L. <P.L...@sy...> - 2002-09-26 12:10:54
|
> Thanks! Is there anyone trying / working on this? Not as far as I know, no-one has said as much to the list. Vasil and I don't have the time or resources, though we're happy to help if we can. Keep talking on the list. > My idea is to provide a probe function, the transmit, poll, reset > and disable function to etherboot but internally making use of PXE > API to drive the network card. I guess that many of these will be quite simple, since startup/shutdown and Tx functions are part of the API. There's no poll as such, so presumably getting UNDI to achieve this is not quite trivial. I think you'll just have to wade through the API. > Is there any potential problem that I may encounter? My guess is "dumbass firmware". :) |
|
From: Peter L. <P.L...@sy...> - 2002-09-26 11:57:47
|
> I am trying to write up a generic 'nic' driver that make use of the > PXE UNDI API, do I need to define PXELOADER_KEEP_UNDI? Hooray! Joe, I will personally buy you a beer when this first works! I take it that you have a copy of the 2.1 pxespec doc [*]? The PXE API consists of 4 sections (pre-boot, UNDI, UDP, TFTP), which can be unloaded if not required. Actually the current PXE "loader" does not actually load anything - the nic's PXE firmware actually loads and initiates it. It is really an *unloader* - once it finds itself running, it unloads the PXE API sections - and then runs the same Etherboot code (including the NIC driver) as if it had been loaded from ROM, floppy or whatever. The PXELOADER_KEEP_UNDI has the effect of not unloading UNDI - so yes, you'll need to keep that code (there isn't a lot of it) for a UNDI driver to work. Vasil, who wrote the PXE (un)loader code, put in the flag as a hint to the brave soul who takes on a UNDI driver. A bit of history - the code was written last year when we needed to do booting of cluster machines. I had some success in using EB from lilo and ROM (we used 3c905Cs which are easily flashable), but we started getting machines with unflashable PXE nic roms. It was also deemed desirable at the time to say to a customer that we "supported" PXE. To get Linux from PXE, the alternatives I could see were pxelinux or bpbatch, but I wanted EB, so I tried naively to get PXE to load a DOS environment and then EB via a COM file. I spoke to Vasil about this, and he realised that it would be quite easy to get PXE to use EB as the NBP (unlike me, he can code x86 assembler). A few days later he code working; my only contribution was to help merge it with EB source tree and give out some hints on using it. Marty Connor then did a detailed description which has become PXE howto for Etherboot and LTSP. This got round *our* PXE problem, and it seems that quite a few people have used EB-via-PXE (Marty, do you know what the rom-o-matic download stats are for the various forms of EB?). However, the main disadvantage has always been that for simple cases where using the UNDI driver would be desirable, one must select the right EB driver and build or get an image from rom-o-matic. A UNDI driver would make EB-via-PXE into a single, portable blob of code - a more viable alternative to pxelinux. [To the pxelinux fans out there - I have nothing against pxelinux as such, other than the fact of its reliance on PXE]. Notes... Using the other PXE APIs (UDP, TFTP) seems like a really bad idea - the commercial implementations have a reputation for poor quality. I know you weren't suggesting this, but I'll mention it anyway. Stick to just the driver. Although an UNDI driver would be more convenient for thin clients and e.g. LTSP, the choice of using an EB driver is still needed. Obviously the UNDI driver only exists during a PXE boot, but using EB-via-PXE does NOT mean that only UNDI should be used once a UNDI driver exists. PXE implementations don't handle multiple NICs, so for >1 nic the EB drivers are required. And finally, though a UNDI driver is the obvious next step, the world *also* needs PXE-via-EB, as well as EB-via-PXE, i.e. a PXE API based on the existing EB driver code which allows existing PXE NBPs to run. So, Joe, if you're looking for *another* project after the UNDI driver, how about porting NILO (which currently uses OSkit) as an Etherboot module? :) [*] http://www.intel.com/labs/manage/wfm/wfmspecs.htm |
|
From: Joe W. <jo...@sh...> - 2002-09-26 11:15:39
|
Thanks! Is there anyone trying / working on this? My idea is to provide a probe function, the transmit, poll, reset and disable function to etherboot but internally making use of PXE API to drive the network card. Is there any potential problem that I may encounter? - Joe On Thu, 2002-09-26 at 19:01, Eric W Biederman wrote: > Joe Wong <jo...@sh...> writes: > > > Hello, > > > > I am trying to write up a generic 'nic' driver that make use of the > > PXE UNDI API, do I need to define PXELOADER_KEEP_UNDI? > > If you are loading via PXE yes. > > Eric |
|
From: Eric W B. <ebi...@ln...> - 2002-09-26 11:05:01
|
ke...@us... (Ken Yap) writes: > >I will think about it. I would rather do it the other way though. > >Have all of the IDs in the drivers, and then generate NIC from that. > > > >I would very much like to be at the point, where the driver API > >was easy enough everything could be contained in a single file. > >I am almost there in 5.1 I just need to make NIC auto-generated. > > Think about ISA cards too even if you don't have any. Don't worry. When I am just skimming things I tend to not consider those cases, but when I am actually working it they get covered. Right now I don't think I can do any auto-generation of the ISA drivers because there is still a fair amount of potential code in the Makefile and other places that is per driver. But covering the pci and newer drivers should be straight forward. In 5.1 I have already moved the pci_ids into the driver files so auto-generating config.c would be moving in the opposite direction, and it would would make it very hard to have a multiple driver etherboot. Eric |
|
From: Eric W B. <ebi...@ln...> - 2002-09-26 11:01:32
|
Joe Wong <jo...@sh...> writes: > Hello, > > I am trying to write up a generic 'nic' driver that make use of the > PXE UNDI API, do I need to define PXELOADER_KEEP_UNDI? If you are loading via PXE yes. Eric |
|
From: Joe W. <jo...@sh...> - 2002-09-26 05:05:55
|
Hello, I am trying to write up a generic 'nic' driver that make use of the PXE UNDI API, do I need to define PXELOADER_KEEP_UNDI? Regards, - Joe |
|
From: <ke...@us...> - 2002-09-25 12:14:41
|
http://www.etherboot.org/p910nd/ 0.5 can now be compiled with libwrap (tcpwrappers) support and thus the daemon can be more selective about who can connect to it. |
|
From: <ke...@us...> - 2002-09-25 07:27:19
|
>I will think about it. I would rather do it the other way though. >Have all of the IDs in the drivers, and then generate NIC from that. > >I would very much like to be at the point, where the driver API >was easy enough everything could be contained in a single file. >I am almost there in 5.1 I just need to make NIC auto-generated. Think about ISA cards too even if you don't have any. |
|
From: <ebi...@ln...> - 2002-09-25 06:22:48
|
ke...@us... writes: > I've done what I should have done long ago: generate the PCI ID tables > for config.c from NIC. I've made the changes to genrules.pl which will > now generate files of the form $family_ids.h which are then included by > config.c. Now only NIC has to be edited to add a new PCI ID. I have > checked in the changes to CVS. > > Eric you might want do something similar for the 5.1.x branch by > grabbing NIC and genrules.pl from CVS and modifying the driver files. I will think about it. I would rather do it the other way though. Have all of the IDs in the drivers, and then generate NIC from that. I would very much like to be at the point, where the driver API was easy enough everything could be contained in a single file. I am almost there in 5.1 I just need to make NIC auto-generated. Eric |
|
From: <ke...@us...> - 2002-09-25 02:10:54
|
I've done what I should have done long ago: generate the PCI ID tables for config.c from NIC. I've made the changes to genrules.pl which will now generate files of the form $family_ids.h which are then included by config.c. Now only NIC has to be edited to add a new PCI ID. I have checked in the changes to CVS. Eric you might want do something similar for the 5.1.x branch by grabbing NIC and genrules.pl from CVS and modifying the driver files. |
|
From: Christoph P. <pl...@ir...> - 2002-09-24 12:08:37
|
Hello, What is probed by Etherboot to detect if the rom image is the correct one for the LAN Interface? I have an Ethernet Express Pro 100 Card, probably Model Nr. 82562ET. When I saw that Etherboot said "Probing...[EEPRO100] No adapter found", I started to investigate and found out that my card has PCI device ID 0x8086,0x103b instead of the number that is given in the file src/NIC. So I added another card to that file and named it "id103b" with PCI Id 0x8086,0x103b. Then I called "make clean", "make Roms" and "make". When I tried the image id103b.rom, the boot was still aborted with the message "No adapter found". Therefore I want to ask here the above question. Christoph |
|
From: Ronald G M. <rmi...@la...> - 2002-09-23 16:34:15
|
I have been on other things for a while but had a chance to look at this again. Recap: on the smartcore P3, etherboot 5.0.7 fails because all inw() operations return 0. Two inw()s in a row sometimes return the right value on the second one. I thought this might be a memory config problem so I brought down memtest 3.0, and am now running it. Unfortunately, it runs just fine. Memory configuration, at least judging by the memtest results, is correct on this machine. I'm up to test 4, running for 7 minutes now, and usually memory problems if they existed would have shown up by now. So, back to the original issue: inw operations acting wrong. The first inw() always reads 0, the seconds reads what looks like the right value. Anybody have an idea on what kind of north/south configuration problems could make this happen? ron |
|
From: <ebi...@ln...> - 2002-09-22 21:42:17
|
Anselm Martin Hoffmeister <eth...@ho...> writes: > Hello , > > etherboot 5.1.7 (as taken from CVS this evening) does NOT compile > for me (reference: download from CVS at 20:45 GMT). That's what my > linux tells me (gcc version 2.95.3, kernel SuSE 2.4.18 [sorry]) > > anselm-31:/home/anselm/etherboot/etherboot-5.1/src # make bin32/rtl8139.lilo > as -o bin/liloprefix.o bin/liloprefix.s > ld -Ttext 0x10000 --oformat binary -o bin/liloprefix.bin bin/liloprefix.o > ld: warning: cannot find entry symbol _start; defaulting to 00010000 > bin/liloprefix.o: In function `bootsector': > bin/liloprefix.o(.text+0x1): relocation truncated to fit: R_386_16 text > bin/liloprefix.o: In function `go': > bin/liloprefix.o(.text+0x19): relocation truncated to fit: R_386_16 text > make: *** [bin/liloprefix.bin] Error 1 > rm bin/liloprefix.o > anselm-31:/home/anselm/etherboot/etherboot-5.1/src # > > Does that mean "relocation =^= work in progress"? > > BTW Found this while entering changes into rtl8139.c, for multicast > support with that nic (Hi Deng Zhiguo :-) but wanted to test-run > before commiting to CVS... Hmm. It looks like I have probably done something that broke the lilo prefix. The relocation warnings mean ld doesn't like it. I can reproduce it here, but I'm not quite ready to track down what happened. I have been tracking a really iritating BIOS bug all weekend that looks like it will turn out to be a problem with supplying power to the machines. Anyway the multicast code works great when booting a 1000 node cluster. Now if all of the other issues were ironed out. Eric |
53 messages has been excluded from this view by a project administrator.
