Re: broken ACPI NUMA config option

[Randy Dunlap]

On Sat, 08 Sep 2007 23:48:56 -0400 James C. Georgas wrote:

> On Sat, 2007-08-09 at 18:16 -0700, Randy Dunlap wrote:
> 
> > 2.6.23-rc5-git1 builds for me when I follow those steps...
> > except for some Section mismatch warnings.
> > 
> 
> OK, it worked for me also, using torvalds/linux-2.6.git. The behaviour
> of the "select" directive in Kconfig appears to have changed since
> 2.6.22.6. It now turns on ACPI, even when PM is not selected.
> 
> This still looks broken to me, because ACPI gets selected by ACPI_NUMA,
> and ACPI depends on PM, but PM is not selected. It works out in the end,
> as far as the build is concerned, but it still bugs me.
> 
> Does anyone object to the idea of a selected item automatically
> selecting its own dependencies?
> 
> For example, you would only need to specify one "select" directive in
> X86_64_ACPI_NUMA, (i.e. to turn on ACPI_NUMA). The configuration system
> would then recursively walk up ACPI_NUMA's dependency hierarchy, turning
> on what it needed.

That is highly desirable IMO.  Not having that is one of the things
that makes using 'select' "evil."

Have you looked at the code and given any thought to implementing this?

Thanks,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: sk98lin for 2.6.23-rc1

[Willy Tarreau]

On Sat, Sep 08, 2007 at 10:42:20PM -0400, Kyle Rose wrote:
> 
> > You are a regular reader of linux-kernel, and therefore the sk98lin 
> > removal can hardly be a surprise for you. If you prefer whining over 
> > helping to improve the kernel that's your choice...
> >   
> In my case the issue is simply one of practicality: I cannot go to the
> data center 5 times per day to reboot my colo box.  Therefore, I run
> sk98lin.  It's really that simple.

Adrian generally wants to force "normal" users to test new drivers in order
to quickly find bugs and fade out older ones. While this is often possible
on the desktop, it's not possible for production servers. And not everyone
can run 2.6.16.x to get a long-term stable kernel.

I think that what is really needed is to add the opposite of "experimental"
in the config options. Something like "deprecated drivers" which would be
disabled by default. Desktop users would normally not care about that and
rely only on newer drivers. Server users would have to enable the option if
they want their old driver to be present because they have no other choice.

With each driver's help text, it would be wise to add some text indicating
what will replace the driver in question, so that their users know how to
test it on non-production machines.

But I agree with Kyle that on production systems, it is not acceptable to
have a driver hang even once a month. This generally implies loss of service
and customers going away. Ideology has no place in this area, is is quickly
replaced by pragmatism.

It was the same reason I spent time trying to get sky2 to reliably work in
2.4 ; sk98lin v8 was horribly unstable. Sky2 was fairly better but did not
support some basic operations such as ifdown/ifup. sk98lin v10 finally worked
fine, and I upgraded my customer's system with it because I needed anything
which would reliably work. It was not acceptable anymore to have the customer
phone twice a week complaining that their server had crashed again.

In the long term, I would really like to get sky2 to work well in 2.4
because I'm more confident it in, it's cleaner, less obscure and less
bloated. Having passed terabytes of data through both drivers I have
not observed any glitch with sky2 as I had with sk98lin v8.

Fortunately, sky2 chips are mostly found on desktop motherboards, so that
helps the driver stabilize very quickly. It should not take as long as
the transition from eepro100 to e100.

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: broken ACPI NUMA config option

[Yinghai Lu]

On 9/8/07, James C. Georgas <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-08-09 at 18:16 -0700, Randy Dunlap wrote:
>
> > 2.6.23-rc5-git1 builds for me when I follow those steps...
> > except for some Section mismatch warnings.
> >
>
> OK, it worked for me also, using torvalds/linux-2.6.git. The behaviour
> of the "select" directive in Kconfig appears to have changed since
> 2.6.22.6. It now turns on ACPI, even when PM is not selected.
>
> This still looks broken to me, because ACPI gets selected by ACPI_NUMA,
> and ACPI depends on PM, but PM is not selected. It works out in the end,
> as far as the build is concerned, but it still bugs me.
>
> Does anyone object to the idea of a selected item automatically
> selecting its own dependencies?
>
> For example, you would only need to specify one "select" directive in
> X86_64_ACPI_NUMA, (i.e. to turn on ACPI_NUMA). The configuration system
> would then recursively walk up ACPI_NUMA's dependency hierarchy, turning
> on what it needed.

dont know my old patch still can be applied or not..
http://lkml.org/lkml/2007/4/4/17

Andi was talking about to use ACPI numa aka SRAT table, but not use dsdt 

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

Re: sata & scsi suggestion for make menuconfig

[Al Boldi]

Al Boldi wrote:
> Alan Cox wrote:
> > > I once sent a patch to make libata a submenu of scsi.
> >
> > Which is wrong
> >
> > Nakked-by: Alan Cox <[EMAIL PROTECTED]>
> >
> > The general comments about moving this stuff around and making it
> > clearer what sd/sr etc are nowdays are good but hiding libata under SCSI
> > will cause even more confusion than it cures
>
> That's easy to fix:  just change the SCSI heading to include a libata
> hint.
>
> Something like this:
>
> [PATCH] libata Kconfig: Allow libata to be selected from within the SCSI
> submenu
>
> Move libata Kconfig sourcing from the drivers Kconfig into the SCSI
> Kconfig, and change the SCSI menu heading to indicate libata submenu
> inclusion.
>
> This allows the user to quickly select additional disk/tape/cdrom support
> from within the same menu.
>
> Signed-off-by: Al Boldi <[EMAIL PROTECTED]>
> Cc: Alan Cox <[EMAIL PROTECTED]>
> ---
> --- a/drivers/Kconfig   2007-05-02 17:25:30.0 +0300
> +++ b/drivers/Kconfig   2007-08-01 06:33:13.0 +0300
> @@ -22,8 +22,6 @@ source "drivers/ide/Kconfig"
>
>  source "drivers/scsi/Kconfig"
>
> -source "drivers/ata/Kconfig"
> -
>  source "drivers/cdrom/Kconfig"
>
>  source "drivers/md/Kconfig"
> --- a/drivers/scsi/Kconfig  2007-07-09 06:38:37.0 +0300
> +++ b/drivers/scsi/Kconfig  2007-08-01 06:46:42.0 +0300
> @@ -7,6 +7,8 @@ config RAID_ATTRS
> ---help---
>   Provides RAID
>
> +source "drivers/ata/Kconfig"
> +
>  config SCSI
> -   tristate "SCSI device support"
> +   tristate "SCSI and Libata device support"
> depends on BLOCK

Actually, this should have read:

--- a/drivers/scsi/Kconfig  2007-07-09 06:38:37.0 +0300
+++ a/drivers/scsi/Kconfig  2007-09-09 06:48:11.0 +0300
@@ -1,4 +1,4 @@
-menu "SCSI device support"
+menu "SCSI and Libata (SATA/PATA/new IDE) device support"
 
 config RAID_ATTRS
tristate "RAID Transport Class"
@@ -7,6 +7,8 @@ config RAID_ATTRS
---help---
  Provides RAID
 
+source "drivers/ata/Kconfig"
+
 config SCSI
tristate "SCSI device support"
depends on BLOCK


I would think that with this minimal change it would make it crystal clear, 
to anybody who can read, where to enable libata support, and at the same 
time not to forget/overlook sd/sr selection.


Thanks!

--
Al

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

Re: broken ACPI NUMA config option

[James C. Georgas]

On Sat, 2007-08-09 at 18:16 -0700, Randy Dunlap wrote:

> 2.6.23-rc5-git1 builds for me when I follow those steps...
> except for some Section mismatch warnings.
> 

OK, it worked for me also, using torvalds/linux-2.6.git. The behaviour
of the "select" directive in Kconfig appears to have changed since
2.6.22.6. It now turns on ACPI, even when PM is not selected.

This still looks broken to me, because ACPI gets selected by ACPI_NUMA,
and ACPI depends on PM, but PM is not selected. It works out in the end,
as far as the build is concerned, but it still bugs me.

Does anyone object to the idea of a selected item automatically
selecting its own dependencies?

For example, you would only need to specify one "select" directive in
X86_64_ACPI_NUMA, (i.e. to turn on ACPI_NUMA). The configuration system
would then recursively walk up ACPI_NUMA's dependency hierarchy, turning
on what it needed.

James
/\V

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

Re: 2.6.23-rc3-mm1 - vdso and gettimeofday issues with glibc

[Valdis . Kletnieks]

On Sat, 08 Sep 2007 10:57:50 +0200, Andi Kleen said:

> vdso effectively only supports TSC and HPET (the other clock sources are not 
> accessible
> from ring 3)

Ahh.. that explains why acpi_pm clocksource doesn't trip over the problem


pgpZ3U1saEbaH.pgp
Description: PGP signature

Re: sk98lin for 2.6.23-rc1

[Kyle Rose]

> You are a regular reader of linux-kernel, and therefore the sk98lin 
> removal can hardly be a surprise for you. If you prefer whining over 
> helping to improve the kernel that's your choice...
>   
In my case the issue is simply one of practicality: I cannot go to the
data center 5 times per day to reboot my colo box.  Therefore, I run
sk98lin.  It's really that simple.

Kyle

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: broken ACPI NUMA config option

[James C. Georgas]

On Sat, 2007-08-09 at 18:16 -0700, Randy Dunlap wrote:
> On Sat, 8 Sep 2007 18:09:04 -0700 Randy Dunlap wrote:
> 
> > On Sat, 08 Sep 2007 18:51:39 -0400 James C. Georgas wrote:
> > 
> > > If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly)
selected
> > > automatically, but ACPI is not selected automatically. This causes
> > > ACPI_NUMA to not be built, and the kernel compile fails with
unresolved
> > > symbols.
> > 
> > exactly what kernel version??
> > 
> 
> 2.6.23-rc5-git1 builds for me when I follow those steps...
> except for some Section mismatch warnings.

What is the git project path name for the 2.6.23rc branch, if I wanted
to clone it, to keep up to date?

James
/\V

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

Problem charging blackberry 8700c with berry_charge (2.6.22.6)

[Matt LaPlante]

I'm running the 2.6.22.6 kernel with the berry_charge module loaded.  I connect 
my 8700c via USB, but the blackberry does not appear to charge. The power icon 
does not change, and even after staying connected for an extended period, the 
device does not appear to be gaining any power.  The cable is good, as I can 
plug it into my Windows machine and it begins charging immediately.  I see the 
following in dmesg:

[ 6638.606493] usb 1-2: new full speed USB device using uhci_hcd and address 2
[ 6638.776524] usb 1-2: configuration #1 chosen from 1 choice
[ 6639.639611] usbcore: registered new interface driver berry_charge
[ 6639.837097] usb 1-2: Second magic command failed: -71.
[ 6639.866430] usb 1-2: USB disconnect, address 2
[ 6640.610385] usb 1-2: new full speed USB device using uhci_hcd and address 3
[ 6640.775947] usb 1-2: configuration #1 chosen from 1 choice

I'd be glad to provide more information if needed.

-- 
Matt LaPlante
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: broken ACPI NUMA config option

[James C. Georgas]

On Sat, 2007-08-09 at 18:09 -0700, Randy Dunlap wrote:
> On Sat, 08 Sep 2007 18:51:39 -0400 James C. Georgas wrote:
> 
> > If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly) selected
> > automatically, but ACPI is not selected automatically. This causes
> > ACPI_NUMA to not be built, and the kernel compile fails with unresolved
> > symbols.
> 
> exactly what kernel version??
> 
> 

It's 2.6.22.6. I'm thinking a fix would be to add "select PM" to
X86_64_ACPI_NUMA.

I'm also thinking that maybe K8_NUMA should be changed from "depends on
PCI" to "select PCI", like X86_64_ACPI_NUMA is. That would fix the
pseudo dependency they have between them (i.e. selecting
X86_64_ACPI_NUMA causes PCI to be selected, which then makes K8_NUMA
visible, because its PCI dependency is now satisfied).

James
/\V

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: broken ACPI NUMA config option

[Randy Dunlap]

On Sat, 8 Sep 2007 18:09:04 -0700 Randy Dunlap wrote:

> On Sat, 08 Sep 2007 18:51:39 -0400 James C. Georgas wrote:
> 
> > If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly) selected
> > automatically, but ACPI is not selected automatically. This causes
> > ACPI_NUMA to not be built, and the kernel compile fails with unresolved
> > symbols.
> 
> exactly what kernel version??
> 

2.6.23-rc5-git1 builds for me when I follow those steps...
except for some Section mismatch warnings.


> > Steps to reproduce:
> > 
> > make clean
> > make mrproper
> > make noallconfig
> > 
> > select SMP
> > select NUMA
> > select X86_64_ACPI_NUMA
> > 
> > make
> > 
> > 
> > results:
> > 
> >   LD  .tmp_vmlinux1
> > drivers/built-in.o: In function `acpi_bus_generate_event':
> > (.text+0x23365): undefined reference to `event_is_open'
> > drivers/built-in.o: In function `acpi_bus_get_power':
> > (.text+0x2361d): undefined reference to `acpi_power_get_inferred_state'
> > drivers/built-in.o: In function `acpi_bus_set_power':
> > (.text+0x23733): undefined reference to `acpi_power_transition'
> > drivers/built-in.o: In function `acpi_bus_set_power':
> > (.text+0x237a5): undefined reference to `acpi_power_transition'
> > make: *** [.tmp_vmlinux1] Error 1
> 
> 
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: broken ACPI NUMA config option

[Randy Dunlap]

On Sat, 08 Sep 2007 18:51:39 -0400 James C. Georgas wrote:

> If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly) selected
> automatically, but ACPI is not selected automatically. This causes
> ACPI_NUMA to not be built, and the kernel compile fails with unresolved
> symbols.

exactly what kernel version??


> Steps to reproduce:
> 
>   make clean
>   make mrproper
>   make noallconfig
> 
>   select SMP
>   select NUMA
>   select X86_64_ACPI_NUMA
> 
>   make
>   
> 
> results:
> 
> LD  .tmp_vmlinux1
>   drivers/built-in.o: In function `acpi_bus_generate_event':
>   (.text+0x23365): undefined reference to `event_is_open'
>   drivers/built-in.o: In function `acpi_bus_get_power':
>   (.text+0x2361d): undefined reference to `acpi_power_get_inferred_state'
>   drivers/built-in.o: In function `acpi_bus_set_power':
>   (.text+0x23733): undefined reference to `acpi_power_transition'
>   drivers/built-in.o: In function `acpi_bus_set_power':
>   (.text+0x237a5): undefined reference to `acpi_power_transition'
>   make: *** [.tmp_vmlinux1] Error 1


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

Early userspace, Linux development (Re: perhaps init/ should update the reference to "change floppy")

[Oleg Verych]

* Sat, 8 Sep 2007 08:08:06 -0400 (EDT)
[]
>   from init/do_mounts_rd.c:
>
> ...
[]
> if (rd_prompt)
> change_floppy("root floppy disk to be loaded into RAM disk");
> create_dev("/dev/root", ROOT_DEV);
> create_dev("/dev/ram", MKDEV(RAMDISK_MAJOR, n));
> return rd_load_image("/dev/root");
> }
> ...
>
>   but isn't it a bit archaic to suggest that an explicit ramdisk will
> be found only on a floppy?  can't one be provided on a CD or DVD?
> just suggesting that the terminology could probably be updated.

All this is userspace code, ugly, unmaintained and all that kind of
things.

== Kernel panics without userspace, do you need such kernel? ==

The klibc project[0] was started 5 years ago to have usable kernel early
userspace with *usable* userspace. Status still unknown, but still better
than anything else in every distro, having NIH things just to boot-up
Linux.

[0] http://www.zytor.com/mailman/listinfo/klibc

I'd like to propose KJ as well as KN to look on that project and start to
be real userspace geeks first, before touching kernel and it's real
developers with (hopefully non-silly) stuff. Benefits:

* better understanding basic problems, like userspace API/ABIs
* know "how to" and actual produce tests easily
* improve development process: tools, ways of doing dev. thing, etc.
* have better results with kernel patches

My opinion is, that real developer must be very good user first. And
ordinary tools for that are shell, core utils (compare usage of it for
instance[1,2]). Having almost zero review of kernel development tools usage
and algos, complicated by people like Adrian[2], is not place to go in future
(and present, btw).

[1] http://marc.info/?l=linux-kernel&m=118868338702120
[2] http://marc.info/?l=linux-kernel&m=118911074923392

Only active kbuild developer -- Sam is almost always reply to poking
messages in form of "not much time for kernel-work"[2]. This is main
reasot to have kbuild system split per directory basis. Where most top
ones are actual subsystems. Scripting, inside those directories is due
of local developers/maintainers.

This includes needed CC/LD options checking and workarounds, maybe even
optimizations, if available. Traking of exported out kconfig sysmbols,
making sure nothing leaks, so no problems with dependency, if usage of
exports is agreed (e.g. usb and network). Local symbols must apear only
inside directory. This will simplyfy and speed up pre-build process. In
such configurations Intel developers may have their `imake` inside build
scripts if necessary :). Users may close loop by feed back what is
more approptiate for them in default options, tools.

Again, making sure, that tools are available is problem of local scripts.
Shell have `hash`, so hash all what is in use, and report problem before
any run. Checking versions has no problem at all. If nobody cares much
inside particular directory, then top configuration interface will show
this by means of time-stamp checks or something like that. Help messages
as well as scripts may have more information in categories, like

* users: "enable this, and you will do cool stuff, noone have!!!"

* testers: "run test1, 2, 3 and report if anything wrong after 896fg8"

* developers: "we do this this and that, because of foo and bar"

* distriutions: "state of this implementation/feature is buzz, we not
  sure it's stable for production on ARCH xBAZZ yFAZZ, etc."

Making UI for this is PITA, but ordinary text/stream editor is OK to
start with. I have more to say and show, but latter.

[3] http://marc.info/?l=linux-kernel&m=118777006621795

So, not seeing a tip of iceberg, Linux may hit very serious problems
due to this. And under own pressure in might collapse very easily.
Isn't it better to have Linux development as a nice place to spend
time comfortably, rather than running toward world domination, like
bulldozer, getting more and more burden? Did you saw that `MAINTAINERS'
patches?

Example is same guy -- Adrian, who refused to reply to any messages
regarding maintaining "util-linux". Yes, this is boring job, it's not
like to argue and saying in LKML to others what to do (see later [2]).
His great KJ efforts are known, but yet no tools, only text editor.
Denys has put everything together, including special kernel linking
magic. This bring individual developers way of monitoring of their
developed drivers/subsystems/other sources. Thus `make static` patches
may flow from exact developers, if they will know how to do it
(kconfig/ifdefery issue left out here).

I have nothing personal, just example.

I may or may not have success in my kbuild rewite[4], i don't care.
Anyway. I will start with klibc, using only klibc as tools and then
slowly transform build system to rapid kernel development some time
latter.

[4] http://marc.info/?l=linux-kernel&m=118885530622319

--
-o--=O`C
 #oo'L O
<___=E M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a

Re: 2.6.23-rc3-mm1 - vdso and gettimeofday issues with glibc

[Valdis . Kletnieks]

On Thu, 30 Aug 2007 12:27:10 EDT, Chuck Ebbert said:
> On 08/29/2007 07:15 PM, Andrew Morton wrote:
> >>> The issue:  vdso and gettimeofday seem to be having a quarrel.
> >> This is also open as a Fedora bug:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=262481
> >>
> > 
> > So it's an interaction between the x86_64 vdso patches in Andi's tree and 
> > newer glibc, and we don't know which one is getting it wrong yet?
> > 
> > If I ever get another -mm out the door (have been without electricity for
> > several days) I'll drop the vdso changes until this is sorted out.
> > -
> 
> Problem is present in stock 2.6.23-rc too. Still don't know whether it is
> the new glibc code or the vdso that's causing it, though.

Updating on this issue:   Both myself and another person have reported on
the RedHat bugzilla that it's a clocksource issue - if you are using the
hpet clocksource, the time warps, but booting with clocksource=acpi_pm works.

This ring any bells?



pgpxP6riopP3J.pgp
Description: PGP signature

Re: broken ACPI NUMA config option

[James C. Georgas]

On Sat, 2007-08-09 at 18:51 -0400, James C. Georgas wrote:
> If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly) selected
> automatically, but ACPI is not selected automatically. This causes
> ACPI_NUMA to not be built, and the kernel compile fails with unresolved
> symbols.
> 

Uh, it seems that I'm getting different results this time. Now,
X86_64_ACPI_NUMA does select ACPI, but PM (parent of ACPI) is not
automatically selected. Same result for the compile, though. Boom.

I seem to get different behaviour in general on subsequent runs of make
menuconfig.

For example, the last time I ran it, I was able to select K8_NUMA and
X86_64_ACPI_NUMA, independently of one another.

This time, though, the visibility of K8_NUMA is dependent on whether or
not X86_64_ACPI_NUMA is selected.

Should K8_NUMA and X86_64_ACPI_NUMA both be under NUMA, and independent
of one another?

James
/\V

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

[Alex Riesen]

Alex Riesen, Sat, Sep 08, 2007 20:12:13 +0200:
> Michal Piotrowski, Sat, Sep 08, 2007 01:18:10 +0200:
> > Hi Alex,
> > 
> > On 07/09/2007, Alex Riesen <[EMAIL PROTECTED]> wrote:
> > > Kernel: v2.6.23-rc5+ (b21010ed6498391c0f359f2a89c907533fe07fec)
> > 
> > Is this a post 2.6.22 regression?
> 

Probably not. I can kill the machine on 2.6.22.6 as good as on
2.6.23-rc5. Even without anything in log: just by trying to connect to
a server with players. Will try to connect a serial console tomorrow,
err... later today.

I saw this in logs once, but the machine was running after the BUG:

Sep  9 00:46:19 steel kernel: agpgart: Found an AGP 3.0 compliant device at 
:00:00.0.
Sep  9 00:46:19 steel kernel: agpgart: Putting AGP V3 device at :00:00.0 
into 8x mode
Sep  9 00:46:19 steel kernel: agpgart: Putting AGP V3 device at :01:00.0 
into 8x mode
Sep  9 00:46:19 steel kernel: [drm] Loading R200 Microcode
Sep  9 00:46:27 steel kernel: BUG: unable to handle kernel NULL pointer 
dereference at virtual address 0010
Sep  9 00:46:27 steel kernel:  printing eip:
Sep  9 00:46:27 steel kernel: f9c09bb2
Sep  9 00:46:27 steel kernel: *pde = 
Sep  9 00:46:27 steel kernel: Oops:  [#1]
Sep  9 00:46:27 steel kernel: PREEMPT SMP 
Sep  9 00:46:27 steel kernel: Modules linked in: binfmt_misc nfs radeon drm 
nfsd exportfs lockd sunrpc fan button firmware_class it87 hwmon_vid hwmon 
i2c_isa p4_clockmod speedstep_lib ipv6 sg sr_mod cdrom usb_storage snd_intel8x0 
snd_ac97_codec ac97_bus snd_pcm_oss snd_pcm snd_mixer_oss snd_seq_oss 
snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device 
snd soundcore generic floppy snd_page_alloc e100 ide_core ehci_hcd uhci_hcd 
intel_agp agpgart evdev
Sep  9 00:46:27 steel kernel: CPU:0
Sep  9 00:46:27 steel kernel: EIP:0060:[]Not tainted VLI
Sep  9 00:46:27 steel kernel: EFLAGS: 00210246   (2.6.22.6 #3)
Sep  9 00:46:27 steel kernel: EIP is at radeon_irq_wait+0xdf/0x138 [radeon]
Sep  9 00:46:27 steel kernel: eax:    ebx: f6c9dc00   ecx: f4f92000   
edx: 00200213
Sep  9 00:46:27 steel kernel: esi: 214c   edi: df23   ebp: f4f92f00   
esp: f4f92ed0
Sep  9 00:46:27 steel kernel: ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
Sep  9 00:46:27 steel kernel: Process bzflag (pid: 2616, ti=f4f92000 
task=f4d314c0 task.ti=f4f92000)
Sep  9 00:46:27 steel kernel: Stack: f6cae800 f9c14ba8 f4f92f00  
f4d314c0 c0114436 f6c9dd00 f6c9dd00 
Sep  9 00:46:27 steel kernel:214c f9c09ad3 0057 f9c14bd8 
f4f92f44 f996811c 082af558  
Sep  9 00:46:27 steel kernel:0003ddfe f4f92f34 c180e120 f4f92f40 
00200246 40046457 f4bf9a80 f6c1dbb0 
Sep  9 00:46:27 steel kernel: Call Trace:
Sep  9 00:46:27 steel kernel:  [show_trace_log_lvl+26/47] 
show_trace_log_lvl+0x1a/0x2f
Sep  9 00:46:27 steel kernel:  [show_stack_log_lvl+157/165] 
show_stack_log_lvl+0x9d/0xa5
Sep  9 00:46:27 steel kernel:  [show_registers+497/818] 
show_registers+0x1f1/0x332
Sep  9 00:46:27 steel kernel:  [die+272/529] die+0x110/0x211
Sep  9 00:46:27 steel kernel:  [do_page_fault+1061/1268] 
do_page_fault+0x425/0x4f4
Sep  9 00:46:27 steel kernel:  [error_code+114/120] error_code+0x72/0x78
Sep  9 00:46:27 steel kernel:  [] drm_ioctl+0x154/0x19c [drm]
Sep  9 00:46:27 steel kernel:  [do_ioctl+139/163] do_ioctl+0x8b/0xa3
Sep  9 00:46:27 steel kernel:  [vfs_ioctl+562/581] vfs_ioctl+0x232/0x245
Sep  9 00:46:27 steel kernel:  [sys_ioctl+49/72] sys_ioctl+0x31/0x48
Sep  9 00:46:27 steel kernel:  [sysenter_past_esp+95/133] 
sysenter_past_esp+0x5f/0x85
Sep  9 00:46:27 steel kernel:  ===
Sep  9 00:46:27 steel kernel: Code: a1 00 fe 3a c0 8d b8 84 03 00 00 8d 83 ec 
00 00 00 8d 55 dc e8 91 f2 51 c6 64 a1 00 d0 3e c0 c7 00 01 00 00 00 8b 83 d4 
00 00 00 <8b> 40 10 8b 80 ec 15 00 00 39 f0 73 9b a1 00 fe 3a c0 39 f8 79 
Sep  9 00:46:27 steel kernel: EIP: [] radeon_irq_wait+0xdf/0x138 
[radeon] SS:ESP 0068:f4f92ed0


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: bogomips discrepancy on Intel Core2 Quad CPU

[Bauke Jan Douma]

Bill Davidsen wrote on 03-09-07 16:47:

Bauke Jan Douma wrote:

$> uname -a
Linux skyscraper 2.6.22.5 #7 SMP PREEMPT Sun Sep 2 12:12:25 CEST 2007 
i686 GNU/Linux


$> cat /proc/cpuinfo | grep bogomips
bogomips: 4813.46
bogomips: 4810.91
bogomips: 4810.91
bogomips: 10583.94

The latter seems way off base.
Prod me for more info.

I see this occasionally on a dual, speedstep (or similar) finds a way to 
throttle down the cores under light load. I suspect that if you load the 
system:


  for n in 1 2 3 4; do
nice -19 bash -c 'while true; do a=$RANDOM; done' &
  done

Then you should see your bogomips rise on all cores.


Sorry for now getting back on this sooner.  Other matters forced it to
the backburner.

I don't have Speedstep enabled on this machine's kernel (as a matter
of fact, the entire cpufreq Kconfig subtree is unchecked). Needless to
say running your bash script doesn't change the values in any way.

I'd say the 4800-something bogomips value is the correct one (for a
2.4GHz CPU -- at least that's what I recall on single-CPU machines,
mostly bogomips being approx. twice the rated CPU speed), and the
1-something is the one off base.

Btw., the 1 can be something like 12000-odd after a machine reboot,
and readout on a different CPU.  The rest are all ca. 4810. Odd indeed.

bjd

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: broken ACPI NUMA config option

[James C. Georgas]

On Sat, 2007-08-09 at 18:51 -0400, James C. Georgas wrote:
> Steps to reproduce:
> 
>   make clean
>   make mrproper
>   make noallconfig

Excuse me; that should read allnoconfig, not noallconfig.

James
/\V

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: USB and MMC device problems on Kernel 2.6.22

[Jan Engelhardt]

On Sep 9 2007 08:28, [EMAIL PROTECTED] wrote:
>
> I have an ARM hardware board works fine with USB and MMC on kernel
> 2.6.11. Now, I've just upgraded it to kernel 2.6.22. The modules
> seem loaded fine, please see following list, but neither USB nor
> MMC could detect devices when a USB stick or SD card was plugged in

If it detects something, it should show up in `lsusb`.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

broken ACPI NUMA config option

[James C. Georgas]

If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly) selected
automatically, but ACPI is not selected automatically. This causes
ACPI_NUMA to not be built, and the kernel compile fails with unresolved
symbols.

Steps to reproduce:

make clean
make mrproper
make noallconfig

select SMP
select NUMA
select X86_64_ACPI_NUMA

make


results:

  LD  .tmp_vmlinux1
drivers/built-in.o: In function `acpi_bus_generate_event':
(.text+0x23365): undefined reference to `event_is_open'
drivers/built-in.o: In function `acpi_bus_get_power':
(.text+0x2361d): undefined reference to `acpi_power_get_inferred_state'
drivers/built-in.o: In function `acpi_bus_set_power':
(.text+0x23733): undefined reference to `acpi_power_transition'
drivers/built-in.o: In function `acpi_bus_set_power':
(.text+0x237a5): undefined reference to `acpi_power_transition'
make: *** [.tmp_vmlinux1] Error 1

James
/\V

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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' IEEE 1394/ FireWire subsystem TODO list

[Natalie Protasevich]

On 9/8/07, Stefan Richter <[EMAIL PROTECTED]> wrote:
> Hi lists,
>
> I copied the ancient linux1394 project TODO list from the static page at
> www.linux1394.org over to http://wiki.linux1394.org/ToDo and
> substantially updated it now.  I certainly missed a few important TODOs
> and ideas, but the list is quite long nevertheless.  I thought of
> posting a FireWire driver status report to LKML recently --- so I am
> simply posting the TODO list now.  Another page related to FireWire
> driver development status is http://wiki.linux1394.org/JujuMigration .
>
> Reply or edit the wiki if you have additions or disagree with a TODO
> item.  AFAIK wiki.linux1394.org does not require registration for
> editing.
>
>
>   Linux1394 Project TODO List
>
> See our list of bugs
> 
> at bugzilla.kernel.org. There are also bugs filed in distributors' bug
> trackers but they are not as easy to query.
>
> Contents
>
>   IEEE1394 Subsystem (a.k.a. Linux1394 driver stack)
> * subsystem and core driver
> * sbp2
> * ether1394
> * raw1394
>   FireWire subsystem (a.k.a. Juju driver stack)
> * support in userspace
> * subsystem and core driver
> * firewire-ohci
> * firewire-sbp2
>
> 
>
>
> IEEE1394 Subsystem (a.k.a. Linux1394 driver stack)
>
>
>   subsystem and core driver
>
> * Bug 8403 : If
>   several Linux boxes are plugged into the same bus, they may go
>   multiple forced bus resets, fighting over who gets to be IRM. Our
>   IRM code is too pessimistic if errors happen when querying the
>   remote IRM for its capabilities.
>
> * Handle same node being connected to multiple local hosts
>   (multi-pathing).
>
>
>   sbp2
>
> * Bug 1872 : Fix
>   serialize_io=0.
>
> * Implement per-node queueing options.
>
>   Also see sbp2's TODO list in the source
>   .
>
>
>   ether1394
>
> * Improve reliability (bug 8361
>   , bug 8704
>   ). Fix "Waking
>   dma ctx=0 ... processing is probably too slow", perhaps by
>   increasing the AR DMA buffer size in ohci1394.
>
> * Implement MCAP and multicast support.
>
>
>   raw1394
>
> * Bug 4779 : Test
>   and fix 32bit userland on 64bit kernel. It appears that only
>   address range mapping is still buggy as of Linux 2.6.23.
>
> * Implement access to RAW1394_REQ_MODIFY_ROM in libraw1394. This
>   should be used instead of RAW1394_REQ_UPDATE_ROM. Make sure that
>   the RAW1394_REQ_MODIFY_ROM accessor can be ported to the ROM
>   manipulation ioctl of the new firewire-core ABI, which should
>   eventually be fully supported by libraw1394 too.
>
> 
>
>
> FireWire subsystem (a.k.a. Juju driver stack)
>
>
>   support in userspace
>
> * Finish support by libraw1394.
>
> * Add support in libdc1394 v1?
>
> * Add support in FFmpeg's libavformat.
>
>
>   subsystem and core driver
>
> * Replace fw_notify() and fw_error() (defined in
>   drivers/firewire/fw-transaction.h) by dev_notice() and dev_err()
>   (defined in include/linux/device.h).
>
> * Implement IPv4 over FireWire as per RFC 2734, i.e. port the
>   functionality of eth1394 to the new driver stack. But try not to
>   port eth1394's bugs too.
>
> * Add IPv6 support as per RFC 3146.
>
> * Implement an SBP-2 target using the in-kernel SCSI target
>   framework as an alternative to Endpoint (Oracle's SBP-2 target
>   implementation in userspace).
>
>
>   firewire-ohci
>
> * Implement isochronous I/O for OHCI 1.0 compliant chips (such as
>   VIA VT6306 and chips from NEC and Ricoh which are not OHCI 1.1
>   compliant). That is, implement a mode which does not require
>   dual-buffer IR DMA.
>
> * Bug 8828 : Come
>   up with a quirk fix for NForce2. The person to do so will most
>   certainly require direct access to this hardware. Note, the
>   NForce2 workaround in ohci1394 is unacceptable by today's
>   standards as it involves busy-waiting in the interrupt handler.
>   Either we find something better for firewire-ohci, or NForce2
>   remains unsupported in firewire-ohci.
>
> * Quirk fix for old Apple UniNorth adapters?
>
> * There seem to be issues with ALi controllers.
>
>
>   firewire-sbp2
>
> * Eliminate calls to fw_memcpy_to_be32() by directly writing in big
>   endian into struc

USB and MMC device problems on Kernel 2.6.22

[development . jim]

Sorry for not clear about the kernel version, let me try again:

I have an ARM hardware board works fine with USB and MMC on kernel 
2.6.11. Now, I've just upgraded it to kernel 2.6.22. The modules seem 
loaded fine, please see following list, but neither USB nor MMC could 
detect devices when a USB stick or SD card was plugged in (I enabled 
module debug, but nothing printed out, no device node created in /dev). 
It seems some processes were not running, but I can see usbd and mmcd 
were running at following list, or what is missing?



K22 $ ps
  PID  Uid VmSize Stat Command
1 root268 S   init
2 rootSW< [kthreadd]
3 rootSWN [ksoftirqd/0]
4 rootSW< [events/0]
5 rootSW< [khelper]
   31 rootSW< [kblockd/0]
   32 rootSW< [ksuspend_usbd]
   35 rootSW< [khubd]
   37 rootSW< [kseriod]
   49 rootSW  [pdflush]
   50 rootSW  [pdflush]
   51 rootSW< [kswapd0]
   52 rootSW< [aio/0]
  638 rootSW< [kapmd]
  670 rootSW< [mtdblockd]
  693 rootSW< [s3c2410-spi.1]
  710 rootSW< [kbd_queue/0]
  746 rootSW< [kmmcd]
  775 root644 S   /bin/inetd -f
  776 root404 S   /bin/sh
  790 root324 R   ps


I understand that the devfs is no longer supported by the kernel 2.6.22, 
but should the modules still be able to detect the devices? I manually 
created nodes on /dev tree such as /dev/mmc /dev/scsi before building 
and downloading to the target. Any clues please?


K22 $ lsmod
Module  Size  Used by
nls_utf81696  0
nls_iso8859_1   3936  0
nls_cp437   5600  0
nls_ascii   3936  0
vfat   10336  0
fat48028  1 vfat
mmc_block   8580  0
s3c2410mci  6560  0
mmc_core   25876  2 mmc_block,s3c2410mci


Thank you.

Jim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-usb-devel] 2.6.23-rc3 USB segfaults + urb status -32

[Alan Stern]

On Sun, 9 Sep 2007, Lasse Kärkkäinen wrote:

> Sorry about late reply. I have been extremely busy with other things.
> 
> > Does 2.6.22 work fine?
> 
> Not perfect, but it does not crash spontaneously. I have been running
> 2.6.22-ck1 since my last email with only one crash and today I have
> tortured 2.6.22.5 as badly as I can (switching bConfigurationValue of
> the sound card, unplugging USB devices on fly, doing heavy I/O, etc),
> without crashes.
> 
> However, with 2.6.23-rc5 I still got segfaults on boot¹ (log1),

Those were problems with the usb_id program, not problems in the 
kernel.  How up-to-date is your udev installation?

> a few
> dozen urb status -32 messages by powering off the sound card while it
> was in use (log2),

Nothing wrong with that.  You should expect that removing a device 
while it is use would produce a few error messages.

> but no crashes there. It did finally crash (log3),
> though, after about three hours of coding + listening to music on text
> console (no Nvidia drivers nor any other external modules). Apparently
> it reset all USB buses, including the one that my system disk is
> connected to (there is nothing else on the same port), effectively
> killing the system, even though technically it didn't crash.

There's no indication in the log that the disk problem was at all
related to the sound card.  Nor is there any indication that all your
USB buses were affected; only the disk drive got messed up.  The card
reader, the hub, the keyboard, and the mouse all seem to have survived.

> It also seems that .23-rc5 no longer exposes bConfigurationValue and a
> few other settings under /sys/bus/usb/devices/*/,

Sure it does.

> so I couldn't test if
> switching the bConfigurationValue of the sound card still causes
> crashes² there (it has been a reliable way to do that in the past).
> 
> I could not reproduce the excessive log flood of urb status -32,
> mentioned in my original message.
> 
> The logs are here:
> http://delenn.homelinux.net/kernel-usb/
> 
> ¹) I gather that usb_id is something related to udev. It does not crash
> with .22 kernels, only with the .23 series.
> ²) OOPSes, to be specific, IIRC.

The events in your logs are not oopses.  The program segfaults, which
means that the crash occurs in userspace, not while the program is
running in the kernel.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [NFS] [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945

[Trond Myklebust]

On Sat, 2007-09-08 at 01:56 +0200, Michal Piotrowski wrote:
> Hi,
> 
> On 07/09/2007, Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> > Sep  7 11:42:49 p55lp2 kernel: kernel BUG at fs/nfs/nfs4xdr.c:945!
> > Sep  7 11:42:49 p55lp2 kernel: Oops: Exception in kernel mode, sig: 5 [#1]
> > Sep  7 11:42:49 p55lp2 kernel: SMP NR_CPUS=128 NUMA pSeries
> > Sep  7 11:42:49 p55lp2 kernel: Modules linked in: nfs lockd nfs_acl
> > sunrpc ipv6 loop dm_mod ibmveth sg ibmvscsic sd_mod scsi_mod
> > Sep  7 11:42:49 p55lp2 kernel: NIP: d0378044 LR:
> > d0378034 CTR: 801c5840
> > Sep  7 11:42:49 p55lp2 kernel: REGS: c000d971b050 TRAP: 0700   Not
> > tainted  (2.6.23-rc5-ppc64)
> > Sep  7 11:42:49 p55lp2 kernel: MSR: 80029032   CR:
> > 28000444  XER: 0014
> > Sep  7 11:42:49 p55lp2 kernel: TASK = c2787740[11508] 'fsstress'
> > THREAD: c000d9718000 CPU: 1
> > Sep  7 11:42:49 p55lp2 kernel: GPR00: 0001 c000d971b2d0
> > d03bd648 0037
> > Sep  7 11:42:49 p55lp2 kernel: GPR04:  
> >  
> > Sep  7 11:42:49 p55lp2 kernel: GPR08: 0002 c0616538
> > c000ef7afb58 c0616540
> > Sep  7 11:42:49 p55lp2 kernel: GPR12: 4000 c05e4a80
> >  200b2510
> > Sep  7 11:42:49 p55lp2 kernel: GPR16: 20105550 200b2534
> > 2008c15c 0001
> > Sep  7 11:42:49 p55lp2 kernel: GPR20:  0001
> > f000 c000d971ba30
> > Sep  7 11:42:49 p55lp2 kernel: GPR24: d034f524 c000dc4f8054
> > c000d971b7d0 c000d9d313f0
> > Sep  7 11:42:49 p55lp2 kernel: GPR28: 0276 2200
> > d03b8d78 
> > Sep  7 11:42:49 p55lp2 kernel: NIP [d0378044]
> > .encode_lookup+0x6c/0xbc [nfs]
> > Sep  7 11:42:49 p55lp2 kernel: LR [d0378034]
> > .encode_lookup+0x5c/0xbc [nfs]
> > Sep  7 11:42:49 p55lp2 kernel: Call Trace:
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971b2d0] [d0378034]
> > .encode_lookup+0x5c/0xbc [nfs] (unreliable)
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971b370] [d0379f8c]
> > .nfs4_xdr_enc_lookup+0x78/0xbc [nfs]
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971b440] [d0314534]
> > .rpcauth_wrap_req+0xe4/0x124 [sunrpc]
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971b4f0] [d030a790]
> > .call_transmit+0x218/0x2b8 [sunrpc]
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971b590] [d03124d8]
> > .__rpc_execute+0xd4/0x368 [sunrpc]
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971b630] [d030b114]
> > .rpc_do_run_task+0xc8/0x104 [sunrpc]
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971b6e0] [d030b224]
> > .rpc_call_sync+0x2c/0x64 [sunrpc]
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971b760] [d036ef04]
> > ._nfs4_proc_lookupfh+0xd4/0x124 [nfs]
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971b850] [d03719a0]
> > ._nfs4_proc_lookup+0x80/0x21c [nfs]
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971b910] [d0371ba4]
> > .nfs4_proc_lookup+0x68/0xac [nfs]
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971b9c0] [d0354bf4]
> > .nfs_lookup+0x158/0x334 [nfs]
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971bbc0] [c00f3a28]
> > .lookup_hash+0xfc/0x140
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971bc60] [c00f7b28]
> > .sys_renameat+0x164/0x228
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971be30] [c0008534]
> > syscall_exit+0x0/0x40
> > Sep  7 11:42:49 p55lp2 kernel: Instruction dump:
> > Sep  7 11:42:49 p55lp2 kernel: e8410028 7fa4eb78 7c7f1b79 7fb80026
> > 40820014 e8be83a8 e87e8350 4800c5f9
> > Sep  7 11:42:49 p55lp2 kernel: e8410028 7fb80120 7c180026 54001ffe
> > <0b00> 380f 7b850020 387f0008
> 
> Is this a post 2.6.22 regression? Have you tried 2.6.23-rc5-git1?
> (There are a few nfs fixes)
> 
> Regards,
> Michal

It looks like a bug that has been there at least since 2.6.18. Could you
see if this fixes it?

Trond


--- Begin Message ---
It doesn't look as if the NFSv4 name length is being initialised correctly
in the struct nfs_server. We need to limit any entry there to
NFS4_MAXNAMLEN.

Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]>
---

 fs/nfs/client.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/fs/nfs/client.c b/fs/nfs/client.c
index a49f9fe..54068fb 100644
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -928,6 +928,9 @@ static int nfs4_init_server(struct nfs_server *server,
 
error = nfs_init_server_rpcclient(server, authflavour);
 
+   if (server->namelen == 0 || server->namelen > NFS4_MAXNAMLEN)
+   server->namelen = NFS4_MAXNAMLEN;
+
/* Done */
dprintk("<-- nfs4_init_server() = %d\n", error);
return error;
--- End Message ---

Re: [PATCH] net: myri10ge: force select inet_lro

[David Miller]

From: Daniel Walker <[EMAIL PROTECTED]>
Date: Sat, 08 Sep 2007 09:03:06 -0700

> Did your fix go to LKML ?

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

Re: 2.6.23-rc3 USB segfaults + urb status -32

[Lasse Kärkkäinen]

Sorry about late reply. I have been extremely busy with other things.

> Does 2.6.22 work fine?

Not perfect, but it does not crash spontaneously. I have been running
2.6.22-ck1 since my last email with only one crash and today I have
tortured 2.6.22.5 as badly as I can (switching bConfigurationValue of
the sound card, unplugging USB devices on fly, doing heavy I/O, etc),
without crashes.

However, with 2.6.23-rc5 I still got segfaults on boot¹ (log1), a few
dozen urb status -32 messages by powering off the sound card while it
was in use (log2), but no crashes there. It did finally crash (log3),
though, after about three hours of coding + listening to music on text
console (no Nvidia drivers nor any other external modules). Apparently
it reset all USB buses, including the one that my system disk is
connected to (there is nothing else on the same port), effectively
killing the system, even though technically it didn't crash.

It also seems that .23-rc5 no longer exposes bConfigurationValue and a
few other settings under /sys/bus/usb/devices/*/, so I couldn't test if
switching the bConfigurationValue of the sound card still causes
crashes² there (it has been a reliable way to do that in the past).

I could not reproduce the excessive log flood of urb status -32,
mentioned in my original message.

The logs are here:
http://delenn.homelinux.net/kernel-usb/

¹) I gather that usb_id is something related to udev. It does not crash
with .22 kernels, only with the .23 series.
²) OOPSes, to be specific, IIRC.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Suspend and hibernation status report

[Rafael J. Wysocki]

On Wednesday, 5 September 2007 01:32, Len Brown wrote:
> On Friday 27 July 2007 04:57, Rafael J. Wysocki wrote:
> 
> Thanks for writing this, Rafael.
> 
> > * system hibernation state - state, in which the system's processors are 
> > off and
> >   its main memory is not powered, but the information necessary for 
> > continuing
> >   the computations carried out when the system was last in a working state 
> > is
> >   preserved in a storage space, such as a disk
> > * ACPI S4 state - system hibernation state, in which some information is
> >   preserved by the ACPI platform, in accordance with the ACPI specification
> 
> "some information is preserved by the ACPI platform" is sort of mis-leading.
> What ACPI adds to the hibernate flow is some platform hooks to handle
> wakeup devices, and a platform hook for the actual sleep request.
> I'm not aware of any information saved by ACPI during S4 that is
> not saved were the hibernate to be done with "acpi=off".

Well, I am.

On HPC nx6325 the status of AC adapter after the restore is not reported
correctly if hibernation is done without the ACPI hooks (eg. if you hibernate
with the AC connected and then disconnect it and resume, it will still be
reported as connected until you plug/unplug it).

There are more machines that behave similarly, AFAICT.

Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Disk spin down issue on shut down/suspend to disk

[Rafael J. Wysocki]

On Saturday, 8 September 2007 17:32, Michal Piotrowski wrote:
> Hi,
> 
> On 05/08/2007, Michał sed <[EMAIL PROTECTED]> wrote:
> > Greetings
> >
> > I'm experiencing double disk spin down issue on my HP nx6310 laptop
> > during shut down and suspend to disk. The drive is power down on "Will
> > now halt message" then turned back on and off again with the laptop
> > itself. I'm using the newest bios available F.0D, 2.6.23-rc1-mm kernel
> > along with Debian Unstable plus fixes from Sidux repository so I have
> > the updated shut down script. I have also verified on two other
> > systems [AMD/Nforce based] that the spin down issue has been resolved
> > by the Sidux update and I'm certain that this is a hp bios bug or a
> > piix kernel module problem.
> >
> 
> What is the _actual_ state of this bug? Does anyone work on this?
> 
> I see the report
> http://lkml.org/lkml/2007/8/5/214
> 
> and a very long thread
> http://lkml.org/lkml/2007/8/6/4
> 
> dmidecode stuff
> http://bugzilla.kernel.org/show_bug.cgi?id=8855
> 
> and _only_one_fix_ - for Suspend To Disc (thanks Rafael)
> http://lkml.org/lkml/2007/8/7/316

There's an updated version of that patch at
http://lkml.org/lkml/2007/8/27/392
 
> Shutdown is completely broken on HP NX6??? laptops.

It's not completely broken, it just handles disks incorrectly and we are not
sure whether or not there are any serious consequences of that.  Moreover,
it has happened for a long time now, AFAICT, so that's not a regression.

BTW, in my opinion, we don't really understand why the patch at
http://lkml.org/lkml/2007/8/27/392 actually helps and understanding that might
allow us to fix the problem in general.

Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Intel Memory Ordering White Paper

[H. Peter Anvin]

Nick Piggin wrote:

smp_rmb() should not need to do anything because loads are done
in order anyway. Both AMD and Intel have committed to this now.

The important point is that they *appear* to be done in order. AFAIK,
the CPUs can still do speculative and out of order loads, but throw
out the results if they could be wrong.


Is there anything even semiofficial from VIA?  Not that the x86 
architecture isn't pretty much definable as the AMD-Intel consensus...


-hpa

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

Re: [PATCH] prevent kswapd from freeing excessive amounts of lowmem

[Rik van Riel]

Pavel Machek wrote:

Hi!

The current VM can get itself into trouble fairly easily 
on systems
with a small ZONE_HIGHMEM, which is common on i686 
computers with

1GB of memory.

On one side, page_alloc() will allocate down to 
zone->pages_low,
while on the other side, kswapd() and balance_pgdat() 
will try
to free memory from every zone, until every zone has 
more free

pages than zone->pages_high.

Highmem can be filled up to zone->pages_low with page 
tables,
ramfs, vmalloc allocations and other unswappable things 
quite
easily and without many bad side effects, since we still 
have

a huge ZONE_NORMAL to do future allocations from.

However, as long as the number of free pages in the 
highmem
zone is below zone->pages_high, kswapd will continue 
swapping

things out from ZONE_NORMAL, too!

Sami Farin managed to get his system into a stage where 
kswapd
had freed about 700MB of low memory and was still "going 
strong".


The attached patch will make kswapd stop paging out data 
from
zones when there is more than enough memory free.  We do 
go above
zone->pages_high in order to keep pressure between zones 
equal
in normal circumstances, but the patch should prevent 
the kind

of excesses that made Sami's computer totally unusable.

Please merge this into -mm.

Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>



--- linux-2.6.22.noarch/mm/vmscan.c.excessive   2007-09-05 12:19:49.0 
-0400
+++ linux-2.6.22.noarch/mm/vmscan.c 2007-09-05 12:21:40.0 -0400
@@ -1371,7 +1371,13 @@ loop_again:
temp_priority[i] = priority;
sc.nr_scanned = 0;
note_zone_scanning_priority(zone, priority);
-   nr_reclaimed += shrink_zone(priority, zone, &sc);
+   /*
+* We put equal pressure on every zone, unless one
+* zone has way too many pages free already.
+*/


That does not seem right. Having empty HIGHMEM and full LOWMEM would
be very bad, right? We may stop freeing when there's enough LOWMEM
free, but not if there's only HIGHMEM free.


Please read the code this patch applies to.

The check I add conditionalizes the individual
calls to shrink_zone(), so we do not call
shrink_zone() for a zone that has a ton of free
pages.  We still call shrink_zone() for the
other zones.

--
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] forbid asm/bitops.h direct inclusion

[Jiri Slaby]

forbid asm/bitops.h direct inclusion

Because of compile errors that may occur after bit changes if asm/bitops.h is
included directly without e.g. linux/kernel.h which includes linux/bitops.h, 
forbid
direct inclusion of asm/bitops.h. Thanks to Adrian Bunk.

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

---
commit cd28a228ae727b2224da736edc613c58a08c5ed9
tree 483ca1765baaf80996484889ed3078c4af24be03
parent 3c05eef3d0a98065323d7d6d9a78e0985eba4b10
author Jiri Slaby <[EMAIL PROTECTED]> Sat, 08 Sep 2007 21:02:48 +0200
committer Jiri Slaby <[EMAIL PROTECTED]> Sat, 08 Sep 2007 21:02:48 +0200

 include/asm-alpha/bitops.h |4 
 include/asm-arm/bitops.h   |4 
 include/asm-avr32/bitops.h |4 
 include/asm-blackfin/bitops.h  |4 
 include/asm-cris/bitops.h  |4 
 include/asm-frv/bitops.h   |4 
 include/asm-generic/bitops.h   |4 
 include/asm-h8300/bitops.h |5 +
 include/asm-i386/bitops.h  |4 
 include/asm-ia64/bitops.h  |4 
 include/asm-m32r/bitops.h  |4 
 include/asm-m68k/bitops.h  |4 
 include/asm-m68knommu/bitops.h |4 
 include/asm-mips/bitops.h  |4 
 include/asm-parisc/bitops.h|4 
 include/asm-powerpc/bitops.h   |4 
 include/asm-s390/bitops.h  |4 
 include/asm-sh/bitops.h|5 +
 include/asm-sh64/bitops.h  |5 +
 include/asm-sparc/bitops.h |4 
 include/asm-sparc64/bitops.h   |4 
 include/asm-um/bitops.h|4 
 include/asm-v850/bitops.h  |3 +++
 include/asm-x86_64/bitops.h|4 
 include/asm-xtensa/bitops.h|4 
 25 files changed, 102 insertions(+), 0 deletions(-)

diff --git a/include/asm-alpha/bitops.h b/include/asm-alpha/bitops.h
index ffec8a8..6490e50 100644
--- a/include/asm-alpha/bitops.h
+++ b/include/asm-alpha/bitops.h
@@ -1,6 +1,10 @@
 #ifndef _ALPHA_BITOPS_H
 #define _ALPHA_BITOPS_H
 
+#ifndef _LINUX_BITOPS_H
+#error only  can be included directly
+#endif
+
 #include 
 
 /*
diff --git a/include/asm-arm/bitops.h b/include/asm-arm/bitops.h
index 52fe058..47a6b08 100644
--- a/include/asm-arm/bitops.h
+++ b/include/asm-arm/bitops.h
@@ -19,6 +19,10 @@
 
 #ifdef __KERNEL__
 
+#ifndef _LINUX_BITOPS_H
+#error only  can be included directly
+#endif
+
 #include 
 #include 
 
diff --git a/include/asm-avr32/bitops.h b/include/asm-avr32/bitops.h
index f3faddf..1a50b69 100644
--- a/include/asm-avr32/bitops.h
+++ b/include/asm-avr32/bitops.h
@@ -8,6 +8,10 @@
 #ifndef __ASM_AVR32_BITOPS_H
 #define __ASM_AVR32_BITOPS_H
 
+#ifndef _LINUX_BITOPS_H
+#error only  can be included directly
+#endif
+
 #include 
 #include 
 
diff --git a/include/asm-blackfin/bitops.h b/include/asm-blackfin/bitops.h
index 03ecedc..b39a175 100644
--- a/include/asm-blackfin/bitops.h
+++ b/include/asm-blackfin/bitops.h
@@ -11,6 +11,10 @@
 
 #ifdef __KERNEL__
 
+#ifndef _LINUX_BITOPS_H
+#error only  can be included directly
+#endif
+
 #include 
 #include 
 #include 
diff --git a/include/asm-cris/bitops.h b/include/asm-cris/bitops.h
index 617151b..e2f49c2 100644
--- a/include/asm-cris/bitops.h
+++ b/include/asm-cris/bitops.h
@@ -14,6 +14,10 @@
 /* Currently this is unsuitable for consumption outside the kernel.  */
 #ifdef __KERNEL__ 
 
+#ifndef _LINUX_BITOPS_H
+#error only  can be included directly
+#endif
+
 #include 
 #include 
 #include 
diff --git a/include/asm-frv/bitops.h b/include/asm-frv/bitops.h
index 8dba74b..e29de71 100644
--- a/include/asm-frv/bitops.h
+++ b/include/asm-frv/bitops.h
@@ -21,6 +21,10 @@
 
 #ifdef __KERNEL__
 
+#ifndef _LINUX_BITOPS_H
+#error only  can be included directly
+#endif
+
 #include 
 
 /*
diff --git a/include/asm-generic/bitops.h b/include/asm-generic/bitops.h
index e022a0f..15e6f25 100644
--- a/include/asm-generic/bitops.h
+++ b/include/asm-generic/bitops.h
@@ -19,6 +19,10 @@
 
 #ifdef __KERNEL__
 
+#ifndef _LINUX_BITOPS_H
+#error only  can be included directly
+#endif
+
 #include 
 #include 
 #include 
diff --git a/include/asm-h8300/bitops.h b/include/asm-h8300/bitops.h
index e64ad31..cb18e3b 100644
--- a/include/asm-h8300/bitops.h
+++ b/include/asm-h8300/bitops.h
@@ -10,6 +10,11 @@
 #include 
 
 #ifdef __KERNEL__
+
+#ifndef _LINUX_BITOPS_H
+#error only  can be included directly
+#endif
+
 /*
  * Function prototypes to keep gcc -Wall happy
  */
diff --git a/include/asm-i386/bitops.h b/include/asm-i386/bitops.h
index c96641f..3268a34 100644
--- a/include/asm-i386/bitops.h
+++ b/include/asm-i386/bitops.h
@@ -5,6 +5,10 @@
  * Copyright 1992, Linus Torvalds.
  */
 
+#ifndef _LINUX_BITOPS_H
+#error only  can be included directly
+#endif
+
 #include 
 #include 
 
diff --git a/include/asm-ia64/bitops.h b/include/asm-ia64/bitops.h
index 2144f1a..a977aff 100644
--- a/include/asm-ia64/bitops.h
+++ b/include/asm-ia64/bitops.h
@@ -9,6 +9,10 @@
  * O(1) scheduler patch
  */
 
+#ifndef _LINUX_BITOPS_H
+#error only  can be inc

[PATCH 1/2] remove asm/bitops.h includes

[Jiri Slaby]

remove asm/bitops.h includes

including asm/bitops directly may cause compile errors. don't include it
and include linux/bitops instead. next patch will deny including asm header
directly.

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

---
commit 3c05eef3d0a98065323d7d6d9a78e0985eba4b10
tree cb9691832992f570b0363dd568f6fa3d2c81e3f5
parent 132bb039c741d00f066e7501e3613d2d20bf0595
author Jiri Slaby <[EMAIL PROTECTED]> Tue, 04 Sep 2007 21:01:35 +0200
committer Jiri Slaby <[EMAIL PROTECTED]> Tue, 04 Sep 2007 21:01:35 +0200

 arch/alpha/lib/fls.c|2 +-
 arch/frv/kernel/irq-mb93091.c   |2 +-
 arch/frv/kernel/irq-mb93093.c   |2 +-
 arch/frv/kernel/irq-mb93493.c   |2 +-
 arch/frv/kernel/irq.c   |2 +-
 arch/mips/au1000/pb1200/irqmap.c|2 +-
 arch/mips/basler/excite/excite_irq.c|2 +-
 arch/mips/gt64120/wrppmc/irq.c  |1 -
 arch/mips/tx4938/common/setup.c |2 +-
 arch/powerpc/platforms/maple/setup.c|2 +-
 drivers/char/esp.c  |2 +-
 drivers/char/mxser.c|2 +-
 drivers/char/mxser_new.c|2 +-
 drivers/ide/ide-io.c|2 +-
 drivers/media/dvb/ttpci/av7110_ir.c |2 +-
 drivers/net/bnx2.c  |2 +-
 drivers/net/cris/eth_v10.c  |2 +-
 drivers/net/cxgb3/adapter.h |2 +-
 drivers/net/hamradio/dmascc.c   |2 +-
 drivers/net/mac89x0.c   |2 +-
 drivers/net/spider_net.c|2 +-
 drivers/net/tulip/uli526x.c |2 +-
 drivers/net/wireless/bcm43xx/bcm43xx_leds.c |2 +-
 drivers/pcmcia/m32r_pcc.c   |2 +-
 drivers/pcmcia/m8xx_pcmcia.c|2 +-
 drivers/ps3/vuart.c |2 +-
 drivers/rtc/rtc-pl031.c |2 +-
 drivers/rtc/rtc-sa1100.c|2 +-
 drivers/s390/cio/idset.c|2 +-
 drivers/s390/net/claw.c |2 +-
 drivers/scsi/ide-scsi.c |2 +-
 drivers/serial/crisv10.c|2 +-
 drivers/watchdog/at91rm9200_wdt.c   |2 +-
 drivers/watchdog/ks8695_wdt.c   |2 +-
 drivers/watchdog/omap_wdt.c |2 +-
 drivers/watchdog/sa1100_wdt.c   |2 +-
 fs/reiser4/jnode.h  |2 +-
 fs/reiser4/plugin/space/bitmap.c|2 +-
 include/asm-cris/posix_types.h  |2 +-
 include/asm-i386/pgtable.h  |5 +
 include/asm-i386/smp.h  |2 +-
 include/asm-ia64/cacheflush.h   |2 +-
 include/asm-ia64/pgtable.h  |2 +-
 include/asm-ia64/smp.h  |2 +-
 include/asm-ia64/spinlock.h |2 +-
 include/asm-m32r/pgtable.h  |2 +-
 include/asm-mips/fpu.h  |2 +-
 include/asm-parisc/pgtable.h|2 +-
 include/asm-powerpc/iommu.h |2 +-
 include/asm-powerpc/mmu_context.h   |2 +-
 include/asm-ppc/mmu_context.h   |3 ++-
 include/asm-sparc64/smp.h   |2 +-
 include/asm-x86_64/pgtable.h|2 +-
 include/asm-x86_64/topology.h   |2 +-
 include/linux/of.h  |2 +-
 lib/hweight.c   |2 +-
 net/core/gen_estimator.c|2 +-
 net/core/pktgen.c   |2 +-
 net/ipv4/fib_trie.c |2 +-
 net/netfilter/xt_connbytes.c|2 +-
 60 files changed, 60 insertions(+), 63 deletions(-)

diff --git a/arch/alpha/lib/fls.c b/arch/alpha/lib/fls.c
index 7ad84ea..32afaa3 100644
--- a/arch/alpha/lib/fls.c
+++ b/arch/alpha/lib/fls.c
@@ -3,7 +3,7 @@
  */
 
 #include 
-#include 
+#include 
 
 /* This is fls(x)-1, except zero is held to zero.  This allows most
efficent input into extbl, plus it allows easy handling of fls(0)=0.  */
diff --git a/arch/frv/kernel/irq-mb93091.c b/arch/frv/kernel/irq-mb93091.c
index ad753c1..9e38f99 100644
--- a/arch/frv/kernel/irq-mb93091.c
+++ b/arch/frv/kernel/irq-mb93091.c
@@ -17,10 +17,10 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/frv/kernel/irq-mb93093.c b/arch/frv/kernel/irq-mb93093.c
index e0983f6..3c2752c 100644
--- a/arch/frv/kernel/irq-mb93093.c
+++ b/arch/frv/kernel/irq-mb93093.c
@@ -17,10 +17,10 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/frv/kernel/irq-mb93493.c b/arch/frv/kernel/irq-mb93493.c
index c157eef..7754c73 100644
--- a/arch/

Re: sata & scsi suggestion for make menuconfig

[Stefan Richter]

Randy Dunlap wrote:
> On Sat, 08 Sep 2007 18:44:46 +0200 Stefan Richter wrote:
>> Randy Dunlap wrote:
>>> The problem with 'select' here is that it will enable BLK_DEV_SD,
>>> but if SCSI is not enabled, it will not become enabled -- i.e.,
>>> select does not follow the dependency chain.  So usually the
>>> kernel will not build unless SCSI is enabled by the user.
...
>> I checked the dependencies.  ATA depends on SCSI (actually, selects
>> SCSI), so all is well.  Otherwise I would have added more dependencies
>> to ATA_SD.
> 
> Ah, that's good, then.

Not completely though.  Whenever a 'select' is inserted into the
dependency graph, the whole thing becomes more fragile WRT future changes.
-- 
Stefan Richter
-=-=-=== =--= -=---
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: sysfs change of input/event devices in 2.6.23rc breaks udev

[Andrey Borzenkov]

On Saturday 08 September 2007, Anssi Hannula wrote:
> Andrey Borzenkov wrote:
> > Anssi Hannula wrote:
> >> Hi!
> >>
> >> There seem to be changes in sysfs input structure between 2.6.22 and
> >> 2.6.23-rc5 which cause some breakage.
>
> [...]
>
> >> There is no longer:
> >> /sys/class/input/eventX => /sys/class/input/inputX/eventX
> >> instead there is:
> >> /sys/class/inputX/input:eventX => /sys/class/input/eventX
> >> Notice the added "input:". I don't know if any software depends on this,
> >> though.
> >>
> >> However, the change that broke id_path of udev is that
> >> /sys/class/input/event5/device is now a symlink to the inputX directory
> >> instead of being the same as the device symlink in inputX directory,
> >> i.e. to ../../../devices/platform/pcspkr in this case.
> >>
> >> Udev id_path uses that directory to construct the ID_PATH variable.
> >> Should the sysfs structure be reverted or should udev be adapted to
> >> handle traversing /device symlink twice? I think the former, as there
> >> should be considerably more time to adapt udev for coming changes in
> >> sysfs.
> >
> > I am using 2.6.23-rc5 in current cooker
>
> Same kernel here, but on an older system (MDV2007.1). I tested with a
> path_id from a recent udev as well, though, but the problem was there as
> well.
>
> > and I did not notice any breakage;
> > could you please show example of wrong path? E.g. I have
> >
> > {pts/0}% LC_ALL=C ll /dev/input/by-path
> > total 0
> > lrwxrwxrwx 1 root root 9 Sep  2 15:00
> > platform-i8042-serio-0-event-kbd -> ../event0
> > lrwxrwxrwx 1 root root 9 Sep  2 15:00
> > platform-i8042-serio-1-event-mouse -> ../event1
> > lrwxrwxrwx 1 root root 9 Sep  2 15:00
> > platform-i8042-serio-1-mouse -> ../mouse0
> >
> > and it looks pretty sane for me.
>
> I don't have anything under /dev/input/by-path as the lookup in path_id
> fails.
>
> > Oh, and I do not have CONFIG_SYSFS_DEPRECATED which probably explains why
> > it works for me :)
>
> Probably.
>
> > {pts/0}% LC_ALL=C ll /sys/class/input/input2/
> > total 0
> > drwxr-xr-x 2 root root0 Sep  8 22:25 capabilities/
> > drwxr-xr-x 3 root root0 Sep  8 22:22 event2/
> > drwxr-xr-x 2 root root0 Sep  8 22:25 id/
> > -r--r--r-- 1 root root 4096 Sep  8 22:25 modalias
> > -r--r--r-- 1 root root 4096 Sep  8 22:25 name
> > -r--r--r-- 1 root root 4096 Sep  8 22:25 phys
> > drwxr-xr-x 2 root root0 Sep  8 22:25 power/
> > lrwxrwxrwx 1 root root0 Sep  8 22:25
> > subsystem -> ../../../../class/input/
> > -rw-r--r-- 1 root root 4096 Sep  8 22:25 uevent
> > -r--r--r-- 1 root root 4096 Sep  8 22:25 uniq
>
> What does this print as devpath for you:
> $ udevinfo -q all --name=input/event0
>

{pts/1}% udevinfo -q all --name input/event0
P: /devices/platform/i8042/serio0/input/input0/event0
N: input/event0
S: input/by-path/platform-i8042-serio-0-event-kbd
E: ID_CLASS=kbd
E: ID_SERIAL=noserial
E: ID_PATH=platform-i8042-serio-0

> For me on 2.6.23rc5 it prints:
> P: /class/input/event0
> and on 2.6.22:
> P: /class/input/input0/event0
>
> Both are detected as "old sysfs layout" by path_id, but only on 2.6.22
> is there a /device symlink pointing to the expected location.
>
> I suspect it prints something like /devices/xyz for you, right?
> That seems to be detected as "new sysfs layout" by path_id and handled
> differently.
>
> > this implies that SYSFS_DEPRECATED may be broken w.r.t. udev; OTOH it
> > *is* deprecated, is not it?
>
> Indeed, at least regarding input subsystem, for which there was a recent
> switchover [1] from class_device.
>

If this does not work with current udev this can be considred kernel 
regression as far as I can tell.

-andrey

> [1]
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdi
>ff;h=9657d75c5f0f7d0a9cb507521d3ad1436aea28c9




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

Re: Linux 2.6.20.19

[Willy Tarreau]

diff --git a/Makefile b/Makefile
index 48daec7..6bb9f2e 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 20
-EXTRAVERSION = .18
+EXTRAVERSION = .19
 NAME = Homicidal Dwarf Hamster
 
 # *DOCUMENTATION*
diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index de96e1a..82a3444 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -653,6 +653,14 @@ EXPORT_SYMBOL_GPL(ipv6_invert_rthdr);
   Hop-by-hop options.
  **/
 
+/*
+ * Note: we cannot rely on skb->dst before we assign it in ip6_route_input().
+ */
+static inline struct inet6_dev *ipv6_skb_idev(struct sk_buff *skb)
+{
+   return skb->dst ? ip6_dst_idev(skb->dst) : __in6_dev_get(skb->dev);
+}
+
 /* Router Alert as of RFC 2711 */
 
 static int ipv6_hop_ra(struct sk_buff **skbp, int optoff)
@@ -679,25 +687,25 @@ static int ipv6_hop_jumbo(struct sk_buff **skbp, int 
optoff)
if (skb->nh.raw[optoff+1] != 4 || (optoff&3) != 2) {
LIMIT_NETDEBUG(KERN_DEBUG "ipv6_hop_jumbo: wrong jumbo opt 
length/alignment %d\n",
   skb->nh.raw[optoff+1]);
-   IP6_INC_STATS_BH(ip6_dst_idev(skb->dst),
+   IP6_INC_STATS_BH(ipv6_skb_idev(skb),
 IPSTATS_MIB_INHDRERRORS);
goto drop;
}
 
pkt_len = ntohl(*(__be32*)(skb->nh.raw+optoff+2));
if (pkt_len <= IPV6_MAXPLEN) {
-   IP6_INC_STATS_BH(ip6_dst_idev(skb->dst), 
IPSTATS_MIB_INHDRERRORS);
+   IP6_INC_STATS_BH(ipv6_skb_idev(skb), IPSTATS_MIB_INHDRERRORS);
icmpv6_param_prob(skb, ICMPV6_HDR_FIELD, optoff+2);
return 0;
}
if (skb->nh.ipv6h->payload_len) {
-   IP6_INC_STATS_BH(ip6_dst_idev(skb->dst), 
IPSTATS_MIB_INHDRERRORS);
+   IP6_INC_STATS_BH(ipv6_skb_idev(skb), IPSTATS_MIB_INHDRERRORS);
icmpv6_param_prob(skb, ICMPV6_HDR_FIELD, optoff);
return 0;
}
 
if (pkt_len > skb->len - sizeof(struct ipv6hdr)) {
-   IP6_INC_STATS_BH(ip6_dst_idev(skb->dst), 
IPSTATS_MIB_INTRUNCATEDPKTS);
+   IP6_INC_STATS_BH(ipv6_skb_idev(skb), 
IPSTATS_MIB_INTRUNCATEDPKTS);
goto drop;
}
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 2.6.20.19

[Willy Tarreau]

I've just released Linux 2.6.20.19.

It backports a fix present in 2.6.22 for a bug introduced in the IPv6
stack in 2.6.20, which could lead to crashes under certain circumstances.

I'll also be replying to this message with a copy of the patch between
2.6.20.18 and 2.6.20.19.

The patch and changelog will appear soon at the following locations:
  ftp://ftp.all.kernel.org/pub/linux/kernel/v2.6/
  ftp://ftp.all.kernel.org/pub/linux/kernel/v2.6/patch-2.6.20.19.bz2
  ftp://ftp.all.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20.19

Git repository:
   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.20.y.git
  http://www.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.20.y.git

Git repository through the gitweb interface:
  http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.20.y.git

Willy

---

 Makefile   |2 +-
 net/ipv6/exthdrs.c |   16 
 2 files changed, 13 insertions(+), 5 deletions(-)

Summary of changes from 2.6.20.18 to 2.6.20.19


Willy Tarreau (1):
  Linux 2.6.20.19

YOSHIFUJI Hideaki (1):
  [IPV6]: Do no rely on skb->dst before it is assigned.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: sysfs change of input/event devices in 2.6.23rc breaks udev

[Anssi Hannula]

Andrey Borzenkov wrote:

Anssi Hannula wrote:


Hi!

There seem to be changes in sysfs input structure between 2.6.22 and
2.6.23-rc5 which cause some breakage.


[...]

There is no longer:
/sys/class/input/eventX => /sys/class/input/inputX/eventX
instead there is:
/sys/class/inputX/input:eventX => /sys/class/input/eventX
Notice the added "input:". I don't know if any software depends on this,
though.

However, the change that broke id_path of udev is that
/sys/class/input/event5/device is now a symlink to the inputX directory
instead of being the same as the device symlink in inputX directory,
i.e. to ../../../devices/platform/pcspkr in this case.

Udev id_path uses that directory to construct the ID_PATH variable.
Should the sysfs structure be reverted or should udev be adapted to
handle traversing /device symlink twice? I think the former, as there
should be considerably more time to adapt udev for coming changes in
sysfs.



I am using 2.6.23-rc5 in current cooker


Same kernel here, but on an older system (MDV2007.1). I tested with a 
path_id from a recent udev as well, though, but the problem was there as 
well.


and I did not notice any breakage; 
could you please show example of wrong path? E.g. I have


{pts/0}% LC_ALL=C ll /dev/input/by-path
total 0
lrwxrwxrwx 1 root root 9 Sep  2 15:00
platform-i8042-serio-0-event-kbd -> ../event0
lrwxrwxrwx 1 root root 9 Sep  2 15:00
platform-i8042-serio-1-event-mouse -> ../event1
lrwxrwxrwx 1 root root 9 Sep  2 15:00
platform-i8042-serio-1-mouse -> ../mouse0

and it looks pretty sane for me.


I don't have anything under /dev/input/by-path as the lookup in path_id 
fails.



Oh, and I do not have CONFIG_SYSFS_DEPRECATED which probably explains why it
works for me :)


Probably.


{pts/0}% LC_ALL=C ll /sys/class/input/input2/
total 0
drwxr-xr-x 2 root root0 Sep  8 22:25 capabilities/
drwxr-xr-x 3 root root0 Sep  8 22:22 event2/
drwxr-xr-x 2 root root0 Sep  8 22:25 id/
-r--r--r-- 1 root root 4096 Sep  8 22:25 modalias
-r--r--r-- 1 root root 4096 Sep  8 22:25 name
-r--r--r-- 1 root root 4096 Sep  8 22:25 phys
drwxr-xr-x 2 root root0 Sep  8 22:25 power/
lrwxrwxrwx 1 root root0 Sep  8 22:25
subsystem -> ../../../../class/input/
-rw-r--r-- 1 root root 4096 Sep  8 22:25 uevent
-r--r--r-- 1 root root 4096 Sep  8 22:25 uniq


What does this print as devpath for you:
$ udevinfo -q all --name=input/event0

For me on 2.6.23rc5 it prints:
P: /class/input/event0
and on 2.6.22:
P: /class/input/input0/event0

Both are detected as "old sysfs layout" by path_id, but only on 2.6.22 
is there a /device symlink pointing to the expected location.


I suspect it prints something like /devices/xyz for you, right?
That seems to be detected as "new sysfs layout" by path_id and handled 
differently.



this implies that SYSFS_DEPRECATED may be broken w.r.t. udev; OTOH it *is*
deprecated, is not it?


Indeed, at least regarding input subsystem, for which there was a recent 
switchover [1] from class_device.


[1] 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9657d75c5f0f7d0a9cb507521d3ad1436aea28c9


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

Re: sata & scsi suggestion for make menuconfig

[Stefan Richter]

Andi Kleen wrote:
> On Sat, Sep 08, 2007 at 08:30:06PM +0200, Stefan Richter wrote:
>> Andi Kleen wrote:
>>> when you've been using CONFIG_IDE before it is not completely
>>> obvious you need BLK_SD for your hard disk.
>> Switching to different drivers without reading the help text?
>> Tough.
> 
> The individual driver descriptions don't say BLK_SD needs to be selected.

At least the help to CONFIG_ATA says so.

> Besides if all descriptions said that

We certainly don't want (too much) redundancy in help texts.

> the computer could as well
> do it for the user automatically. After all it's a stupid repetive
> task and computers are much better at those than humans.

In your patch, it is not the computer who finds out that the user wants
BLK_SD.  It is you who predetermined that the user wants it.
-- 
Stefan Richter
-=-=-=== =--= -=---
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: sata & scsi suggestion for make menuconfig

[Andi Kleen]

On Sat, Sep 08, 2007 at 08:30:06PM +0200, Stefan Richter wrote:
> Andi Kleen wrote:
> > when you've been using CONFIG_IDE before it is not completely
> > obvious you need BLK_SD for your hard disk.
> 
> Switching to different drivers without reading the help text?
> Tough.

The individual driver descriptions don't say BLK_SD needs to be selected.

Besides if all descriptions said that the computer could as well
do it for the user automatically. After all it's a stupid repetive
task and computers are much better at those than humans.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] alpha: convert to generic sys_ptrace

[Christoph Hellwig]

This patch converts alpha to the generic sys_ptrace.  We use
force_successful_syscall_return to avoid having to pass the pt_regs
pointer down to the function.  I think the removal of the assemly
stub is correct, but I could only compile-test this patch, so please
give it a spin before commiting :)


Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>

Index: linux-2.6/arch/alpha/kernel/ptrace.c
===
--- linux-2.6.orig/arch/alpha/kernel/ptrace.c   2007-09-08 20:23:22.0 
+0200
+++ linux-2.6/arch/alpha/kernel/ptrace.c2007-09-08 20:52:32.0 
+0200
@@ -260,38 +260,12 @@ void ptrace_disable(struct task_struct *
ptrace_cancel_bpt(child);
 }
 
-asmlinkage long
-do_sys_ptrace(long request, long pid, long addr, long data,
- struct pt_regs *regs)
+long arch_ptrace(struct task_struct *child, long request, long addr, long data)
 {
-   struct task_struct *child;
unsigned long tmp;
size_t copied;
long ret;
 
-   lock_kernel();
-   DBG(DBG_MEM, ("request=%ld pid=%ld addr=0x%lx data=0x%lx\n",
- request, pid, addr, data));
-   if (request == PTRACE_TRACEME) {
-   ret = ptrace_traceme();
-   goto out_notsk;
-   }
-
-   child = ptrace_get_task_struct(pid);
-   if (IS_ERR(child)) {
-   ret = PTR_ERR(child);
-   goto out_notsk;
-   }
-
-   if (request == PTRACE_ATTACH) {
-   ret = ptrace_attach(child);
-   goto out;
-   }
-
-   ret = ptrace_check_attach(child, request == PTRACE_KILL);
-   if (ret < 0)
-   goto out;
-
switch (request) {
/* When I and D space are separate, these will need to be fixed.  */
case PTRACE_PEEKTEXT: /* read word at location addr. */
@@ -301,13 +275,13 @@ do_sys_ptrace(long request, long pid, lo
if (copied != sizeof(tmp))
break;

-   regs->r0 = 0;   /* special return: no errors */
+   force_successful_syscall_return();
ret = tmp;
break;
 
/* Read register number ADDR. */
case PTRACE_PEEKUSR:
-   regs->r0 = 0;   /* special return: no errors */
+   force_successful_syscall_return();
ret = get_reg(child, addr);
DBG(DBG_MEM, ("peek $%ld->%#lx\n", addr, ret));
break;
@@ -353,7 +327,7 @@ do_sys_ptrace(long request, long pid, lo
/* make sure single-step breakpoint is gone. */
ptrace_cancel_bpt(child);
wake_up_process(child);
-   goto out;
+   break;
 
case PTRACE_SINGLESTEP:  /* execute single instruction. */
ret = -EIO;
@@ -366,20 +340,17 @@ do_sys_ptrace(long request, long pid, lo
wake_up_process(child);
/* give it a chance to run. */
ret = 0;
-   goto out;
+   break;
 
case PTRACE_DETACH:  /* detach a process that was attached. */
ret = ptrace_detach(child, data);
-   goto out;
+   break;
 
default:
ret = ptrace_request(child, request, addr, data);
-   goto out;
+   break;
}
- out:
-   put_task_struct(child);
- out_notsk:
-   unlock_kernel();
+
return ret;
 }
 
Index: linux-2.6/arch/alpha/kernel/entry.S
===
--- linux-2.6.orig/arch/alpha/kernel/entry.S2007-09-08 20:52:01.0 
+0200
+++ linux-2.6/arch/alpha/kernel/entry.S 2007-09-08 20:52:16.0 +0200
@@ -917,15 +917,6 @@ sys_pipe:
 .end sys_pipe
 
.align  4
-   .globl  sys_ptrace
-   .entsys_ptrace
-sys_ptrace:
-   .prologue 0
-   mov $sp, $20
-   jmp $31, do_sys_ptrace
-.end sys_ptrace
-
-   .align  4
.globl  sys_execve
.entsys_execve
 sys_execve:
Index: linux-2.6/include/asm-alpha/ptrace.h
===
--- linux-2.6.orig/include/asm-alpha/ptrace.h   2007-09-08 20:52:45.0 
+0200
+++ linux-2.6/include/asm-alpha/ptrace.h2007-09-08 20:52:51.0 
+0200
@@ -68,8 +68,6 @@ struct switch_stack {
 
 #ifdef __KERNEL__
 
-#define __ARCH_SYS_PTRACE  1
-
 #define user_mode(regs) (((regs)->ps & 8) != 0)
 #define instruction_pointer(regs) ((regs)->pc)
 #define profile_pc(regs) instruction_pointer(regs)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: sk98lin for 2.6.23-rc1

[Adrian Bunk]

On Sat, Sep 08, 2007 at 01:44:20PM -0400, Bill Davidsen wrote:
>...
> That was with 2.6.22.5 (or so), dropped back to an old kernel with sk98lin, 
> previously had uptimes in three digit days. Up for a week or so now.

There is a real long-term advantage of removing drivers like sk98lin 
because it forces people to report bugs if the new driver doesn't work  
instead of giving them the workaround of using the obsolete driver.
And this has the (at first sight surprising) effect that removing code  
results in an improvement of the kernel.

> Haven't tried later kernels, don't intend to, while no network is really 
> secure, it not really useful.

You are a regular reader of linux-kernel, and therefore the sk98lin 
removal can hardly be a surprise for you. If you prefer whining over 
helping to improve the kernel that's your choice...

> Bill Davidsen

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: sata & scsi suggestion for make menuconfig

[Randy Dunlap]

On Sat, 08 Sep 2007 18:52:35 +0200 Bodo Eggert wrote:

> BTW2: I think that menu needs very much reordering. "Block devices" should
> be renamed to "Other block devices", AGP support should belong into graphics
> support, and many other things I don't even know need to be pushed around.
> Even ordering by name would be better than the current situation! But it
> should be done by someone knowing these devices, I could only do a part.

how's this?

for 2.6.16-rc4:  consolidated graphics config:
http://marc.info/?l=linux-kernel&m=114101236918589&w=2

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

Linux 2.4.36-pre1

[Willy Tarreau]

Hi,

I've just released Linux 2.4.36-pre1.

It's basically the same as 2.4.35.2, with an add-on I'd like people
to experiment with : In private discussions, Solar Designer proposed
to restrict the ability to map the NULL address to CAP_RAW_IO capable
processes only. The idea behind this was to prevent "normal" users
from trying to exploit NULL dereferences in the kernel which have
not been discovered yet. This is purely a preventive measure. Alan
Cox indicated that it was desirable to be able to dynamically disable
the feature because some (very) rare programs map the NULL pointer
to speed up their walk through linked lists by avoiding NULL pointer
checks.

Chris Wright noted that 2.6 already has a somewhat similar feature
brought by Eric Paris, which introduces a sysctl by which the admin
can set the lower mappable address. 

Finally a combination of both methods was implemented. The same sysctl
as in 2.6 was implemented to set the lowest mappable address for non
CAP_RAW_IO capable processes. By default, it is set to zero (disabled)
which means NULL is mappable for everybody. To enable protection,
simply echo the first mappable address into /proc/sys/vm/mmap_min_addr :

  # echo 4096 > /proc/sys/vm/mmap_min_addr

We chose to use the same sysctl and semantics as in 2.6 to ease the
transition from 2.4 to 2.6 without requiring to remove protection.

Extensive tests have been ran with this feature. Some of my desktop
machines already run with it enabled, and our appliances at Exceliance
ship with it enabled by default. Solar Designer tested both Xorg and
Wine as a normal user, and the same feature is enabled by default in
the Openwall Linux 2.4.35-ow2 kernel.

Please report any breakage you would detect when enabling it. We're
pretty confident that almost every applications will not see any
difference since no normal application maps NULL. But it would be
interesting to identify the "special" ones. Applications running
as root will never be impacted. Depending on the application,
typical breakage would translate into memory allocation error or
segmentation fault. Something clearly detectable anyway.

Another issue I'll try to get solved is the current status of the
e100 driver. I got hit in production by its very unreliable VLAN
support (version 2.3.43 !). I got 3.5.17 to fix all of my issues,
so I'll check with the e100 maintainers if we can upgrade it. It
will make the maintenance easier for them too by getting rid of
a very old and buggy version.

Last but not least, please note that this version _will not_ build
under gcc-4.2, so it's not necessary to report it. I'll try to find
a solution.

I estimate that depending on what will be updated, 2.4.36 could see
the light by the end of this year. 2.4.35.x will still evolve in
parallel, of course !

Willy
--

The patch and changelog will appear soon at the following locations:
  ftp://ftp.all.kernel.org/pub/linux/kernel/v2.4/testing/
  ftp://ftp.all.kernel.org/pub/linux/kernel/v2.4/testing/patch-2.4.36-pre1.bz2
  ftp://ftp.all.kernel.org/pub/linux/kernel/v2.4/testing/patch-2.4.36.log

Git repository:
   git://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/linux-2.4.git
  http://www.kernel.org/pub/scm/linux/kernel/git/wtarreau/linux-2.4.git/

Git repository through the gitweb interface:
  http://git.kernel.org/?p=linux/kernel/git/wtarreau/linux-2.4.git


Summary of changes from v2.4.35 to v2.4.36-pre1


Marc Haisenko (1):
  b44: fix force mac address before ifconfig up

Willy Tarreau (12):
  build fix for lvm with gcc 4
  fix wdt83627 build breakage with gcc 4.x
  wdt83627: fix wdt_init() return code
  module fdomain_cs requires fdomain_setup()
  do not use gcc's builtin strpbrk
  fix incorrect use of -fno-unit-at-a-time on GCC >= 4
  second build fix for some rare buggy versions of GCC 4
  CVE-2007-3848 Privilege escalation via PR_SET_PDEATHSIG
  i386: do_test_wp_bit() must not be inlined
  restore -fno-unit-at-a-time on GCC >= 4
  sysctl to prevent normal processes from mapping NULL
  Change VERSION to 2.4.36-pre1

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

cpuset trouble after hibernate

[Nicolas Capit]

Hello,

This is my situation:
  - I mounted the pseudo cpuset filesystem into /dev/cpuset
  - I created a cpuset named oar with my 2 cpus

cat /dev/cpuset/oar/cpus 
0-1

  - Then I hibernate my computer with 'echo -n "disk" >/sys/power/state'
  - After reboot:

cat /dev/cpuset/oar/cpus 
0

Why did I lost a cpu?
Is this a normal behavior???

Thank you for your attention,
Nicolas Capit


Note on my system:
  - laptop HP dv2000 with a Turion64x2
  - kernel : Linux 2.6.22-1-686 #1 SMP Sun Jul 29 14:37:42 UTC
2007 i686 GNU/Linux
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: sysfs change of input/event devices in 2.6.23rc breaks udev

[Andrey Borzenkov]

Anssi Hannula wrote:

> Hi!
> 
> There seem to be changes in sysfs input structure between 2.6.22 and
> 2.6.23-rc5 which cause some breakage.
> 

I'm running 2.6.23-rc5 in up-to-date cooker.

> With 2.6.22:
> 
>> # LC_ALL=C ls -l /sys/class/input/input4
>> total 0
>> drwxr-xr-x 2 root root0 Sep  8 12:51 capabilities/
>> lrwxrwxrwx 1 root root0 Sep  8 19:48 device ->
>> ../../../devices/platform/pcspkr/
>> drwxr-xr-x 2 root root0 Sep  8 12:51 event4/
>> drwxr-xr-x 2 root root0 Sep  8 12:51 id/
>> -r--r--r-- 1 root root 4096 Sep  8 19:48 modalias
>> -r--r--r-- 1 root root 4096 Sep  8 19:48 name
>> -r--r--r-- 1 root root 4096 Sep  8 19:48 phys
>> lrwxrwxrwx 1 root root0 Sep  8 19:48 subsystem ->
>> ../../../class/input/
>> --w--- 1 root root 4096 Sep  8 19:48 uevent
>> -r--r--r-- 1 root root 4096 Sep  8 19:48 uniq
> 
>> # ls -l /sys/class/input/event4
>> lrwxrwxrwx 1 root root 0 Sep  8 19:48 /sys/class/input/event4 ->
>> ../../class/input/input4/event4/
>> # ls -l /sys/class/input/event4/
>> total 0
>> -r--r--r-- 1 root root 4096 Sep  8 19:58 dev
>> lrwxrwxrwx 1 root root0 Sep  8 19:58 device ->
>> ../../../../devices/platform/pcspkr/
>> lrwxrwxrwx 1 root root0 Sep  8 19:58 subsystem ->
>> ../../../../class/input/
>> --w--- 1 root root 4096 Sep  8 19:58 uevent
> 
> With 2.6.23-rc5:
> 
>> # ls -l /sys/class/input/input5
>> total 0
>> drwxr-xr-x 2 root root0 Sep  8 19:47 capabilities/
>> lrwxrwxrwx 1 root root0 Sep  8 19:03 device ->
>> ../../../devices/platform/pcspkr/
>> drwxr-xr-x 2 root root0 Sep  8 19:47 id/
>> lrwxrwxrwx 1 root root0 Sep  8 19:47 input:event5 ->
>> ../../../class/input/event5/

I do not have this

>> -r--r--r-- 1 root root 4096 Sep  8 19:03 modalias
>> -r--r--r-- 1 root root 4096 Sep  8 19:03 name
>> -r--r--r-- 1 root root 4096 Sep  8 19:47 phys
>> drwxr-xr-x 2 root root0 Sep  8 19:47 power/
>> lrwxrwxrwx 1 root root0 Sep  8 19:03 subsystem ->
>> ../../../class/input/
>> -rw-r--r-- 1 root root 4096 Sep  8 19:03 uevent
>> -r--r--r-- 1 root root 4096 Sep  8 19:47 uniq
> 
>> # ls -l /sys/class/input/event5
>> total 0
>> -r--r--r-- 1 root root 4096 Sep  8 19:03 dev
>> lrwxrwxrwx 1 root root0 Sep  8 19:03 device ->
>> ../../../class/input/input5/
>> drwxr-xr-x 2 root root0 Sep  8 19:48 power/
>> lrwxrwxrwx 1 root root0 Sep  8 19:03 subsystem ->
>> ../../../class/input/
>> -rw-r--r-- 1 root root 4096 Sep  8 19:03 uevent
> 
> There are a few changes.
> 
> There is no longer:
> /sys/class/input/eventX => /sys/class/input/inputX/eventX
> instead there is:
> /sys/class/inputX/input:eventX => /sys/class/input/eventX
> Notice the added "input:". I don't know if any software depends on this,
> though.
> 
> However, the change that broke id_path of udev is that
> /sys/class/input/event5/device is now a symlink to the inputX directory
> instead of being the same as the device symlink in inputX directory,
> i.e. to ../../../devices/platform/pcspkr in this case.
> 
> Udev id_path uses that directory to construct the ID_PATH variable.
> Should the sysfs structure be reverted or should udev be adapted to
> handle traversing /device symlink twice? I think the former, as there
> should be considerably more time to adapt udev for coming changes in
> sysfs.
> 

I am using 2.6.23-rc5 in current cooker and I did not notice any breakage; 
could you please show example of wrong path? E.g. I have

{pts/0}% LC_ALL=C ll /dev/input/by-path
total 0
lrwxrwxrwx 1 root root 9 Sep  2 15:00
platform-i8042-serio-0-event-kbd -> ../event0
lrwxrwxrwx 1 root root 9 Sep  2 15:00
platform-i8042-serio-1-event-mouse -> ../event1
lrwxrwxrwx 1 root root 9 Sep  2 15:00
platform-i8042-serio-1-mouse -> ../mouse0

and it looks pretty sane for me.

Oh, and I do not have CONFIG_SYSFS_DEPRECATED which probably explains why it
works for me :)

{pts/0}% LC_ALL=C ll /sys/class/input/input2/
total 0
drwxr-xr-x 2 root root0 Sep  8 22:25 capabilities/
drwxr-xr-x 3 root root0 Sep  8 22:22 event2/
drwxr-xr-x 2 root root0 Sep  8 22:25 id/
-r--r--r-- 1 root root 4096 Sep  8 22:25 modalias
-r--r--r-- 1 root root 4096 Sep  8 22:25 name
-r--r--r-- 1 root root 4096 Sep  8 22:25 phys
drwxr-xr-x 2 root root0 Sep  8 22:25 power/
lrwxrwxrwx 1 root root0 Sep  8 22:25
subsystem -> ../../../../class/input/
-rw-r--r-- 1 root root 4096 Sep  8 22:25 uevent
-r--r--r-- 1 root root 4096 Sep  8 22:25 uniq

this implies that SYSFS_DEPRECATED may be broken w.r.t. udev; OTOH it *is*
deprecated, is not it?

-andrey

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: limiting to UDMA/33 instead of UDMA/100 - pata_pdc202xx_old (also XFS error)?

[Alan Cox]

On Fri, 07 Sep 2007 19:47:02 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:

> >> res 51/84:00:3f:00:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)
> >> res 51/84:00:3f:00:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)
> >> res 51/84:00:21:9d:fc/00:00:00:00:00/e6 Emask 0x10 (ATA bus error)
> 
> 
> ATA bus error == straight-from-hardware reported error
> 
> Cable or connector is dying maybe?  Bad power supplies also sometimes 
> manifest this way.

With PATA some kind of misclocking can occassionally produce similar
results so its worth a bit of driver debug as well - especially if
forcing the speed down a little helps.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: sata & scsi suggestion for make menuconfig

[Stefan Richter]

Andi Kleen wrote:
> when you've been using CONFIG_IDE before it is not completely
> obvious you need BLK_SD for your hard disk.

Switching to different drivers without reading the help text?
Tough.
-- 
Stefan Richter
-=-=-=== =--= -=---
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: sata & scsi suggestion for make menuconfig

[Stefan Richter]

Bodo Eggert wrote:
> The real problem is hiding devices attached to some controlers between
> one kind of the controllers. This has been correct whern they were bus-
> specific, but since they are now shared by three busses, they should get
> their own menu called "(S)ATA/USB/SCSI attached devices" - or whatever a
> native speaker would suggest.

A side note:  SCSI is not a bus.  It is an architecture and a set of
implementation standards; including command set standards, transport
protocol standards and interconnect standards for a whole lot of
different applications, transports, and interconnects, and not all of
the latter are actual buses.  The oldest of SCSI interconnects, SCSI
Parallel Interconnect alias SPI, is often mistaken for all of SCSI even
though its role is diminishing.  There is much more:
http://www.t10.org/scsi-3.htm

You are right though that Linux' SCSI command set drivers and SCSI core
are used for non-SCSI transports too, and this is not very well
reflected by the configuration menu layout.  (But is there an ideal menu
layout?  I'm sure there isn't.)
-- 
Stefan Richter
-=-=-=== =--= -=---
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: sata & scsi suggestion for make menuconfig

[Andi Kleen]

> I'd say that someone needs to use a vendor kernel, or at least
> begin with a vendor .config file...

Vendor kernels tend to compile forever and require initrds. For 
just testing a kernel quickly compiling only a few drivers in
is much more convenient.

Also when you've been using CONFIG_IDE before it is not completely
obvious you need BLK_SD for your hard disk.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: crash while playing bzflag

[Alex Riesen]

Michal Piotrowski, Sat, Sep 08, 2007 01:18:10 +0200:
> Hi Alex,
> 
> On 07/09/2007, Alex Riesen <[EMAIL PROTECTED]> wrote:
> > Kernel: v2.6.23-rc5+ (b21010ed6498391c0f359f2a89c907533fe07fec)
> 
> Is this a post 2.6.22 regression?
> 

Can't say yet.

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

Re: crash while playing bzflag

[Alex Riesen]

Chuck Ebbert, Sat, Sep 08, 2007 01:14:01 +0200:
> On 09/07/2007 03:56 PM, Alex Riesen wrote:
> > Kernel: v2.6.23-rc5+ (b21010ed6498391c0f359f2a89c907533fe07fec)
> > Ubuntu Feisty, Radeon R200 (9200) dual head, MergedFB, BZFlag in
> > OpenGL mode, frozen. That'll teach me playing games at home...
> > 
> > BUG: unable to handle kernel paging request at virtual address ffa85000
> >  printing eip:
> > c016eed1
> > *pde = 5067
> > *pte = 
> > Oops:  [#1]
> > PREEMPT SMP 
> > Modules linked in: binfmt_misc nfs radeon drm nfsd exportfs lockd sunrpc 
> > fan firmware_class it87 hwmon_vid hwmon p4_clockmod speedstep_lib ipv6 sg 
> > sr_mod cdrom usb_storage snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss 
> > snd_pcm snd_mixer_oss snd_seq_oss snd_seq_midi snd_rawmidi 
> > snd_seq_midi_event snd_seq snd_timer snd_seq_device generic floppy snd 
> > ide_core intel_agp e100 uhci_hcd ehci_hcd soundcore snd_page_alloc agpgart 
> > evdev
> > CPU:0
> > EIP:0060:[__link_path_walk+2146/2867]Not tainted VLI
> > EFLAGS: 00010287   (2.6.23-rc5-t #138)
> > EIP is at __link_path_walk+0x862/0xb33
> > eax: ffa85000   ebx: f0a4dd64   ecx: c0442130   edx: c1782d00
> > esi: eee51f30   edi: ffa85000   ebp: f0e49e40   esp: eee51de4
> > ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
> > Process command-not-fou (pid: 2895, ti=eee51000 task=f08f1020 
> > task.ti=eee51000)
> > Stack: f474c02c 0101 f1db2d64 c016d3eb c1782d00 ffa85000  
> >  
> > 96ba5598 000b f474c021 c18eff00 f0e49e40 f08e1540 
> > eee51f30 
> >c1937c78 c18eff00 c016f1e6 f474c000 c1937c78 c18eff00 c180b180 
> > f11a7600 
> > Call Trace:
> >  [do_lookup+79/323] do_lookup+0x4f/0x143
> >  [link_path_walk+68/179] link_path_walk+0x44/0xb3
> >  [_spin_unlock+5/28] _spin_unlock+0x5/0x1c
> >  [get_unused_fd_flags+198/208] get_unused_fd_flags+0xc6/0xd0
> >  [do_path_lookup+362/463] do_path_lookup+0x16a/0x1cf
> >  [__path_lookup_intent_open+69/117] __path_lookup_intent_open+0x45/0x75
> >  [path_lookup_open+32/37] path_lookup_open+0x20/0x25
> >  [open_namei+114/1364] open_namei+0x72/0x554
> >  [unmap_vmas+791/1240] unmap_vmas+0x317/0x4d8
> >  [do_filp_open+37/57] do_filp_open+0x25/0x39
> >  [_spin_unlock+5/28] _spin_unlock+0x5/0x1c
> >  [get_unused_fd_flags+198/208] get_unused_fd_flags+0xc6/0xd0
> >  [do_sys_open+68/192] do_sys_open+0x44/0xc0
> >  [sys_open+28/30] sys_open+0x1c/0x1e
> >  [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85
> >  [xfrm_bundle_ok+53/522] xfrm_bundle_ok+0x35/0x20a
> >  ===
> > Code: f0 ff ff 0f 87 38 01 00 00 8b 46 1c 8b 44 86 20 89 44 24 14 31 ff 85 
> > c0 0f 84 09 01 00 00 89 c7 3d 00 f0 ff ff 0f 87 f5 00 00 00 <80> 38 2f 0f 
> > 85 9f 00 00 00 89 f0 e8 38 e1 ff ff 64 a1 00 70 3f 
> > EIP: [__link_path_walk+2146/2867] __link_path_walk+0x862/0xb33 SS:ESP 
> > 0068:eee51de4
> 
> Whee...
> 
> here, in __vfs_follow_link:
> 
> if (*link == '/') {   < link points to unmapped memory
> path_release(nd);
> if (!walk_init_root(link, nd))
> /* weird __emul_prefix() stuff did it */
> goto out;
> }
> 
> inlined from __do_follow_link:
> 
> if (!IS_ERR(cookie)) {
> char *s = nd_get_link(nd);
> error = 0;
> if (s)
> error = __vfs_follow_link(nd, s);
> if (dentry->d_inode->i_op->put_link)
> dentry->d_inode->i_op->put_link(dentry, nd, cookie);
> }
> 
> __do_follow_link is inlined from do_follow_link
> 
> presumably inlined here:
> 
> if ((lookup_flags & LOOKUP_FOLLOW)
> && inode && inode->i_op && inode->i_op->follow_link) {
> err = do_follow_link(&next, nd);
> if (err)
> goto return_err;
> inode = nd->dentry->d_inode;
> } else
> 
> What filesystem was this?

Presumably ext3 (because it is where command-not-found python script
is), but I usually have the following mounted:

/dev/sda9 on / type ext3 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
/sys on /sys type sysfs (rw,noexec,nosuid,nodev)
varrun on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755)
varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
procbususb on /proc/bus/usb type usbfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
devshm on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda8 on /home type ext3 (rw)
/dev/sda1 on /media/sda1 type ext2 (rw)
/dev/sda2 on /media/sda2 type ext3 (rw)
/dev/sda5 on /media/sda5 type ext3 (rw)
/dev/sda7 on /media/sda7 type ext3 (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

-
To unsubscribe from t

Re: sk98lin for 2.6.23-rc1

[Bill Davidsen]

James Corey wrote:

--- Stephen Hemminger
<[EMAIL PROTECTED]> wrote:


On Sun, 29 Jul 2007 21:01:30 -0600
Rob Sims <[EMAIL PROTECTED]> wrote:


On Thu, Jul 26, 2007 at 06:57:01PM +0200, Adrian

Bunk wrote:



The only known outstanding problems on 2.62.22.6 of
sky2 are:
 * problems with fibre PHY based systems
 * suspend/resume issues, missing multicast
reinitalization, etc.
The previous stability problems have been addressed.


I pretty much agree with everything said, including 
the part about the sky2 people working hard on it. I

have noticed several bugs fixed recently in the driver
source.

However, it really DOES lock up under load. I even 
tried 2.6.23-rc4 and the absolute latest version of

the
driver and it still locks up, as in

eth1: hw csum failure.

I checnged from the sk98lin to the previous driver Adrian said was the 
"right one," skge IIRC. Then he started pushing sky2, and I tried that. 
Like you I get hangs, but unlike you the system doesn't hang, just the 
NIC. No errors, warnings, and reboot fixes it. Acts as if the cable were 
pulled.


That was with 2.6.22.5 (or so), dropped back to an old kernel with 
sk98lin, previously had uptimes in three digit days. Up for a week or so 
now.


Haven't tried later kernels, don't intend to, while no network is really 
secure, it not really useful.


--
Bill Davidsen <[EMAIL PROTECTED]>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: easy alsa patches for the stable kernel?

[Stefan Richter]

Thorsten Leemhuis wrote:
> On 08.09.2007 01:38, Takashi Iwai wrote:
[backports to -stable]
>> Linux will suck really if one breaks so-called stable thing easily
>> without actually testing.  For stable stuff, "it should be good" isn't
>> enough.  It must be: "it IS good."

This applies (or should apply...) to everything that goes to Linus in
his pre -rc1 merge windows.  To post -rc1 submissions and even more so
to -stable submissions, additional criteria apply.

However, there are special kernel trees out there which accept
backports.  Linux distributors do backports, because they have the means
to do so.

> Linux IMHO will suck even more if crucial pieces of hardware does not
> work for people easily, because Linux won't get even used then and will
> frustrate people.
> 
> Don't get me wrong; I understand and agree mostly to the points you
> raised. But we nevertheless need to find a way to make todays hardware
> usable more quickly, as that hardware is often on the market only for
> some months or a year until the successor-model replaces it (which might
> need new drivers or workarounds) --

In the end there is but one solution to this:  Open specs.

> but it sometimes even for small
> alsa-fixes takes as many months to make it from the developers out to
> the kernel and from there to the distributions the user uses.
> 
> It works better in some areas of the kernels (SATA and Network drivers
> come to my mind) where patches make it quicker into the linus- and
> stable-kernels -- in parts that is due to better cooperation with the
> hardware-vendors, but it seems the sub-tree maintainers have a better
> patch-/workflow, which has a strong impact as well.

Feature additions to SATA and networking, e.g. support of additional
hardware, are not backported to -stable or merged post -rc1 either, I
presume.  Maybe they are better in getting stuff ready in time before
merge windows open --- I don't know, I don't watch these subsystems.
Maybe they have less trouble with closed or nonexisting specs...?
-- 
Stefan Richter
-=-=-=== =--= -=---
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

What's in libata-dev.git?

[Jeff Garzik]

The following is the current contents of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
(recently rebased)

The 'upstream' branch is what I will push upstream for 2.6.24, once
the merge window opens.  I also have a pile in my inbox I need to go
over, while I was away at conference.  At least one fix still pending
for 2.6.23-rc that needs to go up.


list of branches

  ALL   contents of: upstream, sil680-mmio, new-eh
* master
  mv-ahci-pata  rough draft Marvell 6141 PATA support
  mv-ncqrough draft sata_mv NCQ support
  new-ehnew EH conversion for sata_qstor, sata_sx4
  pmask proto_mask implementation
  sii-lbt   SiI 311x large block transfer (LBT) support
  sil680-mmio   pata_sil680 MMIO support from benh
  upstream  queued for 2.6.24

Branch 'upstream' (queued for 2.6.24)

Alan Cox (11):
  libata: Correct IORDY handling
  libata-core: Document some limits/assumptions about ID_ATA
  libata: Note that our cache flush code needs fixing up
  pata_cmd64x: Set up MWDMA modes properly
  [libata] add ACPI cable detect API
  libata pata_amd: ACPI checks for 80wire cable
  libata pata_via: ACPI checks for 80wire cable
  libata: Switch most of the remaining SFF drivers to ata_sff_port_start
  libata-portmap: Remove unused definitions
  libata: Spot bridge chips
  libata: Strict checking for identify reporting

Albert Lee (2):
  libata: move ata_altstatus() to pio data xfer functions
  libata: pata_pdc2027x PLL detection minor cleanup

Andrew Morton (1):
  libata-add-irq_flags-to-struct-pata_platform_info-fix

Christian Lamparter (1):
  ata_piix: disallow UDMA 133 on ICH5 & ICH7

Jeff Garzik (4):
  [libata] pdc_adma: convert to new exception handling (EH) framework
  [libata] Remove ->irq_ack() hook, and ata_dummy_irq_on()
  [libata] Remove ->port_disable() hook
  [libata] ata_piix: Use more-robust form of array initialization

Kristen Carlson Accardi (3):
  [libata] check for SATA async notify support
  [libata] ahci: send event when AN received
  ahci: Store interrupt value

Kristoffer Nyborg Gregertsen (1):
  AVR32 PATA driver

Mark Lord (1):
  libata: add support for ATA_16 on ATAPI

Sonic Zhang (1):
  libata driver for bf548 on chip ATAPI controller.

Tejun Heo (18):
  libata-link: introduce ata_link
  libata-link: implement and use link/device iterators
  libata-link: linkify PHY-related functions
  libata-link: linkify EH action helpers
  libata-link: linkify reset
  libata-link: linkify config/EH related functions
  libata-link: make two port flags HRST_TO_RESUME and SKIP_D2H_BSY link 
flags
  libata-link: separate out link initialization functions
  libata-link: implement ata_link_abort()
  libata-link: add PMP links
  libata-link: update ata_scsi_error() to handle PMP links
  libata-link: update EH to deal with PMP links
  libata-link: update hotplug to handle PMP links
  libata-link: update Power Management to handle PMP links
  libata: use ata_port_printk() in ata_wait_idle()
  libata: add printf format attribute to ehi desc functions
  libata: implement and use ata_port_desc() to report port configuration
  libata: move EH repeat reporting into ata_eh_report()

 drivers/ata/Kconfig  |   25 
 drivers/ata/Makefile |2 
 drivers/ata/ahci.c   |  109 +-
 drivers/ata/ata_generic.c|   16 
 drivers/ata/ata_piix.c   |   52 -
 drivers/ata/libata-acpi.c|   63 +
 drivers/ata/libata-core.c|  669 --
 drivers/ata/libata-eh.c  |  647 +
 drivers/ata/libata-scsi.c|  258 +++--
 drivers/ata/libata-sff.c |   69 -
 drivers/ata/libata.h |7 
 drivers/ata/pata_ali.c   |   17 
 drivers/ata/pata_amd.c   |   43 
 drivers/ata/pata_artop.c |   20 
 drivers/ata/pata_at32.c  |  441 +
 drivers/ata/pata_atiixp.c|9 
 drivers/ata/pata_bf54x.c | 1627 +++
 drivers/ata/pata_cmd640.c|4 
 drivers/ata/pata_cmd64x.c|   43 
 drivers/ata/pata_cs5520.c|   27 
 drivers/ata/pata_cs5530.c|4 
 drivers/ata/pata_cs5535.c|4 
 drivers/ata/pata_cypress.c   |4 
 drivers/ata/pata_efar.c  |   11 
 drivers/ata/pata_hpt366.c|4 
 drivers/ata/pata_hpt37x.c|   28 
 drivers/ata/pata_hpt3x2n.c   |   11 
 drivers/ata/pata_hpt3x3.c|   10 
 drivers/ata/pata_icside.c|   39 
 drivers/ata/pata_isapnp.c|8 
 drivers/ata/pata_it8213.c|   11 
 drivers/ata/pat

What's in netdev-2.6.git?

[Jeff Garzik]

The following is the current contents of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
(recently rebased)

The 'upstream' branch is what I will push upstream for 2.6.24, once
the merge window opens.  I also have a pile in my inbox I need to go
over, while I was away at conference.

List of branches

  ALL   == contents of branches: upstream, stats, ethtool
  ethtool
* master
  stats
  upstream

branch upstream
---
Andrew Morton (1):
  libertas: printk warning fixes

Auke Kok (13):
  e1000e: New pci-express e1000 driver (currently for ICH9 devices only)
  e1000e: Remove unused or empty labels
  e1000e: Make a few functions static
  e1000e: remove duplicate shadowing reference to adapter->hw
  e1000e: Fix header includes [v2]
  e1000e: remove namespace collisions with e1000
  e1000e: Use dma_alloc_coherent where possible
  e1000e: Use time_after to account for jiffies wrapping
  e1000e: error handling for pci_map_single calls.
  e1000e: Remove two compile warnings
  e1000e: retire last_tx_tso workaround
  e1000e: Add read code and printout of PBA number (board identifier)
  e1000e: Remove conditional packet split disable flag

Bill Nottingham (1):
  remove gratuitous space in airo module description

Brajesh Dave (1):
  libertas: advertise 11g ad-hoc rates

Brian King (6):
  ibmveth: Enable TCP checksum offload
  ibmveth: Implement ethtool hooks to enable/disable checksum offload
  ibmveth: Add ethtool TSO handlers
  ibmveth: Add ethtool driver stats hooks
  ibmveth: Remove dead frag processing code
  ibmveth: Remove use of bitfields

Dan Williams (31):
  libertas: kill ieeetypes_capinfo bitfield, use ieee80211.h types
  libertas: rename WLAN_802_11_KEY to enc_key and clean up usage
  libertas: clean up indentation in libertas_association_worker
  libertas: clean up 802.11 IE post-scan handling
  libertas: remove if_bootcmd.c
  libertas: fix mixed-case abuse in cmd_ds_802_11_scan
  libertas: fix mixed-case abuse in cmd_ds_802_11_ad_hoc_result
  libertas: fix mixed-case abuse in cmd_ds_802_11_ad_hoc_start
  libertas: re-uppercase command defines and other constants
  libertas: fix debug build breakage due to field rename
  libertas: remove thread.h and make kthread usage clearer
  libertas: new mesh control knobs
  libertas: bump version to 322.p1
  libertas: fix more mixed-case abuse
  libertas: move generic firmware reset command to common code
  libertas: wlan_ -> libertas_ function prefix renames for main.c
  libertas: simplify and clean up data rate handling
  libertas: fix WEXT quality reporting
  libertas: send association events on adhoc reassociation
  libertas: push mesh beacon bit to userspace in scan results
  libertas: fix assignment of WEP key type
  libertas: push WEXT scan requests to a work queue
  libertas: fix misspelling in debug message
  libertas: ignore spurious mesh autostart events
  libertas: better descriptions for association errors
  libertas: fix sparse-reported problems
  libertas: bump driver version
  libertas: fix inadvertant removal of bits from commit 
831441862956fffa17b9801db37e6ea1650b0f69
  libertas: reorganize and simplify init sequence
  libertas: don't stomp on interface-specific private data
  libertas: send reset command directly instead of calling 
libertas_reset_device

Daniel Drake (2):
  zd1211rw: Add ID for Sitecom WL-162
  zd1211rw: Add ID for ZyXEL M-202 XtremeMIMO

Denis Cheng (1):
  drivers/net/cxgb3: removed several unneeded zero initilization

Divy Le Ray (9):
  cxgb3 - MAC workaround update
  cxgb3 - Update rx coalescing length
  cxgb3 - SGE doorbell overflow warning
  cxgb3 - use immediate data for offload Tx
  cxgb3 - Expose HW memory page info
  cxgb3 - tighten checks on TID values
  cxgb3 - Fatal error update
  cxgb3 - log adapter serial number
  cxgb3 - Update internal memory management

Don Fry (1):
  pcnet32: add suspend and resume capability

Eugene Teo (1):
  drivers/net/wireless/libertas/cmd.c: fix adapter->driver_lock dereference

Faidon Liambotis (2):
  Kconfig: order options
  Kconfig: remove references of pcmcia-cs

Holger Schurig (33):
  libertas: remove fw.c
  libertas: fix one more sparse warning
  libertas: make more functions static & remove unused functions
  libertas: uppercase some #defines
  libertas: access mesh_dev more carefully
  libertas: tune hardware info output
  libertas: remove debugmode
  libertas: make the hex dumper nicer
  libertas: remove a hundred CMD_RET_xxx definitions
  libertas: use LBS_DEB_HOST for host-to-card communications
  libertas: use LBS_DEB_HOST for host-to-card communications
  add support for Marvell 8385 CF cards
  li

Linux 2.4.35.2

[Willy Tarreau]

I've just released Linux 2.4.35.2.

The removal of -fno-unit-at-a-time in 2.4.35.1 in order to fix build
with gcc-4.2 uncovered nasty optimization issues in the current code
under gcc-4.x. This option not only prevents gcc from reordering
sections, it also prevents it from doing a better optimization of some
inlinable functions and from stripping out static variables which
apparently never get assigned.

Since the removal of the option, some users were caught by modules
which had no symbol for certain parameters ; this is a very annoying
regression which forced them to go back to 2.4.34.x.

So I have restored -fno-unit-at-a-time for now, and yes, it *will* break
gcc-4.2. But the breakage will be detected at build time now, and people
will not get randomly working modules. I am currently exploring several
solutions to this issue, one of them consisting in fixing broken modules
since -fno-unit-at-a-time is already deprecated. If I find something
reasonably non-intrusive, I will consider it for 2.4.36-pre.

Right now, I expect 2.4.35.2 to be safe for gcc-4.1 users.

Willy
--

The patch and changelog will appear soon at the following locations:
  ftp://ftp.all.kernel.org/pub/linux/kernel/v2.4/
  ftp://ftp.all.kernel.org/pub/linux/kernel/v2.4/patch-2.4.35.2.bz2
  ftp://ftp.all.kernel.org/pub/linux/kernel/v2.4/ChangeLog-2.4.35.2

Git repository:
   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-v2.4.35.y.git
  http://www.kernel.org/pub/scm/linux/kernel/git/stable/linux-v2.4.35.y.git

Git repository through the gitweb interface:
  http://git.kernel.org/?p=linux/kernel/git/stable/linux-v2.4.35.y.git



Summary of changes from v2.4.35.1 to v2.4.35.2


Willy Tarreau (3):
  i386: do_test_wp_bit() must not be inlined
  restore -fno-unit-at-a-time on GCC >= 4
  Change VERSION to 2.4.35.2

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

sysfs change of input/event devices in 2.6.23rc breaks udev

[Anssi Hannula]

Hi!

There seem to be changes in sysfs input structure between 2.6.22 and 
2.6.23-rc5 which cause some breakage.


With 2.6.22:


# LC_ALL=C ls -l /sys/class/input/input4
total 0
drwxr-xr-x 2 root root0 Sep  8 12:51 capabilities/
lrwxrwxrwx 1 root root0 Sep  8 19:48 device -> 
../../../devices/platform/pcspkr/
drwxr-xr-x 2 root root0 Sep  8 12:51 event4/
drwxr-xr-x 2 root root0 Sep  8 12:51 id/
-r--r--r-- 1 root root 4096 Sep  8 19:48 modalias
-r--r--r-- 1 root root 4096 Sep  8 19:48 name
-r--r--r-- 1 root root 4096 Sep  8 19:48 phys
lrwxrwxrwx 1 root root0 Sep  8 19:48 subsystem -> ../../../class/input/
--w--- 1 root root 4096 Sep  8 19:48 uevent
-r--r--r-- 1 root root 4096 Sep  8 19:48 uniq



# ls -l /sys/class/input/event4
lrwxrwxrwx 1 root root 0 Sep  8 19:48 /sys/class/input/event4 -> 
../../class/input/input4/event4/
# ls -l /sys/class/input/event4/
total 0
-r--r--r-- 1 root root 4096 Sep  8 19:58 dev
lrwxrwxrwx 1 root root0 Sep  8 19:58 device -> 
../../../../devices/platform/pcspkr/
lrwxrwxrwx 1 root root0 Sep  8 19:58 subsystem -> ../../../../class/input/
--w--- 1 root root 4096 Sep  8 19:58 uevent


With 2.6.23-rc5:


# ls -l /sys/class/input/input5
total 0
drwxr-xr-x 2 root root0 Sep  8 19:47 capabilities/
lrwxrwxrwx 1 root root0 Sep  8 19:03 device -> 
../../../devices/platform/pcspkr/
drwxr-xr-x 2 root root0 Sep  8 19:47 id/
lrwxrwxrwx 1 root root0 Sep  8 19:47 input:event5 -> 
../../../class/input/event5/
-r--r--r-- 1 root root 4096 Sep  8 19:03 modalias
-r--r--r-- 1 root root 4096 Sep  8 19:03 name
-r--r--r-- 1 root root 4096 Sep  8 19:47 phys
drwxr-xr-x 2 root root0 Sep  8 19:47 power/
lrwxrwxrwx 1 root root0 Sep  8 19:03 subsystem -> ../../../class/input/
-rw-r--r-- 1 root root 4096 Sep  8 19:03 uevent
-r--r--r-- 1 root root 4096 Sep  8 19:47 uniq



# ls -l /sys/class/input/event5
total 0
-r--r--r-- 1 root root 4096 Sep  8 19:03 dev
lrwxrwxrwx 1 root root0 Sep  8 19:03 device -> ../../../class/input/input5/
drwxr-xr-x 2 root root0 Sep  8 19:48 power/
lrwxrwxrwx 1 root root0 Sep  8 19:03 subsystem -> ../../../class/input/
-rw-r--r-- 1 root root 4096 Sep  8 19:03 uevent


There are a few changes.

There is no longer:
/sys/class/input/eventX => /sys/class/input/inputX/eventX
instead there is:
/sys/class/inputX/input:eventX => /sys/class/input/eventX
Notice the added "input:". I don't know if any software depends on this, 
though.


However, the change that broke id_path of udev is that 
/sys/class/input/event5/device is now a symlink to the inputX directory 
instead of being the same as the device symlink in inputX directory, 
i.e. to ../../../devices/platform/pcspkr in this case.


Udev id_path uses that directory to construct the ID_PATH variable. 
Should the sysfs structure be reverted or should udev be adapted to 
handle traversing /device symlink twice? I think the former, as there 
should be considerably more time to adapt udev for coming changes in sysfs.


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

Re: [2.6.22.5] irq X: nobody cared but X is successfully used by libata

[Tejun Heo]

Paul Rolland wrote:
> Hello,
> 
> My machine (an ASUS P5W-DH-Deluxe, Core2, 4Go RAM, 3 SATA and 2IDE) is
> reporting a :
> irq 23: nobody cared (try booting with the "irqpoll" option)
> together with a Call Trace, but :
>  - irqpoll is present on the command line,
>  - the irq is reported to be used by libata,
>  - the irqpoll option is mandatory if I want _some_ of my SATA disks to be 
>accessible.

So, if you don't add the 'irqpoll' option, IO to disks don't work at all
after nobody cared message, right?

-- 
tejun

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

Re: [PATCH 2.6.23-rc4][reRESEND] ahci: RAID mode SATA patch for Intel Tolapai

[Tejun Heo]

Jeff Garzik wrote:
> Gaston, Jason D wrote:
>> At this time, I don't have any way to test those particular DeviceID's
>> and I know that the AHCI mode DeviceID works by using the class code
>> support.  So, I would like to just leave them at they are, if that is
>> ok.
> 
> 
> Fine by me...  Overall I'll follow "vendor's best advice" here :)

The distinction between board_ahci and board_ahci_pi has been removed in
#upstream anyway, so it doesn't matter too much anyway.

Thanks.

-- 
tejun

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

Re: sata & scsi suggestion for make menuconfig

[Matthew Wilcox]

On Sat, Sep 08, 2007 at 09:50:08AM -0700, Randy Dunlap wrote:
> On 08 Sep 2007 18:07:00 +0200 Andi Kleen wrote:
> > This has also bitten me one or two times. A reasonable way would
> > be to just select SD automatically for !EMBEDDED
> 
> I'd say that someone needs to use a vendor kernel, or at least
> begin with a vendor .config file...

That's not entirely fair ... if you're switching over from a config
you've been dragging around for years which uses IDE rather than ATA,
it's far from obvious which config options you need to change.  I think
Andi's patch is a good one.  It might also be good to select SR (at
least my wife's laptop has the cd-rom on SATA).

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

Re: sata & scsi suggestion for make menuconfig

[Bodo Eggert]

Al Boldi <[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:

>> > I once sent a patch to make libata a submenu of scsi.
>>
>> Which is wrong
>>
>> Nakked-by: Alan Cox <[EMAIL PROTECTED]>
>>
>> The general comments about moving this stuff around and making it clearer
>> what sd/sr etc are nowdays are good but hiding libata under SCSI will
>> cause even more confusion than it cures
> 
> That's easy to fix:  just change the SCSI heading to include a libata hint.

I think you're fixing the wrong problem.

The real problem is hiding devices attached to some controlers between
one kind of the controllers. This has been correct whern they were bus-
specific, but since they are now shared by three busses, they should get
their own menu called "(S)ATA/USB/SCSI attached devices" - or whatever a
native speaker would suggest.

Besides that, if I imagine being a semi-novice and searching for IDE
support, I would have a hard time finding the IDE menu, and asuming
PATA to be non-experimental one day, I'd have a hard time deciding
which of the drivers to use. Maybe the SATA-drivers should be put
above the old PATA menu, amd maybe both of the titles should include
"(E)IDE"?

BTW: For CONFIG_ATA, you can replace
"(!M32R && !M68K || BROKEN) && (!SUN4 || BROKEN)"
with "(!M32R && !M68K && !SUN4 || BROKEN)"

BTW2: I think that menu needs very much reordering. "Block devices" should
be renamed to "Other block devices", AGP support should belong into graphics
support, and many other things I don't even know need to be pushed around.
Even ordering by name would be better than the current situation! But it
should be done by someone knowing these devices, I could only do a part.
-- 
Top 100 things you don't want the sysadmin to say:
14. Any more trouble from you and your account gets moved to the 750

Friß, Spammer: [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: sata & scsi suggestion for make menuconfig

[Randy Dunlap]

On Sat, 08 Sep 2007 18:44:46 +0200 Stefan Richter wrote:

> Randy Dunlap wrote:
> > Stefan Richter wrote:
> >> I am not a friend of 'select', but maybe the following actually helps.
> ...
> > The problem with 'select' here is that it will enable BLK_DEV_SD,
> > but if SCSI is not enabled, it will not become enabled -- i.e.,
> > select does not follow the dependency chain.  So usually the
> > kernel will not build unless SCSI is enabled by the user.
> ...
> >> config ATA_SD
> >> tristate "SATA/PATA HDD support (via SCSI disk support)"
> >> depends on ATA
> >> select BLK_DEV_SD
> >> help
> >>   'SCSI disk support' is required to access SATA HDDs.  It is
> ...
> 
> I checked the dependencies.  ATA depends on SCSI (actually, selects
> SCSI), so all is well.  Otherwise I would have added more dependencies
> to ATA_SD.

Ah, that's good, then.  Thanks.

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

Re: sata & scsi suggestion for make menuconfig

[Randy Dunlap]

On 08 Sep 2007 18:07:00 +0200 Andi Kleen wrote:

> Folkert van Heusden <[EMAIL PROTECTED]> writes:
> 
> > Hi,
> > 
> > Maybe it is a nice enhancement for make menuconfig to more explicitly
> > give a pop-up or so when someone selects for example a sata controller
> > while no 'scsi-disk' support was selected?
> 
> This has also bitten me one or two times. A reasonable way would
> be to just select SD automatically for !EMBEDDED
> 
> Here's a patch:
> 
> -Andi
> 
> Select BLK_DEV_SD for all SCSI/libata drivers
> 
> This avoid a common user mistake.

I'd say that someone needs to use a vendor kernel, or at least
begin with a vendor .config file...


> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>

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

Re: 2.6.22.6 pata_via cable detect

[Alan Cox]

> Did you get any off-list feedback on this? I can move a burner back to 
> the VIA to test, but having another controller I took the easy way out 
> and recabled the device. It's production, so I have to test off hours.

There are a couple of fixes just been submitted which may account for
this so for debug its probably best to wait for 2.6.23 with pata_via
cable type bugs or if you want to try the relevant pata_via change.

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

Re: sata & scsi suggestion for make menuconfig

[Stefan Richter]

Randy Dunlap wrote:
> Stefan Richter wrote:
>> I am not a friend of 'select', but maybe the following actually helps.
...
> The problem with 'select' here is that it will enable BLK_DEV_SD,
> but if SCSI is not enabled, it will not become enabled -- i.e.,
> select does not follow the dependency chain.  So usually the
> kernel will not build unless SCSI is enabled by the user.
...
>> config ATA_SD
>> tristate "SATA/PATA HDD support (via SCSI disk support)"
>> depends on ATA
>> select BLK_DEV_SD
>> help
>>   'SCSI disk support' is required to access SATA HDDs.  It is
...

I checked the dependencies.  ATA depends on SCSI (actually, selects
SCSI), so all is well.  Otherwise I would have added more dependencies
to ATA_SD.
-- 
Stefan Richter
-=-=-=== =--= -=---
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

In search of 10gbps cards/shootout in Linux?

[Justin Piszcz]

There are various agencies/educational institutions doing testing but was 
curious if anyone has 'found' a 10 gigabit card shootout measuring the 
performance between 10 gigabit cards on the 2.6 kernel?  Most of the 
benchmarks are from the vendors themselves Intel/etc-- was wondering if 
there were any vendor-independent benchmarks out there?


Until switches come down in price, 10gbps will be most relegated to 
business/research use and therefore such benchmarks probably will be hard 
to come by but I thought I'd ask..


Thanks,

Justin.


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

Re: 2.6.22.6 pata_via cable detect

[Bill Davidsen]

Howard Chu wrote:
Still have a slight glitch here. I have 2 hard drives on the primary 
channel, detected correctly as 80-wire and UDMA100. I have a DVD burner 
on the secondary channel, detected incorrectly as 40-wire. (It's sitting 
by itself on an 80-wire cable.) This is on an Asus A8V-Deluxe.


Did you get any off-list feedback on this? I can move a burner back to 
the VIA to test, but having another controller I took the easy way out 
and recabled the device. It's production, so I have to test off hours.


Here's the dmesg output after a "modprobe pata_via"

pata_via :00:0f.1: version 0.3.1
ACPI: PCI Interrupt :00:0f.1[A] -> GSI 20 (level, low) -> IRQ 20
scsi5 : pata_via
scsi6 : pata_via
ata6: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 
bmdma 0x0001fc00 irq 14
ata7: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 
bmdma 0x0001fc08 irq 15

ata6.00: ATA-6: WDC WD2000JB-00DUA0, 70.13G70, max UDMA/100
ata6.00: 390721968 sectors, multi 16: LBA48
ata6.01: ATA-7: WDC WD5000AAKB-00UKA0, 07.01N01, max UDMA/100
ata6.01: 976773168 sectors, multi 16: LBA48
ata6.00: configured for UDMA/100
ata6.01: configured for UDMA/100
ata7.00: ATAPI: LITE-ON DVDRW LH-20A1H, LL07, max UDMA/66
ata7.00: limited to UDMA/33 due to 40-wire cable
ata7.00: configured for UDMA/33
scsi 5:0:0:0: Direct-Access ATA  WDC WD2000JB-00D 70.1 PQ: 0 
ANSI: 5

sd 5:0:0:0: [sde] 390721968 512-byte hardware sectors (200050 MB)
sd 5:0:0:0: [sde] Write Protect is off
sd 5:0:0:0: [sde] Mode Sense: 00 3a 00 00
sd 5:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA

sd 5:0:0:0: [sde] 390721968 512-byte hardware sectors (200050 MB)
sd 5:0:0:0: [sde] Write Protect is off
sd 5:0:0:0: [sde] Mode Sense: 00 3a 00 00
sd 5:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA

 sde: sde1
sd 5:0:0:0: [sde] Attached SCSI disk
sd 5:0:0:0: Attached scsi generic sg4 type 0
scsi 5:0:1:0: Direct-Access ATA  WDC WD5000AAKB-0 07.0 PQ: 0 
ANSI: 5

sd 5:0:1:0: [sdf] 976773168 512-byte hardware sectors (500108 MB)
sd 5:0:1:0: [sdf] Write Protect is off
sd 5:0:1:0: [sdf] Mode Sense: 00 3a 00 00
sd 5:0:1:0: [sdf] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA

sd 5:0:1:0: [sdf] 976773168 512-byte hardware sectors (500108 MB)
sd 5:0:1:0: [sdf] Write Protect is off
sd 5:0:1:0: [sdf] Mode Sense: 00 3a 00 00
sd 5:0:1:0: [sdf] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA

 sdf: unknown partition table
sd 5:0:1:0: [sdf] Attached SCSI disk
sd 5:0:1:0: Attached scsi generic sg5 type 0
scsi 6:0:0:0: CD-ROMLITE-ON  DVDRW LH-20A1H   LL07 PQ: 0 
ANSI: 5

sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 6:0:0:0: Attached scsi CD-ROM sr0
sr 6:0:0:0: Attached scsi generic sg6 type 5

Let me know what other info you need.



--
Bill Davidsen <[EMAIL PROTECTED]>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2/4] 2.6.23-rc5: known regressions v2

[Dave Kleikamp]

On Sat, 2007-09-08 at 13:11 +0200, Michal Piotrowski wrote:
> Hi all,
> 
> Here is a list of some known regressions in 2.6.23-rc5.
> 
> Feel free to add new regressions/remove fixed etc.
> http://kernelnewbies.org/known_regressions

> FS
> 
> Subject : umount triggers a warning in jfs and takes almost a minute
> References  : http://lkml.org/lkml/2007/9/4/73
> Last known good : ?
> Submitter   : Oliver Neukum <[EMAIL PROTECTED]>
> Caused-By   : ?
> Handled-By  : ?
> Status  : unknown

Is this a regression?

Oliver,
Have you been using jfs on this flash previously?  If so, what was the
most recent kernel that didn't have problems?

Thanks,
Shaggy
-- 
David Kleikamp
IBM Linux Technology Center

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

Re: 2.6.23-rc4-mm1 compile error for ppc 32

[Benjamin Herrenschmidt]

> > If so, the finger points at this:
> >
> > static __inline__ void __clear_bit_unlock(int nr, volatile unsigned long
> > *addr) {
> > __asm__ __volatile__(LWSYNC_ON_SMP ::: "memory");
> > __clear_bit(nr, addr);
> > }
> >
> > which was added by Nick's powerpc-lock-bitops.patch.  I am suspecting that
> > this isn't pp32 code?
> 
> Hmm, when LWSYNC_ON_SMP is a noop, it seems like it should probably
> be an empty string instead of nothing? ("") That should make behaviour
> more consistent I think.

The wormhole is arch/ppc's hack to get to include/asm-powerpc...

As for having LWSYNC_ON_SMP be "" ... that might be the best way but I'd
rather not take chances right now and go for the quick fix of making
__clear_bit_unlock() do

LWSYNC_ON_SMP ""

instead.

Ben.


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

Re: [4/4] 2.6.23-rc5: known regressions v2

[Pavel Machek]

Hi!

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

Can you try unloading acpi_cpufreq? I seen similar bug in suse
kernel...

If that does not help, try unloading as many modules as possible...

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: sata & scsi suggestion for make menuconfig

[Randy Dunlap]

Stefan Richter wrote:

(added Cc linux-ide)

Folkert van Heusden wrote:

A popup makes some sense, but I don't know if menuconfig knows how to
do popup warnings... and it needs to be done for all *configs,
not just menuconfig.

Maybe add a new type?

How about
comment "Note: 'SCSI disk support' is required for SATA/PATA HDDs!"
depends on ATA && !BLK_DEV_SD

Yes! Maybe create some status-line at the bottom of the screen in which
these hints scrollby. Like powertop does.


'comment' is already supported by make {menu,x,g}config and AFAIK by
make oldconfig too.  It is not effective in make oldconfig though
because it will scroll off the screen quickly.

I am not a friend of 'select', but maybe the following actually helps.
I didn't follow all of this and previous related discussions, so I guess
somebody else suggested something like this before:



The problem with 'select' here is that it will enable BLK_DEV_SD,
but if SCSI is not enabled, it will not become enabled -- i.e.,
select does not follow the dependency chain.  So usually the
kernel will not build unless SCSI is enabled by the user.


# drivers/ata/Kconfig

config ATA
[...]

comment "Controller drivers"

[...low-level drivers go here...]

comment "Storage device drivers"

config ATA_SD
tristate "SATA/PATA HDD support (via SCSI disk support)"
depends on ATA
select BLK_DEV_SD
help
  'SCSI disk support' is required to access SATA HDDs.  It is
  also necessary for parallel ATA (IDE) HDDs if you use the
  experimental parallel ATA option.

  You can say Y or M here to select SCSI disk support, or you
  can do so in the 'SCSI device support' section.

[...ditto for CD/DVD-ROMs, tapes, and generic support...]



--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] prevent kswapd from freeing excessive amounts of lowmem

[Pavel Machek]

Hi!

> The current VM can get itself into trouble fairly easily 
> on systems
> with a small ZONE_HIGHMEM, which is common on i686 
> computers with
> 1GB of memory.
> 
> On one side, page_alloc() will allocate down to 
> zone->pages_low,
> while on the other side, kswapd() and balance_pgdat() 
> will try
> to free memory from every zone, until every zone has 
> more free
> pages than zone->pages_high.
> 
> Highmem can be filled up to zone->pages_low with page 
> tables,
> ramfs, vmalloc allocations and other unswappable things 
> quite
> easily and without many bad side effects, since we still 
> have
> a huge ZONE_NORMAL to do future allocations from.
> 
> However, as long as the number of free pages in the 
> highmem
> zone is below zone->pages_high, kswapd will continue 
> swapping
> things out from ZONE_NORMAL, too!
> 
> Sami Farin managed to get his system into a stage where 
> kswapd
> had freed about 700MB of low memory and was still "going 
> strong".
> 
> The attached patch will make kswapd stop paging out data 
> from
> zones when there is more than enough memory free.  We do 
> go above
> zone->pages_high in order to keep pressure between zones 
> equal
> in normal circumstances, but the patch should prevent 
> the kind
> of excesses that made Sami's computer totally unusable.
> 
> Please merge this into -mm.
> 
> Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>

> --- linux-2.6.22.noarch/mm/vmscan.c.excessive 2007-09-05 12:19:49.0 
> -0400
> +++ linux-2.6.22.noarch/mm/vmscan.c   2007-09-05 12:21:40.0 -0400
> @@ -1371,7 +1371,13 @@ loop_again:
>   temp_priority[i] = priority;
>   sc.nr_scanned = 0;
>   note_zone_scanning_priority(zone, priority);
> - nr_reclaimed += shrink_zone(priority, zone, &sc);
> + /*
> +  * We put equal pressure on every zone, unless one
> +  * zone has way too many pages free already.
> +  */

That does not seem right. Having empty HIGHMEM and full LOWMEM would
be very bad, right? We may stop freeing when there's enough LOWMEM
free, but not if there's only HIGHMEM free.

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: myri10ge: force select inet_lro

[Daniel Walker]

On Sat, 2007-09-08 at 01:22 -0700, David Miller wrote:
> From: Daniel Walker <[EMAIL PROTECTED]>
> Date: Fri, 07 Sep 2007 13:26:25 -0700
> 
> > This driver uses the inet_lro facilities , but it doesn't force it
> > to be enabled .. Someone would have to know to enable inet_lro if
> > they select the driver .. 
> > 
> > Instead, just force INET_LRO if this driver is selected..
> > 
> > Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>
> 
> I put this exact fix into the net-2.6.24 tree several days ago
> already, it's not nice that you didn't even bother checking.

Sorry..

> When I saw the response to the help@ address, I could almost predict
> that the myri10ge developers would not even check if net-2.6.24 had
> the issue cured already.
> 
> Therefore, your patch doesn't even apply to the tree where it is
> relevant.  That sucks.

Not sure what the help@ address is ? I'm just trying to fix problems I
find .. This problem is in -mm which is what I was using. The driver is
pretty obscure, and I just assumed not many people would be building it.
So I didn't check for fixes in git ..

Did your fix go to LKML ?

Daniel

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

[Andi Kleen]

Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
>  
> - profile_hit(SCHED_PROFILING, __builtin_return_address(0));
> + immediate_if (&sched_profiling)

I must say I really dislike immediate_if(). You complained earlier
that something breaks coloring, but adding such macros will definitely
break a lot of editors (especially if you use it without {} like here)

It would be much nicer and readable to just use if 
(unlikely(immediate_read(&x)) or if you prefer to hide the unlikely
if (immediate_bool_test(&x)) with an implicit unlikely().

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

Re: sata & scsi suggestion for make menuconfig

[Jan Engelhardt]

On Sep 8 2007 17:03, Al Boldi wrote:
>Alan Cox wrote:
>> > I once sent a patch to make libata a submenu of scsi.
>>
>> Which is wrong
>>
>> Nakked-by: Alan Cox <[EMAIL PROTECTED]>
>>
>> The general comments about moving this stuff around and making it clearer
>> what sd/sr etc are nowdays are good but hiding libata under SCSI will
>> cause even more confusion than it cures
>
>That's easy to fix:  just change the SCSI heading to include a libata hint.

Let's not. I am perfectly fine with how things currently are, plus optionally
Stefan Richter's suggestion.


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

Re: sata & scsi suggestion for make menuconfig

[Andi Kleen]

Folkert van Heusden <[EMAIL PROTECTED]> writes:

> Hi,
> 
> Maybe it is a nice enhancement for make menuconfig to more explicitly
> give a pop-up or so when someone selects for example a sata controller
> while no 'scsi-disk' support was selected?

This has also bitten me one or two times. A reasonable way would
be to just select SD automatically for !EMBEDDED

Here's a patch:

-Andi

Select BLK_DEV_SD for all SCSI/libata drivers

This avoid a common user mistake.


Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>

Index: linux-2.6.23-rc1-misc/drivers/ata/Kconfig
===
--- linux-2.6.23-rc1-misc.orig/drivers/ata/Kconfig
+++ linux-2.6.23-rc1-misc/drivers/ata/Kconfig
@@ -42,6 +42,7 @@ config ATA_ACPI
 
 config SATA_AHCI
tristate "AHCI SATA support"
+   select BLK_DEV_SD if !EMBEDDED
depends on PCI
help
  This option enables support for AHCI Serial ATA.
@@ -50,6 +51,7 @@ config SATA_AHCI
 
 config SATA_SVW
tristate "ServerWorks Frodo / Apple K2 SATA support"
+   select BLK_DEV_SD if !EMBEDDED
depends on PCI
help
  This option enables support for Broadcom/Serverworks/Apple K2
@@ -59,6 +61,7 @@ config SATA_SVW
 
 config ATA_PIIX
tristate "Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support"
+   select BLK_DEV_SD if !EMBEDDED
depends on PCI
help
  This option enables support for ICH5/6/7/8 Serial ATA
@@ -69,6 +72,7 @@ config ATA_PIIX
 
 config SATA_MV
tristate "Marvell SATA support (HIGHLY EXPERIMENTAL)"
+   select BLK_DEV_SD if !EMBEDDED
depends on PCI && EXPERIMENTAL
help
  This option enables support for the Marvell Serial ATA family.
@@ -78,6 +82,7 @@ config SATA_MV
 
 config SATA_NV
tristate "NVIDIA SATA support"
+   select BLK_DEV_SD if !EMBEDDED
depends on PCI
help
  This option enables support for NVIDIA Serial ATA.
@@ -86,6 +91,7 @@ config SATA_NV
 
 config PDC_ADMA
tristate "Pacific Digital ADMA support"
+   select BLK_DEV_SD if !EMBEDDED
depends on PCI
help
  This option enables support for Pacific Digital ADMA controllers
@@ -94,6 +100,7 @@ config PDC_ADMA
 
 config SATA_QSTOR
tristate "Pacific Digital SATA QStor support"
+   select BLK_DEV_SD if !EMBEDDED
depends on PCI
help
  This option enables support for Pacific Digital Serial ATA QStor.
@@ -102,6 +109,7 @@ config SATA_QSTOR
 
 config SATA_PROMISE
tristate "Promise SATA TX2/TX4 support"
+   select BLK_DEV_SD if !EMBEDDED
depends on PCI
help
  This option enables support for Promise Serial ATA TX2/TX4.
@@ -110,6 +118,7 @@ config SATA_PROMISE
 
 config SATA_SX4
tristate "Promise SATA SX4 support"
+   select BLK_DEV_SD if !EMBEDDED
depends on PCI && EXPERIMENTAL
help
  This option enables support for Promise Serial ATA SX4.
@@ -118,6 +127,7 @@ config SATA_SX4
 
 config SATA_SIL
tristate "Silicon Image SATA support"
+   select BLK_DEV_SD if !EMBEDDED
depends on PCI
help
  This option enables support for Silicon Image Serial ATA.
@@ -126,6 +136,7 @@ config SATA_SIL
 
 config SATA_SIL24
tristate "Silicon Image 3124/3132 SATA support"
+   select BLK_DEV_SD if !EMBEDDED
depends on PCI
help
  This option enables support for Silicon Image 3124/3132 Serial ATA.
@@ -134,6 +145,7 @@ config SATA_SIL24
 
 config SATA_SIS
tristate "SiS 964/965/966/180 SATA support"
+   select BLK_DEV_SD if !EMBEDDED
depends on PCI
select PATA_SIS
help
@@ -145,6 +157,7 @@ config SATA_SIS
 
 config SATA_ULI
tristate "ULi Electronics SATA support"
+   select BLK_DEV_SD if !EMBEDDED
depends on PCI
help
  This option enables support for ULi Electronics SATA.
@@ -153,6 +166,7 @@ config SATA_ULI
 
 config SATA_VIA
tristate "VIA SATA support"
+   select BLK_DEV_SD if !EMBEDDED
depends on PCI
help
  This option enables support for VIA Serial ATA.
@@ -161,6 +175,7 @@ config SATA_VIA
 
 config SATA_VITESSE
tristate "VITESSE VSC-7174 / INTEL 31244 SATA support"
+   select BLK_DEV_SD if !EMBEDDED
depends on PCI
help
  This option enables support for Vitesse VSC7174 and Intel 31244 
Serial ATA.
@@ -169,12 +184,14 @@ config SATA_VITESSE
 
 config SATA_INIC162X
tristate "Initio 162x SATA support (HIGHLY EXPERIMENTAL)"
+   select BLK_DEV_SD if !EMBEDDED
depends on PCI && EXPERIMENTAL
help
  This option enables support for Initio 162x Serial ATA.
 
 config PATA_ALI
tristate "ALi PATA support (Experimental)"
+   select BLK_DEV_SD if !EMBEDDED
depends on PCI && EXPERIMENTAL
help
  This option enables support for the ALi ATA interfaces
@@ -184,6 

PROBLEM: Network sky2 Module

[Werner Meurer]

[1.] One line summary of the problem:


hw csum failure appears in syslog

[2.] Full description of the problem/report:

hw csum failure appears in syslog and sometimes, under heavy network utilization, with NFS-Daemon the Network Device 
totally fails. Then no Network Access is possible. Reboot is not required but i must restart the Network with 
the following commands: "ifdown eth0" and "rmmod sky2", then "insmod sky2" and "ifup eth0".


[3.] Keywords (i.e., modules, networking, kernel):

sky2 (Marvell Yukon Onboard Ethernet), networking, checksum

[4.] Kernel version (from /proc/version):

Linux version 2.6.18.8 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 
(prerelease) (SUSE Linux)) #6 SMP Sun Aug 5 15:09:57 CEST 2007

[5.] Output of Oops.. message (if applicable) with symbolic information 
resolved (see Documentation/oops-tracing.txt)


endeavour:~ # dmesg -c
: hw csum failure.

Call Trace:
[] __skb_checksum_complete+0x4a/0x62
[] udp_poll+0x67/0xf3
[] do_select+0x285/0x46d
[] __pollwait+0x0/0xe0
[] default_wake_function+0x0/0xe
[] _spin_lock_bh+0x9/0x14
[] release_sock+0x13/0xaa
[] udp_sendmsg+0x480/0x563
[] sock_sendmsg+0xf3/0x110
[] sock_recvmsg+0x101/0x120
[] autoremove_wake_function+0x0/0x2e
[] sock_aio_write+0x51/0x60
[] try_to_wake_up+0x3e2/0x3f3
[] sys_select+0x26f/0x3d6
[] sys_sendto+0x119/0x14c
[] system_call+0x7e/0x83


[6.] A small shell script or example program which triggers the
problem (if possible)

-

[7.] Environment

Homebrew Server (Asus P5WDG2-WS Motherboard).

[7.1.] Software (add the output of the ver_linux script here)

Linux endeavour 2.6.18.8 #6 SMP Sun Aug 5 15:09:57 CEST 2007 x86_64 x86_64 
x86_6  4 GNU/Linux

Gnu C  4.1.2
Gnu make   3.81
binutils   2.17.50.0.5
util-linux 2.12r
mount  2.12r
module-init-tools  3.2.2
e2fsprogs  1.39
jfsutils   1.1.11
reiserfsprogs  3.6.19
xfsprogs   2.8.11
PPP2.4.4
Linux C Library> libc.2.5
Dynamic linker (ldd)   2.5
Procps 3.2.7
Net-tools  1.60
Kbd1.12
Sh-utils   6.4
udev   103
Modules Loaded capability commoncap sky2 nfs lockd nfs_acl sunrpc 
iptabl  e_filter ip_tables x_tables 
nls_utf8 af_packet w83627ehf hwmon i2c_isa eeprom i2
  c_dev joydev st sd_mod ide_cd truecrypt nls_iso8859_1 
nls_cp437 vfat fat vmnet v  mmon 
ipv6 button battery ac sg sr_mod cdrom loop usb_storage scsi_mod dm_mod i2c 
 _i801 shpchp pci_hotplug ehci_hcd 
uhci_hcd i2c_core usbcore floppy parport_pc lp  
 parport ext3 mbcache jbd edd fan piix thermal processor ide_disk 
ide_core


[7.2.] Processor information (from /proc/cpuinfo):

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 15
model   : 6
model name  :   Intel(R) Pentium(R) D CPU 3.60GHz
stepping: 4
cpu MHz : 3612.869
cache size  : 2048 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 2
fpu : yes
fpu_exception   : yes
cpuid level : 6
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm constant_tsc 
pni monitor ds_cpl vmx est cid cx16 xtpr lahf_lm
bogomips: 7231.81
clflush size: 64
cache_alignment : 128
address sizes   : 36 bits physical, 48 bits virtual

[7.3.] Module information (from /proc/modules):

capability 22536 0 - Live 0x88435000
commoncap 25472 1 capability, Live 0x8842d000
sky2 61444 0 - Live 0x8811b000
nfs 275768 0 - Live 0x883e8000
lockd 86800 1 nfs, Live 0x883d1000
nfs_acl 20608 1 nfs, Live 0x883ca000
sunrpc 193224 3 nfs,lockd,nfs_acl, Live 0x88399000
iptable_filter 20096 0 - Live 0x88393000
ip_tables 39656 1 iptable_filter, Live 0x88388000
x_tables 35336 1 ip_tables, Live 0x8837e000
nls_utf8 19072 0 - Live 0x88378000
af_packet 57356 0 - Live 0x88368000
w83627ehf 33548 0 - Live 0x8835e000
hwmon 20488 1 w83627ehf, Live 0x88357000
i2c_isa 23040 1 w83627ehf, Live 0x8835
eeprom 24976 0 - Live 0x88348000
i2c_dev 28168 0 - Live 0x8834
joydev 28160 0 - Live 0x88338000
st 57764 0 - Live 0x88328000
sd_mod 39296 0 - Live 0x8831d000
ide_cd 59552 0 - Live 0x8830d000
truecrypt 173088 1 - Live 0x882c
nls_iso8859_1 22144 1 - Live 0x88306000
nls_cp437 23808 1 - Live 0x882ff000
vfat 31104 1 - Live 0x8822
fat 73008 1 vfat, Live 0x882ec000
vmnet 76976 21 - Live 0

Re: [PATCH 1/3] build system: section garbage collection for vmlinux

[Denys Vlasenko]

On Wednesday 05 September 2007 21:07, Sam Ravnborg wrote:
> On Wed, Sep 05, 2007 at 02:47:00PM +0100, Denys Vlasenko wrote:
> > On Wednesday 05 September 2007 14:43, Denys Vlasenko wrote:
> > > These patches fix section names and add
> > > CONFIG_DISCARD_UNUSED_SECTIONS. It is not enabled
> > > unconditionally because only newest binutils have
> > > ld --gc-sections which is stable enough for kernel use.
> > > IOW: this is an experimental feature for now.
> > 
> > Part 1: fix section names over entire source (all arches).
> > 
> > Patch is big and boring global s/.text.lock/.text_lock/
> > type thing.
> 
> The normal naming scheme seems to be:
> ..text so in your example it would be: .lock.text
> See the naming of init and exit sections (that was renamed
> during 2.5 to be compatible with -ffunction-sections).

Well, there seems to be a problem at least with .bss:

http://sourceware.org/bugzilla/show_bug.cgi?id=5006

With __attribute__((section(".bss.page_aligned")))
gcc will produce .bss.page_aligned section
with NOBITS attribute, purely on the basis
of section name starting by '.bss.'

With __attribute__((section(".bss_page_aligned"))),
section will get PROGBITS attribute instead.

Combining NOBITS and PROGBITS sections into one .bss
section is not funny.

IOW: at least for bss, we _must_ use ".bss.xxx" names.

I propose (and will implement in next round of patches)
.bss.k.page_aligned ('k' for 'kernel').

Lickily, we alctually have only one special bss section
on kernel today.

Sam, my question - should I also do the same for text/rodata/data,
just for paranoid reasons?
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: sata & scsi suggestion for make menuconfig

[Al Boldi]

Alan Cox wrote:
> > I once sent a patch to make libata a submenu of scsi.
>
> Which is wrong
>
> Nakked-by: Alan Cox <[EMAIL PROTECTED]>
>
> The general comments about moving this stuff around and making it clearer
> what sd/sr etc are nowdays are good but hiding libata under SCSI will
> cause even more confusion than it cures

That's easy to fix:  just change the SCSI heading to include a libata hint.

Something like this:

[PATCH] libata Kconfig: Allow libata to be selected from within the SCSI submenu

Move libata Kconfig sourcing from the drivers Kconfig into the SCSI Kconfig,
and change the SCSI menu heading to indicate libata submenu inclusion.

This allows the user to quickly select additional disk/tape/cdrom support 
from within the same menu.

Signed-off-by: Al Boldi <[EMAIL PROTECTED]>
Cc: Alan Cox <[EMAIL PROTECTED]>
---
--- a/drivers/Kconfig   2007-05-02 17:25:30.0 +0300
+++ b/drivers/Kconfig   2007-08-01 06:33:13.0 +0300
@@ -22,8 +22,6 @@ source "drivers/ide/Kconfig"
 
 source "drivers/scsi/Kconfig"
 
-source "drivers/ata/Kconfig"
-
 source "drivers/cdrom/Kconfig"
 
 source "drivers/md/Kconfig"
--- a/drivers/scsi/Kconfig  2007-07-09 06:38:37.0 +0300
+++ b/drivers/scsi/Kconfig  2007-08-01 06:46:42.0 +0300
@@ -7,6 +7,8 @@ config RAID_ATTRS
---help---
  Provides RAID
 
+source "drivers/ata/Kconfig"
+
 config SCSI
-   tristate "SCSI device support"
+   tristate "SCSI and Libata device support"
depends on BLOCK



Thanks!

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

Re: Intel Memory Ordering White Paper

[Alan Cox]

> AMD processors guarantee loads are ordered and stores are ordered
> (with exceptions of non-temporal, and non-wb policy).
> 
> As for the others that do out of order stores, are any of them SMP?

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

Device problems on Kernel 22

[development . jim]

Hi,

I have an ARM hardware board works fine with USB and MMC in kernel 11. 
Now, I've just upgraded it to kernel 22. The modules seem loaded fine, 
please see following list, but both usb and mmc modules failed to detect 
the USB stick or SD card when it was plugged in (I enabled module debug, 
but nothing printed out). I understand that the devfs is no longer 
supported by the kernel 22, but should the modules still be able to 
detect the devices? I think something has been missing, could anyone 
help, what I am missing here?


K22 $ lsmod
Module  Size  Used by
nls_utf81696  0
nls_iso8859_1   3936  0
nls_cp437   5600  0
nls_ascii   3936  0
vfat   10336  0
fat48028  1 vfat
mmc_block   8580  0
s3c2410mci  6560  0
mmc_core   25876  2 mmc_block,s3c2410mci


Thank you.

Jim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Oops in pwc v4l driver

[Alex Smith]

On 03/09/2007, Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> Hi Alex,
>
> On 02/09/07, Alex Smith <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I found an old Philips Askey VC010 webcam and attempted to get it
> > working on Linux (latest git, x86_64).
>
> Is this a regression? Does 2.6.22 work fine?

Not sure, I haven't tested with .22. But that patch definitely fixes
the issue - I can't cause it no matter what I do.

Thanks,
Alex

(P.S. Sorry for the late reply - I don't check my lkml email that often)
-- 
Alex Smith - http://www.alex-smith.me.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: [2/4] 2.6.23-rc5: known regressions v2

[Alan Stern]

On Sat, 8 Sep 2007, Greg KH wrote:

> On Sat, Sep 08, 2007 at 01:11:13PM +0200, Michal Piotrowski wrote:
> > USB
> > 
> > Subject : 2.6.23-rc1: USB hard disk broken
> > References  : http://lkml.org/lkml/2007/7/25/62
> > Last known good : ?
> > Submitter   : Tino Keitel <[EMAIL PROTECTED]>
> > Caused-By   : ?
> > Handled-By  : Oliver Neukum <[EMAIL PROTECTED]>
> > Status  : unknown
> > 
> > Subject : USB hard disk broken in 2.6.23-rc3 (autosuspend related)
> > References  : http://bugzilla.kernel.org/show_bug.cgi?id=8892
> > Last known good : ?
> > Submitter   : Roman Jarosz <[EMAIL PROTECTED]>
> > Caused-By   : ?
> > Handled-By  : Alan Stern <[EMAIL PROTECTED]>
> > Workaround  : echo -1 >/sys/bus/usb/devices/1-4/power/autosuspend
> > Status  : possible hardware problem
> 
> Oliver and Alan, is there any info about these?  Anything that I can
> help out with?

We're still waiting to hear back from Tino.

Last week I submitted a patch adding Roman's device to the USB quirks 
list.  IIRC the device is one of those troublesome Genesys USB-IDE 
adapters; most of the time it resumes correctly but every now and then 
it fails.  The patch should be somewhere on your input queue.

Alan Stern

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

Re: sata & scsi suggestion for make menuconfig

[Alan Cox]

> I once sent a patch to make libata a submenu of scsi.

Which is wrong

Nakked-by: Alan Cox <[EMAIL PROTECTED]>

The general comments about moving this stuff around and making it clearer
what sd/sr etc are nowdays are good but hiding libata under SCSI will
cause even more confusion than it cures

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

[Greg KH]

On Fri, Sep 07, 2007 at 03:35:59PM +0200, Jean Delvare wrote:
> Hi Greg, all,
> 
> While platform_device.id is a u32, platform_device_add() handles "-1" as
> a special id value. This has potential for confusion and bugs. One such
> bug was reported to me by David Brownell:
> 
> http://lists.lm-sensors.org/pipermail/i2c/2007-September/001787.html
> 
> And since then I've found two other drivers  affected (uartlite and
> i2c-pxa).
> 
> Could we at least make platform_device.id an int so as to clear up the
> confusion? I doubt that the id will ever be a large number anyway.

Sure, that's fine by me, feel free to send a patch.

thanks,

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

Re: [2/4] 2.6.23-rc5: known regressions v2

[Greg KH]

On Sat, Sep 08, 2007 at 01:11:13PM +0200, Michal Piotrowski wrote:
> USB
> 
> Subject : 2.6.23-rc1: USB hard disk broken
> References  : http://lkml.org/lkml/2007/7/25/62
> Last known good : ?
> Submitter   : Tino Keitel <[EMAIL PROTECTED]>
> Caused-By   : ?
> Handled-By  : Oliver Neukum <[EMAIL PROTECTED]>
> Status  : unknown
> 
> Subject : USB hard disk broken in 2.6.23-rc3 (autosuspend related)
> References  : http://bugzilla.kernel.org/show_bug.cgi?id=8892
> Last known good : ?
> Submitter   : Roman Jarosz <[EMAIL PROTECTED]>
> Caused-By   : ?
> Handled-By  : Alan Stern <[EMAIL PROTECTED]>
> Workaround  : echo -1 >/sys/bus/usb/devices/1-4/power/autosuspend
> Status  : possible hardware problem

Oliver and Alan, is there any info about these?  Anything that I can
help out with?

thanks,

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

Re: [4/4] 2.6.23-rc5: known regressions v2

[Sam Ravnborg]

Hi Michal.

> Kconfig/Kbuild
> 
> Subject : building a specific in-tree module is currently a bit broken
> References  : http://lkml.org/lkml/2007/9/5/40
> Last known good : ?
> Submitter   : Robert P. J. Day <[EMAIL PROTECTED]>
> Caused-By   : ?
> Handled-By  : Sam Ravnborg <[EMAIL PROTECTED]>
> Status  : problem is being debugged

Known bug there has been there for ages so this is not a regression.
I suggest removing it from this list - and I will see to have
it fixed for 2.6.24.
I will not push any fix for -rc for this.

Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Intel Memory Ordering White Paper

[dean gaudet]

On Sat, 8 Sep 2007, Petr Vandrovec wrote:

> dean gaudet wrote:
> > On Sun, 9 Sep 2007, Nick Piggin wrote:
> > 
> > > I've also heard that string operations do not follow the normal ordering,
> > > but
> > > that's just with respect to individual loads/stores in the one operation,
> > > I
> > > hope? And they will still follow ordering rules WRT surrounding loads and
> > > stores?
> > 
> > see section 7.2.3 of intel volume 3A...
> > 
> > "Code dependent upon sequential store ordering should not use the string
> > operations for the entire data structure to be stored. Data and semaphores
> > should be separated. Order dependent code should use a discrete semaphore
> > uniquely stored to after any string operations to allow correctly ordered
> > data to be seen by all processors."
> > 
> > i think we need sfence after things like copy_page, clear_page, and possibly
> > copy_user... at least on intel processors with fast strings option enabled.
> 
> I do not think.  I believe that authors are trying to say that
> 
> struct { uint8 lock; uint8 data; } x;
> 
> lea (x.data),%edi
> mov $2,%ecx
> std
> rep movsb
> 
> to set both data and lock does not guarantee that x.lock will be set after
> x.data and that you should do
> 
> lea (x.data),%edi
> std
> movsb
> movsb  # or mov (%esi),%al; mov %al,(%edi), but movsb looks discrete enough to
> me
> 
> instead (and yes, I know that my example is silly).

no it's worse than that -- intel fast string stores can become globally 
visible in any order at all w.r.t. normal loads or stores... so take all 
those great examples in their recent whitepaper and throw out all the 
ordering guarantees for addresses on different cachelines if any of the 
stores are rep string.

for example transitive store ordering for locations on multiple cachelines 
is not guaranteed at all.  the kernel could return a zero page and one 
core could see the zeroes out of order with another core performing some 
sort of lockless data structure operation.

fast strings don't break ordering from the point of view of the core 
performing the rep string operation, but externally there are no 
guarantees (it's right there in the docs).

-dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 6/6] Linux Kernel Markers - Port SPU to markers

[Christoph Hellwig]

On Thu, Sep 06, 2007 at 04:07:39PM -0400, Mathieu Desnoyers wrote:
> Andrew, any chance to get this into -mm ASAP so we can have it in
> 2.6.24?
> 
> Just in case anyone wonders what this is usefulfor I've ported my
> hacking spu tracing code to it, and if markers get in I'd push a cleaned
> up version of this in the tree of the benefit of everyone trying to
> follow what's going on in the spufs code.  Similarly I'd like to port
> the xfs tracing code over to it which is very helpful in trying to
> debug filesystem issues.
> 
> Note that in this patch the actual logging code is rather nasty
> hand-crafted code lifted from the tcp probe in tree which would benefit
> of going away in favour of more general tracing code aswell.
> 
> Changelog:
> - Porting to 2.6.23-rc4-mm1 gave a reject (a trace point location disappeared)
>   from spufs_ps_nopfn() : spufs_ps_nopfn__sleep and spufs_ps_nopfn__wake.

The subject is rather confusing.  What I ported to markers is the spu _tracing_
support.  And given it's never been public before adding the port part to the
commit doesn't make much sense.

Nevermind, I have updated version of this and would prefer to submit it myself
through the spufs maintainer once markers make mainline (hopefully soon!)

I'll also need more cleanups like adding a config option for it.

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

Re: Intel Memory Ordering White Paper

[Petr Vandrovec]

dean gaudet wrote:

On Sun, 9 Sep 2007, Nick Piggin wrote:


I've also heard that string operations do not follow the normal ordering, but
that's just with respect to individual loads/stores in the one operation, I
hope? And they will still follow ordering rules WRT surrounding loads and
stores?


see section 7.2.3 of intel volume 3A...

"Code dependent upon sequential store ordering should not use the string 
operations for the entire data structure to be stored. Data and semaphores 
should be separated. Order dependent code should use a discrete semaphore 
uniquely stored to after any string operations to allow correctly ordered 
data to be seen by all processors."


i think we need sfence after things like copy_page, clear_page, and 
possibly copy_user... at least on intel processors with fast strings 
option enabled.


I do not think.  I believe that authors are trying to say that

struct { uint8 lock; uint8 data; } x;

lea (x.data),%edi
mov $2,%ecx
std
rep movsb

to set both data and lock does not guarantee that x.lock will be set 
after x.data and that you should do


lea (x.data),%edi
std
movsb
movsb  # or mov (%esi),%al; mov %al,(%edi), but movsb looks discrete 
enough to me


instead (and yes, I know that my example is silly).
Petr

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 3/4] ide: make ide_rate_filter() also respect PIO and SW/MW DMA mode masks (take 2)

[Sergei Shtylyov]

Once I quothed:


Make ide_rate_filter() also respect PIO/SWDMA/MWDMA mode masks.  While at it,
make the udma_filter() method calls take precedence over using the mode masks.


   This one not looking to pretty -- I've geve some thought on how to 
beautify all these switch fallthoughs but haven't got something much better 
then uour original approach (AKA Occam's razor :-).



Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>


Farewell!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/4] hpt366: MWDMA filter for SATA cards

[Sergei Shtylyov]

Hello, I wrote:
Sergei Shtylyov wrote:


   The patch was 4/4 of course. :-<
Probably I was too esctatic about the code. ;-)


   Or rarher me. :-)

The Marvell bridge chips used on HighPoint SATA cards do not seem to 
support
the MWDMA modes (at least that caould be seen in their so-called 
drivers :-),

so the driver needs to account for this -- to achieve this:


- add mdma_filter() method from the original patch by Bartlomiej 
Zolnierkewicz

  with his consent, also adding the method callout to ide_rate_filter();


- installed the method for all chips to only return empty mask if a 
SATA drive

  is detected onHPT372{AN]/374 chips...



Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>



---
This patch against the current Linus' tree and unfortunately I was 
able to only
compile test it since that tree gives MODPOST warning and dies early 
on bootup.

Will hopefully try to test if/when I have time... :-)


   And it was still the same -- I'd bisected if I had time...


Index: linux-2.6/drivers/ide/pci/hpt366.c
===
--- linux-2.6.orig/drivers/ide/pci/hpt366.c
+++ linux-2.6/drivers/ide/pci/hpt366.c
@@ -1,5 +1,5 @@
 /*
- * linux/drivers/ide/pci/hpt366.cVersion 1.12Aug 25, 2007
+ * linux/drivers/ide/pci/hpt366.cVersion 1.13Aug 22, 2007



   Errr... and version shuold Aug 02 -- thought I've fixed that. :-/


   Hehe, thanks.  Those versions turned to be quite PITA a to keep.

MBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Intel Memory Ordering White Paper

[dean gaudet]

On Sun, 9 Sep 2007, Nick Piggin wrote:

> I've also heard that string operations do not follow the normal ordering, but
> that's just with respect to individual loads/stores in the one operation, I
> hope? And they will still follow ordering rules WRT surrounding loads and
> stores?

see section 7.2.3 of intel volume 3A...

"Code dependent upon sequential store ordering should not use the string 
operations for the entire data structure to be stored. Data and semaphores 
should be separated. Order dependent code should use a discrete semaphore 
uniquely stored to after any string operations to allow correctly ordered 
data to be seen by all processors."

i think we need sfence after things like copy_page, clear_page, and 
possibly copy_user... at least on intel processors with fast strings 
option enabled.

-dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/2] 2.6.23-rc5: known regressions with patches v2

[Michal Piotrowski]

Hi all,

Here is a list of some known regressions in 2.6.23-rc5
with patches available.

Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions

List of Aces

NameRegressions fixed since 21-Jun-2007
Adrian Bunk10
Linus Torvalds 6
Andi Kleen 5
Hugh Dickins   5
Trond Myklebust5
Andrew Morton  4
Al Viro3
Alan Stern 3
Alexey Starikovskiy3
Cornelia Huck  3
David S. Miller3
Jens Axboe 3
Stephen Hemminger  3
Tejun Heo  3



Some of these patches are available in -krf (known regressions fixes) tree
http://www.stardust.webpages.pl/files/patches/krf/2.6.23-rc5-git1/linux-2.6.23-rc5-git1-krf1.patch.bz2
http://www.stardust.webpages.pl/files/patches/krf/2.6.23-rc5-git1/linux-2.6.23-rc5-git1-krf1.tar.bz2



MMC

Subject : Unable to access memory card reader anymore
References  : http://bugzilla.kernel.org/show_bug.cgi?id=8885
Last known good : ?
Submitter   : Christian Casteyde <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : Alan Stern <[EMAIL PROTECTED]>
Patch   : http://bugzilla.kernel.org/attachment.cgi?id=12438
Status  : patch available



Networking

Subject : ifconfig eth1 - scheduling while atomic: 
ifconfig/0x0002/4170
References  : http://lkml.org/lkml/2007/9/2/165
Last known good : ?
Submitter   : Florian Lohoff <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : Johannes Berg <[EMAIL PROTECTED]>
Patch   : http://lkml.org/lkml/2007/9/7/75
Status  : patch available

Subject : System freeze when restarting network connection with 
Broadcom driver
References  : http://bugzilla.kernel.org/show_bug.cgi?id=8934
Last known good : ?
Submitter   : Christian Casteyde <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : ?
Status  : patch has been submitted to John Linville



Regards,
Michal

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

Re: [4/4] 2.6.23-rc5: known regressions v2

[Michal Piotrowski]

Hi all,

Here is a list of some known regressions in 2.6.23-rc5.

Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions

List of Aces

NameRegressions fixed since 21-Jun-2007
Adrian Bunk10
Linus Torvalds 6
Andi Kleen 5
Hugh Dickins   5
Trond Myklebust5
Andrew Morton  4
Al Viro3
Alan Stern 3
Alexey Starikovskiy3
Cornelia Huck  3
David S. Miller3
Jens Axboe 3
Stephen Hemminger  3
Tejun Heo  3



Kconfig/Kbuild

Subject : building a specific in-tree module is currently a bit broken
References  : http://lkml.org/lkml/2007/9/5/40
Last known good : ?
Submitter   : Robert P. J. Day <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : Sam Ravnborg <[EMAIL PROTECTED]>
Status  : problem is being debugged



Power management

Subject : powersaving degradation, (time spend in C0 goes up after a 
while)
References  : http://lkml.org/lkml/2007/9/2/142
Last known good : ?
Submitter   : Christian Leber <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : ?
Status  : unknown

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

Subject : 2.6.23-rc2 swsusp, suddenly increased uptime
References  : http://lkml.org/lkml/2007/8/12/249
Last known good : ?
Submitter   : Thomas Voegtle <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : Rafael J. Wysocki <[EMAIL PROTECTED]>
Status  : problem is being debugged

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



Regards,
Michal

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

[1/2] 2.6.23-rc5: known regressions with patches v2

[Michal Piotrowski]

Hi all,

Here is a list of some known regressions in 2.6.23-rc5
with patches available.

Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions

List of Aces

NameRegressions fixed since 21-Jun-2007
Adrian Bunk10
Linus Torvalds 6
Andi Kleen 5
Hugh Dickins   5
Trond Myklebust5
Andrew Morton  4
Al Viro3
Alan Stern 3
Alexey Starikovskiy3
Cornelia Huck  3
David S. Miller3
Jens Axboe 3
Stephen Hemminger  3
Tejun Heo  3



Some of these patches are available in -krf (known regressions fixes) tree
http://www.stardust.webpages.pl/files/patches/krf/2.6.23-rc5-git1/linux-2.6.23-rc5-git1-krf1.patch.bz2
http://www.stardust.webpages.pl/files/patches/krf/2.6.23-rc5-git1/linux-2.6.23-rc5-git1-krf1.tar.bz2



Unclassified

Subject : 8250 claims non existing device blocking IO port
References  : http://lkml.org/lkml/2007/8/18/20
Last known good : ?
Submitter   : Andrey Borzenkov <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : Bjorn Helgaas <[EMAIL PROTECTED]>
Patch   : http://lkml.org/lkml/2007/8/21/291
Status  : patch available

Subject : Oops while modprobing phy fixed module
References  : http://lkml.org/lkml/2007/7/14/63
Last known good : ?
Submitter   : Gabriel C <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : Satyam Sharma <[EMAIL PROTECTED]>
  Vitaly Bordug <[EMAIL PROTECTED]>
Patch1  : http://lkml.org/lkml/2007/7/18/506
Status  : patch available



FS

Subject : NFSv3 server error in LOOKUP after READDIRPLUS Call
References  : http://bugzilla.kernel.org/show_bug.cgi?id=8966
Last known good : ?
Submitter   : Peter Kovar <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : Neil Brown <[EMAIL PROTECTED]>
Patch   : http://bugzilla.kernel.org/attachment.cgi?id=12689
Status  : patch available



IDE

Subject : linux-2.6.23-rc4 ppc build failure
References  : http://lkml.org/lkml/2007/8/29/154
Last known good : ?
Submitter   : Bret Towe <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : Tony Breeds <[EMAIL PROTECTED]>
Patch   : http://lkml.org/lkml/2007/8/31/1
Status  : patch was suggested



Regards,
Michal

--
LOG
http://www.stardust.webpages.pl/log/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [3/4] 2.6.23-rc5: known regressions v2

[Michal Piotrowski]

Hi all,

Here is a list of some known regressions in 2.6.23-rc5.

Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions

List of Aces

NameRegressions fixed since 21-Jun-2007
Adrian Bunk10
Linus Torvalds 6
Andi Kleen 5
Hugh Dickins   5
Trond Myklebust5
Andrew Morton  4
Al Viro3
Alan Stern 3
Alexey Starikovskiy3
Cornelia Huck  3
David S. Miller3
Jens Axboe 3
Stephen Hemminger  3
Tejun Heo  3



CPUFREQ

Subject : ide problems: 2.6.22-git17 working, 2.6.23-rc1* is not
References  : http://lkml.org/lkml/2007/7/27/298
  http://lkml.org/lkml/2007/7/29/371
Last known good : ?
Submitter   : dth <[EMAIL PROTECTED]>
Caused-By   : Len Brown <[EMAIL PROTECTED]>
  commit f79e3185dd0f8650022518d7624c876d8929061b
Handled-By  : Len Brown <[EMAIL PROTECTED]>
Status  : problem is being debugged



Networking

Subject : 2.6.23-rc5: possible irq lock inversion dependency detected
References  : http://lkml.org/lkml/2007/9/2/97
Last known good : ?
Submitter   : Christian Kujau <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : ?
Status  : unknown

Subject : zd1211rw regression, device does not enumerate
References  : http://marc.info/?l=linux-usb-devel&m=118854967709322&w=2
  http://bugzilla.kernel.org/show_bug.cgi?id=8972
Last known good : ?
Submitter   : Oliver Neukum <[EMAIL PROTECTED]>
Caused-By   : Daniel Drake <[EMAIL PROTECTED]>
  commit 74553aedd46b3a2cae986f909cf2a3f99369decc
Handled-By  : ?
Status  : unknown

Subject : NETDEV WATCHDOG: eth0: transmit timed out
References  : http://lkml.org/lkml/2007/8/13/737
Last known good : ?
Submitter   : Karl Meyer <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : Francois Romieu <[EMAIL PROTECTED]>
Status  : problem is being debugged

Subject : Weird network problems with 2.6.23-rc2
References  : http://lkml.org/lkml/2007/8/11/40
Last known good : ?
Submitter   : Shish <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : ?
Status  : unknown



Regards,
Michal

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

Re: [2/4] 2.6.23-rc5: known regressions v2

[Michal Piotrowski]

Hi all,

Here is a list of some known regressions in 2.6.23-rc5.

Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions

List of Aces

NameRegressions fixed since 21-Jun-2007
Adrian Bunk10
Linus Torvalds 6
Andi Kleen 5
Hugh Dickins   5
Trond Myklebust5
Andrew Morton  4
Al Viro3
Alan Stern 3
Alexey Starikovskiy3
Cornelia Huck  3
David S. Miller3
Jens Axboe 3
Stephen Hemminger  3
Tejun Heo  3



FS

Subject : umount triggers a warning in jfs and takes almost a minute
References  : http://lkml.org/lkml/2007/9/4/73
Last known good : ?
Submitter   : Oliver Neukum <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : ?
Status  : unknown

Subject : [NFSv4] 2.6.23-rc4 oops in nfs4_cb_recall
References  : http://lkml.org/lkml/2007/9/4/53
Last known good : ?
Submitter   : Daniel J Blueman <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : ?
Status  : unknown

Subject : [NFSD OOPS] 2.6.23-rc1-git10
References  : http://lkml.org/lkml/2007/8/2/462
Last known good : ?
Submitter   : Andrew Clayton <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : ?
Status  : unknown



USB

Subject : 2.6.23-rc1: USB hard disk broken
References  : http://lkml.org/lkml/2007/7/25/62
Last known good : ?
Submitter   : Tino Keitel <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : Oliver Neukum <[EMAIL PROTECTED]>
Status  : unknown

Subject : USB hard disk broken in 2.6.23-rc3 (autosuspend related)
References  : http://bugzilla.kernel.org/show_bug.cgi?id=8892
Last known good : ?
Submitter   : Roman Jarosz <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : Alan Stern <[EMAIL PROTECTED]>
Workaround  : echo -1 >/sys/bus/usb/devices/1-4/power/autosuspend
Status  : possible hardware problem



Regards,
Michal

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

[1/4] 2.6.23-rc5: known regressions v2

[Michal Piotrowski]

Hi all,

Here is a list of some known regressions in 2.6.23-rc5.

Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions

List of Aces

NameRegressions fixed since 21-Jun-2007
Adrian Bunk10
Linus Torvalds 6
Andi Kleen 5
Hugh Dickins   5
Trond Myklebust5
Andrew Morton  4
Al Viro3
Alan Stern 3
Alexey Starikovskiy3
Cornelia Huck  3
David S. Miller3
Jens Axboe 3
Stephen Hemminger  3
Tejun Heo  3



Unclassified

Subject : x86_64 vdso patch is broken somehow?
References  : http://lkml.org/lkml/2007/8/29/136
Last known good : ?
Submitter   : Chuck Ebbert <[EMAIL PROTECTED]>
Caused-By   : Andi Kleen <[EMAIL PROTECTED]>
  commit 2aae950b21e4bc789d1fc6668faf67e8748300b7
Handled-By  : ?
Status  : unknown

Subject : cpu hotplug support broken in 2.6.23-rc3/highres timers break 
cpu hotplug in 2.6.23-rc5
References  : http://lkml.org/lkml/2007/8/27/58
  http://lkml.org/lkml/2007/9/3/65
Last known good : ?
Submitter   : Pavel Machek <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : ?
Status  : problem is being debugged

Subject : 2.6.23-rc3-git1 crash/stuck on VIA CN700 system
References  : http://lkml.org/lkml/2007/8/20/174
Last known good : ?
Submitter   : Stefan Becker <[EMAIL PROTECTED]>
Caused-By   : Andi Kleen <[EMAIL PROTECTED]>
  commit 19d36ccdc34f5ed444f8a6af0cbfdb6790eb1177
Handled-By  : Andi Kleen <[EMAIL PROTECTED]>
  Dave Jones <[EMAIL PROTECTED]>
Workaround  : http://lkml.org/lkml/2007/9/5/221
Status  : problem is being debugged

Subject : console is messed up after resume from s2ram or switching to 
console from X
References  : http://lkml.org/lkml/2007/8/4/6
Last known good : ?
Submitter   : Jeff Chua <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : H. Peter Anvin <[EMAIL PROTECTED]>
  Antonino A. Daplas <[EMAIL PROTECTED]>
Workaround  : "s2ram --force --acpi_sleep 1 --vbe_mode"
Status  : problem is being debugged

Subject : konqueror suddenly vanishing, "konqueror: Fatal IO error: 
client killed"
References  : http://lkml.org/lkml/2007/7/22/86
Last known good : ?
Submitter   : Markus <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : Ingo Molnar <[EMAIL PROTECTED]>
Status  : problem is being debugged

Subject : uml on x86_64 compile error
References  : http://lkml.org/lkml/2007/9/3/86
Last known good : ?
Submitter   : Adrian Bunk <[EMAIL PROTECTED]>
Caused-By   : Jeff Dike <[EMAIL PROTECTED]>
  commit d1254b12c93e1e586137a2ffef71fd33cf273f35
Handled-By  : ?
Status  : unknown



Regards,
Michal

--
LOG
http://www.stardust.webpages.pl/log/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Intel Memory Ordering White Paper

[Nick Piggin]

On Saturday 08 September 2007 20:29, Alan Cox wrote:
> On Fri, 7 Sep 2007 15:26:50 -0700
>
> Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > FYI, we just released a new white paper describing memory ordering for
> > Intel processors:
> > http://developer.intel.com/products/processor/manuals/index.htm
> >
> > Should help answer some questions about some of the ordering primitives
> > we use on i386 and x86_64.
>
> Nice - but it appears to be 64bit only - and indeed it appears to be
> untrue for real 32bit because of the Pentium Pro fencing errata.

As I said, we're not doing anything special in barriers for the ppro errata
today anyway.


> The kernel also runs on IDT Winchip, Cyrix and AMD processors not all of
> which have exactly the same behaviour (the IDT Winchip as we run it
> profoundly differs)

AMD processors guarantee loads are ordered and stores are ordered
(with exceptions of non-temporal, and non-wb policy).

As for the others that do out of order stores, are any of them SMP?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/