Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Lars

Pages: [1] 2 3 ... 95
1
Applications / Re: EXIFTool
« on: April 23, 2025, 05:40:38 pm »
I think that would just ask for desaster if you already have Perl installed via YUM/RPM.

You would have an outdated Perl installed via WarpIn alongside an up-to-date installation via YUM/RPM without really knowing what is being used by the EXIF tool.

The best way would be to remove the idiotic dependency in the WIS script. Unfortunately, I have no time to do it and for the time being, Steve's suggestion is likely the way to go forward.

2
Applications / Re: EXIFTool
« on: April 23, 2025, 01:47:49 am »
As I mentioned elsewhere: the WPI package script needs rework to get rid of the dependency on the Perl WPI package as Perl is now delivered via YUM/RPM.

3
Programming / Re: DOSBox-x - infinite loop in configure/make
« on: April 20, 2025, 02:30:10 pm »
Just a guess: try DID_DIRECTORY_SELECTED.

4
Applications / Re: SSL update: Firefox XUL.DLL can no longer load
« on: April 18, 2025, 01:24:16 pm »
No ssl3.dll im my Firefox directory (containing xul.dll, lgpllibs.dll, mozdqlt3.dll).
Either AN provides ssl3.dll together with their delivery of Firefox or maybe you copied it over yourself.

5
Applications / Re: SSL update: Firefox XUL.DLL can no longer load
« on: April 18, 2025, 12:20:35 pm »
Thanks, that did the trick. I still wonder why "ssl3.dll" got lost on my system.

6
Applications / SSL update: Firefox XUL.DLL can no longer load
« on: April 18, 2025, 12:01:12 pm »
Hallo,

I updated openssl just a few days ago. Now XUL.DLL (part of Firefox) can no longer load as it complains that ssl3.dll is missing which is true.
Is there a newer build of XUL.DLL that uses the updated SSL11.DLL ? Or maybe a newer delivery of Firefox ? I have no AN account.
What I can also find on my system is "ossl3.dll" but not "ssl3.dll". I doubt that I can simply rename the file as the internal DLL name is "ossl3".


7
Multimedia / Re: Updated Uniaud32 build
« on: April 16, 2025, 03:40:33 pm »
Thanks Sigurd, I'll have a look at these a bit later. I've just been thinking about this part of your testlog:
Code: [Select]
Period size min=2f0 max=2f0
Error -22 second time.. Bailing

This comes from:
https://trac.netlabs.org/uniaud/browser/GPL/branches/uniaud32-exp/lib32/sound.c#L1015
& https://trac.netlabs.org/uniaud/browser/GPL/branches/uniaud32-exp/lib32/sound.c#L1025

Error -22 is EINVAL or Invalid Parameter. This suggests that one of the parameters set between https://trac.netlabs.org/uniaud/browser/GPL/branches/uniaud32-exp/lib32/sound.c#L965 & https://trac.netlabs.org/uniaud/browser/GPL/branches/uniaud32-exp/lib32/sound.c#L995 are causing the problem. The trick is know which one.

What I might do is create a specific build which writes each parameter one by one so we can see which one causes the issue.

The logic is really twisted. Without any evidence, I would think that it is possible that:
"periodbytes*nrperiods"
might exceed
"bufsize = hw_param_interval((&params), SNDRV_PCM_HW_PARAM_BUFFER_BYTES)->max;"
which of course is forbidden.

Maybe you can print out these values to begin with.

8
Multimedia / Re: Updated Uniaud32 build
« on: April 16, 2025, 02:36:50 pm »

@Lars - I think about it once again, regarding differences in hardware - the only thing I did during testing was switching form 16 to 1 CPU (/MAXCPU=1 Switch in config.sys). Do not know, if that effect things in any way


The kernel will create one management structure per CPU. If you have 1 CPU instead of 16 (known to OS/2, I mean), that will likely make a difference.

9
Multimedia / Re: Updated Uniaud32 build
« on: April 15, 2025, 06:47:16 pm »
ok, thanks.

For the 2 trap screens that you posted, that means:

trap screen 1: EIP = E1DA82E1 -> what ??? Have you run this on another computer or have you changed configuration ?

trap screen 2: EIP = E5D780A2 -> offset = E5D780A2 - E5CDB000 = 9D082

I find this in the MAP file:  0003:0009D072       component_match_add_release_

That would mean the trap occurs in "component_match_add_release". Provided that the (debug) MAP file is close enough to the binary the trap occured in.

10
Multimedia / Re: Updated Uniaud32 build
« on: April 15, 2025, 08:41:42 am »
Forgot to mention: C "static" routines will not show up in the map file. That is unfortunate but it is the way it is (every device driver writer should never use "static" on a routine ...). But you can find the closest (public) routine name preceding the trap location and then go forward from there to have a guess of what "static" routine has possibly failed.

@Paul: are you distributing test versions as "release" or as "debug" versions ? I am asking because of the MAP file to look at ...

11
Multimedia / Re: Updated Uniaud32 build
« on: April 15, 2025, 08:13:56 am »
Until Sigurd can provide the missing info, here are the "closest" routine names in which Sigurds Traps occur (taking the "release" MAP file from Paul):
0x82E1   -> OSS32_QueryNames_
0x182E1 -> snd_timer_global_register_
0x282E1 -> pci_iounmap_
0x382E1 -> snd_ak4531_mixer_
0x482E1 -> snd_hda_gen_check_power_status_
0x582E1 -> snd_hda_gen_check_power_status_
0x682E1 -> hda_component_manager_free_
0x782E1 -> snd_emu10k1_audigy_midi_
0x882E1 -> snd_ymfpci_pcm_4ch_

If I would have to guess, I would think that "snd_ak4531_mixer_" is the routine to look at.

And for the other trap:
0x80A2   -> OSSToALSAVolume_
0x180A2 -> snd_timer_global_register_
0x280A2 -> pci_iounmap_
0x380A2 -> pci_iounmap_
0x480A2 -> snd_hda_gen_check_power_status_
0x580A2 -> snd_hda_gen_check_power_status_
0x680A2 -> hda_component_manager_playback_hook_
0x780A2 -> snd_emu10k1_audigy_midi_
0x880A2 -> snd_ymfpci_pcm_4ch_


So, maybe "snd_ymfpci_pcm_4ch_" is the more likely culprit (if we assume that the two traps occur in the very same routine). We will know more once Sigurd provides the info.

12
Multimedia / Re: Updated Uniaud32 build
« on: April 15, 2025, 08:00:33 am »
So,I hope this is of help.

I tried Theseus 4 (with Switch /A:2 only) and attach the result as well. When trying to enter "eip", the error message appears.

What else can I provide to help?

Hi Sigurd,

do this in Theseus to get to the info that is needed to locate your traps:
1) in Theseus: System->General System->Modules
2) Search for string "UNIAUD32"
3) if the line is found, double click on the very left hex value that goes under "MTE @"
4) a screen will open, scroll down to the bottom of that screen
5) What you will see is the "Object Table", the "flags" will tell you for each object if it is data or code and if it is 16-bit or 32-bit
6) find the line where the "flags" say "readable executable shared 32-bit". If it is more than one line, pick the line where the value for "size" is the largest (that is very likely the main 32-bit code object where 99% of the functionality is implemented)
7) what is needed is the "address" value of that very same line. The "address" is the base adress of the code object. The offset of your trap into that code segment is then computed as:
offset = EIP - "address"
and the offset is necessary to locate the trapping routine in the MAP file (or SYM file) that Paul has provided

If you are lost: just take a screen shot of the lower half of the "MTE" window you opened in 4).

One important note: if you do not add/delete any device/filesystem/etc. drivers to config.sys or otherwise do fundamental changes  (VIRTUALADRESSLIMIT, other kernel, whatever), the "address" value will likely never change. However, if you add drivers that value might shift. To be on the safe side, you can always look at Theseus to make sure.


In the end, you would be able to do this yourself. We are too few developers so you will have to learn to become one :-)

Cheers, Lars

13
Multimedia / Re: Updated Uniaud32 build
« on: April 14, 2025, 08:47:27 am »
Hi Lars, note that source code reference is where the system is hanging with HDA under virtualbox - I believe Sigurd's problem is elsewhere in the code, so your reading of the trap is probably useful. I haven't spent any time of analysing the trap screens yet.

Ok. My hope would be that Sigurds trap screens will give an indication of what REALLY went wrong. In both cases, it is a NULL pointer issue.

14
Multimedia / Re: Updated Uniaud32 build
« on: April 14, 2025, 08:23:12 am »
For sure, it`s a NULL pointer error: CR2 = 00000004 which should be a linear address but likely something is being addressed via [EBX+4] with EBX = 0 (or EAX or ECX instead of EBX, as can be seen in the trap screen).

That said, the error location in soundmixer.c:
370   if(pHandle == NULL || pHandle->magic != MAGIC_MIXER_ALSA32) {
371   printk("Invalid handle in OSS32_MixSetVolume\n");
372   DebugInt3();
373   return OSSERR_INVALID_STREAMID;
374   }
375   //set operation to non-blocking
376   pHandle->file.f_flags = O_NONBLOCK; <------- ERROR

seems to make that unlikely, as "pHandle" is tested in line 370 if it is a NULL pointer. Unless there is some code that executes in parallel (from a context handler, for example) that would make the memory that pHandle points to invalid while you are trying to access it. Note that "pHandle" is actually the "streamid" that you are being passed in and that might be deallocated where you do not want it to.

@Paul: have you already located Sigurds Trap Position "0xE1DA82E1" and "0xE5D780A2" in the source code ? Given the memory object info for USBAUD2.SYS, it must be in the "EXECUTABLE, READABLE, 32-bit" memory object at either of these offsets:
0x82E1
0x182E1
0x282E1
0x382E1
0x482E1
0x582E1
0x682E1
0x782E1
0x882E1

and analogue for 0xE5D780A2:
0x80A2
0x181A2
etc.

In order to get a confirmed offset, Sigurd would need to use Theseus to display the memory object layout for module "UNIAUD32" but since it hangs/traps already on bootup, that will be a problem ...

15
Programming / Re: EDM/2 - The API Project - Undocumented
« on: April 09, 2025, 05:47:55 pm »
"DrgQueryFormat", as a starter: https://www.gladir.com/CODER/COS2/drgqueryformat.htm

ULONG DrgQueryFormat(PDRAGITEM dragItem, PCSZ a, ULONG b, PCSZ c, ULONG d);

Translation: "This function allows to query the data format of a drag operation."

The fun part will be to find out what "a", "b", "c", "d" stand for. I would suspect that "b" is the buffer size of string "a" and "d" is the buffer size of string "c".
My gut feeling is that this function is replaced by functions "DrgQueryNativeRMF" and "DrgQueryNativeRMFLen" plus possibly "DrgQueryTrueType" and "DrgQueryTrueTypeLen".



Pages: [1] 2 3 ... 95