How is this going?
regards,
2013/10/11 Fengguang Wu :
>> I think something like the below may address the issue - I've only build
>> tested this so far.
>>
>> We have another case where DRM does the wrong thing here too - a similar
>> thing goes on with connectors as well. I've not yet looked
> I think something like the below may address the issue - I've only build
> tested this so far.
>
> We have another case where DRM does the wrong thing here too - a similar
> thing goes on with connectors as well. I've not yet looked into this,
> but I'll take a look later today.
>
> Fengguang
> Damn gmail screwed up my reply-all,
>
> anyhoo I get the feeling I'd rather do this like fbdev does and stop using
> an embedded kdev for this if I can. The lifetime of the minor and the sysfs
> objects aren't necessarily that tied together esp with hot unplug of
> USB devices.
>
> e.g. when a US
On Thu, Oct 10, 2013 at 8:53 PM, Russell King - ARM Linux
wrote:
> On Thu, Oct 10, 2013 at 10:19:20AM +0100, Russell King - ARM Linux wrote:
>> On Thu, Oct 10, 2013 at 03:23:45AM +0100, Dave Airlie wrote:
>> >
>> > > I think David Arlie also needs a quiet talking to about how to use the
>> > > dev
On Thu, Oct 10, 2013 at 10:19:20AM +0100, Russell King - ARM Linux wrote:
> On Thu, Oct 10, 2013 at 03:23:45AM +0100, Dave Airlie wrote:
> >
> > > I think David Arlie also needs a quiet talking to about how to use the
> > > device model:
> > >
> > > int drm_sysfs_device_add(struct drm_minor *mino
On Thu, Oct 10, 2013 at 03:23:45AM +0100, Dave Airlie wrote:
>
> > I think David Arlie also needs a quiet talking to about how to use the
> > device model:
> >
> > int drm_sysfs_device_add(struct drm_minor *minor)
> > {
> > minor->kdev.release = drm_sysfs_device_release;
> > ...
> >
On Wed, Oct 9, 2013 at 7:23 PM, Dave Airlie wrote:
>
> Well the commit that added it had a reason that seems to cover some other
> device model abuses, so maybe someone who actually understands the device
> model (all 2 people) can review usage
Actually, I think it's the same bug.
You *cannot* j
> I think David Arlie also needs a quiet talking to about how to use the
> device model:
>
> int drm_sysfs_device_add(struct drm_minor *minor)
> {
> minor->kdev.release = drm_sysfs_device_release;
> ...
> err = device_register(&minor->kdev);
> }
>
> static void drm_sysfs_device_r
On Tue, Oct 8, 2013 at 8:45 PM, Linus Torvalds
wrote:
> On Tue, Oct 8, 2013 at 3:48 PM, Greg Kroah-Hartman
> wrote:
>>
>> It's going to make things really noisy at boot time, but then it should
>> settle down and not be bad at all. Let's try it and see if it helps or
>> not.
>
> Yeah. And quite
On Tue, Oct 08, 2013 at 05:45:37PM -0700, Linus Torvalds wrote:
> normally that whole DEBUG_KOBJECT_RELEASE
> thing is hopefully only enabled in debug kernels (like maybe the
> Fedora rawhide one
Nope. After spending a couple of days fruitlessly trying to get my machine to
boot
with it enable
On Tue, Oct 8, 2013 at 3:48 PM, Greg Kroah-Hartman
wrote:
>
> It's going to make things really noisy at boot time, but then it should
> settle down and not be bad at all. Let's try it and see if it helps or
> not.
Yeah. And quite frankly, normally that whole DEBUG_KOBJECT_RELEASE
thing is hopefu
On Tue, Oct 08, 2013 at 03:48:40PM -0700, Greg KH wrote:
> On Tue, Oct 08, 2013 at 11:14:17PM +0100, Russell King - ARM Linux wrote:
> > On Tue, Oct 08, 2013 at 08:17:42PM +0800, Fengguang Wu wrote:
> > > I find the above debug messages very helpful in locating the buggy
> > > driver. How about ena
On Tue, Oct 08, 2013 at 11:14:17PM +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 08, 2013 at 08:17:42PM +0800, Fengguang Wu wrote:
> > I find the above debug messages very helpful in locating the buggy
> > driver. How about enabling it whenever CONFIG_DEBUG_KOBJECT_RELEASE is
> > enabled? So
On Tue, Oct 08, 2013 at 08:17:42PM +0800, Fengguang Wu wrote:
> I find the above debug messages very helpful in locating the buggy
> driver. How about enabling it whenever CONFIG_DEBUG_KOBJECT_RELEASE is
> enabled? Something like
>
> #ifdef CONFIG_DEBUG_KOBJECT_RELEASE
> - pr_debug("kobject
Hi Russell,
> I'm now trying to disable all drivers shows up in the kobject_release
> messages:
>
> [2.756392] kobject: 'ipmi_si' (880007764a00): kobject_release, parent
> 881b7648 (delayed)
> [2.758091] kobject: 'ipmi_si' (880007764800): kobject_release, parent
> 8
* Ingo Molnar wrote:
> * Fengguang Wu wrote:
>
> > After enabling CONFIG_DEBUG_OBJECTS_TIMERS=y, it will issue a WARNING
> > followed by a "BUG: ..."
>
> Cool!
>
> > [2.802167] parport_pc 00:04: reported by Plug and Play ACPI
> > [2.803818] parport0: PC-style at 0x378, irq 7 [PCSPP(
* Fengguang Wu wrote:
> After enabling CONFIG_DEBUG_OBJECTS_TIMERS=y, it will issue a WARNING
> followed by a "BUG: ..."
Cool!
> [2.802167] parport_pc 00:04: reported by Plug and Play ACPI
> [2.803818] parport0: PC-style at 0x378, irq 7 [PCSPP(,...)]
> [2.806035] kobject: 'parport
On Tue, Oct 08, 2013 at 09:58:16AM +0200, Ingo Molnar wrote:
>
> * Linus Torvalds wrote:
>
> > On Mon, Oct 7, 2013 at 1:35 AM, Fengguang Wu wrote:
> > > On Mon, Oct 07, 2013 at 01:12:17AM -0700, Linus Torvalds wrote:
> > >
> > > My pleasure! Here are 100 randomly selected call traces. Also atta
On Tue, Oct 08, 2013 at 10:14:52AM +0800, Fengguang Wu wrote:
> [2.785188] kobject: 'drm' (880006dae048): kobject_release, parent
> 88189648 (delayed)
> [2.787362] kobject: 'drm' (880006dafe00): kobject_release, parent
> (null) (delayed)
> [2.789674] [drm] ra
* Linus Torvalds wrote:
> On Mon, Oct 7, 2013 at 1:35 AM, Fengguang Wu wrote:
> > On Mon, Oct 07, 2013 at 01:12:17AM -0700, Linus Torvalds wrote:
> >
> > My pleasure! Here are 100 randomly selected call traces. Also attached
> > several full dmesgs and the kconfig.
>
> Ok, they may be randomly
On Mon, Oct 07, 2013 at 08:29:26PM -0700, Linus Torvalds wrote:
> On Mon, Oct 7, 2013 at 8:11 PM, Fengguang Wu wrote:
> >
> > Yeah, I see no timer usage in parport_pc driver, so it's still questionable.
>
> The timer itself comes simply from the delayed_work that is used to
> delay the freeing of
On Mon, Oct 7, 2013 at 8:11 PM, Fengguang Wu wrote:
>
> Yeah, I see no timer usage in parport_pc driver, so it's still questionable.
The timer itself comes simply from the delayed_work that is used to
delay the freeing of the kobject.
So that is not the surprising part.
The surprising part is t
I'll catch up with your emails if it kills me..
On Mon, Oct 7, 2013 at 7:36 PM, Fengguang Wu wrote:
> On Tue, Oct 08, 2013 at 10:14:52AM +0800, Fengguang Wu wrote:
>
> Disabled PARPORT_PC:
>
> # CONFIG_PARPORT is not set
>
> and retest shows another call trace. Here are two run logs:
Ugh. Ok. So
On Mon, Oct 7, 2013 at 7:14 PM, Fengguang Wu wrote:
>
> I got a call trace containing parport_pc_probe_port() (is it the
> culprit?) after recompiling kernel with
>
> CONFIG_DEBUG_OBJECTS_TIMERS=y
>
> and booting with "ignore_loglevel". Here is the log for two kernel boots.
Ok, so it's definitely
On Mon, Oct 7, 2013 at 7:09 PM, Fengguang Wu wrote:
>
> Thanks for the hints! I run a kernel with pr_alert() for several times
> and here is the screen log. Note that this kernel is compiled with gcc
> 4.6.3 and the decoded code looks different than gcc 4.8.1
Ok, I think we have something.
> NUL
On Mon, Oct 7, 2013 at 3:14 PM, Linus Torvalds
wrote:
>
> I *think* r14 contains the function we're going to jump to in the
> oops, and that could be interesting to know, but it's not decoded, so
> you'd have to match it up against a symbol map...
Actually, Fenguguan, never mind. Instead, change
On Mon, Oct 07, 2013 at 11:29:25PM +0100, Russell King - ARM Linux wrote:
> However, due to the problems with x86, that's fallen on its head and I
> have no solution to get better debugging out which works across all
> architectures. I'm stumpted by this.
The final attempt at trying to sort this
On Mon, Oct 07, 2013 at 03:14:48PM -0700, Linus Torvalds wrote:
> On Mon, Oct 7, 2013 at 1:35 AM, Fengguang Wu wrote:
> > On Mon, Oct 07, 2013 at 01:12:17AM -0700, Linus Torvalds wrote:
> >
> > My pleasure! Here are 100 randomly selected call traces. Also attached
> > several full dmesgs and the k
On Mon, Oct 7, 2013 at 1:35 AM, Fengguang Wu wrote:
> On Mon, Oct 07, 2013 at 01:12:17AM -0700, Linus Torvalds wrote:
>
> My pleasure! Here are 100 randomly selected call traces. Also attached
> several full dmesgs and the kconfig.
Ok, they may be randomly selected, but they are all the same. Whi
On Sun, Oct 6, 2013 at 10:10 PM, Fengguang Wu wrote:
>
> I retried bisect with "Oops:" and the first bad commit is
>
> commit c817a67ecba7c3 ("kobject: delayed kobject release: help find buggy
> drivers")
Ok, that makes way more sense.
> That commit has already helped expose some bugs, however
On Mon, Oct 07, 2013 at 10:11:18AM +0800, Fengguang Wu wrote:
> On Sun, Oct 06, 2013 at 10:26:24AM -0700, Linus Torvalds wrote:
> > On Sun, Oct 6, 2013 at 1:23 AM, Fengguang Wu wrote:
> > >
> > > I got the below dmesg and the first bad commit is commit cf39c8e5352b:
> > > Merge tag 'stable/for
On Sun, Oct 06, 2013 at 10:26:24AM -0700, Linus Torvalds wrote:
> On Sun, Oct 6, 2013 at 1:23 AM, Fengguang Wu wrote:
> >
> > I got the below dmesg and the first bad commit is commit cf39c8e5352b:
> > Merge tag 'stable/for-linus-3.12-rc0-tag' of
> > git://git.kernel.org/pub/scm/linux/kernel/g
- torva...@linux-foundation.org wrote:
> On Sun, Oct 6, 2013 at 1:23 AM, Fengguang Wu
> wrote:
> >
> > I got the below dmesg and the first bad commit is commit
> cf39c8e5352b:
> > Merge tag 'stable/for-linus-3.12-rc0-tag' of
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
>
> Ug
On Sun, Oct 6, 2013 at 1:23 AM, Fengguang Wu wrote:
>
> I got the below dmesg and the first bad commit is commit cf39c8e5352b:
> Merge tag 'stable/for-linus-3.12-rc0-tag' of
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Ugh. How reliable is the double fault? Because bisecting it to
34 matches
Mail list logo
