On Fri, Nov 5, 2010 at 4:27 AM, Arnd Bergmann wrote:
> On Wednesday 03 November 2010, Pekka Enberg wrote:
>> On Tue, Nov 2, 2010 at 3:21 AM, Pavel Machek wrote:
>> > Hi!
>> >
>> >> @@ -79,6 +79,10 @@ static struct drm_driver driver = {
>> >>
>> >> ?static int __init i810_init(void)
>> >> ?{
>> >>
On Wednesday 03 November 2010, Pekka Enberg wrote:
> On Tue, Nov 2, 2010 at 3:21 AM, Pavel Machek wrote:
> > Hi!
> >
> >> @@ -79,6 +79,10 @@ static struct drm_driver driver = {
> >>
> >> static int __init i810_init(void)
> >> {
> >> + if (num_present_cpus() > 1) {
> >> + pr_err("
On Fri, Nov 5, 2010 at 4:27 AM, Arnd Bergmann wrote:
> On Wednesday 03 November 2010, Pekka Enberg wrote:
>> On Tue, Nov 2, 2010 at 3:21 AM, Pavel Machek wrote:
>> > Hi!
>> >
>> >> @@ -79,6 +79,10 @@ static struct drm_driver driver = {
>> >>
>> >> static int __init i810_init(void)
>> >> {
>> >>
On Wednesday 03 November 2010, Pekka Enberg wrote:
> On Tue, Nov 2, 2010 at 3:21 AM, Pavel Machek wrote:
> > Hi!
> >
> >> @@ -79,6 +79,10 @@ static struct drm_driver driver = {
> >>
> >> static int __init i810_init(void)
> >> {
> >> + if (num_present_cpus() > 1) {
> >> + pr_err("
On Tue, Nov 2, 2010 at 3:21 AM, Pavel Machek wrote:
> Hi!
>
>> @@ -79,6 +79,10 @@ static struct drm_driver driver = {
>>
>> ?static int __init i810_init(void)
>> ?{
>> + ? ? if (num_present_cpus() > 1) {
>> + ? ? ? ? ? ? pr_err("drm/i810 does not support SMP\n");
>> + ? ? ? ? ? ? return -EINVAL;
>
Hi!
> @@ -79,6 +79,10 @@ static struct drm_driver driver = {
>
> static int __init i810_init(void)
> {
> + if (num_present_cpus() > 1) {
> + pr_err("drm/i810 does not support SMP\n");
> + return -EINVAL;
> + }
> driver.num_ioctls = i810_max_ioctl;
>
On Tue, Nov 2, 2010 at 3:21 AM, Pavel Machek wrote:
> Hi!
>
>> @@ -79,6 +79,10 @@ static struct drm_driver driver = {
>>
>> static int __init i810_init(void)
>> {
>> + if (num_present_cpus() > 1) {
>> + pr_err("drm/i810 does not support SMP\n");
>> + return -EINVAL;
>
Hi!
> @@ -79,6 +79,10 @@ static struct drm_driver driver = {
>
> static int __init i810_init(void)
> {
> + if (num_present_cpus() > 1) {
> + pr_err("drm/i810 does not support SMP\n");
> + return -EINVAL;
> + }
> driver.num_ioctls = i810_max_ioctl;
>
Any chance you could drop the Cc list a bit for the i810/i830
discussion? It's not relevant to most lists and people Cc'ed here.
Any chance you could drop the Cc list a bit for the i810/i830
discussion? It's not relevant to most lists and people Cc'ed here.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Oct 20, 2010 at 06:50:58AM +1000, Dave Airlie wrote:
> On Tue, Oct 19, 2010 at 11:26 PM, Arnd Bergmann wrote:
> > On Tuesday 19 October 2010, Arnd Bergmann wrote:
> >> On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
> >> > > I might be able to find some hardware still lying around h
On Wed, Oct 20, 2010 at 06:50:58AM +1000, Dave Airlie wrote:
> On Tue, Oct 19, 2010 at 11:26 PM, Arnd Bergmann wrote:
> > On Tuesday 19 October 2010, Arnd Bergmann wrote:
> >> On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
> >> > > I might be able to find some hardware still lying around h
On Wed, Oct 20, 2010 at 4:44 AM, Arnd Bergmann wrote:
> On Tuesday 19 October 2010 22:29:12 Greg KH wrote:
>> On Tue, Oct 19, 2010 at 09:40:47PM +0200, Oliver Neukum wrote:
>> > Am Dienstag, 19. Oktober 2010, 21:37:35 schrieb Greg KH:
>> > > > So no need to clean it up for multiprocessor support.
On Wednesday 20 October 2010, Dave Young wrote:
> be curious, why can't just fix the lock_kernel logic of i810? Fixing
> is too hard?
>
> Find a i810 hardware should be possible, even if the hardware does not
> support SMP, can't we test the fix with preemption?
Yes, that should work too. My usua
On Wed, Oct 20, 2010 at 4:44 AM, Arnd Bergmann wrote:
> On Tuesday 19 October 2010 22:29:12 Greg KH wrote:
>> On Tue, Oct 19, 2010 at 09:40:47PM +0200, Oliver Neukum wrote:
>> > Am Dienstag, 19. Oktober 2010, 21:37:35 schrieb Greg KH:
>> > > > So no need to clean it up for multiprocessor support.
On Tuesday 19 October 2010 22:29:12 Greg KH wrote:
> On Tue, Oct 19, 2010 at 09:40:47PM +0200, Oliver Neukum wrote:
> > Am Dienstag, 19. Oktober 2010, 21:37:35 schrieb Greg KH:
> > > > So no need to clean it up for multiprocessor support.
> > > >
> > > > http://download.intel.com/design/chipsets/d
On Tue, Oct 19, 2010 at 11:26 PM, Arnd Bergmann wrote:
> On Tuesday 19 October 2010, Arnd Bergmann wrote:
>> On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
>> > > I might be able to find some hardware still lying around here that uses
>> > > an
>> > > i810. Not sure unless I go hunting it
On Tuesday 19 October 2010 22:41:22 Alan Cox wrote:
> > > you still need to switch off preemption.
> >
> > Hm, how would you do that from within a driver?
>
> Do we care - unless I misunderstand the current intel DRM driver handles
> the i810 as well ?
No, it does handle all devices supported by
> > you still need to switch off preemption.
>
> Hm, how would you do that from within a driver?
Do we care - unless I misunderstand the current intel DRM driver handles
the i810 as well ?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http:
On Tue, 19 Oct 2010, Greg KH wrote:
> > > > So no need to clean it up for multiprocessor support.
> > > >
> > > > http://download.intel.com/design/chipsets/datashts/29067602.pdf
> > > > http://www.intel.com/design/chipsets/specupdt/29069403.pdf
> > >
> > > Great, we can just drop all calls to lo
On Tue, Oct 19, 2010 at 09:40:47PM +0200, Oliver Neukum wrote:
> Am Dienstag, 19. Oktober 2010, 21:37:35 schrieb Greg KH:
> > > So no need to clean it up for multiprocessor support.
> > >
> > > http://download.intel.com/design/chipsets/datashts/29067602.pdf
> > > http://www.intel.com/design/chipse
Am Dienstag, 19. Oktober 2010, 21:37:35 schrieb Greg KH:
> > So no need to clean it up for multiprocessor support.
> >
> > http://download.intel.com/design/chipsets/datashts/29067602.pdf
> > http://www.intel.com/design/chipsets/specupdt/29069403.pdf
>
> Great, we can just drop all calls to lock_k
On Tue, Oct 19, 2010 at 02:24:53PM -0400, valdis.kletni...@vt.edu wrote:
> On Mon, 18 Oct 2010 17:40:04 PDT, Greg KH said:
>
> > I do have access to this hardware, but its on an old single processor
> > laptop, so any work that it would take to help do this development,
> > really wouldn't be able
On Mon, 18 Oct 2010 17:40:04 PDT, Greg KH said:
> I do have access to this hardware, but its on an old single processor
> laptop, so any work that it would take to help do this development,
> really wouldn't be able to be tested to be valid at all.
The i810 is a graphics chipset embedded on the m
On Wednesday 20 October 2010, Dave Young wrote:
> be curious, why can't just fix the lock_kernel logic of i810? Fixing
> is too hard?
>
> Find a i810 hardware should be possible, even if the hardware does not
> support SMP, can't we test the fix with preemption?
Yes, that should work too. My usua
On Tue, Oct 19, 2010 at 11:26 PM, Arnd Bergmann wrote:
> On Tuesday 19 October 2010, Arnd Bergmann wrote:
>> On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
>> > > I might be able to find some hardware still lying around here that uses
>> > > an
>> > > i810. Not sure unless I go hunting it
On Tue, Oct 19, 2010 at 08:39:58AM -0400, Steven Rostedt wrote:
> On Tue, 2010-10-19 at 09:26 +0200, Arnd Bergmann wrote:
> > On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
> > > > I might be able to find some hardware still lying around here that uses
> > > > an
> > > > i810. Not sure unl
On Tuesday 19 October 2010 22:41:22 Alan Cox wrote:
> > > you still need to switch off preemption.
> >
> > Hm, how would you do that from within a driver?
>
> Do we care - unless I misunderstand the current intel DRM driver handles
> the i810 as well ?
No, it does handle all devices supported by
On Tuesday 19 October 2010 22:29:12 Greg KH wrote:
> On Tue, Oct 19, 2010 at 09:40:47PM +0200, Oliver Neukum wrote:
> > Am Dienstag, 19. Oktober 2010, 21:37:35 schrieb Greg KH:
> > > > So no need to clean it up for multiprocessor support.
> > > >
> > > > http://download.intel.com/design/chipsets/d
On Tue, 19 Oct 2010, Greg KH wrote:
> > > > So no need to clean it up for multiprocessor support.
> > > >
> > > > http://download.intel.com/design/chipsets/datashts/29067602.pdf
> > > > http://www.intel.com/design/chipsets/specupdt/29069403.pdf
> > >
> > > Great, we can just drop all calls to lo
> > you still need to switch off preemption.
>
> Hm, how would you do that from within a driver?
Do we care - unless I misunderstand the current intel DRM driver handles
the i810 as well ?
Am Dienstag, 19. Oktober 2010, 21:37:35 schrieb Greg KH:
> > So no need to clean it up for multiprocessor support.
> >
> > http://download.intel.com/design/chipsets/datashts/29067602.pdf
> > http://www.intel.com/design/chipsets/specupdt/29069403.pdf
>
> Great, we can just drop all calls to lock_k
On Tuesday 19 October 2010, Steven Rostedt wrote:
> On Tue, 2010-10-19 at 15:36 +0200, Arnd Bergmann wrote:
> > [trimming Cc list]
> >
> > On Tuesday 19 October 2010, Steven Rostedt wrote:
> > > I think we also need to cover the PREEMPT case too. But that could be a
> > > compile time check, since
[trimming Cc list]
On Tuesday 19 October 2010, Steven Rostedt wrote:
> I think we also need to cover the PREEMPT case too. But that could be a
> compile time check, since you can't boot a preempt kernel and make it
> non preempt.
Right. Can we turn the lock_kernel() into preempt_disable() in thes
On Tuesday 19 October 2010, Arnd Bergmann wrote:
> On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
> > > I might be able to find some hardware still lying around here that uses an
> > > i810. Not sure unless I go hunting it. But I get the impression that if
> > > the kernel is a single-CPU k
> I might be able to find some hardware still lying around here that uses an
> i810. Not sure unless I go hunting it. But I get the impression that if
> the kernel is a single-CPU kernel there is not any problem anyway? Don't
> distros offer a non-smp kernel as an installation option in case the us
On Mon, 18 Oct 2010 17:40:04 PDT, Greg KH said:
> I do have access to this hardware, but its on an old single processor
> laptop, so any work that it would take to help do this development,
> really wouldn't be able to be tested to be valid at all.
The i810 is a graphics chipset embedded on the m
>>
>> like I'm sure the intersection of this driver and reality are getting
>> quite limited, but its still a userspace ABI change and needs to be
>> treated as such. Xorg 6.7 and XFree86 4.3 were the last users of the
>> old driver/API.
>
> Thus, you are saying that this will break for people with
On Tue, Oct 19, 2010 at 09:40:47PM +0200, Oliver Neukum wrote:
> Am Dienstag, 19. Oktober 2010, 21:37:35 schrieb Greg KH:
> > > So no need to clean it up for multiprocessor support.
> > >
> > > http://download.intel.com/design/chipsets/datashts/29067602.pdf
> > > http://www.intel.com/design/chipse
On Tue, Oct 19, 2010 at 12:24 PM, Greg KH wrote:
> On Tue, Oct 19, 2010 at 10:57:43AM +1000, Dave Airlie wrote:
>> On Tue, Oct 19, 2010 at 10:40 AM, Greg KH wrote:
>> > On Tue, Oct 19, 2010 at 09:00:09AM +1000, Dave Airlie wrote:
>> >> On Tue, Oct 19, 2010 at 4:43 AM, Greg KH wrote:
>> >> > On M
On Tue, Oct 19, 2010 at 02:24:53PM -0400, Valdis.Kletnieks at vt.edu wrote:
> On Mon, 18 Oct 2010 17:40:04 PDT, Greg KH said:
>
> > I do have access to this hardware, but its on an old single processor
> > laptop, so any work that it would take to help do this development,
> > really wouldn't be a
On Tue, Oct 19, 2010 at 10:40 AM, Greg KH wrote:
> On Tue, Oct 19, 2010 at 09:00:09AM +1000, Dave Airlie wrote:
>> On Tue, Oct 19, 2010 at 4:43 AM, Greg KH wrote:
>> > On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote:
>> >>
>> >> Out of the remaining modules, I guess i810/i830, adfs,
On Tue, 2010-10-19 at 15:36 +0200, Arnd Bergmann wrote:
> [trimming Cc list]
>
> On Tuesday 19 October 2010, Steven Rostedt wrote:
> > I think we also need to cover the PREEMPT case too. But that could be a
> > compile time check, since you can't boot a preempt kernel and make it
> > non preempt.
On Tue, Oct 19, 2010 at 08:39:58AM -0400, Steven Rostedt wrote:
> On Tue, 2010-10-19 at 09:26 +0200, Arnd Bergmann wrote:
> > On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
> > > > I might be able to find some hardware still lying around here that uses
> > > > an
> > > > i810. Not sure unl
On Tue, 2010-10-19 at 15:36 +0200, Arnd Bergmann wrote:
> [trimming Cc list]
>
> On Tuesday 19 October 2010, Steven Rostedt wrote:
> > I think we also need to cover the PREEMPT case too. But that could be a
> > compile time check, since you can't boot a preempt kernel and make it
> > non preempt.
On Tuesday 19 October 2010, Arnd Bergmann wrote:
> On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
> > > I might be able to find some hardware still lying around here that uses an
> > > i810. Not sure unless I go hunting it. But I get the impression that if
> > > the kernel is a single-CPU k
On Tue, 2010-10-19 at 09:26 +0200, Arnd Bergmann wrote:
> On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
> > > I might be able to find some hardware still lying around here that uses an
> > > i810. Not sure unless I go hunting it. But I get the impression that if
> > > the kernel is a singl
On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
> > I might be able to find some hardware still lying around here that uses an
> > i810. Not sure unless I go hunting it. But I get the impression that if
> > the kernel is a single-CPU kernel there is not any problem anyway? Don't
> > distros
> I might be able to find some hardware still lying around here that uses an
> i810. Not sure unless I go hunting it. But I get the impression that if
> the kernel is a single-CPU kernel there is not any problem anyway? Don't
> distros offer a non-smp kernel as an installation option in case the us
On Mon, 18 Oct 2010, Steven Rostedt wrote:
> On Tue, 2010-10-19 at 12:45 +1000, Dave Airlie wrote:
> > On Tue, Oct 19, 2010 at 12:24 PM, Greg KH wrote:
>
> > > So, there is no need for the i830 driver? Can it just be removed
> > > because i915 works instead?
> >
> > No because it provides a
>>
>> like I'm sure the intersection of this driver and reality are getting
>> quite limited, but its still a userspace ABI change and needs to be
>> treated as such. Xorg 6.7 and XFree86 4.3 were the last users of the
>> old driver/API.
>
> Thus, you are saying that this will break for people with
On Tue, 2010-10-19 at 12:45 +1000, Dave Airlie wrote:
> On Tue, Oct 19, 2010 at 12:24 PM, Greg KH wrote:
> > So, there is no need for the i830 driver? Can it just be removed
> > because i915 works instead?
>
> No because it provides a different userspace ABI to the i915 driver to
> a different
On Tue, Oct 19, 2010 at 12:24 PM, Greg KH wrote:
> On Tue, Oct 19, 2010 at 10:57:43AM +1000, Dave Airlie wrote:
>> On Tue, Oct 19, 2010 at 10:40 AM, Greg KH wrote:
>> > On Tue, Oct 19, 2010 at 09:00:09AM +1000, Dave Airlie wrote:
>> >> On Tue, Oct 19, 2010 at 4:43 AM, Greg KH wrote:
>> >> > On M
On Tue, Oct 19, 2010 at 10:57:43AM +1000, Dave Airlie wrote:
> On Tue, Oct 19, 2010 at 10:40 AM, Greg KH wrote:
> > On Tue, Oct 19, 2010 at 09:00:09AM +1000, Dave Airlie wrote:
> >> On Tue, Oct 19, 2010 at 4:43 AM, Greg KH wrote:
> >> > On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrot
On Tue, Oct 19, 2010 at 10:40 AM, Greg KH wrote:
> On Tue, Oct 19, 2010 at 09:00:09AM +1000, Dave Airlie wrote:
>> On Tue, Oct 19, 2010 at 4:43 AM, Greg KH wrote:
>> > On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote:
>> >>
>> >> Out of the remaining modules, I guess i810/i830, adfs,
On Tue, Oct 19, 2010 at 09:00:09AM +1000, Dave Airlie wrote:
> On Tue, Oct 19, 2010 at 4:43 AM, Greg KH wrote:
> > On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote:
> >>
> >> Out of the remaining modules, I guess i810/i830, adfs, hpfs and ufs might
> >> end
> >> up not getting fixed
On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
> > I might be able to find some hardware still lying around here that uses an
> > i810. Not sure unless I go hunting it. But I get the impression that if
> > the kernel is a single-CPU kernel there is not any problem anyway? Don't
> > distros
On Tue, Oct 19, 2010 at 4:43 AM, Greg KH wrote:
> On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote:
>>
>> Out of the remaining modules, I guess i810/i830, adfs, hpfs and ufs might end
>> up not getting fixed at all, we can either mark them non-SMP or move them
>> to drivers/staging on
On Tue, 2010-10-19 at 09:26 +0200, Arnd Bergmann wrote:
> On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
> > > I might be able to find some hardware still lying around here that uses an
> > > i810. Not sure unless I go hunting it. But I get the impression that if
> > > the kernel is a singl
On Tuesday 19 October 2010, Steven Rostedt wrote:
> On Tue, 2010-10-19 at 15:36 +0200, Arnd Bergmann wrote:
> > [trimming Cc list]
> >
> > On Tuesday 19 October 2010, Steven Rostedt wrote:
> > > I think we also need to cover the PREEMPT case too. But that could be a
> > > compile time check, since
[trimming Cc list]
On Tuesday 19 October 2010, Steven Rostedt wrote:
> I think we also need to cover the PREEMPT case too. But that could be a
> compile time check, since you can't boot a preempt kernel and make it
> non preempt.
Right. Can we turn the lock_kernel() into preempt_disable() in thes
On Mon, 18 Oct 2010, Steven Rostedt wrote:
> On Tue, 2010-10-19 at 12:45 +1000, Dave Airlie wrote:
> > On Tue, Oct 19, 2010 at 12:24 PM, Greg KH wrote:
>
> > > So, there is no need for the i830 driver? Can it just be removed
> > > because i915 works instead?
> >
> > No because it provides a
On Tue, 2010-10-19 at 12:45 +1000, Dave Airlie wrote:
> On Tue, Oct 19, 2010 at 12:24 PM, Greg KH wrote:
> > So, there is no need for the i830 driver? Can it just be removed
> > because i915 works instead?
>
> No because it provides a different userspace ABI to the i915 driver to
> a different
On Monday 18 October 2010 18:19:24 Christoph Hellwig wrote:
> Before we get into all these fringe drivers:
>
> - I've not seen any progrss on ->get_sb BKL removal for a while
Not sure what you mean. Jan Blunck did the pushdown into get_sb
last year, which is included into linux-next through my b
On Tue, Oct 19, 2010 at 10:57:43AM +1000, Dave Airlie wrote:
> On Tue, Oct 19, 2010 at 10:40 AM, Greg KH wrote:
> > On Tue, Oct 19, 2010 at 09:00:09AM +1000, Dave Airlie wrote:
> >> On Tue, Oct 19, 2010 at 4:43 AM, Greg KH wrote:
> >> > On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrot
This is a update on the current progress for the BKL removal, reflecting
what is currently in linux-next.
Maybe we can briefly discuss this at the kernel summit to decide if we
want a quick death of the BKL, i.e. fixing/disabling/staging-out the
remaining users in 2.6.38 or rather leave them there
On Tue, Oct 19, 2010 at 09:00:09AM +1000, Dave Airlie wrote:
> On Tue, Oct 19, 2010 at 4:43 AM, Greg KH wrote:
> > On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote:
> >>
> >> Out of the remaining modules, I guess i810/i830, adfs, hpfs and ufs might
> >> end
> >> up not getting fixed
On Tue, Oct 19, 2010 at 4:43 AM, Greg KH wrote:
> On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote:
>>
>> Out of the remaining modules, I guess i810/i830, adfs, hpfs and ufs might end
>> up not getting fixed at all, we can either mark them non-SMP or move them
>> to drivers/staging on
Before we get into all these fringe drivers:
- I've not seen any progrss on ->get_sb BKL removal for a while
- locks.c is probably a higher priorit, too.
On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote:
>
> Out of the remaining modules, I guess i810/i830, adfs, hpfs and ufs might end
> up not getting fixed at all, we can either mark them non-SMP or move them
> to drivers/staging once all the others are done.
I recommend moving them t
On Monday 18 October 2010 18:19:24 Christoph Hellwig wrote:
> Before we get into all these fringe drivers:
>
> - I've not seen any progrss on ->get_sb BKL removal for a while
Not sure what you mean. Jan Blunck did the pushdown into get_sb
last year, which is included into linux-next through my b
Before we get into all these fringe drivers:
- I've not seen any progrss on ->get_sb BKL removal for a while
- locks.c is probably a higher priorit, too.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/l
This is a update on the current progress for the BKL removal, reflecting
what is currently in linux-next.
Maybe we can briefly discuss this at the kernel summit to decide if we
want a quick death of the BKL, i.e. fixing/disabling/staging-out the
remaining users in 2.6.38 or rather leave them there
On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote:
>
> Out of the remaining modules, I guess i810/i830, adfs, hpfs and ufs might end
> up not getting fixed at all, we can either mark them non-SMP or move them
> to drivers/staging once all the others are done.
I recommend moving them t
On Saturday 18 September 2010 01:21:41 Petr Vandrovec wrote:
>
> I'll try to come up with something for ncpfs.
Ok, good.
> Trivial lock replacement will open deadlock possibility when
> someone reads to page which is also mmaped from the same
> filesystem (like grep likes to do). BKL with its a
On Saturday 18 September 2010 01:21:41 Petr Vandrovec wrote:
>
> I'll try to come up with something for ncpfs.
Ok, good.
> Trivial lock replacement will open deadlock possibility when
> someone reads to page which is also mmaped from the same
> filesystem (like grep likes to do). BKL with its a
I'll try to come up with something for ncpfs.
Trivial lock replacement will open deadlock possibility when someone reads to
page which is also mmaped from the same filesystem (like grep likes to do). BKL
with its automated release on sleep helped (or papered over) a lot here.
Petr
"Arnd Bergma
On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote:
> The big kernel lock is gone from almost all code in linux-next, this is
> the status of what I think will happen to the remaining users:
>
...
> fs/autofs:
> Pretty much dead, replaced by autofs4. I'd suggest moving this
> to
On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote:
> The big kernel lock is gone from almost all code in linux-next, this is
> the status of what I think will happen to the remaining users:
>
...
> fs/autofs:
> Pretty much dead, replaced by autofs4. I'd suggest moving this
> to
On Thursday 16 September 2010 20:32:36 Jens Axboe wrote:
> On 2010-09-16 16:49, Steven Rostedt wrote:
> > Git blame shows this to be your code (copied from block/blktrace.c from
> > years past).
> >
> > Is the lock_kernel() needed here? (although Arnd did add it in 62c2a7d9)
>
> It isn't, it can
On Thursday 16 September 2010 20:32:36 Jens Axboe wrote:
> On 2010-09-16 16:49, Steven Rostedt wrote:
> > Git blame shows this to be your code (copied from block/blktrace.c from
> > years past).
> >
> > Is the lock_kernel() needed here? (although Arnd did add it in 62c2a7d9)
>
> It isn't, it can
I'll try to come up with something for ncpfs.
Trivial lock replacement will open deadlock possibility when someone reads to
page which is also mmaped from the same filesystem (like grep likes to do). BKL
with its automated release on sleep helped (or papered over) a lot here.
Petr
"Arnd Bergma
Hi,
On 16 Sep 2010, at 16:04, Jan Kara wrote:
> On Thu 16-09-10 16:32:59, Arnd Bergmann wrote:
>> The big kernel lock is gone from almost all code in linux-next, this is
>> the status of what I think will happen to the remaining users:
> ...
>> fs/ncpfs:
>> Should be fixable if Petr still car
From: Samuel Ortiz
Date: Thu, 16 Sep 2010 18:57:56 +0200
> On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote:
>> net/appletalk:
>> net/ipx/af_ipx.c:
>> net/irda/af_irda.c:
>> Can probably be saved from retirement in drivers/staging if the
>> maintainers still care.
> I'll take care
On 2010-09-16 16:49, Steven Rostedt wrote:
> On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote:
>> The big kernel lock is gone from almost all code in linux-next, this is
>> the status of what I think will happen to the remaining users:
>
>> kernel/trace/blktrace.c:
>> Should be easy. In
On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote:
> net/appletalk:
> net/ipx/af_ipx.c:
> net/irda/af_irda.c:
> Can probably be saved from retirement in drivers/staging if the
> maintainers still care.
I'll take care of the IrDA part.
Cheers,
Samuel.
On 2010-09-16 16:32:59, Arnd Bergmann wrote:
> The big kernel lock is gone from almost all code in linux-next, this is
> the status of what I think will happen to the remaining users:
> fs/qnx4:
> Should be easy to fix, there are only a few places in the code that
> use the BKL. Anders
> net/appletalk:
> net/ipx/af_ipx.c:
> net/irda/af_irda.c:
> Can probably be saved from retirement in drivers/staging if the
> maintainers still care.
IPX and Appletalk both have active users. They also look fairly fixable
as the lock_kernel just maps to a stack private mutex, or in se
On Thu 16-09-10 16:32:59, Arnd Bergmann wrote:
> The big kernel lock is gone from almost all code in linux-next, this is
> the status of what I think will happen to the remaining users:
...
> fs/ncpfs:
> Should be fixable if Petr still cares about it. Otherwise suggest
> moving to drive
From: Alan Cox
Date: Thu, 16 Sep 2010 16:07:59 +0100
>> net/appletalk:
>> net/ipx/af_ipx.c:
>> net/irda/af_irda.c:
>> Can probably be saved from retirement in drivers/staging if the
>> maintainers still care.
>
> IPX and Appletalk both have active users. They also look fairly fixable
>
On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote:
> The big kernel lock is gone from almost all code in linux-next, this is
> the status of what I think will happen to the remaining users:
> kernel/trace/blktrace.c:
> Should be easy. Ingo? Steven?
>
Jens,
Git blame shows this to be
The big kernel lock is gone from almost all code in linux-next, this is
the status of what I think will happen to the remaining users:
drivers/gpu/drm/i810/{i810,i830}_dma.c:
Fixable, but needs someone with the hardware to test. Can probably be
marked CONFIG_BROKEN_ON_SMP if nobody
Hi,
On 16 Sep 2010, at 16:04, Jan Kara wrote:
> On Thu 16-09-10 16:32:59, Arnd Bergmann wrote:
>> The big kernel lock is gone from almost all code in linux-next, this is
>> the status of what I think will happen to the remaining users:
> ...
>> fs/ncpfs:
>> Should be fixable if Petr still car
On 2010-09-16 16:49, Steven Rostedt wrote:
> On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote:
>> The big kernel lock is gone from almost all code in linux-next, this is
>> the status of what I think will happen to the remaining users:
>
>> kernel/trace/blktrace.c:
>> Should be easy. In
On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote:
> net/appletalk:
> net/ipx/af_ipx.c:
> net/irda/af_irda.c:
> Can probably be saved from retirement in drivers/staging if the
> maintainers still care.
I'll take care of the IrDA part.
Cheers,
Samuel.
On 2010-09-16 16:32:59, Arnd Bergmann wrote:
> The big kernel lock is gone from almost all code in linux-next, this is
> the status of what I think will happen to the remaining users:
> fs/qnx4:
> Should be easy to fix, there are only a few places in the code that
> use the BKL. Anders
On Thu 16-09-10 16:32:59, Arnd Bergmann wrote:
> The big kernel lock is gone from almost all code in linux-next, this is
> the status of what I think will happen to the remaining users:
...
> fs/ncpfs:
> Should be fixable if Petr still cares about it. Otherwise suggest
> moving to drive
The big kernel lock is gone from almost all code in linux-next, this is
the status of what I think will happen to the remaining users:
drivers/gpu/drm/i810/{i810,i830}_dma.c:
Fixable, but needs someone with the hardware to test. Can probably be
marked CONFIG_BROKEN_ON_SMP if nobody
> net/appletalk:
> net/ipx/af_ipx.c:
> net/irda/af_irda.c:
> Can probably be saved from retirement in drivers/staging if the
> maintainers still care.
IPX and Appletalk both have active users. They also look fairly fixable
as the lock_kernel just maps to a stack private mutex, or in se
From: Alan Cox
Date: Thu, 16 Sep 2010 16:07:59 +0100
>> net/appletalk:
>> net/ipx/af_ipx.c:
>> net/irda/af_irda.c:
>> Can probably be saved from retirement in drivers/staging if the
>> maintainers still care.
>
> IPX and Appletalk both have active users. They also look fairly fixable
>
1 - 100 of 102 matches
Mail list logo
