Re: [patch] mtrr: fix issues with large addresses

2007-02-05 Thread Andi Kleen
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

2007-02-05 Thread Andi Kleen
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&sid=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.

2007-02-05 Thread Ingo Molnar

* 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

2007-02-05 Thread Peter Zijlstra
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

2007-02-05 Thread Eric W. Biederman
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

2007-02-05 Thread Manu Abraham

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&DEV_4E35&SUBSYS_00311822&REV_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

2007-02-05 Thread Grant Grundler
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&DEV_4E35&SUBSYS_00311822&REV_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

2007-02-05 Thread Pierre Ossman
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

2007-02-05 Thread Vivek Goyal
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!

2007-02-05 Thread Greg KH
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!

2007-02-05 Thread Greg KH
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

2007-02-05 Thread H. Peter Anvin

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

2007-02-05 Thread H. Peter Anvin

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

2007-02-05 Thread Vivek Goyal
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

2007-02-05 Thread Manu Abraham

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&DEV_4E35&SUBSYS_00311822&REV_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

2007-02-05 Thread Greg KH
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

2007-02-05 Thread Matt Mackall
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

2007-02-05 Thread H. Peter Anvin

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

2007-02-05 Thread Gene Heskett
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(&floppy_device[drive].dev,&dev_attr_cmos);
>+  err = device_create_file(&floppy_device[drive].dev, 
>&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

2007-02-05 Thread Matt Mackall
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.

2007-02-05 Thread David M. Lloyd
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)

2007-02-05 Thread Theodore Tso
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

2007-02-05 Thread Nick Piggin
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

2007-02-05 Thread Nick Piggin
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

2007-02-05 Thread Andrew Morton
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

2007-02-05 Thread Andrew Morton
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

2007-02-05 Thread Vivek Goyal
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!

2007-02-05 Thread Neil Brown
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(&conf->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, &sh->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

2007-02-05 Thread Stephen Rothwell
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

2007-02-05 Thread Manu Abraham

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

2007-02-05 Thread Rusty Russell
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?

2007-02-05 Thread Eric Sandeen
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

2007-02-05 Thread Grant Grundler
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

2007-02-05 Thread Grant Grundler
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

2007-02-05 Thread Zachary Amsden

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

2007-02-05 Thread Nick Piggin
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!

2007-02-05 Thread Andrew Morton
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

2007-02-05 Thread Rusty Russell
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

2007-02-05 Thread Roland McGrath
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

2007-02-05 Thread Zachary Amsden

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

2007-02-05 Thread Zachary Amsden
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, &vmi_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

2007-02-05 Thread Andrew Morton
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

2007-02-05 Thread Zachary Amsden
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

2007-02-05 Thread Zachary Amsden
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);\
+   paravirt_map

[PATCH 8/11] Add a CPU KHZ calibration function to paravirt-ops

2007-02-05 Thread Zachary Amsden
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

2007-02-05 Thread Zachary Amsden
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

2007-02-05 Thread Zachary Amsden
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 *)®s->esp;
-   else
-   sp = (unsigned long *)regs->esp;
+   unsigned long *sp = (unsigned long *)®s->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

2007-02-05 Thread Zachary Amsden
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(&kretprobe_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

2007-02-05 Thread Zachary Amsden
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

2007-02-05 Thread Zachary Amsden
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(&xtime_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 = &minolduid,
.extra2 = &maxolduid,
},
-#ifdef CONFIG_S390
-#ifdef CONFIG_MATHEMU
-   {
-   .ctl_name   = KERN_IEEE_EMULATION_WARNINGS,
-   .procname   = "ieee_emulation_warnings",
-   .data   = &sysctl_ieee_emulation_warnings,
-   .maxlen = sizeof(int),
-   .mode   = 0644,
-   .proc_handler   = &proc_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   = &proc_dointvec,
+   },
+#endif
+#endif
+#ifdef CONFIG_S390
+#ifdef CONFIG_MATHEMU
+   {
+   .ctl_name   = KERN_IEEE_EMULATION_WARNINGS,
+   .procname   = "ieee_emulation_warnings",
+   .data   = &sysctl_ieee_emulation_warnings,
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = &proc_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

2007-02-05 Thread Zachary Amsden
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 vm

[PATCH 1/11] Make hrtimers friendly to vmi

2007-02-05 Thread Zachary Amsden
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

2007-02-05 Thread Zachary Amsden
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

2007-02-05 Thread Wu, Bryan
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
+
+   root

Re: Regression in kernel linux-2.6.20-rc1/2: Problems with poweroff

2007-02-05 Thread Adrian Bunk
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

2007-02-05 Thread Len Brown
> 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

2007-02-05 Thread Andreas Gruenbacher
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

2007-02-05 Thread Wu, Bryan
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

2007-02-05 Thread Wu, Bryan
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 http://blackfin.ucl

wbsd: IRQ handler type mismatch

2007-02-05 Thread Robert Hancock
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()

2007-02-05 Thread Andrew Morton
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()

2007-02-05 Thread erich

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()

2007-02-05 Thread Robert Hancock
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

2007-02-05 Thread Aubrey Li

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

2007-02-05 Thread 許恆嘉
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 net_d

Re: [RFC 0/28] Patches to pass vfsmount to LSM inode security hooks

2007-02-05 Thread Andreas Gruenbacher
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

2007-02-05 Thread Nick Piggin
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

2007-02-05 Thread Andreas Gruenbacher
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)

2007-02-05 Thread Wu, Bryan
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  |9

Re: [patch 9/9] mm: fix pagecache write deadlocks

2007-02-05 Thread Nick Piggin
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

2007-02-05 Thread Mike Frysinger

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&release_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

2007-02-05 Thread Grzegorz Kulewski

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 vers

Re: [PATCH 1/3] Blackfin: architecture patch against Linux kernel 2.6.20

2007-02-05 Thread Randy Dunlap
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]

2007-02-05 Thread Mike Frysinger
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

2007-02-05 Thread Nigel Cunningham
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

2007-02-05 Thread Oleg Verych
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

2007-02-05 Thread Oleg Verych
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" || dev="

[patch 3/3, resend] kbuild: correctly skip tilded backups in localversion files

2007-02-05 Thread Oleg Verych
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)

2007-02-05 Thread Oleg Verych
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

2007-02-05 Thread Stefan Richter
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= &ieee1394_bus_type,
.release= nodemgr_release_host,
-   .driver = &nodemgr_mid_layer_driver,
 };
 
 
@@ -1850,22 +1849,33 @@ int init_ieee1394_nodemgr(void)
 
error = class_register(&nodemgr_ne_class);
if (error)
-   return error;
-
+   goto fail_ne;
error = class_register(&nodemgr_ud_class);
-   if (error) {
-   class_unregister(&nodemgr_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 = &nodemgr_mid_layer_driver;
+
error = driver_register(&nodemgr_mid_layer_driver);
+   if (error)
+   goto fail_ml;
+
hpsb_register_highlevel(&nodemgr_highlevel);
return 0;
+
+fail_ml:
+   class_unregister(&nodemgr_ud_class);
+fail_ud:
+   class_unregister(&nodemgr_ne_class);
+fail_ne:
+   return error;
 }
 
 void cleanup_ieee1394_nodemgr(void)
 {
hpsb_unregister_highlevel(&nodemgr_highlevel);
-
+   driver_unregister(&nodemgr_mid_layer_driver);
class_unregister(&nodemgr_ud_class);
class_unregister(&nodemgr_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

2007-02-05 Thread Daniel Walker

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

2007-02-05 Thread hackmiester (Hunter Fuller)


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

2007-02-05 Thread Theodore Tso
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

2007-02-05 Thread Mathieu Desnoyers
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

2007-02-05 Thread Robert Crocombe

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

2007-02-05 Thread Andrew Morton
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

2007-02-05 Thread Benjamin Herrenschmidt
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

2007-02-05 Thread Joel Becker
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

2007-02-05 Thread Stefan Richter
I wrote:
> @@ -1132,6 +1132,7 @@ static int __init ieee1394_init(void)
>   }
>   }
>  
> + ret = driver_register(&nodemgr_mid_layer_driver);
>   ret = class_register(&hpsb_host_class);
>   if (ret < 0)
>   goto release_all_bus;

I think I make that a
WARN_ON(driver_register(&nodemgr_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

2007-02-05 Thread David Miller
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

2007-02-05 Thread Randy Dunlap
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

2007-02-05 Thread Paul Mackerras
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

2007-02-05 Thread Paul Mackerras
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)

2007-02-05 Thread Nigel Cunningham
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

2007-02-05 Thread Andreas Gruenbacher
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

2007-02-05 Thread Stefan Richter
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(&nodemgr_mid_layer_driver);
ret = class_register(&hpsb_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= &ieee1394_bus_type,
.name   = "nodemgr",
.owner  = THIS_MODULE,
@@ -1857,7 +1857,6 @@ int init_ieee1394_nodemgr(void)
class_unregister(&nodemgr_ne_class);
return error;
}
-   error = driver_register(&nodemgr_mid_layer_driver);
hpsb_register_highlevel(&nodemgr_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

2007-02-05 Thread H. Peter Anvin

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

2007-02-05 Thread Robert Hancock

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

2007-02-05 Thread 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.

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

2007-02-05 Thread Davide Libenzi
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/


  1   2   3   4   5   >