TRAP 000E with 190

[holger]

I get an TRAP 000E in OS2KRNL @ CS:EIP 168:FFF40B09 on about every second boot. This happens on processing of INIT_COMPLETE - just before WPS starts. If boot was ok (wihout Trap) driver is running fine.

I reverted USBEHCD to 177 state -> running fine. I also tried USBEHCD 186 -> same Trap issue.

I did not test the other Versions of your driver before.

Kernel: 14.106 SMP with 2 CPU
ACPI: ACPI.PSD /VW Version 3.21.07
USB: 82801H (ICH8 Family) USB UHCI Controller

82801H (ICH8 Family) USB2 EHCI Controller

[Lars Erdmann]

Hm, interesting. The trap E happens in a routine called "pgDriver". Seems like that is the routine that pages the drivers into memory when being loaded via config.sys.

I'll have to think about that. I might need to lock down the 32-bit segment. Funny, I have had no reports so far.

Is this system fairly short on memory or do you have many drivers loaded (more than an average system) ?

[Lars Erdmann]

all drivers with all segments marked with IOPL

[Lars Erdmann]

Can you try holger.zip ? Don't expect any functional changes. I try to fix them so that all driver segments remain resident in memory because that's what the issue seems to be.

[holger]

thanks - have tried holger.zip, but failed. After third reboot same Trap message.

Tried a REM before ACPI.PSD -> good. Tried a REM before CACHEF32.EXE (after reenabling ACPI) -> good. Reenabling CACHEF32.EXE -> Trap

Looks like a missing Spinlock or Semaphore before a devHlp Call or access to a Pointer reference to me. The Trap may be raised by the second CPU-Core running on same Resource as the first. I've been looking closer to the point of failure - it is after loading all drivers, executing the RUN and CALL statements in config.sys (but not always at the same point) so it's at the point both CPU Cores are running. There might be a small timing hole where this race condition can happen. That's why it does not happen on every boot and every machine running SMP and even the cause for running ok with small changes in config.sys.

My system has 2 GB of physical memory - should be enaugh i think. I have many drivers loaded - Theseus tells 582 MB Kernel memory allocated, but only 85 MB committed. Anyway, i don't think that short memory is the cause. 177 Version is stable, 186 is not so something must have been changed between them potentially causing SMP issues. Only USBEHCD is affected, the other drivers run fine (or the race condition does not happen here).

[Lars Erdmann]

It's more likely a Problem with ACPI.PSD. I guess you updated ACPI.PSD over time.

I can see no reason for the EHCI driver to trap already on INIT and you say that it works normal thereafter.
For this Problem, the difference is that 177 Version does not contain a 32-bit Segment whereas for 186, it does. Sorry but I cannot help you with that.

You should try an older Version of ACPI.PSD and or you should only run on one core (ACPI.PSD has a Switch for that). See if that makes a difference.

[holger]

My ACPI.PSD is the latest available one.

Some more strange thing today - even 177 produced a Trap on every boot. Reverted to 172 (USBEHCI only) -> booted ok.

Original IBM Driver did newer make souch a Trap (but is much slower). I'll try to find some differences with ACPI.PSD.

[holger]

OK, tested ACPI.PSD with /MAXCPU=1 -> TrapE, so it is NOT SMP Problem and I was wrong. Now, as the Trap comes up on every boot, testing is much easier.

I moved CACHEF32.EXE to the bottom of my config.sys and now there seems to be all fine.

Strange, maybe there's another driver making trouble (or even the kernel) that did not come up until now or I have some partial broken physical memory space.

For me it works now so Ticket might be closed. Thank you!

[Lars Erdmann]

The cause of the trap E is not directly attributable to USBEHCD.SYS as it occurs (or not) when other device drivers / deamon programs are placed into different order in config.sys.

[Lars Erdmann]

Milestone deleted