Folks,
I have a target machine which has a serial port but does not have Firewire port.
The problem is the target machine does not have a available PCIe port.
There is a PCex16 port but that is used by a DVI card.
I came across this adapter and wondering whether it would work.
This is a SATA to firewire adapter.
http://www.cooldrives.com/sata-to-firewire-usb-mini-converter.html
My question is whether this would work for Firewire Debugging in WinDbg.
-Shan
One word. NO NO NO.
You’re stuck with serial, or if one of the periepheral adapters happens to
have USB you could replace it with an adapter that has USB and 1394.
The personal opinion of
Gary G. Little
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, October 27, 2009 7:23 AM
To: Kernel Debugging Interest List
Subject: [windbg] SATA to Firewire Adapter
Folks,
I have a target machine which has a serial port but does not have Firewire
port.
The problem is the target machine does not have a available PCIe port.
There is a PCex16 port but that is used by a DVI card.
I came across this adapter and wondering whether it would work.
This is a SATA to firewire adapter.
http://www.cooldrives.com/sata-to-firewire-usb-mini-converter.html
My question is whether this would work for Firewire Debugging in WinDbg.
-Shan
WINDBG is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
__________ Information from ESET Smart Security, version of virus signature
database 4547 (20091027) __________
The message was checked by ESET Smart Security.
__________ Information from ESET Smart Security, version of virus signature
database 4547 (20091027) __________
The message was checked by ESET Smart Security.
The target machine needs the real 1394 hw on it. The underlying kernel debugger transport talks directly to the host controller, it does not load client drivers so there is no way such a converter would work
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: xxxxx@gmail.com
Sent: Tuesday, October 27, 2009 5:22 AM
To: Kernel Debugging Interest List
Subject: [windbg] SATA to Firewire Adapter
Folks,
I have a target machine which has a serial port but does not have Firewire port.
The problem is the target machine does not have a available PCIe port.
There is a PCex16 port but that is used by a DVI card.
I came across this adapter and wondering whether it would work.
This is a SATA to firewire adapter.
http://www.cooldrives.com/sata-to-firewire-usb-mini-converter.html
My question is whether this would work for Firewire Debugging in WinDbg.
-Shan
—
WINDBG is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
That would be a no.
mm
xxxxx@gmail.com wrote:
Folks,
I have a target machine which has a serial port but does not have Firewire port.
The problem is the target machine does not have a available PCIe port.
There is a PCex16 port but that is used by a DVI card.I came across this adapter and wondering whether it would work.
This is a SATA to firewire adapter.http://www.cooldrives.com/sata-to-firewire-usb-mini-converter.html
My question is whether this would work for Firewire Debugging in WinDbg.
Several people have told you “no”, but I wanted to point out why.
Read the description of the device. This lets you plug in a Firewire
DISK to a SATA disk port. It does not create a general-purpose Firewire
port. The computer hardware is going to see SATA, not Firewire.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks Folks for the responses.
.Read the description of the device. This lets you plug in a Firewire
DISK to a SATA disk port. It does not create a general-purpose Firewire
port. The computer hardware is going to see SATA, not Firewire.
That’s what I suspected. Nevetheless, wanted to check with you guys.
Folks,
Just wanted to check something with you guys. Basically serial debugging is very slow and I am
left with no option but to use serial debugging. I was wondering if I can change the baudrate to
something higher than 115200bps ( I think the max is 115200 in WinDbg ). Modern UART supports svery high baudrates or atleast the ones that I have in my system.
My understanding is ( pls correct me here if I am wrong.) the NT kernel uses the kdcom.dll to configure the UART and then uses the exported functions to send data to the serial port.
kdcom.dll programs the UART registers to use 115200 baudrate or whatever you put in boot.ini under baudrate.
Assuming you have access to the datasheet of the UART that’s there in the system, we just change the I/O registers to the max baudrate that we want on the target and do the samething on the host side as well.
That way, we could be running at speeds greater than 115200bps. Has anybody tried along those lines?
I guess you never wrote programs under DOS that use the serial port
directly. The serial ports of that era were the 16550AFN chip. A rather
large chip from National Semiconductor. The value for the divisor was
limited to producing a speed of 115200. Since Windows NT was developed in
that time frame, there is still ‘probably’ no support for a smaller divisor
nor the understanding of later serial chipsets that allowed other speeds to
be used. Only Microsoft knows for sure, but if you get the specifications
for that serial chip and work within its defined limitations you should be
golden. Using USB is another option, but it costs almost $100 USD for the
special adapter including tax & S&H if in the USA. Until Windows 7, 1394a
did not support suspend or hibernation correctly. The whole kernel debugger
was designed around serial and only recently has support for other
transports begun to approach its level of support and functionality.
I use 1394a all the time, but very infrequently I have to use serial or USB
depending upon the target OS and available ports. Always buy a good TI
chipset based 1394a adapter for PCI/PCI-X/PCIe. Koutech has some good ones,
but you have to call their tech support to find which of their boards use
the TI chipset. OSR sells a good PCI board and a good Cardbus one for
notebooks that will work. PYRO PCI64 is a good one that works in both PCI &
PCI-X since the card has the notch that allows it to work in both slots.
Always disable the 1394a device on the target, even though later operating
systems are supposed to have this fixed, but a disabled device looks better
than a yellow banged device as the OS will not allow access to it for other
uses when it is being used for kernel debugging.
wrote in message news:xxxxx@windbg…
> Folks,
>
> Just wanted to check something with you guys. Basically serial debugging
> is very slow and I am
> left with no option but to use serial debugging. I was wondering if I can
> change the baudrate to
> something higher than 115200bps ( I think the max is 115200 in WinDbg ).
> Modern UART supports svery high baudrates or atleast the ones that I have
> in my system.
>
> My understanding is ( pls correct me here if I am wrong.) the NT kernel
> uses the kdcom.dll to configure the UART and then uses the exported
> functions to send data to the serial port.
>
> kdcom.dll programs the UART registers to use 115200 baudrate or whatever
> you put in boot.ini under baudrate.
>
> Assuming you have access to the datasheet of the UART that’s there in the
> system, we just change the I/O registers to the max baudrate that we want
> on the target and do the samething on the host side as well.
>
> That way, we could be running at speeds greater than 115200bps. Has
> anybody tried along those lines?
>
>
>
>
>
>
>
>
>
>
It is true that the serial support in kdcom.dll is limited to the 16550
programming interface.
It’s also true that higher baud rates don’t tend to work unless you can make
the code interrupt driven. And an interrupt-driven kdcom.dll would be very
hard to do, given that you want it to depend on almost no other parts of the
system.
–
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group
This post implies no warranties and confers no rights.
“David Craig” wrote in message news:xxxxx@windbg…
> I guess you never wrote programs under DOS that use the serial port
> directly. The serial ports of that era were the 16550AFN chip. A rather
> large chip from National Semiconductor. The value for the divisor was
> limited to producing a speed of 115200. Since Windows NT was developed in
> that time frame, there is still ‘probably’ no support for a smaller
> divisor nor the understanding of later serial chipsets that allowed other
> speeds to be used. Only Microsoft knows for sure, but if you get the
> specifications for that serial chip and work within its defined
> limitations you should be golden. Using USB is another option, but it
> costs almost $100 USD for the special adapter including tax & S&H if in
> the USA. Until Windows 7, 1394a did not support suspend or hibernation
> correctly. The whole kernel debugger was designed around serial and only
> recently has support for other transports begun to approach its level of
> support and functionality.
>
> I use 1394a all the time, but very infrequently I have to use serial or
> USB depending upon the target OS and available ports. Always buy a good
> TI chipset based 1394a adapter for PCI/PCI-X/PCIe. Koutech has some good
> ones, but you have to call their tech support to find which of their
> boards use the TI chipset. OSR sells a good PCI board and a good Cardbus
> one for notebooks that will work. PYRO PCI64 is a good one that works in
> both PCI & PCI-X since the card has the notch that allows it to work in
> both slots.
>
> Always disable the 1394a device on the target, even though later operating
> systems are supposed to have this fixed, but a disabled device looks
> better than a yellow banged device as the OS will not allow access to it
> for other uses when it is being used for kernel debugging.
>
> wrote in message news:xxxxx@windbg…
>> Folks,
>>
>> Just wanted to check something with you guys. Basically serial debugging
>> is very slow and I am
>> left with no option but to use serial debugging. I was wondering if I can
>> change the baudrate to
>> something higher than 115200bps ( I think the max is 115200 in WinDbg ).
>> Modern UART supports svery high baudrates or atleast the ones that I have
>> in my system.
>>
>> My understanding is ( pls correct me here if I am wrong.) the NT kernel
>> uses the kdcom.dll to configure the UART and then uses the exported
>> functions to send data to the serial port.
>>
>> kdcom.dll programs the UART registers to use 115200 baudrate or whatever
>> you put in boot.ini under baudrate.
>>
>> Assuming you have access to the datasheet of the UART that’s there in the
>> system, we just change the I/O registers to the max baudrate that we want
>> on the target and do the samething on the host side as well.
>>
>> That way, we could be running at speeds greater than 115200bps. Has
>> anybody tried along those lines?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
I remember last time DriverStudio had the option to debug using Ethernet port. But unfortunately they stopped supporting DriverStudio. I did notice that WinDBg has added a tab called NET but this is not supported. So I was wondering when the WinDbg team has plans to support kernel debugging over ethernet? ( Maybe the Microsoft folks can provide some info here…it’s been more than 6 months since the last WinDbg release… )
Thanks,
Shan
That has been answered many times, the NET tab was an internal thing that
slipped out. Beyond that Microsoft will not say. The challenges of an
ethernet controller is that there are a lot of models, and you have to live
within the rules of being on the wire.
–
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
wrote in message news:xxxxx@windbg…
>I remember last time DriverStudio had the option to debug using Ethernet
>port. But unfortunately they stopped supporting DriverStudio. I did notice
>that WinDBg has added a tab called NET but this is not supported. So I was
>wondering when the WinDbg team has plans to support kernel debugging over
>ethernet? ( Maybe the Microsoft folks can provide some info here…it’s
>been more than 6 months since the last WinDbg release… )
>
> Thanks,
> Shan
>
>
> Information from ESET NOD32 Antivirus, version of virus
> signature database 4569 (20091103)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
Information from ESET NOD32 Antivirus, version of virus signature database 4569 (20091103)
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com