etherboot-developers Mailing List for Etherboot (Page 213)
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: Timothy L. <tl...@ro...> - 2003-02-09 13:22:06
|
> Tim, > > What's the status of sundance.c? I'm planning to do a release of 5.1.6 > in a couple of days. Hi Ken I just checked in some changes that seem to resolve the issues that I introduced in the sundance 1.2 file version. It is still insanely slow, but it will correctly download its own rom. There do seem to be issues with the disable that I will review. Tim |
|
From: Timothy L. <tl...@ro...> - 2003-02-09 13:21:48
|
> Tim, > > What's the status of sundance.c? I'm planning to do a release of 5.1.6 > in a couple of days. Hi Ken I just checked in some changes that seem to resolve the issues that I introduced in the sundance 1.2 file version. It is still insanely slow, but it will correctly download its own rom. There do seem to be issues with the disable that I will review. Tim |
|
From: Timothy L. <tl...@ro...> - 2003-02-09 02:39:07
|
Hi Since I am not familiar with the output of tcpdump, I thought I would post a tcpdump file for review. Please let me know if you see anything that might indicate the issue. Tim |
|
From: <ebi...@ln...> - 2003-02-09 01:36:35
|
ke...@us... writes:
> Eric,
>
> How about this scheme?
>
> Define a macro with a distinctive name, say PCI_ID_ENTRY like this.
>
> #define PCI_ID_ENTRY(a,b,c) {a,b,c}
>
> Then use this macro in all the drivers like this:
>
> PCI_ID_ENTRY(PCI_VENDOR_ID_INTEL,PCI_DEVICE_ID,INTEL_82557,"Intel
> EtherExpressPro100"),
>
> PCI_ID_ENTRY(...),
> ...
>
> Or just use the bare numbers. This allows grep or a perl script to
> extract all the IDs to create the file NIC. If the symbolic names are
> used, then preprocess the output against pci.h using cpp.
That sounds reasonable.
A couple of things. I believe the NIC file still needs
to contain the list of drivers.
The filename for the driver with a particular compile option
needs to be in the table entry. We can replace the long
text string we currently have in the table, with the filename,
as we do not use the long string, and it just takes up space.
Unless I am mistaken the existing tables in the code should
be distinctive enough that a small perl script can parse them
out without the use of a special macro.
Additionally we should be able to get the list of isa drivers,
from a driver file as well.
Eric
|
|
From: <ke...@us...> - 2003-02-08 13:47:27
|
Eric,
How about this scheme?
Define a macro with a distinctive name, say PCI_ID_ENTRY like this.
#define PCI_ID_ENTRY(a,b,c) {a,b,c}
Then use this macro in all the drivers like this:
PCI_ID_ENTRY(PCI_VENDOR_ID_INTEL,PCI_DEVICE_ID,INTEL_82557,"Intel EtherExpressPro100"),
PCI_ID_ENTRY(...),
...
Or just use the bare numbers. This allows grep or a perl script to
extract all the IDs to create the file NIC. If the symbolic names are
used, then preprocess the output against pci.h using cpp.
|
|
From: <ke...@us...> - 2003-02-07 23:26:26
|
>For the development release, 5.1.5, I made also >a patch for supporting a VIA6105 chip with PCI ID 0x3106 Checked in. Thanks. >It is not tested, because I was not able to build a testfloppy. >(the 5.0.8 is test due the better documation ;-) Mmm, we have to do something about doco sometime. |
|
From: <ke...@us...> - 2003-02-07 23:10:41
|
>The via-rhine.c supports one more type of PCI NIC > >Below is patch against 5.0.8 where it is tested. >( a 5.1.5 will follow ) > >Could some apply it? Done. Thanks. |
|
From: <ebi...@ln...> - 2003-02-07 21:05:49
|
Gee...@xs... (Geert Stappers) writes: > Hello, > > For the development release, 5.1.5, I made also > a patch for supporting a VIA6105 chip with PCI ID 0x3106 > > It is not tested, because I was not able to build a testfloppy. > (the 5.0.8 is test due the better documation ;-) make bin/???.fd0 should work... Eric |
|
From: <Gee...@xs...> - 2003-02-07 16:08:59
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
For the development release, 5.1.5, I made also
a patch for supporting a VIA6105 chip with PCI ID 0x3106
It is not tested, because I was not able to build a testfloppy.
(the 5.0.8 is test due the better documation ;-)
Could some apply the patch to the main source?
Kind regards
Geert Stappers
diff -urN --exclude-from excludelist etherboot-5.1.5/LOG etherboot-5.1.5GSt/LOG
- --- etherboot-5.1.5/LOG Tue Jan 7 16:04:52 2003
+++ etherboot-5.1.5GSt/LOG Fri Feb 7 15:59:26 2003
@@ -2408,3 +2408,8 @@
+ Eric rearranged files for multiple platforms, including Itanium.
Released as Etherboot 5.1.4 (development)
+
+5.1.5 tarball ???
+
++ Geert Stappers found a VIA6105 (via-rhine.c) with id 0x3106.
+ altered the version text
diff -urN --exclude-from excludelist etherboot-5.1.5/README etherboot-5.1.5GSt/README
- --- etherboot-5.1.5/README Thu Jan 1 01:00:00 1970
+++ etherboot-5.1.5GSt/README Wed Feb 5 22:26:53 2003
@@ -0,0 +1,5 @@
+
+ There is a documentation directory called "doc".
+ People using development versions,
+ should download the etherboot-doc-X.Y.Z.tar.gz with the doc directory
+
diff -urN --exclude-from excludelist etherboot-5.1.5/src/drivers/net/via-rhine.c etherboot-5.1.5GSt/src/drivers/net/via-rhine.c
- --- etherboot-5.1.5/src/drivers/net/via-rhine.c Fri Dec 27 13:38:46 2002
+++ etherboot-5.1.5GSt/src/drivers/net/via-rhine.c Fri Feb 7 15:47:26 2003
@@ -21,7 +21,7 @@
*/
- -static const char *version = "rhine.c v1.0.0 2000-01-07\n";
+static const char *version = "rhine.c v1.0.1 2003-02-06\n";
/* A few user-configurable values. */
@@ -619,9 +619,6 @@
*/
- -#define PCI_VENDOR_ID_FET 0x1106
- -#define PCI_DEVICE_ID_FET_3043 0x3043
- -
/* The rest of these values should never change. */
#define NUM_TX_DESC 2 /* Number of Tx descriptor registers. */
@@ -1177,6 +1174,8 @@
static struct pci_id rhine_nics[] = {
{ PCI_VENDOR_ID_VIATEC, PCI_DEVICE_ID_VIA_VT6102,
"VIA 6102" },
+ { PCI_VENDOR_ID_VIATEC, PCI_DEVICE_ID_VIA_VT6105,
+ "VIA 6105" },
{ PCI_VENDOR_ID_VIATEC, PCI_DEVICE_ID_VIA_RHINE_I,
"VIA 3043" },
{ PCI_VENDOR_ID_VIATEC, PCI_DEVICE_ID_VIA_86C100A,
diff -urN --exclude-from excludelist etherboot-5.1.5/src/include/pci_ids.h etherboot-5.1.5GSt/src/include/pci_ids.h
- --- etherboot-5.1.5/src/include/pci_ids.h Wed Jan 8 06:14:38 2003
+++ etherboot-5.1.5GSt/src/include/pci_ids.h Wed Feb 5 16:06:25 2003
@@ -965,6 +965,7 @@
#define PCI_DEVICE_ID_VIA_VT6102 0x3065
#define PCI_DEVICE_ID_VIA_82C686_6 0x3068
#define PCI_DEVICE_ID_VIA_8233_0 0x3074
+#define PCI_DEVICE_ID_VIA_VT6105 0x3106
#define PCI_DEVICE_ID_VIA_8233C_0 0x3109
#define PCI_DEVICE_ID_VIA_8633_0 0x3091
#define PCI_DEVICE_ID_VIA_8367_0 0x3099
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAj5D2ewACgkQ91HXn1UReY+HpgCfX337Tsx/OLDYhm3XbVs8hYOO
GhMAn3s0YvaQMuJnmQrYmlcxZO4MES2S
=/b52
-----END PGP SIGNATURE-----
|
|
From: <Gee...@xs...> - 2003-02-07 15:52:44
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
The via-rhine.c supports one more type of PCI NIC
Below is patch against 5.0.8 where it is tested.
( a 5.1.5 will follow )
Could some apply it?
Kind Regards Geert Stappers
diff -urN --exclude-from excludelist etherboot-5.0.8/LOG etherboot-5.0.8GSt/LOG
- --- etherboot-5.0.8/LOG Sun Nov 3 12:52:41 2002
+++ etherboot-5.0.8GSt/LOG Wed Feb 5 19:29:57 2003
@@ -2423,3 +2423,6 @@
main and .rodata. Anybody with a 286 CPU deserves what they get.
Released as Etherboot 5.0.8 (production)
+
++ Geert Stappers found a VIA6105 (via-rhine.c) with id 0x3106.
+
diff -urN --exclude-from excludelist etherboot-5.0.8/src/NIC etherboot-5.0.8GSt/src/NIC
- --- etherboot-5.0.8/src/NIC Sun Nov 3 09:18:21 2002
+++ etherboot-5.0.8GSt/src/NIC Wed Feb 5 19:14:42 2003
@@ -148,6 +148,7 @@
# Rhine-II
via-rhine-old 0x1106,0x6100 VIA 86C100A
via-rhine 0x1106,0x3065 VIA 6102
+via-rhine-6105 0x1106,0x3106 VIA 6105
family w89c840
winbond840 0x1050,0x0840 Winbond W89C840F
diff -urN --exclude-from excludelist etherboot-5.0.8/src/via-rhine.c etherboot-5.0.8GSt/src/via-rhine.c
- --- etherboot-5.0.8/src/via-rhine.c Sat Jun 22 10:48:08 2002
+++ etherboot-5.0.8GSt/src/via-rhine.c Wed Feb 5 18:23:02 2003
@@ -620,9 +620,6 @@
*/
- -#define PCI_VENDOR_ID_FET 0x1106
- -#define PCI_DEVICE_ID_FET_3043 0x3043
- -
/* The rest of these values should never change. */
#define NUM_TX_DESC 2 /* Number of Tx descriptor registers. */
diff -urN --exclude-from excludelist etherboot-5.0.8/src/via-rhine_ids.h etherboot-5.0.8GSt/src/via-rhine_ids.h
- --- etherboot-5.0.8/src/via-rhine_ids.h Sun Nov 3 09:19:07 2002
+++ etherboot-5.0.8GSt/src/via-rhine_ids.h Wed Feb 5 19:14:45 2003
@@ -3,4 +3,5 @@
{ 0x1106,0x3065, "VIA 6102" },
{ 0x1106,0x6100, "VIA 86C100A" },
{ 0x1106,0x3065, "VIA 6102" },
+ { 0x1106,0x3106, "VIA 6105" },
};
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAj5D1c4ACgkQ91HXn1UReY9k8QCfQrS6ojPFtutBm2KCGe1HY6r0
myYAn1mW6V8O0BU/N3ySU8bazkxEXY1Y
=hIuK
-----END PGP SIGNATURE-----
|
|
From: Timothy L. <tl...@ro...> - 2003-02-07 10:57:44
|
> What's the status of sundance.c? I'm planning to do a release of 5.1.6 > in a couple of days. The damn thing is giving me nightmares :-( I have tried everything I can think of, reviewed the code a number of times, but it just seems to be too slow. I am sure there is something I am missing, but I am not sure what. I did send a copy of the card to Marty, so I am hoping that he will be able to help find the problem when he has time. Tim |
|
From: <ke...@us...> - 2003-02-07 02:43:19
|
Tim, What's the status of sundance.c? I'm planning to do a release of 5.1.6 in a couple of days. |
|
From: <ebi...@ln...> - 2003-02-06 13:55:24
|
ke...@us... (Ken Yap) writes:
> >I have working Hammer support in etherboot.
> >
> >Meaning I have added CONFIG_X86_64 to the i386 etherboot port.
> >
> >When enabled I can:
- Detect you are on a x86_64 capable processor.
> >- boot 64bit binaries that are loaded within the first 4GB of ram.
> >- Advertise that I can boot 64bit binaries.
But only when you are on a x86_64 capable processor.
> >- Build etherboot as a 64bit elf binary. (suffixes .lmelf, .zlmelf)
> >
> >Hopefully I will get this checked in tommorrow, It is time for me
> >to go home now.
>
> Oh yum yum, I was getting itchy to make another 5.1 release.
The code is now committed.
When enabled the binary grows by about 300 bytes, and the bss grows by
about 32K, so I have enough space to statically allocate a page table
covering 4GB of addresses.
Now if this cold will give me a break so I can get some sleep...
Eric
|
|
From: <ke...@us...> - 2003-02-06 10:07:04
|
>I have working Hammer support in etherboot. > >Meaning I have added CONFIG_X86_64 to the i386 etherboot port. > >When enabled I can: >- boot 64bit binaries that are loaded within the first 4GB of ram. >- Advertise that I can boot 64bit binaries. >- Build etherboot as a 64bit elf binary. (suffixes .lmelf, .zlmelf) > >Hopefully I will get this checked in tommorrow, It is time for me >to go home now. Oh yum yum, I was getting itchy to make another 5.1 release. |
|
From: <ebi...@ln...> - 2003-02-06 05:59:12
|
I have working Hammer support in etherboot. Meaning I have added CONFIG_X86_64 to the i386 etherboot port. When enabled I can: - boot 64bit binaries that are loaded within the first 4GB of ram. - Advertise that I can boot 64bit binaries. - Build etherboot as a 64bit elf binary. (suffixes .lmelf, .zlmelf) Hopefully I will get this checked in tommorrow, It is time for me to go home now. Eric |
|
From: <ebi...@ln...> - 2003-02-05 19:26:07
|
"Ronald G. Minnich" <rmi...@la...> writes: > sorry to ask this, but google and the manuals don't help. I've forgotten > how to specify an etherboot image for, e.g., e1000+ide. I.e. what's the > makefile pattern. > > Also is a .zimg now a compressed ELF image, or how do you get such? > Version is 5.1.5 .zelf make bin/e1000--ide_disk.zelf Eric |
|
From: Ronald G. M. <rmi...@la...> - 2003-02-04 22:03:45
|
sorry to ask this, but google and the manuals don't help. I've forgotten how to specify an etherboot image for, e.g., e1000+ide. I.e. what's the makefile pattern. Also is a .zimg now a compressed ELF image, or how do you get such? Version is 5.1.5 ron |
|
From: <ebi...@ln...> - 2003-02-04 21:30:42
|
"Timothy Legge" <tim...@us...> writes: > > Good news, bad news. I have managed to reproduce the problem on a k8 > > system, > > so it is not a 486 problem. Probably something to do interactions > > with the old award BIOS core, which it appears my reference system is > > using... > > That is good news. I will confirm the bios. Unfortunately it was a false positive. I had a bootloader in front of etherboot and it was providing a broken IDT (interrupt descriptor table) to etherboot. And this caused the interrupts to fail, when they happened. This is not your problem because 5.0.x would have failed under these conditions as well. I do have a 486 at home (but it's power supply is failing) if I can get it to boot I will see if I can reproduce this problem there. Eric |
|
From: <ke...@us...> - 2003-02-04 10:35:40
|
>> >It is possible to further modify the MBA probe code to support an MBA only >> >boot, but I do not have the time (nor the mandate :) to do that at >> >present. Ah ok, you developed this for booting NBI images converted with imggen. Pity, I was hoping for a MBA loader. I'll put your patch in the patch area on the Sourceforge site in case somebody has the same requirements as you. If you get the time to do the MBA loader, do post. Thanks! |
|
From: Michael G. <mge...@so...> - 2003-02-03 22:14:01
|
> >Aha! Good question. Short answer: interoperability. > > > >Long answer: I have an embedded system with legacy components which > >boot using 3Com MBA ROMs. I am designing replacement components which we > >do not want to purchase rolls of 3Com ROMs for. Instead we've elected to > >go with etherboot. However, one of the requirements is that the new and > >legacy components must be able to coexist with no changes to the boot > >server, hence the preceeding patch. > > > >It is possible to further modify the MBA probe code to support an MBA only > >boot, but I do not have the time (nor the mandate :) to do that at > >present. > > > >Thanks for your interest! > > I'm kind of tickled by the idea of booting MBA images on non-3Com > hardware. I'm like E&E just as much as M$ as long as it's FLOSS that's > doing E&E. :-) > > I am willing to accept the patch provided: > > 1. It's enclosed in suitable #ifdefs so that not selecting the MBA > option costs nothing. Uhuh. I will rework the $ifdefs to make it so. > 2. Your contact address is inserted somewhere so that if someone has a > query or wants to improve the code, they can contact you. It would be > nice if you could continue to maintain it, but I understand that people > move on to other projects. Just as long as someone can email you and you > can tell them: yes that is the right fix, or sorry I'm no longer > maintaining it, UTSL, and it's yours to maintain should you choose to > accept the mission. I should have this assigned as a maintenance task for the foreseeable future and will add my contact info. > I'll have a look over the code later. My body time is still somewhere in > the ocean. Thanks! > --__--__-- > ke...@us... (Ken Yap) writes: > > > I'll have a look over the code later. My body time is still somewhere in > > the ocean. > > Ken look carefully. The code currently requires a tagged image with > an MBA header. I am not certain if anyone else can do anything useful > with a hybrid like that. > > Eric Both the probe and download functions have been added to support this hybrid header. It is true that currently most of the code in these functions is occupied with stripping off the MBA header and then arranging the remaining tag so that it is palatable to the tagged probe function. However, there's nothing stopping someone with more ambition from changing these functions to do the download themselves. The problem lies in extracting the required fields from the MBA header. All I needed for this simple mod was the identification string and header size fields. However, examining the decompiled imggen binary in more detail would reveal the necessary fields for booting a non nbi tagged kernel. |
|
From: <ebi...@ln...> - 2003-02-03 19:50:47
|
ke...@us... (Ken Yap) writes: > I'll have a look over the code later. My body time is still somewhere in > the ocean. Ken look carefully. The code currently requires a tagged image with an MBA header. I am not certain if anyone else can do anything useful with a hybrid like that. Eric |
|
From: <ke...@us...> - 2003-02-03 02:14:08
|
>I have a ADMtek an983 chip,I can download a win98 image and start it;But
>when I restart from windows and reboot the pc, the etherboot report "The
>Tulip chip at %X is not functioning"; then I debug it at :
> if (inl(ioaddr + CSR5) == 0xFFFFFFFF) {
> printf("%s: The Tulip chip at %X is not functioning.\n",
> tp->nic_name, ioaddr);
> return 0;
> }
>then I power off and power on ,it can go correctly; But when I restart from
>windows,problem again!
Seems to be Windows leaving the NIC controller in a particular state.
See if you can fix the reset code to completely reset the NIC
controller. Does the problem happen with booting Linux (not netbooted)?
If not, see if the Linux tulip driver does more to reset the chip and
steal the code.
|
|
From: <ke...@us...> - 2003-02-03 02:04:04
|
>Aha! Good question. Short answer: interoperability. > >Long answer: I have an embedded system with legacy components which >boot using 3Com MBA ROMs. I am designing replacement components which we >do not want to purchase rolls of 3Com ROMs for. Instead we've elected to >go with etherboot. However, one of the requirements is that the new and >legacy components must be able to coexist with no changes to the boot >server, hence the preceeding patch. > >It is possible to further modify the MBA probe code to support an MBA only >boot, but I do not have the time (nor the mandate :) to do that at >present. > >Thanks for your interest! I'm kind of tickled by the idea of booting MBA images on non-3Com hardware. I'm like E&E just as much as M$ as long as it's FLOSS that's doing E&E. :-) I am willing to accept the patch provided: 1. It's enclosed in suitable #ifdefs so that not selecting the MBA option costs nothing. 2. Your contact address is inserted somewhere so that if someone has a query or wants to improve the code, they can contact you. It would be nice if you could continue to maintain it, but I understand that people move on to other projects. Just as long as someone can email you and you can tell them: yes that is the right fix, or sorry I'm no longer maintaining it, UTSL, and it's yours to maintain should you choose to accept the mission. I'll have a look over the code later. My body time is still somewhere in the ocean. |
|
From: Helen B. <se...@co...> - 2003-02-02 08:28:59
|
Hi, I thought you might be interested in getting in-depth knowledge about your web audience and web traffic patterns in a reliable and cost-effective way. Stop Guessing - Start Knowing! - CoolStats measures web site traffic and online behavior of your visitors. - CoolStats will help you understand how to optimize your site to meet the needs of your visitors. - You get access to detailed, real-time statistical analysis of your web pages - 24 hours a day. Click at http://www.coolstats.com/viewdemo/index.html to view Online Demo. - CoolStats is the ultimate real-time tracking solution for small and mid-sized businesses. - 100% accuracy by measuring activity at the client, not via server based log files. - The fee of $24.95 is minimal compared to what it would cost you to run a tracking service yourself! Why CoolStats? - no programming to do - no servers to maintain - no software applications to install Click at http://p1j2m3a4.pdhost.com/pdsvr/www/r?1000016203.1392.15.Gre6Gjq8g4bCuG to Sign Up now! "We needed to make business sense out of our web visitor behavior - CoolStats delivers first-class graphical reports that help us continuously improve and optimize our website to match the requirements of our target audience." BRYAN KASHILIN, BOSTON Click at http://www.coolstats.com/product/customerref.html to check what other customers say about us! For more information about our website tracking services, please visit our website or contact me directly at the below email. I look forward to hearing from you soon. Best regards, Helen Baker CoolStats Support Email: hel...@co... Http://www.coolstats.com Don't be the last one to know! ----------------------------------------------------------------------- This message has been brought to eth...@li.... If you do not wish to receive anymore emails, please follow the opt-out instruction below. We apologize for any inconvenience. |
|
From: Timothy L. <tim...@us...> - 2003-01-31 23:39:00
|
> Good news, bad news. I have managed to reproduce the problem on a k8 > system, > so it is not a 486 problem. Probably something to do interactions > with the old award BIOS core, which it appears my reference system is > using... That is good news. I will confirm the bios. |
53 messages has been excluded from this view by a project administrator.
