[2.6.12-rc1] suspend to Disk success - T42 laptop

[Shawn Starr]

Hello Pavel, I can now suspend to disk on the laptop with 2.6.12-rc1. There is 
no failures anymore. It resumes perfectly.

Thank you.

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: [PATCH 0/6] freepgt: free_pgtables shakeup

[Russell King]

On Sun, Mar 27, 2005 at 10:17:39AM -0800, David S. Miller wrote:
> On Sun, 27 Mar 2005 08:57:25 +0100
> Russell King <[EMAIL PROTECTED]> wrote:
> 
> > Unfortunately not - free_pgd_slow doesn't have any knowledge about the
> > mm_struct that the pgd was associated with.
> 
> You could store the mm pointer in the page struct of the
> pgd, we used to that before set_pte_at() existed on
> sparc64 and ppc64 for pte level tables.
> 
> page->mapping and page->index are basically free game for
> tracking information assosciated with page table chunks.

Why would I want to do this, given that decrementing mm->nr_ptes in
free_pgd_slow() would make it negative ?  Am I missing something
obvious?

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-rc1][ACPI][suspend] /proc/acpi/sleep vs /sys/power/state issue - 'standby' on a laptop

[Shawn Starr]

Hello, 

I've noticed something strange with issuing 'standby' to the system:

when echoing "standby" to /sys/power/state, nothing happens, not even a log or 
system activity to attempt standby mode.

However, trying echo "1" to /proc/acpi/sleep the system attempts to (standby) 
and aborts:

[4295945.236000] PM: Preparing system for suspend
[4295946.27] Stopping tasks: 
=|
[4295946.37] Restarting tasks... done

We get no reason as to why it quickly aborts. 

[4294672.065000] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
[4294676.827000] ACPI: (supports S0 S3 S4 S5)

What is '1' in /proc/acpi/sleep?  standby mode is not the same as suspend to 
ram? when I put a normal desktop in standby mode its still 'on' but the hard 
disk is put to sleep and the system runs in a lower power mode. 

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: 2.6.12-rc1-mm3: class_simple API

[Jim Crilly]

On 03/27/05 01:39:27PM -0500, Nick Orlov wrote:
> On Sun, Mar 27, 2005 at 10:17:17AM -0800, Greg KH wrote:
> > On Sun, Mar 27, 2005 at 01:04:31PM -0500, Nick Orlov wrote:
> > > 
> > >  - Whether the changes like the one above are "the right thing to do" ?
> > 
> > Yes.
> 
> Questionable.
> 
> > 
> > >  - What's the best way to deal with this particular issue ?
> > 
> > Change the code to not use these functions.
> 
> In other words "forget about nvidia <-> udev interaction" ?
> I do not think it is acceptable.
> 
> > Look at the vmware code for examples of how to do this.
> 
> Is there a place where I can download the code example without
> registering / paying license fee ?

http://ftp.cvut.cz/vmware/

The file vmware-any-any-update*.tar.gz contains the source to all of the
VMWare kernel modules. IIRC I found the URL in the VMWare newsgroups and
they're maintained unofficially by a VMWare employee.

> 
> P.S. Please CC me, I'm not subscribed to the list.
> 
> -- 
> With best wishes,
>   Nick Orlov.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message 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/

[PATCH] nommu.c build error fix

[Yoshinori Sato]

- Argument addition of security_file_mmap.
- Because in_gate_area_no_task undefined with CONFIG_KALLSYM=y, add it.

Signed-off-by: Yoshinori Sato <[EMAIL PROTECTED]>

= mm/nommu.c 1.32 vs edited =
--- 1.32/mm/nommu.c 2005-03-10 00:12:40 +09:00
+++ edited/mm/nommu.c   2005-03-28 16:21:12 +09:00
@@ -396,6 +396,7 @@
unsigned int vm_flags;
void *result;
int ret, membacked;
+   unsigned long reqprot = prot;
 
/* do the simple checks first */
if (flags & MAP_FIXED || addr) {
@@ -506,7 +507,7 @@
}
 
/* allow the security API to have its say */
-   ret = security_file_mmap(file, prot, flags);
+   ret = security_file_mmap(file, reqprot, prot, flags);
if (ret)
return ret;
 
@@ -1061,3 +1062,7 @@
return -ENOMEM;
 }
 
+int in_gate_area_no_task(unsigned long addr)
+{
+   return 0;
+}

-- 
Yoshinori Sato
<[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: Linux 2.4.30-rc3

[Ville Herva]

On Sat, Mar 26, 2005 at 01:28:01PM -0300, you [Marcelo Tosatti] wrote:
> 
> Hi, 
> 
> Here goes -rc3.
> 
> A nasty typo happened while merging v2.6 load_elf_library() DoS fix,
> which could leap to oopses.
> 
> Summary of changes from v2.4.30-rc2 to v2.4.30-rc3
> 
> 
> Marcelo Tosatti:
>   o Andreas Arens: Fix deadly mismerge of binfmt_elf DoS fix
>   o Change VERSION to 2.4.30-rc3

I just upgraded from linux-2.4.21 + vserser 0.17 to 2.4.30rc3 + vserver
1.2.10. The box has been running stable with 2.4.21 + vserver 0.17/0.16 for
a few years (uptime before reboot was nearly 400 days.)

The boot went fine, but after few hours I got 
Message from [EMAIL PROTECTED] at Sun Mar 27 22:07:00 2005 ...
turing kernel: journal commit I/O error

and dmesg is filled with 
--8<---
EXT3-fs error (device md(9,3)) in start_transaction: Journal has aborted
EXT3-fs error (device md(9,3)) in start_transaction: Journal has aborted
EXT3-fs error (device md(9,3)) in start_transaction: Journal has aborted
EXT3-fs error (device md(9,3)) in start_transaction: Journal has aborted
--8<---

This is roofs, on top software raid1 and two ide disks. mdstat claims it's
healthy:

--8<---
md3 : active raid1 hdc3[1] hda3[0]
  37955648 blocks [2/2] [UU]
--8<---

While dmesg has filled up and /var/log/messages is read-only - I can't see
all the kernel messages - there appears to be no IO errors from the
underlying devices (md, ide). smartctl -a does not report errors for hda nor
hdc.

During reboot, fsck was run for md3, and it was clean. Now I get

--8<---
Block bitmap differences:  -(7800660--7801060) -(7801934--7802030) 
-(7802370--7802602) -(7802604--7802613) -(7802681--7802700) -(7802715--7802716) 
-(7802726--7802732) -(7802744--7802750)-(7802914--7802927) -(7802934--7802937) 
-(7802946--7802964)  -(7803392--7803417) -(7805060--7808825) 
-(7808976--7809608) 
Fix? no

Inode bitmap differences:  -3899400
Fix? no
--8<---

No errors from the badblocks part of the fsck, though.

Running fsck triggers the "journal commit I/O error" messages again, and
still no IO errors from either md or ide.

This _could_ have something to do with the vserver patch but it doesn't
appear so. Also, it doesn't immediately look like hardware problem. 

Any ideas?


-- v -- 

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

$BBp5^JX!JBh0l9f!K(B

[info]

$BEv%5%$%H$N$4MxMQ$OA4$FL5NA!JCK=w6&!o(B0$B1_!K(B
$B$d$C$Q$j=P0)$&$J$i$46a=j$G5$7Z$KOC$79g$($k%a!<%k!&%(!{%A%U%l%s%I$,$G$9$h(B
$B$M!#Ev%5%$%H$OA49qCO0hJL$N;TD.Bhttp://loves.qsv20.com/
[EMAIL PROTECTED]"[EMAIL 
PROTECTED]&$K%W%i%$%P%7!pJs$rBgNL8x3+$7$F$*$j$^$9!#(B

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

[PATCH 2.6.12-rc1] cpusets GFP_ATOMIC fix: tonedown panic comment

[Paul Jackson]

This patch applies on top of my patch of March 26, entitled "cpusets
special case GFP_ATOMIC allocs".  It tones down my panic'y commentary.

My commentary shouldn't imply that failed GFP_ATOMICs should lead to,
or normally lead to, panics.  Even though there are a few panic()
calls following failed GFP_ATOMIC allocs, this is not the usual or
desired result of a failed GFP_ATOMIC.  The kernel will probably
drop some detail on the floor and keep on working.

Thanks to Nick Piggin for noticing (I hope this answers his point.)

Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>

Index: 2.6.12-pj/Documentation/cpusets.txt
===
--- 2.6.12-pj.orig/Documentation/cpusets.txt2005-03-27 22:48:14.0 
-0800
+++ 2.6.12-pj/Documentation/cpusets.txt 2005-03-27 22:48:22.0 -0800
@@ -264,11 +264,11 @@ Nodes when using hotplug to add or remov
 
 There is a second exception to the above.  GFP_ATOMIC requests are
 kernel internal allocations that must be satisfied, immediately.
-The kernel may panic if such a requested page is not allocated.
-If such a request cannot be satisfied within the cpusets allowed
-memory, then we relax the cpuset boundaries and allow any page in
-the system to satisfy a GFP_ATOMIC request.  It is better to violate
-the cpuset constraints than it is to panic the kernel.
+The kernel may drop some request, in rare cases even panic, if a
+GFP_ATOMIC alloc fails.  If the request cannot be satisfied within
+the current tasks cpuset, then we relax the cpuset, and look for
+memory anywhere we can find it.  It's better to violate the cpuset
+than stress the kernel.
 
 To start a new job that is to be contained within a cpuset, the steps are:
 
Index: 2.6.12-pj/mm/page_alloc.c
===
--- 2.6.12-pj.orig/mm/page_alloc.c  2005-03-27 22:48:14.0 -0800
+++ 2.6.12-pj/mm/page_alloc.c   2005-03-27 22:48:42.0 -0800
@@ -782,7 +782,7 @@ __alloc_pages(unsigned int gfp_mask, uns
 * coming from realtime tasks to go deeper into reserves
 *
 * This is the last chance, in general, before the goto nopage.
-* Ignore cpuset if GFP_ATOMIC (!wait) - better that than panic.
+* Ignore cpuset if GFP_ATOMIC (!wait) rather than fail alloc.
 */
for (i = 0; (z = zones[i]) != NULL; i++) {
if (!zone_watermark_ok(z, order, z->pages_min,


-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Can't use SYSFS for "Proprietry" driver modules !!!.

[Horst von Brand]

Kyle Moffett <[EMAIL PROTECTED]> said:
> On Mar 27, 2005, at 14:16, Aaron Gyes wrote:
> > So what? Sure, GPL'd drivers are easier for an end-user in that case.
> > What does that have to do with law?

> Well, under most interpretations of the GPL, you are *NOT* allowed to
> even _link_ non-GPL code with GPL code. (Basically, by distributing such
> a linked binary, you are certifying that you have permission to GPL the
> entire source-code and are doing so.

Wrong. You are free to do whatever you like in the privacy of your home,
but not distribute the result. So you could very well distribute both
pieces, one under GPL, the other not, and leave the linking to the end
user.

Sure, /creating/ the piece to be linked with the GPLed code might make it
GPL also, but that is another story.

> > What about what's better for the company that made the device?

> Who says that free maintenance and bugfixes *isn't* better for said
> company?

Not me. But it is not the only consideration involved.

> > Should NVIDIA be forced to give up their secrets to all their
> > competitors because some over zealous developers say so?

nVidia doesn't want to tell, that is their decision to make. If they don't
tell, Linux users don't get to use nVidia cards with OSS drivers. Both
sides loose something, nVidia thinks (right or wrong) that what they loose
this way is less than what they'd loose by opening up.

> We don't care about their secrets, we just want to be able to interface
> with their hardware.  Really, we don't care how the hardware does what
> it does internally, we just care how to tell it to do that.  It's the
> difference between telling an artist to paint a big picture and
> watching every thought he makes while he does the painting with a brain
> scanner.

That the "Linux kernel community" (whoever that might be) doesn't care
doesn't mean others wouldn't consider mining the Linux drivers for any data
on their competition.

> > Should the end-users of the current drivers be forced to lose out
> > on features such as sysfs and udev compatability?

> Should the end-users even *have* features such as sysfs and udev?  If
> the *open-source* developers hadn't *opened* their *source*, then that
> code wouldn't exist.  One condition they made when they gave that code
> for free was that *only* people who also gave their code for free
> could use it.

Grey area... it could be argued that this is /public/ interfase to the
kernel, and as such shouldn't be closed off.

> > I love Linux, and a I love that free software has become mildly
> > successful, but the zealots are hurting both.

> On the contrary, the zealots are what protect us from the even worse
> proprietary software zealots.  You may not agree with them, but if
> there were only one kind of zealot then the world would be much
> worse off.

As long as the opposing zealots keep each other in check... ;-)
-- 
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: [PATCH] no need to check for NULL before calling kfree() -fs/ext2/

[Horst von Brand]

Dave Jones <[EMAIL PROTECTED]> said:
> On Sun, Mar 27, 2005 at 05:12:58PM +0200, Jan Engelhardt wrote:
> 
>  > Well, kfree inlined was already mentioned but forgotten again.
>  > What if this was used:
>  > 
>  > inline static void kfree_WRAP(void *addr) {
>  > if(likely(addr != NULL)) {
>  > kfree_real(addr);
>  > }
>  > return;
>  > }
>  > 
>  > And remove the NULL-test in kfree_real()? Then we would have:

> Am I the only person who is completely fascinated by the
> effort being spent here micro-optimising something thats
> almost never in a path that needs optimising ?
> I'd be amazed if any of this masturbation showed the tiniest
> blip on a real workload, or even on a benchmark other than
> one crafted specifically to test kfree in a loop.

Right.

> That each occurance of this 'optimisation' also saves a handful
> of bytes in generated code is it's only real benefit afaics.

No. It clears up the calls to kfree() a bit too in the source. Not really
important, sure.
.
> Even then, if a functions cache performance is better off because
> we trimmed a few bytes from the tail of a function, I'd be
> completely amazed.
> 
> I guess April 1st came early this year.

Got (at) you! ;-)
-- 
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: ]PATCH] cpuset: make function decl. ANSI

[Paul Jackson]

Randy wrote:
> kernel/cpuset.c:1428:41: warning: non-ANSI function declaration

Acked-by: Paul Jackson <[EMAIL PROTECTED]>

Thanks, Randy.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] isdn: hfc4s8s_ll sparse cleanups

[Randy.Dunlap]

drivers/isdn/hisax/hfc4s8s_l1.c:1661:7: warning: obsolete struct initializer, us
e C99 syntax
drivers/isdn/hisax/hfc4s8s_l1.c:1662:7: warning: obsolete struct initializer, us
e C99 syntax
drivers/isdn/hisax/hfc4s8s_l1.c:1663:7: warning: obsolete struct initializer, us
e C99 syntax
drivers/isdn/hisax/hfc4s8s_l1.c:1664:7: warning: obsolete struct initializer, us
e C99 syntax
drivers/isdn/hisax/hfc4s8s_l1.c:1065:18: warning: Using plain integer as NULL po
inter

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>

diffstat:=
 drivers/isdn/hisax/hfc4s8s_l1.c |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff -Naurp ./drivers/isdn/hisax/hfc4s8s_l1.c~isdn_hfcssll_clean 
./drivers/isdn/hisax/hfc4s8s_l1.c
--- ./drivers/isdn/hisax/hfc4s8s_l1.c~isdn_hfcssll_clean2005-03-26 
21:48:11.0 -0800
+++ ./drivers/isdn/hisax/hfc4s8s_l1.c   2005-03-27 21:17:01.0 -0800
@@ -1062,7 +1062,7 @@ tx_b_frame(struct hfc4s8s_btype *bch)
Write_hfc8(l1->hw, A_INC_RES_FIFO, 1);
}
ack_len += skb->truesize;
-   bch->tx_skb = 0;
+   bch->tx_skb = NULL;
bch->tx_cnt = 0;
dev_kfree_skb(skb);
} else
@@ -1658,10 +1658,10 @@ hfc4s8s_remove(struct pci_dev *pdev)
 }
 
 static struct pci_driver hfc4s8s_driver = {
-  name:"hfc4s8s_l1",
-  probe:hfc4s8s_probe,
-  remove:__devexit_p(hfc4s8s_remove),
-  id_table:hfc4s8s_ids,
+  .name= "hfc4s8s_l1",
+  .probe   = hfc4s8s_probe,
+  .remove  = __devexit_p(hfc4s8s_remove),
+  .id_table= hfc4s8s_ids,
 };
 
 /**/


---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] isdn: hfc_usb: use NULL instead of 0

[Randy.Dunlap]

17 of these (all different line numbers):
drivers/isdn/hisax/hfc_usb.c:139:9: warning: Using plain integer as NULL pointer


Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>

diffstat:=
 drivers/isdn/hisax/hfc_usb.c |2 +-
 drivers/isdn/hisax/hfc_usb.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff -Naurp ./drivers/isdn/hisax/hfc_usb.c~isdn_hfcusb_null 
./drivers/isdn/hisax/hfc_usb.c
--- ./drivers/isdn/hisax/hfc_usb.c~isdn_hfcusb_null 2005-03-26 
21:48:11.0 -0800
+++ ./drivers/isdn/hisax/hfc_usb.c  2005-03-27 21:10:19.0 -0800
@@ -136,7 +136,7 @@ vendor_data vdata[] = {
 LED_SCHEME1, {0x80, -64, -32, -16}
 }
,
-   {0, 0, 0}   /* EOL element */
+   {0, 0, NULL}/* EOL element */
 };
 
 /***/
diff -Naurp ./drivers/isdn/hisax/hfc_usb.h~isdn_hfcusb_null 
./drivers/isdn/hisax/hfc_usb.h
--- ./drivers/isdn/hisax/hfc_usb.h~isdn_hfcusb_null 2005-03-27 
21:13:10.0 -0800
+++ ./drivers/isdn/hisax/hfc_usb.h  2005-03-27 21:13:27.0 -0800
@@ -91,7 +91,7 @@
 /**/
 /* macros */
 /**/
-#define 
write_usb(a,b,c)usb_control_msg((a)->dev,(a)->ctrl_out_pipe,0,0x40,(c),(b),0,0,HFC_CTRL_TIMEOUT)
+#define 
write_usb(a,b,c)usb_control_msg((a)->dev,(a)->ctrl_out_pipe,0,0x40,(c),(b),NULL,0,HFC_CTRL_TIMEOUT)
 #define read_usb(a,b,c) 
usb_control_msg((a)->dev,(a)->ctrl_in_pipe,1,0xC0,0,(b),(c),1,HFC_CTRL_TIMEOUT)
 
 


---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] x86_64/lib: find_first_zero_bit not extern

[Randy.Dunlap]

Exported function was marked inline:
arch/x86_64/lib/bitops.c:18: warning: `find_first_zero_bit' declared inline afte
r being called

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>

diffstat:=
 arch/x86_64/lib/bitops.c |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -Naurp ./arch/x86_64/lib/bitops.c~x8664_lib_bitops 
./arch/x86_64/lib/bitops.c
--- ./arch/x86_64/lib/bitops.c~x8664_lib_bitops 2005-03-01 23:37:49.0 
-0800
+++ ./arch/x86_64/lib/bitops.c  2005-03-27 20:42:59.0 -0800
@@ -14,7 +14,7 @@
  * Returns the bit-number of the first zero bit, not the number of the byte
  * containing a bit.
  */
-inline long find_first_zero_bit(const unsigned long * addr, unsigned long size)
+long find_first_zero_bit(const unsigned long * addr, unsigned long size)
 {
long d0, d1, d2;
long res;


---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] cpuset: make function decl. ANSI

[Randy.Dunlap]

kernel/cpuset.c:1428:41: warning: non-ANSI function declaration

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>

diffstat:=
 kernel/cpuset.c |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -Naurp ./kernel/cpuset.c~cpuset_void ./kernel/cpuset.c
--- ./kernel/cpuset.c~cpuset_void   2005-03-26 21:48:12.0 -0800
+++ ./kernel/cpuset.c   2005-03-27 20:59:21.0 -0800
@@ -1425,7 +1425,7 @@ void cpuset_init_current_mems_allowed(vo
  * Do not call this routine if in_interrupt().
  */
 
-void cpuset_update_current_mems_allowed()
+void cpuset_update_current_mems_allowed(void)
 {
struct cpuset *cs = current->cpuset;
 


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

source file unable to export function to kernel

[linux lover]

Hi,
I have included this as myfile.c in
/usr/src/linux-2.4.24/kernel. I included its entry in
Makefile in export-objs.

//sourcefile
#define EXPORT_SYMTAB
#include 
#include 
#include  //contains prototypes for
fun1 and fun2
#include 


char* fun1(char* str1)
{


}

void fun2(char *str1,char *str2)
{

}

EXPORT_SYMBOL(fun1);
EXPORT_SYMBOL(fun2);

But after recompiling kernel when i boot i am unable
to see its entry in /proc/ksyms. Why??
my myhf1.h file is
extern char* fun1(char *);
extern void fun2(char*,char*); 
regards,
linux_lover.



__ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] no need to check for NULL before calling kfree() -fs/ext2/

[Paul Jackson]

Jesper wrote:
> What I'm trying to find out now is if there's a general consensus that 
> these patches are worthwile and wanted or if they are unwanted and I'm 
> wasting my time. 

Thanks for your good work so far, and your good natured tolerance of
the excessively detailed discussions resulting.

I don't have a big preference either way - but a couple of questions:

 1) Do you have any wild guess of how many of these you've done so far,
and how many potentially remain that could be done?  Tens, hundreds,
thousands?

 2) Any idea what was going on with the numbers you posted yesterday,
which, at least from what I saw at first glance, seemed to show
"if (likely(p)) kfree(p);" to be a good or best choice, for all
cases, including (p != NULL) being very unlikely?  That seemed
like a weird result.

If the use of "likely(p)" is almost always a winner, then the changes
you've been doing, followed by a header file change:

static inline void kfree(const void *p)
{
if (likely(p))
__kfree(p); /* __kfree(p) doesn't check for NULL p 
*/
}

along the lines that Jan considered a few posts ago, might be a winner.

But since this "likely(p)" result seems so bizarre, it seems unlikely that
the above kfree wrapper would be a winner.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] oom lca -- fork bombing killer

[Coywolf Qi Hunt]

   March 28, 2005
  Coywolf Qi Hunt
[EMAIL PROTECTED]


Linux OOM LCA (Least Common Ancestor) Patch

An anti Fork Bombing Solution


Introduction

   People complain that linux is still vulnerable to the ancient fork bombing.
   A quick scratch  simply running
   as normal user could make a linux box totally unusable.

   Another example is in the recent thread: oom with 2.6.11
   

   The only way currently to deal with fork bombing is to limit the number of
   running processes or the forking rate. This patch brings a new way to find
   out and kill the possible fork bombing processes or any misbehaving processes
   taking up too much memory.

   The patch applies to 2.6.12-rc1-mm3 and seems able to kill various fork 
   bombings. 
   

Simple Experiment Result

   It is tested on an 256M desktop box. With swapoff and in console, it works
   pretty well.  After the fork bomber has forked into about 1500 instances,

RES = 1036k
SHR = 876k
1500*(1036k-876k)=234M

   it got killed completely.

   When the fork bomber is running as root, kernel first kills the X server and 
   XFce4 el al, immediately kernel kills the bomb totally too.

   I haven't tested with swapon yet. The hard disk would keep swapping badly 
   then.  
   
   When in X, the screen got corrupted, but the box can still reboot through
   ctrl+alt+del. 


The oom LCA algorithm details

   1. New elements add to struct task_struct :
  struct task_struct *bio_parent
  struct list_head bio_children;
  struct list_head bio_sibling;

  Adds struct task_struct *bio_parent to struct task_struct.
  Unlike struct task_struct *parent, user programs can not change it
  by daemon(3).  It is describing the facts except when it is a kernel
  thread. We don't plan to oom kill any kernel threads.

   2. If a process is malicious, we'll consider its children malicious too. 
  So we kill the choose process and all its descendants. This way we'll be
  far faster than the tumor forking. LCA always grows upwards.

   3. LCA(Least Common Ancestor Algorithm, I choose the term LCA for it is more 
  widely used than NCA(Nearest Common Ancestor) according to google.)
  We remember the last killed process' parent, next time we'll kill
  the remembered last_chosen_parent and the new worst process(the highest
  badness)'s least common ancestor. NOTE if find_lca() fails, we just kill 
  the worst process and we must _update_ the last_kill_process to a new 
  value.

   4. Calculates oom badness
  bio_children is considered instead of children.


Not quite related changes

   I also include some other obvious cleanups. They are:

  1. hides reparent_to_init(), reparent_to_init() should be called only by
 daemonize()
  2. removes obsolete code comments in task_struct
  3. removes an obsolete parameter from choose_new_parent() and cleanups
  4. in reparent_thread(), ptrace should be type long, not int.
  5. cleanups in mm/oom_kill.c


Signed-off-by: Coywolf Qi Hunt <[EMAIL PROTECTED]>
---

 arch/i386/mach-voyager/voyager_thread.c |1 
 include/linux/init_task.h   |3 
 include/linux/sched.h   |   10 --
 kernel/exit.c   |   34 ++-
 kernel/fork.c   |4 
 mm/oom_kill.c   |  141 
 6 files changed, 129 insertions(+), 64 deletions(-)

diff -pruN 2.6.12-rc1-mm3/arch/i386/mach-voyager/voyager_thread.c 
2.6.12-rc1-mm3-cy/arch/i386/mach-voyager/voyager_thread.c
--- 2.6.12-rc1-mm3/arch/i386/mach-voyager/voyager_thread.c  2004-08-20 
14:39:58.0 +0800
+++ 2.6.12-rc1-mm3-cy/arch/i386/mach-voyager/voyager_thread.c   2005-03-28 
10:18:24.0 +0800
@@ -126,7 +126,6 @@ thread(void *unused)
 
kvoyagerd_running = 1;
 
-   reparent_to_init();
daemonize(THREAD_NAME);
 
set_timeout = 0;
diff -pruN 2.6.12-rc1-mm3/include/linux/init_task.h 
2.6.12-rc1-mm3-cy/include/linux/init_task.h
--- 2.6.12-rc1-mm3/include/linux/init_task.h2005-03-26 13:21:10.0 
+0800
+++ 2.6.12-rc1-mm3-cy/include/linux/init_task.h 2005-03-28 10:18:24.0 
+0800
@@ -90,6 +90,9 @@ extern struct group_info init_groups;
.parent = , \
.children   = LIST_HEAD_INIT(tsk.children), \
.sibling= LIST_HEAD_INIT(tsk.sibling),  \
+   .bio_parent = , \
+   .bio_children   = LIST_HEAD_INIT(tsk.bio_children), \
+   .bio_sibling= 

Re: upgrading modutils may have fixed: unresolved symbols still in 2.4.30-rc2 (usbserial needs symbol tty_ldisc_ref and tty_ldisc_deref which are EXPORT_SYMBOL_GPL)

[Willy Tarreau]

On Sat, Mar 26, 2005 at 04:31:59PM -0800, David Dyck wrote:
> >dd:linux# insmod usbserial
> >Using /lib/modules/2.4.30-rc2/kernel/drivers/usb/serial/usbserial.o
> >...: unresolved symbol tty_ldisc_ref
> >...: unresolved symbol tty_ldisc_deref
> 
> I tried again with 2.4.30-rc3, but this time I changed my .config
> file to disable 2 other modules that I didn't need, and wasn't loading.
> 
> < CONFIG_USB_UHCI_ALT=m
> < CONFIG_USB_STV680=m
> 
> and build rc3.  It seems to work, so either my earlier
> rc2 test with make clean wasn't clean-enough, or CONFIG_USB_UHCI_ALT
> interferes - testing with CONFIG_USB_UHCI_ALT as a module (not loaded)
> also works, so since interdiff didn't seem to highlite any difference 
> between rc2 and rc3, I'll suspect that my test make clean didn't
> clean things up good enough, and the entire problem was as
> Adrian Bunk suggest (upgrade modutils, thanks Adrian)

I believe it's because of genksyms during the build process, I had the
exact same problem a few weeks ago on a machine with old modutils. So
you should have cleaned everything and rebuilt from scratch after
installing your new modutils. BTW, the required modutils in
Documentation/Changes is still marked as 2.4.10, I hope it is still
enough.

Regards,
Willy

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

Re: imps2 mouse driver and bug 2082

[Dmitry Torokhov]

Hi,

On Sunday 27 March 2005 18:37, Mauro Mozzarelli wrote:
> The mouse driver, re-developed for kernel 2.6, ever since the earliest
> 2.6 release lost the ability to reset a broken link with an IMPS2 mouse
> (this happens when disconnecting the mouse plug either physically or
> through a "non imps2" KVM switch). The result is that the mouse can no
> longer be controlled, with the only solution being a RE-BOOT!
>

You can re-initialize mouse with the following command (while mouse is
connected):

echo -n "reconnect" > /sys/bus/serio/devices/serioX/drvctl

where serioX is serio port your mouse is connected to. You can find out
which one by examining the driver link:

for i in /sys/bus/serio/devices/*; do echo $i: `cat $i/driver/description`; done

You could map this command to a key - given the fact that in pre-2.6 era
one had to switch from X to text console and back to restore the mouse
having a command mapped to a hot-key should be an acceptable workaround
while we searching for a better solution. 

> This issue has been filed as bug 2082
> (http://bugme.osdl.org/show_bug.cgi?id=2082) . A fix was posted for
> 2.6.8, but this patch never made its way into the kernel main stream.
> "Vojtech", author of the 2.6 mouse driver, keeps modifying his code
> version after version, therefore breaking compatibility with the posted
> patch. I adapted the patch for 2.6.9 and 2.6.10 (there are now three
> versions for 2.6.8, 2.6.9 and 2.6.10). Kernel 2.6.11(.6) was released
> recently, still with the same bug, and would require further adaptation
> of the posted patch.
>

When I wrote the patch I thought it would be ok but now I do not think
that the patch is acceptable - it still allows "junk" data into the
kernel and we should find a way to avoid it.
 
-- 
Dmitry 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] no need to check for NULL before calling kfree() -fs/ext2/

[Paul Jackson]

Dave writes:
> Am I the only person who is completely fascinated by the
> effort being spent here micro-optimising something thats

Eh .. it's well known behaviour.  Bring two questions before a
committee, one for millions of dollars and the other for pocket change,
and watch the committee spend more time discussing the second question.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] no need to check for NULL before calling kfree() -fs/ext2/

[Paul Jackson]

Jan - please don't trim the CC lists when responding on lkml.
Thanks.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Can't use SYSFS for "Proprietry" driver modules !!!.

[Clemens Schwaighofer]

The fact that Nvidia and ATI get away with it?
The choose to take a risk based upon a specific interpretation of the
boundary of a derivative work. Since the boundary is untested in law its
not certain who is right.
Plus the fact, that if somebody sues them, they just remove the drivers 
from their list. Linux is so small for them, that probably don't care (plus 
there is an open source nv & ati driver).

[ Clemens Schwaighofer  -=:~ ]
[ TBWA\ && TEQUILA\ Japan IT Group   ]
[6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ]
[ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ]
[ http://www.tequila.co.jphttp://www.tbwajapan.co.jp ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

How to measure time accurately.

[krishna]

Hi All,
Can any one tell me how to measure time accurately for a block of C code 
in device drivers.
For example, If I want to measure the time duration of firmware download.

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

Re: Mac mini sound woes

[Benjamin Herrenschmidt]

On Mon, 2005-03-28 at 03:42 +0200, Andrea Arcangeli wrote:
> On Mon, Mar 28, 2005 at 09:42:00AM +1000, Benjamin Herrenschmidt wrote:
> > suggest I just don't do any control ? Or should I implement a double
> > buffer scheme with software gain as well in the kernel driver ?
> 
> I recall to have sometime clicked on volume controls that weren't
> hardware related, I don't pay much attention when stuff works, perhaps
> it was the kde sound system doing it or something like that.
> 
> I would suggest doing the D->A only, then adding a basic hack to
> g5 too ;), and then go back to the mini to do the gain emulation in
> kernel space if somebody complains ;). Doing the software emulation
> sounds quite orthogonal to the rest so it can be done later if needed.
> 
> Too loud sound is better than no sound.

Will do, of course. As for the G5, yes, I need to work on that too.

Ben.


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

Re: Can't use SYSFS for "Proprietry" driver modules !!!

[Aaron Gyes]

On Sun, 2005-03-27 at 14:30 -0500, Kyle Moffett wrote:
> Well, under most interpretations of the GPL, you are *NOT* allowed to
> even _link_ non-GPL code with GPL code. (Basically, by distributing
> such a linked binary, you are certifying that you have permission to
> GPL the entire source-code and are doing so.

The code that is linked in the nvidia driver is open source. People can
and have easily adapted the free part of the driver to work on new
kernels. The 2.4 driver was ported to 2.6 with little trouble. The only
part that isn't open source is the binary that is wrapped.


> It's the difference between telling an artist to paint a big picture
> and watching every thought he makes while he does the painting with a
> brain scanner.

More crazy metaphores.. Obviously very complex things are being done, or
someone would have figured it out already.

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

Re: Can't use SYSFS for "Proprietry" driver modules !!!.

[Steven Rostedt]

On Mon, 2005-03-28 at 03:39 +0200, Adrian Bunk wrote:

> > Your talking about something completely different.  Yes, it is quite
> > explicit if you modify the source, and distribute it in binary only
> > form.  I'm talking about writing a separate module that links with the
> > GPL code dynamically.  So that the code is compiled different from the
> > GPL code. So the only common part is the API. Now is this a derived
> > work? 
> >...
> 
> My point was a bit different:
> 
> Harald's action was meant as an example, that such things can be brought 
> to court in virtually every country in the world.
> 
> And a court decision in e.g. the USA might not have any influence on a 
> court decision in e.g. Germany.
> 
> Some people seem to think that it was enough if something was OK 
> according to US law - but that's simply wrong.
> 

I understand this quite well since I do business in both the US and
Germany. But I do find the courts quite similar too, from reading the
newspapers in both countries.  But even in the US, things differ from
one court to the next.  Anyway, the problem the GPL may have with
dynamic loading is that the loading is done by the user and not the
distributer, which is who the GPL states is under the obligation of the
license. 

Tschüss,

-- Steve


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

Kernel bug when using quagga/zebra

[Iulian Surugiu]

Hi I`m using fedora core 3 kernel (2.6.9-1.667). I
would like to mention first that this is not only the
first time i am encountering this error, however , for
the last 3 days i had had setup routers on different
distributions/kernels and quagga/zebra different
packages (source/binaries) and versions but i still
get the same behaviour.

Now by following the documentation you supplied in the
REPORTING-BUGS file here are your details:

1. Kernel panic (Oops) using zebra/quagga
2. This problem i encounter when I`m stopping the
zebra daemon.
3. Networking, zebra, quagga, bgpd, kernel, kernel
panic
4. Linux version 2.6.9-1.667
([EMAIL PROTECTED]) (gcc version 3.4.2
20041017 (Red Hat 3.4.2-6.fc3)) #1 Tue Nov 2 14:41:25
EST 2004, Also encountered on debian too, and all
majority of 2.6.x kernels
5. Ooops message (ripped from syslog) 

Jul 25 05:05:02 localhost kernel: Unable to handle
kernel NULL pointer dereference at virtual address

Jul 25 05:05:02 localhost kernel:  printing eip:
Jul 25 05:05:02 localhost kernel: 022ec14e
Jul 25 05:05:02 localhost kernel: *pde = 
Jul 25 05:05:02 localhost kernel: Oops: 0002 [#1]
Jul 25 05:05:02 localhost kernel: Modules linked in:
autofs4 i2c_dev i2c_core sunrpc md5 ipv6 dm_mod
8139too mii 3c59x ext3 jbd
Jul 25 05:05:02 localhost kernel: CPU:0
Jul 25 05:05:02 localhost kernel: EIP:   
0060:[<022ec14e>]Not tainted VLI
Jul 25 05:05:02 localhost kernel: EFLAGS: 00010246  
(2.6.9-1.667)
Jul 25 05:05:02 localhost kernel: EIP is at
fib_release_info+0x72/0xac
Jul 25 05:05:02 localhost kernel: eax:    ebx:
   ecx: 11f884e4   edx: 11f88480
Jul 25 05:05:02 localhost kernel: esi: 11f884e8   edi:
   ebp: 0e444340   esp: 10dfbc90
Jul 25 05:05:02 localhost kernel: ds: 007b   es: 007b 
 ss: 0068
Jul 25 05:05:02 localhost kernel: Process zebra (pid:
3315, threadinfo=10dfb000 task=11a9a6f0)
Jul 25 05:05:02 localhost kernel: Stack: 10cba1f0
117024c0 0001 022ee86b 0024 0017 11ff4280
11f00580
Jul 25 05:05:02 localhost kernel:008c74c2
11f00580 11e18810 11e18800 11ff4280 022ebb7c 11e18800
10970db8
Jul 25 05:05:02 localhost kernel:10970d80
10970d80 02374788 022ebb2c 0009 022b1f79 003c
0002
Jul 25 05:05:02 localhost kernel: Call Trace:
Jul 25 05:05:02 localhost kernel:  [<022ee86b>]
fn_hash_delete+0x196/0x1c8
Jul 25 05:05:02 localhost kernel:  [<022ebb7c>]
inet_rtm_delroute+0x50/0x5c
Jul 25 05:05:02 localhost kernel:  [<022ebb2c>]
inet_rtm_delroute+0x0/0x5c
Jul 25 05:05:02 localhost kernel:  [<022b1f79>]
rtnetlink_rcv+0x225/0x313
Jul 25 05:05:02 localhost kernel:  [<022bce02>]
netlink_data_ready+0x14/0x43
Jul 25 05:05:02 localhost kernel:  [<022bc607>]
netlink_sendskb+0x52/0x6b
Jul 25 05:05:02 localhost kernel:  [<022bcc1e>]
netlink_sendmsg+0x252/0x261
Jul 25 05:05:02 localhost kernel:  [<022a1959>]
sock_sendmsg+0xdb/0xf7
Jul 25 05:05:02 localhost kernel:  [<022a1a90>]
sock_recvmsg+0xef/0x10c
Jul 25 05:05:02 localhost kernel:  [<0211cf5b>]
autoremove_wake_function+0x0/0x2d
Jul 25 05:05:02 localhost kernel:  [<0215e9d0>]
get_user_size+0x30/0x57
Jul 25 05:05:02 localhost kernel:  [<022a7176>]
verify_iovec+0x3e/0x71
Jul 25 05:05:02 localhost kernel:  [<022a300b>]
sys_sendmsg+0x143/0x191
Jul 25 05:05:02 localhost kernel:  [<0215e45f>]
rw_vm+0x3f7/0x482
Jul 25 05:05:02 localhost kernel:  [<0215ea20>]
put_user_size+0x29/0x2d
Jul 25 05:05:02 localhost kernel:  [<02170bc9>]
cp_new_stat64+0xf5/0x107
Jul 25 05:05:02 localhost kernel:  [<02151de2>]
follow_page_pfn+0xec/0xfd
Jul 25 05:05:02 localhost kernel:  [<0215e45f>]
rw_vm+0x3f7/0x482
Jul 25 05:05:02 localhost kernel:  [<022a3398>]
sys_socketcall+0x160/0x179
Jul 25 05:05:02 localhost kernel: Code: <3>Debug:
sleeping function called from invalid context at
include/linux/rwsem.h:43
Jul 25 05:05:02 localhost kernel:
in_atomic():0[expected: 0], irqs_disabled():1
Jul 25 05:05:02 localhost kernel:  [<0211c8b9>]
__might_sleep+0x7d/0x88
Jul 25 05:05:02 localhost kernel:  [<0215e27e>]
rw_vm+0x216/0x482
Jul 25 05:05:02 localhost kernel:  [<022ec123>]
fib_release_info+0x47/0xac
Jul 25 05:05:02 localhost kernel:  [<022ec123>]
fib_release_info+0x47/0xac
Jul 25 05:05:02 localhost kernel:  [<0215e9d0>]
get_user_size+0x30/0x57
Jul 25 05:05:02 localhost kernel:  [<022ec123>]
fib_release_info+0x47/0xac
Jul 25 05:05:02 localhost kernel:  [<0210682b>]
show_registers+0x109/0x15e
Jul 25 05:05:02 localhost kernel:  [<02106a2f>]
die+0x14a/0x241
Jul 25 05:05:02 localhost kernel:  [<0211937e>]
do_page_fault+0x0/0x511
Jul 25 05:05:02 localhost kernel:  [<0211937e>]
do_page_fault+0x0/0x511
Jul 25 05:05:02 localhost kernel:  [<02119733>]
do_page_fault+0x3b5/0x511
Jul 25 05:05:02 localhost kernel:  [<022ec14e>]
fib_release_info+0x72/0xac
Jul 25 05:05:02 localhost kernel:  [<0224fd89>]
cfq_set_request+0x33/0x6b
Jul 25 05:05:02 localhost kernel:  [<0211ba03>]
__wake_up+0x8d/0xf2
Jul 25 05:05:02 localhost kernel:  [<022bc91d>]
netlink_broadcast+0x1df/0x23b
Jul 25 05:05:02 localhost kernel:  

Re: Mac mini sound woes

[Andrea Arcangeli]

On Mon, Mar 28, 2005 at 09:42:00AM +1000, Benjamin Herrenschmidt wrote:
> suggest I just don't do any control ? Or should I implement a double
> buffer scheme with software gain as well in the kernel driver ?

I recall to have sometime clicked on volume controls that weren't
hardware related, I don't pay much attention when stuff works, perhaps
it was the kde sound system doing it or something like that.

I would suggest doing the D->A only, then adding a basic hack to
g5 too ;), and then go back to the mini to do the gain emulation in
kernel space if somebody complains ;). Doing the software emulation
sounds quite orthogonal to the rest so it can be done later if needed.

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

Re: Can't use SYSFS for "Proprietry" driver modules !!!.

[Adrian Bunk]

On Sun, Mar 27, 2005 at 06:54:52PM -0500, Steven Rostedt wrote:
> On Mon, 2005-03-28 at 00:01 +0200, Adrian Bunk wrote:
> > 
> > How do you define "proven in court"?
> > 
> > Decided by an US judge based on US laws?
> > Decided by a German judge based on German laws?
> > Decided by a Chinese judge based on Chinese laws?
> > ...
> > 
> 
> OK, I was talking about US courts since that case was done in the US.
> But this is all what I remember about reading some 10 years ago. So I
> could be all wrong about what happened. I don't have any references and
> I'm too busy now to look them up. So I may be just speaking out of my
> ass. :-)
> 
> > If you distribute software you can be sued in every country you 
> > distribute it.
> > 
> > E.g. Harald Welte is currently quite successful with legal actions in 
> > Germany against companies that distribute Linux-based routers in Germany 
> > without offering the source of the GPL'ed software they use.
> 
> Your talking about something completely different.  Yes, it is quite
> explicit if you modify the source, and distribute it in binary only
> form.  I'm talking about writing a separate module that links with the
> GPL code dynamically.  So that the code is compiled different from the
> GPL code. So the only common part is the API. Now is this a derived
> work? 
>...

My point was a bit different:

Harald's action was meant as an example, that such things can be brought 
to court in virtually every country in the world.

And a court decision in e.g. the USA might not have any influence on a 
court decision in e.g. Germany.

Some people seem to think that it was enough if something was OK 
according to US law - but that's simply wrong.

> -- Steve

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: 2.6.12-rc1-mm3: box hangs solid on resume from disk while resuming device drivers

[Li Shaohua]

On Sun, 2005-03-27 at 02:23, Rafael J. Wysocki wrote:
> Hi,
> 
> On Friday, 25 of March 2005 15:19, Rafael J. Wysocki wrote: 
> > On Friday, 25 of March 2005 13:54, you wrote:
> > ]--snip--[
> > > >My box is still hanged solid on resume (swsusp) by the drivers:
> > > >
> > > >ohci_hcd
> > > >ehci_hcd
> > > >yenta_socket
> > > >
> > > >possibly others, too.  To avoid this, I had to revert the following
> > > patch from the Len's tree:
> > > >
> > > >diff -Naru a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> > > >--- a/drivers/acpi/pci_link.c2005-03-24 04:57:27 -08:00
> > > >+++ b/drivers/acpi/pci_link.c2005-03-24 04:57:27 -08:00
> > > >@@ -72,10 +72,12 @@
> > > > u8  active; /* Current IRQ
> > > */
> > > > u8  edge_level; /* All IRQs */
> > > > u8  active_high_low;/* All IRQs */
> > > >-u8  initialized;
> > > > u8  resource_type;
> > > > u8  possible_count;
> > > > u8  possible[ACPI_PCI_LINK_MAX_POSSIBLE];
> > > >+u8  initialized:1;
> > > >+u8  suspend_resume:1;
> > > >+u8  reserved:6;
> > > > };
> > > >
> > > > struct acpi_pci_link {
> > > >@@ -530,6 +532,10 @@
> > > >
> > > > ACPI_FUNCTION_TRACE("acpi_pci_link_allocate");
> > > >
> > > >+if (link->irq.suspend_resume) {
> > > >+acpi_pci_link_set(link, link->irq.active);
> > > >+link->irq.suspend_resume = 0;
> > > >+}
> > > > if (link->irq.initialized)
> > > > return_VALUE(0);
> > > 
> > > How about just remove below line:
> > > >+acpi_pci_link_set(link, link->irq.active);
> > 
> > You mean apply the patch again and remove just the single
> > line?  No effect (ie hangs).
> 
> It looks like removing this line couldn't help.
> 
> Apparently, acpi_pci_link_set(link, link->irq.active) must be called
> _before_ the call to pci_write_config_word() in
> drivers/pci/pci.c:pci_set_power_state(), because the box hangs
> otherwise.  However, with the patch applied,
> acpi_pci_link_set(link, link->irq.active) is only called through
> pcibios_enable_irq() in pcibios_enable_device(), which is _after_
> the call to pci_set_power_state() in pci_enable_device_bars(),
> so it's too late.
> 
> Hence, it seems, if you really want to get rid of the
> irqrouter_resume(), whatever the reason, the simplest fix
> seems to be to change the order of calls to pci_set_power_state()
> and pcibios_enable_device() in pci_enable_device_bars():
> 
> --- old/drivers/pci/pci.c 2005-03-26 19:10:09.0 +0100
> +++ linux-2.6.12-rc1-mm2/drivers/pci/pci.c2005-03-26 19:10:54.0 
> +0100
> @@ -442,9 +442,9 @@ pci_enable_device_bars(struct pci_dev *d
>  {
>   int err;
>  
> - pci_set_power_state(dev, PCI_D0);
>   if ((err = pcibios_enable_device(dev, bars)) < 0)
>   return err;
> + pci_set_power_state(dev, PCI_D0);
>   return 0;
>  }
>  
> though I'm not sure if that's legal.
Hmm, no, pci_set_power_state should be called before
pcibios_enable_device, otherwise enable_device may fail. This is very
strange. In boot time, there also are uninitialized link devices, I'm
wonder why the call of pci_enable_device_bars doesn't fail in boot time.
Did you find the bug only in specific system?

Could you please file a bug in bugzilla? I don't want to lose the
context of thread. And please attach your acpidmp output in the bug.

Thanks,
Shaohua

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

Re: Can't use SYSFS for "Proprietry" driver modules !!!.

[Albert Cahalan]

greg k-h writes:
> On Sat, Mar 26, 2005 at 10:30:20PM -0500, Lee Revell wrote:

>> That's the problem, it's not spelled out explicitly anywhere.
>> That file does not address the issue of whether a driver is
>> a "derived work". This is the part he should talk to a lawyer
>> about, right?
>
> How about the fact that when you load a kernel module, it is
> linked into the main kernel image?  The GPL explicitly states
> what needs to be done for code linked in.

This probably fails. Obviously, it's not over until the courts
say so, but...

First of all, the GPL might not be as infectious as you and RMS
wish it to be. There is a limit to what can be a derived work
in copyright law.

Second of all, module loading is not the same as "linking" in
the traditional sense. The GPL was written before Linux had
kernel modules. Don't be so sure a court would rule as you
would like it to rule.

> Also, realize that you have to use GPL licensed header files
> to build your kernel module...

Um, like the printer cartridges and game cartridges with code
in them? Courts have held that it was OK to copy because it was
needed to implement an interface.

Whatever your lawyer may have said was undoubtably influenced
by your biased attempt to describe the technical issues.

Not that I care for proprietary stuff, being a PowerPC user
myself, but spreading unjustified FUD isn't proper behavior.
Neither is it proper to be marking key driver interfaces as
GPL-only. It's far better to just ignore the proprietary stuff.


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

Re: Can't use SYSFS for "Proprietry" driver modules !!!.

[Chris Wedgwood]

On Sun, Mar 27, 2005 at 10:10:56AM -0800, Greg KH wrote:

> How about the fact that when you load a kernel module, it is linked
> into the main kernel image?  The GPL explicitly states what needs to
> be done for code linked in.

oddly, the close nv driver has like 2.4MB if text in the kernel.  i
suspect a good chunk of this really should be in userspace but
probably lives in the kernel because 'the windows driver does that'

if the in-kernel part was trimmed down it would be nice for nv to move
the resource manager and whatever else lives in their gigantic module
(larger than most kernels!) to userspace and side-step the entire
issue completely

> Also, realize that you have to use GPL licensed header files to
> build your kernel module...

people could make their own.  i'm not sure if anyone has though.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problems on Apple iBook with ALSA and snd-powermac [2.6.11.5]

[Benjamin Herrenschmidt]

On Mon, 2005-03-28 at 01:08 +0200, Martin Loschwitz wrote:
> Hi folks,
> 
> given that the alsa-user-mailinglist has some strange kind of authentication
> mechanism, and admin-authorization and whatever, I'm writing this mail to the
> LKML (it would have been CCed here anyway).
> 
> The current snd-powermac module from ALSA seems to have trouble with modern
> Apple iBook computers (and possible other Apple notebooks, but I can't tell
> for sure). With 2.6.11.5 and having snd-powermac loaded, playing some sound
> results in a very noisy playback; you can only hear that if you turn volume
> on the PCM and VOL mixers up to the maximum, and even then, it's very hard 
> to hear. After removing snd-powermac and loading the "old" pmac-driver, the
> sound playback works just fine.

Have you tried disabling DRC Or increasing the DRC range level ?

> I have been able to find out that with 2.6.8 (at least with the version that
> Debian ships currently), the problem does not appear; snd-powermac does its
> job very nicely there. Given that 2.6.11 included some ALSA changes, I just
> compiled 2.6.10 on this box and booted it, and had the same problems I have
> with snd-powermac on 2.6.11.5.
> 
> Is this a known problem and is a fix available for it? If not, what can I do
> to help with hunting this bug? I really like ALSA and prefer it over the old
> pmac-sound-driver.
> 
-- 
Benjamin Herrenschmidt <[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: Disc driver is module, software suspend fails

[Jim Carter]

On Fri, 25 Mar 2005, Pavel Machek wrote:

> There's another feature that enables you to start resume manually with
> some echo to /sys... Perhaps it needs to be documented better, I'm
> looking for a patch ;-).

But how can it resume from a swap device for which it has no driver?
Even if you copied the needed module(s) onto the swap device, the kernel
needs the modules to be loaded before it can read anything.  The driver 
would be there if resuming happened after the initrd loaded it.  But
I wasn't able to make that actually work.

James F. Carter  Voice 310 825 2897FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
Email: [EMAIL PROTECTED]  http://www.math.ucla.edu/~jimc (q.v. for PGP key)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] radeonfb: Fix mode setting on CRT monitors

[Benjamin Herrenschmidt]

Hi !

Current radeonfb is a bit "anal" about accepting CRT modes, it basically only
accepts modes that have the exact resolution, which tends to break with fbcon
on console switches as it provides "approximate" modes. This patch fixes it
by having the driver chose the closest possible mode instead of looking for
an exact match.

Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>

--- linux-work.orig/drivers/video/aty/radeon_monitor.c  2005-03-11 
16:54:25.0 +1100
+++ linux-work/drivers/video/aty/radeon_monitor.c   2005-03-11 
16:58:04.0 +1100
@@ -903,7 +903,7 @@
  */
 
 /*
- * This is used when looking for modes. We assign a "goodness" value
+ * This is used when looking for modes. We assign a "distance" value
  * to a mode in the modedb depending how "close" it is from what we
  * are looking for.
  * Currently, we don't compare that much, we could do better but
@@ -912,13 +912,11 @@
 static int radeon_compare_modes(const struct fb_var_screeninfo *var,
const struct fb_videomode *mode)
 {
-   int goodness = 0;
+   int distance = 0;
 
-   if (var->yres == mode->yres)
-   goodness += 10;
-   if (var->xres == mode->xres)
-   goodness += 9;
-   return goodness;
+   distance = mode->yres - var->yres;
+   distance += (mode->xres - var->xres)/2;
+   return distance;
 }
 
 /*
@@ -940,7 +938,7 @@
const struct fb_videomode   *db = vesa_modes;
int i, dbsize = 34;
int has_rmx, native_db = 0;
-   int goodness = 0;
+   int distance = INT_MAX;
const struct fb_videomode   *candidate = NULL;
 
/* Start with a copy of the requested mode */
@@ -976,19 +974,19 @@
/* Now look for a mode in the database */
while (db) {
for (i = 0; i < dbsize; i++) {
-   int g;
+   int d;
 
if (db[i].yres < src->yres)
continue;   
if (db[i].xres < src->xres)
continue;
-   g = radeon_compare_modes(src, [i]);
+   d = radeon_compare_modes(src, [i]);
/* If the new mode is at least as good as the previous 
one,
 * then it's our new candidate
 */
-   if (g >= goodness) {
+   if (d < distance) {
candidate = [i];
-   goodness = g;
+   distance = d;
}
}
db = NULL;

-- 
Benjamin Herrenschmidt <[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: Can't use SYSFS for "Proprietry" driver modules !!!.

[Steven Rostedt]

On Mon, 2005-03-28 at 00:01 +0200, Adrian Bunk wrote:
> On Sun, Mar 27, 2005 at 01:37:11PM -0500, Steven Rostedt wrote:
> >...
> > Wasn't this long ago proven in court that the license of headers can't
> > control the code that calls them.  IIRC, it was with X Motif and making
> > free libraries for that. So, actually it was for a free solution for a
> > non free one (the other way around).  I believe the case sided on the
> > free use. But then again the free code may have had to write their own
> > headers and only the API was free. So if you want to compile against the
> > kernel, you may need to work on rewriting the headers from scratch. Ah,
> > but what do I know?
> >...
> 
> How do you define "proven in court"?
> 
> Decided by an US judge based on US laws?
> Decided by a German judge based on German laws?
> Decided by a Chinese judge based on Chinese laws?
> ...
> 

OK, I was talking about US courts since that case was done in the US.
But this is all what I remember about reading some 10 years ago. So I
could be all wrong about what happened. I don't have any references and
I'm too busy now to look them up. So I may be just speaking out of my
ass. :-)

> If you distribute software you can be sued in every country you 
> distribute it.
> 
> E.g. Harald Welte is currently quite successful with legal actions in 
> Germany against companies that distribute Linux-based routers in Germany 
> without offering the source of the GPL'ed software they use.

Your talking about something completely different.  Yes, it is quite
explicit if you modify the source, and distribute it in binary only
form.  I'm talking about writing a separate module that links with the
GPL code dynamically.  So that the code is compiled different from the
GPL code. So the only common part is the API. Now is this a derived
work? 

As someone mentioned already, if you write your own GPL interface that
supplies the interface for your binary module, is it legal?  The GPL
interface remains GPL and delivered with the source, but the binary is
only delivered binary, and may even be on a separate CD or whatever
medium you distribute with. Just like NVidia. They have their GPL layer
that compiles with the kernel and it supplies an interface for their
binary only version.  I haven't seen anyone take them to court.  Just a
lot of complaints about incompatibilities and tainted kernels on the
mailing list, but nothing more.

-- Steve


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

Re: [RFC] Some thoughts on device drivers and sysfs

[Arioch]

Adam Belay пишет:
I would like to propose that we create a new type of device that would
act as the layer between physical (bus devices) and logical (class
devices).  
why not using D-BUS to allow lowlevel drivers to expose its features to 
userspace?

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

Re: [RFC] spinlock_t & rwlock_t break_lock member initialization (patch seeking comments included)

[Jesper Juhl]

On Sun, 27 Mar 2005, Zwane Mwaikambo wrote:

> On Sun, 27 Mar 2005, Jesper Juhl wrote:
> 
> > I've now been running kernels (both PREEMPT, SMP, both and without both) 
> > with the patch below applied for a few days and I see no ill effects. I'm 
> > still interrested in comments about wether or not something like this 
> > makes sense and is acceptable ?
> 
> The concept seems fine to me, although i think you should be using named 
> initialisers instead.
> 
I wrote it the way I did to keep it similar to how the other members were 
initialized, I wouldn't mind a different approach, but doing it this way 
seemed to be what would "fit in" best, and it did the trick for me 
(silenced the annoying warnings) and seemed safe.

Thank you for taking the time to comment on this trivial issue.

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

Mac mini sound woes

[Benjamin Herrenschmidt]

Hi Takashi !

I'm looking into adding proper sound support for the Mac Mini. The
problem is that from what I've seen (Apple driver is only partially
opensource nowadays it seems, and the latest darwin drop is both
incomplete and doesn't build), that beast only has a fixed function D->A
converter, no HW volume control.

It seems that Apple's driver has an in-kernel framework for doing volume
control, mixing, and other horrors right in the kernel, in temporary
buffers, just before they get DMA'ed (gack !)

I want to avoid something like that. How "friendly" would Alsa be to
drivers that don't have any HW volume control capability ? Does typical
userland libraries provide software processing volume control ? Do you
suggest I just don't do any control ? Or should I implement a double
buffer scheme with software gain as well in the kernel driver ?

Ben.



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

imps2 mouse driver and bug 2082

[Mauro Mozzarelli]

The mouse driver, re-developed for kernel 2.6, ever since the earliest
2.6 release lost the ability to reset a broken link with an IMPS2 mouse
(this happens when disconnecting the mouse plug either physically or
through a "non imps2" KVM switch). The result is that the mouse can no
longer be controlled, with the only solution being a RE-BOOT!

This issue has been filed as bug 2082
(http://bugme.osdl.org/show_bug.cgi?id=2082) . A fix was posted for
2.6.8, but this patch never made its way into the kernel main stream.
"Vojtech", author of the 2.6 mouse driver, keeps modifying his code
version after version, therefore breaking compatibility with the posted
patch. I adapted the patch for 2.6.9 and 2.6.10 (there are now three
versions for 2.6.8, 2.6.9 and 2.6.10). Kernel 2.6.11(.6) was released
recently, still with the same bug, and would require further adaptation
of the posted patch.

I was wondering if some business related priority could be set for this
issue.

Given that most Linux deployments are in server farms, where boxes
share a console attached to a KVM that might good enough, but not
properly supporting IMPS2, please, could we include this patch in the
kernel main stream before adding support for any new mouse device that
hardly anyone running a server would be interested in?

Mauro


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

Re: Can't use SYSFS for "Proprietry" driver modules !!!.

[Greg KH]

On Sun, Mar 27, 2005 at 11:16:54AM -0800, Aaron Gyes wrote:
> > And then the user want to upgrade the 2.0 kernel that shipped with this 
> > box although the company that made the hardware went bankrupt some years 
> > ago.
> > 
> > If the user has the source of the driver, he can port the driver or hire 
> > someone to port the driver (this "obscure piece of hardware" might also 
> > be an expensive piece of hardware).
> 
> So what? Sure, GPL'd drivers are easier for an end-user in that case.
> What does that have to do with law? What about what's better for the
> company that made the device? Should NVIDIA be forced to give up their
> secrets to all their competitors because some over zealous developers
> say so? Should the end-users of the current drivers be forced to lose
> out on features such as sysfs and udev compatability?

It's not zealotry, it's called being compliant with the license of the
kernel.  It's as simple as that.  

If you ignore the license, you will suffer the consequences of it, just
like if you ignore the license of any closed source chunk of software.
Would you expect the owner of that software to turn a blind eye toward
violators?

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

Re: [PATCH] no need to check for NULL before calling kfree()-fs/ext2/

[linux-os]

On Sun, 27 Mar 2005, Arjan van de Ven wrote:
On Sat, 2005-03-26 at 18:21 -0500, linux-os wrote:
On Sat, 26 Mar 2005, Arjan van de Ven wrote:
On Fri, 2005-03-25 at 17:29 -0500, linux-os wrote:
Isn't it expensive of CPU time to call kfree() even though the
pointer may have already been freed?
nope
a call instruction is effectively half a cycle or less, the branch
Wrong!
oh? a call is "push eip + a new eip" effectively. the new eip is
entirely free, the push eip takes half a cycle (or 1 full cycle but only
one of the two/three pipelines).

predictor of the cpu can predict perfectly where the next instruction is
from. The extra if() you do in front is a different matter, that can
easily cost 100 cycles+. (And those are redundant cycles because kfree
will do the if again anyway). So what you propose is to spend 100+
cycles to save half a cycle. Not a good tradeoff ;)
Wrong!
Is it wrong that the cpu can predict the target perfectly? No. Unless
you use function pointers (then it's a  whole different ballgame).
Pure unmitigated bull-shit. I measure (with hardware devices)
the execution time of real code in modern CPUs. I do this for
a living so you don't have to stand in line for a couple of
hours to have your baggage scanned at the airport.
Ok I used to do this kind of performance work for a living too and
measuring it to death as well.
Always, always, a call will be more expensive than a branch
on condition.
It is not on modern Out of order cpus.
It's impossible to be otherwise. A call requires
that the return address be written to memory (the stack),
using register indirection (the stack-pointer).
and it's a so common pattern that it's optimized to death. Internally a
call gets transformed to 2 uops or so, one is push eip, the other is the
jmp (which gets then just absorbed by the "what is the next eip" logic,
just as a "jmp"s are 0 cycles)
If somebody said; "I think that the code will look better
and the few cycles lost will not be a consequence with modern
CPUs...", then there is a point. But coming up with this
disingenuous bullshit is something else.
I don't have to take this from you and I don't. You're calling me a liar
with zero evidence. Lets get some facts straight
1) On a modern cpu, a miss of the branch predictor is quite expensive.
  The entire pipeline needs flushing if this happens, and on a p4 this
  will be in the order of 50 to 100 cycles at minimum.
No. It depends upon how the branch prediction is done. If there are
two virtual logic-units, one that has already taken the result of
the TRUE condition the other that has already taken the result of
the FALSE condition, then the IP is set to the address of one
or the other, regardless of whatever is taken. Both of these
IPs are already in the cache because the branch logic makes
sure they are before the conditional test occurs. The possible loss
of performance occurs if there is another conditional branch that
must occur before the logic-units pipelines can be refilled.
This can happen if the tests are conducted like:
cmpl$NUMBER, %eax
jbe 1f  # First branch  ZF or CF
..  # Other code
..  # Other code
1:  jc  2f  # Immediate second branch on CF
Most compilers don't produce code like that, but they could.
The loss of performance is only the loss of the branch predictor,
for the second branch.
2) absolute "jmp" is free on modern OOO cpus. Instead of taking an
  actual execution slot, all that happens is that the "what is the next
  EIP" logic gets a different value. (you can argue what happens if you
  have a sequence of jmps and that it's not free then, and I'll grant
  you that, but that corner case is not relevant here)
So? I never even mentioned a jump and, falling through after
a conditional test is not a jump, it's just executing the
next instruction.
3) a "call" instruction gets translated into what basically is
  "push EIP" and "jmp" uops.
No, It can't be on machines that have a "call" instruction.
This is because, in cases where you use the same stack for
access to data, one needs to maintain the coherency of the
stack.  If I call 'kfree', I do:
pushl   (pointer)
callkfree
addl$4, %esp# Sizeof the pointer
... or
movl(pointer), %eax
pushl   %eax
callkfree
addl$4, %esp
(pointer) is a memory operand, could be on the stack or in
other data. It is the pointer you want to free.
When kfree() gets called, the value passed __must__ be in its
final place on the stack, which means that the return address
must be there and the stack-pointer value adjusted to its
final resting place. This is necessary so that code will
get the correct values. On ix86, the called function will
find the first passed parameter at 0x04(%esp). The return
address will be at 0x00(%esp).
With the test for NULL, a decent compiler will produce code
like:
movl(pointer), %eax
orl 

Problems on Apple iBook with ALSA and snd-powermac [2.6.11.5]

[Martin Loschwitz]

Hi folks,

given that the alsa-user-mailinglist has some strange kind of authentication
mechanism, and admin-authorization and whatever, I'm writing this mail to the
LKML (it would have been CCed here anyway).

The current snd-powermac module from ALSA seems to have trouble with modern
Apple iBook computers (and possible other Apple notebooks, but I can't tell
for sure). With 2.6.11.5 and having snd-powermac loaded, playing some sound
results in a very noisy playback; you can only hear that if you turn volume
on the PCM and VOL mixers up to the maximum, and even then, it's very hard 
to hear. After removing snd-powermac and loading the "old" pmac-driver, the
sound playback works just fine.

I have been able to find out that with 2.6.8 (at least with the version that
Debian ships currently), the problem does not appear; snd-powermac does its
job very nicely there. Given that 2.6.11 included some ALSA changes, I just
compiled 2.6.10 on this box and booted it, and had the same problems I have
with snd-powermac on 2.6.11.5.

Is this a known problem and is a fix available for it? If not, what can I do
to help with hunting this bug? I really like ALSA and prefer it over the old
pmac-sound-driver.

-- 
  .''`.   Martin Loschwitz   Debian GNU/Linux developer
 : :'  :  [EMAIL PROTECTED][EMAIL PROTECTED]
 `. `'`   http://www.madkiss.org/people.debian.org/~madkiss/
   `- Use Debian GNU/Linux 3.0!  See http://www.debian.org/


signature.asc
Description: Digital signature

Re: [PATCH] no need to check for NULL before calling kfree() -fs/ext2/

[Jesper Juhl]

On Sun, 27 Mar 2005, Dave Jones wrote:

> Am I the only person who is completely fascinated by the
> effort being spent here micro-optimising something thats
> almost never in a path that needs optimising ?
> I'd be amazed if any of this masturbation showed the tiniest
> blip on a real workload, or even on a benchmark other than
> one crafted specifically to test kfree in a loop.
> 
> That each occurance of this 'optimisation' also saves a handful
> of bytes in generated code is it's only real benefit afaics.
> Even then, if a functions cache performance is better off because
> we trimmed a few bytes from the tail of a function, I'd be
> completely amazed.
> 

I agree, it's amazing that this is treated like a big issue, it's not, and 
I never meant for it to be a matter of such debate. 

The whole thing (viewed from where I'm sitting) started when I noticed a 
few of those redundant NULL checks while reading code, thought I'd clean 
them up since they were clearly not needed and submit those patches. When 
those patches then got merged I thought "ok, so this is something that's 
actually appreciated, guess I might as well do some more when I come 
across them or maybe even seek them out and get rid of them once and for 
all"... So I started doing that and more of the patches got merged which 
(at least to me) confirmed that it was a worthwhile activity, until at 
some point voices were raised in objection.

At that point I felt I needed to explain the "why" of why I was doing it 
and try and show that it might actually be a bennefit (and I believe the 
small test I wrote shows it to be either a bennefit in the usual case or 
at worst a trivial performance hit in the not-so-common case).
What I'm trying to find out now is if there's a general consensus that 
these patches are worthwile and wanted or if they are unwanted and I'm 
wasting my time.  If the patches are wanted I don't mind doing them, but 
if they are not wanted I don't want to waste my time (nor anyone elses) on 
them.  So, if I could just get peoples comment on that "wanted vs 
not-wanted" then I could get on with either producing some patches for 
people or get on with other things and drop this... Or I guess I could 
just go on making those patches, submit them and then just leave it in the 
hands of the individual maintainers (which was more or less how I started 
out)...


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

[RFC] Driver States

[Adam Belay]

Dynamic power management may require devices and drivers to transition
between various physical and logical states.  I would like to start a
discussion on how these might be defined at the bus, driver, and class
levels.

Bus Level
=
At the bus level, there are two state attributes, power and
enable/disable.  Enable/disable may mean different things on different
buses, but they generally refer to resource decoding.  A device can only
be enabled during a non-off power state.

A possible API:

struct bus_type {
char* name;

struct subsystemsubsys;
struct kset drivers;
struct kset devices;

struct bus_attribute* bus_attrs;
struct device_attribute * dev_attrs;
struct driver_attribute * drv_attrs;

int (*match)(struct device * dev, struct device_driver * 
drv);
int (*hotplug) (struct device *dev, char **envp, 
int num_envp, char *buffer, int 
buffer_size);
int (*suspend)(struct device * dev, pm_message_t state);
int (*resume)(struct device * dev);
int (*enable)(struct device * dev);
int (*disable)(struct device * dev);
};

Driver Level

At the driver level there are two areas of interest, physical and
logical state.  There is an additional concern of transitioning between
these states multiple times.  Because a driver acts as a bridge between
physical and logical components, I think separating these steps seems
natural.

A possible API:

struct device_driver {
char* name;
struct bus_type * bus;

struct semaphoreunload_sem;
struct kobject  kobj;
struct list_headdevices;

struct module   * owner;

int (*attach)   (struct device * dev);
int (*start)(struct device * dev);
int (*open) (struct device * dev);
int (*close)(struct device * dev);
void(*stop) (struct device * dev);
void(*detach)   (struct device * dev);
void(*shutdown) (struct device * dev);
int (*suspend)  (struct device * dev, u32 state, u32 level);
int (*resume)   (struct device * dev, u32 level);
};

*attach - allocates data structures, creates sysfs entries, prepares driver
   to handle the hardware.
 
*start -  Sets up device resources and configures the hardware.  Loads
firmware, etc.
(physical)
 
*open -   engages the hardware, and makes it usable by the class device.
(logical and physical)
 
*close -  disengages the hardware, and stops class level access
(logical and physical)
 
*stop -   physically disables the hardware
(physical)
 
*detach - tears down the driver and releases it from the "struct device"

The idea behind *attach and *detach is to move code that would only need
to be called once out of *probe and *remove.

A table could be defined that indicates what should be called for each
power level transition.  *suspend and *resume could handle any extra
steps (ex. saving state).  As an example, *start and *stop may only be
called when power is going to be lost entirely.

Additional states are class specific and would only be used after *open
is called.

Class Level
===
At the class level, we could have a simple start/stop mechanism.

A possible API:

struct class_device {
struct list_headnode;

struct kobject  kobj;
struct class* class;
struct device   * dev;
void* class_data;

charclass_id[BUS_ID_SIZE];

int (*attach)   (struct device * dev);
int (*start)(struct device * dev);
void(*stop) (struct device * dev);
void(*detach)   (struct device * dev);
};

*attach - allocates data structures, creates sysfs entries, prepares
class to handle the device.

*start - start the logical class device, accept userspace interaction

*stop - stop the logical class device, deny userspace interaction

*detach - tear down the class driver's bindings with this class device


These are just rough ideas.  I look forward to any comments or
alternative approaches.

Thanks,
Adam


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

Re: Do not misuse Coverity please (Was: sound/oss/cs46xx.c: fix a check after use)

[Russell King]

On Mon, Mar 28, 2005 at 12:34:01AM +0200, Jean Delvare wrote:
> I think that you'd be better just telling the
> maintainers about the problem without providing an arbitrary patch, so
> that they will actually look into the problem with their advanced
> knowledge of the driver

FWIW, I agree with Jean.

Applying these patches without adequate review is like applying __iomem
or __user fixes where they've been generated with the aim of shutting up
sparse, rather than considering whether the warning is actually valid.
Once the warning is gone, the real problem is lost and never gets looked
at.

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

Re: Can't use SYSFS for "Proprietry" driver modules !!!.

[Dave Airlie]

> > How about the fact that when you load a kernel module, it is linked into
> > the main kernel image?  The GPL explicitly states what needs to be done
> > for code linked in.
> >
> I've always wondered about dynamically loaded modules (and libraries for
> that matter).  The standard IANAL, but I've talked to many to try to
> understand what is really legal, and I usually come up with the
> conclusion, it's just an interpretation of the law by the judge.
> 
> If the user is loading the module (or library) and the distributer
> doesn't, then is the the user breaking the license and not the
> distributer?

I think this is probably what the lawyers are telling the graphics
card companies at the moment, the GPL is broken by the act of linking
and at what stage is the link considered to have happened, so if I
distribute a GPL or BSD licensed stub layer in source form, a big
binary blob that doesn't use any kernel interfaces except my stub
layer ones, and never distribute any of it with a kernel or linked
into anything, am I breaking the GPL on the kernel? all I'm doing is
releasing some source code and some binary image files, the user is
doing the linking by loading my code into their running kernel  and
I'm not distributing my code with the kernel...

It'll be an interesting day in court... and maybe then derived work
will become nicely defined at least for one country

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

Re: Do not misuse Coverity please (Was: sound/oss/cs46xx.c: fix a check after use)

[Jean Delvare]

Hi Adrian,

> There are two cases:
> 1. NULL is impossible, the check is superfluous
> 2. this was an actual bug

Agreed.

> In the first case, my patch doesn't do any harm (a superfluous isn't
> a real bug).

The fact that it isn't a bug does not imply that the patch doesn't harm.
Tricking the reader into thinking that something can happen when it in
fact cannot does possibly harm in the long run.

> In the second case, it fixed a bug.
> It might be a bug not many people hit because it might be in some
> error path of some esoteric driver.

True, except that e.g. the sg_mmap() function of scsi/sg hardly falls
into this category. Same for fbcon_init() in video/console/fbcon. You
don't seem to treat core code any differently than esoteric drivers.

> If a maintainer of a well-maintained subsystem like i2c says
> "The check is superfluous." that's the perfect solution.
> 
> But in less maintained parts of the kernel, even a low possibility
> that it fixes a possible bug is IMHO worth making such a riskless
> patch.

This is where my opinion strongly differs.

The very fact that these "check after use" cases were not fixed yet
means that they are not hit frequently, if ever, regardless of how
popular the driver is. This means that we have (relatively) plenty of
time to fix them. At least Coverity or a similar tool will keep
reminding us to take a look and decide what must be done after we
carefully checked the code. Your approach will not let us do that.
Mass-posting these patches here is likely to make them end in Andrew's
tree soon and to Linus' right after that is nobody objects, right?

If you can make sure that none of these patches ever reaches Linus' tree
without their respective driver maintainer having confirmed that they
were the right thing to do, then fine with me, but it doesn't look like
the way things will go. I think that you'd be better just telling the
maintainers about the problem without providing an arbitrary patch, so
that they will actually look into the problem with their advanced
knowledge of the driver, rather than merely ack'ing that the patch looks
OK, which I think is what will happen with your method. (I'd love to be
proven wrong though.)

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

Network Performance Ingo's RT-Preempt

[Christensen Tom]

I'm running 2.6.11 with Ingo's Preempt patch 
(realtime-preempt-2.6.11-final-V0.7.40-04).  The system is SMP with a 
broadcom NIC (tg3 driver).  I am seeing truly appalling network performance 
(2-4kbps on a 1gbps network).  Is this a known issue?  I know this patch is 
not production ready, what traces/logs do you need/want to be able to 
debug/fix this?
Thanks,
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/

i386/x86_64 segment register issuses (Re: PATCH: Fix x86 segment register access)

[H. J. Lu]

It turns out that 2.4 kernel has

arch/i386/kernel/process.c: asm volatile("movl %%" #seg ",%0":"=m" (*(int 
*)&(value)))
arch/i386/kernel/process.c: asm volatile("movl %%fs,%0":"=m" (*(int 
*)>fs));
arch/i386/kernel/process.c: asm volatile("movl %%gs,%0":"=m" (*(int 
*)>gs));
arch/x86_64/kernel/process.c:   asm("movl %%gs,%0" : "=m" (p->thread.gsindex));
arch/x86_64/kernel/process.c:   asm("movl %%fs,%0" : "=m" (p->thread.fsindex));
arch/x86_64/kernel/process.c:   asm("movl %%es,%0" : "=m" (p->thread.es));
arch/x86_64/kernel/process.c:   asm("movl %%ds,%0" : "=m" (p->thread.ds));
arch/x86_64/kernel/process.c:   asm volatile("movl %%es,%0" : "=m" (prev->es));
arch/x86_64/kernel/process.c:   asm volatile ("movl %%ds,%0" : "=m" (prev->ds));

2.6 kernel has

arch/i386/kernel/process.c: asm volatile("movl %%fs,%0":"=m" (*(int 
*)>fs));
arch/i386/kernel/process.c: asm volatile("movl %%gs,%0":"=m" (*(int 
*)>gs));
arch/x86_64/kernel/process.c:   asm("movl %%gs,%0" : "=m" (p->thread.gsindex));
arch/x86_64/kernel/process.c:   asm("movl %%fs,%0" : "=m" (p->thread.fsindex));
arch/x86_64/kernel/process.c:   asm("movl %%es,%0" : "=m" (p->thread.es));
arch/x86_64/kernel/process.c:   asm("movl %%ds,%0" : "=m" (p->thread.ds));
arch/x86_64/kernel/process.c:   asm volatile("movl %%es,%0" : "=m" (prev->es));
arch/x86_64/kernel/process.c:   asm volatile ("movl %%ds,%0" : "=m" (prev->ds));
arch/x86_64/kernel/process.c:   asm volatile("movl %%fs,%0" : "=g" 
(fsindex));
arch/x86_64/kernel/process.c:   asm volatile("movl %%gs,%0" : "=g" 
(gsindex));

The new assembler will disallow them since those instructions with
memory operand will only use the first 16bits. If the memory operand
is 16bit, you won't see any problems. But if the memory destinatin
is 32bit, the upper 16bits may have random values. The new assembler
will force people to use

mov (%eax),%ds
movw (%eax),%ds
movw %ds,(%eax)
mov %ds,(%eax)

Will it be a big problem for kernel people?

BTW, I haven't checked glibc yet. It may have similar issues.

H.J.
---
On Fri, Mar 25, 2005 at 06:05:06PM -0800, H. J. Lu wrote:
> X86 segment register access is a special. We can move between a segment
> register and a 16/32/64bit general-purpose register. But we can only
> move between a segment register and a 16bit memory address. The current
> assembler allows "movl (%eax),%ds", but doesn't allow "movq %rax,%ds".
> The disassembler display "movl (%eax),%ds". This patch tries to fix
> those.
> 
> 
> H.J.
> 
> gas/testsuite/
> 
> 2005-03-25  H.J. Lu  <[EMAIL PROTECTED]>
> 
>   * gas/i386/i386.exp: Run segment and inval-seg for i386. Run
>   x86-64-segment and x86-64-inval-seg for x86-64.
> 
>   * gas/i386/intel.d: Expect movw for moving between memory and
>   segment register.
>   * gas/i386/naked.d: Likewise.
>   * gas/i386/opcode.d: Likewise.
>   * gas/i386/x86-64-opcode.d: Likewise.
> 
>   * gas/i386/opcode.s: Use movw for moving between memory and
>   segment register.
>   * gas/i386/x86-64-opcode.s: Likewise.
> 
>   * : Likewise.
> 
>   * gas/i386/inval-seg.l: New.
>   * gas/i386/inval-seg.s: New.
>   * gas/i386/segment.l: New.
>   * gas/i386/segment.s: New.
>   * gas/i386/x86-64-inval-seg.l: New.
>   * gas/i386/x86-64-inval-seg.s: New.
>   * gas/i386/x86-64-segment.l: New.
>   * gas/i386/x86-64-segment.s: New.
> 
> include/opcode/
> 
> 2005-03-25  H.J. Lu  <[EMAIL PROTECTED]>
> 
>   * i386.h (i386_optab): Don't allow the `l' suffix for moving
>   moving between memory and segment register. Allow movq for
>   moving between general-purpose register and segment register.
> 
> opcodes/
> 
> 2005-03-25  H.J. Lu  <[EMAIL PROTECTED]>
> 
>   * i386-dis.c (SEG_Fixup): New.
>   (Sv): New.
>   (dis386): Use "Sv" for 0x8c and 0x8e.
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Some thoughts on device drivers and sysfs

[Adam Belay]

On Sun, 2005-03-27 at 23:43 +0200, Dominik Brodowski wrote:
> On Sun, Mar 27, 2005 at 04:27:24PM -0500, Adam Belay wrote:
> > > extern int device_create_file(struct device *device, struct 
> > > device_attribute
> > > * entry);
> > > and delete them (e.g. in ->remove) using
> > > extern void device_remove_file(struct device * dev, struct 
> > > device_attribute
> > > * attr);
> > > 
> > > and there's also 
> > > 
> > > extern int driver_create_file(struct device_driver *, struct
> > > driver_attribute *);
> > > extern void driver_remove_file(struct device_driver *, struct
> > > driver_attribute *);
> > > 
> > > 
> > >   Dominik
> > 
> > Yes, I'm aware of these functions but they pollute the bus level
> > namespace.  I'm interested in reactions to this alternative approach.  I
> > wanted to explore the possibility of making a device driver instance a
> > separate component with its own individual state and relationships.
> 
> To be honest, I don't consider this to be a pollution of the "bus"
> namespace, but I fear that having two different places for somewhat similar,
> or even equal, data adds unneeded complexity to the driver model. In what
> specific instances has the current design limited or obstructed your
> intentions?
> 

Fair enough.  I just wanted to float this possibility.  I appreciate
your comments.  The original intention for this design was to begin
working on a framework for driver layering.  (ex. snd-intel8x0m -> ac97,
or the pci express bus abstraction)  I was considering the possibility
of having driver devices with parent and child relationships that
reflect the internal layering of Linux drivers.  I haven't really had a
chance to fully develop this idea, so at this point, driver layering and
my original email are just abstract concepts.

Adam


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

Re: SATA Promise TX4 Crash

[Neil Whelchel]

On Sat, 26 Mar 2005, quasiben wrote:

> Dear Neil Whelchel,
>  I have been having very similar problems.  However, my setup is
> somewhat different.  I have a LVM logical volume that spans two disks
> (one PATA and one SATA).  Did you upgrade your PSU as one person
> suggested ? If so, did it work ?
>
> --Benji
>
> Neil Whelchel wrote:
> > Hello,
> > I have two Promise SATA TX4 cards connected to a total of 6 Maxtor
> 250 GB
> > drives (7Y250M0) configured into a RAID 5. All works well with small
> > disk load, but when a large number of requests are issued, it causes
> crash
> > similar to the attached, except that the errors before the crash are
> on a
> > different drive nearly every time. I have tried several different
> > motherboards with both Nvidia and Via chipsets, with Athlon and K6
> > CPUs, and the crash remains the same. I have also seen the same crash
> > with both a preemptable and a non-preemptable kernel, with kernel
> > versions 2.6.9, 2.6.10, 2.6.11, and 2.6.11.2 (this one).
> > Any suggestions, or is this a bug?
> >
> >
> > ata3: status=0x51 { DriveReady SeekComplete Error }
> > ata3: error=0x40 { UncorrectableError }
> > ata3: status=0x51 { DriveReady SeekComplete Error }
> > ata3: error=0x40 { UncorrectableError }
> > ata3: status=0x51 { DriveReady SeekComplete Error }
> > ata3: error=0x40 { UncorrectableError }
> > ata3: status=0x51 { DriveReady SeekComplete Error }
> > ata3: error=0x40 { UncorrectableError }
> > ata3: status=0x51 { DriveReady SeekComplete Error }
> > ata3: error=0x40 { UncorrectableError }
> > ata3: command timeout
> > Assertion failed! qc->flags &
> >
> ATA_QCFLAG_ACTIVE,drivers/scsi/libata-core.c,ata_qc_complete,line=2807
> > ata3: status=0x51 { DriveReady SeekComplete Error }
> > ata3: called with no error (51)!
> > [ cut here ]
> > kernel BUG at drivers/scsi/scsi.c:299!
> > invalid operand:  [#1]
> > PREEMPT
> > Modules linked in:
> > CPU:0
> > EIP:0060:[]Not tainted VLI
> > EFLAGS: 00010046   (2.6.11.2)
> > EIP is at scsi_put_command+0xbb/0x100
> > eax: 0001   ebx: c2f5e390   ecx: 0001   edx: c2f5e390
> > esi: c2f5e380   edi: 0246   ebp: c7c4beb4   esp: c7c4be9c
> > ds: 007b   es: 007b   ss: 0068
> > Process scsi_eh_2 (pid: 821, threadinfo=c7c4a000 task=c7c315b0)
> > Stack: 0296 c7c3 c7c26400 c7c23030 c2f5e380 0246 c7c4bec4
> c02ae9b3
> >c2f5e380 c44a1740 c7c4bee0 c02aeabc c2f5e380 c7c23030 c2f5e380
> 0802
> >c44a1740 c7c4bf28 c02aedd2 c2f5e380 0001  
> 
> > Call Trace:
> >  [] show_stack+0x72/0xa0
> >  [] show_registers+0x104/0x180
> >  [] die+0xd3/0x180
> >  [] do_invalid_op+0x90/0xa0
> >  [] error_code+0x2b/0x30
> >  [] scsi_next_command+0x13/0x20
> >  [] scsi_end_request+0xbc/0xe0
> >  [] scsi_io_completion+0x132/0x3c0
> >  [] sd_rw_intr+0xb8/0x2c0
> >  [] ata_scsi_qc_complete+0x20/0x40
> >  [] ata_qc_complete+0x2c/0xa0
> >  [] pdc_eng_timeout+0x93/0x120
> >  [] ata_scsi_error+0x14/0x40
> >  [] scsi_error_handler+0x5b/0xc0
> >  [] kernel_thread_helper+0x5/0x14
> > Code: ec 8b 42 08 ff 30 e8 e5 cd e8 ff 59 5b 8b 45 f0 05 84 01 00 00
> 89 45
> > 08 8d 65 f4 5b 5e 5f c9 e9 ac 41 fc ff e8 47 6c 13 00 eb ce <0f> 0b
> 2b 01
> > d6 e8 40 c0 e9 6c ff ff ff e8 33 6c 13 00 eb 8b 89
> >  <6>note: scsi_eh_2[821] exited with preempt_count 1
> >
> >
> > -Neil Whelchel-
> > First Light Internet Services
> > 760 366-0145
> > - We don't do Window$, that's what the janitor is for -
> >
> > Bubble Memory, n.:
> > A derogatory term, usually referring to a person's
> > intelligence.  See also "vacuum tube".
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
>
Hello,
Yes, I did replace the PSU about 6 times. I had the same problem with 4
similar machines (all the same), and in one of them I tried two
other different power supplies, so there were a total of three completely
different supplies tested. All of them were 450 Watts, except for one 500
Watt that I tested..
While, my 'feelings' tell me that the PSU is the issue, I have been
looking more to grounding and SATA cable than anything else. But there is
one HUGE however here... If there is a communication failure, it should
not cause a crash in the kernel, this should be fixed!

-Neil Whelchel-
First Light Internet Services
760 366-0145
- We don't do Window$, that's what the janitor is for -

Bubble Memory, n.:
A derogatory term, usually referring to a person's
intelligence.  See also "vacuum tube".

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] no need to check for NULL before calling kfree() -fs/ext2/

[linux-os]

On Sat, 26 Mar 2005, Marcin Dalecki wrote:
On 2005-03-27, at 00:21, linux-os wrote:
Always, always, a call will be more expensive than a branch
on condition. It's impossible to be otherwise. A call requires
that the return address be written to memory (the stack),
using register indirection (the stack-pointer).
Needless to say that there are enough architectures out there, which
don't even
have something like an explicit call as separate assembler
instruction...
Yes, they break the 'call' into seperate expensive operations like
loading the IP address that will exist after the call into a register
storing that in a dedicated register, used as a "stack", then
branching to the called procedure with another indirection, etc.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/usb/media/usbvideo.c: fix a check after use

[Jean Delvare]

Hi Adrian,

> This patch fixes a check after use found by the Coverity checker.
> 
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> 
> --- linux-2.6.12-rc1-mm1-full/drivers/usb/media/usbvideo.c.old
> 2005-03-23 04:59:11.0 +0100
> +++ linux-2.6.12-rc1-mm1-full/drivers/usb/media/usbvideo.c2005-03-23 
> 04:59:46.0 +0100
> @@ -1814,12 +1814,12 @@
>  {
>   int i, j;
>  
> - if (uvd->debug > 1)
> - info("%s($%p)", __FUNCTION__, uvd);
> -
>   if ((uvd == NULL) || (!uvd->streaming) || (uvd->dev == NULL))
>   return;
>  
> + if (uvd->debug > 1)
> + info("%s($%p)", __FUNCTION__, uvd);
> +

Note that you slightly change the debug trace when doing this. For
example, the case where udv != NULL and !udv->streaming would display
the debug line before your patch, and no more after.

Now I don't know whether that change is a problem or not in this
particular case, as I am not the one who would debug this driver if
there were a problem with it, but this is something to pay attention to
in such cases.

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

Re: Can't use SYSFS for "Proprietry" driver modules !!!.

[Adrian Bunk]

On Sun, Mar 27, 2005 at 01:37:11PM -0500, Steven Rostedt wrote:
>...
> Wasn't this long ago proven in court that the license of headers can't
> control the code that calls them.  IIRC, it was with X Motif and making
> free libraries for that. So, actually it was for a free solution for a
> non free one (the other way around).  I believe the case sided on the
> free use. But then again the free code may have had to write their own
> headers and only the API was free. So if you want to compile against the
> kernel, you may need to work on rewriting the headers from scratch. Ah,
> but what do I know?
>...

How do you define "proven in court"?

Decided by an US judge based on US laws?
Decided by a German judge based on German laws?
Decided by a Chinese judge based on Chinese laws?
...

If you distribute software you can be sued in every country you 
distribute it.

E.g. Harald Welte is currently quite successful with legal actions in 
Germany against companies that distribute Linux-based routers in Germany 
without offering the source of the GPL'ed software they use.

> -- Steve

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: Can't use SYSFS for "Proprietry" driver modules !!!.

[Steven Rostedt]

On Sun, 2005-03-27 at 10:10 -0800, Greg KH wrote:

> How about the fact that when you load a kernel module, it is linked into
> the main kernel image?  The GPL explicitly states what needs to be done
> for code linked in.
> 
I've always wondered about dynamically loaded modules (and libraries for
that matter).  The standard IANAL, but I've talked to many to try to
understand what is really legal, and I usually come up with the
conclusion, it's just an interpretation of the law by the judge.

If the user is loading the module (or library) and the distributer
doesn't, then is the the user breaking the license and not the
distributer?

> Also, realize that you have to use GPL licensed header files to build
> your kernel module...
> 

Wasn't this long ago proven in court that the license of headers can't
control the code that calls them.  IIRC, it was with X Motif and making
free libraries for that. So, actually it was for a free solution for a
non free one (the other way around).  I believe the case sided on the
free use. But then again the free code may have had to write their own
headers and only the API was free. So if you want to compile against the
kernel, you may need to work on rewriting the headers from scratch. Ah,
but what do I know?

My code usually falls under something like LGPL. Link with what you
want, but keep any changes to my code open.  I know that this is not the
stance of the kernel and I respect that. But I'm still waiting for the
day in court that talks about dynamic modules and libraries.

-- Steve




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

Re: [RFC] Some thoughts on device drivers and sysfs

[Dominik Brodowski]

On Sun, Mar 27, 2005 at 04:27:24PM -0500, Adam Belay wrote:
> > extern int device_create_file(struct device *device, struct device_attribute
> > * entry);
> > and delete them (e.g. in ->remove) using
> > extern void device_remove_file(struct device * dev, struct device_attribute
> > * attr);
> > 
> > and there's also 
> > 
> > extern int driver_create_file(struct device_driver *, struct
> > driver_attribute *);
> > extern void driver_remove_file(struct device_driver *, struct
> > driver_attribute *);
> > 
> > 
> > Dominik
> 
> Yes, I'm aware of these functions but they pollute the bus level
> namespace.  I'm interested in reactions to this alternative approach.  I
> wanted to explore the possibility of making a device driver instance a
> separate component with its own individual state and relationships.

To be honest, I don't consider this to be a pollution of the "bus"
namespace, but I fear that having two different places for somewhat similar,
or even equal, data adds unneeded complexity to the driver model. In what
specific instances has the current design limited or obstructed your
intentions?

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

Re: Do not misuse Coverity please (Was: sound/oss/cs46xx.c: fix a check after use)

[Adrian Bunk]

On Sun, Mar 27, 2005 at 11:21:58PM +0200, Jean Delvare wrote:
> Hi Adrian,
> 
> > This patch fixes a check after use found by the Coverity checker.
> > (...)
> >  static void amp_hercules(struct cs_card *card, int change)
> >  {
> > -   int old=card->amplifier;
> > +   int old;
> > if(!card)
> > {
> > CS_DBGOUT(CS_ERROR, 2, printk(KERN_INFO 
> > "cs46xx: amp_hercules() called before initialized.\n"));
> > return;
> > }
> > +   old = card->amplifier;
> 
> I see that you are fixing many bugs like this one today, all reported by
> Coverity. In all cases (as far as I could see at least) you are moving
> the dereference after the check. Of course it prevents any NULL pointer
> dereference, and will make Coverity happy. However, I doubt that this is
> always the correct solution.
> 
> Think about it. If the pointer could be NULL, then it's unlikely that
> the bug would have gone unnoticed so far (unless the code is very
> recent). Coverity found 3 such bugs in one i2c driver [1], and the
> correct solution was to NOT check for NULL because it just couldn't
> happen. Could be the case for all the bugs you are fixing right now too.
> 
> [1] http://linux.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED]
> 
> Coverity and similar tools are a true opportunity for us to find out and
> study suspect parts of our code. Please do not misuse these tools! The
> goal is NOT to make the tools happy next time you run them, but to
> actually fix the problems, once and for all. If you focus too much on
> fixing the problems quickly rather than fixing them cleanly, then we
> forever lose the opportunity to clean our code, because the problems
> will then be hidden. If you look at case [1] above, you'll see that we
> were able to fix more than just what Coverity had reported.
>...

There are two cases:
1. NULL is impossible, the check is superfluous
2. this was an actual bug

In the first case, my patch doesn't do any harm (a superfluous isn't a 
real bug).

In the second case, it fixed a bug.
It might be a bug not many people hit because it might be in some error 
path of some esoteric driver.

If a maintainer of a well-maintained subsystem like i2c says
"The check is superfluous." that's the perfect solution.

But in less maintained parts of the kernel, even a low possibility that 
it fixes a possible bug is IMHO worth making such a riskless patch.

> Thanks,
> Jean Delvare

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: [RFC] Some thoughts on device drivers and sysfs

[Jon Smirl]

On Sun, 27 Mar 2005 14:24:59 -0500, Adam Belay <[EMAIL PROTECTED]> wrote:
> This would allow us to represent per-device driver attributes in sysfs.
> As an added benefit, driver devices would allow the tracking and control
> of driver state, which may be needed for dynamic power management.  I
> look forward to any comments.

Isn't there already a way to do this? I recall some discussion lkml
about six months ago  about doing it. I tried googling for it but
couldn't find it. It may not have been implemented.

-- 
Jon Smirl
[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: Do not misuse Coverity please (Was: sound/oss/cs46xx.c: fix a check after use)

[Jean Delvare]

Hi Adrian,

> This patch fixes a check after use found by the Coverity checker.
> (...)
>  static void amp_hercules(struct cs_card *card, int change)
>  {
> - int old=card->amplifier;
> + int old;
>   if(!card)
>   {
>   CS_DBGOUT(CS_ERROR, 2, printk(KERN_INFO 
>   "cs46xx: amp_hercules() called before initialized.\n"));
>   return;
>   }
> + old = card->amplifier;

I see that you are fixing many bugs like this one today, all reported by
Coverity. In all cases (as far as I could see at least) you are moving
the dereference after the check. Of course it prevents any NULL pointer
dereference, and will make Coverity happy. However, I doubt that this is
always the correct solution.

Think about it. If the pointer could be NULL, then it's unlikely that
the bug would have gone unnoticed so far (unless the code is very
recent). Coverity found 3 such bugs in one i2c driver [1], and the
correct solution was to NOT check for NULL because it just couldn't
happen. Could be the case for all the bugs you are fixing right now too.

[1] http://linux.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED]

Coverity and similar tools are a true opportunity for us to find out and
study suspect parts of our code. Please do not misuse these tools! The
goal is NOT to make the tools happy next time you run them, but to
actually fix the problems, once and for all. If you focus too much on
fixing the problems quickly rather than fixing them cleanly, then we
forever lose the opportunity to clean our code, because the problems
will then be hidden. If you look at case [1] above, you'll see that we
were able to fix more than just what Coverity had reported.

Considering the very important flow of patches you are sending these
days, I have to admit I am quite suspicious that you don't really
investigate all issues individually as you should, but merely want to
fix as many bugs as possible in a short amount of time. This is not,
IMVHO, what needs to be done. Of course, if you actually investigated
all these bugs and are certain that none of these checks can be removed
because pointers can actually be NULL in regular cases, then please
accept my humble apologizes and keep up with the good work.

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

Re: Can't use SYSFS for "Proprietry" driver modules !!!.

[Diego Calleja]

El Sun, 27 Mar 2005 11:16:54 -0800,
Aaron Gyes <[EMAIL PROTECTED]> escribió:

> company that made the device? Should NVIDIA be forced to give up their
> secrets to all their competitors because some over zealous developers
> say so? Should the end-users of the current drivers be forced to lose

Is not just about zealotism, propietary drivers have to deal with locking, 
multiple
architectures and so on, and often they're not very good at that.

Note that this is not a problem only with linux, Windows is suffering the same
every day. Here: http://blogs.msdn.com/oldnewthing/archive/2004/03/05/84469.aspx
is a good example of how *scary* can be. This is what happens in a OS where a 
certification process is needed. I don't want to know what are they doing in 
linux,
where such certification doesn't exist.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] MAINTAINERS: remove obsolete HPUSBSCSI entry

[Adrian Bunk]

It seems I forgot MAINTAINERS in my patch that removed this driver...

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

--- linux-2.6.12-rc1-mm3-full/MAINTAINERS.old   2005-03-27 23:17:59.0 
+0200
+++ linux-2.6.12-rc1-mm3-full/MAINTAINERS   2005-03-27 23:18:07.0 
+0200
@@ -998,11 +998,6 @@
 W: http://artax.karlin.mff.cuni.cz/~mikulas/vyplody/hpfs/index-e.cgi
 S: Maintained
 
-HPUSBSCSI
-P: Oliver Neukum
-M: [EMAIL PROTECTED]
-S: Maintained
-
 HUGETLB FILESYSTEM
 P: William Irwin
 M: [EMAIL PROTECTED]

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

[2.6 patch] sound/oss/rme96xx.c: fix two check after use

[Adrian Bunk]

This patch fixes two check after use found by the Coverity checker.

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

--- linux-2.6.12-rc1-mm3-full/sound/oss/rme96xx.c.old   2005-03-27 
23:16:02.0 +0200
+++ linux-2.6.12-rc1-mm3-full/sound/oss/rme96xx.c   2005-03-27 
23:16:11.0 +0200
@@ -1534,18 +1534,20 @@
 static ssize_t rme96xx_write(struct file *file, const char __user *buffer, 
size_t count, loff_t *ppos)
 {
struct dmabuf *dma = (struct dmabuf *)file->private_data;
ssize_t ret = 0;
int cnt; /* number of bytes from "buffer" that will/can be used */
-   int hop = count/dma->outchannels;
+   int hop;
int hwp;
int exact = (file->f_flags & O_NONBLOCK); 
 
 
if(dma == NULL || (dma->s) == NULL) 
return -ENXIO;
 
+   hop = count/dma->outchannels;
+
if (dma->mmapped || !dma->opened)
return -ENXIO;
 
if (!access_ok(VERIFY_READ, buffer, count))
return -EFAULT;
@@ -1599,18 +1601,20 @@
 static ssize_t rme96xx_read(struct file *file, char __user *buffer, size_t 
count, loff_t *ppos)
 { 
struct dmabuf *dma = (struct dmabuf *)file->private_data;
ssize_t ret = 0;
int cnt; /* number of bytes from "buffer" that will/can be used */
-   int hop = count/dma->inchannels;
+   int hop;
int hwp;
int exact = (file->f_flags & O_NONBLOCK); 
 
 
if(dma == NULL || (dma->s) == NULL) 
return -ENXIO;
 
+   hop = count/dma->inchannels;
+
if (dma->mmapped || !dma->opened)
return -ENXIO;
 
if (!access_ok(VERIFY_WRITE, buffer, count))
return -EFAULT;

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

[2.6 patch] drivers/pci/msi.c: fix a check after use

[Adrian Bunk]

This patch fixes a check after use found by the Coverity checker.

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

--- linux-2.6.12-rc1-mm1-full/drivers/pci/msi.c.old 2005-03-23 
04:46:30.0 +0100
+++ linux-2.6.12-rc1-mm1-full/drivers/pci/msi.c 2005-03-23 04:47:03.0 
+0100
@@ -703,12 +703,14 @@
  **/
 int pci_enable_msi(struct pci_dev* dev)
 {
-   int pos, temp = dev->irq, status = -EINVAL;
+   int pos, temp, status = -EINVAL;
u16 control;
 
if (!pci_msi_enable || !dev)
return status;
 
+   temp = dev->irq;
+
if ((status = msi_init()) < 0)
return status;
 

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

Re: [RFC] Some thoughts on device drivers and sysfs

[Dominik Brodowski]

On Sun, Mar 27, 2005 at 02:24:59PM -0500, Adam Belay wrote:
> One of the original design goals of sysfs was to provide a standardized
> location to keep driver configuration attributes.  Although sysfs
> handles this very well for bus devices and class devices, there isn't
> currently a method to export attributes for device drivers and their
> specific bound device instances to userspace.

Drivers can add (e.g. in ->probe) attributes for devices using
extern int device_create_file(struct device *device, struct device_attribute
* entry);
and delete them (e.g. in ->remove) using
extern void device_remove_file(struct device * dev, struct device_attribute
* attr);

and there's also 

extern int driver_create_file(struct device_driver *, struct
driver_attribute *);
extern void driver_remove_file(struct device_driver *, struct
driver_attribute *);


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

Re: BK snapshots removed from kernel.org?

[Barry K. Nathan]

On Sun, Mar 27, 2005 at 02:14:33PM -0300, Norberto Bensa wrote:
[quote rewrapped to keep it within 80 columns]
> Why were snapshots (-bk) removed from www.kernel.org? I can't see any
> relevant post in LKML.

It happens whenever the kernel.org scripts get confused. It's happened
at least once before; this time I think it happened when the fixes
from 2.6.11.6 were merged into Linus's BK tree.

You can still get to the snapshots using this URL, but as I said, the
scripts are confused right now:
http://kernel.org/pub/linux/kernel/v2.6/snapshots/

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

[2.6 patch] sound/oss/cs46xx.c: fix a check after use

[Adrian Bunk]

This patch fixes a check after use found by the Coverity checker.

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

--- linux-2.6.12-rc1-mm1-full/sound/oss/cs46xx.c.old2005-03-23 
04:48:53.0 +0100
+++ linux-2.6.12-rc1-mm1-full/sound/oss/cs46xx.c2005-03-23 
04:49:31.0 +0100
@@ -3086,13 +3086,14 @@
  
 static void amp_hercules(struct cs_card *card, int change)
 {
-   int old=card->amplifier;
+   int old;
if(!card)
{
CS_DBGOUT(CS_ERROR, 2, printk(KERN_INFO 
"cs46xx: amp_hercules() called before initialized.\n"));
return;
}
+   old = card->amplifier;
card->amplifier+=change;
if( (card->amplifier && !old) && !(hercules_egpio_disable))
{

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

Re: Can't use SYSFS for "Proprietry" driver modules !!!.

[James Courtier-Dutton]

Mark Fortescue wrote:
> Hi,
> 
> I am writing a "Proprietry" driver module for a "Proprietry" PCI card and
> I have found that I can't use SYSFS on Linux-2.6.10.
> 
> Why ?. 
> 
> I am not modifing the Kernel/SYSFS code so I should be able, to use all
> the SYSFS/internal kernel function calls without hinderence.
> 
> In order to be able to use SYSFS to debug the driver during development
> the way I would like to be able to do, I will have to temporally change
> the module licence line to "GPL". When the development is finnished I will
> then need to remove all the code that accesses the SYSFS stuf in the
> Kernel and change the module back to a "Proprietry" licence in order to
> comply with other requirements. This will then hinder any debugging if
> future issues arise.
> 
> I believe that this sort of idiocy is what helps Microsoft hold on to its
> manopoly and as shuch hinders hardware/software development in all areas
> and should be chanaged in a way that promotes diversified software
> development.
> 
> Regards
>   Mark Fortescue.
> 
> 

If you wish to keep stuff secret, just don't bother with Linux drivers
for it. Use your PCI card in windows or some other system. Linux is
supposed to be open source...live with 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/

[2.6 patch] drivers/usb/media/usbvideo.c: fix a check after use

[Adrian Bunk]

This patch fixes a check after use found by the Coverity checker.

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

--- linux-2.6.12-rc1-mm1-full/drivers/usb/media/usbvideo.c.old  2005-03-23 
04:59:11.0 +0100
+++ linux-2.6.12-rc1-mm1-full/drivers/usb/media/usbvideo.c  2005-03-23 
04:59:46.0 +0100
@@ -1814,12 +1814,12 @@
 {
int i, j;
 
-   if (uvd->debug > 1)
-   info("%s($%p)", __FUNCTION__, uvd);
-
if ((uvd == NULL) || (!uvd->streaming) || (uvd->dev == NULL))
return;
 
+   if (uvd->debug > 1)
+   info("%s($%p)", __FUNCTION__, uvd);
+
/* Unschedule all of the iso td's */
for (i=0; i < USBVIDEO_NUMSBUF; i++) {
usb_kill_urb(uvd->sbuf[i].urb);

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] fs/udf/inode.c: fix a check after use

[Adrian Bunk]

This patch fixes a check after use found by the Coverity checker.

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

--- linux-2.6.12-rc1-mm1-full/fs/udf/inode.c.old2005-03-23 
05:12:25.0 +0100
+++ linux-2.6.12-rc1-mm1-full/fs/udf/inode.c2005-03-23 05:12:53.0 
+0100
@@ -1948,28 +1948,30 @@
udf_release_data(obh);
return (elen >> 30);
 }
 
 int8_t inode_bmap(struct inode *inode, int block, kernel_lb_addr *bloc, 
uint32_t *extoffset,
kernel_lb_addr *eloc, uint32_t *elen, uint32_t *offset, struct 
buffer_head **bh)
 {
-   uint64_t lbcount = 0, bcount = (uint64_t)block << 
inode->i_sb->s_blocksize_bits;
+   uint64_t lbcount = 0, bcount;
int8_t etype;
 
if (block < 0)
{
printk(KERN_ERR "udf: inode_bmap: block < 0\n");
return -1;
}
if (!inode)
{
printk(KERN_ERR "udf: inode_bmap: NULL inode\n");
return -1;
}
 
+   bcount = (uint64_t)block << inode->i_sb->s_blocksize_bits;
+
*extoffset = 0;
*elen = 0;
*bloc = UDF_I_LOCATION(inode);
 
do
{
if ((etype = udf_next_aext(inode, bloc, extoffset, eloc, elen, 
bh, 1)) == -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/

[2.6 patch] drivers/net/pcmcia/nmclan_cs.c: fix a check after use

[Adrian Bunk]

This patch fixes a check after use found by the Coverity checker.

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

--- linux-2.6.12-rc1-mm1-full/drivers/net/pcmcia/nmclan_cs.c.old
2005-03-23 05:04:00.0 +0100
+++ linux-2.6.12-rc1-mm1-full/drivers/net/pcmcia/nmclan_cs.c2005-03-23 
05:04:30.0 +0100
@@ -1090,20 +1090,22 @@
  */
 static irqreturn_t mace_interrupt(int irq, void *dev_id, struct pt_regs *regs)
 {
   struct net_device *dev = (struct net_device *) dev_id;
   mace_private *lp = netdev_priv(dev);
-  kio_addr_t ioaddr = dev->base_addr;
+  kio_addr_t ioaddr;
   int status;
   int IntrCnt = MACE_MAX_IR_ITERATIONS;
 
   if (dev == NULL) {
 DEBUG(2, "mace_interrupt(): irq 0x%X for unknown device.\n",
  irq);
 return IRQ_NONE;
   }
 
+  ioaddr = dev->base_addr;
+
   if (lp->tx_irq_disabled) {
 printk(
   (lp->tx_irq_disabled?
KERN_NOTICE "%s: Interrupt with tx_irq_disabled "
"[isr=%02X, imr=%02X]\n": 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/sg.c: fix check after use

[Adrian Bunk]

This patch fixes a check after use found by the Coverity checker.

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

--- linux-2.6.12-rc1-mm1-full/drivers/scsi/sg.c.old 2005-03-23 
04:57:20.0 +0100
+++ linux-2.6.12-rc1-mm1-full/drivers/scsi/sg.c 2005-03-23 04:57:50.0 
+0100
@@ -1208,11 +1208,14 @@
 sg_mmap(struct file *filp, struct vm_area_struct *vma)
 {
Sg_fd *sfp;
-   unsigned long req_sz = vma->vm_end - vma->vm_start;
+   unsigned long req_sz;
Sg_scatter_hold *rsv_schp;
 
if ((!filp) || (!vma) || (!(sfp = (Sg_fd *) filp->private_data)))
return -ENXIO;
+
+   req_sz = vma->vm_end - vma->vm_start;
+
SCSI_LOG_TIMEOUT(3, printk("sg_mmap starting, vm_start=%p, len=%d\n",
   (void *) vma->vm_start, (int) req_sz));
if (vma->vm_pgoff)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/console/fbcon.c: fix a check after use

[Adrian Bunk]

This patch fixes a check after use found by the Coverity checker.

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

--- linux-2.6.12-rc1-mm1-full/drivers/video/console/fbcon.c.old 2005-03-23 
04:53:20.0 +0100
+++ linux-2.6.12-rc1-mm1-full/drivers/video/console/fbcon.c 2005-03-23 
04:53:44.0 +0100
@@ -906,10 +906,13 @@ static void fbcon_init(struct vc_data *v
struct vc_data *svc = *default_mode;
struct display *t, *p = _display[vc->vc_num];
int logo = 1, new_rows, new_cols, rows, cols, charcnt = 256;
-   int cap = info->flags;
+   int cap;
 
if (info_idx == -1 || info == NULL)
return;
+
+   cap = info->flags;
+
if (vc != svc || logo_shown == FBCON_LOGO_DONTSHOW ||
(info->fix.type == FB_TYPE_TEXT))
logo = 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/

[2.6 patch] fs/udf/udftime.c: fix off by one error

[Adrian Bunk]

This patch fixes an off by one error found by the Coverity checker.

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

--- linux-2.6.12-rc1-mm1-full/fs/udf/udftime.c.old  2005-03-23 
01:22:02.0 +0100
+++ linux-2.6.12-rc1-mm1-full/fs/udf/udftime.c  2005-03-23 01:22:13.0 
+0100
@@ -103,7 +103,7 @@ udf_stamp_to_time(time_t *dest, long *de
offset = 0;
 
if ((src.year < EPOCH_YEAR) ||
-   (src.year > EPOCH_YEAR+MAX_YEAR_SECONDS))
+   (src.year >= EPOCH_YEAR+MAX_YEAR_SECONDS))
{
*dest = -1;
*dest_usec = -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/

[2.6 patch] sound/oss/sonicvibes.c: fix an array overflow

[Adrian Bunk]

This patch fixes an array overflow found by the Coverity checker.

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

--- linux-2.6.12-rc1-mm1-full/sound/oss/sonicvibes.c.old2005-03-23 
01:53:13.0 +0100
+++ linux-2.6.12-rc1-mm1-full/sound/oss/sonicvibes.c2005-03-23 
01:55:11.0 +0100
@@ -1146,13 +1146,13 @@ static int mixer_ioctl(struct sv_state *
for (i = 0; i < SOUND_MIXER_NRDEVICES; i++) {
if (!(val & (1 << i)))
continue;
if (mixtable[i].rec)
break;
}
-   if (!mixtable[i].rec)
+   if (i == SOUND_MIXER_NRDEVICES)
return 0;
spin_lock_irqsave(>lock, flags);
frobindir(s, SV_CIMIX_ADCINL, 0x1f, mixtable[i].rec << 5);
frobindir(s, SV_CIMIX_ADCINR, 0x1f, mixtable[i].rec << 5);
spin_unlock_irqrestore(>lock, flags);
return 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/

[2.6 patch] drivers/input/joystick/spaceorb.c: fix an array overflow

[Adrian Bunk]

This patch fixes an array overflow found by the Coverity checker.

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

--- linux-2.6.12-rc1-mm1-full/drivers/input/joystick/spaceorb.c.old 
2005-03-23 02:12:33.0 +0100
+++ linux-2.6.12-rc1-mm1-full/drivers/input/joystick/spaceorb.c 2005-03-23 
02:16:18.0 +0100
@@ -116,7 +116,7 @@ static void spaceorb_process_packet(stru
 
case 'K':   /* Button data */
if (spaceorb->idx != 5) return;
-   for (i = 0; i < 7; i++)
+   for (i = 0; i < 6; i++)
input_report_key(dev, spaceorb_buttons[i], 
(data[2] >> i) & 1);
 
break;

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

[2.6 patch] fix NCR53C9x.c compile warning

[Adrian Bunk]

This patch fixes the following warning:

  CC [M]  drivers/scsi/NCR53C9x.o
drivers/scsi/NCR53C9x.c: In function `esp_do_data':
drivers/scsi/NCR53C9x.c:1838: warning: unused variable `flags'

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

---

This patch was already sent on:
- 12 Aug 2004
- 20 Dec 2003

--- linux-2.6.0-test11-mm1-modular-no-smp/drivers/scsi/NCR53C9x.c.old   
2003-12-19 23:26:15.0 +0100
+++ linux-2.6.0-test11-mm1-modular-no-smp/drivers/scsi/NCR53C9x.c   
2003-12-19 23:27:10.0 +0100
@@ -1835,7 +1835,10 @@
/* loop */
while (hmuch) {
int j, fifo_stuck = 0, newphase;
-   unsigned long flags, timeout;
+   unsigned long timeout;
+#if 0
+   unsigned long flags;
+#endif
 #if 0
if ( i % 10 )
ESPDATA(("\r"));



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/pnp/pnpacpi/rsparser.c: fix an array overflow

[Adrian Bunk]

This patch fixes an array overflow found by the Coverity checker.

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

--- linux-2.6.12-rc1-mm1-full/drivers/pnp/pnpacpi/rsparser.c.old
2005-03-23 02:58:31.0 +0100
+++ linux-2.6.12-rc1-mm1-full/drivers/pnp/pnpacpi/rsparser.c2005-03-23 
03:02:49.0 +0100
@@ -94,8 +94,8 @@
 pnpacpi_parse_allocated_dmaresource(struct pnp_resource_table * res, int dma)
 {
int i = 0;
-   while (!(res->dma_resource[i].flags & IORESOURCE_UNSET) &&
-   i < PNP_MAX_DMA)
+   while (i < PNP_MAX_DMA &&
+   !(res->dma_resource[i].flags & IORESOURCE_UNSET))
i++;
if (i < PNP_MAX_DMA) {
res->dma_resource[i].flags = IORESOURCE_DMA;  // Also clears 
_UNSET flag

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/radeonfb.c: fix an array overflow

[Adrian Bunk]

This patch fixes an array overflow found by the Coverity checker.

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

--- linux-2.6.12-rc1-mm1-full/drivers/video/radeonfb.c.old  2005-03-23 
01:50:14.0 +0100
+++ linux-2.6.12-rc1-mm1-full/drivers/video/radeonfb.c  2005-03-23 
01:50:30.0 +0100
@@ -2107,7 +2107,7 @@ static void radeon_write_mode (struct ra
 
 
if (rinfo->arch == RADEON_M6) {
-   for (i=0; i<8; i++)
+   for (i=0; i<7; i++)
OUTREG(common_regs_m6[i].reg, common_regs_m6[i].val);
} else {
for (i=0; i<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/pnp/pnpbios/rsparser.c: fix an array overflow

[Adrian Bunk]

This patch fixes an array overflow found by the Coverity checker.

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

--- linux-2.6.12-rc1-mm1-full/drivers/pnp/pnpbios/rsparser.c.old
2005-03-23 03:04:17.0 +0100
+++ linux-2.6.12-rc1-mm1-full/drivers/pnp/pnpbios/rsparser.c2005-03-23 
03:05:21.0 +0100
@@ -72,7 +72,9 @@
 pnpbios_parse_allocated_dmaresource(struct pnp_resource_table * res, int dma)
 {
int i = 0;
-   while (!(res->dma_resource[i].flags & IORESOURCE_UNSET) && i < 
PNP_MAX_DMA) i++;
+   while (i < PNP_MAX_DMA && 
+   !(res->dma_resource[i].flags & IORESOURCE_UNSET))
+   i++;
if (i < PNP_MAX_DMA) {
res->dma_resource[i].flags = IORESOURCE_DMA;  // Also clears 
_UNSET flag
if (dma == -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/

[2.6 patch] SCSI: cleanups

[Adrian Bunk]

This patch contains the following cleanups:
- make needlessly global code static
- remove the following unused functions:
  - scsi.h: print_driverbyte
  - scsi.h: print_hostbyte
- #if 0 the following unused functions:
  - constants.c: scsi_print_hostbyte
  - constants.c: scsi_print_driverbyte
- remove the following unneeded EXPORT_SYMBOL's:
  - hosts.c: scsi_host_lookup
  - scsi.c: scsi_device_cancel
  - scsi_lib.c: scsi_device_resume

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

---

 drivers/scsi/constants.c   |4 
 drivers/scsi/hosts.c   |3 +--
 drivers/scsi/scsi.c|7 ---
 drivers/scsi/scsi.h|8 
 drivers/scsi/scsi_debug.c  |2 +-
 drivers/scsi/scsi_lib.c|5 ++---
 drivers/scsi/scsi_priv.h   |4 
 drivers/scsi/scsi_sysfs.c  |5 ++---
 include/scsi/scsi_dbg.h|2 --
 include/scsi/scsi_device.h |1 -
 10 files changed, 14 insertions(+), 27 deletions(-)

--- linux-2.6.11-rc4-mm1-full/drivers/scsi/scsi.h.old   2005-02-28 
18:18:22.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/scsi.h   2005-03-01 
00:58:19.0 +0100
@@ -80,14 +80,6 @@
 {
return scsi_print_req_sense(devclass, req);
 }
-static inline void print_driverbyte(int scsiresult)
-{
-   return scsi_print_driverbyte(scsiresult);
-}
-static inline void print_hostbyte(int scsiresult)
-{
-   return scsi_print_hostbyte(scsiresult);
-}
 static inline void print_status(unsigned char status)
 {
return scsi_print_status(status);
--- linux-2.6.11-rc4-mm1-full/include/scsi/scsi_dbg.h.old   2005-02-28 
18:17:32.0 +0100
+++ linux-2.6.11-rc4-mm1-full/include/scsi/scsi_dbg.h   2005-03-01 
01:01:25.0 +0100
@@ -11,8 +11,6 @@
 extern void __scsi_print_sense(const char *name,
   const unsigned char *sense_buffer,
   int sense_len);
-extern void scsi_print_driverbyte(int);
-extern void scsi_print_hostbyte(int);
 extern void scsi_print_status(unsigned char);
 extern int scsi_print_msg(const unsigned char *);
 extern const char *scsi_sense_key_string(unsigned char);
--- linux-2.6.11-rc4-mm1-full/drivers/scsi/constants.c.old  2005-02-28 
18:17:46.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/constants.c  2005-03-01 
01:00:37.0 +0100
@@ -1393,6 +1393,8 @@
 }
 EXPORT_SYMBOL(scsi_print_command);
 
+#if 0
+
 #ifdef CONFIG_SCSI_CONSTANTS
 
 static const char * hostbyte_table[]={
@@ -1446,3 +1448,5 @@
printk("Driverbyte=0x%02x ", driver_byte(scsiresult));
 }
 #endif
+
+#endif  /*  0  */
--- linux-2.6.11-rc4-mm1-full/drivers/scsi/hosts.c.old  2005-02-28 
18:33:14.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/hosts.c  2005-03-01 
00:58:19.0 +0100
@@ -56,7 +56,7 @@
  * @shost: pointer to struct Scsi_Host
  * recovery:   recovery requested to run.
  **/
-void scsi_host_cancel(struct Scsi_Host *shost, int recovery)
+static void scsi_host_cancel(struct Scsi_Host *shost, int recovery)
 {
struct scsi_device *sdev;
 
@@ -362,7 +362,6 @@
 
return shost;
 }
-EXPORT_SYMBOL(scsi_host_lookup);
 
 /**
  * scsi_host_get - inc a Scsi_Host ref count
--- linux-2.6.11-rc4-mm1-full/drivers/scsi/scsi_priv.h.old  2005-02-28 
19:59:30.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/scsi_priv.h  2005-03-01 
00:58:19.0 +0100
@@ -66,8 +66,6 @@
 extern int scsi_dispatch_cmd(struct scsi_cmnd *cmd);
 extern int scsi_setup_command_freelist(struct Scsi_Host *shost);
 extern void scsi_destroy_command_freelist(struct Scsi_Host *shost);
-extern void scsi_done(struct scsi_cmnd *cmd);
-extern int scsi_retry_command(struct scsi_cmnd *cmd);
 extern int scsi_insert_special_req(struct scsi_request *sreq, int);
 extern void scsi_init_cmd_from_req(struct scsi_cmnd *cmd,
struct scsi_request *sreq);
@@ -141,7 +139,6 @@
 #endif /* CONFIG_SYSCTL */
 
 /* scsi_sysfs.c */
-extern void scsi_device_dev_release(struct device *);
 extern int scsi_sysfs_add_sdev(struct scsi_device *);
 extern int scsi_sysfs_add_host(struct Scsi_Host *);
 extern int scsi_sysfs_register(void);
@@ -150,7 +147,6 @@
 extern int scsi_sysfs_target_initialize(struct scsi_device *);
 extern struct scsi_transport_template blank_transport_template;
 
-extern struct class sdev_class;
 extern struct bus_type scsi_bus_type;
 
 /* 
--- linux-2.6.11-rc4-mm1-full/drivers/scsi/scsi.c.old   2005-02-28 
19:59:56.0 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/scsi/scsi.c   2005-03-01 
00:58:19.0 +0100
@@ -68,6 +68,8 @@
 #include "scsi_priv.h"
 #include "scsi_logging.h"
 
+static void scsi_done(struct scsi_cmnd *cmd);
+static int scsi_retry_command(struct scsi_cmnd *cmd);
 
 /*
  * Definitions and constants.
@@ -733,7 +735,7 @@
  *
  * This function is interrupt context safe.
  */
-void scsi_done(struct scsi_cmnd *cmd)
+static void scsi_done(struct scsi_cmnd *cmd)
 {
/*
 * We don't have to worry about this one timing out 

[-mm patch] always enable regparm on i386

[Adrian Bunk]

The patch below always enables regparm on i386 (with gcc >= 3.0).

With this patch, it should get a better testing coverage in -mm.

This patch should help to find bugs that show up with regparm enabled.


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

--- linux-2.6.10-mm2-full/arch/i386/Kconfig.old 2005-01-08 17:41:49.0 
+0100
+++ linux-2.6.10-mm2-full/arch/i386/Kconfig 2005-01-08 17:42:10.0 
+0100
@@ -877,9 +877,8 @@
default y
 
 config REGPARM
-   bool "Use register arguments (EXPERIMENTAL)"
-   depends on EXPERIMENTAL
-   default n
+   bool
+   default y
help
Compile the kernel with -mregparm=3. This uses an different ABI
and passes the first three arguments of a function call in registers.

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

Re: [Ext2-devel] Re: OOM problems on 2.6.12-rc1 with many fsx tests

[Badari Pulavarty]

Badari Pulavarty wrote:
Mingming Cao wrote:
On Sat, 2005-03-26 at 16:23 -0800, Mingming Cao wrote:
On Fri, 2005-03-25 at 14:11 -0800, Badari Pulavarty wrote:
On Fri, 2005-03-25 at 13:56, Andrew Morton wrote:
Mingming Cao <[EMAIL PROTECTED]> wrote:
I run into OOM problem again on 2.6.12-rc1. I run some(20) fsx 
tests on
2.6.12-rc1 kernel(and 2.6.11-mm4) on ext3 filesystem, after about 10
hours the system hit OOM, and OOM keep killing processes one by 
one. I
could reproduce this problem very constantly on a 2 way PIII 
700MHZ with
512MB RAM. Also the problem could be reproduced on running the 
same test
on reiser fs.

The fsx command is:
./fsx -c 10 -n -r 4096 -w 4096 /mnt/test/foo1 &

I was able to reproduce this on ext3.  Seven instances of the above 
leaked
10-15MB over 10 hours.  All of it permanently stuck on the LRU.

I'll continue to poke at it - see what kernel it started with, which
filesystems it affects, whether it happens on UP&&!PREEMPT, etc.  
Not a
quick process.

I reproduced *similar* issue with 2.6.11. The reason I say similar, is
there is no OOM kill, but very low free memory and machine doesn't
respond at all. (I booted my machine with 256M memory and ran 20 copies
of fsx on ext3).

Yes, I re-run the same test on 2.6.11 for 24 hours, like Badari see on
his machine, my machine did not go to OOM on 2.6.11,still alive, but
memory is very low(only 5M free). Killed all fsx and umount the ext3
filesystem did not bring back much memory. I will going to rerun the
tests without the mapped read/write to see what happen.


Run fsx tests without mapped IO on 2.6.11 seems fine.  Here is
the /proc/meminfo after 18 hours run:

Mingming, Reproduce it on 2.6.11 with mapped IO tests. That will tell
us when the regression started.
Sorry - Ignore my request, Mingming already did this work and posted
the result.
Thanks,
Badari
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ext2-devel] Re: OOM problems on 2.6.12-rc1 with many fsx tests

[Badari Pulavarty]

Mingming Cao wrote:
On Sat, 2005-03-26 at 16:23 -0800, Mingming Cao wrote:
On Fri, 2005-03-25 at 14:11 -0800, Badari Pulavarty wrote:
On Fri, 2005-03-25 at 13:56, Andrew Morton wrote:
Mingming Cao <[EMAIL PROTECTED]> wrote:
I run into OOM problem again on 2.6.12-rc1. I run some(20) fsx tests on
2.6.12-rc1 kernel(and 2.6.11-mm4) on ext3 filesystem, after about 10
hours the system hit OOM, and OOM keep killing processes one by one. I
could reproduce this problem very constantly on a 2 way PIII 700MHZ with
512MB RAM. Also the problem could be reproduced on running the same test
on reiser fs.
The fsx command is:
./fsx -c 10 -n -r 4096 -w 4096 /mnt/test/foo1 &
I was able to reproduce this on ext3.  Seven instances of the above leaked
10-15MB over 10 hours.  All of it permanently stuck on the LRU.
I'll continue to poke at it - see what kernel it started with, which
filesystems it affects, whether it happens on UP&&!PREEMPT, etc.  Not a
quick process.
I reproduced *similar* issue with 2.6.11. The reason I say similar, is
there is no OOM kill, but very low free memory and machine doesn't
respond at all. (I booted my machine with 256M memory and ran 20 copies
of fsx on ext3).

Yes, I re-run the same test on 2.6.11 for 24 hours, like Badari see on
his machine, my machine did not go to OOM on 2.6.11,still alive, but
memory is very low(only 5M free). Killed all fsx and umount the ext3
filesystem did not bring back much memory. I will going to rerun the
tests without the mapped read/write to see what happen.


Run fsx tests without mapped IO on 2.6.11 seems fine.  Here is
the /proc/meminfo after 18 hours run:
Mingming, Reproduce it on 2.6.11 with mapped IO tests. That will tell
us when the regression started.
Thanks,
Badari
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] typo fix in Documentation/eisa.txt

[Jean Delvare]

> > >  Force the probing code to probe EISA slots even when it cannot find an
> > > -EISA compliant mainboard (nothing appears on slot 0). Defaultd to 0
> > > +EISA compliant mainboard (nothing appears on slot 0). Default to 0
> > >  (don't force), and set to 1 (force probing) when either
> > >  CONFIG_ALPHA_JENSEN or CONFIG_EISA_VLB_PRIMING are set.
> >
> > Wouldn't it rather be "Defaults"?
> 
> Damn, yes. Every time I read it again I feel a little bit more
> comfortable with s/are set/is set/. Am I right or is it already too
> late for useful work?

"is" is better, even if both are commonly used in this case. And no,
it's not to late.

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

Re: Linux 2.6.11.6

[Chris Wright]

* Ryan Anderson ([EMAIL PROTECTED]) wrote:
> On Sat, Mar 26, 2005 at 01:27:53AM -0800, Chris Wright wrote:
> > > Could you please add CAN IDs to the stable changelog for already assigned
> > > vulnerabilities?
> > 
> > That's what I did for .5 -> .6.  We can't retroactively update changeset
> > comments, and I'm not sure we have any other candidates in -stable.
> > We'll certainly continue to add them as we have them.
> 
> bk helptool comments

Yeah, I've actually used that, but as Dave mentioned, it's only really
useful while you have the changes locally and haven't pushed them out yet.

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: [PATCH] typo fix in Documentation/eisa.txt

[Rolf Eike Beer]

Typo fixes.

Thanks to Randy Dunlap and Jean Delvare.

Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>

--- linux-2.6.11/Documentation/eisa.txt 2005-03-02 08:38:12.0 +0100
+++ linux-2.6.12-rc1/Documentation/eisa.txt 2005-03-27 21:58:04.0 
+0200
@@ -171,9 +171,9 @@
 virtual_root.force_probe :
 
 Force the probing code to probe EISA slots even when it cannot find an
-EISA compliant mainboard (nothing appears on slot 0). Defaultd to 0
-(don't force), and set to 1 (force probing) when either
-CONFIG_ALPHA_JENSEN or CONFIG_EISA_VLB_PRIMING are set.
+EISA compliant mainboard (nothing appears on slot 0). Defaults to 0
+(don't force) and set to 1 (force probing) when either
+CONFIG_ALPHA_JENSEN or CONFIG_EISA_VLB_PRIMING is set.
 
 ** Random notes :
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-bk10 non-fatal oops mkdir'ing loop-mounted UDF image

[Alessandro Suardi]

Machine is a K7-800 with 256MB, 2x160GB hard disks, a
 Samsung TL-552 burner running FC3 plus 2.6.11-bk10
 from kernel.org.

While trying to understand why mkisofs -dvd-video creates
 an image with a VOB file that has a different MD5 sum than
 the original (reproducible), I wanted to give it another try
 and create the image from a directory that not only had
 VIDEO_TS but also AUDIO_TS.

Unfortunately I confused the ext3 and loop gnome-terminal
 windows, and attempted mkdir on the loop-mounted image.

Results: mkdir command printed "Segmentation fault" while
 the bash shell survived. I can't now umount the loop-mounted
 file and an oops was logged. From dmesg (and note the first
 message, coming from a previous successful audio burning
 session with cdrecord <...> -eject)

[1003810.249656] scsi: unknown opcode 0x01
[1098164.712708] UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume
'CDROM', timestamp 2005/03/27 17:10 (103c)
[1098895.563940] UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume
'CDROM', timestamp 2005/03/27 17:10 (103c)
[1099506.099370] UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume
'CDROM', timestamp 2005/03/27 18:46 (103c)
[1104119.924833] UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume
'CDROM', timestamp 2005/03/27 20:03 (103c)
[1105984.457690] Unable to handle kernel paging request at virtual
address 00d600fe
[1105984.458592]  printing eip:
[1105984.458946] c02034e9
[1105984.459545] *pde = 
[1105984.459911] Oops:  [#1]
[1105984.460268] PREEMPT
[1105984.460597] Modules linked in: loop parport_pc parport 8139too floppy
[1105984.461257] CPU:0
[1105984.461260] EIP:0060:[]Not tainted VLI
[1105984.461264] EFLAGS: 00210297   (2.6.11-bk10)
[1105984.462565] EIP is at udf_get_filelongad+0x29/0x60
[1105984.463050] eax: 00d601ae   ebx: 00d600fe   ecx: c8057e18   edx: 00d601be
[1105984.463656] esi: 00d701af   edi: 00d701af   ebp: c8057d74   esp: c8057d68
[1105984.464259] ds: 007b   es: 007b   ss: 0068
[1105984.464698] Process mkdir (pid: 18065, threadinfo=c8056000 task=ccbac510)
[1105984.465132] Stack: ca766b10 c6fc8348 00d600fe c8057dac c01fb500
0001  
[1105984.466116]00d600fe c8057e18  0002 
00b8 c8057e10 c6fc8380
[1105984.467097]c8057e28 c8057dd4 c01fb367 c8057e1c c8057e24
c8057e28 0001 c8057e18
[1105984.468080] Call Trace:
[1105984.468592]  [] show_stack+0x7a/0x90
[1105984.469079]  [] show_registers+0x14d/0x1c0
[1105984.469594]  [] die+0xe4/0x170
[1105984.470044]  [] do_page_fault+0x456/0x673
[1105984.470560]  [] error_code+0x2b/0x30
[1105984.471043]  [] udf_current_aext+0x130/0x1d0
[1105984.471569]  [] udf_next_aext+0x37/0xa0
[1105984.472067]  [] udf_discard_prealloc+0xaa/0x290
[1105984.472610]  [] udf_clear_inode+0x36/0x50
[1105984.473120]  [] clear_inode+0xf4/0x100
[1105984.473615]  [] generic_forget_inode+0x11e/0x160
[1105984.474162]  [] iput+0x56/0x80
[1105984.474612]  [] udf_new_inode+0x364/0x379
[1105984.475122]  [] udf_mkdir+0x39/0x210
[1105984.475605]  [] vfs_mkdir+0x71/0xa0
[1105984.476085]  [] sys_mkdir+0x89/0xd0
[1105984.476562]  [] sysenter_past_esp+0x54/0x75
[1105984.477081] Code: 00 00 55 89 e5 56 89 d6 53 89 c3 83 ec 04 85 c0
0f 94 c2 85 c9 0f 94 c0 09 d0 a8 01 75 27 8b 01 85 c0 78 2e 8d 50 10
39 f2 77 27 <8b> 33 31 c0 85 f6 74 21 8b 45 08 85 c0 74 02 89 11 83 c4
04 89
[1105984.565877]


Thanks,
 
--alessandro

 "I want to know if it's you I don't trust
  'cause I damn sure don't trust myself"

(Bruce Springsteen, "Brilliant Disguise")
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] typo fix in Documentation/eisa.txt

[Randy.Dunlap]

Rolf Eike Beer wrote:
Jean Delvare wrote:
Hi Eike,

Trivial typo fix.
(...)
Force the probing code to probe EISA slots even when it cannot find an
-EISA compliant mainboard (nothing appears on slot 0). Defaultd to 0
+EISA compliant mainboard (nothing appears on slot 0). Default to 0
(don't force), and set to 1 (force probing) when either
CONFIG_ALPHA_JENSEN or CONFIG_EISA_VLB_PRIMING are set.
Wouldn't it rather be "Defaults"?

Damn, yes. Every time I read it again I feel a little bit more comfortable 
with s/are set/is set/. Am I right or is it already too late for useful 
work?
Defaults
when either FOO or BAR is set.
and the comma after (don't force) shouldn't be there...
--
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] typo fix in Documentation/eisa.txt

[Rolf Eike Beer]

Jean Delvare wrote:
> Hi Eike,
>
> > Trivial typo fix.
> > (...)
> >  Force the probing code to probe EISA slots even when it cannot find an
> > -EISA compliant mainboard (nothing appears on slot 0). Defaultd to 0
> > +EISA compliant mainboard (nothing appears on slot 0). Default to 0
> >  (don't force), and set to 1 (force probing) when either
> >  CONFIG_ALPHA_JENSEN or CONFIG_EISA_VLB_PRIMING are set.
>
> Wouldn't it rather be "Defaults"?

Damn, yes. Every time I read it again I feel a little bit more comfortable 
with s/are set/is set/. Am I right or is it already too late for useful 
work?

Eike


pgpGBSFYaK8Tn.pgp
Description: PGP signature

Re: Can't use SYSFS for "Proprietry" driver modules !!!.

[Adrian Bunk]

On Sun, Mar 27, 2005 at 11:16:54AM -0800, Aaron Gyes wrote:
> > And then the user want to upgrade the 2.0 kernel that shipped with this 
> > box although the company that made the hardware went bankrupt some years 
> > ago.
> > 
> > If the user has the source of the driver, he can port the driver or hire 
> > someone to port the driver (this "obscure piece of hardware" might also 
> > be an expensive piece of hardware).
> 
> So what? Sure, GPL'd drivers are easier for an end-user in that case.
> What does that have to do with law? What about what's better for the

I wasn't talking about legal issues.

I was answering Dave's "very specialist piece of equipment" opinion.

And my point was that even in this case it's better for the user to have 
the source.

> company that made the device? Should NVIDIA be forced to give up their
> secrets to all their competitors because some over zealous developers
> say so? Should the end-users of the current drivers be forced to lose
> out on features such as sysfs and udev compatability?
> 
> I love Linux, and a I love that free software has become mildly
> successful, but the zealots are hurting both.

There are many bug reports to linux-kernel that are undebuggable because 
they involve the nvidia binary-only module.

I do personally know several people who use the nvidia binary-only 
modules and have as a result experienced stability problems on their 
computer. Linux has an IMHO justified reputation for being stable.
Users experiencing system stability problems due to binary-only modules 
might wrongfully attribute them to Linux harming the reputation of 
Linux.

cu
Adrian

-- 

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

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

Re: [PATCH] typo fix in Documentation/eisa.txt

[Jean Delvare]

Hi Eike,

> Trivial typo fix.
> (...)
>  Force the probing code to probe EISA slots even when it cannot find an
> -EISA compliant mainboard (nothing appears on slot 0). Defaultd to 0
> +EISA compliant mainboard (nothing appears on slot 0). Default to 0
>  (don't force), and set to 1 (force probing) when either
>  CONFIG_ALPHA_JENSEN or CONFIG_EISA_VLB_PRIMING are set.

Wouldn't it rather be "Defaults"?

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

Re: Can't use SYSFS for "Proprietry" driver modules !!!.

[Kyle Moffett]

On Mar 27, 2005, at 14:16, Aaron Gyes wrote:
So what? Sure, GPL'd drivers are easier for an end-user in that case.
What does that have to do with law?
Well, under most interpretations of the GPL, you are *NOT* allowed to
even _link_ non-GPL code with GPL code. (Basically, by distributing such
a linked binary, you are certifying that you have permission to GPL the
entire source-code and are doing so.

What about what's better for the company that made the device?
Who says that free maintenance and bugfixes *isn't* better for said
company?

Should NVIDIA be forced to give up their secrets to all their
competitors because some over zealous developers say so?
We don't care about their secrets, we just want to be able to interface
with their hardware.  Really, we don't care how the hardware does what
it does internally, we just care how to tell it to do that.  It's the
difference between telling an artist to paint a big picture and
watching every thought he makes while he does the painting with a brain
scanner.

Should the end-users of the current drivers be forced to lose out
on features such as sysfs and udev compatability?
Should the end-users even *have* features such as sysfs and udev?  If
the *open-source* developers hadn't *opened* their *source*, then that
code wouldn't exist.  One condition they made when they gave that code
for free was that *only* people who also gave their code for free
could use it.

I love Linux, and a I love that free software has become mildly
successful, but the zealots are hurting both.
On the contrary, the zealots are what protect us from the even worse
proprietary software zealots.  You may not agree with them, but if
there were only one kind of zealot then the world would be much
worse off.
Cheers,
Kyle Moffett
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$
L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r  
!y?(-)
--END GEEK CODE BLOCK--

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

[RFC] Some thoughts on device drivers and sysfs

[Adam Belay]

One of the original design goals of sysfs was to provide a standardized
location to keep driver configuration attributes.  Although sysfs
handles this very well for bus devices and class devices, there isn't
currently a method to export attributes for device drivers and their
specific bound device instances to userspace.

I would like to propose that we create a new type of device that would
act as the layer between physical (bus devices) and logical (class
devices).  It could be referred to as a "driver device".  Driver devices
would bind to a bus devices and create one or more class devices.  Their
type would be of "struct device_driver".  As an example, this would
allow us to move something like /proc/driver/emu10k1/:01:09.0 into
sysfs.

(physical)   |(logical)

|bus device --> driver device --> class device |


struct driver_device {
struct list_head node;
unsigned long id;
struct kobject kobj;
struct device_driver *drv;
struct device *dev;
int state;
};

In sysfs, a new directory could be created to represent driver devices.
It might look like the following:

bus
|
\- pci
 |
 \- devices
  |
  \- link to device0
  \- link to device1
 \- drivers
  |
  \- link to random_drv (in other words random_drv can drive this bus)

device
|
\- device0
[...]
\- device1
[...]

driver (this directory is new)
|
\- random_drv
 |
 \- 0 (a sequential instance number) <-- this is a driver device
  |
  \- link to device0
  \- link to class0
  \- a file to control driver state (start, stop, etc.)
  \- driver attributes for this link
 \- 1
  |
  \- link to device1
  \- link to class1
  \- a file to control driver state
  \- driver attributes for this link

class
|
\-some_type
 |
 \- class0
[...]
 \- class1
[...]

This would allow us to represent per-device driver attributes in sysfs.
As an added benefit, driver devices would allow the tracking and control
of driver state, which may be needed for dynamic power management.  I
look forward to any comments.

Thanks,
Adam


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

Re: [Ext2-devel] Re: OOM problems on 2.6.12-rc1 with many fsx tests

[Mingming Cao]

On Sat, 2005-03-26 at 16:23 -0800, Mingming Cao wrote:
> On Fri, 2005-03-25 at 14:11 -0800, Badari Pulavarty wrote:
> > On Fri, 2005-03-25 at 13:56, Andrew Morton wrote:
> > > Mingming Cao <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I run into OOM problem again on 2.6.12-rc1. I run some(20) fsx tests on
> > > > 2.6.12-rc1 kernel(and 2.6.11-mm4) on ext3 filesystem, after about 10
> > > > hours the system hit OOM, and OOM keep killing processes one by one. I
> > > > could reproduce this problem very constantly on a 2 way PIII 700MHZ with
> > > > 512MB RAM. Also the problem could be reproduced on running the same test
> > > > on reiser fs.
> > > > 
> > > > The fsx command is:
> > > > 
> > > > ./fsx -c 10 -n -r 4096 -w 4096 /mnt/test/foo1 &
> > > 
> > > I was able to reproduce this on ext3.  Seven instances of the above leaked
> > > 10-15MB over 10 hours.  All of it permanently stuck on the LRU.
> > > 
> > > I'll continue to poke at it - see what kernel it started with, which
> > > filesystems it affects, whether it happens on UP&&!PREEMPT, etc.  Not a
> > > quick process.
> > 
> > I reproduced *similar* issue with 2.6.11. The reason I say similar, is
> > there is no OOM kill, but very low free memory and machine doesn't
> > respond at all. (I booted my machine with 256M memory and ran 20 copies
> > of fsx on ext3).
> > 
> > 
> 
> Yes, I re-run the same test on 2.6.11 for 24 hours, like Badari see on
> his machine, my machine did not go to OOM on 2.6.11,still alive, but
> memory is very low(only 5M free). Killed all fsx and umount the ext3
> filesystem did not bring back much memory. I will going to rerun the
> tests without the mapped read/write to see what happen.
> 
> 

Run fsx tests without mapped IO on 2.6.11 seems fine.  Here is
the /proc/meminfo after 18 hours run:

# cat /proc/meminfo
MemTotal:   510464 kB
MemFree:  6004 kB
Buffers:179420 kB
Cached:   9144 kB
SwapCached:  0 kB
Active: 313236 kB
Inactive:   171380 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:   510464 kB
LowFree:  6004 kB
SwapTotal: 1052216 kB
SwapFree:  1052216 kB
Dirty:2100 kB
Writeback:   0 kB
Mapped:  24884 kB
Slab:14788 kB
CommitLimit:   1307448 kB
Committed_AS:78032 kB
PageTables:720 kB
VmallocTotal:   516024 kB
VmallocUsed:  1672 kB
VmallocChunk:   514352 kB

elm3b92:~ # killall -9 fsx
elm3b92:~ # cat /proc/meminfo
MemTotal:   510464 kB
MemFree: 21332 kB
Buffers:179668 kB
Cached:   8828 kB
SwapCached:  0 kB
Active: 298748 kB
Inactive:   171152 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:   510464 kB
LowFree: 21332 kB
SwapTotal: 1052216 kB
SwapFree:  1052216 kB
Dirty:1140 kB
Writeback:   0 kB
Mapped:  11648 kB
Slab:14632 kB
CommitLimit:   1307448 kB
Committed_AS:59800 kB
PageTables:492 kB
VmallocTotal:   516024 kB
VmallocUsed:  1672 kB
VmallocChunk:   514352 kB

elm3b92:~ # umount /mnt/ext3
elm3b92:~ # cat /proc/meminfo
MemTotal:   510464 kB
MemFree:181636 kB
Buffers: 22092 kB
Cached:   6740 kB
SwapCached:  0 kB
Active: 151284 kB
Inactive:   158948 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:   510464 kB
LowFree:181636 kB
SwapTotal: 1052216 kB
SwapFree:  1052216 kB
Dirty:   0 kB
Writeback:   0 kB
Mapped:  11656 kB
Slab:14052 kB
CommitLimit:   1307448 kB
Committed_AS:59800 kB
PageTables:492 kB
VmallocTotal:   516024 kB
VmallocUsed:  1672 kB
VmallocChunk:   514352 kB


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] no need to check for NULL before calling kfree() -fs/ext2/

[Pekka Enberg]

On Sun, 27 Mar 2005 12:40:26 -0500, Dave Jones <[EMAIL PROTECTED]> wrote:
> Am I the only person who is completely fascinated by the
> effort being spent here micro-optimising something thats
> almost never in a path that needs optimising ?
> I'd be amazed if any of this masturbation showed the tiniest
> blip on a real workload, or even on a benchmark other than
> one crafted specifically to test kfree in a loop.

Indeed. The NULL checks are redundant and thus need to go. If someone
can show a measurable performance regression in the kernel for a
realistic workload, kfree() can be turned into an inline function
which will take care of it. The microbenchmarks are fun but should not
stand in the way of merging the kfree() cleanups from Jesper and
others.

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

[OOPS] 2.6.11 - NMI lockup with CFQ scheduler

[Chris Rankin]

[gcc-3.4.3, Linux-2.6.11-SMP, Dual P4 Xeon with HT enabled]

Hi,

My Linux 2.6.11 box oopsed when I tried to logout. I have switched to using the 
anticipatory
scheduler instead.

Cheers,
Chris

NMI Watchdog detected LOCKUP on CPU1, eip c0275cc7, registers:
Modules linked in: snd_pcm_oss snd_mixer_oss snd_usb_audio snd_usb_lib 
snd_intel8x0 snd_seq_oss
snd_seq_midi snd_emu10k1_synth snd_emu10k1 snd_ac97_codec snd_pcm 
snd_page_alloc snd_emux_synth
snd_seq_virmidi snd_rawmidi snd_seq_midi_event snd_seq_midi_emul snd_hwdep 
snd_util_mem snd_seq
snd_seq_device snd_rtctimer snd_timer snd nls_iso8859_1 nls_cp437 vfat fat 
usb_storage radeon drm
i2c_algo_bit emu10k1_gp gameport deflate zlib_deflate zlib_inflate twofish 
serpent aes_i586
blowfish des sha256 crypto_null af_key binfmt_misc eeprom i2c_sensor button 
processor psmouse
pcspkr p4_clockmod speedstep_lib usbserial lp nfsd exportfs md5 ipv6 sd_mod 
scsi_mod autofs nfs
lockd sunrpc af_packet ohci_hcd parport_pc parport e1000 video1394 raw1394 
i2c_i801 i2c_core
ohci1394 ieee1394 ehci_hcd soundcore pwc videodev uhci_hcd usbcore intel_agp 
agpgart ide_cd cdrom
ext3 jbd
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00200086   (2.6.11) 
EIP is at _spin_lock+0x7/0xf
eax: f7b8b01c   ebx: f7c82b88   ecx: f7c82b94   edx: f6c33714
esi: eb68ad88   edi: f6c33708   ebp: f6c33714   esp: f5b32f70
ds: 007b   es: 007b   ss: 0068
Process nautilus (pid: 5757, threadinfo=f5b32000 task=f7518020)
Stack: c01f7f79 00200282 f76bda24 f6c323e4 f7518020   c01f1d0c 
   f5b32000 c011d7b3 0001  b65ffa40  f5b32fac  
     f5b32000 c011d8d6 c0102e7f  b65ffbf0 b6640bf0 
Call Trace:
 [] cfq_exit_io_context+0x54/0xb3
 [] exit_io_context+0x45/0x51
 [] do_exit+0x205/0x308
 [] next_thread+0x0/0xc
 [] syscall_call+0x7/0xb
Code: 05 e8 3a e6 ff ff c3 ba 00 f0 ff ff 21 e2 81 42 14 00 01 00 00 f0 81 28 
00 00 00 01 74 05 e8
1d e6 ff ff c3 f0 fe 08 79 09 f3 90 <80> 38 00 7e f9 eb f2 c3 f0 81 28 00 00 00 
01 74 05 e8 ff e5
ff 
console shuts up ...


Send instant messages to your online friends http://uk.messenger.yahoo.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/

[PATCH] typo fix in drivers/scsi/sata_svw.c

[Rolf Eike Beer]

Add missing brace.

Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>

--- linux-2.6.11/drivers/scsi/sata_svw.c2005-03-21 11:41:58.0 
+0100
+++ linux-2.6.12-rc1/drivers/scsi/sata_svw.c2005-03-27 15:50:38.0 
+0200
@@ -395,7 +395,7 @@
 
/* Clear a magic bit in SCR1 according to Darwin, those help
 * some funky seagate drives (though so far, those were already
-* set by the firmware on the machines I had access to
+* set by the firmware on the machines I had access to)
 */
writel(readl(mmio_base + K2_SATA_SICR1_OFFSET) & ~0x0004,
   mmio_base + K2_SATA_SICR1_OFFSET);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Can't use SYSFS for "Proprietry" driver modules !!!.

[Aaron Gyes]

> And then the user want to upgrade the 2.0 kernel that shipped with this 
> box although the company that made the hardware went bankrupt some years 
> ago.
> 
> If the user has the source of the driver, he can port the driver or hire 
> someone to port the driver (this "obscure piece of hardware" might also 
> be an expensive piece of hardware).

So what? Sure, GPL'd drivers are easier for an end-user in that case.
What does that have to do with law? What about what's better for the
company that made the device? Should NVIDIA be forced to give up their
secrets to all their competitors because some over zealous developers
say so? Should the end-users of the current drivers be forced to lose
out on features such as sysfs and udev compatability?

I love Linux, and a I love that free software has become mildly
successful, but the zealots are hurting both.

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