Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: FreeBSD HP Ultrium 3000 supported? #225

Closed
roker opened this issue Nov 8, 2020 · 7 comments · Fixed by #239
Closed

Question: FreeBSD HP Ultrium 3000 supported? #225

roker opened this issue Nov 8, 2020 · 7 comments · Fixed by #239
Labels

Comments

@roker
Copy link

roker commented Nov 8, 2020

With a tad of pain (you are having duplicate symbols on v2.4-stable, Makefile uses libtape_cam_la-ibm_tape.o twice, first as .libs/libtape_cam_la-ibm_tape.o and second time as ./.libs/libtape_cam_la-ibm_tape.o) I have compiled latest sources which should have patch for non IBM tapes.

I have checked hp_tape.c and found this, which looked very promising:
struct supported_device *hp_supported_drives[] = { TAPEDRIVE( HP_VENDOR_ID, "Ultrium 5-SCSI", DRIVE_LTO5, "[Ultrium 5-SCSI]" ), /* HP Ultrium Gen 5 */

But running ltfs produces:

`18db0 LTFS31223I Opening a device through CAM driver (/dev/sa0)

18db0 LTFS31228I Product ID is 'Ultrium 5-SCSI'

18db0 LTFS31229I Vendor ID is HP

18db0 LTFS31230I Unsupported Drive 'Ultrium 5-SCSI Z64D'

18db0 LTFS12012E Cannot open device: failed backend open call.

18db0 LTFS10004E Cannot open device '/dev/sa0'.`

Is there something wrong with the way I build the code, hp ultrium not supported or something else? If this is a bug, I can help you with debugging...

@roker
Copy link
Author

roker commented Nov 8, 2020

Ok, now I understand. LTFS has support for other vendors and tapes but no one modified the freebsd part of LTFS code to actually use the support. Also any support code for hp devices is missing so even if vendor_compat is implemented there is no code to communicate with library. I have found sources of HP implementation but porting this would take too much time.

@piste-jp
Copy link
Member

Sorry, I don't have a time to make a response in a few days.

Yes, you are right. Actually drive support code is on OS dependent code, called tape driver. And now, only linux-sg and osx-iokit supports HP/Quantum drives.

HP guys kindly fixed my first trial code and confirmed behavior on their equipment for HP drives on Linux and Mac. And another contributer kindly confirmed the behavior on a Quantum HH drive on Linux. So I added it as supported.

Honestly I forget to take care about other OSs (may be the reason is they are not the code I'm not an originator...).

I can try to port the code to FreeBSD and NetBSD and I can confirm the compile. But I can't have any good physical environment for testing FreeBSD and NetBSD porting. It is very helpful if you can do that.

@kev009
Copy link
Contributor

kev009 commented Dec 2, 2020

@piste-jp-ibm can you fix the duplicate symbol issue in 2.4? I would like to package it for freebsd with or without the other drive support.

@piste2750
Copy link
Member

piste2750 commented Dec 4, 2020

@kev009 ,

I fixed and the fix was merged to master already.

I checked the build on FreeBSD 12.2-RELEASE

@kev009
Copy link
Contributor

kev009 commented Dec 4, 2020

@piste2750 thanks can you point me to the commit I will need to pull that into our ports system in the mean time.

@piste2750
Copy link
Member

@kev009 ,

Are you saying about the commit hash of this change? The change s merged to the master branch of this repository. The hash isbe1b873.

@piste-jp piste-jp added the bug label Jan 18, 2021
@piste-jp piste-jp reopened this Jan 18, 2021
@piste-jp
Copy link
Member

Sorry, this fix is not merged yet.

@piste-jp piste-jp linked a pull request Jan 18, 2021 that will close this issue
6 tasks
piste-jp pushed a commit that referenced this issue Jan 18, 2021
- Fix of issue #225
- Remove accidental committed files
piste-jp pushed a commit that referenced this issue Jan 19, 2021
- Fix of issue #225
- Remove accidental committed files
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants