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(&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: 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&tid=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, &p->sel, tmp.security,
delete);
security_xfrm_policy_free(&tmp);
}
- 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, everyt
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&tid=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, &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: [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/
