On Fri, Oct 26, 2018 at 3:02 AM Greg KH wrote:
>
> Here is the big USB/PHY driver patches for 4.20-rc1
Pulled,
Linus
On Tue, Apr 24, 2018 at 6:28 AM, Sedat Dilek wrote:
>
> $ objdump -S clang-eflag.o
>
> Does this now look good?
Looks fine to me. The instruction choice is still pretty odd:
1a: f6 c3 fftest $0xff,%bl
1d: 74 02 je 21
that "test $0xff,%bl" is a
On Tue, Jan 9, 2018 at 9:57 AM, Eric Dumazet wrote:
>
> Your patch considers TASKLET_SOFTIRQ being a candidate for 'immediate
> handling', but TCP Small queues heavily use TASKLET,
> so as far as I am concerned a revert would have the same effect.
Does it actually?
TCP ends up dropping packets o
On Tue, Jan 9, 2018 at 9:42 AM, Mauro Carvalho Chehab
wrote:
>
> On my preliminar tests, writing to a file on an ext4 partition at a
> USB stick loses data up to the point to make it useless (1/4 of the data
> is lost!). However, writing to a class 10 microSD card is doable.
Note that most USB st
On Tue, Jan 9, 2018 at 9:27 AM, Eric Dumazet wrote:
>
> So yes, commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job") has
> shown up multiple times in various 'regressions'
> simply because it could surface the problem more often.
> But even if you revert it, you can still make the faulty
> dr
On Mon, Jan 8, 2018 at 11:15 AM, Alan Stern wrote:
>
> Both dwc2_hsotg and ehci-hcd use the tasklets embedded in the
> giveback_urb_bh member of struct usb_hcd. See usb_hcd_giveback_urb()
> in drivers/usb/core/hcd.c; the calls are
>
> else if (high_prio_bh)
> tasklet_hi_sc
On Mon, Jan 8, 2018 at 9:55 AM, Ingo Molnar wrote:
>
> as I doubt we have enough time to root-case this properly.
Well, it's not like this is a new issue, and we don't have to get it
fixed for 4.15. It's been around since 4.9, it's not a "have to
suddenly fix it this week" issue.
I just think th
On Sat, Jan 6, 2018 at 11:54 AM, Mauro Carvalho Chehab
wrote:
>
> Em Sat, 6 Jan 2018 16:04:16 +0100
> "Josef Griebichler" escreveu:
>>
>> the causing commit has been identified.
>> After reverting commit
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4cd13c21b20
On Mon, Nov 13, 2017 at 8:19 AM, Greg KH wrote:
>
> Other major thing is the typec code that moved out of staging and into
> the "real" part of the drivers/usb/ tree, which was nice to see happen.
Hmm. So now it asks me about Type-C Port Controller Manager. Fair
enough. I say "N", because I have
On Mon, Oct 2, 2017 at 2:26 PM, Josh Poimboeuf wrote:
>
> The bisect is pointing to a commit which is almost 5 months old, so this
> is pre-ORC. Kallsyms *is* enabled, but the unwinder dump isn't smart
> enough to realize it's dumping misaligned stack addresses:
Ahh, I didn't pick up on that "es
Bringing in Josh on this, because the merge commit gets fingered
because it seems to be an interaction between the new code from the
merge and the ORC unwinder changes. It's probably some almost trivial
code difference that just causes some code generation to change.
And because Josh wasn't implic
On Thu, Jun 8, 2017 at 12:49 PM, Alan Stern wrote:
>
> So maybe CONFIG_HID_ASUS should default to Y? I'll leave it up to Hans
> to straighten this out.
No, I think the main problem is that the hid_have_special_driver[]
array change is garbage.
It adds the ASUS ID, regardless of whether the spec
On Fri, May 19, 2017 at 5:46 AM, Christoph Hellwig wrote:
>
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 33c2b0b77429..5a7fd3b6a7b9 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1342,7 +1342,7 @@ pci_alloc_irq_vectors_affinity(struct pci_dev *dev,
> unsi
On Thu, Feb 16, 2017 at 12:06 PM, Pavel Machek wrote:
>
> Hmm, that would explain problems at boot _and_ problems during
> suspend/resume.
I've committed the revert, and I'm just assuming that the revert also
fixed your suspend/resume issues, but I wanted to just double-check
that since it's only
On Thu, Feb 16, 2017 at 10:13 AM, Frederic Weisbecker
wrote:
>
> I haven't followed the discussion but this patch has a known issue which is
> fixed
> with:
> 7bdb59f1ad474bd7161adc8f923cdef10f2638d1
> "tick/nohz: Fix possible missing clock reprog after tick soft restart"
>
> I hope this
On Wed, Feb 15, 2017 at 3:20 PM, Pavel Machek wrote:
> 4.10-rc4 broken
> 4.10-rc3 ok
Hmm. If those actually end up being reliable, then there's not a whole
lot in between them wrt PCI or USB.
What looked like the most likely candidate seems to be xhci-specific, though.
But maybe it's something
On Sun, Dec 25, 2016 at 8:09 AM, Raz Manor wrote:
>
> I had a problem with the net2280 driver- reading from an endpoint resulted
> with a wrong read size in some cases.
>
> I found the problem and fixed it, and I wanted to publish the fix. However,
> I have no push access, and I couldn't find who
On Mon, Jun 27, 2016 at 1:27 PM, Sedat Dilek wrote:
>
> I just grepped for some "buzzwords" people gave me in this
> email-thread and I was looking at (llvm.git HEAD - upcoming v3.9
> release) and found these comments in [1]
>
>
> [1]
> https://github.com/llvm-mirror/llvm/blob/master/lib/Target/X
On Mon, Jun 27, 2016 at 12:50 PM, Sedat Dilek wrote:
>
> $ objdump -S clang-eflag.o
>
> clang-eflag.o: file format elf64-x86-64
>
>
> Disassembly of section .text:
>
> :
>0: 55 push %rbp
>1: 48 89 e5mov%rsp,%rbp
>4:
On Fri, Mar 18, 2016 at 3:51 PM, Linus Torvalds
wrote:
>
> The commit that ends up being marked bad is odd, but there it is:
> 69bec7259853 "USB: core: let USB device know device node".
Confirmed. Not only did it bisect to that, reverting it on top of the
current kernel fi
On Wed, Mar 16, 2016 at 5:09 PM, Greg KH wrote:
>
> USB patches for 4.6-rc1
>
> Here is the big USB patchset for 4.6-rc1.
Something in this - or possibly the tty pull, but that doesn't sound
very likely - has killed my USB keyboard on my desktop.
I'm bisecting right now. Expect a likely revert.
On Fri, Mar 18, 2016 at 2:43 PM, Linus Torvalds
wrote:
>
> Something in this - or possibly the tty pull, but that doesn't sound
> very likely - has killed my USB keyboard on my desktop.
Yeah, the bisect is now solidly in the usb part.
The machine has
00:14.0 USB controller: Int
On Fri, Mar 18, 2016 at 3:58 PM, Greg KH wrote:
>
> Yes, people did report issues with that yesterday, and I queued up a
> patch for it, it's attached below, but I didn't think it would cause any
> issues with non-OF systems either. I wanted to give it a few days
> testing in linux-next before se
On Fri, Mar 18, 2016 at 2:58 PM, Linus Torvalds
wrote:
>
> Yeah, the bisect is now solidly in the usb part.
The commit that ends up being marked bad is odd, but there it is:
69bec7259853 "USB: core: let USB device know device node".
Very odd, but I tested multiple times: I&
On Mon, Mar 7, 2016 at 12:15 PM, Bjørn Mork wrote:
> usbnet_link_change will call schedule_work and should be
> avoided if bind is failing. Otherwise we will end up with
> scheduled work referring to a netdev which has gone away.
>
> Instead of making the call conditional, we can just defer
> it t
On Mon, Mar 7, 2016 at 10:07 AM, Alan Stern wrote:
>
> Of course, there are other ways to save a single flag value (such as
> setz). It's up to the compiler developers to decide what they think is
> best.
Using 'setcc' to save eflags somewhere is definitely the right thing to do.
Using pushf/po
On Sat, Mar 5, 2016 at 11:53 AM, Bjørn Mork wrote:
>
>
> Definitely. The patch is so obviously correct that we can only wonder how it
> was possible to miss it it the first place :)
>
> Will take a look to see if we could do a better job cleaning up in other
> places.
What should I do for 4.5?
On Fri, Mar 4, 2016 at 2:26 PM, Andrey Konovalov wrote:
>
> and when I run the vm and connect the device I get:
>
> [ 23.672662] cdc_ncm 1-1:1.6: bind() failure
> [ 23.673447] usbnet_probe(): freeing netdev: 88006ab48000
> [ 23.675822] usbnet_probe(): freeing netdev: 88006ab48000
>
>
[ Moving this to proper lists ]
On Thu, Mar 3, 2016 at 4:19 PM, Andrey Konovalov wrote:
>
> I found another double-free, this time in the usbnet driver.
Hmm. It doesn't look like a double free to me, at least from the logs
you attached.
> Whenever the `bind()` function fails (drivers/net/usb/us
On Sun, Feb 14, 2016 at 12:39 PM, Greg KH wrote:
>
> Ugh, you are right, sorry about that, do you need an updated pull
> request, or are you ok with this one?
I took it and updates the merge log appropriately.
Linus
--
To unsubscribe from this list: send the line "unsubscribe l
On Sun, Feb 14, 2016 at 11:01 AM, Greg KH wrote:
>
> USB and PHY fixes for 4.5-rc4
>
> Here are a number of USB and PHY driver fixes for 4.5-rc4.
Actually, only PHY fixes. The USB fixes you already sent me for rc3.
See merge commit 46df55ceeaf3.
Apparently you haven't updated your upstream tree.
On Thu, Oct 29, 2015 at 4:44 PM, Linus Torvalds
wrote:
>
> That said, I'm pretty sure it's just that there were (and probably
> still are) tons of bad USB sticks with cheap controllers with 8-bit
> sector counts, and you're better off picking something that causes
>
On Thu, Oct 29, 2015 at 4:25 PM, Felipe Balbi wrote:
>
> Fair enough. Linus, do you have any recollection of which device you
> found to be quirky ? Your original commit limitting to 240 sectors
> doesn't make that clear at all ;-)
>
> [1] http://marc.info/?l=git-commits-head&m=106945975115131&w=2
On Tue, Sep 15, 2015 at 12:53 PM, Eric Curtin wrote:
> My first kernel patch, hope I did everything correctly! Instead of calling
> strlen on every iteration of the for loop, just call it once instead and
> store in a variable.
Heh. Ok, that resulted in a rather long email thread.
Anyway, I'd
Hmm. Oliver is marked as the maintainer of the USB CDC code, but
others have touched it more recently. So I'm just wildly adding people
to the cc to comment on this patch and maybe apply it.
Oliver/David/Ben/Bjørn?
Linus
-- Forwarded message --
From: xiaomao
Date
On Mon, Dec 15, 2014 at 3:32 AM, Hans de Goede wrote:
>
> Code wise this looks good and I've just given:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>
> a spin with an uas disk enclosure, and verified that tcq is being used,
> and everything works fine.
Thanks for
On Sun, Dec 14, 2014 at 3:17 PM, Stephen Rothwell wrote:
>
> Attached is the message I sent about this on Nov 24 to which I received
> no response and so assumed it was ok ...
Looks like the same resolution I got.
I'd still prefer to get an actual positive "yup, tested it" about it.
On Sun, Dec 14, 2014 at 2:35 PM, Greg KH wrote:
>
> Hans de Goede (1):
> uas: Make uas work with blk-mq
So I got some fairly trivial conflicts on this one (conflicting with
the scsi cleanups mainly by Christoph Hellwig.
I resolved the conflict easily, and it all *looks* fine, but quite
fra
Hmm, Greg.
I seem to get this problem possibly more commonly at boot these days:
usb 1-6: new full-speed USB device number 2 using xhci_hcd
usb 1-6: device descriptor read/64, error -71
xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 1.
usb 1-6: hub failed to enable dev
On Thu, Jul 24, 2014 at 5:58 AM, Peter Zijlstra wrote:
>
> So going by the nifty picture rostedt made:
>
> [ 61.454336]CPU0CPU1
> [ 61.454336]
> [ 61.454336] lock(&(&p->alloc_lock)->rlock);
> [ 61.454336]
On Wed, Jul 23, 2014 at 2:53 AM, Borislav Petkov wrote:
>
> Well, it looks like we f*cked up something after -rc5 since I'm starting
> to see lockdep splats all over the place which I didn't see before. I'm
> running rc6 + tip/master.
>
> There was one in r8169 yesterday:
>
> https://lkml.kernel.o
On Tue, Apr 1, 2014 at 11:49 AM, Greg KH wrote:
>
> USB patches for 3.15-rc1
>
> Here's the big USB pull request for 3.15-rc1.
Hmm. I'm getting this when testing:
warning: (AHCI_XGENE) selects PHY_XGENE which has unmet direct
dependencies (HAS_IOMEM && OF && (ARM64 || COMPILE_TEST))
which loo
On Tue, Nov 26, 2013 at 2:12 PM, Josh Hunt wrote:
>
> I should have clarified that I'm not using dm/md in my setup. I know
> the modules are getting loaded in the log I attached, but root is not
> a md/dm device.
Hmm. The initcall debugging doesn't actually show any of the "wait for
async events"
On Tue, Nov 26, 2013 at 1:29 PM, Josh Hunt wrote:
>
> Both ahci and sata_svw call ata_host_activate(), which call
> ata_host_register() and async_schedule(async_port_probe, ap).
Well, with the modern logic ("only wait for async probing if the
module itself did async probing") the ahci and svw mod
On Mon, Sep 23, 2013 at 12:30 PM, Felipe Balbi wrote:
>
> I remember there was a discussion of not dropping variable length array
> support, wasn't there ?
We should definitely drop it. The feature is an abomination. I thought
gcc only allowed them at the end of structs, in the middle of a struct
On Wed, May 1, 2013 at 9:13 AM, Alan Stern wrote:
>
> This patch (as1677) removes the remaining instances of that symbol.
Btw, what are these "as" ID's, and what does the noise buy us?
Doing a
git log | egrep -w 'as[0-9]{3,}'
shows that this has been going on forever, but it still doesn'
On Mon, Apr 29, 2013 at 2:14 PM, Alan Stern wrote:
>
> What other things seemed odd about Greg's pull request?
The only other thing I noticed was the new CONFIG_USB_PHY quesiton,
which is not something that I think is sensible to ask from a user,
and the help text doesn't really help anything eit
On Mon, Apr 29, 2013 at 9:23 AM, Greg KH wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/
> tags/usb-3.10-rc1
This has some odd things in it, but I made the mistake of pushing out
my merge before I noticed, so it's out there now regardless.
See here: commit 84ebc10294a
On Sun, Mar 31, 2013 at 3:56 PM, Rafael J. Wysocki wrote:
>
> So, I have two patches (on top of the Linus' tree) that will follow shortly:
Should I take these directly as patches, or expect them to show up in
a pull soon (ie do you have or expect to have other things pending)?
On Fri, Feb 22, 2013 at 4:48 PM, Rafael J. Wysocki wrote:
>
> The problem is, though, that even if bisection turns up something, it doesn't
> automatically mean that this particular commit is the one that caused the
> problem to happen in the first place.
No, I agree. I just react *very* strongly
On Fri, Feb 22, 2013 at 4:19 PM, Rafael J. Wysocki wrote:
>
> It won't revert, there's more stuff on top of it. And it is a fix, so
> reverting it is not really a good idea anyway.
Rafael, please don't *ever* write that crap again.
We revert stuff whether it "fixed" something else or not. The r
On Thu, Feb 21, 2013 at 10:40 AM, Greg KH wrote:
>
> USB patches for 3.9-rc1
>
> Here's the big USB merge for 3.9-rc1
>
> Nothing major, lots of gadget fixes, and of course, xhci stuff.
Ok, so there were a couple of conflicts with Thierry Reding's series
to convert devm_request_and_ioremap() user
On Tue, Jan 22, 2013 at 4:15 PM, Tejun Heo wrote:
>
> Linus, I've updated the description to better explain why it's broken.
> The code is ugly but cleanup patches are already ready, so it will be
> cleaned up during 3.9-rc1. How should this be routed?
I'm not a huge fan of the patch and I might
On Thu, Jan 17, 2013 at 7:04 PM, Tejun Heo wrote:
>
> Another thing is that it seems like having introspection type
> interface often lead to abuses - work_pending(), work_busy() both
> ended up bringing more unnecessary dependencies and subtle bugginess
> on internal details than actual benefits.
On Thu, Jan 17, 2013 at 5:25 PM, Tejun Heo wrote:
> Implement work/async_current_func() which query whether the current
> task is a workqueue or async worker respectively and, if so, return
> the current function being executed along with work / async item
> related information.
So why the odd in
On Thu, Jan 17, 2013 at 10:59 AM, Tejun Heo wrote:
>
> If you're okay with it, I'll route these two and the patches to add
> warning through a wq branch. There's already a wq/for-3.9 patch which
> am_i_async() can make use of, so it's gonna be easier this way.
Sounds good to me. Thanks,
On Thu, Jan 17, 2013 at 10:38 AM, Tejun Heo wrote:
>
> Oh yeah, it's coming. I just wanted to finish something else first
> and, as turning on PF_WQ_WORKER on a rescuer thread has some chance of
> developing into an obscure difficult-to-trigger and diagnose problem,
> don't want to hurry it too m
Tejun, mind explaining this one a bit more to me?
If ordering matters, and we have a running queue and a pending queue,
how could the pending queue *ever* be lower than the running one?
That implies that something was taken off the pending queue and put on
the running queue out of order, right?
les are available in
> the usual places in initramfs, initrd or the root filesystem, the
> default modules are loaded as soon as possible.
>
> This will replace the on-demand elevator module loading from elevator
> init path.
>
> Signed-off-by: Tejun Heo
> Cc: Jens Axboe
On Wed, Jan 16, 2013 at 9:03 AM, Arjan van de Ven wrote:
>
> we can even try twice
>
> the first time right after we mount the initramfs
> the second time when the initramfs code exits, and before we exec init
> (the initramfs supposedly mounted the real root fs at this point)
Yes. This, together
On Tue, Jan 15, 2013 at 7:05 PM, Ming Lei wrote:
>
> So looks only sd.c and floppy.c are to be synchronized suppose
> some sync interfaces are introduced, doesn't it?
What about ata_host_register() (usually called through ata_host_activate())?
I don't understand why you continue to push for some
On Tue, Jan 15, 2013 at 7:25 PM, Tejun Heo wrote:
> Hello, Linus.
>
> On Tue, Jan 15, 2013 at 07:00:31PM -0800, Linus Torvalds wrote:
>> That said, maybe we could just make the rule be that you can't pick a
>> default IO scheduler that is modular.
>
> This is def
On Tue, Jan 15, 2013 at 6:52 PM, Tejun Heo wrote:
>
> It makes me feel dirty but makes the problem go away and I can't think
> of anything better, so here is the implementation of "used async"
> workaround.
Ok, people, can we get a tested-by (or "Nope, doesn't work") from the
people who saw this?
On Tue, Jan 15, 2013 at 4:36 PM, Linus Torvalds
wrote:
>
> There's a reason I asked for a warning for this. Or the "let's flag
> the current thread if it ever started anything asynchronous". Because
> it's complicated.
Btw, the sequence counter (that is *n
On Tue, Jan 15, 2013 at 3:50 PM, Tejun Heo wrote:
>
> For now, I'm gonna implement simple "I'm not gonna wait for myself"
> self-deadlock avoidance.
You can't really do that. Or rather, it won't *help*.
The thing is, the module loading in particular is not necessarily
happening in the same conte
On Tue, Jan 15, 2013 at 10:32 AM, Tejun Heo wrote:
>
> I think the root problem here, apart from request_module() from block
> - which is a bit nasty but making that part completely async would too
> be quite nasty albeit in a different way - is that
> async_synchronize_full() is way too indescrim
On Tue, Jan 15, 2013 at 9:36 AM, Linus Torvalds
wrote:
>
> This kind of "let's randomly encourage people to write subtly buggy
> code that has magical timing dependencies, so that the developer won't
> likely even see it because he has fast disks etc" code is total
[ Added Tejun to the discussion, since he's the async go-to-guy ]
On Mon, Jan 14, 2013 at 10:23 PM, Ming Lei wrote:
>
> But I have another idea to address the problem, and let module code call
> async_synchronize_full() only if the module requires that explicitly, so how
> about the below draft p
On Mon, Jan 14, 2013 at 10:04 AM, Alan Stern wrote:
>
> How about skipping that call if the current thread is one of the async
> helpers? Is it possible to detect when that happens?
>
> Or maybe such a check should go inside async_synchronize_full() itself.
Do we have some idea of exactly what i
On Sun, Jan 13, 2013 at 11:15 PM, Ming Lei wrote:
>
> The deadlock problem is caused by calling request_module() inside
> async function of do_scan_async(), and it was introduced by Linus's
> below commit:
>
> commit d6de2c80e9d758d2e36c21699117db6178c0f517
> Author: Lin
Woody,
Any chance you can bisect this? It's not going to be hugely pleasant
(with 11k+ commits in between 3.7 and 3.8-rc1 you'll have to compile
and test at least 14 kernels), but it would help enormously. Of
course, maybe some USB person can guess what would cause the device to
go offline..
Adde
On Wed, Jul 25, 2012 at 5:35 AM, Ming Lei wrote:
>
> The below patch should fix the problem above.
Actually, I think we could make this even simpler.
There's nothing wrong with saying "user mode is enabled" *just* before
we unthaw things, if we also simply guarantee that there is no
sleeping loc
On Sun, Jul 22, 2012 at 5:58 AM, Borislav Petkov wrote:
>
> Question: is there any other reason
>
> [besides maybe embedded people who care about each single Kb of memory
>on the system]
>
> why we don't make this cache/uncache firmware thing *implicit*? That is,
> load it once at driver ope
On Sat, Jul 21, 2012 at 12:55 PM, Ming Lei wrote:
>
> Suppose it is not good for resume case, I think it still makes sense
> for early boot situation, at least the patch will support to request
> firmware inside init call, and allow drivers to be built in kernel i
> case of requesting firmware fro
On Fri, Jul 20, 2012 at 5:33 AM, Ming Lei wrote:
> The RFC patch is just for discussing if the idea of deferring
> request_firmware is doable for addressing the issue of
> request_firmware in resume path, which is caused by driver
> unbind/rebind during resume.
NAK.
It really *has* to be handled
75 matches
Mail list logo
