Re: O_CLOFORK use case
On Mon, 2019-06-03 at 08:24 -0700, Joshua Hudson wrote:
> I ran headlong into the use case for O_CLOFORK and got into a locking
> debate over it.
>
> The actual use case involves squashing a thread race between two
> threads. If a file is opened for write in one thread with O_CLOEXEC
> while another thread calls fork(), a race condition can happen where
> the thread that closes the handle misses the out of disk error because
> the child process closed the handle last inside execve().
>
> The decades old idiom for replacing config files isn't safe in
> multi-threaded code. Yipe.
>
> int h = open(".configfile~", O_WRONY | O_EXCL | O_CLOEXEC, 0666);
> if (h < 0) { perror(".configfile"); return 1; }
> ssize_t delta = 0;
> while ((delta = write(h, newconfigdata, newconfiglen)) > 0) {
> newconfigdata += delta;
> newconfiglen -= delta;
> }
> if (delta < 0) { perror(".configfile"); return 1; }
> if (close(h)) { perror(".configfile"); return 1; }
> rename(".configfile~", ".configfile");
>
> To fix it, we have to put locks around close() and fork()/vfork(). Ugh.
fsync() / fdatasync() before close() should fix it, non?
I was under the impression that any of those two became mandatory when
ext4 came along.
--
Mihai Donțu
Re: [RFC PATCH V2 00/11] Intel EPT-Based Sub-page Protection Support
Hi Paolo, On Fri, 2018-11-30 at 11:07 +0100, Paolo Bonzini wrote: > On 30/11/18 08:52, Zhang Yi wrote: > > Here is a patch-series which adding EPT-Based Sub-page Write Protection > > Support. > > > > Introduction: > > > > EPT-Based Sub-page Write Protection referred to as SPP, it is a capability > > which > > allow Virtual Machine Monitors(VMM) to specify write-permission for guest > > physical memory at a sub-page(128 byte) granularity. When this capability > > is > > utilized, the CPU enforces write-access permissions for sub-page regions of > > 4K > > pages as specified by the VMM. EPT-based sub-page permissions is intended to > > enable fine-grained memory write enforcement by a VMM for security(guest OS > > monitoring) and usages such as device virtualization and memory check-point. > > > > SPPT is active when the "sub-page write protection" VM-execution control is > > 1. > > SPPT looks up the guest physical addresses to derive a 64 bit "sub-page > > permission" value containing sub-page write permissions. The lookup from > > guest-physical addresses to the sub-page region permissions is determined > > by a > > set of SPPT paging structures. > > > > When the "sub-page write protection" VM-execution control is 1, the SPPT is > > used > > to lookup write permission bits for the 128 byte sub-page regions > > containing in > > the 4KB guest physical page. EPT specifies the 4KB page level privileges > > that > > software is allowed when accessing the guest physical address, whereas SPPT > > defines the write permissions for software at the 128 byte granularity > > regions > > within a 4KB page. Write accesses prevented due to sub-page permissions > > looked > > up via SPPT are reported as EPT violation VM exits. Similar to EPT, a > > logical > > processor uses SPPT to lookup sub-page region write permissions for > > guest-physical addresses only when those addresses are used to access > > memory. > > Hi, > > I think the right thing to do here would be to first get VM > introspection in KVM, as SPP is mostly an introspection feature and it > should be controller by the introspector rather than the KVM userspace. > > Mihai, if you resubmit, I promise that I will look at it promptly. I'm currently traveling until Wednesday, but when I'll get into the office I will see about preparing a new patch set and send it to the list before Christmas. Regards, -- Mihai Donțu
Re: [RFC PATCH V2 00/11] Intel EPT-Based Sub-page Protection Support
Hi Paolo, On Fri, 2018-11-30 at 11:07 +0100, Paolo Bonzini wrote: > On 30/11/18 08:52, Zhang Yi wrote: > > Here is a patch-series which adding EPT-Based Sub-page Write Protection > > Support. > > > > Introduction: > > > > EPT-Based Sub-page Write Protection referred to as SPP, it is a capability > > which > > allow Virtual Machine Monitors(VMM) to specify write-permission for guest > > physical memory at a sub-page(128 byte) granularity. When this capability > > is > > utilized, the CPU enforces write-access permissions for sub-page regions of > > 4K > > pages as specified by the VMM. EPT-based sub-page permissions is intended to > > enable fine-grained memory write enforcement by a VMM for security(guest OS > > monitoring) and usages such as device virtualization and memory check-point. > > > > SPPT is active when the "sub-page write protection" VM-execution control is > > 1. > > SPPT looks up the guest physical addresses to derive a 64 bit "sub-page > > permission" value containing sub-page write permissions. The lookup from > > guest-physical addresses to the sub-page region permissions is determined > > by a > > set of SPPT paging structures. > > > > When the "sub-page write protection" VM-execution control is 1, the SPPT is > > used > > to lookup write permission bits for the 128 byte sub-page regions > > containing in > > the 4KB guest physical page. EPT specifies the 4KB page level privileges > > that > > software is allowed when accessing the guest physical address, whereas SPPT > > defines the write permissions for software at the 128 byte granularity > > regions > > within a 4KB page. Write accesses prevented due to sub-page permissions > > looked > > up via SPPT are reported as EPT violation VM exits. Similar to EPT, a > > logical > > processor uses SPPT to lookup sub-page region write permissions for > > guest-physical addresses only when those addresses are used to access > > memory. > > Hi, > > I think the right thing to do here would be to first get VM > introspection in KVM, as SPP is mostly an introspection feature and it > should be controller by the introspector rather than the KVM userspace. > > Mihai, if you resubmit, I promise that I will look at it promptly. I'm currently traveling until Wednesday, but when I'll get into the office I will see about preparing a new patch set and send it to the list before Christmas. Regards, -- Mihai Donțu
Re: [PATCH] platform/x86: wmi: Do not mix pages and kmalloc
Hi Darren, On Fri, 2018-06-22 at 16:27 -0700, Darren Hart wrote: > On Thu, Jun 21, 2018 at 01:24:34AM +, mario.limoncie...@dell.com wrote: > > > -Original Message- > > > From: Darren Hart [mailto:dvh...@infradead.org] > > > Sent: Wednesday, June 20, 2018 7:17 PM > > > To: Kees Cook > > > Cc: LKML; Andy Shevchenko; Platform Driver; Mihai Donțu; Limonciello, > > > Mario > > > Subject: Re: [PATCH] platform/x86: wmi: Do not mix pages and kmalloc > > > > > > On Wed, Jun 20, 2018 at 04:43:14PM -0700, Kees Cook wrote: > > > > On Wed, Jun 20, 2018 at 4:37 PM, Darren Hart > > > > wrote: > > > > > On Wed, Jun 20, 2018 at 02:31:41PM -0700, Kees Cook wrote: > > > > > > The probe handler_data was being allocated with __get_free_pages() > > > > > > for no reason I could find. The error path was using kfree(). Since > > > > > > > > > > v4 of Mario's series used kmalloc: > > > > > https://patchwork.kernel.org/patch/9985827/ > > > > > > > > > > This was changed in v10 to use __get_free_pages: > > > > > https://patchwork.kernel.org/patch/10018023/ > > > > > > > > > > But... I'm not finding the discussion that led to this change > > > > > Mario, > > > > > do you recall? Something about contiguous memory? We had a similar > > > > > discussion on an earlier series: > > > > > > > > > > https://patchwork.kernel.org/patch/9975277/ > > > > > > > > FWIW, kmalloc gets you contiguous memory... > > > > > > Yeah, I'm not finding a valid reason to use __get_free_pages over kmalloc > > > in > > > this case. I'll give Mario a chance to respond in case I'm just missing > > > something, but otherwise will plan to apply this patch. > > > > I think it was for contiguous memory, so if kmalloc is giving that I agree > > no need to keep __get_free_pages instead. > > > > Acked-by: Mario Limonciello > > Confirmed, kmalloc in physically contiguous. > > Queued up, and tagged for stable. Thanks everyone. > Would it be possible to queue this for 4.18 or is it too late? I just noticed it has not reached 4.17.12 either. Thanks, -- Mihai Donțu
Re: [PATCH] platform/x86: wmi: Do not mix pages and kmalloc
Hi Darren, On Fri, 2018-06-22 at 16:27 -0700, Darren Hart wrote: > On Thu, Jun 21, 2018 at 01:24:34AM +, mario.limoncie...@dell.com wrote: > > > -Original Message- > > > From: Darren Hart [mailto:dvh...@infradead.org] > > > Sent: Wednesday, June 20, 2018 7:17 PM > > > To: Kees Cook > > > Cc: LKML; Andy Shevchenko; Platform Driver; Mihai Donțu; Limonciello, > > > Mario > > > Subject: Re: [PATCH] platform/x86: wmi: Do not mix pages and kmalloc > > > > > > On Wed, Jun 20, 2018 at 04:43:14PM -0700, Kees Cook wrote: > > > > On Wed, Jun 20, 2018 at 4:37 PM, Darren Hart > > > > wrote: > > > > > On Wed, Jun 20, 2018 at 02:31:41PM -0700, Kees Cook wrote: > > > > > > The probe handler_data was being allocated with __get_free_pages() > > > > > > for no reason I could find. The error path was using kfree(). Since > > > > > > > > > > v4 of Mario's series used kmalloc: > > > > > https://patchwork.kernel.org/patch/9985827/ > > > > > > > > > > This was changed in v10 to use __get_free_pages: > > > > > https://patchwork.kernel.org/patch/10018023/ > > > > > > > > > > But... I'm not finding the discussion that led to this change > > > > > Mario, > > > > > do you recall? Something about contiguous memory? We had a similar > > > > > discussion on an earlier series: > > > > > > > > > > https://patchwork.kernel.org/patch/9975277/ > > > > > > > > FWIW, kmalloc gets you contiguous memory... > > > > > > Yeah, I'm not finding a valid reason to use __get_free_pages over kmalloc > > > in > > > this case. I'll give Mario a chance to respond in case I'm just missing > > > something, but otherwise will plan to apply this patch. > > > > I think it was for contiguous memory, so if kmalloc is giving that I agree > > no need to keep __get_free_pages instead. > > > > Acked-by: Mario Limonciello > > Confirmed, kmalloc in physically contiguous. > > Queued up, and tagged for stable. Thanks everyone. > Would it be possible to queue this for 4.18 or is it too late? I just noticed it has not reached 4.17.12 either. Thanks, -- Mihai Donțu
Re: wmi: usercopy: Kernel memory overwrite attempt detected to spans multiple pages (offset 0, size 4104)
On Sun, 2018-06-17 at 10:36 -0700, Kees Cook wrote:
> On Sat, Jun 16, 2018 at 3:04 PM, Mihai Donțu wrote:
> > On Sun, 2018-06-17 at 00:01 +0300, Mihai Donțu wrote:
> > > While trying to adjust the keyboard backlight mode, I hit this BUG:
> > >
> > > Jun 16 22:16:07 mdontu-l kernel: usercopy: Kernel memory overwrite
> > > attempt detected to spans multiple pages (offset 0, size 4104)!
>
> CONFIG_HARDENED_USERCOPY_PAGESPAN=y is really only useful for
> debugging special cases. For now, I recommend leaving it disabled,
> since there are a lot of cases it still trips over.
>
> > I eventually sprinkled some printk-s and got this:
> >
> > 855 if (copy_from_user(buf, input, wblock->req_buf_size)) {
> > 856 dev_dbg(>dev.dev, "Copy %llu from user
> > failed\n",
> > 857 wblock->req_buf_size);
> > 858 ret = -EFAULT;
> > 859 goto out_ioctl;
> > 860 }
>
> However, since you tracked this one down, I think this would be fixed
> by adjusting the handler_data allocation:
>
>
> diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
> index 8e3d0146ff8c..ea6bf98f197a 100644
> --- a/drivers/platform/x86/wmi.c
> +++ b/drivers/platform/x86/wmi.c
> @@ -918,8 +918,8 @@ static int wmi_dev_probe(struct device *dev)
> }
>
> count = get_order(wblock->req_buf_size);
> - wblock->handler_data = (void *)__get_free_pages(GFP_KERNEL,
> - count);
> + wblock->handler_data = (void *)
> + __get_free_pages(GFP_KERNEL | __GFP_COMP, count);
> if (!wblock->handler_data) {
> ret = -ENOMEM;
> goto probe_failure;
>
Your patch works OK for me, thank you. The libsmbios tool, however, not
so much. It appears to be behind latest developments.
# echo "+keyboard" >/sys/class/leds/dell\:\:kbd_backlight/start_triggers
is all that is needed today.
Regards,
> But in looking further, I don't know why this is using
> __get_free_pages() instead of kmalloc? In fact, there is a kfree() in
> the error path, which looks wrong:
>
> kfree(wblock->handler_data);
>
> I think this should just be converted to using kmalloc/kfree everywhere.
--
Mihai Donțu
Re: wmi: usercopy: Kernel memory overwrite attempt detected to spans multiple pages (offset 0, size 4104)
On Sun, 2018-06-17 at 10:36 -0700, Kees Cook wrote:
> On Sat, Jun 16, 2018 at 3:04 PM, Mihai Donțu wrote:
> > On Sun, 2018-06-17 at 00:01 +0300, Mihai Donțu wrote:
> > > While trying to adjust the keyboard backlight mode, I hit this BUG:
> > >
> > > Jun 16 22:16:07 mdontu-l kernel: usercopy: Kernel memory overwrite
> > > attempt detected to spans multiple pages (offset 0, size 4104)!
>
> CONFIG_HARDENED_USERCOPY_PAGESPAN=y is really only useful for
> debugging special cases. For now, I recommend leaving it disabled,
> since there are a lot of cases it still trips over.
>
> > I eventually sprinkled some printk-s and got this:
> >
> > 855 if (copy_from_user(buf, input, wblock->req_buf_size)) {
> > 856 dev_dbg(>dev.dev, "Copy %llu from user
> > failed\n",
> > 857 wblock->req_buf_size);
> > 858 ret = -EFAULT;
> > 859 goto out_ioctl;
> > 860 }
>
> However, since you tracked this one down, I think this would be fixed
> by adjusting the handler_data allocation:
>
>
> diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
> index 8e3d0146ff8c..ea6bf98f197a 100644
> --- a/drivers/platform/x86/wmi.c
> +++ b/drivers/platform/x86/wmi.c
> @@ -918,8 +918,8 @@ static int wmi_dev_probe(struct device *dev)
> }
>
> count = get_order(wblock->req_buf_size);
> - wblock->handler_data = (void *)__get_free_pages(GFP_KERNEL,
> - count);
> + wblock->handler_data = (void *)
> + __get_free_pages(GFP_KERNEL | __GFP_COMP, count);
> if (!wblock->handler_data) {
> ret = -ENOMEM;
> goto probe_failure;
>
Your patch works OK for me, thank you. The libsmbios tool, however, not
so much. It appears to be behind latest developments.
# echo "+keyboard" >/sys/class/leds/dell\:\:kbd_backlight/start_triggers
is all that is needed today.
Regards,
> But in looking further, I don't know why this is using
> __get_free_pages() instead of kmalloc? In fact, there is a kfree() in
> the error path, which looks wrong:
>
> kfree(wblock->handler_data);
>
> I think this should just be converted to using kmalloc/kfree everywhere.
--
Mihai Donțu
Re: wmi: usercopy: Kernel memory overwrite attempt detected to spans multiple pages (offset 0, size 4104)
On Sun, 2018-06-17 at 00:01 +0300, Mihai Donțu wrote:
> While trying to adjust the keyboard backlight mode, I hit this BUG:
>
> Jun 16 22:16:07 mdontu-l kernel: usercopy: Kernel memory overwrite attempt
> detected to spans multiple pages (offset 0, size 4104)!
> Jun 16 22:16:07 mdontu-l kernel: [ cut here ]
> Jun 16 22:16:07 mdontu-l kernel: kernel BUG at mm/usercopy.c:100!
> Jun 16 22:16:07 mdontu-l kernel: invalid opcode: [#1] PREEMPT SMP PTI
> Jun 16 22:16:07 mdontu-l kernel: Modules linked in: vboxpci(O) vboxnetadp(O)
> vboxnetflt(O) vboxdrv(O)
> Jun 16 22:16:07 mdontu-l kernel: CPU: 1 PID: 11726 Comm: smbios-keyboard
> Tainted: G OT 4.17.1-gentoo #1
> Jun 16 22:16:07 mdontu-l kernel: Hardware name: Dell Inc. Latitude
> E7440/07F3F4, BIOS A25 02/01/2018
> Jun 16 22:16:07 mdontu-l kernel: RIP: 0010:usercopy_abort+0x74/0x76
> Jun 16 22:16:07 mdontu-l kernel: RSP: 0018:9235021b7d98 EFLAGS: 00010246
> Jun 16 22:16:07 mdontu-l kernel: RAX: 0061 RBX: 8be94b0d8000
> RCX:
> Jun 16 22:16:07 mdontu-l kernel: RDX: RSI: 8be95ea95538
> RDI: 8be95ea95538
> Jun 16 22:16:07 mdontu-l kernel: RBP: 1008 R08: 000ecdbf
> R09: 03ce
> Jun 16 22:16:07 mdontu-l kernel: R10: R11: 9384378d
> R12:
> Jun 16 22:16:07 mdontu-l kernel: R13: 8be94b0d9008 R14:
> R15: 8be94e04d350
> Jun 16 22:16:07 mdontu-l kernel: FS: 7715b596f540()
> GS:8be95ea8() knlGS:
> Jun 16 22:16:07 mdontu-l kernel: CS: 0010 DS: ES: CR0:
> 80050033
> Jun 16 22:16:07 mdontu-l kernel: CR2: 7715b28bc350 CR3: 000390ee0001
> CR4: 001606e0
> Jun 16 22:16:07 mdontu-l kernel: Call Trace:
> Jun 16 22:16:07 mdontu-l kernel: __check_object_size.cold.2+0x16/0x7d
> Jun 16 22:16:07 mdontu-l kernel: wmi_ioctl+0x85/0x190
> Jun 16 22:16:07 mdontu-l kernel: do_vfs_ioctl+0xa8/0x680
> Jun 16 22:16:07 mdontu-l kernel: ksys_ioctl+0x60/0x90
> Jun 16 22:16:07 mdontu-l kernel: __x64_sys_ioctl+0x16/0x20
> Jun 16 22:16:07 mdontu-l kernel: do_syscall_64+0x6f/0x500
> Jun 16 22:16:07 mdontu-l kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
> Jun 16 22:16:07 mdontu-l kernel: RIP: 0033:0x7715b461dbd7
> Jun 16 22:16:07 mdontu-l kernel: RSP: 002b:7ffec2afb618 EFLAGS: 0246
> ORIG_RAX: 0010
> Jun 16 22:16:07 mdontu-l kernel: RAX: ffda RBX: 56c3a5638bc0
> RCX: 7715b461dbd7
> Jun 16 22:16:07 mdontu-l kernel: RDX: 56c3a5638bc0 RSI: c0345700
> RDI: 0003
> Jun 16 22:16:07 mdontu-l kernel: RBP: 1008 R08: 56c3a5638bc0
> R09:
> Jun 16 22:16:07 mdontu-l kernel: R10: R11: 0246
> R12: 7715b2ac9580
> Jun 16 22:16:07 mdontu-l kernel: R13: 56c3a56323e0 R14: fffb
> R15: 0003
> Jun 16 22:16:07 mdontu-l kernel: Code: 48 0f 45 c6 48 c7 c2 e1 65 b8 92 48 c7
> c6 5b 85 b7 92 51 48 0f 45 f2 48 89 f9 41 52 48 89 c2 48 c7 c7 c8 66 b8 92 e8
> fd fc ea ff <0f> 0b 49 89 e8 31 c9 44 89 e2 31 f6 48 c7 c7 1c 66 b8 92 e8 74
> Jun 16 22:16:07 mdontu-l kernel: RIP: usercopy_abort+0x74/0x76 RSP:
> 9235021b7d98
> Jun 16 22:16:07 mdontu-l kernel: ---[ end trace d1b2e9ad540f2091 ]---
>
> I couldn't pinpoint the exact user copy call that triggers it:
>
> (gdb) list *wmi_ioctl+0x85/0x190
> 0x81be9470 is in wmi_ioctl (drivers/platform/x86/wmi.c:816).
> 811>req_buf_size,
> 812sizeof(wblock->req_buf_size));
> 813 }
> 814
> 815 static long wmi_ioctl(struct file *filp, unsigned int cmd, unsigned
> long arg)
> 816 {
> 817 struct wmi_ioctl_buffer __user *input =
> 818 (struct wmi_ioctl_buffer __user *) arg;
> 819 struct wmi_block *wblock = filp->private_data;
> 820 struct wmi_ioctl_buffer *buf = NULL;
>
> I have attached my kernel config.
I eventually sprinkled some printk-s and got this:
855 if (copy_from_user(buf, input, wblock->req_buf_size)) {
856 dev_dbg(>dev.dev, "Copy %llu from user failed\n",
857 wblock->req_buf_size);
858 ret = -EFAULT;
859 goto out_ioctl;
860 }
Regards,
--
Mihai Donțu
Re: wmi: usercopy: Kernel memory overwrite attempt detected to spans multiple pages (offset 0, size 4104)
On Sun, 2018-06-17 at 00:01 +0300, Mihai Donțu wrote:
> While trying to adjust the keyboard backlight mode, I hit this BUG:
>
> Jun 16 22:16:07 mdontu-l kernel: usercopy: Kernel memory overwrite attempt
> detected to spans multiple pages (offset 0, size 4104)!
> Jun 16 22:16:07 mdontu-l kernel: [ cut here ]
> Jun 16 22:16:07 mdontu-l kernel: kernel BUG at mm/usercopy.c:100!
> Jun 16 22:16:07 mdontu-l kernel: invalid opcode: [#1] PREEMPT SMP PTI
> Jun 16 22:16:07 mdontu-l kernel: Modules linked in: vboxpci(O) vboxnetadp(O)
> vboxnetflt(O) vboxdrv(O)
> Jun 16 22:16:07 mdontu-l kernel: CPU: 1 PID: 11726 Comm: smbios-keyboard
> Tainted: G OT 4.17.1-gentoo #1
> Jun 16 22:16:07 mdontu-l kernel: Hardware name: Dell Inc. Latitude
> E7440/07F3F4, BIOS A25 02/01/2018
> Jun 16 22:16:07 mdontu-l kernel: RIP: 0010:usercopy_abort+0x74/0x76
> Jun 16 22:16:07 mdontu-l kernel: RSP: 0018:9235021b7d98 EFLAGS: 00010246
> Jun 16 22:16:07 mdontu-l kernel: RAX: 0061 RBX: 8be94b0d8000
> RCX:
> Jun 16 22:16:07 mdontu-l kernel: RDX: RSI: 8be95ea95538
> RDI: 8be95ea95538
> Jun 16 22:16:07 mdontu-l kernel: RBP: 1008 R08: 000ecdbf
> R09: 03ce
> Jun 16 22:16:07 mdontu-l kernel: R10: R11: 9384378d
> R12:
> Jun 16 22:16:07 mdontu-l kernel: R13: 8be94b0d9008 R14:
> R15: 8be94e04d350
> Jun 16 22:16:07 mdontu-l kernel: FS: 7715b596f540()
> GS:8be95ea8() knlGS:
> Jun 16 22:16:07 mdontu-l kernel: CS: 0010 DS: ES: CR0:
> 80050033
> Jun 16 22:16:07 mdontu-l kernel: CR2: 7715b28bc350 CR3: 000390ee0001
> CR4: 001606e0
> Jun 16 22:16:07 mdontu-l kernel: Call Trace:
> Jun 16 22:16:07 mdontu-l kernel: __check_object_size.cold.2+0x16/0x7d
> Jun 16 22:16:07 mdontu-l kernel: wmi_ioctl+0x85/0x190
> Jun 16 22:16:07 mdontu-l kernel: do_vfs_ioctl+0xa8/0x680
> Jun 16 22:16:07 mdontu-l kernel: ksys_ioctl+0x60/0x90
> Jun 16 22:16:07 mdontu-l kernel: __x64_sys_ioctl+0x16/0x20
> Jun 16 22:16:07 mdontu-l kernel: do_syscall_64+0x6f/0x500
> Jun 16 22:16:07 mdontu-l kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
> Jun 16 22:16:07 mdontu-l kernel: RIP: 0033:0x7715b461dbd7
> Jun 16 22:16:07 mdontu-l kernel: RSP: 002b:7ffec2afb618 EFLAGS: 0246
> ORIG_RAX: 0010
> Jun 16 22:16:07 mdontu-l kernel: RAX: ffda RBX: 56c3a5638bc0
> RCX: 7715b461dbd7
> Jun 16 22:16:07 mdontu-l kernel: RDX: 56c3a5638bc0 RSI: c0345700
> RDI: 0003
> Jun 16 22:16:07 mdontu-l kernel: RBP: 1008 R08: 56c3a5638bc0
> R09:
> Jun 16 22:16:07 mdontu-l kernel: R10: R11: 0246
> R12: 7715b2ac9580
> Jun 16 22:16:07 mdontu-l kernel: R13: 56c3a56323e0 R14: fffb
> R15: 0003
> Jun 16 22:16:07 mdontu-l kernel: Code: 48 0f 45 c6 48 c7 c2 e1 65 b8 92 48 c7
> c6 5b 85 b7 92 51 48 0f 45 f2 48 89 f9 41 52 48 89 c2 48 c7 c7 c8 66 b8 92 e8
> fd fc ea ff <0f> 0b 49 89 e8 31 c9 44 89 e2 31 f6 48 c7 c7 1c 66 b8 92 e8 74
> Jun 16 22:16:07 mdontu-l kernel: RIP: usercopy_abort+0x74/0x76 RSP:
> 9235021b7d98
> Jun 16 22:16:07 mdontu-l kernel: ---[ end trace d1b2e9ad540f2091 ]---
>
> I couldn't pinpoint the exact user copy call that triggers it:
>
> (gdb) list *wmi_ioctl+0x85/0x190
> 0x81be9470 is in wmi_ioctl (drivers/platform/x86/wmi.c:816).
> 811>req_buf_size,
> 812sizeof(wblock->req_buf_size));
> 813 }
> 814
> 815 static long wmi_ioctl(struct file *filp, unsigned int cmd, unsigned
> long arg)
> 816 {
> 817 struct wmi_ioctl_buffer __user *input =
> 818 (struct wmi_ioctl_buffer __user *) arg;
> 819 struct wmi_block *wblock = filp->private_data;
> 820 struct wmi_ioctl_buffer *buf = NULL;
>
> I have attached my kernel config.
I eventually sprinkled some printk-s and got this:
855 if (copy_from_user(buf, input, wblock->req_buf_size)) {
856 dev_dbg(>dev.dev, "Copy %llu from user failed\n",
857 wblock->req_buf_size);
858 ret = -EFAULT;
859 goto out_ioctl;
860 }
Regards,
--
Mihai Donțu
wmi: usercopy: Kernel memory overwrite attempt detected to spans multiple pages (offset 0, size 4104)
Hi,
While trying to adjust the keyboard backlight mode, I hit this BUG:
Jun 16 22:16:07 mdontu-l kernel: usercopy: Kernel memory overwrite attempt
detected to spans multiple pages (offset 0, size 4104)!
Jun 16 22:16:07 mdontu-l kernel: [ cut here ]
Jun 16 22:16:07 mdontu-l kernel: kernel BUG at mm/usercopy.c:100!
Jun 16 22:16:07 mdontu-l kernel: invalid opcode: [#1] PREEMPT SMP PTI
Jun 16 22:16:07 mdontu-l kernel: Modules linked in: vboxpci(O) vboxnetadp(O)
vboxnetflt(O) vboxdrv(O)
Jun 16 22:16:07 mdontu-l kernel: CPU: 1 PID: 11726 Comm: smbios-keyboard
Tainted: G OT 4.17.1-gentoo #1
Jun 16 22:16:07 mdontu-l kernel: Hardware name: Dell Inc. Latitude
E7440/07F3F4, BIOS A25 02/01/2018
Jun 16 22:16:07 mdontu-l kernel: RIP: 0010:usercopy_abort+0x74/0x76
Jun 16 22:16:07 mdontu-l kernel: RSP: 0018:9235021b7d98 EFLAGS: 00010246
Jun 16 22:16:07 mdontu-l kernel: RAX: 0061 RBX: 8be94b0d8000
RCX:
Jun 16 22:16:07 mdontu-l kernel: RDX: RSI: 8be95ea95538
RDI: 8be95ea95538
Jun 16 22:16:07 mdontu-l kernel: RBP: 1008 R08: 000ecdbf
R09: 03ce
Jun 16 22:16:07 mdontu-l kernel: R10: R11: 9384378d
R12:
Jun 16 22:16:07 mdontu-l kernel: R13: 8be94b0d9008 R14:
R15: 8be94e04d350
Jun 16 22:16:07 mdontu-l kernel: FS: 7715b596f540()
GS:8be95ea8() knlGS:
Jun 16 22:16:07 mdontu-l kernel: CS: 0010 DS: ES: CR0:
80050033
Jun 16 22:16:07 mdontu-l kernel: CR2: 7715b28bc350 CR3: 000390ee0001
CR4: 001606e0
Jun 16 22:16:07 mdontu-l kernel: Call Trace:
Jun 16 22:16:07 mdontu-l kernel: __check_object_size.cold.2+0x16/0x7d
Jun 16 22:16:07 mdontu-l kernel: wmi_ioctl+0x85/0x190
Jun 16 22:16:07 mdontu-l kernel: do_vfs_ioctl+0xa8/0x680
Jun 16 22:16:07 mdontu-l kernel: ksys_ioctl+0x60/0x90
Jun 16 22:16:07 mdontu-l kernel: __x64_sys_ioctl+0x16/0x20
Jun 16 22:16:07 mdontu-l kernel: do_syscall_64+0x6f/0x500
Jun 16 22:16:07 mdontu-l kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
Jun 16 22:16:07 mdontu-l kernel: RIP: 0033:0x7715b461dbd7
Jun 16 22:16:07 mdontu-l kernel: RSP: 002b:7ffec2afb618 EFLAGS: 0246
ORIG_RAX: 0010
Jun 16 22:16:07 mdontu-l kernel: RAX: ffda RBX: 56c3a5638bc0
RCX: 7715b461dbd7
Jun 16 22:16:07 mdontu-l kernel: RDX: 56c3a5638bc0 RSI: c0345700
RDI: 0003
Jun 16 22:16:07 mdontu-l kernel: RBP: 1008 R08: 56c3a5638bc0
R09:
Jun 16 22:16:07 mdontu-l kernel: R10: R11: 0246
R12: 7715b2ac9580
Jun 16 22:16:07 mdontu-l kernel: R13: 56c3a56323e0 R14: fffb
R15: 0003
Jun 16 22:16:07 mdontu-l kernel: Code: 48 0f 45 c6 48 c7 c2 e1 65 b8 92 48 c7
c6 5b 85 b7 92 51 48 0f 45 f2 48 89 f9 41 52 48 89 c2 48 c7 c7 c8 66 b8 92 e8
fd fc ea ff <0f> 0b 49 89 e8 31 c9 44 89 e2 31 f6 48 c7 c7 1c 66 b8 92 e8 74
Jun 16 22:16:07 mdontu-l kernel: RIP: usercopy_abort+0x74/0x76 RSP:
9235021b7d98
Jun 16 22:16:07 mdontu-l kernel: ---[ end trace d1b2e9ad540f2091 ]---
I couldn't pinpoint the exact user copy call that triggers it:
(gdb) list *wmi_ioctl+0x85/0x190
0x81be9470 is in wmi_ioctl (drivers/platform/x86/wmi.c:816).
811>req_buf_size,
812sizeof(wblock->req_buf_size));
813 }
814
815 static long wmi_ioctl(struct file *filp, unsigned int cmd, unsigned
long arg)
816 {
817 struct wmi_ioctl_buffer __user *input =
818 (struct wmi_ioctl_buffer __user *) arg;
819 struct wmi_block *wblock = filp->private_data;
820 struct wmi_ioctl_buffer *buf = NULL;
I have attached my kernel config.
Regards,
--
Mihai Donțu
config-4.17.1-gentoo.gz
Description: application/gzip
wmi: usercopy: Kernel memory overwrite attempt detected to spans multiple pages (offset 0, size 4104)
Hi,
While trying to adjust the keyboard backlight mode, I hit this BUG:
Jun 16 22:16:07 mdontu-l kernel: usercopy: Kernel memory overwrite attempt
detected to spans multiple pages (offset 0, size 4104)!
Jun 16 22:16:07 mdontu-l kernel: [ cut here ]
Jun 16 22:16:07 mdontu-l kernel: kernel BUG at mm/usercopy.c:100!
Jun 16 22:16:07 mdontu-l kernel: invalid opcode: [#1] PREEMPT SMP PTI
Jun 16 22:16:07 mdontu-l kernel: Modules linked in: vboxpci(O) vboxnetadp(O)
vboxnetflt(O) vboxdrv(O)
Jun 16 22:16:07 mdontu-l kernel: CPU: 1 PID: 11726 Comm: smbios-keyboard
Tainted: G OT 4.17.1-gentoo #1
Jun 16 22:16:07 mdontu-l kernel: Hardware name: Dell Inc. Latitude
E7440/07F3F4, BIOS A25 02/01/2018
Jun 16 22:16:07 mdontu-l kernel: RIP: 0010:usercopy_abort+0x74/0x76
Jun 16 22:16:07 mdontu-l kernel: RSP: 0018:9235021b7d98 EFLAGS: 00010246
Jun 16 22:16:07 mdontu-l kernel: RAX: 0061 RBX: 8be94b0d8000
RCX:
Jun 16 22:16:07 mdontu-l kernel: RDX: RSI: 8be95ea95538
RDI: 8be95ea95538
Jun 16 22:16:07 mdontu-l kernel: RBP: 1008 R08: 000ecdbf
R09: 03ce
Jun 16 22:16:07 mdontu-l kernel: R10: R11: 9384378d
R12:
Jun 16 22:16:07 mdontu-l kernel: R13: 8be94b0d9008 R14:
R15: 8be94e04d350
Jun 16 22:16:07 mdontu-l kernel: FS: 7715b596f540()
GS:8be95ea8() knlGS:
Jun 16 22:16:07 mdontu-l kernel: CS: 0010 DS: ES: CR0:
80050033
Jun 16 22:16:07 mdontu-l kernel: CR2: 7715b28bc350 CR3: 000390ee0001
CR4: 001606e0
Jun 16 22:16:07 mdontu-l kernel: Call Trace:
Jun 16 22:16:07 mdontu-l kernel: __check_object_size.cold.2+0x16/0x7d
Jun 16 22:16:07 mdontu-l kernel: wmi_ioctl+0x85/0x190
Jun 16 22:16:07 mdontu-l kernel: do_vfs_ioctl+0xa8/0x680
Jun 16 22:16:07 mdontu-l kernel: ksys_ioctl+0x60/0x90
Jun 16 22:16:07 mdontu-l kernel: __x64_sys_ioctl+0x16/0x20
Jun 16 22:16:07 mdontu-l kernel: do_syscall_64+0x6f/0x500
Jun 16 22:16:07 mdontu-l kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
Jun 16 22:16:07 mdontu-l kernel: RIP: 0033:0x7715b461dbd7
Jun 16 22:16:07 mdontu-l kernel: RSP: 002b:7ffec2afb618 EFLAGS: 0246
ORIG_RAX: 0010
Jun 16 22:16:07 mdontu-l kernel: RAX: ffda RBX: 56c3a5638bc0
RCX: 7715b461dbd7
Jun 16 22:16:07 mdontu-l kernel: RDX: 56c3a5638bc0 RSI: c0345700
RDI: 0003
Jun 16 22:16:07 mdontu-l kernel: RBP: 1008 R08: 56c3a5638bc0
R09:
Jun 16 22:16:07 mdontu-l kernel: R10: R11: 0246
R12: 7715b2ac9580
Jun 16 22:16:07 mdontu-l kernel: R13: 56c3a56323e0 R14: fffb
R15: 0003
Jun 16 22:16:07 mdontu-l kernel: Code: 48 0f 45 c6 48 c7 c2 e1 65 b8 92 48 c7
c6 5b 85 b7 92 51 48 0f 45 f2 48 89 f9 41 52 48 89 c2 48 c7 c7 c8 66 b8 92 e8
fd fc ea ff <0f> 0b 49 89 e8 31 c9 44 89 e2 31 f6 48 c7 c7 1c 66 b8 92 e8 74
Jun 16 22:16:07 mdontu-l kernel: RIP: usercopy_abort+0x74/0x76 RSP:
9235021b7d98
Jun 16 22:16:07 mdontu-l kernel: ---[ end trace d1b2e9ad540f2091 ]---
I couldn't pinpoint the exact user copy call that triggers it:
(gdb) list *wmi_ioctl+0x85/0x190
0x81be9470 is in wmi_ioctl (drivers/platform/x86/wmi.c:816).
811>req_buf_size,
812sizeof(wblock->req_buf_size));
813 }
814
815 static long wmi_ioctl(struct file *filp, unsigned int cmd, unsigned
long arg)
816 {
817 struct wmi_ioctl_buffer __user *input =
818 (struct wmi_ioctl_buffer __user *) arg;
819 struct wmi_block *wblock = filp->private_data;
820 struct wmi_ioctl_buffer *buf = NULL;
I have attached my kernel config.
Regards,
--
Mihai Donțu
config-4.17.1-gentoo.gz
Description: application/gzip
Re: [RFC 00/12] KVM/X86: Introduce a new guest mapping API
On Sat, 2018-02-10 at 12:33 +0100, KarimAllah Ahmed wrote: > On 02/05/2018 08:26 PM, Mihai Donțu wrote: > > On Mon, 2018-02-05 at 19:47 +0100, KarimAllah Ahmed wrote: > > > Guest memory can either be directly managed by the kernel (i.e. have a > > > "struct > > > page") or they can simply live outside kernel control (i.e. do not have a > > > "struct page"). KVM mostly support these two modes, except in a few places > > > where the code seems to assume that guest memory must have a "struct > > > page". > > > > In cases where there is no 'struct page', would it be possible to get > > two VM-s to share memory (in the way Xen's grant tables do)? > > > > We are working on a page sharing mechanism and would like to know if > > this use case can be accommodated. > > If your code is posted somewhere, I can take a look and let you know it > can be accommodated or not. Here is the latest patch: https://patchwork.kernel.org/patch/10121697/ The work is fairly alpha quality, but my colleague Mircea Cirjaliu is essentially trying to get two VMA-s (one belonging to a guest and one to the other) to point to the same page (much like KSM does). I'm not very familiar with the mm subsystem and whether something similar can be achieved with VMA-s of type VM_PFNMAP. > > > This patchset introduces a new mapping function to map guest memory into > > > host > > > kernel memory. Ideally I should also get rid of all guest mapping > > > functions > > > that end up converting a guest address to a page, but I decided to get > > > feedback > > > on this first and see if this is an acceptable API. > > > > > > Most of the offending code paths that has been updated are in the nested > > > code > > > base. Mostly because I stumbled upon this code while looking at the > > > nested MSR > > > bitmap handling for the IBRS patches. There are also offending code paths > > > in > > > SVM code, but I will do that once the interface is accepted. > > > > > > KarimAllah Ahmed (12): > > >KVM: Introduce helper functions to map/unmap guest memory > > >KVM/VMX: Use the new host mapping API for apic_access_page > > >KVM/VMX: Use the new host mapping API for virtual_apic_page > > >KVM/VMX: Use the new host mapping API for pi_desc_page > > >KVM/VMX: Use the new host mapping API for mapping nested vmptr > > >KVM/VMX: Use the new host mapping API for handle_vmptrld > > >KVM/VMX: Use the new host mapping API for mapping L12 MSR bitmap > > >KVM/VMX: Use the new host mapping API for mapping nested PML > > >KVM/VMX: Use the new host mapping API for cmpxchg_emulated > > >KVM/VMX: Use the new host mapping API for synic_clear_sint_msg_pending > > >KVM/VMX: Use the new host mapping API for synic_deliver_msg > > >KVM/VMX: Remove kvm_vcpu_gpa_to_page as it is now unused > > > > > > arch/x86/kvm/hyperv.c| 24 +++ > > > arch/x86/kvm/vmx.c | 159 > > > ++++--- > > > arch/x86/kvm/x86.c | 12 ++-- > > > include/linux/kvm_host.h | 18 +- > > > virt/kvm/kvm_main.c | 62 ++ > > > 5 files changed, 161 insertions(+), 114 deletions(-) > > > > > > Cc: Paolo Bonzini <pbonz...@redhat.com> > > > Cc: Radim Krčmář <rkrc...@redhat.com> > > > Cc: k...@vger.kernel.org > > > Cc: linux-kernel@vger.kernel.org -- Mihai Donțu signature.asc Description: This is a digitally signed message part
Re: [RFC 00/12] KVM/X86: Introduce a new guest mapping API
On Sat, 2018-02-10 at 12:33 +0100, KarimAllah Ahmed wrote: > On 02/05/2018 08:26 PM, Mihai Donțu wrote: > > On Mon, 2018-02-05 at 19:47 +0100, KarimAllah Ahmed wrote: > > > Guest memory can either be directly managed by the kernel (i.e. have a > > > "struct > > > page") or they can simply live outside kernel control (i.e. do not have a > > > "struct page"). KVM mostly support these two modes, except in a few places > > > where the code seems to assume that guest memory must have a "struct > > > page". > > > > In cases where there is no 'struct page', would it be possible to get > > two VM-s to share memory (in the way Xen's grant tables do)? > > > > We are working on a page sharing mechanism and would like to know if > > this use case can be accommodated. > > If your code is posted somewhere, I can take a look and let you know it > can be accommodated or not. Here is the latest patch: https://patchwork.kernel.org/patch/10121697/ The work is fairly alpha quality, but my colleague Mircea Cirjaliu is essentially trying to get two VMA-s (one belonging to a guest and one to the other) to point to the same page (much like KSM does). I'm not very familiar with the mm subsystem and whether something similar can be achieved with VMA-s of type VM_PFNMAP. > > > This patchset introduces a new mapping function to map guest memory into > > > host > > > kernel memory. Ideally I should also get rid of all guest mapping > > > functions > > > that end up converting a guest address to a page, but I decided to get > > > feedback > > > on this first and see if this is an acceptable API. > > > > > > Most of the offending code paths that has been updated are in the nested > > > code > > > base. Mostly because I stumbled upon this code while looking at the > > > nested MSR > > > bitmap handling for the IBRS patches. There are also offending code paths > > > in > > > SVM code, but I will do that once the interface is accepted. > > > > > > KarimAllah Ahmed (12): > > >KVM: Introduce helper functions to map/unmap guest memory > > >KVM/VMX: Use the new host mapping API for apic_access_page > > >KVM/VMX: Use the new host mapping API for virtual_apic_page > > >KVM/VMX: Use the new host mapping API for pi_desc_page > > >KVM/VMX: Use the new host mapping API for mapping nested vmptr > > >KVM/VMX: Use the new host mapping API for handle_vmptrld > > >KVM/VMX: Use the new host mapping API for mapping L12 MSR bitmap > > >KVM/VMX: Use the new host mapping API for mapping nested PML > > >KVM/VMX: Use the new host mapping API for cmpxchg_emulated > > >KVM/VMX: Use the new host mapping API for synic_clear_sint_msg_pending > > >KVM/VMX: Use the new host mapping API for synic_deliver_msg > > >KVM/VMX: Remove kvm_vcpu_gpa_to_page as it is now unused > > > > > > arch/x86/kvm/hyperv.c| 24 +++ > > > arch/x86/kvm/vmx.c | 159 > > > --- > > > arch/x86/kvm/x86.c | 12 ++-- > > > include/linux/kvm_host.h | 18 +- > > > virt/kvm/kvm_main.c | 62 ++ > > > 5 files changed, 161 insertions(+), 114 deletions(-) > > > > > > Cc: Paolo Bonzini > > > Cc: Radim Krčmář > > > Cc: k...@vger.kernel.org > > > Cc: linux-kernel@vger.kernel.org -- Mihai Donțu signature.asc Description: This is a digitally signed message part
Re: [RFC 00/12] KVM/X86: Introduce a new guest mapping API
On Mon, 2018-02-05 at 19:47 +0100, KarimAllah Ahmed wrote: > Guest memory can either be directly managed by the kernel (i.e. have a "struct > page") or they can simply live outside kernel control (i.e. do not have a > "struct page"). KVM mostly support these two modes, except in a few places > where the code seems to assume that guest memory must have a "struct page". In cases where there is no 'struct page', would it be possible to get two VM-s to share memory (in the way Xen's grant tables do)? We are working on a page sharing mechanism and would like to know if this use case can be accommodated. Thank you, > This patchset introduces a new mapping function to map guest memory into host > kernel memory. Ideally I should also get rid of all guest mapping functions > that end up converting a guest address to a page, but I decided to get > feedback > on this first and see if this is an acceptable API. > > Most of the offending code paths that has been updated are in the nested code > base. Mostly because I stumbled upon this code while looking at the nested MSR > bitmap handling for the IBRS patches. There are also offending code paths in > SVM code, but I will do that once the interface is accepted. > > KarimAllah Ahmed (12): > KVM: Introduce helper functions to map/unmap guest memory > KVM/VMX: Use the new host mapping API for apic_access_page > KVM/VMX: Use the new host mapping API for virtual_apic_page > KVM/VMX: Use the new host mapping API for pi_desc_page > KVM/VMX: Use the new host mapping API for mapping nested vmptr > KVM/VMX: Use the new host mapping API for handle_vmptrld > KVM/VMX: Use the new host mapping API for mapping L12 MSR bitmap > KVM/VMX: Use the new host mapping API for mapping nested PML > KVM/VMX: Use the new host mapping API for cmpxchg_emulated > KVM/VMX: Use the new host mapping API for synic_clear_sint_msg_pending > KVM/VMX: Use the new host mapping API for synic_deliver_msg > KVM/VMX: Remove kvm_vcpu_gpa_to_page as it is now unused > > arch/x86/kvm/hyperv.c| 24 +++ > arch/x86/kvm/vmx.c | 159 > --- > arch/x86/kvm/x86.c | 12 ++-- > include/linux/kvm_host.h | 18 +- > virt/kvm/kvm_main.c | 62 ++ > 5 files changed, 161 insertions(+), 114 deletions(-) > > Cc: Paolo Bonzini <pbonz...@redhat.com> > Cc: Radim Krčmář <rkrc...@redhat.com> > Cc: k...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org -- Mihai Donțu
Re: [RFC 00/12] KVM/X86: Introduce a new guest mapping API
On Mon, 2018-02-05 at 19:47 +0100, KarimAllah Ahmed wrote: > Guest memory can either be directly managed by the kernel (i.e. have a "struct > page") or they can simply live outside kernel control (i.e. do not have a > "struct page"). KVM mostly support these two modes, except in a few places > where the code seems to assume that guest memory must have a "struct page". In cases where there is no 'struct page', would it be possible to get two VM-s to share memory (in the way Xen's grant tables do)? We are working on a page sharing mechanism and would like to know if this use case can be accommodated. Thank you, > This patchset introduces a new mapping function to map guest memory into host > kernel memory. Ideally I should also get rid of all guest mapping functions > that end up converting a guest address to a page, but I decided to get > feedback > on this first and see if this is an acceptable API. > > Most of the offending code paths that has been updated are in the nested code > base. Mostly because I stumbled upon this code while looking at the nested MSR > bitmap handling for the IBRS patches. There are also offending code paths in > SVM code, but I will do that once the interface is accepted. > > KarimAllah Ahmed (12): > KVM: Introduce helper functions to map/unmap guest memory > KVM/VMX: Use the new host mapping API for apic_access_page > KVM/VMX: Use the new host mapping API for virtual_apic_page > KVM/VMX: Use the new host mapping API for pi_desc_page > KVM/VMX: Use the new host mapping API for mapping nested vmptr > KVM/VMX: Use the new host mapping API for handle_vmptrld > KVM/VMX: Use the new host mapping API for mapping L12 MSR bitmap > KVM/VMX: Use the new host mapping API for mapping nested PML > KVM/VMX: Use the new host mapping API for cmpxchg_emulated > KVM/VMX: Use the new host mapping API for synic_clear_sint_msg_pending > KVM/VMX: Use the new host mapping API for synic_deliver_msg > KVM/VMX: Remove kvm_vcpu_gpa_to_page as it is now unused > > arch/x86/kvm/hyperv.c| 24 +++ > arch/x86/kvm/vmx.c | 159 > --- > arch/x86/kvm/x86.c | 12 ++-- > include/linux/kvm_host.h | 18 +- > virt/kvm/kvm_main.c | 62 ++ > 5 files changed, 161 insertions(+), 114 deletions(-) > > Cc: Paolo Bonzini > Cc: Radim Krčmář > Cc: k...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org -- Mihai Donțu
Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.
On Fri, 2017-10-20 at 16:47 +0800, Yi Zhang wrote: > On 2017-10-18 at 17:13:18 +0300, Mihai Donțu wrote: > > On Wed, 2017-10-18 at 11:35 +0200, Paolo Bonzini wrote: > > > On 16/10/2017 02:08, Yi Zhang wrote: > > > > > And the introspection facility by Mihai uses a completely > > > > > different API for the introspector, based on sockets rather than > > > > > ioctls. > > > > > So I'm not sure this is the right API at all. > > > > > > > > Currently, We only block the write access, As far as I know an example, > > > > we now using it in a security daemon: > > > > > > Understood. However, I think QEMU is the wrong place to set this up. > > > > > > If the kernel wants to protect _itself_, it should use a hypercall. If > > > an introspector appliance wants to protect the guest kernel, it should > > > use the socket that connects it to the hypervisor. > > > > We have been looking at using SPP for VMI for quite some time. If a > > guest kernel will be able to control it (can it do so with EPT?) then > > it would be useful a simple switch that disables this ability, as an > > introspector wouldn't want the guest is trying to protect to interfere > > with it. > > Could you mind to provide more information and history about your > investigation? We are using VMI to secure certain parts of a guest kernel in memory (like prevent a certain data structure from being overriten). However, it sometimes happens for that part to be placed in the same page with other data, of no interest to us, that gets written frequently. This makes using the EPT problematic (a 4k page is just too big and generates too many violations). However, SPP (with its 128 bytes granularity) is ideal here. > > Also, if Intel doesn't have a specific use case for it that requires > > separate access to SPP control, then maybe we can fold it into the VMI > > API we are working on? > > That's totally Excellent as we really don't have a specific user case at > this time. OK. We will spend some time thinking at a proper way of exposing SPP with the VMI API. For example, we now work on implementing something similar to this: kvm_set_page_access( struct kvm *kvm, gfn_t gfn, u8 access ); The simplest approach would be to add something like: kvm_set_sub_page_access( struct kvm *kvm, gfn_t gfn, u32 mask ); where every bit from 'mask' indicates the write-allowed state of every 128-byte subpage. > BTW, I have already submit the SPP implementation draft in Xen side. > when you got some time, you can take a look at if that match your > requirement. I believe my colleague Răzvan Cojocaru has already commented on that patch set. :-) > > > > Consider It has a server which launching in the host user-space, and a > > > > client launching in the guest kernel. Yes, they are communicate with > > > > sockets. The guest kernel wanna protect a special area to prevent all > > > > the process including the kernel itself modify this area. the client > > > > could send the guest physical address via the security socket to server > > > > side, and server would update these protection into KVM. Thus, all the > > > > write access in a guest specific area will be blocked. > > > > > > > > Now the implementation only on the second half(maybe third ^_^) of this > > > > example: 'How kvm set the write-protect into a specific GFN?' > > > > > > > > Maybe a user space tools which use ioctl let kvm mmu update the > > > > write-protection is a better choice. -- Mihai Donțu
Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.
On Fri, 2017-10-20 at 16:47 +0800, Yi Zhang wrote: > On 2017-10-18 at 17:13:18 +0300, Mihai Donțu wrote: > > On Wed, 2017-10-18 at 11:35 +0200, Paolo Bonzini wrote: > > > On 16/10/2017 02:08, Yi Zhang wrote: > > > > > And the introspection facility by Mihai uses a completely > > > > > different API for the introspector, based on sockets rather than > > > > > ioctls. > > > > > So I'm not sure this is the right API at all. > > > > > > > > Currently, We only block the write access, As far as I know an example, > > > > we now using it in a security daemon: > > > > > > Understood. However, I think QEMU is the wrong place to set this up. > > > > > > If the kernel wants to protect _itself_, it should use a hypercall. If > > > an introspector appliance wants to protect the guest kernel, it should > > > use the socket that connects it to the hypervisor. > > > > We have been looking at using SPP for VMI for quite some time. If a > > guest kernel will be able to control it (can it do so with EPT?) then > > it would be useful a simple switch that disables this ability, as an > > introspector wouldn't want the guest is trying to protect to interfere > > with it. > > Could you mind to provide more information and history about your > investigation? We are using VMI to secure certain parts of a guest kernel in memory (like prevent a certain data structure from being overriten). However, it sometimes happens for that part to be placed in the same page with other data, of no interest to us, that gets written frequently. This makes using the EPT problematic (a 4k page is just too big and generates too many violations). However, SPP (with its 128 bytes granularity) is ideal here. > > Also, if Intel doesn't have a specific use case for it that requires > > separate access to SPP control, then maybe we can fold it into the VMI > > API we are working on? > > That's totally Excellent as we really don't have a specific user case at > this time. OK. We will spend some time thinking at a proper way of exposing SPP with the VMI API. For example, we now work on implementing something similar to this: kvm_set_page_access( struct kvm *kvm, gfn_t gfn, u8 access ); The simplest approach would be to add something like: kvm_set_sub_page_access( struct kvm *kvm, gfn_t gfn, u32 mask ); where every bit from 'mask' indicates the write-allowed state of every 128-byte subpage. > BTW, I have already submit the SPP implementation draft in Xen side. > when you got some time, you can take a look at if that match your > requirement. I believe my colleague Răzvan Cojocaru has already commented on that patch set. :-) > > > > Consider It has a server which launching in the host user-space, and a > > > > client launching in the guest kernel. Yes, they are communicate with > > > > sockets. The guest kernel wanna protect a special area to prevent all > > > > the process including the kernel itself modify this area. the client > > > > could send the guest physical address via the security socket to server > > > > side, and server would update these protection into KVM. Thus, all the > > > > write access in a guest specific area will be blocked. > > > > > > > > Now the implementation only on the second half(maybe third ^_^) of this > > > > example: 'How kvm set the write-protect into a specific GFN?' > > > > > > > > Maybe a user space tools which use ioctl let kvm mmu update the > > > > write-protection is a better choice. -- Mihai Donțu
Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.
On Wed, 2017-10-18 at 11:35 +0200, Paolo Bonzini wrote: > On 16/10/2017 02:08, Yi Zhang wrote: > > > And the introspection facility by Mihai uses a completely > > > different API for the introspector, based on sockets rather than ioctls. > > > So I'm not sure this is the right API at all. > > > > Currently, We only block the write access, As far as I know an example, > > we now using it in a security daemon: > > Understood. However, I think QEMU is the wrong place to set this up. > > If the kernel wants to protect _itself_, it should use a hypercall. If > an introspector appliance wants to protect the guest kernel, it should > use the socket that connects it to the hypervisor. We have been looking at using SPP for VMI for quite some time. If a guest kernel will be able to control it (can it do so with EPT?) then it would be useful a simple switch that disables this ability, as an introspector wouldn't want the guest is trying to protect to interfere with it. Also, if Intel doesn't have a specific use case for it that requires separate access to SPP control, then maybe we can fold it into the VMI API we are working on? Thanks, > > Consider It has a server which launching in the host user-space, and a > > client launching in the guest kernel. Yes, they are communicate with > > sockets. The guest kernel wanna protect a special area to prevent all > > the process including the kernel itself modify this area. the client > > could send the guest physical address via the security socket to server > > side, and server would update these protection into KVM. Thus, all the > > write access in a guest specific area will be blocked. > > > > Now the implementation only on the second half(maybe third ^_^) of this > > example: 'How kvm set the write-protect into a specific GFN?' > > > > Maybe a user space tools which use ioctl let kvm mmu update the > > write-protection is a better choice. -- Mihai Donțu
Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.
On Wed, 2017-10-18 at 11:35 +0200, Paolo Bonzini wrote: > On 16/10/2017 02:08, Yi Zhang wrote: > > > And the introspection facility by Mihai uses a completely > > > different API for the introspector, based on sockets rather than ioctls. > > > So I'm not sure this is the right API at all. > > > > Currently, We only block the write access, As far as I know an example, > > we now using it in a security daemon: > > Understood. However, I think QEMU is the wrong place to set this up. > > If the kernel wants to protect _itself_, it should use a hypercall. If > an introspector appliance wants to protect the guest kernel, it should > use the socket that connects it to the hypervisor. We have been looking at using SPP for VMI for quite some time. If a guest kernel will be able to control it (can it do so with EPT?) then it would be useful a simple switch that disables this ability, as an introspector wouldn't want the guest is trying to protect to interfere with it. Also, if Intel doesn't have a specific use case for it that requires separate access to SPP control, then maybe we can fold it into the VMI API we are working on? Thanks, > > Consider It has a server which launching in the host user-space, and a > > client launching in the guest kernel. Yes, they are communicate with > > sockets. The guest kernel wanna protect a special area to prevent all > > the process including the kernel itself modify this area. the client > > could send the guest physical address via the security socket to server > > side, and server would update these protection into KVM. Thus, all the > > write access in a guest specific area will be blocked. > > > > Now the implementation only on the second half(maybe third ^_^) of this > > example: 'How kvm set the write-protect into a specific GFN?' > > > > Maybe a user space tools which use ioctl let kvm mmu update the > > write-protection is a better choice. -- Mihai Donțu
Re: [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)
On Sun, 06 Nov 2016 15:48:36 +0100 Martin Steigerwald wrote: > Hi. > > Am Samstag, 5. November 2016, 16:46:33 CET schrieb Linus Torvalds: > > So it's once again a Saturday afternoon rather than Sunday, this time > > because I felt this rc was already big enough. > > With kernel 4.9-rc4 I saw gfx corruptions like > > https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png > > in Konversation, Konsole, Akregator and other KDE/Qt related apps up to the > point of not being able to use these applications in a meaningful way. > > I first thought this might be due to upgrading Qt from 5.6.1 to 5.7.1, yet > after rebooting into 4.8 Linux kernel as packaged in Debian I saw no gfx > glitches like that anymore. > > Anything known about this? https://bugzilla.kernel.org/show_bug.cgi?id=177701 The proposed patch appears to be: https://patchwork.freedesktop.org/patch/116808/ Have not tested it yet. > Machine is ThinkPad T520 with Sandybridge graphics. > > Kernel compiled with Debian distro GCC 6 but using no-pie makefile patch. > > Next week and weekend will be pretty busy and this is a production machine, > so > bisection or any other time-consuming work on this is out of question for me. > I can provide additional details in case they are easy and quick enough to > obtain. > > > System information (now back on 4.8 kernel): > > # phoronix-test-suite system-info > > Phoronix Test Suite v5.2.1 > System Information > > Hardware: > Processor: Intel Core i5-2520M @ 3.20GHz (4 Cores), Motherboard: LENOVO > 42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 16384MB, > Disk: 300GB INTEL SSDSA2CW30 + 480GB Crucial_CT480M50, Graphics: Intel 2nd > Generation Core Family IGP, Audio: Conexant CX20590, Monitor: P24T-7 LED, > Network: Intel 82579LM Gigabit Connection + Intel Centrino Advanced-N 6205 > > Software: > OS: Debian unstable, Kernel: 4.8.0-1-amd64 (x86_64), Desktop: KDE Frameworks > 5, Display Server: X Server 1.18.4, Display Driver: modesetting 1.18.4, > OpenGL: 3.3 Mesa 12.0.3, Compiler: GCC 6.2.0 20161103, File-System: btrfs, > Screen Resolution: 3840x1080 > > > # apt-show-versions | egrep "(^libgl1-mesa-dri|^libdrm-intel1|xserver-xorg- > core)" | grep amd64 > libdrm-intel1:amd64/sid 2.4.71-1 uptodate > libgl1-mesa-dri:amd64/sid 12.0.3-3 uptodate > xserver-xorg-core:amd64/sid 2:1.18.4-2 uptodate > > > Excerpt of glxinfo: > > Extended renderer info (GLX_MESA_query_renderer): > Vendor: Intel Open Source Technology Center (0x8086) > Device: Mesa DRI Intel(R) Sandybridge Mobile (0x126) > Version: 12.0.3 > Accelerated: yes > Video memory: 1536MB > Unified memory: yes > Preferred profile: core (0x1) > Max core profile version: 3.3 > Max compat profile version: 3.0 > Max GLES1 profile version: 1.1 > Max GLES[23] profile version: 3.0 > > X.org runs with modesetting driver (default was changed in Debian Sid a while > back). -- Mihai Donțu
Re: [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)
On Sun, 06 Nov 2016 15:48:36 +0100 Martin Steigerwald wrote: > Hi. > > Am Samstag, 5. November 2016, 16:46:33 CET schrieb Linus Torvalds: > > So it's once again a Saturday afternoon rather than Sunday, this time > > because I felt this rc was already big enough. > > With kernel 4.9-rc4 I saw gfx corruptions like > > https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png > > in Konversation, Konsole, Akregator and other KDE/Qt related apps up to the > point of not being able to use these applications in a meaningful way. > > I first thought this might be due to upgrading Qt from 5.6.1 to 5.7.1, yet > after rebooting into 4.8 Linux kernel as packaged in Debian I saw no gfx > glitches like that anymore. > > Anything known about this? https://bugzilla.kernel.org/show_bug.cgi?id=177701 The proposed patch appears to be: https://patchwork.freedesktop.org/patch/116808/ Have not tested it yet. > Machine is ThinkPad T520 with Sandybridge graphics. > > Kernel compiled with Debian distro GCC 6 but using no-pie makefile patch. > > Next week and weekend will be pretty busy and this is a production machine, > so > bisection or any other time-consuming work on this is out of question for me. > I can provide additional details in case they are easy and quick enough to > obtain. > > > System information (now back on 4.8 kernel): > > # phoronix-test-suite system-info > > Phoronix Test Suite v5.2.1 > System Information > > Hardware: > Processor: Intel Core i5-2520M @ 3.20GHz (4 Cores), Motherboard: LENOVO > 42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 16384MB, > Disk: 300GB INTEL SSDSA2CW30 + 480GB Crucial_CT480M50, Graphics: Intel 2nd > Generation Core Family IGP, Audio: Conexant CX20590, Monitor: P24T-7 LED, > Network: Intel 82579LM Gigabit Connection + Intel Centrino Advanced-N 6205 > > Software: > OS: Debian unstable, Kernel: 4.8.0-1-amd64 (x86_64), Desktop: KDE Frameworks > 5, Display Server: X Server 1.18.4, Display Driver: modesetting 1.18.4, > OpenGL: 3.3 Mesa 12.0.3, Compiler: GCC 6.2.0 20161103, File-System: btrfs, > Screen Resolution: 3840x1080 > > > # apt-show-versions | egrep "(^libgl1-mesa-dri|^libdrm-intel1|xserver-xorg- > core)" | grep amd64 > libdrm-intel1:amd64/sid 2.4.71-1 uptodate > libgl1-mesa-dri:amd64/sid 12.0.3-3 uptodate > xserver-xorg-core:amd64/sid 2:1.18.4-2 uptodate > > > Excerpt of glxinfo: > > Extended renderer info (GLX_MESA_query_renderer): > Vendor: Intel Open Source Technology Center (0x8086) > Device: Mesa DRI Intel(R) Sandybridge Mobile (0x126) > Version: 12.0.3 > Accelerated: yes > Video memory: 1536MB > Unified memory: yes > Preferred profile: core (0x1) > Max core profile version: 3.3 > Max compat profile version: 3.0 > Max GLES1 profile version: 1.1 > Max GLES[23] profile version: 3.0 > > X.org runs with modesetting driver (default was changed in Debian Sid a while > back). -- Mihai Donțu
Re: valgrind: mmap ENOMEM
On Mon, 25 Jan 2016 15:19:08 +0300 Konstantin Khlebnikov wrote: > On Mon, Jan 25, 2016 at 2:49 PM, Mihai Donțu wrote: > > Hi, > > > > I just moved to 4.5-rc1 and noticed this little gem while trying to > > debug an issue with skype: > > > > $ valgrind skype > > valgrind: mmap(0x60b000, 8192) failed in UME with error 12 (Cannot > > allocate memory). > > > > 4.4 works fine. I have attached my kernel config. > > Also fixed in upstream valgrind: https://bugs.kde.org/show_bug.cgi?id=357833 Thank you Kirill, Konstantin. I will patiently wait for a new valgrind and -rc2. :-) -- Mihai Donțu
Re: valgrind: mmap ENOMEM
On Mon, 25 Jan 2016 15:19:08 +0300 Konstantin Khlebnikov wrote: > On Mon, Jan 25, 2016 at 2:49 PM, Mihai Donțu <mihai.do...@gmail.com> wrote: > > Hi, > > > > I just moved to 4.5-rc1 and noticed this little gem while trying to > > debug an issue with skype: > > > > $ valgrind skype > > valgrind: mmap(0x60b000, 8192) failed in UME with error 12 (Cannot > > allocate memory). > > > > 4.4 works fine. I have attached my kernel config. > > Also fixed in upstream valgrind: https://bugs.kde.org/show_bug.cgi?id=357833 Thank you Kirill, Konstantin. I will patiently wait for a new valgrind and -rc2. :-) -- Mihai Donțu
Re: 4.4-rc0: 5 W+X pages found
On Tue, 8 Dec 2015 13:19:32 -0800 Kees Cook wrote: > On Mon, Nov 23, 2015 at 6:37 AM, Mihai Donțu wrote: > > On Sun, 15 Nov 2015 08:00:22 +0100 Pavel Machek wrote: > >> Kernel complains: > >> > >> [5.256044] [ cut here ] > >> [5.259267] WARNING: CPU: 0 PID: 1 at > >> arch/x86/mm/dump_pagetables.c:225 note_page+0x5ec/0x790() > >> [5.262668] x86/mm: Found insecure W+X mapping at address > >> ffe69000/0xffe69000 > >> [5.267109] Modules linked in: > >> [5.271403] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.3.0+ #122 > >> [5.275679] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW > >> (2.19 ) 03/31/2011 > >> [5.279957] f5cffeac c42b9f18 f5cffed8 f5cffec8 > >> c404062b 00e1 > >> [5.284387] c403ca9c f5cfff50 0163 f5cffee0 c4040686 > >> 0009 f5cffed8 > >> [5.288815] c4d268ac f5cffef4 f5cfff1c c403ca9c c4d1f494 00e1 > >> c4d268ac ffe69000 > >> [5.293314] Call Trace: > >> [5.297602] [] dump_stack+0x41/0x59 > >> [5.301864] [] warn_slowpath_common+0x6b/0xa0 > >> [5.306054] [] ? note_page+0x5ec/0x790 > >> [5.310209] [] warn_slowpath_fmt+0x26/0x30 > >> [5.314358] [] note_page+0x5ec/0x790 > >> [5.318440] [] ptdump_walk_pgd_level_core+0x14f/0x230 > >> [5.322578] [] ptdump_walk_pgd_level_checkwx+0x11/0x20 > >> [5.326632] [] mark_rodata_ro+0xcd/0xf0 > >> [5.330625] [] kernel_init+0x17/0xc0 > >> [5.334585] [] ret_from_kernel_thread+0x21/0x38 > >> [5.338585] [] ? rest_init+0xa0/0xa0 > >> [5.342583] ---[ end trace bc9ac0874ad9a058 ]--- > >> [5.346630] x86/mm: Checked W+X mappings: FAILED, 5 W+X pages > >> found. > >> > >> ...I'm not quite sure why it does backtrace, or how to debug this > >> one... > > > > That is a modest number. > > > > [2.493559] [ cut here ] > > [2.493563] WARNING: CPU: 2 PID: 1 at arch/x86/mm/dump_pagetables.c:225 > > note_page+0x5e1/0x780() > > [2.493565] x86/mm: Found insecure W+X mapping at address > > 8809d000/0x8809d000 > > [2.493565] Modules linked in: > > [2.493568] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc2 #2 > > [2.493569] Hardware name: Dell Inc. Latitude E7440/07F3F4, BIOS A15 > > 05/19/2015 > > [2.493570] c03551f4 88040c7cbd48 > > aa54851c > > [2.493572] 88040c7cbd90 88040c7cbd80 aa13a662 > > 88040c7cbe90 > > [2.493573] 8163 0004 > > > > [2.493575] Call Trace: > > [2.493579] [] dump_stack+0x4e/0x82 > > [2.493582] [] warn_slowpath_common+0x82/0xc0 > > [2.493583] [] warn_slowpath_fmt+0x5c/0x80 > > [2.493585] [] note_page+0x5e1/0x780 > > [2.493587] [] ptdump_walk_pgd_level_core+0x2c4/0x3f0 > > [2.493588] [] ptdump_walk_pgd_level_checkwx+0x17/0x20 > > [2.493591] [] mark_rodata_ro+0xef/0x100 > > [2.493594] [] ? rest_init+0x90/0x90 > > [2.493595] [] kernel_init+0x1d/0xe0 > > [2.493596] [] ret_from_fork+0x3f/0x70 > > [2.493598] [] ? rest_init+0x90/0x90 > > [2.493599] ---[ end trace e2aec56d15b94609 ]--- > > [2.498994] x86/mm: Checked W+X mappings: FAILED, 104640 W+X pages found. > > > > All the while I have: > > > > $ zgrep NX /proc/config.gz > > CONFIG_DEBUG_SET_MODULE_RONX=y > > > > I added to CC the people involved in pushing this feature to mainline, > > maybe they can point me to a possible cause. > > If you enable CONFIG_X86_PTDUMP, see if you can find out what exists > in /sys/kernel/debug/kernel_page_tables at 8809d000 ? ---[ Low Kernel Mapping ]--- 0x8800-0x88097000 604K RW GLB NX pte 0x88097000-0x88098000 4K ro GLB NX pte 0x88098000-0x88099000 4K ro GLB x pte 0x88099000-0x8809d000 16K RW GLB NX pte *0x8809d000-0x8809e000* 4K RW GLB x pte 0x8809e000-0x88201416K RW GLB NX pte 0x8820-0x88002900 654M RW PSE GLB NX pmd 0x88002900-0x880029e0 14M ro PSE GLB x pmd 0x880029e0-0x880029e89
Re: 4.4-rc0: 5 W+X pages found
On Tue, 8 Dec 2015 13:19:32 -0800 Kees Cook wrote: > On Mon, Nov 23, 2015 at 6:37 AM, Mihai Donțu wrote: > > On Sun, 15 Nov 2015 08:00:22 +0100 Pavel Machek wrote: > >> Kernel complains: > >> > >> [5.256044] [ cut here ] > >> [5.259267] WARNING: CPU: 0 PID: 1 at > >> arch/x86/mm/dump_pagetables.c:225 note_page+0x5ec/0x790() > >> [5.262668] x86/mm: Found insecure W+X mapping at address > >> ffe69000/0xffe69000 > >> [5.267109] Modules linked in: > >> [5.271403] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.3.0+ #122 > >> [5.275679] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW > >> (2.19 ) 03/31/2011 > >> [5.279957] f5cffeac c42b9f18 f5cffed8 f5cffec8 > >> c404062b 00e1 > >> [5.284387] c403ca9c f5cfff50 0163 f5cffee0 c4040686 > >> 0009 f5cffed8 > >> [5.288815] c4d268ac f5cffef4 f5cfff1c c403ca9c c4d1f494 00e1 > >> c4d268ac ffe69000 > >> [5.293314] Call Trace: > >> [5.297602] [] dump_stack+0x41/0x59 > >> [5.301864] [] warn_slowpath_common+0x6b/0xa0 > >> [5.306054] [] ? note_page+0x5ec/0x790 > >> [5.310209] [] warn_slowpath_fmt+0x26/0x30 > >> [5.314358] [] note_page+0x5ec/0x790 > >> [5.318440] [] ptdump_walk_pgd_level_core+0x14f/0x230 > >> [5.322578] [] ptdump_walk_pgd_level_checkwx+0x11/0x20 > >> [5.326632] [] mark_rodata_ro+0xcd/0xf0 > >> [5.330625] [] kernel_init+0x17/0xc0 > >> [5.334585] [] ret_from_kernel_thread+0x21/0x38 > >> [5.338585] [] ? rest_init+0xa0/0xa0 > >> [5.342583] ---[ end trace bc9ac0874ad9a058 ]--- > >> [5.346630] x86/mm: Checked W+X mappings: FAILED, 5 W+X pages > >> found. > >> > >> ...I'm not quite sure why it does backtrace, or how to debug this > >> one... > > > > That is a modest number. > > > > [2.493559] [ cut here ] > > [2.493563] WARNING: CPU: 2 PID: 1 at arch/x86/mm/dump_pagetables.c:225 > > note_page+0x5e1/0x780() > > [2.493565] x86/mm: Found insecure W+X mapping at address > > 8809d000/0x8809d000 > > [2.493565] Modules linked in: > > [2.493568] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc2 #2 > > [2.493569] Hardware name: Dell Inc. Latitude E7440/07F3F4, BIOS A15 > > 05/19/2015 > > [2.493570] c03551f4 88040c7cbd48 > > aa54851c > > [2.493572] 88040c7cbd90 88040c7cbd80 aa13a662 > > 88040c7cbe90 > > [2.493573] 8163 0004 > > > > [2.493575] Call Trace: > > [2.493579] [] dump_stack+0x4e/0x82 > > [2.493582] [] warn_slowpath_common+0x82/0xc0 > > [2.493583] [] warn_slowpath_fmt+0x5c/0x80 > > [2.493585] [] note_page+0x5e1/0x780 > > [2.493587] [] ptdump_walk_pgd_level_core+0x2c4/0x3f0 > > [2.493588] [] ptdump_walk_pgd_level_checkwx+0x17/0x20 > > [2.493591] [] mark_rodata_ro+0xef/0x100 > > [2.493594] [] ? rest_init+0x90/0x90 > > [2.493595] [] kernel_init+0x1d/0xe0 > > [2.493596] [] ret_from_fork+0x3f/0x70 > > [2.493598] [] ? rest_init+0x90/0x90 > > [2.493599] ---[ end trace e2aec56d15b94609 ]--- > > [2.498994] x86/mm: Checked W+X mappings: FAILED, 104640 W+X pages found. > > > > All the while I have: > > > > $ zgrep NX /proc/config.gz > > CONFIG_DEBUG_SET_MODULE_RONX=y > > > > I added to CC the people involved in pushing this feature to mainline, > > maybe they can point me to a possible cause. > > If you enable CONFIG_X86_PTDUMP, see if you can find out what exists > in /sys/kernel/debug/kernel_page_tables at 8809d000 ? ---[ Low Kernel Mapping ]--- 0x8800-0x88097000 604K RW GLB NX pte 0x88097000-0x88098000 4K ro GLB NX pte 0x88098000-0x88099000 4K ro GLB x pte 0x88099000-0x8809d000 16K RW GLB NX pte *0x8809d000-0x8809e000* 4K RW GLB x pte 0x8809e000-0x88201416K RW GLB NX pte 0x8820-0x88002900 654M RW PSE GLB NX pmd 0x88002900-0x880029e0 14M ro PSE GLB x pmd 0x880029e0-0x880029e89
Re: 4.4-rc0: 5 W+X pages found
On Sun, 15 Nov 2015 08:00:22 +0100 Pavel Machek wrote: > Kernel complains: > > [5.256044] [ cut here ] > [5.259267] WARNING: CPU: 0 PID: 1 at > arch/x86/mm/dump_pagetables.c:225 note_page+0x5ec/0x790() > [5.262668] x86/mm: Found insecure W+X mapping at address > ffe69000/0xffe69000 > [5.267109] Modules linked in: > [5.271403] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.3.0+ #122 > [5.275679] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW > (2.19 ) 03/31/2011 > [5.279957] f5cffeac c42b9f18 f5cffed8 f5cffec8 > c404062b 00e1 > [5.284387] c403ca9c f5cfff50 0163 f5cffee0 c4040686 > 0009 f5cffed8 > [5.288815] c4d268ac f5cffef4 f5cfff1c c403ca9c c4d1f494 00e1 > c4d268ac ffe69000 > [5.293314] Call Trace: > [5.297602] [] dump_stack+0x41/0x59 > [5.301864] [] warn_slowpath_common+0x6b/0xa0 > [5.306054] [] ? note_page+0x5ec/0x790 > [5.310209] [] warn_slowpath_fmt+0x26/0x30 > [5.314358] [] note_page+0x5ec/0x790 > [5.318440] [] ptdump_walk_pgd_level_core+0x14f/0x230 > [5.322578] [] ptdump_walk_pgd_level_checkwx+0x11/0x20 > [5.326632] [] mark_rodata_ro+0xcd/0xf0 > [5.330625] [] kernel_init+0x17/0xc0 > [5.334585] [] ret_from_kernel_thread+0x21/0x38 > [5.338585] [] ? rest_init+0xa0/0xa0 > [5.342583] ---[ end trace bc9ac0874ad9a058 ]--- > [5.346630] x86/mm: Checked W+X mappings: FAILED, 5 W+X pages > found. > > ...I'm not quite sure why it does backtrace, or how to debug this > one... That is a modest number. [2.493559] [ cut here ] [2.493563] WARNING: CPU: 2 PID: 1 at arch/x86/mm/dump_pagetables.c:225 note_page+0x5e1/0x780() [2.493565] x86/mm: Found insecure W+X mapping at address 8809d000/0x8809d000 [2.493565] Modules linked in: [2.493568] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc2 #2 [2.493569] Hardware name: Dell Inc. Latitude E7440/07F3F4, BIOS A15 05/19/2015 [2.493570] c03551f4 88040c7cbd48 aa54851c [2.493572] 88040c7cbd90 88040c7cbd80 aa13a662 88040c7cbe90 [2.493573] 8163 0004 [2.493575] Call Trace: [2.493579] [] dump_stack+0x4e/0x82 [2.493582] [] warn_slowpath_common+0x82/0xc0 [2.493583] [] warn_slowpath_fmt+0x5c/0x80 [2.493585] [] note_page+0x5e1/0x780 [2.493587] [] ptdump_walk_pgd_level_core+0x2c4/0x3f0 [2.493588] [] ptdump_walk_pgd_level_checkwx+0x17/0x20 [2.493591] [] mark_rodata_ro+0xef/0x100 [2.493594] [] ? rest_init+0x90/0x90 [2.493595] [] kernel_init+0x1d/0xe0 [2.493596] [] ret_from_fork+0x3f/0x70 [2.493598] [] ? rest_init+0x90/0x90 [2.493599] ---[ end trace e2aec56d15b94609 ]--- [2.498994] x86/mm: Checked W+X mappings: FAILED, 104640 W+X pages found. All the while I have: $ zgrep NX /proc/config.gz CONFIG_DEBUG_SET_MODULE_RONX=y I added to CC the people involved in pushing this feature to mainline, maybe they can point me to a possible cause. -- Mihai Donțu -- 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: 4.4-rc0: 5 W+X pages found
On Sun, 15 Nov 2015 08:00:22 +0100 Pavel Machek wrote: > Kernel complains: > > [5.256044] [ cut here ] > [5.259267] WARNING: CPU: 0 PID: 1 at > arch/x86/mm/dump_pagetables.c:225 note_page+0x5ec/0x790() > [5.262668] x86/mm: Found insecure W+X mapping at address > ffe69000/0xffe69000 > [5.267109] Modules linked in: > [5.271403] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.3.0+ #122 > [5.275679] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW > (2.19 ) 03/31/2011 > [5.279957] f5cffeac c42b9f18 f5cffed8 f5cffec8 > c404062b 00e1 > [5.284387] c403ca9c f5cfff50 0163 f5cffee0 c4040686 > 0009 f5cffed8 > [5.288815] c4d268ac f5cffef4 f5cfff1c c403ca9c c4d1f494 00e1 > c4d268ac ffe69000 > [5.293314] Call Trace: > [5.297602] [] dump_stack+0x41/0x59 > [5.301864] [] warn_slowpath_common+0x6b/0xa0 > [5.306054] [] ? note_page+0x5ec/0x790 > [5.310209] [] warn_slowpath_fmt+0x26/0x30 > [5.314358] [] note_page+0x5ec/0x790 > [5.318440] [] ptdump_walk_pgd_level_core+0x14f/0x230 > [5.322578] [] ptdump_walk_pgd_level_checkwx+0x11/0x20 > [5.326632] [] mark_rodata_ro+0xcd/0xf0 > [5.330625] [] kernel_init+0x17/0xc0 > [5.334585] [] ret_from_kernel_thread+0x21/0x38 > [5.338585] [] ? rest_init+0xa0/0xa0 > [5.342583] ---[ end trace bc9ac0874ad9a058 ]--- > [5.346630] x86/mm: Checked W+X mappings: FAILED, 5 W+X pages > found. > > ...I'm not quite sure why it does backtrace, or how to debug this > one... That is a modest number. [2.493559] [ cut here ] [2.493563] WARNING: CPU: 2 PID: 1 at arch/x86/mm/dump_pagetables.c:225 note_page+0x5e1/0x780() [2.493565] x86/mm: Found insecure W+X mapping at address 8809d000/0x8809d000 [2.493565] Modules linked in: [2.493568] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc2 #2 [2.493569] Hardware name: Dell Inc. Latitude E7440/07F3F4, BIOS A15 05/19/2015 [2.493570] c03551f4 88040c7cbd48 aa54851c [2.493572] 88040c7cbd90 88040c7cbd80 aa13a662 88040c7cbe90 [2.493573] 8163 0004 [2.493575] Call Trace: [2.493579] [] dump_stack+0x4e/0x82 [2.493582] [] warn_slowpath_common+0x82/0xc0 [2.493583] [] warn_slowpath_fmt+0x5c/0x80 [2.493585] [] note_page+0x5e1/0x780 [2.493587] [] ptdump_walk_pgd_level_core+0x2c4/0x3f0 [2.493588] [] ptdump_walk_pgd_level_checkwx+0x17/0x20 [2.493591] [] mark_rodata_ro+0xef/0x100 [2.493594] [] ? rest_init+0x90/0x90 [2.493595] [] kernel_init+0x1d/0xe0 [2.493596] [] ret_from_fork+0x3f/0x70 [2.493598] [] ? rest_init+0x90/0x90 [2.493599] ---[ end trace e2aec56d15b94609 ]--- [2.498994] x86/mm: Checked W+X mappings: FAILED, 104640 W+X pages found. All the while I have: $ zgrep NX /proc/config.gz CONFIG_DEBUG_SET_MODULE_RONX=y I added to CC the people involved in pushing this feature to mainline, maybe they can point me to a possible cause. -- Mihai Donțu -- 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] kvm/x86: add support for MONITOR_TRAP_FLAG
On Friday 10 July 2015 13:28:26 Paolo Bonzini wrote: > On 09/07/2015 21:49, Jan Kiszka wrote: > >> > CPU_BASED_MOV_DR_EXITING | CPU_BASED_UNCOND_IO_EXITING | > >> > -CPU_BASED_USE_IO_BITMAPS | CPU_BASED_MONITOR_EXITING | > >> > +CPU_BASED_USE_IO_BITMAPS | CPU_BASED_MONITOR_TRAP_FLAG > >> > | CPU_BASED_MONITOR_EXITING | > > Overlong line. > > Fixed and applied. Thank you! -- Mihai Donțu -- 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] kvm/x86: add support for MONITOR_TRAP_FLAG
On Friday 10 July 2015 13:28:26 Paolo Bonzini wrote: On 09/07/2015 21:49, Jan Kiszka wrote: CPU_BASED_MOV_DR_EXITING | CPU_BASED_UNCOND_IO_EXITING | -CPU_BASED_USE_IO_BITMAPS | CPU_BASED_MONITOR_EXITING | +CPU_BASED_USE_IO_BITMAPS | CPU_BASED_MONITOR_TRAP_FLAG | CPU_BASED_MONITOR_EXITING | Overlong line. Fixed and applied. Thank you! -- Mihai Donțu -- 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] kvm/x86: add support for MONITOR_TRAP_FLAG
Allow a nested hypervisor to single step its guests.
Signed-off-by: Mihai Donțu
---
This patch applies on top of current linux-next.
---
arch/x86/include/asm/vmx.h | 1 +
arch/x86/include/uapi/asm/vmx.h | 2 ++
arch/x86/kvm/vmx.c | 10 +-
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index da772ed..9299ae5 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -47,6 +47,7 @@
#define CPU_BASED_MOV_DR_EXITING0x0080
#define CPU_BASED_UNCOND_IO_EXITING 0x0100
#define CPU_BASED_USE_IO_BITMAPS0x0200
+#define CPU_BASED_MONITOR_TRAP_FLAG 0x0800
#define CPU_BASED_USE_MSR_BITMAPS 0x1000
#define CPU_BASED_MONITOR_EXITING 0x2000
#define CPU_BASED_PAUSE_EXITING 0x4000
diff --git a/arch/x86/include/uapi/asm/vmx.h b/arch/x86/include/uapi/asm/vmx.h
index 1fe9218..37fee27 100644
--- a/arch/x86/include/uapi/asm/vmx.h
+++ b/arch/x86/include/uapi/asm/vmx.h
@@ -58,6 +58,7 @@
#define EXIT_REASON_INVALID_STATE 33
#define EXIT_REASON_MSR_LOAD_FAIL 34
#define EXIT_REASON_MWAIT_INSTRUCTION 36
+#define EXIT_REASON_MONITOR_TRAP_FLAG 37
#define EXIT_REASON_MONITOR_INSTRUCTION 39
#define EXIT_REASON_PAUSE_INSTRUCTION 40
#define EXIT_REASON_MCE_DURING_VMENTRY 41
@@ -106,6 +107,7 @@
{ EXIT_REASON_MSR_READ, "MSR_READ" }, \
{ EXIT_REASON_MSR_WRITE, "MSR_WRITE" }, \
{ EXIT_REASON_MWAIT_INSTRUCTION, "MWAIT_INSTRUCTION" }, \
+ { EXIT_REASON_MONITOR_TRAP_FLAG, "MONITOR_TRAP_FLAG" }, \
{ EXIT_REASON_MONITOR_INSTRUCTION, "MONITOR_INSTRUCTION" }, \
{ EXIT_REASON_PAUSE_INSTRUCTION, "PAUSE_INSTRUCTION" }, \
{ EXIT_REASON_MCE_DURING_VMENTRY,"MCE_DURING_VMENTRY" }, \
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index e856dd5..6d7c650 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2443,7 +2443,7 @@ static void nested_vmx_setup_ctls_msrs(struct vcpu_vmx
*vmx)
CPU_BASED_CR8_LOAD_EXITING | CPU_BASED_CR8_STORE_EXITING |
#endif
CPU_BASED_MOV_DR_EXITING | CPU_BASED_UNCOND_IO_EXITING |
- CPU_BASED_USE_IO_BITMAPS | CPU_BASED_MONITOR_EXITING |
+ CPU_BASED_USE_IO_BITMAPS | CPU_BASED_MONITOR_TRAP_FLAG |
CPU_BASED_MONITOR_EXITING |
CPU_BASED_RDPMC_EXITING | CPU_BASED_RDTSC_EXITING |
CPU_BASED_PAUSE_EXITING | CPU_BASED_TPR_SHADOW |
CPU_BASED_ACTIVATE_SECONDARY_CONTROLS;
@@ -6246,6 +6246,11 @@ static int handle_mwait(struct kvm_vcpu *vcpu)
return handle_nop(vcpu);
}
+static int handle_monitor_trap(struct kvm_vcpu *vcpu)
+{
+ return 1;
+}
+
static int handle_monitor(struct kvm_vcpu *vcpu)
{
printk_once(KERN_WARNING "kvm: MONITOR instruction emulated as NOP!\n");
@@ -7282,6 +7287,7 @@ static int (*const kvm_vmx_exit_handlers[])(struct
kvm_vcpu *vcpu) = {
[EXIT_REASON_EPT_MISCONFIG] = handle_ept_misconfig,
[EXIT_REASON_PAUSE_INSTRUCTION] = handle_pause,
[EXIT_REASON_MWAIT_INSTRUCTION] = handle_mwait,
+ [EXIT_REASON_MONITOR_TRAP_FLAG] = handle_monitor_trap,
[EXIT_REASON_MONITOR_INSTRUCTION] = handle_monitor,
[EXIT_REASON_INVEPT] = handle_invept,
[EXIT_REASON_INVVPID] = handle_invvpid,
@@ -7542,6 +7548,8 @@ static bool nested_vmx_exit_handled(struct kvm_vcpu *vcpu)
return true;
case EXIT_REASON_MWAIT_INSTRUCTION:
return nested_cpu_has(vmcs12, CPU_BASED_MWAIT_EXITING);
+ case EXIT_REASON_MONITOR_TRAP_FLAG:
+ return nested_cpu_has(vmcs12, CPU_BASED_MONITOR_TRAP_FLAG);
case EXIT_REASON_MONITOR_INSTRUCTION:
return nested_cpu_has(vmcs12, CPU_BASED_MONITOR_EXITING);
case EXIT_REASON_PAUSE_INSTRUCTION:
--
2.4.5
--
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] kvm/x86: add support for MONITOR_TRAP_FLAG
Allow a nested hypervisor to single step its guests.
Signed-off-by: Mihai Donțu mihai.do...@gmail.com
---
This patch applies on top of current linux-next.
---
arch/x86/include/asm/vmx.h | 1 +
arch/x86/include/uapi/asm/vmx.h | 2 ++
arch/x86/kvm/vmx.c | 10 +-
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index da772ed..9299ae5 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -47,6 +47,7 @@
#define CPU_BASED_MOV_DR_EXITING0x0080
#define CPU_BASED_UNCOND_IO_EXITING 0x0100
#define CPU_BASED_USE_IO_BITMAPS0x0200
+#define CPU_BASED_MONITOR_TRAP_FLAG 0x0800
#define CPU_BASED_USE_MSR_BITMAPS 0x1000
#define CPU_BASED_MONITOR_EXITING 0x2000
#define CPU_BASED_PAUSE_EXITING 0x4000
diff --git a/arch/x86/include/uapi/asm/vmx.h b/arch/x86/include/uapi/asm/vmx.h
index 1fe9218..37fee27 100644
--- a/arch/x86/include/uapi/asm/vmx.h
+++ b/arch/x86/include/uapi/asm/vmx.h
@@ -58,6 +58,7 @@
#define EXIT_REASON_INVALID_STATE 33
#define EXIT_REASON_MSR_LOAD_FAIL 34
#define EXIT_REASON_MWAIT_INSTRUCTION 36
+#define EXIT_REASON_MONITOR_TRAP_FLAG 37
#define EXIT_REASON_MONITOR_INSTRUCTION 39
#define EXIT_REASON_PAUSE_INSTRUCTION 40
#define EXIT_REASON_MCE_DURING_VMENTRY 41
@@ -106,6 +107,7 @@
{ EXIT_REASON_MSR_READ, MSR_READ }, \
{ EXIT_REASON_MSR_WRITE, MSR_WRITE }, \
{ EXIT_REASON_MWAIT_INSTRUCTION, MWAIT_INSTRUCTION }, \
+ { EXIT_REASON_MONITOR_TRAP_FLAG, MONITOR_TRAP_FLAG }, \
{ EXIT_REASON_MONITOR_INSTRUCTION, MONITOR_INSTRUCTION }, \
{ EXIT_REASON_PAUSE_INSTRUCTION, PAUSE_INSTRUCTION }, \
{ EXIT_REASON_MCE_DURING_VMENTRY,MCE_DURING_VMENTRY }, \
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index e856dd5..6d7c650 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2443,7 +2443,7 @@ static void nested_vmx_setup_ctls_msrs(struct vcpu_vmx
*vmx)
CPU_BASED_CR8_LOAD_EXITING | CPU_BASED_CR8_STORE_EXITING |
#endif
CPU_BASED_MOV_DR_EXITING | CPU_BASED_UNCOND_IO_EXITING |
- CPU_BASED_USE_IO_BITMAPS | CPU_BASED_MONITOR_EXITING |
+ CPU_BASED_USE_IO_BITMAPS | CPU_BASED_MONITOR_TRAP_FLAG |
CPU_BASED_MONITOR_EXITING |
CPU_BASED_RDPMC_EXITING | CPU_BASED_RDTSC_EXITING |
CPU_BASED_PAUSE_EXITING | CPU_BASED_TPR_SHADOW |
CPU_BASED_ACTIVATE_SECONDARY_CONTROLS;
@@ -6246,6 +6246,11 @@ static int handle_mwait(struct kvm_vcpu *vcpu)
return handle_nop(vcpu);
}
+static int handle_monitor_trap(struct kvm_vcpu *vcpu)
+{
+ return 1;
+}
+
static int handle_monitor(struct kvm_vcpu *vcpu)
{
printk_once(KERN_WARNING kvm: MONITOR instruction emulated as NOP!\n);
@@ -7282,6 +7287,7 @@ static int (*const kvm_vmx_exit_handlers[])(struct
kvm_vcpu *vcpu) = {
[EXIT_REASON_EPT_MISCONFIG] = handle_ept_misconfig,
[EXIT_REASON_PAUSE_INSTRUCTION] = handle_pause,
[EXIT_REASON_MWAIT_INSTRUCTION] = handle_mwait,
+ [EXIT_REASON_MONITOR_TRAP_FLAG] = handle_monitor_trap,
[EXIT_REASON_MONITOR_INSTRUCTION] = handle_monitor,
[EXIT_REASON_INVEPT] = handle_invept,
[EXIT_REASON_INVVPID] = handle_invvpid,
@@ -7542,6 +7548,8 @@ static bool nested_vmx_exit_handled(struct kvm_vcpu *vcpu)
return true;
case EXIT_REASON_MWAIT_INSTRUCTION:
return nested_cpu_has(vmcs12, CPU_BASED_MWAIT_EXITING);
+ case EXIT_REASON_MONITOR_TRAP_FLAG:
+ return nested_cpu_has(vmcs12, CPU_BASED_MONITOR_TRAP_FLAG);
case EXIT_REASON_MONITOR_INSTRUCTION:
return nested_cpu_has(vmcs12, CPU_BASED_MONITOR_EXITING);
case EXIT_REASON_PAUSE_INSTRUCTION:
--
2.4.5
--
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] small update for strlen, strnlen, use less cpu instructions
On Tue, 16 Jun 2015 04:40:55 -0500 Orestes Leal Rodriguez wrote: > very small update to strlen and strnlen that now use less cpu > instructions by using a counter to avoid the memory addresses > substraction to find the length of the string. Nice. :-) Performance counter stats for './strnlen-new': 3.602591 task-clock (msec) #0.836 CPUs utilized 4 context-switches #0.001 M/sec 2 cpu-migrations#0.555 K/sec 48 page-faults #0.013 M/sec 9,607,307 cycles#2.667 GHz stalled-cycles-frontend stalled-cycles-backend 23,612,424 instructions #2.46 insns per cycle 9,121,754 branches # 2531.998 M/sec 5,409 branch-misses #0.06% of all branches 0.004311477 seconds time elapsed Performance counter stats for './strnlen-old': 3.181354 task-clock (msec) #0.930 CPUs utilized 1 context-switches #0.314 K/sec 1 cpu-migrations#0.314 K/sec 47 page-faults #0.015 M/sec 8,558,129 cycles#2.690 GHz stalled-cycles-frontend stalled-cycles-backend 23,577,237 instructions #2.75 insns per cycle 9,114,760 branches # 2865.057 M/sec 4,298 branch-misses #0.05% of all branches 0.003419085 seconds time elapsed However, you will need to create a proper patch: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/SubmittingPatches -- Mihai Donțu -- 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] small update for strlen, strnlen, use less cpu instructions
On Tue, 16 Jun 2015 04:40:55 -0500 Orestes Leal Rodriguez wrote: very small update to strlen and strnlen that now use less cpu instructions by using a counter to avoid the memory addresses substraction to find the length of the string. Nice. :-) Performance counter stats for './strnlen-new': 3.602591 task-clock (msec) #0.836 CPUs utilized 4 context-switches #0.001 M/sec 2 cpu-migrations#0.555 K/sec 48 page-faults #0.013 M/sec 9,607,307 cycles#2.667 GHz not supported stalled-cycles-frontend not supported stalled-cycles-backend 23,612,424 instructions #2.46 insns per cycle 9,121,754 branches # 2531.998 M/sec 5,409 branch-misses #0.06% of all branches 0.004311477 seconds time elapsed Performance counter stats for './strnlen-old': 3.181354 task-clock (msec) #0.930 CPUs utilized 1 context-switches #0.314 K/sec 1 cpu-migrations#0.314 K/sec 47 page-faults #0.015 M/sec 8,558,129 cycles#2.690 GHz not supported stalled-cycles-frontend not supported stalled-cycles-backend 23,577,237 instructions #2.75 insns per cycle 9,114,760 branches # 2865.057 M/sec 4,298 branch-misses #0.05% of all branches 0.003419085 seconds time elapsed However, you will need to create a proper patch: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/SubmittingPatches -- Mihai Donțu -- 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: Audio crackles with 4.1-rc1
On Fri, 12 Jun 2015 16:13:16 +0200 Takashi Iwai wrote:
> For your convenience, below is the combined patch for 4.1.
>
> Jonathan, could you also try this patch and see whether you still get
> the noise?
>
> ---
> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> index 0320cb523d9e..919051d92a0b 100644
> --- a/sound/pci/hda/patch_realtek.c
> +++ b/sound/pci/hda/patch_realtek.c
> @@ -4515,6 +4515,8 @@ enum {
> ALC288_FIXUP_DELL_HEADSET_MODE,
> ALC288_FIXUP_DELL1_MIC_NO_PRESENCE,
> ALC288_FIXUP_DELL_XPS_13_GPIO6,
> + ALC292_FIXUP_DELL_E7X,
> + ALC292_FIXUP_DISABLE_AAMIX,
> };
>
> static const struct hda_fixup alc269_fixups[] = {
> @@ -5037,6 +5039,16 @@ static const struct hda_fixup alc269_fixups[] = {
> .chained = true,
> .chain_id = ALC288_FIXUP_DELL1_MIC_NO_PRESENCE
> },
> + [ALC292_FIXUP_DISABLE_AAMIX] = {
> + .type = HDA_FIXUP_FUNC,
> + .v.func = alc_fixup_disable_aamix,
> + },
> + [ALC292_FIXUP_DELL_E7X] = {
> + .type = HDA_FIXUP_FUNC,
> + .v.func = alc_fixup_dell_xps13,
> + .chained = true,
> + .chain_id = ALC292_FIXUP_DISABLE_AAMIX
> + },
> };
>
> static const struct snd_pci_quirk alc269_fixup_tbl[] = {
> @@ -5049,6 +5061,8 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
> SND_PCI_QUIRK(0x1025, 0x0775, "Acer Aspire E1-572",
> ALC271_FIXUP_HP_GATE_MIC_JACK_E1_572),
> SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G",
> ALC282_FIXUP_ASPIRE_V5_PINS),
> SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
> + SND_PCI_QUIRK(0x1028, 0x05ca, "Dell Latitude E7240",
> ALC292_FIXUP_DELL_E7X),
> + SND_PCI_QUIRK(0x1028, 0x05cb, "Dell Latitude E7440",
> ALC292_FIXUP_DELL_E7X),
> SND_PCI_QUIRK(0x1028, 0x05da, "Dell Vostro 5460",
> ALC290_FIXUP_SUBWOOFER),
> SND_PCI_QUIRK(0x1028, 0x05f4, "Dell",
> ALC269_FIXUP_DELL1_MIC_NO_PRESENCE),
> SND_PCI_QUIRK(0x1028, 0x05f5, "Dell",
> ALC269_FIXUP_DELL1_MIC_NO_PRESENCE),
> @@ -5637,8 +5651,7 @@ static int patch_alc269(struct hda_codec *codec)
>
> spec = codec->spec;
> spec->gen.shared_mic_vref_pin = 0x18;
> - if (codec->core.vendor_id != 0x10ec0292)
> - codec->power_save_node = 1;
> + codec->power_save_node = 1;
>
> snd_hda_pick_fixup(codec, alc269_fixup_models,
> alc269_fixup_tbl, alc269_fixups);
This patch works fine for me. You can add my Tested-by when you re-spin
it for Linus and if Jonathan is happy as well.
Thank you!
--
Mihai Donțu
--
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: Audio crackles with 4.1-rc1
On Fri, 12 Jun 2015 09:00:06 +0200 Takashi Iwai wrote:
> At Fri, 12 Jun 2015 01:23:18 +0300, Mihai Donțu wrote:
> > No, 4.0.5 and all previous kernels (>= 3.12) are OK. I have attached a
> > small tarball with the two files produced by alsa-info.sh.
>
> Both are taken in different states (one is headphone plugged and
> another unplugged?). At best, take the snapshot in the same situation
> for comparison.
>
> In anyway, below is another shot in dark. The white noise is possibly
> the ill side effect of analog loopback. But it's strange that this
> didn't happen on 4.0.x. And, it combines another black magic that
> worked for another Dell model. Let's see.
>
>
> Takashi
>
> ---
> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> index 9d3e0fcb4326..cf46f6012ba4 100644
> --- a/sound/pci/hda/patch_realtek.c
> +++ b/sound/pci/hda/patch_realtek.c
> @@ -4522,6 +4522,8 @@ enum {
> ALC288_FIXUP_DELL1_MIC_NO_PRESENCE,
> ALC288_FIXUP_DELL_XPS_13_GPIO6,
> ALC298_FIXUP_DELL1_MIC_NO_PRESENCE,
> + ALC292_FIXUP_DELL_E74,
> + ALC292_FIXUP_DISABLE_AAMIX,
> };
>
> static const struct hda_fixup alc269_fixups[] = {
> @@ -5054,6 +5056,16 @@ static const struct hda_fixup alc269_fixups[] = {
> .chained = true,
> .chain_id = ALC269_FIXUP_HEADSET_MODE
> },
> + [ALC292_FIXUP_DISABLE_AAMIX] = {
> + .type = HDA_FIXUP_FUNC,
> + .v.func = alc_fixup_disable_aamix,
> + },
> + [ALC292_FIXUP_DELL_E74] = {
> + .type = HDA_FIXUP_FUNC,
> + .v.func = alc_fixup_dell_xps13,
> + .chained = true,
> + .chain_id = ALC292_FIXUP_DISABLE_AAMIX
> + },
> };
>
> static const struct snd_pci_quirk alc269_fixup_tbl[] = {
> @@ -5066,6 +5078,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
> SND_PCI_QUIRK(0x1025, 0x0775, "Acer Aspire E1-572",
> ALC271_FIXUP_HP_GATE_MIC_JACK_E1_572),
> SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G",
> ALC282_FIXUP_ASPIRE_V5_PINS),
> SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
> + SND_PCI_QUIRK(0x1028, 0x05cb, "Dell Latitude E7440",
> ALC292_FIXUP_DELL_E74),
> SND_PCI_QUIRK(0x1028, 0x05da, "Dell Vostro 5460",
> ALC290_FIXUP_SUBWOOFER),
> SND_PCI_QUIRK(0x1028, 0x05f4, "Dell",
> ALC269_FIXUP_DELL1_MIC_NO_PRESENCE),
> SND_PCI_QUIRK(0x1028, 0x05f5, "Dell",
> ALC269_FIXUP_DELL1_MIC_NO_PRESENCE),
Nice shot! It appears to work. :-) No clicks, no static.
I had to apply it by hand over 4.1-rc7, because the first two arrays
look different in both it and -master. Anyway, I will play with it some
more today see if anything else is broken.
Oh, and yes, the second state is without headphones on. I removed them
without thinking when the noise started. Sorry about that.
Thanks!
--
Mihai Donțu
--
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: Audio crackles with 4.1-rc1
On Fri, 12 Jun 2015 09:00:06 +0200 Takashi Iwai wrote:
At Fri, 12 Jun 2015 01:23:18 +0300, Mihai Donțu wrote:
No, 4.0.5 and all previous kernels (= 3.12) are OK. I have attached a
small tarball with the two files produced by alsa-info.sh.
Both are taken in different states (one is headphone plugged and
another unplugged?). At best, take the snapshot in the same situation
for comparison.
In anyway, below is another shot in dark. The white noise is possibly
the ill side effect of analog loopback. But it's strange that this
didn't happen on 4.0.x. And, it combines another black magic that
worked for another Dell model. Let's see.
Takashi
---
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 9d3e0fcb4326..cf46f6012ba4 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -4522,6 +4522,8 @@ enum {
ALC288_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC288_FIXUP_DELL_XPS_13_GPIO6,
ALC298_FIXUP_DELL1_MIC_NO_PRESENCE,
+ ALC292_FIXUP_DELL_E74,
+ ALC292_FIXUP_DISABLE_AAMIX,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -5054,6 +5056,16 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MODE
},
+ [ALC292_FIXUP_DISABLE_AAMIX] = {
+ .type = HDA_FIXUP_FUNC,
+ .v.func = alc_fixup_disable_aamix,
+ },
+ [ALC292_FIXUP_DELL_E74] = {
+ .type = HDA_FIXUP_FUNC,
+ .v.func = alc_fixup_dell_xps13,
+ .chained = true,
+ .chain_id = ALC292_FIXUP_DISABLE_AAMIX
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -5066,6 +5078,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x0775, Acer Aspire E1-572,
ALC271_FIXUP_HP_GATE_MIC_JACK_E1_572),
SND_PCI_QUIRK(0x1025, 0x079b, Acer Aspire V5-573G,
ALC282_FIXUP_ASPIRE_V5_PINS),
SND_PCI_QUIRK(0x1028, 0x0470, Dell M101z, ALC269_FIXUP_DELL_M101Z),
+ SND_PCI_QUIRK(0x1028, 0x05cb, Dell Latitude E7440,
ALC292_FIXUP_DELL_E74),
SND_PCI_QUIRK(0x1028, 0x05da, Dell Vostro 5460,
ALC290_FIXUP_SUBWOOFER),
SND_PCI_QUIRK(0x1028, 0x05f4, Dell,
ALC269_FIXUP_DELL1_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1028, 0x05f5, Dell,
ALC269_FIXUP_DELL1_MIC_NO_PRESENCE),
Nice shot! It appears to work. :-) No clicks, no static.
I had to apply it by hand over 4.1-rc7, because the first two arrays
look different in both it and -master. Anyway, I will play with it some
more today see if anything else is broken.
Oh, and yes, the second state is without headphones on. I removed them
without thinking when the noise started. Sorry about that.
Thanks!
--
Mihai Donțu
--
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: Audio crackles with 4.1-rc1
On Fri, 12 Jun 2015 16:13:16 +0200 Takashi Iwai wrote:
For your convenience, below is the combined patch for 4.1.
Jonathan, could you also try this patch and see whether you still get
the noise?
---
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 0320cb523d9e..919051d92a0b 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -4515,6 +4515,8 @@ enum {
ALC288_FIXUP_DELL_HEADSET_MODE,
ALC288_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC288_FIXUP_DELL_XPS_13_GPIO6,
+ ALC292_FIXUP_DELL_E7X,
+ ALC292_FIXUP_DISABLE_AAMIX,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -5037,6 +5039,16 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC288_FIXUP_DELL1_MIC_NO_PRESENCE
},
+ [ALC292_FIXUP_DISABLE_AAMIX] = {
+ .type = HDA_FIXUP_FUNC,
+ .v.func = alc_fixup_disable_aamix,
+ },
+ [ALC292_FIXUP_DELL_E7X] = {
+ .type = HDA_FIXUP_FUNC,
+ .v.func = alc_fixup_dell_xps13,
+ .chained = true,
+ .chain_id = ALC292_FIXUP_DISABLE_AAMIX
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -5049,6 +5061,8 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x0775, Acer Aspire E1-572,
ALC271_FIXUP_HP_GATE_MIC_JACK_E1_572),
SND_PCI_QUIRK(0x1025, 0x079b, Acer Aspire V5-573G,
ALC282_FIXUP_ASPIRE_V5_PINS),
SND_PCI_QUIRK(0x1028, 0x0470, Dell M101z, ALC269_FIXUP_DELL_M101Z),
+ SND_PCI_QUIRK(0x1028, 0x05ca, Dell Latitude E7240,
ALC292_FIXUP_DELL_E7X),
+ SND_PCI_QUIRK(0x1028, 0x05cb, Dell Latitude E7440,
ALC292_FIXUP_DELL_E7X),
SND_PCI_QUIRK(0x1028, 0x05da, Dell Vostro 5460,
ALC290_FIXUP_SUBWOOFER),
SND_PCI_QUIRK(0x1028, 0x05f4, Dell,
ALC269_FIXUP_DELL1_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1028, 0x05f5, Dell,
ALC269_FIXUP_DELL1_MIC_NO_PRESENCE),
@@ -5637,8 +5651,7 @@ static int patch_alc269(struct hda_codec *codec)
spec = codec-spec;
spec-gen.shared_mic_vref_pin = 0x18;
- if (codec-core.vendor_id != 0x10ec0292)
- codec-power_save_node = 1;
+ codec-power_save_node = 1;
snd_hda_pick_fixup(codec, alc269_fixup_models,
alc269_fixup_tbl, alc269_fixups);
This patch works fine for me. You can add my Tested-by when you re-spin
it for Linus and if Jonathan is happy as well.
Thank you!
--
Mihai Donțu
--
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: Audio crackles with 4.1-rc1
On Thu, 11 Jun 2015 07:01:13 +0200 Takashi Iwai wrote: > At Thu, 11 Jun 2015 01:12:36 +0300, Mihai Donțu wrote: > > On Wed, 10 Jun 2015 20:23:01 +0200 Takashi Iwai wrote: > > > From: Takashi Iwai > > > Subject: [PATCH] ALSA: hda - Reduce click noise at power up > > > > > > Some machines suffer from click noises at power up with the recent > > > kernels, and this seems triggered at the power transition and the > > > immediate verb executions. As a workaround, put a short delay (10ms) > > > right after the D0 transition. > > > > > > There are a few places that have the same kind of delays, especially > > > in the resume path. I guess they can be removed (or reduced) after > > > this patch. But, since the delay is relatively small, let's do it > > > later as a cleanup. > > > > > > Reported-by: Mihai Donțu > > > Signed-off-by: Takashi Iwai > > > --- > > > sound/pci/hda/hda_codec.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c > > > index b7782212dd64..38f5509ee52f 100644 > > > --- a/sound/pci/hda/hda_codec.c > > > +++ b/sound/pci/hda/hda_codec.c > > > @@ -3077,6 +3077,9 @@ static unsigned int hda_set_power_state(struct > > > hda_codec *codec, > > > break; > > > } > > > > > > + if (power_state == AC_PWRST_D0) > > > + msleep(10); > > > + > > > return state; > > > } > > > > > > > I take back my previous observations. I was at work and did not have > > access to headphones (one of those days). Now I'm at home, it's 1 AM, > > very quiet, and I notice the following: > > > > * on speakers: the click reproduces but with _very_ low amplitude; > >msleep(100) is unnoticeable, but msleep(10) is, barely; > > * on headphones: the moment I plug them I hear a loud static sound > >(like an old, untuned AM radio). If I play something, the static > >disappears. If I pause, the static returns after ~15s. > > OK, then the patch is no-go. We need a bit deeper analysis. > > About the headphone problem: don't you get the same issue with 4.0.x? > Please take alsa-info.sh outputs on both 4.0.x and 4.1 before and > after plugging the headphone, and attach the outputs. > (Run the script with --no-upload option.) No, 4.0.5 and all previous kernels (>= 3.12) are OK. I have attached a small tarball with the two files produced by alsa-info.sh. Thanks, -- Mihai Donțu alsa-info.tar.gz Description: application/gzip
Re: Audio crackles with 4.1-rc1
On Thu, 11 Jun 2015 07:01:13 +0200 Takashi Iwai wrote: At Thu, 11 Jun 2015 01:12:36 +0300, Mihai Donțu wrote: On Wed, 10 Jun 2015 20:23:01 +0200 Takashi Iwai wrote: From: Takashi Iwai ti...@suse.de Subject: [PATCH] ALSA: hda - Reduce click noise at power up Some machines suffer from click noises at power up with the recent kernels, and this seems triggered at the power transition and the immediate verb executions. As a workaround, put a short delay (10ms) right after the D0 transition. There are a few places that have the same kind of delays, especially in the resume path. I guess they can be removed (or reduced) after this patch. But, since the delay is relatively small, let's do it later as a cleanup. Reported-by: Mihai Donțu mihai.do...@gmail.com Signed-off-by: Takashi Iwai ti...@suse.de --- sound/pci/hda/hda_codec.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index b7782212dd64..38f5509ee52f 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3077,6 +3077,9 @@ static unsigned int hda_set_power_state(struct hda_codec *codec, break; } + if (power_state == AC_PWRST_D0) + msleep(10); + return state; } I take back my previous observations. I was at work and did not have access to headphones (one of those days). Now I'm at home, it's 1 AM, very quiet, and I notice the following: * on speakers: the click reproduces but with _very_ low amplitude; msleep(100) is unnoticeable, but msleep(10) is, barely; * on headphones: the moment I plug them I hear a loud static sound (like an old, untuned AM radio). If I play something, the static disappears. If I pause, the static returns after ~15s. OK, then the patch is no-go. We need a bit deeper analysis. About the headphone problem: don't you get the same issue with 4.0.x? Please take alsa-info.sh outputs on both 4.0.x and 4.1 before and after plugging the headphone, and attach the outputs. (Run the script with --no-upload option.) No, 4.0.5 and all previous kernels (= 3.12) are OK. I have attached a small tarball with the two files produced by alsa-info.sh. Thanks, -- Mihai Donțu alsa-info.tar.gz Description: application/gzip
Re: Audio crackles with 4.1-rc1
On Wed, 10 Jun 2015 20:23:01 +0200 Takashi Iwai wrote: > From: Takashi Iwai > Subject: [PATCH] ALSA: hda - Reduce click noise at power up > > Some machines suffer from click noises at power up with the recent > kernels, and this seems triggered at the power transition and the > immediate verb executions. As a workaround, put a short delay (10ms) > right after the D0 transition. > > There are a few places that have the same kind of delays, especially > in the resume path. I guess they can be removed (or reduced) after > this patch. But, since the delay is relatively small, let's do it > later as a cleanup. > > Reported-by: Mihai Donțu > Signed-off-by: Takashi Iwai > --- > sound/pci/hda/hda_codec.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c > index b7782212dd64..38f5509ee52f 100644 > --- a/sound/pci/hda/hda_codec.c > +++ b/sound/pci/hda/hda_codec.c > @@ -3077,6 +3077,9 @@ static unsigned int hda_set_power_state(struct > hda_codec *codec, > break; > } > > + if (power_state == AC_PWRST_D0) > + msleep(10); > + > return state; > } > I take back my previous observations. I was at work and did not have access to headphones (one of those days). Now I'm at home, it's 1 AM, very quiet, and I notice the following: * on speakers: the click reproduces but with _very_ low amplitude; msleep(100) is unnoticeable, but msleep(10) is, barely; * on headphones: the moment I plug them I hear a loud static sound (like an old, untuned AM radio). If I play something, the static disappears. If I pause, the static returns after ~15s. -- Mihai Donțu -- 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: Audio crackles with 4.1-rc1
On Wed, 10 Jun 2015 18:27:23 +0200 Takashi Iwai wrote: > At Wed, 10 Jun 2015 19:22:02 +0300, Mihai Donțu wrote: > > On Wed, 10 Jun 2015 14:50:30 +0200 Takashi Iwai wrote: > > > At Wed, 10 Jun 2015 14:33:42 +0200, Takashi Iwai wrote: > > > > At Wed, 10 Jun 2015 14:45:51 +0300, Mihai Donțu wrote: > > > > > On Wed, 10 Jun 2015 12:50:22 +0200 Takashi Iwai wrote: > > > > > > At Wed, 10 Jun 2015 13:41:35 +0300, Mihai Donțu wrote: > > > > > > > On Wed, 10 Jun 2015 12:22:53 +0200 Takashi Iwai wrote: > > > > > > > > At Wed, 10 Jun 2015 13:17:55 +0300, Mihai Donțu wrote: > > > > > > > > > On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote: > > > > > > > > > > From: Takashi Iwai > > > > > > > > > > Subject: [PATCH] ALSA: hda - Disable widget power-saving > > > > > > > > > > for ALC292 & co > > > > > > > > > > > > > > > > > > > > We've got reports that ALC3226 (a Dell variant of ALC292) > > > > > > > > > > gives click > > > > > > > > > > noises at transition from D3 to D0 when the widget > > > > > > > > > > power-saving is > > > > > > > > > > enabled. Further debugging session showed that avoiding it > > > > > > > > > > isn't > > > > > > > > > > trivial, unfortunately, since paths are basically activated > > > > > > > > > > dynamically while the pins have been already enabled. > > > > > > > > > > > > > > > > > > > > This patch disables the widget power-saving for such codecs. > > > > > > > > > > > > > > > > > > > > Reported-by: Jonathan McDowell > > > > > > > > > > Signed-off-by: Takashi Iwai > > > > > > > > > > --- > > > > > > > > > > sound/pci/hda/patch_realtek.c | 3 ++- > > > > > > > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > > > > > diff --git a/sound/pci/hda/patch_realtek.c > > > > > > > > > > b/sound/pci/hda/patch_realtek.c > > > > > > > > > > index 2e246fe495f6..31f8f13be907 100644 > > > > > > > > > > --- a/sound/pci/hda/patch_realtek.c > > > > > > > > > > +++ b/sound/pci/hda/patch_realtek.c > > > > > > > > > > @@ -5623,7 +5623,8 @@ static int patch_alc269(struct > > > > > > > > > > hda_codec *codec) > > > > > > > > > > > > > > > > > > > > spec = codec->spec; > > > > > > > > > > spec->gen.shared_mic_vref_pin = 0x18; > > > > > > > > > > - codec->power_save_node = 1; > > > > > > > > > > + if (codec->core.vendor_id != 0x10ec0292) > > > > > > > > > > + codec->power_save_node = 1; > > > > > > > > > > > > > > > > > > > > snd_hda_pick_fixup(codec, alc269_fixup_models, > > > > > > > > > >alc269_fixup_tbl, alc269_fixups); > > > > > > > > > > > > > > > > > > I'm on 4.1-rc7 which appears to contain this patch, however, > > > > > > > > > I still > > > > > > > > > get the audio artifacts (crackles) when I boot my laptop > > > > > > > > > (Latitude > > > > > > > > > E7440): > > > > > > > > > > > > > > > > > > [1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig > > > > > > > > > for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line > > > > > > > > > [1.058843] snd_hda_codec_realtek hdaudioC1D0: > > > > > > > > > speaker_outs=1 (0x14/0x0/0x0/0x0/0x0) > > > > > > > > > [1.058846] snd_hda_codec_realtek hdaudioC1D0: > > > > > > > > > hp_outs=1 (0x15/0x0/0x0/0x0/0x0) > > > > > > > > > [1.058849] snd_hda_codec_realtek hdaudioC1D0:mono: > > > > > > >
Re: Audio crackles with 4.1-rc1
On Wed, 10 Jun 2015 14:50:30 +0200 Takashi Iwai wrote: > At Wed, 10 Jun 2015 14:33:42 +0200, Takashi Iwai wrote: > > At Wed, 10 Jun 2015 14:45:51 +0300, Mihai Donțu wrote: > > > On Wed, 10 Jun 2015 12:50:22 +0200 Takashi Iwai wrote: > > > > At Wed, 10 Jun 2015 13:41:35 +0300, Mihai Donțu wrote: > > > > > On Wed, 10 Jun 2015 12:22:53 +0200 Takashi Iwai wrote: > > > > > > At Wed, 10 Jun 2015 13:17:55 +0300, Mihai Donțu wrote: > > > > > > > On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote: > > > > > > > > From: Takashi Iwai > > > > > > > > Subject: [PATCH] ALSA: hda - Disable widget power-saving for > > > > > > > > ALC292 & co > > > > > > > > > > > > > > > > We've got reports that ALC3226 (a Dell variant of ALC292) gives > > > > > > > > click > > > > > > > > noises at transition from D3 to D0 when the widget power-saving > > > > > > > > is > > > > > > > > enabled. Further debugging session showed that avoiding it > > > > > > > > isn't > > > > > > > > trivial, unfortunately, since paths are basically activated > > > > > > > > dynamically while the pins have been already enabled. > > > > > > > > > > > > > > > > This patch disables the widget power-saving for such codecs. > > > > > > > > > > > > > > > > Reported-by: Jonathan McDowell > > > > > > > > Signed-off-by: Takashi Iwai > > > > > > > > --- > > > > > > > > sound/pci/hda/patch_realtek.c | 3 ++- > > > > > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > diff --git a/sound/pci/hda/patch_realtek.c > > > > > > > > b/sound/pci/hda/patch_realtek.c > > > > > > > > index 2e246fe495f6..31f8f13be907 100644 > > > > > > > > --- a/sound/pci/hda/patch_realtek.c > > > > > > > > +++ b/sound/pci/hda/patch_realtek.c > > > > > > > > @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec > > > > > > > > *codec) > > > > > > > > > > > > > > > > spec = codec->spec; > > > > > > > > spec->gen.shared_mic_vref_pin = 0x18; > > > > > > > > - codec->power_save_node = 1; > > > > > > > > + if (codec->core.vendor_id != 0x10ec0292) > > > > > > > > + codec->power_save_node = 1; > > > > > > > > > > > > > > > > snd_hda_pick_fixup(codec, alc269_fixup_models, > > > > > > > >alc269_fixup_tbl, alc269_fixups); > > > > > > > > > > > > > > I'm on 4.1-rc7 which appears to contain this patch, however, I > > > > > > > still > > > > > > > get the audio artifacts (crackles) when I boot my laptop (Latitude > > > > > > > E7440): > > > > > > > > > > > > > > [1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for > > > > > > > ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line > > > > > > > [1.058843] snd_hda_codec_realtek hdaudioC1D0: > > > > > > > speaker_outs=1 (0x14/0x0/0x0/0x0/0x0) > > > > > > > [1.058846] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 > > > > > > > (0x15/0x0/0x0/0x0/0x0) > > > > > > > [1.058849] snd_hda_codec_realtek hdaudioC1D0:mono: > > > > > > > mono_out=0x0 > > > > > > > [1.058851] snd_hda_codec_realtek hdaudioC1D0:inputs: > > > > > > > [1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock > > > > > > > Mic=0x19 > > > > > > > [1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset > > > > > > > Mic=0x1a > > > > > > > [1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal > > > > > > > Mic=0x12 > > > > > > > > > > > > > > 4.0.4 was fine. > > > > > > > > > > > > Does it happen onl
Re: Audio crackles with 4.1-rc1
On Wed, 10 Jun 2015 12:50:22 +0200 Takashi Iwai wrote: > At Wed, 10 Jun 2015 13:41:35 +0300, Mihai Donțu wrote: > > On Wed, 10 Jun 2015 12:22:53 +0200 Takashi Iwai wrote: > > > At Wed, 10 Jun 2015 13:17:55 +0300, Mihai Donțu wrote: > > > > On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote: > > > > > From: Takashi Iwai > > > > > Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 & > > > > > co > > > > > > > > > > We've got reports that ALC3226 (a Dell variant of ALC292) gives click > > > > > noises at transition from D3 to D0 when the widget power-saving is > > > > > enabled. Further debugging session showed that avoiding it isn't > > > > > trivial, unfortunately, since paths are basically activated > > > > > dynamically while the pins have been already enabled. > > > > > > > > > > This patch disables the widget power-saving for such codecs. > > > > > > > > > > Reported-by: Jonathan McDowell > > > > > Signed-off-by: Takashi Iwai > > > > > --- > > > > > sound/pci/hda/patch_realtek.c | 3 ++- > > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/sound/pci/hda/patch_realtek.c > > > > > b/sound/pci/hda/patch_realtek.c > > > > > index 2e246fe495f6..31f8f13be907 100644 > > > > > --- a/sound/pci/hda/patch_realtek.c > > > > > +++ b/sound/pci/hda/patch_realtek.c > > > > > @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec) > > > > > > > > > > spec = codec->spec; > > > > > spec->gen.shared_mic_vref_pin = 0x18; > > > > > - codec->power_save_node = 1; > > > > > + if (codec->core.vendor_id != 0x10ec0292) > > > > > + codec->power_save_node = 1; > > > > > > > > > > snd_hda_pick_fixup(codec, alc269_fixup_models, > > > > > alc269_fixup_tbl, alc269_fixups); > > > > > > > > I'm on 4.1-rc7 which appears to contain this patch, however, I still > > > > get the audio artifacts (crackles) when I boot my laptop (Latitude > > > > E7440): > > > > > > > > [1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for > > > > ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line > > > > [1.058843] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=1 > > > > (0x14/0x0/0x0/0x0/0x0) > > > > [1.058846] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 > > > > (0x15/0x0/0x0/0x0/0x0) > > > > [1.058849] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0 > > > > [1.058851] snd_hda_codec_realtek hdaudioC1D0:inputs: > > > > [1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19 > > > > [1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a > > > > [1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12 > > > > > > > > 4.0.4 was fine. > > > > > > Does it happen only once at boot (i.e. at power up), or happens always > > > at runtime PM? If it's a once-off boot thing, the patch shouldn't > > > have much effect. Something else, very subtle thing, e.g. the order > > > of verb execution, might cause this kind of problem. > > > > Only at power up. I've also suspend-resumed twice and can confirm it's > > OK. > > > > There's a _very_ brief click at suspend (when the power is cut), but it > > looks like a plain circuitry thing. I probably didn't notice it before > > because I wasn't looking for it. > > Thanks. Do you get the same click noise when reloading snd-hda-intel > driver? Also, does it happen when booting in runlevel 3? > > Last but not least, a patch like below has any effect? > > > Takashi > > --- > diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c > --- a/sound/pci/hda/hda_codec.c > +++ b/sound/pci/hda/hda_codec.c > @@ -3077,6 +3077,8 @@ static unsigned int hda_set_power_state(struct > hda_codec *codec, > break; > } > > + if (power_state == AC_PWRST_D0) > + msleep(100); > return state; > } > Reloading snd-hda-intel does not trigger the noise, but it helps. I've noticed that the clicks appear when loading/reloading pulseaudio. $ pulseaudio -k will spawn a new child in background (probably asked by kmix) and immediately I hear the noise. Reloading the driver makes the problem go away. telinit 3 does nothing for me (Gentoo seems to have things wired differently). Manually reloading alsasound (/etc/init.d/alsasound) did not trigger the problem either. However! Your patch seems to work. Cold boot, pulseaudio restart and nothing. Not a peep. :-) -- Mihai Donțu -- 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: Audio crackles with 4.1-rc1
On Wed, 10 Jun 2015 12:22:53 +0200 Takashi Iwai wrote: > At Wed, 10 Jun 2015 13:17:55 +0300, Mihai Donțu wrote: > > On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote: > > > From: Takashi Iwai > > > Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 & co > > > > > > We've got reports that ALC3226 (a Dell variant of ALC292) gives click > > > noises at transition from D3 to D0 when the widget power-saving is > > > enabled. Further debugging session showed that avoiding it isn't > > > trivial, unfortunately, since paths are basically activated > > > dynamically while the pins have been already enabled. > > > > > > This patch disables the widget power-saving for such codecs. > > > > > > Reported-by: Jonathan McDowell > > > Signed-off-by: Takashi Iwai > > > --- > > > sound/pci/hda/patch_realtek.c | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c > > > index 2e246fe495f6..31f8f13be907 100644 > > > --- a/sound/pci/hda/patch_realtek.c > > > +++ b/sound/pci/hda/patch_realtek.c > > > @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec) > > > > > > spec = codec->spec; > > > spec->gen.shared_mic_vref_pin = 0x18; > > > - codec->power_save_node = 1; > > > + if (codec->core.vendor_id != 0x10ec0292) > > > + codec->power_save_node = 1; > > > > > > snd_hda_pick_fixup(codec, alc269_fixup_models, > > > alc269_fixup_tbl, alc269_fixups); > > > > I'm on 4.1-rc7 which appears to contain this patch, however, I still > > get the audio artifacts (crackles) when I boot my laptop (Latitude > > E7440): > > > > [1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: > > line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line > > [1.058843] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=1 > > (0x14/0x0/0x0/0x0/0x0) > > [1.058846] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 > > (0x15/0x0/0x0/0x0/0x0) > > [1.058849] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0 > > [1.058851] snd_hda_codec_realtek hdaudioC1D0:inputs: > > [1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19 > > [1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a > > [1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12 > > > > 4.0.4 was fine. > > Does it happen only once at boot (i.e. at power up), or happens always > at runtime PM? If it's a once-off boot thing, the patch shouldn't > have much effect. Something else, very subtle thing, e.g. the order > of verb execution, might cause this kind of problem. Only at power up. I've also suspend-resumed twice and can confirm it's OK. There's a _very_ brief click at suspend (when the power is cut), but it looks like a plain circuitry thing. I probably didn't notice it before because I wasn't looking for it. -- Mihai Donțu -- 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: Audio crackles with 4.1-rc1
On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote: > From: Takashi Iwai > Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 & co > > We've got reports that ALC3226 (a Dell variant of ALC292) gives click > noises at transition from D3 to D0 when the widget power-saving is > enabled. Further debugging session showed that avoiding it isn't > trivial, unfortunately, since paths are basically activated > dynamically while the pins have been already enabled. > > This patch disables the widget power-saving for such codecs. > > Reported-by: Jonathan McDowell > Signed-off-by: Takashi Iwai > --- > sound/pci/hda/patch_realtek.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c > index 2e246fe495f6..31f8f13be907 100644 > --- a/sound/pci/hda/patch_realtek.c > +++ b/sound/pci/hda/patch_realtek.c > @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec) > > spec = codec->spec; > spec->gen.shared_mic_vref_pin = 0x18; > - codec->power_save_node = 1; > + if (codec->core.vendor_id != 0x10ec0292) > + codec->power_save_node = 1; > > snd_hda_pick_fixup(codec, alc269_fixup_models, > alc269_fixup_tbl, alc269_fixups); I'm on 4.1-rc7 which appears to contain this patch, however, I still get the audio artifacts (crackles) when I boot my laptop (Latitude E7440): [1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line [1.058843] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=1 (0x14/0x0/0x0/0x0/0x0) [1.058846] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [1.058849] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0 [1.058851] snd_hda_codec_realtek hdaudioC1D0:inputs: [1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19 [1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a [1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12 4.0.4 was fine. -- Mihai Donțu -- 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: Audio crackles with 4.1-rc1
On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote: From: Takashi Iwai ti...@suse.de Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 co We've got reports that ALC3226 (a Dell variant of ALC292) gives click noises at transition from D3 to D0 when the widget power-saving is enabled. Further debugging session showed that avoiding it isn't trivial, unfortunately, since paths are basically activated dynamically while the pins have been already enabled. This patch disables the widget power-saving for such codecs. Reported-by: Jonathan McDowell nood...@earth.li Signed-off-by: Takashi Iwai ti...@suse.de --- sound/pci/hda/patch_realtek.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 2e246fe495f6..31f8f13be907 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec) spec = codec-spec; spec-gen.shared_mic_vref_pin = 0x18; - codec-power_save_node = 1; + if (codec-core.vendor_id != 0x10ec0292) + codec-power_save_node = 1; snd_hda_pick_fixup(codec, alc269_fixup_models, alc269_fixup_tbl, alc269_fixups); I'm on 4.1-rc7 which appears to contain this patch, however, I still get the audio artifacts (crackles) when I boot my laptop (Latitude E7440): [1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line [1.058843] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=1 (0x14/0x0/0x0/0x0/0x0) [1.058846] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [1.058849] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0 [1.058851] snd_hda_codec_realtek hdaudioC1D0:inputs: [1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19 [1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a [1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12 4.0.4 was fine. -- Mihai Donțu -- 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: Audio crackles with 4.1-rc1
On Wed, 10 Jun 2015 12:22:53 +0200 Takashi Iwai wrote: At Wed, 10 Jun 2015 13:17:55 +0300, Mihai Donțu wrote: On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote: From: Takashi Iwai ti...@suse.de Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 co We've got reports that ALC3226 (a Dell variant of ALC292) gives click noises at transition from D3 to D0 when the widget power-saving is enabled. Further debugging session showed that avoiding it isn't trivial, unfortunately, since paths are basically activated dynamically while the pins have been already enabled. This patch disables the widget power-saving for such codecs. Reported-by: Jonathan McDowell nood...@earth.li Signed-off-by: Takashi Iwai ti...@suse.de --- sound/pci/hda/patch_realtek.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 2e246fe495f6..31f8f13be907 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec) spec = codec-spec; spec-gen.shared_mic_vref_pin = 0x18; - codec-power_save_node = 1; + if (codec-core.vendor_id != 0x10ec0292) + codec-power_save_node = 1; snd_hda_pick_fixup(codec, alc269_fixup_models, alc269_fixup_tbl, alc269_fixups); I'm on 4.1-rc7 which appears to contain this patch, however, I still get the audio artifacts (crackles) when I boot my laptop (Latitude E7440): [1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line [1.058843] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=1 (0x14/0x0/0x0/0x0/0x0) [1.058846] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [1.058849] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0 [1.058851] snd_hda_codec_realtek hdaudioC1D0:inputs: [1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19 [1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a [1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12 4.0.4 was fine. Does it happen only once at boot (i.e. at power up), or happens always at runtime PM? If it's a once-off boot thing, the patch shouldn't have much effect. Something else, very subtle thing, e.g. the order of verb execution, might cause this kind of problem. Only at power up. I've also suspend-resumed twice and can confirm it's OK. There's a _very_ brief click at suspend (when the power is cut), but it looks like a plain circuitry thing. I probably didn't notice it before because I wasn't looking for it. -- Mihai Donțu -- 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: Audio crackles with 4.1-rc1
On Wed, 10 Jun 2015 12:50:22 +0200 Takashi Iwai wrote: At Wed, 10 Jun 2015 13:41:35 +0300, Mihai Donțu wrote: On Wed, 10 Jun 2015 12:22:53 +0200 Takashi Iwai wrote: At Wed, 10 Jun 2015 13:17:55 +0300, Mihai Donțu wrote: On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote: From: Takashi Iwai ti...@suse.de Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 co We've got reports that ALC3226 (a Dell variant of ALC292) gives click noises at transition from D3 to D0 when the widget power-saving is enabled. Further debugging session showed that avoiding it isn't trivial, unfortunately, since paths are basically activated dynamically while the pins have been already enabled. This patch disables the widget power-saving for such codecs. Reported-by: Jonathan McDowell nood...@earth.li Signed-off-by: Takashi Iwai ti...@suse.de --- sound/pci/hda/patch_realtek.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 2e246fe495f6..31f8f13be907 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec) spec = codec-spec; spec-gen.shared_mic_vref_pin = 0x18; - codec-power_save_node = 1; + if (codec-core.vendor_id != 0x10ec0292) + codec-power_save_node = 1; snd_hda_pick_fixup(codec, alc269_fixup_models, alc269_fixup_tbl, alc269_fixups); I'm on 4.1-rc7 which appears to contain this patch, however, I still get the audio artifacts (crackles) when I boot my laptop (Latitude E7440): [1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line [1.058843] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=1 (0x14/0x0/0x0/0x0/0x0) [1.058846] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [1.058849] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0 [1.058851] snd_hda_codec_realtek hdaudioC1D0:inputs: [1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19 [1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a [1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12 4.0.4 was fine. Does it happen only once at boot (i.e. at power up), or happens always at runtime PM? If it's a once-off boot thing, the patch shouldn't have much effect. Something else, very subtle thing, e.g. the order of verb execution, might cause this kind of problem. Only at power up. I've also suspend-resumed twice and can confirm it's OK. There's a _very_ brief click at suspend (when the power is cut), but it looks like a plain circuitry thing. I probably didn't notice it before because I wasn't looking for it. Thanks. Do you get the same click noise when reloading snd-hda-intel driver? Also, does it happen when booting in runlevel 3? Last but not least, a patch like below has any effect? Takashi --- diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3077,6 +3077,8 @@ static unsigned int hda_set_power_state(struct hda_codec *codec, break; } + if (power_state == AC_PWRST_D0) + msleep(100); return state; } Reloading snd-hda-intel does not trigger the noise, but it helps. I've noticed that the clicks appear when loading/reloading pulseaudio. $ pulseaudio -k will spawn a new child in background (probably asked by kmix) and immediately I hear the noise. Reloading the driver makes the problem go away. telinit 3 does nothing for me (Gentoo seems to have things wired differently). Manually reloading alsasound (/etc/init.d/alsasound) did not trigger the problem either. However! Your patch seems to work. Cold boot, pulseaudio restart and nothing. Not a peep. :-) -- Mihai Donțu -- 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: Audio crackles with 4.1-rc1
On Wed, 10 Jun 2015 14:50:30 +0200 Takashi Iwai wrote: At Wed, 10 Jun 2015 14:33:42 +0200, Takashi Iwai wrote: At Wed, 10 Jun 2015 14:45:51 +0300, Mihai Donțu wrote: On Wed, 10 Jun 2015 12:50:22 +0200 Takashi Iwai wrote: At Wed, 10 Jun 2015 13:41:35 +0300, Mihai Donțu wrote: On Wed, 10 Jun 2015 12:22:53 +0200 Takashi Iwai wrote: At Wed, 10 Jun 2015 13:17:55 +0300, Mihai Donțu wrote: On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote: From: Takashi Iwai ti...@suse.de Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 co We've got reports that ALC3226 (a Dell variant of ALC292) gives click noises at transition from D3 to D0 when the widget power-saving is enabled. Further debugging session showed that avoiding it isn't trivial, unfortunately, since paths are basically activated dynamically while the pins have been already enabled. This patch disables the widget power-saving for such codecs. Reported-by: Jonathan McDowell nood...@earth.li Signed-off-by: Takashi Iwai ti...@suse.de --- sound/pci/hda/patch_realtek.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 2e246fe495f6..31f8f13be907 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec) spec = codec-spec; spec-gen.shared_mic_vref_pin = 0x18; - codec-power_save_node = 1; + if (codec-core.vendor_id != 0x10ec0292) + codec-power_save_node = 1; snd_hda_pick_fixup(codec, alc269_fixup_models, alc269_fixup_tbl, alc269_fixups); I'm on 4.1-rc7 which appears to contain this patch, however, I still get the audio artifacts (crackles) when I boot my laptop (Latitude E7440): [1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line [1.058843] snd_hda_codec_realtek hdaudioC1D0: speaker_outs=1 (0x14/0x0/0x0/0x0/0x0) [1.058846] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [1.058849] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0 [1.058851] snd_hda_codec_realtek hdaudioC1D0:inputs: [1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19 [1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a [1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12 4.0.4 was fine. Does it happen only once at boot (i.e. at power up), or happens always at runtime PM? If it's a once-off boot thing, the patch shouldn't have much effect. Something else, very subtle thing, e.g. the order of verb execution, might cause this kind of problem. Only at power up. I've also suspend-resumed twice and can confirm it's OK. There's a _very_ brief click at suspend (when the power is cut), but it looks like a plain circuitry thing. I probably didn't notice it before because I wasn't looking for it. Thanks. Do you get the same click noise when reloading snd-hda-intel driver? Also, does it happen when booting in runlevel 3? Last but not least, a patch like below has any effect? Takashi --- diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3077,6 +3077,8 @@ static unsigned int hda_set_power_state(struct hda_codec *codec, break; } + if (power_state == AC_PWRST_D0) + msleep(100); return state; } Reloading snd-hda-intel does not trigger the noise, but it helps. I've noticed that the clicks appear when loading/reloading pulseaudio. $ pulseaudio -k will spawn a new child in background (probably asked by kmix) and immediately I hear the noise. Reloading the driver makes the problem go away. Hm. It's a bit inconsistent, but still this can be only at the full power up sequence. telinit 3 does nothing for me (Gentoo seems to have things wired differently). Manually reloading alsasound (/etc/init.d/alsasound) did not trigger the problem either. However! Your patch seems to work. Cold boot, pulseaudio restart and nothing. Not a peep. :-) OK, could you try to reduce the sleep value from 100 to 10
Re: Audio crackles with 4.1-rc1
On Wed, 10 Jun 2015 18:27:23 +0200 Takashi Iwai wrote: At Wed, 10 Jun 2015 19:22:02 +0300, Mihai Donțu wrote: On Wed, 10 Jun 2015 14:50:30 +0200 Takashi Iwai wrote: At Wed, 10 Jun 2015 14:33:42 +0200, Takashi Iwai wrote: At Wed, 10 Jun 2015 14:45:51 +0300, Mihai Donțu wrote: On Wed, 10 Jun 2015 12:50:22 +0200 Takashi Iwai wrote: At Wed, 10 Jun 2015 13:41:35 +0300, Mihai Donțu wrote: On Wed, 10 Jun 2015 12:22:53 +0200 Takashi Iwai wrote: At Wed, 10 Jun 2015 13:17:55 +0300, Mihai Donțu wrote: On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote: From: Takashi Iwai ti...@suse.de Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 co We've got reports that ALC3226 (a Dell variant of ALC292) gives click noises at transition from D3 to D0 when the widget power-saving is enabled. Further debugging session showed that avoiding it isn't trivial, unfortunately, since paths are basically activated dynamically while the pins have been already enabled. This patch disables the widget power-saving for such codecs. Reported-by: Jonathan McDowell nood...@earth.li Signed-off-by: Takashi Iwai ti...@suse.de --- sound/pci/hda/patch_realtek.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 2e246fe495f6..31f8f13be907 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec) spec = codec-spec; spec-gen.shared_mic_vref_pin = 0x18; - codec-power_save_node = 1; + if (codec-core.vendor_id != 0x10ec0292) + codec-power_save_node = 1; snd_hda_pick_fixup(codec, alc269_fixup_models, alc269_fixup_tbl, alc269_fixups); I'm on 4.1-rc7 which appears to contain this patch, however, I still get the audio artifacts (crackles) when I boot my laptop (Latitude E7440): [1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line [1.058843] snd_hda_codec_realtek hdaudioC1D0: speaker_outs=1 (0x14/0x0/0x0/0x0/0x0) [1.058846] snd_hda_codec_realtek hdaudioC1D0: hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [1.058849] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0 [1.058851] snd_hda_codec_realtek hdaudioC1D0:inputs: [1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19 [1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a [1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12 4.0.4 was fine. Does it happen only once at boot (i.e. at power up), or happens always at runtime PM? If it's a once-off boot thing, the patch shouldn't have much effect. Something else, very subtle thing, e.g. the order of verb execution, might cause this kind of problem. Only at power up. I've also suspend-resumed twice and can confirm it's OK. There's a _very_ brief click at suspend (when the power is cut), but it looks like a plain circuitry thing. I probably didn't notice it before because I wasn't looking for it. Thanks. Do you get the same click noise when reloading snd-hda-intel driver? Also, does it happen when booting in runlevel 3? Last but not least, a patch like below has any effect? Takashi --- diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3077,6 +3077,8 @@ static unsigned int hda_set_power_state(struct hda_codec *codec, break; } + if (power_state == AC_PWRST_D0) + msleep(100); return state; } Reloading snd-hda-intel does not trigger the noise, but it helps. I've noticed that the clicks appear when loading/reloading pulseaudio. $ pulseaudio -k will spawn a new child in background (probably asked by kmix) and immediately I hear the noise. Reloading the driver makes the problem go away. Hm. It's a bit inconsistent, but still this can be only at the full power up
Re: Audio crackles with 4.1-rc1
On Wed, 10 Jun 2015 20:23:01 +0200 Takashi Iwai wrote: From: Takashi Iwai ti...@suse.de Subject: [PATCH] ALSA: hda - Reduce click noise at power up Some machines suffer from click noises at power up with the recent kernels, and this seems triggered at the power transition and the immediate verb executions. As a workaround, put a short delay (10ms) right after the D0 transition. There are a few places that have the same kind of delays, especially in the resume path. I guess they can be removed (or reduced) after this patch. But, since the delay is relatively small, let's do it later as a cleanup. Reported-by: Mihai Donțu mihai.do...@gmail.com Signed-off-by: Takashi Iwai ti...@suse.de --- sound/pci/hda/hda_codec.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index b7782212dd64..38f5509ee52f 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3077,6 +3077,9 @@ static unsigned int hda_set_power_state(struct hda_codec *codec, break; } + if (power_state == AC_PWRST_D0) + msleep(10); + return state; } I take back my previous observations. I was at work and did not have access to headphones (one of those days). Now I'm at home, it's 1 AM, very quiet, and I notice the following: * on speakers: the click reproduces but with _very_ low amplitude; msleep(100) is unnoticeable, but msleep(10) is, barely; * on headphones: the moment I plug them I hear a loud static sound (like an old, untuned AM radio). If I play something, the static disappears. If I pause, the static returns after ~15s. -- Mihai Donțu -- 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: atomic_inc and spin_lock_irq
On Thu, 18 Dec 2014 21:07:46 + Rogelio M. Serrano Jr. wrote: > whats the difference between: > > atomic_inc(>count); It is intended to atomically increment a variable of a standard size (int/long). See [1] for more information. > and > > spin_lock_irq(>lock); > ++port->count; > spin_unlock_irq(>lock); These are intended to be used when larger changes are to be made in an atomic fashion (not just increments). See [2] for details and [3] for an example. [1] https://en.wikipedia.org/wiki/Fetch-and-add [2] http://lxr.free-electrons.com/source/include/linux/spinlock_api_smp.h#L104 [3] http://lxr.free-electrons.com/source/arch/x86/mm/mmio-mod.c#L265 -- Mihai Donțu -- 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: atomic_inc and spin_lock_irq
On Thu, 18 Dec 2014 21:07:46 + Rogelio M. Serrano Jr. wrote: whats the difference between: atomic_inc(port-count); It is intended to atomically increment a variable of a standard size (int/long). See [1] for more information. and spin_lock_irq(port-lock); ++port-count; spin_unlock_irq(port-lock); These are intended to be used when larger changes are to be made in an atomic fashion (not just increments). See [2] for details and [3] for an example. [1] https://en.wikipedia.org/wiki/Fetch-and-add [2] http://lxr.free-electrons.com/source/include/linux/spinlock_api_smp.h#L104 [3] http://lxr.free-electrons.com/source/arch/x86/mm/mmio-mod.c#L265 -- Mihai Donțu -- 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: bluetooth related firmware loader spew on resume.
On Wed, 26 Nov 2014 16:19:49 +0100 Takashi Iwai wrote: > At Wed, 26 Nov 2014 16:56:09 +0200, > Mihai Donțu wrote: > > > > On Tue, 11 Nov 2014 13:12:28 -0500 Dave Jones wrote: > > > Since the addition of 10d4c6736ea "Bluetooth: btusb: Add Broadcom patch > > > RAM support", I (and a number of other people[*]) have been seeing > > > this trace on resume from suspend. > > > > > > WARNING: CPU: 1 PID: 8565 at drivers/base/firmware_class.c:1127 > > > _request_firmware+0x4c1/0x7c0() > > > CPU: 1 PID: 8565 Comm: kworker/u17:0 Not tainted 3.17.2-200.fc20.x86_64 #1 > > > Hardware name: LENOVO 2356JK8/2356JK8, BIOS G7ET94WW (2.54 ) 04/30/2013 > > > Workqueue: hci0 hci_power_on [bluetooth] > > > f52a564b 8800a8c63be8 817271cc > > > 8800a8c63c20 81094ced 8800a8c63d10 > > > 8801365ddf00 8801387b4b00 8800a8c63d08 fff5 > > > Call Trace: > > > [] dump_stack+0x45/0x56 > > > [] warn_slowpath_common+0x7d/0xa0 > > > [] warn_slowpath_null+0x1a/0x20 > > > [] _request_firmware+0x4c1/0x7c0 > > > [] ? snprintf+0x49/0x70 > > > [] request_firmware+0x31/0x50 > > > [] btusb_setup_bcm_patchram+0x83/0x550 [btusb] > > > [] ? rpm_idle+0xd6/0x2b0 > > > [] hci_dev_do_open+0xe1/0xa60 [bluetooth] > > > ACPI: \_SB_.PCI0.LPC_.EC__.BAT1: docking > > > Restarting tasks ... > > > [] ? ttwu_do_activate.constprop.90+0x5d/0x70 > > > [] hci_power_on+0x40/0x1e0 [bluetooth] > > > [] ? lock_timer_base.isra.34+0x2b/0x50 > > > [] process_one_work+0x149/0x3d0 > > > [] worker_thread+0x11b/0x490 > > > [] ? rescuer_thread+0x2e0/0x2e0 > > > [] kthread+0xd8/0xf0 > > > [] ? kthread_create_on_node+0x190/0x190 > > > [] ret_from_fork+0x7c/0xb0 > > > [] ? kthread_create_on_node+0x190/0x190 > > > ---[ end trace 75a0e9c7f33ebb4c ]--- > > > bluetooth hci0: firmware: brcm/BCM20702A0-0a5c-21e6.hcd will not be loaded > > > Bluetooth: hci0: BCM: patch brcm/BCM20702A0-0a5c-21e6.hcd not found > > > > > > > > > At first I thought it was just over-reaction to the file being missing, > > > but > > > looking at the WARN_ON, it appears that we're trying to invoke the > > > firmware > > > loader before userspace is back up ? > > > > > > In this (and probably other related) kernel, CONFIG_FW_LOADER_USER_HELPER > > > is unset, > > > in case that matters at all. > > > > > > Dave > > > > > > [*] https://bugzilla.kernel.org/show_bug.cgi?id=81821 > > > https://bugzilla.redhat.com/show_bug.cgi?id=1133378 > > > > I have the following during normal boot: > > > > [5.620796] Bluetooth: hci0: read Intel version: 370710018002030d00 > > [5.620822] bluetooth hci0: Direct firmware load for > > intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq failed with error -2 > > [5.620827] Bluetooth: hci0 failed to open Intel firmware file: > > intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq(-2) > > [5.620920] bluetooth hci0: Direct firmware load for > > intel/ibt-hw-37.7.bseq failed with error -2 > > [5.620922] Bluetooth: hci0 failed to open default Intel fw file: > > intel/ibt-hw-37.7.bseq > > [5.629910] EXT4-fs (sda2): mounted filesystem with ordered data mode. > > Opts: (null) > > [5.629916] VFS: Mounted root (ext4 filesystem) readonly on device 8:2. > > > > The driver is trying to load the firmware before root is mounted. Do I > > really need an initramfs? > > If btusb driver is loaded in initrd, you'd need the corresponding > firmware in initrd, too. The driver is built into the kernel and I don't use an initrd. I could probably create one, but it's a bit tricky with UEFI and a tad harder to maintain. -- Mihai Donțu -- 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: bluetooth related firmware loader spew on resume.
On Tue, 11 Nov 2014 13:12:28 -0500 Dave Jones wrote: > Since the addition of 10d4c6736ea "Bluetooth: btusb: Add Broadcom patch > RAM support", I (and a number of other people[*]) have been seeing > this trace on resume from suspend. > > WARNING: CPU: 1 PID: 8565 at drivers/base/firmware_class.c:1127 > _request_firmware+0x4c1/0x7c0() > CPU: 1 PID: 8565 Comm: kworker/u17:0 Not tainted 3.17.2-200.fc20.x86_64 #1 > Hardware name: LENOVO 2356JK8/2356JK8, BIOS G7ET94WW (2.54 ) 04/30/2013 > Workqueue: hci0 hci_power_on [bluetooth] > f52a564b 8800a8c63be8 817271cc > 8800a8c63c20 81094ced 8800a8c63d10 > 8801365ddf00 8801387b4b00 8800a8c63d08 fff5 > Call Trace: > [] dump_stack+0x45/0x56 > [] warn_slowpath_common+0x7d/0xa0 > [] warn_slowpath_null+0x1a/0x20 > [] _request_firmware+0x4c1/0x7c0 > [] ? snprintf+0x49/0x70 > [] request_firmware+0x31/0x50 > [] btusb_setup_bcm_patchram+0x83/0x550 [btusb] > [] ? rpm_idle+0xd6/0x2b0 > [] hci_dev_do_open+0xe1/0xa60 [bluetooth] > ACPI: \_SB_.PCI0.LPC_.EC__.BAT1: docking > Restarting tasks ... > [] ? ttwu_do_activate.constprop.90+0x5d/0x70 > [] hci_power_on+0x40/0x1e0 [bluetooth] > [] ? lock_timer_base.isra.34+0x2b/0x50 > [] process_one_work+0x149/0x3d0 > [] worker_thread+0x11b/0x490 > [] ? rescuer_thread+0x2e0/0x2e0 > [] kthread+0xd8/0xf0 > [] ? kthread_create_on_node+0x190/0x190 > [] ret_from_fork+0x7c/0xb0 > [] ? kthread_create_on_node+0x190/0x190 > ---[ end trace 75a0e9c7f33ebb4c ]--- > bluetooth hci0: firmware: brcm/BCM20702A0-0a5c-21e6.hcd will not be loaded > Bluetooth: hci0: BCM: patch brcm/BCM20702A0-0a5c-21e6.hcd not found > > > At first I thought it was just over-reaction to the file being missing, but > looking at the WARN_ON, it appears that we're trying to invoke the firmware > loader before userspace is back up ? > > In this (and probably other related) kernel, CONFIG_FW_LOADER_USER_HELPER is > unset, > in case that matters at all. > > Dave > > [*] https://bugzilla.kernel.org/show_bug.cgi?id=81821 > https://bugzilla.redhat.com/show_bug.cgi?id=1133378 I have the following during normal boot: [5.620796] Bluetooth: hci0: read Intel version: 370710018002030d00 [5.620822] bluetooth hci0: Direct firmware load for intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq failed with error -2 [5.620827] Bluetooth: hci0 failed to open Intel firmware file: intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq(-2) [5.620920] bluetooth hci0: Direct firmware load for intel/ibt-hw-37.7.bseq failed with error -2 [5.620922] Bluetooth: hci0 failed to open default Intel fw file: intel/ibt-hw-37.7.bseq [5.629910] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null) [5.629916] VFS: Mounted root (ext4 filesystem) readonly on device 8:2. The driver is trying to load the firmware before root is mounted. Do I really need an initramfs? Thanks, -- Mihai Donțu -- 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: bluetooth related firmware loader spew on resume.
On Tue, 11 Nov 2014 13:12:28 -0500 Dave Jones wrote: Since the addition of 10d4c6736ea Bluetooth: btusb: Add Broadcom patch RAM support, I (and a number of other people[*]) have been seeing this trace on resume from suspend. WARNING: CPU: 1 PID: 8565 at drivers/base/firmware_class.c:1127 _request_firmware+0x4c1/0x7c0() CPU: 1 PID: 8565 Comm: kworker/u17:0 Not tainted 3.17.2-200.fc20.x86_64 #1 Hardware name: LENOVO 2356JK8/2356JK8, BIOS G7ET94WW (2.54 ) 04/30/2013 Workqueue: hci0 hci_power_on [bluetooth] f52a564b 8800a8c63be8 817271cc 8800a8c63c20 81094ced 8800a8c63d10 8801365ddf00 8801387b4b00 8800a8c63d08 fff5 Call Trace: [817271cc] dump_stack+0x45/0x56 [81094ced] warn_slowpath_common+0x7d/0xa0 [81094e1a] warn_slowpath_null+0x1a/0x20 [814965c1] _request_firmware+0x4c1/0x7c0 [8137b9b9] ? snprintf+0x49/0x70 [814968f1] request_firmware+0x31/0x50 [a0943bf3] btusb_setup_bcm_patchram+0x83/0x550 [btusb] [8148ecf6] ? rpm_idle+0xd6/0x2b0 [a0649051] hci_dev_do_open+0xe1/0xa60 [bluetooth] ACPI: \_SB_.PCI0.LPC_.EC__.BAT1: docking Restarting tasks ... [810bcb3d] ? ttwu_do_activate.constprop.90+0x5d/0x70 [a064a1c0] hci_power_on+0x40/0x1e0 [bluetooth] [810f53fb] ? lock_timer_base.isra.34+0x2b/0x50 [810acc39] process_one_work+0x149/0x3d0 [810ad2bb] worker_thread+0x11b/0x490 [810ad1a0] ? rescuer_thread+0x2e0/0x2e0 [810b2318] kthread+0xd8/0xf0 [810b2240] ? kthread_create_on_node+0x190/0x190 [8172e7bc] ret_from_fork+0x7c/0xb0 [810b2240] ? kthread_create_on_node+0x190/0x190 ---[ end trace 75a0e9c7f33ebb4c ]--- bluetooth hci0: firmware: brcm/BCM20702A0-0a5c-21e6.hcd will not be loaded Bluetooth: hci0: BCM: patch brcm/BCM20702A0-0a5c-21e6.hcd not found At first I thought it was just over-reaction to the file being missing, but looking at the WARN_ON, it appears that we're trying to invoke the firmware loader before userspace is back up ? In this (and probably other related) kernel, CONFIG_FW_LOADER_USER_HELPER is unset, in case that matters at all. Dave [*] https://bugzilla.kernel.org/show_bug.cgi?id=81821 https://bugzilla.redhat.com/show_bug.cgi?id=1133378 I have the following during normal boot: [5.620796] Bluetooth: hci0: read Intel version: 370710018002030d00 [5.620822] bluetooth hci0: Direct firmware load for intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq failed with error -2 [5.620827] Bluetooth: hci0 failed to open Intel firmware file: intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq(-2) [5.620920] bluetooth hci0: Direct firmware load for intel/ibt-hw-37.7.bseq failed with error -2 [5.620922] Bluetooth: hci0 failed to open default Intel fw file: intel/ibt-hw-37.7.bseq [5.629910] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null) [5.629916] VFS: Mounted root (ext4 filesystem) readonly on device 8:2. The driver is trying to load the firmware before root is mounted. Do I really need an initramfs? Thanks, -- Mihai Donțu -- 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: bluetooth related firmware loader spew on resume.
On Wed, 26 Nov 2014 16:19:49 +0100
Takashi Iwai ti...@suse.de wrote:
At Wed, 26 Nov 2014 16:56:09 +0200,
Mihai Donțu wrote:
On Tue, 11 Nov 2014 13:12:28 -0500 Dave Jones wrote:
Since the addition of 10d4c6736ea Bluetooth: btusb: Add Broadcom patch
RAM support, I (and a number of other people[*]) have been seeing
this trace on resume from suspend.
WARNING: CPU: 1 PID: 8565 at drivers/base/firmware_class.c:1127
_request_firmware+0x4c1/0x7c0()
CPU: 1 PID: 8565 Comm: kworker/u17:0 Not tainted 3.17.2-200.fc20.x86_64 #1
Hardware name: LENOVO 2356JK8/2356JK8, BIOS G7ET94WW (2.54 ) 04/30/2013
Workqueue: hci0 hci_power_on [bluetooth]
f52a564b 8800a8c63be8 817271cc
8800a8c63c20 81094ced 8800a8c63d10
8801365ddf00 8801387b4b00 8800a8c63d08 fff5
Call Trace:
[817271cc] dump_stack+0x45/0x56
[81094ced] warn_slowpath_common+0x7d/0xa0
[81094e1a] warn_slowpath_null+0x1a/0x20
[814965c1] _request_firmware+0x4c1/0x7c0
[8137b9b9] ? snprintf+0x49/0x70
[814968f1] request_firmware+0x31/0x50
[a0943bf3] btusb_setup_bcm_patchram+0x83/0x550 [btusb]
[8148ecf6] ? rpm_idle+0xd6/0x2b0
[a0649051] hci_dev_do_open+0xe1/0xa60 [bluetooth]
ACPI: \_SB_.PCI0.LPC_.EC__.BAT1: docking
Restarting tasks ...
[810bcb3d] ? ttwu_do_activate.constprop.90+0x5d/0x70
[a064a1c0] hci_power_on+0x40/0x1e0 [bluetooth]
[810f53fb] ? lock_timer_base.isra.34+0x2b/0x50
[810acc39] process_one_work+0x149/0x3d0
[810ad2bb] worker_thread+0x11b/0x490
[810ad1a0] ? rescuer_thread+0x2e0/0x2e0
[810b2318] kthread+0xd8/0xf0
[810b2240] ? kthread_create_on_node+0x190/0x190
[8172e7bc] ret_from_fork+0x7c/0xb0
[810b2240] ? kthread_create_on_node+0x190/0x190
---[ end trace 75a0e9c7f33ebb4c ]---
bluetooth hci0: firmware: brcm/BCM20702A0-0a5c-21e6.hcd will not be loaded
Bluetooth: hci0: BCM: patch brcm/BCM20702A0-0a5c-21e6.hcd not found
At first I thought it was just over-reaction to the file being missing,
but
looking at the WARN_ON, it appears that we're trying to invoke the
firmware
loader before userspace is back up ?
In this (and probably other related) kernel, CONFIG_FW_LOADER_USER_HELPER
is unset,
in case that matters at all.
Dave
[*] https://bugzilla.kernel.org/show_bug.cgi?id=81821
https://bugzilla.redhat.com/show_bug.cgi?id=1133378
I have the following during normal boot:
[5.620796] Bluetooth: hci0: read Intel version: 370710018002030d00
[5.620822] bluetooth hci0: Direct firmware load for
intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq failed with error -2
[5.620827] Bluetooth: hci0 failed to open Intel firmware file:
intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq(-2)
[5.620920] bluetooth hci0: Direct firmware load for
intel/ibt-hw-37.7.bseq failed with error -2
[5.620922] Bluetooth: hci0 failed to open default Intel fw file:
intel/ibt-hw-37.7.bseq
[5.629910] EXT4-fs (sda2): mounted filesystem with ordered data mode.
Opts: (null)
[5.629916] VFS: Mounted root (ext4 filesystem) readonly on device 8:2.
The driver is trying to load the firmware before root is mounted. Do I
really need an initramfs?
If btusb driver is loaded in initrd, you'd need the corresponding
firmware in initrd, too.
The driver is built into the kernel and I don't use an initrd. I could
probably create one, but it's a bit tricky with UEFI and a tad harder
to maintain.
--
Mihai Donțu
--
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: [PATCHv8.1] fanotify: enable close-on-exec on events' fd when requested in fanotify_init()
On Thu, 02 Oct 2014 08:20:55 +0200 Yann Droneaud wrote:
> Hi,
>
> Le mercredi 01 octobre 2014 à 15:36 -0700, Andrew Morton a écrit :
> > On Mon, 29 Sep 2014 10:49:15 +0200 Yann Droneaud
> > wrote:
> >
> > > According to commit 80af258867648 ('fanotify: groups can specify
> > > their f_flags for new fd'), file descriptors created as part of
> > > file access notification events inherit flags from the
> > > event_f_flags argument passed to syscall fanotify_init(2).
> > >
> > > So while it is legal for userspace to call fanotify_init() with
> > > O_CLOEXEC as part of its second argument, O_CLOEXEC is currently
> > > silently ignored.
> > >
> > > Indeed event_f_flags are only given to dentry_open(), which only
> > > seems to care about O_ACCMODE and O_PATH in do_dentry_open(),
> > > O_DIRECT in open_check_o_direct() and O_LARGEFILE in
> > > generic_file_open().
> > >
> > > But it seems logical to set close-on-exec flag on the file
> > > descriptor if userspace is allowed to request it with O_CLOEXEC.
> > >
> > > In fact, according to some lookup on http://codesearch.debian.net/
> > > and various search engine, there's already some userspace code
> > > requesting it:
> > >
> > > - in systemd's readahead[2]:
> > >
> > > fanotify_fd = fanotify_init(FAN_CLOEXEC|FAN_NONBLOCK,
> > > O_RDONLY|O_LARGEFILE|O_CLOEXEC|O_NOATIME);
> > >
> > > - in clsync[3]:
> > >
> > > #define FANOTIFY_EVFLAGS (O_LARGEFILE|O_RDONLY|O_CLOEXEC)
> > >
> > > int fanotify_d = fanotify_init(FANOTIFY_FLAGS, FANOTIFY_EVFLAGS);
> > >
> > > - in examples [4] from "Filesystem monitoring in the Linux
> > > kernel" article[5] by Aleksander Morgado:
> > >
> > > if ((fanotify_fd = fanotify_init (FAN_CLOEXEC,
> > > O_RDONLY | O_CLOEXEC |
> > > O_LARGEFILE)) < 0)
> >
> > So we have a number of apps which are setting O_CLOEXEC, but it doesn't
> > actually work. With this change it *will* work, so the behaviour of
> > those apps might change, possibly breaking them?
> >
>
> In the other hand, not enabling close-on-exec might expose unwanted file
> descriptor to childs, creating security issues. YMMV.
>
As someone who uses fanotify for content introspection, I can say that
I am _explicitly_ marking the fd obtained via read() as O_CLOEXEC,
because I have encountered a situation where a child managed to create
a deadlock because it kept the fd open after the main application
responded with FAN_ALLOW.
--
Mihai Donțu
--
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: [PATCHv8.1] fanotify: enable close-on-exec on events' fd when requested in fanotify_init()
On Thu, 02 Oct 2014 08:20:55 +0200 Yann Droneaud wrote:
Hi,
Le mercredi 01 octobre 2014 à 15:36 -0700, Andrew Morton a écrit :
On Mon, 29 Sep 2014 10:49:15 +0200 Yann Droneaud ydrone...@opteya.com
wrote:
According to commit 80af258867648 ('fanotify: groups can specify
their f_flags for new fd'), file descriptors created as part of
file access notification events inherit flags from the
event_f_flags argument passed to syscall fanotify_init(2).
So while it is legal for userspace to call fanotify_init() with
O_CLOEXEC as part of its second argument, O_CLOEXEC is currently
silently ignored.
Indeed event_f_flags are only given to dentry_open(), which only
seems to care about O_ACCMODE and O_PATH in do_dentry_open(),
O_DIRECT in open_check_o_direct() and O_LARGEFILE in
generic_file_open().
But it seems logical to set close-on-exec flag on the file
descriptor if userspace is allowed to request it with O_CLOEXEC.
In fact, according to some lookup on http://codesearch.debian.net/
and various search engine, there's already some userspace code
requesting it:
- in systemd's readahead[2]:
fanotify_fd = fanotify_init(FAN_CLOEXEC|FAN_NONBLOCK,
O_RDONLY|O_LARGEFILE|O_CLOEXEC|O_NOATIME);
- in clsync[3]:
#define FANOTIFY_EVFLAGS (O_LARGEFILE|O_RDONLY|O_CLOEXEC)
int fanotify_d = fanotify_init(FANOTIFY_FLAGS, FANOTIFY_EVFLAGS);
- in examples [4] from Filesystem monitoring in the Linux
kernel article[5] by Aleksander Morgado:
if ((fanotify_fd = fanotify_init (FAN_CLOEXEC,
O_RDONLY | O_CLOEXEC |
O_LARGEFILE)) 0)
So we have a number of apps which are setting O_CLOEXEC, but it doesn't
actually work. With this change it *will* work, so the behaviour of
those apps might change, possibly breaking them?
In the other hand, not enabling close-on-exec might expose unwanted file
descriptor to childs, creating security issues. YMMV.
As someone who uses fanotify for content introspection, I can say that
I am _explicitly_ marking the fd obtained via read() as O_CLOEXEC,
because I have encountered a situation where a child managed to create
a deadlock because it kept the fd open after the main application
responded with FAN_ALLOW.
--
Mihai Donțu
--
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/
ath9k: dmar: DRHD: handling fault status reg 3
Hi, I have this device: 03:02.0 Network controller: Qualcomm Atheros AR9227 Wireless Network Adapter (rev 01) Subsystem: Qualcomm Atheros Device 0300 Flags: bus master, 66MHz, medium devsel, latency 168, IRQ 19 Memory at f7c0 (32-bit, non-prefetchable) [size=64K] Capabilities: [40] #80 [] Kernel driver in use: ath9k which works great, except dmesg keeps being spammed with messages like this one: [ 2880.027256] dmar: DRHD: handling fault status reg 3 [ 2880.027260] dmar: DMAR:[DMA Read] Request device [03:00.0] fault addr d000 DMAR:[fault reason 06] PTE Read access is not set Is this a driver issue or a hardware one? Can I somehow silence it without disabling the use of the IOMMU? Thanks, -- Mihai Donțu -- 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/
ath9k: dmar: DRHD: handling fault status reg 3
Hi, I have this device: 03:02.0 Network controller: Qualcomm Atheros AR9227 Wireless Network Adapter (rev 01) Subsystem: Qualcomm Atheros Device 0300 Flags: bus master, 66MHz, medium devsel, latency 168, IRQ 19 Memory at f7c0 (32-bit, non-prefetchable) [size=64K] Capabilities: [40] #80 [] Kernel driver in use: ath9k which works great, except dmesg keeps being spammed with messages like this one: [ 2880.027256] dmar: DRHD: handling fault status reg 3 [ 2880.027260] dmar: DMAR:[DMA Read] Request device [03:00.0] fault addr d000 DMAR:[fault reason 06] PTE Read access is not set Is this a driver issue or a hardware one? Can I somehow silence it without disabling the use of the IOMMU? Thanks, -- Mihai Donțu -- 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: possible viri in tarballs?
On Wed, 5 Feb 2014 09:15:34 -0500 Gene Heskett wrote: > I recently brought a daily system scan by clamscan back to life, and > its emailing me this: > > /home/gene/src/linux-3.8.2/Documentation/usb/gadget_multi.txt: > MBL_400944.UNOFFICIAL > FOUND /home/gene/src/linux-3.12.6/Documentation/usb/gadget_multi.txt: > MBL_400944.UNOFFICIAL > FOUND /home/gene/src/linux-3.8.3/Documentation/usb/gadget_multi.txt: > MBL_400944.UNOFFICIAL > FOUND /home/gene/src/linux-3.12.9/Documentation/usb/gadget_multi.txt: > MBL_400944.UNOFFICIAL > FOUND /home/gene/src/linux-3.4.36/Documentation/usb/gadget_multi.txt: > MBL_400944.UNOFFICIAL > FOUND /home/gene/src/linux-3.0.69/Documentation/usb/gadget_multi.txt: > MBL_400944.UNOFFICIAL > FOUND /home/gene/src/linux-3.2.40/Documentation/usb/gadget_multi.txt: > MBL_400944.UNOFFICIAL FOUND > > Repeat for several other kernel trees. > FP or ?? Most likely a FP, but try: https://www.virustotal.com/ -- Mihai Donțu -- 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: possible viri in tarballs?
On Wed, 5 Feb 2014 09:15:34 -0500 Gene Heskett wrote: I recently brought a daily system scan by clamscan back to life, and its emailing me this: /home/gene/src/linux-3.8.2/Documentation/usb/gadget_multi.txt: MBL_400944.UNOFFICIAL FOUND /home/gene/src/linux-3.12.6/Documentation/usb/gadget_multi.txt: MBL_400944.UNOFFICIAL FOUND /home/gene/src/linux-3.8.3/Documentation/usb/gadget_multi.txt: MBL_400944.UNOFFICIAL FOUND /home/gene/src/linux-3.12.9/Documentation/usb/gadget_multi.txt: MBL_400944.UNOFFICIAL FOUND /home/gene/src/linux-3.4.36/Documentation/usb/gadget_multi.txt: MBL_400944.UNOFFICIAL FOUND /home/gene/src/linux-3.0.69/Documentation/usb/gadget_multi.txt: MBL_400944.UNOFFICIAL FOUND /home/gene/src/linux-3.2.40/Documentation/usb/gadget_multi.txt: MBL_400944.UNOFFICIAL FOUND Repeat for several other kernel trees. FP or ?? Most likely a FP, but try: https://www.virustotal.com/ -- Mihai Donțu -- 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: Linux kernel API about sector count
On Mon, 11 Nov 2013 20:31:14 +0800 韩磊 wrote: > Can you tell me the API about the count of sector in linux kernel? > > which .h file and function? > Looking at fdisk (util-linux) there are several ioctls: * HDIO_GETGEO (linux/hdreg.h) * BLKGETSIZE64 (linux/fs.h), sector size is assumed 512 The HDIO interface *seems* to be legacy: http://www.mjmwired.net/kernel/Documentation/ioctl/hdio.txt Also see: https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/fdisks/fdisk.c I hope this helps a bit. -- Mihai Donțu -- 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: Linux kernel API about sector count
On Mon, 11 Nov 2013 20:31:14 +0800 韩磊 wrote: Can you tell me the API about the count of sector in linux kernel? which .h file and function? Looking at fdisk (util-linux) there are several ioctls: * HDIO_GETGEO (linux/hdreg.h) * BLKGETSIZE64 (linux/fs.h), sector size is assumed 512 The HDIO interface *seems* to be legacy: http://www.mjmwired.net/kernel/Documentation/ioctl/hdio.txt Also see: https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/fdisks/fdisk.c I hope this helps a bit. -- Mihai Donțu -- 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/
fanotify: don't merge permission events
Ben, Greg, Can you pull this[1] patch into your stable kernels (3.2, 3.4)? It fixes an unfortunate bug in fanotify where a multithreaded application can end up in an interruptible state, a situation which only a reboot can fix. Ultimately, I'm hoping that the fix ends up in Ubuntu's kernels (for which I have also created a request[2]). Thank you, [1] https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/fs/notify/fanotify?id=03a1cec1f17ac1a6041996b3e40f96b5a2f90e1b [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1148084 -- Mihai Donțu -- 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/
fanotify: don't merge permission events
Ben, Greg, Can you pull this[1] patch into your stable kernels (3.2, 3.4)? It fixes an unfortunate bug in fanotify where a multithreaded application can end up in an interruptible state, a situation which only a reboot can fix. Ultimately, I'm hoping that the fix ends up in Ubuntu's kernels (for which I have also created a request[2]). Thank you, [1] https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/fs/notify/fanotify?id=03a1cec1f17ac1a6041996b3e40f96b5a2f90e1b [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1148084 -- Mihai Donțu -- 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: my first post
On Wed, 17 Jul 2013 14:09:20 +0800 merrys...@tom.com wrote: > I have meeted a problem with linux kernel 2.6.X.X that my user app > wants to get thread kernel stack frame ponter(FP) from user space by > system call or /proc system or any other ways except driver. I do not > want to write a driver,) to finish it. I have endured this problem > for a long time. > > would anyone please to give me a hint to solve the problem. > (I'm ignoring the questionable practicality of this) People have gone to great lengths not to reveal sensitive addresses from ring 0, %rsp/%rbp being subject to this restriction. If you configure your kernel to expose full /dev/mem (CONFIG_STRICT_DEVMEM=n), then using the image for your running kernel and with a bit of DWARF knowledge, I _think_ it's possible to list the current running threads and their contexts (ie. CPU registers). Otherwise, I don't believe there's any way you can achieve this, other than exploiting a bug. :-) -- Mihai Donțu -- 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: my first post
On Wed, 17 Jul 2013 14:09:20 +0800 merrys...@tom.com wrote: I have meeted a problem with linux kernel 2.6.X.X that my user app wants to get thread kernel stack frame ponter(FP) from user space by system call or /proc system or any other ways except driver. I do not want to write a driver,) to finish it. I have endured this problem for a long time. would anyone please to give me a hint to solve the problem. (I'm ignoring the questionable practicality of this) People have gone to great lengths not to reveal sensitive addresses from ring 0, %rsp/%rbp being subject to this restriction. If you configure your kernel to expose full /dev/mem (CONFIG_STRICT_DEVMEM=n), then using the image for your running kernel and with a bit of DWARF knowledge, I _think_ it's possible to list the current running threads and their contexts (ie. CPU registers). Otherwise, I don't believe there's any way you can achieve this, other than exploiting a bug. :-) -- Mihai Donțu -- 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: e1000e 3.9-rc1 suspend failure (was: Re: e1000e: nic does not work properly after cold power on)
On Mon, 4 Mar 2013 22:48:30 +0100 Borislav Petkov wrote: > On Mon, Mar 04, 2013 at 07:15:07PM +0100, Morten Stevens wrote: > > Can you reproduce this with linux 3.9-rc1? 3.9-rc1 has the latest > > upstream driver (e1000e 2.2.14) which contains many bugfixes. > On my system (ThinkPad T420) I get: [ 10.694743] e1000e: Intel(R) PRO/1000 Network Driver - 2.2.14-k [ 10.694746] e1000e: Copyright(c) 1999 - 2013 Intel Corporation. [ 10.694852] e1000e :00:19.0: setting latency timer to 64 [ 10.694911] e1000e :00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode [ 10.694949] e1000e :00:19.0: irq 47 for MSI/MSI-X [ 10.975086] e1000e :00:19.0 eth0: registered PHC clock [ 10.975091] e1000e :00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 00:21:cc:70:17:a0 [ 10.975093] e1000e :00:19.0 eth0: Intel(R) PRO/1000 Network Connection [ 10.975127] e1000e :00:19.0 eth0: MAC: 10, PHY: 11, PBA No: 1000FF-0FF [ 89.716695] e1000e :00:19.0 eth0: Hardware Error [ 90.025403] e1000e :00:19.0 eth0: Timesync Tx Control register not set as expected [ 90.349197] e1000e :00:19.0: irq 47 for MSI/MSI-X [ 90.449760] e1000e :00:19.0: irq 47 for MSI/MSI-X The 'hardware error' line caught my attention. > This e1000e thing gets more b0rked by the minute. This is what happens > when I try to suspend with 3.9-rc1: > > [ 83.502908] PM: Syncing filesystems ... done. > [ 83.509886] Freezing user space processes ... (elapsed 0.01 > seconds) done. [ 83.523352] PM: Preallocating image memory... done > (allocated 95652 pages) [ 83.675083] PM: Allocated 382608 kbytes in > 0.15 seconds (2550.72 MB/s) [ 83.675782] Freezing remaining > freezable tasks ... (elapsed 0.01 seconds) done. [ 83.688524] > Suspending console(s) (use no_console_suspend to debug) > [ 84.251024] e1000e :00:19.0 eth0: Hardware Error > [ 84.458866] [ cut here ] [ 84.458871] > WARNING: at kernel/irq/manage.c:1249 __free_irq+0xa3/0x1e0() > [ 84.458872] Hardware name: 2320CTO [ 84.458872] Trying to free > already-free IRQ 20 [ 84.458898] Modules linked in: > cpufreq_powersave cpufreq_userspace cpufreq_conservative > cpufreq_stats uinput loop hid_generic usb hid hid coretemp kvm_intel > arc4 kvm crc32_pclmul iwldvm crc32c_intel ghash_clmulni_intel > mac80211 aesni_intel xts ipv6 aes_x86_64 lr w gf128mul ablk_helper > cryptd iTCO_wdt iTCO_vendor_support iwlwifi sdhci_pci sdhci cfg80211 > snd_hda_codec_hdmi snd_hda_codec_realtek mmc_core microcode e1000e > thinkpad_acpi pcspkr lpc_ich i2c_i801 mfd_core nvram snd_hda_intel > rfkill snd_hda_codec battery ac snd_hw dep led_class snd_pcm > snd_page_alloc snd_timer snd acpi_cpufreq soundcore mperf ptp wmi > pps_core xhci_hcd ehci_pci ehci_hcd processo r thermal [ 84.458900] > Pid: 3353, comm: kworker/u:35 Tainted: GW3.9.0-rc1 #1 > [ 84.458901] Call Trace: [ 84.458905] [] > warn_slowpath_common+0x7f/0xc0 [ 84.458907] [] > warn_slowpath_fmt+0x46/0x50 [ 84.458910] [] ? > _raw_spin_lock_irqsave+0x4e/0x60 [ 84.458911] > [] ? __free_irq+0x55/0x1e0 [ 84.458913] > [] __free_irq+0xa3/0x1e0 [ 84.458914] > [] free_irq+0x54/0xc0 [ 84.458919] > [] e1000_free_irq+0x7d/0x90 [e1000e] > [ 84.458922] [] __e1000_shutdown+0x8f/0x8a0 > [e1000e] [ 84.458924] [] ? > __device_suspend+0xb7/0x200 [ 84.458927] [] ? > get_parent_ip+0x11/0x50 [ 84.458931] [] > e1000_suspend+0x23/0x50 [e1000e] [ 84.458932] > [] ? __device_suspend+0xb7/0x200 [ 84.458933] > [] ? sub_preempt_count+0x79/0xd0 [ 84.458936] > [] pci_pm_freeze+0x55/0xc0 [ 84.458937] > [] ? pci_pm_resume_noirq+0xd0/0xd0 [ 84.458938] > [] dpm_run_callback.isra.5+0x25/0x50 > [ 84.458939] [] __device_suspend+0xe3/0x200 > [ 84.458941] [] async_suspend+0x1f/0xa0 > [ 84.458942] [] async_run_entry_fn+0x3b/0x140 > [ 84.458944] [] process_one_work+0x1ed/0x510 > [ 84.458946] [] ? process_one_work+0x18b/0x510 > [ 84.458948] [] worker_thread+0x115/0x390 > [ 84.458949] [] ? manage_workers+0x300/0x300 > [ 84.458951] [] kthread+0xea/0xf0 > [ 84.458953] [] ? > kthread_create_on_node+0x160/0x160 [ 84.458954] > [] ret_from_fork+0x7c/0xb0 [ 84.458955] > [] ? kthread_create_on_node+0x160/0x160 > [ 84.458956] ---[ end trace 3114e23ce50d2357 ]--- [ 85.082276] > pci_pm_freeze(): e1000_suspend+0x0/0x50 [e1000e] returns -2 > [ 85.082278] dpm_run_callback(): pci_pm_freeze+0x0/0xc0 returns -2 > [ 85.082281] PM: Device :00:19.0 failed to freeze async: error > -2 > > Let's add more folks to CC. > -- Mihai Donțu -- 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/
e1000e: nic does not work properly after cold power on
Hi, I apologize in advance for posting on two lists at once and for not even being subscribed to e1000-devel. Ever since upgrading to 3.8.x, I'm unable to use my wired connection (e1000e - Intel Corporation 82579LM Gigabit) immediately after power on. I have to boot into an older kernel (3.2.0 I happen to have around) and _then_ boot into 3.8.1. There are no errors in dmesg that I can see. The only one behaving strangely is NetworkManager who simply says the device is managed and skips it. Also, there's no 'link becomes ready' in dmesg either (and I swear the cable is plugged in). Has anyone else encountered this? Thanks, -- Mihai Donțu dmesg-3.8.1-e1000e.txt.gz Description: application/gzip
e1000e: nic does not work properly after cold power on
Hi, I apologize in advance for posting on two lists at once and for not even being subscribed to e1000-devel. Ever since upgrading to 3.8.x, I'm unable to use my wired connection (e1000e - Intel Corporation 82579LM Gigabit) immediately after power on. I have to boot into an older kernel (3.2.0 I happen to have around) and _then_ boot into 3.8.1. There are no errors in dmesg that I can see. The only one behaving strangely is NetworkManager who simply says the device is managed and skips it. Also, there's no 'link becomes ready' in dmesg either (and I swear the cable is plugged in). Has anyone else encountered this? Thanks, -- Mihai Donțu dmesg-3.8.1-e1000e.txt.gz Description: application/gzip
Re: e1000e 3.9-rc1 suspend failure (was: Re: e1000e: nic does not work properly after cold power on)
On Mon, 4 Mar 2013 22:48:30 +0100 Borislav Petkov wrote: On Mon, Mar 04, 2013 at 07:15:07PM +0100, Morten Stevens wrote: Can you reproduce this with linux 3.9-rc1? 3.9-rc1 has the latest upstream driver (e1000e 2.2.14) which contains many bugfixes. On my system (ThinkPad T420) I get: [ 10.694743] e1000e: Intel(R) PRO/1000 Network Driver - 2.2.14-k [ 10.694746] e1000e: Copyright(c) 1999 - 2013 Intel Corporation. [ 10.694852] e1000e :00:19.0: setting latency timer to 64 [ 10.694911] e1000e :00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode [ 10.694949] e1000e :00:19.0: irq 47 for MSI/MSI-X [ 10.975086] e1000e :00:19.0 eth0: registered PHC clock [ 10.975091] e1000e :00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 00:21:cc:70:17:a0 [ 10.975093] e1000e :00:19.0 eth0: Intel(R) PRO/1000 Network Connection [ 10.975127] e1000e :00:19.0 eth0: MAC: 10, PHY: 11, PBA No: 1000FF-0FF [ 89.716695] e1000e :00:19.0 eth0: Hardware Error [ 90.025403] e1000e :00:19.0 eth0: Timesync Tx Control register not set as expected [ 90.349197] e1000e :00:19.0: irq 47 for MSI/MSI-X [ 90.449760] e1000e :00:19.0: irq 47 for MSI/MSI-X The 'hardware error' line caught my attention. This e1000e thing gets more b0rked by the minute. This is what happens when I try to suspend with 3.9-rc1: [ 83.502908] PM: Syncing filesystems ... done. [ 83.509886] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 83.523352] PM: Preallocating image memory... done (allocated 95652 pages) [ 83.675083] PM: Allocated 382608 kbytes in 0.15 seconds (2550.72 MB/s) [ 83.675782] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [ 83.688524] Suspending console(s) (use no_console_suspend to debug) [ 84.251024] e1000e :00:19.0 eth0: Hardware Error [ 84.458866] [ cut here ] [ 84.458871] WARNING: at kernel/irq/manage.c:1249 __free_irq+0xa3/0x1e0() [ 84.458872] Hardware name: 2320CTO [ 84.458872] Trying to free already-free IRQ 20 [ 84.458898] Modules linked in: cpufreq_powersave cpufreq_userspace cpufreq_conservative cpufreq_stats uinput loop hid_generic usb hid hid coretemp kvm_intel arc4 kvm crc32_pclmul iwldvm crc32c_intel ghash_clmulni_intel mac80211 aesni_intel xts ipv6 aes_x86_64 lr w gf128mul ablk_helper cryptd iTCO_wdt iTCO_vendor_support iwlwifi sdhci_pci sdhci cfg80211 snd_hda_codec_hdmi snd_hda_codec_realtek mmc_core microcode e1000e thinkpad_acpi pcspkr lpc_ich i2c_i801 mfd_core nvram snd_hda_intel rfkill snd_hda_codec battery ac snd_hw dep led_class snd_pcm snd_page_alloc snd_timer snd acpi_cpufreq soundcore mperf ptp wmi pps_core xhci_hcd ehci_pci ehci_hcd processo r thermal [ 84.458900] Pid: 3353, comm: kworker/u:35 Tainted: GW3.9.0-rc1 #1 [ 84.458901] Call Trace: [ 84.458905] [8103ef7f] warn_slowpath_common+0x7f/0xc0 [ 84.458907] [8103f076] warn_slowpath_fmt+0x46/0x50 [ 84.458910] [81537bfe] ? _raw_spin_lock_irqsave+0x4e/0x60 [ 84.458911] [810bc8d5] ? __free_irq+0x55/0x1e0 [ 84.458913] [810bc923] __free_irq+0xa3/0x1e0 [ 84.458914] [810bcab4] free_irq+0x54/0xc0 [ 84.458919] [a017745d] e1000_free_irq+0x7d/0x90 [e1000e] [ 84.458922] [a01834af] __e1000_shutdown+0x8f/0x8a0 [e1000e] [ 84.458924] [813c92a7] ? __device_suspend+0xb7/0x200 [ 84.458927] [81073b71] ? get_parent_ip+0x11/0x50 [ 84.458931] [a0183d33] e1000_suspend+0x23/0x50 [e1000e] [ 84.458932] [813c92a7] ? __device_suspend+0xb7/0x200 [ 84.458933] [8153c049] ? sub_preempt_count+0x79/0xd0 [ 84.458936] [812a2ff5] pci_pm_freeze+0x55/0xc0 [ 84.458937] [812a2fa0] ? pci_pm_resume_noirq+0xd0/0xd0 [ 84.458938] [813c8b45] dpm_run_callback.isra.5+0x25/0x50 [ 84.458939] [813c92d3] __device_suspend+0xe3/0x200 [ 84.458941] [813c940f] async_suspend+0x1f/0xa0 [ 84.458942] [8106bcfb] async_run_entry_fn+0x3b/0x140 [ 84.458944] [8105d00d] process_one_work+0x1ed/0x510 [ 84.458946] [8105cfab] ? process_one_work+0x18b/0x510 [ 84.458948] [8105e7b5] worker_thread+0x115/0x390 [ 84.458949] [8105e6a0] ? manage_workers+0x300/0x300 [ 84.458951] [81064e2a] kthread+0xea/0xf0 [ 84.458953] [81064d40] ? kthread_create_on_node+0x160/0x160 [ 84.458954] [8153ff9c] ret_from_fork+0x7c/0xb0 [ 84.458955] [81064d40] ? kthread_create_on_node+0x160/0x160 [ 84.458956] ---[ end trace 3114e23ce50d2357 ]--- [ 85.082276] pci_pm_freeze(): e1000_suspend+0x0/0x50 [e1000e] returns -2 [ 85.082278] dpm_run_callback(): pci_pm_freeze+0x0/0xc0 returns -2 [ 85.082281] PM: Device :00:19.0 failed to freeze async: error -2 Let's add more folks to CC. -- Mihai Donțu -- To unsubscribe from this list
Re: [PATCH] fanotify: to differ file access event from different threads
: CS: 0010 DS: ES: CR0: 8005003b CR2: 7fb5d310 CR3: 1ca06000 CR4: 06f0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process swapper/0 (pid: 0, threadinfo 81c0, task 81c0d020) Stack: 2710 81c31c00 81c31d00 88003fc03dc8 81033231 000a 88003fc0ec40 88003fc03e18 810defbe 8801 81c32d00 Call Trace: [] arch_trigger_all_cpu_backtrace+0x61/0xa0 [] __rcu_pending+0x3ae/0x420 [] rcu_check_callbacks+0x79/0x1e0 [] update_process_times+0x48/0x90 [] tick_sched_timer+0x64/0xc0 [] __run_hrtimer+0x76/0x1f0 [] ? tick_nohz_handler+0x100/0x100 [] hrtimer_interrupt+0xf7/0x230 [] smp_apic_timer_interrupt+0x69/0x99 [] apic_timer_interrupt+0x6e/0x80 [] ? sched_clock_local+0x25/0x90 [] ? native_safe_halt+0xb/0x10 [] default_idle+0x53/0x1d0 [] cpu_idle+0xd6/0x120 [] rest_init+0x72/0x74 [] start_kernel+0x3b0/0x3bd [] x86_64_start_reservations+0x132/0x136 [] ? early_idt_handlers+0x140/0x140 [] x86_64_start_kernel+0x102/0x111 [...] It happens after my application runs for half an hour or so. However, I don't see how this could possibly solve the problem I've observed: due to a race, a kernel thread ends up doing wait_event() on an event which soon after is merged by a different thread into a new one which becomes the actual event to be "received" by the content introspection application. It's easily reproducible with a simple script: $ while true; do cp -f /root/eicar.com /root/watched-dir; done all the while the fanotify application does a re-open (RD -> RDWR) and truncate(0), on multiple threads. (I do a fanotify_init(O_RDONLY) because of surprise ETXTBSY) Anyway, regardless of how I use the API the race needs to be eliminated somehow. So my problem now is: how do I switch all wait_event()-users to the new event created by fanotify_merge()? -- Mihai Donțu -- 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] fanotify: to differ file access event from different threads
8801 81c32d00 Call Trace: IRQ [81033231] arch_trigger_all_cpu_backtrace+0x61/0xa0 [810defbe] __rcu_pending+0x3ae/0x420 [810df329] rcu_check_callbacks+0x79/0x1e0 [81078068] update_process_times+0x48/0x90 [8109b4f4] tick_sched_timer+0x64/0xc0 [8108df56] __run_hrtimer+0x76/0x1f0 [8109b490] ? tick_nohz_handler+0x100/0x100 [8108e907] hrtimer_interrupt+0xf7/0x230 [81650409] smp_apic_timer_interrupt+0x69/0x99 [8164e2de] apic_timer_interrupt+0x6e/0x80 EOI [810904a5] ? sched_clock_local+0x25/0x90 [8103cedb] ? native_safe_halt+0xb/0x10 [8101c6b3] default_idle+0x53/0x1d0 [81013236] cpu_idle+0xd6/0x120 [816172ce] rest_init+0x72/0x74 [81cfcba5] start_kernel+0x3b0/0x3bd [81cfc347] x86_64_start_reservations+0x132/0x136 [81cfc140] ? early_idt_handlers+0x140/0x140 [81cfc44d] x86_64_start_kernel+0x102/0x111 [...] It happens after my application runs for half an hour or so. However, I don't see how this could possibly solve the problem I've observed: due to a race, a kernel thread ends up doing wait_event() on an event which soon after is merged by a different thread into a new one which becomes the actual event to be received by the content introspection application. It's easily reproducible with a simple script: $ while true; do cp -f /root/eicar.com /root/watched-dir; done all the while the fanotify application does a re-open (RD - RDWR) and truncate(0), on multiple threads. (I do a fanotify_init(O_RDONLY) because of surprise ETXTBSY) Anyway, regardless of how I use the API the race needs to be eliminated somehow. So my problem now is: how do I switch all wait_event()-users to the new event created by fanotify_merge()? -- Mihai Donțu -- 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: s2ram + usb
On Tuesday 25 September 2007, Jiri Kosina wrote: > (linux-usb-devel added to CC) > > On Tue, 25 Sep 2007, Mihai Don?u wrote: > > > [1.743528] Restarting tasks ... <3>hub 1-0:1.0: port 5 disabled by hub > > (EMI?), re-enabling... > > [1.743563] usb 1-5: USB disconnect, address 3 > > [1.782485] usb 1-5: new high speed USB device using ehci_hcd and > > address 6 > > [1.785747] done. > > [1.831805] usb 1-5: configuration #1 chosen from 1 choice > > [1.834418] scsi3 : SCSI emulation for USB Mass Storage devices > > [1.834741] usb-storage: device found at 6 > > [1.834785] usb-storage: waiting for device to settle before scanning > > [1.845293] ohci_hcd :00:13.1: Unlink after no-IRQ? Controller is > > probably using the wrong IRQ. > > Hi Mihai, > > does booting with 'irqpoll' kernel parameter have any effect? No, 'sorry. I get the same message as above. Strangely, 'irqpoll' disabled 'alt-sysreq-' (noticed this after power up). -- Mihai Donțu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
s2ram + usb
Hi, I've been trying to make suspend-to-ram part of my day-by-day life, but there are still some issues. For example, I did: $ sync && echo "mem" >/sys/power/state (I don't know if sync is needed or helps, but I do it anyway - I *really* love my data) unplugged everything (power, mouse, network cable, ...), got to work, plugged everything back, power up, dmesg: [1.367928] Restarting tasks ... <4>ohci_hcd :00:13.1: Unlink after no-IRQ? Controller is probably using the wrong IRQ. [1.402715] done. [1.627564] tg3: eth0: Link is up at 100 Mbps, full duplex. [1.627568] tg3: eth0: Flow control is on for TX and on for RX. [ 10.448935] usb 3-3: USB disconnect, address 3 [ 10.811866] ohci_hcd :00:13.1: IRQ INTR_SF lossage [ 10.811871] ohci_hcd :00:13.1: leak ed 810037991050 (#00) state 0 (has tds) After this my mouse doesn't work and I'm unable to reboot/poweroff my laptop (not even alt+sysreq+b work). It locks hard. I have been playing with pci=assign-busses (thinking about IRQ-s here) and pci=noacpi. No result. However, with pci=assign-busses I got this (a small variation of the message above): [1.743528] Restarting tasks ... <3>hub 1-0:1.0: port 5 disabled by hub (EMI?), re-enabling... [1.743563] usb 1-5: USB disconnect, address 3 [1.782485] usb 1-5: new high speed USB device using ehci_hcd and address 6 [1.785747] done. [1.831805] usb 1-5: configuration #1 chosen from 1 choice [1.834418] scsi3 : SCSI emulation for USB Mass Storage devices [1.834741] usb-storage: device found at 6 [1.834785] usb-storage: waiting for device to settle before scanning [1.845293] ohci_hcd :00:13.1: Unlink after no-IRQ? Controller is probably using the wrong IRQ. I looked in 'kernel-parameters.txt" and in "x86_86/boot-options.txt" but I did not find anything that could help (that is: usb related). Has anyone else experienced this? I'll try to pull 2.6.23-rc8 tonight and play with it. I've seen some ACPI related stuff in ChangeLog. Who knows ... Thanks, -- Mihai Donțu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc7 + radeonfb/s2ram
On Monday 24 September 2007, Andreas Herrmann wrote: > Have you tried to boot your kernel with > >video=radeonfb:noaccel > > I usual add this kernel parameter when running radeonfb and X. > > Otherwise I've observed the same symptoms (e.g. with my radeon card > at home: Radeon X300SE, 1002:5b70). It works. Golden option. Should be documented somewhere. Thanks, -- Mihai Donțu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc7 + radeonfb/s2ram
On Monday 24 September 2007, Andreas Herrmann wrote: Have you tried to boot your kernel with video=radeonfb:noaccel I usual add this kernel parameter when running radeonfb and X. Otherwise I've observed the same symptoms (e.g. with my radeon card at home: Radeon X300SE, 1002:5b70). It works. Golden option. Should be documented somewhere. Thanks, -- Mihai Donțu - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
s2ram + usb
Hi, I've been trying to make suspend-to-ram part of my day-by-day life, but there are still some issues. For example, I did: $ sync echo mem /sys/power/state (I don't know if sync is needed or helps, but I do it anyway - I *really* love my data) unplugged everything (power, mouse, network cable, ...), got to work, plugged everything back, power up, dmesg: [1.367928] Restarting tasks ... 4ohci_hcd :00:13.1: Unlink after no-IRQ? Controller is probably using the wrong IRQ. [1.402715] done. [1.627564] tg3: eth0: Link is up at 100 Mbps, full duplex. [1.627568] tg3: eth0: Flow control is on for TX and on for RX. [ 10.448935] usb 3-3: USB disconnect, address 3 [ 10.811866] ohci_hcd :00:13.1: IRQ INTR_SF lossage [ 10.811871] ohci_hcd :00:13.1: leak ed 810037991050 (#00) state 0 (has tds) After this my mouse doesn't work and I'm unable to reboot/poweroff my laptop (not even alt+sysreq+b work). It locks hard. I have been playing with pci=assign-busses (thinking about IRQ-s here) and pci=noacpi. No result. However, with pci=assign-busses I got this (a small variation of the message above): [1.743528] Restarting tasks ... 3hub 1-0:1.0: port 5 disabled by hub (EMI?), re-enabling... [1.743563] usb 1-5: USB disconnect, address 3 [1.782485] usb 1-5: new high speed USB device using ehci_hcd and address 6 [1.785747] done. [1.831805] usb 1-5: configuration #1 chosen from 1 choice [1.834418] scsi3 : SCSI emulation for USB Mass Storage devices [1.834741] usb-storage: device found at 6 [1.834785] usb-storage: waiting for device to settle before scanning [1.845293] ohci_hcd :00:13.1: Unlink after no-IRQ? Controller is probably using the wrong IRQ. I looked in 'kernel-parameters.txt and in x86_86/boot-options.txt but I did not find anything that could help (that is: usb related). Has anyone else experienced this? I'll try to pull 2.6.23-rc8 tonight and play with it. I've seen some ACPI related stuff in ChangeLog. Who knows ... Thanks, -- Mihai Donțu - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: s2ram + usb
On Tuesday 25 September 2007, Jiri Kosina wrote: (linux-usb-devel added to CC) On Tue, 25 Sep 2007, Mihai Don?u wrote: [1.743528] Restarting tasks ... 3hub 1-0:1.0: port 5 disabled by hub (EMI?), re-enabling... [1.743563] usb 1-5: USB disconnect, address 3 [1.782485] usb 1-5: new high speed USB device using ehci_hcd and address 6 [1.785747] done. [1.831805] usb 1-5: configuration #1 chosen from 1 choice [1.834418] scsi3 : SCSI emulation for USB Mass Storage devices [1.834741] usb-storage: device found at 6 [1.834785] usb-storage: waiting for device to settle before scanning [1.845293] ohci_hcd :00:13.1: Unlink after no-IRQ? Controller is probably using the wrong IRQ. Hi Mihai, does booting with 'irqpoll' kernel parameter have any effect? No, 'sorry. I get the same message as above. Strangely, 'irqpoll' disabled 'alt-sysreq-cmd' (noticed this after power up). -- Mihai Donțu - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc7 + radeonfb/s2ram
On Sunday 23 September 2007, Rafael J. Wysocki wrote: > On Sunday, 23 September 2007 20:31, Mihai Donțu wrote: > > On Sunday 23 September 2007, Mihai Donțu wrote: > > > I'll to do a full cleanup and start all over. I'm going to nail this > > > thing down if > > > it's the last thing I do! (so help me God) :) > > > > Found it! > > > > The problem was "Framebuffer Console support". It was enabled by default > > in older > > configs (like 2.6.22.7) but I think someone noticed this was bad and put > > it to > > default N in newer (2.6.23-rc7); and since I reused the .config from > > 2.6.21.3 ... > > > > So there, if one wants "ATI Radeon display support" on Radeon XPRESS 200M > > with > > X using radeon_drv.so, *should* put "Framebuffer Console support" to N > > (if it's > > not already). > > > > Now all I have to do is figure out what's the equivalent of "vga=791" on > > the new > > kernel (default text console looks really bad on my laptop). > > > > Sorry for all the noise (and spam), > > No, this actually is valuable information, thanks for it. :-) > > [I have missed your first post, sorry for that.] Don't worry. Now, one last update (I've just ran into it): I was preparing my laptop (to brag tomorrow with my new s2ram thinggie) when I noticed that after powering up from a suspend-to-ram, X doesn't like radeonfb working behind it's back, as a result it goes crazy (corrupted pixmaps and such). I should have tested these two together :| Bottom line: no radeonfb for me :( at least, not now; but I have to be honest with you: I don't see what commit dd1447134454b169d5ae353aceb93f2368db8547 brought new into the picture. The previous radeonfb worked just great, but then, again, maybe I'm not using the console at it's full power :) I have attached the dmesg after power up. Thanks, (last post today, I swear to God!) -- Mihai Donțu [0.00] Linux version 2.6.23-rc7 ([EMAIL PROTECTED]) (gcc version 4.1.2 (Gentoo 4.1.2)) #16 PREEMPT Sun Sep 23 21:45:39 EEST 2007 [0.00] Command line: nohz=on root=/dev/sda7 libata.noacpi=0 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e - 0010 (reserved) [0.00] BIOS-e820: 0010 - 37fd (usable) [0.00] BIOS-e820: 37fd - 37fefc00 (reserved) [0.00] BIOS-e820: 37fefc00 - 37ffb000 (ACPI NVS) [0.00] BIOS-e820: 37ffb000 - 4000 (reserved) [0.00] BIOS-e820: e000 - f000 (reserved) [0.00] BIOS-e820: fec0 - fec02000 (reserved) [0.00] BIOS-e820: ffb8 - ffc0 (reserved) [0.00] BIOS-e820: fff8 - 0001 (reserved) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 229328) 1 entries of 256 used [0.00] end_pfn_map = 1048576 [0.00] DMI 2.3 present. [0.00] ACPI: RSDP 000FE270, 0014 (r0 HP) [0.00] ACPI: RSDT 37FEFC84, 0034 (r1 HP 0944 22110520 HP 1) [0.00] ACPI: FACP 37FEFC00, 0084 (r2 HP 09442 HP 1) [0.00] ACPI: DSDT 37FEFD50, 7489 (r1 HPSB4001 MSFT 10E) [0.00] ACPI: FACS 37FFAE80, 0040 [0.00] ACPI: APIC 37FEFCB8, 005A (r1 HP 09441 HP 1) [0.00] ACPI: MCFG 37FEFD14, 003C (r1 HP 09441 HP 1) [0.00] ACPI: SSDT 37FF71D9, 0382 (r1 HP HPQPpc 1001 MSFT 10E) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 229328) 1 entries of 256 used [0.00] No mptable found. [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] DMA324096 -> 1048576 [0.00] Normal1048576 -> 1048576 [0.00] Movable zone start PFN for each node [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 -> 159 [0.00] 0: 256 -> 229328 [0.00] On node 0 totalpages: 229231 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 1911 pages reserved [0.00] DMA zone: 2032 pages, LIFO batch:0 [0.00] DMA32 zone: 3079 pages used for memmap [0.00] DMA32 zone: 222153 pages, LIFO batch:31 [0.00] Normal zone: 0 pages used for memmap [0.00] Movable zone: 0
Re: 2.6.23-rc7 + radeonfb/s2ram
On Sunday 23 September 2007, Mihai Donțu wrote: > I'll to do a full cleanup and start all over. I'm going to nail this thing > down if > it's the last thing I do! (so help me God) :) Found it! The problem was "Framebuffer Console support". It was enabled by default in older configs (like 2.6.22.7) but I think someone noticed this was bad and put it to default N in newer (2.6.23-rc7); and since I reused the .config from 2.6.21.3 ... So there, if one wants "ATI Radeon display support" on Radeon XPRESS 200M with X using radeon_drv.so, *should* put "Framebuffer Console support" to N (if it's not already). Now all I have to do is figure out what's the equivalent of "vga=791" on the new kernel (default text console looks really bad on my laptop). Sorry for all the noise (and spam), -- Mihai Donțu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc7 + radeonfb/s2ram
On Sunday 23 September 2007, Mihai Donțu wrote: > On Sunday 23 September 2007, Benjamin Herrenschmidt wrote: > > Heh, yup. > > > > There have been some radeonfb patches around -rc6 or so. Can you try > > backing them out and letting us know if that helps a) ? > > > > In that case, Linus, we probably want to revert them... > > > > Though looking at your PCI ID (5955), I don't think the patches should > > have changed anything. > > After four hours of bisecting, I got this, which dates back to 2.6.21, but > I've been on 2.6.21.3 for too long and thus missed the commit (I just decided > to be a good citizen and test things before they get out). > > dd1447134454b169d5ae353aceb93f2368db8547 is first bad commit > commit dd1447134454b169d5ae353aceb93f2368db8547 > Author: johan henriksson <[EMAIL PROTECTED]> > Date: Tue May 8 00:37:59 2007 -0700 > > radeonfb: Add support for Radeon xpress 200m > > Added support for radeon xpress 200m(rs480). Note that the card doesn't > like dynclk turned on. > > Signed-off-by: Johan Henriksson <[EMAIL PROTECTED]> > Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > Cc: "Antonino A. Daplas" <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > :04 04 e553664a656ee329152789818b5b071a36ac1e45 > 0a698ad7daa8cdfd9eb5304812845306c9feb2f9 M drivers > > I turned dynclk off, no result (although dynclk is preferred). > > What is interesting, is that the driver ignores "vga=normal" and "jumps" to > a quite high res (I think is 1024x768 or something; the fonts look really nice > though :)). Something strange is going on here: after I cleaned up the bisect kernels, I booted 2.6.23-rc7 using something like: "vga=normal nohz=on root=/dev/sda7 libata.noacpi=0 pci=assing-busses" and explicitly selecting "Enable Video Mode Handling Helpers" (which normally gets automatically selected once I choose "ATI Radeon display support" but I - suffering from intense paranoia - selected it by hand prior to selecting ATI Radeon ...). I works! X is no longer acting weird. I can't use "vga=791" anymore (the screen goes blank until X loads => timings definitely changed) but it *works* and I don't know why _and_ I can't seem to be able to make it go back to being bad :) I did a diff between the .config used in bisect and the current .config. I don't see anything suspicious. I'll to do a full cleanup and start all over. I'm going to nail this thing down if it's the last thing I do! (so help me God) :) -- Mihai Donțu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc7 + radeonfb/s2ram
On Sunday 23 September 2007, Benjamin Herrenschmidt wrote: > Heh, yup. > > There have been some radeonfb patches around -rc6 or so. Can you try > backing them out and letting us know if that helps a) ? > > In that case, Linus, we probably want to revert them... > > Though looking at your PCI ID (5955), I don't think the patches should > have changed anything. After four hours of bisecting, I got this, which dates back to 2.6.21, but I've been on 2.6.21.3 for too long and thus missed the commit (I just decided to be a good citizen and test things before they get out). dd1447134454b169d5ae353aceb93f2368db8547 is first bad commit commit dd1447134454b169d5ae353aceb93f2368db8547 Author: johan henriksson <[EMAIL PROTECTED]> Date: Tue May 8 00:37:59 2007 -0700 radeonfb: Add support for Radeon xpress 200m Added support for radeon xpress 200m(rs480). Note that the card doesn't like dynclk turned on. Signed-off-by: Johan Henriksson <[EMAIL PROTECTED]> Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]> Cc: "Antonino A. Daplas" <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> :04 04 e553664a656ee329152789818b5b071a36ac1e45 0a698ad7daa8cdfd9eb5304812845306c9feb2f9 M drivers I turned dynclk off, no result (although dynclk is preferred). What is interesting, is that the driver ignores "vga=normal" and "jumps" to a quite high res (I think is 1024x768 or something; the fonts look really nice though :)). -- Mihai Donțu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/2] suspend/resume regression fixes
On Sunday 23 September 2007, Alan Cox wrote: > > I switched to libata, but it behaves like the old IDE without ACPI. I > > did not manage to get a full dmesg (apparently all volumes are mounted > > r/o right after a power up from a s2ram) but I did make a picture, from > > which I quote (if I may say so): > > Device errors. > > Libata currently (wrongly IMHO) defaults to avoiding the use of ACPI > suspend/resume methods > > So you also need to boot with "libata.noacpi=0" and if that works beat > up Jeff a bit .. You were right, 'libata.noacpi=0' does the trick :) It's interesting my mmc is unmounted before s2ram and then mounted back on resume. So, to sum up, I have a working suspend-to-ram with libata. Not bad, not bad at all... Thanks, -- Mihai Donțu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/2] suspend/resume regression fixes
On Sunday 23 September 2007, Alan Cox wrote: I switched to libata, but it behaves like the old IDE without ACPI. I did not manage to get a full dmesg (apparently all volumes are mounted r/o right after a power up from a s2ram) but I did make a picture, from which I quote (if I may say so): Device errors. Libata currently (wrongly IMHO) defaults to avoiding the use of ACPI suspend/resume methods So you also need to boot with libata.noacpi=0 and if that works beat up Jeff a bit .. You were right, 'libata.noacpi=0' does the trick :) It's interesting my mmc is unmounted before s2ram and then mounted back on resume. So, to sum up, I have a working suspend-to-ram with libata. Not bad, not bad at all... Thanks, -- Mihai Donțu - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc7 + radeonfb/s2ram
On Sunday 23 September 2007, Benjamin Herrenschmidt wrote: Heh, yup. There have been some radeonfb patches around -rc6 or so. Can you try backing them out and letting us know if that helps a) ? In that case, Linus, we probably want to revert them... Though looking at your PCI ID (5955), I don't think the patches should have changed anything. After four hours of bisecting, I got this, which dates back to 2.6.21, but I've been on 2.6.21.3 for too long and thus missed the commit (I just decided to be a good citizen and test things before they get out). dd1447134454b169d5ae353aceb93f2368db8547 is first bad commit commit dd1447134454b169d5ae353aceb93f2368db8547 Author: johan henriksson [EMAIL PROTECTED] Date: Tue May 8 00:37:59 2007 -0700 radeonfb: Add support for Radeon xpress 200m Added support for radeon xpress 200m(rs480). Note that the card doesn't like dynclk turned on. Signed-off-by: Johan Henriksson [EMAIL PROTECTED] Cc: Benjamin Herrenschmidt [EMAIL PROTECTED] Cc: Antonino A. Daplas [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] :04 04 e553664a656ee329152789818b5b071a36ac1e45 0a698ad7daa8cdfd9eb5304812845306c9feb2f9 M drivers I turned dynclk off, no result (although dynclk is preferred). What is interesting, is that the driver ignores vga=normal and jumps to a quite high res (I think is 1024x768 or something; the fonts look really nice though :)). -- Mihai Donțu - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc7 + radeonfb/s2ram
On Sunday 23 September 2007, Mihai Donțu wrote: On Sunday 23 September 2007, Benjamin Herrenschmidt wrote: Heh, yup. There have been some radeonfb patches around -rc6 or so. Can you try backing them out and letting us know if that helps a) ? In that case, Linus, we probably want to revert them... Though looking at your PCI ID (5955), I don't think the patches should have changed anything. After four hours of bisecting, I got this, which dates back to 2.6.21, but I've been on 2.6.21.3 for too long and thus missed the commit (I just decided to be a good citizen and test things before they get out). dd1447134454b169d5ae353aceb93f2368db8547 is first bad commit commit dd1447134454b169d5ae353aceb93f2368db8547 Author: johan henriksson [EMAIL PROTECTED] Date: Tue May 8 00:37:59 2007 -0700 radeonfb: Add support for Radeon xpress 200m Added support for radeon xpress 200m(rs480). Note that the card doesn't like dynclk turned on. Signed-off-by: Johan Henriksson [EMAIL PROTECTED] Cc: Benjamin Herrenschmidt [EMAIL PROTECTED] Cc: Antonino A. Daplas [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] :04 04 e553664a656ee329152789818b5b071a36ac1e45 0a698ad7daa8cdfd9eb5304812845306c9feb2f9 M drivers I turned dynclk off, no result (although dynclk is preferred). What is interesting, is that the driver ignores vga=normal and jumps to a quite high res (I think is 1024x768 or something; the fonts look really nice though :)). Something strange is going on here: after I cleaned up the bisect kernels, I booted 2.6.23-rc7 using something like: vga=normal nohz=on root=/dev/sda7 libata.noacpi=0 pci=assing-busses and explicitly selecting Enable Video Mode Handling Helpers (which normally gets automatically selected once I choose ATI Radeon display support but I - suffering from intense paranoia - selected it by hand prior to selecting ATI Radeon ...). I works! X is no longer acting weird. I can't use vga=791 anymore (the screen goes blank until X loads = timings definitely changed) but it *works* and I don't know why _and_ I can't seem to be able to make it go back to being bad :) I did a diff between the .config used in bisect and the current .config. I don't see anything suspicious. I'll to do a full cleanup and start all over. I'm going to nail this thing down if it's the last thing I do! (so help me God) :) -- Mihai Donțu - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc7 + radeonfb/s2ram
On Sunday 23 September 2007, Mihai Donțu wrote: I'll to do a full cleanup and start all over. I'm going to nail this thing down if it's the last thing I do! (so help me God) :) Found it! The problem was Framebuffer Console support. It was enabled by default in older configs (like 2.6.22.7) but I think someone noticed this was bad and put it to default N in newer (2.6.23-rc7); and since I reused the .config from 2.6.21.3 ... So there, if one wants ATI Radeon display support on Radeon XPRESS 200M with X using radeon_drv.so, *should* put Framebuffer Console support to N (if it's not already). Now all I have to do is figure out what's the equivalent of vga=791 on the new kernel (default text console looks really bad on my laptop). Sorry for all the noise (and spam), -- Mihai Donțu - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc7 + radeonfb/s2ram
On Sunday 23 September 2007, Rafael J. Wysocki wrote: On Sunday, 23 September 2007 20:31, Mihai Donțu wrote: On Sunday 23 September 2007, Mihai Donțu wrote: I'll to do a full cleanup and start all over. I'm going to nail this thing down if it's the last thing I do! (so help me God) :) Found it! The problem was Framebuffer Console support. It was enabled by default in older configs (like 2.6.22.7) but I think someone noticed this was bad and put it to default N in newer (2.6.23-rc7); and since I reused the .config from 2.6.21.3 ... So there, if one wants ATI Radeon display support on Radeon XPRESS 200M with X using radeon_drv.so, *should* put Framebuffer Console support to N (if it's not already). Now all I have to do is figure out what's the equivalent of vga=791 on the new kernel (default text console looks really bad on my laptop). Sorry for all the noise (and spam), No, this actually is valuable information, thanks for it. :-) [I have missed your first post, sorry for that.] Don't worry. Now, one last update (I've just ran into it): I was preparing my laptop (to brag tomorrow with my new s2ram thinggie) when I noticed that after powering up from a suspend-to-ram, X doesn't like radeonfb working behind it's back, as a result it goes crazy (corrupted pixmaps and such). I should have tested these two together :| Bottom line: no radeonfb for me :( at least, not now; but I have to be honest with you: I don't see what commit dd1447134454b169d5ae353aceb93f2368db8547 brought new into the picture. The previous radeonfb worked just great, but then, again, maybe I'm not using the console at it's full power :) I have attached the dmesg after power up. Thanks, (last post today, I swear to God!) -- Mihai Donțu [0.00] Linux version 2.6.23-rc7 ([EMAIL PROTECTED]) (gcc version 4.1.2 (Gentoo 4.1.2)) #16 PREEMPT Sun Sep 23 21:45:39 EEST 2007 [0.00] Command line: nohz=on root=/dev/sda7 libata.noacpi=0 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e - 0010 (reserved) [0.00] BIOS-e820: 0010 - 37fd (usable) [0.00] BIOS-e820: 37fd - 37fefc00 (reserved) [0.00] BIOS-e820: 37fefc00 - 37ffb000 (ACPI NVS) [0.00] BIOS-e820: 37ffb000 - 4000 (reserved) [0.00] BIOS-e820: e000 - f000 (reserved) [0.00] BIOS-e820: fec0 - fec02000 (reserved) [0.00] BIOS-e820: ffb8 - ffc0 (reserved) [0.00] BIOS-e820: fff8 - 0001 (reserved) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 229328) 1 entries of 256 used [0.00] end_pfn_map = 1048576 [0.00] DMI 2.3 present. [0.00] ACPI: RSDP 000FE270, 0014 (r0 HP) [0.00] ACPI: RSDT 37FEFC84, 0034 (r1 HP 0944 22110520 HP 1) [0.00] ACPI: FACP 37FEFC00, 0084 (r2 HP 09442 HP 1) [0.00] ACPI: DSDT 37FEFD50, 7489 (r1 HPSB4001 MSFT 10E) [0.00] ACPI: FACS 37FFAE80, 0040 [0.00] ACPI: APIC 37FEFCB8, 005A (r1 HP 09441 HP 1) [0.00] ACPI: MCFG 37FEFD14, 003C (r1 HP 09441 HP 1) [0.00] ACPI: SSDT 37FF71D9, 0382 (r1 HP HPQPpc 1001 MSFT 10E) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 229328) 1 entries of 256 used [0.00] No mptable found. [0.00] Zone PFN ranges: [0.00] DMA 0 - 4096 [0.00] DMA324096 - 1048576 [0.00] Normal1048576 - 1048576 [0.00] Movable zone start PFN for each node [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 - 159 [0.00] 0: 256 - 229328 [0.00] On node 0 totalpages: 229231 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 1911 pages reserved [0.00] DMA zone: 2032 pages, LIFO batch:0 [0.00] DMA32 zone: 3079 pages used for memmap [0.00] DMA32 zone: 222153 pages, LIFO batch:31 [0.00] Normal zone: 0 pages used for memmap [0.00] Movable zone: 0 pages used for memmap [0.00] ATI board detected. Disabling timer routing over 8254. [0.00] ACPI: PM-Timer IO Port: 0x8008 [0.00] ACPI: Local APIC address 0xfec01000 [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [0.00] Processor #0 (Bootup-CPU
Re: [patch 0/2] suspend/resume regression fixes
On Sunday 23 September 2007, Linus Torvalds wrote: > From a "future behaviour" standpoint it would probably be interesting to > hear whether Mihai can make his machine with not with the old IDE layer > (which distributions are migrating away from) but with the ATA layer > (libata) instead. It too should hopefully know about using ACPI to restore > any ATA controller quirks. I switched to libata, but it behaves like the old IDE without ACPI. I did not manage to get a full dmesg (apparently all volumes are mounted r/o right after a power up from a s2ram) but I did make a picture, from which I quote (if I may say so): " ata1.00: configured for PIO0 sd 0:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x08 sd 0:0:0:0: [sda] Sense key : 0xb [current] [descriptor] Descriptor sense data with sense descriptors (in hex): 72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00 07 65 35 25 sd 0:0:0:0: [sda] ASC=0x0 ASCQ=0x0 end_request: I/O error, dev sda, sector 124073509 ata1: EH complete sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata1.00: cmd c5/00:10:75:36:65/00:00:00:00:00/e7 tag 0 cdb 0x0 data 8192 out res 51/04:10:75:36:65/00:00:00:00:00/e7 Emask 0x1 (device error) ata1.00: configured for PIO0 ata1: EH complete " The last six lines repeat six times after which the whole things goes from the beginning: " ata1.00: configured for PIO0 ... " It all gets crazy the moment I (or a process) try to access the root (or any other drive), until then, everything is nice and quiet. Mmm... in the excerpt above it says: "Write Protect is off" but when I did $ mount -o remount,rw / I got something like: "the device is write protected". I tried to save the dmesg on a mmc, but after powering up it said: "out of disk space" These are about all symptoms that I noticed... oh, and 'scsi_eh_0/1' enters disk-sleep often. I attached the dmesg pre s2ram. Thanks, -- Mihai Donțu [0.00] Linux version 2.6.23-rc7 ([EMAIL PROTECTED]) (gcc version 4.1.2 (Gentoo 4.1.2)) #10 PREEMPT Sun Sep 23 06:54:24 EEST 2007 [0.00] Command line: nohz=on root=/dev/sda7 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e - 0010 (reserved) [0.00] BIOS-e820: 0010 - 37fd (usable) [0.00] BIOS-e820: 37fd - 37fefc00 (reserved) [0.00] BIOS-e820: 37fefc00 - 37ffb000 (ACPI NVS) [0.00] BIOS-e820: 37ffb000 - 4000 (reserved) [0.00] BIOS-e820: e000 - f000 (reserved) [0.00] BIOS-e820: fec0 - fec02000 (reserved) [0.00] BIOS-e820: ffb8 - ffc0 (reserved) [0.00] BIOS-e820: fff8 - 0001 (reserved) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 229328) 1 entries of 256 used [0.00] end_pfn_map = 1048576 [0.00] DMI 2.3 present. [0.00] ACPI: RSDP 000FE270, 0014 (r0 HP) [0.00] ACPI: RSDT 37FEFC84, 0034 (r1 HP 0944 22110520 HP 1) [0.00] ACPI: FACP 37FEFC00, 0084 (r2 HP 09442 HP 1) [0.00] ACPI: DSDT 37FEFD50, 7489 (r1 HPSB4001 MSFT 10E) [0.00] ACPI: FACS 37FFAE80, 0040 [0.00] ACPI: APIC 37FEFCB8, 005A (r1 HP 09441 HP 1) [0.00] ACPI: MCFG 37FEFD14, 003C (r1 HP 09441 HP 1) [0.00] ACPI: SSDT 37FF71D9, 0382 (r1 HP HPQPpc 1001 MSFT 10E) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 229328) 1 entries of 256 used [0.00] No mptable found. [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] DMA324096 -> 1048576 [0.00] Normal1048576 -> 1048576 [0.00] Movable zone start PFN for each node [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 -> 159 [0.00] 0: 256 -> 229328 [0.00] On node 0 totalpages: 229231 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 1911 pages reserved [0.00] DMA zone: 2032 pages, LIFO batch:0 [0.00] DMA32 zone: 3079 pages used for memmap [0.00] DMA32 zone: 222153 pages, LIFO batch:31 [0.00] Normal zone: 0 pages used for memmap [0.00] Movable zone: 0
Re: 2.6.23-rc7 + radeonfb/s2ram
On Saturday 22 September 2007, Mihai Donțu wrote:
> Hi,
>
> Today, out of curiosity, I pulled 2.6.23-rc7 (leave on the edge in a quiet
> weekend).
> Anyway, it seems that radeonfb and my:
> "01:05.0 VGA compatible controller: ATI Technologies Inc ATI Radeon XPRESS
> 200M 5955 (PCIE)"
> don't get along anymore, by:
> a) X somehow fails to initialize the card and everything moves really slow (I
> can
>see how surfaces are drawn pixel-by-pixel); furthermore, garbage stuff
> appears
>on the screen;
> b) after powering up from a s2ram, the system freezes;
>
> b) is not that bad, s2ram never worked on my machine (kjournald and some
> other kernel
> processes, enter disk-sleep and in a matter of seconds, everything just...
> freezes.
> I can type a few commands at the normal console but that is all);
>
> Following the advices in 'Documentation/power/s2ram.txt' helped. Using the
> regular
> VGA console got X on the right track (no more slowness);
>
> Now that I got my hands "dirty", I'm in the mood to make my s2ram work (I've
> been using Linux (exclusively) for three years now, it's about time I do a
> small
> contribution). What kernel option must I enable to determine why some
> processes
> enter (and stay in) disk-sleep? I'm on a laptop and I don't think it will
> withstand
> too many reboots :)
>
> I've also attached the output of lspci and dmesg. Maybe someone spots
> something.
>
> Thanks,
>
Since there was no reply, I assume people *do* take the weekend off :)
Anyway, I took matters into my own hands and enabled whatever debugging
feature seamed reasonable enough (ACPI, SysRq, etc).
Reboot, play, echo "mem" >/sys/power/state. I waited 5s and powered up
and found this in dmesg
"
hda:task_out_intr:status = 0x51 { DriveReady SeekComplete Error }
hda:task_out_intr:error = 0x04 { DriveStatusError }
ide:failed opcode was: unknown
"
I figured my IDE woke up in a bad mood so I alt-sysrq-s, alt-sysrq-u and
alt-sysrq-b (blessed be he who invented alt-sysrq-). After
boot I went back to my "make menuconfig" and stared for ... 15s, when I
found this: "IDE ACPI support" (boy do I feel silly).
Reboot, play, echo "mem" >/sys/power/state ... [5s] ... power up. Ta-da!
Everything works. Well, maybe the audio needed a little "jolt" (turn sound
off, back on, move the volume a bit and voila!).
I've attached the dmesg, again, maybe someone spots something bad.
Thanks,
--
Mihai Donțu
[0.00] Linux version 2.6.23-rc7 ([EMAIL PROTECTED]) (gcc version 4.1.2
(Gentoo 4.1.2)) #5 PREEMPT Sat Sep 22 17:20:57 EEST 2007
[0.00] Command line: vga=791 nohz=on
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: - 0009fc00 (usable)
[0.00] BIOS-e820: 0009fc00 - 000a (reserved)
[0.00] BIOS-e820: 000e - 0010 (reserved)
[0.00] BIOS-e820: 0010 - 37fd (usable)
[0.00] BIOS-e820: 37fd - 37fefc00 (reserved)
[0.00] BIOS-e820: 37fefc00 - 37ffb000 (ACPI NVS)
[0.00] BIOS-e820: 37ffb000 - 4000 (reserved)
[0.00] BIOS-e820: e000 - f000 (reserved)
[0.00] BIOS-e820: fec0 - fec02000 (reserved)
[0.00] BIOS-e820: ffb8 - ffc0 (reserved)
[0.00] BIOS-e820: fff8 - 0001 (reserved)
[0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used
[0.00] Entering add_active_range(0, 256, 229328) 1 entries of 256 used
[0.00] end_pfn_map = 1048576
[0.00] DMI 2.3 present.
[0.00] ACPI: RSDP 000FE270, 0014 (r0 HP)
[0.00] ACPI: RSDT 37FEFC84, 0034 (r1 HP 0944 22110520 HP
1)
[0.00] ACPI: FACP 37FEFC00, 0084 (r2 HP 09442 HP
1)
[0.00] ACPI: DSDT 37FEFD50, 7489 (r1 HPSB4001 MSFT
10E)
[0.00] ACPI: FACS 37FFAE80, 0040
[0.00] ACPI: APIC 37FEFCB8, 005A (r1 HP 09441 HP
1)
[0.00] ACPI: MCFG 37FEFD14, 003C (r1 HP 09441 HP
1)
[0.00] ACPI: SSDT 37FF71D9, 0382 (r1 HP HPQPpc 1001 MSFT
10E)
[0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used
[0.00] Entering add_active_range(0, 256, 229328) 1 entries of 256 used
[0.00] No mptable found.
[0.00] Zone PFN ranges:
[0.00] DMA 0 -> 4096
[0.00] DMA324096 -> 1048576
[0.00] Normal1048576 -> 1048576
[0.00] Movable zone start PFN for each node
[0.00] early
Re: 2.6.23-rc7 + radeonfb/s2ram
On Saturday 22 September 2007, Mihai Donțu wrote:
Hi,
Today, out of curiosity, I pulled 2.6.23-rc7 (leave on the edge in a quiet
weekend).
Anyway, it seems that radeonfb and my:
01:05.0 VGA compatible controller: ATI Technologies Inc ATI Radeon XPRESS
200M 5955 (PCIE)
don't get along anymore, by:
a) X somehow fails to initialize the card and everything moves really slow (I
can
see how surfaces are drawn pixel-by-pixel); furthermore, garbage stuff
appears
on the screen;
b) after powering up from a s2ram, the system freezes;
b) is not that bad, s2ram never worked on my machine (kjournald and some
other kernel
processes, enter disk-sleep and in a matter of seconds, everything just...
freezes.
I can type a few commands at the normal console but that is all);
Following the advices in 'Documentation/power/s2ram.txt' helped. Using the
regular
VGA console got X on the right track (no more slowness);
Now that I got my hands dirty, I'm in the mood to make my s2ram work (I've
been using Linux (exclusively) for three years now, it's about time I do a
small
contribution). What kernel option must I enable to determine why some
processes
enter (and stay in) disk-sleep? I'm on a laptop and I don't think it will
withstand
too many reboots :)
I've also attached the output of lspci and dmesg. Maybe someone spots
something.
Thanks,
Since there was no reply, I assume people *do* take the weekend off :)
Anyway, I took matters into my own hands and enabled whatever debugging
feature seamed reasonable enough (ACPI, SysRq, etc).
Reboot, play, echo mem /sys/power/state. I waited 5s and powered up
and found this in dmesg
hda:task_out_intr:status = 0x51 { DriveReady SeekComplete Error }
hda:task_out_intr:error = 0x04 { DriveStatusError }
ide:failed opcode was: unknown
I figured my IDE woke up in a bad mood so I alt-sysrq-s, alt-sysrq-u and
alt-sysrq-b (blessed be he who invented alt-sysrq-command). After
boot I went back to my make menuconfig and stared for ... 15s, when I
found this: IDE ACPI support (boy do I feel silly).
Reboot, play, echo mem /sys/power/state ... [5s] ... power up. Ta-da!
Everything works. Well, maybe the audio needed a little jolt (turn sound
off, back on, move the volume a bit and voila!).
I've attached the dmesg, again, maybe someone spots something bad.
Thanks,
--
Mihai Donțu
[0.00] Linux version 2.6.23-rc7 ([EMAIL PROTECTED]) (gcc version 4.1.2
(Gentoo 4.1.2)) #5 PREEMPT Sat Sep 22 17:20:57 EEST 2007
[0.00] Command line: vga=791 nohz=on
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: - 0009fc00 (usable)
[0.00] BIOS-e820: 0009fc00 - 000a (reserved)
[0.00] BIOS-e820: 000e - 0010 (reserved)
[0.00] BIOS-e820: 0010 - 37fd (usable)
[0.00] BIOS-e820: 37fd - 37fefc00 (reserved)
[0.00] BIOS-e820: 37fefc00 - 37ffb000 (ACPI NVS)
[0.00] BIOS-e820: 37ffb000 - 4000 (reserved)
[0.00] BIOS-e820: e000 - f000 (reserved)
[0.00] BIOS-e820: fec0 - fec02000 (reserved)
[0.00] BIOS-e820: ffb8 - ffc0 (reserved)
[0.00] BIOS-e820: fff8 - 0001 (reserved)
[0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used
[0.00] Entering add_active_range(0, 256, 229328) 1 entries of 256 used
[0.00] end_pfn_map = 1048576
[0.00] DMI 2.3 present.
[0.00] ACPI: RSDP 000FE270, 0014 (r0 HP)
[0.00] ACPI: RSDT 37FEFC84, 0034 (r1 HP 0944 22110520 HP
1)
[0.00] ACPI: FACP 37FEFC00, 0084 (r2 HP 09442 HP
1)
[0.00] ACPI: DSDT 37FEFD50, 7489 (r1 HPSB4001 MSFT
10E)
[0.00] ACPI: FACS 37FFAE80, 0040
[0.00] ACPI: APIC 37FEFCB8, 005A (r1 HP 09441 HP
1)
[0.00] ACPI: MCFG 37FEFD14, 003C (r1 HP 09441 HP
1)
[0.00] ACPI: SSDT 37FF71D9, 0382 (r1 HP HPQPpc 1001 MSFT
10E)
[0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used
[0.00] Entering add_active_range(0, 256, 229328) 1 entries of 256 used
[0.00] No mptable found.
[0.00] Zone PFN ranges:
[0.00] DMA 0 - 4096
[0.00] DMA324096 - 1048576
[0.00] Normal1048576 - 1048576
[0.00] Movable zone start PFN for each node
[0.00] early_node_map[2] active PFN ranges
[0.00] 0:0 - 159
[0.00] 0: 256 - 229328
[0.00] On node 0 totalpages: 229231
[0.00] DMA zone: 56 pages used for memmap
[0.00] DMA zone: 1974 pages reserved
Re: [patch 0/2] suspend/resume regression fixes
On Sunday 23 September 2007, Linus Torvalds wrote: From a future behaviour standpoint it would probably be interesting to hear whether Mihai can make his machine with not with the old IDE layer (which distributions are migrating away from) but with the ATA layer (libata) instead. It too should hopefully know about using ACPI to restore any ATA controller quirks. I switched to libata, but it behaves like the old IDE without ACPI. I did not manage to get a full dmesg (apparently all volumes are mounted r/o right after a power up from a s2ram) but I did make a picture, from which I quote (if I may say so): ata1.00: configured for PIO0 sd 0:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x08 sd 0:0:0:0: [sda] Sense key : 0xb [current] [descriptor] Descriptor sense data with sense descriptors (in hex): 72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00 07 65 35 25 sd 0:0:0:0: [sda] ASC=0x0 ASCQ=0x0 end_request: I/O error, dev sda, sector 124073509 ata1: EH complete sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata1.00: cmd c5/00:10:75:36:65/00:00:00:00:00/e7 tag 0 cdb 0x0 data 8192 out res 51/04:10:75:36:65/00:00:00:00:00/e7 Emask 0x1 (device error) ata1.00: configured for PIO0 ata1: EH complete The last six lines repeat six times after which the whole things goes from the beginning: ata1.00: configured for PIO0 ... It all gets crazy the moment I (or a process) try to access the root (or any other drive), until then, everything is nice and quiet. Mmm... in the excerpt above it says: Write Protect is off but when I did $ mount -o remount,rw / I got something like: the device is write protected. I tried to save the dmesg on a mmc, but after powering up it said: out of disk space These are about all symptoms that I noticed... oh, and 'scsi_eh_0/1' enters disk-sleep often. I attached the dmesg pre s2ram. Thanks, -- Mihai Donțu [0.00] Linux version 2.6.23-rc7 ([EMAIL PROTECTED]) (gcc version 4.1.2 (Gentoo 4.1.2)) #10 PREEMPT Sun Sep 23 06:54:24 EEST 2007 [0.00] Command line: nohz=on root=/dev/sda7 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e - 0010 (reserved) [0.00] BIOS-e820: 0010 - 37fd (usable) [0.00] BIOS-e820: 37fd - 37fefc00 (reserved) [0.00] BIOS-e820: 37fefc00 - 37ffb000 (ACPI NVS) [0.00] BIOS-e820: 37ffb000 - 4000 (reserved) [0.00] BIOS-e820: e000 - f000 (reserved) [0.00] BIOS-e820: fec0 - fec02000 (reserved) [0.00] BIOS-e820: ffb8 - ffc0 (reserved) [0.00] BIOS-e820: fff8 - 0001 (reserved) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 229328) 1 entries of 256 used [0.00] end_pfn_map = 1048576 [0.00] DMI 2.3 present. [0.00] ACPI: RSDP 000FE270, 0014 (r0 HP) [0.00] ACPI: RSDT 37FEFC84, 0034 (r1 HP 0944 22110520 HP 1) [0.00] ACPI: FACP 37FEFC00, 0084 (r2 HP 09442 HP 1) [0.00] ACPI: DSDT 37FEFD50, 7489 (r1 HPSB4001 MSFT 10E) [0.00] ACPI: FACS 37FFAE80, 0040 [0.00] ACPI: APIC 37FEFCB8, 005A (r1 HP 09441 HP 1) [0.00] ACPI: MCFG 37FEFD14, 003C (r1 HP 09441 HP 1) [0.00] ACPI: SSDT 37FF71D9, 0382 (r1 HP HPQPpc 1001 MSFT 10E) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 229328) 1 entries of 256 used [0.00] No mptable found. [0.00] Zone PFN ranges: [0.00] DMA 0 - 4096 [0.00] DMA324096 - 1048576 [0.00] Normal1048576 - 1048576 [0.00] Movable zone start PFN for each node [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 - 159 [0.00] 0: 256 - 229328 [0.00] On node 0 totalpages: 229231 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 1911 pages reserved [0.00] DMA zone: 2032 pages, LIFO batch:0 [0.00] DMA32 zone: 3079 pages used for memmap [0.00] DMA32 zone: 222153 pages, LIFO batch:31 [0.00] Normal zone: 0 pages used for memmap [0.00] Movable zone: 0 pages used for memmap [0.00] ATI board detected. Disabling timer routing over 8254. [0.00] ACPI: PM
2.6.23-rc7 + radeonfb/s2ram
Hi, Today, out of curiosity, I pulled 2.6.23-rc7 (leave on the edge in a quiet weekend). Anyway, it seems that radeonfb and my: "01:05.0 VGA compatible controller: ATI Technologies Inc ATI Radeon XPRESS 200M 5955 (PCIE)" don't get along anymore, by: a) X somehow fails to initialize the card and everything moves really slow (I can see how surfaces are drawn pixel-by-pixel); furthermore, garbage stuff appears on the screen; b) after powering up from a s2ram, the system freezes; b) is not that bad, s2ram never worked on my machine (kjournald and some other kernel processes, enter disk-sleep and in a matter of seconds, everything just... freezes. I can type a few commands at the normal console but that is all); Following the advices in 'Documentation/power/s2ram.txt' helped. Using the regular VGA console got X on the right track (no more slowness); Now that I got my hands "dirty", I'm in the mood to make my s2ram work (I've been using Linux (exclusively) for three years now, it's about time I do a small contribution). What kernel option must I enable to determine why some processes enter (and stay in) disk-sleep? I'm on a laptop and I don't think it will withstand too many reboots :) I've also attached the output of lspci and dmesg. Maybe someone spots something. Thanks, -- Mihai Donțu [0.00] Linux version 2.6.23-rc7 ([EMAIL PROTECTED]) (gcc version 4.1.2 (Gentoo 4.1.2)) #3 PREEMPT Sat Sep 22 07:27:11 EEST 2007 [0.00] Command line: vga=791 nohz=on [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e - 0010 (reserved) [0.00] BIOS-e820: 0010 - 37fd (usable) [0.00] BIOS-e820: 37fd - 37fefc00 (reserved) [0.00] BIOS-e820: 37fefc00 - 37ffb000 (ACPI NVS) [0.00] BIOS-e820: 37ffb000 - 4000 (reserved) [0.00] BIOS-e820: e000 - f000 (reserved) [0.00] BIOS-e820: fec0 - fec02000 (reserved) [0.00] BIOS-e820: ffb8 - ffc0 (reserved) [0.00] BIOS-e820: fff8 - 0001 (reserved) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 229328) 1 entries of 256 used [0.00] end_pfn_map = 1048576 [0.00] DMI 2.3 present. [0.00] ACPI: RSDP 000FE270, 0014 (r0 HP) [0.00] ACPI: RSDT 37FEFC84, 0034 (r1 HP 0944 22110520 HP 1) [0.00] ACPI: FACP 37FEFC00, 0084 (r2 HP 09442 HP 1) [0.00] ACPI: DSDT 37FEFD50, 7489 (r1 HPSB4001 MSFT 10E) [0.00] ACPI: FACS 37FFAE80, 0040 [0.00] ACPI: APIC 37FEFCB8, 005A (r1 HP 09441 HP 1) [0.00] ACPI: MCFG 37FEFD14, 003C (r1 HP 09441 HP 1) [0.00] ACPI: SSDT 37FF71D9, 0382 (r1 HP HPQPpc 1001 MSFT 10E) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 229328) 1 entries of 256 used [0.00] No mptable found. [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] DMA324096 -> 1048576 [0.00] Normal1048576 -> 1048576 [0.00] Movable zone start PFN for each node [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 -> 159 [0.00] 0: 256 -> 229328 [0.00] On node 0 totalpages: 229231 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 1960 pages reserved [0.00] DMA zone: 1983 pages, LIFO batch:0 [0.00] DMA32 zone: 3079 pages used for memmap [0.00] DMA32 zone: 222153 pages, LIFO batch:31 [0.00] Normal zone: 0 pages used for memmap [0.00] Movable zone: 0 pages used for memmap [0.00] ATI board detected. Disabling timer routing over 8254. [0.00] ACPI: PM-Timer IO Port: 0x8008 [0.00] ACPI: Local APIC address 0xfec01000 [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [0.00] Processor #0 (Bootup-CPU) [0.00] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [0.00] ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 1, address 0xfec0, GSI 0-23 [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 21 low level) [0.00] ACPI: IRQ0 used by override. [0.00] ACPI: IRQ2 used by override. [0.00] Setting APIC routing to flat [0.00] Using ACPI (MADT) for SMP conf
2.6.23-rc7 + radeonfb/s2ram
Hi, Today, out of curiosity, I pulled 2.6.23-rc7 (leave on the edge in a quiet weekend). Anyway, it seems that radeonfb and my: 01:05.0 VGA compatible controller: ATI Technologies Inc ATI Radeon XPRESS 200M 5955 (PCIE) don't get along anymore, by: a) X somehow fails to initialize the card and everything moves really slow (I can see how surfaces are drawn pixel-by-pixel); furthermore, garbage stuff appears on the screen; b) after powering up from a s2ram, the system freezes; b) is not that bad, s2ram never worked on my machine (kjournald and some other kernel processes, enter disk-sleep and in a matter of seconds, everything just... freezes. I can type a few commands at the normal console but that is all); Following the advices in 'Documentation/power/s2ram.txt' helped. Using the regular VGA console got X on the right track (no more slowness); Now that I got my hands dirty, I'm in the mood to make my s2ram work (I've been using Linux (exclusively) for three years now, it's about time I do a small contribution). What kernel option must I enable to determine why some processes enter (and stay in) disk-sleep? I'm on a laptop and I don't think it will withstand too many reboots :) I've also attached the output of lspci and dmesg. Maybe someone spots something. Thanks, -- Mihai Donțu [0.00] Linux version 2.6.23-rc7 ([EMAIL PROTECTED]) (gcc version 4.1.2 (Gentoo 4.1.2)) #3 PREEMPT Sat Sep 22 07:27:11 EEST 2007 [0.00] Command line: vga=791 nohz=on [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e - 0010 (reserved) [0.00] BIOS-e820: 0010 - 37fd (usable) [0.00] BIOS-e820: 37fd - 37fefc00 (reserved) [0.00] BIOS-e820: 37fefc00 - 37ffb000 (ACPI NVS) [0.00] BIOS-e820: 37ffb000 - 4000 (reserved) [0.00] BIOS-e820: e000 - f000 (reserved) [0.00] BIOS-e820: fec0 - fec02000 (reserved) [0.00] BIOS-e820: ffb8 - ffc0 (reserved) [0.00] BIOS-e820: fff8 - 0001 (reserved) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 229328) 1 entries of 256 used [0.00] end_pfn_map = 1048576 [0.00] DMI 2.3 present. [0.00] ACPI: RSDP 000FE270, 0014 (r0 HP) [0.00] ACPI: RSDT 37FEFC84, 0034 (r1 HP 0944 22110520 HP 1) [0.00] ACPI: FACP 37FEFC00, 0084 (r2 HP 09442 HP 1) [0.00] ACPI: DSDT 37FEFD50, 7489 (r1 HPSB4001 MSFT 10E) [0.00] ACPI: FACS 37FFAE80, 0040 [0.00] ACPI: APIC 37FEFCB8, 005A (r1 HP 09441 HP 1) [0.00] ACPI: MCFG 37FEFD14, 003C (r1 HP 09441 HP 1) [0.00] ACPI: SSDT 37FF71D9, 0382 (r1 HP HPQPpc 1001 MSFT 10E) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 229328) 1 entries of 256 used [0.00] No mptable found. [0.00] Zone PFN ranges: [0.00] DMA 0 - 4096 [0.00] DMA324096 - 1048576 [0.00] Normal1048576 - 1048576 [0.00] Movable zone start PFN for each node [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 - 159 [0.00] 0: 256 - 229328 [0.00] On node 0 totalpages: 229231 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 1960 pages reserved [0.00] DMA zone: 1983 pages, LIFO batch:0 [0.00] DMA32 zone: 3079 pages used for memmap [0.00] DMA32 zone: 222153 pages, LIFO batch:31 [0.00] Normal zone: 0 pages used for memmap [0.00] Movable zone: 0 pages used for memmap [0.00] ATI board detected. Disabling timer routing over 8254. [0.00] ACPI: PM-Timer IO Port: 0x8008 [0.00] ACPI: Local APIC address 0xfec01000 [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [0.00] Processor #0 (Bootup-CPU) [0.00] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [0.00] ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 1, address 0xfec0, GSI 0-23 [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 21 low level) [0.00] ACPI: IRQ0 used by override. [0.00] ACPI: IRQ2 used by override. [0.00] Setting APIC routing to flat [0.00] Using ACPI (MADT) for SMP configuration information [0.00
