Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Andi Kleen wrote: We -used- to need data from RNG directly into the kernel randomness Are you sure? I dont think there was ever code to do this in mainline. There might have been something in -ac*, but not mainline. Yes, I am positive. I wrote the code. Look at the old Intel RNG driver code, before it grew AMD and VIA support, and became hw_random. pool. The consensus was that the FIPS testing should be moved to userspace. Consensus from whom? And who says the FIPS testing is useful anyways? lkml. Read the archives. I think you just need to trust the random generator, it is like you need to trust any other piece of hardware in your machine. Or do you check regularly if you mov instruction still works? @) Hardware RNGs -have- failed in the past. And if you are going to credit entropy to the data -- a very big deal -- it damn well better be random data. Otherwise failures cascade through the system. I think it is a trade off between easy to use and saving of resources and overly paranoia. With an user space solution which near nobody uses currently (I am not aware of any distribution that runs that daemon) Debian does. It's under-use is mainly because nobody has an RNG. it means most people wont have hardware supported randomness in their ssh, and I think that is a big drawback. "big drawback" == 99% of users right now. Jeff - 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] no need to check for NULL before calling kfree() -fs/ext2/
>> I see kfree used in several hot paths. Check out >> this /proc/latency_trace excerpt: > >Yes, but is the pointer being free'd NULL most of the time? "[...]In general, you should prefer to use actual profile feedback for this (`-fprofile-arcs'), as programmers are NOTORIOUSLY BAD AT PREDICTING how their programs actually perform." --gcc info pages. >The optimization does not help if you are releasing actual memory. It does not turn the real case (releasing memory) worse, but just improves the unreal case (releasing NULL). Jan Engelhardt -- No TOFU for me, please. - 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] s390: claw network device driver
Jeff Garzik <[EMAIL PROTECTED]> wrote: > > Linux Kernel Mailing List wrote: > > ChangeSet 1.2231.1.122, 2005/03/28 19:50:29-08:00, [EMAIL PROTECTED] > > > >[PATCH] s390: claw network device driver > > > >Add support for claw network devices. > > > >Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]> > >Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > >Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > Grumpity grump grump grump. How tough is it to send new net drivers to > netdev and me for review? Was cc'ed to linux-net last Thursday, but it looks like the messages was too large and the vger server munched it. - 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] API for true Random Number Generators to add entropy (2.6.11)
[EMAIL PROTECTED] wrote: pool. The consensus was that the FIPS testing should be moved to userspace. Consensus from whom? And who says the FIPS testing is useful anyways? I think you just need to trust the random generator, it is like you need to trust any other piece of hardware in your machine. Or do you check regularly if you mov instruction still works? @) For joe-user imho it's better to do a check from a cronjob once a day. But for That would not catch the hardware failures seen in the field, in the past. Jeff - 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] API for true Random Number Generators to add entropy (2.6.11)
Andi Kleen wrote: BTW what do you do when the FIPS test fails? I dont see a good fallback path for this case. If the FIPS test fails, do the obvious: don't feed that data to the kernel (and credit entropy), and possibly stop using the hardware RNG under a human has intervened. This is not rocket science. The fallback path is "use software", which is what most users do right now anyway. Jeff - 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: INITRAMFS: junk in compressed archive
> Kernel + compressed initramfs + uncompressed initramfs must fit in memory at > the same time. But that could not be the problem: initramfs packed: 6,4 MByte unpacked: 14,7 MByte kernelunpacked: 2,2 MByte 23,3 MByte 128 MByte RAM on the PC (?) - the kernel tells that the RAM is available. An other interesting thing is that the "checking if image is initramfs... it isn't (junk in compressed archive)" message disappeared after using smaller initramfs (using the same method to compress the .cpio.gz file!). Maybe my boot procedure is a problem(?): I've to remote-boot DOS via RPL, load Novell Client for DOS, copy Linux + initramfs to ramdisk and call loadlin (version 1.6c) to start Linux. Could there something remain in memory? The size of memory available to the PC should still be enough to hold both systems and also the DOS - Ramdisk in memory. Other Question: is (could) DOS-Ramdisk (be) available to Kernel? Maybe as MTD? regards Bernhard Schauer - 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] typo fix in drivers/scsi/sata_svw.c
Rolf Eike Beer wrote: Add missing brace. Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]> --- linux-2.6.11/drivers/scsi/sata_svw.c2005-03-21 11:41:58.0 +0100 +++ linux-2.6.12-rc1/drivers/scsi/sata_svw.c2005-03-27 15:50:38.0 +0200 Please send patches as directed: [EMAIL PROTECTED] linux-2.6]$ head -7 drivers/scsi/sata_svw.c /* * sata_svw.c - ServerWorks / Apple K2 SATA * * Maintained by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> and * Jeff Garzik <[EMAIL PROTECTED]> * Please ALWAYS copy linux-ide@vger.kernel.org * on emails. - 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] Reduce stack usage in module.c
Attempt to reduce stack usage in module.c (linux-2.6.12-rc1-mm3).
Specifically from checkstack.pl
Before patch
--
who_is_doing_it: 512
obsolete_params: 160
After patch
who_is_doing_it: none
obsolete_params: 12
Also while at it, fix following in who_is_doing_it(...)
- use only as much memory is needed
- do not write past array index for the boundary case
Patch is against linux-2.6.12-rc1-mm3
Thanks,
Rayan
Signed-off-by: Yum Rayan <[EMAIL PROTECTED]>
--- kernel/module.c.orig2005-03-28 22:32:35.0 -0800
+++ kernel/module.c 2005-03-28 22:49:26.0 -0800
@@ -769,15 +769,25 @@
struct kernel_param *kp;
unsigned int i;
int ret;
+ char *sym_name = NULL;
+ unsigned int sym_name_len = 0;
kp = kmalloc(sizeof(kp[0]) * num, GFP_KERNEL);
if (!kp)
return -ENOMEM;
- for (i = 0; i < num; i++) {
- char sym_name[128 + sizeof(MODULE_SYMBOL_PREFIX)];
+ if (num) {
+ sym_name_len = 128 + sizeof (MODULE_SYMBOL_PREFIX);
+ sym_name = kmalloc(sym_name_len, GFP_KERNEL);
+ if (!sym_name) {
+ ret = -ENOMEM;
+ goto free_kp;
+ }
+ }
- snprintf(sym_name, sizeof(sym_name), "%s%s",
+ for (i = 0; i < num; i++) {
+
+ snprintf(sym_name, sym_name_len, "%s%s",
MODULE_SYMBOL_PREFIX, obsparm[i].name);
kp[i].name = obsparm[i].name;
@@ -791,13 +801,15 @@
printk("%s: falsely claims to have parameter %s\n",
name, obsparm[i].name);
ret = -EINVAL;
- goto out;
+ goto free_sym;
}
kp[i].arg = [i];
}
ret = parse_args(name, args, kp, num, NULL);
- out:
+ free_sym:
+ kfree(sym_name);
+ free_kp:
kfree(kp);
return ret;
}
@@ -1399,12 +1411,16 @@
static void who_is_doing_it(void)
{
/* Print out all the args. */
- char args[512];
+ char *args;
unsigned long i, len = current->mm->arg_end - current->mm->arg_start;
if (len > 512)
len = 512;
+ args = kmalloc(len + 1, GFP_KERNEL);
+ if (!args)
+ return;
+
len -= copy_from_user(args, (void *)current->mm->arg_start, len);
for (i = 0; i < len; i++) {
@@ -1413,6 +1429,7 @@
}
args[i] = 0;
printk("ARGS: %s\n", args);
+ kfree(args);
}
/* Allocate and load the module: note that size of section 0 is always
-
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: [ubuntu-hardened] Re: Collecting NX information
> > You need to consider that in the end I'd need PT_GNU_STACK to do > everything PaX wants why? Why not have independent flags for independent things? That way you have both cleanness of design and you don't break anything. > The point is > to not break anything, yet to still make things easier for those > projects and distributions like Hardened Ubuntu. to achieve that you need to get the toolchain to omit this stuff automatically somehow. - 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] s390: qeth tcp segmentation offload
Linux Kernel Mailing List wrote:
ChangeSet 1.2231.1.121, 2005/03/28 19:50:10-08:00, [EMAIL PROTECTED]
[PATCH] s390: qeth tcp segmentation offload
Add support for TCP Segmentation Offload to the qeth network driver.
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
+static inline void
+qeth_eddp_copy_data_tcp(char *dst, struct qeth_eddp_data *eddp, int len,
+ u32 *hcsum)
+{
+ struct skb_frag_struct *frag;
+ int left_in_frag;
+ int copy_len;
+ u8 *src;
+
+ QETH_DBF_TEXT(trace, 5, "eddpcdtc");
+ if (skb_shinfo(eddp->skb)->nr_frags == 0) {
+ memcpy(dst, eddp->skb->data + eddp->skb_offset, len);
+ *hcsum = csum_partial(eddp->skb->data + eddp->skb_offset, len,
+ *hcsum);
+ eddp->skb_offset += len;
+ } else {
+ while (len > 0) {
+ if (eddp->frag < 0) {
+ /* we're in skb->data */
+ left_in_frag = qeth_get_skb_data_len(eddp->skb)
+ - eddp->skb_offset;
+ src = eddp->skb->data + eddp->skb_offset;
+ } else {
+ frag = _shinfo(eddp->skb)->
+ frags[eddp->frag];
+ left_in_frag = frag->size - eddp->frag_offset;
+ src = (u8 *)(
+ (page_to_pfn(frag->page) << PAGE_SHIFT)+
+ frag->page_offset + eddp->frag_offset);
+ }
+ if (left_in_frag <= 0) {
+ eddp->frag++;
+ eddp->frag_offset = 0;
+ continue;
+ }
+ copy_len = min(left_in_frag, len);
+ memcpy(dst, src, copy_len);
+ *hcsum = csum_partial(src, copy_len, *hcsum);
+ dst += copy_len;
+ eddp->frag_offset += copy_len;
+ eddp->skb_offset += copy_len;
+ len -= copy_len;
+ }
+ }
+}
Please help me understand: why add all this TSO code (zerocopy), if you
are adding memcpy() under the hood?
Was this reviewed on netdev? or by any network developer?
Overall this patch adds a whole lot of code that must be VERY intimate
with the net stack, a huge maintenance burden that is likely to be rife
with out-of-date code and bugs over time.
+static inline void
+qeth_eddp_create_segment_data_tcp(struct qeth_eddp_context *ctx,
+ struct qeth_eddp_data *eddp, int data_len,
+ u32 hcsum)
+{
+ u8 *page;
+ int page_remainder;
+ int page_offset;
+ struct qeth_eddp_element *element;
+ int first_lap = 1;
+
+ QETH_DBF_TEXT(trace, 5, "eddpcsdt");
+ page = ctx->pages[ctx->offset >> PAGE_SHIFT];
+ page_offset = ctx->offset % PAGE_SIZE;
+ element = >elements[ctx->num_elements];
+ while (data_len){
+ page_remainder = PAGE_SIZE - page_offset;
+ if (page_remainder < data_len){
+ qeth_eddp_copy_data_tcp(page + page_offset, eddp,
+ page_remainder, );
+ element->length += page_remainder;
+ if (first_lap)
+ element->flags = SBAL_FLAGS_FIRST_FRAG;
+ else
+ element->flags = SBAL_FLAGS_MIDDLE_FRAG;
+ ctx->num_elements++;
+ element++;
+ data_len -= page_remainder;
+ ctx->offset += page_remainder;
+ page = ctx->pages[ctx->offset >> PAGE_SHIFT];
+ page_offset = 0;
+ element->addr = page + page_offset;
+ } else {
+ qeth_eddp_copy_data_tcp(page + page_offset, eddp,
+ data_len, );
+ element->length += data_len;
+ if (!first_lap)
+ element->flags = SBAL_FLAGS_LAST_FRAG;
+ ctx->num_elements++;
+ ctx->offset += data_len;
+ data_len = 0;
+ }
+ first_lap = 0;
+ }
+ ((struct tcphdr *)eddp->th_in_ctx)->check = csum_fold(hcsum);
+}
+
+static inline u32
+qeth_eddp_check_tcp4_hdr(struct qeth_eddp_data *eddp, int data_len)
+{
+ u32 phcsum; /* pseudo header checksum */
Re: Strange memory problem with Linux booted from U-Boot
- Original Message -
From: "Jan Engelhardt" <[EMAIL PROTECTED]>
To: "Ara Avanesyan" <[EMAIL PROTECTED]>
Cc: ; <[EMAIL PROTECTED]>
Sent: Monday, March 28, 2005 8:06 PM
Subject: Re: Strange memory problem with Linux booted from U-Boot
> >Hi,
> >
> >I need some help on solving this strange problem.
> >Here is what I have,
> >I have a loadable module (linux.2.4.20) which contains a 2 mb static
gloabal
> >array.
> >
> >Additional information:
> >The same error occurs if I just run depmod -a.
>
> I'd be more interested in the kernel space code...
>
>
>
> Jan Engelhardt
> --
> No TOFU for me, please.
>
Oh, the code for kernel space is exactly the same code translated to C:
That is:
___
#include
void mtestit(char val)
{
char *buf;
int i, j;
int size = 64;
int pass = 2 * 1024 * 1024;
printk("starting val == %x\n", val);
buf = vmalloc(size);
printk("allocated memory of %d bytes. buf == %x\n", size, (int)buf);
for (j = 0; j < pass; j++)
{
printk("passing %d", j);
for (i = 0; i < size; i++)
{
buf[i] = val;
}
printk("passed\n");
}
printk("freeing\n");
vfree(buf);
printk("finished!\n");
}
___
I call this in a module's entry point and insmod that module.
now, mtestit(0xff) works, but mtestit(0x00) crashes:(
Works fine with RedBoot. Very strange to me:)
Moreover, works fine if I do the very same thing from
within U-Boot (mw.b 10 0 10).
I'm interested in ideas of what could potentially be the
cause of this strange behaviour.
__
Thanks,
Ara
-
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/2] fork_connector: add a fork connector
On Tue, Mar 29, 2005 at 11:04:16AM +0400, Evgeniy Polyakov wrote: > On Mon, 2005-03-28 at 13:42 -0800, Paul Jackson wrote: > > I don't see it in my copies of *-mm or recent Linus bk trees. Am I > > missing something? > > It was dropped from -mm tree, since bk tree where it lives > was in maintenance mode. > I think connector will be appeared in the next -mm release. Should have been in the last -mm release. If not, please let me know. thanks, greg k-h - 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/2] fork_connector: add a fork connector
On Mon, 2005-03-28 at 13:42 -0800, Paul Jackson wrote: > Guillaume wrote: > > The lmbench shows that the overhead (the construction and the sending > > of the message) in the fork() routine is around 7%. > > Thanks for including the numbers. The 7% seems a bit costly, for a bit > more accounting information. Perhaps dean's suggestion, to not use > ascii, will help. I hope so, though I doubt it will make a huge > difference. Was this 7% loss with or without a user level program > consuming the sent messages? I would think that the number of interest > would include a minimal consumer task. There is no overhead at all using CBUS. On my old P2/256mb SMP machine it took about 950 usec to create+exit process both with fork connector turned on and without it even compiled. Direct connector's method call took about 1000-1100 usec. Current fork connector does not use CBUS [yet, I hope]. > I don't see a good reason to make fork_connector() inline. Since it > calls other subroutines and is not just a few lines, perhaps better to > make it a real routine, so we can see it in "nm --print-size" output and > debug stacks. > > Having the "#ifdef CONFIG_FORK_CONNECTOR" chunk of code right in fork.c > seems unfortunate. Can the real fork_connector() be put elsewhere, and > the ifdef put in a header file that makes it a no-op if not configured, > or simply a function declaration, if configured? > > What's the status of the connector driver patch? I perhaps wasn't > paying close enough attention, but all I see of it now is a couple of > patches sent to lkml, from Evgeniy Polyakov, in September and January. > I don't see it in my copies of *-mm or recent Linus bk trees. Am I > missing something? It was dropped from -mm tree, since bk tree where it lives was in maintenance mode. I think connector will be appeared in the next -mm release. > This still seems to me like more apparatus than is desirable, just to > get another form of session id, as best as I can figure it. However > we've already been there, and apparently my concerns were not > persuasive. If one does go down this path, then using this connector > patch is a good an alternative as any I know of. Well, that or relayfs. > My uneducated assumption is that relayfs might at least batch data > packets up into big buffer chunks better, but someone more knowledgeable > than me needs to consider that. > > It's a little sad, when almost all the required accounting information > comes out in packed 64 byte records, carefully buffered and sent in > big chunks, to minimize per-task costs. Then this one extra detail, > of requires an entire netlink packet of > its own of what size -- another 50 or 100 bytes? Is this packet > received as a separate data packet, on its own recv(2) system call, > by the user task, not in a big block of packets? The efficiency > of getting this one extra out of the kernel > seems to be one or two orders of magnitude worse than the rest of > the accounting data. It can be easily changed. One may send kernel/acct.c acct_t structure out of the kernel - overhead will be the same: kmalloc probably will get new area from the same 256-bytes pool, skb is still in cache. > === > > Hmmm ... perhaps one could add a _second_ accounting file, cutting and > pasting code in kernel/acct.c and enabling writing additional > information to that second file, using the same mechanisms as now used > for the primary file. Use a more extensible record format for the > second file (say start each record with a magic cookie, a byte record > type and a byte record length, then that many bytes). That way, we have > an escape valve for adding additional record types in the future. > And that way we can efficiently write short records, with just say > a couple of interesting values, and minimal overhead. > > Don't worry if the magic cookie appears as part of the raw data. If one > has to resync such a data stream, one can look for a series of records, > each starting with the magic cookie, sensible record type byte, and a > length that ends right at the next such valid record. The occassional > duplication of the same cookie within the data stream would not thwart a > resync for long. And the main purpose of the magic cookie is to make > sure you are still in sync, not reverting to garbage-in, garbage-out, > mode. Almost any magic value other than 0x will suffice for that > purpose. > > I just ran a silly little test on my PC desktop Linux box, scanning > /proc/kcore. The _least_ common 2 byte word seen was 0x2B91, with 31 > instances in a half-billion words scanned, so I nominate that value for > the magic cookie ;). > > The key reason that it might make sense here to adapt the existing > accounting file direct write mechanism, rather than using "connector" or > "relayfs", is that we really do want to get this data to disk initially. > Relayfs is optimized for getting alot of data to a user daemon, and the > connector for
Re: How's the nforce4 support in Linux?
On Sat, 26 Mar 2005 15:13:47 +0100, Michal Schmidt
<[EMAIL PROTECTED]> wrote:
> Julien Wajsberg wrote:
> > Good point... I just tried, but forcedeth doesn't support netpoll. If
> > you have a pointer, I could try to implement it ;-)
>
> Can you try the attached patch for forcedeth?
> It compiles for me, but I don't have nForce hardware to test it.
Okay, it works :)
maybe I'll have something for you to debug at the next crash...
--
Julien
> --- linux-2.6.12-rc1/drivers/net/forcedeth.c.orig 2005-03-26
> 15:00:12.0 +0100
> +++ linux-2.6.12-rc1/drivers/net/forcedeth.c2005-03-26 15:08:56.0
> +0100
> @@ -1480,6 +1480,13 @@ static void nv_do_nic_poll(unsigned long
> enable_irq(dev->irq);
> }
>
> +#ifdef CONFIG_NET_POLL_CONTROLLER
> +static void nv_poll_controller(struct net_device *dev)
> +{
> + nv_do_nic_poll((long) dev);
> +}
> +#endif
> +
> static void nv_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo
> *info)
> {
> struct fe_priv *np = get_nvpriv(dev);
> @@ -1962,6 +1969,9 @@ static int __devinit nv_probe(struct pci
> dev->get_stats = nv_get_stats;
> dev->change_mtu = nv_change_mtu;
> dev->set_multicast_list = nv_set_multicast;
> +#ifdef CONFIG_NET_POLL_CONTROLLER
> + dev->poll_controller = nv_poll_controller;
> +#endif
> SET_ETHTOOL_OPS(dev, );
> dev->tx_timeout = nv_tx_timeout;
> dev->watchdog_timeo = NV_WATCHDOG_TIMEO;
>
>
>
-
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] kernel/param.c: don't use .max when .num is NULL in param_array_set()
On Sun, 2005-03-27 at 14:57 +0200, Bert Wesarg wrote: > Hello, > > there seems to be a bug, at least for me, in kernel/param.c for arrays > with .num == NULL. If .num == NULL, the function param_array_set() uses > &.max for the call to param_array(), wich alters the .max value to the > number of arguments. The result is, you can't set more array arguments as > the last time you set the parameter. Yes. But this ignores the larger problem, in that the printing routines need *some* way of telling how many to print. We could add a new element for this case, at the price of enlarging the structure a little for every array parameter. I think you'll find that with your patch, the code does this: $ insmod example.ko array=1,2,3 $ cat /sys/module/example/parameters/array 1,2,3,0,0,0,0,0,0,0 Cheers, Rusty. -- A bad analogy is like a leaky screwdriver -- Richard Braakman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel OOOPS in 2.6.11.6
On Mon, Mar 28, 2005 at 02:44:30PM -0800, Chris Wright wrote: > * Ali Akcaagac ([EMAIL PROTECTED]) wrote: > > And happy easter to you all. Just got this while trying to delete some > > files on my system. > ... > > : EIP is at linvfs_open+0x59/0xa0 > ... > Nothing in the -stable series has changed either XFS or the core vfs > path on during file open. Without a chance of reproducing or any more > information, it'll be tough to make much progress here. *nod*. Your full .config would be useful too, Ali, thanks. > with eax == . This corresponds to a vp->v_fops (or rather > vp->v_bh.bh_first->bd_ops) deref. So, looks like the vnode has a > NULL v_bh.bh_first (which looks like it's meant to be used to mean > uninitialized). May check with XFS folks if they've seen this type > of bug. Its not currently known. Looks like a possible iget-related race; does this one ring any bells, Christoph? cheers. -- Nathan - 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] no need to check for NULL before calling kfree() -fs/ext2/
On Mon, 28 Mar 2005 21:52:57 -0500, Lee Revell <[EMAIL PROTECTED]> wrote: > I see kfree used in several hot paths. Check out > this /proc/latency_trace excerpt: Yes, but is the pointer being free'd NULL most of the time? The optimization does not help if you are releasing actual memory. Pekka - 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: [linux-pm] Re: [RFC] Some thoughts on device drivers and sysfs
On Tuesday 29 March 2005 00:03, Greg KH wrote: > On Sun, Mar 27, 2005 at 02:24:59PM -0500, Adam Belay wrote: > > One of the original design goals of sysfs was to provide a standardized > > location to keep driver configuration attributes. ÂAlthough sysfs > > handles this very well for bus devices and class devices, there isn't > > currently a method to export attributes for device drivers and their > > specific bound device instances to userspace. > > Hm, what's device_create_file(), device_remove_file(), and DEVICE_ATTR() > for? ÂA number of drivers use these functions today to add their own > driver specific attributes to a device they control. > > Then, userspace can just do a simple: > ls /sys/bus/pci/drivers/my_foo_driver/ > to see all devices on the PCI bus that are controlled by that driver. > Then it can go into those directories and cat out the specific > information if needed. It probably would be nice if all driver-specific device attributes would be grouped under /sys/devices/...//drvattr/* so their names would not clash with names of driver core attributes. Unfortunately that would mean we are breaking userspace again... -- Dmitry - 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-rc1-bk2+PREEMPT_BKL: Oops at serio_interrupt
On Monday 28 March 2005 12:26, Alexey Dobriyan wrote:
> Steps to reproduce for me:
> * Boot CONFIG_PREEMPT_BKL=y kernel (.config, dmesg are attached)
> * Start rebooting
> * Start moving serial mouse (I have Genius NetMouse Pro)
> * Right after gpm is shut down I see the oops
> * The system continues to reboot
>
Could you try the patch below, please? Thanks!
--
Dmitry
===
Input: serport - fix an Oops when closing port - should not call
serio_interrupt when serio port is being unregistered.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
serport.c | 40 ++--
1 files changed, 38 insertions(+), 2 deletions(-)
Index: dtor/drivers/input/serio/serport.c
===
--- dtor.orig/drivers/input/serio/serport.c
+++ dtor/drivers/input/serio/serport.c
@@ -27,11 +27,14 @@ MODULE_LICENSE("GPL");
MODULE_ALIAS_LDISC(N_MOUSE);
#define SERPORT_BUSY 1
+#define SERPORT_ACTIVE 2
+#define SERPORT_DEAD 3
struct serport {
struct tty_struct *tty;
wait_queue_head_t wait;
struct serio *serio;
+ spinlock_t lock;
unsigned long flags;
};
@@ -49,10 +52,31 @@ static void serport_serio_close(struct s
{
struct serport *serport = serio->port_data;
- serport->serio->id.type = 0;
+ set_bit(SERPORT_DEAD, >flags);
wake_up_interruptible(>wait);
}
+static int serport_serio_start(struct serio *serio)
+{
+ struct serport *serport = serio->port_data;
+
+ spin_lock(>lock);
+ set_bit(SERPORT_ACTIVE, >flags);
+ spin_unlock(>lock);
+
+ return 0;
+}
+
+static void serport_serio_stop(struct serio *serio)
+{
+ struct serport *serport = serio->port_data;
+
+ spin_lock(>lock);
+ clear_bit(SERPORT_ACTIVE, >flags);
+ serport->serio = NULL;
+ spin_unlock(>lock);
+}
+
/*
* serport_ldisc_open() is the routine that is called upon setting our line
* discipline on a tty. It prepares the serio struct.
@@ -79,6 +103,7 @@ static int serport_ldisc_open(struct tty
serport->serio = serio;
set_bit(TTY_DO_WRITE_WAKEUP, >flags);
serport->tty = tty;
+ spin_lock_init(>lock);
tty->disc_data = serport;
memset(serio, 0, sizeof(struct serio));
@@ -87,6 +112,8 @@ static int serport_ldisc_open(struct tty
serio->id.type = SERIO_RS232;
serio->write = serport_serio_write;
serio->close = serport_serio_close;
+ serio->start = serport_serio_start;
+ serio->stop = serport_serio_stop;
serio->port_data = serport;
init_waitqueue_head(>wait);
@@ -117,8 +144,17 @@ static void serport_ldisc_receive(struct
{
struct serport *serport = (struct serport*) tty->disc_data;
int i;
+
+ spin_lock(>lock);
+
+ if (!test_bit(SERPORT_ACTIVE, >flags))
+ goto out;
+
for (i = 0; i < count; i++)
serio_interrupt(serport->serio, cp[i], 0, NULL);
+
+out:
+ spin_unlock(>lock);
}
/*
@@ -148,7 +184,7 @@ static ssize_t serport_ldisc_read(struct
serio_register_port(serport->serio);
printk(KERN_INFO "serio: Serial port %s\n", tty_name(tty, name));
- wait_event_interruptible(serport->wait, !serport->serio->id.type);
+ wait_event_interruptible(serport->wait, test_bit(SERPORT_DEAD,
>flags));
serio_unregister_port(serport->serio);
clear_bit(SERPORT_BUSY, >flags);
-
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-rc1-mm3
On Monday 28 March 2005 05:30, Reuben Farrelly wrote: > Hi, > > Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.6.12-rc1-mm3/ > > > > - Mainly a bunch of fixes relative to 2.6.12-rc1-mm2. > > > > - Again, we'd like people who have had recent DRM and USB resume problems to > > test and report, please. > > > > - The bk-ide-dev tree is back after a couple of weeks of difficulties. > > > > - Jeff asks that anyone who has had problems with the Silicon Image SATA > > drivers test sata_sil-corruption--lockup-fix.patch, which is included in > > this kernel. > > I'm repeatably getting this crash on shutdown in -mm3, and a few > releases earlier (but I can't be certain it was the same crash..) > It would be nice to know when it started breaking... At least point release, not -rc or -bk. -- Dmitry - 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: Do not misuse Coverity please (Was: sound/oss/cs46xx.c: fix a check after use)
Jean Delvare <[EMAIL PROTECTED]> wrote:
>
> > This patch fixes a check after use found by the Coverity checker.
> > (...)
> > 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;
>
> I see that you are fixing many bugs like this one today, all reported by
> Coverity. In all cases (as far as I could see at least) you are moving
> the dereference after the check. Of course it prevents any NULL pointer
> dereference, and will make Coverity happy. However, I doubt that this is
> always the correct solution.
>
> Think about it. If the pointer could be NULL, then it's unlikely that
> the bug would have gone unnoticed so far (unless the code is very
> recent). Coverity found 3 such bugs in one i2c driver [1], and the
> correct solution was to NOT check for NULL because it just couldn't
> happen.
No, there is a third case: the pointer can be NULL, but the compiler
happened to move the dereference down to after the check.
If the optimiser is later changed, or if someone tries to compile the code
with -O0, it will oops.
-
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/
a sales Pro's dream. Retire rich not old. $1000-$4500 commission per sale.
Hello , This email is compliant with the CAN-SPAM Act. http://www.ftc.gov/bcp/conline/pubs/buspubs/canspam.htm May I send you information about our powerful, talented team and our automated system do 90% of the work. Not MLM. Are you earning what you're worth or what you want? Have you achieved your life dreams yet? Why not retire rich, not old. If you would like info, call 1-800-570-3782 ext 1429 USA Leave your name, number, best time to call and your email address twice. Watch for email from Joan. Successful regards, Joan Kearns and The Team Directors/Trainers "If you rest, you rust" - Warren Miller P.S. This email is compliant with the CAN-SPAM Act. http://www.ftc.gov/bcp/conline/pubs/buspubs/canspam.htm This is permission marketing/advertising. You, or someone using using your email address, requested information on the internet about starting your own home business. If you no long wish to receive financial and/or opportunity information from us, click reply and type Re`move in the subject line. Your request will be honored promptly. Or you may click this link: [EMAIL PROTECTED] You may send a mail request to: CCW Joan Kearns 1735 N Story Road #129 Plymouth Park Irving, TX 75061 - 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: isofs: unobfuscate rock.c
Hi Andries, Andries Brouwer writes: Good! When Linus asked I audited rock.c and also did rather similar polishing - it happens automatically if one looks at this code. But it seems everybody is doing this right now, so I must wait a few weeks and see what got into Linus' tree. Linus plugged many but not all holes. (Maybe you did more?) I didn't fix anything. I tried to be very careful about preserving the current logic while making it more readable so I could find bugs :-). Pekka - 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: Can't use SYSFS for "Proprietry" driver modules !!!.
Mark Fortescue wrote: > Hi Greg, > > If you read the Linux Kernel header file "linux/module.h", there is a > section about Licenses. If "Proprietary" licences are not leagal, then why > are they supported ? Because it does want to let module authors tell the truth, however bleak. The GPL is quite unambiguous on the subject - the answer is "not allowed". But the GPL is a copyright license, not an EULA-style contract. If you feel confident that you can defend a case claiming that your driver was a derived work, it may not be necessary to agree to the terms at all. Only if the additional rights granted by GPL (such as the right to distribute derived works) are required, are you forced to accept it's terms in exchange for such rights. There are at least some who grudgingly accept that it may be possible to write drivers which are not derived works, at least if they stick to a interfaces which are widespread and in not specific to Linux. This is arguably a weakness of the GPL-as-copyright-license, but given the ideals it represents, arguing to strengthen the laws would be most counterproductive :-) > The implication of providing support for them in the header file is that > it is leagal to create and supply them. This is certainly something that could be argued from, but I don't know how successful you it would be. Only a court case could tell. > I am porting a driver to Linux for a third party. I do not know if they > whish to release the Linux driver under GPL so I have assumed (because of > the nature of the hardware) that they do not whish to. I will discus this > matter with them when I have finnished the driver. I would suggest you discuss it now; they take a while to get legal advice and make their decision. > The use of header files to build a propriatory object files/binaries or > the use of GCC to compile such a file does not breach GPL as if it did, > GCC and GLIBC would not be available for non GPL platforms and it would > not be posible to provide propriatory code for use in a Linux/GNU > environment. glibc and libgcc are not under a vanilla GPL. gcc itself is GPL, but it's fairly well accepted that the output of a tool is not a derived work and does not fall under that tool's copyright. Otherwise microsoft would be pocketing a slice of the royalties on everything written using Word. Even they haven't been that bold yet :-) In any case, these licenses carry specific exemptions allowing proprietary use. This is a deliberate choice on the part of their maintainers. > The Linux Kernel internal APIs are not mensioned in the Kernel GPL so it > can be argued quite reasonably that the APIs are not coverd by the GPL. I fail to see how this is even relevent. The kernel COPYING file specifically states the widely held (I won't claim universal - there's bound to be someone who would otherwise disagree) belief that the syscall interface is sufficiently generic; namely, that proprietary use at that level does not carry any implication that the proprietary component is a derived work. But this is only a clarification; it does this as the GPL's interpretation is quite broad. Nothing specific is said about internal kernel API, so it's covered by the GPL. > With regard to derived work - mensioned in a number of responses, a new > driver ported from MS Windows is derived from the Windows Driver not the > Linux Kernel. If it can be shown that there are sections of code in the This is the sort of claim that nVidia and ATI make - that the proprietary portions are not derived works. The fact that they are portable across multiple OSes, make use of only basic OS services, and predate the linux port, are reasonably good arguments to that effect. Assuming they aren't just crazy (which seems a good assumption) they apparently think they can win if anyone ever challenges them. Seemingly, so do most of the people complaining, since no court case has yet appeared about it. > new driver that have been coppied from other Linux drivers, then there is > a good argument with regard to derived code but it would still be very > difficult to prove that this code had not been written totally > independantly from the Linux drivers containing the same or similar code. > In addition the driver is being built as a module, out side of the kernel > source tree and as a result can be considered to be separate enterty to Built inside or outside is not a particularly compelling argument, though it certainly would be worth a mention if trying to put a case together. > the kernel. If it was required to be built into the kernel as apposed to > being a Kernel Module then it would be totally different and the driver > would need to be GPL. It wouldn't be all that different. Just another point of evidence in the decision of whether or not the addition was a derived work. > The hardware that this driver is being written for is low volume, very > specialised (with regard to its application). The driver will only be of And this has
Re: Do not misuse Coverity please (Was: sound/oss/cs46xx.c: fix a check after use)
On Mon, 28 Mar 2005, L. A. Walsh wrote: > However, in this case, if the author is _certain_ the > pointer can never be NULL, than an "ASSERT(card!=NULL);" might > be appropriate, where ASSERT is a macro that normally compiles > in the check, but could compile to "nothing" for embedded or > kernels that aren't being developed in. If the kernel dereferences a NULL pointer, it produces an extensive bug report. The automatic oops is about the most useful thing to do if a pointer is unexpectedly NULL. -Daniel *This .sig left intentionally blank* - 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: sched_setscheduler() and usage issues ....please help
>> > I am trying to set the SCHED_FIFO policy for my process.I am using >> > sched_setscheduler() function to do this. >> >> Attached is a little program that I use to set the priority of tasks. > >Why not just use chrt from schedtools? Not every distro has it yet, and I like to point out that a lot of users is still using "older" distros, such as FC2, SUSE 9.1, and also olders with Linux 2.4 kernels. Jan Engelhardt -- No TOFU for me, please. - 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: Can't use SYSFS for "Proprietry" driver modules !!!.
On 03/29/05 10:37:52AM +0800, Coywolf Qi Hunt wrote: > Lee Revell wrote: > >On Sat, 2005-03-26 at 10:28 -0800, Greg KH wrote: > > > >>On Sat, Mar 26, 2005 at 05:52:20PM +, Mark Fortescue wrote: > >> > >>>I am writing a "Proprietry" driver module for a "Proprietry" PCI card and > >>>I have found that I can't use SYSFS on Linux-2.6.10. > >>> > >>>Why ?. > >> > >>What ever gave you the impression that it was legal to create a > >>"Proprietry" kernel driver for Linux in the first place. > > > > > >The fact that Nvidia and ATI get away with it? > > I have the nvidia GeForce4 driver: NVIDIA-Linux-x86-1.0-6629-pkg1. > > $ ls NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/ > Makefile@makedevices.sh* nv-vm.c nv_compiler.h os-agp.c > os-registry.c > Makefile.kbuild makefile nv-vm.h nvidia.ko os-agp.h > os-registry.o > Makefile.nvidia nv-kernel.o nv-vm.o nvidia.mod.c os-agp.o > pat.h > README nv-linux.h nv.c nvidia.mod.o > os-interface.c precompiled/ > conftest.sh nv-memdbg.h nv.h nvidia.o > os-interface.h rmretval.h > gcc-version-check.c nv-misc.hnv.o nvtypes.h os-interface.o > > > So it seems nvidia has their kernel module `open'. Is it? See that 4.2M binary file called nv-kernel.o? That's the real driver, the open part is the glue, a sort of middle-ware so that the driver can be recompiled and loaded into any kernel. > > > 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/ - 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: Can't use SYSFS for "Proprietry" driver modules !!!.
On Mon, Mar 28, 2005 at 09:01:27PM -0800, Aaron Gyes wrote: > On Mon, 2005-03-28 at 20:45 -0800, Greg KH wrote: > > If after removed, that's not what udev is set up to do, sorry. > > There's no way to either a) Hack udev.conf to always create a node with > a certain major and minor No. > or b) A way to make sysfs trick udev? From userspace? No. > I'll kind of need to do this for nvidia and any other modules affected > by this change, or else switch back to the inferior devfs. I know debian provides a way for the udev startup script to create any static device node that you want to have be created. I suggest you look at that as an example to do what you wish. Also, vmware already supports using udev, yet it does not use sysfs. It does so by creating the device nodes in its startup script. There is no reason why you can't do the same thing in the nvidia driver. thanks, greg k-h - 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] Some thoughts on device drivers and sysfs
On Sun, Mar 27, 2005 at 02:24:59PM -0500, Adam Belay wrote: > One of the original design goals of sysfs was to provide a standardized > location to keep driver configuration attributes. Although sysfs > handles this very well for bus devices and class devices, there isn't > currently a method to export attributes for device drivers and their > specific bound device instances to userspace. Hm, what's device_create_file(), device_remove_file(), and DEVICE_ATTR() for? A number of drivers use these functions today to add their own driver specific attributes to a device they control. Then, userspace can just do a simple: ls /sys/bus/pci/drivers/my_foo_driver/ to see all devices on the PCI bus that are controlled by that driver. Then it can go into those directories and cat out the specific information if needed. Is there something that is lacking in the current code that you would like to see present? I don't think that adding another layer on top of a device would help out much here. thanks, greg k-h - 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: Can't use SYSFS for "Proprietry" driver modules !!!.
Aaron Gyes wrote: On Mon, 2005-03-28 at 20:45 -0800, Greg KH wrote: What do you mean by "static"? Something that persists over a reboot? Or after the device is removed? Forgot to clarify. Create a node for something that's not in sysfs, with udev. At least in Fedora, /etc/udev/makedevices.d or /etc/udev/devices. -- Brian Gerst - 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: Can't use SYSFS for "Proprietry" driver modules !!!.
On Mon, 2005-03-28 at 20:45 -0800, Greg KH wrote: > What do you mean by "static"? Something that persists over a reboot? > Or after the device is removed? Forgot to clarify. Create a node for something that's not in sysfs, with udev. - 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: How to measure time accurately.
krishna wrote: Hi All, Can any one tell me how to measure time accurately for a block of C code in device drivers. For example, If I want to measure the time duration of firmware download. Most cpus have some way of getting at a counter or decrementer of various frequencies. Usually it requires low-level hardware knowledge and often it needs assembly code. On ppc you'd use the mftbu/mftbl instructions, as suggested by Lee on x86 you'd use the rdtsc instruction. Chris - 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: Can't use SYSFS for "Proprietry" driver modules !!!.
On Mon, 2005-03-28 at 20:45 -0800, Greg KH wrote: > If after removed, that's not what udev is set up to do, sorry. There's no way to either a) Hack udev.conf to always create a node with a certain major and minor or b) A way to make sysfs trick udev? I'll kind of need to do this for nvidia and any other modules affected by this change, or else switch back to the inferior devfs. Aaron Gyes - 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/
$B4JC1!u0B?4$N=P2q$$(B
$B"#"""#"""#"""#"""#"""#"""#"""#"""#"""#"""#"""#"""#"""#"""#"""#"""#"""#"""#(B $B!!!y4JC1$K=P2q$&!&9b3NN(!y!!%F%-%9%HHG!!(BVol.084 $B"#"""#"""#"""#"""#"""#"""#"""#"""#"""#"""#"""#"""#"""#"""#"""#"""#"""#"""#(B [EMAIL PROTECTED]@-8r!K$r<}$a$k!!!z!D!D!D!D(B $B!y(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,!y(B $B!!$[$H$s$I$,%5%/%i1?1D$G$"$k!V=P2q$$7O%5%$%H!W$r96N,$9$k$?$a$N80$O!)(B $B!!$b$A$m$s%5%/%i$r8[$&$K$b?M7oHq$,$+$+$k!#2f!9$OL5BL$J!J%5%/%i!K?M7oHq(B $B!!$rGS=|$7!"[EMAIL PROTECTED];;$rAH$s$G$*$j$^$9!*(B $B!!(Bhttp://com.deai-pc.com/?num=10010 $B!D!D!D!D!z!!=P2q$$BN83<[EMAIL PROTECTED](B $B!y(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,!y(B [EMAIL PROTECTED]@n8)!!2#IM;T!!2qP!K(B $B!!A0J'[EMAIL PROTECTED]>!P!K(B $B!!%3%s%Q$H$+9T$/$H!"7k6I<~$j$K5$$r;H$C$A$c$C$F;}$A5"$l$J$$KM$G$9$,!"$3$s$J(B [EMAIL PROTECTED]@b$/:MG=$,$"$C$?$s$G$9$M!*!)(B $B!y(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,!y(B $B!!(Bhttp://com.deai-pc.com/?num=20010 $B!!!z5$;}$A$h$/=c?h$J=P2q$$$r3Z$7$`$?$a$K!"0B?4$NA0J'$$$r:NMQ$7$F$*$j$^$9(B $B!!!z<+F0E*$KNA6b$,H/@[EMAIL PROTECTED];$s(B $B!!!z%5%/%i!"$d$i$;$J$I!"[EMAIL PROTECTED];$s(B $B=P(-2q(-$$(-#P(-#C(-$G(-(B $B(,(0(,(0(,(0(,(0(,(0(,(0(B $BAG(-E((-$J(-%;(-%U(-%l(-$r(-(B $B(,(0(,(0(,(0(,(0(,(0(,(0(,(0(B $B#G(-#E(-#T(-$7(-$m(-!*(-(B $B(,(0(,(0(,(0(,(0(,(0(,(0(B $B"(Ev%a!<%k%^%,%8%s$OL5CGE>:\$r$41sN8$7$F$*$j$^$9(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/
Re: [RFC/PATCH 0/17][Kdump] Overview
On Mon, 2005-03-28 at 17:48 -0800, Andrew Morton wrote: > Vivek Goyal <[EMAIL PROTECTED]> wrote: > > > > Following patches (as in series file) need to be dropped before applying > > the fresh ones. > > > > crashdump-documentation.patch > > crashdump-memory-preserving-reboot-using-kexec.patch > > crashdump-routines-for-copying-dump-pages.patch > > crashdump-routines-for-copying-dump-pages-fixes.patch > > crashdump-elf-format-dump-file-access.patch > > crashdump-linear-raw-format-dump-file-access.patch > > crashdump-linear-raw-format-dump-file-access-coding-style.patch > > At some point we should stop tossing out patches and replacing them in this > manner. Andrew, I shall take care of sending incremental patches only next time onwards. The reason why I did this because changes were relatively large and I thought dropping the existing series and replacing it with new series (some patches retaining the old name) might be a better idea. > Because doing so makes it hard for people to see what has changed. > > It makes it hard for people to see that changes in the above patches > haven't been simply lost. > > And the fact that you were probably working against some kernel other than > -mm gives little confidence that the kdump development team have been > testing the patches which are presently in -mm. And that is what they are > there for. > > > - 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: sched_setscheduler() and usage issues ....please help
On Mon, 2005-03-28 at 23:40 -0500, Steven Rostedt wrote: > On Tue, 2005-03-29 at 08:58 +0530, Arun Srinivas wrote: > > I am trying to set the SCHED_FIFO policy for my process.I am using > > sched_setscheduler() function to do this. > > Attached is a little program that I use to set the priority of tasks. Why not just use chrt from schedtools? Lee - 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/
(no subject)
unsubscribe. Regards, Sumesh - 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: Can't use SYSFS for "Proprietry" driver modules !!!.
On Mon, Mar 28, 2005 at 09:03:29PM -0700, Zan Lynx wrote: > On Mon, 2005-03-28 at 19:33 -0800, Greg KH wrote: > > Also, the code has undergone a rewrite, fixing many issues, and changing > > the way things work to tie more closely into the main driver core code. > > As such, the class_simple code is now just gone, there is no such need > > for it. And as such, the new code contains the _GPL markings, as I do > > not think that _anyone_ can try to claim that their code would not be a > > derived work of Linux who wants to use it (as no other OS has such a > > driver model interface.) > > That does not really make sense, as the driver model code could be used > for ndiswrapper, for example. That would not make the Windows net > drivers derived code of the Linux kernel. ndiswrapper, yes it would be. > Binary driver blobs, no. > > ndiswrapper is a perfect example, in fact. It is GPL, and implements an > _interface_ to binary code that is not GPL. And do your lawyers deem ndiswrapper as something that is legal under the GPL? The ones I have talked to definitely do not feel that way. Again, why are we, non-lawyers arguing about this. If you work for a company that deals with Linux kernel issues, and you have any questions about the legality of _anything_, get a legal opinion. Don't rely on lkml for this. greg k-h - 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: Can't use SYSFS for "Proprietry" driver modules !!!.
On Mon, Mar 28, 2005 at 08:28:31PM -0800, Aaron Gyes wrote: > > In other news: How do I get udev to create a static node? What do you mean by "static"? Something that persists over a reboot? Or after the device is removed? If reboot, mount your /dev on a disk-backed filesystem, not a ramfs or tmpfs. If after removed, that's not what udev is set up to do, sorry. thanks, greg k-h - 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: sched_setscheduler() and usage issues ....please help
On Tue, 2005-03-29 at 08:58 +0530, Arun Srinivas wrote:
> I am trying to set the SCHED_FIFO policy for my process.I am using
> sched_setscheduler() function to do this.
Attached is a little program that I use to set the priority of tasks.
-- Steve
/* Copyright (C) 2004 Kihon Technologies Inc.
This utilities is free software, you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
These utilities are distributed in the hope that they will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with the GNU C Library; if not, write to the Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA. */
/*
* Author: Steven Rostedt
*/
#include
#include
#include
#include
#include
#include
void usage (char **argv)
{
char *arg = argv[0];
char *p = arg + strlen(arg);
while (p >= arg && *p != '/') p--;
p++;
fprintf(stderr,"usage: %s pid policy priority\n"
"\n\twhere policy is SCHED_RR, SCHED_FIFO or SCHED_OTHER\n"
"\n", p);
exit(-1);
}
int main (int argc, char **argv)
{
pid_t pid;
int policy;
struct sched_param p;
char *strpolicy;
if (argc != 4)
usage(argv);
strpolicy = argv[2];
pid = atoi(argv[1]);
p.sched_priority = atoi(argv[3]);
if (strcmp(strpolicy,"SCHED_RR")==0) {
policy = SCHED_RR;
} else if (strcmp(strpolicy,"SCHED_FIFO") == 0) {
policy = SCHED_FIFO;
} else if (strcmp(strpolicy,"SCHED_OTHER") == 0) {
policy = SCHED_OTHER;
} else {
fprintf(stderr,"\nunknown policy %s",strpolicy);
usage(argv);
}
if (sched_setscheduler(pid,policy,)) {
perror("sched_setscheduler");
exit(errno);
}
exit(0);
}
Re: Can't use SYSFS for "Proprietry" driver modules !!!.
On Mon, 2005-03-28 at 19:33 -0800, Greg KH wrote:
> I hope the above explanation is acceptable. If you have further
> questions, please do not hesitate to ask. And I would personally like
> to thank you for your civil tone. My current inbox reflects the rants
> of people without such civility at this time.
Beyond acceptable, thank you. I'll admit I started off (other posts in
this thread) somewhat upset ("That jerk broke the udev support in the
drivers I use!") But I've been somewhat swayed by what I've read. And I
guess if a license say something, it doesn't really matter how
inconvienient it is for me. (Though "derived work" is still pretty vague
and I eagerly await a lawsuite that will disambiguate it.
In other news: How do I get udev to create a static node?
Aaron Gyes
-
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: Can't use SYSFS for "Proprietry" driver modules !!!.
On Mon, 2005-03-28 at 19:33 -0800, Greg KH wrote: > Also, the code has undergone a rewrite, fixing many issues, and changing > the way things work to tie more closely into the main driver core code. > As such, the class_simple code is now just gone, there is no such need > for it. And as such, the new code contains the _GPL markings, as I do > not think that _anyone_ can try to claim that their code would not be a > derived work of Linux who wants to use it (as no other OS has such a > driver model interface.) That does not really make sense, as the driver model code could be used for ndiswrapper, for example. That would not make the Windows net drivers derived code of the Linux kernel. ndiswrapper, yes it would be. Binary driver blobs, no. ndiswrapper is a perfect example, in fact. It is GPL, and implements an _interface_ to binary code that is not GPL. It seems to me that any author has the right to create a public interface into the kernel. If that interface is well-defined and public, implementing it from the other side in binary code does not create a derived work. It is especially obvious if there are multiple interface implementations. Hard to argue that the same binary that links unchanged into Windows, BSD and Linux is Linux-derived. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Can't use SYSFS for "Proprietry" driver modules !!!.
On Mon, 2005-03-28 at 15:12 +0200, Geert Uytterhoeven wrote: > On Sun, 27 Mar 2005, Alan Cox wrote: > > On Sul, 2005-03-27 at 14:53, Wichert Akkerman wrote: > > > Are you sure? It is perfectly legal to relicense things if you own the > > > copyright. As long as he never distributes his GPL version I don't see > > > why he should have a problem. > > > > The GPL is a distribution license, it doesn't really matter what you do > > *internally* with GPL code. It might be a DMCA violation in the USSA but > > Is this a plain stupid typo, or am I missing a new joke? ;-( > That's quite an old joke actually. Lee - 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: Mac mini sound woes
On Mon, 2005-03-28 at 22:36 -0500, Lee Revell wrote: > On Mon, 2005-03-28 at 09:42 +1000, Benjamin Herrenschmidt wrote: > > It seems that Apple's driver has an in-kernel framework for doing volume > > control, mixing, and other horrors right in the kernel, in temporary > > buffers, just before they get DMA'ed (gack !) > > > > I want to avoid something like that. How "friendly" would Alsa be to > > drivers that don't have any HW volume control capability ? Does typical > > userland libraries provide software processing volume control ? Do you > > suggest I just don't do any control ? Or should I implement a double > > buffer scheme with software gain as well in the kernel driver ? > > alsa-lib handles both mixing (dmix plugin) and volume control (softvol > plugin) in software for codecs like this that don't do it in hardware. > Since Windows does mixing and volume control in the kernel (ugh) it's > increasingly common to find devices that cannot do these. You don't > need to handle it in the driver at all. Yah, OS X does it in the kernel too lately ... at least Apple drivers are doing it, it's not a "common" lib. They also split treble/bass that way when you have an iSub plugged on USB and using the machine internal speakers for treble. > dmix has been around for a while but softvol plugin is very new, you > will need ALSA CVS or the upcoming 1.0.9 release. Ok. Ben. - 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: How to measure time accurately.
On Mon, 2005-03-28 at 08:58 +0530, krishna wrote: > Hi All, > > Can any one tell me how to measure time accurately for a block of C code > in device drivers. > For example, If I want to measure the time duration of firmware download. rdtsc() - 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: Can't use SYSFS for "Proprietry" driver modules !!!.
On Mon, Mar 28, 2005 at 05:52:37PM +0100, Mark Fortescue wrote: > Hi Greg, > > If you read the Linux Kernel header file "linux/module.h", there is a > section about Licenses. If "Proprietary" licences are not leagal, then why > are they supported ? They are not "supported" in any sense of the word. > The implication of providing support for them in the header file is that > it is leagal to create and supply them. I'm sorry, but you need to consult with a lawyer about this issue, as I am not one, and you are asking me legal questions and asking for my advice, which is not the wisest thing to do :) Also, the current symbol markings for the sysfs and driver code interfaces are going to remain as is. thanks, greg k-h - 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: Can't use SYSFS for "Proprietry" driver modules !!!.
On Mon, Mar 28, 2005 at 05:04:37PM -0800, Aaron Gyes wrote: > On Sun, 2005-03-27 at 10:12 -0800, Greg KH wrote: > > No, that is not the general consensus at all. Please search the > > archives and the web for summaries of this discussion topic the last > > time it came up. > > > > greg k-h > > Hi. I've searched the archives about this stuff. It looks like you > attempted to change the EXPORT_SYMBOL's to EXPORT_SYMBOL_GPL for sysfs > stuff back in February, and the issue in general has come up many times. I only tried to change the class_simple code at that time. This was because the entire other driver core code was converted by the author of that code at the same time. The reason people complained about the class_simple code was because of vmware and nvidia. Since then, vmware has stated that they don't even like sysfs and udev, and dropped support for it entirely. Also, nvidia has told me that they do not like udev either, so they don't care about the sysfs code too. > A few people have made the point that Linus has said that changing > EXPORT_SYMBOL to EXPORT_SYMBOL_GPL is not okay, that they are supposed > to start off as EXPORT_SYMBOL_GPL or somesuch. And it seems last time > you tried it, something made you change it back. Yes, I was asked nicely to do so by some people I respect. Since then, I sought out the only closed source users of this code that I could find, and consulted them for what to do. As mentioned above, neither company has a problem with me doing this. Also, the code has undergone a rewrite, fixing many issues, and changing the way things work to tie more closely into the main driver core code. As such, the class_simple code is now just gone, there is no such need for it. And as such, the new code contains the _GPL markings, as I do not think that _anyone_ can try to claim that their code would not be a derived work of Linux who wants to use it (as no other OS has such a driver model interface.) > Can you explain this, please? I hope the above explanation is acceptable. If you have further questions, please do not hesitate to ask. And I would personally like to thank you for your civil tone. My current inbox reflects the rants of people without such civility at this time. thanks, greg k-h - 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: Mac mini sound woes
On Mon, 2005-03-28 at 09:42 +1000, Benjamin Herrenschmidt wrote: > It seems that Apple's driver has an in-kernel framework for doing volume > control, mixing, and other horrors right in the kernel, in temporary > buffers, just before they get DMA'ed (gack !) > > I want to avoid something like that. How "friendly" would Alsa be to > drivers that don't have any HW volume control capability ? Does typical > userland libraries provide software processing volume control ? Do you > suggest I just don't do any control ? Or should I implement a double > buffer scheme with software gain as well in the kernel driver ? alsa-lib handles both mixing (dmix plugin) and volume control (softvol plugin) in software for codecs like this that don't do it in hardware. Since Windows does mixing and volume control in the kernel (ugh) it's increasingly common to find devices that cannot do these. You don't need to handle it in the driver at all. dmix has been around for a while but softvol plugin is very new, you will need ALSA CVS or the upcoming 1.0.9 release. Lee - 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/
sched_setscheduler() and usage issues ....please help
I am trying to set the SCHED_FIFO policy for my process.I am using sched_setscheduler() function to do this. I am following the correct syntax and running it as root process.I am using the given syntax i.e., int sched_setscheduler(pid_t pid, int policy, const struct sched_param *p); (SCHED_FIFO for the policy and priority in the range of 1 to 99 for p). But the function returns with an value of -1. I am trying to call this function from the user-space. 1) Is this usage correct? 2)How do I read the error code (i.e., text description of what kiind of error occurred like for eg., ESRCH,EPERM,EINVAL). Please help. thanks Arun _ Don't know where to look for your life partner? http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?74 Trust BharatMatrimony.com - 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: Problems on Apple iBook with ALSA and snd-powermac [2.6.11.5]
On Mon, 2005-03-28 at 01:08 +0200, Martin Loschwitz wrote: > Hi folks, > > given that the alsa-user-mailinglist has some strange kind of authentication > mechanism, and admin-authorization and whatever, I'm writing this mail to the > LKML (it would have been CCed here anyway). Still off topic. ALSA bug reports should be filed here: https://bugtrack.alsa-project.org/alsa-bug/login_page.php Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel OOOPS in 2.6.11.6
On Tue, Mar 29, 2005 at 12:27:01PM +1000, Keith Owens wrote: > i386 needs unwind data plus a kernel unwinder to get accurate > backtraces. Without the data and an unwinder, i386 backtraces are > best guess. They often contain spurious addresses, from noise words > that were left on the kernel stack. Nothing to do with > CONFIG_4K_STACKS. XFS will break sometimes with 4K stacks on x86 - 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] optimization: defer bio_vec deallocation
On Mon, Mar 28, 2005 at 06:38:23PM -0800, Chen, Kenneth W wrote: > We have measured that the following patch give measurable performance gain > for industry standard db benchmark. Comments? Dave Jones wrote on Monday, March 28, 2005 7:00 PM > If you can't publish results from that certain benchmark due its stupid > restrictions, could you also try running an alternative benchmark that > you can show results from ? > > These nebulous claims of 'measurable gains' could mean anything. > I'm assuming you see a substantial increase in throughput, but > how much is it worth in exchange for complicating the code? Are you asking for micro-benchmark result? I had a tough time last time around when I presented micro-benchmark result on LKML. I got kicked in the butt for lack of evidence with performance data running real bench on real hardware. I guess either way, I'm bruised one way or the other. - 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] optimization: defer bio_vec deallocation
On Mon, Mar 28, 2005 at 06:38:23PM -0800, Chen, Kenneth W wrote: > We have measured that the following patch give measurable performance gain > for industry standard db benchmark. Comments? If you can't publish results from that certain benchmark due its stupid restrictions, could you also try running an alternative benchmark that you can show results from ? These nebulous claims of 'measurable gains' could mean anything. I'm assuming you see a substantial increase in throughput, but how much is it worth in exchange for complicating the code? Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.6.11.5 doesn't recognize Plextor 712 SATA DVD burner
OK, I took the plunge and dove into the code. Here is what I've discovered so far. scsi_scan_host_selected: <1:4294967295:4294967295:4294967295> scsi scan: INQUIRY pass 1 to host 1 channel 0 id 0 lun 0, length 36 ata1: command 0xa0 timeout, stat 0xd0 host_stat 0x1 scsi scan: INQUIRY failed with code 0x2 I don't yet know why the DVD burner is failing on the scsi INQUIRY command. Does anybody have any ideas? I plan to keep looking. Thanks, Andy -- Andy Stewart, Founder Worcester Linux Users' Group Worcester, MA, USA http://www.wlug.org - 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: kprobe_handler should check pre_handler function
On Mon, 28 Mar 2005 21:34:08 -0500 Ananth N Mavinakayanahalli <[EMAIL PROTECTED]> wrote: > You are right. The check for pre_handler is needed and here is a patch > against 2.6.12-rc1-mm3 that does this. The sparc64 part looks just fine. - 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] use cheaper elv_queue_empty when unplug a device
This patch was posted last year and if I remember correctly, Jens said he is OK with the patch. In function __generic_unplug_deivce(), kernel can use a cheaper function elv_queue_empty() instead of more expensive elv_next_request to find whether the queue is empty or not. blk_run_queue can also made conditional on whether queue's emptiness before calling request_fn(). Signed-off-by: Ken Chen <[EMAIL PROTECTED]> --- linux-2.6.11/drivers/block/ll_rw_blk.c.orig 2005-03-28 18:22:26.0 -0800 +++ linux-2.6.11/drivers/block/ll_rw_blk.c 2005-03-28 18:44:46.0 -0800 @@ -1459,7 +1459,7 @@ void __generic_unplug_device(request_que /* * was plugged, fire request_fn if queue has stuff to do */ - if (elv_next_request(q)) + if (!elv_queue_empty(q)) q->request_fn(q); } EXPORT_SYMBOL(__generic_unplug_device); @@ -1589,7 +1589,8 @@ void blk_run_queue(struct request_queue spin_lock_irqsave(q->queue_lock, flags); blk_remove_plug(q); - q->request_fn(q); + if (!elv_queue_empty(q)) + q->request_fn(q); spin_unlock_irqrestore(q->queue_lock, flags); } EXPORT_SYMBOL(blk_run_queue); - 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] no need to check for NULL before calling kfree() -fs/ext2/
On Sun, 2005-03-27 at 12:40 -0500, Dave Jones wrote:
> On Sun, Mar 27, 2005 at 05:12:58PM +0200, Jan Engelhardt wrote:
>
> > Well, kfree inlined was already mentioned but forgotten again.
> > What if this was used:
> >
> > inline static void kfree_WRAP(void *addr) {
> > if(likely(addr != NULL)) {
> > kfree_real(addr);
> > }
> > return;
> > }
> >
> > And remove the NULL-test in kfree_real()? Then we would have:
>
> Am I the only person who is completely fascinated by the
> effort being spent here micro-optimising something thats
> almost never in a path that needs optimising ?
> I'd be amazed if any of this masturbation showed the tiniest
> blip on a real workload, or even on a benchmark other than
> one crafted specifically to test kfree in a loop.
>
I see kfree used in several hot paths. Check out
this /proc/latency_trace excerpt:
(T1/#147) ksoftirqd/0 2 0 2 0002 0093 [0038603486826120]
0.133ms (+0.000ms): preempt_schedule+0x11/0x80
(rpc_wake_up_task+0x6c/0x80 )
(T1/#148) ksoftirqd/0 2 0 2 0001 0094 [0038603486826375]
0.133ms (+0.000ms): preempt_schedule+0x11/0x80
(udp_data_ready+0x1ca/0x270 )
(T1/#149) ksoftirqd/0 2 0 2 0001 0095 [0038603486826527]
0.133ms (+0.000ms): skb_free_datagram+0xb/0x30
(udp_data_ready+0x19c/0x270 )
(T1/#150) ksoftirqd/0 2 0 2 0001 0096 [0038603486826686]
0.133ms (+0.000ms): __kfree_skb+0xe/0xf0 (udp_data_ready+0x19c/0x270
)
(T1/#151) ksoftirqd/0 2 0 2 0001 0097 [0038603486826924]
0.133ms (+0.000ms): sock_rfree+0x8/0x20 (__kfree_skb+0x6b/0xf0
)
(T1/#152) ksoftirqd/0 2 0 2 0001 0098 [0038603486827082]
0.134ms (+0.000ms): kfree_skbmem+0xe/0x30 (__kfree_skb+0x76/0xf0
)
(T1/#153) ksoftirqd/0 2 0 2 0001 0099 [0038603486827189]
0.134ms (+0.000ms): skb_release_data+0xd/0xd0
(kfree_skbmem+0x19/0x30 )
(T1/#154) ksoftirqd/0 2 0 2 0001 009a [0038603486827444]
0.134ms (+0.000ms): skb_drop_fraglist+0xc/0x50
(skb_release_data+0xa3/0xd0 )
(T1/#155) ksoftirqd/0 2 0 2 0001 009b [0038603486827573]
0.134ms (+0.000ms): __kfree_skb+0xe/0xf0
(skb_drop_fraglist+0x35/0x50 )
(T1/#156) ksoftirqd/0 2 0 2 0001 009c [0038603486827733]
0.134ms (+0.000ms): kfree_skbmem+0xe/0x30 (__kfree_skb+0x76/0xf0
)
(T1/#157) ksoftirqd/0 2 0 2 0001 009d [0038603486827861]
0.134ms (+0.000ms): skb_release_data+0xd/0xd0
(kfree_skbmem+0x19/0x30 )
(T1/#158) ksoftirqd/0 2 0 2 0001 009e [0038603486828121]
0.134ms (+0.000ms): kfree+0x14/0x70 (kfree_skbmem+0x19/0x30
)
(T1/#159) ksoftirqd/0 2 0 2 0001 009f [0038603486828671]
0.135ms (+0.000ms): kmem_cache_free+0x14/0x60
(kfree_skbmem+0x2a/0x30 )
(T1/#160) ksoftirqd/0 2 0 2 0001 00a0 [0038603486829127]
0.135ms (+0.000ms): __kfree_skb+0xe/0xf0
(skb_drop_fraglist+0x35/0x50 )
(T1/#161) ksoftirqd/0 2 0 2 0001 00a1 [0038603486829341]
0.135ms (+0.000ms): kfree_skbmem+0xe/0x30 (__kfree_skb+0x76/0xf0
)
(T1/#162) ksoftirqd/0 2 0 2 0001 00a2 [0038603486829469]
0.135ms (+0.000ms): skb_release_data+0xd/0xd0
(kfree_skbmem+0x19/0x30 )
(T1/#163) ksoftirqd/0 2 0 2 0001 00a3 [0038603486829644]
0.135ms (+0.000ms): kfree+0x14/0x70 (kfree_skbmem+0x19/0x30
)
(T1/#164) ksoftirqd/0 2 0 2 0001 00a4 [0038603486829944]
0.136ms (+0.000ms): kmem_cache_free+0x14/0x60
(kfree_skbmem+0x2a/0x30 )
(T1/#165) ksoftirqd/0 2 0 2 0001 00a5 [0038603486830243]
0.136ms (+0.000ms): __kfree_skb+0xe/0xf0
(skb_drop_fraglist+0x35/0x50 )
(T1/#166) ksoftirqd/0 2 0 2 0001 00a6 [0038603486830463]
0.136ms (+0.000ms): kfree_skbmem+0xe/0x30 (__kfree_skb+0x76/0xf0
)
(T1/#167) ksoftirqd/0 2 0 2 0001 00a7 [0038603486830589]
0.136ms (+0.000ms): skb_release_data+0xd/0xd0
(kfree_skbmem+0x19/0x30 )
(T1/#168) ksoftirqd/0 2 0 2 0001 00a8 [0038603486830800]
0.136ms (+0.000ms): kfree+0x14/0x70 (kfree_skbmem+0x19/0x30
)
(T1/#169) ksoftirqd/0 2 0 2 0001 00a9 [0038603486831083]
0.137ms (+0.000ms): kmem_cache_free+0x14/0x60
(kfree_skbmem+0x2a/0x30 )
(T1/#170) ksoftirqd/0 2 0 2 0001 00aa [0038603486831394]
0.137ms (+0.000ms): __kfree_skb+0xe/0xf0
(skb_drop_fraglist+0x35/0x50 )
(T1/#171) ksoftirqd/0 2 0 2 0001 00ab [0038603486831608]
0.137ms (+0.000ms): kfree_skbmem+0xe/0x30 (__kfree_skb+0x76/0xf0
)
(T1/#172) ksoftirqd/0 2 0 2 0001 00ac [0038603486831736]
0.137ms (+0.000ms): skb_release_data+0xd/0xd0
(kfree_skbmem+0x19/0x30 )
(T1/#173) ksoftirqd/0 2 0 2 0001 00ad [0038603486831985]
0.137ms (+0.000ms): kfree+0x14/0x70 (kfree_skbmem+0x19/0x30
)
(T1/#174) ksoftirqd/0 2 0 2 0001 00ae [0038603486832443]
0.138ms (+0.000ms): kmem_cache_free+0x14/0x60
[RFC/PATCH 2.6.11.2 1/1] x86 reboot: Add reboot fixup for gx1/cs5530a
Hi Riley, Dave, Peter, i386 boot/workaround maintainers,
This patch incorporates the suggestions from the previous thread.
ie: add header, use dummy macro, describe safety in help.
Please let me know if it's okay.
Thanks,
Jaya Kumar
---
I ran into a problem getting reboot working with 2.6.11 on an embedded
board. The board has a Geode GX1 with a CS5530A companion. What I observe on
reboot is the "Restarting system" printk, and then a cpu stall/hang. I think
the problem arises because the keyboard controller is disabled by the BIOS,
so the traditional mach_reboot()'s output to port 0x64 is ignored. Then the
386 triple fault issued after mach_reboot() results in a shutdown (because
the hardware doesn't have to detect the triple fault and issue a reset).
That then gives the end result of a stalled cpu/hang.
I found that the CS5530A in question has a "issue system wide reset" bit.
The reboot works cleanly if I write that bit rather than do mach_reboot().
So the following patch is my attempt to incorporate that change into 2.6.11
by adding a X86_REBOOTFIXUPS option. In order to keep reboot.c free of hw
specific fixups, I put it in another file, reboot_fixups.c. I tried to make
it a bit generic so that if there are other reboot related fixups for other
chipsets/boards, there'd be a clean place to put it. Please let me know what
you think.
Thanks,
Jaya Kumar
---
Signed-off-by: Jaya Kumar <[EMAIL PROTECTED]>
diff -uprN -X dontdiff linux-2.6.11.2-vanilla/arch/i386/Kconfig
linux-2.6.11.2/arch/i386/Kconfig
--- linux-2.6.11.2-vanilla/arch/i386/Kconfig2005-03-10 16:31:25.0
+0800
+++ linux-2.6.11.2/arch/i386/Kconfig2005-03-29 09:44:58.053898616 +0800
@@ -645,6 +645,24 @@ config I8K
Say Y if you intend to run this kernel on a Dell Inspiron 8000.
Say N otherwise.
+config X86_REBOOTFIXUPS
+ bool "Enable X86 Board Specific Fixups for Reboot"
+ depends on X86
+ default n
+ ---help---
+ This enables chipset and/or board specific fixups to be done
+ in order to get reboot to work correctly. This is only needed on
+ some combinations of hardware and BIOS. The symptom, for which
+ this config is intended, is when reboot ends with a stalled/hung
+ system.
+
+ Currently, the only fixup is for the Geode GX1/CS5530A/TROM2.1.
+ combination.
+
+ Say Y if you want to enable the fixup. Currently, it's safe to
+ enable this option even if you don't need it.
+ Say N otherwise.
+
config MICROCODE
tristate "/dev/cpu/microcode - Intel IA32 CPU microcode support"
---help---
diff -uprN -X dontdiff linux-2.6.11.2-vanilla/arch/i386/kernel/Makefile
linux-2.6.11.2/arch/i386/kernel/Makefile
--- linux-2.6.11.2-vanilla/arch/i386/kernel/Makefile2005-03-10
16:31:25.0 +0800
+++ linux-2.6.11.2/arch/i386/kernel/Makefile2005-03-28 15:56:31.0
+0800
@@ -23,6 +23,7 @@ obj-$(CONFIG_X86_TRAMPOLINE) += trampoli
obj-$(CONFIG_X86_MPPARSE) += mpparse.o
obj-$(CONFIG_X86_LOCAL_APIC) += apic.o nmi.o
obj-$(CONFIG_X86_IO_APIC) += io_apic.o
+obj-$(CONFIG_X86_REBOOTFIXUPS) += reboot_fixups.o
obj-$(CONFIG_X86_NUMAQ)+= numaq.o
obj-$(CONFIG_X86_SUMMIT_NUMA) += summit.o
obj-$(CONFIG_KPROBES) += kprobes.o
diff -uprN -X dontdiff linux-2.6.11.2-vanilla/arch/i386/kernel/reboot.c
linux-2.6.11.2/arch/i386/kernel/reboot.c
--- linux-2.6.11.2-vanilla/arch/i386/kernel/reboot.c2005-03-10
16:31:25.0 +0800
+++ linux-2.6.11.2/arch/i386/kernel/reboot.c2005-03-29 09:35:19.858797632
+0800
@@ -13,6 +13,7 @@
#include
#include
#include "mach_reboot.h"
+#include
/*
* Power off function, if any
@@ -348,6 +349,7 @@ void machine_restart(char * __unused)
/* rebooting needs to touch the page at absolute addr 0 */
*((unsigned short *)__va(0x472)) = reboot_mode;
for (;;) {
+ mach_reboot_fixups(); /* for board specific fixups */
mach_reboot();
/* That didn't work - force a triple fault.. */
__asm__ __volatile__("lidt %0": :"m" (no_idt));
diff -uprN -X dontdiff linux-2.6.11.2-vanilla/arch/i386/kernel/reboot_fixups.c
linux-2.6.11.2/arch/i386/kernel/reboot_fixups.c
--- linux-2.6.11.2-vanilla/arch/i386/kernel/reboot_fixups.c 1970-01-01
07:30:00.0 +0730
+++ linux-2.6.11.2/arch/i386/kernel/reboot_fixups.c 2005-03-29
09:34:06.404964312 +0800
@@ -0,0 +1,53 @@
+/*
+ * linux/arch/i386/kernel/reboot_fixups.c
+ *
+ * This is a good place to put board specific reboot fixups.
+ *
+ */
+
+#include
+#include
+
+void cs5530a_warm_reset(struct pci_dev *dev)
+{
+ /* writing 1 to the reset control register, 0x44 causes the
+ cs5530a to perform a system warm reset */
+ pci_write_config_byte(dev, 0x44, 0x1);
+ udelay(50); /* shouldn't get here but be safe and
Re: Can't use SYSFS for "Proprietry" driver modules !!!.
Lee Revell wrote: On Sat, 2005-03-26 at 10:28 -0800, Greg KH wrote: On Sat, Mar 26, 2005 at 05:52:20PM +, Mark Fortescue wrote: I am writing a "Proprietry" driver module for a "Proprietry" PCI card and I have found that I can't use SYSFS on Linux-2.6.10. Why ?. What ever gave you the impression that it was legal to create a "Proprietry" kernel driver for Linux in the first place. The fact that Nvidia and ATI get away with it? I have the nvidia GeForce4 driver: NVIDIA-Linux-x86-1.0-6629-pkg1. $ ls NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/ Makefile@makedevices.sh* nv-vm.c nv_compiler.h os-agp.c os-registry.c Makefile.kbuild makefile nv-vm.h nvidia.ko os-agp.h os-registry.o Makefile.nvidia nv-kernel.o nv-vm.o nvidia.mod.c os-agp.o pat.h README nv-linux.h nv.c nvidia.mod.o os-interface.c precompiled/ conftest.sh nv-memdbg.h nv.h nvidia.o os-interface.h rmretval.h gcc-version-check.c nv-misc.hnv.o nvtypes.h os-interface.o So it seems nvidia has their kernel module `open'. Is it? 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] optimization: defer bio_vec deallocation
Kernel needs at least one bio and one bio_vec structure to process one I/O.
For every I/O, kernel also does two pairs of mempool_alloc/free, one for
bio and one for bio_vec. It is not exactly cheap in setup/tear down bio_vec
structure. bio_alloc_bs() does more things in that function other than the
minimally required mempool_alloc().
One optimization we are proposing is to defer the deallocation of bio_vec
at the next bio allocation. Let bio hang on to the bio_vec for the last
bio_put. And at next bio alloc time, check whether it has the same iovec
requirement. If it is, bingo! bio already has it. If not, then we free
previous iovec and allocate a new one. So in steady state, When I/O size
does not change much, we benefit from the deferred free, saving one pair
of alloc/free. If I/O request has random size or in dynamic state, then
we fall back and do the normal two pairs of alloc/free. We have measured
that the following patch give measurable performance gain for industry
standard db benchmark. Comments?
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1/fs/bio.c.orig 2005-03-28 13:49:37.0 -0800
+++ linux-2.6.12-rc1/fs/bio.c 2005-03-28 15:59:57.0 -0800
@@ -109,19 +109,15 @@ static inline struct bio_vec *bvec_alloc
*/
static void bio_destructor(struct bio *bio)
{
- const int pool_idx = BIO_POOL_IDX(bio);
struct bio_set *bs = bio->bi_set;
-
- BIO_BUG_ON(pool_idx >= BIOVEC_NR_POOLS);
-
- mempool_free(bio->bi_io_vec, bs->bvec_pools[pool_idx]);
mempool_free(bio, bs->bio_pool);
}
inline void bio_init(struct bio *bio)
{
bio->bi_next = NULL;
- bio->bi_flags = 1 << BIO_UPTODATE;
+ bio->bi_flags &= ~(BIO_POOL_MASK - 1);
+ bio->bi_flags |= 1 << BIO_UPTODATE;
bio->bi_rw = 0;
bio->bi_vcnt = 0;
bio->bi_idx = 0;
@@ -130,7 +126,6 @@ inline void bio_init(struct bio *bio)
bio->bi_hw_front_size = 0;
bio->bi_hw_back_size = 0;
bio->bi_size = 0;
- bio->bi_max_vecs = 0;
bio->bi_end_io = NULL;
atomic_set(>bi_cnt, 1);
bio->bi_private = NULL;
@@ -158,20 +153,37 @@ struct bio *bio_alloc_bioset(int gfp_mas
bio_init(bio);
if (likely(nr_iovecs)) {
- unsigned long idx;
-
- bvl = bvec_alloc_bs(gfp_mask, nr_iovecs, , bs);
- if (unlikely(!bvl)) {
- mempool_free(bio, bs->bio_pool);
- bio = NULL;
- goto out;
+ if (unlikely(nr_iovecs != bio->bi_max_vecs)) {
+ unsigned long idx;
+ if (bio->bi_max_vecs) {
+ struct bio_set *_bs = bio->bi_set;
+ idx = BIO_POOL_IDX(bio);
+ mempool_free(bio->bi_io_vec,
_bs->bvec_pools[idx]);
+ bio->bi_max_vecs = 0;
+ bio->bi_flags &= BIO_POOL_MASK - 1;
+ }
+ bvl = bvec_alloc_bs(gfp_mask, nr_iovecs, ,
bs);
+ if (unlikely(!bvl)) {
+ mempool_free(bio, bs->bio_pool);
+ bio = NULL;
+ goto out;
+ }
+ bio->bi_flags |= idx << BIO_POOL_OFFSET;
+ bio->bi_max_vecs = bvec_slabs[idx].nr_vecs;
+ bio->bi_io_vec = bvl;
+ bio->bi_set = bs;
+ }
+ } else {
+ /* a zero io_vec allocation, need to free io_vec */
+ if (bio->bi_max_vecs) {
+ unsigned long idx = BIO_POOL_IDX(bio);
+ struct bio_set *_bs = bio->bi_set;
+ mempool_free(bio->bi_io_vec,
_bs->bvec_pools[idx]);
+ bio->bi_io_vec = NULL;
+ bio->bi_max_vecs = 0;
+ bio->bi_set = bs;
}
- bio->bi_flags |= idx << BIO_POOL_OFFSET;
- bio->bi_max_vecs = bvec_slabs[idx].nr_vecs;
}
- bio->bi_io_vec = bvl;
- bio->bi_destructor = bio_destructor;
- bio->bi_set = bs;
}
out:
return bio;
@@ -1013,6 +1025,24 @@ bad:
return NULL;
}
+static void bio_ctor(void *p, kmem_cache_t *cachep, unsigned long flags)
+{
+ struct bio * bio = (struct bio*) p;
+ memset(bio, 0, sizeof(*bio));
+ bio->bi_destructor = bio_destructor;
+}
+
+static void bio_dtor(void *p, kmem_cache_t *cachep, unsigned
Re: kprobe_handler should check pre_handler function
On Mon, Mar 28, 2005 at 04:10:32PM -0500, William Cohen wrote:
Hi Will,
> I found kprobes expects there to be a pre_handler function in the
> structure. I was writing a probe that only needed a post_handler
> function, no pre_handler function. The probe was tracking the
> destinations of indirect calls and jumps, the probe needs to fire after
> the instruction single steps to get the target address. The probe
> crashed the machine because arch/i386/kernel/kprobe.c:kprobe_handler()
> blindly calls p->pre_handler(). There should be a check to verify that
> the pointer is non-null. There are cases where the pre_handler is not
> needed and it would make sense to set it to NULL. Thus, a check should
> be done for pre_handler like post_handler and fault_handler.
You are right. The check for pre_handler is needed and here is a patch
against 2.6.12-rc1-mm3 that does this.
Thanks,
Ananth
Signed-off-by: Ananth N Mavinakayanahalli <[EMAIL PROTECTED]>
diff -Narup temp/linux-2.6.12-rc1/arch/i386/kernel/kprobes.c
linux-2.6.12-rc1/arch/i386/kernel/kprobes.c
--- temp/linux-2.6.12-rc1/arch/i386/kernel/kprobes.c2005-03-17
20:34:10.0 -0500
+++ linux-2.6.12-rc1/arch/i386/kernel/kprobes.c 2005-03-28 17:51:21.0
-0500
@@ -159,17 +159,16 @@ static int kprobe_handler(struct pt_regs
if (is_IF_modifier(p->opcode))
kprobe_saved_eflags &= ~IF_MASK;
- if (p->pre_handler(p, regs)) {
+ if (p->pre_handler && p->pre_handler(p, regs))
/* handler has already set things up, so skip ss setup */
return 1;
- }
- ss_probe:
+ss_probe:
prepare_singlestep(p, regs);
kprobe_status = KPROBE_HIT_SS;
return 1;
- no_kprobe:
+no_kprobe:
preempt_enable_no_resched();
return ret;
}
diff -Narup temp/linux-2.6.12-rc1/arch/ppc64/kernel/kprobes.c
linux-2.6.12-rc1/arch/ppc64/kernel/kprobes.c
--- temp/linux-2.6.12-rc1/arch/ppc64/kernel/kprobes.c 2005-03-28
17:48:56.0 -0500
+++ linux-2.6.12-rc1/arch/ppc64/kernel/kprobes.c2005-03-28
17:51:31.0 -0500
@@ -128,10 +128,9 @@ static inline int kprobe_handler(struct
kprobe_status = KPROBE_HIT_ACTIVE;
current_kprobe = p;
kprobe_saved_msr = regs->msr;
- if (p->pre_handler(p, regs)) {
+ if (p->pre_handler && p->pre_handler(p, regs))
/* handler has already set things up, so skip ss setup */
return 1;
- }
ss_probe:
prepare_singlestep(p, regs);
diff -Narup temp/linux-2.6.12-rc1/arch/sparc64/kernel/kprobes.c
linux-2.6.12-rc1/arch/sparc64/kernel/kprobes.c
--- temp/linux-2.6.12-rc1/arch/sparc64/kernel/kprobes.c 2005-03-17
20:34:33.0 -0500
+++ linux-2.6.12-rc1/arch/sparc64/kernel/kprobes.c 2005-03-28
17:50:55.0 -0500
@@ -128,7 +128,7 @@ static int kprobe_handler(struct pt_regs
kprobe_status = KPROBE_HIT_ACTIVE;
current_kprobe = p;
- if (p->pre_handler(p, regs))
+ if (p->pre_handler && p->pre_handler(p, regs))
return 1;
ss_probe:
diff -Narup temp/linux-2.6.12-rc1/arch/x86_64/kernel/kprobes.c
linux-2.6.12-rc1/arch/x86_64/kernel/kprobes.c
--- temp/linux-2.6.12-rc1/arch/x86_64/kernel/kprobes.c 2005-03-28
17:48:57.0 -0500
+++ linux-2.6.12-rc1/arch/x86_64/kernel/kprobes.c 2005-03-28
17:51:10.0 -0500
@@ -293,17 +293,16 @@ int kprobe_handler(struct pt_regs *regs)
if (is_IF_modifier(p->ainsn.insn))
kprobe_saved_rflags &= ~IF_MASK;
- if (p->pre_handler(p, regs)) {
+ if (p->pre_handler && p->pre_handler(p, regs))
/* handler has already set things up, so skip ss setup */
return 1;
- }
- ss_probe:
+ss_probe:
prepare_singlestep(p, regs);
kprobe_status = KPROBE_HIT_SS;
return 1;
- no_kprobe:
+no_kprobe:
preempt_enable_no_resched();
return ret;
}
-
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] check nmi watchdog is broken
A bug against an xSeries system showed up recently
noting that the check_nmi_watchdog() test was failing.
I have been investigating it and discovered in both
i386 and x86_64 the recent change to the routine
to use the cpu_callin_map has uncovered a problem.
Prior to that change, on an SMP box, the test was
trivally passing because all cpu's were found to
not yet be online, but now with the callin_map they
are discovered, it goes on to test the counter
and they have not yet begun to increment, so it
announces a CPU is stuck and bails out.
On all the systems I have access to test, the announcement
of failure is also bougs... by the time you can login
and check /proc/interrupts, the NMI count is happily
incrementing on all CPUs. Its just that the test is
being done too early.
I have tried moving the call to the test around a bit,
and it was always too early. I finally hit on this
proposed solution, it delays the routine via a
late_initcall(), seems like the right solution to
me.
Please copy me on responses.
Regards,
Jack
diff -Naur linux-2.6.11/arch/i386/kernel/apic.c
linux-2.6.11-jfv/arch/i386/kernel/apic.c
--- linux-2.6.11/arch/i386/kernel/apic.c2005-03-01 23:38:33.0
-0800
+++ linux-2.6.11-jfv/arch/i386/kernel/apic.c2005-03-28 09:12:15.0
-0800
@@ -1265,8 +1265,6 @@
setup_local_APIC();
- if (nmi_watchdog == NMI_LOCAL_APIC)
- check_nmi_watchdog();
#ifdef CONFIG_X86_IO_APIC
if (smp_found_config)
if (!skip_ioapic_setup && nr_ioapics)
diff -Naur linux-2.6.11/arch/i386/kernel/io_apic.c
linux-2.6.11-jfv/arch/i386/kernel/io_apic.c
--- linux-2.6.11/arch/i386/kernel/io_apic.c 2005-03-01 23:37:54.0
-0800
+++ linux-2.6.11-jfv/arch/i386/kernel/io_apic.c 2005-03-28 09:13:05.0
-0800
@@ -2171,7 +2171,6 @@
disable_8259A_irq(0);
setup_nmi();
enable_8259A_irq(0);
- check_nmi_watchdog();
}
return;
}
@@ -2194,7 +2193,6 @@
add_pin_to_irq(0, 0, pin2);
if (nmi_watchdog == NMI_IO_APIC) {
setup_nmi();
- check_nmi_watchdog();
}
return;
}
diff -Naur linux-2.6.11/arch/i386/kernel/nmi.c
linux-2.6.11-jfv/arch/i386/kernel/nmi.c
--- linux-2.6.11/arch/i386/kernel/nmi.c 2005-03-01 23:38:10.0 -0800
+++ linux-2.6.11-jfv/arch/i386/kernel/nmi.c 2005-03-28 09:23:17.0
-0800
@@ -102,20 +102,21 @@
(P4_CCCR_OVF_PMI0|P4_CCCR_THRESHOLD(15)|P4_CCCR_COMPLEMENT| \
P4_CCCR_COMPARE|P4_CCCR_REQUIRED|P4_CCCR_ESCR_SELECT(4)|P4_CCCR_ENABLE)
-int __init check_nmi_watchdog (void)
+static int __init check_nmi_watchdog (void)
{
unsigned int prev_nmi_count[NR_CPUS];
int cpu;
- printk(KERN_INFO "testing NMI watchdog ... ");
+ if (nmi_watchdog == NMI_NONE)
+ return 0;
+
+ printk(KERN_INFO "Testing NMI watchdog ... ");
for (cpu = 0; cpu < NR_CPUS; cpu++)
prev_nmi_count[cpu] = irq_stat[cpu].__nmi_count;
local_irq_enable();
mdelay((10*1000)/nmi_hz); // wait 10 ticks
- /* FIXME: Only boot CPU is online at this stage. Check CPUs
- as they come up. */
for (cpu = 0; cpu < NR_CPUS; cpu++) {
#ifdef CONFIG_SMP
/* Check cpu_callin_map here because that is set
@@ -139,6 +140,8 @@
return 0;
}
+/* This needs to happen later in boot so counters are working */
+late_initcall(check_nmi_watchdog);
static int __init setup_nmi_watchdog(char *str)
{
diff -Naur linux-2.6.11/arch/i386/kernel/smpboot.c
linux-2.6.11-jfv/arch/i386/kernel/smpboot.c
--- linux-2.6.11/arch/i386/kernel/smpboot.c 2005-03-01 23:38:09.0
-0800
+++ linux-2.6.11-jfv/arch/i386/kernel/smpboot.c 2005-03-28 09:12:37.0
-0800
@@ -1077,9 +1077,6 @@
printk(KERN_WARNING "WARNING: %d siblings found for
CPU%d, should be %d\n", siblings, cpu, smp_num_siblings);
}
- if (nmi_watchdog == NMI_LOCAL_APIC)
- check_nmi_watchdog();
-
smpboot_setup_io_apic();
setup_boot_APIC_clock();
diff -Naur linux-2.6.11/arch/x86_64/kernel/io_apic.c
linux-2.6.11-jfv/arch/x86_64/kernel/io_apic.c
--- linux-2.6.11/arch/x86_64/kernel/io_apic.c 2005-03-01 23:38:09.0
-0800
+++ linux-2.6.11-jfv/arch/x86_64/kernel/io_apic.c 2005-03-28
09:24:28.0 -0800
@@ -1603,7 +1603,6 @@
disable_8259A_irq(0);
setup_nmi();
enable_8259A_irq(0);
- check_nmi_watchdog();
}
return;
}
@@ -1623,7
Re: Kernel OOOPS in 2.6.11.6
On Mon, 28 Mar 2005 18:06:08 -0800, Chris Wedgwood <[EMAIL PROTECTED]> wrote: >On Mon, Mar 28, 2005 at 04:24:15PM -0800, Chris Wright wrote: > >> Imperfect stack trace decoding. > >Is this with CONFIG_4K_STACKS? does it happen w/o it? i386 needs unwind data plus a kernel unwinder to get accurate backtraces. Without the data and an unwinder, i386 backtraces are best guess. They often contain spurious addresses, from noise words that were left on the kernel stack. Nothing to do with CONFIG_4K_STACKS. - 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: Can't use SYSFS for "Proprietry" driver modules !!!.
On Mar 28, 2005, at 20:53, David Schwartz wrote: The GPL explicitly permits you to modify the code as you wish, and this includes removing any restriction or enforcement type code. Yeah, sure, one could remove the technological enforcement, but IIRC the thread also brought up that you _still_ couldn't distribute anything that _used_ the broken type enforcement, because changing the source code to include the comment "This is Public Domain!" likewise doesn't make it so. Cheers, Kyle Moffett -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$ L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r !y?(-) --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel OOOPS in 2.6.11.6
On Mon, Mar 28, 2005 at 04:24:15PM -0800, Chris Wright wrote: > Imperfect stack trace decoding. Is this with CONFIG_4K_STACKS? does it happen w/o it? - 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 rc1-mm3] timers: simplify locking
Oleg Nesterov <[EMAIL PROTECTED]> wrote: > > This is the last one, I promise. > On top of "[PATCH rc1-mm3] timers: kill timer_list->lock", see > http://marc.theaimsgroup.com/?l=linux-kernel=93319932543 I thought that earlier patch was a bit weird and I think it would be better to get to the bottom of these problems which people have been reporting in the 2.6.12-rc1-mm3 timer code before adding more things, don't you? - 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 a clear_pages function to clear pages of higher order
On Sun, 27 Mar 2005, Andi Kleen wrote: > > Clearly, if the CPU that's clearing the page is likely to use that > > same page soon after, it'd be useful to use temporal stores. > > That is always the case in the current code (without Christophers > pre cleaning daemon). The page fault handler clears and user space > is guaranteed to need at least one cacheline from the fresh page > because it just did a page fault on it. With non temporal stores > you guarantee at least one hard cache miss directly after > the return to user space. It is not the case that *all* the cachelines of a page are going to be used right after zeroing. For the page fault case it is only guaranteed that *one* cacheline will be used. In the PTE/PMD/PUD page allocation cases it is likely that only a single cacheline is used. There are some cases in the code (apart from the fault handler) where zeroed pages are allocated with no guarantee of use (f.e. the allocations for buffers for shared memory or pipes). > I suspect even with precleaning the average time from cleaning to use will be > quite short. If the time is short then hot cleaning is the right way to go and then prezeroing is of no benefit. Prezeroing can only be of benefit if there is sufficient time between the zeroing and the use of the data. It must be sufficiently long to cause the the cachelines to no longer be in in the caches. Then the loading of these cachelines may be avoided which yields the performance benefit. - 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: Can't use SYSFS for "Proprietry" driver modules !!!.
> The GPL is a distribution license, it doesn't really matter what you do > *internally* with GPL code. It might be a DMCA violation in the USSA but > thats because the law is broken. You can't violate the DMCA on a GPL'd work. At least, if there's a way to do, I couldn't find it. See some of the previous posts on this list about whether the DMCA meant you couldn't remove the GPL tag on exported symbols. The GPL explicitly permits you to modify the code as you wish, and this includes removing any restriction or enforcement type code. DS - 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] Prezeroing V8
On Fri, 25 Mar 2005, Pavel Machek wrote: > > +unsigned int sysctl_scrub_start = 100; /* Min percentage of zeroed > > free pages per zone (~10% default) */ > > +unsigned int sysctl_scrub_stop = 300; /* Max percentage of zeroed > > free pages per zone (~30% default) */ > > +unsigned int sysctl_scrub_load = 1;/* Do not run scrubd if load > > > */ > Perhaps that variable should be called sysctl_scrub*d*_load? Hmm. Ok they are all now _scrubd_ instead.. > > + Scrubd is woken up if the system load is lower than this setting and > > + the numer of unzeroed free pages drops below scrub_start*10 percent. > > + The default setting of 1 insures that there will be no performance > > + degradation in single user mode. In an SMP system a cpu is frequently > > + idle despite the load being high. A setting of 9 or 99 may > > + be useful then. > > I don't think 1 guarantees no performance degradation. After all, it > is average load and scrubd might run at just the wrong times. Perhaps > it should default to 0? Correct. Changed the wording. Not sure about setting it to zero since its an experimental feature set to off by default. If one enables scrubd then the presumably something should be happening. - 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] new fifo I/O elevator that really does nothing at all
The noop elevator is still too fat for db transaction processing workload.
Since the db application already merged all blocks before sending it down,
the I/O presented to the elevator are actually not merge-able anymore. Since
I/O are also random, we don't want to sort them either. However the noop
elevator is still doing a linear search on the entire list of requests in
the queue. A noop elevator after all isn't really noop.
We are proposing a true no-op elevator algorithm, no merge, no nothing. Just
do first in and first out list management for the I/O request. The best name
I can come up with is "FIFO". I also piggy backed the code onto noop-iosched.c.
I can easily pull those code into a separate file if people object. Though, I
hope Jens is OK with it.
--- linux-2.6.11/drivers/block/noop-iosched.c.orig 2005-03-28
16:37:30.0 -0800
+++ linux-2.6.11/drivers/block/noop-iosched.c 2005-03-28 16:43:57.0
-0800
@@ -74,6 +74,21 @@ static struct request *elevator_noop_nex
return NULL;
}
+static void elevator_fifo_add_request(request_queue_t *q, struct request *rq,
+ int where)
+{
+ list_add_tail(>queuelist, >queue_head);
+}
+
+static struct elevator_type elevator_fifo = {
+ .ops = {
+ .elevator_next_req_fn = elevator_noop_next_request,
+ .elevator_add_req_fn= elevator_fifo_add_request,
+ },
+ .elevator_name = "fifo",
+ .elevator_owner = THIS_MODULE,
+};
+
static struct elevator_type elevator_noop = {
.ops = {
.elevator_merge_fn = elevator_noop_merge,
@@ -87,12 +102,14 @@ static struct elevator_type elevator_noo
static int __init noop_init(void)
{
- return elv_register(_noop);
+ return (elv_register(_noop) ||
+ elv_register(_fifo));
}
static void __exit noop_exit(void)
{
elv_unregister(_noop);
+ elv_unregister(_fifo);
}
module_init(noop_init);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH 0/17][Kdump] Overview
Vivek Goyal <[EMAIL PROTECTED]> wrote: > > Following patches (as in series file) need to be dropped before applying > the fresh ones. > > crashdump-documentation.patch > crashdump-memory-preserving-reboot-using-kexec.patch > crashdump-routines-for-copying-dump-pages.patch > crashdump-routines-for-copying-dump-pages-fixes.patch > crashdump-elf-format-dump-file-access.patch > crashdump-linear-raw-format-dump-file-access.patch > crashdump-linear-raw-format-dump-file-access-coding-style.patch At some point we should stop tossing out patches and replacing them in this manner. Because doing so makes it hard for people to see what has changed. It makes it hard for people to see that changes in the above patches haven't been simply lost. And the fact that you were probably working against some kernel other than -mm gives little confidence that the kdump development team have been testing the patches which are presently in -mm. And that is what they are there for. - 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: [-mm patch] always enable regparm on i386
Adrian Bunk <[EMAIL PROTECTED]> wrote: > > The patch below always enables regparm on i386 (with gcc >= 3.0). I'd prefer to keep the config option so that people can diagnose compiler and kernel bugs by disabling it. This has proved useful in the past. - 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] API for true Random Number Generators to add entropy (2.6.11)
On Wed, Mar 23, 2005 at 09:32:26PM -0800, Andrew Morton wrote:
> Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >
> > > It neither applies correctly nor compiles in current kernels. 2.6.11 is
> > > very old in kernel time.
> >
> > Hrm. This is getting pretty lame, if you can't take patches from the
> > -latest- stable release. It's pretty easy in BK:
> >
> > bk clone -ql -rv2.6.11 linux-2.6 rng-2.6.11
> > cd rng-2.6.11
> > { apply patch }
> > bk pull ../linux-2.6
> >
> > Can you set up something like that?
>
> About thirty patches have gone into random.c since 2.6.11. But the patch
> was easy enough to apply anyway.
>
> And then, it didn't compile. I don't think bk will fix that.
No, the names of all the pools changed. I agree with Jeff, this patch
is unnecessary. If we actually wanted such an interface, I'd rather it
refactor things so as not to reproduce the wake up logic.
--
Mathematics is the supreme nostalgia of our time.
-
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: Can't use SYSFS for "Proprietry" driver modules !!!.
On Mon, 2005-03-28 at 17:22 -0800, Paul Jackson wrote: > > So you are saying that a stand alone section of code, that needs > > wrappers to work with Linux is a derived work of Linux? > > Not what I said. > Good, so you most likely misunderstood me. OK, I've had enough of being devil's advocate. I'm usually fighting to get things under the GPL, or at least the LGPL, and I'm getting worn out fighting for the other side. Have a good one, I have work to do ;-) -- 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/
Re: Can't use SYSFS for "Proprietry" driver modules !!!.
On Mon, 2005-03-28 at 19:56 -0500, Kyle Moffett wrote: > On Mar 28, 2005, at 19:21, Steven Rostedt wrote: > > So you are saying that a stand alone section of code, that needs > > wrappers to work with Linux is a derived work of Linux? If there's > > some functionality, that you make, and it just happens to need > > some kind of operating system to work. Does that make it a derived > > work of any operating system? > > It depends on how special and different the wrappers for Linux are > from the wrappers for other operating systems. Like, for example, > the sysfs stuff is so radically different from the APIs that other > operating systems provide that anything using it is most likely > copied from other in-kernel sysfs code, and is therefore derived > from the Linux kernel. > If your stand alone code has it's own API and your GPL wrapper handles the sysfs interface, then this might get around it. > > OK, I took your advise and found this from googling: > > > > http://www.pbwt.com/Attorney/files/ravicher_1.pdf > > Mmm, good reference, thanks! > You're welcome! > > Unless you misunderstood me, and thought that I was talking > > about taking some part of Linux and making it work under another > > OS, I still stand by my statement. > > I think it really depends on the APIs implemented. Anything based > on the sysfs code, even if only using the APIs, will probably be > found to be a derivative work (NOTE: IANAL) because the sysfs API > is so very different from everything else. Other interfaces like > PCI management, memory management, etc, may not be so protectable, > because they are standard across many systems. If Linux got a > new and unique memory hotplug API, however, that might be a very > different story. Similar things could be said about integration > between drivers and the new Unified Driver Model, which appears to > be quite original. > Yes, but as the article states, ideas are not protected under copyright law. So an unique idea to handle hotplug then it may still not be covered. This is all very ambiguous, and is too confusing. I'll leave it up to the lawers! -- 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/
Re: [patch] posix-cpu-timers and cputime_t divisons.
Sorry I was not able to get back to you on this sooner. The various cputime-related fixes here are all fine and should go in. As you can see, I merged my code with the cputime stuff late in the game and quickly (and apparently somewhat carelessly). (I knew that you were going to have to add cputime_div, but I left it to you since cputime is your baby.) You are right about the incorrect use of do_div because the divisor is 64 bits, thanks for noticing that. But I'd like to see this fixed in a way that doesn't penalize the 64-bit platforms where using normal 64-bit division is perfectly fine to do. Probably BITS_PER_LONG==BITS_PER_LONG_LONG is a reasonable test for that. This patch as it is seems like a fine enough starting point, and fixes existing problems on 32-bit platforms. A fix to restore 64-bit platforms to the simple solution could come after. > What still worries me a bit is to use "timer->it.cpu.incr.sched == 0" > as check if the timer is armed at all. It should work but its not > really clean. It is not used that way. The only case of the expression you quoted is the one in bump_cpu_timer, which is checking whether the timer is set to reload or not. All-zeros is what the user interface is for indicating this (in timer_settime and setitimer). (bump_cpu_timer short-circuits the no-reload case to avoid trying divison by zero in the reload code path.) Perhaps you meant the "expires.sched" field? It is true that an expiry time of zero is used to mean a disabled timer. That is consistent with what's been done with jiffies timers in the past. It is clean enough in that 0 is never going to be the real expiry time of the timer, and moreover the user interface is the same (a timespec of zeros to disarm a timer). Or perhaps you are referring to using the ".sched == 0" tests for the disabled-zero value (for expiry and reload, in various places in the code), regardless of the flavor of value in the union actually in use? That is indeed not so clean. It seemed reasonable enough when the union members were unsigned long and unsigned long long. Now with cputime_t, it is theoretically opaque and you could be storing the value with a bias of -427 for all I know. (But, there may be other places we have around that assume that zeroed data structures including cputime_t's match cputime_zero.) These could at least be made a macro or inline to consolidate the slightly magic assumptions in a single spot. I wouldn't object to changing it to do something more fully kosher where we now have .sched = 0 assignments to clear any flavor or .sched == 0 tests to check any flavor for disarmed/no-reload, but only if it doesn't make the code gcc produces less optimal than we get now. Unfortunately gcc on x86 produces more code for ".sched == 0 && .cpu == 0" than the optimal code it yields for ".sched == 0" alone, though the two are functionally identical given the data layout. 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/
Re: Can't use SYSFS for "Proprietry" driver modules !!!.
> So you are saying that a stand alone section of code, that needs > wrappers to work with Linux is a derived work of Linux? Not what I said. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 1.925.600.0401 - 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] typo fix in Documentation/eisa.txt
Rolf Eike Beer wrote: Typo fixes. Thanks to Randy Dunlap and Jean Delvare. Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]> --- linux-2.6.11/Documentation/eisa.txt 2005-03-02 08:38:12.0 +0100 +++ linux-2.6.12-rc1/Documentation/eisa.txt 2005-03-27 21:58:04.0 +0200 @@ -171,9 +171,9 @@ virtual_root.force_probe : Force the probing code to probe EISA slots even when it cannot find an -EISA compliant mainboard (nothing appears on slot 0). Defaultd to 0 -(don't force), and set to 1 (force probing) when either -CONFIG_ALPHA_JENSEN or CONFIG_EISA_VLB_PRIMING are set. +EISA compliant mainboard (nothing appears on slot 0). Defaults to 0 +(don't force) and set to 1 (force probing) when either +CONFIG_ALPHA_JENSEN or CONFIG_EISA_VLB_PRIMING is set. --- 01234567890123456789012345678901234567890123456789012345678901234567890123456789 My expertise is limited by a fuzzy memory, and I know it's bad form to comment much on english usage or spelling as they are often tangential to the issue at hand, but as long as we are on the topic, I think you had it right the first time. I believe the comment, properly used the "imperative": declaring intended usage of the variable, i.e. - "Do this or do that"; "Default to 0 or set to 1". To use a perl like example: # set probe action: probe=0; # default to 0 (don't force) probe=1 if (X || Y); # and set to 1 (force), if either X or Y is set If you use "Defaults", then I think that's an implied 3rd person singular usage and for correct parallelism, the parallel clause (after the "and") should use the same tense. Third person tense for "set" would use "is" as a passive-voice auxiliary: "[it] is set to 1..." Saying "default to 0" is like the perlism: setup values of v: v=0; # default to 0 v=1 if (X || Y); # and set to 1 if X or Y is set I can't believe we are discussing grammer concerns in comments in the linux-kenel. :-) (!). -linda - 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: Can't use SYSFS for "Proprietry" driver modules !!!.
On Sun, 2005-03-27 at 10:12 -0800, Greg KH wrote: > No, that is not the general consensus at all. Please search the > archives and the web for summaries of this discussion topic the last > time it came up. > > greg k-h Hi. I've searched the archives about this stuff. It looks like you attempted to change the EXPORT_SYMBOL's to EXPORT_SYMBOL_GPL for sysfs stuff back in February, and the issue in general has come up many times. A few people have made the point that Linus has said that changing EXPORT_SYMBOL to EXPORT_SYMBOL_GPL is not okay, that they are supposed to start off as EXPORT_SYMBOL_GPL or somesuch. And it seems last time you tried it, something made you change it back. Can you explain this, please? - 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: Can't use SYSFS for "Proprietry" driver modules !!!.
On Mar 28, 2005, at 19:21, Steven Rostedt wrote: So you are saying that a stand alone section of code, that needs wrappers to work with Linux is a derived work of Linux? If there's some functionality, that you make, and it just happens to need some kind of operating system to work. Does that make it a derived work of any operating system? It depends on how special and different the wrappers for Linux are from the wrappers for other operating systems. Like, for example, the sysfs stuff is so radically different from the APIs that other operating systems provide that anything using it is most likely copied from other in-kernel sysfs code, and is therefore derived from the Linux kernel. OK, I took your advise and found this from googling: http://www.pbwt.com/Attorney/files/ravicher_1.pdf Mmm, good reference, thanks! Unless you misunderstood me, and thought that I was talking about taking some part of Linux and making it work under another OS, I still stand by my statement. I think it really depends on the APIs implemented. Anything based on the sysfs code, even if only using the APIs, will probably be found to be a derivative work (NOTE: IANAL) because the sysfs API is so very different from everything else. Other interfaces like PCI management, memory management, etc, may not be so protectable, because they are standard across many systems. If Linux got a new and unique memory hotplug API, however, that might be a very different story. Similar things could be said about integration between drivers and the new Unified Driver Model, which appears to be quite original. Cheers, Kyle Moffett -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$ L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r !y?(-) --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel OOOPS in 2.6.11.6
On Tue, 2005-03-29 at 08:12 +0800, Coywolf Qi Hunt wrote: > > > > with eax == . This corresponds to a vp->v_fops (or rather > > > > vp->v_bh.bh_first->bd_ops) deref. So, looks like the vnode has a > > > > NULL v_bh.bh_first (which looks like it's meant to be used to mean > > > > uninitialized). May check with XFS folks if they've seen this type > > > > of bug. > > > > > > I think it is f = kmem_cache_alloc(filp_cachep, GFP_KERNEL); returns an > > > invalid pointer, then in memset(f, 0, sizeof(*f)); fault happens at > > > address f. > > > eax == 0 is to clear the memory in memset(). > > > > The trace indicates it's in linvfs_open > > (EIP: 0060:[linvfs_open+89/160]) > > and the insturction dump at the end supports that. > > How to explain: > Call Trace: [get_empty_filp+89/208] get_empty_filp+0x59/0xd0 ? I like to let you know that this was all I got as dump. Was simply trying to copy some stuff from A to B on my harddisk using MC on a XFS partition using 2.6.11.6. Though I also detected another really strange thing together with this issue. On a valid XFS partition (no errors or something) I tried to delete about 160 CVS checked out modules (GNOME) and *buff* stuff couldn't be deleted anymore but I wasn't aware of this at that moment. Seconds later I was trying to copy stuff from A to B as described above and this gave me that hit. Luckely the hit caused let me continue using the System. I then tried to delete the stuff again and noticed that it hadn't deleted the CVS checkout in A) properly and that I copied the undeleted stuff to B) as well. I then inserted my own created rescue CD, mounted the partition again, and voila was able to delete the stuff xfs_repair check on it gave no errors or something. Maybe this helps isolating the issue. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel OOOPS in 2.6.11.6
* Coywolf Qi Hunt ([EMAIL PROTECTED]) wrote: > How to explain: > Call Trace: [get_empty_filp+89/208] get_empty_filp+0x59/0xd0 ? Imperfect stack trace decoding. thanks, -chris - 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: Can't use SYSFS for "Proprietry" driver modules !!!.
On Mon, 2005-03-28 at 15:43 -0800, Paul Jackson wrote: > > Writing code that needs wrappers is not derived work, if that code can > > also have wrappers for BSD, QNX and perhaps Windows. > > Just because it works with another O.S. doesn't mean it is not derived > from Linux code. Good grief. Try your lawyer, or at least a Google > search for something like "copyright derived work", for a better idea > of what "derived" means. > So you are saying that a stand alone section of code, that needs wrappers to work with Linux is a derived work of Linux? If there's some functionality, that you make, and it just happens to need some kind of operating system to work. Does that make it a derived work of any operating system? OK, I took your advise and found this from googling: http://www.pbwt.com/Attorney/files/ravicher_1.pdf It's a good read (I recommend you to read it), and it goes back to one of my first points, and that is the interpretation of a derived work is basically up to the judge that is handling the case. There's nothing set in stone here. It covers mainly US copyright law, and that's what I'm mainly concerned with. Unless you misunderstood me, and thought that I was talking about taking some part of Linux and making it work under another OS, I still stand by my statement. -- 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/
Re: Kernel OOOPS in 2.6.11.6
On Mon, 28 Mar 2005 15:04:16 -0800, Chris Wright <[EMAIL PROTECTED]> wrote: > * Coywolf Qi Hunt ([EMAIL PROTECTED]) wrote: > > On Mon, 28 Mar 2005 14:44:30 -0800, Chris Wright <[EMAIL PROTECTED]> wrote: > > > * Ali Akcaagac ([EMAIL PROTECTED]) wrote: > > > > And happy easter to you all. Just got this while trying to delete some > > > > files on my system. > > > > > > I'm curious, what was the virtual address the kernel was "Unable to > > > handle..." > > > That part was left off this bug report. > > > > > > > : printing eip: > > > > : c021f089 > > > > : *pde = > > > > : Oops: [#1] > > > > : PREEMPT > > > > : Modules linked in: snd_seq_midi snd_emu10k1_synth snd_emux_synth > > > > snd_seq_virmidi snd_seq_midi_event snd_seq_midi_emul snd_seq snd_emu10k1 > > > > snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer > > > > snd_page_alloc snd_util_mem snd_hwdep snd soundcore parport_pc lp > > > > parport 8139too mii crc32 > > > > : CPU:0 > > > > : EIP:0060:[linvfs_open+89/160]Not tainted VLI > > > > : EFLAGS: 00010282 (2.6.11.6) > > > > : EIP is at linvfs_open+0x59/0xa0 > > > > > > Nothing in the -stable series has changed either XFS or the core vfs > > > path on during file open. Without a chance of reproducing or any more > > > information, it'll be tough to make much progress here. > > > > > > > : eax: ebx: c77ac06c ecx: 0001 edx: c021f030 > > > > : esi: edi: c77ac050 ebp: dffe41a0 esp: c2d95f14 > > > > : ds: 007b es: 007b ss: 0068 > > > > : Process mc (pid: 17862, threadinfo=c2d94000 task=d18d2a80) > > > > : Stack: c01561a9 dffe41a0 d73504c0 c77ac06c c015446b c77ac06c > > > > d73504c0 > > > > :0001 ffe9 8000 8000 dc364000 c2d94000 c015426c > > > > cbcdff54 > > > > :dffe41a0 8000 c2d95f60 cbcdff54 dffe41a0 bfffeef0 0d00ad72 > > > > 0031 > > > > : Call Trace: > > > > : [get_empty_filp+89/208] get_empty_filp+0x59/0xd0 > > > > : [dentry_open+491/672] dentry_open+0x1eb/0x2a0 > > > > : [filp_open+92/112] filp_open+0x5c/0x70 > > > > : [get_unused_fd+123/224] get_unused_fd+0x7b/0xe0 > > > > : [sys_open+73/144] sys_open+0x49/0x90 > > > > : [syscall_call+7/11] syscall_call+0x7/0xb > > > > : Code: 5b 3c b8 01 00 00 00 e8 c6 42 ef ff b8 00 e0 ff ff 21 e0 8b 40 > > > > 08 a8 08 75 4d 85 f6 7c 0a 7f 32 81 fb ff ff ff 7f 77 2a 8b 47 14 <8b> > > > > 50 08 c7 44 24 04 00 00 00 00 89 04 24 ff 52 04 8b 5c 24 08 > > > > > > Best I can tell, you hit this: > > > > > > mov0x8(%eax),%edx > > > > > > with eax == . This corresponds to a vp->v_fops (or rather > > > vp->v_bh.bh_first->bd_ops) deref. So, looks like the vnode has a > > > NULL v_bh.bh_first (which looks like it's meant to be used to mean > > > uninitialized). May check with XFS folks if they've seen this type > > > of bug. > > > > I think it is f = kmem_cache_alloc(filp_cachep, GFP_KERNEL); returns an > > invalid pointer, then in memset(f, 0, sizeof(*f)); fault happens at address > > f. > > eax == 0 is to clear the memory in memset(). > > The trace indicates it's in linvfs_open > (EIP: 0060:[linvfs_open+89/160]) > and the insturction dump at the end supports that. How to explain: Call Trace: [get_empty_filp+89/208] get_empty_filp+0x59/0xd0 ? Thanks -- 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: Linux 2.4.30-rc3 md/ext3 problems
On Monday March 28, [EMAIL PROTECTED] wrote: > On Mon, Mar 28, 2005 at 10:34:05AM +0300, [Ville Herva] wrote: > > > > I just upgraded from linux-2.4.21 + vserser 0.17 to 2.4.30rc3 + vserver > > 1.2.10. The box has been running stable with 2.4.21 + vserver 0.17/0.16 for > > a few years (uptime before reboot was nearly 400 days.) > > > > The boot went fine, but after few hours I got > > Message from [EMAIL PROTECTED] at Sun Mar 27 22:07:00 2005 ... > > kernel: journal commit I/O error I got that error on 2.4.30-rc1 a couple of times, and now cannot reproduce it :-( But if you got it too, then it wasn't just bad luck. The ext3 code in 2.4.30-rc does have a few more checks for IO errors which will cause the journal to be aborted and produce this error, so I suspect that change which caused the problem is a change in ext3. However that doesn't mean the bug is there. The extra code in ext3 seems to just check if buffer_uptodate is false after it has waited on a locked buffer, and triggers a journal abort if it isn't. This should be perfectly safe, and I cannot find any logic error near by. But nor can I find any errors that would cause a buffer returned from raid1 to not be uptodate (unless there really was an IO error). NeilBrown - 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: Garbage on serial console after serial driver loads
> > > > Seems like you are correct, given the below patch fixes the garbage > > output for me. > > David, > > Is this patch ok for you? Just an aside, I've had this patch in my own internal tree for over a year I never thought it would be kernel acceptable... but I noticed this problem a long time ago and thought it was an issue with my internal hardware as I never saw it on a normal board... Dave. - 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: Do not misuse Coverity please (Was: sound/oss/cs46xx.c: fix a check after use)
Adrian Bunk wrote: On Sun, Mar 27, 2005 at 11:21:58PM +0200, Jean Delvare wrote: There are two cases: 1. NULL is impossible, the check is superfluous 2. this was an actual bug In the first case, my patch doesn't do any harm (a superfluous isn't a real bug). In the second case, it fixed a bug. It might be a bug not many people hit because it might be in some error path of some esoteric driver. If a maintainer of a well-maintained subsystem like i2c says "The check is superfluous." that's the perfect solution. But in less maintained parts of the kernel, even a low possibility that it fixes a possible bug is IMHO worth making such a riskless patch. --- I'd agree in [al]most any part of the kernel. Unless it is extremely time critical code, subroutines should expect possible garbage from their callers. Just because it may be perfect today doesn't mean someone down the line won't call the routine with less than perfect parameters. It used to be called "defensive" programming. However, in this case, if the author is _certain_ the pointer can never be NULL, than an "ASSERT(card!=NULL);" might be appropriate, where ASSERT is a macro that normally compiles in the check, but could compile to "nothing" for embedded or kernels that aren't being developed in. -linda Thanks, Jean Delvare cu Adrian - 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: read() on relayfs channel returns premature 0
On Thu, Mar 24, 2005 at 01:11:39PM -0600, Tom Zanussi wrote: > Kingsley Cheung writes: > > On Wed, Mar 23, 2005 at 09:29:12AM -0600, Tom Zanussi wrote: > > > [EMAIL PROTECTED] writes: > > > > > > > > Now I understand that this is not the latest release of relayfs (there > > > > are the redux patches, which I have yet to try). Nonetheless I'd like > > [...] > > > > > I've tested it on 2.6.10 with the pagg and relayfs patches from > > > > http://www.opersys.com/ftp/pub/relayfs/patch-relayfs-2.6.10-050113 > > > > and > > > > ftp://oss.sgi.com/projects/pagg/download/linux-2.6.10-pagg.patch-4 > > > > read() gives me a zero still once about a page of data has been read. > > > > Thanks - I've tried it out and haven't immediately been able to > reproduce the problem yet - I'll do some more pounding on it though > when I get the chance. Ok. It should be fairly easy to reproduce. On a dual 400MHz PII I've been able to get the zero by running one reader of the channel in parallel with a simple shell script like "while :; do ps -ef > /dev/null; done". > > BTW, I just want to point out that there aren't any problems with > read() in the version of relayfs included in the -mm tree (i.e. the > 'redux' version), since of course it doesn't support read(). Ok. > I went ahead and did a quick port of your stuff to the new version of > relayfs, which you can find here: > > http://prdownloads.sourceforge.net/dprobes/RelayfsModule-new.tar.bz2?download > > There's a README in the tarball with some notes on building and > running it. It includes both the kernel and user-side code, which makes > use of the relay-apps code and documentation found here (I've included > the necessary files in the RelayfsModule-new tarball so you don't have > to actually get this): > > http://prdownloads.sourceforge.net/dprobes/relay-apps-0.2.tar.gz?download > > Hopefully the new version will still be useful for what you're trying > to do, but it does differ in a couple important ways from the old > version, and points up the fact that the new relayfs really is now > much more specialized for high-volume applications - > > - your old version used 'packet' mode with read(). The new relayfs > only supports 'bulk' mode with mmap(), which means it's not really > useful for notification of single events. I'm not sure how important > that is for your application - if you're mainly interested in > collecting data, you can certainly use it even for low-volume > applications, but the events will be sent to user space in 'blocks'. > You can modify the user space app to process blocks of events as they > come in, and play around with buffer sizes to get them more often, but > it's not quite the same thing. > > - your old version used a single buffer, while the new relayfs only > supports per-cpu buffers, which means you'd have to sort out the > events in user space and impose some ordering using timestamps for > instance if your data doesn't already have a natural ordering (BTW, > the new relayfs doesn't have an option any longer to do automatic > timestamping either). Right. Thanks for all your work on it Tom . I really appreciate it. I have been considering a move over to the redux version recently. Your port will make it easier for me to test both versions out. I'll keep your pointers in mind. > I'll continue maintaining the old relayfs for existing users (so > thanks for the patch and the test code) so if the new version doesn't > fit your needs, you'll still have the old version to fall back on. > > Thanks, > > Tom Ok. Thanks again! -- Kingsley - 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: Can't use SYSFS for "Proprietry" driver modules !!!.
> Writing code that needs wrappers is not derived work, if that code can > also have wrappers for BSD, QNX and perhaps Windows. Just because it works with another O.S. doesn't mean it is not derived from Linux code. Good grief. Try your lawyer, or at least a Google search for something like "copyright derived work", for a better idea of what "derived" means. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 1.925.600.0401 - 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 2.6.12-rc1-mm3 3/3] perfctr: mapped state cleanup: common
perfctr common updates for mapped state cleanup:
- Update virtual.c for perfctr_cpu_state layout change.
- Add perfctr sysfs attribute providing user-space with the offset
in an mmap()ed perfctr object to the user-visible state.
Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>
drivers/perfctr/init.c|7 +++
drivers/perfctr/version.h |2 +-
drivers/perfctr/virtual.c | 46 +++---
3 files changed, 31 insertions(+), 24 deletions(-)
diff -rupN linux-2.6.12-rc1-mm3/drivers/perfctr/init.c
linux-2.6.12-rc1-mm3.perfctr-mapped-state-cleanup-common/drivers/perfctr/init.c
--- linux-2.6.12-rc1-mm3/drivers/perfctr/init.c 2005-03-28 17:26:13.0
+0200
+++
linux-2.6.12-rc1-mm3.perfctr-mapped-state-cleanup-common/drivers/perfctr/init.c
2005-03-28 23:05:37.0 +0200
@@ -42,6 +42,12 @@ tsc_to_cpu_mult_show(struct class *class
}
static ssize_t
+state_user_offset_show(struct class *class, char *buf)
+{
+ return sprintf(buf, "%u\n", (unsigned int)offsetof(struct
perfctr_cpu_state, user));
+}
+
+static ssize_t
cpus_online_show(struct class *class, char *buf)
{
int ret = cpumask_scnprintf(buf, PAGE_SIZE-1, cpu_online_map);
@@ -62,6 +68,7 @@ static struct class_attribute perfctr_cl
__ATTR_RO(cpu_features),
__ATTR_RO(cpu_khz),
__ATTR_RO(tsc_to_cpu_mult),
+ __ATTR_RO(state_user_offset),
__ATTR_RO(cpus_online),
__ATTR_RO(cpus_forbidden),
__ATTR_NULL
diff -rupN linux-2.6.12-rc1-mm3/drivers/perfctr/version.h
linux-2.6.12-rc1-mm3.perfctr-mapped-state-cleanup-common/drivers/perfctr/version.h
--- linux-2.6.12-rc1-mm3/drivers/perfctr/version.h 2005-03-28
17:26:14.0 +0200
+++
linux-2.6.12-rc1-mm3.perfctr-mapped-state-cleanup-common/drivers/perfctr/version.h
2005-03-28 23:05:37.0 +0200
@@ -1 +1 @@
-#define VERSION "2.7.12"
+#define VERSION "2.7.14"
diff -rupN linux-2.6.12-rc1-mm3/drivers/perfctr/virtual.c
linux-2.6.12-rc1-mm3.perfctr-mapped-state-cleanup-common/drivers/perfctr/virtual.c
--- linux-2.6.12-rc1-mm3/drivers/perfctr/virtual.c 2005-03-28
17:26:14.0 +0200
+++
linux-2.6.12-rc1-mm3.perfctr-mapped-state-cleanup-common/drivers/perfctr/virtual.c
2005-03-28 23:05:37.0 +0200
@@ -54,7 +54,7 @@ struct vperfctr {
struct work_struct work;
struct task_struct *parent_tsk;
};
-#define IS_RUNNING(perfctr)
perfctr_cstatus_enabled((perfctr)->cpu_state.cstatus)
+#define IS_RUNNING(perfctr)
perfctr_cstatus_enabled((perfctr)->cpu_state.user.cstatus)
#ifdef CONFIG_PERFCTR_INTERRUPT_SUPPORT
@@ -254,9 +254,9 @@ static void vperfctr_ihandler(unsigned l
__FUNCTION__, tsk->pid);
return;
}
- if (!perfctr_cstatus_has_ictrs(perfctr->cpu_state.cstatus)) {
+ if (!perfctr_cstatus_has_ictrs(perfctr->cpu_state.user.cstatus)) {
printk(KERN_ERR "%s: BUG! vperfctr has cstatus %#x (pid %d,
comm %s)\n",
- __FUNCTION__, perfctr->cpu_state.cstatus, tsk->pid,
tsk->comm);
+ __FUNCTION__, perfctr->cpu_state.user.cstatus, tsk->pid,
tsk->comm);
return;
}
vperfctr_suspend(perfctr);
@@ -279,12 +279,12 @@ static void vperfctr_handle_overflow(str
perfctr->ireload_needed = 1;
/* suspend a-mode and i-mode PMCs, leaving only TSC on */
/* XXX: some people also want to suspend the TSC */
- perfctr->resume_cstatus = perfctr->cpu_state.cstatus;
+ perfctr->resume_cstatus = perfctr->cpu_state.user.cstatus;
if (perfctr_cstatus_has_tsc(perfctr->resume_cstatus)) {
- perfctr->cpu_state.cstatus = perfctr_mk_cstatus(1, 0, 0);
+ perfctr->cpu_state.user.cstatus = perfctr_mk_cstatus(1, 0, 0);
vperfctr_resume(perfctr);
} else
- perfctr->cpu_state.cstatus = 0;
+ perfctr->cpu_state.user.cstatus = 0;
si.si_signo = perfctr->si_signo;
si.si_errno = 0;
si.si_code = SI_PMC_OVF;
@@ -383,7 +383,7 @@ static void vperfctr_unlink(struct task_
owner->thread.perfctr = NULL;
task_unlock(owner);
- perfctr->cpu_state.cstatus = 0;
+ perfctr->cpu_state.user.cstatus = 0;
perfctr->resume_cstatus = 0;
if (do_unlink)
put_vperfctr(perfctr);
@@ -418,15 +418,15 @@ static void do_vperfctr_release(struct v
if (parent_perfctr && child_perfctr) {
spin_lock(_perfctr->children_lock);
if (parent_perfctr->inheritance_id ==
child_perfctr->inheritance_id) {
- cstatus = parent_perfctr->cpu_state.cstatus;
+ cstatus = parent_perfctr->cpu_state.user.cstatus;
if (perfctr_cstatus_has_tsc(cstatus))
parent_perfctr->children.tsc +=
- child_perfctr->cpu_state.tsc_sum
[PATCH 2.6.12-rc1-mm3 2/3] perfctr: mapped state cleanup: ppc32
perfctr ppc32 mapped state cleanup:
- Swap cstatus and k1 fields in struct perfctr_cpu_state. Move
now contiguous user-visible fields to struct perfctr_cpu_state_user.
Hide kernel-private stuff. Inline now obsolete k1 struct. Cleanups.
Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>
drivers/perfctr/ppc.c | 104 ++
include/asm-ppc/perfctr.h | 40 -
2 files changed, 71 insertions(+), 73 deletions(-)
diff -rupN linux-2.6.12-rc1-mm3/drivers/perfctr/ppc.c
linux-2.6.12-rc1-mm3.perfctr-mapped-state-cleanup-ppc32/drivers/perfctr/ppc.c
--- linux-2.6.12-rc1-mm3/drivers/perfctr/ppc.c 2005-03-28 17:26:14.0
+0200
+++
linux-2.6.12-rc1-mm3.perfctr-mapped-state-cleanup-ppc32/drivers/perfctr/ppc.c
2005-03-28 23:07:20.0 +0200
@@ -15,9 +15,7 @@
/* Support for lazy evntsel and perfctr SPR updates. */
struct per_cpu_cache { /* roughly a subset of perfctr_cpu_state */
- union {
- unsigned int id;/* cache owner id */
- } k1;
+ unsigned int id;/* cache owner id */
/* Physically indexed cache of the MMCRs. */
unsigned int ppc_mmcr[3];
};
@@ -81,18 +79,18 @@ void perfctr_cpu_set_ihandler(perfctr_ih
static inline void
set_isuspend_cpu(struct perfctr_cpu_state *state, int cpu)
{
- state->k1.isuspend_cpu = cpu;
+ state->isuspend_cpu = cpu;
}
static inline int
is_isuspend_cpu(const struct perfctr_cpu_state *state, int cpu)
{
- return state->k1.isuspend_cpu == cpu;
+ return state->isuspend_cpu == cpu;
}
static inline void clear_isuspend_cpu(struct perfctr_cpu_state *state)
{
- state->k1.isuspend_cpu = NR_CPUS;
+ state->isuspend_cpu = NR_CPUS;
}
#else
@@ -234,12 +232,12 @@ static void ppc_read_counters(struct per
{
unsigned int cstatus, nrctrs, i;
- cstatus = state->cstatus;
+ cstatus = state->user.cstatus;
if (perfctr_cstatus_has_tsc(cstatus))
ctrs->tsc = get_tbl();
nrctrs = perfctr_cstatus_nractrs(cstatus);
for(i = 0; i < nrctrs; ++i) {
- unsigned int pmc = state->pmc[i].map;
+ unsigned int pmc = state->user.pmc[i].map;
ctrs->pmc[i] = read_pmc(pmc);
}
}
@@ -301,7 +299,7 @@ static int ppc_check_control(struct perf
for(i = 0; i < nrctrs; ++i) {
pmc = state->control.pmc_map[i];
- state->pmc[i].map = pmc;
+ state->user.pmc[i].map = pmc;
if (pmc >= nr_pmcs || (pmc_mask & (1control.header.nrictrs)
return -EINVAL;
- state->k1.id = new_id();
+ state->id = new_id();
/*
* MMCR0[FC] and MMCR0[TRIGGER] may change on 74xx if FCECE or
@@ -355,14 +353,14 @@ static int ppc_check_control(struct perf
case PM_7450:
case PM_7400:
if (state->control.mmcr0 & (MMCR0_FCECE | MMCR0_TRIGGER))
- state->cstatus =
perfctr_cstatus_set_mmcr0_quirk(state->cstatus);
+ state->user.cstatus =
perfctr_cstatus_set_mmcr0_quirk(state->user.cstatus);
default:
;
}
/* The MMCR0 handling for FCECE and TRIGGER is also needed for PMXE. */
if (state->control.mmcr0 & (MMCR0_PMXE | MMCR0_FCECE | MMCR0_TRIGGER))
- state->cstatus =
perfctr_cstatus_set_mmcr0_quirk(state->cstatus);
+ state->user.cstatus =
perfctr_cstatus_set_mmcr0_quirk(state->user.cstatus);
return 0;
}
@@ -379,15 +377,15 @@ static void ppc_isuspend(struct perfctr_
cpu = smp_processor_id();
set_isuspend_cpu(state, cpu); /* early to limit cpu's live range */
cache = __get_cpu_cache(cpu);
- cstatus = state->cstatus;
+ cstatus = state->user.cstatus;
nrctrs = perfctr_cstatus_nrctrs(cstatus);
for(i = perfctr_cstatus_nractrs(cstatus); i < nrctrs; ++i) {
- unsigned int pmc = state->pmc[i].map;
+ unsigned int pmc = state->user.pmc[i].map;
unsigned int now = read_pmc(pmc);
- state->pmc[i].sum += now - state->pmc[i].start;
- state->pmc[i].start = now;
+ state->user.pmc[i].sum += now - state->user.pmc[i].start;
+ state->user.pmc[i].start = now;
}
- /* cache->k1.id is still == state->k1.id */
+ /* cache->id is still == state->id */
}
static void ppc_iresume(const struct perfctr_cpu_state *state)
@@ -399,8 +397,8 @@ static void ppc_iresume(const struct per
cpu = smp_processor_id();
cache = __get_cpu_cache(cpu);
- if (cache->k1.id == state->k1.id) {
- /* Clearing cache->k1.id to force write_control()
+ if (cache->id == state->id) {
+ /* Clearing cache->id to force write_control()
to unfreeze MMCR0 would be done here, but it
[PATCH 2.6.12-rc1-mm3 1/3] perfctr: mapped state cleanup: x86
perfctr x86 mapped state cleanup:
- Swap cstatus and k1 fields in struct perfctr_cpu_state. Move
now contiguous user-visible fields to struct perfctr_cpu_state_user.
Hide kernel-private stuff. Inline now obsolete k1 struct. Cleanups.
Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>
drivers/perfctr/x86.c | 141 ++---
include/asm-i386/perfctr.h | 52
2 files changed, 95 insertions(+), 98 deletions(-)
diff -rupN linux-2.6.12-rc1-mm3/drivers/perfctr/x86.c
linux-2.6.12-rc1-mm3.perfctr-mapped-state-cleanup-x86/drivers/perfctr/x86.c
--- linux-2.6.12-rc1-mm3/drivers/perfctr/x86.c 2005-03-28 17:26:14.0
+0200
+++ linux-2.6.12-rc1-mm3.perfctr-mapped-state-cleanup-x86/drivers/perfctr/x86.c
2005-03-28 23:08:09.0 +0200
@@ -23,10 +23,7 @@ struct hw_interrupt_type;
/* Support for lazy evntsel and perfctr MSR updates. */
struct per_cpu_cache { /* roughly a subset of perfctr_cpu_state */
- union {
- unsigned int p5_cesr;
- unsigned int id;/* cache owner id */
- } k1;
+ unsigned int id;/* cache owner id */
#ifdef CONFIG_PERFCTR_INTERRUPT_SUPPORT
unsigned int interrupts_masked;
#endif
@@ -193,18 +190,18 @@ static inline void perfctr_cpu_unmask_in
static inline void
set_isuspend_cpu(struct perfctr_cpu_state *state, int cpu)
{
- state->k1.isuspend_cpu = cpu;
+ state->isuspend_cpu = cpu;
}
static inline int
is_isuspend_cpu(const struct perfctr_cpu_state *state, int cpu)
{
- return state->k1.isuspend_cpu == cpu;
+ return state->isuspend_cpu == cpu;
}
static inline void clear_isuspend_cpu(struct perfctr_cpu_state *state)
{
- state->k1.isuspend_cpu = NR_CPUS;
+ state->isuspend_cpu = NR_CPUS;
}
#else
@@ -245,7 +242,7 @@ static int p5_like_check_control(struct
cesr_half[1] = 0;
for(i = 0; i < state->control.header.nractrs; ++i) {
pmc = state->control.pmc_map[i];
- state->pmc[i].map = pmc;
+ state->user.pmc[i].map = pmc;
if (pmc > 1 || cesr_half[pmc] != 0)
return -EINVAL;
evntsel = state->control.evntsel[0];
@@ -261,7 +258,7 @@ static int p5_like_check_control(struct
return -EINVAL;
cesr_half[pmc] = evntsel;
}
- state->k1.id = (cesr_half[1] << 16) | cesr_half[0];
+ state->id = (cesr_half[1] << 16) | cesr_half[0];
return 0;
}
@@ -276,12 +273,12 @@ static void p5_write_control(const struc
struct per_cpu_cache *cache;
unsigned int cesr;
- cesr = state->k1.id;
+ cesr = state->id;
if (!cesr) /* no PMC is on (this test doesn't work on C6) */
return;
cache = get_cpu_cache();
- if (cache->k1.p5_cesr != cesr) {
- cache->k1.p5_cesr = cesr;
+ if (cache->id != cesr) {
+ cache->id = cesr;
wrmsr(MSR_P5_CESR, cesr, 0);
}
}
@@ -296,12 +293,12 @@ static void p5_read_counters(const struc
later in our caller. */
asm("" : : "r"(ctrs->tsc));
- cstatus = state->cstatus;
+ cstatus = state->user.cstatus;
if (perfctr_cstatus_has_tsc(cstatus))
rdtscl(ctrs->tsc);
nrctrs = perfctr_cstatus_nractrs(cstatus);
for(i = 0; i < nrctrs; ++i) {
- unsigned int pmc = state->pmc[i].map;
+ unsigned int pmc = state->user.pmc[i].map;
rdmsr_low(MSR_P5_CTR0+pmc, ctrs->pmc[i]);
}
}
@@ -312,12 +309,12 @@ static void rdpmc_read_counters(const st
{
unsigned int cstatus, nrctrs, i;
- cstatus = state->cstatus;
+ cstatus = state->user.cstatus;
if (perfctr_cstatus_has_tsc(cstatus))
rdtscl(ctrs->tsc);
nrctrs = perfctr_cstatus_nractrs(cstatus);
for(i = 0; i < nrctrs; ++i) {
- unsigned int pmc = state->pmc[i].map;
+ unsigned int pmc = state->user.pmc[i].map;
rdpmc_low(pmc, ctrs->pmc[i]);
}
}
@@ -376,12 +373,12 @@ static void c6_write_control(const struc
struct per_cpu_cache *cache;
unsigned int cesr;
- if (perfctr_cstatus_nractrs(state->cstatus) == 0) /* no PMC is on */
+ if (perfctr_cstatus_nractrs(state->user.cstatus) == 0) /* no PMC is on
*/
return;
cache = get_cpu_cache();
- cesr = state->k1.id;
- if (cache->k1.p5_cesr != cesr) {
- cache->k1.p5_cesr = cesr;
+ cesr = state->id;
+ if (cache->id != cesr) {
+ cache->id = cesr;
wrmsr(MSR_P5_CESR, cesr, 0);
}
}
@@ -415,7 +412,7 @@ static int p6_like_check_control(struct
pmc_mask = 0;
for(i = 0; i < nrctrs; ++i) {
pmc = state->control.pmc_map[i];
- state->pmc[i].map = pmc;
+
[PATCH 2.6.12-rc1-mm3 0/3] perfctr: mapped state cleanup: overview
Andrew, This set of patches change the layout of the perfctr cpu state object. This state is mmap()able, providing a low-overhead sampling method to user-space. But in order to limit the number of cache lines touched at frequent operations (context switches and explicit samplings), some kernel-private fields are unfortunately visible to user-space near the start of the counter state object. This is both ugly and prevents the kernel from ever changing the size of those fields. This issue is fixed now as follows: - The fields are reordered slightly. The freqently accessed kernel-private fields are now first, followed by the user-visible fields. This doesn't change the number of cache lines touched. - The now contiguous user-visible fields are moved to a sub-struct. - The kernel-private types are moved out of the user-visible parts of . - When mmap()ing a perfctr object, user-space must now add an offset to the mapping's address in order to reach the user-visible state. That offset is exported via a new perfctr sysfs attribute. This is a simple straightforward change, but the patches get large because a large number of field accesses must be adjusted. /Mikael - 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/pci/msi.c: fix a check after use
On Sun, Mar 27, 2005 at 11:15:24PM +0200, Adrian Bunk wrote: > This patch fixes a check after use found by the Coverity checker. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Applied, thanks. greg k-h - 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: PCI: remove pci_find_device usage from pci sysfs code.
On Thu, Mar 24, 2005 at 10:06:11PM +0100, Rolf Eike Beer wrote: > Greg KH wrote: > > On Sun, Mar 20, 2005 at 03:53:58PM +0100, Rolf Eike Beer wrote: > > > Greg KH wrote: > > > > ChangeSet 1.1998.11.23, 2005/02/25 08:26:11-08:00, [EMAIL PROTECTED] > > > > > > > > PCI: remove pci_find_device usage from pci sysfs code. > > > > Any reasons why you are not using "for_each_pci_dev(pdev)" here? > > > > Nope, I forgot it was there :) > > Patch is against 2.6.12-rc1-bk1 and does the same think like your one, > except it uses for_each_pci_dev() Applied, thanks. greg k-h - 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/pci/hotplug/cpqphp_core.c: fix a check after use
On Fri, Mar 25, 2005 at 01:21:55AM +0100, Adrian Bunk wrote: > This patch fixes a check after use found by the Coverity checker. Applied, thanks. greg k-h - 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] shrink drivers/pci/proc.c::pci_seq_start()
On Sun, Mar 27, 2005 at 03:05:43PM +0100, Rolf Eike Beer wrote: > Hi, > > this patch shrinks pci_seq_start by using for_each_pci_dev() macro instead > of explicitely using a loop and avoiding a goto. > > Eike > > Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]> Applied, thanks. greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel OOOPS in 2.6.11.6
* Coywolf Qi Hunt ([EMAIL PROTECTED]) wrote: > On Mon, 28 Mar 2005 14:44:30 -0800, Chris Wright <[EMAIL PROTECTED]> wrote: > > * Ali Akcaagac ([EMAIL PROTECTED]) wrote: > > > And happy easter to you all. Just got this while trying to delete some > > > files on my system. > > > > I'm curious, what was the virtual address the kernel was "Unable to > > handle..." > > That part was left off this bug report. > > > > > : printing eip: > > > : c021f089 > > > : *pde = > > > : Oops: [#1] > > > : PREEMPT > > > : Modules linked in: snd_seq_midi snd_emu10k1_synth snd_emux_synth > > > snd_seq_virmidi snd_seq_midi_event snd_seq_midi_emul snd_seq snd_emu10k1 > > > snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer > > > snd_page_alloc snd_util_mem snd_hwdep snd soundcore parport_pc lp > > > parport 8139too mii crc32 > > > : CPU:0 > > > : EIP:0060:[linvfs_open+89/160]Not tainted VLI > > > : EFLAGS: 00010282 (2.6.11.6) > > > : EIP is at linvfs_open+0x59/0xa0 > > > > Nothing in the -stable series has changed either XFS or the core vfs > > path on during file open. Without a chance of reproducing or any more > > information, it'll be tough to make much progress here. > > > > > : eax: ebx: c77ac06c ecx: 0001 edx: c021f030 > > > : esi: edi: c77ac050 ebp: dffe41a0 esp: c2d95f14 > > > : ds: 007b es: 007b ss: 0068 > > > : Process mc (pid: 17862, threadinfo=c2d94000 task=d18d2a80) > > > : Stack: c01561a9 dffe41a0 d73504c0 c77ac06c c015446b c77ac06c > > > d73504c0 > > > :0001 ffe9 8000 8000 dc364000 c2d94000 c015426c > > > cbcdff54 > > > :dffe41a0 8000 c2d95f60 cbcdff54 dffe41a0 bfffeef0 0d00ad72 > > > 0031 > > > : Call Trace: > > > : [get_empty_filp+89/208] get_empty_filp+0x59/0xd0 > > > : [dentry_open+491/672] dentry_open+0x1eb/0x2a0 > > > : [filp_open+92/112] filp_open+0x5c/0x70 > > > : [get_unused_fd+123/224] get_unused_fd+0x7b/0xe0 > > > : [sys_open+73/144] sys_open+0x49/0x90 > > > : [syscall_call+7/11] syscall_call+0x7/0xb > > > : Code: 5b 3c b8 01 00 00 00 e8 c6 42 ef ff b8 00 e0 ff ff 21 e0 8b 40 > > > 08 a8 08 75 4d 85 f6 7c 0a 7f 32 81 fb ff ff ff 7f 77 2a 8b 47 14 <8b> > > > 50 08 c7 44 24 04 00 00 00 00 89 04 24 ff 52 04 8b 5c 24 08 > > > > Best I can tell, you hit this: > > > > mov0x8(%eax),%edx > > > > with eax == . This corresponds to a vp->v_fops (or rather > > vp->v_bh.bh_first->bd_ops) deref. So, looks like the vnode has a > > NULL v_bh.bh_first (which looks like it's meant to be used to mean > > uninitialized). May check with XFS folks if they've seen this type > > of bug. > > I think it is f = kmem_cache_alloc(filp_cachep, GFP_KERNEL); returns an > invalid pointer, then in memset(f, 0, sizeof(*f)); fault happens at address f. > eax == 0 is to clear the memory in memset(). The trace indicates it's in linvfs_open (EIP: 0060:[linvfs_open+89/160]) and the insturction dump at the end supports that. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - 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] ppc32: cleanup of Book-E exception handling
Andrew, Cleaned up the Book-E exception handling code to remove saving/restoring registers that were not needed. Moved the register save/restore area onto the exception stacks instead of dedicated offsets. Additionally, this allows for proper SMP handling of the additional exception levels. Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- diff -Nru a/arch/ppc/kernel/entry.S b/arch/ppc/kernel/entry.S --- a/arch/ppc/kernel/entry.S 2005-03-28 14:24:24 -06:00 +++ b/arch/ppc/kernel/entry.S 2005-03-28 14:24:24 -06:00 @@ -45,40 +45,37 @@ #endif #ifdef CONFIG_BOOKE -#defineCOR r8 /* Critical Offset Register (COR) */ -#define BOOKE_LOAD_COR lis COR,[EMAIL PROTECTED] -#define BOOKE_REST_COR mfspr COR,SPRN_SPRG2 -#define BOOKE_SAVE_COR mtspr SPRN_SPRG2,COR -#else -#define COR0 -#define BOOKE_LOAD_COR -#define BOOKE_REST_COR -#define BOOKE_SAVE_COR -#endif - -#ifdef CONFIG_BOOKE +#include "head_booke.h" .globl mcheck_transfer_to_handler mcheck_transfer_to_handler: - mtspr SPRN_SPRG6W,r8 - lis r8,[EMAIL PROTECTED] - lwz r0,[EMAIL PROTECTED](r8) + mtspr MCHECK_SPRG,r8 + BOOKE_LOAD_MCHECK_STACK + lwz r0,GPR10-INT_FRAME_SIZE(r8) stw r0,GPR10(r11) - lwz r0,[EMAIL PROTECTED](r8) + lwz r0,GPR11-INT_FRAME_SIZE(r8) stw r0,GPR11(r11) - mfspr r8,SPRN_SPRG6R + mfspr r8,MCHECK_SPRG b transfer_to_handler_full + + .globl crit_transfer_to_handler +crit_transfer_to_handler: + mtspr CRIT_SPRG,r8 + BOOKE_LOAD_CRIT_STACK + lwz r0,GPR10-INT_FRAME_SIZE(r8) + stw r0,GPR10(r11) + lwz r0,GPR11-INT_FRAME_SIZE(r8) + stw r0,GPR11(r11) + mfspr r8,CRIT_SPRG + /* fall through */ #endif -#if defined(CONFIG_40x) || defined(CONFIG_BOOKE) +#ifdef CONFIG_40x .globl crit_transfer_to_handler crit_transfer_to_handler: - BOOKE_SAVE_COR - BOOKE_LOAD_COR - lwz r0,[EMAIL PROTECTED](COR) + lwz r0,[EMAIL PROTECTED](0) stw r0,GPR10(r11) - lwz r0,[EMAIL PROTECTED](COR) + lwz r0,[EMAIL PROTECTED](0) stw r0,GPR11(r11) - BOOKE_REST_COR /* fall through */ #endif @@ -724,8 +721,6 @@ * We have to restore various SPRs that may have been in use at the * time of the critical interrupt. * - * Note that SPRG6 is used for machine check on CONFIG_BOOKE parts and - * thus not saved in the critical handler */ .globl ret_from_crit_exc ret_from_crit_exc: @@ -770,32 +765,9 @@ mtspr SPRN_CSRR1,r12 lwz r9,GPR9(r1) lwz r12,GPR12(r1) - BOOKE_SAVE_COR - BOOKE_LOAD_COR - lwz r10,[EMAIL PROTECTED](COR) - mtspr SPRN_SPRG0,r10 - lwz r10,[EMAIL PROTECTED](COR) - mtspr SPRN_SPRG1,r10 - lwz r10,[EMAIL PROTECTED](COR) - mtspr SPRN_SPRG4,r10 - lwz r10,[EMAIL PROTECTED](COR) - mtspr SPRN_SPRG5,r10 -#ifdef CONFIG_40x - lwz r10,[EMAIL PROTECTED](COR) - mtspr SPRN_SPRG6,r10 -#endif - lwz r10,[EMAIL PROTECTED](COR) - mtspr SPRN_SPRG7,r10 - lwz r10,[EMAIL PROTECTED](COR) - mtspr SPRN_SRR0,r10 - lwz r10,[EMAIL PROTECTED](COR) - mtspr SPRN_SRR1,r10 - lwz r10,[EMAIL PROTECTED](COR) - mtspr SPRN_PID,r10 lwz r10,GPR10(r1) lwz r11,GPR11(r1) lwz r1,GPR1(r1) - BOOKE_REST_COR PPC405_ERR77_SYNC rfci b . /* prevent prefetch past rfci */ @@ -839,32 +811,9 @@ mtspr SPRN_MCSRR1,r12 lwz r9,GPR9(r1) lwz r12,GPR12(r1) - mtspr SPRN_SPRG6W,r8 - lis r8,[EMAIL PROTECTED] - lwz r10,[EMAIL PROTECTED](r8) - mtspr SPRN_SPRG0,r10 - lwz r10,[EMAIL PROTECTED](r8) - mtspr SPRN_SPRG1,r10 - lwz r10,[EMAIL PROTECTED](r8) - mtspr SPRN_SPRG4,r10 - lwz r10,[EMAIL PROTECTED](r8) - mtspr SPRN_SPRG5,r10 - lwz r10,[EMAIL PROTECTED](r8) - mtspr SPRN_SPRG7,r10 - lwz r10,[EMAIL PROTECTED](r8) - mtspr SPRN_SRR0,r10 - lwz r10,[EMAIL PROTECTED](r8) - mtspr SPRN_SRR1,r10 - lwz r10,[EMAIL PROTECTED](r8) - mtspr SPRN_CSRR0,r10 - lwz r10,[EMAIL PROTECTED](r8) - mtspr SPRN_CSRR1,r10 - lwz r10,[EMAIL PROTECTED](r8) - mtspr SPRN_PID,r10 lwz r10,GPR10(r1) lwz r11,GPR11(r1) lwz r1,GPR1(r1) - mfspr r8,SPRN_SPRG6R RFMCI #endif /* CONFIG_BOOKE */ diff -Nru a/arch/ppc/kernel/head_44x.S b/arch/ppc/kernel/head_44x.S --- a/arch/ppc/kernel/head_44x.S2005-03-28 14:24:24 -06:00 +++ b/arch/ppc/kernel/head_44x.S2005-03-28 14:24:24 -06:00 @@ -728,78 +728,13 @@ _GLOBAL(swapper_pg_dir) .space 8192 +/*
Re: [PATCH] disable MSI for AMD-8131
On Sun, Mar 06, 2005 at 10:28:45PM +0200, Michael S. Tsirkin wrote: > Greg, Martin, > > The AMD-8131 I/O APIC (device id 1022:7450/7451) does not support message > signalled interrupts. Thus, if a device driver attempts to enable msi, > it will suceed, but interrupts are not actually delivered to the cpu. > The Nforce chipsets do not seem to have this limitation. > AMD confirmed that MSI mode is unsupported with this APIC. > > The following patch adds a flag to pci quirks to detect this and disable msi. > > Please let me know what do you think. > > Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]> Looks good, applied, thanks. greg k-h - 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/
