Using HL3120 drive with linux and plscsi

[DonJ]

Hi is it actually possible to set the drive to modeb in one pc and then 'hotswap' the sata cable to another mainboard and boot in windows on the other pc?

Thx

[Da Mafia]

Hi is it actually possible to set the drive to modeb in one pc and then 'hotswap' the sata cable to another mainboard and boot in windows on the other pc?

Thx

As long as the drive doesn't lose power i'm pretty sure it will work fine.

[geebee]

Hi is it actually possible to set the drive to modeb in one pc and then 'hotswap' the sata cable to another mainboard and boot in windows on the other pc?

Thx

why would you want to?

[DonJ]

Hotswapping did work.
I also found that it slows down Windows severley if you have a x360 game in the drive...

Well I had to hotswap cause only my server sata chipset worked with the slax cd but I couldn't boot windows without all my hdds attached (raid), so I had to hotswap the drive to my other pc (slax cd didn't work with that chipset).

[geebee]

Hotswapping did work.
I also found that it slows down Windows severley if you have a x360 game in the drive...

Well I had to hotswap cause only my server sata chipset worked with the slax cd but I couldn't boot windows without all my hdds attached (raid), so I had to hotswap the drive to my other pc (slax cd didn't work with that chipset).

ahh...i had the same problem. I just disconnected my raptors and attached a backup  ide HD with xp on.

[HODGEY]

I have booted up using slax and it shoes hdc and hde in fstab..but if i tr to remount HDE(HL DVD ROM) or try and run memdump, the program just kind of stalls and bails out. memdump just stalls and stays black, and if i try and mount it says "no medium found"  Anyne now whyt he drive shows up in fstab, yet i cant get it to dump??

[geebee]

you boot using slax, then you reboot the pc into windows. Is that what you were trying to do?

[HODGEY]

Nope....my drive wont detect in windows...trying to dump it using memdump.c after i compiled it...

[geebee]

$ ./memdump /dev/hdc 12200 8 8000 ./firmware.bin   ?

[HODGEY]

I ran that right away and it just freezes....and i have to mount the drive before it will do anything, because i also have to mount y flppy drive beore anything will run off of it. When i mount the sata drive it just hangs....any ideas on my its in fstab, but i cant mount it??

[probutus]

Hi again,

I know the problem with memdump... If you want to dump your firmware you should use the plscsi method (plscsi is also included in the dvd base mo package) mentioned on the first or second post in this thread; afaik memdump also works only if there is NO disk in the drive...

I am still looking into the sata(n) driver stuff; I still do not know why this spurious interrupt happens but there is a comment inside libata-core telling me that this *can* happen and is not fatal but what I see is that IF that happens the IRQ will be disabled therefore communication with the drive will not run properly anymore  (and all other devices linked to the same irq)

My next "idea" is to inject the hitachi cdb command just after the IDENTIFY_PACKET_DEVICE and redo the whole detection but this will ONLY work for hitachi drives then...
Another method could be to just kick the set_device_caps command out and do directly the modified inquriy command to the drive (this would work on both drives then but the hitachi needs a separate call to modeb then)

I received some logs in the last few days thanks very much for that but there is one small issue:

please do not send me the contents of the file /var/log/dmesg or /var/log/messages because my debug output is NOT in there.

you need to do:

dmesg > /tmp/dmesg.txt

and send me the /tmp/dmesg.txt file. for some reason the above mentioned files are not updated properly after startup anymore...

[SeventhSon]

afaik memdump also works only if there is NO disk in the drive...

Nah. I've used it to dump PFI/SS/response table/etc. from RAM with all kinds of discs in the drive.

[probutus]

@SeventhSon:sorry, I did not catch this...
I also can use memdump to cath PFI and the SS but when I try to read the flash in one go my drive seems to hang somehow...
(might also be a result of my weird cabling...)

@all:
If there is someone here with a sata->pata adapter, a hitachi drive and a sata-controller:
Can you please try the following:
1) put the drive in modeb (via sata/pata adapter)
2) connect the sata cable to the sata controller
3) boot the sata test-cd
4)login and type "dmesg >/tmp/dmesg.txt"
5) send me the dmesg.txt file

This would help me figure out the exact difference between modea and modeb with the native sata connection...
I assume
1)
- that there is no spurious interrupt anymore
- the drive responds to 0xEF and then sends the standard inquiry command..

This would mean that the root cause of the trouble is the spurious interrupt

or
2)
- the spurious interrupt is still there but
- the 0xEF command is working and the standard inquiry applied afterwards

This would mean that 0xEF causes the trouble

or
3) (the worst case)
everything is the same like in mode a

[SeventhSon]

I can see nothing in the handler than would cause command 0xEF to fail. Here's the commented disassembly. It's a really simple handler, only seems to support sub-command 3, which is the one we are interested in.

Code:

ROM:0002A8F2                 movm    [D2], (SP)      ! ATA SET FEATURES command
ROM:0002A8F4                 add     0xFC, SP ! 'n'
ROM:0002A8F7                 call    sub_1D723, [], 4 ! routine crap
ROM:0002A8FE                 movbu   (loc_CC6C+3), D2 ! D2 = (CC6F) (Features reg)
ROM:0002A901                 movbu   (loc_CC78), D0  ! D0 = (CC78) (Sector Count reg)
ROM:0002A904                 cmp     3, D2           ! is requested sub-command 3 (set tranfer mode)?
ROM:0002A906                 beq     loc_2A90B       ! yes, continue
ROM:0002A908                 jmp     loc_2A983       ! no, fail
ROM:0002A90B ! ---------------------------------------------------------------------------
ROM:0002A90B
ROM:0002A90B loc_2A90B:                              ! CODE XREF: ROM:0002A906j
ROM:0002A90B                 mov     0xF8, D2 ! '°'
ROM:0002A90E                 and     D0, D2          ! D2 = transfer type (upper 5 bits of Sector Count reg)
ROM:0002A910                 beq     loc_2A924       ! branch if transfer type is 00000 (PIO)
ROM:0002A912                 cmp     8, D2
ROM:0002A914                 beq     loc_2A94B       ! branch if transfer type is 00001 (PIO flow control)
ROM:0002A916                 cmp     0x10, D2
ROM:0002A918                 beq     loc_2A95E       ! branch if transfer type is 00010 (retired)
ROM:0002A91A                 cmp     0x20, D2 ! ' '
ROM:0002A91C                 beq     loc_2A960       ! branch if transfer type is 00100 (Multiword DMA)
ROM:0002A91E                 cmp     0x40, D2 ! '@'
ROM:0002A920                 beq     loc_2A970       ! branch if transfer type is 01000 (Ultra DMA)
ROM:0002A922                 bra     loc_2A983       ! else, bail out
ROM:0002A924 ! ---------------------------------------------------------------------------
ROM:0002A924

*snip*

ROM:0002A970
ROM:0002A970 loc_2A970:                              ! CODE XREF: ROM:0002A920j
ROM:0002A970                 and     7, D0           ! Ultra DMA
ROM:0002A970                                         ! D0 = mode
ROM:0002A973                 mov     D0, D1          ! D1 = mode (lower 3 bits of Sector Count reg)
ROM:0002A974                 extbu   D1
ROM:0002A975                 cmp     6, D1           ! is the requested mode greater than 5?
ROM:0002A977                 bge     loc_2A983       ! yes, fail
ROM:0002A979                 movbu   D0, (word_63B)  ! no, (63B) = mode
ROM:0002A97C                 mov     2, D0
ROM:0002A97E
ROM:0002A97E loc_2A97E:                              ! CODE XREF: ROM:0002A96Ej
ROM:0002A97E                 movbu   D0, (word_636+1) ! (637) = 2
ROM:0002A981                 bra     loc_2A989       ! return
ROM:0002A983 ! ---------------------------------------------------------------------------

* There is no sign of any modeA/B differences.
* The command should work with the input registers it receives
Features: 0x03 (set transfer type)
Sector Count: 0x45 (transfer type UDMA, mode 5)
LBA Low/Med/High: 0x00/0x00/0x00

I would be very surprised if this command was the cause of your problem. Hopefully someone can try your experiment and we'll know for sure.

[probutus]

it really seems that the spurious interrupt in the beginning is the root of all evil... But afaik, the result of mode_b is switching the ioport which controls the eject line to an output... which is the same like using the hw-modeb method.. (this means we have case3 the worst case)

Thanks to Tiros and SeventhSon for the hint 

so the following things need to be done:

1) catch the unexpected interrupt or mask it out (still have to find out how to do that) maybe booting with irqpoll could be an option..
2) directly after doing an identify packet device we have to issue the modeb cdb command...

I will modify the driver and pubish it for alpha testing as soon as possible (have to leave now for BBQ and nobody believes me that I cant go 'cause of headaches)

[SeventhSon]

it really seems that the spurious interrupt in the beginning is the root of all evil...

Certainly looks that way

But afaik, the result of mode_b is switching the ioport which controls the eject line to an output... which is the same like using the hw-modeb method.. (this means we have case3 the worst case)

This is news to me. I'm not aware of modeB switching eject to an output pin. But, then again, I'm not aware of a lot of things. What makes you say that it does?

I will modify the driver and pubish it for alpha testing as soon as possible (have to leave now for BBQ and nobody believes me that I cant go 'cause of headaches)

Haha. Gotta stay social.

[SeventhSon]

Grrr. Double post. Quoted myself instead of editing.

[probutus]

I analyzed some logs and it seems that I have tough news for native sata support:

It seems that we cannot prevent the spurious interrupt somehow since we do not know if this is meant for us or any other device on the same irq....

but there is still a small chance left; its named irqpoll

Can someone please hook on the hitachi drive and enter on the boot: prompt of the sata-testcd the following:

slax irqpoll

and pm me the output? If we are lucky the irq will be disabled but the driver should keep working (so no 0xEF timeout...)...

[Da Mafia]

I analyzed some logs and it seems that I have tough news for native sata support:

It seems that we cannot prevent the spurious interrupt somehow since we do not know if this is meant for us or any other device on the same irq....

but there is still a small chance left; its named irqpoll

Can someone please hook on the hitachi drive and enter on the boot: prompt of the sata-testcd the following:

slax irqpoll

and pm me the output? If we are lucky the irq will be disabled but the driver should keep working (so no 0xEF timeout...)...

I could do this for you mate I just dont know how to save the read out to my HDD and my Hitachi will be connected to my native sata, is the the kinda read out your after.

[probutus]

Thanks for the help!

if you have a floppy disk you can do the following:

after booting with slax irqpoll

1) insert formatted disk in drive
2) login as root
3)type the following:

mkdir /mnt
mount /dev/fd0 /mnt
dmesg > /mnt/dmesg.txt
umount /mnt
reboot

4) when the system reboots you should have a file called dmesg.txt on your disk