This does correct the sequence of switching to HS400 but it might be
safest to just add this to the latest until it gets a little testing
to make sure it doesn't expose some bug in existing controllers.
Thanks
Al
On Tue, Sep 3, 2019 at 10:52 AM Ulf Hansson wrote:
>
> On Tue, 3 Sep 2019 at
Is there any way to tell syzbot to run the reproducer but with only one
device instance (that is, only one dummy-hcd bus)?
Or can you a new, modified reproducer that will do this?
Alan Stern
On Wed, 18 Sep 2019, Abhishek Pandit-Subedi wrote:
> Sorry, last reply went out with HTML. Re-sending in plain text.
>
> On Wed, Sep 18, 2019 at 7:23 AM Alan Stern wrote:
> >
> > On Tue, 17 Sep 2019, Abhishek Pandit-Subedi wrote:
> >
> > > On a Realtek USB
On Wed, 18 Sep 2019, Matthias Maennich wrote:
> Follow common practice and retire printk(KERN_ERR ...) in favor of
> pr_fmt and dev_err().
>
> Cc: Alan Stern
> Cc: Greg Kroah-Hartman
> Cc: usb-stor...@lists.one-eyed-alien.net
> Signed-off-by: Matthias Maennich
> --
On Wed, 18 Sep 2019, Matthias Maennich wrote:
> Follow common practice and retire printk(KERN_ERR ...) in favor of
> pr_fmt and pr_err.
As long as you're changing this, why not change it to dev_err()
instead? That would be a lot more useful.
> Cc: Alan Stern
> Cc: Greg Kroah-H
vice's BT radio during suspend (if
wakeup is disabled) and then turn it back on during resume? Wouldn't
that accomplish what you want just as well?
Alan Stern
that with
no more than six (or however many threads syzbot used) callbacks per
jiffy, there would be plenty of time for normal threads to run.
Alan Stern
On Tue, 17 Sep 2019, syzbot wrote:
> Hello,
>
> syzbot tried to test the proposed patch but build/boot failed:
Oops. Typo.
#syz test: https://github.com/google/kasan.git f0df5c1b
drivers/media/usb/usbvision/usbvision-video.c | 27 ++
1 file changed, 23
an be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
The driver assumes that t
On Tue, 17 Sep 2019, Alan Stern wrote:
> On Tue, 17 Sep 2019, syzbot wrote:
>
> > Hello,
> >
> > syzbot has tested the proposed patch but the reproducer still triggered
> > crash:
> > WARNING in sysfs_remove_group
> >
> > [ cut here
2 layer handles
reference counting seems suspicious and I don't understand it. (Does
the code assume that the only reference holders are initial
registration and open files?)
In this case it looks like the device may be unregistered twice. It's
hard to tell exactly what's going wrong without knowing more about how
this is supposed to work. It wouldn't hurt, for example, to use
dev_info() instead of printk(KERN_INFO) in places like
usbvision_disconnect().
I'm going to step back and let the maintainers deal with the rest of
this.
Alan Stern
ady holding lock:
> 69c3004e (>v4l2_lock){+.+.}, at:
> __video_do_ioctl+0x3ba/0xba0 drivers/media/v4l2-core/v4l2-ioctl.c:2846
Heh. That's what comes of trying to patch a driver when you aren't an
expert on it already.
Okay, the lock is already held at this point so we don't need to
acqu
On Tue, 17 Sep 2019, Andrey Konovalov wrote:
> On Tue, Sep 17, 2019 at 4:51 PM Alan Stern wrote:
> >
> > On Tue, 17 Sep 2019, Dmitry Vyukov wrote:
> >
> > > On Mon, Sep 16, 2019 at 10:31 PM Alan Stern
> > > wrote:
> > > >
> > >
On Mon, 16 Sep 2019, syzbot wrote:
> Hello,
>
> syzbot has tested the proposed patch but the reproducer still triggered
> crash:
> general protection fault in vidioc_querycap
Same problem in a different part of the code.
Alan Stern
#syz test: https://github.com/google/kas
On Tue, 17 Sep 2019, Dmitry Vyukov wrote:
> On Mon, Sep 16, 2019 at 6:40 PM Alan Stern wrote:
> >
> > On Mon, 16 Sep 2019, syzbot wrote:
> >
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit:
On Tue, 17 Sep 2019, Dmitry Vyukov wrote:
> On Mon, Sep 16, 2019 at 10:31 PM Alan Stern wrote:
> >
> > On Mon, 16 Sep 2019, syzbot wrote:
> >
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > H
DR6: fffe0ff0 DR7: 0400
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
This is probably the same problem that was fixed in the Logitech driver
earlier. The fix still appears to be in linux-next (commit
5f9242775bb6).
Shouldn't syzbot wait until after the merge window before running tests
like this?
Alan Stern
urex_interrupt - unknown status received: -71
> yurex 5-1:0.101: yurex_interrupt - unknown status received: -71
> yurex 6-1:0.101: yurex_interrupt - unknown status received: -71
Let's see if preventing blind resubmissions fixes the problem.
Alan Stern
#syz test: https://github.com/google/k
On Mon, 16 Sep 2019, Greg Kroah-Hartman wrote:
> On Mon, Sep 16, 2019 at 12:32:52PM -0400, Alan Stern wrote:
> > Retry-limiting is not the sort of thing we want to add to each
> > individual USB class driver. Maybe it can be handled in the USB core;
> > I'll t
0 R15: 00
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
This is undoubted the same as the previous bug report. It should be
fixed by commit 9472aff16ca0 in Greg KH's usb-next branch, but the
fix is not yet in Linus's tree.
#syz dup: possible deadlock in open_rio
Alan Stern
On Mon, 16 Sep 2019, Andrey Konovalov wrote:
> On Fri, Sep 13, 2019 at 10:35 PM Alan Stern wrote:
> >
> > On Fri, 13 Sep 2019, syzbot wrote:
> >
> > > syzbot has found a reproducer for the following crash on:
> > >
> > > HEAD commit:f0
tar & int) part is okay. In
other words, if
Z ->(xbstar & int) Y
then it is certainly true that any store propagating to Z's CPU before
Z executes also propagates to Y's CPU (which is the same one) before Y
executes.
Alan
anation.txt. This could make the model simple (both for description
> and explanation), and one better thing is that we won't need commit in
> Paul's dev branch:
>
> c683f2c807d2 "tools/memory-model: Fix data race detection for unordered
> store and load"
>
> , and data race rules will look more symmetrical ;-)
>
> Thoughts? Or am I missing something subtle here?
See above.
Alan
r. The kernel
config you are using has CONFIG_HZ=100, but dummy-hcd needs
CONFIG_HZ=1000 (see the comment on line 1789). That is, lower values
of HZ will occasionally lead to trouble, and this may be an example.
Can you change the config value for HZ and see if the bug still
reproduces?
Alan Stern
On Thu, 12 Sep 2019, Paul E. McKenney wrote:
> On Fri, Sep 06, 2019 at 02:11:29PM -0400, Alan Stern wrote:
> > To this end, the LKMM imposes three extra restrictions, together
> > called the "plain-coherence" axiom because of their resemblance to the
> > coherency
On Fri, Sep 13, 2019 at 5:11 AM Kishon Vijay Abraham I wrote:
>
> + Haotian Wang
>
> On 03/06/19 11:12 PM, Alan Mikhak wrote:
> > On Sun, Jun 2, 2019 at 9:43 PM Kishon Vijay Abraham I wrote:
> >> Hi Alan,
> >> On 31/05/19 11:46 PM, Alan Mikhak wrote:
> >
ailing list about this issue,
but I haven't tried to keep track of them.
Also, just warning about a non-page-aligned allocation doesn't really
help. It would be better to fix the misbehaving allocator.
Alan Stern
On Thu, 12 Sep 2019, Paul E. McKenney wrote:
> On Fri, Sep 06, 2019 at 02:11:29PM -0400, Alan Stern wrote:
> > Folks:
> >
> > I have spent some time writing up a section for
> > tools/memory-model/Documentation/explanation.txt on plain accesses and
> > data rac
On Thu, 12 Sep 2019, Joe Perches wrote:
> On Thu, 2019-09-12 at 16:55 -0400, Alan Stern wrote:
> > checkpatch.pl shouldn't warn about a "Missing Signed-off-by: line by
> > nominal patch author" if there is no nominal patch author. Without
> > this change, checkpatc
checkpatch.pl shouldn't warn about a "Missing Signed-off-by: line by
nominal patch author" if there is no nominal patch author. Without
this change, checkpatch always gives me the following warning:
WARNING: Missing Signed-off-by: line by nominal patch author ''
Signed-of
USB: host: ohci-at91: suspend: delay needed before to stop clocks
>
> drivers/usb/host/ohci-at91.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
For all three patches:
Acked-by: Alan Stern
n use so that it can
> make a decision on what to do with the pages now that it knows they
> are unused.
>
> All this is providing is just a report and it is optional if the
> hypervisor will act on it or not. If the hypervisor takes some sort of
> action on the page, then the expectation is that the hypervisor will
> use some sort of mechanism such as a page fault to discover when the
> page is used again.
OK, that's interestingly different (but OK) from some other schemes that
hav ebeen described which *require* the guest to somehow indicate the
page is in use before starting to use the page again.
Dave
> -
> To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
_can_ do this currently, by writing the name of the interface to
/sys/bus/usb/drivers/usb-storage/bind. But as you know, this doesn't
work unless the VID & PID already match one of the driver's entries.
Alan Stern
py-atomic systems, as the WWC pattern demonstrates.
This patch changes the LKMM to accept either a wr-vis or a reverse
rw-xbstar link as a proof of non-concurrency.
Signed-off-by: Alan Stern
---
tools/memory-model/linux-kernel.cat |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index:
topic so to
some extent this is unavoidable.
In any case, I'd like to hear your comments and reviews.
Alan
PLAIN ACCESSES AND DATA RACES
-
In the LKMM, memory accesses such as READ_ONCE(x
ummy_hcd *dum_hcd)
> dum_hcd->rh_state = DUMMY_RH_RUNNING;
> dum_hcd->stream_en_ep = 0;
> INIT_LIST_HEAD(_hcd->urbp_list);
> - dummy_hcd_to_hcd(dum_hcd)->power_budget = POWER_BUDGET;
> + dummy_hcd_to_hcd(dum_hcd)->power_budget = POWER_BUDGET_3;
> dummy_hcd_to_hcd(dum_hcd)->state = HC_STATE_RUNNING;
> dummy_hcd_to_hcd(dum_hcd)->uses_new_polling = 1;
> #ifdef CONFIG_USB_OTG
Acked-by: Alan Stern
to the actual length of the descriptors
that were read in and validated. Then the memcpy() call, or any other
code using these descriptors, will be able to rely on wTotalLength
being valid.
Reported-and-tested-by: syzbot+35f4d916c623118d5...@syzkaller.appspotmail.com
Signed-off-by: Alan Stern
CC
h adds the missing check and aborts the probe operation if
necessary.
Reported-and-tested-by: syzbot+1088533649dafa1c9...@syzkaller.appspotmail.com
Signed-off-by: Alan Stern
CC:
---
[as1911]
drivers/hid/hid-prodikeys.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
Inde
On Wed, 4 Sep 2019, Andrey Konovalov wrote:
> On Wed, Sep 4, 2019 at 4:41 PM Alan Stern wrote:
> >
> > On Tue, 3 Sep 2019, syzbot wrote:
> >
> > > Hello,
> > >
> > > syzbot has tested the proposed patch but the reproducer still triggered
&
ask kworker/1:0/17
Very sneaky! A BOS descriptor whose wTotalLength field varies
depending on how many bytes you read.
This should fix it. It's the same approach we use for the Config
descriptor.
Alan Stern
#syz test: https://github.com/google/kasan.git eea39f24
drivers/usb/core/config.c
SERVED = 16 << 16,
Dave
> };
>
> enum fuse_notify_code {
> --
> MST
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
MMY_RH_RUNNING;
> > dum_hcd->stream_en_ep = 0;
> > INIT_LIST_HEAD(_hcd->urbp_list);
> > - dummy_hcd_to_hcd(dum_hcd)->power_budget = POWER_BUDGET;
> > + dummy_hcd_to_hcd(dum_hcd)->power_budget = POWER_BUDGET_3_0;
> > dummy_hcd_to_hcd(
On Tue, Sep 03, 2019 at 11:48:52AM -0700, Palmer Dabbelt wrote:
> On Tue, 27 Aug 2019 23:11:46 PDT (-0700), Christoph Hellwig wrote:
> >On Tue, Aug 27, 2019 at 04:37:16PM -0700, Palmer Dabbelt wrote:
> >>clint0 would be version 0 of the clint, with is the core-local interrupt
> >>controller in
s is right, this is pretty malicious...
Alan Stern
#syz test: https://github.com/google/kasan.git eea39f24
drivers/usb/core/config.c |2 ++
drivers/usb/core/hub.c|7 +++
2 files changed, 9 insertions(+)
Index: usb-devel/drivers/usb/core/hub.c
===
00b6d58371 Len 0xa8
> ==
> BUG: KASAN: slab-out-of-bounds in memcmp+0xa6/0xb0 lib/string.c:904
> Read of size 1 at addr 8881cd95d876 by task kworker/0:4/2841
Argh -- I forgot about printk's kernel-address mangling. Let's t
836
The reason for this bug seems pretty clear: pcmidi_get_output_report()
can return an error, but pcmidi_set_operational() doesn't bother to
check the return code.
Alan Stern
#syz test: https://github.com/google/kasan.git eea39f24
Index: usb-devel/drivers/hid/hid-prodikeys.c
==
On Tue, 3 Sep 2019, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:eea39f24 usb-fuzzer: main usb gadget fuzzer driver
> git tree: https://github.com/google/kasan.git usb-fuzzer
> console output: https://syzkaller.appspot.com/x/log.txt?x=174761b660
On Tue, 3 Sep 2019, Alan Stern wrote:
> On Tue, 3 Sep 2019, David Howells wrote:
>
> > Guenter Roeck wrote:
> >
> > > > > This added call to usbdev_remove() results in a crash when running
> > > > > the qemu "tosa" emulation. Removi
id.
Now, this is what writing to the sysfs "bind" file does -- except that
it won't let you bind a driver to a device it doesn't match!
So we have two problems:
Bind a driver to a particular device,
Even though the id's for the device don't match the driver.
The kernel already contains solutions for each of these problems, but
nothing that can handle both at once.
Alan Stern
ceSubClass=ff"), while still being
> backwards-compatible to the old format if you only give it numbers?
> What do you think?
I prefer the manual/automatic approach. It allows the user to control
exactly which device will be probed, which could be important.
Alan Stern
perates on whole devices... is there any way to force
> it to only bind one particular interface?
No. But with the NO_AUTO flag in your match flags, this wouldn't
matter. Besides, the IDs you want to add aren't really dynamic -- they
are fixed and known in advance.
Try something like the pat
re
> you really grab the device you meant to grab). Some of that
> information (the 'route' field) isn't even directly available from
> userspace (I could use the device name string instead and that would
> roughly come out to the same thing, but seems less clean to me).
The full, reliable routing information (not just the data in
udev->route) is indeed available to userspace. See the definition of
the USBDEVFS_CONNINFO_EX usbfs ioctl.
> So I could either do the mode switch in userspace and add a big custom
> sysfs interface to the usb-storage driver to allow userspace to
> configure all this, or I can add a small kernel shim driver like in
> this patch. Considering how little code the shim driver actually needs
> I expect it would come out to roughly the same amount of kernel code
> in both cases, and I feel like this version is much simpler to follow
> and fits cleaner in the existing "unusual device" driver
> infrastructure.
IMO the userspace approach would be better, unless you can provide a
really compelling argument for why it won't suffice.
Alan Stern
Why don't these patch-test reports include the dashboard link? It sure
would be handy to have a copy of it here.
Alan Stern
ed because CLINT is compatible to but
not mandatory in the privileged spec. In other words, it is possible that
a Linux-capable RISC-V platform does not contain a CLINT component but
rely on some other mechanism to deal with SW/timer interrupts.
>
> I can rebase my patch on top of yours and I can send it together or you
> can include in your series.
>
> Let me know your preference.
>
> --
> Regards,
> Atish
Best,
Alan
On Tue, 20 Aug 2019, Oliver Neukum wrote:
> Am Dienstag, den 20.08.2019, 10:18 -0400 schrieb Alan Stern:
> > On Mon, 19 Aug 2019, Oliver Neukum wrote:
> >
> > > Am Montag, den 19.08.2019, 07:48 -0700 schrieb syzbot:
> > > > Hello,
> > >
But if you're just doing a
single access in each place, not multiple accesses, then there's
nothing to optimize anyway. So there's no real reason not to use
READ_ONCE or WRITE_ONCE.
Alan Stern
Hi Christoph,
On Tue, Aug 13, 2019 at 05:47:45PM +0200, Christoph Hellwig wrote:
> When we get booted we want a clear slate without any leaks from previous
> supervisors or the firmware. Flush the instruction cache and then clear
> all registers to known good values. This is really important
Please ignore the previous mail, I must have missed this part of the patch,
>
> > + csrrt0, CSR_MISA
> > + andit0, t0, (COMPAT_HWCAP_ISA_F | COMPAT_HWCAP_ISA_D)
> > + bnezt0, .Lreset_regs_done
> > +
In S-mode we were not able to obtain the ISA information in misa, but now
the
andle, attrs);
> else if (ops->free)
> ops->free(dev, size, cpu_addr, dma_handle, attrs);
> }
> EXPORT_SYMBOL(dma_free_attrs);
>
> maybe you're gonna have to fire up a workqueue to free this memory for
> you :-(
>
> Unless someone else has b
No problem.
Thanks
Al
On Tue, Jul 30, 2019 at 4:00 AM Adrian Hunter wrote:
>
> On 26/07/19 12:37 AM, Alan Cooper wrote:
> > That's an even better solution and it gets my HS400 mode working.
> > Will you add this change or should I?
>
> You, if you wouldn't mind.
4f680)
> > The buggy address belongs to the page:
> > page:ea00073f1200 refcount:1 mapcount:0 mapping:8881dac02800
> > index:0x0 compound_mapcount: 0
> > flags: 0x2010200(slab|head)
> > raw: 02010200 dead00000100 dead0200 8881dac02800
> > raw: 0
gt;
> Link: https://lore.kernel.org/lkml/20190729121745.ga140...@google.com
>
> Suggested-by: Alan Stern
> Signed-off-by: Joel Fernandes (Google)
> ---
> tools/memory-model/Documentation/explanation.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
>
On Mon, 29 Jul 2019, Michael Kerrisk (man-pages) wrote:
> Hello Alan,
>
> On 7/21/19 5:32 PM, Alan Stern wrote:
> > Here are two extracts from the man page for ppoll(2) (from the
> > man-pages 4.16 package; the 5.01 version is the same):
> >
> >Speci
lies that
> +that stores to x and y propagate to P2 before the smp_store_release(), which
> +means that P2's smp_store_release() will propagate stores to x and y to all
> +CPUs before the store to z propagates (A-cumulative property of this fence).
> +Finally P0's load of z executes after P2's store to z has propagated to
> +P0 (rfe link).
Again, a better change would be simply to replace the two instances of
"fence" in the original text with "cumul-fence".
Alan
That's an even better solution and it gets my HS400 mode working.
Will you add this change or should I?
Thanks
Al
On Thu, Jul 25, 2019 at 3:33 AM Adrian Hunter wrote:
>
> On 23/07/19 3:34 PM, Alan Cooper wrote:
> > On Tue, Jul 23, 2019 at 1:21 AM Adrian Hunter
> > wrote:
>
On Tue, Jul 23, 2019 at 1:21 AM Adrian Hunter wrote:
>
> On 23/07/19 1:31 AM, Alan Cooper wrote:
> > I'm having a problem with a new SD/MMC controller and PHY in our
> > latest SoC's. The issue I'm seeing is that I can't switch into HS400
> > mode. This looks like somet
I'm having a problem with a new SD/MMC controller and PHY in our
latest SoC's. The issue I'm seeing is that I can't switch into HS400
mode. This looks like something the driver is doing that doesn't meet
the JEDEC spec. In the "HS400 timing mode selection" section of the
JEDEC spec , in step 7 it
platform:
> - while we do have PCI, the virtio devices are usually plugged via the ccw
> bus.
> That implies no PCI bars. I assume you use those PCI bars only to
> implicitely
> have the location of the shared memory
> Correct?
Right.
> - no real memory mapped I/O. Instead there are instructions that work on the
> mmio.
> As I understand things, this is of no concern regarding virtio-fs as you do
> not
> need mmio in the sense that a memory access of the guest to such an address
> triggers an exit. You just need the shared memory as a mean to have the data
> inside the guest. Any notification is done via normal virtqueue mechanisms
> Correct?
Yep.
>
> Adding Heiko, maybe he remembers some details of the dcssblk/xip history.
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
t negative time values in tmo_p are not interpreted
as an infinite timeout.
Also, in the ERRORS section, change the text for EINVAL to:
EINVAL The nfds value exceeds the RLIMIT_NOFILE value or
*tmo_p contains an invalid (negative) time value.
Alan Stern
k_write_reg+0x1ef/0x2b0 drivers/media/radio/radio-shark2.c:88
> >
> > Based on
> > drivers/media/radio/radio-shark2.c:88 and
> > drivers/usb/core/message.c:245
> >
> > I say that the warning reported is bogus.
You have misunderstood the problem.
drivers/usb/core/message.c:245 allows drivers to call usb_bulk_msg()
when the target is actually an interrupt endpoint. The bug in this
case is that drivers/media/radio/radio-shark2.c:88 calls
usb_interrupt_msg() with an INTERRUPT pipe type when the target is
actually a bulk endpoint.
These are two different things. It can make sense to use an interrupt
endpoint, especially if a bulk endpoint is not available. But the
reverse does not make sense, because bulk endpoints do not provide the
bandwidth guarantees that interrupt endpoints do.
Alan Stern
are going to convert shifts to multiply and divide then used
unsigned maths so the compiler can optimize it nicely on some of the low
end processors.
Alan
; /* set the new configuration */
> ioctl(fd, GSMIOC_SETCONF, );
> + /* get and print base gsmtty device node */
> + ioctl(fd, GSMIOC_GETBASE, );
Can we at least use a specific sized type ? uint32_t or whatever is fine.
Alan
From: Alan Mikhak
nvme_dev_add() assumes a read queue is always allocated.
That may not be the case on single-interrupt systems for
which pci_assign_irq() would report runtime IRQ mapping
not provided by arch.
This patch makes sure nvme_dev_add() only requests an
IRQ mapping for read queues
From: Alan Mikhak
Modify nvme_alloc_sq_cmds() to call pci_free_p2pmem()
to free the memory it allocated using pci_alloc_p2pmem()
in case pci_p2pmem_virt_to_bus() returns null.
Makes sure not to call pci_free_p2pmem() if pci_alloc_p2pmem()
returned null which can happen if CONFIG_PCI_P2PDMA
md_find_chipset_info to usb_amd_quirk_pll_check (along with the
other code adjustments) and be done with it.
However, in the end I don't care if you still want to do this. Either
way:
Acked-by: Alan Stern
Alan Stern
md_chipset.probe_result;
> + need_pll_quirk = amd_chipset.probe_result;
>
> spin_unlock_irqrestore(_lock, flags);
>
> @@ -277,7 +284,7 @@ int usb_amd_find_chipset_info(void)
> spin_unlock_irqrestore(_lock, flags);
> }
>
> - return ret;
> + return need_pll_quirk;
> }
> EXPORT_SYMBOL_GPL(usb_amd_find_chipset_info);
Acked-by: Alan Stern
On 05/07/2019 12:38, Peter Zijlstra wrote:
On Fri, Jul 05, 2019 at 12:25:46PM +0100, Alan Jenkins wrote:
Hi, scheduler experts!
My cpu "iowait" time appears to be reported incorrectly. Do you know why
this could happen?
Because iowait is a magic random number that has no sa
wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 7854.0 total,432.2 free, 4616.4 used, 2805.4 buff/cache
MiB Swap: 2048.0 total, 1978.2 free, 69.8 used. 2498.0 avail Mem
PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND
31849 alan-sy+ 20 0 216052 2836
On Fri, 5 Jul 2019, Suwan Kim wrote:
> On Mon, Jun 24, 2019 at 01:24:15PM -0400, Alan Stern wrote:
> > On Mon, 24 Jun 2019, Suwan Kim wrote:
> >
> > > > > + hcd->self.sg_tablesize = ~0;
> > > > > + hcd->self.no_sg_constraint = 1;
>
On 03/07/2019 15:06, Doug Smythies wrote:
On 2019.07.01 08:34 Alan Jenkins wrote:
Hi
Hi,
I tried running a simple test:
dd if=testfile iflag=direct bs=1M of=/dev/null
With my default settings, `vmstat 10` shows something like 85% idle time
to 15% iowait time. I have 4 CPUs, so
/proc/stat will decrease in certain
conditions|
Thanks for all the power-saving code
Alan
On Mon, 1 Jul 2019, Oliver Neukum wrote:
> Am Mittwoch, den 26.06.2019, 10:38 -0400 schrieb Alan Stern:
> > On Wed, 26 Jun 2019, Oliver Neukum wrote:
> >
> > > Am Montag, den 24.06.2019, 10:22 -0400 schrieb Alan Stern:
> > > > But that pattern make
the informal documentation to at least acknowledge such addition.
>
> Signed-off-by: Andrea Parri
> Cc: Alan Stern
> Cc: Will Deacon
> Cc: Peter Zijlstra
> Cc: Boqun Feng
> Cc: Nicholas Piggin
> Cc: David Howells
> Cc: Jade Alglave
> Cc: Luc Maranget
> Cc: "Pau
On Wed, 26 Jun 2019, Oliver Neukum wrote:
> Am Montag, den 24.06.2019, 10:22 -0400 schrieb Alan Stern:
> > But that pattern makes no sense; a driver would never use it. The
> > driver would just do the reset itself.
>
> Correct. But UAS and storage themselves still need to
On Tue, Jun 25, 2019 at 10:10 AM Heitke, Kenneth
wrote:
>
>
>
> On 6/24/2019 5:57 PM, Alan Mikhak wrote:
> > Modify nvme_alloc_sq_cmds() to call pci_free_p2pmem()
> > to free the memory it allocated using pci_alloc_p2pmem()
> > in case pci_p2pmem_virt_to_bus() r
On Tue, Jun 25, 2019 at 12:09 AM Christoph Hellwig wrote:
>
> On Mon, Jun 24, 2019 at 04:57:22PM -0700, Alan Mikhak wrote:
> > Modify nvme_alloc_sq_cmds() to call pci_free_p2pmem()
> > to free the memory it allocated using pci_alloc_p2pmem()
> > in case pci_p2pmem_vi
.
Signed-off-by: Alan Mikhak
---
drivers/nvme/host/pci.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 524d6bd6d095..5dfa067f6506 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -1456,11
esize value.
I didn't have any good reason for picking 16. Using the smallest value
of all the HCDs seems like a good idea.
Alan Stern
On Mon, 24 Jun 2019, Paul E. McKenney wrote:
> On Sun, Jun 23, 2019 at 09:34:55PM -0700, Paul E. McKenney wrote:
> > On Sun, Jun 23, 2019 at 11:15:06AM -0400, Alan Stern wrote:
> > > On Sun, 23 Jun 2019, Akira Yokosawa wrote:
> > >
> > > > Hi Paul and Al
On Mon, 24 Jun 2019, Oliver Neukum wrote:
> Am Donnerstag, den 20.06.2019, 07:10 -0700 schrieb Tejun Heo:
> > Hello,
> >
> > On Tue, Jun 18, 2019 at 11:59:39AM -0400, Alan Stern wrote:
> > > > > Even if you disagree, perhaps we should have a global workqueue w
On Sun, 23 Jun 2019, Akira Yokosawa wrote:
> Hi Paul and Alan,
>
> On 2019/06/22 8:54, Paul E. McKenney wrote:
> > On Fri, Jun 21, 2019 at 10:25:23AM -0400, Alan Stern wrote:
> >> On Fri, 21 Jun 2019, Andrea Parri wrote:
> >>
> >>> On Thu, Jun 2
, the stub driver allocates
> big buffer using kmalloc() instead of using sgl_alloc() which
> allocates SG list and pages.
You might be better off not using kmalloc. It's easier for the kernel
to allocate a bunch of small buffers than a single big one. Then you
can create a separate URB
eric PCI names to make them
> compatible with defines in pci_regs.h.
>
> All unused defines are removed from skfbi.h.
I sincerely doubt anyone on the planet is using this card any more.
Alan
abka
Signed-off-by: Vlastimil Babka
Signed-off-by: Alan Jenkins
Fixes: 1c30844d2dfe ("mm: reclaim small amounts of memory when an external
fragmentation event occurs")
Acked-by: Mel Gorman
---
Changes since v1:
Use Vlastimil's suggested code. It is much cleane
On Fri, 21 Jun 2019, Andrea Parri wrote:
> On Thu, Jun 20, 2019 at 11:55:58AM -0400, Alan Stern wrote:
> > Herbert Xu recently reported a problem concerning RCU and compiler
> > barriers. In the course of discussing the problem, he put forth a
> > litmus test which illustr
> > Remove "brcm,bdc-v0.16" because it was never used on any system.
>
> You're not really removing it, are you?
Whoops, it was supposed to be removed.
Thanks
Al
On Fri, Jun 21, 2019 at 4:28 AM Sergei Shtylyov
wrote:
>
> Hello!
>
> On 21.06.2019 0:09, Al Cooper wrote:
>
> > Remove
> > diff --git a/drivers/usb/gadget/udc/bdc/bdc_core.c
> > b/drivers/usb/gadget/udc/bdc/bdc_core.c
> > index ccbd1d34eb2a..11a43de6c1c6 100644
> > --- a/drivers/usb/gadget/udc/bdc/bdc_core.c
> > +++ b/drivers/usb/gadget/udc/bdc/bdc_core.c
> > @@ -490,8 +490,14 @@ static int bdc_probe(struct
It's been very useful to have the DEFER debug message so I'd like to
leave in the check for DEFER. I should not be skipping the clock
disable, so I'll "goto clk_cleanup" for both cases.
Thanks
Al
On Fri, Jun 21, 2019 at 1:39 AM Chunfeng Yun wrote:
>
> On Thu, 2019-06-20 at 17:09 -0400, Al
Normal
pages free 74597
min 9582
low 34505
high 36900
https://unix.stackexchange.com/questions/525674/my-low-and-high-watermarks-seem-higher-than-predicted-by-documentation-sysctl-vm/525687
Signed-off-by: Alan Jenkins
Fixes: 1c30844d2dfe ("mm: reclaim sm
601 - 700 of 20878 matches
Mail list logo
