• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

Medion Akoya (MSI Wind) netbook and eComStation

Started by Shai, 2008.07.03, 11:46:10

Previous topic - Next topic

Sigurd

Big, big thank to Robert Lalla! He made the resolution 1024X600 availiable for this (and possible a lot of other) 10' Netbooks!

One should use the widescreen 0.74 driver, and will get this:

http://www.commtalk.org/FileRepository/ForumAttachments/54-75933-Akoyaw2.JPG

This is really fantastic! This is really a difference to the EEE 701.

So is there anybody who can help us finding a solution for the usbd.sys?

This would be great!!!

Cheers


Sigurd

SMP - thats Okay!

Just to inform: SMP (not tested together with APIC) works fine here.

Please look:

http://www.commtalk.org/FileRepository/ForumAttachments/54-75943-Akoyaw3.JPG

Cheers

Saijin_Naib

Hey Sigurd, do you know if the new Widescreen driver will activate 1024x800 on a VIA Chrome chipset? I am tempted to get a Sylvania G Netbook, but I NEED native display resolution through Panorama.

Sigurd

Hey,

I don't know exactly, as far as I can see the widescreen is only working with ATOM Bios (ATI Chipset) and INTEL Bios. You may ask Eugene Gorbunow or Robert Lalla for further information. Sorry.

Shai

Are there any benefits in using a SMP kernel on a single-core machine?

But maybe I'll try it, too - just to see whether it changes anything on the USB issue. As far as I know, drivers often tend to make problems with SMP kernels, maybe it's the other way around here.

achain

Hi guys,

Could you try following procedure for your MSI Wind notebooks, and let me know the result?
1. Go to www.os2warp.be and step into Gomi NDIS MAC drivers section, then aquire RTL8169 driver v1.12.
2. Prepare the following text file and put it in the same place of rtgnda.os2, with naming it e.g. patch.txt.
FILE rtgnda.os2
VER 1876 6781
CHA 1876 3681

3. From command prompt, call patch.exe (OS/2's one, not GNU's) with "/A" parameter. e.g. >patch.exe patch.txt /A
4. Install the patched RTL8169 driver as usual.
5. Check the LAN connectivity.

I got the RTL8102E of Intel D945GCLF Atom motherboard working by this procedure. But it fails on Gigabyte GA-GC230D...maybe because the "shutdown" problem.

Shai

Yes, it works - on my machine at least but I don't see any reason that it shouldn't work on other Medion Akoyas. In fact, I'm writing this post on my Medion Akoya in eCS.

So thanks a lot, achain! Where did you get that from or how did you get the idea this might work?
Maybe we could inform the author, so if he's still interested, he can add out-of-the-box support for this chipset in an upcoming version of his driver.
This is indeed good news.

btw. I'm currently running eCS with the SMP kernel and ACPI in APIC mode. So far USB seems to work without any problems but you know it seemed to work before... Two CPUs (hyper-threading?) are detected and displayed and the CPU throttling program finally works - though it doesn't seem to add much to the batteries' life span. VDMs don't work anymore - I'll continue to play around with ACPI to see what effect it has on the USB issue.
Previously - when it didn't work - the reason was that attaching USB devices immediately crashed the system with trap 008. So when you loaded all USB drivers but without the EHCI controller driver (there's an internal USB device attached to that controller - besides the Webcam which only appears in the resource manager if you switch it on via keyboard) it booted fine (dozens of times) and just crashed if you attached an USB device. If you enabled the EHCI controller driver it alreaded crashed before starting PMSHELL, probably because of the already attached device.
btw2. I had to set the "Accept IRQ level > 15" option to "YES" to get the RTL8169 driver to work properly because i'm running in APIC mode.

cheers,
Robin

achain

Robin, I'm glad to hear the result :)

By referring Realtek LAN device driver source code for FreeBSD, all RTLxxxx device control procedure seemed almost common. So I thought that legacy Realtek driver for OS/2 should work if it can detect RTL8102E (PCI ID=10EC:8136). I patched rtsnd323 (RTL8139 driver for OS/2) first to let it detect RTL8102E. But it failed. Driver could be loaded but it said "Cable is disconnected". I almost gave up at that time...but my friend gave me a hint to use the RTL8169 driver instead.

The patch provided in my previous post is just to replace supported device ID 10EC:8167 with 10EC:8136.
My OS/2 MCP2 based web server (www.os2.jp) is running with this driver over 10 days. (HW is Intel D945GCLF Atom motherboard.)
I can say the driver is stable enough.

I can contact the driver author. I will ask him to put the RTL8102E support code in. Or, I can release new driver by myself. I have just succeeded to make the driver from the source code.

Shai

Yes, I see it. "6781"/"3681" is nothing else as 8167h/8136h in little endian.

I also tried the same thing with the RTL8139 driver - however I was even too stupid to find the location of a supported device Id...

I'm still trying to find a way to get the Windows driver of RT8160 to work with Genmac. I think it can be patched, too because there's got to be something preventing it from using the included firmware (or using it at all). Should be possible to find the location ie. the MOV opcode referencing "rt2860.bin" in the disassembled code and look for the responsible code from there going backwards (and replace it e.g. with NOPs). I hope it's all in one function or otherwise I need a stack backtrace or references to that function to find the original one. However I have to find out how addresses are calculated in that kind of Win32 binary first (or find a tool which does that for me). I guess it's not as easy as in DOS .COM files (where I practised my assembly skills last time) - if I recall it correctly, there was just 100h=256 added to the actual position of the data in the COM file because the program's code/data was copied to the position 100h in it's 64kb segment or something like that... Didn't they introduce separate data and code segments in one binary later (EXE) ... crap
Sadly it's not possible to get it to work in "UNSUPPORTED" mode so it can take some time until it is officially supported by Genmac.

cheers,
Robin

rudi

Quote from: achain on 2008.07.23, 18:48:06
I can contact the driver author. I will ask him to put the RTL8102E support code in. Or, I can release new driver by myself. I have just succeeded to make the driver from the source code.

Maybe you can ask why this "Accept IRQ level > 15" option does exist ? I really don't see any
good reason for this and I'm not aware of any other driver using such an option.


achain

Quote from: rudi on 2008.07.23, 23:47:22
Maybe you can ask why this "Accept IRQ level > 15" option does exist ? I really don't see any
good reason for this and I'm not aware of any other driver using such an option.
This is because, as Robin mentioned, APIC interrupt mode allows IRQ to be larger than 15. DaniS506 also supports such high IRQs to adapt to APIC.PSD that come with eCS ACPI support.
High IRQ support for RTL 8169 was added after initial release of the driver. IIRC, the author made it an option for backward compatibility, unlike DaniS506 that expanded IRQ levels without extra options.

rudi

Quote from: achain on 2008.07.24, 08:59:57
IIRC, the author made it an option for backward compatibility

What sense does that make (except adding the possibility for the user to do something
wrong) ?

BTW, for a disk driver it's much more tricky, because the device is active while the system
switches to "high" IRQ mode. IOW, the driver has to handle possible IRQ changes during the
boot process...

achain

Quote from: rudi on 2008.07.24, 16:01:39
What sense does that make (except adding the possibility for the user to do something wrong) ?

No strong reason.

First, Japanese OS/2 users including the author (and me) are still far from high IRQ environment because we don't have eCS Japanese edition in the market yet. He couldn't test the high IRQ support code by himself. Under such situation, his priority could be "no regression" than "new feature".
- I need high IRQ support in your driver.
- Please test my implementation. You can enable it by option parameter.
- It works well.
- Okay I release it (as-is).

And, the default value of the option parameter can be easily changed by modifying rtgnda.nif file with text editor. As mentioned in the document file, author doesn't stop us to modify anything of the driver package and re-release it by ourselves.
So you can go ahead.

Shai

ok Wifi finally works :)

I'm writing this connected to my hotspot.

for some strange reason the driver didn't work in UNSUPPORTED mode. It wasn't recognized by XWLAN and it probably wouldn't have worked without it anyway (scan.exe didn't display anything!?). I suspect that the reason is that there's an initialization flag that's only enabled if the device is officially supported. At least that happened after patching genm32w.os2 to think our RT2860 is officially supported. According to the Genmac debug logs that didn't seem to change much (expect for the new flag I couldn't enable in UNSUPPORTED mode) but suddenly XWLAN recognized the driver.
Looking for public hotspots doesn't work - don't ask me why. However you can create a profile if you know the SSID and connect to that manually configured WLAN. Once connected it seems to work fine - it's stable so far.
btw. I didn't need the Wifi device firmware - so the impression I had after browsing (and trying to patch) the Windows driver was right: Providing the firmware is optional.

I attached a ZIP file to this post containing the Windows driver (used the one from my driver CD), the NIF file needed by Genmac as well as a genm32w.os2 patch ("patch genmac.patch /A").
The necessary steps are:
Install Genmac 2.2 without any drivers, copy the WRAPPER_1814_0781 directory to \ecs\system\genmac\driver, copy W1814x0781.NIF to \ecs\system\genmac\nif and \ibmcom\macs and copy genmac.patch to \ecs\system\genmac\driver, make a backup of genm32w.os2 and apply the patch with "patch genmac.patch /A" on the commandline. Finally copy the patched genm32w.os2 to \ibmcom\macs. You should be able to add a driver called "GenMac Wrapper Ralink RT2860 series Wireless LAN Card" using MPTS configuration or by editing your PROTOCOL.INI. On startup it will say it loads the driver for Asus WLAN RT2400 but display the proper device id. (You could hexedit that, too... easily... just be sure that the new nullterminated string is shorter or as long as the old one so you don't overwrite some other static variables or code)

Alright, I'd say it's time to remove the "Designed for Windows XP" sticker ;-)

cheers,
Robin

Shai

yet another update: I wrote that after switching to SMP kernel and ACPI in SMP and APIC mode (my config.sys entry is "PSD=ACPI.PSD /SMP /APIC /CD"), USB suddenly worked fine. That's right I hadn't had any problems with it so far, even with the EHCI controller driver activated at startup. However - as I've already said - VDMs (DOS & Win 3.1) don't work anymore. The ACPI readme says that this could happen in APIC mode. So I tried to switch back to PIC (without /CD switch as this is APIC-specific) and I immediately got the trap 0008 at startup again. Switched back to "/APIC /CD" and it works again. So it seems we can't have working USB, APIC and VDMs at the same time. That wouldn't matter for most people - to have working sound in DOS games most people probably use DOSBox anyway - but I'm a bit of a DOS nostalgic and I even occasionally use Win3.1 sessions.
So does anyone know whether there is some kind of fix or workaround for that problem?

cheers,
Robin