Re: 2.6.18.5 usb/sysfs bug.

[Chuck Ebbert]

In-Reply-To: <[EMAIL PROTECTED]>

On Sat, 16 Dec 2006 09:18:28 -0500, Dave Jones wrote:

>  > That's strange.  Remove_files called sysfs_hash_and_remove()
>  > with dir==0xfff3 (-13 decimal.)
> 
> Hmm, That's -EACCESS.  Something not checking a return code at a lower
> level maybe ?

In fs/sysfs/group.c:

void sysfs_remove_group(struct kobject * kobj,
const struct attribute_group * grp)
{
struct dentry * dir;

if (grp->name)
dir = lookup_one_len(grp->name, kobj->dentry,
strlen(grp->name));
else
dir = dget(kobj->dentry);

remove_files(dir,grp);
if (grp->name)
sysfs_remove_subdir(dir);
/* release the ref. taken in this routine */
dput(dir);
}

'dir' is being used without checking whether lookup_one_len()
succeeded.

> It's odd that something disconnects during boot, as nothing gets plugged.

Sometimes notebooks have USB devices built-in and they get treated
as if they were hotplugged.

-- 
MBTI: IXTP

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: IO-APIC + timer doesn't work

[Eric W. Biederman]

Linus Torvalds <[EMAIL PROTECTED]> writes:

> On Sun, 17 Dec 2006, Tobias Diedrich wrote:
>> 
>> No such luck, it still panics and the APIC error is also unchanged.
>
> Ok. I don't see anything wrong off-hand, but I'll keep the patch in the 
> tree in the hopes that Andi and/or Eric can see what's wrong and solve it.
>
> If we don't find a solution, I'll have to revert it, but let's give it a 
> few more days. 
>
> Tobias, can you please make sure to remind me about this if nothing seems 
> to happen? 

Actually can anyone tell me how try_apic_pin is supposed to work at
all?

It doesn't appear to be programming the io_apic.

So either I am missing something or I have found a real problem.

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

Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer

[Komuro]

On Sun, 17 Dec 2006 04:02:22 +
Al Viro <[EMAIL PROTECTED]> wrote:

> On Sun, Dec 17, 2006 at 09:27:52PM +0900, Komuro wrote:
> > 
> > Hello,
> > 
> > On kernel 2.6.20-rc1, ftp (get or put) stops
> > during file-transfer.
> > 
> > Client: ftp-0.17-33.fc6  (192.168.1.1)
> > Server: vsftpd-2.0.5-8   (192.168.1.3)
> > 
> > This problem does _not_ happen on kernel-2.6.19.
> > is it caused by network-subsystem change on 2.6.20-rc1??
> 
> Do you have NAT between you and server?

No. I don't have NAT between the client and the server.
Actually, the client and the sever is located in same room.


client -- 100MbpsHub -- server.

Thanks!

Best Regards
Komuro




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: IO-APIC + timer doesn't work

[Eric W. Biederman]

Linus Torvalds <[EMAIL PROTECTED]> writes:

> On Sun, 17 Dec 2006, Tobias Diedrich wrote:
>> 
>> No such luck, it still panics and the APIC error is also unchanged.
>
> Ok. I don't see anything wrong off-hand, but I'll keep the patch in the 
> tree in the hopes that Andi and/or Eric can see what's wrong and solve it.
>
> If we don't find a solution, I'll have to revert it, but let's give it a 
> few more days. 
>
> Tobias, can you please make sure to remind me about this if nothing seems 
> to happen? 

Just skimming for differences the first test seems to be missing an
umask_IO_APIC_irq(0);

It would be good to know which case is working before this change was made.

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

Re: [RFC 2.6.19 1/1] fbdev,mm: hecuba/E-Ink fbdev driver v2

[Jaya Kumar]

On 12/13/06, Franck Bui-Huu <[EMAIL PROTECTED]> wrote:

On 12/12/06, Jaya Kumar <[EMAIL PROTECTED]> wrote:
> I think that PTEs set up by vmalloc are marked cacheable and via the
> above nopage end up as cacheable. I'm not doing DMA. So the accesses
> are through the cache so I don't think cache aliasing is an issue for
> this case. Please let me know if I misunderstood.
>

This issue is not related to DMA: there are 2 different virtual
addresses that can map the same physical address. If these 2 virtual
addresses use 2 different data cache entries then you have a cache
aliasing issue. In your case the 2 different virtual addresses are (1)


Ok. I now see what you mean. In typical cases, only one path is used
to write. Meaning an app will decide to use the mmap path or the slow
write path and the kernel only ever reads from its pte entry (unless
fbcon is used which is not suited for this type of display). But you
are right that it is possible for a situation to arise where one app
does mmap and another is doing write. My hope is that something takes
care of flushing the data cache for me in this case. Do you recommend
I add something to force that? I'm worried about having an fbdev
driver that is too involved with mm.

Thanks,
jayakumar



the one got by the kernel (returned by vmalloc) (2) the one got by the
application (returned by mmap).

Hope that helps.
--
   Franck


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Theodore Tso]

On Sun, Dec 17, 2006 at 01:22:12AM +0100, Ricardo Galli wrote:
> OK, let assume your perspective of the history is the valid and real one, 
> then, ¿where are all lawsits against other big GPL only projects? For example 
> libqt/kdelibs. You can hardly provide any example where the GPL wasn't hold 
> in court.

There's no need for lawsuits against things like libqt.  The question
is whether someone who writes a commercial program that happens to
dynamically link against libqt is in fact in violation of copyright
claims.  In such a case, the owners of libqt would have to sue the
commercial application writer, not the other way around.  There
haven't been any such cases, mostly because (a) the FUD generated by
the FSF about GPL vs. LGPL has generally been enough to cause
application authors to avoid using GPL'ed code even if it would be
legally defensible in court, and (b) I personally suspect that the FSF
has deliberately not tried to make a test case out of a commercial
application dynamically linking against a GPL'ed library.

In point of fact, if you compile libss from e2fsprogs on a Solaris
machine, and then let the Sun Enterprise Authentication Mechanism (a
propietary version of Kerberos v5) link against that version of libss
(as opposed to the one derived from the MIT Kerberos version of
libss), you can have a propietary Sun binary linking against libss
which will called will dynamically pull in the GPL'ed version of
readline (or the BSD licensed editline library, whichever one it finds
first in its search path).  Quick!  Is there a GPL violation involved,
and if so, who should the FSF try to sue first?

There are indeed plenty of cases where the GPL has been upheld in a
court of law, but usually it's some straightforward case of an
embedded version of Linux being used without releasing source.  As far
as I know, there has been no case on point about GPL and dynamic
linking, and I personally suspect it's at least partially because the
FSF is afraid it would lose such a case.  (As I've said, at least one
law professor of mine from the MIT Sloan School of Management has told
me that in her opinion the FSF's theory would be "laughed out of
court").

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

Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer

[Al Viro]

On Sun, Dec 17, 2006 at 09:27:52PM +0900, Komuro wrote:
> 
> Hello,
> 
> On kernel 2.6.20-rc1, ftp (get or put) stops
> during file-transfer.
> 
> Client: ftp-0.17-33.fc6  (192.168.1.1)
> Server: vsftpd-2.0.5-8   (192.168.1.3)
> 
> This problem does _not_ happen on kernel-2.6.19.
> is it caused by network-subsystem change on 2.6.20-rc1??

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

[BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer

[Komuro]

Hello,

On kernel 2.6.20-rc1, ftp (get or put) stops
during file-transfer.

Client: ftp-0.17-33.fc6  (192.168.1.1)
Server: vsftpd-2.0.5-8   (192.168.1.3)

This problem does _not_ happen on kernel-2.6.19.
is it caused by network-subsystem change on 2.6.20-rc1??


Best Regards
Komuro

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Adrian Bunk]

On Sun, Dec 17, 2006 at 02:56:09AM +0100, Adrian Bunk wrote:
>...
> Otherwise, it seems to be highly unlikely that anyone will want to sue a 
> company that is often located in a different country, and the only 
> possible legal action will be cease and desist letters against people 
> who are infriding the copyright by e.g. selling Linux distributions 
> containing fglrx at Ebay or operating Debian ftp mirrors. That sounds 
> highly unfair, but unfortunately it also seems to be the only effective 
> way for someone without a big wallet to effectively act against such 
> licence violations...

To avoid any misunderstandings:

I do not want to threaten anyone, and I do not plan to do such legal 
actions myself.

My point is simply that whoever considers this grey area a good thing 
and wants to leave clarifications to the lawyers should be aware that 
e.g. in the fglrx and nvidia cases it's quite possible that the target 
of legal actions might not be AMD but e.g. the Technical University of 
Dresden that is distributing the offending code in Germany [1].

cu
Adrian

[1] by operating ftp.de.debian.org

-- 

   "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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Adrian Bunk]

On Sat, Dec 16, 2006 at 01:33:01PM -0500, Dave Jones wrote:
> On Sat, Dec 16, 2006 at 09:20:15AM -0800, Linus Torvalds wrote:
> 
>  > Anything else, you have to make some really scary decisions. Can a judge 
>  > decide that a binary module is a derived work even though you didn't 
>  > actually use any code? The real answer is: HELL YES. It's _entirely_ 
>  > possible that a judge would find NVidia and ATI in violation of the GPLv2 
>  > with their modules.
> 
> ATI in particular, I'm amazed their lawyers OK'd stuff like..
> 
> +ifdef STANDALONE
>  MODULE_LICENSE(GPL);
> +endif
> 
> This a paraphrased diff, it's been a while since I've seen it.
> It's GPL if you build their bundled copy of the AGPGART code as agpgart.ko,
> but the usual use case is that it's built-in to fglrx.ko, which sounds
> incredibly dubious.
>...

Current versions contain
  MODULE_LICENSE("GPL and additional rights");
...

> The thing that really ticks me off though is the free support ATI seem
> to think they're entitled to.  I've had end-users emailing me
> "I asked ATI about this crash I've been seeing with fglrx, and they
>  asked me to mail you".
> 
> I invest my time into improving free drivers.  When companies start
> expecting me to debug their part binary garbage mixed with license
> violations, frankly, I think they're taking the piss.
> 
> A year and a half ago, I met an ATI engineer at OLS, who told me they
> were going to 'resolve this'.  I'm still waiting.
> I live in hope that the AMD buyout will breathe some sanity into ATI.
> Then again, I've only a limited supply of optimism.

But who's actually taking legal actions?

Perhaps pending legal changes that will turn copyright violations into 
crimes might help to take legal actions without the legal risks of
civil trials.

Otherwise, it seems to be highly unlikely that anyone will want to sue a 
company that is often located in a different country, and the only 
possible legal action will be cease and desist letters against people 
who are infriding the copyright by e.g. selling Linux distributions 
containing fglrx at Ebay or operating Debian ftp mirrors. That sounds 
highly unfair, but unfortunately it also seems to be the only effective 
way for someone without a big wallet to effectively act against such 
licence violations...

>   Dave

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 1/2] kill_something_info: misc cleanups

[Eric W. Biederman]

I'm CC'ing the containers list these namespaces are what it is setup
to talk about.

Oleg Nesterov <[EMAIL PROTECTED]> writes:

> On 12/16, Eric W. Biederman wrote:
>>
>> Oleg Nesterov <[EMAIL PROTECTED]> writes:
>> 
>> > On top of
>> >signal-rewrite-kill_something_info-so-it-uses-newer-helpers.patch
>> >
>> > - Factor out sending PIDTYPE_PGID wide signals.
>> >
>> > - Use is_init(p) instead of "p->pid > 1". We don't hash idle threads
> anymore,
>> >   no need to worry about p->pid == 0.
>> 
>> 
>> I do not believe is_init is the proper function here.
>
> Ok. How about child_reaper() for now? "p->pid == 1" doesn't look
> good either.

Ok.  It is probably reasonable to introduce a helper at this point so
we can be clear on what is happening.  I called it pspace_leader
in my proof of concept implementation.  pid_leader is probably more
concise and more in line with the rest of the naming though.

>>In the presence
>> of multiple pid namespaces
>
> In that case we should use something else than for_each_process() to filter
> out task from different namespaces, no?

Probably I haven't quite gotten that far yet.  In my proof of concept
implementation I simply did more filtering on the task list. i.e. I
did this:

> int __kill_pspace_info(int sig, struct siginfo *info, struct pspace *pspace)
> {
> struct task_struct *p = NULL;
> int retval = 0, count = 0;
> 
> for_each_process(p) {
> int err;
> /* Skip the current pspace leader */
> if (current_pspace_leader(p))
> continue;
> 
> /* Skip the sender of the signal */
> if (p->signal == current->signal)
> continue;
> 
> /* Skip processes outside the target process space */
> if (!in_pspace(pspace, p))
> continue;
> 
> /* Finally it is a good process send the signal. */
> err = group_send_sig_info(sig, info, p);
> ++count;
> if (err != -EPERM)
> retval = err;
> }
> return count ? retval : -ESRCH;
> }
> 

The difficult part is the recursive nature of the pid namespace.  We
can't really keep a separate process list for each.  So if we wanted
an efficient traversal the only thing I can see is to put the pids
into a radix tree/trie and walk that.

I haven't gotten to this part yet in the production kernel.  I am
close but not quite there yet.  

>> the intention is for is_init to catch all of
>> the special handling (except signal behavior) for the init process.
>>
>> That way when we have multiple processes with pid == 1 we know which
>> one we care about.
>
> I must admit, I don't understand what is the purpose of pid namespace.
> The current implementation looks incomplete. For example, mk_pid()
> takes pid_namespace into account, but find_pid() (and thus attach_pid())
> does not. Shouldn't pid_hash[] live in the "struct pid_namespace" ?

It isn't yet.  Just a bit of scaffolding to make it possible.  However must
of the support code is in place.  As I see it the first step is getting
everything using struct pid, pid_nr, and getting rid of must uses of
daemonize() and kernel_thread.

Once I have that actually implementing the pid namespace in a usable form
will be a couple of simple patches.

What I am looking at for basic semantics is that each process in
addition to have a unique pid in it's own pid namespace will have a
unique pid in each pid namespace up to the root of the process tree.
I don't expect this to need to be more than about 3 pids for the first
implementation and then CLONE_NEW_PID_NAMESPACE and then return an out
of resources error. 

The pid namespace is fundamentally recursive because otherwise things
like wait and kill (basic process control) won't work if they don't
have pids to work with.  We need to allow for migration which means
pids can be assigned on another machine which means we have to work
with arbitrary pid values.

I have gotten the worst of them but there are still quite a few pid_t
references that need to be fixed up.  The two that stand out in my
head are pids in the siginfo of signal sending and credentials
on unix domain sockets.

When it is done from inside of the pid namespace you will have your
own separate set of pids.  Essentially what we are building is chroot
on steroids.  Separate instances of the pid namespace, the ipc
namespace, and the mount namespace pretty much will result in the
feeling of having the machine to yourself (when you are inside them).

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

Re: [PATCH][2.6.20-rc1-mm1] sparsemem vmem_map optimzed pfn_valid() [0/2]

[KAMEZAWA Hiroyuki]

On Sat, 16 Dec 2006 10:38:53 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:

> On Sat, 16 Dec 2006, KAMEZAWA Hiroyuki wrote:
> 
> > By this, we'll not access mem_section[] in usual ops.
> 
> Why do we need mem_section? We have a page table that fulfills the same 
> role.
> 
Basically, we don't need it.
But I use mem_section[] in bootstrap and I want to keep patches small in this
time. 
I think it's not too late that we'll consider removing it after implementing
memory hot unplug.(and confirm we never use it.)

-Kame 

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

[Stephen Clark]

Jan Engelhardt wrote:


On Dec 16 2006 08:45, Pavel Machek wrote:
 


Two escapes works now. :-)
 


Actually could we fix our consoles, somehow, to make esc usable?
Having important key like esc unusable on consoles is quite ugly.
   



It's something between a misdesign and a misconfiguration of the ESC key.

In other words, many unices make ESC generate ^[, the general
terminal escape character that is _also_ generated by keys like "up",
^[[A.

MS-DOS, or rather QBASIC's, Turbo BASIC's and other implementation of
keys, does not have this "bug": here ESC generates "\x1B" and "up"
generates "\x00H" IIRC. There is no key defined to generate "\x00".
=> All fits nicely.

So I see two steps:

- making ESC generate something else than ^[, or making function
  keys do something else

- fixing the terminfo description and the xterms

- possibly creating a new termtype ("linux2" or "xterm2") so as to
  not tamper with compatibility

Then text-console graphic applications (ncurses, slang, etc.) would
not need to wait the defined one second for an escape sequence to
complete.

HOWEVER, unix people probably _had a reason_ to make ESC generate
part of what function keys do. Should my UP key go broke, I could
still - though probably tedious - reproduce it by hitting the three
keys ESC [ A. Problem, as pointed out, is that ESC has long been used
by the majority of people back then for something else than doing
terminal sequences by hand: DOS, apps, games, Windows GUIs, and,
I suppose, even X11.



-`J'
 


Hi,

do man ascii - ESC is 0x1b.
Thats what the esc key should generate - it sometimes echoed as ^[ 
because the [ = 0x5b


Steve

--

"They that give up essential liberty to obtain temporary safety, 
deserve neither liberty nor safety."  (Ben Franklin)


"The course of history shows that as a government grows, liberty 
decreases."  (Thomas Jefferson)




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

Schedule tsdev.c for removal

[Richard Purdie]

Schedule drivers/input/tsdev.c for removal, nobody should be using
this anymore. See the patch for details.

Signed-off-by: Richard Purdie <[EMAIL PROTECTED]>

 Documentation/feature-removal-schedule.txt |   14 ++
 1 file changed, 14 insertions(+)

Index: git/Documentation/feature-removal-schedule.txt
===
--- git.orig/Documentation/feature-removal-schedule.txt 2006-12-16 
21:44:40.0 +
+++ git/Documentation/feature-removal-schedule.txt  2006-12-17 
00:15:03.0 +
@@ -256,3 +256,17 @@ Why:   Speedstep-centrino driver with ACPI
 Who:   Venkatesh Pallipadi <[EMAIL PROTECTED]>
 
 ---
+
+What:   Compaq touchscreen device emulation
+When:   March 2007
+Files:  drivers/input/tsdev.c
+Why:The code says it was obsolete when it was written in 2001.
+   tslib is a userspace library which does anything tsdev can do and 
+   much more besides in userspace where this code belongs. There is no 
+   longer any need for tsdev and applications should have converted to 
+   use tslib by now.
+   The name "tsdev" is also extremely confusing and lots of people have 
+   it loaded when they don't need/use it.
+Who:Richard Purdie <[EMAIL PROTECTED]>
+
+---

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

Re: [PATCH 1/2] kill_something_info: misc cleanups

[Oleg Nesterov]

On 12/16, Eric W. Biederman wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> writes:
> 
> > On top of
> > signal-rewrite-kill_something_info-so-it-uses-newer-helpers.patch
> >
> > - Factor out sending PIDTYPE_PGID wide signals.
> >
> > - Use is_init(p) instead of "p->pid > 1". We don't hash idle threads 
> > anymore,
> >   no need to worry about p->pid == 0.
> 
> 
> I do not believe is_init is the proper function here.

Ok. How about child_reaper() for now? "p->pid == 1" doesn't look good either.

>In the presence
> of multiple pid namespaces

In that case we should use something else than for_each_process() to filter
out task from different namespaces, no?

> the intention is for is_init to catch all of
> the special handling (except signal behavior) for the init process.
>
> That way when we have multiple processes with pid == 1 we know which
> one we care about.

I must admit, I don't understand what is the purpose of pid namespace.
The current implementation looks incomplete. For example, mk_pid()
takes pid_namespace into account, but find_pid() (and thus attach_pid())
does not. Shouldn't pid_hash[] live in the "struct pid_namespace" ?

Oleg.

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

kernel-rt-15 give NETDEV WATCHDOG: eth1: transmit timed out

[Sergio Monteiro Basto]

Hi, 
kernel-rt-14 rocks but wiht kernel-rt-15 I got kernel: NETDEV WATCHDOG:
eth1: transmit timed out, I downgrade to kernel-rt-14 and that got this
problem anymore.

I not use my on-board via-rhine II Ethernet. 
This tests has been made with one external Ethernet card, one Realtek
Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)

kernel-rt-14 without notsc option and boot clean, don't have any oops
anymore.

Thanks,
-- 
Sérgio M.B.


smime.p7s
Description: S/MIME cryptographic signature

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Ricardo Galli]

On Saturday 16 December 2006 22:01, Linus Torvalds wrote:
> On Sat, 16 Dec 2006, Ricardo Galli wrote:
> > As you probably know, the GPL, the FSF, RMS or even GPL "zealots" never
> > tried to change or restrict "fair use". GPL[23] covers only to
> > "distibution" of the covered program. The freedom #0 says explicitly:
> > "right to use the program for any purpose".
>
> I'm sorry, but you're just rewriting history.
>
> The FSF very much _has_ tried to make "fair use" a very restricted issue.
> The whole reason the LGPL exists is that people realized that if they
> don't do something like that, the GPL would have been tried in court, and
> the FSF's position that anything that touches GPL'd code would probably
> have been shown to be bogus.
>
> In reality, if the FSF actually believed in "fair use", they would just
> have admitted that GNU libc could have continued to be under the GPL, and
> that any programs that link against it are obviously not "derived" from
> it.
>
> But no. The FSF has very much tried to confuse and muddle the issue, and
> instead have claimed that projects like glibc should be done under the
> "Lesser" GPL.

OK, let assume your perspective of the history is the valid and real one, 
then, ¿where are all lawsits against other big GPL only projects? For example 
libqt/kdelibs. You can hardly provide any example where the GPL wasn't hold 
in court.

> The fact is, if you accept fair use, you have to accept it for other
> people to take advantage of too. Fair use really isn't just a one-way
> street.

"Fair use: The right set forth in Section 107 of the United States Copyright 
Act, to use copyrighted materials for certain purposes, such as criticism, 
comment, news reporting, teaching, scholarship, and research. The Copyright 
Act does not define fair use. Instead, whether a use is fair use is 
determined by balancing these factors: ..."

According to the law, I don't see how FSF tries to avoid or to reject the fair 
use rights.

It seems to me you provides us with a copyright law interpretation supported 
only by the very [narrow] exceptions of the copyright law, a logical fallacy.


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

Re: 2.6.19 file content corruption on ext3

[Andrei Popa]

Hello,
I had filesystem data corruption with rtorrent with 2.6.19.
I tried recent git with Peter Zijlstra patch
http://lkml.org/lkml/2006/12/16/144 and it seems that the problem is
fixed.

Please CC as I am not subscribed to lkml.

Andrei

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: IO-APIC + timer doesn't work

[Linus Torvalds]

On Sun, 17 Dec 2006, Tobias Diedrich wrote:
> 
> No such luck, it still panics and the APIC error is also unchanged.

Ok. I don't see anything wrong off-hand, but I'll keep the patch in the 
tree in the hopes that Andi and/or Eric can see what's wrong and solve it.

If we don't find a solution, I'll have to revert it, but let's give it a 
few more days. 

Tobias, can you please make sure to remind me about this if nothing seems 
to happen? 

Thanks,

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))

[Lennert Buytenhek]

On Sun, Dec 17, 2006 at 12:31:34AM +0100, Francois Romieu wrote:

> > Sounds good.  How about something like the patch below plus the
> > corresponding r8169 diff?
> 
> Go wild.

Martin/Riku, I'm pretty busy with other stuff at the moment, can you
give this (on top of 2.6.20-rc1) a spin?  


Index: linux-2.6.19/arch/arm/mach-iop32x/n2100.c
===
--- linux-2.6.19.orig/arch/arm/mach-iop32x/n2100.c
+++ linux-2.6.19/arch/arm/mach-iop32x/n2100.c
@@ -123,9 +123,13 @@ static struct hw_pci n2100_pci __initdat
 
 static int __init n2100_pci_init(void)
 {
-   if (machine_is_n2100())
+   if (machine_is_n2100()) {
pci_common_init(&n2100_pci);
 
+   pci_get_bus_and_slot(0, 0x08)->broken_parity_status = 1;
+   pci_get_bus_and_slot(0, 0x10)->broken_parity_status = 1;
+   }
+
return 0;
 }
 
Index: linux-2.6.19/drivers/net/r8169.c
===
--- linux-2.6.19.orig/drivers/net/r8169.c
+++ linux-2.6.19/drivers/net/r8169.c
@@ -225,7 +225,6 @@ MODULE_DEVICE_TABLE(pci, rtl8169_pci_tbl
 
 static int rx_copybreak = 200;
 static int use_dac;
-static int ignore_parity_err;
 static struct {
u32 msg_enable;
 } debug = { -1 };
@@ -471,8 +470,6 @@ module_param(use_dac, int, 0);
 MODULE_PARM_DESC(use_dac, "Enable PCI DAC. Unsafe on 32 bit PCI slot.");
 module_param_named(debug, debug.msg_enable, int, 0);
 MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ..., 16=all)");
-module_param_named(ignore_parity_err, ignore_parity_err, bool, 0);
-MODULE_PARM_DESC(ignore_parity_err, "Ignore PCI parity error as target. 
Default: false");
 MODULE_LICENSE("GPL");
 MODULE_VERSION(RTL8169_VERSION);
 
@@ -2388,7 +2385,7 @@ static void rtl8169_pcierr_interrupt(str
 *
 * Feel free to adjust to your needs.
 */
-   if (ignore_parity_err)
+   if (pdev->broken_parity_status)
pci_cmd &= ~PCI_COMMAND_PARITY;
else
pci_cmd |= PCI_COMMAND_SERR | PCI_COMMAND_PARITY;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.20-rc1 00/10] Kernel memory leak detector 0.13

[Catalin Marinas]

Hi Ingo,

On 16/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:

FYI, i'm working on integrating kmemleak into -rt. Firstly, i needed the
fixes below when applying it ontop of 2.6.19-rt15.


Do you need these fixes to avoid a compiler error? If yes, this is
caused by a bug in gcc-4.x. The kmemleak container_of macro has
protection for non-constant offsets passed to container_of but the
faulty gcc always returns true for builtin_contant_p, even when this
is not the case. Previous versions (3.4) or one of the latest 4.x gcc
don't have this bug.

I wouldn't extend kmemleak to work around a gcc bug which was already fixed.


Secondly, i'm wondering about the following recursion:

 [] rt_spin_lock_slowlock+0x98/0x1dc
 [] rt_spin_lock+0x13/0x4b
 [] kfree+0x3a/0xce
 [] hash_delete+0x58/0x5f
 [] memleak_free+0xe9/0x1e6
 [] __cache_free+0x27/0x414
 [] kfree+0xb5/0xce
 [] acpi_ns_get_node+0xb1/0xbb
 [] acpi_ns_root_initialize+0x30f/0x31d
 [] acpi_initialize_subsystem+0x58/0x87
 [] acpi_early_init+0x4f/0x12e
 [] start_kernel+0x41b/0x44b

kfree() within kfree() ... this probably works on the upstream SLAB
allocator but makes it pretty nasty to sort out SLAB locking in -rt.


I test kmemleak with lockdep enabled but I eliminated all the
dependencies on the vanilla kernel. When kfree(hnode) is called (in
hash_delete), no kmemleak locks are held and hence no dependency on
the kmemleak locks (since kmemleak is protected against re-entrance).
My understanding is that slab __cache_free is re-entrant anyway
(noticed this when using radix-tree instead of hash in kmemleak and
got some lockdep reports on l3->list_lock and memleak_lock) and
calling it again from kmemleak doesn't seem to have any problem on the
vanilla kernel.

In the -rt kernel, is there any protection against a re-entrant
__cache_free (via cache_flusharray -> free_block -> slab_destroy) or
this is not needed?


Wouldnt it be better to just preallocate the hash nodes, like lockdep
does, to avoid conceptual nesting? Basically debugging infrastructure
should rely on other infrastructure as little as possible.


It would indeed be better to avoid using the slab infrastructure (and
not worry about kmemleak re-entrance and lock dependecies). I'll have
a look on how this is done in lockdep since the preallocation size
isn't known. There are also the memleak_object structures that need to
be allocated/freed. To avoid any locking dependencies, I ended up
delaying the memleak_object structures freeing in an RCU manner. It
might work if I do the same with the hash nodes.


also, the number of knobs in the Kconfig is quite large:


I had some reasons and couldn't find a unified solution, but probably
only for one or two if them:


 CONFIG_DEBUG_MEMLEAK=y
 CONFIG_DEBUG_MEMLEAK_HASH_BITS=16


For my limited configurations (an x86 laptop and several ARM embedded
platforms), 16 bits were enough. I'm not sure this is enough on a
server machine for example.


 CONFIG_DEBUG_MEMLEAK_TRACE_LENGTH=4


I thought this is a user preference. I could hard-code it to 16.
What's the trace length used by lockdep?


 CONFIG_DEBUG_MEMLEAK_PREINIT_OBJECTS=512


I can probably hard-code this as well. This is a buffer to temporary
store memory allocations before kmemleak is fully initialised.
Kmemleak gets initialised quite early in the start_kernel function and
shouldn't be that different in other kernel configurations.


 CONFIG_DEBUG_MEMLEAK_SECONDARY_ALIASES=y
 CONFIG_DEBUG_MEMLEAK_TASK_STACKS=y


These could be eliminated as well.

There are also:

CONFIG_DEBUG_MEMLEAK_REPORT_THLD - can be removed
CONFIG_DEBUG_MEMLEAK_REPORTS_NR - can be removed
CONFIG_DEBUG_KEEP_INIT - this might be useful for other tools that
store the backtrace and display it at a later time. Could be made more
generic.


plus the Kconfig dependency on SLAB_DEBUG makes it less likely for
people to spontaneously try kmemleak. I'd suggest to offer KMEMLEAK
unconditionally (when KERNEL_DEBUG is specified) and simply select
SLAB_DEBUG.


I just followed the DEBUG_SLAB_LEAK configuration but I don't have any
problem with making it more visible.

Thanks for your comments.

--
Catalin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: IO-APIC + timer doesn't work (was: Linux 2.6.20-rc1)

[Linus Torvalds]

On Sun, 17 Dec 2006, Tobias Diedrich wrote:
>
> With commit b0268726 backed out, 2.6.20-rc1 boots fine.

Ok. It's sad, because that thing really did clean stuff up, and seemed 
like a nice and robust approach.

Your dmesg is kind of interesting:

..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 enabled(7)APIC error on CPU0: 
04(40)
 .. failed

where that APIC error on CPU0 seems to be a "Send accept error" and "Send 
illegal vector" thing. I think we actually got the interrupt there, but 
because we had some APIC setup bug, we didn't accept it properly, and it 
resulted in that "APIC error" thing. Maybe. 

This is a long shot, but I wonder if we should _wait_ for the APIC to 
stabilize after we've unmasked the IRQ. Ie, if you could undo the back-out 
(going back to the broken situation), and try the patch below, and see if 
it makes a difference.

Unlikely, I know. I don't see anything wrong with the code, though, but 
maybe I'm just blind.

Eric, Andi, Yinghai, do you see anything here to explain why that commit 
breaks?

Linus

---
diff --git a/arch/x86_64/kernel/io_apic.c b/arch/x86_64/kernel/io_apic.c
index 2a1dcd5..a8a09e0 100644
--- a/arch/x86_64/kernel/io_apic.c
+++ b/arch/x86_64/kernel/io_apic.c
@@ -294,7 +294,7 @@ static void add_pin_to_irq(unsigned int irq, int apic, int 
pin)
 
 DO_ACTION( __mask, 0, |= 0x0001, io_apic_sync(entry->apic) )
/* mask = 1 */
-DO_ACTION( __unmask,   0, &= 0xfffe, )
+DO_ACTION( __unmask,   0, &= 0xfffe, io_apic_sync(entry->apic) )
/* mask = 0 */
 
 static void mask_IO_APIC_irq (unsigned int irq)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))

[Francois Romieu]

Lennert Buytenhek <[EMAIL PROTECTED]> :
[...]
> Sounds good.  How about something like the patch below plus the
> corresponding r8169 diff?

Go wild.

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

Re: 2.6.19 file content corruption on ext3

[Hugh Dickins]

On Sat, 16 Dec 2006, Peter Zijlstra wrote:
> Moving the cleaning of the page out from under the private_lock opened
> up a window where newly attached buffer might still see the page dirty
> status and were thus marked (incorrectly) dirty themselves; resulting in
> filesystem data corruption.

I'm not going to pretend to understand the buffers issues here:
people thought that change was safe originally, and I can't say
it's not - it just stood out as a potentially weakening change.

The patch you propose certainly looks like a good way out, if
that moved unlock really is a problem: your patch is very well
worth trying by those people seeing their corruption problems,
let's wait to hear their feedback.

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

Re: [PATCH 1/2] kill_something_info: misc cleanups

[Eric W. Biederman]

Oleg Nesterov <[EMAIL PROTECTED]> writes:

> On top of
>   signal-rewrite-kill_something_info-so-it-uses-newer-helpers.patch
>
> - Factor out sending PIDTYPE_PGID wide signals.
>
> - Use is_init(p) instead of "p->pid > 1". We don't hash idle threads anymore,
>   no need to worry about p->pid == 0.


I do not believe is_init is the proper function here.  In the presence
of multiple pid namespaces the intention is for is_init to catch all of
the special handling (except signal behavior) for the init process.

That way when we have multiple processes with pid == 1 we know which
one we care about.


> - Use "p != current->group_leader" instead of "p->tgid != current->tgid",
>   saves one dereference and kills yet another direct pid_t usage.

Makes sense as you have to be a group_leader to be on the task list.

> - Simplify return value calculation for "pid == -1" case, remove "retval"
>   variable.
>
> No functional changes.

Looks sane.

> Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>

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

Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))

[Lennert Buytenhek]

On Fri, Dec 15, 2006 at 09:14:35PM +, Russell King wrote:

> > > > Is there a way we can have this done by default on the n2100?  I guess
> > > > that since it's a PCI device, there isn't much hope for that..?
> > > 
> > > Do you mean an automagically tuned default value based on CONFIG_ARM ?
> > 
> > No, that wouldn't make sense, that's like making a workaround depend on
> > arch == i386.
> > 
> > I'm thinking that we should somehow enable this option on the n2100
> > built-in r8169 ports by default only.  Since the n2100 also has a mini-PCI
> > slot, and it is in theory possible to put an r8169 on a mini-PCI card,
> > the workaround probably shouldn't apply to those, so testing for
> > CONFIG_MACH_N2100 also isn't the right thing to do.
> 
> There is dev->broken_parity_status ... although exactly what the sematics
> of that flag actually are seems to be rather vague - there's code which
> sets it for the Mellanox Tavor device, but it seems to only be exposed
> via sysfs - no code in drivers/pci seems to take any action based upon
> this flag being set.

Sounds good.  How about something like the patch below plus the
corresponding r8169 diff?


Index: linux-2.6.19/arch/arm/mach-iop32x/n2100.c
===
--- linux-2.6.19.orig/arch/arm/mach-iop32x/n2100.c
+++ linux-2.6.19/arch/arm/mach-iop32x/n2100.c
@@ -123,9 +123,13 @@ static struct hw_pci n2100_pci __initdat
 
 static int __init n2100_pci_init(void)
 {
-   if (machine_is_n2100())
+   if (machine_is_n2100()) {
pci_common_init(&n2100_pci);
 
+   pci_get_bus_and_slot(0, 0x08)->broken_parity_status = 1;
+   pci_get_bus_and_slot(0, 0x10)->broken_parity_status = 1;
+   }
+
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/

Re: Linux 2.6.20-rc1

[Alistair John Strachan]

On Saturday 16 December 2006 21:36, Linus Torvalds wrote:
> On Fri, 15 Dec 2006, Alistair John Strachan wrote:
> > In total isolation, v2.6.19..0e75f9063f5c55fb0b0b546a7c356f8ec186825e it
> > breaks. Reverting just 0e75f9063f5c55fb0b0b546a7c356f8ec186825e, it works
> > again.
> >
> > So I think this is the source, but I can't explain why it "goes away"
> > before git1 and "comes back" before 2.6.20-rc1.
>
> Can you see if the kernel state at commit 77d172ce ("[PATCH] fix SG_IO bio
> leak") is good? Ie just do something like
>
>   git checkout -b test-branch 77d172ce
>
> and compile and test that?

As predicted, it still doesn't work.

[alistair] 22:59 [~/linux-git] git-status
# On branch refs/heads/test-branch
nothing to commit

[root] 22:59 [~] hddtemp /dev/sda
/dev/sda: ATA WDC WD2500KS-00M: S.M.A.R.T. not available

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 1/2] acpi: Remove procfs from bay

[Kristen Carlson Accardi]

Remove the procfs related code from the bay driver.

Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
---
 drivers/acpi/bay.c |  152 -
 1 file changed, 2 insertions(+), 150 deletions(-)

--- kristen-2.6.orig/drivers/acpi/bay.c
+++ kristen-2.6/drivers/acpi/bay.c
@@ -28,7 +28,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -67,12 +66,10 @@ struct bay {
acpi_handle handle;
char *name;
struct list_head list;
-   struct proc_dir_entry *proc;
 };
 
 LIST_HEAD(drive_bays);
 
-static struct proc_dir_entry *acpi_bay_dir;
 
 /*
  * Drive Bay functions   *
@@ -219,130 +216,11 @@ static int acpi_bay_add(struct acpi_devi
return 0;
 }
 
-static int acpi_bay_status_seq_show(struct seq_file *seq, void *offset)
-{
-   struct bay *bay = (struct bay *)seq->private;
-
-   if (!bay)
-   return 0;
-
-   if (bay_present(bay))
-   seq_printf(seq, "present\n");
-   else
-   seq_printf(seq, "removed\n");
-
-   return 0;
-}
-
-static ssize_t
-acpi_bay_write_eject(struct file *file,
- const char __user * buffer,
- size_t count, loff_t * data)
-{
-   struct seq_file *m = (struct seq_file *)file->private_data;
-   struct bay *bay = (struct bay *)m->private;
-   char str[12] = { 0 };
-   u32 state = 0;
-
-   /* FIXME - our only valid value here is 1 */
-   if (!bay || count + 1 > sizeof str)
-   return -EINVAL;
-
-   if (copy_from_user(str, buffer, count))
-   return -EFAULT;
-
-   str[count] = 0;
-   state = simple_strtoul(str, NULL, 0);
-   if (state)
-   eject_device(bay->handle);
-
-   return count;
-}
-
-static int
-acpi_bay_status_open_fs(struct inode *inode, struct file *file)
-{
-   return single_open(file, acpi_bay_status_seq_show,
-  PDE(inode)->data);
-}
-
-static int
-acpi_bay_eject_open_fs(struct inode *inode, struct file *file)
-{
-   return single_open(file, acpi_bay_status_seq_show,
-  PDE(inode)->data);
-}
-
-static struct file_operations acpi_bay_status_fops = {
-   .open = acpi_bay_status_open_fs,
-   .read = seq_read,
-   .llseek = seq_lseek,
-   .release = single_release,
-};
-
-static struct file_operations acpi_bay_eject_fops = {
-   .open = acpi_bay_eject_open_fs,
-   .read = seq_read,
-   .write = acpi_bay_write_eject,
-   .llseek = seq_lseek,
-   .release = single_release,
-};
-#if 0
-static struct file_operations acpi_bay_insert_fops = {
-   .open = acpi_bay_insert_open_fs,
-   .read = seq_read,
-   .llseek = seq_lseek,
-   .release = single_release,
-};
-#endif
 static int acpi_bay_add_fs(struct bay *bay)
 {
-   struct proc_dir_entry *entry = NULL;
-
if (!bay)
return -EINVAL;
 
-   /*
-* create a proc entry for this device
-* we need to do this a little bit differently than normal
-* acpi device drivers because our device may not be present
-* at the moment, and therefore we have no acpi_device struct
-*/
-
-   bay->proc = proc_mkdir(bay->name, acpi_bay_dir);
-
-   /* 'status' [R] */
-   entry = create_proc_entry("status",
- S_IRUGO, bay->proc);
-   if (!entry)
-   return -EIO;
-   else {
-   entry->proc_fops = &acpi_bay_status_fops;
-   entry->data = bay;
-   entry->owner = THIS_MODULE;
-   }
-   /* 'eject' [W] */
-   entry = create_proc_entry("eject",
- S_IWUGO, bay->proc);
-   if (!entry)
-   return -EIO;
-   else {
-   entry->proc_fops = &acpi_bay_eject_fops;
-   entry->data = bay;
-   entry->owner = THIS_MODULE;
-   }
-#if 0
-   /* 'insert' [W] */
-   entry = create_proc_entry("insert",
- S_IWUGO, bay->proc);
-   if (!entry)
-   return -EIO;
-   else {
-   entry->proc_fops = &acpi_bay_insert_fops;
-   entry->data = bay;
-   entry->owner = THIS_MODULE;
-   }
-#endif
return 0;
 }
 
@@ -350,16 +228,6 @@ static void acpi_bay_remove_fs(struct ba
 {
if (!bay)
return;
-
-   if (bay->proc) {
-   remove_proc_entry("status", bay->proc);
-   remove_proc_entry("eject", bay->proc);
-#if 0
-   remove_proc_entry("insert", bay->proc);
-#endif
-   remove_proc_entry(bay->name, acpi_bay_dir);
-   bay->proc = NULL;
-   }
 }
 
 static int bay_is_dock_device(acpi_handle handle)
@@ -384,13 +252,6 @@ static int bay_add(acpi_handle ha

2.6.20-rc1-git4: drivers/connector/connector.c doesn't build due to work_struct changes

[Alessandro Suardi]

 CC [M]  drivers/char/hangcheck-timer.o
 CC  drivers/clocksource/acpi_pm.o
 LD  drivers/clocksource/built-in.o
 CC [M]  drivers/connector/cn_queue.o
 CC [M]  drivers/connector/connector.o
drivers/connector/connector.c: In function 'cn_call_callback':
drivers/connector/connector.c:138: error: 'struct work_struct' has no
member named 'management'
drivers/connector/connector.c:138: error: 'struct work_struct' has no
member named 'management'
make[2]: *** [drivers/connector/connector.o] Error 1
make[1]: *** [drivers/connector] Error 2
make: *** [drivers] Error 2

--alessandro

"...when I get it, I _get_ it"

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

[patch 0/2] more patches for removable drive bay

[Kristen Carlson Accardi]

Hi Len,
Here's a set of patches for changing the removable drive bay driver
(drivers/acpi/bay) from using the old proc interface to using a sysfs
interface instead.  I made the bay driver a platform driver, and 
so it's entries will now be located in /sys/devices/platform/bay.X.
There are still 2 entries - one for checking whether the bay is
present (present) that is read only, and one that is write only for
ejecting the bay (eject).  Let me know if you would prefer me to fold
these into the original bay driver patch.

Thanks,
Kristen
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/2] Convert the bay driver to be a platform driver

[Kristen Carlson Accardi]

Convert the bay driver to be a platform driver, so that we can have sysfs 
entries.

Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
---

 drivers/acpi/bay.c |   87 +
 1 file changed, 75 insertions(+), 12 deletions(-)

--- kristen-2.6.orig/drivers/acpi/bay.c
+++ kristen-2.6/drivers/acpi/bay.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define ACPI_BAY_DRIVER_NAME "ACPI Removable Drive Bay Driver"
 
@@ -45,7 +46,6 @@ MODULE_LICENSE("GPL");
struct acpi_buffer buffer = {sizeof(prefix), prefix};\
acpi_get_name(h, ACPI_FULL_PATHNAME, &buffer);\
printk(KERN_DEBUG PREFIX "%s: %s\n", prefix, s); }
-
 static void bay_notify(acpi_handle handle, u32 event, void *data);
 static int acpi_bay_add(struct acpi_device *device);
 static int acpi_bay_remove(struct acpi_device *device, int type);
@@ -66,6 +66,7 @@ struct bay {
acpi_handle handle;
char *name;
struct list_head list;
+   struct platform_device *pdev;
 };
 
 LIST_HEAD(drive_bays);
@@ -133,6 +134,33 @@ static void eject_device(acpi_handle han
pr_debug("Failed to evaluate _EJ0!\n");
 }
 
+/*
+ * show_present - read method for "present" file in sysfs
+ */
+static ssize_t show_present(struct device *dev,
+  struct device_attribute *attr, char *buf)
+{
+   struct bay *bay = dev_get_drvdata(dev);
+   return snprintf(buf, PAGE_SIZE, "%d\n", bay_present(bay));
+
+}
+DEVICE_ATTR(present, S_IRUGO, show_present, NULL);
+
+/*
+ * write_eject - write method for "eject" file in sysfs
+ */
+static ssize_t write_eject(struct device *dev, struct device_attribute *attr,
+  const char *buf, size_t count)
+{
+   struct bay *bay = dev_get_drvdata(dev);
+
+   if (!count)
+   return -EINVAL;
+
+   eject_device(bay->handle);
+   return count;
+}
+DEVICE_ATTR(eject, S_IWUSR, NULL, write_eject);
 
 /**
  * is_ata - see if a device is an ata device
@@ -218,16 +246,32 @@ static int acpi_bay_add(struct acpi_devi
 
 static int acpi_bay_add_fs(struct bay *bay)
 {
-   if (!bay)
-   return -EINVAL;
+   int ret;
+   struct device *dev = &bay->pdev->dev;
 
+   ret = device_create_file(dev, &dev_attr_present);
+   if (ret)
+   goto add_fs_err;
+   ret = device_create_file(dev, &dev_attr_eject);
+   if (ret) {
+   device_remove_file(dev, &dev_attr_present);
+   goto add_fs_err;
+   }
return 0;
+
+add_fs_err:
+   bay_dprintk(bay->handle, "Error adding sysfs files\n");
+   return ret;
+
 }
 
 static void acpi_bay_remove_fs(struct bay *bay)
 {
-   if (!bay)
-   return;
+   struct device *dev = &bay->pdev->dev;
+
+   /* cleanup sysfs */
+   device_remove_file(dev, &dev_attr_present);
+   device_remove_file(dev, &dev_attr_eject);
 }
 
 static int bay_is_dock_device(acpi_handle handle)
@@ -242,10 +286,11 @@ static int bay_is_dock_device(acpi_handl
return (is_dock_device(handle) || is_dock_device(parent));
 }
 
-static int bay_add(acpi_handle handle)
+static int bay_add(acpi_handle handle, int id)
 {
acpi_status status;
struct bay *new_bay;
+   struct platform_device *pdev;
struct acpi_buffer nbuffer = {ACPI_ALLOCATE_BUFFER, NULL};
acpi_get_name(handle, ACPI_FULL_PATHNAME, &nbuffer);
 
@@ -254,12 +299,24 @@ static int bay_add(acpi_handle handle)
/*
 * Initialize bay device structure
 */
-   new_bay = kmalloc(GFP_ATOMIC, sizeof(*new_bay));
+   new_bay = kzalloc(GFP_ATOMIC, sizeof(*new_bay));
INIT_LIST_HEAD(&new_bay->list);
new_bay->handle = handle;
new_bay->name = (char *)nbuffer.pointer;
-   list_add(&new_bay->list, &drive_bays);
-   acpi_bay_add_fs(new_bay);
+
+   /* initialize platform device stuff */
+   pdev = platform_device_register_simple(ACPI_BAY_CLASS, id, NULL, 0);
+   if (pdev == NULL) {
+   printk(KERN_ERR PREFIX "Error registering bay device\n");
+   goto bay_add_err;
+   }
+   new_bay->pdev = pdev;
+   platform_set_drvdata(pdev, new_bay);
+
+   if (acpi_bay_add_fs(new_bay)) {
+   platform_device_unregister(new_bay->pdev);
+   goto bay_add_err;
+   }
 
/* register for events on this device */
status = acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
@@ -275,8 +332,14 @@ static int bay_add(acpi_handle handle)
bay_dprintk(handle, "Is dependent on dock\n");
register_hotplug_dock_device(handle, bay_notify, new_bay);
}
+   list_add(&new_bay->list, &drive_bays);
printk(KERN_INFO PREFIX "Bay [%s] Added\n", new_bay->name);
return 0;
+
+bay_add_err:
+   kfree(new_bay->name);
+   kfree(new_bay);
+   return -ENODEV;
 }
 
 static int acpi_bay_remove(struct acpi_device *

Re: Linux 2.6.20-rc1

[Jeff Garzik]

Alistair John Strachan wrote:

It could simply be that bisect isn't working here because it's actually broken
by two separate patches. Out of bad luck, I've ended up singling out the one
that already has a "fix", and the "real bug" hasn't been found.

I guess I should repeat the bisection, and when the bio-fix isn't applied,
manually apply it? Is there some magical Git way to do this?

Here's the bisection log, for what it's worth;



This may be totally subjective on my part, but if I get stuck (and I 
have the patience) I sometimes like to look at the log and try to pick 
arbitrary 'good' points, to stir the pot a bit.


Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.20-rc1

[Alistair John Strachan]

On Saturday 16 December 2006 21:36, Linus Torvalds wrote:
> On Fri, 15 Dec 2006, Alistair John Strachan wrote:
> > In total isolation, v2.6.19..0e75f9063f5c55fb0b0b546a7c356f8ec186825e it
> > breaks. Reverting just 0e75f9063f5c55fb0b0b546a7c356f8ec186825e, it works
> > again.
> >
> > So I think this is the source, but I can't explain why it "goes away"
> > before git1 and "comes back" before 2.6.20-rc1.
>
> Can you see if the kernel state at commit 77d172ce ("[PATCH] fix SG_IO bio
> leak") is good? Ie just do something like
>
>   git checkout -b test-branch 77d172ce
>
> and compile and test that?
>
> That commit _should_ be the one that fixed whatever problems that commit
> 0e75f906 introduced. It *did* fix it for other - somewhat similar -
> situations.
>
> That said: Jens - I think 0e75f906 was a mistake. "blk_rq_unmap()" really
> should be passed the "struct bio", not the "struct request *". Right now
> it does something _really_ strange with requests with linked bio's, and I
> don't think your and FUJITA's "leak fix" really works. What happens when
> the bio was a linked list on the request, and you put the old _head_ on
> the request with "rq->bio = bio"? What happens to the other parts of it?
>
> IOW, I think this is broken. I think we should revert 0e75f906. Or at
> least you should explain to me why it's not broken, and why clearly people
> (eg Alistair) still see problems with it?

It could simply be that bisect isn't working here because it's actually broken
by two separate patches. Out of bad luck, I've ended up singling out the one
that already has a "fix", and the "real bug" hasn't been found.

I guess I should repeat the bisection, and when the bio-fix isn't applied,
manually apply it? Is there some magical Git way to do this?

Here's the bisection log, for what it's worth;

[alistair] 22:27 [~/linux-git] git bisect log
git-bisect start
# bad: [cc016448b0bf0764928275d034e367753bde8162] Linux v2.6.20-rc1
git-bisect bad cc016448b0bf0764928275d034e367753bde8162
# good: [c3fe6924620fd733ffe8bc8a9da1e9cde08402b3] Linux 2.6.19
git-bisect good c3fe6924620fd733ffe8bc8a9da1e9cde08402b3
# bad: [b2c03941b50944a268ee4d5823872f220809a3ba] IPMI: Allow hot system 
interface remove
git-bisect bad b2c03941b50944a268ee4d5823872f220809a3ba
# bad: [29b08d2bae854f66d3cfd5f57aaf2e7c2c7fce32] [S390] pfault code cleanup.
git-bisect bad 29b08d2bae854f66d3cfd5f57aaf2e7c2c7fce32
# bad: [0e11c91e1e912bc4db5b71607d149e7e9a77e756] [AF_PACKET]: annotate
git-bisect bad 0e11c91e1e912bc4db5b71607d149e7e9a77e756
# bad: [5f56bbdf1e35d41b4b3d4c92bdb3e70c63877e4d] Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband
git-bisect bad 5f56bbdf1e35d41b4b3d4c92bdb3e70c63877e4d
# good: [94fcda1f8ab5e0cacc381c5ca1cc9aa6ad523576] usbcore: remove unused 
argument in autosuspend
git-bisect good 94fcda1f8ab5e0cacc381c5ca1cc9aa6ad523576
# bad: [4549df891a31b9a05b7d183106c09049b79327be] Merge 
master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6
git-bisect bad 4549df891a31b9a05b7d183106c09049b79327be
# good: [5ab699810d46011ad2195c5916f3cbc684bfe3ee] driver core: Introduce 
device_find_child().
git-bisect good 5ab699810d46011ad2195c5916f3cbc684bfe3ee
# good: [6b44d4e69c6144d0df71ab47ec90d2009237d48f] Fix typos in 
drivers/isdn/hisax/isdnl2.c
git-bisect good 6b44d4e69c6144d0df71ab47ec90d2009237d48f
# bad: [6b8cc71ab2619a776b02869fd733ac1ead3db4e8] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6
git-bisect bad 6b8cc71ab2619a776b02869fd733ac1ead3db4e8
# bad: [bb37b94c68e7b37eecea8576039ae9396ca07839] [BLOCK] Cleanup unused 
variable passing
git-bisect bad bb37b94c68e7b37eecea8576039ae9396ca07839
# good: [ad2d7225709b11da47e092634cbdf0591829ae9c] block: kill length alignment 
test in bio_map_user()
git-bisect good ad2d7225709b11da47e092634cbdf0591829ae9c
# bad: [0e75f9063f5c55fb0b0b546a7c356f8ec186825e] block: support larger block 
pc requests
git-bisect bad 0e75f9063f5c55fb0b0b546a7c356f8ec186825e

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/1] Char: tty_wakeup cleanup

[Jiri Slaby]

tty_wakeup cleanup

- remove wake_up_interruptible(&tty->write_wait) surrounding
  tty_wakup(tty);
- substitute tty->ldisc.write_wakeup(tty) + wake_up() by tty_wakeup(tty);

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

---
commit 2acac8f970a75a3dc8466781845ae5d14c3d8988
tree 396cc84d4e198d2a65cd4aa9748aabeab5681ba5
parent 8b380d8b1c3ff7d09d68d467d2f135774cab4086
author Jiri Slaby <[EMAIL PROTECTED]> Sat, 16 Dec 2006 22:22:57 +0059
committer Jiri Slaby <[EMAIL PROTECTED]> Sat, 16 Dec 2006 22:22:57 +0059

 drivers/char/amiserial.c |5 +
 drivers/char/cyclades.c  |1 -
 drivers/char/epca.c  |3 ---
 drivers/char/generic_serial.c|1 -
 drivers/char/ip2/i2lib.c |   10 +-
 drivers/char/isicom.c|1 -
 drivers/char/istallion.c |1 -
 drivers/char/mxser.c |4 +---
 drivers/char/pcmcia/synclink_cs.c|4 +---
 drivers/char/rio/riointr.c   |9 ++---
 drivers/char/riscom8.c   |5 +
 drivers/char/rocket.c|3 ---
 drivers/char/specialix.c |4 +---
 drivers/char/synclink.c  |5 +
 drivers/char/synclink_gt.c   |5 +
 drivers/char/synclinkmp.c|5 +
 drivers/isdn/gigaset/interface.c |   14 ++
 drivers/isdn/i4l/isdn_tty.c  |1 -
 drivers/serial/crisv10.c |   14 +++---
 drivers/tc/zs.c  |4 +---
 drivers/usb/serial/digi_acceleport.c |   10 +-
 drivers/usb/serial/keyspan_pda.c |7 +--
 drivers/usb/serial/mos7720.c |   14 ++
 drivers/usb/serial/mos7840.c |   14 ++
 drivers/usb/serial/serqt_usb.c   |   18 ++
 25 files changed, 25 insertions(+), 137 deletions(-)

diff --git a/drivers/char/amiserial.c b/drivers/char/amiserial.c
index feb4ac8..39880eb 100644
--- a/drivers/char/amiserial.c
+++ b/drivers/char/amiserial.c
@@ -527,10 +527,8 @@ static void do_softint(unsigned long private_)
if (!tty)
return;
 
-   if (test_and_clear_bit(RS_EVENT_WRITE_WAKEUP, &info->event)) {
+   if (test_and_clear_bit(RS_EVENT_WRITE_WAKEUP, &info->event))
tty_wakeup(tty);
-   wake_up_interruptible(&tty->write_wait);
-   }
 }
 
 /*
@@ -968,7 +966,6 @@ static void rs_flush_buffer(struct tty_struct *tty)
local_irq_save(flags);
info->xmit.head = info->xmit.tail = 0;
local_irq_restore(flags);
-   wake_up_interruptible(&tty->write_wait);
tty_wakeup(tty);
 }
 
diff --git a/drivers/char/cyclades.c b/drivers/char/cyclades.c
index 3ffa080..363beb1 100644
--- a/drivers/char/cyclades.c
+++ b/drivers/char/cyclades.c
@@ -4488,7 +4488,6 @@ static void cy_flush_buffer(struct tty_struct *tty)
CY_UNLOCK(info, flags);
}
tty_wakeup(tty);
-   wake_up_interruptible(&tty->write_wait);
 }  /* cy_flush_buffer */
 
 /*
diff --git a/drivers/char/epca.c b/drivers/char/epca.c
index a0f822c..88fc24f 100644
--- a/drivers/char/epca.c
+++ b/drivers/char/epca.c
@@ -844,7 +844,6 @@ static void pc_flush_buffer(struct tty_struct *tty)
fepcmd(ch, STOUT, (unsigned) tail, 0, 0, 0);
memoff(ch);
spin_unlock_irqrestore(&epca_lock, flags);
-   wake_up_interruptible(&tty->write_wait);
tty_wakeup(tty);
 } /* End pc_flush_buffer */
 
@@ -1795,7 +1794,6 @@ static void doevent(int crd)
{ /* Begin if LOWWAIT */
ch->statusflags &= ~LOWWAIT;
tty_wakeup(tty);
-   wake_up_interruptible(&tty->write_wait);
} /* End if LOWWAIT */
} else if (event & EMPTYTX_IND)  { /* Begin EMPTYTX_IND 
*/
/* This event is generated by setup_empty_event 
*/
@@ -1803,7 +1801,6 @@ static void doevent(int crd)
if (ch->statusflags & EMPTYWAIT)  { /* Begin if 
EMPTYWAIT */
ch->statusflags &= ~EMPTYWAIT;
tty_wakeup(tty);
-   wake_up_interruptible(&tty->write_wait);
} /* End if EMPTYWAIT */
} /* End EMPTYTX_IND */
} /* End if valid tty */
diff --git a/drivers/char/generic_serial.c b/drivers/char/generic_serial.c
index e769811..337bbcd 100644
--- a/drivers/char/generic_serial.c
+++ b/drivers/char/generic_serial.c
@@ -382,7 +382,6 @@ void gs_flush_buffer(struct tty_struct *tty)
port->xmit_cnt = port->xmit_head = port->xmit_tail = 0;
spin_unlock_irqrestore (&port->driver_lock, flags);
 
-   wake_up_interruptible(&tty->write_wait);
tty_wakeup(tty);
fun

Re: cxgb3 and 2.6.20-rc1

[Jan Engelhardt]

On Dec 16 2006 13:55, Divy Le Ray wrote:
>> > A corresponding monolithic patch is posted at the following URL:
>> > http://service.chelsio.com/kernel.org/cxgb3.patch.bz2
>> > 
>> 
>> I was unable to compile this on 2.6.20-rc1, because:
>> 
>>  CC [M]  drivers/net/cxgb3/cxgb3_offload.o
>> drivers/net/cxgb3/cxgb3_offload.c: In function ‘cxgb_free_mem’:
>> drivers/net/cxgb3/cxgb3_offload.c:1004: error: ‘PKMAP_BASE’ undeclared
>> (first use in this function)
>> 
>> However, line 1004 is:
>> 
>> if (p >= VMALLOC_START && p < VMALLOC_END)
>> 
>> and include/asm/pgtable.h:
>> 
>> # ifdef CONFIG_HIGHMEM
>> # define VMALLOC_END(PKMAP_BASE-2*PAGE_SIZE)
>> # else
>> # define VMALLOC_END(FIXADDR_START-2*PAGE_SIZE)
>> # endif
>> 
>> So include/asm/pgtable.h lacks inclusion of include/asm/highmem.h,
>> where PKMAP_BASE is defined. Adding it gives me more compile errors.
>> Not good. Does anyone have a patch to fix that?
>> 
>
> I've never tripped on this. I cannot reproduce it.

Enable CONFIG_HIGHMEM4G or CONFIG_HIGHMEM64G.

> Would you mind trying this:
> add #include  in drivers/net/cxgb3/cxgb3_offload.c 
> and see if it fixes the compilation ?

Yes 'fixes' it.
But such a change seems bogus to me. You are 
using VMALLOC_END, hence you should include the .h file which contains 
VMALLOC_END, and nothing more. Of course there are exceptions to this 
(like getting at elevator.h's stuff by means of inclusion of blkdev.h)


-`J'
-- 

Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))

[Francois Romieu]

Lennert Buytenhek <[EMAIL PROTECTED]> :
> On Sat, Dec 16, 2006 at 01:54:39AM +0100, Francois Romieu wrote:
[...]
> I'm thinking that the entire option is just wrong.  It sucks for
> distributors to have to make the choice between having it always on
> and having it always off.  It sucks for end users compiling their
> own kernels, because their ethernet won't work out of the box, and
> they will have no idea what's wrong and what to do.

I would have hoped that it was distributors's job to figure the details
of the configuration at run time from userspace when their package manager
updates the kernel. From there they can set whatever runtime option is
necessary in the configuration file of the modutils package.

However you are right that users may get screwed when they compile their
own kernel though. What about something like the patch below:

Date: Sat, 16 Dec 2006 22:36:06 +0100
Subject: [PATCH] r8169: Aunt Tillie got a Thecus N2100 for Xmas

She compiles kernel again. If only she had been offered an Internet
connexion and an introductory guide to Google too...

Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
---
 drivers/net/Kconfig |   11 +++
 drivers/net/r8169.c |4 
 2 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 9de0eed..57432d9 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2085,6 +2085,17 @@ config R8169_VLAN
  
  If in doubt, say Y.
 
+config R8169_SYSERR_DISABLE
+   bool "Disable reporting of the PCI SysErr"
+   depends on R8169 && ARCH_IOP32X
+   ---help---
+ Without this option, the driver reports a lot of PCI SysErr and
+ is completely unusable with the Thecus N2100. As an alternate
+ solution, you can use the 'ignore_parity_err' parameter of the
+ r8169 module to cure the problem at runtime.
+
+ If in doubt, say N.
+
 config SIS190
tristate "SiS190/SiS191 gigabit ethernet support"
depends on PCI
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index f83b41d..5e4149e 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -225,7 +225,11 @@ MODULE_DEVICE_TABLE(pci, rtl8169_pci_tbl
 
 static int rx_copybreak = 200;
 static int use_dac;
+#ifdef CONFIG_R8169_SYSERR_DISABLE
+static int ignore_parity_err = 1;
+#else
 static int ignore_parity_err;
+#endif
 static struct {
u32 msg_enable;
 } debug = { -1 };
-- 
1.4.4.1

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

Re: Linux 2.6.20-rc1

[Linus Torvalds]

On Fri, 15 Dec 2006, Alistair John Strachan wrote:
> 
> In total isolation, v2.6.19..0e75f9063f5c55fb0b0b546a7c356f8ec186825e it 
> breaks. Reverting just 0e75f9063f5c55fb0b0b546a7c356f8ec186825e, it works 
> again.
> 
> So I think this is the source, but I can't explain why it "goes away" before 
> git1 and "comes back" before 2.6.20-rc1.

Can you see if the kernel state at commit 77d172ce ("[PATCH] fix SG_IO bio 
leak") is good? Ie just do something like

git checkout -b test-branch 77d172ce

and compile and test that?

That commit _should_ be the one that fixed whatever problems that commit 
0e75f906 introduced. It *did* fix it for other - somewhat similar - 
situations.

That said: Jens - I think 0e75f906 was a mistake. "blk_rq_unmap()" really 
should be passed the "struct bio", not the "struct request *". Right now 
it does something _really_ strange with requests with linked bio's, and I 
don't think your and FUJITA's "leak fix" really works. What happens when 
the bio was a linked list on the request, and you put the old _head_ on 
the request with "rq->bio = bio"? What happens to the other parts of it?

IOW, I think this is broken. I think we should revert 0e75f906. Or at 
least you should explain to me why it's not broken, and why clearly people 
(eg Alistair) still see problems with it?

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

Re: 2.6.19 file content corruption on ext3

[Peter Zijlstra]

On Sat, 2006-12-16 at 19:18 +, Hugh Dickins wrote:
> On Sat, 16 Dec 2006, Martin Michlmayr wrote:
> > * Marc Haber <[EMAIL PROTECTED]> [2006-12-09 10:26]:
> > > Unfortunately, I am lacking the knowledge needed to do this in an
> > > informed way. I am neither familiar enough with git nor do I possess
> > > the necessary C powers.
> > 
> > I wonder if what you're seein is related to
> > http://lkml.org/lkml/2006/12/16/73
> > 
> > You said that you don't see any corruption with 2.6.18.  Can you try
> > to apply the patch from
> > http://www2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d08b3851da41d0ee60851f2c75b118e1f7a5fc89
> > to 2.6.18 to see if the corruption shows up?
> 
> I did wonder about the very first hunk of Peter's patch, where the
> mapping->private_lock is unlocked earlier now in try_to_free_buffers,
> before the clear_page_dirty.  I'm not at all familiar with that area,
> I wonder if Jan has looked at that change, and might be able to say
> whether it's good or not (earlier he worried about his JBD changes,
> but they wouldn't be implicated if just 2.6.18+Peter's gives trouble).

fs/buffers.c:2775

/*
 * try_to_free_buffers() checks if all the buffers on this particular page
 * are unused, and releases them if so.
 *
 * Exclusion against try_to_free_buffers may be obtained by either
 * locking the page or by holding its mapping's private_lock.
 *
 * If the page is dirty but all the buffers are clean then we need to
 * be sure to mark the page clean as well.  This is because the page
 * may be against a block device, and a later reattachment of buffers
 * to a dirty page will set *all* buffers dirty.  Which would corrupt
 * filesystem data on the same device.
 *
 * The same applies to regular filesystem pages: if all the buffers are
 * clean then we set the page clean and proceed.  To do that, we require
 * total exclusion from __set_page_dirty_buffers().  That is obtained with
 * private_lock.
 *
 * try_to_free_buffers() is non-blocking.
 */

Note the 3th paragraph. Would I have opened up a race by moving that
unlock upwards, such that it is possible to re-attach buffers to the
page before having it marked clean; which according to this text will
mark those buffers dirty and cause data corruption?

Hmm, how to go about something like this:

---
Moving the cleaning of the page out from under the private_lock opened
up a window where newly attached buffer might still see the page dirty
status and were thus marked (incorrectly) dirty themselves; resulting in
filesystem data corruption.

Close this by moving the cleaning of the page inside of the private_lock
scope again. However it is not possible to call page_mkclean() from
within the private_lock (this violates locking order); thus introduce a
variant of test_clear_page_dirty() that does not call page_mkclean() and
call it ourselves when we did do clean the page and call it outside of
the private_lock.

This is still safe because the page is still locked by means of
PG_locked.

Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
 fs/buffer.c|   11 +--
 include/linux/page-flags.h |1 +
 mm/page-writeback.c|   10 --
 3 files changed, 18 insertions(+), 4 deletions(-)

Index: linux-2.6-git/fs/buffer.c
===
--- linux-2.6-git.orig/fs/buffer.c  2006-12-16 22:18:24.0 +0100
+++ linux-2.6-git/fs/buffer.c   2006-12-16 22:22:17.0 +0100
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static int fsync_buffers_list(spinlock_t *lock, struct list_head *list);
 static void invalidate_bh_lrus(void);
@@ -2832,6 +2833,7 @@ int try_to_free_buffers(struct page *pag
struct address_space * const mapping = page->mapping;
struct buffer_head *buffers_to_free = NULL;
int ret = 0;
+   int must_clean = 0;
 
BUG_ON(!PageLocked(page));
if (PageWriteback(page))
@@ -2844,7 +2846,6 @@ int try_to_free_buffers(struct page *pag
 
spin_lock(&mapping->private_lock);
ret = drop_buffers(page, &buffers_to_free);
-   spin_unlock(&mapping->private_lock);
if (ret) {
/*
 * If the filesystem writes its buffers by hand (eg ext3)
@@ -2858,9 +2859,15 @@ int try_to_free_buffers(struct page *pag
 * the page's buffers clean.  We discover that here and clean
 * the page also.
 */
-   if (test_clear_page_dirty(page))
+   if (__test_clear_page_dirty(page, 0)) {
task_io_account_cancelled_write(PAGE_CACHE_SIZE);
+   if (mapping_cap_account_dirty(mapping))
+   must_clean = 1;
+   }
}
+   spin_unlock(&mapping->private_lock);
+   if (must_clean)
+   page_mkclean(page);
 out:
if (buffers_to_free) {
struct buffer_head *bh = buf

Re: Recent mm changes leading to filesystem corruption?

[Martin Michlmayr]

* Peter Zijlstra <[EMAIL PROTECTED]> [2006-12-16 21:55]:
> What is not clear from all these reports is what architectures this is
> seen on. I suspect some of them are i686, which together with the
> explicit mention of ARM make it a cross platform issue.

Problems have been seen at least on x86, x86_64 and arm.
-- 
Martin Michlmayr
[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: [KORG] Re: kernel.org lies about latest -mm kernel

[Nigel Cunningham]

Hi.

I've have git trees against a few versions besides Linus', and have just
moved all but Linus' to staging to help until you can get your new
hardware. If others were encouraged to do the same, it might help a lot?

Regards,

Nigel

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

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Willy Tarreau]

On Sat, Dec 16, 2006 at 03:23:12PM -0500, Theodore Tso wrote:
> On Sat, Dec 16, 2006 at 05:30:31PM +0100, Willy Tarreau wrote:
> > I don't think this is the same case. The film _author_'s primary goal is
> > to have a lot of families buy his DVD to watch it. Whatever the MPAA says,
> > I can consider it "fair use" if a family of 4..8 persons watch the DVD at
> > the same time. 
> 
> "You can consider it"?  But you're not the author.  This is the
> hypocrisy that Linus was talking about.  At the same time that you're
> trying to dictate to other other people can use their copy of the
> Linux kernel, when it comes to others people's copyrighted work, you
> feel to dictate what is and isn't "fair use".

No, I don't want to dictate, it's the opposite, I say what _I_ consider
fair use. Other people will consider it other ways. It's exactly the
gray area Linus was talking about. As long as all parties agree on one
given fair use, there's no problem. Discussion and sometimes litigation
is needed when some parties disagree.

> That's the big thing about dynamic linking.  The GPL has always said
> it is about distribution, not about use.  The dynamic linking of a
> kernel module happens in the privacy of someone's home.  When we try
> to dictate what people are doing in the privacy in their home, we're
> no better than the MPAA or the RIAA.  

100% agreed with you on this !

> As far as whether or not someone is allowed to distribute a binary
> module that can be linked into the Linux kernel, that's a question of
> whether the binary module is a derived work or not.  And that's not up
> to us, that's up to the local laws.  But before you decide that you
> want the most extreme form of anything that wanders close to one
> person's code or header files is a derived work, and to start going to
> work lobbying your local legislature, recall that there have been
> those who have claimed that Linux is a derived work of Unix because we
> used things like #define's for errno codes and structure definitions
> of ELF binaries.  You really sure you want to go there?

Ted, I think you get me wrong. I don't want to dictate anyone what's
derived work and what is not. Instead, it's the opposite. I just want
to indicate them what's explicitly permitted by the author and copyright
owner (at least by me as the author/copyright owner when I can) so that
people can decide by themselves what level of risk they take by doing
whatever they want. What I consider the most important is to encourage
fair use even in areas I never anticipated, and when possible, try to
protect fair users from the GPL zealots who want to bite whenever one
gives them an opportunity to abuse the gray area to feel stronger.

I have opened even more my software and tried to clarify the reasons
why I chose the dual license exactly for this reason.

What I was suggesting is to add a clarification with the kernel to
avoid those overly long threads on LKML such as this one. It would
basically be structured like this :

"Use in the following order" :
  1) fully respect the license and you're OK.
  2) play in the gray area if you need and if you consider it fair use,
 but seek legal advice from a lawyer (and not LKML) before !
  3) explicitly violate the license, and prepare to get sued sooner or later.
  For GPL zealots : please do not report what _you_ consider abuse to LKML,
  contact the abuser, then a lawyer or specialized sites for this.

But Linus is right, he's not the only copyright owner, and that makes it
harder to touch anything related to license and use.

>   - Ted

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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Linus Torvalds]

On Sat, 16 Dec 2006, Ricardo Galli wrote:

> As you probably know, the GPL, the FSF, RMS or even GPL "zealots" never tried 
> to change or restrict "fair use". GPL[23] covers only to "distibution" of the 
> covered program. The freedom #0 says explicitly: "right to use the program 
> for any purpose".

I'm sorry, but you're just rewriting history.

The FSF very much _has_ tried to make "fair use" a very restricted issue. 
The whole reason the LGPL exists is that people realized that if they 
don't do something like that, the GPL would have been tried in court, and 
the FSF's position that anything that touches GPL'd code would probably 
have been shown to be bogus.

In reality, if the FSF actually believed in "fair use", they would just 
have admitted that GNU libc could have continued to be under the GPL, and 
that any programs that link against it are obviously not "derived" from 
it.

But no. The FSF has very much tried to confuse and muddle the issue, and 
instead have claimed that projects like glibc should be done under the 
"Lesser" GPL.

That's just idiocy, but it works as a way to defuse the problem that the 
FSF has always had with admitting that not only _they_ have "fair use" 
rights, but others have them too.

Do you REALLY believe that a binary becomes a "derived work" of any random 
library that it gets linked against? If that's not "fair use" of a library 
that implements a standard library definition, I don't know what is.

And yes, the FSF really has tried to push that totally insane argument. 

So don't tell me that the FSF honors "fair use". They say they do, but 
they only seem to honor it when it helps _their_ argument, not when it 
helps "those evil people who try to take advantage of our hard work".

The fact is, if you accept fair use, you have to accept it for other 
people to take advantage of too. Fair use really isn't just a one-way 
street.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.20-rc1 in __find_get_block()

[Ben Collins]

This occurred on a X40 (amd64 running x86 kernel) after a few minutes of
uptime. Cc'd Daniel, since he originally reported the bug.

Kernel is SMP, voluntary-preempt.

[  287.328000] invalid opcode:  [#1]
[  287.328000] SMP 
[  287.328000] CPU:0
[  287.328000] EIP:0060:[__find_get_block+376/400]Not tainted VLI
[  287.328000] EFLAGS: 00010046   (2.6.20-1-generic #3)
[  287.328000] EIP is at __find_get_block+0x178/0x190
[  287.328000] eax: 0096   ebx: 1000   ecx: 1000   edx: 00520050
[  287.328000] esi: 00a4   edi: 00520050   ebp: df8c6900   esp: f1f15c78
[  287.328000] ds: 007b   es: 007b   ss: 0068
[  287.328000] Process gcalctool (pid: 5411, ti=f1f14000 task=f2127560 
task.ti=f1f14000)
[  287.328000] Stack: 00520050  0001 0001  0002 
 000280d2 
[  287.328000]c03e2c2c 0246 0040 1000 00a4 00520050 
dfdc0a00 c01957b3 
[  287.328000]1000  c015ae7f 0044 0010 00520050 
 df8c6900 
[  287.328000] Call Trace:
[  287.328000]  [__getblk+35/688] __getblk+0x23/0x2b0
[  287.328000]  [pg0+944672526/1068770304] __ext3_get_inode_loc+0x11e/0x340 
[ext3]
[  287.328000]  [pg0+944673143/1068770304] ext3_reserve_inode_write+0x27/0x80 
[ext3]
[  287.328000]  [pg0+944673267/1068770304] ext3_mark_inode_dirty+0x23/0x50 
[ext3]
[  287.328000]  [pg0+944685961/1068770304] ext3_dirty_inode+0x79/0x90 [ext3]
[  287.328000]  [__mark_inode_dirty+52/400] __mark_inode_dirty+0x34/0x190
[  287.328000]  [__link_path_walk+3074/3696] __link_path_walk+0xc02/0xe70
[  287.328000]  [link_path_walk+69/192] link_path_walk+0x45/0xc0
[  287.328000]  [do_path_lookup+131/448] do_path_lookup+0x83/0x1c0
[  287.328000]  [__path_lookup_intent_open+81/160] 
__path_lookup_intent_open+0x51/0xa0
[  287.328000]  [path_lookup_open+32/48] path_lookup_open+0x20/0x30
[  287.328000]  [open_namei+90/1536] open_namei+0x5a/0x600
[  287.328000]  [do_filp_open+51/96] do_filp_open+0x33/0x60
[  287.328000]  [do_sys_open+78/240] do_sys_open+0x4e/0xf0
[  287.328000]  [sys_open+28/32] sys_open+0x1c/0x20
[  287.328000]  [syscall_call+7/11] syscall_call+0x7/0xb
[  287.328000]  [phys_startup_32+-120961/-1073741824] 0xb7f6bf94
[  287.328000]  ===
[  287.328000] Code: 24 08 e8 ac f4 ff ff e9 20 ff ff ff 89 d8 e8 a0 f4 ff ff 
eb 8b 89 d6 8d 56 ff 8b 04 97 85 d2 89 04 b7 75 f1 89 1f e9 f0 fe ff ff <0f> 0b 
eb fe 0f 0b eb fe 0f 0b eb fe 8d b6 00 00 00 00 8d bf 00 
[  287.328000] EIP: [__find_get_block+376/400] __find_get_block+0x178/0x190 
SS:ESP 0068:f1f15c78

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Recent mm changes leading to filesystem corruption?

[Peter Zijlstra]

On Sat, 2006-12-16 at 16:50 +0100, Martin Michlmayr wrote:
> Debian recently applied a number of mm changes that went into 2.6.19
> to their 2.6.18 kernel for LSB 3.1 compliance (msync() had problems
> before).  Since then, some filesystem corruption has been observed
> which can be traced back to these mm changes.  Is anyone aware of
> problems with these patches?

As said by Hugh, no we were not.

> The patches that were applied are:
> 
>- mm: tracking shared dirty pages
>- mm: balance dirty pages
>- mm: optimize the new mprotect() code a bit
>- mm: small cleanup of install_page()
>- mm: fixup do_wp_page()
>- mm: msync() cleanup
> 
> With these applied to 2.6.18, the Debian installer on a slow ARM
> system fails because a program segfaults due to filesystem corruption:
> http://bugs.debian.org/401980  This problem also occurs if you only
> apply the "mm: tracking shared dirty pages" patch to 2.6.18 from the
> series of 5 patches listed above.

This made me think of a blog entry by DaveM from some time ago:
  http://vger.kernel.org/~davem/cgi-bin/blog.cgi/2006/06/09

> Another problem has been reported related to libtorrent: according to
> http://bugs.debian.org/402707 someone also saw this with non-Debian
> 2.6.19 but obviously it's hard to say whether the bugs are really
> related.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394392;msg=24 shows
> some dmesg messages but again it's not 100% clear it's the same bug.
> 
> Has anyone else seen problems or is aware of a fix to the patches
> listed above that I'm unaware of?  It's possible the problem only
> shows up on slow systems. (The corruption is reproducible on a slow
> NSLU2 ARM system with 32 MB ram, but it doesn't happen on a faster ARM
> box with more RAM.)

What is not clear from all these reports is what architectures this is
seen on. I suspect some of them are i686, which together with the
explicit mention of ARM make it a cross platform issue.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/2] kill_something_info: really ignore -EPERM

[Oleg Nesterov]

kill(-1, sig) returns 0 if it has found some processes but there
is no one for which we have permission to send the signal.

Doesn't it make more sense to return -ESRCH in this case?

Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>

--- eric-mm1/kernel/signal.c~2_perm 2006-12-16 22:17:52.0 +0300
+++ eric-mm1/kernel/signal.c2006-12-16 22:22:48.0 +0300
@@ -1326,20 +1326,16 @@ static int kill_something_info(int sig, 
ret = kill_pid_info(sig, info, find_pid(pid));
} else if (pid == -1) {
struct task_struct *p;
-   int found = 0;
 
-   ret = 0;
+   ret = -ESRCH;
read_lock(&tasklist_lock);
for_each_process(p)
if (!is_init(p) && p != current->group_leader) {
int err = group_send_sig_info(sig, info, p);
if (err != -EPERM)
ret = err;
-   found = 1;
}
read_unlock(&tasklist_lock);
-   if (!found)
-   ret = -ESRCH;
} else {
struct pid *grp = task_pgrp(current);
if (pid != 0)

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

[PATCH 1/2] kill_something_info: misc cleanups

[Oleg Nesterov]

On top of
signal-rewrite-kill_something_info-so-it-uses-newer-helpers.patch

- Factor out sending PIDTYPE_PGID wide signals.

- Use is_init(p) instead of "p->pid > 1". We don't hash idle threads anymore,
  no need to worry about p->pid == 0.

- Use "p != current->group_leader" instead of "p->tgid != current->tgid",
  saves one dereference and kills yet another direct pid_t usage.

- Simplify return value calculation for "pid == -1" case, remove "retval"
  variable.

No functional changes.

Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>

--- eric-mm1/kernel/signal.c~1_ksi  2006-12-16 20:57:58.0 +0300
+++ eric-mm1/kernel/signal.c2006-12-16 22:08:43.0 +0300
@@ -1317,34 +1317,37 @@ EXPORT_SYMBOL_GPL(kill_pid_info_as_uid);
  * POSIX specifies that kill(-1,sig) is unspecified, but what we have
  * is probably wrong.  Should make it like BSD or SYSV.
  */
-
 static int kill_something_info(int sig, struct siginfo *info, int pid)
 {
int ret;
-   rcu_read_lock();
-   if (!pid) {
-   ret = kill_pgrp_info(sig, info, task_pgrp(current));
-   } else if (pid == -1) {
-   int retval = 0, count = 0;
-   struct task_struct * p;
-
-   read_lock(&tasklist_lock);
-   for_each_process(p) {
-   if (p->pid > 1 && p->tgid != current->tgid) {
-   int err = group_send_sig_info(sig, info, p);
-   ++count;
-   if (err != -EPERM)
-   retval = err;
-   }
-   }
-   read_unlock(&tasklist_lock);
-   ret = count ? retval : -ESRCH;
-   } else if (pid < 0) {
-   ret = kill_pgrp_info(sig, info, find_pid(-pid));
-   } else {
-   ret = kill_pid_info(sig, info, find_pid(pid));
-   }
-   rcu_read_unlock();
+
+   rcu_read_lock();
+   if (pid > 0) {
+   ret = kill_pid_info(sig, info, find_pid(pid));
+   } else if (pid == -1) {
+   struct task_struct *p;
+   int found = 0;
+
+   ret = 0;
+   read_lock(&tasklist_lock);
+   for_each_process(p)
+   if (!is_init(p) && p != current->group_leader) {
+   int err = group_send_sig_info(sig, info, p);
+   if (err != -EPERM)
+   ret = err;
+   found = 1;
+   }
+   read_unlock(&tasklist_lock);
+   if (!found)
+   ret = -ESRCH;
+   } else {
+   struct pid *grp = task_pgrp(current);
+   if (pid != 0)
+   grp = find_pid(-pid);
+   ret = kill_pgrp_info(sig, info, grp);
+   }
+   rcu_read_unlock();
+
return ret;
 }
 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: DVD-RAM cannot be mounted RW with 2.6.18/2.6.19

[Laurent Riffard]

Le 16.12.2006 20:55, A. Kalten a écrit :

Hello,

DVD-RAM disks previously made with a Linux system can
no longer be mounted in RW mode.  For some reason, as
indicated by the error message from the mount command,
the disks are detected as being write-protected (which
is not the case).  To be able to write to these disks,
the mount command must be issued again with the "-o remount"
option.

The commands given are as follows.  Although the file
type in this example is ext2, the same behavior is seen
also with the udf file type.

# modprobe ide-cd
# hdparm -d1 -X udma4 -k1 /dev/hde

# mount -t ext2 -o rw,noatime /dev/hde /cdrom
mount: block device /dev/hde is write-protected, mounting read-only

# mount -t ext2 -o remount,rw,noatime /dev/hde /cdrom

Now the DVD-RAM disk can be written normally, but there should
be no need for the second mount command.

The kernel log for this command sequence seems to show nothing abnormal:

kernel: hde: ATAPI 39X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(66)
kernel: Uniform CD-ROM driver Revision: 3.20
kernel: hde: CHECK for good STATUS
kernel: cdrom: hde: mrw address space DMA selected
kernel: cdrom open: mrw_status 'not mrw'

Furthermore, if I attempt to check the unmounted DVD-RAM disk with
e2fsck, the drive is still reported as read-only:

# e2fsck -p /dev/hde
e2fsck: Read-only file system while trying to open /dev/hde
Disk write-protected; use the -n option to do a read-only
check of the device.

However, as I indicated above, the disk is not write-protected.

I am reporting this problem on the lkml because of a hint
that I discovered at this link:

http://lists.opensuse.org/packet-writing/2006-10/msg0.html

Although this problem does not involve packet-writing, it may
be related to the cdrom code.


The problem I reported in the above link was related to UDF filesystem.

AFAIR, my DVD-RW have been formatted with "mkduffs --media-type=dvd",
which toggled a read-only flag at the FS level. I reformatted this DVD-RW 
with "mkudffs --media-type=dvdram" and the problem was gone.


I'm afraid this won't help you...
~~
laurent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [KORG] Re: kernel.org lies about latest -mm kernel

[Russell King]

On Sat, Dec 16, 2006 at 11:30:34AM -0800, J.H. wrote:
> The problem has been hashed over quite a bit recently, and I would be
> curious what you would consider the real problem after you see the
> situation.

One thing which isn't helping you is the way folk inevitably end up
using ftp.kernel.org rather than ftp..kernel.org. [*]

Let me illustrate why.  Throw http://ftp.uk.kernel.org/pub/linux/kernel
into a web browser.  The address changes to:

  http://ftp.uk.kernel.org/sites/ftp.kernel.org/pub/linux/kernel/

Hit reload a few times, and eventually be greated by:

Forbidden
You don't have permission to access /sites/ftp.kernel.org/pub/linux/kernel/ on 
this server.

because one of the IPs which "ftp.uk.kernel.org" resolves to isn't a
part of the UK mirror service (who are providing most of ftp.uk.kernel.org),
and therefore has a different site policy.

Ergo, downloads via http from ftp.uk.kernel.org are at best unreliable
for multiple requests.

I agree that it's not directly your problem, and isn't something you
have direct control over.  However, if you want to round-robin the
.kernel.org IP addresses between different providers, I suggest
that either the name resolves to just one site, or that kernel.org
adopts a policy with their mirrors that they only become part of
the .kernel.org DNS entries as long as they do not rewrite their
site-specific URLs in terms of that address.

IOW, that URL above should've been:

  http://hawking-if-b.mirrorservice.org/sites/ftp.kernel.org/pub/linux/kernel/

to ensure that mirrorservice.org's policy isn't uselessly applied to
someone elses mirror site.

Maybe then ftp..kernel.org would become slightly more attractive.

* - I gave up with ftp.uk.kernel.org many years ago when it became
unreliable and haven't looked back, despite recent news that it's
improved.  But as illustrated above it does still have issues.  I
certainly would _not_ want to use ftp.uk.linux.org to obtain GIT
updates from as long as the current DNS situation persists - that
would be suicide.

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

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Jan Engelhardt]

On Dec 16 2006 15:13, Lee Revell wrote:
>On Thu, 2006-12-14 at 18:02 +0100, Jan Engelhardt wrote:
>> 
>> They use floating point in (Windows) kernelspace? Oh my.
>
>Yes, definitely.

Explains why Windows is so slow ;-) [FPU restore and stuff...]

On that matter, when does the Linux kernel do proper FPU handling? At context
switches? If so, would not that make a kthread fpu-capable?

>For example lots of Windows sound drivers do AC3 decoding in kernelspace.
>Of course the vendors usually lie and say it's done in hardware...

They don't need to lie, the user buys it anyway...


-`J'
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] kill_pid_info: kill acquired_tasklist_lock

[Oleg Nesterov]

Kill acquired_tasklist_lock, sig_needs_tasklist() is very cheap nowadays.

Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>

--- eric-mm1/kernel/signal.c~3_kpi  2006-12-16 22:22:48.0 +0300
+++ eric-mm1/kernel/signal.c2006-12-16 23:14:05.0 +0300
@@ -1247,19 +1247,18 @@ int kill_pgrp_info(int sig, struct sigin
 int kill_pid_info(int sig, struct siginfo *info, struct pid *pid)
 {
int error;
-   int acquired_tasklist_lock = 0;
struct task_struct *p;
 
rcu_read_lock();
-   if (unlikely(sig_needs_tasklist(sig))) {
+   if (unlikely(sig_needs_tasklist(sig)))
read_lock(&tasklist_lock);
-   acquired_tasklist_lock = 1;
-   }
+
p = pid_task(pid, PIDTYPE_PID);
error = -ESRCH;
if (p)
error = group_send_sig_info(sig, info, p);
-   if (unlikely(acquired_tasklist_lock))
+
+   if (unlikely(sig_needs_tasklist(sig)))
read_unlock(&tasklist_lock);
rcu_read_unlock();
return error;

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Theodore Tso]

On Sat, Dec 16, 2006 at 05:30:31PM +0100, Willy Tarreau wrote:
> I don't think this is the same case. The film _author_'s primary goal is
> to have a lot of families buy his DVD to watch it. Whatever the MPAA says,
> I can consider it "fair use" if a family of 4..8 persons watch the DVD at
> the same time. 

"You can consider it"?  But you're not the author.  This is the
hypocrisy that Linus was talking about.  At the same time that you're
trying to dictate to other other people can use their copy of the
Linux kernel, when it comes to others people's copyrighted work, you
feel to dictate what is and isn't "fair use".

That's the big thing about dynamic linking.  The GPL has always said
it is about distribution, not about use.  The dynamic linking of a
kernel module happens in the privacy of someone's home.  When we try
to dictate what people are doing in the privacy in their home, we're
no better than the MPAA or the RIAA.  

As far as whether or not someone is allowed to distribute a binary
module that can be linked into the Linux kernel, that's a question of
whether the binary module is a derived work or not.  And that's not up
to us, that's up to the local laws.  But before you decide that you
want the most extreme form of anything that wanders close to one
person's code or header files is a derived work, and to start going to
work lobbying your local legislature, recall that there have been
those who have claimed that Linux is a derived work of Unix because we
used things like #define's for errno codes and structure definitions
of ELF binaries.  You really sure you want to go there?

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

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Lee Revell]

On Thu, 2006-12-14 at 18:02 +0100, Jan Engelhardt wrote:
> On Dec 14 2006 10:56, Hans-Jürgen Koch wrote:
> >
> >A small German manufacturer produces high-end AD converter cards. He sells
> >100 pieces per year, only in Germany and only with Windows drivers. He would
> >now like to make his cards work with Linux. He has two driver programmers
> >with little experience in writing Linux kernel drivers. What do you tell him?
> >Write a large kernel module from scratch? Completely rewrite his code 
> >because it uses floating point arithmetics?
> 
> They use floating point in (Windows) kernelspace? Oh my.

Yes, definitely.  For example lots of Windows sound drivers do AC3
decoding in kernelspace.  Of course the vendors usually lie and say it's
done in hardware...

Lee

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

Re: [KORG] Re: kernel.org lies about latest -mm kernel

[J.H.]

The problem has been hashed over quite a bit recently, and I would be
curious what you would consider the real problem after you see the
situation.

The root cause boils down to with git, gitweb and the normal mirroring
on the frontend machines our basic working set no longer stays resident
in memory, which is forcing more and more to actively go to disk causing
a much higher I/O load.  You have the added problem that one of the
frontend machines is getting hit harder than the other due to several
factors: various DNS servers not round robining, people explicitly
hitting [git|mirrors|www|etc]1 instead of 2 for whatever reason and
probably several other factors we aren't aware of.  This has caused the
average load on that machine to hover around 150-200 and if for whatever
reason we have to take one of the machines down the load on the
remaining machine will skyrocket to 2000+.  

Since it's apparent not everyone is aware of what we are doing, I'll
mention briefly some of the bigger points.

- We have contacted HP to see if we can get additional hardware, mind
you though this is a long term solution and will take time, but if our
request is approved it will double the number of machines kernel.org
runs.

- Gitweb is causing us no end of headache, there are (known to me
anyway) two different things happening on that.  I am looking at Jeff
Garzik's suggested caching mechanism as a temporary stop-gap, with an
eye more on doing a rather heavy re-write of gitweb itself to include
semi-intelligent caching.  I've already started in on the later - and I
just about have the caching layer put in.  But this is still at least a
week out before we could even remotely consider deploying it.

- We've cut back on the number of ftp and rsync users to the machines.
Basically we are cutting back where we can in an attempt to keep the
load from spiraling out of control, this helped a bit when we recently
had to take one of the machines down and instead of loads spiking into
the 2000+ range we peaked at about 500-600 I believe.

So we know the problem is there, and we are working on it - we are
getting e-mails about it if not daily than every other day or so.  If
there are suggestions we are willing to hear them - but the general
feeling with the admins is that we are probably hitting the biggest
problems already.

- John 'Warthog9' Hawley
Kernel.org Admin

On Sat, 2006-12-16 at 10:02 -0800, Randy Dunlap wrote:
> Andrew Morton wrote:
> > On Sat, 16 Dec 2006 09:44:21 -0800
> > Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > 
> >> On Thu, 14 Dec 2006 23:37:18 +0100 Pavel Machek wrote:
> >>
> >>> Hi!
> >>>
> >>> [EMAIL PROTECTED]:/data/pavel$ finger @www.kernel.org
> >>> [zeus-pub.kernel.org]
> >>> ...
> >>> The latest -mm patch to the stable Linux kernels is: 2.6.19-rc6-mm2
> >>> [EMAIL PROTECTED]:/data/pavel$ head /data/l/linux-mm/Makefile
> >>> VERSION = 2
> >>> PATCHLEVEL = 6
> >>> SUBLEVEL = 19
> >>> EXTRAVERSION = -mm1
> >>> ...
> >>> [EMAIL PROTECTED]:/data/pavel$
> >>>
> >>> AFAICT 2.6.19-mm1 is newer than 2.6.19-rc6-mm2, but kernel.org does
> >>> not understand that.
> >> Still true (not listed) for 2.6.20-rc1-mm1  :(
> >>
> >> Could someone explain what the problem is and what it would
> >> take to correct it?
> > 
> > 2.6.20-rc1-mm1 still hasn't propagated out to the servers (it's been 36
> > hours).  Presumably the front page non-update is a consequence of that.
> 
> Agreed on the latter part.  Can someone address the real problem???
> 

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

DVD-RAM cannot be mounted RW with 2.6.18/2.6.19

[A. Kalten]

Hello,

DVD-RAM disks previously made with a Linux system can
no longer be mounted in RW mode.  For some reason, as
indicated by the error message from the mount command,
the disks are detected as being write-protected (which
is not the case).  To be able to write to these disks,
the mount command must be issued again with the "-o remount"
option.

The commands given are as follows.  Although the file
type in this example is ext2, the same behavior is seen
also with the udf file type.

# modprobe ide-cd
# hdparm -d1 -X udma4 -k1 /dev/hde

# mount -t ext2 -o rw,noatime /dev/hde /cdrom
mount: block device /dev/hde is write-protected, mounting read-only

# mount -t ext2 -o remount,rw,noatime /dev/hde /cdrom

Now the DVD-RAM disk can be written normally, but there should
be no need for the second mount command.

The kernel log for this command sequence seems to show nothing abnormal:

kernel: hde: ATAPI 39X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(66)
kernel: Uniform CD-ROM driver Revision: 3.20
kernel: hde: CHECK for good STATUS
kernel: cdrom: hde: mrw address space DMA selected
kernel: cdrom open: mrw_status 'not mrw'

Furthermore, if I attempt to check the unmounted DVD-RAM disk with
e2fsck, the drive is still reported as read-only:

# e2fsck -p /dev/hde
e2fsck: Read-only file system while trying to open /dev/hde
Disk write-protected; use the -n option to do a read-only
check of the device.

However, as I indicated above, the disk is not write-protected.

I am reporting this problem on the lkml because of a hint
that I discovered at this link:

http://lists.opensuse.org/packet-writing/2006-10/msg0.html

Although this problem does not involve packet-writing, it may
be related to the cdrom code.

Andrew Kalten

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/10] cxgb3, p2

[Jan Engelhardt]

> A corresponding monolithic patch is posted at the following URL:
> http://service.chelsio.com/kernel.org/cxgb3.patch.bz2

Stylistic stuff that was mentioned. (TYPE * a  -> TYPE *a)

Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>

Index: linux-2.6.20-rc1/drivers/net/cxgb3/common.h
===
--- linux-2.6.20-rc1.orig/drivers/net/cxgb3/common.h
+++ linux-2.6.20-rc1/drivers/net/cxgb3/common.h
@@ -139,10 +139,10 @@ struct cphy;
 struct adapter;
 
 struct mdio_ops {
-   int (*read) (struct adapter * adapter, int phy_addr, int mmd_addr,
-int reg_addr, unsigned int *val);
-   int (*write) (struct adapter * adapter, int phy_addr, int mmd_addr,
- int reg_addr, unsigned int val);
+   int (*read)(struct adapter *adapter, int phy_addr, int mmd_addr,
+   int reg_addr, unsigned int *val);
+   int (*write)(struct adapter *adapter, int phy_addr, int mmd_addr,
+int reg_addr, unsigned int val);
 };
 
 struct adapter_info {
@@ -158,8 +158,8 @@ struct adapter_info {
 };
 
 struct port_type_info {
-   void (*phy_prep) (struct cphy * phy, struct adapter * adapter,
- int phy_addr, const struct mdio_ops * ops);
+   void (*phy_prep)(struct cphy *phy, struct adapter *adapter,
+int phy_addr, const struct mdio_ops *ops);
unsigned int caps;
const char *desc;
 };
@@ -476,23 +476,23 @@ enum {
 
 /* PHY operations */
 struct cphy_ops {
-   void (*destroy) (struct cphy * phy);
-   int (*reset) (struct cphy * phy, int wait);
+   void (*destroy)(struct cphy *phy);
+   int (*reset)(struct cphy *phy, int wait);
 
-   int (*intr_enable) (struct cphy * phy);
-   int (*intr_disable) (struct cphy * phy);
-   int (*intr_clear) (struct cphy * phy);
-   int (*intr_handler) (struct cphy * phy);
-
-   int (*autoneg_enable) (struct cphy * phy);
-   int (*autoneg_restart) (struct cphy * phy);
-
-   int (*advertise) (struct cphy * phy, unsigned int advertise_map);
-   int (*set_loopback) (struct cphy * phy, int mmd, int dir, int enable);
-   int (*set_speed_duplex) (struct cphy * phy, int speed, int duplex);
-   int (*get_link_status) (struct cphy * phy, int *link_ok, int *speed,
-   int *duplex, int *fc);
-   int (*power_down) (struct cphy * phy, int enable);
+   int (*intr_enable)(struct cphy *phy);
+   int (*intr_disable)(struct cphy *phy);
+   int (*intr_clear)(struct cphy *phy);
+   int (*intr_handler)(struct cphy *phy);
+
+   int (*autoneg_enable)(struct cphy *phy);
+   int (*autoneg_restart)(struct cphy *phy);
+
+   int (*advertise)(struct cphy *phy, unsigned int advertise_map);
+   int (*set_loopback)(struct cphy *phy, int mmd, int dir, int enable);
+   int (*set_speed_duplex)(struct cphy *phy, int speed, int duplex);
+   int (*get_link_status)(struct cphy *phy, int *link_ok, int *speed,
+  int *duplex, int *fc);
+   int (*power_down)(struct cphy *phy, int enable);
 };
 
 /* A PHY instance */
@@ -501,10 +501,10 @@ struct cphy {
struct adapter *adapter;/* associated adapter */
unsigned long fifo_errors;  /* FIFO over/under-flows */
const struct cphy_ops *ops; /* PHY operations */
-   int (*mdio_read) (struct adapter * adapter, int phy_addr, int mmd_addr,
- int reg_addr, unsigned int *val);
-   int (*mdio_write) (struct adapter * adapter, int phy_addr, int mmd_addr,
-  int reg_addr, unsigned int val);
+   int (*mdio_read)(struct adapter *adapter, int phy_addr, int mmd_addr,
+int reg_addr, unsigned int *val);
+   int (*mdio_write)(struct adapter *adapter, int phy_addr, int mmd_addr,
+ int reg_addr, unsigned int val);
 };
 
 /* Convenience MDIO read/write wrappers */
Index: linux-2.6.20-rc1/drivers/net/cxgb3/cxgb3_main.c
===
--- linux-2.6.20-rc1.orig/drivers/net/cxgb3/cxgb3_main.c
+++ linux-2.6.20-rc1/drivers/net/cxgb3/cxgb3_main.c
@@ -1479,7 +1479,7 @@ static int in_range(int val, int lo, int
return val < 0 || (val <= hi && val >= lo);
 }
 
-static int cxgb_extension_ioctl(struct net_device *dev, void __user * useraddr)
+static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
 {
int ret;
u32 cmd;
Index: linux-2.6.20-rc1/drivers/net/cxgb3/cxgb3_offload.h
===
--- linux-2.6.20-rc1.orig/drivers/net/cxgb3/cxgb3_offload.h
+++ linux-2.6.20-rc1/drivers/net/cxgb3/cxgb3_offload.h
@@ -64,16 +64,16 @@ void cxgb3_unregister_client(struct cxgb
 void cxgb3_add_clients(struct t3cdev *tdev);
 void cxgb3_remove_clients(struct t3cdev *tdev);
 
-typedef int (*cxgb3_cpl

Re: [PATCH 0/10] cxgb3, p1

[Jan Engelhardt]

> I resubmit the patch supporting the latest Chelsio T3 adapter.
> It incorporates the last feedbacks for code cleanup.
> It is built gainst Linus'tree.
>
> We think the driver is now ready to be merged.
> Can you please advise on the next steps for inclusion in 2.6.20 ?
>
> A corresponding monolithic patch is posted at the following URL:
> http://service.chelsio.com/kernel.org/cxgb3.patch.bz2
>
> This driver is required by the Chelsio T3 RDMA driver
> which was updated on 12/10/2006.

Here are some extras that you could source (but don't require a 
resubmit)



---

Cleanup.
Not all unnecessary casts are gone

  - (void)cmpxchg stayed to silence a warning

  - some (u32) in t3_hw.c remain because it's not just an ugly cast,
but also a truncation. Taking away (u32) without verifying that
it is invariant with an implicit truncation is not good (and
I was lazy at verifying it)

Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>

Index: linux-2.6.20-rc1/drivers/net/cxgb3/xgmac.c
===
--- linux-2.6.20-rc1.orig/drivers/net/cxgb3/xgmac.c
+++ linux-2.6.20-rc1/drivers/net/cxgb3/xgmac.c
@@ -25,7 +25,7 @@ static inline int macidx(const struct cm
 
 static void xaui_serdes_reset(struct cmac *mac)
 {
-   static unsigned int clear[] = {
+   static const unsigned int clear[] = {
F_PWRDN0 | F_PWRDN1, F_RESETPLL01, F_RESET0 | F_RESET1,
F_PWRDN2 | F_PWRDN3, F_RESETPLL23, F_RESET2 | F_RESET3
};
@@ -38,7 +38,7 @@ static void xaui_serdes_reset(struct cma
 F_RESET3 | F_RESET2 | F_RESET1 | F_RESET0 |
 F_PWRDN3 | F_PWRDN2 | F_PWRDN1 | F_PWRDN0 |
 F_RESETPLL23 | F_RESETPLL01);
-   (void)t3_read_reg(adap, ctrl);
+   t3_read_reg(adap, ctrl);
udelay(15);
 
for (i = 0; i < ARRAY_SIZE(clear); i++) {
@@ -80,7 +80,7 @@ int t3_mac_reset(struct cmac *mac)
unsigned int oft = mac->offset;
 
t3_write_reg(adap, A_XGM_RESET_CTRL + oft, F_MAC_RESET_);
-   (void)t3_read_reg(adap, A_XGM_RESET_CTRL + oft);/* flush */
+   t3_read_reg(adap, A_XGM_RESET_CTRL + oft);  /* flush */
 
t3_write_regs(adap, mac_reset_avp, ARRAY_SIZE(mac_reset_avp), oft);
t3_set_reg_field(adap, A_XGM_RXFIFO_CFG + oft,
@@ -115,7 +115,7 @@ int t3_mac_reset(struct cmac *mac)
else
val |= F_RGMII_RESET_ | F_XG2G_RESET_;
t3_write_reg(adap, A_XGM_RESET_CTRL + oft, val);
-   (void)t3_read_reg(adap, A_XGM_RESET_CTRL + oft);/* flush */
+   t3_read_reg(adap, A_XGM_RESET_CTRL + oft);  /* flush */
if ((val & F_PCS_RESET_) && adap->params.rev) {
msleep(1);
t3b_pcs_reset(mac);
Index: linux-2.6.20-rc1/drivers/net/cxgb3/sge.c
===
--- linux-2.6.20-rc1.orig/drivers/net/cxgb3/sge.c
+++ linux-2.6.20-rc1/drivers/net/cxgb3/sge.c
@@ -2160,7 +2160,7 @@ static irqreturn_t t3_intr(int irq, void
 
if (likely(w0 | w1)) {
t3_write_reg(adap, A_PL_CLI, 0);
-   (void)t3_read_reg(adap, A_PL_CLI);  /* flush */
+   t3_read_reg(adap, A_PL_CLI);/* flush */
 
if (likely(w0))
process_responses_gts(adap, q0);
Index: linux-2.6.20-rc1/drivers/net/cxgb3/t3_hw.c
===
--- linux-2.6.20-rc1.orig/drivers/net/cxgb3/t3_hw.c
+++ linux-2.6.20-rc1/drivers/net/cxgb3/t3_hw.c
@@ -15,7 +15,7 @@
 #include "firmware_exports.h"
 
  /**
- * t3_wait_op_done_val - wait until an operation is completed
+  *t3_wait_op_done_val - wait until an operation is completed
   *@adapter: the adapter performing the operation
   *@reg: the register to check for completion
   *@mask: a single-bit field within @reg that indicates completion
@@ -84,7 +84,7 @@ void t3_set_reg_field(struct adapter *ad
u32 v = t3_read_reg(adapter, addr) & ~mask;
 
t3_write_reg(adapter, addr, v | val);
-   (void)t3_read_reg(adapter, addr);   /* flush */
+   t3_read_reg(adapter, addr); /* flush */
 }
 
 /**
@@ -526,7 +526,7 @@ int t3_seeprom_read(struct adapter *adap
if ((addr >= EEPROMSIZE && addr != EEPROM_STAT_ADDR) || (addr & 3))
return -EINVAL;
 
-   pci_write_config_word(adapter->pdev, base + PCI_VPD_ADDR, (u16) addr);
+   pci_write_config_word(adapter->pdev, base + PCI_VPD_ADDR, addr);
do {
udelay(10);
pci_read_config_word(adapter->pdev, base + PCI_VPD_ADDR, &val);
@@ -562,7 +562,7 @@ int t3_seeprom_write(struct adapter *ada
pci_write_config_dword(adapter->pdev, base + PCI_VPD_DATA,
   cpu_to_le32(data));
pci_write_config_word(adapter->pdev,base + PCI_VPD_ADDR,
- (u16)addr | PCI_VPD_ADDR_F);
+ 

Re: 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18

[Lee Garrett]

Andrey Borzenkov wrote:
> [...]
This is rather funny; in 2.6.19-rc5 grub is *really* slow loading kernel when 
I switch on the system after suspend to disk. Actually, after kernel has been 
loaded, the whole resuming (up to the point I have usable desktop again) 
takes about three time less than the process of loading kernel + initrd. 
During loading disk LED is constantly lit. This almost looks like kernel 
leaves HDD in some strange state, although I always assumed HDD/IDE is 
completely reinitialized in this case.

> [...]

I had the same problem (/boot on reiserfs, grub hanging for ages 
after resume with 2.6.19), but in 2.6.19.1 it seems fixed. Do you 
still have this bug, Andrey? I didn't find an update on this issue 
on LKML.


Greetings, Lee

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

[-mm patch] noinitramfs cleanup

[Frederik Deweerdt]

On Thu, Dec 14, 2006 at 10:59:13PM -0800, Andrew Morton wrote:
>   
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/
> 
> +disable-init-initramfsc-updated.patch


Jean-Paul,

The following patch silences the following compile time warning introduced
by the disable-init-initramfsc-updated patch:

  CC  init/noinitramfs.o
  init/noinitramfs.c:42: warning : initialization from incompatible pointer type

In addition, I've cleaned up the headers and added some error handling.

Regards,
Frederik

Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>

diff --git a/init/noinitramfs.c b/init/noinitramfs.c
index 01f88c3..f4c1a3a 100644
--- a/init/noinitramfs.c
+++ b/init/noinitramfs.c
@@ -18,25 +18,35 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
  */
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
+#include 
+#include 
 #include 
 
 /*
  * Create a simple rootfs that is similar to the default initramfs
  */
-static void __init default_rootfs(void)
+static int __init default_rootfs(void)
 {
-   int mkdir_err = sys_mkdir("/dev", 0755);
-   int err = sys_mknod((const char __user *) "/dev/console",
-   S_IFCHR | S_IRUSR | S_IWUSR,
-   new_encode_dev(MKDEV(5, 1)));
-   if (err == -EROFS)
-   printk("Warning: Failed to create a rootfs\n");
-   mkdir_err = sys_mkdir("/root", 0700);
+   int err;
+
+   err = sys_mkdir("/dev", 0755);
+   if (err < 0)
+   goto out;
+
+   err = sys_mknod((const char __user *) "/dev/console",
+   S_IFCHR | S_IRUSR | S_IWUSR,
+   new_encode_dev(MKDEV(5, 1)));
+   if (err < 0)
+   goto out;
+
+   err = sys_mkdir("/root", 0700);
+   if (err < 0)
+   goto out;
+
+   return 0;
+
+out:
+   printk(KERN_WARNING "Failed to create a rootfs\n");
+   return err;
 }
 rootfs_initcall(default_rootfs);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: pata_marvell and Marvell 88SE6121

[Alan]

On Sat, 16 Dec 2006 18:41:26 +0100
Jose Alberto Reguero <[EMAIL PROTECTED]> wrote:

> I am trying to make work the driver pata_marvell of linux-2.6.20-rc1 with 
> Marvell 88SE6121.

The 6121 is I believe ahci.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: cxgb3 and 2.6.20-rc1

[Jan Engelhardt]

Hi,


On Dec 13 2006 21:40, Divy Le Ray wrote:
>
> A corresponding monolithic patch is posted at the following URL:
> http://service.chelsio.com/kernel.org/cxgb3.patch.bz2

I was unable to compile this on 2.6.20-rc1, because:

  CC [M]  drivers/net/cxgb3/cxgb3_offload.o
drivers/net/cxgb3/cxgb3_offload.c: In function ‘cxgb_free_mem’:
drivers/net/cxgb3/cxgb3_offload.c:1004: error: ‘PKMAP_BASE’ undeclared 
(first use in this function)

However, line 1004 is:

if (p >= VMALLOC_START && p < VMALLOC_END)

and include/asm/pgtable.h:

#ifdef CONFIG_HIGHMEM
# define VMALLOC_END(PKMAP_BASE-2*PAGE_SIZE)
#else
# define VMALLOC_END(FIXADDR_START-2*PAGE_SIZE)
#endif

So include/asm/pgtable.h lacks inclusion of include/asm/highmem.h,
where PKMAP_BASE is defined. Adding it gives me more compile errors.
Not good. Does anyone have a patch to fix that?


-`J'
-- 

Re: 2.6.19 file content corruption on ext3

[Hugh Dickins]

On Sat, 16 Dec 2006, Martin Michlmayr wrote:
> * Marc Haber <[EMAIL PROTECTED]> [2006-12-09 10:26]:
> > Unfortunately, I am lacking the knowledge needed to do this in an
> > informed way. I am neither familiar enough with git nor do I possess
> > the necessary C powers.
> 
> I wonder if what you're seein is related to
> http://lkml.org/lkml/2006/12/16/73
> 
> You said that you don't see any corruption with 2.6.18.  Can you try
> to apply the patch from
> http://www2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d08b3851da41d0ee60851f2c75b118e1f7a5fc89
> to 2.6.18 to see if the corruption shows up?

I did wonder about the very first hunk of Peter's patch, where the
mapping->private_lock is unlocked earlier now in try_to_free_buffers,
before the clear_page_dirty.  I'm not at all familiar with that area,
I wonder if Jan has looked at that change, and might be able to say
whether it's good or not (earlier he worried about his JBD changes,
but they wouldn't be implicated if just 2.6.18+Peter's gives trouble).

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

[ANN] Acrypto asynchronous crypto layer 2.6.19 release.

[Evgeniy Polyakov]

Hello.

I am pleased to announce new release of the acrypto for 2.6.19 kernel -
first asynchronous crypto layer for Linux kernel 2.6.

Acrypto allows to handle crypto requests asynchronously in hardware.

Acrypto supports following features:
 * multiple asynchronous crypto device queues
 * crypto session routing (allows to complete single crypto session when
   several operations (crypto, hmac, anything) are completed)
 * crypto session binding (bind crypto processing to specified device)
 * modular load balancing (one can created load balancer which will get
   into account for example pid of the calling process)
 * crypto session batching genetically implemented by design (acrypto
   provides the whole data structure to crypto device, i.e. it is
   possible to use acrypto as a bridge which routes requests between
   completely different devices, since it does not differentiate between
   users, just handles requests)
 * crypto session priority
 * different kinds of crypto operation(RNG, asymmetrical crypto, HMAC and
   any other)

Combined patchset includes:
 * acrypto core
 * IPsec ESP4 port to acrypto
 * dm-crypt port to acrypto
 * OCF to acrypto bridge, which allows to run OCF device
   drivers with acrypto (for example ixp4xx), requires OCF installed.

Ported crypto drivers and benchmarks can be found on acrypto homepage:
http://tservice.net.ru/~s0mbre/old/?section=projects&item=acrypto

Changes from previous release:
 * moved to 2.6.19 crypto API where it is used
 * updated XFRM engine
 * bugfixes

2.6.16 - 2.6.18 releases moved to maintenance mode.

Patchset is not attached due to its size (192kb).

Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>

-- 
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Recent mm changes leading to filesystem corruption?

[Hugh Dickins]

On Sat, 16 Dec 2006, Martin Michlmayr wrote:
> * Hugh Dickins <[EMAIL PROTECTED]> [2006-12-16 18:20]:
> > Very disturbing.  I'm not aware of any problem with them, and we
> > surely wouldn't have released 2.6.19 with any known-corrupting patches
> > in.  There's some doubts about 2.6.19 itself in the links below: were
> > it not for those, I'd suspect a mismerge of the pieces into 2.6.18,
> > perhaps a hidden dependency on something else.  I'll ponder a little,
> > but let's CC linux-mm in case someone there has an idea.
> 
> Do you think http://article.gmane.org/gmane.linux.kernel/473710 might
> be related?

Sounds like it.  Let's CC Jan Kara on your other thread,
he seems to have delved into it a little.

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

Re: [patch] scrub non-__GLIBC__ checks in linux/socket.h and linux/stat.h

[Erik Andersen]

On Sat Dec 16, 2006 at 01:42:11PM -0500, Mike Frysinger wrote:
> On 11/30/06, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
> >but there are a few other
> >cases which still contain compound preprocessor directives such as:
> >
> >  #if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2)
> >
> >having never worked with unifdef before, i guess i was being overly
> >optimistic in thinking that it, if i "unifdef"ed __KERNEL__, it might
> >at least simplify the expression.  oh, well ... live and learn.
> 
> userspace should be worrying about userspace, so having the socket.h
> and stat.h pollute the namespace in the non-glibc case is wrong and
> pretty much prevents any other libc from utilizing these headers
> sanely unless they set up the __GLIBC__ define themselves (which
> sucks)
> -mike

Ack from me.  I'd love to see this applied so uClibc could
stop have to define __GLIBC__

 -Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.19 file content corruption on ext3

[Florian Weimer]

* Marc Haber:

> After updating to 2.6.19, Debian's apt control file
> /var/cache/apt/pkgcache.bin corrupts pretty frequently - like in under
> six hours.

I've seen that with Debian's 2.6.18 kernels as well.  Perhaps it's
related to this Debian bug?


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

Re: 2.6.19 file content corruption on ext3

[Martin Michlmayr]

* Marc Haber <[EMAIL PROTECTED]> [2006-12-09 10:26]:
> Unfortunately, I am lacking the knowledge needed to do this in an
> informed way. I am neither familiar enough with git nor do I possess
> the necessary C powers.

I wonder if what you're seein is related to
http://lkml.org/lkml/2006/12/16/73

You said that you don't see any corruption with 2.6.18.  Can you try
to apply the patch from
http://www2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d08b3851da41d0ee60851f2c75b118e1f7a5fc89
to 2.6.18 to see if the corruption shows up?
-- 
Martin Michlmayr
[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: 2.6.18 mmap hangs unrelated apps

[Christian Kuhn]

Hi,

I enabled some kernel hacking options on 2.6.20-rc1 and ran sysrq t when
the problem occured.

Some hopefully usefull information in the links below: .config, dmesg,
vmstat and vmstat -m. Sorry for the links, I do not know what is
relevant and this is too much to inline for this list (is it?)


http://www.lollingola.de/kernel/dmesg
http://www.lollingola.de/kernel/vmstat
http://www.lollingola.de/kernel/vmstat-m
http://www.lollingola.de/kernel/config-2.6.20-rc1


Christian

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

Re: Recent mm changes leading to filesystem corruption?

[Martin Michlmayr]

* Hugh Dickins <[EMAIL PROTECTED]> [2006-12-16 18:20]:
> Very disturbing.  I'm not aware of any problem with them, and we
> surely wouldn't have released 2.6.19 with any known-corrupting patches
> in.  There's some doubts about 2.6.19 itself in the links below: were
> it not for those, I'd suspect a mismerge of the pieces into 2.6.18,
> perhaps a hidden dependency on something else.  I'll ponder a little,
> but let's CC linux-mm in case someone there has an idea.

Do you think http://article.gmane.org/gmane.linux.kernel/473710 might
be related?
-- 
Martin Michlmayr
http://www.cyrius.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] scrub non-__GLIBC__ checks in linux/socket.h and linux/stat.h

[Mike Frysinger]

On 11/30/06, Robert P. J. Day <[EMAIL PROTECTED]> wrote:

but there are a few other
cases which still contain compound preprocessor directives such as:

  #if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2)

having never worked with unifdef before, i guess i was being overly
optimistic in thinking that it, if i "unifdef"ed __KERNEL__, it might
at least simplify the expression.  oh, well ... live and learn.


userspace should be worrying about userspace, so having the socket.h
and stat.h pollute the namespace in the non-glibc case is wrong and
pretty much prevents any other libc from utilizing these headers
sanely unless they set up the __GLIBC__ define themselves (which
sucks)
-mike


linux-scrub-GLIBC-ifdefs.patch
Description: Binary data

Re: [PATCH][2.6.20-rc1-mm1] sparsemem vmem_map optimzed pfn_valid() [0/2]

[Christoph Lameter]

On Sat, 16 Dec 2006, KAMEZAWA Hiroyuki wrote:

> By this, we'll not access mem_section[] in usual ops.

Why do we need mem_section? We have a page table that fulfills the same 
role.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Recent mm changes leading to filesystem corruption?

[Hugh Dickins]

On Sat, 16 Dec 2006, Martin Michlmayr wrote:

> Debian recently applied a number of mm changes that went into 2.6.19
> to their 2.6.18 kernel for LSB 3.1 compliance (msync() had problems
> before).  Since then, some filesystem corruption has been observed
> which can be traced back to these mm changes.  Is anyone aware of
> problems with these patches?

Very disturbing.  I'm not aware of any problem with them, and we
surely wouldn't have released 2.6.19 with any known-corrupting patches
in.  There's some doubts about 2.6.19 itself in the links below: were
it not for those, I'd suspect a mismerge of the pieces into 2.6.18,
perhaps a hidden dependency on something else.  I'll ponder a little,
but let's CC linux-mm in case someone there has an idea.

Hugh

> 
> The patches that were applied are:
> 
>- mm: tracking shared dirty pages
>- mm: balance dirty pages
>- mm: optimize the new mprotect() code a bit
>- mm: small cleanup of install_page()
>- mm: fixup do_wp_page()
>- mm: msync() cleanup
> 
> With these applied to 2.6.18, the Debian installer on a slow ARM
> system fails because a program segfaults due to filesystem corruption:
> http://bugs.debian.org/401980  This problem also occurs if you only
> apply the "mm: tracking shared dirty pages" patch to 2.6.18 from the
> series of 5 patches listed above.
> 
> Another problem has been reported related to libtorrent: according to
> http://bugs.debian.org/402707 someone also saw this with non-Debian
> 2.6.19 but obviously it's hard to say whether the bugs are really
> related.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394392;msg=24 shows
> some dmesg messages but again it's not 100% clear it's the same bug.
> 
> Has anyone else seen problems or is aware of a fix to the patches
> listed above that I'm unaware of?  It's possible the problem only
> shows up on slow systems. (The corruption is reproducible on a slow
> NSLU2 ARM system with 32 MB ram, but it doesn't happen on a faster ARM
> box with more RAM.)
> -- 
> Martin Michlmayr
> http://www.cyrius.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] drivers/video/{s3fb,svgalib}.c: possible cleanups

[Ondrej Zajicek]

On Sat, Dec 16, 2006 at 02:56:57PM +0100, Adrian Bunk wrote:
> This patch contains the following possible cleanups:
> - CodingStyle:
>   - opening braces of functions at the beginning of the next line
>   - C99 struct initializers
> - make the following needlessly global functions static:
>   - s3fb.c: s3fb_settile()
>   - s3fb.c: s3fb_tilecopy()
>   - s3fb.c: s3fb_tilefill()
>   - s3fb.c: s3fb_tileblit()
>   - s3fb.c: s3fb_tilecursor()
>   - s3fb.c: s3fb_init()
>   - svgalib.c: svga_regset_size()
> - #if 0 the following unused global functions:
>   - svga_wseq_multi()
>   - svga_dump_var()
> 
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

Acked-by: Ondrej Zajicek <[EMAIL PROTECTED]>

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: [EMAIL PROTECTED], jabber: [EMAIL PROTECTED])
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.20-rc1] fix vm_events_fold_cpu() build breakage

[Christoph Lameter]

On Fri, 15 Dec 2006, Magnus Damm wrote:

> fix vm_events_fold_cpu() build breakage

Acked-by: Christoph Lameter <[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: [Fwd: escape key]

[Jan Engelhardt]

On Dec 16 2006 08:45, Pavel Machek wrote:
>
>> Two escapes works now. :-)
>
>Actually could we fix our consoles, somehow, to make esc usable?
>Having important key like esc unusable on consoles is quite ugly.

It's something between a misdesign and a misconfiguration of the ESC key.

In other words, many unices make ESC generate ^[, the general
terminal escape character that is _also_ generated by keys like "up",
^[[A.

MS-DOS, or rather QBASIC's, Turbo BASIC's and other implementation of
keys, does not have this "bug": here ESC generates "\x1B" and "up"
generates "\x00H" IIRC. There is no key defined to generate "\x00".
=> All fits nicely.

So I see two steps:

 - making ESC generate something else than ^[, or making function
   keys do something else

 - fixing the terminfo description and the xterms

 - possibly creating a new termtype ("linux2" or "xterm2") so as to
   not tamper with compatibility

Then text-console graphic applications (ncurses, slang, etc.) would
not need to wait the defined one second for an escape sequence to
complete.

HOWEVER, unix people probably _had a reason_ to make ESC generate
part of what function keys do. Should my UP key go broke, I could
still - though probably tedious - reproduce it by hitting the three
keys ESC [ A. Problem, as pointed out, is that ESC has long been used
by the majority of people back then for something else than doing
terminal sequences by hand: DOS, apps, games, Windows GUIs, and,
I suppose, even X11.



-`J'
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Dave Jones]

On Sat, Dec 16, 2006 at 09:20:15AM -0800, Linus Torvalds wrote:

 > Anything else, you have to make some really scary decisions. Can a judge 
 > decide that a binary module is a derived work even though you didn't 
 > actually use any code? The real answer is: HELL YES. It's _entirely_ 
 > possible that a judge would find NVidia and ATI in violation of the GPLv2 
 > with their modules.

ATI in particular, I'm amazed their lawyers OK'd stuff like..

+ifdef STANDALONE
 MODULE_LICENSE(GPL);
+endif

This a paraphrased diff, it's been a while since I've seen it.
It's GPL if you build their bundled copy of the AGPGART code as agpgart.ko,
but the usual use case is that it's built-in to fglrx.ko, which sounds
incredibly dubious.

Now, AGPGART has a murky past wrt licenses.  It initally was imported
into the tree with the license "GPL plus additional rights".
Nowhere was it actually documented what those rights were, but I'm
fairly certain it wasn't to enable nonsense like the above.
As it came from the XFree86 folks, it's more likely they really meant
"Dual GPL/MIT" or similar.

When I took over, any new code I wrote I explicitly set out to mark as GPL
code, as my modifications weren't being contributed back to X, they were
going back to the Linux kernel.  ATI took those AGPv3 modifications from
a 2.5 kernel, backported them to their 2.4 driver, and when time came
to do a 2.6 driver, instead of doing the sensible thing and dropping
them in favour of using the kernel AGP driver, they chose to forward
port their unholy abomination to 2.6.
It misses so many fixes (and introduces a number of other problems)
that its just unfunny.

The thing that really ticks me off though is the free support ATI seem
to think they're entitled to.  I've had end-users emailing me
"I asked ATI about this crash I've been seeing with fglrx, and they
 asked me to mail you".

I invest my time into improving free drivers.  When companies start
expecting me to debug their part binary garbage mixed with license
violations, frankly, I think they're taking the piss.

A year and a half ago, I met an ATI engineer at OLS, who told me they
were going to 'resolve this'.  I'm still waiting.
I live in hope that the AMD buyout will breathe some sanity into ATI.
Then again, I've only a limited supply of optimism.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Ricardo Galli]

> I think it would be a hell of a lot better idea if people just realized
> that they have "fair use" rights whether the authors give them or not, and
 ^
> that the authors copyrights NEVER extend to anything but a "derived work"
...
> I find the RIAA's position and the DMCA distasteful, and in that I
> probably have a lot of things in common with a lot of people on this list.
> But by _exactly_ the same token, I also find the FSF's position and a lot
> of GPL zealots' position on this matter very distasteful.
...
> Because "fair use" is NOT somethng that should be specified in the
  ^
> license.

As you probably know, the GPL, the FSF, RMS or even GPL "zealots" never tried 
to change or restrict "fair use". GPL[23] covers only to "distibution" of the 
covered program. The freedom #0 says explicitly: "right to use the program 
for any purpose".

So, I don't see any clash here between GPL/FSF/RMS with "fair use"

And you probably know that any GPLed code can be linked and executed with any 
other program, whatever is its license if it's for personal use (is that 
worse than "fair use"?). 

And even if there is a function in linux that disables loading of non GPL 
modules, it's still allowed under the GPL to distribute a kernel with those 
functions removed. Any user can load any other module in this kernel without 
worrying about "fair use" or "derived work", GPL allows her to do it.

So, where's the freaking relationship between GPL (or its "zealots") and "fair 
use"? Who is trying to re-define it?

FUD, FUD, FUD.

-- 
  ricardo galli   GPG id C8114D34
  http://mnm.uib.es/gallir/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: V4L2: __ucmpdi2 undefined on ppc

[Mauro Carvalho Chehab]

> I posted a patch to Paul this week to fix this, as saw we saw it on
> Ubuntu's powerpc kernel builds.
> 
> Since ppc32 can't do a 64bit comparison on its own it seems, gcc
> will generate a call to a helper function from libgcc. What other
> arches do is link libgcc.a into libs-y, and export the symbol
> they want from it. The build process will discard the rest of the
> .a that is unused. parisc uses this method, for example.
> 
> Gcc targets can provide optimized versions of these helpers in
> assembly, but at least in this case, the generic C version seems
> to be used everywhere. It might be useful to provide kernel local
> copies of these C versions linked __weak or something if the
> arch happens to need them.
> 
> (Not going to sign off or anything, since I've already sent it to
> paulus@ and I don't want it to get merged without his approval...)

Seems to be a good way to solve it.


> ---
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index a00fe72..5b60c05 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -139,6 +139,8 @@ core-$(CONFIG_XMON)   += arch/powerpc/xmon/
>  
>  drivers-$(CONFIG_OPROFILE)   += arch/powerpc/oprofile/
>  
> +libs-y   += `$(CC) -print-libgcc-file-name`
> +
>  # Default to zImage, override when needed
>  defaultimage-y   := zImage
>  defaultimage-$(CONFIG_PPC_ISERIES) := vmlinux
> diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
> index 9179f07..dea8384 100644
> --- a/arch/powerpc/kernel/ppc_ksyms.c
> +++ b/arch/powerpc/kernel/ppc_ksyms.c
> @@ -164,6 +164,9 @@ long long __lshrdi3(long long, int);
>  EXPORT_SYMBOL(__ashrdi3);
>  EXPORT_SYMBOL(__ashldi3);
>  EXPORT_SYMBOL(__lshrdi3);
> +
> +extern void __ucmpdi2(void);
> +EXPORT_SYMBOL(__ucmpdi2);
>  #endif
>  
>  EXPORT_SYMBOL(memcpy);
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
Cheers, 
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: lots of code could be simplified by using ARRAY_SIZE()

[Jan Engelhardt]

On Dec 16 2006 08:09, Robert P. J. Day wrote:
>On Sat, 16 Dec 2006, Pavel Machek wrote:
>> > but we already have, from "include/linux/kernel.h":
>> >
>> >   #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
>>
>> Hmmm. quite misleading name :-(. ARRAY_LEN would be better.
>
>i suspect it's *way* too late to make that kind of change, given that
>"ARRAY_SIZE" is firmly ensconced in countless places in the source
>tree and that would be a major, disruptive change.
>
>even *i* wouldn't try to promote that idea.  :-)

You know, you could always make it compat for a while, but that requires
approval from Linus I suppose /* heh, heh */

I don't even know if this will compile everywhere,
but I hope you can figure out the idea...

#define ARRAY_SIZE(x) (print_warning(), sizeof(x) / sizeof(*x))
#define ARRAY_LEN(x)  (sizeof(x) / sizeof(*x))
extern ...
void print_warning(void) {
printk("Don't use ARRAY_SIZE anymore, it will go away\n");
}


-`J'
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Horses and donkeys [Re: Binary Drivers]

[Jan Engelhardt]

On Dec 16 2006 08:12, Pavel Machek wrote:
>> 
>> If you are going to mount a sanctimonious high horse it 
>> is a wise idea
>> to mount a horse instead of a donkey.
>
>High horses are common and easy to ride. But a donkey... :-).

The next thing that happens is that nvidia and ati
undermine us a Trojan Rabbit.


-`J'
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: IO-APIC + timer doesn't work (was: Linux 2.6.20-rc1)

[Linus Torvalds]

On Sat, 16 Dec 2006, Tobias Diedrich wrote:
> 
> 2.6.20-rc1 won't boot with the error message "IO-APIC + timer
> doesn't work! Try using the 'noapic' kernel parameter".
> However, IO-APIC seems to work just fine with 2.6.19-rc6 and I'd
> rather like to continue using it. :)

Can you try "git bisect" on this?

It's really easy: since you know that v2.6.20-rc1 doesn't work, and 
v2.6.19-rc6 _does_ work, just get the current kernel git tree, and then do

git bisect start
git bisect good v2.6.19-rc6
git bisect bad v2.6.20-rc1

and it will pick a kernel for you to try. Just compile that, boot with it, 
and if it works, say "git bisect good" (and if it doesn't work, just do 
"git bisect bad" instead). It will give you a new kernel, and in a few 
tries you'll have been able to narrow down exactly where it breaks (ok, 
more than "a few" - there's 3728 commits in that range, so it's more like 
"twelve reboots later").

That said, it's likely one of not a lot of commits that are broken, as 
shown by

git log v2.6.19-rc6..v2.6.20-rc1 arch/x86_64/kernel/io_apic.c

and it's *probably* commit b0268726: "[PATCH] x86-64: Try multiple timer 
variants in check_timer"

But a few other people also added to the Cc in case they have ideas.

Linus

*** snip snip, left the most relevant info here
***
*** others: please look up the post on linux-kernel
*** for config info if you care

> http://tdiedrich.de/~ranma/2.6.20-rc1-oops.jpg
> (netconsole is configured but doesn't work for some reason, haven't
> looked into that so far)
> [...]
> ENABLING IO-APIC IRQs
> ..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 disabled(3) .. failed
> ..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 enabled(7)APIC error on CPU0: 
> 04(40)
>  .. failed
> ..TIMER: trying IO-APIC=0 PIN=2 fallback with 8259 IRQ0 disabled(3) .. failed
> ...trying to set up timer as Virtual Wire IRQ... failed.
> ...trying to set up timer as ExtINT IRQ... failed :(.
> Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 
> 'noapic' kernel parameter
> 
> The board is an ASUS M2N SLI Deluxe (Athlon64/nforce).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Binary Drivers

[Jan Engelhardt]

On Dec 16 2006 01:57, Tomas Carnecky wrote:
> Alexey Dobriyan wrote:
>> On Fri, Dec 15, 2006 at 09:20:58PM +, James Porter wrote:
>> > For what it's worth, I don't see any problem with binary drivers from
>> > hardware
>> > manufacturers.
>> 
>> Binary drivers from hardware manufacturers are crap. Learn it by heart.
>
> That's your personal opinion! A lot other people (including me) have had
> excellent experience with binary drivers!

Either way.

 *  NVIDIA blob on a desktop box

Ability to deadlock the machine, proved so in the past, but
has not happened >= 1.0.7xxx so far.


 *  Free "radeon" driver on a laptop

The _second_ time (relative to starting the X binary) I switch
from Xorg 6.x to the console, the screen fades from black to
white. System remains operational, switching back to X gives me
my graphics mode back, but no way to go back to console.



-`J'
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [KORG] Re: kernel.org lies about latest -mm kernel

[Randy Dunlap]

Andrew Morton wrote:

On Sat, 16 Dec 2006 09:44:21 -0800
Randy Dunlap <[EMAIL PROTECTED]> wrote:


On Thu, 14 Dec 2006 23:37:18 +0100 Pavel Machek wrote:


Hi!

[EMAIL PROTECTED]:/data/pavel$ finger @www.kernel.org
[zeus-pub.kernel.org]
...
The latest -mm patch to the stable Linux kernels is: 2.6.19-rc6-mm2
[EMAIL PROTECTED]:/data/pavel$ head /data/l/linux-mm/Makefile
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 19
EXTRAVERSION = -mm1
...
[EMAIL PROTECTED]:/data/pavel$

AFAICT 2.6.19-mm1 is newer than 2.6.19-rc6-mm2, but kernel.org does
not understand that.

Still true (not listed) for 2.6.20-rc1-mm1  :(

Could someone explain what the problem is and what it would
take to correct it?


2.6.20-rc1-mm1 still hasn't propagated out to the servers (it's been 36
hours).  Presumably the front page non-update is a consequence of that.


Agreed on the latter part.  Can someone address the real problem???

--
~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: [RFC][PATCH] Make entries in the "Device drivers" menu individually selectable

[Jan Engelhardt]

On Dec 16 2006 11:52, Stefan Richter wrote:
>Robert P. J. Day wrote on 2006-12-14:
>>   i've posted on this before so here's a slightly-updated patch that
>> uses the kbuild "menuconfig" feature to make numerous entries under
>> the Device drivers menu selectable on the spot.
>
>Works for me, but I don't see a lot of benefit from it. Actually I see
>two disadvantages of the patch:
>
> - Without the patch, the choice of y/m/n for a subsystem and the help
>text is put aside into the submenu. I find this current layout simpler
>and quieter.

When using "Help" on a (normal) menu element, the menuconfig help pops up.
(This is probably what you mean.)
This could be changed for menuconfig elements.

> - There are two out-of-tree FireWire drivers for special purposes (one
>bus sniffer, one remote debugging aid) which might perhaps be candidates
>for integration into mainline. These drivers do not use the ieee1394
>base driver. (They just don't need to.) With your patch, disabling the
>subsystem menu would not only disable the subsystem core driver (which
>is correct) but would also hide the choice for such extra drivers which
>do not need the core driver. Or vice versa, enabling the submenu would
>enable the core driver, even though not all subsystem choices need the
>core driver.

And in case there is a

   menu FOO

   config BAR

   config BAZ

   endmenu

just don't convert these to menuconfig. Issue set :)



-`J'
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [KORG] Re: kernel.org lies about latest -mm kernel

[Andrew Morton]

On Sat, 16 Dec 2006 09:44:21 -0800
Randy Dunlap <[EMAIL PROTECTED]> wrote:

> On Thu, 14 Dec 2006 23:37:18 +0100 Pavel Machek wrote:
> 
> > Hi!
> > 
> > [EMAIL PROTECTED]:/data/pavel$ finger @www.kernel.org
> > [zeus-pub.kernel.org]
> > ...
> > The latest -mm patch to the stable Linux kernels is: 2.6.19-rc6-mm2
> > [EMAIL PROTECTED]:/data/pavel$ head /data/l/linux-mm/Makefile
> > VERSION = 2
> > PATCHLEVEL = 6
> > SUBLEVEL = 19
> > EXTRAVERSION = -mm1
> > ...
> > [EMAIL PROTECTED]:/data/pavel$
> > 
> > AFAICT 2.6.19-mm1 is newer than 2.6.19-rc6-mm2, but kernel.org does
> > not understand that.
> 
> Still true (not listed) for 2.6.20-rc1-mm1  :(
> 
> Could someone explain what the problem is and what it would
> take to correct it?

2.6.20-rc1-mm1 still hasn't propagated out to the servers (it's been 36
hours).  Presumably the front page non-update is a consequence of that.

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

[Jan Engelhardt]

Hi,



Reusing code is a good idea, and I would like to do so from my 
match modules. netfilter already provides a xt_request_find_target() but 
an xt_request_find_match() does not yet exist. This patch adds it.

Objections welcome :)

---

Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>

Index: linux-2.6.20-rc1/net/netfilter/x_tables.c
===
--- linux-2.6.20-rc1.orig/net/netfilter/x_tables.c
+++ linux-2.6.20-rc1/net/netfilter/x_tables.c
@@ -206,6 +206,19 @@ struct xt_match *xt_find_match(int af, c
 }
 EXPORT_SYMBOL(xt_find_match);
 
+struct xt_match *xt_request_find_match(int af, const char *name, u8 revision)
+{
+   struct xt_match *match;
+
+   match = try_then_request_module(xt_find_match(af, name, revision),
+   "%st_%s", xt_prefix[af], name);
+   if(IS_ERR(match) || match == NULL)
+   return NULL;
+
+   return match;
+}
+EXPORT_SYMBOL_GPL(xt_request_find_match);
+
 /* Find target, grabs ref.  Returns ERR_PTR() on error. */
 struct xt_target *xt_find_target(int af, const char *name, u8 revision)
 {
#

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

pata_marvell and Marvell 88SE6121

[Jose Alberto Reguero]

I am trying to make work the driver pata_marvell of linux-2.6.20-rc1 with 
Marvell 88SE6121.
I added the PCI ID: 0x6121

{ PCI_DEVICE(0x11AB, 0x6101), },
{ PCI_DEVICE(0x11AB, 0x6145), },
{ PCI_DEVICE(0x11AB, 0x6121), },
{ } /* terminate list */

But not succes.

Log attached.

Any hints are welcome.
Thanks.

Jose Alberto
Dec 16 12:22:58 jar kernel: ata3: PATA max UDMA/100 cmd 0xEC00 ctl 0xE882 bmdma 
0xE400 irq 28
Dec 16 12:22:58 jar kernel: ata4: PATA max UDMA/133 cmd 0xE800 ctl 0xE482 bmdma 
0xE408 irq 28
Dec 16 12:22:58 jar kernel: scsi3 : pata_marvell
Dec 16 12:22:58 jar kernel: BAR5:00:02 01:7F 02:22 03:CA 04:00 05:00 06:00 
07:80 08:00 09:00 0A:00 0B:00 0C:07 0D:00 0E:00 0F:00
Dec 16 12:22:58 jar kernel: ATA: abnormal status 0x7F on port 0xEC07
Dec 16 12:22:58 jar kernel: scsi4 : pata_marvell
Dec 16 12:22:58 jar kernel: BAR5:00:02 01:7F 02:22 03:CA 04:00 05:00 06:00 
07:80 08:00 09:00 0A:00 0B:00 0C:07 0D:00 0E:00 0F:00
Dec 16 12:22:58 jar kernel: ATA: abnormal status 0x7F on port 0xE807

[KORG] Re: kernel.org lies about latest -mm kernel

[Randy Dunlap]

On Thu, 14 Dec 2006 23:37:18 +0100 Pavel Machek wrote:

> Hi!
> 
> [EMAIL PROTECTED]:/data/pavel$ finger @www.kernel.org
> [zeus-pub.kernel.org]
> ...
> The latest -mm patch to the stable Linux kernels is: 2.6.19-rc6-mm2
> [EMAIL PROTECTED]:/data/pavel$ head /data/l/linux-mm/Makefile
> VERSION = 2
> PATCHLEVEL = 6
> SUBLEVEL = 19
> EXTRAVERSION = -mm1
> ...
> [EMAIL PROTECTED]:/data/pavel$
> 
> AFAICT 2.6.19-mm1 is newer than 2.6.19-rc6-mm2, but kernel.org does
> not understand that.

Still true (not listed) for 2.6.20-rc1-mm1  :(

Could someone explain what the problem is and what it would
take to correct it?

---
~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: [-mm patch] drivers/video/{s3fb,svgalib}.c: possible cleanups

[Randy Dunlap]

On Sat, 16 Dec 2006 14:56:57 +0100 Adrian Bunk wrote:

> This patch contains the following possible cleanups:
> - CodingStyle:
>   - opening braces of functions at the beginning of the next line
>   - C99 struct initializers

I don't see anything about struct initializers in CodingStyle,
but I would say that it's a good candidate for addition.

---
~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: [ANNOUNCE] RAIF: Redundant Array of Independent Filesystems

[Nikolai Joukov]

> I am looking at filling the net-pipe, and it only reaches 40-75% max, with
> some short 100% bursts, and a slow 10% start.  It seems that caching
> somewhat delays the writes, which then batch up and sync at various speeds.
> So you have the cache really hiding slow sync speeds.  To tune this, it may
> be helpful to turn off caching, which in turn could surface the actual
> bottlenecks.

Well, RAIF is an external kernel module and as such cannot change the
caching behavior much.  The notorious problem of all Linux stackable file
systems is double-caching of data.  Every stackable file system caches the
data at its own level and copies it from/to the lower file system's cached
pages when necessary.  This has some advantages for file systems that
change the data (e.g., encrypt or compress).  However, this effectively
reduces the system's cache memory size by two or more times.

Among all the existing stackable file systems, Tracefs and RAIF have the
highest requirements for low overheads.  Here are the solutions to the
double-caching problem that we tried:

1. Redirect read and write requests to the lower file systems directly.
   This allows to avoid caching of data at the RAIF level.  However, this
   optimization must be turned off as soon as a file is mmap'ed to avoid
   cache inconsistencies.  Also, even if the file is not mmap'ed, RAIF1
   still keeps the data copies for all the lower branches.  This
   optimization is implemented in RAIF but is not turned on by default.
   (We strip this and many other #ifdef'ed code fragments from the
   code releases automatically.)

2. We cache the data at the RAIF level.  When we write to the lower file
   systems we do allocate the lower pages and do copy the data but we
   also mark the lower pages with PG_reclaim flag before calling the
   lower writepage operation.  This releases all the lower pages right
   after the write completes.  This works fine for mmap'ed files and this
   is the default RAIF behavior now.  This solves the problem for most
   workloads that mix reads and writes.  For example, it improved
   Postmark's performance several times.  Unfortunately, this optimization
   does not improve performance for big sequential writes - the workload
   that you tried.  So essentially, you had a quarter of your original page
   cache while running your workload.

3. A known ideal solution for this problem is sharing of the cached pages
   between file systems.  We attempted to do it for Tracefs but the
   resulting code is not beautiful and is potentially racy:
   
   Unfortunately, for fan-out file systems this solution requires even
   more support from the OS.  However, this is what most OSs do
   (including BSD and Windows) but unfortunately not Linux :-(

> little overhead.  So for RAIF to be viable, it needs to have low overhead,
> which doesn't seem impossible to implement, given RAIF's simple but
> beautiful approach.

Thanks a lot!

Nikolai.
-
Nikolai Joukov, Ph.D.
Filesystems and Storage Laboratory
Stony Brook University
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[git patches] libata fixes

[Jeff Garzik]

More fixes coming too - the thing Alan's talking about, and an ata_piix
leak-on-err fix.  By Monday-ish (its a working weekend).

Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git 
upstream-linus

to receive the following updates:

 drivers/ata/Kconfig|6 +++---
 drivers/ata/ahci.c |2 --
 drivers/ata/ata_piix.c |   22 +-
 drivers/ata/libata-core.c  |   14 ++
 drivers/ata/libata-scsi.c  |4 ++--
 drivers/ata/pata_legacy.c  |4 +++-
 drivers/ata/pata_qdi.c |4 ++--
 drivers/ata/pata_rz1000.c  |2 --
 drivers/ata/pata_via.c |9 +++--
 drivers/ata/pata_winbond.c |4 ++--
 drivers/ata/sata_svw.c |   41 ++---
 11 files changed, 80 insertions(+), 32 deletions(-)

Akinobu Mita (1):
  ata: fix platform_device_register_simple() error check

Alan (2):
  Fix help text for CONFIG_ATA_PIIX
  pata_via: Cable detect error

Ira Snyder (1):
  initializer entry defined twice in pata_rz1000

Jason Gaston (1):
  ata_piix: IDE mode SATA patch for Intel ICH9

Jeff Garzik (2):
  [libata] use kmap_atomic(KM_IRQ0) in SCSI simulator
  [libata] sata_svw: Disable ATAPI DMA on current boards (errata workaround)

Tejun Heo (3):
  ata_piix: use piix_host_stop() in ich_pata_ops
  libata: don't initialize sg in ata_exec_internal() if DMA_NONE (take #2)
  ahci: do not mangle saved HOST_CAP while resetting controller

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 984ab28..b34e0a9 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -40,9 +40,9 @@ config ATA_PIIX
tristate "Intel PIIX/ICH SATA support"
depends on PCI
help
- This option enables support for ICH5/6/7/8 Serial ATA.
- If PATA support was enabled previously, this enables
- support for select Intel PIIX/ICH PATA host controllers.
+ This option enables support for ICH5/6/7/8 Serial ATA
+ and support for PATA on the Intel PIIX3/PIIX4/ICH series
+ PATA host controllers.
 
  If unsure, say N.
 
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index f36da48..dbae6d9 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -645,8 +645,6 @@ static int ahci_reset_controller(void __iomem *mmio, struct 
pci_dev *pdev)
u32 cap_save, impl_save, tmp;
 
cap_save = readl(mmio + HOST_CAP);
-   cap_save &= ( (1<<28) | (1<<17) );
-   cap_save |= (1 << 27);
impl_save = readl(mmio + HOST_PORTS_IMPL);
 
/* global controller reset */
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index c7de0bb..47701b2 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -226,14 +226,26 @@ static const struct pci_device_id piix_pci_tbl[] = {
{ 0x8086, 0x27c0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich6_sata_ahci },
/* 2801GBM/GHM (ICH7M, identical to ICH6M) */
{ 0x8086, 0x27c4, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich6m_sata_ahci },
-   /* Enterprise Southbridge 2 (where's the datasheet?) */
+   /* Enterprise Southbridge 2 (631xESB/632xESB) */
{ 0x8086, 0x2680, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich6_sata_ahci },
-   /* SATA Controller 1 IDE (ICH8, no datasheet yet) */
+   /* SATA Controller 1 IDE (ICH8) */
{ 0x8086, 0x2820, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
-   /* SATA Controller 2 IDE (ICH8, ditto) */
+   /* SATA Controller 2 IDE (ICH8) */
{ 0x8086, 0x2825, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
-   /* Mobile SATA Controller IDE (ICH8M, ditto) */
+   /* Mobile SATA Controller IDE (ICH8M) */
{ 0x8086, 0x2828, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
+   /* SATA Controller IDE (ICH9) */
+   { 0x8086, 0x2920, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
+   /* SATA Controller IDE (ICH9) */
+   { 0x8086, 0x2921, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
+   /* SATA Controller IDE (ICH9) */
+   { 0x8086, 0x2926, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
+   /* SATA Controller IDE (ICH9M) */
+   { 0x8086, 0x2928, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
+   /* SATA Controller IDE (ICH9M) */
+   { 0x8086, 0x292d, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
+   /* SATA Controller IDE (ICH9M) */
+   { 0x8086, 0x292e, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
 
{ } /* terminate list */
 };
@@ -330,7 +342,7 @@ static const struct ata_port_operations ich_pata_ops = {
 
.port_start = ata_port_start,
.port_stop  = ata_port_stop,
-   .host_stop  = ata_host_stop,
+   .host_stop  = piix_host_stop,
 };
 
 static const struct ata_port_operations piix_sata_ops = {
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 011c0a8..0d51d13 100644
--- a/drivers/ata/lib

Re: [2.6 patch] more ftape removal

[Jeff Garzik]

Adrian Bunk wrote:

On Sat, Dec 16, 2006 at 11:36:37AM -0500, Jeff Garzik wrote:

Adrian Bunk wrote:

This patch removes some more ftape code.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
this affects userspace exported headers, so I'm not sure we want to kill 
that.  even if the interface is gone is current kernels, people might 
want to build binaries against these headers that work on older kernels.


Can you be more specific?

Building ftape-utils has already been broken by you removing four 
userspace exported ftape headers in your ftape removal patch.


One would expect that to break.  I'm more concerned about things like 
util-linux or mt-st.


But you're right, we should probably remove everything at a set.

Jeff



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

[Adrian Bunk]

On Sat, Dec 16, 2006 at 11:36:37AM -0500, Jeff Garzik wrote:
> Adrian Bunk wrote:
> >This patch removes some more ftape code.
> >
> >Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> 
> this affects userspace exported headers, so I'm not sure we want to kill 
> that.  even if the interface is gone is current kernels, people might 
> want to build binaries against these headers that work on older kernels.

Can you be more specific?

Building ftape-utils has already been broken by you removing four 
userspace exported ftape headers in your ftape removal patch.

>   Jeff

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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Linus Torvalds]

On Sat, 16 Dec 2006, Willy Tarreau wrote:
> 
> I understand your point, but not completely agree with the comparison,
> because I think that you (as the "author") are in the type of authors
> you describe below :
> 
> > Of course, all reasonable true authors tend to agree with fair use.

Sure. Sadly, in this day and age, "copyright owner" and "author" only bear 
a very passing resemblance to each other.

In a lot of areas, the AUTHOR may be a very reasonable person, and realize 
that fair use is a good thing, and perhaps even realize that in some 
places even unfair use can be a good thing (do you really think you should 
pay $20 for a DVD if you make $3 a month in a sweatshop in china? Maybe 
piracy sometimes is simply better..)

But the author may also have his own reasons for wanting to _deny_ fair 
use. Maybe he's just a royal a-hole, and wants to milk his work for 
whatever it's worth. But maybe he's a person with an agenda, and wants to 
ignore fair use because he wants to "improve the world for everybody", 
never mind that he tries to deny people a fundamental right in the 
process. I call those people a-holes too (in all fairness, they return the 
favor, so we're all even ;)

But even more commonly, the author simply doesn't control the copyright at 
all any more. In many areas (and software is one - including even large 
swaths of free software), the copyrights of a work is not really 
controlled by the author of the work, but by companies or foundations that 
have no reason to really try to educate people about "fair use".

So I actually think that the authors that actually UNDERSTAND fair use, 
and realize that people can use portions of their work without permission, 
AND that actually control their work is a very very very small subset of 
authors in general.

This has nothing to do with software per se, btw. Pick up one of the 
Calvin & Hobbes books by Bill Watterson - I think it may have been the "10 
year anniversary" one - where he talks about the disagreements he had with 
the people who actually controlled the copyrights (and I think also some 
of the people who used his artwork without any permission - the line 
between "fair use" and "illegal" really is a murky one, and while we 
should celebrate that murkiness, it's also why people disagree).

> > And I'd rather teach people that fundamental fact, than try to confuse the 
> > issue EVEN MORE by saying that my copyright only extends to derived works 
> > in the license text. That will just make people think that if the license 
> > does NOT say that, they don't have fair use. AND THAT IS WRONG.
> 
> That's a valid point. What is really needed is to tell them that if they
> doubt, they just have to ask the author and not be advised by any GPL zealot.

Well, in open source, there often isn't any one "the author". So you can't 
do that. And when there is, as mentioned, he may not actually even have 
the legal right any more to give you any license advice. And even when he 
does hold the copyrights, he may change his mind later.

So in the end, the thing you can and should depend on is: the license text 
itself (and happily, the GPLv2 very clearly talks about the real line 
being "derived work" - it may be a murky line, and they seem to want to 
change that to something harder in the GPLv3, but it's a good line), a 
separate signed contract, or simply a legal opinion, preferably by a judge 
in a court of law. 

Of course, it very seldom gets to that kind of issue. People tend to just 
walk very gently around it all.

If you want to be safe, you NEVER do any binary modules. The only 
_obviously_ safe thing is to always do only what the license very 
explicitly allows you to, and in the case of the GPLv2, that's to release 
all modifications under the same GPLv2.

Anything else, you have to make some really scary decisions. Can a judge 
decide that a binary module is a derived work even though you didn't 
actually use any code? The real answer is: HELL YES. It's _entirely_ 
possible that a judge would find NVidia and ATI in violation of the GPLv2 
with their modules.

Judges have done stranger things. And it's not my place to say what the 
limit of "derived work" actually is. It all probably depends on a lot of 
circumstances, and there simply isn't an easy answer.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: JMicron SATA, "softreset failed (1st FIS failed)" on every boot

[Jeff Garzik]

Tobias Diedrich wrote:
> Hi,
> 
> I'm seeing the following strange behaviour with libata in the
> mm-series (currently 2.6.18-mm2):
> 
> [   31.324566] ata2: softreset failed (1st FIS failed)
> [   31.324674] ata2: softreset failed, retrying in 5 secs
> [   36.642196] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [   36.645232] ata2.00: ATA-7, max UDMA7, 488397168 sectors: LBA48 NCQ (depth 
> 31/32)
> 
> This is with a JMicron controller in AHCI mode on an ASUS M2N-SLI
> Deluxe board.  It's a bit annoying, since this means an additional
> 5-second delay on every boot.

Do you see the same on 2.6.20-rc1?

Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] sata_promise: Port enumeration order - SATA 150 TX4, SATA 300 TX4

[Jeff Garzik]

Evan Harris wrote:


I have a card that mirrors this one from your list:

Retail name: SATA300 TX4
Chip label: PDC40718-GP  SATAII300
Vendor-Device number: 105a:3d17 (rev 02)

Through testing, I've found linux 2.6.16 and 2.6.17 find the ports in 
this order (the list is ordered by linux detection):


1. silkscreen port 3
2. silkscreen port 2
3. silkscreen port 4
4. silkscreen port 1
NOTE: the patch I have submitted ( 
http://marc.theaimsgroup.com/?l=linux-ide&m=114082978311290&w=2 ) is a 
solution that doesn't know about the older Promise SATA controllers, 
which are not affected with the "new wiring" problem, so the older 
controllers will appear screwed if you use it.


Hopefully we will collect enough info about all the SATA Promise 
controllers to distinguish the new and the old wiring controllers, 
then produce a new patch that will be a correct solution to the "new 
wiring" problem.


Mikael Pettersson has been doing some excellent work recently on 
sata_promise.  If enough data has been collected on this sata_promise 
port enumeration problem, maybe the data could be collated and proposed 
via Mikael as a patch?


Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[David Nicol]

On 12/15/06, Alan <[EMAIL PROTECTED]> wrote:

> blather and idiotic hogwash. "Information" doesn't want to be free, nor is
> it somethign you should fight for or necessarily even encourage.

As a pedant that is the one item I have to pick you up on Linus.
Information wants to be free, the natural efficient economic state of
information is generally free in both senses.


I have often thought that "information wants to be free" is a meaningless
phrase that tends to stop arguments because it is difficult to understand
the words in it.  Raw data does not act without agent. The universe does
tend towards increasing entropy however.  Here's a fun thought experiment:
If you burn a book do you free the words?






--
He thought he could organize freedom
how naive and controlling of him
(Bjork, then some)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.20-rc1 00/10] Kernel memory leak detector 0.13

[Ingo Molnar]

* Catalin Marinas <[EMAIL PROTECTED]> wrote:

> This series of patches represent version 0.13 of the kernel memory 
> leak detector. See the Documentation/kmemleak.txt file for a more 
> detailed description. The patches are downloadable from (the whole 
> patch or the broken-out series) http://www.procode.org/kmemleak/

nice stuff!

FYI, i'm working on integrating kmemleak into -rt. Firstly, i needed the 
fixes below when applying it ontop of 2.6.19-rt15.

Secondly, i'm wondering about the following recursion:

 [] rt_spin_lock_slowlock+0x98/0x1dc
 [] rt_spin_lock+0x13/0x4b
 [] kfree+0x3a/0xce
 [] hash_delete+0x58/0x5f
 [] memleak_free+0xe9/0x1e6
 [] __cache_free+0x27/0x414
 [] kfree+0xb5/0xce
 [] acpi_ns_get_node+0xb1/0xbb
 [] acpi_ns_root_initialize+0x30f/0x31d
 [] acpi_initialize_subsystem+0x58/0x87
 [] acpi_early_init+0x4f/0x12e
 [] start_kernel+0x41b/0x44b

kfree() within kfree() ... this probably works on the upstream SLAB 
allocator but makes it pretty nasty to sort out SLAB locking in -rt. 

Wouldnt it be better to just preallocate the hash nodes, like lockdep 
does, to avoid conceptual nesting? Basically debugging infrastructure 
should rely on other infrastructure as little as possible.

also, the number of knobs in the Kconfig is quite large:

 CONFIG_DEBUG_MEMLEAK=y
 CONFIG_DEBUG_MEMLEAK_HASH_BITS=16
 CONFIG_DEBUG_MEMLEAK_TRACE_LENGTH=4
 CONFIG_DEBUG_MEMLEAK_PREINIT_OBJECTS=512
 CONFIG_DEBUG_MEMLEAK_SECONDARY_ALIASES=y
 CONFIG_DEBUG_MEMLEAK_TASK_STACKS=y

i'd suggest to simplify the Kconfig choices to a binary thing: either 
have kmemleak or not have it.

plus the Kconfig dependency on SLAB_DEBUG makes it less likely for 
people to spontaneously try kmemleak. I'd suggest to offer KMEMLEAK 
unconditionally (when KERNEL_DEBUG is specified) and simply select 
SLAB_DEBUG.

Ingo

---
 fs/fcntl.c   |4 ++--
 fs/mbcache.c |2 +-
 include/linux/list.h |9 +
 include/linux/pid.h  |7 +++
 kernel/pid.c |2 +-
 5 files changed, 20 insertions(+), 4 deletions(-)

Index: linux/fs/fcntl.c
===
--- linux.orig/fs/fcntl.c
+++ linux/fs/fcntl.c
@@ -512,7 +512,7 @@ void send_sigio(struct fown_struct *fown
goto out_unlock_fown;

read_lock(&tasklist_lock);
-   do_each_pid_task(pid, type, p) {
+   __do_each_pid_task(pid, type, p) {
send_sigio_to_task(p, fown, fd, band);
} while_each_pid_task(pid, type, p);
read_unlock(&tasklist_lock);
@@ -543,7 +543,7 @@ int send_sigurg(struct fown_struct *fown
ret = 1;

read_lock(&tasklist_lock);
-   do_each_pid_task(pid, type, p) {
+   __do_each_pid_task(pid, type, p) {
send_sigurg_to_task(p, fown);
} while_each_pid_task(pid, type, p);
read_unlock(&tasklist_lock);
Index: linux/fs/mbcache.c
===
--- linux.orig/fs/mbcache.c
+++ linux/fs/mbcache.c
@@ -555,7 +555,7 @@ __mb_cache_entry_find(struct list_head *
 {
while (l != head) {
struct mb_cache_entry *ce =
-   list_entry(l, struct mb_cache_entry,
+   __list_entry(l, struct mb_cache_entry,
   e_indexes[index].o_list);
if (ce->e_bdev == bdev && ce->e_indexes[index].o_key == key) {
DEFINE_WAIT(wait);
Index: linux/include/linux/list.h
===
--- linux.orig/include/linux/list.h
+++ linux/include/linux/list.h
@@ -367,6 +367,8 @@ static inline void list_splice_init(stru
  */
 #define list_entry(ptr, type, member) \
container_of(ptr, type, member)
+#define __list_entry(ptr, type, member) \
+   __container_of(ptr, type, member)
 
 /**
  * list_for_each   -   iterate over a list
@@ -822,6 +824,7 @@ static inline void hlist_add_after_rcu(s
 }
 
 #define hlist_entry(ptr, type, member) container_of(ptr,type,member)
+#define __hlist_entry(ptr, type, member) __container_of(ptr,type,member)
 
 #define hlist_for_each(pos, head) \
for (pos = (head)->first; pos && ({ prefetch(pos->next); 1; }); \
@@ -897,6 +900,12 @@ static inline void hlist_add_after_rcu(s
 rcu_dereference(pos) && ({ prefetch(pos->next); 1;}) && \
({ tpos = hlist_entry(pos, typeof(*tpos), member); 1;}); \
 pos = pos->next)
+#define __hlist_for_each_entry_rcu(tpos, pos, head, member) \
+   for (pos = (head)->first;\
+rcu_dereference(pos) && ({ prefetch(pos->next); 1;}) && \
+   ({ tpos = __hlist_entry(pos, typeof(*tpos), member); 1;}); \
+pos = pos->next)
+
 
 #else
 #warning "don't include kernel headers in userspace"
Index: linux/include/linux/pid.h
=

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jeremy Fitzhardinge]

Theodore Tso wrote:
> P.S.  For people who live in the US; write your congresscritters; the
> MPAA wants to propose new legislation stating exactly this.
>   
(Erm, that was a joke on a parody site; it got widely reported as "news".

http://www.bbspot.com/News/2006/11/home-theater-regulations.html

Other headlines:

MPAA to Thwart Pirates by Making All Movies Suck
Sony Unveils New Self-Destructive DVD Player


J)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Willy Tarreau]

On Sat, Dec 16, 2006 at 08:28:20AM -0800, Linus Torvalds wrote:
> On Sat, 16 Dec 2006, Willy Tarreau wrote:
> > 
> > All this is about "fair use", and "fair use" comes from compatibility
> > between the author's intent and the user's intent.
> 
> No. "fair use" comes from an INcompatibility between the author's intent 
> and the users intent. 
> 
> In other words, "fair use" kicks in EXACTLY when an author says "you can't 
> copy this except when you [payme, stand on your head for two hours, give 
> your modifications back]", and the user _disagrees_.
> 
> Users still have rights under copyright law even when the author tries to 
> deny them those rights.

I understand your point, but not completely agree with the comparison,
because I think that you (as the "author") are in the type of authors
you describe below :

> Of course, all reasonable true authors tend to agree with fair use. People 
> who actually do "original work" tend to all realize that everybody really 
> feeds off of each others works, and that we're all inspired by authors etc 
> that went before us. So I doubt a lot of real authors, musicians or 
> computer programmers will actually disagree with the notion of fair use, 
> but it's important to realize that fair use is exactly for when the users 
> and the authors rights clash, and the user DOES have rights. Even rights 
> that weren't explicitly given to them by the author.

And it is in this situation that I see the compatibility between the user's
and the author's intent : if the user doubts about his fair use and asks the
author, generally the author agrees to extend his fair use perimeter.

(...)

> I think it would be a hell of a lot better idea if people just realized 
  ^^^
> that they have "fair use" rights whether the authors give them or not, and 
> that the authors copyrights NEVER extend to anything but a "derived work".
> 
> I find the RIAA's position and the DMCA distasteful, and in that I 
> probably have a lot of things in common with a lot of people on this list. 
> But by _exactly_ the same token, I also find the FSF's position and a lot 
> of GPL zealots' position on this matter very distasteful.
 ^^^

You see my point ? The users generally understand "fair use" easier than
the GPL zealots which pollute the list or strip down kernel drivers to
save users' freedom. And it is to protect fair users from those people
that I explicited my intent along with the license.

> Because "fair use" is NOT somethng that should be specified in the 
> license. It's very much something that people have DESPITE any license 
> claiming otherwise.
> 
> And I'd rather teach people that fundamental fact, than try to confuse the 
> issue EVEN MORE by saying that my copyright only extends to derived works 
> in the license text. That will just make people think that if the license 
> does NOT say that, they don't have fair use. AND THAT IS WRONG.

That's a valid point. What is really needed is to tell them that if they
doubt, they just have to ask the author and not be advised by any GPL zealot.

>   Linus

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: [2.6 patch] more ftape removal

[Jeff Garzik]

Adrian Bunk wrote:

This patch removes some more ftape code.

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


this affects userspace exported headers, so I'm not sure we want to kill 
that.  even if the interface is gone is current kernels, people might 
want to build binaries against these headers that work on older kernels.


Jeff



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