* Fwd: How to determine which device crashes udev in boot?
From: iwillallways forget1 @ 2016-03-15 1:39 UTC (permalink / raw)
To: linux-hotplug
Greg KH, thank you for replying to me, since your bot on your
documented e-mail address kept deleting my message and kept telling me
to resend if I really intended to mail you, whereupon it automatically
deleted the resends, etc.
Does anyone know why my real e-mail address n0diamond attract yahoo
dotty co dotty jp iw disliked by vger.kernel.org? What spam does it
accuse me of spamming?
Greg KH wrote:
> I (Norman Diamond) wrote:
>> I'm trying to narrow which device in an NEC VF-6 causes Linux boots to
>> hang, permanently, in udevadm trigger and udevadm settle. Many Google
>> searches found many pages but no tutorials on how to debug udev this
>> way.
>> I downloaded fresh copies of Porteus 3.1 32-bit and 64-bit.
>
> What kernel versions are these?
3.17.4. I had the same problem with kernel 3.4.something and probably
some older ones, but that's probabky beside the point because the
question of how to track down the device is a udev question.
>> Porteus 3.1 64-bit boots fine, udev finds everything, x Windows works
>> (I told you Windows rulez)
(Oh yeah, I created a throwaway account on outlook.com but
vger.kernel.org accused my brand new account of being a spammer too,
and I forgot to delete that part when trying to send from gmail.com)
>> etc. Even on this NEC VF-6.
>>
>> Porteus 3.1 32-bit boots fine on everything except this NEC VF-6, x
>> Windows works, etc.
>>
>> Porteus 3.1 32-bit hangs when starting udev on this NEC VF-6.
>>
>> Booting with "3 nohotplug" works (3 tells Porteus what run level to
>> use, and nohotplug is observed by both the kernel and Porteus). In
>> text mode I can do some amount of experiments. I don't know how to do
>> meaningful experiments, to try to track down which device causes the
>> hang.
>
> Try looking at the documentation of udevadm, you can manually enable the
> 'coldplug' options there to narrow down what hardware is causing the
> problem.
That's exactly what I want to do. Several Google searches today were
as futile as dozens of Google searches during the past week. As far
as I can tell, udevadm trigger --actiond (the same as in rc.udev)
adds everything, and there is some way to exclude an individual device
but I haven't found how to specify a device correctly to get it
excluded.
--max-childs=1 and stuff like that have not helped.
> Odds are, you have a kernel driver that doesn't like the
> hardware and it is getting loaded automatically by udev.
Yes, that's why I'm asking how to track down which device it is.
If the problematic device is something not needed for my employer's
product, I can try to blacklist the device if I can figure out or get
help to do it. But first I have to find out which device it is.
Some devices obviously have drivers running already before udevd and
udevadm trigger get started. But for example if I type startx then
the video driver gets loaded dynamically and the keyboard and mouse
die dynamically, so I have to press the power switch. So I think the
kernel hang comes from some other driver getting loaded dynamically
after udevd starts and udevadm triggers everything, but I can't find
what device it is.
Some device has a working driver for Porteus's 64-bit kernel but a
crashing driver for Porteus's 32-bit kernel, and the crash is so hard
that it doesn't even start flashing two keyboard lights. Also this
being text mode (when I type udevadm not startx), the crash is so hard
that it doesn't print an oops.
greg k-h
^ permalink raw reply
* Re: How to determine which device crashes udev in boot?
From: Greg KH @ 2016-03-14 17:49 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAD4SBxADbDuHn45WNxqdcRfFM=uu8=vXUYLhKc6JNaY5JL-DLw@mail.gmail.com>
On Mon, Mar 14, 2016 at 01:48:39PM +0900, iwillallways forget1 wrote:
> I'm trying to narrow which device in an NEC VF-6 causes Linux boots to
> hang, permanently, in udevadm trigger and udevadm settle. Many Google
> searches found many pages but no tutorials on how to debug udev this
> way.
>
> I downloaded fresh copies of Porteus 3.1 32-bit and 64-bit.
What kernel versions are these?
> Porteus 3.1 64-bit boots fine, udev finds everything, x Windows works
> (I told you Windows rulez), etc. Even on this NEC VF-6.
>
> Porteus 3.1 32-bit boots fine on everything except this NEC VF-6, x
> Windows works, etc.
>
> Porteus 3.1 32-bit hangs when starting udev on this NEC VF-6. It's
> not a 120-second timeout in udevadm settle. It never wakes up. The
> Caps Lock key stops toggling the Caps Lock light. The Num Lock key
> stops toggling the Num Lock light. Ctrl+Alt+Delete is ignored. It
> does not appear to be a kernel panic because two of the keyboard
> lights don't flash. It is hanged, frozen, dead.
>
> Booting with "3 nohotplug" works (3 tells Porteus what run level to
> use, and nohotplug is observed by both the kernel and Porteus). In
> text mode I can do some amount of experiments. I don't know how to do
> meaningful experiments, to try to track down which device causes the
> hang.
Try looking at the documentation of udevadm, you can manually enable the
'coldplug' options there to narrow down what hardware is causing the
problem. Odds are, you have a kernel driver that doesn't like the
hardware and it is getting loaded automatically by udev.
good luck!
greg k-h
^ permalink raw reply
* How to determine which device crashes udev in boot?
From: iwillallways forget1 @ 2016-03-14 4:48 UTC (permalink / raw)
To: linux-hotplug
I'm trying to narrow which device in an NEC VF-6 causes Linux boots to
hang, permanently, in udevadm trigger and udevadm settle. Many Google
searches found many pages but no tutorials on how to debug udev this
way.
I downloaded fresh copies of Porteus 3.1 32-bit and 64-bit.
Porteus 3.1 64-bit boots fine, udev finds everything, x Windows works
(I told you Windows rulez), etc. Even on this NEC VF-6.
Porteus 3.1 32-bit boots fine on everything except this NEC VF-6, x
Windows works, etc.
Porteus 3.1 32-bit hangs when starting udev on this NEC VF-6. It's
not a 120-second timeout in udevadm settle. It never wakes up. The
Caps Lock key stops toggling the Caps Lock light. The Num Lock key
stops toggling the Num Lock light. Ctrl+Alt+Delete is ignored. It
does not appear to be a kernel panic because two of the keyboard
lights don't flash. It is hanged, frozen, dead.
Booting with "3 nohotplug" works (3 tells Porteus what run level to
use, and nohotplug is observed by both the kernel and Porteus). In
text mode I can do some amount of experiments. I don't know how to do
meaningful experiments, to try to track down which device causes the
hang.
The kernel in Porteus 3.1 32-bit is configured with EISA enabled but
not in Porteus 3.1 64-bit. I think I could figure out how to try
udevadm trigger excluding eisa, but it still hanged. The PC doesn't
actually contain any EISA devices, so there's an eisa.0 bus but no
actual devices, so this experiment didn't change anything.
Obviously for myself I could just run 64-bit Linux on this PC, but
this doesn't solve the problem. I have to provide something that
customers can run on any PC made since around 1999, and a lot of those
don't have 64-bit CPUs. I don't know if NEC VF-6 is the only model
that has problems, but I have to be able to patch something to work
around this kind of problem when I learn about them.
Someone found that pci=use_crs solved udev hangs on some PCs, but it
didn't help on NEC VF-6.
(By the way, my name is Norman Diamond. vger.kernel.org bounces mail
from my real e-mail address n0diamond atsign yahoo period co period jp
because I've been a big bad spammer, but I don't know what spams I
seent.)
^ permalink raw reply
* Re: Fwd: Information request on /dev/bus/usb
From: Greg KH @ 2016-02-10 16:17 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAHsu+ktg3E_6Sj0=F0P-5zeXM7Acq1_hk0qZNebG4nHC7Vig7g@mail.gmail.com>
On Wed, Feb 10, 2016 at 04:48:49PM +0530, Ahamed wrote:
> Hi,
>
> Looks like we have some issues enabling udev.
> So, as an alternative, I mounted devtmpfs using the command
>
> mount -t devtmpfs none /dev
>
> Now all the USB devices are available.
udev is not an "alternative" to devtmpfs, they work in tandom, you need
both.
good luck!
greg k-h
^ permalink raw reply
* Re: Fwd: Information request on /dev/bus/usb
From: Ahamed @ 2016-02-10 11:30 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAHsu+ktg3E_6Sj0=F0P-5zeXM7Acq1_hk0qZNebG4nHC7Vig7g@mail.gmail.com>
Hi,
Looks like we have some issues enabling udev.
So, as an alternative, I mounted devtmpfs using the command
mount -t devtmpfs none /dev
Now all the USB devices are available.
Thank you for the help.
regards,
Ahamed
On Wed, Feb 10, 2016 at 2:31 AM, Greg KH <greg@kroah.com> wrote:
> On Wed, Feb 10, 2016 at 01:48:40AM +0530, Ahamed wrote:
>> Dear Greg,
>>
>> > And devtmpfs, which you do have enabled, right?
>>
>> Yes, devtmps is enabled
>>
>> >> lsusb
>> >> is not working since there is nothing under /dev/bus/usb.
>>
>> >Then you should update your version of libusb and usbutils, it handled
>> >this change automatically.
>>
>> Yes, I am trying to update these libs.
>>
>>
>> >They should still be there, perhaps your distro did not properly update
>> >other things needed for this?
>> I am trying to find out why the devices are not showing under /dev/bus/usb.
>> I dont even find the folder bus inside /dev. Can you please let me
>> know if there are any configuration that is needed?
>> Also, i dont see udev daemon running on the box.
>
> Then I suggest you work on fixing that first :)
>
> Also, please talk to the distro developers who put together your system,
> odds are there are lots of things you should be upgrading at the same
> time you upgrade your kernel version.
>
> good luck!
>
> greg k-h
^ permalink raw reply
* Re: Fwd: Information request on /dev/bus/usb
From: Greg KH @ 2016-02-09 21:01 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAHsu+ktg3E_6Sj0=F0P-5zeXM7Acq1_hk0qZNebG4nHC7Vig7g@mail.gmail.com>
On Wed, Feb 10, 2016 at 01:48:40AM +0530, Ahamed wrote:
> Dear Greg,
>
> > And devtmpfs, which you do have enabled, right?
>
> Yes, devtmps is enabled
>
> >> lsusb
> >> is not working since there is nothing under /dev/bus/usb.
>
> >Then you should update your version of libusb and usbutils, it handled
> >this change automatically.
>
> Yes, I am trying to update these libs.
>
>
> >They should still be there, perhaps your distro did not properly update
> >other things needed for this?
> I am trying to find out why the devices are not showing under /dev/bus/usb.
> I dont even find the folder bus inside /dev. Can you please let me
> know if there are any configuration that is needed?
> Also, i dont see udev daemon running on the box.
Then I suggest you work on fixing that first :)
Also, please talk to the distro developers who put together your system,
odds are there are lots of things you should be upgrading at the same
time you upgrade your kernel version.
good luck!
greg k-h
^ permalink raw reply
* Re: Fwd: Information request on /dev/bus/usb
From: Ahamed @ 2016-02-09 20:30 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAHsu+ktg3E_6Sj0=F0P-5zeXM7Acq1_hk0qZNebG4nHC7Vig7g@mail.gmail.com>
Dear Greg,
> And devtmpfs, which you do have enabled, right?
Yes, devtmps is enabled
>> lsusb
>> is not working since there is nothing under /dev/bus/usb.
>Then you should update your version of libusb and usbutils, it handled
>this change automatically.
Yes, I am trying to update these libs.
>They should still be there, perhaps your distro did not properly update
>other things needed for this?
I am trying to find out why the devices are not showing under /dev/bus/usb.
I dont even find the folder bus inside /dev. Can you please let me
know if there are any configuration that is needed?
Also, i dont see udev daemon running on the box.
regards,
Ahamed
On Wed, Feb 10, 2016 at 1:21 AM, Greg KH <greg@kroah.com> wrote:
> On Wed, Feb 10, 2016 at 01:04:57AM +0530, Ahamed wrote:
>> I hope you are well and doing great.
>>
>> I really want some help from you regarding the /dev/bus/usb
>>
>>
>> Initially, we were on 3.4 Kernel and were using usbfs. Hence, using
>> the command "mount -t usbfs none /proc/bus/usb". This showed all our
>> usb devices under /proc/bus/usb.
>>
>> Now we have moved to 3.14 and I understand that usbfs is no longer supported.
>>
>> But I am not able to see the devices under /dev/bus/usb.
>
> They should still be there, perhaps your distro did not properly update
> other things needed for this?
>
>> I see them
>> under /sys/bus/usb. I came to know that /dev is managed by udev.
>
> And devtmpfs, which you do have enabled, right?
>
>> lsusb
>> is not working since there is nothing under /dev/bus/usb.
>
> Then you should update your version of libusb and usbutils, it handled
> this change automatically.
>
> And note, 3.14 is very old and obsolete, I suggest updating to a more
> modern kernel version, or, ask these questions to the company that is
> forcing you to stay with such an old and obsolete kernel version, as you
> are paying them for support.
>
> Hope this helps,
>
> greg k-h
^ permalink raw reply
* Re: Fwd: Information request on /dev/bus/usb
From: Greg KH @ 2016-02-09 19:51 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAHsu+ktg3E_6Sj0=F0P-5zeXM7Acq1_hk0qZNebG4nHC7Vig7g@mail.gmail.com>
On Wed, Feb 10, 2016 at 01:04:57AM +0530, Ahamed wrote:
> I hope you are well and doing great.
>
> I really want some help from you regarding the /dev/bus/usb
>
>
> Initially, we were on 3.4 Kernel and were using usbfs. Hence, using
> the command "mount -t usbfs none /proc/bus/usb". This showed all our
> usb devices under /proc/bus/usb.
>
> Now we have moved to 3.14 and I understand that usbfs is no longer supported.
>
> But I am not able to see the devices under /dev/bus/usb.
They should still be there, perhaps your distro did not properly update
other things needed for this?
> I see them
> under /sys/bus/usb. I came to know that /dev is managed by udev.
And devtmpfs, which you do have enabled, right?
> lsusb
> is not working since there is nothing under /dev/bus/usb.
Then you should update your version of libusb and usbutils, it handled
this change automatically.
And note, 3.14 is very old and obsolete, I suggest updating to a more
modern kernel version, or, ask these questions to the company that is
forcing you to stay with such an old and obsolete kernel version, as you
are paying them for support.
Hope this helps,
greg k-h
^ permalink raw reply
* Fwd: Information request on /dev/bus/usb
From: Ahamed @ 2016-02-09 19:46 UTC (permalink / raw)
To: linux-hotplug
I hope you are well and doing great.
I really want some help from you regarding the /dev/bus/usb
Initially, we were on 3.4 Kernel and were using usbfs. Hence, using
the command "mount -t usbfs none /proc/bus/usb". This showed all our
usb devices under /proc/bus/usb.
Now we have moved to 3.14 and I understand that usbfs is no longer supported.
But I am not able to see the devices under /dev/bus/usb. I see them
under /sys/bus/usb. I came to know that /dev is managed by udev. lsusb
is not working since there is nothing under /dev/bus/usb.
Can you help in giving some hints on how to resolve this issue?
Thanks in advance for the help.
regards,
Ahamed
^ permalink raw reply
* Re: Improved fxload [Was: Re: fxload devpath]
From: Wojciech A. Koszek @ 2015-10-19 5:53 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <561B3ADF.5010308@koszek.com>
Carl,
Thanks for testing. I gave you the credit for mentioning
LIBUSB_SUPPORT=1. I forgot about it.
W.
On 10/13/15 10:52 AM, Carl Karsten wrote:
> looks like I need to set LIBUSB_SUPPORT
> $ LIBUSB_SUPPORT=1 make
>
> And now it is working as described, which is very nice.
> +1 mainline
>
> Q: What happens if there are 2 devices plugged in?
>
> I am assuming it uses the first one it finds.
> For my usage that is fine.
> You might want to add an index or something, although in those cases
> the person can just use the devpath. I expect most people will be
> using this from a udev rule that acts on the device being plugged in.
>
>
> On Sun, Oct 11, 2015 at 11:45 PM, Wojciech A. Koszek
> <wojciech@koszek.com> wrote:
>> Hello,
>>
>> In May 2010 I've fixed fxload by adding LibUSB support.
>>
>> After seeing Carl's e-mail I dug out a patches from backup, and made a repo
>> out of it:
>>
>> https://github.com/wkoszek/fxload
>>
>> So basically fxload would gain LibUSB support and much easier usage, since
>> the paths which fxload requires right now change for some devices doing
>> re-enumeration.
>>
>> Back then I failed to get any replies. Retrying now in hope we could get
>> these fixes into mainline.
>>
>> Thanks,
>>
>> Wojciech
>>
>> On 10/11/15 8:23 PM, Andrei Borzenkov wrote:
>>> 12.10.2015 01:29, Carl Karsten пишет:
>>>> man fxload - Firmware download to EZ-USB devices
>>>>
>>>> fxload [ -v ] [ -l ] [ -D devpath ] ...
>>>>
>>>> -D devpath
>>>> Specifies the "usbfs" path name for the device in
>>>> question, such
>>>> as /proc/bus/usb/004/080. This takes precedence over any
>>>> DEVICE
>>>> environment variable that may be set.
>>>>
>>>> How do I figure out what the devpath is for the device I plugged in?
>>>>
>>>> or.. how do I know what devnum will get assigned?
>>>>
>>>> The device(s) I am working with:
>>>>
>>>> juser@dc10b:~$ lsusb -s 2:9; lsusb -s 2:10
>>>> Bus 002 Device 009: ID 04e2:1410 Exar Corp.
>>>> Bus 002 Device 010: ID 1443:0007 Digilent Development board JTAG
>>>>
>>> Should be /dev/bus/usb/002/010 etc.
>>>
>>>> Ubuntu trusty lts
>>>> Linux dc10b 3.13.0-65-generic #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC
>>>> 2015 x86_64 x86_64 x86_64 GNU/Linux
>>>>
>>>> --
>>>> Carl K
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-hotplug"
>>>> in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-hotplug"
>>> in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>
>
^ permalink raw reply
* Re: [PATCHv4 1/1] SCSI: hosts: update to use ida_simple for host_no management
From: Greg KH @ 2015-10-16 20:14 UTC (permalink / raw)
To: Lee Duncan
Cc: James Bottomley, linux-scsi, linux-kernel, Tejun Heo,
Hannes Reinecke, Johannes Thumshirn, Christoph Hellwig, linux-usb,
linux-hotplug
In-Reply-To: <5621581E.3000407@suse.com>
On Fri, Oct 16, 2015 at 01:03:42PM -0700, Lee Duncan wrote:
> Adding linux-usb and linux-hotplug to cc list, in case they wish to comment.
>
> Summary: I want to change SCSI host number so that it gets re-used, like
> disk index numbers, instead of always increasing.
>
> Please see below.
>
> On 10/14/2015 11:53 AM, James Bottomley wrote:
> > On Wed, 2015-10-14 at 11:34 -0700, Lee Duncan wrote:
> >> On 10/14/2015 06:55 AM, James Bottomley wrote:
> >>> On Wed, 2015-10-07 at 16:51 -0700, Lee Duncan wrote:
> >>>> Update the SCSI hosts module to use the ida_simple*() routines
> >>>> to manage its host_no index instead of an ATOMIC integer. This
> >>>> means that the SCSI host number will now be reclaimable.
> >>>
> >>> OK, but why would we want to do this? We do it for sd because our minor
> >>> space for the device nodes is very constrained, so packing is essential.
> >>> For HBAs, there's no device space density to worry about, they're
> >>> largely statically allocated at boot time and not reusing the numbers
> >>> allows easy extraction of hotplug items for the logs (quite useful for
> >>> USB) because each separate hotplug has a separate and monotonically
> >>> increasing host number.
> >>>
> >>> James
> >>>
> >>
> >> Good question, James. Apologies for not making the need clear.
> >>
> >> The iSCSI subsystem uses a host structure for discovery, then throws it
> >> away. So each time it does discovery it gets a new host structure. With
> >> the current approach, that number is ever increasing. It's only a matter
> >> of time until some user with a hundreds of disks and perhaps thousands
> >> of LUNs, that likes to do periodic discovery (think super-computers)
> >> will run out of host numbers. Or, worse yet, get a negative number
> >> number (because the value is signed right now).
> >>
> >> And this use case is a real one right now, by the way.
> >
> > Um, so even if you do discovery continuously, say one every second, it
> > still will take 68 years before we wrap the sign.
> >
> >> As you can see from the patch, it's a small amount of code to ensure
> >> that the host number management is handled more cleanly.
> >
> > Well, I'm a bit worried about the loss of a monotonically increasing
> > host number from the debugging perspective. Right now, if you look at
> > any log, hostX always refers to one and only one incarnation throughout
> > the system lifetime for any given value of X. With your patch, the
> > lowest host number gets continually reused ... probably for every hot
> > plug event. If the USB and other hotplug system people don't mind this,
> > I suppose I can live with it, but I'd like to hear their view before
> > making this change.
USB "people" don't care about this, why would we? You can plug and
unplug and plug devices in lots of times and they get the "old" names
all the time, this is something that tools have had to deal with for
well over a decade.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCHv4 1/1] SCSI: hosts: update to use ida_simple for host_no management
From: Lee Duncan @ 2015-10-16 20:03 UTC (permalink / raw)
To: James Bottomley
Cc: linux-scsi, linux-kernel, Tejun Heo, Hannes Reinecke,
Johannes Thumshirn, Christoph Hellwig, linux-usb, linux-hotplug
In-Reply-To: <1444848835.2220.50.camel@HansenPartnership.com>
Adding linux-usb and linux-hotplug to cc list, in case they wish to comment.
Summary: I want to change SCSI host number so that it gets re-used, like
disk index numbers, instead of always increasing.
Please see below.
On 10/14/2015 11:53 AM, James Bottomley wrote:
> On Wed, 2015-10-14 at 11:34 -0700, Lee Duncan wrote:
>> On 10/14/2015 06:55 AM, James Bottomley wrote:
>>> On Wed, 2015-10-07 at 16:51 -0700, Lee Duncan wrote:
>>>> Update the SCSI hosts module to use the ida_simple*() routines
>>>> to manage its host_no index instead of an ATOMIC integer. This
>>>> means that the SCSI host number will now be reclaimable.
>>>
>>> OK, but why would we want to do this? We do it for sd because our minor
>>> space for the device nodes is very constrained, so packing is essential.
>>> For HBAs, there's no device space density to worry about, they're
>>> largely statically allocated at boot time and not reusing the numbers
>>> allows easy extraction of hotplug items for the logs (quite useful for
>>> USB) because each separate hotplug has a separate and monotonically
>>> increasing host number.
>>>
>>> James
>>>
>>
>> Good question, James. Apologies for not making the need clear.
>>
>> The iSCSI subsystem uses a host structure for discovery, then throws it
>> away. So each time it does discovery it gets a new host structure. With
>> the current approach, that number is ever increasing. It's only a matter
>> of time until some user with a hundreds of disks and perhaps thousands
>> of LUNs, that likes to do periodic discovery (think super-computers)
>> will run out of host numbers. Or, worse yet, get a negative number
>> number (because the value is signed right now).
>>
>> And this use case is a real one right now, by the way.
>
> Um, so even if you do discovery continuously, say one every second, it
> still will take 68 years before we wrap the sign.
>
>> As you can see from the patch, it's a small amount of code to ensure
>> that the host number management is handled more cleanly.
>
> Well, I'm a bit worried about the loss of a monotonically increasing
> host number from the debugging perspective. Right now, if you look at
> any log, hostX always refers to one and only one incarnation throughout
> the system lifetime for any given value of X. With your patch, the
> lowest host number gets continually reused ... probably for every hot
> plug event. If the USB and other hotplug system people don't mind this,
> I suppose I can live with it, but I'd like to hear their view before
> making this change.
>
> James
>
>
>
>
--
Lee Duncan
SUSE Labs
^ permalink raw reply
* Re: Improved fxload [Was: Re: fxload devpath]
From: Xiaofan Chen @ 2015-10-14 8:47 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <561B3ADF.5010308@koszek.com>
On Mon, Oct 12, 2015 at 12:45 PM, Wojciech A. Koszek
<wojciech@koszek.com> wrote:
> Hello,
>
> In May 2010 I've fixed fxload by adding LibUSB support.
>
> After seeing Carl's e-mail I dug out a patches from backup, and made a repo
> out of it:
>
> https://github.com/wkoszek/fxload
>
> So basically fxload would gain LibUSB support and much easier usage, since
> the paths which fxload requires right now change for some devices doing
> re-enumeration.
>
> Back then I failed to get any replies. Retrying now in hope we could get
> these fixes into mainline.
libusb project shipped with fxload as an example as well. Not so sure which
version is better.
https://github.com/libusb/libusb/tree/master/examples
--
Xiaofan
^ permalink raw reply
* Re: Improved fxload [Was: Re: fxload devpath]
From: Carl Karsten @ 2015-10-13 17:52 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <561B3ADF.5010308@koszek.com>
looks like I need to set LIBUSB_SUPPORT
$ LIBUSB_SUPPORT=1 make
And now it is working as described, which is very nice.
+1 mainline
Q: What happens if there are 2 devices plugged in?
I am assuming it uses the first one it finds.
For my usage that is fine.
You might want to add an index or something, although in those cases
the person can just use the devpath. I expect most people will be
using this from a udev rule that acts on the device being plugged in.
On Sun, Oct 11, 2015 at 11:45 PM, Wojciech A. Koszek
<wojciech@koszek.com> wrote:
> Hello,
>
> In May 2010 I've fixed fxload by adding LibUSB support.
>
> After seeing Carl's e-mail I dug out a patches from backup, and made a repo
> out of it:
>
> https://github.com/wkoszek/fxload
>
> So basically fxload would gain LibUSB support and much easier usage, since
> the paths which fxload requires right now change for some devices doing
> re-enumeration.
>
> Back then I failed to get any replies. Retrying now in hope we could get
> these fixes into mainline.
>
> Thanks,
>
> Wojciech
>
> On 10/11/15 8:23 PM, Andrei Borzenkov wrote:
>>
>> 12.10.2015 01:29, Carl Karsten пишет:
>>>
>>> man fxload - Firmware download to EZ-USB devices
>>>
>>> fxload [ -v ] [ -l ] [ -D devpath ] ...
>>>
>>> -D devpath
>>> Specifies the "usbfs" path name for the device in
>>> question, such
>>> as /proc/bus/usb/004/080. This takes precedence over any
>>> DEVICE
>>> environment variable that may be set.
>>>
>>> How do I figure out what the devpath is for the device I plugged in?
>>>
>>> or.. how do I know what devnum will get assigned?
>>>
>>> The device(s) I am working with:
>>>
>>> juser@dc10b:~$ lsusb -s 2:9; lsusb -s 2:10
>>> Bus 002 Device 009: ID 04e2:1410 Exar Corp.
>>> Bus 002 Device 010: ID 1443:0007 Digilent Development board JTAG
>>>
>>
>> Should be /dev/bus/usb/002/010 etc.
>>
>>> Ubuntu trusty lts
>>> Linux dc10b 3.13.0-65-generic #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC
>>> 2015 x86_64 x86_64 x86_64 GNU/Linux
>>>
>>> --
>>> Carl K
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-hotplug"
>>> in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-hotplug"
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
--
Carl K
^ permalink raw reply
* Re: Improved fxload [Was: Re: fxload devpath]
From: Carl Karsten @ 2015-10-12 5:41 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <561B3ADF.5010308@koszek.com>
Thank you. I'll try this out in the next day or so.
On Sun, Oct 11, 2015 at 11:45 PM, Wojciech A. Koszek
<wojciech@koszek.com> wrote:
> Hello,
>
> In May 2010 I've fixed fxload by adding LibUSB support.
>
> After seeing Carl's e-mail I dug out a patches from backup, and made a repo
> out of it:
>
> https://github.com/wkoszek/fxload
>
> So basically fxload would gain LibUSB support and much easier usage, since
> the paths which fxload requires right now change for some devices doing
> re-enumeration.
>
> Back then I failed to get any replies. Retrying now in hope we could get
> these fixes into mainline.
>
> Thanks,
>
> Wojciech
>
> On 10/11/15 8:23 PM, Andrei Borzenkov wrote:
>>
>> 12.10.2015 01:29, Carl Karsten пишет:
>>>
>>> man fxload - Firmware download to EZ-USB devices
>>>
>>> fxload [ -v ] [ -l ] [ -D devpath ] ...
>>>
>>> -D devpath
>>> Specifies the "usbfs" path name for the device in
>>> question, such
>>> as /proc/bus/usb/004/080. This takes precedence over any
>>> DEVICE
>>> environment variable that may be set.
>>>
>>> How do I figure out what the devpath is for the device I plugged in?
>>>
>>> or.. how do I know what devnum will get assigned?
>>>
>>> The device(s) I am working with:
>>>
>>> juser@dc10b:~$ lsusb -s 2:9; lsusb -s 2:10
>>> Bus 002 Device 009: ID 04e2:1410 Exar Corp.
>>> Bus 002 Device 010: ID 1443:0007 Digilent Development board JTAG
>>>
>>
>> Should be /dev/bus/usb/002/010 etc.
>>
>>> Ubuntu trusty lts
>>> Linux dc10b 3.13.0-65-generic #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC
>>> 2015 x86_64 x86_64 x86_64 GNU/Linux
>>>
>>> --
>>> Carl K
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-hotplug"
>>> in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-hotplug"
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
--
Carl K
^ permalink raw reply
* Improved fxload [Was: Re: fxload devpath]
From: Wojciech A. Koszek @ 2015-10-12 4:45 UTC (permalink / raw)
To: linux-hotplug
Hello,
In May 2010 I've fixed fxload by adding LibUSB support.
After seeing Carl's e-mail I dug out a patches from backup, and made a
repo out of it:
https://github.com/wkoszek/fxload
So basically fxload would gain LibUSB support and much easier usage,
since the paths which fxload requires right now change for some devices
doing re-enumeration.
Back then I failed to get any replies. Retrying now in hope we could get
these fixes into mainline.
Thanks,
Wojciech
On 10/11/15 8:23 PM, Andrei Borzenkov wrote:
> 12.10.2015 01:29, Carl Karsten пишет:
>> man fxload - Firmware download to EZ-USB devices
>>
>> fxload [ -v ] [ -l ] [ -D devpath ] ...
>>
>> -D devpath
>> Specifies the "usbfs" path name for the device in
>> question, such
>> as /proc/bus/usb/004/080. This takes precedence over
>> any DEVICE
>> environment variable that may be set.
>>
>> How do I figure out what the devpath is for the device I plugged in?
>>
>> or.. how do I know what devnum will get assigned?
>>
>> The device(s) I am working with:
>>
>> juser@dc10b:~$ lsusb -s 2:9; lsusb -s 2:10
>> Bus 002 Device 009: ID 04e2:1410 Exar Corp.
>> Bus 002 Device 010: ID 1443:0007 Digilent Development board JTAG
>>
>
> Should be /dev/bus/usb/002/010 etc.
>
>> Ubuntu trusty lts
>> Linux dc10b 3.13.0-65-generic #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC
>> 2015 x86_64 x86_64 x86_64 GNU/Linux
>>
>> --
>> Carl K
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-hotplug" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-hotplug" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: fxload devpath
From: Andrei Borzenkov @ 2015-10-12 3:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CADmzSShFRZqhkPgie97q6mEEG6cpm=uKVjoNwYgqs=2agfktBQ@mail.gmail.com>
12.10.2015 01:29, Carl Karsten пишет:
> man fxload - Firmware download to EZ-USB devices
>
> fxload [ -v ] [ -l ] [ -D devpath ] ...
>
> -D devpath
> Specifies the "usbfs" path name for the device in question, such
> as /proc/bus/usb/004/080. This takes precedence over any DEVICE
> environment variable that may be set.
>
> How do I figure out what the devpath is for the device I plugged in?
>
> or.. how do I know what devnum will get assigned?
>
> The device(s) I am working with:
>
> juser@dc10b:~$ lsusb -s 2:9; lsusb -s 2:10
> Bus 002 Device 009: ID 04e2:1410 Exar Corp.
> Bus 002 Device 010: ID 1443:0007 Digilent Development board JTAG
>
Should be /dev/bus/usb/002/010 etc.
> Ubuntu trusty lts
> Linux dc10b 3.13.0-65-generic #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC
> 2015 x86_64 x86_64 x86_64 GNU/Linux
>
> --
> Carl K
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* fxload devpath
From: Carl Karsten @ 2015-10-11 22:29 UTC (permalink / raw)
To: linux-hotplug
man fxload - Firmware download to EZ-USB devices
fxload [ -v ] [ -l ] [ -D devpath ] ...
-D devpath
Specifies the "usbfs" path name for the device in question, such
as /proc/bus/usb/004/080. This takes precedence over any DEVICE
environment variable that may be set.
How do I figure out what the devpath is for the device I plugged in?
or.. how do I know what devnum will get assigned?
The device(s) I am working with:
juser@dc10b:~$ lsusb -s 2:9; lsusb -s 2:10
Bus 002 Device 009: ID 04e2:1410 Exar Corp.
Bus 002 Device 010: ID 1443:0007 Digilent Development board JTAG
Ubuntu trusty lts
Linux dc10b 3.13.0-65-generic #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC
2015 x86_64 x86_64 x86_64 GNU/Linux
--
Carl K
^ permalink raw reply
* Re: [Intel-wired-lan] [Patch V3 5/9] i40e: Use numa_mem_id() to better support memoryless node
From: Jiang Liu @ 2015-10-09 9:25 UTC (permalink / raw)
To: Kamezawa Hiroyuki, Andrew Morton, David Rientjes
Cc: Patil, Kiran, Mel Gorman, Mike Galbraith, Peter Zijlstra,
Wysocki, Rafael J, Tang Chen, Tejun Heo, Kirsher, Jeffrey T,
Brandeburg, Jesse, Nelson, Shannon, Wyborny, Carolyn,
Skidmore, Donald C, Vick, Matthew, Ronciak, John,
Williams, Mitch A, Luck, Tony, netdev@vger.kernel.org,
x86@kernel.org, linux-hotplug@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
intel-wired-lan@lists.osuosl.org
In-Reply-To: <56178419.6090503@jp.fujitsu.com>
On 2015/10/9 17:08, Kamezawa Hiroyuki wrote:
> On 2015/10/09 14:52, Jiang Liu wrote:
>> On 2015/10/9 4:20, Andrew Morton wrote:
>>> On Wed, 19 Aug 2015 17:18:15 -0700 (PDT) David Rientjes
>>> <rientjes@google.com> wrote:
>>>
>>>> On Wed, 19 Aug 2015, Patil, Kiran wrote:
>>>>
>>>>> Acked-by: Kiran Patil <kiran.patil@intel.com>
>>>>
>>>> Where's the call to preempt_disable() to prevent kernels with
>>>> preemption
>>>> from making numa_node_id() invalid during this iteration?
>>>
>>> David asked this question twice, received no answer and now the patch
>>> is in the maintainer tree, destined for mainline.
>>>
>>> If I was asked this question I would respond
>>>
>>> The use of numa_mem_id() is racy and best-effort. If the unlikely
>>> race occurs, the memory allocation will occur on the wrong node, the
>>> overall result being very slightly suboptimal performance. The
>>> existing use of numa_node_id() suffers from the same issue.
>>>
>>> But I'm not the person proposing the patch. Please don't just ignore
>>> reviewer comments!
>> Hi Andrew,
>> Apologize for the slow response due to personal reasons!
>> And thanks for answering the question from David. To be honest,
>> I didn't know how to answer this question before. Actually this
>> question has puzzled me for a long time when dealing with memory
>> hot-removal. For normal cases, it only causes sub-optimal memory
>> allocation if schedule event happens between querying NUMA node id
>> and calling alloc_pages_node(). But what happens if system run into
>> following execution sequence?
>> 1) node = numa_mem_id();
>> 2) memory hot-removal event triggers
>> 2.1) remove affected memory
>> 2.2) reset pgdat to zero if node becomes empty after memory removal
>
> I'm sorry if I misunderstand something.
> After commit b0dc3a342af36f95a68fe229b8f0f73552c5ca08, there is no
> memset().
Hi Kamezawa,
Thanks for the information. The commit solved the issue what
I was puzzling about. With this change applied, thing should work
as expected. Seems it would be better to enhance __build_all_zonelists()
to handle those offlined empty nodes too, but that really doesn't
make to much difference:)
Thanks for the info again!
Thanks!
Gerry
^ permalink raw reply
* Re: [Intel-wired-lan] [Patch V3 5/9] i40e: Use numa_mem_id() to better support memoryless node
From: Kamezawa Hiroyuki @ 2015-10-09 9:08 UTC (permalink / raw)
To: Jiang Liu, Andrew Morton, David Rientjes
Cc: Patil, Kiran, Mel Gorman, Mike Galbraith, Peter Zijlstra,
Wysocki, Rafael J, Tang Chen, Tejun Heo, Kirsher, Jeffrey T,
Brandeburg, Jesse, Nelson, Shannon, Wyborny, Carolyn,
Skidmore, Donald C, Vick, Matthew, Ronciak, John,
Williams, Mitch A, Luck, Tony, netdev@vger.kernel.org,
x86@kernel.org, linux-hotplug@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
intel-wired-lan@lists.osuosl.org
In-Reply-To: <56175637.50102@linux.intel.com>
On 2015/10/09 14:52, Jiang Liu wrote:
> On 2015/10/9 4:20, Andrew Morton wrote:
>> On Wed, 19 Aug 2015 17:18:15 -0700 (PDT) David Rientjes <rientjes@google.com> wrote:
>>
>>> On Wed, 19 Aug 2015, Patil, Kiran wrote:
>>>
>>>> Acked-by: Kiran Patil <kiran.patil@intel.com>
>>>
>>> Where's the call to preempt_disable() to prevent kernels with preemption
>>> from making numa_node_id() invalid during this iteration?
>>
>> David asked this question twice, received no answer and now the patch
>> is in the maintainer tree, destined for mainline.
>>
>> If I was asked this question I would respond
>>
>> The use of numa_mem_id() is racy and best-effort. If the unlikely
>> race occurs, the memory allocation will occur on the wrong node, the
>> overall result being very slightly suboptimal performance. The
>> existing use of numa_node_id() suffers from the same issue.
>>
>> But I'm not the person proposing the patch. Please don't just ignore
>> reviewer comments!
> Hi Andrew,
> Apologize for the slow response due to personal reasons!
> And thanks for answering the question from David. To be honest,
> I didn't know how to answer this question before. Actually this
> question has puzzled me for a long time when dealing with memory
> hot-removal. For normal cases, it only causes sub-optimal memory
> allocation if schedule event happens between querying NUMA node id
> and calling alloc_pages_node(). But what happens if system run into
> following execution sequence?
> 1) node = numa_mem_id();
> 2) memory hot-removal event triggers
> 2.1) remove affected memory
> 2.2) reset pgdat to zero if node becomes empty after memory removal
I'm sorry if I misunderstand something.
After commit b0dc3a342af36f95a68fe229b8f0f73552c5ca08, there is no memset().
> 3) alloc_pages_node(), which may access zero-ed pgdat structure.
?
>
> I haven't found a mechanism to protect system from above sequence yet,
> so puzzled for a long time already:(. Does stop_machine() protect
> system from such a execution sequence?
To access pgdat, a pgdat's zone should be on per-pgdat-zonelist.
Now, __build_all_zonelists() is called under stop_machine(). That's the reason
why you're asking what stop_machine() does. And, as you know, stop_machine() is not
protecting anything. The caller may fallback into removed zone.
Then, let's think.
At first, please note "pgdat" is not removed (and cannot be removed),
accessing pgdat's memory will not cause segmentation fault.
Just contents are problem. At removal, zone's page related information
and pgdat's page related information is cleared.
alloc_pages uses zonelist/zoneref/cache to walk each zones without accessing
pgdat itself. I think accessing zonelist is safe because it's an array updated
by stop_machine().
So, the problem is alloc_pages() can work correctly even if zone contains no page.
I think it should work.
(Note: zones are included in pgdat. So, zeroing pgdat means zeroing zone and other
structures. it will not work.)
So, what problem you see now ?
I'm sorry I can't chase old discusions.
Thanks,
-Kame
^ permalink raw reply
* Re: [Intel-wired-lan] [Patch V3 5/9] i40e: Use numa_mem_id() to better support memoryless node
From: Jiang Liu @ 2015-10-09 5:52 UTC (permalink / raw)
To: Andrew Morton, David Rientjes
Cc: Patil, Kiran, Mel Gorman, Mike Galbraith, Peter Zijlstra,
Wysocki, Rafael J, Tang Chen, Tejun Heo, Kirsher, Jeffrey T,
Brandeburg, Jesse, Nelson, Shannon, Wyborny, Carolyn,
Skidmore, Donald C, Vick, Matthew, Ronciak, John,
Williams, Mitch A, Luck, Tony, netdev@vger.kernel.org,
x86@kernel.org, linux-hotplug@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
intel-wired-lan@lists.osuosl.org
In-Reply-To: <20151008132037.fc3887da0818e7d011cb752f@linux-foundation.org>
On 2015/10/9 4:20, Andrew Morton wrote:
> On Wed, 19 Aug 2015 17:18:15 -0700 (PDT) David Rientjes <rientjes@google.com> wrote:
>
>> On Wed, 19 Aug 2015, Patil, Kiran wrote:
>>
>>> Acked-by: Kiran Patil <kiran.patil@intel.com>
>>
>> Where's the call to preempt_disable() to prevent kernels with preemption
>> from making numa_node_id() invalid during this iteration?
>
> David asked this question twice, received no answer and now the patch
> is in the maintainer tree, destined for mainline.
>
> If I was asked this question I would respond
>
> The use of numa_mem_id() is racy and best-effort. If the unlikely
> race occurs, the memory allocation will occur on the wrong node, the
> overall result being very slightly suboptimal performance. The
> existing use of numa_node_id() suffers from the same issue.
>
> But I'm not the person proposing the patch. Please don't just ignore
> reviewer comments!
Hi Andrew,
Apologize for the slow response due to personal reasons!
And thanks for answering the question from David. To be honest,
I didn't know how to answer this question before. Actually this
question has puzzled me for a long time when dealing with memory
hot-removal. For normal cases, it only causes sub-optimal memory
allocation if schedule event happens between querying NUMA node id
and calling alloc_pages_node(). But what happens if system run into
following execution sequence?
1) node = numa_mem_id();
2) memory hot-removal event triggers
2.1) remove affected memory
2.2) reset pgdat to zero if node becomes empty after memory removal
3) alloc_pages_node(), which may access zero-ed pgdat structure.
I haven't found a mechanism to protect system from above sequence yet,
so puzzled for a long time already:(. Does stop_machine() protect
system from such a execution sequence?
Thanks!
Gerry
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [Patch V3 3/9] sgi-xp: Replace cpu_to_node() with cpu_to_mem() to support memoryless node
From: Jiang Liu @ 2015-10-09 5:04 UTC (permalink / raw)
To: David Rientjes
Cc: Andrew Morton, Mel Gorman, Mike Galbraith, Peter Zijlstra,
Rafael J . Wysocki, Tang Chen, Tejun Heo, Cliff Whickman,
Robin Holt, Tony Luck, linux-mm, linux-hotplug, linux-kernel, x86
In-Reply-To: <55D5755C.5060803@linux.intel.com>
On 2015/8/20 14:36, Jiang Liu wrote:
> On 2015/8/20 8:02, David Rientjes wrote:
>> On Wed, 19 Aug 2015, Jiang Liu wrote:
>>
>>>> Why not simply fix build_zonelists_node() so that the __GFP_THISNODE
>>>> zonelists are set up to reference the zones of cpu_to_mem() for memoryless
>>>> nodes?
>>>>
>>>> It seems much better than checking and maintaining every __GFP_THISNODE
>>>> user to determine if they are using a memoryless node or not. I don't
>>>> feel that this solution is maintainable in the longterm.
>>> Hi David,
>>> There are some usage cases, such as memory migration,
>>> expect the page allocator rejecting memory allocation requests
>>> if there is no memory on local node. So we have:
>>> 1) alloc_pages_node(cpu_to_node(), __GFP_THISNODE) to only allocate
>>> memory from local node.
>>> 2) alloc_pages_node(cpu_to_mem(), __GFP_THISNODE) to allocate memory
>>> from local node or from nearest node if local node is memoryless.
>>>
>>
>> Right, so do you think it would be better to make the default zonelists be
>> setup so that cpu_to_node()->zonelists = cpu_to_mem()->zonelists and then
>> individual callers that want to fail for memoryless nodes check
>> populated_zone() themselves?
> Hi David,
> Great idea:) I think that means we are going to kill the
> concept of memoryless node, and we only need to specially handle
> a few callers who really care about whether there is memory on
> local node.
> Then I need some time to audit all usages of __GFP_THISNODE
> and update you whether it's doable.
Hi David,
It seems that I'm too optimistic:(. After auditing all usages
of __GFP_THISNODE and reading Documentation/vm/numa again, I feel it
would be better to keep cpu_to_mem()/numa_mem_id(). It makes things
more clear if we follow rules:
1) cpu_to_node()/numa_node_id() for schedule domain
2) cpu_to_mem()/numa_mem_id() for memory management domain
3) alloc_pages_node(cpu_to_node(cpu), __GFP_THIS_NODE) for special
usage cases.
And it would be easier for maintenance than open-coded checking of
populated_zone() by using alloc_pages_node(cpu_to_node(cpu),
__GFP_THIS_NODE).
Thanks!
Gerry
^ permalink raw reply
* Re: [Patch V3 2/9] kernel/profile.c: Replace cpu_to_mem() with cpu_to_node()
From: Jiang Liu @ 2015-10-09 2:35 UTC (permalink / raw)
To: David Rientjes
Cc: Andrew Morton, Mel Gorman, Mike Galbraith, Peter Zijlstra,
Rafael J . Wysocki, Tang Chen, Tejun Heo, Tony Luck, linux-mm,
linux-hotplug, linux-kernel, x86
In-Reply-To: <alpine.DEB.2.10.1508191657330.30666@chino.kir.corp.google.com>
On 2015/8/20 8:00, David Rientjes wrote:
> On Wed, 19 Aug 2015, Jiang Liu wrote:
>
>> On 2015/8/18 8:31, David Rientjes wrote:
>>> On Mon, 17 Aug 2015, Jiang Liu wrote:
>>>
>>>> Function profile_cpu_callback() allocates memory without specifying
>>>> __GFP_THISNODE flag, so replace cpu_to_mem() with cpu_to_node()
>>>> because cpu_to_mem() may cause suboptimal memory allocation if
>>>> there's no free memory on the node returned by cpu_to_mem().
>>>>
>>>
>>> Why is cpu_to_node() better with regard to free memory and NUMA locality?
>> Hi David,
>> Thanks for review. This is a special case pointed out by Tejun.
>> For the imagined topology, A<->B<->X<->C<->D, where A, B, C, D has
>> memory and X is memoryless.
>> Possible fallback lists are:
>> B: [ B, A, C, D]
>> X: [ B, C, A, D]
>> C: [ C, D, B, A]
>>
>> cpu_to_mem(X) will either return B or C. Let's assume it returns B.
>> Then we will use "B: [ B, A, C, D]" to allocate memory for X, which
>> is not the optimal fallback list for X. And cpu_to_node(X) returns
>> X, and "X: [ B, C, A, D]" is the optimal fallback list for X.
>
> Ok, that makes sense, but I would prefer that this
> alloc_pages_exact_node() change to alloc_pages_node() since, as you
> mention in your commit message, __GFP_THISNODE is not set.
Hi David,
Sorry for slow response due to personal reasons!
Function alloc_pages_exact_node() has been renamed as
__alloc_pages_node() by commit 96db800f5d73, and __alloc_pages_node()
is a slightly optimized version of alloc_pages_node() which doesn't
fallback to current node for nid = NUMA_NO_NODE case. So it would
be better to keep using __alloc_pages_node() because cpu_to_node()
always returns valid node id.
Thanks!
Gerry
>
> In the longterm, if we setup both zonelists correctly (no __GFP_THISNODE
> and with __GFP_THISNODE), then I'm not sure there's any reason to ever use
> cpu_to_mem() for alloc_pages().
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [Intel-wired-lan] [Patch V3 5/9] i40e: Use numa_mem_id() to better support memoryless node
From: Andrew Morton @ 2015-10-08 20:20 UTC (permalink / raw)
To: David Rientjes
Cc: Patil, Kiran, Jiang Liu, Mel Gorman, Mike Galbraith,
Peter Zijlstra, Wysocki, Rafael J, Tang Chen, Tejun Heo,
Kirsher, Jeffrey T, Brandeburg, Jesse, Nelson, Shannon,
Wyborny, Carolyn, Skidmore, Donald C, Vick, Matthew,
Ronciak, John, Williams, Mitch A, Luck, Tony,
netdev@vger.kernel.org, x86@kernel.org,
linux-hotplug@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, intel-wired-lan@lists.osuosl.org
In-Reply-To: <alpine.DEB.2.10.1508191717450.30666@chino.kir.corp.google.com>
On Wed, 19 Aug 2015 17:18:15 -0700 (PDT) David Rientjes <rientjes@google.com> wrote:
> On Wed, 19 Aug 2015, Patil, Kiran wrote:
>
> > Acked-by: Kiran Patil <kiran.patil@intel.com>
>
> Where's the call to preempt_disable() to prevent kernels with preemption
> from making numa_node_id() invalid during this iteration?
David asked this question twice, received no answer and now the patch
is in the maintainer tree, destined for mainline.
If I was asked this question I would respond
The use of numa_mem_id() is racy and best-effort. If the unlikely
race occurs, the memory allocation will occur on the wrong node, the
overall result being very slightly suboptimal performance. The
existing use of numa_node_id() suffers from the same issue.
But I'm not the person proposing the patch. Please don't just ignore
reviewer comments!
^ permalink raw reply
* Re: possible bug regarding pciehp
From: Tormen @ 2015-09-18 9:19 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <55E70945.6060802@diplomail.ch>
On 09/05/2015 05:38 AM, Greg KH wrote:
> On Fri, Sep 04, 2015 at 09:54:18AM +0200, Tormen wrote:
>> On 09/02/2015 05:27 PM, Greg KH wrote:
>>> On Wed, Sep 02, 2015 at 04:35:49PM +0200, Tormen wrote:
>> When the network driver is loaded it seems to connect as a "PCI Express"
>> device:
>> tg3 0000:0a:00.0 eth0: Tigon3 [partno(BCM957762) rev 57766000] (PCI
>> Express)
>
> That's separate from the thunderbolt controller.
>
>> When I unplug the adapter the first thing appearing in dmesg is pciehp:
>> [ 210.992938] usb 1-2: USB disconnect, device number 4
>> [ 1557.453818] pciehp 0000:06:03.0:pcie24: slot(3-2): Link Down event
>> [ 1557.453870] pciehp 0000:06:03.0:pcie24: Cannot remove display device
>> 0000:08:00.0
>> [ 1557.509812] pciehp 0000:06:03.0:pcie24: Card not present on Slot(3-2)
>> [ 1558.721344] tg3 0000:0a:00.0: tg3_abort_hw timed out, TX_MODE_ENABLE
>> will not clear MAC_TX_MODEÿffffff
>> [ 1558.934601] pciehp 0000:09:00.0:pcie24: unloading service driver pciehp
>> [ 1558.935366] pciehp 0000:09:00.0:pcie24: Timeout on hotplug command
>> 0x1038 (issued 1557532 msec ago)
>> [ 1558.943460] pci_bus 0000:0a: busn_res: [bus 0a] is released
>> [ 1558.958426] pci_bus 0000:09: busn_res: [bus 09-0a] is released
>> [ 1558.958432] acpiphp: Slot [1] unregistered
>> [ 1558.958451] acpiphp: Slot [2-1] unregistered
>> [ 1558.958464] acpiphp: Slot [3-1] unregistered
>> [ 1558.958475] acpiphp: Slot [4-1] unregistered
>> [ 1558.958486] acpiphp: Slot [5-1] unregistered
>>
>> But I am not a kernel, pciehp, thunderbolt specialist :(
>>
>> How can I determine why the pciehp hotplug command 0x1038 timed out ?
>
> No idea, sorry, this is very odd hardware that doesn't follow any spec.
> Try emailing the author of the thunderbolt code, they should be able to
> help you out more.
>
> good luck,
>
> greg k-h
>
Thanks a lot! - I did and he was very kind in answering me right away -
thanks a lot Andreas - and his suggestion did lead to a working patch:
https://bugzilla.kernel.org/show_bug.cgi?id\x100191#c18
which makes the thunderbolt module load on boot and thus - like you
assumed Greg - provides the missing hotplug functionality!
Thanks again !
Tormen
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox