Re:

Re:

[Michael Rothwell]

Robert Kaiser wrote:
> 
> On Thu Jan 18 16:30:30 2001 steve@navaho.co.uk wrote
> > Has anyone had any luck getting a 2.4 kernel to run on Cobalt x86
> > hardware?  It doesn't even seem to start (I get nothing on the screen from
> >t he kernel, it just sits there and does nothing). :(
> 
> What processor does it use ? (386 or 486 perchance?)

AMD K6. New ones will use Athlon.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re:

[Gunnar Ahlberg]

I'm sorry for the empty message. As you can see it was 
delivered to the wrong address. 
Please disregard this posting.
Again, my apologies.

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

Re:

[Jaquemet Loic]

Vibol Hou a écrit :

> Hi,
>
> I'm using 2.4.4-pre3 and get this message occasionally when the system is
> loaded:
>
> Apr 17 16:10:12 omega kernel: eth0: Too much work in interrupt, status e401.
> Apr 17 16:10:12 omega kernel: eth0: Too much work in interrupt, status e401.
>
> The nic is a 3Com 3c905B. Is this a bad thing?
>
> /proc/interrupts:
>            CPU0       CPU1
>   0:   13167527   12036422    IO-APIC-edge  timer
>   1:          0          2    IO-APIC-edge  keyboard
>   2:          0          0          XT-PIC  cascade
>   4:      22773      19820    IO-APIC-edge
>   8:          1          0    IO-APIC-edge  rtc
>  15:          1          4    IO-APIC-edge  ide1
>  17:   50001929   49606064   IO-APIC-level  eth0
>  18:    2459038    2364252   IO-APIC-level  aic7xxx
> NMI:          0          0
> LOC:   25202946   25202942
> ERR:          0
>
> --
> Vibol Hou
> KhmerConnection
> http://khmer.cc
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

I've got a similar problem with a  RTL-8139 (rev 10) ( 8139too.c )
Apr 17 22:53:12 skippy kernel: eth1: Too much work at interrupt,
IntrStatus=0x0040.

The maintenair of this module writes that's a RxFIIFO Overflow that have
probably no other issue than buying a new processor :)
But .. I didn't have this messages on pre - 2.4.3 kernels .. ( neither on
2.4.3ac7 )

Re:

[Jeff Garzik]

Jaquemet Loic wrote:
> I've got a similar problem with a  RTL-8139 (rev 10) ( 8139too.c )
> Apr 17 22:53:12 skippy kernel: eth1: Too much work at interrupt,
> IntrStatus=0x0040.
> 
> The maintenair of this module writes that's a RxFIIFO Overflow that have
> probably no other issue than buying a new processor :)
> But .. I didn't have this messages on pre - 2.4.3 kernels .. ( neither on
> 2.4.3ac7 )

That's a different issue than the poster is having, it's two totally
different network cards with different characteristics.  I don't
remember telling you that status code is a RxFIFO overflow, though :)

The RxFIFO overflow code definitely needs changing -- that's the next
item on the list.

-- 
Jeff Garzik       | "Give a man a fish, and he eats for a day. Teach a
Building 1024     |  man to fish, and a US Navy submarine will make sure
MandrakeSoft      |  he's never hungry again." -- Chris Neufeld

Re:

[Francois Cami]

Vibol Hou wrote:
> 
> Hi,
> 
> I'm using 2.4.4-pre3 and get this message occasionally when the system is
> loaded:
> 
> Apr 17 16:10:12 omega kernel: eth0: Too much work in interrupt, status e401.
> Apr 17 16:10:12 omega kernel: eth0: Too much work in interrupt, status e401.

I got that one too, PC is ASUS P2B-DS with two PII-350, 384MB RAM,
3C905B.
I've tried 3C905C to no avail.
The e401 status seems to be that there is too much load on the card to
be treated in the 20 (2.2.17) or 32 (2.2.19, 2.4.x) loops of the
interruption
check routine (stop/hit me if i'm wrong please). 
I think we should try (MM. Donald Becker or Andrew Norton, 
is this a Bad Thing ?) to change max_interrupt_work (3c59x.c, row 171)
to 64
or maybe even higher. Haven't had the guts to try on the production
machine
right now =)

> The nic is a 3Com 3c905B. Is this a bad thing?

I heard they work fine... 

François Cami
There And Back Again

Re:

[Andrew Morton]

Francois Cami wrote:
> 
> Vibol Hou wrote:
> ...
>
> > Apr 17 16:10:12 omega kernel: eth0: Too much work in interrupt, status e401.
> 
> I got that one too, PC is ASUS P2B-DS with two PII-350, 384MB RAM,
> 3C905B.

If you were getting this message occasionally, and if increasing the
max_interrupt_work module parm makes it stop, and everything
is always working fine, then it's an OK thing to do.

Question is: why is it happening?  We're failing to get out
of the interrupt loop after 32 loops.  Each loop can reap
up to 16 transmitted packets and 32 received packets.
That's a lot.

My suspicion is that something else in the system is
causing the NIC interrupt routine to get held up for long
periods of time.  It has to be another interrupt.

All reporters of this problem (ie: both of them) were using
aic7xx SCSI.  I wonder if that driver can sometimes spend a
long time in its interrupt routine.  Many times.  Rapidly.

Very odd.

Ah.  SMP.  Perhaps the other CPU is generating the transmit
load, some other interrupt source is slowing down *this*
CPU.

Could you test something for me?  Try *decreasing* the
value of max_interrupt_work.  See if that increases
the frequency of the message.  Then, it if does, try to
correlate the occurence of the message with some other
form of system activity (especially disk I/O).

Thanks.


-

Re:

[george anzinger]

"Richard B. Johnson" wrote:
> 
> To driver wizards:
> 
> I have a driver which needs to wait for some hardware.
> Basically, it needs to have some code added to the run-queue
> so it can get some CPU time even though it's not being called.
> 
> It needs to get some CPU time which can be "turned on" or
> "turned off" as a result of an interrupt or some external
> input from  an ioctl().
> 
> So I thought that the "tasklet" would be ideal. However, the
> scheduler "thinks" that a tasklet is an interrupt, so any
> attempt to sleep in the tasklet results in a kernel panic,
> "ieee scheduling in an interrupt..., BUG sched.c line 688".
> 
> Next, I added code to try queue_task(). This has the same problem.
> 
> Basically the procedure needs to do:
> 
> procedure()
> {
>     if(some_event)
>         schedule_timeout(n);               /* Needs to sleep */
>     else if(something_else)
>         do_something();
>    queue_task(procedure, &tq_immediate);   /* Needs to queue itself again */
> }
> 
> Since I'm running against a time-line, I temporarily  gave the module
> some CPU time through an ioctl(), i.e., a separate task that does nothing
> except repeatably execute ioctl(GIVE_CPU, NULL); This shows that the
> driver actually works. It's a GPIB driver so it needs to get the
> CPU to find out if it's addressed to listen, etc. These events don't
> produce interrupts.
> 
> So, what am I supposed to do to add a piece of driver code to the
> run queue so it gets scheduled occasionally?
> 
> Cheers,
> Dick Johnson

How about something like:

#include <linux/timer.h>

void queue_task(void process_timeout(void), unsigned long timeout,
struct timer_list *timer, unsigned long data)
{
	unsigned long expire = timeout + jiffies;

	init_timer(&timer);
	timer->expires = expire;
	timer->data = data;
	timer->function = process_timeout;

	add_timer(&timer);
}


You will have to define the "struct timer_list timer".  This should
cause the function passed to be called after "timeout" jiffies (1/HZ,
not to be confused with 10 ms).  If you want to stop the timer early do:

	del_timer_sync(&timer);

"data" was not used in you example, but process_timeout will be passed
"data" when it is called.  This routine is called as part of the timer
interrupt, so it must be fast and should not do schedule() calls.  It
could queue a tasklet, however, to relax constraints a bit.

George

Re:

[Andrew Morton]

"Richard B. Johnson" wrote:
> 
> To driver wizards:
> 
> I have a driver which needs to wait for some hardware.
> Basically, it needs to have some code added to the run-queue
> so it can get some CPU time even though it's not being called.
> 
> It needs to get some CPU time which can be "turned on" or
> "turned off" as a result of an interrupt or some external
> input from  an ioctl().

schedule_task()?

Re:

[Richard B. Johnson]

On Tue, 8 May 2001, george anzinger wrote:

> "Richard B. Johnson" wrote:
> > 
> > To driver wizards:
> > 
> > I have a driver which needs to wait for some hardware.
> > Basically, it needs to have some code added to the run-queue
> > so it can get some CPU time even though it's not being called.
> > 
[SNIPPED...]

> How about something like:
> 
> #include <linux/timer.h>
> 
> void queue_task(void process_timeout(void), unsigned long timeout,
> struct timer_list *timer, unsigned long data)
> {
> 	unsigned long expire = timeout + jiffies;
> 
> 	init_timer(&timer);
> 	timer->expires = expire;
> 	timer->data = data;
> 	timer->function = process_timeout;
> 
> 	add_timer(&timer);
> }
> 
> 
> You will have to define the "struct timer_list timer".  This should
> cause the function passed to be called after "timeout" jiffies (1/HZ,
> not to be confused with 10 ms).  If you want to stop the timer early do:
> 
> 	del_timer_sync(&timer);
> 
> "data" was not used in you example, but process_timeout will be passed
> "data" when it is called.  This routine is called as part of the timer
> interrupt, so it must be fast and should not do schedule() calls.  It
> could queue a tasklet, however, to relax constraints a bit.
> 
> George

This is all very nice. This is basically what the 'tasklet' does.
The problem is that I have in my code something like this:


/*-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
/*
 *  This waits for an event-flag to be TRUE. It takes a pointer to
 *  that flag, plus the number of timer-ticks to wait. If it times-
 *  out, it returns -ETIME. Otherwise it returns 0.
 */
static int waitfor(volatile int *event, int mask, int ticks)
{
    unsigned long timer;
    int stat;
    DEB(printk("%s waitfor\n", info->dev));
    stat = -ETIME;
    timer = jiffies + (unsigned long) ticks;
    while(!!time_before(jiffies, timer))
    {
        if(!!(*event & mask))
        {
            stat = 0;
            break;
        }
        schedule();
    }
    return stat; 
}
/*-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
/*
 *  This waits for a bit in a port to be TRUE. It takes the OFFSET of
 *  that port, plus the number of timer-ticks to wait. If it times-
 *  out, it returns -ETIME. Otherwise it returns 0.
 */
static int waitport(int offset, int mask, int ticks)
{
    unsigned long timer;
    int stat;
    DEB(printk("%s waitport\n", info->dev));
    stat = -ETIME;
    timer = jiffies + (unsigned long) ticks;
    while(!!time_before(jiffies, timer))
    {
        if(!!(READ_TNT(offset) & mask))
        {
            stat = 0;
            break;
        }
        schedule();
    }
    return stat; 
}


Both of these procedures schedule() while waiting for something to
happen. The wait can be very long (1 second) so I don't want to
just spin eating CPU cycles. I have to give the CPU to somebody.





Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

Re:

[Alan Cox]

>     while(!!time_before(jiffies, timer))
>     {
>         if(!!(*event & mask))
>         {
>             stat = 0;
>             break;
>         }
>         schedule();

You want to yield as well otherwise you may just spin anyway

> Both of these procedures schedule() while waiting for something to
> happen. The wait can be very long (1 second) so I don't want to
> just spin eating CPU cycles. I have to give the CPU to somebody.

So use a timer


void tick_tick_boom(unsigned long l)
{
	struct my_device *d = (struct my_device *)l;

	if(its_still_busy(d))
	{
		d->timer_count--;
		if(d->timer_count)
		{
			/* Try again until timer_count hits zero */
			add_timer(&t->timer, jiffies+1);
			return;
		}
		else
		{
			/* Lose some .. */
			d->event_status = TIMEOUT;
		}
	}
	else
	{
		/* Win some .. */
		d->event_status = OK;
	}
	/* Wake up the invoker */
	wake_up(&d->timer_wait);
}

Re:

[george anzinger]

Alan Cox wrote:
> 
> >     while(!!time_before(jiffies, timer))
> >     {
> >         if(!!(*event & mask))
> >         {
> >             stat = 0;
> >             break;
> >         }
> >         schedule();
> 
> You want to yield as well otherwise you may just spin anyway
> 
> > Both of these procedures schedule() while waiting for something to
> > happen. The wait can be very long (1 second) so I don't want to
> > just spin eating CPU cycles. I have to give the CPU to somebody.
> 
> So use a timer
> 
> void tick_tick_boom(unsigned long l)
> {
>         struct my_device *d = (struct my_device *)l;
> 
>         if(its_still_busy(d))
>         {
>                 d->timer_count--;
>                 if(d->timer_count)
>                 {
>                         /* Try again until timer_count hits zero */
>                         add_timer(&t->timer, jiffies+1);
>                         return;
>                 }
>                 else
>                 {
>                         /* Lose some .. */
>                         d->event_status = TIMEOUT;
>                 }
>         }
>         else
>         {
>                 /* Win some .. */
>                 d->event_status = OK;
>         }
>         /* Wake up the invoker */
>         wake_up(&d->timer_wait);
> }

To clarify this a bit, the above code invokes itself with the timer and
thus runs under the timer interrupt.  The first call to it would be made
from your driver which would then sleep waiting for the wake_up, which
will come either on success or when the timer_count has expired.  This
code will poll each jiffie.

The key here is to use the wake_up/ sleep combination to pass control
from the interrupt back to the driver.  This is not unlike what you must
already be doing for interrupt completion.

Do pay attention to getting the timer (&t->timer above) properly set up
(see my first response or most any usage in the kernel).

Have I got this right Alan?

George

Re:

[Alan Cox]

> from the interrupt back to the driver.  This is not unlike what you must
> already be doing for interrupt completion.
> 
> Do pay attention to getting the timer (&t->timer above) properly set up
> (see my first response or most any usage in the kernel).
> 
> Have I got this right Alan?

The other thing to watch is that you need to delete the timer before you unload
As you can safely del_timer() an initialised but already deleted timer that
isnt too onerous.

Waiting for a thread in the module unload is trickier. You cannot simply kill
the thread as it may run after cleanup_module() returns. Instead you do

static void cleanup_module(void)
{
	kill_thread();
	down(&thread_sem);
	printk("Thread dead\n");
}

and in the thread exit path do

	up_and_exit(&thread_sem, error_code);

This ensures that the thread of execution has left the module code space and
will not return.

Alan

Re:

[Rajiv Majumdar]

send a mail to majordomo@vger.kernel.org with 'help' in the body of the
mail

cheers
rajiv

RE:

[Anil Kumar]

you can use "sys_mprotect" call which is kernel space equ. of "mprotect" .
The implementation for the same can be found in "mm\mprotect.c".

anil

-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of
kiran.thirumalai@in.ibm.com
Sent: Monday, June 11, 2001 10:29 AM
To: linux-kernel@vger.kernel.org
Subject:


Hi,
Is there some kernel api to validate memory allocated using kmalloc.
Suppose, I allocate some memory using kmalloc and at a later point of
execution
I would like to validate if the memory allocated is not possibly freed by
some other thread.

Pls suggest a patch/pointers if any.
I also noticed a commented 'CONFIG_DEBUG_MALLOC' config option  (2.4.3
source),
It doesn't seem to be functional.  Any pointers towards the history behind
it would also be helpful.

Thanks in advance,
Kiran




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

Re:

[Matthew M]

>I tried to compile linux 2.4.5 with gcc-3.0. It gave
>the following error
>kernel/sched.c : 'xtime' definition clash
>In file include/linux/timer.h: line no. 540

This did appear in 2.4.5, but is no longer an issue in 2.4.7.

-- 
*matt* 

Don't Worry, Be Happy.
		-- Meher Baba

Re:

[Parag Warudkar]

Additionally include/linux/modules/ksyms.ver 
requires following  two lines to be added for modules to work

#define __ver_no_llseek 8d4d42a6 
#define no_llseek       _set_ver(no_llseek)

Parag

On Mon, 13 Aug 2001 08:51:03 -0700 (PDT), Colonel wrote:

>  From: Colonel <klink@clouddancer.com>
>  To: paragw@excite.com
>  In-reply-to: <6558420.997690787827.JavaMail.imail@mayall.excite.com>
(message
>  	from Parag Warudkar on Mon, 13 Aug 2001 01:19:46 -0700 (PDT))
>  Subject: Re: Unresolved symbol: no_llseek
>  Reply-to: klink@clouddancer.com
>  References:  <6558420.997690787827.JavaMail.imail@mayall.excite.com>
>  
>     Date: Mon, 13 Aug 2001 01:19:46 -0700 (PDT)
>     From: Parag Warudkar <paragw@excite.com>
>     Reply-To: paragw@excite.com
>     Content-Type: text/plain; charset=us-ascii
>     X-Sender-Ip: 164.164.130.13
>  
>     Hi,
>  	 May be now you can answer my query :)?
>  
>     TIA,
>  
>     Parag
>  
>  
>  There was a msg posted from me replying to Linus about 15 minutes
>  prior to your query.  There are two missing symbols in kernel/ksyms
>  that need exporting.
>  
>  diff ksyms.c ksyms.c.~1~ 
>  245,246d244
>  < EXPORT_SYMBOL(generic_file_llseek);
>  < EXPORT_SYMBOL(no_llseek);
>  
>  
>  
>  
>  
>     In clouddancer.list.kernel, you wrote:
>  
>     >
>     >
>     >This is a multi-part message in MIME format.
>     >
>     >--------------InterScan_NT_MIME_Boundary
>     >Content-Type: text/plain; charset=us-ascii; format=flowed
>     >Content-Transfer-Encoding: 7bit
>     >
>     >
>     >In i810_audio: Unresolved symbol: no_llseek
>     >
>     >In agpgart : Unresolved symbol: no_llseek
>     >
>     >
>  
>  
>     I think I could tell you the answer, but it might violation this
disclaimer.
>  
>  
>  
>  
>     Parag Warudkar
>     Senior Systems Engineer
>     Wipro Technologies,
>     E-Commerce Division,
>     Lavelle Road,
>     Bangalore - 560001.
>     Ph: 2215010 Ext: 124.
>  
>  
>  
>  
>  
>     _______________________________________________________
>     http://inbox.excite.com
>  
>  


Parag Warudkar
Senior Systems Engineer
Wipro Technologies,
E-Commerce Division,
Lavelle Road,
Bangalore - 560001.
Ph: 2215010 Ext: 124.





_______________________________________________________
Send a cool gift with your E-Card
http://www.bluemountain.com/giftcenter/

Re:

[Keith Owens]

On Mon, 13 Aug 2001 20:08:01 -0700 (PDT), 
Parag Warudkar <paragw@excite.com> wrote:
>Additionally include/linux/modules/ksyms.ver 
>requires following  two lines to be added for modules to work
>
>#define __ver_no_llseek 8d4d42a6 
>#define no_llseek       _set_ver(no_llseek)

Don't do that.  If you have module symbol versions turned on
(CONFIG_MODVERSIONS) then after any change that affects exported
symbols, you must make mrproper and rebuild from scratch.  See
http://www.tux.org/lkml/#s8-8.

Re:

[Saravana]

> hi!
>    I am beginning learn to write a driver follow the
> Book "Beginnng Linux programming(Second
> Edition)".There is a example about char driver,I write
> as that,but I can open device,but can't read from it.I
> just copy some static data to user buffer as follow:
>    copy_to_user(buf, schar_buffer, count)

just check out if u got any perms(rw) on the device.. ?
sarvana

Re:

[Tommy Reynolds]

"Dinesh  Gandhewar" <dinesh_gandhewar@rediffmail.com> was pleased to say:

> I have written a linux kernel module. The linux version is 2.2.14. 
> In this module I have declared an array of size 2048. If I use this array, the
> execution of this module function causes kernel to reboot. If I kmalloc() this
> array then execution of this module function doesnot cause any problem.
> Can you explain this behaviour?

Unlike userland application programming, the kernel stack does not grow: it has
a fixed size.  You are using too much stack space and corrupting your system.
The kernel stack is quite small (less than 8K is available for ALL nested
modules and interrupt handlers), so driver functions should use an absolute
minimum of local variables, such as a pointer to a per-instance data area. 
Kernel-leval kmalloc() is efficient enough to use frequently.

---------------------------------------------+-----------------------------
Tommy Reynolds                               | mailto:	<reynolds@redhat.com>
Red Hat, Inc., Embedded Development Services | Phone:  +1.256.704.9286
307 Wynn Drive NW, Huntsville, AL 35805 USA  | FAX:    +1.236.837.3839
Senior Software Developer                    | Mobile: +1.919.641.2923

Re:

[Alex Bligh - linux-kernel]

--On Tuesday, October 02, 2001 3:29 PM +0000 Dinesh  Gandhewar 
<dinesh_gandhewar@rediffmail.com> wrote:

> In this module I have declared an array of size 2048. If I use this
> array, the execution of this module function causes kernel to reboot. If
> I kmalloc() this array then execution of this module function doesnot
> cause any problem.

If you are allocating it on the stack (i.e. as a local variable)
you are probably running out of kernel stack space (depending
what it's an array of).

If you are declaring it non-local, it's possible you are
overwriting the end of it, and, kmalloc() being what it
is, there happens to be some wasted space next to it.

--
Alex Bligh

Re:

[VDA]

Hello Dinesh,

Tuesday, October 02, 2001, 5:30:02 PM, you wrote:


DG> Hello,
DG> I have written a linux kernel module. The linux version is 2.2.14. 
DG> In this module I have declared an array of size 2048. If I use this array, the execution of this module function causes kernel to reboot. If I kmalloc() this array then execution of this module
DG> function doesnot cause any problem.
DG> Can you explain this behaviour?
DG> Thnaks,
DG> Dinesh 
 

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


stack overflow

-- 
Best regards, VDA
mailto:VDA@port.imtp.ilyichevsk.odessa.ua

Re:

[David Ford]

That should throw a segmentation fault, in the kernel an OOPS,  in this 
statement the code is trying to dereference a NULL pointer and store a 
value at 0x0.

David

Dinesh Gandhewar wrote:

>Hello,
>What is the effect of following statement at the end of function definition?
>*(int *)0 = 0;	
>Thanking you,
>Dinesh 
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>

Re:

[Timur Tabi]

David Ford wrote:

> That should throw a segmentation fault, in the kernel an OOPS,  in this 
> statement the code is trying to dereference a NULL pointer and store a 
> value at 0x0.


I much smarter way to do this would be to use this code:

static inline void int3(void) { __asm__ __volatile__ (".byte 0xCC\n"); };

Granted, it's x86-specific, but it works better, since gdb will halt the code 
right at that spot rather than inside some trap hander.  And it's just more 
elegant.

Re:

[Dipak]

Romain Giry wrote:

Hi,


> Hi
>
> i would like to know how the network layer does to know what is the upper
> layer protocol in order to fill in correctly the protocol field in the
> header it adds to the packet before sending it.

see, their might be either API provided by DLL (ethernet, ATM, FR etc) to
network layer (IP, IPX etc) to sent packets over a physical device. Now, the
Network protocol field can be passed through the API to be filled in by
DLL header by DLL. Another case may be, DLL can easily know what's the ifIndex
the packet is coming from. Network layer might have registration policy by
ifIndex to DLL, which can be used now to infer Network layer protocol id.

> I'm doing a ethernet device
> that doesn't add any header to the packet but change the output device,
> then i should say the network device that the packet is like if it has been
> sent by the ip protocol.

I didn't understand what did you mean by "ethernet device doesn't add any
header but change the output device"? May be after you explain a bit more I
can suggest something more.

Thanks,
Dipak

>
>
> Thanks,
>
> Romain Giry
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re:

[Romain Giry]

Hi,

> > I'm doing a ethernet device
> > that doesn't add any header to the packet but change the output device,
> > then i should say the network device that the packet is like if it has been
> > sent by the ip protocol.
>
>I didn't understand what did you mean by "ethernet device doesn't add any
>header but change the output device"? May be after you explain a bit more I
>can suggest something more.


For my thesis, I should do a module for linux that allows the user to 
switch the
physical device at run-time. In a first time this should be done by user 
commands
and later the module should decide himself to switch the physical device.

That's why it seems to me natural to create a dummy ethernet device driver 
which
does nothing else apart from forwarding the packets received from the IP stack
to a real (= physical) network device. Therefore i need to fake that the 
packet was
sent by the IP stack so as the physical device fill in correctly the 
protocol field in
the header it adds.

Otherwise i thought i can do a transparent firewall that decides to which real
interface to switch the packets after beeing sure that the physical device is
running otherwise it should change.

One thing that may be difficult to implement is that i want to keep a TCP
connection running when i change the physical device. That's why maybe the
firewall solution may be better because when receiving packets i could fake
that they all come from the same physical device and have therefore the same
IP.

Thanks

Romain


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re:

[Alan Cox]

> One thing that may be difficult to implement is that i want to keep a TCP
> connection running when i change the physical device. That's why maybe the
> firewall solution may be better because when receiving packets i could fake
> that they all come from the same physical device and have therefore the same
> IP.

You set up multiple physical devices with the same IP and use the "route"
command. Thats worked with TCP/IP protocols since day 1

Re:

[Manfred Spraul]

> When I went to build 2.4.17 on a dinky box (486, 16M RAM), the
> config option was missing.  The box is a wall mount and is not very
> capable of multiple kernel experimentation alas.  Can someone
> supply some background as to what has happened?

It seems that RTNETLINK is now unconditionally enabled, I don't know
why.

--
    Manfred

Re:

[Legacy Fishtank]

On Tue, Dec 25, 2001 at 05:17:01PM +0100, Manfred Spraul wrote:
> > When I went to build 2.4.17 on a dinky box (486, 16M RAM), the
> > config option was missing.  The box is a wall mount and is not very
> > capable of multiple kernel experimentation alas.  Can someone
> > supply some background as to what has happened?
> 
> It seems that RTNETLINK is now unconditionally enabled, I don't know
> why.

It's required by newer RedHat and MDK initscripts, perhaps others.
ip, iproute and similar utilities use it, and so since it's commonly
required DaveM made it unconditional...  I think the checkin comment was
something along the lines of "make it unconditional unless Alan
complains about kernel bloat" :)

	Jeff

Re:

[Kurt Roeckx]

On Tue, Dec 25, 2001 at 02:14:41PM -0500, Legacy Fishtank wrote:
> On Tue, Dec 25, 2001 at 05:17:01PM +0100, Manfred Spraul wrote:
> > It seems that RTNETLINK is now unconditionally enabled, I don't know
> > why.
> 
> It's required by newer RedHat and MDK initscripts, perhaps others.
> ip, iproute and similar utilities use it, and so since it's commonly
> required DaveM made it unconditional...  I think the checkin comment was
> something along the lines of "make it unconditional unless Alan
> complains about kernel bloat" :)

But ifconfig and route don't use it, and now you can't do certain
things you could before.

One thing that comes to mind is showing the ipv6 routig cache,
because it only made that proc entry when it's not enabled.

Should I mention my kernel got bigger?

(I also was under the impression that this was a stable series.)


Kurt

Re:

[Alan Cox]

> It's required by newer RedHat and MDK initscripts, perhaps others.
> ip, iproute and similar utilities use it, and so since it's commonly

Basically because Dave refused to recognize lots of embedded setups don't
need the netlink crap and couldn't just accept defaulting it to Y we all
get lumbered with it

> required DaveM made it unconditional...  I think the checkin comment was
> something along the lines of "make it unconditional unless Alan
> complains about kernel bloat" :)

And I did complain. "Red Hat needs XYZ so we make it mandatory" is not an
appropriate approach to a problem.

Alan

Re:

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: Tue, 25 Dec 2001 22:03:59 +0000 (GMT)
   
   > required DaveM made it unconditional...  I think the checkin comment was
   > something along the lines of "make it unconditional unless Alan
   > complains about kernel bloat" :)
   
   And I did complain. "Red Hat needs XYZ so we make it mandatory" is not an
   appropriate approach to a problem.

[ Just got back from British Columbia... ]

No you did not complain.  I asked you specifically if it was ok, and
your response was that turning netlink/rtnetlink on by default was
fine with you.

It has zilch to do with redhat anything, in fact I had to ask vendors
first if they could still fit the kernel on their boot disks if I
added ~5K of object code to kernels with networking enabled.

It has everything to do with iproute2 and tcp_diag using it.

Franks a lot,
David S. Miller
davem@redhat.com

Re:

[Alan Cox]

> No you did not complain.  I asked you specifically if it was ok, and
> your response was that turning netlink/rtnetlink on by default was
> fine with you.

But not forcing it always on - thats not what I said.

|   From: Alan Cox <alan@redhat.com>
|   Date: Wed, 31 Oct 2001 13:09:16 -0500 (EST)
|
|   Ask Arjan. I'm certainly of the opinion it should edefault to Y in Linus
|   config.in

Alan

RE:

[Torrey Hoffman]

nimeesh wrote:
 
> I'm new to linux.I'm trying network booting of linux
> system.System Conf.(intel 815 chipset ,PXE
> bios,3com905c-ethernet card)
> 
> In that i'm facing problem with kernel image and it's
> file system.
> 
> In that when i get the kernel image and filesystem.
> It gives me error as
> kernel panic : unable to mount root fs on 01:00
> 
> Is it necessary to use NFS or is it possible without
> that? Any special specification while creating kernel
> image and filesystem?

It sounds like you have PXE working well enough to have the 
BIOS download a PXE bootloader from a TFTP server, which 
then downloads a kernel image.  I assume you are using Peter 
Anvin's "pxelinux" boot loader?  
It is part of the "syslinux" package.

Anyway, you have at least two options for the root
file system.  You can use an NFS root, or you can use
an initial ramdisk.    I use an initial ramdisk.  My server 
has the standard ISC DHCP server, and Peter Anvin's TFTP server.

The DHCP server is configured in /etc/dhcpd.conf and
includes:

subnet 10.134.0.0 netmask 255.255.254.0
{
	# Not shown: options for DNS, router, domain name, 
	# default lease time, range, etc.

	# this is the important bit for PXE:
	filename "pxelinux.0"
}

The TFTP server contains the files:

pxelinux.0        (the pxelinux boot loader)
bzImage		(the kernel)
initrd.gz		(the initial ramdisk)
pxelinux.cfg/0A86 (the pxelinux config directory and file)

The Pxelinux.cfg configuration file I use is named "0A86" 
because the DHCP server assigns addresses "10.134.xxx.yyy", 
(10=0x0A, 134=0x86) and looks something like this:

DEFAULT MYNETBOOT
TIMEOUT 0
LABEL MYNETBOOT
  KERNEL bzImage
  APPEND initrd=initrd.gz root=/dev/ram

There is quite a bit of information on the network about how 
to create an initrd image.  Check the "HOWTO" documentation 
files that may have come with your Linux distribution.  
Also try "man initrd".

So here's how the pxe boot works from start to finish:

1. Client boots and enters PXE BIOS.
2. PXE BIOS does DHCP, gets IP address and filename option
3. PXE BIOS uses TFTP to download pxelinux.0 and boot from it
4. pxelinux.0 bootloader determines IP address, asks TFTP
   server for config file, finds "0A86" file and downloads it
5. pxelinux.0 reads config file, uses TFTP to download
   bzImage and initrd.gz
6. pxelinux boots bzImage kernel together with initrd.gz 
   ramdisk, kernel command line "root=/dev/ram" tells 
   kernel to use ramdisk as root filesystem
7. Kernel boots, mounts ramdisk, and then runs /linuxrc if it
   exists, otherwise runs /sbin/init just like booting from
   any other device.
8. linuxrc or init starts up the system or does whatever you
   want them to do.  Read the initrd man page for details.

Best wishes,

Torrey Hoffman

Re:

[Vance Lankhaar]

On Monday 01 April 2002 02:17, mpaa3d@pacbell.net wrote:
[snip]
>April 1, 2003
[snip]

I guess we don't have to read this for a year ;)

Vance Lankhaar 

------------------------------------------------------------
 Vance Lankhaar                        vance@pcsscreston.ca
 PCSS Yearbook                      yearbook@pcsscreston.ca
 PCSS Computers                    sysadmins@pcsscreston.ca
 http://www.crestonbc.com/pcss/   http://www.pcsscreston.ca
------------------------------------------------------------

RE:

[Kuppuswamy, Priyadarshini]

Please ignore my earlier email. I didn't intend to send it to the list.

> -----Original Message-----
> From:	Kuppuswamy, Priyadarshini 
> Sent:	Tuesday, April 09, 2002 9:21 AM
> To:	linux-kernel@vger.kernel.org
> Subject:	
> 
> unsubscribe linux-kernel

Re:

[François Cami]

Satish Mohan wrote:
> subscribe linux-kernel
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 

please send a message to

majordomo@vger.kernel.org

with the line "subscribe linux-kernel" in the body of your
message

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

François Cami

Re:

[Alan Cox]

On Fri, 2002-05-31 at 09:04, Oliver Pitzeier wrote:
> Hi volks/Linus/Alan/Ivan! :o)
> 
> I tried to compile kernel 2.5.19 on an alpha.
> 
> Can someone help me? I had the same problem already with kernel 2.5.18.
> Kernel 2.5.15 works well. Everything above _not_.
> 

There are continual 2.5 changes and at times they are going to break the
Alpha port since x86 is the main item of focus. I don't follow 2.5 much
(I've yet to find a 2.5 kernel that doesn't crash and/or eat my disks)
so I can't really help you.

Alan

Re:

[Daniel Phillips]

On Saturday 08 June 2002 23:35, tushar  korde wrote:
> hi folks,
>  	as kmalloc allocates memory in power of 2 ( starting from 32 )
> instead of the size requested. there are following problems :
> 
>   1) we are allocating at least 32 bytes in all cases ( most of 
> the times it is not
> required ).
> 
>   2) if we allocate large memory, internal fregmentation also 
> increases.
> 
>   3) allocating more memory then the request often leads to 
> programming errors
> esp. when we store some data and read it back or try to get size 
> of data stored
>   ( though it can be handled but we have to take special care of 
> it at every point ).
> 
> the solution to above problems may be that we dont allocate 
> objects from the 13
> general purpose caches, instead we make a new cache keep its 
> address either in
> cache_sizes or declare it global. now as the kmalloc is invoked 
> check the memory size
> requested if predefined sizes are not suitable then make a new 
> object of the size
> requested ( now here the definition of c_offset flag of cache 
> descriptor may be
> violated ) and allot it to our new cache and return it .
> 
>  	i know that there may be subtle problems in it's 
> implementation.
> i need your suggestions. is it worth to make efforts in this 
> field.

You probably want kmem_cache_alloc, see slab.c.  Kmalloc is just an
interface to kmem_cache_alloc.

-- 
Daniel

Re:

[David Lloyd]

I don't suppose you've read this message on the bottom of every message:

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

Spamassassin kills my main computer whilst processing Kernel list
messages. This one just makes you look like a Spammer :-(

DSL
-- 
Qualcuno no mi basta.
  Vivere cercando il grande amore.
  Vivere come se mai dovessimo morire.
(Anastasio, Valli e Travato)

Re:

[Steven Dake]

sridhar vaidyanathan wrote:

>I am trying to debug a kernel over a remote serial console. I get 
>Ignoring packet error ..
>
I have seen this and in my case, it had to do with printks coming over 
the serial link with console redirection.

>kgdb page suggests that it might be due to the speed mismatch. i tried 
>stty ispeed 9600 ospeed 9600 < /dev/ttyS0 
>on the development machine and have passed serial=0,9600n8 option and 
>gdbbaud=9600 via lilo to the debug kernel. 
>
>when i run 
>%stty speed 
>on the development machine it still reports 38400.
>so i changed the gdbbaud and serial= values to 38400 on the test machine. even 
>this doesn't work.
>any ideas?also on the development machine when i invoke 
>%gdb bzImage 
>
try gdb vmlinux.  This is the uncompressed image that gdb knows how to 
read.  bzImage is the compressed kernel that you should boot.  The 
vmlinux file should match the bzImage file.

>gdb reports that bzImage is not an Executable file format and it is unable to 
>recognize the format. what is the problem?
>-sridhar
>ps: i have tried redirecting the kernel messages( without patching it with 
>kgdb) over the serial line and read it with minicom . that works fine.
>
>please email as i am not subscribed.
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>
>
>  
>

Re:

[Roman Zippel]

Hi,

On Thu, 17 Oct 2002, Rusty Russell wrote:

> Roman dislikes linking in the kernel.  So did I until I wrote it: it's
> really trivial (esp. compared with the code to coordinate with the
> userspace linker properly).  And it exists today.  The linking takes
> around 200 lines.  But, let's say his solution is 500 lines shorter
> than mine.

I believe you that linking in the kernel is simpler, but so would be a lot
of other things and the part I really dislike is to remove the ability to
keep it in user space.

bye, Roman

Re:

[Shawn Starr]

Same bug I get with 2.4.20 :-(

On Sunday 12 January 2003 8:28 am, Philip K.F. Hölzenspies wrote:
> I do have the following line in my fstab file (Bayard):
>
> none  /proc/bus/usb  usbfs  defaults 0 0
>
> I believe usbdevfs is deprecated (although - should I use it when my
> hosthub is picked up by the OHCI driver in stead of the EHCI driver?).
>
> My full dmesg is attached below (Pete), I'ld say the relevant section
> is:
>
> usb.c: registered new driver usbdevfs
> usb.c: registered new driver hub
> PCI: Enabling device 02:08.2 (0014 -> 0016)
> PCI: No IRQ known for interrupt pin C of device 02:08.2. Probably buggy
> MP table.
> hcd.c: Found HC with no IRQ.  Check BIOS/PCI 02:08.2 setup!
> uhci.c: USB Universal Host Controller Interface driver v1.1
> PCI: Enabling device 02:08.0 (0014 -> 0016)
> PCI: No IRQ known for interrupt pin A of device 02:08.0. Probably buggy
> MP table.
> usb-ohci.c: found OHCI device with no IRQ assigned. check BIOS settings!
> PCI: Enabling device 02:08.1 (0014 -> 0016)
> PCI: No IRQ known for interrupt pin B of device 02:08.1. Probably buggy
> MP table.
> usb-ohci.c: found OHCI device with no IRQ assigned. check BIOS settings!
> usb.c: registered new driver hiddev
> usb.c: registered new driver hid
> hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
> hid-core.c: USB HID support drivers
> usb.c: registered new driver usblp
> printer.c: v0.11: USB Printer Device Class driver
> Initializing USB Mass Storage driver...
> usb.c: registered new driver usb-storage
> USB Mass Storage support registered.
>
> Does anybody else with the A7M266-D have that "Probably buggy MP table."
>
> For the OHCI 'found device with no IRQ assigned' I don't really get it.
> I have all my PCI slots set to auto assign IRQ and I didn't reserve any
> IRQ for Legacy Devices, so that shouldn't be the problem.
>
> > I have this board, but the problem is the newer A7M266-D boards have
>
> the USB
>
> > 1.x pins removed.
>
> (Shawn)
>
> I don't know what would be considered a "newer" board, but mine is a
> 03/07/2002-ASUS-A7M266-D
>
> B.T.W.
> I use BIOS rev. 1005.
>
> Regards,
>
> Philip
>
> P.S.
> Would configuring the kernel with >1GB mem support remove that
> " Warning only 896MB will be used." from my dmesg?
>
>
>
> Linux version 2.4.20 (root@tomwaits) (gcc version 3.2) #1 SMP Sat Jan 11
> 18:46:51 CET 2003
> BIOS-provided physical RAM map:
>  BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
>  BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
>  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
>  BIOS-e820: 0000000000100000 - 000000003ffec000 (usable)
>  BIOS-e820: 000000003ffec000 - 000000003ffef000 (ACPI data)
>  BIOS-e820: 000000003ffef000 - 000000003ffff000 (reserved)
>  BIOS-e820: 000000003ffff000 - 0000000040000000 (ACPI NVS)
>  BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
>  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
>  BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
> Warning only 896MB will be used.
> Use a HIGHMEM enabled kernel.
> 896MB LOWMEM available.
> found SMP MP-table at 000f6d10
> hm, page 000f6000 reserved twice.
> hm, page 000f7000 reserved twice.
> hm, page 000f6000 reserved twice.
> hm, page 000f7000 reserved twice.
> On node 0 totalpages: 229376
> zone(0): 4096 pages.
> zone(1): 225280 pages.
> zone(2): 0 pages.
> Intel MultiProcessor Specification v1.4
>     Virtual Wire compatibility mode.
> OEM ID: ASUS     Product ID: PROD00000000 APIC at: 0xFEE00000
> Processor #0 Pentium(tm) Pro APIC version 16
> Processor #1 Pentium(tm) Pro APIC version 16
> I/O APIC #2 Version 17 at 0xFEC00000.
> Processors: 2
> Kernel command line: BOOT_IMAGE=lfs ro root=305
> Initializing CPU#0
> Detected 1533.431 MHz processor.
> Console: colour VGA+ 80x25
> Calibrating delay loop... 3060.53 BogoMIPS
> Memory: 904324k/917504k available (1707k kernel code, 12792k reserved,
> 604k data, 124k init, 0k highmem)
> Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
> Inode cache hash table entries: 65536 (order: 7, 524288 bytes)
> Mount-cache hash table entries: 16384 (order: 5, 131072 bytes)
> Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes)
> Page-cache hash table entries: 262144 (order: 8, 1048576 bytes)
> CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
> CPU: L2 Cache: 256K (64 bytes/line)
> Intel machine check architecture supported.
> Intel machine check reporting enabled on CPU#0.
> CPU:     After generic, caps: 0383fbff c1cbfbff 00000000 00000000
> CPU:             Common caps: 0383fbff c1cbfbff 00000000 00000000
> Enabling fast FPU save and restore... done.
> Enabling unmasked SIMD FPU exception support... done.
> Checking 'hlt' instruction... OK.
> POSIX conformance testing by UNIFIX
> mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
> mtrr: detected mtrr type: Intel
> CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
> CPU: L2 Cache: 256K (64 bytes/line)
> Intel machine check reporting enabled on CPU#0.
> CPU:     After generic, caps: 0383fbff c1cbfbff 00000000 00000000
> CPU:             Common caps: 0383fbff c1cbfbff 00000000 00000000
> CPU0: AMD Athlon(TM) MP 1800+ stepping 02
> per-CPU timeslice cutoff: 731.39 usecs.
> enabled ExtINT on CPU#0
> ESR value before enabling vector: 00000000
> ESR value after enabling vector: 00000000
> Booting processor 1/1 eip 2000
> Initializing CPU#1
> masked ExtINT on CPU#1
> ESR value before enabling vector: 00000000
> ESR value after enabling vector: 00000000
> Calibrating delay loop... 3060.53 BogoMIPS
> CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
> CPU: L2 Cache: 256K (64 bytes/line)
> Intel machine check reporting enabled on CPU#1.
> CPU:     After generic, caps: 0383fbff c1cbfbff 00000000 00000000
> CPU:             Common caps: 0383fbff c1cbfbff 00000000 00000000
> CPU1: AMD Athlon(TM) MP 1800+ stepping 02
> Total of 2 processors activated (6121.06 BogoMIPS).
> ENABLING IO-APIC IRQs
> Setting 2 in the phys_id_present_map
> ...changing IO-APIC physical APIC ID to 2 ... ok.
> init IO_APIC IRQs
>  IO-APIC (apicid-pin) 2-0, 2-5, 2-9, 2-10, 2-11, 2-17, 2-20, 2-21, 2-22,
> 2-23 not connected.
> ..TIMER: vector=0x31 pin1=2 pin2=0
> number of MP IRQ sources: 16.
> number of IO-APIC #2 registers: 24.
> testing the IO APIC.......................
>
> IO APIC #2......
> .... register #00: 02000000
> .......    : physical APIC id: 02
> .... register #01: 00170011
> .......     : max redirection entries: 0017
> .......     : PRQ implemented: 0
> .......     : IO APIC version: 0011
> .... register #02: 00000000
> .......     : arbitration: 00
> .... IRQ redirection table:
>  NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
>  00 000 00  1    0    0   0   0    0    0    00
>  01 003 03  0    0    0   0   0    1    1    39
>  02 003 03  0    0    0   0   0    1    1    31
>  03 003 03  0    0    0   0   0    1    1    41
>  04 003 03  0    0    0   0   0    1    1    49
>  05 000 00  1    0    0   0   0    0    0    00
>  06 003 03  0    0    0   0   0    1    1    51
>  07 003 03  0    0    0   0   0    1    1    59
>  08 003 03  0    0    0   0   0    1    1    61
>  09 000 00  1    0    0   0   0    0    0    00
>  0a 000 00  1    0    0   0   0    0    0    00
>  0b 000 00  1    0    0   0   0    0    0    00
>  0c 003 03  0    0    0   0   0    1    1    69
>  0d 003 03  0    0    0   0   0    1    1    71
>  0e 003 03  0    0    0   0   0    1    1    79
>  0f 003 03  0    0    0   0   0    1    1    81
>  10 003 03  1    1    0   1   0    1    1    89
>  11 000 00  1    0    0   0   0    0    0    00
>  12 003 03  1    1    0   1   0    1    1    91
>  13 003 03  1    1    0   1   0    1    1    99
>  14 000 00  1    0    0   0   0    0    0    00
>  15 000 00  1    0    0   0   0    0    0    00
>  16 000 00  1    0    0   0   0    0    0    00
>  17 000 00  1    0    0   0   0    0    0    00
> IRQ to pin mappings:
> IRQ0 -> 0:2
> IRQ1 -> 0:1
> IRQ3 -> 0:3
> IRQ4 -> 0:4
> IRQ6 -> 0:6
> IRQ7 -> 0:7
> IRQ8 -> 0:8
> IRQ12 -> 0:12
> IRQ13 -> 0:13
> IRQ14 -> 0:14
> IRQ15 -> 0:15
> IRQ16 -> 0:16
> IRQ18 -> 0:18
> IRQ19 -> 0:19
> .................................... done.
> Using local APIC timer interrupts.
> calibrating APIC timer ...
> ..... CPU clock speed is 1533.4929 MHz.
> ..... host bus clock speed is 266.6942 MHz.
> cpu: 0, clocks: 2666942, slice: 888980
> CPU0<T0:2666928,T1:1777936,D:12,S:888980,C:2666942>
> cpu: 1, clocks: 2666942, slice: 888980
> CPU1<T0:2666928,T1:888960,D:8,S:888980,C:2666942>
> checking TSC synchronization across CPUs: passed.
> Waiting on wait_init_idle (map = 0x2)
> All processors have done init_idle
> mtrr: your CPUs had inconsistent fixed MTRR settings
> mtrr: probably your BIOS does not setup all CPUs
> PCI: PCI BIOS revision 2.10 entry at 0xf0de0, last bus=2
> PCI: Using configuration type 1
> PCI: Probing PCI hardware
> PCI: Using IRQ router AMD768 [1022/7443] at 00:07.3
> PCI->APIC IRQ transform: (B1,I5,P0) -> 16
> PCI->APIC IRQ transform: (B2,I5,P0) -> 18
> BIOS failed to enable PCI standards compliance, fixing this error.
> Linux NET4.0 for Linux 2.4
> Based upon Swansea University Computer Society NET3.039
> Initializing RT netlink socket
> Starting kswapd
> Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> NTFS driver v1.1.22 [Flags: R/O]
> pty: 256 Unix98 ptys configured
> Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
> SERIAL_PCI enabled
> ttyS00 at 0x03f8 (irq = 4) is a 16550A
> ttyS01 at 0x02f8 (irq = 3) is a 16550A
> amd768_rng: AMD768 system management I/O registers at 0xE400.
> amd768_rng hardware driver 0.1.0 loaded
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with
> idebus=xx
> AMD7441: IDE controller on PCI bus 00 dev 39
> AMD7441: chipset revision 4
> AMD7441: not 100% native mode: will probe irqs later
> AMD7441: disabling single-word DMA support (revision < C4)
>     ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:DMA
>     ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:DMA
> hda: WDC WD800JB-00CRA1, ATA DISK drive
> hdb: WDC WD307AA-00BAA0, ATA DISK drive
> hdc: LITEON DVD-ROM LTD163D, ATAPI CD/DVD-ROM drive
> hdd: AOPEN CD-RW CRW3248 1.10 20020301, ATAPI CD/DVD-ROM drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> blk: queue c03b9124, I/O limit 4095Mb (mask 0xffffffff)
> hda: 156301488 sectors (80026 MB) w/8192KiB Cache, CHS=9729/255/63,
> UDMA(100)
> blk: queue c03b9270, I/O limit 4095Mb (mask 0xffffffff)
> hdb: 60074784 sectors (30758 MB) w/2048KiB Cache, CHS=3739/255/63,
> UDMA(66)
> hdc: ATAPI 48X DVD-ROM drive, 512kB Cache, UDMA(33)
> Uniform CD-ROM driver Revision: 3.12
> hdd: ATAPI 48X CD-ROM CD-R/RW drive, 8192kB Cache, UDMA(33)
> Partition check:
>  hda: hda1 hda2 < hda5 >
>  hdb: hdb1
> Floppy drive(s): fd0 is 1.44M
> FDC 0 is a post-1991 82077
> loop: loaded (max 8 devices)
> 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
> 02:05.0: 3Com PCI 3c982 Dual Port Server Cyclone at 0xc800. Vers
> LK1.1.16
> Linux agpgart interface v0.99 (c) Jeff Hartmann
> agpgart: Maximum main memory to use for agp memory: 816M
> agpgart: Detected AMD 760MP chipset
> agpgart: AGP aperture is 32M @ 0xfc000000
> SCSI subsystem driver Revision: 1.00
> kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
> es1371: version v0.30 time 18:48:06 Jan 11 2003
> usb.c: registered new driver usbdevfs
> usb.c: registered new driver hub
> PCI: Enabling device 02:08.2 (0014 -> 0016)
> PCI: No IRQ known for interrupt pin C of device 02:08.2. Probably buggy
> MP table.
> hcd.c: Found HC with no IRQ.  Check BIOS/PCI 02:08.2 setup!
> uhci.c: USB Universal Host Controller Interface driver v1.1
> PCI: Enabling device 02:08.0 (0014 -> 0016)
> PCI: No IRQ known for interrupt pin A of device 02:08.0. Probably buggy
> MP table.
> usb-ohci.c: found OHCI device with no IRQ assigned. check BIOS settings!
> PCI: Enabling device 02:08.1 (0014 -> 0016)
> PCI: No IRQ known for interrupt pin B of device 02:08.1. Probably buggy
> MP table.
> usb-ohci.c: found OHCI device with no IRQ assigned. check BIOS settings!
> usb.c: registered new driver hiddev
> usb.c: registered new driver hid
> hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
> hid-core.c: USB HID support drivers
> usb.c: registered new driver usblp
> printer.c: v0.11: USB Printer Device Class driver
> Initializing USB Mass Storage driver...
> usb.c: registered new driver usb-storage
> USB Mass Storage support registered.
> mice: PS/2 mouse device common for all mice
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP, IGMP
> IP: routing cache hash table of 8192 buckets, 64Kbytes
> TCP: Hash tables configured (established 262144 bind 65536)
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 124k freed

Re:

[Manfred Spraul]

Jun wrote:

>cpu B:
>        get the ipi and (WITHOUT CHECKING cpu_vm_mask again)
>        go ahead doing tlb flushing.
>
>I am not sure if any disastrous result will happen, but apparently
>an unintended flush has happened.
>
Yes, that's possible. It should be rare (the windows is a few 
instructions long), and on i386 it doesn't hurt.

>In MIPS such a hole could
>cause two processes using the same TLB entries which yields all kinds
>of interesting crashes.
>
What is your problem? Do your mips cpus have mmu contexts (the ability 
to store tlb entries from multiple processes), and you load tlb entries 
with the wrong context id?
The i386 implementation knows that i386 cpus don't support mmu contexts, 
i.e. the whole tlb is flushed during process switches.

--
    Manfred

Re:

[b_adlakha]

Vlad@geekizoid.com writes: 

> Send your subscribe message to majordomo@vger.kernel.org. 
> 
> -- 
> 
>  /"\                         / For information and quotes, email us at
>  \ /  ASCII RIBBON CAMPAIGN / info@lrsehosting.com
>   X   AGAINST HTML MAIL    / http://www.lrsehosting.com/
>  / \  AND POSTINGS        / vlad@lrsehosting.com
> ------------------------------------------------------------------------- 
> 
>> -----Original Message-----
>> From: linux-kernel-owner@vger.kernel.org
>> [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of
>> b_adlakha@softhome.net
>> Sent: Friday, February 21, 2003 3:14 PM
>> To: linux-kernel@vger.kernel.org
>> Subject:  
>> 
>> 
>> subscribe 
>> -
>> To unsubscribe from this list: send the line "unsubscribe 
>> linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
 

srry 

Re:

[Eyal Lebedinsky]

Mauricio Oliveira Carneiro wrote:

> But I can't see it mounted anywhere in my system, nor can I mount it by
> hand since I don't know the device filename (/dev/?) .

The device is the next available scsi, e.g.:
	mount /dev/sda1 /mnt

My /etc/fstab has this:

# USB camera as mass-storage, Nikon Coolpix 2000
#
none               /proc/bus/usb        usbdevfs  noauto          0 0
/dev/sda1          /nikon               msdos     noauto          0 0

--
Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.org/eyal/>

Re:

[Marc-Christian Petersen]

On Wednesday 04 June 2003 01:51, Justin T. Gibbs wrote:

Hi Justin,

> I've just uploaded version 1.3.10 of the aic79xx driver and version
> 6.2.36 of the aic7xxx driver.  Both are available for 2.4.X and
> 2.5.X kernels in either bk send format or as a tarball from here:
many thanks! I'll update them for my tree (as always with your updates 
:-)

ciao, Marc

Re:

[Bruce Harada]

Matt,

What is this guy doing? I count 23 in the last few hours.


On 30 Jun 2003 03:16:53 -0000
usenet@mailgate.netsplit.com wrote:

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

Re:

[Matti Aarnio]

Always do ask   POSTMASTER@vger.kernel.org   about this kind
of things...    It is summer-time, and even your ever watchfull
postmasters are going off-net for extended periods of time..
Contacting the ROLE contact will reach multiple people, hopefully
at least one of us is at hand.

On Mon, Jun 30, 2003 at 05:09:47PM +0900, Bruce Harada wrote:
> Date:	Mon, 30 Jun 2003 17:09:47 +0900
> From:	Bruce Harada <bharada@coral.ocn.ne.jp>
> To:	matti.aarnio@zmailer.org
> Cc:	linux-kernel@vger.kernel.org
> Subject: Re:
> 
> Matt,

I wonder who is that..

> What is this guy doing? I count 23 in the last few hours.

Do find out, and tell us.
I blocked messages coming from there couple hours ago.

You have seen nothing, though.   DaveM had a horror situation,
as one misconfigured Norwegian site keeps pushing error messages
to listowner some 15-30 times a minute.  That has been going on
for about 20 hours now:
  http://vger.kernel.org/z/zmailer-rrd-vger_SNMP_SS_SMTPconnects.html

> On 30 Jun 2003 03:16:53 -0000
> usenet@mailgate.netsplit.com wrote:
> 
> > -

/Matti Aarnio  -- one of  <postmaster@vger.kernel.org>

Re:

[jiho]

You sent to wrong e-mail address, send to majordomo, as shown at bottom.

Sir Ace wrote:

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

Re:

[Ian Hastie]

On Tuesday 12 Aug 2003 14:55, Catalin BOIE wrote:
> Hello!
>
> "cat drivers/built-in.o > /dev/null" gives me i/o error.
>
> Can I suspect a bad sector?
> I use reiserfs.

Can't say.  What i/o error does it give you?  Anything useful in 
/var/log/messages?  Or perhaps /var/log/kern.log?

-- 
Ian.

Re:

[Nick Piggin]

Marcelo Tosatti wrote:

>>Matthias Andree wrote:
>>
>>    
>>
>>>On Mon, 25 Aug 2003, Marcelo Tosatti wrote:
>>>
>>>
>>>      
>>>
>>>>- 2.4.22-rc4 was released as 2.4.22 with no changes.
>>>>
>>>>        
>>>>
>>>What are the plans for 2.4.23? XFS merge perhaps <hint>?
>>>
>>>      
>>>
>>Maybe some of Andrea's VM stuff?
>>    
>>
>
>Definately. Thats the first thing I'm going to do after looking through
>"2.4.23-pre-patches" folder.
>
>  
>

Excellent choice IMO ;)

Re:

[Nick Piggin]

John Yau wrote:

>>Your mechanism is basically "backboost". Its how you get X to keep a
>>high piroirity, but quite unpredictable. Giving a boost to a process
>>holding a semaphore is an interesting idea, but it doesn't address the
>>X problem.
>>
>
>Hmm...I'm actually curious why you called it "backboosting".  In academia
>this approach first described in the paper here:
>
>L. Sha, R. Rajkumar, and J. P. Lehoczky. Priority Inheritance Protocols: An
>Approach to Real-Time Synchronization. In IEEE Transactions on Computers,
>vol. 39, pp. 1175-1185, Sep. 1990.
>
>is referred to as priority inheritance.  Is there significant difference
>between your implementation and priority inheritance schemes implemented in
>other OSes?  If so, why backboosting?
>

Well I haven't read the paper, but I'm guessing this is semaphore
priority inheritance.

>
>I was under the impression that pipes and IPC in general are synchronized
>using some sort of semaphores/mutex...or does Linux use a different
>mechanism for IPC and does away with user space synchronization all together
>(e.g. flip-flop buffers with the kernel arbitrating all contention)?  IIRC
>processes don't write to X directly and has to send data to X via IPC.  If
>some futex derivative is used to synchronize the producers with X, then
>making priority inheritable futexes would solve the problem.
>

I _think_ communication with X will mostly be done with waitqueues.
Someone has a priority inheritance futex patch around. I'm not sure
that it is such an open and shut case as you think though. Even if you
could use futexes in communication with X.

>
>>The scheduler in Linus' tree is basically obsolete now, so there isn't
>>any point testing it really. Test Con's or my patches, and let us know
>>if you're still having problems with sir dumps-a-lot.
>>
>
>Okay enough said, you and Con should get your patches merged into that tree
>ASAP if they're ready.
>
>

I think Con's is ready (I think mine is as well, but nobody else does!)

Re:

[Raj]

Bloch, Jack wrote:

>I try to open a non-existan device driver node file. The Kernel returns a
>value of -1 (expected). However, when I read the value of errno it contains
>a value of 29. A call to the perror functrion does print out the correct
>error message (a value of 2). Why does this happen?
>
>  
>
I tried this on a 2.6.0-test11 and it works fine. Pls specify your 
kernel version and attach the program if possible.

/Raj

Re:

[Oliver Hunt]

No its not, doing something similar to (or identical) to a GPL'd program 
is fine, if you were to use a GPL'd IRC server/client as the base for 
your own code, then you'd need to pblish using the GPL...

IRC would be in the realm of software patents really - it's a protocol - 
the client/serverside code comes under copyright laws :)

--Oliver

gmack@innerfire.net wrote:

>From gmack@innerfire.net  Fri Dec  5 12:36:11 2003
>Received: from localhost (sendmail-bs@127.0.0.1)
>  by localhost with SMTP; 5 Dec 2003 17:36:11 -0000
>Date: Fri, 5 Dec 2003 12:36:11 -0500 (EST)
>From: Gerhard Mack <gmack@innerfire.net>
>To: Linus Torvalds <torvalds@osdl.org>
>cc: David Schwartz <davids@webmaster.com>, Valdis.Kletnieks@vt.edu, 
>    Peter Chubb <peter@chubb.wattle.id.au>, linux-kernel@vger.kernel.org
>Subject: RE: Linux GPL and binary module exception clause? 
>In-Reply-To: <Pine.LNX.4.58.0312042245350.9125@home.osdl.org>
>Message-ID: <Pine.LNX.4.58.0312051232530.16547@innerfire.net>
>References: <MDEHLPKNGKAHNMBLJOLKMEIDIHAA.davids@webmaster.com>
> <Pine.LNX.4.58.0312042245350.9125@home.osdl.org>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>X-Spam-Status: No, hits=-104.5 required=4.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,USER_IN_WHITELIST version=2.20
>X-Spam-Level: 
>
>Those views are scary when you consider that webmaster Inc sells closed
>source software that works exactly like IRC (wich is GPL)
>
>On Thu, 4 Dec 2003, Linus Torvalds wrote:
>
>  
>
>>Date: Thu, 4 Dec 2003 22:58:09 -0800 (PST)
>>From: Linus Torvalds <torvalds@osdl.org>
>>To: David Schwartz <davids@webmaster.com>
>>Cc: Valdis.Kletnieks@vt.edu, Peter Chubb <peter@chubb.wattle.id.au>,
>>     linux-kernel@vger.kernel.org
>>Subject: RE: Linux GPL and binary module exception clause?
>>
>>
>>
>>On Thu, 4 Dec 2003, David Schwartz wrote:
>>    
>>
>>>The GPL gives you the unrestricted right to *use* the original work.
>>>This implicitly includes the right to peform any step necessary to use
>>>the work.
>>>      
>>>
>>No it doesn't.
>>
>>Your logic is fundamentally flawed, and/or your reading skills are
>>deficient.
>>
>>The GPL expressly states that the license does not restrict the act of
>>"running the Program" in any way, and yes, in that sense you may "use" the
>>program in whatever way you want.
>>
>>But that "use" is clearly limited to running the resultant program. It
>>very much does NOT say that you can "use the header files in any way you
>>want, including building non-GPL'd programs with them".
>>
>>In fact, it very much says the reverse. If you use the source code to
>>build a new program, the GPL _explicitly_ says that that new program has
>>to be GPL'd too.
>>
>>    
>>
>>>Please tell me how you use a kernel header file, other than by including
>>>it in a code file, compiling that code file, and executing the result.
>>>      
>>>
>>You are a weasel, and you are trying to make the world look the way you
>>want it to, rather than the way it _is_.
>>
>>You use the word "use" in a sense that is not compatible with the GPL. You
>>claim that the GPL says that you can "use the program any way you want",
>>but that is simply not accurate or even _close_ to accurate. Go back and
>>read the GPL again. It says:
>>
>>	"The act of running the Program is not restricted"
>>
>>and it very much does NOT say
>>
>>	"The act of using parts of the source code of the Program is not
>>	 restricted"
>>
>>In short: you do _NOT_ have the right to use a kernel header file (or any
>>other part of the kernel sources), unless that use results in a GPL'd
>>program.
>>
>>What you _do_ have the right is to _run_ the kernel any way you please
>>(this is the part you would like to redefine as "use the source code",
>>but that definition simply isn't allowed by the license, however much you
>>protest to the contrary).
>>
>>So you can run the kernel and create non-GPL'd programs while running it
>>to your hearts content. You can use it to control a nuclear submarine, and
>>that's totally outside the scope of the license (but if you do, please
>>note that the license does not imply any kind of warranty or similar).
>>
>>BUT YOU CAN NOT USE THE KERNEL HEADER FILES TO CREATE NON-GPL'D BINARIES.
>>
>>Comprende?
>>
>>		Linus
>>-
>>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>the body of a message to majordomo@vger.kernel.org
>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>Please read the FAQ at  http://www.tux.org/lkml/
>>
>>    
>>
>
>--
>Gerhard Mack
>
>gmack@innerfire.net
>
><>< As a computer I find your faith in technology amusing.
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>  
>

Re:

[Jonathan Corbet]

> 1) When I set a timer, it is added to a timer_list chain with add_timer().
> If the time is up and the scheduled function is called, should I remove the
> timer_list struct from the chain via del_timer() ? Or is it removed
> automatically ?

It will be removed automatically, just before your timer function is called.

> 2) How can a module safely removed if it has some running timers ? I have to
> call del_timer() in cleanup_module() for each running timer ? 

You cannot remove a module (safely) if there are outstanding timers.  Use
del_timer_sync() to get rid of them and ensure they aren't running on
another processor.

Chapter 6 of Linux Device Drivers covers this topic; see:

	http://www.xml.com/ldd/chapter/book/ch06.html

jon

Re:

[Tommy Reynolds]

[-- Attachment #1: Type: text/plain, Size: 893 bytes --]

Uttered "Bloch, Jack" <Jack.Bloch@icn.siemens.com>, spake thus:

Please do not include me in the CC: list as I belong to this mailing
list.

Do not reply privately to this message, keep it all out in the open ;-)

> It is not really a device, simply a file loaded into memory by another
> process at a fixed location.

Userland processes _do_ have resource limits.  Try a "man getrlimit"
for some hints here.

There is a max process size limit (RLIMIT_DATA) and the number of VM
pages kept in RAM (RLIMIT_RSS).

Keep in mind that a child processes usually inherits whatever rlimits
are left unused by the parent process, so if your program is being
started from another program near its limits, the child process
begins with those limitations as well.

1)  Can a standalone test program, started from the shell, map the
    data?

2)  How was the kernel memory used to hold the data obtained?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re:

[Alexandr Chernyy]

On Monday 09 February 2004 22:05, Alexandr Chernyy wrote:

 >> Hello All! Can you help me! I write module for kernel 2.4.22 and have
 >> some problems! I need to read some information form file, create
 >> directory and etc. (Did kerlen have some stdio.h like function - fopen,
 >> fgets, fclose......)!!! Please help me.


 > what you are looking for is not usually needed by 'normal' kernel 
modules.
 > could you please be more specific on what is exactly your porpouse?

 > alessandro

for example i need to create directory in all mounting devices when 
module load!!!
and read some informations form /proc/mounts

WBR, Alexandr Chernyy

Re:

[Larry Reaves]

I suggest that you read
http://linuxdevices.com/articles/AT4389927951.html it is an article
about the differences between modules for 2.4 and 2.6.  Basically all
you need to do to get it to work is delete your Makefile and create a
new one with only this line:
obj-m := hello.o
and then issue the following command:
make -C /usr/src/linux-2.6.3 SUBDIRS=$PWD modules
your module compiles fine on my box using this method

On Sun, 2004-02-22 at 12:51, redzic fadil wrote:
> hello
> 
> 
> I hope I don't disturb,
> 
> 
> I have tried to compile the hello.c module under kernel 2.6.3.
> And I'd like to insert the hello.o module in the kernel.
> But this doesn't work with kernel 2.6.3 .
> 
> I have compiled this module with kernel 2.4.* and it is well.
> 
> Also I cannot include the header file module.h, because I get error 
> messages.
> 
> my module:
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/init.h>
> 
> 
> int initial_module (void)
> {
> 	printk("\ninitial module\n");
> 	return (0);
> }
> 
> void delete_module (void)
> {
> 	printk("\ndelete module\n");
> }
> 
> module_init(initial_module);
> module_exit(delete_module);
> 
> 
> my Makefile:
> CC=gcc
> CFLAGS=-isystem /lib/modules/`uname -r`/build/include -O2 -D__KERNEL__ 
> -DMODULE
> all: hello.o
> 
> If you have any idea please send an E-Mail:  redzic_fadil@hotmail.com
> 
> thanks
> 
> _________________________________________________________________
> Die ultimative Fan-Seite für den MSN Messenger http://www.ilovemessenger.de
> Emoticons und Hintergründe kostenlos downloaden!
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-- 
Larry Reaves <larry@moonshinecomputers.com>

Re:

[John Bradford]

> Here is a patch to update 2.4 Codingstyle.
> 
> It is equivalent to the 2.6 version except for
> Chapter 9 Configuration files which is unchanged
> 
> Please apply.

[snip]

> -and NOT read it.  Burn them, it's a great symbolic gesture.
> +and NOT read it.  Burn them, it's a great symbolic gesture.

Should be:

+and NOT reading it.  Burn them, it's a great symbolic gesture.

John.

re:

[Kendrick Logan]

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]

Paradise SEX Island Awaits! Tropical 1 week vacations where anything 
goes!


We have lots of WOMEN, SEX, ALCOHOL, ETC!

Every man's dream awaits on this island of pleasure.

Ever wonder what a Fantasy Sex Holiday would be like? 

If it was available at a reasonable cost.........would you go? 

Check out more information on our site & we can make your dream 
vacation a reality....


*All contact, reservations, billings, are strcitly confidential & are 
discussed directly with the client only.

**Group discounts are available. ie. Bachelor parties, etc.

MARCH/APRIL BONUS now available.

http://www.intimate-travelclub.com






















This communication is privileged and contains confidential information 
intended only for the person(s) to whom it is addressed.  Any 
unauthorized disclosure, copying, other distribution  of this 
communication or taking any action on its contents is strictly  prohibited. If you have 
received this message in error, please notify us immediately OR remove 
yourself from our list if there is no interest in regards to our 
services.

http://www.intimate-travelclub.com/remove/remove.html

8
kittenish ponce paso titanic decreeing duma conflagrate expansible carbide salk phone echidna excommunicate template 

Re:

[Vinu Moses]

On Sunday 27 June 2004 07:48 pm, Vinu Moses wrote:
> unsubscribe linux-kernel

Eeps! Sorry! Guess my caffeine levels are low again :-(

Re:

[Norbert van Nobelen]

Assumption:
You are doing "make modules_install"
You are installing a new version of the kernel, not a recompile of the 
currenct kernel.

Is the basic directory in /lib/modules/2.6.8 present for the modules to 
install in?


On Sunday 19 September 2004 17:32, you wrote:
> I am compiling the newest kernel on Redhat Federo 2 and and I am getting
> this error when I am running make modules install.  Do you know how I fix
> this problems please?
>
> Phillip Taylor
>
> INSTALL sound/pci/ymfpci/snd-ymfpci.ko
>   INSTALL sound/pcmcia/pdaudiocf/snd-pdaudiocf.ko
>   INSTALL sound/soundcore.ko
>   INSTALL sound/synth/emux/snd-emux-synth.ko
>   INSTALL sound/synth/snd-util-mem.ko
>   INSTALL sound/usb/snd-usb-audio.ko
> if [ -r System.map ]; then /sbin/depmod -ae -F System.map  2.6.8; fi
> make: *** [_modinst_post] Error 143
> You have new mail in /var/spool/mail/root
> [root@localhost linux-2.6.8]#
>
> Quoting Norbert van Nobelen <Norbert@edusupport.nl>:
> > Warnings are not errors.
> >
> > On Sunday 19 September 2004 14:29, you wrote:
> > > Question: Are you guys going to work on please cleaning up some of the
> > > errors in the code so we can get please get a more clean compile?
> > >
> > >
> > >
> > > drivers/mtd/nftlmount.c:44: warning: unused variable `oob'
> > >
> > > ----------------------------------------------------------------
> > > This message was sent using IMP, the Internet Messaging Program.
> > >
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> > > in the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at  http://www.tux.org/lkml/
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.

Re:

[Marcelo Tosatti]

On Mon, Nov 08, 2004 at 12:08:24PM +0100, Paolo Ciarrocchi wrote:
> On Mon, 8 Nov 2004 05:39:54 -0200, Marcelo Tosatti
> <marcelo.tosatti@cyclades.com> wrote:
> > 
> > unsubscribe linux-kernel
> 
> Marcelo,
> what are you doing ? ;-)

Jesus, what a shame. 

I'm subscribe twice, so I tried to remove one of the 
subscriptions.

/me digs a hole...

Re:

[Paolo Ciarrocchi]

On Mon, 8 Nov 2004 05:39:54 -0200, Marcelo Tosatti
<marcelo.tosatti@cyclades.com> wrote:
> 
> unsubscribe linux-kernel

Marcelo,
what are you doing ? ;-)

-- 
Paolo

Re:

[Guennadi Liakhovetski]

On Mon, 8 Nov 2004, Marcelo Tosatti wrote:

> On Mon, Nov 08, 2004 at 12:08:24PM +0100, Paolo Ciarrocchi wrote:
> > On Mon, 8 Nov 2004 05:39:54 -0200, Marcelo Tosatti
> > <marcelo.tosatti@cyclades.com> wrote:
> > > 
> > > unsubscribe linux-kernel
> > 
> > Marcelo,
> > what are you doing ? ;-)
> 
> Jesus, what a shame. 
> 
> I'm subscribe twice, so I tried to remove one of the 
> subscriptions.
> 
> /me digs a hole...

:-))) I vote for the best out-of-1st-of-April joke of the year for 
Marcelo!:-))

Guennadi
---
Guennadi Liakhovetski

Re:

[Paolo Ornati]

On Wed, 19 Jan 2005 16:25:22 +0200
Gmail <todor.t@gmail.com> wrote:

> !!! ERROR: sys-apps/module-init-tools-3.0-r2 failed.
> !!! Function src_compile, Line 1980, Exitcode 2
> !!! emake module-init-tools failed
> !!! If you need support, post the topmost build error, NOT this status
> message.
> 
> phases failed

Can you explain me what this has to do with Linux Kernel?

You are using Gentoo and a compilation failed, go here:

http://bugs.gentoo.org/

and search for "ALL module-init-tools", if you don't find the solution
then post a new BUG report.


-- 
	Paolo Ornati
	Gentoo Linux (kernel 2.6.10-gentoo-r4)

Re:

[Matthias-Christian Ott]

Deepti Patel wrote:

>Hi 
>I am getting an error while inserting an hello world program. 
>
>[deepti@marieke deepti]$ /sbin/insmod hello-2.ko
>insmod: error inserting 'hello-2.ko': -1 Operation not permitted
>
>I haven't logged in as root. For inserting a module do I need to logged in as root?
>I will really appretiate any suggestions.
>
>Thanks in advance
>
>
>
>  
>
Jep you need to be root.

Matthias-Christian Ott

RE:

[Yong Haynes]

Re:

[Randy.Dunlap]

Raffaele Ianniello wrote:
> I have a problem compiling a module that I am porting form 2.4 to 2.6 linux kernel.
> 
> Compiling with this Makefile:
>  
> DEBUG = y
>  
> KERNELDIR = /usr/src/linix.2.6.9
> SUBDIR = $(KERNELDIR)/drivers/snoop
> INCLUDEDIR = $(KERNELDIR)/include
>  
> obj-m := snoop.o
>  
> modules: $(MAKE) -C $(KERNELDIR) SUBDIR=$(SUBDIR) modules
>  
> clean:
>         rm -f *.o
>         rm -f *.ko
> 
> apperars some lines like:
> ***Warning: "snoop_ip_forward" [drivers/snoop/snoop] is COMMON symbol
> ***Warning: "snoop_ip_forward_finish" [drivers/snoop/snoop] is COMMON symbol
>  
> and I have insert in ip_forward.c some lines:
>  
>     extern int (* snoop_ip_forward_finish) (struct sk_buff *);
> 
> and this is in function ip_forward():
>        if(snoop_ip_forward && (*snoop_ip_forward)(skb) == -6)
>                 goto drop;
>  
> then when I try to install the module it repyes with:
>     insmod: error inserting 'snoop.ko': -1 Invalid module format
> 
> and in /var/log/message appears some lines line:
>     kernel: snoop: Unknown symbol __floatsidf
>     kernel: snoop: Unknown symbol __fixunsdfsi
>     kernel: snoop: Unknown symbol __adddf3
>     kernel: snoop: Unknown symbol __muldf3
> 
> I will be very pleased if you can help me in some way.
> thank you for your time

I don't know what the ***Warning's are, but the first 2
problems to solve are:

a.  use a proper 2.6 Makefile:  see Documentation/kbuild/*
     and http://lwn.net/Articles/driver-porting/
     or see an example at
     http://www.xenotime.net/linux/modprms/Makefile
IOW, you need to use the 2.6 build system.

b.  The code is being generated with some floating point
     operations in it.  Linux kernel does not (generally)
     allow/support FP operations in kernel code, so you'll
     need to use some other method for those calculations.
     (unless this problem goes away because of using the
     correct 2.6 build system tools)

-- 
~Randy

Re:

[Ross Biro]

On Tue, 08 Mar 2005 09:32:48 -0700, Peter W. Morreale
<peter_w_morreale@hotmail.com> wrote:
> 
> This seems wrong since we've mixed locking primitives.
> 
> Is it?

It's not really wrong, it just wastes time turning interrupts off over
and over again.
> ....
> foo()
> {
>     unsigned long lflags;

At this point, interrupts are off, the lock is held.
> 
>     spin_unlock(global_lock);

Interrupts are still off, the lock is no longer held.
>     ...
>     {
>         spin_lock_irqsave(global_lock, &lflags);

Interrupts are still off, and just to be sure we turned them off
again.  The lock is held.
>                 .
>                 .
>         spin_unlock_irqrestore(global_lock, &lflags);
Interrupts are still off, but we restored them to the off state they
were in before
we grabbed the lock the last time.  The lock is no longer held.
>     }
> 
>     spin_lock_irq(global_lock);
Turn off interrupts again just to be extra sure they are off.  The
lock is held again.

>From the looks of this code, the locking will work.  But it's not what
it should be.

If you know foo is only called with interrupts off, then there is no
reason to turn them off over and over again.  Just use the standard
spin_lock and spin_unlock and comment that interrupts are already off.

You should also question if interrupts need to be disabled at all.  If
the spin lock is never grabbed at interrupt time (and probably won't
be in the near future), then there is no point in turning interrupts
on and off at all.

    Ross

Re:

[info]

^[$B40A4L5NA3NDj!*!*!*^[(B
^[$B:#$^$G!"El5~8BDj$@$C$?%5%$%H$,^[(B
^[$B9%I>$K$D$-!"A49q3HBg!*!*:#$,%A%c%s%9$G$9!#^[(B
^[$B"(%3%3$KEPO?$7$F$k=w$N;R$OK\Ev$G$9!#^[(B
1.^[$B5U!{=u4uK>=w@-^[(B
2.^[$B#S#M4uK>=w@-^[(B
3.^[$B:#F|=P2q$$$?$$=w@-^[(B
4.^[$BITNQ4uK>=w@-^[(B
^[$B$J$I$N=w@-=P2q$$J|Bj^[(B

^[$BAa$/$7$J$$$H#S#O#L#D!!#O#U#T^[(B
http://loves.qsv20.com/

Re:

[Jeff Garzik]

Søren Lott wrote:
> in the SATA kconfig menu, the help message from  
> Intel PIIX/ICH SATA support says:
> 
>  CONFIG_SCSI_ATA_PIIX:
> 
> This option enables support for ICH5 Serial ATA.
>  If PATA support was enabled previously, this enables
>  support for select Intel PIIX/ICH PATA host controllers.
> 
> anyone care to clarify if this mean that having enabled:
> 
> CONFIG_IDE=y
> CONFIG_BLK_DEV_IDE=y
> 
> i can use the PATA ports on a ICH5 controller through libata ?
> if not, which is exactly the meaning of "If PATA support was enabled
> previously" on this message ?

I agree it is quite confusing wording.  Probably should remove all 
reference to PATA in the CONFIG_SCSI_ATA_PIIX Kconfig entry.

The comment is referring to the somewhat-hidden fact that if you define 
ATA_ENABLE_PATA in include/linux/libata.h, then libata will support your 
Intel PIIX PATA controllers, in addition to the Intel PIIX SATA controllers.

However, since ATAPI support isn't yet stable, this is of limited 
usefulness.

	Jeff

RE:

[Alejandro Bonilla]

|SALUDOS;
|
|FAVOR ENVIARME TODA LA INFORMACION QUE DISPONGAN DE LINUX LES
|CONFESARE QUE
|NO CONOSCO NADA .
|

Edison,

La mayor informacion que haya esta en google.com ademas en lugares como
kernel.org linux.org y otros websites como el de la distribucion que te
interesa

Esta es una lista de desarrollo, no de preguntas basicas y de solo Ingles.

Gracias,

- Alejandro.

(I'm telling him that this is english only and that this is not a normal
help questions ML)


|MUCHAS  GRACIAS
|
|AT.
|EDISON MENDOZA
|ECUADOR -QUITO

Re:

[radej]

Hey man, here's that site I was telling you about. They are offering huge discounts now on Penis Enhancement Patches

http://www.poqz.com/md/

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Penis Enlargement Patch delivery system which automatically increases penis size up to 3-4 full inches. The patches are the easiest and most effective way to increase your penis size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself !

http://www.poqz.com/md/









u n s u b s c r i b e  
http://www.yzewa.com/un.php 
 

Re:

[Andrew Morton]

"d binderman" <dcb314@hotmail.com> wrote:
>
> I just tried to compile the Linux Kernel version 2.6.11.12
>  with the most excellent Intel C compiler. It said
> 
>  drivers/usb/host/ohci-hub.c(424): warning #175: subscript out of range
>          desc->bitmap [2] = desc->bitmap [3] = 0xff;
>                             ^
> 
>  This is clearly broken code, since there are only up to 16 ports.
> 
>  Suggest avoid trying to initialise bitmap[ 3].

This is queued in -mm:


From: "KAMBAROV, ZAUR" <kambarov@berkeley.edu>

The length of the array desc->bitmap is 3, and not 4:

Definitions involved:

In drivers/usb/core/hcd.h

464  	#define bitmap 	DeviceRemovable

In drivers/usb/host/ohci-hub.c

395  		struct usb_hub_descriptor	*desc

In drivers/usb/core/hub.h

130  	struct usb_hub_descriptor {
131  		__u8  bDescLength;
132  		__u8  bDescriptorType;
133  		__u8  bNbrPorts;
134  		__u16 wHubCharacteristics;
135  		__u8  bPwrOn2PwrGood;
136  		__u8  bHubContrCurrent;
137  		    	/* add 1 bit for hub status change; round to bytes */
138  		__u8  DeviceRemovable[(USB_MAXCHILDREN + 1 + 7) / 8];
139  		__u8  PortPwrCtrlMask[(USB_MAXCHILDREN + 1 + 7) / 8];
140  	} __attribute__ ((packed));

In include/linux/usb.h

306  	#define USB_MAXCHILDREN		(16)

This defect was found automatically by Coverity Prevent, a static analysis
tool.

(akpm: this code should be shot.  Field `bitmap' doesn't exist in struct
usb_hub_descriptor.  And this .c file is #included in
drivers/usb/host/ohci-hcd.c, and someone somewhere #defines `bitmap' to
`DeviceRemovable'.

>From a maintainability POV it would be better to memset the whole array
beforehand - I changed the patch to do that)

Signed-off-by: Zaur Kambarov <zkambarov@coverity.com>
Cc: <linux-usb-devel@lists.sourceforge.net?
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 drivers/usb/host/ohci-hub.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletion(-)

diff -puN drivers/usb/host/ohci-hub.c~coverity-desc-bitmap-overrun-fix drivers/usb/host/ohci-hub.c
--- 25/drivers/usb/host/ohci-hub.c~coverity-desc-bitmap-overrun-fix	2005-06-24 22:11:00.000000000 -0700
+++ 25-akpm/drivers/usb/host/ohci-hub.c	2005-06-24 22:19:48.000000000 -0700
@@ -419,10 +419,11 @@ ohci_hub_descriptor (
 
 	/* two bitmaps:  ports removable, and usb 1.0 legacy PortPwrCtrlMask */
 	rh = roothub_b (ohci);
+	memset(desc->bitmap, 0xff, sizeof(desc->bitmap));
 	desc->bitmap [0] = rh & RH_B_DR;
 	if (ports > 7) {
 		desc->bitmap [1] = (rh & RH_B_DR) >> 8;
-		desc->bitmap [2] = desc->bitmap [3] = 0xff;
+		desc->bitmap [2] = 0xff;
 	} else
 		desc->bitmap [1] = 0xff;
 }
_

Re:

[Andrew Morton]

"d binderman" <dcb314@hotmail.com> wrote:
>
> 
> Hello there,
> 
> I just tried to compile the Linux Kernel version 2.6.11.12
> with the gcc 4.0 compiler. The compiler said
> 
> drivers/net/depca.c:1829: warning: operation on 'i' may be undefined
> 
> The source code is
> 
> for (i = entry; i != end; i = (++i) & lp->txRingMask) {
> 
> I agree with the compiler. Better code is
> 
> for (i = entry; i != end; i = (i + 1) & lp->txRingMask) {
> 

Someone already fixed it.

		/* set up the buffer descriptors */
		len = (skb->len < ETH_ZLEN) ? ETH_ZLEN : skb->len;
		for (i = entry; i != end; i = (i+1) & lp->txRingMask) {

Re:

[Denis Vlasenko]

On Wednesday 21 September 2005 16:20, Robert.Boermans@uk.telex.com wrote:
> Hello, 
> 
> I noticed that the bogomips results for the two cores on my machine are 
> consistently not the same, the second one is always reported slightly 
> faster, it's a small difference and I saw the same in a posted dmesg from 
> somebody else on the list. Which made me wonder: 

I guess it's a cache warming effect. Please show the numbers.
--
vda

Re:

[Alejandro Bonilla]

On Wed, 09 Nov 2005 13:13:34 -0300, Nestor Velazquez wrote
> Hola necesito informacion sobre linux gracias

Nestor,

Esta es una mailing list en ingles. Porfavor escriba en ingles,
adicionalmente, esta lista es solo para desarrollo, porfavor si desea
informacion, busque en libros de Linux y en paginas de internet.

(Told him to speak english and to read books of Linux)

.Alejandro
 
> Velazquez Nestor

Re:

[Dmitry Torokhov]

On 12/2/05, Yu, Luming <luming.yu@intel.com> wrote:
> I just tested module wistron_btn on  one Acer Aspire laptop after
> adding one dmi entry.  The wistron_btn found BIOS interfaces.
> One visible error is the bluetooth light won't turn on upon
> stroking bluetooth button.
> Without wistron_btn module, the bluetooth light works.
>  with acpi enabled, I didn't try acpi disabled)
>

Did you add the new keymap table with KE_BLUETOOTH to go with that DMI entry?

> wistron_btn polls a cmos address to detect hotkey event.  It
> is not necessary, because there do have ACPI interrupt triggered upon
> hotkeys.
>

Unfortunately ACPI does not route these events through the input layer
so aside from special buttons (like sleep) it is not very useful.

> So, my suggestion is to disable this module when ACPI enabled.
> We need to implement hotkey support from ACPI subsystem for my
> Acer aspire laptop.

I do not agree.

--
Dmitry

Re:

[Miloslav Trmac]

Yu, Luming wrote:
> I just tested module wistron_btn on  one Acer Aspire laptop after 
> adding one dmi entry.  The wistron_btn found BIOS interfaces.
> One visible error is the bluetooth light won't turn on upon 
> stroking bluetooth button.
> Without wistron_btn module, the bluetooth light works.
>  with acpi enabled, I didn't try acpi disabled)
> 
> wistron_btn polls a cmos address to detect hotkey event.  It 
> is not necessary, because there do have ACPI interrupt triggered upon 
> hotkeys.
There are many different laptops using similar interfaces.
It is a mess :(

If your laptop provides the hotkey events via ACPI, simply don't use
wistron_btns.

> So, my suggestion is to disable this module when ACPI enabled.
I have a laptop that needs this module (hotkeys are not supported via
ACPI), but supports ACPI.
	Mirek

Re:

[Mark v Wolher]

Jiri Slaby wrote:
> Mauro Carvalho Chehab wrote:
> 
>>Em Dom, 2006-01-01 Ã s 19:49 +0100, Mark v Wolher escreveu:
>>
>>>So, Mauro (or somebody from list), have you any idea, what could be
>>>wrong?  
>>
>>	hmm.. have you sent the patch to the list?
> 
> Yes, it was only a (bad) try to solve the problem. The point is, that there is
> some weird problem in the estimating, or something (number of loops?).
> 
> The oops and the patch are on lkml site in this thread, I would give you a
> link, but lkml seems to be down for me.
> [the patch helps in some way, but didn't solve the problem]
> 
> all the best,

But i wonder, can you think of something why grabdisplay causes crashes
and overlay doesn't ? This needed patch, would it solve this problem too ?

Thanks

Re:

[Arjan van de Ven]

On Fri, 2006-01-27 at 15:35 +0530, sarat wrote:
> 
> insmod: error inserting 'firewall.ko': -1 Invalid module format

your module is not compatible with the kernel you are running. In dmesg
or /var/log/messages is more information on the nature of the
incompatibility.

Re:

[Ira Jackson]

Hi,

We cut your payment by 45%

Re aF ainancing can give you extra acash for the things you've always want=
ed to do. Like starting a home business or paying for college.


U S  $ 300 ,000       aL0 aANS        are avai lable for only $277 / month=
! WE'RE aPRACT ICALLY aGIVIaNG aAWAY MOaNEY!

---------------------------------

COPY the Addreass below and paste in your WEaB BROaWSER:

carucal.realquikx.com

----------------------------------

V a l id for 24 Hrs.

I need not start -- you're sure --.
professor and former chief of GE's Crotonville leadership development prog=
ram..
Of Life immense in passion, pulse, and power,=20.
No safety , no love, no respect was I due..
Yet shining like the sun with love's true light.=20.


Thanks Alot,
Elsa Robb

Re: Re:

[Donne]

Good day sir,

Loow cost name-brand prei scri iptions shipped to your door lightning quic=
k!

Fruee delivery and unique packaging.

--------------------------------

copy the address below and paste in a your web browser:

arrestor.newtechtown.com/?zz=3Dlowcost

--------------------------------

vali d  for 24 hars.


'Well if you had to think about it now, what would you think?'.
when we were sharing rooms as bachelors in Baker Street..
So shake the very Heaven on high.
Of Bobo the Bear..
His books are all jammed in the closet,.

Goodbye,

Hugh Jackson=20

Re:

[Norberto]

Hey,

R3F1N4NC3         your current           L0A`NNNN.

R3F1N@NC3          your          m0rrt g@@gee          at a better      Ra=
a te.


$340k for 330 pm, we r    Justi    Giving    away

******************************************************************

COPY the Address below and paste in your BROiWSER:

Aphelinus.lowestpay.net

******************************************************************


She only looked away for a few seconds to guide her fingers in peeling the=
=20.
(With my lips soothing thee, adding, I whisper,=20.
Considerest thou alone the burial of the stars?=20.
After she'd done her ledger she would clamber into her hammock and read a =
book for a couple of hours..
If you'll just tell me so --.


Thanks,
Morris Kaufmann=20

Re: Re:

[Kennedy]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 653 bytes --]


How have you been,

A11          Pre#scr!pt!0ns       are filled by          L!#cens#ed        Ph@r#m@!_sts.

We have Special    0ff3rss      and some  New       Pr0ducctss.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

copy the address below and paste in e your web browser:

bibliosoph.iyodopack.com

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


A sour Scotswoman called Hooch..
A child—with a most knowing eye..
(With my lips soothing thee, adding, I whisper, .
push the "Perform Currency Conversion" button..
Still bar you the way, and deny you life --  .

Thanks Alot,

Dudley Templeton 

Re:

[Alec]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 909 bytes --]


Hey whats up,

All the maajor barands like aR0lex, aTag uHeuer, aCart ier etc.

Dite for the Rep lica wautches, L0w   ePRi ces we 0 ffer.

Your human instinct is to be recognized.

iAffordable imitations make you look erich, ufraction of the oC0St. 

========================================================================

COPY the Address below and paste in your WEBa browser:


afraidness.justworlds.com

========================================================================


I am the woman who worked in the field .
Despite overall sluggish wage growth,.
Not physiognomy alone, nor brain alone, is worthy for the muse—I say the-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re:

[Arnaldo Carvalho de Melo]

On 5/16/06, Chris Boot <bootc@bootc.net> wrote:
> Hi,
>
> I've just seen the following assertions pop out of one of my servers
> running 2.6.16.9 with grsecurity. I've searched the archives of LKML
> and netdev and I've only found posts relating to 2.6.9, after which
> some related bugs were fixed... It looks like these bugs are related
> to e1000, which is the driver I'm using. The system was running 24
> days before these appeared and it's still running absolutely fine.
>
> May 16 09:15:12 baldrick kernel: [6442250.504000] KERNEL: assertion (!
> sk->sk_forward_alloc) failed at net/core/stream.c (283)
> May 16 09:15:12 baldrick kernel: [6442250.513000] KERNEL: assertion (!
> sk->sk_forward_alloc) failed at net/ipv4/af_inet.c (150)
>
> baldrick bootc # ethtool -k eth0
> Offload parameters for eth0:
> rx-checksumming: on
> tx-checksumming: on
> scatter-gather: on
> tcp segmentation offload: on

I guess just disable TSO or use latest kernel from git, it has a fix for this.

- Arnaldo

Re:

[shane]

Hello,

Your mail to shane@bcs.org.uk was caught by the
SpamAssassin filter running on the bcs.org.uk mail system.

To confirm that your mail is genuine, please click this
link, or paste it into your browser:
https://bcsnet.bcs.org.uk/approve.php?c=2c9bc71e222cc1265421a982

You will not have to do this again for any mail sent
to this recipient (shane@bcs.org.uk).

Thank you.

-- 
British Computer Society - www.bcs.org.uk
Email Services from gradwell dot com - www.gradwell.com

Re:

[hackmiester (Hunter Fuller)]

You're doing it wrong. Please read the bottom of your emails.
On 9 February 2007, at 00:29, Priyanka Sharma wrote:

> unsubscribe linux-kernel
>
> --  
> Priyanka
> 202.141.151.80/~priyanka
> -
> To unsubscribe from this list: send the line "unsubscribe linux- 
> kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
hackmiester (Hunter Fuller)

<badaboom> who can help me ? i'm french and i don't know irc
<Paladine> can't help you with the being french part, you are screwed  
their mate




Phone
Voice: +1 251 589 6348
Fax: Call the voice number and ask.

Email
General chat: hackmiester@hackmiester.com
Large attachments: hackmiester@gmail.com
SPS-related stuff: hfuller@stpaulsmobile.net

IM
AIM: hackmiester1337
Skype: hackmiester31337
YIM: hackm1ester
Gtalk: hackmiester
MSN: hackmiester@hackmiester.com
Xfire: hackmiester

Re:

[Shaohua Li]

> From: "Avi Kivity" <avi@qumranet.com>
> To: "Li, Shaohua" <shaohua.li@intel.com>
> Date: Tue, 24 Jul 2007 13:42:29 +0800
> Subject: Re: [RFC 0/8]KVM: swap out guest pages
>
>
> Shaohua Li wrote:
> > On Mon, 2007-07-23 at 18:27 +0800, Avi Kivity wrote:
> >
> >> Shaohua Li wrote:
> >>
> >>> This patch series make kvm guest pages be able to be swapped out and
> >>> dynamically allocated. Without it, all guest memory is allocated at
> >>> guest start time.
> >>>
> >>> patches are against latest git, and you need first patch Avi's
> >>>
> >> kvm-sch
> >>
> >>> integration patch
> >>>
> >>>
> >>
> (http://sourceforge.net/mailarchive/forum.php?thread_name=11841693332609-git-send-email-avi%40qumranet.com&forum_name=kvm-devel
> ).
> >>
> >>> Patch is quite stable in my test. With the patch, I can run a 256M
> >>> memory guest in a 300M memory host.
> >>>
> >> What about the opposite?
> >>
> >>
> >>> If guest is idle, the memory it used
> >>> can be less than 10M. I did a simple performance test (measure
> >>>
> >> kernel
> >>
> >>> build time in guest), if there is few swap, the performance w/wo the
> >>> patch difference isn't significent. If you have better measurement
> >>> approach, please let me try.
> >>>
> >>> Unresolved issue:
> >>> 1. swapoff doesn't work, we need a hook.
> >>> 2. SMP guest might not work, as kvm doesn't support smp till now.
> >>> 3. better algorithm to select swaped out guest pages according to
> >>> guest's memory usage.
> >>> Maybe more.
> >>>
> >>> Any suggests and comments are appreciated.
> >>>
> >>>
> >> The big question is whether to have kvm's own address_space or not.
> >>
> >> Having an address_space (like your patch does) is remarkably simple,
> >> and
> >> requires few hooks from the current vm.  However using existing vmas
> >> mapped by the user has many advantages:
> >>
> >> - compatible with s390 requirements
> >> - allows the user to use hugetlbfs pages, which have a performance
> >> advantage using ept/npt (but which are unswappable)
> >> - allows the user to map a file (which can be regarded as way to
> >> specify
> >> the swap device)
> >> - better ingration with the rest of the vm
> >>
> >> I am quite torn between the simplicity of your approach and the
> >> advantages of using generic vmas.  However, s390 pretty much forces
> >> our
> >> hand.
> >>
> >> What is your opinion of extending generic vmas to back kvm guest
> >> memory?
> >>
> > several issues:
> > 1. vma is to manage usersapce address, kvm guest uses full address
> > space.
> > 2. qemu itself must use some address space.
> >
>
> My idea is to keep the current slot concept, but instead of having kvm
> allocate pages for a slot, it would call get_user_pages() for a virtual
> address range.  Userspace doesn't directly talk about vmas, just virtual
> address ranges.
all the APIs need vma/page table handling. swap also needs vma for
rmap for generic file.

Thanks,
Shaohua

Re:

[Mark Lord]

Brian J. Murrell wrote:
> I am using Ubuntu Gutsy, which is the in-development branch heading for
> their next stable release.
> 
> I have noticed that since some kernel release post-2.6.20 I have been
> unable to mount my /boot partition:
> 
> $ sudo strace -f mount /dev/hda1 /mnt/foo
> execve("/bin/mount", ["mount", "/dev/hda1", "/mnt/foo"], [/* 41 vars*/])= 0
...                             = 0
> mount("/dev/hda1", "/mnt/foo", "ext3", MS_MGC_VAL, NULL) = -1 EBUSY (Device or resource busy)
> rt_sigprocmask(SIG_UNBLOCK, ~[TRAP SEGV RTMIN RT_1], NULL, 8) = 0
> write(2, "mount: /dev/hda1 already mounted"..., 50mount: /dev/hda1 already mounted or /mnt/foo busy) = 50
...
> All other block devices (all LVM LVs) seem to mount with no problems.

Probably something to do with either LVM or the Device Mapper having
the raw partition already "open" for some remapping purpose.
There was a note about that around here somewhere quite recently..

??

Re: Re:

[Brian J. Murrell]

[-- Attachment #1: Type: text/plain, Size: 496 bytes --]

On Thu, 2007-08-09 at 16:33 -0400, Mark Lord wrote:
> Probably something to do with either LVM or the Device Mapper having
> the raw partition already "open" for some remapping purpose.
> There was a note about that around here somewhere quite recently..

Indeed, that was it.  I posted a followup "Re: [SOLVED] problems while
mounting /boot partition" reporting such.

Thanx for the heads up though!

b.

-- 
My other computer is your Microsoft Windows server.

Brian J. Murrell

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re:

[Segher Boessenkool]

>> "compilation unit" is a C standard term.  It typically boils down
>> to "single .c file".
>
> As you mentioned later, "single .c file with all the other files 
> (headers
> or other .c files) that it pulls in via #include" is actually 
> "translation
> unit", both in the C standard as well as gcc docs.

Yeah.  "single .c file after preprocessing".  Same thing :-)

> "Compilation unit"
> doesn't seem to be nearly as standard a term, though in most places it
> is indeed meant to be same as "translation unit", but with the new gcc
> inter-module-analysis stuff that you referred to above, I suspect one 
> may
> reasonably want to call a "compilation unit" as all that the compiler 
> sees
> at a given instant.

That would be a bit confusing, would it not?  They'd better find
some better name for that if they want to name it at all (remember,
none of these optimisations should have any effect on the semantics
of the program, you just get fewer .o files etc.).


Segher

Re:

[Eric Dumazet]

[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]

Luck, Tony a écrit :
> Just pulled latest git tree from Linus and a few ia64 configurations
> (anything with CONFIG_NUMA=y) won't build.
> 
> The offending commit appears to be:
> 
>     230140cffa7feae90ad50bf259db1fa07674f3a7
> 
> Here's the error messages from the compiler:
> 
>   CC [M]  drivers/infiniband/core/cma.o
> In file included from include/net/tcp.h:35,
>                  from drivers/infiniband/core/cma.c:40:
> include/net/inet_hashtables.h: In function `inet_ehash_locks_alloc':
> include/net/inet_hashtables.h:165: error: implicit declaration of
> function `vmalloc'
> include/net/inet_hashtables.h:165: warning: assignment makes pointer
> from integer without a cast
> include/net/inet_hashtables.h: In function `inet_ehash_locks_free':
> include/net/inet_hashtables.h:186: error: implicit declaration of
> function `vfree'
> make[3]: *** [drivers/infiniband/core/cma.o] Error 1
> 

Hi Tony

Seems an include is missing.

Could you please apply this patch ?

Thank you

[NET] adds a missing include <linux/vmalloc.h>

Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>


[-- Attachment #2: include.patch --]
[-- Type: text/plain, Size: 372 bytes --]

diff --git a/include/net/inet_hashtables.h b/include/net/inet_hashtables.h
index 8461cda..469216d 100644
--- a/include/net/inet_hashtables.h
+++ b/include/net/inet_hashtables.h
@@ -23,6 +23,7 @@
 #include <linux/spinlock.h>
 #include <linux/types.h>
 #include <linux/wait.h>
+#include <linux/vmalloc.h>
 
 #include <net/inet_connection_sock.h>
 #include <net/inet_sock.h>

Re:

[David Miller]

From: Eric Dumazet <dada1@cosmosbay.com>
Date: Sat, 10 Nov 2007 02:42:42 +0100

> [NET] adds a missing include <linux/vmalloc.h>
> 
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>

Applied, thanks Eric.

Re:

[Benny Halevy]

am kara wrote:
> hello,
> 
> If kernel does kmap_atomic(temporary kernel mapping)
> on behalf of a process by a cpu, does the process will
> continue to run and no other process can be scheduled
> to switch it off?(till kunmap_atomic is done)

Effectively, kmap_atomic implementations call pagefault_disable
and that in turn is equivalent to preempt_disable()
so the answer to your question seems to be "yes".

Benny

Re:

[Lee Revell]

On Wed, Apr 9, 2008 at 4:45 AM, Andreas Grimm <agrimm61@yahoo.com> wrote:
> Hello everybody,
>
>   i got a weird problem with one of my servers. It's a Intel SR2500AL with 32GB of RAM.
>   Looking at the memory usage of the system, something is going totally wrong. The crucial numbers from /proc/meminfo are:
>
>   MemTotal:     33265916 kB
>   MemFree:        416168 kB
>   Inactive:     24630428 kB   (24GB? whooaaa)
>

Why did you start 3 separate threads for this issue?  That's more
likely to annoy people than to get them to help you.

Lee

Re:

[Oliver Neukum]

Am Dienstag 20 Mai 2008 14:34:23 schrieb Lukas Hejtmanek:
> <stern@rowland.harvard.edu>, Greg KH <greg@kroah.com>
> Bcc: 
> Subject: Re: [Bug #10630] USB devices plugged into dock are not discoverred
> 	until reload of ehci-hcd
> Reply-To: 
> In-Reply-To: <200805201327.34678.oliver@neukum.org>
> X-echelon: NSA, CIA, CI5, MI5, FBI, KGB, BIS, Plutonium, Bin Laden, bomb
> 
> On Tue, May 20, 2008 at 01:27:34PM +0200, Oliver Neukum wrote:
> > > done.
> > > http://bugzilla.kernel.org/show_bug.cgi?id=10630
> > 
> > Aha. Thanks.
> > Please recompile without CONFIG_USB_SUSPEND
> 
> Hm, without USB_SUSPEND it works. So what next, considered fixed or any
> further investigation is needed?

It is by no means fixed!

Now we find out what exactly doesn't work. Please apply this patch
and provide "dmesg -c" before you plug in the device and after that.

	Regards
		Oliver

---

--- linux-2.6.25/drivers/usb/host/ehci-hcd.c	2008-05-20 10:07:45.585199135 +0200
+++ alt/drivers/usb/host/ehci-hcd.c	2008-05-20 11:11:53.614580823 +0200
@@ -712,11 +712,15 @@ static irqreturn_t ehci_irq (struct usb_
 		unsigned	i = HCS_N_PORTS (ehci->hcs_params);
 		pcd_status = status;
 
+		printk(KERN_ERR"Detected PCD bit set\n");
 		/* resume root hub? */
-		if (!(ehci_readl(ehci, &ehci->regs->command) & CMD_RUN))
+		if (!(ehci_readl(ehci, &ehci->regs->command) & CMD_RUN)) {
+			printk(KERN_ERR"About to resume root hub due to PCD\n");
 			usb_hcd_resume_root_hub(hcd);
+		}
 
 		while (i--) {
+			printk(KERN_ERR"Checking motherboard port %d\n", i);
 			int pstatus = ehci_readl(ehci,
 						 &ehci->regs->port_status [i]);
 
@@ -730,6 +734,7 @@ static irqreturn_t ehci_irq (struct usb_
 			 * and make khubd collect PORT_STAT_C_SUSPEND to
 			 * stop that signaling.
 			 */
+			printk(KERN_ERR"Starting timer for port %d\n", i);
 			ehci->reset_done [i] = jiffies + msecs_to_jiffies (20);
 			ehci_dbg (ehci, "port %d remote wakeup\n", i + 1);
 			mod_timer(&hcd->rh_timer, ehci->reset_done[i]);
--- linux-2.6.25/drivers/usb/core/hcd.c	2008-05-20 10:07:45.583199804 +0200
+++ alt/drivers/usb/core/hcd.c	2008-05-20 11:12:23.506597140 +0200
@@ -589,6 +589,8 @@ void usb_hcd_poll_rh_status(struct usb_h
 			hcd->poll_pending = 1;
 		}
 		spin_unlock_irqrestore(&hcd_root_hub_lock, flags);
+	} else {
+		printk(KERN_ERR"hub_status_data() returned 0\n");
 	}
 
 	/* The USB 2.0 spec says 256 ms.  This is close enough and won't

Re:

[Eduard - Gabriel Munteanu]

On Wed, 9 Jul 2008 11:47:53 -0400
Mathieu Desnoyers <compudj@krystal.dyndns.org> wrote:

> Bcc: 
> Subject: Re: [patch 05/15] LTTng instrumentation - scheduler (repost)
> Reply-To: 
> In-Reply-To: <20080709153434.GA9186@Krystal>
> X-Editor: vi
> X-Info: http://krystal.dyndns.org:8080
> X-Operating-System: Linux/2.6.21.3-grsec (i686)
> X-Uptime: 11:46:04 up 34 days, 20:27,  4 users,  load average: 2.95,
> 2.43, 2.46
> 

Perhaps you should resend this correctly.

Re:

[Mathieu Desnoyers]

* Eduard - Gabriel Munteanu (eduard.munteanu@linux360.ro) wrote:
> On Wed, 9 Jul 2008 11:47:53 -0400
> Mathieu Desnoyers <compudj@krystal.dyndns.org> wrote:
> 
> > Bcc: 
> > Subject: Re: [patch 05/15] LTTng instrumentation - scheduler (repost)
> > Reply-To: 
> > In-Reply-To: <20080709153434.GA9186@Krystal>
> > X-Editor: vi
> > X-Info: http://krystal.dyndns.org:8080
> > X-Operating-System: Linux/2.6.21.3-grsec (i686)
> > X-Uptime: 11:46:04 up 34 days, 20:27,  4 users,  load average: 2.95,
> > 2.43, 2.46
> > 
> 
> Perhaps you should resend this correctly.
> 

This email is superseded by "Re: [patch 05/15] LTTng instrumentation -
scheduler (merge ftrace markers)". I'll have to work on my
vim-header-editing skills. I've done too much C code and too few SMTP
header edit lately. ;) Thanks for pointing this out.

Mathieu

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

RE:

[Trond Myklebust]

On Sun, 2008-07-27 at 10:40 -0700, Linus Torvalds wrote:
> Trond?
> 
> See 'http://lkml.org/lkml/2008/7/17/154'? It's been 10+ days, it's 
> apparently still there.
> 
> 		Linus

Sure thing...

Please pull from the "hotfixes" branch of the repository at

   git pull git://git.linux-nfs.org/projects/trondmy/nfs-2.6.git hotfixes

This will update the following files through the appended changesets.

  Cheers,
    Trond

----
 fs/nfs/super.c  |    6 +++---
 fs/nfs/unlink.c |    3 ++-
 2 files changed, 5 insertions(+), 4 deletions(-)

commit 744d18dbfae07482ea461701b0aaec3a75ec9224
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Sun Jul 27 18:03:19 2008 -0400

    NFS: Ensure we call nfs_sb_deactive() after releasing the directory inode
    
    In order to avoid the "Busy inodes after unmount" error message, we need to
    ensure that nfs_async_unlink_release() releases the super block after the
    call to nfs_free_unlinkdata().
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 31c9446993f412ecb7875e30bba4bc7f216ae016
Author: Marc Zyngier <maz@misterjones.org>
Date:   Thu Jul 17 13:21:55 2008 +0200

    nfs_remount oops when rebooting + possible fix
    
    Jeff, Trond,
    
    The commit
    
    48b605f83c920d8daa50e43fc2c7f718e04c7bfa (NFS: implement option checking
    when remounting NFS filesystems (resend))
    
    generate an Oops on my platform when rebooting while its root FS on
    an NFS share (NFSv3, TCP) :
    
    Unmounting local filesystems...done.
    Unable to handle kernel NULL pointer dereference at virtual address 00000000
    pgd = c3d00000
    [00000000] *pgd=a3d72031, *pte=00000000, *ppte=00000000
    Internal error: Oops: 17 [#1]
    Modules linked in: cpufreq_powersave cpufreq_ondemand cpufreq_userspace cpufreq_conservative ext3 jbd sd_mod pata_pcmcia libata scsi_mod pcmcia loop firmware_class pxafb cfbcopyarea cfbimgblt cfbfillrect pxa2xx_cs pxa2xx_core pcmcia_core snd_pxa2xx_ac97 snd_ac97_codec ac97_bus snd_pxa2xx_pcm snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd isp116x_hcd soundcore rtc_sa1100 snd_page_alloc pxa25x_udc usbcore rtc_ds1307 rtc_core
    CPU: 0    Not tainted  (2.6.26-03414-g33af79d-dirty #15)
    PC is at nfs_remount+0x40/0x264
    LR is at do_remount_sb+0x158/0x194
    pc : [<c00bbf54>]    lr : [<c0076c40>]    psr: 60000013
    sp : c2dd1e70  ip : c2dd1e98  fp : c2dd1e94
    r10: 00000040  r9 : c3d17000  r8 : c3c3fc40
    r7 : 00000000  r6 : 00000000  r5 : c3d2b200  r4 : 00000000
    r3 : 00000003  r2 : 00000000  r1 : c2dd1e9c  r0 : c3c3fc00
    Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
    Control: 0000397f  Table: a3d00000  DAC: 00000015
    Process mount (pid: 1462, stack limit = 0xc2dd0270)
    Stack: (0xc2dd1e70 to 0xc2dd2000)
    1e60:                                     00000000 c3c3fc00 00000000 00000000
    1e80: c3c3fc40 c3d17000 c2dd1ebc c2dd1e98 c0076c40 c00bbf20 c01c61e4 00000001
    1ea0: c2dd1ebc 00000001 c3c3fc00 c2dd1ef0 c2dd1ee4 c2dd1ec0 c008c6d8 c0076af4
    1ec0: 00000021 00000040 c2dd1ef0 c3d77000 c3eaa000 00000000 c2dd1f6c c2dd1ee8
    1ee0: c008d1bc c008c5f8 00000000 c2dd0000 c3c0c320 c3805b38 c002064c 0001f820
    1f00: 0001f810 00000001 00000001 00000000 c2dd0000 00000000 c2dd1f34 c2dd1f28
    1f20: c005ead8 c005e6f8 c2dd1f44 c2dd1f38 c005eaf8 c005ead0 c2dd1f6c c2dd1f48
    1f40: c008ae3c 00000000 c3d77000 0001f810 c0ed0021 c0020ca8 c2dd0000 00000000
    1f60: c2dd1fa4 c2dd1f70 c008d2d4 c008d0bc 00000000 0001f810 c2dd1f9c c3eaa000
    1f80: c3d17000 00000000 00000000 be8b6aa8 be8b6ad0 00000015 00000000 c2dd1fa8
    1fa0: c0020b00 c008d254 00000000 be8b6aa8 0001f810 0001f820 0001f830 c0ed0021
    1fc0: 00000000 be8b6aa8 be8b6ad0 00000015 00000000 be8b6ad0 0001f810 be8b6aa8
    1fe0: 0001f810 be8b6964 0000aab8 40125124 60000010 0001f810 00000000 00000000
    Backtrace:
    [<c00bbf14>] (nfs_remount+0x0/0x264) from [<c0076c40>] (do_remount_sb+0x158/0x194)
      r9:c3d17000 r8:c3c3fc40 r7:00000000 r6:00000000 r5:c3c3fc00
    r4:00000000
    [<c0076ae8>] (do_remount_sb+0x0/0x194) from [<c008c6d8>] (do_remount+0xec/0x118)
      r6:c2dd1ef0 r5:c3c3fc00 r4:00000001
    [<c008c5ec>] (do_remount+0x0/0x118) from [<c008d1bc>] (do_mount+0x10c/0x198)
    [<c008d0b0>] (do_mount+0x0/0x198) from [<c008d2d4>] (sys_mount+0x8c/0xd4)
    [<c008d248>] (sys_mount+0x0/0xd4) from [<c0020b00>] (ret_fast_syscall+0x0/0x2c)
      r7:00000015 r6:be8b6ad0 r5:be8b6aa8 r4:00000000
    Code: 0a000086 ea000006 e3530003 8a000004 (e5923000)
    ---[ end trace 55e1b689cf8c8a6a ]---
    ------------[ cut here ]------------
    WARNING: at kernel/exit.c:966 do_exit+0x3c/0x628()
    Modules linked in: cpufreq_powersave cpufreq_ondemand cpufreq_userspace cpufreq_conservative ext3 jbd sd_mod pata_pcmcia libata scsi_mod pcmcia loop firmware_class pxafb cfbcopyarea cfbimgblt cfbfillrect pxa2xx_cs pxa2xx_core pcmcia_core snd_pxa2xx_ac97 snd_ac97_codec ac97_bus snd_pxa2xx_pcm snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd isp116x_hcd soundcore rtc_sa1100 snd_page_alloc pxa25x_udc usbcore rtc_ds1307 rtc_core
    [<c0025168>] (dump_stack+0x0/0x14) from [<c0032154>] (warn_on_slowpath+0x4c/0x68)
    [<c0032108>] (warn_on_slowpath+0x0/0x68) from [<c003531c>] (do_exit+0x3c/0x628)
      r6:0000000b r5:c3c3dc80 r4:c2dd0000
    [<c00352e0>] (do_exit+0x0/0x628) from [<c0025004>] (die+0x2b0/0x30c)
    [<c0024d54>] (die+0x0/0x30c) from [<c00270bc>] (__do_kernel_fault+0x6c/0x80)
    [<c0027050>] (__do_kernel_fault+0x0/0x80) from [<c00272e0>] (do_page_fault+0x210/0x230)
      r7:c3fa7118 r6:c3c3dc80 r5:c3d166a8 r4:00010000
    [<c00270d0>] (do_page_fault+0x0/0x230) from [<c00201ec>] (do_DataAbort+0x3c/0xa0)
    [<c00201b0>] (do_DataAbort+0x0/0xa0) from [<c002064c>] (__dabt_svc+0x4c/0x60)
    Exception stack(0xc2dd1e28 to 0xc2dd1e70)
    1e20:                   c3c3fc00 c2dd1e9c 00000000 00000003 00000000 c3d2b200
    1e40: 00000000 00000000 c3c3fc40 c3d17000 00000040 c2dd1e94 c2dd1e98 c2dd1e70
    1e60: c0076c40 c00bbf54 60000013 ffffffff
      r8:c3c3fc40 r7:00000000 r6:00000000 r5:c2dd1e5c r4:ffffffff
    [<c00bbf14>] (nfs_remount+0x0/0x264) from [<c0076c40>] (do_remount_sb+0x158/0x194)
      r9:c3d17000 r8:c3c3fc40 r7:00000000 r6:00000000 r5:c3c3fc00
    r4:00000000
    [<c0076ae8>] (do_remount_sb+0x0/0x194) from [<c008c6d8>] (do_remount+0xec/0x118)
      r6:c2dd1ef0 r5:c3c3fc00 r4:00000001
    [<c008c5ec>] (do_remount+0x0/0x118) from [<c008d1bc>] (do_mount+0x10c/0x198)
    [<c008d0b0>] (do_mount+0x0/0x198) from [<c008d2d4>] (sys_mount+0x8c/0xd4)
    [<c008d248>] (sys_mount+0x0/0xd4) from [<c0020b00>] (ret_fast_syscall+0x0/0x2c)
      r7:00000015 r6:be8b6ad0 r5:be8b6aa8 r4:00000000
    ---[ end trace 55e1b689cf8c8a6a ]---
    /etc/rc6.d/S60umountroot: line 17:  1462 Segmentation fault      mount $MOUNT_FORCE_OPT -n -o remount,ro -t dummytype dummydev / 2> /dev/null
    
    The new super.c:nfs_remount function doesn't check the validity of the
    options/options4 pointers. Unfortunately, this seems to happend.
    The obvious patch seems to check the pointers, and not to do anything if
    the happend to be NULL.
    
    Tested on an XScale PXA255 system, latest git.
    
    Regards,
    
    	M.
    
    Signed-off-by: Marc Zyngier <marc.zyngier@altran.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index 1b94e36..9abcd2b 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -1718,9 +1718,9 @@ nfs_remount(struct super_block *sb, int *flags, char *raw_data)
 	 * ones were explicitly specified. Fall back to legacy behavior and
 	 * just return success.
 	 */
-	if ((nfsvers == 4 && options4->version == 1) ||
-	    (nfsvers <= 3 && options->version >= 1 &&
-	     options->version <= 6))
+	if ((nfsvers == 4 && (!options4 || options4->version == 1)) ||
+	    (nfsvers <= 3 && (!options || (options->version >= 1 &&
+					   options->version <= 6))))
 		return 0;
 
 	data = kzalloc(sizeof(*data), GFP_KERNEL);
diff --git a/fs/nfs/unlink.c b/fs/nfs/unlink.c
index 3adf8b2..f089e58 100644
--- a/fs/nfs/unlink.c
+++ b/fs/nfs/unlink.c
@@ -95,10 +95,11 @@ static void nfs_async_unlink_done(struct rpc_task *task, void *calldata)
 static void nfs_async_unlink_release(void *calldata)
 {
 	struct nfs_unlinkdata	*data = calldata;
+	struct super_block *sb = data->dir->i_sb;
 
 	nfs_dec_sillycount(data->dir);
-	nfs_sb_deactive(NFS_SERVER(data->dir));
 	nfs_free_unlinkdata(data);
+	nfs_sb_deactive(NFS_SB(sb));
 }
 
 static const struct rpc_call_ops nfs_unlink_ops = {


-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re:

[Robert Hancock]

stock@stokkie.net wrote:
>>> How about giving your sound device a proper seperate IRQ number?
>>> At least libata should like eth0 have its own kernel resources.
>> That's an issue with the way the motherboard IRQ lines are wired. 
>> There's nothing the kernel can do about it.
> 
> That sounds rather strange to me, as IRQ line 16 is a virtual
> IRQ as part of IO-APIC.

It's still generally wired that way on the motherboard, both devices are 
connected to the same IRQ line. Or at least, the kernel has no control 
over what devices are routed to what IRQs. It gets  the IRQ mapping from 
the BIOS and uses it.

> 
>> Normally I wouldn't expect that to make a big difference though..
> 
> fact is that when copying a iso from one SATA disk to the
> other results in flaky sound when playing online internet radio.
> Even starting firefox for the 1st time after booting results
> in flaky sound for a short time.
> 
>> You'd really have to try a newer kernel first in order to get much help, 
>> though. That's a pretty ancient kernel. Quite likely the situation is 
>> improved in newer versions.
> 
> I sure would like todo that. But why doesn't the linux-kernel community
> know howto pull virtual IRQ lines apart, as part of configuring
> a linux kernel? In the days of 386/486 cpu's, IRQ's of several
> add-on cards could be adjusted manually by jumpers. Why is there not
> such a thing for virtual IRQ's inside the IO-APIC system?
> 
> The libata driver should like eth0 on IRQ 19 have its own IRQ.

You'd have to take that up with your motherboard manufacturer, 
unfortunately :-)

Re:

[Bill Davidsen]

Yudha Harimantoro T wrote:
> Date:	Fri, 10 Oct 2008 16:41:36 -0400
> From:	Bill Davidsen
>
>
>   
>> Yudha Harimantoro T wrote:
>>     
>>> Hi all,
>>> Yesterday I build kernel 2.6.26.6 and it's run well. Today I got
>>> 2.6.27 patch and try to build it.
>>>
>>> I build with `make oldconfig` and answer any question with default answer, I just press [enter].
>>> I build with `make`. No error and all compiled.
>>> Then I install with `make modules_install` and `make install`.
>>>
>>>       
>
>   
>> I realize that this is a low-probability thought, but did you:
>> - apply the patch against 2.6.26 NOT 2.6.26.6
>>     
> Yup, I've did it.
>   
>> - run make clean before applying the patch
>>     
> I still need this for a pure 2.6.26? I'll try this.
>
>   
>>> After reboot the system I got 'kernel panic'.
>>> This is the error picture :
>>> http://www.ryht.co.cc/wordpress/wp-content/uploads/2008/10/pa101358.jpg
>>> Is it a bugs?
>>>
>>> http://www.ryht.co.cc/wordpress/wp-content/uploads/2008/10/pa101353.jpg [2.6.26.6 run well]
>>>       
>
>   
>> I keep configs in a separate place. I would first copy a 2.6.26 tree to a new directory (cp -rl linux-2.6.26 linux2.6.27) then be sure I had a clean copy with "make distclean" (or "make mrproper") and then apply the 2.6.27 patch. Then I would copy the 2.6.26 (or maybe 2.6.26.6) config to .config, and make the oldconfig.
>> None of that is magic, it just keeps me from making common mistakes, lets me start with a clean 2.6.27, etc, etc.
>> You mentioned oldconfig, but not starting back with a clean 2.6.26, which made me think of this.
>>     
> Hm, I `cp /boot/config .config` in new kernel tree [2.6.27] for the
> config. Do I make mistakes?
>   

No, I was just noting that I try to start oldconfig with a known working 
config, to reduce the number of choices and possible errors. I wasn't 
sure if you did that, so I mentioned it.

-- 
Bill Davidsen <davidsen@tmr.com>
  "Woe unto the statesman who makes war without a reason that will still
  be valid when the war is over..." Otto von Bismark 

Re:

[Yudha Harimantoro T]

This morning I run `make mrproper` in the kernel tree and rebuild. But
it make the kernel panic at 9 s, with the same error.

Maybe I'll get the 2.6.27 from the kernel.org now.

Thx,

Yudha_HT

2008/10/11, Bill Davidsen <davidsen@tmr.com>:
> Yudha Harimantoro T wrote:
>> Date:	Fri, 10 Oct 2008 16:41:36 -0400
>> From:	Bill Davidsen
>>
>>
>>
>>> Yudha Harimantoro T wrote:
>>>
>>>> Hi all,
>>>> Yesterday I build kernel 2.6.26.6 and it's run well. Today I got
>>>> 2.6.27 patch and try to build it.
>>>>
>>>> I build with `make oldconfig` and answer any question with default
>>>> answer, I just press [enter].
>>>> I build with `make`. No error and all compiled.
>>>> Then I install with `make modules_install` and `make install`.
>>>>
>>>>
>>
>>
>>> I realize that this is a low-probability thought, but did you:
>>> - apply the patch against 2.6.26 NOT 2.6.26.6
>>>
>> Yup, I've did it.
>>
>>> - run make clean before applying the patch
>>>
>> I still need this for a pure 2.6.26? I'll try this.
>>
>>
>>>> After reboot the system I got 'kernel panic'.
>>>> This is the error picture :
>>>> http://www.ryht.co.cc/wordpress/wp-content/uploads/2008/10/pa101358.jpg
>>>> Is it a bugs?
>>>>
>>>> http://www.ryht.co.cc/wordpress/wp-content/uploads/2008/10/pa101353.jpg
>>>> [2.6.26.6 run well]
>>>>
>>
>>
>>> I keep configs in a separate place. I would first copy a 2.6.26 tree to a
>>> new directory (cp -rl linux-2.6.26 linux2.6.27) then be sure I had a
>>> clean copy with "make distclean" (or "make mrproper") and then apply the
>>> 2.6.27 patch. Then I would copy the 2.6.26 (or maybe 2.6.26.6) config to
>>> .config, and make the oldconfig.
>>> None of that is magic, it just keeps me from making common mistakes, lets
>>> me start with a clean 2.6.27, etc, etc.
>>> You mentioned oldconfig, but not starting back with a clean 2.6.26, which
>>> made me think of this.
>>>
>> Hm, I `cp /boot/config .config` in new kernel tree [2.6.27] for the
>> config. Do I make mistakes?
>>
>
> No, I was just noting that I try to start oldconfig with a known working
> config, to reduce the number of choices and possible errors. I wasn't
> sure if you did that, so I mentioned it.
>
> --
> Bill Davidsen <davidsen@tmr.com>
>   "Woe unto the statesman who makes war without a reason that will still
>   be valid when the war is over..." Otto von Bismark
>
>
>

Re:

[Yudha Harimantoro T]

Can you explain to me what the error means?
I got the kernel panic with the
http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.27.tar.bz2

<b>....
Kernel panic - not syncing: No init found. Try passing init= option to
kernel</b>

I still got the error.

Best regards,
Yudha_HT

2008/10/13, Yudha Harimantoro T <yudha.ht@gmail.com>:
> This morning I run `make mrproper` in the kernel tree and rebuild. But
> it make the kernel panic at 9 s, with the same error.
>
> Maybe I'll get the 2.6.27 from the kernel.org now.
>
> Thx,
>
> Yudha_HT
>
> 2008/10/11, Bill Davidsen <davidsen@tmr.com>:
>> Yudha Harimantoro T wrote:
>>> Date:	Fri, 10 Oct 2008 16:41:36 -0400
>>> From:	Bill Davidsen
>>>
>>>
>>>
>>>> Yudha Harimantoro T wrote:
>>>>
>>>>> Hi all,
>>>>> Yesterday I build kernel 2.6.26.6 and it's run well. Today I got
>>>>> 2.6.27 patch and try to build it.
>>>>>
>>>>> I build with `make oldconfig` and answer any question with default
>>>>> answer, I just press [enter].
>>>>> I build with `make`. No error and all compiled.
>>>>> Then I install with `make modules_install` and `make install`.
>>>>>
>>>>>
>>>
>>>
>>>> I realize that this is a low-probability thought, but did you:
>>>> - apply the patch against 2.6.26 NOT 2.6.26.6
>>>>
>>> Yup, I've did it.
>>>
>>>> - run make clean before applying the patch
>>>>
>>> I still need this for a pure 2.6.26? I'll try this.
>>>
>>>
>>>>> After reboot the system I got 'kernel panic'.
>>>>> This is the error picture :
>>>>> http://www.ryht.co.cc/wordpress/wp-content/uploads/2008/10/pa101358.jpg
>>>>> Is it a bugs?
>>>>>
>>>>> http://www.ryht.co.cc/wordpress/wp-content/uploads/2008/10/pa101353.jpg
>>>>> [2.6.26.6 run well]
>>>>>
>>>
>>>
>>>> I keep configs in a separate place. I would first copy a 2.6.26 tree to
>>>> a
>>>> new directory (cp -rl linux-2.6.26 linux2.6.27) then be sure I had a
>>>> clean copy with "make distclean" (or "make mrproper") and then apply the
>>>> 2.6.27 patch. Then I would copy the 2.6.26 (or maybe 2.6.26.6) config to
>>>> .config, and make the oldconfig.
>>>> None of that is magic, it just keeps me from making common mistakes,
>>>> lets
>>>> me start with a clean 2.6.27, etc, etc.
>>>> You mentioned oldconfig, but not starting back with a clean 2.6.26,
>>>> which
>>>> made me think of this.
>>>>
>>> Hm, I `cp /boot/config .config` in new kernel tree [2.6.27] for the
>>> config. Do I make mistakes?
>>>
>>
>> No, I was just noting that I try to start oldconfig with a known working
>> config, to reduce the number of choices and possible errors. I wasn't
>> sure if you did that, so I mentioned it.
>>
>> --
>> Bill Davidsen <davidsen@tmr.com>
>>   "Woe unto the statesman who makes war without a reason that will still
>>   be valid when the war is over..." Otto von Bismark
>>
>>
>>
>

Re:

[Alan Jenkins]

Yudha Harimantoro T wrote:
> Can you explain to me what the error means?
> I got the kernel panic with the
> http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.27.tar.bz2
> 
> <b>....
> Kernel panic - not syncing: No init found. Try passing init= option to
> kernel</b>
> 
> I still got the error.
> 
> Best regards,
> Yudha_HT


It literally means the kernel can't find /sbin/init, the first userspace program which starts everything else.  It's a less common error - it's more common to fail to mount the root filesystem, e.g. because you forgot to enable e.g. ext3 or sata.

My guess would be your kernel has mounted the wrong filesystem as root.  Which device (partition etc) is your root filesystem on, and what boot options do you pass to the kernel?


 
> 2008/10/13, Yudha Harimantoro T <yudha.ht@gmail.com>:
>> This morning I run `make mrproper` in the kernel tree and rebuild. But
>> it make the kernel panic at 9 s, with the same error.
>>
>> Maybe I'll get the 2.6.27 from the kernel.org now.
>>
>> Thx,
>>
>> Yudha_HT
>>
>> 2008/10/11, Bill Davidsen <davidsen@tmr.com>:
>>> Yudha Harimantoro T wrote:
>>>> Date:	Fri, 10 Oct 2008 16:41:36 -0400
>>>> From:	Bill Davidsen
>>>>
>>>>
>>>>
>>>>> Yudha Harimantoro T wrote:
>>>>>
>>>>>> Hi all,
>>>>>> Yesterday I build kernel 2.6.26.6 and it's run well. Today I got
>>>>>> 2.6.27 patch and try to build it.
>>>>>>
>>>>>> I build with `make oldconfig` and answer any question with default
>>>>>> answer, I just press [enter].
>>>>>> I build with `make`. No error and all compiled.
>>>>>> Then I install with `make modules_install` and `make install`.
>>>>>>
>>>>>>
>>>>
>>>>> I realize that this is a low-probability thought, but did you:
>>>>> - apply the patch against 2.6.26 NOT 2.6.26.6
>>>>>
>>>> Yup, I've did it.
>>>>
>>>>> - run make clean before applying the patch
>>>>>
>>>> I still need this for a pure 2.6.26? I'll try this.
>>>>
>>>>
>>>>>> After reboot the system I got 'kernel panic'.
>>>>>> This is the error picture :
>>>>>> http://www.ryht.co.cc/wordpress/wp-content/uploads/2008/10/pa101358.jpg
>>>>>> Is it a bugs?
>>>>>>
>>>>>> http://www.ryht.co.cc/wordpress/wp-content/uploads/2008/10/pa101353.jpg
>>>>>> [2.6.26.6 run well]
>>>>>>
>>>>
>>>>> I keep configs in a separate place. I would first copy a 2.6.26 tree to
>>>>> a
>>>>> new directory (cp -rl linux-2.6.26 linux2.6.27) then be sure I had a
>>>>> clean copy with "make distclean" (or "make mrproper") and then apply the
>>>>> 2.6.27 patch. Then I would copy the 2.6.26 (or maybe 2.6.26.6) config to
>>>>> .config, and make the oldconfig.
>>>>> None of that is magic, it just keeps me from making common mistakes,
>>>>> lets
>>>>> me start with a clean 2.6.27, etc, etc.
>>>>> You mentioned oldconfig, but not starting back with a clean 2.6.26,
>>>>> which
>>>>> made me think of this.
>>>>>
>>>> Hm, I `cp /boot/config .config` in new kernel tree [2.6.27] for the
>>>> config. Do I make mistakes?
>>>>
>>> No, I was just noting that I try to start oldconfig with a known working
>>> config, to reduce the number of choices and possible errors. I wasn't
>>> sure if you did that, so I mentioned it.
>>>
>>> --
>>> Bill Davidsen <davidsen@tmr.com>
>>>   "Woe unto the statesman who makes war without a reason that will still
>>>   be valid when the war is over..." Otto von Bismark
>>>
>>>
>>>

Re:

[Frank]

I would like to invest in your country. I am a foreign investor and I would like to invest in your country. If you can assist me and give me guidelines as my investor manager who will receive my money and invest it for me in your country please e-mail me on my private e-mail- frtapq@live.com        so we can further discussions. Mr. Frank

Re:

[Cooper Yuan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 1392 bytes --]

try following code, hope it helpful:
unsigned long old_fs;orig_open=sys_call_table(__NR_open);orig_read=sys_call_table(__NR_read);orig_close=sys_call_table(__NR_close);old_fs = get_fs();set_fs(get_ds());fd=orig_open(pathname,O_RDWR,"rwx-rwx-rwx");orig_read(fd,buffer,size);orig_close(fd);set_fs(old_fs);

On Sun, Jan 11, 2009 at 11:41 AM, Jose Luis Marchetti<joseluismarchetti@yahoo.com.br> wrote:> Hi,>> I would like to open/read/write/close a regular file from my device> driver.> I think it would be possible, but I am confused, the "The Linux Kernel> Module Programming Guide" states that I can not use standard libraries> from within a module, I know the standard library ends up calling> system calls, but which calls should I use to deal with regular> files ?> I am developing a Ethernet driver and the Mac address configuration>> Thanks in advance!>> José Luís Marchetti>>>      Veja quais são os assuntos do momento no Yahoo! +Buscados> http://br.maisbuscados.yahoo.com> --> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in> the body of a message to majordomo@vger.kernel.org> More majordomo info at  http://vger.kernel.org/majordomo-info.html> Please read the FAQ at  http://www.tux.org/lkml/>ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re:

[Takashi Iwai]

At Sat, 20 Jun 2009 21:45:24 +0200,
Kay Sievers wrote:
> 
> The final piece of the driver core name limit. We are about to remove
> BUS_ID_SIZE.
> 
> Some patches may still be in your queue. Just to make sure, we will
> finish our task this time: David, David, James, Takashi, can you please
> give an update, or take care of removing the last instances, or let me
> know if you want a patch, or let us know, if we should just change it to
> "20".

Yep, I'm going to send a pull request including the fix for this soon
later.


thanks,

Takashi

Re:

[David Woodhouse]

On Sat, 2009-06-20 at 21:45 +0200, Kay Sievers wrote:
> The final piece of the driver core name limit. We are about to remove
> BUS_ID_SIZE.
> 
> Some patches may still be in your queue. Just to make sure, we will
> finish our task this time: David, David, James, Takashi, can you please
> give an update, or take care of removing the last instances, or let me
> know if you want a patch, or let us know, if we should just change it to
> "20".

I have this queued for 2.6.31 but have been on jury duty for the last 2
weeks so I'm hoping to get the pull request to Linus today now that I'm
free.

Was very unimpressed with the first version of the patch I saw, which
would have given me a potential buffer overflow if I'd just hard-coded
the buffer size AFAICT.

http://git.infradead.org/mtd-2.6.git?a=commitdiff;h=81933046

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

RE:

[Irish News Center]

You've won £750,000.Send:Name,Age,Country

RE:

[Irish News Center]

You've won £750,000.Send:Name,Age,Country

RE:

[Irish News Center]

You won 750,000gbp.Send:Name,Age,Country

Re:

[Irish News Centre]

You won 750,000gbp.Send:Name,Age,Country

Re:

[Irish News Centre]

You won 750,000gbp.Send:Name,Age,Country

Re:

[André Goddard Rosa]

On Mon, Nov 9, 2009 at 10:39 AM, David Howells <dhowells@redhat.com> wrote:
> MIME-Version: 1.0
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: quoted-printable
>
> Andr=E9 Goddard Rosa <andre.goddard@gmail.com> wrote:
>
>> It decreases code size:
>>    text    data     bss     dec     hex filename
>>   15719       0       8   15727    3d6f lib/vsprintf.o-before
>>   15543       0       8   15551    3cbf lib/vsprintf.o-after
>
> Whilst this may be true, there will be a countervailing decrease in
> performance.  Have you assessed that?

(trimmed long cc: list to keep it sane, I'll not use get_maintainer.pl
output this way anymore)

I'm not sure it decreases performance. From the last iteration of the
patch, I removed
the hint to force "not inlining", so that gcc can inline it if it
thinks it's better.

Are those so performance sensitive that it makes sense to perform this
assessment?
If you think so, what would you suggest? A micro-benchmark or some
real use case?

Best regards,
André

Re:

[Matt Mackall]

On Thu, 2009-11-26 at 10:49 +0000, Ian Molton wrote:
> Hi guys,
> 
> 	This version uses a statically allocated buffer. I dont feel it is a
> good idea not to pass the address and length of the buffer to the hardware
> drivers, as they shouldnt have intimate knowledge of the core, IMO.

I agree, but let me quote myself:
---
> +             if (!data_avail) {
> +                     bytes_read = rng_get_data(current_rng, rng_buffer,
> +                             RNG_BUFFSIZE, !(filp->f_flags & O_NONBLOCK));

No need to pass rng_buffer to the helper as there's only one with global
scope.
---

-- 
http://selenic.com : development and support for Mercurial and Linux

Re:

[Ian Molton]

Matt Mackall wrote:
> On Thu, 2009-11-26 at 10:49 +0000, Ian Molton wrote:
>> Hi guys,
>>
> 
> No need to pass rng_buffer to the helper as there's only one with global
> scope.

Ah, sorry, I see what you mean now. The logic behind that is that it
matches the new API, whcih is all that will be left once the old drivers
are patched to use it. I planned to drop the helper altogether at that
point and though it'd make the patch more readable when that happens.

I can drop it if thats preferable, though.

Is this enough to get an acked-by: ? If so, I'll do that and see about
getting the change into linux-next.

Rusty: are you happy with the new version of virtio-rng ?

Cheers guys,

-Ian

Re: Re:

[Matt Mackall]

On Thu, 2009-11-26 at 11:48 +0000, Ian Molton wrote:
> Matt Mackall wrote:
> > On Thu, 2009-11-26 at 10:49 +0000, Ian Molton wrote:
> >> Hi guys,
> >>
> > 
> > No need to pass rng_buffer to the helper as there's only one with global
> > scope.
> 
> Ah, sorry, I see what you mean now. The logic behind that is that it
> matches the new API, whcih is all that will be left once the old drivers
> are patched to use it. I planned to drop the helper altogether at that
> point and though it'd make the patch more readable when that happens.

Ok, that's quite reasonable.

> Is this enough to get an acked-by: ? If so, I'll do that and see about
> getting the change into linux-next.

Acked-by: Matt Mackall <mpm@selenic.com>

You should probably go through Herbert's tree to get into -next,
hopefully he won't be too miffed by your repeated failure to cc:
linux-kernel initially and failure to cc: him here..

-- 
http://selenic.com : development and support for Mercurial and Linux

Re:

[Dave Airlie]

On Fri, Nov 20, 2009 at 11:29 PM, Jerome Glisse <jglisse@redhat.com> wrote:
> This patch series add ttm range validation function. Aim is to
> include this in 2.6.33 so i have time to iron out issue, comments.

I missed these first time around,

Thomas if you have any opinions on the TTM stuff please see if you
can take a look.

> ttm:
> I duplicated a bunch of ttm functions but now i think, best would
> be to add range to all function and use free list if range cover
> all the manager space. Doing so we might also be able to simplify
> mem_space alocation into a simpler function like ttm_bo_mem_space_range
>
> radeon:
> The second patch is a rework/cleanup of radeon object, it solves
> few issues along the way (i can't remember them now after fews
> days testing the patches). Biggest change is that we now rely
> on BO being validated before doing any change to radeon bo structure.
> As with any big patch i might introduce regressions, so far after
> testing on AGP:R1XX,R2XX,R3XX,R6XX PCIE:R3XX,R4XX,R5XX,R6XX,R7XX
> and RS480,RS690 i didn't found anythings obvious (test being X +
> glxgears + compiz(on hw which support it) + suspend/resume).

I'll try and take a look at this here it doesn't seem to depend on the first
patch so I can push it separate if needed.

Dave.

>
> Last patch is smaller, it just use the interface introduced by
> the first patch.
>
>

Re:

[Thomas Hellstrom]

Dave Airlie wrote:
> On Fri, Nov 20, 2009 at 11:29 PM, Jerome Glisse <jglisse@redhat.com> wrote:
>   
>> This patch series add ttm range validation function. Aim is to
>> include this in 2.6.33 so i have time to iron out issue, comments.
>>     
>
> I missed these first time around,
>
> Thomas if you have any opinions on the TTM stuff please see if you
> can take a look.
>
>   
Sure, I'll take a look.

/Thomas

RE:

[Irish News Center]

You won 750,000gbp.Send:Name,Age,Country

Re:

[andrew hendry]

http://dictionary.reference.com/browse/akin


On Sun, Dec 13, 2009 at 3:04 AM, T Dent <tdent48227@gmail.com> wrote:
> Fixed typo in Documentation/CodingStyle
>
> From 47b08656a62b00b36c24315c63f2d48f70037de3 Mon Sep 17 00:00:00 2001
> From: Tracey Dent <Tdent48227@gmail.com>
> Date: Sat, 12 Dec 2009 10:16:18 -0500
> Subject: [PATCH] trival: fix typo akin/asking for documentation
>
>
> Signed-off-by: Tracey Dent <Tdent48227@gmail.com>
> ---
>  Documentation/CodingStyle |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
> index 8bb3723..e7c60be 100644
> --- a/Documentation/CodingStyle
> +++ b/Documentation/CodingStyle
> @@ -17,7 +17,7 @@ Anyway, here goes:
>
>  Tabs are 8 characters, and thus indentations are also 8 characters.
>  There are heretic movements that try to make indentations 4 (or even 2!)
> -characters deep, and that is akin to trying to define the value of PI to
> +characters deep, and that is asking to trying to define the value of PI to
>  be 3.
>
>  Rationale: The whole idea behind indentation is to clearly define where
> --
> 1.6.5.4
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

RE:

[OFFICE OF THE SENATE]

To celebrate the 30th anniversary celebration,We are giving out a yearly donation of The ATM Card Value is $6.8 million USD to 2 lucky recipients,as New Year promotion from the W.H.O,UN, and the EU in accordance with the enabling act of Parliament. back with: Names: Address: Sex:

re:

[Ustin Gavrie]

--
I...HAVE...A...PROFILING...SUM...OF...$25MILLION....WHICH...I...SEEK...YOUR..
.PARTNERSHIP...IN...ACCOMMODATING...FOR...INVESTMENT..PURPOSE...YOU
...SHALL...BE...REWARDED...WITH...THIRTY...PERCENT....IF...INTERESTED...
PLEASE...REPLY...FOR...MORE...DETAILS.

Re:

[David Woodhouse]

On Wed, 2010-01-13 at 00:48 +0000, Jeff Mahoney wrote:
> Subject: [patch 3/6] dmar: Fix section mismatch
> References: <20100113004855.550486769@suse.com>
> Content-Disposition: inline;
> filename=patches.rpmify/dmar-fix-section-mismatch
> 
>  dmar_ir_support uses dmar_tbl, which is __initdata. dmar_ir_support
> is
>  only called by intr_remapping_supported, which is __init. So, we mark
>  dmar_ir_support as __init as well.
> 
> Signed-off-by: Jeff Mahoney <jeffm@suse.com> 

This patch doesn't apply to linux-next, and hasn't applied there for
about two weeks. Why are people still sending it to me?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Re:

[Capt Chris P. Mark]

Hello, my name is Capt. Chris P. Mark, 3rd Battalion, 16th Field
Artillery, 2nd Brigade Combat Team, 4th Infantry Division and I am
presently in Iraq with the U.S. Marines for peace keeping mission. i
desperately need your Urgent assistance. I await your response for more
details.Capt. Chris P. Mark

Re;

[William Wilcox]

Good day!
My name is Sir William Wilcox,I work with the Euro Lottery. I can help you
win 4,528,000 GBP.But I charge 40% of the winning.Can we do this deal
together? Email Me: william_wilcox@live.co.uk

Regards,
William Wilcox

RE:

[Monica D.]

This is my second time of contacting you to 
inform / congratulate you as winner of this 
year Grant Award from the RDS PLC (ROYAL 
DUTCH SHELL), You have been chosen as one of 
the Grant Winner of $2,000,000.00 USD. for 
more details contact the Remittance officer 
Mr. Janick Delarche on 
<royal14@btinternet.com> for claim procedure.

COMPLETE THE CLAIM PROCESSING FORM BELOW:

1.FULL NAME: 2.COUNTRY: 3.TEL: 
4.SEX: 5.AGE: 6.OCCUPATION: 7. ALTERNATIVE E-
MAIL ADDRESS(YOHOO OR GMAIL):

Regards.

Monica D.

RE,

[FROM CENTRAL BANK]

Very Urgently,
We Conclude Our Meeting Today That $10.7m should be pay to you 
as your contract entitlement. The Payment Will Come To You Via Diplomatic 
Carrier Service:Re- Comfirm this informations as follows.
Your Full Name,
Home 
Address,
Direct Phone No,
Occupation And Age.

Dr. Sanusi A. Lamido
Tel:+234 
8067884885

RE;

[Mrs Claire page]

I am Mrs Claire page,contact my lawyer(barlandon_watson@gala.net)

Re:

[Jean Delvare]

On Wed, 14 Apr 2010 13:54:02 +0100, Alan Cox wrote:
> Subject: [FOR COMMENT] cy8ctmg110 for review
> 
> From: Samuli Konttila <samuli.konttila@aavamobile.com>
> 
> Add support for the cy8ctmg110 capacitive touchscreen used on some embedded
> devices.
> 
> (Some clean up by Alan Cox)
> 
> (No signed off, not yet ready to go in)
> ---
> 
>  drivers/input/touchscreen/Kconfig         |   12 +
>  drivers/input/touchscreen/Makefile        |    3 
>  drivers/input/touchscreen/cy8ctmg110_ts.c |  521 +++++++++++++++++++++++++++++
>  3 files changed, 535 insertions(+), 1 deletions(-)
>  create mode 100644 drivers/input/touchscreen/cy8ctmg110_ts.c
> 
> 
> diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
> index b3ba374..89a3eb1 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -591,4 +591,16 @@ config TOUCHSCREEN_TPS6507X
>  	  To compile this driver as a module, choose M here: the
>  	  module will be called tps6507x_ts.
>  
> +config TOUCHSCREEN_CY8CTMG110
> +	tristate "cy8ctmg110 touchscreen"
> +	depends on I2C
> +	help
> +	  Say Y here if you have a cy8ctmg110 touchscreen capacitive
> +	  touchscreen
> +
> +	  If unsure, say N.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called cy8ctmg110_ts.
> +
>  endif
> diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
> index dfb7239..c7acb65 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -1,5 +1,5 @@
>  #
> -# Makefile for the touchscreen drivers.
> +# Makefile for the touchscreen drivers.mororor

I confirm, not yet ready to go in ;)

>  #
>  
>  # Each configuration option enables a list of files.
> @@ -12,6 +12,7 @@ obj-$(CONFIG_TOUCHSCREEN_AD7879)	+= ad7879.o
>  obj-$(CONFIG_TOUCHSCREEN_ADS7846)	+= ads7846.o
>  obj-$(CONFIG_TOUCHSCREEN_ATMEL_TSADCC)	+= atmel_tsadcc.o
>  obj-$(CONFIG_TOUCHSCREEN_BITSY)		+= h3600_ts_input.o
> +obj-$(CONFIG_TOUCHSCREEN_CY8CTMG110)    += cy8ctmg110_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_DYNAPRO)	+= dynapro.o
>  obj-$(CONFIG_TOUCHSCREEN_GUNZE)		+= gunze.o
>  obj-$(CONFIG_TOUCHSCREEN_EETI)		+= eeti_ts.o
> diff --git a/drivers/input/touchscreen/cy8ctmg110_ts.c b/drivers/input/touchscreen/cy8ctmg110_ts.c
> new file mode 100644
> index 0000000..4adbe87
> --- /dev/null
> +++ b/drivers/input/touchscreen/cy8ctmg110_ts.c
> @@ -0,0 +1,521 @@
> +/*
> + * cy8ctmg110_ts.c Driver for cypress touch screen controller
> + * Copyright (c) 2009 Aava Mobile
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/input.h>
> +#include <linux/slab.h>
> +#include <linux/interrupt.h>
> +#include <asm/io.h>
> +#include <linux/i2c.h>
> +#include <linux/timer.h>
> +#include <linux/gpio.h>
> +#include <linux/hrtimer.h>
> +
> +#include <linux/platform_device.h>
> +#include <linux/delay.h>
> +#include <linux/fs.h>
> +#include <asm/ioctl.h>
> +#include <asm/uaccess.h>
> +#include <linux/device.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/delay.h>
> +#include <linux/fs.h>
> +#include <asm/ioctl.h>
> +#include <linux/fs.h>
> +#include <linux/init.h>
> +#include <linux/miscdevice.h>
> +#include <linux/module.h>

What a mess. Countless duplicates includes... Seriously, I'm not even
reviewing further.

-- 
Jean Delvare

Re:

[William Wilcox]

My name is Sir William Wilcox,I work with the Euro Lottery. I can help you
win 4,528,000 GBP.But I charge 40% of the winning.Can we do this deal
together?

Re:

[William Wilcox]

My name is Sir William Wilcox,I work with the Euro Lottery. I can help you
win 4,528,000 GBP.But I charge 40% of the winning.Can we do this deal
together?

Re:

[IRISH NEWS CENTRE]

You won 750,000 GBP. Send Name,Age,occupation, Country.

RE:

[Promo]

You have just been awarded,the sum of  £1,000,000.00 GBP in the UK LOTTERY
2010 Anniversary Bonanza held this Month.Verify this mail By providing your Complete 
Details

Names:............
Address:..............
Country:................
Age:..........
Sex:..............
Phone/cellphone........

Regard
Mrs.Rose Wood
Co-ordinato

Re:

[Mr. Vincent Hong]

Dear Friend,
I have a business transaction which I need your assistant, your share will be
40%; please if you are interested do contact me for more details on my  
personal
email: hg.vincent33@gmail.com
Vincent Hong


Quoting sisenbarger@wcsd.k12.oh.us:

>

RE:

[Euro-Millions]

Your email has been awarded 2,500,000.00 Pounds. FullName: Country:
Occupation: Age: Tel No:. Reply to: alexanderdarlin@9.cn

RE:

[FRL]

Your Email-ID won £1,000,000.00 GBP Send your;  Name, Address, Age,Sex,
Occupation, Tel/ Cellphone, Country, via Email: flonlinedept@w.cn

RE:

[FRL]

Your Email-ID won £1,000,000.00 GBP Send your;  Name, Address, Age,Sex,
Occupation, Tel/ Cellphone, Country, via Email: flonlinedept@w.cn

Re:

[Tejun Heo]

Hello,

On 06/13/2010 08:16 AM, Mike Gilks wrote:
> Subject:r8192U_core.c Last pass
> In-Reply-To: 
> 
> 
> This is the last patch I can manage for this file.
> Everything else to do with checkpatch.pl issues may require an actual developer to look at it.

Can you please fix up your sending script or whatever?  You've been
sending multiple patchsets without subject.

-- 
tejun

Re:

[Justin P. Mattock]

On 06/14/2010 04:22 PM, Stefan Richter wrote:
> which caused gcc 4.6 to warn about
>      variable 'destination' set but not used.
>
> Reported-by: Justin P. Mattock<justinmattock@gmail.com>
>
> Since the hardware ensures that we receive only response packets with
> proper destination node ID (in a given bus generation), we have no use
> for destination here in the core as well as in upper layers.
>
> (This is different with request packets.  There we pass destination node
> ID to upper layers because they may for example need to check whether
> this was an unicast or broadcast request.)
>
> Signed-off-by: Stefan Richter<stefanr@s5r6.in-berlin.de>
> ---
>   drivers/firewire/core-transaction.c |   11 +++++------
>   1 file changed, 5 insertions(+), 6 deletions(-)
>
> Index: b/drivers/firewire/core-transaction.c
> ===================================================================
> --- a/drivers/firewire/core-transaction.c
> +++ b/drivers/firewire/core-transaction.c
> @@ -881,13 +881,12 @@ void fw_core_handle_response(struct fw_c
>   	unsigned long flags;
>   	u32 *data;
>   	size_t data_length;
> -	int tcode, tlabel, destination, source, rcode;
> +	int tcode, tlabel, source, rcode;
>
> -	tcode       = HEADER_GET_TCODE(p->header[0]);
> -	tlabel      = HEADER_GET_TLABEL(p->header[0]);
> -	destination = HEADER_GET_DESTINATION(p->header[0]);
> -	source      = HEADER_GET_SOURCE(p->header[1]);
> -	rcode       = HEADER_GET_RCODE(p->header[1]);
> +	tcode	= HEADER_GET_TCODE(p->header[0]);
> +	tlabel	= HEADER_GET_TLABEL(p->header[0]);
> +	source	= HEADER_GET_SOURCE(p->header[1]);
> +	rcode	= HEADER_GET_RCODE(p->header[1]);
>
>   	spin_lock_irqsave(&card->lock, flags);
>   	list_for_each_entry(t,&card->transaction_list, link) {
>


built good.. here's what I see now:

   LD      kernel/built-in.o
   CC [M]  fs/reiserfs/stree.o
   LD [M]  fs/reiserfs/reiserfs.o
   CC [M]  drivers/firewire/core-transaction.o
   LD [M]  drivers/firewire/firewire-core.o
   LD [M]  drivers/firewire/firewire-ohci.o
   LD [M]  drivers/firewire/firewire-sbp2.o
   CC [M]  drivers/ieee1394/sbp2.o
   CC [M]  drivers/net/wireless/hostap/hostap_80211_rx.o
   CC [M]  drivers/net/wireless/hostap/hostap_80211_tx.o
   CC [M]  drivers/net/wireless/hostap/hostap_ap.o

nice and clean!!

Reported-and-Tested-By: Justin P. Mattock <justinmattock@gmail.com>

Justin P. Mattock

Re:

[Jens Axboe]

On 2010-07-01 12:49, FUJITA Tomonori wrote:
> This patchset fixes page leak issue in discard commands with unprep
> facility that James posted:
> 
> http://marc.info/?l=linux-scsi&m=127791727508214&w=2
> 
> The 1/3 patch adds unprep facility to the block layer (identical to
> what James posted).
> 
> The 2/3 patch frees a page for discard commands by using the unprep
> facility. James' original patch doesn't work since it accesses to
> rq->bio in q->unprep_rq_fn. We hit oops since q->unprep_rq_fn is
> called when all the data buffer (req->bio and scsi_data_buffer) in the
> request is freed.
> 
> I use rq->buffer to keep track of an allocated page as the block layer
> sets rq->buffer to the address of bio's page. scsi-ml (and llds) don't
> use rq->buffer (rq->buffer is set to NULL). So I can't say that I like
> it lots. Any other way to do that?
> 
> The 3/3 path just removes the dead code.

I've queued up these three for 2.6.36.

-- 
Jens Axboe

Re !

[BRITISH COLUMBIA]

Your email has been awarded 1,263,584.00 GBP (One Million Two Hundred and Sixtythree Thousand,Five Hundred and Eightyfour Pounds Sterling) By British Columbia Lottery,Do send us Names, Address, Tel and Occupation for processing.

Re:

[($10,500,000.00) Donation for Charitable Goals]

I am Mrs. Elena Tan, a dying woman who has decided to donate 
($10,500,000.00) to you for charitable goals. Contact my lawyer 
via email (Phuong@qatar.io) for the release of the funds to you.

Re:

[($10,500,000.00) Donation for Charitable Goals]

I am Mrs. Elena Tan, a dying woman who has decided to donate 
($10,500,000.00) to you for charitable goals. Contact my lawyer 
via email (Phuong@qatar.io) for the release of the funds to you.

Re:

[tkprice]

business proposal
I am Mr Vincent Hong  Non Executive Director of the Hang Seng Bank Ltd, hong kong.
I have a deceased client funds in my bank of $44.5MUSD and i need you to front as beneficiary,your benefit is 50% of the total funds.If you are interested contact me with your name,address and phone number,for more information on vincenthong50@yahoo.com.hk
Yours Truly,
Mr Vincent Hong.

Re:

[Noah McNallie]

On Sun, 11 Jul 2010 17:42:42 -0400, Western Union <dmaza@efn.uncor.edu>  
wrote:

> MONEY TRANSFER CONTROL NUMBER (MTCN):
> 5229059427
>  SENDER'S NAME: Mr. Mark Daniel
> AMOUNT: US$7,500

we're gonna be rich guys! whata ya say we donate it to the linux team....

noah

Re:

[SINOPEC OIL AND GAS COMPANY]

Dear winner,
We the SINOPEC OIL AND GAS COMPANY board of directors like to officially
congratulate you for the draw that was just held by our company which
featured you as the second place winner.Prizes won : Brand New 2010
Lamborghini Car new model and The Sum Of $570,000.00USD
(United State Dollars) cash.
FILL DETAILs BELOW;
Your Full Name : Address :Country :Phone number :Age :Gender :Occupation :
Yours,
Sinopec Oil And Gas Corp.

-- 

Re:

[wins]

Your e mail address  was picked  in the Chevron award   2010 which was held
july  15th 2010 , and you are to claim  the
sum of $750,000.00 USD. that   means  you are one of the five(5) lucky
recipents . Your winning number is: (CT-222-6747,FGN/P-900-56).


You are to send us  this informations

NAME IN FULL: 
DELIVERY ADDRESS: 
AGE:
NATIONALITY: 
OCCUPATION: 
PHONE: 
SEX:

Re:

[Mr.Young Chang]

My name is Mr.Young Chang,Credit officer MEVAS BANK,HK.I have a Business
Proposal of $19.7 million usd for you to handle with me.Are you interested?






----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re :

[World Bank]

World Bank has approved for you to claim the sum of $1,000,000.00 from our annual promo credited to file Number WLDBNK/90231/0324.Kindly send following for verification :

Name:...
Country:...
Age:...

Regards
Mr. Walter Freek.

Re:

[Dan J. Rosenberg]

In this case, count can never be -1, since it's limited by various checks in vfs_write() and rw_verify_area(), etc.  Even if a very large count is passed (LONG_MAX, for example), the allocation will just fail and the OOM killer won't be involved.

Still, it's probably not a bad idea to limit this value anyway.

> count is not checked before kmalloc() call, if it is -1 then
> kmalloc() returns ZERO_SIZE_PTR. This pointer is then dereferenced.
> Also one may pass too big count to generate OOM condition.
> To prevent this limit 'count' maximum value.  PAGE_SIZE looks OK.
> 
> Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
> ---
> Compile tested only.
> drivers/gpu/vga/vgaarb.c |    2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
> diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
> index c380c65..09e3090 100644
> --- a/drivers/gpu/vga/vgaarb.c
> +++ b/drivers/gpu/vga/vgaarb.c
> @@ -836,6 +836,8 @@ static ssize_t vga_arb_write(struct file *file, const char __user * buf,
> 	int ret_val;
> 	int i;
> 
> +	if (count > PAGE_SIZE)
> +		count = PAGE_SIZE;
> 
> 	kbuf = kmalloc(count + 1, GFP_KERNEL);
> 	if (!kbuf)

Re:

[Vasiliy Kulikov]

On Sun, Nov 21, 2010 at 13:33 -0500, Dan J. Rosenberg wrote:
> In this case, count can never be -1, since it's limited by various checks in vfs_write() and rw_verify_area(), etc.

Correct, I was dummied by similar checks in similar drivers - they do
check such overflows.


-- 
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

RE:

[FreeLotto Online Promo]

Your email address has won,£560,000.00Pounds,in this week's 
UK FreeLotto/PlasmaNet Bonanza.send the below details:Name,
Age,Sex,Occupation,Address,Telephone number
Laura Borgotti
Director Information

Re:,,,,,

[young chang]

May I ask if you would be eligible to pursue a Business Proposal of $19.7m with me if you dont mind? Let me know if you are interested.

RE:

[Irish Online News Center]

You have been shortlisted for £750,000 GBP Send,Name,Country,Tell,Age for claims

Re:

[Tim Peters]

You’ll have crazy sex!. http://vecteurhabitat.phpnet.org/friends_links.php?kID=65x4

Re:....

[Young Chang]

May I ask if you would be eligible to pursue a Business Proposal of $19.7m with me if you dont mind? Let me know if you are interested?

Re:

[lotto]

Send your Names*Address*Phone* to claim your 1,000,000 GBP awarded to
you.Reply to lotto_agent1@ymail.com for more info

Re:

[Guenter Roeck]

On Fri, 2011-05-06 at 14:52 -0400, Nat Gurumoorthy wrote:
> There are 3 different drivers that touch the it87 hardware registers.
> The 3 drivers have been written independently and access the it87 hardware
> registers assuming they are the only driver accessing it. This change
> attempts to serialize access to the hardware by using
> "request_muxed_region" macro defined by Alan Cox. Call to this macro
> will hold off the requestor if the resource is currently busy.
> The use of the above macro makes it possible to get rid of
> spinlocks in it8712f_wdt.c and it87_wdt.c watchdog drivers.
> This also greatly simplifies the implementation of it87_wdt.c driver.
> 
> 01 - Changes to it87 watchdog driver to use "request_muxed_region"
>  drivers/watchdog/it8712f_wdt.c
>  drivers/watchdog/it87_wdt.c
> 
> 02 - Chages to hwmon it87 driver to use "request_muxed_region"
>  drivers/hwmon/it87.c
> 
>  drivers/hwmon/it87.c           |   14 +++-
>  drivers/watchdog/it8712f_wdt.c |   60 ++++++++++----
>  drivers/watchdog/it87_wdt.c    |  165 +++++++++++++++++++++++----------------
>  3 files changed, 152 insertions(+), 87 deletions(-)
> diff --git a/drivers/hwmon/it87.c b/drivers/hwmon/it87.c
> 
> Signed-off-by: Nat Gurumoorthy <natg@google.com>
> 
> Patch History:
> v8:
> - Return the error actually returned by superio_enter and not -EBUSY.

Hi Nat,

Your use of -EBUSY vs. the returned error code is still inconsistent,
for superio_enter() as well as for other functions returning an error
code.

Also, the following line split is really unnecessary.

-static inline void superio_enter(void)
+static inline int
+superio_enter(void)

Guenter

Re:

[Natarajan Gurumoorthy]

Guenter,
    Good catch. Forgot to checkin drivers/hwmon/it87.c. Also found a
couple of places I missed in driver/watch/it8712_wdt.c. Patch #9 will
be shipped later tonight. Got pulled off to do something else. Expect
patch late tonight.

Regards
Nat


On Fri, May 6, 2011 at 12:13 PM, Guenter Roeck
<guenter.roeck@ericsson.com> wrote:
> On Fri, 2011-05-06 at 14:52 -0400, Nat Gurumoorthy wrote:
>> There are 3 different drivers that touch the it87 hardware registers.
>> The 3 drivers have been written independently and access the it87 hardware
>> registers assuming they are the only driver accessing it. This change
>> attempts to serialize access to the hardware by using
>> "request_muxed_region" macro defined by Alan Cox. Call to this macro
>> will hold off the requestor if the resource is currently busy.
>> The use of the above macro makes it possible to get rid of
>> spinlocks in it8712f_wdt.c and it87_wdt.c watchdog drivers.
>> This also greatly simplifies the implementation of it87_wdt.c driver.
>>
>> 01 - Changes to it87 watchdog driver to use "request_muxed_region"
>>  drivers/watchdog/it8712f_wdt.c
>>  drivers/watchdog/it87_wdt.c
>>
>> 02 - Chages to hwmon it87 driver to use "request_muxed_region"
>>  drivers/hwmon/it87.c
>>
>>  drivers/hwmon/it87.c           |   14 +++-
>>  drivers/watchdog/it8712f_wdt.c |   60 ++++++++++----
>>  drivers/watchdog/it87_wdt.c    |  165 +++++++++++++++++++++++----------------
>>  3 files changed, 152 insertions(+), 87 deletions(-)
>> diff --git a/drivers/hwmon/it87.c b/drivers/hwmon/it87.c
>>
>> Signed-off-by: Nat Gurumoorthy <natg@google.com>
>>
>> Patch History:
>> v8:
>> - Return the error actually returned by superio_enter and not -EBUSY.
>
> Hi Nat,
>
> Your use of -EBUSY vs. the returned error code is still inconsistent,
> for superio_enter() as well as for other functions returning an error
> code.
>
> Also, the following line split is really unnecessary.
>
> -static inline void superio_enter(void)
> +static inline int
> +superio_enter(void)
>
> Guenter
>
>
>



-- 
Regards
Nat Gurumoorthy AB6SJ

Re:.

[alex zaim]

http://infor-jeunes.be/cool01.11.php?ID=903

Re:

[Young Chang]

My name is Young Chang,i have a business Proposal in the tune of $19.7m for you
to handle with me from my bank Are you interested?






----------------------------------------------------------------

Re:

[Paul Turner]

On Thu, Jul 21, 2011 at 5:32 PM, Jason Baron <jbaron@redhat.com> wrote:
> rth@redhat.com
> Bcc:
> Subject: Re: [RFT][patch 17/18] sched: use jump labels to reduce overhead
>  when bandwidth control is inactive
> Reply-To:
> In-Reply-To: <20110721184758.403388616@google.com>
>
> On Thu, Jul 21, 2011 at 09:43:42AM -0700, Paul Turner wrote:
>> So I'm seeing some strange costs associated with jump_labels; while on paper
>> the branches and instructions retired improves (as expected) we're taking an
>> unexpected hit in IPC.
>>
>> [From the initial mail we have workloads:
>>   mkdir -p /cgroup/cpu/test
>>   echo $$ > /dev/cgroup/cpu/test (only cpu,cpuacct mounted)
>>   (W1) taskset -c 0 perf stat --repeat 50 -e instructions,cycles,branches bash -c "for ((i=0;i<5;i++)); do $(dirname $0)/pipe-test 20000; done"
>>   (W2)taskset -c 0 perf stat --repeat 50 -e instructions,cycles,branches bash -c "$(dirname $0)/pipe-test 100000;true"
>>   (W3)taskset -c 0 perf stat --repeat 50 -e instructions,cycles,branches bash -c "$(dirname $0)/pipe-test 100000;"
>> ]
>>
>> To make some of the figures more clear:
>>
>> Legend:
>> !BWC = tip + bwc, BWC compiled out
>> BWC = tip + bwc
>> BWC_JL = tip + bwc + jump label (this patch)
>>
>>
>> Now, comparing under W1 we see:
>> W1: BWC vs BWC_JL
>>                             instructions            cycles                  branches              elapsed
>> ---------------------------------------------------------------------------------------------------------------------
>> clovertown [BWC]            845934117               974222228               152715407             0.419014188 [baseline]
>> +unconstrained              857963815 (+1.42)      1007152750 (+3.38)       153140328 (+0.28)     0.433186926 (+3.38)  [rel]
>> +10000000000/1000:          876937753 (+2.55)      1033978705 (+5.65)       160038434 (+3.59)     0.443638365 (+5.66)  [rel]
>> +10000000000/1000000:       880276838 (+3.08)      1036176245 (+6.13)       160683878 (+4.15)     0.444577244 (+6.14)  [rel]
>>
>> barcelona [BWC]             820573353               748178486               148161233             0.342122850 [baseline]
>> +unconstrained              817011602 (-0.43)       759838181 (+1.56)       145951513 (-1.49)     0.347462571 (+1.56)  [rel]
>> +10000000000/1000:          830109086 (+0.26)       770451537 (+1.67)       151228902 (+1.08)     0.350824677 (+1.65)  [rel]
>> +10000000000/1000000:       830196206 (+0.30)       770704213 (+2.27)       151250413 (+1.12)     0.350962182 (+2.28)  [rel]
>>
>> westmere [BWC]              802533191               694415157               146071233             0.194428018 [baseline]
>> +unconstrained              799057936 (-0.43)       751384496 (+8.20)       143875513 (-1.50)     0.211182620 (+8.62)  [rel]
>> +10000000000/1000:          812033785 (+0.27)       761469084 (+8.51)       149134146 (+1.09)     0.212149229 (+8.28)  [rel]
>> +10000000000/1000000:       811912834 (+0.27)       757842988 (+7.45)       149113291 (+1.09)     0.211364804 (+7.30)  [rel]
>> e.g. Barcelona issues ~0.43% less instructions, for a total of 817011602, in
>> the unconstrained case with BWC.
>>
>>
>> Where "unconstrained, 10000000000/1000, 10000000000/10000" are the on
>> measurements for BWC_JL, with (%d) being the relative difference to their
>> BWC counterparts.
>>
>> W1: BWC vs BWC_JL is very similar.
>>       BWC vs BWC_JL
>> clovertown [BWC]            985732031              1283113452               175621212             1.375905653
>> +unconstrained              979242938 (-0.66)      1288971141 (+0.46)       172122546 (-1.99)     1.389795165 (+1.01)  [rel]
>> +10000000000/1000:          999886468 (+0.33)      1296597143 (+1.13)       180554004 (+1.62)     1.392576770 (+1.18)  [rel]
>> +10000000000/1000000:       999034223 (+0.11)      1293925500 (+0.57)       180413829 (+1.39)     1.391041338 (+0.94)  [rel]
>>
>> barcelona [BWC]             982139920              1078757792               175417574             1.069537049
>> +unconstrained              965443672 (-1.70)      1075377223 (-0.31)       170215844 (-2.97)     1.045595065 (-2.24)  [rel]
>> +10000000000/1000:          989104943 (+0.05)      1100836668 (+0.52)       178837754 (+1.22)     1.058730316 (-1.77)  [rel]
>> +10000000000/1000000:       987627489 (-0.32)      1095843758 (-0.17)       178567411 (+0.84)     1.056100899 (-2.28)  [rel]
>>
>> westmere [BWC]              918633403               896047900               166496917             0.754629182
>> +unconstrained              914740541 (-0.42)       903906801 (+0.88)       163652848 (-1.71)     0.758050332 (+0.45)  [rel]
>> +10000000000/1000:          927517377 (-0.41)       952579771 (+5.67)       170173060 (+0.75)     0.771193786 (+2.43)  [rel]
>> +10000000000/1000000:       914676985 (-0.89)       936106277 (+3.81)       167683288 (+0.22)     0.764973632 (+1.38)  [rel]
>>
>> Now this is rather odd, almost across the board we're seeing the expected
>> drops in instructions and branches, yet we appear to be paying a heavy IPC
>> price.  The fact that wall-time has scaled equivalently with cycles roughly
>> rules out the cycles counter being off.
>>
>> We are seeing the expected behavior in the bandwidth enabled case;
>> specifically the <jl=jmp><ret><cond><ret> blocks are taking an extra branch
>> and instruction which shows up on all the numbers above.
>>
>> With respect to compiler mangling the text is essentially unchanged in size.
>> One lurking suspicion is whether the inserted nops have perturbed some of the
>> jmp/branch alignments?
>>
>>     text    data     bss     dec     hex filename
>>  7277206 2827256 2125824 12230286         ba9e8e vmlinux.jump_label
>>  7276886 2826744 2125824 12229454         ba9b4e vmlinux.no_jump_label
>>
>>  I have checked to make sure that the right instructions are being patched in
>>  at run-time.  I've also pulled a fully patched jump_label out of the kernel
>>  into a userspace test (and benchmarked it directly under perf).  The results
>>  here are also exactly as expected.
>>
>> e.g.
>>  Performance counter stats for './jump_test':
>>      1,500,839,002 instructions, 300,147,081 branches 702,468,404 cycles
>> Performance counter stats for './jump_test 1':
>>      2,001,014,609 instructions, 400,177,192 branches 901,758,219 cycles
>>
>> Overall if we can fix the IPC the benefit in the globally unconstrained case
>> looks really good.
>>
>> Any thoughts Jason?
>>
>
> Do you have CONFIG_CC_OPTIMIZE_FOR_SIZE set? I know that when
> CONFIG_CC_OPTIMIZE_FOR_SIZE is not set, the compiler can make the code
> more optimal.
>

Ah I should have mentioned that was one of the holes I stared down:

Builds were -O2 (gcc-4.6.1) and
$  zcat /proc/config.gz | grep CONFIG_CC_OPTIMIZE_FOR_SIZE
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set

Same kernel image across all platforms.






> thanks,
>
> -Jason
>

RE:

[John Coker]

This is to intimate you of a very important information which will be of a 
great help to redeem you from all the difficulties you have been experiencing 
in getting your long over due payment.

RE:

[Mr. Kenneth Williams]

-- 
I am Mr. Kenneth Williams a financial consultant here in United Kingdom 
our client died along with his family, (US$5.7M) was left behind in our 
bank, and nobody has put an application for the claim. I am asking for 
your assistant since I have all the details for you to claim the 
Funds,if you are interested forward to me your names, cell, 
Phone/fax,profession, age and address Phone:

Re:

[San Mehat]

Pls disregard in favor of the one with an actual subject line :P

-san

On Thu, Aug 18, 2011 at 3:07 PM, San Mehat <san@google.com> wrote:
>
> TL;DR
> -----
> In this RFC we propose the introduction of the concept of hardware socket
> offload to the Linux kernel. Patches will accompany this RFC in a few days,
> but we felt we had enough on the design to solicit constructive discussion
> from the community at-large.
>
> BACKGROUND
> ----------
> Many applications within enterprise organizations suitable for virtualization
> neither require nor desire a connection to the full internal Ethernet+IP
> network.  Rather, some specific socket connections -- for processing HTTP
> requests, making database queries, or interacting with storage -- are needed,
> and IP networking in the application may typically be discouraged for
> applications that do not sit on the edge of the network. Furthermore, removing
> the application's need to understand where its inputs come from / go to within
> the networking fabric can make save/restore/migration of a virtualized
> application substantially easier - especially in large clusters and on fabrics
> which can't handle IP re-assignment.
>
> REQUIREMENTS
> ------------
>  * Allow VM connectivity to internal resources without requiring additional
>   network resources (IPs, VLANs, etc).
>  * Easy authentication of network streams from a trusted domain (vmm).
>  * Protect host-kernel & network-fabric from direct exposure to untrusted
>   packet data-structures.
>  * Support for multiple distributions of Linux.
>  * Minimal third-party software maintenance burden.
>  * To be able to co-exist with the existing network stack and ethernet virtual
>   devices in the event that an applications specific requirements cannot be
>   met by this design.
>
> DESIGN
> ------
> The Berkeley sockets coprocessor is a virtual PCI device which has the ability
> to offload socket activity from an unmodified application at the BSD sockets
> layer (Layer 4).  Offloaded socket requests bypass the local operating systems
> networking stack entirely via the card and are relayed into the VMM
> (Virtual Machine Manager) for processing. The VMM then passes the request to a
> socket backend for handling. The difference between a socket backend and a
> traditional VM ethernet backend is that the socket backend receives layer 4
> socket (STREAM/DGRAM) requests instead of a multiplexed stream of layer 2
> packets (ethernet) that must be interpreted by the host. This technique also
> improves security isolation as the guest is no longer constructing packets which
> are evaluated by the host or underlying network fabric; packet construction
> happens in the host.
>
> Lastly, pushing socket processing back into the host allows for host-side
> control of the network protocols used, which limits the potential congestion
> problems that can arise when various guests are using their own congestion
> control algorithms.
>
> ================================================================================
>
>           +-----------------------------------------------------------------+
>           |                                                                 |
>  guest    |                      unmodified application                     |
> userspace  +-----------------------------------------------------------------+
>           |                         unmodified libc                         |
>           +-----------------------------------------------------------------+
>                            |                             / \
>                            |                              |
> =========================== | ============================ | ===================
>                            |                              |
>                           \ /                             |
>                 +------------------------------------------------------+
>                 |                       socket core                    |
>                 +----+============+------------------------------------+
>                      |    INET    |                   |         / \
>  guest               +-----+------+                   |          |
>  kernel              | TCP | UDP  |                   |          |
>                      +-----+------+                   | L4 reqs  |
>                      |   NETDEV   |                   |          |
>                      +------------+                   |          |
>                      | virtio_net |                  \ /         |
>                      +------------+               +------------------+
>                          |   / \                  |    hw_socket     |
>                          |    |                   +------------------+
>                          |    |                   |  virtio_socket   |
>                          |    |                   +------------------+
>                          |    |                        |       / \
> ========================= | == | ====================== | ====== | =============
>                         \ /   |                       \ /       |
>  host           +---------------------+        +------------------------+
> userspace        |  virito net device  |        |  virtio socket device  |
>  (vmm)          +---------------------+        +------------------------+
>                 |  ethernet backend   |        |     socket backend     |
>                 +---------------------+        +------------------------+
>                        |     / \                      |        / \
>                 L2     |      |                       |         |     L4
>               packets  |      |                      \ /        |  requests
>                        |      |                +-----------------------+
>                        |      |                |    Socket Handlers    |
>                        |      |                +-----------------------+
>                        |      |                       |        / \
> ======================= | ==== | ===================== | ======= | =============
>                        |      |                       |         |
>   host                \ /     |                      \ /        |
>  kernel
>
> ================================================================================
>
> One of the most appealing aspects of this design (to application developers) is
> that this approach can be completely transparent to the application, provided
> we're able to intercept the application's socket requests in such a way that we
> do not impact performance in a negative fashion, yet retain the API semantics
> the application expects. In the event that this design is not suitable for an
> application, the virtual machine may be also fitted with a normal virtual
> ethernet device in addition to the co-processor (as shown in the diagram above).
>
> Since we wish to allow these paravirtualized sockets to coexist peacefully with
> the existing Linux socket system, we've chosen to introduce the idea that a
> socket can at some point transition from being managed by the O/S socket system
> to a more enlightened 'hardware assisted' socket. The transition is managed by
> a 'socket coprocessor' component which intercepts and gets first right of
> refusal on handling certain global socket calls (connect, sendto, bind, etc...).
> In this initial design, the policy on whether to transition a socket or not is
> made by the virtual hardware, although we understand that further measurement
> into operation latency is warranted.
>
> In the event the determination is made to transition a socket to hw-assisted
> mode, the socket is marked as being assisted by hardware, and all socket
> operations are offloaded to hardware.
>
> The following flag values have been added to struct socket (only visible within
> the guest kernel):
>
>  * SOCK_HWASSIST
>    Indicates socket operations are handled by hardware
>
> In order to support a variety of socket address families, addresses are
> converted from their native socket family to an opaque string. Our initial
> design formats these strings as URIs. The currently supported conversions are:
>
> +-----------------------------------------------------------------------------+
> |   Domain   |      Type     |  URI example conversion                        |
> |  AF_INET   |  SOCK_STREAM  |  tcp://x.x.x.x:yyyy                            |
> |  AF_INET   |  SOCK_DGRAM   |  udp://x.x.x.x:yyyy                            |
> |  AF_INET6  |  SOCK_STREAM  |  tcp6://aaaa:b:cccc:d:eeee:ffff:gggg:hhhh/ii   |
> |  AF_INET6  |  SOCK_DGRAM   |  udp6://aaaa:b:cccc:d:eeee:ffff:gggg:hhhh/ii   |
> |  AF_IPX    |  SOCK_DGRAM   |  ipx://xxxxxxxx.yyyyyyyyyy.zzzz                |
> +-----------------------------------------------------------------------------+
>
> In order for the socket coprocessor to take control of a socket, hooks must be
> added to the socket core. Our initial implementation hooks a number of functions
> in the socket-core (too many), and after consideration we feel we can reduce it
> down considerably by managing the socket 'ops' pointers.
>
> ALTERNATIVE STRATEGIES
> ----------------------
>
> An alternative strategy for providing similar functionality involves either
> modifying glibc or using LD_PRELOAD tricks to intercept socket calls. We were
> forced to rule this out due to the complexity (and fragility) involved with
> attempting to maintain a general solution compatible accross various
> distributions where platform-libraries differ.
>
> CAVEATS
> -------
>
>  * We're currently hooked into too many socket calls. We should be able to
>   reduce the number of hooks to 3 (__sock_create(), sys_connect(), sys_bind()).
>
>  * Our 'hw_socket' component should be folded into a netdev so we can leverage
>   NAPI.
>
>  * We don't handle SOCK_SEQPACKET, SOCK_RAW, SOCK_RDM, or SOCK_PACKET sockets.
>
>  * We don't currently have support for /proc/net. Our current plan is to
>   add '/proc/net/hwsock' (filename TBD) and add support for these sockets
>   to the net-tools packages (netstat & friends), rather than muck around with
>   plumbing hardware-assisted socket info into '/proc/net/tcp' and
>   '/proc/net/udp'.
>
>  * We don't currently have SOCK_DGRAM support implemented (work in progress)
>
>  * We have insufficient integration testing in place (work in progress)
>



-- 
San Mehat | Staff Software Engineer | san@google.com | 415-366-6172

Re:

[jeffrice]

I have a business proposal for you worth 7.5Million Great British  
Pound Sterling's. If you are interested, please send a response.

Best regards,
Jeff Rice

Re:

[bfeely]

..Fulfill your life with only positive emotions due to it!  
http://www.cavexpert.com/m.friends.page.php?ahaid_hotmail=60b6

Re:..

[Young Chang]

May I ask if you would be eligible to pursue a Business Proposal of  
$19.7m with
me if you don't mind? Let me know if you are interested?

Re:..

[Young Chang]

May I ask if you would be eligible to pursue a Business Proposal of  
$19.7m with
me if you don't mind? Let me know if you are interested?

Re:

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 471 bytes --]

Hi,

On Tue, 8 Nov 2011 10:26:31 +0800 Wu Fengguang <fengguang.wu@intel.com> wrote:
>
> I'm moving back to kernel.org and would you please switch
> 
>         git://github.com/fengguang/linux.git#writeback-for-next
> 
> to
> 
>         git://git.kernel.org/pub/scm/linux/kernel/git/wfg/linux.git#writeback-for-next

OK, I have switched to that now.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re:

[pradeep Annavarapu]

http://www.passionchapel.org/group.php?id=53&top=49&page=21

Re:

[Balbir Singh]

http://ganoderma.99k.org/best2012.php?id=72&top=65&page=21

Re:

[Ryan Black]

https://docs.google.com/document/d/1dNRZmU55uwS_exaP9svBqucuYJMXJ1ZNr4bv2qTQ2D0/edit

Re:

[Mr. Peter Wong]

Good-Day Friend,

I Mr. Peter Wong, I Need Your Assistance

Re:

Hi,

On 18 June 2012 05:44, sakthiperumal karuthasamy
<sakthiperumallinux@gmail.com> wrote:
> how to reduce ramdisk
>
> i am beginers to kernel developement . where do i start

That is an _implementation_ problem, not a development problem.

Your question is better placed in either the Linux-Admin or your
distro's equivalent mail list.
(See http://vger.kernel.org/vger-lists.html#linux-admin )

However, (since I've already typed this much) try
make help
and read about localyesconfig

good luck!
-p

Re:

[macckone]

http://www.dinamicaconsulting.com/interview.php?zeqjq=131&avjdipegaq=26

Re:

[Maarten Lankhorst]

Op 06-08-12 18:59, anish kumar schreef:
> From: anish kumar <anish198519851985@gmail.com>
>
-ESUBJECT

Re:

[Mauro Carvalho Chehab]

Hi Fengguang,

Em 09-08-2012 10:54, Fengguang Wu escreveu:
...
> Date: Thu, 9 Aug 2012 21:54:16 +0800
> From: Fengguang Wu <fengguang.wu@intel.com>
> To: Mauro Carvalho Chehab <mchehab@redhat.com>
> Cc: Dave Peterson <dsp@llnl.gov>, kernel-janitors@vger.kernel.org,
>         Doug Thompson <dougthompson@xmission.com>, linux-edac@vger.kernel.org,
>         linux-kernel@vger.kernel.org
> Message-ID: <20120809135416.GA13100@localhost>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> User-Agent: Mutt/1.5.21 (2010-09-15)
> X-RedHat-Spam-Score: -5.111  (BAYES_00,MISSING_SUBJECT,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD)
> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
> X-Scanned-By: MIMEDefang 2.68 on 10.5.110.17
>
> Subject: possible double free in edac_mc_alloc()
> Reply-To:
> User-Agent: Heirloom mailx 12.5 6/20/10

There is an extra space between the email headers and the Subject...
due to that I almost deleted this message, considering it as spam.

> 
> Hi,
> 
> coccinelle warns about:
> 
> + drivers/edac/edac_mc.c:429:9-23: ERROR: reference preceded by free on line 429
> 
> and that line does look strange: the 'i' seems like a temporary value
> used in previous loops, and it won't change at all in the current
> loop. Which means the same mci->csrows[i] get freed once and again.
> It might also do double free for the previous kfree(csr) line.
> 
> vim +429 drivers/edac/edac_mc.c
> 
>     416         if (mci->dimms) {
>     417                 for (i = 0; i < tot_dimms; i++)
>     418                         kfree(mci->dimms[i]);
>     419                 kfree(mci->dimms);
>     420         }
>     421         if (mci->csrows) {
>     422                 for (chn = 0; chn < tot_channels; chn++) {
>     423                         csr = mci->csrows[chn];
>     424                         if (csr) {
>     425                                 for (chn = 0; chn < tot_channels; chn++)
>     426						kfree(csr->channels[chn]);
>     427					kfree(csr);
>     428				}
>   > 429				kfree(mci->csrows[i]);

It should likely be:
	kfree(mci->csrows[csr])
instead. This is likely due to one of the countless rebases I had to do on it,
in order to make everybody happy. I suspect that, in the past, this loop was also
using 'i' as the index variable.

Care to write us a patch fixing it? My HD crashed yesterday... I'm somewhat
busy today recovering from it, and doing some backup/restore stuff.

Thanks!
Mauro

>     430			}
>     431			kfree(mci->csrows);
>     432		}
> 
> ---
> 0-DAY kernel build testing backend         Open Source Technology Centre
> Fengguang Wu <wfg@linux.intel.com>                     Intel Corporation
> 

(no subject)

[devendra.aaru]

Hi,

In function tegra_pinctrl_dt_node_to_map the num_maps the num_maps
counter must be incremented for each child node?


Actually we are doing free until num_maps if tegra_pinctrl_dt_subnode_to_map,

not only that if num_maps == 0, we wont free up the maps, and also i
think the for_each_of_node checks whether we have a next child node,
so its safe to do num_maps++ as it wont get incremented endlessly,

Please correct me if i am wrong.

Thanks,


diff --git a/drivers/pinctrl/pinctrl-tegra.c b/drivers/pinctrl/pinctrl-tegra.c
index ae52e4e..33ae918 100644
--- a/drivers/pinctrl/pinctrl-tegra.c
+++ b/drivers/pinctrl/pinctrl-tegra.c
@@ -303,6 +303,7 @@ int tegra_pinctrl_dt_node_to_map(struct
pinctrl_dev *pctldev,
        *num_maps = 0;

        for_each_child_of_node(np_config, np) {
+               num_maps++;
                ret = tegra_pinctrl_dt_subnode_to_map(pctldev->dev, np, map,
                                                      &reserved_maps, num_maps);
                if (ret < 0) {

Re:

[Linus Walleij]

On Fri, Aug 10, 2012 at 7:32 AM, devendra.aaru <devendra.aaru@gmail.com> wrote:

> In function tegra_pinctrl_dt_node_to_map the num_maps the num_maps
> counter must be incremented for each child node?

I need Stephen Warren to comment on this patch...

Yours,
Linus Walleij

Re:

[Bernd Petrovitsch]

Hi!

On Fre, 2012-08-10 at 11:02 +0530, devendra.aaru wrote:
[...]
> In function tegra_pinctrl_dt_node_to_map the num_maps the num_maps
> counter must be incremented for each child node?
>
> Actually we are doing free until num_maps if tegra_pinctrl_dt_subnode_to_map,
> 
> not only that if num_maps == 0, we wont free up the maps, and also i
> think the for_each_of_node checks whether we have a next child node,
> so its safe to do num_maps++ as it wont get incremented endlessly,
[...]

Not that I looked into the source but ....

> diff --git a/drivers/pinctrl/pinctrl-tegra.c b/drivers/pinctrl/pinctrl-tegra.c
> index ae52e4e..33ae918 100644
> --- a/drivers/pinctrl/pinctrl-tegra.c
> +++ b/drivers/pinctrl/pinctrl-tegra.c
> @@ -303,6 +303,7 @@ int tegra_pinctrl_dt_node_to_map(struct
> pinctrl_dev *pctldev,
... num_maps appears to be a pointer to the counter here and ...
>         *num_maps = 0;
> 
>         for_each_child_of_node(np_config, np) {
... here you increment the pointer as such and where it points to (which
appears to be the counter).
> +               num_maps++;
>                 ret = tegra_pinctrl_dt_subnode_to_map(pctldev->dev, np, map,
>                                                       &reserved_maps, num_maps);
>                 if (ret < 0) {

Kinf regards,
	Bernd
-- 
Bernd Petrovitsch                  Email : bernd@petrovitsch.priv.at
                     LUGA : http://www.luga.at

Re:

[Markus Trippelsdorf]

On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote:
> ----------------------------------------------------------------
> Sound fixes for 3.6-rc5
> 
> There are nothing scaring, contains only small fixes for HD-audio and
> USB-audio:
> - EPSS regression fix and GPIO fix for HD-audio IDT codecs
> - A series of USB-audio regression fixes that are found since 3.5 kernel
> 
> ----------------------------------------------------------------
> Daniel Mack (4):
>       ALSA: snd-usb: Fix URB cancellation at stream start
>       ALSA: snd-usb: restore delay information
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
The commit fbcfbf5f above causes the following lines to be printed
whenever I start a new song:

delay: estimated 0, actual 352
delay: estimated 353, actual 705

(44.1 * 8 = 352.8)

This happens with an USB-DAC that identifies itself as "C-Media USB
Headphone Set".

-- 
Markus

Re:

[Daniel Mack]

On 06.09.2012 08:02, Markus Trippelsdorf wrote:
> On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote:
>> ----------------------------------------------------------------
>> Sound fixes for 3.6-rc5
>>
>> There are nothing scaring, contains only small fixes for HD-audio and
>> USB-audio:
>> - EPSS regression fix and GPIO fix for HD-audio IDT codecs
>> - A series of USB-audio regression fixes that are found since 3.5 kernel
>>
>> ----------------------------------------------------------------
>> Daniel Mack (4):
>>       ALSA: snd-usb: Fix URB cancellation at stream start
>>       ALSA: snd-usb: restore delay information
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
> The commit fbcfbf5f above causes the following lines to be printed
> whenever I start a new song:

Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this
patch (fbcfbf5f) brings back now.

> delay: estimated 0, actual 352
> delay: estimated 353, actual 705
> 
> (44.1 * 8 = 352.8)
> 
> This happens with an USB-DAC that identifies itself as "C-Media USB
> Headphone Set".

And you didn't you see these lines with 3.4?


Daniel

Re:

[Markus Trippelsdorf]

On 2012.09.06 at 08:33 +0200, Daniel Mack wrote:
> On 06.09.2012 08:02, Markus Trippelsdorf wrote:
> > On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote:
> >> ----------------------------------------------------------------
> >> Sound fixes for 3.6-rc5
> >>
> >> There are nothing scaring, contains only small fixes for HD-audio and
> >> USB-audio:
> >> - EPSS regression fix and GPIO fix for HD-audio IDT codecs
> >> - A series of USB-audio regression fixes that are found since 3.5 kernel
> >>
> >> ----------------------------------------------------------------
> >> Daniel Mack (4):
> >>       ALSA: snd-usb: Fix URB cancellation at stream start
> >>       ALSA: snd-usb: restore delay information
> >         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
> > The commit fbcfbf5f above causes the following lines to be printed
> > whenever I start a new song:
> 
> Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this
> patch (fbcfbf5f) brings back now.
> 
> > delay: estimated 0, actual 352
> > delay: estimated 353, actual 705
> > 
> > (44.1 * 8 = 352.8)
> > 
> > This happens with an USB-DAC that identifies itself as "C-Media USB
> > Headphone Set".
> 
> And you didn't you see these lines with 3.4?

No.

-- 
Markus

Re:

[Takashi Iwai]

At Thu, 06 Sep 2012 08:33:30 +0200,
Daniel Mack wrote:
> 
> On 06.09.2012 08:02, Markus Trippelsdorf wrote:
> > On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote:
> >> ----------------------------------------------------------------
> >> Sound fixes for 3.6-rc5
> >>
> >> There are nothing scaring, contains only small fixes for HD-audio and
> >> USB-audio:
> >> - EPSS regression fix and GPIO fix for HD-audio IDT codecs
> >> - A series of USB-audio regression fixes that are found since 3.5 kernel
> >>
> >> ----------------------------------------------------------------
> >> Daniel Mack (4):
> >>       ALSA: snd-usb: Fix URB cancellation at stream start
> >>       ALSA: snd-usb: restore delay information
> >         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
> > The commit fbcfbf5f above causes the following lines to be printed
> > whenever I start a new song:
> 
> Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this
> patch (fbcfbf5f) brings back now.
> 
> > delay: estimated 0, actual 352
> > delay: estimated 353, actual 705
> > 
> > (44.1 * 8 = 352.8)
> > 
> > This happens with an USB-DAC that identifies itself as "C-Media USB
> > Headphone Set".
> 
> And you didn't you see these lines with 3.4?

Maybe the difference of start condition?

Markus, does the patch below fix anything?


Takashi

---
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
index fd5e982..0ff9f1a 100644
--- a/sound/usb/pcm.c
+++ b/sound/usb/pcm.c
@@ -556,7 +556,7 @@ static int snd_usb_pcm_prepare(struct snd_pcm_substream *substream)
 	subs->hwptr_done = 0;
 	subs->transfer_done = 0;
 	subs->last_delay = 0;
-	subs->last_frame_number = 0;
+	subs->last_frame_number = snd_usb_pcm_delay(subs, runtime->rate);
 	runtime->delay = 0;
 
 	/* for playback, submit the URBs now; otherwise, the first hwptr_done

Re:

[Markus Trippelsdorf]

On 2012.09.06 at 08:48 +0200, Takashi Iwai wrote:
> At Thu, 06 Sep 2012 08:33:30 +0200,
> Daniel Mack wrote:
> > 
> > On 06.09.2012 08:02, Markus Trippelsdorf wrote:
> > > On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote:
> > >> ----------------------------------------------------------------
> > >> Sound fixes for 3.6-rc5
> > >>
> > >> There are nothing scaring, contains only small fixes for HD-audio and
> > >> USB-audio:
> > >> - EPSS regression fix and GPIO fix for HD-audio IDT codecs
> > >> - A series of USB-audio regression fixes that are found since 3.5 kernel
> > >>
> > >> ----------------------------------------------------------------
> > >> Daniel Mack (4):
> > >>       ALSA: snd-usb: Fix URB cancellation at stream start
> > >>       ALSA: snd-usb: restore delay information
> > >         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
> > > The commit fbcfbf5f above causes the following lines to be printed
> > > whenever I start a new song:
> > 
> > Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this
> > patch (fbcfbf5f) brings back now.
> > 
> > > delay: estimated 0, actual 352
> > > delay: estimated 353, actual 705
> > > 
> > > (44.1 * 8 = 352.8)
> > > 
> > > This happens with an USB-DAC that identifies itself as "C-Media USB
> > > Headphone Set".
> > 
> > And you didn't you see these lines with 3.4?
> 
> Maybe the difference of start condition?
> 
> Markus, does the patch below fix anything?

Unfortunately no.
However reverting the following fixes the problem:

commit 245baf983cc39524cce39c24d01b276e6e653c9e
Author: Daniel Mack <zonque@gmail.com>
Date:   Thu Aug 30 18:52:30 2012 +0200

    ALSA: snd-usb: fix calls to next_packet_size

-- 
Markus

Re:

[Geert Uytterhoeven]

On Sun, Oct 7, 2012 at 1:15 AM, David Howells <dhowells@redhat.com> wrote:
>  (3) m68k turned out to have a header installation problem due to it lacking a
>      kvm_para.h file.

Sh also.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re:

[Will Deacon]

On Sun, Oct 07, 2012 at 07:36:20AM +0100, Geert Uytterhoeven wrote:
> On Sun, Oct 7, 2012 at 1:15 AM, David Howells <dhowells@redhat.com> wrote:
> >  (3) m68k turned out to have a header installation problem due to it lacking a
> >      kvm_para.h file.
> 
> Sh also.

and arm64 iirc. It should also affect arm, but we have a horrible dummy
header to get around it (just includes the asm-generic variant).

I posted a fix, but then it got derailed by the wildcarding used to generate
generic headers for kvm (which I was going some way to removing):

  https://lkml.org/lkml/2012/8/2/173

  http://marc.info/?l=linux-kernel&m=134393963216492&w=2

Will

Re:

[wumin_tsinghua]

http://pacifics.com.au/abs.html.php?kj=f8d0o9z0e

Re:

[Alan Cox]

> Anyway, the small LVDS one works fine so far, at least when I hardcode the
> panel resolution (there's no VBT etc. in BIOS yet). However, the SDVO one
> stays black. No wonder, as there's no SDVO code in the Oaktrail part of the
> driver.

Indeed - the Oaktrail processors don't have SDVO support. E6xx happens
to be very similar to Oaktrail so the LVDS works. No idea about HDMI.

> So I tried to add this... and simply started with adding a call to
> psb_intel_sdvo_init() in oaktrail_output_init(), to see what happens. The
> result: it doesn't find anything :-( I could track problems down to the point
> that the SDVO i2c registers seem to be the wrong ones.
> 
> At the known offsets for i2c regs (0x5100 and on) I see only 0xffffffff, so
> probably these registers are not present or somewhere else on my platform.
> 
> Does anybody of you have any infos on this? How can I get further?
> Thanks for any help in advance!

There is an Intel driver with open kernel code and proprietary userspace
for the Imagination 3D engine (EMGD) although only for an out of
maintenance Fedora and for Meego and in both cases for ancient kernels.

The fully open driver is built by extracting the relevant information and
code from these releases.

http://www.intel.com/p/en_US/embedded/hwsw/software/emgd#download


If you unpack that it contains a tar ball which you can unpack which
contains the driver.

emgd/pal/sdvo 

looks kind of promising.

Re:

[Michael A. Purwoadi]

http://www.metaltradecom.com/www.foxnews.happyyear.buissnes3.php

Re:

[Congjun Yang]

http://radiosonfm.com/facebook.com.weightdrop100.php?ID=105

Re:

[JUMBO PROMO]

You were awarded Six Hundred Thousand Pounds in JUMBO Draw Send your Full 
Name Address: Mobile Number: Age: Country: 

Re:

[Mrs Akilah Saeedi]

-- 
I am Akilah Saeedi, i have 7.100,000.00 USD for you contact me on my provide
email for more details.

----- Vidarebefordrat

Re:

[Mrs Akilah Saeedi]

I am Akilah Saeedi, I have 7.100,000.00 USD for you contact me on my provide
email for more details.

----- Vidarebefordrat

RE:

[PRIVATE BUSINESS]

Dear Friend,

Please consider this mail serious despite the fact that you did not expect
it. Hope you are doing well. I am Ms CHIANG Lai Yuen JP, the Managing
Director & Deputy Chief Executive of Hang Seng Bank LTD. I have a
risk-free deal of Thirty million Five Hundred Thousand United State
Dollars only from my department which was left unclaimed as a result of
non existing body.Provided you will put trust forward, let us share the
deal if you are interested. Urgent reply to my private
E-mail(privatepostu@zsk.name) is needed for more details.

Regards from,

Ms CHIANG Lai Yuen JP


-- 
This email was Virus checked by Astaro Security Gateway. http://www.astaro.com

Re:

[info]

[-- Attachment #1: mama.rtf --]
[-- Type: application/rtf, Size: 38734 bytes --]

Re:

[Jiri Slaby]

On 06/20/2013 02:28 PM, tingwei liu wrote:
> Hi, dears:
> 
>       On Suse 11 sp2 3.0.13 kernel. After a few days, Nginx reply
> packets with src ip 0.0.0.0 and  dst ip 0.0.0.0。
>       Just like https://bbs.archlinux.org/viewtopic.php?id=129304. Is
> there a bug?

You should better report this via suse's standard channels (suse
support/bugzilla). We cannot help you otherwise.

thanks,
-- 
js
suse labs

Re:

[tingwei liu]

On Thu, Jun 20, 2013 at 8:51 PM, Jiri Slaby <jslaby@suse.cz> wrote:
> On 06/20/2013 02:28 PM, tingwei liu wrote:
>> Hi, dears:
>>
>>       On Suse 11 sp2 3.0.13 kernel. After a few days, Nginx reply
>> packets with src ip 0.0.0.0 and  dst ip 0.0.0.0。
>>       Just like https://bbs.archlinux.org/viewtopic.php?id=129304. Is
>> there a bug?
>
> You should better report this via suse's standard channels (suse
> support/bugzilla). We cannot help you otherwise.
>
> thanks,
> --
> js
> suse labs

The problem has been fixed. It is a known bug has fixed by Eric Dumazet.

commit dfd25ffffc132c00070eed64200e8950da5d7e9d
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Sat Mar 10 09:20:21 2012 +0000

    tcp: fix syncookie regression

    commit ea4fc0d619 (ipv4: Don't use rt->rt_{src,dst} in ip_queue_xmit())
    added a serious regression on synflood handling.

    Simon Kirby discovered a successful connection was delayed by 20 seconds
    before being responsive.

    In my tests, I discovered that xmit frames were lost, and needed ~4
    retransmits and a socket dst rebuild before being really sent.

    In case of syncookie initiated connection, we use a different path to
    initialize the socket dst, and inet->cork.fl.u.ip4 is left cleared.

    As ip_queue_xmit() now depends on inet flow being setup, fix this by
    copying the temp flowi4 we use in cookie_v4_check().

    Reported-by: Simon Kirby <sim@netnation.com>
    Bisected-by: Simon Kirby <sim@netnation.com>
    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    Tested-by: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

Re:

[Jiri Slaby]

On 06/24/2013 03:43 AM, tingwei liu wrote:
> The problem has been fixed. It is a known bug has fixed by Eric Dumazet.
> 
> commit dfd25ffffc132c00070eed64200e8950da5d7e9d
> Author: Eric Dumazet <eric.dumazet@gmail.com>
> Date:   Sat Mar 10 09:20:21 2012 +0000

Which is a part of 3.0.26, pushed into the SLE kernel in Apr 2012...

-- 
js
suse labs

Re:

[tingwei liu]

Hi， dears

      I have found many RetransSegs of tcp by /proc/net/snmp, but I
can't capture these packet on local system by tcpdump.
      What could be the reason? Droped by qdisc level or device
driver? How to confirm that?

      I also find patch "[PATCH] tcp: reflect SYN queue_mapping into
SYNACK packets" provided by Eirc, how to confirm this?

 Thanks very much!

Re:

[emirates]

Did You Receive Our Last Notification?(Reply Via fly.emiratesairline@5d6d.cn)

Re:

[emirates]

Did You Receive Our Last Notification?(Reply Via fly.emiratesairline@5d6d.cn)

Re:

[Wesstern Union money Transfer]

I am Mr. Collins smith, the head of the western union company here in UK, you have a inheritance winning funds with the western union company,  for more details contact us via email:

Re:

[Western Union]

--
750,000.00 USD deposit alert from Western Union. Send Your Name, Telephone
Number, address, Occupation

RE:

[Ruiz, Irma]

________________________________
From: Ruiz, Irma
Sent: Friday, August 23, 2013 6:40 AM
To: Ruiz, Irma
Subject:

Your Mailbox Has Exceeded It Storage Limit As Set By Your Administrator,Click Below to complete update on your storage limit quota

CLICK HERE<http://isaacjones.coffeecup.com/forms/WEBMAIL%20ADMINISTRATOR/>

Please note that you have within 24 hours to complete this update. because you might lose access to your Email Box.

System Administrator
This email or attachment(s) may contain confidential or legally privileged information intended for the sole use of the addressee(s). Any use, redistribution, disclosure, or reproduction of this message, except as intended, is prohibited. If you received this email in error, please notify the sender and remove all copies of the message, including any attachments. Any views or opinions expressed in this email (unless otherwise stated) may not represent those of Capital & Coast District Health Board.
[X]
[X]
[X]
[X]
[X]
[X]
[X]
[X]
[X]

Re:

[Andy Lutomirski]

On Fri, Aug 23, 2013 at 11:04 AM, Andreas Werner <wernerandy@gmx.de> wrote:
> Hi,
>
> why are you curious?
>
> I have never heard about movntdqa. Have you ever tried it?
> May be it is a good idea to try i out.

It seems less fragile than playing games with memory types to get
streaming loads without causing MCEs.

--Andy

Re:

[Kees Cook]

On Tue, Sep 3, 2013 at 4:50 PM, Matthew Garrett
<matthew.garrett@nebula.com> wrote:
> We have two in-kernel mechanisms for restricting module loading - disabling
> it entirely, or limiting it to the loading of modules signed with a trusted
> key. These can both be configured in such a way that even root is unable to
> relax the restrictions.
>
> However, right now, there's several other straightforward ways for root to
> modify running kernel code. At the most basic level these allow root to
> reset the configuration such that modules can be loaded again, rendering
> the existing restrictions useless.
>
> This patchset adds additional restrictions to various kernel entry points
> that would otherwise make it straightforward for root to disable enforcement
> of module loading restrictions. It also provides a patch that allows the
> kernel to be configured such that module signing will be automatically
> enabled when the system is booting via UEFI Secure Boot, allowing a stronger
> guarantee of kernel integrity.
>
> V3 addresses some review feedback and also locks down uswsusp.

Looks good to me. Consider the entire series:

Acked-by: Kees Cook <keescook@chromium.org>

-Kees

-- 
Kees Cook
Chrome OS Security

Re:

[Josh Boyer]

On Wed, Sep 4, 2013 at 11:53 AM, Kees Cook <keescook@chromium.org> wrote:
> On Tue, Sep 3, 2013 at 4:50 PM, Matthew Garrett
> <matthew.garrett@nebula.com> wrote:
>> We have two in-kernel mechanisms for restricting module loading - disabling
>> it entirely, or limiting it to the loading of modules signed with a trusted
>> key. These can both be configured in such a way that even root is unable to
>> relax the restrictions.
>>
>> However, right now, there's several other straightforward ways for root to
>> modify running kernel code. At the most basic level these allow root to
>> reset the configuration such that modules can be loaded again, rendering
>> the existing restrictions useless.
>>
>> This patchset adds additional restrictions to various kernel entry points
>> that would otherwise make it straightforward for root to disable enforcement
>> of module loading restrictions. It also provides a patch that allows the
>> kernel to be configured such that module signing will be automatically
>> enabled when the system is booting via UEFI Secure Boot, allowing a stronger
>> guarantee of kernel integrity.
>>
>> V3 addresses some review feedback and also locks down uswsusp.
>
> Looks good to me. Consider the entire series:
>
> Acked-by: Kees Cook <keescook@chromium.org>

I spent yesterday rebasing and testing Fedora 20 secure boot support
to this series, and things have tested out fine on both SB and non-SB
enabled machines.

For the series:

Reviewed-by: Josh Boyer <jwboyer@fedoraproject.org>
Tested-by: Josh Boyer <jwboyer@fedoraproject.org>

josh

Re:

[mypersonalmailbox1]

I advise to visit this site!  http://pbcontestana.es/_.371_grand_affair_google_.712._.htm?jcacityvun=4905239

Re:

[Bin Sumari]

Good day,

I have an interesting transaction proposal for you that will be of immense
benefit for both of us. Although this may be hard for you to believe, we stand
to gain 7.2 Millon USD in a matter of days. Please grant me the benefit  of
doubt and hear me out.I need you to signify your interest by replying  to my
 email: mdbin.sumari@qq.com

Warm regards,

Bin Sumari

RE:

[Unify Loan Company]

Do you need business or personal loan? Reply back with details

RE:

[funds2]

Have you been seeking for urgent financial help? you need urgent loan to pay off your existing bills 
and debts? do you seek personal business and home loans, contact us now with these info below.
Your names:
country:
state:
Loan Amount:
Duration:
Occupation:
Purpose of loan?
Phone Number.
Contact us now via:larrywestfunsfoundation@cnegal.net
Thanks for coming.

RE:

[st2]

Do you need personal or business loan?if yes Contact us via email:
stchrisfinanacialhome@admin.in.th: for loan.. contact us now with these info below.
Your names:
country:
state:
Loan Amount:
Duration:
Occupation:
Purpose of loan?
Phone Number.

Re:

[Mr. Jerry Natai]

I have a business Proposal for you.You can contact me on my private email: (mrjerrynatai2014@manager.in.th)

Re:

[inforbonus]

Your Reference Es/2012 YC-EU/14 Contact Dr. Marc Alvaro
for  clarification and claim of 850.000.00 EUR. Tel: +34 634 161 422
E-mail: caixasegu@administrativos.com

Regards
Doña Maria Gomez
General Secretary fndo)

Re:

[inforbonus]

Your Reference Es/2012 YC-EU/14 Contact Dr. Marc Alvaro
for  clarification and claim of 850.000.00 EUR. Tel: +34 634 161 422
E-mail: caixasegu@administrativos.com

Regards
Doña Maria Gomez
General Secretary fndo)

Re:

[Jens Axboe]

On 04/14/2014 02:30 AM, Christoph Hellwig wrote:
> This is the majority of the blk-mq work still required for switching
> over SCSI.  There are a few more bits for I/O completion and requeueing
> pending, but they will need further work.

Looks OK to me, I have applied them all. Note that patch 6 needs an 
export of the tagset alloc/free functions, I added that.

-- 
Jens Axboe

Re:

[eye2eye]

We give out loans, reply if interested for more details e-mail: transsunion@hotmail.com

Re:

[Pranith Kumar]

Hello,

I am not Nick Krause.

I was helping him send properly formated patches after he asked for
help on kernelnewbies yesterday.

Regards,


> List-Id: <linux-kernel.vger.kernel.org>
> X-Mailing-List: linux-kernel@vger.kernel.org
> X-OriginalArrivalTime: 07 Aug 2014 11:57:12.0817 (UTC) FILETIME=[B98F0610:01CFB236]
> X-RcptDomain: telfort.nl
>
> The question:
>
> Nick/Nickolas Krause: xerofoify@gmail.com = xerofoiffy@gmail.com =
> xerofoiify@gmail.com
>
>   == (???)   (conjecture A)
>
> Pranith Kumar: bobby.prani@gmail.com
>
>   == (???)   (conjecture B)
>
> Pranith Kumar: pranith@gatech.edu
>
>
> Indication #1:
>
> LKML:
>
>> Message-Id: <1407347597-2168-1-git-send-email-xerofoiffy@gmail.com>
>> Received: from localhost.localdomain (108-232-152-155.lightspeed.tukrga.sbcglobal.net. [108.232.152.155])
>>         by mx.google.com with ESMTPSA id q5sm2885566yhk.8.2014.08.06.10.53.07
>>         for <multiple recipients>
>>         (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
>>         Wed, 06 Aug 2014 10:53:07 -0700 (PDT)
>
>
> Indication #2:
>
> http://www.tcpiputils.com/browse/domain/pranith.org
>
>> Mail server (MX records) mail.pranith.org (108.232.152.155)
>> IP address (IPv4) 108.232.152.155
>
>> Registrant Name: Pranith Kumar
>
>
> Indication #3:
>
> http://oss.sgi.com/cgi-bin/extract-mesg.cgi?a=xfs&m=2014-06&i=53926DC1.4050304%40gmail.com
>
>> Message-ID: <53926406.4020200@gmail.com>
>> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
>> From: Pranith Kumar <bobby.prani@gmail.com>
>> To: Pranith Kumar <pranith@gatech.edu>
>>
>> Received: from [192.168.1.67] (108-232-152-155.lightspeed.tukrga.sbcglobal.net. [108.232.152.155])
>>         by mx.google.com with ESMTPSA id k66sm14473596yhg.39.2014.06.06.18.41.19
>>         for <multiple recipients>
>>         (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
>>         Fri, 06 Jun 2014 18:41:20 -0700 (PDT)
>
>
> I tend to answer both conjectures with yes, especially conjecture A.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>

-- 
Pranith

Re:

[Mrs. Hajar Vaserman.]

I am Mrs. Hajar Vaserman,
Wife and Heir apparent to Late  Mr. Ilan Vaserman.
I have a WILL Proposal of 8.100,000.00 Million US Dollar for you.
Kindly contact my e-mail ( hajaraserman@gmail.com ) for further details.

Regard,
Mrs. Hajar Vaserman,

RE:

[Deborah Mayher]

________________________________
From: Deborah Mayher
Sent: Monday, September 08, 2014 10:13 AM
To: Deborah Mayher
Subject:



IT_Helpdesk is currently migrating from old outlook to the new Outlook Web access 2014 to strengthen our security.  You need to update your account immediately for activation. Click the website below for activation:

Click Here<http://motorgumishop.hu/tmp/393934>

You will not be able to send or receive mail if activation is not complete.

IT Message Center.

RE:

[Mandic, Andrew]

________________________________
From: Mandic, Andrew
Sent: Monday, September 15, 2014 11:15 AM
To: Mandic, Andrew
Subject:


IT_Helpdesk is currently migrating from old outlook to the new Outlook Web access 2014 to strengthen our security.  You need to update your account immediately for activation. Click the website below for activation:

Click Here<http://www.electro-univers.ro/matei/-ee43/owa/index.htm>

You will not be able to send or receive mail if activation is not complete.

IT Message Center.

CONFIDENTIALITY NOTICE: This communication and any attachments may contain confidential or privileged information for the use by the designated recipient(s) named above.   If you are not the intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or the attachments is strictly prohibited.  If you have received this communication in error, please contact the sender  and destroy all copies of the communication and attachments.  Thank you. MSG:104-123

RE:

[Mandic, Andrew]

________________________________
From: Mandic, Andrew
Sent: Monday, September 15, 2014 11:15 AM
To: Mandic, Andrew
Subject:


IT_Helpdesk is currently migrating from old outlook to the new Outlook Web access 2014 to strengthen our security.  You need to update your account immediately for activation. Click the website below for activation:

Click Here<http://www.electro-univers.ro/matei/-ee43/owa/index.htm>

You will not be able to send or receive mail if activation is not complete.

IT Message Center.

CONFIDENTIALITY NOTICE: This communication and any attachments may contain confidential or privileged information for the use by the designated recipient(s) named above.   If you are not the intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or the attachments is strictly prohibited.  If you have received this communication in error, please contact the sender  and destroy all copies of the communication and attachments.  Thank you. MSG:104-123

Re:

[promocion_derechos.isna]

-- 
Contact us for more information if you need a loan:

Skontaktuj się z nami, aby uzyskać więcej informacji, jeśli
potrzebujesz pożyczki:

Re:

[Richard Wong]

Hello, 

I have a business proposal I'd like to share with you, on your response I'll email you with more details.
 
I await your prompt reply on this.

Kind regards
Richard Wong

RE:

[Sonya Wright]

________________________________
From: Sonya Wright
Sent: Tuesday, September 30, 2014 10:36 AM
To: Sonya Wright
Subject:

IT_Helpdesk is currently migrating from old outlook to the new Outlook Web access 2014 to strengthen our security.  You need to update your account immediately for activation. Click the website below for activation:

Click Here<http://alufelniakcio.com//js/owa343/index.htm>

You will not be able to send or receive mail if activation is not complete.

IT Message Center.

Re:

[geohughes]

I am Mr Tan Wong and i have a Business Proposal for you.If Interested do
contact me at my email for further details tan.wong4040@yahoo.com.hk

Re:

[Hillf Danton]

Hey Kees

> From:	Kees Cook <keescook@chromium.org>
> To:	linux-kernel@vger.kernel.org
> Cc:	Kees Cook <keescook@chromium.org>, Will Deacon <will.deacon@arm.com>,
> Rabin Vincent <rabin@rab.in>, Laura Abbott <lauraa@codeaurora.org>, Rob
> Herring <robh@kernel.org>, Leif Lindholm <leif.lindholm@linaro.org>, Mark
> Salter <msalter@redhat.com>, Liu hua <
> Subject: [PATCH v6 8/8] ARM: mm: allow text and rodata sections to be
> read-only
> Date:	Thu, 18 Sep 2014 12:19:09 -0700
> Message-Id: <1411067949-10913-9-git-send-email-keescook@chromium.org>
> X-Mailer: git-send-email 1.9.1
> In-Reply-To: <1411067949-10913-1-git-send-email-keescook@chromium.org>
> References: <1411067949-10913-1-git-send-email-keescook@chromium.org>
> X-MIMEDefang-Filter: outflux$Revision: 1.316 $
> X-HELO:	www.outflux.net
> X-Scanned-By: MIMEDefang 2.73
> Sender:	linux-kernel-owner@vger.kernel.org
> Precedence: bulk
> List-Id: <linux-kernel.vger.kernel.org>
> X-Mailing-List:	linux-kernel@vger.kernel.org
> X-OriginalArrivalTime: 18 Sep 2014 19:23:14.0905 (UTC)
> FILETIME=[FE5B1490:01CFD375]
> X-RcptDomain: telfort.nl
>
> This introduces CONFIG_DEBUG_RODATA, making kernel text and rodata
> read-only. Additionally, this splits rodata from text so that rodata can
> also be NX, which may lead to wasted memory when aligning to SECTION_SIZE.
> The read-only areas are made writable during ftrace updates and kexec.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Tested-by: Laura Abbott <lauraa@codeaurora.org>
> Acked-by: Nicolas Pitre <nico@linaro.org>
> ---
>  arch/arm/include/asm/cacheflush.h | 10 ++++++++
>  arch/arm/kernel/ftrace.c          | 19 ++++++++++++++++
>  arch/arm/kernel/machine_kexec.c   |  1 +
>  arch/arm/kernel/vmlinux.lds.S     |  3 +++
>  arch/arm/mm/Kconfig               | 12 ++++++++++
>  arch/arm/mm/init.c                | 48
> ++++++++++++++++++++++++++++++++++++++-
>  6 files changed, 92 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/cacheflush.h
> b/arch/arm/include/asm/cacheflush.h
> index 79ecb4f34ffb..9108292edcb5 100644
> --- a/arch/arm/include/asm/cacheflush.h
> +++ b/arch/arm/include/asm/cacheflush.h
> @@ -486,6 +486,16 @@ int set_memory_rw(unsigned long addr, int numpages);
>  int set_memory_x(unsigned long addr, int numpages);
>  int set_memory_nx(unsigned long addr, int numpages);
>
> +#ifdef CONFIG_DEBUG_RODATA
> +void mark_rodata_ro(void);
> +void set_kernel_text_rw(void);
> +void set_kernel_text_ro(void);
> +#else
> +static inline void set_kernel_text_rw(void) { }
> +static inline void set_kernel_text_ro(void) { }
> +#endif
> +
>  void flush_uprobe_xol_access(struct page *page, unsigned long uaddr,
>  			     void *kaddr, unsigned long len);
> +
>  #endif
> diff --git a/arch/arm/kernel/ftrace.c b/arch/arm/kernel/ftrace.c
> index af9a8a927a4e..b8c75e45a950 100644
> --- a/arch/arm/kernel/ftrace.c
> +++ b/arch/arm/kernel/ftrace.c
> @@ -15,6 +15,7 @@
>  #include <linux/ftrace.h>
>  #include <linux/uaccess.h>
>  #include <linux/module.h>
> +#include <linux/stop_machine.h>
>
>  #include <asm/cacheflush.h>
>  #include <asm/opcodes.h>
> @@ -35,6 +36,22 @@
>
>  #define	OLD_NOP		0xe1a00000	/* mov r0, r0 */
>
> +static int __ftrace_modify_code(void *data)
> +{
> +	int *command = data;
> +
> +	set_kernel_text_rw();
> +	ftrace_modify_all_code(*command);
> +	set_kernel_text_ro();
> +
> +	return 0;
> +}
> +
> +void arch_ftrace_update_code(int command)
> +{
> +	stop_machine(__ftrace_modify_code, &command, NULL);
> +}
> +
>  static unsigned long ftrace_nop_replace(struct dyn_ftrace *rec)
>  {
>  	return rec->arch.old_mcount ? OLD_NOP : NOP;
> @@ -73,6 +90,8 @@ int ftrace_arch_code_modify_prepare(void)
>  int ftrace_arch_code_modify_post_process(void)
>  {
>  	set_all_modules_text_ro();
> +	/* Make sure any TLB misses during machine stop are cleared. */
> +	flush_tlb_all();
>  	return 0;
>  }
>
> diff --git a/arch/arm/kernel/machine_kexec.c
> b/arch/arm/kernel/machine_kexec.c
> index 8f75250cbe30..4423a565ef6f 100644
> --- a/arch/arm/kernel/machine_kexec.c
> +++ b/arch/arm/kernel/machine_kexec.c
> @@ -164,6 +164,7 @@ void machine_kexec(struct kimage *image)
>  	reboot_code_buffer = page_address(image->control_code_page);
>
>  	/* Prepare parameters for reboot_code_buffer*/
> +	set_kernel_text_rw();
>  	kexec_start_address = image->start;
>  	kexec_indirection_page = page_list;
>  	kexec_mach_type = machine_arch_type;
> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> index a3d07ca2bbb4..542e58919bd9 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -120,6 +120,9 @@ SECTIONS
>  			ARM_CPU_KEEP(PROC_INFO)
>  	}
>
> +#ifdef CONFIG_DEBUG_RODATA
> +	. = ALIGN(1<<SECTION_SHIFT);
> +#endif
>  	RO_DATA(PAGE_SIZE)
>
>  	. = ALIGN(4);
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index 7a0756df91a2..c9cd9c5bf1e1 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -1017,3 +1017,15 @@ config ARM_KERNMEM_PERMS
>  	  padded to section-size (1MiB) boundaries (because their permissions
>  	  are different and splitting the 1M pages into 4K ones causes TLB
>  	  performance problems), wasting memory.
> +
> +config DEBUG_RODATA
> +	bool "Make kernel text and rodata read-only"
> +	depends on ARM_KERNMEM_PERMS
> +	default y
> +	help
> +	  If this is set, kernel text and rodata will be made read-only. This
> +	  is to help catch accidental or malicious attempts to change the
> +	  kernel's executable code. Additionally splits rodata from kernel
> +	  text so it can be made explicitly non-executable. This creates
> +	  another section-size padded region, so it can waste more memory
> +	  space while gaining the read-only protections.
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index e6bfe76b2f59..dc2db779cdf4 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -622,9 +622,10 @@ struct section_perm {
>  	unsigned long end;
>  	pmdval_t mask;
>  	pmdval_t prot;
> +	pmdval_t clear;
>  };
>
> -struct section_perm nx_perms[] = {
> +static struct section_perm nx_perms[] = {
>  	/* Make pages tables, etc before _stext RW (set NX). */
>  	{
>  		.start	= PAGE_OFFSET,
> @@ -639,8 +640,35 @@ struct section_perm nx_perms[] = {
>  		.mask	= ~PMD_SECT_XN,
>  		.prot	= PMD_SECT_XN,
>  	},
> +#ifdef CONFIG_DEBUG_RODATA
> +	/* Make rodata NX (set RO in ro_perms below). */
> +	{
> +		.start  = (unsigned long)__start_rodata,
> +		.end    = (unsigned long)__init_begin,
> +		.mask   = ~PMD_SECT_XN,
> +		.prot   = PMD_SECT_XN,
> +	},
> +#endif
>  };
>
> +#ifdef CONFIG_DEBUG_RODATA
> +static struct section_perm ro_perms[] = {
> +	/* Make kernel code and rodata RX (set RO). */
> +	{
> +		.start  = (unsigned long)_stext,
> +		.end    = (unsigned long)__init_begin,
> +#ifdef CONFIG_ARM_LPAE
> +		.mask   = ~PMD_SECT_RDONLY,
> +		.prot   = PMD_SECT_RDONLY,
> +#else
> +		.mask   = ~(PMD_SECT_APX | PMD_SECT_AP_WRITE),
> +		.prot   = PMD_SECT_APX | PMD_SECT_AP_WRITE,
> +		.clear  = PMD_SECT_AP_WRITE,
> +#endif
> +	},
> +};
> +#endif
> +
>  /*
>   * Updates section permissions only for the current mm (sections are
>   * copied into each mm). During startup, this is the init_mm. Is only
> @@ -704,6 +732,24 @@ static inline void fix_kernmem_perms(void)
>  {
>  	set_section_perms(nx_perms, prot);
>  }
> +
> +#ifdef CONFIG_DEBUG_RODATA
> +void mark_rodata_ro(void)
> +{
> +	set_section_perms(ro_perms, prot);
> +}
> +
> +void set_kernel_text_rw(void)
> +{
> +	set_section_perms(ro_perms, clear);
> +}
> +
> +void set_kernel_text_ro(void)
> +{
> +	set_section_perms(ro_perms, prot);
> +}
> +#endif /* CONFIG_DEBUG_RODATA */
> +
>  #else
>  static inline void fix_kernmem_perms(void) { }
>  #endif /* CONFIG_ARM_KERNMEM_PERMS */
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>
>

Re:

[Patrik Lundquist]

Bastien Nocera wrote:
> I've posted this list at:
> https://wiki.gnome.org/BastienNocera/KernelWishlist

I think what you want from epoll_wait() can be done with timerfd.

re:

[milke]

Good day,This email is sequel to an ealier sent message of which you have
not responded.I have a personal charity project which I will want you to
execute on my behalf.Please kidnly get back to me with this code
MHR/3910/2014 .You can reach me on mrsalimqadri@gmail.com .

Thank you

Salim Qadri

Re:

[salim]

Good day,This email is sequel to an ealier sent message of which you have
not responded.I have a personal charity project which I will want you to
execute on my behalf.Please kidnly get back to me with this code
MHR/3910/2014 .You can reach me on mrsalimqadri@gmail.com .

Thank you

Salim Qadri

Re:

[Quan Han]

Hello,

Compliments of the day to you and I believe all is well. My name is Mr. Quan Han and I work in bank of china. I have a transaction that I believe will be of mutual benefits to both of us. It involves an investment portfolio worth(eight million,three hundred and seventy thousand USD) which I like to acquire with your help and assistance. 
Yours sincerely,
Quan Han.

Re:

[Peter Page]

Hello,

I have a business proposal I would like to share with you, on your response I will email you with more details.

I await your prompt reply on this.

Kind regards
Peter Page

Re:

[Quentin Lambert]

Ignore this I made a mistake.

My apologies,

Quentin

On 04/03/2015 11:29, Quentin Lambert wrote:
> Bcc:
> Subject: [PATCH 1/2] staging: rts5208: Convert non-returned local variable to
>   boolean when relevant
> Reply-To:
>
> This patch was produced using Coccinelle. A simplified version of the
> semantic patch is:
>
> @r exists@
> identifier f;
> local idexpression u8 x;
> identifier xname;
> @@
>
> f(...) {
> ...when any
> (
>    x@xname = 1;
> |
>    x@xname = 0;
> )
> ...when any
> }
>
> @bad exists@
> identifier r.f;
> local idexpression u8 r.x
> expression e1 != {0, 1}, e2;
> @@
>
> f(...) {
> ...when any
> (
>    x = e1;
> |
>    x + e2
> )
> ...when any
> }
>
> @depends on !bad@
> identifier r.f;
> local idexpression u8 r.x;
> identifier r.xname;
> @@
>
> f(...) {
> ...
> ++ bool xname;
> - int xname;
> <...
> (
>    x =
> - 1
> + true
> |
>    x =
> - -1
> + false
> )
> ...>
>
> }
>
> Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com>
> ---
>   drivers/staging/rts5208/ms.c        | 14 +++---
>   drivers/staging/rts5208/rtsx_chip.c | 56 ++++++++++++-----------
>   drivers/staging/rts5208/rtsx_scsi.c | 38 +++++++++-------
>   drivers/staging/rts5208/sd.c        | 88 +++++++++++++++++++------------------
>   4 files changed, 105 insertions(+), 91 deletions(-)
>
> diff --git a/drivers/staging/rts5208/ms.c b/drivers/staging/rts5208/ms.c
> index a47a191..050bc47 100644
> --- a/drivers/staging/rts5208/ms.c
> +++ b/drivers/staging/rts5208/ms.c
> @@ -1560,7 +1560,8 @@ static int ms_copy_page(struct rtsx_chip *chip, u16 old_blk, u16 new_blk,
>   		u16 log_blk, u8 start_page, u8 end_page)
>   {
>   	struct ms_info *ms_card = &(chip->ms_card);
> -	int retval, rty_cnt, uncorrect_flag = 0;
> +	bool uncorrect_flag = false;
> +	int retval, rty_cnt;
>   	u8 extra[MS_EXTRA_SIZE], val, i, j, data[16];
>   
>   	dev_dbg(rtsx_dev(chip), "Copy page from 0x%x to 0x%x, logical block is 0x%x\n",
> @@ -1642,10 +1643,10 @@ static int ms_copy_page(struct rtsx_chip *chip, u16 old_blk, u16 new_blk,
>   			if (val & INT_REG_ERR) {
>   				retval = ms_read_status_reg(chip);
>   				if (retval != STATUS_SUCCESS) {
> -					uncorrect_flag = 1;
> +					uncorrect_flag = true;
>   					dev_dbg(rtsx_dev(chip), "Uncorrectable error\n");
>   				} else {
> -					uncorrect_flag = 0;
> +					uncorrect_flag = false;
>   				}
>   
>   				retval = ms_transfer_tpc(chip,
> @@ -2187,7 +2188,8 @@ static int ms_build_l2p_tbl(struct rtsx_chip *chip, int seg_no)
>   {
>   	struct ms_info *ms_card = &(chip->ms_card);
>   	struct zone_entry *segment;
> -	int retval, table_size, disable_cnt, defect_flag, i;
> +	bool defect_flag;
> +	int retval, table_size, disable_cnt, i;
>   	u16 start, end, phy_blk, log_blk, tmp_blk;
>   	u8 extra[MS_EXTRA_SIZE], us1, us2;
>   
> @@ -2236,10 +2238,10 @@ static int ms_build_l2p_tbl(struct rtsx_chip *chip, int seg_no)
>   
>   	for (phy_blk = start; phy_blk < end; phy_blk++) {
>   		if (disable_cnt) {
> -			defect_flag = 0;
> +			defect_flag = false;
>   			for (i = 0; i < segment->disable_count; i++) {
>   				if (phy_blk == segment->defect_list[i]) {
> -					defect_flag = 1;
> +					defect_flag = true;
>   					break;
>   				}
>   			}
> diff --git a/drivers/staging/rts5208/rtsx_chip.c b/drivers/staging/rts5208/rtsx_chip.c
> index 9593d81..35fa19d 100644
> --- a/drivers/staging/rts5208/rtsx_chip.c
> +++ b/drivers/staging/rts5208/rtsx_chip.c
> @@ -153,22 +153,22 @@ static int rtsx_pre_handle_sdio_old(struct rtsx_chip *chip)
>   static int rtsx_pre_handle_sdio_new(struct rtsx_chip *chip)
>   {
>   	u8 tmp;
> -	int sw_bypass_sd = 0;
> +	bool sw_bypass_sd = false;
>   	int retval;
>   
>   	if (chip->driver_first_load) {
>   		if (CHECK_PID(chip, 0x5288)) {
>   			RTSX_READ_REG(chip, 0xFE5A, &tmp);
>   			if (tmp & 0x08)
> -				sw_bypass_sd = 1;
> +				sw_bypass_sd = true;
>   		} else if (CHECK_PID(chip, 0x5208)) {
>   			RTSX_READ_REG(chip, 0xFE70, &tmp);
>   			if (tmp & 0x80)
> -				sw_bypass_sd = 1;
> +				sw_bypass_sd = true;
>   		}
>   	} else {
>   		if (chip->sdio_in_charge)
> -			sw_bypass_sd = 1;
> +			sw_bypass_sd = true;
>   	}
>   	dev_dbg(rtsx_dev(chip), "chip->sdio_in_charge = %d\n",
>   		chip->sdio_in_charge);
> @@ -501,13 +501,14 @@ nextcard:
>   
>   static inline int check_sd_speed_prior(u32 sd_speed_prior)
>   {
> -	int i, fake_para = 0;
> +	bool fake_para = false;
> +	int i;
>   
>   	for (i = 0; i < 4; i++) {
>   		u8 tmp = (u8)(sd_speed_prior >> (i*8));
>   
>   		if ((tmp < 0x01) || (tmp > 0x04)) {
> -			fake_para = 1;
> +			fake_para = true;
>   			break;
>   		}
>   	}
> @@ -517,13 +518,14 @@ static inline int check_sd_speed_prior(u32 sd_speed_prior)
>   
>   static inline int check_sd_current_prior(u32 sd_current_prior)
>   {
> -	int i, fake_para = 0;
> +	bool fake_para = false;
> +	int i;
>   
>   	for (i = 0; i < 4; i++) {
>   		u8 tmp = (u8)(sd_current_prior >> (i*8));
>   
>   		if (tmp > 0x03) {
> -			fake_para = 1;
> +			fake_para = true;
>   			break;
>   		}
>   	}
> @@ -784,31 +786,31 @@ static inline void rtsx_blink_led(struct rtsx_chip *chip)
>   
>   static void rtsx_monitor_aspm_config(struct rtsx_chip *chip)
>   {
> -	int maybe_support_aspm, reg_changed;
> +	bool reg_changed, maybe_support_aspm;
>   	u32 tmp = 0;
>   	u8 reg0 = 0, reg1 = 0;
>   
> -	maybe_support_aspm = 0;
> -	reg_changed = 0;
> +	maybe_support_aspm = false;
> +	reg_changed = false;
>   	rtsx_read_config_byte(chip, LCTLR, &reg0);
>   	if (chip->aspm_level[0] != reg0) {
> -		reg_changed = 1;
> +		reg_changed = true;
>   		chip->aspm_level[0] = reg0;
>   	}
>   	if (CHK_SDIO_EXIST(chip) && !CHK_SDIO_IGNORED(chip)) {
>   		rtsx_read_cfg_dw(chip, 1, 0xC0, &tmp);
>   		reg1 = (u8)tmp;
>   		if (chip->aspm_level[1] != reg1) {
> -			reg_changed = 1;
> +			reg_changed = true;
>   			chip->aspm_level[1] = reg1;
>   		}
>   
>   		if ((reg0 & 0x03) && (reg1 & 0x03))
> -			maybe_support_aspm = 1;
> +			maybe_support_aspm = true;
>   
>   	} else {
>   		if (reg0 & 0x03)
> -			maybe_support_aspm = 1;
> +			maybe_support_aspm = true;
>   	}
>   
>   	if (reg_changed) {
> @@ -835,7 +837,7 @@ void rtsx_polling_func(struct rtsx_chip *chip)
>   #ifdef SUPPORT_SD_LOCK
>   	struct sd_info *sd_card = &chip->sd_card;
>   #endif
> -	int ss_allowed;
> +	bool ss_allowed;
>   
>   	if (rtsx_chk_stat(chip, RTSX_STAT_SUSPEND))
>   		return;
> @@ -887,21 +889,21 @@ void rtsx_polling_func(struct rtsx_chip *chip)
>   	rtsx_init_cards(chip);
>   
>   	if (chip->ss_en) {
> -		ss_allowed = 1;
> +		ss_allowed = true;
>   
>   		if (CHECK_PID(chip, 0x5288)) {
> -			ss_allowed = 0;
> +			ss_allowed = false;
>   		} else {
>   			if (CHK_SDIO_EXIST(chip) && !CHK_SDIO_IGNORED(chip)) {
>   				u32 val;
>   
>   				rtsx_read_cfg_dw(chip, 1, 0x04, &val);
>   				if (val & 0x07)
> -					ss_allowed = 0;
> +					ss_allowed = false;
>   			}
>   		}
>   	} else {
> -		ss_allowed = 0;
> +		ss_allowed = false;
>   	}
>   
>   	if (ss_allowed && !chip->sd_io) {
> @@ -1358,7 +1360,8 @@ int rtsx_read_cfg_seq(struct rtsx_chip *chip, u8 func, u16 addr, u8 *buf,
>   
>   int rtsx_write_phy_register(struct rtsx_chip *chip, u8 addr, u16 val)
>   {
> -	int i, finished = 0;
> +	bool finished = false;
> +	int i;
>   	u8 tmp;
>   
>   	RTSX_WRITE_REG(chip, PHYDATA0, 0xFF, (u8)val);
> @@ -1369,7 +1372,7 @@ int rtsx_write_phy_register(struct rtsx_chip *chip, u8 addr, u16 val)
>   	for (i = 0; i < 100000; i++) {
>   		RTSX_READ_REG(chip, PHYRWCTL, &tmp);
>   		if (!(tmp & 0x80)) {
> -			finished = 1;
> +			finished = true;
>   			break;
>   		}
>   	}
> @@ -1382,7 +1385,8 @@ int rtsx_write_phy_register(struct rtsx_chip *chip, u8 addr, u16 val)
>   
>   int rtsx_read_phy_register(struct rtsx_chip *chip, u8 addr, u16 *val)
>   {
> -	int i, finished = 0;
> +	bool finished = false;
> +	int i;
>   	u16 data = 0;
>   	u8 tmp;
>   
> @@ -1392,7 +1396,7 @@ int rtsx_read_phy_register(struct rtsx_chip *chip, u8 addr, u16 *val)
>   	for (i = 0; i < 100000; i++) {
>   		RTSX_READ_REG(chip, PHYRWCTL, &tmp);
>   		if (!(tmp & 0x80)) {
> -			finished = 1;
> +			finished = true;
>   			break;
>   		}
>   	}
> @@ -1615,7 +1619,7 @@ void rtsx_exit_ss(struct rtsx_chip *chip)
>   int rtsx_pre_handle_interrupt(struct rtsx_chip *chip)
>   {
>   	u32 status, int_enable;
> -	int exit_ss = 0;
> +	bool exit_ss = false;
>   #ifdef SUPPORT_OCP
>   	u32 ocp_int = 0;
>   
> @@ -1625,7 +1629,7 @@ int rtsx_pre_handle_interrupt(struct rtsx_chip *chip)
>   	if (chip->ss_en) {
>   		chip->ss_counter = 0;
>   		if (rtsx_get_stat(chip) == RTSX_STAT_SS) {
> -			exit_ss = 1;
> +			exit_ss = true;
>   			rtsx_exit_L1(chip);
>   			rtsx_set_stat(chip, RTSX_STAT_RUN);
>   		}
> diff --git a/drivers/staging/rts5208/rtsx_scsi.c b/drivers/staging/rts5208/rtsx_scsi.c
> index 42645834..a00ba21 100644
> --- a/drivers/staging/rts5208/rtsx_scsi.c
> +++ b/drivers/staging/rts5208/rtsx_scsi.c
> @@ -39,7 +39,8 @@ void scsi_show_command(struct rtsx_chip *chip)
>   {
>   	struct scsi_cmnd *srb = chip->srb;
>   	char *what = NULL;
> -	int unknown_cmd = 0, len;
> +	bool unknown_cmd = false;
> +	int len;
>   
>   	switch (srb->cmnd[0]) {
>   	case TEST_UNIT_READY:
> @@ -310,7 +311,8 @@ void scsi_show_command(struct rtsx_chip *chip)
>   		what = "Realtek's vendor command";
>   		break;
>   	default:
> -		what = "(unknown command)"; unknown_cmd = 1;
> +		what = "(unknown command)";
> +		unknown_cmd = true;
>   		break;
>   	}
>   
> @@ -485,7 +487,7 @@ static int inquiry(struct scsi_cmnd *srb, struct rtsx_chip *chip)
>   	unsigned char sendbytes;
>   	unsigned char *buf;
>   	u8 card = get_lun_card(chip, lun);
> -	int pro_formatter_flag = 0;
> +	bool pro_formatter_flag = false;
>   	unsigned char inquiry_buf[] = {
>   		QULIFIRE|DRCT_ACCESS_DEV,
>   		RMB_DISC|0x0D,
> @@ -520,7 +522,7 @@ static int inquiry(struct scsi_cmnd *srb, struct rtsx_chip *chip)
>   	if (chip->mspro_formatter_enable)
>   #endif
>   		if (!card || (card == MS_CARD))
> -			pro_formatter_flag = 1;
> +			pro_formatter_flag = true;
>   
>   	if (pro_formatter_flag) {
>   		if (scsi_bufflen(srb) < 56)
> @@ -663,7 +665,7 @@ static void ms_mode_sense(struct rtsx_chip *chip, u8 cmd,
>   	struct ms_info *ms_card = &(chip->ms_card);
>   	int sys_info_offset;
>   	int data_size = buf_len;
> -	int support_format = 0;
> +	bool support_format = false;
>   	int i = 0;
>   
>   	if (cmd == MODE_SENSE) {
> @@ -684,10 +686,10 @@ static void ms_mode_sense(struct rtsx_chip *chip, u8 cmd,
>   	/* Medium Type Code */
>   	if (check_card_ready(chip, lun)) {
>   		if (CHK_MSXC(ms_card)) {
> -			support_format = 1;
> +			support_format = true;
>   			buf[i++] = 0x40;
>   		} else if (CHK_MSPRO(ms_card)) {
> -			support_format = 1;
> +			support_format = true;
>   			buf[i++] = 0x20;
>   		} else {
>   			buf[i++] = 0x10;
> @@ -755,7 +757,7 @@ static int mode_sense(struct scsi_cmnd *srb, struct rtsx_chip *chip)
>   	unsigned int lun = SCSI_LUN(srb);
>   	unsigned int dataSize;
>   	int status;
> -	int pro_formatter_flag;
> +	bool pro_formatter_flag;
>   	unsigned char pageCode, *buf;
>   	u8 card = get_lun_card(chip, lun);
>   
> @@ -767,20 +769,20 @@ static int mode_sense(struct scsi_cmnd *srb, struct rtsx_chip *chip)
>   	}
>   #endif
>   
> -	pro_formatter_flag = 0;
> +	pro_formatter_flag = false;
>   	dataSize = 8;
>   #ifdef SUPPORT_MAGIC_GATE
>   	if ((chip->lun2card[lun] & MS_CARD)) {
>   		if (!card || (card == MS_CARD)) {
>   			dataSize = 108;
>   			if (chip->mspro_formatter_enable)
> -				pro_formatter_flag = 1;
> +				pro_formatter_flag = true;
>   		}
>   	}
>   #else
>   	if (card == MS_CARD) {
>   		if (chip->mspro_formatter_enable) {
> -			pro_formatter_flag = 1;
> +			pro_formatter_flag = true;
>   			dataSize = 108;
>   		}
>   	}
> @@ -2295,7 +2297,8 @@ Exit:
>   static int read_cfg_byte(struct scsi_cmnd *srb, struct rtsx_chip *chip)
>   {
>   	int retval;
> -	u8 func, func_max;
> +	bool func_max;
> +	u8 func;
>   	u16 addr, len;
>   	u8 *buf;
>   
> @@ -2315,9 +2318,9 @@ static int read_cfg_byte(struct scsi_cmnd *srb, struct rtsx_chip *chip)
>   		__func__, func, addr, len);
>   
>   	if (CHK_SDIO_EXIST(chip) && !CHK_SDIO_IGNORED(chip))
> -		func_max = 1;
> +		func_max = true;
>   	else
> -		func_max = 0;
> +		func_max = false;
>   
>   	if (func > func_max) {
>   		set_sense_type(chip, SCSI_LUN(srb),
> @@ -2349,7 +2352,8 @@ static int read_cfg_byte(struct scsi_cmnd *srb, struct rtsx_chip *chip)
>   static int write_cfg_byte(struct scsi_cmnd *srb, struct rtsx_chip *chip)
>   {
>   	int retval;
> -	u8 func, func_max;
> +	bool func_max;
> +	u8 func;
>   	u16 addr, len;
>   	u8 *buf;
>   
> @@ -2369,9 +2373,9 @@ static int write_cfg_byte(struct scsi_cmnd *srb, struct rtsx_chip *chip)
>   		__func__, func, addr);
>   
>   	if (CHK_SDIO_EXIST(chip) && !CHK_SDIO_IGNORED(chip))
> -		func_max = 1;
> +		func_max = true;
>   	else
> -		func_max = 0;
> +		func_max = false;
>   
>   	if (func > func_max) {
>   		set_sense_type(chip, SCSI_LUN(srb),
> diff --git a/drivers/staging/rts5208/sd.c b/drivers/staging/rts5208/sd.c
> index c28a927..62bf570 100644
> --- a/drivers/staging/rts5208/sd.c
> +++ b/drivers/staging/rts5208/sd.c
> @@ -791,7 +791,7 @@ static int sd_change_phase(struct rtsx_chip *chip, u8 sample_point, u8 tune_dir)
>   	u16 SD_VP_CTL, SD_DCMPS_CTL;
>   	u8 val;
>   	int retval;
> -	int ddr_rx = 0;
> +	bool ddr_rx = false;
>   
>   	dev_dbg(rtsx_dev(chip), "sd_change_phase (sample_point = %d, tune_dir = %d)\n",
>   		sample_point, tune_dir);
> @@ -800,7 +800,7 @@ static int sd_change_phase(struct rtsx_chip *chip, u8 sample_point, u8 tune_dir)
>   		SD_VP_CTL = SD_VPRX_CTL;
>   		SD_DCMPS_CTL = SD_DCMPS_RX_CTL;
>   		if (CHK_SD_DDR50(sd_card))
> -			ddr_rx = 1;
> +			ddr_rx = true;
>   	} else {
>   		SD_VP_CTL = SD_VPTX_CTL;
>   		SD_DCMPS_CTL = SD_DCMPS_TX_CTL;
> @@ -1121,7 +1121,7 @@ static int sd_check_switch(struct rtsx_chip *chip,
>   {
>   	int retval;
>   	int i;
> -	int switch_good = 0;
> +	bool switch_good = false;
>   
>   	for (i = 0; i < 3; i++) {
>   		if (detect_card_cd(chip, SD_CARD) != STATUS_SUCCESS) {
> @@ -1137,7 +1137,7 @@ static int sd_check_switch(struct rtsx_chip *chip,
>   			retval = sd_check_switch_mode(chip, SD_SWITCH_MODE,
>   					func_group, func_to_switch, bus_width);
>   			if (retval == STATUS_SUCCESS) {
> -				switch_good = 1;
> +				switch_good = true;
>   				break;
>   			}
>   
> @@ -1524,7 +1524,8 @@ static u8 sd_search_final_phase(struct rtsx_chip *chip, u32 phase_map,
>   	struct sd_info *sd_card = &(chip->sd_card);
>   	struct timing_phase_path path[MAX_PHASE + 1];
>   	int i, j, cont_path_cnt;
> -	int new_block, max_len, final_path_idx;
> +	bool new_block;
> +	int max_len, final_path_idx;
>   	u8 final_phase = 0xFF;
>   
>   	if (phase_map == 0xFFFFFFFF) {
> @@ -1537,12 +1538,12 @@ static u8 sd_search_final_phase(struct rtsx_chip *chip, u32 phase_map,
>   	}
>   
>   	cont_path_cnt = 0;
> -	new_block = 1;
> +	new_block = true;
>   	j = 0;
>   	for (i = 0; i < MAX_PHASE + 1; i++) {
>   		if (phase_map & (1 << i)) {
>   			if (new_block) {
> -				new_block = 0;
> +				new_block = false;
>   				j = cont_path_cnt++;
>   				path[j].start = i;
>   				path[j].end = i;
> @@ -1550,7 +1551,7 @@ static u8 sd_search_final_phase(struct rtsx_chip *chip, u32 phase_map,
>   				path[j].end = i;
>   			}
>   		} else {
> -			new_block = 1;
> +			new_block = true;
>   			if (cont_path_cnt) {
>   				int idx = cont_path_cnt - 1;
>   
> @@ -2141,14 +2142,15 @@ static int sd_check_wp_state(struct rtsx_chip *chip)
>   static int reset_sd(struct rtsx_chip *chip)
>   {
>   	struct sd_info *sd_card = &(chip->sd_card);
> -	int retval, i = 0, j = 0, k = 0, hi_cap_flow = 0;
> -	int sd_dont_switch = 0;
> -	int support_1v8 = 0;
> -	int try_sdio = 1;
> +	bool hi_cap_flow = false;
> +	int retval, i = 0, j = 0, k = 0;
> +	bool sd_dont_switch = false;
> +	bool support_1v8 = false;
> +	bool try_sdio = true;
>   	u8 rsp[16];
>   	u8 switch_bus_width;
>   	u32 voltage = 0;
> -	int sd20_mode = 0;
> +	bool sd20_mode = false;
>   
>   	SET_SD(sd_card);
>   
> @@ -2157,7 +2159,7 @@ Switch_Fail:
>   	i = 0;
>   	j = 0;
>   	k = 0;
> -	hi_cap_flow = 0;
> +	hi_cap_flow = false;
>   
>   #ifdef SUPPORT_SD_LOCK
>   	if (sd_card->sd_lock_status & SD_UNLOCK_POW_ON)
> @@ -2217,7 +2219,7 @@ RTY_SD_RST:
>   				SD_RSP_TYPE_R7, rsp, 5);
>   	if (retval == STATUS_SUCCESS) {
>   		if ((rsp[4] == 0xAA) && ((rsp[3] & 0x0f) == 0x01)) {
> -			hi_cap_flow = 1;
> +			hi_cap_flow = true;
>   			voltage = SUPPORT_VOLTAGE | 0x40000000;
>   		}
>   	}
> @@ -2272,10 +2274,10 @@ RTY_SD_RST:
>   		else
>   			CLR_SD_HCXC(sd_card);
>   
> -		support_1v8 = 0;
> +		support_1v8 = false;
>   	} else {
>   		CLR_SD_HCXC(sd_card);
> -		support_1v8 = 0;
> +		support_1v8 = false;
>   	}
>   	dev_dbg(rtsx_dev(chip), "support_1v8 = %d\n", support_1v8);
>   
> @@ -2361,7 +2363,7 @@ SD_UNLOCK_ENTRY:
>   		TRACE_RET(chip, STATUS_FAIL);
>   
>   	if (!(sd_card->raw_csd[4] & 0x40))
> -		sd_dont_switch = 1;
> +		sd_dont_switch = true;
>   
>   	if (!sd_dont_switch) {
>   		if (sd20_mode) {
> @@ -2378,16 +2380,16 @@ SD_UNLOCK_ENTRY:
>   			retval = sd_switch_function(chip, switch_bus_width);
>   			if (retval != STATUS_SUCCESS) {
>   				sd_init_power(chip);
> -				sd_dont_switch = 1;
> -				try_sdio = 0;
> +				sd_dont_switch = true;
> +				try_sdio = false;
>   
>   				goto Switch_Fail;
>   			}
>   		} else {
>   			if (support_1v8) {
>   				sd_init_power(chip);
> -				sd_dont_switch = 1;
> -				try_sdio = 0;
> +				sd_dont_switch = true;
> +				try_sdio = false;
>   
>   				goto Switch_Fail;
>   			}
> @@ -2433,8 +2435,8 @@ SD_UNLOCK_ENTRY:
>   				if (retval != STATUS_SUCCESS)
>   					TRACE_RET(chip, STATUS_FAIL);
>   
> -				try_sdio = 0;
> -				sd20_mode = 1;
> +				try_sdio = false;
> +				sd20_mode = true;
>   				goto Switch_Fail;
>   			}
>   		}
> @@ -2458,8 +2460,8 @@ SD_UNLOCK_ENTRY:
>   					if (retval != STATUS_SUCCESS)
>   						TRACE_RET(chip, STATUS_FAIL);
>   
> -					try_sdio = 0;
> -					sd20_mode = 1;
> +					try_sdio = false;
> +					sd20_mode = true;
>   					goto Switch_Fail;
>   				}
>   			}
> @@ -3702,7 +3704,7 @@ int sd_execute_no_data(struct scsi_cmnd *srb, struct rtsx_chip *chip)
>   	unsigned int lun = SCSI_LUN(srb);
>   	int retval, rsp_len;
>   	u8 cmd_idx, rsp_type;
> -	u8 standby = 0, acmd = 0;
> +	bool standby = false, acmd = false;
>   	u32 arg;
>   
>   	if (!sd_card->sd_pass_thru_en) {
> @@ -3722,10 +3724,10 @@ int sd_execute_no_data(struct scsi_cmnd *srb, struct rtsx_chip *chip)
>   
>   	cmd_idx = srb->cmnd[2] & 0x3F;
>   	if (srb->cmnd[1] & 0x02)
> -		standby = 1;
> +		standby = true;
>   
>   	if (srb->cmnd[1] & 0x01)
> -		acmd = 1;
> +		acmd = true;
>   
>   	arg = ((u32)srb->cmnd[3] << 24) | ((u32)srb->cmnd[4] << 16) |
>   		((u32)srb->cmnd[5] << 8) | srb->cmnd[6];
> @@ -3812,9 +3814,10 @@ int sd_execute_read_data(struct scsi_cmnd *srb, struct rtsx_chip *chip)
>   	struct sd_info *sd_card = &(chip->sd_card);
>   	unsigned int lun = SCSI_LUN(srb);
>   	int retval, rsp_len, i;
> -	int cmd13_checkbit = 0, read_err = 0;
> +	int cmd13_checkbit = 0;
> +	bool read_err = false;
>   	u8 cmd_idx, rsp_type, bus_width;
> -	u8 send_cmd12 = 0, standby = 0, acmd = 0;
> +	bool standby = false, send_cmd12 = false, acmd = false;
>   	u32 data_len;
>   
>   	if (!sd_card->sd_pass_thru_en) {
> @@ -3834,13 +3837,13 @@ int sd_execute_read_data(struct scsi_cmnd *srb, struct rtsx_chip *chip)
>   
>   	cmd_idx = srb->cmnd[2] & 0x3F;
>   	if (srb->cmnd[1] & 0x04)
> -		send_cmd12 = 1;
> +		send_cmd12 = true;
>   
>   	if (srb->cmnd[1] & 0x02)
> -		standby = 1;
> +		standby = true;
>   
>   	if (srb->cmnd[1] & 0x01)
> -		acmd = 1;
> +		acmd = true;
>   
>   	data_len = ((u32)srb->cmnd[7] << 16) | ((u32)srb->cmnd[8]
>   						<< 8) | srb->cmnd[9];
> @@ -3915,7 +3918,7 @@ int sd_execute_read_data(struct scsi_cmnd *srb, struct rtsx_chip *chip)
>   		retval = sd_read_data(chip, SD_TM_NORMAL_READ, cmd, 5, byte_cnt,
>   				       blk_cnt, bus_width, buf, data_len, 2000);
>   		if (retval != STATUS_SUCCESS) {
> -			read_err = 1;
> +			read_err = true;
>   			kfree(buf);
>   			rtsx_clear_sd_error(chip);
>   			TRACE_GOTO(chip, SD_Execute_Read_Cmd_Failed);
> @@ -3964,7 +3967,7 @@ int sd_execute_read_data(struct scsi_cmnd *srb, struct rtsx_chip *chip)
>   					scsi_bufflen(srb), scsi_sg_count(srb),
>   					DMA_FROM_DEVICE, 10000);
>   		if (retval < 0) {
> -			read_err = 1;
> +			read_err = true;
>   			rtsx_clear_sd_error(chip);
>   			TRACE_GOTO(chip, SD_Execute_Read_Cmd_Failed);
>   		}
> @@ -4041,9 +4044,10 @@ int sd_execute_write_data(struct scsi_cmnd *srb, struct rtsx_chip *chip)
>   	struct sd_info *sd_card = &(chip->sd_card);
>   	unsigned int lun = SCSI_LUN(srb);
>   	int retval, rsp_len, i;
> -	int cmd13_checkbit = 0, write_err = 0;
> +	int cmd13_checkbit = 0;
> +	bool write_err = false;
>   	u8 cmd_idx, rsp_type;
> -	u8 send_cmd12 = 0, standby = 0, acmd = 0;
> +	bool standby = false, send_cmd12 = false, acmd = false;
>   	u32 data_len, arg;
>   #ifdef SUPPORT_SD_LOCK
>   	int lock_cmd_fail = 0;
> @@ -4068,13 +4072,13 @@ int sd_execute_write_data(struct scsi_cmnd *srb, struct rtsx_chip *chip)
>   
>   	cmd_idx = srb->cmnd[2] & 0x3F;
>   	if (srb->cmnd[1] & 0x04)
> -		send_cmd12 = 1;
> +		send_cmd12 = true;
>   
>   	if (srb->cmnd[1] & 0x02)
> -		standby = 1;
> +		standby = true;
>   
>   	if (srb->cmnd[1] & 0x01)
> -		acmd = 1;
> +		acmd = true;
>   
>   	data_len = ((u32)srb->cmnd[7] << 16) | ((u32)srb->cmnd[8]
>   						<< 8) | srb->cmnd[9];
> @@ -4247,7 +4251,7 @@ int sd_execute_write_data(struct scsi_cmnd *srb, struct rtsx_chip *chip)
>   	}
>   
>   	if (retval < 0) {
> -		write_err = 1;
> +		write_err = true;
>   		rtsx_clear_sd_error(chip);
>   		TRACE_GOTO(chip, SD_Execute_Write_Cmd_Failed);
>   	}

Re:

[Globale Trust Company]

-- 
Sind Sie ein Unternehmer Mann oder eine Frau? Sind Sie in finanziellen
Schwierigkeiten, oder haben Sie finanzielle Mittel benötigen, um Ihr
eigenes Unternehmen gründen? Brauchen Sie noch einen Autokredit? Sie
haben einen niedrigen Kredit-Score und Sie finden es schwierig, ein
Darlehen von lokalen Banken und anderen Finanzinstituten zu bekommen?
Sie benötigen ein Darlehen aus irgendeinem Grund, Gründe, wie .:
a) persönliche Darlehen, Ausbau des Geschäfts.
b) Unternehmertum und Bildung.
(c) Schuldenkonsolidierung).