Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 12, 2005 at 03:45:43PM -0700, David Schwartz wrote: > This wasn't a copyright case. The court only refused to uphold the > agreement because there was no oppurtunity to review the agreement before > purchase. So it certainly wouldn't apply to a click-through type agreement. http://www.answers.com/topic/first-sale-doctrine cites several cases, and has a very nice writeup on the current status of this issue. In essence, you're claiming that the difference between Davidson & Associates v. Internet Gateway Inc (2004) and other cases such as Softman v. Adobe (2001) and Novell, Inc. v. CPU Distrib., Inc. (2000) is that the presence of a click-through is the determining factor. Of course, it could just as easily be something else (for example, admitting in court agreement with the license). Does this thread have anything to do with the linux kernel at this point? -- Raul - 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: Why system call need to copy the date from the userspace before using it
On Wed, 13 Apr 2005, Tomko wrote: > Hi all, > > I am new to linux , hope someone can help me. > While i am reading the source code of the linux system call , i find > that the system call need to call copy_from_user() to copy the data from > user space to kernel space before using it . Why not use it directly as > the system call has got the address ? Furthermore , how to distinguish > between user space and kernel space ? > > Thx a lot, > > TOM > - The quick and simple answer to this question is: data integrity. The main thing to understand is that, from the perspective of the kernel, any user input provided in the form of system calls must have immutable data. Only if the data is immutable can the kernel code parse it and decide what to do, without getting into really hairy race conditions. And, for that matter, it's much simpler and less error-prone to program code where you don't have to worry about the inputs changing around you all the time. So, you might say, what's wrong with the user code giving the kernel a pointer to a userland buffer? After all, the calling task will be blocked while the system call is being executed on its behalf. The biggest problem is that the buffer can still be modified, while the system call is executing, by another userland thread running in the same virtual memory context. Or, for that matter, by another process that has this chunk of memory shared with the original task. There are innumerable ways for the data to potentially change in the middle of the system call, and the simplest solution ends up being to copy the data to kernelspace before working with it. That way, no userland tasks can change it on you. I'm sure there are other reasons for doing the copy, that someone will be able to chime in with. Other input is always welcome. :-) -Vadim Lobanov - 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: Exploit in 2.6 kernels
On Tue, 12 Apr 2005 22:32:59 BST, John M Collins said: > I wish some kind soul would speak nicely to Nvidia and get them to see > reason on the point but I suspect I'm not the first person to wish that. NVidia is aware, and they're doing the best they can under the circumstances (no, they can't opensource it all, there's other people's intellectual property in there that they licensed...) > (Or is there a sneaky way of patching the modules so they'll work in > another kernel without tainting it?). Patching it so it won't taint is a one-line patch. However, it's so morally bankrupt that I'm not giving any more hints. Much trickier is doing it so the same module will insmod into multiple kernels without screwing the pooch. If you look around in nv-linux.h and nv.c, there's a number of checks of KERNEL_VERSION, and they're all there for a reason. pgphdXvvl4WmV.pgp Description: PGP signature
Re: [patch 164/198] IB/mthca: fill in more device query fields
>> + memset(props, 0, sizeof props); Alexey> sizeof *props ? Indeed -- excellent catch considering the volume of patches that went by today. I've committed this fix to our svn tree so it won't get lost, and I'll send it upstream once the patch backlog cleared a bit. Thanks, Roland - 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 013/198] SELinux: fix bug in Netlink message type detection
From: James Morris <[EMAIL PROTECTED]> This patch fixes a bug in the SELinux Netlink message type detection code, where the wrong constant was being used in a case statement. The incorrect value is not valid for this class of object so it would not have been reached, and fallen through to a default handler for all Netlink messages. Signed-off-by: James Morris <[EMAIL PROTECTED]> Signed-off-by: Stephen Smalley <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- 25-akpm/security/selinux/nlmsgtab.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN security/selinux/nlmsgtab.c~selinux-fix-bug-in-netlink-message-type-detection security/selinux/nlmsgtab.c --- 25/security/selinux/nlmsgtab.c~selinux-fix-bug-in-netlink-message-type-detection 2005-04-12 03:21:06.586135656 -0700 +++ 25-akpm/security/selinux/nlmsgtab.c 2005-04-12 03:21:06.589135200 -0700 @@ -126,7 +126,7 @@ int selinux_nlmsg_lookup(u16 sclass, u16 break; case SECCLASS_NETLINK_FIREWALL_SOCKET: - case NETLINK_IP6_FW: + case SECCLASS_NETLINK_IP6FW_SOCKET: err = nlmsg_perm(nlmsg_type, perm, nlmsg_firewall_perms, sizeof(nlmsg_firewall_perms)); break; _ - 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 1/6]sep initializing rework
Hello,
This is a hotplug CPU patch for i386, done against 2.6.12-rc2-mm3.
Somewhat alternative to the one posted by Li Shaohua, but not really
(and I didn't mean that :). If you look closer, our patches are
different and can complement each other I think. Li did great job on
sep, after-offline cleanup, __devinit etc., and I have some radical
changes in the AP bringup mechanism. I left alone __init to __devinit
part (I was going through it lately, but I think even though I had few
more than Li did, he covered it sufficiently perhaps). I started having
doubts in free_initmem() vs __devinit because look how many of __init's
left! just a few :). I got rid of do_boot_cpu loop in smpboot.c because
the loop
static void __init smp_init(void)
{
unsigned int i;
/* FIXME: This should be done in userspace --RR */
for_each_present_cpu(i) {
if (num_online_cpus() >= max_cpus)
break;
if (!cpu_online(i))
cpu_up(i);
}
...
does it again so why leave it in smpboot.c to boot AP's twice. I also
found that my system fails sooner or later when I try not to synch
runtime booted processor with others, so I changed tsc synchronization
to only sync between booting CPU and the one that boots it. The patch
works for me on Intel 8x generic box, and on ES7000. I was asked to
separate my patch into smaller ones by the theme, but I'm posting the
entire patch for now, because I think it is probably not the final one.
I think (I hope) I will sync up with Li later on.
My idea was that if we find a CPU core in ACPI (enabled or disabled), we
encounter for it in sibling map and create a sysfs node accordingly, and
cpu_possible_map will reflect that. We take processors up/down depending
on physical presence using the existing node. That's the scenario
implemented on ES7000 that reports all possible cores in ACPI marking
absent processors as disabled. Runtime enablement/disablement depends on
sysfs only and the driving agent can be anything (ACPI or user) that
triggers sysfs node for this processor.
Thanks,
--Natalie
-Original Message-
From: Zwane Mwaikambo [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 12, 2005 6:08 AM
To: Li Shaohua
Cc: lkml; ACPI-DEV; Len Brown; Pavel Machek; Andrew Morton; Protasevich,
Natalie; Ryan Harper
Subject: Re: [PATCH 1/6]sep initializing rework
Hello Shaohua,
On Tue, 12 Apr 2005, Li Shaohua wrote:
> These patches (together with 5 patches followed this one) are updated
> suspend/resume SMP patches. The patches fixed some bugs and do clean
> up as suggested. Now they work for both suspend-to-ram and
suspend-to-disk.
> Patches are against 2.6.12-rc2-mm3.
These patches look good and i think we should go ahead with them. I've
also cross checked with physical hotplug cpu patches for ES7xxx from
Natalie (added to Cc) and it does indeed look like a lot of the code
will work for her too, but i'd appreciate it if she also does a double
check.
Obviously this won't work for other upcoming users of hotplug cpu like
Xen (Ryan added to Cc) but i think we can abstract things later on to
cover other special users.
Thanks Shaohua,
Zwane
hotcpu-2.6.11.diff
Description: hotcpu-2.6.11.diff
[patch 193/198] nfsd4: callback create rpc client returns
From: NeilBrown <[EMAIL PROTECTED]>
rpc_create_clnt and friends return errors, not NULL, on failure.
Signed-off-by: J. Bruce Fields <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/fs/nfsd/nfs4callback.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff -puN fs/nfsd/nfs4callback.c~nfsd4-callback-create-rpc-client-returns
fs/nfsd/nfs4callback.c
--- 25/fs/nfsd/nfs4callback.c~nfsd4-callback-create-rpc-client-returns
2005-04-12 03:21:49.376630512 -0700
+++ 25-akpm/fs/nfsd/nfs4callback.c 2005-04-12 03:21:49.379630056 -0700
@@ -405,7 +405,8 @@ nfsd4_probe_callback(struct nfs4_client
timeparms.to_exponential = 1;
/* Create RPC transport */
- if (!(xprt = xprt_create_proto(IPPROTO_TCP, , ))) {
+ xprt = xprt_create_proto(IPPROTO_TCP, , );
+ if (IS_ERR(xprt)) {
dprintk("NFSD: couldn't create callback transport!\n");
goto out_err;
}
@@ -426,7 +427,8 @@ nfsd4_probe_callback(struct nfs4_client
* XXX AUTH_UNIX only - need AUTH_GSS
*/
sprintf(hostname, "%u.%u.%u.%u", NIPQUAD(addr.sin_addr.s_addr));
- if (!(clnt = rpc_create_client(xprt, hostname, program, 1,
RPC_AUTH_UNIX))) {
+ clnt = rpc_create_client(xprt, hostname, program, 1, RPC_AUTH_UNIX);
+ if (IS_ERR(clnt)) {
dprintk("NFSD: couldn't create callback client\n");
goto out_xprt;
}
_
-
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 180/198] IB/mthca: add SYNC_TPT firmware command
From: Michael S. Tsirkin <[EMAIL PROTECTED]>
Add code for SYNC_TPT firmware command, which will be used by FMR
implementation.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/drivers/infiniband/hw/mthca/mthca_cmd.c |5 +
25-akpm/drivers/infiniband/hw/mthca/mthca_cmd.h |1 +
2 files changed, 6 insertions(+)
diff -puN
drivers/infiniband/hw/mthca/mthca_cmd.c~ib-mthca-add-sync_tpt-firmware-command
drivers/infiniband/hw/mthca/mthca_cmd.c
---
25/drivers/infiniband/hw/mthca/mthca_cmd.c~ib-mthca-add-sync_tpt-firmware-command
2005-04-12 03:21:46.273102320 -0700
+++ 25-akpm/drivers/infiniband/hw/mthca/mthca_cmd.c 2005-04-12
03:21:46.279101408 -0700
@@ -1404,6 +1404,11 @@ int mthca_WRITE_MTT(struct mthca_dev *de
return err;
}
+int mthca_SYNC_TPT(struct mthca_dev *dev, u8 *status)
+{
+ return mthca_cmd(dev, 0, 0, 0, CMD_SYNC_TPT, CMD_TIME_CLASS_B, status);
+}
+
int mthca_MAP_EQ(struct mthca_dev *dev, u64 event_mask, int unmap,
int eq_num, u8 *status)
{
diff -puN
drivers/infiniband/hw/mthca/mthca_cmd.h~ib-mthca-add-sync_tpt-firmware-command
drivers/infiniband/hw/mthca/mthca_cmd.h
---
25/drivers/infiniband/hw/mthca/mthca_cmd.h~ib-mthca-add-sync_tpt-firmware-command
2005-04-12 03:21:46.275102016 -0700
+++ 25-akpm/drivers/infiniband/hw/mthca/mthca_cmd.h 2005-04-12
03:21:46.279101408 -0700
@@ -276,6 +276,7 @@ int mthca_HW2SW_MPT(struct mthca_dev *de
int mpt_index, u8 *status);
int mthca_WRITE_MTT(struct mthca_dev *dev, u64 *mtt_entry,
int num_mtt, u8 *status);
+int mthca_SYNC_TPT(struct mthca_dev *dev, u8 *status);
int mthca_MAP_EQ(struct mthca_dev *dev, u64 event_mask, int unmap,
int eq_num, u8 *status);
int mthca_SW2HW_EQ(struct mthca_dev *dev, void *eq_context,
_
-
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 198/198] md: remove a number of misleading calls to MD_BUG
From: NeilBrown <[EMAIL PROTECTED]>
The conditions that cause these calls to MD_BUG are not kernel bugs, just
oddities in what userspace is asking for.
Also convert analyze_sbs to return void, and the value it returned was
always 0.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/drivers/md/md.c | 30 --
1 files changed, 8 insertions(+), 22 deletions(-)
diff -puN drivers/md/md.c~md-remove-a-number-of-misleading-calls-to-md_bug
drivers/md/md.c
--- 25/drivers/md/md.c~md-remove-a-number-of-misleading-calls-to-md_bug
2005-04-12 03:21:50.447467720 -0700
+++ 25-akpm/drivers/md/md.c 2005-04-12 03:21:50.453466808 -0700
@@ -1387,7 +1387,7 @@ abort_free:
*/
-static int analyze_sbs(mddev_t * mddev)
+static void analyze_sbs(mddev_t * mddev)
{
int i;
struct list_head *tmp;
@@ -1441,7 +1441,6 @@ static int analyze_sbs(mddev_t * mddev)
" -- starting background reconstruction\n",
mdname(mddev));
- return 0;
}
int mdp_major = 0;
@@ -1508,10 +1507,9 @@ static int do_md_run(mddev_t * mddev)
struct gendisk *disk;
char b[BDEVNAME_SIZE];
- if (list_empty(>disks)) {
- MD_BUG();
+ if (list_empty(>disks))
+ /* cannot run an array with no devices.. */
return -EINVAL;
- }
if (mddev->pers)
return -EBUSY;
@@ -1519,10 +1517,8 @@ static int do_md_run(mddev_t * mddev)
/*
* Analyze all RAID superblock(s)
*/
- if (!mddev->raid_disks && analyze_sbs(mddev)) {
- MD_BUG();
- return -EINVAL;
- }
+ if (!mddev->raid_disks)
+ analyze_sbs(mddev);
chunk_size = mddev->chunk_size;
pnum = level_to_pers(mddev->level);
@@ -1548,7 +1544,7 @@ static int do_md_run(mddev_t * mddev)
* chunk-size has to be a power of 2 and multiples of PAGE_SIZE
*/
if ( (1 << ffz(~chunk_size)) != chunk_size) {
- MD_BUG();
+ printk(KERN_ERR "chunk_size of %d not valid\n",
chunk_size);
return -EINVAL;
}
if (chunk_size < PAGE_SIZE) {
@@ -1573,11 +1569,6 @@ static int do_md_run(mddev_t * mddev)
}
}
- if (pnum >= MAX_PERSONALITY) {
- MD_BUG();
- return -EINVAL;
- }
-
#ifdef CONFIG_KMOD
if (!pers[pnum])
{
@@ -1762,10 +1753,8 @@ static void autorun_array(mddev_t *mddev
struct list_head *tmp;
int err;
- if (list_empty(>disks)) {
- MD_BUG();
+ if (list_empty(>disks))
return;
- }
printk(KERN_INFO "md: running: ");
@@ -3128,7 +3117,6 @@ int register_md_personality(int pnum, md
spin_lock(_lock);
if (pers[pnum]) {
spin_unlock(_lock);
- MD_BUG();
return -EBUSY;
}
@@ -3140,10 +3128,8 @@ int register_md_personality(int pnum, md
int unregister_md_personality(int pnum)
{
- if (pnum >= MAX_PERSONALITY) {
- MD_BUG();
+ if (pnum >= MAX_PERSONALITY)
return -EINVAL;
- }
printk(KERN_INFO "md: %s personality unregistered\n", pers[pnum]->name);
spin_lock(_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: [PATCH] Priority Lists for the RT mutex
On Sun, 2005-04-10 at 04:09, Ingo Molnar wrote: > Unless i'm missing something, this could be implemented by detaching > lock->owner_prio from lock->owner - via e.g. negative values. Thus some > minimal code would check whether we need the owner's priority in the PI > logic, or the semaphore's "own" priority level. The owners priority should be set to the semaphore's priority .. Or the highest priority of all the semaphores that it has locked. Daniel - 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 174/198] IB/mthca: fix format of CQ number for CQ events
From: Roland Dreier <[EMAIL PROTECTED]> CQ numbers are only 24 bits, so only print 6 hex digits and mask off reserved part when reporting a CQ event. Signed-off-by: Roland Dreier <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- 25-akpm/drivers/infiniband/hw/mthca/mthca_eq.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff -puN drivers/infiniband/hw/mthca/mthca_eq.c~ib-mthca-fix-format-of-cq-number-for-cq-events drivers/infiniband/hw/mthca/mthca_eq.c --- 25/drivers/infiniband/hw/mthca/mthca_eq.c~ib-mthca-fix-format-of-cq-number-for-cq-events 2005-04-12 03:21:44.893312080 -0700 +++ 25-akpm/drivers/infiniband/hw/mthca/mthca_eq.c 2005-04-12 03:21:44.896311624 -0700 @@ -344,10 +344,10 @@ static int mthca_eq_int(struct mthca_dev break; case MTHCA_EVENT_TYPE_CQ_ERROR: - mthca_warn(dev, "CQ %s on CQN %08x\n", + mthca_warn(dev, "CQ %s on CQN %06x\n", eqe->event.cq_err.syndrome == 1 ? "overrun" : "access violation", - be32_to_cpu(eqe->event.cq_err.cqn)); + be32_to_cpu(eqe->event.cq_err.cqn) & 0xff); break; case MTHCA_EVENT_TYPE_EQ_OVERFLOW: _ - 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 178/198] IB/mthca: allow address handle creation in interrupt context
From: Roland Dreier <[EMAIL PROTECTED]>
Make address handle verbs usable from interrupt context.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/drivers/infiniband/hw/mthca/mthca_av.c |6 +++---
25-akpm/drivers/infiniband/hw/mthca/mthca_provider.c |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff -puN
drivers/infiniband/hw/mthca/mthca_av.c~ib-mthca-allow-address-handle-creation-in-interrupt-context
drivers/infiniband/hw/mthca/mthca_av.c
---
25/drivers/infiniband/hw/mthca/mthca_av.c~ib-mthca-allow-address-handle-creation-in-interrupt-context
2005-04-12 03:21:45.821171024 -0700
+++ 25-akpm/drivers/infiniband/hw/mthca/mthca_av.c 2005-04-12
03:21:45.826170264 -0700
@@ -63,7 +63,7 @@ int mthca_create_ah(struct mthca_dev *de
ah->type = MTHCA_AH_PCI_POOL;
if (dev->hca_type == ARBEL_NATIVE) {
- ah->av = kmalloc(sizeof *ah->av, GFP_KERNEL);
+ ah->av = kmalloc(sizeof *ah->av, GFP_ATOMIC);
if (!ah->av)
return -ENOMEM;
@@ -77,7 +77,7 @@ int mthca_create_ah(struct mthca_dev *de
if (index == -1)
goto on_hca_fail;
- av = kmalloc(sizeof *av, GFP_KERNEL);
+ av = kmalloc(sizeof *av, GFP_ATOMIC);
if (!av)
goto on_hca_fail;
@@ -89,7 +89,7 @@ int mthca_create_ah(struct mthca_dev *de
on_hca_fail:
if (ah->type == MTHCA_AH_PCI_POOL) {
ah->av = pci_pool_alloc(dev->av_table.pool,
- SLAB_KERNEL, >avdma);
+ SLAB_ATOMIC, >avdma);
if (!ah->av)
return -ENOMEM;
diff -puN
drivers/infiniband/hw/mthca/mthca_provider.c~ib-mthca-allow-address-handle-creation-in-interrupt-context
drivers/infiniband/hw/mthca/mthca_provider.c
---
25/drivers/infiniband/hw/mthca/mthca_provider.c~ib-mthca-allow-address-handle-creation-in-interrupt-context
2005-04-12 03:21:45.823170720 -0700
+++ 25-akpm/drivers/infiniband/hw/mthca/mthca_provider.c2005-04-12
03:21:45.827170112 -0700
@@ -315,7 +315,7 @@ static struct ib_ah *mthca_ah_create(str
int err;
struct mthca_ah *ah;
- ah = kmalloc(sizeof *ah, GFP_KERNEL);
+ ah = kmalloc(sizeof *ah, GFP_ATOMIC);
if (!ah)
return ERR_PTR(-ENOMEM);
_
-
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 189/198] IB/mthca: add support for new MT25204 HCA
From: Roland Dreier <[EMAIL PROTECTED]>
Decouple table of HCA features from exact HCA device type. Add a current FW
version field so we can warn when someone is using old FW. Add support for
new MT25204 HCA.
Remove the warning about mem-free support, since it should be pretty solid at
this point.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/drivers/infiniband/hw/mthca/mthca_dev.h | 13 +--
25-akpm/drivers/infiniband/hw/mthca/mthca_main.c | 67 +++
25-akpm/drivers/infiniband/hw/mthca/mthca_provider.c | 17 +++-
25-akpm/drivers/infiniband/hw/mthca/mthca_reset.c|2
4 files changed, 73 insertions(+), 26 deletions(-)
diff -puN
drivers/infiniband/hw/mthca/mthca_dev.h~ib-mthca-add-support-for-new-mt25204-hca
drivers/infiniband/hw/mthca/mthca_dev.h
---
25/drivers/infiniband/hw/mthca/mthca_dev.h~ib-mthca-add-support-for-new-mt25204-hca
2005-04-12 03:21:48.431774152 -0700
+++ 25-akpm/drivers/infiniband/hw/mthca/mthca_dev.h 2005-04-12
03:21:48.439772936 -0700
@@ -49,20 +49,15 @@
#define DRV_VERSION"0.06-pre"
#define DRV_RELDATE"November 8, 2004"
-/* Types of supported HCA */
-enum {
- TAVOR, /* MT23108*/
- ARBEL_COMPAT, /* MT25208 in Tavor compat mode */
- ARBEL_NATIVE/* MT25208 with extended features */
-};
-
enum {
MTHCA_FLAG_DDR_HIDDEN = 1 << 1,
MTHCA_FLAG_SRQ= 1 << 2,
MTHCA_FLAG_MSI= 1 << 3,
MTHCA_FLAG_MSI_X = 1 << 4,
MTHCA_FLAG_NO_LAM = 1 << 5,
- MTHCA_FLAG_FMR= 1 << 6
+ MTHCA_FLAG_FMR= 1 << 6,
+ MTHCA_FLAG_MEMFREE= 1 << 7,
+ MTHCA_FLAG_PCIE = 1 << 8
};
enum {
@@ -473,7 +468,7 @@ static inline struct mthca_dev *to_mdev(
static inline int mthca_is_memfree(struct mthca_dev *dev)
{
- return dev->hca_type == ARBEL_NATIVE;
+ return dev->mthca_flags & MTHCA_FLAG_MEMFREE;
}
#endif /* MTHCA_DEV_H */
diff -puN
drivers/infiniband/hw/mthca/mthca_main.c~ib-mthca-add-support-for-new-mt25204-hca
drivers/infiniband/hw/mthca/mthca_main.c
---
25/drivers/infiniband/hw/mthca/mthca_main.c~ib-mthca-add-support-for-new-mt25204-hca
2005-04-12 03:21:48.433773848 -0700
+++ 25-akpm/drivers/infiniband/hw/mthca/mthca_main.c2005-04-12
03:21:48.440772784 -0700
@@ -103,7 +103,7 @@ static int __devinit mthca_tune_pci(stru
"aborting.\n");
return -ENODEV;
}
- } else if (mdev->hca_type == TAVOR)
+ } else if (!(mdev->mthca_flags & MTHCA_FLAG_PCIE))
mthca_info(mdev, "No PCI-X capability, not setting RBC.\n");
cap = pci_find_capability(mdev->pdev, PCI_CAP_ID_EXP);
@@ -119,8 +119,7 @@ static int __devinit mthca_tune_pci(stru
"register, aborting.\n");
return -ENODEV;
}
- } else if (mdev->hca_type == ARBEL_NATIVE ||
- mdev->hca_type == ARBEL_COMPAT)
+ } else if (mdev->mthca_flags & MTHCA_FLAG_PCIE)
mthca_info(mdev, "No PCI Express capability, "
"not setting Max Read Request Size.\n");
@@ -438,7 +437,7 @@ static int __devinit mthca_init_icm(stru
if (!mdev->qp_table.rdb_table) {
mthca_err(mdev, "Failed to map RDB context memory, aborting\n");
err = -ENOMEM;
- goto err_unmap_eqp;
+ goto err_unmap_rdb;
}
mdev->cq_table.table = mthca_alloc_icm_table(mdev, init_hca->cqc_base,
@@ -593,6 +592,7 @@ static int __devinit mthca_init_arbel(st
err_free_icm:
mthca_free_icm_table(mdev, mdev->cq_table.table);
+ mthca_free_icm_table(mdev, mdev->qp_table.rdb_table);
mthca_free_icm_table(mdev, mdev->qp_table.eqp_table);
mthca_free_icm_table(mdev, mdev->qp_table.qp_table);
mthca_free_icm_table(mdev, mdev->mr_table.mpt_table);
@@ -851,6 +851,7 @@ static void mthca_close_hca(struct mthca
if (mthca_is_memfree(mdev)) {
mthca_free_icm_table(mdev, mdev->cq_table.table);
+ mthca_free_icm_table(mdev, mdev->qp_table.rdb_table);
mthca_free_icm_table(mdev, mdev->qp_table.eqp_table);
mthca_free_icm_table(mdev, mdev->qp_table.qp_table);
mthca_free_icm_table(mdev, mdev->mr_table.mpt_table);
@@ -869,11 +870,32 @@ static void mthca_close_hca(struct mthca
mthca_SYS_DIS(mdev, );
}
+/* Types of supported HCA */
+enum {
+ TAVOR, /* MT23108*/
+ ARBEL_COMPAT, /* MT25208 in Tavor compat mode */
+ ARBEL_NATIVE, /* MT25208 with extended features */
+ SINAI /* MT25204 */
+};
+
+#define MTHCA_FW_VER(major, minor, subminor) \
+ (((u64)
[patch 191/198] jbd dirty buffer leak fix
This fixes the lots-of-fsx-linux-instances-cause-a-slow-leak bug.
It's been there since 2.6.6, caused by:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.5/2.6.5-mm4/broken-out/jbd-move-locked-buffers.patch
That patch moves under-writeout ordered-data buffers onto a separate journal
list during commit. It took out the old code which was based on a single
list.
The old code (necessarily) had logic which would restart I/O against buffers
which had been redirtied while they were on the committing transaction's
t_sync_datalist list. The new code only writes buffers once, ignoring
redirtyings by a later transaction, which is good.
But over on the truncate side of things, in journal_unmap_buffer(), we're
treating buffers on the t_locked_list as inviolable things which belong to the
committing transaction, and we just leave them alone during concurrent
truncate-vs-commit.
The net effect is that when truncate tries to invalidate a page whose buffers
are on t_locked_list and have been redirtied, journal_unmap_buffer() just
leaves those buffers alone. truncate will remove the page from its mapping
and we end up with an anonymous clean page with dirty buffers, which is an
illegal state for a page. The JBD commit will not clean those buffers as they
are removed from t_locked_list. The VM (try_to_free_buffers) cannot reclaim
these pages.
The patch teaches journal_unmap_buffer() about buffers which are on the
committing transaction's t_locked_list. These buffers have been written and
I/O has completed. We can take them off the transaction and undirty them
within the context of journal_invalidatepage()->journal_unmap_buffer().
Acked-by: "Stephen C. Tweedie" <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/fs/jbd/transaction.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff -puN fs/jbd/transaction.c~jbd-dirty-buffer-leak-fix fs/jbd/transaction.c
--- 25/fs/jbd/transaction.c~jbd-dirty-buffer-leak-fix 2005-04-12
03:21:48.891704232 -0700
+++ 25-akpm/fs/jbd/transaction.c2005-04-12 03:21:48.895703624 -0700
@@ -1812,7 +1812,17 @@ static int journal_unmap_buffer(journal_
}
}
} else if (transaction == journal->j_committing_transaction) {
- /* If it is committing, we simply cannot touch it. We
+ if (jh->b_jlist == BJ_Locked) {
+ /*
+* The buffer is on the committing transaction's locked
+* list. We have the buffer locked, so I/O has
+* completed. So we can nail the buffer now.
+*/
+ may_free = __dispose_buffer(jh, transaction);
+ goto zap_buffer;
+ }
+ /*
+* If it is committing, we simply cannot touch it. We
* can remove it's next_transaction pointer from the
* running transaction if that is set, but nothing
* else. */
@@ -1887,7 +1897,6 @@ int journal_invalidatepage(journal_t *jo
unsigned int next_off = curr_off + bh->b_size;
next = bh->b_this_page;
- /* AKPM: doing lock_buffer here may be overly paranoid */
if (offset <= curr_off) {
/* This block is wholly outside the truncation point */
lock_buffer(bh);
_
-
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 170/198] IB/mthca: fix MR allocation error path
From: Michael S. Tsirkin <[EMAIL PROTECTED]> Fix error handling in MR allocation for mem-free mode: mthca_free must get an MR index, not a key. Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]> Signed-off-by: Roland Dreier <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- 25-akpm/drivers/infiniband/hw/mthca/mthca_mr.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff -puN drivers/infiniband/hw/mthca/mthca_mr.c~ib-mthca-fix-mr-allocation-error-path drivers/infiniband/hw/mthca/mthca_mr.c --- 25/drivers/infiniband/hw/mthca/mthca_mr.c~ib-mthca-fix-mr-allocation-error-path 2005-04-12 03:21:43.875466816 -0700 +++ 25-akpm/drivers/infiniband/hw/mthca/mthca_mr.c 2005-04-12 03:21:43.878466360 -0700 @@ -231,7 +231,7 @@ err_out_table: mthca_table_put(dev, dev->mr_table.mpt_table, key); err_out_mpt_free: - mthca_free(>mr_table.mpt_alloc, mr->ibmr.lkey); + mthca_free(>mr_table.mpt_alloc, key); kfree(mailbox); return err; } @@ -368,7 +368,7 @@ err_out_table: mthca_table_put(dev, dev->mr_table.mpt_table, key); err_out_mpt_free: - mthca_free(>mr_table.mpt_alloc, mr->ibmr.lkey); + mthca_free(>mr_table.mpt_alloc, key); return err; } _ - 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 129/198] fix up newly added jsm driver
From: Christoph Hellwig <[EMAIL PROTECTED]>
- plug various leaks and use after frees in the remove and
initialization failure path (some still left)
- remove useless global list of boards and use pci_set_drvdata instead
- unobsfucate init path by merging functions together
- kill various totally useless state variables
- .. probably more I forgot
Note that the tty part still generates lots of sparse warnings and there's
still a totally useless layer of function pointer indirections, but maybe
someone else will fix that bit up.
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/drivers/serial/jsm/jsm.h| 38 ---
25-akpm/drivers/serial/jsm/jsm_driver.c | 348
25-akpm/drivers/serial/jsm/jsm_tty.c| 24 --
3 files changed, 95 insertions(+), 315 deletions(-)
diff -puN drivers/serial/jsm/jsm_driver.c~fixup-newly-added-jsm-driver
drivers/serial/jsm/jsm_driver.c
--- 25/drivers/serial/jsm/jsm_driver.c~fixup-newly-added-jsm-driver
2005-04-12 03:21:34.728857312 -0700
+++ 25-akpm/drivers/serial/jsm/jsm_driver.c 2005-04-12 03:21:34.736856096
-0700
@@ -29,7 +29,9 @@
#include "jsm.h"
MODULE_AUTHOR("Digi International, http://www.digi.com;);
-MODULE_DESCRIPTION("Driver for the Digi International Neo PCI based product
line");
+MODULE_DESCRIPTION("Driver for the Digi International "
+ "Neo PCI based product line");
+MODULE_LICENSE("GPL");
MODULE_SUPPORTED_DEVICE("jsm");
#define JSM_DRIVER_NAME "jsm"
@@ -43,7 +45,6 @@ struct uart_driver jsm_uart_driver = {
.major = 253,
.minor = JSM_MINOR_START,
.nr = NR_PORTS,
- .cons = NULL,
};
int jsm_debug;
@@ -53,193 +54,99 @@ module_param(jsm_rawreadok, int, 0);
MODULE_PARM_DESC(jsm_debug, "Driver debugging level");
MODULE_PARM_DESC(jsm_rawreadok, "Bypass flip buffers on input");
-/*
- * Globals
- */
-intjsm_driver_state = DRIVER_INITIALIZED;
-spinlock_t jsm_board_head_lock = SPIN_LOCK_UNLOCKED;
-LIST_HEAD(jsm_board_head);
-
-static struct pci_device_id jsm_pci_tbl[] = {
- { PCI_DEVICE (PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2DB9), 0,
0, 0 },
- { PCI_DEVICE (PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2DB9PRI), 0,
0, 1 },
- { PCI_DEVICE (PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2RJ45), 0,
0, 2 },
- { PCI_DEVICE (PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2RJ45PRI), 0,
0, 3 },
- { 0,} /* 0 terminated list. */
-};
-MODULE_DEVICE_TABLE(pci, jsm_pci_tbl);
-
-static struct board_id jsm_Ids[] = {
- { PCI_DEVICE_NEO_2DB9_PCI_NAME, 2 },
- { PCI_DEVICE_NEO_2DB9PRI_PCI_NAME, 2 },
- { PCI_DEVICE_NEO_2RJ45_PCI_NAME,2 },
- { PCI_DEVICE_NEO_2RJ45PRI_PCI_NAME, 2 },
- { NULL, 0 }
-};
-
-char *jsm_driver_state_text[] = {
- "Driver Initialized",
- "Driver Ready."
-};
-
-static int jsm_finalize_board_init(struct jsm_board *brd)
+static int jsm_probe_one(struct pci_dev *pdev, const struct pci_device_id *ent)
{
int rc = 0;
+ struct jsm_board *brd;
+ static int adapter_count = 0;
+ int retval;
- jsm_printk(INIT, INFO, >pci_dev, "start\n");
-
- if (brd->irq) {
- rc = request_irq(brd->irq, brd->bd_ops->intr,
SA_INTERRUPT|SA_SHIRQ, "JSM", brd);
-
- if (rc) {
- printk(KERN_WARNING "Failed to hook IRQ %d\n",brd->irq);
- brd->state = BOARD_FAILED;
- brd->dpastatus = BD_NOFEP;
- rc = -ENODEV;
- } else
- jsm_printk(INIT, INFO, >pci_dev,
- "Requested and received usage of IRQ %d\n",
brd->irq);
+ rc = pci_enable_device(pdev);
+ if (rc) {
+ dev_err(>dev, "Device enable FAILED\n");
+ goto out;
}
- return rc;
-}
-/*
- * jsm_found_board()
- *
- * A board has been found, init it.
- */
-static int jsm_found_board(struct pci_dev *pdev, int id)
-{
- struct jsm_board *brd;
- int i = 0;
- int rc = 0;
- struct list_head *tmp;
- struct jsm_board *cur_board_entry;
- unsigned long lock_flags;
- int adapter_count = 0;
- int retval;
+ rc = pci_request_regions(pdev, "jsm");
+ if (rc) {
+ dev_err(>dev, "pci_request_region FAILED\n");
+ goto out_disable_device;
+ }
brd = kmalloc(sizeof(struct jsm_board), GFP_KERNEL);
if (!brd) {
- dev_err(>dev, "memory allocation for board structure
failed\n");
- return -ENOMEM;
+ dev_err(>dev,
+ "memory allocation for board structure failed\n");
+ rc = -ENOMEM;
+ goto out_release_regions;
}
[patch 196/198] fbdev MAINTAINERS update
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]> This patch does the long overdue updates to MAINTAINERS file for aty128fb and radeonfb. Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- 25-akpm/MAINTAINERS |8 1 files changed, 4 insertions(+), 4 deletions(-) diff -puN MAINTAINERS~fbdev-maintainers-update MAINTAINERS --- 25/MAINTAINERS~fbdev-maintainers-update 2005-04-12 03:21:50.014533536 -0700 +++ 25-akpm/MAINTAINERS 2005-04-12 03:21:50.019532776 -0700 @@ -1852,14 +1852,14 @@ W: http://www.alarsen.net/linux/qnx4fs/ S: Maintained RADEON FRAMEBUFFER DISPLAY DRIVER -P: Ani Joshi -M: [EMAIL PROTECTED] +P: Benjamin Herrenschmidt +M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] S: Maintained RAGE128 FRAMEBUFFER DISPLAY DRIVER -P: Ani Joshi -M: [EMAIL PROTECTED] +P: Paul Mackerras +M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] S: Maintained _ - 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 194/198] nfsd4: fix struct file leak
From: NeilBrown <[EMAIL PROTECTED]>
We were failing to close on an error path, resulting in a leak of struct files
which could take a v4 server down fairly quickly So call
nfs4_close_delegation instead of just open-coding parts of it.
Simplify the cleanup on delegation failure while we're at it.
Signed-off-by: J. Bruce Fields <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/fs/nfsd/nfs4state.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff -puN fs/nfsd/nfs4state.c~nfsd4-fix-struct-file-leak fs/nfsd/nfs4state.c
--- 25/fs/nfsd/nfs4state.c~nfsd4-fix-struct-file-leak 2005-04-12
03:21:49.583599048 -0700
+++ 25-akpm/fs/nfsd/nfs4state.c 2005-04-12 03:21:49.589598136 -0700
@@ -190,7 +190,8 @@ nfs4_close_delegation(struct nfs4_delega
dp->dl_vfs_file = NULL;
/* The following nfsd_close may not actually close the file,
* but we want to remove the lease in any case. */
- setlease(filp, F_UNLCK, >dl_flock);
+ if (dp->dl_flock)
+ setlease(filp, F_UNLCK, >dl_flock);
nfsd_close(filp);
vfsclose++;
}
@@ -1673,10 +1674,7 @@ nfs4_open_delegation(struct svc_fh *fh,
if ((status = setlease(stp->st_vfs_file,
flag == NFS4_OPEN_DELEGATE_READ? F_RDLCK: F_WRLCK, ))) {
dprintk("NFSD: setlease failed [%d], no delegation\n", status);
- list_del(>dl_del_perfile);
- list_del(>dl_del_perclnt);
- nfs4_put_delegation(dp);
- free_delegation++;
+ unhash_delegation(dp);
flag = NFS4_OPEN_DELEGATE_NONE;
goto out;
}
_
-
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 131/198] quota: fix possible oops on quotaoff
From: Jan Kara <[EMAIL PROTECTED]> Remove dquot structures from quota file on quotaon - quota code does not expect them to be there. Signed-off-by: Jan Kara <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- 25-akpm/fs/dquot.c |1 + 1 files changed, 1 insertion(+) diff -puN fs/dquot.c~quota-fix-possible-oops-on-quotaoff fs/dquot.c --- 25/fs/dquot.c~quota-fix-possible-oops-on-quotaoff 2005-04-12 03:21:35.241779336 -0700 +++ 25-akpm/fs/dquot.c 2005-04-12 03:21:35.245778728 -0700 @@ -1443,6 +1443,7 @@ static int vfs_quota_on_inode(struct ino oldflags = inode->i_flags & (S_NOATIME | S_IMMUTABLE | S_NOQUOTA); inode->i_flags |= S_NOQUOTA | S_NOATIME | S_IMMUTABLE; up_write(>dqptr_sem); + sb->dq_op->drop(inode); error = -EIO; dqopt->files[type] = igrab(inode); _ - 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 scsi-misc-2.6 00/04] scsi: scsi_request_fn() reimplementation
Hello, guys. This patchset reimplements scsi_request_fn(). All prep's are moved into prep_fn and all state checking/issueing are moved into scsi_reqfn. prep_fn() only terminates/defers unpreparable requests and all requests are terminated through scsi midlayer. [ Start of patch descriptions ] 01_scsi_reqfn_consolidate_error_handling.patch : consolidate error handling out of scsi_init_io() into scsi_prep_fn() This patch fixes a queue stall bug which occurred when sgtable allocation failed and device_busy == 0. When scsi_init_io() returns BLKPREP_DEFER or BLKPREP_KILL, it's supposed to free resources itself. This patch consolidates defer and kill handling into scsi_prep_fn(). Note that this patch doesn't consolidate state defer/kill handlings in scsi_prep_fn(). They were omitted as all state checks will be moved into scsi_reques_fn() by the following reqfn_reimpl patch. ret value checking was changed to switch() as in James's patch. Also, kill: comment is copied from James's patch. 02_scsi_reqfn_move_preps_to_prep_fn.patch : move request preps in other places into prep_fn() Move request preparations scattered in scsi_request_fn() and scsi_dispatch_cmd() into scsi_prep_fn() * CDB_SIZE check in scsi_dispatch_cmd() * SCSI-2 LUN preparation in scsi_dispatch_cmd() No invalid request reaches scsi_request_fn() anymore. Note that scsi_init_cmd_errh() is still left in scsi_request_fn(). As all requeued requests need its sense buffer and result value cleared, we can't move this to prep_fn() yet. This is moved into prep_fn in the following requeue path consoildation patchset. 03_scsi_reqfn_reimplementation.patch : reimplement scsi_request_fn() This patch rewrites scsi_request_fn(). scsi_dispatch_cmd() is merged into scsi_request_fn(). Goals are * Remove unnecessary operations (host_lock unlocking/locking, recursing into scsi_run_queue(), ...) * Consolidate defer/kill paths. * Be concise. The following bugs are fixed. * All killed requests now get fully prep'ed and pass through __scsi_done(). This is the only kill path. - scsi_cmnd leak in offline-kill path removed - unfinished request bug in scsi_dispatch_cmd():SDEV_DEL-kill path removed. - commands are never terminated directly from blk layer unless they are invalid, so no need to supply req->end_io callback for special requests. * Timer is added while holding host_lock, after all conditions are checked and serial number is assigned. This guarantees that until host_lock is released, the scsi_cmnd pointed to by cmd isn't released. That didn't hold in the original code and, theoretically, the original code could access already released cmd. * For the same reason, if shost->hostt->queuecommand() fails, we try to delete the timer before releasing host_lock. Other changes/notes * host_lock is acquired and released only once. enter (qlocked) -> enter loop -> dev-prep -> switch to hlock -\ ^ switch to qlock <- issue <- host-prep <-/ * unnecessary if () on get_device() removed. * loop on elv_next_request() instead of blk_queue_plugged(). We now explicitly break out of loop when we plug and check if the queue has been plugged underneath us at the end of loop. * All device/host state checks are done in this function and done only once while holding qlock/host_lock respectively. * Requests which get deferred during dev-prep are never removed from request queue, so deferring is achieved by simply breaking out of the loop and returning. * Failure of blk_queue_start_tag() on tagged queue is a BUG now. This condition should have been catched by scsi_dev_queue_ready(). * req->special == NULL test removed. This just can't happen, and even if it ever happens, scsi_request_fn() will deterministically oops. * Requests which gets deferred during host-prep are requeued using blk_requeue_request(). This is the only requeue path. Note that scsi_kill_requests() still terminates requests using blk layer. The path is circular-ref workaround and soon to be replaced, so ignore it for now. 04_scsi_reqfn_remove_wait_req_end_io.patch : remove unnecessary scsi_wait_req_end_io() As all requests are now terminated via scsi midlayer, we don't need to set end_io for special reqs, remove it. Note that scsi_kill_requests() still terminates requests using
[patch 135/198] undo do_readv_writev() behavior change
From: Dave Hansen <[EMAIL PROTECTED]> Bugme bug 4326: http://bugme.osdl.org/show_bug.cgi?id=4326 reports: executing the systemcall readv with Bad argument ->len == -1) it gives out error EFAULT instead of EINVAL Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- 25-akpm/fs/read_write.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff -puN fs/read_write.c~undo-do_readv_writev-behavior-change fs/read_write.c --- 25/fs/read_write.c~undo-do_readv_writev-behavior-change 2005-04-12 03:21:36.081651656 -0700 +++ 25-akpm/fs/read_write.c 2005-04-12 03:21:36.084651200 -0700 @@ -467,10 +467,10 @@ static ssize_t do_readv_writev(int type, void __user *buf = iov[seg].iov_base; ssize_t len = (ssize_t)iov[seg].iov_len; - if (unlikely(!access_ok(vrfy_dir(type), buf, len))) - goto Efault; if (len < 0)/* size_t not fitting an ssize_t .. */ goto out; + if (unlikely(!access_ok(vrfy_dir(type), buf, len))) + goto Efault; tot_len += len; if ((ssize_t)tot_len < 0) /* maths overflow on the ssize_t */ goto out; _ - 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: more git updates..
Hi, Linus Torvalds schrub am Tue, 12 Apr 2005 15:49:07 -0700:
>> Have to tried to import it?
>
> It would take days.
You can always import it later and then graft it into the commit tree.
That would of course change *every* commit node, but so what? They're
small, and you can delete the old ones when you're done.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [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/
[PATCH] saa7134: Add OEM version of already supported card
Hi Tobias!
Thanks for checking the hardware. It is the same card,
the same configuration on the GPx resistors,
just a different subsystem vendor ID stored in its EEPROM.
The below patch is all it should take to have it auto-detected.
The driver will say it's a FlyTV, simply because the name strings
are stored with the card design data, not the device ID data.
Maintainers: NB, this is my 3rd patch over 2.6.12-rc2 on this file.
The patches don't overlap.
Peter
--- linux-2.6.12-rc2/drivers/media/video/saa7134/saa7134-cards.c
2005-04-09 12:01:47.0 +0200
+++ video4linux/saa7134-cards.c 2005-04-12 20:56:18.0 +0200
@@ -1628,11 +1628,17 @@
},{
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7133,
- .subvendor= 0x5168,
+ .subvendor= 0x5168, /* Animation Technologies (LifeView) */
.subdevice= 0x0214, /* Standard PCI, LR214WF */
.driver_data = SAA7134_BOARD_FLYTVPLATINUM_FM,
},{
.vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+ .subvendor= 0x1489, /* KYE */
+ .subdevice= 0x0214, /* Genius VideoWonder ProTV */
+ .driver_data = SAA7134_BOARD_FLYTVPLATINUM_FM, /* is an
LR214WF actually */
+},{
+ .vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7134,
.subvendor= 0x16be,
.subdevice= 0x0003,
On Tuesday 12 April 2005 20:21, Tobias van Dyk wrote:
> Peter here is the info:
> Things I'd like you to check:
>
> * There should be a small white sticker on the top side, near the
> audio/video
> connectors, with an 8-digit hex number on. LifeView stick the card's
> subsystem ID there. That should read 14890214 (or 02141489, can't actually
> remember the ordering) for yours, further evidence that it's jumped off the
> same production line. (Does the fine print say "LR214F" anywhere on the
> card?)
> ===>
> Yes sticker is 02141489
> PCB has LR214 REV D written at bottom righthand side
>
> * On the right edge of the card, there is a row of tiny configuration
> resistors labelled "GP1" through "GP7". I'd like you to write down which
> ones
> are populated and which ones are absent. Gerd and I assume that drivers may
> detect the finer details of a card's configuration from there, e.g. absence
> or presence of FM radio feature, so we need to collect how they're
> configured
> for the various versions of each LifeView card design.
> ==>
> Surface mount R's:
> GP1 and GP2 no resistors soldered
> GP3 GP4 GP5 GP6 GP7 has soldered resistors
>
> The tuning offset - I did a clean edit and compile - I do get a signal
> at -0.15 MHz below the true frequency but it is much weaker (distorted) -
> the one at -3.95 MHz is stronger - I cannot think why the two cards should
> be different is this respect. I tried to start the FMTuner "clean" and
> after TV settings - it does not make a difference. TV norm is PAL-I
>
> Regards
> Tobias
> - Original Message -
> From: "Peter Missel" <[EMAIL PROTECTED]>
> To:
> Cc: "Tobias van Dyk" <[EMAIL PROTECTED]>
> Sent: Tuesday, April 12, 2005 5:34 PM
> Subject: Re: Genius VideoWonder ProTV SAA7135 and TDA8275 Working
>
> > Tobias,
> >
> > on the audio offset, that's odd, it's definitely just .15 MHz for me.
> > What TV
> > norm are you on? Maybe there's something the tuner code forgets to adjust
> > when switching from TV to radio or somesuch problem.
> >
> > I've had a look around the web, and this card of yours indeed looks
> > EXACTLY
> > like the FlyTV Platinum FM - even more so from the dmesg capture you
> > gave. It
> > seems to be like I suspected, same thing with a different subsystem
> > vendor ID
> > (but even the same subsystem ID 0x0214).
> >
> > Things I'd like you to check:
> >
> > * There should be a small white sticker on the top side, near the
> > audio/video
> > connectors, with an 8-digit hex number on. LifeView stick the card's
> > subsystem ID there. That should read 14890214 (or 02141489, can't
> > actually remember the ordering) for yours, further evidence that it's
> > jumped off the
> > same production line. (Does the fine print say "LR214F" anywhere on the
> > card?)
> >
> > * On the right edge of the card, there is a row of tiny configuration
> > resistors labelled "GP1" through "GP7". I'd like you to write down which
> > ones
> > are populated and which ones are absent. Gerd and I assume that drivers
> > may
> > detect the finer details of a card's configuration from there, e.g.
> > absence
> > or presence of FM radio feature, so we need to collect how they're
> > configured
> > for the various versions of each LifeView card design.
> >
> > Anyone happen to have a FlyTV Platinum w/o FM? Only $38 from newegg, if
> > someone in the US wants to
[patch 136/198] Direct IO async short read fix
From: Daniel McNeil <[EMAIL PROTECTED]>
The direct I/O code is mapping the read request to the file system block. If
the file size was not on a block boundary, the result would show the the read
reading past EOF. This was only happening for the AIO case. The non-AIO case
truncates the result to match file size (in direct_io_worker). This patch
does the same thing for the AIO case, it truncates the result to match the
file size if the read reads past EOF.
When I/O completes the result can be truncated to match the file size
without using i_size_read(), thus the aio result now matches the number of
bytes read to the end of file.
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/fs/direct-io.c | 20 +---
1 files changed, 17 insertions(+), 3 deletions(-)
diff -puN fs/direct-io.c~direct-io-async-short-read-fix fs/direct-io.c
--- 25/fs/direct-io.c~direct-io-async-short-read-fix2005-04-12
03:21:36.288620192 -0700
+++ 25-akpm/fs/direct-io.c 2005-04-12 03:21:36.292619584 -0700
@@ -66,6 +66,7 @@ struct dio {
struct bio *bio;/* bio under assembly */
struct inode *inode;
int rw;
+ loff_t i_size; /* i_size when submitted */
int lock_type; /* doesn't change */
unsigned blkbits; /* doesn't change */
unsigned blkfactor; /* When we're using an alignment which
@@ -230,17 +231,29 @@ static void finished_one_bio(struct dio
spin_lock_irqsave(>bio_lock, flags);
if (dio->bio_count == 1) {
if (dio->is_async) {
+ ssize_t transferred;
+ loff_t offset;
+
/*
* Last reference to the dio is going away.
* Drop spinlock and complete the DIO.
*/
spin_unlock_irqrestore(>bio_lock, flags);
- dio_complete(dio, dio->block_in_file << dio->blkbits,
- dio->result);
+
+ /* Check for short read case */
+ transferred = dio->result;
+ offset = dio->iocb->ki_pos;
+
+ if ((dio->rw == READ) &&
+ ((offset + transferred) > dio->i_size))
+ transferred = dio->i_size - offset;
+
+ dio_complete(dio, offset, transferred);
+
/* Complete AIO later if falling back to buffered i/o */
if (dio->result == dio->size ||
((dio->rw == READ) && dio->result)) {
- aio_complete(dio->iocb, dio->result, 0);
+ aio_complete(dio->iocb, transferred, 0);
kfree(dio);
return;
} else {
@@ -951,6 +964,7 @@ direct_io_worker(int rw, struct kiocb *i
dio->page_errors = 0;
dio->result = 0;
dio->iocb = iocb;
+ dio->i_size = i_size_read(inode);
/*
* BIO completion state.
_
-
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 reproducible SMP crash in security/keys/key.c
SMP race handling is broken in key_user_lookup() in security/keys/key.c
(if CONFIG_KEYS is set to 'y'). This came up on our Samba servers, but is
not restricted to samba, though samba is probably the only software which
is likely to trigger this repeatedly (and it did happen allready four
times here in University of Helsinki, CS department).
However, it only takes two setreuid() calls at the same instant, so this
may be responsible for some other mysterious random crashes.
This is the same bug which was previously raported to LKML here (found by
google):
http://www.ussg.iu.edu/hypermail/linux/kernel/0502.2/0521.html
Here is a small test program, which can be used to trigger the bug and
crash the machine where it is run. It might take a few seconds:
#include
#include
int main() {
int i;
fork();
while(1) {
for(i=0;i<6;i++) { setreuid(i,0); }
putchar('.'); fflush(stdout);
};
}
The (rather obvious) problem is that key_user_lookup() does not properly
re-initialize the user lookup if there was a race.
This patch applies to vanilla 2.6.11.7 and latest fedora kernel
2.6.11-1.14_FC3. When applied, the test program runs just fine (and does
nothing useful).
Please Cc: any replies to me, since I am not a regular kernel hacker and
do not subscribe LKML.
Signed-Off-By: Jani Jaakkola <[EMAIL PROTECTED]>
--- linux-2.6.11/security/keys/key.c.orig Wed Mar 2 09:38:25 2005
+++ linux-2.6.11/security/keys/key.cTue Apr 12 18:19:50 2005
@@ -56,10 +56,12 @@
struct key_user *key_user_lookup(uid_t uid)
{
struct key_user *candidate = NULL, *user;
- struct rb_node *parent = NULL;
- struct rb_node **p = _user_tree.rb_node;
+ struct rb_node *parent;
+ struct rb_node **p;
try_again:
+ parent = NULL;
+ p = _user_tree.rb_node;
spin_lock(_user_lock);
/* search the tree for a user record with a matching UID */
-
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.12-rc2-mm3
Andrew Morton wrote: Nick Piggin <[EMAIL PROTECTED]> wrote: AS basically does its own TCQ strangulation, which IIRC involves things > > like completing all reads before issuing new writes, and completing all > > reads from one process before reads from another. As well as the > > fundamental way that waiting for a 'dependant read' throttles TCQ. > > My (mpt-fusion-based) workstation is still really slow when there's a lot > of writeout happening. Just from a quick test: > > > 2.6.12-rc2, as, tcq depth=2: 7.241 seconds > > 2.6.12-rc2, as, tcq depth=64: 12.172 seconds > > 2.6.12-rc2+patch,as, tcq depth=64: 7.199 seconds > > 2.6.12-rc2, cfq2, tcq depth=64: much more than 5 minutes > > 2.6.12-rc2, cfq3, tcq depth=64: much more than 5 minutes > > 2.6.11-rc4-mm1, as, mpt-f 39.349 seconds > > That was really really slow but had a sudden burst of read I/O at the end > which made the thing look better than it really is. I wouldn't have a clue > what tag depth it's using, and it's the only mpt-fusion based machine I > have handy... > Heh. Well with my current lineup on the mpt-fusion driver and no as-limit-queue-depth.patch that test takes 17 seconds. With as-limit-queue-depth.patch it's down to 10 seconds. Which is pretty darn good btw. I assume from this: scsi0 : ioc0: LSI53C1030, FwRev=01030600h, Ports=1, MaxQ=222, IRQ=25 scsi1 : ioc1: LSI53C1030, FwRev=01030600h, Ports=1, MaxQ=222, IRQ=26 that it's using a tag depth of 222. int req_depth; /* Number of request frames */ I wonder if that's true... One thing which changed is that this kernel now has the fixed-up mpt-fusion chipset tuning. That doubles the IO bandwidth, which would pretty well account for that difference. I'll wait and see how irritating things get under writeout load. Yes, we'll need to decide if we want to retain as-limit-queue-depth.patch and toss out some of the older AS logic which was designed to address the TCQ problem. Steve, could you help to identify a not-too-hard-to-set-up workload at which AS was particularly poor? Thanks. AS with XFS was pretty bad on a couple of workloads. random 4k reads and "metadata" which was 40%create, 40%append, 20%delete multithreaded workloads. I'll try to run a few tests with and without this patch on my hardware setup over the next day or so and see how it does. I have not really looked at AS performance since about 2.6.6/7. Our database team recently re-checked IO Scheduler performance, and on the Ad Hoc Decision Support Workload we still saw a 15-20% lower throughput on RHEL4 with AS compared to other schedulers which were all within a couple of %. Steve - 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 102/198] x86_64: Switch SMP bootup over to new CPU hotplug state machine
From: "Andi Kleen" <[EMAIL PROTECTED]>
This will allow hotplug CPU in the future and in general cleans up a lot of
crufty code. It also should plug some races that the old hackish way
introduces. Remove one old race workaround in NMI watchdog setup that is not
needed anymore.
I removed the old total sum of bogomips reporting code. The brag value of
BogoMips has been greatly devalued in the last years on the open market.
Real CPU hotplug will need some more work, but the infrastructure for it is
there now.
One drawback: the new TSC sync algorithm is less accurate than before. The
old way of zeroing TSCs is too intrusive to do later. Instead the TSC of the
BP is duplicated now, which is less accurate.
akpm:
- sync_tsc_bp_init seems to have the sense of `init' inverted.
- SPIN_LOCK_UNLOCKED is deprecated - use DEFINE_SPINLOCK.
Cc: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/x86_64/kernel/nmi.c |6
25-akpm/arch/x86_64/kernel/smp.c | 25 +
25-akpm/arch/x86_64/kernel/smpboot.c | 684 ---
25-akpm/arch/x86_64/kernel/time.c|9
25-akpm/include/asm-x86_64/msr.h |1
25-akpm/include/asm-x86_64/proto.h |2
25-akpm/include/asm-x86_64/smp.h | 29 -
7 files changed, 369 insertions(+), 387 deletions(-)
diff -puN
arch/x86_64/kernel/nmi.c~x86_64-switch-smp-bootup-over-to-new-cpu-hotplug-state
arch/x86_64/kernel/nmi.c
---
25/arch/x86_64/kernel/nmi.c~x86_64-switch-smp-bootup-over-to-new-cpu-hotplug-state
2005-04-12 03:21:27.384973752 -0700
+++ 25-akpm/arch/x86_64/kernel/nmi.c2005-04-12 03:21:27.396971928 -0700
@@ -130,12 +130,6 @@ int __init check_nmi_watchdog (void)
mdelay((10*1000)/nmi_hz); // wait 10 ticks
for (cpu = 0; cpu < NR_CPUS; cpu++) {
-#ifdef CONFIG_SMP
- /* Check cpu_callin_map here because that is set
- after the timer is started. */
- if (!cpu_isset(cpu, cpu_callin_map))
- continue;
-#endif
if (cpu_pda[cpu].__nmi_count - counts[cpu] <= 5) {
printk("CPU#%d: NMI appears to be stuck (%d)!\n",
cpu,
diff -puN
arch/x86_64/kernel/smpboot.c~x86_64-switch-smp-bootup-over-to-new-cpu-hotplug-state
arch/x86_64/kernel/smpboot.c
---
25/arch/x86_64/kernel/smpboot.c~x86_64-switch-smp-bootup-over-to-new-cpu-hotplug-state
2005-04-12 03:21:27.386973448 -0700
+++ 25-akpm/arch/x86_64/kernel/smpboot.c2005-04-12 03:21:27.401971168
-0700
@@ -12,8 +12,7 @@
* Pentium Pro and Pentium-II/Xeon MP machines.
* Original development of Linux SMP code supported by Caldera.
*
- * This code is released under the GNU General Public License version 2 or
- * later.
+ * This code is released under the GNU General Public License version 2
*
* Fixes
* Felix Koop : NR_CPUS used properly
@@ -31,9 +30,13 @@
* Tigran Aivazian : fixed "0.00 in /proc/uptime on SMP" bug.
* Maciej W. Rozycki : Bits for genuine 82489DX APICs
* Andi Kleen : Changed for SMP boot into long mode.
- * Rusty Russell : Hacked into shape for new "hotplug"
boot process.
+ * Rusty Russell : Hacked into shape for new "hotplug"
boot process.
+ * Andi Kleen : Converted to new state machine.
+ * Various cleanups.
+ * Probably mostly hotplug CPU ready now.
*/
+
#include
#include
@@ -54,11 +57,15 @@
#include
#include
+/* Change for real CPU hotplug. Note other files need to be fixed
+ first too. */
+#define __cpuinit __init
+#define __cpuinitdata __initdata
+
/* Number of siblings per CPU package */
int smp_num_siblings = 1;
/* Package ID of each logical CPU */
u8 phys_proc_id[NR_CPUS] = { [0 ... NR_CPUS-1] = BAD_APICID };
-/* Core ID of each logical CPU */
u8 cpu_core_id[NR_CPUS] = { [0 ... NR_CPUS-1] = BAD_APICID };
EXPORT_SYMBOL(phys_proc_id);
EXPORT_SYMBOL(cpu_core_id);
@@ -66,13 +73,24 @@ EXPORT_SYMBOL(cpu_core_id);
/* Bitmask of currently online CPUs */
cpumask_t cpu_online_map;
+EXPORT_SYMBOL(cpu_online_map);
+
+/*
+ * Private maps to synchronize booting between AP and BP.
+ * Probably not needed anymore, but it makes for easier debugging. -AK
+ */
cpumask_t cpu_callin_map;
cpumask_t cpu_callout_map;
-static cpumask_t smp_commenced_mask;
+
+cpumask_t cpu_possible_map;
+EXPORT_SYMBOL(cpu_possible_map);
/* Per CPU bogomips and other parameters */
struct cpuinfo_x86 cpu_data[NR_CPUS] __cacheline_aligned;
+/* Set when the idlers are all forked */
+int smp_threads_ready;
+
cpumask_t cpu_sibling_map[NR_CPUS] __cacheline_aligned;
cpumask_t cpu_core_map[NR_CPUS] __cacheline_aligned;
@@ -80,8 +98,8 @@ cpumask_t
[patch 120/198] fix u32 vs. pm_message_t in rest of the tree
From: Pavel Machek <[EMAIL PROTECTED]>
This fixes u32 vs. pm_message_t confusion in remaining places. Fortunately
there's few of them.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/sh/kernel/cpu/bus.c|2 +-
25-akpm/drivers/ide/pci/sc1200.c|2 +-
25-akpm/drivers/macintosh/via-pmu.c |2 +-
25-akpm/include/asm-sh/bus-sh.h |2 +-
25-akpm/include/linux/mmc/host.h|2 +-
25-akpm/sound/oss/cs46xx.c |2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff -puN arch/sh/kernel/cpu/bus.c~fix-u32-vs-pm_message_t-in-rest-of-the-tree
arch/sh/kernel/cpu/bus.c
--- 25/arch/sh/kernel/cpu/bus.c~fix-u32-vs-pm_message_t-in-rest-of-the-tree
2005-04-12 03:21:32.496196728 -0700
+++ 25-akpm/arch/sh/kernel/cpu/bus.c2005-04-12 03:21:32.506195208 -0700
@@ -31,7 +31,7 @@ static int sh_bus_match(struct device *d
return shdev->dev_id == shdrv->dev_id;
}
-static int sh_bus_suspend(struct device *dev, u32 state)
+static int sh_bus_suspend(struct device *dev, pm_message_t state)
{
struct sh_dev *shdev = to_sh_dev(dev);
struct sh_driver *shdrv = to_sh_driver(dev->driver);
diff -puN drivers/ide/pci/sc1200.c~fix-u32-vs-pm_message_t-in-rest-of-the-tree
drivers/ide/pci/sc1200.c
--- 25/drivers/ide/pci/sc1200.c~fix-u32-vs-pm_message_t-in-rest-of-the-tree
2005-04-12 03:21:32.497196576 -0700
+++ 25-akpm/drivers/ide/pci/sc1200.c2005-04-12 03:21:32.507195056 -0700
@@ -346,7 +346,7 @@ typedef struct sc1200_saved_state_s {
} sc1200_saved_state_t;
-static int sc1200_suspend (struct pci_dev *dev, u32 state)
+static int sc1200_suspend (struct pci_dev *dev, pm_message_t state)
{
ide_hwif_t *hwif = NULL;
diff -puN
drivers/macintosh/via-pmu.c~fix-u32-vs-pm_message_t-in-rest-of-the-tree
drivers/macintosh/via-pmu.c
--- 25/drivers/macintosh/via-pmu.c~fix-u32-vs-pm_message_t-in-rest-of-the-tree
2005-04-12 03:21:32.499196272 -0700
+++ 25-akpm/drivers/macintosh/via-pmu.c 2005-04-12 03:21:32.509194752 -0700
@@ -3052,7 +3052,7 @@ pmu_polled_request(struct adb_request *r
static int pmu_sys_suspended = 0;
-static int pmu_sys_suspend(struct sys_device *sysdev, u32 state)
+static int pmu_sys_suspend(struct sys_device *sysdev, pm_message_t state)
{
if (state != PM_SUSPEND_DISK || pmu_sys_suspended)
return 0;
diff -puN include/asm-sh/bus-sh.h~fix-u32-vs-pm_message_t-in-rest-of-the-tree
include/asm-sh/bus-sh.h
--- 25/include/asm-sh/bus-sh.h~fix-u32-vs-pm_message_t-in-rest-of-the-tree
2005-04-12 03:21:32.500196120 -0700
+++ 25-akpm/include/asm-sh/bus-sh.h 2005-04-12 03:21:32.510194600 -0700
@@ -34,7 +34,7 @@ struct sh_driver {
unsigned intbus_id;
int (*probe)(struct sh_dev *);
int (*remove)(struct sh_dev *);
- int (*suspend)(struct sh_dev *, u32);
+ int (*suspend)(struct sh_dev *, pm_message_t);
int (*resume)(struct sh_dev *);
};
diff -puN include/linux/mmc/host.h~fix-u32-vs-pm_message_t-in-rest-of-the-tree
include/linux/mmc/host.h
--- 25/include/linux/mmc/host.h~fix-u32-vs-pm_message_t-in-rest-of-the-tree
2005-04-12 03:21:32.501195968 -0700
+++ 25-akpm/include/linux/mmc/host.h2005-04-12 03:21:32.510194600 -0700
@@ -98,7 +98,7 @@ extern void mmc_free_host(struct mmc_hos
#define mmc_priv(x)((void *)((x) + 1))
#define mmc_dev(x) ((x)->dev)
-extern int mmc_suspend_host(struct mmc_host *, u32);
+extern int mmc_suspend_host(struct mmc_host *, pm_message_t);
extern int mmc_resume_host(struct mmc_host *);
extern void mmc_detect_change(struct mmc_host *);
diff -puN sound/oss/cs46xx.c~fix-u32-vs-pm_message_t-in-rest-of-the-tree
sound/oss/cs46xx.c
--- 25/sound/oss/cs46xx.c~fix-u32-vs-pm_message_t-in-rest-of-the-tree
2005-04-12 03:21:32.504195512 -0700
+++ 25-akpm/sound/oss/cs46xx.c 2005-04-12 03:21:32.514193992 -0700
@@ -3640,7 +3640,7 @@ static int cs46xx_restart_part(struct cs
static void cs461x_reset(struct cs_card *card);
static void cs461x_proc_stop(struct cs_card *card);
-static int cs46xx_suspend(struct cs_card *card, u32 state)
+static int cs46xx_suspend(struct cs_card *card, pm_message_t state)
{
unsigned int tmp;
CS_DBGOUT(CS_PM | CS_FUNCTION, 4,
_
-
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 006/198] arm: add comment about max_low_pfn/max_pfn
FYI http://lkml.org/lkml/2004/6/29/57 On 4/13/05, Coywolf Qi Hunt <[EMAIL PROTECTED]> wrote: > I told rmk about this long time ago. > > On 4/12/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > From: Russell King <[EMAIL PROTECTED]> > > > > Oddly, max_low_pfn/max_pfn end up being the number of pages in the system, > > rather than the maximum PFN on ARM. This doesn't seem to cause any > > problems, > > so just add a note about it. > > > > Signed-off-by: Russell King <[EMAIL PROTECTED]> > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > --- > > > > 25-akpm/arch/arm/mm/init.c |3 +++ > > 1 files changed, 3 insertions(+) > > > > diff -puN arch/arm/mm/init.c~arm-add-comment-about-max_low_pfn-max_pfn > > arch/arm/mm/init.c > > --- 25/arch/arm/mm/init.c~arm-add-comment-about-max_low_pfn-max_pfn > > 2005-04-12 03:21:04.967381744 -0700 > > +++ 25-akpm/arch/arm/mm/init.c 2005-04-12 03:21:04.971381136 -0700 > > @@ -223,6 +223,9 @@ find_memend_and_nodes(struct meminfo *mi > > * This doesn't seem to be used by the Linux memory > > * manager any more. If we can get rid of it, we > > * also get rid of some of the stuff above as well. > > +* > > +* Note: max_low_pfn and max_pfn reflect the number > > +* of _pages_ in the system, not the maximum PFN. > > */ > > max_low_pfn = memend_pfn - O_PFN_DOWN(PHYS_OFFSET); > > max_pfn = memend_pfn - O_PFN_DOWN(PHYS_OFFSET); > > _ > > -- > Coywolf Qi Hunt > http://sosdg.org/~coywolf/ > -- Coywolf Qi Hunt http://sosdg.org/~coywolf/ - 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 125/198] AYSNC IO using singals other than SIGIO
From: Bharath Ramesh <[EMAIL PROTECTED]> A question on sigwaitinfo based IO mechanism in multithreaded applications. I am trying to use RT signals to notify me of IO events using RT signals instead of SIGIO in a multithreaded applications. I noticed that there was some discussion on lkml during november 1999 with the subject of the discussion as "Signal driven IO". In the thread I noticed that RT signals were being delivered to the worker thread. I am running 2.6.10 kernel and I am trying to use the very same mechanism and I find that only SIGIO being propogated to the worker threads and RT signals only being propogated to the main thread and not the worker threads where I actually want them to be propogated too. On further inspection I found that the following patch which I have attached solves the problem. I am not sure if this is a bug or feature in the kernel. Roland McGrath <[EMAIL PROTECTED]> said: This relates only to fcntl F_SETSIG, which is a Linux extension. So there is no POSIX issue. When changing various things like the normal SIGIO signalling to do group signals, I was concerned strictly with the POSIX semantics and generally avoided touching things in the domain of Linux inventions. That's why I didn't change this when I changed the call right next to it. There is no reason I can see that F_SETSIG-requested signals shouldn't use a group signal like normal SIGIO does. I'm happy to ACK this patch, there is nothing wrong with its change to the semantics in my book. But neither POSIX nor I care a whit what F_SETSIG does. Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- 25-akpm/fs/fcntl.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN fs/fcntl.c~async-io-using-rt-signals fs/fcntl.c --- 25/fs/fcntl.c~async-io-using-rt-signals 2005-04-12 03:21:33.611027248 -0700 +++ 25-akpm/fs/fcntl.c 2005-04-12 03:21:33.614026792 -0700 @@ -437,7 +437,7 @@ static void send_sigio_to_task(struct ta else si.si_band = band_table[reason - POLL_IN]; si.si_fd= fd; - if (!send_sig_info(fown->signum, , p)) + if (!send_group_sig_info(fown->signum, , p)) break; /* fall-through: fall back on the old plain SIGIO signal */ case 0: _ - 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/
Why system call need to copy the date from the userspace before using it
Hi all, I am new to linux , hope someone can help me. While i am reading the source code of the linux system call , i find that the system call need to call copy_from_user() to copy the data from user space to kernel space before using it . Why not use it directly as the system call has got the address ? Furthermore , how to distinguish between user space and kernel space ? Thx a lot, TOM - 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 119/198] fix u32 vs. pm_message_t in driver/video
From: Pavel Machek <[EMAIL PROTECTED]>
This fixes u32 vs. pm_message_t confusion in drivers/video. Should change no
code.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/drivers/video/backlight/corgi_bl.c |2 +-
25-akpm/drivers/video/pxafb.c |2 +-
25-akpm/drivers/video/sa1100fb.c |2 +-
25-akpm/drivers/video/savage/savagefb_driver.c |4 ++--
25-akpm/drivers/video/w100fb.c |2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
diff -puN
drivers/video/backlight/corgi_bl.c~fix-u32-vs-pm_message_t-in-driver-video
drivers/video/backlight/corgi_bl.c
---
25/drivers/video/backlight/corgi_bl.c~fix-u32-vs-pm_message_t-in-driver-video
2005-04-12 03:21:32.226237768 -0700
+++ 25-akpm/drivers/video/backlight/corgi_bl.c 2005-04-12 03:21:32.235236400
-0700
@@ -81,7 +81,7 @@ static void corgibl_blank(int blank)
}
#ifdef CONFIG_PM
-static int corgibl_suspend(struct device *dev, u32 state, u32 level)
+static int corgibl_suspend(struct device *dev, pm_message_t state, u32 level)
{
if (level == SUSPEND_POWER_DOWN)
corgibl_blank(FB_BLANK_POWERDOWN);
diff -puN drivers/video/pxafb.c~fix-u32-vs-pm_message_t-in-driver-video
drivers/video/pxafb.c
--- 25/drivers/video/pxafb.c~fix-u32-vs-pm_message_t-in-driver-video
2005-04-12 03:21:32.228237464 -0700
+++ 25-akpm/drivers/video/pxafb.c 2005-04-12 03:21:32.236236248 -0700
@@ -942,7 +942,7 @@ pxafb_freq_policy(struct notifier_block
* Power management hooks. Note that we won't be called from IRQ context,
* unlike the blank functions above, so we may sleep.
*/
-static int pxafb_suspend(struct device *dev, u32 state, u32 level)
+static int pxafb_suspend(struct device *dev, pm_message_t state, u32 level)
{
struct pxafb_info *fbi = dev_get_drvdata(dev);
diff -puN drivers/video/sa1100fb.c~fix-u32-vs-pm_message_t-in-driver-video
drivers/video/sa1100fb.c
--- 25/drivers/video/sa1100fb.c~fix-u32-vs-pm_message_t-in-driver-video
2005-04-12 03:21:32.229237312 -0700
+++ 25-akpm/drivers/video/sa1100fb.c2005-04-12 03:21:32.238235944 -0700
@@ -1307,7 +1307,7 @@ sa1100fb_freq_policy(struct notifier_blo
* Power management hooks. Note that we won't be called from IRQ context,
* unlike the blank functions above, so we may sleep.
*/
-static int sa1100fb_suspend(struct device *dev, u32 state, u32 level)
+static int sa1100fb_suspend(struct device *dev, pm_message_t state, u32 level)
{
struct sa1100fb_info *fbi = dev_get_drvdata(dev);
diff -puN
drivers/video/savage/savagefb_driver.c~fix-u32-vs-pm_message_t-in-driver-video
drivers/video/savage/savagefb_driver.c
---
25/drivers/video/savage/savagefb_driver.c~fix-u32-vs-pm_message_t-in-driver-video
2005-04-12 03:21:32.231237008 -0700
+++ 25-akpm/drivers/video/savage/savagefb_driver.c 2005-04-12
03:21:32.240235640 -0700
@@ -2103,7 +2103,7 @@ static void __devexit savagefb_remove (s
}
}
-static int savagefb_suspend (struct pci_dev* dev, u32 state)
+static int savagefb_suspend (struct pci_dev* dev, pm_message_t state)
{
struct fb_info *info =
(struct fb_info *)pci_get_drvdata(dev);
@@ -2118,7 +2118,7 @@ static int savagefb_suspend (struct pci_
release_console_sem();
pci_disable_device(dev);
- pci_set_power_state(dev, state);
+ pci_set_power_state(dev, pci_choose_state(dev, state));
return 0;
}
diff -puN drivers/video/w100fb.c~fix-u32-vs-pm_message_t-in-driver-video
drivers/video/w100fb.c
--- 25/drivers/video/w100fb.c~fix-u32-vs-pm_message_t-in-driver-video
2005-04-12 03:21:32.232236856 -0700
+++ 25-akpm/drivers/video/w100fb.c 2005-04-12 03:21:32.241235488 -0700
@@ -544,7 +544,7 @@ static void w100fb_clear_buffer(void)
#ifdef CONFIG_PM
-static int w100fb_suspend(struct device *dev, u32 state, u32 level)
+static int w100fb_suspend(struct device *dev, pm_message_t state, u32 level)
{
if (level == SUSPEND_POWER_DOWN) {
struct fb_info *info = dev_get_drvdata(dev);
_
-
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 124/198] possible use-after-free of bio
From: Jens Axboe <[EMAIL PROTECTED]>
There is a possibility that a bio will be accessed after it has been freed
on SCSI. It happens if you submit a bio with BIO_SYNC marked and the
auto-unplugging kicks the request_fn, SCSI re-enables interrupts in-between
so if the request completes between the add_request() in __make_request()
and the bio_sync() call, we could be looking at a dead bio. It's a slim
race, but it has been triggered in the Real World.
So assign bio_sync() to a local variable instead.
Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/drivers/block/ll_rw_blk.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff -puN drivers/block/ll_rw_blk.c~possible-use-after-free-of-bio
drivers/block/ll_rw_blk.c
--- 25/drivers/block/ll_rw_blk.c~possible-use-after-free-of-bio 2005-04-12
03:21:33.400059320 -0700
+++ 25-akpm/drivers/block/ll_rw_blk.c 2005-04-12 03:21:33.405058560 -0700
@@ -2559,7 +2559,7 @@ EXPORT_SYMBOL(__blk_attempt_remerge);
static int __make_request(request_queue_t *q, struct bio *bio)
{
struct request *req, *freereq = NULL;
- int el_ret, rw, nr_sectors, cur_nr_sectors, barrier, err;
+ int el_ret, rw, nr_sectors, cur_nr_sectors, barrier, err, sync;
sector_t sector;
sector = bio->bi_sector;
@@ -2567,6 +2567,7 @@ static int __make_request(request_queue_
cur_nr_sectors = bio_cur_sectors(bio);
rw = bio_data_dir(bio);
+ sync = bio_sync(bio);
/*
* low level driver can indicate that it wants pages above a
@@ -2698,7 +2699,7 @@ get_rq:
out:
if (freereq)
__blk_put_request(q, freereq);
- if (bio_sync(bio))
+ if (sync)
__generic_unplug_device(q);
spin_unlock_irq(q->queue_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/
[patch 122/198] swsusp: SMP fix
From: Alexander Nyberg <[EMAIL PROTECTED]>
Fix some smp_processor_id-in-preemptible warnings
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/kernel/power/smp.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -puN kernel/power/smp.c~swsusp-smp-fix kernel/power/smp.c
--- 25/kernel/power/smp.c~swsusp-smp-fix2005-04-12 03:21:32.984122552
-0700
+++ 25-akpm/kernel/power/smp.c 2005-04-12 03:21:32.987122096 -0700
@@ -46,13 +46,13 @@ static cpumask_t oldmask;
void disable_nonboot_cpus(void)
{
- printk("Freezing CPUs (at %d)", smp_processor_id());
oldmask = current->cpus_allowed;
set_cpus_allowed(current, cpumask_of_cpu(0));
+ printk("Freezing CPUs (at %d)", _smp_processor_id());
current->state = TASK_INTERRUPTIBLE;
schedule_timeout(HZ);
printk("...");
- BUG_ON(smp_processor_id() != 0);
+ BUG_ON(_smp_processor_id() != 0);
/* FIXME: for this to work, all the CPUs must be running
* "idle" thread (or we deadlock). Is that guaranteed? */
_
-
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 123/198] uml: fix compilation for __CHOOSE_MODE addition
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
I had added the __CHOOSE_MODE syntax to fix some warnings with newer GCC's
in the uml-fix-cond-expr-as-lvalues-warning patch.
Here is the update from the version I sent to make it work also when only
one mode (TT or SKAS) is enabled.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/um/include/choose-mode.h | 27 ++-
1 files changed, 10 insertions(+), 17 deletions(-)
diff -puN
arch/um/include/choose-mode.h~uml-fix-compilation-for-__choose_mode-addition
arch/um/include/choose-mode.h
---
25/arch/um/include/choose-mode.h~uml-fix-compilation-for-__choose_mode-addition
2005-04-12 03:21:33.190091240 -0700
+++ 25-akpm/arch/um/include/choose-mode.h 2005-04-12 03:21:33.193090784
-0700
@@ -11,6 +11,13 @@
#if defined(UML_CONFIG_MODE_TT) && defined(UML_CONFIG_MODE_SKAS)
#define CHOOSE_MODE(tt, skas) (mode_tt ? (tt) : (skas))
+extern int mode_tt;
+static inline void *__choose_mode(void *tt, void *skas) {
+ return mode_tt ? tt : skas;
+}
+
+#define __CHOOSE_MODE(tt, skas) (*( (typeof(tt) *) __choose_mode(&(tt),
&(skas
+
#elif defined(UML_CONFIG_MODE_SKAS)
#define CHOOSE_MODE(tt, skas) (skas)
@@ -21,22 +28,8 @@
#define CHOOSE_MODE_PROC(tt, skas, args...) \
CHOOSE_MODE(tt(args), skas(args))
-extern int mode_tt;
-static inline void *__choose_mode(void *tt, void *skas) {
- return mode_tt ? tt : skas;
-}
-
-#define __CHOOSE_MODE(tt, skas) (*( (typeof(tt) *) __choose_mode(&(tt),
&(skas
-
+#ifndef __CHOOSE_MODE
+#define __CHOOSE_MODE(tt, skas) CHOOSE_MODE(tt, skas)
#endif
-/*
- * Overrides for Emacs so that we follow Linus's tabbing style.
- * Emacs will notice this stuff at the end of the file and automatically
- * adjust the settings for this buffer only. This must remain at the end
- * of the file.
- * ---
- * Local variables:
- * c-file-style: "linux"
- * End:
- */
+#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/
[patch 115/198] fix u32 vs. pm_message_t in PCI, PCIE
From: Pavel Machek <[EMAIL PROTECTED]>
This fixes drivers/pci (mostly pcie stuff).
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/drivers/pci/hotplug/pciehp_core.c |2 +-
25-akpm/drivers/pci/pcie/portdrv.h|2 +-
25-akpm/drivers/pci/pcie/portdrv_bus.c|4 ++--
25-akpm/drivers/pci/pcie/portdrv_core.c |6 +++---
25-akpm/drivers/pci/pcie/portdrv_pci.c|2 +-
25-akpm/include/linux/pcieport_if.h |2 +-
6 files changed, 9 insertions(+), 9 deletions(-)
diff -puN drivers/pci/hotplug/pciehp_core.c~fix-u32-vs-pm_message_t-in-pci-pcie
drivers/pci/hotplug/pciehp_core.c
--- 25/drivers/pci/hotplug/pciehp_core.c~fix-u32-vs-pm_message_t-in-pci-pcie
2005-04-12 03:21:31.183396304 -0700
+++ 25-akpm/drivers/pci/hotplug/pciehp_core.c 2005-04-12 03:21:31.192394936
-0700
@@ -578,7 +578,7 @@ static void pciehp_remove (struct pcie_d
}
#ifdef CONFIG_PM
-static int pciehp_suspend (struct pcie_device *dev, u32 state)
+static int pciehp_suspend (struct pcie_device *dev, pm_message_t state)
{
printk("%s ENTRY\n", __FUNCTION__);
return 0;
diff -puN drivers/pci/pcie/portdrv_bus.c~fix-u32-vs-pm_message_t-in-pci-pcie
drivers/pci/pcie/portdrv_bus.c
--- 25/drivers/pci/pcie/portdrv_bus.c~fix-u32-vs-pm_message_t-in-pci-pcie
2005-04-12 03:21:31.184396152 -0700
+++ 25-akpm/drivers/pci/pcie/portdrv_bus.c 2005-04-12 03:21:31.193394784
-0700
@@ -15,7 +15,7 @@
#include
static int pcie_port_bus_match(struct device *dev, struct device_driver *drv);
-static int pcie_port_bus_suspend(struct device *dev, u32 state);
+static int pcie_port_bus_suspend(struct device *dev, pm_message_t state);
static int pcie_port_bus_resume(struct device *dev);
struct bus_type pcie_port_bus_type = {
@@ -46,7 +46,7 @@ static int pcie_port_bus_match(struct de
return 1;
}
-static int pcie_port_bus_suspend(struct device *dev, u32 state)
+static int pcie_port_bus_suspend(struct device *dev, pm_message_t state)
{
struct pcie_device *pciedev;
struct pcie_port_service_driver *driver;
diff -puN drivers/pci/pcie/portdrv_core.c~fix-u32-vs-pm_message_t-in-pci-pcie
drivers/pci/pcie/portdrv_core.c
--- 25/drivers/pci/pcie/portdrv_core.c~fix-u32-vs-pm_message_t-in-pci-pcie
2005-04-12 03:21:31.185396000 -0700
+++ 25-akpm/drivers/pci/pcie/portdrv_core.c 2005-04-12 03:21:31.193394784
-0700
@@ -61,7 +61,7 @@ static int pcie_port_remove_service(stru
static void pcie_port_shutdown_service(struct device *dev) {}
-static int pcie_port_suspend_service(struct device *dev, u32 state, u32 level)
+static int pcie_port_suspend_service(struct device *dev, pm_message_t state,
u32 level)
{
struct pcie_device *pciedev;
struct pcie_port_service_driver *driver;
@@ -76,7 +76,7 @@ static int pcie_port_suspend_service(str
return 0;
}
-static int pcie_port_resume_service(struct device *dev, u32 state)
+static int pcie_port_resume_service(struct device *dev, u32 level)
{
struct pcie_device *pciedev;
struct pcie_port_service_driver *driver;
@@ -317,7 +317,7 @@ int pcie_port_device_register(struct pci
}
#ifdef CONFIG_PM
-int pcie_port_device_suspend(struct pci_dev *dev, u32 state)
+int pcie_port_device_suspend(struct pci_dev *dev, pm_message_t state)
{
struct list_head*head, *tmp;
struct device *parent, *child;
diff -puN drivers/pci/pcie/portdrv.h~fix-u32-vs-pm_message_t-in-pci-pcie
drivers/pci/pcie/portdrv.h
--- 25/drivers/pci/pcie/portdrv.h~fix-u32-vs-pm_message_t-in-pci-pcie
2005-04-12 03:21:31.187395696 -0700
+++ 25-akpm/drivers/pci/pcie/portdrv.h 2005-04-12 03:21:31.194394632 -0700
@@ -31,7 +31,7 @@ extern struct bus_type pcie_port_bus_typ
extern int pcie_port_device_probe(struct pci_dev *dev);
extern int pcie_port_device_register(struct pci_dev *dev);
#ifdef CONFIG_PM
-extern int pcie_port_device_suspend(struct pci_dev *dev, u32 state);
+extern int pcie_port_device_suspend(struct pci_dev *dev, pm_message_t state);
extern int pcie_port_device_resume(struct pci_dev *dev);
#endif
extern void pcie_port_device_remove(struct pci_dev *dev);
diff -puN drivers/pci/pcie/portdrv_pci.c~fix-u32-vs-pm_message_t-in-pci-pcie
drivers/pci/pcie/portdrv_pci.c
--- 25/drivers/pci/pcie/portdrv_pci.c~fix-u32-vs-pm_message_t-in-pci-pcie
2005-04-12 03:21:31.188395544 -0700
+++ 25-akpm/drivers/pci/pcie/portdrv_pci.c 2005-04-12 03:21:31.194394632
-0700
@@ -67,7 +67,7 @@ static void pcie_portdrv_remove (struct
}
#ifdef CONFIG_PM
-static int pcie_portdrv_suspend (struct pci_dev *dev, u32 state)
+static int pcie_portdrv_suspend (struct pci_dev *dev, pm_message_t state)
{
return pcie_port_device_suspend(dev, state);
}
diff -puN include/linux/pcieport_if.h~fix-u32-vs-pm_message_t-in-pci-pcie
include/linux/pcieport_if.h
--- 25/include/linux/pcieport_if.h~fix-u32-vs-pm_message_t-in-pci-pcie
[patch 111/198] fix u32 vs. pm_message_t in drivers/mmc,mtd,scsi
From: Pavel Machek <[EMAIL PROTECTED]>
This fixes u32 vs. pm_message_t in drivers/mmc, drivers/mtd and
drivers/scsi.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/drivers/mmc/mmc.c |2 +-
25-akpm/drivers/mmc/mmci.c |2 +-
25-akpm/drivers/mmc/pxamci.c|2 +-
25-akpm/drivers/mmc/wbsd.c |2 +-
25-akpm/drivers/mtd/maps/sa1100-flash.c |2 +-
25-akpm/drivers/scsi/mesh.c |2 +-
25-akpm/drivers/scsi/nsp32.c| 10 +-
7 files changed, 11 insertions(+), 11 deletions(-)
diff -puN drivers/mmc/mmc.c~fix-u32-vs-pm_message_t-in-drivers-mmcmtdscsi
drivers/mmc/mmc.c
--- 25/drivers/mmc/mmc.c~fix-u32-vs-pm_message_t-in-drivers-mmcmtdscsi
2005-04-12 03:21:30.196546328 -0700
+++ 25-akpm/drivers/mmc/mmc.c 2005-04-12 03:21:30.208544504 -0700
@@ -884,7 +884,7 @@ EXPORT_SYMBOL(mmc_free_host);
* @host: mmc host
* @state: suspend mode (PM_SUSPEND_xxx)
*/
-int mmc_suspend_host(struct mmc_host *host, u32 state)
+int mmc_suspend_host(struct mmc_host *host, pm_message_t state)
{
mmc_claim_host(host);
mmc_deselect_cards(host);
diff -puN drivers/mmc/mmci.c~fix-u32-vs-pm_message_t-in-drivers-mmcmtdscsi
drivers/mmc/mmci.c
--- 25/drivers/mmc/mmci.c~fix-u32-vs-pm_message_t-in-drivers-mmcmtdscsi
2005-04-12 03:21:30.197546176 -0700
+++ 25-akpm/drivers/mmc/mmci.c 2005-04-12 03:21:30.208544504 -0700
@@ -603,7 +603,7 @@ static int mmci_remove(struct amba_devic
}
#ifdef CONFIG_PM
-static int mmci_suspend(struct amba_device *dev, u32 state)
+static int mmci_suspend(struct amba_device *dev, pm_message_t state)
{
struct mmc_host *mmc = amba_get_drvdata(dev);
int ret = 0;
diff -puN drivers/mmc/pxamci.c~fix-u32-vs-pm_message_t-in-drivers-mmcmtdscsi
drivers/mmc/pxamci.c
--- 25/drivers/mmc/pxamci.c~fix-u32-vs-pm_message_t-in-drivers-mmcmtdscsi
2005-04-12 03:21:30.198546024 -0700
+++ 25-akpm/drivers/mmc/pxamci.c2005-04-12 03:21:30.209544352 -0700
@@ -558,7 +558,7 @@ static int pxamci_remove(struct device *
}
#ifdef CONFIG_PM
-static int pxamci_suspend(struct device *dev, u32 state, u32 level)
+static int pxamci_suspend(struct device *dev, pm_message_t state, u32 level)
{
struct mmc_host *mmc = dev_get_drvdata(dev);
int ret = 0;
diff -puN drivers/mmc/wbsd.c~fix-u32-vs-pm_message_t-in-drivers-mmcmtdscsi
drivers/mmc/wbsd.c
--- 25/drivers/mmc/wbsd.c~fix-u32-vs-pm_message_t-in-drivers-mmcmtdscsi
2005-04-12 03:21:30.200545720 -0700
+++ 25-akpm/drivers/mmc/wbsd.c 2005-04-12 03:21:30.210544200 -0700
@@ -1563,7 +1563,7 @@ static int wbsd_remove(struct device* de
*/
#ifdef CONFIG_PM
-static int wbsd_suspend(struct device *dev, u32 state, u32 level)
+static int wbsd_suspend(struct device *dev, pm_message_t state, u32 level)
{
DBGF("Not yet supported\n");
diff -puN
drivers/mtd/maps/sa1100-flash.c~fix-u32-vs-pm_message_t-in-drivers-mmcmtdscsi
drivers/mtd/maps/sa1100-flash.c
---
25/drivers/mtd/maps/sa1100-flash.c~fix-u32-vs-pm_message_t-in-drivers-mmcmtdscsi
2005-04-12 03:21:30.201545568 -0700
+++ 25-akpm/drivers/mtd/maps/sa1100-flash.c 2005-04-12 03:21:30.211544048
-0700
@@ -403,7 +403,7 @@ static int __exit sa1100_mtd_remove(stru
}
#ifdef CONFIG_PM
-static int sa1100_mtd_suspend(struct device *dev, u32 state, u32 level)
+static int sa1100_mtd_suspend(struct device *dev, pm_message_t state, u32
level)
{
struct sa_info *info = dev_get_drvdata(dev);
int ret = 0;
diff -puN drivers/scsi/mesh.c~fix-u32-vs-pm_message_t-in-drivers-mmcmtdscsi
drivers/scsi/mesh.c
--- 25/drivers/scsi/mesh.c~fix-u32-vs-pm_message_t-in-drivers-mmcmtdscsi
2005-04-12 03:21:30.203545264 -0700
+++ 25-akpm/drivers/scsi/mesh.c 2005-04-12 03:21:30.212543896 -0700
@@ -1757,7 +1757,7 @@ static void set_mesh_power(struct mesh_s
#ifdef CONFIG_PM
-static int mesh_suspend(struct macio_dev *mdev, u32 state)
+static int mesh_suspend(struct macio_dev *mdev, pm_message_t state)
{
struct mesh_state *ms = (struct mesh_state *)macio_get_drvdata(mdev);
unsigned long flags;
diff -puN drivers/scsi/nsp32.c~fix-u32-vs-pm_message_t-in-drivers-mmcmtdscsi
drivers/scsi/nsp32.c
--- 25/drivers/scsi/nsp32.c~fix-u32-vs-pm_message_t-in-drivers-mmcmtdscsi
2005-04-12 03:21:30.204545112 -0700
+++ 25-akpm/drivers/scsi/nsp32.c2005-04-12 03:21:30.215543440 -0700
@@ -3435,7 +3435,7 @@ static int nsp32_prom_read_bit(nsp32_hw_
#ifdef CONFIG_PM
/* Device suspended */
-static int nsp32_suspend(struct pci_dev *pdev, u32 state)
+static int nsp32_suspend(struct pci_dev *pdev, pm_message_t state)
{
struct Scsi_Host *host = pci_get_drvdata(pdev);
@@ -3443,7 +3443,7 @@ static int nsp32_suspend(struct pci_dev
pci_save_state (pdev);
pci_disable_device (pdev);
- pci_set_power_state(pdev, state);
+ pci_set_power_state(pdev,
Re: Kernel SCM saga.. (bk license?)
On Tue, 12 Apr 2005, Kedar Sovani wrote: >I was wondering if working on git, is in anyway, in violation of the >Bitkeeper license, which states that you cannot work on any other SCM >(SCM-like?) tool for "x" amount of time after using Bitkeeper ? Technically, yes, it is. However, as BitMover has given the community little other choice, I don't see how they could hold anyone to it. They'd have a hard time making that 1year clause stick given their abandonment of the free product and refusal to grant licenses to OSDL employees. Plus, there's nothing in the bkl specifically granting BitMover the right to revoke the license and thus use of BK/Free at their whim. They have every right to stop developing, supporting, and distributing BK/Free, but recending all BK/Free licenses just for spite does not appear to be within their legal rights. (Sorry Larry, but that's what you're doing. Tridge was working on taking your toys apart -- he does that, what can I say. He explicitly lied and said he would stop, but of course didn't. And then you got all pissed at OSDL for not smiting him when, technically, they can't -- an employer is not responsible for the actions of their employees on their own time, on their own property, unrelated to their employ. Sorry, but I know that one by heart :-)) --Ricky - 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] kallsyms C_SYMBOL_PREFIX support
At Tue, 12 Apr 2005 12:43:34 +0100,
Paulo Marques wrote:
>
> Yoshinori Sato wrote:
> > kallsyms does not consider SYMBOL_PREFIX of C.
> > Consequently do not work in architecture using prefix character (h8300,
> > v850) really.
> >
> > Because I can want to use this, I made a patch.
> > Please comment.
> >
> > [...]
>
> > @@ -177,6 +184,11 @@
> > "_SDA2_BASE_", /* ppc */
> > NULL };
> > int i;
> > + int offset = 1;
> > +
> > + /* skip prefix char */
> > + if (symbol_prefix_char && *(s->sym + 1) == symbol_prefix_char)
> > + offset++;
>
> maybe something like:
>
> char *sname;
> sname = s->sym + 1;
> if (symbol_prefix_char && *(s->sym + 1) == symbol_prefix_char)
> sname++;
>
> would avoid all the "(s->sym + offset)" below, turning them to just "sname".
>
> I know that it was "(s->sym + 1)" before, so its really not your fault,
> but you could take this opportunity to clean that up, too.
This one is fine.
> >
> > /* if --all-symbols is not specified, then symbols outside the text
> > * and inittext sections are discarded */
> > @@ -190,17 +202,17 @@
> > * they may get dropped in pass 2, which breaks the kallsyms
> > * rules.
> > */
> > - if ((s->addr == _etext && strcmp(s->sym + 1, "_etext")) ||
> > - (s->addr == _einittext && strcmp(s->sym + 1, "_einittext")))
> > + if ((s->addr == _etext && strcmp(s->sym + offset, "_etext")) ||
> > + (s->addr == _einittext && strcmp(s->sym + offset,
> > "_einittext")))
> > return 0;
> > }
> >
> > /* Exclude symbols which vary between passes. */
> > - if (strstr(s->sym + 1, "_compiled."))
> > + if (strstr(s->sym + offset, "_compiled."))
> > return 0;
> >
> > for (i = 0; special_symbols[i]; i++)
> > - if( strcmp(s->sym + 1, special_symbols[i]) == 0 )
> > + if( strcmp(s->sym + offset, special_symbols[i]) == 0 )
> > return 0;
> >
> > return 1;
> > @@ -225,9 +237,15 @@
>
> > [...]
> >
> > /* uncompress a compressed symbol. When this function is called, the best
> > table
> > @@ -665,6 +683,13 @@
> >
> > insert_real_symbols_in_table();
> >
> > + /* When valid symbol is not registered, exit to error */
> > + if (good_head.left == good_head.right &&
> > + bad_head.left == bad_head.right) {
> > + fprintf(stderr, "No valid symbol.\n");
> > + exit(1);
> > + }
> > +
> > optimize_result();
> > }
>
> This should only trigger if there are no symbols at all, or if there are
> some symbols that are considered invalid, and do not go into the final
> result.
>
> Maybe we should just do a return here instead of exit, so that even if
> this happens, kallsyms will still produce an empty result, that will at
> least allow the kernel to compile.
>
> It should give the error output to warn the user that there is something
> fishy, nevertheless. Maybe even a bigger message, since this should not
> happen at all, and if this triggers it means that something is seriously
> wrong.
Not surely possible normally.
But raise SEGV if there is not a check. I do not think that this is good action.
> > @@ -672,9 +697,21 @@
> > int
> > main(int argc, char **argv)
> > {
> > - if (argc == 2 && strcmp(argv[1], "--all-symbols") == 0)
> > - all_symbols = 1;
> > - else if (argc != 1)
> > + if (argc >= 2) {
>
> This test is unnecessary.
>
> > + int i;
> > + for (i = 1; i < argc; i++) {
> > + if(strcmp(argv[i], "--all-symbols") == 0)
> > + all_symbols = 1;
> > + else if (strncmp(argv[i], "--symbol-prefix=", 16) == 0)
> > {
> > + char *p = [i][16];
> > + /* skip quote */
> > + if ((*p == '"' && *(p+2) == '"') || (*p == '\''
> > && *(p+2) == '\''))
> > + p++;
> > + symbol_prefix_char = *p;
> > + } else
> > + usage();
> > + }
> > + } else if (argc != 1)
> > usage();
>
> and so is this.
>
> >
> > read_map(stdin);
> > @@ -683,4 +720,3 @@
> >
> > return 0;
> > }
>
> At least the patch seems to not affect architectures that don't use the
> "--symbol-prefix" option, so it should be harmless for most.
I think of the same thread which are an issue with it being worked if do not
appoint "--symbol-prefix".
Use CONFIG_ARCH and may judge it, but will it be good to refer to include/linux
here?
> Anyway, appart from the few comments, it has my acknowledge.
>
> --
> Paulo Marques - www.grupopie.com
>
> All that is necessary for the triumph of evil is that good men do nothing.
> Edmund Burke (1729 - 1797)
--
Yoshinori Sato
<[EMAIL PROTECTED]>
-
To unsubscribe from this list:
$B$J$s$H!) (B
$BCO0h8!:w$G6a=j$NH`=w$,8+$D$+$k!*(B $B%3%3$G!V%T%e%"$JM'C#!?M!W(B $B$r8!:w$7$h$&!*(B $Bhttp://www.getluck2.net/ $B"([EMAIL PROTECTED]@ZL5$7!#BN83B`2q<+M3!#B(%"%]!"B(%O%aN($,9b$$$N$G(B $B8zN($,NI$$%5%$%H!#(B - 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 113/198] Fix u32 vs. pm_message_t in x86-64
From: Pavel Machek <[EMAIL PROTECTED]>
I thought I'm done with fixing u32 vs. pm_message_t ... unfortunately that
turned out not to be the case... Here are fixes x86-64.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/x86_64/kernel/apic.c|2 +-
25-akpm/arch/x86_64/kernel/i8259.c |2 +-
25-akpm/arch/x86_64/kernel/io_apic.c |2 +-
25-akpm/arch/x86_64/kernel/nmi.c |2 +-
25-akpm/arch/x86_64/kernel/time.c|2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff -puN arch/x86_64/kernel/apic.c~fix-u32-vs-pm_message_t-in-x86-64
arch/x86_64/kernel/apic.c
--- 25/arch/x86_64/kernel/apic.c~fix-u32-vs-pm_message_t-in-x86-64
2005-04-12 03:21:30.700469720 -0700
+++ 25-akpm/arch/x86_64/kernel/apic.c 2005-04-12 03:21:30.710468200 -0700
@@ -457,7 +457,7 @@ static struct {
unsigned int apic_thmr;
} apic_pm_state;
-static int lapic_suspend(struct sys_device *dev, u32 state)
+static int lapic_suspend(struct sys_device *dev, pm_message_t state)
{
unsigned long flags;
diff -puN arch/x86_64/kernel/i8259.c~fix-u32-vs-pm_message_t-in-x86-64
arch/x86_64/kernel/i8259.c
--- 25/arch/x86_64/kernel/i8259.c~fix-u32-vs-pm_message_t-in-x86-64
2005-04-12 03:21:30.701469568 -0700
+++ 25-akpm/arch/x86_64/kernel/i8259.c 2005-04-12 03:21:30.710468200 -0700
@@ -409,7 +409,7 @@ static int i8259A_resume(struct sys_devi
return 0;
}
-static int i8259A_suspend(struct sys_device *dev, u32 state)
+static int i8259A_suspend(struct sys_device *dev, pm_message_t state)
{
save_ELCR(irq_trigger);
return 0;
diff -puN arch/x86_64/kernel/io_apic.c~fix-u32-vs-pm_message_t-in-x86-64
arch/x86_64/kernel/io_apic.c
--- 25/arch/x86_64/kernel/io_apic.c~fix-u32-vs-pm_message_t-in-x86-64
2005-04-12 03:21:30.703469264 -0700
+++ 25-akpm/arch/x86_64/kernel/io_apic.c2005-04-12 03:21:30.712467896
-0700
@@ -1712,7 +1712,7 @@ struct sysfs_ioapic_data {
};
static struct sysfs_ioapic_data * mp_ioapic_data[MAX_IO_APICS];
-static int ioapic_suspend(struct sys_device *dev, u32 state)
+static int ioapic_suspend(struct sys_device *dev, pm_message_t state)
{
struct IO_APIC_route_entry *entry;
struct sysfs_ioapic_data *data;
diff -puN arch/x86_64/kernel/nmi.c~fix-u32-vs-pm_message_t-in-x86-64
arch/x86_64/kernel/nmi.c
--- 25/arch/x86_64/kernel/nmi.c~fix-u32-vs-pm_message_t-in-x86-64
2005-04-12 03:21:30.704469112 -0700
+++ 25-akpm/arch/x86_64/kernel/nmi.c2005-04-12 03:21:30.712467896 -0700
@@ -248,7 +248,7 @@ void enable_timer_nmi_watchdog(void)
static int nmi_pm_active; /* nmi_active before suspend */
-static int lapic_nmi_suspend(struct sys_device *dev, u32 state)
+static int lapic_nmi_suspend(struct sys_device *dev, pm_message_t state)
{
nmi_pm_active = nmi_active;
disable_lapic_nmi_watchdog();
diff -puN arch/x86_64/kernel/time.c~fix-u32-vs-pm_message_t-in-x86-64
arch/x86_64/kernel/time.c
--- 25/arch/x86_64/kernel/time.c~fix-u32-vs-pm_message_t-in-x86-64
2005-04-12 03:21:30.706468808 -0700
+++ 25-akpm/arch/x86_64/kernel/time.c 2005-04-12 03:21:30.713467744 -0700
@@ -965,7 +965,7 @@ __setup("report_lost_ticks", time_setup)
static long clock_cmos_diff;
static unsigned long sleep_start;
-static int timer_suspend(struct sys_device *dev, u32 state)
+static int timer_suspend(struct sys_device *dev, pm_message_t state)
{
/*
* Estimate time zone so that set_time can update the clock
_
-
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 114/198] fix u32 vs. pm_message_t in drivers/macintosh
From: Pavel Machek <[EMAIL PROTECTED]>
I thought I'm done with fixing u32 vs. pm_message_t ... unfortunately that
turned out not to be the case as Russel King pointed out. Here are fixes for
drivers/macintosh.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/drivers/macintosh/macio_asic.c |2 +-
25-akpm/drivers/macintosh/mediabay.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff -puN
drivers/macintosh/macio_asic.c~fix-u32-vs-pm_message_t-in-drivers-macintosh
drivers/macintosh/macio_asic.c
---
25/drivers/macintosh/macio_asic.c~fix-u32-vs-pm_message_t-in-drivers-macintosh
2005-04-12 03:21:30.956430808 -0700
+++ 25-akpm/drivers/macintosh/macio_asic.c 2005-04-12 03:21:30.960430200
-0700
@@ -106,7 +106,7 @@ static void macio_device_shutdown(struct
drv->shutdown(macio_dev);
}
-static int macio_device_suspend(struct device *dev, u32 state)
+static int macio_device_suspend(struct device *dev, pm_message_t state)
{
struct macio_dev * macio_dev = to_macio_device(dev);
struct macio_driver * drv = to_macio_driver(dev->driver);
diff -puN
drivers/macintosh/mediabay.c~fix-u32-vs-pm_message_t-in-drivers-macintosh
drivers/macintosh/mediabay.c
---
25/drivers/macintosh/mediabay.c~fix-u32-vs-pm_message_t-in-drivers-macintosh
2005-04-12 03:21:30.957430656 -0700
+++ 25-akpm/drivers/macintosh/mediabay.c2005-04-12 03:21:30.961430048
-0700
@@ -704,7 +704,7 @@ static int __devinit media_bay_attach(st
}
-static int __pmac media_bay_suspend(struct macio_dev *mdev, u32 state)
+static int __pmac media_bay_suspend(struct macio_dev *mdev, pm_message_t state)
{
struct media_bay_info *bay = macio_get_drvdata(mdev);
_
-
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 116/198] u32 vs. pm_message_t in ppc and radeon
From: Pavel Machek <[EMAIL PROTECTED]>
This fixes pm_message_t vs. u32 confusion in ppc and aty (I *hope* that's
basically radeon code...). I was not able to test most of these, but I'm
not really changing anything, so it should be okay.
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/ppc64/kernel/of_device.c |2 +-
25-akpm/include/asm-ppc/macio.h |2 +-
25-akpm/include/asm-ppc/ocp.h |2 +-
25-akpm/include/asm-ppc/of_device.h |2 +-
drivers/video/aty/aty128fb.c |0
drivers/video/aty/atyfb_base.c|0
drivers/video/aty/radeonfb.h |0
7 files changed, 4 insertions(+), 4 deletions(-)
diff -puN arch/ppc64/kernel/of_device.c~u32-vs-pm_message_t-in-ppc-and-radeon
arch/ppc64/kernel/of_device.c
--- 25/arch/ppc64/kernel/of_device.c~u32-vs-pm_message_t-in-ppc-and-radeon
2005-04-12 03:21:31.445356480 -0700
+++ 25-akpm/arch/ppc64/kernel/of_device.c 2005-04-12 03:21:31.457354656
-0700
@@ -104,7 +104,7 @@ static int of_device_remove(struct devic
return 0;
}
-static int of_device_suspend(struct device *dev, u32 state)
+static int of_device_suspend(struct device *dev, pm_message_t state)
{
struct of_device * of_dev = to_of_device(dev);
struct of_platform_driver * drv = to_of_platform_driver(dev->driver);
diff -puN drivers/video/aty/aty128fb.c~u32-vs-pm_message_t-in-ppc-and-radeon
drivers/video/aty/aty128fb.c
diff -puN drivers/video/aty/atyfb_base.c~u32-vs-pm_message_t-in-ppc-and-radeon
drivers/video/aty/atyfb_base.c
diff -puN drivers/video/aty/radeonfb.h~u32-vs-pm_message_t-in-ppc-and-radeon
drivers/video/aty/radeonfb.h
diff -puN include/asm-ppc/macio.h~u32-vs-pm_message_t-in-ppc-and-radeon
include/asm-ppc/macio.h
--- 25/include/asm-ppc/macio.h~u32-vs-pm_message_t-in-ppc-and-radeon
2005-04-12 03:21:31.451355568 -0700
+++ 25-akpm/include/asm-ppc/macio.h 2005-04-12 03:21:31.457354656 -0700
@@ -126,7 +126,7 @@ struct macio_driver
int (*probe)(struct macio_dev* dev, const struct of_match *match);
int (*remove)(struct macio_dev* dev);
- int (*suspend)(struct macio_dev* dev, u32 state);
+ int (*suspend)(struct macio_dev* dev, pm_message_t state);
int (*resume)(struct macio_dev* dev);
int (*shutdown)(struct macio_dev* dev);
diff -puN include/asm-ppc/ocp.h~u32-vs-pm_message_t-in-ppc-and-radeon
include/asm-ppc/ocp.h
--- 25/include/asm-ppc/ocp.h~u32-vs-pm_message_t-in-ppc-and-radeon
2005-04-12 03:21:31.453355264 -0700
+++ 25-akpm/include/asm-ppc/ocp.h 2005-04-12 03:21:31.458354504 -0700
@@ -119,7 +119,7 @@ struct ocp_driver {
const struct ocp_device_id *id_table; /* NULL if wants all devices */
int (*probe) (struct ocp_device *dev);/* New device inserted
*/
void (*remove) (struct ocp_device *dev);/* Device removed (NULL
if not a hot-plug capable driver) */
- int (*suspend) (struct ocp_device *dev, u32 state);/* Device
suspended */
+ int (*suspend) (struct ocp_device *dev, pm_message_t state); /*
Device suspended */
int (*resume) (struct ocp_device *dev);/*
Device woken up */
struct device_driver driver;
};
diff -puN include/asm-ppc/of_device.h~u32-vs-pm_message_t-in-ppc-and-radeon
include/asm-ppc/of_device.h
--- 25/include/asm-ppc/of_device.h~u32-vs-pm_message_t-in-ppc-and-radeon
2005-04-12 03:21:31.454355112 -0700
+++ 25-akpm/include/asm-ppc/of_device.h 2005-04-12 03:21:31.458354504 -0700
@@ -55,7 +55,7 @@ struct of_platform_driver
int (*probe)(struct of_device* dev, const struct of_match *match);
int (*remove)(struct of_device* dev);
- int (*suspend)(struct of_device* dev, u32 state);
+ int (*suspend)(struct of_device* dev, pm_message_t state);
int (*resume)(struct of_device* dev);
int (*shutdown)(struct of_device* dev);
_
-
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 105/198] pm_message_t: more fixes in common and i386
From: Pavel Machek <[EMAIL PROTECTED]>
I thought I'm done with fixing u32 vs. pm_message_t ... unfortunately
that turned out not to be the case as Russel King pointed out. Here are
fixes for Documentation and common code (mainly system devices).
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/Documentation/driver-model/bus.txt|2 +-
25-akpm/Documentation/driver-model/driver.txt |4 ++--
25-akpm/arch/i386/kernel/apic.c |2 +-
25-akpm/arch/i386/kernel/i8259.c |2 +-
25-akpm/arch/i386/kernel/io_apic.c|2 +-
25-akpm/arch/i386/kernel/nmi.c|2 +-
25-akpm/arch/i386/kernel/time.c |2 +-
25-akpm/arch/i386/oprofile/nmi_int.c |2 +-
25-akpm/drivers/base/sys.c|3 ++-
25-akpm/include/linux/pci.h |5 +++--
25-akpm/include/linux/sysdev.h|5 +++--
11 files changed, 17 insertions(+), 14 deletions(-)
diff -puN arch/i386/kernel/apic.c~pm_message_t-more-fixes-in-common-and-i386
arch/i386/kernel/apic.c
--- 25/arch/i386/kernel/apic.c~pm_message_t-more-fixes-in-common-and-i386
2005-04-12 03:21:28.164855192 -0700
+++ 25-akpm/arch/i386/kernel/apic.c 2005-04-12 03:21:28.181852608 -0700
@@ -548,7 +548,7 @@ static struct {
unsigned int apic_thmr;
} apic_pm_state;
-static int lapic_suspend(struct sys_device *dev, u32 state)
+static int lapic_suspend(struct sys_device *dev, pm_message_t state)
{
unsigned long flags;
diff -puN arch/i386/kernel/i8259.c~pm_message_t-more-fixes-in-common-and-i386
arch/i386/kernel/i8259.c
--- 25/arch/i386/kernel/i8259.c~pm_message_t-more-fixes-in-common-and-i386
2005-04-12 03:21:28.165855040 -0700
+++ 25-akpm/arch/i386/kernel/i8259.c2005-04-12 03:21:28.182852456 -0700
@@ -262,7 +262,7 @@ static int i8259A_resume(struct sys_devi
return 0;
}
-static int i8259A_suspend(struct sys_device *dev, u32 state)
+static int i8259A_suspend(struct sys_device *dev, pm_message_t state)
{
save_ELCR(irq_trigger);
return 0;
diff -puN arch/i386/kernel/io_apic.c~pm_message_t-more-fixes-in-common-and-i386
arch/i386/kernel/io_apic.c
--- 25/arch/i386/kernel/io_apic.c~pm_message_t-more-fixes-in-common-and-i386
2005-04-12 03:21:28.167854736 -0700
+++ 25-akpm/arch/i386/kernel/io_apic.c 2005-04-12 03:21:28.190851240 -0700
@@ -2299,7 +2299,7 @@ struct sysfs_ioapic_data {
};
static struct sysfs_ioapic_data * mp_ioapic_data[MAX_IO_APICS];
-static int ioapic_suspend(struct sys_device *dev, u32 state)
+static int ioapic_suspend(struct sys_device *dev, pm_message_t state)
{
struct IO_APIC_route_entry *entry;
struct sysfs_ioapic_data *data;
diff -puN arch/i386/kernel/nmi.c~pm_message_t-more-fixes-in-common-and-i386
arch/i386/kernel/nmi.c
--- 25/arch/i386/kernel/nmi.c~pm_message_t-more-fixes-in-common-and-i386
2005-04-12 03:21:28.168854584 -0700
+++ 25-akpm/arch/i386/kernel/nmi.c 2005-04-12 03:21:28.191851088 -0700
@@ -265,7 +265,7 @@ void enable_timer_nmi_watchdog(void)
static int nmi_pm_active; /* nmi_active before suspend */
-static int lapic_nmi_suspend(struct sys_device *dev, u32 state)
+static int lapic_nmi_suspend(struct sys_device *dev, pm_message_t state)
{
nmi_pm_active = nmi_active;
disable_lapic_nmi_watchdog();
diff -puN arch/i386/kernel/time.c~pm_message_t-more-fixes-in-common-and-i386
arch/i386/kernel/time.c
--- 25/arch/i386/kernel/time.c~pm_message_t-more-fixes-in-common-and-i386
2005-04-12 03:21:28.170854280 -0700
+++ 25-akpm/arch/i386/kernel/time.c 2005-04-12 03:21:28.192850936 -0700
@@ -376,7 +376,7 @@ void notify_arch_cmos_timer(void)
static long clock_cmos_diff, sleep_start;
-static int timer_suspend(struct sys_device *dev, u32 state)
+static int timer_suspend(struct sys_device *dev, pm_message_t state)
{
/*
* Estimate time zone so that set_time can update the clock
diff -puN
arch/i386/oprofile/nmi_int.c~pm_message_t-more-fixes-in-common-and-i386
arch/i386/oprofile/nmi_int.c
--- 25/arch/i386/oprofile/nmi_int.c~pm_message_t-more-fixes-in-common-and-i386
2005-04-12 03:21:28.171854128 -0700
+++ 25-akpm/arch/i386/oprofile/nmi_int.c2005-04-12 03:21:28.192850936
-0700
@@ -32,7 +32,7 @@ static int nmi_enabled = 0;
#ifdef CONFIG_PM
-static int nmi_suspend(struct sys_device *dev, u32 state)
+static int nmi_suspend(struct sys_device *dev, pm_message_t state)
{
if (nmi_enabled == 1)
nmi_stop();
diff -puN
Documentation/driver-model/bus.txt~pm_message_t-more-fixes-in-common-and-i386
Documentation/driver-model/bus.txt
---
25/Documentation/driver-model/bus.txt~pm_message_t-more-fixes-in-common-and-i386
2005-04-12 03:21:28.172853976 -0700
+++ 25-akpm/Documentation/driver-model/bus.txt 2005-04-12 03:21:28.193850784
-0700
@@ -18,7 +18,7 @@ struct bus_type {
int
[patch 108/198] fix u32 vs. pm_message_t in pcmcia
From: Pavel Machek <[EMAIL PROTECTED]>
This fixes u32 vs. pm_message_t in pcmcia.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/drivers/pcmcia/au1000_generic.c |2 +-
25-akpm/drivers/pcmcia/hd64465_ss.c |2 +-
25-akpm/drivers/pcmcia/m32r_cfc.c |2 +-
25-akpm/drivers/pcmcia/m32r_pcc.c |2 +-
25-akpm/drivers/pcmcia/pxa2xx_base.c|2 +-
25-akpm/drivers/pcmcia/sa1100_generic.c |2 +-
25-akpm/drivers/pcmcia/sa_generic.c |2 +-
25-akpm/drivers/pcmcia/vrc4171_card.c |2 +-
8 files changed, 8 insertions(+), 8 deletions(-)
diff -puN drivers/pcmcia/au1000_generic.c~fix-u32-vs-pm_message_t-in-pcmcia
drivers/pcmcia/au1000_generic.c
--- 25/drivers/pcmcia/au1000_generic.c~fix-u32-vs-pm_message_t-in-pcmcia
2005-04-12 03:21:29.355674160 -0700
+++ 25-akpm/drivers/pcmcia/au1000_generic.c 2005-04-12 03:21:29.367672336
-0700
@@ -518,7 +518,7 @@ static int au1x00_drv_pcmcia_probe(struc
}
-static int au1x00_drv_pcmcia_suspend(struct device *dev, u32 state, u32 level)
+static int au1x00_drv_pcmcia_suspend(struct device *dev, pm_message_t state,
u32 level)
{
int ret = 0;
if (level == SUSPEND_SAVE_STATE)
diff -puN drivers/pcmcia/hd64465_ss.c~fix-u32-vs-pm_message_t-in-pcmcia
drivers/pcmcia/hd64465_ss.c
--- 25/drivers/pcmcia/hd64465_ss.c~fix-u32-vs-pm_message_t-in-pcmcia
2005-04-12 03:21:29.356674008 -0700
+++ 25-akpm/drivers/pcmcia/hd64465_ss.c 2005-04-12 03:21:29.368672184 -0700
@@ -845,7 +845,7 @@ static void hs_exit_socket(hs_socket_t *
local_irq_restore(flags);
}
-static int hd64465_suspend(struct device *dev, u32 state, u32 level)
+static int hd64465_suspend(struct device *dev, pm_message_t state, u32 level)
{
int ret = 0;
if (level == SUSPEND_SAVE_STATE)
diff -puN drivers/pcmcia/m32r_cfc.c~fix-u32-vs-pm_message_t-in-pcmcia
drivers/pcmcia/m32r_cfc.c
--- 25/drivers/pcmcia/m32r_cfc.c~fix-u32-vs-pm_message_t-in-pcmcia
2005-04-12 03:21:29.358673704 -0700
+++ 25-akpm/drivers/pcmcia/m32r_cfc.c 2005-04-12 03:21:29.369672032 -0700
@@ -743,7 +743,7 @@ static struct pccard_operations pcc_oper
/**/
-static int m32r_pcc_suspend(struct device *dev, u32 state, u32 level)
+static int m32r_pcc_suspend(struct device *dev, pm_message_t state, u32 level)
{
int ret = 0;
if (level == SUSPEND_SAVE_STATE)
diff -puN drivers/pcmcia/m32r_pcc.c~fix-u32-vs-pm_message_t-in-pcmcia
drivers/pcmcia/m32r_pcc.c
--- 25/drivers/pcmcia/m32r_pcc.c~fix-u32-vs-pm_message_t-in-pcmcia
2005-04-12 03:21:29.359673552 -0700
+++ 25-akpm/drivers/pcmcia/m32r_pcc.c 2005-04-12 03:21:29.370671880 -0700
@@ -696,7 +696,7 @@ static struct pccard_operations pcc_oper
/**/
-static int m32r_pcc_suspend(struct device *dev, u32 state, u32 level)
+static int m32r_pcc_suspend(struct device *dev, pm_message_t state, u32 level)
{
int ret = 0;
if (level == SUSPEND_SAVE_STATE)
diff -puN drivers/pcmcia/pxa2xx_base.c~fix-u32-vs-pm_message_t-in-pcmcia
drivers/pcmcia/pxa2xx_base.c
--- 25/drivers/pcmcia/pxa2xx_base.c~fix-u32-vs-pm_message_t-in-pcmcia
2005-04-12 03:21:29.360673400 -0700
+++ 25-akpm/drivers/pcmcia/pxa2xx_base.c2005-04-12 03:21:29.370671880
-0700
@@ -205,7 +205,7 @@ int pxa2xx_drv_pcmcia_probe(struct devic
}
EXPORT_SYMBOL(pxa2xx_drv_pcmcia_probe);
-static int pxa2xx_drv_pcmcia_suspend(struct device *dev, u32 state, u32 level)
+static int pxa2xx_drv_pcmcia_suspend(struct device *dev, pm_message_t state,
u32 level)
{
int ret = 0;
if (level == SUSPEND_SAVE_STATE)
diff -puN drivers/pcmcia/sa1100_generic.c~fix-u32-vs-pm_message_t-in-pcmcia
drivers/pcmcia/sa1100_generic.c
--- 25/drivers/pcmcia/sa1100_generic.c~fix-u32-vs-pm_message_t-in-pcmcia
2005-04-12 03:21:29.362673096 -0700
+++ 25-akpm/drivers/pcmcia/sa1100_generic.c 2005-04-12 03:21:29.370671880
-0700
@@ -75,7 +75,7 @@ static int sa11x0_drv_pcmcia_probe(struc
return ret;
}
-static int sa11x0_drv_pcmcia_suspend(struct device *dev, u32 state, u32 level)
+static int sa11x0_drv_pcmcia_suspend(struct device *dev, pm_message_t state,
u32 level)
{
int ret = 0;
if (level == SUSPEND_SAVE_STATE)
diff -puN drivers/pcmcia/sa_generic.c~fix-u32-vs-pm_message_t-in-pcmcia
drivers/pcmcia/sa_generic.c
--- 25/drivers/pcmcia/sa_generic.c~fix-u32-vs-pm_message_t-in-pcmcia
2005-04-12 03:21:29.363672944 -0700
+++ 25-akpm/drivers/pcmcia/sa_generic.c 2005-04-12 03:21:29.371671728
-0700
@@ -158,7 +158,7 @@ static int __devexit pcmcia_remove(struc
return 0;
}
-static int pcmcia_suspend(struct sa_dev *dev, u32 state)
+static int pcmcia_suspend(struct sa_dev *dev, pm_message_t state)
{
return pcmcia_socket_dev_suspend(>dev, state);
}
diff
[patch 101/198] x86_64: Rename the extended cpuid level field
From: "Andi Kleen" <[EMAIL PROTECTED]>
It was confusingly named.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
DESC
x86_64: Switch SMP bootup over to new CPU hotplug state machine
EDESC
From: "Andi Kleen" <[EMAIL PROTECTED]>
This will allow hotplug CPU in the future and in general cleans up a lot of
crufty code. It also should plug some races that the old hackish way
introduces. Remove one old race workaround in NMI watchdog setup that is not
needed anymore.
I removed the old total sum of bogomips reporting code. The brag value of
BogoMips has been greatly devalued in the last years on the open market.
Real CPU hotplug will need some more work, but the infrastructure for it is
there now.
One drawback: the new TSC sync algorithm is less accurate than before. The
old way of zeroing TSCs is too intrusive to do later. Instead the TSC of the
BP is duplicated now, which is less accurate.
Cc: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/x86_64/kernel/setup.c | 13 ++---
25-akpm/include/asm-x86_64/processor.h |2 +-
2 files changed, 7 insertions(+), 8 deletions(-)
diff -puN
arch/x86_64/kernel/setup.c~x86_64-rename-the-extended-cpuid-level-field
arch/x86_64/kernel/setup.c
--- 25/arch/x86_64/kernel/setup.c~x86_64-rename-the-extended-cpuid-level-field
2005-04-12 03:21:27.159008104 -0700
+++ 25-akpm/arch/x86_64/kernel/setup.c 2005-04-12 03:21:27.165007192 -0700
@@ -673,7 +673,7 @@ static int __init get_model_name(struct
{
unsigned int *v;
- if (c->x86_cpuid_level < 0x8004)
+ if (c->extended_cpuid_level < 0x8004)
return 0;
v = (unsigned int *) c->x86_model_id;
@@ -689,7 +689,7 @@ static void __init display_cacheinfo(str
{
unsigned int n, dummy, eax, ebx, ecx, edx;
- n = c->x86_cpuid_level;
+ n = c->extended_cpuid_level;
if (n >= 0x8005) {
cpuid(0x8005, , , , );
@@ -781,7 +781,7 @@ static int __init init_amd(struct cpuinf
}
display_cacheinfo(c);
- if (c->x86_cpuid_level >= 0x8008) {
+ if (c->extended_cpuid_level >= 0x8008) {
c->x86_num_cores = (cpuid_ecx(0x8008) & 0xff) + 1;
if (c->x86_num_cores & (c->x86_num_cores - 1))
c->x86_num_cores = 1;
@@ -841,7 +841,6 @@ static void __init detect_ht(struct cpui
if (smp_num_siblings & (smp_num_siblings - 1))
index_msb++;
- /* RED-PEN surely this must run in the non HT case too! -AK */
cpu_core_id[cpu] = phys_pkg_id(index_msb);
if (c->x86_num_cores > 1)
@@ -878,7 +877,7 @@ static void __init init_intel(struct cpu
unsigned n;
init_intel_cacheinfo(c);
- n = c->x86_cpuid_level;
+ n = c->extended_cpuid_level;
if (n >= 0x8008) {
unsigned eax = cpuid_eax(0x8008);
c->x86_virt_bits = (eax >> 8) & 0xff;
@@ -927,7 +926,7 @@ void __init early_identify_cpu(struct cp
c->x86_cache_alignment = c->x86_clflush_size;
c->x86_num_cores = 1;
c->x86_apicid = c == _cpu_data ? 0 : c - cpu_data;
- c->x86_cpuid_level = 0;
+ c->extended_cpuid_level = 0;
memset(>x86_capability, 0, sizeof c->x86_capability);
/* Get vendor name */
@@ -974,7 +973,7 @@ void __init identify_cpu(struct cpuinfo_
/* AMD-defined flags: level 0x8001 */
xlvl = cpuid_eax(0x8000);
- c->x86_cpuid_level = xlvl;
+ c->extended_cpuid_level = xlvl;
if ((xlvl & 0x) == 0x8000) {
if (xlvl >= 0x8001) {
c->x86_capability[1] = cpuid_edx(0x8001);
diff -puN
include/asm-x86_64/processor.h~x86_64-rename-the-extended-cpuid-level-field
include/asm-x86_64/processor.h
---
25/include/asm-x86_64/processor.h~x86_64-rename-the-extended-cpuid-level-field
2005-04-12 03:21:27.161007800 -0700
+++ 25-akpm/include/asm-x86_64/processor.h 2005-04-12 03:21:27.165007192
-0700
@@ -64,7 +64,7 @@ struct cpuinfo_x86 {
__u8x86_num_cores;
__u8x86_apicid;
__u32 x86_power;
- __u32 x86_cpuid_level;/* Max CPUID function supported */
+ __u32 extended_cpuid_level; /* Max extended CPUID function
supported */
unsigned long loops_per_jiffy;
} cacheline_aligned;
_
-
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 091/198] x86_64: Always use CPUID 80000008 to figure out MTRR address space size
From: "Andi Kleen" <[EMAIL PROTECTED]>
It doesn't make sense to only do this only for AMD K8.
This would support future CPUs with extended address spaces properly.
For i386 and x86-64
Cc: <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/i386/kernel/cpu/mtrr/main.c | 49 +--
1 files changed, 15 insertions(+), 34 deletions(-)
diff -puN
arch/i386/kernel/cpu/mtrr/main.c~x86_64-always-use-cpuid-8008-to-figure-out-mtrr
arch/i386/kernel/cpu/mtrr/main.c
---
25/arch/i386/kernel/cpu/mtrr/main.c~x86_64-always-use-cpuid-8008-to-figure-out-mtrr
2005-04-12 03:21:24.863357096 -0700
+++ 25-akpm/arch/i386/kernel/cpu/mtrr/main.c2005-04-12 03:21:24.867356488
-0700
@@ -614,40 +614,21 @@ static int __init mtrr_init(void)
mtrr_if = _mtrr_ops;
size_or_mask = 0xff00; /* 36 bits */
size_and_mask = 0x00f0;
-
- switch (boot_cpu_data.x86_vendor) {
- case X86_VENDOR_AMD:
- /* The original Athlon docs said that
- total addressable memory is 44 bits wide.
- It was not really clear whether its MTRRs
- follow this or not. (Read: 44 or 36 bits).
- However, "x86-64_overview.pdf" explicitly
- states that "previous implementations support
- 36 bit MTRRs" and also provides a way to
- query the width (in bits) of the physical
- addressable memory on the Hammer family.
-*/
- if (boot_cpu_data.x86 == 15
- && (cpuid_eax(0x8000) >= 0x8008)) {
- u32 phys_addr;
- phys_addr = cpuid_eax(0x8008) & 0xff;
- size_or_mask =
- ~((1 << (phys_addr - PAGE_SHIFT)) - 1);
- size_and_mask = ~size_or_mask & 0xfff0;
- }
- /* Athlon MTRRs use an Intel-compatible interface for
-* getting and setting */
- break;
- case X86_VENDOR_CENTAUR:
- if (boot_cpu_data.x86 == 6) {
- /* VIA Cyrix family have Intel style MTRRs, but
don't support PAE */
- size_or_mask = 0xfff0; /* 32 bits */
- size_and_mask = 0;
- }
- break;
-
- default:
- break;
+
+ /* This is an AMD specific MSR, but we assume(hope?) that
+ Intel will implement it to when they extend the address
+ bus of the Xeon. */
+ if (cpuid_eax(0x8000) >= 0x8008) {
+ u32 phys_addr;
+ phys_addr = cpuid_eax(0x8008) & 0xff;
+ size_or_mask = ~((1 << (phys_addr - PAGE_SHIFT)) - 1);
+ size_and_mask = ~size_or_mask & 0xfff0;
+ } else if (boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR &&
+ boot_cpu_data.x86 == 6) {
+ /* VIA C* family have Intel style MTRRs, but
+ don't support PAE */
+ size_or_mask = 0xfff0; /* 32 bits */
+ size_and_mask = 0;
}
} else {
switch (boot_cpu_data.x86_vendor) {
_
-
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 100/198] x86_64: Add acpi_skip_timer_override option
From: "Andi Kleen" <[EMAIL PROTECTED]>
Add acpi_skip_timer_override option. It was missing previously.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/x86_64/kernel/setup.c |4
1 files changed, 4 insertions(+)
diff -puN arch/x86_64/kernel/setup.c~x86_64-add-acpi_skip_timer_override-option
arch/x86_64/kernel/setup.c
--- 25/arch/x86_64/kernel/setup.c~x86_64-add-acpi_skip_timer_override-option
2005-04-12 03:21:26.946040480 -0700
+++ 25-akpm/arch/x86_64/kernel/setup.c 2005-04-12 03:21:26.950039872 -0700
@@ -327,6 +327,10 @@ static __init void parse_cmdline_early (
else if (!memcmp(from, "acpi=strict", 11)) {
acpi_strict = 1;
}
+#ifdef CONFIG_X86_IO_APIC
+ else if (!memcmp(from, "acpi_skip_timer_override", 24))
+ acpi_skip_timer_override = 1;
+#endif
#endif
if (!memcmp(from, "nolapic", 7) ||
_
-
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.12-rc2-mm3
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes: > On Tue, 2005-04-12 at 06:42 +0200, Juergen Kreileder wrote: >> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes: >> >>> On Tue, 2005-04-12 at 03:18 +0200, Juergen Kreileder wrote: Andrew Morton <[EMAIL PROTECTED]> writes: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/ I'm getting frequent lockups on my PowerMac G5 with rc2-mm3. 2.6.11-mm4 works fine but all 2.6.12 versions I've tried (all since -rc1-mm3) lock up randomly. The easiest way to reproduce the problem seems to be running Azareus. So it might be network related, but I'm not 100% sure about that, there was a least one deadlock with virtually no network usage. >>> >>> Hrm... I just noticed you have CONFIG_PREEMPT enabled... Can you >>> test without it and let me know if it makes a difference ? >> >> IIRC I had disabled that for rc2-mm2 and it didn't make a >> difference. I'll disable it again when I try older versions. >> >> I just got another crash with rc2-mm3. The crash was a bit >> different this time, I still could move the mouse pointer and the >> logs contained some info: > > Ok, what about non-mm ? (just plain rc2) I've tried older kernels now. rc1-mm1 locks up (no logs); plain rc1 seems to be OK (running fine for several hours now). Juergen -- Juergen Kreileder, Blackdown Java-Linux Team http://blog.blackdown.de/ - 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 098/198] x86_64: Final support for AMD dual core
From: "Andi Kleen" <[EMAIL PROTECTED]>
Clean up the code greatly. Now uses the infrastructure from the Intel dual
core patch Should fix a final bug noticed by Tyan of not detecting the nodes
correctly in some corner cases.
Patch for x86-64 and i386
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/i386/kernel/cpu/amd.c| 24 ++-
25-akpm/arch/i386/kernel/cpu/common.c |2
25-akpm/arch/x86_64/kernel/setup.c| 71 ++
3 files changed, 53 insertions(+), 44 deletions(-)
diff -puN arch/i386/kernel/cpu/amd.c~x86_64-final-support-for-amd-dual-core
arch/i386/kernel/cpu/amd.c
--- 25/arch/i386/kernel/cpu/amd.c~x86_64-final-support-for-amd-dual-core
2005-04-12 03:21:26.496108880 -0700
+++ 25-akpm/arch/i386/kernel/cpu/amd.c 2005-04-12 03:21:26.502107968 -0700
@@ -24,6 +24,9 @@ __asm__(".align 4\nvide: ret");
static void __init init_amd(struct cpuinfo_x86 *c)
{
+#ifdef CONFIG_SMP
+ int cpu = c == _cpu_data ? 0 : c - cpu_data;
+#endif
u32 l, h;
int mbytes = num_physpages >> (20-PAGE_SHIFT);
int r;
@@ -195,16 +198,17 @@ static void __init init_amd(struct cpuin
c->x86_num_cores = 1;
}
- detect_ht(c);
-
-#ifdef CONFIG_X86_HT
- /* AMD dual core looks like HT but isn't really. Hide it from the
- scheduler. This works around problems with the domain scheduler.
- Also probably gives slightly better scheduling and disables
- SMT nice which is harmful on dual core.
- TBD tune the domain scheduler for dual core. */
- if (cpu_has(c, X86_FEATURE_CMP_LEGACY))
- smp_num_siblings = 1;
+#ifdef CONFIG_SMP
+ /*
+* On a AMD dual core setup the lower bits of the APIC id
+* distingush the cores. Assumes number of cores is a power
+* of two.
+*/
+ if (c->x86_num_cores > 1) {
+ cpu_core_id[cpu] = cpu >> hweight32(c->x86_num_cores - 1);
+ printk(KERN_INFO "CPU %d(%d) -> Core %d\n",
+ cpu, c->x86_num_cores, cpu_core_id[cpu]);
+ }
#endif
}
diff -puN arch/i386/kernel/cpu/common.c~x86_64-final-support-for-amd-dual-core
arch/i386/kernel/cpu/common.c
--- 25/arch/i386/kernel/cpu/common.c~x86_64-final-support-for-amd-dual-core
2005-04-12 03:21:26.497108728 -0700
+++ 25-akpm/arch/i386/kernel/cpu/common.c 2005-04-12 03:21:26.503107816
-0700
@@ -437,7 +437,7 @@ void __init detect_ht(struct cpuinfo_x86
int index_msb, tmp;
int cpu = smp_processor_id();
- if (!cpu_has(c, X86_FEATURE_HT))
+ if (!cpu_has(c, X86_FEATURE_HT) || cpu_has(c, X86_FEATURE_CMP_LEGACY))
return;
cpuid(1, , , , );
diff -puN arch/x86_64/kernel/setup.c~x86_64-final-support-for-amd-dual-core
arch/x86_64/kernel/setup.c
--- 25/arch/x86_64/kernel/setup.c~x86_64-final-support-for-amd-dual-core
2005-04-12 03:21:26.499108424 -0700
+++ 25-akpm/arch/x86_64/kernel/setup.c 2005-04-12 03:21:26.504107664 -0700
@@ -715,14 +715,46 @@ static void __init display_cacheinfo(str
}
}
+#ifdef CONFIG_SMP
+/*
+ * On a AMD dual core setup the lower bits of the APIC id distingush the cores.
+ * Assumes number of cores is a power of two.
+ */
+static void __init amd_detect_cmp(struct cpuinfo_x86 *c)
+{
+#ifdef CONFIG_SMP
+ int cpu = c->x86_apicid;
+ int node = 0;
+ if (c->x86_num_cores == 1)
+ return;
+ cpu_core_id[cpu] = cpu >> hweight32(c->x86_num_cores - 1);
+
+#ifdef CONFIG_NUMA
+ /* When an ACPI SRAT table is available use the mappings from SRAT
+ instead. */
+ if (acpi_numa <= 0) {
+ node = cpu_core_id[cpu];
+ if (!node_online(node))
+ node = first_node(node_online_map);
+ cpu_to_node[cpu] = node;
+ } else {
+ node = cpu_to_node[cpu];
+ }
+#endif
+ printk(KERN_INFO "CPU %d(%d) -> Node %d -> Core %d\n",
+ cpu, c->x86_num_cores, node, cpu_core_id[cpu]);
+#endif
+}
+#else
+static void __init amd_detect_cmp(struct cpuinfo_x86 *c)
+{
+}
+#endif
static int __init init_amd(struct cpuinfo_x86 *c)
{
int r;
int level;
-#ifdef CONFIG_NUMA
- int cpu;
-#endif
/* Bit 31 in normal CPUID used for nonstandard 3DNow ID;
3DNow is IDd by bit 31 in extended CPUID (1*32+31) anyway */
@@ -750,21 +782,7 @@ static int __init init_amd(struct cpuinf
if (c->x86_num_cores & (c->x86_num_cores - 1))
c->x86_num_cores = 1;
-#ifdef CONFIG_NUMA
- /* On a dual core setup the lower bits of apic id
- distingush the cores. Fix up the CPU<->node mappings
- here based on that.
- Assumes number of cores is a
Re: Digi Neo 8: linux-2.6.12_r2 jsm driver
On Tue, 12 Apr 2005, Christoph Hellwig wrote: >On Tue, Apr 12, 2005 at 10:30:19AM -0500, Kilau, Scott wrote: >> However, when the copyright holder says "No, please don't add that >> code", >> and gives *GOOD* reasons why, you should respect that decision. > >You didn't not give a single good reason. Only political bullshit. As an outside observer, I think he's given you plenty of reason to not include this "hack". You, however, appear to only want to make a mess. >> So if I don't sign off on this change, does the matter? > >No. Could you possibly be any more of an ass? Don't bother answer that. This is entirely the attitude the denouncers of open source live for. It shows the complete lake of respect for the wishes of the maintainer(s). And it's even worse because, as you and various others state, if it's not in the kernel, it might as well not exist -- OSS, GPL, or not. So, what's the point of maintainers submitting code for inclusion in the kernel if they are going to be ignored the instant it's excepted? And the code's maintainer(s) and/or authors are the only ones that *can* submit new code. On one hand you're honoring their wishes, but then basically ignoring them the instant they "give" you their code. (If it's already GPL'd, there's nothing legally stopping the code from being included in the first place, so why must they ask for and/or ok inclusion? Answer: good will within the community which you are now pissing all over.) Am I the only one with his eyes open here? When I read the first reply from Scott, I was thinking, "why not just make it a config option? What's the big f***ing deal?" Make it a config option with help text pointing people to the "better" driver with improved features and support for that board. Or something as simple as "don't enable this if you're going to use this other dirver." The mere fact that you are unwilling to accept the desires of the maintainers subtracts substantial credability from the entire kernel development process and stands as a powerful deterent to getting manufacturers to submit drivers to the kernel. I'd be interested to hear Linus' take on this BS, but he's busy digging out of the bullshit some other stuborn, self-absorbed nut has buried him under. --Ricky "Kernel hacker for over 10 years" (but we know how much that's worth) - 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/
[SCM saga] An alternative to git
Linus,
Background:
---
The SCM problem is something I've been toying with for a while now on my own
because I wanted a distributed SCM tool, but didn't like one thing or another
about the existing projects. I thought monotone came very close to what I
wanted, but I didn't like the repository as a binary blob. So I've been
playing with my own prototype SCM project. I'd like to know what you think
of this approach, and maybe observations on this prototype implementation.
The Repository:
---
The on-disk format looks like this:
linux-repository
linux_kernel_repo/
|-- cache
|-- nodes ("revisions" would be a better name)
|-- patches
`-- tags
Files are created in the repository, and never modified once they are there.
Files are never deleted from the repository (with the possible exception of
stuff in the cache directory).
The patches directory contains .patch files, which are basically
[comments]
[diffstat]
[diff -aurN]
The nodes directory contains .node files, which have
[author] [date]
[.node .patch]
... (There can be 0 or more [node,patch] tuples.)
The tags directory contains files named like this:
[EMAIL PROTECTED]
(i.e: --.tag)
that contain the name of a node: .node
Then finally, there is the cache directory. With my current implementation,
this area is used to cache unpacked revisions of the source tree for diffing
and the like. The contents of these directories are hard-linked to conserve
some space.
Repository Implications:
This repository layout allows for a number of neat features.
Like git, you can use rsync to push and pull everything from one repository to
another. (You'll probably want to exclude (most of) the cache directory.)
But even better than that, you can pull a cached node from a repository into a
new repository, (such as linux-2.6.11) then pull your current head revision
and patches tracking back to that node, giving you a minimal repository with
just the history you want. Then when you're happy with what you have, push
it out.
That would let you have every revision of Linux known to man in a public
repository somewhere (kernel.org?), but you could keep a much reduced copy of
the repository on your working machine.
And we can do all of that without writing a dedicated SCM server: ftp, sftp,
rsync, etc. should all work.
Since the patches don't reference a node in themselves, they can be applied to
nodes other than the one they were created from. I believe this will allow
merging to work better than git would allow because we can track that the
same patch was applied to both of two lines of development that we're trying
to merge.
Current performance isn't very good, but I haven't really optimized it yet,
either. The numbers below are from commits to my repository on a 2.6GHz
Celeron w/768MB RAM.
Commit 2.6.095.31user 354.33system 9:07.91elapsed 82%CPU
Commit 2.6.161.53user 139.10system 6:01.20elapsed 55%CPU
Commit 2.6.221.48user 32.11system 1:02.36elapsed 85%CPU
Commit 2.6.322.40user 31.51system 1:00.45elapsed 89%CPU
Commit 2.6.426.41user 42.79system 1:17.18elapsed 89%CPU
Commit 2.6.524.16user 38.97system 1:13.21elapsed 86%CPU
Commit 2.6.625.37user 38.99system 1:15.28elapsed 85%CPU
Commit 2.6.735.83user 55.06system 1:46.76elapsed 85%CPU
Commit 2.6.843.94user 70.02system 2:27.96elapsed 77%CPU
Commit 2.6.943.90user 75.02system 2:42.44elapsed 73%CPU
Commit 2.6.10 52.16user 89.46system 3:03.61elapsed 77%CPU
Commit 2.6.11 54.47user 93.21system 3:25.57elapsed 71%CPU
Commit 2.6.11.1 14.06user 29.82system 1:04.60elapsed 67%CPU
Commit 2.6.11.2 5.42user 12.66system 0:32.30elapsed 56%CPU
Commit 2.6.11.3 1.91user 1.35system 0:06.49elapsed 50%CPU
Commit 2.6.11.4 1.82user 1.41system 0:06.84elapsed 47%CPU
Commit 2.6.11.5 1.91user 1.31system 0:04.26elapsed 75%CPU
Commit 2.6.11.6 1.89user 1.35system 0:06.94elapsed 46%CPU
Commit 2.6.11.7 2.07user 1.50system 0:07.44elapsed 48%CPU
Doing some profiling leads me to believe that there is a lot of room for
improvement for the nothing -> 2.6.0 and the 2.6.0 -> 2.6.1 commits. I
believe the 2.6.x commits can also be improved.
The 2.6.11.x commits tend to be <10 seconds. Which should be your common
case.
(Yes, I know git is blazingly fast, but are these numbers reasonable? How far
would they need to go to be reasonable? I think these are comparable to what
monotone would do, but they've done some optimization recently, so I'm
probably slower.)
As for disk usage (du -sck) of the above repository:
152 tags
168 nodes
354572 patches
Those three directories contain all the history.
1379704 cache
And that can be re-created from the nodes+patches.
There is no compression going on here, which would be an easy way to improve
that. I haven't implemented that yet though.
The Sandbox:
At the top directory of the sandbox, I have a .scm directory containing state
information such as current revision and
Re: [PATCH] ppc64: very basic desktop g5 sound support (#2)
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes: > This patch hacks the current PowerMac Alsa driver to add some basic > support of analog sound output to some desktop G5s. It has severe > limitations though: > > - Only 44100Khz 16 bits > - Only work on G5 models using a TAS3004 analog code, that is early >single CPU desktops and all dual CPU desktops at this date, but none >of the more recent ones like iMac G5. > - It does analog only, no digital/SPDIF support at all, no native >AC3 support On my PowerMac the internal speaker is now working, but unfortunately on the line-out I get nearly no output. I have pushed both the master and pcm control to the maximum and still barely hear anything. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." - 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, 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?
Replace weak attribute with define method as suggested.
Thanks,
Shaohua
---
linux-2.6.11-root/arch/i386/kernel/smpboot.c | 112 ---
linux-2.6.11-root/drivers/base/cpu.c |7 +
linux-2.6.11-root/include/asm-i386/smp.h |3
3 files changed, 93 insertions(+), 29 deletions(-)
diff -puN arch/i386/kernel/smpboot.c~warm_boot_cpu arch/i386/kernel/smpboot.c
--- linux-2.6.11/arch/i386/kernel/smpboot.c~warm_boot_cpu 2005-04-13
10:58:37.152081456 +0800
+++ linux-2.6.11-root/arch/i386/kernel/smpboot.c2005-04-13
10:58:37.159080392 +0800
@@ -80,6 +80,12 @@ cpumask_t cpu_callin_map;
cpumask_t cpu_callout_map;
static cpumask_t smp_commenced_mask;
+/* TSC's upper 32 bits can't be written in eariler CPU (before prescott), there
+ * is no way to resync one AP against BP. TBD: for prescott and above, we
+ * should use IA64's algorithm
+ */
+static int __devinitdata tsc_sync_disabled;
+
/* Per CPU bogomips and other parameters */
struct cpuinfo_x86 cpu_data[NR_CPUS] __cacheline_aligned;
@@ -416,7 +422,7 @@ static void __devinit smp_callin(void)
/*
* Synchronize the TSC with the BP
*/
- if (cpu_has_tsc && cpu_khz)
+ if (cpu_has_tsc && cpu_khz && !tsc_sync_disabled)
synchronize_tsc_ap();
}
@@ -809,6 +815,31 @@ static inline int alloc_cpu_id(void)
return cpu;
}
+#ifdef CONFIG_HOTPLUG_CPU
+static struct task_struct * __devinitdata cpu_idle_tasks[NR_CPUS];
+static inline struct task_struct * alloc_idle_task(int cpu)
+{
+ struct task_struct *idle;
+
+ if ((idle = cpu_idle_tasks[cpu]) != NULL) {
+ /* initialize thread_struct. we really want to avoid destroy
+* idle tread
+*/
+ idle->thread.esp = (unsigned long)(((struct pt_regs *)
+ (THREAD_SIZE + (unsigned long) idle->thread_info)) - 1);
+ init_idle(idle, cpu);
+ return idle;
+ }
+ idle = fork_idle(cpu);
+
+ if (!IS_ERR(idle))
+ cpu_idle_tasks[cpu] = idle;
+ return idle;
+}
+#else
+#define alloc_idle_task(cpu) fork_idle(cpu)
+#endif
+
static int __devinit do_boot_cpu(int apicid, int cpu)
/*
* NOTE - on most systems this is a PHYSICAL apic ID, but on multiquad
@@ -828,7 +859,7 @@ static int __devinit do_boot_cpu(int api
* We can't use kernel_thread since we must avoid to
* reschedule the child.
*/
- idle = fork_idle(cpu);
+ idle = alloc_idle_task(cpu);
if (IS_ERR(idle))
panic("failed fork for CPU %d", cpu);
idle->thread.eip = (unsigned long) start_secondary;
@@ -931,6 +962,55 @@ void cpu_exit_clear(void)
cpu_clear(cpu, smp_commenced_mask);
unmap_cpu_to_logical_apicid(cpu);
}
+
+struct warm_boot_cpu_info {
+ struct completion *complete;
+ int apicid;
+ int cpu;
+};
+
+static void __devinit do_warm_boot_cpu(void *p)
+{
+ struct warm_boot_cpu_info *info = p;
+ do_boot_cpu(info->apicid, info->cpu);
+ complete(info->complete);
+}
+
+int __devinit smp_prepare_cpu(int cpu)
+{
+ DECLARE_COMPLETION(done);
+ struct warm_boot_cpu_info info;
+ struct work_struct task;
+ int apicid, ret;
+
+ lock_cpu_hotplug();
+ apicid = x86_cpu_to_apicid[cpu];
+ if (apicid == BAD_APICID) {
+ ret = -ENODEV;
+ goto exit;
+ }
+
+ info.complete =
+ info.apicid = apicid;
+ info.cpu = cpu;
+ INIT_WORK(, do_warm_boot_cpu, );
+
+ tsc_sync_disabled = 1;
+
+ /* init low mem mapping */
+ memcpy(swapper_pg_dir, swapper_pg_dir + USER_PGD_PTRS,
+ sizeof(swapper_pg_dir[0]) * KERNEL_PGD_PTRS);
+ flush_tlb_all();
+ schedule_work();
+ wait_for_completion();
+
+ tsc_sync_disabled = 0;
+ zap_low_mappings();
+ ret = 0;
+exit:
+ unlock_cpu_hotplug();
+ return ret;
+}
#endif
static void smp_tune_scheduling (void)
@@ -1169,24 +1249,6 @@ void __devinit smp_prepare_boot_cpu(void
}
#ifdef CONFIG_HOTPLUG_CPU
-
-/* must be called with the cpucontrol mutex held */
-static int __devinit cpu_enable(unsigned int cpu)
-{
- /* get the target out of its holding state */
- per_cpu(cpu_state, cpu) = CPU_UP_PREPARE;
- wmb();
-
- /* wait for the processor to ack it. timeout? */
- while (!cpu_online(cpu))
- cpu_relax();
-
- fixup_irqs(cpu_online_map);
- /* counter the disable in fixup_irqs() */
- local_irq_enable();
- return 0;
-}
-
static void
remove_siblinginfo(int cpu)
{
@@ -1270,14
Re: [patch] sched: unlocked context-switches
David Mosberger wrote: On Tue, 12 Apr 2005 12:12:45 +1000, Nick Piggin <[EMAIL PROTECTED]> said: >> Now, Ingo says that the order is reversed with his patch, i.e., >> switch_mm() happens after switch_to(). That means flush_tlb_mm() >> may now see a current->active_mm which hasn't really been >> activated yet. Nick> If that did bother you, could you keep track of the actually Nick> activated mm in your arch code? Or would that involve more Nick> arch hooks and general ugliness in the scheduler? I'm sorry, but I don't see the point of this. We are already tracking care of ownership, just not atomically. What's the point of putting another level of (atomic) tracking on top of it. That seems exceedingly ugly. Well, you were worried about it not being atomic. So that would be the point, but I agree it would probably be exceedingly ugly if implemented. Nick - 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 3/6]init call cleanup
On Tue, 2005-04-12 at 17:32, Rolf Eike Beer wrote:
> Li Shaohua wrote:
> > Trival patch for CPU hotplug. In CPU identify part, only did cleaup
> for
> > intel CPUs. Need do for other CPUs if they support S3 SMP.
> >
> > @@ -405,7 +405,7 @@ void __init init_bsp_APIC(void)
> > apic_write_around(APIC_LVT1, value);
> > }
> >
> > -void __init setup_local_APIC (void)
> > +void __devinit setup_local_APIC (void)
> ^
>
> > {
> > unsigned long oldvalue, value, ver, maxlvt;
> >
>
> Please remove this space while you are at it.
>
> > @@ -556,7 +556,7 @@ void __init early_cpu_init(void)
> > * and IDT. We reload them nevertheless, this function acts as a
> > * 'CPU state barrier', nothing should get across.
> > */
> > -void __init cpu_init (void)
> > +void __devinit cpu_init (void)
> > {
> > int cpu = smp_processor_id();
> > struct tss_struct * t = _cpu(init_tss, cpu);
>
> This one too.
Removed the space at two places as suggested.
Thanks,
Shaohua
Trival patch for CPU hotplug. In CPU identify part, only did cleaup for intel
CPUs. Need do for other CPUs if they support S3 SMP.
---
linux-2.6.11-root/arch/i386/kernel/apic.c| 14 +++
linux-2.6.11-root/arch/i386/kernel/cpu/common.c | 30 +++
linux-2.6.11-root/arch/i386/kernel/cpu/intel.c | 12 +++---
linux-2.6.11-root/arch/i386/kernel/cpu/intel_cacheinfo.c |4 +-
linux-2.6.11-root/arch/i386/kernel/cpu/mcheck/mce.c |4 +-
linux-2.6.11-root/arch/i386/kernel/cpu/mcheck/p4.c |4 +-
linux-2.6.11-root/arch/i386/kernel/cpu/mcheck/p5.c |2 -
linux-2.6.11-root/arch/i386/kernel/cpu/mcheck/p6.c |2 -
linux-2.6.11-root/arch/i386/kernel/process.c |2 -
linux-2.6.11-root/arch/i386/kernel/setup.c |2 -
linux-2.6.11-root/arch/i386/kernel/smpboot.c | 18 -
linux-2.6.11-root/arch/i386/kernel/timers/timer_tsc.c|2 -
12 files changed, 48 insertions(+), 48 deletions(-)
diff -puN arch/i386/kernel/apic.c~init_call_cleanup arch/i386/kernel/apic.c
--- linux-2.6.11/arch/i386/kernel/apic.c~init_call_cleanup 2005-04-12
10:37:07.0 +0800
+++ linux-2.6.11-root/arch/i386/kernel/apic.c 2005-04-13 10:57:55.817365288
+0800
@@ -405,7 +405,7 @@ void __init init_bsp_APIC(void)
apic_write_around(APIC_LVT1, value);
}
-void __init setup_local_APIC (void)
+void __devinit setup_local_APIC(void)
{
unsigned long oldvalue, value, ver, maxlvt;
@@ -676,7 +676,7 @@ static struct sys_device device_lapic =
.cls= _sysclass,
};
-static void __init apic_pm_activate(void)
+static void __devinit apic_pm_activate(void)
{
apic_pm_state.active = 1;
}
@@ -877,7 +877,7 @@ fake_ioapic_page:
* but we do not accept timer interrupts yet. We only allow the BP
* to calibrate.
*/
-static unsigned int __init get_8254_timer_count(void)
+static unsigned int __devinit get_8254_timer_count(void)
{
extern spinlock_t i8253_lock;
unsigned long flags;
@@ -896,7 +896,7 @@ static unsigned int __init get_8254_time
}
/* next tick in 8254 can be caught by catching timer wraparound */
-static void __init wait_8254_wraparound(void)
+static void __devinit wait_8254_wraparound(void)
{
unsigned int curr_count, prev_count;
@@ -916,7 +916,7 @@ static void __init wait_8254_wraparound(
* Default initialization for 8254 timers. If we use other timers like HPET,
* we override this later
*/
-void (*wait_timer_tick)(void) __initdata = wait_8254_wraparound;
+void (*wait_timer_tick)(void) __devinitdata = wait_8254_wraparound;
/*
* This function sets up the local APIC timer, with a timeout of
@@ -952,7 +952,7 @@ static void __setup_APIC_LVTT(unsigned i
apic_write_around(APIC_TMICT, clocks/APIC_DIVISOR);
}
-static void __init setup_APIC_timer(unsigned int clocks)
+static void __devinit setup_APIC_timer(unsigned int clocks)
{
unsigned long flags;
@@ -1065,7 +1065,7 @@ void __init setup_boot_APIC_clock(void)
local_irq_enable();
}
-void __init setup_secondary_APIC_clock(void)
+void __devinit setup_secondary_APIC_clock(void)
{
setup_APIC_timer(calibration_result);
}
diff -puN arch/i386/kernel/cpu/common.c~init_call_cleanup
arch/i386/kernel/cpu/common.c
--- linux-2.6.11/arch/i386/kernel/cpu/common.c~init_call_cleanup
2005-04-12 10:37:07.0 +0800
+++ linux-2.6.11-root/arch/i386/kernel/cpu/common.c 2005-04-13
10:58:25.777810608 +0800
@@ -24,9 +24,9 @@ EXPORT_PER_CPU_SYMBOL(cpu_gdt_table);
DEFINE_PER_CPU(unsigned char, cpu_16bit_stack[CPU_16BIT_STACK_SIZE]);
EXPORT_PER_CPU_SYMBOL(cpu_16bit_stack);
-static int cachesize_override __initdata = -1;
-static int disable_x86_fxsr __initdata = 0;
-static int disable_x86_serial_nr __initdata = 1;
+static int cachesize_override __devinitdata = -1;
+static int disable_x86_fxsr __devinitdata = 0;
+static int
[patch 096/198] x86_64: Remove duplicated syscall entry.
From: "Andi Kleen" <[EMAIL PROTECTED]> Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- 25-akpm/include/asm-x86_64/unistd.h |2 -- 1 files changed, 2 deletions(-) diff -puN include/asm-x86_64/unistd.h~x86_64-remove-duplicated-syscall-entry include/asm-x86_64/unistd.h --- 25/include/asm-x86_64/unistd.h~x86_64-remove-duplicated-syscall-entry 2005-04-12 03:21:25.949192024 -0700 +++ 25-akpm/include/asm-x86_64/unistd.h 2005-04-12 03:21:25.952191568 -0700 @@ -533,8 +533,6 @@ __SYSCALL(__NR_tgkill, sys_tgkill) __SYSCALL(__NR_utimes, sys_utimes) #define __NR_vserver 236 __SYSCALL(__NR_vserver, sys_ni_syscall) -#define __NR_vserver 236 -__SYSCALL(__NR_vserver, sys_ni_syscall) #define __NR_mbind 237 __SYSCALL(__NR_mbind, sys_mbind) #define __NR_set_mempolicy 238 _ - 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 089/198] x86_64: Use the extended RIP MSR for machine check reporting if available.
From: "Andi Kleen" <[EMAIL PROTECTED]>
They are rumoured to be much more reliable than the RIP in the stack frame on
P4s.
This is a borderline case because the code is very simple. Please note there
are no plans to add support for all the MCE register MSRs.
Cc: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/x86_64/kernel/mce.c | 30 ++
1 files changed, 22 insertions(+), 8 deletions(-)
diff -puN
arch/x86_64/kernel/mce.c~x86_64-use-the-extended-rip-msr-for-machine-check
arch/x86_64/kernel/mce.c
---
25/arch/x86_64/kernel/mce.c~x86_64-use-the-extended-rip-msr-for-machine-check
2005-04-12 03:21:24.452419568 -0700
+++ 25-akpm/arch/x86_64/kernel/mce.c2005-04-12 03:21:24.455419112 -0700
@@ -33,6 +33,7 @@ static int banks;
static unsigned long bank[NR_BANKS] = { [0 ... NR_BANKS-1] = ~0UL };
static unsigned long console_logged;
static int notify_user;
+static int rip_msr;
/*
* Lockless MCE logging infrastructure.
@@ -124,6 +125,23 @@ static int mce_available(struct cpuinfo_
test_bit(X86_FEATURE_MCA, >x86_capability);
}
+static inline void mce_get_rip(struct mce *m, struct pt_regs *regs)
+{
+ if (regs && (m->mcgstatus & MCG_STATUS_RIPV)) {
+ m->rip = regs->rip;
+ m->cs = regs->cs;
+ } else {
+ m->rip = 0;
+ m->cs = 0;
+ }
+ if (rip_msr) {
+ /* Assume the RIP in the MSR is exact. Is this true? */
+ m->mcgstatus |= MCG_STATUS_EIPV;
+ rdmsrl(rip_msr, m->rip);
+ m->cs = 0;
+ }
+}
+
/*
* The actual machine check handler
*/
@@ -176,14 +194,7 @@ void do_machine_check(struct pt_regs * r
if (m.status & MCI_STATUS_ADDRV)
rdmsrl(MSR_IA32_MC0_ADDR + i*4, m.addr);
- if (regs && (m.mcgstatus & MCG_STATUS_RIPV)) {
- m.rip = regs->rip;
- m.cs = regs->cs;
- } else {
- m.rip = 0;
- m.cs = 0;
- }
-
+ mce_get_rip(, regs);
if (error_code != -1)
rdtscll(m.tsc);
wrmsrl(MSR_IA32_MC0_STATUS + i*4, 0);
@@ -296,6 +307,9 @@ static void mce_init(void *dummy)
printk(KERN_INFO "MCE: warning: using only %d banks\n", banks);
banks = NR_BANKS;
}
+ /* Use accurate RIP reporting if available. */
+ if ((cap & (1<<9)) && ((cap >> 16) & 0xff) >= 9)
+ rip_msr = MSR_IA32_MCG_EIP;
/* Log the machine checks left over from the previous reset.
This also clears all registers */
_
-
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 093/198] x86_64: Port over e820 gap detection from i386
From: "Andi Kleen" <[EMAIL PROTECTED]>
Look for gaps in the e820 memory map to put PCI resources in.
This hopefully fixes problems with the PCI code assigning 32bit BARs MMIO
resources which are >32bit.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/x86_64/kernel/e820.c | 59 +
25-akpm/arch/x86_64/kernel/setup.c | 12 ---
25-akpm/include/asm-x86_64/e820.h |1
3 files changed, 61 insertions(+), 11 deletions(-)
diff -puN
arch/x86_64/kernel/e820.c~x86_64-port-over-e820-gap-detection-from-i386
arch/x86_64/kernel/e820.c
--- 25/arch/x86_64/kernel/e820.c~x86_64-port-over-e820-gap-detection-from-i386
2005-04-12 03:21:25.287292648 -0700
+++ 25-akpm/arch/x86_64/kernel/e820.c 2005-04-12 03:21:25.293291736 -0700
@@ -511,3 +511,62 @@ void __init parse_memopt(char *p, char *
end_user_pfn >>= PAGE_SHIFT;
}
+unsigned long pci_mem_start = 0xaeedbabe;
+
+/*
+ * Search for the biggest gap in the low 32 bits of the e820
+ * memory space. We pass this space to PCI to assign MMIO resources
+ * for hotplug or unconfigured devices in.
+ * Hopefully the BIOS let enough space left.
+ */
+__init void e820_setup_gap(void)
+{
+ unsigned long gapstart, gapsize;
+ unsigned long last;
+ int i;
+ int found = 0;
+
+ last = 0x1ull;
+ gapstart = 0x1000;
+ gapsize = 0x40;
+ i = e820.nr_map;
+ while (--i >= 0) {
+ unsigned long long start = e820.map[i].addr;
+ unsigned long long end = start + e820.map[i].size;
+
+ /*
+* Since "last" is at most 4GB, we know we'll
+* fit in 32 bits if this condition is true
+*/
+ if (last > end) {
+ unsigned long gap = last - end;
+
+ if (gap > gapsize) {
+ gapsize = gap;
+ gapstart = end;
+ found = 1;
+ }
+ }
+ if (start < last)
+ last = start;
+ }
+
+ if (!found) {
+ gapstart = (end_pfn << PAGE_SHIFT) + 1024*1024;
+ printk(KERN_ERR "PCI: Warning: Cannot find a gap in the 32bit
address range\n"
+ KERN_ERR "PCI: Unassigned devices with 32bit resource
registers may break!\n");
+ }
+
+ /*
+* Start allocating dynamic PCI memory a bit into the gap,
+* aligned up to the nearest megabyte.
+*
+* Question: should we try to pad it up a bit (do something
+* like " + (gapsize >> 3)" in there too?). We now have the
+* technology.
+*/
+ pci_mem_start = (gapstart + 0xf) & ~0xf;
+
+ printk(KERN_INFO "Allocating PCI resources starting at %lx (gap:
%lx:%lx)\n",
+ pci_mem_start, gapstart, gapsize);
+}
diff -puN
arch/x86_64/kernel/setup.c~x86_64-port-over-e820-gap-detection-from-i386
arch/x86_64/kernel/setup.c
--- 25/arch/x86_64/kernel/setup.c~x86_64-port-over-e820-gap-detection-from-i386
2005-04-12 03:21:25.288292496 -0700
+++ 25-akpm/arch/x86_64/kernel/setup.c 2005-04-12 03:21:25.294291584 -0700
@@ -76,9 +76,6 @@ int __initdata acpi_force = 0;
int acpi_numa __initdata;
-/* For PCI or other memory-mapped resources */
-unsigned long pci_mem_start = 0x1000;
-
/* Boot loader ID as an integer, for the benefit of proc_dointvec */
int bootloader_type;
@@ -495,7 +492,6 @@ static void __init reserve_ebda_region(v
void __init setup_arch(char **cmdline_p)
{
- unsigned long low_mem_size;
unsigned long kernel_end;
ROOT_DEV = old_decode_dev(ORIG_ROOT_DEV);
@@ -654,13 +650,7 @@ void __init setup_arch(char **cmdline_p)
request_resource(_resource, _io_resources[i]);
}
- /* Will likely break when you have unassigned resources with more
- than 4GB memory and bridges that don't support more than 4GB.
- Doing it properly would require to use pci_alloc_consistent
- in this case. */
- low_mem_size = ((end_pfn << PAGE_SHIFT) + 0xf) & ~0xf;
- if (low_mem_size > pci_mem_start)
- pci_mem_start = low_mem_size;
+ e820_setup_gap();
#ifdef CONFIG_GART_IOMMU
iommu_hole_init();
diff -puN
include/asm-x86_64/e820.h~x86_64-port-over-e820-gap-detection-from-i386
include/asm-x86_64/e820.h
--- 25/include/asm-x86_64/e820.h~x86_64-port-over-e820-gap-detection-from-i386
2005-04-12 03:21:25.289292344 -0700
+++ 25-akpm/include/asm-x86_64/e820.h 2005-04-12 03:21:25.294291584 -0700
@@ -50,6 +50,7 @@ extern void e820_print_map(char *who);
extern int e820_mapped(unsigned long start, unsigned long end, unsigned type);
extern void e820_bootmem_free(pg_data_t *pgdat, unsigned long start,unsigned
long end);
+extern void
Re: [patch 2/3]: entry.S trap return fixes
Hello. Andrew Morton wrote: do_debug() returns void, do_int3() too when This patch is applicable to the mainline kernel, is it not? I think so - with some offsets it applies and looks valid. - 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 094/198] x86_64: Use the e820 hole to map the IOMMU/AGP aperture
From: "Andi Kleen" <[EMAIL PROTECTED]>
This might save memory on some Opteron systems without AGP bridge.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/x86_64/kernel/aperture.c | 41 --
1 files changed, 30 insertions(+), 11 deletions(-)
diff -puN
arch/x86_64/kernel/aperture.c~x86_64-use-the-e820-hole-to-map-the-iommu-agp-aperture
arch/x86_64/kernel/aperture.c
---
25/arch/x86_64/kernel/aperture.c~x86_64-use-the-e820-hole-to-map-the-iommu-agp-aperture
2005-04-12 03:21:25.519257384 -0700
+++ 25-akpm/arch/x86_64/kernel/aperture.c 2005-04-12 03:21:25.522256928
-0700
@@ -33,11 +33,13 @@ int fallback_aper_force __initdata = 0;
int fix_aperture __initdata = 1;
-/* This code runs before the PCI subsystem is initialized, so just
- access the northbridge directly. */
-
#define NB_ID_3 (PCI_VENDOR_ID_AMD | (0x1103<<16))
+static struct resource aper_res = {
+ .name = "Aperture",
+ .flags = IORESOURCE_MEM,
+};
+
static u32 __init allocate_aperture(void)
{
#ifdef CONFIG_DISCONTIGMEM
@@ -53,11 +55,24 @@ static u32 __init allocate_aperture(void
aper_size = (32 * 1024 * 1024) << fallback_aper_order;
/*
-* Aperture has to be naturally aligned. This means an 2GB aperture
won't
-* have much chances to find a place in the lower 4GB of memory.
-* Unfortunately we cannot move it up because that would make the
-* IOMMU useless.
+* Aperture has to be naturally aligned. This means an 2GB
+* aperture won't have much chances to find a place in the
+* lower 4GB of memory. Unfortunately we cannot move it up
+* because that would make the IOMMU useless.
*/
+
+ /* First try to find some free unused space */
+ if (!allocate_resource(_resource, _res,
+ aper_size,
+ 0, 0x,
+ aper_size,
+ NULL, NULL)) {
+ printk(KERN_INFO "Putting aperture at %lx-%lx\n",
+ aper_res.start, aper_res.end);
+ return aper_res.start;
+ }
+
+ /* No free space found. Go on to waste some memory... */
p = __alloc_bootmem_node(nd0, aper_size, aper_size, 0);
if (!p || __pa(p)+aper_size > 0x) {
printk("Cannot allocate aperture memory hole (%p,%uK)\n",
@@ -66,7 +81,7 @@ static u32 __init allocate_aperture(void
free_bootmem_node(nd0, (unsigned long)p, aper_size);
return 0;
}
- printk("Mapping aperture over %d KB of RAM @ %lx\n",
+ printk("Mapping aperture over %d KB of precious RAM @ %lx\n",
aper_size >> 10, __pa(p));
return (u32)__pa(p);
}
@@ -87,10 +102,16 @@ static int __init aperture_valid(char *n
printk("Aperture from %s pointing to e820 RAM.
Ignoring.\n",name);
return 0;
}
+ /* Don't check the resource here because the aperture is usually
+ in an e820 reserved area, and we allocated these earlier. */
return 1;
}
-/* Find a PCI capability */
+/*
+ * Find a PCI capability.
+ * This code runs before the PCI subsystem is initialized, so just
+ * access the northbridge directly.
+ */
static __u32 __init find_cap(int num, int slot, int func, int cap)
{
u8 pos;
@@ -255,8 +276,6 @@ void __init iommu_hole_init(void)
fallback_aper_force) {
printk("Your BIOS doesn't leave a aperture memory hole\n");
printk("Please enable the IOMMU option in the BIOS setup\n");
- printk("This costs you %d MB of RAM\n",
- 32 << fallback_aper_order);
aper_order = fallback_aper_order;
aper_alloc = allocate_aperture();
_
-
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 088/198] x86_64: Correct wrong comment in local.h
From: "Andi Kleen" <[EMAIL PROTECTED]> local_t is actually a win over atomic_t because it does not need lock prefixes. Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- 25-akpm/include/asm-x86_64/local.h |3 ++- 1 files changed, 2 insertions(+), 1 deletion(-) diff -puN include/asm-x86_64/local.h~x86_64-correct-wrong-comment-in-localh include/asm-x86_64/local.h --- 25/include/asm-x86_64/local.h~x86_64-correct-wrong-comment-in-localh 2005-04-12 03:21:24.242451488 -0700 +++ 25-akpm/include/asm-x86_64/local.h 2005-04-12 03:21:24.245451032 -0700 @@ -45,7 +45,8 @@ static __inline__ void local_sub(unsigne :"ir" (i), "m" (v->counter)); } -/* On x86, these are no better than the atomic variants. */ +/* On x86-64 these are better than the atomic variants on SMP kernels + because they dont use a lock prefix. */ #define __local_inc(l) local_inc(l) #define __local_dec(l) local_dec(l) #define __local_add(i,l) local_add((i),(l)) _ - 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 090/198] x86_64: Remove excessive stack allocation in MCE code with large NR_CPUS
From: "Andi Kleen" <[EMAIL PROTECTED]>
Remove excessive stack allocation in MCE code with large NR_CPUS
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/x86_64/kernel/mce.c |8 +++-
1 files changed, 7 insertions(+), 1 deletion(-)
diff -puN
arch/x86_64/kernel/mce.c~x86_64-remove-excessive-stack-allocation-in-mce-code
arch/x86_64/kernel/mce.c
---
25/arch/x86_64/kernel/mce.c~x86_64-remove-excessive-stack-allocation-in-mce-code
2005-04-12 03:21:24.658388256 -0700
+++ 25-akpm/arch/x86_64/kernel/mce.c2005-04-12 03:21:24.661387800 -0700
@@ -379,18 +379,23 @@ static void collect_tscs(void *data)
static ssize_t mce_read(struct file *filp, char __user *ubuf, size_t usize,
loff_t *off)
{
- unsigned long cpu_tsc[NR_CPUS];
+ unsigned long *cpu_tsc;
static DECLARE_MUTEX(mce_read_sem);
unsigned next;
char __user *buf = ubuf;
int i, err;
+ cpu_tsc = kmalloc(NR_CPUS * sizeof(long), GFP_KERNEL);
+ if (!cpu_tsc)
+ return -ENOMEM;
+
down(_read_sem);
next = rcu_dereference(mcelog.next);
/* Only supports full reads right now */
if (*off != 0 || usize < MCE_LOG_LEN*sizeof(struct mce)) {
up(_read_sem);
+ kfree(cpu_tsc);
return -EINVAL;
}
@@ -421,6 +426,7 @@ static ssize_t mce_read(struct file *fil
}
}
up(_read_sem);
+ kfree(cpu_tsc);
return err ? -EFAULT : buf - ubuf;
}
_
-
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 092/198] x86_64-always-use-cpuid-80000008-to-figure-out-mtrr fix
From: "Siddha, Suresh B" <[EMAIL PROTECTED]>
We need to use the size_and_mask in set_mtrr_var_ranges(which is called
while programming MTRR's for AP's
Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/i386/kernel/cpu/mtrr/generic.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff -puN
arch/i386/kernel/cpu/mtrr/generic.c~x86_64-always-use-cpuid-8008-to-figure-out-mtrr-fix
arch/i386/kernel/cpu/mtrr/generic.c
---
25/arch/i386/kernel/cpu/mtrr/generic.c~x86_64-always-use-cpuid-8008-to-figure-out-mtrr-fix
2005-04-12 03:21:25.075324872 -0700
+++ 25-akpm/arch/i386/kernel/cpu/mtrr/generic.c 2005-04-12 03:21:25.078324416
-0700
@@ -193,7 +193,8 @@ static int set_mtrr_var_ranges(unsigned
rdmsr(MTRRphysBase_MSR(index), lo, hi);
if ((vr->base_lo & 0xf0ffUL) != (lo & 0xf0ffUL)
- || (vr->base_hi & 0xfUL) != (hi & 0xfUL)) {
+ || (vr->base_hi & (size_and_mask >> (32 - PAGE_SHIFT))) !=
+ (hi & (size_and_mask >> (32 - PAGE_SHIFT {
mtrr_wrmsr(MTRRphysBase_MSR(index), vr->base_lo, vr->base_hi);
changed = TRUE;
}
@@ -201,7 +202,8 @@ static int set_mtrr_var_ranges(unsigned
rdmsr(MTRRphysMask_MSR(index), lo, hi);
if ((vr->mask_lo & 0xf800UL) != (lo & 0xf800UL)
- || (vr->mask_hi & 0xfUL) != (hi & 0xfUL)) {
+ || (vr->mask_hi & (size_and_mask >> (32 - PAGE_SHIFT))) !=
+ (hi & (size_and_mask >> (32 - PAGE_SHIFT {
mtrr_wrmsr(MTRRphysMask_MSR(index), vr->mask_lo, vr->mask_hi);
changed = TRUE;
}
_
-
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 087/198] x86_64: Don't assume future AMD CPUs have K8 compatible performance counters
From: "Andi Kleen" <[EMAIL PROTECTED]>
The NMI watchdog code did this incorrectly
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/x86_64/kernel/nmi.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN
arch/x86_64/kernel/nmi.c~x86_64-dont-assume-future-amd-cpus-have-k8-compatible
arch/x86_64/kernel/nmi.c
---
25/arch/x86_64/kernel/nmi.c~x86_64-dont-assume-future-amd-cpus-have-k8-compatible
2005-04-12 03:21:23.910501952 -0700
+++ 25-akpm/arch/x86_64/kernel/nmi.c2005-04-12 03:21:23.913501496 -0700
@@ -336,7 +336,7 @@ void setup_apic_nmi_watchdog(void)
{
switch (boot_cpu_data.x86_vendor) {
case X86_VENDOR_AMD:
- if (boot_cpu_data.x86 < 6)
+ if (boot_cpu_data.x86 != 15)
return;
if (strstr(boot_cpu_data.x86_model_id, "Screwdriver"))
return;
_
-
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 006/198] arm: add comment about max_low_pfn/max_pfn
I told rmk about this long time ago. On 4/12/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > From: Russell King <[EMAIL PROTECTED]> > > Oddly, max_low_pfn/max_pfn end up being the number of pages in the system, > rather than the maximum PFN on ARM. This doesn't seem to cause any problems, > so just add a note about it. > > Signed-off-by: Russell King <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > --- > > 25-akpm/arch/arm/mm/init.c |3 +++ > 1 files changed, 3 insertions(+) > > diff -puN arch/arm/mm/init.c~arm-add-comment-about-max_low_pfn-max_pfn > arch/arm/mm/init.c > --- 25/arch/arm/mm/init.c~arm-add-comment-about-max_low_pfn-max_pfn > 2005-04-12 03:21:04.967381744 -0700 > +++ 25-akpm/arch/arm/mm/init.c 2005-04-12 03:21:04.971381136 -0700 > @@ -223,6 +223,9 @@ find_memend_and_nodes(struct meminfo *mi > * This doesn't seem to be used by the Linux memory > * manager any more. If we can get rid of it, we > * also get rid of some of the stuff above as well. > +* > +* Note: max_low_pfn and max_pfn reflect the number > +* of _pages_ in the system, not the maximum PFN. > */ > max_low_pfn = memend_pfn - O_PFN_DOWN(PHYS_OFFSET); > max_pfn = memend_pfn - O_PFN_DOWN(PHYS_OFFSET); > _ -- Coywolf Qi Hunt http://sosdg.org/~coywolf/ - 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 patch] sound/oss/rme96xx.c: fix two check after use
On Wed, Apr 13, 2005 at 04:17:42AM +0200, Adrian Bunk wrote: > This patch fixes two check after use found by the Coverity checker. Bullshit. ->private_data is set by rme96xx_open() to guaranteed non-NULL and never changed elsewhere. Same comment about reading the fscking source, BUG_ON(), etc. - 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 086/198] x86_64: Make kernel math errors a die() now
From: "Andi Kleen" <[EMAIL PROTECTED]>
There were no reports about the previous warning for FPU exceptions in the
kernel, so make it a die() now.
Also improve the error messages slightly.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/x86_64/kernel/traps.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff -puN arch/x86_64/kernel/traps.c~x86_64-make-kernel-math-errors-a-die-now
arch/x86_64/kernel/traps.c
--- 25/arch/x86_64/kernel/traps.c~x86_64-make-kernel-math-errors-a-die-now
2005-04-12 03:21:23.706532960 -0700
+++ 25-akpm/arch/x86_64/kernel/traps.c 2005-04-12 03:21:23.709532504 -0700
@@ -733,14 +733,8 @@ static int kernel_math_error(struct pt_r
return 1;
}
notify_die(DIE_GPF, str, regs, 0, 16, SIGFPE);
-#if 0
- /* This should be a die, but warn only for now */
+ /* Illegal floating point operation in the kernel */
die(str, regs, 0);
-#else
- printk(KERN_DEBUG "%s: %s at ", current->comm, str);
- printk_address(regs->rip);
- printk("\n");
-#endif
return 0;
}
@@ -824,7 +818,7 @@ asmlinkage void do_simd_coprocessor_erro
conditional_sti(regs);
if ((regs->cs & 3) == 0 &&
- kernel_math_error(regs, "simd math error"))
+ kernel_math_error(regs, "kernel simd math error"))
return;
/*
_
-
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 patch] fs/udf/inode.c: fix a check after use
On Wed, Apr 13, 2005 at 04:17:37AM +0200, Adrian Bunk wrote: > This patch fixes a check after use found by the Coverity checker. Bullshit. *Please*, read the surrounding code. Again, we never get to calling that function if we would pass NULL in its first argument. It's BUG_ON(), not printk(). And oops on entering the function in question is just as good as BUG_ON(). Remove check and be done with that. - 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 patch] drivers/net/pcmcia/nmclan_cs.c: fix a check after use
On Wed, Apr 13, 2005 at 04:17:34AM +0200, Adrian Bunk wrote: > This patch fixes a check after use found by the Coverity checker. Again, check is a pure BS. Argument passed to this sucker comes from ->Instance of the same struct that had ->Handler equal to mace_interrupt(). That would be link->irq.Handler = _interrupt; link->irq.Instance = dev; in nmclan_attach(). Nothing ever modifies that beast afterwards and dev sure as hell can't be NULL in nmclan_attach() (explict check and a bunch of dereferencings prior to that point). Adrian, could you please _read_ the code you are modifying? - 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 056/198] mips: update VR41xx CPU-PCI bridge support
From: Yoichi Yuasa <[EMAIL PROTECTED]>
This patch updates NEC VR4100 series CPU-PCI bridge support.
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
Cc: Ralf Baechle <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/mips/pci/ops-vr41xx.c |6 +-
25-akpm/arch/mips/pci/pci-vr41xx.c | 88 +-
25-akpm/arch/mips/pci/pci-vr41xx.h | 69 ---
25-akpm/include/asm-mips/vr41xx/pci.h| 90 +++
25-akpm/include/asm-mips/vr41xx/vr41xx.h | 70
5 files changed, 181 insertions(+), 142 deletions(-)
diff -puN arch/mips/pci/ops-vr41xx.c~mips-update-vr41xx-cpu-pci-bridge
arch/mips/pci/ops-vr41xx.c
--- 25/arch/mips/pci/ops-vr41xx.c~mips-update-vr41xx-cpu-pci-bridge
2005-04-12 03:21:16.787584800 -0700
+++ 25-akpm/arch/mips/pci/ops-vr41xx.c 2005-04-12 03:21:16.795583584 -0700
@@ -3,7 +3,7 @@
*
* Copyright (C) 2001-2003 MontaVista Software Inc.
*Author: Yoichi Yuasa <[EMAIL PROTECTED] or [EMAIL PROTECTED]>
- * Copyright (C) 2004 Yoichi Yuasa <[EMAIL PROTECTED]>
+ * Copyright (C) 2004-2005 Yoichi Yuasa <[EMAIL PROTECTED]>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -29,8 +29,8 @@
#include
-#define PCICONFDREGKSEG1ADDR(0x0f000c14)
-#define PCICONFAREGKSEG1ADDR(0x0f000c18)
+#define PCICONFDREG(void __iomem *)KSEG1ADDR(0x0f000c14)
+#define PCICONFAREG(void __iomem *)KSEG1ADDR(0x0f000c18)
static inline int set_pci_configuration_address(unsigned char number,
unsigned int devfn, int where)
diff -puN arch/mips/pci/pci-vr41xx.c~mips-update-vr41xx-cpu-pci-bridge
arch/mips/pci/pci-vr41xx.c
--- 25/arch/mips/pci/pci-vr41xx.c~mips-update-vr41xx-cpu-pci-bridge
2005-04-12 03:21:16.789584496 -0700
+++ 25-akpm/arch/mips/pci/pci-vr41xx.c 2005-04-12 03:21:16.796583432 -0700
@@ -3,8 +3,8 @@
*
* Copyright (C) 2001-2003 MontaVista Software Inc.
*Author: Yoichi Yuasa <[EMAIL PROTECTED] or [EMAIL PROTECTED]>
- * Copyright (C) 2004 Yoichi Yuasa <[EMAIL PROTECTED]>
- * Copyright (C) 2004 by Ralf Baechle ([EMAIL PROTECTED])
+ * Copyright (C) 2004-2005 Yoichi Yuasa <[EMAIL PROTECTED]>
+ * Copyright (C) 2004 by Ralf Baechle ([EMAIL PROTECTED])
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -31,12 +31,18 @@
#include
#include
+#include
#include
#include "pci-vr41xx.h"
extern struct pci_ops vr41xx_pci_ops;
+static void __iomem *pciu_base;
+
+#define pciu_read(offset) readl(pciu_base + (offset))
+#define pciu_write(offset, value) writel((value), pciu_base + (offset))
+
static struct pci_master_address_conversion pci_master_memory1 = {
.bus_base_address = PCI_MASTER_MEM1_BUS_BASE_ADDRESS,
.address_mask = PCI_MASTER_MEM1_ADDRESS_MASK,
@@ -113,6 +119,15 @@ static int __init vr41xx_pciu_init(void)
setup = _pci_controller_unit_setup;
+ if (request_mem_region(PCIU_BASE, PCIU_SIZE, "PCIU") == NULL)
+ return -EBUSY;
+
+ pciu_base = ioremap(PCIU_BASE, PCIU_SIZE);
+ if (pciu_base == NULL) {
+ release_mem_region(PCIU_BASE, PCIU_SIZE);
+ return -EBUSY;
+ }
+
/* Disable PCI interrupt */
vr41xx_disable_pciint();
@@ -129,14 +144,14 @@ static int __init vr41xx_pciu_init(void)
pci_clock_max = PCI_CLOCK_MAX;
vtclock = vr41xx_get_vtclock_frequency();
if (vtclock < pci_clock_max)
- writel(EQUAL_VTCLOCK, PCICLKSELREG);
+ pciu_write(PCICLKSELREG, EQUAL_VTCLOCK);
else if ((vtclock / 2) < pci_clock_max)
- writel(HALF_VTCLOCK, PCICLKSELREG);
+ pciu_write(PCICLKSELREG, HALF_VTCLOCK);
else if (current_cpu_data.processor_id >= PRID_VR4131_REV2_1 &&
(vtclock / 3) < pci_clock_max)
- writel(ONE_THIRD_VTCLOCK, PCICLKSELREG);
+ pciu_write(PCICLKSELREG, ONE_THIRD_VTCLOCK);
else if ((vtclock / 4) < pci_clock_max)
- writel(QUARTER_VTCLOCK, PCICLKSELREG);
+ pciu_write(PCICLKSELREG, QUARTER_VTCLOCK);
else {
printk(KERN_ERR "PCI Clock is over 33MHz.\n");
return -EINVAL;
@@ -151,11 +166,11 @@ static int __init vr41xx_pciu_init(void)
MASTER_MSK(master->address_mask) |
WINEN |
PCIA(master->pci_base_address);
- writel(val, PCIMMAW1REG);
+ pciu_write(PCIMMAW1REG, val);
} else {
- val = readl(PCIMMAW1REG);
+ val = pciu_read(PCIMMAW1REG);
val &= ~WINEN;
- writel(val,
[patch 082/198] x86_64: Regularize exception stack handling
From: "Andi Kleen" <[EMAIL PROTECTED]>
This fixes various issues in the return path for "paranoid"
handlers (= running on a private exception stack that act like NMIs).
Generalize previous hack to switch back to process stack for
scheduling/signal handling purposes.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/x86_64/kernel/entry.S | 49 +--
25-akpm/arch/x86_64/kernel/traps.c | 57 ++---
2 files changed, 55 insertions(+), 51 deletions(-)
diff -puN arch/x86_64/kernel/entry.S~x86_64-regularize-exception-stack-handling
arch/x86_64/kernel/entry.S
--- 25/arch/x86_64/kernel/entry.S~x86_64-regularize-exception-stack-handling
2005-04-12 03:21:22.841664440 -0700
+++ 25-akpm/arch/x86_64/kernel/entry.S 2005-04-12 03:21:22.846663680 -0700
@@ -579,6 +579,7 @@ ENTRY(spurious_interrupt)
movq ORIG_RAX(%rsp),%rsi
movq $-1,ORIG_RAX(%rsp)
call \sym
+ cli
.endm
/*
@@ -794,10 +795,6 @@ ENTRY(debug)
pushq $0
CFI_ADJUST_CFA_OFFSET 8
paranoidentry do_debug
- /* switch back to process stack to restore the state ptrace touched */
- movq %rax,%rsp
- testl $3,CS(%rsp)
- jnz paranoid_userspace
jmp paranoid_exit
CFI_ENDPROC
@@ -807,35 +804,49 @@ ENTRY(nmi)
pushq $-1
CFI_ADJUST_CFA_OFFSET 8
paranoidentry do_nmi
+ /*
+* "Paranoid" exit path from exception stack.
+* Paranoid because this is used by NMIs and cannot take
+* any kernel state for granted.
+* We don't do kernel preemption checks here, because only
+* NMI should be common and it does not enable IRQs and
+* cannot get reschedule ticks.
+*/
/* ebx: no swapgs flag */
paranoid_exit:
testl %ebx,%ebx /* swapgs needed? */
jnz paranoid_restore
+ testl $3,CS(%rsp)
+ jnz paranoid_userspace
paranoid_swapgs:
- cli
swapgs
paranoid_restore:
RESTORE_ALL 8
iretq
paranoid_userspace:
- cli
GET_THREAD_INFO(%rcx)
- movl threadinfo_flags(%rcx),%edx
- testl $_TIF_WORK_MASK,%edx
+ movl threadinfo_flags(%rcx),%ebx
+ andl $_TIF_WORK_MASK,%ebx
jz paranoid_swapgs
- testl $_TIF_NEED_RESCHED,%edx
- jnz paranoid_resched
+ movq %rsp,%rdi /* _regs */
+ call sync_regs
+ movq %rax,%rsp /* switch stack for scheduling */
+ testl $_TIF_NEED_RESCHED,%ebx
+ jnz paranoid_schedule
+ movl %ebx,%edx /* arg3: thread flags */
sti
- xorl %esi,%esi /* oldset */
- movq %rsp,%rdi /* _regs */
+ xorl %esi,%esi /* arg2: oldset */
+ movq %rsp,%rdi /* arg1: _regs */
call do_notify_resume
- jmp paranoid_exit
-paranoid_resched:
+ cli
+ jmp paranoid_userspace
+paranoid_schedule:
sti
call schedule
- jmp paranoid_exit
+ cli
+ jmp paranoid_userspace
CFI_ENDPROC
-
+
ENTRY(int3)
zeroentry do_int3
@@ -858,9 +869,6 @@ ENTRY(reserved)
ENTRY(double_fault)
CFI_STARTPROC
paranoidentry do_double_fault
- movq %rax,%rsp
- testl $3,CS(%rsp)
- jnz paranoid_userspace
jmp paranoid_exit
CFI_ENDPROC
@@ -874,9 +882,6 @@ ENTRY(segment_not_present)
ENTRY(stack_segment)
CFI_STARTPROC
paranoidentry do_stack_segment
- movq %rax,%rsp
- testl $3,CS(%rsp)
- jnz paranoid_userspace
jmp paranoid_exit
CFI_ENDPROC
diff -puN arch/x86_64/kernel/traps.c~x86_64-regularize-exception-stack-handling
arch/x86_64/kernel/traps.c
--- 25/arch/x86_64/kernel/traps.c~x86_64-regularize-exception-stack-handling
2005-04-12 03:21:22.842664288 -0700
+++ 25-akpm/arch/x86_64/kernel/traps.c 2005-04-12 03:21:22.847663528 -0700
@@ -488,24 +488,8 @@ DO_ERROR(10, SIGSEGV, "invalid TSS", inv
DO_ERROR(11, SIGBUS, "segment not present", segment_not_present)
DO_ERROR_INFO(17, SIGBUS, "alignment check", alignment_check, BUS_ADRALN, 0)
DO_ERROR(18, SIGSEGV, "reserved", reserved)
-
-#define DO_ERROR_STACK(trapnr, signr, str, name) \
-asmlinkage void *do_##name(struct pt_regs * regs, long error_code) \
-{ \
- struct pt_regs *pr = ((struct pt_regs *)(current->thread.rsp0))-1; \
- if (notify_die(DIE_TRAP, str, regs, error_code, trapnr, signr) \
- == NOTIFY_STOP) \
- return regs; \
- if (regs->cs & 3) { \
- memcpy(pr, regs, sizeof(struct pt_regs)); \
- regs = pr; \
- } \
- do_trap(trapnr, signr, str, regs, error_code, NULL); \
- return regs;\
-}
-
Re: Processes stuck on D state on Dual Opteron
Claudio Martins wrote:
On Tuesday 12 April 2005 01:46, Andrew Morton wrote:
Claudio Martins <[EMAIL PROTECTED]> wrote:
I think I'm going to give a try to Neil's patch, but I'll have to apply
some patches from -mm.
Just this one if you're using 2.6.12-rc2:
--- 25/drivers/md/md.c~avoid-deadlock-in-sync_page_io-by-using-gfp_noio Mon
Apr 11 16:55:07 2005 +++ 25-akpm/drivers/md/md.c Mon Apr 11 16:55:07 2005
@@ -332,7 +332,7 @@ static int bi_complete(struct bio *bio,
static int sync_page_io(struct block_device *bdev, sector_t sector, int
size, struct page *page, int rw)
{
- struct bio *bio = bio_alloc(GFP_KERNEL, 1);
+ struct bio *bio = bio_alloc(GFP_NOIO, 1);
struct completion event;
int ret;
_
Hi Andrew, all,
Sorry for the delay in reporting. This patch does indeed fix the problem.
The machine ran stress for almost 15h straight with no problems at all.
As for Nick's patch I, too, think it would be nice to be included (once the
performance problems are sorted out), since it seemed to make the block layer
more robust and well behaved (at least with stress), although I didn't run
performance tests to measure regressions.
Thanks Nick, Neil, Andrew and all others for your great help with this
issue. I'll have to put the machine on production now with the patch applied,
but let me know if I can be of any further help with these issues.
Thanks for reporting and testing - what we need is more people
like you contributing to Linux ;)
--
SUSE Labs, Novell Inc.
-
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 1/3]: move config option for BAD_SYSCALL_EXIT
Hello. This patch moves the CONFIG_TRAP_BAD_SYSCALL_EXIT from "Executable file formats" section to the KGDB section. I had real problems finding that option where it was. Signed-off-by: Stas Sergeev <[EMAIL PROTECTED]> --- linux/arch/i386/Kconfig.old 2005-04-12 09:47:38.0 +0400 +++ linux/arch/i386/Kconfig 2005-04-12 09:56:48.0 +0400 @@ -1267,14 +1267,6 @@ source "fs/Kconfig.binfmt" -config TRAP_BAD_SYSCALL_EXITS - bool "Debug bad system call exits" - depends on KGDB - help - If you say Y here the kernel will check for system calls which - return without clearing preempt. -default n - endmenu source "drivers/Kconfig" --- linux/arch/i386/Kconfig.kgdb.old 2005-04-12 09:47:38.0 +0400 +++ linux/arch/i386/Kconfig.kgdb 2005-04-12 09:57:11.0 +0400 @@ -140,6 +140,14 @@ to check for kernel stack overflow on interrupts and system calls. This is part of the kgdb code on x86 systems. +config TRAP_BAD_SYSCALL_EXITS + bool "Debug bad system call exits" + depends on KGDB + help + If you say Y here the kernel will check for system calls which + return without clearing preempt. +default n + config KGDB_CONSOLE bool "Enable serial console thru kgdb port" depends on KGDB
[patch 084/198] x86_64: Remove unused macro in preempt support
From: "Andi Kleen" <[EMAIL PROTECTED]> Remove unused macro in preempt support Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- 25-akpm/arch/x86_64/kernel/entry.S |5 + 1 files changed, 1 insertion(+), 4 deletions(-) diff -puN arch/x86_64/kernel/entry.S~x86_64-remove-unused-macro-in-preempt-support arch/x86_64/kernel/entry.S --- 25/arch/x86_64/kernel/entry.S~x86_64-remove-unused-macro-in-preempt-support 2005-04-12 03:21:23.267599688 -0700 +++ 25-akpm/arch/x86_64/kernel/entry.S 2005-04-12 03:21:23.270599232 -0700 @@ -44,10 +44,7 @@ .code64 -#ifdef CONFIG_PREEMPT -#define preempt_stop cli -#else -#define preempt_stop +#ifndef CONFIG_PREEMPT #define retint_kernel retint_restore_args #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/
[2.6 patch] drivers/video/console/fbcon.c: fix a check after use
This patch fixes a check after use found by the Coverity checker. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- This patch was already sent on: - 27 Mar 2005 --- linux-2.6.12-rc1-mm1-full/drivers/video/console/fbcon.c.old 2005-03-23 04:53:20.0 +0100 +++ linux-2.6.12-rc1-mm1-full/drivers/video/console/fbcon.c 2005-03-23 04:53:44.0 +0100 @@ -906,10 +906,13 @@ static void fbcon_init(struct vc_data *v struct vc_data *svc = *default_mode; struct display *t, *p = _display[vc->vc_num]; int logo = 1, new_rows, new_cols, rows, cols, charcnt = 256; - int cap = info->flags; + int cap; if (info_idx == -1 || info == NULL) return; + + cap = info->flags; + if (vc != svc || logo_shown == FBCON_LOGO_DONTSHOW || (info->fix.type == FB_TYPE_TEXT)) logo = 0; - 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/
[2.6 patch] fs/udf/udftime.c: fix off by one error
This patch fixes an off by one error found by the Coverity checker.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 27 Mar 2005
--- linux-2.6.12-rc1-mm1-full/fs/udf/udftime.c.old 2005-03-23
01:22:02.0 +0100
+++ linux-2.6.12-rc1-mm1-full/fs/udf/udftime.c 2005-03-23 01:22:13.0
+0100
@@ -103,7 +103,7 @@ udf_stamp_to_time(time_t *dest, long *de
offset = 0;
if ((src.year < EPOCH_YEAR) ||
- (src.year > EPOCH_YEAR+MAX_YEAR_SECONDS))
+ (src.year >= EPOCH_YEAR+MAX_YEAR_SECONDS))
{
*dest = -1;
*dest_usec = -1;
-
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 070/198] x86_64 genapic update
From: Jason Davis <[EMAIL PROTECTED]>
x86_64 genapic mechanism should be aware of machines that use physical APIC
mode regardless of how many clusters/processors are detected.
ACPI 3.0 FADT makes this determination very simple by providing a feature
flag "force_apic_physical_destination_mode" to state whether the machine
unconditionally uses physical APIC mode.
Unisys' next generation x86_64 ES7000 will need to utilize this FADT
feature flag in order to boot the x86_64 kernel in the correct APIC mode.
This patch has been tested on both x86_64 commodity and ES7000 boxes.
Signed-off-by: Jason Davis <[EMAIL PROTECTED]>
Acked-by: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/i386/kernel/acpi/boot.c |4
25-akpm/arch/x86_64/kernel/genapic.c | 16
2 files changed, 20 insertions(+)
diff -puN arch/i386/kernel/acpi/boot.c~x86_64-genapic-update
arch/i386/kernel/acpi/boot.c
--- 25/arch/i386/kernel/acpi/boot.c~x86_64-genapic-update 2005-04-12
03:21:20.212064200 -0700
+++ 25-akpm/arch/i386/kernel/acpi/boot.c2005-04-12 03:21:20.217063440
-0700
@@ -608,6 +608,10 @@ static int __init acpi_parse_fadt(unsign
acpi_fadt.sci_int = fadt->sci_int;
#endif
+ /* initialize rev and apic_phys_dest_mode for x86_64 genapic */
+ acpi_fadt.revision = fadt->revision;
+ acpi_fadt.force_apic_physical_destination_mode =
fadt->force_apic_physical_destination_mode;
+
#ifdef CONFIG_X86_PM_TIMER
/* detect the location of the ACPI PM Timer */
if (fadt->revision >= FADT2_REVISION_ID) {
diff -puN arch/x86_64/kernel/genapic.c~x86_64-genapic-update
arch/x86_64/kernel/genapic.c
--- 25/arch/x86_64/kernel/genapic.c~x86_64-genapic-update 2005-04-12
03:21:20.214063896 -0700
+++ 25-akpm/arch/x86_64/kernel/genapic.c2005-04-12 03:21:20.218063288
-0700
@@ -20,6 +20,10 @@
#include
#include
+#if defined(CONFIG_ACPI_BUS)
+#include
+#endif
+
/* which logical CPU number maps to which CPU (physical APIC ID) */
u8 x86_cpu_to_apicid[NR_CPUS] = { [0 ... NR_CPUS-1] = BAD_APICID };
EXPORT_SYMBOL(x86_cpu_to_apicid);
@@ -47,6 +51,18 @@ void __init clustered_apic_check(void)
goto print;
}
+#if defined(CONFIG_ACPI_BUS)
+ /*
+* Some x86_64 machines use physical APIC mode regardless of how many
+* procs/clusters are present (x86_64 ES7000 is an example).
+*/
+ if (acpi_fadt.revision > FADT2_REVISION_ID)
+ if (acpi_fadt.force_apic_physical_destination_mode) {
+ genapic = _cluster;
+ goto print;
+ }
+#endif
+
memset(cluster_cnt, 0, sizeof(cluster_cnt));
for (i = 0; i < NR_CPUS; i++) {
_
-
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] X86_64: no legacy HPET fix
All,
Currently the x86-64 HPET code assumes the entire HPET implementation
from the spec is present. This breaks on boxes that do not implement the
optional legacy timer replacement functionality portion of the spec.
This is my first swing at resolving this issue, allowing x86-64 systems
that cannot use the HPET for the timer interrupt and RTC to still use
the HPET as a time source. Unfortunately I haven't gotten to test this
on other HPET enabled systems, so proceed with caution.
Its likely a similar patch will be necessary for i386.
Comments/Thoughts/Feedback?
thanks
-john
linux-2.6.12-rc2_hpet-nolegacy-fix_A0
=
diff -Nru a/arch/x86_64/kernel/time.c b/arch/x86_64/kernel/time.c
--- a/arch/x86_64/kernel/time.c 2005-04-12 19:31:50 -07:00
+++ b/arch/x86_64/kernel/time.c 2005-04-12 19:31:50 -07:00
@@ -60,6 +60,7 @@
unsigned int cpu_khz; /* TSC clocks / usec,
not used here */
static unsigned long hpet_period; /* fsecs / HPET clock */
unsigned long hpet_tick; /* HPET clocks /
interrupt */
+static int hpet_use_timer;
unsigned long vxtime_hz = PIT_TICK_RATE;
int report_lost_ticks; /* command line option */
unsigned long long monotonic_base;
@@ -373,8 +374,10 @@
write_seqlock(_lock);
- if (vxtime.hpet_address) {
- offset = hpet_readl(HPET_T0_CMP) - hpet_tick;
+ if (vxtime.hpet_address)
+ offset = hpet_readl(HPET_COUNTER);
+
+ if (hpet_use_timer) {
delay = hpet_readl(HPET_COUNTER) - offset;
} else {
spin_lock(_lock);
@@ -732,7 +735,7 @@
struct hpet_datahd;
unsigned intntimer;
- if (!vxtime.hpet_address)
+ if (!hpet_use_timer)
return -1;
memset(, 0, sizeof (hd));
@@ -794,17 +797,18 @@
* Set up timer 0, as periodic with first interrupt to happen at hpet_tick,
* and period also hpet_tick.
*/
-
- hpet_writel(HPET_TN_ENABLE | HPET_TN_PERIODIC | HPET_TN_SETVAL |
+ if (hpet_use_timer) {
+ hpet_writel(HPET_TN_ENABLE | HPET_TN_PERIODIC | HPET_TN_SETVAL |
HPET_TN_32BIT, HPET_T0_CFG);
- hpet_writel(hpet_tick, HPET_T0_CMP);
- hpet_writel(hpet_tick, HPET_T0_CMP); /* AK: why twice? */
-
+ hpet_writel(hpet_tick, HPET_T0_CMP);
+ hpet_writel(hpet_tick, HPET_T0_CMP); /* AK: why twice? */
+ cfg |= HPET_CFG_LEGACY;
+ }
/*
* Go!
*/
- cfg |= HPET_CFG_ENABLE | HPET_CFG_LEGACY;
+ cfg |= HPET_CFG_ENABLE;
hpet_writel(cfg, HPET_CFG);
return 0;
@@ -825,10 +829,11 @@
id = hpet_readl(HPET_ID);
- if (!(id & HPET_ID_VENDOR) || !(id & HPET_ID_NUMBER) ||
- !(id & HPET_ID_LEGSUP))
+ if (!(id & HPET_ID_VENDOR) || !(id & HPET_ID_NUMBER))
return -1;
+ hpet_use_timer = (id & HPET_ID_LEGSUP);
+
hpet_period = hpet_readl(HPET_PERIOD);
if (hpet_period < 10 || hpet_period > 1)
return -1;
@@ -892,9 +897,11 @@
set_normalized_timespec(_to_monotonic,
-xtime.tv_sec, -xtime.tv_nsec);
- if (!hpet_init()) {
+ if (!hpet_init())
vxtime_hz = (1000L + hpet_period / 2) /
hpet_period;
+
+ if (hpet_use_timer) {
cpu_khz = hpet_calibrate_tsc();
timename = "HPET";
} else {
@@ -940,12 +947,12 @@
if (oem_force_hpet_timer())
notsc = 1;
if (vxtime.hpet_address && notsc) {
- timetype = "HPET";
+ timetype = hpet_use_timer ? "HPET" : "PIT/HPET";
vxtime.last = hpet_readl(HPET_T0_CMP) - hpet_tick;
vxtime.mode = VXTIME_HPET;
do_gettimeoffset = do_gettimeoffset_hpet;
} else {
- timetype = vxtime.hpet_address ? "HPET/TSC" : "PIT/TSC";
+ timetype = hpet_use_timer ? "HPET/TSC" : "PIT/TSC";
vxtime.mode = VXTIME_TSC;
}
-
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/
[2.6 patch] sound/oss/rme96xx.c: fix two check after use
This patch fixes two check after use found by the Coverity checker.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 27 Mar 2005
--- linux-2.6.12-rc1-mm3-full/sound/oss/rme96xx.c.old 2005-03-27
23:16:02.0 +0200
+++ linux-2.6.12-rc1-mm3-full/sound/oss/rme96xx.c 2005-03-27
23:16:11.0 +0200
@@ -1534,18 +1534,20 @@
static ssize_t rme96xx_write(struct file *file, const char __user *buffer,
size_t count, loff_t *ppos)
{
struct dmabuf *dma = (struct dmabuf *)file->private_data;
ssize_t ret = 0;
int cnt; /* number of bytes from "buffer" that will/can be used */
- int hop = count/dma->outchannels;
+ int hop;
int hwp;
int exact = (file->f_flags & O_NONBLOCK);
if(dma == NULL || (dma->s) == NULL)
return -ENXIO;
+ hop = count/dma->outchannels;
+
if (dma->mmapped || !dma->opened)
return -ENXIO;
if (!access_ok(VERIFY_READ, buffer, count))
return -EFAULT;
@@ -1599,18 +1601,20 @@
static ssize_t rme96xx_read(struct file *file, char __user *buffer, size_t
count, loff_t *ppos)
{
struct dmabuf *dma = (struct dmabuf *)file->private_data;
ssize_t ret = 0;
int cnt; /* number of bytes from "buffer" that will/can be used */
- int hop = count/dma->inchannels;
+ int hop;
int hwp;
int exact = (file->f_flags & O_NONBLOCK);
if(dma == NULL || (dma->s) == NULL)
return -ENXIO;
+ hop = count/dma->inchannels;
+
if (dma->mmapped || !dma->opened)
return -ENXIO;
if (!access_ok(VERIFY_WRITE, buffer, count))
return -EFAULT;
-
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/
[2.6 patch] kill smp_tune_scheduling()
Since all remaining smp_tune_scheduling()'s are now empty (except for
the useless setting of function-local variables), we can completely
remove the remaining ones.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
arch/i386/kernel/smpboot.c | 31 ---
arch/i386/mach-voyager/voyager_smp.c |4 ---
arch/m32r/kernel/smpboot.c |7 --
arch/mips/kernel/smp.c | 29 -
4 files changed, 71 deletions(-)
--- linux-2.6.12-rc2-mm1-full/arch/mips/kernel/smp.c.old2005-04-05
16:53:13.0 +0200
+++ linux-2.6.12-rc2-mm1-full/arch/mips/kernel/smp.c2005-04-05
16:53:35.0 +0200
@@ -46,34 +46,6 @@
EXPORT_SYMBOL(phys_cpu_present_map);
EXPORT_SYMBOL(cpu_online_map);
-static void smp_tune_scheduling (void)
-{
- struct cache_desc *cd = _cpu_data.scache;
- unsigned long cachesize; /* kB */
- unsigned long bandwidth = 350; /* MB/s */
- unsigned long cpu_khz;
-
- /*
-* Crude estimate until we actually meassure ...
-*/
- cpu_khz = loops_per_jiffy * 2 * HZ / 1000;
-
- /*
-* Rough estimation for SMP scheduling, this is the number of
-* cycles it takes for a fully memory-limited process to flush
-* the SMP-local cache.
-*
-* (For a P5 this pretty much means we will choose another idle
-* CPU almost always at wakeup time (this is due to the small
-* L1 cache), on PIIs it's around 50-100 usecs, depending on
-* the cache size)
-*/
- if (!cpu_khz)
- return;
-
- cachesize = cd->linesz * cd->sets * cd->ways;
-}
-
extern void __init calibrate_delay(void);
extern ATTRIB_NORET void cpu_idle(void);
@@ -217,7 +189,6 @@
cpu_data[0].udelay_val = loops_per_jiffy;
init_new_context(current, _mm);
current_thread_info()->cpu = 0;
- smp_tune_scheduling();
prom_prepare_cpus(max_cpus);
}
--- linux-2.6.12-rc2-mm1-full/arch/i386/kernel/smpboot.c.old2005-04-05
16:53:43.0 +0200
+++ linux-2.6.12-rc2-mm1-full/arch/i386/kernel/smpboot.c2005-04-05
16:53:58.0 +0200
@@ -855,36 +855,6 @@
return boot_error;
}
-static void smp_tune_scheduling (void)
-{
- unsigned long cachesize; /* kB */
- unsigned long bandwidth = 350; /* MB/s */
- /*
-* Rough estimation for SMP scheduling, this is the number of
-* cycles it takes for a fully memory-limited process to flush
-* the SMP-local cache.
-*
-* (For a P5 this pretty much means we will choose another idle
-* CPU almost always at wakeup time (this is due to the small
-* L1 cache), on PIIs it's around 50-100 usecs, depending on
-* the cache size)
-*/
-
- if (!cpu_khz) {
- /*
-* this basically disables processor-affinity
-* scheduling on SMP without a TSC.
-*/
- return;
- } else {
- cachesize = boot_cpu_data.x86_cache_size;
- if (cachesize == -1) {
- cachesize = 16; /* Pentiums, 2x8kB cache */
- bandwidth = 100;
- }
- }
-}
-
/*
* Cycle through the processors sending APIC IPIs to boot each.
*/
@@ -913,7 +883,6 @@
x86_cpu_to_apicid[0] = boot_cpu_physical_apicid;
current_thread_info()->cpu = 0;
- smp_tune_scheduling();
cpus_clear(cpu_sibling_map[0]);
cpu_set(0, cpu_sibling_map[0]);
--- linux-2.6.12-rc2-mm1-full/arch/i386/mach-voyager/voyager_smp.c.old
2005-04-05 16:54:07.0 +0200
+++ linux-2.6.12-rc2-mm1-full/arch/i386/mach-voyager/voyager_smp.c
2005-04-05 16:54:22.0 +0200
@@ -688,10 +688,6 @@
* schedule at the moment */
//global_irq_holder = boot_cpu_id;
- /* FIXME: Need to do something about this but currently only works
-* on CPUs with a tsc which none of mine have.
- smp_tune_scheduling();
-*/
smp_store_cpu_info(boot_cpu_id);
printk("CPU%d: ", boot_cpu_id);
print_cpu_info(_data[boot_cpu_id]);
--- linux-2.6.12-rc2-mm1-full/arch/m32r/kernel/smpboot.c.old2005-04-05
16:54:30.0 +0200
+++ linux-2.6.12-rc2-mm1-full/arch/m32r/kernel/smpboot.c2005-04-05
16:54:42.0 +0200
@@ -109,7 +109,6 @@
void smp_prepare_boot_cpu(void);
void smp_prepare_cpus(unsigned int);
-static void smp_tune_scheduling(void);
static void init_ipi_lock(void);
static void do_boot_cpu(int);
int __cpu_up(unsigned int);
@@ -185,7 +184,6 @@
* Setup boot CPU information
*/
smp_store_cpu_info(0); /* Final full version of the data */
- smp_tune_scheduling();
/*
* If SMP should be disabled, then really disable it!
@@ -229,11 +227,6 @@
Dprintk("Boot done.\n");
}
-static void __init
[2.6 patch] fs/udf/inode.c: fix a check after use
This patch fixes a check after use found by the Coverity checker.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 27 Mar 2005
--- linux-2.6.12-rc1-mm1-full/fs/udf/inode.c.old2005-03-23
05:12:25.0 +0100
+++ linux-2.6.12-rc1-mm1-full/fs/udf/inode.c2005-03-23 05:12:53.0
+0100
@@ -1948,28 +1948,30 @@
udf_release_data(obh);
return (elen >> 30);
}
int8_t inode_bmap(struct inode *inode, int block, kernel_lb_addr *bloc,
uint32_t *extoffset,
kernel_lb_addr *eloc, uint32_t *elen, uint32_t *offset, struct
buffer_head **bh)
{
- uint64_t lbcount = 0, bcount = (uint64_t)block <<
inode->i_sb->s_blocksize_bits;
+ uint64_t lbcount = 0, bcount;
int8_t etype;
if (block < 0)
{
printk(KERN_ERR "udf: inode_bmap: block < 0\n");
return -1;
}
if (!inode)
{
printk(KERN_ERR "udf: inode_bmap: NULL inode\n");
return -1;
}
+ bcount = (uint64_t)block << inode->i_sb->s_blocksize_bits;
+
*extoffset = 0;
*elen = 0;
*bloc = UDF_I_LOCATION(inode);
do
{
if ((etype = udf_next_aext(inode, bloc, extoffset, eloc, elen,
bh, 1)) == -1)
-
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 patch] sound/oss/cs46xx.c: fix a check after use
On Wed, Apr 13, 2005 at 04:17:39AM +0200, Adrian Bunk wrote: > This patch fixes a check after use found by the Coverity checker. NAK. Please, read the surrounding code. All places that can call that function have form ->amplifier_ctrl(,...); so we _can't_ get NULL first argument. The check should be removed - it's not paranoia, it's simple stupidity. - 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/
[2.6 patch] drivers/net/pcmcia/nmclan_cs.c: fix a check after use
This patch fixes a check after use found by the Coverity checker.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 27 Mar 2005
--- linux-2.6.12-rc1-mm1-full/drivers/net/pcmcia/nmclan_cs.c.old
2005-03-23 05:04:00.0 +0100
+++ linux-2.6.12-rc1-mm1-full/drivers/net/pcmcia/nmclan_cs.c2005-03-23
05:04:30.0 +0100
@@ -1090,20 +1090,22 @@
*/
static irqreturn_t mace_interrupt(int irq, void *dev_id, struct pt_regs *regs)
{
struct net_device *dev = (struct net_device *) dev_id;
mace_private *lp = netdev_priv(dev);
- kio_addr_t ioaddr = dev->base_addr;
+ kio_addr_t ioaddr;
int status;
int IntrCnt = MACE_MAX_IR_ITERATIONS;
if (dev == NULL) {
DEBUG(2, "mace_interrupt(): irq 0x%X for unknown device.\n",
irq);
return IRQ_NONE;
}
+ ioaddr = dev->base_addr;
+
if (lp->tx_irq_disabled) {
printk(
(lp->tx_irq_disabled?
KERN_NOTICE "%s: Interrupt with tx_irq_disabled "
"[isr=%02X, imr=%02X]\n":
-
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 078/198] x86_64: Dump stack and prevent recursion on early fault
From: "Andi Kleen" <[EMAIL PROTECTED]> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- 25-akpm/arch/x86_64/kernel/head.S |8 1 files changed, 8 insertions(+) diff -puN arch/x86_64/kernel/head.S~x86_64-dump-stack-and-prevent-recursion-on-early-fault arch/x86_64/kernel/head.S --- 25/arch/x86_64/kernel/head.S~x86_64-dump-stack-and-prevent-recursion-on-early-fault 2005-04-12 03:21:22.009790904 -0700 +++ 25-akpm/arch/x86_64/kernel/head.S 2005-04-12 03:21:22.012790448 -0700 @@ -200,14 +200,22 @@ init_rsp: .quad init_thread_union+THREAD_SIZE-8 ENTRY(early_idt_handler) + cmpl $2,early_recursion_flag(%rip) + jz 1f + incl early_recursion_flag(%rip) xorl %eax,%eax movq 8(%rsp),%rsi # get rip movq (%rsp),%rdx movq %cr2,%rcx leaq early_idt_msg(%rip),%rdi call early_printk + cmpl $2,early_recursion_flag(%rip) + jz 1f + call dump_stack 1: hlt jmp 1b +early_recursion_flag: + .long 0 early_idt_msg: .asciz "PANIC: early exception rip %lx error %lx cr2 %lx\n" _ - 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 083/198] x86_64: Fix a small missing schedule race
From: "Andi Kleen" <[EMAIL PROTECTED]> Could lead to a lost reschedule event when the process already rescheduled on exception exit, and needs it again while still being in the kernel. Unlikely case though. Also remove one redundant cli in another entry.S path. Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- 25-akpm/arch/x86_64/kernel/entry.S |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN arch/x86_64/kernel/entry.S~x86_64-fix-a-small-missing-schedule-race arch/x86_64/kernel/entry.S --- 25/arch/x86_64/kernel/entry.S~x86_64-fix-a-small-missing-schedule-race 2005-04-12 03:21:23.062630848 -0700 +++ 25-akpm/arch/x86_64/kernel/entry.S 2005-04-12 03:21:23.066630240 -0700 @@ -284,6 +284,7 @@ int_careful: pushq %rdi call schedule popq %rdi + cli jmp int_with_check /* handle signals and tracing -- both require a full stack frame */ @@ -453,7 +454,6 @@ retint_check: andl %edi,%edx jnz retint_careful retint_swapgs: - cli swapgs retint_restore_args: cli _ - 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] Maintainers list update: linux-net -> netdev
On Tue, Apr 12, 2005 at 12:14:56PM -0700, George Anzinger wrote: > Horms wrote: > > > >Use netdev as the mailing list contact instead of the mostly dead > >linux-net list. > > > ~ > > PHRAM MTD DRIVER > >@@ -1795,7 +1795,7 @@ > > POSIX CLOCKS and TIMERS > > P: George Anzinger > > M: george@mvista.com > >-L: linux-net@vger.kernel.org > >+L: netdev@oss.sgi.com > > S: Supported > > > I don't really know about the rest of them, but I think this should be: > L: linux-kernel@vger.kernel.org > > Least wise that is where I look... Yes, I was wondering about that one. Here is a patch that adds to my previous patch. Trivial to say the least. I can re-diff the whole thing if that is more convenient. -- Horms POSIX CLOCKS and TIMERS disscussion is more appropriate on linux-kernel than linux-net. As suggested by the maintainer, George Anzinger. Signed-off-by: Horms <[EMAIL PROTECTED]> --- a/MAINTAINERS 2005-04-13 11:06:39.0 +0900 +++ b/MAINTAINERS 2005-04-13 11:07:04.0 +0900 @@ -1795,7 +1795,7 @@ POSIX CLOCKS and TIMERS P: George Anzinger M: george@mvista.com -L: linux-net@vger.kernel.org +L: linux-kernel@vger.kernel.org S: Supported PNP SUPPORT - 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 077/198] x86_64: Use a common function to find code segment bases
From: "Andi Kleen" <[EMAIL PROTECTED]>
To avoid some code duplication.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/x86_64/mm/fault.c | 12 +---
25-akpm/include/asm-x86_64/ptrace.h |5 +
2 files changed, 10 insertions(+), 7 deletions(-)
diff -puN
arch/x86_64/mm/fault.c~x86_64-use-a-common-function-to-find-code-segment-bases
arch/x86_64/mm/fault.c
---
25/arch/x86_64/mm/fault.c~x86_64-use-a-common-function-to-find-code-segment-bases
2005-04-12 03:21:21.786824800 -0700
+++ 25-akpm/arch/x86_64/mm/fault.c 2005-04-12 03:21:21.790824192 -0700
@@ -62,21 +62,19 @@ void bust_spinlocks(int yes)
static noinline int is_prefetch(struct pt_regs *regs, unsigned long addr,
unsigned long error_code)
{
- unsigned char *instr = (unsigned char *)(regs->rip);
+ unsigned char *instr;
int scan_more = 1;
int prefetch = 0;
- unsigned char *max_instr = instr + 15;
+ unsigned char *max_instr;
/* If it was a exec fault ignore */
if (error_code & (1<<4))
return 0;
- /* Code segments in LDT could have a non zero base. Don't check
- when that's possible */
- if (regs->cs & (1<<2))
- return 0;
+ instr = (unsigned char *)convert_rip_to_linear(current, regs);
+ max_instr = instr + 15;
- if ((regs->cs & 3) != 0 && regs->rip >= TASK_SIZE)
+ if ((regs->cs & 3) != 0 && instr >= (unsigned char *)TASK_SIZE)
return 0;
while (scan_more && instr < max_instr) {
diff -puN
include/asm-x86_64/ptrace.h~x86_64-use-a-common-function-to-find-code-segment-bases
include/asm-x86_64/ptrace.h
---
25/include/asm-x86_64/ptrace.h~x86_64-use-a-common-function-to-find-code-segment-bases
2005-04-12 03:21:21.787824648 -0700
+++ 25-akpm/include/asm-x86_64/ptrace.h 2005-04-12 03:21:21.790824192 -0700
@@ -86,6 +86,11 @@ struct pt_regs {
extern unsigned long profile_pc(struct pt_regs *regs);
void signal_fault(struct pt_regs *regs, void __user *frame, char *where);
+struct task_struct;
+
+extern unsigned long
+convert_rip_to_linear(struct task_struct *child, struct pt_regs *regs);
+
enum {
EF_CF = 0x0001,
EF_PF = 0x0004,
_
-
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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, 2005-04-12 at 20:45 +0200, Sven Luther wrote: [snip] > > A did put a GPL notice on it. He can't change his mind later. > Then he should give us the source. [snip] > The fact remains that those firmware blob have no licence, and thus defacto > fall under the GPL. > > > Moreover, the firmare in not in binary form, but is part of a C source > > file. > > It is in binary form. Disguised binary form maybe but still binary form. [snip] > And where did those hexstrings come from ? It seems to me, that to be consistent with the argument you seem to be presenting concerning binary data in GPLd code, that you also need to be demanding the "source" hardware design for binary register values. Why not consider the binary firmware in the same category as binary register programming information? You poke these magic bytes into these memory locations and it works. Where do you draw the lines between "write this byte to set the input gate here and the output gate to there" and "write this byte sequence to send the input byte through this loop, into this buffer, add it to the last byte entered, and output it over there"? -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: [patch 1/9] GFP_ZERO fix
Nick Piggin <[EMAIL PROTECTED]> wrote: > > #define GFP_LEVEL_MASK (__GFP_WAIT|__GFP_HIGH|__GFP_IO|__GFP_FS| \ > -__GFP_COLD|__GFP_NOWARN|__GFP_REPEAT| \ > -__GFP_NOFAIL|__GFP_NORETRY|__GFP_NO_GROW|__GFP_COMP) > +__GFP_COLD|__GFP_NOWARN|__GFP_REPEAT|__GFP_NOFAIL| \ > +__GFP_NORETRY|__GFP_NO_GROW|__GFP_COMP|__GFP_ZERO) Passing GFP_ZERO into kmem_cache_alloc() is such a bizarre thing to do, perhaps a BUG is the correct response. I guess it could be argued that the kmem_cache_alloc() callers "knows" that the ctor will be zeroing out all the objects, but it would seem cleaner to me to pass the "you should use GFP_ZERO" hint into kmem_cache_create() rather than kmem_cache_alloc(). - 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 079/198] x86_64: Fix interaction of single stepping with debuggers
From: "Andi Kleen" <[EMAIL PROTECTED]>
Ported from i386/Linus
Fix another TF corner case. Need to do the special TF handling for all
signals to make debuggers happy
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/x86_64/kernel/signal.c | 12
1 files changed, 12 insertions(+)
diff -puN
arch/x86_64/kernel/signal.c~x86_64-fix-interaction-of-single-stepping-with-debuggers
arch/x86_64/kernel/signal.c
---
25/arch/x86_64/kernel/signal.c~x86_64-fix-interaction-of-single-stepping-with-debuggers
2005-04-12 03:21:22.220758832 -0700
+++ 25-akpm/arch/x86_64/kernel/signal.c 2005-04-12 03:21:22.223758376 -0700
@@ -368,6 +368,18 @@ handle_signal(unsigned long sig, siginfo
}
}
+ /*
+* If TF is set due to a debugger (PT_DTRACE), clear the TF
+* flag so that register information in the sigcontext is
+* correct.
+*/
+ if (unlikely(regs->eflags & TF_MASK)) {
+ if (likely(current->ptrace & PT_DTRACE)) {
+ current->ptrace &= ~PT_DTRACE;
+ regs->eflags &= ~TF_MASK;
+ }
+ }
+
#ifdef CONFIG_IA32_EMULATION
if (test_thread_flag(TIF_IA32)) {
if (ka->sa.sa_flags & SA_SIGINFO)
_
-
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 076/198] x86_64: Handle programs that set TF in user space using popf while single stepping
From: "Andi Kleen" <[EMAIL PROTECTED]>
Ported from i386/Linus
Still won't handle other TF changing instructions like IRET or LAHF.
Prefix handling must be double checked...
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/x86_64/kernel/ptrace.c | 88
1 files changed, 88 insertions(+)
diff -puN
arch/x86_64/kernel/ptrace.c~x86_64-handle-programs-that-set-tf-in-user-space-using
arch/x86_64/kernel/ptrace.c
---
25/arch/x86_64/kernel/ptrace.c~x86_64-handle-programs-that-set-tf-in-user-space-using
2005-04-12 03:21:21.572857328 -0700
+++ 25-akpm/arch/x86_64/kernel/ptrace.c 2005-04-12 03:21:21.576856720 -0700
@@ -86,6 +86,84 @@ static inline long put_stack_long(struct
return 0;
}
+#define LDT_SEGMENT 4
+
+unsigned long convert_rip_to_linear(struct task_struct *child, struct pt_regs
*regs)
+{
+ unsigned long addr, seg;
+
+ addr = regs->rip;
+ seg = regs->cs & 0x;
+
+ /*
+* We'll assume that the code segments in the GDT
+* are all zero-based. That is largely true: the
+* TLS segments are used for data, and the PNPBIOS
+* and APM bios ones we just ignore here.
+*/
+ if (seg & LDT_SEGMENT) {
+ u32 *desc;
+ unsigned long base;
+
+ down(>mm->context.sem);
+ desc = child->mm->context.ldt + (seg & ~7);
+ base = (desc[0] >> 16) | ((desc[1] & 0xff) << 16) | (desc[1] &
0xff00);
+
+ /* 16-bit code segment? */
+ if (!((desc[1] >> 22) & 1))
+ addr &= 0x;
+ addr += base;
+ up(>mm->context.sem);
+ }
+ return addr;
+}
+
+static int is_at_popf(struct task_struct *child, struct pt_regs *regs)
+{
+ int i, copied;
+ unsigned char opcode[16];
+ unsigned long addr = convert_rip_to_linear(child, regs);
+
+ copied = access_process_vm(child, addr, opcode, sizeof(opcode), 0);
+ for (i = 0; i < copied; i++) {
+ switch (opcode[i]) {
+ /* popf */
+ case 0x9d:
+ return 1;
+
+ /* CHECKME: 64 65 */
+
+ /* opcode and address size prefixes */
+ case 0x66: case 0x67:
+ continue;
+ /* irrelevant prefixes (segment overrides and repeats) */
+ case 0x26: case 0x2e:
+ case 0x36: case 0x3e:
+ case 0x64: case 0x65:
+ case 0xf0: case 0xf2: case 0xf3:
+ continue;
+
+ /* REX prefixes */
+ case 0x40 ... 0x4f:
+ continue;
+
+ /* CHECKME: f0, f2, f3 */
+
+ /*
+* pushf: NOTE! We should probably not let
+* the user see the TF bit being set. But
+* it's more pain than it's worth to avoid
+* it, and a debugger could emulate this
+* all in user space if it _really_ cares.
+*/
+ case 0x9c:
+ default:
+ return 0;
+ }
+ }
+ return 0;
+}
+
static void set_singlestep(struct task_struct *child)
{
struct pt_regs *regs = get_child_regs(child);
@@ -106,6 +184,16 @@ static void set_singlestep(struct task_s
/* Set TF on the kernel stack.. */
regs->eflags |= TRAP_FLAG;
+ /*
+* ..but if TF is changed by the instruction we will trace,
+* don't mark it as being "us" that set it, so that we
+* won't clear it by hand later.
+*
+* AK: this is not enough, LAHF and IRET can change TF in user space
too.
+*/
+ if (is_at_popf(child, regs))
+ return;
+
child->ptrace |= PT_DTRACE;
}
_
-
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/
[2.6 patch] sound/oss/cs46xx.c: fix a check after use
This patch fixes a check after use found by the Coverity checker.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 27 Mar 2005
--- linux-2.6.12-rc1-mm1-full/sound/oss/cs46xx.c.old2005-03-23
04:48:53.0 +0100
+++ linux-2.6.12-rc1-mm1-full/sound/oss/cs46xx.c2005-03-23
04:49:31.0 +0100
@@ -3086,13 +3086,14 @@
static void amp_hercules(struct cs_card *card, int change)
{
- int old=card->amplifier;
+ int old;
if(!card)
{
CS_DBGOUT(CS_ERROR, 2, printk(KERN_INFO
"cs46xx: amp_hercules() called before initialized.\n"));
return;
}
+ old = card->amplifier;
card->amplifier+=change;
if( (card->amplifier && !old) && !(hercules_egpio_disable))
{
-
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 051/198] ppc64: Detect altivec via firmware on unknown CPUs
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
This patch adds detection of the Altivec capability of the CPU via the
firmware in addition to the cpu table. This allows newer CPUs that aren't
in the table to still have working altivec support in the kernel.
It also fixes a problem where if a CPU isn't recognized as having altivec
features, and takes an altivec unavailable exception due to userland
issuing altivec instructions, the kernel would happily enable it and
context switch the registers ... but not all of them (it would basically
forget vrsave). With this patch, the kernel will refuse to enable altivec
when the feature isn't detected for the CPU (SIGILL).
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/ppc64/kernel/head.S |2 ++
25-akpm/arch/ppc64/kernel/prom.c | 19 ++-
25-akpm/arch/ppc64/kernel/traps.c |2 --
3 files changed, 20 insertions(+), 3 deletions(-)
diff -puN
arch/ppc64/kernel/head.S~ppc64-detect-altivec-via-firmware-on-unknown-cpus
arch/ppc64/kernel/head.S
---
25/arch/ppc64/kernel/head.S~ppc64-detect-altivec-via-firmware-on-unknown-cpus
2005-04-12 03:21:15.707748960 -0700
+++ 25-akpm/arch/ppc64/kernel/head.S2005-04-12 03:21:15.714747896 -0700
@@ -922,7 +922,9 @@ fp_unavailable_common:
altivec_unavailable_common:
EXCEPTION_PROLOG_COMMON(0xf20, PACA_EXGEN)
#ifdef CONFIG_ALTIVEC
+BEGIN_FTR_SECTION
bne .load_up_altivec/* if from user, just load it up */
+END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
#endif
bl .save_nvgprs
addir3,r1,STACK_FRAME_OVERHEAD
diff -puN
arch/ppc64/kernel/prom.c~ppc64-detect-altivec-via-firmware-on-unknown-cpus
arch/ppc64/kernel/prom.c
---
25/arch/ppc64/kernel/prom.c~ppc64-detect-altivec-via-firmware-on-unknown-cpus
2005-04-12 03:21:15.708748808 -0700
+++ 25-akpm/arch/ppc64/kernel/prom.c2005-04-12 03:21:15.715747744 -0700
@@ -885,6 +885,7 @@ static int __init early_init_dt_scan_cpu
const char *full_path, void *data)
{
char *type = get_flat_dt_prop(node, "device_type", NULL);
+ u32 *prop;
/* We are scanning "cpu" nodes only */
if (type == NULL || strcmp(type, "cpu") != 0)
@@ -916,6 +917,20 @@ static int __init early_init_dt_scan_cpu
}
}
+ /* Check if we have a VMX and eventually update CPU features */
+ prop = (u32 *)get_flat_dt_prop(node, "ibm,vmx", NULL);
+ if (prop && (*prop) > 0) {
+ cur_cpu_spec->cpu_features |= CPU_FTR_ALTIVEC;
+ cur_cpu_spec->cpu_user_features |= PPC_FEATURE_HAS_ALTIVEC;
+ }
+
+ /* Same goes for Apple's "altivec" property */
+ prop = (u32 *)get_flat_dt_prop(node, "altivec", NULL);
+ if (prop) {
+ cur_cpu_spec->cpu_features |= CPU_FTR_ALTIVEC;
+ cur_cpu_spec->cpu_user_features |= PPC_FEATURE_HAS_ALTIVEC;
+ }
+
return 0;
}
@@ -1104,7 +1119,9 @@ void __init early_init_devtree(void *par
DBG("Scanning CPUs ...\n");
- /* Retreive hash table size from flattened tree */
+ /* Retreive hash table size from flattened tree plus other
+* CPU related informations (altivec support, boot CPU ID, ...)
+*/
scan_flat_dt(early_init_dt_scan_cpus, NULL);
/* If hash size wasn't obtained above, we calculate it now based on
diff -puN
arch/ppc64/kernel/traps.c~ppc64-detect-altivec-via-firmware-on-unknown-cpus
arch/ppc64/kernel/traps.c
---
25/arch/ppc64/kernel/traps.c~ppc64-detect-altivec-via-firmware-on-unknown-cpus
2005-04-12 03:21:15.710748504 -0700
+++ 25-akpm/arch/ppc64/kernel/traps.c 2005-04-12 03:21:15.716747592 -0700
@@ -450,14 +450,12 @@ void kernel_fp_unavailable_exception(str
void altivec_unavailable_exception(struct pt_regs *regs)
{
-#ifndef CONFIG_ALTIVEC
if (user_mode(regs)) {
/* A user program has executed an altivec instruction,
but this kernel doesn't support altivec. */
_exception(SIGILL, regs, ILL_ILLOPC, regs->nip);
return;
}
-#endif
printk(KERN_EMERG "Unrecoverable VMX/Altivec Unavailable Exception "
"%lx at %lx\n", regs->trap, regs->nip);
die("Unrecoverable VMX/Altivec Unavailable Exception", regs, SIGABRT);
_
-
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] ppc64: add PT_NOTE section to vDSO
Hi !
This patch from Roland adds a PT_NOTE section to both 32 and 64 bits
vDSOs to expose the kernel version to glibc, thus avoiding a uname
syscall on every launch. This is equivalent to the patches Roland posted
already for x86 and x86-64.
Note: the 64 bits .note is actually using the 32 bits format. This is
normal. The ELF spec specifies a different format for 64 bits .note, but
for some reason, this was never properly implemented, the core dumps for
example are all using 32 bits format .note, and binutils cannot even
read a 64 bits format .note. Talking to our toolchain folks, they think
we'd rather stick to 32 bits format .note everywhere and get the spec
fixed some day ...
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Index: linux-work/arch/ppc64/kernel/vdso32/Makefile
===
--- linux-work.orig/arch/ppc64/kernel/vdso32/Makefile 2005-04-13
11:15:21.0 +1000
+++ linux-work/arch/ppc64/kernel/vdso32/Makefile2005-04-13
11:19:53.0 +1000
@@ -1,7 +1,7 @@
# List of files in the vdso, has to be asm only for now
-obj-vdso32 = sigtramp.o gettimeofday.o datapage.o cacheflush.o
+obj-vdso32 = sigtramp.o gettimeofday.o datapage.o cacheflush.o note.o
# Build rules
Index: linux-work/arch/ppc64/kernel/vdso32/vdso32.lds.S
===
--- linux-work.orig/arch/ppc64/kernel/vdso32/vdso32.lds.S 2005-04-13
11:15:21.0 +1000
+++ linux-work/arch/ppc64/kernel/vdso32/vdso32.lds.S2005-04-13
11:19:53.0 +1000
@@ -20,6 +20,8 @@
.gnu.version_d : { *(.gnu.version_d) }
.gnu.version_r : { *(.gnu.version_r) }
+ .note : { *(.note.*) } :text :note
+
. = ALIGN (16);
.text :
{
@@ -87,6 +89,7 @@
PHDRS
{
text PT_LOAD FILEHDR PHDRS FLAGS(5); /* PF_R|PF_X */
+ note PT_NOTE FLAGS(4); /* PF_R */
dynamic PT_DYNAMIC FLAGS(4); /* PF_R */
eh_frame_hdr 0x6474e550; /* PT_GNU_EH_FRAME, but ld doesn't match the name */
}
Index: linux-work/arch/ppc64/kernel/vdso64/Makefile
===
--- linux-work.orig/arch/ppc64/kernel/vdso64/Makefile 2005-04-13
11:15:21.0 +1000
+++ linux-work/arch/ppc64/kernel/vdso64/Makefile2005-04-13
11:20:35.0 +1000
@@ -1,6 +1,6 @@
# List of files in the vdso, has to be asm only for now
-obj-vdso64 = sigtramp.o gettimeofday.o datapage.o cacheflush.o
+obj-vdso64 = sigtramp.o gettimeofday.o datapage.o cacheflush.o note.o
# Build rules
Index: linux-work/arch/ppc64/kernel/vdso64/vdso64.lds.S
===
--- linux-work.orig/arch/ppc64/kernel/vdso64/vdso64.lds.S 2005-04-13
11:15:21.0 +1000
+++ linux-work/arch/ppc64/kernel/vdso64/vdso64.lds.S2005-04-13
11:19:53.0 +1000
@@ -18,12 +18,14 @@
.gnu.version_d : { *(.gnu.version_d) }
.gnu.version_r : { *(.gnu.version_r) }
+ .note : { *(.note.*) } :text :note
+
. = ALIGN (16);
.text :
{
*(.text .stub .text.* .gnu.linkonce.t.*)
*(.sfpr .glink)
- }
+ }:text
PROVIDE (__etext = .);
PROVIDE (_etext = .);
PROVIDE (etext = .);
@@ -88,6 +90,7 @@
PHDRS
{
text PT_LOAD FILEHDR PHDRS FLAGS(5); /* PF_R|PF_X */
+ note PT_NOTE FLAGS(4); /* PF_R */
dynamic PT_DYNAMIC FLAGS(4); /* PF_R */
eh_frame_hdr 0x6474e550; /* PT_GNU_EH_FRAME, but ld doesn't match the name */
}
Index: linux-work/arch/ppc64/kernel/vdso32/note.S
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-work/arch/ppc64/kernel/vdso32/note.S 2005-04-13 11:19:53.0
+1000
@@ -0,0 +1,25 @@
+/*
+ * This supplies .note.* sections to go into the PT_NOTE inside the vDSO text.
+ * Here we can supply some information useful to userland.
+ */
+
+#include
+#include
+
+#define ASM_ELF_NOTE_BEGIN(name, flags, vendor, type)\
+ .section name, flags; \
+ .balign 4;\
+ .long 1f - 0f; /* name length */ \
+ .long 3f - 2f; /* data length */ \
+ .long type; /* note type */ \
+0: .asciz vendor; /* vendor name */ \
+1: .balign 4;\
+2:
+
+#define ASM_ELF_NOTE_END \
+3: .balign 4; /* pad out section */ \
+ .previous
+
+ ASM_ELF_NOTE_BEGIN(".note.kernel-version", "a", UTS_SYSNAME, 0)
+
Re: [patch 2/3]: entry.S trap return fixes
Stas Sergeev <[EMAIL PROTECTED]> wrote:
>
> do_debug() returns void, do_int3() too when
> !CONFIG_KPROBES.
> This patch fixes the CONFIG_KPROBES variant
> of do_int3() to return void too and adjusts
> the entry.S accordingly.
>
This patch is applicable to the mainline kernel, is it not?
>
>
>
> [kgdbfix1.diff text/x-patch (1297 bytes)]
> --- linux/arch/i386/kernel/entry.S.old 2005-04-12 09:47:38.0
> +0400
> +++ linux/arch/i386/kernel/entry.S 2005-04-12 11:13:03.0 +0400
> @@ -550,8 +550,6 @@
> xorl %edx,%edx # error code 0
> movl %esp,%eax # pt_regs pointer
> call do_debug
> -testl %eax,%eax
> -jnz restore_all
> jmp ret_from_exception
>
> /*
> @@ -632,8 +630,6 @@
> xorl %edx,%edx # zero error code
> movl %esp,%eax # pt_regs pointer
> call do_int3
> -testl %eax,%eax
> -jnz restore_all
> jmp ret_from_exception
>
> ENTRY(overflow)
> --- linux/arch/i386/kernel/traps.c.old 2005-04-12 09:47:38.0
> +0400
> +++ linux/arch/i386/kernel/traps.c 2005-04-12 10:59:54.0 +0400
> @@ -695,16 +695,15 @@
> }
>
> #ifdef CONFIG_KPROBES
> -fastcall int do_int3(struct pt_regs *regs, long error_code)
> +fastcall void do_int3(struct pt_regs *regs, long error_code)
> {
> if (notify_die(DIE_INT3, "int3", regs, error_code, 3, SIGTRAP)
> == NOTIFY_STOP)
> -return 1;
> +return;
> /* This is an interrupt gate, because kprobes wants interrupts
> disabled. Normal trap handlers don't. */
> restore_interrupts(regs);
> do_trap(3, SIGTRAP, "int3", 1, regs, error_code, NULL);
> -return 0;
> }
> #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/
[patch 069/198] x86_64: disable interrupts during SMP bogomips checking
From: Andi Kleen <[EMAIL PROTECTED]>
Port over a i386 kludge from rusty to x86-64
I don't think it is a full solution, but the upcomming smp bootup rewrite
will solve it.
This fixes BUGs at bootup on bigger x86-64 systems.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/x86_64/kernel/smpboot.c |4
1 files changed, 4 deletions(-)
diff -puN
arch/x86_64/kernel/smpboot.c~x86_64-disable-interrupts-during-smp-bogomips-checking
arch/x86_64/kernel/smpboot.c
---
25/arch/x86_64/kernel/smpboot.c~x86_64-disable-interrupts-during-smp-bogomips-checking
2005-04-12 03:21:19.996097032 -0700
+++ 25-akpm/arch/x86_64/kernel/smpboot.c2005-04-12 03:21:19.999096576
-0700
@@ -304,8 +304,6 @@ static void __init smp_callin(void)
Dprintk("CALLIN, before setup_local_APIC().\n");
setup_local_APIC();
- local_irq_enable();
-
/*
* Get our bogomips.
*/
@@ -319,8 +317,6 @@ static void __init smp_callin(void)
*/
smp_store_cpu_info(cpuid);
- local_irq_disable();
-
/*
* Allow the master to continue.
*/
_
-
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 073/198] x86_64: Make IRDA devices are not really ISA devices not depend on CONFIG_ISA
From: "Andi Kleen" <[EMAIL PROTECTED]> This allows to use them on x86-64 Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- 25-akpm/drivers/net/irda/Kconfig | 10 +- 25-akpm/include/net/irda/irda_device.h |2 -- 25-akpm/net/irda/irda_device.c |4 +--- 3 files changed, 6 insertions(+), 10 deletions(-) diff -puN drivers/net/irda/Kconfig~x86_64-make-irda-devices-are-not-really-isa-devices-not drivers/net/irda/Kconfig --- 25/drivers/net/irda/Kconfig~x86_64-make-irda-devices-are-not-really-isa-devices-not 2005-04-12 03:21:20.901959320 -0700 +++ 25-akpm/drivers/net/irda/Kconfig2005-04-12 03:21:20.907958408 -0700 @@ -310,7 +310,7 @@ config SIGMATEL_FIR config NSC_FIR tristate "NSC PC87108/PC87338" - depends on IRDA && ISA + depends on IRDA help Say Y here if you want to build support for the NSC PC87108 and PC87338 IrDA chipsets. This driver supports SIR, @@ -321,7 +321,7 @@ config NSC_FIR config WINBOND_FIR tristate "Winbond W83977AF (IR)" - depends on IRDA && ISA + depends on IRDA help Say Y here if you want to build IrDA support for the Winbond W83977AF super-io chipset. This driver should be used for the IrDA @@ -347,7 +347,7 @@ config AU1000_FIR config SMC_IRCC_FIR tristate "SMSC IrCC (EXPERIMENTAL)" - depends on EXPERIMENTAL && IRDA && ISA + depends on EXPERIMENTAL && IRDA help Say Y here if you want to build support for the SMC Infrared Communications Controller. It is used in a wide variety of @@ -357,7 +357,7 @@ config SMC_IRCC_FIR config ALI_FIR tristate "ALi M5123 FIR (EXPERIMENTAL)" - depends on EXPERIMENTAL && IRDA && ISA + depends on EXPERIMENTAL && IRDA help Say Y here if you want to build support for the ALi M5123 FIR Controller. The ALi M5123 FIR Controller is embedded in ALi M1543C, @@ -385,7 +385,7 @@ config SA1100_FIR config VIA_FIR tristate "VIA VT8231/VT1211 SIR/MIR/FIR" - depends on IRDA && ISA && PCI + depends on IRDA help Say Y here if you want to build support for the VIA VT8231 and VIA VT1211 IrDA controllers, found on the motherboards using diff -puN include/net/irda/irda_device.h~x86_64-make-irda-devices-are-not-really-isa-devices-not include/net/irda/irda_device.h --- 25/include/net/irda/irda_device.h~x86_64-make-irda-devices-are-not-really-isa-devices-not 2005-04-12 03:21:20.902959168 -0700 +++ 25-akpm/include/net/irda/irda_device.h 2005-04-12 03:21:20.907958408 -0700 @@ -235,9 +235,7 @@ int irda_device_register_dongle(struct dongle_t *irda_device_dongle_init(struct net_device *dev, int type); int irda_device_dongle_cleanup(dongle_t *dongle); -#ifdef CONFIG_ISA void irda_setup_dma(int channel, dma_addr_t buffer, int count, int mode); -#endif void irda_task_delete(struct irda_task *task); struct irda_task *irda_task_execute(void *instance, diff -puN net/irda/irda_device.c~x86_64-make-irda-devices-are-not-really-isa-devices-not net/irda/irda_device.c --- 25/net/irda/irda_device.c~x86_64-make-irda-devices-are-not-really-isa-devices-not 2005-04-12 03:21:20.903959016 -0700 +++ 25-akpm/net/irda/irda_device.c 2005-04-12 03:21:20.908958256 -0700 @@ -470,11 +470,10 @@ void irda_device_unregister_dongle(struc } EXPORT_SYMBOL(irda_device_unregister_dongle); -#ifdef CONFIG_ISA /* * Function setup_dma (idev, buffer, count, mode) * - *Setup the DMA channel. Commonly used by ISA FIR drivers + *Setup the DMA channel. Commonly used by LPC FIR drivers * */ void irda_setup_dma(int channel, dma_addr_t buffer, int count, int mode) @@ -493,4 +492,3 @@ void irda_setup_dma(int channel, dma_add release_dma_lock(flags); } EXPORT_SYMBOL(irda_setup_dma); -#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/
[patch 071/198] x86_64 show_stack(): call touch_nmi_watchdog
I had strange NMI watchdog timeouts running sysrq-T across 9600-baud serial.
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/arch/x86_64/kernel/traps.c |2 ++
1 files changed, 2 insertions(+)
diff -puN arch/x86_64/kernel/traps.c~x86_64-show_stack-touch_nmi_watchdog
arch/x86_64/kernel/traps.c
--- 25/arch/x86_64/kernel/traps.c~x86_64-show_stack-touch_nmi_watchdog
2005-04-12 03:21:20.429031216 -0700
+++ 25-akpm/arch/x86_64/kernel/traps.c 2005-04-12 03:21:20.433030608 -0700
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -243,6 +244,7 @@ void show_stack(struct task_struct *tsk,
if (i && ((i % 4) == 0))
printk("\n ");
printk("%016lx ", *stack++);
+ touch_nmi_watchdog();
}
show_trace((unsigned long *)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/
Re: [PATCH] add EOWNERDEAD and ENOTRECOVERABLE
Joe Korty <[EMAIL PROTECTED]> wrote: > > This patch adds EOWNERDEAD and ENOTRECOVERABLE to all > architectures. Though there is nothing in the kernel > that uses them yet, I know of two patches in development, > one by Intel and the other by Bull, that adds robust mutex > support to pthread_mutex*. We normally have objections to reserving parts of the name/number space for external patches, but I think robust mutexes are sufficiently popular and important to justify us making your lives easier. Could you please reissue the patch, only add /* For robust mutexes */ in the appropriate places? Otherwise someone will come in and try to clean it up again. - 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/
