Re: RFD: Kernel release numbering
Andrew Morton wrote: It won't help that at all. None of these proposals will increase testing of tip-of-tree. In fact the 2.6.x proposal may decrease that level of that testing, although probably not much. Giving humans a well-known point where bugfixes-only mode starts would help. Such as the -pre/-rc split does in 2.4.x. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB 2.4.30: fix modem_run
On Fri, 11 Feb 2005 11:16:20 +0100 Duncan Sands <[EMAIL PROTECTED]> wrote: > On Thu, 2005-02-10 at 16:11 -0800, Pete Zaitcev wrote: > > I entered a patch which adds "exclusive_access" lock into 2.4.29, > > to fix devices which cannot handle simultaneous accesses. This > > caused a regression with European ADSL modems. An ioctl > > USBDEVFS_REAPURB allows a process to enter the kernel and wait for > > USB I/O to finish. Naturally, this should not take > > exclusive_access, or nothing will ever finish. > > How does this compare with the locking in 2.6 kernels? In 2.6, there is no locking whatsoever. Instead, rules for queueing are relaxed for all HCs. If the device chokes when it receives a control together with a data exchange (on a bulk endpoint, usually), kernel does not interfere. Users (libusb & drivers) are supposed to know when not to do it. Obviously, it's not the case of usb-storage. To help that, descriptor strings are cached in latest Greg's trees, since a week ago or so. This way at least "cat /proc/bus/usb/devices" won't interfere. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Tracing memory leaks (slabs) in 2.6.9+ kernels?
Thanks everybody for your help. I have at least located the site of the leak - now I just need to find out why the destructor is not being called ;-). Will the slab debugger make it into the kernel as a standard compile time option? It is a _really_ usefull tool to have around. Thanks again, Justin Andrew Morton wrote: Justin Schoeman <[EMAIL PROTECTED]> wrote: OK - I have the patch working now, but there seems to be a flaw in the address reporting. When I look up the reported address in /proc/kallsyms, then look in the objdump of the module, the reported adress _does_not_ point to a call. Am I missing something simple here? Use the latest version of the patch (below). Link the module into the kernel. Enable CONFIG_KALLSYMS. --- 25/include/asm-alpha/types.h~slab-leak-detector 2005-03-02 08:30:59.0 -0800 +++ 25-akpm/include/asm-alpha/types.h 2005-03-02 08:30:59.0 -0800 @@ -56,7 +56,7 @@ typedef unsigned long u64; typedef u64 dma_addr_t; typedef u64 dma64_addr_t; -typedef unsigned short kmem_bufctl_t; +typedef unsigned long kmem_bufctl_t; #endif /* __ASSEMBLY__ */ #endif /* __KERNEL__ */ diff -puN include/asm-arm26/types.h~slab-leak-detector include/asm-arm26/types.h --- 25/include/asm-arm26/types.h~slab-leak-detector 2005-03-02 08:30:59.0 -0800 +++ 25-akpm/include/asm-arm26/types.h 2005-03-02 08:30:59.0 -0800 @@ -52,7 +52,7 @@ typedef unsigned long long u64; typedef u32 dma_addr_t; typedef u32 dma64_addr_t; -typedef unsigned int kmem_bufctl_t; +typedef unsigned long kmem_bufctl_t; #endif /* __ASSEMBLY__ */ diff -puN include/asm-arm/types.h~slab-leak-detector include/asm-arm/types.h --- 25/include/asm-arm/types.h~slab-leak-detector 2005-03-02 08:30:59.0 -0800 +++ 25-akpm/include/asm-arm/types.h 2005-03-02 08:30:59.0 -0800 @@ -52,7 +52,7 @@ typedef unsigned long long u64; typedef u32 dma_addr_t; typedef u32 dma64_addr_t; -typedef unsigned int kmem_bufctl_t; +typedef unsigned long kmem_bufctl_t; #endif /* __ASSEMBLY__ */ diff -puN include/asm-cris/types.h~slab-leak-detector include/asm-cris/types.h --- 25/include/asm-cris/types.h~slab-leak-detector 2005-03-02 08:30:59.0 -0800 +++ 25-akpm/include/asm-cris/types.h 2005-03-02 08:30:59.0 -0800 @@ -52,7 +52,7 @@ typedef unsigned long long u64; typedef u32 dma_addr_t; typedef u32 dma64_addr_t; -typedef unsigned int kmem_bufctl_t; +typedef unsigned long kmem_bufctl_t; #endif /* __ASSEMBLY__ */ diff -puN include/asm-frv/types.h~slab-leak-detector include/asm-frv/types.h --- 25/include/asm-frv/types.h~slab-leak-detector 2005-03-02 08:30:59.0 -0800 +++ 25-akpm/include/asm-frv/types.h 2005-03-02 08:30:59.0 -0800 @@ -65,7 +65,7 @@ typedef u64 u_quad_t; typedef u32 dma_addr_t; -typedef unsigned short kmem_bufctl_t; +typedef unsigned long kmem_bufctl_t; #endif /* __ASSEMBLY__ */ diff -puN include/asm-h8300/types.h~slab-leak-detector include/asm-h8300/types.h --- 25/include/asm-h8300/types.h~slab-leak-detector 2005-03-02 08:30:59.0 -0800 +++ 25-akpm/include/asm-h8300/types.h 2005-03-02 08:30:59.0 -0800 @@ -58,7 +58,7 @@ typedef u32 dma_addr_t; #define HAVE_SECTOR_T typedef u64 sector_t; -typedef unsigned int kmem_bufctl_t; +typedef unsigned long kmem_bufctl_t; #endif /* __KERNEL__ */ diff -puN include/asm-i386/types.h~slab-leak-detector include/asm-i386/types.h --- 25/include/asm-i386/types.h~slab-leak-detector 2005-03-02 08:30:59.0 -0800 +++ 25-akpm/include/asm-i386/types.h 2005-03-02 08:30:59.0 -0800 @@ -63,7 +63,7 @@ typedef u64 sector_t; #define HAVE_SECTOR_T #endif -typedef unsigned short kmem_bufctl_t; +typedef unsigned long kmem_bufctl_t; #endif /* __ASSEMBLY__ */ diff -puN include/asm-ia64/types.h~slab-leak-detector include/asm-ia64/types.h --- 25/include/asm-ia64/types.h~slab-leak-detector 2005-03-02 08:30:59.0 -0800 +++ 25-akpm/include/asm-ia64/types.h 2005-03-02 08:30:59.0 -0800 @@ -67,7 +67,7 @@ typedef __u64 u64; typedef u64 dma_addr_t; -typedef unsigned short kmem_bufctl_t; +typedef unsigned long kmem_bufctl_t; # endif /* __KERNEL__ */ #endif /* !__ASSEMBLY__ */ diff -puN include/asm-m32r/types.h~slab-leak-detector include/asm-m32r/types.h --- 25/include/asm-m32r/types.h~slab-leak-detector 2005-03-02 08:30:59.0 -0800 +++ 25-akpm/include/asm-m32r/types.h 2005-03-02 08:30:59.0 -0800 @@ -55,7 +55,7 @@ typedef unsigned long long u64; typedef u32 dma_addr_t; typedef u64 dma64_addr_t; -typedef unsigned short kmem_bufctl_t; +typedef unsigned long kmem_bufctl_t; #endif /* __ASSEMBLY__ */ diff -puN include/asm-m68k/types.h~slab-leak-detector include/asm-m68k/types.h --- 25/include/asm-m68k/types.h~slab-leak-detector 2005-03-02 08:30:59.0 -0800 +++ 25-akpm/include/asm-m68k/types.h 2005-03-02 08:30:59.0 -0800 @@ -60,7 +60,7 @@ typedef unsigned long long u64; typedef u32 dma_addr_t; typedef u32 dma64_addr_t; -typedef
Re: 2.6.11 vs DVB cx88 stuffs
On Thu, Mar 03, 2005 at 11:17:16PM -0800, Andrew Morton wrote: > > The reason this wasn't picked up is that neither `make allyesconfig' or > > `make allmodconfig' enables CONFIG_VIDEO_CX88_DVB or > > CONFIG_VIDEO_CX88_DVB_MODULE. > > > > For coverage purposes it would be excellent to fix that up too, please. > > Wise words, those. It's dependant on CONFIG_BROKEN. Remove that, and allmodconfig should pick it up. Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] Do ext2, jfs and reiserfs respect mount -o sync/dirsync option?
>All warnings boil down to a single cause: when these file systems are >mounted -o sync or dirsync, dirty blocks are still written out >asynchronously. It appears to me that these mount options don't have any >effect on these file systems. Is this the intended behavior? At least my HDD LED flashes regularly when I add -o sync... (Using `mount / -o remount,sync`) It may happen that FISC reads the disk before the write command even finished. With all the HD head movement optimization in the kernel (block layer, boiling down to TCQ/NCQ), this sounds possible. Jan Engelhardt -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Does linux kernel support little-endian on powerpc?
No it does not and its extremely unlikely we will ever support little-endian, the list of pains this causes is endless. - kumar On Mar 3, 2005, at 11:45 PM, David L wrote: Hi All, I know toolchain support the target powerpcle-elf. it enable the little-endian on powerpc. I see that there is -melf32ppc param for ld in arch/ppc/Makefile. Can I modify it to -melf32lppc? what will occur? Can kernel suport little-endian on powerpc well? thanks Jason - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11 vs DVB cx88 stuffs
On Thu, 03 Mar 2005 21:19:04 -0500, Gene Heskett <[EMAIL PROTECTED]> wrote: > Greetings; > > I've a new pcHDTV-3000 card, and I thought maybe it would > be a good idea to build the cx88 stuff in the DVB section > of a make xconfig. > > It doesn't build, spitting out this bailout: > > CC [M] drivers/media/video/cx88/cx88-cards.o > drivers/media/video/cx88/cx88-cards.c: In function `hauppauge_eeprom_dvb': > drivers/media/video/cx88/cx88-cards.c:694: error: `PLLTYPE_DTT7595' > undeclared (first use in this function) > drivers/media/video/cx88/cx88-cards.c:694: error: (Each undeclared identifier > is reported only once > drivers/media/video/cx88/cx88-cards.c:694: error: for each function it > appears in.) > drivers/media/video/cx88/cx88-cards.c:698: error: `PLLTYPE_DTT7592' > undeclared (first use in this function) > drivers/media/video/cx88/cx88-cards.c: In function `cx88_card_setup': > drivers/media/video/cx88/cx88-cards.c:856: error: `PLLTYPE_DTT7579' > undeclared (first use in this function) > make[4]: *** [drivers/media/video/cx88/cx88-cards.o] Error 1 > make[3]: *** [drivers/media/video/cx88] Error 2 > make[2]: *** [drivers/media/video] Error 2 FWIW, there is a similar, perhaps enough to be related, BugMe bug (#4269): http://bugzilla.kernel.org/show_bug.cgi?id=4269 I had contacted Gerd Knorr (who I've CC'ed this mail to, to bring it to his attention, as well as Michael Hunold) about the issue (as noted in the BugMe entry) and he said he had patches setup for 2.6.12. Gerd, would your patches fix these errors as well? 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] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
Andrew Morton wrote: Jeff Garzik <[EMAIL PROTECTED]> wrote: The boot param is rather lame, IMO, since it affects a -bunch- of laptops. But whatever... My main desktop (a recent Dell), running 2.6.11-rc4-mm1 needs i8042.nopnp=1 (sic. It got renamed) so I can type stuff too. (rerekicks self). I expect this machine would require i8042.noacpi=1 if it was running 2.6.11. Lots of machines are affected. It's a bit of a howler. Definitely a linux-release candidate then. On a side note, it would be nice to give you access to push things into the linux-release tree yourself. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] Do ext2, jfs and reiserfs respect mount -o sync/dirsync option?
On Thu, Mar 03, 2005 at 10:33:40PM -0800, Junfeng Yang wrote: > > Hi, > > FiSC (our file system checker) emits several warnings on ext2, jfs and > reiserfs, complaining that diretories or files are lost while FiSC > believes they should already be persistent on disk. (ext3 behaves > correctly.) > > All warnings boil down to a single cause: when these file systems are > mounted -o sync or dirsync, dirty blocks are still written out > asynchronously. It appears to me that these mount options don't have any > effect on these file systems. Is this the intended behavior? I don't believe so. The sync option should definitionally make calls to fsync for integrity redundant. This probably got broken ages ago for ext2 in one of the many buffer/page cache refactorings. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11 vs DVB cx88 stuffs
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> >
> > I've a new pcHDTV-3000 card, and I thought maybe it would
> > be a good idea to build the cx88 stuff in the DVB section
> > of a make xconfig.
> >
> > It doesn't build, spitting out this bailout:
> >
> >CC [M] drivers/media/video/cx88/cx88-cards.o
> > drivers/media/video/cx88/cx88-cards.c: In function `hauppauge_eeprom_dvb':
> > drivers/media/video/cx88/cx88-cards.c:694: error: `PLLTYPE_DTT7595'
> undeclared (first use in this function)
> > drivers/media/video/cx88/cx88-cards.c:694: error: (Each undeclared
> identifier is reported only once
> > drivers/media/video/cx88/cx88-cards.c:694: error: for each function it
> appears in.)
> > drivers/media/video/cx88/cx88-cards.c:698: error: `PLLTYPE_DTT7592'
> undeclared (first use in this function)
> > drivers/media/video/cx88/cx88-cards.c: In function `cx88_card_setup':
> > drivers/media/video/cx88/cx88-cards.c:856: error: `PLLTYPE_DTT7579'
> undeclared (first use in this function)
>
> OK, this is one for Gerd. Those identifiers just aren't anywhere in the
> tree.
>
OK, the below should get you going again. It fixes up a warning too.
> The reason this wasn't picked up is that neither `make allyesconfig' or
> `make allmodconfig' enables CONFIG_VIDEO_CX88_DVB or
> CONFIG_VIDEO_CX88_DVB_MODULE.
>
> For coverage purposes it would be excellent to fix that up too, please.
Wise words, those.
diff -puN drivers/media/dvb/frontends/cx22702.h~c8xx-cards-build-fix
drivers/media/dvb/frontends/cx22702.h
--- 25/drivers/media/dvb/frontends/cx22702.h~c8xx-cards-build-fix
2005-03-03 23:13:59.0 -0800
+++ 25-akpm/drivers/media/dvb/frontends/cx22702.h 2005-03-03
23:14:17.0 -0800
@@ -30,6 +30,10 @@
#include
+#define PLLTYPE_DTT7592 1
+#define PLLTYPE_DTT7595 2
+#define PLLTYPE_DTT7579 3
+
struct cx22702_config
{
/* the demodulator's i2c address */
diff -puN drivers/media/video/cx88/cx88-cards.c~c8xx-cards-build-fix
drivers/media/video/cx88/cx88-cards.c
--- 25/drivers/media/video/cx88/cx88-cards.c~c8xx-cards-build-fix
2005-03-03 23:15:09.0 -0800
+++ 25-akpm/drivers/media/video/cx88/cx88-cards.c 2005-03-03
23:15:35.0 -0800
@@ -707,6 +707,7 @@ static int hauppauge_eeprom_dvb(struct c
core->pll_addr = 0x61;
core->demod_addr = 0x43;
+ return 0;
}
#endif
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: are the io-schedulers per-device?
On Fri, Mar 04 2005, Florin Iucha wrote: > Hello, > > For a semester project I am experimenting with a new IO scheduler and I > was trying to set my scheduler to control a single device, to ease the > development and debugging, by using >echo "foo" > /sys/block/ubdc/queue/scheduler > Much to my suprise, this sets the scheduler for the other block > devices as well! Does this happen only to UML block devices? Do I need > to do anything to allow a per-device scheduler? Is the functionality > there, or is it in-progress? Am I reading too much in the fact that > the queue/scheduler is defined under each block device? It's per-queue. In general that is per-device, apparently that is not so for UML since it shares a queue for several devices. From a cleanliness and performance POV, it's is far better to have a queue per device instead of sharing, I would suggest fixing the uml block device. It looks pretty straight forward to do so, except for ubd_handler(). Which, btw, calls elv_next_request() without holding the queue lock! -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
Jeff Garzik <[EMAIL PROTECTED]> wrote: > > The boot param is rather lame, IMO, since it affects a -bunch- of > laptops. But whatever... My main desktop (a recent Dell), running 2.6.11-rc4-mm1 needs i8042.nopnp=1 (sic. It got renamed) so I can type stuff too. (rerekicks self). I expect this machine would require i8042.noacpi=1 if it was running 2.6.11. Lots of machines are affected. It's a bit of a howler. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
Chris Wright wrote: IMO, we have to rely on Dmitry's judgement. Is it critical (i.e. broke laptops how)? Can it be worked around with the i8042.noacpi boot param? If so, I don't think it fits the bill as critical. If it was critical for 2.6.11, I would think it's critical for 2.6.11.1. One would hope its at least tested on one affected laptop. The boot param is rather lame, IMO, since it affects a -bunch- of laptops. But whatever... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
* Andrew Morton ([EMAIL PROTECTED]) wrote: > Chris Wright <[EMAIL PROTECTED]> wrote: > > > > > And it's a temp-fix - it'll be addressed by other means in 2.6.12. > > > > > > What do we do? > > > > IMO, we have to rely on Dmitry's judgement. Is it critical (i.e. broke > > laptops how)? Can it be worked around with the i8042.noacpi boot param? > > If so, I don't think it fits the bill as critical. > > Well. It was critical for 2.6.11, but it didn't make it :( Ah, I see. > So people whose keyboards don't work need to either update to 2.6.11.1 or > add i8042.noacpi=1. > > But it's just a for-instance. And a good one to exercise the rules measuring how critical the patch is. In this case, I don't think it is if workaround is good enough, but could be convinced if Dmitry thinks otherwise. Anyway, time to pack, sleep a few and catch a plane back west later, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
Chris Wright <[EMAIL PROTECTED]> wrote: > > > And it's a temp-fix - it'll be addressed by other means in 2.6.12. > > > > What do we do? > > IMO, we have to rely on Dmitry's judgement. Is it critical (i.e. broke > laptops how)? Can it be worked around with the i8042.noacpi boot param? > If so, I don't think it fits the bill as critical. Well. It was critical for 2.6.11, but it didn't make it :( So people whose keyboards don't work need to either update to 2.6.11.1 or add i8042.noacpi=1. But it's just a for-instance. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: auditing subsystem
On Thu, 03 Mar 2005 22:18:11 PST, Russell Miller said: > I've been doing a lot of research on this, and I keep coming up with things > I notice there is a CONFIG_AUDIT option. Is this what I am looking for, and > how do I use it? /dev/audit seems not to work... oooh.. a victim^Wtester ;) CONFIG_AUDIT is indeed what you're looking for, in combination with the audit-0.6.5 userspace end just released. Mailing list is [EMAIL PROTECTED], visit http://www.redhat.com/mailman/listinfo/linux-audit for more info (Currently, there's still a add-on kernel patch for stuff that's not in the mainstream yet - but that's hopefully temporary.. ;) pgpQvwrzuXgzT.pgp Description: PGP signature
Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
* Andrew Morton ([EMAIL PROTECTED]) wrote: > Chris Wright <[EMAIL PROTECTED]> wrote: > > > > * Jeff Garzik ([EMAIL PROTECTED]) wrote: > > > Andrew Morton wrote: > > > >Chris Wright <[EMAIL PROTECTED]> wrote: > > > >>Olof's patch is in the linux-release tree, so this brings up a point > > > >>regarding merging. If the quick fix is to be replaced by a better fix > > > >>later (as in this case) there's some room for merge conflict. Does > > this > > > >>pose a problem for either -mm or Linus' tree? > > > > > > > >It depends who gets to Linus's tree first. If linux-release merges > > first, > > > >I just revert the temp fix while adding the real fix. But the temp fix > > > >should never have gone into Linus's tree in the first place. > > > > Consider it first patch in fixup series ;-) Actually I meant fix 1/2 == quick, fix 2/2 == more complete. > Here's the second, and this is much more critical. > > And it's untested. I'd rather it be tested.../me keeps wishing If it's untested, are we even sure it fixes the problem? Or are you worried about the umpteen other non-Dell laptops that could have problems with the patch? > And it's a temp-fix - it'll be addressed by other means in 2.6.12. > > What do we do? IMO, we have to rely on Dmitry's judgement. Is it critical (i.e. broke laptops how)? Can it be worked around with the i8042.noacpi boot param? If so, I don't think it fits the bill as critical. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
are the io-schedulers per-device?
Hello, For a semester project I am experimenting with a new IO scheduler and I was trying to set my scheduler to control a single device, to ease the development and debugging, by using echo "foo" > /sys/block/ubdc/queue/scheduler Much to my suprise, this sets the scheduler for the other block devices as well! Does this happen only to UML block devices? Do I need to do anything to allow a per-device scheduler? Is the functionality there, or is it in-progress? Am I reading too much in the fact that the queue/scheduler is defined under each block device? Thank you, florin PS: Please Cc: me as I am not subscribed. -- Don't question authority: they don't know either! signature.asc Description: Digital signature
Re: 2.6.11 vs DVB cx88 stuffs
Gene Heskett <[EMAIL PROTECTED]> wrote: > > I've a new pcHDTV-3000 card, and I thought maybe it would > be a good idea to build the cx88 stuff in the DVB section > of a make xconfig. > > It doesn't build, spitting out this bailout: > >CC [M] drivers/media/video/cx88/cx88-cards.o > drivers/media/video/cx88/cx88-cards.c: In function `hauppauge_eeprom_dvb': > drivers/media/video/cx88/cx88-cards.c:694: error: `PLLTYPE_DTT7595' > undeclared (first use in this function) > drivers/media/video/cx88/cx88-cards.c:694: error: (Each undeclared > identifier is reported only once > drivers/media/video/cx88/cx88-cards.c:694: error: for each function it > appears in.) > drivers/media/video/cx88/cx88-cards.c:698: error: `PLLTYPE_DTT7592' > undeclared (first use in this function) > drivers/media/video/cx88/cx88-cards.c: In function `cx88_card_setup': > drivers/media/video/cx88/cx88-cards.c:856: error: `PLLTYPE_DTT7579' > undeclared (first use in this function) OK, this is one for Gerd. Those identifiers just aren't anywhere in the tree. The reason this wasn't picked up is that neither `make allyesconfig' or `make allmodconfig' enables CONFIG_VIDEO_CX88_DVB or CONFIG_VIDEO_CX88_DVB_MODULE. For coverage purposes it would be excellent to fix that up too, please. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SATA] libata-dev queue updated
On Thu, Mar 03, 2005 at 11:09:26PM -0500, Jeff Garzik wrote: > Joerg Sommrey wrote: > >On Wed, Mar 02, 2005 at 05:43:59PM -0500, Jeff Garzik wrote: > > > >>Joerg Sommrey wrote: > >> > >>>Jeff Garzik wrote: > >>> > Patch: > http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/2.6.11-rc5-bk4-libata-dev1.patch.bz2 > >>> > >>> > >>>Still not usable here. The same errors as before when backing up: > >> > >>Please try 2.6.11 without any patches. > > > >Plain 2.6.11 doesn't work either. All of 2.6.10-ac11, 2.6.11-rc5, > >2.6.11-rc5 + 2.6.11-rc5-bk4-libata-dev1.patch and 2.6.11 fail with the > >same symptoms. > > > >Reverting to stable 2.6.10-ac8 :-) > > Does reverting the attached patch in 2.6.11 (apply with patch -R) fix > things? > Still the same with this patch reverted. -jo -- -rw-r--r-- 1 jo users 63 2005-03-04 07:32 /home/jo/.signature - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: auditing subsystem
* Russell Miller ([EMAIL PROTECTED]) wrote: > I've been doing a lot of research on this, and I keep coming up with things > that don't work, have been abandoned, or are almost impossible to find or get > working. So I'll ask here. Maybe one of the ultra-elightened linux gods > will have a ready answer. You'll have better luck using linux-audit list. > I want to be able to audit system calls - I want to log when files are > opened, > created, changed, deleted, etc. Preferably I would like to do it without > having to apply kernel patches, using vanilla (or close to vanilla) kernel. > If this isn't possible, my net preference is to use a module. If this isn't > possible, well, I'll do what I have to. No patches needed (although you will want 2.6.11 because the inode filter was busted, and you'll likely want to use it), for opened anyway. You'll need an additional auditfs patch for created/deleted/changed(for more than just knowing open w/ write access) and it's not a stable patch yet. > I notice there is a CONFIG_AUDIT option. Is this what I am looking for, and > how do I use it? /dev/audit seems not to work... You'll need auditd, auditctl, and some rules to capture what you care about. For example: To watch accesses to /etc/passwd (not creation/deletion events). # auditd # auditctl -a entry,possible -S open # auditctl -a exit,always -S open -F inode=(inode of /etc/passwd) -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[CHECKER] Do ext2, jfs and reiserfs respect mount -o sync/dirsync option?
Hi, FiSC (our file system checker) emits several warnings on ext2, jfs and reiserfs, complaining that diretories or files are lost while FiSC believes they should already be persistent on disk. (ext3 behaves correctly.) All warnings boil down to a single cause: when these file systems are mounted -o sync or dirsync, dirty blocks are still written out asynchronously. It appears to me that these mount options don't have any effect on these file systems. Is this the intended behavior? man mount shows: sync All I/O to the file system should be done synchronously. dirsync All directory updates within the file system should be done synchronously. This affects the following system calls: creat, link, unlink, symlink, mkdir, rmdir, mknod and rename. Any clafirication on this would be very helpful, -Junfeng - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
Andrew Morton wrote: That works as long as I don't have non-linux_release patches which depend upon earlier fixes. If that happens I have to wait until linux-release merges up. Hopefully linux-release pulls, and linux-release releases, will happen fairly quickly. Otherwise its value diminishes. Release early, release often Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH] Custom power states for non-ACPI systems
On Thursday 03 March 2005 8:49 pm, Nigel Cunningham wrote: > > > > ... the goal of letting the system use those low > > power modes more generally, without needing user(space) input to > > suggest that now would be a good time to conserve more milliWatts. > > > > Of course, on systems that don't swap (or swsusp) there may be > > dozens of different low-power "standby" states. I'm not sure it > > helps to try labeling them all through /sys/power/files. > > It seems to make a lot of sense to me for us to make a split between > capability/implementation and policy, and move the policy stuff to > userspace. But what's a "policy"? And what's its scope? When the device drivers can cheaply turn their clocks on/off depending on whether their hardware is in use, there's little point in having control knobs for that. And considering debug and testing, such knobs create pain and trouble. Yet each different clock that can be gated creates a different family of such low power "standby" states... all subtly different combinations of active clocks. I counted over six dozen clocks on one SOC; do the math, it's hard to justify userspace caring about that many states!! (Some characteristics may matter though, e.g. whether the 48 MHz PLL is currently active or not. If not, more aggressive power saving modes might be available.) There's a cost to having userspace make decisions. When that cost can exceed the power savings, it's probably best not to get it involved. There are policy decisions that probably make sense in userspace, like "backlight off"; and ones that certainly don't make sense there (like IMO almost all clock gating decisions). > Drivers could also interact with each other to communicate status > changes (eg USB drivers notify parent HUB of their removal). Actually it works the other way around: hub status change events are used to detect device removal, then the device gets told. I think most hotpluggable busses work that way: PCMCIA/CF, MMC, CardBus, FireWire, PCI Hotplug, and so on. > This is, of > course, the more complicated bit. Since this is the implementation (and > not policy), however, userspace doesn't need to be involved. This > separation should simplify things. My USB hub driver knows what its > children are via the driver model. It doesn't need to receive a message > from userspace to tell it to sleep because it has nothing to do. Right, but there are important PM scenarios lurking there. There's the example of USB mice autosuspending, to enable root hubs to suspend, allowing DMA to stop, and thus enabling C3 CPU mode, and saving 2 Watts on top of the power no longer being supplied to that bus-powered mouse. (And the same could be done for some other USB devices.) This is, you'll note, purely device power management ... it's all in the same ACPI system state, S0. (Though the mouse can probably be used to wake the system from S1, S2, or S3 later on ...) What we've discussed so far is that the only policy setting there would be a module parameter for the HID driver, saying whether to start that sequence after N seconds. For the other drivers, CONFIG_PM would seem to be enough of a request. > With an implementation along these lines, I think we'll have a good > basis for getting runtime power management and system states into a > usable state. Using DBUS to allow active policy (re)decisions could work, but I'd also like to see most PM policies not need to swap in DBUS. Sysfs is a fine place to record policy decisions (though the cost of each new attribute is less memory available for Real Work). Do you have examples of PM policies where a DBUS agent would need to make choices on the fly? - Dave > > Regards, > > Nigel > -- > Nigel Cunningham > Software Engineer, Canberra, Australia > http://www.cyclades.com > Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028; Mob: +61 (417) 100 574 > > Maintainer of Suspend2 Kernel Patches http://softwaresuspend.berlios.de > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11 ps/2 mouse is dead
On Friday 04 March 2005 00:52, Leonid Petrov wrote: > I upgraded from 2.6.10 to 2.6.11 using "make oldconfig" and my > Logitech ps/2 mouse is dead. cat /dev/input/mice shows > nothing. Nothing suspicios in /var/log/messages > The same mousce works fine with 2.6.10 > Does it work with i8042.noacpi kernel boot option? -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
Chris Wright <[EMAIL PROTECTED]> wrote:
>
> * Jeff Garzik ([EMAIL PROTECTED]) wrote:
> > Andrew Morton wrote:
> > >Chris Wright <[EMAIL PROTECTED]> wrote:
> > >>Olof's patch is in the linux-release tree, so this brings up a point
> > >>regarding merging. If the quick fix is to be replaced by a better fix
> > >>later (as in this case) there's some room for merge conflict. Does this
> > >>pose a problem for either -mm or Linus' tree?
> > >
> > >It depends who gets to Linus's tree first. If linux-release merges first,
> > >I just revert the temp fix while adding the real fix. But the temp fix
> > >should never have gone into Linus's tree in the first place.
>
> Consider it first patch in fixup series ;-)
Here's the second, and this is much more critical.
And it's untested.
And it's a temp-fix - it'll be addressed by other means in 2.6.12.
What do we do?
From: Dmitry Torokhov <[EMAIL PROTECTED]>
Some ACPI-related changes were recently made to i8042 discovery for ia64.
Unfortunately this broke a significant number of Dell laptops due to their
having incorrect BIOS tables.
So, for now, arrange for the new code to be ia64-only.
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/drivers/input/serio/i8042-x86ia64io.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff -puN drivers/input/serio/i8042-x86ia64io.h~i8042-pnp-workaround
drivers/input/serio/i8042-x86ia64io.h
--- 25/drivers/input/serio/i8042-x86ia64io.h~i8042-pnp-workaround
2005-03-03 13:34:49.0 -0800
+++ 25-akpm/drivers/input/serio/i8042-x86ia64io.h 2005-03-03
13:34:49.0 -0800
@@ -88,7 +88,7 @@ static struct dmi_system_id __initdata i
};
#endif
-#ifdef CONFIG_ACPI
+#if defined(__ia64__) && defined(CONFIG_ACPI)
#include
#include
@@ -281,7 +281,7 @@ static inline int i8042_platform_init(vo
i8042_kbd_irq = I8042_MAP_IRQ(1);
i8042_aux_irq = I8042_MAP_IRQ(12);
-#ifdef CONFIG_ACPI
+#if defined(__ia64__) && defined(CONFIG_ACPI)
if (i8042_acpi_init())
return -1;
#endif
@@ -300,7 +300,7 @@ static inline int i8042_platform_init(vo
static inline void i8042_platform_exit(void)
{
-#ifdef CONFIG_ACPI
+#if defined(__ia64__) && defined(CONFIG_ACPI)
i8042_acpi_exit();
#endif
}
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
* Jeff Garzik ([EMAIL PROTECTED]) wrote: > Andrew Morton wrote: > >Chris Wright <[EMAIL PROTECTED]> wrote: > >>Olof's patch is in the linux-release tree, so this brings up a point > >>regarding merging. If the quick fix is to be replaced by a better fix > >>later (as in this case) there's some room for merge conflict. Does this > >>pose a problem for either -mm or Linus' tree? > > > >It depends who gets to Linus's tree first. If linux-release merges first, > >I just revert the temp fix while adding the real fix. But the temp fix > >should never have gone into Linus's tree in the first place. Consider it first patch in fixup series ;-) > >If I merge before linux-release, I guess Linus has some conflict resolving > >to do when he pulls from linux-release. That's OK for an obvious > >two-liner, but would get out of control for more substantial things. > > > >Neither solution is acceptable, really. I suspect the idea of pulling > >linux-release into mainline won't work very well, and that making it a > >backport tree would be more practical. > > Maybe you're right, but I tend to think that "quick, get that fix out > immediately" fixes will appear before more substantial fixes. That is > certainly the way things have worked up until now. > > For the cases that we care about, putting that into linux-release and > then pulling would seem more appropriate. Yes, and this case was on the border of a newly existing system. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > Neither solution is acceptable, really. I suspect the idea of pulling > > linux-release into mainline won't work very well, and that making it a > > backport tree would be more practical. > > Maybe you're right, but I tend to think that "quick, get that fix out > immediately" fixes will appear before more substantial fixes. That is > certainly the way things have worked up until now. > > For the cases that we care about, putting that into linux-release and > then pulling would seem more appropriate. > > Remember, the linux-release tree for each release will slow down, and > eventually die off, as we progress towards the next release (where the > linux-2.6.x.y-1 tree will indeed die). Yup. But anyway, there's no point in overdesigning all this. Let's suck it and see. If it doesn't work we can populate linux-release by some other means. The downstream users of linux-release won't see any change as a result of that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > Olof's patch is in the linux-release tree, so this brings up a point > > regarding merging. If the quick fix is to be replaced by a better fix > > later (as in this case) there's some room for merge conflict. Does this > > pose a problem for either -mm or Linus' tree? > > Just need to make sure aware of this, when you push to Linus. > > In most cases, of dire fixes, they should just go into linux-release, > and then get pulled into linux-2.6. > > For a few cases, like this one, the quick fix will hit linux-release and > linux-2.6 before the better fix, so no big deal. > > In a few rare cases, you will need to create a "for-upstream" tree that > handles the conflict before it get pushed to Linus. As I say, it sounds dumb, but I'm sure you can make it work ;) The main person it affects is yours truly: bix:/usr/src/25> grep fix series | wc -l 162 And fixes which are 2.6.x.y material need to go mm->linux_release->linus. I drop them when they turn up in Linus's tree. That works as long as I don't have non-linux_release patches which depend upon earlier fixes. If that happens I have to wait until linux-release merges up. Again, it's manageable, but complex. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
auditing subsystem
I've been doing a lot of research on this, and I keep coming up with things that don't work, have been abandoned, or are almost impossible to find or get working. So I'll ask here. Maybe one of the ultra-elightened linux gods will have a ready answer. I want to be able to audit system calls - I want to log when files are opened, created, changed, deleted, etc. Preferably I would like to do it without having to apply kernel patches, using vanilla (or close to vanilla) kernel. If this isn't possible, my net preference is to use a module. If this isn't possible, well, I'll do what I have to. I notice there is a CONFIG_AUDIT option. Is this what I am looking for, and how do I use it? /dev/audit seems not to work... Thanks. If you can even point me a suitable FM to R, I'd be content. --Russell -- Russell Miller - [EMAIL PROTECTED] - Agoura, CA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
Andrew Morton wrote: Chris Wright <[EMAIL PROTECTED]> wrote: * Olof Johansson ([EMAIL PROTECTED]) wrote: Hi, On Thu, Mar 03, 2005 at 05:59:51PM -0800, Andrew Morton wrote: This patch doesn't seem right - current 2.6.11 has: return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC; The patch was against what Greg had already pushed into the linux-release.bkbits.net 2.6.11 tree, i.e. not what's in mainline. You're right, your revised patch would apply against mainline. However: This patch shouldn't go to mainline, since ppc-ppc64-abstract-cpu_feature-checks.patch in your tree takes care of the problem. I'd like the abstraction/cleanup patch to be merged upstream instead of the #ifdef hack once the tree opens up. Olof's patch is in the linux-release tree, so this brings up a point regarding merging. If the quick fix is to be replaced by a better fix later (as in this case) there's some room for merge conflict. Does this pose a problem for either -mm or Linus' tree? It depends who gets to Linus's tree first. If linux-release merges first, I just revert the temp fix while adding the real fix. But the temp fix should never have gone into Linus's tree in the first place. If I merge before linux-release, I guess Linus has some conflict resolving to do when he pulls from linux-release. That's OK for an obvious two-liner, but would get out of control for more substantial things. Neither solution is acceptable, really. I suspect the idea of pulling linux-release into mainline won't work very well, and that making it a backport tree would be more practical. Maybe you're right, but I tend to think that "quick, get that fix out immediately" fixes will appear before more substantial fixes. That is certainly the way things have worked up until now. For the cases that we care about, putting that into linux-release and then pulling would seem more appropriate. Remember, the linux-release tree for each release will slow down, and eventually die off, as we progress towards the next release (where the linux-2.6.x.y-1 tree will indeed die). Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
Chris Wright <[EMAIL PROTECTED]> wrote: > > * Olof Johansson ([EMAIL PROTECTED]) wrote: > > Hi, > > > > On Thu, Mar 03, 2005 at 05:59:51PM -0800, Andrew Morton wrote: > > > This patch doesn't seem right - current 2.6.11 has: > > > > > > return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC; > > > > The patch was against what Greg had already pushed into the > > linux-release.bkbits.net 2.6.11 tree, i.e. not what's in mainline. > > You're right, your revised patch would apply against mainline. > > > > However: This patch shouldn't go to mainline, since > > ppc-ppc64-abstract-cpu_feature-checks.patch in your tree takes care of > > the problem. I'd like the abstraction/cleanup patch to be merged upstream > > instead of the #ifdef hack once the tree opens up. > > Olof's patch is in the linux-release tree, so this brings up a point > regarding merging. If the quick fix is to be replaced by a better fix > later (as in this case) there's some room for merge conflict. Does this > pose a problem for either -mm or Linus' tree? It depends who gets to Linus's tree first. If linux-release merges first, I just revert the temp fix while adding the real fix. But the temp fix should never have gone into Linus's tree in the first place. If I merge before linux-release, I guess Linus has some conflict resolving to do when he pulls from linux-release. That's OK for an obvious two-liner, but would get out of control for more substantial things. Neither solution is acceptable, really. I suspect the idea of pulling linux-release into mainline won't work very well, and that making it a backport tree would be more practical. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
Chris Wright wrote: * Olof Johansson ([EMAIL PROTECTED]) wrote: Hi, On Thu, Mar 03, 2005 at 05:59:51PM -0800, Andrew Morton wrote: This patch doesn't seem right - current 2.6.11 has: return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC; The patch was against what Greg had already pushed into the linux-release.bkbits.net 2.6.11 tree, i.e. not what's in mainline. You're right, your revised patch would apply against mainline. However: This patch shouldn't go to mainline, since ppc-ppc64-abstract-cpu_feature-checks.patch in your tree takes care of the problem. I'd like the abstraction/cleanup patch to be merged upstream instead of the #ifdef hack once the tree opens up. Olof's patch is in the linux-release tree, so this brings up a point regarding merging. If the quick fix is to be replaced by a better fix later (as in this case) there's some room for merge conflict. Does this pose a problem for either -mm or Linus' tree? Just need to make sure aware of this, when you push to Linus. In most cases, of dire fixes, they should just go into linux-release, and then get pulled into linux-2.6. For a few cases, like this one, the quick fix will hit linux-release and linux-2.6 before the better fix, so no big deal. In a few rare cases, you will need to create a "for-upstream" tree that handles the conflict before it get pushed to Linus. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
* Olof Johansson ([EMAIL PROTECTED]) wrote: > Hi, > > On Thu, Mar 03, 2005 at 05:59:51PM -0800, Andrew Morton wrote: > > This patch doesn't seem right - current 2.6.11 has: > > > > return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC; > > The patch was against what Greg had already pushed into the > linux-release.bkbits.net 2.6.11 tree, i.e. not what's in mainline. > You're right, your revised patch would apply against mainline. > > However: This patch shouldn't go to mainline, since > ppc-ppc64-abstract-cpu_feature-checks.patch in your tree takes care of > the problem. I'd like the abstraction/cleanup patch to be merged upstream > instead of the #ifdef hack once the tree opens up. Olof's patch is in the linux-release tree, so this brings up a point regarding merging. If the quick fix is to be replaced by a better fix later (as in this case) there's some room for merge conflict. Does this pose a problem for either -mm or Linus' tree? thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.11 ps/2 mouse is dead
I upgraded from 2.6.10 to 2.6.11 using "make oldconfig" and my Logitech ps/2 mouse is dead. cat /dev/input/mice shows nothing. Nothing suspicios in /var/log/messages The same mousce works fine with 2.6.10 Any clues? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: RFD: Kernel release numbering
> You cannot have it both ways. Either the kernel needs > testers, or it is "stable". See how these are opposites? I think one of the fundamental problems is "either the kernel needs more features, or it needs stablization". You cannot have it both ways. With the current model, the kernel develops at a faster pace than testers can keep up with, and that's why you feel there aren't enough testers. Not everyone downloads a kernel every day or even every week. Just once a while. If you roll out a kernel, you need to give some time to people to test it out. However, with the current model the kernel keeps adding features, non-bug fixes, etc, _and completely abandons the previous one and moves on_. So what's the point of testing? When I download 2.6.9, 2.6.11 might have come out. Even if bug reports do not become obosolete, they are outpaced by new bugs. Agreed we need a balance. The problem is the 2.6 focuses too much on development than stablization. The old "stable release maintainer" model was completely abandoned. Surely that was not an exciting job, but people need it. Hua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Does linux kernel support little-endian on powerpc?
Hi All, I know toolchain support the target powerpcle-elf. it enable the little-endian on powerpc. I see that there is -melf32ppc param for ld in arch/ppc/Makefile. Can I modify it to -melf32lppc? what will occur? Can kernel suport little-endian on powerpc well? thanks Jason - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc5-mm1: reiser4 panic
On Fri, Mar 04, 2005 at 02:16:56AM +0100, Alexander Gran wrote: > Hi, > > after my external USB hdd disconnected itself reiser4 paniced. I dont think a > journalingfs should panic if its device fails.. Panicking is sometimes what you want. Panic can trigger a reboot and get the box back on its feet quickly. But going read-only on errors is a more sensible default policy, especially if you have other unrelated activities going on. Ext2 and ext3 have such an option. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Jochen Striepe <[EMAIL PROTECTED]> wrote: > > Hi, > > On 03 Mar 2005, Andrew Morton wrote: > > 2.6.x is making good progress but there have been a handful of prominent > > regressions which seem to be making people think that the whole process is > > bust. I don't believe that this has been proven yet. > > Sorry -- what you (with the vision of a kernel developer) are seeing > here surely is interesting, but it's not the point: > > The point is what the *users* think. Just in case it still hasn't been > made clear enough in this thread: If your user base gets the impression > the development process isn't reliable any longer, you won't get your > kernel tested as much as you want. You cannot have it both ways. Either the kernel needs testers, or it is "stable". See how these are opposites? We don't _need_ people to test stable kernels, because they're stable. (OK, we'll pick up on a few things, but we'd pick up on them if people were testing tip-of-tree, as well). The 2.6.x.y thing is a service to people who want 2.6.x with kinks ironed out. It's not particularly interesting or useful from a development POV, apart from its potential to attract a few people who are presently stuck on 2.4 or 2.6.crufty. > > So I hope the latest proposal really helps making releases contain fewer > surprises. > It won't help that at all. None of these proposals will increase testing of tip-of-tree. In fact the 2.6.x proposal may decrease that level of that testing, although probably not much. There is no complete answer to all of this, because there are competing needs. It's a question of balance. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: RFD: Kernel release numbering
Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > Am I right? All we're proposing here is a tree which has small fixups for > > reasonably serious problems. Almost without exception it would consist of > > backports. > > "thru-ports": commit to linux-2.6.x.y and get Linus to pull. This means that for patches which didn't come through -mm, their first exposure in a public tree will be when they pop up in our "most stable" tree. That's backwards. However it should be manageable, as long as linux-release is constrained to obviously-correct and its-no-more-broken-now-than-it-used-to-be 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/
Re: 2.6.11 compilation problem.
On Thu, Mar 03, 2005 at 08:39:33PM +0100, Christophe Lucas wrote: > Hi, > > Sorry if I waste your time, but I would recompile my kernel with this > version, and when it was time to DRM, compilation dead. > Perhaps I say mistakes, but it seems drivers/char/drm/gamma.h is not > present, which is needed by other parts such as gamma_drv.c > > Perhaps, it is my .config which is faulty :-( if it is : sorry. > ... > CONFIG_BROKEN=y > CONFIG_BROKEN_ON_SMP=y You told the kernel to try and compile broken drivers. They broke. End of story. Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: netdev-2.6 queue updated
Daniel Drake wrote: Jeff Garzik wrote: : o [netdrvr 8139cp] add PCI ID This one seems to be already present in 2.6.11 under a different name (PCI_DEVICE_ID_TTTECH_MC322). Also, the corresponding entry in pci_ids.h is not in the order of the file. BitKeeper will fix that up at merge time. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.11 compilation problem.
Hi, Sorry if I waste your time, but I would recompile my kernel with this version, and when it was time to DRM, compilation dead. Perhaps I say mistakes, but it seems drivers/char/drm/gamma.h is not present, which is needed by other parts such as gamma_drv.c Perhaps, it is my .config which is faulty :-( if it is : sorry. ~Christophe # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # CONFIG_CLEAN_COMPILE is not set CONFIG_BROKEN=y CONFIG_BROKEN_ON_SMP=y # # General setup # CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_HOTPLUG=y # CONFIG_IKCONFIG is not set CONFIG_EMBEDDED=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set CONFIG_M686=y # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set # CONFIG_X86_EMU486 is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_PPRO_FENCE=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=m CONFIG_X86_MCE_P4THERMAL=y CONFIG_TOSHIBA=m CONFIG_I8K=m CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # CONFIG_EDD=m # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y # CONFIG_HIGHPTE is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_HAVE_DEC_LOCK=y # CONFIG_REGPARM is not set # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_SOFTWARE_SUSPEND is not set # CONFIG_PM_DISK is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_FAN=m CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_THERMAL=m CONFIG_ACPI_ASUS=m CONFIG_ACPI_TOSHIBA=m # 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_X86_PM_TIMER=y # # APM (Advanced Power Management) BIOS Support # CONFIG_APM=m # CONFIG_APM_IGNORE_USER_SUSPEND is not set # CONFIG_APM_DO_ENABLE is not set # CONFIG_APM_CPU_IDLE is not set # CONFIG_APM_DISPLAY_BLANK is not set # CONFIG_APM_RTC_IS_GMT is not set # CONFIG_APM_ALLOW_INTS is not set # CONFIG_APM_REAL_MODE_POWER_OFF is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_PROC_INTF=m 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=m CONFIG_CPU_FREQ_GOV_USERSPACE=m # CONFIG_CPU_FREQ_24_API is not set CONFIG_CPU_FREQ_TABLE=m # # CPUFreq processor drivers # CONFIG_X86_ACPI_CPUFREQ=m # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set CONFIG_X86_POWERNOW_K6=m CONFIG_X86_POWERNOW_K7=m CONFIG_X86_POWERNOW_K8=m CONFIG_X86_GX_SUSPMOD=m CONFIG_X86_SPEEDSTEP_CENTRINO=m CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=y CONFIG_X86_SPEEDSTEP_ICH=m CONFIG_X86_SPEEDSTEP_SMI=m CONFIG_X86_P4_CLOCKMOD=m CONFIG_X86_SPEEDSTEP_LIB=m CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK=y CONFIG_X86_LONGRUN=m CONFIG_X86_LONGHAUL=m # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y
Re: [Alsa-devel] Re: intel 8x0 went silent in 2.6.11
Lee Revell wrote: If you want to complain, complain to the hardware manufacturers, who make devices where bit $foo means $bar in one hardware revision, and $baz in the next, and don't give us sufficient documentation to sort out the mess. That's not terribly productive. Life is what it is. We deal with it. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Thu, 2005-03-03 at 16:03 -0800, Andrew Morton wrote: > Or, to put it another way, we're getting a small number of irritating > regressions, mainly in device drivers which is giving the whole thing a bad > rep. Is there some way in which we can fix that problem without > reinventing the whole world? This seems to be a damn hard problem. For example I can't think of any reasonable release candidate process that would have prevented that guy's sound problem with the Thinkpad and the docking station. Without comprehensive hardware documentation, as long as there are more different types of hardware then there are people who can hack drivers, I think this will be an issue. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Thu, 3 Mar 2005, Thomas Gleixner wrote: > > It still does not solve the problem of "untested" releases. Users will > still ignore the linus-tree-rcX kernels. .. and maybe that problem is unsolvable. People certainly argued vehemently that anything we do to try to make test releases (renaming etc) won't help. So what do you do if you find an unsolvable problem? You don't solve it: you make sure it's not a show-stopper. So part of the idea of having the "other tree" is that it ends up solving the "hmm, we missed that detail" problem. And by _not_ giving it release numbers or any schedule at all, people can't _wait_ for it. Sneaky. That's my middle name. 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: Crash in ext3 while extracting 2.6.11 (on 2.6.11-rc5-something)
Hello,
> On Thu, Mar 03, 2005 at 02:10:04PM +0100, Jan Kara wrote:
> > Hello,
> >
> > >I've noticed that 2.6.11 is released, so I run (flawlessly) 'bk pull',
> > > and now I'm trying to export tree from 'bk' by doing 'bk export -tplain
> > > /tmp/linux-2.6.11'. Unfortunately I tried it twice, and twice it died
> > > with same crash in log_do_checkpoint (see below). Anybody has a clue
> > > what it could be? When I hit alt-sysrq-s, sync takes about 10 seconds,
> > > so box had to have lots of disk caches dirtied when crash occured.
> > >
> > > Box is dual opteron rev cg, kernel has enabled all possible debug
> > > options. Problem seems to occur on 2.6.11-rc4-something too, it just
> > > begins with crash in ext3_inode_dirty because I have rc4-something built
> > > without memory poisoning (probably).
> > >
> > > I've not noticed any other problems, and it was possible to extract
> > > 2.6.11-rc5-something on Monday with 2.6.11-rc4-something, which crashes
> > > now too. I'll run 'fsck -f', maybe it will help things a bit...
> > >
> > > Bootdata ok (command line is BOOT_IMAGE=Linux ro root=801 ramdisk=0
> > > console=tty0 console=ttyS0,115200 nmi_watchdog=2 psmouse_noext=1 verbose)
> > > Linux version 2.6.11-rc5-2065-64 ([EMAIL PROTECTED]) (gcc version 3.3.3
> > > (Debian 20040401)) #1 SMP Mon Feb 28 22:15:10 CET 2005
> > >
> > > stack segment: [1] PREEMPT SMP
> > > CPU 0
> > I don't see here a reason why the machine crashed (some NULL pointer
> > deref or what...). It would be useful to know it. Also could you run
> > gdb on vmlinux a find out where exactly in the function the oops
> > occured?
>
> It died because of dereferencing RBP which contained memory poisoning
> signature:
>
> 0x801d9996 : lock btsl $0x13,0x0(%rbp)
>
> apparently x86-64 generates #SS for %rbp non-canonical addresses too, like
> i386 does with %ebp segment overruns.
>
> Crash occured in bit_spin_trylock called by jbd_trylock_bh_state from
> log_do_checkpoint
> (fs/jbd/checkpoint.c:636), because jh2bh (jh->b_bh) returned poisoned pattern
> - apparently somebody else freed journal_head while we were holding pointer
> to it. No idea how it happened.
could you try applying attached patch and reproducing the problem? If
it is really oops because bh was set to NULL when freeing journal head
then the patch should catch it and write the place where we freed the
journal head...
Thanks
Honza
diff -rupX /home/jack/.kerndiffexclude linux-2.6.11/fs/jbd/checkpoint.c
linux-2.6.11-jhdebug/fs/jbd/checkpoint.c
--- linux-2.6.11/fs/jbd/checkpoint.c2005-03-03 18:58:29.0 +0100
+++ linux-2.6.11-jhdebug/fs/jbd/checkpoint.c2005-03-03 19:53:04.0
+0100
@@ -59,7 +59,7 @@ static int __try_to_free_cp_buf(struct j
JBUFFER_TRACE(jh, "remove from checkpoint list");
__journal_remove_checkpoint(jh);
jbd_unlock_bh_state(bh);
- journal_remove_journal_head(bh);
+ journal_remove_journal_head(bh, "__try_to_free_cp_buf");
BUFFER_TRACE(bh, "release");
__brelse(bh);
ret = 1;
@@ -182,7 +182,7 @@ static int __cleanup_transaction(journal
BUFFER_TRACE(bh, "remove from checkpoint");
__journal_remove_checkpoint(jh);
jbd_unlock_bh_state(bh);
- journal_remove_journal_head(bh);
+ journal_remove_journal_head(bh,
"__cleanup_transaction");
__brelse(bh);
ret = 1;
} else {
diff -rupX /home/jack/.kerndiffexclude linux-2.6.11/fs/jbd/commit.c
linux-2.6.11-jhdebug/fs/jbd/commit.c
--- linux-2.6.11/fs/jbd/commit.c2005-03-03 18:58:29.0 +0100
+++ linux-2.6.11-jhdebug/fs/jbd/commit.c2005-03-03 19:57:38.0
+0100
@@ -286,7 +286,7 @@ write_out_data:
goto write_out_data;
__journal_unfile_buffer(jh);
jbd_unlock_bh_state(bh);
- journal_remove_journal_head(bh);
+ journal_remove_journal_head(bh,
"commit_transaction_1");
put_bh(bh);
if (lock_need_resched(>j_list_lock)) {
spin_unlock(>j_list_lock);
@@ -327,7 +327,7 @@ write_out_data:
if (buffer_jbd(bh) && jh->b_jlist == BJ_Locked) {
__journal_unfile_buffer(jh);
jbd_unlock_bh_state(bh);
- journal_remove_journal_head(bh);
+ journal_remove_journal_head(bh, "commit_transaction_2");
put_bh(bh);
} else {
Re: IDE locking (was: Re: RFD: Kernel release numbering)
On Fri, Mar 04, 2005 at 12:44:16PM +1100, CaT wrote:
> The problems were weird. The fs I was copying from decided it was
> corrupt. Unmounting the partition and trying an fsck reported that it
> couldn't find the partition. After a reboot all was well and a fsck
> reported no problems.
Similar stuff with ac12 if dma is on on both drives.
Mar 4 15:15:55 nessie kernel: hdi: dma_timer_expiry: dma status == 0x21
Mar 4 15:16:10 nessie kernel: hdi: DMA timeout error
Mar 4 15:16:10 nessie kernel: hdi: dma timeout error: status=0x58 { DriveReady
SeekComplete DataRequest }
Mar 4 15:16:10 nessie kernel:
Mar 4 15:16:10 nessie kernel: ide: failed opcode was: unknown
Should be noted that hdi does not boot with multisec or dma on.
--
Red herrings strewn hither and yon.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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][10/10] verify_area cleanup : deprecate
Jesper> Eventually when this has been deprecated for a while I'll Jesper> send patches to completely remove the function (thoughts Jesper> on how long it should be deprecated first are welcome). I don't have an opinion on how long to wait before removing the function, but this patch should probably add an entry to Documentation/feature-removal.txt. - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: RFD: Kernel release numbering
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/03/2005 07:21 AM, Linus Torvalds wrote: > Comments? before you do this, we have to make -rc's real rc's. Seriously how can it be that there is a diff between the last rc and the "vanilla" release. Thats a no-goer in my opinion. Even if it is small things, there is a chance that it breaks. If there patches that have to be applied, because they are bugfixes, then make another rc before going live. And odd/even sub number won't help here anyway. People who get the kernel won't know it, there will be confusion, etc. I would stick with the current scheme, I see no big advantage in a special odd/even numbering. If there is a bugfix release, call it X.Y.Z.1 like for 2.6.8, rest of the bugfixing can be found in -ac/-as patchsets anyway. The time of using vanilla kernels is long over. Nowadays its more like, something, where you wait that a vendor gives you a kernel, or else you will shot your own foot off ... - -- [ Clemens Schwaighofer -=:~ ] [ TBWA\ && TEQUILA\ Japan IT Group ] [6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ] [ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ] [ http://www.tequila.co.jphttp://www.tbwajapan.co.jp ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCJ+W4jBz/yQjBxz8RAgnoAKCKGVcIujulCLyk8p3ole80RhhcOwCgyHSM tD2sZv+sCz7oG5MfokKh05c= =lnqT -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: problem with linux 2.6.11 and sa
On Thu, Mar 03, 2005 at 01:57:28PM -0500, George Georgalis wrote: > I recall a problem a while back with a pipe from > /proc/kmsg that was sent by root to a program with a > user uid. The fix was to run the logging program as > root. Has that protected pipe method been extended > since 2.6.8.1? > > I'm very defiantly seeing a problem with the 2.6.11 > kernel and my spamassassin setup. However, it's not > clear exactly where the problem is, seems like sa > but it might be 2.6.11 with daemontools + qmail + > QMAIL_QUEUE. Does reverting to 2.6.10 fix this behavior? Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11 vs DVB cx88 stuffs
On Thursday 03 March 2005 21:55, Randy.Dunlap wrote: >Gene Heskett wrote: >> Greetings; >> >> I've a new pcHDTV-3000 card, and I thought maybe it would >> be a good idea to build the cx88 stuff in the DVB section >> of a make xconfig. [...] >> This is from a freshly unpacked src tree for 2.6.11, with only the >> bk-ieee1394 patch applied. That doesn't touch this. >> >> Comments? >> >> Another patch needed maybe? > >Sure, some patch is needed. Let's ask the maintainer (cc-ed). > >BTW, to get this you had to enable CONFIG_BROKEN: > >config VIDEO_CX88_DVB > tristate "DVB Support for cx2388x based TV cards" > depends on VIDEO_CX88 && DVB_CORE && BROKEN > select VIDEO_BUF_DVB I hadn't made that connection between the CONFIG_BROKEN and that, Randy, so if thats the case, its of somewhat less than showstopper status AFAIAC. The card is, for watching never twice same color tv, working just fine once the cx88** & related stuffs are replaced by doing a make install in the pcHDTV tree, which replaces the following stuff in the /lib/modules/`uname -r`/kernel/drivers dir tree: btcx-risc.ko bttv.ko cx8800.ko cx88xx.ko tuner.ko v4l1-compat.ko v4l2-common.ko video-buf.ko At some point, it would be nice if this stuff was merged, but for the benefit of how many would depend on sales of this and similar hdtv cards. There is of course a cost vs benefits ratio to consider in any such merging endeavor. I have NDI how many users of this card there may be about, but suspect the user base is growing exponentially as 'flag day' approaches. Jack Steven Kelliher <[EMAIL PROTECTED]> could no doubt give a better accounting. Sales must be good though, the last order was large enough that he was able to negotiate a better price than the web page shows by a $20 bill. He passed that savings on to us. Thats always appreciated. :) -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: RFD: Kernel release numbering
On March 2, 2005 09:14 pm, Gene Heskett wrote: > One doesn't have to be a code monkey to do this 'canary' scene as long > as a bash script can be hacked up to do the majority of the work, I > have a couple of them that basicly make a new kernel install a no > brainer. Often under 30 minutes to being rebooted to a new rc from > going after the patch. I'm a casual user, and I'm happy to bang on the latest (-mm) kernels so long as my data doesn't get corrupted. But the process of downloading, patching, configuring, compiling, and installing a new kernel is a bit of a pain, requiring user intervention a number of times. It's enough that I don't update very often. I've just done a bit of looking for scripts to automate the process of installing a new kernel, and I haven't come up with much of much. So right now I'm writing my own. If there are tools to help automate this they need to be more prominent on www.kernel.org and www.kernelnewbies.org, to make casual testing even easier. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Custom power states for non-ACPI systems
Hi. On Fri, 2005-03-04 at 13:17, David Brownell wrote: > On Wednesday 02 March 2005 12:56 am, Pavel Machek wrote: > > > > If OMAP has "big sleep" and "deep sleep", why not simply map them to > > "standby" and "suspend-to-ram"? > > Or even "cpu idle". Entering power saving modes shouldn't be such > a Big Deal. Some of the variable scheduling timeout work has been > done specifically with the goal of letting the system use those low > power modes more generally, without needing user(space) input to > suggest that now would be a good time to conserve more milliWatts. > > Of course, on systems that don't swap (or swsusp) there may be > dozens of different low-power "standby" states. I'm not sure it > helps to try labeling them all through /sys/power/files. It seems to make a lot of sense to me for us to make a split between capability/implementation and policy, and move the policy stuff to userspace. Here's the proposal I'm slowly fleshing out: Two way communication between a userspace policy manager and kernel drivers is implemented via DBus. In this scheme, 'kernel drivers' doesn't just refer to the drivers for hardware. It refers to anything remotely power management related, including code to implement suspend-to-RAM, to disk or the like, ACPI drivers or code to implement system power states. The policy manager can enumerate devices and inter-relationships, capabilities, settings and status information, set and query policies and implementation results. The drivers can notify events. This communication doesn't use complicated structures or type definitions. Rather, all the nous regarding interpretation of the messages that are sent is in the policy manager and the drivers. One driver might say it's capable of states called "D0, D1 and D3", another (system) states called "Deep Sleep" and "Big Sleep". Nothing but the driver itself and userspace manager need to how to interpret & use these states. Inter-relationships between drivers are _not_ included in this information. The policy manager sets policy, the drivers deal with the specifics of implementing it. The userspace manager can in turn [en|dis]able capabilites and send a list of run-time states that the driver can move between according to its own logic (eg lack of active children) without notifying the userspace manager. This would fit in with your power modes above, even to the level of "cpu idle". The DBus support would also provide a means by which the userspace manager could be notified of events it might be interested in. Again, a generic format could be used, with the format depending upon the driver. These events might include 'no keypresses in the specified period' or 'I'm a new driver just loaded'. Support for system states works in a similar manner. Capabilities and configuration parameters for system states (suspend to ram, deep sleep etc) could be registered in a similar manner to the device drivers above, but the choice regarding entering them comes from the userspace manager. The code implementing the state interacts with drivers using the existing driver model which, by definition (it only deals with system states), overrides the runtime policy settings previously applied. DBus events could also come from userspace, such as window manager requesting hibernation or a userspace UPS driver notifying AC loss. Drivers could also interact with each other to communicate status changes (eg USB drivers notify parent HUB of their removal). This is, of course, the more complicated bit. Since this is the implementation (and not policy), however, userspace doesn't need to be involved. This separation should simplify things. My USB hub driver knows what its children are via the driver model. It doesn't need to receive a message from userspace to tell it to sleep because it has nothing to do. With an implementation along these lines, I think we'll have a good basis for getting runtime power management and system states into a usable state. Regards, Nigel -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028; Mob: +61 (417) 100 574 Maintainer of Suspend2 Kernel Patches http://softwaresuspend.berlios.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH, RFT] starfire net driver update
The starfire net driver was just updated to include the firmware that
Adaptec kindly GPL'd for us a while ago. The firmware is needed to
enable zero-copy.
Can someone with this card give it a test, to make sure all is still
working?
Particularly, if you could test an application that uses sendfile(2)
[zero-copy], that would be useful.
Jeff
#
# ChangeSet
# 2005/03/03 22:53:40-05:00 [EMAIL PROTECTED]
# [netdrvr starfire] Add GPL'd firmware, remove compat code
#
# Contributed by Ion Badulescu <[EMAIL PROTECTED]>,
# further fixed up by me.
#
diff -Nru a/drivers/net/starfire.c b/drivers/net/starfire.c
--- a/drivers/net/starfire.c2005-03-03 22:53:54 -05:00
+++ b/drivers/net/starfire.c2005-03-03 22:53:54 -05:00
@@ -2,7 +2,7 @@
/*
Written 1998-2000 by Donald Becker.
- Current maintainer is Ion Badulescu <[EMAIL PROTECTED]>. Please
+ Current maintainer is Ion Badulescu . Please
send all bug reports to me, and not to Donald Becker, as this code
has been heavily modified from Donald's original version.
@@ -129,12 +129,18 @@
- put the chip to a D3 slumber on driver unload
- added config option to enable/disable NAPI
-TODO: bugfixes (no bugs known as of right now)
+ LK1.4.2 (Ion Badulescu)
+ - finally added firmware (GPL'ed by Adaptec)
+ - removed compatibility code for 2.2.x
+
+TODO: - fix forced speed/duplexing code (broken a long time ago, when
+ somebody converted the driver to use the generic MII code)
+ - fix VLAN support
*/
#define DRV_NAME "starfire"
-#define DRV_VERSION"1.03+LK1.4.1"
-#define DRV_RELDATE"February 10, 2002"
+#define DRV_VERSION"1.03+LK1.4.2"
+#define DRV_RELDATE"January 19, 2005"
#include
#include
@@ -145,25 +151,15 @@
#include
#include
#include
+#include
+#include
+#include
+#include
#include /* Processor type for cache alignment.
*/
#include
#include
-/*
- * Adaptec's license for their drivers (which is where I got the
- * firmware files) does not allow one to redistribute them. Thus, we can't
- * include the firmware with this driver.
- *
- * However, should a legal-to-distribute firmware become available,
- * the driver developer would need only to obtain the firmware in the
- * form of a C header file.
- * Once that's done, the #undef below must be changed into a #define
- * for this driver to really use the firmware. Note that Rx/Tx
- * hardware TCP checksumming is not possible without the firmware.
- *
- * WANTED: legal firmware to include with this GPL'd driver.
- */
-#undef HAS_FIRMWARE
+#include "starfire_firmware.h"
/*
* The current frame processor firmware fails to checksum a fragment
* of length 1. If and when this is fixed, the #define below can be removed.
@@ -172,13 +168,7 @@
/*
* Define this if using the driver with the zero-copy patch
*/
-#if defined(HAS_FIRMWARE) && defined(MAX_SKB_FRAGS)
#define ZEROCOPY
-#endif
-
-#ifdef HAS_FIRMWARE
-#include "starfire_firmware.h"
-#endif /* HAS_FIRMWARE */
#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
#define VLAN_SUPPORT
@@ -202,11 +192,7 @@
The Starfire has a 512 element hash table based on the Ethernet CRC. */
static int multicast_filter_limit = 512;
/* Whether to do TCP/UDP checksums in hardware */
-#ifdef HAS_FIRMWARE
static int enable_hw_cksum = 1;
-#else
-static int enable_hw_cksum = 0;
-#endif
#define PKT_BUF_SZ 1536/* Size of each temporary Rx buffer.*/
/*
@@ -291,43 +277,15 @@
#define RX_DESC_ADDR_SIZE RxDescAddr32bit
#endif
-#ifdef MAX_SKB_FRAGS
#define skb_first_frag_len(skb)skb_headlen(skb)
#define skb_num_frags(skb) (skb_shinfo(skb)->nr_frags + 1)
-#else /* not MAX_SKB_FRAGS */
-#define skb_first_frag_len(skb)(skb->len)
-#define skb_num_frags(skb) 1
-#endif /* not MAX_SKB_FRAGS */
-
-/* 2.2.x compatibility code */
-#if LINUX_VERSION_CODE < 0x20300
-
-#include "starfire-kcomp22.h"
-
-#else /* LINUX_VERSION_CODE > 0x20300 */
-
-#include
-#include
-#include
-
-#include
-
-#define init_tx_timer(dev, func, timeout) \
- dev->tx_timeout = func; \
- dev->watchdog_timeo = timeout;
-#define kick_tx_timer(dev, func, timeout)
-
-#define netif_start_if(dev)
-#define netif_stop_if(dev)
-
-#define PCI_SLOT_NAME(pci_dev) pci_name(pci_dev)
-
-#endif /* LINUX_VERSION_CODE > 0x20300 */
#ifdef HAVE_NETDEV_POLL
#define init_poll(dev) \
+do { \
dev->poll = _poll; \
- dev->weight = max_interrupt_work;
+ dev->weight = max_interrupt_work; \
+} while (0)
#define netdev_rx(dev, ioaddr) \
do { \
u32 intr_enable; \
@@ -341,7 +299,7 @@
/* Paranoia check */ \
intr_enable = readl(ioaddr + IntrEnable); \
if (intr_enable & (IntrRxDone | IntrRxEmpty)) { \
- printk("%s: interrupt while in polling mode!\n",
dev->name); \
+ printk(KERN_INFO "%s:
Re: 2.6.11-rc5-mm1
* Jeff Dike ([EMAIL PROTECTED]) wrote: > [EMAIL PROTECTED] said: > > Thanks, I'll push that with rest of audit changes. > > Applies on top of your changes. > > Signed-off-by: Jeff Dike <[EMAIL PROTECTED]> Thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: RFD: Kernel release numbering
On Thu, 3 Mar 2005, Hua Zhong wrote: > > Do you consider having a real stable release maintainer again? No, this really is a different thing. This is not a "truly separate" parallell track, exactly because it would not actually get a life of its own. For it to make sense, it would not do any big changes, ie it would be _limited_ in a way that a real stable release would not. Also, since it would leave the old kernel behind when a new stable release comes along, it would not have any real independence in time either. Now, I think this "sucker tree" I'm talking about would be a great basis for somebody else then taking it _further_ (ie vendor stable trees), but it really is a fairly small step. > If you want someone to do the job, give him a title. It's a thankless and > boring job, and you can't make it worse by just hiding him somewhere. Actually, that was something I'd _avoid_ - make it non-glorious on purpose. In the kind of tree I envision, the _last_ thing we'd want is the maintainer looking at a big picture and feeling important. I'd be happiest if he was almost totally anonymous, because I think it's likely a boring job, but it's a boring job that _many_ people could do (ie to avoid burnign people out, make it be a stint of a couple of months, not a "crowning life work", and then you could probably have half a dozen people who are perfectly willing to take it on every once in a while. Ie I'd organize it like some of the "checkin committees" work for other projects that have nowhere _near_ as much work going on as Linux has. That seems to work well for small projects - and we can try to keep this "small" exactly by having the strict rules in place that would mean that 99% of all patches wouldn't even be a consideration. In other words, I'm really talking about something different from what you seem to envision. I think we should call the tree the "sucker tree", and if somebody wants to make a logo for it, make it be a penguin with a jokers' hat: exactly to remind people that it's not about the glory. (Maybe that's going overboard a bit ;) 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/
Problem with w6692 & kernel >=2.6.10
I have problem with w6692 (mISDN-2005-02-25) & kernel >=2.6.10 (with 2.6.9 is OK!) # lspci :01:07.0 Network controller: Winbond Electronics Corp W6692 (rev 01) # modprobe w6692pci protocol=2 FATAL: Error inserting w6692pci (/lib/modules/2.6.11/kernel/drivers/isdn/hardware/mISDN/w6692pci.ko): No such device log: CAPI Subsystem Rev 1.1.2.8 capi20: Rev 1.1.2.7: started up with major 68 (middleware+capifs) Modular ISDN Stack core $Revision: 1.23 $ mISDNd: kernel daemon started ISDN L1 driver version 1.11 ISDN L2 driver version 1.19 mISDN: DSS1 Rev. 1.26 Capi 2.0 driver file version 1.14 ISAC module $Revision: 1.16 $ Winbond W6692 PCI driver Rev. 1.12 ACPI: PCI interrupt :01:07.0[A] -> GSI 19 (level, high) -> IRQ 19 mISDN_w6692: found adapter Winbond W6692 at :01:07.0 W6692: Winbond W6692 version (0): W6692 V00 kcapi: Controller 1: mISDN1 attached mISDNd: test event done w6692: IRQ 19 count 4 kcapi: card 1 "mISDN1" ready. w6692 1 cards installed try_ok(13) try_wait(0) try_mult(0) try_inirq(0) irq_ok(4) irq_fail(0) release_l1 id 1 release_udss1 refcnt 1 l3(f39faa40) inst(f39faab8) kcapi: card 1 down. kcapi: Controller 1: mISDN1 unregistered - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Alsa-devel] Re: intel 8x0 went silent in 2.6.11
(I hope you don't mind me re-adding LKML because this illustrates an important point) On Thu, 2005-03-03 at 14:15 -0500, Mark Canter wrote: > Seems like the Q/A process is kind of borked if the below tests are known > but don't get applied before it gets released into the wild. We will never be able to get 100% of these before they get out the door, because the ALSA developers can't test on every possible hardware. And the group of users who test ALSA CVS and ALSA releases before they go in the kernel is small. That being said, you are 100% right. It is widely acknowledged that the release candidate process is broken. The solution is to fix the release candidate process, so more people try the -rcs. This is the only way to catch bugs like this before they get out. Please see the "release numbering" thread for some proposed solutions. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
On Thu, Mar 03, 2005 at 01:26:36PM -0500, Jeff Garzik wrote:
> Rene Rebe wrote:
> >Hi,
> >
> >
> >--- linux-2.6.11/drivers/md/raid6altivec.uc.vanilla2005-03-02
> >16:44:56.407107752 +0100
> >+++ linux-2.6.11/drivers/md/raid6altivec.uc2005-03-02
> >16:45:22.424152560 +0100
> >@@ -108,7 +108,7 @@
> > int raid6_have_altivec(void)
> > {
> > /* This assumes either all CPUs have Altivec or none does */
> >-return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
> >+return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;
>
>
> I nominate this as a candidate for linux-2.6.11 release branch. :)
Ok, I've fixed up the patch and applied it to a local tree that I've set
up to catch these things (it will live at
bk://kernel.bkbits.net:gregkh/linux-2.6.11.y until Chris Wright and I
set up how we are going to handle all of this.)
Feel free to start pointing stuff like this at me and chris (we'll also
be setting up an alias for it.)
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: proc/locaavg definition
On Thu, 3 Mar 2005 02:36:50 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > David Lang <[EMAIL PROTECTED]> wrote: > > > > from what I have been able to find under /Documentation /proc/loadavg is > > defined as giving three loadaverage numbers, 1 min, 5 min, 15 min. > > > > however as of 2.6.5ish timeframe there are a coupld of additional colums > > that do not appear to be documented > > > > the first is something #/# that could be # of running processes/total # of > > processes, but I can't find a definition of this anywhere > > number of currently ready-to-run threads > / > total number of threads in the machine > the pid of the most-recently-created thread. > > No idea why the last one is there. This refects the forking activity. How `heavy' the load is. -- Coywolf Qi Hunt Homepage http://sosdg.org/~coywolf/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Thu, 2005-03-03 at 18:08 +0100, Adrian Bunk wrote: > This only attacks part of the problem. It still does not solve the problem of "untested" releases. Users will still ignore the linus-tree-rcX kernels. So we move the real -rcX phase after the so called stable release. Doing -rcX from the "sucker" tree up to a stable release makes much more sense and would have more testers and get back lost confidence. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11 vs DVB cx88 stuffs
On Thursday 03 March 2005 21:45, Andrew Morton wrote: >Gene Heskett <[EMAIL PROTECTED]> wrote: >> I've a new pcHDTV-3000 card, and I thought maybe it would >> be a good idea to build the cx88 stuff in the DVB section >> of a make xconfig. >> >> It doesn't build, spitting out this bailout: >> >>CC [M] drivers/media/video/cx88/cx88-cards.o >> drivers/media/video/cx88/cx88-cards.c: In function >> `hauppauge_eeprom_dvb': drivers/media/video/cx88/cx88-cards.c:694: >> error: `PLLTYPE_DTT7595' undeclared (first use in this function) >> drivers/media/video/cx88/cx88-cards.c:694: error: (Each undeclared >> identifier is reported only once >> drivers/media/video/cx88/cx88-cards.c:694: error: for each >> function it appears in.) >> drivers/media/video/cx88/cx88-cards.c:698: error: >> `PLLTYPE_DTT7592' undeclared (first use in this function) >> drivers/media/video/cx88/cx88-cards.c: In function >> `cx88_card_setup': drivers/media/video/cx88/cx88-cards.c:856: >> error: `PLLTYPE_DTT7579' undeclared (first use in this function) >> make[4]: *** [drivers/media/video/cx88/cx88-cards.o] Error 1 >> make[3]: *** [drivers/media/video/cx88] Error 2 >> make[2]: *** [drivers/media/video] Error 2 > >.config, please. Attached. *After* turning that option back on. I'm running the one I built w/o that option. And, with a postinstall of the pcHDTV-1.6 stuff from Jack, the card is working in ntsc just fine. (No antenna yet & its not a 'cable ready' card) -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11 # Thu Mar 3 22:56:03 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # CONFIG_CLEAN_COMPILE is not set CONFIG_BROKEN=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_LOG_BUF_SHIFT=16 CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y # CONFIG_IKCONFIG_PROC is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_FUTEX=y CONFIG_EPOLL=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set 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 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y # CONFIG_X86_UP_APIC is not set CONFIG_X86_TSC=y # CONFIG_X86_MCE is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set CONFIG_X86_CPUID=y # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y CONFIG_HIGHPTE=y # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_HAVE_DEC_LOCK=y # CONFIG_REGPARM is not set # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced
Re: RFD: Kernel release numbering - an orthogonal solution
Linus Torvalds wrote: On Thu, 3 Mar 2005, Horst von Brand wrote: [I'm pulling bk daily, and have it mixed with the ipw tree too, so I'm just the kind of tester you are looking for... haven't seen any of the showstopper bugs everybody is talking about, or I'd have screamed.] Yeah, I wish everybody was like that. Sadly, it seems to be pretty rare to have people do weekly builds, much less daily. Daily builds is the holy grail for me, if just a small percentage of people did that, we'd be really well off.. Right not it's not even a "percentage", it's a very much self-selected small group of people, usually with what ends up actually being fairly similar high-end PC hardware. Now, I haven't actually gotten any complaints about 2.6.11 (apart from "gcc4 still has problems" with fairly trivial solutions), so maybe the whole cycle really worked out well this time, and I happened to choose a really bad time to bring up this discussion. Or maybe this discussion scared away people, and I just need to give it another week or two ;) Linus I suspect you don't mean 'everybody'. So who do you mean? Why isn't there some advice on www.kernel.org that says: Do you use the Linux kernel? _You_ can make it better!! Here's how you can help... and goes on to tell people how, depending on their familiarity and risk-aversion/linux-love ratio, they can install -mm kernels or -ck ones or -rc ones or -pre ones... and it explains clearly what the intent and promises around each one are and it explains the risks (probably in terms of likelihood of losing their digital photos!) and it tells them how to subscribe to linux-kernel-announce So they don't have to monitor lkml to know about them. Maybe people like Horst could publicise the way in which they automatically download and deploy kernels. I certainly wouldn't mind rebooting my desktop once a week to try a current kernel. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11 vs DVB cx88 stuffs
On Thursday 03 March 2005 21:55, Randy.Dunlap wrote: >Gene Heskett wrote: >> Greetings; >> >> I've a new pcHDTV-3000 card, and I thought maybe it would >> be a good idea to build the cx88 stuff in the DVB section >> of a make xconfig. >> >> It doesn't build, spitting out this bailout: >> >> CC [M] drivers/media/video/cx88/cx88-cards.o >> drivers/media/video/cx88/cx88-cards.c: In function >> `hauppauge_eeprom_dvb': drivers/media/video/cx88/cx88-cards.c:694: >> error: `PLLTYPE_DTT7595' undeclared (first use in this function) >> drivers/media/video/cx88/cx88-cards.c:694: error: (Each undeclared >> identifier is reported only once >> drivers/media/video/cx88/cx88-cards.c:694: error: for each >> function it appears in.) >> drivers/media/video/cx88/cx88-cards.c:698: error: >> `PLLTYPE_DTT7592' undeclared (first use in this function) >> drivers/media/video/cx88/cx88-cards.c: In function >> `cx88_card_setup': drivers/media/video/cx88/cx88-cards.c:856: >> error: `PLLTYPE_DTT7579' undeclared (first use in this function) >> make[4]: *** [drivers/media/video/cx88/cx88-cards.o] Error 1 >> make[3]: *** [drivers/media/video/cx88] Error 2 >> make[2]: *** [drivers/media/video] Error 2 >> >> This is from a freshly unpacked src tree for 2.6.11, with only the >> bk-ieee1394 patch applied. That doesn't touch this. >> >> Comments? >> >> Another patch needed maybe? > >Sure, some patch is needed. Let's ask the maintainer (cc-ed). > >BTW, to get this you had to enable CONFIG_BROKEN: > >config VIDEO_CX88_DVB > tristate "DVB Support for cx2388x based TV cards" > depends on VIDEO_CX88 && DVB_CORE && BROKEN > select VIDEO_BUF_DVB You're right of course Randy. Thats an option I hadn't canceled out of force of habit because at one point i needed a driver for the advansys scsi cards that you all had rendered an opinion that it was broken. IMO the maintainer had vanished. I looked at the code, but came to the conclusion I was looking at a bowl of spagetti. I'm no good at sorting stuff like that. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [SATA] libata-dev queue updated
Joerg Sommrey wrote:
On Wed, Mar 02, 2005 at 05:43:59PM -0500, Jeff Garzik wrote:
Joerg Sommrey wrote:
Jeff Garzik wrote:
Patch:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/2.6.11-rc5-bk4-libata-dev1.patch.bz2
Still not usable here. The same errors as before when backing up:
Please try 2.6.11 without any patches.
Plain 2.6.11 doesn't work either. All of 2.6.10-ac11, 2.6.11-rc5,
2.6.11-rc5 + 2.6.11-rc5-bk4-libata-dev1.patch and 2.6.11 fail with the
same symptoms.
Reverting to stable 2.6.10-ac8 :-)
Does reverting the attached patch in 2.6.11 (apply with patch -R) fix
things?
Jeff
diff -Nru a/drivers/scsi/sata_promise.c b/drivers/scsi/sata_promise.c
--- a/drivers/scsi/sata_promise.c 2005-03-01 23:39:08 -08:00
+++ b/drivers/scsi/sata_promise.c 2005-03-01 23:39:08 -08:00
@@ -156,10 +156,18 @@
board_2037x },
{ PCI_VENDOR_ID_PROMISE, 0x3376, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
board_2037x },
+ { PCI_VENDOR_ID_PROMISE, 0x3574, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+ board_2037x },
+ { PCI_VENDOR_ID_PROMISE, 0x3d75, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+ board_2037x },
+
{ PCI_VENDOR_ID_PROMISE, 0x3318, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
board_20319 },
{ PCI_VENDOR_ID_PROMISE, 0x3319, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
board_20319 },
+ { PCI_VENDOR_ID_PROMISE, 0x3d18, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+ board_20319 },
+
{ } /* terminate list */
};
@@ -406,9 +414,11 @@
return IRQ_NONE;
}
-spin_lock(_set->lock);
+ spin_lock(_set->lock);
-for (i = 0; i < host_set->n_ports; i++) {
+ writel(mask, mmio_base + PDC_INT_SEQMASK);
+
+ for (i = 0; i < host_set->n_ports; i++) {
VPRINTK("port %u\n", i);
ap = host_set->ports[i];
tmp = mask & (1 << (i + 1));
@@ -546,6 +556,7 @@
unsigned long base;
void *mmio_base;
unsigned int board_idx = (unsigned int) ent->driver_data;
+ int pci_dev_busy = 0;
int rc;
if (!printed_version++)
@@ -560,8 +571,10 @@
return rc;
rc = pci_request_regions(pdev, DRV_NAME);
- if (rc)
+ if (rc) {
+ pci_dev_busy = 1;
goto err_out;
+ }
rc = pci_set_dma_mask(pdev, ATA_DMA_MASK);
if (rc)
@@ -640,7 +653,8 @@
err_out_regions:
pci_release_regions(pdev);
err_out:
- pci_disable_device(pdev);
+ if (!pci_dev_busy)
+ pci_disable_device(pdev);
return rc;
}
Re: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
Hi,
Greg KH wrote:
Except the patch is malformed, and even after light editing, does not
apply to the 2.6.11 kernel :(
Sorry - to match linux-kernel style I pasted it from gvim into
thunderbird to make kernel folks happy. Here you find the patch as it
applies to 2.6.11 attached.
Yours,
--
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://www.exactcode.de/ | http://www.t2-project.org/
+49 (0)30 255 897 45
Tiny compile fix for the raid6 PowerPC/Altivec code.
- Rene Rebe <[EMAIL PROTECTED]>
--- linux-2.6.11/drivers/md/raid6altivec.uc.vanilla 2005-03-02
16:44:56.407107752 +0100
+++ linux-2.6.11/drivers/md/raid6altivec.uc 2005-03-02 16:45:22.424152560
+0100
@@ -108,7 +108,7 @@
int raid6_have_altivec(void)
{
/* This assumes either all CPUs have Altivec or none does */
- return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
+ return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;
}
#endif
Re: [Alsa-devel] Re: intel 8x0 went silent in 2.6.11
On Thu, 2005-03-03 at 14:06 -0500, Mark Canter wrote: > Correct, but if you want to use your headphones you would have to enable > headphones on your mixer, which would negate your speaker output through > your docking station's output. If you want to use the docking station > speakers, you would have to disable the headphones in order to get the > docking station speakers to work; no? If that is the case, then you would > still have to enable/disable each time you wanted to change the direction > of headphones/external speakers. Again, this is not the case under <= > 2.6.10 where it works regardless of enabling/disabling headphones. > > I'd hate to rant and rave here under something that has worked under 2.4.x > and <= 2.6.10. But this seems like a very un-userfriendly solution to > something that has had no issues for quite some time. In that case, what > deemed the change necessary? As far as I see the 8x0 driver added support > for ICH7. I'm sure there's more to it than just that, I just haven't > looked into it the rest of the way. Because the change was needed to make someone else's hardware work. It's a bug, bugs happen. If you want to complain, complain to the hardware manufacturers, who make devices where bit $foo means $bar in one hardware revision, and $baz in the next, and don't give us sufficient documentation to sort out the mess. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kernel/timer: fix msleep_interruptible() comment
Hi, Please consider applying. Description: The comment for msleep_interruptible() is wrong, as it will ignore wait-queue events, but will wake up early for signals. Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]> --- 2.6.11-kj-v/kernel/timer.c 2005-03-01 23:38:25.0 -0800 +++ 2.6.11-kj/kernel/timer.c2005-03-02 15:22:06.0 -0800 @@ -1589,7 +1589,7 @@ void msleep(unsigned int msecs) EXPORT_SYMBOL(msleep); /** - * msleep_interruptible - sleep waiting for waitqueue interruptions + * msleep_interruptible - sleep waiting for signals * @msecs: Time in milliseconds to sleep for */ unsigned long msleep_interruptible(unsigned int msecs) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Alsa-devel] Re: intel 8x0 went silent in 2.6.11
Correct, but if you want to use your headphones you would have to enable headphones on your mixer, which would negate your speaker output through your docking station's output. If you want to use the docking station speakers, you would have to disable the headphones in order to get the docking station speakers to work; no? If that is the case, then you would still have to enable/disable each time you wanted to change the direction of headphones/external speakers. Again, this is not the case under <= 2.6.10 where it works regardless of enabling/disabling headphones. I'd hate to rant and rave here under something that has worked under 2.4.x and <= 2.6.10. But this seems like a very un-userfriendly solution to something that has had no issues for quite some time. In that case, what deemed the change necessary? As far as I see the 8x0 driver added support for ICH7. I'm sure there's more to it than just that, I just haven't looked into it the rest of the way. On Thu, 3 Mar 2005, Lee Revell wrote: On Thu, 2005-03-03 at 13:46 -0500, Mark Canter wrote: You don't have to disable and re-enable it each time, if your system is configured correctly then your mixer settings will be saved. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
problem with linux 2.6.11 and sa
I recall a problem a while back with a pipe from /proc/kmsg that was sent by root to a program with a user uid. The fix was to run the logging program as root. Has that protected pipe method been extended since 2.6.8.1? I'm very defiantly seeing a problem with the 2.6.11 kernel and my spamassassin setup. However, it's not clear exactly where the problem is, seems like sa but it might be 2.6.11 with daemontools + qmail + QMAIL_QUEUE. A sure sign of it is no logs (with debug) for remote sa connections which score "0/0" and correct operation with local "cat spam.txt | spamc -R"; fix is to use the older kernel. SA has stopped stdout logging completely with 2.6.11 in addition to the all pass score. But the message seems to go through my temp queue (for testing) and sent on to my local MDA. I'm not sure if it's a sa problem with the kernel or the new kernel doing something new with pipes from tcp connections. Maybe the new kernel is not making files available (eg 0 bytes), until the writing pipe is closed? That would make my SA test a zero byte file, which would pass, close, become full, and the file piped to local MDA is full? ...humm then I'd get a score of "0/5"... this sounds like a SA problem with the new kernel, ideas? // George -- George Georgalis, systems architect, administrator Linux BSD IXOYE http://galis.org/george/ cell:646-331-2027 mailto:[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: 2.6.11 vs DVB cx88 stuffs
On Thursday 03 March 2005 18:45, Andrew Morton wrote: > Gene Heskett <[EMAIL PROTECTED]> wrote: > > I've a new pcHDTV-3000 card, and I thought maybe it would > > be a good idea to build the cx88 stuff in the DVB section > > of a make xconfig. > > > > It doesn't build, spitting out this bailout: > > > >CC [M] drivers/media/video/cx88/cx88-cards.o > > drivers/media/video/cx88/cx88-cards.c: In function > > `hauppauge_eeprom_dvb': drivers/media/video/cx88/cx88-cards.c:694: error: > > `PLLTYPE_DTT7595' undeclared (first use in this function) > > drivers/media/video/cx88/cx88-cards.c:694: error: (Each undeclared > > identifier is reported only once > > drivers/media/video/cx88/cx88-cards.c:694: error: for each function it > > appears in.) drivers/media/video/cx88/cx88-cards.c:698: error: > > `PLLTYPE_DTT7592' undeclared (first use in this function) > > drivers/media/video/cx88/cx88-cards.c: In function `cx88_card_setup': > > drivers/media/video/cx88/cx88-cards.c:856: error: `PLLTYPE_DTT7579' > > undeclared (first use in this function) make[4]: *** > > [drivers/media/video/cx88/cx88-cards.o] Error 1 > > make[3]: *** [drivers/media/video/cx88] Error 2 > > make[2]: *** [drivers/media/video] Error 2 > > .config, please. > - I have the same problem. Here is mine. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11 # Wed Mar 2 15:49:02 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # CONFIG_CLEAN_COMPILE is not set CONFIG_BROKEN=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_FUTEX=y CONFIG_EPOLL=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set 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 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y # CONFIG_HPET_TIMER is not set # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y # CONFIG_X86_UP_APIC is not set CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_MICROCODE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y # CONFIG_HIGHPTE is not set CONFIG_MATH_EMULATION=y CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_HAVE_DEC_LOCK=y # CONFIG_REGPARM is not set # # Power management options (ACPI, APM) # # CONFIG_PM is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=m CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_THERMAL=m CONFIG_ACPI_ASUS=m CONFIG_ACPI_IBM=m CONFIG_ACPI_TOSHIBA=m CONFIG_ACPI_BLACKLIST_YEAR=0 # 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_X86_PM_TIMER is not set CONFIG_ACPI_CONTAINER=m # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set
Re: RFD: Kernel release numbering
On Thu, 3 Mar 2005, Steven Rostedt wrote: On Thu, 2005-03-03 at 13:24 -0800, David Lang wrote: I don't think you are understanding the proposal You're probably right. :-) 2.6.11.y will be released as 2.6.12 is being developed. once 2.6.12 is released (or shortly after that if 2.6.12 ends up being a _real_ mess) 2.6.11.y will not get any additional releases (2.6.12.y will get released instead) as a result there will be no backports at all. if you want a feature that's introduced in 2.6.12 then you wait until you get a 2.6.12.y release that's good enough for you. I understand the no backports. That's a good thing. That's what I was trying to state (but was probably too long winded!). Lets see if this is what I believe is being proposed. 2.6.x would be the release with some number of features added. 2.6.x.y would include bug fixes only, that are under the strong rule of Linus to only be things that crash/hang the machine or nasty security exploits. 2.6.x+1 would be 2.6.x.(some y) also including features (from -rc or -mm) 2.6.x.z (where z is greater than the above "some y") only include the same level of fixes as with 2.6.x.y, with the parallel work of 2.6.x+1 still going on. Please correct me if I'm wrong here. this sounds like what I am understanding. also I think the expectation is that there aren't going to be more then 2-3 2.6.x.y releases so your comment of people waiting until y>5 won't apply Say after 2.6.x.3 has been released and 2.6.x+1 is now out, and someone finds a rare race condition that hangs the machine. A 2.6.x.4 would not be released? my understanding is that in general there would no be a 2.6.x.4 in this case (special cases can cause rules to be bent, a rare race condition probably wouldn't qualify, a remote root security hole probably would) Actually, the >5 was pretty pointless anyway. What I got from talking to people is that they wanted a release that only got fixes that would crash the machine, or cause a root exploit. That's what I thought Linus was trying to say. the trouble is that 'crash the machine' can include a HUGE number of the fixes that go into 2.6.x+1 and you just lost stability again David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: RFD: Kernel release numbering
Hi, On 03 Mar 2005, Andrew Morton wrote: > 2.6.x is making good progress but there have been a handful of prominent > regressions which seem to be making people think that the whole process is > bust. I don't believe that this has been proven yet. Sorry -- what you (with the vision of a kernel developer) are seeing here surely is interesting, but it's not the point: The point is what the *users* think. Just in case it still hasn't been made clear enough in this thread: If your user base gets the impression the development process isn't reliable any longer, you won't get your kernel tested as much as you want. Please remember why this thread started. It was a proposal to get more users testing the rc kernels. So I hope the latest proposal really helps making releases contain fewer surprises. Greetings, Jochen. -- All I want is a warm bed and a kind word and unlimited power. -- Ashleigh Brilliant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Page fault scalability patch V18: Drop first acquisition of ptl
Christoph Lameter <[EMAIL PROTECTED]> wrote: > > On Wed, 2 Mar 2005, Andrew Morton wrote: > > > > This is not relevant since it only deals with file pages. > > > > OK. And CONFIG_DEBUG_PAGEALLOC? > > Its a debug feature that can be fixed if its broken. It's broken. A fix would be to restore the get_page() if CONFIG_DEBUG_PAGEALLOC. Not particularly glorious.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: RFD: Kernel release numbering
On Thu, 2005-03-03 at 00:21 -0500, Dave Jones wrote: > compile time regressions we should be able to nail down fairly easily. > (someone from OSDL is already doing compile stats and such on each release > [too bad they're mostly incomprehensible to the casual viewer]) Dave, I'm the "someone from OSDL". I agree that the compile stats and error/warning regresssions can be a little challenging to grock for the casual observer. Is it content or formatting that would help the casual viewer? John > The bigger problem is runtime testing. If things aren't getting the > exposure they need, we're going to get screwed over by something or other > every time Linus bk pull's some random driver repo. > > 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/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86_64: 32bit emulation problems
On Thursday 03 March 2005 10:19, Andi Kleen wrote: > On Wed, Mar 02, 2005 at 08:53:07AM -0800, Trond Myklebust wrote: > > on den 02.03.2005 Klokka 12:33 (+0100) skreiv Bernd Schubert: > > > > I can see no good reason for truncating inode number values on > > > > platforms that actually do support 64-bit inode numbers, but I can > > > > see several > > > > > > Well, at least we would have a reason ;) > > > > A 32-bit emulation mode is clearly a "platform" which does NOT support > > 64-bit inode numbers, however there is (currently) no way for the kernel > > to detect that you are running that. Any extra truncation should > > therefore ideally be done by the emulation layer rather than the kernel > > itself. > > The problem here is that glibc uses stat64() which supports > 64bit inode numbers. But glibc does the overflow checking itself > and generates the EOVERFLOW in user space. Nothing we can do > about that. The 64bit inodes work under 32bit too, so your > code checking for 64bitness is totally bogus. > > The old stat interface doesn't check that case currently either > (will fix that), but that's not the problem here. > > But in general the emulation layer cannot do truncation because > it doesn't know if it is ok to do for the low level file system. > If anything this has to be done in the fs. > So what do you actually suggest? On the one hand you say even 32bit userspace supports 64bit inodes, if it wants. On the other hand you say the truncation needs to be done on file system level. To my mind this is contradicting, the first statement suggests to do the truncation in userspace, the second says it can only be done in the kernel? Cheers, Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: RFD: Kernel release numbering
On Thu, Mar 03, 2005 at 01:49:50PM -0800, John Cherry wrote: > On Thu, 2005-03-03 at 00:21 -0500, Dave Jones wrote: > > > compile time regressions we should be able to nail down fairly easily. > > (someone from OSDL is already doing compile stats and such on each release > > [too bad they're mostly incomprehensible to the casual viewer]) > > Dave, I'm the "someone from OSDL". I agree that the compile stats and > error/warning regresssions can be a little challenging to grock for the > casual observer. Is it content or formatting that would help the casual > viewer? I don't have one handy to quote from, but personally I find there are two problems with what's currently presented. 1 - information overload. It's just a screenfull of numbers. 2 - the column headings were non-obvious iirc. Or maybe I'm just dumb and didn't look at them long enough. So it could just need some formatting tweaks to make it more palatable. Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > That is all inappropriate activity for a 2.6.x.y tree as it is being > > proposed. > > > > Am I right? All we're proposing here is a tree which has small fixups for > > reasonably serious problems. Almost without exception it would consist of > > backports. > > "thru-ports": commit to linux-2.6.x.y and get Linus to pull. But a subset of these fixes (such as Olaf's ppc raid6 fix) are not-for-Linus. Otherwise I guess it'll work - we can try it and see. Can we get a commits-list running for linux-release please? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11 vs DVB cx88 stuffs
Gene Heskett wrote: Greetings; I've a new pcHDTV-3000 card, and I thought maybe it would be a good idea to build the cx88 stuff in the DVB section of a make xconfig. It doesn't build, spitting out this bailout: CC [M] drivers/media/video/cx88/cx88-cards.o drivers/media/video/cx88/cx88-cards.c: In function `hauppauge_eeprom_dvb': drivers/media/video/cx88/cx88-cards.c:694: error: `PLLTYPE_DTT7595' undeclared (first use in this function) drivers/media/video/cx88/cx88-cards.c:694: error: (Each undeclared identifier is reported only once drivers/media/video/cx88/cx88-cards.c:694: error: for each function it appears in.) drivers/media/video/cx88/cx88-cards.c:698: error: `PLLTYPE_DTT7592' undeclared (first use in this function) drivers/media/video/cx88/cx88-cards.c: In function `cx88_card_setup': drivers/media/video/cx88/cx88-cards.c:856: error: `PLLTYPE_DTT7579' undeclared (first use in this function) make[4]: *** [drivers/media/video/cx88/cx88-cards.o] Error 1 make[3]: *** [drivers/media/video/cx88] Error 2 make[2]: *** [drivers/media/video] Error 2 This is from a freshly unpacked src tree for 2.6.11, with only the bk-ieee1394 patch applied. That doesn't touch this. Comments? Another patch needed maybe? Sure, some patch is needed. Let's ask the maintainer (cc-ed). BTW, to get this you had to enable CONFIG_BROKEN: config VIDEO_CX88_DVB tristate "DVB Support for cx2388x based TV cards" depends on VIDEO_CX88 && DVB_CORE && BROKEN select VIDEO_BUF_DVB -- ~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/
[PATCH][2/10] verify_area cleanup : drivers part 2
This patch converts the second half of drivers from verify_area to
access_ok.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
diff -urp linux-2.6.11-orig/drivers/mtd/mtdchar.c
linux-2.6.11/drivers/mtd/mtdchar.c
--- linux-2.6.11-orig/drivers/mtd/mtdchar.c 2005-03-02 08:38:13.0
+0100
+++ linux-2.6.11/drivers/mtd/mtdchar.c 2005-03-03 22:51:20.0 +0100
@@ -285,12 +285,12 @@ static int mtd_ioctl(struct inode *inode
size = (cmd & IOCSIZE_MASK) >> IOCSIZE_SHIFT;
if (cmd & IOC_IN) {
- ret = verify_area(VERIFY_READ, argp, size);
- if (ret) return ret;
+ if (!access_ok(VERIFY_READ, argp, size))
+ return -EFAULT;
}
if (cmd & IOC_OUT) {
- ret = verify_area(VERIFY_WRITE, argp, size);
- if (ret) return ret;
+ if (!access_ok(VERIFY_WRITE, argp, size))
+ return -EFAULT;
}
switch (cmd) {
@@ -389,7 +389,8 @@ static int mtd_ioctl(struct inode *inode
if (!mtd->write_oob)
ret = -EOPNOTSUPP;
else
- ret = verify_area(VERIFY_READ, buf.ptr, buf.length);
+ ret = access_ok(VERIFY_READ, buf.ptr,
+ buf.length) ? 0 : EFAULT;
if (ret)
return ret;
@@ -428,7 +429,8 @@ static int mtd_ioctl(struct inode *inode
if (!mtd->read_oob)
ret = -EOPNOTSUPP;
else
- ret = verify_area(VERIFY_WRITE, buf.ptr, buf.length);
+ ret = access_ok(VERIFY_WRITE, buf.ptr,
+ buf.length) ? 0 : -EFAULT;
if (ret)
return ret;
diff -urp linux-2.6.11-orig/drivers/net/wireless/orinoco.c
linux-2.6.11/drivers/net/wireless/orinoco.c
--- linux-2.6.11-orig/drivers/net/wireless/orinoco.c2005-03-02
08:38:33.0 +0100
+++ linux-2.6.11/drivers/net/wireless/orinoco.c 2005-03-03 22:51:20.0
+0100
@@ -2553,9 +2553,8 @@ static int orinoco_ioctl_getiwrange(stru
TRACE_ENTER(dev->name);
- err = verify_area(VERIFY_WRITE, rrq->pointer, sizeof(range));
- if (err)
- return err;
+ if (!access_ok(VERIFY_WRITE, rrq->pointer, sizeof(range)))
+ return -EFAULT;
rrq->length = sizeof(range);
diff -urp linux-2.6.11-orig/drivers/pcmcia/ds.c linux-2.6.11/drivers/pcmcia/ds.c
--- linux-2.6.11-orig/drivers/pcmcia/ds.c 2005-03-02 08:38:17.0
+0100
+++ linux-2.6.11/drivers/pcmcia/ds.c2005-03-03 22:51:28.0 +0100
@@ -1099,17 +1099,15 @@ static int ds_ioctl(struct inode * inode
return -EPERM;
if (cmd & IOC_IN) {
- err = verify_area(VERIFY_READ, uarg, size);
- if (err) {
- ds_dbg(3, "ds_ioctl(): verify_read = %d\n", err);
- return err;
+ if (!access_ok(VERIFY_READ, uarg, size)) {
+ ds_dbg(3, "ds_ioctl(): verify_read = %d\n", -EFAULT);
+ return -EFAULT;
}
}
if (cmd & IOC_OUT) {
- err = verify_area(VERIFY_WRITE, uarg, size);
- if (err) {
- ds_dbg(3, "ds_ioctl(): verify_write = %d\n", err);
- return err;
+ if (!access_ok(VERIFY_WRITE, uarg, size)) {
+ ds_dbg(3, "ds_ioctl(): verify_write = %d\n", -EFAULT);
+ return -EFAULT;
}
}
buf = kmalloc(sizeof(ds_ioctl_arg_t), GFP_KERNEL);
diff -urp linux-2.6.11-orig/drivers/s390/net/ctctty.c
linux-2.6.11/drivers/s390/net/ctctty.c
--- linux-2.6.11-orig/drivers/s390/net/ctctty.c 2005-03-02 08:38:10.0
+0100
+++ linux-2.6.11/drivers/s390/net/ctctty.c 2005-03-03 22:51:22.0
+0100
@@ -778,11 +778,10 @@ ctc_tty_ioctl(struct tty_struct *tty, st
printk(KERN_DEBUG "%s%d ioctl TIOCSERGETLSR\n",
CTC_TTY_NAME,
info->line);
#endif
- error = verify_area(VERIFY_WRITE, (void __user *) arg,
sizeof(uint));
- if (error)
- return error;
- else
+ if (access_ok(VERIFY_WRITE, (void __user *) arg,
sizeof(uint)))
return ctc_tty_get_lsr_info(info, (uint __user
*) arg);
+ else
+ return -EFAULT;
default:
#ifdef CTC_DEBUG_MODEM_IOCTL
printk(KERN_DEBUG "UNKNOWN ioctl 0x%08x on %s%d\n", cmd,
diff -urp linux-2.6.11-orig/drivers/sbus/char/aurora.c
linux-2.6.11/drivers/sbus/char/aurora.c
--- linux-2.6.11-orig/drivers/sbus/char/aurora.c2005-03-02
08:37:49.0 +0100
+++ linux-2.6.11/drivers/sbus/char/aurora.c 2005-03-03 22:51:22.0
+0100
@@ -1887,14 +1887,12 @@ extern int aurora_get_serial_info(struct
{
[PATCH][1/10] verify_area cleanup : drivers part 1
This patch converts the first half of drivers from verify_area to
access_ok.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
diff -urp linux-2.6.11-orig/drivers/block/nbd.c linux-2.6.11/drivers/block/nbd.c
--- linux-2.6.11-orig/drivers/block/nbd.c 2005-03-02 08:37:50.0
+0100
+++ linux-2.6.11/drivers/block/nbd.c2005-03-03 22:51:28.0 +0100
@@ -38,7 +38,7 @@
* 03-06-24 Cleanup PARANOIA usage & code. <[EMAIL PROTECTED]>
* 04-02-19 Remove PARANOIA, plus various cleanups (Paul Clements)
* possible FIXME: make set_sock / set_blksize / set_size / do_it one syscall
- * why not: would need verify_area and friends, would share yet another
+ * why not: would need access_ok and friends, would share yet another
* structure with userland
*/
diff -urp linux-2.6.11-orig/drivers/block/viodasd.c
linux-2.6.11/drivers/block/viodasd.c
--- linux-2.6.11-orig/drivers/block/viodasd.c 2005-03-02 08:37:50.0
+0100
+++ linux-2.6.11/drivers/block/viodasd.c2005-03-03 22:51:28.0
+0100
@@ -250,7 +250,6 @@ static int viodasd_release(struct inode
static int viodasd_ioctl(struct inode *ino, struct file *fil,
unsigned int cmd, unsigned long arg)
{
- int err;
unsigned char sectors;
unsigned char heads;
unsigned short cylinders;
@@ -263,9 +262,8 @@ static int viodasd_ioctl(struct inode *i
geo = (struct hd_geometry *)arg;
if (geo == NULL)
return -EINVAL;
- err = verify_area(VERIFY_WRITE, geo, sizeof(*geo));
- if (err)
- return err;
+ if (!access_ok(VERIFY_WRITE, geo, sizeof(*geo)))
+ return -EFAULT;
gendisk = ino->i_bdev->bd_disk;
d = gendisk->private_data;
sectors = d->sectors;
diff -urp linux-2.6.11-orig/drivers/bluetooth/hci_vhci.c
linux-2.6.11/drivers/bluetooth/hci_vhci.c
--- linux-2.6.11-orig/drivers/bluetooth/hci_vhci.c 2005-03-02
08:38:26.0 +0100
+++ linux-2.6.11/drivers/bluetooth/hci_vhci.c 2005-03-03 22:51:28.0
+0100
@@ -157,7 +157,7 @@ static ssize_t hci_vhci_chr_write(struct
{
struct hci_vhci_struct *hci_vhci = (struct hci_vhci_struct *)
file->private_data;
- if (verify_area(VERIFY_READ, buf, count))
+ if (!access_ok(VERIFY_READ, buf, count))
return -EFAULT;
return hci_vhci_get_user(hci_vhci, buf, count);
@@ -222,7 +222,7 @@ static ssize_t hci_vhci_chr_read(struct
continue;
}
- if (!verify_area(VERIFY_WRITE, buf, count))
+ if (access_ok(VERIFY_WRITE, buf, count))
ret = hci_vhci_put_user(hci_vhci, skb, buf, count);
else
ret = -EFAULT;
diff -urp linux-2.6.11-orig/drivers/cdrom/cdu31a.c
linux-2.6.11/drivers/cdrom/cdu31a.c
--- linux-2.6.11-orig/drivers/cdrom/cdu31a.c2005-03-02 08:38:13.0
+0100
+++ linux-2.6.11/drivers/cdrom/cdu31a.c 2005-03-03 22:51:28.0 +0100
@@ -2769,7 +2769,6 @@ static int scd_dev_ioctl(struct cdrom_de
unsigned int cmd, unsigned long arg)
{
void __user *argp = (void __user *)arg;
- int i;
switch (cmd) {
case CDROMREADAUDIO:/* Read 2352 byte audio tracks and 2340 byte
@@ -2790,10 +2789,9 @@ static int scd_dev_ioctl(struct cdrom_de
return 0;
}
- i = verify_area(VERIFY_WRITE, ra.buf,
- CD_FRAMESIZE_RAW * ra.nframes);
- if (i < 0)
- return i;
+ if (!access_ok(VERIFY_WRITE, ra.buf,
+ CD_FRAMESIZE_RAW * ra.nframes))
+ return -EFAULT;
if (ra.addr_format == CDROM_LBA) {
if ((ra.addr.lba >=
diff -urp linux-2.6.11-orig/drivers/cdrom/sbpcd.c
linux-2.6.11/drivers/cdrom/sbpcd.c
--- linux-2.6.11-orig/drivers/cdrom/sbpcd.c 2005-03-02 08:37:49.0
+0100
+++ linux-2.6.11/drivers/cdrom/sbpcd.c 2005-03-03 22:51:28.0 +0100
@@ -4266,9 +4266,9 @@ static int sbpcd_dev_ioctl(struct cdrom_
sizeof(struct cdrom_read_audio)))
RETURN_UP(-EFAULT);
if (read_audio.nframes < 0 ||
read_audio.nframes>current_drive->sbp_audsiz) RETURN_UP(-EINVAL);
- i=verify_area(VERIFY_WRITE, read_audio.buf,
- read_audio.nframes*CD_FRAMESIZE_RAW);
- if (i) RETURN_UP(i);
+ if (!access_ok(VERIFY_WRITE, read_audio.buf,
+ read_audio.nframes*CD_FRAMESIZE_RAW))
+ RETURN_UP(-EFAULT);
if
Re: radeonfb blanks my monitor
On Thu, 2005-03-03 at 12:38 -0300, Frédéric L. W. Meunier wrote: > On Thu, 3 Mar 2005, Benjamin Herrenschmidt wrote: > > > There should be more than these... Does it continue booting > > afte the screen goes blank or not at all ? Can you send the > > full dmesg log too ? Also, enable radeonfb verbose debug in > > the config. > > Yes, there were more in /var/log/syslog: > > Mar 2 15:16:45 darkstar kernel: radeonfb: Reference=27.00 MHz (RefDiv=12) > Memory=325.00 Mhz, System=200.00 MHz > Mar 2 15:16:45 darkstar kernel: radeonfb: PLL min 2 max 4 > Mar 2 15:16:45 darkstar kernel: i2c-algo-bit.o: monid seems to be busy. > Mar 2 15:16:45 darkstar kernel: radeonfb :01:00.0: Failed to register > I2C bus monid. > Mar 2 15:16:45 darkstar kernel: i2c-algo-bit.o: crt2 seems to be busy. > Mar 2 15:16:46 darkstar kernel: radeonfb :01:00.0: Failed to register > I2C bus crt2. > Mar 2 15:16:46 darkstar kernel: Console: switching to colour frame buffer > device 90x25 > Mar 2 15:16:46 darkstar kernel: radeonfb (:01:00.0): ATI Radeon AP > > Do the "seems to be busy." and/or "Failed to register I2C bus" > indicate a problem ? Maybe we are having conflicting bus names between radeonfb and matroxfb, or 2 instances of radeonfb ? Can you send the entire log please ? > There's nothing about radeonfb in dmesg because I manually > loaded the modules. And ? You should have it in dmesg after the module load... > I now compiled built-in with debug enabled and got the same > problem. Nothing got logged. Everything seems to stop when it > blanks, but SysRq works. Well, I would need the full log, and with radeonfb verbose debug enabled in the config. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11 vs DVB cx88 stuffs
Gene Heskett <[EMAIL PROTECTED]> wrote: > > I've a new pcHDTV-3000 card, and I thought maybe it would > be a good idea to build the cx88 stuff in the DVB section > of a make xconfig. > > It doesn't build, spitting out this bailout: > >CC [M] drivers/media/video/cx88/cx88-cards.o > drivers/media/video/cx88/cx88-cards.c: In function `hauppauge_eeprom_dvb': > drivers/media/video/cx88/cx88-cards.c:694: error: `PLLTYPE_DTT7595' > undeclared (first use in this function) > drivers/media/video/cx88/cx88-cards.c:694: error: (Each undeclared > identifier is reported only once > drivers/media/video/cx88/cx88-cards.c:694: error: for each function it > appears in.) > drivers/media/video/cx88/cx88-cards.c:698: error: `PLLTYPE_DTT7592' > undeclared (first use in this function) > drivers/media/video/cx88/cx88-cards.c: In function `cx88_card_setup': > drivers/media/video/cx88/cx88-cards.c:856: error: `PLLTYPE_DTT7579' > undeclared (first use in this function) > make[4]: *** [drivers/media/video/cx88/cx88-cards.o] Error 1 > make[3]: *** [drivers/media/video/cx88] Error 2 > make[2]: *** [drivers/media/video] Error 2 .config, please. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][8/10] verify_area cleanup : x86_64 and ia64
This is the patch that converts verify_area to access_ok for the x86_64
and ia64 archs.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
diff -urp linux-2.6.11-orig/arch/ia64/ia32/ia32_signal.c
linux-2.6.11/arch/ia64/ia32/ia32_signal.c
--- linux-2.6.11-orig/arch/ia64/ia32/ia32_signal.c 2005-03-02
08:37:31.0 +0100
+++ linux-2.6.11/arch/ia64/ia32/ia32_signal.c 2005-03-03 23:28:49.0
+0100
@@ -778,7 +778,7 @@ restore_sigcontext_ia32 (struct pt_regs
struct _fpstate * buf;
err |= __get_user(buf, >fpstate);
if (buf) {
- if (verify_area(VERIFY_READ, buf, sizeof(*buf)))
+ if (!access_ok(VERIFY_READ, buf, sizeof(*buf)))
goto badframe;
err |= restore_i387(buf);
}
@@ -978,7 +978,7 @@ sys32_sigreturn (int arg0, int arg1, int
sigset_t set;
int eax;
- if (verify_area(VERIFY_READ, frame, sizeof(*frame)))
+ if (!access_ok(VERIFY_READ, frame, sizeof(*frame)))
goto badframe;
if (__get_user(set.sig[0], >sc.oldmask)
@@ -1010,7 +1010,7 @@ sys32_rt_sigreturn (int arg0, int arg1,
sigset_t set;
int eax;
- if (verify_area(VERIFY_READ, frame, sizeof(*frame)))
+ if (!access_ok(VERIFY_READ, frame, sizeof(*frame)))
goto badframe;
if (__copy_from_user(, >uc.uc_sigmask, sizeof(set)))
goto badframe;
diff -urp linux-2.6.11-orig/arch/ia64/ia32/sys_ia32.c
linux-2.6.11/arch/ia64/ia32/sys_ia32.c
--- linux-2.6.11-orig/arch/ia64/ia32/sys_ia32.c 2005-03-02 08:38:12.0
+0100
+++ linux-2.6.11/arch/ia64/ia32/sys_ia32.c 2005-03-03 23:28:49.0
+0100
@@ -2402,12 +2402,11 @@ sys32_epoll_ctl(int epfd, int op, int fd
{
mm_segment_t old_fs = get_fs();
struct epoll_event event64;
- int error = -EFAULT;
+ int error;
u32 data_halfword;
- if ((error = verify_area(VERIFY_READ, event,
-sizeof(struct epoll_event32
- return error;
+ if (!access_ok(VERIFY_READ, event, sizeof(struct epoll_event32)))
+ return -EFAULT;
__get_user(event64.events, >events);
__get_user(data_halfword, >data[0]);
@@ -2437,9 +2436,8 @@ sys32_epoll_wait(int epfd, struct epoll_
}
/* Verify that the area passed by the user is writeable */
- if ((error = verify_area(VERIFY_WRITE, events,
-maxevents * sizeof(struct epoll_event32
- return error;
+ if (!access_ok(VERIFY_WRITE, events, maxevents * sizeof(struct
epoll_event32)))
+ return -EFAULT;
/*
* Allocate space for the intermediate copy. If the space needed
diff -urp linux-2.6.11-orig/arch/ia64/kernel/ptrace.c
linux-2.6.11/arch/ia64/kernel/ptrace.c
--- linux-2.6.11-orig/arch/ia64/kernel/ptrace.c 2005-03-02 08:38:33.0
+0100
+++ linux-2.6.11/arch/ia64/kernel/ptrace.c 2005-03-03 23:55:33.0
+0100
@@ -1074,15 +1074,12 @@ ptrace_getregs (struct task_struct *chil
struct ia64_fpreg fpval;
struct switch_stack *sw;
struct pt_regs *pt;
- long ret, retval;
+ long ret, retval = 0;
char nat = 0;
int i;
- retval = verify_area(VERIFY_WRITE, ppr,
-sizeof(struct pt_all_user_regs));
- if (retval != 0) {
+ if (!access_ok(VERIFY_WRITE, ppr, sizeof(struct pt_all_user_regs)))
return -EIO;
- }
pt = ia64_task_regs(child);
sw = (struct switch_stack *) (child->thread.ksp + 16);
@@ -1105,8 +1102,6 @@ ptrace_getregs (struct task_struct *chil
|| access_uarea(child, PT_NAT_BITS, _bits, 0))
return -EIO;
- retval = 0;
-
/* control regs */
retval |= __put_user(pt->cr_iip, >cr_iip);
@@ -1223,16 +1218,13 @@ ptrace_setregs (struct task_struct *chil
struct switch_stack *sw;
struct ia64_fpreg fpval;
struct pt_regs *pt;
- long ret, retval;
+ long ret, retval = 0;
int i;
memset(, 0, sizeof(fpval));
- retval = verify_area(VERIFY_READ, ppr,
-sizeof(struct pt_all_user_regs));
- if (retval != 0) {
+ if (!access_ok(VERIFY_READ, ppr, sizeof(struct pt_all_user_regs)))
return -EIO;
- }
pt = ia64_task_regs(child);
sw = (struct switch_stack *) (child->thread.ksp + 16);
@@ -1246,8 +1238,6 @@ ptrace_setregs (struct task_struct *chil
return -EIO;
}
- retval = 0;
-
/* control regs */
retval |= __get_user(pt->cr_iip, >cr_iip);
diff -urp linux-2.6.11-orig/arch/x86_64/ia32/ia32_aout.c
linux-2.6.11/arch/x86_64/ia32/ia32_aout.c
--- linux-2.6.11-orig/arch/x86_64/ia32/ia32_aout.c 2005-03-02
08:38:33.0 +0100
Re: RFD: Kernel release numbering
Hua Zhong wrote: The reason that I think it's important for some other person to do this job independently is that you are not bothered by bugfixes, which you never did well. :) You move on to each release as you do today, with different criteria, and someone else who can do the job better do so to stablize it. In the end it's more like the old way of 2.5/2.4, but just with a shorter release cycle, and the "2.6 stable release maintainer" could also continue to pick up new 2.6.x releases to work on instead of having to be stuck on one tree for 2 years or ever. He can say "this is the last 2.6.12.x release and next I'll start 2.6.16.1", etc. For this to happen the person has to be well-recognized and trusted by the community. Alan is one of the best candidates. :) Of course, I'm not sure if he is still interested.. I think the system we appear to have wound up with is superior: there is no single 2.6.X.Y maintainer, but more a $sucker mail alias that Does The Right Thing. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Alsa-devel] Re: intel 8x0 went silent in 2.6.11
Mark Canter <[EMAIL PROTECTED]> wrote: > > > To close this issue out of the LKML and alsa-devel, a bug report has been > written. > > It appears to be an issue with the 'headphone jack sense' (as kde labels > it). The issue is in the way the 8x0 addresses the docking station/port > replicator's audio output jack. The mentioned quick fix does not work for > using the ds/pr audio output, but does resolve it for a user that is only > using headphones/internal speakers. But there was a behavioural change: applications which worked in 2.6.10 don't work in 2.6.11, is that correct? If so, the best course of action is to change the kernel so those applications work again. Can that be done? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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][6/10] verify_area cleanup : ppc, ppc64, m68k, m68knommu
Convert verify_area to access_ok for ppc, ppc64, m68k and m68knommu
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
diff -urp linux-2.6.11-orig/arch/ppc/kernel/align.c
linux-2.6.11/arch/ppc/kernel/align.c
--- linux-2.6.11-orig/arch/ppc/kernel/align.c 2005-03-02 08:38:34.0
+0100
+++ linux-2.6.11/arch/ppc/kernel/align.c2005-03-03 20:34:35.0
+0100
@@ -248,7 +248,7 @@ fix_alignment(struct pt_regs *regs)
*/
p = (long __user *) (regs->dar & -L1_CACHE_BYTES);
if (user_mode(regs)
- && verify_area(VERIFY_WRITE, p, L1_CACHE_BYTES))
+ && !access_ok(VERIFY_WRITE, p, L1_CACHE_BYTES))
return -EFAULT;
for (i = 0; i < L1_CACHE_BYTES / sizeof(long); ++i)
if (__put_user(0, p+i))
@@ -328,7 +328,7 @@ fix_alignment(struct pt_regs *regs)
/* Verify the address of the operand */
if (user_mode(regs)) {
- if (verify_area((flags & ST? VERIFY_WRITE: VERIFY_READ), addr,
nb))
+ if (!access_ok((flags & ST? VERIFY_WRITE: VERIFY_READ), addr,
nb))
return -EFAULT; /* bad address */
}
diff -urp linux-2.6.11-orig/arch/ppc/kernel/signal.c
linux-2.6.11/arch/ppc/kernel/signal.c
--- linux-2.6.11-orig/arch/ppc/kernel/signal.c 2005-03-02 08:38:33.0
+0100
+++ linux-2.6.11/arch/ppc/kernel/signal.c 2005-03-03 20:34:35.0
+0100
@@ -118,7 +118,7 @@ sys_sigaction(int sig, const struct old_
if (act) {
old_sigset_t mask;
- if (verify_area(VERIFY_READ, act, sizeof(*act)) ||
+ if (!access_ok(VERIFY_READ, act, sizeof(*act)) ||
__get_user(new_ka.sa.sa_handler, >sa_handler) ||
__get_user(new_ka.sa.sa_restorer, >sa_restorer))
return -EFAULT;
@@ -130,7 +130,7 @@ sys_sigaction(int sig, const struct old_
ret = do_sigaction(sig, (act? _ka: NULL), (oact? _ka: NULL));
if (!ret && oact) {
- if (verify_area(VERIFY_WRITE, oact, sizeof(*oact)) ||
+ if (!access_ok(VERIFY_WRITE, oact, sizeof(*oact)) ||
__put_user(old_ka.sa.sa_handler, >sa_handler) ||
__put_user(old_ka.sa.sa_restorer, >sa_restorer))
return -EFAULT;
@@ -376,7 +376,7 @@ handle_rt_signal(unsigned long sig, stru
/* create a stack frame for the caller of the handler */
newsp -= __SIGNAL_FRAMESIZE + 16;
- if (verify_area(VERIFY_WRITE, (void __user *) newsp, origsp - newsp))
+ if (!access_ok(VERIFY_WRITE, (void __user *) newsp, origsp - newsp))
goto badframe;
/* Put the siginfo & fill in most of the ucontext */
@@ -445,7 +445,7 @@ int sys_swapcontext(struct ucontext __us
return -EINVAL;
if (old_ctx != NULL) {
- if (verify_area(VERIFY_WRITE, old_ctx, sizeof(*old_ctx))
+ if (!access_ok(VERIFY_WRITE, old_ctx, sizeof(*old_ctx))
|| save_user_regs(regs, _ctx->uc_mcontext, 0)
|| __copy_to_user(_ctx->uc_sigmask,
>blocked, sizeof(sigset_t))
@@ -454,7 +454,7 @@ int sys_swapcontext(struct ucontext __us
}
if (new_ctx == NULL)
return 0;
- if (verify_area(VERIFY_READ, new_ctx, sizeof(*new_ctx))
+ if (!access_ok(VERIFY_READ, new_ctx, sizeof(*new_ctx))
|| __get_user(tmp, (u8 __user *) new_ctx)
|| __get_user(tmp, (u8 __user *) (new_ctx + 1) - 1))
return -EFAULT;
@@ -464,7 +464,7 @@ int sys_swapcontext(struct ucontext __us
* image of the user's registers, we can't just return -EFAULT
* because the user's registers will be corrupted. For instance
* the NIP value may have been updated but not some of the
-* other registers. Given that we have done the verify_area
+* other registers. Given that we have done the access_ok
* and successfully read the first and last bytes of the region
* above, this should only happen in an out-of-memory situation
* or if another thread unmaps the region containing the context.
@@ -487,7 +487,7 @@ int sys_rt_sigreturn(int r3, int r4, int
rt_sf = (struct rt_sigframe __user *)
(regs->gpr[1] + __SIGNAL_FRAMESIZE + 16);
- if (verify_area(VERIFY_READ, rt_sf, sizeof(struct rt_sigframe)))
+ if (!access_ok(VERIFY_READ, rt_sf, sizeof(struct rt_sigframe)))
goto bad;
if (do_setcontext(_sf->uc, regs, 1))
goto bad;
@@ -572,7 +572,7 @@ int sys_debug_setcontext(struct ucontext
* image of the user's registers, we can't just return -EFAULT
* because the user's registers will be corrupted. For instance
* the NIP value may have been updated but not some of the
-*
[PATCH][7/10] verify_area cleanup : sparc and sparc64
This patch converts verify_area to access_ok for sparc and sparc64.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
diff -urp linux-2.6.11-orig/arch/sparc/kernel/ptrace.c
linux-2.6.11/arch/sparc/kernel/ptrace.c
--- linux-2.6.11-orig/arch/sparc/kernel/ptrace.c2005-03-02
08:38:33.0 +0100
+++ linux-2.6.11/arch/sparc/kernel/ptrace.c 2005-03-03 20:42:08.0
+0100
@@ -374,8 +374,8 @@ asmlinkage void do_ptrace(struct pt_regs
struct pt_regs *cregs = child->thread.kregs;
int rval;
- rval = verify_area(VERIFY_WRITE, pregs, sizeof(struct pt_regs));
- if(rval) {
+ if (!access_ok(VERIFY_WRITE, pregs, sizeof(struct pt_regs))) {
+ rval = -EFAULT;
pt_error_return(regs, -rval);
goto out_tsk;
}
@@ -401,8 +401,8 @@ asmlinkage void do_ptrace(struct pt_regs
/* Must be careful, tracing process can only set certain
* bits in the psr.
*/
- i = verify_area(VERIFY_READ, pregs, sizeof(struct pt_regs));
- if(i) {
+ if (!access_ok(VERIFY_READ, pregs, sizeof(struct pt_regs))) {
+ i = -EFAULT;
pt_error_return(regs, -i);
goto out_tsk;
}
@@ -439,8 +439,8 @@ asmlinkage void do_ptrace(struct pt_regs
struct fps __user *fps = (struct fps __user *) addr;
int i;
- i = verify_area(VERIFY_WRITE, fps, sizeof(struct fps));
- if(i) {
+ if (!access_ok(VERIFY_WRITE, fps, sizeof(struct fps))) {
+ i = -EFAULT;
pt_error_return(regs, -i);
goto out_tsk;
}
@@ -474,8 +474,8 @@ asmlinkage void do_ptrace(struct pt_regs
struct fps __user *fps = (struct fps __user *) addr;
int i;
- i = verify_area(VERIFY_READ, fps, sizeof(struct fps));
- if(i) {
+ if (!access_ok(VERIFY_READ, fps, sizeof(struct fps))) {
+ i = -EFAULT;
pt_error_return(regs, -i);
goto out_tsk;
}
diff -urp linux-2.6.11-orig/arch/sparc/kernel/signal.c
linux-2.6.11/arch/sparc/kernel/signal.c
--- linux-2.6.11-orig/arch/sparc/kernel/signal.c2005-03-02
08:38:13.0 +0100
+++ linux-2.6.11/arch/sparc/kernel/signal.c 2005-03-03 20:42:08.0
+0100
@@ -205,7 +205,7 @@ restore_fpu_state(struct pt_regs *regs,
set_used_math();
clear_tsk_thread_flag(current, TIF_USEDFPU);
- if (verify_area(VERIFY_READ, fpu, sizeof(*fpu)))
+ if (!access_ok(VERIFY_READ, fpu, sizeof(*fpu)))
return -EFAULT;
err = __copy_from_user(>thread.float_regs[0],
>si_float_regs[0],
@@ -231,7 +231,7 @@ static inline void do_new_sigreturn (str
sf = (struct new_signal_frame __user *) regs->u_regs[UREG_FP];
/* 1. Make sure we are not getting garbage from the user */
- if (verify_area(VERIFY_READ, sf, sizeof(*sf)))
+ if (!access_ok(VERIFY_READ, sf, sizeof(*sf)))
goto segv_and_exit;
if (((unsigned long) sf) & 3)
@@ -297,7 +297,7 @@ asmlinkage void do_sigreturn(struct pt_r
scptr = (struct sigcontext __user *) regs->u_regs[UREG_I0];
/* Check sanity of the user arg. */
- if (verify_area(VERIFY_READ, scptr, sizeof(struct sigcontext)) ||
+ if (!access_ok(VERIFY_READ, scptr, sizeof(struct sigcontext)) ||
(((unsigned long) scptr) & 3))
goto segv_and_exit;
@@ -356,7 +356,7 @@ asmlinkage void do_rt_sigreturn(struct p
synchronize_user_stack();
sf = (struct rt_signal_frame __user *) regs->u_regs[UREG_FP];
- if (verify_area(VERIFY_READ, sf, sizeof(*sf)) ||
+ if (!access_ok(VERIFY_READ, sf, sizeof(*sf)) ||
(((unsigned long) sf) & 0x03))
goto segv;
diff -urp linux-2.6.11-orig/arch/sparc/kernel/sys_sparc.c
linux-2.6.11/arch/sparc/kernel/sys_sparc.c
--- linux-2.6.11-orig/arch/sparc/kernel/sys_sparc.c 2005-03-02
08:38:00.0 +0100
+++ linux-2.6.11/arch/sparc/kernel/sys_sparc.c 2005-03-03 20:42:08.0
+0100
@@ -399,7 +399,7 @@ sparc_sigaction (int sig, const struct o
if (act) {
unsigned long mask;
- if (verify_area(VERIFY_READ, act, sizeof(*act)) ||
+ if (!access_ok(VERIFY_READ, act, sizeof(*act)) ||
__get_user(new_ka.sa.sa_handler, >sa_handler) ||
__get_user(new_ka.sa.sa_restorer, >sa_restorer))
return -EFAULT;
@@ -417,7 +417,7 @@ sparc_sigaction (int sig, const struct o
* deadlock us if we held the signal lock on SMP. So for
* now I take the easy way out
[PATCH][9/10] verify_area cleanup : misc remaining archs
The last remaining archs that have not already been converted from
verify_area to access_ok by the previous patches are all taken care of by
this one.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
diff -urp linux-2.6.11-orig/arch/sh/kernel/signal.c
linux-2.6.11/arch/sh/kernel/signal.c
--- linux-2.6.11-orig/arch/sh/kernel/signal.c 2005-03-02 08:38:34.0
+0100
+++ linux-2.6.11/arch/sh/kernel/signal.c2005-03-03 22:28:34.0
+0100
@@ -100,7 +100,7 @@ sys_sigaction(int sig, const struct old_
if (act) {
old_sigset_t mask;
- if (verify_area(VERIFY_READ, act, sizeof(*act)) ||
+ if (!access_ok(VERIFY_READ, act, sizeof(*act)) ||
__get_user(new_ka.sa.sa_handler, >sa_handler) ||
__get_user(new_ka.sa.sa_restorer, >sa_restorer))
return -EFAULT;
@@ -112,7 +112,7 @@ sys_sigaction(int sig, const struct old_
ret = do_sigaction(sig, act ? _ka : NULL, oact ? _ka : NULL);
if (!ret && oact) {
- if (verify_area(VERIFY_WRITE, oact, sizeof(*oact)) ||
+ if (!access_ok(VERIFY_WRITE, oact, sizeof(*oact)) ||
__put_user(old_ka.sa.sa_handler, >sa_handler) ||
__put_user(old_ka.sa.sa_restorer, >sa_restorer))
return -EFAULT;
@@ -239,7 +239,7 @@ asmlinkage int sys_sigreturn(unsigned lo
sigset_t set;
int r0;
- if (verify_area(VERIFY_READ, frame, sizeof(*frame)))
+ if (!access_ok(VERIFY_READ, frame, sizeof(*frame)))
goto badframe;
if (__get_user(set.sig[0], >sc.oldmask)
@@ -273,7 +273,7 @@ asmlinkage int sys_rt_sigreturn(unsigned
stack_t st;
int r0;
- if (verify_area(VERIFY_READ, frame, sizeof(*frame)))
+ if (!access_ok(VERIFY_READ, frame, sizeof(*frame)))
goto badframe;
if (__copy_from_user(, >uc.uc_sigmask, sizeof(set)))
diff -urp linux-2.6.11-orig/arch/um/include/sysdep-i386/checksum.h
linux-2.6.11/arch/um/include/sysdep-i386/checksum.h
--- linux-2.6.11-orig/arch/um/include/sysdep-i386/checksum.h2005-03-02
08:38:34.0 +0100
+++ linux-2.6.11/arch/um/include/sysdep-i386/checksum.h 2005-03-03
22:28:34.0 +0100
@@ -41,7 +41,7 @@ unsigned int csum_partial_copy_from(cons
* passed in an incorrect kernel address to one of these functions.
*
* If you use these functions directly please don't forget the
- * verify_area().
+ * access_ok().
*/
static __inline__
diff -urp linux-2.6.11-orig/arch/um/include/sysdep-x86_64/checksum.h
linux-2.6.11/arch/um/include/sysdep-x86_64/checksum.h
--- linux-2.6.11-orig/arch/um/include/sysdep-x86_64/checksum.h 2005-03-02
08:37:54.0 +0100
+++ linux-2.6.11/arch/um/include/sysdep-x86_64/checksum.h 2005-03-03
22:28:34.0 +0100
@@ -19,7 +19,7 @@ extern unsigned csum_partial(const unsig
* passed in an incorrect kernel address to one of these functions.
*
* If you use these functions directly please don't forget the
- * verify_area().
+ * access_ok().
*/
static __inline__
diff -urp linux-2.6.11-orig/arch/um/sys-i386/ldt.c
linux-2.6.11/arch/um/sys-i386/ldt.c
--- linux-2.6.11-orig/arch/um/sys-i386/ldt.c2005-03-02 08:38:09.0
+0100
+++ linux-2.6.11/arch/um/sys-i386/ldt.c 2005-03-03 22:28:34.0 +0100
@@ -17,7 +17,7 @@ extern int modify_ldt(int func, void *pt
int sys_modify_ldt_tt(int func, void __user *ptr, unsigned long bytecount)
{
- if (verify_area(VERIFY_READ, ptr, bytecount))
+ if (!access_ok(VERIFY_READ, ptr, bytecount))
return -EFAULT;
return modify_ldt(func, ptr, bytecount);
diff -urp linux-2.6.11-orig/arch/um/sys-i386/signal.c
linux-2.6.11/arch/um/sys-i386/signal.c
--- linux-2.6.11-orig/arch/um/sys-i386/signal.c 2005-03-02 08:38:17.0
+0100
+++ linux-2.6.11/arch/um/sys-i386/signal.c 2005-03-03 22:28:34.0
+0100
@@ -211,8 +211,8 @@ int setup_signal_stack_sc(unsigned long
stack_top &= -8UL;
frame = (struct sigframe *) stack_top - 1;
- if(verify_area(VERIFY_WRITE, frame, sizeof(*frame)))
- return(1);
+ if (!access_ok(VERIFY_WRITE, frame, sizeof(*frame)))
+ return 1;
restorer = (void *) frame->retcode;
if(ka->sa.sa_flags & SA_RESTORER)
@@ -261,8 +261,8 @@ int setup_signal_stack_si(unsigned long
stack_top &= -8UL;
frame = (struct rt_sigframe *) stack_top - 1;
- if(verify_area(VERIFY_WRITE, frame, sizeof(*frame)))
- return(1);
+ if (!access_ok(VERIFY_WRITE, frame, sizeof(*frame)))
+ return 1;
restorer = (void *) frame->retcode;
if(ka->sa.sa_flags & SA_RESTORER)
diff -urp linux-2.6.11-orig/arch/um/sys-i386/syscalls.c
linux-2.6.11/arch/um/sys-i386/syscalls.c
--- linux-2.6.11-orig/arch/um/sys-i386/syscalls.c 2005-03-02
Re: RFD: Kernel release numbering
On Thursday 03 March 2005 16:07, Jeff Garzik wrote: >As a further elaboration... > >The problem with the current 2.6-rc setup is a _human_ > _communications_ problem. > >Users have been trained in a metaphor that is applied uniformly > across all software projects that use the metaphor: > > test release: a useful merge/testing point > release candidate: bugfixes only, test test test > >Linux does it differently. > >It's hard enough to get users to test... now we have raised the >barrier even higher by abusing a common metaphor. A metaphor that > is used _succesfully_ elsewhere to get users to test. > >"release candidate" is a promise to users that the current tree is > close to what the release will look like, and only major fixes will > appear between -rc and -final. > >We broke that promise. In human interface terms, this is like >redefining the "garbage can" icon to mean "save your work." ;-) > > Jeff I've seen this comment before too, and I still think it says it best: The full release s/b the last rc with NO changes other than its name. Now we are faced with a final that may have another 50k+ of patches applied over what made the rc5. IMO, in the immediately past case, that should not have been final, but an rc6. I personally vote for going back to the -pre series where we get to test new ideas & maybe morph the neighbors dog/cat. At some point it gets stable enough to call it -rc1, at which point nothing but bugfixes should be allowed in until the final. That way we have a develop, then stabilize, then develop the next, then stabilize it set of stairsteps. I personally build and run as many of them as I can find the time to do. I just applied the bk-1394-patch and its building because 2.6.11 isn't really comfortable running my movie camera yet. I also haven't built any more of Andrews -mm's since the last time I got told off about it. I can go back to doing that too, if the results of my testing it aren't going to be thrown out like the babys bath water. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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][4/10] verify_area cleanup : i386 and misc.
This patch converts verify_area to access_ok in arch/i386, fs/, kernel/
and a few other bits that didn't fit in the other patches or that I
actually was able to test on my hardware - this is by far the best tested
of all the patches.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
diff -urp linux-2.6.11-orig/arch/i386/kernel/signal.c
linux-2.6.11/arch/i386/kernel/signal.c
--- linux-2.6.11-orig/arch/i386/kernel/signal.c 2005-03-02 08:38:08.0
+0100
+++ linux-2.6.11/arch/i386/kernel/signal.c 2005-03-03 21:04:34.0
+0100
@@ -93,7 +93,7 @@ sys_sigaction(int sig, const struct old_
if (act) {
old_sigset_t mask;
- if (verify_area(VERIFY_READ, act, sizeof(*act)) ||
+ if (!access_ok(VERIFY_READ, act, sizeof(*act)) ||
__get_user(new_ka.sa.sa_handler, >sa_handler) ||
__get_user(new_ka.sa.sa_restorer, >sa_restorer))
return -EFAULT;
@@ -105,7 +105,7 @@ sys_sigaction(int sig, const struct old_
ret = do_sigaction(sig, act ? _ka : NULL, oact ? _ka : NULL);
if (!ret && oact) {
- if (verify_area(VERIFY_WRITE, oact, sizeof(*oact)) ||
+ if (!access_ok(VERIFY_WRITE, oact, sizeof(*oact)) ||
__put_user(old_ka.sa.sa_handler, >sa_handler) ||
__put_user(old_ka.sa.sa_restorer, >sa_restorer))
return -EFAULT;
@@ -187,7 +187,7 @@ restore_sigcontext(struct pt_regs *regs,
struct _fpstate __user * buf;
err |= __get_user(buf, >fpstate);
if (buf) {
- if (verify_area(VERIFY_READ, buf, sizeof(*buf)))
+ if (!access_ok(VERIFY_READ, buf, sizeof(*buf)))
goto badframe;
err |= restore_i387(buf);
} else {
@@ -213,7 +213,7 @@ asmlinkage int sys_sigreturn(unsigned lo
sigset_t set;
int eax;
- if (verify_area(VERIFY_READ, frame, sizeof(*frame)))
+ if (!access_ok(VERIFY_READ, frame, sizeof(*frame)))
goto badframe;
if (__get_user(set.sig[0], >sc.oldmask)
|| (_NSIG_WORDS > 1
@@ -243,7 +243,7 @@ asmlinkage int sys_rt_sigreturn(unsigned
sigset_t set;
int eax;
- if (verify_area(VERIFY_READ, frame, sizeof(*frame)))
+ if (!access_ok(VERIFY_READ, frame, sizeof(*frame)))
goto badframe;
if (__copy_from_user(, >uc.uc_sigmask, sizeof(set)))
goto badframe;
diff -urp linux-2.6.11-orig/arch/i386/math-emu/errors.c
linux-2.6.11/arch/i386/math-emu/errors.c
--- linux-2.6.11-orig/arch/i386/math-emu/errors.c 2005-03-02
08:38:10.0 +0100
+++ linux-2.6.11/arch/i386/math-emu/errors.c2005-03-03 21:04:34.0
+0100
@@ -40,7 +40,7 @@ void Un_impl(void)
unsigned long address = FPU_ORIG_EIP;
RE_ENTRANT_CHECK_OFF;
- /* No need to verify_area(), we have previously fetched these bytes. */
+ /* No need to check access_ok(), we have previously fetched these bytes. */
printk("Unimplemented FPU Opcode at eip=%p : ", (void __user *) address);
if ( FPU_CS == __USER_CS )
{
@@ -91,7 +91,7 @@ void FPU_printall(void)
unsigned long address = FPU_ORIG_EIP;
RE_ENTRANT_CHECK_OFF;
- /* No need to verify_area(), we have previously fetched these bytes. */
+ /* No need to check access_ok(), we have previously fetched these bytes. */
printk("At %p:", (void *) address);
if ( FPU_CS == __USER_CS )
{
diff -urp linux-2.6.11-orig/drivers/char/consolemap.c
linux-2.6.11/drivers/char/consolemap.c
--- linux-2.6.11-orig/drivers/char/consolemap.c 2005-03-02 08:38:13.0
+0100
+++ linux-2.6.11/drivers/char/consolemap.c 2005-03-03 21:04:34.0
+0100
@@ -262,9 +262,8 @@ int con_set_trans_old(unsigned char __us
int i;
unsigned short *p = translations[USER_MAP];
- i = verify_area(VERIFY_READ, arg, E_TABSZ);
- if (i)
- return i;
+ if (!access_ok(VERIFY_READ, arg, E_TABSZ))
+ return -EFAULT;
for (i=0; i 0 && i < 65536) {
if (__put_user(inb(i),tmp) < 0)
@@ -361,7 +361,7 @@ static ssize_t write_port(struct file *
unsigned long i = *ppos;
const char __user * tmp = buf;
- if (verify_area(VERIFY_READ,buf,count))
+ if (!access_ok(VERIFY_READ,buf,count))
return -EFAULT;
while (count-- > 0 && i < 65536) {
char c;
diff -urp linux-2.6.11-orig/fs/compat_ioctl.c linux-2.6.11/fs/compat_ioctl.c
--- linux-2.6.11-orig/fs/compat_ioctl.c 2005-03-02 08:38:38.0 +0100
+++ linux-2.6.11/fs/compat_ioctl.c 2005-03-03 21:04:34.0 +0100
@@ -2344,9 +2344,8 @@ put_dirent32 (struct dirent *d, struct c
{
int ret;
-if ((ret = verify_area(VERIFY_WRITE, d32,
- sizeof(struct compat_dirent
-
[PATCH][5/10] verify_area cleanup : mips
This is the patch to convert verify_area to access_ok for arch/mips
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
diff -urp linux-2.6.11-orig/arch/mips/kernel/irixelf.c
linux-2.6.11/arch/mips/kernel/irixelf.c
--- linux-2.6.11-orig/arch/mips/kernel/irixelf.c2005-03-02
08:38:34.0 +0100
+++ linux-2.6.11/arch/mips/kernel/irixelf.c 2005-03-03 21:27:55.0
+0100
@@ -887,12 +887,11 @@ unsigned long irix_mapelf(int fd, struct
/* First get the verification out of the way. */
hp = user_phdrp;
- retval = verify_area(VERIFY_READ, hp, (sizeof(struct elf_phdr) * cnt));
- if(retval) {
+ if (!access_ok(VERIFY_READ, hp, (sizeof(struct elf_phdr) * cnt))) {
#ifdef DEBUG_ELF
- printk("irix_mapelf: verify_area fails!\n");
+ printk("irix_mapelf: access_ok fails!\n");
#endif
- return retval;
+ return -EFAULT;
}
#ifdef DEBUG_ELF
diff -urp linux-2.6.11-orig/arch/mips/kernel/irixinv.c
linux-2.6.11/arch/mips/kernel/irixinv.c
--- linux-2.6.11-orig/arch/mips/kernel/irixinv.c2005-03-02
08:37:48.0 +0100
+++ linux-2.6.11/arch/mips/kernel/irixinv.c 2005-03-03 21:27:55.0
+0100
@@ -36,8 +36,8 @@ int dump_inventory_to_user (void *userbu
inventory_t *user = userbuf;
int v;
- if ((v = verify_area (VERIFY_WRITE, userbuf, size)))
- return v;
+ if (!access_ok(VERIFY_WRITE, userbuf, size))
+ return -EFAULT;
for (v = 0; v < inventory_items; v++){
inv = [v];
diff -urp linux-2.6.11-orig/arch/mips/kernel/irixsig.c
linux-2.6.11/arch/mips/kernel/irixsig.c
--- linux-2.6.11-orig/arch/mips/kernel/irixsig.c2005-03-02
08:38:25.0 +0100
+++ linux-2.6.11/arch/mips/kernel/irixsig.c 2005-03-03 21:32:49.0
+0100
@@ -312,7 +312,7 @@ irix_sigaction(int sig, const struct sig
#endif
if (act) {
sigset_t mask;
- if (verify_area(VERIFY_READ, act, sizeof(*act)) ||
+ if (!access_ok(VERIFY_READ, act, sizeof(*act)) ||
__get_user(new_ka.sa.sa_handler, >sa_handler) ||
__get_user(new_ka.sa.sa_flags, >sa_flags))
return -EFAULT;
@@ -331,7 +331,7 @@ irix_sigaction(int sig, const struct sig
ret = do_sigaction(sig, act ? _ka : NULL, oact ? _ka : NULL);
if (!ret && oact) {
- if (verify_area(VERIFY_WRITE, oact, sizeof(*oact)) ||
+ if (!access_ok(VERIFY_WRITE, oact, sizeof(*oact)) ||
__put_user(old_ka.sa.sa_handler, >sa_handler) ||
__put_user(old_ka.sa.sa_flags, >sa_flags))
return -EFAULT;
@@ -350,12 +350,10 @@ asmlinkage int irix_sigpending(irix_sigs
asmlinkage int irix_sigprocmask(int how, irix_sigset_t *new, irix_sigset_t
*old)
{
sigset_t oldbits, newbits;
- int error;
if (new) {
- error = verify_area(VERIFY_READ, new, sizeof(*new));
- if (error)
- return error;
+ if (!access_ok(VERIFY_READ, new, sizeof(*new)))
+ return -EFAULT;
__copy_from_user(, new, sizeof(unsigned long)*4);
sigdelsetmask(, ~_BLOCKABLE);
@@ -385,9 +383,8 @@ asmlinkage int irix_sigprocmask(int how,
spin_unlock_irq(>sighand->siglock);
}
if(old) {
- error = verify_area(VERIFY_WRITE, old, sizeof(*old));
- if(error)
- return error;
+ if (!access_ok(VERIFY_WRITE, old, sizeof(*old)))
+ return -EFAULT;
__copy_to_user(old, >blocked, sizeof(unsigned long)*4);
}
@@ -469,12 +466,13 @@ asmlinkage int irix_sigpoll_sys(unsigned
#endif
/* Must always specify the signal set. */
- if(!set)
+ if (!set)
return -EINVAL;
- error = verify_area(VERIFY_READ, set, sizeof(kset));
- if (error)
+ if (!access_ok(VERIFY_READ, set, sizeof(kset))) {
+ error = -EFAULT;
goto out;
+ }
__copy_from_user(, set, sizeof(set));
if (error)
@@ -485,11 +483,10 @@ asmlinkage int irix_sigpoll_sys(unsigned
goto out;
}
- if(tp) {
- error = verify_area(VERIFY_READ, tp, sizeof(*tp));
- if(error)
- return error;
- if(!tp->tv_sec && !tp->tv_nsec) {
+ if (tp) {
+ if (!access_ok(VERIFY_READ, tp, sizeof(*tp)))
+ return -EFAULT;
+ if (!tp->tv_sec && !tp->tv_nsec) {
error = -EINVAL;
goto out;
}
@@ -564,13 +561,15 @@ asmlinkage int irix_waitsys(int type, in
retval = -EINVAL;
goto out;
}
- retval =
Re: RFD: Kernel release numbering
Andrew Morton wrote: Alan Cox <[EMAIL PROTECTED]> wrote: On Iau, 2005-03-03 at 23:17, Andrew Morton wrote: Ideally, the 2.6.x.y maintainer wouldn't need any particular kernel development skills - it's just patchmonkeying the things which maintainers send him. I would disagree, and I suspect anyone else who has maintained a distro stable kernel would likewise. It needs one or more people who know who to ask about stuff, are careful, have a good grounding in bug spotting, races, common mistakes and know roughly how all the kernel works. Maintainers aren't very good at it in general and they don't see overlaps between areas very well. That is all inappropriate activity for a 2.6.x.y tree as it is being proposed. Am I right? All we're proposing here is a tree which has small fixups for reasonably serious problems. Almost without exception it would consist of backports. "thru-ports": commit to linux-2.6.x.y and get Linus to pull. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][10/10] verify_area cleanup : deprecate
The previous 9 patches should take care of converting all callers of
verify_area into access_ok, so now it's time to deprecate verify_area all
over so noone gets tempted to use it in new code - this patch does that.
Eventually when this has been deprecated for a while I'll send patches to
completely remove the function (thoughts on how long it should be
deprecated first are welcome).
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
diff -urp linux-2.6.11-orig/include/asm-alpha/uaccess.h
linux-2.6.11/include/asm-alpha/uaccess.h
--- linux-2.6.11-orig/include/asm-alpha/uaccess.h 2005-03-02
08:38:17.0 +0100
+++ linux-2.6.11/include/asm-alpha/uaccess.h2005-03-03 23:58:56.0
+0100
@@ -48,7 +48,8 @@
__access_ok(((unsigned long)(addr)),(size),get_fs()); \
})
-extern inline int verify_area(int type, const void __user * addr, unsigned
long size)
+/* this function will go away soon - use access_ok() instead */
+extern inline int __deprecated verify_area(int type, const void __user * addr,
unsigned long size)
{
return access_ok(type,addr,size) ? 0 : -EFAULT;
}
diff -urp linux-2.6.11-orig/include/asm-arm/uaccess.h
linux-2.6.11/include/asm-arm/uaccess.h
--- linux-2.6.11-orig/include/asm-arm/uaccess.h 2005-03-02 08:38:12.0
+0100
+++ linux-2.6.11/include/asm-arm/uaccess.h 2005-03-03 23:58:56.0
+0100
@@ -77,7 +77,8 @@ static inline void set_fs (mm_segment_t
#define access_ok(type,addr,size) (__range_ok(addr,size) == 0)
-static inline int verify_area(int type, const void __user *addr, unsigned long
size)
+/* this function will go away soon - use access_ok() instead */
+static inline int __deprecated verify_area(int type, const void __user *addr,
unsigned long size)
{
return access_ok(type, addr, size) ? 0 : -EFAULT;
}
diff -urp linux-2.6.11-orig/include/asm-arm26/uaccess.h
linux-2.6.11/include/asm-arm26/uaccess.h
--- linux-2.6.11-orig/include/asm-arm26/uaccess.h 2005-03-02
08:37:48.0 +0100
+++ linux-2.6.11/include/asm-arm26/uaccess.h2005-03-03 23:58:57.0
+0100
@@ -40,7 +40,8 @@ extern int fixup_exception(struct pt_reg
#define access_ok(type,addr,size) (__range_ok(addr,size) == 0)
-static inline int verify_area(int type, const void * addr, unsigned long size)
+/* this function will go away soon - use access_ok() instead */
+static inline int __deprecated verify_area(int type, const void * addr,
unsigned long size)
{
return access_ok(type, addr, size) ? 0 : -EFAULT;
}
diff -urp linux-2.6.11-orig/include/asm-cris/uaccess.h
linux-2.6.11/include/asm-cris/uaccess.h
--- linux-2.6.11-orig/include/asm-cris/uaccess.h2005-03-02
08:37:48.0 +0100
+++ linux-2.6.11/include/asm-cris/uaccess.h 2005-03-03 23:58:57.0
+0100
@@ -91,7 +91,8 @@
#define __access_ok(addr,size) (__kernel_ok || __user_ok((addr),(size)))
#define access_ok(type,addr,size) __access_ok((unsigned long)(addr),(size))
-extern inline int verify_area(int type, const void __user * addr, unsigned
long size)
+/* this function will go away soon - use access_ok() instead */
+extern inline int __deprecated verify_area(int type, const void __user * addr,
unsigned long size)
{
return access_ok(type,addr,size) ? 0 : -EFAULT;
}
diff -urp linux-2.6.11-orig/include/asm-frv/uaccess.h
linux-2.6.11/include/asm-frv/uaccess.h
--- linux-2.6.11-orig/include/asm-frv/uaccess.h 2005-03-02 08:38:33.0
+0100
+++ linux-2.6.11/include/asm-frv/uaccess.h 2005-03-03 23:58:57.0
+0100
@@ -67,7 +67,8 @@ static inline int ___range_ok(unsigned l
#define access_ok(type,addr,size) (__range_ok((addr), (size)) == 0)
#define __access_ok(addr,size) (__range_ok((addr), (size)) == 0)
-static inline int verify_area(int type, const void * addr, unsigned long size)
+/* this function will go away soon - use access_ok() / __range_ok() instead */
+static inline int __deprecated verify_area(int type, const void * addr,
unsigned long size)
{
return __range_ok(addr, size);
}
diff -urp linux-2.6.11-orig/include/asm-h8300/uaccess.h
linux-2.6.11/include/asm-h8300/uaccess.h
--- linux-2.6.11-orig/include/asm-h8300/uaccess.h 2005-03-02
08:37:54.0 +0100
+++ linux-2.6.11/include/asm-h8300/uaccess.h2005-03-03 23:58:57.0
+0100
@@ -24,7 +24,8 @@ static inline int __access_ok(unsigned l
return(RANGE_CHECK_OK(addr, size, 0L, (unsigned long)&_ramend));
}
-static inline int verify_area(int type, const void *addr, unsigned long size)
+/* this function will go away soon - use access_ok() instead */
+static inline int __deprecated verify_area(int type, const void *addr,
unsigned long size)
{
return access_ok(type,addr,size)?0:-EFAULT;
}
diff -urp linux-2.6.11-orig/include/asm-i386/uaccess.h
linux-2.6.11/include/asm-i386/uaccess.h
--- linux-2.6.11-orig/include/asm-i386/uaccess.h2005-03-02
08:37:49.0 +0100
+++
lk-changelog.pl
This is a semi-automatic announcement. lk-changelog.pl aka. shortlog version has been released. This script is used by Linus and Marcelo to rearrange and reformat BK ChangeSet logs into a more human-readable format, and the official repository is Parent repository is file://var/bitkeeper/BK-kernel-tools As the script has grown large, this mail only contains a diff against the last released version. You can always download the full script and GPG signatures from http://home.pages.de/~mandree/linux/kernel/ My thanks go to Vitezslav Samel who has spent a lot of time on digging out the real names for addresses sending in BK ChangeSets. Note that your mailer must be MIME-capable to save this mail properly, because it is in the "quoted-printable" encoding. = <- if you see just an equality sign, but no "3D", your mailer is fine. = <- if you see 3D on this line, then upgrade your mailer or pipe this mail = <- into metamail. -- A sh script on behalf of Matthias Andree - Changes since last release: revision 0.328 date: 2005-03-04 02:36:50 +; author: emma; state: Exp; lines: +200 -3 Merge CVS <-> BK, dropping ID line which is sorta useless. revision 0.327 date: 2004-12-02 11:10:20 +; author: emma; state: Exp; lines: +68 -6 synch up CVS <-> BK = Index: lk-changelog.pl === RCS file: /var/CVS/lk-changelog/lk-changelog.pl,v retrieving revision 0.327 retrieving revision 0.328 diff -u -U2 -r0.327 -r0.328 --- lk-changelog.pl 2 Dec 2004 11:10:20 - 0.327 +++ lk-changelog.pl 4 Mar 2005 02:36:50 - 0.328 @@ -9,5 +9,4 @@ # Vitezslav Samel <[EMAIL PROTECTED]> # -# $Id: lk-changelog.pl,v 0.327 2004/12/02 11:10:20 emma Exp $ # -- # Distribution of this script is permitted under the terms of the @@ -117,4 +116,5 @@ 'davej:codemonkey.org.uk' => 'Dave Jones', 'davej:delerium.codemonkey.org.uk' => 'Dave Jones', +'davej:delerium.kernelslacker.org' => 'Dave Jones', 'davej:wopr.codemonkey.org.uk' => 'Dave Jones', 'davem:cheetah.ninka.net' => 'David S. Miller', @@ -152,4 +152,5 @@ 'aaron.baranoff:tsc.tdk.com' => 'Aaron Baranoff', 'abbotti:mev.co.uk' => 'Ian Abbott', +'abem.se:shinybook.infradead.org' => 'Per Hedblom', 'abraham:2d3d.co.za' => 'Abraham van der Merwe', 'abslucio:terra.com.br' => 'Lucio Maciel', @@ -167,4 +168,5 @@ 'acme:dhcp197.conectiva' => 'Arnaldo Carvalho de Melo', 'acme:parisc.kerneljanitors.org' => 'Arnaldo Carvalho de Melo', +'acme:toy.ghostprotocols.net' => 'Arnaldo Carvalho de Melo', 'acme:toy.kerneljanitors.org' => 'Arnaldo Carvalho de Melo', 'acurtis:onz.com' => 'Allen Curtis', @@ -222,4 +224,5 @@ 'ak:suse.de' => 'Andi Kleen', 'akepner:sgi.com' => 'Arthur Kepner', +'akeptner:sgi.com' => 'Arthur Kepner', 'akiyama.nobuyuk:jp.fujitsu.com' => 'Akiyama Nobuyuki', 'akm:osdl.org' => 'Andrew Morton', # typo? @@ -241,7 +244,10 @@ 'albert:users.sf.net' => 'Albert Cahalan', 'albert:users.sourceforge.net' => 'Albert Cahalan', +'albert_herranz:yahoo.es' => 'Albert Herranz', +'albertcc:tw.ibm.com' => 'Albert Lee', 'albertogli:telpin.com.ar' => 'Alberto Bertogli', 'alborchers:steinerpoint.com' => 'Al Borchers', 'alessandro.zummo:towertech.it' => 'Alessandro Zummo', +'alex.butcher:assursys.co.uk' => 'Alex Butcher', 'alex.kern:gmx.de' => 'Alexander Kern', 'alex.kiernan:gmail.com' => 'Alex Kiernan', @@ -292,4 +298,5 @@ 'andreas:xss.co.at' => 'Andreas Haumer', 'andrej.filipcic:ijs.si' => 'Andrej Filipcic', +'andrew-lists:optusnet.com.au' => 'Andrew Dennison', 'andrew.grover:intel.com' => 'Andy Grover', # "Andy" to match former entries 'andrew.patterson:hp.com' => 'Andrew Patterson', @@ -378,4 +385,5 @@ 'baldrick:wanadoo.fr' => 'Duncan Sands', 'ballabio_dario:emc.com' => 'Dario Ballabio', +'baris:idealteknoloji.com' => 'M. Baris Demiray', 'barrow_dj:yahoo.com' => 'D. J. Barrow', 'barryn:pobox.com' => 'Barry K. Nathan', # lbdb @@ -384,4 +392,5 @@ 'bart:samwel.tk' => 'Bart Samwel', 'baruch:ev-en.org' => 'Baruch Even', +'basic:mozdev.org' => 'Pang Lih Wuei', 'bastian:waldi.eu.org' => 'Bastian Blank', 'bbosch:iphase.com' => 'Bradley A. Bosch', @@ -390,4 +399,5 @@ 'bcollins:debian.org' => 'Ben Collins', 'bcrl:bob.home.kvack.org' => 'Benjamin LaHaise', +'bcrl:kvack.org' => 'Benjamin LaHaise', 'bcrl:redhat.com' => 'Benjamin LaHaise', 'bcrl:toomuch.toronto.redhat.com' => 'Benjamin LaHaise', # guessed @@ -395,6 +405,8 @@ 'bde:nwlink.com' => 'Bruce D. Elliott', 'bdschuym:pandora.be' => 'Bart De Schuymer', +'bdschuym:telenet.be' => 'Bart De Schuymer', 'bdshuym:pandora.be' => 'Bart De Schuymer', # it's typo IMHO 'beattie:beattie-home.net' => 'Brian Beattie', # from david.nelson
Re: Page fault scalability patch V18: Overview
Hi Darren On Fri, 04 Mar 2005, Darren Williams wrote: > Hi Christoph > > On Tue, 01 Mar 2005, Christoph Lameter wrote: > > > Is there any chance that this patchset could go into mm now? This has been > > discussed since last August > > > > Changelog: > > > > V17->V18 Rediff against 2.6.11-rc5-bk4 > > Just applied this patch against 2.6.11, however with the patch applied > and all the aditional config options not set, the kernel hangs at > Freeing unused kernel memory: 240kB freed > FYI: > > bootatomic prezero > OKon on > fail off on > fail off off > OKon off A bit extra info on the system: HP rx8620 Itanium(R) 2 16way > > > V16->V17 Do not increment page_count in do_wp_page. Performance data > > posted. > > V15->V16 of this patch: Redesign to allow full backback > > for architectures that do not supporting atomic operations. > > > > An introduction to what this patch does and a patch archive can be found on > > http://oss.sgi.com/projects/page_fault_performance. The archive also has the > > result of various performance tests (LMBench, Microbenchmark and > > kernel compiles). > > > > The basic approach in this patchset is the same as used in SGI's 2.4.X > > based kernels which have been in production use in ProPack 3 for a long > > time. > > > > The patchset is composed of 4 patches (and was tested against > > 2.6.11-rc5-bk4): > > > [SNIP] > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-ia64" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > Darren Williams > [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/ -- Darren Williams [EMAIL PROTECTED] -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][3/10] verify_area cleanup : sound
This patch converts verify_area to access_ok in sound/
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
diff -urp linux-2.6.11-orig/sound/core/hwdep.c linux-2.6.11/sound/core/hwdep.c
--- linux-2.6.11-orig/sound/core/hwdep.c2005-03-02 08:38:34.0
+0100
+++ linux-2.6.11/sound/core/hwdep.c 2005-03-03 22:24:20.0 +0100
@@ -223,7 +223,7 @@ static int snd_hwdep_dsp_load(snd_hwdep_
/* check whether the dsp was already loaded */
if (hw->dsp_loaded & (1 << info.index))
return -EBUSY;
- if (verify_area(VERIFY_READ, info.image, info.length))
+ if (!access_ok(VERIFY_READ, info.image, info.length))
return -EFAULT;
err = hw->ops.dsp_load(hw, );
if (err < 0)
diff -urp linux-2.6.11-orig/sound/core/seq/seq_clientmgr.c
linux-2.6.11/sound/core/seq/seq_clientmgr.c
--- linux-2.6.11-orig/sound/core/seq/seq_clientmgr.c2005-03-02
08:37:48.0 +0100
+++ linux-2.6.11/sound/core/seq/seq_clientmgr.c 2005-03-03 22:24:20.0
+0100
@@ -375,7 +375,7 @@ static ssize_t snd_seq_read(struct file
if (!(snd_seq_file_flags(file) & SNDRV_SEQ_LFLG_INPUT))
return -ENXIO;
- if (verify_area(VERIFY_WRITE, buf, count))
+ if (!access_ok(VERIFY_WRITE, buf, count))
return -EFAULT;
/* check client structures are in place */
diff -urp linux-2.6.11-orig/sound/isa/sb/emu8000_patch.c
linux-2.6.11/sound/isa/sb/emu8000_patch.c
--- linux-2.6.11-orig/sound/isa/sb/emu8000_patch.c 2005-03-02
08:37:49.0 +0100
+++ linux-2.6.11/sound/isa/sb/emu8000_patch.c 2005-03-03 22:24:20.0
+0100
@@ -183,10 +183,10 @@ snd_emu8000_sample_new(snd_emux_t *rec,
}
if (sp->v.mode_flags & SNDRV_SFNT_SAMPLE_8BITS) {
- if (verify_area(VERIFY_READ, data, sp->v.size))
+ if (!access_ok(VERIFY_READ, data, sp->v.size))
return -EFAULT;
} else {
- if (verify_area(VERIFY_READ, data, sp->v.size * 2))
+ if (!access_ok(VERIFY_READ, data, sp->v.size * 2))
return -EFAULT;
}
diff -urp linux-2.6.11-orig/sound/oss/btaudio.c linux-2.6.11/sound/oss/btaudio.c
--- linux-2.6.11-orig/sound/oss/btaudio.c 2005-03-02 08:37:50.0
+0100
+++ linux-2.6.11/sound/oss/btaudio.c2005-03-03 22:24:20.0 +0100
@@ -558,7 +558,7 @@ static ssize_t btaudio_dsp_read(struct f
__s16 __user *dst = (__s16 __user *)(buffer + ret);
__s16 avg;
int n = ndst>>1;
- if (0 != verify_area(VERIFY_WRITE,dst,ndst)) {
+ if (!access_ok(VERIFY_WRITE, dst, ndst)) {
if (0 == ret)
ret = -EFAULT;
break;
@@ -574,7 +574,7 @@ static ssize_t btaudio_dsp_read(struct f
__u8 *src = bta->buf_cpu + bta->read_offset;
__u8 __user *dst = buffer + ret;
int n = ndst;
- if (0 != verify_area(VERIFY_WRITE,dst,ndst)) {
+ if (!access_ok(VERIFY_WRITE, dst, ndst)) {
if (0 == ret)
ret = -EFAULT;
break;
@@ -587,7 +587,7 @@ static ssize_t btaudio_dsp_read(struct f
__u16 *src = (__u16*)(bta->buf_cpu + bta->read_offset);
__u16 __user *dst = (__u16 __user *)(buffer + ret);
int n = ndst>>1;
- if (0 != verify_area(VERIFY_WRITE,dst,ndst)) {
+ if (!access_ok(VERIFY_WRITE,dst,ndst)) {
if (0 == ret)
ret = -EFAULT;
break;
diff -urp linux-2.6.11-orig/sound/oss/soundcard.c
linux-2.6.11/sound/oss/soundcard.c
--- linux-2.6.11-orig/sound/oss/soundcard.c 2005-03-02 08:38:09.0
+0100
+++ linux-2.6.11/sound/oss/soundcard.c 2005-03-03 22:24:20.0 +0100
@@ -341,11 +341,11 @@ static int sound_ioctl(struct inode *ino
if (len < 1 || len > 65536 || !p)
return -EFAULT;
if (_SIOC_DIR(cmd) & _SIOC_WRITE)
- if ((err = verify_area(VERIFY_READ, p, len)) < 0)
- return err;
+ if (!access_ok(VERIFY_READ, p, len))
+ return -EFAULT;
if (_SIOC_DIR(cmd) & _SIOC_READ)
- if ((err = verify_area(VERIFY_WRITE, p, len)) < 0)
- return err;
+ if (!access_ok(VERIFY_WRITE, p, len))
+ return -EFAULT;
}
DEB(printk("sound_ioctl(dev=%d, cmd=0x%x, arg=0x%x)\n", dev, cmd, arg));
if (cmd
Re: [Alsa-devel] Re: intel 8x0 went silent in 2.6.11
Yes, flipping back to the 2.6.10 kernel resolves the sound issue through the docking station so that everything runs without incident. Though I'd like to see/assist in resolving the issue for future releases :). On Thu, 3 Mar 2005, Andrew Morton wrote: Mark Canter <[EMAIL PROTECTED]> wrote: To close this issue out of the LKML and alsa-devel, a bug report has been written. It appears to be an issue with the 'headphone jack sense' (as kde labels it). The issue is in the way the 8x0 addresses the docking station/port replicator's audio output jack. The mentioned quick fix does not work for using the ds/pr audio output, but does resolve it for a user that is only using headphones/internal speakers. But there was a behavioural change: applications which worked in 2.6.10 don't work in 2.6.11, is that correct? If so, the best course of action is to change the kernel so those applications work again. Can that be done? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/3] openfirmware: adds sysfs nodes for openfirmware devices
> Reviewing the 'compatible' values in my device-tree, I definately agree. > I can hack the pmac_zilog driver to test this out further - I've just > been using my airport card. > > Are there any other "invalid" characters for the compatible property? > CRLF would work, but these values (as a group) need to be put into > modules.ofmap as well as passed via environment variables for hotplug. > As such, CRLF isn't really easiest choice to work with. I don't think any value is "invalid". Not sure what is best to use ... maybe '#' ? never seen it in there so far ... but who knows ... > Is whitespace (in any form) allowed in the compatible value? Yes. For example: "Power Macintosh" is a typical compatible value in the root of the devive tree. Maybe "tab" ? Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
