Re: [PATCH 9/11] Panic delay fix
Hi! > >>We'd have to audit and figure out what udelays are for hardware and > >>which are not, but the evidence is that the vast majority of them are > >>for hardware and not needed for virtualization. > >> > > > >Which is irrelevant since the hardware drivers won't be used in a > >virtualised environment with any kind of performance optimisation. > > > > Which is why an audit is irrelevant for the most part. Note on the > performance below. You know it is ugly. Alan demonstrated it even hurts performance, but being ugly is the main problem. If you _need_ to avoid udelay() in some cases, introduce udelay_unless_virtualized(), and switch few users to it. Just globaly defining udelay to nop is _ugly_. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 19/31] clockevents: i386 drivers
On Wed, 13 Dec 2006 14:02:11 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > Add clockevent drivers for i386: lapic (local) and PIT (global). Update > the timer IRQ to call into the PIT driver's event handler and the > lapic-timer IRQ to call into the lapic clockevent driver. The > assignement of timer functionality is delegated to the core framework > code and replaces the compile and runtime evalution in > do_timer_interrupt_hook() > > Use the clockevents broadcast support and implement the lapic_broadcast > function for ACPI. > > No changes to existing functionality. This patch breaks the NMI on my crufty old dual-PIII supermicro p6dbe machine: Testing NMI watchdog ... CPU#0: NMI appears to be stuck (26->26)! CPU#1: NMI appears to be stuck (0->0)! vmm:/home/akpm> cat /proc/interrupts CPU0 CPU1 0: 59 0 IO-APIC-edge timer 1: 2 0 IO-APIC-edge i8042 2: 0 0XT-PIC-XTcascade 6: 3 0 IO-APIC-edge floppy 8: 1 0 IO-APIC-edge rtc 10:192 61 IO-APIC-fasteoi aic7xxx 11: 1339 31 IO-APIC-fasteoi eth0 12: 3 1 IO-APIC-edge i8042 15: 3067 7 IO-APIC-edge ide1 NMI: 26 0 LOC: 58665 58663 ERR: 0 MIS: 0 and it isn't changing. See http://userweb.kernel.org/~akpm/nmi-prob/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] UML hang with 100% CPU
> > Strangely enough after continuing in gdb, UML is back to normal, and I > > can't make it hang any more. It must be something timing related. > > Can you see if the patch below fixes it? Yay! Got my nice fast UML back instead of ugly slow QEmu ;) Seems to work perfectly now. Thanks, Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Wed, 2007-02-14 at 23:28 -0800, v j wrote: > Open = 3rd party Linux drivers can be loaded. Closed = No third party > Linux drivers can be loaded. Then go ahead and use Windows CE or VxWorks. By your silly definition they are pretty open. Xav - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Unify pcspeaker platform device code between i386/x86-64
> It's always seemed broken (though perhaps this was a distro bug?) in > module form, so I've been compiling it in to get it to work. Must have been a distro bug. It should have worked before as long as the config was enabled. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix mempolicy's check on a system with memory-less-node take4
On Thursday 15 February 2007 08:32, KAMEZAWA Hiroyuki wrote: > > please ack if O.K. Ok for me -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 000/196] V4L/DVB updates
On Thu, Feb 15, 2007 at 03:59:55AM -0200, Mauro Carvalho Chehab wrote: > Basically, this series adds support for a bunch of newer cards and newer > drivers, do some relevant cleanups on cx88 (improving source code > readability and reducing binary code size), adds FM radio support on > pvrusb2 and do several other fixes and improvements. > > A more detailed log: > > [removed 100+ lines of stuff] > > > PS.: Due to the size of this series, I'm not mailbombing them into LKML. > > V4L/DVB development is hosted at http://linuxtv.org Why weren't these submitted in smaller batches? Why were all these patches held back before releasing any? Heikki Orsila - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Wed, 2007-02-14 at 22:27 -0800, v j wrote: > You are right. I have not contributed anything to Linux. Except one > small patch to the MTD code. However, I don't think that is the point > here. I am perfectly willing to live with the way Linux is today. I am > telling you as a user that if Linux continues on the current path it > will become less and less attractive to Embedded Users. Guess what ? No one cares. If being serious about the GPL means that free-riders like you, who take and never give back, prefer to go elsewhere, that's not a problem. No one looses anything. BTW, the thousands of different predictions "if linux doesn't do X, it'll never be successful" get old pretty quicly. Xav - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
Dave Jones wrote: On Wed, Feb 14, 2007 at 10:46:13PM -0800, v j wrote: > Using our source code would not benefit anybody but > our competitors. This excuse has been given time and time again, and repeatedly been proven false. And as soon as one of your competitors makes their drivers open, guess which one gets 1000+ free developers working on their code ? Customers also like to buy hardware where they -know- support will not disappear in a year, when the vendor releases a new chip. In fact, in some markets, the engineers who wrote the code have often moved to the next project, by the time the customers actually get their hands on the end result. Open source means that problems found in real world field testing can be readily debugged and fixed. 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: PROBLEM: 2.6.19.1 Oops while doing Disk IO + playing sound, 2.6.20 too
On Thu 15-02-07 00:33:31, Frank Hartmann wrote: > Jan Kara <[EMAIL PROTECTED]> writes: > > > Yes I see some correlation. Again it seems there is a problem with buffers > > attached to a page which got truncated but Private flag of the page stayed. > > It's probably not important but just out of curiosity - do you have > > CONFIG_LBD (large block device) set? I'd just like to verify that page_bufs > > was NULL when it was passed to walk_page_buffers(). > > fantasio:~/tmp/linux-2.6.20$ fgrep CONFIG_LBD .config > # CONFIG_LBD is not set OK, thanks. Then I'm slightly confused as the offset 0x2d in struct buffer_head is somewhere in b_assoc_buffers which is never dereferenced. Can you run gdb on vmlinux from the 2.6.20 kernel and send me the output of 'disass walk_page_buffers'? Thanks. > > You said 2.6.17 worked for you, didn't you? How long does it take to > > reproduce the problem? If it is reasonably easy (e.g. a few hours), could > > you trace back when the problem started happening? If you could narrow that > > problem down to a single patch (using git-bisect), that would be great. > > Yes I said that. At least I did not notice it happen:) > Reproduction seems easy. So I will try. Great. > I have some problem: I am not sufficiently familar with git! > > I found > http://www.kernel.org/pub/software/scm/git/docs/howto/isolate-bugs-with-bisect.txt > Is this the way to do a git-bisect? Yes, that's it. > From where do I get the 'labels' for good(2.6.17) and bad(2.6.20)? git bisect bad v2.6.20 git bisect good v2.6.17 (or maybe you could start with 'git bisect bad v2.6.19' if that was also failing for you). Git will spit out something like: Bisecting: 9467 revisions left to test after this [ebdea46fecae40c4d7effcd33f40918a37a1df4b] Merge branch 'devel' of master.kernel.org:/home/rmk/linux-2.6-arm After you test kernel from the revision 'ebdea46fecae40c4d7effcd33f40918a37a1df4b', you do git bisect good/bad ebdea46fecae40c4d7effcd33f40918a37a1df4 and you'll get next revision to check. I hope it's clearer now. Honza -- Jan Kara <[EMAIL PROTECTED]> SuSE CR Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Unify pcspeaker platform device code between i386/x86-64
Linux Kernel Mailing List wrote: Gitweb: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=62cc49396e593dd71c6595302bb10b085aefbfa5 Commit: 62cc49396e593dd71c6595302bb10b085aefbfa5 Parent: 40d22c1b5675e428b3f3f9a945d0bd62e94ca2f1 Author: Andi Kleen <[EMAIL PROTECTED]> AuthorDate: Tue Feb 13 13:26:26 2007 +0100 Committer: Andi Kleen <[EMAIL PROTECTED]> CommitDate: Tue Feb 13 13:26:26 2007 +0100 [PATCH] x86: Unify pcspeaker platform device code between i386/x86-64 Trivial cleanup. Only change is that it is always compiled in now on x86-64 like on i386. Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> THANK YOU. It's always seemed broken (though perhaps this was a distro bug?) in module form, so I've been compiling it in to get it to work. 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] aio: fix kernel bug when page is temporally busy
Ken Chen wrote
> It might shut up kernel
> panic by eliminate double calls to aio_complete(), but it will
> silently introduce data corruption.
I had got kernel panic after an hour of aiostress running.
After patching I have not got aiostress massage
"verify error, file %s offset %Lu contents (offset:bad:good):\n"
during 5 hour aiostress running with 'verify' option.
Looking closely into aiostress.c
ftp://ftp.suse.com/pub/people/mason/utils/aio-stress.c
we can see that this program may write in random mode THE SAME
contents to the same file offset asynchronously from different
buffers and do not cure about it. Does Ken consider that kernel
panic is the best way to prevent data corruption in such kind
of programs?
> So any error value returned from invalidate_inode_pages2_range() has
> to be taken seriously in the direct IO submit path instead of dropping
> it to the floor.
If invalidate_inode_pages2_range() will return EIOCBRETRY as the patch
"aio: fix kernel bug when page is temporally busy"
sets then do_sync_read/write() will not drop IO submit but will retry
it:
for (;;) {
ret = filp->f_op->aio_read(, , 1, kiocb.ki_pos);
if (ret != -EIOCBRETRY)
break;
wait_on_retry_sync_kiocb();
}
And do_sync_read/write() will not return EIO if page is busy
as it does now, before patching.
Ken Chen wrote:
> I also think the original patch is wrong.
What do you mean saying 'also'?
Leonid
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: xfs internal error on a new filesystem
On Wed, Feb 14, 2007 at 10:24:27AM +, Ramy M. Hassan wrote: > Hello, > We got the following xfs internal error on one of our production servers: > > Feb 14 08:28:52 info6 kernel: [238186.676483] Filesystem "sdd8": XFS > internal error xfs_trans_cancel at line 1138 of file fs/xfs/xfs_trans.c. > Caller 0xf8b906e7 Real stack looks to be: xfs_trans_cancel xfs_mkdir xfs_vn_mknod xfs_vn_mkdir vfs_mkdir sys_mkdirat sys_mkdir We aborted a transaction for some reason. We got an error somewhere in a mkdir while we had a dirty transaction. Unfortunately, this tells us very little about the error that actually caused the shutdown. What is your filessytem layout? (xfs_info ) How much memory do you have and were you near enomem conditions? > We were able to unmount/remount the volume (didn't do xfs_repair because we > thought it might take long time, and the server was already in production > at the moement) Risky to run a production system on a filesystem that might be corrupted. You risk further problems if you don't run repair > The file system was created less than 48hours ago, and 370G of sensitve > production data was moved to the server before it xfs crash. So that's not a "new" filesystem at all... FWIW, did you do any offline testing before you put it into production? > System details : > Kernel: 2.6.18 > Controller: 3ware 9550SX-8LP (RAID 10) Can you describe your dm/md volume layout? > We are wondering here if this problem is an indicator to data corruption on > disk ? It might be. You didn't run xfs_check or xfs_repair, so we don't know if there is any on disk corruption here. > is it really necessary to run xfs_repair ? If you want to know if you haven't left any landmines around for the filesystem to trip over again. i.e. You should run repair after any sort of XFS shutdown to make sure nothing is corrupted on disk. If nothing is corrupted on disk, then we are looking at an in-memory problem > Do u recommend that we switch back to reiserfs ? Not yet. > Could it be a hardware related problems ? Yes. Do you have ECC memory on your server? Have you run memtest86? Were there any I/O errors in the log prior to the shutdown message? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.20 new perfmon code base + libpfm + pfmon
Andi,
On Wed, Feb 14, 2007 at 12:20:56AM +0100, Andi Kleen wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
> > > On Tue, 13 Feb 2007 10:48:39 -0800 Stephane Eranian <[EMAIL PROTECTED]>
> > > wrote:
> > > I have released another version of the perfmon new code base package.
> >
> > Can we have a bug push to get this merged up please?
>
> Yes, there certainly seems to be user interest in this.
>
> I've been merging the x86 specific infrastructure Stephane sent.
> So hopefully the basics are there already.
>
Yes, almost everything is in there now. Tony Luck told me he has integrated
the idle notifier for IA-64. I saw that the i386 version of the notifier
was recently integrated as well. So I think that for 2.6.21 we'll have
everything we need for i386, x86-64 and ia64. On MIPS and PowerPC,
a few things are still missing but they should be fixed soon.
On x86-64 and i386, the one last thing I would need that you do not already
have is in the NMI handler for the architectural perfmon to switch PERFCTR0
to PERFCTR1. This would allow certain events to be measured while the NMI
watchdog is active. This is needed on Intel Core-based processors where
certain events can ONLY be measured by PERFCTR0. The CPU_CLK_UNHALTED event
used by the watchdog can be measured by any counter.
I have attached the x86-64 patch for this. I can submit the i386 version
as well.
> The big open question was still the review of the syscall interface.
> Probably needs some determined reviewers.
>
Not a problem.
> I did a review of some of the basic low level code some time ago;
> there were some issues but I believe they are probably all resolved
> by now (but I haven't verified that recently)
>
Yes, all the changes and fixes you and Andrew had requested have been made.
changelog:
- for architectural perfmon support, switch from PERFCTR0 to PERFCTR1.
this does free PERFCTR0 which is the only counter supported for
certain
events on Intel Core-based processors.
signed-off-by: stephane eranian <[EMAIL PROTECTED]>
diff --exclude=.git -urp linux-2.6.20.base/arch/x86_64/kernel/nmi.c
linux-2.6.20/arch/x86_64/kernel/nmi.c
--- linux-2.6.20.base/arch/x86_64/kernel/nmi.c 2007-02-05 00:31:52.0
-0800
+++ linux-2.6.20/arch/x86_64/kernel/nmi.c 2007-02-09 09:44:29.0
-0800
@@ -275,7 +275,7 @@ int __init check_nmi_watchdog (void)
* 32nd bit should be 1, for 33.. to be 1.
* Find the appropriate nmi_hz
*/
- if (wd->perfctr_msr == MSR_ARCH_PERFMON_PERFCTR0 &&
+ if (wd->perfctr_msr == MSR_ARCH_PERFMON_PERFCTR1 &&
((u64)cpu_khz * 1000) > 0x7fffULL) {
nmi_hz = ((u64)cpu_khz * 1000) / 0x7fffUL + 1;
}
@@ -615,8 +615,8 @@ static int setup_intel_arch_watchdog(voi
(ebx & ARCH_PERFMON_UNHALTED_CORE_CYCLES_PRESENT))
goto fail;
- perfctr_msr = MSR_ARCH_PERFMON_PERFCTR0;
- evntsel_msr = MSR_ARCH_PERFMON_EVENTSEL0;
+ perfctr_msr = MSR_ARCH_PERFMON_PERFCTR1;
+ evntsel_msr = MSR_ARCH_PERFMON_EVENTSEL1;
if (!reserve_perfctr_nmi(perfctr_msr))
goto fail;
@@ -855,7 +855,7 @@ int __kprobes nmi_watchdog_tick(struct p
dummy &= ~P4_CCCR_OVF;
wrmsrl(wd->cccr_msr, dummy);
apic_write(APIC_LVTPC, APIC_DM_NMI);
- } else if (wd->perfctr_msr ==
MSR_ARCH_PERFMON_PERFCTR0) {
+ } else if (wd->perfctr_msr ==
MSR_ARCH_PERFMON_PERFCTR1) {
/*
* ArchPerfom/Core Duo needs to re-unmask
* the apic vector
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LIBATA] drives not detected
On 2/15/07, Patrick Ale <[EMAIL PROTECTED]> wrote: Good morning all, Now, when I boot up, I miss two drives, exactly the two connected to this promise card. I have another onboard Promise controller which works just fine, so the driver gets loaded properly, and since i see all my other disks but these two I think we can rule out a misconfiguration of the kernel config this time ;-) It would be nice if I'd also mention the kernel I use eh. It's linux-2.6-git8 Patrick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[LIBATA] drives not detected
Good morning all, Yesterday I replaced a Sil680 PCI add-on card for a Promise 2027x PCI add-on card. Now, when I boot up, I miss two drives, exactly the two connected to this promise card. I have another onboard Promise controller which works just fine, so the driver gets loaded properly, and since i see all my other disks but these two I think we can rule out a misconfiguration of the kernel config this time ;-) This is a snippet from my dmesg pata_pdc2027x :00:0b.0: version 0.74-ac5 ACPI: PCI Interrupt :00:0b.0[A] -> GSI 19 (level, low) -> IRQ 20 pata_pdc2027x :00:0b.0: PLL input clock 16799 kHz ata7: PATA max UDMA/133 cmd 0xf98a17c0 ctl 0xf98a1fda bmdma 0xf98a1000 irq 20 ata8: PATA max UDMA/133 cmd 0xf98a15c0 ctl 0xf98a1dda bmdma 0xf98a1008 irq 20 scsi7 : pata_pdc2027x scsi8 : pata_pdc2027x ATA: abnormal status 0x8 on port 0xf98a15df As you can see, scsi8 gives an abnormal status, which as we got pointed out this week is just a cosmetic error for "No drive attached/detected" and it's very right in that finding. But what about scsi7? no warning/error about no disks being attached nor a disk detection. To state the obvious: I see the disks being detected by the Promise BIOS when I boot the system,Primaiy master and Primaiy slave. Here is the lspci -vvv regarding the controller 00:0b.0 Mass storage controller: Promise Technology, Inc. 20269 (rev 02) (prog-if 85) Subsystem: Promise Technology, Inc. Ultra133TX2 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
Oh, I am sorry. Seems like the German courts have spoken. I am not sure about what, but they have spoken. Sorry for the confusion. On 2/15/07, Richard Knutsson <[EMAIL PROTECTED]> wrote: v j wrote: > On 2/14/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote: >> On Wed, 2007-02-14 at 21:16 -0800, v j wrote: >> > This is in reference to the following thread: >> > >> > http://lkml.org/lkml/2006/12/14/63 >> > >> > I am not sure if this is ever addressed in LKML, but linux is _very_ >> > popular in the embedded space. We (an embedded vendor) chose Linux 3 >> > years back because of its lack of royalty model, robustness and >> > availability of infinite number of open-source tools. >> >> >> I think you have a bit of a misunderstanding... Linux is not royalty >> free. Just the royalty is not in the form of cash, but in the form of >> having to give your improvements back to the open source world. > > Sure. But this is not legally binding. Please clarify! http://yro.slashdot.org/yro/04/07/23/1558219.shtml?tid=117=123 Richard Knutsson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Optimize generic get_unaligned / put_unaligned implementations.
Hi Andrew,
> > +#define get_unaligned(ptr) \
> > +({ \
> > + const struct { \
> > + union { \
> > + const int __un_foo[0]; \
> > + const __typeof__(*(ptr)) __un; \
> > + } __un __attribute__ ((packed));\
> > + } * const __gu_p = (void *) (ptr); \
> > + \
> > + __gu_p->__un.__un; \
> > })
>
> Can someone please tell us how this magic works? (And it does appear to
> work).
>
> It seems to assuming that the compiler will assume that members of packed
> structures can have arbitrary alignment, even if that alignment is obvious.
>
> Which makes sense, but I'd like to see chapter-and-verse from the spec or
> from the gcc docs so we can rely upon it working on all architectures and
> compilers from now until ever more.
I am far away from having any knowledge about the GCC internals and the
reason why this code works, but I've been told the generic way of
handling unaligned access is this:
#define get_unaligned(ptr) \
({ \
struct __attribute__((packed)) {\
typeof(*(ptr)) __v; \
} *__p = (void *) (ptr);\
__p->__v; \
})
#define put_unaligned(val, ptr) \
do {\
struct __attribute__((packed)) {\
typeof(*(ptr)) __v; \
} *__p = (void *) (ptr);\
__p->__v = (val); \
} while(0)
Actually I am using this code in the Bluetooth userspace library for
over two years now without any complaints.
Regards
Marcel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/15/07, Neil Brown <[EMAIL PROTECTED]> wrote: And as I understand it, an important principle in out community is freedom. If vj wants to take a particular moral/ethical stance, then he should be free to do that. Of course he will have to live with any consequences, as do we all. Yes, and one of the consequences is that people who disagree with his stance tell him off for it. Him, and everyone else who profits from distributing GPL licensed code without abiding by the very simple requirements of the GPL are parasites. They should stop. Legally they might not be required to.. and some of the best legal minds in the world think they are, if only the copyright holders would sue already.. but that's just a side issue. Trent - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
v j wrote: On 2/14/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote: If your mindset is "how much can I take take take without giving back back back" then personally I think you're sort of acting like a parasite in this context Ok so are thousands of others who are using Linux as their OS of choice in embedded systems. They are not doing this because they are eager to give back back. They are doing it because Linux provides compelling reasons for them to choose it. They could have very well chosen VxWorks or OSE too. They chose not to, but not because they were unwilling to be a parasite. I can't control how people think or the reasons behind their actions. Nor do I care. All I care about is that I don't have parasites hanging off me. -- Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.20 Oopses in xfrm_audit_log
Joy Latten wrote:
i upgraded to vanilla kernel 2.6.20 and while i was using strongswan
2.8.2 to setup an IPSEC VPN i got the following kernel Ooops.
I had successfully established the same tunnel a few times, but key
renegotiation caused a problem ( both ends did not renegotiate at the
same time so the tunnel was frozen ), i decided to kill the tunnel and
start a new one ( using ipsec auto --down tunnel & ipsec auto --up
tunnel ), while i was doing so, i got the oops.
BUG: unable to handle kernel NULL pointer dereference at virtual address
0188
printing eip:
c02fb85c
*pde =
Oops: [#1]
PREEMPT
Modules linked in: xfrm4_mode_tunnel usblp deflate zlib_deflate twofish
twofish_common serpent blowfish des cbc ecb blkcipher xcbc sha256 sha1
crypto_null xfrm4_tunnel tunnel4 ipcomp esp4 ah4 af_key autofs4 asb100
hwmon_vid hidp rfcomm l2cap bluetooth sunrpc nf_conntrack_netbios_ns
ipt_LOG xt_limit xt_mark xt_state xt_tcpudp iptable_filter
ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 xt_MARK
iptable_mangle ip_tables x_tables binfmt_misc sd_mod ipv6 sg hfsplus
video button ac lp parport_pc parport floppy nvram usb_storage scsi_mod
libusual usbhid hid ehci_hcd snd_via82xx snd_ac97_codec ac97_bus
ohci1394 snd_seq_dummy uhci_hcd ieee1394 snd_seq_oss snd_seq_midi_event
snd_seq snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc
snd_mpu401_uart snd_rawmidi snd_seq_device snd via_agp agpgart
i2c_viapro soundcore eepro100 i2c_core b44 pcspkr mii shpchp usbcore dm_mod
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246 (2.6.20 #1)
EIP is at xfrm_audit_log+0x4cc/0x580
eax: ecb71061 ebx: c039d160 ecx: edx: 0021
esi: 01f4 edi: 0255 ebp: esp: e8cd5a18
ds: 007b es: 007b ss: 0068
Process pluto (pid: 27486, ti=e8cd4000 task=d3557070 task.ti=e8cd4000)
Stack: c17d2ea0 c0354bf1 e183f9c0 0003 c03ac59c e1399800 0001
0003
f8d0a450 0001 0286 e8cd5a6c c011506b
0286
f73cb8c0 0246 c17d2ea0 f73cb8c0 f8d03c67
Call Trace:
[] __wake_up+0x4b/0x80
[] pfkey_broadcast+0x137/0x1b0 [af_key]
[] pfkey_send_policy_notify+0xef/0x1a0 [af_key]
[] local_bh_enable+0x2e/0xa0
[] xfrm_get_policy+0x2b7/0x2f0
[] xfrm_get_policy+0x0/0x2f0
[] xfrm_user_rcv_msg+0x102/0x1b0
[] xfrm_user_rcv_msg+0x0/0x1b0
[] netlink_run_queue+0x82/0x120
[] xfrm_netlink_rcv+0x28/0x40
[] netlink_data_ready+0x12/0x50
[] netlink_sendskb+0x21/0x40
[] netlink_sendmsg+0x230/0x310
[] sock_aio_write+0x11d/0x130
[] avc_has_perm+0x5a/0x70
[] do_sync_write+0xd5/0x120
[] autoremove_wake_function+0x0/0x50
[] vfs_write+0x177/0x180
[] sys_write+0x41/0x70
[] syscall_call+0x7/0xb
===
Code: 8b 44 24 70 c1 e2 08 c1 e8 08 09 c2 0f b7 c2 89 44 24 08 8b 44 24
48 89 04 24 e8 10 eb e3 ff e9 bc fc ff ff 8b 8c 24 c0 00 00 00 <8b> 91
88 01 00 00 0f b7 99 82 00 00 00 85 d2 0f 85 64 fc ff ff
EIP: [] xfrm_audit_log+0x4cc/0x580 SS:ESP 0068:e8cd5a18
This is similar to another bug reported last month.
Here is the patch I sent out then. Please let me know
how it goes.
Regards,
Joy
Signed-off-by: Joy Latten <[EMAIL PROTECTED]>
diff -urpN linux-2.6.19.orig/net/xfrm/xfrm_policy.c
linux-2.6.19/net/xfrm/xfrm_policy.c
--- linux-2.6.19.orig/net/xfrm/xfrm_policy.c2007-01-02 14:24:14.0
-0600
+++ linux-2.6.19/net/xfrm/xfrm_policy.c 2007-01-02 14:28:24.0 -0600
@@ -2003,6 +2003,9 @@ void xfrm_audit_log(uid_t auid, u32 sid,
if (audit_enabled == 0)
return;
+ if ((x == NULL) && (xp == NULL))
+ return;
+
audit_buf = audit_log_start(current->audit_context, GFP_ATOMIC, type);
if (audit_buf == NULL)
return;
diff -urpN linux-2.6.19.orig/net/xfrm/xfrm_user.c
linux-2.6.19/net/xfrm/xfrm_user.c
--- linux-2.6.19.orig/net/xfrm/xfrm_user.c 2007-01-02 14:24:14.0
-0600
+++ linux-2.6.19/net/xfrm/xfrm_user.c 2007-01-02 14:28:14.0 -0600
@@ -1268,10 +1268,6 @@ static int xfrm_get_policy(struct sk_buf
xp = xfrm_policy_bysel_ctx(type, p->dir, >sel, tmp.security,
delete);
security_xfrm_policy_free();
}
- if (delete)
- xfrm_audit_log(NETLINK_CB(skb).loginuid, NETLINK_CB(skb).sid,
- AUDIT_MAC_IPSEC_DELSPD, (xp) ? 1 : 0, xp, NULL);
-
if (xp == NULL)
return -ENOENT;
@@ -1289,6 +1285,10 @@ static int xfrm_get_policy(struct sk_buf
} else {
if ((err = security_xfrm_policy_delete(xp)) != 0)
goto out;
+
+ xfrm_audit_log(NETLINK_CB(skb).loginuid, NETLINK_CB(skb).sid,
+ AUDIT_MAC_IPSEC_DELSPD, (xp) ? 1 : 0, xp, NULL);
+
c.data.byid = p->index;
c.event = nlh->nlmsg_type;
c.seq = nlh->nlmsg_seq;
Hi Joy,
just to let you know that since i've applied you patch, everything
Re: [RFC][PATCH 6/6] automatic tuning applied to some kernel components
Eric W. Biederman wrote: Nadia Derbey <[EMAIL PROTECTED]> writes: But, what do you do with Oracle that's asking maxfiles to be set to 0x1, while the default value might be enough for a system that's not running Oracle. I'm afraid that giving boot time values to the max_* tunables we will loose all the benefits from /proc (or /sys): it is impossible to anticipate what an OS will be used for. So allowing such things to be changed without having to reboot the machine is in my mind quite a powerful feature we should keep taking adavntage of. I'm not saying remove user spaces' ability to set the denial-of-service limits. I'm saying if they need to be frequently changed we need to update the default so they are higher by default. There really is no cost in moving those values up and down it is just an arbitrary integer used in comparisons. But if we can make a good guess that still catches runaway programs before they kill the machine but also allows more programs to work out of the box we are in better shape. OK, happy to see we are on the same wavelength (and sorry for misunderstanding what you were saying ;-) ) Regards, Nadia - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
v j wrote: On 2/14/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote: On Wed, 2007-02-14 at 21:16 -0800, v j wrote: > This is in reference to the following thread: > > http://lkml.org/lkml/2006/12/14/63 > > I am not sure if this is ever addressed in LKML, but linux is _very_ > popular in the embedded space. We (an embedded vendor) chose Linux 3 > years back because of its lack of royalty model, robustness and > availability of infinite number of open-source tools. I think you have a bit of a misunderstanding... Linux is not royalty free. Just the royalty is not in the form of cash, but in the form of having to give your improvements back to the open source world. Sure. But this is not legally binding. Please clarify! http://yro.slashdot.org/yro/04/07/23/1558219.shtml?tid=117=123 Richard Knutsson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug
On Thursday, 15 February 2007 07:34, Gautham R Shenoy wrote: > On Wed, Feb 14, 2007 at 10:43:35PM +0100, Rafael J. Wysocki wrote: > > Hi, > > > > On Wednesday, 14 February 2007 15:40, Gautham R Shenoy wrote: > > > Hello Everybody, > > > > > > This is an experiment towards process_freezer based implementation > > > of cpu-hotplug. This is mainly based on ideas of Andrew Morton, > > > Ingo Molnar and Paul Mckenney featured in the discussion > > > http://lkml.org/lkml/2007/1/31/323. > > > > > > This is an absolute bare-minimal implementation to check the feasibility > > > of using process freezer for cpu-hotplug. > > > > > > The patchset comprises of four patches. > > > o PATCH 1/4: Core implementation of freezer-based-hotplug. > > > o PATCH 2/4: Revert changes to workqueue to make it work with the > > > freezer-cpu-hotplug. > > > o PATCH 3/4: Eliminate hotcpu subsystem mutexes from sched and slab. > > > o PATCH 4/4: Eliminate lock_cpu_hotplug from the kernel. > > > > I think two things are missing: > > > > 1) We should make sure there are not PF_NOFREEZE tasks running when a CPU > > is removed (when one is added probably too). For this purpose we can add a > > parameter to freeze_processes() that will tell it to ignore PF_NOFREEZE, but > > at the same time we'll have to change all kernel threads that set > > PF_NOFREEZE > > to call try_to_freeze() anyway. I can do that, but it will take me a > > couple of > > days. > > Why should we make sure that PF_NOFREEZE tasks are also frozen for > cpu hotplug? Instead, we can create an infrastructure which allows threads to > specify for the scenarios they would want to be excempted from freeze. > Something like what Paul has suggested in > http://lkml.org/lkml/2007/1/31/323. That way, threads which have nothing > to do with the online_cpu_map or with handling of cpu-hotplug events can > mark themselves to be exempted from being frozen for cpu hotplug. I think all kernel threads should call try_to_freeze() in suitable places anyway if we are going to use the freezer for anything more than just the suspend. In other words, they all should be _able_ to freeze if necessary. > Once this is achieved, it's all about classifying the threads into > according to their NO_FREEZE needs :) Yes, but I think it's just a generalization of ingoring PF_NOFREEZE. If all kernel threads are able to freeze, we can mark them as "freeze for CPU hotplug" or "freeze for kprobes", or "freeze for suspend" etc. and call the freezer with the appropriate parameter. BTW, what happens to a process running on a CPU being removed? > > 2) We have to change the PM code to stop using CPU hotplug for disabling > > nonboot CPUs. ;-) > > Just wondering, how hard is that ? Hmmm. In fact the problem is that the suspend code freezes tasks and then calls disable_nonboot_cpus() which uses (_)cpu_down/up(). In principle we could make disable_nonboot_cpus() call some lower-level routines to avoid the freezing of tasks, _but_ the suspend code may freeze too few tasks (ie. we may want to freeze more tasks for the CPU hotplug). Thus I think we should do something like this: suspend:CPU hotplug: freeze_processes(SUSPEND) ... ... freeze_processes(CPU_HOTPLUG) ... ... ... thaw_processes(CPU_HOTPLUG) thaw_processes(SUSPEND) ... so freeze_processes() should be reentrant, at least for different values of the argument. All in all, I think we should start from modifying the freezer and the classification of processes with respect to the freezing. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
v j wrote: On 2/14/07, Randy Dunlap <[EMAIL PROTECTED]> wrote: At least one of us is confused about that an embedded User is. It seems to me that you are an embedded developer, not User. I doubt that most Embedded Users care what their OS is, or even know what an OS is. I am not sure what the difference is. We are trying to use Linux to support our application. It may be that Linux has a bug, or our application. When it is Linux, that has the problem, I have tried to inform the community of that. The difference is that you are selling it and not contributing back. I think the legal term is something like distributing copyright material without a license. > Not everybody has to be a contributor. The reason Linux is popular is > because of its openness. Take that away and see where it goes. We seem to have different definitions of open and closed. Open = 3rd party Linux drivers can be loaded. Closed = No third party Linux drivers can be loaded. So most linux kernel developers chose to contribute to Linux because they prefer something closer to the GPL's notion of open (assuming your definitions are in the context of the legality of redistributing the end result). Don't take offence, but most of us don't _want_ the embedded developers who contribute nothing back. Even if you tripled the total Linux userbase, how would that be a good thing for anyone but yourself? Now imagine if nobody contributed anything back. The reason Linux is good enough that you chose in the first place is because of everyone contributing back. Why would we want to undermine that? My aim for Linux is not to have it shut down VxWorks, or to have a huge userbase, but to be the best OS out there. Maybe that helps explain the why others here don't share your opinion? With that said, there are some reasonable free BSD licensed operating systems out there that you can use without opening your source. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Thu, 2007-02-15 at 00:04 -0800, v j wrote: > On 2/14/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > > On Wed, 2007-02-14 at 21:16 -0800, v j wrote: > > > This is in reference to the following thread: > > > > > > http://lkml.org/lkml/2006/12/14/63 > > > > > > I am not sure if this is ever addressed in LKML, but linux is _very_ > > > popular in the embedded space. We (an embedded vendor) chose Linux 3 > > > years back because of its lack of royalty model, robustness and > > > availability of infinite number of open-source tools. > > > > > > I think you have a bit of a misunderstanding... Linux is not royalty > > free. Just the royalty is not in the form of cash, but in the form of > > having to give your improvements back to the open source world. > > Sure. But this is not legally binding. that's a legal conclusion that is ... iffy at least. I'm not a lawyer, but I suggest you talk to a real one before making that conclusion, and you'll see it's not as simple as that. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Thursday February 15, [EMAIL PROTECTED] wrote: > On 2/15/07, Neil Brown <[EMAIL PROTECTED]> wrote: > > [..] then it is less clear what people believe > > Another area where it is less clear what people believe is if you are > distributing the module separately to the kernel, but, as I understand > it, vj says he is not. > > > But of course the person who's opinion really counts is the judge. > > The judge's opinion only counts if you actually get to court and > manage to put up a legal defense. > > > So you need to get legal advice. > > Or, ya know, you could take the moral/ethical advice that you're being > a worm and stop now. I don't think we do ourselves any favours by calling people names And as I understand it, an important principle in out community is freedom. If vj wants to take a particular moral/ethical stance, then he should be free to do that. Of course he will have to live with any consequences, as do we all. He (or maybe she? I don't know but English is forcing me to use gender-specific pronouns) or his company sees a business risk in open sourcing their code. They now see a legal risk it not doing so. They get to choose how to respond. This list is a great place to seek technical advice on the different options. It is not such a good place to get business or legal advice. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/6] scsi: megaraid_sas - throttle io if FW is busy
Sumant Patro wrote:
Checks added in megasas_queue_command to know if FW is able to process
commands within the timeout period. If number of retries is 2 or more,
the driver stops sending cmd to FW. IO is resumed when pending cmd count
reduces to 16 or 10 seconds has elapsed from the time cmds were last
sent to FW.
Signed-off-by: Sumant Patro <[EMAIL PROTECTED]>
---
drivers/scsi/megaraid/megaraid_sas.c | 27 +
drivers/scsi/megaraid/megaraid_sas.h |3 ++
2 files changed, 30 insertions(+)
[snip]
diff -uprN linux-feb13-new-p2/drivers/scsi/megaraid/megaraid_sas.h
linux-feb13-new-p3/drivers/scsi/megaraid/megaraid_sas.h
--- linux-feb13-new-p2/drivers/scsi/megaraid/megaraid_sas.h 2007-02-13
07:22:40.0 -0800
+++ linux-feb13-new-p3/drivers/scsi/megaraid/megaraid_sas.h 2007-02-13
11:37:09.0 -0800
@@ -1102,6 +1102,9 @@ struct megasas_instance {
atomic_t fw_outstanding;
u32 hw_crit_error;
+ u8 is_busy;
Why not "bool is_busy:8;"? It obviously is a boolean. I would also think
false/true would be more descriptive then 0/1.
Richard Knutsson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/14/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote: On Wed, 2007-02-14 at 21:16 -0800, v j wrote: > This is in reference to the following thread: > > http://lkml.org/lkml/2006/12/14/63 > > I am not sure if this is ever addressed in LKML, but linux is _very_ > popular in the embedded space. We (an embedded vendor) chose Linux 3 > years back because of its lack of royalty model, robustness and > availability of infinite number of open-source tools. I think you have a bit of a misunderstanding... Linux is not royalty free. Just the royalty is not in the form of cash, but in the form of having to give your improvements back to the open source world. Sure. But this is not legally binding. (this is paraphrasing the intent of the GPL basically, you can argue for hours if drivers are separate or improvements, and I'm not interested in that debate, it has been debated to death before and only lawyers will in the end be able to settle that on a case by case basis). If your mindset is "how much can I take take take without giving back back back" then personally I think you're sort of acting like a parasite in this context Ok so are thousands of others who are using Linux as their OS of choice in embedded systems. They are not doing this because they are eager to give back back. They are doing it because Linux provides compelling reasons for them to choose it. They could have very well chosen VxWorks or OSE too. They chose not to, but not because they were unwilling to be a parasite. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] adjust legacy IDE resource setting (v2)
The change to force legacy mode IDE channels' resources to fixed
non-zero values confuses (at least some versions of) X, because the
values reported by the kernel and those readable from PCI config space
aren't consistent anymore. Therefore, this patch arranges for the
respective BARs to also get updated if possible.
(The only change to the original version is an added comment.)
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
--- linux-2.6.20/drivers/pci/probe.c2007-02-04 19:44:54.0 +0100
+++ 2.6.20-pci-ide-legacy/drivers/pci/probe.c 2007-02-15 08:54:58.0
+0100
@@ -639,7 +639,34 @@ static void pci_read_irq(struct pci_dev
dev->irq = irq;
}
-#define LEGACY_IO_RESOURCE (IORESOURCE_IO | IORESOURCE_PCI_FIXED)
+static void change_legacy_io_resource(struct pci_dev * dev, unsigned index,
+ unsigned start, unsigned end)
+{
+ unsigned base = start & PCI_BASE_ADDRESS_IO_MASK;
+ unsigned len = (end | ~PCI_BASE_ADDRESS_IO_MASK) - base + 1;
+
+ /*
+* Some X versions get confused when the BARs reported through
+* /sys or /proc differ from those seen in config space, thus
+* try to update the config space values, too.
+*/
+ if (!(pci_resource_flags(dev, index) & IORESOURCE_IO))
+ printk(KERN_WARNING "%s: cannot adjust BAR%u (not I/O)\n",
+ pci_name(dev), index);
+ else if (pci_resource_len(dev, index) != len)
+ printk(KERN_WARNING "%s: cannot adjust BAR%u (size %04X)\n",
+ pci_name(dev), index, (unsigned)pci_resource_len(dev,
index));
+ else {
+ printk(KERN_INFO "%s: trying to change BAR%u from %04X to
%04X\n",
+ pci_name(dev), index,
+ (unsigned)pci_resource_start(dev, index), base);
+ pci_write_config_dword(dev, PCI_BASE_ADDRESS_0 + index * 4,
base);
+ }
+ pci_resource_start(dev, index) = start;
+ pci_resource_end(dev, index) = end;
+ pci_resource_flags(dev, index) =
+ IORESOURCE_IO | IORESOURCE_PCI_FIXED |
PCI_BASE_ADDRESS_SPACE_IO;
+}
/**
* pci_setup_device - fill in class and map information of a device
@@ -692,20 +719,12 @@ static int pci_setup_device(struct pci_d
u8 progif;
pci_read_config_byte(dev, PCI_CLASS_PROG, );
if ((progif & 1) == 0) {
- dev->resource[0].start = 0x1F0;
- dev->resource[0].end = 0x1F7;
- dev->resource[0].flags = LEGACY_IO_RESOURCE;
- dev->resource[1].start = 0x3F6;
- dev->resource[1].end = 0x3F6;
- dev->resource[1].flags = LEGACY_IO_RESOURCE;
+ change_legacy_io_resource(dev, 0, 0x1F0, 0x1F7);
+ change_legacy_io_resource(dev, 1, 0x3F6, 0x3F6);
}
if ((progif & 4) == 0) {
- dev->resource[2].start = 0x170;
- dev->resource[2].end = 0x177;
- dev->resource[2].flags = LEGACY_IO_RESOURCE;
- dev->resource[3].start = 0x376;
- dev->resource[3].end = 0x376;
- dev->resource[3].flags = LEGACY_IO_RESOURCE;
+ change_legacy_io_resource(dev, 2, 0x170, 0x177);
+ change_legacy_io_resource(dev, 3, 0x376, 0x376);
}
}
break;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH 2.6.21 review I] [4/25] x86: kernel-mode faults pollute current->thead
>>> Jeff Dike <[EMAIL PROTECTED]> 14.02.07 18:51 >>> >On Tue, Feb 13, 2007 at 07:52:54AM +, Jan Beulich wrote: >> Actually, after a second round of thinking I believe there's still more to do >> - your second patch missed fixing i386's do_trap() similarly to x86-64's >> and, vice versa, x86-64's do_general_protection() similarly to i386's. > >Sigh, here's another go at it - the full patch instead of >incrementally fixing the old one: Ack. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH 2.6.21 review I] [4/25] x86: kernel-mode faults pollute current-thead
Jeff Dike [EMAIL PROTECTED] 14.02.07 18:51 On Tue, Feb 13, 2007 at 07:52:54AM +, Jan Beulich wrote: Actually, after a second round of thinking I believe there's still more to do - your second patch missed fixing i386's do_trap() similarly to x86-64's and, vice versa, x86-64's do_general_protection() similarly to i386's. Sigh, here's another go at it - the full patch instead of incrementally fixing the old one: Ack. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] adjust legacy IDE resource setting (v2)
The change to force legacy mode IDE channels' resources to fixed
non-zero values confuses (at least some versions of) X, because the
values reported by the kernel and those readable from PCI config space
aren't consistent anymore. Therefore, this patch arranges for the
respective BARs to also get updated if possible.
(The only change to the original version is an added comment.)
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
--- linux-2.6.20/drivers/pci/probe.c2007-02-04 19:44:54.0 +0100
+++ 2.6.20-pci-ide-legacy/drivers/pci/probe.c 2007-02-15 08:54:58.0
+0100
@@ -639,7 +639,34 @@ static void pci_read_irq(struct pci_dev
dev-irq = irq;
}
-#define LEGACY_IO_RESOURCE (IORESOURCE_IO | IORESOURCE_PCI_FIXED)
+static void change_legacy_io_resource(struct pci_dev * dev, unsigned index,
+ unsigned start, unsigned end)
+{
+ unsigned base = start PCI_BASE_ADDRESS_IO_MASK;
+ unsigned len = (end | ~PCI_BASE_ADDRESS_IO_MASK) - base + 1;
+
+ /*
+* Some X versions get confused when the BARs reported through
+* /sys or /proc differ from those seen in config space, thus
+* try to update the config space values, too.
+*/
+ if (!(pci_resource_flags(dev, index) IORESOURCE_IO))
+ printk(KERN_WARNING %s: cannot adjust BAR%u (not I/O)\n,
+ pci_name(dev), index);
+ else if (pci_resource_len(dev, index) != len)
+ printk(KERN_WARNING %s: cannot adjust BAR%u (size %04X)\n,
+ pci_name(dev), index, (unsigned)pci_resource_len(dev,
index));
+ else {
+ printk(KERN_INFO %s: trying to change BAR%u from %04X to
%04X\n,
+ pci_name(dev), index,
+ (unsigned)pci_resource_start(dev, index), base);
+ pci_write_config_dword(dev, PCI_BASE_ADDRESS_0 + index * 4,
base);
+ }
+ pci_resource_start(dev, index) = start;
+ pci_resource_end(dev, index) = end;
+ pci_resource_flags(dev, index) =
+ IORESOURCE_IO | IORESOURCE_PCI_FIXED |
PCI_BASE_ADDRESS_SPACE_IO;
+}
/**
* pci_setup_device - fill in class and map information of a device
@@ -692,20 +719,12 @@ static int pci_setup_device(struct pci_d
u8 progif;
pci_read_config_byte(dev, PCI_CLASS_PROG, progif);
if ((progif 1) == 0) {
- dev-resource[0].start = 0x1F0;
- dev-resource[0].end = 0x1F7;
- dev-resource[0].flags = LEGACY_IO_RESOURCE;
- dev-resource[1].start = 0x3F6;
- dev-resource[1].end = 0x3F6;
- dev-resource[1].flags = LEGACY_IO_RESOURCE;
+ change_legacy_io_resource(dev, 0, 0x1F0, 0x1F7);
+ change_legacy_io_resource(dev, 1, 0x3F6, 0x3F6);
}
if ((progif 4) == 0) {
- dev-resource[2].start = 0x170;
- dev-resource[2].end = 0x177;
- dev-resource[2].flags = LEGACY_IO_RESOURCE;
- dev-resource[3].start = 0x376;
- dev-resource[3].end = 0x376;
- dev-resource[3].flags = LEGACY_IO_RESOURCE;
+ change_legacy_io_resource(dev, 2, 0x170, 0x177);
+ change_legacy_io_resource(dev, 3, 0x376, 0x376);
}
}
break;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/14/07, Arjan van de Ven [EMAIL PROTECTED] wrote: On Wed, 2007-02-14 at 21:16 -0800, v j wrote: This is in reference to the following thread: http://lkml.org/lkml/2006/12/14/63 I am not sure if this is ever addressed in LKML, but linux is _very_ popular in the embedded space. We (an embedded vendor) chose Linux 3 years back because of its lack of royalty model, robustness and availability of infinite number of open-source tools. I think you have a bit of a misunderstanding... Linux is not royalty free. Just the royalty is not in the form of cash, but in the form of having to give your improvements back to the open source world. Sure. But this is not legally binding. (this is paraphrasing the intent of the GPL basically, you can argue for hours if drivers are separate or improvements, and I'm not interested in that debate, it has been debated to death before and only lawyers will in the end be able to settle that on a case by case basis). If your mindset is how much can I take take take without giving back back back then personally I think you're sort of acting like a parasite in this context Ok so are thousands of others who are using Linux as their OS of choice in embedded systems. They are not doing this because they are eager to give back back. They are doing it because Linux provides compelling reasons for them to choose it. They could have very well chosen VxWorks or OSE too. They chose not to, but not because they were unwilling to be a parasite. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Thursday February 15, [EMAIL PROTECTED] wrote: On 2/15/07, Neil Brown [EMAIL PROTECTED] wrote: [..] then it is less clear what people believe Another area where it is less clear what people believe is if you are distributing the module separately to the kernel, but, as I understand it, vj says he is not. But of course the person who's opinion really counts is the judge. The judge's opinion only counts if you actually get to court and manage to put up a legal defense. So you need to get legal advice. Or, ya know, you could take the moral/ethical advice that you're being a worm and stop now. I don't think we do ourselves any favours by calling people names And as I understand it, an important principle in out community is freedom. If vj wants to take a particular moral/ethical stance, then he should be free to do that. Of course he will have to live with any consequences, as do we all. He (or maybe she? I don't know but English is forcing me to use gender-specific pronouns) or his company sees a business risk in open sourcing their code. They now see a legal risk it not doing so. They get to choose how to respond. This list is a great place to seek technical advice on the different options. It is not such a good place to get business or legal advice. NeilBrown - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
v j wrote: On 2/14/07, Randy Dunlap [EMAIL PROTECTED] wrote: At least one of us is confused about that an embedded User is. It seems to me that you are an embedded developer, not User. I doubt that most Embedded Users care what their OS is, or even know what an OS is. I am not sure what the difference is. We are trying to use Linux to support our application. It may be that Linux has a bug, or our application. When it is Linux, that has the problem, I have tried to inform the community of that. The difference is that you are selling it and not contributing back. I think the legal term is something like distributing copyright material without a license. Not everybody has to be a contributor. The reason Linux is popular is because of its openness. Take that away and see where it goes. We seem to have different definitions of open and closed. Open = 3rd party Linux drivers can be loaded. Closed = No third party Linux drivers can be loaded. So most linux kernel developers chose to contribute to Linux because they prefer something closer to the GPL's notion of open (assuming your definitions are in the context of the legality of redistributing the end result). Don't take offence, but most of us don't _want_ the embedded developers who contribute nothing back. Even if you tripled the total Linux userbase, how would that be a good thing for anyone but yourself? Now imagine if nobody contributed anything back. The reason Linux is good enough that you chose in the first place is because of everyone contributing back. Why would we want to undermine that? My aim for Linux is not to have it shut down VxWorks, or to have a huge userbase, but to be the best OS out there. Maybe that helps explain the why others here don't share your opinion? With that said, there are some reasonable free BSD licensed operating systems out there that you can use without opening your source. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Thu, 2007-02-15 at 00:04 -0800, v j wrote: On 2/14/07, Arjan van de Ven [EMAIL PROTECTED] wrote: On Wed, 2007-02-14 at 21:16 -0800, v j wrote: This is in reference to the following thread: http://lkml.org/lkml/2006/12/14/63 I am not sure if this is ever addressed in LKML, but linux is _very_ popular in the embedded space. We (an embedded vendor) chose Linux 3 years back because of its lack of royalty model, robustness and availability of infinite number of open-source tools. I think you have a bit of a misunderstanding... Linux is not royalty free. Just the royalty is not in the form of cash, but in the form of having to give your improvements back to the open source world. Sure. But this is not legally binding. that's a legal conclusion that is ... iffy at least. I'm not a lawyer, but I suggest you talk to a real one before making that conclusion, and you'll see it's not as simple as that. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug
On Thursday, 15 February 2007 07:34, Gautham R Shenoy wrote: On Wed, Feb 14, 2007 at 10:43:35PM +0100, Rafael J. Wysocki wrote: Hi, On Wednesday, 14 February 2007 15:40, Gautham R Shenoy wrote: Hello Everybody, This is an experiment towards process_freezer based implementation of cpu-hotplug. This is mainly based on ideas of Andrew Morton, Ingo Molnar and Paul Mckenney featured in the discussion http://lkml.org/lkml/2007/1/31/323. This is an absolute bare-minimal implementation to check the feasibility of using process freezer for cpu-hotplug. The patchset comprises of four patches. o PATCH 1/4: Core implementation of freezer-based-hotplug. o PATCH 2/4: Revert changes to workqueue to make it work with the freezer-cpu-hotplug. o PATCH 3/4: Eliminate hotcpu subsystem mutexes from sched and slab. o PATCH 4/4: Eliminate lock_cpu_hotplug from the kernel. I think two things are missing: 1) We should make sure there are not PF_NOFREEZE tasks running when a CPU is removed (when one is added probably too). For this purpose we can add a parameter to freeze_processes() that will tell it to ignore PF_NOFREEZE, but at the same time we'll have to change all kernel threads that set PF_NOFREEZE to call try_to_freeze() anyway. I can do that, but it will take me a couple of days. Why should we make sure that PF_NOFREEZE tasks are also frozen for cpu hotplug? Instead, we can create an infrastructure which allows threads to specify for the scenarios they would want to be excempted from freeze. Something like what Paul has suggested in http://lkml.org/lkml/2007/1/31/323. That way, threads which have nothing to do with the online_cpu_map or with handling of cpu-hotplug events can mark themselves to be exempted from being frozen for cpu hotplug. I think all kernel threads should call try_to_freeze() in suitable places anyway if we are going to use the freezer for anything more than just the suspend. In other words, they all should be _able_ to freeze if necessary. Once this is achieved, it's all about classifying the threads into according to their NO_FREEZE needs :) Yes, but I think it's just a generalization of ingoring PF_NOFREEZE. If all kernel threads are able to freeze, we can mark them as freeze for CPU hotplug or freeze for kprobes, or freeze for suspend etc. and call the freezer with the appropriate parameter. BTW, what happens to a process running on a CPU being removed? 2) We have to change the PM code to stop using CPU hotplug for disabling nonboot CPUs. ;-) Just wondering, how hard is that ? Hmmm. In fact the problem is that the suspend code freezes tasks and then calls disable_nonboot_cpus() which uses (_)cpu_down/up(). In principle we could make disable_nonboot_cpus() call some lower-level routines to avoid the freezing of tasks, _but_ the suspend code may freeze too few tasks (ie. we may want to freeze more tasks for the CPU hotplug). Thus I think we should do something like this: suspend:CPU hotplug: freeze_processes(SUSPEND) ... ... freeze_processes(CPU_HOTPLUG) ... ... ... thaw_processes(CPU_HOTPLUG) thaw_processes(SUSPEND) ... so freeze_processes() should be reentrant, at least for different values of the argument. All in all, I think we should start from modifying the freezer and the classification of processes with respect to the freezing. Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
v j wrote: On 2/14/07, Arjan van de Ven [EMAIL PROTECTED] wrote: On Wed, 2007-02-14 at 21:16 -0800, v j wrote: This is in reference to the following thread: http://lkml.org/lkml/2006/12/14/63 I am not sure if this is ever addressed in LKML, but linux is _very_ popular in the embedded space. We (an embedded vendor) chose Linux 3 years back because of its lack of royalty model, robustness and availability of infinite number of open-source tools. I think you have a bit of a misunderstanding... Linux is not royalty free. Just the royalty is not in the form of cash, but in the form of having to give your improvements back to the open source world. Sure. But this is not legally binding. Please clarify! http://yro.slashdot.org/yro/04/07/23/1558219.shtml?tid=117tid=123 Richard Knutsson - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 6/6] automatic tuning applied to some kernel components
Eric W. Biederman wrote: Nadia Derbey [EMAIL PROTECTED] writes: But, what do you do with Oracle that's asking maxfiles to be set to 0x1, while the default value might be enough for a system that's not running Oracle. I'm afraid that giving boot time values to the max_* tunables we will loose all the benefits from /proc (or /sys): it is impossible to anticipate what an OS will be used for. So allowing such things to be changed without having to reboot the machine is in my mind quite a powerful feature we should keep taking adavntage of. I'm not saying remove user spaces' ability to set the denial-of-service limits. I'm saying if they need to be frequently changed we need to update the default so they are higher by default. There really is no cost in moving those values up and down it is just an arbitrary integer used in comparisons. But if we can make a good guess that still catches runaway programs before they kill the machine but also allows more programs to work out of the box we are in better shape. OK, happy to see we are on the same wavelength (and sorry for misunderstanding what you were saying ;-) ) Regards, Nadia - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
v j wrote: On 2/14/07, Arjan van de Ven [EMAIL PROTECTED] wrote: If your mindset is how much can I take take take without giving back back back then personally I think you're sort of acting like a parasite in this context Ok so are thousands of others who are using Linux as their OS of choice in embedded systems. They are not doing this because they are eager to give back back. They are doing it because Linux provides compelling reasons for them to choose it. They could have very well chosen VxWorks or OSE too. They chose not to, but not because they were unwilling to be a parasite. I can't control how people think or the reasons behind their actions. Nor do I care. All I care about is that I don't have parasites hanging off me. -- Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/15/07, Neil Brown [EMAIL PROTECTED] wrote: And as I understand it, an important principle in out community is freedom. If vj wants to take a particular moral/ethical stance, then he should be free to do that. Of course he will have to live with any consequences, as do we all. Yes, and one of the consequences is that people who disagree with his stance tell him off for it. Him, and everyone else who profits from distributing GPL licensed code without abiding by the very simple requirements of the GPL are parasites. They should stop. Legally they might not be required to.. and some of the best legal minds in the world think they are, if only the copyright holders would sue already.. but that's just a side issue. Trent - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] Optimize generic get_unaligned / put_unaligned implementations.
Hi Andrew,
+#define get_unaligned(ptr) \
+({ \
+ const struct { \
+ union { \
+ const int __un_foo[0]; \
+ const __typeof__(*(ptr)) __un; \
+ } __un __attribute__ ((packed));\
+ } * const __gu_p = (void *) (ptr); \
+ \
+ __gu_p-__un.__un; \
})
Can someone please tell us how this magic works? (And it does appear to
work).
It seems to assuming that the compiler will assume that members of packed
structures can have arbitrary alignment, even if that alignment is obvious.
Which makes sense, but I'd like to see chapter-and-verse from the spec or
from the gcc docs so we can rely upon it working on all architectures and
compilers from now until ever more.
I am far away from having any knowledge about the GCC internals and the
reason why this code works, but I've been told the generic way of
handling unaligned access is this:
#define get_unaligned(ptr) \
({ \
struct __attribute__((packed)) {\
typeof(*(ptr)) __v; \
} *__p = (void *) (ptr);\
__p-__v; \
})
#define put_unaligned(val, ptr) \
do {\
struct __attribute__((packed)) {\
typeof(*(ptr)) __v; \
} *__p = (void *) (ptr);\
__p-__v = (val); \
} while(0)
Actually I am using this code in the Bluetooth userspace library for
over two years now without any complaints.
Regards
Marcel
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
Oh, I am sorry. Seems like the German courts have spoken. I am not sure about what, but they have spoken. Sorry for the confusion. On 2/15/07, Richard Knutsson [EMAIL PROTECTED] wrote: v j wrote: On 2/14/07, Arjan van de Ven [EMAIL PROTECTED] wrote: On Wed, 2007-02-14 at 21:16 -0800, v j wrote: This is in reference to the following thread: http://lkml.org/lkml/2006/12/14/63 I am not sure if this is ever addressed in LKML, but linux is _very_ popular in the embedded space. We (an embedded vendor) chose Linux 3 years back because of its lack of royalty model, robustness and availability of infinite number of open-source tools. I think you have a bit of a misunderstanding... Linux is not royalty free. Just the royalty is not in the form of cash, but in the form of having to give your improvements back to the open source world. Sure. But this is not legally binding. Please clarify! http://yro.slashdot.org/yro/04/07/23/1558219.shtml?tid=117tid=123 Richard Knutsson - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[LIBATA] drives not detected
Good morning all, Yesterday I replaced a Sil680 PCI add-on card for a Promise 2027x PCI add-on card. Now, when I boot up, I miss two drives, exactly the two connected to this promise card. I have another onboard Promise controller which works just fine, so the driver gets loaded properly, and since i see all my other disks but these two I think we can rule out a misconfiguration of the kernel config this time ;-) This is a snippet from my dmesg pata_pdc2027x :00:0b.0: version 0.74-ac5 ACPI: PCI Interrupt :00:0b.0[A] - GSI 19 (level, low) - IRQ 20 pata_pdc2027x :00:0b.0: PLL input clock 16799 kHz ata7: PATA max UDMA/133 cmd 0xf98a17c0 ctl 0xf98a1fda bmdma 0xf98a1000 irq 20 ata8: PATA max UDMA/133 cmd 0xf98a15c0 ctl 0xf98a1dda bmdma 0xf98a1008 irq 20 scsi7 : pata_pdc2027x scsi8 : pata_pdc2027x ATA: abnormal status 0x8 on port 0xf98a15df As you can see, scsi8 gives an abnormal status, which as we got pointed out this week is just a cosmetic error for No drive attached/detected and it's very right in that finding. But what about scsi7? no warning/error about no disks being attached nor a disk detection. To state the obvious: I see the disks being detected by the Promise BIOS when I boot the system,Primaiy master and Primaiy slave. Here is the lspci -vvv regarding the controller 00:0b.0 Mass storage controller: Promise Technology, Inc. 20269 (rev 02) (prog-if 85) Subsystem: Promise Technology, Inc. Ultra133TX2 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow TAbort- TAbort- MAbort- SERR- PERR- Latency: 32 (1000ns min, 4500ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 20 Region 0: I/O ports at 9400 [size=8] Region 1: I/O ports at 9800 [size=4] Region 2: I/O ports at 9c00 [size=8] Region 3: I/O ports at a000 [size=4] Region 4: I/O ports at a400 [size=16] Region 5: Memory at eb00 (32-bit, non-prefetchable) [size=16K] [virtual] Expansion ROM at ea10 [disabled] [size=16K] Capabilities: [60] Power Management version 1 Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Take care all! Patrick - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LIBATA] drives not detected
On 2/15/07, Patrick Ale [EMAIL PROTECTED] wrote: Good morning all, Now, when I boot up, I miss two drives, exactly the two connected to this promise card. I have another onboard Promise controller which works just fine, so the driver gets loaded properly, and since i see all my other disks but these two I think we can rule out a misconfiguration of the kernel config this time ;-) It would be nice if I'd also mention the kernel I use eh. It's linux-2.6-git8 Patrick - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: xfs internal error on a new filesystem
On Wed, Feb 14, 2007 at 10:24:27AM +, Ramy M. Hassan wrote: Hello, We got the following xfs internal error on one of our production servers: Feb 14 08:28:52 info6 kernel: [238186.676483] Filesystem sdd8: XFS internal error xfs_trans_cancel at line 1138 of file fs/xfs/xfs_trans.c. Caller 0xf8b906e7 Real stack looks to be: xfs_trans_cancel xfs_mkdir xfs_vn_mknod xfs_vn_mkdir vfs_mkdir sys_mkdirat sys_mkdir We aborted a transaction for some reason. We got an error somewhere in a mkdir while we had a dirty transaction. Unfortunately, this tells us very little about the error that actually caused the shutdown. What is your filessytem layout? (xfs_info mntpt) How much memory do you have and were you near enomem conditions? We were able to unmount/remount the volume (didn't do xfs_repair because we thought it might take long time, and the server was already in production at the moement) Risky to run a production system on a filesystem that might be corrupted. You risk further problems if you don't run repair The file system was created less than 48hours ago, and 370G of sensitve production data was moved to the server before it xfs crash. So that's not a new filesystem at all... FWIW, did you do any offline testing before you put it into production? System details : Kernel: 2.6.18 Controller: 3ware 9550SX-8LP (RAID 10) Can you describe your dm/md volume layout? We are wondering here if this problem is an indicator to data corruption on disk ? It might be. You didn't run xfs_check or xfs_repair, so we don't know if there is any on disk corruption here. is it really necessary to run xfs_repair ? If you want to know if you haven't left any landmines around for the filesystem to trip over again. i.e. You should run repair after any sort of XFS shutdown to make sure nothing is corrupted on disk. If nothing is corrupted on disk, then we are looking at an in-memory problem Do u recommend that we switch back to reiserfs ? Not yet. Could it be a hardware related problems ? Yes. Do you have ECC memory on your server? Have you run memtest86? Were there any I/O errors in the log prior to the shutdown message? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] aio: fix kernel bug when page is temporally busy
Ken Chen wrote
It might shut up kernel
panic by eliminate double calls to aio_complete(), but it will
silently introduce data corruption.
I had got kernel panic after an hour of aiostress running.
After patching I have not got aiostress massage
verify error, file %s offset %Lu contents (offset:bad:good):\n
during 5 hour aiostress running with 'verify' option.
Looking closely into aiostress.c
ftp://ftp.suse.com/pub/people/mason/utils/aio-stress.c
we can see that this program may write in random mode THE SAME
contents to the same file offset asynchronously from different
buffers and do not cure about it. Does Ken consider that kernel
panic is the best way to prevent data corruption in such kind
of programs?
So any error value returned from invalidate_inode_pages2_range() has
to be taken seriously in the direct IO submit path instead of dropping
it to the floor.
If invalidate_inode_pages2_range() will return EIOCBRETRY as the patch
aio: fix kernel bug when page is temporally busy
sets then do_sync_read/write() will not drop IO submit but will retry
it:
for (;;) {
ret = filp-f_op-aio_read(kiocb, iov, 1, kiocb.ki_pos);
if (ret != -EIOCBRETRY)
break;
wait_on_retry_sync_kiocb(kiocb);
}
And do_sync_read/write() will not return EIO if page is busy
as it does now, before patching.
Ken Chen wrote:
I also think the original patch is wrong.
What do you mean saying 'also'?
Leonid
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Unify pcspeaker platform device code between i386/x86-64
Linux Kernel Mailing List wrote: Gitweb: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=62cc49396e593dd71c6595302bb10b085aefbfa5 Commit: 62cc49396e593dd71c6595302bb10b085aefbfa5 Parent: 40d22c1b5675e428b3f3f9a945d0bd62e94ca2f1 Author: Andi Kleen [EMAIL PROTECTED] AuthorDate: Tue Feb 13 13:26:26 2007 +0100 Committer: Andi Kleen [EMAIL PROTECTED] CommitDate: Tue Feb 13 13:26:26 2007 +0100 [PATCH] x86: Unify pcspeaker platform device code between i386/x86-64 Trivial cleanup. Only change is that it is always compiled in now on x86-64 like on i386. Signed-off-by: Andi Kleen [EMAIL PROTECTED] THANK YOU. It's always seemed broken (though perhaps this was a distro bug?) in module form, so I've been compiling it in to get it to work. 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: PROBLEM: 2.6.19.1 Oops while doing Disk IO + playing sound, 2.6.20 too
On Thu 15-02-07 00:33:31, Frank Hartmann wrote: Jan Kara [EMAIL PROTECTED] writes: Yes I see some correlation. Again it seems there is a problem with buffers attached to a page which got truncated but Private flag of the page stayed. It's probably not important but just out of curiosity - do you have CONFIG_LBD (large block device) set? I'd just like to verify that page_bufs was NULL when it was passed to walk_page_buffers(). fantasio:~/tmp/linux-2.6.20$ fgrep CONFIG_LBD .config # CONFIG_LBD is not set OK, thanks. Then I'm slightly confused as the offset 0x2d in struct buffer_head is somewhere in b_assoc_buffers which is never dereferenced. Can you run gdb on vmlinux from the 2.6.20 kernel and send me the output of 'disass walk_page_buffers'? Thanks. You said 2.6.17 worked for you, didn't you? How long does it take to reproduce the problem? If it is reasonably easy (e.g. a few hours), could you trace back when the problem started happening? If you could narrow that problem down to a single patch (using git-bisect), that would be great. Yes I said that. At least I did not notice it happen:) Reproduction seems easy. So I will try. Great. I have some problem: I am not sufficiently familar with git! I found http://www.kernel.org/pub/software/scm/git/docs/howto/isolate-bugs-with-bisect.txt Is this the way to do a git-bisect? Yes, that's it. From where do I get the 'labels' for good(2.6.17) and bad(2.6.20)? git bisect bad v2.6.20 git bisect good v2.6.17 (or maybe you could start with 'git bisect bad v2.6.19' if that was also failing for you). Git will spit out something like: Bisecting: 9467 revisions left to test after this [ebdea46fecae40c4d7effcd33f40918a37a1df4b] Merge branch 'devel' of master.kernel.org:/home/rmk/linux-2.6-arm After you test kernel from the revision 'ebdea46fecae40c4d7effcd33f40918a37a1df4b', you do git bisect good/bad ebdea46fecae40c4d7effcd33f40918a37a1df4 and you'll get next revision to check. I hope it's clearer now. Honza -- Jan Kara [EMAIL PROTECTED] SuSE CR Labs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
Dave Jones wrote: On Wed, Feb 14, 2007 at 10:46:13PM -0800, v j wrote: Using our source code would not benefit anybody but our competitors. This excuse has been given time and time again, and repeatedly been proven false. And as soon as one of your competitors makes their drivers open, guess which one gets 1000+ free developers working on their code ? Customers also like to buy hardware where they -know- support will not disappear in a year, when the vendor releases a new chip. In fact, in some markets, the engineers who wrote the code have often moved to the next project, by the time the customers actually get their hands on the end result. Open source means that problems found in real world field testing can be readily debugged and fixed. 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: GPL vs non-GPL device drivers
On Wed, 2007-02-14 at 22:27 -0800, v j wrote: You are right. I have not contributed anything to Linux. Except one small patch to the MTD code. However, I don't think that is the point here. I am perfectly willing to live with the way Linux is today. I am telling you as a user that if Linux continues on the current path it will become less and less attractive to Embedded Users. Guess what ? No one cares. If being serious about the GPL means that free-riders like you, who take and never give back, prefer to go elsewhere, that's not a problem. No one looses anything. BTW, the thousands of different predictions if linux doesn't do X, it'll never be successful get old pretty quicly. Xav - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Unify pcspeaker platform device code between i386/x86-64
It's always seemed broken (though perhaps this was a distro bug?) in module form, so I've been compiling it in to get it to work. Must have been a distro bug. It should have worked before as long as the config was enabled. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix mempolicy's check on a system with memory-less-node take4
On Thursday 15 February 2007 08:32, KAMEZAWA Hiroyuki wrote: please ack if O.K. Ok for me -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Wed, 2007-02-14 at 23:28 -0800, v j wrote: Open = 3rd party Linux drivers can be loaded. Closed = No third party Linux drivers can be loaded. Then go ahead and use Windows CE or VxWorks. By your silly definition they are pretty open. Xav - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 19/31] clockevents: i386 drivers
On Wed, 13 Dec 2006 14:02:11 +0100 Ingo Molnar [EMAIL PROTECTED] wrote: Add clockevent drivers for i386: lapic (local) and PIT (global). Update the timer IRQ to call into the PIT driver's event handler and the lapic-timer IRQ to call into the lapic clockevent driver. The assignement of timer functionality is delegated to the core framework code and replaces the compile and runtime evalution in do_timer_interrupt_hook() Use the clockevents broadcast support and implement the lapic_broadcast function for ACPI. No changes to existing functionality. This patch breaks the NMI on my crufty old dual-PIII supermicro p6dbe machine: Testing NMI watchdog ... CPU#0: NMI appears to be stuck (26-26)! CPU#1: NMI appears to be stuck (0-0)! vmm:/home/akpm cat /proc/interrupts CPU0 CPU1 0: 59 0 IO-APIC-edge timer 1: 2 0 IO-APIC-edge i8042 2: 0 0XT-PIC-XTcascade 6: 3 0 IO-APIC-edge floppy 8: 1 0 IO-APIC-edge rtc 10:192 61 IO-APIC-fasteoi aic7xxx 11: 1339 31 IO-APIC-fasteoi eth0 12: 3 1 IO-APIC-edge i8042 15: 3067 7 IO-APIC-edge ide1 NMI: 26 0 LOC: 58665 58663 ERR: 0 MIS: 0 and it isn't changing. See http://userweb.kernel.org/~akpm/nmi-prob/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 9/11] Panic delay fix
Hi! We'd have to audit and figure out what udelays are for hardware and which are not, but the evidence is that the vast majority of them are for hardware and not needed for virtualization. Which is irrelevant since the hardware drivers won't be used in a virtualised environment with any kind of performance optimisation. Which is why an audit is irrelevant for the most part. Note on the performance below. You know it is ugly. Alan demonstrated it even hurts performance, but being ugly is the main problem. If you _need_ to avoid udelay() in some cases, introduce udelay_unless_virtualized(), and switch few users to it. Just globaly defining udelay to nop is _ugly_. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/4] ipmi: add pci remove handling
On Wed, 14 Feb 2007 14:06:24 -0600 Corey Minyard [EMAIL PROTECTED] wrote:
Add pci_remove handling to the driver, so it will clean up if
the device is hot-removed.
Signed-off-by: Corey Minyard [EMAIL PROTECTED]
Index: linux-2.6.19/drivers/char/ipmi/ipmi_si_intf.c
===
--- linux-2.6.19.orig/drivers/char/ipmi/ipmi_si_intf.c
+++ linux-2.6.19/drivers/char/ipmi/ipmi_si_intf.c
@@ -2191,12 +2191,15 @@ static int __devinit ipmi_pci_probe(stru
info-irq_setup = std_irq_setup;
info-dev = pdev-dev;
+ pdev-dev-driver_data = info;
return try_smi_init(info);
}
static void __devexit ipmi_pci_remove(struct pci_dev *pdev)
{
+ struct smi_info *info = pdev-dev-driver_data;
+ cleanup_one_si(info);
}
drivers/char/ipmi/ipmi_si_intf.c: In function 'ipmi_pci_probe':
drivers/char/ipmi/ipmi_si_intf.c:2192: error: invalid type argument of '-'
drivers/char/ipmi/ipmi_si_intf.c: In function 'ipmi_pci_remove':
drivers/char/ipmi/ipmi_si_intf.c:2199: error: invalid type argument of '-'
Judging from the patch headers you were working against 2.6.19, which is
most optimistic. Please always prepare and test patches against the
latest kernel.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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/3] Input: psmouse - wrap protocol extensions (except synaptics) with ifdefs
Allow ALPS, LOGIPS2PP, LIFEBOOK, and TRACKPOINT protocol extensions (in
the psmouse driver) to be disabled during compilation. The synaptics
stuff is left alone for now, since it needs special handling for
synaptic pass-through ports.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
diff --git a/drivers/input/mouse/psmouse-base.c
b/drivers/input/mouse/psmouse-base.c
index a0e4a03..6b3ac9d 100644
--- a/drivers/input/mouse/psmouse-base.c
+++ b/drivers/input/mouse/psmouse-base.c
@@ -555,6 +555,7 @@ static int psmouse_extensions(struct psmouse *psmouse,
{
int synaptics_hardware = 0;
+#ifdef CONFIG_MOUSE_PS2_LIFEBOOK
/*
* We always check for lifebook because it does not disturb mouse
* (it only checks DMI information).
@@ -565,6 +566,7 @@ static int psmouse_extensions(struct psmouse *psmouse,
return PSMOUSE_LIFEBOOK;
}
}
+#endif
/*
* Try Kensington ThinkingMouse (we try first, because synaptics probe
@@ -596,6 +598,7 @@ static int psmouse_extensions(struct psmouse *psmouse,
synaptics_reset(psmouse);
}
+#ifdef CONFIG_MOUSE_PS2_ALPS
/*
* Try ALPS TouchPad
*/
@@ -610,15 +613,20 @@ static int psmouse_extensions(struct psmouse *psmouse,
max_proto = PSMOUSE_IMEX;
}
}
+#endif
if (max_proto PSMOUSE_IMEX genius_detect(psmouse, set_properties)
== 0)
return PSMOUSE_GENPS;
+#ifdef CONFIG_MOUSE_PS2_LOGIPS2PP
if (max_proto PSMOUSE_IMEX ps2pp_init(psmouse, set_properties) ==
0)
return PSMOUSE_PS2PP;
+#endif
+#ifdef CONFIG_MOUSE_PS2_TRACKPOINT
if (max_proto PSMOUSE_IMEX trackpoint_detect(psmouse,
set_properties) == 0)
return PSMOUSE_TRACKPOINT;
+#endif
/*
* Reset to defaults in case the device got confused by extended
@@ -660,12 +668,14 @@ static const struct psmouse_protocol psmouse_protocols[]
= {
.maxproto = 1,
.detect = ps2bare_detect,
},
+#ifdef CONFIG_MOUSE_PS2_LOGIPS2PP
{
.type = PSMOUSE_PS2PP,
.name = PS2++,
.alias = logitech,
.detect = ps2pp_init,
},
+#endif
{
.type = PSMOUSE_THINKPS,
.name = ThinkPS/2,
@@ -699,6 +709,7 @@ static const struct psmouse_protocol psmouse_protocols[] = {
.detect = synaptics_detect,
.init = synaptics_init,
},
+#ifdef CONFIG_MOUSE_PS2_ALPS
{
.type = PSMOUSE_ALPS,
.name = AlpsPS/2,
@@ -706,18 +717,23 @@ static const struct psmouse_protocol psmouse_protocols[]
= {
.detect = alps_detect,
.init = alps_init,
},
+#endif
+#ifdef CONFIG_MOUSE_PS2_LIFEBOOK
{
.type = PSMOUSE_LIFEBOOK,
.name = LBPS/2,
.alias = lifebook,
.init = lifebook_init,
},
+#endif
+#ifdef CONFIG_MOUSE_PS2_TRACKPOINT
{
.type = PSMOUSE_TRACKPOINT,
.name = TPPS/2,
.alias = trackpoint,
.detect = trackpoint_detect,
},
+#endif
{
.type = PSMOUSE_AUTO,
.name = auto,
--
1.4.4.2
[patch 1/3] Input: psmouse - create PS/2 protocol options for Kconfig
Initial framework for disabling PS/2 protocol extensions. The current protocols can only be disabled if CONFIG_EMBEDDED is selected. No source files are changed, merely build stuff. Signed-off-by: Andres Salomon [EMAIL PROTECTED] diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig index 35d998c..498930d 100644 --- a/drivers/input/mouse/Kconfig +++ b/drivers/input/mouse/Kconfig @@ -37,6 +37,56 @@ config MOUSE_PS2 To compile this driver as a module, choose M here: the module will be called psmouse. +config MOUSE_PS2_ALPS + bool ALPS PS/2 mouse protocol extension if EMBEDDED + default y + depends on MOUSE_PS2 + ---help--- + Say Y here if you have an ALPS PS/2 touchpad connected to + your system. + + If unsure, say Y. + +config MOUSE_PS2_LOGIPS2PP + bool Logictech PS/2++ mouse protocol extension if EMBEDDED + default y + depends on MOUSE_PS2 + ---help--- + Say Y here if you have a Logictech PS/2++ mouse connected to + your system. + + If unsure, say Y. + +config MOUSE_PS2_SYNAPTICS + bool Synaptics PS/2 mouse protocol extension if EMBEDDED + default y + depends on MOUSE_PS2 + ---help--- + Say Y here if you have a Synaptics PS/2 TouchPad connected to + your system. + + If unsure, say Y. + +config MOUSE_PS2_LIFEBOOK + bool Fujitsu Lifebook PS/2 mouse protocol extension if EMBEDDED + default y + depends on MOUSE_PS2 + ---help--- + Say Y here if you have a Fujitsu B-series Lifebook PS/2 + TouchScreen connected to your system. + + If unsure, say Y. + +config MOUSE_PS2_TRACKPOINT + bool IBM Trackpoint PS/2 mouse protocol extension if EMBEDDED + default y + depends on MOUSE_PS2 + ---help--- + Say Y here if you have an IBM Trackpoint PS/2 mouse connected + to your system. + + If unsure, say Y. + config MOUSE_SERIAL tristate Serial mouse select SERIO diff --git a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile index 21a1de6..c55aa29 100644 --- a/drivers/input/mouse/Makefile +++ b/drivers/input/mouse/Makefile @@ -14,4 +14,9 @@ obj-$(CONFIG_MOUSE_SERIAL)+= sermouse.o obj-$(CONFIG_MOUSE_HIL)+= hil_ptr.o obj-$(CONFIG_MOUSE_VSXXXAA)+= vsxxxaa.o -psmouse-objs := psmouse-base.o alps.o logips2pp.o synaptics.o lifebook.o trackpoint.o +psmouse-objs := psmouse-base.o synaptics.o + +psmouse-$(CONFIG_MOUSE_PS2_ALPS) += alps.o +psmouse-$(CONFIG_MOUSE_PS2_LOGIPS2PP) += logips2pp.o +psmouse-$(CONFIG_MOUSE_PS2_LIFEBOOK) += lifebook.o +psmouse-$(CONFIG_MOUSE_PS2_TRACKPOINT) += trackpoint.o -- 1.4.4.2
[patch 3/3] Input: psmouse - allow disabling of synaptics protocol extension
Allow disabling of synaptics via CONFIG_MOUSE_PS2_SYNAPTICS;
we leave synaptic_detect and synaptic_reset (for synaptics hardware
that emulates other protocols), but get rid of synaptic_init.
Signed-off-by: Andres Salomon [EMAIL PROTECTED]
diff --git a/drivers/input/mouse/psmouse-base.c
b/drivers/input/mouse/psmouse-base.c
index 6b3ac9d..bfb47e1 100644
--- a/drivers/input/mouse/psmouse-base.c
+++ b/drivers/input/mouse/psmouse-base.c
@@ -583,8 +583,11 @@ static int psmouse_extensions(struct psmouse *psmouse,
synaptics_hardware = 1;
if (max_proto PSMOUSE_IMEX) {
+#ifdef CONFIG_MOUSE_PS2_SYNAPTICS
if (!set_properties || synaptics_init(psmouse) == 0)
return PSMOUSE_SYNAPTICS;
+#endif
+
/*
* Some Synaptics touchpads can emulate extended protocols (like IMPS/2).
* Unfortunately Logitech/Genius probes confuse some firmware versions so
@@ -702,6 +705,7 @@ static const struct psmouse_protocol psmouse_protocols[] = {
.maxproto = 1,
.detect = im_explorer_detect,
},
+#ifdef CONFIG_MOUSE_PS2_SYNAPTICS
{
.type = PSMOUSE_SYNAPTICS,
.name = SynPS/2,
@@ -709,6 +713,7 @@ static const struct psmouse_protocol psmouse_protocols[] = {
.detect = synaptics_detect,
.init = synaptics_init,
},
+#endif
#ifdef CONFIG_MOUSE_PS2_ALPS
{
.type = PSMOUSE_ALPS,
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index 49ac696..5d69f52 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -45,28 +45,30 @@
/
/*
- * Send a command to the synpatics touchpad by special commands
+ * Set the synaptics touchpad mode byte by special commands
*/
-static int synaptics_send_cmd(struct psmouse *psmouse, unsigned char c,
unsigned char *param)
+static int synaptics_mode_cmd(struct psmouse *psmouse, unsigned char mode)
{
- if (psmouse_sliced_command(psmouse, c))
+ unsigned char param[1];
+
+ if (psmouse_sliced_command(psmouse, mode))
return -1;
- if (ps2_command(psmouse-ps2dev, param, PSMOUSE_CMD_GETINFO))
+ param[0] = SYN_PS_SET_MODE2;
+ if (ps2_command(psmouse-ps2dev, param, PSMOUSE_CMD_SETRATE))
return -1;
return 0;
}
+#ifdef CONFIG_MOUSE_PS2_SYNAPTICS
+
/*
- * Set the synaptics touchpad mode byte by special commands
+ * Send a command to the synpatics touchpad by special commands
*/
-static int synaptics_mode_cmd(struct psmouse *psmouse, unsigned char mode)
+static int synaptics_send_cmd(struct psmouse *psmouse, unsigned char c,
unsigned char *param)
{
- unsigned char param[1];
-
- if (psmouse_sliced_command(psmouse, mode))
+ if (psmouse_sliced_command(psmouse, c))
return -1;
- param[0] = SYN_PS_SET_MODE2;
- if (ps2_command(psmouse-ps2dev, param, PSMOUSE_CMD_SETRATE))
+ if (ps2_command(psmouse-ps2dev, param, PSMOUSE_CMD_GETINFO))
return -1;
return 0;
}
@@ -529,12 +531,16 @@ static void set_input_params(struct input_dev *dev,
struct synaptics_data *priv)
clear_bit(REL_Y, dev-relbit);
}
+#endif /* CONFIG_MOUSE_PS2_SYNAPTICS */
+
void synaptics_reset(struct psmouse *psmouse)
{
/* reset touchpad back to relative mode, gestures enabled */
synaptics_mode_cmd(psmouse, 0);
}
+#ifdef CONFIG_MOUSE_PS2_SYNAPTICS
+
static void synaptics_disconnect(struct psmouse *psmouse)
{
synaptics_reset(psmouse);
@@ -569,6 +575,8 @@ static int synaptics_reconnect(struct psmouse *psmouse)
return 0;
}
+#endif /* CONFIG_MOUSE_PS2_SYNAPTICS */
+
int synaptics_detect(struct psmouse *psmouse, int set_properties)
{
struct ps2dev *ps2dev = psmouse-ps2dev;
@@ -593,6 +601,8 @@ int synaptics_detect(struct psmouse *psmouse, int
set_properties)
return 0;
}
+#ifdef CONFIG_MOUSE_PS2_SYNAPTICS
+
#if defined(__i386__)
#include linux/dmi.h
static struct dmi_system_id toshiba_dmi_table[] = {
@@ -679,4 +689,4 @@ int synaptics_init(struct psmouse *psmouse)
return -1;
}
-
+#endif /* CONFIG_MOUSE_PS2_SYNAPTICS */
--
1.4.4.2
Re: [BUG] at drivers/char/vt.c:3332 do_blank_screen() on resume
Hi! With 2.6.20, resuming from disk sometimes cannot returns on vt7 where X runs but everything seems working, so just changing to vt1 and returning to vt7 solves the problem. But dmesg shows some BUG() output like [1] whenever this problem occurs I'm using 20070207 snapshot of suspend, s2disk is used to suspend2disk, machine is a Sony Vaio FS-215B which is in the whitelist and works well with 2.6.16/17/18 (all have fbsplash and vesafb-tng patches [from gentoo] applied). [1] http://cekirdek.pardus.org.tr/~caglar/dmesg.2.6.20 Contact fbcon people... They are calling do_blank_screen+0x4e/0x218 from fbcon_event_notify+0x8f1/0xa1e ... probably without taking neccessary locks. Aha, it seems their blanking code triggers _while_ resuming, which is not exactly nice. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: irqdesc porting help
On Thu, Feb 15, 2007 at 12:01:37PM +0530, Maximus wrote: Im trying to port some drivers between 2.6.14 and 2.6.19 I find that irqdesc has changed completely. how do i port the drivers between 2.6.14 and 2.6.19? is there a porting guide available to port the drivers which use irqdesc?. my drivers use variables triggered, ... which dont exist in 2.6.19 irqdesc strcuture. Presumably you're talking about the struct hw_interrupt_type and the lack of an irq_desc[irq].handler? There's some migration helper glue in include/linux/irq.h that you can use, but you're better off converting completely. You can at least get it building again by changing to irq_desc[irq].chip, but you really want a proper irq_chip implementation to go along with this, rather than munging in the hw_interrupt_type. You can easily compare before-and-after versions of most of the IRQ controllers to identify the minimal changes required. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: irqdesc porting help
On Thu, Feb 15, 2007 at 07:33:47PM +0900, Paul Mundt wrote: On Thu, Feb 15, 2007 at 12:01:37PM +0530, Maximus wrote: Im trying to port some drivers between 2.6.14 and 2.6.19 I find that irqdesc has changed completely. how do i port the drivers between 2.6.14 and 2.6.19? is there a porting guide available to port the drivers which use irqdesc?. my drivers use variables triggered, ... which dont exist in 2.6.19 irqdesc strcuture. Presumably you're talking about the struct hw_interrupt_type and the lack of an irq_desc[irq].handler? There's some migration helper glue in include/linux/irq.h that you can use, but you're better off converting completely. You can at least get it building again by changing to irq_desc[irq].chip, but you really want a proper irq_chip implementation to go along with this, rather than munging in the hw_interrupt_type. It should be asked - why are drivers poking about in the irqdesc structure? -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Serial console issues.
On Wed, Feb 14, 2007 at 05:39:22PM -0700, [EMAIL PROTECTED] wrote: Well, this is the most bastardized sucker I've ever seen. . . I have had no end of trouble with it (couldn't even get a boot loader to work with it - had to write my own). And, as luck would have it, the serial port is no different. Using setserial, I changed the type of this port to a 16550A and all my problems went away. The question now remains: How can I FORCE the Linux serial driver to see this as a 16550A -- As I before stated, I know that this has a 16-byte buffer. Therefore, the 16750 with its mammoth buffer size is killing this serial port. Short of modifying the kernel (which I'd rather not do) or including the setserial with the kernel image (also I'd rather not do as I only have 2.3 MB of storage on this device) I need a command line parameter to control the serial line -- is there one? A build option? PLEASE SOMETHING??? No. Use setserial which is a small tool to achieve what you require. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Thu, Feb 15, 2007 at 04:44:51AM -0500, Jeff Garzik wrote: Dave Jones wrote: On Wed, Feb 14, 2007 at 10:46:13PM -0800, v j wrote: Using our source code would not benefit anybody but our competitors. This excuse has been given time and time again, and repeatedly been proven false. And as soon as one of your competitors makes their drivers open, guess which one gets 1000+ free developers working on their code ? Customers also like to buy hardware where they -know- support will not disappear in a year, when the vendor releases a new chip. Absolutely. This is a very good point. And users of binary blobs like nvidia.ko are already beginning to see this problem. (Nvidia dropped support for legacy cards a while back) Only open drivers ensure ongoing vendor-independant support, which is an important thing. I'd not be happy buying a device that I know the vendor is going to ship security updates for a year after release. VJ, how long does your company support each product? And how much engineering effort is spent doing so, vs effort that you could get for free by opening your driver(s) ? In fact, in some markets, the engineers who wrote the code have often moved to the next project, by the time the customers actually get their hands on the end result. Open source means that problems found in real world field testing can be readily debugged and fixed. Even open drivers have the same problem. Take for example longhaul.c. I lost interest in this a while ago and moved on to shinier new hardware (whilst it still had numerous problems) and rafal picked this up and has been fixing it up like something possessed since. If this were a closed driver, it would have been doomed never to improve. It's a great example of one of the strengths of the open process. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
I am still a kernel newbie, and I am still not very much aware about the GPL vs. Non-GPL drivers debate. I personally think it'd be better that all drivers should be GPL'd but if that's the case, what would be the legal position of such vendors as ATI or NVIDIA who supply closed source drivers? Would it be illegal to use them? I know this question might sound silly, but as I said before I have only little awareness about the issue. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] at drivers/char/vt.c:3332 do_blank_screen() on resume
On Thu, 15 Feb 2007 11:40:32 +0100 Pavel Machek [EMAIL PROTECTED] wrote: Contact fbcon people... There aren't any, basically. Since Tony disappeared James has been helping out but doesn't have a lot of time. So we're pretty much on our own with problems in this area. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.20 new perfmon code base + libpfm + pfmon
Andi,
On Wed, Feb 14, 2007 at 12:20:56AM +0100, Andi Kleen wrote:
Andrew Morton [EMAIL PROTECTED] writes:
On Tue, 13 Feb 2007 10:48:39 -0800 Stephane Eranian [EMAIL PROTECTED]
wrote:
I have released another version of the perfmon new code base package.
Can we have a bug push to get this merged up please?
Yes, there certainly seems to be user interest in this.
I've been merging the x86 specific infrastructure Stephane sent.
So hopefully the basics are there already.
Yes, almost everything is in there now. Tony Luck told me he has integrated
the idle notifier for IA-64. I saw that the i386 version of the notifier
was recently integrated as well. So I think that for 2.6.21 we'll have
everything we need for i386, x86-64 and ia64. On MIPS and PowerPC,
a few things are still missing but they should be fixed soon.
On x86-64 and i386, the one last thing I would need that you do not already
have is in the NMI handler for the architectural perfmon to switch PERFCTR0
to PERFCTR1. This would allow certain events to be measured while the NMI
watchdog is active. This is needed on Intel Core-based processors where
certain events can ONLY be measured by PERFCTR0. The CPU_CLK_UNHALTED event
used by the watchdog can be measured by any counter.
I have attached the x86-64 patch for this. I can submit the i386 version
as well.
The big open question was still the review of the syscall interface.
Probably needs some determined reviewers.
Not a problem.
I did a review of some of the basic low level code some time ago;
there were some issues but I believe they are probably all resolved
by now (but I haven't verified that recently)
Yes, all the changes and fixes you and Andrew had requested have been made.
changelog:
- for architectural perfmon support, switch from PERFCTR0 to PERFCTR1.
this does free PERFCTR0 which is the only counter supported for
certain
events on Intel Core-based processors.
signed-off-by: stephane eranian [EMAIL PROTECTED]
diff --exclude=.git -urp linux-2.6.20.base/arch/x86_64/kernel/nmi.c
linux-2.6.20/arch/x86_64/kernel/nmi.c
--- linux-2.6.20.base/arch/x86_64/kernel/nmi.c 2007-02-05 00:31:52.0
-0800
+++ linux-2.6.20/arch/x86_64/kernel/nmi.c 2007-02-09 09:44:29.0
-0800
@@ -275,7 +275,7 @@ int __init check_nmi_watchdog (void)
* 32nd bit should be 1, for 33.. to be 1.
* Find the appropriate nmi_hz
*/
- if (wd-perfctr_msr == MSR_ARCH_PERFMON_PERFCTR0
+ if (wd-perfctr_msr == MSR_ARCH_PERFMON_PERFCTR1
((u64)cpu_khz * 1000) 0x7fffULL) {
nmi_hz = ((u64)cpu_khz * 1000) / 0x7fffUL + 1;
}
@@ -615,8 +615,8 @@ static int setup_intel_arch_watchdog(voi
(ebx ARCH_PERFMON_UNHALTED_CORE_CYCLES_PRESENT))
goto fail;
- perfctr_msr = MSR_ARCH_PERFMON_PERFCTR0;
- evntsel_msr = MSR_ARCH_PERFMON_EVENTSEL0;
+ perfctr_msr = MSR_ARCH_PERFMON_PERFCTR1;
+ evntsel_msr = MSR_ARCH_PERFMON_EVENTSEL1;
if (!reserve_perfctr_nmi(perfctr_msr))
goto fail;
@@ -855,7 +855,7 @@ int __kprobes nmi_watchdog_tick(struct p
dummy = ~P4_CCCR_OVF;
wrmsrl(wd-cccr_msr, dummy);
apic_write(APIC_LVTPC, APIC_DM_NMI);
- } else if (wd-perfctr_msr ==
MSR_ARCH_PERFMON_PERFCTR0) {
+ } else if (wd-perfctr_msr ==
MSR_ARCH_PERFMON_PERFCTR1) {
/*
* ArchPerfom/Core Duo needs to re-unmask
* the apic vector
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 000/196] V4L/DVB updates
On Thu, Feb 15, 2007 at 03:59:55AM -0200, Mauro Carvalho Chehab wrote: Basically, this series adds support for a bunch of newer cards and newer drivers, do some relevant cleanups on cx88 (improving source code readability and reducing binary code size), adds FM radio support on pvrusb2 and do several other fixes and improvements. A more detailed log: [removed 100+ lines of stuff] PS.: Due to the size of this series, I'm not mailbombing them into LKML. V4L/DVB development is hosted at http://linuxtv.org Why weren't these submitted in smaller batches? Why were all these patches held back before releasing any? Heikki Orsila - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/6] scsi: megaraid_sas - throttle io if FW is busy
Sumant Patro wrote:
Checks added in megasas_queue_command to know if FW is able to process
commands within the timeout period. If number of retries is 2 or more,
the driver stops sending cmd to FW. IO is resumed when pending cmd count
reduces to 16 or 10 seconds has elapsed from the time cmds were last
sent to FW.
Signed-off-by: Sumant Patro [EMAIL PROTECTED]
---
drivers/scsi/megaraid/megaraid_sas.c | 27 +
drivers/scsi/megaraid/megaraid_sas.h |3 ++
2 files changed, 30 insertions(+)
[snip]
diff -uprN linux-feb13-new-p2/drivers/scsi/megaraid/megaraid_sas.h
linux-feb13-new-p3/drivers/scsi/megaraid/megaraid_sas.h
--- linux-feb13-new-p2/drivers/scsi/megaraid/megaraid_sas.h 2007-02-13
07:22:40.0 -0800
+++ linux-feb13-new-p3/drivers/scsi/megaraid/megaraid_sas.h 2007-02-13
11:37:09.0 -0800
@@ -1102,6 +1102,9 @@ struct megasas_instance {
atomic_t fw_outstanding;
u32 hw_crit_error;
+ u8 is_busy;
Why not bool is_busy:8;? It obviously is a boolean. I would also think
false/true would be more descriptive then 0/1.
Richard Knutsson
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] Suspend to RAM, Sony Vaio PCG-SRX51P, lcd stays off
Hi! I own an older Sony Vaio SRX51P, European Model, P3 based. s2ram identifies it with sys_vendor = Sony Corporation sys_product = PCG-SRX51P(DE) sys_version = 01 bios_version = R0232U2 Suspend to RAM by using s2ram -v -m -f actually works and the laptop comes back to life, is accessible by network, etc. kudos so far. The only but serious problem is, that the lcd stays off after resume. No matter what kind of options for s2ram I try, if I disable Is the _lcd_ off or the _backlight_ off? Use bright flashlight to tell. framebuffer or suspend from X, the lcd always stays off. Only a reboot fixes this. Note that the X driver also cannot dis-/enable the lcd (xset dpms force off). It always stays lit. I also tried with i810switch, but that also does not affect the lcd. spicctrl -b42 neither. Latest kernel I tested is 2.6.20-git11 from today. So has anyone of you suspend, acpi, sonypi, fb people an idea how to fix this? I suspect one has to call some magic ACPI method upon resume? What other kind of information would be needed to debug this? Anything more to try? Are there some sony people here listening who can fix this? sonypi people actually might know how to help... 00:02.0 VGA compatible controller: Intel Corporation 82815 CGC [Chipset Graphics Controller] (rev 11) Wait a moment, did not Intel release nice, commented, GPLed sources for their graphics cards somewhere? That might help. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] UML hang with 100% CPU
Strangely enough after continuing in gdb, UML is back to normal, and I can't make it hang any more. It must be something timing related. Can you see if the patch below fixes it? Yay! Got my nice fast UML back instead of ugly slow QEmu ;) Seems to work perfectly now. Thanks, Miklos - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] Suspend to RAM, Sony Vaio PCG-SRX51P, lcd stays off
Pavel Machek wrote: Hi! I own an older Sony Vaio SRX51P, European Model, P3 based. s2ram identifies it with sys_vendor = Sony Corporation sys_product = PCG-SRX51P(DE) sys_version = 01 bios_version = R0232U2 Suspend to RAM by using s2ram -v -m -f actually works and the laptop comes back to life, is accessible by network, etc. kudos so far. The only but serious problem is, that the lcd stays off after resume. No matter what kind of options for s2ram I try, if I disable Is the _lcd_ off or the _backlight_ off? Use bright flashlight to tell. The lcd. If you press the lid button you get the same effect (but you cannot use it to turn the lcd on again :-(( ). But I'll doublecheck with a flashlight nevertheless. framebuffer or suspend from X, the lcd always stays off. Only a reboot fixes this. Note that the X driver also cannot dis-/enable the lcd (xset dpms force off). It always stays lit. I also tried with i810switch, but that also does not affect the lcd. spicctrl -b42 neither. Latest kernel I tested is 2.6.20-git11 from today. So has anyone of you suspend, acpi, sonypi, fb people an idea how to fix this? I suspect one has to call some magic ACPI method upon resume? What other kind of information would be needed to debug this? Anything more to try? Are there some sony people here listening who can fix this? sonypi people actually might know how to help... 00:02.0 VGA compatible controller: Intel Corporation 82815 CGC [Chipset Graphics Controller] (rev 11) Wait a moment, did not Intel release nice, commented, GPLed sources for their graphics cards somewhere? That might help. URL? But I suspect the lcd on/off is controlled by some embedded controller or such (reachable via acpi, at least I've an EC0 in /proc/acpi/). Jan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] Suspend to RAM, Sony Vaio PCG-SRX51P, lcd stays off
Hi! I own an older Sony Vaio SRX51P, European Model, P3 based. s2ram identifies it with sys_vendor = Sony Corporation sys_product = PCG-SRX51P(DE) sys_version = 01 bios_version = R0232U2 Suspend to RAM by using s2ram -v -m -f actually works and the laptop comes back to life, is accessible by network, etc. kudos so far. The only but serious problem is, that the lcd stays off after resume. No matter what kind of options for s2ram I try, if I disable Is the _lcd_ off or the _backlight_ off? Use bright flashlight to tell. The lcd. If you press the lid button you get the same effect (but you cannot use it to turn the lcd on again :-(( ). But I'll doublecheck with a flashlight nevertheless. If lid button breaks the lcd, even in grub boot loader... then I'd call your machine broken hardware, complain to the manufacturer. (Are you at latest BIOS?) framebuffer or suspend from X, the lcd always stays off. Only a reboot fixes this. Note that the X driver also cannot dis-/enable the lcd (xset dpms force off). It always stays lit. I also tried with i810switch, but that also does not affect the lcd. spicctrl -b42 neither. Latest kernel I tested is 2.6.20-git11 from today. So has anyone of you suspend, acpi, sonypi, fb people an idea how to fix this? I suspect one has to call some magic ACPI method upon resume? What other kind of information would be needed to debug this? Anything more to try? Are there some sony people here listening who can fix this? sonypi people actually might know how to help... 00:02.0 VGA compatible controller: Intel Corporation 82815 CGC [Chipset Graphics Controller] (rev 11) Wait a moment, did not Intel release nice, commented, GPLed sources for their graphics cards somewhere? That might help. URL? But I suspect the lcd on/off is controlled by some embedded controller or such (reachable via acpi, at least I've an EC0 in /proc/acpi/). Google a bit, it was a _big_ announcement. Of course it is _possible_ EC is responsible, but I don't quite think so. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH]mm incorrect direct io error handling (v4)
Incorrect direct io error handling (v4)
Changes from v3:
- Patch preparead gainst 2.6.20-rc6-mm3. It seems now it's not conflict
with Nick's stuff.
- fix generic segment check function.
LOG:
If generic_file_direct_write() has fail (ENOSPC condition) inside
__generic_file_aio_write_nolock() it may have instantiated
a few blocks outside i_size. And fsck will complain about wrong i_size
(ext2, ext3 and reiserfs interpret i_size and biggest block difference as
error),
after fsck will fix error i_size will be increased to the biggest block,
but this blocks contain gurbage from previous write attempt, this is not
information leak, but its silence file data corruption. This issue affect
fs regardless the values of blocksize or pagesize.
We need truncate any block beyond i_size after write have failed , do in simular
generic_file_buffered_write() error path. Initialy i've proposed do it in
__generic_file_aio_write_nolock() with explicit guarantee i_mutex always held,
but not everybody was agree with it. So we may safely call vmtruncate() inside
generic_file_aio_write(), here i_mutex already locked.
TEST_CASE:
open(/mnt/test/BIG_FILE, O_WRONLY|O_CREAT|O_DIRECT, 0666) = 3
write(3, aaa..., 104857600) = -1 ENOSPC (No space left on device)
#stat /mnt/test/BIG_FILE
File: `/mnt/test/BIG_FILE'
Size: 0 Blocks: 110896 IO Block: 1024 regular empty file
file size is less than biggest block idx
Device: fe07h/65031dInode: 14 Links: 1
Access: (0644/-rw-r--r--) Uid: (0/root) Gid: (0/root)
Access: 2007-01-24 20:03:38.0 +0300
Modify: 2007-01-24 20:03:38.0 +0300
Change: 2007-01-24 20:03:39.0 +0300
#fsck.ext3 -f /dev/VG/test
e2fsck 1.39 (29-May-2006)
Pass 1: Checking inodes, blocks, and sizes
Inode 14, i_size is 0, should be 56556544. Fixy? yes
Pass 2: Checking directory structure
Changes not dirrectly connected with issue:
- move common segment checks to separate helper function.
Patch pass ltp and fsstres test.
Signed-off-by: Dmitriy Monakhov [EMAIL PROTECTED]
---
diff --git a/mm/filemap.c b/mm/filemap.c
index 529eb9e..5f189e0 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1170,6 +1170,31 @@ success:
return size;
}
+int generic_segment_checks(const struct iovec *iov, unsigned long *nr_segs,
+ size_t *count, unsigned long access_flags)
+{
+ unsigned long seg;
+ for (seg = 0; seg *nr_segs; seg++) {
+ const struct iovec *iv = iov[seg];
+
+ /*
+* If any segment has a negative length, or the cumulative
+* length ever wraps negative then return -EINVAL.
+*/
+ *count += iv-iov_len;
+ if (unlikely((ssize_t)(*count|iv-iov_len) 0))
+ return -EINVAL;
+ if (access_ok(access_flags, iv-iov_base, iv-iov_len))
+ continue;
+ if (seg == 0)
+ return -EFAULT;
+ *nr_segs = seg;
+ *count -= iv-iov_len; /* This segment is no good */
+ break;
+ }
+ return 0;
+}
+
/**
* generic_file_aio_read - generic filesystem read routine
* @iocb: kernel I/O control block
@@ -1191,24 +1216,9 @@ generic_file_aio_read(struct kiocb *iocb, const struct
iovec *iov,
loff_t *ppos = iocb-ki_pos;
count = 0;
- for (seg = 0; seg nr_segs; seg++) {
- const struct iovec *iv = iov[seg];
-
- /*
-* If any segment has a negative length, or the cumulative
-* length ever wraps negative then return -EINVAL.
-*/
- count += iv-iov_len;
- if (unlikely((ssize_t)(count|iv-iov_len) 0))
- return -EINVAL;
- if (access_ok(VERIFY_WRITE, iv-iov_base, iv-iov_len))
- continue;
- if (seg == 0)
- return -EFAULT;
- nr_segs = seg;
- count -= iv-iov_len; /* This segment is no good */
- break;
- }
+ retval = generic_segment_checks(iov, nr_segs, count, VERIFY_WRITE);
+ if (retval)
+ return retval;
/* coalesce the iovecs and go direct-to-BIO for O_DIRECT */
if (filp-f_flags O_DIRECT) {
@@ -2103,8 +2113,9 @@ generic_file_direct_write(struct kiocb *iocb, const
struct iovec *iov,
/*
* Sync the fs metadata but not the minor inode changes and
* of course not the data as we did direct DMA for the IO.
-* i_mutex is held, which protects generic_osync_inode() from
-* livelocking. AIO O_DIRECT ops attempt to sync metadata here.
+* i_mutex may not being held, if so some specific locking
+* ordering must protect generic_osync_inode() from livelocking.
+* AIO O_DIRECT ops attempt to sync metadata here.
*/
Re: [linux-pm] Suspend to RAM, Sony Vaio PCG-SRX51P, lcd stays off
Pavel Machek wrote: Hi! I own an older Sony Vaio SRX51P, European Model, P3 based. s2ram identifies it with sys_vendor = Sony Corporation sys_product = PCG-SRX51P(DE) sys_version = 01 bios_version = R0232U2 Suspend to RAM by using s2ram -v -m -f actually works and the laptop comes back to life, is accessible by network, etc. kudos so far. The only but serious problem is, that the lcd stays off after resume. No matter what kind of options for s2ram I try, if I disable Is the _lcd_ off or the _backlight_ off? Use bright flashlight to tell. The lcd. If you press the lid button you get the same effect (but you cannot use it to turn the lcd on again :-(( ). But I'll doublecheck with a flashlight nevertheless. If lid button breaks the lcd, even in grub boot loader... then I'd call your machine broken hardware, complain to the manufacturer. (Are you at latest BIOS?) No, you misunderstood me. If I press the lid button, the lcd goes off and when I release it, it goes on again. But after a suspend cycle even that does not revive the lcd. Jan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] at drivers/char/vt.c:3332 do_blank_screen() on resume
15 Şub 2007 Per tarihinde, Andrew Morton şunları yazmıştı: On Thu, 15 Feb 2007 11:40:32 +0100 Pavel Machek [EMAIL PROTECTED] wrote: Contact fbcon people... There aren't any, basically. Since Tony disappeared James has been helping out but doesn't have a lot of time. So we're pretty much on our own with problems in this area. I already sent same mail to linux-fbdev-devel mailing lists at sf.net with hope :) Cheers -- S.Çağlar Onur [EMAIL PROTECTED] http://cekirdek.pardus.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house! pgpxmJAeQSCgt.pgp Description: PGP signature
Re: GPL vs non-GPL device drivers
On Thu, 2007-02-15 at 12:51 +0200, Mohammed Gamal wrote: I am still a kernel newbie, and I am still not very much aware about the GPL vs. Non-GPL drivers debate. I personally think it'd be better that all drivers should be GPL'd but if that's the case, what would be the legal position of such vendors as ATI or NVIDIA who supply closed source drivers? Would it be illegal to use them? Yeah, this is a recurrent debate, and the positions are mixed. Linus said that the nvidia driver isn't developed only for linux but also for windows, so it's not a true derivative of the kernel, so the GPL doesn't really apply. But not everyone (I mean core developpers) fully agrees IIRC. But that's not the case with VJ's drivers, which are apparently solely for linux, so should be distributed under the GPL. Xav - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/15/07, Xavier Bestel [EMAIL PROTECTED] wrote: But that's not the case with VJ's drivers, which are apparently solely for linux, so should be distributed under the GPL. In any case, you're free to use any driver, regardless of license.. copyright does not cover use, only copying and most, if not all, jurisdictions make it clear that copying into memory is not a copyright matter. Trent - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
Our source code is meaningless to the Open Source community at large. It is only useful to our tiny set of competitors that have nothing to do with Linux. The Embedded space is very specific. We are only _using_ Linux. Just as we could have used VxWorks or OSE. Using our source code would not benefit anybody but our competitors. What a load of B.S. I'm working with embedded Linux for five years and hear that shit more or less every day. Is it mantra for happiness here or what? That's TOTALLY wrong. You basically are saying that your main competitors are your own customers. People do with stuff absolutely unpredictable things creators often even cannot think about. And then they become your /competitors/. That what is called innovation. Linux precisely thriving, since it gave power back to consumers - and allowed them to use things they have bought to their fullest. Few people can clearly state what they need - and Linux allow them (w/o thinking hard formulating on bug report to you - and sparing your time on guessing what user really wants) to take it and adopt it to their own needs. I have customers who did absolutely crazy things with embedded systems - putting to better use those few resources original system had left redundant. (Just recall LinkSys' WRT54G - and it is just but one of the examples. In corporate world it is also happening all the time - just let customers in.) Also, to the question of not benefit anybody. I have seen piles of rare/obscure hardware which is rare/obscure precisely because there are no drivers for it. And guess how hardware/OS selection works: primary question is availability of ready drivers and/or effort it would take to adopt existing drivers. This is vital part of embedded system costs: engineering costs. Your vendor had driven itself into lock-in: you have unique drivers for unique piece hardware and costs cannot be cut because hardware doesn't become commodity. And it can't become commodity (nor can be standardized) due to lack of open drivers. .. and I've seen it before, .. and I'll see it again (c) Propellerheads. -- Don't walk behind me, I may not lead. Don't walk in front of me, I may not follow. Just walk beside me and be my friend. -- Albert Camus (attributed to) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Thu, Feb 15, 2007 at 12:00:56PM +0100, Xavier Bestel wrote: On Thu, 2007-02-15 at 12:51 +0200, Mohammed Gamal wrote: I am still a kernel newbie, and I am still not very much aware about the GPL vs. Non-GPL drivers debate. I personally think it'd be better that all drivers should be GPL'd but if that's the case, what would be the legal position of such vendors as ATI or NVIDIA who supply closed source drivers? Would it be illegal to use them? Yeah, this is a recurrent debate, and the positions are mixed. Linus said that the nvidia driver isn't developed only for linux but also for windows, so it's not a true derivative of the kernel, so the GPL doesn't really apply. But not everyone (I mean core developpers) fully agrees IIRC. to further expand on the above question it isn't really crystal clear whether this (from the ATI driver) is legal.. (psuedo diff vs the kernel agp drivers) +#ifdef STANDALONE_AGPGART MODULE_AUTHOR(Jeff Hartmann [EMAIL PROTECTED]); MODULE_PARM(agp_try_unsupported, 1i); #ifdef MODULE_LICENSE MODULE_LICENSE(GPL and additional rights); +#endif and then linking the result to their binary blob. I assume ATI's lawyers think its legal, as it's been a year and a half since I first brought this questionable act to their attention. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Thu, Feb 15, 2007 at 09:05:11PM +1000, Trent Waddington wrote: On 2/15/07, Xavier Bestel [EMAIL PROTECTED] wrote: But that's not the case with VJ's drivers, which are apparently solely for linux, so should be distributed under the GPL. In any case, you're free to use any driver, regardless of license.. copyright does not cover use, only copying and most, if not all, jurisdictions make it clear that copying into memory is not a copyright matter. One area that is clear however is distribution of the result. You're free to do whatever you want to my code as long as it never leaves your computer. As soon as you give it to someone else, you're bound by the conditions of the license to give copies of the modified source. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Unify pcspeaker platform device code between i386/x86-64
On Thu, Feb 15, 2007 at 10:49:57AM +0100, Andi Kleen wrote: It's always seemed broken (though perhaps this was a distro bug?) in module form, so I've been compiling it in to get it to work. Must have been a distro bug. It should have worked before as long as the config was enabled. If so, I'm not sure what distro Jeff was running, as it worked fine in Fedora for some time on both 32bit and 64bit x86 for me. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.20-git10: BUG at drivers/pci/pci.c:817 during suspend to disk
Update: On Thursday, 15 February 2007 00:16, Rafael J. Wysocki wrote: Hi, I've got this in the resume-during-suspend phase of suspend to disk with 2.6.20-git10 on HPC nx6325: PCI: Setting latency timer of device :00:06.0 to 64 sata_sil :00:12.0: resuming BUG: at drivers/pci/pci.c:817 pcim_enable_device() Call Trace: [8031c05e] pcim_enable_device+0x93/0xb3 [8039a74c] ata_pci_device_do_resume+0x21/0x5e [803a5f8a] sil_pci_device_resume+0x1c/0x51 [8031e072] pci_device_resume+0x22/0x53 [8038bea4] resume_device+0xca/0x131 [8038bf8c] dpm_resume+0x81/0xd3 [8038c00e] device_resume+0x30/0x45 [802a0d8c] snapshot_ioctl+0x245/0x63e [8023f7f2] do_ioctl+0x5e/0x77 [8022dab2] vfs_ioctl+0x25c/0x279 [8024948a] sys_ioctl+0x5f/0x82 [8021555d] sys_write+0x47/0x70 [8025911e] system_call+0x7e/0x83 The box has survived the entire suspend-resume cycle, though, and seems to be fully functional. I get this 100% of the time, but the box suspends and behaves normally after the resume. Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Unify pcspeaker platform device code between i386/x86-64
Dave Jones wrote: On Thu, Feb 15, 2007 at 10:49:57AM +0100, Andi Kleen wrote: It's always seemed broken (though perhaps this was a distro bug?) in module form, so I've been compiling it in to get it to work. Must have been a distro bug. It should have worked before as long as the config was enabled. If so, I'm not sure what distro Jeff was running, as it worked fine in Fedora for some time on both 32bit and 64bit x86 for me. Fedora's always had this problem for me, on most if not all the active computers in my lab :) Maybe my house is over a magetic ley line or something :) 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: GPL vs non-GPL device drivers
On 2/15/07, Dave Jones [EMAIL PROTECTED] wrote: I assume ATI's lawyers think its legal, as it's been a year and a half since I first brought this questionable act to their attention. Lawyers don't think X is legal.. that's not how lawyers think. If ATI's lawyers have advised ATI on this at all, and ATI has taken their lawyers' advice, then the advice would have been: we believe the risk of liability is acceptable. The only reason I can imagine why a lawyer would advise a client that it is an acceptable risk to do something legally questionable with the linux kernel is that so few kernel people have been sued for, or given notice of, an infringement. If any of the kernel developers, other than Harald Welte, are enforcing their copyright, they don't tend to publicize it. I, personally, don't know why anyone who owned copyright on any GPL software and had no desire to enforce that copyright, would not offer to assign their copyright to the FSF so they can defend it.. but I imagine people have their reasons. Trent - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
(no subject)
unsubscribe linux-kernel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
v j [EMAIL PROTECTED] wrote: On 2/14/07, Arjan van de Ven [EMAIL PROTECTED] wrote: On Wed, 2007-02-14 at 21:16 -0800, v j wrote: This is in reference to the following thread: http://lkml.org/lkml/2006/12/14/63 I am not sure if this is ever addressed in LKML, but linux is _very_ popular in the embedded space. We (an embedded vendor) chose Linux 3 years back because of its lack of royalty model, robustness and availability of infinite number of open-source tools. I think you have a bit of a misunderstanding... Linux is not royalty free. Just the royalty is not in the form of cash, but in the form of having to give your improvements back to the open source world. Sure. But this is not legally binding. Gee, you have the choice: Be bound, or be using something different because you opted not to accept the license that would allow you to use linux. If you use linux and say I don't accept the license, it's like stepping into a train saying I don't want to make a contract, so I don't have to pay. -- Funny quotes: 14. Eagles may soar, but weasels don't get sucked into jet engines. Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
Hello! I think you have a bit of a misunderstanding... Linux is not royalty free. Just the royalty is not in the form of cash, but in the form of having to give your improvements back to the open source world. Sure. But this is not legally binding. Maybe it's not, but it certainly doesn't mean that the kernel developers should try to make your life easier, especially if they believe that what you do is unethical. Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED] http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth This message is transmitted on 100% recycled electrons. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Thu, Feb 15, 2007 at 06:30:33PM +1100, Neil Brown wrote: On Wednesday February 14, [EMAIL PROTECTED] wrote: I am well aware of what Greg KHs position is, in fact he is the reason I started the whole rant. This is only a plea to the higher authorities. Linus, please save Linux! Linus is not in any position to do anything. The die is cast. You should speak to a lawyer. The key issue is this: Does combining your work with Linux create a derived work. If it does not, you have nothing to worry about. If it does, then maybe you should worry. If someone who owns copyright in part of the Linux kernel that you are using, decides that they think you have created a derived work, then they might bring this to your attention and ask you to abide by the conditions in the license under which you obtained the Linux kernel. If no suitable resolution can be found, they might take you to court for using their protected work without a valid license (The GPL becomes void if you breach it's requirements). And then the judge might or might not find against you. But it is very hard to know in advance how the judge will decide in a particular case. Hence the best advice is to speak to a lawyer, They have the best chance of advising your how to minimise your risk. I hope that makes the situation clear enough. You missed one point: In every country you distribute your product, a local kernel developer could bring the case to a local court based on local copyright law. NeilBrown cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add PM_TRACE x86_64 support.
On Thu, 08 Feb 2007 13:08:06 +1100 Nigel Cunningham [EMAIL PROTECTED] wrote: This patch add x86_64 support for PM_TRACE, and shifts per-arch code to the appropriate subdirectories. ia64 allmodconfig: include/linux/resume-trace.h:4:30: asm/resume-trace.h: No such file or directory drivers/base/power/resume.c: In function `resume_device': drivers/base/power/resume.c:28: warning: implicit declaration of function `TRACE_RESUME' - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.20 mmc: problem with highspeed SD card
On 2/15/07, Pierre Ossman [EMAIL PROTECTED] wrote: Eugene Ilkov wrote: I have I/O errors with Transcend SD highspeed card 2GB/150x when it's mounted in r/w mode (cardreader on sharp sl-c1000) It works well if I reverse mmcv4 patch commited to 2.6.19-git2 (http://lkml.org/lkml/2006/10/4/27) That patch is not the same as you are referencing in the rest of your mail. I geuss changes was started from that patch, I mean changes that comes with that: http://www.linuxhq.com/kernel/v2.6/19-git2/drivers/mmc/mmc.c I found another related patch http://mailman.laptop.org/pipermail/commits-kernel/2007-January/000554.html so i guess i'm not alone I'm not experienced in mmc, but I figured out that problem is somewhere in mmc_read_switch_caps() and when i change cmd.arg value from 0x80F1 to 0x00F1 it works fine too What argument should have SD_SWITCH opcode? The argument is correct, so I'm guessing that your controller might be a bit flaky and not handle the new timing. Can you enable MMC_DEBUG and send over the dmesg? mmc debug output is too noisy and i can give you only this: mmc0: starting CMD18 arg 30007e00 flags 0035 PXAMCI: irq 0004 stat 2140 PXAMCI: irq 0005 stat 2940 PXAMCI: irq 0007 stat 3940 mmc0: req done (CMD18): 0/0/0: 0900 5f5a83d5 2db7ffbf 96800012 mmc0: starting CMD18 arg ae00 flags 0035 PXAMCI: irq 0004 stat 2140 PXAMCI: irq 0005 stat 2940 PXAMCI: irq 0007 stat 3940 mmc0: req done (CMD18): 0/0/0: 0900 5f5a83d5 2db7ffbf 96800012 mmc0: starting CMD18 arg 0ab49e00 flags 0035 PXAMCI: irq 0004 stat 2140 PXAMCI: irq 0005 stat 2940 PXAMCI: irq 0007 stat 3940 mmc0: req done (CMD18): 0/0/0: 0900 5f5a83d5 2db7ffbf 96800012 mmc0: starting CMD18 arg 0ab4ae00 flags 0035 PXAMCI: irq 0004 stat 2140 PXAMCI: irq 0005 stat 2940 PXAMCI: irq 0007 stat 3940 mmc0: req done (CMD18): 0/0/0: 0900 5f5a83d5 2db7ffbf 96800012 with desabled mmc debug : Linux version 2.6.20-rc1-mm1-z2 ([EMAIL PROTECTED]) (gcc version 4.1.1 (Gentoo 4.1.1-r3)) #58 PREEMPT Thu Feb 15 13:49:39 MSK 2007 CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE), cr=397f Machine: SHARP Akita [..skipped..] mmcblk0: mmc0:b368 SDC 2009600KiB mmcblk0: p1 mmcblk0: error 2 transferring data mmcblk0: error 2 transferring data kjournald starting. Commit interval 5 seconds mmcblk0: error 2 transferring data EXT3 FS on mmcblk0p1, internal journal EXT3-fs: recovery complete. mmcblk0: error 2 transferring data EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem). Freeing init memory: 72K mmcblk0: error 2 transferring data mmcblk0: error 2 transferring data mmcblk0: error 2 transferring data mmcblk0: error 2 transferring data mmcblk0: error 2 transferring data mmcblk0: error 2 transferring data mmcblk0: error 2 transferring data i boot into root fs on SD, and it just hangs on remounting to rw, so it's not easy to get full dmesg output with i/o error and mmc debug info, but i'll try if it helps - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] more support for memory-less-node.
Andi Kleen [EMAIL PROTECTED] wrote: Now if it's better to set up a empty node or use a nearby node for a memory less cpu can be further discussed. I still think I lean towards the later. Worst case: Only slot 0 is used. Plug your memoryless CPU card into the last slot before your plug the CPU+mem card into the last-1 slot. -- W.I.N.D.O.W.S.: Wireless Intelligent Neohuman Designed for Observation and Worldwide Sabotage -- http://www.brunching.com/toys/toy-cyborger.html Friß, Spammer: [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: [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug
On Thu, Feb 15, 2007 at 09:09:51AM +0100, Rafael J. Wysocki wrote: Why should we make sure that PF_NOFREEZE tasks are also frozen for cpu hotplug? Instead, we can create an infrastructure which allows threads to specify for the scenarios they would want to be excempted from freeze. Something like what Paul has suggested in http://lkml.org/lkml/2007/1/31/323. That way, threads which have nothing to do with the online_cpu_map or with handling of cpu-hotplug events can mark themselves to be exempted from being frozen for cpu hotplug. I think all kernel threads should call try_to_freeze() in suitable places anyway if we are going to use the freezer for anything more than just the suspend. In other words, they all should be _able_ to freeze if necessary. Yeah! I agree. I misunderstood your earlier point. I thought you were hinting at freezing *everyone* while doing a cpu hotplug. Once this is achieved, it's all about classifying the threads into according to their NO_FREEZE needs :) Yes, but I think it's just a generalization of ingoring PF_NOFREEZE. If all kernel threads are able to freeze, we can mark them as freeze for CPU hotplug or freeze for kprobes, or freeze for suspend etc. and call the freezer with the appropriate parameter. BTW, what happens to a process running on a CPU being removed? We call stop_machine_run in _cpu_down which schedules an idle thread on the cpu to be removed. Once the idle thread runs, we call __cpu_die and subsequently the scheduler performs task migration while handling the CPU_DEAD notification (see migration_call in sched.c) 2) We have to change the PM code to stop using CPU hotplug for disabling nonboot CPUs. ;-) Just wondering, how hard is that ? Hmmm. In fact the problem is that the suspend code freezes tasks and then calls disable_nonboot_cpus() which uses (_)cpu_down/up(). In principle we could make disable_nonboot_cpus() call some lower-level routines to avoid the freezing of tasks, _but_ the suspend code may freeze too few tasks (ie. we may want to freeze more tasks for the CPU hotplug). Thus I think we should do something like this: suspend: CPU hotplug: freeze_processes(SUSPEND) ... ... freeze_processes(CPU_HOTPLUG) ... ... ... thaw_processes(CPU_HOTPLUG) thaw_processes(SUSPEND) ... so freeze_processes() should be reentrant, at least for different values of the argument. That would still mean going over the task list twice. How if we have freeze_process(SUSPEND|CPU_HOTPLUG); perform_pre_hotplug_suspend(); primitive_cpu_down/_up(); perform_post_hotplug_suspend(); Does this look like a good thing to you? All in all, I think we should start from modifying the freezer and the classification of processes with respect to the freezing. Cool! Lets get started then ;-) Greetings, Rafael -- Gautham R Shenoy Linux Technology Center IBM India. Freedom comes with a price tag of responsibility, which is still a bargain, because Freedom is priceless! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
hi vj, On Thursday 15 February 2007, v j wrote: This is in reference to the following thread: http://lkml.org/lkml/2006/12/14/63 I am not sure if this is ever addressed in LKML, but linux is _very_ popular in the embedded space. We (an embedded vendor) chose Linux 3 years back because of its lack of royalty model, robustness and availability of infinite number of open-source tools. We recently decided to move to Linux 2.6 for our next product, mainly because Linux has worked so well for us in the past, and we would like to move up to keep up with the latest and greatest. you choose to move to linux 2.6 for your next product - fine. it has worked for you well in the past - fine. you would like to keep along with the latest and greatest - fine. _but_ for all those reasons you have to get along with all rules, licenses and at least all changes that the kernel community decided to perform. However in moving to 2.6, we noticed a number of alarming things. Porting drivers over from devfs to udev, though easy raised a number of alarming issues. Driver's no longer could dynamically allocate their MAJOR/MINOR numbers. Doing so would mean they would have to use sysfs. However it seems that sysfs (and the class_ interface) is only available to GPL modules. This is very concerning. The drivers which we have written over the last three years are suddenly under threat. We don't mind statically assigning MAJOR/MINOR numbers to our drivers. We can do this and modify our user space applications too. However we have a worrying trend here. If at some point it becomes illegal to load our modules into the linux kernel, then it is unacceptable to us. We would have been better off choosing VxWorks or OSE 3 years ago when we made an OS choice. The fact that Linux is becoming more and more closed is very very alarming. the trend is not worrying. we are not responsible for your decisions you made in the past. the only real FACT is that linux is being stated to BE OPEN and what is much more important to STAY OPEN for everybody. you chose it years ago, because of those facts. of course linux is very popular on embedded systems. i am working within some open source projects that also run on embedded hardware designs. your main mistake in understanding linux and our way to have it also more open in future than by now. what actually costs you more in future? opening your drivers, as much it must be, to have your hardware supported under 2.6 _or_ paying license fees for runtime/development tools for vxworks, ose whatever? and what will do complain at windriver or other companies, if they decide not to support your used cpu architecture anymore? this were my 0.2$ marcel p.s. you said you like linux for its royalty model - that also includes that you accept all the other rules and terms. e.g. gpl license _and_ its fullfillment. vj. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: GPL vs non-GPL device drivers
On Wed, Feb 14, 2007 at 10:16:44PM -0800, v j wrote: On 2/14/07, v j [EMAIL PROTECTED] wrote: This has nothing to do with politics. I am not a Linux contributor. I realize that people who have contributed to the Linux Kernel have very valid points. It is their sweat and blood. They have a right to protect what they have worked on. I am purely commenting from a user perspective. If Linux becomes closed to external drivers, then it will have repercussions in the embedded space. I can say for certain that a company evaluating OSes and realizing that their drivers will have to be open-source will almost certainly go for the alternative. So, to summarize: 1) You don't contribute to the kernel 2) You recognize the rights of contributors to do with their work what they please 3) you aren't willing to open source your kernel code. Why don't you just go with vxWorks or some other embedded OS? You've recognized that you are officially getting something (alot of something) for free here, and are unwilling to play by the rules those who have donated to you set out. Its not like you're doing anyone who contributes any favors by using Linux. Granted, its always good to have more linux devices out there, but if you can't play by the rules, don't play. And just so you know, making it easier for open source drivers to operate with the kernel than closed source drivers isn't closing the kernel, its reminding you that keeping your source closed in linux comes at a price. Neil On 2/14/07, Trent Waddington [EMAIL PROTECTED] wrote: On 2/15/07, v j [EMAIL PROTECTED] wrote: The drivers which we have written over the last three years are suddenly under threat. [..] The fact that Linux is becoming more and more closed is very very alarming. Sigh. Someone remind me of the rules against politics on the list before I get into why vj should play nice with the other children. Trent - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: GPL vs non-GPL device drivers
On 2/15/07, Mws [EMAIL PROTECTED] wrote: hi vj, On Thursday 15 February 2007, v j wrote: This is in reference to the following thread: http://lkml.org/lkml/2006/12/14/63 I am not sure if this is ever addressed in LKML, but linux is _very_ popular in the embedded space. We (an embedded vendor) chose Linux 3 years back because of its lack of royalty model, robustness and availability of infinite number of open-source tools. We recently decided to move to Linux 2.6 for our next product, mainly because Linux has worked so well for us in the past, and we would like to move up to keep up with the latest and greatest. you choose to move to linux 2.6 for your next product - fine. it has worked for you well in the past - fine. you would like to keep along with the latest and greatest - fine. _but_ for all those reasons you have to get along with all rules, licenses and at least all changes that the kernel community decided to perform. However in moving to 2.6, we noticed a number of alarming things. Porting drivers over from devfs to udev, though easy raised a number of alarming issues. Driver's no longer could dynamically allocate their MAJOR/MINOR numbers. Doing so would mean they would have to use sysfs. However it seems that sysfs (and the class_ interface) is only available to GPL modules. This is very concerning. The drivers which we have written over the last three years are suddenly under threat. We don't mind statically assigning MAJOR/MINOR numbers to our drivers. We can do this and modify our user space applications too. However we have a worrying trend here. If at some point it becomes illegal to load our modules into the linux kernel, then it is unacceptable to us. We would have been better off choosing VxWorks or OSE 3 years ago when we made an OS choice. The fact that Linux is becoming more and more closed is very very alarming. the trend is not worrying. we are not responsible for your decisions you made in the past. the only real FACT is that linux is being stated to BE OPEN and what is much more important to STAY OPEN for everybody. you chose it years ago, because of those facts. of course linux is very popular on embedded systems. i am working within some open source projects that also run on embedded hardware designs. your main mistake in understanding linux and our way to have it also more open in future than by now. what actually costs you more in future? opening your drivers, as much it must be, to have your hardware supported under 2.6 _or_ paying license fees for runtime/development tools for vxworks, ose whatever? marcel, most of the vendors, who claim IP just cite nonsense. There are really hardly a few vendors who are really bound to the IP issue. Just that they do not know how to write proper code, they do not want to open up their code. In fact , such vendors do have a think probably like this if we open up our driver if people see the pathetic quality, the customers would probably think how bad is the hardware and probably affect our sales . So it would be better if we hide under the shade of the IP umbrella. Little do that these vendors know that customers wouldn't want to go alongwith such narrow minded vendors in the long run. But somehow due to a certain void people do the get along, that's it, not for long though. regards, manu - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: irqdesc porting help
Hi, My drivers in 2.6.14 use statements like desc-triggered = 1; And desc also points to some members of irqdesc which arent in 2.6.19 but in 2.6.14. Im a newbie, What changes am i supposed to make to make it work in 2.6.19. Im not sure what changes are exactly needed. Please Advice, Regards, Jo On 2/15/07, Russell King [EMAIL PROTECTED] wrote: On Thu, Feb 15, 2007 at 07:33:47PM +0900, Paul Mundt wrote: On Thu, Feb 15, 2007 at 12:01:37PM +0530, Maximus wrote: Im trying to port some drivers between 2.6.14 and 2.6.19 I find that irqdesc has changed completely. how do i port the drivers between 2.6.14 and 2.6.19? is there a porting guide available to port the drivers which use irqdesc?. my drivers use variables triggered, ... which dont exist in 2.6.19 irqdesc strcuture. Presumably you're talking about the struct hw_interrupt_type and the lack of an irq_desc[irq].handler? There's some migration helper glue in include/linux/irq.h that you can use, but you're better off converting completely. You can at least get it building again by changing to irq_desc[irq].chip, but you really want a proper irq_chip implementation to go along with this, rather than munging in the hw_interrupt_type. It should be asked - why are drivers poking about in the irqdesc structure? -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Feb 15 2007 18:43, Neil Brown wrote: We seem to have different definitions of open and closed. Open = 3rd party Linux drivers can be loaded. Closed = No third party Linux drivers can be loaded. Loading a driver is not at issue. Anyone may load a driver. And, after all, because loading is not distribution, you may rip out export_symbol_gpl and use sysfs directly. It does not make legal things any safer though, I'd say [ianal]. Jan -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
