Using HL3120 drive with linux and plscsi

[probutus]

after analyzing loads of kernel logs I found out the following:

-If you boot the sata-testcd (which does NOT work for sil3112 and sil3114; for that you need the live-cd.iso) on the boot prompt with:

slax irqpoll

the spurious interrupt does still occur but it seems not to hamper device detection (we get millions of disconnect/connect messages due to the interrupt but the sequence seems to be intact..)

the drive should then be recognized as /dev/scd0 (but still in modea)

so if you issue

modeb /dev/scd0

the drive should get into modeb..

modeb is only available if you integrate the dvd base v2 mo package into the testcd

I can not test it myself since I do currently have no access to my 3120 (only to my 8163)

[geebee]

you mean try it on a 31122/3114? or another chipset?

[probutus]

if you have a 3112 or 3114 you should use the live-cd.iso since there the old ide driver is used

but remember: on a 3114 only 2 of 4 ports are working.. (due to port mapping problems)

[probutus]

@the mods:

can someone update the wiki page with links to the latest live-cd.iso and the dvd-base-v2.mo file? I get loads of mails of people asking me for the links since the posts containing them are "sunken" in this huge thread (on page 8 or 9)...

[Da Mafia]

after analyzing loads of kernel logs I found out the following:

-If you boot the sata-testcd (which does NOT work for sil3112 and sil3114; for that you need the live-cd.iso) on the boot prompt with:

slax irqpoll

the spurious interrupt does still occur but it seems not to hamper device detection (we get millions of disconnect/connect messages due to the interrupt but the sequence seems to be intact..)

the drive should then be recognized as /dev/scd0 (but still in modea)

so if you issue

modeb /dev/scd0

the drive should get into modeb..

modeb is only available if you integrate the dvd base v2 mo package into the testcd

I can not test it myself since I do currently have no access to my 3120 (only to my 8163)

Just wondering if anybody has managed to get this to work yet as when I try it it just ssys the the special device doesnt exist.

[geebee]

yup same here

[probutus]

with my sil3112/3114 i can not test it but I saw that with the irqpoll option the inquiry command from the scsi-part is sent to the drive which should get it identified the 12 0 0 0 24 c0...

so I assumed detection worked... as already said, I can not test it due to my controller...

If you do a dmesg; you should see something like:

ata_scsi_dump_cdb: 12 0 0 0 24 C0 0 0 xx

this is the command which the scsi driver applies to identify the device; as you can see this is the patched one which works also for mode_a... (see the very beginning of this post);

please ensure that there is no message like Warning: ATAPI disabled in your log! If you see this message it won't work...

[Pandor]

hey guys and girls.

i'm done stresstesting me 360 so i thought i would join in on the fun.

so my setup:
dfi mobo with sil3114 host controller (sil bios v. 5.0.6.4) in sata mode (not sata raid)
gentoo linux with kernel 2.6.16.20 running sata_sil

Now for some questions:
If the drive is powered from the 360 and in modeB (wire trick), does it still need the inquiry command, or does it act like any other drive?

@ probutus:
Could you give me a  headsup on your paches? i as i'm already using linux i don't want to download another linux bootdisc.
So would you be willing to post your patches as diffs, or plain text and maybe give a litle comment on what it does?

[Pandor]

Some other thoughts.

Since sata_sil is part of the libata-framework and is therefore considered by the kernel to be a SCSI-driver, did you guys enable scsi CD-ROM support in the kernel (sr_mod) and could src/linux/drivers/scsi/sr_vendor.c be used to pass non-standard (vendor specific) commands to the drive.

[probutus]

Hi Pandor,

the siimage driver on the live cd is the "old" legacy-ide driver which uses ide-cd...
The problem with sata is that I am still looking for a way to prevent the spurious interrupts which are coming in when the drive is still in mode a; IRQPOLL only solves the problem partly...
When a spurious interrupt occurs the IRQ will be disabled which has the effect that all other devices on this irq stop working 
I already have seen a good place to put the faked inquiry command and put the drive via the modeb command to mode b (already in the sata test cd)...

[Pandor]

Hi Pandor,
...
The problem with sata is that I am still looking for a way to prevent the spurious interrupts which are coming in when the drive is still in mode a.
..

So in modeB this problem shouldn't exist?

i just connected my drive to my pc and the sil bios wouldn't detect it in mode a.

So i did the wire trick and booted with modeB. The drive got detected by the bios, but the OS would hang at bootup with the "irq16 nobody cared" message.
then i tried booting into modeB with irqpoll enabled and then the system would boot (stil showing the message) but still not detecting the drive.

looking at /proc/interrupts i find this:

Code:

16:      37510   IO-APIC-level  libata, bttv0, nvidia

So it's disabled, but my videocard and tv-card are using it?..

I knew it wouldn't be this easy, but i just started out, so i wanted to see for myself.

[probutus]

Hi pandor,

I dont know exactly wether crossing the wires would put the drive in mode_b because of the following:

when grounding the wire the drive should still be in mode_a  because you still need a special inquiry command to get it detected (the extra c0 byte). What I assume (Thanks to Tiros) is that on startup this pin is used as an input pin which tells the drive wether to open the tray or not (this is NOT the tray status pin; since this is an output pin). This pin is floating and gets the drive confused so that it trys to send loads of tray status information to the host (the result is the spurious interrupt).

setting the drive to mode_b via the sw command has the side effect that this input pin is configured as a output pin, the interrupts are gone AND you can use the standard scsi-inquiry command to recognize the drive

The BIOS recognizes the drive via ATAPI-Inquiry command (0xA1) not via scsi-inquiry and this recognition is independant of mode a or b (If you use a sata->pata adapter these spurious interrupts are ignored and the drive is recognized by the BIOS but not yet by windows; to get it recognized you have to put it additionally to mode_b; this is done inside the ide-cd driver on the live cd)

[Pandor]

Hi pandor,

I dont know exactly wether crossing the wires would put the drive in mode_b because of the following:

when grounding the wire the drive should still be in mode_a  because you still need a special inquiry command to get it detected (the extra c0 byte). What I assume (Thanks to Tiros) is that on startup this pin is used as an input pin which tells the drive wether to open the tray or not (this is NOT the tray status pin; since this is an output pin). This pin is floating and gets the drive confused so that it trys to send loads of tray status information to the host (the result is the spurious interrupt).

setting the drive to mode_b via the sw command has the side effect that this input pin is configured as a output pin, the interrupts are gone AND you can use the standard scsi-inquiry command to recognize the drive

...

That would explain it. thx.

[Pandor]

I've been doing some more reading an got some more Q's :p

Hi pandor,

I dont know exactly wether crossing the wires would put the drive in mode_b because of the following:

when grounding the wire the drive should still be in mode_a  because you still need a special inquiry command to get it detected (the extra c0 byte).

If it still needs the inquiry, then why does windows detect it with a hardware induced modeB?
i've seen a lot of success stories with the wire trick and windows.

What I assume (Thanks to Tiros) is that on startup this pin is used as an input pin which tells the drive wether to open the tray or not (this is NOT the tray status pin; since this is an output pin). This pin is floating and gets the drive confused so that it trys to send loads of tray status information to the host (the result is the spurious interrupt).
...

I found this post by SeventhSon wich could be helpfull.

One more thing, one time the drive tray ejected when i crossed the wires, but all the other times the drive tray is closed, and the powerlight is blinking like crazy, is this right?

Yeah.

tray_status behaves completely differently in modeB

9a = input : tray_status (0V = opening/closing, +3.3V open/closed)
9b = input : tray_status (+3.3V = open, 0V = closed)

The 360 gets 'confused' about the state of the drive and that's why the dvd tray and front panel LEDs behave strangely.

If this annoys you, then cut tray_status and tie the 360 end to +3.3V (pin 7 in the above diagram) to solve this.

that way the pin (*tray_status) wouldn't be floating and the drive would/should act normally, would it not?

[probutus]

Hi Pandor,

the issue that there is no vendor specific byte needed anymore when grounding the wire is exactly the point which I do not understand (yet):

Question is: What is this bit which is set to 1 via mode_b; is this  the iopin configuration for the output line?
and what is the purpose of this register (because it seems to skip all vendor specific crap...)?

I red that it is possible to make the TS drive behave in the same way by grounding the wire... So there should be a possibility to have such a command also?

Sorry for not answering questions but raising new ones....

If we can get a clearer picture what is going on inside there it would help improving the live cd with sata drivers...

[moontan]

can anyone tell me how your meant to carry out modeb manually through slax?

I have usb2sata adapter and im trying this method:
1) attach adapter and do a lsusb and note the product and vendor id of the usb adapter
2) reboot the machine WITHOUT the usb adapter plugged in
3) login as root and do a "modprobe usb-storage fix_inq_vendor_id=0xYOUR_VENDOR_ID_IN_HEX_HERE fix_inq_product_id=0xYOUR_PRODUCT_ID_IN_HEX_HERE
4) plug in the usb adapter and the drive
5) if you like you can now execute modeB (from kev.nu) restart the system and use the drive in your standard linux or even window$

but i get an error (i'll try and paste it later, its about the usb-storage file) after doing step 3, but if i do step 4 then 3 i dont get an error ( is it still possible to do this correctly by plugging in usb adapter before doing the modprobe? )

Anyways, after that what are you meant to do, to actually get drive into modeb?

Thanks

[crsnwby]

I have a Asus A8N SLI Mobo and need to get my LG into modeB can this CD do it? My mobo has the 3114 chipset?

Thanks

Im going mad and need to flash the FW of my 360

[moontan]

the error from my post above when i try the modprobe usb-storage says:

error inserting usb-storage ( then location of usb-storage.ko file in brackets) : Unknown symbol in module, or unknown parameter (dmesg)

I have the same usb2sata vendor id's etc as you ( same cheap one off ebay ? )

[crsnwby]

I REPEAT!!!

I have a Asus A8N SLI Mobo and need to get my LG into modeB can this CD do it? My mobo has the 3114 chipset?

Thanks

Im going mad and need to flash the FW of my 360

[Arakon]

you repeat again to spam a thread and it'll be the last time you post something here.