Re: [patch] mtrr: fix issues with large addresses
On Monday 05 February 2007 23:50, Siddha, Suresh B wrote: > On Mon, Feb 05, 2007 at 06:19:59PM +0100, Andreas Herrmann wrote: > > o added check to restrict base address to 36 bit on i386 > > Why is this? It can go upto implemented physical bits, right? In theory it can, but Linux doesn't support it. -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] Missing critical phys_to_virt in lib/swiotlb.c
On Monday 05 February 2007 22:35, Andrew Morton wrote: > On Sun, 04 Feb 2007 13:39:40 -0500 > David Moore <[EMAIL PROTECTED]> wrote: > > > From: David Moore <[EMAIL PROTECTED]> > > > > Adds missing call to phys_to_virt() in the > > lib/swiotlb.c:swiotlb_sync_sg() function. Without this change, a kernel > > panic will always occur whenever a SWIOTLB bounce buffer from a > > scatter-gather list gets synced. > > > > Signed-off-by: David Moore <[EMAIL PROTECTED]> > > --- > > > > This change was originally part of a larger patch by Jan Beulich, which > > was more extensive and doesn't look destined to make it into 2.6.20: > > http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm3/broken-out/ia64-swiotlb-bug-fixes.patch > > > > However, considering the severity of this one-liner bug, I would like to > > request that this simplified patch make it into 2.6.20, despite how > > close we are to the final cut. It fixes real crashes: > > http://lists.opensuse.org/opensuse-bugs/2006-12/msg02943.html > > http://qa.mandriva.com/show_bug.cgi?id=28224 > > http://www.pchdtv.com/forum/viewtopic.php?t=2063=a959a14a4c2db0eebaab7b0df56103ce > > > > --- linux-2.6.19.x86_64/lib/swiotlb.c.orig 2007-02-04 13:18:41.0 > > -0500 > > +++ linux-2.6.19.x86_64/lib/swiotlb.c 2007-02-04 13:19:43.0 > > -0500 > > @@ -750,7 +750,7 @@ swiotlb_sync_sg(struct device *hwdev, st > > > > for (i = 0; i < nelems; i++, sg++) > > if (sg->dma_address != SG_ENT_PHYS_ADDRESS(sg)) > > - sync_single(hwdev, (void *) sg->dma_address, > > + sync_single(hwdev, phys_to_virt(sg->dma_address), > > sg->dma_length, dir, target); > > } > > > > argh. I didn't know that Jan's patches fixed crashes. I thought they were > ia64-only things. Sounds weird. If this really didn't work much more should be broken (e.g. no cdroms/sound on Intel x86-64 boxes with >4GB) I'm a little sceptical. Perhaps the TV driver is doing something bogus here? Also I haven't heard of this problem before at all and I'm sure I would have if sounds/cdroms were broken. Shouldn't be applied without further analysis. > Who maintains the swiotlb code? Nobody. But I hacked last on it. -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 2/2] x86_64 irq: Handle irqs pending in IRR during irq migration.
* Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> When making the interrupt vectors per cpu I failed to handle a case
> during irq migration. If the same interrupt comes in while we are
> servicing the irq but before we migrate it the pending bit in the
> local apic IRR register will be set for that irq.
hm. I think this needs more work. For example this part of the fix looks
quite ugly to me:
> +static unsigned apic_in_service_vector(void)
> +{
> + unsigned isr, vector;
> + /* Figure out which vector we are servicing */
> + for (vector = FIRST_EXTERNAL_VECTOR; vector < FIRST_SYSTEM_VECTOR;
> vector += 32) {
> + isr = apic_read(APIC_ISR + ((vector/32) * 0x10));
> + if (isr)
> + break;
> + }
> + /* Find the low bits of the vector we are servicing */
> + vector += __ffs(isr);
> + return vector;
so we read the hardware to figure out what the hell we are doing. The
problem is - why doesnt the kernel know at this point what it is doing?
It knows the CPU and it should know all the vector numbers. It also has
an irq number.
> + /* If the irq we are servicing has moved and is not pending
> + * free it's vector.
> + */
> + irr = apic_read(APIC_IRR + ((vector/32) * 0x10));
the IRR is quite fragile. It's a rarely used hardware field and it has
erratums attached to it. Again, it seems like this function too tries to
recover information it /should/ already have.
> @@ -1400,19 +1439,24 @@ static int ioapic_retrigger_irq(unsigned int irq)
>
> static void ack_apic_edge(unsigned int irq)
> {
> - move_native_irq(irq);
> + if (unlikely(irq_desc[irq].status & IRQ_MOVE_PENDING)) {
> + move_native_irq(irq);
> + apic_handle_pending_vector(apic_in_service_vector());
> + }
> ack_APIC_irq();
this looks a bit ugly and a bit fragile. We had a simple
'move_native_irq()' call for IRQ balancing, which is straightforward,
but now we've got this complex condition open coded.
If then this should be done in some sort of helper - but even then, the
whole approach looks a bit erroneous.
To me the cleanest way to migrate an IRQ between two different vectors
on two different CPUs would be to first mask the IRQ source in the PIC,
then to do the migration /atomically/ (no intermediary state), and then
unmask. If the PIC loses edges while masked then that's a problem of the
irq chip implementation of the PIC: its ->set_affinity() method should
refuse to migrate edge-triggered IRQs if it can lose edges while
unmasked!
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: One-shot high-resolution POSIX timer periodically late
On Mon, 2007-02-05 at 17:37 +0100, John wrote: > Ingo Molnar wrote: > > > John wrote: > > > >> John Stultz wrote: > >> > >>> Also do check the -rt tree as Ingo suggested. I mis-read your earlier > >>> email and thought you were running it. > >> > >> I've been pulling my hair over a related issue for the past two days. > >> > >> (I think I may be tickling a -hrt bug...) > >> > >> I'm working with 2.6.18.6 + patch-2.6.18-rt7 > > > > 2.6.18-rt7 is pretty old, do you see the problem in 2.6.20-rc6-rt5 too? > > Ingo, Thomas, > > As far as I can tell, the -rt patch set is only updated for the latest > kernel version available. Is that correct? > > http://people.redhat.com/mingo/realtime-preempt/older/?M=D > > In other words, once 2.6.20 is released, and work starts on 2.6.21, if a > bug is discovered in -rt, the fix will not be back-ported to the > 2.6.20.x (and 2.6.19.x, and 2.6.18.x, etc) patch set? Correct, there is only 1 live branch. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Compressed ia32 ELF file generation for loading by Gujin 1/3
Vivek Goyal <[EMAIL PROTECTED]> writes: > On Mon, Feb 05, 2007 at 10:38:30PM -0800, H. Peter Anvin wrote: >> Vivek Goyal wrote: >> > >> >That time, grub was working fine but lilo had broken on one of Andrew's >> >machine. I could not reproduce the problem on my setup and had no clue what >> >was the issue. Hence got rid of ELF header from bzImage which was >> >non-essential >> >stuff for relocatable kernel. But that issue should be fixable. >> > >> >> Either way, though, putting Gujin-specific code in the main kernel >> output is a pretty dull thud. >> > > Agreed. Just for documentation the current interface is you come in through the kernels 16bit entry point and get all of it's BIOS calls, or your bootloader is responsible for getting the equivalent information somehow. >From what little I skimmed part of what Gujin wanted to do was sane at first glance. Just boot a gziped vmlinux like the other architectures. The problem was the 16bit code. So there may be some good ideas buried in there somewhere, but it likely to take some doing, and patches that I have to save before I read them are a real pain! Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 PCI Cannot allocate resource region 2
On 2/6/07, Grant Grundler <[EMAIL PROTECTED]> wrote: On Tue, Feb 06, 2007 at 10:28:56AM +0400, Manu Abraham wrote: > On 2/6/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > >On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler > ><[EMAIL PROTECTED]> wrote: > > > >> On Mon, Feb 05, 2007 at 09:55:28PM -0700, Grant Grundler wrote: > >> ... > >> > > Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- > >ParErr- Stepping- SERR- FastB2B- > >> > > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > >SERR+ >> > > Latency: 0, Cache Line Size 0c > >> > > BIST is running > >> > > >> > BIST is required to complete in 2 seconds. Either with success or > >failure. > >> > I expect BIOS to have complained before launching grub/lilo. > >> > >> Gregkh, > >> I just realized linux-pci bus scan should ignore devices (print a > >warning) > >> which have BIST set. Want a patch for this? > >> > >> Slight risk some previously "working" device which violates the > >> spec might get ignored...but I hope there aren't too many of those. > > > >Should we wait two seconds before declaring the device dead? To see > >whether > >it will come back? > > > > > Wonders ! > > I was about to give the card it's last rites. I thought well let me > try under the other OS Could you be more specific? Which OS? FreeBSD? :) Hehe, we don't get question marks and stuff like that for those OS 's .. ;-) M$ XP SP2 > I didn't have any drivers for the same, since the demodulator driver > doesn't exist in the other OS also, but the bridge device does have > the driver. > > I plugged the card in, the OS searched for drivers, since i didn't > have any didn't load any.. > So it went under a question mark. > > Looking under Resources, > > It showed the PCI information string like this .. > > PCI\VEN_1822_4E35_00311822_01\4&2E98101C&0&10F0 > > then i thought try with the driver eventhough support for the > demodulator doesn't exist .. > > Downloaded and installed drivers .. > > Lo ..! > > Memory Range: F87FF000 - F87F > IRQ : 17 > > it got assigned a memory region indeed. Excellent. > So, to wrap it up, the device is not dead .. We have something wrong > in the PCI subsystem probably. Hrm maybe but not likely. I'm more inclined to believe PCI subsystem is missing hacks needed for that device and/or BIOS. I have access to the source there, but there are no PCI specific stuff, i think the NT HAL just handles all the PCI stuff over there. It would be great , if we could have the missing hacks under Linux as well. grant 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: 2.6.20 PCI Cannot allocate resource region 2
On Tue, Feb 06, 2007 at 10:28:56AM +0400, Manu Abraham wrote: > On 2/6/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > >On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler > ><[EMAIL PROTECTED]> wrote: > > > >> On Mon, Feb 05, 2007 at 09:55:28PM -0700, Grant Grundler wrote: > >> ... > >> > > Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- > >ParErr- Stepping- SERR- FastB2B- > >> > > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > >SERR+ >> > > Latency: 0, Cache Line Size 0c > >> > > BIST is running > >> > > >> > BIST is required to complete in 2 seconds. Either with success or > >failure. > >> > I expect BIOS to have complained before launching grub/lilo. > >> > >> Gregkh, > >> I just realized linux-pci bus scan should ignore devices (print a > >warning) > >> which have BIST set. Want a patch for this? > >> > >> Slight risk some previously "working" device which violates the > >> spec might get ignored...but I hope there aren't too many of those. > > > >Should we wait two seconds before declaring the device dead? To see > >whether > >it will come back? > > > > > Wonders ! > > I was about to give the card it's last rites. I thought well let me > try under the other OS Could you be more specific? Which OS? FreeBSD? :) > I didn't have any drivers for the same, since the demodulator driver > doesn't exist in the other OS also, but the bridge device does have > the driver. > > I plugged the card in, the OS searched for drivers, since i didn't > have any didn't load any.. > So it went under a question mark. > > Looking under Resources, > > It showed the PCI information string like this .. > > PCI\VEN_1822_4E35_00311822_01\4&2E98101C&0&10F0 > > then i thought try with the driver eventhough support for the > demodulator doesn't exist .. > > Downloaded and installed drivers .. > > Lo ..! > > Memory Range: F87FF000 - F87F > IRQ : 17 > > it got assigned a memory region indeed. Excellent. > So, to wrap it up, the device is not dead .. We have something wrong > in the PCI subsystem probably. Hrm maybe but not likely. I'm more inclined to believe PCI subsystem is missing hacks needed for that device and/or BIOS. grant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: wbsd: IRQ handler type mismatch
Robert Hancock wrote: > > It looks like wbsd is being loaded first, which being a nice PnP device > sees that IRQ 6 is available and grabs it. Then the we try to load the > floppy module (which is hard-coded to use IRQ 6) which fails because > wbsd already owns IRQ6 (which is fine, there's no floppy controller > anyway). The mismatch is occurring because wbsd passes IRQF_SHARED > whereas floppy doesn't. I assume one of the two is likely wrong. Should > wbsd really be passing IRQF_SHARED here? This is an LPC device which > uses ISA-style edge triggered interrupts, is it safe to try and share an > interrupt with this chip anyway? > This is all perfectly valid. The wbsd hw and driver can handle sharing the interrupt line, while the floppy cannot. If you want to avoid this, then don't load the floppy driver or assign another irq for wbsd. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.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: [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3
On Mon, Feb 05, 2007 at 10:38:30PM -0800, H. Peter Anvin wrote: > Vivek Goyal wrote: > > > >That time, grub was working fine but lilo had broken on one of Andrew's > >machine. I could not reproduce the problem on my setup and had no clue what > >was the issue. Hence got rid of ELF header from bzImage which was > >non-essential > >stuff for relocatable kernel. But that issue should be fixable. > > > > Either way, though, putting Gujin-specific code in the main kernel > output is a pretty dull thud. > Agreed. Thanks Vivek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Free Linux Driver Development!
On Sun, Feb 04, 2007 at 07:59:47PM +0100, Pierre Ossman wrote: > Hi Greg, > > Although I am a bit of a cynic, I really hope that this endeavor works > the way you hope. > > I'd also like to offer my services to this quest of yours. If you get > any SD, MMC or SDIO requests, feel free to pass them along to me. I am > not a big fan of debug-by-email though, so I'd prefer vendors who either > can provide samples or where the hardware is cheap and freely available > so I can just go out and by one. Great, thanks for letting me know, I've added you to the list. greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Free Linux Driver Development!
On Mon, Feb 05, 2007 at 04:24:21PM +0100, Jiri Slaby wrote: > Greg KH napsal(a): > >On Sun, Feb 04, 2007 at 08:08:32PM +0100, Miguel Ojeda wrote: > >>On 2/4/07, Greg KH <[EMAIL PROTECTED]> wrote: > >>>Just let me know if you are interested in participating, and what types > >>>of devices you wish to write drivers for (USB, PCI, network, etc.) > >>I would like to participate; however, for people who is not at USA > >>(say, Europe), are there fair chances to get samples of devices to > >>work with? > > > >Not all of the companies asking for this work are in the US, so I don't > >see any reason why we should limit our developers to just one country, > >that wouldn't be very fair... > > > >Just let me know what types of devices you are interested in working on. > > Then, I want to be involved too. I'm interested in PCI and network devices. Thanks, I've added you to the list. greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3
Vivek Goyal wrote: That time, grub was working fine but lilo had broken on one of Andrew's machine. I could not reproduce the problem on my setup and had no clue what was the issue. Hence got rid of ELF header from bzImage which was non-essential stuff for relocatable kernel. But that issue should be fixable. Either way, though, putting Gujin-specific code in the main kernel output is a pretty dull thud. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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][5/5] floppy.c: Fix device_create_file() warning
Gene Heskett wrote: On Monday 05 February 2007 18:30, Jesper Juhl wrote: And this is almost OT for this, but I'd like to interject here that in recent history, it has been very very difficult to properly access LSN0 of a floppy. Some formats, such as those laid down by a WD-1773 floppy controller, do indeed use a sector marking of '0' (zero) on all tracks. I thought the sector numbers of floppy discs were software programmable (at formatting time.) I believe different OSes used different offsets, with 1, 2, 3... being the way IBM did it in the PC, but all kinds of variants were used, including things like 0xa0, 0xa1, ... for no apparent reason. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Compressed ia32 ELF file generation for loading by Gujin 1/3
On Mon, Feb 05, 2007 at 10:16:59PM -0800, H. Peter Anvin wrote: > Vivek Goyal wrote: > > > >I don't know much about Gujin, but advantage here seems to be that it has > >capability to load elf files and that's why the attempt to turn kernel > >binary > >into a compressed elf image. Why don't we then simply add an ELF header to > >bzImage and Gujin and any ELF loader including Gujin, should be able to > >load > >it? (As Eric had done in one of the implementations in the past?) Why to > >create the new infrastructure? > > > > Well, Gujin wants additional code too. > > Putting an ELF header on bzImage broke some bootloaders (GRUB, I > believe), so that's not going to happen again. See the relocatable > bzImage thread... > That time, grub was working fine but lilo had broken on one of Andrew's machine. I could not reproduce the problem on my setup and had no clue what was the issue. Hence got rid of ELF header from bzImage which was non-essential stuff for relocatable kernel. But that issue should be fixable. Thanks Vivek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 PCI Cannot allocate resource region 2
On 2/6/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler <[EMAIL PROTECTED]> wrote: > On Mon, Feb 05, 2007 at 09:55:28PM -0700, Grant Grundler wrote: > ... > > > Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- > > > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR+ > > Latency: 0, Cache Line Size 0c > > > BIST is running > > > > BIST is required to complete in 2 seconds. Either with success or failure. > > I expect BIOS to have complained before launching grub/lilo. > > Gregkh, > I just realized linux-pci bus scan should ignore devices (print a warning) > which have BIST set. Want a patch for this? > > Slight risk some previously "working" device which violates the > spec might get ignored...but I hope there aren't too many of those. Should we wait two seconds before declaring the device dead? To see whether it will come back? Wonders ! I was about to give the card it's last rites. I thought well let me try under the other OS I didn't have any drivers for the same, since the demodulator driver doesn't exist in the other OS also, but the bridge device does have the driver. I plugged the card in, the OS searched for drivers, since i didn't have any didn't load any.. So it went under a question mark. Looking under Resources, It showed the PCI information string like this .. PCI\VEN_1822_4E35_00311822_01\4&2E98101C&0&10F0 then i thought try with the driver eventhough support for the demodulator doesn't exist .. Downloaded and installed drivers .. Lo ..! Memory Range: F87FF000 - F87F IRQ : 17 it got assigned a memory region indeed. So, to wrap it up, the device is not dead .. We have something wrong in the PCI subsystem probably. 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: 2.6.20 PCI Cannot allocate resource region 2
On Mon, Feb 05, 2007 at 10:03:31PM -0700, Grant Grundler wrote: > On Mon, Feb 05, 2007 at 09:55:28PM -0700, Grant Grundler wrote: > ... > > > Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > > > Stepping- SERR- FastB2B- > > > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > > > SERR+ > > Latency: 0, Cache Line Size 0c > > > BIST is running > > > > BIST is required to complete in 2 seconds. Either with success or failure. > > I expect BIOS to have complained before launching grub/lilo. > > Gregkh, > I just realized linux-pci bus scan should ignore devices (print a warning) > which have BIST set. Want a patch for this? Yes, that would be good. > Slight risk some previously "working" device which violates the > spec might get ignored...but I hope there aren't too many of those. Odds are there are probably _way_ too many devices, but it can't hurt to at least flag them as a broken card so that they can be fixed in the future... thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, Feb 05, 2007 at 08:09:58PM -0500, Theodore Tso wrote: > On Mon, Feb 05, 2007 at 11:21:34PM +, David Woodhouse wrote: > > But Alan makes a reasonable suggestion -- we could work around this in > > the tools too. > > I wouldn't call it "work around this" in the tools. It's a useful > feature we can add in the tools for developers who aren't men enough > to use "sed/grep" pipelines. :-) > > But I have to agree with Linus here that we should be optimizing the > tools for people who know how to compile the kernel, but who aren't > necessarily familiar with all of the hidden dependencies in the > literally hundreds of config options in the kernel tree. In reality, > you want to make it easy to turn on *or* off any arbitrary config > option, and to understand what you need to do so you can turn an > arbitrary config option on or off. If that means tools enhancements, > so be it. With apt (or presumably with yum), you can happily apt-remove a package that nothing else depends on. If you remove something that other things depend on, you get a list of those things and opportunity to force it (with a -f flag, for instance). If you ask for a package that has other dependencies, it automatically pulls all those things in unless there's a conflict. In which case you can force it again. There's no reason we shouldn't be able to do exactly that with config symbols in Kconfig-land. The only difference is that we've got slightly different semantics for our "depend" keyword. Things which don't have their "depend" requirements met aren't offered as options. Whereas "select" is "automatically pull in dependencies" apt/yum-style. While we're at it, it would also be nice to be able to do: $ kconfig enable ACPI CONFIG_ACPI conflicts with CONFIG_APM $ kconfig enable -F ACPI disabling CONFIG_APM $ kconfig disable SCSI CONFIG_USB_STORAGE depends on CONFIG_SCSI $ kconfig disable -f SCSI disabling USB_STORAGE $ make -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3
Vivek Goyal wrote: I don't know much about Gujin, but advantage here seems to be that it has capability to load elf files and that's why the attempt to turn kernel binary into a compressed elf image. Why don't we then simply add an ELF header to bzImage and Gujin and any ELF loader including Gujin, should be able to load it? (As Eric had done in one of the implementations in the past?) Why to create the new infrastructure? Well, Gujin wants additional code too. Putting an ELF header on bzImage broke some bootloaders (GRUB, I believe), so that's not going to happen again. See the relocatable bzImage thread... -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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][5/5] floppy.c: Fix device_create_file() warning
On Monday 05 February 2007 18:30, Jesper Juhl wrote: And this is almost OT for this, but I'd like to interject here that in recent history, it has been very very difficult to properly access LSN0 of a floppy. Some formats, such as those laid down by a WD-1773 floppy controller, do indeed use a sector marking of '0' (zero) on all tracks. This is akin to an old basic program that had a 'base' statement with an argument of zero or one. We need, for legacy machines where a floppy disk sneakernet is in use, to maintain this "base 0" functionality in an easy to access format. Ditto for sector sizes of 256 and even 128 bytes. >This fixes the warning > warning: ignoring return value of `device_create_file', declared with > attribute warn_unused_result in function `floppy_init'. It does this by > checking the return value and printing a warning message in case of no > success. > > >Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> >--- > > floppy.c |7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > >--- linux-2.6.20/drivers/block/floppy.c.patch4 2007-02-05 > 23:22:26.0 +0100 +++ > linux-2.6.20/drivers/block/floppy.c 2007-02-05 23:32:42.0 +0100 > @@ -4302,7 +4302,12 @@ > if (err) > goto out_flush_work; > >- device_create_file(_device[drive].dev,_attr_cmos); >+ err = device_create_file(_device[drive].dev, >_attr_cmos); >+ if (err) >+ printk(KERN_WARNING "Unable to create sysfs attribute " >+ "file for floppy device: %s\n", >+ floppy_device[drive].name); >+ > /* to be cleaned up... */ > disks[drive]->private_data = (void *)(long)drive; > disks[drive]->queue = floppy_queue; > > > >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" > in the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2007 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, Feb 05, 2007 at 09:17:52PM +, David Woodhouse wrote: > On Mon, 2007-02-05 at 08:58 -0800, Linus Torvalds wrote: > > More importantly, some things that *are* visible probably shouldn't be, or > > should perhaps only be in expert mode (aka "EMBEDDED"). > > I've heard some fairly stupid abuse of the term 'embedded' in my time, > but rarely have I heard people daft enough to abuse it to mean 'expert'. > But yes, that's what we use CONFIG_EMBEDDED for. I'd be happy to turn this into CONFIG_NONSTANDARD or CONFIG_EXPERT, which is how I described it in the Kconfig help texts: menuconfig EMBEDDED bool "Configure standard kernel features (for small systems)" help This option allows certain base kernel options and settings to be disabled or tweaked. This is for specialized environments which can tolerate a "non-standard" kernel. Only use this if you really know what you are doing. A number of current users are indeed bogus. Stuff like: config SUPERH bool default y select EMBEDDED Just because you're using a SuperH board doesn't mean you want to turn off standard features. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [take35 0/10] kevent: Generic event handling mechanism.
On Thu, 2007-02-01 at 13:12 +0300, Evgeniy Polyakov wrote: > Generic event handling mechanism. The patch applied cleanly to 2.6.20 final, but I got a build error: CC kernel/kevent/kevent.o CC kernel/kevent/kevent_user.o CC kernel/kevent/kevent_timer.o CC kernel/kevent/kevent_poll.o make[2]: *** No rule to make target `kernel/kevent/epoll.o', needed by `kernel/kevent/built-in.o'. Stop. make[1]: *** [kernel/kevent] Error 2 make: *** [kernel] Error 2 - DML - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH[RFC] kill sysrq-u (emergency remount r/o)
On Mon, Feb 05, 2007 at 09:40:08PM +0100, Jan Engelhardt wrote: > > On Feb 5 2007 18:32, Christoph Hellwig wrote: > > > >in two recent discussions (file_list_lock scalability and remount r/o > >on suspend) I stumbled over this emergency remount feature. It's not > >actually useful because it tries a potentially dangerous remount > >despite writers still beeing in progress, which we can't get rid. > > The current way is to remount things, and return -EROFS to any process > that attempts to write(). Unless we want to kill processes to get rid of > them [most likely we possibly won't], I am fine with how things are atm. > So, what's the "dangerous" part, actually? The dangerous part is that we change f->f_mode for all open files without regard for whether there might be any writes underway at the time. This isn't *serious* although the results might be a little strange and it might result in a confused return from write(2). More seriously, mark_files_ro() in super.c *only* changes f->f_mode and doesn't deal with the possibility that the file might be mapped read-write. For filesystems that do delayed allocation, I'm not at all convinced that an emergency read-only will result in the filesystem doing anything at all sane, depending on what else the filesystem might do when the filesystem is forced into read-only state. > sysrq+u is helpful. It is like \( sysrq+s && make sure no further writes > go to disk \). I agree it is useful, but if we're going to do it we really should do it right. We should have real revoke() functionality on file descriptors, which revokes all of the mmap()'s (any attempt to write into a previously read/write mmap will cause a SEGV) as well as changing f_mode, and then use that to implement emergency read-only remount. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/9] mm: fix pagecache write deadlocks
On Tue, Feb 06, 2007 at 06:49:05AM +0100, Nick Piggin wrote: > > - If the get_user() doesn't fault, and if we're copying from and to the > > same page, we know that we've locked it, so nobody will be able to unmap > > it while we're copying from it. > > > > Close, but no cigar! This is still vulnerable to Hugh's ab/ba deadlock > > scenario. > > Yes I considered this too. Hard isn't it? BTW, there are two different abba deadlocks. It's all documented in the patch 9/9 description. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/9] mm: fix pagecache write deadlocks
On Mon, Feb 05, 2007 at 09:30:06PM -0800, Andrew Morton wrote:
> On Tue, 6 Feb 2007 05:41:46 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> > >
> > > Not necessarily -- they could read from one part of a page and write to
> > > another. I see this as the biggest data corruption problem.
>
> The kernel gets that sort of thing wrong anyway, and always has, because
> it uses memcpy()-style copying and not memmove()-style.
>
> I can't imagine what sort of application you're envisaging here. The
> problem was only ever observed from userspace by an artificial stress-test
> thing.
No, I'm not talking about writing into a page with memory from the same
page. I'm talking about one process writing to part of a file, and another
reading from that same file (different offset).
If they happen to be covered by the same page, then the reader can see
zeroes.
I'm not envisaging any sort of application, all I know is that there are
several (related) data corruption bugs and I'm trying to fix them (and
fix these deadlock problems without introducing more).
> > And in fact, it is not just transient errors either. This problem can
> > add permanent corruption into the pagecache and onto disk, and it doesn't
> > even require two processes to race.
> >
> > After zeroing out the uncopied part of the page, and attempting to loop
> > again, we might bail out of the loop for any reason before completing the
> > rest of the copy, leaving the pagecache corrupted, which will soon go out
> > to disk.
> >
>
> Only because ->commit_write() went and incorrectly marked parts of the page
> as up-to-date.
>
> Zeroing out the fag end of the copy_from_user() on fault is actually
> incorrect.
Yes, I know.
> What we _should_ do is to bring those uncopyable, non-uptodate parts of the
> page uptodate rather than zeroing them. ->readpage() does that.
>
> So... what happens if we do
>
> lock_page()
> prepare_write()
> if (copy_from_user_atomic()) {
> readpage()
> wait_on_page()
> lock_page()
> }
> commit_write()
> unlock_page()
>
> - If the page has no buffers then it is either fully uptodate or fully
> not uptodate. In the former case, don't call readpage at all. In the
> latter case, readpage() is the correct thing to do.
>
> - If the page had buffers, then readpage() won't touch the uptodate ones
> and will bring the non-uptodate ones up to date from disk.
>
> Some of the data which we copied from userspace may get overwritten
> from backing store, but that's OK.
>
> seems crazy, but it's close. We do have the minor problem that readpage
> went and unlocked the page so we need to relock it. I bet there are holes
> in there.
Yes, I tried doing this as well and there are holes in it. Even supposing
that we add a readpage_dontunlock, there is still the issue of breaking
the filesystem API from nesting readpage inside prepare_write. You also
do need to zero newly allocated blocks, for example.
> Idea #42: after we've locked the pagecache page, do an atomic get_user()
> against the source page(s) before attempting the copy_from_user(). If that
> faults, don't run prepare_write or anything else: drop the page lock and
> try again.
>
> Because
>
> - If the get_user() faults, it might be because the page we're copying
> from and to is the same page, and someone went and unmapped it: deadlock.
>
> - If the get_user() doesn't fault, and if we're copying from and to the
> same page, we know that we've locked it, so nobody will be able to unmap
> it while we're copying from it.
>
> Close, but no cigar! This is still vulnerable to Hugh's ab/ba deadlock
> scenario.
Yes I considered this too. Hard isn't it?
> btw, to fix the writev() performance problem we may need to go off and run
> get_user() against up to 1024 separate user pages before locking the
> pagecache page, which sounds fairly idiotic. Are you doing that in the
> implemetnations which you've been working on? I forget...
No, because in my fix it can do non-atomic usercopies for !uptodate pages.
For uptodate pages, yes there is a possibility that it may do a short copy
and have to retry, but it is probably safe to bet that the source data is
fairly recently accessed in most cases, so a short copy will be unlikely.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 PCI Cannot allocate resource region 2
On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler <[EMAIL PROTECTED]> wrote: > On Mon, Feb 05, 2007 at 09:55:28PM -0700, Grant Grundler wrote: > ... > > > Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > > > Stepping- SERR- FastB2B- > > > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > > > SERR+ > > Latency: 0, Cache Line Size 0c > > > BIST is running > > > > BIST is required to complete in 2 seconds. Either with success or failure. > > I expect BIOS to have complained before launching grub/lilo. > > Gregkh, > I just realized linux-pci bus scan should ignore devices (print a warning) > which have BIST set. Want a patch for this? > > Slight risk some previously "working" device which violates the > spec might get ignored...but I hope there aren't too many of those. Should we wait two seconds before declaring the device dead? To see whether it will come back? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/9] mm: fix pagecache write deadlocks
On Tue, 6 Feb 2007 05:41:46 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 06, 2007 at 03:25:49AM +0100, Nick Piggin wrote:
> > On Sun, Feb 04, 2007 at 10:36:20AM -0800, Andrew Morton wrote:
> > > On Sun, 4 Feb 2007 16:10:51 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> > >
> > > > They're not likely to hit the deadlocks, either. Probability gets more
> > > > likely after my patch to lock the page in the fault path. But
> > > > practially,
> > > > we could live without that too, because the data corruption it fixes is
> > > > very rare as well. Which is exactly what we've been doing quite happily
> > > > for most of 2.6, including all distro kernels (I think).
> > >
> > > Thing is, an application which is relying on the contents of that page is
> > > already unreliable (or really peculiar), because it can get indeterminate
> > > results anyway.
> >
> > Not necessarily -- they could read from one part of a page and write to
> > another. I see this as the biggest data corruption problem.
The kernel gets that sort of thing wrong anyway, and always has, because
it uses memcpy()-style copying and not memmove()-style.
I can't imagine what sort of application you're envisaging here. The
problem was only ever observed from userspace by an artificial stress-test
thing.
> And in fact, it is not just transient errors either. This problem can
> add permanent corruption into the pagecache and onto disk, and it doesn't
> even require two processes to race.
>
> After zeroing out the uncopied part of the page, and attempting to loop
> again, we might bail out of the loop for any reason before completing the
> rest of the copy, leaving the pagecache corrupted, which will soon go out
> to disk.
>
Only because ->commit_write() went and incorrectly marked parts of the page
as up-to-date.
Zeroing out the fag end of the copy_from_user() on fault is actually incorrect.
What we _should_ do is to bring those uncopyable, non-uptodate parts of the
page uptodate rather than zeroing them. ->readpage() does that.
So... what happens if we do
lock_page()
prepare_write()
if (copy_from_user_atomic()) {
readpage()
wait_on_page()
lock_page()
}
commit_write()
unlock_page()
- If the page has no buffers then it is either fully uptodate or fully
not uptodate. In the former case, don't call readpage at all. In the
latter case, readpage() is the correct thing to do.
- If the page had buffers, then readpage() won't touch the uptodate ones
and will bring the non-uptodate ones up to date from disk.
Some of the data which we copied from userspace may get overwritten
from backing store, but that's OK.
seems crazy, but it's close. We do have the minor problem that readpage
went and unlocked the page so we need to relock it. I bet there are holes
in there.
Idea #42: after we've locked the pagecache page, do an atomic get_user()
against the source page(s) before attempting the copy_from_user(). If that
faults, don't run prepare_write or anything else: drop the page lock and
try again.
Because
- If the get_user() faults, it might be because the page we're copying
from and to is the same page, and someone went and unmapped it: deadlock.
- If the get_user() doesn't fault, and if we're copying from and to the
same page, we know that we've locked it, so nobody will be able to unmap
it while we're copying from it.
Close, but no cigar! This is still vulnerable to Hugh's ab/ba deadlock
scenario.
btw, to fix the writev() performance problem we may need to go off and run
get_user() against up to 1024 separate user pages before locking the
pagecache page, which sounds fairly idiotic. Are you doing that in the
implemetnations which you've been working on? I forget...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Compressed ia32 ELF file generation for loading by Gujin 1/3
On Mon, Feb 05, 2007 at 04:37:43PM -0800, H. Peter Anvin wrote: > First of all, if sending attached patches, *MAKE SURE* they're text/plain. > > >diff -uprN -X linux-2.6.20/Documentation/dontdiff > >linux-2.6.20/arch/i386/kernel/setup.c > >linux-2.6.20-gujin/arch/i386/kernel/setup.c > >--- linux-2.6.20/arch/i386/kernel/setup.c 2007-02-04 > >18:44:54.0 + > >+++ linux-2.6.20-gujin/arch/i386/kernel/setup.c 2007-02-05 > >21:27:01.0 + > >@@ -579,6 +579,19 @@ void __init setup_arch(char **cmdline_p) > >strlcpy(command_line, saved_command_line, COMMAND_LINE_SIZE); > >*cmdline_p = command_line; > > > >+ /* > >+* If the command line begin with '/', it is the filename of the > >+* kernel file - like a shell command line. That can be used to > >+* deduce where root was located when the kernel was compiled, > >+* inside a directory of root named /boot, inside a small partition > >+* mounted on a directory of root named /boot or in the root > >+* directory itself. > >+*/ > >+ if (**cmdline_p == '/') > >+ while (**cmdline_p != ' ' && **cmdline_p != '\t' > >+ && **cmdline_p != '\n' && **cmdline_p != '\0') > >+ ++*cmdline_p; > >+ > >max_low_pfn = setup_memory(); > > > >/* > > The standard way to do this is to have a command line argument named > BOOT_IMAGE (as in BOOT_IMAGE=/foo/bar/baz). There is no reason to do > this differently from every other bootloader. > > Why build the real-mode code as part of the kernel binary? If you have > to reference kernel symbols, you can do that with the -R option to ld. > Bundling it into the kernel binary just to then extract it later is > silly at best. > Building real mode code with kernel binary (vmlinux) has got another disadvantage that it breaks using vmlinux for kdump purposes. One compiles the kernel binary to execute from a different address but real mode code/data will continue to be at virtual/physical addr 0 and kexec can not load it as that physical memory is not available at all. Kdump skips the real mode code execution. I don't know much about Gujin, but advantage here seems to be that it has capability to load elf files and that's why the attempt to turn kernel binary into a compressed elf image. Why don't we then simply add an ELF header to bzImage and Gujin and any ELF loader including Gujin, should be able to load it? (As Eric had done in one of the implementations in the past?) Why to create the new infrastructure? Thanks Vivek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bio device too big | kernel BUG at mm/filemap.c:537!
On Monday February 5, [EMAIL PROTECTED] wrote:
> On Mon, 05 Feb 2007 20:08:39 -0800 "Kai" <[EMAIL PROTECTED]> wrote:
>
> You hit two bugs. It seems that raid5 is submitting BIOs which are larger
> than the device can accept. In response someone (probably the block layer)
> caused a page to come unlocked twice, possibly by running bi_end_io twice
> against the same BIO.
At least two bugs... there should be a prize for that :-)
Raid5 was definitely submitting a bio that was too big for the device,
and then when it got an error and went to try it the old-fashioned way
(lots of little Bi's through the stripe-cache) it messed up.
Whether that is what trigger the double-unlock I'm not yet sure.
This patch should fix the worst of the offences, but I'd like to
experiment and think a bit more before I submit it to stable.
And probably test it too - as yet I have only compile and brain
tested.
What is the chunk-size on your raid5? Presumably at least 128k ?
NeilBrown
### Diffstat output
./drivers/md/raid5.c | 40 ++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff .prev/drivers/md/raid5.c ./drivers/md/raid5.c
--- .prev/drivers/md/raid5.c2007-02-06 16:16:39.0 +1100
+++ ./drivers/md/raid5.c2007-02-06 16:20:57.0 +1100
@@ -2669,6 +2669,27 @@ static int raid5_align_endio(struct bio
return 0;
}
+static int bio_fits_rdev(struct bio *bi)
+{
+ request_queue_t *q = bdev_get_queue(bi->bi_bdev);
+
+ if ((bi->bi_size>>9) > q->max_sectors)
+ return 0;
+ blk_recount_segments(q, bi);
+ if (bi->bi_phys_segments > q->max_phys_segments ||
+ bi->bi_hw_segments > q->max_hw_segments)
+ return 0;
+
+ if (q->merge_bvec_fn)
+ /* it's too hard to apply the merge_bvec_fn at this stage,
+* just just give up
+*/
+ return 0;
+
+ return 1;
+}
+
+
static int chunk_aligned_read(request_queue_t *q, struct bio * raid_bio)
{
mddev_t *mddev = q->queuedata;
@@ -2715,6 +2736,13 @@ static int chunk_aligned_read(request_qu
align_bi->bi_flags &= ~(1 << BIO_SEG_VALID);
align_bi->bi_sector += rdev->data_offset;
+ if (!bio_fits_rdev(align_bi)) {
+ /* too big in some way */
+ bio_put(align_bi);
+ rdev_dec_pending(rdev, mddev);
+ return 0;
+ }
+
spin_lock_irq(>device_lock);
wait_event_lock_irq(conf->wait_for_stripe,
conf->quiesce == 0,
@@ -3107,7 +3135,9 @@ static int retry_aligned_read(raid5_con
last_sector = raid_bio->bi_sector + (raid_bio->bi_size>>9);
for (; logical_sector < last_sector;
-logical_sector += STRIPE_SECTORS, scnt++) {
+logical_sector += STRIPE_SECTORS,
+sector += STRIPE_SECTORS,
+scnt++) {
if (scnt < raid_bio->bi_hw_segments)
/* already done this stripe */
@@ -3123,7 +3153,13 @@ static int retry_aligned_read(raid5_con
}
set_bit(R5_ReadError, >dev[dd_idx].flags);
- add_stripe_bio(sh, raid_bio, dd_idx, 0);
+ if (!add_stripe_bio(sh, raid_bio, dd_idx, 0)) {
+ release_stripe(sh);
+ raid_bio->bi_hw_segments = scnt;
+ conf->retry_read_aligned = raid_bio;
+ return handled;
+ }
+
handle_stripe(sh, NULL);
release_stripe(sh);
handled++;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/11] VMI / Paravirt bugfixes for 2.6.21
On Tue, 06 Feb 2007 16:11:16 +1100 Rusty Russell <[EMAIL PROTECTED]> wrote: > > Patches welcome (but note that I've started a new lguest patch repo at > http://lguest.kernel.org/patches). Presumably you mean lguest.ozlabs.org ... -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 PCI Cannot allocate resource region 2
On 2/6/07, Grant Grundler <[EMAIL PROTECTED]> wrote: On Mon, Feb 05, 2007 at 05:09:01AM +0400, Manu Abraham wrote: > Hi, > > I get this error on booting up 2.6.20 (Similar error on 2.6.17.7 also, > the message is slightly different in 2.6.17.7) > > PCI Cannot allocate resource region 2 of device :02:0a.0 > PCI Error while updating region 000:02:0a.0/5 (f3e4 != 0200) > PCI Error while updating region 000:02:0a.0/5 (high != 4e351) ... > The last 2 devices are Rev 1 chips, whereas the one which is acting a > bit strange is a newer version from the same vendor. > Any ideas as to why it could not allocate the region ? Looks like the HW is broken. ah, was thinking about this. :-) This bridge: > 00:1e.0 0604: 8086:244e (rev c2) > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-Latency: 0 > Bus: primary=00, secondary=02, subordinate=02, sec-latency=64 > I/O behind bridge: d000-dfff > Memory behind bridge: f3e0-f7ef > Prefetchable memory behind bridge: e9b0-e9bf > Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort-BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B- will only route 0xf3e... to 0xf7efff... The attempt to assign f3e4 is just trying to put a valid value in the BAR. So I think linux is _trying_ to DTRT. > 02:0a.0 4e35: 1800:4e35 (rev 08) (prog-if 18) > Subsystem: 002c:c200 > Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR+Latency: 0, Cache Line Size 0c > BIST is running BIST is required to complete in 2 seconds. Either with success or failure. I expect BIOS to have complained before launching grub/lilo. BIOS didn't say anything at all. You might look for that on the next reboot and if possible use a serial console to log all output or look for BIOS warnings or logged "events". But all bets are off regarding programming the device as long as BIST is running. The only PCI requirement is the device not interfere with "operation of other devices on the bus". BIST is supposed to terminate before, say the OS kernel is loaded ? or does it mean that it can keep running still ? > Region 0: Memory at f7ee (32-bit, non-prefetchable) [disabled] [size=4K] > Region 2: Memory at e9b0 (32-bit, prefetchable) [disabled] [size=4K] > Region 3: Memory at (32-bit, prefetchable) [disabled] > Region 4: Memory at (32-bit, non-prefetchable) [disabled] > Region 5: Memory at (64-bit, non-prefetchable) [disabled] This is obviously garbage. 64-bit registers can only be represented with two consecutive "BAR" and region 5 is the last one. There is no way this can be a 64-bit BAR. Generally, 64-bit BARs start on an "even" numbered BAR (but I've forgotten again if that's just convention or a requirement) was just wondering how it could be a 64 bit device. hth, grant Thanks a lot for the valuable info. I had not ruled out the option that it could be broken. I will try the device in the other OS also, to confirm this. Will post the status after that. But most probably as you said, could be broken. Thanks, 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: [PATCH 0/11] VMI / Paravirt bugfixes for 2.6.21
On Mon, 2007-02-05 at 20:54 -0800, Zachary Amsden wrote: > Rusty Russell wrote: > > Indeed, I'm expecting to push lguest this week, and this code will > > effect me, so I'd like to see this in a -mm soon... > > Yes, I took a look at the lguest changes today and I think these won't > generate conflicts, just make stuff easier for you ;) Course you've now > got a couple new paravirt-ops to support, but the native ones are fine > for temporary use. Implementing stolen time is something I'd like to do, since it'd be a nice self-contained example the expectations. Patches welcome (but note that I've started a new lguest patch repo at http://lguest.kernel.org/patches). Thanks! Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
How far should BLKROSET/set_device_ro() go?
While looking at another bug a while ago, I noticed that in 2.6 at least, set_device_ro() sets the policy on the hd_struct to mark it readonly, but it appears that IO is only really blocked from userspace, via generic_write_checks(). There are bdev_read_only() checks in other places, but nothing in a common spot to reject all possible IO. Should we have something in generic_make_request() to reject ALL IO on a readonly bdev, or is that further than the policy is supposed to go? Or is it up to each location that might possibly issue that IO to check it and be well-behaved? The motivation for this investigation was ext3 happily doing orphan inode recovery on read-only lvm snapshot Thanks, -Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 PCI Cannot allocate resource region 2
On Mon, Feb 05, 2007 at 09:55:28PM -0700, Grant Grundler wrote: ... > > Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > > Stepping- SERR- FastB2B- > > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > > SERR+ > Latency: 0, Cache Line Size 0c > > BIST is running > > BIST is required to complete in 2 seconds. Either with success or failure. > I expect BIOS to have complained before launching grub/lilo. Gregkh, I just realized linux-pci bus scan should ignore devices (print a warning) which have BIST set. Want a patch for this? Slight risk some previously "working" device which violates the spec might get ignored...but I hope there aren't too many of those. grant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 PCI Cannot allocate resource region 2
On Mon, Feb 05, 2007 at 05:09:01AM +0400, Manu Abraham wrote: > Hi, > > I get this error on booting up 2.6.20 (Similar error on 2.6.17.7 also, > the message is slightly different in 2.6.17.7) > > PCI Cannot allocate resource region 2 of device :02:0a.0 > PCI Error while updating region 000:02:0a.0/5 (f3e4 != 0200) > PCI Error while updating region 000:02:0a.0/5 (high != 4e351) ... > The last 2 devices are Rev 1 chips, whereas the one which is acting a > bit strange is a newer version from the same vendor. > Any ideas as to why it could not allocate the region ? Looks like the HW is broken. This bridge: > 00:1e.0 0604: 8086:244e (rev c2) > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR+ FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-Latency: 0 > Bus: primary=00, secondary=02, subordinate=02, sec-latency=64 > I/O behind bridge: d000-dfff > Memory behind bridge: f3e0-f7ef > Prefetchable memory behind bridge: e9b0-e9bf > Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- >BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B- will only route 0xf3e... to 0xf7efff... The attempt to assign f3e4 is just trying to put a valid value in the BAR. So I think linux is _trying_ to DTRT. > 02:0a.0 4e35: 1800:4e35 (rev 08) (prog-if 18) > Subsystem: 002c:c200 > Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > SERR+Latency: 0, Cache Line Size 0c > BIST is running BIST is required to complete in 2 seconds. Either with success or failure. I expect BIOS to have complained before launching grub/lilo. You might look for that on the next reboot and if possible use a serial console to log all output or look for BIOS warnings or logged "events". But all bets are off regarding programming the device as long as BIST is running. The only PCI requirement is the device not interfere with "operation of other devices on the bus". > Region 0: Memory at f7ee (32-bit, non-prefetchable) [disabled] > [size=4K] > Region 2: Memory at e9b0 (32-bit, prefetchable) [disabled] [size=4K] > Region 3: Memory at (32-bit, prefetchable) [disabled] > Region 4: Memory at (32-bit, non-prefetchable) [disabled] > Region 5: Memory at (64-bit, non-prefetchable) > [disabled] This is obviously garbage. 64-bit registers can only be represented with two consecutive "BAR" and region 5 is the last one. There is no way this can be a 64-bit BAR. Generally, 64-bit BARs start on an "even" numbered BAR (but I've forgotten again if that's just convention or a requirement) hth, grant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/11] VMI / Paravirt bugfixes for 2.6.21
Rusty Russell wrote: On Mon, 2007-02-05 at 19:52 -0800, Zachary Amsden wrote: A bunch of VMI and paravirt-ops bugfixes for upstream. Also, fix the timer code to work for 2.6.21, which had a number of changes. These should mostly be non-controversial and beneficial to all the paravirt-ops work. Indeed, I'm expecting to push lguest this week, and this code will effect me, so I'd like to see this in a -mm soon... Thanks! Rusty. Yes, I took a look at the lguest changes today and I think these won't generate conflicts, just make stuff easier for you ;) Course you've now got a couple new paravirt-ops to support, but the native ones are fine for temporary use. Cheers, Zach - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/9] mm: fix pagecache write deadlocks
On Tue, Feb 06, 2007 at 03:25:49AM +0100, Nick Piggin wrote: > On Sun, Feb 04, 2007 at 10:36:20AM -0800, Andrew Morton wrote: > > On Sun, 4 Feb 2007 16:10:51 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote: > > > > > They're not likely to hit the deadlocks, either. Probability gets more > > > likely after my patch to lock the page in the fault path. But practially, > > > we could live without that too, because the data corruption it fixes is > > > very rare as well. Which is exactly what we've been doing quite happily > > > for most of 2.6, including all distro kernels (I think). > > > > Thing is, an application which is relying on the contents of that page is > > already unreliable (or really peculiar), because it can get indeterminate > > results anyway. > > Not necessarily -- they could read from one part of a page and write to > another. I see this as the biggest data corruption problem. And in fact, it is not just transient errors either. This problem can add permanent corruption into the pagecache and onto disk, and it doesn't even require two processes to race. After zeroing out the uncopied part of the page, and attempting to loop again, we might bail out of the loop for any reason before completing the rest of the copy, leaving the pagecache corrupted, which will soon go out to disk. Nick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bio device too big | kernel BUG at mm/filemap.c:537!
On Mon, 05 Feb 2007 20:08:39 -0800 "Kai" <[EMAIL PROTECTED]> wrote: > I booted up the new kernel version, 2.6.20; I pretty much copied over my > .config that worked in 2.6.19.2, that has worked correctly since that > version came out... I looked through the menuconfig to see if any new > options had been added, but I'm pretty sure I didn't change anything, > and got this error message shortly after booting: > > bio too big device hdg1 (184 > 128) > [ cut here ] > kernel BUG at mm/filemap.c:537! > invalid opcode: [#1] > Modules linked in: iptable_filter ip_tables x_tables snd_seq_dummy > snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss > snd_mixer_oss nvidia_agp agpgart > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00010246 (2.6.20 #1) > EIP is at unlock_page+0xd/0x22 > eax: ebx: c1714a20 ecx: edx: c1714a20 > esi: c199c45c edi: 0001 ebp: 1422bf48 esp: f7c8df18 > ds: 007b es: 007b ss: 0068 > Process md0_raid5 (pid: 901, ti=f7c8c000 task=f7c50050 task.ti=f7c8c000) > Stack: c1997920 c016363c c1bca460 c1997920 c1bca460 c0315af2 f7c8df4c > f7c8df50 >c1bca460 1422bf48 0a115f48 0002 >c1bca460 >0002 f7faf600 fffc c0315b92 f7ee6c20 7fff f7c8df8c >c031f877 > Call Trace: > [] mpage_end_io_read+0x4c/0x5e > [] retry_aligned_read+0x108/0x13a > [] raid5d+0x6e/0xcc > [] md_thread+0xdc/0xf2 > [] autoremove_wake_function+0x0/0x33 > [] __wake_up_common+0x35/0x4f > [] autoremove_wake_function+0x0/0x33 > [] md_thread+0x0/0xf2 > [] kthread+0x72/0x97 > [] kthread+0x0/0x97 > [] kernel_thread_helper+0x7/0x10 > === > Code: 73 ff ff ff b9 a4 d6 12 c0 89 fa c7 04 24 02 00 00 00 e8 87 77 27 > 00 83 c4 44 5b 5e 5f c3 53 89 c3 0f ba 30 00 19 c0 85 c0 75 04 <0f> 0b > eb fe 89 d8 e8 41 ff ff ff 89$ > EIP: [] unlock_page+0xd/0x22 SS:ESP 0068:f7c8df18 > > The devices it seems to be complaining about are /dev/hdg and /dev/hde, > which are physically attached to the PCI0680 Ultra ATA-133 Host > Controller listed in lspci.txt. > Both drives are 160 GB Western Digital HDDs... don't remember the > precise model, but I can find out if necessary. > You hit two bugs. It seems that raid5 is submitting BIOs which are larger than the device can accept. In response someone (probably the block layer) caused a page to come unlocked twice, possibly by running bi_end_io twice against the same BIO. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/11] VMI / Paravirt bugfixes for 2.6.21
On Mon, 2007-02-05 at 19:52 -0800, Zachary Amsden wrote: > A bunch of VMI and paravirt-ops bugfixes for upstream. Also, fix the > timer code to work for 2.6.21, which had a number of changes. > > These should mostly be non-controversial and beneficial to all the > paravirt-ops work. Indeed, I'm expecting to push lguest this week, and this code will effect me, so I'd like to see this in a -mm soon... Thanks! Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Kwatch: kernel watchpoints using CPU debug registers
Sorry I've been slow in giving you feedback on kwatch. > I'll be happy to move this over to the utrace setting, once it is merged. > Do you think it would be better to include the current version of kwatch > now or to wait for utrace? > > Roland, is there a schedule for when you plan to get utrace into -mm? Since you've asked, I'll mention that I've been discussing this with Andrew lately and we plan to work on merging it into -mm as soon as we can manage. The kwatch implementation is pretty much orthogonal to the utrace patch as it is so far. As you've noted, it doesn't change the nature of the setting of the debug registers; it only moves around the existing code for setting them in raw form. Hence it doesn't much matter which order the work is merged at this stage. There's no reason to withhold kwatch waiting for utrace. I do have a problem with kwatch, however. The existing user ABI includes setting all of the debug registers, and this interface has never before expressed a situation where you can set some but not all of them. Having ptrace suddenly fail with EBUSY when it never did before is not OK. No well-behaved kernel-mode tracing/debugging facility should perturb the user experience in this way. It is certainly understandable that one will sometimes want to do invasive kernel-mode debugging and on special occasions choose to be ill-behaved in this way (you might know your userland work load doesn't include running gdb with watchpoints). But kwatch as it stands does not even make it possible to write a well-behaved facility. I am all in favor of a facility to manage shared use of the debug registers, such as your debugreg.h additions. I just think it needs to be a little more flexible. An unobtrusive kernel facility has to get out of the way when user-mode decides to use all its debug registers. It's not immediately important what it's going to about it when contention arises, but there has to be a way for the user-mode facilities to say they need to allocate debugregs with priority and evict other squatters. So, something like code allocating a debugreg can supply a callback that's made when its allocation has to taken by something with higher priority. Even after utrace, there will always be the possibility of a traditional uncoordinated user of the raw debug registers, if nothing else ptrace compatibility will always be there for old users. So anything new and fancy needs to be prepared to back out of the way gracefully. In the case of kwatch, it can just have a handler function given by the caller to start with. It's OK if individual callers can specially declare "I am not well-behaved" and eat debugregs so that well-behaved high-priority users like ptrace just have to lose (breaking compatibility). But no well-behaved caller of kwatch will do that. As a later improvement, kwatch could try a thing or two to stave off giving up and telling its caller the watchpoint couldn't stay for the current task. For example, if a watchpoint is in kernel memory, you could switch in your debugreg settings on entering the kernel and restore the user watchpoints before returning to user mode. Then you'd need to make get_user et al somehow observe the user-mode watchpoints. But it could be investigated if the need arises. Note that you can already silently do something simple like juggling your kwatch debugreg assignments around if the higher-priority consumer evicting you has left some other debugregs unused. I certainly intend for later features based on utrace to include higher-level treatment of watchpoints so that user debugging facilities can also become responsive to debugreg allocation pressure. (Eventually, the user facilities might have easier ways of falling back to other methods and getting out of the way of kernel debugreg consumers, than can be done for the kernel-mode-tracing facilities.) To that end, I'd like to see a clear and robust interface for debugreg sharing, below the level of kwatch. I'd also like to see a thin layer on that giving a machine-independent kernel source API for talking about watchpoints, which you pretty much have rolled into the kwatch interface now. But these are further refinements, not barriers to including kwatch. Also, an unrelated minor point. I think it's error-prone to have an integer argument to unregister_kwatch. I think it makes most sense to have the caller provide the space and call register/unregister with a pointer, in the style of kprobes. Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/11] Sched clock paravirt op
Zachary Amsden wrote:
#include "mach_timer.h"
@@ -102,9 +103,6 @@ unsigned long long sched_clock(void)
{
unsigned long long this_offset;
- if (unlikely(custom_sched_clock))
- return (*custom_sched_clock)();
-
/*
* Fall back to jiffies if there's no TSC available:
*/
@@ -113,13 +111,13 @@ unsigned long long sched_clock(void)
return (jiffies_64 - INITIAL_JIFFIES) * (10 / HZ);
/* read the Time Stamp Counter: */
- rdtscll(this_offset);
+ get_scheduled_cycles(this_offset);
/* return the value in ns */
return cycles_2_ns(this_offset);
}
I missed a title / signed-off on this guy.
Internally, sched_clock runs in units of nanoseconds, not CPU cycles.
This was wrong in my previous patch. Fix it so everyone can use the
same cycles_2_ns code in tsc.c.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/11] Vmi timer race
Because timer code moves around, and we might eventually move our init to a
late_time_init hook, save and restore IRQs around this code because it is
definitely not interrupt safe.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r dd4d4324a5b3 arch/i386/kernel/vmitime.c
--- a/arch/i386/kernel/vmitime.cThu Feb 01 23:53:06 2007 -0800
+++ b/arch/i386/kernel/vmitime.cFri Feb 02 00:03:05 2007 -0800
@@ -178,7 +178,9 @@ void __init vmi_time_init(void)
void __init vmi_time_init(void)
{
unsigned long long cycles_per_sec, cycles_per_msec;
-
+ unsigned long flags;
+
+ local_irq_save(flags);
setup_irq(0, _timer_irq);
#ifdef CONFIG_X86_LOCAL_APIC
set_intr_gate(LOCAL_TIMER_VECTOR, apic_vmi_timer_interrupt);
@@ -222,6 +224,8 @@ void __init vmi_time_init(void)
VMI_ALARM_WIRED_IRQ0 | VMI_ALARM_IS_PERIODIC |
VMI_CYCLES_AVAILABLE,
per_cpu(process_times_cycles_accounted_cpu, 0) +
cycles_per_alarm,
cycles_per_alarm);
+
+ local_irq_restore(flags);
}
#ifdef CONFIG_X86_LOCAL_APIC
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.19.2, 2.6.20 Kernel oops
On Mon, 5 Feb 2007 12:08:29 +0100 Lukas Hejtmanek <[EMAIL PROTECTED]> wrote: > Hello, > > playing with my java application that sends data into network I got the > following oops. I got also similar oops in interrupt handler but such > situation results in kernel panic so I'm unable to provide exact oops, > however, it also crashes in page_to_pfn. > > kernel: [ 222.002013] CPU 0 > kernel: [ 222.002014] Modules linked in: container fan button ac thermal > processor myri10ge megaraid_sas serio_raw psmouse evdev > kernel: [ 222.002020] Pid: 3234, comm: java Not tainted 2.6.20 #1 > kernel: [ 222.002021] RIP: 0010:[page_to_pfn+0/64] [page_to_pfn+0/64] > page_to_pfn+0x0/0x40 > kernel: [ 222.002024] RSP: 0018:81024ebf9ac0 EFLAGS: 00010246 > kernel: [ 222.002026] RAX: 8102574213c0 RBX: 810256f07800 RCX: > 81022e5600c0 > kernel: [ 222.002027] RDX: 0740 RSI: RDI: > > kernel: [ 222.002028] RBP: 0740 R08: 0002 R09: > 8102536b9a40 > kernel: [ 222.002030] R10: 0007 R11: 80259650 R12: > > kernel: [ 222.002031] R13: 810257422460 R14: 0002 R15: > 81022e5600c0 > kernel: [ 222.002033] FS: 41061950(0063) GS:80649000() > knlGS: > kernel: [ 222.002034] CS: 0010 DS: ES: CR0: 8005003b > kernel: [ 222.002036] CR2: CR3: 000251dbb000 CR4: > 06e0 > kernel: [ 222.002037] Process java (pid: 3234, threadinfo 81024ebf8000, > task 81024ebdc7a0) > kernel: [ 222.002038] Stack: 804c4f77 810257422400 > 0002 81024ebf9f28 > kernel: [ 222.002042] f240 0740 810257422460 > 0002 > kernel: [ 222.002044] 804c3ba5 0010 81022e5600c0 > 8102536b9a40 > kernel: [ 222.002046] Call Trace: > kernel: [ 222.002051] [ioat_dma_memcpy_buf_to_pg+71/224] > ioat_dma_memcpy_buf_to_pg+0x47/0xe0 > kernel: [ 222.002053] [dma_memcpy_to_iovec+613/768] > dma_memcpy_to_iovec+0x265/0x300 > kernel: [ 222.002057] [dma_skb_copy_datagram_iovec+115/656] > dma_skb_copy_datagram_iovec+0x73/0x290 > kernel: [ 222.002060] [tcp_recvmsg+1764/3296] tcp_recvmsg+0x6e4/0xce0 > kernel: [ 222.002063] [sock_common_recvmsg+48/80] > sock_common_recvmsg+0x30/0x50 > kernel: [ 222.002065] [sock_recvmsg+281/352] sock_recvmsg+0x119/0x160 > kernel: [ 222.002069] [autoremove_wake_function+0/48] > autoremove_wake_function+0x0/0x30 > kernel: [ 222.002071] [autoremove_wake_function+0/48] > autoremove_wake_function+0x0/0x30 > kernel: [ 222.002073] [__handle_mm_fault+1741/2896] > __handle_mm_fault+0x6cd/0xb50 > kernel: [ 222.002076] [sys_recvfrom+250/400] sys_recvfrom+0xfa/0x190 > kernel: [ 222.002078] [tty_ldisc_deref+100/128] tty_ldisc_deref+0x64/0x80 > kernel: [ 222.002080] [tty_write+540/592] tty_write+0x21c/0x250 > kernel: [ 222.002083] [system_call+126/131] system_call+0x7e/0x83 > kernel: [ 222.002084] > kernel: [ 222.002085] > kernel: [ 222.002085] Code: 48 8b 07 48 c1 e8 3a 48 8b 14 c5 80 b8 65 80 48 > b8 b7 6d db > kernel: [ 222.002092] RSP > Is that the whole oops message? There should have been a few interesting lines preceding the above. We went splat in ioat_dma_memcpy_buf_to_pg->pci_map_page->lowmem_page_address->page_to_pfn. I'm not sure how you can oops on the first instruction of page_to_pfn(). Maybe a trashed stack pointer? Seeing the first part of the oops message will help. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/11] Paravirt debug defaults off
Deliberate register clobber around performance critical inline code is great for testing, bad to leave on by default. Many people ship with DEBUG_KERNEL turned on, so stop making DEBUG_PARAVIRT default on. Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]> diff -r 3a8033f42ecf arch/i386/Kconfig.debug --- a/arch/i386/Kconfig.debug Fri Feb 02 17:33:35 2007 -0800 +++ b/arch/i386/Kconfig.debug Fri Feb 02 17:48:45 2007 -0800 @@ -89,7 +89,7 @@ config DOUBLEFAULT config DEBUG_PARAVIRT bool "Enable some paravirtualization debugging" - default y + default n depends on PARAVIRT && DEBUG_KERNEL help Currently deliberately clobbers regs which are allowed to be - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/11] Vmi fix highpte
Provide a PT map hook for HIGHPTE kernels to designate where they are mapping
page tables. This information is required so the physical address of PTE
updates can be determined; otherwise, the mm layer would have to carry the
physical address all the way to each PTE modification callsite, which is
even more hideous that the macros required to provide the proper hooks.
So lets not mess up arch neutral code to achieve this, but keep the horror
in an #ifdef HIGHPTE in include/asm-i386/pgtable.h. I had to use macros
here because some types are not yet defined in all the include paths for
this header.
If anyone can find a cleaner way to do this, please implement it and I will
mail you a beer.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r 08dce48f1a50 arch/i386/kernel/paravirt.c
--- a/arch/i386/kernel/paravirt.c Fri Feb 02 16:31:59 2007 -0800
+++ b/arch/i386/kernel/paravirt.c Fri Feb 02 17:19:34 2007 -0800
@@ -556,6 +556,8 @@ struct paravirt_ops paravirt_ops = {
.flush_tlb_kernel = native_flush_tlb_global,
.flush_tlb_single = native_flush_tlb_single,
+ .map_pt_hook = (void *)native_nop,
+
.alloc_pt = (void *)native_nop,
.alloc_pd = (void *)native_nop,
.alloc_pd_clone = (void *)native_nop,
diff -r 08dce48f1a50 arch/i386/kernel/vmi.c
--- a/arch/i386/kernel/vmi.cFri Feb 02 16:31:59 2007 -0800
+++ b/arch/i386/kernel/vmi.cFri Feb 02 17:28:53 2007 -0800
@@ -372,6 +372,26 @@ static void vmi_check_page_type(u32 pfn,
#define vmi_check_page_type(p,t) do { } while (0)
#endif
+static void vmi_map_pt_hook(u32 slot, pte_t *va, u32 pfn)
+{
+ /*
+* Internally, the VMI ROM must map virtual addresses to physical
+* addresses for processing MMU updates. By the time MMU updates
+* are issued, this information is typically already lost.
+* Fortunately, the VMI provides a cache of mapping slots for active
+* page tables.
+*
+* We use slot zero for the linear mapping of physical memory, thus
+* bump the slot numbers by one.
+*
+* HIGHMEM_PTE kernels use two additional slots for the mapped PTE and
+* nested PTE.
+*
+* args: SLOT VA COUNT PFN
+*/
+ vmi_ops.set_linear_mapping(slot+1, (u32)va, 1, pfn);
+}
+
static void vmi_allocate_pt(u32 pfn)
{
vmi_set_page_type(pfn, VMI_PAGE_L1);
@@ -820,6 +840,7 @@ static int __init activate_vmi(void)
vmi_ops.allocate_page = vmi_get_function(VMI_CALL_AllocatePage);
vmi_ops.release_page = vmi_get_function(VMI_CALL_ReleasePage);
+ paravirt_ops.map_pt_hook = vmi_map_pt_hook;
paravirt_ops.alloc_pt = vmi_allocate_pt;
paravirt_ops.alloc_pd = vmi_allocate_pd;
paravirt_ops.alloc_pd_clone = vmi_allocate_pd_clone;
diff -r 08dce48f1a50 include/asm-i386/paravirt.h
--- a/include/asm-i386/paravirt.h Fri Feb 02 16:31:59 2007 -0800
+++ b/include/asm-i386/paravirt.h Fri Feb 02 17:17:26 2007 -0800
@@ -131,6 +131,8 @@ struct paravirt_ops
void (fastcall *flush_tlb_kernel)(void);
void (fastcall *flush_tlb_single)(u32 addr);
+ void (fastcall *map_pt_hook)(u32 slot, pte_t *va, u32 pfn);
+
void (fastcall *alloc_pt)(u32 pfn);
void (fastcall *alloc_pd)(u32 pfn);
void (fastcall *alloc_pd_clone)(u32 pfn, u32 clonepfn, u32 start, u32
count);
@@ -354,6 +356,8 @@ static inline void startup_ipi_hook(int
#define __flush_tlb_global() paravirt_ops.flush_tlb_kernel()
#define __flush_tlb_single(addr) paravirt_ops.flush_tlb_single(addr)
+#define paravirt_map_pt_hook(slot, va, pfn) paravirt_ops.map_pt_hook(slot, va,
pfn)
+
#define paravirt_alloc_pt(pfn) paravirt_ops.alloc_pt(pfn)
#define paravirt_release_pt(pfn) paravirt_ops.release_pt(pfn)
diff -r 08dce48f1a50 include/asm-i386/pgtable.h
--- a/include/asm-i386/pgtable.hFri Feb 02 16:31:59 2007 -0800
+++ b/include/asm-i386/pgtable.hFri Feb 02 17:33:24 2007 -0800
@@ -263,6 +263,7 @@ static inline pte_t pte_mkhuge(pte_t pte
*/
#define pte_update(mm, addr, ptep) do { } while (0)
#define pte_update_defer(mm, addr, ptep) do { } while (0)
+#define paravirt_map_pt_hook(slot, va, pfn)do { } while (0)
#endif
/*
@@ -469,10 +470,24 @@ extern pte_t *lookup_address(unsigned lo
#endif
#if defined(CONFIG_HIGHPTE)
-#define pte_offset_map(dir, address) \
- ((pte_t *)kmap_atomic(pmd_page(*(dir)),KM_PTE0) + pte_index(address))
-#define pte_offset_map_nested(dir, address) \
- ((pte_t *)kmap_atomic(pmd_page(*(dir)),KM_PTE1) + pte_index(address))
+#define pte_offset_map(dir, address) \
+({ \
+ pte_t *__ptep; \
+ unsigned pfn = pmd_val(*(dir)) >> PAGE_SHIFT; \
+ __ptep = (pte_t *)kmap_atomic(pfn_to_page(pfn),KM_PTE0);\
+
[PATCH 8/11] Add a CPU KHZ calibration function to paravirt-ops
Provide a paravirtualized way to get the CPU clock frequency; this allows much
of the code in tsc.c to be shared between all paravirt implementations.
Subject: Add a CPU KHZ calibration function to paravirt-ops
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r a08f195aa92a arch/i386/kernel/vmi.c
--- a/arch/i386/kernel/vmi.cFri Feb 02 16:30:59 2007 -0800
+++ b/arch/i386/kernel/vmi.cFri Feb 02 16:31:45 2007 -0800
@@ -881,6 +881,7 @@ static int __init activate_vmi(void)
paravirt_ops.setup_secondary_clock =
vmi_timer_setup_secondary_alarm;
#endif
paravirt_ops.get_scheduled_cycles = vmi_get_sched_cycles;
+ paravirt_ops.get_cpu_khz = vmi_cpu_khz;
}
/*
diff -r a08f195aa92a arch/i386/kernel/vmitime.c
--- a/arch/i386/kernel/vmitime.cFri Feb 02 16:30:59 2007 -0800
+++ b/arch/i386/kernel/vmitime.cFri Feb 02 16:30:59 2007 -0800
@@ -175,6 +175,15 @@ unsigned long long vmi_get_sched_cycles(
return read_available_cycles();
}
+unsigned long vmi_cpu_khz(void)
+{
+ unsigned long long khz;
+
+ khz = vmi_timer_ops.get_cycle_frequency();
+ (void)do_div(khz, 1000);
+ return khz;
+}
+
void __init vmi_time_init(void)
{
unsigned long long cycles_per_sec, cycles_per_msec;
@@ -204,7 +213,6 @@ void __init vmi_time_init(void)
(void)do_div(cycles_per_alarm, alarm_hz);
cycles_per_msec = cycles_per_sec;
(void)do_div(cycles_per_msec, 1000);
- cpu_khz = cycles_per_msec;
printk(KERN_WARNING "VMI timer cycles/sec = %llu ; cycles/jiffy = %llu
;"
"cycles/alarm = %llu\n", cycles_per_sec, cycles_per_jiffy,
diff -r a08f195aa92a include/asm-i386/vmi_time.h
--- a/include/asm-i386/vmi_time.h Fri Feb 02 16:30:59 2007 -0800
+++ b/include/asm-i386/vmi_time.h Fri Feb 02 16:31:24 2007 -0800
@@ -50,6 +50,7 @@ extern unsigned long vmi_get_wallclock(v
extern unsigned long vmi_get_wallclock(void);
extern int vmi_set_wallclock(unsigned long now);
extern unsigned long long vmi_get_sched_cycles(void);
+extern unsigned long vmi_cpu_khz(void);
#ifdef CONFIG_X86_LOCAL_APIC
extern void __init vmi_timer_setup_boot_alarm(void);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 9/11] Panic delay fix
Failure to use real-time delay here causes the keyboard to become demonically possessed in the event of a kernel crash, with wildly blinking lights and unpredictable behavior. This has resulted in several injuries. Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]> diff -r 10fac6d484e2 drivers/input/serio/i8042.c --- a/drivers/input/serio/i8042.c Tue Jan 30 16:44:54 2007 -0800 +++ b/drivers/input/serio/i8042.c Tue Jan 30 16:45:00 2007 -0800 @@ -9,6 +9,7 @@ * under the terms of the GNU General Public License version 2 as published by * the Free Software Foundation. */ +#define USE_REAL_TIME_DELAY #include #include - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/11] Profile pc badness
Profile_pc was broken when using paravirtualization because the
assumption the kernel was running at CPL 0 was violated, causing
bad logic to read a random value off the stack.
The only way to be in kernel lock functions is to be in kernel
code, so validate that assumption explicitly by checking the CS
value. We don't want to be fooled by BIOS / APM segments and
try to read those stacks, so only match KERNEL_CS.
I moved some stuff in segment.h to make it prettier.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r 69d0339b9997 arch/i386/kernel/time.c
--- a/arch/i386/kernel/time.c Fri Feb 02 15:55:46 2007 -0800
+++ b/arch/i386/kernel/time.c Fri Feb 02 16:15:45 2007 -0800
@@ -131,15 +131,13 @@ unsigned long profile_pc(struct pt_regs
unsigned long pc = instruction_pointer(regs);
#ifdef CONFIG_SMP
- if (!user_mode_vm(regs) && in_lock_functions(pc)) {
+ if (!v8086_mode(regs) && SEGMENT_IS_KERNEL_CODE(regs->xcs) &&
+ in_lock_functions(pc)) {
#ifdef CONFIG_FRAME_POINTER
return *(unsigned long *)(regs->ebp + 4);
#else
- unsigned long *sp;
- if ((regs->xcs & 3) == 0)
- sp = (unsigned long *)>esp;
- else
- sp = (unsigned long *)regs->esp;
+ unsigned long *sp = (unsigned long *)>esp;
+
/* Return address is either directly at stack pointer
or above a saved eflags. Eflags has bits 22-31 zero,
kernel addresses don't. */
diff -r 69d0339b9997 include/asm-i386/ptrace.h
--- a/include/asm-i386/ptrace.h Fri Feb 02 15:55:46 2007 -0800
+++ b/include/asm-i386/ptrace.h Fri Feb 02 16:12:37 2007 -0800
@@ -49,6 +49,10 @@ static inline int user_mode_vm(struct pt
{
return ((regs->xcs & SEGMENT_RPL_MASK) | (regs->eflags & VM_MASK)) >=
USER_RPL;
}
+static inline int v8086_mode(struct pt_regs *regs)
+{
+ return (regs->eflags & VM_MASK);
+}
#define instruction_pointer(regs) ((regs)->eip)
#define regs_return_value(regs) ((regs)->eax)
diff -r 69d0339b9997 include/asm-i386/segment.h
--- a/include/asm-i386/segment.hFri Feb 02 15:55:46 2007 -0800
+++ b/include/asm-i386/segment.hFri Feb 02 16:08:50 2007 -0800
@@ -83,13 +83,7 @@
* The GDT has 32 entries
*/
#define GDT_ENTRIES 32
-
#define GDT_SIZE (GDT_ENTRIES * 8)
-
-/* Matches __KERNEL_CS and __USER_CS (they must be 2 entries apart) */
-#define SEGMENT_IS_FLAT_CODE(x) (((x) & 0xec) == GDT_ENTRY_KERNEL_CS * 8)
-/* Matches PNP_CS32 and PNP_CS16 (they must be consecutive) */
-#define SEGMENT_IS_PNP_CODE(x) (((x) & 0xf4) == GDT_ENTRY_PNPBIOS_BASE * 8)
/* Simple and small GDT entries for booting only */
@@ -134,4 +128,17 @@
#ifndef CONFIG_PARAVIRT
#define get_kernel_rpl() 0
#endif
+/*
+ * Matching rules for certain types of segments.
+ */
+
+/* Matches only __KERNEL_CS, ignoring PnP / USER / APM segments */
+#define SEGMENT_IS_KERNEL_CODE(x) (((x) & 0xfc) == GDT_ENTRY_KERNEL_CS * 8)
+
+/* Matches __KERNEL_CS and __USER_CS (they must be 2 entries apart) */
+#define SEGMENT_IS_FLAT_CODE(x) (((x) & 0xec) == GDT_ENTRY_KERNEL_CS * 8)
+
+/* Matches PNP_CS32 and PNP_CS16 (they must be consecutive) */
+#define SEGMENT_IS_PNP_CODE(x) (((x) & 0xf4) == GDT_ENTRY_PNPBIOS_BASE * 8)
+
#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/11] Kprobe rpl fix
Kprobes bugfix for paravirt compatibility - RPL on the CS when inserting BPs must match running kernel. Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]> CC: Eric Biederman <[EMAIL PROTECTED]> diff -r fad1c2108c13 arch/i386/kernel/kprobes.c --- a/arch/i386/kernel/kprobes.cFri Feb 02 16:22:37 2007 -0800 +++ b/arch/i386/kernel/kprobes.cFri Feb 02 16:28:48 2007 -0800 @@ -408,7 +408,7 @@ fastcall void *__kprobes trampoline_hand spin_lock_irqsave(_lock, flags); head = kretprobe_inst_table_head(current); /* fixup registers */ - regs->xcs = __KERNEL_CS; + regs->xcs = __KERNEL_CS | get_kernel_rpl(); regs->eip = trampoline_address; regs->orig_eax = 0x; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 5/11] Fix PIT override bug for paravirt
The time initialization changed for i386 when some code moved into time_init.
This made it no longer possible to override the PIT / HPET, which broke
paravirt guests.
Subject: Fix PIT override bug for paravirt
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r acd12d5196c7 arch/i386/kernel/paravirt.c
--- a/arch/i386/kernel/paravirt.c Thu Feb 01 23:13:18 2007 -0800
+++ b/arch/i386/kernel/paravirt.c Thu Feb 01 23:19:36 2007 -0800
@@ -497,7 +497,7 @@ struct paravirt_ops paravirt_ops = {
.memory_setup = machine_specific_memory_setup,
.get_wallclock = native_get_wallclock,
.set_wallclock = native_set_wallclock,
- .time_init = time_init_hook,
+ .time_init = native_time_init,
.init_IRQ = native_init_IRQ,
.cpuid = native_cpuid,
diff -r acd12d5196c7 arch/i386/kernel/time.c
--- a/arch/i386/kernel/time.c Thu Feb 01 23:13:18 2007 -0800
+++ b/arch/i386/kernel/time.c Thu Feb 01 23:43:21 2007 -0800
@@ -268,10 +268,17 @@ static void __init hpet_time_init(void)
{
if (!hpet_enable())
setup_pit_timer();
- do_time_init();
-}
-
+ time_init_hook();
+}
+
+void __init native_time_init(void)
+{
+ late_time_init = hpet_time_init;
+}
+
+#ifndef CONFIG_PARAVIRT
void __init time_init(void)
{
- late_time_init = hpet_time_init;
-}
+ native_time_init();
+}
+#endif
diff -r acd12d5196c7 include/asm-i386/paravirt.h
--- a/include/asm-i386/paravirt.h Thu Feb 01 23:13:18 2007 -0800
+++ b/include/asm-i386/paravirt.h Thu Feb 01 23:17:27 2007 -0800
@@ -185,7 +185,7 @@ static inline int set_wallclock(unsigned
return paravirt_ops.set_wallclock(nowtime);
}
-static inline void do_time_init(void)
+static inline void time_init(void)
{
return paravirt_ops.time_init();
}
diff -r acd12d5196c7 include/asm-i386/time.h
--- a/include/asm-i386/time.h Thu Feb 01 23:13:18 2007 -0800
+++ b/include/asm-i386/time.h Thu Feb 01 23:43:29 2007 -0800
@@ -28,13 +28,14 @@ static inline int native_set_wallclock(u
return retval;
}
+extern void native_time_init(void);
+
#ifdef CONFIG_PARAVIRT
#include
#else /* !CONFIG_PARAVIRT */
#define get_wallclock() native_get_wallclock()
#define set_wallclock(x) native_set_wallclock(x)
-#define do_time_init() time_init_hook()
#endif /* CONFIG_PARAVIRT */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/11] Vmi timer no idle hz fixes.patch
Fix the VMI-Timer no-idle-hz code.
Do not setup a one shot alarm if we are keeping the periodic alarm
armed. Additionally, since the periodic alarm can be run at a lower
rate than HZ, let's fixup the guard to the no-idle-hz mode appropriately.
This fixes the bug where the no-idle-hz mode might have a higher interrupt
rate than the non-idle case.
Signed-off-by: Dan Hecht <[EMAIL PROTECTED]>
diff -r 9d107b81bb7d arch/i386/kernel/vmitime.c
--- a/arch/i386/kernel/vmitime.cThu Feb 01 23:43:37 2007 -0800
+++ b/arch/i386/kernel/vmitime.cThu Feb 01 23:52:59 2007 -0800
@@ -374,7 +374,6 @@ int vmi_stop_hz_timer(void)
unsigned long seq, next;
unsigned long long real_cycles_expiry;
int cpu = smp_processor_id();
- int idle;
BUG_ON(!irqs_disabled());
if (sysctl_hz_timer != 0)
@@ -382,13 +381,13 @@ int vmi_stop_hz_timer(void)
cpu_set(cpu, nohz_cpu_mask);
smp_mb();
+
if (rcu_needs_cpu(cpu) || local_softirq_pending() ||
- (next = next_timer_interrupt(), time_before_eq(next, jiffies))) {
+ (next = next_timer_interrupt(),
+time_before_eq(next, jiffies + HZ/CONFIG_VMI_ALARM_HZ))) {
cpu_clear(cpu, nohz_cpu_mask);
- next = jiffies;
- idle = 0;
- } else
- idle = 1;
+ return 0;
+ }
/* Convert jiffies to the real cycle counter. */
do {
@@ -398,17 +397,13 @@ int vmi_stop_hz_timer(void)
} while (read_seqretry(_lock, seq));
/* This cpu is going idle. Disable the periodic alarm. */
- if (idle) {
- vmi_timer_ops.cancel_alarm(VMI_CYCLES_AVAILABLE);
- per_cpu(idle_start_jiffies, cpu) = jiffies;
- }
-
+ vmi_timer_ops.cancel_alarm(VMI_CYCLES_AVAILABLE);
+ per_cpu(idle_start_jiffies, cpu) = jiffies;
/* Set the real time alarm to expire at the next event. */
vmi_timer_ops.set_alarm(
- VMI_ALARM_WIRING | VMI_ALARM_IS_ONESHOT | VMI_CYCLES_REAL,
- real_cycles_expiry, 0);
-
- return idle;
+ VMI_ALARM_WIRING | VMI_ALARM_IS_ONESHOT | VMI_CYCLES_REAL,
+ real_cycles_expiry, 0);
+ return 1;
}
static void vmi_reenable_hz_timer(int cpu)
diff -r 9d107b81bb7d kernel/sysctl.c
--- a/kernel/sysctl.c Thu Feb 01 23:43:37 2007 -0800
+++ b/kernel/sysctl.c Thu Feb 01 23:52:59 2007 -0800
@@ -440,17 +440,7 @@ static ctl_table kern_table[] = {
.extra1 = ,
.extra2 = ,
},
-#ifdef CONFIG_S390
-#ifdef CONFIG_MATHEMU
- {
- .ctl_name = KERN_IEEE_EMULATION_WARNINGS,
- .procname = "ieee_emulation_warnings",
- .data = _ieee_emulation_warnings,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = _dointvec,
- },
-#endif
+#if defined(CONFIG_S390) || defined(CONFIG_VMI)
#ifdef CONFIG_NO_IDLE_HZ
{
.ctl_name = KERN_HZ_TIMER,
@@ -459,6 +449,18 @@ static ctl_table kern_table[] = {
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = _dointvec,
+ },
+#endif
+#endif
+#ifdef CONFIG_S390
+#ifdef CONFIG_MATHEMU
+ {
+ .ctl_name = KERN_IEEE_EMULATION_WARNINGS,
+ .procname = "ieee_emulation_warnings",
+ .data = _ieee_emulation_warnings,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = _dointvec,
},
#endif
{
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/11] Sched clock paravirt op
diff -r 3e746c0ebcdf arch/i386/kernel/paravirt.c
--- a/arch/i386/kernel/paravirt.c Fri Feb 02 13:54:53 2007 -0800
+++ b/arch/i386/kernel/paravirt.c Fri Feb 02 15:27:50 2007 -0800
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
/* nop stub */
static void native_nop(void)
@@ -523,6 +524,8 @@ struct paravirt_ops paravirt_ops = {
.write_msr = native_write_msr,
.read_tsc = native_read_tsc,
.read_pmc = native_read_pmc,
+ .get_scheduled_cycles = native_read_tsc,
+ .get_cpu_khz = native_calculate_cpu_khz,
.load_tr_desc = native_load_tr_desc,
.set_ldt = native_set_ldt,
.load_gdt = native_load_gdt,
diff -r 3e746c0ebcdf arch/i386/kernel/tsc.c
--- a/arch/i386/kernel/tsc.cFri Feb 02 13:54:53 2007 -0800
+++ b/arch/i386/kernel/tsc.cFri Feb 02 13:54:53 2007 -0800
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include "mach_timer.h"
@@ -102,9 +103,6 @@ unsigned long long sched_clock(void)
{
unsigned long long this_offset;
- if (unlikely(custom_sched_clock))
- return (*custom_sched_clock)();
-
/*
* Fall back to jiffies if there's no TSC available:
*/
@@ -113,13 +111,13 @@ unsigned long long sched_clock(void)
return (jiffies_64 - INITIAL_JIFFIES) * (10 / HZ);
/* read the Time Stamp Counter: */
- rdtscll(this_offset);
+ get_scheduled_cycles(this_offset);
/* return the value in ns */
return cycles_2_ns(this_offset);
}
-static unsigned long calculate_cpu_khz(void)
+unsigned long native_calculate_cpu_khz(void)
{
unsigned long long start, end;
unsigned long count;
diff -r 3e746c0ebcdf arch/i386/kernel/vmi.c
--- a/arch/i386/kernel/vmi.cFri Feb 02 13:54:53 2007 -0800
+++ b/arch/i386/kernel/vmi.cFri Feb 02 15:32:20 2007 -0800
@@ -880,7 +880,7 @@ static int __init activate_vmi(void)
paravirt_ops.setup_boot_clock = vmi_timer_setup_boot_alarm;
paravirt_ops.setup_secondary_clock =
vmi_timer_setup_secondary_alarm;
#endif
- custom_sched_clock = vmi_sched_clock;
+ paravirt_ops.get_scheduled_cycles = vmi_get_sched_cycles;
}
/*
diff -r 3e746c0ebcdf include/asm-i386/paravirt.h
--- a/include/asm-i386/paravirt.h Fri Feb 02 13:54:53 2007 -0800
+++ b/include/asm-i386/paravirt.h Fri Feb 02 15:27:50 2007 -0800
@@ -94,6 +94,8 @@ struct paravirt_ops
u64 (fastcall *read_tsc)(void);
u64 (fastcall *read_pmc)(void);
+ u64 (*get_scheduled_cycles)(void);
+ unsigned long (*get_cpu_khz)(void);
void (fastcall *load_tr_desc)(void);
void (fastcall *load_gdt)(const struct Xgt_desc_struct *);
@@ -273,6 +275,9 @@ static inline void halt(void)
#define rdtscll(val) (val = paravirt_ops.read_tsc())
+#define get_scheduled_cycles(val) (val = paravirt_ops.get_scheduled_cycles())
+#define calculate_cpu_khz() (paravirt_ops.get_cpu_khz())
+
#define write_tsc(val1,val2) wrmsr(0x10, val1, val2)
#define rdpmc(counter,low,high) do { \
diff -r 3e746c0ebcdf include/asm-i386/time.h
--- a/include/asm-i386/time.h Fri Feb 02 13:54:53 2007 -0800
+++ b/include/asm-i386/time.h Fri Feb 02 15:27:50 2007 -0800
@@ -30,7 +30,6 @@ static inline int native_set_wallclock(u
#ifdef CONFIG_PARAVIRT
#include
-extern unsigned long long native_sched_clock(void);
#else /* !CONFIG_PARAVIRT */
#define get_wallclock() native_get_wallclock()
diff -r 3e746c0ebcdf include/asm-i386/timer.h
--- a/include/asm-i386/timer.h Fri Feb 02 13:54:53 2007 -0800
+++ b/include/asm-i386/timer.h Fri Feb 02 13:54:53 2007 -0800
@@ -4,13 +4,21 @@
#include
#define TICK_SIZE (tick_nsec / 1000)
+
void setup_pit_timer(void);
+unsigned long long native_sched_clock(void);
+unsigned long native_calculate_cpu_khz(void);
+
/* Modifiers for buggy PIT handling */
extern int pit_latch_buggy;
extern int timer_ack;
extern int no_timer_check;
-extern unsigned long long (*custom_sched_clock)(void);
extern int no_sync_cmos_clock;
extern int recalibrate_cpu_khz(void);
+#ifndef CONFIG_PARAVIRT
+#define get_scheduled_cycles(val) rdtscll(val)
+#define calculate_cpu_khz() native_calculate_cpu_khz()
#endif
+
+#endif
diff -r 3e746c0ebcdf arch/i386/kernel/vmitime.c
--- a/arch/i386/kernel/vmitime.cFri Feb 02 13:54:53 2007 -0800
+++ b/arch/i386/kernel/vmitime.cFri Feb 02 15:31:35 2007 -0800
@@ -170,7 +170,7 @@ int vmi_set_wallclock(unsigned long now)
return -1;
}
-unsigned long long vmi_sched_clock(void)
+unsigned long long vmi_get_sched_cycles(void)
{
return read_available_cycles();
}
diff -r 3e746c0ebcdf include/asm-i386/vmi_time.h
--- a/include/asm-i386/vmi_time.h Fri Feb 02 13:54:53 2007 -0800
+++ b/include/asm-i386/vmi_time.h Fri Feb 02 15:31:53 2007 -0800
@@ -49,7 +49,7 @@ extern void __init vmi_time_init(void);
extern void __init
[PATCH 1/11] Make hrtimers friendly to vmi
Highres timers no longer breaks with VMI turned on because the required function is now exported even with hrtimers turned on. Until hrtimers becomes the default for i386, we must still support both timer modes, NO_HZ, and also NO_IDLE_HZ, which is paravirt specific. Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]> diff -r 4141f5f8c54e arch/i386/Kconfig --- a/arch/i386/Kconfig Thu Feb 01 18:46:27 2007 -0800 +++ b/arch/i386/Kconfig Thu Feb 01 18:53:21 2007 -0800 @@ -219,7 +219,7 @@ config PARAVIRT config VMI bool "VMI Paravirt-ops support" - depends on PARAVIRT && !NO_HZ + depends on PARAVIRT default y help VMI provides a paravirtualized interface to multiple hypervisors - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/11] VMI / Paravirt bugfixes for 2.6.21
A bunch of VMI and paravirt-ops bugfixes for upstream. Also, fix the timer code to work for 2.6.21, which had a number of changes. These should mostly be non-controversial and beneficial to all the paravirt-ops work. Zach <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3, try #2] Blackfin: documents and maintainer patch
Hi folks, Update the MAINTAINERS file change. Thanks Aubrey for pointing out this old MAINTAINERS file. Signed-off-by: Bryan Wu <[EMAIL PROTECTED]> --- Documentation/blackfin/00-INDEX | 11 ++ Documentation/blackfin/Filesystems | 169 +++ Documentation/blackfin/cache-lock.txt| 48 Documentation/blackfin/cachefeatures.txt | 65 +++ MAINTAINERS | 38 ++ 5 files changed, 331 insertions(+) Index: linux-2.6/Documentation/blackfin/00-INDEX === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6/Documentation/blackfin/00-INDEX 2007-02-06 11:37:24.0 +0800 @@ -0,0 +1,11 @@ +00-INDEX + - This file + +cache-lock.txt + - HOWTO for blackfin cache locking. + +cachefeatures.txt + - Supported cache features. + +Filesystems + - Requirements for mounting the root file system. Index: linux-2.6/Documentation/blackfin/Filesystems === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6/Documentation/blackfin/Filesystems2007-02-06 11:37:24.0 +0800 @@ -0,0 +1,169 @@ +/* + * File: Documentation/blackfin/Filesystems + * Based on: + * Author: + * + * Created: + * Description: This file contains the simple DMA Implementation for Blackfin + * + * Rev: $Id: Filesystems 2384 2006-11-01 04:12:43Z magicyang $ + * + * Modified: + * Copyright 2004-2006 Analog Devices Inc. + * + * Bugs: Enter bugs at http://blackfin.uclinux.org/ + * + */ + + How to mount the root file system in uClinux/Blackfin + - + +1 Mounting EXT3 File system. + + + Creating an EXT3 File system for uClinux/Blackfin: + + +Please follow the steps to form the EXT3 File system and mount the same as root +file system. + +a Make an ext3 file system as large as you want the final root file + system. + + mkfs.ext3 /dev/ram0 + +b Mount this Empty file system on a free directory as: + + mount -t ext3 /dev/ram0 ./test + where ./test is the empty directory. + +c Copy your root fs directory that you have so carefully made over. + + cp -af /tmp/my_final_rootfs_files/* ./test + + (For ex: cp -af uClinux-dist/romfs/* ./test) + +d If you have done everything right till now you should be able to see + the required "root" dir's (that's etc, root, bin, lib, sbin...) + +e Now unmount the file system + + umount ./test + +f Create the root file system image. + + dd if=/dev/ram0 bs=1k count= \ + > ext3fs.img + + +Now you have to tell the kernel that will be mounting this file system as +rootfs. +So do a make menuconfig under kernel and select the Ext3 journaling file system +support under File system --> submenu. + + +2. Mounting EXT2 File system. + - + +By default the ext2 file system image will be created if you invoke make from +the top uClinux-dist directory. + + +3. Mounting CRAMFS File System + + +To create a CRAMFS file system image execute the command + + mkfs.cramfs ./test cramfs.img + + where ./test is the target directory. + + +4. Mounting ROMFS File System + -- + +To create a ROMFS file system image execute the command + + genromfs -v -V "ROMdisk" -f romfs.img -d ./test + + where ./test is the target directory + + +5. Mounting the JFFS2 Filesystem + - + +To create a compressed JFFS filesystem (JFFS2), please execute the command + + mkfs.jffs2 -d ./test -o jffs2.img + + where ./test is the target directory. + +However, please make sure the following is in your kernel config. + +/* + * RAM/ROM/Flash chip drivers + */ +#define CONFIG_MTD_CFI 1 +#define CONFIG_MTD_ROM 1 +/* + * Mapping drivers for chip access + */ +#define CONFIG_MTD_COMPLEX_MAPPINGS 1 +#define CONFIG_MTD_BF533 1 +#undef CONFIG_MTD_UCLINUX + +Through the u-boot boot loader, use the jffs2.img in the corresponding +partition made in linux-2.6.x/drivers/mtd/maps/bf533_flash.c. + +NOTE - Currently the Flash driver is available only for EZKIT. Watch out for a + STAMP driver soon. + + +6. Mounting the NFS File system + - + + For mounting the NFS please do the following in the kernel config. + + In Networking Support --> Networking options --> TCP/IP networking --> + IP: kernel level autoconfiguration + + Enable BOOTP Support. + + In Kernel hacking --> Compiled-in kernel boot parameter add the following + +
Re: Regression in kernel linux-2.6.20-rc1/2: Problems with poweroff
On Mon, Feb 05, 2007 at 10:28:34PM -0500, Len Brown wrote: > > On Tue, Jan 02, 2007 at 12:41:59AM +0100, Berthold Cogel wrote: > > > > >> 'shutdown -h now' doesn't work for my system (Acer Extensa 3002 WLMi) > > > >> with linux-2.6.20-rc kernels. The system reboots instead. > > > >> I've checked linux-2.6.19.1 with an almost identical .config file > > > >> (differences because of new or changed options). For pre 2.6.20 kernels > > > >> shutdown works for my computer. > > Try CONFIG_USB=n CONFIG_USB_SUSPEND=n is most likely enough. That's an unfixed 2.6.20-rc regression reported more than once, the first time in December last year... > http://bugzilla.kernel.org/show_bug.cgi?id=7945 http://bugzilla.kernel.org/show_bug.cgi?id=7828 > -Len 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: Regression in kernel linux-2.6.20-rc1/2: Problems with poweroff
> On Tue, Jan 02, 2007 at 12:41:59AM +0100, Berthold Cogel wrote: > > >> 'shutdown -h now' doesn't work for my system (Acer Extensa 3002 WLMi) > > >> with linux-2.6.20-rc kernels. The system reboots instead. > > >> I've checked linux-2.6.19.1 with an almost identical .config file > > >> (differences because of new or changed options). For pre 2.6.20 kernels > > >> shutdown works for my computer. Try CONFIG_USB=n http://bugzilla.kernel.org/show_bug.cgi?id=7945 -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/28] Patches to pass vfsmount to LSM inode security hooks
On Monday 05 February 2007 11:02, Christoph Hellwig wrote: > On Mon, Feb 05, 2007 at 10:58:26AM -0800, Trond Myklebust wrote: > > On Mon, 2007-02-05 at 18:44 +, Christoph Hellwig wrote: > > > Just FYI: Al was very opposed to the idea of passing the vfsmount to > > > the vfs_ helpers, so you should discuss this with him. > > > > > > Looking at the actual patches I see you're lazy in a lot of places. > > > Please make sure that when you introduce a vfsmount argument somewhere > > > that it is _always_ passed and not just when it's conveniant. Yes, > > > that's more work, but then again if you're not consistant anyone > > > half-serious will laught at a security model using this infrasturcture. > > > > nfsd in particular tends to be a bit lazy about passing around vfsmount > > info. Forcing it to do so should not be hard since the vfsmount is > > already cached in the "struct export" (which can be found using the > > filehandle). It will take a bit of re-engineering in order to pass that > > information around inside the nfsd code, though. > > I actually have a patch to fix that. It's part of a bigger series > that's not quite ready, but I hope to finish all of it this month. It's actually not hard to "fix", and nfsd would look a little less weird. But what would this add, what do pathnames mean in the context of nfsd, and would nfsd actually become less weird? On the wire, nfs transmits file handles, not filenames. The file handle usually contains the inode numbers of the file and the containing directory. The code in fs/exportfs/expfs.c:find_exported_dentry() shows that fh_verify() should return a dentry that may be connected or not, depending on the export options and whether it's a file or directory. Together with the vfsmount from the svc_export, we could compute a pathname. But there is no way to tell different hardlinks to the same inode in the same directory from each other (both the file and directory inode are the same), and depending on the export options, we may or may not be able to distinguish different hardlinks across directories. If the nohide or crossmnt export options are used, we might run into similar aliasing issues with mounts (I'm not sure about this). So we could compute pathnames, but they wouldn't be very meaningful. Instead of going that way, it seems more reasonable to not do pathname based access control for the kernel kernel nfsd at all. Passing NULL as the vfsmounts does that. With a properly configured nfsd, the areas that remote users could access would still be well confined. The focus with this whole pathname based security stuff really is to be able to better confine local processes. The kernel nfsd is a kernel thread, and as such, confining it from a security point of view cannot really work, anyway. > > Note also that it might be nice to enforce the vfsmount argument by > > replacing the existing dentry parameters with a struct path instead of > > adding an extra reference to the vfsmount to existing functions. > > That definitly sounds like a good idea, independent of whether we want > to pass the vfsmount in more places or not. Note that you can still pass a NULL vfsmount in a struct path. Thanks, Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3, try #2] Blackfin: documents and maintainer patch
Hi everyone, This is the documents patch for Blackfin arch, also includes the MAINTAINERS file change. Thank Mike, I update this patch and regenerate it in -p1 format. Sorry for starting a new thread, because I switch to a new email client. Signed-off-by: Bryan Wu <[EMAIL PROTECTED]> --- Documentation/blackfin/00-INDEX | 11 ++ Documentation/blackfin/Filesystems | 169 +++ Documentation/blackfin/cache-lock.txt| 48 Documentation/blackfin/cachefeatures.txt | 65 +++ MAINTAINERS | 30 + 5 files changed, 323 insertions(+) Index: linux-2.6/Documentation/blackfin/00-INDEX === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6/Documentation/blackfin/00-INDEX 2007-02-06 01:20:13.0 +0800 @@ -0,0 +1,11 @@ +00-INDEX + - This file + +cache-lock.txt + - HOWTO for blackfin cache locking. + +cachefeatures.txt + - Supported cache features. + +Filesystems + - Requirements for mounting the root file system. Index: linux-2.6/Documentation/blackfin/Filesystems === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6/Documentation/blackfin/Filesystems2007-02-06 01:20:13.0 +0800 @@ -0,0 +1,169 @@ +/* + * File: Documentation/blackfin/Filesystems + * Based on: + * Author: + * + * Created: + * Description: This file contains the simple DMA Implementation for Blackfin + * + * Rev: $Id: Filesystems 2384 2006-11-01 04:12:43Z magicyang $ + * + * Modified: + * Copyright 2004-2006 Analog Devices Inc. + * + * Bugs: Enter bugs at http://blackfin.uclinux.org/ + * + */ + + How to mount the root file system in uClinux/Blackfin + - + +1 Mounting EXT3 File system. + + + Creating an EXT3 File system for uClinux/Blackfin: + + +Please follow the steps to form the EXT3 File system and mount the same as root +file system. + +a Make an ext3 file system as large as you want the final root file + system. + + mkfs.ext3 /dev/ram0 + +b Mount this Empty file system on a free directory as: + + mount -t ext3 /dev/ram0 ./test + where ./test is the empty directory. + +c Copy your root fs directory that you have so carefully made over. + + cp -af /tmp/my_final_rootfs_files/* ./test + + (For ex: cp -af uClinux-dist/romfs/* ./test) + +d If you have done everything right till now you should be able to see + the required "root" dir's (that's etc, root, bin, lib, sbin...) + +e Now unmount the file system + + umount ./test + +f Create the root file system image. + + dd if=/dev/ram0 bs=1k count= \ + > ext3fs.img + + +Now you have to tell the kernel that will be mounting this file system as +rootfs. +So do a make menuconfig under kernel and select the Ext3 journaling file system +support under File system --> submenu. + + +2. Mounting EXT2 File system. + - + +By default the ext2 file system image will be created if you invoke make from +the top uClinux-dist directory. + + +3. Mounting CRAMFS File System + + +To create a CRAMFS file system image execute the command + + mkfs.cramfs ./test cramfs.img + + where ./test is the target directory. + + +4. Mounting ROMFS File System + -- + +To create a ROMFS file system image execute the command + + genromfs -v -V "ROMdisk" -f romfs.img -d ./test + + where ./test is the target directory + + +5. Mounting the JFFS2 Filesystem + - + +To create a compressed JFFS filesystem (JFFS2), please execute the command + + mkfs.jffs2 -d ./test -o jffs2.img + + where ./test is the target directory. + +However, please make sure the following is in your kernel config. + +/* + * RAM/ROM/Flash chip drivers + */ +#define CONFIG_MTD_CFI 1 +#define CONFIG_MTD_ROM 1 +/* + * Mapping drivers for chip access + */ +#define CONFIG_MTD_COMPLEX_MAPPINGS 1 +#define CONFIG_MTD_BF533 1 +#undef CONFIG_MTD_UCLINUX + +Through the u-boot boot loader, use the jffs2.img in the corresponding +partition made in linux-2.6.x/drivers/mtd/maps/bf533_flash.c. + +NOTE - Currently the Flash driver is available only for EZKIT. Watch out for a + STAMP driver soon. + + +6. Mounting the NFS File system + - + + For mounting the NFS please do the following in the kernel config. + + In Networking Support --> Networking options --> TCP/IP networking --> + IP: kernel level autoconfiguration
[PATCH 2/3, try #2] Blackfin: serial driver for Blackfin architecture against Linux kernel 2.6.20
Hi everyone, This is the serial driver supports Blackfin processors. It is designed for the serial core framework. Thanks Alan and Aubrey. Aubrey update the patch according Alan's review. Sorry for start a new thread, because I change a new email client. Signed-off-by: Bryan Wu <[EMAIL PROTECTED]> --- drivers/serial/Kconfig | 94 drivers/serial/Makefile |1 drivers/serial/bfin_5xx.c | 1027 include/linux/serial_core.h |3 4 files changed, 1125 insertions(+) Index: linux-2.6/drivers/serial/Kconfig === --- linux-2.6.orig/drivers/serial/Kconfig 2007-02-06 01:13:42.0 +0800 +++ linux-2.6/drivers/serial/Kconfig2007-02-06 01:20:13.0 +0800 @@ -498,6 +498,100 @@ your boot loader (lilo or loadlin) about how to pass options to the kernel at boot time.) +config SERIAL_BFIN + tristate "Blackfin serial port support (EXPERIMENTAL)" + depends on BFIN && EXPERIMENTAL + select SERIAL_CORE + select SERIAL_BFIN_UART0 if (BF531 || BF532 || BF533 || BF561) + help + Add support for the built-in UARTs on the Blackfin. + + To compile this driver as a module, choose M here: the + module will be called bfin_5xx. + +config SERIAL_BFIN_CONSOLE + bool "Console on Blackfin serial port" + depends on SERIAL_BFIN + select SERIAL_CORE_CONSOLE + +choice + prompt "Blackfin UART Mode" + depends on SERIAL_BFIN + default SERIAL_BFIN_DMA + help + This driver supports the built-in serial ports of the Blackfin family + of CPUs + +config SERIAL_BFIN_DMA + bool "Blackfin UART DMA mode" + depends on DMA_UNCACHED_1M + help + This driver works under DMA mode. If this option is selected, the + blackfin simple dma driver is also enabled. + +config SERIAL_BFIN_PIO + bool "Blackfin UART PIO mode" + help + This driver works under PIO mode. + +endchoice + +config SERIAL_BFIN_UART0 + bool "Enable UART0" + depends on SERIAL_BFIN + help + Enable UART0 + +config BFIN_UART0_CTSRTS + bool "Enable UART0 hardware flow control" + depends on SERIAL_BFIN_UART0 + help + Enable hardware flow control in the driver. Using GPIO emulate the CTS/RTS + signal. + +config UART0_CTS_PIN + int "UART0 CTS pin" + depends on BFIN_UART0_CTSRTS + default 23 + help + The default pin is GPIO_GP7. + Refer to ./include/asm-blackfin/gpio.h to see the GPIO map. + +config UART0_RTS_PIN + int "UART0 RTS pin" + depends on BFIN_UART0_CTSRTS + default 22 + help + The default pin is GPIO_GP6. + Refer to ./include/asm-blackfin/gpio.h to see the GPIO map. + +config SERIAL_BFIN_UART1 + bool "Enable UART1" + depends on SERIAL_BFIN && BF537 + help + Enable UART1 + +config BFIN_UART1_CTSRTS + bool "Enable UART1 hardware flow control" + depends on SERIAL_BFIN_UART1 + help + Enable hardware flow control in the driver. Using GPIO emulate the CTS/RTS + signal. + +config UART1_CTS_PIN + int "UART1 CTS pin" + depends on BFIN_UART1_CTSRTS + default -1 + help + Refer to ./include/asm-blackfin/gpio.h to see the GPIO map. + +config UART1_RTS_PIN + int "UART1 RTS pin" + depends on BFIN_UART1_CTSRTS + default -1 + help + Refer to ./include/asm-blackfin/gpio.h to see the GPIO map. + config SERIAL_IMX bool "IMX serial port support" depends on ARM && ARCH_IMX Index: linux-2.6/drivers/serial/Makefile === --- linux-2.6.orig/drivers/serial/Makefile 2007-02-06 01:13:42.0 +0800 +++ linux-2.6/drivers/serial/Makefile 2007-02-06 01:20:13.0 +0800 @@ -26,6 +26,7 @@ obj-$(CONFIG_SERIAL_CLPS711X) += clps711x.o obj-$(CONFIG_SERIAL_PXA) += pxa.o obj-$(CONFIG_SERIAL_SA1100) += sa1100.o +obj-$(CONFIG_SERIAL_BFIN) += bfin_5xx.o obj-$(CONFIG_SERIAL_S3C2410) += s3c2410.o obj-$(CONFIG_SERIAL_SUNCORE) += suncore.o obj-$(CONFIG_SERIAL_SUNHV) += sunhv.o Index: linux-2.6/drivers/serial/bfin_5xx.c === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6/drivers/serial/bfin_5xx.c 2007-02-06 11:12:47.0 +0800 @@ -0,0 +1,1027 @@ +/* + * File: drivers/serial/bfin_5xx.c + * Based on: Based on drivers/serial/sa1100.c + * Author: Aubrey Li <[EMAIL PROTECTED]> + * + * Created: + * Description: Driver for blackfin 5xx serial ports + * + * Rev: $Id: bfin_5xx.c,v 1.19 2006/09/24 02:33:53 aubrey Exp $ + * + * Modified: + * Copyright 2006 Analog Devices Inc. + * + * Bugs: Enter bugs at
wbsd: IRQ handler type mismatch
I'm seeing this on bootup on my laptop with recent kernels (currently 2.6.20-rc6-mm3): Floppy drive(s): fd0 is 1.44M IRQ handler type mismatch for IRQ 6 current handler: wbsd [] setup_irq+0x194/0x1ac [] floppy_hardint+0x0/0xc0 [floppy] [] request_irq+0x7c/0x98 [] init_module+0x546/0xe15 [floppy] [] _spin_unlock_irq+0x5/0x7 [] __link_module+0x0/0x10 [] __link_module+0x0/0x10 [] sys_init_module+0x1781/0x18c8 [] blk_init_queue+0x0/0x8 [] vfs_read+0xa6/0x152 [] sysenter_past_esp+0x5f/0x85 [] error_code+0x68/0x84 === floppy0: Unable to grab IRQ6 for the floppy driver It looks like wbsd is being loaded first, which being a nice PnP device sees that IRQ 6 is available and grabs it. Then the we try to load the floppy module (which is hard-coded to use IRQ 6) which fails because wbsd already owns IRQ6 (which is fine, there's no floppy controller anyway). The mismatch is occurring because wbsd passes IRQF_SHARED whereas floppy doesn't. I assume one of the two is likely wrong. Should wbsd really be passing IRQF_SHARED here? This is an LPC device which uses ISA-style edge triggered interrupts, is it safe to try and share an interrupt with this chip anyway? -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc6-mm3 and NTFS: BUG: at arch/i386/mm/highmem.c:52 kmap_atomic()
On Mon, 05 Feb 2007 20:55:35 -0600 Robert Hancock <[EMAIL PROTECTED]> wrote:
> Seeing these BUGs on 2.6.20-rc6-mm3 when mounting an NTFS partition. I
> saw some reports of something like this on -mm1, was this supposed to be
> patched already?
>
> BUG: at arch/i386/mm/highmem.c:52 kmap_atomic()
> [] kmap_atomic+0xb4/0x1cd
> [] ntfs_end_buffer_async_read+0x276/0x2db [ntfs]
> [] end_bio_bh_io_sync+0x0/0x39
> [] end_bio_bh_io_sync+0x2e/0x39
> [] bio_endio+0x5b/0x63
> [] _spin_lock_irqsave+0x9/0xd
> [] lock_timer_base+0x15/0x2f
> [] __end_that_request_first+0x176/0x421
> [] scsi_delete_timer+0xf/0x50 [scsi_mod]
> [] scsi_request_fn+0x2d4/0x324 [scsi_mod]
> [] ata_scsi_qc_complete+0x344/0x354 [libata]
> [] __blk_run_queue+0x17/0x35
> [] scsi_end_request+0x1a/0xa8 [scsi_mod]
> [] scsi_io_completion+0x15a/0x32b [scsi_mod]
> [] pit_next_event+0x2b/0x2f
> [] sd_rw_intr+0x21b/0x245 [sd_mod]
> [] scsi_finish_command+0x84/0x8b [scsi_mod]
> [] blk_done_softirq+0x49/0x54
> [] __do_softirq+0x5d/0xba
> [] do_softirq+0x32/0x36
> [] irq_exit+0x38/0x6b
> [] do_IRQ+0x87/0x9c
> [] common_interrupt+0x23/0x28
> [] __dequeue_signal+0x97/0x14e
> [] acpi_processor_idle+0x209/0x3ca
> [] acpi_processor_idle+0x0/0x3ca
> [] cpu_idle+0xaa/0xd0
> [] start_kernel+0x435/0x43d
> [] unknown_bootoption+0x0/0x202
Yes, that was a real bug. It got fixed in 2.6.20.
Below is the fix, which I have just uploaded to the hot-fixes directory,
thanks.
--- a/fs/ntfs/aops.c~ntfs-kmap_atomic-atomicity-fix
+++ a/fs/ntfs/aops.c
@@ -92,10 +92,12 @@ static void ntfs_end_buffer_async_read(s
ofs = 0;
if (file_ofs < init_size)
ofs = init_size - file_ofs;
+ local_irq_save(flags);
kaddr = kmap_atomic(page, KM_BIO_SRC_IRQ);
memset(kaddr + bh_offset(bh) + ofs, 0,
bh->b_size - ofs);
kunmap_atomic(kaddr, KM_BIO_SRC_IRQ);
+ local_irq_restore(flags);
flush_dcache_page(page);
}
} else {
@@ -143,11 +145,13 @@ static void ntfs_end_buffer_async_read(s
recs = PAGE_CACHE_SIZE / rec_size;
/* Should have been verified before we got here... */
BUG_ON(!recs);
+ local_irq_save(flags);
kaddr = kmap_atomic(page, KM_BIO_SRC_IRQ);
for (i = 0; i < recs; i++)
post_read_mst_fixup((NTFS_RECORD*)(kaddr +
i * rec_size), rec_size);
kunmap_atomic(kaddr, KM_BIO_SRC_IRQ);
+ local_irq_restore(flags);
flush_dcache_page(page);
if (likely(page_uptodate && !PageError(page)))
SetPageUptodate(page);
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.16.32 stuck in generic_file_aio_write()
Dear Igmar Palsenberg, I can not make sure it is hardware problem, but I have interest in this case's reproducing. If you tell me your platform's construction, I will try it and give you good solution. Does your RAID adapter's firmware version work on 1.42? Areca firmware had fix some hardware bugs and rare sg length handle in this version. Best Regards Erich Chen - Original Message - From: "Igmar Palsenberg" <[EMAIL PROTECTED]> To: "Andrew Morton" <[EMAIL PROTECTED]> Cc: ; <[EMAIL PROTECTED]>; "erich" <[EMAIL PROTECTED]> Sent: Monday, February 05, 2007 6:24 PM Subject: Re: 2.6.16.32 stuck in generic_file_aio_write() Does the other machine have the same problems? It does. It seems to depend on the interrupt frequency : Setting KERNEL_HZ=250 makes it ony appear once a month or so, with KERNEL_HZ=1000, it will occur within a week. It does happen a lot less with the other machine, which isn't under disk activity load as much as the other machine. Are you able to rule out a hardware failure? Well.. It's too much coincidence that 2 (almost identical) machines show the same weard behaviour. What strikes me that only *disk* interrupts after a while don't get handled. The machine itself is alive, just all disk IO is blocked, which makes it pretty much useless. Erich, could this be some sort of hardware problem ? I know it's a PITA to reproduce, but setting CONFIG_HZ to 1000 and bashing the machine with diskactivity seems to help :) Regards, Igmar -- Igmar Palsenberg JDI ICT Zutphensestraatweg 85 6953 CJ Dieren Tel: +31 (0)313 - 496741 Fax: +31 (0)313 - 420996 The Netherlands mailto: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.20-rc6-mm3 and NTFS: BUG: at arch/i386/mm/highmem.c:52 kmap_atomic()
Seeing these BUGs on 2.6.20-rc6-mm3 when mounting an NTFS partition. I saw some reports of something like this on -mm1, was this supposed to be patched already? BUG: at arch/i386/mm/highmem.c:52 kmap_atomic() [] kmap_atomic+0xb4/0x1cd [] ntfs_end_buffer_async_read+0x276/0x2db [ntfs] [] end_bio_bh_io_sync+0x0/0x39 [] end_bio_bh_io_sync+0x2e/0x39 [] bio_endio+0x5b/0x63 [] _spin_lock_irqsave+0x9/0xd [] lock_timer_base+0x15/0x2f [] __end_that_request_first+0x176/0x421 [] scsi_delete_timer+0xf/0x50 [scsi_mod] [] scsi_request_fn+0x2d4/0x324 [scsi_mod] [] ata_scsi_qc_complete+0x344/0x354 [libata] [] __blk_run_queue+0x17/0x35 [] scsi_end_request+0x1a/0xa8 [scsi_mod] [] scsi_io_completion+0x15a/0x32b [scsi_mod] [] pit_next_event+0x2b/0x2f [] sd_rw_intr+0x21b/0x245 [sd_mod] [] scsi_finish_command+0x84/0x8b [scsi_mod] [] blk_done_softirq+0x49/0x54 [] __do_softirq+0x5d/0xba [] do_softirq+0x32/0x36 [] irq_exit+0x38/0x6b [] do_IRQ+0x87/0x9c [] common_interrupt+0x23/0x28 [] __dequeue_signal+0x97/0x14e [] acpi_processor_idle+0x209/0x3ca [] acpi_processor_idle+0x0/0x3ca [] cpu_idle+0xaa/0xd0 [] start_kernel+0x435/0x43d [] unknown_bootoption+0x0/0x202 === -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Blackfin: serial driver for Blackfin architecture against Linux kernel 2.6.20
Hi Alan, On 2/5/07, Alan <[EMAIL PROTECTED]> wrote: Likewise - why this not locks ? Other than the locking bits looks ok, although has rather a lot of ifdefs Thanks to point it out. It should be fixed in the coming patch. Thanks, -Aubrey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.19.2] r8169: support RTL8169SC/8110SC
Dear Francois:
Thanks for your reply. I gave my idea about your questions with the the
key word "ANS_2".
If you have further questions, please raise them.
Best Regards,
Edward 2007/02/06
Francois Romieu 提到:
>許恆嘉 <[EMAIL PROTECTED]> :
>[...]
>
>
static struct pci_device_id rtl8169_pci_tbl[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8129), 0, 0, RTL_CFG_0 },
- { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8136), 0, 0, RTL_CFG_2 },
- { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8167), 0, 0, RTL_CFG_0 },
- { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8168), 0, 0, RTL_CFG_2 },
- { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8169), 0, 0, RTL_CFG_0 },
- { PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4300), 0, 0, RTL_CFG_0 },
- { PCI_DEVICE(0x1259, 0xc107), 0, 0, RTL_CFG_0 },
- { PCI_DEVICE(0x16ec, 0x0116), 0, 0, RTL_CFG_0 },
- { PCI_VENDOR_ID_LINKSYS, 0x1032,
- PCI_ANY_ID, 0x0024, 0, 0, RTL_CFG_0 },
+ { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8169), },
+ { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8167), },
>>>The current driver is intended to handle the whole set of PCI IDs
>>>which would be removed by the patch. Thoug some combination of
>>>chipset and motherboard do not work as expected, the gigabit
>>>chipsets have been reported to work.
>>>
>>>Please elaborate if there is a good reason to remove any ID.
>>>
>>>
>>>
>>>
>>ANS:
>>I have explained my point about this in last question. This driver is
>>developed for Realtek PCI gigabit ethernet controllers. Although some
>>vendors may use Realtek solutions with their own PCI DIDs and VIDs, they
>>should customize this driver and maintained the customized driver on
>>their own.
>>
>>
>
>Vendors will change the PCI ID because they like to see their name in
>the nifty hardware GUI under Windows. The brave ones will mess with the
>VPD (before or after they vandalize the ACPI tables, at their option).
>Eventually they will copy an outdated version of your driver on their site
>with the updated ID. Given the tight margin on these kind of mass-volume
>product, I would not expect vendors to do more for their customers who
>use Linux.
>
>
ANS_2:
So, do you think that it is a good idea to keep other vendos's PID and
DID in the part?
>If your hardware changes significantly, it may make sense to use a new,
>different driver. Otherwise, as long as the changes are minor, a single
>in-kernel driver which works out of the box for most users/vendors offers
>the best coverage. It should not be neglected.
>
>So far, I have only seen minor differences between r8101-1.001.00,
>r8168-8.001.00 and r8169-6.001.00. The mac init sequence is not pretty
>to unify but the drivers stay mostly the same. There even is a floating
>patch for MSI support which seems manageable within a single driver.
>
>Of course it depends a lot on the kind of changes that you envision for
>the driver(s).
>
>
ANS_2:
Sure! You are right. RTL8110SC, RTL8111B and RTL8101E have modest
differences, now. However, RTL8101E is a PCI-E fast ethernet controller.
I don't think is a good idea to merge its Linux driver into r8168.c or
r8169.c. RTL8110SC is the final version of Realtek PCI gigabit ethernet
controller. Moreover, due to the increasing popularity of PCI-E, Realtek
is going to design several generations of PCI-E ethernet controllers to
satisfy customer requests. I have discussed this issue with my hardware
colleagues. They believe that both MAC register layout and tx/rx
descriptor layout will be changed a lot in new PCI-E ICs. Actually, they
already did. Therefore, the hardwares of RTL8111B(PCI-E gigabit
ethernet) and RTL8101E(PCI-E fast ethernet) will have frequent and
drastic changes. So, I think that it's a good moment to separate their
Linux drivers, and r8169.c can become stable.
>[...]
>
>
RxMaxSize = 0xDA,
CPlusCmd = 0xE0,
IntrMitigate = 0xE2,
@@ -287,11 +291,10 @@ enum RTL8169_register_content {
RxOK = 0x01,
/* RxStatusDesc */
- RxFOVF = (1 << 23),
- RxRWT = (1 << 22),
- RxRES = (1 << 21),
- RxRUNT = (1 << 20),
- RxCRC = (1 << 19),
+ RxRES = 0x0020,
+ RxCRC = 0x0008,
+ RxRUNT = 0x0010,
+ RxRWT = 0x0040,
>>>This part removes RxFOVF. Please elaborate if there is a reason
>>>to do so.
>>>
>>>
>>>
>>>
>>ANS:
>>According to the spec of RTL8110SC, bit 23 and bit 24 are reserved in
>>the 1st double word of rx status descriptor. Therefore, I delete it.
>>
>>
>
>
>
ANS_2:
I have the specs of RTL8110S/SB/SC. According those specs, the two bits are
reserved. Since I didn't create this driver, I don't know who wrote it. I think
they are not used.
>The bits are fine for the old Gigabit 8169 though, aren't they ?
>
>[...]
>
>
>>>Two points here:
>>>1. the driver uniformly uses u{8/16/32} types. Please follow the current
>>> style and avoid to add uint{8/16/32}_t things.
>>>2. does this new field bring something that struct
Re: [RFC 0/28] Patches to pass vfsmount to LSM inode security hooks
On Monday 05 February 2007 11:50, Chris Wright wrote: > This kind of change (or perhaps straight to struct path) is definitely > needed from AA. I tried struct path; in terms of code size it doesn't seem worth it. We could get identical code out of it as if we were passing the dentry and vfsmount individually, with somewhat slimmer looking interfaces, but then we'd have to create temporary struct path objects in a few places, and accessing either object would become a bit more verbose (path.dentry instead of dentry, etc.) See the following thread on linux-kernel, Message-ID [EMAIL PROTECTED]: [RFC] Pack the vfsmount and dentry in nameidata into a struct path Thanks, Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/9] mm: fix pagecache write deadlocks
On Sun, Feb 04, 2007 at 10:36:20AM -0800, Andrew Morton wrote: > On Sun, 4 Feb 2007 16:10:51 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote: > > > They're not likely to hit the deadlocks, either. Probability gets more > > likely after my patch to lock the page in the fault path. But practially, > > we could live without that too, because the data corruption it fixes is > > very rare as well. Which is exactly what we've been doing quite happily > > for most of 2.6, including all distro kernels (I think). > > Thing is, an application which is relying on the contents of that page is > already unreliable (or really peculiar), because it can get indeterminate > results anyway. Not necessarily -- they could read from one part of a page and write to another. I see this as the biggest data corruption problem. But even in the case where they can get indeterminate results, they can still determine what the results *won't* be. Eg. they might use a single byte for a flag or something. > > ... > > > > On a P4 Xeon, SMP kernel, on a tmpfs filesystem, a 1GB dd if=/dev/zero write > > had the following performance (higher is worse): > > > > Orig kernel New kernel > > new file (no pagecache) > > 4K blocks 1.280s 1.287s (+0.5%) > > 64K blocks 1.090s 1.105s (+1.4%) > > notrunc (uptodate pagecache) > > 4K blocks 0.976s 1.001s (+0.5%) > > 64K blocks 0.780s 0.792s (+1.5%) > > > > [numbers are better than +/- 0.005] > > > > So we lose somewhere between half and one and a half of one percent > > performance in a pagecache write intensive workload. > > That's not too bad - caches are fast. Did you look at optimising the > handling of that temp page, ensure that we always use the same page? I > guess the page allocator per-cpu-pages thing is being good here. Yeah it should be doing a reasonable job. > I'm not sure how, though. Park a copy in the task_struct, just as an > experiment. But that'd de-optimise multiple-tasks-writing-on-the-same-cpu. > Maybe a per-cpu thing? Largely duplicates the page allocator's per-cpu-pages. Putting a copy in the task_struct won't do much I figure, except saving a copule of interrupt enable/disable, and being more wasteful of memory and cache-hotness. Per-cpu doesn't work because we can't hold preempt off over the usercopy (well, we *could* do it in a loop together with fault_in_pages, but that just adds to the icache bloat). > > Of course, we're also increasing caceh footprint, which this test won't > show. We are indeed. At least we release the hot page back to the allocator very quickly that it can be reused. The upshot is that your writev performance will be improved :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 0/28] Patches to pass vfsmount to LSM inode security hooks
On Monday 05 February 2007 10:44, Christoph Hellwig wrote: > Looking at the actual patches I see you're lazy in a lot of places. > Please make sure that when you introduce a vfsmount argument somewhere > that it is _always_ passed and not just when it's conveniant. Yes, that's > more work, but then again if you're not consistant anyone half-serious > will laught at a security model using this infrasturcture. It may appear like laziness, but it's not. Let's look at where we're passing NULL at the moment: fs/hpfs/namei.c In hpfs_unlink, hpfs truncates one of its own inodes through notify_change(). You definitely don't want any lsms to interfere here, pathname based or not; hpfs should probably truncate its inode itself instead. But given that hpfs goes via the vfs, we at least pass NULL to indicate that this file really has no meaningful paths to it anymore. (In addition, we don't really have a vfsmount at this point anymore, and neither would it make sense to pass it there.) To play more nicely with other lsms, hpfs could mark the inode as private before attempting the truncate. fs/reiserfs/xattr.c The directories an files that reiserfs uses internally to store xattrs are hanging off ".reiserfs_priv/xattrs" in the filesystem. This part of the namespace is not accessible or visible from user space though except through the xattr syscalls. Reiserfs should probably just mark all its xattr inodes as private in order to play nicely with other lsms. As far as pathname based lsms are concerned, pathnames to those fs-internal objects are meaningless though, and so we pass NULL here. fs/sysfs/file.c fs/nfsd/vfs.c and fs/nfsd/nfs4recover.c For nfsd, the concept of pathnames is a bit peculiar. I'll try to respond to that separately. Thanks, Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 1/3] Blackfin: architecture patch against Linux kernel 2.6.20 (again)
Hi everyone, This is the Blackfin architecture patch against Linux kernel 2.6.20, again. As we promised, some issues are fixed in the latest release with the help from LKML. The blackfin-arch patch is at http://blackfin.uclinux.org/gf/download/frsrelease/25/2501/blackfin-arch-linux-2.6.20.patch Which, at 1.9M bytes, is too large to attach here. Please let me know if you want me to do it anyway. I understand that a full review is a huge job, but I'd appreciate a pointer or two in the general direction that I need to take this in order to get it acceptable for mainline. Thanks Ben, I regenerated the patch by -p1 setting and change a new email client to send this emails. Thanks Mike and Sonic fixed the patch downloading problem, now it can be downloaded. Signed-off-by: Bryan Wu <[EMAIL PROTECTED]> --- arch/blackfin/Kconfig | 891 +++ arch/blackfin/Makefile | 81 arch/blackfin/boot/Makefile| 27 arch/blackfin/defconfig| 1314 +++ arch/blackfin/kernel/Makefile | 13 arch/blackfin/kernel/asm-offsets.c | 138 + arch/blackfin/kernel/bfin_dma_5xx.c| 747 ++ arch/blackfin/kernel/bfin_gpio.c | 654 + arch/blackfin/kernel/bfin_ksyms.c | 115 arch/blackfin/kernel/dma-mapping.c | 174 + arch/blackfin/kernel/dualcore_test.c | 51 arch/blackfin/kernel/entry.S | 92 arch/blackfin/kernel/init_task.c | 63 arch/blackfin/kernel/irqchip.c | 144 + arch/blackfin/kernel/module.c | 431 +++ arch/blackfin/kernel/process.c | 348 ++ arch/blackfin/kernel/ptrace.c | 413 +++ arch/blackfin/kernel/setup.c | 894 +++ arch/blackfin/kernel/signal.c | 431 +++ arch/blackfin/kernel/sys_bfin.c| 133 + arch/blackfin/kernel/time.c| 326 ++ arch/blackfin/kernel/traps.c | 622 + arch/blackfin/kernel/vmlinux.lds.S | 221 + arch/blackfin/lib/Makefile | 10 arch/blackfin/lib/ashldi3.c| 56 arch/blackfin/lib/ashrdi3.c| 57 arch/blackfin/lib/checksum.c | 138 + arch/blackfin/lib/divsi3.S | 156 + arch/blackfin/lib/gcclib.h | 49 arch/blackfin/lib/ins.S| 71 arch/blackfin/lib/lshrdi3.c| 70 arch/blackfin/lib/memchr.S | 65 arch/blackfin/lib/memcmp.S | 110 arch/blackfin/lib/memcpy.S | 129 + arch/blackfin/lib/memmove.S| 103 arch/blackfin/lib/memset.S | 103 arch/blackfin/lib/modsi3.S | 74 arch/blackfin/lib/muldi3.c | 97 arch/blackfin/lib/outs.S | 64 arch/blackfin/lib/strcmp.c | 11 arch/blackfin/lib/strcpy.c | 11 arch/blackfin/lib/strncmp.c| 11 arch/blackfin/lib/strncpy.c| 11 arch/blackfin/lib/udivsi3.S| 157 + arch/blackfin/lib/umodsi3.S| 63 arch/blackfin/mach-bf533/Kconfig | 92 arch/blackfin/mach-bf533/Makefile |9 arch/blackfin/mach-bf533/boards/Makefile |8 arch/blackfin/mach-bf533/boards/cm_bf533.c | 271 ++ arch/blackfin/mach-bf533/boards/ezkit.c| 231 + arch/blackfin/mach-bf533/boards/generic_board.c| 97 arch/blackfin/mach-bf533/boards/stamp.c| 328 ++ arch/blackfin/mach-bf533/cpu.c | 163 + arch/blackfin/mach-bf533/head.S| 776 ++ arch/blackfin/mach-bf533/ints-priority.c | 67 arch/blackfin/mach-bf537/Kconfig | 141 + arch/blackfin/mach-bf537/Makefile |9 arch/blackfin/mach-bf537/boards/Makefile |8 arch/blackfin/mach-bf537/boards/cm_bf537.c | 379 +++ arch/blackfin/mach-bf537/boards/generic_board.c| 464 +++ arch/blackfin/mach-bf537/boards/led.S | 183 + arch/blackfin/mach-bf537/boards/pnav10.c | 541 arch/blackfin/mach-bf537/boards/stamp.c| 575 arch/blackfin/mach-bf537/cpu.c | 163 + arch/blackfin/mach-bf537/head.S| 605 + arch/blackfin/mach-bf537/ints-priority.c | 76 arch/blackfin/mach-bf561/Kconfig | 222 + arch/blackfin/mach-bf561/Makefile |
Re: [patch 9/9] mm: fix pagecache write deadlocks
On Sun, Feb 04, 2007 at 05:40:35PM +, Anton Altaparmakov wrote: > On Sun, 4 Feb 2007, Andrew Morton wrote: > > truncate's OK: we're holding i_mutex. > > How about excluding readpage() (in addition to truncate if Nick is right > and some cases of truncate do not hold i_mutex) with an extra page flag as > I proposed for truncate exclusion? Then it would not matter that > prepare_write might have allocated blocks and might expose stale data. > It would go to sleep and wait on the bit to be cleared instead of trying > to bring the page uptodate. It can then lock the page and either find it > uptodate (because commit_write did it) or not and then bring it uptodate. > > Then we could safely fault in the page, copy from it into a temporary > page, then lock the destination page again and copy into it. > > This is getting more involved as a patch again... )-: But at least it > does not affect the common case except for having to check the new page > flag in every readpage() and truncate() call. But at least the checks > could be with an "if (unlikely(newpageflag()))" so should not be too bad. > > Have I missed anything this time? Yes. If you have a flag to exclude readpage(), then you must also exclude filemap_nopage, in which case it is still deadlocky. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Blackfin: architecture patch against Linux kernel 2.6.20
On 2/5/07, Randy Dunlap <[EMAIL PROTECTED]> wrote: I can't access this patch file. (no, don't attach it for the mailing list) please try this: http://blackfin.uclinux.org/gf/download/frsrelease/25/2501/blackfin-arch-linux-2.6.20.patch as it gets tweaked, the magic id # gets incremented :/ this URL should contain the latest link: http://blackfin.uclinux.org/gf/project/uclinux-dist/frs/?action=FrsReleaseView_id=25 -mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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_uli puts second channel to PIO4 on 2.6.18
Resending since I didn't receive any replies on this. Could somebody please tell me if this is planned? Is there some hardware bug that needs to be worked around this way? Is there some problem with the disk? Should changing controller (for example) to VIA based one help? Or is it some bug in the code? As you may realize this problem is very urgent for me because it blocks one of my important production servers. Thanks in advance, GK On Sat, 3 Feb 2007, Grzegorz Kulewski wrote: Hi, I got this SATA PCI card: 00:04.0 Mass storage controller: ALi Corporation ALi M5281 Serial ATA / RAID Host Controller (rev a4) (prog-if 85) Subsystem: ALi Corporation ALi M5281 Serial ATA / RAID Host Controller Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 128, Cache Line Size: 512 bytes Interrupt: pin A routed to IRQ 185 Region 0: I/O ports at d400 [size=8] Region 1: I/O ports at d000 [size=4] Region 2: I/O ports at b800 [size=8] Region 3: I/O ports at b400 [size=4] Region 4: I/O ports at b000 [size=16] [virtual] Expansion ROM at 8800 [disabled] [size=64K] 00:04.1 Mass storage controller: ALi Corporation M5228 ALi ATA/RAID Controller (rev c6) (prog-if 85) Subsystem: ALi Corporation Unknown device 5281 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 128 Interrupt: pin A routed to IRQ 9 Region 0: I/O ports at a800 [size=8] Region 1: I/O ports at a400 [size=4] Region 2: I/O ports at a000 [size=8] Region 3: I/O ports at 9800 [size=4] Region 4: I/O ports at 9400 [size=16] It worked very well for half a year but with one disk (IIRC it was even plugged into second channel but I wont bet on it). Now I have second disk (very similar) and it is always put into PIO4 mode: [ 17.404451] libata version 2.00 loaded. [ 17.404916] sata_uli :00:04.0: version 1.0 [ 17.405009] ACPI: PCI Interrupt :00:04.0[A] -> GSI 18 (level, low) -> IRQ 185 [ 17.405223] ata1: SATA max UDMA/133 cmd 0xD400 ctl 0xD002 bmdma 0xB000 irq 185 [ 17.405385] ata2: SATA max UDMA/133 cmd 0xB800 ctl 0xB402 bmdma 0xB008 irq 185 [ 17.405519] scsi2 : sata_uli [ 17.858803] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 17.880541] ata1.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 0/32) [ 17.880660] ata1.00: ata1: dev 0 multi count 16 [ 17.58] ata1.00: configured for UDMA/133 [ 17.888941] scsi3 : sata_uli [ 18.342469] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 18.343573] ata2.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 0/32) [ 18.343691] ata2.00: ata2: dev 0 multi count 16 [ 18.344972] ata2.00: configured for PIO4 [ 18.345466] Vendor: ATA Model: ST3250620NS Rev: 3.AE [ 18.346391] Type: Direct-Access ANSI SCSI revision: 05 [ 18.347464] Vendor: ATA Model: ST3250620NS Rev: 3.AE [ 18.348390] Type: Direct-Access ANSI SCSI revision: 05 [ 18.349457] SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) [ 18.350234] sda: Write Protect is off [ 18.350307] sda: Mode Sense: 00 3a 00 00 [ 18.351234] SCSI device sda: drive cache: write back [ 18.352233] SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) [ 18.352444] sda: Write Protect is off [ 18.352517] sda: Mode Sense: 00 3a 00 00 [ 18.353443] SCSI device sda: drive cache: write back [ 18.353522] sda: sda1 sda2 [ 18.371118] sd 2:0:0:0: Attached scsi disk sda [ 18.372221] SCSI device sdb: 488397168 512-byte hdwr sectors (250059 MB) [ 18.372431] sdb: Write Protect is off [ 18.372504] sdb: Mode Sense: 00 3a 00 00 [ 18.373440] SCSI device sdb: drive cache: write back [ 18.374430] SCSI device sdb: 488397168 512-byte hdwr sectors (250059 MB) [ 18.375218] sdb: Write Protect is off [ 18.375291] sdb: Mode Sense: 00 3a 00 00 [ 18.376216] SCSI device sdb: drive cache: write back [ 18.376295] sdb: unknown partition table [ 18.381481] sd 3:0:0:0: Attached scsi disk sdb As you probably know this gives very very poor performance. Is there any way to make it fast? I tried changing cables and reconnecting them but it looks like it does not help. I can't do too much with this hardware since it is used as production server. But testing some patches is of course possible. On the other hand full kernel upgrade to 2.6.19 or .20 is not possible because this kernel has openvz patches and I don't have them for .19 or .20 yet. This is what I am getting from various utilities: # dmesg [0.00] Linux version 2.6.18-028test010 ([EMAIL PROTECTED]) (gcc
Re: [PATCH 1/3] Blackfin: architecture patch against Linux kernel 2.6.20
On Mon, 5 Feb 2007 02:28:40 -0500 Wu, Bryan wrote: > Hi everyone, > > This is the Blackfin architecture patch against Linux kernel 2.6.20, > again. As we promised, some issues are fixed in the latest release with > the help from lkml. > > The blackfin-arch patch is at > https://blackfin.uclinux.org/gf/download/frsrelease/25/2490/blackfin-arc > h-linux-2.6.20.patch > Which, at 1.9M bytes, is too large to attach here. Please let me know if > you want me to do it anyway. I can't access this patch file. (no, don't attach it for the mailing list) --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[no subject]
we don't actually use anything from asm-m68k/page.h in asm-m68k/user.h, so don't bother including it Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]> --- --- a/include/asm-m68k/user.h +++ b/include/asm-m68k/user.h @@ -1,8 +1,6 @@ #ifndef _M68K_USER_H #define _M68K_USER_H -#include - /* Core file format: The core file is written in such a way that gdb can understand it and provide useful information to the user (under linux we use the 'trad-core' bfd). There are quite a number of pgpFS6zDRTeT4.pgp Description: PGP signature
Re: hwsusp defunct
Hi. On Mon, 2007-02-05 at 19:10 -0600, hackmiester (Hunter Fuller) wrote: > On 4 February 2007, at 07:12, Jiri Slaby wrote: > > > > > Back to C! > > This is a bit off topic, but what does this message mean? Is it > referring to the programming language? It's just saying that the lowlevel assembly stuff succeeded to the point that we got back to compiled C code. > Also, when I swsusp my machine, why does it print "Linu" at the top > of the screen? Not "Linux," but "Linu..." That's Pavel's evil plan to take over the world with a microkernel based version of Linux - he's going to call it Linu :) Regards, Nigel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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, resend] kbuild: improve option checking, Kbuild.include cleanup
kbuild: improve option checking, Kbuild.include cleanup
GNU binutils, root users, tmpfiles, external modules ro builds must
be fixed to do the right thing now.
Cc: Roman Zippel <[EMAIL PROTECTED]>
Cc: Sam Ravnborg <[EMAIL PROTECTED]>
Cc: Horst Schirmeier <[EMAIL PROTECTED]>
Cc: Jan Beulich <[EMAIL PROTECTED]>
Cc: Daniel Drake <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Randy Dunlap <[EMAIL PROTECTED]>
Signed-off-by: Oleg Verych <[EMAIL PROTECTED]>
---
-- all checks by shell united in one macro -- checker-shell;
-- one disposable output sym. link to /dev/null per shell,
thus no racing, `-Z' is removed;
-- modules' build output directory is used, if supplied;
-- every option checking function calls shell wrapper, acquires probe;
-- `echo -e' bashizm substituted (people with sh != bash have distinct
CC options!);
-- some spelling and sense added to the comments;
-- small shuffle of whitespace.
Mostly all people, discussing this back in October are in the Cc list.
Sam Ravnborg have not much time to reply. I've added Roman Zippel, as
a very kind reviewer and commiter of previous fix. Comments and
testing are appreciated. Thanks.
scripts/Kbuild.include | 96 +++--
1 file changed, 53 insertions(+), 43 deletions(-)
Index: linux-2.6.20/scripts/Kbuild.include
===
--- linux-2.6.20.orig/scripts/Kbuild.include2007-02-06 02:12:37.543828750
+0100
+++ linux-2.6.20/scripts/Kbuild.include 2007-02-06 02:14:37.575330250 +0100
@@ -2,5 +2,5 @@
# kbuild: Generic definitions
-# Convinient variables
+# Convenient constants
comma := ,
squote := '
@@ -57,38 +57,44 @@ endef
# See documentation in Documentation/kbuild/makefiles.txt
-# output directory for tests below
-TMPOUT := $(if $(KBUILD_EXTMOD),$(firstword $(KBUILD_EXTMOD))/)
+# checker-shell
+# Usage: option = $(call checker-shell, $(CC)...-o $$OUT, option-ok, otherwise)
+# Exit code chooses option. $$OUT is safe location for needless output.
+define checker-shell
+ $(shell set -e; \
+DIR=$(KBUILD_EXTMOD); \
+cd $${DIR:-$(objtree)}; \
+OUT=$$PWD/..null; \
+\
+ln -s /dev/null $$OUT; \
+if $(1) >/dev/null 2>&1; \
+ then echo "$(2)"; \
+ else echo "$(3)"; \
+fi; \
+rm -f $$OUT)
+endef
# as-option
# Usage: cflags-y += $(call as-option, -Wa$(comma)-isa=foo,)
-
-as-option = $(shell if $(CC) $(CFLAGS) $(1) -Wa,-Z -c -o /dev/null \
--xassembler /dev/null > /dev/null 2>&1; then echo "$(1)"; \
-else echo "$(2)"; fi ;)
+as-option = $(call checker-shell, \
+ $(CC) $(CFLAGS) $(1) -c -xassembler /dev/null -o $$OUT, $(1), $(2))
# as-instr
# Usage: cflags-y += $(call as-instr, instr, option1, option2)
-
-as-instr = $(shell if echo -e "$(1)" | \
- $(CC) $(AFLAGS) -c -xassembler - \
- -o $(TMPOUT)astest.out > /dev/null 2>&1; \
- then rm $(TMPOUT)astest.out; echo "$(2)"; \
- else echo "$(3)"; fi)
+as-instr = $(call checker-shell, \
+ printf "$(1)" | $(CC) $(AFLAGS) -c -xassembler -o $$OUT -, $(2), $(3))
# cc-option
# Usage: cflags-y += $(call cc-option, -march=winchip-c6, -march=i586)
-
-cc-option = $(shell if $(CC) $(CFLAGS) $(1) -S -o /dev/null -xc /dev/null \
- > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi ;)
+cc-option = $(call checker-shell, \
+ $(CC) $(CFLAGS) $(if $(3),$(3),$(1)) -S -xc /dev/null -o $$OUT, $(1), $(2))
# cc-option-yn
# Usage: flag := $(call cc-option-yn, -march=winchip-c6)
-cc-option-yn = $(shell if $(CC) $(CFLAGS) $(1) -S -o /dev/null -xc /dev/null \
-> /dev/null 2>&1; then echo "y"; else echo "n"; fi;)
+cc-option-yn = $(call cc-option, "y", "n", $(1))
# cc-option-align
# Prefix align with either -falign or -malign
cc-option-align = $(subst -functions=0,,\
- $(call cc-option,-falign-functions=0,-malign-functions=0))
+ $(call cc-option,-falign-functions=0,-malign-functions=0))
# cc-version
@@ -98,15 +104,13 @@ cc-version = $(shell $(CONFIG_SHELL) $(s
# cc-ifversion
# Usage: EXTRA_CFLAGS += $(call cc-ifversion, -lt, 0402, -O1)
-cc-ifversion = $(shell if [ $(call cc-version, $(CC)) $(1) $(2) ]; then \
- echo $(3); fi;)
+cc-ifversion = $(shell [ $(call cc-version, $(CC)) $(1) $(2) ] && echo $(3))
# ld-option
# Usage: ldflags += $(call ld-option, -Wl$(comma)--hash-style=both)
-ld-option = $(shell if $(CC) $(1) -nostdlib -xc /dev/null \
--o $(TMPOUT)ldtest.out > /dev/null 2>&1; \
- then rm $(TMPOUT)ldtest.out; echo "$(1)"; \
- else echo "$(2)"; fi)
+ld-option = $(call checker-shell, \
+ $(CC) $(1) -nostdlib -xc /dev/null -o $$OUT, $(1), $(2))
+
+##
-###
# Shorthand for $(Q)$(MAKE) -f scripts/Makefile.build obj=
# Usage:
@@ -114,17 +118,26 @@ ld-option = $(shell if $(CC) $(1) -nostd
build := -f $(if
[patch 1/3, resend] scripts: replace gawk, head, bc with shell, update
scripts: replace gawk, head, bc with shell, update
Replacing overhead of using some (external) programs
instead of good old `sh'.
Cc: Roman Zippel <[EMAIL PROTECTED]>
Cc: Sam Ravnborg <[EMAIL PROTECTED]>
Cc: William Stearns <[EMAIL PROTECTED]>
Cc: Martin Schlemmer <[EMAIL PROTECTED]>
Signed-off-by: Oleg Verych <[EMAIL PROTECTED]>
---
Whitespace cleanup included.
scripts/gen_initramfs_list.sh | 43 +-
scripts/makelst | 34 -
2 files changed, 39 insertions(+), 38 deletions(-)
Index: linux-2.6.20/scripts/makelst
===
--- linux-2.6.20.orig/scripts/makelst 2007-02-06 02:12:38.811908000 +0100
+++ linux-2.6.20/scripts/makelst2007-02-06 02:12:43.688212750 +0100
@@ -1,31 +1,31 @@
-#!/bin/bash
+#!/bin/sh
# A script to dump mixed source code & assembly
# with correct relocations from System.map
-# Requires the following lines in Rules.make.
-# Author(s): DJ Barrow ([EMAIL PROTECTED],[EMAIL PROTECTED])
-#William Stearns <[EMAIL PROTECTED]>
+# Requires the following lines in makefile:
#%.lst: %.c
# $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(CFLAGS_$@) -g -c -o $*.o $<
-# $(TOPDIR)/scripts/makelst $*.o $(TOPDIR)/System.map $(OBJDUMP)
+# $(srctree)/scripts/makelst $*.o $(objtree)/System.map $(OBJDUMP)
#
-#Copyright (C) 2000 IBM Corporation
-#Author(s): DJ Barrow ([EMAIL PROTECTED],[EMAIL PROTECTED])
+# Copyright (C) 2000 IBM Corporation
+# Author(s): DJ Barrow ([EMAIL PROTECTED],[EMAIL PROTECTED])
+#William Stearns <[EMAIL PROTECTED]>
#
-t1=`$3 --syms $1 | grep .text | grep " F " | head -n 1`
+# awk style field access
+field() {
+ shift $1 ; echo $1
+}
+
+t1=`$3 --syms $1 | grep .text | grep -m1 " F "`
if [ -n "$t1" ]; then
- t2=`echo $t1 | gawk '{ print $6 }'`
+ t2=`field 6 $t1`
if [ ! -r $2 ]; then
echo "No System.map" >&2
-t7=0
else
t3=`grep $t2 $2`
-t4=`echo $t3 | gawk '{ print $1 }'`
-t5=`echo $t1 | gawk '{ print $1 }'`
-t6=`echo $t4 - $t5 | tr a-f A-F`
-t7=`( echo ibase=16 ; echo $t6 ) | bc`
+t4=`field 1 $t3`
+t5=`field 1 $t1`
+t6=`printf "%lu" $((0x$t4 - 0x$t5))`
fi
-else
- t7=0
fi
-$3 -r --source --adjust-vma=$t7 $1
+$3 -r --source --adjust-vma=${t6:-0} $1
Index: linux-2.6.20/scripts/gen_initramfs_list.sh
===
--- linux-2.6.20.orig/scripts/gen_initramfs_list.sh 2007-02-06
02:12:38.819908500 +0100
+++ linux-2.6.20/scripts/gen_initramfs_list.sh 2007-02-06 02:12:43.688212750
+0100
@@ -1,5 +1,5 @@
#!/bin/bash
# Copyright (C) Martin Schlemmer <[EMAIL PROTECTED]>
-# Copyright (c) 2006 Sam Ravnborg <[EMAIL PROTECTED]>
+# Copyright (C) 2006 Sam Ravnborg <[EMAIL PROTECTED]>
#
# Released under the terms of the GNU GPL
@@ -18,13 +18,13 @@ Usage:
$0 [-o ] [-u ] [-g ] {-d | } ...
-o Create gzipped initramfs file named using
- gen_init_cpio and gzip
+ gen_init_cpio and gzip
-uUser ID to map to user ID 0 (root).
- is only meaningful if
- is a directory.
+ is only meaningful if
+ is a directory.
-gGroup ID to map to group ID 0 (root).
- is only meaningful if
- is a directory.
+ is only meaningful if
+ is a directory.
File list or directory for cpio archive.
- If is a .cpio file it will be used
+ If is a .cpio file it will be used
as direct input to initramfs.
-d Output the default cpio list.
@@ -37,4 +37,10 @@ EOF
}
+# awk style field access
+# $1 - field number; rest is argument string
+field() {
+ shift $1 ; echo $1
+}
+
list_default_initramfs() {
# echo usr/kinit/kinit
@@ -120,20 +126,15 @@ parse() {
;;
"nod")
- local dev_type=
- local maj=$(LC_ALL=C ls -l "${location}" | \
- gawk '{sub(/,/, "", $5); print $5}')
- local min=$(LC_ALL=C ls -l "${location}" | \
- gawk '{print $6}')
-
- if [ -b "${location}" ]; then
- dev_type="b"
- else
- dev_type="c"
- fi
- str="${ftype} ${name} ${str} ${dev_type} ${maj} ${min}"
+ local dev=`LC_ALL=C ls -l "${location}"`
+ local maj=`field 5 ${dev}`
+ local min=`field 6 ${dev}`
+ maj=${maj%,}
+
+ [ -b "${location}" ] && dev="b" ||
[patch 3/3, resend] kbuild: correctly skip tilded backups in localversion files
kbuild: correctly skip tilded backups in localversion files Tildes as in path as in filenames are handled correctly now: only files, containing tilde '~', are backups, thus are not valid. [KJ]: Definition of `space' was removed, scripts/Kbuild.include has one. That definition was taken right from the GNU make manual, while Kbuild's version is original. Cc: Roman Zippel <[EMAIL PROTECTED]> Cc: Bastian Blank <[EMAIL PROTECTED]> Cc: Sam Ravnborg <[EMAIL PROTECTED]> Signed-off-by: Oleg Verych <[EMAIL PROTECTED]> --- My using of the `sh' rides from willing to have more portable, understandable implementation (and due to GFDL make's docs ;) Original report by Bastian Blank: The following patch fixes the problem that localversion files where ignored if the tree lives in a path which contains a ~. It changes the test to apply to the filename only. Debian allows versions which contains ~ in it. The upstream part of the version is in the directory name of the build tree and we got weird results because the localversion files was just got ignored in this case. Makefile | 17 ++--- 1 file changed, 6 insertions(+), 11 deletions(-) Index: linux-2.6.20/Makefile === --- linux-2.6.20.orig/Makefile 2007-02-06 02:12:35.703713750 +0100 +++ linux-2.6.20/Makefile 2007-02-06 02:17:06.612644500 +0100 @@ -777,5 +777,5 @@ $(vmlinux-dirs): prepare scripts # $(localver-full) #$(localver) -# localversion* (all localversion* files) +# localversion* (files without backups, containing '~') # $(CONFIG_LOCALVERSION) (from kernel config setting) #$(localver-auto) (only if CONFIG_LOCALVERSION_AUTO is set) @@ -788,15 +788,10 @@ $(vmlinux-dirs): prepare scripts # scripts/setlocalversion and add the appropriate checks as needed. -nullstring := -space := $(nullstring) # end of line +pattern = ".*/localversion[^~]*" +string = $(shell cat /dev/null \ + `find $(objtree) $(srctree) -maxdepth 1 -regex $(pattern) | sort`) -___localver = $(objtree)/localversion* $(srctree)/localversion* -__localver = $(sort $(wildcard $(___localver))) -# skip backup files (containing '~') -_localver = $(foreach f, $(__localver), $(if $(findstring ~, $(f)),,$(f))) - -localver = $(subst $(space),, \ - $(shell cat /dev/null $(_localver)) \ - $(patsubst "%",%,$(CONFIG_LOCALVERSION))) +localver = $(subst $(space),, $(string) \ + $(patsubst "%",%,$(CONFIG_LOCALVERSION))) # If CONFIG_LOCALVERSION_AUTO is set scripts/setlocalversion is called -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 0/3, resend] scripts, kbuild updates/fixes (against 2.6.20)
Due to almost zer0 activity, this may be last attempt. -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 update] ieee1394: fix host device registering when nodemgr disabled
Since my commit 8252bbb1363b7fe963a3eb6f8a36da619a6f5a65 in 2.6.20-rc1,
host devices have a dummy driver attached. Alas the driver was not
registered before use if ieee1394 was loaded with disable_nodemgr=1.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
Update: - work without extern variables,
- better error checks,
- add missing driver_unregister.
drivers/ieee1394/nodemgr.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
Index: linux-2.6.20-rc5/drivers/ieee1394/nodemgr.c
===
--- linux-2.6.20-rc5.orig/drivers/ieee1394/nodemgr.c
+++ linux-2.6.20-rc5/drivers/ieee1394/nodemgr.c
@@ -258,7 +258,6 @@ static struct device_driver nodemgr_mid_
struct device nodemgr_dev_template_host = {
.bus= _bus_type,
.release= nodemgr_release_host,
- .driver = _mid_layer_driver,
};
@@ -1850,22 +1849,33 @@ int init_ieee1394_nodemgr(void)
error = class_register(_ne_class);
if (error)
- return error;
-
+ goto fail_ne;
error = class_register(_ud_class);
- if (error) {
- class_unregister(_ne_class);
- return error;
- }
+ if (error)
+ goto fail_ud;
+
+ /* don't show this driver if nodemgr is off (disable_nodmgr=1) */
+ nodemgr_dev_template_host.driver = _mid_layer_driver;
+
error = driver_register(_mid_layer_driver);
+ if (error)
+ goto fail_ml;
+
hpsb_register_highlevel(_highlevel);
return 0;
+
+fail_ml:
+ class_unregister(_ud_class);
+fail_ud:
+ class_unregister(_ne_class);
+fail_ne:
+ return error;
}
void cleanup_ieee1394_nodemgr(void)
{
hpsb_unregister_highlevel(_highlevel);
-
+ driver_unregister(_mid_layer_driver);
class_unregister(_ud_class);
class_unregister(_ne_class);
}
--
Stefan Richter
-=-=-=== --=- --==-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: v2.6.20-rt1, yum/rpm
The /proc/interrupts timer entry is dangling a little. With PREEMPT_RT the entry doesn't get updated .. My system after two hours uptime, CPU0 CPU1 0: 56 0 IO-APIC-edge timer 1: 2 0 IO-APIC-edge i8042 4: 1450 0 IO-APIC-edge serial 6: 3 0 IO-APIC-edge floppy 8: 0 0 IO-APIC-edge rtc 9: 0 0 IO-APIC-fasteoi acpi 12: 4 0 IO-APIC-edge i8042 14: 824890 0 IO-APIC-edge ide0 17:182 0 IO-APIC-fasteoi HDA Intel 20: 0 0 IO-APIC-fasteoi uhci_hcd:usb2 21: 0 0 IO-APIC-fasteoi libata, ehci_hcd:usb1, uhci_hcd:usb4 22: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 23: 7515 0 IO-APIC-fasteoi uhci_hcd:usb5, eth0 NMI: 0 0 LOC:17496351749614 ERR: 0 Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hwsusp defunct
On 4 February 2007, at 07:12, Jiri Slaby wrote: Back to C! This is a bit off topic, but what does this message mean? Is it referring to the programming language? Also, when I swsusp my machine, why does it print "Linu" at the top of the screen? Not "Linux," but "Linu..." -- hackmiester (Hunter Fuller) who can help me ? i'm french and i don't know irc can't help you with the being french part, you are screwed their mate Phone Voice: +1 251 589 6348 Fax: Call the voice number and ask. Email General chat: [EMAIL PROTECTED] Large attachments: [EMAIL PROTECTED] SPS-related stuff: [EMAIL PROTECTED] IM AIM: hackmiester1337 Skype: hackmiester31337 YIM: hackm1ester Gtalk: hackmiester MSN: [EMAIL PROTECTED] Xfire: hackmiester - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, Feb 05, 2007 at 11:21:34PM +, David Woodhouse wrote: > But Alan makes a reasonable suggestion -- we could work around this in > the tools too. I wouldn't call it "work around this" in the tools. It's a useful feature we can add in the tools for developers who aren't men enough to use "sed/grep" pipelines. :-) But I have to agree with Linus here that we should be optimizing the tools for people who know how to compile the kernel, but who aren't necessarily familiar with all of the hidden dependencies in the literally hundreds of config options in the kernel tree. In reality, you want to make it easy to turn on *or* off any arbitrary config option, and to understand what you need to do so you can turn an arbitrary config option on or off. If that means tools enhancements, so be it. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Powerpc move of_irq_to_resource from prom.h to prom_parse.c
Powerpc move of_irq_to_resource from prom.h to prom_parse.c
Sorry for the lack of information, it got cut in the previous messages.
Let's start all over again :
In the powerpc architecture, of_irq_to_resource, currently sitting in
prom.h, needs irq_of_parse_and_map and NO_IRQ from asm-powerpc/irq.h.
The solution suggested by Benjamin Herrenschmidt is to move it to
arch/powerpc/kernel/prom_parse.c.
It applies on 2.6.20.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
--- a/arch/powerpc/kernel/prom_parse.c
+++ b/arch/powerpc/kernel/prom_parse.c
@@ -1003,3 +1003,18 @@ int of_irq_map_one(struct device_node *device, int
index, struct of_irq *out_irq
return res;
}
EXPORT_SYMBOL_GPL(of_irq_map_one);
+
+int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
+{
+ int irq = irq_of_parse_and_map(dev, index);
+
+ /* Only dereference the resource if both the
+* resource and the irq are valid. */
+ if (r && irq != NO_IRQ) {
+ r->start = r->end = irq;
+ r->flags = IORESOURCE_IRQ;
+ }
+
+ return irq;
+}
+EXPORT_SYMBOL_GPL(of_irq_to_resource);
--- a/include/asm-powerpc/prom.h
+++ b/include/asm-powerpc/prom.h
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
/* Definitions used by the flattened device tree */
#define OF_DT_HEADER 0xd00dfeed /* marker */
@@ -334,20 +335,8 @@ extern int of_irq_map_one(struct device_node *device, int
index,
struct pci_dev;
extern int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq);
-static inline int of_irq_to_resource(struct device_node *dev, int index,
struct resource *r)
-{
- int irq = irq_of_parse_and_map(dev, index);
-
- /* Only dereference the resource if both the
-* resource and the irq are valid. */
- if (r && irq != NO_IRQ) {
- r->start = r->end = irq;
- r->flags = IORESOURCE_IRQ;
- }
-
- return irq;
-}
-
+extern int of_irq_to_resource(struct device_node *dev, int index,
+ struct resource *r);
#endif /* __KERNEL__ */
#endif /* _POWERPC_PROM_H */
--
Mathieu Desnoyers
Computer Engineering Graduate Student, École Polytechnique de Montréal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ohci1394 broke 2.6.19 -> 2.6.20-rc1
On 2/5/07, Stefan Richter <[EMAIL PROTECTED]> wrote: It's my oversight, see patch. Yes, this fixes things. Thanks! -- Robert Crocombe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: forcedeth problems on 2.6.20-rc6-mm3
On Mon, 05 Feb 2007 18:35:06 -0600 Robert Hancock <[EMAIL PROTECTED]> wrote: > Daniel Barkalow wrote: > > On Sun, 4 Feb 2007, Robert Hancock wrote: > > > >> Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to > >> 2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get > >> received and so the machine can't get an IP address. I tried reverting all > >> the > >> -mm changes to drivers/net/forcedeth.c, which didn't help. The network > >> controller shares an IRQ with the USB OHCI controller which is receiving > >> interrupts, so it doesn't seem like an interrupt routing problem, though I > >> suppose something wierd could be happening there. > > > > IIRC, forcedeth tries to use MSI by default. Perhaps the hardware is using > > it, but the kernel thinks enabling it didn't work? I think there's a > > module option for forcedeth to disable MSI, which might be worth a try to > > see if it has any effect. > > I must have messed something up when testing before - reverting to > forcedeth.c from 2.6.20-rc6 does indeed fix the problem. And it doesn't > seem like no packets at all are received with the -mm3 version (driver > version 0.60), either - if I do a tcpdump I can get Ethernet packets > showing up, but I can't ping my router so it seems like something isn't > getting through properly. With the 2.6.20-rc6 version (driver version > 0.59) it works fine. I switched back and forth between versions and this > seems repeatable. > > I don't think it's MSI related, the CK804 version of these controllers > doesn't support MSI and the driver shouldn't be trying to use it. I > tried the MSI and MSI-X disable options on the 0.60 driver, but that > didn't help. > OK, thanks. Jeff, please note that the forcedeth changes in git-netdev-all have a problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Cbe-oss-dev] [RFC, PATCH] CELL PPU Oprofile SPU profiling updated patch
On Mon, 2007-02-05 at 16:28 -0800, Carl Love wrote: > This is the first update to the patch previously posted by Maynard > Johnson as "PATCH 4/4. Add support to OProfile for profiling CELL". > > There are still a few items from the comments being discussed > specifically how to profile the dynamic code for the SPFS context > switch > code and how to deal with dynamic code stubs for library support. Our > proposal is to assign the samples from the SPFS and dynamic library > code > to an anonymous sample bucket. The support for properly handling the > symbol extraction in these cases would be deferred to a later SDK. > > There is also a bug in profiling overlay code that we are > investigating. > > Subject: Add support to OProfile for profiling Cell BE SPUs > > From: Maynard Johnson <[EMAIL PROTECTED]> > > This patch updates the existing arch/powerpc/oprofile/op_model_cell.c > to add in the SPU profiling capabilities. In addition, a 'cell' > subdirectory > was added to arch/powerpc/oprofile to hold Cell-specific SPU profiling > code. > > Signed-off-by: Carl Love <[EMAIL PROTECTED]> > Signed-off-by: Maynard Johnson <[EMAIL PROTECTED]> Patch got mangled. You seem to be using evolution, make sure you use the "Preformat" style when posting a patch. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2 of 4] Introduce i386 fibril scheduling
On Mon, Feb 05, 2007 at 04:27:44PM -0800, Scot McKinley wrote: > Finally, it is agreed that neg-errno is a much better approach for the > return code. The threading/concurrency issues associated w/ the current > unix errno has always been buggy area for Oracle Networking code. As Scot knows, when Oracle started using the current io_submit(2) and io_getevents(2), -errno was a big win. Joel -- "Born under a bad sign. I been down since I began to crawl. If it wasn't for bad luck, I wouldn't have no luck at all." Joel Becker Principal Software Developer Oracle E-mail: [EMAIL PROTECTED] Phone: (650) 506-8127 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ohci1394 broke 2.6.19 -> 2.6.20-rc1
I wrote: > @@ -1132,6 +1132,7 @@ static int __init ieee1394_init(void) > } > } > > + ret = driver_register(_mid_layer_driver); > ret = class_register(_host_class); > if (ret < 0) > goto release_all_bus; I think I make that a WARN_ON(driver_register(_mid_layer_driver)); -- Stefan Richter -=-=-=== --=- --==- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2 of 4] Introduce i386 fibril scheduling
From: Scot McKinley <[EMAIL PROTECTED]> Date: Mon, 05 Feb 2007 16:27:44 -0800 > As Joel mentioned earlier, from an Oracle perspective, one of the key > things we are looking for is a nice clean *common* wait point. How much investigation have the Oracle folks (besides Zach :-) done into Evgeniy's kevent interfaces and how much feedback have they given to him. I know it sounds like I'm being a pain in the ass, but it saddens me that there is this whole large body of work implemented to solve a problem, the maintainer keeps posting patch sets and the whole discussions has gone silent. I'd be quiet if there were some well formulated objections to his work being posted, but people are posting nothing. So either it's a perfect API or people aren't giving it the attention and consideration it deserves. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][1/5] floppy.c: Initial (partial) CodingStyle cleanup
On Tue, 6 Feb 2007 00:28:50 +0100 Jesper Juhl wrote:
>
> This is a basic CodingStyle cleanup for drivers/block/floppy.c
>
> There are no functional changes in this patch.
>
> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
> ---
>
> floppy.c | 203 -
> 1 file changed, 94 insertions(+), 109 deletions(-)
>
> --- linux-2.6.20-orig/drivers/block/floppy.c 2007-02-04 19:44:54.0
> +0100
> +++ linux-2.6.20/drivers/block/floppy.c 2007-02-05 23:08:39.0
> +0100
> @@ -1252,8 +1258,8 @@
> DPRINT("Invalid data rate for perpendicular mode!\n");
> cont->done(0);
> FDCS->reset = 1;/* convenient way to return to
> - * redo without to much hassle
> (deep
> - * stack et al. */
> + * redo without to much hassle
~~> too
> + * (deep stack et al. */
> return;
> }
> } else
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Missing include in include/asm-powerpc/prom.h
Mathieu Desnoyers writes: > * Benjamin Herrenschmidt ([EMAIL PROTECTED]) wrote: > > On Mon, 2007-02-05 at 09:29 -0500, Mathieu Desnoyers wrote: > > > Missing include in include/asm-powerpc/prom.h > > > > > > include/asm-powerpc/prom.h needs to include asm/irq.h because it uses > > > irq_of_parse_and_map and NO_IRQ. It applies on 2.6.20. > > > > I'd rather not do that better to move of_irq_to_resource() to > > prom_parse.c > > > > Thanks, this patch should apply on top of the previous patch in this thread. Do you actually want this patch to go upstream? Because if you do, that really doesn't cut it as a patch description. Please look at http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt and resubmit as one patch with an informative description. Thanks, Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] CELL PPU Oprofile SPU profiling updated patch
Carl Love writes: > This is the first update to the patch previously posted by Maynard > Johnson as "PATCH 4/4. Add support to OProfile for profiling CELL". Is it really necessary to keep posting all these messages to three lists? Wouldn't cbe-oss-dev be sufficient? Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH[RFC] kill sysrq-u (emergency remount r/o)
Hi. On Mon, 2007-02-05 at 18:32 +0100, Christoph Hellwig wrote: > Hi there, > > in two recent discussions (file_list_lock scalability and remount r/o > on suspend) I stumbled over this emergency remount feature. It's not > actually useful because it tries a potentially dangerous remount > despite writers still beeing in progress, which we can't get rid. > > I've attached one patch in this mail that simply kills the > functionality, and in a reply to this mail I'll send a second one > that keeps the sysrq functionality, but removes the force argument > from do_remount_sb that overrides the still busy check. This version > is currently not useful, but makes a lot of sense once Dave Hansens > per-mountpoint r/o patches get in, as we can check for a real write > in progress instead of simply a file opened with write permission. > > Any ideas and comments? I'm not really keen - it sometimes get's invoked here and by others in a sysrq-s sysrq-u sysrq-b sequence (sync, unmount, reboot) in a context where things have gone south (particularly if there's some process stuck). In that context it helps make filesystems cleaner than they'd otherwise be, and the fact that writers might still be in progress is irrelevant because the next keypress is going to reboot anyway. Ok. I'll admit to being a heretic ext3 user, loving not having to fsck after the above and still getting zero corruption as a result. Regards, Nigel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 0/28] Patches to pass vfsmount to LSM inode security hooks
On Monday 05 February 2007 10:44, Christoph Hellwig wrote: > Just FYI: Al was very opposed to the idea of passing the vfsmount to > the vfs_ helpers, so you should discuss this with him. The vfs_ helper functions are the ones calling the lsm hooks in many cases. Any lsm that makes pathname based decisions will need both the dentry and vfsmount for figuring out a file's pathname. I don't see a better way of passing that information to the lsm hooks than passing it through the vfs_ helpers. Thanks, Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ohci1394 broke 2.6.19 -> 2.6.20-rc1
On 6 Feb, Stefan Richter wrote:
> Robert Crocombe wrote:
>> moving to anything more recent than 2.6.19
>> means ohci1394 is non-functional (no 1394 hosts are detected) and the
>> module cannot be removed.
Not using the option disable_nodemgr=1 should avoid the bug.
>> I have narrowed it down to 2.6.19 works, 2.6.20-rc1 doesn't. Lots of detail
>> at:
>>
>> http://bugzilla.kernel.org/show_bug.cgi?id=7942
>
> I get a spinlock lockup on 2.6.20-rc6 + some 1394 updates with a similar
> trace to what Robert posted at bugzilla --- *if* I use ieee1394's option
> disable_nodemgr=1. (Never used it before.) The key appears to be how
> hpsb_alloc_host interacts with the driver core. I don't know if hosts.c
> is at fault or some change in the driver core.
It's my oversight, see patch.
From: Stefan Richter <[EMAIL PROTECTED]>
Subject: ieee1394: fix host device registering when nodemgr disabled
Since my commit 8252bbb1363b7fe963a3eb6f8a36da619a6f5a65 in 2.6.20-rc1,
host devices have a dummy driver attached. Alas the driver was not
registered before use if ieee1394 was loaded with disable_nodemgr=1.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/ieee1394/ieee1394_core.c |1 +
drivers/ieee1394/nodemgr.c |3 +--
drivers/ieee1394/nodemgr.h |4 +---
3 files changed, 3 insertions(+), 5 deletions(-)
Index: linux-2.6.20-rc6/drivers/ieee1394/ieee1394_core.c
===
--- linux-2.6.20-rc6.orig/drivers/ieee1394/ieee1394_core.c 2007-02-03
18:04:50.0 +0100
+++ linux-2.6.20-rc6/drivers/ieee1394/ieee1394_core.c 2007-02-06
01:28:04.0 +0100
@@ -1132,6 +1132,7 @@ static int __init ieee1394_init(void)
}
}
+ ret = driver_register(_mid_layer_driver);
ret = class_register(_host_class);
if (ret < 0)
goto release_all_bus;
Index: linux-2.6.20-rc6/drivers/ieee1394/nodemgr.c
===
--- linux-2.6.20-rc6.orig/drivers/ieee1394/nodemgr.c2007-01-27
14:07:00.0 +0100
+++ linux-2.6.20-rc6/drivers/ieee1394/nodemgr.c 2007-02-06 01:29:21.0
+0100
@@ -249,7 +249,7 @@ static struct device nodemgr_dev_templat
* useful drivers for them yet, and there would be a deadlock possible if the
* driver core scans the host device while the host's low-level driver (i.e.
* the host's parent device) is being removed. */
-static struct device_driver nodemgr_mid_layer_driver = {
+struct device_driver nodemgr_mid_layer_driver = {
.bus= _bus_type,
.name = "nodemgr",
.owner = THIS_MODULE,
@@ -1857,7 +1857,6 @@ int init_ieee1394_nodemgr(void)
class_unregister(_ne_class);
return error;
}
- error = driver_register(_mid_layer_driver);
hpsb_register_highlevel(_highlevel);
return 0;
}
Index: linux-2.6.20-rc6/drivers/ieee1394/nodemgr.h
===
--- linux-2.6.20-rc6.orig/drivers/ieee1394/nodemgr.h2007-01-27
14:07:00.0 +0100
+++ linux-2.6.20-rc6/drivers/ieee1394/nodemgr.h 2007-02-06 01:30:27.0
+0100
@@ -181,10 +181,8 @@ int nodemgr_for_each_host(void *__data,
int init_ieee1394_nodemgr(void);
void cleanup_ieee1394_nodemgr(void);
-/* The template for a host device */
+extern struct device_driver nodemgr_mid_layer_driver;
extern struct device nodemgr_dev_template_host;
-
-/* Bus attributes we export */
extern struct bus_attribute *const fw_bus_attrs[];
#endif /* _IEEE1394_NODEMGR_H */
--
Stefan Richter
-=-=-=== --=- --==-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Compressed ia32 ELF file generation for loading by Gujin 1/3
First of all, if sending attached patches, *MAKE SURE* they're text/plain. diff -uprN -X linux-2.6.20/Documentation/dontdiff linux-2.6.20/arch/i386/kernel/setup.c linux-2.6.20-gujin/arch/i386/kernel/setup.c --- linux-2.6.20/arch/i386/kernel/setup.c 2007-02-04 18:44:54.0 + +++ linux-2.6.20-gujin/arch/i386/kernel/setup.c 2007-02-05 21:27:01.0 + @@ -579,6 +579,19 @@ void __init setup_arch(char **cmdline_p) strlcpy(command_line, saved_command_line, COMMAND_LINE_SIZE); *cmdline_p = command_line; + /* +* If the command line begin with '/', it is the filename of the +* kernel file - like a shell command line. That can be used to +* deduce where root was located when the kernel was compiled, +* inside a directory of root named /boot, inside a small partition +* mounted on a directory of root named /boot or in the root +* directory itself. +*/ + if (**cmdline_p == '/') + while (**cmdline_p != ' ' && **cmdline_p != '\t' + && **cmdline_p != '\n' && **cmdline_p != '\0') + ++*cmdline_p; + max_low_pfn = setup_memory(); /* The standard way to do this is to have a command line argument named BOOT_IMAGE (as in BOOT_IMAGE=/foo/bar/baz). There is no reason to do this differently from every other bootloader. Why build the real-mode code as part of the kernel binary? If you have to reference kernel symbols, you can do that with the -R option to ld. Bundling it into the kernel binary just to then extract it later is silly at best. @@ -1106,6 +1179,9 @@ help: @echo 'Other generic targets:' @echo ' all - Build all targets marked with [*]' @echo '* vmlinux - Build the bare kernel' + @echo " /boot/linux-$(KERNELRELEASE).kgz - create a boot kernel for the Gujin bootloader" + @echo ' /boot/linux.kgz ROOT=/dev/hda1 - do not autodetect root filesystem at boot time' + @echo ' /boot/linux.kgz ROOT=auto- root filesystem from current /proc/cmdline' @echo '* modules - Build all modules' @echo ' modules_install - Install all modules to INSTALL_MOD_PATH (default: /)' @echo ' dir/- Build all files in dir and below' This doesn't exactly fit very well the standard pattern. Something like make gujin TARGET=... would be more like it. Given how many of your files are highly Gujin-specific, and have generic names, please put them in a subdirectory (e.g. arch/i386/boot/gujin/). -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: forcedeth problems on 2.6.20-rc6-mm3
Daniel Barkalow wrote: On Sun, 4 Feb 2007, Robert Hancock wrote: Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to 2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get received and so the machine can't get an IP address. I tried reverting all the -mm changes to drivers/net/forcedeth.c, which didn't help. The network controller shares an IRQ with the USB OHCI controller which is receiving interrupts, so it doesn't seem like an interrupt routing problem, though I suppose something wierd could be happening there. IIRC, forcedeth tries to use MSI by default. Perhaps the hardware is using it, but the kernel thinks enabling it didn't work? I think there's a module option for forcedeth to disable MSI, which might be worth a try to see if it has any effect. I must have messed something up when testing before - reverting to forcedeth.c from 2.6.20-rc6 does indeed fix the problem. And it doesn't seem like no packets at all are received with the -mm3 version (driver version 0.60), either - if I do a tcpdump I can get Ethernet packets showing up, but I can't ping my router so it seems like something isn't getting through properly. With the 2.6.20-rc6 version (driver version 0.59) it works fine. I switched back and forth between versions and this seems repeatable. I don't think it's MSI related, the CK804 version of these controllers doesn't support MSI and the driver shouldn't be trying to use it. I tried the MSI and MSI-X disable options on the 0.60 driver, but that didn't help. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.19.2] r8169: support RTL8169SC/8110SC
? <[EMAIL PROTECTED]> :
[...]
> >>static struct pci_device_id rtl8169_pci_tbl[] = {
> >>- { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8129), 0, 0, RTL_CFG_0 },
> >>- { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8136), 0, 0, RTL_CFG_2 },
> >>- { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8167), 0, 0, RTL_CFG_0 },
> >>- { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8168), 0, 0, RTL_CFG_2 },
> >>- { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8169), 0, 0, RTL_CFG_0 },
> >>- { PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4300), 0, 0, RTL_CFG_0 },
> >>- { PCI_DEVICE(0x1259, 0xc107), 0, 0, RTL_CFG_0 },
> >>- { PCI_DEVICE(0x16ec, 0x0116), 0, 0, RTL_CFG_0 },
> >>- { PCI_VENDOR_ID_LINKSYS, 0x1032,
> >>- PCI_ANY_ID, 0x0024, 0, 0, RTL_CFG_0 },
> >>+ { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8169), },
> >>+ { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8167), },
> >>
> >>
> >
> >The current driver is intended to handle the whole set of PCI IDs
> >which would be removed by the patch. Thoug some combination of
> >chipset and motherboard do not work as expected, the gigabit
> >chipsets have been reported to work.
> >
> >Please elaborate if there is a good reason to remove any ID.
> >
> >
> ANS:
> I have explained my point about this in last question. This driver is
> developed for Realtek PCI gigabit ethernet controllers. Although some
> vendors may use Realtek solutions with their own PCI DIDs and VIDs, they
> should customize this driver and maintained the customized driver on
> their own.
Vendors will change the PCI ID because they like to see their name in
the nifty hardware GUI under Windows. The brave ones will mess with the
VPD (before or after they vandalize the ACPI tables, at their option).
Eventually they will copy an outdated version of your driver on their site
with the updated ID. Given the tight margin on these kind of mass-volume
product, I would not expect vendors to do more for their customers who
use Linux.
If your hardware changes significantly, it may make sense to use a new,
different driver. Otherwise, as long as the changes are minor, a single
in-kernel driver which works out of the box for most users/vendors offers
the best coverage. It should not be neglected.
So far, I have only seen minor differences between r8101-1.001.00,
r8168-8.001.00 and r8169-6.001.00. The mac init sequence is not pretty
to unify but the drivers stay mostly the same. There even is a floating
patch for MSI support which seems manageable within a single driver.
Of course it depends a lot on the kind of changes that you envision for
the driver(s).
[...]
> >>RxMaxSize = 0xDA,
> >>CPlusCmd = 0xE0,
> >>IntrMitigate = 0xE2,
> >>@@ -287,11 +291,10 @@ enum RTL8169_register_content {
> >>RxOK = 0x01,
> >>
> >>/* RxStatusDesc */
> >>- RxFOVF = (1 << 23),
> >>- RxRWT = (1 << 22),
> >>- RxRES = (1 << 21),
> >>- RxRUNT = (1 << 20),
> >>- RxCRC = (1 << 19),
> >>+ RxRES = 0x0020,
> >>+ RxCRC = 0x0008,
> >>+ RxRUNT = 0x0010,
> >>+ RxRWT = 0x0040,
> >>
> >>
> >
> >This part removes RxFOVF. Please elaborate if there is a reason
> >to do so.
> >
> >
>
> ANS:
> According to the spec of RTL8110SC, bit 23 and bit 24 are reserved in
> the 1st double word of rx status descriptor. Therefore, I delete it.
The bits are fine for the old Gigabit 8169 though, aren't they ?
[...]
> >Two points here:
> >1. the driver uniformly uses u{8/16/32} types. Please follow the current
> > style and avoid to add uint{8/16/32}_t things.
> >2. does this new field bring something that struct net_device.dev_addr
> > does not ?
> >
> >
> >
> ANS:
> I reference the source code of e1000.c, which is currently existing in
> Linux kernel. I think it uses u{8/16/32} and the new field.
The e1000 driver has an interesting history. It is strongly suggested
to ponder several drivers to figure some good practices. Please see for
instance tg3.c, b44.c, sky2.c or any recent driver in drivers/net.
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2 of 4] Introduce i386 fibril scheduling
On Mon, 5 Feb 2007, Davide Libenzi wrote: > On Mon, 5 Feb 2007, Linus Torvalds wrote: > > > Indeed. One word is *exactly* what a normal system call returns too. > > > > That said, normally we have a user-space library layer to turn that into > > the "errno + return value" thing, and in the case of async() calls we > > very basically wouldn't have that. So either: > > > > - we'd need to do it in the kernel (which is actually nasty, since > >different system calls have slightly different semantics - some don't > >return any error value at all, and negative numbers are real numbers) > > > > - we'd have to teach user space about the "negative errno" mechanism, in > >which case one word really is alwats enough. > > > > Quite frankly, I much prefer the second alternative. The "negative errno" > > thing has not only worked really really well inside the kernel, it's so > > obviously 100% superior to the standard UNIX "-1 + errno" approach that > > it's not even funny. > > Currently it's in the syscall wrapper. Couldn't we have it in the > asys_teardown_stack() stub? Eeeek, that was something *really* stupid I said :D - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
