Re: [1/4] 2.6.23-rc4: known regressions

[Jan Dittmer]

Christoph Lameter wrote:

On Thu, 30 Aug 2007, Adrian Bunk wrote:

Christoph, is your fix in -mm suitable for 2.6.23, or how else should 
this regression be fixed for 2.6.23?


Looks like this is just alpha and a certain particular compiler version? 


binutils 2.15.95, gcc 3.3.6 and I could update to 4.0.4 or something
more recent I guess. And yes, it's only alpha.

Of which file do you want the objdump?

Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CFS review

[Rene Herman]

On 08/29/2007 09:56 PM, Rene Herman wrote:

Realised the BUGs may mean the kernel DRM people could want to be in CC...


On 08/29/2007 05:57 PM, Keith Packard wrote:


With X server 1.3, I'm getting consistent crashes with two glxgear
instances running. So, if you're getting any output, it's better than my
situation.


Before people focuss on software rendering too much -- also with 1.3.0
(and a Matrox Millenium G550 AGP, 32M) glxgears also works decidedly
crummy using hardware rendering. While I can move the glxgears window
itself, the actual spinning wheels stay in the upper-left corner of the
screen and the movement leaves a non-repainting trace on the screen.
Running a second instance of glxgears in addition seems to make both
instances unkillable -- and when I just now forcefully killed X in this
situation (the spinning wheels were covering the upper left corner of all
my desktops) I got the below.

Kernel is 2.6.22.5-cfs-v20.5, schedule() is in the traces (but that may be
expected anyway).

BUG: unable to handle kernel NULL pointer dereference at virtual address 
0010

 printing eip:
c10ff416
*pde = 
Oops:  [#1]
PREEMPT
Modules linked in: nfsd exportfs lockd nfs_acl sunrpc nls_iso8859_1 
nls_cp437 vfat fat nls_base

CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00210246   (2.6.22.5-cfs-v20.5-local #5)
EIP is at mga_dma_buffers+0x189/0x2e3
eax:    ebx: efd07200   ecx: 0001   edx: efc32c00
esi:    edi: c12756cc   ebp: dfea44c0   esp: dddaaec0
ds: 007b   es: 007b   fs:   gs: 0033  ss: 0068
Process glxgears (pid: 1775, ti=dddaa000 task=e9daca60 task.ti=dddaa000)
Stack: efc32c00  0004 e4c3bd20 c10fa54b e4c3bd20 efc32c00 

   0004     0001 0001 
bfbdb8bc
   bfbdb8b8  c10ff28d 0029 c12756cc dfea44c0 c10f87fc 
bfbdb844

Call Trace:
 [] drm_lock+0x255/0x2de
 [] mga_dma_buffers+0x0/0x2e3
 [] drm_ioctl+0x142/0x18a
 [] do_IRQ+0x97/0xb0
 [] drm_ioctl+0x0/0x18a
 [] drm_ioctl+0x0/0x18a
 [] do_ioctl+0x87/0x9f
 [] vfs_ioctl+0x23d/0x250
 [] schedule+0x2d0/0x2e6
 [] sys_ioctl+0x33/0x4d
 [] syscall_call+0x7/0xb
 ===
Code: 9a 08 03 00 00 8b 73 30 74 14 c7 44 24 04 28 76 1c c1 c7 04 24 49 
51 23 c1 e8 b0 74 f1 ff 8b 83 d8 00 00 00 83 3d 1c 47 30 c1 00 <8b> 40 
10 8b a8 58 1e 00 00 8b 43 28 8b b8 64 01 00 00 74 32 8b

EIP: [] mga_dma_buffers+0x189/0x2e3 SS:ESP 0068:dddaaec0
BUG: unable to handle kernel NULL pointer dereference at virtual address 
0010

 printing eip:
c10ff416
*pde = 
Oops:  [#2]
PREEMPT
Modules linked in: nfsd exportfs lockd nfs_acl sunrpc nls_iso8859_1 
nls_cp437 vfat fat nls_base

CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00210246   (2.6.22.5-cfs-v20.5-local #5)
EIP is at mga_dma_buffers+0x189/0x2e3
eax:    ebx: efd07200   ecx: 0001   edx: efc32c00
esi:    edi: c12756cc   ebp: dfea4780   esp: e0552ec0
ds: 007b   es: 007b   fs:   gs: 0033  ss: 0068
Process glxgears (pid: 1776, ti=e0552000 task=c19ec000 task.ti=e0552000)
Stack: efc32c00  0003 efc64b40 c10fa54b efc64b40 efc32c00 

   0003     0001 0001 
bf8dbdcc
   bf8dbdc8  c10ff28d 0029 c12756cc dfea4780 c10f87fc 
bf8dbd54

Call Trace:
 [] drm_lock+0x255/0x2de
 [] mga_dma_buffers+0x0/0x2e3
 [] drm_ioctl+0x142/0x18a
 [] preempt_schedule+0x4e/0x5a
 [] drm_ioctl+0x0/0x18a
 [] drm_ioctl+0x0/0x18a
 [] do_ioctl+0x87/0x9f
 [] vfs_ioctl+0x23d/0x250
 [] schedule+0x23b/0x2e6
 [] schedule+0x2d0/0x2e6
 [] sys_ioctl+0x33/0x4d
 [] syscall_call+0x7/0xb
 ===
Code: 9a 08 03 00 00 8b 73 30 74 14 c7 44 24 04 28 76 1c c1 c7 04 24 49 
51 23 c1 e8 b0 74 f1 ff 8b 83 d8 00 00 00 83 3d 1c 47 30 c1 00 <8b> 40 
10 8b a8 58 1e 00 00 8b 43 28 8b b8 64 01 00 00 74 32 8b

EIP: [] mga_dma_buffers+0x189/0x2e3 SS:ESP 0068:e0552ec0
[drm:drm_release] *ERROR* Device busy: 2 0


Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Possible kernel lock in semaphore's __down()

[Peter Zijlstra]

On Wed, 2007-08-29 at 23:52 +0200, Aleksandar Dezelin wrote:
> Hi!
> 
> I'm a newbie here on the list and also as a "kernel hacker". There's a
> bug reported in bugzilla (Bug 7927), cite:
> 
> 
> > In the function __down
> >  
> > fastcall void __sched __down(struct semaphore * sem)
> > {
> >  struct task_struct *tsk = current;
> >  DECLARE_WAITQUEUE(wait, tsk);
> >  unsigned long flags;
> >  
> >  tsk->state = TASK_UNINTERRUPTIBLE;
> >  spin_lock_irqsave(&sem->wait.lock, flags);
> >  add_wait_queue_exclusive_locked(&sem->wait, &wait);
> >  ...
> > }
> >  
> > 
> > From this code fragment, it sets the tsk->state to TASK_UNINTERRUPTIBLE 
> > before 
> > gets the spinlock. Assume at that moment, a interrupt ocuur and and after 
> > the 
> > interrupt handle ends, an other process is scheduled to run (assume the 
> > kernel 
> > is preemptalbe). In this case, the previous process ( its state has set to 
> > TASK_UNINTERRUPTIBLE) has been picked off the run queue, and it has not yet 
> > add 
> > to the wait queue( sem->wait ), so it may be never waited up forever. 
> > 
> 
> I have marked it as rejected as as I can see at the time this function is 
> called,
> it is guaranteed that ret_from_intr() will not call schedule() on return from 
> an 
> interrupt handler to either kernel space or user space because of the call 
> to macro might_sleep() in semaphore's down(). Am I wrong?

I think the reported meant interrupt driven involuntary preemption. So
ret_from_intr() is not the right place to look. But afaict you're still
right, see how preempt_schedule*() adds PREEMPT_ACTIVE to the
preempt_count, and how that makes the scheduler ignore the task state.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CFS review

[Ingo Molnar]

* Rene Herman <[EMAIL PROTECTED]> wrote:

> Realised the BUGs may mean the kernel DRM people could want to be in CC...

and note that the schedule() call in there is not part of the crash 
backtrace:

> >Call Trace:
> > [] drm_lock+0x255/0x2de
> > [] mga_dma_buffers+0x0/0x2e3
> > [] drm_ioctl+0x142/0x18a
> > [] do_IRQ+0x97/0xb0
> > [] drm_ioctl+0x0/0x18a
> > [] drm_ioctl+0x0/0x18a
> > [] do_ioctl+0x87/0x9f
> > [] vfs_ioctl+0x23d/0x250
> > [] schedule+0x2d0/0x2e6
> > [] sys_ioctl+0x33/0x4d
> > [] syscall_call+0x7/0xb

it just happened to be on the kernel stack. Nor is the do_IRQ() entry 
real. Both are frequent functions (and were executed recently) that's 
why they were still in the stackframe.

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: uncached page allocator

[Nick Piggin]

Peter Zijlstra wrote:

On Tue, 2007-08-21 at 16:05 +1000, Dave Airlie wrote:



So you can see why some sort of uncached+writecombined page cache
would be useful, I could just allocate a bunch of pages at startup as
uncached+writecombined, and allocate pixmaps from them and when I
bind/free the pixmap I don't need the flush at all, now I'd really
like this to be part of the VM so that under memory pressure it can
just take the pages I've got in my cache back and after flushing turn
them back into cached pages, the other option is for the DRM to do
this on its own and penalise the whole system.



Can't you make these pages part of the regular VM by sticking them all
into an address_space.

And for this reclaim behaviour you'd only need to set PG_private and
have a_ops->releasepage() dtrt.


I'd just suggest Dave just registers a shrinker to start with.

You really want to be able to batch TLB flushes as well, which
->releasepage may not be so good at (you could add more machinery
behind the releasepage to build batches and so on, but anyway, a
shrinker might be the quickest way to get something working).

--
SUSE Labs, Novell Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Designers and Builders (was: Who wants to maintain KR list for stable releases?)

[Adrian Bunk]

On Thu, Aug 30, 2007 at 07:31:24AM +0300, Al Boldi wrote:
> Adrian Bunk wrote
> > Tracking feature or implementation suggestions wouldn't make sense.
> > Consider e.g. that there are several people on linux-kernel who often
> > write what they think the kernel should do but who never write a single
> > line of code themselves. There's no value in tracking such stuff.
> 
> There are designers, and there are builders.
> 
> Can you tell me who is more important?

That's a distinction that doesn't exist in practice:

Designing kernel features requires good knowledge of the area of the 
kernel that should be changed.

IOW: If you don't have the skills to implement it yourself you don't 
have the skills to do any good design.

> Thanks!
> Al

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kexec: reenable HPET before kexec

[Eric W. Biederman]

Konstantin Baydarov <[EMAIL PROTECTED]> writes:

> On Mon, 27 Aug 2007 11:26:29 -0700
> "Pallipadi, Venkatesh" <[EMAIL PROTECTED]> wrote:
>
>> 
>> 
>> - Another thing to try is to disable HPET and boot with PIT in the
>> first kernel. Just to check whether PIT never works on this platform
>> or the first kernel is doing something to stop PIT. You can try
>> "hpet=disable" boot option for that.
>> 
>> Thanks,
>> Venki
>
> I've tried kernel 1 with HPET disabled - it boots fine, PIT works!
> Then I made additional investigations and found out that PIT won't work
> in kernel 2 if bit HPET_CFG_LEGACY is set.
> Bit HPET_CFG_LEGACY is set by hpet_enable_int() during HPET
> initialization, so if this bit is cleared in machine_kexec() kernel 2
> boots fine.
> I can't explain this magic, maybe someone can explain this. Thanks.
>
> Here is new version of workaround for 2.6.23-rc3

Ok.  It looks like you understand this issue.

Can you please try calling hpet_disable_int from
hpet_set_mode under CLOCK_EVT_MODE_SHUTDOWN.  I haven't
traced the clock event methods all of the way through
but as a first approximation I think that will get
things called at the appropriate time with out needing
to patch machine_kexec.  Which is very much the wrong
place to add call any hpet code from.

We may also need to make the hpet initialization more
robust so we can do something sane in the kexec on panic
case, where we deliberately don't run any shutdown methods.

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/

[PATCH 2.6.21] Return available first timeslice to the creator, not parent

[Vitaly Mayatskikh]

Short-living process returns its timeslice to the parent, this affects process 
that creates a lot of such short-living threads, because its not a parent for 
new threads. Patch fixes this issue and doesn't break kabi as does the patch 
from reporter: http://lkml.org/lkml/2007/4/7/21

An example and script for systemtap were modified a bit. Patch was tested on 
2.6.21 with results:

Pass 1: parsed user script and 54 library script(s) in 330usr/10sys/340real ms.
Pass 2: analyzed script: 3 probe(s), 10 function(s), 0 embed(s), 10 global(s) 
in 540usr/890sys/1445real ms.
Pass 3: translated to C into 
"/tmp/stapg9EJ30/stap_09f64923e2e59e40ae9680eee1ee0ac9_7206.c" in 
10usr/0sys/5real ms.
Pass 4: compiled C into "stap_09f64923e2e59e40ae9680eee1ee0ac9_7206.ko" in 
2880usr/250sys/3124real ms.
Pass 5: starting run.
sched_exit/enter:  pid = 16625, tgid = 16623, ppid = 3761, creator = 16624, 
avail. timeslice = 6, creator's timeslice = 5
sched_exit/return: pid = 16625, tgid = 16623, ppid = 3761, creator = 16624, 
creator's adjusted timeslice = 11
sched_exit/enter:  pid = 16626, tgid = 16623, ppid = 3761, creator = 16624, 
avail. timeslice = 6, creator's timeslice = 5
sched_exit/return: pid = 16626, tgid = 16623, ppid = 3761, creator = 16624, 
creator's adjusted timeslice = 11
sched_exit/enter:  pid = 16627, tgid = 16623, ppid = 3761, creator = 16624, 
avail. timeslice = 6, creator's timeslice = 5
sched_exit/return: pid = 16627, tgid = 16623, ppid = 3761, creator = 16624, 
creator's adjusted timeslice = 11
sched_exit/enter:  pid = 16628, tgid = 16623, ppid = 3761, creator = 16624, 
avail. timeslice = 6, creator's timeslice = 5
sched_exit/return: pid = 16628, tgid = 16623, ppid = 3761, creator = 16624, 
creator's adjusted timeslice = 11
sched_exit/enter:  pid = 16629, tgid = 16623, ppid = 3761, creator = 16624, 
avail. timeslice = 6, creator's timeslice = 5
sched_exit/return: pid = 16629, tgid = 16623, ppid = 3761, creator = 16624, 
creator's adjusted timeslice = 11
sched_exit/enter:  pid = 16637, tgid = 16623, ppid = 3761, creator = 16624, 
avail. timeslice = 6, creator's timeslice = 5
sched_exit/return: pid = 16637, tgid = 16623, ppid = 3761, creator = 16624, 
creator's adjusted timeslice = 11
sched_exit/enter:  pid = 16638, tgid = 16623, ppid = 3761, creator = 16624, 
avail. timeslice = 6, creator's timeslice = 5
sched_exit/return: pid = 16638, tgid = 16623, ppid = 3761, creator = 16624, 
creator's adjusted timeslice = 11
sched_exit/enter:  pid = 16639, tgid = 16623, ppid = 3761, creator = 16624, 
avail. timeslice = 6, creator's timeslice = 5
sched_exit/return: pid = 16639, tgid = 16623, ppid = 3761, creator = 16624, 
creator's adjusted timeslice = 11
sched_exit/enter:  pid = 16640, tgid = 16623, ppid = 3761, creator = 16624, 
avail. timeslice = 6, creator's timeslice = 5
sched_exit/return: pid = 16640, tgid = 16623, ppid = 3761, creator = 16624, 
creator's adjusted timeslice = 11
sched_exit/enter:  pid = 16641, tgid = 16623, ppid = 3761, creator = 16624, 
avail. timeslice = 6, creator's timeslice = 5
sched_exit/return: pid = 16641, tgid = 16623, ppid = 3761, creator = 16624, 
creator's adjusted timeslice = 11
sched_exit/enter:  pid = 16624, tgid = 16623, ppid = 3761, creator = 16623, 
avail. timeslice = 11, creator's timeslice = 10
sched_exit/return: pid = 16624, tgid = 16623, ppid = 3761, creator = 16623, 
creator's adjusted timeslice = 21
sched_exit/enter:  pid = 16623, tgid = 16623, ppid = 3761, creator = 3761, 
avail. timeslice = 21, creator's timeslice = 21
sched_exit/return: pid = 16623, tgid = 16623, ppid = 3761, creator = 3761, 
creator's adjusted timeslice = 42
Pass 5: run completed in 40usr/150sys/4266real ms.

diff -up -bB ./include/linux/sched.h.orig ./include/linux/sched.h
--- ./include/linux/sched.h.orig2007-08-21 09:20:22.0 +0200
+++ ./include/linux/sched.h 2007-08-27 10:14:06.0 +0200
@@ -827,7 +827,9 @@ struct task_struct {
 
unsigned long policy;
cpumask_t cpus_allowed;
-   unsigned int time_slice, first_time_slice;
+   unsigned int time_slice;
+   /* Pid of creator */
+   unsigned int cpid;
 
 #if defined(CONFIG_SCHEDSTATS) || defined(CONFIG_TASK_DELAY_ACCT)
struct sched_info sched_info;
diff -up -bB ./kernel/sched.c.orig ./kernel/sched.c
--- ./kernel/sched.c.orig   2007-08-21 09:20:22.0 +0200
+++ ./kernel/sched.c2007-08-27 10:18:44.0 +0200
@@ -1626,9 +1626,9 @@ void fastcall sched_fork(struct task_str
p->time_slice = (current->time_slice + 1) >> 1;
/*
 * The remainder of the first timeslice might be recovered by
-* the parent if the child exits early enough.
+* the creator (not parent!) if the child exits early enough.
 */
-   p->first_time_slice = 1;
+   p->cpid = current->pid;
current->time_slice >>= 1;
p->timestamp = sched_clock();
if (unlikely(!current->time_slice)) {
@@ -1728,33 +1728,46 @@ void fastcall wake_up_new_task

Re: hda: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }

[John Sigler]

Alan Cox wrote:


John Sigler wrote:


Standards:
 Likely used: 1


Prehistory


The tragic bit is that we were sold similar DOMs in 2007...
(It's probably time to change suppliers?)


 LBA, IORDY not likely


No DMA, nothing above PIO2


OK. (Grumble)


 Buffer type: 0002: dual port, multi-sector
 Buffer size: 1.0kB  bytes avail on r/w long: 4
 Cannot perform double-word IO


Can't even do double word I/O


Double word is 32 bits, right? Isn't "Cannot perform double-word IO" in 
contradiction with the following statements?


 IO_support=  1 (32-bit)

Buffer size: 1.0kB  bytes avail on r/w long: 4

(Assuming an 8-bit byte, 4 bytes = 32 bits)


The messages with old IDE should be harmless and the current libata IDE
should drive it politely (I debugged a problem the same hardware showed
up for someone else).


When you say "the current libata IDE" do you mean PATA_VIA (in my case)?
I've avoided this driver because it is marked EXPERIMENTAL. Would there 
be any benefit in using it over the legacy ATA/MFM/RLL driver?



Basically your dinosaur is working correctly.


What do the warnings mean? :-)

Regards.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/4] 2.6.23-rc4: known regressions

[Danny ter Haar]

Quoting Michal Piotrowski ([EMAIL PROTECTED]):
> Here is a list of some known regressions in 2.6.23-rc4.
> CPUFREQ
> Subject : ide problems: 2.6.22-git17 working, 2.6.23-rc1* is not
> References  : http://lkml.org/lkml/2007/7/27/298
>   http://lkml.org/lkml/2007/7/29/371
> Last known good : ?
> Submitter   : dth <[EMAIL PROTECTED]>
> Caused-By   : Len Brown <[EMAIL PROTECTED]>
>   commit f79e3185dd0f8650022518d7624c876d8929061b
> Handled-By  : Len Brown <[EMAIL PROTECTED]>
> Status  : problem is being debugged

I just compiled 2.6.23-rc4 on this setup to check if we made any
progress. After reboot i see:

[SNIP]
NET: Registered protocol family 17
Using IPI Shortcut mode
Freeing unused kernel memory: 148 freed
init[1]: segfault at 8589 eip 8589 esp bfcfcb8c error 4
init[1]: segfault at 8589 eip 8589 esp bfcfcb8c error 4
init[1]: segfault at 8589 eip 8589 esp bfcfcb8c error 4
init[1]: segfault at 8589 eip 8589 esp bfcfcb8c error 4
init[1]: segfault at 8589 eip 8589 esp bfcfcb8c error 4
init[1]: segfault at 8589 eip 8589 esp bfcfcb8c error 4
init[1]: segfault at 8589 eip 8589 esp bfcfcb8c error 4
init[1]: segfault at 8589 eip 8589 esp bfcfcb8c error 4
init[1]: segfault at 8589 eip 8589 esp bfcfcb8c error 4
init[1]: segfault at 8589 eip 8589 esp bfcfcb8c error 4
input: AT Translated Set 2 keyboard as /devices/platform/i8042/
printk: 7888020 messages suppressed
init[1]: segfault at 8589 eip 8589 esp bfcfcb8c error 4

[more of the last 2 lines repeated over and over]

Am i doing something wrong (very possible) or am i bitten by
another/new phenomena ?

Danny
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: arch_align_stack() seems useless

[Franck Bui-Huu]

Arjan,

Franck Bui-Huu wrote:
> Arjan van de Ven wrote:
>> arch_align_stack aligns, on x86, within a 2 page range (this is for
>> cache coloring).
> 
> OK, but for elf case this seems useless since the top of the stack is
> already randomized.
> 
> It seems that the randomization stuff (top of the stack + stack
> pointer inside a page) belongs to the elf binary format whereas it
> could have been part of exec.c. Are there any reasons ?
> 
>> The other thing you missed is that arch_align_stack()
>> is called in 2 locations, binfmt_elf.c is the primary location for
>> inside-the-page randomization.
>>
> 
> Well not really because for mips case, we have:
> 
>   $ git grep ELF_PLATFORM include/asm-mips
>   include/asm-mips/elf.h:#define ELF_PLATFORM  (NULL)
> 
> So on mips, the stack pointer won't get the inside the page
> randomization. Is that correct ?
> 
> If so, I'm wondering why this randomization must depend on that string
> to be defined. I must admit that I'm not sure how it's used. I guess
> it's used by ld.so and it could be set to "mips" for now...
> 

Do you think that the diff below would be correct ? I tested it on
mips and it seems to work fine but I can't really say if it's
valid enough to submit it as a patch...

thanks
Franck

---8<---

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 4482a06..024006e 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -151,6 +151,13 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr 
*exec,
struct vm_area_struct *vma;
 
/*
+* In some cases (e.g. Hyper-Threading), we want to avoid L1
+* evictions by the processes running on the same package. One
+* thing we can do is to shuffle the initial stack for them.
+*/
+   p = arch_align_stack(p);
+
+   /*
 * If this architecture has a platform capability string, copy it
 * to userspace.  In some cases (Sparc), this info is impossible
 * for userspace to get any other way, in others (i386) it is
@@ -160,14 +167,6 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr 
*exec,
if (k_platform) {
size_t len = strlen(k_platform) + 1;
 
-   /*
-* In some cases (e.g. Hyper-Threading), we want to avoid L1
-* evictions by the processes running on the same package. One
-* thing we can do is to shuffle the initial stack for them.
-*/
-
-   p = arch_align_stack(p);
-
u_platform = (elf_addr_t __user *)STACK_ALLOC(p, len);
if (__copy_to_user(u_platform, k_platform, len))
return -EFAULT;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 4/5] Net: ath5k, license is GPLv2

[Jarek Poplawski]

On 29-08-2007 21:37, Michael Buesch wrote:
> On Wednesday 29 August 2007 21:33:43 Jon Smirl wrote:
>> What if a patch spans both code that is pure GPL and code imported
>> from BSD, how do you license it?
> 
> I think it's a valid assumption, if we say that the author
> of the patch read the license header of a file and agreed with it.
> So the patch is licensed to whatever the fileheader says. And if
> there's none, it's licensed with the COPYING terms.
> If a patch author likes some other license conditions, he must
> explicitely add them with the patch to the file, saying that this
> and that part have these and those conditions. Of course they must
> be compatible with the original license.
> 

I didn't track this thread from the beginning, so maybe I repeat
somebody's ideas (probably like above), but IMHO: do we have to be
so selfish/pedantic? Can't we sometimes 'donate' a little bit to our
'older' bsd cousins or half-brothers? I think, it could be like this:

- if our changes are minor and authors of these changes don't mind
the file could stay BSD licensed only; plus we ask BSD to let it be
dual licensed (but no big hassle);

- otherwise, we should always distinctly mark all GPL parts.

Regards,
Jarek P.

PS: there is probably some mess with gmail addresses in this thread.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: speeding up swapoff

[Eric W. Biederman]

Hugh Dickins <[EMAIL PROTECTED]> writes:

> The speedups I've imagined making, were a need demonstrated, have
> been more on the lines of batching (dealing with a range of pages
> in one go) and hashing (using the swapmap's ushort, so often 1 or
> 2 or 3, to hold an indicator of where to look for its references).

There is one other possibility.  Typically the swap code is using
compatibility disk I/O functions instead of the best the kernel
can offer.  I haven't looked recently but it might be worth just
making certain that there isn't some low-level optimization or
cleanup possible on that path.  Although I may just be thinking
of swapfiles.

I know there were tremendous gains ago when I removed the functions
that wrote pages synchronously to swapfiles.

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: [PATCH 4/5] Net: ath5k, license is GPLv2

[Jarek Poplawski]

On Thu, Aug 30, 2007 at 10:26:52AM +0200, Jarek Poplawski wrote:
...
> PS: there is probably some mess with gmail addresses in this thread.

...or maybe it's OK...  Sorry.

Jarek P.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.21] Return available first timeslice to the creator, not parent

[Michal Schmidt]

Vitaly Mayatskikh skrev:

Short-living process returns its timeslice to the parent, this
affects process that creates a lot of such short-living threads,
because its not a parent for new threads.


I don't see the point of sending patches for old Linux versions such as 
2.6.21, unless it's something applicable to the -stable tree.

Do recent kernels with CFS have the same problem?


Patch fixes this issue and
doesn't break kabi as does the patch from reporter:
http://lkml.org/lkml/2007/4/7/21


There's no kabi.

Michal

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.22.1-rt4] very strange oops in the kernel, which made the system very slow to respond

[Maarten Maathuis]

Can anyone make sense of this?

I have not encountered something like this, nor do i know what this trace means.

Please CC me if you reply.

Sincerely,

Maarten Maathuis.

log snippet:

Aug 29 21:15:15 localhost Unable to handle kernel paging request at
81003a2c6518 RIP:
Aug 29 21:15:15 localhost []
Aug 29 21:15:15 localhost PGD 8063 PUD 9063 PMD 80003a2001e3 PTE
cb7794f74fd27497
Aug 29 21:15:15 localhost Oops: 0011 [1] PREEMPT
Aug 29 21:15:15 localhost CPU 0
Aug 29 21:15:15 localhost Modules linked in: sch_sfq cls_fw sch_htb
ip6table_filter iptable_raw xt_comment xt_policy xt_multiport ipt_ULOG
ipt_TTL ipt_ttl ipt_TOS ipt_tos ipt_SAME ipt_REJECT ipt_REDIRECT
ipt_recent ipt_owner ipt_NETMAP ipt_MASQUERADE ipt_LOG ipt_iprange
ipt_ECN ipt_ecn ipt_CLUSTERIP ipt_ah ipt_addrtype nf_nat_tftp
nf_nat_snmp_basic nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc
nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda
nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_sctp
nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink
nf_conntrack_netbios_ns nf_conntrack_irc nf_conntrack_h323 xt_tcpmss
xt_pkttype xt_NFQUEUE xt_NFLOG xt_MARK xt_mark xt_mac xt_limit
xt_length xt_helper xt_hashlimit ip6_tables xt_dccp xt_conntrack
xt_connmark xt_CLASSIFY xt_tcpudp xt_state iptable_nat nf_nat
nf_conntrack_ipv4 iptable_mangle iptable_filter ip_tables x_tables
nf_conntrack_ftp nf_conntrack nfnetlink it87 hwmon_vid i2c_isa
i2c_nforce2 ivtv cx25840 wm8775 tuner cx2341x tveeprom videodev
v4l2_common v4l1_compat nouveau drm snd_ice1724 snd_ice17xx_ak4xxx
snd_ac97_codec ac97_bus snd_ak4114 snd_pcm snd_page_alloc snd_pt2258
snd_i2c snd_ak4xxx_adda snd_mpu401_uart snd_rawmidi k8temp
Aug 29 21:15:15 localhost Pid: 12, comm: softirq-rcu/0 Not tainted
2.6.22.1-rt4 #1
Aug 29 21:15:15 localhost RIP: 0010:[]  []
Aug 29 21:15:15 localhost RSP: :81003ffa9ed8  EFLAGS: 00010282
Aug 29 21:15:15 localhost RAX: feff RBX: 810006803500
RCX: 027c
Aug 29 21:15:15 localhost RDX: 81003ffa0100 RSI: 810038160240
RDI: 81002d613c80
Aug 29 21:15:15 localhost RBP: 81002d613c80 R08: 81003ffa8000
R09: 807116e0
Aug 29 21:15:15 localhost R10:  R11: 007a1200
R12: 0100
Aug 29 21:15:15 localhost R13:  R14: 806a6be0
R15: 
Aug 29 21:15:15 localhost FS:  2ba7c91da6f0()
GS:80676000() knlGS:f738d6d0
Aug 29 21:15:15 localhost CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
Aug 29 21:15:15 localhost CR2: 81003a2c6518 CR3: 18fce000
CR4: 06e0
Aug 29 21:15:15 localhost Process softirq-rcu/0 (pid: 12, threadinfo
81003ffa8000, task 81003ffa0100)
Aug 29 21:15:15 localhost Stack:  80251fed 81003ffa9ef0
feff 8070d9c0
Aug 29 21:15:15 localhost 8022e7ce 0032
 8070d9c0
Aug 29 21:15:15 localhost 8022e6b8 81003ff83d00
8023aae3 
Aug 29 21:15:15 localhost Call Trace:
Aug 29 21:15:15 localhost [] rcu_process_callbacks+0x96/0xb1
Aug 29 21:15:15 localhost [] ksoftirqd+0x116/0x1b0
Aug 29 21:15:15 localhost [] ksoftirqd+0x0/0x1b0
Aug 29 21:15:15 localhost [] kthread+0x47/0x74
Aug 29 21:15:15 localhost [] child_rip+0xa/0x12
Aug 29 21:15:15 localhost [] kthread+0x0/0x74
Aug 29 21:15:15 localhost [] child_rip+0x0/0x12
Aug 29 21:15:15 localhost
Aug 29 21:15:15 localhost ---
Aug 29 21:15:15 localhost | preempt count:  ]
Aug 29 21:15:15 localhost | 0-level deep critical section nesting:
Aug 29 21:15:15 localhost 
Aug 29 21:15:15 localhost
Aug 29 21:15:15 localhost
Aug 29 21:15:15 localhost Code: 80 3c 61 2d 00 81 ff ff 00 ce b6 39 00
81 ff ff 28 65 2c 3a
Aug 29 21:15:15 localhost RIP  []
Aug 29 21:15:15 localhost RSP 
Aug 29 21:15:15 localhost CR2: 81003a2c6518
Aug 29 21:15:15 localhost BUG: sleeping function called from invalid
context softirq-rcu/0(12) at kernel/rtmutex.c:636
Aug 29 21:15:15 localhost in_atomic():0 [], irqs_disabled():1
Aug 29 21:15:15 localhost
Aug 29 21:15:15 localhost Call Trace:
Aug 29 21:15:15 localhost [] __rt_spin_lock+0x27/0x47
Aug 29 21:15:15 localhost [] __wake_up+0x1c/0x63
Aug 29 21:15:15 localhost [] oops_end+0x15/0x54
Aug 29 21:15:15 localhost [] do_page_fault+0x694/0x75f
Aug 29 21:15:15 localhost [] dequeue_task+0x16/0x24
Aug 29 21:15:15 localhost [] __switch_to+0x21/0x270
Aug 29 21:15:15 localhost [] enqueue_task+0x16/0x24
Aug 29 21:15:15 localhost [] activate_task+0x6f/0x8b
Aug 29 21:15:15 localhost [] try_to_wake_up+0xea/0x114
Aug 29 21:15:15 localhost [] error_exit+0x0/0x84
Aug 29 21:15:15 localhost [] rcu_process_callbacks+0x96/0xb1
Aug 29 21:15:15 localhost [] ksoftirqd+0x116/0x1b0
Aug 29 21:15:15 localhost [] ksoftirqd+0x0/0x1b0
Aug 29 21:15:15 localhost [] kthread+0x47/0x74
Aug 29 21:15:15 localhost [] child_rip+0xa/0x12
Aug 29 21:15:15 localh

Re: [PATCH] ppc32/8xx: Fix r3 trashing due to 8MB TLB page instantiation

[Jochen Friedrich]

Hi Kumar,

> do we need this in arch/powerpc as well?

No. At least not until these patches are applied to powerpc, as well:

8f069b1a90bd97bf6d59a02ecabf0173d9175609 [PATCH] powerpc/8xx: Use 8MB D-TLB's 
for kernel static mapping faults
3ea4807de7b2c5c903380ba2c2e7150bee942f42 [PATCH] powerpc/8xx: last two 8MB 
D-TLB entries are incorrectly set
c51e078f82096a7d35ac8ec2416272e843a0e1c4 [PATCH] ppc32/8xx: Fix r3 trashing due 
to 8MB TLB page instantiation

Thanks,
Jochen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Who wants to maintain KR list for stable releases? (was Re: nmi_watchdog=2 regression in 2.6.21)

[Adrian Bunk]

On Wed, Aug 29, 2007 at 04:59:47PM -0700, Natalie Protasevich wrote:
> > Bugzilla is for tracking bugs, not for discussing possible
> > kernel features.
> 
> True, but some of them are categorized as bugs from the reporter's
> prospective, when they say "man page says" or "according to POSIX it's
> wrong".

If code behaves differently from how it should that is a bug. [1]

> I am going to push ones that are feature suggestions,
> re-design suggestions, and some way implementation related out to the
> site that Rick is going to help to maintain, which is more of
> suggested projects list.
> 
> > Tracking feature or implementation suggestions wouldn't make sense.
> > Consider e.g. that there are several people on linux-kernel who often
> > write what they think the kernel should do but who never write a single
> > line of code themselves. There's no value in tracking such stuff.
> 
> Yes, but some suggestions seem to make sense. How about evaluating it?
> and if they are real making it a possible project for someone who
> would do appropriate research, etc. And we move them from bugzilla
> where they don't belong to a development arena.

Fine with me, my point was simply that they don't belong into a
_bug_ tracker.

> > >  improved searches - for sure, for example in addition to
> > > pre-cooked queries make possible using "raw" queries directly on sql,
> > > which will address misplaced bugs and will make categories more
> > > dynamic;
> >
> > What do you have in mind?
> 
> I am going to look into the bugzilla software to start with, and see
> if there is a way to expand it this way. we used to have such internal
> tracking (unix based) at work, where we could compose pretty much
> freelance queries, it is really not big deal for developers who script
> and write huge regular expressions for their convenience every
> day...just a vogue idea for now, trying to think how to minimize bugs
> that get lost because of wrong bucket. Going manually through all of
> them is not very effective.

Is there any reasonable query that would be possible through SQL but 
isn't already possible through the web interface?

> > I've always been able to do any search I wanted using the "Advanced Search"
> > of Bugzilla. Well, just checking, it seems the search for the new
> > "regression" flag could be made easier, but that's not a general problem.
> 
> Yes but you have to assume that everything is in the right place from
> start, besides putting things into categories is often impossible
> before some exchange with reporter and initial diagnostics. The worst
> category so fas as I found is "other" (in every place where it
> exists). Most of the "other" bugs haven't been touched, and some have
> huge "SATA" letters in the description written in them :)
>...

You need some kind of first level support that does some initial 
debugging and assigns the bug into the right category, and that will 
always be a manual task done by going through all new bugs.

> --Natalie

cu
Adrian

[1] there are special cases where the kernel might deliberately not
some specification

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Send quota messages via netlink

[Jan Kara]

On Wed 29-08-07 15:06:43, Eric W. Biederman wrote:
> Jan Kara <[EMAIL PROTECTED]> writes:
> >> However I'm still confused about the use of current->user.  If that
> >> is what we really want and not the user who's quota will be charged
> >> it gets to be a really trick business, because potentially the uid
> >> we want to deliver varies depending on who opened the netlink socket.
> >   I see it's a complicated matter :). What I need to somehow pass to
> > userspace is something (and I don't really care whether it will be number,
> > string or whatever) that userspace can read and e.g. find a terminal
> > window or desktop the affected user has open and also translate the
> > identity to some user-understandable name (average user Joe has to
> > understand that he should quickly cleanup his home directory ;).
> >   Thinking more about it, we could probably pass a string to userspace in
> > the format:
> >   :
> >
> > So for example we can have something like:
> >   unix:1000 (traditional unix UIDs)
> >   nfs4:[EMAIL PROTECTED]
> >
> > The problem is: Are we able to find out in which "namespace type" we are
> > and send enough identifying information from a context of unpriviledged
> > user?
> 
> Ok.  This provides enough context to understand what you are trying to do.
> You do want the unix user id, not the filesystem notion.  Because you
> are looking for the user.
> 
> So we have to figure out how to do the hard thing which is look at
> who opened our netlink broadcast see if they are in the same user
> namespace as current->user.  Which is a pain and we don't currently
> have the infrastructure for.
  There can be arbitrary number of listeners (potentially from different
namespaces if I understand it correctly) listening to broadcasts. So I
think we should pass some universal identifier rather than try to find out
who is listening etc. I think such identifiers would be useful for other
things too, won't they?
  BTW: Do you have some idea, when would be the infrastructure clearer?
Whether it makes sence to currently proceed with UIDs and later change it
to something generic or whether I should wait before you sort it out :).

Honza
-- 
Jan Kara <[EMAIL PROTECTED]>
SuSE CR Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.21] Return available first timeslice to the creator, not parent

[Peter Zijlstra]

On Thu, 2007-08-30 at 09:50 +0200, Vitaly Mayatskikh wrote:
> Short-living process returns its timeslice to the parent, this affects
> process that creates a lot of such short-living threads, because its
> not a parent for new threads. Patch fixes this issue and doesn't break
> kabi as does the patch from reporter: http://lkml.org/lkml/2007/4/7/21

> plain text document attachment (2.6.21-timeslice.patch), "proposed
> patch"
> diff -up -bB ./include/linux/sched.h.orig ./include/linux/sched.h
> --- ./include/linux/sched.h.orig  2007-08-21 09:20:22.0 +0200
> +++ ./include/linux/sched.h   2007-08-27 10:14:06.0 +0200
> @@ -827,7 +827,9 @@ struct task_struct {
>  
>   unsigned long policy;
>   cpumask_t cpus_allowed;
> - unsigned int time_slice, first_time_slice;
> + unsigned int time_slice;
> + /* Pid of creator */
> + unsigned int cpid;

might as well make that pid_t, or maybe even a struct pid* and keep a
reference on it - the struct pid police might have an opinion.

>  #if defined(CONFIG_SCHEDSTATS) || defined(CONFIG_TASK_DELAY_ACCT)
>   struct sched_info sched_info;
> diff -up -bB ./kernel/sched.c.orig ./kernel/sched.c
> --- ./kernel/sched.c.orig 2007-08-21 09:20:22.0 +0200
> +++ ./kernel/sched.c  2007-08-27 10:18:44.0 +0200
> @@ -1626,9 +1626,9 @@ void fastcall sched_fork(struct task_str
>   p->time_slice = (current->time_slice + 1) >> 1;
>   /*
>* The remainder of the first timeslice might be recovered by
> -  * the parent if the child exits early enough.
> +  * the creator (not parent!) if the child exits early enough.
>*/
> - p->first_time_slice = 1;
> + p->cpid = current->pid;
>   current->time_slice >>= 1;
>   p->timestamp = sched_clock();
>   if (unlikely(!current->time_slice)) {
> @@ -1728,33 +1728,46 @@ void fastcall wake_up_new_task(struct ta
>  
>  /*
>   * Potentially available exiting-child timeslices are
> - * retrieved here - this way the parent does not get
> + * retrieved here - this way the creator does not get
>   * penalized for creating too many threads.
>   *
>   * (this cannot be used to 'generate' timeslices
>   * artificially, because any timeslice recovered here
> - * was given away by the parent in the first place.)
> + * was given away by the creator in the first place.)
>   */
>  void fastcall sched_exit(struct task_struct *p)
>  {
>   unsigned long flags;
>   struct rq *rq;
> -
> + struct task_struct* creator = NULL;
>   /*
>* If the child was a (relative-) CPU hog then decrease
> -  * the sleep_avg of the parent as well.
> +  * the sleep_avg of the creator as well.
>*/
> - rq = task_rq_lock(p->parent, &flags);
> - if (p->first_time_slice && task_cpu(p) == task_cpu(p->parent)) {
> - p->parent->time_slice += p->time_slice;
> - if (unlikely(p->parent->time_slice > task_timeslice(p)))
> - p->parent->time_slice = task_timeslice(p);
> + if (p->cpid) {
> + struct pid *pid = find_get_pid((pid_t)p->cpid);
> + if (pid) {
> + creator = get_pid_task(pid, PIDTYPE_PID);
> + put_pid(pid);
>   }
> - if (p->sleep_avg < p->parent->sleep_avg)
> - p->parent->sleep_avg = p->parent->sleep_avg /
> +
> + if (creator) {
> + if (task_cpu(p) == task_cpu(creator)) {
> + rq = task_rq_lock(creator, &flags);
> +
> + creator->time_slice += p->time_slice;
> + if (unlikely(creator->time_slice > 
> task_timeslice(p)))
> + creator->time_slice = task_timeslice(p);
> +
> + if (p->sleep_avg < creator->sleep_avg)
> + creator->sleep_avg = creator->sleep_avg 
> /
>   (EXIT_WEIGHT + 1) * EXIT_WEIGHT + p->sleep_avg /
>   (EXIT_WEIGHT + 1);
>   task_rq_unlock(rq, &flags);
> + }
> + put_task_struct(creator);
> + }
> + }
>  }
>  
>  /**
> @@ -3153,7 +3166,7 @@ static void task_running_tick(struct rq 
>*/
>   if ((p->policy == SCHED_RR) && !--p->time_slice) {
>   p->time_slice = task_timeslice(p);
> - p->first_time_slice = 0;
> + p->cpid = 0;
>   set_tsk_need_resched(p);
>  
>   /* put it at the end of the queue: */
> @@ -3166,7 +3179,7 @@ static void task_running_tick(struct rq 
>   set_tsk_need_resched(p);
>   p->prio = effective_prio(p);
>   p->time_slice = task_timeslice(p);
> - p->first_time_slice = 0;
> + p->cpid = 0;
>  
>   if (!rq->expired_timestamp)
>   rq->expired_timestamp = jiffies;

Other than that it lo

Re: Possible kernel lock in semaphore's __down()

[Oleg Nesterov]

(just in case Peter's explanation was too concise)

On 08/30, Peter Zijlstra wrote:
>
> On Wed, 2007-08-29 at 23:52 +0200, Aleksandar Dezelin wrote:
> > Hi!
> > 
> > I'm a newbie here on the list and also as a "kernel hacker". There's a
> > bug reported in bugzilla (Bug 7927), cite:
> > 
> > 
> > > In the function __down
> > >  
> > > fastcall void __sched __down(struct semaphore * sem)
> > > {
> > >  struct task_struct *tsk = current;
> > >  DECLARE_WAITQUEUE(wait, tsk);
> > >  unsigned long flags;
> > >  
> > >  tsk->state = TASK_UNINTERRUPTIBLE;
> > >  spin_lock_irqsave(&sem->wait.lock, flags);
> > >  add_wait_queue_exclusive_locked(&sem->wait, &wait);
> > >  ...
> > > }
> > >  
> > > 
> > > From this code fragment, it sets the tsk->state to TASK_UNINTERRUPTIBLE 
> > > before 
> > > gets the spinlock. Assume at that moment, a interrupt ocuur and and after 
> > > the 
> > > interrupt handle ends, an other process is scheduled to run (assume the 
> > > kernel 
> > > is preemptalbe). In this case, the previous process ( its state has set 
> > > to 
> > > TASK_UNINTERRUPTIBLE) has been picked off the run queue,
^
please see below,

>   and it has not 
> yet add 
> > > to the wait queue( sem->wait ), so it may be never waited up forever. 
> > > 
> > 
> > I have marked it as rejected as as I can see at the time this function is 
> > called,
> > it is guaranteed that ret_from_intr() will not call schedule() on return 
> > from an 
> > interrupt handler to either kernel space or user space because of the call 
> > to macro might_sleep() in semaphore's down(). Am I wrong?

No, ret_from_intr() still can schedule(). Actually it does 
preempt_schedule_irq()
which sets PREEMPT_ACTIVE.

And, as Peter explained,

> I think the reported meant interrupt driven involuntary preemption. So
> ret_from_intr() is not the right place to look. But afaict you're still
> right, see how preempt_schedule*() adds PREEMPT_ACTIVE to the
> preempt_count, and how that makes the scheduler ignore the task state.

this is OK, because in this case schedule() doesn't remove the task from
run queue even if its state is TASK_UNINTERRUPTIBLE,

if (prev->state && !(preempt_count() & PREEMPT_ACTIVE)) {
...
deactivate_task();
}

note the "!(preempt_count() & PREEMPT_ACTIVE))" check. So the task is still
runnable, we don't need to wake it, it will get CPU eventually.

Oleg.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.21] Return available first timeslice to the creator, not parent

[Peter Zijlstra]

On Thu, 2007-08-30 at 10:37 +0200, Michal Schmidt wrote:
> Vitaly Mayatskikh skrev:
> > Short-living process returns its timeslice to the parent, this
> > affects process that creates a lot of such short-living threads,
> > because its not a parent for new threads.
> 
> I don't see the point of sending patches for old Linux versions such as 
> 2.6.21, unless it's something applicable to the -stable tree.

The older trees might want to have this, perhaps the .16 by Adrian,
certainly distros still care.

> Do recent kernels with CFS have the same problem?

Very much not comparable, as you probably guessed :-)

> > Patch fixes this issue and
> > doesn't break kabi as does the patch from reporter:
> > http://lkml.org/lkml/2007/4/7/21
> 
> There's no kabi.

True.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm PATCH] Memory controller improve user interface

[Balbir Singh]

KAMEZAWA Hiroyuki wrote:
> On Thu, 30 Aug 2007 04:07:11 +0530
> Balbir Singh <[EMAIL PROTECTED]> wrote:
>> 1. Several people recommended it
>> 2. Herbert mentioned that they've moved to that interface and it
>>was working fine for them.
>>
> 
> I have no strong opinion. But how about Mega bytes ? (too big ?)
> There will be no rounding up/down problem.
> 

Here is what I am thinking, allow the user to input bytes/kilobytes/
megabytes or gigabytes. Store the data internally in kilobytes or
PFN. I prefer kilobytes (no rounding issues), but while implementing
limits we round up to the closest PFN.


-- 
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [11/36] Use page_cache_xxx in fs/buffer.c

[Dmitry Monakhov]

On 12:06 Tue 28 Aug , [EMAIL PROTECTED] wrote:
> Use page_cache_xxx in fs/buffer.c.
submit_bh wasn't changed this means what bio pages may have huge size
without respect to queue reqsrictions (q->max_hw_segments, and etc)
At least driver/md/raid0 will be broken by you'r patch.
> 
> We have a special situation in set_bh_page() since reiserfs calls that
> function before setting up the mapping. So retrieve the page size
> from the page struct rather than the mapping.
> 
> Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
> ---
>  fs/buffer.c |  110 
> +---
>  1 file changed, 62 insertions(+), 48 deletions(-)
> 
> Index: linux-2.6/fs/buffer.c
> ===
> --- linux-2.6.orig/fs/buffer.c2007-08-28 11:37:13.0 -0700
> +++ linux-2.6/fs/buffer.c 2007-08-28 11:37:58.0 -0700
> @@ -257,7 +257,7 @@ __find_get_block_slow(struct block_devic
>   struct page *page;
>   int all_mapped = 1;
>  
> - index = block >> (PAGE_CACHE_SHIFT - bd_inode->i_blkbits);
> + index = block >> (page_cache_shift(bd_mapping) - bd_inode->i_blkbits);
>   page = find_get_page(bd_mapping, index);
>   if (!page)
>   goto out;
> @@ -697,7 +697,7 @@ static int __set_page_dirty(struct page 
>  
>   if (mapping_cap_account_dirty(mapping)) {
>   __inc_zone_page_state(page, NR_FILE_DIRTY);
> - task_io_account_write(PAGE_CACHE_SIZE);
> + task_io_account_write(page_cache_size(mapping));
>   }
>   radix_tree_tag_set(&mapping->page_tree,
>   page_index(page), PAGECACHE_TAG_DIRTY);
> @@ -891,10 +891,11 @@ struct buffer_head *alloc_page_buffers(s
>  {
>   struct buffer_head *bh, *head;
>   long offset;
> + unsigned int page_size = page_cache_size(page->mapping);
>  
>  try_again:
>   head = NULL;
> - offset = PAGE_SIZE;
> + offset = page_size;
>   while ((offset -= size) >= 0) {
>   bh = alloc_buffer_head(GFP_NOFS);
>   if (!bh)
> @@ -1426,7 +1427,7 @@ void set_bh_page(struct buffer_head *bh,
>   struct page *page, unsigned long offset)
>  {
>   bh->b_page = page;
> - BUG_ON(offset >= PAGE_SIZE);
> + BUG_ON(offset >= compound_size(page));
>   if (PageHighMem(page))
>   /*
>* This catches illegal uses and preserves the offset:
> @@ -1605,6 +1606,7 @@ static int __block_write_full_page(struc
>   struct buffer_head *bh, *head;
>   const unsigned blocksize = 1 << inode->i_blkbits;
>   int nr_underway = 0;
> + struct address_space *mapping = inode->i_mapping;
>  
>   BUG_ON(!PageLocked(page));
>  
> @@ -1625,7 +1627,8 @@ static int __block_write_full_page(struc
>* handle that here by just cleaning them.
>*/
>  
> - block = (sector_t)page->index << (PAGE_CACHE_SHIFT - inode->i_blkbits);
> + block = (sector_t)page->index <<
> + (page_cache_shift(mapping) - inode->i_blkbits);
>   head = page_buffers(page);
>   bh = head;
>  
> @@ -1742,7 +1745,7 @@ recover:
>   } while ((bh = bh->b_this_page) != head);
>   SetPageError(page);
>   BUG_ON(PageWriteback(page));
> - mapping_set_error(page->mapping, err);
> + mapping_set_error(mapping, err);
>   set_page_writeback(page);
>   do {
>   struct buffer_head *next = bh->b_this_page;
> @@ -1767,8 +1770,8 @@ static int __block_prepare_write(struct 
>   struct buffer_head *bh, *head, *wait[2], **wait_bh=wait;
>  
>   BUG_ON(!PageLocked(page));
> - BUG_ON(from > PAGE_CACHE_SIZE);
> - BUG_ON(to > PAGE_CACHE_SIZE);
> + BUG_ON(from > page_cache_size(inode->i_mapping));
> + BUG_ON(to > page_cache_size(inode->i_mapping));
>   BUG_ON(from > to);
>  
>   blocksize = 1 << inode->i_blkbits;
> @@ -1777,7 +1780,8 @@ static int __block_prepare_write(struct 
>   head = page_buffers(page);
>  
>   bbits = inode->i_blkbits;
> - block = (sector_t)page->index << (PAGE_CACHE_SHIFT - bbits);
> + block = (sector_t)page->index <<
> + (page_cache_shift(inode->i_mapping) - bbits);
>  
>   for(bh = head, block_start = 0; bh != head || !block_start;
>   block++, block_start=block_end, bh = bh->b_this_page) {
> @@ -1921,7 +1925,8 @@ int block_read_full_page(struct page *pa
>   create_empty_buffers(page, blocksize, 0);
>   head = page_buffers(page);
>  
> - iblock = (sector_t)page->index << (PAGE_CACHE_SHIFT - inode->i_blkbits);
> + iblock = (sector_t)page->index <<
> + (page_cache_shift(page->mapping) - inode->i_blkbits);
>   lblock = (i_size_read(inode)+blocksize-1) >> inode->i_blkbits;
>   bh = head;
>   nr = 0;
> @@ -2045,7 +2050,7 @@ int generic_cont_expand(struct inode *in
>   pgoff_t index;
>   unsigned int offset;

[PATCH] fix ALSA compilation on Sparc32

[Markus Dahms]

The dma_alloc_coherent and dma_free_coherent function seem to be not
available on sparc(32) architecture. It is not used by SBus sound
drivers, so it's disabled via #ifndef for CONFIG_SPARC32.

Signed-off-by: Markus Dahms <[EMAIL PROTECTED]>

---
It is tested on a SparcStation 5 with the cs4231 driver. The ALSA list
should have been CCed, but as it is subscriber-only I skipped it.


--- linux-2.6/sound/core/memalloc.c 2007-08-30 10:59:50.0 +0200
+++ linux-2.6/sound/core/memalloc.c.patched 2007-08-23 18:41:41.0 
+0200
@@ -205,6 +205,8 @@ void snd_free_pages(void *ptr, size_t si
  *
  */
 
+#ifndef CONFIG_SPARC32
+
 /* allocate the coherent DMA pages */
 static void *snd_malloc_dev_pages(struct device *dev, size_t size, dma_addr_t 
*dma)
 {
@@ -239,6 +241,8 @@ static void snd_free_dev_pages(struct de
dma_free_coherent(dev, PAGE_SIZE << pg, ptr, dma);
 }
 
+#endif
+
 #ifdef CONFIG_SBUS
 
 static void *snd_malloc_sbus_pages(struct device *dev, size_t size,
@@ -311,9 +315,11 @@ int snd_dma_alloc_pages(int type, struct
dmab->area = snd_malloc_sbus_pages(device, size, &dmab->addr);
break;
 #endif
+#ifndef CONFIG_SPARC32
case SNDRV_DMA_TYPE_DEV:
dmab->area = snd_malloc_dev_pages(device, size, &dmab->addr);
break;
+#endif
case SNDRV_DMA_TYPE_DEV_SG:
snd_malloc_sgbuf_pages(device, size, dmab, NULL);
break;
@@ -382,9 +388,11 @@ void snd_dma_free_pages(struct snd_dma_b
snd_free_sbus_pages(dmab->dev.dev, dmab->bytes, dmab->area, 
dmab->addr);
break;
 #endif
+#ifndef CONFIG_SPARC32
case SNDRV_DMA_TYPE_DEV:
snd_free_dev_pages(dmab->dev.dev, dmab->bytes, dmab->area, 
dmab->addr);
break;
+#endif
case SNDRV_DMA_TYPE_DEV_SG:
snd_free_sgbuf_pages(dmab);
break;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.21] Return available first timeslice to the creator, not parent

[Oleg Nesterov]

On 08/30, Peter Zijlstra wrote:
>
> On Thu, 2007-08-30 at 09:50 +0200, Vitaly Mayatskikh wrote:
> > Short-living process returns its timeslice to the parent, this affects
> > process that creates a lot of such short-living threads, because its
> > not a parent for new threads. Patch fixes this issue and doesn't break
> > kabi as does the patch from reporter: http://lkml.org/lkml/2007/4/7/21
> 
> > plain text document attachment (2.6.21-timeslice.patch), "proposed
> > patch"
> > diff -up -bB ./include/linux/sched.h.orig ./include/linux/sched.h
> > --- ./include/linux/sched.h.orig2007-08-21 09:20:22.0 +0200
> > +++ ./include/linux/sched.h 2007-08-27 10:14:06.0 +0200
> > @@ -827,7 +827,9 @@ struct task_struct {
> >  
> > unsigned long policy;
> > cpumask_t cpus_allowed;
> > -   unsigned int time_slice, first_time_slice;
> > +   unsigned int time_slice;
> > +   /* Pid of creator */
> > +   unsigned int cpid;
> 
> might as well make that pid_t, or maybe even a struct pid* and keep a
> reference on it - the struct pid police might have an opinion.

I agree, "struct pid*" is better, because

1. we don't need a costly find_pid() in sched_exit()
2. we don't suffer from pid re-use problem

> >  void fastcall sched_exit(struct task_struct *p)
> >  {
> > unsigned long flags;
> > struct rq *rq;
> > -
> > +   struct task_struct* creator = NULL;
> > /*
> >  * If the child was a (relative-) CPU hog then decrease
> > -* the sleep_avg of the parent as well.
> > +* the sleep_avg of the creator as well.
> >  */
> > -   rq = task_rq_lock(p->parent, &flags);
> > -   if (p->first_time_slice && task_cpu(p) == task_cpu(p->parent)) {
> > -   p->parent->time_slice += p->time_slice;
> > -   if (unlikely(p->parent->time_slice > task_timeslice(p)))
> > -   p->parent->time_slice = task_timeslice(p);
> > +   if (p->cpid) {
> > +   struct pid *pid = find_get_pid((pid_t)p->cpid);
> > +   if (pid) {
> > +   creator = get_pid_task(pid, PIDTYPE_PID);
> > +   put_pid(pid);

sched_exit() was removed in 2.6.23-rc.

If you are going to re-introduce this logic, please don't do sched_exit()
from release_task(). It was done this way just because we can't access
->parent after release_task(). But release_task() is called either too
early, or too late for timeslice accounting, depending on ->exit_signal == -1.

I'd suggest to do this in do_exit(), before the last schedule(). Without
write_unlock_irq() the code above needs a couple of rcu_read_lock()'s.

I am not sure Ingo will like this change though...

Oleg.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 of autofs for current git?

[Martin Knoblauch]

On Wed, 2007-08-29 at 20:09 -0700, Ian Kent wrote:
>
>http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=75180df2ed467866ada839fe73cf7cc7d75c0a22
>
>This (and it's related patches) may be the problem.
>I can probably tell if you post your map or if you strace the
automount
>process managing the a problem mount point and look for mount
returning
>EBUSY when it should succeed.

 Likely. That is the one that will break the user-space automounter as
well (and keeps me from .23). I don't care very much about what the
default is, but it would be great if the new behaviour could be
globally changed at run- (or boot-) time. It will be some time until
the new mount option makes it into the distros.

Cheers
Martin
PS: Sorry, but I likely killed the CC list


--
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www:   http://www.knobisoft.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.21] Return available first timeslice to the creator, not parent

[Pavel Emelyanov]

Peter Zijlstra wrote:

On Thu, 2007-08-30 at 09:50 +0200, Vitaly Mayatskikh wrote:

Short-living process returns its timeslice to the parent, this affects
process that creates a lot of such short-living threads, because its
not a parent for new threads. Patch fixes this issue and doesn't break
kabi as does the patch from reporter: http://lkml.org/lkml/2007/4/7/21



plain text document attachment (2.6.21-timeslice.patch), "proposed
patch"
diff -up -bB ./include/linux/sched.h.orig ./include/linux/sched.h
--- ./include/linux/sched.h.orig2007-08-21 09:20:22.0 +0200
+++ ./include/linux/sched.h 2007-08-27 10:14:06.0 +0200
@@ -827,7 +827,9 @@ struct task_struct {
 
 	unsigned long policy;

cpumask_t cpus_allowed;
-   unsigned int time_slice, first_time_slice;
+   unsigned int time_slice;
+   /* Pid of creator */
+   unsigned int cpid;


might as well make that pid_t, or maybe even a struct pid* and keep a
reference on it - the struct pid police might have an opinion.


Store the struct pid reference itself. In any case you make
the find_get_pid() later to obtain the struct pid itself. This
will even make the sched_exit() work faster.


 #if defined(CONFIG_SCHEDSTATS) || defined(CONFIG_TASK_DELAY_ACCT)
struct sched_info sched_info;
diff -up -bB ./kernel/sched.c.orig ./kernel/sched.c
--- ./kernel/sched.c.orig   2007-08-21 09:20:22.0 +0200
+++ ./kernel/sched.c2007-08-27 10:18:44.0 +0200
@@ -1626,9 +1626,9 @@ void fastcall sched_fork(struct task_str
p->time_slice = (current->time_slice + 1) >> 1;
/*
 * The remainder of the first timeslice might be recovered by
-* the parent if the child exits early enough.
+* the creator (not parent!) if the child exits early enough.
 */
-   p->first_time_slice = 1;
+   p->cpid = current->pid;
current->time_slice >>= 1;
p->timestamp = sched_clock();
if (unlikely(!current->time_slice)) {
@@ -1728,33 +1728,46 @@ void fastcall wake_up_new_task(struct ta
 
 /*

  * Potentially available exiting-child timeslices are
- * retrieved here - this way the parent does not get
+ * retrieved here - this way the creator does not get
  * penalized for creating too many threads.
  *
  * (this cannot be used to 'generate' timeslices
  * artificially, because any timeslice recovered here
- * was given away by the parent in the first place.)
+ * was given away by the creator in the first place.)
  */
 void fastcall sched_exit(struct task_struct *p)
 {
unsigned long flags;
struct rq *rq;
-
+   struct task_struct* creator = NULL;
/*
 * If the child was a (relative-) CPU hog then decrease
-* the sleep_avg of the parent as well.
+* the sleep_avg of the creator as well.
 */
-   rq = task_rq_lock(p->parent, &flags);
-   if (p->first_time_slice && task_cpu(p) == task_cpu(p->parent)) {
-   p->parent->time_slice += p->time_slice;
-   if (unlikely(p->parent->time_slice > task_timeslice(p)))
-   p->parent->time_slice = task_timeslice(p);
+   if (p->cpid) {
+   struct pid *pid = find_get_pid((pid_t)p->cpid);
+   if (pid) {
+   creator = get_pid_task(pid, PIDTYPE_PID);
+   put_pid(pid);
}
-   if (p->sleep_avg < p->parent->sleep_avg)
-   p->parent->sleep_avg = p->parent->sleep_avg /
+
+   if (creator) {
+   if (task_cpu(p) == task_cpu(creator)) {
+   rq = task_rq_lock(creator, &flags);
+
+   creator->time_slice += p->time_slice;
+   if (unlikely(creator->time_slice > 
task_timeslice(p)))
+   creator->time_slice = task_timeslice(p);
+
+   if (p->sleep_avg < creator->sleep_avg)
+   creator->sleep_avg = creator->sleep_avg 
/
(EXIT_WEIGHT + 1) * EXIT_WEIGHT + p->sleep_avg /
(EXIT_WEIGHT + 1);
task_rq_unlock(rq, &flags);
+   }
+   put_task_struct(creator);
+   }
+   }
 }
 
 /**
@@ -3153,7 +3166,7 @@ static void task_running_tick(struct rq 
 		 */

if ((p->policy == SCHED_RR) && !--p->time_slice) {
p->time_slice = task_timeslice(p);
-   p->first_time_slice = 0;
+   p->cpid = 0;
set_tsk_need_resched(p);
 
 			/* put it at the end of the queue: */
@@ -3166,7 +3179,7 @@ static void task_running_tick(struct rq 
 		set_tsk_need_resched(p);

p->prio = effective_prio(p);
p->time_slice = task_timeslice(p);
-   p->first_time_slice = 0;
+   p->cpid = 0;
 
 		if (!rq->expired_timestamp)

Re: [PATCH] Override 80-wire cable detection for Toshiba S1800-814

[Alan Cox]

> Wow!  I have been running 80wire cable detection override on 40wire cables 
> for quite some time without any problem, but I never thought it to be legal 
> if the 40wire cable length is short enough.

Yes.

> How short does it have to be, and can't we have a kernel bootparm to override 
> the cable detection?

For most users the goal should be to automate behaviour. It should just
work.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] hwmon: Add power meters to Documentation/hwmon/sysfs-interface

[Jean Delvare]

Hi Darrick,

On Wed, 29 Aug 2007 07:50:03 -0700, Darrick J. Wong wrote:
> On Wed, Aug 29, 2007 at 11:10:52AM +0200, Jean Delvare wrote:
> 
> > I'm not sure if we want these "historical" files. We don't have them for
> > the other input types, and I believe that it's not the driver's job to
> > compute and export these values. If anyone cares about the history of
> 
> In the case of ibmpex, it is the _hardware_ that computes the historical
> data; the driver merely exports what it sees.

OK, that's a bit different then, but I'm still not sure that there is
much value in exporting these values in sysfs, in particular if there
is no way to reset them.

I am also not happy with the names you proposed: power1_max_input and
power1_min_input are somewhat confusing IMHO, I'd suggest
power1_input_highest and power1_input_lowest to make them clearly
different from the min and max limits we have for other sensor types.
If we have them at all, of course.

-- 
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA problems

[Nigel Kukard]

Hrmmm,

>>  > 
>>  >  > > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
>>  >  > > 0x0001c807
>>  >  > > Jun 14 07:55:52 nigel-m2v kernel: ATA: abnormal status 0x7F on port
>>  >  > > 0x0001c807
>>  > 
>>  > Unrelated to the other error, but I've been meaning to ask for a while..
>>  > If this is 'abnormal', why does every SATA box I've seen do it?
>>
>> *crickets*
>>
>> Should we check for this case explicitly, and not print this?
>>
>>   
>> 
> After I get the above errors, my entire SATA bus crashes and I need to
> hard reset the box ... not sure we can just ignore the errors?
>
>   

Appears even with the patch provided a few months ago I'm getting
freezes. Replaced the HDD & all cables, same errors ... especially
whilst doing heavy IO.

Can anyone shed some light?


ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd c8/00:00:9f:c9:cb/00:00:00:00:00/e1 tag 0 cdb 0x0 data
131072 in
 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2: soft resetting port
ATA: abnormal status 0x7F on port 0x0001c807
ATA: abnormal status 0x7F on port 0x0001c807
ata2.00: configured for UDMA/133
ata2: EH complete
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd c8/00:00:9f:c9:cb/00:00:00:00:00/e1 tag 0 cdb 0x0 data
131072 in
 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2: soft resetting port
ATA: abnormal status 0x7F on port 0x0001c807
ATA: abnormal status 0x7F on port 0x0001c807
ata2.00: configured for UDMA/133
ata2: EH complete
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd c8/00:00:9f:c9:cb/00:00:00:00:00/e1 tag 0 cdb 0x0 data
131072 in
 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2: soft resetting port
ATA: abnormal status 0x7F on port 0x0001c807
ATA: abnormal status 0x7F on port 0x0001c807
ata2.00: configured for UDMA/133
ata2: EH complete
ata2.00: limiting speed to UDMA/100:PIO4
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd c8/00:00:9f:c9:cb/00:00:00:00:00/e1 tag 0 cdb 0x0 data
131072 in
 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2: soft resetting port
ATA: abnormal status 0x7F on port 0x0001c807
ATA: abnormal status 0x7F on port 0x0001c807
ata2.00: configured for UDMA/100
ata2: EH complete
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd c8/00:00:9f:c9:cb/00:00:00:00:00/e1 tag 0 cdb 0x0 data
131072 in
 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2: soft resetting port
ATA: abnormal status 0x7F on port 0x0001c807
ATA: abnormal status 0x7F on port 0x0001c807
ata2.00: configured for UDMA/100
ata2: EH complete
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd c8/00:00:9f:c9:cb/00:00:00:00:00/e1 tag 0 cdb 0x0 data
131072 in
 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2: soft resetting port
ATA: abnormal status 0x7F on port 0x0001c807
ATA: abnormal status 0x7F on port 0x0001c807
ata2.00: configured for UDMA/100
sd 3:0:0:0: SCSI error: return code = 0x0802
sda: Current [descriptor]: sense key=0xb
ASC=0x0 ASCQ=0x0
Descriptor sense data with sense descriptors (in hex):
72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
00 00 00 00
end_request: I/O error, dev sda, sector 30132639
ata2: EH complete
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd c8/00:00:9f:ca:cb/00:00:00:00:00/e1 tag 0 cdb 0x0 data
131072 in
 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2: soft resetting port
ATA: abnormal status 0x7F on port 0x0001c807
ATA: abnormal status 0x7F on port 0x0001c807
ata2.00: configured for UDMA/100
ata2: EH complete
ata2.00: limiting speed to UDMA/33:PIO4
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd c8/00:00:9f:ca:cb/00:00:00:00:00/e1 tag 0 cdb 0x0 data
131072 in
 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2: soft resetting port
ATA: abnormal status 0x7F on port 0x0001c807
ATA: abnormal status 0x7F on port 0x0001c807
ata2.00: configured for UDMA/33
ata2: EH complete
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd c8/00:00:9f:ca:cb/00:00:00:00:00/e1 tag 0 cdb 0x0 data
131072 in
 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2: soft resetting port
ATA: abnormal status 0x7F on port 0x0001c807
ATA: abnormal status 0x7F on port 0x0001c807
ata2.00: configured for UDMA/33
ata2: EH complete
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd c8/00:00:9f:ca:cb/00:00:00:00:00/e1 tag 0 cdb 0x0 data
131072 in
 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2: soft resetting port
ATA: abnormal status 0x7F on port 0x0001c807
ATA: abnormal status 0x7F on port 0x0001c807
ata2.00: configured for UDMA/33
ata2: EH complete




signature.asc
Description: O

Re: [PATCH 2.6.21] Return available first timeslice to the creator, not parent

[Peter Zijlstra]

On Thu, 2007-08-30 at 13:49 +0400, Oleg Nesterov wrote:
> On 08/30, Peter Zijlstra wrote:
> >
> > On Thu, 2007-08-30 at 09:50 +0200, Vitaly Mayatskikh wrote:
> > > Short-living process returns its timeslice to the parent, this affects
> > > process that creates a lot of such short-living threads, because its
> > > not a parent for new threads. Patch fixes this issue and doesn't break
> > > kabi as does the patch from reporter: http://lkml.org/lkml/2007/4/7/21
> > 
> > > plain text document attachment (2.6.21-timeslice.patch), "proposed
> > > patch"
> > > diff -up -bB ./include/linux/sched.h.orig ./include/linux/sched.h
> > > --- ./include/linux/sched.h.orig  2007-08-21 09:20:22.0 +0200
> > > +++ ./include/linux/sched.h   2007-08-27 10:14:06.0 +0200
> > > @@ -827,7 +827,9 @@ struct task_struct {
> > >  
> > >   unsigned long policy;
> > >   cpumask_t cpus_allowed;
> > > - unsigned int time_slice, first_time_slice;
> > > + unsigned int time_slice;
> > > + /* Pid of creator */
> > > + unsigned int cpid;
> > 
> > might as well make that pid_t, or maybe even a struct pid* and keep a
> > reference on it - the struct pid police might have an opinion.
> 
> I agree, "struct pid*" is better, because
> 
>   1. we don't need a costly find_pid() in sched_exit()
>   2. we don't suffer from pid re-use problem

Ah, good arguments indeed.

> > >  void fastcall sched_exit(struct task_struct *p)
> > >  {
> > >   unsigned long flags;
> > >   struct rq *rq;
> > > -
> > > + struct task_struct* creator = NULL;
> > >   /*
> > >* If the child was a (relative-) CPU hog then decrease
> > > -  * the sleep_avg of the parent as well.
> > > +  * the sleep_avg of the creator as well.
> > >*/
> > > - rq = task_rq_lock(p->parent, &flags);
> > > - if (p->first_time_slice && task_cpu(p) == task_cpu(p->parent)) {
> > > - p->parent->time_slice += p->time_slice;
> > > - if (unlikely(p->parent->time_slice > task_timeslice(p)))
> > > - p->parent->time_slice = task_timeslice(p);
> > > + if (p->cpid) {
> > > + struct pid *pid = find_get_pid((pid_t)p->cpid);
> > > + if (pid) {
> > > + creator = get_pid_task(pid, PIDTYPE_PID);
> > > + put_pid(pid);
> 
> sched_exit() was removed in 2.6.23-rc.
> 
> If you are going to re-introduce this logic, please don't do sched_exit()
> from release_task(). It was done this way just because we can't access
> ->parent after release_task(). But release_task() is called either too
> early, or too late for timeslice accounting, depending on ->exit_signal == -1.
> 
> I'd suggest to do this in do_exit(), before the last schedule(). Without
> write_unlock_irq() the code above needs a couple of rcu_read_lock()'s.
> 
> I am not sure Ingo will like this change though...

This is not intended as re-introduction of the feature, this stems from
fixing this issue in older (read distro) kernels.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fix ALSA compilation on Sparc32

[Alan Cox]

On Thu, 30 Aug 2007 11:26:04 +0200
Markus Dahms <[EMAIL PROTECTED]> wrote:

> The dma_alloc_coherent and dma_free_coherent function seem to be not
> available on sparc(32) architecture. It is not used by SBus sound
> drivers, so it's disabled via #ifndef for CONFIG_SPARC32.

It would probably look a lot cleaner if you either provided dummy
dma_alloc_coherent/free coherent inlines for SPARC32, fixed it (if
sparc32 can do coherent DMA) or if you must ifdef it provide dummy
functions in the memalloc code so its a single ifdef

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.21] Return available first timeslice to the creator, not parent

[Oleg Nesterov]

On 08/30, Peter Zijlstra wrote:
>
> On Thu, 2007-08-30 at 13:49 +0400, Oleg Nesterov wrote:
> > 
> > sched_exit() was removed in 2.6.23-rc.
> > 
> > If you are going to re-introduce this logic, please don't do sched_exit()
> > from release_task(). It was done this way just because we can't access
> > ->parent after release_task(). But release_task() is called either too
> > early, or too late for timeslice accounting, depending on ->exit_signal == 
> > -1.
> > 
> > I'd suggest to do this in do_exit(), before the last schedule(). Without
> > write_unlock_irq() the code above needs a couple of rcu_read_lock()'s.
> > 
> > I am not sure Ingo will like this change though...
> 
> This is not intended as re-introduction of the feature, this stems from
> fixing this issue in older (read distro) kernels.

Ah, good, sorry for noise then.

In that case I don't think it makes sense to move sched_exit() to do_exit(),
of course. This doesn't look suitable for the -stable tree.

Oleg.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/RESENT] hptiop: adding new firmware interface and more PCI device IDs

[HighPoint Linux Team]

updated patch based on Jeff Garzik's comments.

- check adapter firmware version and use appropriate interface accordingly
- add new PCI device IDs and use PCI_VDEVICE macro
- update driver version string
- remove unused data structures
- remove unnecessary typecasts

Signed-off-by: HighPoint Linux Team <[EMAIL PROTECTED]>
---
 drivers/scsi/hptiop.c |   63 +
 drivers/scsi/hptiop.h |  229 
++-
 2 files changed, 58 insertions(+), 234 deletions(-)

diff -urpN a/drivers/scsi/hptiop.c b/drivers/scsi/hptiop.c
--- a/drivers/scsi/hptiop.c 2007-08-28 22:52:20.0 -0700
+++ b/drivers/scsi/hptiop.c 2007-08-30 10:08:13.0 -0700
@@ -1,6 +1,6 @@
 /*
  * HighPoint RR3xxx controller driver for Linux
- * Copyright (C) 2006 HighPoint Technologies, Inc. All Rights Reserved.
+ * Copyright (C) 2006-2007 HighPoint Technologies, Inc. All Rights Reserved.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -42,7 +42,7 @@ MODULE_DESCRIPTION("HighPoint RocketRAID
 
 static char driver_name[] = "hptiop";
 static const char driver_name_long[] = "RocketRAID 3xxx SATA Controller 
driver";
-static const char driver_ver[] = "v1.0 (060426)";
+static const char driver_ver[] = "v1.2 (070830)";
 
 static void hptiop_host_request_callback(struct hptiop_hba *hba, u32 tag);
 static void hptiop_iop_request_callback(struct hptiop_hba *hba, u32 tag);
@@ -76,7 +76,7 @@ static int iop_wait_ready(struct hpt_iop
 
 static void hptiop_request_callback(struct hptiop_hba *hba, u32 tag)
 {
-   if ((tag & IOPMU_QUEUE_MASK_HOST_BITS) == IOPMU_QUEUE_ADDR_HOST_BIT)
+   if (tag & IOPMU_QUEUE_ADDR_HOST_BIT)
return hptiop_host_request_callback(hba,
tag & ~IOPMU_QUEUE_ADDR_HOST_BIT);
else
@@ -323,12 +323,22 @@ static inline void free_req(struct hptio
hba->req_list = req;
 }
 
-static void hptiop_host_request_callback(struct hptiop_hba *hba, u32 tag)
+static void hptiop_host_request_callback(struct hptiop_hba *hba, u32 _tag)
 {
struct hpt_iop_request_scsi_command *req;
struct scsi_cmnd *scp;
+   u32 tag;
+
+   if (hba->iopintf_v2) {
+   tag = _tag & ~ IOPMU_QUEUE_REQUEST_RESULT_BIT;
+   req = hba->reqs[tag].req_virt;
+   if (likely(_tag & IOPMU_QUEUE_REQUEST_RESULT_BIT))
+   req->header.result = IOP_RESULT_SUCCESS;
+   } else {
+   tag = _tag;
+   req = hba->reqs[tag].req_virt;
+   }
 
-   req = (struct hpt_iop_request_scsi_command *)hba->reqs[tag].req_virt;
dprintk("hptiop_host_request_callback: req=%p, type=%d, "
"result=%d, context=0x%x tag=%d\n",
req, req->header.type, req->header.result,
@@ -497,7 +507,7 @@ static int hptiop_queuecommand(struct sc
goto cmd_done;
}
 
-   req = (struct hpt_iop_request_scsi_command *)_req->req_virt;
+   req = _req->req_virt;
 
/* build S/G table */
sg_count = hptiop_buildsgl(scp, req->sg_list);
@@ -521,8 +531,19 @@ static int hptiop_queuecommand(struct sc
 
memcpy(req->cdb, scp->cmnd, sizeof(req->cdb));
 
-   writel(IOPMU_QUEUE_ADDR_HOST_BIT | _req->req_shifted_phy,
-   &hba->iop->inbound_queue);
+   if (hba->iopintf_v2) {
+   u32 size_bits;
+   if (req->header.size < 256)
+   size_bits = IOPMU_QUEUE_REQUEST_SIZE_BIT;
+   else if (req->header.size < 512)
+   size_bits = IOPMU_QUEUE_ADDR_HOST_BIT;
+   else
+   size_bits = IOPMU_QUEUE_REQUEST_SIZE_BIT |
+   IOPMU_QUEUE_ADDR_HOST_BIT;
+   writel(_req->req_shifted_phy | size_bits, 
&hba->iop->inbound_queue);
+   } else
+   writel(_req->req_shifted_phy | IOPMU_QUEUE_ADDR_HOST_BIT,
+   &hba->iop->inbound_queue);
 
return 0;
 
@@ -688,6 +709,7 @@ static int __devinit hptiop_probe(struct
hba->pcidev = pcidev;
hba->host = host;
hba->initialized = 0;
+   hba->iopintf_v2 = 0;
 
atomic_set(&hba->resetting, 0);
atomic_set(&hba->reset_count, 0);
@@ -722,8 +744,13 @@ static int __devinit hptiop_probe(struct
hba->max_request_size = le32_to_cpu(iop_config.request_size);
hba->max_sg_descriptors = le32_to_cpu(iop_config.max_sg_count);
hba->firmware_version = le32_to_cpu(iop_config.firmware_version);
+   hba->interface_version = le32_to_cpu(iop_config.interface_version);
hba->sdram_size = le32_to_cpu(iop_config.sdram_size);
 
+   if (hba->firmware_version > 0x0102 ||
+   hba->interface_version > 0x0102)
+   hba->iopintf_v2 = 1;
+
hos

Re: Understanding I/O behaviour - next try

[Martin Knoblauch]

--- Robert Hancock <[EMAIL PROTECTED]> wrote:

> 
> I saw a bulletin from HP recently that sugggested disabling the 
> write-back cache on some Smart Array controllers as a workaround
> because 
> it reduced performance in applications that did large bulk writes. 
> Presumably they are planning on releasing some updated firmware that 
> fixes this eventually..
> 
> -- 
> Robert Hancock  Saskatoon, SK, Canada
> To email, remove "nospam" from [EMAIL PROTECTED]
> Home Page: http://www.roberthancock.com/
> 
Robert,

 just checked it out. At least with the "6i", you do not want to
disable the WBC :-) Performance really goes down the toilet for all
cases.

 Do you still have a pointer to that bulletin?

Cheers
Martin

--
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www:   http://www.knobisoft.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: speeding up swapoff

[Hugh Dickins]

On Thu, 30 Aug 2007, Eric W. Biederman wrote:
> 
> There is one other possibility.  Typically the swap code is using
> compatibility disk I/O functions instead of the best the kernel
> can offer.  I haven't looked recently but it might be worth just
> making certain that there isn't some low-level optimization or
> cleanup possible on that path.  Although I may just be thinking
> of swapfiles.

Andrew rewrote swapfile support in 2.5, making it use FIBMAP at
swapon time: so that in 2.6 swapfiles are as deadlock-free and
as efficient (unless the swapfile happens to be badly fragmented)
as raw disk partitions.

There's certainly scope for a study of I/O patterns in swapping,
it's hard to imagine that improvements couldn't be made (but also
easy to imagine endless disputes over different kinds of workload).
But most people would appreciate an improvement in active swapping,
and not care very much about the swapoff.

Regarding Daniel's use of swapoff: it's a very heavy sledgehammer
for cracking that nut, I strongly agree with those who have pointed
him to mlock and mlockall instead.

Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[KJ][patch 0/3] use abs() from kernel.h where appropriate

[andre]

This small series of quite trivial patches converts a own definition
of the abs macro to the one from kernel.h and replaces some inline
calculations of abs with the macro.

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[KJ][patch 1/3] IDT77252: use abs() from kernel.h where appropriate

[andre]

From: Andre Haupt <[EMAIL PROTECTED]>
Signed-off-by: Andre Haupt <[EMAIL PROTECTED]>
---
Index: linus/drivers/atm/idt77252.c
===
--- linus.orig/drivers/atm/idt77252.c   2007-08-30 11:33:22.0 +0200
+++ linus/drivers/atm/idt77252.c2007-08-30 11:37:00.0 +0200
@@ -2092,7 +2092,7 @@ idt77252_rate_logindex(struct idt77252_d
 {
u16 afp;
 
-   afp = idt77252_int_to_atmfp(pcr < 0 ? -pcr : pcr);
+   afp = idt77252_int_to_atmfp(abs(pcr));
if (pcr < 0)
return rate_to_log[(afp >> 5) & 0x1ff];
return rate_to_log[((afp >> 5) + 1) & 0x1ff];
@@ -2149,7 +2149,7 @@ idt77252_init_est(struct vc_map *vc, int
est = kzalloc(sizeof(struct rate_estimator), GFP_KERNEL);
if (!est)
return NULL;
-   est->maxcps = pcr < 0 ? -pcr : pcr;
+   est->maxcps = abs(pcr);
est->cps = est->maxcps;
est->avcps = est->cps << 5;
 

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-2.6.23-rc4 ppc build failure

[Felipe Balbi]

Hi,

On 8/29/07, Bret Towe <[EMAIL PROTECTED]> wrote:
> On 8/29/07, Felipe Balbi <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > On 8/29/07, Bret Towe <[EMAIL PROTECTED]> wrote:
> > > while trying to build a fresh kernel for my mini after upgrading from 
> > > gutsy
> > > (and forgetting to save my .config) I hit the below build error
> >
> > The .config you can get from /boot/config-`uname -r`
>
> yes I know the one thats attached is based off that
> just slimed down trying to keep the compile time down as much as possable

Well, I don't have ppc cross-compiler... so I can't try this for you.
What I can tell you is that it doesn't seem like there was any change
regarding those functions. But even though, you're selecting the
needed Kconfig Macros.

Maybe someone who uses PPC arch could help better ???

>
> > > 2.6.23-rc3 I did work under feisty but that is with a different .config
> > > so not sure if that makes any difference or not
> > > I've not bisected cause it takes so long on this computer...
> > > attached is the config I'm working off now
> > >
> > > arch/powerpc/platforms/built-in.o: In function `pmac_probe':
> > > setup.c:(.init.text+0xbba): undefined reference to `pmac_ide_get_base'
> > > setup.c:(.init.text+0xbbe): undefined reference to 
> > > `pmac_ide_init_hwif_ports'
> > > setup.c:(.init.text+0xbc6): undefined reference to `pmac_ide_get_base'
> > > setup.c:(.init.text+0xbca): undefined reference to 
> > > `pmac_ide_init_hwif_ports'
> > > make[1]: *** [.tmp_vmlinux1] Error 1
> > > make[1]: Leaving directory `/usr/src/linux-2.6'
> > >
> > >
> >
> >
> > --
> > Best Regards,
> >
> > Felipe Balbi
> > [EMAIL PROTECTED]
> >
>


-- 
Best Regards,

Felipe Balbi
[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/

[KJ][patch 2/3] CIFS SMB: use abs() from kernel.h where appropriate

[andre]

From: Andre Haupt <[EMAIL PROTECTED]>
Signed-off-by: Andre Haupt <[EMAIL PROTECTED]>
---
Index: linus/fs/cifs/cifssmb.c
===
--- linus.orig/fs/cifs/cifssmb.c2007-08-30 11:43:20.0 +0200
+++ linus/fs/cifs/cifssmb.c 2007-08-30 11:44:58.0 +0200
@@ -513,7 +513,7 @@ CIFSSMBNegotiate(unsigned int xid, struc
(int)ts.tv_sec, (int)utc.tv_sec,
(int)(utc.tv_sec - ts.tv_sec)));
val = (int)(utc.tv_sec - ts.tv_sec);
-   seconds = val < 0 ? -val : val;
+   seconds = abs(val);
result = (seconds / MIN_TZ_ADJ) * MIN_TZ_ADJ;
remain = seconds % MIN_TZ_ADJ;
if (remain >= (MIN_TZ_ADJ / 2))

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[KJ][patch 3/3] VIDC20: use abs() from kernel.h instead of own definition

[andre]

From: Andre Haupt <[EMAIL PROTECTED]>
Signed-off-by: Andre Haupt <[EMAIL PROTECTED]>
---
Index: linus/sound/oss/vidc.c
===
--- linus.orig/sound/oss/vidc.c 2007-08-30 11:57:13.0 +0200
+++ linus/sound/oss/vidc.c  2007-08-30 11:57:53.0 +0200
@@ -185,8 +185,6 @@ static unsigned int vidc_audio_set_forma
return vidc_audio_format;
 }
 
-#define my_abs(i) ((i)<0 ? -(i) : (i))
-
 static int vidc_audio_set_speed(int dev, int rate)
 {
if (rate) {
@@ -214,8 +212,8 @@ static int vidc_audio_set_speed(int dev,
rate_ext = VIDC_SOUND_CLOCK_EXT / hwrate_ext;
 
/* Chose between external and internal clock */
-   diff_int = my_abs(rate_ext-rate);
-   diff_ext = my_abs(rate_int-rate);
+   diff_int = abs(rate_ext-rate);
+   diff_ext = abs(rate_int-rate);
if (diff_ext < diff_int) {
/*printk("VIDC: external %d %d %d\n", rate, rate_ext, 
hwrate_ext);*/
hwrate=hwrate_ext;

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ide.c and compactFlash

[Espen M. Rutger]

Lennart Sorensen wrote:

On Thu, Aug 23, 2007 at 01:56:35PM +0200, Espen M. Rutger wrote:
  
I got problems with the IDE code which causes the kernel to freez after 
printing out:


hda: status timeout: status=0xd0 { Busy }

kernel used: 2.4.18 crosscompiled with Montavista tools (ppc_82xx-gcc 
(GCC) 3.2.1 20020930 (MontaVista))


The ide interface chip is a PD6729 configured to ATA mode.

CompactFlash cards: winsys 1GB industrial grade and simpleTech 1GB 
industrial grade.


I beleive this is a timing issue and have tried to increase a udelay () 
to 2 microseconds (instead of 1 microsecond) in the ide_wait_stat() 
function - it took longer time to freez, but it still freezes...



Try booting with 'ide=nodma'.  Some compact flash cards support DMA
mode, and of course most IDE controllers support DMA mode, and if both
support it the kernel tends to try and enable it but if you don't have
the DMA lines connected it will fail and give annoying errors similar to
that one.  The DMA part of compact flash was a fairly recent addition
and the two affected lines used to be reserved on compact flash.  The
product I work on did not have the DMA lines on the previous board
design but we have it on the latest board revision.  On the old boards
we had to disable DMA support for IDE since otherwise certain types of
compact flash would have annoying timeouts trying to enable DMA.  On our
new board with the DMA lines, everything just works and the DMA access
gives about twice the read/write speed to the compact flash cards we are
using.

--
Len Sorensen

  


Thank you very much for your response Lennart, but unfortunately this 
did not solve my problem - the system (got four machines in my test 
setup) still generate the error and make the kernel wait forever.


regards
Espen M. Rutger

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Understanding I/O behaviour - next try

[Martin Knoblauch]

--- Jens Axboe <[EMAIL PROTECTED]> wrote:

> 
> Try limiting the queue depth on the cciss device, some of those are
> notoriously bad at starving commands. Something like the below hack,
> see
> if it makes a difference (and please verify in dmesg that it prints
> the
> message about limiting depth!):
> 
> diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
> index 084358a..257e1c3 100644
> --- a/drivers/block/cciss.c
> +++ b/drivers/block/cciss.c
> @@ -2992,7 +2992,12 @@ static int cciss_pci_init(ctlr_info_t *c,
> struct pci_dev *pdev)
>   if (board_id == products[i].board_id) {
>   c->product_name = products[i].product_name;
>   c->access = *(products[i].access);
> +#if 0
>   c->nr_cmds = products[i].nr_cmds;
> +#else
> + c->nr_cmds = 2;
> + printk("cciss: limited max commands to 2\n");
> +#endif
>   break;
>   }
>   }
> 
> -- 
> Jens Axboe
> 
> 
Hi Jens,

 how exactely is the queue depth related to the max # of commands? I
ask, because with the 2.6.22 kernel the "maximum queue depth since
init" seems to be never higher than 16, even with much higher
outstanding commands. On a 2.6.19 kernel, maximum queue depth is much
higher, just a bit below "max # of commands since init".

[2.6.22]# cat /proc/driver/cciss/cciss0
cciss0: HP Smart Array 6i Controller
Board ID: 0x40910e11
Firmware Version: 2.76
IRQ: 51
Logical drives: 1
Max sectors: 2048
Current Q depth: 0
Current # commands on controller: 145
Max Q depth since init: 16
Max # commands on controller since init: 204
Max SG entries since init: 31
Sequential access devices: 0

[2.6.19] cat /proc/driver/cciss/cciss0
cciss0: HP Smart Array 6i Controller
Board ID: 0x40910e11
Firmware Version: 2.76
IRQ: 51
Logical drives: 1
Current Q depth: 0
Current # commands on controller: 0
Max Q depth since init: 197
Max # commands on controller since init: 198
Max SG entries since init: 31
Sequential access devices: 0

Cheers
Martin




--
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www:   http://www.knobisoft.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fix ALSA compilation on Sparc32

[Takashi Iwai]

At Thu, 30 Aug 2007 11:09:39 +0100,
Alan Cox wrote:
> 
> On Thu, 30 Aug 2007 11:26:04 +0200
> Markus Dahms <[EMAIL PROTECTED]> wrote:
> 
> > The dma_alloc_coherent and dma_free_coherent function seem to be not
> > available on sparc(32) architecture. It is not used by SBus sound
> > drivers, so it's disabled via #ifndef for CONFIG_SPARC32.
> 
> It would probably look a lot cleaner if you either provided dummy
> dma_alloc_coherent/free coherent inlines for SPARC32, fixed it (if
> sparc32 can do coherent DMA) or if you must ifdef it provide dummy
> functions in the memalloc code so its a single ifdef

It's been indeed inline on 2.6.22 or ealier in
include/asm-generic/dma-mapping.h, but it's changed to extern without
defining functions.

I don't think it's a good idea to have function declarations even
though we surely know that there are no real function definitions...


Takashi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/5] ALSA: cs5535audio fixes

[Takashi Iwai]

At Wed, 29 Aug 2007 23:52:08 -0400,
Jaya Kumar wrote:
> 
> On 8/29/07, Andres Salomon <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > Here are a bunch of fixes for the cs5535audio driver.  None of these are
> > OLPC specific; generic chip and power management fixes, and one cleanup
> > patch.  All have been tested on an OLPC (5536), so even though the 5535
> > data sheet claims to be the same, it would be nice to hear success/failure
> > reports from someone with a 5535.
> 
> The patches look good. I'm traveling till Sep 2nd so can't test on
> 5535 yet. Thanks very much for your efforts Andres.

OK, let me know if it works for you.  Then I'll apply them to ALSA
tree.

Thanks,

Takashi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/RESENT] hptiop: adding new firmware interface and more PCI device IDs

[Jeff Garzik]

HighPoint Linux Team wrote:

updated patch based on Jeff Garzik's comments.

- check adapter firmware version and use appropriate interface accordingly
- add new PCI device IDs and use PCI_VDEVICE macro
- update driver version string
- remove unused data structures
- remove unnecessary typecasts

Signed-off-by: HighPoint Linux Team <[EMAIL PROTECTED]>


ACK


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [4/4] 2.6.23-rc4: known regressions

[Soeren Sonnenburg]

On Wed, 2007-08-29 at 17:27 +0200, Michal Piotrowski wrote:

> Power management
> 
> Subject : something broke resume from s2ram on mbp c1d (??? :))
> References  : http://lkml.org/lkml/2007/8/28/67
> Last known good : 2.6.23-rc3
> Submitter   : Soeren Sonnenburg <[EMAIL PROTECTED]>
> Caused-By   : ?
> Handled-By  : Rafael J. Wysocki <[EMAIL PROTECTED]>
> Status  : unknown

> Subject : resume from ram much slower
> References  : http://lkml.org/lkml/2007/8/10/275
> Last known good : 2.6.23-rc1 ?
> Submitter   : Arkadiusz Miskiewicz <[EMAIL PROTECTED]>
> Caused-By   : ?
> Handled-By  : Rafael J. Wysocki <[EMAIL PROTECTED]>
> Status  : problem is being debugged


I am not sure whether the problem I am having is not the very same as
the one Arkadiusz is seeing. At least I've found resume from s2ram to be
working a couple of times. Only sometimes it took long to resume, that
is >30 seconds (around 5 - which I already consider long - is normal). 

anyway this this is with the closed source fglrx kernel module, as
without the machine freezes when X is running on resume...

well and fglrx seems to cause this ...

BUG: scheduling while atomic: Xorg/0x0002/3408
 [] schedule+0x5d2/0x6d0
 [] __wake_up+0x38/0x50
 [] irqmgr_wrap_shutdown+0xe1/0x150 [fglrx]
 [] firegl_release_helper+0x55f/0x7d0 [fglrx]
 [] firegl_takedown+0x5b/0xc40 [fglrx]
 [] firegl_release+0x12f/0x190 [fglrx]
 [] ip_firegl_release+0xf/0x20 [fglrx]
 [] __fput+0x91/0x160
 [] filp_close+0x49/0x80
 [] put_files_struct+0x9c/0xc0
 [] do_exit+0x12e/0x7c0
 [] IRQMGR_WorkerThreadRoutine+0x29/0x30 [fglrx]
 [] kasThreadRoutineHelper+0x0/0x20 [fglrx]
 [] kasThreadRoutineHelper+0x0/0x20 [fglrx]
 [] IRQMGR_CallbackWrapper+0xe/0x20 [fglrx]
 [] kasThreadRoutineHelper+0x0/0x20 [fglrx]
 [] kernel_thread_helper+0xd/0x18

well...
Soeren
-- 
Sometimes, there's a moment as you're waking, when you become aware of
the real world around you, but you're still dreaming.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [KJ][patch 3/3] VIDC20: use abs() from kernel.h instead of own definition

[Matthew Wilcox]

On Thu, Aug 30, 2007 at 12:40:38PM +0200, [EMAIL PROTECTED] wrote:
> - diff_int = my_abs(rate_ext-rate);
> - diff_ext = my_abs(rate_int-rate);
> + diff_int = abs(rate_ext-rate);
> + diff_ext = abs(rate_int-rate);

Nothing to do with the patch, but is this really correct?  Surely it
should be diff_ext = abs(rate_ext-rate) ?

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ethernet driver: hard_start_xmit

[Harsha]

Hi,

I have written a network device driver (Linux kernel: 2.6.20.1) on ARM
based target board.
I have implemented ether_tx, which is called whenever hard_start_xmit is
called.

--
[ PINGing from BOARD TO OTHER HOST ]

The network driver is working.  I am able to ping to other hosts and i
am able to get the reply without any problem

Q1.  For large packet size say (2048, 4096) after sometime ping exits
saying "sendto: buffer space unavailable"

---
[ PINGing from other HOST to BOARD ]

ping works but only for some time.  It stops working by saying "Request
timed out" after some successful pinging.
The number of times ping succeeds depend on the packet size

Packet size = 64, ping stops working exactly after 449 times
Packet size = 4096, ping stops working exactly after 28 times.

I did some digging and found that when ping stops working, ether_tx(or
hard_start_xmit) is not called at all.  Though the packets are recieved
correctly by ether_rx.  After ping stops, any more ping of any packet
size does not work. Also i found that at this stage if i ping from board
to host it works.

Q2.  What might be the reason for ping to stop?

Regards
harsha




-- 
  Harsha
  [EMAIL PROTECTED]

-- 
http://www.fastmail.fm - Accessible with your email software
  or over the web

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.22 oops kernel BUG at block/elevator.c:366!

[Arkadiusz Miskiewicz]

On Wednesday 29 of August 2007, Jens Axboe wrote:
> On Wed, Aug 29 2007, Arkadiusz Miskiewicz wrote:
> > On Wednesday 29 of August 2007, Jens Axboe wrote:
> > > On Wed, Aug 29 2007, Arkadiusz Miskiewicz wrote:
> > > > On Wednesday 29 of August 2007, Jens Axboe wrote:
> > > > > On Wed, Aug 29 2007, Arkadiusz Miskiewicz wrote:
> > > > > > I guess I should sent these here since it looks like not scsi bug
> > > > > > anyway.
> > > > >
> > > > > It's stex, right? It seems to have some issues with multiple
> > > > > completions of commands, which craps out the block layer of course.
> > > >
> > > > Yes, stex. I'm staying with 2.6.19 in that case since it works fine
> > > > in that version.
> > > >
> > > > So scsi bug ... 8-)
> > >
> > > And you based that conclusion on what exactly?
> >
> > Isn't drivers/scsi/* handled by [EMAIL PROTECTED] (that's what I mean)
>
> Yep indeed, I thought you meant that it was a scsi bug (and not an stex
> one). You could try and copy the 2.6.19 stex driver into 2.6.20 and see
> if that works, though.

Looks like this bug is known for months :-(

Ed Lin pointed to http://lkml.org/lkml/2007/1/23/268 with possible patch (that 
unfortunately serialises access to storage devices, well...)

There is also: http://bugzilla.kernel.org/show_bug.cgi?id=7842

I'm running 2.6.22 with that patch now, did huge (few hours) rsync that 
previously caused oopses and now everything works properly.

Can we get some form of this patch into Linus tree?

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.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: from which address does the kernel load initrd?

[Xu Yang]

hi peter,

thanks for your reply.

my platform is realview_eb_mpcore. the cpu is arm. not i386. and I
check the booting file in the documentation /arm , it is not
specified.

do you have any idea about that?

anyone knows?

thanks,

regards,


2007/8/29, H. Peter Anvin <[EMAIL PROTECTED]>:
> Xu Yang wrote:
> > does anyone know from which address does the kernel load the initrd? I
> > mean the default value?
> >
> > I want to boot the filesystem using a ramdisk. but the I don't know
> > where to put it in my ram? as I don't have flash , I can only load the
> > ramdisk into the ram.
> >
> > and which boot option should I use?
>
> See Documentation/i386/boot.txt
>
>-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] fix ALSA compilation on Sparc32

[Takashi Iwai]

At Thu, 30 Aug 2007 11:26:04 +0200,
Markus Dahms wrote:
> 
> The dma_alloc_coherent and dma_free_coherent function seem to be not
> available on sparc(32) architecture. It is not used by SBus sound
> drivers, so it's disabled via #ifndef for CONFIG_SPARC32.
> 
> Signed-off-by: Markus Dahms <[EMAIL PROTECTED]>

Actually, the fix has been in ALSA tree (found in git-alsa.patch in mm
tree) since long time ago, but it was never pushed. 

Jaroslav, could you push the fixes please...?


thanks,

Takashi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

kernel 2.6.22: what IS the VM doing?

[Sami Farin]

Using SMP kernel 2.6.22.6pre-CFS-v20.5 on Pentium D (IA-32).
I think this bug (or whatever you want to call it) got triggered
when you first allocate several megabytes of memory in a kernel module
and then free them, and then run e.g. X and when memory gets tight,
you end up with this situation...

Top 2 /proc/vmstat Biggest Winners:

pgrefill_normal:49900/second
pgrefill_high:20810/second

$ vmstat 1

procs ---memory-- ---swap-- -io --system-- 
-cpu--
 r  b   swpd   free   buff  cache   si   sobibo   incs us sy id wa 
st
 0  1 326020 861476  0   7384  2360   392 0   68  1100  1  1 45 54  0
 0  1 326020 861860  0   7216   64  14064   148   68  1137  0  0 48 51  0
 0  1 326020 862696  0   6772   960   108 4   55  1069  0  1 48 51  0
 0  3 326024 861352  0   8080  752  300  2540   308  191  1202  1  3 37 59  0
 0  2 326024 857464  0   9340 27680  536440  228  1589  0  2 20 77  0
 0  3 326396 857772  0   8408 1280  656  2580   664  203  1589  1  3 20 78  0
 0  3 326376 855768  0   9864 14480  3632 0  167  1488  1  2 11 87  0
 0  3 326084 854000  0  10712 18480  3228 0  180  1515  1  3  1 95  0
 0  1 326084 854204  0  10052  6280   776 0   98  1324  1  1 38 61  0
 0  1 326084 855476  0   8644  1000   33252   81  1065  1  1 48 51  0
 0  2 326084 856444  0   8180   880   396 0   84  1195  1  2 38 60  0
 0  2 319072 849068  0   9572 70080  8548 0 1820  8460  1 18 15 68  0
 2  3 303888 835724  0   8864 149000 15100 8 3800 15863  1 27 29 44 
 0

around here I rand swapoff -a

 0  2 289024 822352  0   7724 146880 14840 4 3706 17628  1 25 13 61 
 0
 0  4 270728 805104  0   7644 173840 17656 8 4388 19984  0 25 19 55 
 0
 0  3 255216 789884  0   7296 157320 15892 8 3932 19146  1 22 24 54 
 0
 2  3 241188 776476  0   6748 141920 14732 4 3550 16584  1 21  0 78 
 0
 2  4 224708 760320  0   7152 165520 17460 0 4142 18909  1 22  0 77 
 0
 2  4 211624 748112  0   6996 127160 13496 8 3226 14975  0 19  9 71 
 0
 0  4 196352 733304  0   7464 152680 1616816 3816 18359  1 25  0 74 
 0
 2  4 179580 716516  0   7112 170280 17776 9 4261 20913  1 26  6 67 
 0
procs ---memory-- ---swap-- -io --system-- 
-cpu--
 r  b   swpd   free   buff  cache   si   sobibo   incs us sy id wa 
st
 0  4 164692 701644  0   7168 148480 16276 8 3732 16751  0 19  0 80 
 0
 2  5 151980 688480  0   8140 127920 13872 0 3196 15417  0 24  0 75 
 0
 0  6 135712 672272  0   8036 164960 17484 0 4036 18392  1 22  0 78 
 0
 0  4 122128 658556  0   8116 136160 1474812 3374 16222  0 23  0 77 
 0
 0  4 109360 646788  0   7632 126480 13164 4 3176 15188  0 24  3 72 
 0
 2  5  92496 630396  0   7480 168600 17460 4 4215 19614  1 24  5 71 
 0
 0  6  78620 617316  0   7944 126880 13940 0 3229 14086  1 21  0 79 
 0
 3  3  64760 603536  0   7980 136920 14576 8 3455 16508  1 20  2 76 
 0
 0  4  50728 589352  0   8868 135520 1539620 3474 15373  0 20  2 77 
 0
 1  4  36088 575916  0   7724 146760 15208 4 3726 17567  0 27  0 72 
 0
 2  2  22896 562900  0   7748 129520 13732 0 3311 14979  1 20  0 80 
 0
 2  4   6108 547560  0   8044 151640 16300 0 3865 16899  1 24 40 35 
 0
 0  1  0 545740192   7620 38320  558865 1108  6072  1  8 38 54  0
 0  2  0 545652148   760800   332 0   63  1006  0  1 50 50  0
 0  1  0 545048 44   834400  1976 0  103  1542  1  2 42 57  0
 0  2  0 544168  0   949200  2764 4  105  1523  0  3 45 52  0
 0  1  0 543812  0   964400  1584 8  113  1397  1  2 47 51  0
 0  1  0 543836  0   950800   396 0   66   955  1  1 50 49  0
 0  1  0 544288  0   913200 8 1   53   813  0  1 50 49  0
 0  1  0 545216  0   816800   392 0   72  1489  1  1 50 48  0
 0  1  0 545684  0   749600   124 8   59  1275  1  2 47 51  0
 0  1  0 545160  0   802000   856 8   60   951  0  2 46 51  0
 0  1  0 543396  0  1005600  3144 0  146  1545  1  2 24 74  0

well did not make much difference,

$ vmstat 1 -a

procs ---memory-- ---swap-- -io --system-- 
-cpu--
 r  b   swpd   free  inact active   si   sobibo   incs us sy id wa 
st
 0  1 326084 854204   3176  18896  6280   776 0   97  1324  1  1 38 61  0
 0  1 326084 855476   2936  17696  1000   33252   82  1065  1  1 48 51  0
 0  2 326084 856444   2536  17156   880   396 0   84  1195  1  2 38 60  0
 1  1 319076 849068   2676  24404 70040  8544 0 1820  8459  1 18 15 68  0
 2  3 303920 835744   1388  39100

Re: [KJ][patch 3/3] VIDC20: use abs() from kernel.h instead of own definition

[Andre Haupt]

On Thu, Aug 30, 2007 at 05:17:47AM -0600, Matthew Wilcox wrote:
> On Thu, Aug 30, 2007 at 12:40:38PM +0200, [EMAIL PROTECTED] wrote:
> > -   diff_int = my_abs(rate_ext-rate);
> > -   diff_ext = my_abs(rate_int-rate);
> > +   diff_int = abs(rate_ext-rate);
> > +   diff_ext = abs(rate_int-rate);
> 
> Nothing to do with the patch, but is this really correct?  Surely it
> should be diff_ext = abs(rate_ext-rate) ?

hmmh, not sure about this ...

Russell?


regards,

Andre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 4/5] Net: ath5k, license is GPLv2

[Johannes Berg]

On Wed, 2007-08-29 at 15:13 +0200, Xavier Bestel wrote:

> How about asking for changes to be dual-licenced too ?

In theory, that could work, but in practice relying on functions that
the Linux kernel offers in GPLv2-only headers etc. will make the result
GPLv2 anyway, and disentangling it would be a nightmare.

johannes


signature.asc
Description: This is a digitally signed message part

Re: [PATCH] Revised timerfd() interface

[Davide Libenzi]

On Sat, 25 Aug 2007, Michael Kerrisk wrote:

> Davide -- ping!  Can you please offer your comments about this change, and
> also thoughts on Jon's and my comments about a more radical API change
> later  in this thread.

IMO the complexity of the resulting API (and resulting patch), and the ABI 
change, is not justified by the added value.



- 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/

Re: [PATCH] sysctl: Deprecate sys_sysctl in a user space visible fashion.

[Theodore Tso]

On Wed, Aug 29, 2007 at 01:00:07PM -0600, Eric W. Biederman wrote:
> "H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> 
> > Eric W. Biederman wrote:
> >>
> >> My hypothesis.  No one cares now.
> >>
> >> My observation. The way we have been maintaining the binary sysctl
> >> side of things using it is asking for your application to be broken in
> >> subtle and nasty ways.
> >>
> >
> > I suspect the right thing to do is simply to make a list of the supported 
> > binary
> > sysctls, and automatically verify those numbers.  Doing that would alleviate
> > these concerns, wouldn't break anything, and isn't really that hard to do.
> 
> Well the list is currently 1200 lines long, with wild cards in it.
> See sysctl_check.c in the -mm tree.  I think I have finally found
> all of the binary sysctl numbers that are currently in use but I may
> have missed something.  Although that can probably be trimmed a bit
> now that a number of those sysctls have been identified as impossibly
> and always broken

It's not hard to do read-side, right?  Take the list of sysctl's, and
create a program which reads it via the binary interface and the /proc
interface, and verify they are the same.  

Testing write-side, where we have to worry about permission tests,
making sure the correctr value is set, locking issues, etc., is
admittedly more difficult.  My guess though many programs/libraries
are reading from the sysctl interface than writing to 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/

Re: hda: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }

[John Sigler]

Petr Vandrovec wrote:


John Sigler wrote:


Alan Cox wrote:


Basically your dinosaur is working correctly.


What do the warnings mean? :-)


That your drive does not support set transfer mode/speed command at all, 
or that value which kernel tried is not supported by the drive...


I would guess that some contractor wrote firmware for device for PQI in 
one day for $100, and before that somebody else designed ATA-SD bridge 
for PQI for another $100.


I guess that these two printk()s happen because drive claims to support 
pio0,1,2 - so Linux tries pio2, drive refuses, Linux tries pio1, drive 
refuses, and finally as pio0 is default, that one gets used.  Which is 
more or less confirmed by having no '*' sign in front of any pio - with 
"real" drives you should see '*' in front of one of listed dma/pio modes.


You should ask reseller how they can ship drive which does not conform 
to any ATA standard...


I took drivers/ide/pci/via82cxxx.c and sprinkled ENTER/EXIT printk's.
http://lxr.linux.no/source/drivers/ide/pci/via82cxxx.c

via82cxxx_tune_drive() and via82cxxx_ide_dma_check() both call 
via_set_drive() which calls ide_config_drive_speed().


http://lxr.linux.no/source/drivers/ide/ide-iops.c#L769

  if (error)
  {
(void) ide_dump_status(drive, "set_drive_speed_status", stat);
printk(KERN_INFO "EXIT %s error\n", __func__);
return error;
  }

Does someone know why error is not set to 0?


Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot :00:07.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci:00:07.1
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: PQI IDE DiskOnModule, ATA DISK drive
ENTER via82cxxx_tune_drive
ENTER via_set_drive
ENTER ide_config_drive_speed
hda: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hda: set_drive_speed_status: error=0x04 { DriveStatusError }
EXIT ide_config_drive_speed error
ENTER via_set_speed
EXIT via_set_speed
EXIT via_set_drive
EXIT via82cxxx_tune_drive pio == 255
ENTER via82cxxx_ide_dma_check
ENTER via_set_drive
ENTER ide_config_drive_speed
hda: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hda: set_drive_speed_status: error=0x04 { DriveStatusError }
EXIT ide_config_drive_speed error
ENTER via_set_speed
EXIT via_set_speed
EXIT via_set_drive
EXIT via82cxxx_ide_dma_check
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hda: max request size: 128KiB
hda: 128000 sectors (65 MB) w/1KiB Cache, CHS=500/8/32
 hda: hda1 hda2

Regards.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [KJ][patch 3/3] VIDC20: use abs() from kernel.h instead of own definition

[Russell King]

On Thu, Aug 30, 2007 at 01:50:59PM +0200, Andre Haupt wrote:
> On Thu, Aug 30, 2007 at 05:17:47AM -0600, Matthew Wilcox wrote:
> > On Thu, Aug 30, 2007 at 12:40:38PM +0200, [EMAIL PROTECTED] wrote:
> > > - diff_int = my_abs(rate_ext-rate);
> > > - diff_ext = my_abs(rate_int-rate);
> > > + diff_int = abs(rate_ext-rate);
> > > + diff_ext = abs(rate_int-rate);
> > 
> > Nothing to do with the patch, but is this really correct?  Surely it
> > should be diff_ext = abs(rate_ext-rate) ?
> 
> hmmh, not sure about this ...

No idea.  The support for external clocking came from someone else
(I was never able to work it out myself).

I can only assume that the code as it stands does work.  So let's
remain bug-compatible until there's a proven problem.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/5] Net: ath5k, kconfig changes

[Christoph Hellwig]

On Thu, Aug 30, 2007 at 04:38:09AM +0300, Nick Kossifidis wrote:
> It saves big chunks of code (not only initial register settings
> arrays) and we'll extend it's use more inside ath5k_hw.c Trust me this
> is a very useful step, eg. check out descriptor processing / setup or
> PHY functions (calibrate/channel set etc). For example AR5210 mac chip
> only comes with RF5110 phy chip so we can get rid of RF5111/RF5112
> code, AR5211 comes with RF5111 so we can get rid of RF5110 and RF5112
> code and AR5212 comes with RF5111 or RF5112 so we get rid of RF5110.
> This thing also saves lots of checks during runtime (some of them
> happen verry frequently, eg. durring descriptor processing). Also most
> people will use 5212 code only, 5211 cards are on some old laptops and
> 5210, well i couldn't even find  a 5210 for actual testing :P

If you're doing these checks in a hotpath something is badly wrong with
your architecture.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CONFIG_HOTPLUG_CPU: kconfig bug?

[Hugh Dickins]

On Thu, 30 Aug 2007, Roman Zippel wrote:
> 
> > > > > I've noticed an oddity with CONFIG_HOTPLUG_CPU in 2.6.23-rc:
> > > > > make oldconfig seems to turn it on even when nothing wants it,
> > > > > increasing kernel size by about 10k; but if you then edit the
> > > > > line out of .config and make oldconfig again, it correctly
> > > > > offers the choice and lets it be turned off after all.
> 
> It's somewhat a side effect of using select and defaults, the order of the 
> config symbols becomes significant for oldconfig, if you look at the 
> output you'll find:
> 
> Support for suspend on SMP and hot-pluggable CPUs (EXPERIMENTAL) 
> (HOTPLUG_CPU) [Y/?] y
> 
> this sets it to 'y'. In this case one isn't asked about it, because there 
> is only one choice. The patch below avoids the setting of the value here.

Thanks for working that out: your patch certainly works for me,
and would be good to see in 2.6.23, to prevent lots of users getting
an unnecessary CONFIG_HOTPLUG_CPU forever after.  I wonder what config
options this might have forced in the past.

> 
> Avoid setting the value if the symbol doesn't need to be changed or can't 
> be changed. Later choices may change the dependencies and thus the 
> possible input range.
> 
> Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>

But please add a sentence to your patch description, something like:

make oldconfig from a 2.6.22 .config with CONFIG_HOTPLUG_CPU not set
was in some configurations setting CONFIG_HOTPLUG_CPU=y without asking,
even when there was no actual requirement for CONFIG_HOTPLUG_CPU.

Thanks,
Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Hdaps-devel] [PATCH 2.6.23-rc2] hwmon: HP Mobile Data Protection System 3D ACPI driver (resend)

[Henrique de Moraes Holschuh]

On Wed, 29 Aug 2007, Shem Multinymous wrote:
> > > I agree that the sys interface is probably not the best choice, but the
> > > accelerometer data should provide not only position, but also generate
> > > an event when it detects
> > > that it's falling. From what I understood hdaps does not have that info,
> >
> > You can generate events on input devices, but I am not sure that's the best
> > way to go about it for this.  Things that block on read until an interrupt
> > happens might work better.
> 
> You can do the latter via another (4th) input device.

We have the events that can be sent over all devices, actually (we can use
button events for this).  But blocking on read might indeed require a
separate input device... or a file, or something like that.  And we
*definately* should implement something like proper select() and poll()
support for the position sysfs attribute.

HDAPS has also some other crap that needs to go over the input device (mouse
activity, keyboard activity flags).  ams and hpmdp have the "possible shock
imminent" events, etc.  The goal is to kill all need for userspace to keep
pestering the accelerometer driver with open/read/close on sysfs attributes
constantly.

> > I'd suggest an accelerometer sysfs interface, that we implement in hdaps
> > (in and out-of-tree), ams and hpmdp.  One input device for joystick
> > emulation (optional), one input device with accelerometer data in mg or ug,
> 
> Is any of the accelerometer drivers currently capable of computing the
> physical acceleration? Also, is there an issue of linear vs. angular
> acceleration?

HDAPS is, if we add the code to calculate it.  I suppose the others can,
too, if they get the datasheets for the acceleration sensors.  However, if
it proves too difficult to calculate these values, we will have to do away
with it, and instead find a way to export what data we know about the
accelerometers (orientation, type of mesaurement, scales of measurement,
etc).

As for linear vs angular, we will have to find a way to report either: it
will depend on the accelerometer sensor.  HDAPS uses only linear, on two
axes (bad! ams and hpmdp can do it for three axes).  I know of sensors for
three axis (also linear), but it is not difficult to imagine people using
angular acceleration sensors.  Maybe we could export the type of
acceleration per-axis or somesuch using sysfs?

> Before or after axis inversion/swapping? The tp_smapi hdaps driver

After inversion.  The goal is to have something applications can use
transparently, so all input devices have to use the same orientation in all
platforms. We will have to set those in some arbitrary way, and the drivers
will have to do axis inversion when needed.

While one doesn't need (or care) about axis orientation for sudden movement
detection (where the really interesting use is :-) ) (it is enough to know
the axis are orthogonal to each other), it does matter for toys.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Average number of instructions per line of kernel code

[Mohamed Bamakhrama]

Hi all,
I have a question regarding the average number of assembly
instructions per line of kernel code. I know that this is a difficult
question since it depends on many factors such as the instruction set
architecture, compiler used, optimizations used, type of code, coding
style, etc...
I would like to know a rough estimate for such a quantity for the
kernel 2.4/2.6 code running on MIPS32 architecture.
My estimate is between 5-10 instructions. I googled for such a thing
but couldn't find any useful papers/resources.

Many thanks in advance.

Best regards

-- 
Mohamed A. Bamakhrama
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 4/5] Net: ath5k, license is GPLv2

[David Newall]

Is it actually necessary to change the license?  With the dual-license, 
you can keep a single code-base for both BSD and Linux platforms, which 
seems terribly important to me.  It'd be awful to lose that.  It would 
be a maintenance nightmare for BSD.  Is it even possible--in real life, 
I mean--to accept GPLed patches into a BSD project?  Nightmare, I tell you!

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] TASK_KILLED

[Trond Myklebust]

On Wed, 2007-08-29 at 14:40 -0600, Matthew Wilcox wrote:
> I've long hated the non-killability of tasks accessing a dead
> NFS server.  Linus had an idea for fixing this way back in 2002:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0208.0/0167.html which
> I've prototyped in this patch.
> 
> Splitting up TASK_* into separate bits is going to need a lot more
> auditing, I think.  It was easier back in 2002, but since then we've added
> TASK_STOPPED and TASK_TRACED which also need to be gingerly checked for.
> 
> There's some debug code left in here to discourage Linus from just
> applying it.
> 
> I've only added one real user of the killable concept to this patch --
> try_lock_page().  However, this is enough for 'cat */*/*' to be killable
> with a ^C when I unplug the ethernet cord between it and the nfs server.
> 
> I have another version of this patch which makes TASK_KILLABLE a separate
> state on par with TASK_INTERRUPTIBLE and TASK_UNINTERRUPTIBLE, but I
> don't like it as much as this one.  I'll post it if there's demand.
> 
> diff --git a/fs/proc/array.c b/fs/proc/array.c
> index ee4814d..6a3c876 100644
> --- a/fs/proc/array.c
> +++ b/fs/proc/array.c
> @@ -140,13 +140,8 @@ static const char *task_state_array[] = {
>  
>  static inline const char *get_task_state(struct task_struct *tsk)
>  {
> - unsigned int state = (tsk->state & (TASK_RUNNING |
> - TASK_INTERRUPTIBLE |
> - TASK_UNINTERRUPTIBLE |
> - TASK_STOPPED |
> - TASK_TRACED)) |
> - (tsk->exit_state & (EXIT_ZOMBIE |
> - EXIT_DEAD));
> + unsigned int state = (tsk->state & TASK_REPORT) |
> + (tsk->exit_state & (EXIT_ZOMBIE | EXIT_DEAD));
>   const char **p = &task_state_array[0];
>  
>   while (state) {
> diff --git a/fs/read_write.c b/fs/read_write.c
> index 507ddff..29e3f21 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -220,7 +220,7 @@ Einval:
>  
>  static void wait_on_retry_sync_kiocb(struct kiocb *iocb)
>  {
> - set_current_state(TASK_UNINTERRUPTIBLE);
> + set_current_state(TASK_KILLABLE);
>   if (!kiocbIsKicked(iocb))
>   schedule();
>   else

Won't this change just cause functions like do_sync_read() and
do_sync_write() to loop forever when you kill the process?

> diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
> index 8a83537..56675e4 100644
> --- a/include/linux/pagemap.h
> +++ b/include/linux/pagemap.h
> @@ -154,6 +154,7 @@ static inline pgoff_t linear_page_index(struct 
> vm_area_struct *vma,
>  }
>  
>  extern void FASTCALL(__lock_page(struct page *page));
> +extern int FASTCALL(__try_lock_page(struct page *page));
>  extern void FASTCALL(__lock_page_nosync(struct page *page));
>  extern void FASTCALL(unlock_page(struct page *page));
>  
> @@ -168,6 +169,18 @@ static inline void lock_page(struct page *page)
>  }
>  
>  /*
> + * try_lock_page is like lock_page but sleeps killably.  It returns
> + * 1 if it locked the page and 0 if it was killed while waiting.
> + */
> +static inline int try_lock_page(struct page *page)
> +{
> + might_sleep();
> + if (TestSetPageLocked(page))
> + return __try_lock_page(page);
> + return 1;
> +}
> +
> +/*
>   * lock_page_nosync should only be used if we can't pin the page's inode.
>   * Doesn't play quite so well with block device plugging.
>   */
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index bd6a032..c0c7d7c 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -165,16 +165,35 @@ print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq 
> *cfs_rq)
>   * mistake.
>   */
>  #define TASK_RUNNING 0
> -#define TASK_INTERRUPTIBLE   1
> -#define TASK_UNINTERRUPTIBLE 2
> -#define TASK_STOPPED 4
> -#define TASK_TRACED  8
> +#define __TASK_INTERRUPTIBLE 1
> +#define __TASK_UNINTERRUPTIBLE   2
> +#define __TASK_STOPPED   4
> +#define __TASK_TRACED8
>  /* in tsk->exit_state */
>  #define EXIT_ZOMBIE  16
>  #define EXIT_DEAD32
>  /* in tsk->state again */
>  #define TASK_NONINTERACTIVE  64
>  #define TASK_DEAD128
> +#define TASK_WAKEKILL256
> +#define TASK_WAKESIGNAL  512
> +#define TASK_LOADAVG 1024
> +
> +/* Convenience macros for the sake of set_task_state */
> +#define TASK_INTERRUPTIBLE   (TASK_WAKESIGNAL | __TASK_INTERRUPTIBLE)
> +#define TASK_UNINTERRUPTIBLE (TASK_LOADAVG | __TASK_UNINTERRUPTIBLE)
> +#define TASK_KILLABLE(TASK_WAKEKILL | TASK_UNINTERRUPTIBLE)
> +#define TASK_STOPPED (TASK_WAKEKILL | __TASK_STOPPED)
> +#define TASK_TRACED  (TASK_WAKEKILL | __TASK_TRACED)
> +
> +/* Convenience macros for the sake of wake_up */
> +#define TASK_NORMAL  (__TASK_INTERRUPTIBLE | 

Re: [PATCH 3/5] Net: ath5k, use int as retval

[John W. Linville]

On Tue, Aug 28, 2007 at 12:00:09PM -0400, Jiri Slaby wrote:
> ath5k, use int as retval
> 
> Convert some functions to return int and proper negative return value on
> error as we are used to.

Since I didn't apply 1/5, this one didn't apply either.  It seems
fine overall, so if you rediff I'll be happy to apply.

John
-- 
John W. Linville
[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 5/5] Net: ath5k, kconfig changes

[John W. Linville]

On Thu, Aug 30, 2007 at 04:38:09AM +0300, Nick Kossifidis wrote:
> 2007/8/28, Christoph Hellwig <[EMAIL PROTECTED]>:

> > Also this whole patch seems rather pointless.  It saves only
> > very little and turns the driver into a complete ifdef maze.

> Also most
> people will use 5212 code only, 5211 cards are on some old laptops and
> 5210, well i couldn't even find  a 5210 for actual testing :P

FWIW, I'd bet dollars to donuts that distros will enable them all
together.

Is saving code space the only reason to turn these off?  How much
space do you save?

Is there some way you can isolate and/or limit the number of ifdef
blocks further?  If so, we might consider a version of this patch
that depends on EMBEDDED or somesuch...?

John
-- 
John W. Linville
[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] sysctl: Deprecate sys_sysctl in a user space visible fashion.

[David Newall]

Eric W. Biederman wrote:

This isn't "Oh some apps are using it let's get them to stop, because
it is inconvenient".  This is  "No apps seems to be using this, we
keep goofing up the maintenance and no one notices, and so it is
likely a source of security problems and other nasties"
  


This first claim is not consistent with the next claim:


I have evidence that there are 1 or 2 open source applications using
this (not counting the glibc weirdness).


If may be unmaintainable but, apparently, it's not really unused.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 patch] remove securebits

[Serge E. Hallyn]

Quoting Andrew Morgan ([EMAIL PROTECTED]):
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Serge E. Hallyn wrote:
> > To summarize more clearly, I think that so long as we support
> > process trees with a sort of !SECURE_NOROOT support, that
> > support should include the ability to use prctl(KEEP_CAPS) the
> > way one uses it now.
> 
> > When a process tree is in strict capability mode,
> > prctl(PR_{G,S}ET_KEEP_CAPS) should return -EINVAL.
> 
> I agree. I'll try to code it up in a way that its clear how to delete
> this functionality when folk realize they no longer need it...
> 
> - -static inline int get_file_caps(struct linux_binprm *bprm)
> +int cap_bprm_set_security(struct linux_binprm *bprm)
>  {
>   bprm_clear_caps(bprm);
> + bprm_force_uid0_caps(bprm);
> + current->keep_capabilities = 0;
> 
> > This is being moved from bprm_apply to bprm_set, which moves it
> > earlier.  If exec fails later on, keep_capabilities might be set
> > to 0 even though exec failed.
> 
> I'll look at it again, but I had thought I had preserved the previous
> behavior with this condensed version of the code. Are you suggesting an
> improvement to what was there, or pointing out I'm inadvertently
> breaking the old behavior?

Well it's just 'breaking' old behavior in certain error cases.  I.e. if
audit fails, or no handler is found for the binary, we never reach
compute_creds (which is called from within the binary loader), so in 
the past keep_capabilities would have remained 1 until something was
actually executed.  Now in all likelyhood the process would try to
exec something else, but if it should happen to decide to setuid()
instead, with your patch keep_capabilities will have been unexpectedly
set to 0 during the failed exec attempt.

-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Average number of instructions per line of kernel code

[Jesper Juhl]

On 30/08/2007, Mohamed Bamakhrama <[EMAIL PROTECTED]> wrote:
> Hi all,
> I have a question regarding the average number of assembly
> instructions per line of kernel code. I know that this is a difficult
> question since it depends on many factors such as the instruction set
> architecture, compiler used, optimizations used, type of code, coding
> style, etc...
> I would like to know a rough estimate for such a quantity for the
> kernel 2.4/2.6 code running on MIPS32 architecture.
> My estimate is between 5-10 instructions. I googled for such a thing
> but couldn't find any useful papers/resources.
>

Why don't you simply count the number of non-blank non-comment lines
in the source files that you are building, build the kernel and then
count the number of instructions in the resulting binary ?

-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/5] Net: ath5k, license is GPLv2

[Jarek Poplawski]

On 30-08-2007 13:59, Johannes Berg wrote:
> On Wed, 2007-08-29 at 15:13 +0200, Xavier Bestel wrote:
> 
>> How about asking for changes to be dual-licenced too ?
> 
> In theory, that could work, but in practice relying on functions that
> the Linux kernel offers in GPLv2-only headers etc. will make the result
> GPLv2 anyway, and disentangling it would be a nightmare.
> 

Why?

Very good point, but, in my opinion, it should be still resonable for
both sides: it simply means such changes are mostly unusable for the
other side, but nobody is going to waste time for marking all these
places, or care about suing if accidentally the changes, after some
adaptation, are usable for the other side. Unless you think or know
that "#include xyz" or "print_linux_way()" should add more than these
(maybe unusable) words or lines only?

Jarek P.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Average number of instructions per line of kernel code

[Mohamed Bamakhrama]

On 8/30/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> On 30/08/2007, Mohamed Bamakhrama <[EMAIL PROTECTED]> wrote:
> > Hi all,
> > I have a question regarding the average number of assembly
> > instructions per line of kernel code. I know that this is a difficult
> > question since it depends on many factors such as the instruction set
> > architecture, compiler used, optimizations used, type of code, coding
> > style, etc...
> > I would like to know a rough estimate for such a quantity for the
> > kernel 2.4/2.6 code running on MIPS32 architecture.
> > My estimate is between 5-10 instructions. I googled for such a thing
> > but couldn't find any useful papers/resources.
> >
>
> Why don't you simply count the number of non-blank non-comment lines
> in the source files that you are building, build the kernel and then
> count the number of instructions in the resulting binary ?

Hi,
I agree with you but is there any way to include ALL the drivers in
the kernel tree in building the image? Otherwise, I will be counting
un-used lines.

-- 
Mohamed
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Designers and Builders (was: Who wants to maintain KR list for stable releases?)

[Al Boldi]

Adrian Bunk wrote:
> On Thu, Aug 30, 2007 at 07:31:24AM +0300, Al Boldi wrote:
> > Adrian Bunk wrote
> >
> > > Tracking feature or implementation suggestions wouldn't make sense.
> > > Consider e.g. that there are several people on linux-kernel who often
> > > write what they think the kernel should do but who never write a
> > > single line of code themselves. There's no value in tracking such
> > > stuff.
> >
> > There are designers, and there are builders.
> >
> > Can you tell me who is more important?
>
> That's a distinction that doesn't exist in practice:
>
> Designing kernel features requires good knowledge of the area of the
> kernel that should be changed.
>
> IOW: If you don't have the skills to implement it yourself you don't
> have the skills to do any good design.

I might agree with you on this wrt hacking around the kernel, but when it 
comes to introducing new subsystems, then we have a two fold situation:

  1.  Designing the internals of the new subsystem
  2.  Interfacing it with the rest of the kernel

Part 1 is completely independent of the implementation, it's part 2 that 
needs intricate implementation knowledge.

We recently had an example of this:  kexec based hibernation

So, what's wrong with tapping into people's design suggestions, and allowing 
others to implement it?


Thanks!

--
Al

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Override 80-wire cable detection for Toshiba S1800-814

[Al Boldi]

Alan Cox wrote:
> > Wow!  I have been running 80wire cable detection override on 40wire
> > cables for quite some time without any problem, but I never thought it
> > to be legal if the 40wire cable length is short enough.
>
> Yes.
>
> > How short does it have to be, and can't we have a kernel bootparm to
> > override the cable detection?
>
> For most users the goal should be to automate behaviour. It should just
> work.

What's the max length of a 40wire cable to sustain 80wire cable 
characteristics?


Thanks!

--
Al

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Average number of instructions per line of kernel code

[Jesper Juhl]

On 30/08/2007, Mohamed Bamakhrama <[EMAIL PROTECTED]> wrote:
> On 8/30/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> > On 30/08/2007, Mohamed Bamakhrama <[EMAIL PROTECTED]> wrote:
> > > Hi all,
> > > I have a question regarding the average number of assembly
> > > instructions per line of kernel code. I know that this is a difficult
> > > question since it depends on many factors such as the instruction set
> > > architecture, compiler used, optimizations used, type of code, coding
> > > style, etc...
> > > I would like to know a rough estimate for such a quantity for the
> > > kernel 2.4/2.6 code running on MIPS32 architecture.
> > > My estimate is between 5-10 instructions. I googled for such a thing
> > > but couldn't find any useful papers/resources.
> > >
> >
> > Why don't you simply count the number of non-blank non-comment lines
> > in the source files that you are building, build the kernel and then
> > count the number of instructions in the resulting binary ?
>
> Hi,
> I agree with you but is there any way to include ALL the drivers in
> the kernel tree in building the image? Otherwise, I will be counting
> un-used lines.
>
make allyesconfig
make


-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

i2c transfers during interrupt context

[Francis Moreau]

Hello,

I have a very simple question about i2c transfers.

I'm wondering if I'm allowed to initiate some very short i2c transfers
in an interrupt handler.

Thanks for your answers.
--
Francis


-- 
Francis
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] i386 and x86_64: randomize brk()

[Jiri Kosina]

[resending, as discussed last week, thanks]


From: Jiri Kosina <[EMAIL PROTECTED]>

i386 and x86_64: randomize brk()

This patch randomizes the location of the heap (brk) for i386 and x86_64. 
The range is randomized in the range starting at current brk location up 
to 0x0200 offset for both architectures. This, together with 
pie-executable-randomization.patch and 
pie-executable-randomization-fix.patch, should make the address space 
randomization on i386 and x86_64 complete.

Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>

diff --git a/arch/i386/kernel/process.c b/arch/i386/kernel/process.c
index 8466471..5817749 100644
--- a/arch/i386/kernel/process.c
+++ b/arch/i386/kernel/process.c
@@ -949,3 +949,15 @@ unsigned long arch_align_stack(unsigned long sp)
sp -= get_random_int() % 8192;
return sp & ~0xf;
 }
+
+void arch_randomize_brk(void)
+{
+   unsigned long new_brk, range_start, range_end;
+
+   range_start = current->mm->brk;
+   range_end = range_start + 0x0200;
+   new_brk = randomize_range(range_start, range_end, 0);
+   if (new_brk)
+   current->mm->brk = current->mm->start_brk = new_brk;
+}
+
diff --git a/arch/x86_64/ia32/ia32_binfmt.c b/arch/x86_64/ia32/ia32_binfmt.c
index dffd2ac..ccc4350 100644
--- a/arch/x86_64/ia32/ia32_binfmt.c
+++ b/arch/x86_64/ia32/ia32_binfmt.c
@@ -262,6 +262,7 @@ static void elf32_init(struct pt_regs *);
 #define ARCH_HAS_SETUP_ADDITIONAL_PAGES 1
 #define arch_setup_additional_pages syscall32_setup_pages
 extern int syscall32_setup_pages(struct linux_binprm *, int exstack);
+extern void arch_randomize_brk(void);
 
 #include "../../../fs/binfmt_elf.c" 
 
diff --git a/arch/x86_64/kernel/process.c b/arch/x86_64/kernel/process.c
index 2842f50..5c3953c 100644
--- a/arch/x86_64/kernel/process.c
+++ b/arch/x86_64/kernel/process.c
@@ -902,3 +902,15 @@ unsigned long arch_align_stack(unsigned long sp)
sp -= get_random_int() % 8192;
return sp & ~0xf;
 }
+
+void arch_randomize_brk(void)
+{
+   unsigned long new_brk, range_start, range_end;
+
+   range_start = current->mm->brk;
+   range_end = range_start + 0x0200;
+   new_brk = randomize_range(range_start, range_end, 0);
+   if (new_brk)
+   current->mm->brk = current->mm->start_brk = new_brk;
+}
+
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index d65f1d9..4c92461 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1073,6 +1073,9 @@ static int load_elf_binary(struct linux_binprm *bprm, 
struct pt_regs *regs)
current->mm->end_data = end_data;
current->mm->start_stack = bprm->p;
 
+   if (current->flags & PF_RANDOMIZE)
+   arch_randomize_brk();
+
if (current->personality & MMAP_PAGE_ZERO) {
/* Why this, you ask???  Well SVr4 maps page 0 as read-only,
   and some applications "depend" upon this behavior.
diff --git a/include/asm-alpha/elf.h b/include/asm-alpha/elf.h
index 6c2d78f..18210cc 100644
--- a/include/asm-alpha/elf.h
+++ b/include/asm-alpha/elf.h
@@ -163,5 +163,9 @@ extern int alpha_l3_cacheshape;
 NEW_AUX_ENT(AT_L3_CACHESHAPE, alpha_l3_cacheshape);\
   } while (0)
 
+static inline void arch_randomize_brk(void)
+{
+}
+
 #endif /* __KERNEL__ */
 #endif /* __ASM_ALPHA_ELF_H */
diff --git a/include/asm-arm/elf.h b/include/asm-arm/elf.h
index ec1c685..e3f 100644
--- a/include/asm-arm/elf.h
+++ b/include/asm-arm/elf.h
@@ -116,4 +116,8 @@ extern char elf_platform[];
 
 #endif
 
+static inline void arch_randomize_brk(void)
+{
+}
+
 #endif
diff --git a/include/asm-avr32/elf.h b/include/asm-avr32/elf.h
index d334b49..61b7d81 100644
--- a/include/asm-avr32/elf.h
+++ b/include/asm-avr32/elf.h
@@ -107,4 +107,8 @@ typedef struct user_fpu_struct elf_fpregset_t;
 #define SET_PERSONALITY(ex, ibcs2) set_personality(PER_LINUX_32BIT)
 #endif
 
+static inline void arch_randomize_brk(void)
+{
+}
+
 #endif /* __ASM_AVR32_ELF_H */
diff --git a/include/asm-blackfin/elf.h b/include/asm-blackfin/elf.h
index 5264b55..9223b86 100644
--- a/include/asm-blackfin/elf.h
+++ b/include/asm-blackfin/elf.h
@@ -124,4 +124,8 @@ do {
\
 #define SET_PERSONALITY(ex, ibcs2) set_personality((ibcs2)?PER_SVR4:PER_LINUX)
 #endif
 
+static inline void arch_randomize_brk(void)
+{
+}
+
 #endif
diff --git a/include/asm-cris/elf.h b/include/asm-cris/elf.h
index 96a40c1..10607c7 100644
--- a/include/asm-cris/elf.h
+++ b/include/asm-cris/elf.h
@@ -93,4 +93,8 @@ typedef unsigned long elf_fpregset_t;
 
 #endif /* __KERNEL__ */
 
+static inline void arch_randomize_brk(void)
+{
+}
+
 #endif
diff --git a/include/asm-frv/elf.h b/include/asm-frv/elf.h
index 7df58a3..07df9dd 100644
--- a/include/asm-frv/elf.h
+++ b/include/asm-frv/elf.h
@@ -141,4 +141,8 @@ do {
\
 #define SET_PERSONALITY(ex, i

Re: hda: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }

[Alan Cox]

>  Buffer size: 1.0kB  bytes avail on r/w long: 4
> 
> (Assuming an 8-bit byte, 4 bytes = 32 bits)

R/W Long is a different thing.

> When you say "the current libata IDE" do you mean PATA_VIA (in my case)?
> I've avoided this driver because it is marked EXPERIMENTAL. Would there 
> be any benefit in using it over the legacy ATA/MFM/RLL driver?

Just less warning messages

> > Basically your dinosaur is working correctly.
> 
> What do the warnings mean? :-)

Old IDE wrongly tries to issue a set features command for PIO2 to the
device. It rejects it and old IDE carries on happy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: speeding up swapoff

[Helge Hafting]

Robert Hancock wrote:

Daniel Drake wrote:

On Wed, 2007-08-29 at 07:30 -0700, Arjan van de Ven wrote:

My experiments show that when there is not much free physical memory,
swapoff moves pages out of swap at a rate of approximately 5mb/sec.

sounds like about disk speed (at random-seek IO pattern)


We are only using 'standard' seagate SATA disks, but I would have
thought much more performance (40+ mb/sec) would be reachable.


Not if it is doing random seeks..

If the swap device is full, then there is no need for random
seeks as the swap pages can be read in disk order. A not
so full swap will skip over the unused areas, the time
needed should still be limited to the time needed for reading the
whole swap device.

If this optimization is worth it is another problem though.

Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.23] ibmebus: Prevent bus_id collisions

[Joachim Fenkes]

Nathan Lynch <[EMAIL PROTECTED]> wrote on 29.08.2007 20:12:32:

> > Previously, ibmebus derived a device's bus_id from its location code. 
The
> > location code is not guaranteed to be unique, so we might get bus_id
> > collisions if two devices share the same location code. The OFDT 
full_name,
> > however, is unique, so we use that instead.
> 
> This is a userspace-visible change, but I guess it's unavoidable.
> Will anything break?

Nope. Userspace programs should not depend on ibmebus' way of naming the 
devices; especially since some overly long loc_codes tended to be 
truncated and thus rendered useless. I have tested IBM's DLPAR tools 
against the changed kernel, and they didn't break.
 
> Also, I dislike this approach of duplicating the firmware device tree
> path in sysfs.

Why? Any specific reasons for your dislike?

> Are GX/ibmebus devices guaranteed to be children of
> the same node in the OF device tree?  If so, their unit addresses will
> be unique, and therefore suitable values for bus_id.  I believe this
> is what the powerpc vio bus code does.

While there's no such guarantee (as in "officially signed document"), yes, 
I expect future GX devices to also appear beneath the OFDT root node. For 
the existing devices, the unit addresses are already part of the device 
name, so I save the need to use sprintf() again. Plus, I rather like using 
the full_name since it also contains a descriptive name as opposed to 
being just nondescript numbers, helping the layman (ie user) to make sense 
out of a dev_id.

jschopp <[EMAIL PROTECTED]> wrote on 29.08.2007 20:33:30:

> > +   len = strlen(dn->full_name + 1);
> > +   bus_len = min(len, BUS_ID_SIZE - 1);
> > +   memcpy(dev->ofdev.dev.bus_id, dn->full_name + 1
> > +  + (len - bus_len), bus_len);
> > +   for (i = 0; i < bus_len; i++)
> > +  if (dev->ofdev.dev.bus_id[i] == '/')
> > + dev->ofdev.dev.bus_id[i] = '_';
> > 
> > /* Register with generic device framework. */
> > if (ibmebus_register_device_common(dev, dn->name) != 0) {
> 
> What happens when the full name is > 31 characters?  It looks to me that 
it 
> will be truncated, which takes away the uniqueness guarantee.

There are currently two GX devices, eHCA and eHEA, which both reside 
beneath the root node - this is required by architecture for those 
devices. Unless they invent a device called 
"supercalifragilisticexpialidocious", devices in the root note will have a 
full_name of less than 31 chars. Even in that case, the truncation occurs 
at the beginning, so the @xxx part that makes the nodes unique will stay 
in place.

If any more GX devices appear on the scene, I expect them to appear in the 
root node as well. The substitution of "/" by "_" is a safeguard so 
possible weird OFDT setups don't break the kernel.
 
> There must be an individual property that is guaranteed to be unique and 

> less than 32 characters.  How about "ibm,my-drc-index"?  That looks like 
a 
> good candidate.

On first glance, it does, however the attribute might not be present in 
all cases. Architecture states it only needs to be present on systems with 
dynamic reconfiguration enabled.

All things considered, I still like the idea of using the full_name most. 
No offense.

Regards,
  Joachim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] i386 and x86_64: randomize brk()

[Mike Frysinger]

On 8/30/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
> From: Jiri Kosina <[EMAIL PROTECTED]>
>
> i386 and x86_64: randomize brk()
>
> This patch randomizes the location of the heap (brk) for i386 and x86_64.
> The range is randomized in the range starting at current brk location up
> to 0x0200 offset for both architectures. This, together with
> pie-executable-randomization.patch and
> pie-executable-randomization-fix.patch, should make the address space
> randomization on i386 and x86_64 complete.
>
> Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>

does it really make sense to stick stubs into no-mmu ports which
cannot utilize the ELF binfmt ?
-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: speeding up swapoff

[Xavier Bestel]

On Thu, 2007-08-30 at 15:55 +0200, Helge Hafting wrote:
> If the swap device is full, then there is no need for random
> seeks as the swap pages can be read in disk order.

If the swap file is full, you probably have a machine dead into a swap
storm.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

parse_tag_ramdisk

[Xu Yang]

Hi guys,


I found that in the function parse_tag_ramdisk , the setup_ramdisk is
called. is it true that in the setup_ramdisk the location ot the
initrd is specified?

it seems that in my case the parse_tag_ramdisk is never accessed. what
might cause this?

in the parse_tag_ramdisk  the tag should be specified, where to
specify the "tag" and how?

thanks your answer is appreciated.

regards,

yang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.23-rc3-mm1 - vdso and gettimeofday issues with glibc

[Valdis . Kletnieks]

On Wed, 29 Aug 2007 16:15:45 PDT, Andrew Morton said:

> So it's an interaction between the x86_64 vdso patches in Andi's tree and 
> newer glibc, and we don't know which one is getting it wrong yet?
> 
> If I ever get another -mm out the door (have been without electricity for
> several days) I'll drop the vdso changes until this is sorted out.

Don't bother, I tested this last night against a vanilla 2.6.23-rc3 kernel
and it had the same issue as well.  So Andi's vdso patches in his tree and/or
the -mm kernel aren't to blame - it's in mainline as well.  And it's been
in for a while - I also hit it with a 2.6.22-rc6-mm1 kernel.



pgp5nj924gJUL.pgp
Description: PGP signature

Re: speeding up swapoff

[Helge Hafting]

Xavier Bestel wrote:

On Thu, 2007-08-30 at 15:55 +0200, Helge Hafting wrote:
  

If the swap device is full, then there is no need for random
seeks as the swap pages can be read in disk order.



If the swap file is full, you probably have a machine dead into a swap
storm.

Only if you have enough swap. :-)

Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

NFS4 authentification / fsuid

[Jan Engelhardt]

Hi,


with NFS3, there is this 'root hole', i.e. any person who has a root 
account (perhaps by use of a laptop) can mount an export (let's say this 
export had the "root_squash" option), and still have a look at the user 
files, because he can locally setuid() into another user.

So I was looking for alternatives. CIFS is my favorite candidate, but it 
has a few issues right now. So does sshfs and about everything I have 
come across. Since I remember NFS4 can use KRB5 authentification, my 
question is, will the NFS(4) server process run with an fsuid equal to 
the user that authenticated?


thanks,
Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: speeding up swapoff

[Xavier Bestel]

On Thu, 2007-08-30 at 16:06 +0200, Helge Hafting wrote:
> Xavier Bestel wrote:
> > On Thu, 2007-08-30 at 15:55 +0200, Helge Hafting wrote:
> >   
> >> If the swap device is full, then there is no need for random
> >> seeks as the swap pages can be read in disk order.
> >> 
> >
> > If the swap file is full, you probably have a machine dead into a swap
> > storm.
> Only if you have enough swap. :-)

Yeah, sure. But these days disk space is cheap and I tend to put too big
swap partitions, and I always regret it later ...

Xav


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] bug in AT91 MCI suspend routines

[Nicolas Ferre]

From: Anti Sullin <[EMAIL PROTECTED]>

This patch fixes a bug in AT91 mmc host driver, that enables the wakeup 
from suspend on card detection pin even if the card detect pin is not 
available (==0). If not card detection pin is defined, IRQ0 == FIQ gets 
enabled and if some activity is present on that pin, the system gets a 
FIQ request, that causes a crash.


Signed-off-by: Anti Sullin <[EMAIL PROTECTED]>
Signed-off-by: Nicolas Ferre <[EMAIL PROTECTED]>
---

Original patch from Anti Sullin reviewed by Andrew Victor and
Marc Pignat ; thank you to all of you.

drivers/mmc/host/at91_mci.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

Index: linux-2.6-snapshot/drivers/mmc/host/at91_mci.c
===
--- linux-2.6-snapshot.orig/drivers/mmc/host/at91_mci.c
+++ linux-2.6-snapshot/drivers/mmc/host/at91_mci.c
@@ -941,7 +941,7 @@ static int __exit at91_mci_remove(struct

host = mmc_priv(mmc);

-   if (host->present != -1) {
+   if (host->board->det_pin) {
device_init_wakeup(&pdev->dev, 0);
free_irq(host->board->det_pin, host);
cancel_delayed_work(&host->mmc->detect);
@@ -972,7 +972,7 @@ static int at91_mci_suspend(struct platf
struct at91mci_host *host = mmc_priv(mmc);
int ret = 0;

-   if (device_may_wakeup(&pdev->dev))
+   if (host->board->det_pin && device_may_wakeup(&pdev->dev))
enable_irq_wake(host->board->det_pin);

if (mmc)
@@ -987,7 +987,7 @@ static int at91_mci_resume(struct platfo
struct at91mci_host *host = mmc_priv(mmc);
int ret = 0;

-   if (device_may_wakeup(&pdev->dev))
+   if (host->board->det_pin && device_may_wakeup(&pdev->dev))
disable_irq_wake(host->board->det_pin);

if (mmc)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Designers and Builders (was: Who wants to maintain KR list for stable releases?)

[Adrian Bunk]

On Thu, Aug 30, 2007 at 04:54:24PM +0300, Al Boldi wrote:
> Adrian Bunk wrote:
> > On Thu, Aug 30, 2007 at 07:31:24AM +0300, Al Boldi wrote:
> > > Adrian Bunk wrote
> > >
> > > > Tracking feature or implementation suggestions wouldn't make sense.
> > > > Consider e.g. that there are several people on linux-kernel who often
> > > > write what they think the kernel should do but who never write a
> > > > single line of code themselves. There's no value in tracking such
> > > > stuff.
> > >
> > > There are designers, and there are builders.
> > >
> > > Can you tell me who is more important?
> >
> > That's a distinction that doesn't exist in practice:
> >
> > Designing kernel features requires good knowledge of the area of the
> > kernel that should be changed.
> >
> > IOW: If you don't have the skills to implement it yourself you don't
> > have the skills to do any good design.
> 
> I might agree with you on this wrt hacking around the kernel, but when it 
> comes to introducing new subsystems, then we have a two fold situation:
> 
>   1.  Designing the internals of the new subsystem
>   2.  Interfacing it with the rest of the kernel
> 
> Part 1 is completely independent of the implementation, it's part 2 that 
> needs intricate implementation knowledge.

That's a perfect approach that works NOT.

Your subsystem needs to interact with the VFS or the block layer or 
whatever else parts of the kernel.

If you had ever written kernel code you would have known that your 
statement wasn't true.

> We recently had an example of this:  kexec based hibernation
> 
> So, what's wrong with tapping into people's design suggestions, and allowing 
> others to implement it?

People soon realize that you are making a fool of yourself when your 
suggestions show that you don't have a clue what you are talking about.

There's nothing wrong if this is the desired effect...

> Thanks!
> Al

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i386 and x86_64: randomize brk()

[Jiri Kosina]

On Thu, 30 Aug 2007, Mike Frysinger wrote:

> does it really make sense to stick stubs into no-mmu ports which cannot 
> utilize the ELF binfmt ?

Good point, thanks. I have removed the stubs for h8300 and m68knommu.


From: Jiri Kosina <[EMAIL PROTECTED]>

i386 and x86_64: randomize brk()

This patch randomizes the location of the heap (brk) for i386 and x86_64. 
The range is randomized in the range starting at current brk location up 
to 0x0200 offset for both architectures. This, together with 
pie-executable-randomization.patch and 
pie-executable-randomization-fix.patch, should make the address space 
randomization on i386 and x86_64 complete.

Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>

diff --git a/arch/i386/kernel/process.c b/arch/i386/kernel/process.c
index 8466471..5817749 100644
--- a/arch/i386/kernel/process.c
+++ b/arch/i386/kernel/process.c
@@ -949,3 +949,15 @@ unsigned long arch_align_stack(unsigned long sp)
sp -= get_random_int() % 8192;
return sp & ~0xf;
 }
+
+void arch_randomize_brk(void)
+{
+   unsigned long new_brk, range_start, range_end;
+
+   range_start = current->mm->brk;
+   range_end = range_start + 0x0200;
+   new_brk = randomize_range(range_start, range_end, 0);
+   if (new_brk)
+   current->mm->brk = current->mm->start_brk = new_brk;
+}
+
diff --git a/arch/x86_64/ia32/ia32_binfmt.c b/arch/x86_64/ia32/ia32_binfmt.c
index dffd2ac..ccc4350 100644
--- a/arch/x86_64/ia32/ia32_binfmt.c
+++ b/arch/x86_64/ia32/ia32_binfmt.c
@@ -262,6 +262,7 @@ static void elf32_init(struct pt_regs *);
 #define ARCH_HAS_SETUP_ADDITIONAL_PAGES 1
 #define arch_setup_additional_pages syscall32_setup_pages
 extern int syscall32_setup_pages(struct linux_binprm *, int exstack);
+extern void arch_randomize_brk(void);
 
 #include "../../../fs/binfmt_elf.c" 
 
diff --git a/arch/x86_64/kernel/process.c b/arch/x86_64/kernel/process.c
index 2842f50..5c3953c 100644
--- a/arch/x86_64/kernel/process.c
+++ b/arch/x86_64/kernel/process.c
@@ -902,3 +902,15 @@ unsigned long arch_align_stack(unsigned long sp)
sp -= get_random_int() % 8192;
return sp & ~0xf;
 }
+
+void arch_randomize_brk(void)
+{
+   unsigned long new_brk, range_start, range_end;
+
+   range_start = current->mm->brk;
+   range_end = range_start + 0x0200;
+   new_brk = randomize_range(range_start, range_end, 0);
+   if (new_brk)
+   current->mm->brk = current->mm->start_brk = new_brk;
+}
+
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index d65f1d9..4c92461 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1073,6 +1073,9 @@ static int load_elf_binary(struct linux_binprm *bprm, 
struct pt_regs *regs)
current->mm->end_data = end_data;
current->mm->start_stack = bprm->p;
 
+   if (current->flags & PF_RANDOMIZE)
+   arch_randomize_brk();
+
if (current->personality & MMAP_PAGE_ZERO) {
/* Why this, you ask???  Well SVr4 maps page 0 as read-only,
   and some applications "depend" upon this behavior.
diff --git a/include/asm-alpha/elf.h b/include/asm-alpha/elf.h
index 6c2d78f..18210cc 100644
--- a/include/asm-alpha/elf.h
+++ b/include/asm-alpha/elf.h
@@ -163,5 +163,9 @@ extern int alpha_l3_cacheshape;
 NEW_AUX_ENT(AT_L3_CACHESHAPE, alpha_l3_cacheshape);\
   } while (0)
 
+static inline void arch_randomize_brk(void)
+{
+}
+
 #endif /* __KERNEL__ */
 #endif /* __ASM_ALPHA_ELF_H */
diff --git a/include/asm-arm/elf.h b/include/asm-arm/elf.h
index ec1c685..e3f 100644
--- a/include/asm-arm/elf.h
+++ b/include/asm-arm/elf.h
@@ -116,4 +116,8 @@ extern char elf_platform[];
 
 #endif
 
+static inline void arch_randomize_brk(void)
+{
+}
+
 #endif
diff --git a/include/asm-avr32/elf.h b/include/asm-avr32/elf.h
index d334b49..61b7d81 100644
--- a/include/asm-avr32/elf.h
+++ b/include/asm-avr32/elf.h
@@ -107,4 +107,8 @@ typedef struct user_fpu_struct elf_fpregset_t;
 #define SET_PERSONALITY(ex, ibcs2) set_personality(PER_LINUX_32BIT)
 #endif
 
+static inline void arch_randomize_brk(void)
+{
+}
+
 #endif /* __ASM_AVR32_ELF_H */
diff --git a/include/asm-blackfin/elf.h b/include/asm-blackfin/elf.h
index 5264b55..9223b86 100644
--- a/include/asm-blackfin/elf.h
+++ b/include/asm-blackfin/elf.h
@@ -124,4 +124,8 @@ do {
\
 #define SET_PERSONALITY(ex, ibcs2) set_personality((ibcs2)?PER_SVR4:PER_LINUX)
 #endif
 
+static inline void arch_randomize_brk(void)
+{
+}
+
 #endif
diff --git a/include/asm-cris/elf.h b/include/asm-cris/elf.h
index 96a40c1..10607c7 100644
--- a/include/asm-cris/elf.h
+++ b/include/asm-cris/elf.h
@@ -93,4 +93,8 @@ typedef unsigned long elf_fpregset_t;
 
 #endif /* __KERNEL__ */
 
+static inline void arch_randomize_brk(void)
+{
+}
+
 #endif
diff --git a/include/asm-frv/elf.h b/include/asm-frv/elf.h
index 7df58a3..07df9dd 100644
--- a/include/asm-frv/elf.h

New x886-Setup code breaks HVM-XEN boot

[Christian Ehrhardt]

Hi,

I am trying to boot a current 2.6 kernel as a guest under XEN in HVM mode.
With linux-2.6.22.(5) as the guest this works fine but current git kernels
fail very early in the boot process.

The XEN host is a debian kernel with XEN enabled (2.6.18-4-xen-686).
The XEN guest is a vanilla kernel from kernel org booting with LILO
22.6.1 in HVM mode.

I bisected the problem and the bisection points at this commit:
| # bad: [4fd06960f120e02e9abc802a09f9511c400042a5] Use the new x86 setup code 
for i386
| git-bisect bad 4fd06960f120e02e9abc802a09f9511c400042a5

The boot of a current git snapshot fails as follows:
bash$ sudo xm console guest
LILO 22.6.1 boot: lkcur
Loading lkcur.
BIOS data check bypassed
bash$

Note the the xm console command terminates on its own, i.e. the guest
machine seems to halt and not hang somewhere.

I could verify that the real mode code up to the assembly code in
pmjump.S is in fact executed. The problem appears to occur while
enabling protected mode. I tried to put endless loops into the 32-bit
setup code but these were apparently not reached. As far as I understand
this, the protected mode jump in pmjump.S seems to jump into nowhere.

I am willing to do tests with the XEN guest and send any additional
information that might be helpful. However, I cannot change the XEN host
at this time.

Any suggestions? 

 regards  Christian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 4096 byte limit to /proc/PID/environ ?

[James Pearson]

H. Peter Anvin wrote:

Guy Streeter wrote:


On 6/1/06, James Pearson <[EMAIL PROTECTED]> wrote:


H. Peter Anvin wrote:


I think this is the wrong approach.

Many of these should probably be converted to seq_file, but in the
particular case of environ, the right approach is to observe the fact
that reading environ is just like reading /proc/PID/mem, except:

a. the access restrictions are less strict, and
b. there is a range restriction, which needs to be enforced, and
c. there is an offset.

Pretty much, take the guts from /proc/PID/mem and generalize it
slightly, and you have the code that can run either /proc/PID/mem or
/proc/PID/environ.


The following patch is based on the /proc/PID/mem code appears to work fine.



This thread has gone stale. The PAGE_SIZE limit still exists. Is this
solution acceptable?




Can we avoid the code duplication?


There isn't that much that is duplicated - and there are also bits of 
the /proc/PID/mem code that are not needed in this case, so I'm not 
really sure if it is worth doing.


I did submit a patch a few months ago - see:



James Pearson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NFS4 authentification / fsuid

[Trond Myklebust]

On Thu, 2007-08-30 at 16:12 +0200, Jan Engelhardt wrote:
> Hi,
> 
> 
> with NFS3, there is this 'root hole', i.e. any person who has a root 
> account (perhaps by use of a laptop) can mount an export (let's say this 
> export had the "root_squash" option), and still have a look at the user 
> files, because he can locally setuid() into another user.
> 
> So I was looking for alternatives. CIFS is my favorite candidate, but it 
> has a few issues right now. So does sshfs and about everything I have 
> come across. Since I remember NFS4 can use KRB5 authentification, my 
> question is, will the NFS(4) server process run with an fsuid equal to 
> the user that authenticated?
> 
> 
> thanks,
>   Jan

NFSv3 should work fine with krb5 too, but that won't solve your problem
with setuid: kerberos saves the TGT in a file on /tmp, so root can still
suid and grab your cred (and the same goes for CIFS).

We've got people working on fixing this problem using David Howells'
keyrings, but it will probably be a while until we've solved all the
upcall issues, and it will probably take even longer to push the
kerberos changes back to the official MIT etc distros.

Cheers
  Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] i386 and x86_64: randomize brk()

[Mike Frysinger]

On 8/30/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
> On Thu, 30 Aug 2007, Mike Frysinger wrote:
> > does it really make sense to stick stubs into no-mmu ports which cannot
> > utilize the ELF binfmt ?
>
> Good point, thanks. I have removed the stubs for h8300 and m68knommu.

Blackfin too please :)

i think v850 also falls into this category, but i'm not terribly
familiar with it ...
-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: [PATCH] Override 80-wire cable detection for Toshiba S1800-814

[Robert Hancock]

Al Boldi wrote:

Alan Cox wrote:

Wow!  I have been running 80wire cable detection override on 40wire
cables for quite some time without any problem, but I never thought it
to be legal if the 40wire cable length is short enough.

Yes.


How short does it have to be, and can't we have a kernel bootparm to
override the cable detection?

For most users the goal should be to automate behaviour. It should just
work.


What's the max length of a 40wire cable to sustain 80wire cable 
characteristics?


This is normally only the case on a laptop, where the cable is 
essentially just a tiny stub between the motherboard and the drive. I 
suspect this is something that the system manufacturer has to validate 
works properly, more than any hard and fast limit.


For a normal desktop PC, it would be far better to just use an 80-wire 
cable.


--
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: Designers and Builders (was: Who wants to maintain KR list for stable releases?)

[Valdis . Kletnieks]

On Thu, 30 Aug 2007 07:31:24 +0300, Al Boldi said:
> Adrian Bunk wrote
> > Tracking feature or implementation suggestions wouldn't make sense.
> > Consider e.g. that there are several people on linux-kernel who often
> > write what they think the kernel should do but who never write a single
> > line of code themselves. There's no value in tracking such stuff.
> 
> There are designers, and there are builders.
> 
> Can you tell me who is more important?

The problem is not builders, or designers - this list has plenty of both.

What Adrian is talking about are the people who go to designers and say
"Build me something blue, with a design that doesn't work with the VFS".


pgp4zkiFv5O4l.pgp
Description: PGP signature

Re: NFS4 authentification / fsuid

[Trond Myklebust]

On Thu, 2007-08-30 at 10:29 -0400, Trond Myklebust wrote:
> We've got people working on fixing this problem using David Howells'
> keyrings, but it will probably be a while until we've solved all the
> upcall issues, and it will probably take even longer to push the
> kerberos changes back to the official MIT etc distros.

BTW: even when this task is done, a creative root can still find ways to
subvert the security (he can read /dev/mem, replace the kernel with a
compromised one, ). The bottom line is that if you can't trust root,
don't even log in.

Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NFS4 authentification / fsuid

[Jan Engelhardt]

On Aug 30 2007 10:29, Trond Myklebust wrote:
>On Thu, 2007-08-30 at 16:12 +0200, Jan Engelhardt wrote:
>> 
>> with NFS3, there is this 'root hole', i.e. any person who has a root 
>> account (perhaps by use of a laptop) can mount an export (let's say this 
>> export had the "root_squash" option), and still have a look at the user 
>> files, because he can locally setuid() into another user.
>> 
>> So I was looking for alternatives. CIFS is my favorite candidate, but it 
>> has a few issues right now. So does sshfs and about everything I have 
>> come across. Since I remember NFS4 can use KRB5 authentification, my 
>> question is, will the NFS(4) server process run with an fsuid equal to 
>> the user that authenticated?
>
>NFSv3 should work fine with krb5 too, but that won't solve your problem
>with setuid: kerberos saves the TGT in a file on /tmp, so root can still
>suid and grab your cred (and the same goes for CIFS).

Hm? I do not see this problem with CIFS. The user may have local
root, but on the server, he only has his non-root account on the
server, and as such, can only operate on the server using this
non-root fsuid. Did I miss something? (Especially the /dev/mem thing
is not quite clear to me.)

>BTW: even when this task is done, a creative root can still find ways to
>subvert the security (he can read /dev/mem, replace the kernel with a
>compromised one, ). The bottom line is that if you can't trust root,
>don't even log in.


Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ALSA: cs5535audio: correctly set dma->substream

[Jordan Crouse]

On 29/08/07 23:28 -0400, Andres Salomon wrote:
> 
> We're never actually setting dma->substream to the current substream; that
> means the dma->substream checks that we do in the suspend/resume path
> are never satisfied, and the PRD registers are never correctly managed.  This
> changes it so that we set the substream when constructing the specific
> bus master DMA, and unsetting it when we tear down the BM's DMA.
> 
> Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>
Acked-by: Jordan Crouse <[EMAIL PROTECTED]>

> ---
> 
>  sound/pci/cs5535audio/cs5535audio_pcm.c |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/sound/pci/cs5535audio/cs5535audio_pcm.c 
> b/sound/pci/cs5535audio/cs5535audio_pcm.c
> index 5450a9e..e61f972 100644
> --- a/sound/pci/cs5535audio/cs5535audio_pcm.c
> +++ b/sound/pci/cs5535audio/cs5535audio_pcm.c
> @@ -164,6 +164,7 @@ static int cs5535audio_build_dma_packets(struct 
> cs5535audio *cs5535au,
>   jmpprd_addr = cpu_to_le32(lastdesc->addr +
> (sizeof(struct 
> cs5535audio_dma_desc)*periods));
>  
> + dma->substream = substream;
>   dma->period_bytes = period_bytes;
>   dma->periods = periods;
>   spin_lock_irq(&cs5535au->reg_lock);
> @@ -241,6 +242,7 @@ static void cs5535audio_clear_dma_packets(struct 
> cs5535audio *cs5535au,
>  {
>   snd_dma_free_pages(&dma->desc_buf);
>   dma->desc_buf.area = NULL;
> + dma->substream = NULL;
>  }
>  
>  static int snd_cs5535audio_hw_params(struct snd_pcm_substream *substream,
> 
> 

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/