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 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 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 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
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
> > 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 ?
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord
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 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, 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 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 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordom
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 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 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 Friday 17 September 2010, Christoph Hellwig wrote:
>
> Just add a per-sb mutex inside the filesystem. Given that lock_super
> isn't used by the VFS anymore that's actually equivalent.
Ok, thanks for the hint. I'll fix that for isofs.
Arnd
--
To unsubscribe from this list: send the li
On Fri, Sep 17, 2010 at 03:50:49PM +0200, Arnd Bergmann wrote:
> On Friday 17 September 2010, Christoph Hellwig wrote:
> >
> > On Fri, Sep 17, 2010 at 12:45:41PM +0200, Arnd Bergmann wrote:
> > > ncpfs: replace BKL with lock_super
> >
> > Err, no. lock_super is just as much on it's way out as th
On Friday 17 September 2010, Christoph Hellwig wrote:
>
> On Fri, Sep 17, 2010 at 12:45:41PM +0200, Arnd Bergmann wrote:
> > ncpfs: replace BKL with lock_super
>
> Err, no. lock_super is just as much on it's way out as the BKL. We've
> managed to move it down from the VFS into a few remaining f
On Fri, Sep 17, 2010 at 12:45:41PM +0200, Arnd Bergmann wrote:
> ncpfs: replace BKL with lock_super
Err, no. lock_super is just as much on it's way out as the BKL. We've
managed to move it down from the VFS into a few remaining filesystems
and now need to get rid of those users. Please don't ad
On Thursday 16 September 2010, Anton Altaparmakov wrote:
> 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:
>
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: 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
>
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.
--
To unsubscribe from this
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
> 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, 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
50 matches
Mail list logo
