From: Alastair D'Silva
> Sent: 08 May 2019 08:02
> To: alast...@d-silva.org
...
> --- a/include/linux/printk.h
> +++ b/include/linux/printk.h
> @@ -480,13 +480,13 @@ enum {
> DUMP_PREFIX_OFFSET
> };
>
> -extern int hex_dump_to_buffer(const void *buf, size_t len, int rowsize,
> -
From: Alastair D'Silva
> Sent: 15 April 2019 11:45
...
> > Although I think you'd want a 'no hex' flag to suppress the hex.
> >
> > Probably more useful flags are ones to suppress the address column.
>
> This is already supported by the prefix_type parameter - are you proposing
> that we eliminat
From: Alastair D'Silva
> Sent: 15 April 2019 11:29
...
> I do, and I believe the choice of the output length should be in the hands
> of the caller.
>
> On further thought, it would make more sense to remove the hardcoded list of
> sizes and just enforce a power of 2. The function shouldn't dictat
From: Alastair D'Silva
> Sent: 15 April 2019 11:07
...
> In the above example the author only wants the hex output, while in other
> situations, both hex & ASCII output is desirable. If you just want ASCII
> output, the caller should just use a printk or one of it's wrappers.
Hexdump will 'sanitis
From: Alastair D'Silva
> Sent: 10 April 2019 04:17
> With the wider display format, it can become hard to identify how many
> bytes into the line you are looking at.
>
> The patch adds new flags to hex_dump_to_buffer() and print_hex_dump() to
> print vertical lines to separate every N groups of by
From: James Bottomley
> Sent: 13 November 2018 16:11
>
> On Tue, 2018-11-13 at 16:53 +0100, Johannes Thumshirn wrote:
> > On 13/11/2018 16:44, John Garry wrote:
> > > On 13/11/2018 15:08, Sabyasachi Gupta wrote:
> [...]
> > > > -fnic_trace_buf_p = (unsigned long)vmalloc((trace_max_pages *
> >
From: James Bottomley
> Sent: 25 October 2018 16:33
>
> On Thu, 2018-10-25 at 16:13 +0100, Colin King wrote:
> > From: Colin Ian King
> >
> > In the expression "ahc_inb(ahc, port+3) << 24", the initial value is
> > a u8, but is promoted to a signed int, then sign-extended to
> > uint64_t.
>
> Wh
> > - sizeof(wwn_t[iocmd->nports])) != BFA_STATUS_OK) {
> > + sizeof(wwn_t) * iocmd->nports) != BFA_STATUS_OK) {
>
> These parentheses made me blurry eyed but it's actually OK.
iocmd->nports * sizeof(wwn_t)) != BFA_STATUS_OK) {
is easier to focus on :-)
From: Stephen Kitt
> Sent: 09 March 2018 22:34
>
> COMMAND_SIZE currently uses an array of values in block/scsi_ioctl.c.
> A number of device_handler functions use this to initialise arrays,
> and this is flagged by -Wvla.
>
> This patch replaces COMMAND_SIZE with a variant using a formula which
From: Andy Shevchenko
> Sent: 23 February 2018 17:13
> To: David Laight
> Cc: Arnd Bergmann; James Smart; Dick Kennedy; James E.J. Bottomley; Martin K.
> Petersen; Hannes
> Reinecke; Johannes Thumshirn; linux-scsi@vger.kernel.org;
> linux-ker...@vger.kernel.org
> Subject: R
From: Andy Shevchenko
> Sent: 23 February 2018 16:51
> On Fri, Feb 23, 2018 at 6:41 PM, David Laight wrote:
> > From: Arnd Bergmann
> >> Sent: 23 February 2018 15:37
> >>
> >> 32-bit architectures generally cannot use writeq(), so we now get a
From: Arnd Bergmann
> Sent: 23 February 2018 15:37
>
> 32-bit architectures generally cannot use writeq(), so we now get a build
> failure for the lpfc driver:
>
> drivers/scsi/lpfc/lpfc_sli.c: In function 'lpfc_sli4_wq_put':
> drivers/scsi/lpfc/lpfc_sli.c:145:4: error: implicit declaration of fu
From: Arnd Bergmann
> Sent: 14 July 2017 13:07
> gcc points out a theorerical string overflow:
>
> drivers/message/fusion/mptbase.c: In function 'mpt_detach':
> drivers/message/fusion/mptbase.c:2103:17: error: '%s' directive writing up to
> 31 bytes into a region
> of size 28 [-Werror=format-over
From: Christoph Hellwig
> Sent: 16 June 2017 08:17
>
> For many years we've had the dma_alloc_attrs API that is more flexible
> than dma_alloc_noncoherent. This series moves the remaining users over
> to the attrs API.
And most of the callers probably only want to specify 'noncoherent'.
Grepping
From: Logan Gunthorpe
> Sent: 13 April 2017 23:05
> Straightforward conversion to the new helper, except due to
> the lack of error path, we have to warn if unmapable memory
> is ever present in the sgl.
>
> Signed-off-by: Logan Gunthorpe
> ---
> drivers/block/xen-blkfront.c | 33 +++
From: James Bottomley
> Sent: 28 September 2015 16:12
> > > > The x86 cpus will also do 32bit wide rmw cycles for the 'bit'
> > > > operations.
> > >
> > > That's different: it's an atomic RMW operation. The problem with the
> > > alpha was that the operation wasn't atomic (meaning that it can't
From: James Bottomley [mailto:james.bottom...@hansenpartnership.com]
> Sent: 28 September 2015 15:27
> On Mon, 2015-09-28 at 08:58 +, David Laight wrote:
> > From: Rafael J. Wysocki
> > > Sent: 27 September 2015 15:09
> > ...
> > > > > Say you have thr
From: Rafael J. Wysocki
> Sent: 27 September 2015 15:09
...
> > > Say you have three adjacent fields in a structure, x, y, z, each one byte
> > > long.
> > > Initially, all of them are equal to 0.
> > >
> > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > >
> > > What's the resu
From: Brian King
> Sent: 18 September 2015 22:35
...
> > + for (i = 0; i < CXLFLASH_NUM_VLUNS; i++, buf += 22)
>
> Rather than this bug prone hard coded 22, how about never incrementing buf
> and do something
> similar to this:
>
> > + bytes += scnprintf(buf, PAGE_SIZE, "%03d: %016ll
From: Linuxppc-dev Matthew R. Ochs
> Sent: 16 September 2015 22:28
> Interrupt processing can run in parallel to a remove operation. This
> can lead to a condition where the interrupt handler is processing with
> memory that has been freed.
>
> To avoid processing an interrupt while memory may be
From: Of James Bottomley
> Sent: 22 June 2015 18:36
> To: Alan Stern
...
> > > Obviously, for a disk with a writeback cache that can't do flush, that
> > > window is much wider and the real solution should be to try to switch
> > > the cache to write through.
> >
> > I agree. Doing the switch manu
From: Norman Diamond
...
> By the way, I've seen some USB bridges that lie about whether they
> performed various SAT commands (ATA passthrough), but told the truth
> about performing an ATA IDENTIFY DEVICE through SAT. So we could attempt
> ATA passthrough with an IDENTIFY DEVICE command, and if
From: Boaz Harrosh
> On 11/06/2014 05:53 PM, Alan Stern wrote:
> >> But just the simple case of read-capacity failure should we then?
> >
> > That's a separate question. As far as I know, the case you are
> > describing has not come up.
> >
>
> BTW: what we should do is when the partition parser
From: Alan Stern
...
> > p = quirks;
> > while (*p) {
> > @@ -543,6 +544,9 @@ void usb_stor_adjust_quirks(struct usb_device *udev,
> > unsigned long *fflags)
> > case 's':
> > f |= US_FL_SINGLE_LUN;
> > break;
> > + case 't':
>
From Oliver Neukum [mailto:oneu...@suse.de]
> On Tue, 2014-08-26 at 09:58 +0000, David Laight wrote:
> > > Part of the problem is that usb-storage has no way to know that
> > > anything strange is going on. It's normal for READ CAPACITY(16) to
> > > fail (this
From: Alan Stern
> On Mon, 25 Aug 2014, Alfredo Dal Ava Junior wrote:
>
> > Well, it is causing problems anyway... from user perspective, it's a
> > Linux compatibility issue, as it works "fine" on Windows. I'm not an
> > expert, but I'm wondering that if usb-storage could set capacity as
> > "UND
From: loody
...
> but what it really do is read sector, not media_change or test_unit_ready.
Maybe one of the programs that reads the mbr partition table can
be persuaded to do a direct read?
David
From: Lars Melin
...
> sgread is not included in BusyBox but you should have "touch".
> Create a dummy file on the disk and let cron touch it every 4 minutes.
You don't need 'touch' a shell redirect eg ": >file" will do open(...,
O_CREAT|O_TRUNC).
However that still might not force an actual disc
From: Julia Lawall
> On Wed, 4 Jun 2014, Geert Uytterhoeven wrote:
>
> > Hi Julia,
> >
> > On Wed, Jun 4, 2014 at 1:00 PM, Julia Lawall wrote:
> > > OK, thanks. I was only looking at the C code.
> > >
> > > But the C code contains a loop that is followed by:
> > >
> > > if (!size)
> > >
From: Julia Lawall
> On Wed, 4 Jun 2014, Geert Uytterhoeven wrote:
>
> > Hi Julia,
> >
> > On Wed, Jun 4, 2014 at 11:07 AM, Julia Lawall wrote:
> > > Find_first_zero_bit considers BITS_PER_LONG bits at a time, and thus may
> > > return a larger number than the maximum position argument if that po
From: walt
> On 01/21/2014 01:51 AM, David Laight wrote:
> > From: Sarah Sharp
> >> On Mon, Jan 20, 2014 at 11:21:14AM +, David Laight wrote:
> > ...
> >>> A guess...
> >>>
> >>> In queue_bulk_sg_tx() try calling xhci_v1_0_td_remai
From: Sarah Sharp
> On Mon, Jan 20, 2014 at 11:21:14AM +0000, David Laight wrote:
...
> > A guess...
> >
> > In queue_bulk_sg_tx() try calling xhci_v1_0_td_remainder() instead
> > of xhci_td_remainder().
>
> Why? Walt has a 0.96 xHCI host controller, and the for
From: walt
> On 01/17/2014 06:34 AM, David Laight wrote:
>
> > Can you try the patch I posted that stops the ownership on LINK TRBs
> > being changed before that on the linked-to TRB?
>
> Please disregard my earlier post about the patch not applying cleanly.
> That wa
From:
> On 01/17/2014 06:34 AM, David Laight wrote:
>
> > Can you try the patch I posted that stops the ownership on LINK TRBs
> > being changed before that on the linked-to TRB?
>
> Sadly, the patch didn't fix the ASMedia lockup behavior, however :(
>
> I
From: walt
> Oy, Sarah! ;) I put the ASMedia adapter in my older amd64 machine, and, well,
> the stupid thing Just Works(TM) with kernel 3.12.7! (Yes, with the same disk
> docking station, too.)
>
> I can't believe the adapter works perfectly in a different computer. Have you
> seen this kind o
From: walt
> On 01/09/2014 03:50 PM, Sarah Sharp wrote:
>
> >>> On Tue, Jan 07, 2014 at 03:57:00PM -0800, walt wrote:
> >>
> >> I've wondered if my xhci problems might be caused by hardware quirks, and
> >> wondering why I seem to be the only one who has this problem.
> >>
> >> Maybe I could "take
From: walt
> > In the meantime, try this patch, which is something of a long shot.
>
> No difference. But I notice the code enables the TRB quirk only if the
> xhci_version is specifically 0x95. My debug messages claim that "xHCI
> doesn't need link TRB QUIRK" so I'm wondering if adding my asmed
> From: walt
...
> I'm still wondering if I'm suffering from hardware quirks. From the
> first day I installed my usb3 adapter card and the usb3 disk docking
> station I've noticed some quirky behavior.
Ah - this isn't an 'on chip' usb3 adapter.
Some kind of PCIe card ?
> e.g. I boot the machine
> From: Alan Stern
> On Wed, 8 Jan 2014, David Laight wrote:
>
> > > From: Alan Stern
> > >
> > > This may be a foolish question, but why is xhci-hcd using no-op TRBs in
> > > the first place?
> >
> > Because it can't write in a link T
> From: Alan Stern
>
> This may be a foolish question, but why is xhci-hcd using no-op TRBs in
> the first place?
Because it can't write in a link TRB because other parts of the
code use link TRBs to detect the end of the ring.
The problem is that it can't put a link TRB in the middle of
a chain
> From: Sarah Sharp
> On Tue, Jan 07, 2014 at 03:57:00PM -0800, walt wrote:
> > On 01/07/2014 01:21 PM, Sarah Sharp wrote:
> >
> > > Can you please try the attached patch, on top of the previous three
> > > patches, and send me dmesg?
> >
> > Hi Sarah, I just now finished running 0001-More-debuggin
The dmesg contains:
[ 538.728064] EXT4-fs warning (device dm-0): ext4_end_bio:316: I/O error
writing to inode 23330865 (offset 0 size 8388608 starting block 812628)
An 8MB transfer will need at least 128 ring entries (TRB) even if the request
is a single contiguous memory block.
Are you using
> From: walt
...
> Thanks Sarah. dmesg0 is from the diagnostic patch only. dmesg1 has all
> three patches applied. Some of the messages in dmesg1 fell off the end of
> the kernel buffer, so I may need to make the buffer larger next time but
> I'll need a reminder of how to do it.
>
> As you sus
> From: walt
...
> /* Accept arbitrarily long scatter-gather lists */
> - hcd->self.sg_tablesize = ~0;
> + hcd->self.sg_tablesize = 31;
Even if that reduces the number of fragments passed to the xhci driver
it may not be enough to limit the actual number of fragments that
need
> > It seems to me that a more useful interface would take a minimum and
> > maximum number of vectors from the driver. This wouldn't allow the
> > driver to specify that it could only accept, say, any even number within
> > a certain range, but you could still leave the current functions
> > avai
> This patch implements a low latency Write Combining (aka Write Coalescing)
> work
> request path. PCIE maps User Space Doorbell BAR2 region writes to the new
> interface to SGE. SGE pulls a new message from PCIE new interface and if its a
> coalesced write work request then pushes it for process
> >>> + writel(n, adap->bar2 + q->udb + 8);
> >>> +#if defined(CONFIG_X86_32) || defined(CONFIG_X86_64)
> >>> + asm volatile("sfence" : : : "memory");
> >>> +#endif
> >> There is absolutely no way I'm letting anyone put crap like this
> >> into a driver.
> >
47 matches
Mail list logo
