Re: 2.6.22-rc6-mm1

[Satyam Sharma]

On 7/1/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:

[...]
I am heading for vacation for 20 days without Internet (real vacation :-))


I hope I'm not late in catching you here ...


By the way - kbuild.git is lacking behind on patches.
I have several queded from other peopel and have more in the works myself.


... is http://lkml.org/lkml/2007/6/23/116/ one of those queued up too?

Note that that patch is also:
Tested-by: Adrian McMenamin <[EMAIL PROTECTED]>

As you can see from:
http://readlist.com/lists/vger.kernel.org/linux-kernel/72/361641.html

[ I think I'll utilize the next few days going through my patches-to-do
list and resurrecting old patches-that-fell-into-lkml-blackhole ... ]

Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: PM policy, hotplug, power saving (was Re: [PATCH] b44: power down PHY when interface down)

[Kyle Moffett]

On Jun 30, 2007, at 12:42:06, Jeff Garzik wrote:
Definitely matters.  Switch renegotiation can take a while, and you  
must take into account the common case of interface bouncing  
(immediate down, then up).


Hoards actively complained the few times we experimented with this,  
because of e.g. DHCP's habit of bouncing the interface, which  
resulted in PHY power bouncing, which resulted in negotiation,  
which resulted in an excrutiating wait on various broken or stupid  
switches.


Overall, this may be classed with other problems of a similar  
sort:  we can power down a PHY, but that removes hotplug capability  
and extends partner/link negotiation time.


Like SATA, we actually want to support BOTH -- active hotplug and  
PHY power-down -- and so this wanders into power management policy.


Give me a knob, and we can program plenty of ethernet|SATA|USB|...  
drivers to power down the PHY and save power.


With some buggy switches and other hardware you actually *want* to  
bounce the link to get them to properly renegotiate.  I can also see  
wanting to power off and on a single-PoE-port NIC to restart whatever  
device is at the other end, although I don't know if any such devices  
exist.  Currently the tg3 driver turns the PHY off and on during down/ 
up on a few of my systems, which I use to make a buggy no-name switch  
recognize STP changes properly.


Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: kvm_amd: Unknown symbol signal_pending - where should I be looking?

[Satyam Sharma]

On 7/1/07, jim miro <[EMAIL PROTECTED]> wrote:

I am trying to get Kvm running on Debian with a custom
 2.6.22-rc5 amd dual core kernel.


Custom as in custom (non-mainline) patches? Can't really
help with those, then.


To prepare I do:

/sbin/modprobe kvm-amd
FATAL: Error inserting kvm_amd
(/lib/modules/2.6.22-rc5/extra/kvm-amd.ko): Unknown
symbol in module, or unknown parameter (see dmesg)

dmesg returns:
kvm_amd: Unknown symbol signal_pending


signal_pending was supposed to be an inline, and
drivers/kvm/svm.c does #include sched.h ... so not sure
where's the problem.


lsmod shows:
kvm56996  0


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

kvm_amd: Unknown symbol signal_pending - where should I be looking?

[jim miro]

I am trying to get Kvm running on Debian with a custom
 2.6.22-rc5 amd dual core kernel.

To prepare I do:

/sbin/modprobe kvm-amd
FATAL: Error inserting kvm_amd
(/lib/modules/2.6.22-rc5/extra/kvm-amd.ko): Unknown
symbol in module, or unknown parameter (see dmesg)

dmesg returns:
kvm_amd: Unknown symbol signal_pending

lsmod shows:
kvm56996  0

ls /lib/modules/2.6.22-rc5/kernel/drivers/kvm
kvm-amd.ko  kvm.ko

a google search on:
kvm_amd: Unknown symbol signal_pending
returns nothing

Any clues where to look?





  

Fussy? Opinionated? Impossible to please? Perfect.  Join Yahoo!'s user panel 
and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 

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

Re: [patch 0/4] MAP_NOZERO v2 - VM_NOZERO/MAP_NOZERO early summer madness

[Davide Libenzi]

On Sat, 30 Jun 2007, Kyle Moffett wrote:

> On Jun 30, 2007, at 19:57:18, Davide Libenzi wrote:
> > On Sat, 30 Jun 2007, Kyle Moffett wrote:
> > > Very simple case:  SELinux is turned on, an s9 (IE: TOP_SECRET) process
> > > calls free(), and an s3 (IE: UNCLASSIFIED) process calls malloc(), getting
> > > the data from the TOP_SECRET process.
> > 
> > Note that you use *s3* and *s9*. Those will be two different context
> > cookies.  SeLinux will have its own way to set the cookie in the mm_struct,
> > to *s3* in one case, and to *s9* in the other case. This will make things so
> > that they'll never see each other pages.
> 
> Except s3 and s9 aren't complete cookies.  A complete label might be:
> "system_u:system_r:apache2_t:s3" for an unclassified apache web-server
> process, or "kmoffett_u:secadmin_r:usershell_t:s9" for me logged in with a
> top-secret label in my security-administrator role.  That's why you'd need to
> call an LSM hook to get a unique identifier, as the LSM would actually need to
> allocate identifiers for equivalence classes.  Secondly, processes may change
> labels as they run, so you couldn't just call it once and cache the result,
> you would need to call it for every freed page (or every re-use of a page).

It does not matter what the UID contain and how it is generated. The focus 
now should be to verify that different UIDs do not see other UIDs pages. 
Once that is verified to be true, and if SeLinux actually wants to use 
it, we'll find a way so that the other 99% of Linux users won't pay the 
price of the abstraction needed to accomplish what they need for this to 
work for them. Ok?



- Davide


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

Re: Kernel doesn't recognize complete memory

[Matthew Garrett]

The 945 chipset used in the Z61 can only address 4GB of physical address 
space and your BIOS is using some of this for PCI and other bits of 
hardware. That only leaves 3GB for RAM. I believe that this restriction 
is mentioned on the IBM website somewhere.

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

Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip

[Bjorn Helgaas]

On Saturday 30 June 2007 03:13:24 pm Andrey Borzenkov wrote:
> After some digging, it works now :) So the story:
> 
> PCMCIA includes code for checking for free IO range(s)
> code is active only if CONFIG_ISA is defined
> CONFIG_ISA has this excellent help text:
>   Find out whether you have ISA slots on your motherboard. 
> and I was stupid enough to take this literally (having notebook I obviously 
> do 
> not have any slots at all)

I'm sorry I don't have time at the moment to do digging of my own.
But I don't think you should have to define CONFIG_ISA.  I think
you hit the nail on the head in your last email -- PNP should be
reserving the resources of active devices.

The fact that PNP doesn't reserve them means PCMCIA is free to
claim them for itself.  So I think PNP is mostly at fault here.
(Of course, we'll still have to work around the Portege BIOS
issue as well.)

> So after recompiling with CONFIG_ISA defined I now get
> 
> [ 2254.136611] cs: IO port probe 0x100-0x3af: excluding 0x100-0x107 
> 0x2e8-0x2ef 0x378-0x37f
> [ 2254.166638] cs: IO port probe 0x3e0-0x4ff: excluding 0x3f8-0x3ff 
> 0x408-0x40f 0x480-0x48f 0x4d0-0x4d7
> [ 2254.194838] cs: IO port probe 0x820-0x8ff: clean.
> [ 2254.222401] cs: IO port probe 0xc00-0xcf7: clean.
> [ 2254.250056] cs: IO port probe 0xa00-0xaff: clean.

I suspect that things will mostly work if you load the drivers in
the (smsc-ircc2, wlags49_h1_cs) order.  Then smsc-ircc2 has a chance
to reserve the resources before yenta and wlags49 get involved.  But
of course, we can't rely on that workaround.

I think there's lots of work needed here -- make PNP reserve resources,
add smarter PNP quirk infrastructure so we can do things at _SRS-time,
add real Portege BIOS workaround, etc.  Way more than we can do for
2.6.22.

What do you think we need to get 2.6.22 out?  I was thinking of a
stop-gap patch like the one below.  I'm between trips and can't
really test it.  In my one quick boot, it did find the IR device,
but irdadump didn't seem to do anything.



[patch] smsc-ircc2: bypass PNP detection until we get the quirks worked out

Don't use PNP detection by default yet.  We have some PNP and BIOS issues
to work out first.

Sample problem on a Toshiba Portege 4000: the SMCf010 device is handed off
disabled.  We assign I/O ports originally assigned to the SMCf010 to a
PCMCIA device instead.  We enable the SMCf010, configuring it to use
disjoint ports, but _SRS doesn't work correctly, so the device doesn't
work.

Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>

Index: w/drivers/net/irda/smsc-ircc2.c
===
--- w.orig/drivers/net/irda/smsc-ircc2.c2007-06-30 21:00:06.0 
-0600
+++ w/drivers/net/irda/smsc-ircc2.c 2007-06-30 21:00:08.0 -0600
@@ -79,7 +79,7 @@
 MODULE_DESCRIPTION("SMC IrCC SIR/FIR controller driver");
 MODULE_LICENSE("GPL");
 
-static int smsc_nopnp;
+static int smsc_nopnp = 1;
 module_param_named(nopnp, smsc_nopnp, bool, 0);
 MODULE_PARM_DESC(nopnp, "Do not use PNP to detect controller settings");
 

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

Re: [RFC 1/7] cpuset write dirty map

[Ethan Solomita]

Christoph Lameter wrote:
> On Wed, 27 Jun 2007, Ethan Solomita wrote:
> 
>>  I looked over it at one point. Most of the code doesn't conflict, but I
>> believe that the code path which calculates the dirty limits will need
>> some merging. Doable but non-trivial.
>>  -- Ethan
> 
> I hope you will keep on updating the patchset and posting it against 
> current mm?
> 

I have no new changes, but I can update it against the current mm. Or
did the per-bdi throttling change get taken by Andrew?
-- Ethan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: speedstep-centrino (no such device)

[Renato S. Yamane]

Robert Hancock wrote:

Renato S. Yamane wrote:

Is impossible use speedstep in my Laptop with Pentium M 1,86Ghz:

#modprobe speedstep-centrino
FATAL: Error inserting speedstep_centrino 
(/lib/modules/2.6.18-3-686/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.ko): 
No such device


To do that (speedstep), I need install powersaved, but 
speedstep-centrino is not used.


I believe acpi-cpufreq is preferred over speedstep-centrino in most 
cases today, does that work?


Robert, acpi_cpufreq works fine to me.
I insert parameter CPUFREQD_MODULE="acpi_cpufreq" in my 
/etc/powersave/cpufreq and now is possible use scaling frequency.


I read 
/usr/src/linux-2.6.21.5/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c 
and see that this module is made using document 25261202.pdf (from 
Intel) as reference.


This document include only some Pentium M models.

My Pentium M is model 750 (1.86GHz) and you can see datasheet on 
document 30526202.pdf available here:



What I can choose on "CPUFreq Processor drivers" availiable in .config?
Currently I do that (in Kernel 2.6.21.1):

# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=m
# CONFIG_X86_POWERNOW_K6 is not set
# CONFIG_X86_POWERNOW_K7 is not set
# CONFIG_X86_POWERNOW_K8 is not set
# CONFIG_X86_GX_SUSPMOD is not set
CONFIG_X86_SPEEDSTEP_CENTRINO=y
CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y
CONFIG_X86_SPEEDSTEP_ICH=m
# CONFIG_X86_SPEEDSTEP_SMI is not set
# CONFIG_X86_P4_CLOCKMOD is not set
# CONFIG_X86_CPUFREQ_NFORCE2 is not set
# CONFIG_X86_LONGRUN is not set
# CONFIG_X86_LONGHAUL is not set
# CONFIG_X86_E_POWERSAVER is not set

#
# shared options
#
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
CONFIG_X86_SPEEDSTEP_LIB=m
CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK=y

Best regards,
Renato S. Yamane
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-rc6-mm1

[Roman Zippel]

Hi,

On Sat, 30 Jun 2007, Andrew Morton wrote:

> > > I continue to believe that kbuild's lets-trash-your-symlink behaviour is
> > > obnoxious, but I was unable to persuade anyone else of this.
> >
> > I thought we fixed that long time ago?!?!
> 
> Nope, a simple `make oldconfig' breaks the symlink.

KCONFIG_OVERWRITECONFIG was added especially for you. :-)

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-rc6-mm1

[Roman Zippel]

Hi,

On Fri, 29 Jun 2007, Andrew Morton wrote:

> > Reset generates values only if Kconfig and .config agree.
> 
> unclear.  Could you please explain further what this change does?

Normally generated values (Kconfig entries without a prompt) are cleared 
as they are regenerated anyway and so they appear as new should they 
become visible and defaults work as expected (once a value is set defaults 
aren't used anymore).
The detection whether a value is generated or not is only based on its 
visibility status, which can quickly change for a lot of symbols by just 
removing a single line from .config or adding a dependency to Kconfig as 
you noticed.
The patch now suppresses this logic when .config and Kconfig aren't in 
sync and .config needs to be updated, so that you can remove now a random 
value from .config and oldconfig won't reask for many other values.

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

Re: [patch 0/4] MAP_NOZERO v2 - VM_NOZERO/MAP_NOZERO early summer madness

[Kyle Moffett]

On Jun 30, 2007, at 19:57:18, Davide Libenzi wrote:

On Sat, 30 Jun 2007, Kyle Moffett wrote:
Very simple case:  SELinux is turned on, an s9 (IE: TOP_SECRET)  
process calls free(), and an s3 (IE: UNCLASSIFIED) process calls  
malloc(), getting the data from the TOP_SECRET process.


Note that you use *s3* and *s9*. Those will be two different  
context cookies.  SeLinux will have its own way to set the cookie  
in the mm_struct, to *s3* in one case, and to *s9* in the other  
case. This will make things so that they'll never see each other  
pages.


Except s3 and s9 aren't complete cookies.  A complete label might be:  
"system_u:system_r:apache2_t:s3" for an unclassified apache web- 
server process, or "kmoffett_u:secadmin_r:usershell_t:s9" for me  
logged in with a top-secret label in my security-administrator role.   
That's why you'd need to call an LSM hook to get a unique identifier,  
as the LSM would actually need to allocate identifiers for  
equivalence classes.  Secondly, processes may change labels as they  
run, so you couldn't just call it once and cache the result, you  
would need to call it for every freed page (or every re-use of a page).


It is very easy, assuming a simple unsigned long cookie is enough  
for

SeLinux, to fit in the current MAP_NOZERO.   Well, we have to change
something in the current struct page _mapcount reuse, but that  
doable. There
is one line to change, that is the line where the cookie is  
assigned  to the

mm_struct.


I do think a single unsigned long cookie would work, as long as you  
have an LSM hook:


int process_equivalence_class(struct task_struct *task, unsigned long  
*result);


If it returns 0 then you can use the result as a page cookie,  
otherwise you can't reuse pages for this process at all.


Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip

[Michal Piotrowski]

Michal Piotrowski pisze:
> Hi,
> 
> Bjorn Helgaas pisze:
>> [patch] PNP SMCf010 quirk: work around Toshiba Portege 4000 ACPI issues
>>
>> When we enable the SMCf010 IR device, the Toshiba Portege 4000 BIOS claims
>> the device is working, but it really isn't configured correctly.  The BIOS
>> *will* configure it, but only if we call _SRS after (1) reversing the order
>> of the SIR and FIR I/O port regions and (2) changing the IRQ from active-high
>> to active-low.
>>
>> This patch fixes the 2.6.22 regression:
>> "no irda0 interface (2.6.21 was OK), smsc does not find chip"
> 
> Hmmm...
> 
> 375   2007-06-29 14:24:47 6921mkkp"no irda0 interface 
> (2.6.21 was OK), smsc does not find chip" fixed, STATISTICS Bjorn Helgaas +1
> 
> Wasn't it fixed?
> 
> commit 172d0496cd22c98ee2e4238821fa309c01685f3a
> Author: Bjorn Helgaas <[EMAIL PROTECTED]>
> Date:   Wed Jun 27 14:09:52 2007 -0700
> [..]
> This patch addresses part of the 2.6.22 regression:
   
   yup, my fault.


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.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip

[Michal Piotrowski]

Hi,

Bjorn Helgaas pisze:
> [patch] PNP SMCf010 quirk: work around Toshiba Portege 4000 ACPI issues
> 
> When we enable the SMCf010 IR device, the Toshiba Portege 4000 BIOS claims
> the device is working, but it really isn't configured correctly.  The BIOS
> *will* configure it, but only if we call _SRS after (1) reversing the order
> of the SIR and FIR I/O port regions and (2) changing the IRQ from active-high
> to active-low.
> 
> This patch fixes the 2.6.22 regression:
> "no irda0 interface (2.6.21 was OK), smsc does not find chip"

Hmmm...

375 2007-06-29 14:24:47 6921mkkp"no irda0 interface 
(2.6.21 was OK), smsc does not find chip" fixed, STATISTICS Bjorn Helgaas +1

Wasn't it fixed?

commit 172d0496cd22c98ee2e4238821fa309c01685f3a
Author: Bjorn Helgaas <[EMAIL PROTECTED]>
Date:   Wed Jun 27 14:09:52 2007 -0700
[..]
This patch addresses part of the 2.6.22 regression:
"no irda0 interface (2.6.21 was OK), smsc does not find chip"


> 
> I tested this on a Portege 4000.  The smsc-ircc2 driver correctly detects
> the device, and "irattach irda0 -s && irdadump" shows transmitted and
> received packets.
> 

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: [patch 0/4] MAP_NOZERO v2 - VM_NOZERO/MAP_NOZERO early summer madness

[Davide Libenzi]

On Sat, 30 Jun 2007, Kyle Moffett wrote:

> On Jun 30, 2007, at 15:03:07, Davide Libenzi wrote:
> > Hmm, why would you need MAP_REUSABLE? If a page is visible at any time for a
> > given UID, and you have a login under such UID, you can fetch the content of
> > the page at any time (ie, ptrace_attach, gdb, ...).
> 
> Not under SELinux or other LSMs.  I suppose those could live without a 15%
> performance improvement in some workloads, but it would be nice if we could
> avoid it.  Essentially, UID is a really poor way to define
> process-security-equivalence classes in some systems.  If you really want to
> define such classes then you need to add LSM hooks to manage the equivalence
> classes.
> 
> > I think the focus should be to find a case where under the currently
> > implemented policy for MAP_NOZERO, MAP_NOZERO represent a loss of security
> > WRT no MAP_NOZERO.
> 
> Very simple case:
> SELinux is turned on, an s9 (IE: TOP_SECRET) process calls free(), and an s3
> (IE: UNCLASSIFIED) process calls malloc(), getting the data from the
> TOP_SECRET process.

Note that you use *s3* and *s9*. Those will be two different context cookies. 
SeLinux will have its own way to set the cookie in the mm_struct, to *s3* 
in one case, and to *s9* in the other case. This will make things so that 
they'll never see each other pages.




> > It is very easy, assuming a simple unsigned long cookie is enough for
> > SeLinux, to fit in the current MAP_NOZERO.   Well, we have to change
> > something in the current struct page _mapcount reuse, but that doable. There
> > is one line to change, that is the line where the cookie is assigned  to the
> > mm_struct.
> 
> I think if you create the concept of a "process equivalence class" and add an
> LSM hook for it, then the unsigned long could just store which equivalence
> class the page is in.  The default without LSMs would be to use
> mutual-ptraceability as the equivalence class (IE: the UID with a proviso for
> SUID binaries).  LSMs should be able to create a process_equivalence_class
> hook which when called returns an unsigned long identifying the "equivalence
> class" (IE: pool) into which the page is placed when freed (or ((unsigned
> long)-1) to forcibly zero the page).  When a process requests a
> maybe-not-zeroed page, the LSM hook would be called again to determine what
> equivalence class should be used, (or ((unsigned long)-1) for
> dont-use-any-class).

I'd rather prefer to not create anything, and to not add anything. SeLinux 
can set the cookie as it likes, and it can also disable the feature. Since 
SeLinux is definitely not the common case, I'd prefer to keep the simple 
unsigned long cookie abstraction, and let them handle however they like it.



- Davide


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

Re: [patch 0/4] MAP_NOZERO v2 - VM_NOZERO/MAP_NOZERO early summer madness

[Kyle Moffett]

On Jun 30, 2007, at 15:03:07, Davide Libenzi wrote:
Hmm, why would you need MAP_REUSABLE? If a page is visible at any  
time for a given UID, and you have a login under such UID, you can  
fetch the content of the page at any time (ie, ptrace_attach,  
gdb, ...).


Not under SELinux or other LSMs.  I suppose those could live without  
a 15% performance improvement in some workloads, but it would be nice  
if we could avoid it.  Essentially, UID is a really poor way to  
define process-security-equivalence classes in some systems.  If you  
really want to define such classes then you need to add LSM hooks to  
manage the equivalence classes.


I think the focus should be to find a case where under the  
currently implemented policy for MAP_NOZERO, MAP_NOZERO represent a  
loss of security WRT no MAP_NOZERO.


Very simple case:
SELinux is turned on, an s9 (IE: TOP_SECRET) process calls free(),  
and an s3 (IE: UNCLASSIFIED) process calls malloc(), getting the data  
from the TOP_SECRET process.


The real trick is how to define the "key".  The default, without  
LSMs, should be something like the UID.  SELinux, on the other  
hand, would probably want to use some kind of hash of the label as  
the "key", (and store the label in each pool, as well).  That way  
SELinux could have a simple access-vector check for  
process:reusepage, as well as an access-vector check and type  
transition for "freereusablepage".  Then a policy could allow most  
user processes to unconditionally reuse pages (which would end up  
in the access-vector-cache and therefore be fast), while security- 
sensitive processes like ssh-agent could neither reuse pages nor  
have their pages reused, even if they request it.


It is very easy, assuming a simple unsigned long cookie is enough  
for SeLinux, to fit in the current MAP_NOZERO.   Well, we have to  
change something in the current struct page _mapcount reuse, but  
that doable. There is one line to change, that is the line where  
the cookie is assigned  to the mm_struct.


I think if you create the concept of a "process equivalence class"  
and add an LSM hook for it, then the unsigned long could just store  
which equivalence class the page is in.  The default without LSMs  
would be to use mutual-ptraceability as the equivalence class (IE:  
the UID with a proviso for SUID binaries).  LSMs should be able to  
create a process_equivalence_class hook which when called returns an  
unsigned long identifying the "equivalence class" (IE: pool) into  
which the page is placed when freed (or ((unsigned long)-1) to  
forcibly zero the page).  When a process requests a maybe-not-zeroed  
page, the LSM hook would be called again to determine what  
equivalence class should be used, (or ((unsigned long)-1) for dont- 
use-any-class).


Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [1/2] 2.6.22-rc6: known regressions with patches

[Michal Piotrowski]

Hi Ingo,

Ingo Molnar pisze:
> * Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> 
>> Subject: fix nmi_watchdog=2 bootup hang
>> References : http://lkml.org/lkml/2007/6/25/51
>> Submitter  : Ingo Molnar <[EMAIL PROTECTED]>
>> Caused-By  : Jeremy Fitzhardinge <[EMAIL PROTECTED]>
>> Andi Kleen <[EMAIL PROTECTED]>
>> commit f8822f42019eceed19cc6c0f985a489e17796ed8
>> Status : patch available
> 
> fixed by:
> 
>  commit b9e3614f444f6546204f4538afcaa3ebe36d49f2
>  Author: Bjrn Steinbrink <[EMAIL PROTECTED]>
>  Date:   Mon Jun 25 23:04:37 2007 +0200
> 
>  fix nmi_watchdog=2 bootup hang
> 
>   Ingo
> 


It's already removed

364 2007-06-27 00:19:54 8494mkkp"fix nmi_watchdog=2 
bootup hang" fixed

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/

[PATCH][isapnp] Fix a potential NULL pointer dereference in isapnp_read_tag()

[Jesper Juhl]

The Coverity checker spotted (as bug #809) that we dereference 'type' 
long before we actually test it against NULL in 
drivers/pnp/isapnp/core.c::isapnp_read_tag() - both branches of the 
'if (tag & 0x80)' dereference type, and since this 'if' is before the test 
against NULL and the return of -1, this will blow up is ever type is NULL.
This is easy to fix by simply moving the NULL test to the beginning of 
the function.


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

 drivers/pnp/isapnp/core.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
diff --git a/drivers/pnp/isapnp/core.c b/drivers/pnp/isapnp/core.c
index a0b1587..5696924 100644
--- a/drivers/pnp/isapnp/core.c
+++ b/drivers/pnp/isapnp/core.c
@@ -356,6 +356,8 @@ static int __init isapnp_read_tag(unsigned char *type, 
unsigned short *size)
 {
unsigned char tag, tmp[2];
 
+   if (!type)  /* wrong type */
+   return -1;
isapnp_peek(, 1);
if (tag == 0)   /* invalid tag */
return -1;
@@ -370,8 +372,6 @@ static int __init isapnp_read_tag(unsigned char *type, 
unsigned short *size)
 #if 0
printk(KERN_DEBUG "tag = 0x%x, type = 0x%x, size = %i\n", tag, *type, 
*size);
 #endif
-   if (type == 0)  /* wrong type */
-   return -1;
if (*type == 0xff && *size == 0x)   /* probably invalid data */
return -1;
return 0;


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

Re: [possible regression] 2.6.22 reiserfs/libata sporadically hangs on resume from hibernation

[Michal Piotrowski]

Andrey Borzenkov pisze:
> On Sunday 01 July 2007, Rafael J. Wysocki wrote:
>> On Saturday, 30 June 2007 06:59, Andrey Borzenkov wrote:
>>> Since 2.6.18 I do not have suspend to RAM; now I am starting to lose
>>> suspend to disk :)
>>>
>>> Environment - vanilla kernel (2.6.22-rc6 currently + squashfs + single
>>> pata_ali patch to switch off DMA on CD-ROM), single root on reiserfs,
>>> libata with pata_ali driver.
>>>
>>> Until 2.6.22-rc I never had problems with hibernation. With 2.6.22-rc
>>> system hung at least once in every rcX. Up to rc6 those lockups were
>>> absolutely silent (black screen without reaction to any key). In rc6 I
>>> just got something different. After resume I got on screem:
>>>
>>> swsusp: Marking nosave pages: 0009f000-0010
>>> swsusp: Basic memory bitmaps created
>>> swsusp: Basic memory bitmaps freed
>>>
>>> After that it just sits there doing nothing. Ther was brief sound of HDD
>>> but I suspect it was related more to power-on. System was responding to
>>> power-on button press:
>>>
>>> ACPI Error (event-0305): No installed handler for fixed event [0002
>>> 20070125]
>>>
>>> And SysRq was functioning.
>> That probably means that there's a deadlock somewhere in there.
>>
>>> Unfortunately I do not have serial console so I
>>> copy manually stacks from several last screens of output; I have tried to
>>> make a photo but right now my kbluetooth is refusing to work at all so I
>>> cannot transfer them :( (but I suspect quality would be too bad anyway)
>>>
>>> laptop_mode D
>>> io_schedule+0xe/0x20
>> Looks suspicious to me.  Can you identify what line of code this points to?
>>
> 
> If you could explain how to ...

gdb vmlinux

(gdb) l *io_schedule+0xe

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/

[PATCH][XFS][resend] memory leak; allocated transaction not freed in xfs_inactive_free_eofblocks() in failure case.

[Jesper Juhl]

(this is back from May 16 2007, resending since it doesn't look like 
the patch ever made it in anywhere)


Fix XFS memory leak; allocated transaction not freed in 
xfs_inactive_free_eofblocks() in failure case.

the code allocates a transaction, but in the case where 'truncate' is
!=0 and xfs_itruncate_start(ip, XFS_ITRUNC_DEFINITE, 0); happens to return
an error, we'll just return from the function without dealing with the
memory allocated byxfs_trans_alloc() and assigned to 'tp', thus it'll be
orphaned/leaked - not good.

Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
--- 
 fs/xfs/xfs_vnodeops.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/fs/xfs/xfs_vnodeops.c b/fs/xfs/xfs_vnodeops.c
index de17aed..32519cf 100644
--- a/fs/xfs/xfs_vnodeops.c
+++ b/fs/xfs/xfs_vnodeops.c
@@ -1260,6 +1260,7 @@ xfs_inactive_free_eofblocks(
error = xfs_itruncate_start(ip, XFS_ITRUNC_DEFINITE,
ip->i_size);
if (error) {
+   xfs_trans_cancel(tp, 0);
xfs_iunlock(ip, XFS_IOLOCK_EXCL);
return error;
}


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

[PATCH][XFS][resend] fix memory leak in xfs_inactive()

[Jesper Juhl]

(this is back from May 16 2007, resending since it doesn't look like 
the patch ever made it in anywhere)


The Coverity checker found a memory leak in xfs_inactive().

The offending code is this bit :

1671tp = xfs_trans_alloc(mp, XFS_TRANS_INACTIVE);

At conditional (1): "truncate != 0" taking true path

1672if (truncate) {
1673/*
1674 * Do the xfs_itruncate_start() call before
1675 * reserving any log space because itruncate_start
1676 * will call into the buffer cache and we can't
1677 * do that within a transaction.
1678 */
1679xfs_ilock(ip, XFS_IOLOCK_EXCL);
1680
1681error = xfs_itruncate_start(ip, XFS_ITRUNC_DEFINITE, 0);

At conditional (2): "error != 0" taking true path

1682if (error) {
1683xfs_iunlock(ip, XFS_IOLOCK_EXCL);

Event leaked_storage: Returned without freeing storage "tp"
Also see events: [alloc_fn][var_assign]

1684return VN_INACTIVE_CACHE;
1685}

So, the code allocates a transaction, but in the case where 'truncate' is !=0 
and xfs_itruncate_start(ip, XFS_ITRUNC_DEFINITE, 0); happens to return an 
error, we'll just return from the function without dealing with the memory 
allocated byxfs_trans_alloc() and assigned to 'tp', thus it'll be 
orphaned/leaked - not good.

The bug was introduced by this commit:
http://git2.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d3cf209476b72c83907a412b6708c5e498410aa7

The patch below is

From: Dave Chinner <[EMAIL PROTECTED]>
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
 fs/xfs/xfs_vnodeops.c |1 +
 1 file changed, 1 insertion(+)

Index: 2.6.x-xfs-new/fs/xfs/xfs_vnodeops.c
===
--- 2.6.x-xfs-new.orig/fs/xfs/xfs_vnodeops.c2007-05-11 16:04:03.0 
+1000
+++ 2.6.x-xfs-new/fs/xfs/xfs_vnodeops.c 2007-05-17 12:37:25.671399078 +1000
@@ -1710,6 +1710,7 @@ xfs_inactive(
 
error = xfs_itruncate_start(ip, XFS_ITRUNC_DEFINITE, 0);
if (error) {
+   xfs_trans_cancel(tp, 0);
xfs_iunlock(ip, XFS_IOLOCK_EXCL);
return VN_INACTIVE_CACHE;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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][Documentation][resend] Add missing files and dirs to 00-INDEX in Documentation/

[Jesper Juhl]

(originally send: Wed, 6 Jun 2007, resending since it doesn't seem to have 
been picked up anywhere)


This patch adds descriptions for a number of missing files and directories 
to the Documentation/00-INDEX file.
People really should learn to keep this file up-to-date when adding or 
moving documentation...


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

 Documentation/00-INDEX |  142 
+---
 1 files changed, 133 insertions(+), 9 deletions(-)

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index f08ca95..8b05636 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -12,6 +12,8 @@ Following translations are available on the WWW:
 
 00-INDEX
- this file.
+ABI/
+   - info on kernel <-> userspace ABI and relative interface stability.
 BUG-HUNTING
- brute force method of doing binary search of patches to find bug.
 Changes
@@ -25,37 +27,57 @@ DMA-mapping.txt
 DocBook/
- directory with DocBook templates etc. for kernel documentation.
 HOWTO
-   - The process and procedures of how to do Linux kernel development.
+   - the process and procedures of how to do Linux kernel development.
 IO-mapping.txt
- how to access I/O mapped memory from within device drivers.
 IPMI.txt
- info on Linux Intelligent Platform Management Interface (IPMI) Driver.
 IRQ-affinity.txt
- how to select which CPU(s) handle which interrupt events on SMP.
+IRQ.txt
+   - description of what an IRQ is.
 ManagementStyle
- how to (attempt to) manage kernel hackers.
 MSI-HOWTO.txt
- the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
+PCIEBUS-HOWTO.txt
+   - a guide describing the PCI Express Port Bus driver.
 RCU/
- directory with info on RCU (read-copy update).
 README.DAC960
- info on Mylex DAC960/DAC1100 PCI RAID Controller Driver for Linux.
+README.cycladesZ
+   - info on Cyclades-Z firmware loading.
 SAK.txt
- info on Secure Attention Keys.
+SecurityBugs
+   - procedure for reporting security bugs found in the kernel.
+SubmitChecklist
+   - Linux kernel patch submission checklist.
 SubmittingDrivers
- procedure to get a new driver source included into the kernel tree.
 SubmittingPatches
- procedure to get a source patch included into the kernel tree.
 VGA-softcursor.txt
- how to change your VGA cursor from a blinking underscore.
+accounting/
+   - documentation on accounting and taskstats.
+aoe/
+   - description of AoE (ATA over Ethernet) along with config examples.
 applying-patches.txt
- description of various trees and how to apply their patches.
 arm/
- directory with info about Linux on the ARM architecture.
+atomic_ops.txt
+   - semantics and behavior of atomic and bitmask operations.
+auxdisplay/
+   - misc. LCD driver documentation (cfag12864b, ks0108).
 basic_profiling.txt
- basic instructions for those who wants to profile Linux kernel.
 binfmt_misc.txt
- info on the kernel support for extra binary formats.
+blackfin/
+   - directory with documentation for the Blackfin arch.
 block/
- info on the Block I/O (BIO) layer.
 cachetlb.txt
@@ -68,16 +90,32 @@ cli-sti-removal.txt
- cli()/sti() removal guide.
 computone.txt
- info on Computone Intelliport II/Plus Multiport Serial Driver.
+connector/
+   - docs on the netlink based userspace<->kernel space communication mod.
+console/
+   - documentation on Linux console drivers.
 cpqarray.txt
- info on using Compaq's SMART2 Intelligent Disk Array Controllers.
 cpu-freq/
- info on CPU frequency and voltage scaling.
+cpu-hotplug.txt
+   - document describing CPU hotplug support in the Linux kernel.
+cpu-load.txt
+   - document describing how CPU load statistics are collected.
+cpusets.txt
+   - documents the cpusets feature; assign CPUs and Mem to a set of tasks.
+cputopology.txt
+   - documentation on how CPU topology info is exported via sysfs.
 cris/
- directory with info about Linux on CRIS architecture.
 crypto/
- directory with info on the Crypto API.
+dcdbas.txt
+   - information on the Dell Systems Management Base Driver.
 debugging-modules.txt
- some notes on debugging modules after Linux 2.6.3.
+dell_rbu.txt
+   - document demonstrating the use of the Dell Remote BIOS Update driver.
 device-mapper/
- directory with info on Device Mapper.
 devices.txt
@@ -86,32 +124,52 @@ digiepca.txt
- info on Digi Intl. {PC,PCI,EISA}Xx and Xem series cards.
 dnotify.txt
- info about directory notification in Linux.
+dontdiff
+   - file containing a list of files that should never be diff'ed.
 driver-model/
- directory with info about Linux driver model.
+drivers/
+   - directory with driver documentation (currently only EDAC).
 dvb/
- info on Linux Digital Video Broadcast 

[PATCH][ISDN][resend] Guard against a potential NULL pointer dereference in old_capi_manufacturer()

[Jesper Juhl]

(first send: Monday 25 June 2007, resending due to no response)


In drivers/isdn/capi/kcapi.c::old_capi_manufacturer(), if the call 
to get_capi_ctr_by_nr(ldef.contr); in line 823 returns NULL, then 
we'll be dereferencing a NULL pointer in the very next line.

(Found by Coverity checker as bug #402)


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

 drivers/isdn/capi/kcapi.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/isdn/capi/kcapi.c b/drivers/isdn/capi/kcapi.c
index 3ed34f7..3f9e962 100644
--- a/drivers/isdn/capi/kcapi.c
+++ b/drivers/isdn/capi/kcapi.c
@@ -821,6 +821,8 @@ static int old_capi_manufacturer(unsigned int cmd, void 
__user *data)
return -EFAULT;
}
card = get_capi_ctr_by_nr(ldef.contr);
+   if (!card)
+   return -EINVAL;
card = capi_ctr_get(card);
if (!card)
return -ESRCH;

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

[PATCH][ISDN][resend] fix possible NULL deref on low memory condition in capidrv.c::send_message()

[Jesper Juhl]

(first send: Monday 25 June 2007, resending due to no response)


If we fail to allocate an skb in 
drivers/isdn/capi/capidrv.c::send_message(), then we'll end up 
dereferencing a NULL pointer.
Since out of memory conditions are not unheard of, I believe it 
is better to print a error message and just return rather than 
bring down the whole kernel. 
Sure, doing this may upset some application, but that's still 
better than crashing the whole system.

(ps. please Cc me on replies from the isdn4linux list since I'm not subscribed 
 there)


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

 drivers/isdn/capi/capidrv.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/isdn/capi/capidrv.c b/drivers/isdn/capi/capidrv.c
index 23b6f7b..476012b 100644
--- a/drivers/isdn/capi/capidrv.c
+++ b/drivers/isdn/capi/capidrv.c
@@ -506,9 +506,14 @@ static void send_message(capidrv_contr * card, _cmsg * 
cmsg)
 {
struct sk_buff *skb;
size_t len;
+
capi_cmsg2message(cmsg, cmsg->buf);
len = CAPIMSG_LEN(cmsg->buf);
skb = alloc_skb(len, GFP_ATOMIC);
+   if (!skb) {
+   printk(KERN_ERR "capidrv::send_message: can't allocate mem\n");
+   return;
+   }
memcpy(skb_put(skb, len), cmsg->buf, len);
if (capi20_put_message(, skb) != CAPI_NOERROR)
kfree_skb(skb);

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] b44: power down PHY when interface down

[Lennert Buytenhek]

On Sun, Jul 01, 2007 at 12:24:40AM +0200, Michael Buesch wrote:

> > > Hm, I was going to measure the real power advantage with a
> > > PCI-extender card. But my B44B0 card doesn't seem to work in
> > > that extender card. It works perfectly fine sticked directly into
> > > the motherboard, though, and other cards like a BCM4318 work in
> > > the extender, too.
> > > Not sure what this is.
> > > The extender has an application note about nonworking cards in the
> > > extender and a too big resistor on the board IDSEL pin being the
> > > cause of this.
> > 
> > Does the card show up in lspci at all?
> 
> No it doesn't.

Right, so it sounds like it might be this issue.


> > Does the extender board have a PCI-PCI bridge on it?  (If not,
> > there's not really any reason to resistively couple the IDSEL
> > line to the host, since the host should take care of that.)
> 
> There's no bridge. It just decouples all voltage lines, so you can
> drive it from external supply and/or measure voltages and current.
> On the PCB it looks like the the IDSEL line is rather directly
> routed to the host IDSEL. It just goes through one of the bus
> isolation chips. So I guess (just my guess) that this chip has some
> resistance and if the total resistance of the chip + the IDSEL
> resistor on the mainboard goes above some threshold it doesn't work
> anymore for some cards. In the application note they write
> about trouble for IDSEL resistors >51ohms.

More or less.  You can't add the resistances like that, since the
bus isolation chip buffers the IDSEL signal, but it is correct that
if the host's IDSEL resistor is larger than a certain value, the
combination of the resistive coupling of IDSEL plus the extra buffer
in the isolator might be causing the IDSEL input on the 'guest' PCI
board to assert too late (or not assert at all), causing config
accesses to fail.

(This also depends on the specific 'guest' PCI board used, as you
noted, due to differing IDSEL trace lengths/capacitances and input
pin capacitances on different PCI boards.  Also, it might work at
33 MHz but not work at 66 MHz, etc.)

If you feel adventurous, you could try to hack around this by
figuring out which AD[31:16] line this PCI slot's IDSEL line is
resistively coupled to (depends on the slot), and then adding
another parallel resistor on the board itself to make the bus
isolator's input buffer charge faster.  Note that this does
increase the load on that specific AD[] line, which might cause
other funny effects.


> > > Maybe I can try with another machine tomorrow.
> > 
> > That would only make a difference if there is no PCI-PCI bridge on
> > the extender board.
> 
> Well, they suggest it in the application note as a possible fix. ;)

The bus isolation chip doesn't count as a PCI-PCI bridge. :)  I'm just
saying that you wouldn't see the issue you are seeing now if the
extender board had a real PCI-PCI bridge on it, since in that case the
type 0 config access to the guest PCI board would be generated by the
bridge instead of by the host.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: IRQ handling difference between i386 and x86_64

[Krzysztof Oledzki]

On Sat, 30 Jun 2007, Arjan van de Ven wrote:


On Sat, 2007-06-30 at 16:55 +0200, Krzysztof Oledzki wrote:

Hello,

It seems that IRQ handling is somehow different between i386 and x86_64.

In my Dell PowerEdge 1950 is it possible to enable interrupts spreading
over all CPUs. This a single CPU, four CORE system (Quad-Core E5335 Xeon)
so I think that interrupts migration may be useful. Unfortunately, it
works only with 32-bit kernel. Booting it with x86_64 leads to situation,
when all interrupts goes only to the first cpu matching a smp_affinity
mask.


arguably that is the most efficient behavior... round robin of
interrupts is the worst possible case in terms of performance


Even on dual/quadro core CPUs with shared cache? So why it is possible to 
enable such behaviuor in BIOS, which works only on i386 BTW. :(



are you using irqbalance ? (www.irqbalance.org)


Yes, I'm aware about this useful tool, but in some situations (routing 
for example) it cannot help much as it keeps three cpus idle. :(


Best regards,

Krzysztof Olędzki

Re: [PATCH] retrieve VBE EDID/DDC info independent of used video mode

[Andrew Morton]

On Sat, 30 Jun 2007 18:25:31 -0400 Daniel Drake <[EMAIL PROTECTED]> wrote:

> Jan Beulich wrote:
> > The code to retrieve this information was (a) inside a CONFIG_VIDEO_SELECT
> > section and (b) protected by a check of a variable (vbe_version) that
> > would get initialized only when a VESA mode was selected on the command
> > line.
> 
> This patch solves a 2.6.20.11 (and 2.6.21) regression added by the patch 
> titled "x86: Don't probe for DDC on VBE1.2"
> 
> The regression caused the screen resolution to be incorrectly adjusted 
> by 6 pixels. This patch makes it go back to normal again.
> 
> https://bugs.gentoo.org/show_bug.cgi?id=181067
> 
> Please apply this patch or discuss further :)

Well drat.  I didn't merge the patch because it conflicts with
git-newsetup, and Peter believes that git-newsetup already contains an
equivalent fix.  Testing 2.6.22-rc6-mm1 would confirm that.  Please.

So what do we think?  Should we merge Jan's patch into 2.6.22?  And 2.6.21?
And do we feel that it is safe enough for this?

Or can we afford to leave this bug in place in 2.6.22, which would suck a
bit?


> > Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
> > 
> >  arch/i386/boot/video.S |   28 ++--
> >  1 files changed, 18 insertions(+), 10 deletions(-)
> > 
> > --- linux-2.6.22-rc5/arch/i386/boot/video.S 2007-04-26 05:08:32.0 
> > +0200
> > +++ 2.6.22-rc5-edid-no-vesa-mode/arch/i386/boot/video.S 2007-06-19 
> > 14:34:50.0 +0200
> > @@ -96,6 +96,7 @@
> >  #define PARAM_LFB_PAGES0x32
> >  #define PARAM_VESA_ATTRIB  0x34
> >  #define PARAM_CAPABILITIES 0x36
> > +#define PARAM_EDID_INFO0x140
> >  
> >  /* Define DO_STORE according to CONFIG_VIDEO_RETAIN */
> >  #ifdef CONFIG_VIDEO_RETAIN
> > @@ -132,8 +133,8 @@ vid1:
> >  #ifdef CONFIG_VIDEO_RETAIN
> > callrestore_screen  # Restore screen contents
> >  #endif /* CONFIG_VIDEO_RETAIN */
> > -   callstore_edid
> >  #endif /* CONFIG_VIDEO_SELECT */
> > +   callstore_edid
> > callmode_params # Store mode parameters
> > popw%ds # Restore original DS
> > ret
> > @@ -571,16 +572,12 @@ setr1:lodsw
> > jmp _m_s
> >  
> >  check_vesa:
> > -#ifdef CONFIG_FIRMWARE_EDID
> > leawmodelist+1024, %di
> > movw$0x4f00, %ax
> > int $0x10
> > cmpw$0x004f, %ax
> > jnz setbad
> >  
> > -   movw4(%di), %ax
> > -   movw%ax, vbe_version
> > -#endif
> > leawmodelist+1024, %di
> > subb$VIDEO_FIRST_VESA>>8, %bh
> > movw%bx, %cx# Get mode information structure
> > @@ -1935,6 +1932,7 @@ skip10:   movb%ah, %al
> > popw%cx
> > popw%ax
> > ret
> > +#endif /* CONFIG_VIDEO_SELECT */
> >  
> >  store_edid:
> >  #ifdef CONFIG_FIRMWARE_EDID
> > @@ -1945,18 +1943,28 @@ store_edid:
> > pushw   %dx
> > pushw   %di
> >  
> > +   pushw   %ds
> > +   popw%es
> > +   leawmodelist, %di
> > +   movw$0x4f00, %ax
> > +   int $0x10
> > +   cmpw$0x004f, %ax
> > +   setne   %dl
> > +   cmpw$0x0200, 4(%di) # only do EDID on >= VBE2.0
> > +   adc %dl, %dl
> > +
> > pushw   %fs
> > popw%es
> >  
> > movl$0x13131313, %eax   # memset block with 0x13
> > movw$32, %cx
> > -   movw$0x140, %di
> > +   movw$PARAM_EDID_INFO, %di
> > cld
> > rep
> > stosl
> >  
> > -   cmpw$0x0200, vbe_version# only do EDID on >= VBE2.0
> > -   jl  no_edid
> > +   testb   %dl, %dl
> > +   jnz no_edid
> >  
> > pushw   %es # save ES
> > xorw%di, %di# Report Capability
> > @@ -1978,7 +1986,7 @@ store_edid:
> > movw$0x01, %bx
> > movw$0x00, %cx
> > movw$0x00, %dx
> > -   movw$0x140, %di
> > +   movw$PARAM_EDID_INFO, %di
> > int $0x10
> >  
> >  no_edid:
> > @@ -1991,6 +1999,7 @@ no_edid:
> >  #endif
> > ret
> >  
> > +#ifdef CONFIG_VIDEO_SELECT
> >  # VIDEO_SELECT-only variables
> >  mt_end:.word   0   # End of video mode table if built
> >  edit_buf:  .space  6   # Line editor buffer
> > @@ -2000,7 +2009,6 @@ do_restore:   .byte   0   # Screen contents al
> >  svga_prefix:   .byte   VIDEO_FIRST_BIOS>>8 # Default prefix for 
> > BIOS modes
> >  graphic_mode:  .byte   0   # Graphic mode with a linear frame 
> > buffer
> >  dac_size:  .byte   6   # DAC bit depth
> > -vbe_version:   .word   0   # VBE bios version
> >  
> >  # Status messages
> >  keymsg:.ascii  "Press  to see video modes available, "
> > 
> > 
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  

Re: [patch 0/6] sys_indirect RFC - sys_indirect introduction

[Davide Libenzi]

On Sat, 30 Jun 2007, Davide Libenzi wrote:

> Think about if we had this for the latest pselect/ppoll/epoll_pwait. 
> Think about how your solution and mine would apply to that very much 
> concrete case.

This is how all those overloaded syscalls looks like, BTW:

if (sigmask) {
if (sigsetsize != sizeof(sigset_t))
return -EINVAL;
if (copy_from_user(, sigmask, sizeof(ksigmask)))
return -EFAULT;
sigdelsetmask(, sigmask(SIGKILL) | sigmask(SIGSTOP));
sigprocmask(SIG_SETMASK, , );
}
error = sys_XXX(...);
if (sigmask) {
if (error == -EINTR) {
memcpy(>saved_sigmask, ,
   sizeof(sigsaved));
set_thread_flag(TIF_RESTORE_SIGMASK);
} else
sigprocmask(SIG_SETMASK, , NULL);
}

How would you do that with a single shared strcture, w/out adding in all 
signal paths the knowledge of the structure?



- Davide


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

Re: [patch 0/6] sys_indirect RFC - sys_indirect introduction

[Davide Libenzi]

On Sat, 30 Jun 2007, Ulrich Drepper wrote:

> On 6/30/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
> > But, a __get_user(), once you scrap off all the gcc wrapping, is bacially
> > a move. That could even be removed, but really I don't see the reason
> > since it allows for a cleaner strcture definition in userland.
> 
> Don't generalize.  The 4G/4G kernel, for instance, doesn't have this
> property.  Who knows what else will come up.  Anyway, two memcpy are
> slower than one.
>
> > But this does not allow more than one context to be set at a time, like
> > the current implementation does. Ie, the current implementation allow you
> > to:
> 
> Of course it does.  It just requires an appropriate union element.
> I've listed flags and sigset_t as separate union elements since I
> cannot think of a place where we need both extensions.  Should there
> be one this can easily be changed.

Why do you want to stick everything inside a structure, with nested 
strctures and unions, when they clearly are separate contexts?
Also, unions don't work if you want to pass multiple contexts at a time.
You need your structure to contains *all* the possible contexts.
You do not want to sell the monster-struct-union by branding an extra 
__get_user(), do you?
On top of that, the single pointer to the compat multi-context strcture, 
will force the kernel to decide which one of the members is actually valid 
or not. The set/unset callbacks separate each context from a structure POV 
and from a setup/teardown POV, and allow the kernel to use their native 
data structures. Think about if we had this for the latest 
pselect/ppoll/epoll_pwait. Think about how your solution and mine would 
apply to that very much concrete case.




- Davide


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] retrieve VBE EDID/DDC info independent of used video mode

[Daniel Drake]

Jan Beulich wrote:

The code to retrieve this information was (a) inside a CONFIG_VIDEO_SELECT
section and (b) protected by a check of a variable (vbe_version) that
would get initialized only when a VESA mode was selected on the command
line.


This patch solves a 2.6.20.11 (and 2.6.21) regression added by the patch 
titled "x86: Don't probe for DDC on VBE1.2"


The regression caused the screen resolution to be incorrectly adjusted 
by 6 pixels. This patch makes it go back to normal again.


https://bugs.gentoo.org/show_bug.cgi?id=181067

Please apply this patch or discuss further :)


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

 arch/i386/boot/video.S |   28 ++--
 1 files changed, 18 insertions(+), 10 deletions(-)

--- linux-2.6.22-rc5/arch/i386/boot/video.S 2007-04-26 05:08:32.0 
+0200
+++ 2.6.22-rc5-edid-no-vesa-mode/arch/i386/boot/video.S 2007-06-19 
14:34:50.0 +0200
@@ -96,6 +96,7 @@
 #define PARAM_LFB_PAGES0x32
 #define PARAM_VESA_ATTRIB  0x34
 #define PARAM_CAPABILITIES 0x36
+#define PARAM_EDID_INFO0x140
 
 /* Define DO_STORE according to CONFIG_VIDEO_RETAIN */

 #ifdef CONFIG_VIDEO_RETAIN
@@ -132,8 +133,8 @@ vid1:
 #ifdef CONFIG_VIDEO_RETAIN
callrestore_screen  # Restore screen contents
 #endif /* CONFIG_VIDEO_RETAIN */
-   callstore_edid
 #endif /* CONFIG_VIDEO_SELECT */
+   callstore_edid
callmode_params # Store mode parameters
popw%ds # Restore original DS
ret
@@ -571,16 +572,12 @@ setr1:lodsw
jmp _m_s
 
 check_vesa:

-#ifdef CONFIG_FIRMWARE_EDID
leawmodelist+1024, %di
movw$0x4f00, %ax
int $0x10
cmpw$0x004f, %ax
jnz setbad
 
-	movw	4(%di), %ax

-   movw%ax, vbe_version
-#endif
leawmodelist+1024, %di
subb$VIDEO_FIRST_VESA>>8, %bh
movw%bx, %cx# Get mode information structure
@@ -1935,6 +1932,7 @@ skip10:   movb%ah, %al
popw%cx
popw%ax
ret
+#endif /* CONFIG_VIDEO_SELECT */
 
 store_edid:

 #ifdef CONFIG_FIRMWARE_EDID
@@ -1945,18 +1943,28 @@ store_edid:
pushw   %dx
pushw   %di
 
+	pushw	%ds

+   popw%es
+   leawmodelist, %di
+   movw$0x4f00, %ax
+   int $0x10
+   cmpw$0x004f, %ax
+   setne   %dl
+   cmpw$0x0200, 4(%di) # only do EDID on >= VBE2.0
+   adc %dl, %dl
+
pushw   %fs
popw%es
 
 	movl	$0x13131313, %eax		# memset block with 0x13

movw$32, %cx
-   movw$0x140, %di
+   movw$PARAM_EDID_INFO, %di
cld
rep
stosl
 
-	cmpw	$0x0200, vbe_version		# only do EDID on >= VBE2.0

-   jl  no_edid
+   testb   %dl, %dl
+   jnz no_edid
 
 	pushw   %es# save ES

xorw%di, %di# Report Capability
@@ -1978,7 +1986,7 @@ store_edid:
movw$0x01, %bx
movw$0x00, %cx
movw$0x00, %dx
-   movw$0x140, %di
+   movw$PARAM_EDID_INFO, %di
int $0x10
 
 no_edid:

@@ -1991,6 +1999,7 @@ no_edid:
 #endif
ret
 
+#ifdef CONFIG_VIDEO_SELECT

 # VIDEO_SELECT-only variables
 mt_end:.word   0   # End of video mode table if built
 edit_buf:  .space  6   # Line editor buffer
@@ -2000,7 +2009,6 @@ do_restore:   .byte   0   # Screen contents al
 svga_prefix:   .byte   VIDEO_FIRST_BIOS>>8   # Default prefix for BIOS 
modes
 graphic_mode:  .byte   0   # Graphic mode with a linear frame buffer
 dac_size:  .byte   6   # DAC bit depth
-vbe_version:   .word   0   # VBE bios version
 
 # Status messages

 keymsg:.ascii  "Press  to see video modes available, "



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



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

Re: [PATCH] b44: power down PHY when interface down

[Michael Buesch]

On Sunday 01 July 2007 00:03:01 Lennert Buytenhek wrote:
> On Sat, Jun 30, 2007 at 11:53:25PM +0200, Michael Buesch wrote:
> 
> > > When the interface is down (or driver removed), the BroadCom 44xx card 
> > > remains
> > > powered on, and both its MAC and PHY is using up power.
> > > This patch makes the driver issue a MAC_CTRL_PHY_PDOWN when the interface
> > > is halted, and does a partial chip reset turns off the activity LEDs too.
> > > 
> > > Applies to 2.6.22-rc6, or current git head.
> > > 
> > > Tested on a Broadcom BCM4401-B0 card, it saves ~0.5W (measured using 
> > > powertop).
> > 
> > Hm, I was going to measure the real power advantage with a
> > PCI-extender card. But my B44B0 card doesn't seem to work in
> > that extender card. It works perfectly fine sticked directly into
> > the motherboard, though, and other cards like a BCM4318 work in
> > the extender, too.
> > Not sure what this is.
> > The extender has an application note about nonworking cards in the
> > extender and a too big resistor on the board IDSEL pin being the
> > cause of this.
> 
> Does the card show up in lspci at all?

No it doesn't.

> IDSEL drive strength 
> issues should only affect config space accesses.

Yeah.

> Does the extender board have a PCI-PCI bridge on it?  (If not,
> there's not really any reason to resistively couple the IDSEL
> line to the host, since the host should take care of that.)

There's no bridge. It just decouples all voltage lines, so you can
drive it from external supply and/or measure voltages and current.
On the PCB it looks like the the IDSEL line is rather directly
routed to the host IDSEL. It just goes through one of the bus
isolation chips. So I guess (just my guess) that this chip has some
resistance and if the total resistance of the chip + the IDSEL
resistor on the mainboard goes above some threshold it doesn't work
anymore for some cards. In the application note they write
about trouble for IDSEL resistors >51ohms.

> > Maybe I can try with another machine tomorrow.
> 
> That would only make a difference if there is no PCI-PCI bridge on
> the extender board.

Well, they suggest it in the application note as a possible fix. ;)


-- 
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] b44: power down PHY when interface down

[Lennert Buytenhek]

On Sat, Jun 30, 2007 at 11:53:25PM +0200, Michael Buesch wrote:

> > When the interface is down (or driver removed), the BroadCom 44xx card 
> > remains
> > powered on, and both its MAC and PHY is using up power.
> > This patch makes the driver issue a MAC_CTRL_PHY_PDOWN when the interface
> > is halted, and does a partial chip reset turns off the activity LEDs too.
> > 
> > Applies to 2.6.22-rc6, or current git head.
> > 
> > Tested on a Broadcom BCM4401-B0 card, it saves ~0.5W (measured using 
> > powertop).
> 
> Hm, I was going to measure the real power advantage with a
> PCI-extender card. But my B44B0 card doesn't seem to work in
> that extender card. It works perfectly fine sticked directly into
> the motherboard, though, and other cards like a BCM4318 work in
> the extender, too.
> Not sure what this is.
> The extender has an application note about nonworking cards in the
> extender and a too big resistor on the board IDSEL pin being the
> cause of this.

Does the card show up in lspci at all?  IDSEL drive strength
issues should only affect config space accesses.

Does the extender board have a PCI-PCI bridge on it?  (If not,
there's not really any reason to resistively couple the IDSEL
line to the host, since the host should take care of that.)


> Maybe I can try with another machine tomorrow.

That would only make a difference if there is no PCI-PCI bridge on
the extender board.

If the extender resistively couples the host's IDSEL line, you might
see different results on a different host bridge, since different
host bridges can use different numbers of IDSEL stepping cycles.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 0/6] sys_indirect RFC - sys_indirect introduction

[Ulrich Drepper]

On 6/30/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:

But, a __get_user(), once you scrap off all the gcc wrapping, is bacially
a move. That could even be removed, but really I don't see the reason
since it allows for a cleaner strcture definition in userland.


Don't generalize.  The 4G/4G kernel, for instance, doesn't have this
property.  Who knows what else will come up.  Anyway, two memcpy are
slower than one.



But this does not allow more than one context to be set at a time, like
the current implementation does. Ie, the current implementation allow you
to:


Of course it does.  It just requires an appropriate union element.
I've listed flags and sigset_t as separate union elements since I
cannot think of a place where we need both extensions.  Should there
be one this can easily be changed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] b44: power down PHY when interface down

[Michael Buesch]

On Saturday 30 June 2007 13:47:35 Török Edvin wrote:
> When the interface is down (or driver removed), the BroadCom 44xx card remains
> powered on, and both its MAC and PHY is using up power.
> This patch makes the driver issue a MAC_CTRL_PHY_PDOWN when the interface
> is halted, and does a partial chip reset turns off the activity LEDs too.
> 
> Applies to 2.6.22-rc6, or current git head.
> 
> Tested on a Broadcom BCM4401-B0 card, it saves ~0.5W (measured using 
> powertop).

Hm, I was going to measure the real power advantage with a
PCI-extender card. But my B44B0 card doesn't seem to work in
that extender card. It works perfectly fine sticked directly into
the motherboard, though, and other cards like a BCM4318 work in
the extender, too.
Not sure what this is.
The extender has an application note about nonworking cards in the
extender and a too big resistor on the board IDSEL pin being the
cause of this.
Maybe I can try with another machine tomorrow.

-- 
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: A simpler variant on sys_indirect?

[Linus Torvalds]

On Sat, 30 Jun 2007, [EMAIL PROTECTED] wrote:
> 
> The downsides are that you need to save and restore the prefix flags
> across signal delivery, and you have a second user/kernel/user transition.

Both of these are basically horrible mistakes. 

The first one will almost certainly break things that get clever, like 
strace, and just make things really hard to debug.

The second one means that you are guaranteed to be basically twice as slow 
on any fast system call, since the system call overhead itself is usually 
quite a noticeable cost, often dominating everything else.

> And if the kernel entry overhead IS a problem, wouldn't you want to
> batch together the non-prefix system calls as well, using something like
> the syslet ideas that were kicked around recently?  That would
> allow less than 1 kernel entry per system call, even with prefixes.

The batching has serious problems, not the least of which is that it's a 
fundamentally more complex interface, and introduces issues like "how do 
we pass values from one system call to the next". 

That's why I shot it down for syslets too. 

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

Re: 2.6.22-rc6-mm1

[Andrew Morton]

On Sat, 30 Jun 2007 23:10:17 +0200 Sam Ravnborg <[EMAIL PROTECTED]> wrote:

> > I continue to believe that kbuild's lets-trash-your-symlink behaviour is
> > obnoxious, but I was unable to persuade anyone else of this.
> 
> I thought we fixed that long time ago?!?!

Nope, a simple `make oldconfig' breaks the symlink.

> I am heading for vacation for 20 days without Internet (real vacation :-))

Can I come?

> and have properly forget most about Linux and everything about this
> issue when I return.
> In the unlikely event that I recall it I will take a look when I'm back.
> 
> By the way - kbuild.git is lacking behind on patches.
> I have several queded from other peopel and have more in the works myself.
> This will not be looked into until I'm back.

No probs - it's been like that for all time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [possible regression] 2.6.22 reiserfs/libata sporadically hangs on resume from hibernation

[Andrey Borzenkov]

On Sunday 01 July 2007, Rafael J. Wysocki wrote:
> On Saturday, 30 June 2007 06:59, Andrey Borzenkov wrote:
> > Since 2.6.18 I do not have suspend to RAM; now I am starting to lose
> > suspend to disk :)
> >
> > Environment - vanilla kernel (2.6.22-rc6 currently + squashfs + single
> > pata_ali patch to switch off DMA on CD-ROM), single root on reiserfs,
> > libata with pata_ali driver.
> >
> > Until 2.6.22-rc I never had problems with hibernation. With 2.6.22-rc
> > system hung at least once in every rcX. Up to rc6 those lockups were
> > absolutely silent (black screen without reaction to any key). In rc6 I
> > just got something different. After resume I got on screem:
> >
> > swsusp: Marking nosave pages: 0009f000-0010
> > swsusp: Basic memory bitmaps created
> > swsusp: Basic memory bitmaps freed
> >
> > After that it just sits there doing nothing. Ther was brief sound of HDD
> > but I suspect it was related more to power-on. System was responding to
> > power-on button press:
> >
> > ACPI Error (event-0305): No installed handler for fixed event [0002
> > 20070125]
> >
> > And SysRq was functioning.
>
> That probably means that there's a deadlock somewhere in there.
>
> > Unfortunately I do not have serial console so I
> > copy manually stacks from several last screens of output; I have tried to
> > make a photo but right now my kbluetooth is refusing to work at all so I
> > cannot transfer them :( (but I suspect quality would be too bad anyway)
> >
> > laptop_mode D
> > io_schedule+0xe/0x20
>
> Looks suspicious to me.  Can you identify what line of code this points to?
>

If you could explain how to ... (I never understood what those two numbers 
mean :) ) Here is disassembled function

 4168   .section .sched.text
 4169   .p2align 4,,15
 4170   .globl io_schedule
 4171   .type io_schedule,@function
 4172   io_schedule:
 4173 0cd0 55   pushl %ebp
 4174 0cd1 89E5 movl %esp,%ebp
 4175
 4176 0cd3 FF05140A incl per_cpu__runqueues+2388
 4176  
 4177
 4178 0cd9 E8FC call schedule
 4178  FF
 4179
 4180 0cde FF0D140A decl per_cpu__runqueues+2388
 4180  
 4181
 4182 0ce4 5D   popl %ebp
 4183 0ce5 C3   ret
 4184   .size io_schedule,.-io_schedule


> > sync_buffer+0x35/0x40
> > __wait_on_bit+0x45/0x70
> > out_of_line_wait_on_bit+0x6c/0x80
> > __wait_on_buffer+0x27/0x30
> > search_by_key+0x15e/0x1250 [reiserfs]
> > reiserfs_read_locked_inode+0x64/0x570 [reiserfs]
> > reiserfs_iget+0x7e/0xa0 [reiserfs]
> > reiserfs_lookup+0xc7/0x120 [reiserfs]
> > do_lookup+0x138/0x180
> > __link_path_walk+0x787/0xce0
> > link_path_walk+0x44/0xc0
> > path_walk+0x18/0x20
> > do_path_lookup_0x88/0x210
> > __path_lookupintent_open+0x4d/0x90
> > path_lookup_open+0x1f/0x30
> > open_exec+0x28/0xb0
> > do_execve+0x36/0x1d0
> > sys_execve+0x2e/0x80
> > sysenter_past_esp+0x5f/0x99
> >
> > 90clock D
> > __mutex_lock_slow_path+0xa1/0x290
> > mutex_lock+0x21/0x30
> > do_lookup+0xa1/0x180
> > __link_path_walk+0x44/0xc0
> > path_walk+0x18/0x20
> > do_path_lookup+0x78/0x210
> > __user_walk_fd+0x38/0x50
> > vfs_stat_fd+0x21/0x50
> > vfs_stat+0x11/0x20
> > sys_stat64+0x14/0x30
> > sysenter_past_esp+0x5f/0x99
> >
> > alsactl D
> > io_schedule+0xe/0x20
>
> Same here.  Hmm.
>
> > sync_page+0x35/0x40
> > __wait_on_bit_lock+0x3f/0x70
> > __lock_page+0x68/0x70
> > filemap_nopage+0x16c/0x300
> > __handle_mm_faul+0x1d7/0x610
> > do_page_fault+0x1d7/0x610
> > error_code+0x6a/0x70
> > padzero+0x1f/0x30
> > load_elf_binary+0x743/0x1ab0
> > search_binary_handler+0x7b/0x1f0
> > do_execve+0x137/0x1d0
> > sys_execve+0x2e/0x80
> > sysenter_past_esp+0x5f/0x90
> >
> > After that I could remount, sync and reboot using SysRq (well, after
> > reboot it still insisted on replaying insane number of transactions so
> > may be it did *not* remount / ro after all). Before reboot there was
> > brief output that resembled lockdep warnings, but it went too fast to be
> > readable.
> >
> > usual stuff follows
>
> I see you're using CFQ as the default IO scheduler.  Can you please switch
> to AS and see if that changes anything?
>

Sure, but given that I have no idea how to reproduce the lockup, we may never 
know whether it actually helped.


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

Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip

[Andrey Borzenkov]

On Saturday 30 June 2007, Andrey Borzenkov wrote:
> On Saturday 30 June 2007, Bjorn Helgaas wrote:
> > This means that the SMCf010 device *did* respond, I think at the
> > FIR address 0x100.  (I can't figure out the "right" way to print
> > those resource_size_t things, so I added some casts in the appended
> > patch.)
>
> Those can be 64 bit if CONFIG_RESOURCE_64BIT is set; so you probably should
> cast to unsigned long long and use %llx. Or do it conditionally depending
> on above macro.
>
> > Well, the whole problem I'm trying to fix is that we aren't doing
> > resource allocation correctly.  The BIOS has configured the IR
> > device to use port 0x100, and then something else came along and
> > decided to also use port 0x100.
>

After some digging, it works now :) So the story:

PCMCIA includes code for checking for free IO range(s)
code is active only if CONFIG_ISA is defined
CONFIG_ISA has this excellent help text:
  Find out whether you have ISA slots on your motherboard. 
and I was stupid enough to take this literally (having notebook I obviously do 
not have any slots at all)

So after recompiling with CONFIG_ISA defined I now get

[ 2254.136611] cs: IO port probe 0x100-0x3af: excluding 0x100-0x107 
0x2e8-0x2ef 0x378-0x37f
[ 2254.166638] cs: IO port probe 0x3e0-0x4ff: excluding 0x3f8-0x3ff 
0x408-0x40f 0x480-0x48f 0x4d0-0x4d7
[ 2254.194838] cs: IO port probe 0x820-0x8ff: clean.
[ 2254.222401] cs: IO port probe 0xc00-0xcf7: clean.
[ 2254.250056] cs: IO port probe 0xa00-0xaff: clean.

(I wonder why this is repeated 3 times, but well ...) and smsc-ircc2 takes 
over ports 0x100 - 0x107 and is happy.

THANK YOU!

Bjorn, I believe last touch that is needed is to sort out printf issues, 
otherwise patch is fine here.

-andrey


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

Re: [patch] CFS scheduler, -v18

[Willy Tarreau]

Ingo,

I've accidentally discovered a problem with -v18.

Some time ago, I wrote a small program to prevent my laptop from entering
low-power mode, and noticed that after upgrading my laptop's kernel from
2.4.20.9+cfs-v6 to 2.4.20.14+cfs-v18, it completely freezes if I run this
program.

The program is trivial, it just sets its prio to nice +20 and forks a busy
loop. I've added the ability to stop the loop after a user-definable number
of iterations, and I can confirm that it unfreezes when the loop ends. I'm
not even root when I run it.

Everything freezes, including the frame-buffer. It's not 100% reproducible, I
would say 90% only. Sometimes it requires a few seconds before freezing. It
*seems* to me that running another task in parallel (such as vmstat) increases
its chances to freeze. It seems like nicing to +19 does not cause any trouble.

I've tried it on my dual athlon, and with 1 process I see occasional pauses of
1 or 2 seconds, and with 2 processes, I see fairly larger pauses.

Here's the trivial program. Probably you'll find an obvious bug.

Regards,
Willy

---

/*
 * cfs-freeze.c
 * Fork a busy loop running with idle prio. This often results
 * in complete freezes with CFS-v18.
 *
 * $ gcc -O2 -s -o cfs-freeze cfs-freeze.c
 * $ ./cfs-freeze
 */

#include 
#include 
#include 
#include 
#include 
#include 


int main(int argc, char **argv) {
struct sched_param sch;
long long i;

if (argc > 1)
i = atoll(argv[1]);

if (i <= 0)
i = 4 * 1000 * 1000 * 1000ULL;

sch.sched_priority = 0;
sched_setscheduler(0, SCHED_OTHER, );
setpriority(PRIO_PROCESS, 0, 20);
if (fork() == 0)
while (i--);
return 0;
}

---

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

Re: 2.6.22-rc6-mm1

[Sam Ravnborg]

On Fri, Jun 29, 2007 at 10:15:10PM -0700, Andrew Morton wrote:
> On Sat, 30 Jun 2007 00:17:46 -0400 [EMAIL PROTECTED] wrote:
> 
> > On Fri, 29 Jun 2007 14:01:30 PDT, Andrew Morton said:
> > > On Fri, 29 Jun 2007 10:50:30 -0400
> > > [EMAIL PROTECTED] wrote:
> > 
> > > > Odd - just for grins, I checked what 'make oldconfig' did when handed a 
> > > > .config
> > > > from 22-rc4-mm2, and it behaved just fine, much to my surprise.
> > > 
> > > That's probably because your old config file was relatively recent, and
> > > had things like CONFIG_BLK_DEV=y in it.
> > 
> > Ahh...  Yeah, it gets a 'make oldconfig' for pretty
> > much every single -mm, I suck at any regression testing other than "since
> > the last -mm".
> > 
> 
> All my .configs have mouldered since I lost the ability to have .config be
> a symlink to a revision-controlled file (used to carry a custom patch for
> this, but it died).
> 
> I continue to believe that kbuild's lets-trash-your-symlink behaviour is
> obnoxious, but I was unable to persuade anyone else of this.

I thought we fixed that long time ago?!?!
I am heading for vacation for 20 days without Internet (real vacation :-))
and have properly forget most about Linux and everything about this
issue when I return.
In the unlikely event that I recall it I will take a look when I'm back.

By the way - kbuild.git is lacking behind on patches.
I have several queded from other peopel and have more in the works myself.
This will not be looked into until I'm back.

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/

dump of ext3 very slow from dm LV

[Ross Vandegrift]

Hello everyone,

A while back I asked about this on the LVM mailing list, but didn't
receive a response.  Am revisiting it now, so would like a broader
audience.

I've run into some substantial read slowness when using dump or tar
to backup filesystems that are stored on LVM2 LVs.  All of my tests
are dumping ext3 filesystems to /dev/null.

I'm seeing speeds in the range of 3-4MiB/s.  If I increase dump's
blocksize to 128KiB records, speed jumps up to about 20KiB/s, which
is better but still frustratingly slow. Going to 1024KiB gets me
about 28MiB/s.

Today I loop mounted a file on my LVM, filled it up with some crap
from urandom and dumped it out.  I was able to get 50-60MiB/s.  

Is this amount of performance loss due to dm expected? My LV is just two
SATA hard disks that I put into a VG. Stupid benchmarks with dd gives me
a raw read speed from the LV of about 60MiB/sec.

I'm using kernel 2.6.18-4-686 from debian.  Any ideas on what's
slowing down dump? 
-- 
Ross Vandegrift
[EMAIL PROTECTED]

"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

A simpler variant on sys_indirect?

[linux]

I was just thinking, while sys_indirect is an interesting way to add
features to a system call, the argument marshalling in user space is a
bit of a pain.

An alternate idea would be to instead have a "prefix system call" that
sets some flags that apply to the next system call made by that thread
only.  They wouldn't be global mode flags that would mess up libraries.

Maybe I've just been programming x86s too long, but this seems
like a nicer mental model.

The downsides are that you need to save and restore the prefix flags
across signal delivery, and you have a second user/kernel/user transition.

Most of the options seem to be applied to system calls that resolve
path names.  While that is certainly a very important code path, it's
also of non-trivial length, even with the dcache.  How much would one
extra kernel entry bloat the budget?

And if the kernel entry overhead IS a problem, wouldn't you want to
batch together the non-prefix system calls as well, using something like
the syslet ideas that were kicked around recently?  That would
allow less than 1 kernel entry per system call, even with prefixes.

Oh!  That suggests an interesting possibility that solves the signal
handling problem as well:
- Make a separate prefix system call, BUT
- The flags are reset on each return to user space, THUS
- You *have* to use a batch-system-call mechanism for the prefix
  system calls to do anything.

Of course, this takes us right back to the beginning with respect to
messy user-space argument marshalling.  But at least it's only one
indirect system call mechanism, not two.  Wrapping indirect system call
mechanism #1 (to set syscall options) in indirect system call mechanism
#2 (to batch system calls) seems like a bit of a nightmare.

I'm not at all sure that these are good ideas, but they're not obviously
bad ones, to me.  Is it worth looking for synergy between various
"indirect system call" ideas?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 v2 0/5] uvesafb: a general description

[Gabriel C]

Michal Januszewski wrote:

uvesafb is a generic driver for VBE2+ compliant video cards; an enhanced
version of vesafb and a direct successor of vesafb-tng [1].

  


Hi Michal,

I've just tested uvesafb on my workstation ( which has a really old 
GeForce2 MX 400 Nvidia card ) and it didn't worked here.


If I remember right vesafb-ntg worked here and vesafb works for sure :)

Here the error from dmesg :




[   37.397298] uvesafb: Getting VBE info block failed (eax=0x4f00, err=-3)
[   37.397358] uvesafb: vbe_init() failed with -22
[   37.397411] uvesafb: probe of uvesafb.0 failed with error -22




Here some infos I got with read-edid[1] tool:


./get-edid: get-edid version 1.4.1

   Performing real mode VBE call
   Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0
   Function supported
   Call successful

   VBE version 300
   VBE string at 0x0 "NVidia"

VBE/DDC service about to be called
   Report DDC capabilities

   Performing real mode VBE call
   Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0
   Function supported
   Call successful

   Monitor and video card combination does not support DDC1 transfers
   Monitor and video card combination supports DDC2 transfers
   0 seconds per 128 byte EDID block transfer
   Screen is not blanked during DDC transfer

Reading next EDID block

VBE/DDC service about to be called
   Read EDID

   Performing real mode VBE call
   Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0
   Function supported
   Call successful



.

./parse-edid: parse-edid version 1.4.1
./parse-edid: EDID checksum passed.

   # EDID version 1 revision 3
Section "Monitor"
   # Block type: 2:0 3:ff
   # Block type: 2:0 3:fd
   # Block type: 2:0 3:fc
   Identifier "GD 7000S"
   VendorName "GRC"
   ModelName "GD 7000S"
   # Block type: 2:0 3:ff
   # Block type: 2:0 3:fd
   HorizSync 30-83
   VertRefresh 50-75
   # Max dot clock (video bandwidth) 140 MHz
   # Block type: 2:0 3:fc
   # DPMS capabilities: Active off:yes  Suspend:yes  Standby:yes

   Mode"1280x1024" # vfreq 60.013Hz, hfreq 63.974kHz
   DotClock108.50
   HTimings1280 1344 1472 1696
   VTimings1024 1025 1028 1066
   Flags   "+HSync" "+VSync"
   EndMode
   # Block type: 2:0 3:ff
   # Block type: 2:0 3:fd
   # Block type: 2:0 3:fc
EndSection

...

Let me know if you need more infos.

Regards,

Gabriel C

[1] http://john.fremlin.de/programs/linux/read-edid/


PS: You have an typo on line 702 in the patch from your website 
s/vesafb/uvesafb/ in that printk



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [possible regression] 2.6.22 reiserfs/libata sporadically hangs on resume from hibernation

[Rafael J. Wysocki]

On Saturday, 30 June 2007 06:59, Andrey Borzenkov wrote:
> Since 2.6.18 I do not have suspend to RAM; now I am starting to lose suspend 
> to disk :)
> 
> Environment - vanilla kernel (2.6.22-rc6 currently + squashfs + single 
> pata_ali patch to switch off DMA on CD-ROM), single root on reiserfs, libata 
> with pata_ali driver.
> 
> Until 2.6.22-rc I never had problems with hibernation. With 2.6.22-rc system 
> hung at least once in every rcX. Up to rc6 those lockups were absolutely 
> silent (black screen without reaction to any key). In rc6 I just got 
> something different. After resume I got on screem:
> 
> swsusp: Marking nosave pages: 0009f000-0010
> swsusp: Basic memory bitmaps created
> swsusp: Basic memory bitmaps freed
> 
> After that it just sits there doing nothing. Ther was brief sound of HDD but 
> I 
> suspect it was related more to power-on. System was responding to power-on 
> button press:
> 
> ACPI Error (event-0305): No installed handler for fixed event [0002 
> 20070125]
> 
> And SysRq was functioning.

That probably means that there's a deadlock somewhere in there.

> Unfortunately I do not have serial console so I  
> copy manually stacks from several last screens of output; I have tried to 
> make a photo but right now my kbluetooth is refusing to work at all so I 
> cannot transfer them :( (but I suspect quality would be too bad anyway)
> 
> laptop_mode D
>   io_schedule+0xe/0x20

Looks suspicious to me.  Can you identify what line of code this points to?

>   sync_buffer+0x35/0x40
>   __wait_on_bit+0x45/0x70
>   out_of_line_wait_on_bit+0x6c/0x80
>   __wait_on_buffer+0x27/0x30
>   search_by_key+0x15e/0x1250 [reiserfs]
>   reiserfs_read_locked_inode+0x64/0x570 [reiserfs]
>   reiserfs_iget+0x7e/0xa0 [reiserfs]
>   reiserfs_lookup+0xc7/0x120 [reiserfs]
>   do_lookup+0x138/0x180
>   __link_path_walk+0x787/0xce0
>   link_path_walk+0x44/0xc0
>   path_walk+0x18/0x20
>   do_path_lookup_0x88/0x210
>   __path_lookupintent_open+0x4d/0x90
>   path_lookup_open+0x1f/0x30
>   open_exec+0x28/0xb0
>   do_execve+0x36/0x1d0
>   sys_execve+0x2e/0x80
>   sysenter_past_esp+0x5f/0x99
> 
> 90clock D
>   __mutex_lock_slow_path+0xa1/0x290
>   mutex_lock+0x21/0x30
>   do_lookup+0xa1/0x180
>   __link_path_walk+0x44/0xc0
>   path_walk+0x18/0x20
>   do_path_lookup+0x78/0x210
>   __user_walk_fd+0x38/0x50
>   vfs_stat_fd+0x21/0x50
>   vfs_stat+0x11/0x20
>   sys_stat64+0x14/0x30
>   sysenter_past_esp+0x5f/0x99
> 
> alsactl D
>   io_schedule+0xe/0x20

Same here.  Hmm.

>   sync_page+0x35/0x40
>   __wait_on_bit_lock+0x3f/0x70
>   __lock_page+0x68/0x70
>   filemap_nopage+0x16c/0x300
>   __handle_mm_faul+0x1d7/0x610
>   do_page_fault+0x1d7/0x610
>   error_code+0x6a/0x70
>   padzero+0x1f/0x30
>   load_elf_binary+0x743/0x1ab0
>   search_binary_handler+0x7b/0x1f0
>   do_execve+0x137/0x1d0
>   sys_execve+0x2e/0x80
>   sysenter_past_esp+0x5f/0x90
> 
> After that I could remount, sync and reboot using SysRq (well, after reboot 
> it 
> still insisted on replaying insane number of transactions so may be it did 
> *not* remount / ro after all). Before reboot there was brief output that 
> resembled lockdep warnings, but it went too fast to be readable.
> 
> usual stuff follows

I see you're using CFQ as the default IO scheduler.  Can you please switch to
AS and see if that changes anything?

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Optional Beeping During Resume From Suspend To Ram.

[Rafael J. Wysocki]

Hi,

On Saturday, 30 June 2007 12:11, Pavel Machek wrote:
> Hi!
> 
> > > > Sorry, but I can't resist the opportunity to say "Send a patch!" :)
> > > > 
> > > > Seriously, though, I'd prefer not to. If we rename that acpi video 
> > > > flags 
> > > > variable (I assume this is what you're thinking of), we only create 
> > > > cause for 
> > > > confusion. A variable should for debugging or for controlling quirks, 
> > > > not for 
> > > > both at the same time.
> > > 
> > > Cause for confusion? We are currently using 2 bits of that variable,
> > > and we want to add one more bit. I seriously doubt that can confuse
> > > anyone.
> > 
> > Well, indeed it would be more elegant to rename the existing flags variable
> > and use another bit out of it, but I personally don't think it's _that_
> > important.  At least, I don't think we should block the patch
> > because of that.
> 
> It is not _that_ important.
> 
> > BTW, has anyone confirmed that it works on i386?
> 
> If you have patch somewhere nearby, I can test it on i386 and make it
> use just one flags variable.

http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc6/patches/28-Optional-Beeping-During-Resume-From-RAM.patch

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/ADMA TIMEOUTS, dmesg output

[Jeff Garzik]

Charles Shannon Hendrix wrote:



Following this post is output from Linux kernel 2.6.21 showing ADMA 
timeouts.


2.6.21 has improved the situation over earlier kernels, but the problems 
do still occur.


nforce4 chipset, Seagate Barracuda SATA drives.

This is meant mainly as an additional data point in case it helps 
someone debug the problem.


Does setting 'adma' module option to zero fix things?

Jeff



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

Re: drivers/net/wireless/libertas/rx.c: use-after-free

[Dan Williams]

On Fri, 2007-06-29 at 21:51 +0200, Adrian Bunk wrote:
> The Coverity checker spotted the following use-after-free of "skb" in 
> drivers/net/wireless/libertas/rx.c introduced by
> commit 9012b28a407511fb355f6d2176a12d4653489672 (WTF did this commit
> with the title "libertas: make debug configurable" add the 
> "skb->protocol = __constant_htons(0x0019);" line?):

Holger, that's all you :)

dan

> <--  snip  -->
> 
> ...
> static int process_rxed_802_11_packet(wlan_private * priv, struct sk_buff 
> *skb)
> {
> ...
> libertas_upload_rx_packet(priv, skb);
> 
> ret = 0;
> 
> done:
> skb->protocol = __constant_htons(0x0019);   /* ETH_P_80211_RAW */
> ...
> 
> <--  snip  -->
> 
> 
> cu
> Adrian
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.21.5-rt17 on lenovo t61, some BUG's (lukewarm IQ?)

[Fernando Lopez-Lezcano]

On Sat, 2007-06-30 at 21:24 +0200, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote:
> 
> > Hi Ingo, this is happening in a brand new laptop, a Lenovo t61 with a 
> > 7700 processor and the Santa Rosa chipset.
> > 
> > Lukewarm IQ detected in hotplug locking
> > BUG: at kernel/cpu.c:44 lock_cpu_hotplug()
> 
> hm, that's an upstream kernel message. Cpu-hotplug locking is ... a bit 
> messy still. Does it otherwise work? (it should only affect sw-suspend 
> on SMP)

It seems to work (I'm typing this on that machine running rt17). But I'm
still testing things and I have certainly not gotten to the point of
really trying suspend. It is a brand new laptop with new'ish chipset and
stuff so lotsa small details to fix :-)

> > [BTW, I tried to unsuccessfully boot rt18 today in one of my CCRMA 
> > machines but the boot hung when trying to start the acpi daemon - this 
> > was on FC6, I'll try to find out more tomorrow. We are seeing some 
> > hungs with rt17 that I have not tried to diagnose yet]
> 
> do you still see this?

Yes I do. My previous report was not very precise. 

Trying to boot rt18 - this is on fc6 - seems more slugish than rt17
(very subjective), eventually it gets to "starting udev" and it hangs
there. I presume it is trying to start a device driver unsuccessfully
but I don't get any more information and can't get to single user to
find out more. 

Yesterday I noticed that _sometimes_ "starting udev" in rt17 takes some
time. So this may be something that got worse in rt18 as opposed to
something completely new in rt18. 

Sorry for the vageness and let me know if there's something I can do to
try to find out what's going on (looking at rc.sysinit I found there's
some kernel boot options that allow for more debugging but I did not
have time to try that). 

As for the hangs in rt17 I have not been able to find anything out. They
are very sporadic (surprise!) and so far I have found no clues or
commonality in what was happening when the hang occurs. 

-- Fernando


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

Re: [patch 0/6] sys_indirect RFC - sys_indirect introduction

[Davide Libenzi]

On Fri, 29 Jun 2007, Ulrich Drepper wrote:

> On 6/29/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
> > [include/linux/indirect.h]
> > #define SYSIND_CTX_OPENFLAGS0
> > struct sysind_ctx_OPENFLAGS {
> > __u32 ctx;
> > __u32 flags;
> 
> I agree that this interface is more than any other in danger of
> needing an interface change.  But I think your solution is a bit too
> expensive and complex.  You need two reads from userlevel.

But, a __get_user(), once you scrap off all the gcc wrapping, is bacially 
a move. That could even be removed, but really I don't see the reason 
since it allows for a cleaner strcture definition in userland.




> The standard way to handle this is a versioned struct.  I.e., define a
> struct for the current needs, define an initial version.  To use the
> syscall pass the version number and the struct pointer to the syscall.
> If the kernel doesn't know the version number it fails.  Otherwise it
> might have to read old versions of the struct which is trivial to do.
> E.g.:
> 
> #define SYSIND_VERSION 1
> #define SYSIND_CTX_OPENFLAGS 0
> #define SYSIND_CTX_SIGMASK 1
> struct sysind_ctx {
>  int ctx;
>  union {
>int flags;
>kernel_sigset_t  sset;
>  };
> };

But this does not allow more than one context to be set at a time, like 
the current implementation does. Ie, the current implementation allow you 
to:

#define SYSIND_CTX_OPENFLAGS0
struct sysind_ctx_OPENFLAGS {
__u32 ctx;
__u32 flags;
};

#define SYSIND_CTX_SIGSET   1
struct sysind_ctx_SIGSET {
__u32 ctx;
__compat_sigset set;
};

struct sysind_ctx_OPENFLAGS octx;
struct sysind_ctx_SIGSET sctx;
struct indirect_ctx *ctxs[2];
unsigned long params[6];

octx.ctx = SYSIND_CTX_OPENFLAGS;
octx.flags = O_CLOEXEC;
sctx.ctx = SYSIND_CTX_SIGSET;
sctx.set = SIG_XYZ | SIG_ABC;
ctxs[0] = (struct indirect_ctx *) 
ctxs[1] = (struct indirect_ctx *) 
params[0] = blah;
params[1] = blew;
...
res = indirect(__NR_, ctxs, 2, params);


So you basically keep the context strcture separated, and allow to pass 
down more then one context to be set.
Another solution would be to have:

struct sysind_ctx_OPENFLAGS {
__u32 flags;
};
struct sysind_ctx_SIGSET {
__compat_sigset set;
};
struct monster_struct {
__u32 size;
__u64 flags;
struct sysind_ctx_OPENFLAGS octx;
struct sysind_ctx_SIGSET sctx;
...
};

Where size gives you the size of the monster structure, and every bit on 
flags tells you which strcture inside monster is valid.
But I'd clearly prefer the former.



- Davide


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.21.5-rt17 on lenovo t61, some BUG's (lukewarm IQ?)

[Ingo Molnar]

* Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote:

> Hi Ingo, this is happening in a brand new laptop, a Lenovo t61 with a 
> 7700 processor and the Santa Rosa chipset.
> 
> Lukewarm IQ detected in hotplug locking
> BUG: at kernel/cpu.c:44 lock_cpu_hotplug()

hm, that's an upstream kernel message. Cpu-hotplug locking is ... a bit 
messy still. Does it otherwise work? (it should only affect sw-suspend 
on SMP)

> [BTW, I tried to unsuccessfully boot rt18 today in one of my CCRMA 
> machines but the boot hung when trying to start the acpi daemon - this 
> was on FC6, I'll try to find out more tomorrow. We are seeing some 
> hungs with rt17 that I have not tried to diagnose yet]

do you still see this?

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [1/2] 2.6.22-rc6: known regressions with patches

[Ingo Molnar]

* Michal Piotrowski <[EMAIL PROTECTED]> wrote:

> Subject: fix nmi_watchdog=2 bootup hang
> References : http://lkml.org/lkml/2007/6/25/51
> Submitter  : Ingo Molnar <[EMAIL PROTECTED]>
> Caused-By  : Jeremy Fitzhardinge <[EMAIL PROTECTED]>
> Andi Kleen <[EMAIL PROTECTED]>
> commit f8822f42019eceed19cc6c0f985a489e17796ed8
> Status : patch available

fixed by:

 commit b9e3614f444f6546204f4538afcaa3ebe36d49f2
 Author: Bjrn Steinbrink <[EMAIL PROTECTED]>
 Date:   Mon Jun 25 23:04:37 2007 +0200

 fix nmi_watchdog=2 bootup hang

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Optional Beeping During Resume From Suspend To Ram.

[Pavel Machek]

Hi!

> > > Sorry, but I can't resist the opportunity to say "Send a patch!" :)
> > > 
> > > Seriously, though, I'd prefer not to. If we rename that acpi video flags 
> > > variable (I assume this is what you're thinking of), we only create cause 
> > > for 
> > > confusion. A variable should for debugging or for controlling quirks, not 
> > > for 
> > > both at the same time.
> > 
> > Cause for confusion? We are currently using 2 bits of that variable,
> > and we want to add one more bit. I seriously doubt that can confuse
> > anyone.
> 
> Well, indeed it would be more elegant to rename the existing flags variable
> and use another bit out of it, but I personally don't think it's _that_
> important.  At least, I don't think we should block the patch
> because of that.

It is not _that_ important.

> BTW, has anyone confirmed that it works on i386?

If you have patch somewhere nearby, I can test it on i386 and make it
use just one flags variable.
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: Dynamic ticks make system jerking

[Ingo Molnar]

* Uwe Kleine-König <[EMAIL PROTECTED]> wrote:

> I found the problem, it had only indirectly to do with nohz.  I didn't 
> acknowledge the serial interrupt but as the timer and the serial need 
> the same acknowledgement the serial irq got his ack always when the 
> timer triggerd.  Up to now that delay didn't stick out as the delay 
> was < 10ms.

yeah, that makes sense. Now you've probably got a better serial driver 
as a side-effect :-)

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-rcX Transmeta/APM regression

[Andrew Morton]

On 30 Jun 2007 14:57:06 -0400 [EMAIL PROTECTED] wrote:

> > --- a/arch/i386/kernel/cpu/mtrr/generic.c~i386-mtrr-crash-fix
> > +++ a/arch/i386/kernel/cpu/mtrr/generic.c
> > @@ -65,7 +65,8 @@ get_fixed_ranges(mtrr_type * frs)
> >  
> >  void mtrr_save_fixed_ranges(void *info)
> >  {
> > -   get_fixed_ranges(mtrr_state.fixed_ranges);
> > +   if (cpu_has_mtrr)
> > +   get_fixed_ranges(mtrr_state.fixed_ranges);
> >  }
> >  
> >  static void print_fixed(unsigned base, unsigned step, const 
> > mtrr_type*types)
> 
> This works great, thanks!  Please consider the regression diagnosed and fixed.

OK, thanks.  I'll scoot that linuswards later today.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-rc6-mm1

[Michal Marek]

Andrew Morton wrote:
> On Fri, 29 Jun 2007 14:32:09 +0200
> Mariusz Kozlowski <[EMAIL PROTECTED]> wrote:
>> anyway after unselecting XMON we can see:
>>
>>   CC [M]  fs/xfs/linux-2.6/xfs_ioctl32.o
>> fs/xfs/linux-2.6/xfs_ioctl32.c: In function 'xfs_ioc_bulkstat_compat':
>> fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: 'xfs_inumbers_fmt_compat' 
>> undeclared (first use in this function)
>> fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: (Each undeclared identifier is 
>> reported only once
>> fs/xfs/linux-2.6/xfs_ioctl32.c:334: error: for each function it appears in.)
>> make[2]: *** [fs/xfs/linux-2.6/xfs_ioctl32.o] Blad 1
>> make[1]: *** [fs/xfs] Blad 2
> 
> Michal cc'ed.  I think this is the one which was already reported but
> I haven't seen a fix yet?

Hi, I sent you an updated patch yesterday (should I've changed the
subject / started a new thread? This was my first patch so bear with
me... :)). Anyway, the mail with the fix is here:
http://lkml.org/lkml/2007/6/29/87

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

Re: [patch 0/4] MAP_NOZERO v2 - VM_NOZERO/MAP_NOZERO early summer madness

[Davide Libenzi]

On Fri, 29 Jun 2007, Kyle Moffett wrote:

> Well I would be very interested in actually being able to use this feature
> under SELinux, I think that just the underlying "can-I-use-this-page" logic
> needs modification.  Maybe "MAP_REUSABLE"?  That would both imply that we can
> accept reused (IE: nonzeroed) memory *AND* that the current page may be reused
> (IE: remapped without zeroing), although you could conceivably have one flag
> for each case.  The userspace allocator should be able to (when prompted by
> MAP_REUSABLE) look in a page "pool" of sorts before falling back to a zeroed
> page.  The pool would be created for a given "key" the first time it unmaps
> MAP_REUSABLE pages, possibly using the memory freed by said unmap.

Hmm, why would you need MAP_REUSABLE? If a page is visible at any time for 
a given UID, and you have a login under such UID, you can fetch the content 
of the page at any time (ie, ptrace_attach, gdb, ...).   And if you are 
not under a UID login, you'll never get to see that page. ATM not even the 
classical "root can see everything" rule is applied.
I think the focus should be to find a case where under the currently 
implemented policy for MAP_NOZERO, MAP_NOZERO represent a loss of security 
WRT no MAP_NOZERO.   I have not been able to find one yet, although Andy 
found a potential one in the setuid+exec/ptrace race (fixed by a patch 
that should IMO go in in any case).
The more ppl think about breaking it, the better it is.




> The real trick is how to define the "key".  The default, without LSMs, should
> be something like the UID.  SELinux, on the other hand, would probably want to
> use some kind of hash of the label as the "key", (and store the label in each
> pool, as well).  That way SELinux could have a simple access-vector check for
> process:reusepage, as well as an access-vector check and type transition for
> "freereusablepage".  Then a policy could allow most user processes to
> unconditionally reuse pages (which would end up in the access-vector-cache and
> therefore be fast), while security-sensitive processes like ssh-agent could
> neither reuse pages nor have their pages reused, even if they request it.

It is very easy, assuming a simple unsigned long cookie is enough for 
SeLinux, to fit in the current MAP_NOZERO.   Well, we have to change 
something in the current struct page _mapcount reuse, but that doable.
There is one line to change, that is the line where the cookie is assigned 
to the mm_struct.   From there on, it's all handled the same way.
If the hash is any longer than unsigned long, I don't really think is ever 
gonna fly, being it stored inside a struct page.
Also, if you start introducing "keys" whose domain is wider than a single 
user, then you'll run for sure in some sort of problem.   This is why the 
current code does not even try to go into the "group" policies.
IMO all this may have some sense if 1) it is very simple 2) limits code 
and data structures bloat to very little or nothing 3) stays all the way 
to the safe side, at the cost of losing some possible valid pages to be 
recycled.   After all, MAP_NOZERO is an hint and not a requirement.
I think that the current method (either UID or KEY based) is simple, does 
not add extra management pools and, *so far*, is not showing security 
leaks.




- Davide


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-rcX Transmeta/APM regression

[linux]

Responding to various proposed fixes:

> Index: linux/arch/i386/kernel/cpu/mtrr/main.c
> ===
> --- linux.orig/arch/i386/kernel/cpu/mtrr/main.c
> +++ linux/arch/i386/kernel/cpu/mtrr/main.c
> @@ -734,8 +734,11 @@ void mtrr_ap_init(void)
>   */
>  void mtrr_save_state(void)
>  {
> - int cpu = get_cpu();
> + int cpu;
>  
> + if (!cpu_has_mtrr)
> + return;
> + cpu  = get_cpu();
>   if (cpu == 0)
>   mtrr_save_fixed_ranges(NULL);
>   else

This does not change the symptoms in any way.

> --- a/arch/i386/kernel/cpu/mtrr/generic.c~i386-mtrr-crash-fix
> +++ a/arch/i386/kernel/cpu/mtrr/generic.c
> @@ -65,7 +65,8 @@ get_fixed_ranges(mtrr_type * frs)
>  
>  void mtrr_save_fixed_ranges(void *info)
>  {
> - get_fixed_ranges(mtrr_state.fixed_ranges);
> + if (cpu_has_mtrr)
> + get_fixed_ranges(mtrr_state.fixed_ranges);
>  }
>  
>  static void print_fixed(unsigned base, unsigned step, const mtrr_type*types)

This works great, thanks!  Please consider the regression diagnosed and fixed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [OT] Re: Linux Kernel include files

[Daniel Hazelton]

On Saturday 30 June 2007 08:02:16 Joerg Schilling wrote:
> Willy Tarreau <[EMAIL PROTECTED]> wrote:
> > Jörg,
> >
> > On Thu, Jun 28, 2007 at 12:39:57PM +0200, Joerg Schilling wrote:
> > > David Woodhouse <[EMAIL PROTECTED]> wrote:
> > > > On Thu, 2007-06-28 at 12:27 +0200, Joerg Schilling wrote:
> > > > > David Woodhouse <[EMAIL PROTECTED]> wrote:
> > > > > > By the way, your mailer seems to be sometimes omitting
> > > > > > In-Reply-To: and References: headers, which RFC2822 says you
> > > > > > SHOULD include in replies.
> > > > >
> > > > > Sending such accusation without knowing the reason is not polite.
> > > >
> > > > It's not an accusation -- it's merely an observation. You may not
> > > > have noticed that your mailer was misbehaving; now you _do_ know, and
> > > > if you care about RFC compliance you might want to fix it. You're not
> > > > _obliged_ to fix it, of course. I just thought you'd like to know.
> > >
> > > Well there you are: my mailer is definitely NOT missbehaving.
> > > Please do not repeat similar accusations when not knowing the reason.
> >
> > Attacking people who suggest to you they *may* have noticed an anomaly is
> > not polite at all, childish at best, and counter-productive in any case.
>
> Well, then please write this to the person who did attack me for no reason!
>
> What he did is typical trollish behavior, as he tried to turn a technical
> based discussion into a flame war for no reason.
>
> Jörg

Jörg - I see no attack. What I do see is a quite friendly notification that 
your mail program appears to be omitting those headers in certain mails and 
that such action is in violation of a published standard.

Your response was inflammatory, rude and very trollish. And when the person 
calmly restated himself and the reason he made the original comment you again 
responded in an extremely unpleasant manner.

When notified that your behavior was incorrect you pointed fingers and 
yelled "He started it!" - something that *CHILDREN* do.

Since it appears that you act like a child its time to add you to my killfile 
again.

DRH

-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-rc6-mm1 Intel DMAR crash on AMD x86_64

[Andi Kleen]

Muli Ben-Yehuda <[EMAIL PROTECTED]> writes:
> 
> The convention is to print a KERN_DEBUG message if hardware is not
> found when probing it, otherwise the boot messages become cluttered
> with lots of "$FOO not found".

No the convention is to print no message at all when nothing is found
Some drivers fail this, but they're bad examples.

-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: dma_mapping_ops for i386

[Herbert Xu]

Muli Ben-Yehuda <[EMAIL PROTECTED]> wrote:
>
>> And probably some similar mechanism for network drivers that limits
>> MTUs.
> 
> Will that guarantee that block and net IOs will not straddle a page
> boundary?

Mostly.  There is the thorny case of slab debugging that breaks
these nice assumptions.

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

SATA/ADMA TIMEOUTS, dmesg output

[Charles Shannon Hendrix]

Following this post is output from Linux kernel 2.6.21 showing ADMA timeouts.

2.6.21 has improved the situation over earlier kernels, but the problems do 
still occur.


nforce4 chipset, Seagate Barracuda SATA drives.

This is meant mainly as an additional data point in case it helps someone debug 
the problem.


---


[192487.538000] SCSI device sdb: write cache: enabled, read cache: enabled, does
n't support DPO or FUA
[211093.118000] ata4: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl 0
x1501000 status 0x400 next cpb count 0x0 next cpb idx 0x0
[211093.118000] ata4: CPB 0: ctl_flags 0x9, resp_flags 0x0
[211093.118000] ata4: timeout waiting for ADMA IDLE, stat=0x400
[211093.118000] ata4: timeout waiting for ADMA LEGACY, stat=0x400
[211093.118000] ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
[211093.118000] ata4.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 d
ata 0
[211093.118000]  res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (time
out)
[211093.421000] ata4: soft resetting port
[211093.626000] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[211093.632000] ata4.00: configured for UDMA/133
[211093.632000] ata4: EH complete
[211093.632000] SCSI device sdb: 156301488 512-byte hdwr sectors (80026 MB)
[211093.632000] sdb: Write Protect is off
[211093.632000] sdb: Mode Sense: 00 3a 00 00
[211093.632000] SCSI device sdb: write cache: enabled, read cache: enabled, does
n't support DPO or FUA
[221976.072000] ata4: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl 0
x1501000 status 0x400 next cpb count 0x0 next cpb idx 0x0
[221976.072000] ata4: CPB 0: ctl_flags 0x9, resp_flags 0x0
[221976.072000] ata4: timeout waiting for ADMA IDLE, stat=0x400
[221976.072000] ata4: timeout waiting for ADMA LEGACY, stat=0x400
[221976.072000] ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
[221976.072000] ata4.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 d
ata 0
[221976.072000]  res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (time
out)
[221976.375000] ata4: soft resetting port
[221976.58] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[221976.586000] ata4.00: configured for UDMA/133
[221976.586000] ata4: EH complete
[221976.587000] SCSI device sdb: 156301488 512-byte hdwr sectors (80026 MB)
[221976.587000] sdb: Write Protect is off
[221976.587000] sdb: Mode Sense: 00 3a 00 00
[221976.587000] SCSI device sdb: write cache: enabled, read cache: enabled, does
n't support DPO or FUA
[222045.513000] ata4: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl 0
x1501000 status 0x400 next cpb count 0x0 next cpb idx 0x0
[222045.513000] ata4: CPB 0: ctl_flags 0x9, resp_flags 0x0
[222045.513000] ata4: timeout waiting for ADMA IDLE, stat=0x400
[222045.513000] ata4: timeout waiting for ADMA LEGACY, stat=0x400
[222045.513000] ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
[222045.513000] ata4.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 d
ata 0
[222045.513000]  res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (time
out)
[222045.816000] ata4: soft resetting port
[222046.021000] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[222046.027000] ata4.00: configured for UDMA/133
[222046.027000] ata4: EH complete
[222046.027000] SCSI device sdb: 156301488 512-byte hdwr sectors (80026 MB)
[222046.027000] sdb: Write Protect is off
[222046.027000] sdb: Mode Sense: 00 3a 00 00
[222046.027000] SCSI device sdb: write cache: enabled, read cache: enabled, does
n't support DPO or FUA



--
shannon   | An Irishman is never drunk as long as he can hold onto
  | one blade of grass and not fall off the face of the earth.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] mmc: at91_mci typo

[Pierre Ossman]

On Tue, 19 Jun 2007 18:32:34 +0200
Nicolas Ferre <[EMAIL PROTECTED]> wrote:

> 
> Typo fix in at91_mci driver : standardized the typo 
> (at91_mci everywhere)
> 
> Signed-off-by: Nicolas Ferre <[EMAIL PROTECTED]> 
> ---

Thanks, applied.


signature.asc
Description: PGP signature

PM policy, hotplug, power saving and WoL

[Henrique de Moraes Holschuh]

On Sat, 30 Jun 2007, Jeff Garzik wrote:
> Like SATA, we actually want to support BOTH -- active hotplug and PHY 
> power-down -- and so this wanders into power management policy.
>
> Give me a knob, and we can program plenty of ethernet|SATA|USB|... drivers 
> to power down the PHY and save power.

While at it, could we please fix our borked WOL interface requirements, so
that the PHY is *never* to be powered down when WOL is active?  This is
another deficiency that userspace has to work around in halt(8)...

If WOL is enabled and supported in a device, the kernel must never do
anything that would cause that device to stop responding to WOL packets.

OTOH, if WOL is disabled, it would be very very nice indeed to be able to
tell the kernel that yes, it is to power down the PHY if it is not in use.
Laptops appreciate it a lot, and so do the switches (which will know they
don't have to forward any traffic over that port).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel doesn't recognize complete memory

[Robert Hancock]

Frank Fiene wrote:

On Samstag, 30. Juni 2007, Robert Hancock wrote:

Frank Fiene wrote:

Lenovo Z61p, Intel Core2 Duo T7200

I have 4GB RAM installed and BIOS recognize 4GB RAM.
Linux kernel (Ubuntu-7.04, 32bit-PAE and 64bit, openSUSE-10.2
32bit-PAE and 64bit) tells me: only 3GB of RAM are installed.

Any other user with a 4GB Thinkpad? tytso?

What can i do? Please help!

Regards
Frank

Please post your bootup dmesg output. If your chipset doesn't support
memory remapping above 4GB or the BIOS doesn't enable it, you won't
be able to use all 4GB of memory.


Here is me dmesg output, fist 400 lines.


BIOS-provided physical RAM map:
 BIOS-e820:  - 0009f000 (usable)
 BIOS-e820: 0009f000 - 000a (reserved)
 BIOS-e820: 000dc000 - 0010 (reserved)
 BIOS-e820: 0010 - bfed (usable)
 BIOS-e820: bfed - bfedf000 (ACPI data)
 BIOS-e820: bfedf000 - bff0 (ACPI NVS)
 BIOS-e820: bff0 - c000 (reserved)
 BIOS-e820: f000 - f400 (reserved)
 BIOS-e820: fec0 - fec1 (reserved)
 BIOS-e820: fed0 - fed00400 (reserved)
 BIOS-e820: fed14000 - fed1a000 (reserved)
 BIOS-e820: fed1c000 - fed9 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820: ff80 - 0001 (reserved)

Yes, that's the problem. Your BIOS/chipset only provides about 3070MB of 
usable RAM to the OS. Unless there is a memory remap option in the BIOS 
that you can enable, there's not much you can do about it.


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/


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

Re: [PATCH] Input: document the proper usage of EV_KEY and KEY_UNKNOWN (v2)

[Henrique de Moraes Holschuh]

On Fri, 29 Jun 2007, Dmitry Torokhov wrote:
> Finally gottent to the patch. It seems a little long-winded, how about
> the patch below instead?

Well, your version of the patch:

1. does not make it clear to *userland* that using EV_SCAN instead of EV_KEY
is something that is not to be done.  If userland wants to use a key that is
not generating an useful EV_KEY, it must remap the key to something.
Otherwise, we are opening our flank to the crap we have with that kludge
from hell AT keyboard reverse scan-code generation all again...  it might
have been unavoidable with the AT keyboard, due to legacy stuff, but there
is no way we should let it happen to anything else.

2. does not make it clear that EV_SCAN events must reflect the scan code
that, when remapped, would reprogram the key that caused that EV_SCAN event
to be generated.

I think these two points need to be addressed by the docs.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: PM policy, hotplug, power saving (was Re: [PATCH] b44: power down PHY when interface down)

[Stephen Hemminger]

On Sat, 30 Jun 2007 12:42:06 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:

> Arjan van de Ven wrote:
> > Matthew Garrett wrote:
> >> Do you still get link beat detection when the phy is powered down?
> 
> > does that matter?
> > If the interface is down, nic drivers aren't expected to detect link... 
> > if userspace wants to find link status it should have the interface up.
> 
> 
> Definitely matters.  Switch renegotiation can take a while, and you must 
> take into account the common case of interface bouncing (immediate down, 
> then up).
> 
> Hoards actively complained the few times we experimented with this, 
> because of e.g. DHCP's habit of bouncing the interface, which resulted 
> in PHY power bouncing, which resulted in negotiation, which resulted in 
> an excrutiating wait on various broken or stupid switches.
> 
> Overall, this may be classed with other problems of a similar sort:  we 
> can power down a PHY, but that removes hotplug capability and extends 
> partner/link negotiation time.
> 
> Like SATA, we actually want to support BOTH -- active hotplug and PHY 
> power-down -- and so this wanders into power management policy.
> 
> Give me a knob, and we can program plenty of ethernet|SATA|USB|... 
> drivers to power down the PHY and save power.
> 
>   Jeff

We do have IFF_DORMANT, but almost no driver uses it. And most
certainly, the common applications wouldn't know how to use 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: Kernel doesn't recognize complete memory

[Frank Fiene]

On Samstag, 30. Juni 2007, Robert Hancock wrote:
> Frank Fiene wrote:
> > Lenovo Z61p, Intel Core2 Duo T7200
> >
> > I have 4GB RAM installed and BIOS recognize 4GB RAM.
> > Linux kernel (Ubuntu-7.04, 32bit-PAE and 64bit, openSUSE-10.2
> > 32bit-PAE and 64bit) tells me: only 3GB of RAM are installed.
> >
> > Any other user with a 4GB Thinkpad? tytso?
> >
> > What can i do? Please help!
> >
> > Regards
> > Frank
>
> Please post your bootup dmesg output. If your chipset doesn't support
> memory remapping above 4GB or the BIOS doesn't enable it, you won't
> be able to use all 4GB of memory.

Here is me dmesg output, fist 400 lines.

Regards
Frank
Linux version 2.6.18.8-0.3-bigsmp ([EMAIL PROTECTED]) (gcc version 4.1.2 
20061115 (prerelease) (SUSE Linux)) #1 SMP Tue Apr 17 08:42:35 UTC 2007
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009f000 (usable)
 BIOS-e820: 0009f000 - 000a (reserved)
 BIOS-e820: 000dc000 - 0010 (reserved)
 BIOS-e820: 0010 - bfed (usable)
 BIOS-e820: bfed - bfedf000 (ACPI data)
 BIOS-e820: bfedf000 - bff0 (ACPI NVS)
 BIOS-e820: bff0 - c000 (reserved)
 BIOS-e820: f000 - f400 (reserved)
 BIOS-e820: fec0 - fec1 (reserved)
 BIOS-e820: fed0 - fed00400 (reserved)
 BIOS-e820: fed14000 - fed1a000 (reserved)
 BIOS-e820: fed1c000 - fed9 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820: ff80 - 0001 (reserved)
2174MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000f67e0
NX (Execute Disable) protection: active
On node 0 totalpages: 786128
  DMA zone: 4096 pages, LIFO batch:0
  Normal zone: 225280 pages, LIFO batch:31
  HighMem zone: 556752 pages, LIFO batch:31
DMI present.
Using APIC driver default
ACPI: RSDP (v002 LENOVO) @ 0x000f67a0
ACPI: XSDT (v001 LENOVO TP-7F0x2180  LTP 0x) @ 0xbfed1c26
ACPI: FADT (v003 LENOVO TP-7F0x2180 LNVO 0x0001) @ 0xbfed1d00
ACPI: SSDT (v001 LENOVO TP-7F0x2180 MSFT 0x010e) @ 0xbfed1eb4
ACPI: ECDT (v001 LENOVO TP-7F0x2180 LNVO 0x0001) @ 0xbfedebc1
ACPI: TCPA (v002 LENOVO TP-7F0x2180 LNVO 0x0001) @ 0xbfedec13
ACPI: MADT (v001 LENOVO TP-7F0x2180 LNVO 0x0001) @ 0xbfedec45
ACPI: MCFG (v001 LENOVO TP-7F0x2180 LNVO 0x0001) @ 0xbfedecad
ACPI: HPET (v001 LENOVO TP-7F0x2180 LNVO 0x0001) @ 0xbfedece9
ACPI: SLIC (v001 LENOVO TP-7F0x2180  LTP 0x) @ 0xbfedee62
ACPI: BOOT (v001 LENOVO TP-7F0x2180  LTP 0x0001) @ 0xbfedefd8
ACPI: SSDT (v001 LENOVO TP-7F0x2180 INTL 0x20050513) @ 0xbfef2686
ACPI: SSDT (v001 LENOVO TP-7F0x2180 INTL 0x20050513) @ 0xbfef28e5
ACPI: SSDT (v001 LENOVO TP-7F0x2180 INTL 0x20050513) @ 0xbfef298b
ACPI: SSDT (v001 LENOVO TP-7F0x2180 INTL 0x20050513) @ 0xbfef2e82
ACPI: DSDT (v001 LENOVO TP-7F0x2180 MSFT 0x010e) @ 0x
ACPI: PM-Timer IO Port: 0x1008
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 6:15 APIC version 20
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1 6:15 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 1, version 32, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
ACPI: HPET id: 0x8086a201 base: 0xfed0
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at c400 (gap: c000:3000)
Detected 1995.077 MHz processor.
Built 1 zonelists.  Total pages: 786128
Kernel command line: root=/dev/sda2 vga=0x375 resume=/dev/sda1 splash=silent 
elevator=deadline PROFILE=haltern
bootsplash: silent mode.
mapped APIC to d000 (fee0)
mapped IOAPIC to c000 (fec0)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 16384 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 3110924k/3144512k available (1703k kernel code, 32200k reserved, 1103k 
data, 200k init, 2227008k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
hpet0: at MMIO 0xfed0 (virtual 0xf880), IRQs 2, 8, 0
hpet0: 3 64-bit timers, 14318180 Hz
Using HPET for base-timer
Calibrating delay using timer specific 

Re: [RFC] automatic CC generation for patch submission

[Dan Aloni]

On Sat, Jun 30, 2007 at 09:32:05AM -0700, Andrew Morton wrote:
>[..]
> 
> > Given a set of historical modifiers of a file, 
> > would you take the most common commiter(s), or the most common 
> > _recent_ commiter(s), or what? It's a bit fuzzy.
> 
> All the above?  Multiply frequency by recency, pick the top five?
> 
> Doesn't matter much: the cost of picking too many is high.
> 
> I shudder at the thought of manually maintaining anything like this.


Why? It shouldn't take much more effort than the effort currently
being taken to maintain the MAINTAINERS file as it is. This field can
even be considered optional - i.e. let the maintainers themselves who
usually send patches to MAINTAINERS just to update their mailing
address add this field _only if they want to_.

Heck, this way it would even help us to see which maintainers are
more attentive :)
 
> > Moreover, it is slow in comparison and assumes the availability of 
> > local .git db, which wouldn't be the case for some porition of patch 
> > submitters.
> 
> a) precalculate the tables once per week
> 
> b) the whole thing wouldn't succeed if it requires software at
>patch-submitter's site.  It'd need to run at vger.
> 

And:

c) The script will need to query vger for each file in the patch
via some protocol..

Do you think it's worth the effort?

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] automatic CC generation for patch submission

[Adrian Bunk]

On Sat, Jun 30, 2007 at 09:32:05AM -0700, Andrew Morton wrote:
> On Sat, 30 Jun 2007 13:47:52 +0300 Dan Aloni <[EMAIL PROTECTED]> wrote:
> 
> > On Sat, Jun 30, 2007 at 02:54:25AM -0700, Andrew Morton wrote:
> > > On Fri, 29 Jun 2007 19:51:53 -0700 "Kok, Auke" <[EMAIL PROTECTED]> wrote:
> > > 
> > > > > Some extensions to the popular E-Mail clients might be needed 
> > > > > here. Also, a bot reading LKML would automatically send links 
> > > > > about posted patches to the other mailing lists whenever 
> > > > > someone forgets to add a CC.
> > > > > 
> > > > > Any comments?
> > > > 
> > > > an easier way to implement this is to add an extra field in the 
> > > > MAINTAINERS 
> > > > file, something like below. All the contact info would stay the same, 
> > > > closely 
> > > > where applicable and it would allow you to also specify specific files 
> > > > as well.
> > > 
> > > We already have that information in git.  Parse the git changelogs of the
> > > affected files, find out who works on them.
> > 
> > I think it's quite complex to make a reliable inference of maintainership 
> > information from git.
> 
> Clever people will work it out.

I don't see how git could tell you to Cc net patches to 
[EMAIL PROTECTED]

> > Given a set of historical modifiers of a file, 
> > would you take the most common commiter(s), or the most common 
> > _recent_ commiter(s), or what? It's a bit fuzzy.
> 
> All the above?  Multiply frequency by recency, pick the top five?
> 
> Doesn't matter much: the cost of picking too many is high.
> 
> I shudder at the thought of manually maintaining anything like this.

Auke suggestion of an additional field in MAINTAINERS makes sense - and 
it leaves it to the maintainers to maintain it similar to the other 
information there.

Independent of whatever software Dan wants to write it would also solve 
problems like the one that MAINTAINERS currently isn't really good in 
telling e.g. who is maintaining drivers/net/wireless/.

> > Moreover, it is slow in comparison and assumes the availability of 
> > local .git db, which wouldn't be the case for some porition of patch 
> > submitters.
> 
> a) precalculate the tables once per week
> 
> b) the whole thing wouldn't succeed if it requires software at
>patch-submitter's site.  It'd need to run at vger.

It might depend on what use cases you think of and whom you expect to 
use it.

For me, a tool that simply tells me whom to Cc for a patch would be a 
great tool.

What you suggest would be something completely different.

cu
Adrian

-- 

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

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

Re: [PATCH] LinuxPPS (with new syscalls API) - new version

[Rodolfo Giometti]

On Fri, Jun 29, 2007 at 05:40:52PM +0100, David Woodhouse wrote:
> 
> Remember you have to support _both_ 32-bit and 64-bit system calls. You
> need to define struct compat_pps_info and struct compat_pps_params, and 
> you'll have to provide a compat wrapper for sys_time_pps_getparams() and
> sys_time_pps_setparams(). You'll also need to extend your
> compat_sys_time_pps_fetch() wrapper to handle the struct pps_info too.

At this point I'm seriously considfering your previous suggestion:

   Had you considered changing the API so that you don't need the
   compatibility wrapper at all? Could you take an integer number of
   µS or ms instead of a struct timespec?

Maybe I can define a special struct for exchanging time data as:

   struct pps_timedata_s {
  long sec;
  long nsec;
   }

and managing time data conversions at userland...

What do you think about that? :)

Thanks,

Rodolfo

-- 

GNU/Linux Solutions  e-mail:[EMAIL PROTECTED]
Linux Device Driver [EMAIL PROTECTED]
Embedded Systems[EMAIL PROTECTED]
UNIX programming phone: +39 349 2432127
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] LinuxPPS (with new syscalls API) - new version

[Rodolfo Giometti]

On Sat, Jun 30, 2007 at 09:38:27AM +0100, Christoph Hellwig wrote:
> 
> Sorry for coming in that late, but using syscalls for something as
> periphal sounds like a very bad idea to me, and the syscalls aren't
> defined nicely either (e.g. you have an ioctl lookalike).  I'd say
> back to the drawingboard.

PPS API is not only a periphal class. RFC 2783 defines new «functions»
that allow accesso to internal system data collected by some
periferals but these devices are never managed as a tipical char or
block device.

I think implementing parts or full RFC 2783 PPS's functions as
syscalls are not so wrong... IMHO, at least! :)

> And yes, even ioctls are nicer than badly designed syscalls :)

I see, but consider that some PPS devices cannot be always connected
with a filedescriptor since, for example, some PPS devices are
connected by serial lines, other by parallel ports and other
(expecially on embedded systems) are connected by CPU's GPIOs.

An userland programs shouldn't know whenever these devices are
connected, they should only know how to collect PPS data from the
system.

> Also code seems to be odd at least in a few places, e.g. all the access_oks
> and double checks of the ioctl-lookalike commands should go.

I already removed such functions in my latest patches. :)

Thanks,

Rodolfo

-- 

GNU/Linux Solutions  e-mail:[EMAIL PROTECTED]
Linux Device Driver [EMAIL PROTECTED]
Embedded Systems[EMAIL PROTECTED]
UNIX programming phone: +39 349 2432127
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

PM policy, hotplug, power saving (was Re: [PATCH] b44: power down PHY when interface down)

[Jeff Garzik]

Arjan van de Ven wrote:

Matthew Garrett wrote:

Do you still get link beat detection when the phy is powered down?



does that matter?
If the interface is down, nic drivers aren't expected to detect link... 
if userspace wants to find link status it should have the interface up.



Definitely matters.  Switch renegotiation can take a while, and you must 
take into account the common case of interface bouncing (immediate down, 
then up).


Hoards actively complained the few times we experimented with this, 
because of e.g. DHCP's habit of bouncing the interface, which resulted 
in PHY power bouncing, which resulted in negotiation, which resulted in 
an excrutiating wait on various broken or stupid switches.


Overall, this may be classed with other problems of a similar sort:  we 
can power down a PHY, but that removes hotplug capability and extends 
partner/link negotiation time.


Like SATA, we actually want to support BOTH -- active hotplug and PHY 
power-down -- and so this wanders into power management policy.


Give me a knob, and we can program plenty of ethernet|SATA|USB|... 
drivers to power down the PHY and save power.


Jeff


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

Re: [PATCH 0/4] fbdev: uvesafb

[Michal Januszewski]

On Tue, Jun 26, 2007 at 11:42:41AM +0100, Jonathan McDowell wrote:

> Have you considered using libx86[1] in v86d? It looks very similar to
> what you have at present and there are plans to extend it to non
> x86(_64) archs.

It looks like an interesting solution and it is indeed similar to what
I'm currently using.  I'll consider switching to it in the next version
of v86d.

Thanks,
Michal

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

[Michal Januszewski]

Documentation for the uvesafb driver.

Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
---
 Documentation/fb/uvesafb.txt |  187 ++
 1 files changed, 187 insertions(+), 0 deletions(-)

diff --git a/Documentation/fb/uvesafb.txt b/Documentation/fb/uvesafb.txt
new file mode 100644
index 000..cfc4e55
--- /dev/null
+++ b/Documentation/fb/uvesafb.txt
@@ -0,0 +1,187 @@
+
+uvesafb - A Generic Driver for VBE2+ compliant video cards
+==
+
+1. Requirements
+---
+
+uvesafb should work with any video card that has a Video BIOS compliant
+with the VBE 2.0 standard.
+
+Unlike other drivers, uvesafb makes use of a userspace helper called
+v86d.  v86d is used to run the x86 Video BIOS code in a simulated and
+controlled environment.  This allows uvesafb to function on arches other
+than x86.  Check the v86d documentation for a list of currently supported
+arches.
+
+v86d source code can be downloaded from the following website:
+  http://dev.gentoo.org/~spock/projects/uvesafb
+
+Please refer to the v86d documentation for detailed configuration and
+installation instructions.
+
+Note that the v86d userspace helper has to be available at all times in
+order for uvesafb to work properly.  If you want to use uvesafb during
+early boot, you will have to include v86d into an initramfs image, and
+either compile it into the kernel or use it as an initrd.
+
+2. Caveats and limitations
+--
+
+uvesafb is a _generic_ driver which supports a wide variety of video
+cards, but which is ultimately limited by the Video BIOS interface.
+The most important limitations are:
+
+- Lack of any type of acceleration.
+- A strict and limited set of supported video modes.  Often the native
+  or most optimal resolution/refresh rate for your setup will not work
+  with uvesafb, simply because the Video BIOS doesn't support the
+  video mode you want to use.  This can be especially painful with
+  widescreen panels, where native video modes don't have the 4:3 aspect
+  ratio, which is what most BIOS-es are limited to.
+- Adjusting the refresh rate is only possible with a VBE 3.0 compliant
+  Video BIOS.  Note that many nVidia Video BIOS-es claim to be VBE 3.0
+  compliant, while they simply ignore any refresh rate settings.
+
+3. Configuration
+
+
+uvesafb can be compiled either as a module, or directly into the kernel.
+In both cases it supports the same set of configuration options, which
+are either given on the kernel command line or as module parameters, e.g.:
+
+ video=uvesafb:1024x768-32,mtrr:3,ywrap (compiled into the kernel)
+
+ # modprobe uvesafb mode=1024x768-32 mtrr=3 scroll=ywrap  (module)
+
+Accepted options:
+
+ypanEnable display panning using the VESA protected mode
+interface.  The visible screen is just a window of the
+video memory, console scrolling is done by changing the
+start of the window.
+
+ywrap   Same as ypan, but assumes your gfx board can wrap-around
+the video memory (i.e. starts reading from top if it
+reaches the end of video memory).  Faster than ypan.
+
+redraw  Scroll by redrawing the affected part of the screen, this
+is the safe (and slow) default.
+
+(If you're using uvesafb as a module, the above three options are
+ used a parameter of the scroll option, e.g. scroll=ypan.)
+
+vgapal  Use the standard VGA registers for palette changes.
+
+pmipal  Use the protected mode interface for palette changes.
+This is the default if the protected mode interface is
+available.
+
+mtrr:n  Setup memory type range registers for the framebuffer
+where n:
+  0 - disabled (equivalent to nomtrr) (default)
+  1 - uncachable
+  2 - write-back
+  3 - write-combining
+  4 - write-through
+
+If you see the following in dmesg, choose the type that matches
+the old one.  In this example, use "mtrr:2".
+...
+mtrr: type mismatch for e000,800 old: write-back new: write-combining
+...
+
+nomtrr  Do not use memory type range registers.
+
+vremap:n
+Remap 'n' MiB of video RAM.  If 0 or not specified, remap memory
+according to video mode.
+
+vtotal:n
+If the video BIOS of your card incorrectly determines the total
+amount of video RAM, use this option to override the BIOS (in MiB).
+
+  The mode you want to set, in the standard modedb format.  Refer to
+modedb.txt for a detailed description.  When uvesafb is compiled as
+a module, the mode string should be provided as a value of the
+'mode' option.
+
+vbemode:x
+Force the use of VBE mode x.  The mode will only be set if it's
+found in the VBE-provided list of supported modes.
+NOTE: The mode number 'x' should be specified in VESA mode number
+notation, not the Linux kernel one (eg. 257 instead 

[PATCH v2 3/5] uvesafb: change connector's max message size

[Michal Januszewski]

Change the maximum message size to 4k to allow transfers of VBE
data blocks from userspace.

Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
---
 include/linux/connector.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/linux/connector.h b/include/linux/connector.h
index 14cecaf..12e3140 100644
--- a/include/linux/connector.h
+++ b/include/linux/connector.h
@@ -44,7 +44,7 @@
 /*
  * Maximum connector's message size.
  */
-#define CONNECTOR_MAX_MSG_SIZE 1024
+#define CONNECTOR_MAX_MSG_SIZE 4096
 
 /*
  * idx and val are unique identifiers which 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] automatic CC generation for patch submission

[Andrew Morton]

On Sat, 30 Jun 2007 13:47:52 +0300 Dan Aloni <[EMAIL PROTECTED]> wrote:

> On Sat, Jun 30, 2007 at 02:54:25AM -0700, Andrew Morton wrote:
> > On Fri, 29 Jun 2007 19:51:53 -0700 "Kok, Auke" <[EMAIL PROTECTED]> wrote:
> > 
> > > > Some extensions to the popular E-Mail clients might be needed 
> > > > here. Also, a bot reading LKML would automatically send links 
> > > > about posted patches to the other mailing lists whenever 
> > > > someone forgets to add a CC.
> > > > 
> > > > Any comments?
> > > 
> > > an easier way to implement this is to add an extra field in the 
> > > MAINTAINERS 
> > > file, something like below. All the contact info would stay the same, 
> > > closely 
> > > where applicable and it would allow you to also specify specific files as 
> > > well.
> > 
> > We already have that information in git.  Parse the git changelogs of the
> > affected files, find out who works on them.
> 
> I think it's quite complex to make a reliable inference of maintainership 
> information from git.

Clever people will work it out.

> Given a set of historical modifiers of a file, 
> would you take the most common commiter(s), or the most common 
> _recent_ commiter(s), or what? It's a bit fuzzy.

All the above?  Multiply frequency by recency, pick the top five?

Doesn't matter much: the cost of picking too many is high.

I shudder at the thought of manually maintaining anything like this.

> Moreover, it is slow in comparison and assumes the availability of 
> local .git db, which wouldn't be the case for some porition of patch 
> submitters.

a) precalculate the tables once per week

b) the whole thing wouldn't succeed if it requires software at
   patch-submitter's site.  It'd need to run at vger.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 v2 2/5] uvesafb: add connector entries

[Michal Januszewski]

Add connector idx and val constants for v86d and uvesafb.

Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
---
 include/linux/connector.h |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/connector.h b/include/linux/connector.h
index 10eb56b..14cecaf 100644
--- a/include/linux/connector.h
+++ b/include/linux/connector.h
@@ -36,9 +36,10 @@
 #define CN_VAL_CIFS 0x1
 #define CN_W1_IDX  0x3 /* w1 communication */
 #define CN_W1_VAL  0x1
+#define CN_IDX_V86D0x4
+#define CN_VAL_V86D_UVESAFB0x1
 
-
-#define CN_NETLINK_USERS   4
+#define CN_NETLINK_USERS   5
 
 /*
  * Maximum connector's message size.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 v2 1/5] uvesafb: export fb_destroy_modelist

[Michal Januszewski]

Make fb_destroy_modelist an exported symbol for use in the uvesafb driver.

Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
---
 drivers/video/modedb.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
index 3741ad7..d351eed 100644
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -938,6 +938,7 @@ void fb_destroy_modelist(struct list_head *head)
kfree(pos);
}
 }
+EXPORT_SYMBOL_GPL(fb_destroy_modelist);
 
 /**
  * fb_videomode_to_modelist: convert mode array to mode list

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

[PATCH v2 0/5] uvesafb: a general description

[Michal Januszewski]

uvesafb is a generic driver for VBE2+ compliant video cards; an enhanced
version of vesafb and a direct successor of vesafb-tng [1].

This is the second version of this patch, and it incorporates all fixes
and cleanups suggested on the lkml.  My thanks to everyone who took
their time to review the first version.

uvesafb uses a userspace helper application (v86d, [2]) to run the x86
Video BIOS code.  This makes it possible to include in uvesafb all the
standard features (refresh rate control, video mode changes etc) that
are missing from vesafb without resorting to ugly hacks such as the ones
used in [1].  The current implementation of v86d can use either LRMI or
x86emu to run the BIOS code and supports both x86 and x86_64.

[1] http://dev.gentoo.org/~spock/projects/vesafb-tng/
[2] http://dev.gentoo.org/~spock/projects/uvesafb/

Best regards.
-- 
Michal Januszewski  JID: [EMAIL PROTECTED]
Gentoo Linux Developerhttp://people.gentoo.org/spock

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

[Jeremy Fitzhardinge]

Andrew Morton wrote:

All my .configs have mouldered since I lost the ability to have .config be
a symlink to a revision-controlled file (used to carry a custom patch for
this, but it died).

I continue to believe that kbuild's lets-trash-your-symlink behaviour is
obnoxious, but I was unable to persuade anyone else of this.
  


That's pretty awful, but it hasn't really affected me much since I 
started using separate object directories for pretty much everything.


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

Re: [RFD 1/4] Pass no useless nameidata to the create, lookup, and permission IOPs

[Andreas Gruenbacher]

On Saturday 30 June 2007 11:13, Christoph Hellwig wrote:
> We need something like this, but I don't quite like the way you've done
> it.  First the name is wrong, it's not a nameidata anymore but a lookup
> intent, so it should be named that way, struct lookup_intent.

Sure, that name was pretty random ... lookup_intent has gotten the majority of 
votes so far, and I'm perfectly fine with that.

> Second the macro hackery is more than ugly,  please keep the structures
> separate. With modern gcc it might be possible to embed the lookup_intent
> into the nameidata anonymously.

http://gcc.gnu.org/onlinedocs/gcc-4.2.0/gcc/Unnamed-Fields.html

If we can add the -fms-extensions gcc option we can get rid of the macro, and 
the code becomes pretty clean (as shown below). If we cannot add this option, 
then gcc would puke on ``struct lookup_intent;'' in the definition of struct 
nameidata. The macro is the cleanest way to work around this I could come up 
with, but maybe somebody knows another trick.

--- a/include/linux/namei.h
+++ b/include/linux/namei.h
@@ -14,14 +14,10 @@ struct open_intent {
 
 enum { MAX_NESTED_LINKS = 8 };
 
-struct nameidata {
+struct lookup_intent {
struct dentry   *dentry;
struct vfsmount *mnt;
-   struct qstr last;
unsigned intflags;
-   int last_type;
-   unsigneddepth;
-   char *saved_names[MAX_NESTED_LINKS + 1];
 
/* Intent data */
union {
@@ -29,6 +25,19 @@ struct nameidata {
} intent;
 };
 
+struct nameidata {
+   struct lookup_intent;
+   struct qstr last;
+   int last_type;
+   unsigneddepth;
+   char *saved_names[MAX_NESTED_LINKS + 1];
+};

> Also please either remove the dentry from struct lookup_entry or from the
> direct argument list of the functions and methods - there is no need to pass
> this one twice.

The dentry in the lookup_intent of the create inode operation is the parent 
dentry right now, and the child dentry is passed as the separate parameter. I 
would prefer the cleaner interface in which the lookup_intent refers to the 
child dentry as well. (Getting from the child to the parent is trivial.) I 
guess this can go in an incremental patch with the next version of these 
patches.

Thanks,
Andreas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] b44: power down PHY when interface down

[Lennert Buytenhek]

On Sat, Jun 30, 2007 at 04:19:23PM +0100, Matthew Garrett wrote:

> I'd agree that there's a need for a state where we power down as much as 
> possible (even at the cost of functionality), but where possible it 
> would also be nice to offer a state where the mac is powered down and 
> the phy left up.

There are PHYs which can detect that someone's on the other end even
when powered down..
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: IRQ handling difference between i386 and x86_64

[Arjan van de Ven]

On Sat, 2007-06-30 at 16:55 +0200, Krzysztof Oledzki wrote:
> Hello,
> 
> It seems that IRQ handling is somehow different between i386 and x86_64.
> 
> In my Dell PowerEdge 1950 is it possible to enable interrupts spreading 
> over all CPUs. This a single CPU, four CORE system (Quad-Core E5335 Xeon) 
> so I think that interrupts migration may be useful. Unfortunately, it 
> works only with 32-bit kernel. Booting it with x86_64 leads to situation, 
> when all interrupts goes only to the first cpu matching a smp_affinity 
> mask.

arguably that is the most efficient behavior... round robin of
interrupts is the worst possible case in terms of performance

are you using irqbalance ? (www.irqbalance.org)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] b44: power down PHY when interface down

[Matthew Garrett]

On Sat, Jun 30, 2007 at 07:44:59AM -0700, Arjan van de Ven wrote:
> Matthew Garrett wrote:
> >Do you still get link beat detection when the phy is powered down?
> >
> does that matter?
> If the interface is down, nic drivers aren't expected to detect 
> link... if userspace wants to find link status it should have the 
> interface up.

If that's the policy, why do we leave this up to individual drivers? 
Right now most of them let you make the query regardless of interface 
state.

I'd agree that there's a need for a state where we power down as much as 
possible (even at the cost of functionality), but where possible it 
would also be nice to offer a state where the mac is powered down and 
the phy left up. If the existing semantics are confused then it would be 
nice to fix them, too.
-- 
Matthew Garrett | [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: vm/fs meetup in september?

[Al Boldi]

[EMAIL PROTECTED] wrote:
> > "Christoph" == Christoph Hellwig <[EMAIL PROTECTED]> writes:
>
> Christoph> On Tue, Jun 26, 2007 at 10:07:24AM -0700, Jared Hulbert
>
> Christoph> wrote:
> >> If you have a large array of a non-volatile semi-writeable memory
> >> such as a highspeed NOR Flash or some of the similar emerging
> >> technologies in a system.  It would be useful to use that memory as
> >> an extension of RAM.  One of the ways you could do that is allow
> >> pages to be swapped out to this memory.  Once there these pages
> >> could be read directly, but would require a COW procedure on a
> >> write access.  The reason why I think this may be a vm/fs topic is
> >> that the hardware makes writing to this memory efficiently a
> >> non-trivial operation that requires management just like a
> >> filesystem.  Also it seems to me that there are probably overlaps
> >> between this topic and the recent filemap_xip.c discussions.
>
> Christoph> So what you mean is "swap on flash" ?  Defintively sounds
> Christoph> like an interesting topic, although I'm not too sure it's
> Christoph> all that filesystem-related.

I wouldn't want to call it swap, as this carries with it block-io 
connotations.  It's really mmap on flash.

> You need either a block translation layer,

Are you suggesting to go through the block layer to reach the flash?

> or a (swap) filesystem that
> understands flash peculiarities in order to make such a thing work.
> The standard Linux swap format will not work.

Correct.

BTW, you may want to have a look at my "[RFC] VM: I have a dream..." thread.

Here is an excerpt:

"What's more, there is no more swap.
Apps are executed inplace, as if already loaded.
Physical RAM is used to cache slower storage RAM, much the same as the CPU 
cache RAM caches slower physical RAM."

The thread ended with this conclusion:

Alan Cox wrote:
> On Iau, 2006-02-02 at 21:59 +0300, Al Boldi wrote:
> > So w/ 1GB RAM, no swap, and 1TB disk mmap'd, could this mmap'd space be
> > added to the total memory available to the OS, as is done w/ swap?
>
> Yes in theory. It would be harder to manage.
>
> > And if that's possible, why not replace swap w/ mmap'd disk-space?
>
> Swap is just somewhere to stick data that isnt file backed, you could
> build a swapless mmap based OS but it wouldn't be quite the same as
> Unix/Linux are.


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: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip

[Andrey Borzenkov]

On Saturday 30 June 2007, Bjorn Helgaas wrote:
> This means that the SMCf010 device *did* respond, I think at the
> FIR address 0x100.  (I can't figure out the "right" way to print
> those resource_size_t things, so I added some casts in the appended
> patch.)
>

Those can be 64 bit if CONFIG_RESOURCE_64BIT is set; so you probably should 
cast to unsigned long long and use %llx. Or do it conditionally depending on 
above macro.

> Well, the whole problem I'm trying to fix is that we aren't doing
> resource allocation correctly.  The BIOS has configured the IR
> device to use port 0x100, and then something else came along and
> decided to also use port 0x100.
>

That I already asked - how should PCMCIA subsystem know that some device 
requires fixed io port? Or for that matter - how should PnP know that some 
resource it believes is free is actually used by PCMCIA?

> It looks like the something else is the wlags49_h1_cs driver for
> the PCMCIA card you have inserted.  Can you temporarily remove that
> card and driver and try the patch below?  If the IR device works
> without the wlags49_h1_cs driver, then we'll have to look at
> wlags49_h1_cs to see whether it's doing something wrong.
>


Yes, this works. I did not use patch below, because it works with original too 
of course. In this PCMCIA later sees that port range at 0x100 is already 
taken and selects another one:

[  693.694389] SMsC IrDA Controller found
[  693.694395]  IrCC version 2.0, firport 0x100, sirport 0x2e8 dma=1, irq=5
[  693.735620] No transceiver found. Defaulting to Fast pin select
[  693.757188] IrDA: Registered device irda0
[  840.397539] Yenta: CardBus bridge found at :00:10.0 [12a3:ab01]
[  840.419345] Yenta: Using CSCINT to route CSC interrupts to PCI
[  840.441395] Yenta: Routing CardBus interrupts to PCI
[  840.463454] Yenta TI: socket :00:10.0, mfunc 0x0102, devctl 0x60
[  840.713821] Yenta: ISA IRQ mask 0x, PCI irq 11
[  840.736937] Socket status: 3059
[  840.761016] Yenta: CardBus bridge found at :00:11.0 [1179:0001]
[  840.910480] Yenta: ISA IRQ mask 0x04b8, PCI irq 11
[  840.934571] Socket status: 3087
[  840.959527] Yenta: CardBus bridge found at :00:11.1 [1179:0001]
[  841.110433] Yenta: ISA IRQ mask 0x04b8, PCI irq 11
[  841.135628] Socket status: 3087
[  841.393023] pccard: PCMCIA card inserted into slot 0
[  970.189560] wlags49_h1_cs v7.18 for PCMCIA, 03/31/2004 14:31:00 by Agere 
Systems, http://www.agere.com
[  970.212434] *** Modified for kernel 2.6 by Andrey Borzenkov 
<[EMAIL PROTECTED]> $Revision: 39 $
[  970.235874] *** Station Mode (STA) Support: YES
[  970.259328] *** Access Point Mode (AP) Support: YES
[ 1286.581694] cs: memory probe 0x0c-0x0f: excluding 0xc-0xcbfff 
0xe-0xf
[ 1286.608294] cs: memory probe 0x6000-0x60ff: clean.
[ 1286.642101] cs: memory probe 0xa000-0xa0ff: clean.
[ 1286.676160] pcmcia: registering new device pcmcia0.0
[ 1287.186722] eth0: PRI 31 variant 2 version 9.48
[ 1287.208487] eth0: NIC 5 variant 2 version 1.02
[ 1287.234616] eth0: Wireless, io_addr 0x180, irq 11, mac_address 
00:02:2D:26:95:6C

is it interesting to look at ports:

0100-0107 : smsc-ircc2
0170-0177 : :00:04.0
  0170-0177 : libata
0180-01bf : pcmcia_socket0

notice that pcmcia_socket available resources do not change at all in this 
case and still list port range 100 - 3af.

I do not think wlags driver has anything to do with it (directly). It just 
requests resource allocation from PCMCIA core. So either we have to mark 
resources of PnP devices reserved (even if devices are not active and no 
driver is loaded) or we need some way to force PnP to allocate different 
resources on device activation. Which means PCMCIA should somehow inform PnP 
that resources it allocated are in use. 

Anyway if you want to get a look - driver is available at 
http://arvidjaar.newmail.ru/wlags49.tar.bz2. 

-andrey


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

Re: [PATCH] b44: power down PHY when interface down

[Arjan van de Ven]

Matthew Garrett wrote:

On Sat, Jun 30, 2007 at 02:47:35PM +0300, Török Edvin wrote:
When the interface is down (or driver removed), the BroadCom 44xx card 
remains

powered on, and both its MAC and PHY is using up power.
This patch makes the driver issue a MAC_CTRL_PHY_PDOWN when the interface
is halted, and does a partial chip reset turns off the activity LEDs too.


Do you still get link beat detection when the phy is powered down?


does that matter?
If the interface is down, nic drivers aren't expected to detect 
link... if userspace wants to find link status it should have the 
interface up.

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

[PATCH 2.6.22-rc6] add PCI-ID for Adaptec 1430SA 4-Port SATA Controller

[Florian Attenberger]

Hi,

added this pci id to support my:
lspci:
01:00.0 RAID bus controller: Adaptec Unknown device 0243 (rev 02)
lspci -n:
01:00.0 0104: 9005:0243 (rev 02)

seems to work fine.

florian attenberger


--- 2.6.22-rc6/drivers/ata/sata_mv.c2007-06-30 16:21:47.462020256 +0200
+++ 2.6.22-rc6.mine/drivers/ata/sata_mv.c   2007-06-30 16:25:25.999165444 
+0200
@@ -582,6 +582,9 @@ static const struct pci_device_id mv_pci
 
{ PCI_VDEVICE(ADAPTEC2, 0x0241), chip_604x },
 
+   /* Adaptec 1430SA */
+   { PCI_VDEVICE(ADAPTEC2, 0x0243), chip_7042 },
+
{ PCI_VDEVICE(TTI, 0x2310), chip_7042 },
 
/* add Marvell 7042 support */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] - x86_64-add-ioapic-nmi-support-fix-3

[Randy Dunlap]

John Keller wrote:

[adding Andi Kleen]

John Keller wrote:

Place all the IOACPI NMI support code under CONFIG_ACPI
to clear up build errors with certain configs.

Signed-off-by: John Keller <[EMAIL PROTECTED]>
---

Is there some architectural reason that IO APIC NMI support should
require ACPI?


OK, I guess standing alone this description was a bit misleading.
The code referred to here is the new code supporting the ACPI NMI SRC
structure that can be specified in the MADT. Without ACPI support this
code is not relevant. All the code touched by this patch was introduced
by eariler versions of this patchset.

This patch makes no changes to the workings of nmi_watchdog.


OK, thanks for the clarification.


John



Is this a new requirement?  It seems like a step backwards to me.


Documentation/nmi_watchdog.txt doesn't say anything about ACPI being
needed.  It does say:

"For x86-64, the needed APIC is always compiled in, and the NMI watchdog is
always enabled with I/O-APIC mode (nmi_watchdog=1). Currently, local APIC
mode (nmi_watchdog=2) does not work on x86-64.

Using local APIC (nmi_watchdog=2) needs the first performance register, so
you can't use it for other purposes (such as high precision performance
profiling.) However, at least oprofile and the perfctr driver disable the
local APIC NMI watchdog automatically."



--
~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 5/5] Optimize page_mkclean_one

[Hugh Dickins]

On Fri, 29 Jun 2007, Martin Schwidefsky wrote:
> On Fri, 2007-06-29 at 19:56 +0100, Hugh Dickins wrote:
> > I don't dare comment on your page_mkclean_one patch (5/5),
> > that dirty page business has grown too subtle for me.
> 
> Oh yes, the dirty handling is tricky. I had to fix a really nasty bug
> with it lately. As for page_mkclean_one the difference is that it
> doesn't claim a page is dirty if only the write protect bit has not been
> set. If we manage to lose dirty bits from ptes and have to rely on the
> write protect bit to take over the job, then we have a different problem
> altogether, no ?

[Moving that over from 1/5 discussion].

Expect you're right, but I _really_ don't want to comment, when I don't
understand that "|| pte_write" in the first place, and don't know the
consequence of pte_dirty && !pte_write or !pte_dirty && pte_write there.
Peter?

My suspicion is that the "|| pte_write" is precisely to cover your
s390 case where pte is never dirty (it may even have been me who got
Peter to put it in for that reason).  In which case your patch would
be fine - though I think it'd be improved a lot by a comment or
rearrangement or new macro in place of the pte_dirty || pte_write
line (perhaps adjust my pte_maybe_dirty in asm-generic/pgtable.h,
and use that - its former use in msync has gone away now).

Hugh

On Fri, 29 Jun 2007, Martin Schwidefsky wrote:

> page_mkclean_one is used to clear the dirty bit and to set the write
> protect bit of a pte. In additions it returns true if the pte either
> has been dirty or if it has been writable. As far as I can see the
> function should return true only if the pte has been dirty, or page
> writeback will needlessly write a clean page.
> 
> Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
> ---
> 
>  mm/rmap.c |3 ++-
>  1 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff -urpN linux-2.6/mm/rmap.c linux-2.6-patched/mm/rmap.c
> --- linux-2.6/mm/rmap.c   2007-06-29 09:58:33.0 +0200
> +++ linux-2.6-patched/mm/rmap.c   2007-06-29 15:44:58.0 +0200
> @@ -433,11 +433,12 @@ static int page_mkclean_one(struct page 
>  
>   flush_cache_page(vma, address, pte_pfn(*pte));
>   entry = ptep_clear_flush(vma, address, pte);
> + if (pte_dirty(entry))
> + ret = 1;
>   entry = pte_wrprotect(entry);
>   entry = pte_mkclean(entry);
>   set_pte_at(mm, address, pte, entry);
>   lazy_mmu_prot_update(entry);
> - ret = 1;
>   }
>  
>   pte_unmap_unlock(pte, ptl);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [OT] Re: Linux Kernel include files

[Måns Rullgård]

[EMAIL PROTECTED] (Joerg Schilling) writes:

> Willy Tarreau <[EMAIL PROTECTED]> wrote:
>
>> Jörg,
>>
>> On Thu, Jun 28, 2007 at 12:39:57PM +0200, Joerg Schilling wrote:
>> > David Woodhouse <[EMAIL PROTECTED]> wrote:
>> > 
>> > > On Thu, 2007-06-28 at 12:27 +0200, Joerg Schilling wrote:
>> > > > David Woodhouse <[EMAIL PROTECTED]> wrote:
>> > > > > By the way, your mailer seems to be sometimes omitting
>> > > > > In-Reply-To: and References: headers, which RFC2822 says
>> > > > > you SHOULD include in replies.
>> > > > 
>> > > > Sending such accusation without knowing the reason is not polite.
>> > >
>> > > It's not an accusation -- it's merely an observation. You may
>> > > not have noticed that your mailer was misbehaving; now you _do_
>> > > know, and if you care about RFC compliance you might want to
>> > > fix it. You're not _obliged_ to fix it, of course. I just
>> > > thought you'd like to know.
>> > 
>> > Well there you are: my mailer is definitely NOT missbehaving.
>> > Please do not repeat similar accusations when not knowing the
>> > reason.
>>
>> Attacking people who suggest to you they *may* have noticed an
>> anomaly is not polite at all, childish at best, and
>> counter-productive in any case.
>
> Well, then please write this to the person who did attack me for no
> reason!
>
> What he did is typical trollish behavior, as he tried to turn a
> technical based discussion into a flame war for no reason.

Ah, it's nice to see Jörg back to his usual self.  For a while there
the headers discussion was looking almost reasonable.

BTW Jörg, thanks for the absolutely fantastic real-life flame war you
gave us at LinuxTag (by the Google booth, remember).  I haven't had so
much fun in a long time.  Quite a few bystanders seemed rather
entertained too.

-- 
Måns Rullgård
[EMAIL PROTECTED]

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

Re: [PATCH] CIFS: make cifsd (more)

[Satyam Sharma]

[ Trimmed Cc: list ]

On 6/30/07, Steve French <[EMAIL PROTECTED]> wrote:

The reason that cifs switched from wait_for_completion to the kthread
call to cifs_demultiplex_thread in the first place is because without
use of kthread it won't work with a linux-vserver.   See the thread:

http://marc.info/?l=linux-cifs-client=117552761703381=2

If we take out the kthread call, we break those guys.

I agree that using sk_callbacks is worth looking into - I only found
ocfs2 and SunRPC (NFS) though that used it.   Is there a better
example though?   The NFS socket handling code is huge
(net/sunrpc/xprtsck.c) - something seems wrong when replacing a few
lines of code with a new 1675 line file.  There must be a better
example of doing what you suggest...


You're correct. "Right" / "elegant" solutions are rarely (if ever?) complex
and involved. Simplicity _is_ good. I see no point in converting 5 good
lines of maintainable, readable, solid code with 1000 lines of kludge :-)
just to work-around this kthreads limitation. But then, of course, the call
is yours.


I am tempted to drop the socket timeout (which cifs sets to 7 seconds)
to a smaller number and not use signals at all rather than add that
much complexity


Timeout too low => CPU wastage => power wastage. [ Think laptop
batteries, with say 5 cifsd kthreads waking up once every second ... ]
Timeout too high => umount(2) hangs, annoys user, user takes
drastic actions ... so think of some good "magic number" :-)

I don't quite think of all these suggestions as solutions at all -- they
are workarounds at best, IMHO (for kthread's limitation in dealing with
kernel threads that want to block -- I still don't see any fundamental
reasoning / logic behind why kthreads should be banned from doing
blocking recv's -- if there is, please let me know too).

Don't have much else to say than what I already have on the two
threads discussing this.

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

Re: [RFC] automatic CC generation for patch submission

[Kok, Auke]

Andrew Morton wrote:

On Fri, 29 Jun 2007 19:51:53 -0700 "Kok, Auke" <[EMAIL PROTECTED]> wrote:

Some extensions to the popular E-Mail clients might be needed 
here. Also, a bot reading LKML would automatically send links 
about posted patches to the other mailing lists whenever 
someone forgets to add a CC.


Any comments?
an easier way to implement this is to add an extra field in the MAINTAINERS 
file, something like below. All the contact info would stay the same, closely 
where applicable and it would allow you to also specify specific files as well.


We already have that information in git.  Parse the git changelogs of the
affected files, find out who works on them.

Not that it'll help much, given the amnount of stuff which gets
mysteriously ignored even when the correct people are cc'ed...

(For extra giggles we could parse emailed oops and bug reports and add the
appropriate cc's there too.  Harder.)


well, I'm more thinking of the advertisement value of having some sort of 
pointer in the MAINTAINERS file to the exact location of a certain subsystem. 
Quite often I find myself searching somewhere in /drivers/ only to find out that 
the stuff I need is in asm/arch or elsewhere. E.g. alsa is a driver but lives in 
/sound/. Having a voluntary field (usable for other purposes) in the MAINTAINERS 
field seems awfully appropriate in that place and very low impact.


git does have that info, except for the fact that quite often others touch the 
same subsystem much more than the maintainer (pci, net, etc)...


Auke
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] [PATCH] PXA27x UDC driver.

[David Brownell]

On Thursday 28 June 2007, Andrew Morton wrote:

> > +#undef DISABLE_TEST_MODE
> 
> enabling DISABLE_TEST_MODE seens to enable test mode.  Confused.

Blame it on Intel.  ISTR that early pxa2[156]x silicon had
something called "test mode".  And a boatload of errata, with
a common thread in workarounds:  using the "test mode" helped
many things work better, although it was neither necessary nor
sufficient.  If one were to #define DISABLE_TEST_MODE, software
could experiment with other workarounds ... and maybe be able
to get the documented "double buffering" feature to work.

Later silicon stopped documenting "test mode" as such, effectively
making certain workarounds become the standard way to use the chip.

Which doesn't explain why pxa270 code has pxa2[156]x devel hooks,
but explains why pxa2[156]x code wants the hardware "test mode"
to be enabled ... except during developer experiments.

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

[PATCH] - x86_64-add-ioapic-nmi-support-fix-3

[John Keller]

> 
> [adding Andi Kleen]
> 
> John Keller wrote:
> > Place all the IOACPI NMI support code under CONFIG_ACPI
> > to clear up build errors with certain configs.
> > 
> > Signed-off-by: John Keller <[EMAIL PROTECTED]>
> > ---
> 
> Is there some architectural reason that IO APIC NMI support should
> require ACPI?

OK, I guess standing alone this description was a bit misleading.
The code referred to here is the new code supporting the ACPI NMI SRC
structure that can be specified in the MADT. Without ACPI support this
code is not relevant. All the code touched by this patch was introduced
by eariler versions of this patchset.

This patch makes no changes to the workings of nmi_watchdog.

John


> 
> Is this a new requirement?  It seems like a step backwards to me.
> 
> 
> Documentation/nmi_watchdog.txt doesn't say anything about ACPI being
> needed.  It does say:
> 
> "For x86-64, the needed APIC is always compiled in, and the NMI watchdog is
> always enabled with I/O-APIC mode (nmi_watchdog=1). Currently, local APIC
> mode (nmi_watchdog=2) does not work on x86-64.
> 
> Using local APIC (nmi_watchdog=2) needs the first performance register, so
> you can't use it for other purposes (such as high precision performance
> profiling.) However, at least oprofile and the perfctr driver disable the
> local APIC NMI watchdog automatically."
> 
> 
> 
> >  arch/x86_64/kernel/io_apic.c |   77 +
> >  1 file changed, 40 insertions(+), 37 deletions(-)
> > 
> > 
> > Index: linux-2.6.22-rc6/arch/x86_64/kernel/io_apic.c
> > ===
> > --- linux-2.6.22-rc6.orig/arch/x86_64/kernel/io_apic.c  2007-06-29 
> > 08:56:46.0 -0500
> > +++ linux-2.6.22-rc6/arch/x86_64/kernel/io_apic.c   2007-06-29 
> > 10:28:08.109040333 -0500
> > @@ -76,6 +76,10 @@ struct irq_cfg irq_cfg[NR_IRQS] __read_m
> > [15] = { .domain = CPU_MASK_ALL, .vector = IRQ15_VECTOR, },
> >  };
> >  
> > +#ifdef CONFIG_ACPI
> > +static void setup_ioapic_nmi_irq(int ioapic, int pin,
> > +struct IO_APIC_route_entry *entry);
> > +#endif
> >  static int assign_irq_vector(int irq, cpumask_t mask);
> >  
> >  #define __apicdebuginit  __init
> > @@ -1168,9 +1172,6 @@ void __apicdebuginit print_PIC(void)
> >  
> >  #endif  /*  0  */
> >  
> > -static void setup_ioapic_nmi_irq(int ioapic, int pin,
> > -struct IO_APIC_route_entry *entry);
> > -
> >  static void __init enable_IO_APIC(void)
> >  {
> > union IO_APIC_reg_01 reg_01;
> > @@ -1211,8 +1212,10 @@ static void __init enable_IO_APIC(void)
> > continue;
> > }
> >  
> > +#ifdef CONFIG_ACPI
> > if (entry.delivery_mode == dest_NMI)
> > setup_ioapic_nmi_irq(apic, pin, );
> > +#endif
> > }
> > }
> >  
> > @@ -1586,40 +1589,6 @@ static void setup_nmi (void)
> > printk(" done.\n");
> >  }
> >  
> > -#define disable_nmi_ioapic  mask_IO_APIC_irq
> > -#define enable_nmi_ioapic   unmask_IO_APIC_irq
> > -
> > -static struct irq_chip nmi_ioapic_chip __read_mostly = {
> > -   .name   = "IO-APIC NMI",
> > -   .enable = enable_nmi_ioapic,
> > -   .disable= disable_nmi_ioapic,
> > -   .mask   = mask_IO_APIC_irq,
> > -   .unmask = unmask_IO_APIC_irq,
> > -};
> > -
> > -void __init setup_ioapic_nmi_irq(int apic, int pin,
> > -struct IO_APIC_route_entry *entry)
> > -{
> > -   int irq;
> > -
> > -   entry->dest_mode = INT_DEST_MODE;
> > -   entry->dest = cpu_mask_to_apicid(TARGET_CPUS);
> > -   ioapic_write_entry(apic, pin, *entry);
> > -
> > -   irq = mp_apic_pin_to_gsi(apic, pin);
> > -
> > -   /* Setup pin_2_irq[irq] entry */
> > -   add_pin_to_irq(irq, apic, pin);
> > -
> > -   irq_desc[irq].status = IRQ_NOREQUEST | IRQ_NO_BALANCING;
> > -   if (!entry->mask) {
> > -   irq_desc[irq].status &= ~IRQ_DISABLED;
> > -   irq_desc[irq].depth = 0;
> > -   }
> > -
> > -   set_irq_chip(irq, _ioapic_chip);
> > -}
> > -
> >  /*
> >   * This looks a bit hackish but it's about the only one way of sending
> >   * a few INTA cycles to 8259As and any associated glue logic.  ICR does
> > @@ -2282,6 +2251,40 @@ void __init io_apic_set_nmi_src_irq(int 
> > ioapic_write_entry(ioapic, pin, entry);
> >  }
> >  
> > +#define disable_nmi_ioapic  mask_IO_APIC_irq
> > +#define enable_nmi_ioapic   unmask_IO_APIC_irq
> > +
> > +static struct irq_chip nmi_ioapic_chip __read_mostly = {
> > +   .name   = "IO-APIC NMI",
> > +   .enable = enable_nmi_ioapic,
> > +   .disable= disable_nmi_ioapic,
> > +   .mask   = mask_IO_APIC_irq,
> > +   .unmask = unmask_IO_APIC_irq,
> > +};
> > +
> > +void __init setup_ioapic_nmi_irq(int apic, int pin,
> > +struct IO_APIC_route_entry *entry)
> > +{
> > +   int irq;
> > +
> > +   

Re: [linux-usb-devel] [PATCH] PXA27x UDC driver.

[David Brownell]

On Friday 29 June 2007, Dmitry Krivoschekov wrote:
> David Brownell wrote:
> > On Thursday 28 June 2007, Rodolfo Giometti wrote:
> >
> >> As suggest by Leo let me propose to you my new patch for PXA27x UDC
> >> support.
> >>
> >> Please, let me know what I have to do for kernel inclusion. :)
> >
> > Let's start with *JUST* a driver, not trying to update everything
> > else in the USB Gadget stack so that it looks like it's designed
> > specifically to handle all of Intel's design botches related to
> > endpoint config ... and work worse for essentially everything else.
> >
> > (Unlike pretty much every other vendor, Intel wanted hardware config
> > management. It was unusably buggy in pxa21x/25x/26x, and not much
> > better in pxa27x.)
> >
> >
> > So in technical terms, and to repeat what I've said before: just
> > configure it to act more like a PXA 25x chip (no altsettings) and
> > get it so it passes all the tests [1], modulo errata which have no
> > workarounds
> 
> Other options are:
> 
> 1. pre-program endpoints so the setting covers all gadget
>configurations, it seems it's feasible. The only appreciable
>change is, CDC Ethernet config number should be 3 instead of 1.
>It should not break anything.

ISTR looking at this in some detail a few years back, and
concluding that it wouldn't quite work.  That was before
started to hear back from people that the pxa27x hardware
didn't really match its documentation, too ...


> 2. Implement a FAKE call of GET_CONFIGURATION command so upon
>gadget binding you can issue the command and program endpoints
>according to the received gadget configuration.

That would involve *multiple* such fake calls.  Not the most
elegant of solutions, but ISTR using it in some other context.

But again, that presumes sane hardware, or at least hardware
that matches the docs.  And people who've looked at this in
more pain than I have are consistent in telling me that pxa27x
endpoint configuration has problems that the docs and errata
do not describe.  (If it were just one person, rather than four
different developers, I'd be somewhat skeptical.)  Hence my
eventual conclusion (and advice) to just stop trying to use
that misfeature.

 
> Also, considering that PXA3XX processors include PXA27x-compatible
> USB device controller it makes sense to develop a driver that
> will support both processor families. Hopefully PXA3XX arch
> support will be merged some day (the arch support has been already
> submitted here, but I don't know about its current status).

Has someone actually signed up to develop and maintain such a
controller driver?  If so, that would be a Fine Thing, but not
one I've heard rumored before.  I've assumed that the best we'd
have is someone (Rodolfo?!) finally cleaning up a pxa27x version
so it could be merged.

- Dave


> 
> 
> Regards,
> Dmitry
> 
> > ... then submit that. No epautoconfig updates, no
> > patches to every gadget driver to cope with updated autoconfig.
> >
> > Once there's a basic working no-frills version merged, then we can
> > talk about whether things in the rest of the stack should change
> > to accomodate the bizarre concepts of this controller.
> >
> > - Dave
> >
> >
> > [1] http://www.linux-usb.org/usbtest/
> >
> 


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

[David Brownell]

On Friday 29 June 2007, Rodolfo Giometti wrote:
> On Thu, Jun 28, 2007 at 02:53:22PM -0700, David Brownell wrote:
> > 
> > Let's start with *JUST* a driver, not trying to update everything
> > else in the USB Gadget stack so that it looks like it's designed
> > specifically to handle all of Intel's design botches related to
> > endpoint config ... and work worse for essentially everything else.
> > 
> > (Unlike pretty much every other vendor, Intel wanted hardware config
> > management.  It was unusably buggy in pxa21x/25x/26x, and not much
> > better in pxa27x.)
> > 
> > 
> > So in technical terms, and to repeat what I've said before:  just
> > configure it to act more like a PXA 25x chip (no altsettings) and
> > get it so it passes all the tests [1], modulo errata which have no
> > workarounds ... then submit that.  No epautoconfig updates, no
> > patches to every gadget driver to cope with updated autoconfig.
> 
> This looks interesting... as you alredy told this driver derives from
> an older one, I just maintained it till now.
> 
> If I well understand I should remove usb_ep_autoconfig() and program
> into the controller only one (the default) configuration. Is that
> right?

Other than the fact that "configuration" means something very specific
in USB terms, so there would be three of them ... yes.  That's what the
PXA2[156]x UDC hardware does.


> Currently I tested the driver only with ether gadget, but if I do as
> above, should I get the driver working with all gadgets automagically?
> :)

There's not much point in merging a driver that only works with one
of what are currently six gadget drivers ... others are on the way.

Yes, the point of working more like PXA2[156]x hardware is that we
know that kind of hardware setup works with everything ... while we
know that every attempt to use the PXA27x magic has failed on some
of those drivers.  (By all reports, because of hardware bugs.)

- Dave


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

Re: sh section mismatches [was Re: 2.6.22-rc6 on Dreamcast (SH4)]

[Adrian McMenamin]

On Sat, 2007-06-30 at 19:50 +0530, Satyam Sharma wrote:
> Hi,

> Right, as Mike just said, these warnings are the ones from
> drivers/video/pvr2fb.c which the patch didn't touch ... that was only
> to get rid of the "(between 'mv_dreamcast' and 'systemasic_int')"
> warning. But of course, we can't be too sure about the patch till
> you can boot and run the system ...


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

Personal attacks (was Re: Linux Kernel include files)

[Joerg Schilling]

Willy Tarreau <[EMAIL PROTECTED]> wrote:

>
> > Jörg
> [advertisements removed]

Please stop this kind of trolling, you did not remove anything here,
so do not claim to remove things


As you don't seem to know the nettiquette:

If you believe you have some kind of problems that was used by the
OP to send a personal attack, the natural reaction is to send a
personal mail that does _not_ include a list of persons or a mailing
list.


As it does not seem to make sens to continue here, I will not reply to any 
further mail that tries to discuss something from the "mail threading"
attack.

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: sh section mismatches [was Re: 2.6.22-rc6 on Dreamcast (SH4)]

[Satyam Sharma]

Hi,

On 6/30/07, Adrian McMenamin <[EMAIL PROTECTED]> wrote:

[...]
WARNING: drivers/built-in.o(.text+0x168e0): Section mismatch: reference
to .init.data: (between 'pvr2fb_check_var' and 'pvr2fb_interrupt')
WARNING: drivers/built-in.o(.text+0x1701c): Section mismatch: reference
to .init.data: (between 'pvr2fb_pci_probe' and 'read_mem')
WARNING: drivers/built-in.o(.text+0x17024): Section mismatch: reference
to .init.text: (between 'pvr2fb_pci_probe' and 'read_mem')
WARNING: drivers/built-in.o(.data+0x738): Section mismatch: reference
to .init.text: (between 'board_list' and 'pvr2fb_pci_driver')
WARNING: drivers/built-in.o(.data+0x750): Section mismatch: reference
to .init.text: (between 'board_list' and 'pvr2fb_pci_driver')


Right, as Mike just said, these warnings are the ones from
drivers/video/pvr2fb.c which the patch didn't touch ... that was only
to get rid of the "(between 'mv_dreamcast' and 'systemasic_int')"
warning. But of course, we can't be too sure about the patch till
you can boot and run the system ...

Meanwhile I'll look into Sam's suggestion and try to fix the pvr2fb
warnings too.

Satyam

[ BTW I really wish someone from linux-sh would address that
.machvec.init vs .init.machvec section thing in the earlier mail. ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/