Re: [PATCH]] drm/dp check aux_dev before use in drm_dp_aux_dev_get_by_minor()
On Mon, 7 Sep 2020, Ville Syrjälä wrote: > On Fri, Sep 04, 2020 at 12:21:26AM -0700, Zwane Mwaikambo wrote: > > I observed this when unplugging a DP monitor whilst a computer is asleep > > and then waking it up. This left DP chardev nodes still being present on > > the filesystem and accessing these device nodes caused an oops because > > drm_dp_aux_dev_get_by_minor() assumes a device exists if it is opened. > > This can also be reproduced by creating a device node with mknod(1) and > > issuing an open(2) > > > > [166164.933198] BUG: kernel NULL pointer dereference, address: > > 0018 > > [166164.933202] #PF: supervisor read access in kernel mode > > [166164.933204] #PF: error_code(0x) - not-present page > > [166164.933205] PGD 0 P4D 0 > > [166164.933208] Oops: [#1] PREEMPT SMP NOPTI > > [166164.933211] CPU: 4 PID: 99071 Comm: fwupd Tainted: GW > > 5.8.0-rc6+ #1 > > [166164.933213] Hardware name: LENOVO 20RD002VUS/20RD002VUS, BIOS R16ET25W > > (1.11 ) 04/21/2020 > > [166164.933232] RIP: 0010:drm_dp_aux_dev_get_by_minor+0x29/0x70 > > [drm_kms_helper] > > [166164.933234] Code: 00 0f 1f 44 00 00 55 48 89 e5 41 54 41 89 fc 48 c7 > > c7 60 01 a4 c0 e8 26 ab 30 d7 44 89 e6 48 c7 c7 80 01 a4 c0 e8 47 94 d6 d6 > > <8b> 50 18 49 89 c4 48 8d 78 18 85 d2 74 33 8d 4a 01 89 d0 f0 0f b1 > > [166164.933236] RSP: 0018:b7d7c41cbbf0 EFLAGS: 00010246 > > [166164.933237] RAX: RBX: 8a90001fe900 RCX: > > > > [166164.933238] RDX: RSI: 0003 RDI: > > c0a40180 > > [166164.933239] RBP: b7d7c41cbbf8 R08: R09: > > 8a93e157d6d0 > > [166164.933240] R10: R11: c0a40188 R12: > > 0003 > > [166164.933241] R13: 8a9402200e80 R14: 8a90001fe900 R15: > > > > [166164.933244] FS: 7f7fb041eb00() GS:8a941150() > > knlGS: > > [166164.933245] CS: 0010 DS: ES: CR0: 80050033 > > [166164.933246] CR2: 0018 CR3: 352c2003 CR4: > > 003606e0 > > [166164.933247] Call Trace: > > [166164.933264] auxdev_open+0x1b/0x40 [drm_kms_helper] > > [166164.933278] chrdev_open+0xa7/0x1c0 > > [166164.933282] ? cdev_put.part.0+0x20/0x20 > > [166164.933287] do_dentry_open+0x161/0x3c0 > > [166164.933291] vfs_open+0x2d/0x30 > > [166164.933297] path_openat+0xb27/0x10e0 > > [166164.933306] ? atime_needs_update+0x73/0xd0 > > [166164.933309] do_filp_open+0x91/0x100 > > [166164.933313] ? __alloc_fd+0xb2/0x150 > > [166164.933316] do_sys_openat2+0x210/0x2d0 > > [166164.933318] do_sys_open+0x46/0x80 > > [166164.933320] __x64_sys_openat+0x20/0x30 > > [166164.933328] do_syscall_64+0x52/0xc0 > > [166164.96] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > > > (gdb) disassemble drm_dp_aux_dev_get_by_minor+0x29 > > Dump of assembler code for function drm_dp_aux_dev_get_by_minor: > >0x00017b10 <+0>: callq 0x17b15 > > > >0x00017b15 <+5>: push %rbp > >0x00017b16 <+6>: mov%rsp,%rbp > >0x00017b19 <+9>: push %r12 > >0x00017b1b <+11>:mov%edi,%r12d > >0x00017b1e <+14>:mov$0x0,%rdi > >0x00017b25 <+21>:callq 0x17b2a > > > >0x00017b2a <+26>:mov%r12d,%esi > >0x00017b2d <+29>:mov$0x0,%rdi > >0x00017b34 <+36>:callq 0x17b39 > > > >0x00017b39 <+41>:mov0x18(%rax),%edx <= > >0x00017b3c <+44>:mov%rax,%r12 > >0x00017b3f <+47>:lea0x18(%rax),%rdi > >0x00017b43 <+51>:test %edx,%edx > >0x00017b45 <+53>:je 0x17b7a > > > >0x00017b47 <+55>:lea0x1(%rdx),%ecx > >0x00017b4a <+58>:mov%edx,%eax > >0x00017b4c <+60>:lock cmpxchg %ecx,(%rdi) > >0x00017b50 <+64>:jne0x17b76 > > > >0x00017b52 <+66>:test %edx,%edx > >0x00017b54 <+68>:js 0x17b6d > > > >0x00017b56 <+70>:test %ecx,%ecx > >0x00017b58 <+72>:js 0x17b6d > > > >0x00017b5a <+74>:mov$0x0,%rdi &
[PATCH]] drm/dp check aux_dev before use in drm_dp_aux_dev_get_by_minor()
nd(&aux_idr, index);
66 if (!kref_get_unless_zero(&aux_dev->refcount))
67 aux_dev = NULL;
68 mutex_unlock(&aux_idr_mutex);
69
(gdb) p/x &((struct drm_dp_aux_dev *)(0x0))->refcount
$8 = 0x18
Looking at the caller, checks on the minor are pushed down to
drm_dp_aux_dev_get_by_minor()
static int auxdev_open(struct inode *inode, struct file *file)
{
unsigned int minor = iminor(inode);
struct drm_dp_aux_dev *aux_dev;
aux_dev = drm_dp_aux_dev_get_by_minor(minor); <
if (!aux_dev)
return -ENODEV;
file->private_data = aux_dev;
return 0;
}
Fixes: e94cb37b34eb8 ("Add a drm_aux-dev module for reading/writing dpcd
registers")
Cc: sta...@vger.kernel.org
Signed-off-by: Zwane Mwaikambo
---
diff --git a/drivers/gpu/drm/drm_dp_aux_dev.c b/drivers/gpu/drm/drm_dp_aux_dev.c
index 2510717d5a08..e25181bf2c48 100644
--- a/drivers/gpu/drm/drm_dp_aux_dev.c
+++ b/drivers/gpu/drm/drm_dp_aux_dev.c
@@ -63,7 +63,7 @@ static struct drm_dp_aux_dev
*drm_dp_aux_dev_get_by_minor(unsigned index)
mutex_lock(&aux_idr_mutex);
aux_dev = idr_find(&aux_idr, index);
- if (!kref_get_unless_zero(&aux_dev->refcount))
+ if (aux_dev && !kref_get_unless_zero(&aux_dev->refcount))
aux_dev = NULL;
mutex_unlock(&aux_idr_mutex);
Re: [PATCH] drm: assure aux_dev is nonzero before using it
On Wed, 12 Aug 2020, Lyude Paul wrote: > On Wed, 2020-08-12 at 16:10 +0200, Daniel Vetter wrote: > > On Wed, Aug 12, 2020 at 12:16 AM Zwane Mwaikambo wrote: > > > On Tue, 11 Aug 2020, Daniel Vetter wrote: > > > > > > > On Mon, Aug 10, 2020 at 10:11:50AM -0700, Zwane Mwaikambo wrote: > > > > > Hi Folks, > > > > > I know this thread eventually dropped off due to not identifying > > > > > the underlying issue. It's still occuring on 5.8 and in my case it > > > > > happened because the udev device nodes for the DP aux devices were not > > > > > cleaned up whereas the kernel had no association with them. I can > > > > > reproduce the bug just by creating a device node for a non-existent > > > > > minor > > > > > device and calling open(). > > > > > > > > Hm I don't have that thread anymore, but generally these bugs are solved > > > > by not registering the device before it's ready for use. We do have > > > > drm_connector->late_register for that stuff. Just a guess since I'm not > > > > seeing full details here. > > > > > > In this particular case, the physical device disappeared before the nodes > > > were cleaned up. It involves putting a computer to sleep with a monitor > > > plugged in and then waking it up with the monitor unplugged. > > > > We also have early_unregister for the reverse, but yes this sounds > > more tricky ... Adding Lyude who's been working on way too much > > lifetime fun around dp recently. > > -Daniel > > > Hi-I think just checking whether the auxdev is NULL or not is a reasonable > fix, although I am curious as to how exactly the aux dev's parent is getting > destroyed before it's child, which I would have thought would be the only way > you could hit this? Hi, If this is acceptable, would you consider an updated patch against 5.8? Thanks, Zwane
Re: [PATCH] drm: assure aux_dev is nonzero before using it
On Wed, 12 Aug 2020, Lyude Paul wrote:
> On Wed, 2020-08-12 at 16:10 +0200, Daniel Vetter wrote:
> > On Wed, Aug 12, 2020 at 12:16 AM Zwane Mwaikambo wrote:
> > > On Tue, 11 Aug 2020, Daniel Vetter wrote:
> > >
> > > > On Mon, Aug 10, 2020 at 10:11:50AM -0700, Zwane Mwaikambo wrote:
> > > > > Hi Folks,
> > > > > I know this thread eventually dropped off due to not identifying
> > > > > the underlying issue. It's still occuring on 5.8 and in my case it
> > > > > happened because the udev device nodes for the DP aux devices were not
> > > > > cleaned up whereas the kernel had no association with them. I can
> > > > > reproduce the bug just by creating a device node for a non-existent
> > > > > minor
> > > > > device and calling open().
> > > >
> > > > Hm I don't have that thread anymore, but generally these bugs are solved
> > > > by not registering the device before it's ready for use. We do have
> > > > drm_connector->late_register for that stuff. Just a guess since I'm not
> > > > seeing full details here.
> > >
> > > In this particular case, the physical device disappeared before the nodes
> > > were cleaned up. It involves putting a computer to sleep with a monitor
> > > plugged in and then waking it up with the monitor unplugged.
> >
> > We also have early_unregister for the reverse, but yes this sounds
> > more tricky ... Adding Lyude who's been working on way too much
> > lifetime fun around dp recently.
> > -Daniel
> >
> Hi-I think just checking whether the auxdev is NULL or not is a reasonable
> fix, although I am curious as to how exactly the aux dev's parent is getting
> destroyed before it's child, which I would have thought would be the only way
> you could hit this?
Here is what it looks like without (1) and with (2) monitor connected. In
the case where the monitor disappears during suspend, the device nodes
aux3,4 are still around
1) No monitor connected
ls -l /dev/drm*
crw--- 1 root root 238, 0 Aug 6 22:32 /dev/drm_dp_aux0
crw--- 1 root root 238, 1 Aug 6 22:32 /dev/drm_dp_aux1
2) Monitor connected
crw--- 1 root root 238, 0 Aug 6 22:32 /dev/drm_dp_aux0
crw--- 1 root root 238, 1 Aug 6 22:32 /dev/drm_dp_aux1
crw--- 1 root root 238, 2 Aug 11 14:51 /dev/drm_dp_aux2
crw--- 1 root root 238, 3 Aug 11 14:51 /dev/drm_dp_aux3
crw--- 1 root root 238, 4 Aug 11 14:51 /dev/drm_dp_aux4
>
> > >
> > > > > To me it still makes sense to just check aux_dev because the chardev
> > > > > has
> > > > > no way to check before calling.
> > > > >
> > > > > (gdb) list *drm_dp_aux_dev_get_by_minor+0x29
> > > > > 0x17b39 is in drm_dp_aux_dev_get_by_minor
> > > > > (drivers/gpu/drm/drm_dp_aux_dev.c:65).
> > > > > 60 static struct drm_dp_aux_dev
> > > > > *drm_dp_aux_dev_get_by_minor(unsigned index)
> > > > > 61 {
> > > > > 62 struct drm_dp_aux_dev *aux_dev = NULL;
> > > > > 63
> > > > > 64 mutex_lock(&aux_idr_mutex);
> > > > > 65 aux_dev = idr_find(&aux_idr, index);
> > > > > 66 if (!kref_get_unless_zero(&aux_dev->refcount))
> > > > > 67 aux_dev = NULL;
> > > > > 68 mutex_unlock(&aux_idr_mutex);
> > > > > 69
> > > > > (gdb) p/x &((struct drm_dp_aux_dev *)(0x0))->refcount
> > > > > $8 = 0x18
> > > > >
> > > > > static int auxdev_open(struct inode *inode, struct file *file)
> > > > > {
> > > > > unsigned int minor = iminor(inode);
> > > > > struct drm_dp_aux_dev *aux_dev;
> > > > >
> > > > > aux_dev = drm_dp_aux_dev_get_by_minor(minor);
> > > > > if (!aux_dev)
> > > > > return -ENODEV;
> > > > >
> > > > > file->private_data = aux_dev;
> > > > > return 0;
> > > > > }
> > > > >
> > > > >
> > > > > ___
> > > > > dri-devel mailing list
> > > > > dri-de...@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> >
>
Re: [PATCH] drm: assure aux_dev is nonzero before using it
On Tue, 11 Aug 2020, Daniel Vetter wrote:
> On Mon, Aug 10, 2020 at 10:11:50AM -0700, Zwane Mwaikambo wrote:
> > Hi Folks,
> > I know this thread eventually dropped off due to not identifying
> > the underlying issue. It's still occuring on 5.8 and in my case it
> > happened because the udev device nodes for the DP aux devices were not
> > cleaned up whereas the kernel had no association with them. I can
> > reproduce the bug just by creating a device node for a non-existent minor
> > device and calling open().
>
> Hm I don't have that thread anymore, but generally these bugs are solved
> by not registering the device before it's ready for use. We do have
> drm_connector->late_register for that stuff. Just a guess since I'm not
> seeing full details here.
In this particular case, the physical device disappeared before the nodes
were cleaned up. It involves putting a computer to sleep with a monitor
plugged in and then waking it up with the monitor unplugged.
> >
> > To me it still makes sense to just check aux_dev because the chardev has
> > no way to check before calling.
> >
> > (gdb) list *drm_dp_aux_dev_get_by_minor+0x29
> > 0x17b39 is in drm_dp_aux_dev_get_by_minor
> > (drivers/gpu/drm/drm_dp_aux_dev.c:65).
> > 60 static struct drm_dp_aux_dev *drm_dp_aux_dev_get_by_minor(unsigned
> > index)
> > 61 {
> > 62 struct drm_dp_aux_dev *aux_dev = NULL;
> > 63
> > 64 mutex_lock(&aux_idr_mutex);
> > 65 aux_dev = idr_find(&aux_idr, index);
> > 66 if (!kref_get_unless_zero(&aux_dev->refcount))
> > 67 aux_dev = NULL;
> > 68 mutex_unlock(&aux_idr_mutex);
> > 69
> > (gdb) p/x &((struct drm_dp_aux_dev *)(0x0))->refcount
> > $8 = 0x18
> >
> > static int auxdev_open(struct inode *inode, struct file *file)
> > {
> > unsigned int minor = iminor(inode);
> > struct drm_dp_aux_dev *aux_dev;
> >
> > aux_dev = drm_dp_aux_dev_get_by_minor(minor);
> > if (!aux_dev)
> > return -ENODEV;
> >
> > file->private_data = aux_dev;
> > return 0;
> > }
> >
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
Re: [PATCH] drm: assure aux_dev is nonzero before using it
Hi Folks,
I know this thread eventually dropped off due to not identifying
the underlying issue. It's still occuring on 5.8 and in my case it
happened because the udev device nodes for the DP aux devices were not
cleaned up whereas the kernel had no association with them. I can
reproduce the bug just by creating a device node for a non-existent minor
device and calling open().
To me it still makes sense to just check aux_dev because the chardev has
no way to check before calling.
(gdb) list *drm_dp_aux_dev_get_by_minor+0x29
0x17b39 is in drm_dp_aux_dev_get_by_minor (drivers/gpu/drm/drm_dp_aux_dev.c:65).
60 static struct drm_dp_aux_dev *drm_dp_aux_dev_get_by_minor(unsigned
index)
61 {
62 struct drm_dp_aux_dev *aux_dev = NULL;
63
64 mutex_lock(&aux_idr_mutex);
65 aux_dev = idr_find(&aux_idr, index);
66 if (!kref_get_unless_zero(&aux_dev->refcount))
67 aux_dev = NULL;
68 mutex_unlock(&aux_idr_mutex);
69
(gdb) p/x &((struct drm_dp_aux_dev *)(0x0))->refcount
$8 = 0x18
static int auxdev_open(struct inode *inode, struct file *file)
{
unsigned int minor = iminor(inode);
struct drm_dp_aux_dev *aux_dev;
aux_dev = drm_dp_aux_dev_get_by_minor(minor);
if (!aux_dev)
return -ENODEV;
file->private_data = aux_dev;
return 0;
}
Re: [PATCH] Fix USB Type C hub crash in typec_altmode_update_active
On Sat, 25 Jul 2020, Zwane Mwaikambo wrote:
> diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
> index d0c63afaf..30d0857e4 100644
> --- a/drivers/usb/typec/ucsi/ucsi.c
> +++ b/drivers/usb/typec/ucsi/ucsi.c
> @@ -218,9 +218,12 @@ void ucsi_altmode_update_active(struct ucsi_connector
> *con)
> if (cur < UCSI_MAX_ALTMODES)
> altmode = typec_altmode_get_partner(con->port_altmode[cur]);
>
> - for (i = 0; con->partner_altmode[i]; i++)
> - typec_altmode_update_active(con->partner_altmode[i],
> - con->partner_altmode[i] == altmode);
> + for (i = 0; i < UCSI_MAX_ALTMODES; i++) {
> +if (con->partner_altmode[i]) {
> + typec_altmode_update_active(con->partner_altmode[i],
> + con->partner_altmode[i] ==
> altmode);
> +}
> +}
> }
>
> static u8 ucsi_altmode_next_mode(struct typec_altmode **alt, u16 svid)
>
Previous patch had whitespace issues and i cleaned it up for coding style
reasons, patch is against 5.8.0-rc6
diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
index d0c63afaf..30e811fde 100644
--- a/drivers/usb/typec/ucsi/ucsi.c
+++ b/drivers/usb/typec/ucsi/ucsi.c
@@ -218,9 +218,10 @@ void ucsi_altmode_update_active(struct ucsi_connector *con)
if (cur < UCSI_MAX_ALTMODES)
altmode = typec_altmode_get_partner(con->port_altmode[cur]);
- for (i = 0; con->partner_altmode[i]; i++)
- typec_altmode_update_active(con->partner_altmode[i],
- con->partner_altmode[i] == altmode);
+ for (i = 0; i < UCSI_MAX_ALTMODES; i++)
+ if (con->partner_altmode[i])
+ typec_altmode_update_active(con->partner_altmode[i],
+
con->partner_altmode[i] == altmode);
}
static u8 ucsi_altmode_next_mode(struct typec_altmode **alt, u16 svid)
[PATCH] Fix USB Type C hub crash in typec_altmode_update_active
The following crash occurs whilst plugging in a Thinkpad USB type C dock
and appears to be affecting other users as seen below;
https://bbs.archlinux.org/viewtopic.php?id=256404
https://forums.linuxmint.com/viewtopic.php?p=1826251
My specific crash is;
[ 565.427757] input: USBPS2 as
/devices/pci:00/:00:14.0/usb1/1-2/1-2.1/1-2.1.4/1-2.1.4:1.0/0003:0D3D:0001.0006/input/input31
[ 565.452023] BUG: kernel NULL pointer dereference, address: 02fe
[ 565.452025] #PF: supervisor read access in kernel mode
[ 565.452026] #PF: error_code(0x) - not-present page
[ 565.452026] PGD 0 P4D 0
[ 565.452028] Oops: [#1] PREEMPT SMP NOPTI
[ 565.452030] CPU: 0 PID: 502 Comm: kworker/0:3 Not tainted 5.8.0-rc3+ #1
[ 565.452031] Hardware name: LENOVO 20RD002VUS/20RD002VUS, BIOS R16ET25W (1.11
) 04/21/2020
[ 565.452034] Workqueue: events ucsi_handle_connector_change [typec_ucsi]
[ 565.452039] RIP: 0010:typec_altmode_update_active+0x1f/0x100 [typec]
[ 565.452040] Code: 0f 1f 84 00 00 00 00 00 0f 1f 00 0f 1f 44 00 00 55 48
89 e5 41 54 53 48 83 ec 10 65 48 8b 04 25 28 00 00 00 48 89 45 e8 31 c0
<0f> b6 87 fc 02 00 00 83 e0 01 40 38 f0 0f 84 95 00 00 00 48 8b 47
[ 565.452041] RSP: 0018:b729c066bdb0 EFLAGS: 00010246
[ 565.452042] RAX: RBX: a067c3e64a70 RCX:
[ 565.452043] RDX: b729c066bd20 RSI: RDI: 0002
[ 565.452044] RBP: b729c066bdd0 R08: 0083a7910a4f R09:
[ 565.452044] R10: a106a220 R11: R12:
[ 565.452045] R13: a067c3e64a98 R14: a067c3e64810 R15: a067c3e64800
[ 565.452046] FS: () GS:a067d140()
knlGS:
[ 565.452047] CS: 0010 DS: ES: CR0: 80050033
[ 565.452048] CR2: 02fe CR3: 0001b060a003 CR4: 003606f0
[ 565.452048] Call Trace:
[ 565.452052] ucsi_altmode_update_active+0x83/0xd0 [typec_ucsi]
[ 565.452054] ucsi_handle_connector_change+0x1dc/0x320 [typec_ucsi]
[ 565.452057] process_one_work+0x1df/0x3d0
[ 565.452059] worker_thread+0x4d/0x3d0
[ 565.452060] ? process_one_work+0x3d0/0x3d0
[ 565.452062] kthread+0x127/0x170
[ 565.452063] ? kthread_park+0x90/0x90
[ 565.452065] ret_from_fork+0x1f/0x30
The failing instruction is;
0x0380 <+0>: callq 0x385
0x0385 <+5>: push %rbp
0x0386 <+6>: mov%rsp,%rbp
0x0389 <+9>: push %r12
0x038b <+11>:push %rbx
0x038c <+12>:sub$0x10,%rsp
0x0390 <+16>:mov%gs:0x28,%rax
0x0399 <+25>:mov%rax,-0x18(%rbp)
0x039d <+29>:xor%eax,%eax
0x039f <+31>:movzbl 0x2fc(%rdi),%eax <==
0x03a6 <+38>:and$0x1,%eax
(gdb) list *typec_altmode_update_active+0x1f
0x39f is in typec_altmode_update_active (drivers/usb/typec/class.c:221).
216 */
217 void typec_altmode_update_active(struct typec_altmode *adev, bool
active)
218 {
219 char dir[6];
220
221 if (adev->active == active)
222 return;
223
224 if (!is_typec_port(adev->dev.parent) && adev->dev.driver) {
225 if (!active)
(gdb) list *ucsi_altmode_update_active+0x83
0x12a3 is in ucsi_altmode_update_active (drivers/usb/typec/ucsi/ucsi.c:221).
216 }
217
218 if (cur < UCSI_MAX_ALTMODES)
219 altmode =
typec_altmode_get_partner(con->port_altmode[cur]);
220
221 for (i = 0; con->partner_altmode[i]; i++)
222 typec_altmode_update_active(con->partner_altmode[i],
223con->partner_altmode[i] ==
altmode);
224 }
con->partner_altmode[i] ends up with the value 0x2 in the call and it's
because the array has been accessed out of bounds.
diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
index d0c63afaf..30d0857e4 100644
--- a/drivers/usb/typec/ucsi/ucsi.c
+++ b/drivers/usb/typec/ucsi/ucsi.c
@@ -218,9 +218,12 @@ void ucsi_altmode_update_active(struct ucsi_connector *con)
if (cur < UCSI_MAX_ALTMODES)
altmode = typec_altmode_get_partner(con->port_altmode[cur]);
- for (i = 0; con->partner_altmode[i]; i++)
- typec_altmode_update_active(con->partner_altmode[i],
- con->partner_altmode[i] == altmode);
+ for (i = 0; i < UCSI_MAX_ALTMODES; i++) {
+if (con->partner_altmode[i]) {
+ typec_altmode_update_active(con->partner_altmode[i],
+ con->partner_altmode[i] ==
altmode);
+}
+}
}
static u8 ucsi_altmode_next_mode(struct typec_altmode **alt, u16 svid)
Re: [PATCH] Remove obsolete email address for Zwane Mwaikambo
On Wed, 13 Feb 2013, Andrew Morton wrote: > On Wed, 13 Feb 2013 10:55:28 + > Russell King - ARM Linux wrote: > > > Zwane's arm.linux.org.uk email address has not been functional for > > a number of years now. It's time that all references to it were > > removed. I no longer have a forwarding address for Zwane, as I had > > assumed that my repeated requests over a number of years to Zwane to > > avoid use of this address had been actioned. > > > > Zwane has an infradead account (cc'ed) Hi Guys, Sorry for the headache Russell i changed external references but never did get around to sending a patch for the kernel, could you modify the patch to use "zwa...@gmail.com"? Thanks for the forward Paul. Zwane -- 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] retrieve VBE EDID/DDC info independent of used video mode
Hi Daniel, On Tue, 31 Jul 2007, Daniel Drake wrote: > Hi, > > H. Peter Anvin wrote: > > > So, 2.6.22-rc6-mm1 should work fine with CONFIG_FIRMWARE_EDID=y, or are > > > further patches needed? > > > > > > > It should, yes. > > It didn't work, and the bug still exists in 2.6.23-rc1: the resolution is > wrong by 6 pixels. The user does have CONFIG_FIRMWARE_EDID enabled. > > So far the only known working setups since 2.6.20.11 are: > 1. Zwane's patch reverted > 2. Jan's patch applied (to 2.6.22 or lower, I guess it no longer works for > 2.6.23) > > Here is dmesg output from 2.6.23: > http://bugs.gentoo.org/attachment.cgi?id=126203&action=view > > Let me know how we can help diagnose this further. Sorry if this has been hashed out before, but could you point me towards the gentoo bugzilla entry? I'm trying to understand how your setup broke. Which version VBE does your system have? Thanks, Zwane - 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: [5/6] dynamically allocate IRQ stacks (was: Re: [-mm patch] i386: enable 4k stacks by default)
On Mon, 30 Apr 2007, William Lee Irwin III wrote: > -static char softirq_stack[NR_CPUS * THREAD_SIZE] > - __attribute__((__aligned__(THREAD_SIZE))); > +static DEFINE_PER_CPU(char *, softirq_stack); > +static DEFINE_PER_CPU(char *, hardirq_stack); > > -static char hardirq_stack[NR_CPUS * THREAD_SIZE] > - __attribute__((__aligned__(THREAD_SIZE))); > +#ifdef CONFIG_VMALLOC_STACK > +static void * __init __alloc_irqstack(int cpu) How about just using DEFINE_PER_CPU and allowing the percpu code dynamically allocate. - 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: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler
On Sun, 4 Mar 2007, Gene Heskett wrote: > >There will be times when the mainline scheduler feels more interactive > > than this scheduler, and that is because it has significant unfairness > > granted towards interactive tasks. This degree of unfairness in an > > effort to maintain interactivity has been criticised and causes > > problems in certain environments with both loss of fairness, relative > > starvation and is not entirely predictable. > > Well, in 20 minutes of playing, I am so far VERY impressed, the kmail > composer is typing to the screen in unison to my keystrokes, where with > the older version it often went away for 10 or more seconds at a time, > then displayed the last sentence I had typed in one (or 2 sometimes) > swell foop. Now I can back up and correct a typo in real time whereas > before, it was often faster if the typo was half a line back, and the key > repeat so darned slow it was often over a second per character cell > moved, to go grab the mouse, position the cursor on the typo, click, wait > for the indicator to move, and then fix it. Typing is now pleasurable > again. Key repeats seem to remain at the set in the bios key repeat > speed. Amazing. I do believe you have given me back my machine. What are the specs on your hardware? - 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 00/21] 2.6.19-stable review
On Tue, 27 Feb 2007, Eric W. Biederman wrote: > > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch > >> > >> That's mainly an Andi decision. Let's cc him. > > > > Would be good to have Eric also ack them as safe and obvious. > > > > Btw, that latter one has corrupted sign-offs from Andi (it's in the middle > > of the text, very confusing). > > There are two questions. > 1) What can we do to make the situation better. > 2) Is the hole completely plugged. > > When I wrote the patch I had the local apic priorities backwards in my > head. So apic_in_service_vector can return the wrong value if two > irqs are in service. Now I don't think we allows ourselves to enable > interrupts in an interrupt service routing until after we have acked > the local apic so this should be harmless. The fix is also trivial > of just having apic_in_service_vector return: "~get_irq_regs()->orig_rax". > > Except for that one possible problem everything I can think of are > just theoretical cracks at this point, and they don't make the > situation any worse. > > Given that this patch has appears to have undergone a noticeable > amount of testing, by people other than myself, and clears up the > symptoms. I have no problem Hi Eric, Thanks for getting this cruft cleaned up. I have a few comments regarding; handle-irqs-pending-in-irr-during-irq-migration.patch 1) It relies on checking the IRR, this could race with the corresponding vector bit being set by hardware. 2) apic_handle_pending_vector is oddly named since it doesn't actually handle a pending vector but drops it if it has been freed. 3) It looks complex So how about the following scheme. Add a check in do_IRQ whether the irq's domain contains the current cpu, if not we free the vector upon handler completion. Cheers, Zwane - 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]: Change sysenter_setup to __cpuinit & improve __INIT, __INITDATA
On Mon, 19 Feb 2007, Prarit Bhargava wrote: > /* For assembly routines */ > +#ifdef CONFIG_HOTPLUG_CPU > +#define __INIT .section".text","ax" > +#define __INITDATA .section".data","aw" > +#else > #define __INIT .section".init.text","ax" > -#define __FINIT .previous > #define __INITDATA .section".init.data","aw" > +#endif > +#define __FINIT .previous > > #ifndef __ASSEMBLY__ Shouldn't this be __CPUINT/__CPUINITDATA? That way you could also get rid of things like in x86_64 head.S; #ifndef CONFIG_HOTPLUG_CPU __INITDATA #endif - 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: "compat_agp_ioctl" [drivers/char/agp/agpgart.ko] undefined!
On Mon, 19 Feb 2007, Olaf Hering wrote: > > 2.6.20-git14 > > cp arch/powerpc/configs/g5_defconfig ../O-linus/.config > time env LC_ALL=C make -k O=../O-linus > ... > Building modules, stage 2. > MODPOST 127 modules > WARNING: "compat_agp_ioctl" [drivers/char/agp/agpgart.ko] undefined! > make[2]: *** [__modpost] Error 1 Fixed in Andrew's tree; Index: drivers/char/agp/Makefile === RCS file: /home/cvsroot/linux-2.6.20-rc3/drivers/char/agp/Makefile,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 Makefile --- drivers/char/agp/Makefile 8 Jan 2007 06:36:24 - 1.1.1.1 +++ drivers/char/agp/Makefile 16 Feb 2007 06:29:10 - @@ -1,5 +1,7 @@ agpgart-y := backend.o frontend.o generic.o isoch.o +agpgart-$(CONFIG_COMPAT) += compat_ioctl.o + obj-$(CONFIG_AGP) += agpgart.o obj-$(CONFIG_AGP_ALI) += ali-agp.o obj-$(CONFIG_AGP_ATI) += ati-agp.o - 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] Don't probe for DDC on VBE1.2
On Mon, 19 Feb 2007, Andi Kleen wrote: > > > I tested the x86_64 VBE3 case (similar to Andrew's VAIO), so we just need > > a VBE1.2 on x86_64 test. > > Does this mean you want to have an updated patch or not? Nope, i'm happy with the last patch i sent (below to reconfirm). Thanks Index: linux-2.6.20-mm1/arch/i386/boot/video.S === RCS file: /home/cvsroot/linux-2.6.20-mm1/arch/i386/boot/video.S,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 video.S --- linux-2.6.20-mm1/arch/i386/boot/video.S 15 Feb 2007 17:35:57 - 1.1.1.1 +++ linux-2.6.20-mm1/arch/i386/boot/video.S 17 Feb 2007 08:29:11 - @@ -571,6 +571,16 @@ setr1: lodsw jmp _m_s check_vesa: +#ifdef CONFIG_FIRMWARE_EDID + leawmodelist+1024, %di + movw$0x4f00, %ax + int $0x10 + cmpw$0x004f, %ax + jnz setbad + + movw4(%di), %ax + movw%ax, vbe_version +#endif leawmodelist+1024, %di subb$VIDEO_FIRST_VESA>>8, %bh movw%bx, %cx# Get mode information structure @@ -1945,6 +1955,9 @@ store_edid: rep stosl + cmpw$0x0200, vbe_version# only do EDID on >= VBE2.0 + jl no_edid + pushw %es # save ES xorw%di, %di# Report Capability pushw %di @@ -1987,6 +2000,7 @@ do_restore: .byte 0 # Screen contents al svga_prefix: .byte VIDEO_FIRST_BIOS>>8 # Default prefix for BIOS modes graphic_mode: .byte 0 # Graphic mode with a linear frame buffer dac_size: .byte 6 # DAC bit depth +vbe_version: .word 0 # VBE bios version # Status messages keymsg:.ascii "Press to see video modes available, " Index: linux-2.6.20-mm1/arch/x86_64/boot/video.S === RCS file: /home/cvsroot/linux-2.6.20-mm1/arch/x86_64/boot/video.S,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 video.S --- linux-2.6.20-mm1/arch/x86_64/boot/video.S 15 Feb 2007 17:36:18 - 1.1.1.1 +++ linux-2.6.20-mm1/arch/x86_64/boot/video.S 17 Feb 2007 08:29:11 - @@ -571,6 +571,16 @@ setr1: lodsw jmp _m_s check_vesa: +#ifdef CONFIG_FIRMWARE_EDID + leawmodelist+1024, %di + movw$0x4f00, %ax + int $0x10 + cmpw$0x004f, %ax + jnz setbad + + movw4(%di), %ax + movw%ax, vbe_version +#endif leawmodelist+1024, %di subb$VIDEO_FIRST_VESA>>8, %bh movw%bx, %cx# Get mode information structure @@ -1945,6 +1955,9 @@ store_edid: rep stosl + cmpw$0x0200, vbe_version# only do EDID on >= VBE2.0 + jl no_edid + pushw %es # save ES xorw%di, %di# Report Capability pushw %di @@ -1987,6 +2000,7 @@ do_restore: .byte 0 # Screen contents al svga_prefix: .byte VIDEO_FIRST_BIOS>>8 # Default prefix for BIOS modes graphic_mode: .byte 0 # Graphic mode with a linear frame buffer dac_size: .byte 6 # DAC bit depth +vbe_version: .word 0 # VBE bios version # Status messages keymsg:.ascii "Press to see video modes available, " - 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] Don't probe for DDC on VBE1.2
On Sun, 18 Feb 2007, Andi Kleen wrote: > On Saturday 17 February 2007 09:35, Zwane Mwaikambo wrote: > > On Fri, 16 Feb 2007, Andrew Morton wrote: > > > > > On Fri, 16 Feb 2007 06:39:45 -0800 (PST) Zwane Mwaikambo <[EMAIL > > > PROTECTED]> wrote: > > > > > > > On Thu, 15 Feb 2007, Andrew Morton wrote: > > > > > > > > > It's not an X problem - the screen is black immediately upon loading > > > > > the > > > > > kernel. > > > > > > > > > > But I guess you knew that and you're just after display info: > > > > > http://userweb.kernel.org/~akpm/Xorg.0.log.txt > > > > > > > > Thanks, the X log told me your VBE version. I tried to reproduce it on > > > > my > > > > thinkpad which seems to have a very similar video setup to no avail, > > > > Could > > > > you test the following on the VAIO? If this isn't the case, i suspect > > > > i'm > > > > corrupting your modelist. > > > > > > It's still all black. > > > > Ok it looks like i was corrupting the modelist. The following should take > > care of your VAIO, but i haven't tested the failure case as Tobias is away > > this weekend. > > I merged this version of the patch now. Still needs some x86-64 testing > I guess (any volunteers?), although I don't expect much trouble > because the early boot code is very similar. I tested the x86_64 VBE3 case (similar to Andrew's VAIO), so we just need a VBE1.2 on x86_64 test. Thanks, Zwane - 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] Don't probe for DDC on VBE1.2
On Fri, 16 Feb 2007, Andrew Morton wrote: > On Fri, 16 Feb 2007 06:39:45 -0800 (PST) Zwane Mwaikambo <[EMAIL PROTECTED]> > wrote: > > > On Thu, 15 Feb 2007, Andrew Morton wrote: > > > > > It's not an X problem - the screen is black immediately upon loading the > > > kernel. > > > > > > But I guess you knew that and you're just after display info: > > > http://userweb.kernel.org/~akpm/Xorg.0.log.txt > > > > Thanks, the X log told me your VBE version. I tried to reproduce it on my > > thinkpad which seems to have a very similar video setup to no avail, Could > > you test the following on the VAIO? If this isn't the case, i suspect i'm > > corrupting your modelist. > > It's still all black. Ok it looks like i was corrupting the modelist. The following should take care of your VAIO, but i haven't tested the failure case as Tobias is away this weekend. Index: linux-2.6.20-mm1/arch/i386/boot/video.S === RCS file: /home/cvsroot/linux-2.6.20-mm1/arch/i386/boot/video.S,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 video.S --- linux-2.6.20-mm1/arch/i386/boot/video.S 15 Feb 2007 17:35:57 - 1.1.1.1 +++ linux-2.6.20-mm1/arch/i386/boot/video.S 17 Feb 2007 08:29:11 - @@ -571,6 +571,16 @@ setr1: lodsw jmp _m_s check_vesa: +#ifdef CONFIG_FIRMWARE_EDID + leawmodelist+1024, %di + movw$0x4f00, %ax + int $0x10 + cmpw$0x004f, %ax + jnz setbad + + movw4(%di), %ax + movw%ax, vbe_version +#endif leawmodelist+1024, %di subb$VIDEO_FIRST_VESA>>8, %bh movw%bx, %cx# Get mode information structure @@ -1945,6 +1955,9 @@ store_edid: rep stosl + cmpw$0x0200, vbe_version# only do EDID on >= VBE2.0 + jl no_edid + pushw %es # save ES xorw%di, %di# Report Capability pushw %di @@ -1987,6 +2000,7 @@ do_restore: .byte 0 # Screen contents al svga_prefix: .byte VIDEO_FIRST_BIOS>>8 # Default prefix for BIOS modes graphic_mode: .byte 0 # Graphic mode with a linear frame buffer dac_size: .byte 6 # DAC bit depth +vbe_version: .word 0 # VBE bios version # Status messages keymsg:.ascii "Press to see video modes available, " Index: linux-2.6.20-mm1/arch/x86_64/boot/video.S === RCS file: /home/cvsroot/linux-2.6.20-mm1/arch/x86_64/boot/video.S,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 video.S --- linux-2.6.20-mm1/arch/x86_64/boot/video.S 15 Feb 2007 17:36:18 - 1.1.1.1 +++ linux-2.6.20-mm1/arch/x86_64/boot/video.S 17 Feb 2007 08:29:11 - @@ -571,6 +571,16 @@ setr1: lodsw jmp _m_s check_vesa: +#ifdef CONFIG_FIRMWARE_EDID + leawmodelist+1024, %di + movw$0x4f00, %ax + int $0x10 + cmpw$0x004f, %ax + jnz setbad + + movw4(%di), %ax + movw%ax, vbe_version +#endif leawmodelist+1024, %di subb$VIDEO_FIRST_VESA>>8, %bh movw%bx, %cx# Get mode information structure @@ -1945,6 +1955,9 @@ store_edid: rep stosl + cmpw$0x0200, vbe_version# only do EDID on >= VBE2.0 + jl no_edid + pushw %es # save ES xorw%di, %di# Report Capability pushw %di @@ -1987,6 +2000,7 @@ do_restore: .byte 0 # Screen contents al svga_prefix: .byte VIDEO_FIRST_BIOS>>8 # Default prefix for BIOS modes graphic_mode: .byte 0 # Graphic mode with a linear frame buffer dac_size: .byte 6 # DAC bit depth +vbe_version: .word 0 # VBE bios version # Status messages keymsg:.ascii "Press to see video modes available, " - 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] Don't probe for DDC on VBE1.2
On Thu, 15 Feb 2007, Andrew Morton wrote: > It's not an X problem - the screen is black immediately upon loading the > kernel. > > But I guess you knew that and you're just after display info: > http://userweb.kernel.org/~akpm/Xorg.0.log.txt Thanks, the X log told me your VBE version. I tried to reproduce it on my thinkpad which seems to have a very similar video setup to no avail, Could you test the following on the VAIO? If this isn't the case, i suspect i'm corrupting your modelist. P.s. Thanks for the vga=0x263! Index: linux-2.6.20-mm1/arch/i386/boot/video.S === RCS file: /home/cvsroot/linux-2.6.20-mm1/arch/i386/boot/video.S,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 video.S --- linux-2.6.20-mm1/arch/i386/boot/video.S 15 Feb 2007 17:35:57 - 1.1.1.1 +++ linux-2.6.20-mm1/arch/i386/boot/video.S 16 Feb 2007 12:58:20 - @@ -1945,6 +1945,25 @@ store_edid: rep stosl + pushw %es + pushw %ds + popw%es + leawmodelist+1024, %di + movw$0x02b3, %ax + movw%ax, (%di) + movw$0x9d4a, %ax + movw%ax, 2(%di) # set signature to "vbe2" + + movw$0x4f00, %ax + int $0x10 + popw%es + + cmpw$0x004f, %ax + jne no_edid + + cmpw$0x0200, 4(%di) # only do EDID on >= VBE2.0 + jl no_edid + pushw %es # save ES xorw%di, %di# Report Capability pushw %di Index: linux-2.6.20-mm1/arch/x86_64/boot/video.S === RCS file: /home/cvsroot/linux-2.6.20-mm1/arch/x86_64/boot/video.S,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 video.S --- linux-2.6.20-mm1/arch/x86_64/boot/video.S 15 Feb 2007 17:36:18 - 1.1.1.1 +++ linux-2.6.20-mm1/arch/x86_64/boot/video.S 16 Feb 2007 12:57:57 - @@ -1945,6 +1945,25 @@ store_edid: rep stosl + pushw %es + pushw %ds + popw%es + leawmodelist+1024, %di + movw$0x02b3, %ax + movw%ax, (%di) + movw$0x9d4a, %ax + movw%ax, 2(%di) # set signature to "vbe2" + + movw$0x4f00, %ax + int $0x10 + popw%es + + cmpw$0x004f, %ax + jne no_edid + + cmpw$0x0200, 4(%di) # only do EDID on >= VBE2.0 + jl no_edid + pushw %es # save ES xorw%di, %di# Report Capability pushw %di - 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] Fix modular AGPGART (ia64 allmodconfig)
On Fri, 16 Feb 2007, Kyle McMartin wrote: > On Thu, Feb 15, 2007 at 10:09:57PM -0800, Zwane Mwaikambo wrote: > > +ifeq ($(CONFIG_COMPAT),y) > > +agpgart-y += compat_ioctl.o > > +endif > > + > > eh? > > Couldn't this be? > agpgart-$(CONFIG_COMPAT) += compat_ioctl.o Yep thay works too and does look cleaner - 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] Don't probe for DDC on VBE1.2
On Thu, 15 Feb 2007, Andrew Morton wrote: > On Thu, 15 Feb 2007 21:45:06 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > > > On Thu, 15 Feb 2007 21:35:35 -0800 (PST) Zwane Mwaikambo <[EMAIL > > PROTECTED]> wrote: > > > > > On Thu, 15 Feb 2007, Andrew Morton wrote: > > > > > > > This makes the long-suffering-but-vigorously-defended Vaio come up with > > > > a > > > > black display. Everything's working OK otherwise. Sort of a Black > > > > Screen > > > > of Life. I wouldn't call it an improvement though. > > > > > > Bugger, what does your kernel commandline look like? > > > > Kernel command line: ro root=LABEL=/ rhgb vga=0x263 clock=pit > > Removing the vga=0x263 "fixes" it. > Sorry i missed this earlier, could you also post up an Xorg.0.log (or equivalent for your system). Thanks, Zwane - 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/
[PATCH] Fix modular AGPGART (ia64 allmodconfig)
My previous compat AGP patch broke modular AGPGART. Test built on; i386 CONFIG_AGP=y,m x86_64 CONFIG_AGP=y ia64 CONFIG_AGP=m Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]> Index: linux-2.6.20-mm1-ia64/drivers/char/agp/Makefile === RCS file: /home/cvsroot/linux-2.6.20-mm1/drivers/char/agp/Makefile,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 Makefile --- linux-2.6.20-mm1-ia64/drivers/char/agp/Makefile 15 Feb 2007 17:35:27 - 1.1.1.1 +++ linux-2.6.20-mm1-ia64/drivers/char/agp/Makefile 16 Feb 2007 05:47:27 - @@ -1,7 +1,10 @@ agpgart-y := backend.o frontend.o generic.o isoch.o +ifeq ($(CONFIG_COMPAT),y) +agpgart-y += compat_ioctl.o +endif + obj-$(CONFIG_AGP) += agpgart.o -obj-$(CONFIG_COMPAT) += compat_ioctl.o obj-$(CONFIG_AGP_ALI) += ali-agp.o obj-$(CONFIG_AGP_ATI) += ati-agp.o obj-$(CONFIG_AGP_AMD) += amd-k7-agp.o - 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] Don't probe for DDC on VBE1.2
On Thu, 15 Feb 2007, Andrew Morton wrote: > This makes the long-suffering-but-vigorously-defended Vaio come up with a > black display. Everything's working OK otherwise. Sort of a Black Screen > of Life. I wouldn't call it an improvement though. Bugger, what does your kernel commandline look like? - 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] Don't probe for DDC on VBE1.2
On Thu, 15 Feb 2007, Randy Dunlap wrote: > On Thu, 15 Feb 2007 08:29:49 -0800 (PST) Zwane Mwaikambo wrote: > > > VBE1.2 doesn't support function 15h (DDC) resulting in a 'hang' whilst > > uncompressing kernel with some video cards. Make sure we check VBE version > > before fiddling around with DDC. > > > > http://bugzilla.kernel.org/show_bug.cgi?id=1458 > > > > Opened: 2003-10-30 09:12 Last update: 2007-02-13 22:03 > > > > :( > > true. > > Just one question: why use 'je' instead of 'jle' (jge ?) : check for > current version <= 0x0102, whatever that is in gas; I'm still used > to intel syntax. Good point; Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]> Index: linux-2.6.20-mm1/arch/i386/boot/video.S === RCS file: /home/cvsroot/linux-2.6.20-mm1/arch/i386/boot/video.S,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 video.S --- linux-2.6.20-mm1/arch/i386/boot/video.S 15 Feb 2007 17:35:57 - 1.1.1.1 +++ linux-2.6.20-mm1/arch/i386/boot/video.S 15 Feb 2007 22:28:34 - @@ -1945,6 +1945,20 @@ store_edid: rep stosl + pushw %es + pushw %ds + popw%es + leawmodelist+1024, %di + movw$0x4f00, %ax + int $0x10 + popw%es + + cmpw$0x004f, %ax + jne no_edid + + cmpw$0x0102, 4(%di) # only do EDID on > 1.2 + jle no_edid + pushw %es # save ES xorw%di, %di# Report Capability pushw %di Index: linux-2.6.20-mm1/arch/x86_64/boot/video.S === RCS file: /home/cvsroot/linux-2.6.20-mm1/arch/x86_64/boot/video.S,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 video.S --- linux-2.6.20-mm1/arch/x86_64/boot/video.S 15 Feb 2007 17:36:18 - 1.1.1.1 +++ linux-2.6.20-mm1/arch/x86_64/boot/video.S 15 Feb 2007 22:29:00 - @@ -1945,6 +1945,20 @@ store_edid: rep stosl + pushw %es + pushw %ds + popw%es + leawmodelist+1024, %di + movw$0x4f00, %ax + int $0x10 + popw%es + + cmpw$0x004f, %ax + jne no_edid + + cmpw$0x0102, 4(%di) # only do EDID on > 1.2 + jle no_edid + pushw %es # save ES xorw%di, %di# Report Capability pushw %di - 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/
[PATCH] Don't probe for DDC on VBE1.2
VBE1.2 doesn't support function 15h (DDC) resulting in a 'hang' whilst uncompressing kernel with some video cards. Make sure we check VBE version before fiddling around with DDC. http://bugzilla.kernel.org/show_bug.cgi?id=1458 Opened: 2003-10-30 09:12 Last update: 2007-02-13 22:03 :( Much thanks to Tobias Hain for help in testing and investigating the bug. Tested on; i386, Chips & Technologies 65548 VESA VBE 1.2 CONFIG_VIDEO_SELECT=Y CONFIG_FIRMWARE_EDID=Y Untested on x86_64. Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]> Index: linux-2.6.20-rc6-mm1/arch/i386/boot/video.S === RCS file: /home/cvsroot/linux-2.6.20-rc6-mm1/arch/i386/boot/video.S,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 video.S --- linux-2.6.20-rc6-mm1/arch/i386/boot/video.S 30 Jan 2007 05:28:31 - 1.1.1.1 +++ linux-2.6.20-rc6-mm1/arch/i386/boot/video.S 15 Feb 2007 16:27:32 - @@ -1945,6 +1945,20 @@ store_edid: rep stosl + pushw %es + pushw %ds + popw%es + leawmodelist+1024, %di + movw$0x4f00, %ax + int $0x10 + popw%es + + cmpw$0x004f, %ax + jne no_edid + + cmpw$0x0102, 4(%di) # only do EDID on > 1.2 + je no_edid + pushw %es # save ES xorw%di, %di# Report Capability pushw %di Index: linux-2.6.20-rc6-mm1/arch/x86_64/boot/video.S === RCS file: /home/cvsroot/linux-2.6.20-rc6-mm1/arch/x86_64/boot/video.S,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 video.S --- linux-2.6.20-rc6-mm1/arch/x86_64/boot/video.S 30 Jan 2007 05:28:36 - 1.1.1.1 +++ linux-2.6.20-rc6-mm1/arch/x86_64/boot/video.S 15 Feb 2007 16:27:32 - @@ -1945,6 +1945,20 @@ store_edid: rep stosl + pushw %es + pushw %ds + popw%es + leawmodelist+1024, %di + movw$0x4f00, %ax + int $0x10 + popw%es + + cmpw$0x004f, %ax + jne no_edid + + cmpw$0x0102, 4(%di) # only do EDID on > 1.2 + je no_edid + pushw %es # save ES xorw%di, %di# Report Capability pushw %di - 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: What are the real ioapic rte programming constraints?
On Sun, 11 Feb 2007, Eric W. Biederman wrote: > > 2.15.2 PCI Express* Legacy INTx Support and Boot Interrupt > > http://download.intel.com/design/chipsets/datashts/30262802.pdf > > Ouch. And this kind of thing isn't exactly uncommon. > > However if we have the irqs also disabled in the i8259 we should > be safe from actually receiving this interrupt (even if it generates > bus traffic), and when we enable the irq since it is level triggered > we should still get an interrupt message. > > It isn't immediately obvious where the i8259 irq enable/disable > happens. So i"m having trouble auditing that bit of code. > > Plus we can get very strange things like the irq number changing > and the sharing rules being different when going through the i8259. > So irqN may be irqM when going through the i8259. > > As long as we aren't using anything on the i8259 including the timer > in ExtINT mode we can disable every interrupt pin and not worry about > interrupts from that source. We do the 8259 mask in setup_IO_APIC_irq. does anyone have access to an E7520/E7320 system for testing? Cheers, Zwane - 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: What are the real ioapic rte programming constraints?
On Sun, 11 Feb 2007, Eric W. Biederman wrote:
> What I am looking at doing is:
>
> mask
> read io_apic
> -- Past this point no more irqs are expected from the io_apic
> -- Now I work to drain any inflight/pending instances of the irq
> send ipi to all irq destinations cpus and wait for it to return
> read lapic
> disable local irqs
> take irq lock
> -- Now no more irqs are expected to arrive
> reprogram vector and destination
> enable local irqs
> unmask
>
> What I need to ensure is that I have a point where I will not receive any
> new messages from an ioapic about a particular irq anymore. Even if
> everything is working perfectly setting the disable bit is not enough
> because there could be an irq message in flight. So I need to give any
> in flight irqs a chance to complete.
>
> With a little luck that logic will cover your 7500 disable race as
> well. If not and there is a reasonable work around we should look at
> that. This is not a speed critical path so we can afford to do a
> little more work.
The 7500 issue isn't actually a race but a disease, if you mask a pending
irq in its RTE, the PCI hub generates an INTx message corresponding to
that irq. This apparently was done to support booting OSes without APIC
support. So the following would occur;
- irqN pending on IOAPIC
- mask
=> INTx message for irqN
Unfortunately it appears the below code would also be affected by this as
well, the appropriate reference is;
2.15.2 PCI Express* Legacy INTx Support and Boot Interrupt
http://download.intel.com/design/chipsets/datashts/30262802.pdf
> static void mask_get_irq(unsigned int irq)
> {
> struct irq_desc *desc = irq_desc + irq;
> int cpu;
>
> spin_lock(&vector_lock);
>
> /*
>* Mask the irq so it will no longer occur
>*/
> desc->chip->mask(irq);
>
> /* If I can run a lower priority vector on another cpu
>* then obviously the irq has completed on that cpu. SMP call
>* function is lower priority then all of the hardware
>* irqs.
>*/
> for_each_cpu_mask(cpu, desc->affinity)
> smp_call_function_single(cpu, affinity_noop, NULL, 0, 1);
>
> /*
>* Ensure irqs have cleared the local cpu
>*/
> lapic_sync();
> local_irq_disable();
> lapic_sync();
> spin_lock(&desc->lock);
> }
-
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: What are the real ioapic rte programming constraints?
On Sat, 10 Feb 2007, Eric W. Biederman wrote: > There are not enough details in the justification to really understand > the issue so I'm asking to see if someone has some more details. > > The description makes the assertion that reprograming the ioapic > when an interrupt is pending is the only safe way to handle this. > Since edge triggered interrupts cannot be pending at the ioapic I know > it is not talking level triggered interrupts. > > However it is not possible to fully reprogram a level triggered > interrupt when the interrupt is pending as the ioapic will not > receive the interrupt acknowledgement. So it turns out I have > broken this change for several kernel releases without people > screaming at me about io_apic problems. > > Currently I am disabling the irq on the ioapic before reprogramming > it so I do not run into issues. Does that solve the concerns that > were patched around by only reprogramming interrupt redirection > table entry in interrupt handlers? Hi Eric, Could you outline in pseudocode where you're issuing the mask? If it's done whilst an irq is pending some (intel 7500 based) chipsets will not actually mask it but treat it as a 'legacy' IRQ and deliver it anyway. Using the masked whilst pending logic avoids all of that. Cheers, Zwane - 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/
[PATCH] Fix MTRR compat ioctl
The MTRR compat code wasn't calling the lowlevel MTRR setup due to a
switch block not handling the compat case.
Before:
(WW) I810(0): Failed to set up write-combining range (0xd000,0x1000)
After:
reg00: base=0x ( 0MB), size=1024MB: write-back, count=1
reg01: base=0x4000 (1024MB), size= 512MB: write-back, count=1
reg02: base=0x5f70 (1527MB), size= 1MB: uncachable, count=1
reg03: base=0x5f80 (1528MB), size= 8MB: uncachable, count=1
reg04: base=0xd000 (3328MB), size= 256MB: write-combining, count=1
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
Index: arch/i386/kernel/cpu/mtrr/if.c
===
RCS file: /home/cvsroot/linux-2.6.20-rc6-mm1/arch/i386/kernel/cpu/mtrr/if.c,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 if.c
--- arch/i386/kernel/cpu/mtrr/if.c 30 Jan 2007 05:28:30 - 1.1.1.1
+++ arch/i386/kernel/cpu/mtrr/if.c 4 Feb 2007 21:36:57 -
@@ -158,8 +158,9 @@ mtrr_ioctl(struct file *file, unsigned i
struct mtrr_sentry sentry;
struct mtrr_gentry gentry;
void __user *arg = (void __user *) __arg;
+ unsigned int compat_cmd = cmd;
- switch (cmd) {
+ switch (compat_cmd) {
case MTRRIOC_ADD_ENTRY:
case MTRRIOC_SET_ENTRY:
case MTRRIOC_DEL_ENTRY:
@@ -177,14 +178,20 @@ mtrr_ioctl(struct file *file, unsigned i
return -EFAULT;
break;
#ifdef CONFIG_COMPAT
- case MTRRIOC32_ADD_ENTRY:
- case MTRRIOC32_SET_ENTRY:
- case MTRRIOC32_DEL_ENTRY:
- case MTRRIOC32_KILL_ENTRY:
- case MTRRIOC32_ADD_PAGE_ENTRY:
- case MTRRIOC32_SET_PAGE_ENTRY:
- case MTRRIOC32_DEL_PAGE_ENTRY:
- case MTRRIOC32_KILL_PAGE_ENTRY: {
+#define MTRR_COMPAT_OP(op, type)\
+ case MTRRIOC32_##op:\
+ cmd = MTRRIOC_##op; \
+ goto compat_get_##type
+
+ MTRR_COMPAT_OP(ADD_ENTRY, sentry);
+ MTRR_COMPAT_OP(SET_ENTRY, sentry);
+ MTRR_COMPAT_OP(DEL_ENTRY, sentry);
+ MTRR_COMPAT_OP(KILL_ENTRY, sentry);
+ MTRR_COMPAT_OP(ADD_PAGE_ENTRY, sentry);
+ MTRR_COMPAT_OP(SET_PAGE_ENTRY, sentry);
+ MTRR_COMPAT_OP(DEL_PAGE_ENTRY, sentry);
+ MTRR_COMPAT_OP(KILL_PAGE_ENTRY, sentry);
+compat_get_sentry: {
struct mtrr_sentry32 __user *s32 = (struct mtrr_sentry32 __user
*)__arg;
err = get_user(sentry.base, &s32->base);
err |= get_user(sentry.size, &s32->size);
@@ -193,8 +200,9 @@ mtrr_ioctl(struct file *file, unsigned i
return err;
break;
}
- case MTRRIOC32_GET_ENTRY:
- case MTRRIOC32_GET_PAGE_ENTRY: {
+ MTRR_COMPAT_OP(GET_ENTRY, gentry);
+ MTRR_COMPAT_OP(GET_PAGE_ENTRY, gentry);
+compat_get_gentry: {
struct mtrr_gentry32 __user *g32 = (struct mtrr_gentry32 __user
*)__arg;
err = get_user(gentry.regnum, &g32->regnum);
err |= get_user(gentry.base, &g32->base);
@@ -204,6 +212,7 @@ mtrr_ioctl(struct file *file, unsigned i
return err;
break;
}
+#undef MTRR_COMPAT_OP
#endif
}
@@ -317,7 +326,7 @@ mtrr_ioctl(struct file *file, unsigned i
if (err)
return err;
- switch(cmd) {
+ switch(compat_cmd) {
case MTRRIOC_GET_ENTRY:
case MTRRIOC_GET_PAGE_ENTRY:
if (copy_to_user(arg, &gentry, sizeof gentry))
-
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] AGPGART compat ioctl
On Tue, 30 Jan 2007, Kyle McMartin wrote: > On Sat, Jan 27, 2007 at 07:28:07PM -0800, Zwane Mwaikambo wrote: > > Hi Dave, > > The following video card requires the agpgart driver ioctl > > interface in order to detect video memory. > > > > Tested with testgart.c on parisc64, seems to work alright. Thanks for > doing this work, Zwane. I've been meaning to do compat_ioctl for > agpgart for months. Kyle, Thanks for testing! Hopefully Dave can just queue it up for me. Cheers, Zwane - 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] AGPGART compat ioctl
Hi Christoph,
Thanks for the input. The following has your recommendations;
drivers/char/agp/Makefile |1
drivers/char/agp/agp.h |2
drivers/char/agp/compat_ioctl.c | 282
drivers/char/agp/compat_ioctl.h | 105 ++
drivers/char/agp/frontend.c | 31 ++--
5 files changed, 407 insertions(+), 14 deletions(-)
Index: linux-2.6.20-rc4-mm1/drivers/char/agp/Makefile
===
RCS file: /home/cvsroot/linux-2.6.20-rc4-mm1/drivers/char/agp/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 Makefile
--- linux-2.6.20-rc4-mm1/drivers/char/agp/Makefile 27 Jan 2007 22:03:38
- 1.1.1.1
+++ linux-2.6.20-rc4-mm1/drivers/char/agp/Makefile 30 Jan 2007 04:42:21
-
@@ -1,6 +1,7 @@
agpgart-y := backend.o frontend.o generic.o isoch.o
obj-$(CONFIG_AGP) += agpgart.o
+obj-$(CONFIG_COMPAT) += compat_ioctl.o
obj-$(CONFIG_AGP_ALI) += ali-agp.o
obj-$(CONFIG_AGP_ATI) += ati-agp.o
obj-$(CONFIG_AGP_AMD) += amd-k7-agp.o
Index: linux-2.6.20-rc4-mm1/drivers/char/agp/agp.h
===
RCS file: /home/cvsroot/linux-2.6.20-rc4-mm1/drivers/char/agp/agp.h,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 agp.h
--- linux-2.6.20-rc4-mm1/drivers/char/agp/agp.h 27 Jan 2007 22:03:38 -
1.1.1.1
+++ linux-2.6.20-rc4-mm1/drivers/char/agp/agp.h 30 Jan 2007 04:05:33 -
@@ -298,6 +298,8 @@ extern struct aper_size_info_16 agp3_gen
extern int agp_off;
extern int agp_try_unsupported_boot;
+long compat_agp_ioctl(struct file *file, unsigned int cmd, unsigned long arg);
+
/* Chipset independant registers (from AGP Spec) */
#define AGP_APBASE 0x10
Index: linux-2.6.20-rc4-mm1/drivers/char/agp/compat_ioctl.c
===
RCS file: linux-2.6.20-rc4-mm1/drivers/char/agp/compat_ioctl.c
diff -N linux-2.6.20-rc4-mm1/drivers/char/agp/compat_ioctl.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ linux-2.6.20-rc4-mm1/drivers/char/agp/compat_ioctl.c30 Jan 2007
05:15:44 -
@@ -0,0 +1,282 @@
+/*
+ * AGPGART driver frontend compatibility ioctls
+ * Copyright (C) 2004 Silicon Graphics, Inc.
+ * Copyright (C) 2002-2003 Dave Jones
+ * Copyright (C) 1999 Jeff Hartmann
+ * Copyright (C) 1999 Precision Insight, Inc.
+ * Copyright (C) 1999 Xi Graphics, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included
+ * in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * JEFF HARTMANN, OR ANY OTHER CONTRIBUTORS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE
+ * OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include "agp.h"
+#include "compat_ioctl.h"
+
+static int compat_agpioc_info_wrap(struct agp_file_private *priv, void __user
*arg)
+{
+ struct agp_info32 userinfo;
+ struct agp_kern_info kerninfo;
+
+ agp_copy_info(agp_bridge, &kerninfo);
+
+ userinfo.version.major = kerninfo.version.major;
+ userinfo.version.minor = kerninfo.version.minor;
+ userinfo.bridge_id = kerninfo.device->vendor |
+ (kerninfo.device->device << 16);
+ userinfo.agp_mode = kerninfo.mode;
+ userinfo.aper_base = (compat_long_t)kerninfo.aper_base;
+ userinfo.aper_size = kerninfo.aper_size;
+ userinfo.pg_total = userinfo.pg_system = kerninfo.max_memory;
+ userinfo.pg_used = kerninfo.current_memory;
+
+ if (copy_to_user(arg, &userinfo, sizeof(userinfo)))
+ return -EFAULT;
+
+ return 0;
+}
+
+static int compat_agpioc_reserve_wrap(struct agp_file_private *priv, void
__user *arg)
+{
+ struct agp_region32 ureserve;
+ struct agp_region kreserve;
+ struct agp_client *client;
+ struct agp_file_private *client_priv;
+
+ DBG("");
+ if (copy_from_user(&ureserve, arg, sizeof(ureserve)))
+ return -EFAULT;
+
+ if ((unsigned) ureserve.seg_count >= ~0U/sizeof(struct agp_segment32))
+ return -EFAU
[PATCH] AGPGART compat ioctl
Hi Dave,
The following video card requires the agpgart driver ioctl
interface in order to detect video memory.
00:02.0 VGA compatible controller: Intel Corporation Mobile
945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
Tested on a Thinkpad Z61t, Xorg.0.log from a 32bit debian Xorg is at;
http://montezuma.homeunix.net/Xorg.0.log
Cheers,
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
drivers/char/agp/frontend.c | 253
include/linux/agpgart.h | 61 ++
2 files changed, 314 insertions(+)
Index: linux-2.6.20-rc4-mm1/include/linux/agpgart.h
===
RCS file: /home/cvsroot/linux-2.6.20-rc4-mm1/include/linux/agpgart.h,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 agpgart.h
--- linux-2.6.20-rc4-mm1/include/linux/agpgart.h27 Jan 2007 22:04:06
- 1.1.1.1
+++ linux-2.6.20-rc4-mm1/include/linux/agpgart.h27 Jan 2007 22:41:23
-
@@ -114,6 +114,67 @@ typedef struct _agp_unbind {
#define AGPGART_MINOR 175
+#ifdef CONFIG_COMPAT
+#include
+
+#define AGPIOC_INFO32 _IOR (AGPIOC_BASE, 0, compat_uptr_t)
+#define AGPIOC_ACQUIRE32_IO (AGPIOC_BASE, 1)
+#define AGPIOC_RELEASE32_IO (AGPIOC_BASE, 2)
+#define AGPIOC_SETUP32 _IOW (AGPIOC_BASE, 3, compat_uptr_t)
+#define AGPIOC_RESERVE32_IOW (AGPIOC_BASE, 4, compat_uptr_t)
+#define AGPIOC_PROTECT32_IOW (AGPIOC_BASE, 5, compat_uptr_t)
+#define AGPIOC_ALLOCATE32 _IOWR(AGPIOC_BASE, 6, compat_uptr_t)
+#define AGPIOC_DEALLOCATE32 _IOW (AGPIOC_BASE, 7, compat_int_t)
+#define AGPIOC_BIND32 _IOW (AGPIOC_BASE, 8, compat_uptr_t)
+#define AGPIOC_UNBIND32 _IOW (AGPIOC_BASE, 9, compat_uptr_t)
+
+struct agp_info32 {
+ struct agp_version version; /* version of the driver*/
+ u32 bridge_id; /* bridge vendor/device */
+ u32 agp_mode; /* mode info of bridge */
+ compat_long_t aper_base;/* base of aperture */
+ compat_size_t aper_size;/* size of aperture */
+ compat_size_t pg_total; /* max pages (swap + system)*/
+ compat_size_t pg_system;/* max pages (system) */
+ compat_size_t pg_used; /* current pages used */
+};
+
+/*
+ * The "prot" down below needs still a "sleep" flag somehow ...
+ */
+struct agp_segment32 {
+ compat_off_t pg_start; /* starting page to populate*/
+ compat_size_t pg_count; /* number of pages */
+ compat_int_t prot; /* prot flags for mmap */
+};
+
+struct agp_region32 {
+ compat_pid_t pid; /* pid of process */
+ compat_size_t seg_count;/* number of segments */
+ struct agp_segment32 *seg_list;
+};
+
+struct agp_allocate32 {
+ compat_int_t key; /* tag of allocation*/
+ compat_size_t pg_count; /* number of pages */
+ u32 type; /* 0 == normal, other devspec */
+ u32 physical; /* device specific (some devices
+* need a phys address of the
+* actual page behind the gatt
+* table)*/
+};
+
+struct agp_bind32 {
+ compat_int_t key; /* tag of allocation*/
+ compat_off_t pg_start; /* starting page to populate*/
+};
+
+struct agp_unbind32 {
+ compat_int_t key; /* tag of allocation*/
+ u32 priority; /* priority for paging out */
+};
+#endif /* CONFIG_COMPAT */
+
struct agp_info {
struct agp_version version; /* version of the driver*/
u32 bridge_id; /* bridge vendor/device */
Index: linux-2.6.20-rc4-mm1/drivers/char/agp/frontend.c
===
RCS file: /home/cvsroot/linux-2.6.20-rc4-mm1/drivers/char/agp/frontend.c,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 frontend.c
--- linux-2.6.20-rc4-mm1/drivers/char/agp/frontend.c27 Jan 2007 22:03:38
- 1.1.1.1
+++ linux-2.6.20-rc4-mm1/drivers/char/agp/frontend.c27 Jan 2007 22:41:44
-
@@ -1039,6 +1039,256 @@ ioctl_out:
return ret_val;
}
+#ifdef CONFIG_COMPAT
+static int compat_agpioc_info_wrap(struct agp_file_private *priv, void __user
*arg)
+{
+ struct agp_info32 userinfo;
+ struct agp_kern_info kerninfo;
+
+ agp_copy_info(agp_bridge, &kerninfo);
+
+ userinfo.version.major = kerninfo.version.major;
+ userinfo.version.minor = kerninfo.version.minor;
+ userinfo.bridge_id = kerninfo.device->vendor |
+ (kerninfo.device->device << 16);
+ userinfo.agp_mode = kerninfo.mode;
+
Re: [patch 13/14] x86_64: Use common functions in cluster and physflat mode
On Fri, 10 Sep 2005, Andi Kleen wrote: > On Fri, Sep 09, 2005 at 10:07:28AM -0700, Zwane Mwaikambo wrote: > > On Tue, 6 Sep 2005, Ashok Raj wrote: > > > > > On Tue, Sep 06, 2005 at 01:16:28AM +0200, Andi Kleen wrote: > > > > On Sat, Sep 03, 2005 at 02:33:30PM -0700, [EMAIL PROTECTED] wrote: > > > > > > > > > > From: Ashok Raj <[EMAIL PROTECTED]> > > > > > > > > > > Newly introduced physflat_* shares way too much with cluster with > > > > > only a very > > > > > differences. So we introduce some common functions in that can be > > > > > reused in > > > > > both cases. > > > > On a slightly different topic, how come we're using physflat for hotplug > > cpu? > > The original idea was to always use physflat mode for hotplug because > that does all the sequencing stuff and avoids the shortcut races. > But then Ashok decided it was better to add more ifdefs to flat mode > instead and I gave up protesting at some point. Ok so you wanted to segragate them, i can understand that, but didn't we have a version which worked around the races by doing the same thing, hotplug or not? Is this the one where you weren't pleased with the supposed execution penalty? Thanks, Zwane - 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 13/14] x86_64: Use common functions in cluster and physflat mode
On Tue, 6 Sep 2005, Ashok Raj wrote: > On Tue, Sep 06, 2005 at 01:16:28AM +0200, Andi Kleen wrote: > > On Sat, Sep 03, 2005 at 02:33:30PM -0700, [EMAIL PROTECTED] wrote: > > > > > > From: Ashok Raj <[EMAIL PROTECTED]> > > > > > > Newly introduced physflat_* shares way too much with cluster with only a > > > very > > > differences. So we introduce some common functions in that can be reused > > > in > > > both cases. On a slightly different topic, how come we're using physflat for hotplug cpu? -#ifndef CONFIG_CPU_HOTPLUG /* In the CPU hotplug case we cannot use broadcast mode because that opens a race when a CPU is removed. - Stay at physflat mode in this case. - It is bad to do this unconditionally though. Once - we have ACPI platform support for CPU hotplug - we should detect hotplug capablity from ACPI tables and - only do this when really needed. -AK */ + Stay at physflat mode in this case. - AK */ +#ifdef CONFIG_HOTPLUG_CPU if (num_cpus <= 8) genapic = &apic_flat; Thanks, Zwane - 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] fix i386 interrupt re-enabling in die() (attempt 2)
Hello Jan, On Fri, 9 Sep 2005, Jan Beulich wrote: > - spin_lock_irq(&die.lock); > + spin_lock_irqsave(&die.lock, flags); > die.lock_owner = smp_processor_id(); > die.lock_owner_depth = 0; > bust_spinlocks(1); > } > + else > + local_save_flags(flags); Just one tiny nit, that else should be on the same line as the curly brace. Thanks - 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] i386 boottime for_each_cpu broken
On Fri, 9 Sep 2005, Andrew Morton wrote:
> > static void __init MP_processor_info (struct mpc_config_processor *m)
> > {
> > - int ver, apicid;
> > + int ver, apicid, cpu, found_bsp = 0;
> > physid_mask_t tmp;
> >
> > if (!(m->mpc_cpuflag & CPU_ENABLED))
> > @@ -181,6 +181,7 @@ static void __init MP_processor_info (st
> > if (m->mpc_cpuflag & CPU_BOOTPROCESSOR) {
> > Dprintk("Bootup CPU\n");
> > boot_cpu_physical_apicid = m->mpc_apicid;
> > + found_bsp = 1;
> > }
> >
> > if (num_processors >= NR_CPUS) {
> > @@ -204,6 +205,11 @@ static void __init MP_processor_info (st
> > return;
> > }
> >
> > + if (found_bsp)
> > + cpu = 0;
> > + else
> > + cpu = num_processors - 1;
> > + cpu_set(cpu, cpu_possible_map);
>
> Looky here:
>
> akpm: found_bsp=0 cpu=0 tmp=0x0001 num_processors=1
> akpm: found_bsp=0 cpu=1 tmp=0x0002 num_processors=2
> akpm: found_bsp=0 cpu=2 tmp=0x0004 num_processors=3
> akpm: found_bsp=1 cpu=0 tmp=0x0008 num_processors=4
>
> On this machine, the BSP is the last one to pass through
> MP_processor_info(), so the rude-looking assumption above screws things up.
Yes that's a terrible assumption,
> I don't know what that found_bsp code is trying to do. It wasn't
> changelogged and it wasn't commented and removing it makes by box boot again.
>
> What did I break?
Nothing gov =)
> - if (found_bsp)
> - cpu = 0;
> - else
> - cpu = num_processors - 1;
> - cpu_set(cpu, cpu_possible_map);
> - tmp = apicid_to_cpu_present(apicid);
> - physids_or(phys_cpu_present_map, phys_cpu_present_map, tmp);
> -
> + cpu_set(num_processors, cpu_possible_map);
> + num_processors++;
> + phys_cpu = apicid_to_cpu_present(apicid);
> + physids_or(phys_cpu_present_map, phys_cpu_present_map, phys_cpu);
> +
That looks fine to me, my BSP assumption was bad bad bad!
Thanks,
Zwane
-
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: [RFC] Scheduler hooks to support separate ia64 MCA/INIT stacks
On Fri, 9 Sep 2005, Keith Owens wrote: > The new ia64 MCA/INIT handlers[1] (think of them as super NMI) run on > separate stacks. 99% of the changes for these new handlers is ia64 > only code, however they need a couple of scheduler hooks to support > these extra stacks. The complete patch set will be coming through the > ia64 tree, this RFC covers just the scheduler changes, so they do not > come as a surprise when the ia64 tree is rolled up. > > [1] http://marc.theaimsgroup.com/?l=linux-ia64&m=112537827113545&w=2 > and the following patches. Thanks that gave a lot of background. > This patch adds two small hooks that can be safely called from MCA/INIT > context. If other architectures want to support NMI on separate stacks > then they can also use these functions. Well x86_64 already does this with NMI being setup as ISTs, the difference is that there we use a register to access current (via PDA/%gs). I might have missed this in the URL you posted, but how come IA64 can't do this via r13? Thanks, Zwane - 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] fix i386 condition to call nmi_watchdog_tick
On Thu, 8 Sep 2005, Jan Beulich wrote:
> diff -Npru 2.6.13/arch/i386/kernel/traps.c
> 2.6.13-i386-watchdog-active/arch/i386/kernel/traps.c
> --- 2.6.13/arch/i386/kernel/traps.c 2005-08-29 01:41:01.0
> +0200
> +++
> 2.6.13-i386-watchdog-active/arch/i386/kernel/traps.c 2005-09-01
> 14:04:35.0 +0200
> @@ -611,7 +611,7 @@ static void default_do_nmi(struct pt_reg
>* Ok, so this is none of the documented NMI sources,
>* so it must be the NMI watchdog.
>*/
> - if (nmi_watchdog) {
> + if (nmi_watchdog && nmi_active > 0) {
> nmi_watchdog_tick(regs);
> return;
> }
I dislike this patch, and it's not your fault. The reason being is that
there are a few systems (i have one such) which always reports "CPU stuck"
during watchdog setup but then eventually the watchdog starts ticking
during runtime. Unfortunately if this gets in you'll get lots of the
following;
Uhhuh. NMI received for unknown reason 00 on CPU 1.
Dazed and confused, but trying to continue
Do you have a strange power saving mode enabled?
Uhhuh. NMI received for unknown reason 21 on CPU 0.
So, before the patch can go in, the "CPU stuck" systems probably need
looking at. Since i have one, i'll have a look.
Thanks,
Zwane
Ps. why is NMI watchdog perpetually broken?
-
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] move i386's enabling of fxsr and xmmxcpt
On Thu, 8 Sep 2005, Jan Beulich wrote:
> (Note: Patch also attached because the inline version is certain to get
> line wrapped.)
>
> Move some code unrelated to any dealing with hardware bugs from i386's
> bugs.h to a more logical place.
>
> Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
>
> diff -Npru 2.6.13/arch/i386/kernel/traps.c
> 2.6.13-i386-fxsr/arch/i386/kernel/traps.c
> --- 2.6.13/arch/i386/kernel/traps.c 2005-08-29 01:41:01.0
> +0200
> +++ 2.6.13-i386-fxsr/arch/i386/kernel/traps.c 2005-09-07
> 11:46:35.0 +0200
> @@ -1098,6 +1098,24 @@ void __init trap_init(void)
> #endif
> set_trap_gate(19,&simd_coprocessor_error);
>
> + if (cpu_has_fxsr) {
> + /*
> + * Verify that the FXSAVE/FXRSTOR data will be 16-byte
> aligned.
> + */
> + struct fxsrAlignAssert {
> + int _:!(offsetof(struct task_struct,
> thread.i387.fxsave) & 15);
> + };
> +
> + printk(KERN_INFO "Enabling fast FPU save and restore...
> ");
> + set_in_cr4(X86_CR4_OSFXSR);
> + printk("done.\n");
> + }
> + if (cpu_has_xmm) {
> + printk(KERN_INFO "Enabling unmasked SIMD FPU exception
> support... ");
> + set_in_cr4(X86_CR4_OSXMMEXCPT);
> + printk("done.\n");
> + }
> +
> set_system_gate(SYSCALL_VECTOR,&system_call);
Hmm doesn't this really belong in identify_cpu()?
-
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] fix i386 interrupt re-enabling in die()
On Thu, 8 Sep 2005, Jan Beulich wrote:
> diff -Npru 2.6.13/arch/i386/kernel/traps.c
> 2.6.13-i386-die-irq/arch/i386/kernel/traps.c
> --- 2.6.13/arch/i386/kernel/traps.c 2005-08-29 01:41:01.0
> +0200
> +++ 2.6.13-i386-die-irq/arch/i386/kernel/traps.c 2005-09-07
> 11:39:40.0 +0200
> @@ -304,6 +304,7 @@ void die(const char * str, struct pt_reg
> spinlock_t lock;
> u32 lock_owner;
> int lock_owner_depth;
> + unsigned long flags;
> } die = {
> .lock = SPIN_LOCK_UNLOCKED,
> .lock_owner = -1,
> @@ -313,7 +314,7 @@ void die(const char * str, struct pt_reg
>
> if (die.lock_owner != raw_smp_processor_id()) {
> console_verbose();
> - spin_lock_irq(&die.lock);
> + spin_lock_irqsave(&die.lock, die.flags);
This corrupts flags on contention, use a stack variable.
-
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: The BogoMIPS value sometimes too low on Intel Mobile P3
Hello Martin, On Thu, 8 Sep 2005, Martin Vlk wrote: > I am running a custom-built kernel 2.6.10 on an Intel Mobile P3 processor. > (Acer > TravelMate 620) Please try it with a more recent kernel, there have been some patches which take into consideration SMIs occuring during the calibration loop. Thanks, Zwane - 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] re-export genapic on i386
On Thu, 8 Sep 2005, Jan Beulich wrote: > (Note: Patch also attached because the inline version is certain to get > line wrapped.) > > A change not too long ago made i386's genapic symbol no longer be > exported, > and thus certain low-level functions no longer be usable. Since > close-to- > the-hardware code may still be modular, this rectifies the situation. > > Signed-off-by: Jan Beulich <[EMAIL PROTECTED]> Since there are no in-kernel tree users of this, i suggest that you keep it as a seperate patch, and generally for all exports that you may require for your external work. Then when/if your work gets merged you can submit it. Thanks, Zwane - 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: Brand-new notebook useless with Linux...
On Sun, 4 Sep 2005, Willy Tarreau wrote: > On Sat, Sep 03, 2005 at 06:58:00PM -0400, Chuck Ebbert wrote: > > I just bought a new notebook. Here is the output from lspci using the > > latest > > pci.ids file from sourceforge: > > You seem to be surprized by the contents. When I recently changed my > work notebook (dead screen on the previous one), it took me nearly 6 > months to find one which suits my needs (serial, floppy, ...) and to > ensure that everything in it was supported. I've refused several ones > because there was no clear indication that they hosted supported hardware. > So I'm a bit amazed by your reaction, you seem to have bought the first > cheap K8 you saw in a store. Incidentally, Is that a Compaq R4000? - 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: [x86_64] Exception when using powernowd.
On Sat, 3 Sep 2005, Kyuma Ohta wrote: > Thanx David, > > Written by David Ranson <[EMAIL PROTECTED]> >at Sat, 03 Sep 2005 09:33:56 +0100 : > Subject: Re: [x86_64] Exception when using powernowd. > > spam.david.trap> Kyuma Ohta wrote: > spam.david.trap> > spam.david.trap> > spam.david.trap> >>Hi, > spam.david.trap> >> > spam.david.trap> >>I'm using MSI K8T Neo2 (VIA K8T800 chipset) and Athlon64 > 3000+ > spam.david.trap> >>with linux x86_64 2.6.13 kernel and Debian/sid. > spam.david.trap> >> > spam.david.trap> >> > spam.david.trap> > > spam.david.trap> > > spam.david.trap> I'm using a K8T Neo2 FIR with the same processor and > powernow-k8. Up > spam.david.trap> with 2.6.13 since Sunday, no problems noted. Mine is a SuSE > 9.1 based > spam.david.trap> system though. > spam.david.trap> > spam.david.trap> Maybe BIOS related?? > > I thought this problem,too. > > But,I was upgrade BIOS from v3.3 to v9.2,this issue has happened yet. > > # And,I have to put "pnpacpi=off" to kernel boot line to > # use w83627ths sensor (-_-; > > When upgrade X 6.8.2-4 to 6.8.2-5(or after),this issue has often happend. > I'm using nVidia Geforce 5200 as Display adapter,but this issue > has happend bot Debian's driver and nVidia's driver. I saw something very related in one of Bongani's posts on kernel bugzilla; http://bugzilla.kernel.org/show_bug.cgi?id=4851 (scroll to the bottom) Is there a specific kernel version which started this? Thanks, Zwane - 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: looking for help tracing oops
On Fri, 2 Sep 2005, Christopher Friesen wrote: > > I'm debugging a problem. Unfortunately, I have a module loaded that taints > the kernel. > > Now that that's out of the way, if anyone is still willing to help, the oops > is below, along with the disassembly of filp_close(). One thing I don't > understand--the function makes calls to other functions including printk(), > but I don't see those calls listed in the disassembly. I like to use `objdump -d -r` this is mostly handy for modules since the external references aren't resolved yet. - 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.13-mm1
On Fri, 2 Sep 2005, Alexander Nyberg wrote:
> On Thu, Sep 01, 2005 at 03:55:42AM -0700 Andrew Morton wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/
> >
>
> i386-boottime-for_each_cpu-broken.patch
> i386-boottime-for_each_cpu-broken-fix.patch
>
> The SMP version of __alloc_percpu checks the cpu_possible_map
> before allocating memory for a certain cpu. With the above patches
> the BSP cpuid is never set in cpu_possible_map which breaks CONFIG_SMP
> on uniprocessor machines (as soon as someone tries to dereference
> something allocated via __alloc_percpu, which in fact is never allocated
> since the cpu is not set in cpu_possible_map).
Yes indeed, if there is no mptable or madt we would have missed setting
it.
> The below fixes this, I'm not entirely sure about the voyager
> part, should the cpu_possible_map really be CPU_MASK_ALL to begin
> with there, Zwane?
I wanted to avoid breaking it wholesale and since i don't entirely
understand the voyager SMP boot sequence, i opted for the safe method.
cpu_possible_map is fine because it's supposed to cover all possible
processors, upto NR_CPUS.
> Signed-off-by: Alexander Nyberg <[EMAIL PROTECTED]>
Thanks Alex,
Acked-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
> Index: mm/arch/i386/kernel/smpboot.c
> ===
> --- mm.orig/arch/i386/kernel/smpboot.c2005-09-02 15:28:20.0
> +0200
> +++ mm/arch/i386/kernel/smpboot.c 2005-09-02 16:16:46.0 +0200
> @@ -1265,6 +1265,7 @@
> cpu_set(smp_processor_id(), cpu_online_map);
> cpu_set(smp_processor_id(), cpu_callout_map);
> cpu_set(smp_processor_id(), cpu_present_map);
> + cpu_set(smp_processor_id(), cpu_possible_map);
> per_cpu(cpu_state, smp_processor_id()) = CPU_ONLINE;
> }
>
> Index: mm/arch/i386/mach-voyager/voyager_smp.c
> ===
> --- mm.orig/arch/i386/mach-voyager/voyager_smp.c 2005-09-02
> 15:28:20.0 +0200
> +++ mm/arch/i386/mach-voyager/voyager_smp.c 2005-09-02 16:17:29.0
> +0200
> @@ -1910,6 +1910,7 @@
> {
> cpu_set(smp_processor_id(), cpu_online_map);
> cpu_set(smp_processor_id(), cpu_callout_map);
> + cpu_set(smp_processor_id(), cpu_possible_map);
> }
>
> int __devinit
> -
> 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/
>
-
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] Mobil Pentium 4 HT and the NMI
On Thu, 18 Aug 2005, Andrew Morton wrote: > Steven Rostedt <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > I'm resending this since I don't see it in git yet, and I'm wondering if > > there is a problem with this patch. I have a IBM ThinkPad G41 with a > > Mobile Pentium 4 HT. Without this patch, the NMI won't be setup. Is > > there a reason that if the x86_model is greater than 0x3 it will return. > > Since my processor has a 0x4 x86_model, I upped it to that. Otherwise my > > laptop won't be able to use the NMI. > > > > Well I was hoping that someone with knowledge of the low-level Intel model > differences would pipe up, but they all seem to be in hiding. (Wildly > bcc's lots of x86 people). Looks ok to me, they haven't changed the performance counter setup on those processors. Acked-by: Zwane Mwaikambo <[EMAIL PROTECTED]> - 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] i386 !NUMA node_to_cpumask broken in early boot
On Fri, 19 Aug 2005, Andi Kleen wrote:
> > Thanks for the feedback, ugly indeed, i was really trying to avoid adding
> > a new API function or extra cpu_* variables. Ok, here is an
> > early_node_to_cpumask instead.
>
> Thinking about it again it's most likely broken with CPU hotplug anyways
> whatever you're doing. So how does your code handle adding new
> CPUs? If it does can the normal CPU bootup be handled in the
> same way. Then this wouldn't be needed at all.
The code is populating IDTs before APs are online, so for a given set of
processors i would want to install new IDT entries like so;
node_set_intr_gate()
{
cpumask_t mask = node_to_cpumask(node);
for_each_cpu_mask(cpu, mask)
set_intr_gate(per_cpu_ptr(cpu_idt_table, cpu)
}
Which before resulted in only setting the IDT entry for the BSP.
During boot, i prepare all processor IDTs so they are always
ready for processors coming online and should take care of hotplug cpu
too. The only problem with normal bootup is that the node_to_cpumask is
unreliable.
Zwane
-
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] i386 !NUMA node_to_cpumask broken in early boot
On Fri, 19 Aug 2005, Andi Kleen wrote:
> On Thu, Aug 18, 2005 at 08:07:53PM -0600, Zwane Mwaikambo wrote:
> > node_to_cpumask on non NUMA systems is broken if used before all the
> > processors have been brought up as it returns cpu_online_map, as opposed
> > to NUMA i386 systems which does it earlier than AP bringup. So return
> > which processors responded via cpu_present_map and switch to
> > cpu_online_map during normal runtime. This was found whilst testing a
> > patch which does node dependent work before APs have all gone online.
>
> Very ugly and will probably cause code bloat.
>
> If anything define a special early_node_to ... function for this.
Thanks for the feedback, ugly indeed, i was really trying to avoid adding
a new API function or extra cpu_* variables. Ok, here is an
early_node_to_cpumask instead.
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc5-mm1/include/asm-i386/topology.h
===
RCS file: /home/cvsroot/linux-2.6.13-rc5-mm1/include/asm-i386/topology.h,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 topology.h
--- linux-2.6.13-rc5-mm1/include/asm-i386/topology.h7 Aug 2005 21:38:36
- 1.1.1.1
+++ linux-2.6.13-rc5-mm1/include/asm-i386/topology.h19 Aug 2005 02:47:10
-
@@ -92,6 +92,7 @@ extern unsigned long node_end_pfn[];
extern unsigned long node_remap_size[];
#define node_has_online_mem(nid) (node_start_pfn[nid] != node_end_pfn[nid])
+#define early_node_to_cpumask(nid) node_to_cpumask(nid)
#else /* !CONFIG_NUMA */
/*
@@ -99,6 +100,14 @@ extern unsigned long node_remap_size[];
* above macros here.
*/
+static inline cpumask_t early_node_to_cpumask(int nid)
+{
+ if (unlikely(system_state == SYSTEM_BOOTING))
+ return cpu_present_map;
+
+ return cpu_online_map;
+}
+
#include
#endif /* CONFIG_NUMA */
-
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/
[PATCH] i386 !NUMA node_to_cpumask broken in early boot
node_to_cpumask on non NUMA systems is broken if used before all the
processors have been brought up as it returns cpu_online_map, as opposed
to NUMA i386 systems which does it earlier than AP bringup. So return
which processors responded via cpu_present_map and switch to
cpu_online_map during normal runtime. This was found whilst testing a
patch which does node dependent work before APs have all gone online.
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc5-mm1/include/asm-i386/topology.h
===
RCS file: /home/cvsroot/linux-2.6.13-rc5-mm1/include/asm-i386/topology.h,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 topology.h
--- linux-2.6.13-rc5-mm1/include/asm-i386/topology.h7 Aug 2005 21:38:36
- 1.1.1.1
+++ linux-2.6.13-rc5-mm1/include/asm-i386/topology.h19 Aug 2005 01:35:07
-
@@ -99,6 +99,15 @@ extern unsigned long node_remap_size[];
* above macros here.
*/
+#define node_to_cpumask(node) _node_to_cpumask(node)
+static inline cpumask_t _node_to_cpumask(int node)
+{
+ if (unlikely(system_state == SYSTEM_BOOTING))
+ return cpu_present_map;
+
+ return cpu_online_map;
+}
+
#include
#endif /* CONFIG_NUMA */
-
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] i386 No-Idle-Hz aka Dynamic-Ticks 3
On Mon, 15 Aug 2005, Con Kolivas wrote: > > Why not just set it to a fixed frequency, suspend and then on boot resume > > to a fixed frequency and let the timer tick code eventually switch back. > > It's probably worth holding off further discussion on this point till the SMP > scalable version is working well enough and see if/how the problem manifests > there. For suspend it'll manifest in the same way. Zwane - 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.13-rc5-mm1: BUG: rwlock recursion on CPU#0
On Mon, 15 Aug 2005, Harald Welte wrote: > On Sun, Aug 14, 2005 at 08:15:53PM -0600, Zwane Mwaikambo wrote: > > > Is the following patch correct? ip_conntrack_event_cache should never be > > called with ip_conntrack_lock held and ct_add_counters does not need to be > > called with ip_conntrack_lock held. > > No, it's not correct. ct_add_countes has to be called from within > write_lock_bh() on ip_conntrack_lock. > > So if you keep the ct_add_counters() call where it is and only apply the > rest of your patch (i.e. deferring of ip_conntrack_event_cache() call), > then I think your patch would work. > > However, the whole eventcache needs to be audited, it's called from a > number of places. > > As Patrick wrote he's working on a solution, I'm not going to intervene > or replicate his work. As a interim solution I'd suggest disabling > CONFIG_IP_NF_CT_ACCT [which can't be vital anyway, since it was only > added in net-2.6.14 (and thus -mm)]. Thanks for the explanation Harald, i based the ct_add_counters assumption on other callers of it. Thanks, Zwane - 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: [RFC][2.6.12.3] IRQ compression/sharing patch
On Sun, 14 Aug 2005, James Cleverdon wrote: > > > +static int next_irq = 16; > > > > Won't this need a lock for hotplug later? > > That's what I thought originally, but maybe not. We initialize all RTEs > and assign IRQs+vectors fairly early in boot, plus store the results in > arrays. Thereafter the functions just return the preallocated values. > > Hmmm... Since the I/O APIC init comes after the other CPUs are brought > online, and since I don't understand all that the MSI driver is trying > to accomplish, it might be safer to use a spin lock anyway. With respect to vector allocation, the MSI driver locks around assign_irq_vector, it doesn't look like next_irq is used in that path so you shouldn't need a lock if it's only used in single threaded init. This of course would change if IOAPICs were added after boot. - 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.13-rc6 Oops with Software RAID, LVM, JFS, NFS
On Sun, 14 Aug 2005, Robert Love wrote: > On Sun, 2005-08-14 at 20:40 -0600, Zwane Mwaikambo wrote: > > > I'm new here, if the inode isn't being watched, what's to stop d_delete > > from removing the inode before fsnotify_unlink proceeds to use it? > > Nothing. But check out > > http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7a91bf7f5c22c8407a9991cbd9ce5bb87caa6b4a That git web interface looks rather spiffy. > Should solve this problem? Seems to fit the bill perfectly. Thanks, Zwane - 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.13-rc6 Oops with Software RAID, LVM, JFS, NFS
On Sun, 14 Aug 2005, Phil Dier wrote:
> I just got this:
>
> Unable to handle kernel paging request at virtual address eeafefc0
> printing eip:
> c0188487
> *pde = 00681067
> *pte = 2eafe000
> Oops: [#1]
> SMP DEBUG_PAGEALLOC
> Modules linked in:
> CPU:1
> EIP:0060:[]Not tainted VLI
> EFLAGS: 00010296 (2.6.13-rc6)
> EIP is at inotify_inode_queue_event+0x17/0x130
> eax: eeafefc0 ebx: ecx: 0200 edx: eeafee9c
> esi: edi: ef4cbe9c ebp: f66e1eac esp: f66e1e84
> ds: 007b es: 007b ss: 0068
> Process nfsd (pid: 6259, threadinfo=f66e task=f6307b00)
> Stack: eeafee9c c0536a34 ee900f6c f66e1eac c0179949 eeafefc0 23644d80
> ef4cbe9c f66e1ed4 c01713ad eeafee9c 0400
>eeafee9c ee900f6c f0940f6c f6f0adf8 f66e1f00 c020caa1 ef4cbe9c ee900f6c
> Call Trace:
> [] show_stack+0x7f/0xa0
> [] show_registers+0x160/0x1d0
> [] die+0x100/0x180
> [] do_page_fault+0x369/0x6ed
> [] error_code+0x4f/0x54
> [] vfs_unlink+0x17d/0x210
> [] nfsd_unlink+0x161/0x240
> [] nfsd_proc_remove+0x44/0x90
> [] nfsd_dispatch+0xd7/0x200
> [] svc_process+0x533/0x670
> [] nfsd+0x1bd/0x350
> [] kernel_thread_helper+0x5/0x10
> Code: ff ff ff 8b 5d f8 8b 75 fc 89 ec 5d c3 8d b4 26 00 00 00 00 55 89 e5 57
> 56 53 83 ec 1c 8b 45 08 8b 55 08 05 24 01 00 00 89 45 ec <39> 82 24 01 00 00
> 74 5d f0 ff 8a 2c 01 00 00 0f 88 d1 0b 00 00
int vfs_unlink(struct inode *dir, struct dentry *dentry)
{
/* We don't d_delete() NFS sillyrenamed files--they still exist.
*/
if (!error && !(dentry->d_flags & DCACHE_NFSFS_RENAMED)) {
struct inode *inode = dentry->d_inode;
d_delete(dentry);
<==
fsnotify_unlink(dentry, inode, dir);
}
return error;
}
static inline void fsnotify_unlink(struct dentry *dentry, struct inode *inode,
struct inode *dir)
{
inotify_inode_queue_event(inode, IN_DELETE_SELF, 0, NULL); <=
}
void inotify_inode_queue_event(struct inode *inode, u32 mask, u32 cookie,
const char *name)
{
struct inotify_watch *watch, *next;
if (!inotify_inode_watched(inode)) <==
return;
}
static inline int inotify_inode_watched(struct inode *inode)
{
return !list_empty(&inode->inotify_watches); <===
}
I'm new here, if the inode isn't being watched, what's to stop d_delete
from removing the inode before fsnotify_unlink proceeds to use it?
Thanks,
Zwane
-
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.13-rc5-mm1: BUG: rwlock recursion on CPU#0
On Sun, 14 Aug 2005, Rafael J. Wysocki wrote:
> I've got the following BUG on Asus L5D (x86-64) with the 2.6.13-rc5-mm1
> kernel:
>
> BUG: rwlock recursion on CPU#0, nscd/3668, 8817d4a0
>
> Call Trace:{add_preempt_count+105}
> {rwlock_bug+114}
>{_raw_write_lock+62}
> {_write_lock_bh+40}
>{:ip_conntrack:destroy_conntrack+196}
>{:ip_conntrack:__ip_ct_event_cache_init+165}
>{:ip_conntrack:ip_ct_refresh_acct+249}
>{:ip_conntrack:udp_packet+47}
> {:ip_conntrack:ip_conntrack_in+1059}
>{:ip_conntrack:ip_conntrack_local+76}
>{nf_iterate+92} {dst_output+0}
>{nf_hook_slow+142} {dst_output+0}
>{ip_push_pending_frames+895}
> {lock_sock+201}
>{udp_push_pending_frames+574}
> {udp_sendmsg+1703}
>{current_fs_time+78}
> {file_read_actor+60}
>{update_atime+76}
> {do_generic_mapping_read+1194}
>{inet_sendmsg+86}
> {sock_sendmsg+271}
>{add_preempt_count+105}
> {free_hot_cold_page+270}
>{free_hot_page+11}
> {add_preempt_count+105}
>{autoremove_wake_function+0}
> {sockfd_lookup+28}
>{sys_sendto+260} {do_sys_poll+851}
>{__pollwait+0} {system_call+126}
>
> ---
> | preempt count: 0303 ]
> | 3 level deep critical section nesting:
>
> .. [] nf_hook_slow+0x35/0x160
> .[] .. ( <= ip_push_pending_frames+0x37f/0x490)
> .. [] _write_lock_bh+0x20/0x30
> .[] .. ( <= ip_ct_refresh_acct+0xb0/0x160
> [ip_conntrack])
> .. [] _write_lock_bh+0x20/0x30
> .[] .. ( <= destroy_conntrack+0xc4/0x180
> [ip_conntrack])
Is the following patch correct? ip_conntrack_event_cache should never be
called with ip_conntrack_lock held and ct_add_counters does not need to be
called with ip_conntrack_lock held.
Index: linux-2.6.13-rc5-mm1/net/ipv4/netfilter/ip_conntrack_core.c
===
RCS file:
/home/cvsroot/linux-2.6.13-rc5-mm1/net/ipv4/netfilter/ip_conntrack_core.c,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 ip_conntrack_core.c
--- linux-2.6.13-rc5-mm1/net/ipv4/netfilter/ip_conntrack_core.c 7 Aug 2005
21:38:40 - 1.1.1.1
+++ linux-2.6.13-rc5-mm1/net/ipv4/netfilter/ip_conntrack_core.c 15 Aug 2005
02:09:23 -
@@ -1139,15 +1139,20 @@ void ip_ct_refresh_acct(struct ip_conntr
ct->timeout.expires = extra_jiffies;
ct_add_counters(ct, ctinfo, skb);
} else {
+ int do_event_cache = 0;
+
write_lock_bh(&ip_conntrack_lock);
/* Need del_timer for race avoidance (may already be dying). */
if (del_timer(&ct->timeout)) {
ct->timeout.expires = jiffies + extra_jiffies;
add_timer(&ct->timeout);
- ip_conntrack_event_cache(IPCT_REFRESH, skb);
+ do_event_cache = 1;
}
- ct_add_counters(ct, ctinfo, skb);
write_unlock_bh(&ip_conntrack_lock);
+
+ if (do_event_cache)
+ ip_conntrack_event_cache(IPCT_REFRESH, skb);
+ ct_add_counters(ct, ctinfo, skb);
}
}
-
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] i386 No-Idle-Hz aka Dynamic-Ticks 3
On Sun, 14 Aug 2005, Pavel Machek wrote: > > Ok perhaps on the resume side instead. When trying to resume can you try > > booting with 'dyntick=disable'. Note this isn't meant to be a long term fix > > but once we figure out where the problem is we should be able to code > > around > > it. > > Can you reproduce it using plain swsusp? > > We probably need more carefull suspend/resume support on timer with dyntick > enabled. > > With vanilla, timer just ticks on constant rate; no state to save. > With dyntick, however... Why not just set it to a fixed frequency, suspend and then on boot resume to a fixed frequency and let the timer tick code eventually switch back. - 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: [RFC][2.6.12.3] IRQ compression/sharing patch
On Thu, 11 Aug 2005, Protasevich, Natalie wrote: > > I added some of the suggestions brought forward (dynamically > > allocated IDTs, percpu IDT) last night, all that's left is > > MSI, which does work right now, but gets all its vectors > > allocated on the first irq handling domain. I should be done > > soon, time permitting. > > Zwane, please let me know when I can try it on ES7000, even work in > progress if you need it (see above about volunteering :) Certainly and thanks for volunteering, here is what i had booting last night. There are some things which i need to resolve, for example allocations from __alloc_percpu don't seem to be cacheline aligned, let alone 2k (as i'd expect for a 2k allocation). IDTs are now per cpu, but the policy for distributing which cpus service which devices is still on a node basis. You may also need to ramp up NR_IRQS for the ES7000 subarch, what is a good number? Index: linux-2.6.13-rc4-mm1/arch/i386/kernel/apic.c === RCS file: /home/cvsroot/linux-2.6.13-rc4-mm1/arch/i386/kernel/apic.c,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 apic.c --- linux-2.6.13-rc4-mm1/arch/i386/kernel/apic.c6 Aug 2005 18:46:41 - 1.1.1.1 +++ linux-2.6.13-rc4-mm1/arch/i386/kernel/apic.c11 Aug 2005 03:39:33 - @@ -78,15 +78,15 @@ void __init apic_intr_init(void) smp_intr_init(); #endif /* self generated IPI for local APIC timer */ - set_intr_gate(LOCAL_TIMER_VECTOR, apic_timer_interrupt); + boot_set_intr_gate(LOCAL_TIMER_VECTOR, apic_timer_interrupt); /* IPI vectors for APIC spurious and error interrupts */ - set_intr_gate(SPURIOUS_APIC_VECTOR, spurious_interrupt); - set_intr_gate(ERROR_APIC_VECTOR, error_interrupt); + boot_set_intr_gate(SPURIOUS_APIC_VECTOR, spurious_interrupt); + boot_set_intr_gate(ERROR_APIC_VECTOR, error_interrupt); /* thermal monitor LVT interrupt */ #ifdef CONFIG_X86_MCE_P4THERMAL - set_intr_gate(THERMAL_APIC_VECTOR, thermal_interrupt); + boot_set_intr_gate(THERMAL_APIC_VECTOR, thermal_interrupt); #endif } Index: linux-2.6.13-rc4-mm1/arch/i386/kernel/entry.S === RCS file: /home/cvsroot/linux-2.6.13-rc4-mm1/arch/i386/kernel/entry.S,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 entry.S --- linux-2.6.13-rc4-mm1/arch/i386/kernel/entry.S 6 Aug 2005 18:46:41 - 1.1.1.1 +++ linux-2.6.13-rc4-mm1/arch/i386/kernel/entry.S 7 Aug 2005 01:27:16 - @@ -416,27 +416,18 @@ syscall_badsys: FIXUP_ESPFIX_STACK \ 28:popl %eax; -/* - * Build the entry stubs and pointer table with - * some assembler magic. - */ -.data -ENTRY(interrupt) -.text - +/* Build the IRQ entry stubs */ vector=0 -ENTRY(irq_entries_start) + .align IRQ_STUB_SIZE,0x90 +ENTRY(interrupt) .rept NR_IRQS ALIGN -1: pushl $vector-256 + pushl $vector-0x1 jmp common_interrupt -.data - .long 1b -.text + .align IRQ_STUB_SIZE,0x90 vector=vector+1 .endr - ALIGN common_interrupt: SAVE_ALL movl %esp,%eax Index: linux-2.6.13-rc4-mm1/arch/i386/kernel/head.S === RCS file: /home/cvsroot/linux-2.6.13-rc4-mm1/arch/i386/kernel/head.S,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 head.S --- linux-2.6.13-rc4-mm1/arch/i386/kernel/head.S6 Aug 2005 18:46:41 - 1.1.1.1 +++ linux-2.6.13-rc4-mm1/arch/i386/kernel/head.S11 Aug 2005 02:44:06 - @@ -11,6 +11,7 @@ #include #include #include +#include #include #include #include @@ -304,7 +305,7 @@ is386: movl $2,%ecx# set MP call check_x87 lgdt cpu_gdt_descr - lidt idt_descr + lidt cpu_idt_descr # we switch to per cpu IDTs later ljmp $(__KERNEL_CS),$1f 1: movl $(__KERNEL_DS),%eax# reload all the segment registers movl %eax,%ss # after changing gdt. @@ -370,7 +371,7 @@ setup_idt: movw %dx,%ax/* selector = 0x0010 = cs */ movw $0x8E00,%dx/* interrupt gate - dpl=0, present */ - lea idt_table,%edi + lea boot_idt_table,%edi mov $256,%ecx rp_sidt: movl %eax,(%edi) @@ -445,7 +446,7 @@ int_msg: */ .globl boot_gdt_descr -.globl idt_descr +.globl cpu_idt_descr .globl cpu_gdt_descr ALIGN @@ -456,9 +457,10 @@ boot_gdt_descr: .long boot_gdt_table - __PAGE_OFFSET .word 0 # 32-bit align idt_desc.address -idt_descr: +cpu_idt_descr: .word IDT_ENTRIES*8-1 # idt contains 256 entries - .long idt_table + .long boot_idt_table + .fill NR_CPUS-1,8,0 # boot GDT descriptor (later on used by CPU#0): .word 0 # 32 bit align gdt_desc.address
Re: [PATCH] i386 boottime for_each_cpu broken
Hello Bharata, On Thu, 11 Aug 2005, Bharata B Rao wrote: > I don't know the context of your work here, but a couple of > observations. > > Since you populate cpu_possible_map with NR_CPUS, alloc_percpu() > would end up allocating for all NR_CPUS. Wouldn't you have achieved > the same thing by compile time allocation ? Wouldn't this change > lead to NR_CPUS allocations from alloc_percpu() for all users ? The patch has been modified (courtesy Andi Kleen) to do something a bit smarter and only allocate for detected cpus in MADT or MP table. But my prime concern was that for_each_cpu didn't work at all during boot. > Now since you have separated cpu_possible_map from cpu_callout_map, > do we need to reflect cpu_possible_map with the value from > cpu_callout_map after the cpu_callout_map is initialized fully from > smp_prepare_cpus(). This should be taken care of using above. > BTW, I am working on Kiran's dynamic percpu allocator patch and making > it cpu hotplug aware. With that, alloc_percpu would initially allocate > only for the possible cpus and would allocate for other cpus as and when > they come up. Great, that takes care of my concerns regarding processors which aren't enumerated during smp boot. Thanks for the feedback, Zwane - 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: Need help in understanding x86 syscall
On Thu, 11 Aug 2005, Steven Rostedt wrote: > On Thu, 2005-08-11 at 13:46 -0400, linux-os (Dick Johnson) wrote: > > > > > I was talking about the one who had the glibc support to use > > the newer system-call entry (who's name can confuse). > > > > You are looking at code that uses int 0x80. It's an interrupt, > > therefore, in the kernel, once the stack is set up, interrupts > > need to be (re)enabled. > > int is a call to either an interrupt or exception procedure. 0x80 is > setup in Linux to be a trap and not an interrupt vector. So it does > _not_ turn off interrupts. It's actually a vector, that's all you can install in the IDT. Also a trap doesn't advance the instruction pointer, so you resume at the trapping instruction (e.g. vector 14/page fault), 0x80 is an interrupt gate. One of the distinguishing differences is that 0x80 may be entered via int 0x80 from all ring levels. The reason why int 0x80 doesn't disable interrupts is because issuing int 0x80 directly is similar to doing a far call and therefore doesn't have the same effect as a real interrupt being issued. - 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: [RFC][2.6.12.3] IRQ compression/sharing patch
On Wed, 10 Aug 2005, Protasevich, Natalie wrote: > our systems we are just about to use up all 224 interrupts, but not > quiet. > I have to mention that as far as I know Zwane is about to release his > vector sharing mechanism, he had it implemented and working for i386 (I > tested it on ES7000 successfully, by itself and combined with > compression patch too), and was planning implementing it for x86_64. I > am officially volunteering for testing it in its present state, for both > i386 and x86_64 (I can still do this on our systems by removing the IRQ > compression code :), hope this will help Zwane and Andi to release it as > soon as possible. I added some of the suggestions brought forward (dynamically allocated IDTs, percpu IDT) last night, all that's left is MSI, which does work right now, but gets all its vectors allocated on the first irq handling domain. I should be done soon, time permitting. Thanks, Zwane - 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] i386 boottime for_each_cpu broken
On Thu, 11 Aug 2005, Andi Kleen wrote:
> On Wed, Aug 10, 2005 at 10:59:28PM -0600, Zwane Mwaikambo wrote:
> > for_each_cpu walks through all processors in cpu_possible_map, which is
> > defined as cpu_callout_map on i386 and isn't initialised until all
> > processors have been booted. This breaks things which do for_each_cpu
> > iterations early during boot. So, define cpu_possible_map as a bitmap with
> > NR_CPUS bits populated. This was triggered by a patch i'm working on which
> > does alloc_percpu before bringing up secondary processors.
>
> Better is to initialize it in mpparse.c. That is what x86-64 is doing now.
Good idea, here is an updated version, i left Voyager alone as i have no
way of testing it.
arch/i386/kernel/mpparse.c |8 +++-
arch/i386/kernel/smpboot.c |1 +
arch/i386/mach-voyager/voyager_smp.c |1 +
include/asm-i386/smp.h |2 +-
4 files changed, 10 insertions(+), 2 deletions(-)
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc5-mm1/arch/i386/kernel/mpparse.c
===
RCS file: /home/cvsroot/linux-2.6.13-rc5-mm1/arch/i386/kernel/mpparse.c,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 mpparse.c
--- linux-2.6.13-rc5-mm1/arch/i386/kernel/mpparse.c 7 Aug 2005 21:38:03
- 1.1.1.1
+++ linux-2.6.13-rc5-mm1/arch/i386/kernel/mpparse.c 11 Aug 2005 17:37:23
-
@@ -122,7 +122,7 @@ static int MP_valid_apicid(int apicid, i
static void __init MP_processor_info (struct mpc_config_processor *m)
{
- int ver, apicid;
+ int ver, apicid, cpu, found_bsp = 0;
physid_mask_t tmp;
if (!(m->mpc_cpuflag & CPU_ENABLED))
@@ -181,6 +181,7 @@ static void __init MP_processor_info (st
if (m->mpc_cpuflag & CPU_BOOTPROCESSOR) {
Dprintk("Bootup CPU\n");
boot_cpu_physical_apicid = m->mpc_apicid;
+ found_bsp = 1;
}
if (num_processors >= NR_CPUS) {
@@ -204,6 +205,11 @@ static void __init MP_processor_info (st
return;
}
+ if (found_bsp)
+ cpu = 0;
+ else
+ cpu = num_processors - 1;
+ cpu_set(cpu, cpu_possible_map);
tmp = apicid_to_cpu_present(apicid);
physids_or(phys_cpu_present_map, phys_cpu_present_map, tmp);
Index: linux-2.6.13-rc5-mm1/arch/i386/kernel/smpboot.c
===
RCS file: /home/cvsroot/linux-2.6.13-rc5-mm1/arch/i386/kernel/smpboot.c,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 smpboot.c
--- linux-2.6.13-rc5-mm1/arch/i386/kernel/smpboot.c 7 Aug 2005 21:38:03
- 1.1.1.1
+++ linux-2.6.13-rc5-mm1/arch/i386/kernel/smpboot.c 11 Aug 2005 17:07:44
-
@@ -87,6 +87,7 @@ EXPORT_SYMBOL(cpu_online_map);
cpumask_t cpu_callin_map;
cpumask_t cpu_callout_map;
+cpumask_t cpu_possible_map;
EXPORT_SYMBOL(cpu_callout_map);
static cpumask_t smp_commenced_mask;
Index: linux-2.6.13-rc5-mm1/arch/i386/mach-voyager/voyager_smp.c
===
RCS file:
/home/cvsroot/linux-2.6.13-rc5-mm1/arch/i386/mach-voyager/voyager_smp.c,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 voyager_smp.c
--- linux-2.6.13-rc5-mm1/arch/i386/mach-voyager/voyager_smp.c 7 Aug 2005
21:38:04 - 1.1.1.1
+++ linux-2.6.13-rc5-mm1/arch/i386/mach-voyager/voyager_smp.c 11 Aug 2005
17:40:30 -
@@ -241,6 +241,7 @@ static cpumask_t smp_commenced_mask = CP
/* This is for the new dynamic CPU boot code */
cpumask_t cpu_callin_map = CPU_MASK_NONE;
cpumask_t cpu_callout_map = CPU_MASK_NONE;
+cpumask_t cpu_possible_map = CPU_MASK_ALL;
EXPORT_SYMBOL(cpu_callout_map);
/* The per processor IRQ masks (these are usually kept in sync) */
Index: linux-2.6.13-rc5-mm1/include/asm-i386/smp.h
===
RCS file: /home/cvsroot/linux-2.6.13-rc5-mm1/include/asm-i386/smp.h,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 smp.h
--- linux-2.6.13-rc5-mm1/include/asm-i386/smp.h 7 Aug 2005 21:38:37 -
1.1.1.1
+++ linux-2.6.13-rc5-mm1/include/asm-i386/smp.h 11 Aug 2005 04:25:26 -
@@ -59,7 +59,7 @@ extern void cpu_uninit(void);
extern cpumask_t cpu_callout_map;
extern cpumask_t cpu_callin_map;
-#define cpu_possible_map cpu_callout_map
+extern cpumask_t cpu_possible_map;
/* We don't mark CPUs online until __cpu_up(), so we need another measure */
static inline int num_booting_cpus(void)
-
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 8/14] i386 / Add a per cpu gdt accessor
On Wed, 10 Aug 2005, Zachary Amsden wrote: > Thanks for the feedback. I believe the binary compilation is the same. It is > superfluous in the sense that there is not yet a real use for it, but it is > needed for later developement. > > Xen requires page isolation of system data structures that could be used to > override privilege. Since they do not shadow the GDT, they require the GDT to > be write protected. A side effect of that is that the GDT must be moved to an > isolated page. Thus, the accessors to allow transparently moving the GDT for > a paravirtual build. There is deliberately no effect on the standard build. Thanks for the explanation, i wasn't quite sure what you were planning on doing with the gdt table there. > P.S. Sorry I got your mail address wrong earlier. I mistyped it from the > update to the CREDITS patch. Not a problem, i actually had to double check to make sure i didn't spell it incorrectly too ;) - 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 8/14] i386 / Add a per cpu gdt accessor
On Wed, 10 Aug 2005 [EMAIL PROTECTED] wrote: > Add an accessor function for getting the per-CPU gdt. Callee must already > have the CPU. This one seems superfluous to me, does accessing it indirectly generate better code too? > Patch-base: 2.6.13-rc5-mm1 > Patch-keys: i386 desc xen > Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]> > Index: linux-2.6.13/include/asm-i386/desc.h > === > --- linux-2.6.13.orig/include/asm-i386/desc.h 2005-08-09 20:17:21.0 > -0700 > +++ linux-2.6.13/include/asm-i386/desc.h 2005-08-10 20:41:03.0 > -0700 > @@ -39,6 +39,8 @@ > extern struct desc_struct cpu_gdt_table[GDT_ENTRIES]; > DECLARE_PER_CPU(struct desc_struct, cpu_gdt_table[GDT_ENTRIES]); > > +#define get_cpu_gdt_table(_cpu) (per_cpu(cpu_gdt_table, _cpu)) > + > DECLARE_PER_CPU(unsigned char, cpu_16bit_stack[CPU_16BIT_STACK_SIZE]); - 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/
[PATCH] i386 boottime for_each_cpu broken
for_each_cpu walks through all processors in cpu_possible_map, which is defined as cpu_callout_map on i386 and isn't initialised until all processors have been booted. This breaks things which do for_each_cpu iterations early during boot. So, define cpu_possible_map as a bitmap with NR_CPUS bits populated. This was triggered by a patch i'm working on which does alloc_percpu before bringing up secondary processors. arch/i386/kernel/smpboot.c |1 + arch/i386/mach-voyager/voyager_smp.c |1 + include/asm-i386/smp.h |2 +- 3 files changed, 3 insertions(+), 1 deletion(-) Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]> Index: linux-2.6.13-rc5-mm1/arch/i386/kernel/smpboot.c === RCS file: /home/cvsroot/linux-2.6.13-rc5-mm1/arch/i386/kernel/smpboot.c,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 smpboot.c --- linux-2.6.13-rc5-mm1/arch/i386/kernel/smpboot.c 7 Aug 2005 21:38:03 - 1.1.1.1 +++ linux-2.6.13-rc5-mm1/arch/i386/kernel/smpboot.c 11 Aug 2005 04:26:06 - @@ -87,6 +87,7 @@ EXPORT_SYMBOL(cpu_online_map); cpumask_t cpu_callin_map; cpumask_t cpu_callout_map; +cpumask_t cpu_possible_map = CPU_MASK_ALL; EXPORT_SYMBOL(cpu_callout_map); static cpumask_t smp_commenced_mask; Index: linux-2.6.13-rc5-mm1/arch/i386/mach-voyager/voyager_smp.c === RCS file: /home/cvsroot/linux-2.6.13-rc5-mm1/arch/i386/mach-voyager/voyager_smp.c,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 voyager_smp.c --- linux-2.6.13-rc5-mm1/arch/i386/mach-voyager/voyager_smp.c 7 Aug 2005 21:38:04 - 1.1.1.1 +++ linux-2.6.13-rc5-mm1/arch/i386/mach-voyager/voyager_smp.c 11 Aug 2005 04:26:29 - @@ -241,6 +241,7 @@ static cpumask_t smp_commenced_mask = CP /* This is for the new dynamic CPU boot code */ cpumask_t cpu_callin_map = CPU_MASK_NONE; cpumask_t cpu_callout_map = CPU_MASK_NONE; +cpumask_t cpu_possible_map = CPU_MASK_ALL; EXPORT_SYMBOL(cpu_callout_map); /* The per processor IRQ masks (these are usually kept in sync) */ Index: linux-2.6.13-rc5-mm1/include/asm-i386/smp.h === RCS file: /home/cvsroot/linux-2.6.13-rc5-mm1/include/asm-i386/smp.h,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 smp.h --- linux-2.6.13-rc5-mm1/include/asm-i386/smp.h 7 Aug 2005 21:38:37 - 1.1.1.1 +++ linux-2.6.13-rc5-mm1/include/asm-i386/smp.h 11 Aug 2005 04:25:26 - @@ -59,7 +59,7 @@ extern void cpu_uninit(void); extern cpumask_t cpu_callout_map; extern cpumask_t cpu_callin_map; -#define cpu_possible_map cpu_callout_map +extern cpumask_t cpu_possible_map; /* We don't mark CPUs online until __cpu_up(), so we need another measure */ static inline int num_booting_cpus(void) - 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/
[PATCH] Update email addresses for Zwane
Some folks have been emailing me and having trouble due to these stale addresses; Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]> Index: linux-2.6.13-rc5-mm1/CREDITS === RCS file: /home/cvsroot/linux-2.6.13-rc5-mm1/CREDITS,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 CREDITS --- linux-2.6.13-rc5-mm1/CREDITS7 Aug 2005 21:37:45 - 1.1.1.1 +++ linux-2.6.13-rc5-mm1/CREDITS9 Aug 2005 18:54:21 - @@ -2423,8 +2423,7 @@ S: Toronto, Ontario S: Canada N: Zwane Mwaikambo -E: [EMAIL PROTECTED] -W: http://function.linuxpower.ca +E: [EMAIL PROTECTED] D: Various driver hacking D: Lowlevel x86 kernel hacking D: General debugging Index: linux-2.6.13-rc5-mm1/MAINTAINERS === RCS file: /home/cvsroot/linux-2.6.13-rc5-mm1/MAINTAINERS,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 MAINTAINERS --- linux-2.6.13-rc5-mm1/MAINTAINERS7 Aug 2005 21:37:45 - 1.1.1.1 +++ linux-2.6.13-rc5-mm1/MAINTAINERS9 Aug 2005 18:53:53 - @@ -1762,7 +1762,7 @@ S:Maintained OPL3-SA2, SA3, and SAx DRIVER P: Zwane Mwaikambo -M: [EMAIL PROTECTED] +M: [EMAIL PROTECTED] L: linux-sound@vger.kernel.org S: Maintained @@ -2017,7 +2017,7 @@ S:Maintained SC1200 WDT DRIVER P: Zwane Mwaikambo -M: [EMAIL PROTECTED] +M: [EMAIL PROTECTED] S: Maintained SCHEDULER - 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] i386 No-Idle-Hz aka Dynamic-Ticks 3
On Mon, 8 Aug 2005, Tony Lindgren wrote: > As far as I remember enabling AMD stop grant disconnects all cpus. This > means the system won't be able to do any work until the dyntick timer > interrupt wakes up the system. > > > Both requirements (idling all CPUs together vs individually) I think > > will make the patch more complex. Are such systems (which require having > > to > > idle all CPUs together) pretty common that we have to care about?! > > Probably all AMD SMP based systems? Somebody with better knowledge should > verify this. It would be the K7 only. > > But that may be too late on some CPUs. If dyn_tick->skip = 100, all > > CPUs skip 100 ticks. However some CPUs may have timers that need to be > > service much before that. > > Not in the current case, as the system is completely idle until some > interrupt wakes up the system. Of course it would be different if you make > it per-CPU. I once did a weekend version of this with SMP support and for the PIT, i had the last cpu to enter idle turn reprogram the PIT. Unfortunately this means waiting for all processors and isn't as effective as a result. > Well we need to be able to do various things in the idle loop depending on > the length of the estimated sleep. For example, if next_timer_interrupt is > 2 jiffies away, we cannot do much. But if next_timer_interrupt is 2 seconds > away, we can idle pretty much all devices. > > > > But in any case on P4 systems the APIC timer is not the bottleneck as > > > stopping or reprogramming PIT also kills APIC. (This does not happen on P3 > > > systems). So the bottleneck most likely is the length of PIT. > > > > On these systems, do you disabled APIC (dyntick=noapic)? > > Yeah. It only seems to work on P3 systems. Odd, does reprogramming the APIC at that point get it going again? Zwane - 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] CHECK_IRQ_PER_CPU() to avoid dead code in __do_IRQ()
On Mon, 8 Aug 2005, Alexander Nyberg wrote: > > IRQ_PER_CPU is not used by all architectures. > > This patch introduces the macros > > ARCH_HAS_IRQ_PER_CPU and CHECK_IRQ_PER_CPU() to avoid the generation of > > dead code in __do_IRQ(). > > > > ARCH_HAS_IRQ_PER_CPU is defined by architectures using > > IRQ_PER_CPU in their > > include/asm_ARCH/irq.h > > file. > > > > Through grepping the tree I found the following > > architectures currently use IRQ_PER_CPU: > > > > cris, ia64, ppc, ppc64 and parisc. > > > > There are many places where one could replace run-time tests with > #ifdef's but it makes reading more difficult (and in longer terms > maintainence). Have you benchmarked any workload that benefits > from this? I doubt you'd be able to collect convincing benchmark data, but skipping a branch (possibly mispredicted) is worth it IMO. - 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: Lost Ticks on x86_64
On Sun, 7 Aug 2005, Lee Revell wrote: > > It's most likely bad SMM code in the BIOS that blocks the CPU too long > > and is triggered in idle. You can verify that by using idle=poll > > (not recommended for production, just for testing) and see if it goes away. > > > > WTF, since when do *desktops* use SMM? Are you telling me that we have > to worry about these stupid ACPI/SMM hardware bugs on the desktop too? It's a general platform thing and has been around for ages now... Intel's ICH* definitely use it for example and those are on a lot of desktop systems. For example, turning on "Legacy USB support" will generate periodic SMIs. - 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: [RFC][PATCH] i386: Per node IDT
On Mon, 11 Jul 2005, Oleg Nesterov wrote: > Oleg Nesterov wrote: > > > > Probably it makes sense to change it to > > pushl $vector - 0x - 1 > > > > Please note that entry.S:BUILD_INTERRUPT() also does this trick: > pushl $nr-256; > > so it should be changed as well. I was making these changes and noticed that those were for the various SMP interrupts so they are real vectors. These will always remain within the 256 range. Zwane - 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: Power consumption HZ100, HZ250, HZ1000: new numbers
On Sat, 30 Jul 2005, Lee Revell wrote: > So it looks like artsd wastes way more power DMAing a bunch of silent > pages to the sound card than HZ=1000. > > There's nothing the ALSA layer can do about this, it's a KDE bug. > > I think this is a good argument for leaving HZ at 1000 until some of > these userspace bugs are fixed. It's already 'fixed' just set artsd to release the sound device after some idle time. It's in the "Auto-Suspend" seection of the KDE sound system control module. - 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] 2/6 i386 serialize-msr
wrmsr(MSR_IA32_UCODE_REV, 0, 0);
- __asm__ __volatile__ ("cpuid" : : : "ax", "bx", "cx", "dx");
+ /* see 1.07. Apprent chip bug */
+ serialize_cpu();
1.07 in which document? Also, please just spell 'apparent' correctly,
saving 1 byte really just looks lazy.
-
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] Wireless Security Lock driver.
On Sat, 30 Jul 2005, Brian Schau wrote:
> Hi Michael (and others),
>
>
> Thanks for the info. Well, the reason why I didn't inline the patch
> was due to the size of it - in terms of lines. However, here it is:
> +static void wsl_irq_in(struct urb *urb, struct pt_regs *regs)
> +{
> + struct usb_wsl *wsl=urb->context;
> + int id=0, retval;
> + + switch (urb->status) { <==
> + case -ECONNRESET:
There is something wrong with your patch or mailer.
-
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: isa0060/serio0 problems -WAS- Re: Asus MB and 2.6.12 Problems
On Thu, 28 Jul 2005, Andrew Morton wrote: > Michael Krufky <[EMAIL PROTECTED]> wrote: > > > > Sadly, I must report that yes, the problem still intermittently occurs > > in 2.6.13-rc4 :-( I'm the one that tested on the Shuttle FT61 > > Motherboard. Never has a problem in windows and never in 2.6.11 and > > earlier. > > > > I first noticed this problem sometime during 2.6.12-rc series. > > Sigh. I think it would help if you could generate a new report, please. > > We need a super-easy way for people to do bisection searching. ketchup is extremely handy for narrowing it down to a release, you then pray that the bug is in the -mm tree first so that it's easier to check all the patches individually ;) - 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: Variable ticks
On Wed, 27 Jul 2005, Lee Revell wrote: > On Wed, 2005-07-27 at 02:13 -0600, Zwane Mwaikambo wrote: > > > What about audio? If there is a sound server running then you're going > > > to have a constant stream of interrupts and DMA activity from the sound > > > card even if the machine is idle and there aren't any sounds playing. > > > > Doesn't artsd at least close the audio device after some configurable idle > > time? In which case that sounds like a userspace issue. > > Well, as of ALSA 1.0.9 which does software mixing and volume control by > default, all the sound servers are obsolete. So this should be a > non-issue with a modern distro. > > As far as legacy support, AFAIK esd and artsd both grab the sound device > on startup and never release it. I just setup KDE/artsd to release the sound device after 30seconds and it seems to work. - 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: Variable ticks
On Mon, 25 Jul 2005, Lee Revell wrote: > On Mon, 2005-07-25 at 17:19 -0400, Brown, Len wrote: > > >>>Question one, are there other actions to consider? > > >> > > >> > > >> Yes. > > >> Speaking for ACPI C3 state, note that DMA also > > >> wakes up the CPU -- even if there was no device interrupt. > > >> (aka, "the trouble with USB") > > > > > >Trouble? Why would USB do DMA unless there was a device activity? > > > > look here: > > http://www.google.com/search?hl=en&q=usb+selective+suspend > > > > Linux is working on it too, but it is in development. > > What about audio? If there is a sound server running then you're going > to have a constant stream of interrupts and DMA activity from the sound > card even if the machine is idle and there aren't any sounds playing. Doesn't artsd at least close the audio device after some configurable idle time? In which case that sounds like a userspace issue. - 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: PROBLEM: Opaque kernel bug in work with bzip2(?)
On Sat, 23 Jul 2005, [koi8-r] ? ? wrote: > The letter itself is in an attached file. Run memtest, it sounds like you have failing hardware.
Re: fix suspend/resume irq request free for yenta..
On Sat, 23 Jul 2005, Russell King wrote: > On Sat, Jul 23, 2005 at 02:29:24AM +0200, Pavel Machek wrote: > > > Is it necessary to do free_irq for suspend? Shouldn't disable_irq > > > be enough? > > > > Due to recent changes in ACPI, yes, it is neccessary. > > What if some other driver is sharing the IRQ, and requires IRQs to be > enabled for the resume to complete? This certainly is the case on many laptops. - 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] x86_64: print processor number in show_regs
On Fri, 15 Jul 2005, Andi Kleen wrote:
> On Fri, 15 Jul 2005 05:04:57 -0600 (MDT)
> Zwane Mwaikambo <[EMAIL PROTECTED]> wrote:
>
>
> > void show_regs(struct pt_regs *regs)
> > {
> > + printk("CPU %d:", smp_processor_id());
>
> Isn't there a space after the : missing here?
I don't believe so, there is a \n in the first line of
__show_regs
Zwane
-
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] x86_64: print processor number in show_regs
On Fri, 15 Jul 2005, Zwane Mwaikambo wrote:
> Up to date i've been using the GS value to determine the processor number
> in dumps from show_regs, however this can be cumbersome to do if you don't
> have the vmlinux to verify with the address of cpu_pda, how about the
> following? I considered using hard_smp_processor_id for robustness but we
> already dereference current so we're already relying on MSR_GS_BASE being
> sane.
>
> Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
Sorry, i sent off an older patch, here is the correct one;
Index: linux-2.6.13-rc2-mm1/arch/x86_64/kernel/process.c
===
RCS file: /home/cvsroot/linux-2.6.13-rc2-mm1/arch/x86_64/kernel/process.c,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 process.c
--- linux-2.6.13-rc2-mm1/arch/x86_64/kernel/process.c 10 Jul 2005 04:38:46
- 1.1.1.1
+++ linux-2.6.13-rc2-mm1/arch/x86_64/kernel/process.c 15 Jul 2005 11:00:28
-
@@ -311,6 +311,7 @@ void __show_regs(struct pt_regs * regs)
void show_regs(struct pt_regs *regs)
{
+ printk("CPU %d:", smp_processor_id());
__show_regs(regs);
show_trace(®s->rsp);
}
-
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/
[PATCH] x86_64: print processor number in show_regs
Up to date i've been using the GS value to determine the processor number
in dumps from show_regs, however this can be cumbersome to do if you don't
have the vmlinux to verify with the address of cpu_pda, how about the
following? I considered using hard_smp_processor_id for robustness but we
already dereference current so we're already relying on MSR_GS_BASE being
sane.
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc2-mm1/arch/x86_64/kernel/process.c
===
RCS file: /home/cvsroot/linux-2.6.13-rc2-mm1/arch/x86_64/kernel/process.c,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 process.c
--- linux-2.6.13-rc2-mm1/arch/x86_64/kernel/process.c 10 Jul 2005 04:38:46
- 1.1.1.1
+++ linux-2.6.13-rc2-mm1/arch/x86_64/kernel/process.c 15 Jul 2005 10:54:42
-
@@ -272,7 +272,7 @@ void __show_regs(struct pt_regs * regs)
printk("\n");
print_modules();
- printk("Pid: %d, comm: %.20s %s %s\n",
+ printk("CPU: %d Pid: %d, comm: %.20s %s %s\n", smp_processor_id(),
current->pid, current->comm, print_tainted(),
system_utsname.release);
printk("RIP: %04lx:[<%016lx>] ", regs->cs & 0x, regs->rip);
printk_address(regs->rip);
-
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] i386: Selectable Frequency of the Timer Interrupt
On Fri, 15 Jul 2005, Lee Revell wrote: > On Fri, 2005-07-15 at 14:08 +1000, Con Kolivas wrote: > > Audio did show slightly larger max latencies but nothing that would be of > > significance. > > > > On video, maximum latencies are only slightly larger at HZ 250, all the > > desired cpu was achieved, but the average latency and number of missed > > deadlines was significantly higher. > > Because audio timing is driven by the soundcard interrupt while video, > like MIDI, relies heavily on timers. In interbench it's not driven by a soundcard interrupt. - 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: [RFC][PATCH] i386: Per node IDT
Hello Oleg,
On Mon, 11 Jul 2005, Oleg Nesterov wrote:
> Zwane Mwaikambo wrote:
> >
> > --- linux-2.6.13-rc1-mm1/arch/i386/kernel/entry.S 3 Jul 2005 13:20:43
> > - 1.1.1.1
> > +++ linux-2.6.13-rc1-mm1/arch/i386/kernel/entry.S 10 Jul 2005 22:33:37
> > -
> > -
> > +/* Build the IRQ entry stubs */
> > vector=0
> > -ENTRY(irq_entries_start)
> > + .align IRQ_STUB_SIZE,0x90
> > +ENTRY(interrupt)
> > .rept NR_IRQS
> > ALIGN
> > -1: pushl $vector-256
> > + pushl $vector
> > jmp common_interrupt
> >
> > [...snip...]
> >
> > --- linux-2.6.13-rc1-mm1/arch/i386/kernel/irq.c 3 Jul 2005 13:20:43
> > - 1.1.1.1
> > +++ linux-2.6.13-rc1-mm1/arch/i386/kernel/irq.c 4 Jul 2005 21:39:56
> > -
> > @@ -53,8 +53,7 @@ static union irq_ctx *softirq_ctx[NR_CPU
> > */
> > fastcall unsigned int do_IRQ(struct pt_regs *regs)
> > {
> > - /* high bits used in ret_from_ code */
> > - int irq = regs->orig_eax & 0xff;
> > + int irq = regs->orig_eax;
>
> Could you explain this change? I think it breaks do_signal/handle_signal,
> they check orig_eax >= 0 to handle -ERESTARTSYS:
>
> /* Are we from a system call? */
> if (regs->orig_eax >= 0) {
> /* If so, check system call restarting.. */
> switch (regs->eax) {
> case -ERESTART_RESTARTBLOCK:
> case -ERESTARTNOHAND:
The change is so that we can send IRQs higher than 256 to do_IRQ. That
looks like it tries to check if we came in via system_call since we'd save
the system call number as orig_eax. Now that i think about it, doesn't
that path always get taken when we interrupt userspace and have pending
signals on return from interrupt?
-
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: [RFC][PATCH] i386: Per node IDT
On Mon, 11 Jul 2005, Brian Gerst wrote: > Zwane Mwaikambo wrote: > > On Sun, 11 Jul 2005, Andi Kleen wrote: > > > > > > > Why per node? Why not go the whole way and make it per CPU? > > > > > > I would also not define it statically, but allocate it at boot time > > > in node local memory. > > > > > > I went per node so that it would be minimal/zero impact for the no-node > > case, it would also simplify hotplug cpu since once a cpu in a node goes > > down, we still have other participating processors capable of handling its > > devices without having to do too much migration work. I'll definitely > > incorporate the node local allocations however, for some i386 systems we > > might be forced to stick some additional IDTs on node 0 since the IDTR will > > only take 32bit addresses and we could end up with only highmem on some > > nodes. > > Doesn't the IDTR take a virtual address? It has to or else the f00f bug fix > wouldn't work. Yes you're right, i wasn't quite awake when i replied, thanks for correcting that. Zwane - 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: [RFC][PATCH] i386: Per node IDT
Hi Oleg, On Mon, 11 Jul 2005, Oleg Nesterov wrote: > > The change is so that we can send IRQs higher than 256 to do_IRQ. That > > looks like it tries to check if we came in via system_call since we'd save > > the system call number as orig_eax. Now that i think about it, doesn't > > that path always get taken when we interrupt userspace and have pending > > signals on return from interrupt? > > As far as I can see, we always have orig_eax < 0 on interrupt, because > > irq_entries_start: > pushl $vector-256 <- orig_eax > jmp common_interrupt > > and NR_IRQS < 256. So if we have pending signals on return from interrupt, > do_signal() will not corrupt userspace registers when regs->eax == > -ERESTART... > accidentally. > > Probably it makes sense to change it to > pushl $vector - 0x - 1 > > and in do_IRQ() > int irq = regs->orig_eax & 0x > > if you need to send IRQs higher than 256 to do_IRQ. Good catch, thanks i'll change that! Zwane - 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: [RFC][PATCH] i386: Per node IDT
On Mon, 11 Jul 2005, Arjan van de Ven wrote: > On Mon, 2005-07-11 at 03:59 +0200, Andi Kleen wrote: > > Why per node? Why not go the whole way and make it per CPU? > > Agreed, for two reasons even > 1) Per cpu allows for even more devices and cache locality > 2) While few people have a NUMA system, many have an SMP system so you > get a lot more testing. Agreed, the first version was a per cpu one simply so that i could test it on a normal SMP system. Andi seems to be of the same opinion, what do you think of the hotplug cpu case (explained in previous email)? Thanks Arjan, Zwane - 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: [RFC][PATCH] i386: Per node IDT
On Sun, 11 Jul 2005, Andi Kleen wrote: > Why per node? Why not go the whole way and make it per CPU? > > I would also not define it statically, but allocate it at boot time > in node local memory. I went per node so that it would be minimal/zero impact for the no-node case, it would also simplify hotplug cpu since once a cpu in a node goes down, we still have other participating processors capable of handling its devices without having to do too much migration work. I'll definitely incorporate the node local allocations however, for some i386 systems we might be forced to stick some additional IDTs on node 0 since the IDTR will only take 32bit addresses and we could end up with only highmem on some nodes. Thanks for the feedback, Zwane - 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/
[RFC][PATCH] i386: Per node IDT
As most are aware there is a growing need for more devices on i386/x86_64 based platforms and with that, support for interrupt servicing for all these devices. The proliferation of MSI based devices will also drive that requirement higher due to some devices requiring multiple vectors. Natalie and others have worked on ways of alleviating this recently, but i'd like to put the following forward as well, which should be able to work with other methodologies in place. The general idea behind it is to setup an IDT per node to be shared between all processors on that node, with the definition of 'node' currently based on the NUMA topology. This could, of course, be changed in future to some form of interrupt handling domain/node for finer control over the number of participating cpus in a node. The following patch is a functioning proof of concept, tested on 32 processor, 8 node NUMA system with 320 irq lines and i believe Natalie tested it with 576 interrupts. There is basic MSI support (it'll boot) although i haven't added node awareness to it yet. I'd like to collect opinions on general approach. The patch is currently i386 only, but adding x86_64 for example, should be easy. Thanks arch/i386/kernel/cpu/common.c | 31 + arch/i386/kernel/entry.S | 19 --- arch/i386/kernel/head.S| 12 +- arch/i386/kernel/i8259.c |2 arch/i386/kernel/io_apic.c | 112 + arch/i386/kernel/irq.c |3 arch/i386/kernel/smpboot.c |2 arch/i386/kernel/traps.c | 41 +-- arch/i386/mm/fault.c |6 - drivers/pci/msi.c |6 - drivers/pci/msi.h |1 include/asm-i386/cpu.h |3 include/asm-i386/desc.h|5 include/asm-i386/hw_irq.h |2 include/asm-i386/io_apic.h |2 include/asm-i386/mach-default/irq_vectors_limits.h |8 + include/asm-i386/mach-visws/irq_vectors.h |3 include/asm-i386/mach-voyager/irq_vectors.h|3 include/asm-i386/segment.h |2 19 files changed, 176 insertions(+), 87 deletions(-) Index: linux-2.6.13-rc1-mm1/arch/i386/kernel/entry.S === RCS file: /home/cvsroot/linux-2.6.13-rc1-mm1/arch/i386/kernel/entry.S,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 entry.S --- linux-2.6.13-rc1-mm1/arch/i386/kernel/entry.S 3 Jul 2005 13:20:43 - 1.1.1.1 +++ linux-2.6.13-rc1-mm1/arch/i386/kernel/entry.S 10 Jul 2005 22:33:37 - @@ -407,27 +407,18 @@ syscall_badsys: FIXUP_ESPFIX_STACK \ 28:popl %eax; -/* - * Build the entry stubs and pointer table with - * some assembler magic. - */ -.data -ENTRY(interrupt) -.text - +/* Build the IRQ entry stubs */ vector=0 -ENTRY(irq_entries_start) + .align IRQ_STUB_SIZE,0x90 +ENTRY(interrupt) .rept NR_IRQS ALIGN -1: pushl $vector-256 + pushl $vector jmp common_interrupt -.data - .long 1b -.text + .align IRQ_STUB_SIZE,0x90 vector=vector+1 .endr - ALIGN common_interrupt: SAVE_ALL movl %esp,%eax Index: linux-2.6.13-rc1-mm1/arch/i386/kernel/head.S === RCS file: /home/cvsroot/linux-2.6.13-rc1-mm1/arch/i386/kernel/head.S,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 head.S --- linux-2.6.13-rc1-mm1/arch/i386/kernel/head.S3 Jul 2005 13:20:43 - 1.1.1.1 +++ linux-2.6.13-rc1-mm1/arch/i386/kernel/head.S4 Jul 2005 21:39:56 - @@ -11,6 +11,7 @@ #include #include #include +#include #include #include #include @@ -300,7 +301,7 @@ is386: movl $2,%ecx# set MP call check_x87 lgdt cpu_gdt_descr - lidt idt_descr + lidt node_idt_descr # we switch to per node IDTs later ljmp $(__KERNEL_CS),$1f 1: movl $(__KERNEL_DS),%eax# reload all the segment registers movl %eax,%ss # after changing gdt. @@ -366,7 +367,7 @@ setup_idt: movw %dx,%ax/* selector = 0x0010 = cs */ movw $0x8E00,%dx/* interrupt gate - dpl=0, present */ - lea idt_table,%edi + lea node_idt_table,%edi mov $256,%ecx rp_sidt: movl %eax,(%edi) @@ -441,7 +442,7 @@ int_msg: */ .globl boot_gdt_descr -.globl idt_descr +.globl node_idt_descr .globl cpu_gdt_descr ALIGN @@ -452,9 +453,10 @@ boot_gdt_descr: .long boot_gdt_table - __PAGE_OFFSET .word 0 # 32-bit align idt_desc.address -idt_descr: +node_idt_descr: .wo
[PATCH] Remove preempt_disable from powernow-k8
>From reading the code, my understanding is that powernow-k8 uses
preempt_disable to ensure that driver->target doesn't migrate across cpus
whilst it's accessing per processor registers, however set_cpus_allowed
will provide this for us. Additionally, remove schedule() calls from
set_cpus_allowed as set_cpus_allowed ensures that you're executing on the
target processor on return.
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc1-mm1/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
===
RCS file:
/home/cvsroot/linux-2.6.13-rc1-mm1/arch/i386/kernel/cpu/cpufreq/powernow-k8.c,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 powernow-k8.c
--- linux-2.6.13-rc1-mm1/arch/i386/kernel/cpu/cpufreq/powernow-k8.c 3 Jul
2005 13:20:44 - 1.1.1.1
+++ linux-2.6.13-rc1-mm1/arch/i386/kernel/cpu/cpufreq/powernow-k8.c 10 Jul
2005 22:03:51 -
@@ -453,7 +453,6 @@ static int check_supported_cpu(unsigned
oldmask = current->cpus_allowed;
set_cpus_allowed(current, cpumask_of_cpu(cpu));
- schedule();
if (smp_processor_id() != cpu) {
printk(KERN_ERR "limiting to cpu %u failed\n", cpu);
@@ -488,7 +487,6 @@ static int check_supported_cpu(unsigned
out:
set_cpus_allowed(current, oldmask);
- schedule();
return rc;
}
@@ -895,7 +893,6 @@ static int powernowk8_target(struct cpuf
/* only run on specific CPU from here on */
oldmask = current->cpus_allowed;
set_cpus_allowed(current, cpumask_of_cpu(pol->cpu));
- schedule();
if (smp_processor_id() != pol->cpu) {
printk(KERN_ERR "limiting to cpu %u failed\n", pol->cpu);
@@ -959,8 +956,6 @@ static int powernowk8_target(struct cpuf
err_out:
set_cpus_allowed(current, oldmask);
- schedule();
-
return ret;
}
@@ -1017,7 +1012,6 @@ static int __init powernowk8_cpu_init(st
/* only run on specific CPU from here on */
oldmask = current->cpus_allowed;
set_cpus_allowed(current, cpumask_of_cpu(pol->cpu));
- schedule();
if (smp_processor_id() != pol->cpu) {
printk(KERN_ERR "limiting to cpu %u failed\n", pol->cpu);
@@ -1036,7 +1030,6 @@ static int __init powernowk8_cpu_init(st
/* run on any CPU again */
set_cpus_allowed(current, oldmask);
- schedule();
pol->governor = CPUFREQ_DEFAULT_GOVERNOR;
pol->cpus = cpu_core_map[pol->cpu];
@@ -1069,7 +1062,6 @@ static int __init powernowk8_cpu_init(st
err_out:
set_cpus_allowed(current, oldmask);
- schedule();
powernow_k8_cpu_exit_acpi(data);
kfree(data);
@@ -1105,7 +1097,6 @@ static unsigned int powernowk8_get (unsi
set_cpus_allowed(current, oldmask);
return 0;
}
- preempt_disable();
if (query_current_values_with_pending_wait(data))
goto out;
@@ -1113,7 +1104,6 @@ static unsigned int powernowk8_get (unsi
khz = find_khz_freq_from_fid(data->currfid);
out:
- preempt_enable_no_resched();
set_cpus_allowed(current, oldmask);
return khz;
-
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] [19/48] Suspend2 2.1.9.8 for 2.6.12: 510-version-specific-mac.patch
On Wed, 6 Jul 2005, Nigel Cunningham wrote: > I've just noticed that all the subject lines are off by one. Sorry. > Shall I repost with it right this time? Yes the subject lines did look a bit confusing, it may be easier in future to add a short description of the patch instead of relying on the patch name. > Regarding this x86_64 patch, I haven't been able to test x86_64 support > yet (no hardware here), so I'm sure you're right about all the things. > I've really just parroted what swsusp does in its lowlevel code, since > saving and restoring cpu state is one thing we do the same way. > > Will apply changes. Fair enough. Thanks, Zwane - 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] [11/48] Suspend2 2.1.9.8 for 2.6.12: 401-e820-table-support.patch
On Wed, 6 Jul 2005, Nigel Cunningham wrote: > On Wed, 2005-07-06 at 13:35, Zwane Mwaikambo wrote: > > > > Isn't this covered by Shaohua Li's patch? > > I believe so, but Shaohua Li's patch isn't merged in 2.6.12 (is it yet > at all). This is the solution I've been using for... can't remember how > long. > > Thanks for the feedback. That's fine, i just want to make sure i know which parts can be used by your project too. Thanks Nigel, Zwane - 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] [7/48] Suspend2 2.1.9.8 for 2.6.12: 352-disable-pdflush-during-suspend.patch
On Wed, 6 Jul 2005, Nigel Cunningham wrote: > On Wed, 2005-07-06 at 13:34, Zwane Mwaikambo wrote: > > On Wed, 6 Jul 2005, Nigel Cunningham wrote: > > > > > diff -ruNp > > > 353-disable-highmem-tlb-flush-for-copyback.patch-old/mm/highmem.c > > > 353-disable-highmem-tlb-flush-for-copyback.patch-new/mm/highmem.c > > > --- 353-disable-highmem-tlb-flush-for-copyback.patch-old/mm/highmem.c > > > 2005-06-20 11:47:32.0 +1000 > > > +++ 353-disable-highmem-tlb-flush-for-copyback.patch-new/mm/highmem.c > > > 2005-07-04 23:14:20.0 +1000 > > > @@ -26,6 +26,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > #include > > > > > > static mempool_t *page_pool, *isa_page_pool; > > > @@ -95,7 +96,10 @@ static void flush_all_zero_pkmaps(void) > > > > > > set_page_address(page, NULL); > > > } > > > - flush_tlb_kernel_range(PKMAP_ADDR(0), PKMAP_ADDR(LAST_PKMAP)); > > > + if (test_suspend_state(SUSPEND_FREEZE_SMP)) > > > + __flush_tlb(); > > > + else > > > + flush_tlb_kernel_range(PKMAP_ADDR(0), PKMAP_ADDR(LAST_PKMAP)); > > > } > > > > > > static inline unsigned long map_new_virtual(struct page *page) > > > > What state are the other processors in when you hit this path? > > Looping in arch specific code, waiting for an atomic_t to tell them it's > time to restore state and carry on. They're there the whole time CPU0 is > restoring the image and highmem. Oh ok, so they wouldn't have TLB entries for the above. Thanks, Zwane - 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] [24/48] Suspend2 2.1.9.8 for 2.6.12: 601-kernel_power_power-header.patch
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
> diff -ruNp 602-smp.patch-old/kernel/power/suspend2_core/smp.c
> 602-smp.patch-new/kernel/power/suspend2_core/smp.c
> --- 602-smp.patch-old/kernel/power/suspend2_core/smp.c1970-01-01
> 10:00:00.0 +1000
> +++ 602-smp.patch-new/kernel/power/suspend2_core/smp.c2005-07-04
> 23:14:19.0 +1000
> @@ -0,0 +1,12 @@
> +#include
> +
> +void ensure_on_processor_zero(void)
> +{
> + set_cpus_allowed(current, cpumask_of_cpu(0));
> + BUG_ON(smp_processor_id() != 0);
> +}
> +
> +void return_to_all_processors(void)
> +{
> + set_cpus_allowed(current, CPU_MASK_ALL);
> +}
Do we really need to wrap these?
-
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] [19/48] Suspend2 2.1.9.8 for 2.6.12: 510-version-specific-mac.patch
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
> + /*
> + * eflags
> + */
> + asm volatile ("pushfl ; popl (%0)" : "=m"
> (suspend2_saved_context.eflags));
To be future proof you probably want to do pushfq/popq
> +
> + /*
> + * control registers
> + */
> + asm volatile ("movl %%cr0, %0" : "=r" (suspend2_saved_context.cr0));
> + asm volatile ("movl %%cr2, %0" : "=r" (suspend2_saved_context.cr2));
> + asm volatile ("movl %%cr3, %0" : "=r" (suspend2_saved_context.cr3));
> + asm volatile ("movl %%cr4, %0" : "=r" (suspend2_saved_context.cr4));
I guess we don't have to worry about %cr8 for now?
> + * a little clearer, but it needs to be inlined because we won't have a
> + * stack when we get here (so we can't push a return address).
> + */
> +static inline void restore_processor_context(void)
> +{
> + /*
> + * first restore %ds, so we can access our data properly
> + */
> + //asm volatile ("movw %0, %%ds" :: "r" ((u16)__KERNEL_DS));
> +
> + __flush_tlb_global(); /* INLINE? */
> +
> + asm volatile ("movl $24, %eax");
> + asm volatile ("movl %eax, %ds");
Shouldn't that be KERNEL_DS?
> + asm volatile ("pushl %0 ; popfl" :: "m"
> (suspend2_saved_context.eflags));
pushq/popfq?
> + save_and_set_irq_affinity();
> +
> + c_loops_per_jiffy_ref[_smp_processor_id()] =
> current_cpu_data.loops_per_jiffy;
> +#ifndef CONFIG_SMP
> + cpu_khz_ref = cpu_khz;
> + c_loops_per_jiffy_ref[_smp_processor_id()] = loops_per_jiffy;
> +#endif
> +
> + /* We want to run from swsusp_pg_dir, since swsusp_pg_dir is stored in
> constant
> + * place in memory
> + */
> +
> +__asm__( "movl %%ecx,%%cr3\n" ::"c"(__pa(swsusp_pg_dir)));
This looks like it depends on the swsusp_pg_dir being in lower 32bit
address space, shouldn't it be a movq %%rcx?
-
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] [11/48] Suspend2 2.1.9.8 for 2.6.12: 401-e820-table-support.patch
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
> diff -ruNp 402-mtrr-remove-sysdev.patch-old/arch/i386/kernel/cpu/mtrr/main.c
> 402-mtrr-remove-sysdev.patch-new/arch/i386/kernel/cpu/mtrr/main.c
> --- 402-mtrr-remove-sysdev.patch-old/arch/i386/kernel/cpu/mtrr/main.c
> 2005-06-20 11:46:42.0 +1000
> +++ 402-mtrr-remove-sysdev.patch-new/arch/i386/kernel/cpu/mtrr/main.c
> 2005-07-04 23:14:19.0 +1000
> @@ -166,7 +166,6 @@ static void ipi_handler(void *info)
> atomic_dec(&data->count);
> local_irq_restore(flags);
> }
> -
> #endif
>
> /**
> @@ -560,7 +559,7 @@ struct mtrr_value {
>
> static struct mtrr_value * mtrr_state;
>
> -static int mtrr_save(struct sys_device * sysdev, u32 state)
> +int mtrr_save(void)
> {
> int i;
> int size = num_var_ranges * sizeof(struct mtrr_value);
> @@ -580,28 +579,27 @@ static int mtrr_save(struct sys_device *
> return 0;
> }
Isn't this covered by Shaohua Li's patch?
-
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] [7/48] Suspend2 2.1.9.8 for 2.6.12: 352-disable-pdflush-during-suspend.patch
On Wed, 6 Jul 2005, Nigel Cunningham wrote: > diff -ruNp 353-disable-highmem-tlb-flush-for-copyback.patch-old/mm/highmem.c > 353-disable-highmem-tlb-flush-for-copyback.patch-new/mm/highmem.c > --- 353-disable-highmem-tlb-flush-for-copyback.patch-old/mm/highmem.c > 2005-06-20 11:47:32.0 +1000 > +++ 353-disable-highmem-tlb-flush-for-copyback.patch-new/mm/highmem.c > 2005-07-04 23:14:20.0 +1000 > @@ -26,6 +26,7 @@ > #include > #include > #include > +#include > #include > > static mempool_t *page_pool, *isa_page_pool; > @@ -95,7 +96,10 @@ static void flush_all_zero_pkmaps(void) > > set_page_address(page, NULL); > } > - flush_tlb_kernel_range(PKMAP_ADDR(0), PKMAP_ADDR(LAST_PKMAP)); > + if (test_suspend_state(SUSPEND_FREEZE_SMP)) > + __flush_tlb(); > + else > + flush_tlb_kernel_range(PKMAP_ADDR(0), PKMAP_ADDR(LAST_PKMAP)); > } > > static inline unsigned long map_new_virtual(struct page *page) What state are the other processors in when you hit this path? - 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: Two 2.6.13-rc1 kernel crashes
On Mon, 4 Jul 2005, Martin Mokrejs wrote: > Hi, > I use on i686 architecture Gentoo linux with XFS filesystem. > Recently it happened to me 3 time that the machine locked, > although at least once sys-rq+b worked. Here is the log > from remote console. I don't remeber having such problems > with 2.6.12-rc6-git2, which was my previous testing kernel. > The problems appear under heavy load when I compile/install > some packages and maybe it's just a bad coincidence or not, > when I move my usb mouse in fvwm2 environment. The machine > locks. > Any clues? Please Cc: me in replies. Could you send your .config, and also test without CONFIG_4KSTACKS (if enabled)? Thanks, Zwane - 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 5/6]physical CPU hot add
On Tue, 12 Apr 2005, Li Shaohua wrote:
> On Tue, 2005-04-12 at 20:17, Zwane Mwaikambo wrote:
> > On Tue, 12 Apr 2005, Li Shaohua wrote:
> >
> > > #ifdef CONFIG_HOTPLUG_CPU
> > > +int __attribute__ ((weak)) smp_prepare_cpu(int cpu)
> > > +{
> > > + return 0;
> > > +}
> > > +
> >
> > Any way for you to avoid using weak attribute?
> Just want to avoid more 'ifdef' or 'define empty routine for other
> archs' staffs. Someone prefer 'weak' attribute. Either way is ok to me,
> but if you think the former is better, I'd change it.
The define method is fine and preferred.
Thanks!
Zwane
-
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: kernel panic - not syncing: Fatal exception in interupt
On Tue, 12 Apr 2005, [EMAIL PROTECTED] wrote: > The machine crashed again twice today. I have vga=791 so i caugh a bit more > of the crash. i enabled serial redirection in the bios so i'm hoping to > catch the full dump next time. Cool, can you also try Cc'ing [EMAIL PROTECTED] Thanks, Zwane - 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 5/6]physical CPU hot add
On Tue, 12 Apr 2005, Li Shaohua wrote:
> #ifdef CONFIG_HOTPLUG_CPU
> +int __attribute__ ((weak)) smp_prepare_cpu(int cpu)
> +{
> + return 0;
> +}
> +
Any way for you to avoid using weak attribute?
Thanks,
Zwane
-
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/
