• 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

GEN MAC news?

Started by onlineuser2, 2012.02.20, 15:28:44

Previous topic - Next topic

onlineuser2


DougB

QuoteAny news about?

http://svn.netlabs.org/genmac/ticket/8

I doubt if you will get any response there. That project was opened a couple of years ago, when there was a slight chance that Willibald Meyer might open source GENMAC. He never did, so that project is dead.

Blonde Guy

QuoteAccording to the Intel documentation it is the same software that is used for all Centrino wifi cards from the 4965 and onwards. This may imply that the GenMac? driver for the 4965 Genmac drive also should work for the 6200/6250/6300 cards.

Has anyone tried to use the 4925 Genmac driver for later Intel Centrino cards using the unsupported documentation on ecomstation.ru pages?

Yes we tried. It doesn't work.

The MutliMac project has plans for that chipset, which would let us use laptops newer than Thinkpad T61, but they are still working on more basic support for wired chips at this time. If you are a device driver programmer, you could contact Mensys to help with this project. As far as I know, it would not take that much work to get Centrino support up and running on the MultiMac framework.
Expert Consulting for OS/2 and eComStation

eirik

Blonde Guy is correct, it does not work. I know as I am one of those who probably have pursued this the furthest, and I am the origin of the idea of using Intel 4965 GenMac setup for the 5xxx and 6xxx Intel drivers.  But I think it may still be possible to succeed:


  • the driver loads appropriately without error messages, and
  • the XWLAN signals it is operational.

I think the problem is connected to the second last line in the Lantran log (which I then also believe is causing the MAC not to be appropriately displayed/captured):

IBM OS/2 LANMSGDD [05/21/04] 6.00 is loaded and operational.
IBM OS/2 LAN Netbind
WRND32$  bound to  "TCPIP_NIF".
WRND32$  WRAPPER for bus: 3 slot: 0 Vendor: 0x8086 Device: 0x4238.
WRND32$  load SYS: "netw4x32.sys" length: 2206976 CRC: 0x84fd / 0x1005.
WRND32$  load INF: "netw4x32.reg" length: 2647.
WRND32$  WRAPPER ErrorLog 0x40001b7c.
WRND32$  WRAPPER hardware init successfull MAC : 000000:000000.

If someone knows that error code 0x40001b7c means, I will know if I am barking up the wrong tree or if there is hope.

Eirik

Paul Smedley

Quote from: Blonde Guy on 2012.02.21, 16:36:55
The MutliMac project has plans for that chipset, which would let us use laptops newer than Thinkpad T61, but they are still working on more basic support for wired chips at this time. If you are a device driver programmer, you could contact Mensys to help with this project. As far as I know, it would not take that much work to get Centrino support up and running on the MultiMac framework.

One important difference between a wired and wireless driver is that a wireless driver needs to be 'talked to' by wpa_supplicant

For Genmac - the Genmac driver emulates a Windows NDIS driver (no surprise) in terms of the interface to wpa_supplicant.

For any Multimac port of a wireless driver, I'd guess either the:
- Linux drivers that support nl80211/cfg80211 (most new drivers)
- Linux drivers that support Linux Wireless Extensions v19 or newer with WPA/WPA2 extensions
(above from the wpa supplicant website)

interfaces would need to be used - not sure what exactly would be involved in doing that, as I'm not really a device driver guy.

At some point, I will take a look at the Intel Wireless code - interestingly, David has been updating the e1000e driver based on the linux kernel source from the 3.2.4 kernel.

This suggests at least that taking the current intel wireless driver from the latest kernel sources may be possible to port.

Based on uniaud experiences, one of the most difficult parts is getting the device driver code compiling with Watcom, compared with GCC as used on linux.

Something to look on on a rainy day :)

onlineuser2

Great news from Paul Smedley!
Isn't it going to rain?

Why not thinking of some kind of community support, like java or Qt?

Onlineuser2

Paul Smedley

Quote from: onlineuser2 on 2012.02.27, 16:50:24
Great news from Paul Smedley!
Isn't it going to rain?

Why not thinking of some kind of community support, like java or Qt?

Please don't get too excited - it's something I'd like to look at as it's interesting to me - but I have no idea when I'lll have time/motivation to look at this....

onlineuser2

Not too exited, only dancing for rain!

Updating or rethinking genmac is necessary.
Your post means that it is possible to begin with a close survey,
waiting for... rainy days

thanks for your great work

Onlineuser2

DougB

QuoteUpdating or rethinking genmac is necessary.

It doesn't matter how necessary it is, it looks like it will never happen. Willibald Meyer (the author of GENMAC) has steadfastly refused to release his work, so we have no starting point, other than to start over. The Multimac project is that restart point, but far too few people are working on the project, and those who are working on it have other things to do. Meanwhile, we are falling badly behind, and GENMAC seems to have run out of steam.

We don't need rainy days. We need more, competent, programmers who are willing to do some serious work, for very little, if any, compensation (other than the eternal gratitude of eCS users). It would also help, if those who can't program, would help in other ways. Much testing needs to be done, and work on documentation (including translation) can be done by those who can't program. Monetary donations to those who do the work are also appreciated.

Paul Smedley

Quote from: DougB on 2012.02.29, 05:54:33
QuoteUpdating or rethinking genmac is necessary.

It doesn't matter how necessary it is, it looks like it will never happen. Willibald Meyer (the author of GENMAC) has steadfastly refused to release his work, so we have no starting point, other than to start over. The Multimac project is that restart point, but far too few people are working on the project, and those who are working on it have other things to do. Meanwhile, we are falling badly behind, and GENMAC seems to have run out of steam.

We don't need rainy days. We need more, competent, programmers who are willing to do some serious work, for very little, if any, compensation (other than the eternal gratitude of eCS users). It would also help, if those who can't program, would help in other ways. Much testing needs to be done, and work on documentation (including translation) can be done by those who can't program. Monetary donations to those who do the work are also appreciated.

I'm assuming by 'rethinking' genmac, onlineuser2 meant things like multimac.

People also shouldn't underestimate how much providing feedback - even if it's just a 'thanks' via email means to developers.

As Doug points out, most OS/2 developers do it basically for love.  Heck I've been running Ubuntu as my main desktop OS for the last 11 months, but I still get a kick out of supporting eCS, and it's great stress relief from my day job, so I continue to do it.

One of the things the OS/2 community really SUCKS at is providing feedback....

onlineuser2

I'm assuming by 'rethinking' genmac, onlineuser2 meant things like multimac.

You are right.

I am only a simply end user. I know the situation, from our forum. I still remain disposable for outer support (at least some pennies), as I cannot do anything else (not able unfortunately) .

We are pointing out a problem which must be solved, by a workaround or a real solution.

I wonder what  Mensys or Ecomstation are thinking about (not solving the problem will make useless all their other great work...).






DougB

QuoteOne of the things the OS/2 community really SUCKS at is providing feedback....

Well, yes, but somebody else will do it...

QuoteI wonder what  Mensys or Ecomstation are thinking about (not solving the problem will make useless all their other great work...).

I know that Mensys is very aware of the problem, but they can't do it all either. The ball got dropped when Willibald pulled support for GENMAC, and it was far too long before Mensys picked it up (but somebody else could have done it sooner, if they were interested). On the other hand, I have heard that the eCS community didn't have the tools that are required to do the job, until about the same time that Mensys got the ball rolling, so starting sooner may not have helped anyway. I have done what I can do to try to prolong the usefulness of GENMAC, but I don't know enough about it to fix problems with the driver. All I can do is guess about what might work, and help others install what should be the right parts to make it work. Unfortunately, it seems that GENMAC is just not capable of running modern NICs (especially wireless NICs). Problems with ACPI (some of which are fixed with the latest version) don't help either (in fact, that is, apparently, where the emphasis was placed recently). For Mensys it is a balancing act, and they need to make decisions about what comes next. There are a limited number of programmers who are willing, and capable, so they need to be used to the best advantage (not to mention a restricted budget). It is a tough job to make those decisions, and I don't envy them. Somebody will always be upset, and second guessing the decisions won't help anybody.

QuoteWe are pointing out a problem which must be solved, by a workaround or a real solution.

The workaround was GENMAC. The real solution is Multimac. Unfortunately, it seems that there is a gap in coverage that we will need to live with. GENMAC is past the end of life, and Multimac is not ready to do general device support.

FWIW, there are still devices available that you can plug into a working wired interface, and connect to WiFi with them. I have two such devices, that are quite old now, but they still work well, even though they are G devices, not N (just another workaround).

eirik

I agree that the the solution we are looking for is under the MultiMac umbrella.   The problem for many current users of eCS on laptops is reduced functionality today from the lack of wireless on many laptops.  In some cases, a quick fix may be available under the "obsolete" GenMac framework.  Fixing this short term problem at minor costs may hence influence if these current eCS users remain on eCS or move to other platforms.

I therefore argue that it is important to solve short term critical problems (if easily fixable), and WiFi is such an issue (alongside Flash and Java). 

Many of the other applications are nice too, but a we now have proper browsers (FireFox), a good and reliable email client (ThunderBird), a fast PDF reader (Lucide), porper office suites (Open Office and Lotus SmartSuite), efforts should be geared towards solving the critical issues:

  • Net access (wired and wireless)
  • Proper running of the system (ACPI, Fn+FX keys, etc., although the demand for suspend/resume may have been reduced by blistering fast boot on many systems with ACPI 3.19.15)

Eirik

DougB

QuoteThe problem for many current users of eCS on laptops is reduced functionality today from the lack of wireless on many laptops.

I agree that this needs to be one of the top priorities, and I know that it is being worked on. It is just slow going.

QuoteIn some cases, a quick fix may be available under the "obsolete" GenMac framework.

Nobody has had any new success (that I have heard about) with GENMAC, for a couple of years now. There may be some older devices that haven't been tried yet, but it seems that GENMAC is missing something that is needed for newer devices. GENMAC is unlikely to get fixed, unless somebody can do some serious hacking, and Willibald Meyer (the author) has expressly forbidden distributing any patched versions of his work. On the other hand, if anybody does come up with a patch that works, we can distribute the patch.

QuoteMany of the other applications are nice too

Applications don't seem to be too much of a problem. The QT project seems to have opened a lot of doors.

Quoteefforts should be geared towards solving the critical issues

Now that is where some disagreement comes in. What are the "critical" issues? You mention two projects, that are being worked on (as high priority) by some of the best OS/2 programmers anywhere. It is slow going because there are not enough people to do the work, and those who are working on the projects need to do other things too.

Then we have the guy who decided that being able to run games is high priority. He seems to have made good progress, for a while, but recently there has been nothing from him. I am not surprised by that, but I do question the wisdom of trying to build a games interface, when we don't have an adequate video driver to be able to use it (a video driver is also in the works, under the Panorama project, now with SNAP merged, but apparently no acceleration planned because nobody knows how to do that).

QuoteI therefore argue that it is important to solve short term critical problems (if easily fixable), and WiFi is such an issue (alongside Flash and Java)

This is another problem. "easily fixable" is something that a user can assume can happen. I have heard that WiFi is likely to be a 6 month project, AFTER the basic wired problems are sorted out. I would guess that we will see the first WiFi support in about a year (unless some big breakthrough happens - might be sooner -  or we lose the guy who is doing it - might be never). ACPI is progressing nicely, now that there is a new team working on it. however, it looks like the easy parts are done, and the more complicated parts are left to do. You mention Fn keys. IMO those are not as important as getting devices to properly configure. It is most frustrating when you know that a device isn't working, because it doesn't get an IRQ, but there is nothing that you (as a user) can do about it, other than report the problem with the proper supporting information. But that too is part of the problem (and I am as guilty as anybody else). Problems must be reported, or they won't get fixed. Of course, part of reporting a problem, is testing potential fixes, and reporting the results accurately, and in a timely manner. That, in turn, means that the average OS/2 eCS user needs to become a bit more technical, so they can report problems properly. It is not helpful to report that widget xyz "doesn't work". You need to explain what it does, or does not, do, and how to make it fail, so somebody who can do something about t has half a chance to be able to recreate the problem. You can't fix something that works, and if you don't know how to make it fail, and what to look for, you have nothing to fix (or, you can spend days trying to figure it out - time that could be put to better use).

The bottom line is, that the users need to step up to the plate, and help out as much as they can. Find a project to work with, and do what you can to help out. Of course, the developers also need to help the users by suggesting ways to test things, and how to report what they need to know to recreate problems. It is a two way street.

From an earlier post, from one of the guys who does a LOT of the porting work:

QuoteOne of the things the OS/2 community really SUCKS at is providing feedback....

This needs to change, quickly. Feedback can be both positive, and negative. Positive feedback needs to be short, and to the point. Negative feedback requires usable information so the problems can be fixed.

Overall, the people who are doing the work, are doing a great job. They need to be thanked. There are not enough of them, and they are overworked, so they can use some help. Just try to be sure to help, and not hinder, them (this may also be part of the problem - people are afraid to "help" in the wrong way).

diver

Quote from: eirik on 2012.03.01, 15:14:36
I therefore argue that it is important to solve short term critical problems (if easily fixable), and WiFi is such an issue (alongside Flash and Java). 

now i wonder a bit. whats the problem with Flash and Java? If it does not work for you, did you open bug reports for it?

regards
Silvan