Re: Kernel module_list

[Allison]

Right now , I am just learn. trying a test module that lists out all the modules

Allison

Arjan van de Ven wrote:
> On Thu, 2005-04-14 at 19:53 +, Allison wrote:
> > 
> > I am trying to access the module list kernel data structure from a
> > kernel module. If I gather correctly, module_list is the symbol that
> > is the head pointer of this list.
> 
> can you explain what you want to do with this symbol ?
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.12-rc2: >100% memory usage

[Nick Piggin]

On Thu, 2005-04-14 at 22:20 -0700, Randy.Dunlap wrote:
> On Fri, 15 Apr 2005 14:59:05 +1000 Nick Piggin wrote:
> 
> | On Fri, 2005-04-15 at 12:48 +0800, Michael Deegan wrote:
> | > Hi folks,
> | > 
> | > I noticed something unusual on my home desktop machine (K6II, 448M RAM, 
> runs
> | > KDE, samba, nfsd. 2.6.12-rc2 on Debian sarge). The machine seems to feel
> | > slightly sluggish; it seems to swap a fair bit more than it did under
> | > 2.6.11, but at the same time it's not actually using more swap that it 
> used
> | > to. The large numbers are slowly growing larger too. The biggest spamd was
> | > only 156% of memory yesterday. Normally it's only my xserver (and
> | > occasionally konqueror) that manages to grab more than 10% of memory...
> | 
> | FWIW, me too :P
> | 
> | I think there is a memory leak in recent 2.6.12 kernels.
> | At least on my desktop there is (although it has some of
> | my own patches and I've been too lazy to do more work on
> | it so I haven't reported it).
> | 
> | It seems to be leaking `size-4096` slabs somewhere.
> 
> This one or yet another one?
> http://marc.theaimsgroup.com/?l=linux-kernel=111264601928365=2
> 
> 

No, another one. Much faster. A few kernel compiles and I have
to reboot (only 256MB RAM, though).

But as I said, not quite a vanilla kernel. I'll have to get
motivated and compile a plain one and try to work it out. I
was hoping someone else would do it ;)




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

Re: 2.6.12-rc2: >100% memory usage

[Randy.Dunlap]

On Fri, 15 Apr 2005 14:59:05 +1000 Nick Piggin wrote:

| On Fri, 2005-04-15 at 12:48 +0800, Michael Deegan wrote:
| > Hi folks,
| > 
| > I noticed something unusual on my home desktop machine (K6II, 448M RAM, runs
| > KDE, samba, nfsd. 2.6.12-rc2 on Debian sarge). The machine seems to feel
| > slightly sluggish; it seems to swap a fair bit more than it did under
| > 2.6.11, but at the same time it's not actually using more swap that it used
| > to. The large numbers are slowly growing larger too. The biggest spamd was
| > only 156% of memory yesterday. Normally it's only my xserver (and
| > occasionally konqueror) that manages to grab more than 10% of memory...
| 
| FWIW, me too :P
| 
| I think there is a memory leak in recent 2.6.12 kernels.
| At least on my desktop there is (although it has some of
| my own patches and I've been too lazy to do more work on
| it so I haven't reported it).
| 
| It seems to be leaking `size-4096` slabs somewhere.

This one or yet another one?
http://marc.theaimsgroup.com/?l=linux-kernel=111264601928365=2


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

Re: [INFO] Kernel strict versioning

[Al Viro]

On Thu, Apr 14, 2005 at 10:23:46PM -0500, Franco Sensei wrote:
> Al Viro wrote:
> >Elegant.  Very elegant.  Admirable exercise in misdirection - the word
> >"third-party" used to conflate all things non-kernel with 3rd party
> >kernel modifications.  Followed by appeals to civic obligations, no less.
> 
> Don't you think you're a little bit... disappointing?

No, just allergic to that kind of rethorics.

> >Of course, that doesn't change the simple fact: "outside world" is not
> >a single entity.  There are API warranties for userland.  There's no
> >API warranties for 3rd-party kernel modifications.
> 
> My question is, why?

See below.
 
> Technical reasons? Unaffordable efforts? I bet on the last.

The simple fact that authors of 3rd-party modules do not *want* a sane
API.  Current set of objects available to them is huge and most of that
pile had been exported only because
1) somebody couldn't be bothered by thinking and just exported
whatever random kernel functions they happened to use.  Many of these
exports could be avoided by using an already exported function instead
of reimplementing it and exporting low-level functions used in that
reimplementation.  Many had been result of copying an already existing
stuff and doing local modifications in a copy, instead of figuring out
the sane way to do it in generic code.  And almost always these guys
did not say "we want to do this and that for this and that; let's see
how to do it sanely".  It was "here's a patch adding exports we need
for our module".
2) such patches had met very low resistance for quite a while.

So what we have right now is a random slice of kernel objects that had
been exported for hell knows what reasons.  It's not an interface in any
sane meaning of thw word and preserving that set is both hopeless and
crippling.  And 3rd-party module writers will *not* be happy with managable
set of exports, if the past experience is anything to judge by.

> >Moreover, unless you manage to get the list of functions and data
> >types exported to modules somewhere within an order of magnitude
> >from the corresponding userland list (i.e. syscalls and types involved),
> >you are asking everybody to increase the size of API being preserved
> >at least tenfold.  As it is, that would be "by factor of 200-300".
> 
> I'm probably talking about the design of api.

And I am talking about the existing modules depending on something that
is not and never had been an API.  We can design whatever API we want,
but keeping it stable won't help you at all - modules are using the mess
they are using.  And any attempt to rip that crap out doesn't make them
happy or willing to cooperate, even when saner replacements are already
there and had been around for longer than the exports that get removed.
 
> >If you manage to convince module authors to live with the export list
> >cut down by that much - come back and we'll have something to talk
> >about.
> 
> An elegant way of saying ``shut your mouth''?

No.  "You are talking to wrong people; we can't help you until you pull off
a miracle and convince module authors to sanitize their codebase wrt set
of objects being used by it".

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

Re: 2.6.12-rc2: >100% memory usage

[Nick Piggin]

On Fri, 2005-04-15 at 12:48 +0800, Michael Deegan wrote:
> Hi folks,
> 
> I noticed something unusual on my home desktop machine (K6II, 448M RAM, runs
> KDE, samba, nfsd. 2.6.12-rc2 on Debian sarge). The machine seems to feel
> slightly sluggish; it seems to swap a fair bit more than it did under
> 2.6.11, but at the same time it's not actually using more swap that it used
> to. The large numbers are slowly growing larger too. The biggest spamd was
> only 156% of memory yesterday. Normally it's only my xserver (and
> occasionally konqueror) that manages to grab more than 10% of memory...

FWIW, me too :P

I think there is a memory leak in recent 2.6.12 kernels.
At least on my desktop there is (although it has some of
my own patches and I've been too lazy to do more work on
it so I haven't reported it).

It seems to be leaking `size-4096` slabs somewhere.

-- 
SUSE Labs, Novell Inc.



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

2.6.12-rc2: >100% memory usage

[Michael Deegan]

Hi folks,

I noticed something unusual on my home desktop machine (K6II, 448M RAM, runs
KDE, samba, nfsd. 2.6.12-rc2 on Debian sarge). The machine seems to feel
slightly sluggish; it seems to swap a fair bit more than it did under
2.6.11, but at the same time it's not actually using more swap that it used
to. The large numbers are slowly growing larger too. The biggest spamd was
only 156% of memory yesterday. Normally it's only my xserver (and
occasionally konqueror) that manages to grab more than 10% of memory...

Cutting and pasting from top:

   top - 12:20:17 up 3 days, 17:00,  6 users,  load average: 0.91, 1.25, 1.35
   Tasks: 162 total,   3 running, 158 sleeping,   1 stopped,   0 zombie
   Cpu(s): 13.9% us, 11.1% sy, 37.0% ni, 27.8% id,  0.0% wa,  0.0% hi, 10.2% si
   Mem:450340k total,   443452k used, 6888k free, 1740k buffers
   Swap:  220k total,   384300k used,  1615720k free,22248k cached
   
 PID USER  NI  VIRT  RES SWAP  SHR S %CPU %MEMTIME+  CODE DATA 
COMMAND
2489 root   0 40088 1.0g  4.0 999m S  0.0 232.7   5:15.94  996  35m 
spamd child
2485 root   0 38336 954m  4.0 933m S  0.0 217.0   5:03.79  996  33m 
spamd child
2488 root   0 38528 949m  4.0 932m S  0.0 216.0   4:42.07  996  33m 
spamd child
2486 root   0 38436 932m  4.0 912m S  0.0 212.1   5:15.02  996  33m 
spamd child
2487 root   0 38660 914m  4.0 900m S  0.0 207.9   4:15.34  996  33m 
spamd child
6741 root   0  128m 476m  4.0 470m R 14.6 108.3 790:48.57 1512  43m 
/usr/X11R6/bin/X -nolisten tcp -auth /var/run/xauth/A:0-W1z1fb vt7
6867 michael0 71600 369m  4.0 361m S  4.6 84.1 227:17.70   40  20m 
konqueror [kdeinit] konqueror -session 11c0a8012a0001104403557

/proc/meminfo:

   MemTotal:   450340 kB
   MemFree:  5128 kB
   Buffers:   568 kB
   Cached:  21932 kB
   SwapCached: 120448 kB
   Active: 153944 kB
   Inactive: 2384 kB
   HighTotal:   0 kB
   HighFree:0 kB
   LowTotal:   450340 kB
   LowFree:  5128 kB
   SwapTotal: 220 kB
   SwapFree:  1616164 kB
   Dirty:  48 kB
   Writeback:   0 kB
   Mapped: 152972 kB
   Slab:   273160 kB
   CommitLimit:   2225188 kB
   Committed_AS:   918036 kB
   PageTables:   3180 kB
   VmallocTotal:   581612 kB
   VmallocUsed: 22692 kB
   VmallocChunk:   555496 kB

/proc/2489/status:

   Name:   spamd
   State:  S (sleeping)
   SleepAVG:   78%
   Tgid:   2489
   Pid:2489
   PPid:   1775
   TracerPid:  0
   Uid:0   0   0   0
   Gid:0   0   0   0
   FDSize: 256
   Groups: 1000
   VmSize:40104 kB
   VmLck: 0 kB
   VmRSS:   1033176 kB
   VmData:35772 kB
   VmStk:88 kB
   VmExe:   996 kB
   VmLib:  3060 kB
   VmPTE:52 kB
   Threads:1
   SigQ:   0/3584
   SigPnd: 
   ShdPnd: 
   SigBlk: 
   SigIgn: 0087
   SigCgt: 8000
   CapInh: 
   CapPrm: feff
   CapEff: feff

pmap output seems normal too (total ~40M).

Any ideas on what's happening? Or is everything actually normal and I've
just made an incorrect assumption somewhere? (in which case I'd like to know
what definition of 'resident' I'm supposed to be using :P)

Thanks,

-MD

-- 
---
Michael Deegan   Hugaholic  http://wibble.darktech.org/gallery/
- Nyy Tybel Gb Gur Ulcabgbnq! -
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

New kernel thread

[Allison]

Hi,

I need to create a new kernel thread that will stay alive as long as
the system is up. This should be created as soon as the system boots. 
I need this thread to perform a specific task.

I am not very familiar with the code. Where should I put this thread
creation and my function code (I mean which file ?)? Do I use
kernel_thread function to create a new thread ?

Do I need to cleanup when the system exists ? 
What function should I call ?

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

Re: {PATCH] Fix IBM EMAC driver ioctl bug

[Eugene Surovegin]

On Thu, Apr 14, 2005 at 11:20:32AM -0700, Geoff Levand wrote:
> Fix IBM EMAC driver ioctl bug.
> 
> I found IBM EMAC driver bug.
> So mii-tool command print wrong status.
> 
>   # mii-tool
>   eth0: 10 Mbit, half duplex, no link
>   eth1: 10 Mbit, half duplex, no link
> 
> I can get correct status on fixed kernel.
> 
>   # mii-tool
>   eth0: negotiated 100baseTx-FD, link okZZ
>   eth1: negotiated 100baseTx-FD, link ok
> 

There is a problem with this patch. I'm aware of this problem for 
quite some time, but chose to keep the current code.

This IOCTL implementation has been here for many years in all 
revisions of the driver, so I think we should keep it as is, because 
some software could rely on it, and your change will break it. 

And all new code should use ethtool anyway :).

-- 
Eugene


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

[PATCH] Platform SMIs and their interferance with tsc based delay calibration

[Venkatesh Pallipadi]

Missed copying to the list earlier... sorry if this mail is a duplicate.


Following up on earlier thread
http://www.ussg.iu.edu/hypermail/linux/kernel/0501.3/index.html#1694

Changes from the earlier version:
(1) Now this new routine is generic
(2) Handles both i386 amd x86-64
(3) Repeates the delay calibration 5 times to get good value


Thanks,
Venki 



Issue:
Current tsc based delay_calibration can result in significant errors in 
loops_per_jiffy count when the platform events like SMIs 
(System Management Interrupts that are non-maskable) are present. This could 
lead to potential kernel panic(). This issue is becoming more visible with 2.6 
kernel (as default HZ is 1000) and on platforms with higher SMI handling 
latencies. During the boot time, SMIs are mostly used by BIOS (for things 
like legacy keyboard emulation).

Description:
The psuedocode for current delay calibration with tsc based delay looks like
(0) Estimate a value for loops_per_jiffy
(1) While (loops_per_jiffy estimate is accurate enough)
(2)   wait for jiffy transition (jiffy1)
(3)   Note down current tsc (tsc1)
(4)   loop until tsc becomes tsc1 + loops_per_jiffy
(5)   check whether jiffy changed since jiffy1 or not and refine 
loops_per_jiffy estimate

Consider the following cases
Case 1:
If SMIs happen between (2) and (3) above, we can end up with a 
loops_per_jiffy value that is too low. This results in shorted delays and 
kernel can panic () during boot (Mostly at IOAPIC timer initialization 
timer_irq_works() as we don't have enough timer interrupts in a specified 
interval).

Case 2:
If SMIs happen between (3) and (4) above, then we can end up with a 
loops_per_jiffy value that is too high. And with current i386 code, too 
high lpj value (greater than 17M) can result in a overflow in 
delay.c:__const_udelay() again resulting in shorter delay and panic().


Solution:
The patch below makes the calibration routine aware of asynchronous events 
like SMIs. We increase the delay calibration time and also identify any 
significant errors (greater than 12.5%) in the calibration and notify it to 
user.

Patch below changes both i386 and x86-64 architectures to use this 
new and improved calibrate_delay_direct() routine.


Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>


diff -purN  linux-2.6.12-rc2-mm3//arch/i386/kernel/timers/timer.c.orig 
linux-2.6.12-rc2-mm3//arch/i386/kernel/timers/timer.c
--- linux-2.6.12-rc2-mm3//arch/i386/kernel/timers/timer.c.orig  2005-03-01 
23:38:26.0 -0800
+++ linux-2.6.12-rc2-mm3//arch/i386/kernel/timers/timer.c   2005-04-14 
17:06:04.0 -0700
@@ -64,3 +64,12 @@ struct timer_opts* __init select_timer(v
panic("select_timer: Cannot find a suitable timer\n");
return NULL;
 }
+
+int read_current_timer(unsigned long *timer_val)
+{
+   if (cur_timer->read_timer) {
+   *timer_val = cur_timer->read_timer();
+   return 0;
+   }
+   return -1;
+}
diff -purN  linux-2.6.12-rc2-mm3//arch/i386/kernel/timers/common.c.orig 
linux-2.6.12-rc2-mm3//arch/i386/kernel/timers/common.c
--- linux-2.6.12-rc2-mm3//arch/i386/kernel/timers/common.c.orig 2005-04-14 
17:03:42.0 -0700
+++ linux-2.6.12-rc2-mm3//arch/i386/kernel/timers/common.c  2005-04-14 
17:07:35.0 -0700
@@ -139,6 +139,15 @@ bad_calibration:
 }
 #endif
 
+ 
+unsigned long read_timer_tsc(void)
+{
+   unsigned long retval;
+   rdtscl(retval);
+   return retval;
+}
+
+
 /* calculate cpu_khz */
 void init_cpu_khz(void)
 {
diff -purN  linux-2.6.12-rc2-mm3//arch/i386/kernel/timers/timer_tsc.c.orig 
linux-2.6.12-rc2-mm3//arch/i386/kernel/timers/timer_tsc.c
--- linux-2.6.12-rc2-mm3//arch/i386/kernel/timers/timer_tsc.c.orig  
2005-04-14 17:03:42.0 -0700
+++ linux-2.6.12-rc2-mm3//arch/i386/kernel/timers/timer_tsc.c   2005-04-14 
17:06:04.0 -0700
@@ -572,6 +572,7 @@ static struct timer_opts timer_tsc = {
.get_offset = get_offset_tsc,
.monotonic_clock = monotonic_clock_tsc,
.delay = delay_tsc,
+   .read_timer = read_timer_tsc,
 };
 
 struct init_timer_opts __initdata timer_tsc_init = {
diff -purN  linux-2.6.12-rc2-mm3//arch/i386/kernel/timers/timer_hpet.c.orig 
linux-2.6.12-rc2-mm3//arch/i386/kernel/timers/timer_hpet.c
--- linux-2.6.12-rc2-mm3//arch/i386/kernel/timers/timer_hpet.c.orig 
2005-04-14 17:03:28.0 -0700
+++ linux-2.6.12-rc2-mm3//arch/i386/kernel/timers/timer_hpet.c  2005-04-14 
17:06:04.0 -0700
@@ -183,6 +183,7 @@ static struct timer_opts timer_hpet = {
.get_offset =   get_offset_hpet,
.monotonic_clock =  monotonic_clock_hpet,
.delay =delay_hpet,
+   .read_timer =   read_timer_tsc,
 };
 
 struct init_timer_opts __initdata timer_hpet_init = {
diff -purN  linux-2.6.12-rc2-mm3//arch/i386/kernel/timers/timer_pm.c.orig 
linux-2.6.12-rc2-mm3//arch/i386/kernel/timers/timer_pm.c
--- 

Re: [PATCH] sched: fix never executed code due to expression always false

[Nick Piggin]

On Fri, 2005-04-15 at 12:59 +1000, Herbert Xu wrote:
> Jesper Juhl <[EMAIL PROTECTED]> wrote:
> >
> > -   if (unlikely((long long)now - prev->timestamp < 0))
> > +   if (unlikely(((long long)now - (long long)prev->timestamp) 
> > < 0))
> 
> You can write this as
> 
> (long long)(now - prev->timestamp)
> 

True. Combined that with Matt's suggestion, and we probably have
the cleanest solution. Thanks.




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

Re: Linux support for IBM ThinkPad Disk shock prevention update...

[Alejandro Bonilla]

05-04-14 at 16:58 -0400, Shawn Starr wrote:
We just need to figure
out to get the specs from IBM
   

Best bet is probably reverse engineering it...
 

Lee, 

I know this is far from easy... but, What do we need to do this? I haven't
seen such a cooler feature in a Thinkpad like the HDAPS. (Well, maybe the
fingerprint reader) But, how can we / I help, if this is ever done?
   

Please see:
http://dxr3.sourceforge.net/re.html
I have discovered several previously unknown emu10k1 hardware features
using this procedure to reverse engineer the Windows drivers, including
a per channel half loop interrupt, and added support to the Linux driver
for some of them.
It may be much easier to find the read and write register subroutines
than in the above guide.  The Windows driver I was working with had
exactly one subroutine that used the inb, inl, inw, outb, outw, outl
instructions, so it was trivial to set breakpoints to log all the port
I/O.  I later found it was even easier, the version of SoftIce I was
using allows you to set I/O breakpoints, so all you need to start
logging the register activity is the port.
I had a little trouble loading the IDA symbols into SoftICE at first,
just because the first few scripts I found on the net didn't work.
Some devices use memory mapped IO, I have no idea how you would RE
these.  Maybe someone else has some pointers?
Lee
 

The only thing I got back from IBM was:
  Please be advised, that the e-mail forum you
  have reached is provided for non-technical
  support and web registration issues of IBM.
  ave reached is provided for non-technical
  Please send your research proposal to IBM at
  T.J Watson Research Center at 914-945-3167.
I don't think I'm l33t enough like to call there and discuss for what we 
are looking for. Also they will probably tell me, " Ahh, well we 
currenly don't want to release anything because of legal issue" (Like I 
was already told)

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

Re: IBM Thinkpad T42 - Looking for a Developer.

[Alejandro Bonilla]

This is located in my home PC, Won't be the fastest downloads...
http://wifitux.com/finger/
 

Under what terms did you obtain these documents and from where? Are 
they completely freely distributable or are there strings attached?
   

I emailed the guys and they told me, "Hey, here you go, let me know if you
want more information"
I guess it can't be more distributable. But as far as I got to read. The
documents don't have too much information like for us to do a great Job. I
think it also requires the making of a firmware.
I don't want to dissapoint you, but I hope I'm lost and that a driver can be
done out of this.
 

There were two PDF documents.
The more useful one tells that there are two possible interfaces:
- Async serial
- USB
Could you show what/sbin/lsusb -vvtells in your T42 ?
Do that without external devices attached.
   

I'm appending the lsusb -vv from my Thinkpad T43 for comparison.  This
also has a builtin USB fingerprint scanner, but I don't know if it is
the same one as used on the T42.  It is "Bus 004 Device 002: ID
0483:2016 SGS Thomson Microelectronics".  There are no other USB devices
connecting.
 

Matti,
   Where do we stand here? Now that you have two of those outputs, so I 
can have some hope... Do you think we can make the driver for this hardware?

   How about the firmware that the documents mention? Could there be a 
layer in the hardware itself that might prevents us from reading the 
fingerprint image?

   Will BioAPI help us at all, or the best approach here is not to make 
dll wrapping?

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

question about returning of a child process

[Tomko]

Hi all,
What is  the first code the new born child process run after it is 
forked by the system call and being schduled into the CPU to run ? what 
i concerned is , kernel will schdule once when leaving the system call 
for returning father process, will kernel schdule once again when 
leaving the systemcall for child process if the child process return 
code is inside the kernel space?

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

Re: [PATCH] sched: fix never executed code due to expression always false

[Herbert Xu]

Jesper Juhl <[EMAIL PROTECTED]> wrote:
>
> -   if (unlikely((long long)now - prev->timestamp < 0))
> +   if (unlikely(((long long)now - (long long)prev->timestamp) < 
> 0))

You can write this as

(long long)(now - prev->timestamp)

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sched: fix never executed code due to expression always false

[Matt Mackall]

On Fri, Apr 15, 2005 at 10:23:11AM +1000, Nick Piggin wrote:
> Jesper Juhl wrote:
> 
> >
> >As per this patch perhaps? : 
> >
> 
> Thanks. I'll make sure it gets to the right place if nobody picks it up.

Perhaps this ought to be wrapped up in sched_clock_before() or some
such.

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

Re: Kernel module_list

[Coywolf Qi Hunt]

On Thu, Apr 14, 2005 at 08:48:42PM +, Allison wrote:
> I am trying to simply print out the module names and code sizes.
> I am just learning how to rtraverse these data structures.

Just read /proc/modules

Coywolf

> 
> Also, on what basis is the decision made whether to export a symbol or not ?
> 
> thanks,
> Allison
> 
> Arjan van de Ven wrote:
> > On Thu, 2005-04-14 at 19:53 +, Allison wrote:
> > > 
> > > I am trying to access the module list kernel data structure from a
> > > kernel module. If I gather correctly, module_list is the symbol that
> > > is the head pointer of this list.
> > 
> > can you explain what you want to do with this symbol ?
> > 
> > 
> > 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] reiserfs: fix a few 'empty body in an if-statement' warnings.

[Randy.Dunlap]

On Fri, 15 Apr 2005 02:58:54 +0200 (CEST) Jesper Juhl wrote:

| When building with  gcc -W  fs/reiserfs/namei.c:602 has a few warnings 
| about 'empty body in an if-statement'. This patch silences those warnings.

So fix include/linux/reiserfs_xattr.h:
change
#define reiserfs_mark_inode_private(inode)
to
#define reiserfs_mark_inode_private(inode)  do { } while (0)


and not as below.

| Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
| 
| --- linux-2.6.12-rc2-mm3-orig/fs/reiserfs/namei.c 2005-04-11 
21:20:55.0 +0200
| +++ linux-2.6.12-rc2-mm3/fs/reiserfs/namei.c  2005-04-15 02:54:53.0 
+0200
| @@ -352,8 +352,9 @@ static struct dentry * reiserfs_lookup (
|  }
|  
|   /* Propogate the priv_object flag so we know we're in the priv tree */
| - if (is_reiserfs_priv_object (dir))
| + if (is_reiserfs_priv_object (dir)) {
|   reiserfs_mark_inode_private (inode);
| + }
|  }
|  reiserfs_write_unlock(dir->i_sb);
|  if ( retval == IO_ERROR ) {
| @@ -599,8 +600,9 @@ static int reiserfs_create (struct inode
|  
|  reiserfs_write_lock(dir->i_sb);
|  
| -if (locked)
| +if (locked) {
|  reiserfs_write_lock_xattrs (dir->i_sb);
| +}
|  
|  retval = journal_begin(, dir->i_sb, jbegin_count);
|  if (retval) {
| @@ -640,8 +642,9 @@ static int reiserfs_create (struct inode
|  retval = journal_end(, dir->i_sb, jbegin_count) ;
|  
|  out_failed:
| -if (locked)
| +if (locked) {
|  reiserfs_write_unlock_xattrs (dir->i_sb);
| +}
|  reiserfs_write_unlock(dir->i_sb);
|  return retval;
|  }
| @@ -668,8 +671,9 @@ static int reiserfs_mknod (struct inode 
|  
|  reiserfs_write_lock(dir->i_sb);
|  
| -if (locked)
| +if (locked) {
|  reiserfs_write_lock_xattrs (dir->i_sb);
| +}
|  
|  retval = journal_begin(, dir->i_sb, jbegin_count) ;
|  if (retval) {
| @@ -714,8 +718,9 @@ static int reiserfs_mknod (struct inode 
|  retval = journal_end(, dir->i_sb, jbegin_count) ;
|  
|  out_failed:
| -if (locked)
| +if (locked) {
|  reiserfs_write_unlock_xattrs (dir->i_sb);
| +}
|  reiserfs_write_unlock(dir->i_sb);
|  return retval;
|  }
| @@ -743,8 +748,9 @@ static int reiserfs_mkdir (struct inode 
|  locked = reiserfs_cache_default_acl (dir);
|  
|  reiserfs_write_lock(dir->i_sb);
| -if (locked)
| +if (locked) {
|  reiserfs_write_lock_xattrs (dir->i_sb);
| +}
|  
|  retval = journal_begin(, dir->i_sb, jbegin_count) ;
|  if (retval) {
| @@ -799,8 +805,9 @@ static int reiserfs_mkdir (struct inode 
|  d_instantiate(dentry, inode);
|  retval = journal_end(, dir->i_sb, jbegin_count) ;
|  out_failed:
| -if (locked)
| +if (locked) {
|  reiserfs_write_unlock_xattrs (dir->i_sb);
| +}
|  reiserfs_write_unlock(dir->i_sb);
|  return retval;
|  }


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

Re: alsa es1371's joystick functionality broken in 2.6.11-mm4

[Patrick McFarland]

On Thursday 14 April 2005 09:26 pm, Lee Revell wrote:
> On Thu, 2005-04-14 at 21:18 -0400, Patrick McFarland wrote:
> > On Thursday 07 April 2005 07:17 am, Patrick McFarland wrote:
> > > Nope, 2.6.7 is also fubar. Now to 2.6.6.
> >
> > I haven't tested 2.6.6 yet, but 2.6.12-rc2-mm3 is broken too.
>
> There's no point in testing newer kernels if you have yet to find an old
> 2.6 kernel where it works.

I didn't explicitly test it. I just updated my usual running kernel, and it 
just happens that it didn't magically start working again.

> Do you have any evidence that it ever worked with ALSA?  I suspect it's
> always been broken, and that 2.6.8 or 2.6.9 system you referred to was
> using the OSS driver.

Nope, I haven't used OSS in a very very very very long time. Back when I used 
2.4 (which ended when 2.6.1 was released) I used ALSA.

-- 
Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED]
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989


pgpTVVQztmzpm.pgp
Description: PGP signature

Re: Git archive now available

[Darren Williams]

Hi David

On Thu, 14 Apr 2005, David S. Miller wrote:

> On Fri, 15 Apr 2005 10:01:47 +1000
> Darren Williams <[EMAIL PROTECTED]> wrote:
> 
> > Thanks to the team at [EMAIL PROTECTED] we now have a
> > no so complete Git archive at
> > http://www.gelato.unsw.edu.au/archives/git/
> > 
> > If somebody could send me a complete Git mbox I will
> > update the archive with it.
> 
> I just had to unsubscribe [EMAIL PROTECTED]
> because it was bouncing with errors like "hypermail: ...
> this archive looks non-empty but there it no gdbm file"
> 
> So don't get too excited about your archive just yet :-)
Sorry permissions problem should be OK now:)

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

Re: Fortuna

[linux]

> What if someone accesses the seed file directly before the machine
> boots?  Well, either (a) they have broken root already, or (b) have
> direct access to the disk.  In either case, the attacker with such
> powers can just has easily trojan an executable or a kernel, and
> you've got far worse problems to worry about that the piddling worries
> of (cue Gilbert and Sullivan overly dramatic music, ) the
> dreaded state-extension attack.

So the only remaining case is where an attacker can read the random
seed file before boot but can't install any trojans.  Which seems
like an awfully small case.  (Although in some scenarios, passive
attacks are much easier to mount than active ones.)

> Actually, if you check the current random.c code, you'll see that it
> has catastrophic reseeding in its design already.

Yes, I know.  Fortuna's claim to fame is that it tries to achieve that
without explicitly measuring entropy.

> My big concern with Fortuna is that it really is the result of
> cryptographic masturbation.  It fundamentally assumes that crypto
> primitives are secure (when the recent break of MD4, MD5, and now SHA1
> should have been a warning that this is a Bad Idea (tm)), and makes
> assumptions that have no real world significance (assume the attacker
> has enough privileges that he might as well be superuser and can
> trojan your system to a fare-thee-well  now, if you can't recover
> from a state extension attack, your random number generator is fatally
> flawed.)

I'm not a big fan of Fortuna either, but the issues are separate.
I agree that trusting crypto prmitives that you don't have to is a bad
idea.  If my application depends on SHA1 being secure, then I might as
well go ahead and use SHA1 in my PRNG.  But a kernel service doesn't
know what applications are relying on.

(Speaking of which, perhaps it's time, in light of the breaking of MD5,
to revisit the cut-down MD4 routine used in the TCP ISN selection?
I haven't read the MD5 & SHA1 papers in enough detail to understand the
flaw, but perhaps some defenses could be erected?)

But still, all else being equal, an RNG resistant to a state extension
attack *is* preferable to one that's not.  And the catastrophic
reseeding support in /dev/random provides exactly that feature.

What Fortuna tries to do is sidestep the hard problem of entropy
measurement.  And that's very admirable.  It's a very hard thing to do in
general, and the current technique of heuristics plus a lot of derating
is merely adequate.

If a technique could be developed that didn't need an accurate entropy
measurement, then things would be much better.


> In addition, Frotuna is profligate with entropy, and wastes it in
> order to be able make certain claims of being able to recover from a
> state-extension attack.  Hopefully everyone agrees that entropy
> collected from the hardware is precious (especially if you don't have
> special-purpose a hardware RNG), and shouldn't be wasted.  Wasting
> collected entropy for no benefit, only to protect against a largely
> theoretical attack --- where if a bad guy has enough privileges to
> compromise your RNG state, there are far easier ways to compromise
> your entire system, not just the RNG --- is Just Stupid(tm).

Just to be clear, I don't remember it ever throwing entropy away, but
it hoards some for years, thereby making it effectively unavailable.
Any catastrophic reseeding solution has to hold back entropy for some
time.

And I think that, even in the absence of special-purpose RNG hardware,
synchronization jitter on modern GHz+ CPUs is a fruitful source of
entropy.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fs/fcntl.c : don't test unsigned value for less than zero

[Matthew Wilcox]

On Fri, Apr 15, 2005 at 03:07:42AM +0200, Jesper Juhl wrote:
> 'arg' is unsigned so it can never be less than zero, so testing for that 
> is pointless and also generates a warning when building with gcc -W. This 
> patch eliminates the pointless check.

Didn't Linus already reject this one 6 months ago?

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: alsa es1371's joystick functionality broken in 2.6.11-mm4

[Lee Revell]

On Thu, 2005-04-14 at 21:18 -0400, Patrick McFarland wrote:
> On Thursday 07 April 2005 07:17 am, Patrick McFarland wrote:
> > Nope, 2.6.7 is also fubar. Now to 2.6.6.
> 
> I haven't tested 2.6.6 yet, but 2.6.12-rc2-mm3 is broken too.
> 

There's no point in testing newer kernels if you have yet to find an old
2.6 kernel where it works.

Do you have any evidence that it ever worked with ALSA?  I suspect it's
always been broken, and that 2.6.8 or 2.6.9 system you referred to was
using the OSS driver.

Lee

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

Re: alsa es1371's joystick functionality broken in 2.6.11-mm4

[Patrick McFarland]

On Thursday 07 April 2005 07:17 am, Patrick McFarland wrote:
> Nope, 2.6.7 is also fubar. Now to 2.6.6.

I haven't tested 2.6.6 yet, but 2.6.12-rc2-mm3 is broken too.

-- 
Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED]
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989


pgpmsePv0Q4iB.pgp
Description: PGP signature

Re: Question On TSS

[Imanpreet Arora]

Never mind, I was missing something really simple.



On 4/15/05, Imanpreet Arora <[EMAIL PROTECTED]> wrote:
> Hello,
> 
> I am a bit confused about the TSS. The documentation says that it
> includes 3 fields SS0, SS1 and SS2 for privilige levels 0, 1, 2
> respectively. And are set up when a task is first created, I can't
> figure out why these fields are necessary. I think that these fileds
> are necessary when we have moved from PL 3 to PL0 and these would
> contain information about upper 3 stacks so that information can be
> retrived.

-- 

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

[PATCH] fs/fcntl.c : don't test unsigned value for less than zero

[Jesper Juhl]

'arg' is unsigned so it can never be less than zero, so testing for that 
is pointless and also generates a warning when building with gcc -W. This 
patch eliminates the pointless check.

Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>

--- linux-2.6.12-rc2-mm3-orig/fs/fcntl.c2005-04-11 21:20:50.0 
+0200
+++ linux-2.6.12-rc2-mm3/fs/fcntl.c 2005-04-15 03:03:00.0 +0200
@@ -308,7 +308,7 @@ static long do_fcntl(int fd, unsigned in
break;
case F_SETSIG:
/* arg == 0 restores default behaviour. */
-   if (arg < 0 || arg > _NSIG) {
+   if (arg > _NSIG) {
break;
}
err = 0;

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

[PATCH] reiserfs: fix a few 'empty body in an if-statement' warnings.

[Jesper Juhl]

When building with  gcc -W  fs/reiserfs/namei.c:602 has a few warnings 
about 'empty body in an if-statement'. This patch silences those warnings.

Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>

--- linux-2.6.12-rc2-mm3-orig/fs/reiserfs/namei.c   2005-04-11 
21:20:55.0 +0200
+++ linux-2.6.12-rc2-mm3/fs/reiserfs/namei.c2005-04-15 02:54:53.0 
+0200
@@ -352,8 +352,9 @@ static struct dentry * reiserfs_lookup (
 }
 
/* Propogate the priv_object flag so we know we're in the priv tree */
-   if (is_reiserfs_priv_object (dir))
+   if (is_reiserfs_priv_object (dir)) {
reiserfs_mark_inode_private (inode);
+   }
 }
 reiserfs_write_unlock(dir->i_sb);
 if ( retval == IO_ERROR ) {
@@ -599,8 +600,9 @@ static int reiserfs_create (struct inode
 
 reiserfs_write_lock(dir->i_sb);
 
-if (locked)
+if (locked) {
 reiserfs_write_lock_xattrs (dir->i_sb);
+}
 
 retval = journal_begin(, dir->i_sb, jbegin_count);
 if (retval) {
@@ -640,8 +642,9 @@ static int reiserfs_create (struct inode
 retval = journal_end(, dir->i_sb, jbegin_count) ;
 
 out_failed:
-if (locked)
+if (locked) {
 reiserfs_write_unlock_xattrs (dir->i_sb);
+}
 reiserfs_write_unlock(dir->i_sb);
 return retval;
 }
@@ -668,8 +671,9 @@ static int reiserfs_mknod (struct inode 
 
 reiserfs_write_lock(dir->i_sb);
 
-if (locked)
+if (locked) {
 reiserfs_write_lock_xattrs (dir->i_sb);
+}
 
 retval = journal_begin(, dir->i_sb, jbegin_count) ;
 if (retval) {
@@ -714,8 +718,9 @@ static int reiserfs_mknod (struct inode 
 retval = journal_end(, dir->i_sb, jbegin_count) ;
 
 out_failed:
-if (locked)
+if (locked) {
 reiserfs_write_unlock_xattrs (dir->i_sb);
+}
 reiserfs_write_unlock(dir->i_sb);
 return retval;
 }
@@ -743,8 +748,9 @@ static int reiserfs_mkdir (struct inode 
 locked = reiserfs_cache_default_acl (dir);
 
 reiserfs_write_lock(dir->i_sb);
-if (locked)
+if (locked) {
 reiserfs_write_lock_xattrs (dir->i_sb);
+}
 
 retval = journal_begin(, dir->i_sb, jbegin_count) ;
 if (retval) {
@@ -799,8 +805,9 @@ static int reiserfs_mkdir (struct inode 
 d_instantiate(dentry, inode);
 retval = journal_end(, dir->i_sb, jbegin_count) ;
 out_failed:
-if (locked)
+if (locked) {
 reiserfs_write_unlock_xattrs (dir->i_sb);
+}
 reiserfs_write_unlock(dir->i_sb);
 return retval;
 }


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

Re: Fortuna

[linux]

> Waiting for 256bits of entropy before outputting data is a good goal.
> Problem becomes how do you measure entropy in a reliable way?  This had
> me lynched last time I asked it so I'll stop right there.

It's a problem.  Also, with the current increase in wireless keyboards
and mice, that source should possibly not be considered secure any more.

On the other hand, clock jitter in GHz clocks is a *very* rich source
of seed material.  One rdtsc per timer tick, even accounted for at
0.1 bit per rdtsc (I think reality is more like 3-5 bits) would keep
you in clover.

> I'll not make any claim that random-fortuna.c should be mv'd to random.c, the
> patch given allows people to kernel config it in under the Cryptographic
> Options menu.  Perhaps a disclaimer in the help menu would be in order to
> inform users that Fortuna has profound consequences for those expecting
> Info-theoretic /dev/random?

I don't mean to disparage you efforts, but then what's the upside to
the resultant code maintenance hassles?  Other than hack value, what's the
advantage of even offering the choice?  An option like that is justified
when the two options have value for different people and it's not
possible to build a single merged solutions that satisfies both markets.

Also, Ted very deliberately made /dev/random non-optional so it could
be relied on without a lot of annoying run-time testing.  Would
a separate /dev/fortuna be better?



> The case where an attacker has some small amount of unknown in the pool is a
> problem that effects BOTH random-fortuna.c and random.c (and any other
> replacement for that matter).  Just an FYI.

Yes, but entropy estimation is supposed to deal with that.  If the
attacker is never allowed enough information out of the pool to
distinguish various input states, the output is secure.

> As for the "shifting property" problem of an attacker controlling some input
> to the pooling system, I've tried to get around this:

(Code that varies the pool things get added to based on r->key[i++ & 7])

> The add_entropy_words() function uses the first 8 bytes of the central
> pool to aggravate the predictability of where entropy goes.  It's still a
> linear progression untill the central pool is re-keyed, then you don't know
> where it went.  The central pool is reseeded every 0.1ms.

You need to think more carefully.  You're just elaborating it without
adding security.  Yes, the attacker *does* know!  The entire underlying
assumption is that the attacker knows the entire initial state of the
pool, owing to some compromise or another.

The assumption is that the only thing the attacker doesn't know is the
exact value of the incoming seed material.  (But the attacker does have
an excellent model of its distribution.)

Given that, the attacker knows the initial value of the key[] array,
and thus knows the order in which the pools are fed.  The question
then arises, come next reseed, can the attacker (with a small mountain
of computers, able to brute-force 40-bit problems in the blink of an
eye) infer the *complete* state of the pool from the output.

The confusion is over the word "random".  In programming jargon, the
word is most often used to mean "arbitrary" or "the choice doesn't
matter".  But that doesn't capture the idea of "unpredictable to
a skilled and determined opponent" that is needed in /dev/random.

So while the contents of key[] may be "random-looking", they're not
*unpredictable*, any more than the digits of pi are.

The attacker just has to, after each reseeding, brute-force the seed
bits fed to the (predictable) pools chosen to mix in, and then
use that information to infer the seeds added to the not-selected
pools.

If the attacker's uncertainty about the state of some of the subpools
increases to the catastrophic reseeding level, then the Fortuna design
goal is achieved.

If the seed samples are independent, then it's easy to see that the
schedule works.

But if the seed samples are correlated, it gets a lot trickier.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6 patch] drivers/video/intelfb/intelfbdrv.h

[Adrian Bunk]

Ingo Oeser noticed that all that intelfbdrv.h contains are prototypes 
for static functions - and such prototypes don't belong into header 
files.

This patch therefore removes drivers/video/intelfb/intelfbdrv.h and 
moves the prototypes to intelfbdrv.c .

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was already sent on:
- 20 Mar 2005

 drivers/video/intelfb/intelfbdrv.c |   40 -
 drivers/video/intelfb/intelfbdrv.h |   68 -
 2 files changed, 39 insertions(+), 69 deletions(-)

--- linux-2.6.11-mm4-full/drivers/video/intelfb/intelfbdrv.c.old
2005-03-20 03:39:30.0 +0100
+++ linux-2.6.11-mm4-full/drivers/video/intelfb/intelfbdrv.c2005-03-20 
03:44:03.0 +0100
@@ -135,9 +135,47 @@
 #endif
 
 #include "intelfb.h"
-#include "intelfbdrv.h"
 #include "intelfbhw.h"
 
+
+static void __devinit get_initial_mode(struct intelfb_info *dinfo);
+static void update_dinfo(struct intelfb_info *dinfo,
+struct fb_var_screeninfo *var);
+static int intelfb_get_fix(struct fb_fix_screeninfo *fix,
+  struct fb_info *info);
+
+static int intelfb_check_var(struct fb_var_screeninfo *var,
+struct fb_info *info);
+static int intelfb_set_par(struct fb_info *info);
+static int intelfb_setcolreg(unsigned regno, unsigned red, unsigned green,
+unsigned blue, unsigned transp,
+struct fb_info *info);
+
+static int intelfb_blank(int blank, struct fb_info *info);
+static int intelfb_pan_display(struct fb_var_screeninfo *var,
+  struct fb_info *info);
+
+static void intelfb_fillrect(struct fb_info *info,
+const struct fb_fillrect *rect);
+static void intelfb_copyarea(struct fb_info *info,
+const struct fb_copyarea *region);
+static void intelfb_imageblit(struct fb_info *info,
+ const struct fb_image *image);
+static int intelfb_cursor(struct fb_info *info,
+  struct fb_cursor *cursor);
+
+static int intelfb_sync(struct fb_info *info);
+
+static int intelfb_ioctl(struct inode *inode, struct file *file,
+unsigned int cmd, unsigned long arg,
+struct fb_info *info);
+
+static int __devinit intelfb_pci_register(struct pci_dev *pdev,
+ const struct pci_device_id *ent);
+static void __devexit intelfb_pci_unregister(struct pci_dev *pdev);
+static int __devinit intelfb_set_fbinfo(struct intelfb_info *dinfo);
+
+
 /*
  * Limiting the class to PCI_CLASS_DISPLAY_VGA prevents function 1 of the
  * mobile chipsets from being registered.
--- linux-2.6.11-mm4-full/drivers/video/intelfb/intelfbdrv.h2005-03-16 
18:55:25.0 +0100
+++ /dev/null   2005-03-19 22:42:59.0 +0100
@@ -1,68 +0,0 @@
-#ifndef _INTELFBDRV_H
-#define _INTELFBDRV_H
-
-/*
- **
- * intelfb
- *
- * Linux framebuffer driver for Intel(R) 830M/845G/852GM/855GM/865G/915G
- * integrated graphics chips.
- *
- * Copyright © 2004 Sylvain Meyer
- *
- * Author: Sylvain Meyer
- *
- **
- *This program is free software; you can redistribute it and/or modify
- *it under the terms of the GNU General Public License as published by
- *the Free Software Foundation; either version 2 of the License, or
- *(at your option) any later version.
- *
- *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.
-*/
-
-static void __devinit get_initial_mode(struct intelfb_info *dinfo);
-static void update_dinfo(struct intelfb_info *dinfo,
-struct fb_var_screeninfo *var);
-static int intelfb_get_fix(struct fb_fix_screeninfo *fix,
-  struct fb_info *info);
-
-static int intelfb_check_var(struct fb_var_screeninfo *var,
-struct fb_info *info);
-static int intelfb_set_par(struct fb_info *info);
-static int intelfb_setcolreg(unsigned regno, unsigned red, unsigned green,
-unsigned blue, unsigned transp,
-struct fb_info *info);
-
-static int intelfb_blank(int blank, struct fb_info *info);
-static int intelfb_pan_display(struct fb_var_screeninfo *var,
-  struct fb_info *info);
-
-static void intelfb_fillrect(struct fb_info *info,
-  

[2.6 patch] change the SOUND_PRIME handling

[Adrian Bunk]

SOUND_PRIME (for OSS) is a tristate.

This doesn't make much sense if most users are checking for 
SOUND_PRIME!=0.

This patch changes the semantics of SOUND_PRIME to being a limit for all 
OSS modules, IOW: SOUND_PRIME=m does now say that all OSS drivers can 
only be modular.

As a side effect, since SOUND_PRIME already depends on SOUND, there's no 
longer a reason for drivers depending on SOUND_PRIME to additionally 
depend on SOUND.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was already sent on:
- 19 Mar 2005

 sound/oss/Kconfig |   62 +++---
 1 files changed, 31 insertions(+), 31 deletions(-)

--- linux-2.6.11-mm4-full/sound/oss/Kconfig.old 2005-03-19 13:49:39.0 
+0100
+++ linux-2.6.11-mm4-full/sound/oss/Kconfig 2005-03-19 13:53:59.0 
+0100
@@ -6,7 +6,7 @@
 # Prompt user for primary drivers.
 config SOUND_BT878
tristate "BT878 audio dma"
-   depends on SOUND_PRIME!=n && SOUND
+   depends on SOUND_PRIME
---help---
  Audio DMA support for bt878 based grabber boards.  As you might have
  already noticed, bt878 is listed with two functions in /proc/pci.
@@ -22,7 +22,7 @@
 
 config SOUND_CMPCI
tristate "C-Media PCI (CMI8338/8738)"
-   depends on SOUND_PRIME!=n && SOUND && PCI
+   depends on SOUND_PRIME && PCI
help
  Say Y or M if you have a PCI sound card using the CMI8338
  or the CMI8738 chipset.  Data on these chips are available at
@@ -61,7 +61,7 @@
 
 config SOUND_EMU10K1
tristate "Creative SBLive! (EMU10K1)"
-   depends on SOUND_PRIME!=n && SOUND && PCI
+   depends on SOUND_PRIME && PCI
---help---
  Say Y or M if you have a PCI sound card using the EMU10K1 chipset,
  such as the Creative SBLive!, SB PCI512 or Emu-APS.
@@ -87,7 +87,7 @@
 
 config SOUND_FUSION
tristate "Crystal SoundFusion (CS4280/461x)"
-   depends on SOUND_PRIME!=n && SOUND
+   depends on SOUND_PRIME
help
  This module drives the Crystal SoundFusion devices (CS4280/46xx
  series) when wired as native sound drivers with AC97 codecs.  If
@@ -95,14 +95,14 @@
 
 config SOUND_CS4281
tristate "Crystal Sound CS4281"
-   depends on SOUND_PRIME!=n && SOUND
+   depends on SOUND_PRIME
help
  Picture and feature list at
  .
 
 config SOUND_BCM_CS4297A
tristate "Crystal Sound CS4297a (for Swarm)"
-   depends on SOUND_PRIME!=n && SIBYTE_SWARM && SOUND
+   depends on SOUND_PRIME && SIBYTE_SWARM
help
  The BCM91250A has a Crystal CS4297a on synchronous serial
  port B (in addition to the DB-9 serial port).  Say Y or M
@@ -112,7 +112,7 @@
 
 config SOUND_ES1370
tristate "Ensoniq AudioPCI (ES1370)"
-   depends on SOUND_PRIME!=n && SOUND && PCI
+   depends on SOUND_PRIME && PCI
help
  Say Y or M if you have a PCI sound card utilizing the Ensoniq
  ES1370 chipset, such as Ensoniq's AudioPCI (non-97). To find
@@ -125,7 +125,7 @@
 
 config SOUND_ES1371
tristate "Creative Ensoniq AudioPCI 97 (ES1371)"
-   depends on SOUND_PRIME!=n && SOUND && PCI
+   depends on SOUND_PRIME && PCI
help
  Say Y or M if you have a PCI sound card utilizing the Ensoniq
  ES1371 chipset, such as Ensoniq's AudioPCI97. To find out if
@@ -138,7 +138,7 @@
 
 config SOUND_ESSSOLO1
tristate "ESS Technology Solo1" 
-   depends on SOUND_PRIME!=n && SOUND && PCI
+   depends on SOUND_PRIME && PCI
help
  Say Y or M if you have a PCI sound card utilizing the ESS Technology
  Solo1 chip. To find out if your sound card uses a
@@ -149,7 +149,7 @@
 
 config SOUND_MAESTRO
tristate "ESS Maestro, Maestro2, Maestro2E driver"
-   depends on SOUND_PRIME!=n && SOUND && PCI
+   depends on SOUND_PRIME && PCI
help
  Say Y or M if you have a sound system driven by ESS's Maestro line
  of PCI sound chips.  These include the Maestro 1, Maestro 2, and
@@ -158,28 +158,28 @@
 
 config SOUND_MAESTRO3
tristate "ESS Maestro3/Allegro driver (EXPERIMENTAL)"
-   depends on SOUND_PRIME!=n && SOUND && PCI && EXPERIMENTAL
+   depends on SOUND_PRIME && PCI && EXPERIMENTAL
help
  Say Y or M if you have a sound system driven by ESS's Maestro 3
  PCI sound chip.
 
 config SOUND_ICH
tristate "Intel ICH (i8xx) audio support"
-   depends on SOUND_PRIME!=n && PCI
+   depends on SOUND_PRIME && PCI
help
  Support for integral audio in Intel's I/O Controller Hub (ICH)
  chipset, as used on the 810/820/840 motherboards.
 
 config SOUND_HARMONY
tristate "PA Harmony audio driver"
-   depends on GSC_LASI && SOUND_PRIME!=n
+   depends on GSC_LASI && SOUND_PRIME
help
  Say 'Y' or 'M' to include support for 

[2.6 patch] sound/oss/sscape.c: remove dead code

[Adrian Bunk]

The Coverity checker found that sscape_sb_enable never get's assigned 
any value different from 0, and therefore some code paths are 
impossible.

This patch removes this variable and the dead code paths.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was already sent on:
- 24 Mar 2005

 sound/oss/sscape.c |8 +---
 1 files changed, 1 insertion(+), 7 deletions(-)

--- linux-2.6.12-rc1-mm1-full/sound/oss/sscape.c.old2005-03-23 
01:10:35.0 +0100
+++ linux-2.6.12-rc1-mm1-full/sound/oss/sscape.c2005-03-23 
01:11:38.0 +0100
@@ -991,7 +991,6 @@ static void __init sscape_pnp_init_hw(ss
unsigned i;
static  char code_file_name[23] = "/sndscape/sndscape.cox";

-   int sscape_sb_enable= 0;
int sscape_joystic_enable   = 0x7f;
int sscape_mic_enable   = 0;
int sscape_ext_midi = 0;
@@ -1015,14 +1014,9 @@ static void __init sscape_pnp_init_hw(ss
sscape_write( devc, 2, devc->ic_type == IC_ODIE ? 0x70 : 0x40);
sscape_write( devc, 3, ( devc -> dma << 4) | 0x80);
 
-   if ( sscape_sb_enable )
-   sscape_write (devc, 4, 0xF0 | (sb_irq << 2) | midi_irq);
-   else
-   sscape_write (devc, 4, 0xF0 | (midi_irq<<2) | midi_irq);
+   sscape_write (devc, 4, 0xF0 | (midi_irq<<2) | midi_irq);
 
i = 0x10; //sscape_read(devc, 9) & (devc->ic_type == IC_ODIE ? 0xf0 : 
0xc0);
-   if ( sscape_sb_enable )
-   i |= devc->ic_type == IC_ODIE ? 0x05 : 0x07;
if (sscape_joystic_enable) i |= 8;

sscape_write (devc, 9, i);

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

[2.6 patch] drivers/scsi/dpt*: remove version.h dependencies

[Adrian Bunk]

On Sat, Apr 02, 2005 at 07:49:38AM -0600, James Bottomley wrote:
> On Sun, 2005-03-27 at 16:34 +0200, Adrian Bunk wrote:
> > This patch removes #if's for kernel 2.2 .
> 
> this one looks like it's not quite complete:
> 
> > -#ifndef LINUX_VERSION_CODE
> >  #include 
> > -#endif
> 
> Once there are no more KERNEL_VERSION dependencies in a file, it's
> inclusion of linux/version.h can be removed also (and that should
> prevent it getting rebuilt every time the kernel version changes).
> 
> So it looks like there's an additional KERNEL_VERSION to remove in
> dpt/dpti_i2o.h version.h includes in dpti_i2o.h and dpt_i2o.c

Is the patch below what you want, or do I misunderstand your comment?

> Then when you have a final patch, could you cc Markus Lidel
> <[EMAIL PROTECTED]> and  
> 
> [EMAIL PROTECTED]
> 
> Thanks,
> 
> James

cu
Adrian


<--  snip  -->


This patch removes version.h dependencies.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

 drivers/scsi/dpt/sys_info.h |4 
 drivers/scsi/dpt_i2o.c  |5 -
 drivers/scsi/dpti.h |   12 
 3 files changed, 21 deletions(-)

--- linux-2.6.12-rc2-mm3-full/drivers/scsi/dpti.h.old   2005-04-15 
01:21:04.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/scsi/dpti.h   2005-04-15 
01:21:26.0 +0200
@@ -20,15 +20,7 @@
 #ifndef _DPT_H
 #define _DPT_H
 
-#ifndef LINUX_VERSION_CODE
-#include 
-#endif
-
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,00)
-#define MAX_TO_IOP_MESSAGES   (210)
-#else
 #define MAX_TO_IOP_MESSAGES   (255)
-#endif
 #define MAX_FROM_IOP_MESSAGES (255)
 
 
@@ -321,10 +313,6 @@
 static void adpt_delay(int millisec);
 #endif
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0)
-static struct pci_dev* adpt_pci_find_device(uint vendor, struct pci_dev* from);
-#endif
-
 #if defined __ia64__ 
 static void adpt_ia64_info(sysInfo_S* si);
 #endif
--- linux-2.6.12-rc2-mm3-full/drivers/scsi/dpt/sys_info.h.old   2005-04-15 
01:23:52.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/scsi/dpt/sys_info.h   2005-04-15 
01:24:13.0 +0200
@@ -146,10 +146,6 @@
uSHORT   flags;  /* See bit definitions above */
uSHORT   conventionalMemSize;/* in KB */
uLONGextendedMemSize;/* in KB */
-   uLONGosType; /* Same as DPTSIG's definition */
-   uCHARosMajorVersion;
-   uCHARosMinorVersion; /* The OS version */
-   uCHARosRevision;
 #ifdef _SINIX_ADDON
uCHARbusType;/* See defininitions above */
uSHORT   osSubRevision;
--- linux-2.6.12-rc2-mm3-full/drivers/scsi/dpt_i2o.c.old2005-04-15 
01:21:48.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/scsi/dpt_i2o.c2005-04-15 
01:25:20.0 +0200
@@ -34,7 +34,6 @@
 
 #define ADDR32 (0)
 
-#include 
 #include 
 
 MODULE_AUTHOR("Deanna Bonds, with _lots_ of help from Mark Salyzyn");
@@ -1824,10 +1823,6 @@
 
memset(, 0, sizeof(si));
 
-   si.osType = OS_LINUX;
-   si.osMajorVersion = (u8) (LINUX_VERSION_CODE >> 16);
-   si.osMinorVersion = (u8) (LINUX_VERSION_CODE >> 8 & 0x0ff);
-   si.osRevision = (u8) (LINUX_VERSION_CODE & 0x0ff);
si.busType = SI_PCI_BUS;
si.processorFamily = DPTI_sig.dsProcessorFamily;
 

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

[2.6 patch] drivers/net/arcnet/: possible cleanups

[Adrian Bunk]

This patch contains the following possible cleanups:
- make needlessly global code static
- arcnet.c: remove the outdated VERSION
- arcnet.c: remove the unneeded EXPORT_SYMBOL(arc_proto_null)
- arcnet.c: remove the unneeded EXPORT_SYMBOL(arcnet_dump_packet)

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was already sent on:
- 24 Mar 2005

 drivers/net/arcnet/arc-rawmode.c |2 +-
 drivers/net/arcnet/arcnet.c  |   19 ++-
 drivers/net/arcnet/rfc1051.c |2 +-
 drivers/net/arcnet/rfc1201.c |3 +--
 include/linux/arcdevice.h|9 -
 5 files changed, 13 insertions(+), 22 deletions(-)

--- linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/arc-rawmode.c.old  
2005-02-16 15:16:38.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/arc-rawmode.c  2005-02-16 
15:16:51.0 +0100
@@ -42,7 +42,7 @@
 static int prepare_tx(struct net_device *dev, struct archdr *pkt, int length,
  int bufnum);
 
-struct ArcProto rawmode_proto =
+static struct ArcProto rawmode_proto =
 {
.suffix = 'r',
.mtu= XMTU,
--- linux-2.6.11-rc3-mm2-full/include/linux/arcdevice.h.old 2005-02-16 
15:17:26.0 +0100
+++ linux-2.6.11-rc3-mm2-full/include/linux/arcdevice.h 2005-02-16 
15:20:57.0 +0100
@@ -206,7 +206,6 @@
 
 extern struct ArcProto *arc_proto_map[256], *arc_proto_default,
*arc_bcast_proto, *arc_raw_proto;
-extern struct ArcProto arc_proto_null;
 
 
 /*
@@ -334,17 +333,9 @@
 #define arcnet_dump_skb(dev,skb,desc) ;
 #endif
 
-#if (ARCNET_DEBUG_MAX & D_RX) || (ARCNET_DEBUG_MAX & D_TX)
-void arcnet_dump_packet(struct net_device *dev, int bufnum, char *desc,
-   int take_arcnet_lock);
-#else
-#define arcnet_dump_packet(dev, bufnum, desc,take_arcnet_lock) ;
-#endif
-
 void arcnet_unregister_proto(struct ArcProto *proto);
 irqreturn_t arcnet_interrupt(int irq, void *dev_id, struct pt_regs *regs);
 struct net_device *alloc_arcdev(char *name);
-void arcnet_rx(struct net_device *dev, int bufnum);
 
 #endif /* __KERNEL__ */
 #endif /* _LINUX_ARCDEVICE_H */
--- linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/arcnet.c.old   2005-02-16 
15:17:47.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/arcnet.c   2005-02-16 
15:21:20.0 +0100
@@ -41,8 +41,6 @@
  * <[EMAIL PROTECTED]>
  */
 
-#define VERSION "arcnet: v3.93 BETA 2000/04/29 - by Avery Pennarun et al.\n"
-
 #include 
 #include 
 #include 
@@ -61,6 +59,7 @@
 static int null_prepare_tx(struct net_device *dev, struct archdr *pkt,
   int length, int bufnum);
 
+static void arcnet_rx(struct net_device *dev, int bufnum);
 
 /*
  * one ArcProto per possible proto ID.  None of the elements of
@@ -71,7 +70,7 @@
  struct ArcProto *arc_proto_map[256], *arc_proto_default,
*arc_bcast_proto, *arc_raw_proto;
 
-struct ArcProto arc_proto_null =
+static struct ArcProto arc_proto_null =
 {
.suffix = '?',
.mtu= XMTU,
@@ -90,7 +89,6 @@
 EXPORT_SYMBOL(arc_proto_default);
 EXPORT_SYMBOL(arc_bcast_proto);
 EXPORT_SYMBOL(arc_raw_proto);
-EXPORT_SYMBOL(arc_proto_null);
 EXPORT_SYMBOL(arcnet_unregister_proto);
 EXPORT_SYMBOL(arcnet_debug);
 EXPORT_SYMBOL(alloc_arcdev);
@@ -118,8 +116,8 @@
 
arcnet_debug = debug;
 
-   printk(VERSION);
+   printk("arcnet loaded.\n");

 #ifdef ALPHA_WARNING
BUGLVL(D_EXTRA) {
printk("arcnet: ***\n"
@@ -178,8 +174,8 @@
  * Dump the contents of an ARCnet buffer
  */
 #if (ARCNET_DEBUG_MAX & (D_RX | D_TX))
-void arcnet_dump_packet(struct net_device *dev, int bufnum, char *desc,
-   int take_arcnet_lock)
+static void arcnet_dump_packet(struct net_device *dev, int bufnum,
+  char *desc, int take_arcnet_lock)
 {
struct arcnet_local *lp = dev->priv;
int i, length;
@@ -208,7 +204,10 @@
 
 }
 
-EXPORT_SYMBOL(arcnet_dump_packet);
+#else
+
+#define arcnet_dump_packet(dev, bufnum, desc,take_arcnet_lock) do { } while (0)
+
 #endif
 
 
@@ -987,7 +986,7 @@
  * This is a generic packet receiver that calls arcnet??_rx depending on the
  * protocol ID found.
  */
-void arcnet_rx(struct net_device *dev, int bufnum)
+static void arcnet_rx(struct net_device *dev, int bufnum)
 {
struct arcnet_local *lp = dev->priv;
struct archdr pkt;
--- linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/rfc1051.c.old  2005-02-16 
15:22:16.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/rfc1051.c  2005-02-16 
15:22:23.0 +0100
@@ -43,7 +43,7 @@
  int bufnum);
 
 
-struct ArcProto rfc1051_proto =
+static struct ArcProto rfc1051_proto =
 {
.suffix = 's',
.mtu= XMTU - RFC1051_HDR_SIZE,
--- linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/rfc1201.c.old  2005-02-16 
15:22:35.0 +0100
+++ 

Re: ALSA Oops (triggered by xmms)

[Jesper Juhl]

On Fri, 15 Apr 2005, Christian Kujau wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Jesper Juhl wrote:
> > 
> >   ^ you should send such info inline in the email - having to go check 
> > external links makes a lot of people ignore the stuff right then and 
> 
> yeah, but the oops doesn't wrap at 80 chars itsself and often oopses are
> hardly readable inline.
> 
I would still suggest including the info inline and then if you think it's 
needed /also/ provide the link you did - then you've covered all bases :)

> > Btw: I believe this is fixed in 2.6.11.7 - from the Changelog : 
> >
> > <[EMAIL PROTECTED]>
> > [PATCH] Fix Oops with ALSA timer event notification
> 
> oh, this sounds good. strange though, that my 2.6.11-gentoo-r5 (whatever
> they've patched in there) *never* oopsed the days ago but all of a sudden
> started to oops yesterday
> 
Some bugs are like that, especially when they involve race conditions or 
timers.. Anyway, if you could test 2.6.11.7 (and perhaps also 2.6.12-rc*) 
to verify that the issue is indeed fixed, then I believe that would be 
appreciated :)


-- 
Jesper


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

Re: [PATCH] sched: fix never executed code due to expression always false

[Nick Piggin]

Jesper Juhl wrote:
As per this patch perhaps? : 

Thanks. I'll make sure it gets to the right place if nobody picks it up.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- linux-2.6.12-rc2-mm3-orig/kernel/sched.c	2005-04-11 21:20:56.0 +0200
+++ linux-2.6.12-rc2-mm3/kernel/sched.c	2005-04-15 02:21:34.0 +0200
@@ -2697,9 +2697,10 @@ need_resched_nonpreemptible:
 	schedstat_inc(rq, sched_cnt);
 	now = sched_clock();
 	if (likely((long long)now - prev->timestamp < NS_MAX_SLEEP_AVG)) {
-		run_time = now - prev->timestamp;
-		if (unlikely((long long)now - prev->timestamp < 0))
+		if (unlikely(((long long)now - (long long)prev->timestamp) < 0))
 			run_time = 0;
+		else
+			run_time = now - prev->timestamp;
 	} else
 		run_time = NS_MAX_SLEEP_AVG;
 
@@ -2776,7 +2777,7 @@ go_idle:
 
 	if (!rt_task(next) && next->activated > 0) {
 		unsigned long long delta = now - next->timestamp;
-		if (unlikely((long long)now - next->timestamp < 0))
+		if (unlikely(((long long)now - (long long)next->timestamp) < 0))
 			delta = 0;
 
 		if (next->activated == 1)



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

Re: ALSA Oops (triggered by xmms)

[Lee Revell]

On Fri, 2005-04-15 at 02:16 +0200, Christian Kujau wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Lee Revell wrote:
> > 
> > Fixed in 2.6.11.7.
> > 
> 
> thank you & sorry for the noise.

No need to apologize, this is not noise.  Always err on the side of
reporting the bug.  It's much better to deal with duplicate bug reports
than have bugs go unreported.

Lee


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

Re: [PATCH] sched: fix never executed code due to expression always false

[Jesper Juhl]

On Fri, 15 Apr 2005, Nick Piggin wrote:

> Jesper Juhl wrote:
> > On Fri, 15 Apr 2005, Nick Piggin wrote:
> > 
> > 
> > > Jesper Juhl wrote:
> > > 
> > > > There are two expressions in kernel/sched.c that are always false since
> > > > they
> > > > test for <0 but the result of the expression is unsigned so they will
> > > > never
> > > > be less than zero. This patch implement the logic that I believe is
> > > > intended
> > > > without the signedness issue and without the nasty casts.
> > > > patch is compile tested only
> > > > 
> > > This is not *quite* the intended behaviour. It is OK for prev->timestamp
> > > to be '0 - a bit' and now to be '0 + a bit' in the case of wrapping.
> > > 
> > > Although considering they're 64-bit values, I'm not sure how much we care.
> > > 
> > 
> > How do you propose to fix this then?  As the code is now the expressionsa
> > are always false - should we just remove the them?  Or do you have a
> > sensible definition of "a bit" ?  or ome other suggestion alltogether?
> > 
> 
> Make it a signed comparison?
> 
As per this patch perhaps? : 

Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>

--- linux-2.6.12-rc2-mm3-orig/kernel/sched.c2005-04-11 21:20:56.0 
+0200
+++ linux-2.6.12-rc2-mm3/kernel/sched.c 2005-04-15 02:21:34.0 +0200
@@ -2697,9 +2697,10 @@ need_resched_nonpreemptible:
schedstat_inc(rq, sched_cnt);
now = sched_clock();
if (likely((long long)now - prev->timestamp < NS_MAX_SLEEP_AVG)) {
-   run_time = now - prev->timestamp;
-   if (unlikely((long long)now - prev->timestamp < 0))
+   if (unlikely(((long long)now - (long long)prev->timestamp) < 0))
run_time = 0;
+   else
+   run_time = now - prev->timestamp;
} else
run_time = NS_MAX_SLEEP_AVG;
 
@@ -2776,7 +2777,7 @@ go_idle:
 
if (!rt_task(next) && next->activated > 0) {
unsigned long long delta = now - next->timestamp;
-   if (unlikely((long long)now - next->timestamp < 0))
+   if (unlikely(((long long)now - (long long)next->timestamp) < 0))
delta = 0;
 
if (next->activated == 1)


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

Re: IBM Thinkpad T42 - Looking for a Developer.

[Matti Aarnio]

On Thu, Apr 14, 2005 at 06:40:16PM -0400, abonilla wrote:
> On Thu, 14 Apr 2005 23:20:19 +0200 (CEST), Jesper Juhl wrote
> > >  This is located in my home PC, Won't be the fastest downloads...
> > >  
> > >  http://wifitux.com/finger/
> > >  
> > Under what terms did you obtain these documents and from where? Are 
> > they completely freely distributable or are there strings attached?
> 
> I emailed the guys and they told me, "Hey, here you go, let me know if you
> want more information"

Those documents and files are downloadable also from   www.upek.com
They are rather scattered out there, but still...

In Linux environment we do need to define and implement our own
interface to the the device.  There is  BioAPI (www.bioapi.org)
interface specification, but that is rather high up in the application
stack.  (There exists also NIST written Linux version at that site,
and it seems to be "BSD with advertisement clause" licensed...)

My reading so far seems to indicate, that this is mostly doable
in the application space without needing kernel space drivers.

Implementing BioAPI interface library with device specific backends
(much in the same manner as SANE works) is the way, I do think.
To how large an extent the existing source code can be used
in this is so far unknown.

To be able to do the device specific backends, I do need to have
the detailed USB interface protocol descriptions, not just a windows
library binary wrapping them up into BioAPI.   I can handle NDA 
documents as long as the resulting source code into Linux (and any
other UNIX-like system capable to use it) can be published.

> > -- 
> > Jesper

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

Re: ALSA Oops (triggered by xmms)

[Christian Kujau]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jesper Juhl wrote:
> 
>   ^ you should send such info inline in the email - having to go check 
> external links makes a lot of people ignore the stuff right then and 

yeah, but the oops doesn't wrap at 80 chars itsself and often oopses are
hardly readable inline.

> Btw: I believe this is fixed in 2.6.11.7 - from the Changelog : 
>
> <[EMAIL PROTECTED]>
>   [PATCH] Fix Oops with ALSA timer event notification

oh, this sounds good. strange though, that my 2.6.11-gentoo-r5 (whatever
they've patched in there) *never* oopsed the days ago but all of a sudden
started to oops yesterday


thank you,
Christian.
- --
BOFH excuse #131:

telnet: Unable to connect to remote host: Connection refused
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCXwem+A7rjkF8z0wRAuXSAJ4tZujWF0H5Da5o2J6yfzZQJolhPACgiKUR
YknU154MUkPEB52FuYTTF50=
=5yoy
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Question On TSS

[Imanpreet Arora]

Hello,

I am a bit confused about the TSS. The documentation says that it
includes 3 fields SS0, SS1 and SS2 for privilige levels 0, 1, 2
respectively. And are set up when a task is first created, I can't
figure out why these fields are necessary. I think that these fileds
are necessary when we have moved from PL 3 to PL0 and these would
contain information about upper 3 stacks so that information can be
retrived.

-- 

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

Re: ALSA Oops (triggered by xmms)

[Christian Kujau]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Lee Revell wrote:
> 
> Fixed in 2.6.11.7.
> 

thank you & sorry for the noise.
Christian.
- --
BOFH excuse #20:

divide-by-zero error
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCXwfv+A7rjkF8z0wRAnnKAJ0T93Q/IHCKmyFiLkhnvBU2a06cPgCdHRRo
7rBaIbXcYc7L5CBEvoAr93E=
=xyAE
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sched: fix never executed code due to expression always false

[Nick Piggin]

Jesper Juhl wrote:
On Fri, 15 Apr 2005, Nick Piggin wrote:

Jesper Juhl wrote:
There are two expressions in kernel/sched.c that are always false since they
test for <0 but the result of the expression is unsigned so they will never
be less than zero. This patch implement the logic that I believe is intended
without the signedness issue and without the nasty casts.
patch is compile tested only
This is not *quite* the intended behaviour. It is OK for prev->timestamp
to be '0 - a bit' and now to be '0 + a bit' in the case of wrapping.
Although considering they're 64-bit values, I'm not sure how much we care.
How do you propose to fix this then?  As the code is now the expressionsa 
are always false - should we just remove the them?  Or do you have a 
sensible definition of "a bit" ?  or ome other suggestion alltogether?

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

Re: [PATCH] sched: fix never executed code due to expression always false

[Jesper Juhl]

On Fri, 15 Apr 2005, Nick Piggin wrote:

> Jesper Juhl wrote:
> > There are two expressions in kernel/sched.c that are always false since they
> > test for <0 but the result of the expression is unsigned so they will never
> > be less than zero. This patch implement the logic that I believe is intended
> > without the signedness issue and without the nasty casts.
> > patch is compile tested only
> > 
> 
> This is not *quite* the intended behaviour. It is OK for prev->timestamp
> to be '0 - a bit' and now to be '0 + a bit' in the case of wrapping.
> 
> Although considering they're 64-bit values, I'm not sure how much we care.
> 
How do you propose to fix this then?  As the code is now the expressionsa 
are always false - should we just remove the them?  Or do you have a 
sensible definition of "a bit" ?  or ome other suggestion alltogether?


-- 
Jesper


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

Re: IBM Thinkpad T42 - Looking for a Developer.

[Jesper Juhl]

On Fri, 15 Apr 2005, Matti Aarnio wrote:

> Could you show what/sbin/lsusb -vvtells in your T42 ?
> Do that without external devices attached.

Here's  /sbin/lsusb -vv  output from my  Thinkpad T42  Type: 2373-F2G : 


Bus 004 Device 002: ID 0483:2016 SGS Thomson Microelectronics 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize0 8
  idVendor   0x0483 SGS Thomson Microelectronics
  idProduct  0x2016 
  bcdDevice0.01
  iManufacturer   1 STMicroelectronics
  iProduct2 Biometric Coprocessor
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   39
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xa0
  Remote Wakeup
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  bytes 64 once
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  bytes 64 once
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0004  bytes 4 three times
bInterval  20

Bus 004 Device 001: ID :  
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 0 
  bMaxPacketSize0 8
  idVendor   0x 
  idProduct  0x 
  bcdDevice2.06
  iManufacturer   3 Linux 2.6.11-rc4-bk9laptop uhci_hcd
  iProduct2 
  iSerial 1 :00:1d.2
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xc0
  Self Powered
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0002  bytes 2 twice
bInterval 255

Bus 003 Device 001: ID :  
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 0 
  bMaxPacketSize0 8
  idVendor   0x 
  idProduct  0x 
  bcdDevice2.06
  iManufacturer   3 Linux 2.6.11-rc4-bk9laptop uhci_hcd
  iProduct2 
  iSerial 1 :00:1d.1
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xc0
  Self Powered
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber   

Re: [PATCH] sched: fix never executed code due to expression always false

[Nick Piggin]

Jesper Juhl wrote:
There are two expressions in kernel/sched.c that are always false since 
they test for <0 but the result of the expression is unsigned so they will 
never be less than zero. This patch implement the logic that I believe is 
intended without the signedness issue and without the nasty casts.
patch is compile tested only

This is not *quite* the intended behaviour. It is OK for prev->timestamp
to be '0 - a bit' and now to be '0 + a bit' in the case of wrapping.
Although considering they're 64-bit values, I'm not sure how much we care.
--
SUSE Labs, Novell Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Git archive now available

[David S. Miller]

On Fri, 15 Apr 2005 10:01:47 +1000
Darren Williams <[EMAIL PROTECTED]> wrote:

> Thanks to the team at [EMAIL PROTECTED] we now have a
> no so complete Git archive at
> http://www.gelato.unsw.edu.au/archives/git/
> 
> If somebody could send me a complete Git mbox I will
> update the archive with it.

I just had to unsubscribe [EMAIL PROTECTED]
because it was bouncing with errors like "hypermail: ...
this archive looks non-empty but there it no gdbm file"

So don't get too excited about your archive just yet :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Git archive now available

[Darren Williams]

Hi All

Thanks to the team at [EMAIL PROTECTED] we now have a
no so complete Git archive at
http://www.gelato.unsw.edu.au/archives/git/

If somebody could send me a complete Git mbox I will
update the archive with it.

 - dsw 

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

Re: IBM Thinkpad T42 - Looking for a Developer.

[Jeff Lessem]

In your message of: Fri, 15 Apr 2005 02:15:13 +0300, you write:
>On Thu, Apr 14, 2005 at 06:40:16PM -0400, abonilla wrote:
>> On Thu, 14 Apr 2005 23:20:19 +0200 (CEST), Jesper Juhl wrote
>> > On Thu, 14 Apr 2005, Alejandro Bonilla wrote:
>...
>> > >  This is located in my home PC, Won't be the fastest downloads...
>> > >  
>> > >  http://wifitux.com/finger/
>> >  
>> > Under what terms did you obtain these documents and from where? Are 
>> > they completely freely distributable or are there strings attached?
>> 
>> I emailed the guys and they told me, "Hey, here you go, let me know if you
>> want more information"
>> 
>> I guess it can't be more distributable. But as far as I got to read. The
>> documents don't have too much information like for us to do a great Job. I
>> think it also requires the making of a firmware.
>> 
>> I don't want to dissapoint you, but I hope I'm lost and that a driver can be
>> done out of this.
>
>There were two PDF documents.
>The more useful one tells that there are two possible interfaces:
> - Async serial
> - USB
>
>Could you show what/sbin/lsusb -vvtells in your T42 ?
>Do that without external devices attached.

I'm appending the lsusb -vv from my Thinkpad T43 for comparison.  This
also has a builtin USB fingerprint scanner, but I don't know if it is
the same one as used on the T42.  It is "Bus 004 Device 002: ID
0483:2016 SGS Thomson Microelectronics".  There are no other USB devices
connecting.


Bus 005 Device 001: ID :  
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 0 
  bMaxPacketSize0 8
  idVendor   0x 
  idProduct  0x 
  bcdDevice2.06
  iManufacturer   3 Linux 2.6.11.7 uhci_hcd
  iProduct2 Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB 
UHCI #4
  iSerial 1 :00:1d.3
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xc0
  Self Powered
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0002  1x 2 bytes
bInterval 255
Hub Descriptor:
  bLength   9
  bDescriptorType  41
  nNbrPorts 2
  wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
  bPwrOn2PwrGood1 * 2 milli seconds
  bHubContrCurrent  0 milli Ampere
  DeviceRemovable0x08
  PortPwrCtrlMask0x68 
 Hub Port Status:
   Port 1: .0100 power
   Port 2: .0100 power

Bus 004 Device 002: ID 0483:2016 SGS Thomson Microelectronics 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize0 8
  idVendor   0x0483 SGS Thomson Microelectronics
  idProduct  0x2016 
  bcdDevice0.01
  iManufacturer   1 STMicroelectronics
  iProduct2 Biometric Coprocessor
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   39
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xa0
  Remote Wakeup
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
   

[PATCH] sched: fix never executed code due to expression always false

[Jesper Juhl]

There are two expressions in kernel/sched.c that are always false since 
they test for <0 but the result of the expression is unsigned so they will 
never be less than zero. This patch implement the logic that I believe is 
intended without the signedness issue and without the nasty casts.
patch is compile tested only


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---

 sched.c |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

--- linux-2.6.12-rc2-mm3-orig/kernel/sched.c2005-04-11 21:20:56.0 
+0200
+++ linux-2.6.12-rc2-mm3/kernel/sched.c 2005-04-15 01:37:48.0 +0200
@@ -2697,9 +2697,10 @@ need_resched_nonpreemptible:
schedstat_inc(rq, sched_cnt);
now = sched_clock();
if (likely((long long)now - prev->timestamp < NS_MAX_SLEEP_AVG)) {
-   run_time = now - prev->timestamp;
-   if (unlikely((long long)now - prev->timestamp < 0))
+   if (unlikely(prev->timestamp > now))
run_time = 0;
+   else
+   run_time = now - prev->timestamp;
} else
run_time = NS_MAX_SLEEP_AVG;
 
@@ -2776,7 +2777,7 @@ go_idle:
 
if (!rt_task(next) && next->activated > 0) {
unsigned long long delta = now - next->timestamp;
-   if (unlikely((long long)now - next->timestamp < 0))
+   if (unlikely(next->timestamp > now))
delta = 0;
 
if (next->activated == 1)


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

[PATCH] hangcheck-timer: Update to 0.9.0.

[Joel Becker]

 
I recently realized that the in-kernel copy of hangcheck-timer
was quite stale.  Here's the latest.  It adds support for s390, ppc64,
and ia64 too.

Signed-off-by: Joel Becker <[EMAIL PROTECTED]>
---

 Kconfig   |2 -
 hangcheck-timer.c |  104 +-
 2 files changed, 96 insertions(+), 10 deletions(-)

Index: linux-2.6.12-rc2/drivers/char/hangcheck-timer.c
===
--- linux-2.6.12-rc2.orig/drivers/char/hangcheck-timer.c2005-03-01 
23:38:07.0 -0800
+++ linux-2.6.12-rc2/drivers/char/hangcheck-timer.c 2005-04-14 
15:32:03.0 -0700
@@ -3,7 +3,7 @@
  *
  * Driver for a little io fencing timer.
  *
- * Copyright (C) 2002 Oracle Corporation.  All rights reserved.
+ * Copyright (C) 2002, 2003 Oracle.  All rights reserved.
  *
  * Author: Joel Becker <[EMAIL PROTECTED]>
  *
@@ -44,11 +44,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
+#include 
 
 
-#define VERSION_STR "0.5.0"
+#define VERSION_STR "0.9.0"
 
 #define DEFAULT_IOFENCE_MARGIN 60  /* Default fudge factor, in seconds */
 #define DEFAULT_IOFENCE_TICK 180   /* Default timer timeout, in seconds */
@@ -56,18 +59,89 @@
 static int hangcheck_tick = DEFAULT_IOFENCE_TICK;
 static int hangcheck_margin = DEFAULT_IOFENCE_MARGIN;
 static int hangcheck_reboot;  /* Defaults to not reboot */
+static int hangcheck_dump_tasks;  /* Defaults to not dumping SysRQ T */
 
-/* Driver options */
+/* options - modular */
 module_param(hangcheck_tick, int, 0);
 MODULE_PARM_DESC(hangcheck_tick, "Timer delay.");
 module_param(hangcheck_margin, int, 0);
 MODULE_PARM_DESC(hangcheck_margin, "If the hangcheck timer has been delayed 
more than hangcheck_margin seconds, the driver will fire.");
 module_param(hangcheck_reboot, int, 0);
 MODULE_PARM_DESC(hangcheck_reboot, "If nonzero, the machine will reboot when 
the timer margin is exceeded.");
+module_param(hangcheck_dump_tasks, int, 0);
+MODULE_PARM_DESC(hangcheck_dump_tasks, "If nonzero, the machine will dump the 
system task state when the timer margin is exceeded.");
 
-MODULE_AUTHOR("Joel Becker");
+MODULE_AUTHOR("Oracle");
 MODULE_DESCRIPTION("Hangcheck-timer detects when the system has gone out to 
lunch past a certain margin.");
 MODULE_LICENSE("GPL");
+MODULE_VERSION(VERSION_STR);
+
+/* options - nonmodular */
+#ifndef MODULE
+
+static int __init hangcheck_parse_tick(char *str)
+{
+   int par;
+   if (get_option(,))
+   hangcheck_tick = par;
+   return 1;
+}
+
+static int __init hangcheck_parse_margin(char *str)
+{
+   int par;
+   if (get_option(,))
+   hangcheck_margin = par;
+   return 1;
+}
+
+static int __init hangcheck_parse_reboot(char *str)
+{
+   int par;
+   if (get_option(,))
+   hangcheck_reboot = par;
+   return 1;
+}
+
+static int __init hangcheck_parse_dump_tasks(char *str)
+{
+   int par;
+   if (get_option(,))
+   hangcheck_dump_tasks = par;
+   return 1;
+}
+
+__setup("hcheck_tick", hangcheck_parse_tick);
+__setup("hcheck_margin", hangcheck_parse_margin);
+__setup("hcheck_reboot", hangcheck_parse_reboot);
+__setup("hcheck_dump_tasks", hangcheck_parse_dump_tasks);
+#endif /* not MODULE */
+
+#if defined(CONFIG_X86) || defined(CONFIG_X86_64)
+# define HAVE_MONOTONIC
+# define TIMER_FREQ 10ULL
+#elif defined(CONFIG_ARCH_S390)
+/* FA24 is 1 Second in the IBM time universe (Page 4-38 Principles of Op 
for zSeries */
+# define TIMER_FREQ 0xFA24ULL
+#elif defined(CONFIG_IA64)
+# define TIMER_FREQ ((unsigned long long)local_cpu_data->itc_freq)
+#elif defined(CONFIG_PPC64)
+# define TIMER_FREQ (HZ*loops_per_jiffy)
+#endif
+
+#ifdef HAVE_MONOTONIC
+extern unsigned long long monotonic_clock(void);
+#else
+static inline unsigned long long monotonic_clock(void)
+{
+# ifdef __s390__
+   /* returns the TOD.  see 4-38 Principles of Op of zSeries */
+   return get_clock();
+# else
+   return get_cycles();
+# endif  /* __s390__ */
+}
+#endif  /* HAVE_MONOTONIC */
 
 
 /* Last time scheduled */
@@ -78,7 +152,6 @@
 static struct timer_list hangcheck_ticktock =
TIMER_INITIALIZER(hangcheck_fire, 0, 0);
 
-extern unsigned long long monotonic_clock(void);
 
 static void hangcheck_fire(unsigned long data)
 {
@@ -92,6 +165,12 @@
tsc_diff = (cur_tsc + (~0ULL - hangcheck_tsc)); /* or something 
*/
 
if (tsc_diff > hangcheck_tsc_margin) {
+   if (hangcheck_dump_tasks) {
+   printk(KERN_CRIT "Hangcheck: Task state:\n");
+#ifdef CONFIG_MAGIC_SYSRQ
+   handle_sysrq('t', NULL, NULL);
+#endif  /* CONFIG_MAGIC_SYSRQ */
+   }
if (hangcheck_reboot) {
printk(KERN_CRIT "Hangcheck: hangcheck is restarting 
the machine.\n");
machine_restart(NULL);
@@ -108,10 +187,16 

Re: ALSA Oops (triggered by xmms)

[Lee Revell]

On Fri, 2005-04-15 at 01:22 +0200, Christian Kujau wrote:
> maybe some guru can shed some light on what's going on in xmms-oops.txt
> and tell me who's to bug here :->

Fixed in 2.6.11.7.

Lee

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

Re: Serverworks LE and MTRR write-combining question

[Lee Revell]

On Thu, 2005-04-14 at 19:00 -0400, Mike Russo wrote:Just 
> wondering if anyone had any updates on this issue, and if not, hey, 
> that's why the source is there -- for me to screw around with. ;)
> 

I think it didn't go in just because no one bothered to repost the patch
with the comment fixed, as requested in that old thread.

Here's the patch from that thread against 2.6.12-rc2.  It also fixes an
unrelated typo in nearby code.  Obviously untested, as I don't have the
hardware ;-)

Summary: Enable write combining for server works LE rev > 6 per
http://www.ussg.iu.edu/hypermail/linux/kernel/0104.3/1007.html

Signed-Off-By: Lee Revell <[EMAIL PROTECTED]>

--- linux-2.6.12-rc2-k7/arch/i386/kernel/cpu/mtrr/main.c~   2005-04-14 
19:29:31.0 -0400
+++ linux-2.6.12-rc2-k7/arch/i386/kernel/cpu/mtrr/main.c2005-04-14 
19:29:16.0 -0400
@@ -72,17 +72,21 @@
 static int have_wrcomb(void)
 {
struct pci_dev *dev;
+   u8 rev;

if ((dev = pci_get_class(PCI_CLASS_BRIDGE_HOST << 8, NULL)) != NULL) {
-   /* ServerWorks LE chipsets have problems with write-combining 
+   /* ServerWorks LE chipsets < rev 6 have problems with 
write-combining 
   Don't allow it and leave room for other chipsets to be 
tagged */
if (dev->vendor == PCI_VENDOR_ID_SERVERWORKS &&
dev->device == PCI_DEVICE_ID_SERVERWORKS_LE) {
-   printk(KERN_INFO "mtrr: Serverworks LE detected. 
Write-combining disabled.\n");
-   pci_dev_put(dev);
-   return 0;
+   pci_read_config_byte(dev, PCI_CLASS_REVISION, );
+   if (rev <= 5) {
+   printk(KERN_INFO "mtrr: Serverworks LE rev < 6 
detected. Write-combining disabled.\n");
+   pci_dev_put(dev);
+   return 0;
+   }
}
-   /* Intel 450NX errata # 23. Non ascending cachline evictions to
+   /* Intel 450NX errata # 23. Non ascending cacheline evictions to
   write combining memory may resulting in data corruption */
if (dev->vendor == PCI_VENDOR_ID_INTEL &&
dev->device == PCI_DEVICE_ID_INTEL_82451NX) {


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

Re: [INFO] Kernel strict versioning

[Al Viro]

On Thu, Apr 14, 2005 at 02:41:44PM -0500, Franco Sensei wrote:
> The global feeling about kernel is that it seems that you don't care 
> about the purpose of your task, which of course is not the kernel by 
> itself. It can't be. It's about what it does (and already does it well), 
> and what it provides to third-parties: the kernel and the API given to 
> the outside world, since the kernel is not alone... and will never be of 
> course! ;)

Elegant.  Very elegant.  Admirable exercise in misdirection - the word
"third-party" used to conflate all things non-kernel with 3rd party
kernel modifications.  Followed by appeals to civic obligations, no less.

Of course, that doesn't change the simple fact: "outside world" is not
a single entity.  There are API warranties for userland.  There's no
API warranties for 3rd-party kernel modifications.

Moreover, unless you manage to get the list of functions and data
types exported to modules somewhere within an order of magnitude
from the corresponding userland list (i.e. syscalls and types involved),
you are asking everybody to increase the size of API being preserved
at least tenfold.  As it is, that would be "by factor of 200-300".

If you manage to convince module authors to live with the export list
cut down by that much - come back and we'll have something to talk
about.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ALSA Oops (triggered by xmms)

[Christian Kujau]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

howdy,

yesterday i hit an Oops when i tried to play an mp3 with xmms. nothing
unusual. the thing is - i've not changed the kernel (2.6.11-gentoo-r5) for
a while, but changed some (multimedia related) libs on my system. xmms
just segfaults and it all seems to be a proper userspace bug (even xmms
told me so). i really suspect xmms or the changed libs.
but i still believe in the old proverb my grandma used to say: "no
userspace app should make the kernel oops." but yesterday it did:

http://nerdbynature.de/bits/prinz/2.6.11-gentoo-r5/

this is 100% reproducable whenever i use the ALSA sounddriver in xmms.
when i use "mpg321 -o alsa ..." everything is ok.

maybe some guru can shed some light on what's going on in xmms-oops.txt
and tell me who's to bug here :->

thank you,
Christian.
- --
BOFH excuse #289:

Interference between the keyboard and the chair.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCXvsy+A7rjkF8z0wRAi5qAKCHXt/BSXHJdiMvYbf6SWnEIuFwkwCgmpmA
jRpOB7REfh99kMVaMdyIniw=
=rSNT
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] drivers/net/wan/: possible cleanups

[Adrian Bunk]

On Sun, Mar 27, 2005 at 05:38:38PM +0100, Alan Cox wrote:
> On Sul, 2005-03-27 at 15:34, Adrian Bunk wrote:
> >   - syncppp.c: sppp_input
> >   - syncppp.c: sppp_change_mtu
> >   - z85230.c: z8530_dma_sync
> >   - z85230.c: z8530_txdma_sync
> 
> Please leave the z85230 ones at least. They are an intentional part of
> the external API for writing other 85230 card drivers.

If they are part of an API, why aren't the prototypes for them in any 
header file?

> Alan

cu
Adrian

-- 

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

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

Re: IBM Thinkpad T42 - Looking for a Developer.

[Matti Aarnio]

On Thu, Apr 14, 2005 at 06:40:16PM -0400, abonilla wrote:
> On Thu, 14 Apr 2005 23:20:19 +0200 (CEST), Jesper Juhl wrote
> > On Thu, 14 Apr 2005, Alejandro Bonilla wrote:
...
> > >  This is located in my home PC, Won't be the fastest downloads...
> > >  
> > >  http://wifitux.com/finger/
> >  
> > Under what terms did you obtain these documents and from where? Are 
> > they completely freely distributable or are there strings attached?
> 
> I emailed the guys and they told me, "Hey, here you go, let me know if you
> want more information"
> 
> I guess it can't be more distributable. But as far as I got to read. The
> documents don't have too much information like for us to do a great Job. I
> think it also requires the making of a firmware.
> 
> I don't want to dissapoint you, but I hope I'm lost and that a driver can be
> done out of this.

There were two PDF documents.
The more useful one tells that there are two possible interfaces:
 - Async serial
 - USB

Could you show what/sbin/lsusb -vvtells in your T42 ?
Do that without external devices attached.
 
> > -- 
> > Jesper

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

[PATCH] crypto: resource release functions ought to check for NULL (crypto_free_tfm)

[Jesper Juhl]

As far as I'm aware there's a general concensus that functions that are 
responsible for freeing resources should be able to cope with being passed 
a NULL pointer. This makes sense as it removes the need for all callers to 
check for NULL, thus elliminating the bugs that happen when some forget 
(safer to just check centrally in the freeing function) and it also makes 
for smaller code all over due to the lack of all those NULL checks.
This patch makes it safe to pass the crypto_free_tfm() function a NULL 
pointer. Once this patch is applied we can start removing the NULL checks 
from the callers.  
Please consider applying.

Please CC: me on replies as I'm not subscribed to linux-crypto


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---

 api.c |   10 --
 1 files changed, 8 insertions(+), 2 deletions(-)

--- linux-2.6.12-rc2-mm3-orig/crypto/api.c  2005-04-11 21:20:39.0 
+0200
+++ linux-2.6.12-rc2-mm3/crypto/api.c   2005-04-15 01:05:52.0 +0200
@@ -163,8 +163,14 @@ out:
 
 void crypto_free_tfm(struct crypto_tfm *tfm)
 {
-   struct crypto_alg *alg = tfm->__crt_alg;
-   int size = sizeof(*tfm) + alg->cra_ctxsize;
+   struct crypto_alg *alg;
+   int size;
+
+   if (!tfm)
+   return;
+
+   alg = tfm->__crt_alg;
+   size = sizeof(*tfm) + alg->cra_ctxsize;
 
crypto_exit_ops(tfm);
crypto_alg_put(alg);



-- 
Jesper Juhl

PS. Please CC: me on replies to linux-crypto as I'm not subscribed to that 
list.


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

Re: poor SATA performance under 2.6.11 (with < 2.6.11 is OK)?

[Tomasz Torcz]

On Fri, Apr 15, 2005 at 12:08:15AM +0200, Tomasz Chmielewski wrote:
> >>The performance under 2.6 kernels is *very* poor (Timing buffered disk
> >>reads never more than 20 MB/sec); under 2.4 it runs quite fine (Timing
> >>buffered disk reads around 60 MB/sec).
> >
> >
> > 2.4 risk data corruption. 2.6 sata_sil.c contains blacklist for some
> >driver-controller combination.
> >
> > See: http://home-tj.org/m15w/
> 
> ...but this link just doesn't explain why performance is sooo bad with 
> 2.6.11.x kernels (Timing buffered disk reads at 10-20 MB/sec), and is 
> just OK with older 2.6 kernels (Timing buffered disk reads even at about 
> 100 MB/sec with 2.6.8.1).
> 
> any clue?

 The sata_sil blacklist grown over time. Older version didn't mark your
drive as bad. Check sata_sil history at
http://www.linuxhq.com/kernel/file/drivers/scsi/sata_sil.c ,
you may find exact time when your drive got blacklisted.

-- 
Tomasz TorczTo co nierealne - tutaj jest normalne.
[EMAIL PROTECTED]  Ziomale na życie mają tu patenty specjalne.

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

Re: Linux support for IBM ThinkPad Disk shock prevention update...

[Lee Revell]

On Thu, 2005-04-14 at 18:46 -0400, abonilla wrote:
> On Thu, 14 Apr 2005 17:15:16 -0400, Lee Revell wrote
> > On Thu, 2005-04-14 at 16:58 -0400, Shawn Starr wrote:
> > > We just need to figure
> > > out to get the specs from IBM
> > 
> > Best bet is probably reverse engineering it...
>  
> Lee, 
> 
> I know this is far from easy... but, What do we need to do this? I haven't
> seen such a cooler feature in a Thinkpad like the HDAPS. (Well, maybe the
> fingerprint reader) But, how can we / I help, if this is ever done?
> 

Please see:

http://dxr3.sourceforge.net/re.html

I have discovered several previously unknown emu10k1 hardware features
using this procedure to reverse engineer the Windows drivers, including
a per channel half loop interrupt, and added support to the Linux driver
for some of them.

It may be much easier to find the read and write register subroutines
than in the above guide.  The Windows driver I was working with had
exactly one subroutine that used the inb, inl, inw, outb, outw, outl
instructions, so it was trivial to set breakpoints to log all the port
I/O.  I later found it was even easier, the version of SoftIce I was
using allows you to set I/O breakpoints, so all you need to start
logging the register activity is the port.

I had a little trouble loading the IDA symbols into SoftICE at first,
just because the first few scripts I found on the net didn't work.

Some devices use memory mapped IO, I have no idea how you would RE
these.  Maybe someone else has some pointers?

Lee

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

Re: 2.6.11.7 ip_conntrack: table full, dropping packet.

[steve]

Are you sure the ip_conntrack itself isn't ACTUALLY full? Have you tried
increase this increasing this via
/proc/sys/net/ipv4/netfilter/ip_conntrack_max?
Just did it, thanks for reply. The 2.4 kernel I ran in the same box does 
not have such problem, maybe there is a change in the algorithm of 
calculating ip_contract_max in the recent kernel? What number you suggest 
(my firewall box has only 64Mb of RAM)

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

Serverworks LE and MTRR write-combining question

[Mike Russo]

Hello,
I'd like to begin by humbly thanking everyone who works on the kernel 
for their time and patience and energy. Without you my company would 
have had to spend a lot more on software and gotten nowhere near as much 
value in return!

I have a question regarding my motherboard's serverworks LE chipset and 
MTRR write-combining.
/usr/src/linux/arch/i386/kernel/cpu/mtrr/main.c will not allow 
write-combining because of the potential for data corruption,
but according to the following old LKML post, this is only true for 
certain old revisions of the motherboard:

http://www.ussg.iu.edu/hypermail/linux/kernel/0104.3/1007.html
This person even submitted a patch which looked like it was going to be 
accepted, but nothing happened after that. I checked the output of lspci 
and my revision (06) was the first one where the fix was included, 
according to this person's post. I therefore disabled the check and 
recompiled my kernel (2.6.12-rc2-mm3, which is noticeably faster than 
the default fedora core 3 kernel, with nearly the same configuration). X 
was able to setup a write-combining range (I had to disable one that was 
setup already but it didn't seem to affect anything else) and I've been 
working over four hours (wow!) without any corruption or lockups.  Just 
wondering if anyone had any updates on this issue, and if not, hey, 
that's why the source is there -- for me to screw around with. ;)

--
Mike Russo
ReadQ Systems, Inc.
(212) 425 3680 x105
Random quote of the day:
We are sorry.  We cannot complete your call as dialed.  Please check
the number and dial again or ask your operator for assistance.
This is a recording.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 1/1] nbd: Don't create all MAX_NBD devices by default all the time

[Domen Puncer]

On 14/04/05 13:23 +0200, Lars Marowsky-Bree wrote:
> From: Lars Marowsky-Bree <[EMAIL PROTECTED]>
> 
> This patches adds the "nbds_max" parameter to the nbd kernel module,
> which limits the number of nbds allocated. Previously, always all 128
> entries were allocated unconditionally, which used to waste resources
> and needlessly flood the hotplug system with events. (Defaults to 16
> now.)
> 
...
>  
> +module_param(nbds_max, int, 16);

This is permissions in sysfs (or 0 if no file is to be created).

> +MODULE_PARM_DESC(nbds_max, "How many network block devices to initialize.");
>  #ifndef NDEBUG
>  module_param(debugflags, int, 0644);
>  MODULE_PARM_DESC(debugflags, "flags for controlling debug output");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11.7 ip_conntrack: table full, dropping packet.

[Omkhar Arasaratnam]

[EMAIL PROTECTED] wrote:

>
> Hi,
>
> I thought this problem has been fixed but apparently not in 2.6.11.7.
> Is there any patch for it ? Thanks
>
>
Are you sure the ip_conntrack itself isn't ACTUALLY full? Have you tried
increase this increasing this via
/proc/sys/net/ipv4/netfilter/ip_conntrack_max?

O




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

Re: [INFO] Kernel strict versioning

[Franco \"Sensei\"]

Adrian Bunk wrote:
Are you sure you know what you are talking about?
ABI stability requires API stability [1].
Of course it requires API stability... as I said ``API and data 
structure stability should be something in mind''. I really meant that 
API shouldn't change suddenly. And from the moment in which API are 
stable, still having even different implementations, *then* (not before) 
probably ABI can be taken in consideration.

[1] you can break the API without breaking the ABI, but these are
mostly pathological examples
I don't want to even think about an incredible coincidence of having a 
_working_ ABI with different API... different function calls, different 
data structures, different behaviors, and still working in binary mode...

--
Sensei  
   
   
   


signature.asc
Description: OpenPGP digital signature

Re: [INFO] Kernel strict versioning

[Franco \"Sensei\"]

Horst von Brand wrote:
No I'm not confusing. As long as the .config has an influence on the 
makefiles I get different symbols names.
Nope.
I don't understand. The .config drives the kernel build, I don't get XFS 
functions and names if I don't compile it. I have different symbol 
names... At least, that's what I understand... and that's what 
happens... Never the same names on different kernels.

And kernels compiled with one compiler are different than those compiled
with another. And if you have preemption they are different. Don't forget
about clasic i386 vs i486 vs ... vs i686 (spinlocks generate different
code!). Then let's consider memory split: 2/2, 3/1, 3.5/0.5, ... Now throw
in assorted debugging options. On some architectures you have several
possible (reasonable!) page sizes.
Yes, ok.
Define "simple environment". Even Red Hat (they are /very/ interested in a
single kernel image, as it cuts down testing and bug tracking etc!) ships
half a dozen different kernels, tailored for different configurations. And
you'll find external modules (like for NTFS) compiled separately for each
of them.
Yes, but as long as you keep with the same configuration, no problem 
should arise in changing the kernel version.

Or having /your/ standard kernel on all 100 machines, compile once and copy
around. No need for /me/ to run your exact same configuration.
I probably expressed myself badly. I don't mean anyone having the same 
configuration... why on earth should it be?

Source compatibility is there.
Sort of.
I hope! :)
And A doesn't have some options I'd like, and others you loathe.
That's why you recompile, but why should you throw your other modules 
not included in the kernel release?

creating the kernel with additions and patches, and 
distributing them. Modules .A should work on .B,
Iff nothing changes. That isn't usually the case.
That's weird... why should things really change so drastically if the 
external interface still remains the same? It's probably a matter of 
abstraction...

The problem is that giving that guarantee costs developer time and
flexibility. The gain (given that source for recompilation is freely
available) is so minuscule that the consensus is that it just isn't worth
any extra hassle /at all/.
Ok.
And the decision to design thusly is completely conscicious, it is not a
random "it just turned out this way by mistake".
I just see advantages on ABI, and I think it's not bad talking about it...
I see many disadvantages to ABI, and it wouldn't be bad to look at them too.
I'd really like to know... I'm naive? Yes :) Of course, other than 
``more work'', but technical disadvantages...

--
Sensei  
   
   
   


signature.asc
Description: OpenPGP digital signature

Re: [PATCH encrypted swsusp 1/3] core functionality

[Matt Mackall]

On Thu, Apr 14, 2005 at 03:11:53PM -0700, Andy Isaacson wrote:
> On Thu, Apr 14, 2005 at 12:53:52PM -0700, Matt Mackall wrote:
> > On Thu, Apr 14, 2005 at 09:27:22PM +0200, Stefan Seyfried wrote:
> > > Matt Mackall wrote:
> > > > Any sensible solution here is going to require remembering passwords.
> > > > And arguably anywhere the user needs encrypted suspend, they'll want
> > > > encrypted swap as well.
> > > 
> > > But after entering the password and resuming, the encrypted swap is
> > > accessible again and my ssh-key may be lying around in it, right?
> > 
> > No. Because it's been zeroed in the resume process.
> 
> Zeroing the entire swsusp region is a big job, especially if you want to
> do it in a FIPS-conformant manner.  Hard to test that you've done it
> right and not missed any bits.
> 
> Much much easier to securely erase just the key storage.
> 
> And unless I'm missing something, you meant to say "it will have been
> zeroed" (after the patch under discussion is merged), right?  The
> current state of the art (as of 2.6.12-rc2) is that mlocked regions are
> written to the swsusp region and may linger there indefinitely after
> resume.

I was referring not to the current implementation but to an ideal
solution. Which is:

- use dm-crypt for swap and suspend
- overwrite mlocked regions on resume
- use per-boot session keys for the swap partition
- password protect the session key on suspend

This doesn't have great FIPS-secure deletion properties if the
attacker can steal the box after resume but while it's still running
(though it's not too bad). As we currently have no solution for
protecting the in-memory ssh-agent, as opposed to the one in the
suspend image, this attack vector is not all that important.

A much more likely vector is stealing the laptop while it's suspended.
And the encrypted swsusp patch has -zero- security here: it writes the
key in the header in the clear. It's rather odd that everyone's hung
up on the "box rooted after resume" attack and completely ignoring the
much more common "stole my laptop" attack.

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

Re: Linux support for IBM ThinkPad Disk shock prevention update...

[abonilla]

On Thu, 14 Apr 2005 17:15:16 -0400, Lee Revell wrote
> On Thu, 2005-04-14 at 16:58 -0400, Shawn Starr wrote:
> > We just need to figure
> > out to get the specs from IBM
> 
> Best bet is probably reverse engineering it...
 
Lee, 

I know this is far from easy... but, What do we need to do this? I haven't
seen such a cooler feature in a Thinkpad like the HDAPS. (Well, maybe the
fingerprint reader) But, how can we / I help, if this is ever done?

> Lee
> 

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

RE: IBM Thinkpad T42 - Looking for a Developer.

[abonilla]

On Thu, 14 Apr 2005 23:20:19 +0200 (CEST), Jesper Juhl wrote
> On Thu, 14 Apr 2005, Alejandro Bonilla wrote:
> 
> > 
> >  Jesper,
> >  
> > Believe me that I would be more happy to have this working... :)
> >  
> I've got a weeks vacation comming up next week - seems like a good 
> time to play with this :)

Well, I'll send you a six pack of Coca-Cola if you get this working. (Does not
apply if you are in EU ;-) )

> 
> >  This is located in my home PC, Won't be the fastest downloads...
> >  
> >  http://wifitux.com/finger/
> >  
> Under what terms did you obtain these documents and from where? Are 
> they completely freely distributable or are there strings attached?

I emailed the guys and they told me, "Hey, here you go, let me know if you
want more information"

I guess it can't be more distributable. But as far as I got to read. The
documents don't have too much information like for us to do a great Job. I
think it also requires the making of a firmware.

I don't want to dissapoint you, but I hope I'm lost and that a driver can be
done out of this.

> 
> -- 
> Jesper

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

Re: [INFO] Kernel strict versioning

[Franco \"Sensei\"]

Arjan van de Ven wrote:
this is a joke right? If you really think this you have no idea what ABI
stability means and how extremely hard it is to even sort of remotely
approach it.
I know it's really hard, the only way of possibly having ABI is plannig 
things really carefully about every single thing, so knowing every 
single piece... It's freakin' hard.

Trust me. It's *extremely* hard to impossible. Several security fixes
can only be fixed this way. And it's REALLY fragile even if for other
fixes. And I am very glad that the linux kernel people in general decide
to not go for abi stability, the hacks that would be needed would be so
obscene and the gains very very minimal. (it's open source, you have the
source after all!)
The gains are simply a rough reuse of older modules! Just joking...
I was simply wondering how guys like beos/haiku (it's a microkernel... i 
know... don't even think about starting a flame) could get ABI/API... I 
mean, if it's true that they have... I don't think it's because of c++ 
instead of plain c...

--
Sensei  
   
   
   


signature.asc
Description: OpenPGP digital signature

Re: poor SATA performance under 2.6.11 (with < 2.6.11 is OK)?

[Chris Wright]

* Tomasz Chmielewski ([EMAIL PROTECTED]) wrote:
> or should I wait for 2.6.11.7 (?), where it should be corrected?

Wait, no longer, 2.6.11.7 has been here already ;-)  However, nothing in
this area was touched.  If there's an outstanding issue, please chase it
down, and if it's reasonable regression fix we can consider it for
the -stable tree.

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

Re: 2.6.11.7 ip_conntrack: table full, dropping packet.

[steve]

Hi,
Maybe you are thinking of a problem I'm not aware of, but have you tried 
increasing /proc/sys/net/ipv4/ip_conntrack_max ?
Ah, just check and discover, in 2.6.8 system the number is 8184 and in the 
2.6.11.7 it is only 4088.

Will try to increase it now and see if the internet slugish disappear. 
Thanks for the tip.

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

Re: [PATCH encrypted swsusp 1/3] core functionality

[Matt Mackall]

On Thu, Apr 14, 2005 at 10:18:12PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > So we would need to zero out the suspend image in swap to prevent the
> > > retrieval of this data from the running machine (imagine a
> > > remote-root-hole).
> > >
> > > Zeroing out the suspend image means "write lots of megabytes to the
> > > disk" which takes a lot of time.
> > 
> > Zero only the mlocked regions. This should take essentially no time at
> > all. Swsusp knows which these are because they have to be mlocked
> 
> I believe this is tricky to implement. You are free to produce patch,
> and if that patch is nicer/simpler than Anreas's code, I may consider
> it.

If I understand swsusp correctly, we can simply set a bit in the pbe
struct to indicate that it's a locked page. 

This can be done by walking the vma list attached to the page's
address space with vma_prio_tree_foreach() and checking the
vma->vm_flags with VM_LOCKED. Analogous to what the swapout code does.

We can either do this in data_write() or preferably higher
(copy_data?) when we have the pfn handy. The lock bit can be stashed
in bit 0 of pbe->address, among other places. Then in data_read, we
check the bit and zero the source.

As I'm not about to actually use swsusp any time soon, someone else is
invited to implement the above. Should take about 10-20 lines.

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

Re: [INFO] Kernel strict versioning

[Franco \"Sensei\"]

Adrian Bunk wrote:
Linux kernel development is working different.
Getting changes quickly to the users is considered more important than 
API or even ABI compatibility.
I don't agree about API, but that's how it goes :) APIs are too 
important to bring them down from my point of view.

Offering improvements and new drivers to the users quickly is one way to 
care about the users.
Of course!
I do not claim to agree with all details of kernel development - but 
that's how it works.
I know, I can bring ideas but I think most of them are already somewhere :)
If you upgrade the kernel, simply get a version of your external modules 
that support your new kernel, compile them against the new kernel, and 
ship the external modules as part of the rollout of the new kernel.
That should be an option.
Kernel development is based on the fact that all drivers should be 
shipped with the kernel.
That can be partly true. There are many things which are gpl (so no 
licence problems) but are not in the kernel (see the pwc module).

If you buy hardware where no open source driver exists (often because 
the hardware manufacturer doesn't publish the hardware specifications) 
that's your problem.
I don't buy hardware not already tested with linux...
Space for the code behind all the obsolete interfaces.
I see.
There are optimizations that are not possible without breaking 
compatibility.

Documentation/stable_api_nonsense.txt contains examples.
Mh. Good thing to know.
You can't care about everything.
What you propose has both advantages and disadvantages for users of the 
kernel. It's general consensus among the kernel developers that the 
advantages are not worth the disadvantages.
That's why I was thinking about high modularity. Increasing the 
modularity and of course, having the same api gives extreme flexibility 
in changing the internal representation.

You know what? I was amazed about the /dev directory. When in 96 I first 
approached linux, I simply said: that's a smart thing, handling every 
kind of device the same way. Writing in a console is not different from
writing in /dev/hda. Amazing.

I was just thinking about something like that for kernel developing. 
Having an external representation which is stabe like it's /dev, but 
flexible internally (I don't mean that the kernel shoud provide a 
``devfs'' for module!). When a new piece should be added, it doesn't 
matter the version, the way of accessing things are still the same. How 
it works may differ a lot.

I strongly believe in high modularity. No questions about micro/macro 
kernel. Both have pros and cons. But I strongly believe that a very 
small kernel providing means for modules to work (in kernel space) is 
something at least easier to mantain, other than having a single piece. 
Modules were very nice when I began to write some of them (it was kernel 
2.0.x though --- slack 3.0) just for fun. Just add a new piece and 
you'll be able to use a new device, and they can be provided by anyone. 
New file systems, new sound cards, everything, just adding a ``small'' 
piece of code --- it was painful using isapnp package and have my weird 
soundcard work! Ah, good memories... :)

Cheers
--
Sensei  
   
   
   


signature.asc
Description: OpenPGP digital signature

Re: Exploit in 2.6 kernels

[John M Collins]

On Thu, 2005-04-14 at 16:02 -0400, Greg Folkert wrote:
> A-Freakin'-MEN me droogy.
> 
> Hehehe, either a slow system, or you know how to transfer a working
> setup to another machine.
> 
> My current image I use(d) for all of my machines was Built a long time
> ago, I think slink was what I used to build it. On a Pentium-90.
> 
> Currently on an Athlon XP3200+ with bells and whistles not even thought
> of then. Moved through about 12 machines since the beginning.

Just to say thanks again for your help - got 2.6.11.7 going everywhere
without hitches. Of course I just called the kernels 2.6.11.7 everywhere
so one version of the nvidia module fitted all.

I also stuck it on a Dell laptop I've got - a Latitude 100L - and at
last I've got ACPI working so I can see the battery level before it
dies.

Maybe our "visitor" did us a favour. (Sort of).

-- 
John Collins Xi Software Ltd www.xisl.com Tel: +44 (0)1707 886110
(Direct) +44 (0)7799 113162 (Mobile)

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

Re: 2.6.11.7 ip_conntrack: table full, dropping packet.

[Daniel Andersen]

[EMAIL PROTECTED] wrote:
Hi,
I thought this problem has been fixed but apparently not in 2.6.11.7. Is 
there any patch for it ? Thanks


Steve Kieu
PerfectPC Ltd. Technical Division.
Web: http://www.perfectpc.co.nz/
Ph: 04 461 7489
Mob: 021 137 0260
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Maybe you are thinking of a problem I'm not aware of, but have you tried 
increasing /proc/sys/net/ipv4/ip_conntrack_max ?

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

Re: [PATCH encrypted swsusp 1/3] core functionality

[Andy Isaacson]

On Thu, Apr 14, 2005 at 12:53:52PM -0700, Matt Mackall wrote:
> On Thu, Apr 14, 2005 at 09:27:22PM +0200, Stefan Seyfried wrote:
> > Matt Mackall wrote:
> > > Any sensible solution here is going to require remembering passwords.
> > > And arguably anywhere the user needs encrypted suspend, they'll want
> > > encrypted swap as well.
> > 
> > But after entering the password and resuming, the encrypted swap is
> > accessible again and my ssh-key may be lying around in it, right?
> 
> No. Because it's been zeroed in the resume process.

Zeroing the entire swsusp region is a big job, especially if you want to
do it in a FIPS-conformant manner.  Hard to test that you've done it
right and not missed any bits.

Much much easier to securely erase just the key storage.

And unless I'm missing something, you meant to say "it will have been
zeroed" (after the patch under discussion is merged), right?  The
current state of the art (as of 2.6.12-rc2) is that mlocked regions are
written to the swsusp region and may linger there indefinitely after
resume.

(I haven't read the code, that's just my understanding of the
discussion.)

> > Zeroing out the suspend image means "write lots of megabytes to the
> > disk" which takes a lot of time.
> 
> Zero only the mlocked regions. This should take essentially no time at
> all. Swsusp knows which these are because they have to be mlocked
> after resume as well. If it's not mlocked, it's liable to be swapped
> out anyway.

Ooof, that sounds complicated and error-prone, and likely to break
silently (a la input entropy gathering).

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

Re: poor SATA performance under 2.6.11 (with < 2.6.11 is OK)?

[Tomasz Chmielewski]

Tomasz Torcz wrote:
On Thu, Apr 14, 2005 at 06:23:30PM +0200, Tomasz Chmielewski wrote:
I have a Silicon Image SIL3112A SATA PCI controller + 2x 200GB, 8MB
Barracuda drives.

 Bad combination.
OK, from the link you gave I can see that there might be some problems 
with SIL3112 controller + seagate disks...


The performance under 2.6 kernels is *very* poor (Timing buffered disk
reads never more than 20 MB/sec); under 2.4 it runs quite fine (Timing
buffered disk reads around 60 MB/sec).

 2.4 risk data corruption. 2.6 sata_sil.c contains blacklist for some
driver-controller combination.
 See: http://home-tj.org/m15w/
...but this link just doesn't explain why performance is sooo bad with 
2.6.11.x kernels (Timing buffered disk reads at 10-20 MB/sec), and is 
just OK with older 2.6 kernels (Timing buffered disk reads even at about 
100 MB/sec with 2.6.8.1).

any clue?
or should I wait for 2.6.11.7 (?), where it should be corrected?
Tomek
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

E1000 - page allocation failure - saga continues :(

[Lukas Hejtmanek]

Hello,

today I tried 2.6.11.7 kernel with hoping that allocation failures disappear.
Unfortunately they did not.

Default min_free_kb is 3200kB.

Here is stack trace:

swapper: page allocation failure. order:0, mode:0x20
 [] __alloc_pages+0x2b3/0x420
 [] kmem_getpages+0x31/0xa0
 [] cache_grow+0xae/0x160
 [] ip_rcv_finish+0x0/0x280
 [] cache_alloc_refill+0x17b/0x230
 [] __kmalloc+0x88/0xa0
 [] alloc_skb+0x47/0xf0
 [] e1000_alloc_rx_buffers+0x57/0x100
 [] e1000_clean_rx_irq+0x1bf/0x4c0
 [] e1000_clean_tx_irq+0x14e/0x230
 [] e1000_clean+0x4d/0x100
 [] net_rx_action+0x81/0x110
 [] __do_softirq+0xba/0xd0
 [] do_softirq+0x2d/0x30
 [] irq_exit+0x39/0x40
 [] apic_timer_interrupt+0x1c/0x24
 [] default_idle+0x23/0x30
 [] cpu_idle+0x5f/0x70
 [] start_kernel+0x158/0x180
 [] unknown_bootoption+0x0/0x1e0
swapper: page allocation failure. order:0, mode:0x20
 [] __alloc_pages+0x2b3/0x420
 [] kmem_getpages+0x31/0xa0
 [] cache_grow+0xae/0x160
 [] as_next_request+0x38/0x50
 [] cache_alloc_refill+0x17b/0x230
 [] scsi_put_command+0x77/0xb0
 [] __kmalloc+0x88/0xa0
 [] alloc_skb+0x47/0xf0
 [] e1000_alloc_rx_buffers+0x57/0x100
 [] e1000_clean_rx_irq+0x1bf/0x4c0
 [] e1000_clean_tx_irq+0x14e/0x230
 [] e1000_clean+0x4d/0x100
 [] net_rx_action+0x81/0x110
 [] __do_softirq+0xba/0xd0
 [] do_softirq+0x2d/0x30
 [] irq_exit+0x39/0x40
 [] apic_timer_interrupt+0x1c/0x24
 [] default_idle+0x23/0x30
 [] cpu_idle+0x5f/0x70
 [] start_kernel+0x158/0x180
 [] unknown_bootoption+0x0/0x1e0
swapper: page allocation failure. order:1, mode:0x20
 [] __alloc_pages+0x2b3/0x420
 [] kmem_getpages+0x31/0xa0
 [] alloc_slabmgmt+0x57/0x70
 [] cache_grow+0xae/0x160
 [] cache_alloc_refill+0x17b/0x230
 [] __kmalloc+0x88/0xa0
 [] alloc_skb+0x47/0xf0
 [] tcp_collapse+0xf1/0x390
 [] tcp_prune_queue+0x94/0x1e0
 [] tcp_data_queue+0x3e4/0xb60
 [] tcp_ack+0x4b3/0x590
 [] tcp_rcv_established+0x22f/0x8d0
 [] mark_offset_tsc+0x1d9/0x2d0
 [] tcp_v4_do_rcv+0x12b/0x130
 [] tcp_v4_rcv+0x6f1/0x950
 [] ip_nat_fn+0x75/0x1d0
 [] ip_local_deliver_finish+0x0/0x220
 [] ip_local_deliver_finish+0xcf/0x220
 [] ip_local_deliver_finish+0x0/0x220
 [] nf_hook_slow+0xf1/0x130
 [] ip_local_deliver_finish+0x0/0x220
 [] ip_local_deliver_finish+0x0/0x220
 [] ip_rcv_finish+0x0/0x280
 [] ip_local_deliver+0x280/0x2b0
 [] ip_local_deliver_finish+0x0/0x220
 [] ip_rcv_finish+0x1f9/0x280
 [] ip_rcv_finish+0x0/0x280
 [] nf_hook_slow+0xf1/0x130
 [] ip_rcv_finish+0x0/0x280
 [] ip_rcv_finish+0x0/0x280
 [] ip_rcv+0x40e/0x4f0
 [] ip_rcv_finish+0x0/0x280
 [] netif_receive_skb+0x148/0x1d0
 [] e1000_clean_rx_irq+0x15c/0x4c0
 [] e1000_clean_tx_irq+0x14e/0x230
 [] e1000_clean+0x4d/0x100
 [] net_rx_action+0x81/0x110
 [] __do_softirq+0xba/0xd0
 [] do_softirq+0x2d/0x30
 [] irq_exit+0x39/0x40
 [] do_IRQ+0x1e/0x30
 [] common_interrupt+0x1a/0x20
 [] default_idle+0x23/0x30
 [] cpu_idle+0x5f/0x70
 [] start_kernel+0x158/0x180
 [] unknown_bootoption+0x0/0x1e0
swapper: page allocation failure. order:1, mode:0x20
 [] __alloc_pages+0x2b3/0x420
 [] kmem_getpages+0x31/0xa0
 [] alloc_slabmgmt+0x57/0x70
 [] cache_grow+0xae/0x160
 [] cache_alloc_refill+0x17b/0x230
 [] __kmalloc+0x88/0xa0
 [] alloc_skb+0x47/0xf0
 [] tcp_collapse+0xf1/0x390
 [] tcp_prune_queue+0x94/0x1e0
 [] tcp_data_queue+0x3e4/0xb60
 [] tcp_ack+0x4b3/0x590
 [] tcp_rcv_established+0x22f/0x8d0
 [] tcp_v4_do_rcv+0x12b/0x130
 [] tcp_v4_rcv+0x6f1/0x950
 [] ip_nat_fn+0x75/0x1d0
 [] ip_local_deliver_finish+0x0/0x220
 [] ip_local_deliver_finish+0xcf/0x220
 [] ip_local_deliver_finish+0x0/0x220
 [] nf_hook_slow+0xf1/0x130
 [] ip_local_deliver_finish+0x0/0x220
 [] ip_local_deliver_finish+0x0/0x220
 [] ip_rcv_finish+0x0/0x280
 [] ip_local_deliver+0x280/0x2b0
 [] ip_local_deliver_finish+0x0/0x220
 [] ip_rcv_finish+0x1f9/0x280
 [] ip_rcv_finish+0x0/0x280
 [] nf_hook_slow+0xf1/0x130
 [] ip_rcv_finish+0x0/0x280
 [] ip_rcv_finish+0x0/0x280
 [] ip_rcv+0x40e/0x4f0
 [] ip_rcv_finish+0x0/0x280
 [] netif_receive_skb+0x148/0x1d0
 [] e1000_clean_rx_irq+0x15c/0x4c0
 [] e1000_clean_tx_irq+0x14e/0x230
 [] e1000_clean+0x4d/0x100
 [] net_rx_action+0x81/0x110
 [] __do_softirq+0xba/0xd0
 [] do_softirq+0x2d/0x30
 [] irq_exit+0x39/0x40
 [] do_IRQ+0x1e/0x30
 [] common_interrupt+0x1a/0x20
 [] default_idle+0x23/0x30
 [] cpu_idle+0x5f/0x70
 [] start_kernel+0x158/0x180
 [] unknown_bootoption+0x0/0x1e0


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

2.6.11.7 ip_conntrack: table full, dropping packet.

[steve]

Hi,
I thought this problem has been fixed but apparently not in 2.6.11.7. Is 
there any patch for it ? Thanks


Steve Kieu
PerfectPC Ltd. Technical Division.
Web: http://www.perfectpc.co.nz/
Ph: 04 461 7489
Mob: 021 137 0260
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: IBM Thinkpad T42 - Looking for a Developer.

[Jesper Juhl]

On Thu, 14 Apr 2005, Alejandro Bonilla wrote:

> 
>  Jesper,
>  
>   Believe me that I would be more happy to have this working... :)
>  
I've got a weeks vacation comming up next week - seems like a good time to 
play with this :)


>  This is located in my home PC, Won't be the fastest downloads...
>  
>  http://wifitux.com/finger/
>  
Under what terms did you obtain these documents and from where? Are they 
completely freely distributable or are there strings attached?

-- 
Jesper  


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

Re: Linux support for IBM ThinkPad Disk shock prevention update...

[Lee Revell]

On Thu, 2005-04-14 at 16:58 -0400, Shawn Starr wrote:
> We just need to figure
> out to get the specs from IBM 

Best bet is probably reverse engineering it...

Lee

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

RE: Linux support for IBM ThinkPad Disk shock prevention update...

[Alejandro Bonilla]

>
> Has anyone started on such a project or would like to? We
> just need to figure
> out to get the specs from IBM I think such support would be good.
>
> Shawn.
> -

I believe I have emailed IBM about 20 times about this, and have sent emails
to the people from IBM Research and the same guys that did the Security chip
Encryption project for Linux and they tried looking into it, but never heard
really anything back. Maybe now that they are with Lenovo, they probably
could release some more specs...

- Alejandro

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

RE: IBM Thinkpad T42 - Looking for a Developer.

[Alejandro Bonilla]

 Jesper,
 
Believe me that I would be more happy to have this working... :)
 
 This is located in my home PC, Won't be the fastest downloads...
 
 http://wifitux.com/finger/
 
 - Alejandro.
 
> > -Original Message-
> > From: Jesper Juhl [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, April 14, 2005 03:07 PM
> > To: Alejandro Bonilla
> > Cc: linux-kernel@vger.kernel.org
> > Subject: Re: IBM Thinkpad T42 - Looking for a Developer.
> > 
> > 
> > On Thu, 14 Apr 2005, Alejandro Bonilla wrote:
> > 
> > > Hi All,
> > > 
> > >   Sorry if this thread has been already discussed or if 
> > this is not the right
> > > place. I'm looking for a driver developer to make the 
> > driver for the IBM
> > > Thinkpads Fingerprint reader.
> > > 
> > >   I have all the documentation required from the Makers 
> > of the hardware, the
> > > so called Programming API and Datasheet. Unfortunately I 
> > cannot provide you
> > > with my hardware ;-) but only with a dedicated ssh 
> > connection to my PC and
> > > me standing in front of the PC for when you ask me to 
> > reboot it cause it
> > > locked up.
> > > 
> > I have a ThinkPad T42 and would be interrested in those docs. 
> > If you are 
> > allowed to distribute those documents then please make them 
> available 
> > somewhere and reply back with the URL.
> > 
> > -- 
> > Jesper Juhl
> > 
> > 
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: BUGs in 2.6.12-rc2-RT-V0.7.45-01

[William Weston]

On Wed, 13 Apr 2005, Ingo Molnar wrote:

> what are you using kprobes for? Do you get lockups even if you disable 
> kprobes?

Various processes will lockup on the P4/HT system, usually while under
some load.  The processes cannot be killed.  X will lockup once or twice a
day (which means my console, and thus sysrq, are toast), but I can still
ssh in.  Nothing is logged by the kernel.  Are there any post-lockup 
forensics that can be performed before I reboot?

Regards,
--William Weston

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

Re: IBM Thinkpad T42 - Looking for a Developer.

[Jesper Juhl]

On Thu, 14 Apr 2005, Alejandro Bonilla wrote:

> Hi All,
> 
>   Sorry if this thread has been already discussed or if this is not the 
> right
> place. I'm looking for a driver developer to make the driver for the IBM
> Thinkpads Fingerprint reader.
> 
>   I have all the documentation required from the Makers of the hardware, 
> the
> so called Programming API and Datasheet. Unfortunately I cannot provide you
> with my hardware ;-) but only with a dedicated ssh connection to my PC and
> me standing in front of the PC for when you ask me to reboot it cause it
> locked up.
> 
I have a ThinkPad T42 and would be interrested in those docs. If you are 
allowed to distribute those documents then please make them available 
somewhere and reply back with the URL.

-- 
Jesper Juhl


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

Re: spurious 8259A interrupt: IRQ7

[Bjorn Helgaas]

On Thu, 2005-04-14 at 16:56 -0400, Lee Revell wrote:
> Is the VIA IRQ fixup related to the "spurious interrupts" messages in
> any way?  Googling the 2.4 threads on the issue gave me the impression
> that it's related to broken hardware.  I think excessive disk activity
> might trigger it.

If you need the VIA IRQ fixup and don't have it, I would expect
some interrupt to be routed to the wrong IRQ.  That might give
you a "spurious interrupt" on the wrong IRQ, but your device would
probably just not work at all.


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

Linux support for IBM ThinkPad Disk shock prevention update...

[Shawn Starr]

Has anyone started on such a project or would like to? We just need to figure
out to get the specs from IBM I think such support would be good. 

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

Re: spurious 8259A interrupt: IRQ7

[Lee Revell]

On Thu, 2005-04-14 at 14:43 -0600, Bjorn Helgaas wrote:
> On Thu, 2005-04-14 at 13:11 -0400, Lee Revell wrote:
> > I get this message occasionally on both my machines.  I googled and saw
> > some references to this message on 2.4 but nothing for 2.6.  Some of the
> > references were to APIC, which I don't have enabled.
> > 
> > Both machines are using VIA chipsets and display the "VIA IRQ fixup"
> > message on boot.  I think this behavior started about the same time that
> > message started to appear.
> 
> The VIA IRQ fixup in 2.6.11 is broken.  It works for some, but
> not all boxes with VIA hardware.
> 
> There's a fix in 2.6.12-rc2-mm3.  Actually, I doubt that it will
> help you, though -- the 2.6.11 breakage is such that some machines
> that need the fixup don't get it (and don't print the "VIA IRQ
> fixup message").
> 

Is the VIA IRQ fixup related to the "spurious interrupts" messages in
any way?  Googling the 2.4 threads on the issue gave me the impression
that it's related to broken hardware.  I think excessive disk activity
might trigger it.

Anyway it's low priority as the message appears to be completely
harmless.

Lee

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

[2.6.12-rc2][panic][NET] qdisc_restart - When loading ipw2200 driver - not mangled

[Shawn Starr]

Here's the dmesg/panic dump:

Any problems with the Network scheduling in 2.6.12-rc2?

[4294667.296000] Linux version 2.6.12-rc2 ([EMAIL PROTECTED]) (gcc version 
4.0.0 20050319 (prerelease)) #1 Wed Apr 13 11:38:19 EDT 2005
[4294667.296000] BIOS-provided physical RAM map:
[4294667.296000]  BIOS-e820:  - 0009f000 (usable)
[4294667.296000]  BIOS-e820: 0009f000 - 000a (reserved)
[4294667.296000]  BIOS-e820: 000dc000 - 0010 (reserved)
[4294667.296000]  BIOS-e820: 0010 - 3ff6 (usable)
[4294667.296000]  BIOS-e820: 3ff6 - 3ff77000 (ACPI data)
[4294667.296000]  BIOS-e820: 3ff77000 - 3ff79000 (ACPI NVS)
[4294667.296000]  BIOS-e820: 3ff8 - 4000 (reserved)
[4294667.296000]  BIOS-e820: ff80 - 0001 (reserved)
[4294667.296000] 127MB HIGHMEM available.
[4294667.296000] 896MB LOWMEM available.
[4294667.296000] DMI present.
[4294667.296000] ACPI: PM-Timer IO Port: 0x1008
[4294667.296000] Allocating PCI resources starting at 4000 (gap: 
4000:bf80)
[4294667.296000] Built 1 zonelists
[4294667.296000] Kernel command line: root=/dev/hda1 ro acpi_sleep=s3_bios 
hdc=ide-cd lapic [EMAIL PROTECTED]/eth0,[EMAIL PROTECTED]/00:0D:60:3C:3A:3F
[4294667.296000] ide_setup: hdc=ide-cd
[4294667.296000] netconsole: local port 6665
[4294667.296000] netconsole: local IP 172.25.244.212
[4294667.296000] netconsole: interface eth0
[4294667.296000] netconsole: remote port 9353
[4294667.296000] netconsole: remote IP 172.25.244.222
[4294667.296000] netconsole: remote ethernet address 00:0d:60:3c:3a:3f
[4294667.296000] Local APIC disabled by BIOS -- reenabling.
[4294667.296000] Found and enabled local APIC!
[4294667.296000] Initializing CPU#0
[4294667.296000] CPU 0 irqstacks, hard=c060a000 soft=c0609000
[4294667.296000] PID hash table entries: 4096 (order: 12, 65536 bytes)
[4294667.296000] Detected 1798.930 MHz processor.
[4294667.296000] Using pmtmr for high-res timesource
[4294667.296000] Console: colour VGA+ 80x25
[4294670.127000] Dentry cache hash table entries: 131072 (order: 7, 524288 
bytes)
[4294670.127000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[4294670.16] Memory: 1032876k/1047936k available
(3693k kernel code, 14480k reserved, 1200k data, 236k init, 130432k highmem)
[4294670.16] Checking if this processor honours the WP bit even in 
supervisor mode... Ok.
[4294670.183000] Mount-cache hash table entries: 512
[4294670.183000] CPU: L1 I cache: 32K, L1 D cache: 32K
[4294670.183000] CPU: L2 cache: 2048K
[4294670.183000] Intel machine check architecture supported.
[4294670.183000] Intel machine check reporting enabled on CPU#0.
[4294670.183000] CPU: Intel(R) Pentium(R) M processor 1.80GHz stepping 06
[4294670.183000] Enabling fast FPU save and restore... done.
[4294670.183000] Enabling unmasked SIMD FPU exception support... done.
[4294670.183000] Checking 'hlt' instruction... OK.
[4294670.187000]  tbxface-0118 [02] acpi_load_tables : ACPI Tables successfully 
acquired
[4294670.399000] Parsing all Control 
Methods:..
..
...
 
[4294670.869000] Table [DSDT](id F005) - 1342 Objects with 64 Devices 403 
Methods 19 Regions
[4294670.869000] Parsing all Control Methods:.
[4294670.87] Table [SSDT](id F003) - 1 Objects with 0 Devices 1 Methods 0 
Regions
[4294670.87] ACPI Namespace successfully loaded at root c0632620
[4294670.87] ACPI: setting ELCR to 0200 (from 0e28)
[4294670.88] evxfevnt-0094 [03] acpi_enable   : Transition to ACPI mode 
successful
[4294670.982000] NET: Registered protocol family 16
[4294670.983000] PCI: PCI BIOS revision 2.10 entry at 0xfd8d6, last bus=8
[4294670.983000] PCI: Using configuration type 1
[4294670.983000] mtrr: v2.0 (20020519)
[4294670.991000] ACPI: Subsystem revision 20050309
[4294671.006000] evgpeblk-0979 [06] ev_create_gpe_block   : GPE 00 to 1F [_GPE] 
4 regs on int 0x9
[4294671.006000] evgpeblk-0987 [06] ev_create_gpe_block   : Found 7 Wake, 
Enabled 0
Runtime GPEs in this block
[4294671.007000] ACPI: Found ECDT
[4294671.017000] Completing Region/Field/Buffer/Package 
initialization:..
..
 
[4294671.249000] Initialized 18/19 Regions 123/123 Fields 72/72 Buffers 39/46 
Packages (1352 nodes)
[4294671.249000] Executing all Device _STA and_INI 

IBM Thinkpad T42 - Looking for a Developer.

[Alejandro Bonilla]

Hi All,

Sorry if this thread has been already discussed or if this is not the 
right
place. I'm looking for a driver developer to make the driver for the IBM
Thinkpads Fingerprint reader.

I have all the documentation required from the Makers of the hardware, 
the
so called Programming API and Datasheet. Unfortunately I cannot provide you
with my hardware ;-) but only with a dedicated ssh connection to my PC and
me standing in front of the PC for when you ask me to reboot it cause it
locked up.

Feel free to e-mail me and ask for anything if you wish to do this 
driver.
I think is a nice approach and would be cool to have the support of such
nice feature. As far as I have seen, only the device ID or so has been added
to the kernel, cause I can see something about it while booting.

Thanks for the time,

- Alejandro.

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

[no subject]

[Allison]

I am trying to simply print out the module names and code sizes.
I am just learning how to rtraverse these data structures.

Also, on what basis is the decision made whether to export a symbol or not ?

thanks,
Allison

Arjan van de Ven wrote:
> On Thu, 2005-04-14 at 19:53 +, Allison wrote:
> > 
> > I am trying to access the module list kernel data structure from a
> > kernel module. If I gather correctly, module_list is the symbol that
> > is the head pointer of this list.
> 
> can you explain what you want to do with this symbol ?
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disc driver is module, software suspend fails

[Pavel Machek]

Hi!


> > > This patch makes software_resume not a late_initcall but rather an
> > > external subroutine similar to software_suspend, and calls it at the
> > > beginning of mount_root (in init/do_mounts.c), just _after_ the initrd
> > > (if any) and its driver have been seen
> > 
> > But the patch is very dangerous. Unsuspecting users will see their
> > systems resumed after unsafe initrd is ran. It is okay for you,
> > through..
> > 
> > What you want to do si to audit your initrd, then add echo to
> > /sys/power/resume at the end...
> 
> I think you expressed similar reservations earlier but I'm not sure if I 
> understand what your issue is.  Are you saying (please let me know which if 
> any of these threats are the ones that concern you):
> 
> 1.  If the initrd mounted any filesystem read-write, or any journalled 
> filesystem, and left it mounted, that would be bad.

Yes. (Note that mounting in the first place is the problem. Even if
you umount it, you already did some changes on disk, BAD).

> 2.  If the initrd started an ordinary process (or a kernel thread?) and 
> left it running, that would be bad.  The ata_piix driver really does 
> create a kernel thread, though I believe it exists only during actual data 
> transfer.

Should not be a problem with new refrigerator setup.

> 3.  The initrd is copied into a ramdisc which is then mounted.  It's still 
> mounted when software_resume is called (as the patch is arranged presently, 
> or if the initrd does "echo resume > /sys/power/state"), and jimc isn't too 
> sure where the ramdisc's memory goes at that point.

Should not me a problem.

> I was hoping to have a single point in the boot-up code where 
> software_resume happened, rather than multiple places or, heaven forbid,
> calling it repeatedly at various steps in the boot process.  I think we can 
> justify some effort to avoid the situation where software_resume is called 
> before initrd loading, and it sometimes refuses to load the image, and then 
> is called again by the initrd.  

I don't see why calling it repeatedly would be that bad. In fact, it
is what we are doing just now. You can try to resume as many times as
you wish (by echo resume...), but obviously at most one of those will
succeed.

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

Re: spurious 8259A interrupt: IRQ7

[Bjorn Helgaas]

On Thu, 2005-04-14 at 13:11 -0400, Lee Revell wrote:
> I get this message occasionally on both my machines.  I googled and saw
> some references to this message on 2.4 but nothing for 2.6.  Some of the
> references were to APIC, which I don't have enabled.
> 
> Both machines are using VIA chipsets and display the "VIA IRQ fixup"
> message on boot.  I think this behavior started about the same time that
> message started to appear.

The VIA IRQ fixup in 2.6.11 is broken.  It works for some, but
not all boxes with VIA hardware.

There's a fix in 2.6.12-rc2-mm3.  Actually, I doubt that it will
help you, though -- the 2.6.11 breakage is such that some machines
that need the fixup don't get it (and don't print the "VIA IRQ
fixup message").

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

Re: hard lockup on nx5000 laptop with 2.6.11+hack and FC2's 2.6.10-1.770_FC2

[Ben Greear]

Yu, Luming wrote:
Do you have acpi enabled?  
 

Yes, in both of my custom kernels, and probably in the FC2 one as well.
If the problem just happend with acpi enabled, please
try latest acpi patch through testing latest mm tree, If it still doesn't 
work, please file a bug on www.kernel.org
 

I'll try the latest -mm and report back.
Thanks,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc  http://www.candelatech.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[no subject]

[kwosvlowp]

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

Re: [PATCH] Fix reloading GDT on ACPI S3 wakeup (fwd)

[Pavel Machek]

Hi!

> This patch - based on
> http://marc.theaimsgroup.com/?l=linux-kernel=110055503031009=2 -
> makes ACPI S3 wakeup work for me on a ThinkPad T40p laptop with a SMP
> kernel. Without it only UP kernels work. I've been using the patch for
> three months now without any issues.
> 
> The ACPI resume code currently uses a real-mode 16-bit lgdt instruction
> to reload the GDT.  This only restores the lower 24 bits of the GDT base
> address.  In recent SMP kernels, the GDT seems to have moved out of the
> lower 16 megs, thereby causing the ACPI resume to fail -- an invalid GDT
> was being loaded.
> 

Actually x86-64 needs this, too. Any testers?
Pavel

--- clean/arch/x86_64/kernel/acpi/wakeup.S  2005-01-22 21:24:51.0 
+0100
+++ linux/arch/x86_64/kernel/acpi/wakeup.S  2005-04-14 22:34:18.0 
+0200
@@ -67,7 +67,7 @@
shll$4, %eax
addl$(gdta - wakeup_code), %eax
movl%eax, gdt_48a +2 - wakeup_code
-   lgdt%ds:gdt_48a - wakeup_code   # load gdt with 
whatever is
+   lgdtl   %ds:gdt_48a - wakeup_code   # load gdt with whatever is
# appropriate
 
movl$1, %eax# protected mode (PE) bit


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

Re: [INFO] Kernel strict versioning

[Horst von Brand]

"Franco \"Sensei\"" <[EMAIL PROTECTED]> said:
> David Lang wrote:
> > some config changes are additions, some redefine things.
> > 
> > you are mistakeing the .config file for a symbol table.

> No I'm not confusing. As long as the .config has an influence on the 
> makefiles I get different symbols names.

Nope.

> > for example if you compile a kernel with SMP=y you get different code 
> > then if you compile with SMP=n
> > 
> > if you have the same kernel version on identical machines, but with the 
> > SMP option different on the two different machines you cannot use the 
> > same module binary on both of them.

> Of course, but It's cleare that machines with SMP are different from a 
> simple mono-cpu.

And kernels compiled with one compiler are different than those compiled
with another. And if you have preemption they are different. Don't forget
about clasic i386 vs i486 vs ... vs i686 (spinlocks generate different
code!). Then let's consider memory split: 2/2, 3/1, 3.5/0.5, ... Now throw
in assorted debugging options. On some architectures you have several
possible (reasonable!) page sizes.

> It's not an issue talking about smp vs. not-smp. Let's talk about a 
> machine: it's useless arguing about Cray while I'm talking about a 
> simple environment.

Define "simple environment". Even Red Hat (they are /very/ interested in a
single kernel image, as it cuts down testing and bug tracking etc!) ships
half a dozen different kernels, tailored for different configurations. And
you'll find external modules (like for NTFS) compiled separately for each
of them.

> Every kernel has always the distinction about smp. So it's not a big 
> problem.

And it has distinctions on dozens of other configuration options too.

[...]

> Finding a bug in the kernel source and patching it, must be a careful 
> step, because if I have to mantain 100 machines, and I know that 
> applying the patch will result in a broken kernel modules, I'm not happy 
> with it. I must go manually on each machine, apply the patch, recompile 
> the modules... Makes me think about NOT applying the patch.

Or having /your/ standard kernel on all 100 machines, compile once and copy
around. No need for /me/ to run your exact same configuration.

[...]

> Source compatibility is there.

Sort of.

>Now, you're talking about issues which 
> are not your buisness: a binary distribution must take care of how the
> kernel it's compiled. As long as it uses the same gcc and switches, it's
> ok.

Yes, it is their bussiness.

> Practically, if suse has kernel-2.6.A and kernel-modules-2.6.A it knows 
> how they're compiled, and they work everywhere. Of course, it has also 
> kernel-2.6.A-SMP and its modules.

And A doesn't have some options I'd like, and others you loathe.

> When 2.6.B is released, using ABI will just result in another 
> compilation,

Right.

>  creating the kernel with additions and patches, and 
> distributing them. Modules .A should work on .B,

Iff nothing changes. That isn't usually the case.

>  like I do with OpenAFS, 
> Every kernel update shouldn't break the magic :)

The problem is that giving that guarantee costs developer time and
flexibility. The gain (given that source for recompilation is freely
available) is so minuscule that the consensus is that it just isn't worth
any extra hassle /at all/.

> > but 2.6.11.7 is not nessasarily binary compatable with 2.6.11.7, let 
> > alone something drasticly different (say 2.6.11.6)

> Sure, because it's not designed to be so.

And the decision to design thusly is completely conscicious, it is not a
random "it just turned out this way by mistake".

> I just see advantages on ABI, and I think it's not bad talking about it...

I see many disadvantages to ABI, and it wouldn't be bad to look at them too.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PCI interrupt problem: e1000 & Super-Micro X6DVA motherboard

[Ben Greear]

Ganesh Venkatesan wrote:
Ben:
Have you checked if the BIOS on the super micro machine is the latest
and greatest. I have had interrupt routing issues very similar to the
one you are describing due to a BIOS Interrupt Routing issue. Moving
to newer BIOS fixed it.
 

A new BIOS didn't help.  Super-Micro eventually reproduced the problem, 
and told me
the fix was to send the MB back to them so they could solder another part
onto it  I haven't received the MB back yet so I don't know if they 
really
have a fix for it or not...

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

[2.6.12-rc2][panic][NET] qdisc_restart - When loading ipw2200 driver

[Shawn Starr]

Here's the dmesg/panic dump: 

Any problems with the Network scheduling in
2.6.12-rc2?

[4294667.296000] Linux version 2.6.12-rc2
([EMAIL PROTECTED]) (gcc version 4.0.0 20050319
(prerelease)) #1 Wed Apr 13 11:38:19 EDT 2005
[4294667.296000] BIOS-provided physical RAM map:
[4294667.296000]  BIOS-e820:  -
0009f000 (usable)
[4294667.296000]  BIOS-e820: 0009f000 -
000a (reserved)
[4294667.296000]  BIOS-e820: 000dc000 -
0010 (reserved)
[4294667.296000]  BIOS-e820: 0010 -
3ff6 (usable)
[4294667.296000]  BIOS-e820: 3ff6 -
3ff77000 (ACPI data)
[4294667.296000]  BIOS-e820: 3ff77000 -
3ff79000 (ACPI NVS)
[4294667.296000]  BIOS-e820: 3ff8 -
4000 (reserved)
[4294667.296000]  BIOS-e820: ff80 -
0001 (reserved)
[4294667.296000] 127MB HIGHMEM available.
[4294667.296000] 896MB LOWMEM available.
[4294667.296000] DMI present.
[4294667.296000] ACPI: PM-Timer IO Port: 0x1008
[4294667.296000] Allocating PCI resources starting at
4000 (gap: 4000:bf80)
[4294667.296000] Built 1 zonelists
[4294667.296000] Kernel command line: root=/dev/hda1
ro acpi_sleep=s3_bios hdc=ide-cd lapic
[EMAIL PROTECTED]/eth0,[EMAIL PROTECTED]/00:0D:60:3C:3A:3F
[4294667.296000] ide_setup: hdc=ide-cd
[4294667.296000] netconsole: local port 6665
[4294667.296000] netconsole: local IP 172.25.244.212
[4294667.296000] netconsole: interface eth0
[4294667.296000] netconsole: remote port 9353
[4294667.296000] netconsole: remote IP 172.25.244.222
[4294667.296000] netconsole: remote ethernet address
00:0d:60:3c:3a:3f
[4294667.296000] Local APIC disabled by BIOS --
reenabling.
[4294667.296000] Found and enabled local APIC!
[4294667.296000] Initializing CPU#0
[4294667.296000] CPU 0 irqstacks, hard=c060a000
soft=c0609000
[4294667.296000] PID hash table entries: 4096 (order:
12, 65536 bytes)
[4294667.296000] Detected 1798.930 MHz processor.
[4294667.296000] Using pmtmr for high-res timesource
[4294667.296000] Console: colour VGA+ 80x25
[4294670.127000] Dentry cache hash table entries:
131072 (order: 7, 524288 bytes)
[4294670.127000] Inode-cache hash table entries: 65536
(order: 6, 262144 bytes)
[4294670.16] Memory: 1032876k/1047936k available
(3693k kernel code, 14480k reserved, 1200k data, 236k
init, 130432k highmem)
[4294670.16] Checking if this processor honours
the WP bit even in supervisor mode... Ok.
[4294670.183000] Mount-cache hash table entries: 512
[4294670.183000] CPU: L1 I cache: 32K, L1 D cache: 32K
[4294670.183000] CPU: L2 cache: 2048K
[4294670.183000] Intel machine check architecture
supported.
[4294670.183000] Intel machine check reporting enabled
on CPU#0.
[4294670.183000] CPU: Intel(R) Pentium(R) M processor
1.80GHz stepping 06
[4294670.183000] Enabling fast FPU save and restore...
done.
[4294670.183000] Enabling unmasked SIMD FPU exception
support... done.
[4294670.183000] Checking 'hlt' instruction... OK.
[4294670.187000]  tbxface-0118 [02] acpi_load_tables  
   : ACPI Tables successfully acquired
[4294670.399000] Parsing all Control
Methods:...
[4294670.869000] Table [DSDT](id F005) - 1342 Objects
with 64 Devices 403 Methods 19 Regions
[4294670.869000] Parsing all Control Methods:.
[4294670.87] Table [SSDT](id F003) - 1 Objects
with 0 Devices 1 Methods 0 Regions
[4294670.87] ACPI Namespace successfully loaded at
root c0632620
[4294670.87] ACPI: setting ELCR to 0200 (from
0e28)
[4294670.88] evxfevnt-0094 [03] acpi_enable   
   : Transition to ACPI mode successful
[4294670.982000] NET: Registered protocol family 16
[4294670.983000] PCI: PCI BIOS revision 2.10 entry at
0xfd8d6, last bus=8
[4294670.983000] PCI: Using configuration type 1
[4294670.983000] mtrr: v2.0 (20020519)
[4294670.991000] ACPI: Subsystem revision 20050309
[4294671.006000] evgpeblk-0979 [06]
ev_create_gpe_block   : GPE 00 to 1F [_GPE] 4 regs on
int 0x9
[4294671.006000] evgpeblk-0987 [06]
ev_create_gpe_block   : Found 7 Wake, Enabled 0
Runtime GPEs in this block
[4294671.007000] ACPI: Found ECDT
[4294671.017000] Completing
Region/Field/Buffer/Package
initialization:
[4294671.249000] Initialized 18/19 Regions 123/123
Fields 72/72 Buffers 39/46 Packages (1352 nodes)
[4294671.249000] Executing all Device _STA and_INI

Re: [PATCH encrypted swsusp 1/3] core functionality

[Pavel Machek]

Hi!

> > So we would need to zero out the suspend image in swap to prevent the
> > retrieval of this data from the running machine (imagine a
> > remote-root-hole).
> >
> > Zeroing out the suspend image means "write lots of megabytes to the
> > disk" which takes a lot of time.
> 
> Zero only the mlocked regions. This should take essentially no time at
> all. Swsusp knows which these are because they have to be mlocked

I believe this is tricky to implement. You are free to produce patch,
and if that patch is nicer/simpler than Anreas's code, I may consider
it.

> But this is all solvable without resorting to yet another encrypted
> block device scheme. Such a scheme shouldn't even be considered until
> all the other options are thoroughly explored. Any scheme that's
> encrypting the suspend image and then storing the key in the clear is
> either obviously broken or obviously doesn't actually need encryption.

Andreas solved real problem. You are waving hands. Obviously your next
mail should contain a patch.
Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [INFO] Kernel strict versioning

[Adrian Bunk]

On Thu, Apr 14, 2005 at 12:40:09PM -0500, Franco Sensei wrote:
> Adrian Bunk wrote:
> >>When a new component is added to the kernel, let's say support for a new 
> >>file system, a .config entry is created (CONFIG_MYFS=y|m). Why is this 
> >>entry breaking compatibility? I mean, symbols still remains the same. 
> >>The addition of symbols is not a breaking point.
> >
> >That's clear.
> >
> >You said you've read Documentation/stable_api_nonsense.txt .
> >Please read the USB example in this document as an example when even API 
> >compatibility was a problem.
> 
> The example says that the usb layer changed from synchronous to 
> asynchronous and changed the data model. I'd say changing drastically is 
> a big issue. I'd say it would be a change from 2.4 to 2.6 series. It 
> does not mean that in a year we have to stick with the same version, in 
> a year things can change drastically and so should be the version.

Linux kernel development is working different.

Getting changes quickly to the users is considered more important than 
API or even ABI compatibility.

> I see one big thing: developement should be careful about who uses the 
> kernel and not caring about it alone, since it's not something useful by 
> itself :)

Offering improvements and new drivers to the users quickly is one way to 
care about the users.

I do not claim to agree with all details of kernel development - but 
that's how it works.

> >If you upgrade your kernel, you'll also upgrade the modules shipped with 
> >the kernel.
> 
> Yes! You said it yourself: shipped with the kernel. The world does not 
> rely only on the kernel. I have to administer a department, and I use 
> other modules that won't be in the kernel, such as afs.

If you upgrade the kernel, simply get a version of your external modules 
that support your new kernel, compile them against the new kernel, and 
ship the external modules as part of the rollout of the new kernel.

>...
> >In an open source system, it's usually more common that all drivers are 
> >shipped with the kernel. Therefore, there isn't such a big need for 
> >API+ABI compatibility since you can change all modules using an API when 
> >changing an API. And ABI compatibility isn't required because you can 
> >recompile the modules every time you recompile the kernel.
> 
> That's not entirely true. Kernel does not have all the modules someone 
> can use, and I made an example with my own department. The kernel should 
> make the machine work, providing means to operate the hardware. So, in 
> no case one can imagine having every single driver on this earth built 
> in the kernel...

Kernel development is based on the fact that all drivers should be 
shipped with the kernel.

If you buy hardware where no open source driver exists (often because 
the hardware manufacturer doesn't publish the hardware specifications) 
that's your problem.

> >ABI compatibility between kernel versions costs the following:
> >- space for all users of the kernel
> 
> I don't understand. Space of what?

Space for the code behind all the obsolete interfaces.

> >- speed of the kernel
> 
> Mmh... why should it be? Optimizing the kernel is possible, speeding it 
> up, without affecting ABI. Adding new components can't affect speed as 
> long as it won't affect it wihout ABI (adding parts does of course 
> affect the speed, but it's not different from ABI to non-ABI).

There are optimizations that are not possible without breaking 
compatibility.

Documentation/stable_api_nonsense.txt contains examples.

> >- much extra work and checking when doing any changes
> 
> Of course! You're developing a kernel to be used by other people! It's 
> quite... straightforward to be really careful about changes.
>...

You can't care about everything.

What you propose has both advantages and disadvantages for users of the 
kernel. It's general consensus among the kernel developers that the 
advantages are not worth the disadvantages.

cu
Adrian

-- 

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

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