Re: [PATCH] st: fix blk_get_queue usage

> On 1 Aug 2017, at 15.42, Hannes Reinecke wrote: > > From: Bodo Stroesser > > If blk_queue_get() in st_probe fails, disk->queue must not > be set to SDp->request_queue, as that would result in > put_disk() dropping a not taken reference. > > Thus,

Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

> On 4.2.2016, at 3.43, Seymour, Shane M wrote: > > Hi Kai, > > Tested with patched kernel 4.5.0-rc2-next-20160202+. It's looking good > everything partition related passed with DDS5 and LTO6. You can definitely > add me as a tested-by. I did find one issue below but

Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

> On 1.2.2016, at 8.31, Seymour, Shane M wrote: > > Hi Kai, > > Thanks for the changes the HPE DAT72 DDS5 drive now works as expected: > Good. Thanks for testing. ... > > I'm asking around again one final time to see if I can lay my hands on a LTO5 > or greater drive

Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

> On 28.1.2016, at 9.36, Seymour, Shane M wrote: > > Hi Kai, > > With the changes the I get a failure partitioning a HP DAT72 drive (DDS-5): > > # ./mt -f /dev/st1 stsetoption debug > # ./mt -f /dev/st1 stsetoption can-partitions > # ./mt -f /dev/st1 mkpartition 1000 >

Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

> On 27.1.2016, at 1.35, Seymour, Shane M wrote: > > Hi Emmanuel, > >> Hmm in fact if we keep using MB we'll be stuck when tapes reach ~2 PB >> which leaves some time to think about it, until LTO-15 circa 2036 :) > > There will be other issues to solve before then (by

Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

> On 28.1.2016, at 21.21, Laurence Oberman wrote: > > Hi Kai > > What kernel was the last patch you attached against. > It was against the latest git version from Jan 24 evening (Finnish time). It is 4.4.0 plus from 4.5 merge window. The patch applies to 3.18.25 with

What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

> On 15.1.2016, at 2.21, Seymour, Shane M wrote: > > Unfortunately I'm unable to lay my hands on an LTO 5 tape drive so I'm not > able to test that it works either. If it helps at all I can test in the > negative and make sure that for an LTO 3 drive it fails gracefully

Re: st driver doesn't seem to grok LTO partitioning

> On 30.12.2015, at 23.24, Emmanuel Florac <eflo...@intellique.com> wrote: > > Le Wed, 30 Dec 2015 21:21:47 +0200 > "Kai Mäkisara (Kolumbus)" <kai.makis...@kolumbus.fi> écrivait: > >> This happens if the position is not at the beginning of partition 0

Re: st driver doesn't seem to grok LTO partitioning

> On 29.12.2015, at 18.59, Emmanuel Florac wrote: > > Le Fri, 25 Dec 2015 17:53:46 +0200 (EET) > Kai Makisara écrivait: > >> the patch implements the following: if the >> size is 1, the driver tells the drive to use default partitioning for

Re: st driver doesn't seem to grok LTO partitioning

> On 29.12.2015, at 18.58, Emmanuel Florac wrote: > > Le Fri, 25 Dec 2015 17:53:46 +0200 (EET) > Kai Makisara écrivait: > >> The patch uses the scsi level of the device to separate processing. >> The FORMAT MEDIUM command is defined in SCSI-3

Re: st driver doesn't seem to grok LTO partitioning

> On 21.12.2015, at 19.57, Emmanuel Florac <eflo...@intellique.com> wrote: > > Le Mon, 21 Dec 2015 19:25:27 +0200 > "Kai Mäkisara (Kolumbus)" <kai.makis...@kolumbus.fi> écrivait: > >>> >>> I'm replying to myself: this is very obv

Re: st driver doesn't seem to grok LTO partitioning

> On 21.12.2015, at 14.46, Emmanuel Florac wrote: > > Le Fri, 18 Dec 2015 17:06:44 +0100 > Emmanuel Florac écrivait: > >> >> I'm trying to use mt to work with LTO-5 and bigger tapes. Switching >> partitions works: >> >> # tapeinfo -f /dev/sg1

Re: [PATCH V2] st: fix potential null pointer dereference.

> On 18.11.2015, at 16.32, Maurizio Lombardi wrote: > > If cdev_add() returns an error, the code calls > cdev_del() passing the STm->cdevs[rew] pointer as parameter; > the problem is that the pointer has not been initialized yet. > > This patch fixes the problem by moving

Re: [PATCH] [SCSI] st: Remove obsolete scsi_tape.max_pfn

> On 15.11.2015, at 13.48, Geert Uytterhoeven wrote: > > Its last user was removed 10 years ago, in commit > 8b05b773b6030de5 ("[SCSI] convert st to use scsi_execute_async"). > > Signed-off-by: Geert Uytterhoeven Acked-by: Kai Mäkisara

Re: [PATCH] st: trivial: remove form feed characters

> On 4.11.2015, at 11.52, Maurizio Lombardi wrote: > > Signed-off-by: Maurizio Lombardi > --- > drivers/scsi/st.c | 24 > 1 file changed, 8 insertions(+), 16 deletions(-) > > diff --git a/drivers/scsi/st.c b/drivers/scsi/st.c >

Re: [PATCH] st: allow debug output to be enabled or disabled via sysfs

> On 12.10.2015, at 7.31, Seymour, Shane M wrote: > > > Change st driver to allow enabling or disabling debug output > via sysfs file /sys/bus/scsi/drivers/st/debug_flag. > > Previously the only way to enable debug output was: > > 1. loading the driver with the module

Re: [PATCH] st: Destroy st_index_idr on module exit

On 8.7.2015, at 18.24, Johannes Thumshirn jthumsh...@suse.de wrote: Destroy st_index_idr on module exit, reclaiming the allocated memory. This was detected by the following semantic patch (written by Luis Rodriguez mcg...@suse.com) ... Signed-off-by: Johannes Thumshirn

Re: [PATCH] st: null pointer dereference panic caused by use after kref_put by st_open

On 2.7.2015, at 15.01, Seymour, Shane M shane.seym...@hp.com wrote: Two SLES11 SP3 servers encountered similar crashes simultaneously following some kind of SAN/tape target issue: ... The crash is fixed by reordering the code so we no longer access the struct scsi_tape after the

Re: [PATCH] st: convert to using driver attr groups for sysfs

On 23.6.2015, at 11.11, Seymour, Shane M shane.seym...@hp.com wrote: This patch changes the st driver to use attribute groups so driver sysfs files are created automatically. See the following for reference: http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/

Re: [PATCH] st: implement sysfs based tape statistics v2

On 9.2.2015, at 8.00, Seymour, Shane M shane.seym...@hp.com wrote: Kai - see last 3 paragraphs for question about if something is a bug or not. BTW I had a look - I couldn't quickly find out if there was a way to tell if the medium has changed in a tape drive (there could be something

Re: [RFC] implementing tape statistics single file vs multi-file in sysfs

On 8.2.2015, at 4.45, Greg KH gre...@linuxfoundation.org wrote: On Sat, Feb 07, 2015 at 09:27:05PM -0500, Laurence Oberman wrote: Hello Its not going to be tens of thousands of devices. That count was an aggregate based on 1000's of servers. In reality its unlikely to ever be more than

Re: [PATCH] st: implement sysfs based tape statistics v2

On 2.2.2015, at 17.16, Laurence Oberman oberma...@gmail.com wrote: I pulled this this morning and will be testing. The prior version was stable for me on the upstream and RHEL 6.5 kernel without exhaustive testing. We also just received more requests to get this into RHEL from HP / Red

Re: [PATCH] st: implement sysfs based tape statistics v2

On 5.2.2015, at 19.40, Laurence Oberman lober...@redhat.com wrote: - Original Message - From: Kai Mäkisara (Kolumbus) kai.makis...@kolumbus.fi To: Laurence Oberman oberma...@gmail.com Cc: Shane M Seymour shane.seym...@hp.com, lober...@redhat.com, linux-scsi@vger.kernel.org, James

Re: [PATCH 4/6] st: call scsi_set_medium_removal directly

On 7.11.2014, at 1.54, Elliott, Robert (Server Storage) elli...@hp.com wrote: ... 3. Reviewing the callers, st_release has an initialized result variable but does nothing else with it but return it: int result = 0; ... return result; It ignores the do_door_lock -

Re: [PATCH]: add debug flag parameter for SCSI tape driver - 2nd request

Hello, I am responding to this, but noticed your next, fixed version. On 17.10.2014, at 23.20, Laurence Oberman lober...@redhat.com wrote: Hello Kai You have seen this patch before. The first time around, given that we don't enable DEBUG by default, I let it go. However we have been

Re: [PATCH]: add debug flag parameter for SCSI tape driver - 2nd request

On 19.10.2014, at 16.44, Laurence Oberman lober...@redhat.com wrote: Hello Kai Thanks. Here is v3 This patch adds a debug_flag parameter that can be set on module load, and allows the DEBUG facility without a module recompile. Note that now DEBUG 1 is the default with this patch.

Re: [PATCH]: add debug flag parameter for SCSI tape driver

On 11.6.2014, at 2.48, Laurence Oberman lober...@redhat.com wrote: Hello Take 2 of this patch, changed module description and subject line. This patch adds a debug_flag parameter that can be set on module load, and allows the DEBUG facility without a module recompile. Usage: mpdprobe

Re: [PATCH] st: fix corruption of the st_modedef structures in st_set_options()

On 11.2.2014, at 23.22, Maurizio Lombardi mlomb...@redhat.com wrote: When copying the st_modedef structures the devs pointers must be preserved in the same way as with the cdevs pointers. This fixes bug 70271: https://bugzilla.kernel.org/show_bug.cgi?id=70271 [ 135.037052] BUG: unable

Re: [PATCH] st: Do not rewind for SG_IO

On 2.2.2014, at 13.42, Hannes Reinecke h...@suse.de wrote: [part of explanation snipped from reply] But we're now trying to deprecate the original (and unmaintained) scsi_id program and replace it with the standard 'sg_inq' program. Which is a standard program which just issues the

Re: [PATCH] st: Do not rewind for SG_IO

On 1.2.2014, at 16.06, Hannes Reinecke h...@suse.de wrote: On 01/31/2014 05:43 PM, Jeremy Linton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/31/2014 2:46 AM, Hannes Reinecke wrote: This patch make the tape always non-rewinding when SG_IO is used, thus allowing udev to get

Re: [PATCH] scsi: int overflow in st_ioctl()

On 17.12.2013, at 16.43, Yongjian Xu xuyongjia...@gmail.com wrote: From: Yongjian Xu xuyongjia...@gmail.com mtc.mt_count comes from user-space. int overflow may occur: mtc.mt_count++; mtc.mt_count—; I agree that this is a problem. However, it seems that there is also another problem: the

Re: [PATCH 1/3] st.ko: fix enlarge_buffer

On 2.12.2013, at 21.00, Bodo Stroesser bstroes...@ts.fujitsu.com wrote: From: Bodo Stroesser bstroes...@ts.fujitsu.com Date: Mon, 2 Dec 2013 18:52:10 +0100 Subject: [PATCH 1/3] st.ko: fix enlarge_buffer This patch removes a bug in enlarge_buffer() that can make a read or write fail under

Re: [PATCH 2/3] st.ko: remove unnecessary normalize_buffer

On 2.12.2013, at 21.00, Bodo Stroesser bstroes...@ts.fujitsu.com wrote: From: Bodo Stroesser bstroes...@ts.fujitsu.com Date: Mon, 2 Dec 2013 18:52:10 +0100 Subject: [PATCH 2/3] st.ko: remove unnecessary normalize_buffer This patch removes an unnecessary call to normalize_buffer() in

Re: [PATCH 3/3] st.ko: change enlarge_buffer result

On 2.12.2013, at 21.00, Bodo Stroesser bstroes...@ts.fujitsu.com wrote: From: Bodo Stroesser bstroes...@ts.fujitsu.com Date: Mon, 2 Dec 2013 18:52:10 +0100 Subject: [PATCH 3/3] st.ko: change enlarge_buffer result enlarge_buffer() just returns 1 or 0 if it could or could not allocate the

Re: PATCH: st.c: Fix blk_get_queue usage

On 14.11.2013, at 16.48, Bodo Stroesser bstroes...@ts.fujitsu.com wrote: Hi, in st_probe(), st.c I stumbled across what I'd call a minor problem. So I'd like to suggest the following patch. Best Regards, Bodo P.S.: Please CC me, I'm not on the list.