Re: kdb v4.4 supports OHCI keyboard in 2.6
On Thu, 21 Jul 2005 12:11:21 +0100, Sid Boyce <[EMAIL PROTECTED]> wrote: > CHK include/linux/version.h >make[1]: `arch/i386/kernel/asm-offsets.s' is up to date. > CHK include/linux/compile.h > CHK usr/initramfs_list > CC arch/i386/kernel/traps.o >arch/i386/kernel/traps.c:809: error: redefinition of `do_int3' >arch/i386/kernel/traps.c:709: error: `do_int3' previously defined here >make[1]: *** [arch/i386/kernel/traps.o] Error 1 >make: *** [arch/i386/kernel] Error 2 > >Both lines are the same, enabling both kprobes and kdb causes the error, >so kprobes must be deselected. Fixed in kdb-v4.4-2.6.13-rc3-common-2 + kdb-v4.4-2.6.13-rc3-i386-2. - 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/5+1] menu -> menuconfig part 1
On Sun, 17 Jul 2005 13:29:03 +0200 (CEST) Bodo Eggert wrote: > On Sun, 17 Jul 2005, Bodo Eggert wrote: > > > These patches change some menus into menuconfig options. > > > > Reworked to apply to linux-2.6.13-rc3-git3 > > Mostly robotic works. Hi, When using xconfig (not menuconfig), the drivers/MTD menu needs some help IMO, but it's not clear where/why. Before the patch, there was only "Memory Technology Devices (MTD)" in the left xconfig panel. After the patch, under that heading there are 4 other MTD entries, which are in the right-side panel before the patch and should remain there. These are: RAM/ROM/Flash chip drivers Mapping drivers for chip access Self-contained MTD device drivers NAND Flash Device support --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm1 (ckrm)
> of the various environments. I don't think you are one of those end > users, though. I don't think I'm required to make everyone happy all > the time. ;) the issue is whether CKRM (in it's real form, not this thin edge) will noticably hurt Linux's fast-path. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux v2.6.13-rc3
>Still it would be nice to let people know what to do if they >have problems with >these changes. Many people don't run -rc kernels and even more people >don't run -mm, so they have no idea that there are known >regressions ... I hope the broader exposure will break the EC patch on another machine (besides your rare Asus) so that we can figure it out and get it fixed for everybody. Re: the S3 interrupt resume issue. We're hoping to fix the most common drivers before the release ships; and we'd like to have a method to detect when drivers do not release their interrupt so that we can at least have a warning to the user to unload the offending module until it gets fixed. thanks for your support, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.13-rc3a] i386: inline restore_fpu
On Fri, 22 Jul 2005, Andrew Morton wrote: > > Is the benchmark actually doing floating point stuff? It must be. We still do lazy FP saves. > We do have the `used_math' optimisation in there which attempts to avoid > doing the FP save/restore if the app isn't actually using math. No, it's more than that. There's a per-processor "used_math" flag to determine if we need to _initialize_ the FPU, but on context switches we always assume the program we're switching to will _not_ use FP, and we just set the "fault on FP" flag and do not normally restore FP state. It seems volanomark will always use FP, if this is the hot path. We'll only save the FP context if the thread has used the FP in _that_ particular time-slice (TS_USEDFPU). As to why volanomark also uses FP, I don't know. I wouldn't be surprised if the benchmark was designed by somebody to not benefit from the x87 state save optimization. On the other hand, I also wouldn't be surprised if glibc (or similar system libraries) is over-eagerly using things like SSE instructions for memcopies etc, not realizing that they can have serious downsides. I don't see why volanomark would use FP, but hey, it's billed as a java VM and thread torture test for "chatrooms". Whatever. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [2/5+1] menu -> menuconfig part 1
On Sun, 17 Jul 2005 13:31:23 +0200 (CEST) Bodo Eggert wrote: > On Sun, 17 Jul 2005, Bodo Eggert wrote: > > > These patches change some menus into menuconfig options. > > > > Reworked to apply to linux-2.6.13-rc3-git3 > > The USB menu. The USB Gadgets menu is also wacky. ? ? <*> USB Gadgets (device side) ---> ? ? ? ? USB Peripheral Controller (NetChip 2280) ---> ? ? ? ? NetChip 2280 (NEW)? ? ? ? USB Gadget Drivers ? ? ? ? < > Gadget Zero (DEVELOPMENT) (NEW) ? ? ? ? < > Ethernet Gadget (with CDC Ethernet support) (NEW) ? ? ? ? < > Gadget Filesystem (EXPERIMENTAL) (NEW)? ? ? ? < > File-backed Storage Gadget (NEW) ? ? ? ? < > Serial Gadget (with CDC ACM support) (NEW) Those should all be visible only after pressing Enter on the USB Gadgets menu item; they should not be expanded inline in the Device Drivers menu. --- ~Randy - 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] [1b/5+1] menu -> menuconfig part 1
On Sun, 17 Jul 2005 19:03:09 +0200 (CEST) Bodo Eggert wrote: > On Sun, 17 Jul 2005, Bodo Eggert wrote: > > On Sun, 17 Jul 2005, Bodo Eggert wrote: > > > > These patches change some menus into menuconfig options. > > > > > > Reworked to apply to linux-2.6.13-rc3-git3 > > > > Mostly robotic works. > > Fixup: unbreak i2c menu Hi Bodo, Was there supposed to be a patch here? I do see that the I2C menu is broken... Thanks, --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm1 (ckrm)
On Fri, 22 Jul 2005 00:53:58 EDT, Mark Hahn wrote: > > > > yes, that's the crux. CKRM is all about resolving conflicting resource > > > > demands in a multi-user, multi-server, multi-purpose machine. this is > > > > a > > > > huge undertaking, and I'd argue that it's completely inappropriate for > > > > *most* servers. that is, computers are generally so damn cheap that > > > > the clear trend is towards dedicating a machine to a specific purpose, > > > > rather than running eg, shell/MUA/MTA/FS/DB/etc all on a single > > > > machine. > > > > This is a big NAK - if computers are so damn cheap, why is virtualization > > and consolidation such a big deal? Well, the answer is actually that > > yes, you did miss my point. I'm actually arguing that it's bad design > to attempt to arbitrate within a single shared user-space. you make > the fast path slower and less maintainable. if you are really concerned > about isolating many competing servers on a single piece of hardware, then > run separate virtualized environments, each with its own user-space. I'm willing to agree to disagree. I'm in favor of full virtualization as well, as it is appropriate to certain styles of workloads. I also have enough end users who also want to share user level, share tasks, yet also have some level of balancing between the resource consumption of the various environments. I don't think you are one of those end users, though. I don't think I'm required to make everyone happy all the time. ;) BTW, does your mailer purposefully remove cc:'s? Seems like that is normally considered impolite. gerrit - 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: sis190 driver
On Fri, Jul 22, 2005 at 01:09:50AM +0200, Francois Romieu wrote:
> No major change from previous version. I'm quietly merging bits from
> the SiS driver that Lars kindly pointed out. The detection of the
> mac address is done differently.
>
> I'll welcome feedback related to regressions and/or netconsole testing.
>
> Single file patch:
> http://www.zoreil.com/~romieu/sis190/20050722-2.6.13-rc2-sis190-test.patch
MAINTAINERS chunk isn't -p1 applicable. ;-)
sparse asks whether you have endianness bugs here:
450 static inline void sis190_make_unusable_by_asic(struct RxDesc *desc)
451 {
452 desc->PSize = 0x0;
453 ===>desc->addr = 0xdeadbeef;<===
454 desc->size &= cpu_to_le32(RingEnd);
455 wmb();
456 desc->status = 0x0;
457 }
drivers/net/sis190.c:453:13: warning: incorrect type in assignment (different
base types)
drivers/net/sis190.c:453:13:expected restricted unsigned int [assigned]
[usertype] addr
drivers/net/sis190.c:453:13:got unsigned int
544 static int sis190_rx_interrupt(struct net_device *dev,
545 struct sis190_private *tp, void __iomem
*ioaddr)
546 {
554 for (; rx_left > 0; rx_left--, cur_rx++) {
555 unsigned int entry = cur_rx % NUM_RX_DESC;
556 struct RxDesc *desc = tp->RxDescRing + entry;
557 u32 status;
558
559 ===>if (desc->status & OWNbit) <===
560 break;
drivers/net/sis190.c:559:20: warning: incompatible types for operation (&)
drivers/net/sis190.c:559:20:left side has type restricted unsigned int
[assigned] [usertype] status
drivers/net/sis190.c:559:20:right side has type unsigned int [unsigned]
enum _DescStatusBit [unsigned] [toplevel] OWNbit
Add endian annotations.
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
Index: linux-sis190/drivers/net/sis190.c
===
--- linux-sis190.orig/drivers/net/sis190.c 2005-07-22 07:56:37.0
+0400
+++ linux-sis190/drivers/net/sis190.c 2005-07-22 08:03:47.0 +0400
@@ -191,17 +191,17 @@ enum sis190_register_content {
};
struct TxDesc {
- u32 PSize;
- u32 status;
- u32 addr;
- u32 size;
+ __le32 PSize;
+ __le32 status;
+ __le32 addr;
+ __le32 size;
};
struct RxDesc {
- u32 PSize;
- u32 status;
- u32 addr;
- u32 size;
+ __le32 PSize;
+ __le32 status;
+ __le32 addr;
+ __le32 size;
};
enum _DescStatusBit {
@@ -1322,7 +1322,7 @@ static int __devinit sis190_get_mac_addr
/* Get MAC address from EEPROM */
for (i = 0; i < MAC_ADDR_LEN / 2; i++) {
- u16 w = sis190_read_eeprom(ioaddr, EEPROMMACAddr + i);
+ __le16 w = sis190_read_eeprom(ioaddr, EEPROMMACAddr + i);
((u16 *)dev->dev_addr)[0] = le16_to_cpu(w);
}
-
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,rfc] Support for touchscreen on sharp zaurus sl-5500
On 7/21/05, Pavel Machek <[EMAIL PROTECTED]> wrote: > Hi! > > > > + set_task_state(tsk, TASK_UNINTERRUPTIBLE); > > > + schedule_timeout(HZ / 100); > > > + if (signal_pending(tsk)) > > > + break; > > > > You specifically allow SIGKILL, but then sleep uninterruptibly? And > > then you check if signal_pending() :) I think you may want > > TASK_INTERRUPTIBLE? Or, go one better and use msleep_interruptible(), > > as I don't see any wait-queues in the immediate area of this code... > > Okay, I think this should be uninterruptible. The signal can be > delivered during next interruptible sleep. Fixes. Good point. But the signal_pending() check after that interruptible sleep (which deterministically comes after this one) takes care of the break, doesn't it? I guess you can (maybe already have done so...) get rid of the signal_pending() check after the uninterruptible sleep. And then go ahead and make this an msleep(10) call and the other one (in the same function) an msleep_interruptible() call ;) Thanks, Nish - 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] [PATCH] Syncthreads support.
Hi. On Fri, 2005-07-22 at 01:39, Pavel Machek wrote: > Hi! > > > This patch implements a new PF_SYNCTHREAD flag, which allows upcoming > > the refrigerator implementation to know that a thread is syncing data to > > disk. This allows the refrigerator to be more reliable, even under heavy > > load, because it can separate userspace processes that are submitting > > I/O from those trying to sync it and freezing the former first. We can > > thus ensure that syncing processes complete their work more quickly and > > the refrigerator is far less likely to incorrectly give up (thinking a > > syncing process is completely failing to enter the refrigerator). > > This patch is , and pretty intrusive too. Ouch and then it is > unneccessary. We have been over this before, and explained to you in > person. Greg explained it to you, too. This one is NOT GOING IN. Drop > it from your patches, trying to submit it 10 times will not get it > accepted. > > [For the record, simple solution for this one is > > sys_sync(); > > and only then start refrigeration]. That's not right. Greg said he believed the right thing to do was to sync in the kernel, but he also said he agreed with you. I thought at the time he was confused about who was suggesting what - let's check with him. Anyway, we discussed before that sync_sync before starting refrigerating is insufficient. Remember that since processes aren't refrigerated yet, there is absolutely nothing to stop other processes submitting I/O between the two actions and thus making the sync pointless. The sync needs to be done after the userspace processes that might submit I/O have been frozen, to ensure that all the dirty data is actually synced to disk. Remember also that it is important that we do need to sync all dirty buffers. In the case of not resuming, data loss should nil. Regards, Nigel -- Evolution. Enumerate the requirements. Consider the interdependencies. Calculate the probabilities. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm1 (ckrm)
> > > yes, that's the crux. CKRM is all about resolving conflicting resource > > > demands in a multi-user, multi-server, multi-purpose machine. this is a > > > huge undertaking, and I'd argue that it's completely inappropriate for > > > *most* servers. that is, computers are generally so damn cheap that > > > the clear trend is towards dedicating a machine to a specific purpose, > > > rather than running eg, shell/MUA/MTA/FS/DB/etc all on a single machine. > > This is a big NAK - if computers are so damn cheap, why is virtualization > and consolidation such a big deal? Well, the answer is actually that yes, you did miss my point. I'm actually arguing that it's bad design to attempt to arbitrate within a single shared user-space. you make the fast path slower and less maintainable. if you are really concerned about isolating many competing servers on a single piece of hardware, then run separate virtualized environments, each with its own user-space. - 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] [PATCH] Workqueue freezer support.
Hi.
On Fri, 2005-07-22 at 05:42, Patrick Mochel wrote:
> On Thu, 21 Jul 2005, Nigel Cunningham wrote:
>
> > This patch implements freezer support for workqueues. The current
> > refrigerator implementation makes all workqueues NOFREEZE, regardless of
> > whether they need to be or not.
>
> A few comments..
>
> > Signed-off by: Nigel Cunningham <[EMAIL PROTECTED]>
> >
> > drivers/acpi/osl.c |2 +-
> > drivers/block/ll_rw_blk.c |2 +-
> > drivers/char/hvc_console.c |2 +-
> > drivers/char/hvcs.c |2 +-
> > drivers/input/serio/serio.c |2 +-
> > drivers/md/dm-crypt.c |2 +-
> > drivers/scsi/hosts.c|2 +-
> > drivers/usb/net/pegasus.c |2 +-
>
> If you want some practice splitting things up, submit the patches above
> individually to the maintainers o the relevant code once the patches you
> submit below get merged to -mm.
Ok. Thanks for telling me.
> > include/linux/kthread.h | 20 ++--
> > include/linux/workqueue.h |9 ++---
> > kernel/kmod.c |4
> > kernel/kthread.c| 23 ++-
> > kernel/sched.c |4 ++--
> > kernel/softirq.c|3 +--
> > kernel/workqueue.c | 21 -
> > 15 files changed, 73 insertions(+), 27 deletions(-)
>
>
> You should make sure that you get an explicit ACK from people (Ingo et al)
> about whether this is an acceptable interface.
Ok. How do I know who to ask? (Who besides Ingo, and could I learn who
without help - Maintainers?)
> > --- 400-workthreads.patch-old/include/linux/kthread.h 2004-11-03
> > 21:51:12.0 +1100
> > +++ 400-workthreads.patch-new/include/linux/kthread.h 2005-07-20
> > 15:11:37.0 +1000
> > @@ -27,6 +27,14 @@ struct task_struct *kthread_create(int (
> >void *data,
> >const char namefmt[], ...);
> >
> > +struct task_struct *_kthread_create(int (*threadfn)(void *data),
> > + void *data,
> > + unsigned long freezer_flags,
> > + const char namefmt[], ...);
> > +
>
> This should be __kthread_create(...)
Ok. Fixed. Is one underscore ever right?
> > -#define kthread_run(threadfn, data, namefmt, ...) \
> > +#define kthread_run(threadfn, data, namefmt, args...)
> >\
> > ({\
> > struct task_struct *__k\
> > - = kthread_create(threadfn, data, namefmt, ## __VA_ARGS__); \
> > + = kthread_create(threadfn, data, namefmt, ##args); \
> > if (!IS_ERR(__k)) \
> > wake_up_process(__k); \
> > __k; \
> > })
> >
> > +#define kthread_nofreeze_run(threadfn, data, namefmt, args...)
> >\
> > +({\
> > + struct task_struct *__k = kthread_nofreeze_create(threadfn, data, \
> > + namefmt, ##args); \
> > + if (!IS_ERR(__k)) \
> > + wake_up_process(__k); \
> > + __k; \
> > +})
>
> Do these functions need to be inlined?
I tried to find out how to pass the va_list on nicely without using a
#define, but could find the info. If you're able to tell me, I'll make
them inline. Perhaps I could also improve the kthread_create call Pavel
and Ingo commented on.
> > @@ -86,6 +87,10 @@ static int kthread(void *_create)
> > /* By default we can run anywhere, unlike keventd. */
> > set_cpus_allowed(current, CPU_MASK_ALL);
> >
> > + /* Set our freezer flags */
> > + current->flags &= ~(PF_SYNCTHREAD | PF_NOFREEZE);
> > + current->flags |= (create->freezer_flags & PF_NOFREEZE);
> > +
>
> Maybe these should be encapsulated in a helper in include/linux/sched.h
> like some other flags manipulations are?
This would be the only place it's used. Does that matter? (And note from
the updated patch that the SYNCTHREAD wouldn't be there).
> > diff -ruNp 400-workthreads.patch-old/kernel/sched.c
> > 400-workthreads.patch-new/kernel/sched.c
> > --- 400-workthreads.patch-old/kernel/sched.c2005-07-21
> > 04:00:02.0 +1000
> > +++ 400-workthreads.patch-new/kernel/sched.c2005-07-21
> > 04:00:19.0 +1000
> > @@ -4580,10 +4580,10 @@ static int migration_call(struct notifie
> >
> > switch (action) {
> > case CPU_UP_PREPARE:
> > - p = kthread_create(migration_thread, hcpu, "migration/%d",cpu);
> > + p =
Re: fastboot, diskstat
bert hubert <[EMAIL PROTECTED]> wrote: > > Hi Andrew, > > I'm currently at OLS and presented http://ds9a.nl/diskstat yesterday, which > also references your ancient 'fboot' program. > > I've also done experiments along those lines, and will be doing more of them > soon. > > You mention it was a waste of time, do you recall if that meant: > > 1) that the total time for prefetching + actual boot was only 10% shorter, > but that the actual booting did not (significantly) touch the disk? > > 2) that on actual boot there would still be a lot of i/o > > ? eep, this was early 2001, on 2.4.whatever. I recall trying various preloading schemes - try loading the metadata first, then the pagecache, pagecache first then metadata, one and not the other, etc. Yeah, 10-15% benefit was obtainable but on a little old laptop the amount of discontiguous I/O was still quite tremendous. I also recall hacking the initscripts so they were _all_ launched asynchronously. A few things broke because of dependency problems of course, but that improved things quite noticeably. I think quite a few of the scripts and daemons and things have explicit sleeps, and parallelising all of those helped. > > Regarding 1), in my own experiments I failed to convince the kernel to > actually cache the pages I touched, I wonder if some sequential-read > detection kicked in, the one that prevents entire cd's being cached. It depends how you touch the page. Remember that there is no unified pagecache in 2.6. The pagecache for /dev/hda1 is separate from the pagecache for /etc/passwd. If one tries to preload /etc/passwd by reading from /dev/hda1 then that won't be effective. So any userspace preloading scheme would have to open both /dev/hda1 and /etc/passwd and it would then read from both fds in some intermingled manner based on disk block address. Although I'd suggest that it'd be easier to just get the kernel to do it: set the disk queue size to something enormous (4096 requests?), open 100 files, launch posix_fadvise() against them all (or against sections of them) then close the files again. Rely upon that large disk queue to perform all the sorting. Maybe. > For my next attempt I'll try to actually lock the pages into memory. It shouldn't be needed. If at the end of preload there's still a decent amount of free memory, you know that the kernel hasn't gone and thrown anything away yet. Any machine with 256MB or more of RAM should be able to fit all the boot-time stuff into RAM fairly comfortably. > Also, regarding the directory entries, are they accessed via the buffer > cache? yes. For ext3 you can preload both inodes and directory entries via read()s from /dev/hda1. For ext2, directory entries each have their own pagecache and should be preloaded via read(open(/name/of/directory)). > Iow, would reading blocks which can't be mapped to files directly via > /dev/hda be useful? If the blocks are directories or inodes then you _must_ preload them via /dev/hda1's pagecache. (/dev/hda1's pagecache is the storage for /dev/hda1's buffercache - they're the same thing). So a scheme which would work for 2.6.x would be: a) Boot the machine b) Walk /dev/hda1's pagecache, record which pages are present. c) For all files which are in dcache, walk their pagecache, work out which pages are present. (nb: it might be possible to do most of the above from userspace: mmap the file and use mincore() to find out if the page is in pagecache). The above data is enough for performing a crude preload: a) Boot the machine b) Boost the disk queue size, set the VFS readahead to zero, open /dev/hda1 and all the regular files, hose reads at the disk via fadvise(). Restore VFS readahead and queue size, continue with boot. More sophisticated preload would involve bmap()ping the various regular files so the reads can be issued in LBA-sorted order. But this could be of marginal additional benefit. And I suspect that the whole thing will be of marginal benefit. Although things might be better now that files are laid out with the Orlov allocator (make sure that the distro was installed with a 2.6 kernel! The file layout will be quite different if the installer used a 2.4 ext3). Of course the next step is to rewrite files so that they are more favourably laid out on disk. Tricky. Or dump all pagecache to some temp file in a nice linear slurp and preload that, copying it all to the appropriate per-inode pagecaches and taking care of files which have been modified. Trickier ;) - 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/
[QN/PATCH] Why do some archs allocate stack via kmalloc, others via get_free_pages?
Hi all.
In making some modifications to Suspend, we've discovered that some
arches use kmalloc and others use get_free_pages to allocate the stack.
Is there a reason for the variation? If not, could the following patch
be considered for inclusion (tested on x86 only).
Regards,
Nigel
arch/frv/kernel/process.c |4 ++--
include/asm-frv/thread_info.h | 11 ---
include/asm-i386/thread_info.h | 11 ---
include/asm-m32r/thread_info.h | 10 +++---
include/asm-mips/thread_info.h |8 +---
include/asm-ppc64/thread_info.h |9 ++---
include/asm-um/thread_info.h|6 --
7 files changed, 40 insertions(+), 19 deletions(-)
diff -ruNp
821-make-task-struct-use-get-free-pages.patch-old/arch/frv/kernel/process.c
821-make-task-struct-use-get-free-pages.patch-new/arch/frv/kernel/process.c
--- 821-make-task-struct-use-get-free-pages.patch-old/arch/frv/kernel/process.c
2005-02-03 22:33:14.0 +1100
+++ 821-make-task-struct-use-get-free-pages.patch-new/arch/frv/kernel/process.c
2005-07-22 04:39:15.0 +1000
@@ -41,7 +41,7 @@ asmlinkage void ret_from_fork(void);
struct task_struct *alloc_task_struct(void)
{
- struct task_struct *p = kmalloc(THREAD_SIZE, GFP_KERNEL);
+ struct task_struct *p = (struct task_struct *)
__get_free_pages(GFP_KERNEL, THREAD_ORDER);
if (p)
atomic_set((atomic_t *)(p+1), 1);
return p;
@@ -50,7 +50,7 @@ struct task_struct *alloc_task_struct(vo
void free_task_struct(struct task_struct *p)
{
if (atomic_dec_and_test((atomic_t *)(p+1)))
- kfree(p);
+ free_pages((unsigned long) p, THREAD_ORDER);
}
static void core_sleep_idle(void)
diff -ruNp
821-make-task-struct-use-get-free-pages.patch-old/include/asm-frv/thread_info.h
821-make-task-struct-use-get-free-pages.patch-new/include/asm-frv/thread_info.h
---
821-make-task-struct-use-get-free-pages.patch-old/include/asm-frv/thread_info.h
2005-07-18 06:37:02.0 +1000
+++
821-make-task-struct-use-get-free-pages.patch-new/include/asm-frv/thread_info.h
2005-07-22 04:52:48.0 +1000
@@ -89,6 +89,8 @@ struct thread_info {
#define THREAD_SIZE8192
#endif
+#define THREAD_ORDER (THREAD_SIZE >> PAGE_SHIFT)
+
/* how to get the thread information struct from C */
register struct thread_info *__current_thread_info asm("gr15");
@@ -100,16 +102,19 @@ register struct thread_info *__current_t
({ \
struct thread_info *ret;\
\
- ret = kmalloc(THREAD_SIZE, GFP_KERNEL); \
+ ret = (struct thread_info *)\
+ __get_free_pages(GFP_KERNEL,\
+ THREAD_ORDER); \
if (ret)\
memset(ret, 0, THREAD_SIZE);\
ret;\
})
#else
-#define alloc_thread_info(tsk) kmalloc(THREAD_SIZE, GFP_KERNEL)
+#define alloc_thread_info(tsk) (struct thread_info *) \
+ __get_free_pages(GFP_KERNEL, THREAD_ORDER)
#endif
-#define free_thread_info(info) kfree(info)
+#define free_thread_info(info) free_pages((unsigned long) info, THREAD_ORDER)
#define get_thread_info(ti)get_task_struct((ti)->task)
#define put_thread_info(ti)put_task_struct((ti)->task)
diff -ruNp
821-make-task-struct-use-get-free-pages.patch-old/include/asm-i386/thread_info.h
821-make-task-struct-use-get-free-pages.patch-new/include/asm-i386/thread_info.h
---
821-make-task-struct-use-get-free-pages.patch-old/include/asm-i386/thread_info.h
2005-07-22 05:17:22.0 +1000
+++
821-make-task-struct-use-get-free-pages.patch-new/include/asm-i386/thread_info.h
2005-07-22 04:58:14.0 +1000
@@ -55,8 +55,10 @@ struct thread_info {
#define PREEMPT_ACTIVE 0x1000
#ifdef CONFIG_4KSTACKS
#define THREAD_SIZE(4096)
+#define THREAD_ORDER 0
#else
#define THREAD_SIZE(8192)
+#define THREAD_ORDER 1
#endif
#define STACK_WARN (THREAD_SIZE/8)
@@ -101,16 +103,19 @@ register unsigned long current_stack_poi
({ \
struct thread_info *ret;\
\
- ret = kmalloc(THREAD_SIZE, GFP_KERNEL); \
+ ret = (struct thread_info *)\
+ __get_free_pages(GFP_KERNEL,\
+ THREAD_ORDER); \
if (ret)\
memset(ret, 0, THREAD_SIZE);\
Re: 2.6.13-rc3-mm1 (ckrm)
Sorry - I didn't see Mark's original comment, so I'm replying to a reply which I did get. ;-) On Thu, 21 Jul 2005 23:59:09 EDT, Shailabh Nagar wrote: > Mark Hahn wrote: > >>I suspect that the main problem is that this patch is not a mainstream > >>kernel feature that will gain multiple uses, but rather provides > >>support for a specific vendor middleware product used by that > >>vendor and a few closely allied vendors. If it were smaller or > >>less intrusive, such as a driver, this would not be a big problem. > >>That's not the case. > > > > > > yes, that's the crux. CKRM is all about resolving conflicting resource > > demands in a multi-user, multi-server, multi-purpose machine. this is a > > huge undertaking, and I'd argue that it's completely inappropriate for > > *most* servers. that is, computers are generally so damn cheap that > > the clear trend is towards dedicating a machine to a specific purpose, > > rather than running eg, shell/MUA/MTA/FS/DB/etc all on a single machine. This is a big NAK - if computers are so damn cheap, why is virtualization and consolidation such a big deal? Well, the answer is actually that floor space, heat, and power are also continuing to be very important in the overall equation. And, buying machines which are dedicated but often 80-99% idle occasionally bothers people who are concerned about wasting planetary resources for no good reason. Yeah, we can stamp out thousands of metal boxes, but if just a couple can do the same work, well, let's consolidate. Less wasted metal, less wasted heat, less wasted power, less air conditioning, wow, we are now part of the eco-computing movement! ;-) > > this is *directly* in conflict with certain prominent products, such as > > the Altix and various less-prominent Linux-based mainframes. they're all > > about partitioning/virtualization - the big-iron aesthetic of splitting up > > a single machine. note that it's not just about "big", since cluster-based > > approaches can clearly scale far past big-iron, and are in effect statically > > partitioned. yes, buying a hideously expensive single box, and then > > chopping > > it into little pieces is more than a little bizarre, and is mainly based > > on a couple assumptions: Well, yeah IBM has been doing this virtualization & partitioning stuff for ages at lots of different levels for lots of reasons. If we are in such direct conflict with Altix, aren't we also in conflict with our own lines of business which do the same thing? But, well, we aren't in conflict - this is a complementary part of our overall capabilities. > > - that clusters are hard. really, they aren't. they are not > > necessarily higher-maintenance, can be far more robust, usually > > do cost less. just about the only bad thing about clusters is > > that they tend to be somewhat larger in size. This is orthogonal to clusters. Or, well, we are even using CKRM today is some grid/cluster style applications. But that has no bearing on whether or not clusters is useful. > > - that partitioning actually makes sense. the appeal is that if > > you have a partition to yourself, you can only hurt yourself. > > but it also follows that burstiness in resource demand cannot be > > overlapped without either constantly tuning the partitions or > > infringing on the guarantee. Well, if you don't think it makes sense, don't buy one. And stay away from Xen, VMware, VirtualIron, PowerPC/pSeries hardware, Mainframes, Altix, IA64 platforms, Intel VT, AMD Pacifica, and, well, anyone else that is working to support virtualization, which is one key level of partitioning. I'm sorry but I'm not buying your argument here at all - it just has no relationship to what's going on at the user side as near as I can tell. > > CKRM is one of those things that could be done to Linux, and will benefit a > > few, but which will almost certainly hurt *most* of the community. > > > > let me say that the CKRM design is actually quite good. the issue is > > whether > > the extensive hooks it requires can be done (at all) in a way which does > > not disporportionately hurt maintainability or efficiency. Can you be more clear on how this will hurt *most* of the community? CKRM when not in use is not in any way intrusive. Can you take a look at the patch again and point out the "extensive" hooks for me? I've looked at "all" of them and I have trouble calling a couple of callbacks "extensive hooks". > > CKRM requires hooks into every resource-allocation decision fastpath: > > - if CKRM is not CONFIG, the only overhead is software maintenance. > > - if CKRM is CONFIG but not loaded, the overhead is a pointer check. > > - if CKRM is CONFIG and loaded, the overhead is a pointer check > > and a nontrivial callback. You left out a case here: CKRM is CONFIG and loaded and classes are defined. In all of the cases that you mentioned, if there are no
[PATCH] Address BUG: using smp_processor_id() in preemptible [00000001] code
This patch fixes a warning in the disable_nonboot_cpus call in
kernel/power/smp.c.
Please apply.
Signed-off by: Nigel Cunningham <[EMAIL PROTECTED]>
smp.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -ruNp 830-smp_processor_id_warning.patch-old/kernel/power/smp.c
830-smp_processor_id_warning.patch-new/kernel/power/smp.c
--- 830-smp_processor_id_warning.patch-old/kernel/power/smp.c 2005-07-18
06:37:08.0 +1000
+++ 830-smp_processor_id_warning.patch-new/kernel/power/smp.c 2005-07-22
11:09:16.0 +1000
@@ -38,7 +38,7 @@ void disable_nonboot_cpus(void)
}
printk("Error taking cpu %d down: %d\n", cpu, error);
}
- BUG_ON(smp_processor_id() != 0);
+ BUG_ON(raw_smp_processor_id() != 0);
if (error)
panic("cpus not sleeping");
}
--
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm1 (ckrm)
Paul Jackson wrote: Martin wrote: No offense, but I really don't see why this matters at all ... the stuff in -mm is what's under consideration for merging - what's in SuSE is ... Yes - what's in SuSE doesn't matter, at least not directly. No - we are not just considering the CKRM that is in *-mm now, but also what can be expected to be proposed as part of CKRM in the future. If the CPU controller is not in *-mm now, but if one might reasonably expect it to be proposed as part of CKRM in the future, then we need to understand that. This is perhaps especially important in this case, where there is some reason to suspect that this additional piece is both non-trivial and essential to CKRM's purpose. The CKRM design explicitly considered this problem of some controllers being more unacceptable than the rest and part of the indirections introduced in CKRM are to allow the kernel community the flexibility of cherry-picking acceptable controllers. So if the current CPU controller implementation is considered too intrusive/unacceptable, it can be reworked or (and we certainly hope not) even rejected in perpetuity. Same for the other controllers as and when they're introduced and proposed for inclusion. -- Shailabh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm1 (ckrm)
Mark Hahn wrote: I suspect that the main problem is that this patch is not a mainstream kernel feature that will gain multiple uses, but rather provides support for a specific vendor middleware product used by that vendor and a few closely allied vendors. If it were smaller or less intrusive, such as a driver, this would not be a big problem. That's not the case. yes, that's the crux. CKRM is all about resolving conflicting resource demands in a multi-user, multi-server, multi-purpose machine. this is a huge undertaking, and I'd argue that it's completely inappropriate for *most* servers. that is, computers are generally so damn cheap that the clear trend is towards dedicating a machine to a specific purpose, rather than running eg, shell/MUA/MTA/FS/DB/etc all on a single machine. The argument about scale-up vs. scale-out is nowhere close to being resolved. To argue that any support for performance partitioning (which CKRM does) is in support of a lost cause is premature to say the least. this is *directly* in conflict with certain prominent products, such as the Altix and various less-prominent Linux-based mainframes. they're all about partitioning/virtualization - the big-iron aesthetic of splitting up a single machine. note that it's not just about "big", since cluster-based approaches can clearly scale far past big-iron, and are in effect statically partitioned. yes, buying a hideously expensive single box, and then chopping it into little pieces is more than a little bizarre, and is mainly based on a couple assumptions: - that clusters are hard. really, they aren't. they are not necessarily higher-maintenance, can be far more robust, usually do cost less. just about the only bad thing about clusters is that they tend to be somewhat larger in size. - that partitioning actually makes sense. the appeal is that if you have a partition to yourself, you can only hurt yourself. but it also follows that burstiness in resource demand cannot be overlapped without either constantly tuning the partitions or infringing on the guarantee. "constantly tuning the partitions" is effectively whats done by workload managers. But our earlier presentations and papers have made the case that this is not the only utility for performance isolation - simple needs like isolating one user from another on a general purpose server is also a need that cannot be met by any existing or proposed Linux kernel mechanisms today. If partitioning made so little sense and the case for clusters was that obvious, one would be hard put to explain why server consolidation is being actively pursued by so many firms, Solaris is bothering with coming up with Containers and Xen/VMWare getting all this attention. I don't think the concept of partitioning can be dismissed so easily. Of course, it must be noted that CKRM only provides performance isolation not fault isolation. But there is a need for that. Whether Linux chooses to let this need influence its design is another matter (which I hope we'll also discuss besides the implementation issues). CKRM is one of those things that could be done to Linux, and will benefit a few, but which will almost certainly hurt *most* of the community. let me say that the CKRM design is actually quite good. the issue is whether the extensive hooks it requires can be done (at all) in a way which does not disporportionately hurt maintainability or efficiency. If there are suggestions on implementing this better, it'll certainly be very welcome. CKRM requires hooks into every resource-allocation decision fastpath: - if CKRM is not CONFIG, the only overhead is software maintenance. - if CKRM is CONFIG but not loaded, the overhead is a pointer check. - if CKRM is CONFIG and loaded, the overhead is a pointer check and a nontrivial callback. but really, this is only for CKRM-enforced limits. CKRM really wants to change behavior in a more "weighted" way, not just causing an allocation/fork/packet to fail. a really meaningful CKRM needs to be tightly integrated into each resource manager - effecting each scheduler (process, memory, IO, net). I don't really see how full-on CKRM can be compiled out, unless these schedulers are made fully pluggable. This is a valid point for the CPU, memory and network controllers (I/O can be made pluggable quite easily). For the CPU controller in SuSE, the CKRM CPU controller can be turned on and off dynamically at runtime. Exploring a similar option for memory and network (incurring only a pointer check) could be explored. Keeping the overhead close to zero for kernel users not interested in CKRM is certainly one of our objectives. finally, I observe that pluggable, class-based resource _limits_ could probably be done without callbacks and potentially with low overhead. but mere limits doesn't meet CKRM's goal of flexible, wide-spread resource partitioning
Re: 2.6.13-rc3-mm1 (ckrm)
On Fri, 22 Jul 2005 13:46:37 +1000, Peter Williams wrote: > Gerrit Huizenga wrote: > >>I imagine that the cpu controller is missing from this version of CKRM > >>because the bugs introduced to the cpu controller during upgrading from > >>2.6.5 to 2.6.10 version have not yet been resolved. > > > > > > I don't know what bugs you are referring to here. I don't think we > > have any open defects with SuSE on the CPU scheduler in their releases. > > And that is not at all related to the reason for not having a CPU > > controller in the current patch set. > > The bugs were in the patches for the 2.6.10 kernel not SuSE's 2.6.5 > kernel. I reported some of them to the ckrm-tech mailing list at the > time. There were changes to the vanilla scheduler between 2.6.5 and > 2.6.10 that were not handled properly when the CKRM scheduler was > upgraded to the 2.6.10 kernel. Ah - okay - that makes sense. Those patches haven't gone through my review yet and I'm not directly tracking their status until I figure out what the right direction is with respect to a fair share style scheduler of some sort. I'm not convinced that the current one is something that is ready for mainline or is necessarily the right answer currently. But we do need to figure out something that will provide some level of CPU allocation minima & maxima for a class, where that solution will work well on a laptop or a huge server. Ideas in that space are welcome - I know of several proposed ideas in progress - the scheduler in SuSE and the forward port to 2.6.10 that you referred to; an idea for building a very simple interface on top of sched_domains for SMP systems (no fairness within a single CPU) and a proposal for timeslice manipulation that might provide some fairness that the Fujitsu folks are thinking about. There are probably others and honestly, I don't have any clue yet as to what the right long term/mainline direction should be here as yet. gerrit - 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 guide to space
Miles wrote: > CodingStyle is vague on the issue, though ... Perhaps we should call it "coding_style" . -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 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: 2.6.13-rc3-mm1 (ckrm)
Martin wrote: > No offense, but I really don't see why this matters at all ... the stuff > in -mm is what's under consideration for merging - what's in SuSE is ... Yes - what's in SuSE doesn't matter, at least not directly. No - we are not just considering the CKRM that is in *-mm now, but also what can be expected to be proposed as part of CKRM in the future. If the CPU controller is not in *-mm now, but if one might reasonably expect it to be proposed as part of CKRM in the future, then we need to understand that. This is perhaps especially important in this case, where there is some reason to suspect that this additional piece is both non-trivial and essential to CKRM's purpose. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 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: 2.6.13-rc3-mm1 (ckrm)
Gerrit Huizenga wrote: On Fri, 22 Jul 2005 11:06:14 +1000, Peter Williams wrote: Paul Jackson wrote: Matthew wrote: I don't see the large ifdefs you're referring to in -mm's kernel/sched.c. Perhaps someone who knows CKRM better than I can explain why the CKRM version in some SuSE releases based on 2.6.5 kernels has substantial code and some large ifdef's in sched.c, but the CKRM in *-mm doesn't. Or perhaps I'm confused. There's a good chance that this represents ongoing improvements that CKRM is making to reduce their footprint in core kernel code. Or perhaps there is a more sophisticated cpu controller in the SuSE kernel. As there is NO CKRM cpu controller in 2.6.13-rc3-mm1 (that I can see) the one in 2.6.5 is certainly more sophisticated :-). So the reason that the considerable mangling of sched.c evident in SuSE's 2.6.5 kernel source is not present is that the cpu controller is not included in these patches. Yeah - I don't really consider the current CPU controller code something ready for consideration yet for mainline merging. That doesn't mean we don't want a CPU controller for CKRM - just that what we have doesn't integrate cleanly/nicely with mainline. I imagine that the cpu controller is missing from this version of CKRM because the bugs introduced to the cpu controller during upgrading from 2.6.5 to 2.6.10 version have not yet been resolved. I don't know what bugs you are referring to here. I don't think we have any open defects with SuSE on the CPU scheduler in their releases. And that is not at all related to the reason for not having a CPU controller in the current patch set. The bugs were in the patches for the 2.6.10 kernel not SuSE's 2.6.5 kernel. I reported some of them to the ckrm-tech mailing list at the time. There were changes to the vanilla scheduler between 2.6.5 and 2.6.10 that were not handled properly when the CKRM scheduler was upgraded to the 2.6.10 kernel. Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - 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/
fastboot, diskstat
Hi Andrew, I'm currently at OLS and presented http://ds9a.nl/diskstat yesterday, which also references your ancient 'fboot' program. I've also done experiments along those lines, and will be doing more of them soon. You mention it was a waste of time, do you recall if that meant: 1) that the total time for prefetching + actual boot was only 10% shorter, but that the actual booting did not (significantly) touch the disk? 2) that on actual boot there would still be a lot of i/o ? Regarding 1), in my own experiments I failed to convince the kernel to actually cache the pages I touched, I wonder if some sequential-read detection kicked in, the one that prevents entire cd's being cached. For my next attempt I'll try to actually lock the pages into memory. Also, regarding the directory entries, are they accessed via the buffer cache? Iow, would reading blocks which can't be mapped to files directly via /dev/hda be useful? Thanks! -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services - 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: Obsolete files in 2.6 tree
Jiri Slaby wrote: > Bob Tracy napsal(a): > >Jiri Slaby wrote: > >>Are these files obsolete and could be deleted from tree. > >>Does anybody use them? Could anybody compile them? > >>(...) > >>drivers/scsi/NCR5380.c > >>drivers/scsi/NCR5380.h > >>(...) > > > >The above are used by (at least) the PAS16 SCSI driver. > > I think, that this driver uses g_NCR5380.c and g_NCR5380.h, doesn't it? grep include pas16.c | grep NCR5380 produces... #include "NCR5380.h" #include "NCR5380.c" -- --- Bob Tracy WTO + WIPO = DMCA? http://www.anti-dmca.org [EMAIL PROTECTED] --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Giving developers clue how many testers verified certain kernel version
Martin MOKREJŠ wrote: Hi, Mark Nipper wrote: I have a different idea along these lines but not using bugzilla. A nice system for tracking usage of certain components might be made by having people register using a certain e-mail address and then submitting their .config as they try out new versions of kernels. Nice idea, but I still think it is of interrest on what hardware was it tested. Maybe also 'dmesg' output would help a bit, but I still don't know how you'd find that I have _this_ motherboard instead of another. I'm a simple Linux user that normally likes to test as much things as posible. This is what I would do: I would make a Summary of the ChangeLog that was done to the kernel, and from there encourage people to test those parts. The worst part that I face against Linux is that I don't know C enough like to understand what the patch that someone sent will really do. A user understandable ChangeLog so that people can test those changed points would be great. And if those changes could have an explanation on how users could troubleshoot the change, then it would be fairly awesome. I have been subscribed here for more than a year already, and I have barely understood a couple of changes that have been done to Drivers and to the kernel itself. How can I make sure that the change will really work better for me? How does one check if hotplug is working better than before? How do I test the fact that a performance issue seen in the driver is now fixed for me or most of users? How do I get back to a bugzilla and tell that there is a bug somewhere when one can't really know if that is the way it works but is simply ugly, or if there is really a bug? My point is that a user like me, can't really get back to this mailing list and say "hey, since 2.6.13-rc1, my PCI bus is having an additional 1ms of latency" We don't really have a process to follow and then be able to say "ahha, so this is different" and then report the problem, even if we can't fix it because of our C and kernel skills. How do we know that something is OK or wrong? just by the fact that it works or not, it doesn't mean like is OK. There has to be a process for any user to be able to verify and study a problem. We don't have that yet. .Alejandro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.13-rc3a] i386: inline restore_fpu
Chuck Ebbert <[EMAIL PROTECTED]> wrote: > > > This patch makes restore_fpu() an inline. When L1/L2 cache are saturated > it makes a measurable difference. > > Results from profiling Volanomark follow. Sample rate was 2000 samples/sec > (HZ = 250, profile multiplier = 8) on a dual-processor Pentium II Xeon. > > > Before: > > 10680 restore_fpu 333.7500 > 8351 device_not_available 203.6829 > 3823 math_state_restore59.7344 > - > 22854 > > > After: > > 12534 math_state_restore 130.5625 > 8354 device_not_available 203.7561 > - > 20888 > > > Patch is "obviously correct" and cuts 9% of the overhead. Please apply. hm. What context switch rate is that thing doing? Is the benchmark actually doing floating point stuff? We do have the `used_math' optimisation in there which attempts to avoid doing the FP save/restore if the app isn't actually using math. But there's code in glibc startup which always does a bit of float, so that optimisation is always defeated. There was some discussion about periodically setting tasks back into !used_math state to try to restore the optimisation for tasks which only do a little bit of FP, but nothing actually got done. > Next step should be to physically place math_state_restore() after > device_not_available(). Would such a patch be accepted? (Yes it > would be ugly and require linker script changes.) Depends on the benefit/ugly ratio ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm1 (ckrm)
On Fri, 22 Jul 2005 11:06:14 +1000, Peter Williams wrote: > Paul Jackson wrote: > > Matthew wrote: > > > >>I don't see the large ifdefs you're referring to in -mm's > >>kernel/sched.c. > > > > > > Perhaps someone who knows CKRM better than I can explain why the CKRM > > version in some SuSE releases based on 2.6.5 kernels has substantial > > code and some large ifdef's in sched.c, but the CKRM in *-mm doesn't. > > Or perhaps I'm confused. There's a good chance that this represents > > ongoing improvements that CKRM is making to reduce their footprint > > in core kernel code. Or perhaps there is a more sophisticated cpu > > controller in the SuSE kernel. > > As there is NO CKRM cpu controller in 2.6.13-rc3-mm1 (that I can see) > the one in 2.6.5 is certainly more sophisticated :-). So the reason > that the considerable mangling of sched.c evident in SuSE's 2.6.5 kernel > source is not present is that the cpu controller is not included in > these patches. Yeah - I don't really consider the current CPU controller code something ready for consideration yet for mainline merging. That doesn't mean we don't want a CPU controller for CKRM - just that what we have doesn't integrate cleanly/nicely with mainline. > I imagine that the cpu controller is missing from this version of CKRM > because the bugs introduced to the cpu controller during upgrading from > 2.6.5 to 2.6.10 version have not yet been resolved. I don't know what bugs you are referring to here. I don't think we have any open defects with SuSE on the CPU scheduler in their releases. And that is not at all related to the reason for not having a CPU controller in the current patch set. gerrit - 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-cluster] Re: [Ocfs2-devel] [RFC] nodemanager, ocfs2, dlm
On Thursday 21 July 2005 02:55, Walker, Bruce J (HP-Labs) wrote: > Like Lars, I too was under the wrong impression about this configfs > "nodemanager" kernel component. Our discussions in the cluster meeting > Monday and Tuesday were assuming it was a general service that other > kernel components could/would utilize and possibly also something that > could send uevents to non-kernel components wanting a std. way to see > membership information/events. > > As to kernel components without corresponding user-level "managers", look > no farther than OpenSSI. Our hope was that we could adapt to a user-land > membership service and this interface thru configfs would drive all our > kernel subsystems. Guys, it is absolutely stupid to rely on a virtual filesystem for userspace/kernel communication for any events that might have to be transmitted inside the block IO path. This includes, among other things, memberhips events. Inserting a virtual filesystem into this path does nothing but add long call chains and new, hard-to-characterize memory usage. There are already tried-and-true interfaces that are designed to do this kind of job efficiently and with quantifiable resource requirements: sockets (UNIX domain or netlink) and ioctls. If you want to layer a virtual filesystem on top as a user friendly way to present current cluster configuration or as a way to provide some administrator knobs, then fine, virtual filesystems are good for this kind of thing. But please do not try to insinuate that bloat into the block IO path. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PPC64] Dynamically allocate segment tables
PPC64 machines before Power4 need a segment table page allocated for
each CPU. Currently these are allocated statically in a big array in
head.S for all CPUs. The segment tables need to be in the first
segment (so do_stab_bolted doesn't take a recursive fault on the stab
itself), but other than that there are no constraints which require
the stabs for the secondary CPUs to be statically allocated.
This patch allocates segment tables dynamically during boot, using
lmb_alloc() to ensure they are within the first 256M segment. This
reduces the kernel image size by 192k...
Tested on RS64 iSeries, POWER3 pSeries, and POWER5.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: working-2.6/arch/ppc64/kernel/head.S
===
--- working-2.6.orig/arch/ppc64/kernel/head.S 2005-07-14 10:57:49.0
+1000
+++ working-2.6/arch/ppc64/kernel/head.S2005-07-21 15:23:31.0
+1000
@@ -2131,13 +2131,6 @@
swapper_pg_dir:
.space 4096
-#ifdef CONFIG_SMP
-/* 1 page segment table per cpu (max 48, cpu0 allocated at STAB0_PHYS_ADDR) */
- .globl stab_array
-stab_array:
- .space 4096 * 48
-#endif
-
/*
* This space gets a copy of optional info passed to us by the bootstrap
* Used to pass parameters into the kernel like root=/dev/sda1, etc.
Index: working-2.6/arch/ppc64/kernel/smp.c
===
--- working-2.6.orig/arch/ppc64/kernel/smp.c2005-07-06 10:30:12.0
+1000
+++ working-2.6/arch/ppc64/kernel/smp.c 2005-07-21 14:55:28.0 +1000
@@ -65,8 +65,6 @@
static volatile unsigned int cpu_callin_map[NR_CPUS];
-extern unsigned char stab_array[];
-
void smp_call_function_interrupt(void);
int smt_enabled_at_boot = 1;
@@ -492,19 +490,6 @@
paca[cpu].default_decr = tb_ticks_per_jiffy;
- if (!cpu_has_feature(CPU_FTR_SLB)) {
- void *tmp;
-
- /* maximum of 48 CPUs on machines with a segment table */
- if (cpu >= 48)
- BUG();
-
- tmp = _array[PAGE_SIZE * cpu];
- memset(tmp, 0, PAGE_SIZE);
- paca[cpu].stab_addr = (unsigned long)tmp;
- paca[cpu].stab_real = virt_to_abs(tmp);
- }
-
/* Make sure callin-map entry is 0 (can be leftover a CPU
* hotplug
*/
Index: working-2.6/arch/ppc64/kernel/setup.c
===
--- working-2.6.orig/arch/ppc64/kernel/setup.c 2005-07-14 10:57:49.0
+1000
+++ working-2.6/arch/ppc64/kernel/setup.c 2005-07-21 15:23:31.0
+1000
@@ -1071,6 +1071,8 @@
irqstack_early_init();
emergency_stack_init();
+ stabs_alloc();
+
/* set up the bootmem stuff with available memory */
do_init_bootmem();
sparse_init();
Index: working-2.6/arch/ppc64/mm/stab.c
===
--- working-2.6.orig/arch/ppc64/mm/stab.c 2005-06-08 15:46:23.0
+1000
+++ working-2.6/arch/ppc64/mm/stab.c2005-07-21 15:23:31.0 +1000
@@ -18,6 +18,8 @@
#include
#include
#include
+#include
+#include
struct stab_entry {
unsigned long esid_data;
@@ -224,6 +226,39 @@
extern void slb_initialize(void);
/*
+ * Allocate segment tables for secondary CPUs. These must all go in
+ * the first (bolted) segment, so that do_stab_bolted won't get a
+ * recursive segment miss on the segment table itself.
+ */
+void stabs_alloc(void)
+{
+ int cpu;
+
+ if (cpu_has_feature(CPU_FTR_SLB))
+ return;
+
+ for_each_cpu(cpu) {
+ unsigned long newstab;
+
+ if (cpu == 0)
+ continue; /* stab for CPU 0 is statically allocated */
+
+ newstab = lmb_alloc_base(PAGE_SIZE, PAGE_SIZE, 1
Why build empty object files in drivers/media?
I have this in my .config file for 2.6.13-rc3: # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set And yet these completely empty files are being built: $ find drivers/media -name built-in.o | xargs ls -go -rw-rw-r-- 1 305 Jul 16 00:20 drivers/media/built-in.o -rw-rw-r-- 1 8 Jul 16 00:20 drivers/media/common/built-in.o -rw-rw-r-- 1 8 Jul 16 00:20 drivers/media/dvb/b2c2/built-in.o -rw-rw-r-- 1 8 Jul 16 00:20 drivers/media/dvb/bt8xx/built-in.o -rw-rw-r-- 1 305 Jul 16 00:20 drivers/media/dvb/built-in.o -rw-rw-r-- 1 8 Jul 16 00:20 drivers/media/dvb/cinergyT2/built-in.o -rw-rw-r-- 1 8 Jul 16 00:20 drivers/media/dvb/dvb-core/built-in.o -rw-rw-r-- 1 8 Jul 16 00:20 drivers/media/dvb/dvb-usb/built-in.o -rw-rw-r-- 1 8 Jul 16 00:20 drivers/media/dvb/frontends/built-in.o -rw-rw-r-- 1 8 Jul 16 00:20 drivers/media/dvb/pluto2/built-in.o -rw-rw-r-- 1 8 Jul 16 00:20 drivers/media/dvb/ttpci/built-in.o -rw-rw-r-- 1 8 Jul 16 00:20 drivers/media/dvb/ttusb-budget/built-in.o -rw-rw-r-- 1 8 Jul 16 00:20 drivers/media/dvb/ttusb-dec/built-in.o -rw-rw-r-- 1 8 Jul 16 00:20 drivers/media/radio/built-in.o -rw-rw-r-- 1 8 Jul 16 00:20 drivers/media/video/built-in.o $ size drivers/media/built-in.o textdata bss dec hex filename 0 0 0 0 0 drivers/media/built-in.o __ Chuck - 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.13-rc3a] i386: inline restore_fpu
This patch makes restore_fpu() an inline. When L1/L2 cache are saturated
it makes a measurable difference.
Results from profiling Volanomark follow. Sample rate was 2000 samples/sec
(HZ = 250, profile multiplier = 8) on a dual-processor Pentium II Xeon.
Before:
10680 restore_fpu 333.7500
8351 device_not_available 203.6829
3823 math_state_restore59.7344
-
22854
After:
12534 math_state_restore 130.5625
8354 device_not_available 203.7561
-
20888
Patch is "obviously correct" and cuts 9% of the overhead. Please apply.
Next step should be to physically place math_state_restore() after
device_not_available(). Would such a patch be accepted? (Yes it
would be ugly and require linker script changes.)
Signed-off-by: Chuck Ebbert <[EMAIL PROTECTED]>
Index: 2.6.13-rc3a/arch/i386/kernel/i387.c
===
--- 2.6.13-rc3a.orig/arch/i386/kernel/i387.c
+++ 2.6.13-rc3a/arch/i386/kernel/i387.c
@@ -82,17 +82,6 @@
}
EXPORT_SYMBOL_GPL(kernel_fpu_begin);
-void restore_fpu( struct task_struct *tsk )
-{
- if ( cpu_has_fxsr ) {
- asm volatile( "fxrstor %0"
- : : "m" (tsk->thread.i387.fxsave) );
- } else {
- asm volatile( "frstor %0"
- : : "m" (tsk->thread.i387.fsave) );
- }
-}
-
/*
* FPU tag word conversions.
*/
Index: 2.6.13-rc3a/include/asm-i386/i387.h
===
--- 2.6.13-rc3a.orig/include/asm-i386/i387.h
+++ 2.6.13-rc3a/include/asm-i386/i387.h
@@ -22,11 +22,20 @@
/*
* FPU lazy state save handling...
*/
-extern void restore_fpu( struct task_struct *tsk );
-
extern void kernel_fpu_begin(void);
#define kernel_fpu_end() do { stts(); preempt_enable(); } while(0)
+static inline void restore_fpu( struct task_struct *tsk )
+{
+ if ( cpu_has_fxsr ) {
+ asm volatile( "fxrstor %0"
+ : : "m" (tsk->thread.i387.fxsave) );
+ } else {
+ asm volatile( "frstor %0"
+ : : "m" (tsk->thread.i387.fsave) );
+ }
+}
+
/*
* These must be called with preempt disabled
*/
__
Chuck
-
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: Giving developers clue how many testers verified certain kernel version
Hi, Mark Nipper wrote: I have a different idea along these lines but not using bugzilla. A nice system for tracking usage of certain components might be made by having people register using a certain e-mail address and then submitting their .config as they try out new versions of kernels. Nice idea, but I still think it is of interrest on what hardware was it tested. Maybe also 'dmesg' output would help a bit, but I still don't know how you'd find that I have _this_ motherboard instead of another. Second, I'd submit sometimes 2 or even 3 tested hosts. But am willing to use only single email, though. ;) I think we'd need some sort of profile, the profile would contain some HW info, like motherboard type, bios version etc. To extract that from 'dmesg' would be a nightmare I think. ... Just an idea. It might require some minimum recommendations to users willing to participate. I know for example that I statically compile all four I/O schedulers in all Well, my case too. ;) Martin - 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 guide to space
"linux-os \(Dick Johnson\)" <[EMAIL PROTECTED]> writes: > It will take probably an hour to parse: > struct BusLogic_FetchHostAdapterLocalRAMReguest > FetchHostAdapterLocalRAMRequest > ^!) Agh! My eyes! The above names are way overdone by any measure, but is there any consensus whether studly-caps in general are discouraged or not? CodingStyle is vague on the issue, though it kind of implies you should use underscores when multiple words are needed (the sole example of studly caps is in a negative context, and a following recommended name uses underlines). The kernel source seems pretty random -- they get used here and there, but more often not; they seem more common in older code. If they are discouraged, it might be better to say so explicitly, as there are many programmers these days who are used to using them. -Miles -- Run away! Run away! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [announce] 'patchview' ver. 003
randy_dunlap wrote:
Hi,
[version 003]
'patchview' merges a patch file and a source tree to a set of
temporary modified files. This enables better patch (re)viewing
and more viewable context. (hopefully)
The patchview script is here:
http://www.xenotime.net/linux/scripts/patchview
usage: patchview [-f] patchfile srctree {ver. 003}
-f : force tkdiff even if 'patch' has errors
-s : single tkdiff even if patchfile contains multiple files
It uses (requires) lsdiff (from patchutils) and tkdiff.
patchutils: http://cyberelk.net/tim/patchutils/
tkdiff: http://sourceforge.net/projects/tkdiff/
---
~Randy
Changes for ver. 003:
- handle patch making empty .orig files (for new files)
with permission of 000
Hi, Randy.
Here's a small modification to make it work with mtkdiff (my hacked
version of tkdiff which supports multiple files). mtkdiff+patchview
tarball is available at the following url.
http://home-tj.org/mtkdiff/files/patchview-mtkdiff.tar.gz
--- patchview.orig 2005-07-22 11:19:26.0 +0900
+++ patchview/patchview 2005-07-22 11:21:01.0 +0900
@@ -5,7 +5,7 @@
# uses patchutils (lsdiff) and tkdiff
PROG=patchview
-VERSION=003
+VERSION=004
# usage: help message and exit
function usage()
@@ -40,7 +40,12 @@
force=0
single=0
+mtkdiff=0
VIEWER="tkdiff"
+if [ -x "`which mtkdiff`" ]; then
+ VIEWER="mtkdiff"
+ mtkdiff=1
+fi
# or maybe "sh -c colordiff" would work
while [ -n "$1" ]
@@ -117,15 +122,29 @@
exit 1
fi
-for pf in $pfiles ; do
- $VIEWER $WORKDIR/$pf.orig $WORKDIR/$pf &
- if [ ${single} -eq 1 ]; then
- wait # for viewer to exit
- fi
-done
+if [ $mtkdiff -ne 0 ]; then
+ i=0
+ argv[i++]="-gdesc"
+ argv[i++]=`diffstat $patchfile`
+ for pf in $pfiles ; do
+ argv[i++]="-fname"
+ argv[i++]="$pf"
+ argv[i++]="$WORKDIR/$pf.orig"
+ argv[i++]="$WORKDIR/$pf"
+ done
-if [ ${single} -eq 0 ]; then
- wait # for all viewers to exit
+ mtkdiff "[EMAIL PROTECTED]"
+else
+ for pf in $pfiles ; do
+ $VIEWER $WORKDIR/$pf.orig $WORKDIR/$pf &
+ if [ ${single} -eq 1 ]; then
+ wait # for viewer to exit
+ fi
+ done
+
+ if [ ${single} -eq 0 ]; then
+ wait # for all viewers to exit
+ fi
fi
rm -rf $WORKDIR
-
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: Giving developers clue how many testers verified certain kernel version
I have a different idea along these lines but not using bugzilla. A nice system for tracking usage of certain components might be made by having people register using a certain e-mail address and then submitting their .config as they try out new versions of kernels. The idea of course is that people will generally only have compiled their own custom kernels with the drivers and components they tend to use most. It might be enough to ask people who use this system to only submit mostly customized configurations as opposed to distribution style kernel configurations where almost everything is compiled as a module. Anyway, the end result being that kernel developers could ultimately refer to this system and see as they change things whether a lot of people are hitting the components in the kernel which might have been affected by their changes. If even one hundred people report using some specific subsystem which has recently undergone significant change without any reports of problems, then the developer can rest somewhat more easily knowing their changes were probably made without incident. Just an idea. It might require some minimum recommendations to users willing to participate. I know for example that I statically compile all four I/O schedulers in all my kernels currently even though I always let the kernel select whichever is the default and never change it myself. Obviously it would make more sense for me to axe those schedulers which are not absolutely necessary to make whatever statistics being gathered on my particular configuration more useful to a developer checking to see which schedulers are being used and to what extent. -- Mark Nippere-contacts: 4475 Carter Creek Parkway [EMAIL PROTECTED] Apartment 724 http://nipsy.bitgnome.net/ Bryan, Texas, 77802-4481 AIM/Yahoo: texasnipsy ICQ: 66971617 (979)575-3193 MSN: [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 GG/IT d- s++:+ a- C++$ UBL$ 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-- ---begin random quote of the moment--- This sentence no verb. end random quote of the moment - 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 0/3] Add disk hotswap support to libata
Lukasz Kosewski wrote: Hey all, introductory blurb here. This sequence of patches will add a framework to libata to allow for hot-swapping disks in and out. There are three patches: 01-promise_sataII150_support 02-libata_hotswap_infrastructure 03-promise_hotswap_support Pretty cool stuff! As soon as I finish SATA ATAPI (this week[end]), I'll take a look at this. A quick review of the patches didn't turn up anything terribly objectionable, though :) Jeff P.S. You might want to CC linux-ide as well, on libata patches. - 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/
Giving developers clue how many testers verified certain kernel version
Hi, I think the discussion going on here in another thread about lack of positive information on how many testers successfully tested certain kernel version can be easily solved with real solution. How about opening separate "project" in bugzilla.kernel.org named kernel-testers or whatever, where whenever cvs/svn/bk gatekeepers would release some kernel patch, would open an empty "bugreport" for that version, say for 2.6.13-rc3-git4. Anybody willing to join the crew who cared to download the patch and tested the kernel would post just a single comment/follow-up to _that_ "bugreport" with either "positive" rating or URL of his own bugreport with some new bug. When the bug get's closed it would be immediately obvious in the 2.6.13-rc3-git4 bug ticket as that bug will be striked-through as closed. Then, we could easily just browse through and see that 2.6.13-rc2 was tested by 33 fellows while 3 of them found a problem and 2 such problems were closed since then. I know what would be really helpfull if the testers would report let's say motherboard type, HIGHMEM/NO-HIGHMEM, ACPI/NO-ACPI, SMP/NO-SMP and few more hints and if teh database would keep those having same hardware + config as a single record. It could even just watch few lines in .config file when uploaded. Well I'm sure you got my point, maybe it would be easier to write some tiny database from scratch instead of tweaking bugzilla to suit this king of solution. ;-) Martin - 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 guide to space
On 7/21/05, Jesper Juhl <[EMAIL PROTECTED]> wrote: > On 7/21/05, linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote: > > > > On Thu, 21 Jul 2005, Jesper Juhl wrote: > > > > > On 7/21/05, Kyle Moffett <[EMAIL PROTECTED]> wrote: > > >> On Jul 20, 2005, at 20:45:21, Paul Jackson wrote: > > > [...snip...] > > >> *cough* TargetStatistics[TargetID].HostAdapterResetsCompleted *cough* > > >> > > >> I suspect linus would be willing to accept a few cleanup patches for the > > >> BusLogic.c file. Perhaps even one that renames BusLogic.c to buslogic.c > > >> like all the other files in the source tree, instead of using nasty > > >> StudlyCaps all over :-D > > >> > > > > > > To avoid people doing duplicate work, I just want to say that I've > > > started doing a CodingStyle/whitespace/VariableAndFunctionNaming > > > cleanup of the BusLogic driver, I'll send the patches to LKML in a few > > > hours. > > > > > Are you going to get rid of the BusLogic* in front of every variable > > and function name? (yes please??) > Yes, I am. > > > If so, you will need a few days! > > That may be, it sure turned into a bigger job than I had at first > expected. I'll break it into a few logical bits and submit them along > the way. First bits in a few hours - let's see how far I get :) > > > > It will take probably an hour to parse: > > struct BusLogic_FetchHostAdapterLocalRAMReguest > > Yeah, it takes time, but I'll get it done. > Heh, it takes a little more time than I had anticipated. I've got ~300Kb of patches here already, and I'm only about 30% done (estimated). It makes little sense to post the patches I have at this time, since they don't really finish the job and leave the files in a funky intermediate state, so I'll hold off on posting them untill I'm a little closer to the goal - hopefully tomorrow I'll finish it (right now I need to get some sleep) - I'll post the patches as soon as I'm done with them... -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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,rfc] Support for touchscreen on sharp zaurus sl-5500
Hi!
> > + set_task_state(tsk, TASK_UNINTERRUPTIBLE);
> > + schedule_timeout(HZ / 100);
> > + if (signal_pending(tsk))
> > + break;
>
> You specifically allow SIGKILL, but then sleep uninterruptibly? And
> then you check if signal_pending() :) I think you may want
> TASK_INTERRUPTIBLE? Or, go one better and use msleep_interruptible(),
> as I don't see any wait-queues in the immediate area of this code...
Okay, I think this should be uninterruptible. The signal can be
delivered during next interruptible sleep. Fixes.
> > +/**
> > + * ucb1x00_adc_read - read the specified ADC channel
> > + * @ucb: UCB1x00 structure describing chip
> > + * @adc_channel: ADC channel mask
> > + * @sync: wait for syncronisation pulse.
> > + *
> > + * Start an ADC conversion and wait for the result. Note that
> > + * synchronised ADC conversions (via the ADCSYNC pin) must wait
> > + * until the trigger is asserted and the conversion is finished.
> > + *
> > + * This function currently spins waiting for the conversion to
> > + * complete (2 frames max without sync).
>
> You technically sleep (schedule_timeout()), not spin...
Well, it also spins :-).
> > + for (;;) {
> > + val = ucb1x00_reg_read(ucb, UCB_ADC_DATA);
> > + if (val & UCB_ADC_DAT_VAL)
> > + break;
> > + /* yield to other processes */
> > + set_current_state(TASK_INTERRUPTIBLE);
> > + schedule_timeout(1);
> > + }
>
> If I ever add a poll_event() interface to the kernel, this would be a
> good user. You don't check if signal_pending(), though, even though
> you are in INTERRUPTIBLE state... Maybe this case can use
> UNINTERRUPTIBLE?
Ok, UNINTERRUPTIBLE here...
Pavel
--
Boycott Kodak -- for their patent abuse against Java.
-
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 page size explanation
On 7/22/05, Gaspar Bakos <[EMAIL PROTECTED]> wrote: > Hi, > > Sorry for this nursery-school question. > > Could someone briefly explain me : > 1. what is the kernel page size (any _useful_ pointer on the web is fine), Depends on arch. Take a look at PAGE_SIZE and PAGE_SHIFT - look in include/asm-*/page.h Here's a nice web interface for browsing the source and quickly finding the info you need :) : http://lxr.linux.no/ident?i=PAGE_SIZE > 2. how can one tune it (for 2.6.*)? For some archs the page size can be set at compile-time with CONFIG_PAGE_SIZE_4KB, CONFIG_PAGE_SIZE_8KB etc - mips is an example of such an arch (also take a look at CONFIG_HUGETLB_PAGE and friends). > 3. what kind of effect does it have on system performance, if it is > tuneable, and if it worth changing this at all? > Depends on your workload. > I am a bit confused; at one place i see someone saying that the kernel > page size is 4kb for i386. > At another place I see a statement: > "I tried all four possible page sizes on Itanium (4k, 8k, 16k and 64k)" > That makes perfect sense - i386 uses a 4K page size, ia64 is one of the archs that support different page sizes (via CONFIG_IA64_PAGE_SIZE_* ). some i386 machines can also use 4MB pages IIRC, but I don't think Linux lets you configure that for i386, but I'm not entirely sure. > How can i figure out the page size of the kernel i am currently using? > You can A) look in the .config file for your current kernel (if your arch supports different page sizes at all). B) You can use the getpagesize(2) syscall at runtime. getpagesize() returns the nr of bytes in a page - man getpagesize - I'm not sure that's universally supported though. C) You can look at /proc/cpuinfo or /proc/meminfo , IIRC some archs report page size there - not quite sure, can't remember... -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] fix u32 vs. pm_message_t confusion in mesh.c
From: Alexander Nyberg <[EMAIL PROTECTED]> Fix u32 vs. pm_message_t confusion in drivers/scsi/mesh.c. Signed-off-by: Alexander Nyberg <[EMAIL PROTECTED]> Signed-off-by: Pavel Machek <[EMAIL PROTECTED]> --- commit 3bd0270be587b87ec14f1fdc50bd8c9e3f1142dc tree 01e19108833246642422af3371b0ca996ade1893 parent b3ace94a1a465a2084bed642021aa8c8ddd912d1 author <[EMAIL PROTECTED](none)> Fri, 22 Jul 2005 03:14:24 +0200 committer <[EMAIL PROTECTED](none)> Fri, 22 Jul 2005 03:14:24 +0200 drivers/scsi/mesh.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/mesh.c b/drivers/scsi/mesh.c --- a/drivers/scsi/mesh.c +++ b/drivers/scsi/mesh.c @@ -1766,7 +1766,7 @@ static int mesh_suspend(struct macio_dev struct mesh_state *ms = (struct mesh_state *)macio_get_drvdata(mdev); unsigned long flags; - if (state == mdev->ofdev.dev.power.power_state || state < 2) + if (state.event == mdev->ofdev.dev.power.power_state.event || state.event < 2) return 0; scsi_block_requests(ms->host); @@ -1791,7 +1791,7 @@ static int mesh_resume(struct macio_dev struct mesh_state *ms = (struct mesh_state *)macio_get_drvdata(mdev); unsigned long flags; - if (mdev->ofdev.dev.power.power_state == 0) + if (mdev->ofdev.dev.power.power_state.event == PM_EVENT_ON) return 0; set_mesh_power(ms, 1); @@ -1802,7 +1802,7 @@ static int mesh_resume(struct macio_dev enable_irq(ms->meshintr); scsi_unblock_requests(ms->host); - mdev->ofdev.dev.power.power_state = 0; + mdev->ofdev.dev.power.power_state.event = PM_EVENT_ON; return 0; } -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm1 (ckrm)
Paul Jackson wrote: Matthew wrote: I don't see the large ifdefs you're referring to in -mm's kernel/sched.c. Perhaps someone who knows CKRM better than I can explain why the CKRM version in some SuSE releases based on 2.6.5 kernels has substantial code and some large ifdef's in sched.c, but the CKRM in *-mm doesn't. Or perhaps I'm confused. There's a good chance that this represents ongoing improvements that CKRM is making to reduce their footprint in core kernel code. Or perhaps there is a more sophisticated cpu controller in the SuSE kernel. As there is NO CKRM cpu controller in 2.6.13-rc3-mm1 (that I can see) the one in 2.6.5 is certainly more sophisticated :-). So the reason that the considerable mangling of sched.c evident in SuSE's 2.6.5 kernel source is not present is that the cpu controller is not included in these patches. I imagine that the cpu controller is missing from this version of CKRM because the bugs introduced to the cpu controller during upgrading from 2.6.5 to 2.6.10 version have not yet been resolved. Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm1 (ckrm)
Paul Jackson wrote: Matthew wrote: Perhaps someone who knows CKRM better than I can explain why the CKRM version in some SuSE releases based on 2.6.5 kernels has substantial code and some large ifdef's in sched.c, but the CKRM in *-mm doesn't. Or perhaps I'm confused. There's a good chance that this represents ongoing improvements that CKRM is making to reduce their footprint in core kernel code. Or perhaps there is a more sophisticated cpu controller in the SuSE kernel. No offense, but I really don't see why this matters at all ... the stuff in -mm is what's under consideration for merging - what's in SuSE is wholly irrelevant ? One obvious thing is that that codebase will be much older ... would be useful if people can direct critiques at the current codebase ;-) M. - 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,rfc] Support for touchscreen on sharp zaurus sl-5500
On 7/20/05, Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> This adds support for touchscreen of sharp zaurus sl-5500. I got the
> patches from John Lenz <[EMAIL PROTECTED]>, but lots of copyrights are
> Russell King. To do so, it needs to add quite a bit of
> infrastructure. If there's better place for some code, please let me
> know (I already moved touchscreen parts to drivers/input).
> diff --git a/drivers/input/touchscreen/collie_ts.c
> b/drivers/input/touchscreen/collie_ts.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/input/touchscreen/collie_ts.c
> +static int ucb1x00_thread(void *_ts)
> +{
> + struct ucb1x00_ts *ts = _ts;
> + struct task_struct *tsk = current;
> + int valid;
> +
> + ts->rtask = tsk;
> +
> + daemonize("ktsd");
> + /* only want to receive SIGKILL */
> + allow_signal(SIGKILL);
> +
> + /*
> +* We run as a real-time thread. However, thus far
> +* this doesn't seem to be necessary.
> +*/
> + tsk->policy = SCHED_FIFO;
> + tsk->rt_priority = 1;
> +
> + complete(>init_exit);
> +
> + valid = 0;
> +
> + for (;;) {
> + unsigned int x, y, p, val;
> +
> + ts->restart = 0;
> +
> + ucb1x00_adc_enable(ts->ucb);
> +
> + x = ucb1x00_ts_read_xpos(ts);
> + y = ucb1x00_ts_read_ypos(ts);
> + p = ucb1x00_ts_read_pressure(ts);
> +
> + /*
> +* Switch back to interrupt mode.
> +*/
> + ucb1x00_ts_mode_int(ts);
> + ucb1x00_adc_disable(ts->ucb);
> +
> + set_task_state(tsk, TASK_UNINTERRUPTIBLE);
> + schedule_timeout(HZ / 100);
> + if (signal_pending(tsk))
> + break;
You specifically allow SIGKILL, but then sleep uninterruptibly? And
then you check if signal_pending() :) I think you may want
TASK_INTERRUPTIBLE? Or, go one better and use msleep_interruptible(),
as I don't see any wait-queues in the immediate area of this code...
> + set_task_state(tsk, TASK_INTERRUPTIBLE);
> + schedule_timeout(HZ / 100);
> + }
> +
> + if (signal_pending(tsk))
> + break;
Then you use INTERRUPTIBLE and check signal_pending() again, so I'm
pretty sure you wanted INTERRUPTIBLE above...But this sleep can be
msleep_interruptible(), as well?
> diff --git a/drivers/misc/ucb1x00-core.c b/drivers/misc/ucb1x00-core.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/misc/ucb1x00-core.c
> +/**
> + * ucb1x00_adc_read - read the specified ADC channel
> + * @ucb: UCB1x00 structure describing chip
> + * @adc_channel: ADC channel mask
> + * @sync: wait for syncronisation pulse.
> + *
> + * Start an ADC conversion and wait for the result. Note that
> + * synchronised ADC conversions (via the ADCSYNC pin) must wait
> + * until the trigger is asserted and the conversion is finished.
> + *
> + * This function currently spins waiting for the conversion to
> + * complete (2 frames max without sync).
You technically sleep (schedule_timeout()), not spin...
> + *
> + * If called for a synchronised ADC conversion, it may sleep
> + * with the ADC semaphore held.
> + */
> +unsigned int ucb1x00_adc_read(struct ucb1x00 *ucb, int adc_channel, int sync)
> +{
> + unsigned int val;
> +
> + if (sync)
> + adc_channel |= UCB_ADC_SYNC_ENA;
> +
> + ucb1x00_reg_write(ucb, UCB_ADC_CR, ucb->adc_cr | adc_channel);
> + ucb1x00_reg_write(ucb, UCB_ADC_CR, ucb->adc_cr | adc_channel |
> UCB_ADC_START);
> +
> + for (;;) {
> + val = ucb1x00_reg_read(ucb, UCB_ADC_DATA);
> + if (val & UCB_ADC_DAT_VAL)
> + break;
> + /* yield to other processes */
> + set_current_state(TASK_INTERRUPTIBLE);
> + schedule_timeout(1);
> + }
If I ever add a poll_event() interface to the kernel, this would be a
good user. You don't check if signal_pending(), though, even though
you are in INTERRUPTIBLE state... Maybe this case can use
UNINTERRUPTIBLE?
Thanks,
Nish
-
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] serverworks should not take ahold of megaraid'd controllers
On Iau, 2005-07-21 at 15:37 -0700, Darrick J. Wong wrote: > I've noticed what might be a small bug with the serverworks driver in > 2.6.12.3. The IBM HS20 blade has a ServerWorks CSB6 IDE controller with > an optional LSI MegaIDE RAID BIOS (BIOS assisted software raid, iow). With a binary only proprietary driver. > (ServerWorks) to IBM. However, the serverworks driver doesn't notice > this and will attach to the controller anyway, thus allowing raw access > to the disks in the RAID. An unsuspecting user can then read and write > whatever they want to the drive, which could very well degrade or > destroy the array, which is clearly not desirable behavior. It may be appropriate for some vendor situations but it isn't appropriate for the base kernel to default to assuming the user wants to use binary only drivers instead of dmraid. Especially as the raid formats for this hardware are partially known despite no assistance I know of from the vendor. Alan - 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 page size explanation
Gaspar Bakos wrote: Hi, Sorry for this nursery-school question. Could someone briefly explain me : 1. what is the kernel page size (any _useful_ pointer on the web is fine), 2. how can one tune it (for 2.6.*)? 3. what kind of effect does it have on system performance, if it is tuneable, and if it worth changing this at all? This is dependent on the hardware, not really the OS. On x86 the normally used page size is 4KB. 4MB pages are also supported but are usually used only for special purposes (ex: hugetlbfs). As you mentioned some other architectures like Itanium support different page sizes. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.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: 2.6.13-rc3-mm1 (ckrm)
Matthew wrote: > I don't see the large ifdefs you're referring to in -mm's > kernel/sched.c. Perhaps someone who knows CKRM better than I can explain why the CKRM version in some SuSE releases based on 2.6.5 kernels has substantial code and some large ifdef's in sched.c, but the CKRM in *-mm doesn't. Or perhaps I'm confused. There's a good chance that this represents ongoing improvements that CKRM is making to reduce their footprint in core kernel code. Or perhaps there is a more sophisticated cpu controller in the SuSE kernel. > Have you looked at more > recent benchmarks posted on CKRM-Tech around April 15th 2005? > ... > http://ckrm.sourceforge.net/downloads/ckrm-ols04-slides.pdf I had not seen these before. Thanks for the pointer. > The Rule-Based Classification Engine (RBCE) makes CKRM useful > without middleware. I'd be encouraged more if this went one step further, past pointing out that the API can be manipulated from the shell without requiring C code, to providing examples of who intends to _directly_ use this interface. The issue is perhaps less whether it's API is naturally C or shell code, or more of how many actual, independent, uses of this API are known to the community. A non-trivial API and mechanism that is de facto captive to a single middleware implementation (which may or may not apply here - I don't know) creates an additional review burden, because some of the natural forces that guide us to healthy long lasting interfaces are missing. If that concern applies here, it's certainly not insurmountable - but it should in my view raise the review barrier to acceptance. If other middleware or direct users are not essentially performing some of the review for us, we have to do it here with greater thoroughness. > If you could be more specific I'd be able to > respond in less general and abstract terms. Good come back . I made an effort along these lines last year, in the thread I referenced a few days ago: Classes: 1) what are they, 2) what is their name? http://sourceforge.net/mailarchive/forum.php?thread_id=5328162_id=35191 I doubt that it I have much more to contribute along these lines now. Sorry. > I haven't seen this limitation [128 cpus] ... Good - I presume that there is no longer, if there ever was, such a limitation. Thanks for you reply. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 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/
kernel page size explanation
Hi, Sorry for this nursery-school question. Could someone briefly explain me : 1. what is the kernel page size (any _useful_ pointer on the web is fine), 2. how can one tune it (for 2.6.*)? 3. what kind of effect does it have on system performance, if it is tuneable, and if it worth changing this at all? I am a bit confused; at one place i see someone saying that the kernel page size is 4kb for i386. At another place I see a statement: "I tried all four possible page sizes on Itanium (4k, 8k, 16k and 64k)" How can i figure out the page size of the kernel i am currently using? Cheers Gaspar - 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: CIFS slowness & crashes
On 21 Jul 2005 17:35:12 -0500, Steve French <[EMAIL PROTECTED]> wrote: > Yes. CCing those lists is recommended. The best list to send to is and > which I and others in this area monitor regularly though is > [EMAIL PROTECTED] If that's the best list to send to, then I suggest it be added to the CIFS MAINTAINERS entry as pr the patch below (also attached since gmail will probably mangle it). Add [EMAIL PROTECTED] to CIFS entry in MAINTAINERS Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- MAINTAINERS |1 + 1 files changed, 1 insertion(+) --- linux-2.6.13-rc3-orig/MAINTAINERS 2005-07-14 20:33:32.0 +0200 +++ linux-2.6.13-rc3/MAINTAINERS2005-07-22 01:42:09.0 +0200 @@ -532,6 +532,7 @@ COMMON INTERNET FILE SYSTEM (CIFS) P: Steve French M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] L: samba-technical@lists.samba.org W: http://us1.samba.org/samba/Linux_CIFS_client.html S: Supported -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html From: Jesper Juhl <[EMAIL PROTECTED]> Add [EMAIL PROTECTED] to CIFS entry in MAINTAINERS Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- linux-2.6.13-rc3-orig/MAINTAINERS 2005-07-14 20:33:32.0 +0200 +++ linux-2.6.13-rc3/MAINTAINERS 2005-07-22 01:42:09.0 +0200 @@ -532,6 +532,7 @@ COMMON INTERNET FILE SYSTEM (CIFS) P: Steve French M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] L: samba-technical@lists.samba.org W: http://us1.samba.org/samba/Linux_CIFS_client.html S: Supported
Re: [Clusters_sig] RE: [Linux-cluster] Re: [Ocfs2-devel] [RFC] nodemanager, ocfs2, dlm
On 2005-07-20T11:39:38, Joel Becker <[EMAIL PROTECTED]> wrote: > In turn, let me clarify a little where configfs fits in to > things. Configfs is merely a convenient and transparent method to > communicate configuration to kernel objects. It's not a place for > uevents, for netlink sockets, or for fancy communication. It allows > userspace to create an in-kernel object and set/get values on that > object. It also allows userspace and kernelspace to share the same > representation of that object and its values. > For more complex interaction, sysfs and procfs are often more > appropriate. While you might "configure" all known nodes in configfs, > the node up/down state might live in sysfs. A netlink socket for > up/down events might live in procfs. And so on. Right. Thanks for the clarification and elaboration, for I am sure not entirely clear as to how all these mechanisms relate in detail and what is appropriate just where, and when to use something more classic like ioctl etc... ;-) FWIW, we didn't mean to get uevents out via configfs of course. Sincerely, Lars Marowsky-Brée <[EMAIL PROTECTED]> -- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin "Ignorance more frequently begets confidence than does knowledge" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm1 - breaks DRI
> >> > >> I also use 2.6.13-rc3-mm1. Will try with a previous version an report to > >> lkml if > >> it works. > >> > > > > I just tried 13-rc2-mm1 and dri is working again. Its reported to also work > > with 13-rc3. > Hmm no idea what could have broken it, I'm at OLS and don't have any DRI capable machine here yet.. so it'll be a while before I get to take a look at it .. I wouldn't be terribly surprised if some of the new mapping code might have some issues.. 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/
sis190 driver
No major change from previous version. I'm quietly merging bits from the SiS driver that Lars kindly pointed out. The detection of the mac address is done differently. I'll welcome feedback related to regressions and/or netconsole testing. Single file patch: http://www.zoreil.com/~romieu/sis190/20050722-2.6.13-rc2-sis190-test.patch Patch-kit: http://www.zoreil.com/~romieu/sis190/20050722-2.6.13-rc2/patches Tarball: http://www.zoreil.com/~romieu/sis190/20050722-2.6.13-rc2.tar.bz2 -- Ueimor - 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] serverworks should not take ahold of megaraid'd controllers
On Thu, 2005-07-21 at 15:37 -0700, Darrick J. Wong wrote: > Hi all, > > I've noticed what might be a small bug with the serverworks driver in > 2.6.12.3. The IBM HS20 blade has a ServerWorks CSB6 IDE controller with > an optional LSI MegaIDE RAID BIOS (BIOS assisted software raid, iow). > When this megaide BIOS is enabled on the HS20, the PCI > subvendor/subdevice IDs on the CSB6 are changed from the default > (ServerWorks) to IBM. However, the serverworks driver doesn't notice > this and will attach to the controller anyway, thus allowing raw access > to the disks in the RAID. An unsuspecting user can then read and write > whatever they want to the drive, which could very well degrade or > destroy the array, which is clearly not desirable behavior. actually this is the RIGHT behavior. This way dmraid can address the raid format and make the thing work. Your patch will break it. That is a very bad idea. So this is a NAK on your patch. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CIFS slowness & crashes
> > 2. Occassionally the transmission speeds go extremely low for no > > apparent reason. While writing this, I am getting 0.39 Mo/s over a > > gigabit network. It would help to know whether you are doing mostly writing to or reading from the server. Forgot to mention that another thing that may help (besides the large number of improvements that already went into 2.6.12 already to drastically reduce the expensive large buffer usage, and the even newer experimental CIFS write code) are two configuration changes - either dropping the buffer size to relieve pressure on the slab (e.g. to just under 8K - perhaps 7800 bytes) or increasing the number of large buffers in the pool (they are insmod parms of cifs.ko - you can do modinfo on cifs.ko to see them) so fewer allocations are done. This would only be needed if multiple processes were accessing the mount at one 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: 2.6.13-rc3-mm1 (ckrm)
On Sun, 2005-07-17 at 08:20 -0700, Paul Jackson wrote: > It is somewhat intrusive in the areas it controls, such as some large > ifdef's in kernel/sched.c. I don't see the large ifdefs you're referring to in -mm's kernel/sched.c. > The sched hooks may well impact the cost of maintaining the sched code, > which is always a hotbed of Linux kernel development. However others > who work in that area will have to speak to that concern. I don't see the hooks you're referring to in the -mm scheduler. > I tried just now to read through the ckrm hooks in fork, to see > what sort of impact they might have on scalability on large systems. > But I gave up after a couple layers of indirection. I saw several > atomic counters and a couple of spinlocks that I suspect (not at all > sure) lay on the fork main code path. I'd be surprised if this didn't > impact scalability. Earlier, according to my notes, I saw mention of > lmbench results in the OLS 2004 slides, indicating a several percent > cost of available cpu cycles. The OLS2004 slides are roughly 1 year old. Have you looked at more recent benchmarks posted on CKRM-Tech around April 15th 2005? They should be available in the CKRM-Tech archives on SourceForge at http://sourceforge.net/mailarchive/forum.php?thread_id=7025751_id=35191 (OLS 2004 Slide 24 of http://ckrm.sourceforge.net/downloads/ckrm-ols04-slides.pdf ) The OLS slide indicates that the overhead is generally less than 0.5usec compared to a total context switch time of anywhere from 2 to 5.5usec. There appears to be little difference in scalability since the overhead appears to oscillate around a constant. > vendor has a serious middleware software product that provides full > CKRM support. Acceptance of CKRM would be easier if multiple competing > middleware vendors were using it. It is also a concern that CKRM > is not really usable for its primary intended purpose except if it > is accompanied by this corresponding middleware, which I presume is The Rule-Based Classification Engine (RBCE) makes CKRM useful without middleware. It uses a table of rules to classify tasks. For example rules that would classify shells: echo 'path=/bin/bash,class=/rcfs/taskclass/shells' > /rcfs/ce/rules/classify_bash_shells echo 'path=/bin/tcsh,class=/rcfs/taskclass/shells' > /rcfs/ce/rules/classify_tcsh_shells .. And class shares would control the fork rate of those shells: echo 'res=numtasks,forkrate=1,forkrate_interval=1' > '/rcfs/taskclass/config' echo 'res=numtasks,guarantee=1000,limit=5000' > '/rcfs/taskclass/shells' No middleware necessary. > CKRM is in part a generalization and descendent of what I call fair > share schedulers. For example, the fork hooks for CKRM include a > forkrates controller, to slow down the rate of forking of tasks using > too much resources. > > No doubt the CKRM experts are already familiar with these, but for > the possible benefit of other readers: > > UNICOS Resource Administration - Chapter 4. Fair-share Scheduler > > http://oscinfo.osc.edu:8080/dynaweb/all/004-2302-001/@Generic__BookTextView/22883 > > SHARE II -- A User Administration and Resource Control System for UNIX > http://www.c-side.com/c/papers/lisa-91.html > > Solaris Resource Manager White Paper > http://wwws.sun.com/software/resourcemgr/wp-mixed/ > > ON THE PERFORMANCE IMPACT OF FAIR SHARE SCHEDULING > http://www.cs.umb.edu/~eb/goalmode/cmg2000final.htm > > A Fair Share Scheduler, J. Kay and P. Lauder > Communications of the ACM, January 1988, Volume 31, Number 1, pp 44-55. > > The documentation that I've noticed (likely I've missed something) > doesn't do an adequate job of making the case - providing the > motivation and context essential to understanding this patch set. The choice of algorithm is entirely up to the scheduler, memory allocator, etc. CKRM currently provides an interface for reading share values and does not impose any meaning on those shares -- that is the role of the scheduler. > Because CKRM provides an infrastructure for multiple controllers > (limiting forks, memory allocation and network rates) and multiple > classifiers and policies, its critical interfaces have rather > generic and abstract names. This makes it difficult for others to > approach CKRM, reducing the rate of peer review by other Linux kernel > developers, which is perhaps the key impediment to acceptance of CKRM. > If anything, CKRM tends to be a little too abstract. Generic and abstract names are appropriate for infrastructure that is not tied to hardware. If you could be more specific I'd be able to respond in less general and abstract terms. > My notes from many months ago indicate something about a 128 CPU > limit in CKRM. I don't know why, nor if it still applies. It is > certainly a smaller limit than the systems I care about. I haven't seen this limitation in the CKRM patches that went into -mm and I'd like to look into
Re: 2.6.13-rc3-mm1 - breaks DRI
On Thursday 21 July 2005 11:56, Andrew Morton wrote: > Ed Tomlinson <[EMAIL PROTECTED]> wrote: > > > >> -- Forwarded Message -- > >> > >> Subject: Re: Xorg and RADEON (dri disabled) > >> Date: Wednesday 20 July 2005 21:25 > >> From: Ed Tomlinson <[EMAIL PROTECTED]> > >> To: debian-amd64@lists.debian.org > >> Cc: Michal Schmidt <[EMAIL PROTECTED]> > >> > >> On Wednesday 20 July 2005 21:13, Michal Schmidt wrote: > >> > Ed Tomlinson wrote: > >> > > Hi, > >> > > > >> > > With Xorg I get: > >> > > > >> > > (==) RADEON(0): Write-combining range (0xd000,0x800) > >> > > drmOpenDevice: node name is /dev/dri/card0 > >> > > drmOpenDevice: open result is -1, (No such device) > >> > > drmOpenDevice: open result is -1, (No such device) > >> > > drmOpenDevice: Open failed > >> > > drmOpenDevice: node name is /dev/dri/card0 > >> > > drmOpenDevice: open result is -1, (No such device) > >> > > drmOpenDevice: open result is -1, (No such device) > >> > > drmOpenDevice: Open failed > >> > > drmOpenByBusid: Searching for BusID pci::01:00.0 > >> > > drmOpenDevice: node name is /dev/dri/card0 > >> > > drmOpenDevice: open result is 7, (OK) > >> > > drmOpenByBusid: drmOpenMinor returns 7 > >> > > drmOpenByBusid: drmGetBusid reports pci::01:00.0 > >> > > (II) RADEON(0): [drm] loaded kernel module for "radeon" driver > >> > > (II) RADEON(0): [drm] DRM interface version 1.2 > >> > > (II) RADEON(0): [drm] created "radeon" driver at busid > >> > > "pci::01:00.0" > >> > > (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc2411000 > >> > > (II) RADEON(0): [drm] drmMap failed > >> > > (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. > >> > > > >> > > And glxgears reports 300 frames per second. How do I get dri back? It > >> > > was working fine with XFree. The XF86Config-4 was changed by the > >> > > upgrade > >> > > dropping some parms in the Device section. Restoring them has no > >> > > effect > >> > > on the problem. > >> > >> > What kernel do you use? I get the same behaviour with 2.6.13-rc3-mm1, > >> > but it works with 2.6.13-rc3. > >> > >> I also use 2.6.13-rc3-mm1. Will try with a previous version an report to > >> lkml if > >> it works. > >> > > > > I just tried 13-rc2-mm1 and dri is working again. Its reported to also work > > with 13-rc3. > > Useful info, thanks. > > > What in mm1 is apt to be breaking dri? > > Faulty kernel programming ;) > > I assume that the failure to open /dev/dri/card0 only happens in rc3-mm1? The difference in the X logs is that the working one does not have the: (II) RADEON(0): [drm] created "radeon" driver at busid "pci::01:00.0" (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc2411000 (II) RADEON(0): [drm] drmMap failed message. When it works it has has: (II) RADEON(0): [drm] created "radeon" driver at busid "pci::01:00.0" (II) RADEON(0): [drm] added 8192 byte SAREA at 0x10001000 (II) RADEON(0): [drm] mapped SAREA 0x10001000 to 0x2aaab2e67000 (II) RADEON(0): [drm] framebuffer handle = 0xd000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): [agp] Mode 0x1f004209 [AGP 0x10de/0x00e1; Card 0x1002/0x5961] (II) RADEON(0): [agp] 8192 kB allocated with handle 0x0001 (II) RADEON(0): [agp] ring handle = 0xe000 > Could you compare the dmesg output for 2.6.13-rc3 versus 2.6.13-rc3-mm1? > And double-check the .config settings: occasionally config options will be > renamed and `make oldconfig' causes things to get acidentally disabled. >From 13-rc2-mm1: Jul 21 07:31:20 grover kernel: [ 13.652465] Linux agpgart interface v0.101 (c) Dave Jones Jul 21 07:31:20 grover kernel: [ 13.652492] [drm] Initialized drm 1.0.0 20040925 and later Jul 21 07:31:34 grover kernel: [ 72.401795] [drm] Initialized radeon 1.16.0 20050311 on minor 0: ATI Technologies Inc RV280 [Radeon 9200] Jul 21 07:31:34 grover kernel: [ 72.402388] agpgart: Found an AGP 3.0 compliant device at :00:00.0. Jul 21 07:31:34 grover kernel: [ 72.402399] agpgart: Putting AGP V3 device at :00:00.0 into 4x mode Jul 21 07:31:34 grover kernel: [ 72.402419] agpgart: Putting AGP V3 device at :01:00.0 into 4x mode Jul 21 07:31:35 grover kernel: [ 72.421888] [drm] Loading R200 Microcode >From 13-rc3-mm1: Jul 20 18:59:34 grover kernel: [ 13.837537] Linux agpgart interface v0.101 (c) Dave Jones Jul 20 18:59:34 grover kernel: [ 13.837565] [drm] Initialized drm 1.0.0 20040925 and later Jul 20 18:59:48 grover kernel: [ 71.638470] [drm] Initialized radeon 1.16.0 20050311 on minor 0: ATI Techno logies Inc RV280 [Radeon 9200] Both .configs are fine. Kernels have agp compiled in with DRM modular. CONFIG_GART_IOMMU=y CONFIG_AGP=y CONFIG_AGP_AMD64=y # CONFIG_AGP_INTEL is not set CONFIG_DRM=y CONFIG_DRM_TDFX=m CONFIG_DRM_R128=m CONFIG_DRM_RADEON=m Hope this helps (Its an AMD64 Kernel), Ed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
Support for Silicon Image 3132 SATA II Controller
Hello, I've got a new Silicon Image 3132 SATA II host-controller, this one is designed along the SATA (II) specification - (Hot-Plug,NCQ,3GB/s transfer). This controller is linked to the pci-express bus. I guess it operate like the 3124 controller with some addition :-) On the Silicon Image website I found some papers for this controller and his architecture. It can be found here http://www.siliconimage.com/products/product.aspx?id=32=1 I can provide a pci-ids for some specific boards if needed...I found this controller on some new motherboards Gigabyte's 955X Royal, ABIT AW8,ECS PF88 Extreme, TUL,Foxconn and maybe others coming. Is it possible to implement this controller to libata: sata_sil driver? I also would spend some time to test the driver. Thanks for help and assistence Greets -- Mit freundlichen Grüßen Michael Thonke Best regards Michael Thonke - 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: CIFS slowness & crashes
On Thu, 2005-07-21 at 17:04, Jesper Juhl wrote: > On 7/21/05, Lasse Kärkkäinen / Tronic <[EMAIL PROTECTED]> wrote: > > I mailed [EMAIL PROTECTED] (the guy who wrote the driver) about this a > > month ago, but didn't get any reply. Is anyone working on that driver > > anymore? > > > As far as I know Steve is still maintaining cifs. If you wrote him and > didn't get a response, then try again after a while (you might have > included him on CC for this mail) - maintainers don't always have time > to answer all mail in a timely fashion (or at all), and it's your > responsability to resend - that's not news. CIFS is still being actively improved/maintained. I was out on vacation for over a week. It might have gotten missed in the flood of email I had to catch up on. I am still maintaining cifs and evaluating patches from others as well. As you can see from the web git page, changesets are still being added. You can see the list of CIFS changesets (most recent first) by the query: http://www.kernel.org/git/?p=linux%2Fkernel%2Fgit%2Fsfrench%2Fcifs-2.6.git=search=CIFS > You could also have written to the samba-technical@lists.samba.org > mailinglist (or copied it - it's listed in MAINTAINERS under "COMMON > INTERNET FILE SYSTEM (CIFS)"). > > [adding Stephen French to CC] > > Personally I'd probably have send the mail > To: Steve French <[EMAIL PROTECTED]> > Cc: samba-technical@lists.samba.org > Cc: linux-kernel@vger.kernel.org Yes. CCing those lists is recommended. The best list to send to is and which I and others in this area monitor regularly though is [EMAIL PROTECTED] > > not possible to umount with either smbumount (hangs) smbumount can not be called on cifs vfs mounts (it is for the older smbfs). Although there is a somewhat similar umount.cifs utility (umount.cifs.c in the samba 3 source) it will be obsolete when more general user umounting (of their own mounts) is permitted in the kernel vfs itself. > nor umount -f > > (prints errors but doesn't umount anything). What are the errors? What is the version of cifs.ko module? > It won't recover without > > reboot, even if the server becomes back online. > > > > This problem has been around as long as I have used SMBFS or CIFS. There > > has only been slight variation from one version to another. Sometimes it > > is possible to umount them (after some pretty long timeout), sometimes > > it is not. It seems as if the problem was being fixed, but none of the > > fixes really worked. My tests of reconnection after server crash or network reconnection with smbfs works (for the past year or two) and also of course for cifs. cifs also reconnects state (open files) not just the connection to \\server\share > > > > 2. Occassionally the transmission speeds go extremely low for no > > apparent reason. While writing this, I am getting 0.39 Mo/s over a > > gigabit network. My informal tests (cifs->samba) showed a maximum of about 20% utilization of gigabit doing large file writes and about double that for large file reads with a single cifs client to Samba over gigabit. Should be somewhat simalar to Windows server. The most common cause of widely varying speeds are the following: 1) memory fragmentation - some versions of the kernel badly fragment slab allocations greater than 4 pages (cifs by default allocates 16.5K buffers - which results in larger size allocations when more than 5 processes are accessing the mount and the cifs buffer pool is exceeded) 2) write behind due to oplock - smbfs does not do oplock, cifs does - which means that cifs client caching can cause a large amount of writebehind data to accumulate (with great performance for a while) - then when memory gets tight due to the inode caching in linux's mm layer, the cifs client is asked to write out a large amount of file data at one time (which it does synchronously). Both of these are being improved. You can bypass the inode caching on the client by using the cifs mount option "forcedirectio" > Using FTP to read the same file gives 40 Mo/s, Similarly NFS was somewhat better than that (as long as the file was in memory already on the server). - 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] serverworks should not take ahold of megaraid'd controllers
Hi all,
I've noticed what might be a small bug with the serverworks driver in
2.6.12.3. The IBM HS20 blade has a ServerWorks CSB6 IDE controller with
an optional LSI MegaIDE RAID BIOS (BIOS assisted software raid, iow).
When this megaide BIOS is enabled on the HS20, the PCI
subvendor/subdevice IDs on the CSB6 are changed from the default
(ServerWorks) to IBM. However, the serverworks driver doesn't notice
this and will attach to the controller anyway, thus allowing raw access
to the disks in the RAID. An unsuspecting user can then read and write
whatever they want to the drive, which could very well degrade or
destroy the array, which is clearly not desirable behavior.
The attached patch against 2.6.12.3 makes the serverworks driver ignore
a megaraided CSB6. If desired, I can respin this patch with a debugging
knob to force the serverworks driver to use the old behavior. This
patch has been tested on the HS20 mentioned above, and I haven't seen
any problems with it.
Please let me know what you think of this patch; I'm not cc'd on lkml or
linux-ide.
--Darrick
diff -Naur linux-2.6.12.3_0/drivers/ide/pci/serverworks.c linux-2.6.12.3_1/drivers/ide/pci/serverworks.c
--- linux-2.6.12.3_0/drivers/ide/pci/serverworks.c 2005-07-15 14:18:57.0 -0700
+++ linux-2.6.12.3_1/drivers/ide/pci/serverworks.c 2005-07-21 13:02:54.469552989 -0700
@@ -645,6 +647,15 @@
{
ide_pci_device_t *d = _chipsets[id->driver_data];
+ /* Refuse to acknowledge CSB6 in MegaRAID mode on IBM HS20/40 blade. */
+ if ( dev->subsystem_vendor == PCI_VENDOR_ID_IBM &&
+ dev->subsystem_device == PCI_DEVICE_ID_SERVERWORKS_CSB6IDE)
+ {
+ printk(KERN_INFO "svwks: MegaRAID detected; ignoring.\n");
+ return -ENODEV;
+ }
+
+
return d->init_setup(dev, d);
}
signature.asc
Description: OpenPGP digital signature
strange boot problem since 2.6.12
The problem is simple and I have it since 2.6.12 final (tested on 2.6.12, 2.6.12.2, 2.6.13-rc3). After grub stage2 (kernel image loaded) the system freeze and I can only hit the three-finger-salute (ctrl+alt+del). The system is: Asus A8V Deluxe bios 1014.007 (tested with 1014.001 and 1013) AMD Athlon 64 3800+ running in 32bit mode 2 GB of DDR PC3200 nVIDIA GF FX 5600XT 256Mb 3 HD (1 ATA and 2 SATA) etc etc and it's running mail, web, ldap, ftp and NX services Here's some info: cmdline -> http://lxnay.no-ip.org/kernel/bug-report/cmdline cpuinfo -> http://lxnay.no-ip.org/kernel/bug-report/cpuinfo lspci -> http://lxnay.no-ip.org/kernel/bug-report/lspci grub configuration -> http://lxnay.no-ip.org/kernel/bug-report/grub lsusb -> http://lxnay.no-ip.org/kernel/bug-report/lsusb kernel config (for 2.6.12 and 2.6.13-rc - make oldconfig) -> http://lxnay.no-ip.org/kernel/bug-report/config Error image -> http://lxnay.no-ip.org/kernel/bug-report/boot.jpg (thanks to kdebluetooth and nokia 6600 :-) ) Yes, I'm running 2.6.12, in fact, after hours of recompilations I was able to generate a running kernel (based on 2.6.12.2)... Every 2.6.11 works fine, this is the only one working 2.6.12 and I don't know why it works... Unfortunately, I can't give any more information since the error appears in an early stage... :( -- Fabio Erculiani lxnay [EMAIL PROTECTED] - [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] Add disk hotswap support to libata
Michael Tokarev wrote: echo -n 1 > /sys/.../hostA/targetA:B:C/A:B:C:D/delete still works. I think. And (again, I think) this same problem exists with 2.6.11 as well. At least, I wasn't able to remove-single-device even once (I discovered this mechanism only recently, haven't tried it with other kernels). You're both correct and incorrect based on my testing; in 2.6.11.12, I have no problems. However, in 2.6.13-rc1-mm1, you're right that echoing 1 into the delete node does remove the device. It seems that there is some issue with the 'scsi_device_lookup' function then? I'd have to debug further. Luke Kosewski Human Cannonball Net Integration Technologies - 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/
[-mm patch] fs/asfs/: make code static
This patch makes needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
fs/asfs/asfs_fs.h | 12
fs/asfs/extents.c |4 +++-
fs/asfs/inode.c | 29 ++---
fs/asfs/objects.c |4 +++-
fs/asfs/super.c | 18 +-
5 files changed, 41 insertions(+), 26 deletions(-)
--- linux-2.6.13-rc3-mm1-full/fs/asfs/extents.c.old 2005-07-21
23:04:26.0 +0200
+++ linux-2.6.13-rc3-mm1-full/fs/asfs/extents.c 2005-07-21 23:04:45.0
+0200
@@ -271,7 +271,9 @@
/* Returns created extentbnode - returned_bh need to saved and realesed in
caller funkction! */
-int createextentbnode(struct super_block *sb, u32 key, struct buffer_head
**returned_bh, struct BNode **returned_bnode)
+static int createextentbnode(struct super_block *sb, u32 key,
+struct buffer_head **returned_bh,
+struct BNode **returned_bnode)
{
int errorcode;
--- linux-2.6.13-rc3-mm1-full/fs/asfs/asfs_fs.h.old 2005-07-21
23:06:11.0 +0200
+++ linux-2.6.13-rc3-mm1-full/fs/asfs/asfs_fs.h 2005-07-21 23:10:22.0
+0200
@@ -174,13 +174,6 @@
/* inode.c */
struct inode *asfs_get_root_inode(struct super_block *sb);
void asfs_read_locked_inode(struct inode *inode, void *arg);
-int asfs_create(struct inode *dir, struct dentry *dentry, int mode, struct
nameidata *nd);
-int asfs_mkdir(struct inode *dir, struct dentry *dentry, int mode);
-int asfs_symlink(struct inode *dir, struct dentry *dentry, const char
*symname);
-int asfs_rmdir(struct inode *dir, struct dentry *dentry);
-int asfs_unlink(struct inode *dir, struct dentry *dentry);
-int asfs_rename(struct inode *old_dir, struct dentry *old_dentry,
- struct inode *new_dir, struct dentry *new_dentry);
int asfs_notify_change(struct dentry *dentry, struct iattr *attr);
/* namei */
@@ -221,11 +214,6 @@
/* super.c */
struct super_block *asfs_read_super(struct super_block *sb, void *data,
int silent);
-void asfs_put_super(struct super_block *sb);
-int asfs_statfs(struct super_block *sb, struct kstatfs *buf);
-int asfs_remount(struct super_block *sb, int *flags, char *data);
-struct inode *asfs_alloc_inode(struct super_block *sb);
-void asfs_destroy_inode(struct inode *inode);
/* symlink.c */
int asfs_symlink_readpage(struct file *file, struct page *page);
--- linux-2.6.13-rc3-mm1-full/fs/asfs/inode.c.old 2005-07-21
23:05:25.0 +0200
+++ linux-2.6.13-rc3-mm1-full/fs/asfs/inode.c 2005-07-21 23:22:36.0
+0200
@@ -26,6 +26,18 @@
#include
+#ifdef CONFIG_ASFS_RW
+static int asfs_create(struct inode *dir, struct dentry *dentry,
+ int mode, struct nameidata *nd);
+static int asfs_mkdir(struct inode *dir, struct dentry *dentry, int mode);
+static int asfs_symlink(struct inode *dir, struct dentry *dentry,
+ const char *symname);
+static int asfs_unlink(struct inode *dir, struct dentry *dentry);
+static int asfs_rmdir(struct inode *dir, struct dentry *dentry);
+static int asfs_rename(struct inode *old_dir, struct dentry *old_dentry,
+ struct inode *new_dir, struct dentry *new_dentry);
+#endif /* CONFIG_ASFS_RW */
+
/* Mapping from our types to the kernel */
static struct address_space_operations asfs_aops = {
@@ -277,22 +289,24 @@
return error;
}
-int asfs_create(struct inode *dir, struct dentry *dentry, int mode, struct
nameidata *nd)
+static int asfs_create(struct inode *dir, struct dentry *dentry,
+ int mode, struct nameidata *nd)
{
return asfs_create_object(dir, dentry, mode, it_file, NULL);
}
-int asfs_mkdir(struct inode *dir, struct dentry *dentry, int mode)
+static int asfs_mkdir(struct inode *dir, struct dentry *dentry, int mode)
{
return asfs_create_object(dir, dentry, mode, it_dir, NULL);
}
-int asfs_symlink(struct inode *dir, struct dentry *dentry, const char *symname)
+static int asfs_symlink(struct inode *dir, struct dentry *dentry,
+ const char *symname)
{
return asfs_create_object(dir, dentry, 0, it_link, symname);
}
-int asfs_rmdir(struct inode *dir, struct dentry *dentry)
+static int asfs_rmdir(struct inode *dir, struct dentry *dentry)
{
asfs_debug("ASFS: %s\n", __FUNCTION__);
@@ -302,7 +316,7 @@
return asfs_unlink(dir, dentry);
}
-int asfs_unlink(struct inode *dir, struct dentry *dentry)
+static int asfs_unlink(struct inode *dir, struct dentry *dentry)
{
struct inode *inode = dentry->d_inode;
int error;
@@ -341,7 +355,8 @@
return 0;
}
-int asfs_rename(struct inode *old_dir, struct dentry *old_dentry, struct inode
*new_dir, struct dentry *new_dentry)
+static int asfs_rename(struct inode *old_dir, struct dentry *old_dentry,
+ struct inode *new_dir, struct dentry *new_dentry)
{
struct super_block *sb
Re: CIFS slowness & crashes
On 7/21/05, Lasse Kärkkäinen / Tronic <[EMAIL PROTECTED]> wrote: > I mailed [EMAIL PROTECTED] (the guy who wrote the driver) about this a > month ago, but didn't get any reply. Is anyone working on that driver > anymore? > As far as I know Steve is still maintaining cifs. If you wrote him and didn't get a response, then try again after a while (you might have included him on CC for this mail) - maintainers don't always have time to answer all mail in a timely fashion (or at all), and it's your responsability to resend - that's not news. You could also have written to the samba-technical@lists.samba.org mailinglist (or copied it - it's listed in MAINTAINERS under "COMMON INTERNET FILE SYSTEM (CIFS)"). [adding Stephen French to CC] Personally I'd probably have send the mail To: Steve French <[EMAIL PROTECTED]> Cc: samba-technical@lists.samba.org Cc: linux-kernel@vger.kernel.org > The problems that I wrote him about were: > > 1. CIFS VFS hangs entirely if the server crashes or otherwise goes > offline. Every process touching the mount halts too and cannot be killed > (but they are not zombies). System loads start climbing and eventually > the entire system will die (after system loads reach about 500). It is > not possible to umount with either smbumount (hangs) nor umount -f > (prints errors but doesn't umount anything). It won't recover without > reboot, even if the server becomes back online. > > This problem has been around as long as I have used SMBFS or CIFS. There > has only been slight variation from one version to another. Sometimes it > is possible to umount them (after some pretty long timeout), sometimes > it is not. It seems as if the problem was being fixed, but none of the > fixes really worked. > > 2. Occassionally the transmission speeds go extremely low for no > apparent reason. While writing this, I am getting 0.39 Mo/s over a > gigabit network. Using FTP to read the same file gives 40 Mo/s, which is > the speed that the file can be read locally on the server too. > Remounting the CIFS does not help, nor does restarting Samba. However, > using SMBFS I can get 20 Mo/s which is a bit better but still far from > what it should be. It is important to mention that sometimes CIFS does > work faster (about as quickly as SMBFS) and that this misbehavior occurs > randomly. > > During CIFS transfer, both computers seem to be idling. The CPU usage > (including I/O wait) is almost none. During SMBFS transfer the server > smbd process uses about 15 % CPU and the client is almost idle. The > client is P4 3.4 GHz and the server is Athlon64 3000+. > > I also tested with a Windows XP client machine and found out that this > slowness issue does not happen with it, using the very same Samba server > that the Linux CIFS mount is using. > > - Tronic - > > - 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 0/3] Add disk hotswap support to libata
Lukasz Kosewski wrote: [] [1] The SCSI error on 2.6.13-rc3-mm1 that I found: 'echo "scsi add-single-device a b c d" > /proc/scsi/scsi' //works, or no-op if the sd corresponding to that device is there already 'echo "scsi remove-single-device a b c d" > /proc/scsi/scsi' //works 'echo "scsi add-single-device a b c d" > /proc/scsi/scsi' //works 'echo "scsi remove-single-device a b c d" > /proc/scsi/scsi' //FAILS echo -n 1 > /sys/.../hostA/targetA:B:C/A:B:C:D/delete still works. I think. And (again, I think) this same problem exists with 2.6.11 as well. At least, I wasn't able to remove-single-device even once (I discovered this mechanism only recently, haven't tried it with other kernels). As such, since the same underlying functions are called by hotplugging, you will only be able to remove a disk from a device once before it fails, until this error is fixed. I'll look into it as well. /mjt - 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: Supermount
>2005/7/21, Lasse Kärkkäinen / Tronic <[EMAIL PROTECTED]>: > Is there a reason why this magnificient piece of software is not already > in the mainline? It seems to be working very well and provides > functionality that simply isn't available otherwise. > Hi Tronic, Supermount is obsolete there are other tools in userspace that do the job perfectly. e.g ivman which uses hal and dbus. Including source like supermount because it simply work is not a good argument. And why to hell should everthing in the kernel, to make sorry *leazy* people happy? The kernel is not a trash...also supermount uses ioctl which is nearly removed from kernel?! Please correct me if i am wrong with ioctl. Also there are other fs like supermount e.g submount etc... > For those who are not familiar with it: this system does on-demand > mounting when the mount point is accessed and automatically umounts > afterwards. Unlike autofs, this does not require a special automount > filesystem to be mounted, but the actual filesystems can be directly > mounted where-ever. Also, it "just works" and the CD drive will eject > when the button is pressed, without having to wait for the umount > timeout to pass. I haven't looked inside to find out HOW it actually > does it, because I simply don't care, as long as it just works. I used supermount, too - for a long long time...but it cost me a second to write a bash script with does supermount job's for eject. ;-) > > - Tronic - > > > -- Mit freundlichen Grüßen Michael Thonke Best regards Michael thonke - 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: Supermount
Lasse K??rkk??inen / Tronic <[EMAIL PROTECTED]> : > Is there a reason why this magnificient piece of software is not already > in the mainline? Yes, there is. Please search the archives. -- Ueimor - 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 3/3] Add disk hotswap support to libata
This patch is an implementation of hotswap on the sata_promise module,
tested on SATA150 and SATAII150 Promise controllers. It depends on
patch 01 from this series of patches to apply, and both 01 and 02 in
order to compile.
We handle hotplug interrupts and call our new API functions in libata.
There is also one new part for the SATAII150 controllers and how they
handle a phy_reset, since they seem to want to re-spew their last
hotplug interrupt unless we mask and clear it.
I don't expect this to be too contentious either.
Luke Kosewski
Human Cannonball
Net Integration Technologies
Signed-off-by: Luke Kosewski <[EMAIL PROTECTED]>
21.07.05 Luke Kosewski <[EMAIL PROTECTED]>
* A full implementation of hotplug on a libata controller, this being
the Promise Tx4/Tx2 Plus controller line (both SATA150 and SATAII150).
Almost all of the code pertaining to how to talk to the hotplug
registers has been stolen from the pdc-ulsata2 and ultra-1.0.8 Promise
drivers. This involves detecting when we have an interrupt pending
and on what device, as well as the bit where a hard SATA reset gets
a SATAII150 controller to re-spew a plug interrupt.
* Note that the hotplug handling code comes AFTER the normal interrupt
handling code in pdc_interrupt_common; this is because we're much
more likely to receive normal interrupts, so this drops the AVERAGE
interrupt handling time down a lot.
Signed-off-by: Luke Kosewski <[EMAIL PROTECTED]>
--- linux-2.6.13-rc3/drivers/scsi/sata_promise.c.old2005-07-21
13:52:13.037895639 -0400
+++ linux-2.6.13-rc3/drivers/scsi/sata_promise.c2005-07-21
13:55:53.490964645 -0400
@@ -84,6 +84,7 @@ static void pdc_eng_timeout(struct ata_p
static int pdc_port_start(struct ata_port *ap);
static void pdc_port_stop(struct ata_port *ap);
static void pdc_phy_reset(struct ata_port *ap);
+static void pdc2_phy_reset(struct ata_port *ap);
static void pdc_pata_phy_reset(struct ata_port *ap);
static void pdc_pata_cbl_detect(struct ata_port *ap);
static void pdc_qc_prep(struct ata_queued_cmd *qc);
@@ -139,7 +140,7 @@ static struct ata_port_operations pdc2_a
.check_status = ata_check_status,
.exec_command = pdc_exec_command_mmio,
.dev_select = ata_std_dev_select,
- .phy_reset = pdc_phy_reset,
+ .phy_reset = pdc2_phy_reset,
.qc_prep= pdc_qc_prep,
.qc_issue = pdc_qc_issue_prot,
.eng_timeout= pdc_eng_timeout,
@@ -325,6 +326,48 @@ static void pdc_phy_reset(struct ata_por
pdc_pata_phy_reset(ap);
}
+/* Mask hotplug interrupts for one channel (ap) */
+static inline void pdc2_disable_channel_hotplug_interrupts(struct ata_port *ap)
+{
+ void *mmio = ap->host_set->mmio_base + PDC2_SATA_PLUG_CSR + 2;
+
+ u8 maskflags = readb(mmio);
+ maskflags |= (0x11 << (u8)ap->hard_port_no);
+ writeb(maskflags, mmio);
+}
+
+static inline void pdc2_enable_channel_hotplug_interrupts(struct ata_port *ap)
+{
+
+ void *mmio = ap->host_set->mmio_base + PDC2_SATA_PLUG_CSR;
+
+ //Clear channel hotplug interrupts
+ u8 maskflags = readb(mmio);
+ maskflags = (0x11 << (u8)ap->hard_port_no);
+ writeb(maskflags, mmio);
+
+ //Unmask channel hotplug interrupts
+ maskflags = readb(mmio + 2);
+ maskflags ^= (0x11 << (u8)ap->hard_port_no);
+ writeb(maskflags, mmio + 2);
+}
+
+static void pdc2_phy_reset(struct ata_port *ap)
+{
+ /* As observed on the Promise SATAII150 Tx2 Plus/Tx4, giving the
+* controller a hard reset triggers another hotplug interrupt. So
+* disable them for the hard reset, and re-enable afterwards.
+*
+* No PATA support here yet
+*/
+ if (ap->flags & ATA_FLAG_SATA_RESET && ap->flags & ATA_FLAG_SATA) {
+ pdc2_disable_channel_hotplug_interrupts(ap);
+ pdc_phy_reset(ap);
+ pdc2_enable_channel_hotplug_interrupts(ap);
+ } else
+ pdc_phy_reset(ap);
+}
+
static void pdc_pata_cbl_detect(struct ata_port *ap)
{
u8 tmp;
@@ -483,6 +526,7 @@ static inline unsigned int pdc_interrupt
struct ata_host_set *host_set = dev_instance;
struct ata_port *ap;
void *mmio_base;
+ u8 plugdata, maskflags;
u32 mask = 0;
unsigned int i, tmp, handled = 0;
unsigned long flags;
@@ -492,21 +536,18 @@ static inline unsigned int pdc_interrupt
}
mmio_base = host_set->mmio_base;
-
+
spin_lock_irqsave(_set->lock, flags);
/* reading should also clear interrupts */
mask = readl(mmio_base + PDC_INT_SEQMASK);
- if (mask == 0x) {
- VPRINTK("QUICK EXIT 2\n");
- goto done_irq;
- }
+ if (mask == 0x)
+
CIFS slowness & crashes
I mailed [EMAIL PROTECTED] (the guy who wrote the driver) about this a month ago, but didn't get any reply. Is anyone working on that driver anymore? The problems that I wrote him about were: 1. CIFS VFS hangs entirely if the server crashes or otherwise goes offline. Every process touching the mount halts too and cannot be killed (but they are not zombies). System loads start climbing and eventually the entire system will die (after system loads reach about 500). It is not possible to umount with either smbumount (hangs) nor umount -f (prints errors but doesn't umount anything). It won't recover without reboot, even if the server becomes back online. This problem has been around as long as I have used SMBFS or CIFS. There has only been slight variation from one version to another. Sometimes it is possible to umount them (after some pretty long timeout), sometimes it is not. It seems as if the problem was being fixed, but none of the fixes really worked. 2. Occassionally the transmission speeds go extremely low for no apparent reason. While writing this, I am getting 0.39 Mo/s over a gigabit network. Using FTP to read the same file gives 40 Mo/s, which is the speed that the file can be read locally on the server too. Remounting the CIFS does not help, nor does restarting Samba. However, using SMBFS I can get 20 Mo/s which is a bit better but still far from what it should be. It is important to mention that sometimes CIFS does work faster (about as quickly as SMBFS) and that this misbehavior occurs randomly. During CIFS transfer, both computers seem to be idling. The CPU usage (including I/O wait) is almost none. During SMBFS transfer the server smbd process uses about 15 % CPU and the client is almost idle. The client is P4 3.4 GHz and the server is Athlon64 3000+. I also tested with a Windows XP client machine and found out that this slowness issue does not happen with it, using the very same Samba server that the Linux CIFS mount is using. - Tronic - signature.asc Description: OpenPGP digital signature
[PATCH 1/3] Add disk hotswap support to libata
This patch changes the sata_promise driver in libata to correctly mask
out hotplug interrupts. The location of the primary hotplug registers
in the SATA150 Tx4/Tx2 Plus controllers is correctly defined as '0x6C',
HOWEVER, for the SATAII150 Tx4/Tx2 Plus controllers, this changes to
'0x60'. This patch rectifies us 'masking out interrupts' at the wrong
location, thus not masking them out at all.
Also, the promise interrupt handler uses a 'spin_lock', I have changed
it into a 'spin_lock_irqsave', since I observe this on most other libata
drivers, so for consistency.
I've also set up a new callback for handling SATAII150 interrupts, which
seemingly does nothing in this patch. Yes, it does nothing. Wait until
we get to patch 03, though.
I don't expect there to be too much contentious material in this patch.
Luke Kosewski
Human Cannonball
Net Integration Technologies
Signed-off-by: Luke Kosewski <[EMAIL PROTECTED]>
21.07.05 Luke Kosewski <[EMAIL PROTECTED]>
* A patch to the sata_promise driver in libata for it to correctly mask
out hotplug interrupts on SATAII150 Tx4/Tx2 Plus controllers. Also,
the 'spin_lock' in the interrupt handler has been changed to a
'spin_lock_irqsave' for consistency with other libata drivers.
Signed-off-by: Luke Kosewski <[EMAIL PROTECTED]>
--- linux-2.6.13-rc3/drivers/scsi/sata_promise.c.old2005-07-21
13:35:43.311486155 -0400
+++ linux-2.6.13-rc3/drivers/scsi/sata_promise.c2005-07-21
13:40:06.145261193 -0400
@@ -52,6 +52,7 @@ enum {
PDC_GLOBAL_CTL = 0x48, /* Global control/status (per port) */
PDC_CTLSTAT = 0x60, /* IDE control and status (per port) */
PDC_SATA_PLUG_CSR = 0x6C, /* SATA Plug control/status reg */
+ PDC2_SATA_PLUG_CSR = 0x60, /* SATAII Plug control/status reg */
PDC_SLEW_CTL= 0x470, /* slew rate control reg */
PDC_ERR_MASK= (1<<19) | (1<<20) | (1<<21) | (1<<22) |
@@ -60,8 +61,10 @@ enum {
board_2037x = 0,/* FastTrak S150 TX2plus */
board_20319 = 1,/* FastTrak S150 TX4 */
board_20619 = 2,/* FastTrak TX4000 */
+ board_2057x = 3,/* SATAII150 Tx2plus */
+ board_40518 = 4,/* SATAII150 Tx4 */
- PDC_HAS_PATA= (1 << 1), /* PDC20375 has PATA */
+ PDC_HAS_PATA= (1 << 1), /* PDC20375/20575 has PATA */
PDC_RESET = (1 << 11), /* HDMA reset */
};
@@ -76,6 +79,7 @@ static u32 pdc_sata_scr_read (struct ata
static void pdc_sata_scr_write (struct ata_port *ap, unsigned int sc_reg, u32
val);
static int pdc_ata_init_one (struct pci_dev *pdev, const struct pci_device_id
*ent);
static irqreturn_t pdc_interrupt (int irq, void *dev_instance, struct pt_regs
*regs);
+static irqreturn_t pdc2_interrupt (int irq, void *dev_instance, struct pt_regs
*regs);
static void pdc_eng_timeout(struct ata_port *ap);
static int pdc_port_start(struct ata_port *ap);
static void pdc_port_stop(struct ata_port *ap);
@@ -128,6 +132,26 @@ static struct ata_port_operations pdc_at
.host_stop = ata_host_stop,
};
+static struct ata_port_operations pdc2_ata_ops = {
+ .port_disable = ata_port_disable,
+ .tf_load= pdc_tf_load_mmio,
+ .tf_read= ata_tf_read,
+ .check_status = ata_check_status,
+ .exec_command = pdc_exec_command_mmio,
+ .dev_select = ata_std_dev_select,
+ .phy_reset = pdc_phy_reset,
+ .qc_prep= pdc_qc_prep,
+ .qc_issue = pdc_qc_issue_prot,
+ .eng_timeout= pdc_eng_timeout,
+ .irq_handler= pdc2_interrupt,
+ .irq_clear = pdc_irq_clear,
+ .scr_read = pdc_sata_scr_read,
+ .scr_write = pdc_sata_scr_write,
+ .port_start = pdc_port_start,
+ .port_stop = pdc_port_stop,
+ .host_stop = ata_host_stop,
+};
+
static struct ata_port_info pdc_port_info[] = {
/* board_2037x */
{
@@ -161,6 +185,28 @@ static struct ata_port_info pdc_port_inf
.udma_mask = 0x7f, /* udma0-6 ; FIXME */
.port_ops = _ata_ops,
},
+
+ /* board_2057x */
+ {
+ .sht= _ata_sht,
+ .host_flags = /* ATA_FLAG_SATA | */ ATA_FLAG_NO_LEGACY |
+ ATA_FLAG_SRST | ATA_FLAG_MMIO,
+ .pio_mask = 0x1f, /* pio0-4 */
+ .mwdma_mask = 0x07, /* mwdma0-2 */
+ .udma_mask = 0x7f, /* udma0-6 ; FIXME */
+ .port_ops = _ata_ops,
+ },
+
+ /* board_40518 */
+ {
+ .sht= _ata_sht,
+ .host_flags
[PATCH 2/3] Add disk hotswap support to libata
This patch is probably the most contentious one; adding a hotswap
framework to libata to allow it to handle disk plugs/unplugs.
The design goals for this framework were as follows:
- easy, stable API.
- simplicity of design and code
- as damn near as we can get to a guarantee that we will NOT panic the
kernel if the user does something stupid, an an attempt to guarantee
correct behaviour anyways.
To meet these goals, I have many comments. The new API, as far as
driver writers see, is two functions 'ata_hotplug_plug' and
'ata_hotplug_unplug'. Respectively, these should be called when a new
disk is picked up or removed. This seems like the most logical way to
go about this.
The functions use a single shared workqueue to schedule plug and unplug
events. In the 'normal case' where a user merely plugs in or unplugs a
disk, you can trivially follow the functionality. The edge cases all
have to do with these cases: what happens when the user really quickly
plugs/unplugs disks, or has pending I/O?
You'll note at a cursory glance that we need to call an ata_bus_reset
when plugging in a disk; this means that we have to wait a bit for
everything to settle. If the user goes and unplugs the disk on us, we
need to immediately take corrective action.
As such, the 'plug' function is a little complicated.
There is also the issue of I/O (or other requests?) pending on a device
when we unplug it. Since we do not want to panic the kernel, we need to
handle them gracefully. As it stands, the SCSI layer does this for us
rather nicely, EXCEPT in the case that we have an outstanding qc on our
device, waiting for completion. This is the explanation for the 'if
(qc)' checks in various parts of the code to kill these functions.
I must point out that I have NOT tested this on SMP systems, where we
can potentially be servicing more than one request from our request
queue. Potentially doing a plug/unplug/plug/unplug/etc. kind of action
very fast might lead us to running multiple 'plug' and 'unplug'
functions simultaneously.
I did NOT want to complicate the libata code by throwing spinlocks
around all over the place to protect against this (changing working,
existing code), instead, I have wrapped the 'plug' and 'unplug'
functions within a mutex. This should ensure no erroneous behaviour,
and still service requests in a timely fashion 99% of the time (on UP
systems, it actually makes no difference).
There are GRATUITOUS comments put in the code for you to look at to see
if my logic is flawed. Have fun!
Luke Kosewski
Human Cannonball
Net Integration Technologies
Signed-off-by: Luke Kosewski <[EMAIL PROTECTED]>
21.07.05 Luke Kosewski <[EMAIL PROTECTED]>
* A patch to add a general-purpose hotswap framework to libata. From
the point of view of the driver writer, we only have two new API
functions; 'ata_hotplug_plug' and 'ata_hotplug_unplug', which have
rather self-explanatory functions.
* A few misc changes are necessary to properly reset flags which are
set by devices when they are present to make sure that new devices
(for instance, disks with different max UDMA transfer rates, not using
LBA48, etc.) being swapped in do not assume values for the old
devices.
* Gratuitous comments here that can probably be removed, so that anyone
looking at this can understand this and poke holes in my logic.
Signed-off-by: Luke Kosewski <[EMAIL PROTECTED]>
--- linux-2.6.13-rc3/drivers/scsi/libata-core.c.old 2005-07-21
13:35:31.609832324 -0400
+++ linux-2.6.13-rc3/drivers/scsi/libata-core.c 2005-07-21 13:42:53.945386060
-0400
@@ -44,7 +44,6 @@
#include
#include
#include
-#include
#include
#include "libata.h"
@@ -65,6 +64,7 @@ static void __ata_qc_complete(struct ata
static unsigned int ata_unique_id = 1;
static struct workqueue_struct *ata_wq;
+static struct workqueue_struct *ata_irq_wq;
MODULE_AUTHOR("Jeff Garzik");
MODULE_DESCRIPTION("Library module for ATA devices");
@@ -1134,6 +1134,11 @@ static void ata_dev_identify(struct ata_
return;
}
+ /* Necessary if we had an LBA48 drive in, we pulled it out, and put in
+* a non-LBA48 drive to replace it.
+*/
+ dev->flags &= ~ATA_DFLAG_LBA48;
+
if (ap->flags & (ATA_FLAG_SRST | ATA_FLAG_SATA_RESET))
using_edd = 0;
else
@@ -3635,6 +3640,73 @@ idle_irq:
return 0; /* irq not handled */
}
+void ata_check_kill_qc(struct ata_port *ap)
+{
+ struct ata_queued_cmd *qc = ata_qc_from_tag(ap, ap->active_tag);
+
+ if (unlikely(qc)) {
+ /* This is SO bad. But we can't just run
+* ata_qc_complete without doing this, because
+* ata_scsi_qc_complete wants to talk to the device,
+* and we can't let it do that since it doesn't exist
+* anymore.
How to change the value of IPCMNI?
Hi, Is there any ways to change IPCMNI in include/linux/ipc.h . It is currently at 32768, and it is not big enough for my implementation. Thx for the help. - 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 0/3] Add disk hotswap support to libata
Hey all, introductory blurb here. This sequence of patches will add a framework to libata to allow for hot-swapping disks in and out. There are three patches: 01-promise_sataII150_support 02-libata_hotswap_infrastructure 03-promise_hotswap_support The rationale for each will be described in following emails. I encourage anyone with design ideas to come forward and contribute, and anyone who can see concurrency problems (I will describe what I see as issues along with the second patch) to suggest fixes. Thus far, I've tested this HEAVILY with a 2.6.11.12 kernel + 2.6.11-libata-dev1.patch. I have found no issues outstanding on that kernel. All testing was done with Promise SATA150 and SATAII150 Tx4/Tx2 Plus controllers and a huge variety of Western Digital and Seagate disks. I have ported my patches to 2.6.13-rc3 and 2.6.13-rc3-mm1, and have tested on the latter as well; they work identically to the 2.6.11 tests except for a breakage in the SCSI layer [1]. The patches I will attach apply to the latter (2.6.13-rc3-mm1) tree, since I expect that by the time people start looking at them seriously, the existing libata patches in that tree will have become part of mainline. If this is NOT the right thing to do, please tell me, and I'll submit patches for the requested kernel version. Enjoy! Luke Kosewski Human Cannonball Net Integration Technologies [1] The SCSI error on 2.6.13-rc3-mm1 that I found: 'echo "scsi add-single-device a b c d" > /proc/scsi/scsi' //works, or no-op if the sd corresponding to that device is there already 'echo "scsi remove-single-device a b c d" > /proc/scsi/scsi' //works 'echo "scsi add-single-device a b c d" > /proc/scsi/scsi' //works 'echo "scsi remove-single-device a b c d" > /proc/scsi/scsi' //FAILS As such, since the same underlying functions are called by hotplugging, you will only be able to remove a disk from a device once before it fails, until this error is fixed. I'll look into it as well. - 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/
Supermount
Is there a reason why this magnificient piece of software is not already in the mainline? It seems to be working very well and provides functionality that simply isn't available otherwise. For those who are not familiar with it: this system does on-demand mounting when the mount point is accessed and automatically umounts afterwards. Unlike autofs, this does not require a special automount filesystem to be mounted, but the actual filesystems can be directly mounted where-ever. Also, it "just works" and the CD drive will eject when the button is pressed, without having to wait for the umount timeout to pass. I haven't looked inside to find out HOW it actually does it, because I simply don't care, as long as it just works. - Tronic - signature.asc Description: OpenPGP digital signature
Re: kernel guide to space
On 7/21/05, linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote: > > On Thu, 21 Jul 2005, Jesper Juhl wrote: > > > On 7/21/05, Kyle Moffett <[EMAIL PROTECTED]> wrote: > >> On Jul 20, 2005, at 20:45:21, Paul Jackson wrote: > > [...snip...] > >> *cough* TargetStatistics[TargetID].HostAdapterResetsCompleted *cough* > >> > >> I suspect linus would be willing to accept a few cleanup patches for the > >> BusLogic.c file. Perhaps even one that renames BusLogic.c to buslogic.c > >> like all the other files in the source tree, instead of using nasty > >> StudlyCaps all over :-D > >> > > > > To avoid people doing duplicate work, I just want to say that I've > > started doing a CodingStyle/whitespace/VariableAndFunctionNaming > > cleanup of the BusLogic driver, I'll send the patches to LKML in a few > > hours. > > > Are you going to get rid of the BusLogic* in front of every variable > and function name? (yes please??) Yes, I am. > If so, you will need a few days! That may be, it sure turned into a bigger job than I had at first expected. I'll break it into a few logical bits and submit them along the way. First bits in a few hours - let's see how far I get :) > It will take probably an hour to parse: > struct BusLogic_FetchHostAdapterLocalRAMReguest Yeah, it takes time, but I'll get it done. > > Thank you. > np. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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] kbuild: make help binrpm-pkg fix
On Tue, Jul 19, 2005 at 09:42:54AM -0500, Coywolf Qi Hunt wrote: > This fixes kbuild make help binrpm-pkg missing `''. Applied, thanks. Sam - 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 -Wun-def to global CFLAGS
On Thu, Jul 21, 2005 at 09:02:09PM +0200, Olaf Hering wrote: > > A recent change to the aic scsi driver removed two defines to detect > endianness. cpp handles undefined strings as 0. As a result, the test turned > into #if 0 == 0 and the wrong code was selected. > Adding -Wundef to global CFLAGS will catch such errors. To my suprise it did not spew out a lot of warnings in my build. In the kernel we quite consitently use ??#ifdef - good! Applied. Sam - 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: amd64-agp vs. swsusp
On Thursday, 21 of July 2005 17:24, Michal Schmidt wrote: > Pavel Machek wrote: > >>I'm trying to do something similar for x86_64. See the attached patch. > >>Unfortunately, it doesn't help. The behaviour seems unchanged (resume > >>still works iff amd64-agp wasn't loaded before suspend). > > > > > > Are you sure problem is on level4_pgt? We probably use constant > > level4_pgt but split pages at some deeper level. You may want try > > saving 3rd-level table, instead. > > I'm not sure about that at all. That was just my attempt of cargocult > programming :-) > OK, I'll try saving the 3rd-level table. It'll take me some time to > figure out how to do that, however :-) I think the amd64-agp is the problem here. There are some memory mappings that seem to require the hardware to be initialized before they can be used safely (at least as far as I understand it). Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - 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] [PATCH] Syncthreads support.
On Thu, 21 Jul 2005, Nigel Cunningham wrote:
> This patch implements a new PF_SYNCTHREAD flag, which allows upcoming
> the refrigerator implementation to know that a thread is syncing data to
> disk. This allows the refrigerator to be more reliable, even under heavy
> load, because it can separate userspace processes that are submitting
> I/O from those trying to sync it and freezing the former first. We can
> thus ensure that syncing processes complete their work more quickly and
> the refrigerator is far less likely to incorrectly give up (thinking a
> syncing process is completely failing to enter the refrigerator).
I don't have any strong feelings for this, one way or another. It seems
kinda hacky, and it needs to be discussed publically, and it seems like it
definitely seems like it doesn't need to go in immediately.
I have just a couple of suggestions below..
> int fsync_super(struct super_block *sb)
> {
> + int ret;
> +
> + /* A safety net. During suspend, we might overwrite
> + * memory containing filesystem info. We don't then
> + * want to sync it to disk. */
> + BUG_ON(test_suspend_state(SUSPEND_DISABLE_SYNCING));
Please do not add any new BUG()s. Figure out another way to gracefully
fail, perhaps some place else.
> + current->flags |= PF_SYNCTHREAD;
Is all the modification of current->flags safe? It seems like you could be
pre-empted in the middle and things could get wacky.
Another note is that these changes will have to go through Al Viro, who
might have some suggestions on the Right(tm) way to do it.
Pat
-
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/
Extending defconfig for x86_64
Hi Andi This patch is a trivial one. Provide a differnet defconfig for x86_64. Each time people get bitten by which scsi controller/eth to use. It might be possible to setup configs for other systems as well, if there are well known system names to make it simple for devl. Please consider for next update. -- Cheers, Ashok Raj - Open Source Technology Center This provides a working default config file for Intel systems. Tested on harwich (4p + ht systems), if more are required either add to this config, or create new defconfig's as required. Signed-off-by: Ashok Raj <[EMAIL PROTECTED]> -- arch/x86_64/configs/harwich_defconfig | 1185 ++ 1 files changed, 1185 insertions(+) Index: linux-2.6.13-rc3-mm1/arch/x86_64/configs/harwich_defconfig === --- /dev/null +++ linux-2.6.13-rc3-mm1/arch/x86_64/configs/harwich_defconfig @@ -0,0 +1,1185 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.13-rc3 +# Mon Jul 18 12:18:34 2005 +# +CONFIG_X86_64=y +CONFIG_64BIT=y +CONFIG_X86=y +CONFIG_MMU=y +CONFIG_RWSEM_GENERIC_SPINLOCK=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_X86_CMPXCHG=y +CONFIG_EARLY_PRINTK=y +CONFIG_GENERIC_ISA_DMA=y +CONFIG_GENERIC_IOMAP=y + +# +# Code maturity level options +# +CONFIG_EXPERIMENTAL=y +CONFIG_CLEAN_COMPILE=y +CONFIG_LOCK_KERNEL=y +CONFIG_INIT_ENV_ARG_LIMIT=32 + +# +# General setup +# +CONFIG_LOCALVERSION="" +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_POSIX_MQUEUE=y +# CONFIG_BSD_PROCESS_ACCT is not set +CONFIG_SYSCTL=y +# CONFIG_AUDIT is not set +CONFIG_HOTPLUG=y +CONFIG_KOBJECT_UEVENT=y +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +# CONFIG_CPUSETS is not set +# CONFIG_EMBEDDED is not set +CONFIG_KALLSYMS=y +CONFIG_KALLSYMS_ALL=y +# CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_EPOLL=y +CONFIG_SHMEM=y +CONFIG_CC_ALIGN_FUNCTIONS=0 +CONFIG_CC_ALIGN_LABELS=0 +CONFIG_CC_ALIGN_LOOPS=0 +CONFIG_CC_ALIGN_JUMPS=0 +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 + +# +# Loadable module support +# +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +CONFIG_MODULE_FORCE_UNLOAD=y +CONFIG_OBSOLETE_MODPARM=y +# CONFIG_MODVERSIONS is not set +# CONFIG_MODULE_SRCVERSION_ALL is not set +# CONFIG_KMOD is not set +CONFIG_STOP_MACHINE=y + +# +# Processor type and features +# +# CONFIG_MK8 is not set +# CONFIG_MPSC is not set +CONFIG_GENERIC_CPU=y +CONFIG_X86_L1_CACHE_BYTES=128 +CONFIG_X86_L1_CACHE_SHIFT=7 +CONFIG_X86_TSC=y +CONFIG_X86_GOOD_APIC=y +# CONFIG_MICROCODE is not set +CONFIG_X86_MSR=y +CONFIG_X86_CPUID=y +CONFIG_X86_HT=y +CONFIG_X86_IO_APIC=y +CONFIG_X86_LOCAL_APIC=y +CONFIG_MTRR=y +CONFIG_SMP=y +CONFIG_SCHED_SMT=y +CONFIG_PREEMPT_NONE=y +# CONFIG_PREEMPT_VOLUNTARY is not set +# CONFIG_PREEMPT is not set +CONFIG_PREEMPT_BKL=y +# CONFIG_K8_NUMA is not set +# CONFIG_NUMA_EMU is not set +# CONFIG_NUMA is not set +CONFIG_ARCH_FLATMEM_ENABLE=y +CONFIG_SELECT_MEMORY_MODEL=y +CONFIG_FLATMEM_MANUAL=y +# CONFIG_DISCONTIGMEM_MANUAL is not set +# CONFIG_SPARSEMEM_MANUAL is not set +CONFIG_FLATMEM=y +CONFIG_FLAT_NODE_MEM_MAP=y +CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y +CONFIG_HAVE_DEC_LOCK=y +CONFIG_NR_CPUS=8 +CONFIG_HOTPLUG_CPU=y +CONFIG_HPET_TIMER=y +CONFIG_X86_PM_TIMER=y +CONFIG_HPET_EMULATE_RTC=y +CONFIG_GART_IOMMU=y +CONFIG_SWIOTLB=y +CONFIG_X86_MCE=y +CONFIG_X86_MCE_INTEL=y +CONFIG_PHYSICAL_START=0x10 +# CONFIG_KEXEC is not set +CONFIG_SECCOMP=y +# CONFIG_HZ_100 is not set +CONFIG_HZ_250=y +# CONFIG_HZ_1000 is not set +CONFIG_HZ=250 +CONFIG_GENERIC_HARDIRQS=y +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_ISA_DMA_API=y + +# +# Power management options +# +CONFIG_PM=y +# CONFIG_PM_DEBUG is not set +CONFIG_SOFTWARE_SUSPEND=y +CONFIG_PM_STD_PARTITION="" +CONFIG_SUSPEND_SMP=y + +# +# ACPI (Advanced Configuration and Power Interface) Support +# +CONFIG_ACPI=y +CONFIG_ACPI_BOOT=y +CONFIG_ACPI_INTERPRETER=y +# CONFIG_ACPI_SLEEP is not set +CONFIG_ACPI_AC=y +CONFIG_ACPI_BATTERY=y +CONFIG_ACPI_BUTTON=y +# CONFIG_ACPI_VIDEO is not set +CONFIG_ACPI_HOTKEY=m +CONFIG_ACPI_FAN=y +CONFIG_ACPI_PROCESSOR=y +CONFIG_ACPI_HOTPLUG_CPU=y +CONFIG_ACPI_THERMAL=y +# CONFIG_ACPI_ASUS is not set +# CONFIG_ACPI_IBM is not set +CONFIG_ACPI_TOSHIBA=y +CONFIG_ACPI_BLACKLIST_YEAR=2001 +# CONFIG_ACPI_DEBUG is not set +CONFIG_ACPI_BUS=y +CONFIG_ACPI_EC=y +CONFIG_ACPI_POWER=y +CONFIG_ACPI_PCI=y +CONFIG_ACPI_SYSTEM=y +CONFIG_ACPI_CONTAINER=y + +# +# CPU Frequency scaling +# +CONFIG_CPU_FREQ=y +CONFIG_CPU_FREQ_TABLE=y +# CONFIG_CPU_FREQ_DEBUG is not set +CONFIG_CPU_FREQ_STAT=y +# CONFIG_CPU_FREQ_STAT_DETAILS is not set +CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y +# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set +CONFIG_CPU_FREQ_GOV_PERFORMANCE=y +# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set +CONFIG_CPU_FREQ_GOV_USERSPACE=y +CONFIG_CPU_FREQ_GOV_ONDEMAND=y +# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set + +# +#
Re: often ide errors on amd64 / A8N-SLI
From: Alan Cox <[EMAIL PROTECTED]>
Date: Thu, Jul 21, 2005 at 08:30:13PM +0100
> On Iau, 2005-07-21 at 19:26 +0200, jurriaan wrote:
> > hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> > hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
>
> There was corruption on the cable between the controller and drive. That
> usually indicates a cable or noise problem in the PC but could indicate
> mistuning of the interface. Make sure the IDE cable is
>
> [controller]< long section ->[slave]--short section-->[master]
>
> as one common cause is having the cable the other way around.
The cable happens to run the correct way, but you've given me a valuable
hint. I was wondering why hda had errors and hdc (which is the same
drive on the second port of the controller) didn't. Perhaps I'll try
another cable.
Thanks,
Jurriaan
--
IF MICROSOFT BUILT CARS..
You could only have one person in the car at a time, unless you
bought "Car95" or "CarNT". But, then you would have to buy more
seats.
Debian (Unstable) GNU/Linux 2.6.13-rc3-mm1 5149 bogomips load 1.94
-
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] [PATCH] Workqueue freezer support.
On Thu, 21 Jul 2005, Nigel Cunningham wrote:
> This patch implements freezer support for workqueues. The current
> refrigerator implementation makes all workqueues NOFREEZE, regardless of
> whether they need to be or not.
A few comments..
> Signed-off by: Nigel Cunningham <[EMAIL PROTECTED]>
>
> drivers/acpi/osl.c |2 +-
> drivers/block/ll_rw_blk.c |2 +-
> drivers/char/hvc_console.c |2 +-
> drivers/char/hvcs.c |2 +-
> drivers/input/serio/serio.c |2 +-
> drivers/md/dm-crypt.c |2 +-
> drivers/scsi/hosts.c|2 +-
> drivers/usb/net/pegasus.c |2 +-
If you want some practice splitting things up, submit the patches above
individually to the maintainers o the relevant code once the patches you
submit below get merged to -mm.
> include/linux/kthread.h | 20 ++--
> include/linux/workqueue.h |9 ++---
> kernel/kmod.c |4
> kernel/kthread.c| 23 ++-
> kernel/sched.c |4 ++--
> kernel/softirq.c|3 +--
> kernel/workqueue.c | 21 -
> 15 files changed, 73 insertions(+), 27 deletions(-)
You should make sure that you get an explicit ACK from people (Ingo et al)
about whether this is an acceptable interface.
> --- 400-workthreads.patch-old/include/linux/kthread.h 2004-11-03
> 21:51:12.0 +1100
> +++ 400-workthreads.patch-new/include/linux/kthread.h 2005-07-20
> 15:11:37.0 +1000
> @@ -27,6 +27,14 @@ struct task_struct *kthread_create(int (
> void *data,
> const char namefmt[], ...);
>
> +struct task_struct *_kthread_create(int (*threadfn)(void *data),
> +void *data,
> +unsigned long freezer_flags,
> +const char namefmt[], ...);
> +
This should be __kthread_create(...)
> -#define kthread_run(threadfn, data, namefmt, ...) \
> +#define kthread_run(threadfn, data, namefmt, args...)
>\
> ({ \
> struct task_struct *__k\
> - = kthread_create(threadfn, data, namefmt, ## __VA_ARGS__); \
> + = kthread_create(threadfn, data, namefmt, ##args); \
> if (!IS_ERR(__k)) \
> wake_up_process(__k); \
> __k; \
> })
>
> +#define kthread_nofreeze_run(threadfn, data, namefmt, args...)
>\
> +({ \
> + struct task_struct *__k = kthread_nofreeze_create(threadfn, data, \
> + namefmt, ##args); \
> + if (!IS_ERR(__k)) \
> + wake_up_process(__k); \
> + __k; \
> +})
Do these functions need to be inlined?
> @@ -86,6 +87,10 @@ static int kthread(void *_create)
> /* By default we can run anywhere, unlike keventd. */
> set_cpus_allowed(current, CPU_MASK_ALL);
>
> + /* Set our freezer flags */
> + current->flags &= ~(PF_SYNCTHREAD | PF_NOFREEZE);
> + current->flags |= (create->freezer_flags & PF_NOFREEZE);
> +
Maybe these should be encapsulated in a helper in include/linux/sched.h
like some other flags manipulations are?
> diff -ruNp 400-workthreads.patch-old/kernel/sched.c
> 400-workthreads.patch-new/kernel/sched.c
> --- 400-workthreads.patch-old/kernel/sched.c 2005-07-21 04:00:02.0
> +1000
> +++ 400-workthreads.patch-new/kernel/sched.c 2005-07-21 04:00:19.0
> +1000
> @@ -4580,10 +4580,10 @@ static int migration_call(struct notifie
>
> switch (action) {
> case CPU_UP_PREPARE:
> - p = kthread_create(migration_thread, hcpu, "migration/%d",cpu);
> + p = kthread_create(migration_thread, hcpu,
> + "migration/%d",cpu);
This is unnecessary.
Overall, it looks pretty good.
Thanks,
Pat
-
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 guide to space
On Thu, 21 Jul 2005, Jesper Juhl wrote: > On 7/21/05, Kyle Moffett <[EMAIL PROTECTED]> wrote: >> On Jul 20, 2005, at 20:45:21, Paul Jackson wrote: > [...snip...] >> *cough* TargetStatistics[TargetID].HostAdapterResetsCompleted *cough* >> >> I suspect linus would be willing to accept a few cleanup patches for the >> BusLogic.c file. Perhaps even one that renames BusLogic.c to buslogic.c >> like all the other files in the source tree, instead of using nasty >> StudlyCaps all over :-D >> > > To avoid people doing duplicate work, I just want to say that I've > started doing a CodingStyle/whitespace/VariableAndFunctionNaming > cleanup of the BusLogic driver, I'll send the patches to LKML in a few > hours. > Are you going to get rid of the BusLogic* in front of every variable and function name? (yes please??) If so, you will need a few days! It will take probably an hour to parse: struct BusLogic_FetchHostAdapterLocalRAMReguest FetchHostAdapterLocalRAMRequest ^!) > -- > Jesper Juhl <[EMAIL PROTECTED]> > Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html > Plain text mails only, please http://www.expita.com/nomime.html Cheers, Dick Johnson Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank 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/
[patch] no disk yoyo for -mm
From: Michal Schmidt <[EMAIL PROTECTED]>
The attached patch stops the disks from spinning down and up on
suspend. The patch applies to 2.6.13-rc3-mm1 (depends on
pm_message_t being struct).
Signed-off-by: Michal Schmidt <[EMAIL PROTECTED]>
---
commit 3d1f9a53dcf4a73934daeb878493ed512fd78407
tree 53c0d3101fa18fbfeae3dd0a4214428319dace99
parent c21641336d5c83a41d15cdb34f18413f2b8217fd
author <[EMAIL PROTECTED](none)> Thu, 21 Jul 2005 21:20:05 +0200
committer <[EMAIL PROTECTED](none)> Thu, 21 Jul 2005 21:20:05 +0200
drivers/ide/ide-io.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
--- a/drivers/ide/ide-io.c
+++ b/drivers/ide/ide-io.c
@@ -150,7 +150,7 @@ static void ide_complete_power_step(ide_
switch (rq->pm->pm_step) {
case ide_pm_flush_cache:/* Suspend step 1 (flush cache)
complete */
- if (rq->pm->pm_state == 4)
+ if (rq->pm->pm_state == PM_EVENT_FREEZE)
rq->pm->pm_step = ide_pm_state_completed;
else
rq->pm->pm_step = idedisk_pm_standby;
--
teflon -- maybe it is a trademark, but it should not be.
-
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: [RFT] solve "swsusp plays yoyo" with disks
hi!
> >>I'd like to get this tested under as many configurations as
> >>possible. With this, your hdd should no longer do "yoyo" (spindown,
> >>spinup, spindown) during suspend...
> >
> >
> >It looks like the patch is now in -mm (I use 2.6.13-rc3-mm1).
> >But my disks still yoyo during suspend. What more is needed? Some patch
> >to ide-disk.c ?
>
> I think I've found the problem.
> The attached patch stops the disks from spinning down and up on suspend.
> The patch applies to 2.6.13-rc3-mm1.
>
> Signed-off-by: Michal Schmidt <[EMAIL PROTECTED]>
Thanks, applied, I'll eventually propagate it.
Pavel
> diff -Nurp -X dontdiff.new linux-mm/drivers/ide/ide-io.c
> linux-mm.mich/drivers/ide/ide-io.c
> --- linux-mm/drivers/ide/ide-io.c 2005-06-30 01:00:53.0 +0200
> +++ linux-mm.mich/drivers/ide/ide-io.c2005-07-21 16:59:46.0
> +0200
> @@ -150,7 +150,7 @@ static void ide_complete_power_step(ide_
>
> switch (rq->pm->pm_step) {
> case ide_pm_flush_cache:/* Suspend step 1 (flush cache)
> complete */
> - if (rq->pm->pm_state == 4)
> + if (rq->pm->pm_state == PM_EVENT_FREEZE)
> rq->pm->pm_step = ide_pm_state_completed;
> else
> rq->pm->pm_step = idedisk_pm_standby;
--
Boycott Kodak -- for their patent abuse against Java.
-
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: often ide errors on amd64 / A8N-SLI
On Iau, 2005-07-21 at 19:26 +0200, jurriaan wrote:
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
There was corruption on the cable between the controller and drive. That
usually indicates a cable or noise problem in the PC but could indicate
mistuning of the interface. Make sure the IDE cable is
[controller]< long section ->[slave]--short section-->[master]
as one common cause is having the cable the other way around.
-
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] add -Wun-def to global CFLAGS
A recent change to the aic scsi driver removed two defines to detect endianness. cpp handles undefined strings as 0. As a result, the test turned into #if 0 == 0 and the wrong code was selected. Adding -Wundef to global CFLAGS will catch such errors. Signed-off-by: Olaf Hering <[EMAIL PROTECTED]> Makefile |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Index: linux-2.6.12.aic-fixing/Makefile === --- linux-2.6.12.aic-fixing.orig/Makefile +++ linux-2.6.12.aic-fixing/Makefile @@ -203,7 +203,7 @@ CONFIG_SHELL := $(shell if [ -x "$$BASH" HOSTCC = gcc HOSTCXX= g++ -HOSTCFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer +HOSTCFLAGS = -Wall -Wundef -Wstrict-prototypes -O2 -fomit-frame-pointer HOSTCXXFLAGS = -O2 # Decide whether to build built-in, modular, or both. @@ -348,7 +348,7 @@ LINUXINCLUDE:= -Iinclude \ CPPFLAGS:= -D__KERNEL__ $(LINUXINCLUDE) -CFLAGS := -Wall -Wstrict-prototypes -Wno-trigraphs \ +CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \ -fno-strict-aliasing -fno-common \ -ffreestanding AFLAGS := -D__ASSEMBLY__ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
On Thu, 21 Jul 2005 20:49:59 +0200 Guillaume Chazarain wrote: > 2005/7/21, Voluspa <[EMAIL PROTECTED]>: > > > > 2h48m at 100 HZ > > 2h48m at 250 HZ > > 2h47m at 1000 HZ > > Now, what would be interesting is to see if the lack of differences > comes from the fact that the processor has enough time to sleep, > not enough time, or simply it does not matter. > > That is, is it a best case or a worst case ? Those words swished above my head. I'd need serious hand-holding to conduct any further (meaningful) tests. > > > #!/bin/sh > > touch time-hz-start > > while (true) do > > touch time-hz-end > > sleep 1m > > done > > Why this ? > Why not simply nothing ? > A computer can be idle for more than 1 minute ;-) I had other things to do than sit with a stopwatch in my hand staring at a black screen :-) Also, 1 minute is a resonable comparison level. Mvh Mats Johannesson -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
2005/7/21, Voluspa <[EMAIL PROTECTED]>: > > 2h48m at 100 HZ > 2h48m at 250 HZ > 2h47m at 1000 HZ Now, what would be interesting is to see if the lack of differences comes from the fact that the processor has enough time to sleep, not enough time, or simply it does not matter. That is, is it a best case or a worst case ? > #!/bin/sh > touch time-hz-start > while (true) do > touch time-hz-end > sleep 1m > done Why this ? Why not simply nothing ? A computer can be idle for more than 1 minute ;-) -- Guillaume - 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 guide to space
On 7/21/05, Kyle Moffett <[EMAIL PROTECTED]> wrote: > On Jul 20, 2005, at 20:45:21, Paul Jackson wrote: [...snip...] > *cough* TargetStatistics[TargetID].HostAdapterResetsCompleted *cough* > > I suspect linus would be willing to accept a few cleanup patches for the > BusLogic.c file. Perhaps even one that renames BusLogic.c to buslogic.c > like all the other files in the source tree, instead of using nasty > StudlyCaps all over :-D > To avoid people doing duplicate work, I just want to say that I've started doing a CodingStyle/whitespace/VariableAndFunctionNaming cleanup of the BusLogic driver, I'll send the patches to LKML in a few hours. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
On Thu, 21 Jul 2005 20:14:32 +0200 Jesper Juhl wrote: > On 7/21/05, Voluspa <[EMAIL PROTECTED]> wrote: [...] > > > Ok, so with an idle machine, different HZ makes no noticeable > difference, but I'd suspect things would be different if the machine > was actually doing some work. I first thought about loading with a loop of md5sum /somedir, play a wav, fetch a couple of webpages etc. But since the talk has been that the powersave would come from CPU sleep between "ticks" (I know, I know, it's not ticks) not having to wake up so often, I decided against a load. > Would be more interresting to see how long it lasts with a light load > and with a heavy load. I won't do that unless heavily beaten ;-) The battery charge time is 2h10 minutes... Mvh Mats Johannesson -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
On 7/21/05, Voluspa <[EMAIL PROTECTED]> wrote: > > I'd gladly (ehum..) redo this mind-numbingly boring test if someone can > point me to a magic software which unleashes some untapped powersaving > feature of the CPU. > > _Kernel 2.6.13-rc3 Boot to Death_: > > 2h48m at 100 HZ > 2h48m at 250 HZ > 2h47m at 1000 HZ > > _"Load"_: > > #!/bin/sh > touch time-hz-start > while (true) do > touch time-hz-end > sleep 1m > done > Ok, so with an idle machine, different HZ makes no noticeable difference, but I'd suspect things would be different if the machine was actually doing some work. Would be more interresting to see how long it lasts with a light load and with a heavy load. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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/
ALSA, snd_intel8x0m and kexec() don't work together (2.6.13-rc3-git4 and 2.6.13-rc3-git3)
Whenever I use kexec() to reboot into a new kernel, sound doesn't work properly. KDE doesn't display a mixer. All modules seem to be loaded, though - and after a reboot using "reboot" instead of "kexec", sound works flawlessly with the same setup. /etc/init.d/alsa restart doesn't change things, either. The one message strinking me as odd during the boot-process is: Jul 21 19:50:01 kasbah kernel: AC'97 warm reset still in progress? [0x] # lsmod Module Size Used by pcmcia 32232 4 firmware_class 7872 1 pcmcia thermal10504 0 fan 3204 0 button 2944 0 ac 3332 0 battery 7556 0 mousedev 10016 1 tsdev 5888 0 evdev 7488 0 psmouse32388 0 rtc10936 0 yenta_socket 22668 4 rsrc_nonstatic 11968 1 yenta_socket pcmcia_core35920 3 pcmcia,yenta_socket,rsrc_nonstatic 8250_pci 17472 0 8250 22820 1 8250_pci serial_core19904 1 8250 snd_intel8x0m 15428 0 usbhid 34464 0 snd_intel8x0 29440 0 snd_ac97_codec 82556 2 snd_intel8x0m,snd_intel8x0 ehci_hcd 32200 0 ohci_hcd 19844 0 vfat 11072 0 fat46492 1 vfat nls_base6400 2 vfat,fat i2c_nforce2 5760 0 i2c_core 17424 1 i2c_nforce2 ndiswrapper 129204 0 usbcore 110972 5 usbhid,ehci_hcd,ohci_hcd,ndiswrapper snd_pcm_oss49440 0 snd_pcm83400 4 snd_intel8x0m,snd_intel8x0,snd_ac97_codec,snd_pcm_oss snd_timer 22276 1 snd_pcm snd_page_alloc 8392 3 snd_intel8x0m,snd_intel8x0,snd_pcm snd_mixer_oss 17408 1 snd_pcm_oss snd47204 7 snd_intel8x0m,snd_intel8x0,snd_ac97_codec,snd_pcm_oss,snd_pcm,snd_timer,snd_mixer_oss soundcore 7520 1 snd ide_cd 37956 0 cdrom 37792 1 ide_cd cpufreq_userspace 3420 0 powernow_k811144 0 freq_table 3460 1 powernow_k8 processor 18684 2 thermal,powernow_k8 unix 23856 590 # lspci :00:00.0 Host bridge: nVidia Corporation nForce3 Host Bridge (rev a4) :00:01.0 ISA bridge: nVidia Corporation nForce3 LPC Bridge (rev a6) :00:01.1 SMBus: nVidia Corporation nForce3 SMBus (rev a4) :00:02.0 USB Controller: nVidia Corporation nForce3 USB 1.1 (rev a5) :00:02.1 USB Controller: nVidia Corporation nForce3 USB 1.1 (rev a5) :00:02.2 USB Controller: nVidia Corporation nForce3 USB 2.0 (rev a2) :00:06.0 Multimedia audio controller: nVidia Corporation nForce3 Audio (rev a2) :00:06.1 Modem: nVidia Corporation: Unknown device 00d9 (rev a2) :00:08.0 IDE interface: nVidia Corporation nForce3 IDE (rev a5) :00:0a.0 PCI bridge: nVidia Corporation nForce3 PCI Bridge (rev a2) :00:0b.0 PCI bridge: nVidia Corporation nForce3 AGP Bridge (rev a4) :00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge :00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge :00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge :00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge :01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 420 Go 32M] (rev a3) :02:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) :02:02.0 Network controller: Broadcom Corporation BCM4301 802.11b (rev 02) :02:04.0 CardBus bridge: Texas Instruments: Unknown device ac54 (rev 01) :02:04.1 CardBus bridge: Texas Instruments: Unknown device ac54 (rev 01) :02:04.2 System peripheral: Texas Instruments: Unknown device 8201 (rev 01) The log of a reboot using kexec(): Jul 21 19:50:01 kasbah kernel: klogd 1.4.1#17, log source = /proc/kmsg started. Jul 21 19:50:01 kasbah kernel: Inspecting /boot/System.map-2.6.13-rc3-git4 Jul 21 19:50:01 kasbah kernel: Loaded 26210 symbols from /boot/System.map-2.6.13-rc3-git4. Jul 21 19:50:01 kasbah kernel: Symbols match kernel version 2.6.13. Jul 21 19:50:01 kasbah kernel: No module symbols loaded - kernel modules not enabled. Jul 21 19:50:01 kasbah kernel: Linux version 2.6.13-rc3-git4 ([EMAIL PROTECTED]) (gcc version 3.4.5 20050706 (prerelease) (Debian 3.4.4-5)) #1 Thu Jul 21 19:31:46 CEST 2005 Jul 21 19:50:01 kasbah kernel: BIOS-provided physical RAM map: Jul 21 19:50:01 kasbah kernel: BIOS-e820: 0100 - 0009f800 (usable) Jul 21 19:50:01 kasbah kernel: BIOS-e820: 0009f800 - 000a (reserved) Jul 21 19:50:01 kasbah kernel: BIOS-e820: 0010 - 1ff7 (usable) Jul 21 19:50:01 kasbah kernel: BIOS-e820: 1ff7 - 1ff7f000 (ACPI data) Jul 21
Re: why is the jiffies 128 in jffs2_find_gc_block() in gc.c of jffs2.
On Thu, 2005-07-21 at 22:43 +0530, krishna wrote: > Hi, > > Can any one tell me > why is the jiffies _128_ in jffs2_find_gc_block() in gc.c of jffs2. jiffies isn't set in that function. The value of jiffies is modded by 128. Since jiffies is a volatile value, the value of n is usually different on each call of that function. This value is used to pick an eraseblock to garbage collect out of a series of different lists. This is done to help with effective wear leveling of flash eraseblocks. josh - 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 tty layer hackery: Heads up and RFC
Alan Cox <[EMAIL PROTECTED]> writes: > At the moment tty buffers are attached directly to the tty. This is > causing a lot of the problems related to tty layer locking, also > problems at high speed and also with bursty data (such as occurs in > virtualised environments) > > I'm working on ripping out the flip buffers and replacing them with a > pool of dynamically allocated buffers. This allows both for old style > "byte I/O" devices and also helps virtualisation and smart devices where > large blocks of data suddenely materialise and need storing. Great! Really good news! > > So far so good. Lots of drivers reference tty->flip.*. Several of them > also call directly and unsafely into function pointers it provides. This > will all break. Most drivers can use tty_insert_flip_char which can be > kept as an API but others need more. > > At the moment I've added the following interfaces, if people think more > will be needed now is a good time to say > > int tty_buffer_request_room(tty, size) > > Try and ensure at least size bytes are available, returns actual room > (may be zero). At the moment it just uses the flipbuf space but that > will change. Repeated calls without characters being added are not > cumulative. (ie if you call it with 1, 1, 1, and then 4 you'll have four > characters of space. The other functions will also try and grow buffers > in future but this will be a more efficient way when you know block > sizes. > > int tty_insert_flip_char(tty, ch, flag) > > As before insert a character if there is room. Now returns 1 for > success, 0 for failure. > > int tty_insert_flip_string(tty, str, len) > > Insert a block of non error characters. Returns the number inserted. > > int tty_prepare_flip_string(tty, strptr, len) > > Adjust the buffer to allow len characters to be added. Returns a buffer > pointer in strptr and the length available. This allows for hardware > that needs to use functions like insl or mencpy_fromio. As you are going to replace flip buffers with different implementation anyway, isn't it better to get rid of "flip" in the interface names as well (maybe providing some synonyms for backward compatibility)? What I mean is that names like tty_buffer_insert_char() tty_buffer_insert_string() for the new interfaces would probably make more sense. Otherwise I find the interfaces you suggest just fine and suitable for the task I was unable to achieve without ugly hacks using current flip buffers interfaces (reliable high-speed bulk USB tty driver). -- Sergei. - 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/
often ide errors on amd64 / A8N-SLI
from dmesg:
Linux version 2.6.13-rc3-mm1 ([EMAIL PROTECTED]) (gcc version 4.0.1 (Debian
4.0.1-2)) #4 Thu Jul 21 19:09:25 CEST 2005
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
NFORCE-CK804: IDE controller at PCI slot :00:06.0
NFORCE-CK804: chipset revision 162
NFORCE-CK804: not 100% native mode: will probe irqs later
NFORCE-CK804: BIOS didn't set cable bits correctly. Enabling workaround.
NFORCE-CK804: :00:06.0 (rev a2) UDMA133 controller
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
hda: WDC WD2000JB-32EVA0, ATA DISK drive
hdb: _NEC DVD_RW ND-3500AG, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
I see a lot of these errors:
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide: failed opcode was: unknown
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide: failed opcode was: unknown
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide: failed opcode was: unknown
CPU0
0: 204642IO-APIC-edge timer
1: 3710IO-APIC-edge i8042
8: 0IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
12:106IO-APIC-edge i8042
14: 30571IO-APIC-edge ide0
15: 30529IO-APIC-edge ide1
50: 0 IO-APIC-level ohci_hcd:usb2
58: 9407 IO-APIC-level libata
66: 54 IO-APIC-level libata, NVidia CK804
74: 61503 IO-APIC-level libata
82: 0 IO-APIC-level ehci_hcd:usb1
225: 56249 IO-APIC-level ohci1394, fast
233: 0 IO-APIC-level SysKonnect SK-98xx
NMI:483
LOC: 204607
ERR: 0
MIS: 0
Is there any way to detect what exactly is causing this? To the best of
my knowledge, the disk works fine - even my raid1 set on this disk isn't
impacted, the speed stays ok, I'm wondering if there's a command being
sent the disk (or the controller) doesn't know how to handle.
smartctl isn't active, BTW.
Thanks,
Jurriaan
--
And the gosts of hope walk silent halls
At the death of the promised land
All is gone, all is gone
But these changing winds can turn cold and hostile
New Model Army
Debian (Unstable) GNU/Linux 2.6.13-rc3-mm1 5149 bogomips load 0.97
-
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/
Linux tty layer hackery: Heads up and RFC
At the moment tty buffers are attached directly to the tty. This is causing a lot of the problems related to tty layer locking, also problems at high speed and also with bursty data (such as occurs in virtualised environments) I'm working on ripping out the flip buffers and replacing them with a pool of dynamically allocated buffers. This allows both for old style "byte I/O" devices and also helps virtualisation and smart devices where large blocks of data suddenely materialise and need storing. So far so good. Lots of drivers reference tty->flip.*. Several of them also call directly and unsafely into function pointers it provides. This will all break. Most drivers can use tty_insert_flip_char which can be kept as an API but others need more. At the moment I've added the following interfaces, if people think more will be needed now is a good time to say int tty_buffer_request_room(tty, size) Try and ensure at least size bytes are available, returns actual room (may be zero). At the moment it just uses the flipbuf space but that will change. Repeated calls without characters being added are not cumulative. (ie if you call it with 1, 1, 1, and then 4 you'll have four characters of space. The other functions will also try and grow buffers in future but this will be a more efficient way when you know block sizes. int tty_insert_flip_char(tty, ch, flag) As before insert a character if there is room. Now returns 1 for success, 0 for failure. int tty_insert_flip_string(tty, str, len) Insert a block of non error characters. Returns the number inserted. int tty_prepare_flip_string(tty, strptr, len) Adjust the buffer to allow len characters to be added. Returns a buffer pointer in strptr and the length available. This allows for hardware that needs to use functions like insl or mencpy_fromio. I've converted a fair number of drivers to this API ready and I'll post some patches for review soon. Alan - 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 guide to space
On Jul 20, 2005, at 20:45:21, Paul Jackson wrote: drivers/scsi/BusLogic.c: %2d %5d %5d %5d%5d %5d %5d %5d %5d %5d\n", TargetID, TargetStatistics[TargetID].CommandAbortsRequested, TargetStatistics[TargetID].CommandAbortsAttempted, TargetStatistics [TargetID].CommandAbortsCompleted, TargetStatistics [TargetID].BusDeviceResetsRequested, TargetStatistics [TargetID].BusDeviceResetsAttempted, TargetStatistics [TargetID].BusDeviceResetsCompleted, TargetStatistics [TargetID].HostAdapterResetsRequested, TargetStatistics [TargetID].HostAdapterResetsAttempted, TargetStatistics [TargetID].HostAdapterResetsCompleted); Ugh!!! From CodingStyle (although this is not always followed): The limit on the length of lines is 80 columns and this is a hard limit. Statements longer than 80 columns will be broken into sensible chunks. Descendants are always substantially shorter than the parent and are placed substantially to the right. The same applies to function headers with a long argument list. Long strings are as well broken into shorter strings. [example relevant to the above code snipped] Also: C is a Spartan language, and so should your naming be. Unlike Modula-2 and Pascal programmers, C programmers do not use cute names like ThisVariableIsATemporaryCounter. A C programmer would call that variable "tmp", which is much easier to write, and not the least more difficult to understand. [...] mixed-case names are frowned upon [...] *cough* TargetStatistics[TargetID].HostAdapterResetsCompleted *cough* I suspect linus would be willing to accept a few cleanup patches for the BusLogic.c file. Perhaps even one that renames BusLogic.c to buslogic.c like all the other files in the source tree, instead of using nasty StudlyCaps all over :-D 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: VIA KT400 + Kernel 2.6.12 + IO-APIC + uhci_hcd = IRQ trouble
Michel Bouissou a écrit : Hi there, Natalie Protasevich and Alan Stern have worked a lot on helping me out with a VIA KT400 chipset / kernel 2.6.12 / IO-APIC / IRQ problem "irq 21: nobody cared!", which so far hasn't found its solution. Research done with Alan shows that, on my system, the USB 2.0 controller seems to generate interrupts on the IRQ line attributed to the USB 1.1 controller, which isn't supposed to happen, and puzzles the system, when IO-APIC is enabled. However, this didn't cause problems with 2.4 series kernels. For the time being, there is no solution (Natalie is still investigating this), and it boils down to the following: - If I boot with USB 2.0 enabled in BIOS, AND IO-APIC enabled in the kernel, then it badly breaks. - If I either disable USB 2.0 in BIOS, or IO-APIC in the kernel, then it's OK. I found today the thread between Bjorn Helgaas and Mathieu Bérard on LKML, where Mathieu reported the same problem, and Bjorn advised him to reverse a kernel patch (http://lkml.org/lkml/2005/6/21/243 ). Mathieu (I don't have his email address, Bjorn, could you be so kind to forward this message to him) reports that it apparently solved this problem, so I tried to do the same, and reversed the same patch. Hi, yes I've encountered the same problem but my system is a little bit different: It's a MSI mainboard with a VIA KT266A chipset and no USB 2.0 controller (just 3 uhci). IO-APIC is enabled. With a 2.6.13-rc1-mm1 kernel, for example, I got those error messages just after the integrated sound card detection: Jul 2 21:04:12 perenold kernel: irq 21: nobody cared (try booting with the "irqpoll" option) Jul 2 21:04:12 perenold kernel: [] __report_bad_irq+0x24/0x80 Jul 2 21:04:12 perenold kernel: [] note_interrupt+0x72/0xc0 Jul 2 21:04:12 perenold kernel: [] __do_IRQ+0xe0/0xf0 Jul 2 21:04:12 perenold kernel: [] do_IRQ+0x3e/0x60 Jul 2 21:04:12 perenold kernel: === Jul 2 21:04:12 perenold kernel: [] common_interrupt+0x1a/0x20 Jul 2 21:04:12 perenold kernel: [] zap_pte_range+0x82/0x1c0 Jul 2 21:04:12 perenold kernel: [] unmap_page_range+0x7f/0xb0 Jul 2 21:04:12 perenold kernel: [] unmap_vmas+0x106/0x210 Jul 2 21:04:12 perenold kernel: [] exit_mmap+0x71/0x140 Jul 2 21:04:12 perenold kernel: [] mmput+0x2e/0xe0 Jul 2 21:04:12 perenold kernel: [] exec_mmap+0xac/0x160 Jul 2 21:04:12 perenold kernel: [] flush_old_exec+0x70/0x700 Jul 2 21:04:12 perenold kernel: [] vfs_read+0xf5/0x160 Jul 2 21:04:12 perenold kernel: [] kernel_read+0x40/0x60 Jul 2 21:04:12 perenold kernel: [] load_elf_binary+0x252/0xd20 Jul 2 21:04:12 perenold kernel: [] buffered_rmqueue+0xb7/0x210 Jul 2 21:04:12 perenold kernel: [] __alloc_pages+0xdb/0x400 Jul 2 21:04:12 perenold kernel: [] do_IRQ+0x45/0x60 Jul 2 21:04:12 perenold kernel: [] __copy_from_user_ll+0x3e/0x70 Jul 2 21:04:12 perenold kernel: [] search_binary_handler+0x4f/0x1d0 Jul 2 21:04:12 perenold kernel: [] do_execve+0x14e/0x200 Jul 2 21:04:12 perenold kernel: [] sys_execve+0x2f/0x70 Jul 2 21:04:12 perenold kernel: [] sysenter_past_esp+0x54/0x75 Jul 2 21:04:12 perenold kernel: handlers: Jul 2 21:04:12 perenold kernel: [] (snd_via82xx_interrupt+0x0/0xc0 [snd_via82xx]) Jul 2 21:04:12 perenold kernel: Disabling IRQ #21 and later: Jul 2 21:04:37 perenold kernel: uhci_hcd :00:11.3: Unlink after no-IRQ? Controller is probably using the wrong IRQ. IRQ 21 is then crazy with a rate of increasing of around 20 per second in /proc/interrupts All those error messages disappear if I revert the patch as I was advised to. I have that in /proc/interrupts: (with an healthy kernel) CPU0 0: 201893429IO-APIC-edge timer 1: 21IO-APIC-edge i8042 7: 2IO-APIC-edge parport0 8: 0IO-APIC-edge rtc 9: 0 IO-APIC-level acpi 14:5448524IO-APIC-edge ide0 15: 14583934IO-APIC-edge ide1 16: 172543 IO-APIC-level ide3 17: 299810 IO-APIC-level saa7134[0] 18: 24973124 IO-APIC-level eth0 19:5233000 IO-APIC-level eth1 20: 82 IO-APIC-level uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3 21: 0 IO-APIC-level VIA8233 NMI: 0 LOC: 201897508 ERR: 0 MIS: 0 So maybe, in my case, it's a mess between the IRQ of the uhci controllers and the one of the integrated AC'97 sound ship. But as it is mainly a server box nor the usb controllers nor the sound card are used very often, so I don't know if those devices are actually working now. I am currently on vacation 300 km away from that box so I can't really plug an USB key to do some tests. But I will as soon as a can if that can help. I will also try to reboot the box several times to see if the "IRQ 21 nobody cared" error reappears. -- Mathieu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at
[PATCH] PPC compilation error with CONFIG_PQ2FADS
The 2.6.12.3 kernel compilation fails for ARCH=ppc when CONFIG_PQ2FADS=y. This patch has been tested on Freescale PQ2FADS-ZU and -VR boards. --- linux-2.6.12.3/arch/ppc/syslib/m82xx_pci.c 2005-07-15 17:18:57.0 -0400 +++ linux-musrum/arch/ppc/syslib/m82xx_pci.c2005-07-20 08:42:41.0 -0400 @@ -238,9 +238,9 @@ * Setting required to enable IRQ1-IRQ7 (SIUMCR [DPPC]), * and local bus for PCI (SIUMCR [LBPC]). */ - immap->im_siu_conf.siu_82xx.sc_siumcr = (immap->im_siu_conf.sc_siumcr & - ~(SIUMCR_L2PC11 | SIUMCR_LBPC11 | SIUMCR_CS10PC11 | SIUMCR_APPC11) | - SIUMCR_BBD | SIUMCR_LBPC01 | SIUMCR_DPPC11 | SIUMCR_APPC10; + immap->im_siu_conf.siu_82xx.sc_siumcr = (immap->im_siu_conf.siu_82xx.sc_siumcr & + ~(SIUMCR_L2CPC11 | SIUMCR_LBPC11 | SIUMCR_CS10PC11 | SIUMCR_APPC11) | + SIUMCR_BBD | SIUMCR_LBPC01 | SIUMCR_DPPC11 | SIUMCR_APPC10); #endif /* Enable PCI */ immap->im_pci.pci_gcr = cpu_to_le32(PCIGCR_PCI_BUS_EN); Thomas Downing IPC Information Systems, LLC - 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/
