Mike,
Good to hear from you. Please let me know what you find out when you
try PCIe. It took a BIOS upgrade by I have now got the ExpressCards to
work on my T43 ThinkPad. However, this is not a core duo machine where
the problems seem to be reported. So far I have been unable to get any
official confirmation of a core duo / ExpressCard problem. I will let
you know if I get such.
BTW is the Dell m65 on-board interface 1394a or b? The website and product
brochure don’t say. - Mike
The Dell m65 has onboard 1394a. My source (can’t speak to reliability
yet) believes that the Dell onboard firewire fails because of the
particular non-TI chip that is used and so is a different issue than
the ExpressCard issue.
Robert Newton
VX Technologies
Mike,
I’ve now got official confirmation from Dell that there is a problem
with the 945 chipset (at least on the M90) and that they are (so far
unsuccessfully) working on a BIOS fix for it. My problem is with an
M65 but I believe it is likely the same problem. Infact, my impression so far is
that this is a problem with core duo processors and the 945 chipset
and not specifically with Dell. That said, I have managed to run
successfully on a 1394a ExpressCard plugged into a MacBook Pro
(booting Windows).
Robert Newton
VX Technologies
Hi Robert - that’s good news. I haven’t got round to testing PCIe cards on
my dual core test machine yet - probably next week but will post any results
here. I can confirm that 1394b interfaces (e.g Adaptec 8300A)
continue not to work properly with XP SP2 and that the MS fix here works -
Mike.
http://www.microsoft.com/downloads/details.aspx?FamilyId=CA0F2007-18B5-4112-8BD6-8BF4BD3130B9&displaylang=en
----- Original Message -----
From: Robert Newton
To: Windows System Software Devs Interest List
Sent: Thursday, November 02, 2006 6:28 PM
Subject: Re[2]: [ntdev] Firewire ExpressCard (Core Duo - 945) Problem
Mike,
I’ve now got official confirmation from Dell that there is a problem
with the 945 chipset (at least on the M90) and that they are (so far
unsuccessfully) working on a BIOS fix for it. My problem is with an
M65 but I believe it is likely the same problem. Infact, my impression so
far is
that this is a problem with core duo processors and the 945 chipset
and not specifically with Dell. That said, I have managed to run
successfully on a 1394a ExpressCard plugged into a MacBook Pro
(booting Windows).
Robert Newton
VX Technologies
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Hi there,
We are experiencing very similar symptoms as described in original post from Robert, but on different setup - using 3 out of 4 different PCMCIA 1394a adapters (can post the list if anyone is interested) on Dell precision M65 (and M70 which is Pentium M and Intel 915). What we are observing with 1394 bus analyzer and our driver is that some Isoch packets are lost - these are present on the bus but never came out from the Firewire stack. What we have also found similar to Robert’s case is that if there is certain CPU load then issue is gone - all Isoch packets are received intact. Further we wrote a program which creates a thread running at lowest possible priority and doing nothing else but:
while (1) ;
or, in other words runs non empty idle loop instead of default Windows “power saving” idle loop in kernel.
With this thread running there is no problems with Isoch packets.
Our guess is that Dell’s software/firmware/hardware places processor into kinda sleep mode, and as the result it is unable to service interrupts from 1394 adapter. When “while (1); “ is running it seems that processor is awake all the time.
Comments and ideas are welcome.
With best regards,
Max Larin, SOFTHARD Technology, Ltd.
> Hi there,
We are experiencing very similar symptoms as described in original post from Robert, but on different setup - using 3 out of 4 different PCMCIA 1394a adapters (can post
the list if anyone is interested) on Dell precision M65 (and M70 which is Pentium M and Intel 915). What we are observing with 1394 bus analyzer and our driver is that
some Isoch packets are lost - these are present on the bus but never came out from the Firewire stack. What we have also found similar to Robert’s case is that if there is
certain CPU load then issue is gone - all Isoch packets are received intact. Further we wrote a program which creates a thread running at lowest possible priority and
doing nothing else but:
while (1) ;
or, in other words runs non empty idle loop instead of default Windows “power saving” idle loop in kernel.
With this thread running there is no problems with Isoch packets.
Our guess is that Dell’s software/firmware/hardware places processor into kinda sleep mode, and as the result it is unable to service interrupts from 1394 adapter. When
“while (1); “ is running it seems that processor is awake all the time.
Comments and ideas are welcome.
With best regards,
Max Larin, SOFTHARD Technology, Ltd.
That is very very interesting. As well as our ExpressCard problem we
also had problems with packet loss with PCMCIA on M65’s and M70’s.
In
our case we were able to control the problem by using only as much
bandwidth as was necessary to send our data, reducing the size of the
isoch packets. At the time I had noted that, strangely, the missing
packets seemed to occur near the start of a data frame after there had
been a small break from the end of the previous frame (30 frames per
second). This is only true for the PCMCIA problem but I remember
thinking that it was acting as if it had to wake up before it could
get the data from the card to memory. The data loss that I experiance
with the ExpressCard does not follow this pattern.
I will test out the while loop on Monday with both PCMCIA and Express
Card 1394a and see if I can confirm your results. Do you mind if I
send this information and your email address to our Dell contact? Did
you take this up with Dell and, if so, do
you have a Dell case number that I can reference?
Robert Newton
VX Technologies.
Hi Robert,
Searching Dell support we stumbled across the following topic:
http://support.dell.com/support/topics/global.aspx/support/dsn/en/document?docid=F015E6A79DFF46ABE030030ABD627473&c=us&l=en&s=dhs
and for M70 (based on Pentium M and 915) this registry entry fixed the problem.
Unfortunately M65 behavior is not affected by this patch, but while(1); still does help.
It could be the same C3 (or other sleep mode) latency issue for CoreDuo/945 systems, but different method to cure it.
We did not report the problem to Dell and have no case id reference for that.
Please feel free to provide my details to your Dell contact.
Another aspect is whether this CPU behavior can be affected via ACPI interface and respective handling of IRP_MJ_POWER requests?
Anybody have any clue?
Max Larin
SOFTHARD Technology Ltd.