OS2 World.Com Forum

Subject  :  Yet another USB flashdrive problem...
Author  :  Shai robin.haberkorn@googlemail.com
Date  :  06 Jan, 2007 on 02:02
Hi,
I recently bought a Philips GoGear (SA1110) mp3 player (1GB space) which can be accessed like an "ordinary" USB flashdrive without special drivers -- at least it does so under Windows and Linux. I read everything about USB flashdrives with OS/2 and possible errors I could find but I still couldn't solve the problem.
I have 2xUHCI+EHCI controllers (Via chipset) and 3 on-board OHCI(+EHCI) controllers (SiS crap). I'm using eComStation 1.1 and the latest USB Basic & USB Mass storage drivers (buildlevel 10.162). Of course I also tried Chris' USB mass storage kit (v.1.2), the USBD.SYS of MMPORT and various different driver versions (I think buildlevel 10.62 was shipped with eCS 1.1 and I used buildlevel 10.158 of USBD.SYS/USBHID.SYS/USBUHCD.SYS/USBMSD.SYS). I combined these drivers in almost every imaginable combination, tried the /CHS and /MS10_OFF switches of USBMSD.SYS as well as the /FORCE_TO_REMOVABLE and /ISS switches of CWUSBMSD.SYS. Also I tried to detach the builtin SD Card reader (which is attached via USB) and disabled the OHCI controller drivers because I thought it could be because of the cheap onboard hardware. Nothing really helped.
Altough it shouldn't matter, I have the latest Netlabs FAT32 drivers (v.0.9.11).
The flashdrive is recognized as an USB device - according to the USB resource manager (I have v.0.9.7) - using recent USBD.SYS drivers or the patched USBD.SYS of MMPORT. However if attached, it doesn't seem to be recognized as a removable media. There is no "Drive X: attached!"-messagebox and LVM says "The partition table on this disk may be corrupt" and "The system is not able to use this disk". Yes, I attached it after the boot-process. I know that this is an ordinary behaviour unless I rewrite the MBR/partition tables with DFSEE. But DFSEE doesn't recognize the disk as removable media ("Error, disk 3 PD3 : reading the MBR info in the 1st sector failed! DUMMY, disk 3 seems reserved with no media present (USB/PCCARD etc") which makes rewriting the MBR impossible. So the USB mass storage driver itself doesn't seem to recognize the device.
For some quite strange reason using the older buildlevel 10.158 USBUHCD.SYS/USBD.SYS/USBHID.SYS/USBMSD.SYS with USBOHCD.SYS drivers disabled (and only with the old drivers...) I get the "Drive X: attached!"-message and LVM *just* reports a corrupted partition table. In this case, DFSEE recognizes the disk as removable media and allows the "New MBR code, ERASE tables"-command. This command, however, fails because of an "invalid" MBR. Blanking the disks first sector (with DFSEE and other tools) or removing the existing FAT32 partition with Linux didn't help, too. Maybe it just looked like it recognized it as removable media but the old problem remained.
If this helps, I think the flashdrive has a SigmaTel chipset (at least it's the companies name showed in the resource manager if I attach the drive in "recovery mode").
I use ordinary USBMSD.SYS parameters: /V /FLOPPIES:0 /REMOVABLES:1 /FIXED_DISKS:0
It works properly with Knoppix which suggests that it's really a software problem.
As you probaply understand, after several days (I think it's almost a week) of "playing" with the device I'm a bit frustrated. Is it really one of the few unsupported flashdrives?
If yes, is there anyway *some* more or less dirty hack to use it? Currently I attach it at my flat share roommates Windows PC and access it via Samba (how humiliating...). I also tried to get it to run on a small floppy FreeDOS (supports FAT32) system. Contrary to common prejudices, the DOS-support of USB mass storage devices isn't that bad. For instance there are some "generic" Cypress & Panasonic USB ASPI and USB MSD drivers (from 2003) that are reported to support a lot of external USB hard and flash drives: http://www.bootdisk.com/usb.htm
The Panasonic ASPI driver had problems with my USB controllers but the Cypress driver recognized the USB flashdrive as removable media but was unable to initialize it.
Do you have any other clue? Thanks for your help in advance.

Robin


Subject  :  Re:Yet another USB flashdrive problem...
Author  :  Pete losepete@ntlworld.com
Date  :  06 Jan, 2007 on 02:52
Hi Robin

Not sure what controllers you have and whether they are all on-board or if you have an addin card.

Have you read and tried to follow the advice in the USB Removable FAQ?

I suggest a look at your usb controllers using USBcfg - which includes a copy of the above FAQ as part of the Help http://hobbes.nmsu.edu/pub/os2/system/usbcfgb7a.zip

You do not mention the bldlevel of OS2DASD.DMD - more devices work with 14.104 than with earlier builds of this driver.

Pointless using old, unsupported drivers such as CW...

Something else to try: USBcfg has a Resource Manager tab, click the run button when the device is attached and see if that application recognizes the device regardless of whether the system fails to attach it (allow 30 secs or so after physically attaching) as a drive.

Regards

Pete


Subject  :  Re:Yet another USB flashdrive problem...
Author  :  tex
Date  :  06 Jan, 2007 on 05:35

Shai (06 Jan, 2007 02:02):

Do you have any other clue? Thanks for your help in advance.

Robin


I don't know what the differences are. I bought a 4GB monster drive formatted FAT32. Windows recognized it as a removable drive. However, eCS (LVMGUI) could see the drive, but did not recognize the partition, even with the FAT32 driver installed. However, once I destroyed the partition and created it with LVMGUI, the partition was recognized. I used Windows to format it FAT32 again. What was strange was that LVMGUI could not destroy the partition. I had to boot to Windows to destroy the partition.

Before destroying and recreating the partition with LVMGUI, Windows recognized the drive as a removable 4GB FAT32 partition. After destroying and recreating the partition with LVMGUI, Both Windows and eCS recognized the drive. However, Windows no longer recognized it as a removable drive even though I could use the Windows utility to unmount the drive. eCS now recognizes the drive as removable and I am able to use "eject" to remove it.

I would say destroy and create the partition with LVMGUI, but this may mess up the MP3 program. However, having never owned or operated a mp3 player, I am could be wrong in my assumption.


Subject  :  Re:Yet another USB flashdrive problem...
Author  :  El Vato
Date  :  06 Jan, 2007 on 15:11

Pete (06 Jan, 2007 02:52):
[...]

Pointless using old, unsupported drivers such as CW...

[...]


With all respect, I beg to differ with you on this statement.

I have used Chris's drivers to support USB drives from 500MB up to a 80GB hard drive in a case (the latter with some problems, albeit). Yes, with a usb basic "unsupported" hack from 2003. And yes I had some initial trouble during the initial configuration. But Wohlgemuth's USB drivers are a competitive option to those "supported" alternatives because they work in various cases.

Even if a user has multiple USB controllers (Wohlgemuth's USB supports a single controller only) and the cwUSBUHC.SYS, cwUSBOHC.SYS, and cwUSBD.sys drivers can not be used, the cwUSBMSD.add driver still can be used in combination with (possibly newer) proprietary alternative USB basic support.(< http://www.os2warp.be/index2.php?name=cwusb >)

You can find an example configuration on a T40 laptop that I submitted to http://www.os2warp.be to support a 1GB Memorex Travel Drive in the appropriate section of the web site.

We would not be falling so far behind in techonology if the OS/2 code were open to be improved by third parties (Wohlgemuth's ). The Linux operating system is "unsupported" also but due to its open code, third parties have turned it into the high caliber super application that has allowed it to enter the enterprise world. Are we there yet by following this conservative old school methodology???

No. We are still having problems with something as simple as USB.

El vato || ...


Subject  :  Re:Yet another USB flashdrive problem...
Author  :  Shai robin.haberkorn@googlemail.com
Date  :  06 Jan, 2007 on 15:22

Pete (06 Jan, 2007 02:52):
Hi Robin

Not sure what controllers you have and whether they are all on-board or if you have an addin card.



The 3 OHCI controllers are on my SiS board and the two UHCI controller are on one addin card (Via chipset).

Have you read and tried to follow the advice in the USB Removable FAQ?

I suggest a look at your usb controllers using USBcfg - which includes a copy of the above FAQ as part of the Help



Yes I tried USBcfg but the program itself doesn't start ("Cannot open ini-file..."). But I thought did read the Mass storage guide. It seems the only driver it refers to, which I didn't update yet is the DANIS506 driver. I'll do so immediately.

You do not mention the bldlevel of OS2DASD.DMD - more devices work with 14.104 than with earlier builds of this driver.

I also read about this driver and updated it. The buildlevel is 14.104.

Robin


Subject  :  Re:Yet another USB flashdrive problem...
Author  :  Shai robin.haberkorn@googlemail.com
Date  :  06 Jan, 2007 on 15:43
Ok, I updated DaniS506 driver to version 1.77. It still doesn't work.

Robin


Subject  :  Re:Yet another USB flashdrive problem...
Author  :  El Vato
Date  :  06 Jan, 2007 on 16:06

tex (06 Jan, 2007 05:35):

Shai (06 Jan, 2007 02:02):

Do you have any other clue? Thanks for your help in advance.

Robin


I don't know what the differences are. I bought a 4GB monster drive formatted FAT32. Windows recognized it as a removable drive. However, eCS (LVMGUI) could see the drive, but did not recognize the partition, even with the FAT32 driver installed. However, once I destroyed the partition [...]


Destroying the partition might erase the MP3 specific software from the (WinXX specific) sectors.

Since Shai has access to Linux, he might do the following to preserve compatibility of the OEM initial MP3 stuff across the three operating systems.

Shai should become or log in as the root or super user to accomplish the procedure.

Copy ALL the data from the USB device to a an appropriate Linux directory. It can be achieved quickly and securely with a command of the form (to mount the USB device if not already mounted):

mount < default /dev/sda > < Shai's defined mount point directory >

Proceed to copy the USB device data with:

cp -rvf < Shai's defined mount point directory > <Shai created Linux directory>

where, of course, the angled <statements> are to be replaced with Shai's specific directory structure definitions.

Proceed to observe the USB mass structure by UMOUNTING the USB drive first:

umount < Shai's defined mount point directory >

(please note spelling: it is umount and NOT unmount command)

Wait a few seconds if the data transaction has not been completed; sometimes Linux will not accomplish a given process immediately, specially if another task is yelling for attention.

Once the USB drive has been unmounted, proceed to make a file system WITHOUT destroying the original partition structure (most likey there will be only one partition covering the whole hard disk a la WinXX). You can verify with the command friendly:

cfdisk /dev/sda

(command above works on a Debian distro) assuming, again, that Shai's USB is the only one of its kind.

Now, after verifying that there is a single partition, enter at the prompt:

mkfs -t vfat /dev/sda

If Shai gets an error about using the option -T to convey to the OS that he means it, then he should modify his original command as follows:

mkfs -t vfat /dev/sda -T

...and Linux will format the original partition in FAT32 and OS/2 will be able to read it WITHOUT destroying the original partition of the MP3.

...well, copy back your original software back to your USB MP3 to finish (after mounting you USB device, of course), WinXX will still continue to use the OEM features since Shai did not mess with the partition.

Note that if WinXX were to be used for this procedure, we would never finish the project since that OS demands incompatibility with other OSes unless, of course, they run in a virtual machine inside the WinXX environment.

...and there the reason of the harsh criticism towards Novell for its pact with the MS empire. Once an OS runs dependent on the resources of another underlying platform (i.e., WinXX), the virtualized OS (Linux, OS/2) is at the mercy of the one providing the resources.

Recommendation: if an OS/2er is to dual boot, lets do it with the Penguin !


Subject  :  Re:Yet another USB flashdrive problem...
Author  :  Shai robin.haberkorn@googlemail.com
Date  :  06 Jan, 2007 on 16:31

El Vato (06 Jan, 2007 16:15):
Destroying the partition might erase the MP3 specific software from the (WinXX specific) sectors.

Thanks for your suggestions but I don't think that's necessary with this device. I deleted the partition but I could still start the player and the firmware was still functioning. There's also a Windows tool to do a firmware update. So if push comes to shove I can restore it.


Recommendation: if an OS/2er is to dual boot, lets do it with the Penguin !

Maybe if you must have a dual boot system because you need it for your work/studies/school. In general, I don't like the idea - it's similar to the possibility to do a lot of work in a guest OS of Virtual PC/SVISTA. It encourages you to prefer the other systen over OS/2. I have access to Linux because my roommate has it on his notebook.

Robin


Subject  :  Re:Yet another USB flashdrive problem...
Author  :  Blonde Guy
Date  :  06 Jan, 2007 on 18:12
I'm using a generic (no brand name on it, bug it might be a Lexar?) MP3 player. It worked right away.

First, I'm using the latest USB basic and USB storage (10.162). I'm also running the removable media daemon provided in those packages.

When I plug in the MP3 player, I get "drive G" added or whatever.

I drag my MP3 files and drop them onto the player's drive folder. This preserves the OS/2 longnames on the player. I have added the appropriate MP3 id stuff using the multimedia features of eComStation 1.2. The MP3 id stuff is how the MP3 player knows the longname of the song and artist.

I always eject the MP3 player before unplugging it.

My MP3 player is unchanged from the factory, where it appears to be formatted FAT16, and all factory-loaded files appear to have VFAT format filenames. I have never plugged it into Windows or Mac to see what happens.


Subject  :  Re:Yet another USB flashdrive problem...
Author  :  Pete losepete@ntlworld.com
Date  :  07 Jan, 2007 on 03:00

Shai (06 Jan, 2007 15:22):

Pete (06 Jan, 2007 02:52):
Hi Robin

Not sure what controllers you have and whether they are all on-board or if you have an addin card.



The 3 OHCI controllers are on my SiS board and the two UHCI controller are on one addin card (Via chipset).

Have you read and tried to follow the advice in the USB Removable FAQ?

I suggest a look at your usb controllers using USBcfg - which includes a copy of the above FAQ as part of the Help



Yes I tried USBcfg but the program itself doesn't start ("Cannot open ini-file..."). But I thought did read the Mass storage guide. It seems the only driver it refers to, which I didn't update yet is the DANIS506 driver. I'll do so immediately.

You do not mention the bldlevel of OS2DASD.DMD - more devices work with 14.104 than with earlier builds of this driver.

I also read about this driver and updated it. The buildlevel is 14.104.

Robin


Hi


I was very interested to read that USBcfg will not start and produces an error message "Cannot open ini-file..."

You may be interested to know that situation cannot arise. The code checks for the existence of the ini file and if it does not exist creates a new file - there is no "Cannot open ini-file..." error message in the code.

Regards

Pete


Subject  :  Re:Yet another USB flashdrive problem...
Author  :  Shai robin.haberkorn@googlemail.com
Date  :  07 Jan, 2007 on 04:22

Pete (07 Jan, 2007 03:00):
Hi


I was very interested to read that USBcfg will not start and produces an error message "Cannot open ini-file..."

You may be interested to know that situation cannot arise. The code checks for the existence of the ini file and if it does not exist creates a new file - there is no "Cannot open ini-file..." error message in the code.

Regards

Pete


Mhh, that is indeed interesting... and impossible if you assume that the message is generated by your program/code. Is it possible that the error is produced by some library/API you rely on?
I attached a screenshot - maybe it's helpful. I ran the program from a temporary directory but if I execute the installed version there's just the same error.

Robin


Subject  :  Re:Yet another USB flashdrive problem...
Author  :  Shai robin.haberkorn@googlemail.com
Date  :  07 Jan, 2007 on 06:31
Good news everyone. After hours/days(/weeks) of frustration it seems that I finally solved the problem. I had to install the Daniela's "NON-512 bytes/sector DASD support filter":
http://hobbes.nmsu.edu/cgi-bin/h-search?sh=1&button=Search&key=danin512r016&stype=all&sort=type&dir=%2F
I didn't read about this anywhere before. It was quite incidentally. It may be a valuable addition to the USBCfg FAQ and the FAT32 removable media guide.
Using this filter driver and the latest USB drivers, DFSEE accepted the drive as removable media, displayed the right drive size and reported several partitions that shouldn't be there. I could apply the MBR/partition table fix and create a primary partition using LVM (I didn't manage to do so with DFSEE - too much confusing options). Then - as described in the USBCfg FAQ - I formatted the partition with DFSEE (FAT32) and set the "LVM information". After ejecting and reattaching I was able to access the drive via the WPS. Copying is damned slow but maybe this has something to do with FAT32's "Lazy" Read/Write deamon or the device wasn't in an EHCI port (which one is EHCI and which one isn't???). I'll try to disable CACHEF32 entirely and attach it to diffent ports.
One other major problem remains. The firmware of the device does *not* recognize the drive's content - either the way it is partitioned or the way it was formatted. Linux and Windows are unable to see it, too. Did anyone have a similar problem with a flash drive? If Windows is able to access the drive, the firmware will probaply also be able to do so.

Greetings, Robin


Subject  :  Re:Yet another USB flashdrive problem...
Author  :  DavidG
Date  :  07 Jan, 2007 on 07:31
There is a major problem with lazy write. Turn it off on the cachef32.exe statement in the config.sys and reboot.

This problem has been looked at, but apparently, it requires a whole rewrite of the cache system which no one wants to do.


Subject  :  Re:Yet another USB flashdrive problem...
Author  :  Pete losepete@ntlworld.com
Date  :  07 Jan, 2007 on 18:20

Shai (07 Jan, 2007 04:25):

Pete (07 Jan, 2007 03:00):
Hi


I was very interested to read that USBcfg will not start and produces an error message "Cannot open ini-file..."

You may be interested to know that situation cannot arise. The code checks for the existence of the ini file and if it does not exist creates a new file - there is no "Cannot open ini-file..." error message in the code.

Regards

Pete


Mhh, that is indeed interesting... and impossible if you assume that the message is generated by your program/code. Is it possible that the error is produced by some library/API you rely on?
I attached a screenshot - maybe it's helpful. I ran the program from a temporary directory but if I execute the installed version there's just the same error.

Robin


Hi Robin

That looks like a default compiler system generated error message - rather than something I have coded to catch an error that should not happen - which I can only guess suggests that the usbcfg.ini file has somehow got trashed and is unreadable.

Must admit that is the 1st of those to ever be reported.

As you are running eCS1.1 does the usbcfg.ini file actually exist in [BootDrive]:\ecs\bin or have you installed to somewhere else?

If it exists delete it and try to start USBcfg again.

If it does not already exist then something is blocking creation of the ini file when the app is started...


I had something similar happen with Warpin 2 days ago - it could not open the database ini file although the file seemed to exist. As Ini Editor (from the IniTools package) could not open it either I deleted the failed ini file and then started Warpin successfully - trouble is all of the previous package install data is now missing...

Hope that is all the problem is there.

Regards

Pete


Subject  :  Re:Yet another USB flashdrive problem...
Author  :  Shai robin.haberkorn@googlemail.com
Date  :  07 Jan, 2007 on 18:44

Pete (07 Jan, 2007 18:20):
Hi Robin

That looks like a default compiler system generated error message - rather than something I have coded to catch an error that should not happen - which I can only guess suggests that the usbcfg.ini file has somehow got trashed and is unreadable.

Must admit that is the 1st of those to ever be reported.

As you are running eCS1.1 does the usbcfg.ini file actually exist in [BootDrive]:\ecs\bin or have you installed to somewhere else?

If it exists delete it and try to start USBcfg again.

If it does not already exist then something is blocking creation of the ini file when the app is started...


I had something similar happen with Warpin 2 days ago - it could not open the database ini file although the file seemed to exist. As Ini Editor (from the IniTools package) could not open it either I deleted the failed ini file and then started Warpin successfully - trouble is all of the previous package install data is now missing...

Hope that is all the problem is there.

Regards

Pete


I installed it to c:\ecs\bin yes - but there is no usbcfg.ini (if it's called this way) and no other ini file that could belong to USBCfg. Also, I don't know what could prevent it from creating one. Is it always in the same directory as usbcfg.exe and if not what does it depend on? I searched my whole drive but found no usbcfg.ini.

Greetings,
Robin


Subject  :  Re:Yet another USB flashdrive problem...
Author  :  El Vato
Date  :  07 Jan, 2007 on 23:37

Shai (06 Jan, 2007 16:31):

El Vato (06 Jan, 2007 16:15):
Destroying the partition might erase the MP3 specific software from the (WinXX specific) sectors.

[...]. There's also a Windows tool to do a firmware update. So if push comes to shove I can restore it.


Recommendation: if an OS/2er is to dual boot, lets do it with the Penguin !

Maybe if you must have a dual boot system because you need it for your work/studies/school. In general, I don't like the idea - it's similar to the possibility to do a lot of work in a guest OS of Virtual PC/SVISTA. It encourages you to prefer the other systen over OS/2.

Not at all. It simply reflects a desire to wean onself from the WinXX imposition by the monopoly. Eberhard Mattes, possibly looking into the future and anticipating the MS onslaught, enabled OS/2ers to achieve that goal using EMX technology.

Noting the fact that you are familiar with WinXX tools, as you stated above, I simply provided an alternative manner to accomplish the same task with Linux's built in tools --and at the same time provide a means to become less dependent WinXX.

The fact that you were using SAMBA to access your device, as you stated elswhere, simply reinforces the fact that an OS/2er needs to look beyond WinXX to solve his/her problems. SAMBA and Linux go toghether.


Shai (06 Jan, 2007 16:31):
I have access to Linux because my roommate has it on his notebook.

Robin


Please, congratulate your roommate on my behalf.

Best regards !


Subject  :  Re:Yet another USB flashdrive problem...
Author  :  Shai robin.haberkorn@googlemail.com
Date  :  08 Jan, 2007 on 02:57
I think I found out why the MP3 player, Linux and Windows do not recognize the partitions/filesystems I create. Of course, the drive can be partitioned and formatted. But why does Linux recognize the (Windows formatted) drive and mounts it but its fdisk is not able to see the right partition (just like LVM/DFSEE). The drive manager of Windows XP refuses to delete the partition everytime I format the drive it seems to overwrite the partition I created before.
The mp3 player expects the drive to be written as a huge floppy and Windows always formats the drive as a huge floppy. That explains why I can access it from OS/2 whithout rewriting the MBR and so on if I use the /REMOVABLES:1 /FLOPPIES:0 /REMOVABLE_AS_FLOPPY options of USBMSD.ADD. As far as I know, OS/2 can't read FAT32-formatted floppies therefore I formatted it as FAT16 (the player's firmware can handle it). Now LVM displays the (floppy-)drive's correct size and filesystem in the Logical View. But sadly although it is FAT16, I can't read or write the drive's content. The WPS itself shows questionmarks instead of the real drive size. However I can easily reformat the drive as FAT16 (commandline FORMAT or WPS context menu). Then it's no problem to read/write data to the drive and the WPS displays the right size and free space. It's also quite fast compared to writing to a FAT32-partition. Ironically although I formatted it then as a floppy, too, Linux & Windows still refuse to read it and the player's firmware doesn't work properly *after* I copied files to the drive.
I'm now quite clueless about what to try next or how to get it to work. Maybe I just give up. I really wasted way too much time with this problem.

Robin


Subject  :  Re:Yet another USB flashdrive problem...
Author  :  Pete losepete@ntlworld.com
Date  :  08 Jan, 2007 on 04:05

Shai (07 Jan, 2007 18:44):


I installed it to c:\ecs\bin yes - but there is no usbcfg.ini (if it's called this way) and no other ini file that could belong to USBCfg. Also, I don't know what could prevent it from creating one. Is it always in the same directory as usbcfg.exe and if not what does it depend on? I searched my whole drive but found no usbcfg.ini.

Greetings,
Robin



Hi Robin

USBcfg does not come with an ini file, the 1st use creates it - in the same directory as USBcfg.exe

I wonder why that is not working for you...

If you like I will put together a test build with some extra error checking to try to establish the cause sometime in the next week or so.

Looking through my code I am very sure that something is preventing the ini file creation.

Basically the code checks for the existence of USBcfg.ini in the directory that USBcfg.exe is running from and if the ini file does not exist sets onscreen location, width and height of the app based on display resolution and then creates a new ini file. Which sets me thinking...

The bit of code involved in width and height is designed around 4:3 screen displays.

If the screen is a different type maybe the app is actually falling over as a result of unknown width/height sizes.

If you have something different you may want to post screen resolution in use so I can check the code - and update as necessary.


I wonder if you have an app like xit running?

Regards

Pete


Subject  :  Re:Yet another USB flashdrive problem...
Author  :  Shai robin.haberkorn@googlemail.com
Date  :  08 Jan, 2007 on 08:09

Pete (08 Jan, 2007 04:05):
Hi Robin

USBcfg does not come with an ini file, the 1st use creates it - in the same directory as USBcfg.exe

I wonder why that is not working for you...

If you like I will put together a test build with some extra error checking to try to establish the cause sometime in the next week or so.



Ok, I'd like to help.

Looking through my code I am very sure that something is preventing the ini file creation.

Basically the code checks for the existence of USBcfg.ini in the directory that USBcfg.exe is running from and if the ini file does not exist sets onscreen location, width and height of the app based on display resolution and then creates a new ini file. Which sets me thinking...

The bit of code involved in width and height is designed around 4:3 screen displays.

If the screen is a different type maybe the app is actually falling over as a result of unknown width/height sizes.

If you have something different you may want to post screen resolution in use so I can check the code - and update as necessary.



Yes that's possible 4:3 = 4/3 = 1.3333... So it works for 1024/768 = 1600/1200 but not for my resolution 1280/1024.


I wonder if you have an app like xit running?

No, I haven't .

Regards

Pete



Subject  :  Re:Yet another USB flashdrive problem...
Author  :  Pete losepete@ntlworld.com
Date  :  08 Jan, 2007 on 15:49

Shai (08 Jan, 2007 08:09):

Pete (08 Jan, 2007 04:05):
Hi Robin

USBcfg does not come with an ini file, the 1st use creates it - in the same directory as USBcfg.exe

I wonder why that is not working for you...

If you like I will put together a test build with some extra error checking to try to establish the cause sometime in the next week or so.



Ok, I'd like to help.

Looking through my code I am very sure that something is preventing the ini file creation.

Basically the code checks for the existence of USBcfg.ini in the directory that USBcfg.exe is running from and if the ini file does not exist sets onscreen location, width and height of the app based on display resolution and then creates a new ini file. Which sets me thinking...

The bit of code involved in width and height is designed around 4:3 screen displays.

If the screen is a different type maybe the app is actually falling over as a result of unknown width/height sizes.

If you have something different you may want to post screen resolution in use so I can check the code - and update as necessary.



Yes that's possible 4:3 = 4/3 = 1.3333... So it works for 1024/768 = 1600/1200 but not for my resolution 1280/1024.


I wonder if you have an app like xit running?

No, I haven't .

Regards

Pete



Hi Robin

1280*1024 is a resolution in use here so that is not the problem.

Here is a total stab in the dark based on some experiences with 1 eCS1.1 system here a couple of years ago:

Open a command window in \ecs\bin (or wherever USBcfg is installed to).

Use the command attrib -r -s -h usbcfg.ini

Do you now have a usbcfg.ini file in that directory? - dir is usually quicker than waiting for the folder view to refresh.


If the answer is Yes then the system is setting the just created usbcfg.ini file as +r +s +h and that is preventing the basic settings from being written - this is definitely not something done by usbcfg.exe for obvious reasons


The resolution here, if some old brief notes are correct, was to run Cleanini followed by Checkini

Cleanini was available here http://www.c-arnold.de.vu but that site seems to have gone...

If you cannot find a copy I could email it to you.

Checkini is part of the wptools package which I think is supplied with eCS1.1


The above cleanini/checkini stopped the system from applying those rsh attributes to the SysInfo/2 pci.ini file (and maybe others that I was not aware of) and allowed the app to run normally.


I hope the above resolves the issue because I am now totally out of ideas...


Regards

Pete


Subject  :  Re:Yet another USB flashdrive problem...
Author  :  Pete losepete@ntlworld.com
Date  :  08 Jan, 2007 on 17:32

El Vato (06 Jan, 2007 15:11):

Pete (06 Jan, 2007 02:52):
[...]

Pointless using old, unsupported drivers such as CW...

[...]


With all respect, I beg to differ with you on this statement.

I have used Chris's drivers to support USB drives from 500MB up to a 80GB hard drive in a case (the latter with some problems, albeit). Yes, with a usb basic "unsupported" hack from 2003. And yes I had some initial trouble during the initial configuration. But Wohlgemuth's USB drivers are a competitive option to those "supported" alternatives because they work in various cases.

Even if a user has multiple USB controllers (Wohlgemuth's USB supports a single controller only) and the cwUSBUHC.SYS, cwUSBOHC.SYS, and cwUSBD.sys drivers can not be used, the cwUSBMSD.add driver still can be used in combination with (possibly newer) proprietary alternative USB basic support.(< http://www.os2warp.be/index2.php?name=cwusb >)

You can find an example configuration on a T40 laptop that I submitted to http://www.os2warp.be to support a 1GB Memorex Travel Drive in the appropriate section of the web site.

We would not be falling so far behind in techonology if the OS/2 code were open to be improved by third parties (Wohlgemuth's ). The Linux operating system is "unsupported" also but due to its open code, third parties have turned it into the high caliber super application that has allowed it to enter the enterprise world. Are we there yet by following this conservative old school methodology???

No. We are still having problems with something as simple as USB.

El vato || ...



Hi El vato


You are more than welcome to disagree with me, maybe my statement was a little too strong but I have seen lots of posts with people struggling to get these drivers to work when the remedy was to remove them and install and configure the IBM drivers correctly. However, that does in all honesty only apply to situations where access to IBM updates are/were possible.


If the CW drivers work with some of your usb devices that, for whatever reason, the IBM USB drivers fail to work with Please carry on

Worth thinking about is that a later USB device probably works with those drivers more by accident than design.

Also worth thinking about is that other drivers are often involved in whether the device works or not - os2dasd.dmd is an example.

A common error is to use lowercase parameters to usbmsd.add and then expect it to work - Yes, case sensitive parameters, requires uppercase.

Another thing people sometimes do not realise is that the mainboard BIOS needs to be setup correctly - most mainboards should have Legacy USB support Disabled. Forgetting this simple step can be a killer as regards USB support on OS/2 based systems.

I have never tried any of the CWUSB drivers because I have never needed to. Every mp3 player, flash drive, external hard drive, scanner, mouse tried here has worked with the IBM drivers - guess I've been lucky


I have 3 systems here all fitted with Internal USB multi cardreaders. These are specifically *Not* supported by the IBM drivers - but all work fine as long as the user remembers to Refresh the Drives Folder View or use the Refresh Removables object. Yes, the specific non-support is that inserting a card into a slot does not get the system to automatically display the attached drive - but it is attached and usable.


Sometimes some fiddling is required: in the case of external flash drives and mp3 players it has been necessary to destroy existing partitions and then recreate with LVM - no, have not needed to resort to DFSee for that yet.

I have not tried any flash drives that use fat32 yet though and suspect they may provide a little challenge.


I do agree that the current IBM drivers still have lots of room for improvement - see Internal cardreaders above as an example.

I suspect that eCS has plans to update some drivers by the simple expedient of replacing them with "home rolled" versions - maybe even open source ports from linux - over a period of time. Let's face it either eCS updates/replaces drivers as necessary or it will rapidly lose customers who need support for their devices. I suspect the current eCS worry is centered around video driver support now that SNAP is no longer being maintained


Anyhow, I hope we have managed to disagree successfully

Pete


Subject  :  Re:Yet another USB flashdrive problem...
Author  :  Shai robin.haberkorn@googlemail.com
Date  :  10 Jan, 2007 on 20:25

Pete (08 Jan, 2007 15:49):
Hi Robin

1280*1024 is a resolution in use here so that is not the problem.

Here is a total stab in the dark based on some experiences with 1 eCS1.1 system here a couple of years ago:

Open a command window in \ecs\bin (or wherever USBcfg is installed to).

Use the command attrib -r -s -h usbcfg.ini

Do you now have a usbcfg.ini file in that directory? - dir is usually quicker than waiting for the folder view to refresh.


If the answer is Yes then the system is setting the just created usbcfg.ini file as +r +s +h and that is preventing the basic settings from being written - this is definitely not something done by usbcfg.exe for obvious reasons

The resolution here, if some old brief notes are correct, was to run Cleanini followed by Checkini

Cleanini was available here http://www.c-arnold.de.vu but that site seems to have gone...

If you cannot find a copy I could email it to you.

Checkini is part of the wptools package which I think is supplied with eCS1.1


The above cleanini/checkini stopped the system from applying those rsh attributes to the SysInfo/2 pci.ini file (and maybe others that I was not aware of) and allowed the app to run normally.


I hope the above resolves the issue because I am now totally out of ideas...


Regards

Pete


I'm afraid, it didn't work - there's doesn't seem to be any usbcfg.ini. However I'm going to try Cleanini somewhen - maybe the system completely prevents (?) usbcfg from creating an ini file. Currently I've not much time - I'm in the midst of my Abitur (highschool diploma) tryouts.

Greetings,
Robin


Subject  :  Re:Yet another USB flashdrive problem...
Author  :  El Vato
Date  :  11 Jan, 2007 on 06:53

Pete (08 Jan, 2007 17:32):

El Vato (06 Jan, 2007 15:11):

Pete (06 Jan, 2007 02:52):
[...]

Pointless using old, unsupported drivers such as CW...

[...]


With all respect, I beg to differ with you on this statement.
[..]
|| ...



Hi El vato


You are more than welcome to disagree with me, maybe my statement was a little too strong but I have seen lots of posts with people struggling to get these drivers to work when the remedy was to remove them and install and configure the IBM drivers correctly. However, that does in all honesty only apply to situations where access to IBM updates are/were possible.


The statement was strong in the sense that it discourages third parties who are not priviledged to "own the rights" to analyze the OS/2 code; and yet, (those parties) try to offer what insight they can to the benfit of others and without monetary compensation.

Analyzing the precarious situation in which OS/2 finds itself at the moment, we can not afford to belittle anybody's contribution --especially if one considers that Wohlgemuth simply made available a hack --that he had developed for his own use-- with the hope that it would be useful for someone else --i.e. unsupported, as open source is.


Pete (08 Jan, 2007 17:32):
If the CW drivers work with some of your usb devices that, for whatever reason, the IBM USB drivers fail to work with Please carry on

I never argued against any other point in your post except that where you belittle Chris's contribution to OS/2.


Pete (08 Jan, 2007 17:32):
Worth thinking about is that a later USB device probably works with those drivers more by accident than design.

That is a necessary evil when the code is under wraps. If those who profit at the expense of keeping the OS/2 code beast chained and in the darkness can not do a better job, Chris' efforts are to be applauded.


Pete (08 Jan, 2007 17:32):
Also worth thinking about is that other drivers are often involved in whether the device works or not - os2dasd.dmd is an example.

If SSI can not even include a recent version of that driver in a default offering, then what would be the point in shelling out the equivalent of an XPP copy simply to struggle due to lack of support?

That is the same question that I asked of BigWarpGuy when not even those who advised him to buy a license for his used laptop are helping him solve his Wi-Fi problem.


Pete (08 Jan, 2007 17:32):
A common error is to use lowercase parameters to usbmsd.add and then expect it to work - Yes, case sensitive parameters, requires uppercase.


I have no argument with that either --I have never used small capitalization there. Notwithstanding, thanks for pointing that out. Having a Unix/Linux environment inside OS/2, I might have been tempted to do so when editting my Config.sys with my Elvis vi clone editor.


Pete (08 Jan, 2007 17:32):
Another thing people sometimes do not realise is that the mainboard BIOS needs to be setup correctly - most mainboards should have Legacy USB support Disabled. Forgetting this simple step can be a killer as regards USB support on OS/2 based systems.


Oddly, I have experienced the opposite. I had a most difficutl time with a Dell Dimension attempting to use only the cwUSBMSD.ADD support with multiple USB controllers. The solution turned out to be to enable Legacy USB support.


Pete (08 Jan, 2007 17:32):
I have never tried any of the CWUSB drivers because I have never needed to. Every mp3 player, flash drive, external hard drive, scanner, mouse tried here has worked with the IBM drivers - guess I've been lucky


Could be. But consider that you simply had the money to buy the latest support.

There are many people in Latin America and Eastern Europe and Africa that due to the high cost barrier are unable to participate in the OS/2 experience. When you consider that an eCS license costs the same as that of an WinXPP, yet with a mediocre support from SSI, it can be concluded which OS they would buy.

Notwithstanding, since those "emerging markets" (as they are called by the capitalists) can not afford neither of the above, those (markets) settle for the os that has a lower barrier of entry: Linux.

If those who control the OS/2 code were not living in the past and freed the OS/2 beast, or at least lowered the price of entry to something in the vicinity of what Novell charges for Linux support for one year, for instance, the OS/2 future would be less cloudy.


Pete (08 Jan, 2007 17:32):
I have 3 systems here all fitted with Internal USB multi cardreaders. These are specifically *Not* supported by the IBM drivers - but all work fine as long as the user remembers to Refresh the Drives Folder View or use the Refresh Removables object. Yes, the specific non-support is that inserting a card into a slot does not get the system to automatically display the attached drive - but it is attached and usable.


Yes, I am familiar with that.


Pete (08 Jan, 2007 17:32):
Sometimes some fiddling is required: in the case of external flash drives and mp3 players it has been necessary to destroy existing partitions and then recreate with LVM - no, have not needed to resort to DFSee for that yet.

I have never used DFSee. I do all my lower level disk procedures from the Linux side.


Pete (08 Jan, 2007 17:32):
I have not tried any flash drives that use fat32 yet though and suspect they may provide a little challenge.


The Linux formatting of FAT32 devices is more compatible with the WinXX methodology and file structure creation. You may want to try the procedure that I suggested to Shai ( I just hope that you will not give me an equally baseless argument).


Pete (08 Jan, 2007 17:32):
I do agree that the current IBM drivers still have lots of room for improvement - see Internal cardreaders above as an example.

Humm...thus, if there are problems with those, SSI does not have any responsibility???


Pete (08 Jan, 2007 17:32):
I suspect that eCS has plans to update some drivers by the simple expedient of replacing them with "home rolled" versions - maybe even open source ports from linux - over a period of time. Let's face it either eCS updates/replaces drivers as necessary or it will rapidly lose customers who need support for their devices. I suspect the current eCS worry is centered around video driver support now that SNAP is no longer being maintained

...hopefully they will realize that a new business model --more in sync with the times-- is a necessary condition to go forward with OS/2. All the major business organizations have realized that to survive they have to change "On Demand" of the current market conditions --and not remain within an old an inertial old school mind set.


Pete (08 Jan, 2007 17:32):
Anyhow, I hope we have managed to disagree successfully

Pete


It was a pleasure to "disagree" with you, Pete!

Best Regards !


Powered by UltraBoard 2000 <www.ub2k.com>