Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down

[poma]

On 06.04.2017 22:25, Jiri Kosina wrote:
> On Thu, 6 Apr 2017, Rafael J. Wysocki wrote:
> 
> Your swap partition may be located on an NVDIMM or be encrypted.

 An NVDIMM should be considered the same as any other persistent storage.

 It may be encrypted, but where's the key stored, how easy is it to retrieve
 and does the swapout code know this?

> Isn't this a bit overly drastic?

 Perhaps, but if it's on disk and it's not encrypted, then maybe not.
>>>
>>> Right.
>>>
>>> Swap encryption is not mandatory and I'm not sure how the hibernate
>>> code can verify whether or not it is in use.
>>
>> BTW, SUSE has patches adding secure boot support to the hibernate code
>> and Jiri promised me to post them last year even. :-)
> 
> Oh, thanks for a friendly ping :) Adding Joey Lee to CC.
> 

Rafael J., are you talking about HIBERNATE_VERIFICATION ?

Ref.
https://github.com/joeyli/linux-s4sign/commits/s4sign-hmac-v2-v4.2-rc8
https://lkml.org/lkml/2015/8/11/47
https://bugzilla.redhat.com/show_bug.cgi?id=1330335

Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down

[poma]

On 06.04.2017 22:25, Jiri Kosina wrote:
> On Thu, 6 Apr 2017, Rafael J. Wysocki wrote:
> 
> Your swap partition may be located on an NVDIMM or be encrypted.

 An NVDIMM should be considered the same as any other persistent storage.

 It may be encrypted, but where's the key stored, how easy is it to retrieve
 and does the swapout code know this?

> Isn't this a bit overly drastic?

 Perhaps, but if it's on disk and it's not encrypted, then maybe not.
>>>
>>> Right.
>>>
>>> Swap encryption is not mandatory and I'm not sure how the hibernate
>>> code can verify whether or not it is in use.
>>
>> BTW, SUSE has patches adding secure boot support to the hibernate code
>> and Jiri promised me to post them last year even. :-)
> 
> Oh, thanks for a friendly ping :) Adding Joey Lee to CC.
> 

Rafael J., are you talking about HIBERNATE_VERIFICATION ?

Ref.
https://github.com/joeyli/linux-s4sign/commits/s4sign-hmac-v2-v4.2-rc8
https://lkml.org/lkml/2015/8/11/47
https://bugzilla.redhat.com/show_bug.cgi?id=1330335

Re: [PATCH 06/11] net: usb: mcs7830: use new api ethtool_{get|set}_link_ksettings

[poma]

On 16.03.2017 23:18, Philippe Reynes wrote:
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> As I don't have the hardware, I'd be very pleased if
> someone may test this patch.
> 
> Signed-off-by: Philippe Reynes <trem...@gmail.com>
> ---
>  drivers/net/usb/mcs7830.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/usb/mcs7830.c b/drivers/net/usb/mcs7830.c
> index 4f345bd..5771ff2 100644
> --- a/drivers/net/usb/mcs7830.c
> +++ b/drivers/net/usb/mcs7830.c
> @@ -464,9 +464,9 @@ static void mcs7830_get_regs(struct net_device *net, 
> struct ethtool_regs *regs,
>   .get_link   = usbnet_get_link,
>   .get_msglevel   = usbnet_get_msglevel,
>   .set_msglevel   = usbnet_set_msglevel,
> - .get_settings   = usbnet_get_settings,
> - .set_settings   = usbnet_set_settings,
>   .nway_reset = usbnet_nway_reset,
> + .get_link_ksettings = usbnet_get_link_ksettings,
> + .set_link_ksettings = usbnet_set_link_ksettings,
>  };
>  
>  static const struct net_device_ops mcs7830_netdev_ops = {
> 

$ modinfo mcs7830 usbnet mii -n
/lib/modules/4.11.0-0.rc3.git0.1.fc26.x86_64/updates/mcs7830.ko
/lib/modules/4.11.0-0.rc3.git0.1.fc26.x86_64/updates/usbnet.ko
/lib/modules/4.11.0-0.rc3.git0.1.fc26.x86_64/updates/mii.ko

$ lsmod | grep mcs7830
mcs783016384  0
usbnet 45056  1 mcs7830
mii16384  2 usbnet,mcs7830

$ nmcli -f GENERAL.DRIVER,GENERAL.STATE device show enp0s4f1u4
GENERAL.DRIVER: MOSCHIP usb-ethernet driver
GENERAL.STATE:  100 (connected)

Tested-by: poma <p...@gmail.com>

Re: [PATCH 06/11] net: usb: mcs7830: use new api ethtool_{get|set}_link_ksettings

[poma]

On 16.03.2017 23:18, Philippe Reynes wrote:
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> As I don't have the hardware, I'd be very pleased if
> someone may test this patch.
> 
> Signed-off-by: Philippe Reynes 
> ---
>  drivers/net/usb/mcs7830.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/usb/mcs7830.c b/drivers/net/usb/mcs7830.c
> index 4f345bd..5771ff2 100644
> --- a/drivers/net/usb/mcs7830.c
> +++ b/drivers/net/usb/mcs7830.c
> @@ -464,9 +464,9 @@ static void mcs7830_get_regs(struct net_device *net, 
> struct ethtool_regs *regs,
>   .get_link   = usbnet_get_link,
>   .get_msglevel   = usbnet_get_msglevel,
>   .set_msglevel   = usbnet_set_msglevel,
> - .get_settings   = usbnet_get_settings,
> - .set_settings   = usbnet_set_settings,
>   .nway_reset = usbnet_nway_reset,
> + .get_link_ksettings = usbnet_get_link_ksettings,
> + .set_link_ksettings = usbnet_set_link_ksettings,
>  };
>  
>  static const struct net_device_ops mcs7830_netdev_ops = {
> 

$ modinfo mcs7830 usbnet mii -n
/lib/modules/4.11.0-0.rc3.git0.1.fc26.x86_64/updates/mcs7830.ko
/lib/modules/4.11.0-0.rc3.git0.1.fc26.x86_64/updates/usbnet.ko
/lib/modules/4.11.0-0.rc3.git0.1.fc26.x86_64/updates/mii.ko

$ lsmod | grep mcs7830
mcs783016384  0
usbnet 45056  1 mcs7830
mii16384  2 usbnet,mcs7830

$ nmcli -f GENERAL.DRIVER,GENERAL.STATE device show enp0s4f1u4
GENERAL.DRIVER: MOSCHIP usb-ethernet driver
GENERAL.STATE:  100 (connected)

Tested-by: poma 

Re: [...] "How does the new naming scheme look like, precisely?"

[poma]

On 14.03.2017 17:16, Tom Horsley wrote:
> And the consistent names change every single time some
> developer decides he just has to rewrite the algorithm
> to make it better, or systemd decides to engluph yet
> another component and not be backward compatible, or
> a kernel developer gets a new motherboard where the
> scheme doesn't work and his fix has the side effect
> of changing the names on thousands of existing systems, etc.
> 
> There have been at least 3 different "immutable" name
> schemes in the short time the whole concept has existed.
> 
> I finally decided to eradicate it and go back to eth0
> and friends because it was infinitely more reliable than
> having to discover yet another naming scheme in every damn
> release.
> 
> Now my only problem will be that they'll probably keep changing
> the name of the kernel option to disable it :-).
> 

This sounds quite disturbing,
can someone from the systemd and kernel campus comment here,
as Tom claims, whether these are the facts?

Re: [...] "How does the new naming scheme look like, precisely?"

[poma]

On 14.03.2017 17:16, Tom Horsley wrote:
> And the consistent names change every single time some
> developer decides he just has to rewrite the algorithm
> to make it better, or systemd decides to engluph yet
> another component and not be backward compatible, or
> a kernel developer gets a new motherboard where the
> scheme doesn't work and his fix has the side effect
> of changing the names on thousands of existing systems, etc.
> 
> There have been at least 3 different "immutable" name
> schemes in the short time the whole concept has existed.
> 
> I finally decided to eradicate it and go back to eth0
> and friends because it was infinitely more reliable than
> having to discover yet another naming scheme in every damn
> release.
> 
> Now my only problem will be that they'll probably keep changing
> the name of the kernel option to disable it :-).
> 

This sounds quite disturbing,
can someone from the systemd and kernel campus comment here,
as Tom claims, whether these are the facts?

Re: crash by cdc_acm driver in kernels 4.8-rc1/5

[poma]

On 21.11.2016 21:23, Wim Osterholt wrote:
> On Mon, Nov 21, 2016 at 04:58:25PM +0100, Wim Osterholt wrote:
>>
>> I didn't find traces of kernel-4.9-rc5 being ran on any of my laptops, so I
>> can't have seen a crash on rc5. It seems rc5 and rc6 is safe now.
> 
> Neither 4.8.10, nor 4.8.9 show the bug.
> It must be a bug ouside cdc_acm that they have fixed. (a late propagation of
> the IRQ-penalty-bug-fix maybe?)
> 
> I'm rebuilding 4.8.8 now.
> 
> Groeten, Wim.
> 


After all the patching and testing I concluded the same, 
breakage came and is gone outside drivers/usb/class/
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/?id=v4.9-rc5=v4.9-rc4

Re: crash by cdc_acm driver in kernels 4.8-rc1/5

[poma]

On 21.11.2016 21:23, Wim Osterholt wrote:
> On Mon, Nov 21, 2016 at 04:58:25PM +0100, Wim Osterholt wrote:
>>
>> I didn't find traces of kernel-4.9-rc5 being ran on any of my laptops, so I
>> can't have seen a crash on rc5. It seems rc5 and rc6 is safe now.
> 
> Neither 4.8.10, nor 4.8.9 show the bug.
> It must be a bug ouside cdc_acm that they have fixed. (a late propagation of
> the IRQ-penalty-bug-fix maybe?)
> 
> I'm rebuilding 4.8.8 now.
> 
> Groeten, Wim.
> 


After all the patching and testing I concluded the same, 
breakage came and is gone outside drivers/usb/class/
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/?id=v4.9-rc5=v4.9-rc4

Re: crash by cdc_acm driver in kernels 4.8-rc1/5

[poma]

On 15.11.2016 01:16, Wim Osterholt wrote:
> On Tue, Oct 18, 2016 at 02:18:43PM +0200, Oliver Neukum wrote:
> 
>> It definitely does not crash and is probed and your .config is not
>> extremely unusual.
> 
> Hmmm.
> 
>> ... Something odd is going on.
> 
> Whell, yes.
> The only thing that appears you'll have to do is unset 'CONFIG_SMP'.
> 
> My machines didn't have the luxury of multicore processors (until recently),
> so there never has been any reason to deliberately switch these options on!
> 
> In the process of searching, many options may have changed. The crash/OOPS
> has now mitigated into just a WARNING with a call trace.
> (Or it could be a totally different bug?)
> After the call trace the device is working normally and a shutdown
> completes to the end now.
> That is with the config given here:
> http://webserver.djo.tudelft.nl/.config-4.9-rc4.OK (CONFIG_SMP=y)
> http://webserver.djo.tudelft.nl/WARNING-4.9-rc4(call trace for C_S unset)
> 
> Tests on other machines with (slightly) different configs all seem to
> confirm that the problems are gone when CONFIG_SMP is set.
> 
> Regards, Wim.
> 
> 

Try retest with mainline 4.9-rc5,
CONFIG_SMP was not crucial[1].

$ grep CONFIG_SMP /boot/config-4.9.0-0.rc5.git0.1.fc26.x86_64*
/boot/config-4.9.0-0.rc5.git0.1.fc26.x86_64:CONFIG_SMP=y
/boot/config-4.9.0-0.rc5.git0.1.fc26.x86_64+debug:CONFIG_SMP=y

[1] https://www.spinics.net/lists/linux-usb/msg148852.html

Re: crash by cdc_acm driver in kernels 4.8-rc1/5

[poma]

On 15.11.2016 01:16, Wim Osterholt wrote:
> On Tue, Oct 18, 2016 at 02:18:43PM +0200, Oliver Neukum wrote:
> 
>> It definitely does not crash and is probed and your .config is not
>> extremely unusual.
> 
> Hmmm.
> 
>> ... Something odd is going on.
> 
> Whell, yes.
> The only thing that appears you'll have to do is unset 'CONFIG_SMP'.
> 
> My machines didn't have the luxury of multicore processors (until recently),
> so there never has been any reason to deliberately switch these options on!
> 
> In the process of searching, many options may have changed. The crash/OOPS
> has now mitigated into just a WARNING with a call trace.
> (Or it could be a totally different bug?)
> After the call trace the device is working normally and a shutdown
> completes to the end now.
> That is with the config given here:
> http://webserver.djo.tudelft.nl/.config-4.9-rc4.OK (CONFIG_SMP=y)
> http://webserver.djo.tudelft.nl/WARNING-4.9-rc4(call trace for C_S unset)
> 
> Tests on other machines with (slightly) different configs all seem to
> confirm that the problems are gone when CONFIG_SMP is set.
> 
> Regards, Wim.
> 
> 

Try retest with mainline 4.9-rc5,
CONFIG_SMP was not crucial[1].

$ grep CONFIG_SMP /boot/config-4.9.0-0.rc5.git0.1.fc26.x86_64*
/boot/config-4.9.0-0.rc5.git0.1.fc26.x86_64:CONFIG_SMP=y
/boot/config-4.9.0-0.rc5.git0.1.fc26.x86_64+debug:CONFIG_SMP=y

[1] https://www.spinics.net/lists/linux-usb/msg148852.html

Re: [PATCH v2] drm/udl: Ensure channel is selected before using the device.

[poma]

On 23.08.2016 07:57, Daniel Vetter wrote:
> On Mon, Aug 22, 2016 at 11:17:34PM +0100, Jamie Lentin wrote:
>> Lift configuration command from udlfb. This appears to be essential for
>> at least a Rextron VCUD-60, without which no URB communication occurs.
>>
>> Signed-off-by: Jamie Lentin 
>> ---
>> udl_encoder_commit() is too late to do this set up in it seems. This
>> setup doesn't need to be performed again after a suspend, although this
>> is somewhat academic until I send the patch adding suspend and resume
>> functions.
>>
>> Tested with a Rextron VCUD-60 attached to a Thinkpad X201s on Linux 4.7.0
> 
> Applied to drm-misc, thanks.
> -Daniel
> 
>>
>> Cheers,
>> ---
>>  drivers/gpu/drm/udl/udl_main.c | 25 +
>>  1 file changed, 25 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
>> index 33dbfb2..29f0207 100644
>> --- a/drivers/gpu/drm/udl/udl_main.c
>> +++ b/drivers/gpu/drm/udl/udl_main.c
>> @@ -16,6 +16,8 @@
>>  /* -BULK_SIZE as per usb-skeleton. Can we get full page and avoid overhead? 
>> */
>>  #define BULK_SIZE 512
>>  
>> +#define NR_USB_REQUEST_CHANNEL 0x12
>> +
>>  #define MAX_TRANSFER (PAGE_SIZE*16 - BULK_SIZE)
>>  #define WRITES_IN_FLIGHT (4)
>>  #define MAX_VENDOR_DESCRIPTOR_SIZE 256
>> @@ -90,6 +92,26 @@ success:
>>  return true;
>>  }
>>  
>> +/*
>> + * Need to ensure a channel is selected before submitting URBs
>> + */
>> +static int udl_select_std_channel(struct udl_device *udl)
>> +{
>> +int ret;
>> +u8 set_def_chn[] = {0x57, 0xCD, 0xDC, 0xA7,
>> +0x1C, 0x88, 0x5E, 0x15,
>> +0x60, 0xFE, 0xC6, 0x97,
>> +0x16, 0x3D, 0x47, 0xF2};
>> +
>> +ret = usb_control_msg(udl->udev,
>> +  usb_sndctrlpipe(udl->udev, 0),
>> +  NR_USB_REQUEST_CHANNEL,
>> +  (USB_DIR_OUT | USB_TYPE_VENDOR), 0, 0,
>> +  set_def_chn, sizeof(set_def_chn),
>> +  USB_CTRL_SET_TIMEOUT);
>> +return ret < 0 ? ret : 0;
>> +}
>> +
>>  static void udl_release_urb_work(struct work_struct *work)
>>  {
>>  struct urb_node *unode = container_of(work, struct urb_node,
>> @@ -301,6 +323,9 @@ int udl_driver_load(struct drm_device *dev, unsigned 
>> long flags)
>>  goto err;
>>  }
>>  
>> +if (udl_select_std_channel(udl))
>> +DRM_ERROR("Selecting channel failed\n");
>> +
>>  if (!udl_alloc_urb_list(dev, WRITES_IN_FLIGHT, MAX_TRANSFER)) {
>>  DRM_ERROR("udl_alloc_urb_list failed\n");
>>  goto err;
>> -- 
>> 2.8.1
>>
> 

It doesn't breaks the device, however under the hood it is boiling,

[ cut here ]
WARNING: CPU: 0 PID: 381 at drivers/usb/core/hcd.c:1584 
usb_hcd_map_urb_for_dma+0x49f/0x770
transfer buffer not dma capable
Modules linked in: ... udl(+) ... drm_kms_helper ... drm ...
CPU: 0 PID: 381 Comm: systemd-udevd Not tainted 
4.9.0-0.rc4.git0.1.fc26.x86_64+debug #1
...
Call Trace:
 [] dump_stack+0x86/0xc3
 [] __warn+0xcb/0xf0
 [] warn_slowpath_fmt+0x5f/0x80
 [] ? debug_dma_mapping_error+0x7b/0x90
 [] usb_hcd_map_urb_for_dma+0x49f/0x770
 [] ? trace_hardirqs_on_caller+0xf5/0x1b0
 [] usb_hcd_submit_urb+0x34d/0xb50
 [] ? mark_held_locks+0x76/0xa0
 [] ? __raw_spin_lock_init+0x21/0x60
 [] ? trace_hardirqs_on_caller+0xf5/0x1b0
 [] usb_submit_urb+0x2f4/0x560
 [] ? lockdep_init_map+0x61/0x210
 [] usb_start_wait_urb+0x74/0x180
 [] usb_control_msg+0xdc/0x120
 [] udl_driver_load+0x141/0x590 [udl]
 [] ? trace_hardirqs_on_caller+0xd1/0x1b0
 [] drm_dev_register+0xa9/0xd0 [drm]
 [] udl_usb_probe+0x42/0x90 [udl]
 [] usb_probe_interface+0x15f/0x2d0
 [] driver_probe_device+0x223/0x430
 [] __driver_attach+0xe3/0xf0
 [] ? driver_probe_device+0x430/0x430
 [] bus_for_each_dev+0x73/0xc0
 [] driver_attach+0x1e/0x20
 [] bus_add_driver+0x173/0x270
 [] driver_register+0x60/0xe0
 [] usb_register_driver+0xaa/0x160
 [] ? 0xc089a000
 [] udl_driver_init+0x1e/0x1000 [udl]
 [] do_one_initcall+0x50/0x180
 [] ? rcu_read_lock_sched_held+0x45/0x80
 [] ? kmem_cache_alloc_trace+0x277/0x2d0
 [] ? do_init_module+0x27/0x1f1
 [] do_init_module+0x5f/0x1f1
 [] load_module+0x2401/0x2b40
 [] ? __symbol_put+0x70/0x70
 [] ? sched_clock_cpu+0x90/0xc0
 [] SYSC_init_module+0x19b/0x1c0
 [] SyS_init_module+0xe/0x10
 [] do_syscall_64+0x6c/0x1f0
 [] entry_SYSCALL64_slow_path+0x25/0x25
---[ end trace 1fa5e22a0dcf62da ]---
[drm:udl_driver_load [udl]] *ERROR* Selecting channel failed
udl 1-2:1.0: fb1: udldrmfb frame buffer device
[drm] Initialized udl on minor 1
usbcore: registered new interface driver udl


Is this expected WARN?


Ref.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/udl?id=d1c151dc
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/core/hcd.c?id=refs/tags/v4.9-rc4#n1584

Re: [PATCH v2] drm/udl: Ensure channel is selected before using the device.

[poma]

On 23.08.2016 07:57, Daniel Vetter wrote:
> On Mon, Aug 22, 2016 at 11:17:34PM +0100, Jamie Lentin wrote:
>> Lift configuration command from udlfb. This appears to be essential for
>> at least a Rextron VCUD-60, without which no URB communication occurs.
>>
>> Signed-off-by: Jamie Lentin 
>> ---
>> udl_encoder_commit() is too late to do this set up in it seems. This
>> setup doesn't need to be performed again after a suspend, although this
>> is somewhat academic until I send the patch adding suspend and resume
>> functions.
>>
>> Tested with a Rextron VCUD-60 attached to a Thinkpad X201s on Linux 4.7.0
> 
> Applied to drm-misc, thanks.
> -Daniel
> 
>>
>> Cheers,
>> ---
>>  drivers/gpu/drm/udl/udl_main.c | 25 +
>>  1 file changed, 25 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
>> index 33dbfb2..29f0207 100644
>> --- a/drivers/gpu/drm/udl/udl_main.c
>> +++ b/drivers/gpu/drm/udl/udl_main.c
>> @@ -16,6 +16,8 @@
>>  /* -BULK_SIZE as per usb-skeleton. Can we get full page and avoid overhead? 
>> */
>>  #define BULK_SIZE 512
>>  
>> +#define NR_USB_REQUEST_CHANNEL 0x12
>> +
>>  #define MAX_TRANSFER (PAGE_SIZE*16 - BULK_SIZE)
>>  #define WRITES_IN_FLIGHT (4)
>>  #define MAX_VENDOR_DESCRIPTOR_SIZE 256
>> @@ -90,6 +92,26 @@ success:
>>  return true;
>>  }
>>  
>> +/*
>> + * Need to ensure a channel is selected before submitting URBs
>> + */
>> +static int udl_select_std_channel(struct udl_device *udl)
>> +{
>> +int ret;
>> +u8 set_def_chn[] = {0x57, 0xCD, 0xDC, 0xA7,
>> +0x1C, 0x88, 0x5E, 0x15,
>> +0x60, 0xFE, 0xC6, 0x97,
>> +0x16, 0x3D, 0x47, 0xF2};
>> +
>> +ret = usb_control_msg(udl->udev,
>> +  usb_sndctrlpipe(udl->udev, 0),
>> +  NR_USB_REQUEST_CHANNEL,
>> +  (USB_DIR_OUT | USB_TYPE_VENDOR), 0, 0,
>> +  set_def_chn, sizeof(set_def_chn),
>> +  USB_CTRL_SET_TIMEOUT);
>> +return ret < 0 ? ret : 0;
>> +}
>> +
>>  static void udl_release_urb_work(struct work_struct *work)
>>  {
>>  struct urb_node *unode = container_of(work, struct urb_node,
>> @@ -301,6 +323,9 @@ int udl_driver_load(struct drm_device *dev, unsigned 
>> long flags)
>>  goto err;
>>  }
>>  
>> +if (udl_select_std_channel(udl))
>> +DRM_ERROR("Selecting channel failed\n");
>> +
>>  if (!udl_alloc_urb_list(dev, WRITES_IN_FLIGHT, MAX_TRANSFER)) {
>>  DRM_ERROR("udl_alloc_urb_list failed\n");
>>  goto err;
>> -- 
>> 2.8.1
>>
> 

It doesn't breaks the device, however under the hood it is boiling,

[ cut here ]
WARNING: CPU: 0 PID: 381 at drivers/usb/core/hcd.c:1584 
usb_hcd_map_urb_for_dma+0x49f/0x770
transfer buffer not dma capable
Modules linked in: ... udl(+) ... drm_kms_helper ... drm ...
CPU: 0 PID: 381 Comm: systemd-udevd Not tainted 
4.9.0-0.rc4.git0.1.fc26.x86_64+debug #1
...
Call Trace:
 [] dump_stack+0x86/0xc3
 [] __warn+0xcb/0xf0
 [] warn_slowpath_fmt+0x5f/0x80
 [] ? debug_dma_mapping_error+0x7b/0x90
 [] usb_hcd_map_urb_for_dma+0x49f/0x770
 [] ? trace_hardirqs_on_caller+0xf5/0x1b0
 [] usb_hcd_submit_urb+0x34d/0xb50
 [] ? mark_held_locks+0x76/0xa0
 [] ? __raw_spin_lock_init+0x21/0x60
 [] ? trace_hardirqs_on_caller+0xf5/0x1b0
 [] usb_submit_urb+0x2f4/0x560
 [] ? lockdep_init_map+0x61/0x210
 [] usb_start_wait_urb+0x74/0x180
 [] usb_control_msg+0xdc/0x120
 [] udl_driver_load+0x141/0x590 [udl]
 [] ? trace_hardirqs_on_caller+0xd1/0x1b0
 [] drm_dev_register+0xa9/0xd0 [drm]
 [] udl_usb_probe+0x42/0x90 [udl]
 [] usb_probe_interface+0x15f/0x2d0
 [] driver_probe_device+0x223/0x430
 [] __driver_attach+0xe3/0xf0
 [] ? driver_probe_device+0x430/0x430
 [] bus_for_each_dev+0x73/0xc0
 [] driver_attach+0x1e/0x20
 [] bus_add_driver+0x173/0x270
 [] driver_register+0x60/0xe0
 [] usb_register_driver+0xaa/0x160
 [] ? 0xc089a000
 [] udl_driver_init+0x1e/0x1000 [udl]
 [] do_one_initcall+0x50/0x180
 [] ? rcu_read_lock_sched_held+0x45/0x80
 [] ? kmem_cache_alloc_trace+0x277/0x2d0
 [] ? do_init_module+0x27/0x1f1
 [] do_init_module+0x5f/0x1f1
 [] load_module+0x2401/0x2b40
 [] ? __symbol_put+0x70/0x70
 [] ? sched_clock_cpu+0x90/0xc0
 [] SYSC_init_module+0x19b/0x1c0
 [] SyS_init_module+0xe/0x10
 [] do_syscall_64+0x6c/0x1f0
 [] entry_SYSCALL64_slow_path+0x25/0x25
---[ end trace 1fa5e22a0dcf62da ]---
[drm:udl_driver_load [udl]] *ERROR* Selecting channel failed
udl 1-2:1.0: fb1: udldrmfb frame buffer device
[drm] Initialized udl on minor 1
usbcore: registered new interface driver udl


Is this expected WARN?


Ref.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/udl?id=d1c151dc
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/core/hcd.c?id=refs/tags/v4.9-rc4#n1584

Re: Kernel panic - not syncing: Fatal exception in interrupt - mainline: 4.4-rc1

[poma]

Hi Fi

please read comment
https://bugzilla.redhat.com/show_bug.cgi?id=1282706#c2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel panic - not syncing: Fatal exception in interrupt - mainline: 4.4-rc1

[poma]

Hi Fi

please read comment
https://bugzilla.redhat.com/show_bug.cgi?id=1282706#c2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Kernel panic - not syncing: Fatal exception in interrupt - mainline: 4.4-rc1

[poma]

WARNING: CPU: 1 PID: 1 at arch/x86/mm/dump_pagetables.c:225 
note_page+0x5e1/0x780()
WARNING: CPU: 0 PID: 18 at kernel/cgroup_pids.c:97 
pids_cancel.constprop.5+0x31/0x40()

Ref.
https://bugzilla.redhat.com/show_bug.cgi?id=1282706
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Kernel panic - not syncing: Fatal exception in interrupt - mainline: 4.4-rc1

[poma]

WARNING: CPU: 1 PID: 1 at arch/x86/mm/dump_pagetables.c:225 
note_page+0x5e1/0x780()
WARNING: CPU: 0 PID: 18 at kernel/cgroup_pids.c:97 
pids_cancel.constprop.5+0x31/0x40()

Ref.
https://bugzilla.redhat.com/show_bug.cgi?id=1282706
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mouse event for unknown monitor - uinput?

[poma]

On Mon, Oct 12, 2015 at 7:59 AM, Dmitry Torokhov
 wrote:
> Hi,
>
> On Mon, Oct 12, 2015 at 06:39:35AM +0200, poma wrote:
>> Hi Fi
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1269667
>>
>> Guys, can you help clarify, can this be a problem of the uinput after all?
>>
>
> There was a regression in uinput code, you need to make sure you have
> commit 72d4736253af74147b1fa68145b2f4c61d1f37e1
>
> Thanks.
>
> --
> Dmitry


Thanks for reply.

Yes, I know it, and it has already been settled with
4.3.0-0.rc4.git0.1.fc24.x86_64

Meanwhile on Rawhide, newer kernels emerged
4.3.0-0.rc4.git1.1.fc24.x86_64
4.3.0-0.rc4.git2.1.fc24.x86_64
4.3.0-0.rc4.git3.1.fc24.x86_64

I patched the kernel 4.3.0-0.rc4.git3.1.fc24.x86_64 with this patch:
https://bugzilla.redhat.com/show_bug.cgi?id=1269667#c17

which is actually a revert to ba4e9a6
as it is in 4.3.0-0.rc0.git7.1.fc24.x86_64
the last working kernel, in this context.

The problem is loss of display, causing loss of mouse functionality,
via SPICE remote computing protocol - if "vga=" higher than standard
80x25 mode (0F00) is used.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mouse event for unknown monitor - uinput?

[poma]

On Mon, Oct 12, 2015 at 7:59 AM, Dmitry Torokhov
<dmitry.torok...@gmail.com> wrote:
> Hi,
>
> On Mon, Oct 12, 2015 at 06:39:35AM +0200, poma wrote:
>> Hi Fi
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1269667
>>
>> Guys, can you help clarify, can this be a problem of the uinput after all?
>>
>
> There was a regression in uinput code, you need to make sure you have
> commit 72d4736253af74147b1fa68145b2f4c61d1f37e1
>
> Thanks.
>
> --
> Dmitry


Thanks for reply.

Yes, I know it, and it has already been settled with
4.3.0-0.rc4.git0.1.fc24.x86_64

Meanwhile on Rawhide, newer kernels emerged
4.3.0-0.rc4.git1.1.fc24.x86_64
4.3.0-0.rc4.git2.1.fc24.x86_64
4.3.0-0.rc4.git3.1.fc24.x86_64

I patched the kernel 4.3.0-0.rc4.git3.1.fc24.x86_64 with this patch:
https://bugzilla.redhat.com/show_bug.cgi?id=1269667#c17

which is actually a revert to ba4e9a6
as it is in 4.3.0-0.rc0.git7.1.fc24.x86_64
the last working kernel, in this context.

The problem is loss of display, causing loss of mouse functionality,
via SPICE remote computing protocol - if "vga=" higher than standard
80x25 mode (0F00) is used.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

mouse event for unknown monitor - uinput?

[poma]

Hi Fi

https://bugzilla.redhat.com/show_bug.cgi?id=1269667

Guys, can you help clarify, can this be a problem of the uinput after all?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

mouse event for unknown monitor - uinput?

[poma]

Hi Fi

https://bugzilla.redhat.com/show_bug.cgi?id=1269667

Guys, can you help clarify, can this be a problem of the uinput after all?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

BUG: quattro stagioni

[poma]

BUG: unable to handle kernel NULL pointer dereference at 0024
BUG: sleeping function called from invalid context at include/linux/sched.h:2756
BUG: scheduling while atomic: spice-vdagentd/906/0x0002
BUG: spinlock lockup suspected on CPU#0, spice-vdagentd/906

https://bugzilla.kernel.org/show_bug.cgi?id=104581
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

BUG: quattro stagioni

[poma]

BUG: unable to handle kernel NULL pointer dereference at 0024
BUG: sleeping function called from invalid context at include/linux/sched.h:2756
BUG: scheduling while atomic: spice-vdagentd/906/0x0002
BUG: spinlock lockup suspected on CPU#0, spice-vdagentd/906

https://bugzilla.kernel.org/show_bug.cgi?id=104581
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: WARNING: CPU: 1 PID: 813 at kernel/module.c:291 module_assert_mutex_or_preempt+0x49/0x90()

[poma]

On 10.08.2015 23:26, poma wrote:
> 
> [ cut here ]
> WARNING: CPU: 1 PID: 813 at kernel/module.c:291 
> module_assert_mutex_or_preempt+0x49/0x90()
> Modules linked in: mxl5007t af9013 ... dvb_usb_af9015(+) ... dvb_usb_v2 
> dvb_core rc_core ...
> CPU: 1 PID: 813 Comm: systemd-udevd Not tainted 
> 4.2.0-0.rc6.git0.1.fc24.x86_64+debug #1
> ...
> Call Trace:
>  [] dump_stack+0x4c/0x65
>  [] warn_slowpath_common+0x86/0xc0
>  [] ? af9013_read_ucblocks+0x20/0x20 [af9013]
>  [] ? af9013_read_ucblocks+0x20/0x20 [af9013]
>  [] warn_slowpath_null+0x1a/0x20
>  [] module_assert_mutex_or_preempt+0x49/0x90
>  [] __module_address+0x32/0x150
>  [] ? af9013_read_ucblocks+0x20/0x20 [af9013]
>  [] ? af9013_read_ucblocks+0x20/0x20 [af9013]
>  [] __module_text_address+0x16/0x70
>  [] ? af9013_read_ucblocks+0x20/0x20 [af9013]
>  [] ? af9013_read_ucblocks+0x20/0x20 [af9013]
>  [] symbol_put_addr+0x29/0x40
>  [] dvb_frontend_detach+0x7d/0x90 [dvb_core]
>  [] dvb_usbv2_probe+0xc85/0x11a0 [dvb_usb_v2]
>  [] af9015_probe+0x84/0xf0 [dvb_usb_af9015]
>  [] usb_probe_interface+0x1bb/0x2e0
>  [] driver_probe_device+0x1f6/0x450
>  [] __driver_attach+0x94/0xa0
>  [] ? driver_probe_device+0x450/0x450
>  [] bus_for_each_dev+0x73/0xc0
>  [] driver_attach+0x1e/0x20
>  [] bus_add_driver+0x1ee/0x280
>  [] driver_register+0x60/0xe0
>  [] usb_register_driver+0xad/0x160
>  [] ? 0xa0567000
>  [] af9015_usb_driver_init+0x1e/0x1000 [dvb_usb_af9015]
>  [] do_one_initcall+0xb3/0x200
>  [] ? kmem_cache_alloc_trace+0x355/0x380
>  [] ? do_init_module+0x28/0x1e9
>  [] do_init_module+0x60/0x1e9
>  [] load_module+0x21f7/0x28d0
>  [] ? m_show+0x1b0/0x1b0
>  [] ? sched_clock+0x9/0x10
>  [] ? local_clock+0x1c/0x20
>  [] SyS_init_module+0x178/0x1c0
>  [] entry_SYSCALL_64_fastpath+0x12/0x76
> ---[ end trace 31a9dd90d4f559f5 ]---
> 
> 
> Ref.
> https://bugzilla.redhat.com/show_bug.cgi?id=1252167
> https://bugzilla.kernel.org/show_bug.cgi?id=102631
> 

You guys are really something.

First of all, as is evident here, I am the original reporter, not Laura Abbott 
.
-All- your comments including the final patch on this issue, are just plain 
wrong.[1]
This patch only hides the actual problem with this particular device - the dual 
tuner combination driven by dvb_usb_af9015 & mxl5007t, broken by design since 
day one.

Read the entire https://bugzilla.redhat.com/show_bug.cgi?id=1252167
and stop this nonsense.

NACK "module: Fix locking in symbol_put_addr()"

[1] http://www.gossamer-threads.com/lists/linux/kernel/2241154


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: WARNING: CPU: 1 PID: 813 at kernel/module.c:291 module_assert_mutex_or_preempt+0x49/0x90()

[poma]

On 10.08.2015 23:26, poma wrote:
 
 [ cut here ]
 WARNING: CPU: 1 PID: 813 at kernel/module.c:291 
 module_assert_mutex_or_preempt+0x49/0x90()
 Modules linked in: mxl5007t af9013 ... dvb_usb_af9015(+) ... dvb_usb_v2 
 dvb_core rc_core ...
 CPU: 1 PID: 813 Comm: systemd-udevd Not tainted 
 4.2.0-0.rc6.git0.1.fc24.x86_64+debug #1
 ...
 Call Trace:
  [81868d8e] dump_stack+0x4c/0x65
  [810ab406] warn_slowpath_common+0x86/0xc0
  [a057d0b0] ? af9013_read_ucblocks+0x20/0x20 [af9013]
  [a057d0b0] ? af9013_read_ucblocks+0x20/0x20 [af9013]
  [810ab53a] warn_slowpath_null+0x1a/0x20
  [81150529] module_assert_mutex_or_preempt+0x49/0x90
  [81150822] __module_address+0x32/0x150
  [a057d0b0] ? af9013_read_ucblocks+0x20/0x20 [af9013]
  [a057d0b0] ? af9013_read_ucblocks+0x20/0x20 [af9013]
  [81150956] __module_text_address+0x16/0x70
  [a057d0b0] ? af9013_read_ucblocks+0x20/0x20 [af9013]
  [a057d0b0] ? af9013_read_ucblocks+0x20/0x20 [af9013]
  [81150f19] symbol_put_addr+0x29/0x40
  [a04b77ad] dvb_frontend_detach+0x7d/0x90 [dvb_core]
  [a04cdfd5] dvb_usbv2_probe+0xc85/0x11a0 [dvb_usb_v2]
  [a05607c4] af9015_probe+0x84/0xf0 [dvb_usb_af9015]
  [8161c03b] usb_probe_interface+0x1bb/0x2e0
  [81579f26] driver_probe_device+0x1f6/0x450
  [8157a214] __driver_attach+0x94/0xa0
  [8157a180] ? driver_probe_device+0x450/0x450
  [815778f3] bus_for_each_dev+0x73/0xc0
  [815796fe] driver_attach+0x1e/0x20
  [8157922e] bus_add_driver+0x1ee/0x280
  [8157b0a0] driver_register+0x60/0xe0
  [8161a87d] usb_register_driver+0xad/0x160
  [a0567000] ? 0xa0567000
  [a056701e] af9015_usb_driver_init+0x1e/0x1000 [dvb_usb_af9015]
  [81002123] do_one_initcall+0xb3/0x200
  [8124ac65] ? kmem_cache_alloc_trace+0x355/0x380
  [81867c37] ? do_init_module+0x28/0x1e9
  [81867c6f] do_init_module+0x60/0x1e9
  [81154167] load_module+0x21f7/0x28d0
  [8114f600] ? m_show+0x1b0/0x1b0
  [81026d79] ? sched_clock+0x9/0x10
  [810e6ddc] ? local_clock+0x1c/0x20
  [811549b8] SyS_init_module+0x178/0x1c0
  [8187282e] entry_SYSCALL_64_fastpath+0x12/0x76
 ---[ end trace 31a9dd90d4f559f5 ]---
 
 
 Ref.
 https://bugzilla.redhat.com/show_bug.cgi?id=1252167
 https://bugzilla.kernel.org/show_bug.cgi?id=102631
 

You guys are really something.

First of all, as is evident here, I am the original reporter, not Laura Abbott 
labb...@redhat.com.
-All- your comments including the final patch on this issue, are just plain 
wrong.[1]
This patch only hides the actual problem with this particular device - the dual 
tuner combination driven by dvb_usb_af9015  mxl5007t, broken by design since 
day one.

Read the entire https://bugzilla.redhat.com/show_bug.cgi?id=1252167
and stop this nonsense.

NACK module: Fix locking in symbol_put_addr()

[1] http://www.gossamer-threads.com/lists/linux/kernel/2241154


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: apropos Regression with 'x86/cacheinfo: Move cacheinfo sysfs code to generic infrastructure' on AMD i686

[poma]

On 14.08.2015 14:12, Peter Hurley wrote:
> On 08/14/2015 06:33 AM, poma wrote:
>>
>> This is broken almost 2 months.
> 
> First reported 19 days ago with fix-it patch on same day.
> 
>> Please push this to the stable 4.1.6 and mainline 4.2-rc7.
> 
> This has already been answered.
> 

Hey man, thanks for reference.
Is there a reason for further testing, I do not see it there in a reply?


> On 08/08/2015 11:41 AM, Greg KH wrote:
>> On Sat, Aug 08, 2015 at 10:46:02AM +0200, Borislav Petkov wrote:
>>> On Mon, Jul 27, 2015 at 09:58:05AM +0200, Borislav Petkov wrote:
>>>> Philip Müller reported a hang when booting 32-bit 4.1 kernel on an AMD
>>>> box. A fragment of the splat was enough to pinpoint the issue:
>>>
>>> Bah, this goes to Greg and not to tip. Anyway, here's a version with
>>> updated tags.
>>>
>>> Greg, please queue for 4.2 as it fixes a hang.
>>
>> What commit caused this issue?
>>
>> And it's a bit late for 4.2, as you say 4.1 is also affected, I'll wait
>> for 4.3-rc1 to give this a chance to get some testing.
>>
>> thanks,
>>
>> greg k-h
> 
> Regards,
> Peter Hurley
> 
> Ref.
> http://www.gossamer-threads.com/lists/linux/kernel/2234622?do=post_view_threaded#2234622
> 
> 
>> Ref.
>> https://bugzilla.kernel.org/show_bug.cgi?id=101971
>> https://bugzilla.redhat.com/show_bug.cgi?id=1253566
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: apropos Regression with 'x86/cacheinfo: Move cacheinfo sysfs code to generic infrastructure' on AMD i686

[poma]

On 14.08.2015 14:12, Peter Hurley wrote:
 On 08/14/2015 06:33 AM, poma wrote:

 This is broken almost 2 months.
 
 First reported 19 days ago with fix-it patch on same day.
 
 Please push this to the stable 4.1.6 and mainline 4.2-rc7.
 
 This has already been answered.
 

Hey man, thanks for reference.
Is there a reason for further testing, I do not see it there in a reply?


 On 08/08/2015 11:41 AM, Greg KH wrote:
 On Sat, Aug 08, 2015 at 10:46:02AM +0200, Borislav Petkov wrote:
 On Mon, Jul 27, 2015 at 09:58:05AM +0200, Borislav Petkov wrote:
 Philip Müller reported a hang when booting 32-bit 4.1 kernel on an AMD
 box. A fragment of the splat was enough to pinpoint the issue:

 Bah, this goes to Greg and not to tip. Anyway, here's a version with
 updated tags.

 Greg, please queue for 4.2 as it fixes a hang.

 What commit caused this issue?

 And it's a bit late for 4.2, as you say 4.1 is also affected, I'll wait
 for 4.3-rc1 to give this a chance to get some testing.

 thanks,

 greg k-h
 
 Regards,
 Peter Hurley
 
 Ref.
 http://www.gossamer-threads.com/lists/linux/kernel/2234622?do=post_view_threaded#2234622
 
 
 Ref.
 https://bugzilla.kernel.org/show_bug.cgi?id=101971
 https://bugzilla.redhat.com/show_bug.cgi?id=1253566
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

apropos Regression with 'x86/cacheinfo: Move cacheinfo sysfs code to generic infrastructure' on AMD i686

[poma]

This is broken almost 2 months.

Please push this to the stable 4.1.6 and mainline 4.2-rc7.

Ref.
https://bugzilla.kernel.org/show_bug.cgi?id=101971
https://bugzilla.redhat.com/show_bug.cgi?id=1253566

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

apropos Regression with 'x86/cacheinfo: Move cacheinfo sysfs code to generic infrastructure' on AMD i686

[poma]

This is broken almost 2 months.

Please push this to the stable 4.1.6 and mainline 4.2-rc7.

Ref.
https://bugzilla.kernel.org/show_bug.cgi?id=101971
https://bugzilla.redhat.com/show_bug.cgi?id=1253566

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

WARNING: CPU: 3 PID: 827 at lib/dma-debug.c:1169 check_for_stack+0x94/0xe0()

[poma]

[ cut here ]
WARNING: CPU: 3 PID: 827 at lib/dma-debug.c:1169 check_for_stack+0x94/0xe0()
ehci-pci :00:02.1: DMA-API: device driver maps memory from stack 
[addr=8800bc6dfa3c]
Modules linked in: ... mt7601u(+) mac80211 ... cfg80211 rfkill ...
CPU: 3 PID: 827 Comm: systemd-udevd Not tainted 
4.2.0-0.rc6.git0.1.fc24.x86_64+debug #1
...
Call Trace:
 [] dump_stack+0x4c/0x65
 [] warn_slowpath_common+0x86/0xc0
 [] warn_slowpath_fmt+0x55/0x70
 [] ? _raw_spin_unlock_irqrestore+0x36/0x60
 [] check_for_stack+0x94/0xe0
 [] debug_dma_map_page+0xfb/0x140
 [] usb_hcd_map_urb_for_dma+0x608/0x760
 [] usb_hcd_submit_urb+0x1cd/0xab0
 [] ? save_trace+0x3f/0xc0
 [] ? mark_held_locks+0x7d/0xb0
 [] ? __raw_spin_lock_init+0x25/0x60
 [] ? lockdep_init_map+0x73/0x640
 [] ? trace_hardirqs_on_caller+0x129/0x1b0
 [] usb_submit_urb+0x3fc/0x5a0
 [] usb_start_wait_urb+0x77/0x180
 [] ? __kmalloc+0x28e/0x360
 [] usb_control_msg+0xdc/0x130
 [] mt7601u_vendor_request+0xf0/0x310 [mt7601u]
 [] ? __mutex_unlock_slowpath+0xbc/0x180
 [] mt7601u_rr+0x59/0x280 [mt7601u]
 [] ? usb_autosuspend_device+0x28/0x30
 [] mt7601u_wait_asic_ready+0x23/0x60 [mt7601u]
 [] mt7601u_probe+0xe0/0x220 [mt7601u]
 [] usb_probe_interface+0x1bb/0x2e0
 [] driver_probe_device+0x1f6/0x450
 [] __driver_attach+0x94/0xa0
 [] ? driver_probe_device+0x450/0x450
 [] bus_for_each_dev+0x73/0xc0
 [] driver_attach+0x1e/0x20
 [] bus_add_driver+0x1ee/0x280
 [] driver_register+0x60/0xe0
 [] usb_register_driver+0xad/0x160
 [] ? 0xa086e000
 [] mt7601u_driver_init+0x1e/0x20 [mt7601u]
 [] do_one_initcall+0xb3/0x200
 [] ? kmem_cache_alloc_trace+0x355/0x380
 [] ? do_init_module+0x28/0x1e9
 [] do_init_module+0x60/0x1e9
 [] load_module+0x21f7/0x28d0
 [] ? m_show+0x1b0/0x1b0
 [] ? sched_clock+0x9/0x10
 [] ? local_clock+0x1c/0x20
 [] SyS_init_module+0x178/0x1c0
 [] entry_SYSCALL_64_fastpath+0x12/0x76
---[ end trace 0c0ff6cd25624338 ]---


Ref.
https://bugzilla.redhat.com/show_bug.cgi?id=1252336
https://bugzilla.kernel.org/show_bug.cgi?id=102661
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

WARNING: CPU: 3 PID: 827 at lib/dma-debug.c:1169 check_for_stack+0x94/0xe0()

[poma]

[ cut here ]
WARNING: CPU: 3 PID: 827 at lib/dma-debug.c:1169 check_for_stack+0x94/0xe0()
ehci-pci :00:02.1: DMA-API: device driver maps memory from stack 
[addr=8800bc6dfa3c]
Modules linked in: ... mt7601u(+) mac80211 ... cfg80211 rfkill ...
CPU: 3 PID: 827 Comm: systemd-udevd Not tainted 
4.2.0-0.rc6.git0.1.fc24.x86_64+debug #1
...
Call Trace:
 [81868d8e] dump_stack+0x4c/0x65
 [810ab406] warn_slowpath_common+0x86/0xc0
 [810ab495] warn_slowpath_fmt+0x55/0x70
 [81871e26] ? _raw_spin_unlock_irqrestore+0x36/0x60
 [81450044] check_for_stack+0x94/0xe0
 [8145062b] debug_dma_map_page+0xfb/0x140
 [81614eb8] usb_hcd_map_urb_for_dma+0x608/0x760
 [8161548d] usb_hcd_submit_urb+0x1cd/0xab0
 [8110315f] ? save_trace+0x3f/0xc0
 [81106edd] ? mark_held_locks+0x7d/0xb0
 [8110ddd5] ? __raw_spin_lock_init+0x25/0x60
 [81103b73] ? lockdep_init_map+0x73/0x640
 [81107039] ? trace_hardirqs_on_caller+0x129/0x1b0
 [8161707c] usb_submit_urb+0x3fc/0x5a0
 [81617947] usb_start_wait_urb+0x77/0x180
 [8124a83e] ? __kmalloc+0x28e/0x360
 [81617b2c] usb_control_msg+0xdc/0x130
 [a0850510] mt7601u_vendor_request+0xf0/0x310 [mt7601u]
 [8186f4dc] ? __mutex_unlock_slowpath+0xbc/0x180
 [a08507b9] mt7601u_rr+0x59/0x280 [mt7601u]
 [8161b738] ? usb_autosuspend_device+0x28/0x30
 [a0857c93] mt7601u_wait_asic_ready+0x23/0x60 [mt7601u]
 [a0850ac0] mt7601u_probe+0xe0/0x220 [mt7601u]
 [8161c03b] usb_probe_interface+0x1bb/0x2e0
 [81579f26] driver_probe_device+0x1f6/0x450
 [8157a214] __driver_attach+0x94/0xa0
 [8157a180] ? driver_probe_device+0x450/0x450
 [815778f3] bus_for_each_dev+0x73/0xc0
 [815796fe] driver_attach+0x1e/0x20
 [8157922e] bus_add_driver+0x1ee/0x280
 [8157b0a0] driver_register+0x60/0xe0
 [8161a87d] usb_register_driver+0xad/0x160
 [a086e000] ? 0xa086e000
 [a086e01e] mt7601u_driver_init+0x1e/0x20 [mt7601u]
 [81002123] do_one_initcall+0xb3/0x200
 [8124ac65] ? kmem_cache_alloc_trace+0x355/0x380
 [81867c37] ? do_init_module+0x28/0x1e9
 [81867c6f] do_init_module+0x60/0x1e9
 [81154167] load_module+0x21f7/0x28d0
 [8114f600] ? m_show+0x1b0/0x1b0
 [81026d79] ? sched_clock+0x9/0x10
 [810e6ddc] ? local_clock+0x1c/0x20
 [811549b8] SyS_init_module+0x178/0x1c0
 [8187282e] entry_SYSCALL_64_fastpath+0x12/0x76
---[ end trace 0c0ff6cd25624338 ]---


Ref.
https://bugzilla.redhat.com/show_bug.cgi?id=1252336
https://bugzilla.kernel.org/show_bug.cgi?id=102661
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

WARNING: CPU: 1 PID: 813 at kernel/module.c:291 module_assert_mutex_or_preempt+0x49/0x90()

[poma]

[ cut here ]
WARNING: CPU: 1 PID: 813 at kernel/module.c:291 
module_assert_mutex_or_preempt+0x49/0x90()
Modules linked in: mxl5007t af9013 ... dvb_usb_af9015(+) ... dvb_usb_v2 
dvb_core rc_core ...
CPU: 1 PID: 813 Comm: systemd-udevd Not tainted 
4.2.0-0.rc6.git0.1.fc24.x86_64+debug #1
...
Call Trace:
 [] dump_stack+0x4c/0x65
 [] warn_slowpath_common+0x86/0xc0
 [] ? af9013_read_ucblocks+0x20/0x20 [af9013]
 [] ? af9013_read_ucblocks+0x20/0x20 [af9013]
 [] warn_slowpath_null+0x1a/0x20
 [] module_assert_mutex_or_preempt+0x49/0x90
 [] __module_address+0x32/0x150
 [] ? af9013_read_ucblocks+0x20/0x20 [af9013]
 [] ? af9013_read_ucblocks+0x20/0x20 [af9013]
 [] __module_text_address+0x16/0x70
 [] ? af9013_read_ucblocks+0x20/0x20 [af9013]
 [] ? af9013_read_ucblocks+0x20/0x20 [af9013]
 [] symbol_put_addr+0x29/0x40
 [] dvb_frontend_detach+0x7d/0x90 [dvb_core]
 [] dvb_usbv2_probe+0xc85/0x11a0 [dvb_usb_v2]
 [] af9015_probe+0x84/0xf0 [dvb_usb_af9015]
 [] usb_probe_interface+0x1bb/0x2e0
 [] driver_probe_device+0x1f6/0x450
 [] __driver_attach+0x94/0xa0
 [] ? driver_probe_device+0x450/0x450
 [] bus_for_each_dev+0x73/0xc0
 [] driver_attach+0x1e/0x20
 [] bus_add_driver+0x1ee/0x280
 [] driver_register+0x60/0xe0
 [] usb_register_driver+0xad/0x160
 [] ? 0xa0567000
 [] af9015_usb_driver_init+0x1e/0x1000 [dvb_usb_af9015]
 [] do_one_initcall+0xb3/0x200
 [] ? kmem_cache_alloc_trace+0x355/0x380
 [] ? do_init_module+0x28/0x1e9
 [] do_init_module+0x60/0x1e9
 [] load_module+0x21f7/0x28d0
 [] ? m_show+0x1b0/0x1b0
 [] ? sched_clock+0x9/0x10
 [] ? local_clock+0x1c/0x20
 [] SyS_init_module+0x178/0x1c0
 [] entry_SYSCALL_64_fastpath+0x12/0x76
---[ end trace 31a9dd90d4f559f5 ]---


Ref.
https://bugzilla.redhat.com/show_bug.cgi?id=1252167
https://bugzilla.kernel.org/show_bug.cgi?id=102631

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

WARNING: CPU: 1 PID: 813 at kernel/module.c:291 module_assert_mutex_or_preempt+0x49/0x90()

[poma]

[ cut here ]
WARNING: CPU: 1 PID: 813 at kernel/module.c:291 
module_assert_mutex_or_preempt+0x49/0x90()
Modules linked in: mxl5007t af9013 ... dvb_usb_af9015(+) ... dvb_usb_v2 
dvb_core rc_core ...
CPU: 1 PID: 813 Comm: systemd-udevd Not tainted 
4.2.0-0.rc6.git0.1.fc24.x86_64+debug #1
...
Call Trace:
 [81868d8e] dump_stack+0x4c/0x65
 [810ab406] warn_slowpath_common+0x86/0xc0
 [a057d0b0] ? af9013_read_ucblocks+0x20/0x20 [af9013]
 [a057d0b0] ? af9013_read_ucblocks+0x20/0x20 [af9013]
 [810ab53a] warn_slowpath_null+0x1a/0x20
 [81150529] module_assert_mutex_or_preempt+0x49/0x90
 [81150822] __module_address+0x32/0x150
 [a057d0b0] ? af9013_read_ucblocks+0x20/0x20 [af9013]
 [a057d0b0] ? af9013_read_ucblocks+0x20/0x20 [af9013]
 [81150956] __module_text_address+0x16/0x70
 [a057d0b0] ? af9013_read_ucblocks+0x20/0x20 [af9013]
 [a057d0b0] ? af9013_read_ucblocks+0x20/0x20 [af9013]
 [81150f19] symbol_put_addr+0x29/0x40
 [a04b77ad] dvb_frontend_detach+0x7d/0x90 [dvb_core]
 [a04cdfd5] dvb_usbv2_probe+0xc85/0x11a0 [dvb_usb_v2]
 [a05607c4] af9015_probe+0x84/0xf0 [dvb_usb_af9015]
 [8161c03b] usb_probe_interface+0x1bb/0x2e0
 [81579f26] driver_probe_device+0x1f6/0x450
 [8157a214] __driver_attach+0x94/0xa0
 [8157a180] ? driver_probe_device+0x450/0x450
 [815778f3] bus_for_each_dev+0x73/0xc0
 [815796fe] driver_attach+0x1e/0x20
 [8157922e] bus_add_driver+0x1ee/0x280
 [8157b0a0] driver_register+0x60/0xe0
 [8161a87d] usb_register_driver+0xad/0x160
 [a0567000] ? 0xa0567000
 [a056701e] af9015_usb_driver_init+0x1e/0x1000 [dvb_usb_af9015]
 [81002123] do_one_initcall+0xb3/0x200
 [8124ac65] ? kmem_cache_alloc_trace+0x355/0x380
 [81867c37] ? do_init_module+0x28/0x1e9
 [81867c6f] do_init_module+0x60/0x1e9
 [81154167] load_module+0x21f7/0x28d0
 [8114f600] ? m_show+0x1b0/0x1b0
 [81026d79] ? sched_clock+0x9/0x10
 [810e6ddc] ? local_clock+0x1c/0x20
 [811549b8] SyS_init_module+0x178/0x1c0
 [8187282e] entry_SYSCALL_64_fastpath+0x12/0x76
---[ end trace 31a9dd90d4f559f5 ]---


Ref.
https://bugzilla.redhat.com/show_bug.cgi?id=1252167
https://bugzilla.kernel.org/show_bug.cgi?id=102631

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

do not call blocking ops when !TASK_RUNNING

[poma]

[   19.381055] [ cut here ]
[   19.381225] WARNING: CPU: 3 PID: 487 at kernel/sched/core.c:7291 
__might_sleep+0x87/0x90()
[   19.381373] do not call blocking ops when !TASK_RUNNING; state=2 set at 
[] wait_for_completion_io+0xe5/0x140
...
[   19.387265] Call Trace:
[   19.387698]  [] dump_stack+0x4c/0x65
[   19.388145]  [] warn_slowpath_common+0x8a/0xc0
[   19.388564]  [] warn_slowpath_fmt+0x55/0x70
[   19.388995]  [] ? wait_for_completion_io+0xe5/0x140
[   19.389433]  [] ? wait_for_completion_io+0xe5/0x140
[   19.389840]  [] __might_sleep+0x87/0x90
[   19.390257]  [] generic_make_request_checks+0x3f/0x600
[   19.390666]  [] ? _raw_spin_unlock_irqrestore+0x36/0x70
[   19.391084]  [] ? trace_hardirqs_on_caller+0x13d/0x1e0
[   19.391505]  [] generic_make_request+0x27/0x130
[   19.391919]  [] raid1_unplug+0x108/0x160 [raid1]
[   19.392325]  [] blk_flush_plug_list+0x9a/0x260
[   19.392728]  [] ? _raw_spin_unlock_irq+0x30/0x50
[   19.393142]  [] io_schedule_timeout+0x120/0x130
[   19.393547]  [] ? trace_hardirqs_on+0xd/0x10
[   19.393955]  [] wait_for_completion_io+0x107/0x140
[   19.394358]  [] ? wake_up_state+0x20/0x20
[   19.394757]  [] __blkdev_issue_zeroout+0x227/0x270
[   19.395162]  [] ? wait_for_completion_io+0x4a/0x140
[   19.395562]  [] blkdev_issue_zeroout+0xaa/0x100
[   19.395966]  [] ext4_ext_zeroout.isra.34+0x52/0x60
[   19.396375]  [] 
ext4_ext_handle_unwritten_extents+0x680/0x10d0
[   19.396768]  [] ext4_ext_map_blocks+0x527/0x13c0
[   19.397180]  [] ? ext4_map_blocks+0x179/0x510
[   19.397577]  [] ? ext4_map_blocks+0x179/0x510
[   19.397976]  [] ext4_map_blocks+0x19d/0x510
[   19.398372]  [] ext4_writepages+0x7fd/0x13e0
[   19.398759]  [] ? update_entity_load_avg+0x381/0x430
[   19.399154]  [] do_writepages+0x21/0x40
[   19.399536]  [] __filemap_fdatawrite_range+0x65/0x90
[   19.399916]  [] filemap_write_and_wait_range+0x2d/0x70
[   19.400298]  [] ext4_sync_file+0x173/0x660
[   19.400669]  [] vfs_fsync_range+0x4b/0xb0
[   19.401035]  [] do_fsync+0x3d/0x70
[   19.401389]  [] SyS_fsync+0x10/0x20
[   19.401725]  [] system_call_fastpath+0x12/0x76
[   19.402060] ---[ end trace 21b3d7a340807572 ]---


4.1.0-0.rc2.git3.1.fc23.x86_64

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

do not call blocking ops when !TASK_RUNNING

[poma]

[   19.381055] [ cut here ]
[   19.381225] WARNING: CPU: 3 PID: 487 at kernel/sched/core.c:7291 
__might_sleep+0x87/0x90()
[   19.381373] do not call blocking ops when !TASK_RUNNING; state=2 set at 
[81897a65] wait_for_completion_io+0xe5/0x140
...
[   19.387265] Call Trace:
[   19.387698]  [81894055] dump_stack+0x4c/0x65
[   19.388145]  [810b043a] warn_slowpath_common+0x8a/0xc0
[   19.388564]  [810b04c5] warn_slowpath_fmt+0x55/0x70
[   19.388995]  [81897a65] ? wait_for_completion_io+0xe5/0x140
[   19.389433]  [81897a65] ? wait_for_completion_io+0xe5/0x140
[   19.389840]  [810e0c17] __might_sleep+0x87/0x90
[   19.390257]  [813fcc1f] generic_make_request_checks+0x3f/0x600
[   19.390666]  [8189d016] ? _raw_spin_unlock_irqrestore+0x36/0x70
[   19.391084]  [8110e0fd] ? trace_hardirqs_on_caller+0x13d/0x1e0
[   19.391505]  [813fd207] generic_make_request+0x27/0x130
[   19.391919]  [a438] raid1_unplug+0x108/0x160 [raid1]
[   19.392325]  [814030da] blk_flush_plug_list+0x9a/0x260
[   19.392728]  [8189cfc0] ? _raw_spin_unlock_irq+0x30/0x50
[   19.393142]  [81896410] io_schedule_timeout+0x120/0x130
[   19.393547]  [8110e1ad] ? trace_hardirqs_on+0xd/0x10
[   19.393955]  [81897a87] wait_for_completion_io+0x107/0x140
[   19.394358]  [810e9b40] ? wake_up_state+0x20/0x20
[   19.394757]  [8140adf7] __blkdev_issue_zeroout+0x227/0x270
[   19.395162]  [818979ca] ? wait_for_completion_io+0x4a/0x140
[   19.395562]  [8140aeea] blkdev_issue_zeroout+0xaa/0x100
[   19.395966]  [81350042] ext4_ext_zeroout.isra.34+0x52/0x60
[   19.396375]  [81355ff0] 
ext4_ext_handle_unwritten_extents+0x680/0x10d0
[   19.396768]  [81356f97] ext4_ext_map_blocks+0x527/0x13c0
[   19.397180]  [813234c9] ? ext4_map_blocks+0x179/0x510
[   19.397577]  [813234c9] ? ext4_map_blocks+0x179/0x510
[   19.397976]  [813234ed] ext4_map_blocks+0x19d/0x510
[   19.398372]  [81326fdd] ext4_writepages+0x7fd/0x13e0
[   19.398759]  [810f2821] ? update_entity_load_avg+0x381/0x430
[   19.399154]  [81200311] do_writepages+0x21/0x40
[   19.399536]  [811f1c15] __filemap_fdatawrite_range+0x65/0x90
[   19.399916]  [811f1d5d] filemap_write_and_wait_range+0x2d/0x70
[   19.400298]  [8131bff3] ext4_sync_file+0x173/0x660
[   19.400669]  [812bcd1b] vfs_fsync_range+0x4b/0xb0
[   19.401035]  [812bcddd] do_fsync+0x3d/0x70
[   19.401389]  [812bd0d0] SyS_fsync+0x10/0x20
[   19.401725]  [8189da6e] system_call_fastpath+0x12/0x76
[   19.402060] ---[ end trace 21b3d7a340807572 ]---


4.1.0-0.rc2.git3.1.fc23.x86_64

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How to increase maximum user cpu usage allowed on a multi core system?

[poma]

On 09.03.2015 20:03, stan wrote:
> I'm running Fedora 21 with a custom compiled kernel,
> 3.19.0-1.20150211.fc21.x86_64.
> 
> I have a multi core system with 6 cores.  All are recognized by the
> kernel.  
> 
> But, when I run a compile job with -j6, in order to allow all six cores
> to be used, it limits the total amount of usage to 100% of a *single*
> core.  So, it might use all six cores, but the sum of the percentages
> on those six cores is always around 100% of one core.  This is from
> htop output.
> 
> On large compilations, like the kernel or firefox, even using 4 cores
> could drastically reduce compile time.
> 
> I've looked at /etc/security/limits.conf, but it doesn't seem to have a
> setting for this.  I've also looked at the /proc system to see if there
> is a kernel variable, though that seems unlikely, with no luck.  Online
> searching found ways to limit the amount that a single job can get, but
> not how to set this for a user.  There must be a configuration variable
> somewhere that is limiting the amount of total cpu a user can use.  But
> I can't find it.
> 
> Can anyone help?
> 


Borislav, can you help explain the man why this is happening with his 
Piledriver.
http://www.cpu-world.com/CPUs/Bulldozer/AMD-FX-Series%20FX-6300.html


poma


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How to increase maximum user cpu usage allowed on a multi core system?

[poma]

On 09.03.2015 20:03, stan wrote:
 I'm running Fedora 21 with a custom compiled kernel,
 3.19.0-1.20150211.fc21.x86_64.
 
 I have a multi core system with 6 cores.  All are recognized by the
 kernel.  
 
 But, when I run a compile job with -j6, in order to allow all six cores
 to be used, it limits the total amount of usage to 100% of a *single*
 core.  So, it might use all six cores, but the sum of the percentages
 on those six cores is always around 100% of one core.  This is from
 htop output.
 
 On large compilations, like the kernel or firefox, even using 4 cores
 could drastically reduce compile time.
 
 I've looked at /etc/security/limits.conf, but it doesn't seem to have a
 setting for this.  I've also looked at the /proc system to see if there
 is a kernel variable, though that seems unlikely, with no luck.  Online
 searching found ways to limit the amount that a single job can get, but
 not how to set this for a user.  There must be a configuration variable
 somewhere that is limiting the amount of total cpu a user can use.  But
 I can't find it.
 
 Can anyone help?
 


Borislav, can you help explain the man why this is happening with his 
Piledriver.
http://www.cpu-world.com/CPUs/Bulldozer/AMD-FX-Series%20FX-6300.html


poma


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Uhhuh - Dazed and confused, but trying to continue :)

[poma]

On 21.01.2015 15:24, Don Zickus wrote:
> On Wed, Jan 21, 2015 at 10:01:32AM +0100, poma wrote:
>> On 19.01.2015 14:49, Don Zickus wrote:
>>
>> Thank you, in the meantime, I've found what causes non-maskable interrupt, 
>> [23]d on CPU 0, on resuming S4,
>> on AMD Phenom(tm) II X4 955 Processor.
>>
>> /etc/default/tlp
>> ...
>> # Kernel NMI Watchdog
>> # 0=disable (default, saves power) / 1=enable (for kernel debugging only)
>> NMI_WATCHDOG=0
>>
>> Toggling to 1, messages no longer appear,
>> NMI_WATCHDOG=1
>>
>> $ cat /proc/sys/kernel/nmi_watchdog
>> 1
>> $ sysctl kernel.watchdog
>> kernel.watchdog = 1
>>
>> Isn't it brilliant.
> 
> 
> Hehe.  Ok.  All that does is swallow your unknown NMI.  But if that makes
> you happy, I am fine with that. :-)
> 
> Cheers,
> Don
> 

I don't want to bother you for nothing, as long as nothing crashes, it can pass.
Thanks again.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Uhhuh - Dazed and confused, but trying to continue :)

[poma]

On 19.01.2015 14:49, Don Zickus wrote:
> On Sun, Jan 18, 2015 at 11:50:38AM +0100, poma wrote:
>>
>> Salutem
>>
>> This happened only on thaw from S4 aka hibernate.
>> What should be "strange power saving mode" these messages relate!?
>>
>> [  208.252986] Uhhuh. NMI received for unknown reason 3d on CPU 0.
>> [  208.252991] Do you have a strange power saving mode enabled?
>> [  208.252992] Dazed and confused, but trying to continue
>>
>> 3.18.3-200.fc21.x86_64
> 
> This looks to be an external unknown NMI (unless you can reproduce on
> something other than cpu0).
> 
> I would have to know what hardware you have and see the dmesg log after
> the resume from hibernate.
> 
> You can open a bz and assign it to me.
> 
> Just attach the dmesg log, lspci and lspci -t output to the bz.
> 
> Though this is most likely a pci device firmware problem.  But I can try
> to narrow it down.
> 
> Cheers,
> Don
> 

Thank you, in the meantime, I've found what causes non-maskable interrupt, 
[23]d on CPU 0, on resuming S4,
on AMD Phenom(tm) II X4 955 Processor.

/etc/default/tlp
...
# Kernel NMI Watchdog
# 0=disable (default, saves power) / 1=enable (for kernel debugging only)
NMI_WATCHDOG=0

Toggling to 1, messages no longer appear,
NMI_WATCHDOG=1

$ cat /proc/sys/kernel/nmi_watchdog
1
$ sysctl kernel.watchdog
kernel.watchdog = 1

Isn't it brilliant.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Uhhuh - Dazed and confused, but trying to continue :)

[poma]

On 19.01.2015 14:49, Don Zickus wrote:
 On Sun, Jan 18, 2015 at 11:50:38AM +0100, poma wrote:

 Salutem

 This happened only on thaw from S4 aka hibernate.
 What should be strange power saving mode these messages relate!?

 [  208.252986] Uhhuh. NMI received for unknown reason 3d on CPU 0.
 [  208.252991] Do you have a strange power saving mode enabled?
 [  208.252992] Dazed and confused, but trying to continue

 3.18.3-200.fc21.x86_64
 
 This looks to be an external unknown NMI (unless you can reproduce on
 something other than cpu0).
 
 I would have to know what hardware you have and see the dmesg log after
 the resume from hibernate.
 
 You can open a bz and assign it to me.
 
 Just attach the dmesg log, lspci and lspci -t output to the bz.
 
 Though this is most likely a pci device firmware problem.  But I can try
 to narrow it down.
 
 Cheers,
 Don
 

Thank you, in the meantime, I've found what causes non-maskable interrupt, 
[23]d on CPU 0, on resuming S4,
on AMD Phenom(tm) II X4 955 Processor.

/etc/default/tlp
...
# Kernel NMI Watchdog
# 0=disable (default, saves power) / 1=enable (for kernel debugging only)
NMI_WATCHDOG=0

Toggling to 1, messages no longer appear,
NMI_WATCHDOG=1

$ cat /proc/sys/kernel/nmi_watchdog
1
$ sysctl kernel.watchdog
kernel.watchdog = 1

Isn't it brilliant.


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Uhhuh - Dazed and confused, but trying to continue :)

[poma]

On 21.01.2015 15:24, Don Zickus wrote:
 On Wed, Jan 21, 2015 at 10:01:32AM +0100, poma wrote:
 On 19.01.2015 14:49, Don Zickus wrote:

 Thank you, in the meantime, I've found what causes non-maskable interrupt, 
 [23]d on CPU 0, on resuming S4,
 on AMD Phenom(tm) II X4 955 Processor.

 /etc/default/tlp
 ...
 # Kernel NMI Watchdog
 # 0=disable (default, saves power) / 1=enable (for kernel debugging only)
 NMI_WATCHDOG=0

 Toggling to 1, messages no longer appear,
 NMI_WATCHDOG=1

 $ cat /proc/sys/kernel/nmi_watchdog
 1
 $ sysctl kernel.watchdog
 kernel.watchdog = 1

 Isn't it brilliant.
 
 
 Hehe.  Ok.  All that does is swallow your unknown NMI.  But if that makes
 you happy, I am fine with that. :-)
 
 Cheers,
 Don
 

I don't want to bother you for nothing, as long as nothing crashes, it can pass.
Thanks again.


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Uhhuh - Dazed and confused, but trying to continue :)

[poma]

Salutem

This happened only on thaw from S4 aka hibernate.
What should be "strange power saving mode" these messages relate!?

[  208.252986] Uhhuh. NMI received for unknown reason 3d on CPU 0.
[  208.252991] Do you have a strange power saving mode enabled?
[  208.252992] Dazed and confused, but trying to continue

3.18.3-200.fc21.x86_64


poma

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Uhhuh - Dazed and confused, but trying to continue :)

[poma]

Salutem

This happened only on thaw from S4 aka hibernate.
What should be strange power saving mode these messages relate!?

[  208.252986] Uhhuh. NMI received for unknown reason 3d on CPU 0.
[  208.252991] Do you have a strange power saving mode enabled?
[  208.252992] Dazed and confused, but trying to continue

3.18.3-200.fc21.x86_64


poma

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

INFO: task echo:622 blocked for more than 120 seconds. - 3.18.0-0.rc0.git

[poma]

02:00.0 VGA compatible controller: 
NVIDIA Corporation G98 [GeForce 8400 GS Rev. 2] (rev a1)
Chipset: G98 (NV98)
Family : NV50

The same for all four kernel:
- 3.18.0-0.rc0.git8.1.fc22.x86_64
- 3.18.0-0.rc0.git9.1.fc22.x86_64
- 3.18.0-0.rc0.git9.3.fc22.x86_64
- 3.18.0-0.rc0.git9.4.fc22.x86_64
after
"fb: switching to nouveaufb from VESA VGA"
display is powered off.
The magic SysRq key sequence is necessary to reboot.

Yet reached this this one recital:
...
[5.860996] [drm] Initialized nouveau 1.2.1 20120801 for :02:00.0 on 
minor 0
...
[  240.229058] INFO: task echo:622 blocked for more than 120 seconds.
[  240.229594]   Not tainted 3.18.0-0.rc0.git9.3.fc22.x86_64 #1
[  240.230149] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  240.230661] echoD 8800c82a3480 12472   622  1 0x0004
[  240.231230]  8800ca2e3ac8 0096 8800c82a3480 
001d5f00
[  240.231784]  8800ca2e3fd8 001d5f00 880128bf 
8800c82a3480
[  240.232344]  82c30990 7fff 81ee2698 
81ee2690
[  240.232931] Call Trace:
[  240.233467]  [] schedule+0x29/0x70
[  240.234025]  [] schedule_timeout+0x26c/0x410
[  240.234562]  [] ? native_sched_clock+0x2a/0xa0
[  240.235118]  [] ? mark_held_locks+0x7c/0xb0
[  240.235645]  [] ? _raw_spin_unlock_irq+0x30/0x50
[  240.236198]  [] ? trace_hardirqs_on_caller+0x15d/0x200
[  240.236729]  [] wait_for_completion+0x10c/0x150
[  240.237290]  [] ? wake_up_state+0x20/0x20
[  240.237842]  [] _rcu_barrier+0x159/0x200
[  240.238375]  [] rcu_barrier+0x15/0x20
[  240.238913]  [] netdev_run_todo+0x6f/0x310
[  240.239449]  [] rtnl_unlock+0xe/0x10
[  240.23]  [] unregister_netdev+0x25/0x30
[  240.240546]  [] rtl_remove_one+0x62/0x230 [r8169]
[  240.241104]  [] pci_device_remove+0x3f/0xc0
[  240.241642]  [] __device_release_driver+0x7f/0xf0
[  240.242180]  [] device_release_driver+0x25/0x40
[  240.242712]  [] pci_stop_bus_device+0x9c/0xb0
[  240.243259]  [] 
pci_stop_and_remove_bus_device_locked+0x1e/0x40
[  240.243785]  [] remove_store+0x7c/0x90
[  240.244321]  [] dev_attr_store+0x18/0x30
[  240.244858]  [] sysfs_kf_write+0x49/0x60
[  240.245375]  [] kernfs_fop_write+0xf9/0x180
[  240.245921]  [] vfs_write+0xba/0x200
[  240.246439]  [] ? retint_swapgs+0x13/0x1b
[  240.246978]  [] SyS_write+0x5c/0xd0
[  240.247491]  [] system_call_fastpath+0x12/0x17
[  240.248025] 6 locks held by echo/622:
[  240.248532]  #0:  (sb_writers#3){.+.+.+}, at: [] 
vfs_write+0x1a3/0x200
[  240.249104]  #1:  (>mutex){+.+.+.}, at: [] 
kernfs_fop_write+0xc7/0x180
[  240.249651]  #2:  (s_active#131){++}, at: [] 
kernfs_remove_self+0xf4/0x170
[  240.250229]  #3:  (pci_rescan_remove_lock){+.+.+.}, at: [] 
pci_lock_rescan_remove+0x17/0x20
[  240.250779]  #4:  (>mutex){..}, at: [] 
device_release_driver+0x1d/0x40
[  240.251358]  #5:  (rcu_sched_state.barrier_mutex){+.+...}, at: 
[] _rcu_barrier+0x35/0x200
[  241.303095] systemd[1]: start request repeated too quickly for 
lightdm.service
[  241.323052] systemd[1]: Unit lightdm.service entered failed state.
[  241.333101] systemd[1]: lightdm.service failed.
[  359.038325] INFO: task kworker/u16:2:81 blocked for more than 120 seconds.
[  359.039475]   Not tainted 3.18.0-0.rc0.git9.3.fc22.x86_64 #1
[  359.040004] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  359.040571] kworker/u16:2   D 880128131a40 1089681  2 0x
[  359.041162] Workqueue: netns cleanup_net
[  359.041701]  8801275bba88 0096 880128131a40 
001d5f00
[  359.042280]  8801275bbfd8 001d5f00 880128bf3480 
880128131a40
[  359.042856]  880128131a40 81ee25e8 0246 
880128131a40
[  359.043436] Call Trace:
[  359.043975]  [] schedule_preempt_disabled+0x31/0x80
[  359.044542]  [] mutex_lock_nested+0x183/0x440
[  359.045108]  [] ? _rcu_barrier+0x35/0x200
[  359.045647]  [] ? native_sched_clock+0x2a/0xa0
[  359.046218]  [] ? _rcu_barrier+0x35/0x200
[  359.046767]  [] ? __mutex_unlock_slowpath+0xc4/0x1c0
[  359.047333]  [] _rcu_barrier+0x35/0x200
[  359.047875]  [] rcu_barrier+0x15/0x20
[  359.048433]  [] netdev_run_todo+0x6f/0x310
[  359.048969]  [] ? rollback_registered_many+0x265/0x2e0
[  359.049528]  [] rtnl_unlock+0xe/0x10
[  359.050062]  [] default_device_exit_batch+0x156/0x180
[  359.050624]  [] ? abort_exclusive_wait+0xb0/0xb0
[  359.051185]  [] ops_exit_list.isra.1+0x53/0x60
[  359.051720]  [] cleanup_net+0x100/0x1f0
[  359.052271]  [] process_one_work+0x218/0x850
[  359.052806]  [] ? process_one_work+0x17f/0x850
[  359.053356]  [] ? worker_thread+0xe7/0x4a0
[  359.053891]  [] worker_thread+0x6b/0x4a0
[  359.05]  [] ? process_one_work+0x850/0x850
[  359.054977]  [] kthread+0x10b/0x130
[  359.055521]  [] ? sched_clock+0x9/0x10
[  359.056054]  [] ? kthread_create_on_node+0x250/0x250
[  359.056600]  [] ret_from_fork+0x7c/0xb0
[  359.057145]  [] ? 

INFO: task echo:622 blocked for more than 120 seconds. - 3.18.0-0.rc0.git

[poma]

02:00.0 VGA compatible controller: 
NVIDIA Corporation G98 [GeForce 8400 GS Rev. 2] (rev a1)
Chipset: G98 (NV98)
Family : NV50

The same for all four kernel:
- 3.18.0-0.rc0.git8.1.fc22.x86_64
- 3.18.0-0.rc0.git9.1.fc22.x86_64
- 3.18.0-0.rc0.git9.3.fc22.x86_64
- 3.18.0-0.rc0.git9.4.fc22.x86_64
after
fb: switching to nouveaufb from VESA VGA
display is powered off.
The magic SysRq key sequence is necessary to reboot.

Yet reached this this one recital:
...
[5.860996] [drm] Initialized nouveau 1.2.1 20120801 for :02:00.0 on 
minor 0
...
[  240.229058] INFO: task echo:622 blocked for more than 120 seconds.
[  240.229594]   Not tainted 3.18.0-0.rc0.git9.3.fc22.x86_64 #1
[  240.230149] echo 0  /proc/sys/kernel/hung_task_timeout_secs disables this 
message.
[  240.230661] echoD 8800c82a3480 12472   622  1 0x0004
[  240.231230]  8800ca2e3ac8 0096 8800c82a3480 
001d5f00
[  240.231784]  8800ca2e3fd8 001d5f00 880128bf 
8800c82a3480
[  240.232344]  82c30990 7fff 81ee2698 
81ee2690
[  240.232931] Call Trace:
[  240.233467]  [8185baf9] schedule+0x29/0x70
[  240.234025]  [81860d1c] schedule_timeout+0x26c/0x410
[  240.234562]  [81028c4a] ? native_sched_clock+0x2a/0xa0
[  240.235118]  [811078bc] ? mark_held_locks+0x7c/0xb0
[  240.235645]  [81861da0] ? _raw_spin_unlock_irq+0x30/0x50
[  240.236198]  [81107a4d] ? trace_hardirqs_on_caller+0x15d/0x200
[  240.236729]  [8185d52c] wait_for_completion+0x10c/0x150
[  240.237290]  [810e51f0] ? wake_up_state+0x20/0x20
[  240.237842]  [8112a559] _rcu_barrier+0x159/0x200
[  240.238375]  [8112a655] rcu_barrier+0x15/0x20
[  240.238913]  [8171813f] netdev_run_todo+0x6f/0x310
[  240.239449]  [817251ae] rtnl_unlock+0xe/0x10
[  240.23]  [8170ea35] unregister_netdev+0x25/0x30
[  240.240546]  [a00222d2] rtl_remove_one+0x62/0x230 [r8169]
[  240.241104]  [814682cf] pci_device_remove+0x3f/0xc0
[  240.241642]  [8155b34f] __device_release_driver+0x7f/0xf0
[  240.242180]  [8155b3e5] device_release_driver+0x25/0x40
[  240.242712]  [8146234c] pci_stop_bus_device+0x9c/0xb0
[  240.243259]  [8146248e] 
pci_stop_and_remove_bus_device_locked+0x1e/0x40
[  240.243785]  [8146b44c] remove_store+0x7c/0x90
[  240.244321]  [81555f98] dev_attr_store+0x18/0x30
[  240.244858]  [81302789] sysfs_kf_write+0x49/0x60
[  240.245375]  [81301ac9] kernfs_fop_write+0xf9/0x180
[  240.245921]  [8127305a] vfs_write+0xba/0x200
[  240.246439]  [8186379c] ? retint_swapgs+0x13/0x1b
[  240.246978]  [81273bac] SyS_write+0x5c/0xd0
[  240.247491]  [81862b69] system_call_fastpath+0x12/0x17
[  240.248025] 6 locks held by echo/622:
[  240.248532]  #0:  (sb_writers#3){.+.+.+}, at: [81273143] 
vfs_write+0x1a3/0x200
[  240.249104]  #1:  (of-mutex){+.+.+.}, at: [81301a97] 
kernfs_fop_write+0xc7/0x180
[  240.249651]  #2:  (s_active#131){++}, at: [81300ce4] 
kernfs_remove_self+0xf4/0x170
[  240.250229]  #3:  (pci_rescan_remove_lock){+.+.+.}, at: [8145f167] 
pci_lock_rescan_remove+0x17/0x20
[  240.250779]  #4:  (dev-mutex){..}, at: [8155b3dd] 
device_release_driver+0x1d/0x40
[  240.251358]  #5:  (rcu_sched_state.barrier_mutex){+.+...}, at: 
[8112a435] _rcu_barrier+0x35/0x200
[  241.303095] systemd[1]: start request repeated too quickly for 
lightdm.service
[  241.323052] systemd[1]: Unit lightdm.service entered failed state.
[  241.333101] systemd[1]: lightdm.service failed.
[  359.038325] INFO: task kworker/u16:2:81 blocked for more than 120 seconds.
[  359.039475]   Not tainted 3.18.0-0.rc0.git9.3.fc22.x86_64 #1
[  359.040004] echo 0  /proc/sys/kernel/hung_task_timeout_secs disables this 
message.
[  359.040571] kworker/u16:2   D 880128131a40 1089681  2 0x
[  359.041162] Workqueue: netns cleanup_net
[  359.041701]  8801275bba88 0096 880128131a40 
001d5f00
[  359.042280]  8801275bbfd8 001d5f00 880128bf3480 
880128131a40
[  359.042856]  880128131a40 81ee25e8 0246 
880128131a40
[  359.043436] Call Trace:
[  359.043975]  [8185c0a1] schedule_preempt_disabled+0x31/0x80
[  359.044542]  [8185d8f3] mutex_lock_nested+0x183/0x440
[  359.045108]  [8112a435] ? _rcu_barrier+0x35/0x200
[  359.045647]  [81028c4a] ? native_sched_clock+0x2a/0xa0
[  359.046218]  [8112a435] ? _rcu_barrier+0x35/0x200
[  359.046767]  [8185f914] ? __mutex_unlock_slowpath+0xc4/0x1c0
[  359.047333]  [8112a435] _rcu_barrier+0x35/0x200
[  359.047875]  [8112a655] rcu_barrier+0x15/0x20
[  359.048433]  [8171813f] netdev_run_todo+0x6f/0x310
[  359.048969]  [8170cd35] ? rollback_registered_many+0x265/0x2e0
[  359.049528]  

Re: debug_dma_assert_idle - ohci - cpu touching an active dma mapped cacheline

[poma]

[ cut here ]
WARNING: CPU: 2 PID: 1065 at lib/dma-debug.c:593 
debug_dma_assert_idle+0x159/0x1d0()
ohci-pci :00:04.0: DMA-API: cpu touching an active dma mapped cacheline 
[cln=0x03004180]
CPU: 2 PID: 1065 Comm: tumblerd Not tainted 3.17.0-0.rc5.git1.1.fc22.i686 #1
Call Trace:
 [] dump_stack+0x48/0x60
 [] warn_slowpath_common+0x82/0xa0
 [] ? debug_dma_assert_idle+0x159/0x1d0
 [] ? debug_dma_assert_idle+0x159/0x1d0
 [] warn_slowpath_fmt+0x3e/0x60
 [] debug_dma_assert_idle+0x159/0x1d0
 [] ? anon_vma_prepare+0x29/0x140
 [] do_wp_page+0xe4/0x8c0
 [] handle_mm_fault+0x662/0xba0
 [] __do_page_fault+0x208/0x5d0
 [] ? vm_mmap_pgoff+0x9b/0xc0
 [] ? SyS_mmap_pgoff+0xe8/0x220
 [] ? trace_hardirqs_on_caller+0x13c/0x1e0
 [] ? __do_page_fault+0x5d0/0x5d0
 [] do_page_fault+0x1a/0x20
 [] error_code+0x6c/0x74
---[ end trace ce8b30fb8a3415c9 ]---
Mapped at:
 [] debug_dma_alloc_coherent+0x22/0x70
 [] ohci_init+0x22c/0x450
 [] ohci_setup+0x59/0x60
 [] ohci_pci_reset+0x4f/0x60
 [] usb_add_hcd+0x29a/0x8c0

$ lsusb -s 004:
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub


poma


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: debug_dma_assert_idle - ohci - cpu touching an active dma mapped cacheline

[poma]

[ cut here ]
WARNING: CPU: 2 PID: 1065 at lib/dma-debug.c:593 
debug_dma_assert_idle+0x159/0x1d0()
ohci-pci :00:04.0: DMA-API: cpu touching an active dma mapped cacheline 
[cln=0x03004180]
CPU: 2 PID: 1065 Comm: tumblerd Not tainted 3.17.0-0.rc5.git1.1.fc22.i686 #1
Call Trace:
 [c0b1bdb6] dump_stack+0x48/0x60
 [c04591e2] warn_slowpath_common+0x82/0xa0
 [c076dad9] ? debug_dma_assert_idle+0x159/0x1d0
 [c076dad9] ? debug_dma_assert_idle+0x159/0x1d0
 [c045923e] warn_slowpath_fmt+0x3e/0x60
 [c076dad9] debug_dma_assert_idle+0x159/0x1d0
 [c059a909] ? anon_vma_prepare+0x29/0x140
 [c058f594] do_wp_page+0xe4/0x8c0
 [c0591792] handle_mm_fault+0x662/0xba0
 [c0447398] __do_page_fault+0x208/0x5d0
 [c058053b] ? vm_mmap_pgoff+0x9b/0xc0
 [c0595178] ? SyS_mmap_pgoff+0xe8/0x220
 [c04a8e1c] ? trace_hardirqs_on_caller+0x13c/0x1e0
 [c0447760] ? __do_page_fault+0x5d0/0x5d0
 [c044777a] do_page_fault+0x1a/0x20
 [c0b258b4] error_code+0x6c/0x74
---[ end trace ce8b30fb8a3415c9 ]---
Mapped at:
 [c076bb82] debug_dma_alloc_coherent+0x22/0x70
 [c09050dc] ohci_init+0x22c/0x450
 [c0905359] ohci_setup+0x59/0x60
 [c09064cf] ohci_pci_reset+0x4f/0x60
 [c08dd8aa] usb_add_hcd+0x29a/0x8c0

$ lsusb -s 004:
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub


poma


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: VGA resume & thaw (wake up from S3 & S4) broken - kernel exclusively

[poma]

On 13.09.2014 06:57, poma wrote:
> 
> Actually I have nothing to show cause logs are all OK.
> Haha, it seems to me that the bugs become intelligent.
> 
> 3.15.10-201.fc20.x86_64
> 3.16.2-200.fc20.x86_64
> 3.17.0-0.rc4.git3.2.fc22.1.x86_64
>  nouveau  [ DRM] suspending display...
>  nouveau  [ DRM] unpinning framebuffer(s)...
>  nouveau  [ DRM] evicting buffers...
>  nouveau  [ DRM] waiting for kernel channels to go idle...
>  nouveau  [ DRM] suspending client object trees...
>  nouveau  [ DRM] suspending kernel object tree...
> ...
>  nouveau  [ DRM] re-enabling device...
>  nouveau  [ DRM] resuming kernel object tree...
>  nouveau  [   VBIOS][:02:00.0] running init tables
>  nouveau  [  PTHERM][:02:00.0] fan management: automatic
>  nouveau  [ CLK][:02:00.0] --: core 566 MHz shader 1400 MHz memory 
> 399 MHz
>  nouveau  [ DRM] resuming client object trees...
>  nouveau  [ DRM] resuming display...
>  nouveau :02:00.0: no hotplug settings from platform
>  nouveau :02:00.0: no hotplug settings from platform
> 
> Logs(dmesg) are literally identical.
> 
> 3.15.10-201.fc20.x86_64 - nouveau(fb) resume & thaw PASSED, and that's all 
> what works.
> Kernels >= 3.16 - nouveau(fb) resume & thaw BROKEN
> ALL Kernels - vesa(fb)resume & thaw BROKEN.
> 
> 

Excusez-moi, 
BROKEN == The display remains OFF.


poma


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

VGA resume & thaw (wake up from S3 & S4) broken - kernel exclusively

[poma]

Actually I have nothing to show cause logs are all OK.
Haha, it seems to me that the bugs become intelligent.

3.15.10-201.fc20.x86_64
3.16.2-200.fc20.x86_64
3.17.0-0.rc4.git3.2.fc22.1.x86_64
 nouveau  [ DRM] suspending display...
 nouveau  [ DRM] unpinning framebuffer(s)...
 nouveau  [ DRM] evicting buffers...
 nouveau  [ DRM] waiting for kernel channels to go idle...
 nouveau  [ DRM] suspending client object trees...
 nouveau  [ DRM] suspending kernel object tree...
...
 nouveau  [ DRM] re-enabling device...
 nouveau  [ DRM] resuming kernel object tree...
 nouveau  [   VBIOS][:02:00.0] running init tables
 nouveau  [  PTHERM][:02:00.0] fan management: automatic
 nouveau  [ CLK][:02:00.0] --: core 566 MHz shader 1400 MHz memory 399 
MHz
 nouveau  [ DRM] resuming client object trees...
 nouveau  [ DRM] resuming display...
 nouveau :02:00.0: no hotplug settings from platform
 nouveau :02:00.0: no hotplug settings from platform

Logs(dmesg) are literally identical.

3.15.10-201.fc20.x86_64 - nouveau(fb) resume & thaw PASSED, and that's all what 
works.
Kernels >= 3.16 - nouveau(fb) resume & thaw BROKEN
ALL Kernels - vesa(fb)resume & thaw BROKEN.


Have a nice weekend folks.


poma

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

VGA resume thaw (wake up from S3 S4) broken - kernel exclusively

[poma]

Actually I have nothing to show cause logs are all OK.
Haha, it seems to me that the bugs become intelligent.

3.15.10-201.fc20.x86_64
3.16.2-200.fc20.x86_64
3.17.0-0.rc4.git3.2.fc22.1.x86_64
 nouveau  [ DRM] suspending display...
 nouveau  [ DRM] unpinning framebuffer(s)...
 nouveau  [ DRM] evicting buffers...
 nouveau  [ DRM] waiting for kernel channels to go idle...
 nouveau  [ DRM] suspending client object trees...
 nouveau  [ DRM] suspending kernel object tree...
...
 nouveau  [ DRM] re-enabling device...
 nouveau  [ DRM] resuming kernel object tree...
 nouveau  [   VBIOS][:02:00.0] running init tables
 nouveau  [  PTHERM][:02:00.0] fan management: automatic
 nouveau  [ CLK][:02:00.0] --: core 566 MHz shader 1400 MHz memory 399 
MHz
 nouveau  [ DRM] resuming client object trees...
 nouveau  [ DRM] resuming display...
 nouveau :02:00.0: no hotplug settings from platform
 nouveau :02:00.0: no hotplug settings from platform

Logs(dmesg) are literally identical.

3.15.10-201.fc20.x86_64 - nouveau(fb) resume  thaw PASSED, and that's all what 
works.
Kernels = 3.16 - nouveau(fb) resume  thaw BROKEN
ALL Kernels - vesa(fb)resume  thaw BROKEN.


Have a nice weekend folks.


poma

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: VGA resume thaw (wake up from S3 S4) broken - kernel exclusively

[poma]

On 13.09.2014 06:57, poma wrote:
 
 Actually I have nothing to show cause logs are all OK.
 Haha, it seems to me that the bugs become intelligent.
 
 3.15.10-201.fc20.x86_64
 3.16.2-200.fc20.x86_64
 3.17.0-0.rc4.git3.2.fc22.1.x86_64
  nouveau  [ DRM] suspending display...
  nouveau  [ DRM] unpinning framebuffer(s)...
  nouveau  [ DRM] evicting buffers...
  nouveau  [ DRM] waiting for kernel channels to go idle...
  nouveau  [ DRM] suspending client object trees...
  nouveau  [ DRM] suspending kernel object tree...
 ...
  nouveau  [ DRM] re-enabling device...
  nouveau  [ DRM] resuming kernel object tree...
  nouveau  [   VBIOS][:02:00.0] running init tables
  nouveau  [  PTHERM][:02:00.0] fan management: automatic
  nouveau  [ CLK][:02:00.0] --: core 566 MHz shader 1400 MHz memory 
 399 MHz
  nouveau  [ DRM] resuming client object trees...
  nouveau  [ DRM] resuming display...
  nouveau :02:00.0: no hotplug settings from platform
  nouveau :02:00.0: no hotplug settings from platform
 
 Logs(dmesg) are literally identical.
 
 3.15.10-201.fc20.x86_64 - nouveau(fb) resume  thaw PASSED, and that's all 
 what works.
 Kernels = 3.16 - nouveau(fb) resume  thaw BROKEN
 ALL Kernels - vesa(fb)resume  thaw BROKEN.
 
 

Excusez-moi, 
BROKEN == The display remains OFF.


poma


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: debug_dma_assert_idle - ahci - cpu touching an active dma mapped cacheline

[poma]

On 11.05.2014 12:02, poma wrote:
> 
> [ cut here ]
> WARNING: CPU: 2 PID: 628 at lib/dma-debug.c:593 
> debug_dma_assert_idle+0x159/0x1d0()
> snd_hda_intel :00:07.0: DMA-API: cpu touching an active dma mapped 
> cacheline [cln=0x03074000]
> CPU: 2 PID: 628 Comm: lightdm Not tainted 3.15.0-0.rc5.git0.1.fc21.i686+debug 
> #1
> Call Trace:
>  [] dump_stack+0x48/0x60
>  [] warn_slowpath_common+0x82/0xa0
>  [] ? debug_dma_assert_idle+0x159/0x1d0
>  [] ? debug_dma_assert_idle+0x159/0x1d0
>  [] warn_slowpath_fmt+0x3e/0x60
>  [] debug_dma_assert_idle+0x159/0x1d0
>  [] ? anon_vma_prepare+0x29/0x140
>  [] do_wp_page+0xce/0x890
>  [] handle_mm_fault+0x662/0xb70
>  [] __do_page_fault+0x1a7/0x5d0
>  [] ? SyS_futex+0x97/0x180
>  [] ? trace_hardirqs_on_caller+0x1c0/0x1e0
>  [] ? trace_hardirqs_on_caller+0x13c/0x1e0
>  [] ? __do_page_fault+0x5d0/0x5d0
>  [] do_page_fault+0x1a/0x20
>  [] error_code+0x6c/0x74
> ---[ end trace b400a64c04aed387 ]---
> Mapped at:
>  [] debug_dma_alloc_coherent+0x22/0x70
>  [] snd_dma_alloc_pages+0x170/0x260 [snd_pcm]
>  [] snd_dma_alloc_pages_fallback+0x62/0x90 [snd_pcm]
>  [] snd_malloc_sgbuf_pages+0xf0/0x211 [snd_pcm]
>  [] snd_dma_alloc_pages+0x203/0x260 [snd_pcm]
> 

[ cut here ]
WARNING: CPU: 1 PID: 1180 at lib/dma-debug.c:593 
debug_dma_assert_idle+0x159/0x1d0()
ahci :00:09.0: DMA-API: cpu touching an active dma mapped cacheline 
[cln=0x03001000]
Modules linked in: ip6t_rpfilter ip6t_REJECT xt_conntrack cfg80211 rfkill 
ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat 
nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security 
ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security 
iptable_raw mt7601Usta(OE) nouveau kvm_amd ata_generic kvm uas pata_acpi ppdev 
mxm_wmi parport_serial video usb_storage k10temp r8169 i2c_algo_bit ttm 
drm_kms_helper serio_raw microcode parport_pc skge parport mii drm wmi 
i2c_nforce2 i2ccore pata_amd acpi_cpufreq sunrpc
CPU: 1 PID: 1180 Comm: gmain Tainted: G   OE  
3.17.0-0.rc2.git3.1.fc22.i686 #1
...
Call Trace:
 [] dump_stack+0x48/0x60
 [] warn_slowpath_common+0x82/0xa0
 [] ? debug_dma_assert_idle+0x159/0x1d0
 [] ? debug_dma_assert_idle+0x159/0x1d0
 [] warn_slowpath_fmt+0x3e/0x60
 [] debug_dma_assert_idle+0x159/0x1d0
 [] ? anon_vma_prepare+0x29/0x140
 [] do_wp_page+0xe4/0x8c0
 [] handle_mm_fault+0x662/0xba0
 [] ? __do_page_fault+0x1a7/0x5d0
 [] __do_page_fault+0x208/0x5d0
 [] ? might_fault+0x51/0xb0
 [] ? might_fault+0xa7/0xb0
 [] ? _copy_to_user+0x40/0x60
 [] ? __do_page_fault+0x5d0/0x5d0
 [] do_page_fault+0x1a/0x20
 [] error_code+0x6c/0x74
---[ end trace d1e2e0e42481c1e4 ]---
Mapped at:
 [] debug_dma_alloc_coherent+0x22/0x70
 [] dmam_alloc_coherent+0xdb/0x130
 [] ahci_port_start+0xed/0x230
 [] ata_host_start.part.24+0xcb/0x1b0
 [] ata_host_activate+0x45/0x100

ahci:
00:09.0 SATA controller: NVIDIA Corporation MCP78S [GeForce 8200] AHCI 
Controller (rev a2)
and
snd_hda_intel:
00:07.0 Audio device: NVIDIA Corporation MCP72XE/MCP72P/MCP78U/MCP78S High 
Definition Audio (rev a1)
swapped the roles. :)
mt7601Usta is irrelevant as tainter, here.


poma



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: debug_dma_assert_idle - ahci - cpu touching an active dma mapped cacheline

[poma]

On 11.05.2014 12:02, poma wrote:
 
 [ cut here ]
 WARNING: CPU: 2 PID: 628 at lib/dma-debug.c:593 
 debug_dma_assert_idle+0x159/0x1d0()
 snd_hda_intel :00:07.0: DMA-API: cpu touching an active dma mapped 
 cacheline [cln=0x03074000]
 CPU: 2 PID: 628 Comm: lightdm Not tainted 3.15.0-0.rc5.git0.1.fc21.i686+debug 
 #1
 Call Trace:
  [c0ae737d] dump_stack+0x48/0x60
  [c04547b2] warn_slowpath_common+0x82/0xa0
  [c0754d99] ? debug_dma_assert_idle+0x159/0x1d0
  [c0754d99] ? debug_dma_assert_idle+0x159/0x1d0
  [c045480e] warn_slowpath_fmt+0x3e/0x60
  [c0754d99] debug_dma_assert_idle+0x159/0x1d0
  [c058a149] ? anon_vma_prepare+0x29/0x140
  [c057e56e] do_wp_page+0xce/0x890
  [c0580b72] handle_mm_fault+0x662/0xb70
  [c0af3667] __do_page_fault+0x1a7/0x5d0
  [c04e1057] ? SyS_futex+0x97/0x180
  [c04b1b00] ? trace_hardirqs_on_caller+0x1c0/0x1e0
  [c04b1a7c] ? trace_hardirqs_on_caller+0x13c/0x1e0
  [c0af3a90] ? __do_page_fault+0x5d0/0x5d0
  [c0af3aaa] do_page_fault+0x1a/0x20
  [c0af0484] error_code+0x6c/0x74
 ---[ end trace b400a64c04aed387 ]---
 Mapped at:
  [c0752e42] debug_dma_alloc_coherent+0x22/0x70
  [f80c3e90] snd_dma_alloc_pages+0x170/0x260 [snd_pcm]
  [f80c3fe2] snd_dma_alloc_pages_fallback+0x62/0x90 [snd_pcm]
  [f80c43b0] snd_malloc_sgbuf_pages+0xf0/0x211 [snd_pcm]
  [f80c3f23] snd_dma_alloc_pages+0x203/0x260 [snd_pcm]
 

[ cut here ]
WARNING: CPU: 1 PID: 1180 at lib/dma-debug.c:593 
debug_dma_assert_idle+0x159/0x1d0()
ahci :00:09.0: DMA-API: cpu touching an active dma mapped cacheline 
[cln=0x03001000]
Modules linked in: ip6t_rpfilter ip6t_REJECT xt_conntrack cfg80211 rfkill 
ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat 
nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security 
ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security 
iptable_raw mt7601Usta(OE) nouveau kvm_amd ata_generic kvm uas pata_acpi ppdev 
mxm_wmi parport_serial video usb_storage k10temp r8169 i2c_algo_bit ttm 
drm_kms_helper serio_raw microcode parport_pc skge parport mii drm wmi 
i2c_nforce2 i2ccore pata_amd acpi_cpufreq sunrpc
CPU: 1 PID: 1180 Comm: gmain Tainted: G   OE  
3.17.0-0.rc2.git3.1.fc22.i686 #1
...
Call Trace:
 [c0b137d8] dump_stack+0x48/0x60
 [c0459092] warn_slowpath_common+0x82/0xa0
 [c076c1e9] ? debug_dma_assert_idle+0x159/0x1d0
 [c076c1e9] ? debug_dma_assert_idle+0x159/0x1d0
 [c04590ee] warn_slowpath_fmt+0x3e/0x60
 [c076c1e9] debug_dma_assert_idle+0x159/0x1d0
 [c059b8a9] ? anon_vma_prepare+0x29/0x140
 [c0590524] do_wp_page+0xe4/0x8c0
 [c0592722] handle_mm_fault+0x662/0xba0
 [c0447237] ? __do_page_fault+0x1a7/0x5d0
 [c0447298] __do_page_fault+0x208/0x5d0
 [c058ebd1] ? might_fault+0x51/0xb0
 [c058ec27] ? might_fault+0xa7/0xb0
 [c074dbb0] ? _copy_to_user+0x40/0x60
 [c0447660] ? __do_page_fault+0x5d0/0x5d0
 [c044767a] do_page_fault+0x1a/0x20
 [c0b1d2b4] error_code+0x6c/0x74
---[ end trace d1e2e0e42481c1e4 ]---
Mapped at:
 [c076a292] debug_dma_alloc_coherent+0x22/0x70
 [c0867cbb] dmam_alloc_coherent+0xdb/0x130
 [c08b798d] ahci_port_start+0xed/0x230
 [c089d23b] ata_host_start.part.24+0xcb/0x1b0
 [c08a2a35] ata_host_activate+0x45/0x100

ahci:
00:09.0 SATA controller: NVIDIA Corporation MCP78S [GeForce 8200] AHCI 
Controller (rev a2)
and
snd_hda_intel:
00:07.0 Audio device: NVIDIA Corporation MCP72XE/MCP72P/MCP78U/MCP78S High 
Definition Audio (rev a1)
swapped the roles. :)
mt7601Usta is irrelevant as tainter, here.


poma



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: WARNING: CPU: 1 PID: 495 at mm/slab_common.c:69 kmem_cache_create+0x1a9/0x330()

[poma]

On 29.07.2014 14:26, Christoph Hellwig wrote:
> On Mon, Jul 28, 2014 at 11:49:22AM +0400, James Bottomley wrote:
>> That needs to be
>>
>> From: James Bottomley 
>>
>> As well.  I do list handling on hansenpartnership.com to minimise
>> exchange wreckage on mailinglists, but I should acknowledge Parallels as
>> supporting the work I do.
> 
> Thanks, I've update the author, added a Cc to ћtable and pushed it out to
> the core-for-3.17 branch.
> 

Thanks guys!

Ref.
http://git.infradead.org/users/hch/scsi-queue.git/patch/884ffee?hp=16acf5d


poma


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: WARNING: CPU: 1 PID: 495 at mm/slab_common.c:69 kmem_cache_create+0x1a9/0x330()

[poma]

On 29.07.2014 14:26, Christoph Hellwig wrote:
 On Mon, Jul 28, 2014 at 11:49:22AM +0400, James Bottomley wrote:
 That needs to be

 From: James Bottomley jbottom...@parallels.com

 As well.  I do list handling on hansenpartnership.com to minimise
 exchange wreckage on mailinglists, but I should acknowledge Parallels as
 supporting the work I do.
 
 Thanks, I've update the author, added a Cc to ћtable and pushed it out to
 the core-for-3.17 branch.
 

Thanks guys!

Ref.
http://git.infradead.org/users/hch/scsi-queue.git/patch/884ffee?hp=16acf5d


poma


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: WARNING: CPU: 1 PID: 495 at mm/slab_common.c:69 kmem_cache_create+0x1a9/0x330()

[poma]

On 21.07.2014 16:58, Christoph Hellwig wrote:

On Mon, Jul 21, 2014 at 11:39:15AM +0200, poma wrote:

Thanks for the tip.
Is there a patch somewhere?


James sent the patch earlier and you replied to it.



Yea I could be more precise. :)
What I thought, is the patch pushed in some official repo and officially 
approved?
I guess that's the only way to achieve validity.


poma


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: WARNING: CPU: 1 PID: 495 at mm/slab_common.c:69 kmem_cache_create+0x1a9/0x330()

[poma]

On 19.07.2014 18:44, Christoph Hellwig wrote:

On Fri, Jul 18, 2014 at 01:07:26PM -0700, James Bottomley wrote:

Is this what you thought?


No, he means this, if you want to try it.


Yes, that's what I mean.



Thanks for the tip.
Is there a patch somewhere?


poma


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: WARNING: CPU: 1 PID: 495 at mm/slab_common.c:69 kmem_cache_create+0x1a9/0x330()

[poma]

On 19.07.2014 18:44, Christoph Hellwig wrote:

On Fri, Jul 18, 2014 at 01:07:26PM -0700, James Bottomley wrote:

Is this what you thought?


No, he means this, if you want to try it.


Yes, that's what I mean.



Thanks for the tip.
Is there a patch somewhere?


poma


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: WARNING: CPU: 1 PID: 495 at mm/slab_common.c:69 kmem_cache_create+0x1a9/0x330()

[poma]

On 21.07.2014 16:58, Christoph Hellwig wrote:

On Mon, Jul 21, 2014 at 11:39:15AM +0200, poma wrote:

Thanks for the tip.
Is there a patch somewhere?


James sent the patch earlier and you replied to it.



Yea I could be more precise. :)
What I thought, is the patch pushed in some official repo and officially 
approved?
I guess that's the only way to achieve validity.


poma


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: WARNING: CPU: 1 PID: 495 at mm/slab_common.c:69 kmem_cache_create+0x1a9/0x330()

[poma]

On 18.07.2014 22:03, poma wrote:

On 18.07.2014 16:20, Christoph Lameter wrote:

On Fri, 18 Jul 2014, poma wrote:


I guess someone working over the summertime. :)


Cache names should not contain blanks. I guess the

WARN_ON(strchr(name, ' ')); /* It confuses parsers */

was triggered?



I can only guess also. ;)



BTW sorry for the noise. :)


poma


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: WARNING: CPU: 1 PID: 495 at mm/slab_common.c:69 kmem_cache_create+0x1a9/0x330()

[poma]

On 18.07.2014 22:16, poma wrote:

On 18.07.2014 22:07, James Bottomley wrote:

On Fri, 2014-07-18 at 22:01 +0200, poma wrote:

On 18.07.2014 16:17, Christoph Hellwig wrote:

On Fri, Jul 18, 2014 at 05:21:04PM +0400, Vladimir Davydov wrote:

Slab warns, because the name of the cache being created contains spaces.
The "bad" cache is created by scsi_get_host_cmd_pool. Its name
(pool->cmd_name) is initialized by scsi_alloc_host_cmd_pool as follows:

pool->cmd_name = kasprintf(GFP_KERNEL, "%s_cmd", hostt->name);

So, if hostt->name contains spaces, the cache name will also contain
spaces and we'll get the warning. And hostt->name can contain spaces,
e.g. virtscsi_host_template_single.name="Virtio SCSI HBA".


Or might not even be present.  I'll send a patch to replace it with
->proc_name, which must not contain spaces and is generally shorter
as well.



Is this what you thought?


No, he means this, if you want to try it.

James

---

diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 88d46fe..eb07a9b 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -368,8 +368,8 @@ scsi_alloc_host_cmd_pool(struct Scsi_Host *shost)
if (!pool)
return NULL;

-   pool->cmd_name = kasprintf(GFP_KERNEL, "%s_cmd", hostt->name);
-   pool->sense_name = kasprintf(GFP_KERNEL, "%s_sense", hostt->name);
+   pool->cmd_name = kasprintf(GFP_KERNEL, "%s_cmd", hostt->proc_name);
+   pool->sense_name = kasprintf(GFP_KERNEL, "%s_sense", hostt->proc_name);
if (!pool->cmd_name || !pool->sense_name) {
scsi_free_host_cmd_pool(pool);
return NULL;




Man, I just now read it correctly - "So, if hostt->name contains spaces".
Thanks.

I'll be back.



Yea, I can confirm it works! :)
No warnings.


poma


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: WARNING: CPU: 1 PID: 495 at mm/slab_common.c:69 kmem_cache_create+0x1a9/0x330()

[poma]

On 18.07.2014 22:07, James Bottomley wrote:

On Fri, 2014-07-18 at 22:01 +0200, poma wrote:

On 18.07.2014 16:17, Christoph Hellwig wrote:

On Fri, Jul 18, 2014 at 05:21:04PM +0400, Vladimir Davydov wrote:

Slab warns, because the name of the cache being created contains spaces.
The "bad" cache is created by scsi_get_host_cmd_pool. Its name
(pool->cmd_name) is initialized by scsi_alloc_host_cmd_pool as follows:

pool->cmd_name = kasprintf(GFP_KERNEL, "%s_cmd", hostt->name);

So, if hostt->name contains spaces, the cache name will also contain
spaces and we'll get the warning. And hostt->name can contain spaces,
e.g. virtscsi_host_template_single.name="Virtio SCSI HBA".


Or might not even be present.  I'll send a patch to replace it with
->proc_name, which must not contain spaces and is generally shorter
as well.



Is this what you thought?


No, he means this, if you want to try it.

James

---

diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 88d46fe..eb07a9b 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -368,8 +368,8 @@ scsi_alloc_host_cmd_pool(struct Scsi_Host *shost)
if (!pool)
return NULL;

-   pool->cmd_name = kasprintf(GFP_KERNEL, "%s_cmd", hostt->name);
-   pool->sense_name = kasprintf(GFP_KERNEL, "%s_sense", hostt->name);
+   pool->cmd_name = kasprintf(GFP_KERNEL, "%s_cmd", hostt->proc_name);
+   pool->sense_name = kasprintf(GFP_KERNEL, "%s_sense", hostt->proc_name);
if (!pool->cmd_name || !pool->sense_name) {
scsi_free_host_cmd_pool(pool);
return NULL;




Man, I just now read it correctly - "So, if hostt->name contains spaces".
Thanks.

I'll be back.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: WARNING: CPU: 1 PID: 495 at mm/slab_common.c:69 kmem_cache_create+0x1a9/0x330()

[poma]

On 18.07.2014 16:20, Christoph Lameter wrote:

On Fri, 18 Jul 2014, poma wrote:


I guess someone working over the summertime. :)


Cache names should not contain blanks. I guess the

   WARN_ON(strchr(name, ' ')); /* It confuses parsers */

was triggered?



I can only guess also. ;)


poma

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: WARNING: CPU: 1 PID: 495 at mm/slab_common.c:69 kmem_cache_create+0x1a9/0x330()

[poma]

On 18.07.2014 16:17, Christoph Hellwig wrote:

On Fri, Jul 18, 2014 at 05:21:04PM +0400, Vladimir Davydov wrote:

Slab warns, because the name of the cache being created contains spaces.
The "bad" cache is created by scsi_get_host_cmd_pool. Its name
(pool->cmd_name) is initialized by scsi_alloc_host_cmd_pool as follows:

pool->cmd_name = kasprintf(GFP_KERNEL, "%s_cmd", hostt->name);

So, if hostt->name contains spaces, the cache name will also contain
spaces and we'll get the warning. And hostt->name can contain spaces,
e.g. virtscsi_host_template_single.name="Virtio SCSI HBA".


Or might not even be present.  I'll send a patch to replace it with
->proc_name, which must not contain spaces and is generally shorter
as well.



Is this what you thought?
@@ -148,20 +148,20 @@
struct kmem_cache   *cmd_slab;
struct kmem_cache   *sense_slab;
unsigned intusers;
-   char*cmd_name;
+   char*proc_name;
char*sense_name;
unsigned intslab_flags;
gfp_t   gfp_mask;
 };
 
 static struct scsi_host_cmd_pool scsi_cmd_pool = {

-   .cmd_name   = "scsi_cmd_cache",
+   .proc_name  = "scsi_cmd_cache",
.sense_name = "scsi_sense_cache",
.slab_flags = SLAB_HWCACHE_ALIGN,
 };
 
 static struct scsi_host_cmd_pool scsi_cmd_dma_pool = {

-   .cmd_name   = "scsi_cmd_cache(DMA)",
+   .proc_name  = "scsi_cmd_cache(DMA)",
.sense_name = "scsi_sense_cache(DMA)",
.slab_flags = SLAB_HWCACHE_ALIGN|SLAB_CACHE_DMA,
.gfp_mask   = __GFP_DMA,
@@ -354,7 +354,7 @@
 scsi_free_host_cmd_pool(struct scsi_host_cmd_pool *pool)
 {
kfree(pool->sense_name);
-   kfree(pool->cmd_name);
+   kfree(pool->proc_name);
kfree(pool);
 }
 
@@ -368,9 +368,9 @@

if (!pool)
return NULL;
 
-	pool->cmd_name = kasprintf(GFP_KERNEL, "%s_cmd", hostt->name);

+   pool->proc_name = kasprintf(GFP_KERNEL, "%s_cmd", hostt->name);
pool->sense_name = kasprintf(GFP_KERNEL, "%s_sense", hostt->name);
-   if (!pool->cmd_name || !pool->sense_name) {
+   if (!pool->proc_name || !pool->sense_name) {
scsi_free_host_cmd_pool(pool);
return NULL;
}
@@ -403,7 +403,7 @@
}
 
 	if (!pool->users) {

-   pool->cmd_slab = kmem_cache_create(pool->cmd_name, cmd_size, 0,
+   pool->cmd_slab = kmem_cache_create(pool->proc_name, cmd_size, 0,
   pool->slab_flags, NULL);
if (!pool->cmd_slab)
goto out_free_pool;


however ain't workin.


poma


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

WARNING: CPU: 1 PID: 495 at mm/slab_common.c:69 kmem_cache_create+0x1a9/0x330()

[poma]

I guess someone working over the summertime. :)

[ cut here ]
WARNING: CPU: 1 PID: 495 at mm/slab_common.c:69 kmem_cache_create+0x1a9/0x330()
Modules linked in: virtio_net virtio_scsi(+) drm virtio_pci i2c_core 
virtio_ring ata_generic pata_acpi virtio sunrpc dm_crypt dm_round_robin linear 
raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor xor async_tx 
raid6_pq raid1 raid0 iscsi_ibft iscsi_boot_sysfs floppy iscsi_tcp libiscsi_tcp 
libiscsi scsi_transport_iscsi squashfs cramfs edd dm_multipath
CPU: 1 PID: 495 Comm: systemd-udevd Not tainted 3.16.0-0.rc5.git0.1.fc21.x86_64 
#1
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
   bfd3b05a 88007f55fa40 8171b4e3
   88007f55fa78 8108f30d 880079175d40
  88007f55ffd8 81c6de08 88007f55ffd8 88007f55ffd8
Call Trace:
  [] dump_stack+0x45/0x56
  [] warn_slowpath_common+0x7d/0xa0
  [] warn_slowpath_null+0x1a/0x20
  [] kmem_cache_create+0x1a9/0x330
  [] scsi_setup_command_freelist+0x120/0x270
  [] scsi_add_host_with_dma+0x60/0x2b0
  [] virtscsi_probe+0x269/0x2af [virtio_scsi]
  [] ? vp_reset+0x90/0x90 [virtio_pci]
  [] virtio_dev_probe+0xe9/0x160 [virtio]
  [] driver_probe_device+0xa3/0x400
  [] __driver_attach+0x8b/0x90
  [] ? __device_attach+0x40/0x40
  [] bus_for_each_dev+0x73/0xc0
  [] driver_attach+0x1e/0x20
  [] bus_add_driver+0x180/0x250
  [] ? 0xa017
  [] driver_register+0x64/0xf0
  [] register_virtio_driver+0x20/0x40 [virtio]
  [] init+0x85/0x1000 [virtio_scsi]
  [] do_one_initcall+0xd8/0x210
  [] ? __vunmap+0xa2/0x100
  [] load_module+0x2061/0x2600
  [] ? store_uevent+0x70/0x70
  [] SyS_init_module+0xcd/0x120
  [] system_call_fastpath+0x16/0x1b
---[ end trace 64d7cf025fd3bf4a ]---

https://bugzilla.redhat.com/show_bug.cgi?id=1121092


poma


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: WARNING: CPU: 1 PID: 495 at mm/slab_common.c:69 kmem_cache_create+0x1a9/0x330()

[poma]

On 18.07.2014 16:17, Christoph Hellwig wrote:

On Fri, Jul 18, 2014 at 05:21:04PM +0400, Vladimir Davydov wrote:

Slab warns, because the name of the cache being created contains spaces.
The bad cache is created by scsi_get_host_cmd_pool. Its name
(pool-cmd_name) is initialized by scsi_alloc_host_cmd_pool as follows:

pool-cmd_name = kasprintf(GFP_KERNEL, %s_cmd, hostt-name);

So, if hostt-name contains spaces, the cache name will also contain
spaces and we'll get the warning. And hostt-name can contain spaces,
e.g. virtscsi_host_template_single.name=Virtio SCSI HBA.


Or might not even be present.  I'll send a patch to replace it with
-proc_name, which must not contain spaces and is generally shorter
as well.



Is this what you thought?
@@ -148,20 +148,20 @@
struct kmem_cache   *cmd_slab;
struct kmem_cache   *sense_slab;
unsigned intusers;
-   char*cmd_name;
+   char*proc_name;
char*sense_name;
unsigned intslab_flags;
gfp_t   gfp_mask;
 };
 
 static struct scsi_host_cmd_pool scsi_cmd_pool = {

-   .cmd_name   = scsi_cmd_cache,
+   .proc_name  = scsi_cmd_cache,
.sense_name = scsi_sense_cache,
.slab_flags = SLAB_HWCACHE_ALIGN,
 };
 
 static struct scsi_host_cmd_pool scsi_cmd_dma_pool = {

-   .cmd_name   = scsi_cmd_cache(DMA),
+   .proc_name  = scsi_cmd_cache(DMA),
.sense_name = scsi_sense_cache(DMA),
.slab_flags = SLAB_HWCACHE_ALIGN|SLAB_CACHE_DMA,
.gfp_mask   = __GFP_DMA,
@@ -354,7 +354,7 @@
 scsi_free_host_cmd_pool(struct scsi_host_cmd_pool *pool)
 {
kfree(pool-sense_name);
-   kfree(pool-cmd_name);
+   kfree(pool-proc_name);
kfree(pool);
 }
 
@@ -368,9 +368,9 @@

if (!pool)
return NULL;
 
-	pool-cmd_name = kasprintf(GFP_KERNEL, %s_cmd, hostt-name);

+   pool-proc_name = kasprintf(GFP_KERNEL, %s_cmd, hostt-name);
pool-sense_name = kasprintf(GFP_KERNEL, %s_sense, hostt-name);
-   if (!pool-cmd_name || !pool-sense_name) {
+   if (!pool-proc_name || !pool-sense_name) {
scsi_free_host_cmd_pool(pool);
return NULL;
}
@@ -403,7 +403,7 @@
}
 
 	if (!pool-users) {

-   pool-cmd_slab = kmem_cache_create(pool-cmd_name, cmd_size, 0,
+   pool-cmd_slab = kmem_cache_create(pool-proc_name, cmd_size, 0,
   pool-slab_flags, NULL);
if (!pool-cmd_slab)
goto out_free_pool;


however ain't workin.


poma


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: WARNING: CPU: 1 PID: 495 at mm/slab_common.c:69 kmem_cache_create+0x1a9/0x330()

[poma]

On 18.07.2014 16:20, Christoph Lameter wrote:

On Fri, 18 Jul 2014, poma wrote:


I guess someone working over the summertime. :)


Cache names should not contain blanks. I guess the

   WARN_ON(strchr(name, ' ')); /* It confuses parsers */

was triggered?



I can only guess also. ;)


poma

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: WARNING: CPU: 1 PID: 495 at mm/slab_common.c:69 kmem_cache_create+0x1a9/0x330()

[poma]

On 18.07.2014 22:07, James Bottomley wrote:

On Fri, 2014-07-18 at 22:01 +0200, poma wrote:

On 18.07.2014 16:17, Christoph Hellwig wrote:

On Fri, Jul 18, 2014 at 05:21:04PM +0400, Vladimir Davydov wrote:

Slab warns, because the name of the cache being created contains spaces.
The bad cache is created by scsi_get_host_cmd_pool. Its name
(pool-cmd_name) is initialized by scsi_alloc_host_cmd_pool as follows:

pool-cmd_name = kasprintf(GFP_KERNEL, %s_cmd, hostt-name);

So, if hostt-name contains spaces, the cache name will also contain
spaces and we'll get the warning. And hostt-name can contain spaces,
e.g. virtscsi_host_template_single.name=Virtio SCSI HBA.


Or might not even be present.  I'll send a patch to replace it with
-proc_name, which must not contain spaces and is generally shorter
as well.



Is this what you thought?


No, he means this, if you want to try it.

James

---

diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 88d46fe..eb07a9b 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -368,8 +368,8 @@ scsi_alloc_host_cmd_pool(struct Scsi_Host *shost)
if (!pool)
return NULL;

-   pool-cmd_name = kasprintf(GFP_KERNEL, %s_cmd, hostt-name);
-   pool-sense_name = kasprintf(GFP_KERNEL, %s_sense, hostt-name);
+   pool-cmd_name = kasprintf(GFP_KERNEL, %s_cmd, hostt-proc_name);
+   pool-sense_name = kasprintf(GFP_KERNEL, %s_sense, hostt-proc_name);
if (!pool-cmd_name || !pool-sense_name) {
scsi_free_host_cmd_pool(pool);
return NULL;




Man, I just now read it correctly - So, if hostt-name contains spaces.
Thanks.

I'll be back.



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: WARNING: CPU: 1 PID: 495 at mm/slab_common.c:69 kmem_cache_create+0x1a9/0x330()

[poma]

On 18.07.2014 22:16, poma wrote:

On 18.07.2014 22:07, James Bottomley wrote:

On Fri, 2014-07-18 at 22:01 +0200, poma wrote:

On 18.07.2014 16:17, Christoph Hellwig wrote:

On Fri, Jul 18, 2014 at 05:21:04PM +0400, Vladimir Davydov wrote:

Slab warns, because the name of the cache being created contains spaces.
The bad cache is created by scsi_get_host_cmd_pool. Its name
(pool-cmd_name) is initialized by scsi_alloc_host_cmd_pool as follows:

pool-cmd_name = kasprintf(GFP_KERNEL, %s_cmd, hostt-name);

So, if hostt-name contains spaces, the cache name will also contain
spaces and we'll get the warning. And hostt-name can contain spaces,
e.g. virtscsi_host_template_single.name=Virtio SCSI HBA.


Or might not even be present.  I'll send a patch to replace it with
-proc_name, which must not contain spaces and is generally shorter
as well.



Is this what you thought?


No, he means this, if you want to try it.

James

---

diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 88d46fe..eb07a9b 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -368,8 +368,8 @@ scsi_alloc_host_cmd_pool(struct Scsi_Host *shost)
if (!pool)
return NULL;

-   pool-cmd_name = kasprintf(GFP_KERNEL, %s_cmd, hostt-name);
-   pool-sense_name = kasprintf(GFP_KERNEL, %s_sense, hostt-name);
+   pool-cmd_name = kasprintf(GFP_KERNEL, %s_cmd, hostt-proc_name);
+   pool-sense_name = kasprintf(GFP_KERNEL, %s_sense, hostt-proc_name);
if (!pool-cmd_name || !pool-sense_name) {
scsi_free_host_cmd_pool(pool);
return NULL;




Man, I just now read it correctly - So, if hostt-name contains spaces.
Thanks.

I'll be back.



Yea, I can confirm it works! :)
No warnings.


poma


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: WARNING: CPU: 1 PID: 495 at mm/slab_common.c:69 kmem_cache_create+0x1a9/0x330()

[poma]

On 18.07.2014 22:03, poma wrote:

On 18.07.2014 16:20, Christoph Lameter wrote:

On Fri, 18 Jul 2014, poma wrote:


I guess someone working over the summertime. :)


Cache names should not contain blanks. I guess the

WARN_ON(strchr(name, ' ')); /* It confuses parsers */

was triggered?



I can only guess also. ;)



BTW sorry for the noise. :)


poma


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

WARNING: CPU: 1 PID: 495 at mm/slab_common.c:69 kmem_cache_create+0x1a9/0x330()

[poma]

I guess someone working over the summertime. :)

[ cut here ]
WARNING: CPU: 1 PID: 495 at mm/slab_common.c:69 kmem_cache_create+0x1a9/0x330()
Modules linked in: virtio_net virtio_scsi(+) drm virtio_pci i2c_core 
virtio_ring ata_generic pata_acpi virtio sunrpc dm_crypt dm_round_robin linear 
raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor xor async_tx 
raid6_pq raid1 raid0 iscsi_ibft iscsi_boot_sysfs floppy iscsi_tcp libiscsi_tcp 
libiscsi scsi_transport_iscsi squashfs cramfs edd dm_multipath
CPU: 1 PID: 495 Comm: systemd-udevd Not tainted 3.16.0-0.rc5.git0.1.fc21.x86_64 
#1
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
   bfd3b05a 88007f55fa40 8171b4e3
   88007f55fa78 8108f30d 880079175d40
  88007f55ffd8 81c6de08 88007f55ffd8 88007f55ffd8
Call Trace:
  [8171b4e3] dump_stack+0x45/0x56
  [8108f30d] warn_slowpath_common+0x7d/0xa0
  [8108f43a] warn_slowpath_null+0x1a/0x20
  [811a7c59] kmem_cache_create+0x1a9/0x330
  [814a4070] scsi_setup_command_freelist+0x120/0x270
  [814a4d90] scsi_add_host_with_dma+0x60/0x2b0
  [a017b9c9] virtscsi_probe+0x269/0x2af [virtio_scsi]
  [a01877c0] ? vp_reset+0x90/0x90 [virtio_pci]
  [a010e1d9] virtio_dev_probe+0xe9/0x160 [virtio]
  [81483d83] driver_probe_device+0xa3/0x400
  [814841ab] __driver_attach+0x8b/0x90
  [81484120] ? __device_attach+0x40/0x40
  [81481b23] bus_for_each_dev+0x73/0xc0
  [8148381e] driver_attach+0x1e/0x20
  [814833f0] bus_add_driver+0x180/0x250
  [a018] ? 0xa017
  [81484974] driver_register+0x64/0xf0
  [a010e550] register_virtio_driver+0x20/0x40 [virtio]
  [a0180085] init+0x85/0x1000 [virtio_scsi]
  [81002148] do_one_initcall+0xd8/0x210
  [811c3952] ? __vunmap+0xa2/0x100
  [8110d951] load_module+0x2061/0x2600
  [811092f0] ? store_uevent+0x70/0x70
  [8110dfbd] SyS_init_module+0xcd/0x120
  [817223a9] system_call_fastpath+0x16/0x1b
---[ end trace 64d7cf025fd3bf4a ]---

https://bugzilla.redhat.com/show_bug.cgi?id=1121092


poma


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

console font

[poma]

On 25.06.2014 20:49, poma wrote:

On 25.06.2014 20:10, Felix Miata wrote:

On 2014-06-25 10:05 (GMT-0700) Adam Williamson composed:


So...these are three different machines?


3 out of 14 on which Rawhide is currently installed (test machines total 20+)
here, among which are represented various flavors of MGA (400 & 550), SiS
(Z7/Z9 XG20 core), Intel (810, 815, 845, 865, 915, 945, 965, 3100, 4100), ATI
(rv200, rv250, rv370, rv380, rv516) & NVidia for video.


I'm curious: why are you passing video= parameters on each one? Do
any/all of them work if you don't pass that parameter?


Most of my test machines get used most of the time with a '21"' CRT with
preferred mode 1600x1200 reported as preferred mode 1280x1024 used at
approximately 175% of normal viewing distance. Avoiding eyestrain requires
1152x864 or lower on the vttys unless I want to monkey with terminal font
reconfiguration from default.

My second most used test machine display is a 19" LCD TV with native mode
1440x900 that reports preferred 1280x1024 but supports 4:3 modes up to
1792x1344. It is used at similar distance, so also needs 1024x768 on the
vttys for the same reason as the CRT.

I also have 2 15" 1024x768, 17" & 19" 1280x1024 and 20" 1600x1200 LCD puter
displays, 2 31.5" TVs, and an abundance of other CRTs to use as test
conditions require, in addition to the LCDs used for my 24/7 systems that can
be briefly pressed into test service when necessary.



# yum install terminus-fonts-console

- permanent system wide
/etc/vconsole.conf
FONT=

e.g. 'latarcyrheb-sun32' or 'ter-v32b'

- runtime local
$ setfont latarcyrheb-sun32
$ setfont ter-v32b



systemd-214-5.fc21.x86_64
kernel-3.16.0-0.rc3.git0.1.fc21.x86_64

It seems this kernel? bug is still present[2].

"rd.vconsole.font=ter-v32b" also fails to subsist due to
"fb: switching to nouveaufb from VESA VGA".

- journal systemd-vconsole-setup
systemd[1]: Starting Setup Virtual Console...
systemd-vconsole-setup[347]: putfont: KDFONTOP: Invalid argument
systemd-vconsole-setup[347]: /usr/bin/setfont failed with error code 71.
systemd[1]: Started Setup Virtual Console.

I've found so far that this can only be overcome with these two almost 
identical solutions;
When I thought of 'actual-vconsole-setup-start' I did not know that Yegor 
already done it.
Saṃsāra.


Yegor's solution[1]:
 # cp /usr/lib/systemd/system/systemd-vconsole-setup.service 
/etc/systemd/system/
 # diff /etc/systemd/system/systemd-vconsole-setup.service \
 > /usr/lib/systemd/system/systemd-vconsole-setup.service
 13,14c13,14
 < After=sysinit.target
 < Before=shutdown.target
 ---
 > After=systemd-readahead-collect.service systemd-readahead-replay.service
 > Before=sysinit.target shutdown.target

or even simpler - leave 'systemd-vconsole-setup.service' as is,
and make this one
/etc/systemd/system/actual-vconsole-setup-start.service:
# Actual Virtual Console Setup Start

[Unit]
Description=Actual Virtual Console Setup Start

[Service]
Type=forking
ExecStart=/usr/lib/systemd/systemd-vconsole-setup

[Install]
WantedBy=rescue.target multi-user.target

# systemctl enable actual-vconsole-setup-start.service

and now you have appropriate font size for 1920x1080,
no need to lower resolution via "video=x".
Perhaps '32' is too large, so choose <= '28', e.g. ter-v28b or ter-v24b.
/usr/share/doc/terminus-fonts-console/README[.fedora]


poma


[1] systemd-vconsole-setup: /usr/bin/setfont failed with error code 71
http://lists.freedesktop.org/archives/systemd-devel/2011-June/002562.html

[2] Can not change console font via /etc/vconsole.conf
https://bugzilla.redhat.com/show_bug.cgi?id=1074113

The keyboard layout for the virtual console cannot be changed using
“localectl set-keymap ; dracut -f; reboot;”
https://bugzilla.redhat.com/show_bug.cgi?id=1033250

font settings are lost when kernel fb drivers are changed
https://bugzilla.redhat.com/show_bug.cgi?id=892340

Kernel drivers lose console font settings
https://bugzilla.redhat.com/show_bug.cgi?id=1074624

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

console font

[poma]

On 25.06.2014 20:49, poma wrote:

On 25.06.2014 20:10, Felix Miata wrote:

On 2014-06-25 10:05 (GMT-0700) Adam Williamson composed:


So...these are three different machines?


3 out of 14 on which Rawhide is currently installed (test machines total 20+)
here, among which are represented various flavors of MGA (400  550), SiS
(Z7/Z9 XG20 core), Intel (810, 815, 845, 865, 915, 945, 965, 3100, 4100), ATI
(rv200, rv250, rv370, rv380, rv516)  NVidia for video.


I'm curious: why are you passing video= parameters on each one? Do
any/all of them work if you don't pass that parameter?


Most of my test machines get used most of the time with a '21' CRT with
preferred mode 1600x1200 reported as preferred mode 1280x1024 used at
approximately 175% of normal viewing distance. Avoiding eyestrain requires
1152x864 or lower on the vttys unless I want to monkey with terminal font
reconfiguration from default.

My second most used test machine display is a 19 LCD TV with native mode
1440x900 that reports preferred 1280x1024 but supports 4:3 modes up to
1792x1344. It is used at similar distance, so also needs 1024x768 on the
vttys for the same reason as the CRT.

I also have 2 15 1024x768, 17  19 1280x1024 and 20 1600x1200 LCD puter
displays, 2 31.5 TVs, and an abundance of other CRTs to use as test
conditions require, in addition to the LCDs used for my 24/7 systems that can
be briefly pressed into test service when necessary.



# yum install terminus-fonts-console

- permanent system wide
/etc/vconsole.conf
FONT=Big mama font

e.g. 'latarcyrheb-sun32' or 'ter-v32b'

- runtime local
$ setfont latarcyrheb-sun32
$ setfont ter-v32b



systemd-214-5.fc21.x86_64
kernel-3.16.0-0.rc3.git0.1.fc21.x86_64

It seems this kernel? bug is still present[2].

rd.vconsole.font=ter-v32b also fails to subsist due to
fb: switching to nouveaufb from VESA VGA.

- journal systemd-vconsole-setup
systemd[1]: Starting Setup Virtual Console...
systemd-vconsole-setup[347]: putfont: KDFONTOP: Invalid argument
systemd-vconsole-setup[347]: /usr/bin/setfont failed with error code 71.
systemd[1]: Started Setup Virtual Console.

I've found so far that this can only be overcome with these two almost 
identical solutions;
When I thought of 'actual-vconsole-setup-start' I did not know that Yegor 
already done it.
Saṃsāra.


Yegor's solution[1]:
 # cp /usr/lib/systemd/system/systemd-vconsole-setup.service 
/etc/systemd/system/
 # diff /etc/systemd/system/systemd-vconsole-setup.service \
  /usr/lib/systemd/system/systemd-vconsole-setup.service
 13,14c13,14
  After=sysinit.target
  Before=shutdown.target
 ---
  After=systemd-readahead-collect.service systemd-readahead-replay.service
  Before=sysinit.target shutdown.target

or even simpler - leave 'systemd-vconsole-setup.service' as is,
and make this one
/etc/systemd/system/actual-vconsole-setup-start.service:
# Actual Virtual Console Setup Start

[Unit]
Description=Actual Virtual Console Setup Start

[Service]
Type=forking
ExecStart=/usr/lib/systemd/systemd-vconsole-setup

[Install]
WantedBy=rescue.target multi-user.target

# systemctl enable actual-vconsole-setup-start.service

and now you have appropriate font size for 1920x1080,
no need to lower resolution via video=xresxyres.
Perhaps '32' is too large, so choose = '28', e.g. ter-v28b or ter-v24b.
/usr/share/doc/terminus-fonts-console/README[.fedora]


poma


[1] systemd-vconsole-setup: /usr/bin/setfont failed with error code 71
http://lists.freedesktop.org/archives/systemd-devel/2011-June/002562.html

[2] Can not change console font via /etc/vconsole.conf
https://bugzilla.redhat.com/show_bug.cgi?id=1074113

The keyboard layout for the virtual console cannot be changed using
“localectl set-keymap map; dracut -f; reboot;”
https://bugzilla.redhat.com/show_bug.cgi?id=1033250

font settings are lost when kernel fb drivers are changed
https://bugzilla.redhat.com/show_bug.cgi?id=892340

Kernel drivers lose console font settings
https://bugzilla.redhat.com/show_bug.cgi?id=1074624

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] asus-nb-wmi: set wapf=4 for ASUSTeK COMPUTER INC. X75VBP & X550CA

[poma]

On 06.05.2014 23:42, Matthew Garrett wrote:

Thanks, if there are no objections I'll apply that.



Matthew, any info for X75VBP?


poma


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] asus-nb-wmi: set wapf=4 for ASUSTeK COMPUTER INC. X75VBP X550CA

[poma]

On 06.05.2014 23:42, Matthew Garrett wrote:

Thanks, if there are no objections I'll apply that.



Matthew, any info for X75VBP?


poma


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: debug_dma_assert_idle - snd_hda_intel - cpu touching an active dma mapped cacheline

[poma]

[ cut here ]
WARNING: CPU: 2 PID: 628 at lib/dma-debug.c:593 
debug_dma_assert_idle+0x159/0x1d0()
snd_hda_intel :00:07.0: DMA-API: cpu touching an active dma mapped 
cacheline [cln=0x03074000]
CPU: 2 PID: 628 Comm: lightdm Not tainted 3.15.0-0.rc5.git0.1.fc21.i686+debug #1
Call Trace:
 [] dump_stack+0x48/0x60
 [] warn_slowpath_common+0x82/0xa0
 [] ? debug_dma_assert_idle+0x159/0x1d0
 [] ? debug_dma_assert_idle+0x159/0x1d0
 [] warn_slowpath_fmt+0x3e/0x60
 [] debug_dma_assert_idle+0x159/0x1d0
 [] ? anon_vma_prepare+0x29/0x140
 [] do_wp_page+0xce/0x890
 [] handle_mm_fault+0x662/0xb70
 [] __do_page_fault+0x1a7/0x5d0
 [] ? SyS_futex+0x97/0x180
 [] ? trace_hardirqs_on_caller+0x1c0/0x1e0
 [] ? trace_hardirqs_on_caller+0x13c/0x1e0
 [] ? __do_page_fault+0x5d0/0x5d0
 [] do_page_fault+0x1a/0x20
 [] error_code+0x6c/0x74
---[ end trace b400a64c04aed387 ]---
Mapped at:
 [] debug_dma_alloc_coherent+0x22/0x70
 [] snd_dma_alloc_pages+0x170/0x260 [snd_pcm]
 [] snd_dma_alloc_pages_fallback+0x62/0x90 [snd_pcm]
 [] snd_malloc_sgbuf_pages+0xf0/0x211 [snd_pcm]
 [] snd_dma_alloc_pages+0x203/0x260 [snd_pcm]


poma


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: debug_dma_assert_idle - snd_hda_intel - cpu touching an active dma mapped cacheline

[poma]

[ cut here ]
WARNING: CPU: 2 PID: 628 at lib/dma-debug.c:593 
debug_dma_assert_idle+0x159/0x1d0()
snd_hda_intel :00:07.0: DMA-API: cpu touching an active dma mapped 
cacheline [cln=0x03074000]
CPU: 2 PID: 628 Comm: lightdm Not tainted 3.15.0-0.rc5.git0.1.fc21.i686+debug #1
Call Trace:
 [c0ae737d] dump_stack+0x48/0x60
 [c04547b2] warn_slowpath_common+0x82/0xa0
 [c0754d99] ? debug_dma_assert_idle+0x159/0x1d0
 [c0754d99] ? debug_dma_assert_idle+0x159/0x1d0
 [c045480e] warn_slowpath_fmt+0x3e/0x60
 [c0754d99] debug_dma_assert_idle+0x159/0x1d0
 [c058a149] ? anon_vma_prepare+0x29/0x140
 [c057e56e] do_wp_page+0xce/0x890
 [c0580b72] handle_mm_fault+0x662/0xb70
 [c0af3667] __do_page_fault+0x1a7/0x5d0
 [c04e1057] ? SyS_futex+0x97/0x180
 [c04b1b00] ? trace_hardirqs_on_caller+0x1c0/0x1e0
 [c04b1a7c] ? trace_hardirqs_on_caller+0x13c/0x1e0
 [c0af3a90] ? __do_page_fault+0x5d0/0x5d0
 [c0af3aaa] do_page_fault+0x1a/0x20
 [c0af0484] error_code+0x6c/0x74
---[ end trace b400a64c04aed387 ]---
Mapped at:
 [c0752e42] debug_dma_alloc_coherent+0x22/0x70
 [f80c3e90] snd_dma_alloc_pages+0x170/0x260 [snd_pcm]
 [f80c3fe2] snd_dma_alloc_pages_fallback+0x62/0x90 [snd_pcm]
 [f80c43b0] snd_malloc_sgbuf_pages+0xf0/0x211 [snd_pcm]
 [f80c3f23] snd_dma_alloc_pages+0x203/0x260 [snd_pcm]


poma


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: debug_dma_assert_idle - snd_hda_intel - cpu touching an active dma mapped cacheline

[poma]

/bpf_dbg.c b/tools/net/bpf_dbg.c

http://pkgs.fedoraproject.org/repo/pkgs/kernel/patch-3.15-rc4-git1.xz/4b0ef9f7c4d9492c34d8263fa875c52f/patch-3.15-rc4-git1.xz


poma


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: debug_dma_assert_idle - snd_hda_intel - cpu touching an active dma mapped cacheline

[poma]

/bpf_dbg.c b/tools/net/bpf_dbg.c

http://pkgs.fedoraproject.org/repo/pkgs/kernel/patch-3.15-rc4-git1.xz/4b0ef9f7c4d9492c34d8263fa875c52f/patch-3.15-rc4-git1.xz


poma


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] asus-nb-wmi: set wapf=4 for ASUSTeK COMPUTER INC. X75VBP & X550CA

[poma]

>From d39d3460f1ab36365a48b6815dd9a5d26613d3ec Mon Sep 17 00:00:00 2001
From: poma 
Date: Tue, 6 May 2014 22:03:38 +0200
Subject: [PATCH] WAPF 4 for ASUSTeK COMPUTER INC. X75VBP WLAN ON.

The 'asus-nb-wmi' WAPF parameter must be set to 4, so the internal Wireless LAN device is operational.

Signed-off-by: poma 
---
 drivers/platform/x86/asus-nb-wmi.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
index 563f59e..674793d 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -182,6 +182,15 @@ static struct dmi_system_id asus_quirks[] = {
 	},
 	{
 		.callback = dmi_matched,
+		.ident = "ASUSTeK COMPUTER INC. X75VBP",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "X75VBP"),
+		},
+		.driver_data = _asus_x401u,
+	},
+	{
+		.callback = dmi_matched,
 		.ident = "ASUSTeK COMPUTER INC. 1015E",
 		.matches = {
 			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
-- 
1.9.0

Re: [PATCH] asus-nb-wmi: set wapf=4 for ASUSTeK COMPUTER INC. X75VBP & X550CA

[poma]

>From d39d3460f1ab36365a48b6815dd9a5d26613d3ec Mon Sep 17 00:00:00 2001
From: poma 
Date: Tue, 6 May 2014 22:03:38 +0200
Subject: [PATCH] WAPF 4 for ASUSTeK COMPUTER INC. X75VBP WLAN ON.

Signed-off-by: poma 
---
 drivers/platform/x86/asus-nb-wmi.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
index 563f59e..674793d 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -182,6 +182,15 @@ static struct dmi_system_id asus_quirks[] = {
 	},
 	{
 		.callback = dmi_matched,
+		.ident = "ASUSTeK COMPUTER INC. X75VBP",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "X75VBP"),
+		},
+		.driver_data = _asus_x401u,
+	},
+	{
+		.callback = dmi_matched,
 		.ident = "ASUSTeK COMPUTER INC. 1015E",
 		.matches = {
 			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
-- 
1.9.0

Re: [PATCH] asus-nb-wmi: set wapf=4 for ASUSTeK COMPUTER INC. X75VBP & X550CA

[poma]

> Corentin, care to pick up this one?
> https://bugzilla.redhat.com/attachment.cgi?id=892751

Matthew, who actually maintains the Asus Notebooks WMI Hotkey Driver i.e. 
'asus-nb-wmi'?


poma


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] asus-nb-wmi: set wapf=4 for ASUSTeK COMPUTER INC. X75VBP X550CA

[poma]

 Corentin, care to pick up this one?
 https://bugzilla.redhat.com/attachment.cgi?id=892751

Matthew, who actually maintains the Asus Notebooks WMI Hotkey Driver i.e. 
'asus-nb-wmi'?


poma


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] asus-nb-wmi: set wapf=4 for ASUSTeK COMPUTER INC. X75VBP X550CA

[poma]

From d39d3460f1ab36365a48b6815dd9a5d26613d3ec Mon Sep 17 00:00:00 2001
From: poma pomidorabelis...@gmail.com
Date: Tue, 6 May 2014 22:03:38 +0200
Subject: [PATCH] WAPF 4 for ASUSTeK COMPUTER INC. X75VBP WLAN ON.

Signed-off-by: poma pomidorabelis...@gmail.com
---
 drivers/platform/x86/asus-nb-wmi.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
index 563f59e..674793d 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -182,6 +182,15 @@ static struct dmi_system_id asus_quirks[] = {
 	},
 	{
 		.callback = dmi_matched,
+		.ident = ASUSTeK COMPUTER INC. X75VBP,
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
+			DMI_MATCH(DMI_PRODUCT_NAME, X75VBP),
+		},
+		.driver_data = quirk_asus_x401u,
+	},
+	{
+		.callback = dmi_matched,
 		.ident = ASUSTeK COMPUTER INC. 1015E,
 		.matches = {
 			DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
-- 
1.9.0

Re: [PATCH] asus-nb-wmi: set wapf=4 for ASUSTeK COMPUTER INC. X75VBP X550CA

[poma]

From d39d3460f1ab36365a48b6815dd9a5d26613d3ec Mon Sep 17 00:00:00 2001
From: poma pomidorabelis...@gmail.com
Date: Tue, 6 May 2014 22:03:38 +0200
Subject: [PATCH] WAPF 4 for ASUSTeK COMPUTER INC. X75VBP WLAN ON.

The 'asus-nb-wmi' WAPF parameter must be set to 4, so the internal Wireless LAN device is operational.

Signed-off-by: poma pomidorabelis...@gmail.com
---
 drivers/platform/x86/asus-nb-wmi.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
index 563f59e..674793d 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -182,6 +182,15 @@ static struct dmi_system_id asus_quirks[] = {
 	},
 	{
 		.callback = dmi_matched,
+		.ident = ASUSTeK COMPUTER INC. X75VBP,
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
+			DMI_MATCH(DMI_PRODUCT_NAME, X75VBP),
+		},
+		.driver_data = quirk_asus_x401u,
+	},
+	{
+		.callback = dmi_matched,
 		.ident = ASUSTeK COMPUTER INC. 1015E,
 		.matches = {
 			DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
-- 
1.9.0

Re: [PATCH] asus-nb-wmi: set wapf=4 for ASUSTeK COMPUTER INC. X75VBP & X550CA

[poma]

On 27.04.2014 00:12, poma wrote:
> Need to set wapf to 4 for ASUSTeK COMPUTER INC. X75VBP & X550CA, so that the 
> wireless network adapter is enabled.
> 
> References:
> - asus-nb-wmi: set wapf=4 for ASUSTeK COMPUTER INC. X75VBP
> http://marc.info/?l=linux-kernel=139819918125110
> - Ath9k WiFi now disabled by radio killswitch
> https://bugzilla.redhat.com/show_bug.cgi?id=1089731
> 
> Reported-by: poma 
> Reported-by: Andreas Utterberg 
> Tested-by: poma 
> Tested-by: Andreas Utterberg 
> Cc: Fedora kernel development 
> Cc: Andreas Utterberg 
> Cc: Josh Boyer 
> Cc: Stanislaw Gruszka 
> 
> ---
>  drivers/platform/x86/asus-nb-wmi.c | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/drivers/platform/x86/asus-nb-wmi.c 
> b/drivers/platform/x86/asus-nb-wmi.c
> index 563f59e..d3641e0 100644
> --- a/drivers/platform/x86/asus-nb-wmi.c
> +++ b/drivers/platform/x86/asus-nb-wmi.c
> @@ -137,6 +137,15 @@ static struct dmi_system_id asus_quirks[] = {
>   },
>   {
>   .callback = dmi_matched,
> + .ident = "ASUSTeK COMPUTER INC. X550CA",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "X550CA"),
> + },
> + .driver_data = _asus_x401u,
> + },
> + {
> + .callback = dmi_matched,
>   .ident = "ASUSTeK COMPUTER INC. X55A",
>   .matches = {
>   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> @@ -182,6 +191,15 @@ static struct dmi_system_id asus_quirks[] = {
>   },
>   {
>   .callback = dmi_matched,
> + .ident = "ASUSTeK COMPUTER INC. X75VBP",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "X75VBP"),
> + },
> + .driver_data = _asus_x401u,
> + },
> + {
> + .callback = dmi_matched,
>   .ident = "ASUSTeK COMPUTER INC. 1015E",
>   .matches = {
>   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> 

Corentin, care to pick up this one?
https://bugzilla.redhat.com/attachment.cgi?id=892751


poma




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: debug_dma_assert_idle - snd_hda_intel - cpu touching an active dma mapped cacheline

[poma]

]
 [] snd_dma_alloc_pages_fallback+0x62/0x90 [snd_pcm]
 [] snd_malloc_sgbuf_pages+0xf0/0x211 [snd_pcm]
 [] snd_dma_alloc_pages+0x203/0x260 [snd_pcm]
...

However with the 'cachelines-revert.patch', 
related to 
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/lib/dma-debug.c?id=3b7a641,
 
after rebooting 12 times sequentially, everything is OK!
i.e.
kernel-3.15.0-0.rc4.git0.3.fc21.i686 PASSED


poma


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: debug_dma_assert_idle - snd_hda_intel - cpu touching an active dma mapped cacheline

[poma]

] ? trace_hardirqs_on+0xb/0x10
 [c04b16fc] ? trace_hardirqs_on_caller+0x13c/0x1e0
 [c0af3620] ? __do_page_fault+0x5d0/0x5d0
 [c0af363a] do_page_fault+0x1a/0x20
 [c0af0014] error_code+0x6c/0x74
---[ end trace 08b99da35a4e0d8d ]---
Mapped at:
 [c0752ce2] debug_dma_alloc_coherent+0x22/0x70
 [f80f8e90] snd_dma_alloc_pages+0x170/0x260 [snd_pcm]
 [f80f8fe2] snd_dma_alloc_pages_fallback+0x62/0x90 [snd_pcm]
 [f80f93b0] snd_malloc_sgbuf_pages+0xf0/0x211 [snd_pcm]
 [f80f8f23] snd_dma_alloc_pages+0x203/0x260 [snd_pcm]
...

However with the 'cachelines-revert.patch', 
related to 
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/lib/dma-debug.c?id=3b7a641,
 
after rebooting 12 times sequentially, everything is OK!
i.e.
kernel-3.15.0-0.rc4.git0.3.fc21.i686 PASSED


poma


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] asus-nb-wmi: set wapf=4 for ASUSTeK COMPUTER INC. X75VBP X550CA

[poma]

On 27.04.2014 00:12, poma wrote:
 Need to set wapf to 4 for ASUSTeK COMPUTER INC. X75VBP  X550CA, so that the 
 wireless network adapter is enabled.
 
 References:
 - asus-nb-wmi: set wapf=4 for ASUSTeK COMPUTER INC. X75VBP
 http://marc.info/?l=linux-kernelm=139819918125110
 - Ath9k WiFi now disabled by radio killswitch
 https://bugzilla.redhat.com/show_bug.cgi?id=1089731
 
 Reported-by: poma pomidorabelis...@gmail.com
 Reported-by: Andreas Utterberg andreas.utterb...@thundera.se
 Tested-by: poma pomidorabelis...@gmail.com
 Tested-by: Andreas Utterberg andreas.utterb...@thundera.se
 Cc: Fedora kernel development ker...@lists.fedoraproject.org
 Cc: Andreas Utterberg andreas.utterb...@thundera.se
 Cc: Josh Boyer jwbo...@fedoraproject.org
 Cc: Stanislaw Gruszka sgrus...@redhat.com
 
 ---
  drivers/platform/x86/asus-nb-wmi.c | 18 ++
  1 file changed, 18 insertions(+)
 
 diff --git a/drivers/platform/x86/asus-nb-wmi.c 
 b/drivers/platform/x86/asus-nb-wmi.c
 index 563f59e..d3641e0 100644
 --- a/drivers/platform/x86/asus-nb-wmi.c
 +++ b/drivers/platform/x86/asus-nb-wmi.c
 @@ -137,6 +137,15 @@ static struct dmi_system_id asus_quirks[] = {
   },
   {
   .callback = dmi_matched,
 + .ident = ASUSTeK COMPUTER INC. X550CA,
 + .matches = {
 + DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
 + DMI_MATCH(DMI_PRODUCT_NAME, X550CA),
 + },
 + .driver_data = quirk_asus_x401u,
 + },
 + {
 + .callback = dmi_matched,
   .ident = ASUSTeK COMPUTER INC. X55A,
   .matches = {
   DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
 @@ -182,6 +191,15 @@ static struct dmi_system_id asus_quirks[] = {
   },
   {
   .callback = dmi_matched,
 + .ident = ASUSTeK COMPUTER INC. X75VBP,
 + .matches = {
 + DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
 + DMI_MATCH(DMI_PRODUCT_NAME, X75VBP),
 + },
 + .driver_data = quirk_asus_x401u,
 + },
 + {
 + .callback = dmi_matched,
   .ident = ASUSTeK COMPUTER INC. 1015E,
   .matches = {
   DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
 

Corentin, care to pick up this one?
https://bugzilla.redhat.com/attachment.cgi?id=892751


poma




--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: debug_dma_assert_idle - snd_hda_intel - cpu touching an active dma mapped cacheline

[poma]

$ file *
linux-3.15.0-0.rc3.git1.10.fc21.i686: directory
linux-3.15.0-0.rc3.git2.1.fc21.i686:  directory
linux-3.15.0-0.rc3.git3.1.fc21.i686:  directory
$
$ grep -R AZX_DCAPS_CORBRP_SELF_CLEAR 
linux-3.15.0-0.rc3.git3.1.fc21.i686/sound/pci/hda/hda_intel.c:   
AZX_DCAPS_CORBRP_SELF_CLEAR)
linux-3.15.0-0.rc3.git3.1.fc21.i686/sound/pci/hda/hda_controller.c: if 
(!(chip->driver_caps & AZX_DCAPS_CORBRP_SELF_CLEAR)) {
linux-3.15.0-0.rc3.git3.1.fc21.i686/sound/pci/hda/hda_priv.h:#define 
AZX_DCAPS_CORBRP_SELF_CLEAR (1 << 28)  /* CORBRP clears itself after reset 
*/
$ 
$ uname -r
3.15.0-0.rc3.git3.1.fc21.i686  PASSED

Referent commit
ALSA: hda - Suppress CORBRP clear on Nvidia controller chips
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/sound/pci/hda?id=6ba736d

Eye Of The Tiger, Takashi!


poma


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: debug_dma_assert_idle - snd_hda_intel - cpu touching an active dma mapped cacheline

[poma]

$ file *
linux-3.15.0-0.rc3.git1.10.fc21.i686: directory
linux-3.15.0-0.rc3.git2.1.fc21.i686:  directory
linux-3.15.0-0.rc3.git3.1.fc21.i686:  directory
$
$ grep -R AZX_DCAPS_CORBRP_SELF_CLEAR 
linux-3.15.0-0.rc3.git3.1.fc21.i686/sound/pci/hda/hda_intel.c:   
AZX_DCAPS_CORBRP_SELF_CLEAR)
linux-3.15.0-0.rc3.git3.1.fc21.i686/sound/pci/hda/hda_controller.c: if 
(!(chip-driver_caps  AZX_DCAPS_CORBRP_SELF_CLEAR)) {
linux-3.15.0-0.rc3.git3.1.fc21.i686/sound/pci/hda/hda_priv.h:#define 
AZX_DCAPS_CORBRP_SELF_CLEAR (1  28)  /* CORBRP clears itself after reset 
*/
$ 
$ uname -r
3.15.0-0.rc3.git3.1.fc21.i686  PASSED

Referent commit
ALSA: hda - Suppress CORBRP clear on Nvidia controller chips
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/sound/pci/hda?id=6ba736d

Eye Of The Tiger, Takashi!


poma


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] asus-nb-wmi: set wapf=4 for ASUSTeK COMPUTER INC. X75VBP & X550CA

[poma]

Need to set wapf to 4 for ASUSTeK COMPUTER INC. X75VBP & X550CA, so that the 
wireless network adapter is enabled.

References:
- asus-nb-wmi: set wapf=4 for ASUSTeK COMPUTER INC. X75VBP
http://marc.info/?l=linux-kernel=139819918125110
- Ath9k WiFi now disabled by radio killswitch
https://bugzilla.redhat.com/show_bug.cgi?id=1089731

Reported-by: poma 
Reported-by: Andreas Utterberg 
Tested-by: poma 
Tested-by: Andreas Utterberg 
Cc: Fedora kernel development 
Cc: Andreas Utterberg 
Cc: Josh Boyer 
Cc: Stanislaw Gruszka 

---
 drivers/platform/x86/asus-nb-wmi.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/platform/x86/asus-nb-wmi.c 
b/drivers/platform/x86/asus-nb-wmi.c
index 563f59e..d3641e0 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -137,6 +137,15 @@ static struct dmi_system_id asus_quirks[] = {
},
{
.callback = dmi_matched,
+   .ident = "ASUSTeK COMPUTER INC. X550CA",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "X550CA"),
+   },
+   .driver_data = _asus_x401u,
+   },
+   {
+   .callback = dmi_matched,
.ident = "ASUSTeK COMPUTER INC. X55A",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
@@ -182,6 +191,15 @@ static struct dmi_system_id asus_quirks[] = {
},
{
.callback = dmi_matched,
+   .ident = "ASUSTeK COMPUTER INC. X75VBP",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "X75VBP"),
+   },
+   .driver_data = _asus_x401u,
+   },
+   {
+   .callback = dmi_matched,
.ident = "ASUSTeK COMPUTER INC. 1015E",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] asus-nb-wmi: set wapf=4 for ASUSTeK COMPUTER INC. X75VBP X550CA

[poma]

Need to set wapf to 4 for ASUSTeK COMPUTER INC. X75VBP  X550CA, so that the 
wireless network adapter is enabled.

References:
- asus-nb-wmi: set wapf=4 for ASUSTeK COMPUTER INC. X75VBP
http://marc.info/?l=linux-kernelm=139819918125110
- Ath9k WiFi now disabled by radio killswitch
https://bugzilla.redhat.com/show_bug.cgi?id=1089731

Reported-by: poma pomidorabelis...@gmail.com
Reported-by: Andreas Utterberg andreas.utterb...@thundera.se
Tested-by: poma pomidorabelis...@gmail.com
Tested-by: Andreas Utterberg andreas.utterb...@thundera.se
Cc: Fedora kernel development ker...@lists.fedoraproject.org
Cc: Andreas Utterberg andreas.utterb...@thundera.se
Cc: Josh Boyer jwbo...@fedoraproject.org
Cc: Stanislaw Gruszka sgrus...@redhat.com

---
 drivers/platform/x86/asus-nb-wmi.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/platform/x86/asus-nb-wmi.c 
b/drivers/platform/x86/asus-nb-wmi.c
index 563f59e..d3641e0 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -137,6 +137,15 @@ static struct dmi_system_id asus_quirks[] = {
},
{
.callback = dmi_matched,
+   .ident = ASUSTeK COMPUTER INC. X550CA,
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
+   DMI_MATCH(DMI_PRODUCT_NAME, X550CA),
+   },
+   .driver_data = quirk_asus_x401u,
+   },
+   {
+   .callback = dmi_matched,
.ident = ASUSTeK COMPUTER INC. X55A,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
@@ -182,6 +191,15 @@ static struct dmi_system_id asus_quirks[] = {
},
{
.callback = dmi_matched,
+   .ident = ASUSTeK COMPUTER INC. X75VBP,
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
+   DMI_MATCH(DMI_PRODUCT_NAME, X75VBP),
+   },
+   .driver_data = quirk_asus_x401u,
+   },
+   {
+   .callback = dmi_matched,
.ident = ASUSTeK COMPUTER INC. 1015E,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
-- 
1.9.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: debug_dma_assert_idle - snd_hda_intel - cpu touching an active dma mapped cacheline

[poma]

On 23.04.2014 02:53, poma wrote:
> 
> This one comes and goes...
> 
> [ cut here ]
> WARNING: CPU: 2 PID: 521 at lib/dma-debug.c:593
> debug_dma_assert_idle+0x159/0x1d0()
> snd_hda_intel :00:07.0: DMA-API: cpu touching an active dma mapped
> cacheline [cln=0x03019000]
> [ cut here ]
> WARNING: CPU: 3 PID: 927 at lib/dma-debug.c:593
> debug_dma_assert_idle+0x159/0x1d0()
> snd_hda_intel :00:07.0: DMA-API: cpu touching an active dma mapped
> cacheline [cln=0x03019000]
> 
> CPU: 3 PID: 927 Comm: firewalld Not tainted 3.15.0-0.rc2.git1.1.fc21.i686 #1
> 
> Call Trace:
> 
>  [] dump_stack+0x48/0x60
> 
>  [] warn_slowpath_common+0x82/0xa0
> 
>  [] ? debug_dma_assert_idle+0x159/0x1d0
> 
>  [] ? debug_dma_assert_idle+0x159/0x1d0
> 
>  [] warn_slowpath_fmt+0x3e/0x60
> 
>  [] debug_dma_assert_idle+0x159/0x1d0
> 
>  [] ? anon_vma_prepare+0x29/0x140
> 
>  [] do_wp_page+0xce/0x890
> 
>  [] ? ext4_releasepage+0x95/0x130
> 
>  [] handle_mm_fault+0x662/0xb70
> 
>  [] ? ext4_releasepage+0x95/0x130
> 
>  [] __do_page_fault+0x1a7/0x5d0
> 
>  [] ? trace_hardirqs_on_caller+0x13c/0x1e0
> 
>  [] ? __audit_syscall_entry+0x8c/0xe0
> 
>  [] ? trace_hardirqs_on+0xb/0x10
> 
>  [] ? trace_hardirqs_on_caller+0x13c/0x1e0
> 
>  [] ? trace_hardirqs_on_caller+0x13c/0x1e0
> 
>  [] ? __do_page_fault+0x5d0/0x5d0
> 
>  [] do_page_fault+0x1a/0x20
> 
>  [] error_code+0x6c/0x74
> ---[ end trace 0464944e27da06b8 ]---
> Mapped at:
> 
> [] debug_dma_alloc_coherent+0x22/0x70
> 
> [] snd_dma_alloc_pages+0x170/0x260 [snd_pcm]
> 
> [] snd_dma_alloc_pages_fallback+0x62/0x90 [snd_pcm]
> 
> [] snd_malloc_sgbuf_pages+0xf0/0x211 [snd_pcm]
> 
> [] snd_dma_alloc_pages+0x203/0x260 [snd_pcm]
> CPU: 2 PID: 521 Comm: firewalld Tainted: GW
> 3.15.0-0.rc2.git1.1.fc21.i686 #1
> Call Trace:
>  [] dump_stack+0x48/0x60
>  [] warn_slowpath_common+0x82/0xa0
>  [] ? debug_dma_assert_idle+0x159/0x1d0
>  [] ? debug_dma_assert_idle+0x159/0x1d0
>  [] warn_slowpath_fmt+0x3e/0x60
>  [] debug_dma_assert_idle+0x159/0x1d0
>  [] ? anon_vma_prepare+0x29/0x140
>  [] do_wp_page+0xce/0x890
>  [] ? ext4_releasepage+0x95/0x130
>  [] handle_mm_fault+0x662/0xb70
>  [] ? ext4_releasepage+0x95/0x130
>  [] __do_page_fault+0x1a7/0x5d0
>  [] ? __audit_syscall_entry+0x8c/0xe0
>  [] ? trace_hardirqs_on+0xb/0x10
>  [] ? trace_hardirqs_on_caller+0x13c/0x1e0
>  [] ? __do_page_fault+0x5d0/0x5d0
>  [] do_page_fault+0x1a/0x20
>  [] error_code+0x6c/0x74
> ---[ end trace 0464944e27da06b9 ]---
> Mapped at:
>  [] debug_dma_alloc_coherent+0x22/0x70
>  [] snd_dma_alloc_pages+0x170/0x260 [snd_pcm]
>  [] snd_dma_alloc_pages_fallback+0x62/0x90 [snd_pcm]
>  [] snd_malloc_sgbuf_pages+0xf0/0x211 [snd_pcm]
>  [] snd_dma_alloc_pages+0x203/0x260 [snd_pcm]
> 
> 
> https://bugzilla.redhat.com/attachment.cgi?id=888686
> 
> dma debug: account for cachelines and read-only mappings in overlap tracking
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/lib/dma-debug.c?id=3b7a6418c7494b8bf0bf0537ddee1dedbca10f51
> 
> Are these two in some relation?

Yep.

3.15.0-0.rc2.git1.1.fc21.x86_64  PASSED
3.15.0-0.rc2.git1.1.fc21.i686FAILED
3.15.0-0.rc2.git1.2.fc21.i686PASSED <-

3.15.0-0.rc2.git1.2.fc21.i686 is
3.15.0-0.rc2.git1.1.fc21.i686 with reverted linux-next git commit 3b7a641
"dma debug: account for cachelines and read-only mappings in overlap
tracking"
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/lib/dma-debug.c?id=3b7a641


Information for build kernel-3.15.0-0.rc2.git1.1.fc21
http://koji.fedoraproject.org/koji/buildinfo?buildID=512446


poma

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: debug_dma_assert_idle - snd_hda_intel - cpu touching an active dma mapped cacheline

[poma]

This one comes and goes...

[ cut here ]
WARNING: CPU: 2 PID: 521 at lib/dma-debug.c:593
debug_dma_assert_idle+0x159/0x1d0()
snd_hda_intel :00:07.0: DMA-API: cpu touching an active dma mapped
cacheline [cln=0x03019000]
[ cut here ]
WARNING: CPU: 3 PID: 927 at lib/dma-debug.c:593
debug_dma_assert_idle+0x159/0x1d0()
snd_hda_intel :00:07.0: DMA-API: cpu touching an active dma mapped
cacheline [cln=0x03019000]

CPU: 3 PID: 927 Comm: firewalld Not tainted 3.15.0-0.rc2.git1.1.fc21.i686 #1

Call Trace:

 [] dump_stack+0x48/0x60

 [] warn_slowpath_common+0x82/0xa0

 [] ? debug_dma_assert_idle+0x159/0x1d0

 [] ? debug_dma_assert_idle+0x159/0x1d0

 [] warn_slowpath_fmt+0x3e/0x60

 [] debug_dma_assert_idle+0x159/0x1d0

 [] ? anon_vma_prepare+0x29/0x140

 [] do_wp_page+0xce/0x890

 [] ? ext4_releasepage+0x95/0x130

 [] handle_mm_fault+0x662/0xb70

 [] ? ext4_releasepage+0x95/0x130

 [] __do_page_fault+0x1a7/0x5d0

 [] ? trace_hardirqs_on_caller+0x13c/0x1e0

 [] ? __audit_syscall_entry+0x8c/0xe0

 [] ? trace_hardirqs_on+0xb/0x10

 [] ? trace_hardirqs_on_caller+0x13c/0x1e0

 [] ? trace_hardirqs_on_caller+0x13c/0x1e0

 [] ? __do_page_fault+0x5d0/0x5d0

 [] do_page_fault+0x1a/0x20

 [] error_code+0x6c/0x74
---[ end trace 0464944e27da06b8 ]---
Mapped at:

[] debug_dma_alloc_coherent+0x22/0x70

[] snd_dma_alloc_pages+0x170/0x260 [snd_pcm]

[] snd_dma_alloc_pages_fallback+0x62/0x90 [snd_pcm]

[] snd_malloc_sgbuf_pages+0xf0/0x211 [snd_pcm]

[] snd_dma_alloc_pages+0x203/0x260 [snd_pcm]
CPU: 2 PID: 521 Comm: firewalld Tainted: GW
3.15.0-0.rc2.git1.1.fc21.i686 #1
Call Trace:
 [] dump_stack+0x48/0x60
 [] warn_slowpath_common+0x82/0xa0
 [] ? debug_dma_assert_idle+0x159/0x1d0
 [] ? debug_dma_assert_idle+0x159/0x1d0
 [] warn_slowpath_fmt+0x3e/0x60
 [] debug_dma_assert_idle+0x159/0x1d0
 [] ? anon_vma_prepare+0x29/0x140
 [] do_wp_page+0xce/0x890
 [] ? ext4_releasepage+0x95/0x130
 [] handle_mm_fault+0x662/0xb70
 [] ? ext4_releasepage+0x95/0x130
 [] __do_page_fault+0x1a7/0x5d0
 [] ? __audit_syscall_entry+0x8c/0xe0
 [] ? trace_hardirqs_on+0xb/0x10
 [] ? trace_hardirqs_on_caller+0x13c/0x1e0
 [] ? __do_page_fault+0x5d0/0x5d0
 [] do_page_fault+0x1a/0x20
 [] error_code+0x6c/0x74
---[ end trace 0464944e27da06b9 ]---
Mapped at:
 [] debug_dma_alloc_coherent+0x22/0x70
 [] snd_dma_alloc_pages+0x170/0x260 [snd_pcm]
 [] snd_dma_alloc_pages_fallback+0x62/0x90 [snd_pcm]
 [] snd_malloc_sgbuf_pages+0xf0/0x211 [snd_pcm]
 [] snd_dma_alloc_pages+0x203/0x260 [snd_pcm]


https://bugzilla.redhat.com/attachment.cgi?id=888686

dma debug: account for cachelines and read-only mappings in overlap tracking
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/lib/dma-debug.c?id=3b7a6418c7494b8bf0bf0537ddee1dedbca10f51

Are these two in some relation?


poma


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

asus-nb-wmi: set wapf=4 for ASUSTeK COMPUTER INC. X75VBP

[poma]

Ahoy!

Need to set wapf to 4 for ASUSTeK COMPUTER INC. X75VBP, so that
the device is enabled.

The corresponding /sys/class/dmi/id/* values via dmesg:
DMI: ASUSTeK COMPUTER INC. X75VBP/X75VBP, BIOS X75VBP.304 06/04/2013

Tested with WAPF values 0, 1 and 4.
The values 1 and 4 have the same effect regarding wireless network
adapter enablement.
A value of 0 has no effect.
The corresponding command line:
Kernel command line: BOOT_IMAGE=/isolinux/vmlinuz0
root=live:LABEL=Fedora-Live-Xfce-x86_64-rawhide- ro rd.live.image
selinux=0 biosdevname=0 asus-nb-wmi.wapf=4

rfkill list - vulgaris:
1: asus-wlan: Wireless LAN
Soft blocked: no
Hard blocked: no
2: asus-bluetooth: Bluetooth
Soft blocked: no
Hard blocked: no
3: phy0: Wireless LAN
Soft blocked: no
Hard blocked: yes
4: hci0: Bluetooth
Soft blocked: no
Hard blocked: no

rfkill list - asus-nb-wmi.wapf=1,
  asus-nb-wmi.wapf=4:
0: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
2: asus-wlan: Wireless LAN
Soft blocked: no
Hard blocked: no
3: asus-bluetooth: Bluetooth
Soft blocked: no
Hard blocked: no

Regardless of the values ​​of the WAPF parameter,
 key combination does not give any results,
i.e. does not toggles The Internal Wireless LAN ON or OFF.
Also the WLAN LED is always ON, no matter what.


poma


diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
index 563f59e..674793d 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -182,6 +182,15 @@ static struct dmi_system_id asus_quirks[] = {
 	},
 	{
 		.callback = dmi_matched,
+		.ident = "ASUSTeK COMPUTER INC. X75VBP",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "X75VBP"),
+		},
+		.driver_data = _asus_x401u,
+	},
+	{
+		.callback = dmi_matched,
 		.ident = "ASUSTeK COMPUTER INC. 1015E",
 		.matches = {
 			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),

asus-nb-wmi: set wapf=4 for ASUSTeK COMPUTER INC. X75VBP

[poma]

Ahoy!

Need to set wapf to 4 for ASUSTeK COMPUTER INC. X75VBP, so that
the device is enabled.

The corresponding /sys/class/dmi/id/* values via dmesg:
DMI: ASUSTeK COMPUTER INC. X75VBP/X75VBP, BIOS X75VBP.304 06/04/2013

Tested with WAPF values 0, 1 and 4.
The values 1 and 4 have the same effect regarding wireless network
adapter enablement.
A value of 0 has no effect.
The corresponding command line:
Kernel command line: BOOT_IMAGE=/isolinux/vmlinuz0
root=live:LABEL=Fedora-Live-Xfce-x86_64-rawhide- ro rd.live.image
selinux=0 biosdevname=0 asus-nb-wmi.wapf=4

rfkill list - vulgaris:
1: asus-wlan: Wireless LAN
Soft blocked: no
Hard blocked: no
2: asus-bluetooth: Bluetooth
Soft blocked: no
Hard blocked: no
3: phy0: Wireless LAN
Soft blocked: no
Hard blocked: yes
4: hci0: Bluetooth
Soft blocked: no
Hard blocked: no

rfkill list - asus-nb-wmi.wapf=1,
  asus-nb-wmi.wapf=4:
0: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
2: asus-wlan: Wireless LAN
Soft blocked: no
Hard blocked: no
3: asus-bluetooth: Bluetooth
Soft blocked: no
Hard blocked: no

Regardless of the values ​​of the WAPF parameter,
FnF2 key combination does not give any results,
i.e. does not toggles The Internal Wireless LAN ON or OFF.
Also the WLAN LED is always ON, no matter what.


poma


diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
index 563f59e..674793d 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -182,6 +182,15 @@ static struct dmi_system_id asus_quirks[] = {
 	},
 	{
 		.callback = dmi_matched,
+		.ident = ASUSTeK COMPUTER INC. X75VBP,
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
+			DMI_MATCH(DMI_PRODUCT_NAME, X75VBP),
+		},
+		.driver_data = quirk_asus_x401u,
+	},
+	{
+		.callback = dmi_matched,
 		.ident = ASUSTeK COMPUTER INC. 1015E,
 		.matches = {
 			DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),

Re: debug_dma_assert_idle - snd_hda_intel - cpu touching an active dma mapped cacheline

[poma]

This one comes and goes...

[ cut here ]
WARNING: CPU: 2 PID: 521 at lib/dma-debug.c:593
debug_dma_assert_idle+0x159/0x1d0()
snd_hda_intel :00:07.0: DMA-API: cpu touching an active dma mapped
cacheline [cln=0x03019000]
[ cut here ]
WARNING: CPU: 3 PID: 927 at lib/dma-debug.c:593
debug_dma_assert_idle+0x159/0x1d0()
snd_hda_intel :00:07.0: DMA-API: cpu touching an active dma mapped
cacheline [cln=0x03019000]

CPU: 3 PID: 927 Comm: firewalld Not tainted 3.15.0-0.rc2.git1.1.fc21.i686 #1

Call Trace:

 [c0ae29dd] dump_stack+0x48/0x60

 [c0454402] warn_slowpath_common+0x82/0xa0

 [c0750e09] ? debug_dma_assert_idle+0x159/0x1d0

 [c0750e09] ? debug_dma_assert_idle+0x159/0x1d0

 [c045445e] warn_slowpath_fmt+0x3e/0x60

 [c0750e09] debug_dma_assert_idle+0x159/0x1d0

 [c0586189] ? anon_vma_prepare+0x29/0x140

 [c057a5be] do_wp_page+0xce/0x890

 [c0640065] ? ext4_releasepage+0x95/0x130

 [c057cbc2] handle_mm_fault+0x662/0xb70

 [c0640065] ? ext4_releasepage+0x95/0x130

 [c0aee997] __do_page_fault+0x1a7/0x5d0

 [c04adcac] ? trace_hardirqs_on_caller+0x13c/0x1e0

 [c04ff83c] ? __audit_syscall_entry+0x8c/0xe0

 [c04add5b] ? trace_hardirqs_on+0xb/0x10

 [c04adcac] ? trace_hardirqs_on_caller+0x13c/0x1e0

 [c04adcac] ? trace_hardirqs_on_caller+0x13c/0x1e0

 [c0aeedc0] ? __do_page_fault+0x5d0/0x5d0

 [c0aeedda] do_page_fault+0x1a/0x20

 [c0aeb7b4] error_code+0x6c/0x74
---[ end trace 0464944e27da06b8 ]---
Mapped at:

[c074eeb2] debug_dma_alloc_coherent+0x22/0x70

[f839de90] snd_dma_alloc_pages+0x170/0x260 [snd_pcm]

[f839dfe2] snd_dma_alloc_pages_fallback+0x62/0x90 [snd_pcm]

[f839e3b0] snd_malloc_sgbuf_pages+0xf0/0x211 [snd_pcm]

[f839df23] snd_dma_alloc_pages+0x203/0x260 [snd_pcm]
CPU: 2 PID: 521 Comm: firewalld Tainted: GW
3.15.0-0.rc2.git1.1.fc21.i686 #1
Call Trace:
 [c0ae29dd] dump_stack+0x48/0x60
 [c0454402] warn_slowpath_common+0x82/0xa0
 [c0750e09] ? debug_dma_assert_idle+0x159/0x1d0
 [c0750e09] ? debug_dma_assert_idle+0x159/0x1d0
 [c045445e] warn_slowpath_fmt+0x3e/0x60
 [c0750e09] debug_dma_assert_idle+0x159/0x1d0
 [c0586189] ? anon_vma_prepare+0x29/0x140
 [c057a5be] do_wp_page+0xce/0x890
 [c0640065] ? ext4_releasepage+0x95/0x130
 [c057cbc2] handle_mm_fault+0x662/0xb70
 [c0640065] ? ext4_releasepage+0x95/0x130
 [c0aee997] __do_page_fault+0x1a7/0x5d0
 [c04ff83c] ? __audit_syscall_entry+0x8c/0xe0
 [c04add5b] ? trace_hardirqs_on+0xb/0x10
 [c04adcac] ? trace_hardirqs_on_caller+0x13c/0x1e0
 [c0aeedc0] ? __do_page_fault+0x5d0/0x5d0
 [c0aeedda] do_page_fault+0x1a/0x20
 [c0aeb7b4] error_code+0x6c/0x74
---[ end trace 0464944e27da06b9 ]---
Mapped at:
 [c074eeb2] debug_dma_alloc_coherent+0x22/0x70
 [f839de90] snd_dma_alloc_pages+0x170/0x260 [snd_pcm]
 [f839dfe2] snd_dma_alloc_pages_fallback+0x62/0x90 [snd_pcm]
 [f839e3b0] snd_malloc_sgbuf_pages+0xf0/0x211 [snd_pcm]
 [f839df23] snd_dma_alloc_pages+0x203/0x260 [snd_pcm]


https://bugzilla.redhat.com/attachment.cgi?id=888686

dma debug: account for cachelines and read-only mappings in overlap tracking
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/lib/dma-debug.c?id=3b7a6418c7494b8bf0bf0537ddee1dedbca10f51

Are these two in some relation?


poma


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: debug_dma_assert_idle - snd_hda_intel - cpu touching an active dma mapped cacheline

[poma]

On 23.04.2014 02:53, poma wrote:
 
 This one comes and goes...
 
 [ cut here ]
 WARNING: CPU: 2 PID: 521 at lib/dma-debug.c:593
 debug_dma_assert_idle+0x159/0x1d0()
 snd_hda_intel :00:07.0: DMA-API: cpu touching an active dma mapped
 cacheline [cln=0x03019000]
 [ cut here ]
 WARNING: CPU: 3 PID: 927 at lib/dma-debug.c:593
 debug_dma_assert_idle+0x159/0x1d0()
 snd_hda_intel :00:07.0: DMA-API: cpu touching an active dma mapped
 cacheline [cln=0x03019000]
 
 CPU: 3 PID: 927 Comm: firewalld Not tainted 3.15.0-0.rc2.git1.1.fc21.i686 #1
 
 Call Trace:
 
  [c0ae29dd] dump_stack+0x48/0x60
 
  [c0454402] warn_slowpath_common+0x82/0xa0
 
  [c0750e09] ? debug_dma_assert_idle+0x159/0x1d0
 
  [c0750e09] ? debug_dma_assert_idle+0x159/0x1d0
 
  [c045445e] warn_slowpath_fmt+0x3e/0x60
 
  [c0750e09] debug_dma_assert_idle+0x159/0x1d0
 
  [c0586189] ? anon_vma_prepare+0x29/0x140
 
  [c057a5be] do_wp_page+0xce/0x890
 
  [c0640065] ? ext4_releasepage+0x95/0x130
 
  [c057cbc2] handle_mm_fault+0x662/0xb70
 
  [c0640065] ? ext4_releasepage+0x95/0x130
 
  [c0aee997] __do_page_fault+0x1a7/0x5d0
 
  [c04adcac] ? trace_hardirqs_on_caller+0x13c/0x1e0
 
  [c04ff83c] ? __audit_syscall_entry+0x8c/0xe0
 
  [c04add5b] ? trace_hardirqs_on+0xb/0x10
 
  [c04adcac] ? trace_hardirqs_on_caller+0x13c/0x1e0
 
  [c04adcac] ? trace_hardirqs_on_caller+0x13c/0x1e0
 
  [c0aeedc0] ? __do_page_fault+0x5d0/0x5d0
 
  [c0aeedda] do_page_fault+0x1a/0x20
 
  [c0aeb7b4] error_code+0x6c/0x74
 ---[ end trace 0464944e27da06b8 ]---
 Mapped at:
 
 [c074eeb2] debug_dma_alloc_coherent+0x22/0x70
 
 [f839de90] snd_dma_alloc_pages+0x170/0x260 [snd_pcm]
 
 [f839dfe2] snd_dma_alloc_pages_fallback+0x62/0x90 [snd_pcm]
 
 [f839e3b0] snd_malloc_sgbuf_pages+0xf0/0x211 [snd_pcm]
 
 [f839df23] snd_dma_alloc_pages+0x203/0x260 [snd_pcm]
 CPU: 2 PID: 521 Comm: firewalld Tainted: GW
 3.15.0-0.rc2.git1.1.fc21.i686 #1
 Call Trace:
  [c0ae29dd] dump_stack+0x48/0x60
  [c0454402] warn_slowpath_common+0x82/0xa0
  [c0750e09] ? debug_dma_assert_idle+0x159/0x1d0
  [c0750e09] ? debug_dma_assert_idle+0x159/0x1d0
  [c045445e] warn_slowpath_fmt+0x3e/0x60
  [c0750e09] debug_dma_assert_idle+0x159/0x1d0
  [c0586189] ? anon_vma_prepare+0x29/0x140
  [c057a5be] do_wp_page+0xce/0x890
  [c0640065] ? ext4_releasepage+0x95/0x130
  [c057cbc2] handle_mm_fault+0x662/0xb70
  [c0640065] ? ext4_releasepage+0x95/0x130
  [c0aee997] __do_page_fault+0x1a7/0x5d0
  [c04ff83c] ? __audit_syscall_entry+0x8c/0xe0
  [c04add5b] ? trace_hardirqs_on+0xb/0x10
  [c04adcac] ? trace_hardirqs_on_caller+0x13c/0x1e0
  [c0aeedc0] ? __do_page_fault+0x5d0/0x5d0
  [c0aeedda] do_page_fault+0x1a/0x20
  [c0aeb7b4] error_code+0x6c/0x74
 ---[ end trace 0464944e27da06b9 ]---
 Mapped at:
  [c074eeb2] debug_dma_alloc_coherent+0x22/0x70
  [f839de90] snd_dma_alloc_pages+0x170/0x260 [snd_pcm]
  [f839dfe2] snd_dma_alloc_pages_fallback+0x62/0x90 [snd_pcm]
  [f839e3b0] snd_malloc_sgbuf_pages+0xf0/0x211 [snd_pcm]
  [f839df23] snd_dma_alloc_pages+0x203/0x260 [snd_pcm]
 
 
 https://bugzilla.redhat.com/attachment.cgi?id=888686
 
 dma debug: account for cachelines and read-only mappings in overlap tracking
 https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/lib/dma-debug.c?id=3b7a6418c7494b8bf0bf0537ddee1dedbca10f51
 
 Are these two in some relation?

Yep.

3.15.0-0.rc2.git1.1.fc21.x86_64  PASSED
3.15.0-0.rc2.git1.1.fc21.i686FAILED
3.15.0-0.rc2.git1.2.fc21.i686PASSED -

3.15.0-0.rc2.git1.2.fc21.i686 is
3.15.0-0.rc2.git1.1.fc21.i686 with reverted linux-next git commit 3b7a641
dma debug: account for cachelines and read-only mappings in overlap
tracking
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/lib/dma-debug.c?id=3b7a641


Information for build kernel-3.15.0-0.rc2.git1.1.fc21
http://koji.fedoraproject.org/koji/buildinfo?buildID=512446


poma

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: debug_dma_assert_idle - snd_hda_intel - cpu touching an active dma mapped cacheline

[poma]

On 17.04.2014 09:40, Clemens Ladisch wrote:
> poma wrote:
>> Sound whispers,
> 
> ???
> 
>>  WARNING: CPU: 3 PID: 900 at lib/dma-debug.c:593 
>> debug_dma_assert_idle+0x159/0x1d0()
>>  snd_hda_intel :00:07.0: DMA-API: cpu touching an active dma mapped 
>> cacheline [cln=0x03014000]
>>  ...
>>  Mapped at:
>>   [] debug_dma_alloc_coherent+0x22/0x70
> 
> "Coherent" means "touching DMA mappings is allowed".
> Why does dma-debug complain about that?
> 
> 
> Regards,
> Clemens
> 

Thanks for comment.
Waiting for rc2 to be sure!


poma


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: debug_dma_assert_idle - snd_hda_intel - cpu touching an active dma mapped cacheline

[poma]

On 17.04.2014 09:40, Clemens Ladisch wrote:
 poma wrote:
 Sound whispers,
 
 ???
 
  WARNING: CPU: 3 PID: 900 at lib/dma-debug.c:593 
 debug_dma_assert_idle+0x159/0x1d0()
  snd_hda_intel :00:07.0: DMA-API: cpu touching an active dma mapped 
 cacheline [cln=0x03014000]
  ...
  Mapped at:
   [c074ec12] debug_dma_alloc_coherent+0x22/0x70
 
 Coherent means touching DMA mappings is allowed.
 Why does dma-debug complain about that?
 
 
 Regards,
 Clemens
 

Thanks for comment.
Waiting for rc2 to be sure!


poma


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/