Soyo Dragon KT400 - Not Recommended
Felix Miata
have abandoned that idea. It has IRQ issues when trying to fill the PCI
slots. Every device has to share an IRQ with one of the USB devices on
the board. This means OS/2 won't boot unless in the BIOS assigning IRQs
to USB is turned off, or certain devices are removed from the PCI slots.
Anyone who wants details on this can find it on the Scitech news server
in scitech.snap.graphics.os2 in the thread "SDD Pro 7.1 & LSI SCSI
Together Won't Boot".
--
"The object and practice of liberty lies in the limitation of
governmental power." General Douglas MacArthur
Team OS/2 ** Reg. Linux User #211409
Felix Miata *** http://members.ij.net/mrmazda/
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Scott G.
>Every device has to share an IRQ with one of the USB devices on
>the board. This means OS/2 won't boot unless in the BIOS assigning IRQs
>to USB is turned off, or certain devices are removed from the PCI slots.
I imagine this would be fixed by applying the os2ldr from one of the more
recent (say 12/2003) "testcase kernels".
Felix Miata
The one failing was from 27 Oct. The last I downloaded was 13 Nov. The
newest on eCS FTP is dated 26 Nov but contains 13 Nov. There are none on
testcase now, and I don't know anyplace that captures and saves them for
those of us who don't visit testcase often. :-(
dave
Put XP on this board, it ROCKS!!
Dave
dave
Put XP on this board, it ROCKS !!
Dave
William L. Hartzell
Felix Miata wrote:
> "Scott G." wrote:
>
>
>>On Thu, 08 Jan 2004 11:47:28 -0500, Felix Miata wrote:
>
>
>
>>>Every device has to share an IRQ with one of the USB devices on
>>>the board. This means OS/2 won't boot unless in the BIOS assigning IRQs
>>>to USB is turned off, or certain devices are removed from the PCI slots.
>
>
>>I imagine this would be fixed by applying the os2ldr from one of the more
>>recent (say 12/2003) "testcase kernels".
>
>
> The one failing was from 27 Oct. The last I downloaded was 13 Nov. The
> newest on eCS FTP is dated 26 Nov but contains 13 Nov. There are none on
> testcase now, and I don't know anyplace that captures and saves them for
> those of us who don't visit testcase often. :-(
<http://www.os2site.com/sw/upgrades/kernel/w420031113.zip>
--
Bill
Thanks a Million!
William L. Hartzell
About as helpful comment as saying eat bog poop.
Felix Miata
> Felix Miata wrote:
> > "Scott G." wrote:
> >>On Thu, 08 Jan 2004 11:47:28 -0500, Felix Miata wrote:
> >>>Every device has to share an IRQ with one of the USB devices on
> >>>the board. This means OS/2 won't boot unless in the BIOS assigning IRQs
> >>>to USB is turned off, or certain devices are removed from the PCI slots.
> >>I imagine this would be fixed by applying the os2ldr from one of the more
> >>recent (say 12/2003) "testcase kernels".
Looks like "recent" means sometime in December, as opposed to
> > The one failing was from 27 Oct. The last I downloaded was 13 Nov. The
> > newest on eCS FTP is dated 26 Nov but contains 13 Nov. There are none on
> > testcase now, and I don't know anyplace that captures and saves them for
> > those of us who don't visit testcase often. :-(
> <http://www.os2site.com/sw/upgrades/kernel/w420031113.zip>
November. I had since found that. 20031113 is 14.096e, which works no
differently than what I had. :-(
William L. Hartzell
Felix Miata wrote:
> "William L. Hartzell" wrote:
>
>
>>Felix Miata wrote:
>
>
>>>"Scott G." wrote:
>
>
>>>>On Thu, 08 Jan 2004 11:47:28 -0500, Felix Miata wrote:
>
>
>>>>>Every device has to share an IRQ with one of the USB devices on
>>>>>the board. This means OS/2 won't boot unless in the BIOS assigning IRQs
>>>>>to USB is turned off, or certain devices are removed from the PCI slots.
>
>
>>>>I imagine this would be fixed by applying the os2ldr from one of the more
>>>>recent (say 12/2003) "testcase kernels".
>
>
> Looks like "recent" means sometime in December, as opposed to
>
>
>>>The one failing was from 27 Oct. The last I downloaded was 13 Nov. The
>>>newest on eCS FTP is dated 26 Nov but contains 13 Nov. There are none on
>>>testcase now, and I don't know anyplace that captures and saves them for
>>>those of us who don't visit testcase often. :-(
>
>
>><http://www.os2site.com/sw/upgrades/kernel/w420031113.zip>
>
>
> November. I had since found that. 20031113 is 14.096e, which works no
> differently than what I had. :-(
That site would have any more recent testcase kernel, if they exist. I
was busy in December and may have missed one being posted.
Richard Steiner
>Put XP on this board, it ROCKS !!
XP has some merit, but its OS/2 application support is sadly lacking.
--
-Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
OS/2 + eCS + Linux + Win95 + DOS + PC/GEOS + Executor = PC Hobbyist Heaven!
Applications analyst/designer/developer (14 yrs) seeking employment.
See web site above for resume/CV and background.
Daniel Krueger
> I was going to use this VIA KT400 chipset motherboard for eCS 1.1, but
> have abandoned that idea. It has IRQ issues when trying to fill the PCI
> slots. Every device has to share an IRQ with one of the USB devices on
> the board. This means OS/2 won't boot unless in the BIOS assigning IRQs
> to USB is turned off, or certain devices are removed from the PCI slots.
This is true for all VIA chipsets. The culprit is the int line to IRQ
mapping. There exists online 4 interrupt lines in the VIA chipsets.
Check PCI programm with parameter -p from Craig Hart ported from Veit
Kannegieser.
The solution is to use SiS chipsets. These have 8 interrupt lines. All
USB controllers have completely different int lines. Now there are only
not enough IRQs, and the INT-IRQ mapping from the Bios is not so good.
But SPCIIRQ driver helps. I've tested this on an Asrock K7S8E 3.0 mainboard.
cu
Daniel
Scott
> November. I had since found that. 20031113 is 14.096e, which works no
> differently than what I had. :-(
The Real OS/2 Guy
SiS is NO solution at all. Ever tried to use sis900 and USB in
parallel? USB won't work, NIC can't hold a connection. CRAP.
Yes, I've here some mainboards with SiS chipset running. They are all
problematic even when USB is NOT decativated in BIOS when you have to
run the on board NIC.
Sure, there is a BETA NIC that knows to handle that problem - but it
is BETA and nobody (including the developer) knows when it gets GA. As
the developer gets NOT payed he can use only his spare free time to
work on - so it would be a long time until the driver gets finished.
--
Tschau/Bye
Herbert
Visit http://www.ecomstation.de the home of german eComStation
MMI
> Felix Miata schrieb:
> > I was going to use this VIA KT400 chipset motherboard for eCS 1.1, but
> > have abandoned that idea. It has IRQ issues when trying to fill the PCI
> > slots. Every device has to share an IRQ with one of the USB devices on
> > the board. This means OS/2 won't boot unless in the BIOS assigning IRQs
> > to USB is turned off, or certain devices are removed from the PCI slots.
>
> This is true for all VIA chipsets. The culprit is the int line to IRQ
> mapping. There exists online 4 interrupt lines in the VIA chipsets.
> Check PCI programm with parameter -p from Craig Hart ported from Veit
> Kannegieser.
Not so. I have two Asus A7V333 boards (with VIA KT333), but they are a
bit different beasts, since one features AC'97 soundcard and LAN NIC,
the other AC'97 soundcard and Promise RAID. One of them puts USB
device on all except one PCI slot, the other hooks all USB devices
onto one IRQ. Both have the same KT333 chipset, but they behave
differently. Perhaps BIOS revision issue?
Cheers,
Martin
Daniel Krueger
>
> SiS is NO solution at all. Ever tried to use sis900 and USB in
> parallel? USB won't work, NIC can't hold a connection. CRAP.
I didn't use the onboard NIC, because we're using old BNC cable.
> Yes, I've here some mainboards with SiS chipset running. They are all
> problematic even when USB is NOT decativated in BIOS when you have to
> run the on board NIC.
>
> Sure, there is a BETA NIC that knows to handle that problem - but it
> is BETA and nobody (including the developer) knows when it gets GA. As
> the developer gets NOT payed he can use only his spare free time to
> work on - so it would be a long time until the driver gets finished.
It's beta, but if it works it's OK. Though I must say I didn't test
neither the onboard NIC as I mentioned above nor the beta driver.
cu
Daniel
Daniel Krueger
> Daniel Krueger <daniel....@web.de> wrote in message news:<btsmln$avp$1...@anderson.hrz.tu-chemnitz.de>...
>
>>mapping. There exists online 4 interrupt lines in the VIA chipsets.
>>Check PCI programm with parameter -p from Craig Hart ported from Veit
>>Kannegieser.
>
> Not so. I have two Asus A7V333 boards (with VIA KT333), but they are a
> bit different beasts, since one features AC'97 soundcard and LAN NIC,
> the other AC'97 soundcard and Promise RAID. One of them puts USB
> device on all except one PCI slot, the other hooks all USB devices
> onto one IRQ. Both have the same KT333 chipset, but they behave
> differently. Perhaps BIOS revision issue?
Maybe my statement was too strict. I read this on a mainboard page. And
saw it on an Asrock K7VT2 board with VIA KT266.
The problem is, that there is no internet site where you can see the PCI
routing table in advance before buying the board. And the mainboard
manufacturer doesn't write such things in their manuals.
cu
Daniel
Veit Kannegieser
> The problem is, that there is no internet site where you can see the PCI
> routing table in advance before buying the board. And the mainboard
> manufacturer doesn't write such things in their manuals.
Does not help in most cases, but you can view the routing table by
downloading a 'bios update' and unpacking it.
most easy for Award BIOS:
awardeco 4saw53.bin - or LH(a)/ModBin
show_pir original.tmp
Veit Kannegieser
Greg B
> MMI schrieb:
> Maybe my statement was too strict. I read this on a mainboard page. And
> saw it on an Asrock K7VT2 board with VIA KT266.
>
> The problem is, that there is no internet site where you can see the PCI
> routing table in advance before buying the board. And the mainboard
> manufacturer doesn't write such things in their manuals.
Well, it's more of a chipset issue...given chipsets work pretty much
the same in this regard, no matter what they are soldered into.
So it would likely be useful for groups who support various OSes
to figure out which chipsets are likely to work, and stick with
those. Even if the mainboard isn't known to work, if its chipset
works elsewhere it's likely a good bet.
Greg
Leo Tick
buy may new MB
The Real OS/2 Guy
> so how can I find out which chip set is ok for OS/2 so I can
> buy may new MB
>
It's simple. When you likes to have the on board sound working avoid a
board with SiS chipset, prefere any with VIA chipset - else does'nt
matter, get what you like.
Greg B
> so how can I find out which chip set is ok for OS/2 so I can
> buy may new MB
I believe it's called 'research.' Look around the mainboard and os/2
newsgroups (and perhaps the OS/2 web sites) and see what other people
are using satisfactorily. Either buy one of those (known quantity)
or one with the same chipset (lesser known quantity, but a good bet).
Greg
Daniel Krueger
>
> board with SiS chipset, prefere any with VIA chipset - else does'nt
> matter, get what you like.
I've here an Asrock K7S8XE 3.0 with SiS 748 chipset.
And it plays sound via the onboard AC97 codec chip vom CMedia with
UNIAUD driver flawlessly (with Media-Folder from Chris Wohlgemuth). And
it wasn't necessery to change any drivers, only plug in my old hard disk
and boot eCS (UNIAUD was used before for an sound card with CMI8737 chip).
USB also works (tested with USB CF card reader).
And concerning VIA chipsets, I definitly not recommend the Asrock K7VT2
with VIA KT266 chipset. There each PCI slot shares an interrupt with one
USB controller. The only solution to get an unshared interrupt is in not
using the EHCI USB controller and additional UHCI USB controllers if you
need even more unshared interrupts (That meens don't install the
respective device drivers).
cu
Daniel
Daniel Krueger
>
> awardeco 4saw53.bin - or LH(a)/ModBin
> show_pir original.tmp
Thank you for the hint.
I only used pci.exe or show_pir so far.
I will try it out.
cu
Daniel
Felix Miata
> so how can I find out which chip set is ok for OS/2 so I can
> buy may new MB
IBM seems to focus its development efforts on (surprise surprise) Intel,
so if you have to gamble on something unknown, Intel is probably your
best bet. OTOH, virtually every install tip for VIA recommends the first
thing to do after installing windoze is to install the VIA 4-in-1
drivers, which seems to say something VIA should be providing in
hardware is instead found only in driver software, which for OS/2 is
liable to be delayed, if it ever happens at all.
William L. Hartzell
Felix Miata wrote:
> Leo Tick wrote:
>
>
>>so how can I find out which chip set is ok for OS/2 so I can
>>buy may new MB
>
>
> IBM seems to focus its development efforts on (surprise surprise) Intel,
> so if you have to gamble on something unknown, Intel is probably your
> best bet. OTOH, virtually every install tip for VIA recommends the first
> thing to do after installing windoze is to install the VIA 4-in-1
> drivers, which seems to say something VIA should be providing in
> hardware is instead found only in driver software, which for OS/2 is
> liable to be delayed, if it ever happens at all.
The truth is closer to the fact that Microsoft supports Intel chipsets,
just as IBM does. Being different, Via must add in their own drivers,
that otherwise are bundled with the operating system. This means that
for OS/2, we must depend upon backdoor support by interested third
parties and independent developers. OS/2 biggest problem is getting the
various chip makers to supply their data sheets to these entities.
Felix Miata
> Sorry!
No help from Friday's 14.097d kernel & loader either. :-(