Hi Greg,
On Tue, Aug 07, 2007 at 04:20:54PM +1000, Greg Ungerer wrote:
> Currently if I submit a patch that was sent to me with a
> Signed-off-by line I just add mine underneath it and send.
> If the patch didn't come with a Signed-off-by then I put the
> original author in a "From" line at the
Pierre Ossman wrote:
> On Tue, 07 Aug 2007 13:55:59 +0100
> David Vrabel <[EMAIL PROTECTED]> wrote:
>
>> sdio: disable CD resistor
>>
>> Disable the card detect resistor to ensure all data lines are equally
>> loaded. Not doing this can have a negative impact on buses with
>> marginal signal
Alan Cox wrote:
I fully agree, and firmly believe that the current stabilisation works
incredibly well for shaking out bugs. My problem is that it doesn't
work for stabilising features. Either we have to get far more people
doing feature integration testing before the merge window, or we have
Hi Steve.
On Tue, Aug 07, 2007 at 09:37:41AM -0500, Steve Wise ([EMAIL PROTECTED]) wrote:
> +static int cma_get_tcp_port(struct rdma_id_private *id_priv)
> +{
> + int ret;
> + struct socket *sock;
> +
> + ret = sock_create_kern(AF_INET, SOCK_STREAM, IPPROTO_TCP, );
> + if (ret)
>
On 08/07/2007 05:55 AM, James Bottomley wrote:
I really, *really* think we need a pre-release tree that consists of all
the upstream targetted features (i.e. all of the for the next merge
window git trees) and nothing else. -mm doesn't really satisfy this,
because it has so much other stuff
> I fully agree, and firmly believe that the current stabilisation works
> incredibly well for shaking out bugs. My problem is that it doesn't
> work for stabilising features. Either we have to get far more people
> doing feature integration testing before the merge window, or we have to
>
On Tue, 2007-08-07 at 15:41 +0900, Tejun Heo wrote:
> Robert Hancock wrote:
> > Tejun Heo wrote:
> >> Michael Sedkowski wrote:
> Hmmm... If the problem only shows up on nx6325, it might be that
> ACPI is
> pulling unnecessary stunt. Please apply the attached patch and report
>
Vincent Legoll wrote:
> Hello,
Hi,
>
> I tried to get 2.4.35 to compile on a file server I manage, and got that:
>
> gcc -D__KERNEL__ -I/usr/src/linux-2.4/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing
> -fno-common -fno-builtin-sprintf -fomit-frame-pointer
>
Robert Hancock wrote:
> Tejun Heo wrote:
>> Yeah, that seems to be what's going on. I don't think we have any other
>> choice than blacklisting those notebooks. This is a mess. How does the
>> other OS cope with this?
>
> Quite possible that it gets a double spindown with these laptop/drive
>
On Tue, 07 Aug 2007 16:08:25 +0200,
Kay Sievers <[EMAIL PROTECTED]> wrote:
> Nope, you would just fulfill in a completely generic way all outstanding
> requests when you are ready. All requests are all nicely grouped and
> visible in sysfs. There would be no need of coding your own device
>
Networking experts,
I'd like input on the patch below, and help in solving this bug
properly. iWARP devices that support both native stack TCP and iWARP
(aka RDMA over TCP/IP/Ethernet) connections on the same interface need
the fix below or some similar fix to the RDMA connection manager.
On Tue, 7 Aug 2007, David Engraf wrote:
> You said your Intel board has also problems with the handoff.
> Could you try the follwing patch, because the EHCI documentation
> says that the OS must set the EHCI_USBLEGSUP_OS bit and then
> wait until EHCI_USBLEGSUP_BIOS is cleared. The kernel never
>
On Mon, 2007-08-06 at 21:01 -0700, Linus Torvalds wrote:
>
> On Mon, 6 Aug 2007, James Bottomley wrote:
> >
> > Confused ... you did get the first pull request in the first week.
>
> Here's the problem. Let me repeat it again:
>
> > > And after -rc1, I don't want to see crap like this:
> > >
>
On Mon, Aug 06, 2007 at 05:08:05PM +0200, Martin Wilck wrote:
> PATCH/RFC: [kdump] fix APIC shutdown sequence
>
> This patch fixes a problem that we have encountered
> with kdump under high I/O load on some machines.
> The machines showing the errors have an Intel ICH7
> chip set with a 6702PXH
On Tue, Aug 07, 2007 at 03:24:17PM +0200, Vincent Legoll wrote:
> Hello,
>
> I tried to get 2.4.35 to compile on a file server I manage, and got that:
>
> gcc -D__KERNEL__ -I/usr/src/linux-2.4/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing
> -fno-common
Tejun Heo wrote:
Robert Hancock wrote:
Tejun Heo wrote:
Michael Sedkowski wrote:
Hmmm... If the problem only shows up on nx6325, it might be that
ACPI is
pulling unnecessary stunt. Please apply the attached patch and report
when the disk spins down and up.
Disk spins down on "Pre-shutdown
On Tue, 07 Aug 2007, Pavel Machek wrote:
> Perhaps this is needed?
> Pavel
>
> diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c
> index a664f2b..654a124 100644
> --- a/drivers/acpi/ibm_acpi.c
> +++
On Tue, 2007-08-07 at 00:14 -0700, Andrew Morton wrote:
> On Mon, 06 Aug 2007 22:55:41 -0500 James Bottomley <[EMAIL PROTECTED]> wrote:
>
> > The real root cause of all of this is that there's no tree I can
> > persuade all the interested parties to test that includes all of these
> > features.
On Tue, 07 Aug 2007 15:59:38 +0200,
Javier Pello <[EMAIL PROTECTED]> wrote:
> On Tue, 07 Aug 2007, Kay Sievers wrote:
>
> > If you don't have modules and the initial request fails, how do you
> > load the firmware later?
>
> I trigger a rebinding of the device to the driver in an init file:
> #
Bernd Schmidt <[EMAIL PROTECTED]> wrote:
> There is a leak:
Yes. I found the major leak this morning. There may be a minor leak, but I'm
not convinced it's in the mmap stuff. See revised patch.
The leak was due to the fact that I wasn't setting the usage count on the 2nd+
pages when I made a
FUJITA Tomonori wrote:
On Tue, 7 Aug 2007 00:14:29 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
On Mon, 06 Aug 2007 22:55:41 -0500 James Bottomley <[EMAIL PROTECTED]> wrote:
The real root cause of all of this is that there's no tree I can
persuade all the interested parties to test that
Bernd Schmidt <[EMAIL PROTECTED]> wrote:
> This probably wants to be dependent on something like MAP_TRIM_EXCESS.
Hmmm... In the interests of not adding more flags, I wonder if mremap()
should be used for that, with a global setting for mmaps made by binfmts as
they can't really be shrunk
On Tue, 7 Aug 2007, Serge E. Hallyn wrote:
> Shall I resend without the LSM_NEED_LOCK, or do you still want a more
> fundamental change?
Removing the needlock is enough, the rest was just a query/suggestion.
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line
Quoting Stephen Smalley ([EMAIL PROTECTED]):
> On Mon, 2007-08-06 at 13:52 -0500, Serge E. Hallyn wrote:
> > >From 1376764cbb54243f088cf00c39000c4f4418f461 Mon Sep 17 00:00:00 2001
> > From: Serge E. Hallyn <[EMAIL PROTECTED]>
> > Date: Mon, 6 Aug 2007 14:20:06 -0400
> > Subject: [PATCH 1/1] file
> What cases did you have in mind?
Mainly mapping memory which is rather tricky.
> From current Intel 64 and IA-32 Architectures Software Developer's Manual
> Volume 3A: System Programming Guide, section 10.5.2:
If you look at the detailed table it's not that simple.
> > Then there are old CPU
Quoting James Morris ([EMAIL PROTECTED]):
> On Mon, 6 Aug 2007, Serge E. Hallyn wrote:
>
> > + err = security_inode_killpriv(out->f_path.dentry, LSM_NEED_LOCK);
> > + if (err)
> > + return err;
> > +
> > err = should_remove_suid(out->f_path.dentry);
> > if (unlikely(err)) {
On Tue, 2007-08-07 at 15:59 +0200, Javier Pello wrote:
> On Tue, 07 Aug 2007, Kay Sievers wrote:
>
> > If you don't have modules and the initial request fails, how do you
> > load the firmware later?
>
> I trigger a rebinding of the device to the driver in an init file:
> # echo -n [device]
Thomas Renninger wrote:
>>> I'd also suggest adding a FAIL to the Linux firmware toolkit to any DSDT
>>> doing this. Who should we prod to add that check?
>> Dunno how the firmware toolkit works but this one can be pretty
>> difficult to test (if it were easy, we could test it in libata) as it
>>
On Mon, 2007-08-06 at 13:52 -0500, Serge E. Hallyn wrote:
> >From 1376764cbb54243f088cf00c39000c4f4418f461 Mon Sep 17 00:00:00 2001
> From: Serge E. Hallyn <[EMAIL PROTECTED]>
> Date: Mon, 6 Aug 2007 14:20:06 -0400
> Subject: [PATCH 1/1] file capabilities: clear fcaps on inode change (v2)
>
>
On Tue, 07 Aug 2007, Kay Sievers wrote:
> If you don't have modules and the initial request fails, how do you
> load the firmware later?
I trigger a rebinding of the device to the driver in an init file:
# echo -n [device] >/sys/.../bind
> The real fix would be to change the driver not to block
On Tue, 7 Aug 2007 00:14:29 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Mon, 06 Aug 2007 22:55:41 -0500 James Bottomley <[EMAIL PROTECTED]> wrote:
>
> > The real root cause of all of this is that there's no tree I can
> > persuade all the interested parties to test that includes all of
Hi,
On Mon, 6 Aug 2007, Mike Frysinger wrote:
> On 8/6/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> > Olaf Hering wrote:
> > >
> > > Remove the __STRICT_ANSI__ check from the __u64/__s64 declaration on
> > > 32bit targets.
> > >
> > > Here is the reason why we think the check should be
On Mon, 6 Aug 2007, Serge E. Hallyn wrote:
> + err = security_inode_killpriv(out->f_path.dentry, LSM_NEED_LOCK);
> + if (err)
> + return err;
> +
> err = should_remove_suid(out->f_path.dentry);
> if (unlikely(err)) {
> mutex_lock(>i_mutex);
It seems
On Tue, 2007-08-07 at 22:32 +0900, Tejun Heo wrote:
> Henrique de Moraes Holschuh wrote:
> > On Tue, 07 Aug 2007, Tejun Heo wrote:
> >> Henrique de Moraes Holschuh wrote:
> approximately translates into "if you have too many boatmen on a ship,
> it goes to mountain". We also have a
> At Tue, 7 Aug 2007 18:52:49 +0800,
> Eugene Teo wrote:
[...]
> I fixed these and applied your patch to ALSA tree now.
> Thanks!
Thanks! Will take note next time.
Eugene
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
On Tue, 07 Aug 2007 13:55:59 +0100
David Vrabel <[EMAIL PROTECTED]> wrote:
> sdio: disable CD resistor
>
> Disable the card detect resistor to ensure all data lines are equally
> loaded. Not doing this can have a negative impact on buses with
> marginal signal quality.
>
> Signed-off-by: David
On Tue, 07 Aug 2007 13:55:12 +0100
David Vrabel <[EMAIL PROTECTED]> wrote:
> sdio: extend sdio_readsb() and friends to handle any length of buffer
>
> Extend sdio_readsb(), sdio_writesb(), sdio_memcpy_fromio(), and
> sdio_memcpy_toio() to handle any length of buffer by splitting the
> transfer
David Howells wrote:
> Here's a preview of my patch to give each process a separate list of VMAs
> under NOMMU mode, just as under MMU mode. Could you have a look over it
> please?
I've managed to apply it to our Blackfin tree and started looking at it.
> Could you also see if you get a memory
On Tuesday, 7 August 2007 06:30, Joonwoo Park wrote:
> 2007/8/7, Rafael J. Wysocki <[EMAIL PROTECTED]>:
> > On Monday, 6 August 2007 17:50, Joonwoo Park wrote:
> > > 2007/8/6, Rafael J. Wysocki <[EMAIL PROTECTED]>:
> > > > On Monday, 6 August 2007 15:42, Joonwoo Park wrote:
> > > > > Hi.
> > > > >
On Tue, 07 Aug 2007 13:54:32 +0100
David Vrabel <[EMAIL PROTECTED]> wrote:
>
> Index: mmc/drivers/mmc/core/sdio.c
> ===
> --- mmc.orig/drivers/mmc/core/sdio.c 2007-08-07
> 00:38:33.0 +0100 +++ mmc/drivers/mmc/core/sdio.c
>
David Howells wrote:
> + /* we allocated a power-of-2 sized page set, so we need to trim off the
> + * excess */
> + total = 1 << order;
> + atomic_add(total, _pages_allocated);
> +
> + point = len >> PAGE_SHIFT;
> + while (point < total) {
> + order =
Thomas Renninger wrote:
Any chances of changing things
so that we inspect/snoop all tasks sent to the device, and filter them
out, or react to them accordingly?
>>> No, we can't unless we snoop ACPI method execution and detect accesses
>>> to IO ports or iomem regions. It's not
On Tue, 07 Aug 2007 13:51:39 +0100
David Vrabel <[EMAIL PROTECTED]> wrote:
>
> In conclusion, the optimum block size is based solely on the card and
> host capabilities and should be limited to at most 512. Hence the
> block size can (and should) only be set once during card
> initialization.
>
On Tue, Aug 07 2007, Alan D. Brunelle wrote:
>
>
> This patch provides more information concerning REMAP operations on block
> IOs. The additional information provides clearer details at the user level,
> and supports post-processing analysis in btt.
>
> o Adds in partition remaps on the same
Henrique de Moraes Holschuh wrote:
> On Tue, 07 Aug 2007, Tejun Heo wrote:
>> Henrique de Moraes Holschuh wrote:
approximately translates into "if you have too many boatmen on a ship,
it goes to mountain". We also have a bunch of Toshiba laptops which
>>> Yeah, that's a problem. But we
At Tue, 7 Aug 2007 18:52:49 +0800,
Eugene Teo wrote:
>
> diff --git a/sound/core/seq/oss/seq_oss_init.c
> b/sound/core/seq/oss/seq_oss_init.c
> index ca5a2ed..f26b751 100644
> --- a/sound/core/seq/oss/seq_oss_init.c
> +++ b/sound/core/seq/oss/seq_oss_init.c
> @@ -176,29 +176,31 @@
This patch provides more information concerning REMAP operations on block
IOs. The additional information provides clearer details at the user level,
and supports post-processing analysis in btt.
o Adds in partition remaps on the same device.
o Fixed up the remap information in DM to be in
Hello,
I tried to get 2.4.35 to compile on a file server I manage, and got that:
gcc -D__KERNEL__ -I/usr/src/linux-2.4/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing
-fno-common -fno-builtin-sprintf -fomit-frame-pointer
-Wno-pointer-sign -pipe
David Howells <[EMAIL PROTECTED]> wrote:
> Yes. I found the major leak this morning. There may be a minor leak, but I'm
> not convinced it's in the mmap stuff. See revised patch.
Oops. That was the old patch. Try this one instead.
David
[PATCH] NOMMU: Make VMAs per MM as for MMU-mode
Am Dienstag, 7. August 2007 02:21 schrieb Henrique de Moraes Holschuh:
> On Mon, 06 Aug 2007, Toralf Förster wrote:
> > Because I
> > (1) use the latest BIOS and
> > (2) I'm able to wake up a suspended system via under Windows XP (yes,
> > dual
> > boot system I need it at work) regardless
On 08/07/2007 08:05 AM, Arjan van de Ven wrote:
[ stuck keys ]
the last time I saw something like this it was a BIOS that kept doing
USB->PS/2 emulation even when the kernel was running.. that caused great
havoc somehow...
those who are seeing this... is it all on a USB keyboard? If so, is
On Tue, 07 Aug 2007, Tejun Heo wrote:
> Henrique de Moraes Holschuh wrote:
> >> approximately translates into "if you have too many boatmen on a ship,
> >> it goes to mountain". We also have a bunch of Toshiba laptops which
> >
> > Yeah, that's a problem. But we can avoid it if we start
On Tuesday 07 August 2007 03:37:08 Alan Cox wrote:
> > > acpi_pm_read is capable of disappearing into SMM traps which will make
> > > it look very slow.
> >
> > what is an SMM trap? I googled a bit but didn't get it...
>
> One of the less documented bits of the PC architecture. It is possible to
Hi Kyle,
Ah-hah, you nailed it right on the head. I unknowingly had Bonjour
running (must be installed by default on Fedora Core 3), which started a
process 'mDNSResponder'. I'm guessing that's the bugger that's fire off
these multicast joins.
Thanks for the tip!
-Adam
On Tue, 7 Aug 2007
On Tue, 07 Aug 2007 14:57:52 +0200,
Kay Sievers <[EMAIL PROTECTED]> wrote:
> The real fix would be to change the driver not to block in the firmware
> request and use async version of firmware loading.
I guess some drivers want to fail the probe if they can't get the
firmware. This sounds like
In defense of my maintainer, who was working on my behalf! ...
The lpfc mods were the bulk of the +/- counts. We batch our bug fixes
together and then push to James as a large lump. Unfortunately, we had
a change that changed logging from a base object to a subobject. Although
not risky, it did
Hi,
While running a cpu-hotplug test involving a high priority
process (SCHED_RR, prio=94) trying to periodically offline and
online cpu1 on a 2-processor machine, I noticed that the system was
becoming unresponsive after a few iterations.
However, when the same test was repeated with
Hello, Henrique.
Henrique de Moraes Holschuh wrote:
>> approximately translates into "if you have too many boatmen on a ship,
>> it goes to mountain". We also have a bunch of Toshiba laptops which
>
> Yeah, that's a problem. But we can avoid it if we start snooping what ACPI
> is asking us to
On Tue, 2007-08-07 at 09:51 -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 07 Aug 2007, Tejun Heo wrote:
> > Henrique de Moraes Holschuh wrote:
> > > On Tue, 07 Aug 2007, Tejun Heo wrote:
> > >> Michael Sedkowski wrote:
---snip---
> > > Any chances of changing things
> > > so that we
* Trond Myklebust ([EMAIL PROTECTED]) wrote:
> On Mon, 2007-08-06 at 11:01 -0700, Andrew Morton wrote:
> > On Mon, 6 Aug 2007 11:08:13 +0100 "Dr. David Alan Gilbert" <[EMAIL
> > PROTECTED]> wrote:
> >
> > > The oops below is from one of a pair of machines that run compiles;
> > > they're not
--
David Vrabel, Software Engineer, Drivers group Tel: +44 (0)1223 692562
CSR plc, Churchill House, Cambridge Business Park, Cowley Road, CB4 0WZ
.
sdio: disable CD resistor
Disable the card detect resistor to ensure all data lines are equally loaded.
Not doing this can have a negative impact
On Tue, 07 Aug 2007, Tejun Heo wrote:
> emergency unload. Emergency unload does shorten the lifespan of the
> disk but you don't have to worry too much about it. Disks are designed
> to withstand certain number of emergency unloads.
You *do* have to worry about it in any box you turn off daily.
--
David Vrabel, Software Engineer, Drivers group Tel: +44 (0)1223 692562
CSR plc, Churchill House, Cambridge Business Park, Cowley Road, CB4 0WZ
.
sdio: extend sdio_readsb() and friends to handle any length of buffer
Extend sdio_readsb(), sdio_writesb(), sdio_memcpy_fromio(), and
--
David Vrabel, Software Engineer, Drivers group Tel: +44 (0)1223 692562
CSR plc, Churchill House, Cambridge Business Park, Cowley Road, CB4 0WZ
.
sdio: set the functions' block size
During function initialization, set the functions' block size to the
largest that's supported by both the
--
David Vrabel, Software Engineer, Drivers group Tel: +44 (0)1223 692562
CSR plc, Churchill House, Cambridge Business Park, Cowley Road, CB4 0WZ
.
sdio: parameterize SDIO FBR register defines
Signed-off-by: David Vrabel <[EMAIL PROTECTED]>
---
Index: mmc/drivers/mmc/core/sdio.c
On Tue, 2007-08-07 at 14:47 +0200, Javier Pello wrote:
> On Tue, 07 Aug 2007, Cornelia Huck wrote:
>
> > On Tue, 7 Aug 2007 13:46:55 +0200,
> > "Kay Sievers" <[EMAIL PROTECTED]> wrote:
> > > How do you check if events have been "handled"? None of the recent
> > > distros uses /sbin/hotplug
On Tue, Aug 07, 2007 at 02:13:39PM +0200, Jarek Poplawski wrote:
> On Tue, Aug 07, 2007 at 11:52:46AM +0200, Jarek Poplawski wrote:
> > On Tue, Aug 07, 2007 at 11:37:01AM +0200, Marcin Ślusarz wrote:
...
> > > No, i don't need a break. I'll have more time in next weeks.
> >
> > Great! So, I'll
Pierre Ossman wrote:
> This is essentially what I mean.
It does not behave very well, see the specific comments at the end.
When considering optimizing SDIO it is important to always keep in mind
that a command is very expensive. They're some 100-150 clocks long and
there's also overheads in
On Tue, 07 Aug 2007, Tejun Heo wrote:
> Henrique de Moraes Holschuh wrote:
> > On Tue, 07 Aug 2007, Tejun Heo wrote:
> >> Michael Sedkowski wrote:
> Hmmm... If the problem only shows up on nx6325, it might be that ACPI is
> pulling unnecessary stunt. Please apply the attached patch and
On Tue, 7 Aug 2007 14:31:34 +0200,
"Kay Sievers" <[EMAIL PROTECTED]> wrote:
> > > How do you check if events have been "handled"? None of the recent
> > > distros uses /sbin/hotplug anymore. Netlink events are broadcasted,
> > > but no failure in delivery doesn't mean anything like "handled", or
On Tue, 07 Aug 2007, Cornelia Huck wrote:
> On Tue, 7 Aug 2007 13:46:55 +0200,
> "Kay Sievers" <[EMAIL PROTECTED]> wrote:
> > How do you check if events have been "handled"? None of the recent
> > distros uses /sbin/hotplug anymore. Netlink events are broadcasted,
> > but no failure in delivery
Francois Romieu wrote:
> Bram <[EMAIL PROTECTED]> :
> [...]
> > The device now works! But, it still comes up as eth2 instead of eth0,
> > even though it's first detected as eth0. There are no other network
>
> Check the udev rules and/or your init scripts ?
>
You're right, it's a udev script
Hi!
I get this nastyness in syslog if I compile ibm_acpi into kernel, then
boot with acpi=off.
floppy0: no floppy controllers found
loop: module loaded
WARNING: at lib/kref.c:33 kref_get()
[] kref_get+0x40/0x50
[] kobject_get+0xf/0x20
[] get_driver+0xe/0x20
[] driver_remove_file+0x13/0x40
Hi,
On Mon, 6 Aug 2007, Arjan van de Ven wrote:
> So, let me ask a direct question: What do you think is specifically
> wrong about changing the msleep() implementation as is done here? The
> behavior is clearly an improvement, so what is your objection on the
> flipside?
Again, we have two
Hi!
> I get this nastyness in syslog if I compile ibm_acpi into kernel, then
> boot with acpi=off.
> Perhaps this is needed?
Indeed the patch fixes it. Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
>
> diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c
> index a664f2b..654a124
On 7 Aug, 09:40, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 06, 2007 at 10:03:15PM -0400, Cédric Augonnet wrote:
> > Hi all,
>
> > For quite a while now, there as been numerous attempt to introduce support
> > for
> > Page Attribute Table (PAT) in the Linux kernel, whereas most other OS
On 8/7/07, Cornelia Huck <[EMAIL PROTECTED]> wrote:
> On Tue, 7 Aug 2007 13:46:55 +0200,
> "Kay Sievers" <[EMAIL PROTECTED]> wrote:
>
> > > - Use an extra parameter in which successful delivery can be indicated.
> > > Make this
> > > int kobject_uevent_env_check(struct kobject *kobject,
> > >
Andy Whitcroft wrote:
> Michal Piotrowski wrote:
>> Hi Andy,
>>
>> On 06/08/07, Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>>> Between 2.6.23-rc1-git1 and 2.6.23-rc1-git2 we started getting the
>>> following fatal error during modpost on an x86_64 machine:
>>>
>>> FATAL: drivers/acpi/video:
On Tue, Aug 07, 2007 at 11:52:46AM +0200, Jarek Poplawski wrote:
> On Tue, Aug 07, 2007 at 11:37:01AM +0200, Marcin Ślusarz wrote:
> > 2007/8/7, Jarek Poplawski <[EMAIL PROTECTED]>:
> > > On Tue, Aug 07, 2007 at 09:46:36AM +0200, Marcin Ślusarz wrote:
> > > > Network card still locks up (tested on
Tejun Heo wrote:
> Michael Sedkowski wrote:
> > Dnia 07-08-2007, Wt o godzinie 15:56 +0900, Tejun Heo napisał(a):
> >> 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age
> >> Always - 388
[snip]
> On power off, the r/w heads in a disk should be unloaded (parked). This
>
Am Monday 06 August 2007 18:24 schrieb Trond Myklebust:
> On Mon, 2007-08-06 at 13:05 +0200, Marc Dietrich wrote:
> > Hi,
> >
> > > (...)
> >
> > just booting into X is enough.
> >
> > I applied the patch, but now I get:
> >
> > =
> > [ INFO: inconsistent lock state
On Tue, 7 Aug 2007 13:46:55 +0200,
"Kay Sievers" <[EMAIL PROTECTED]> wrote:
> > - Use an extra parameter in which successful delivery can be indicated.
> > Make this
> > int kobject_uevent_env_check(struct kobject *kobject,
> > enum kobject_action action,
> >
On Sun, Aug 05 2007, Daniel Phillips wrote:
> A simple way to solve the stable accounting field issue is to add a new
> pointer to struct bio that is owned by the top level submitter
> (normally generic_make_request but not always) and is not affected by
> any recursive resubmission. Then
> On the other hand, the filesystem writers here are declaring their own
> setattr operation. Is it unreasonable for them to take responsibility
> for handling this too?
We have about half of all the in-tree filesystems declaring
->setattr(), and out of those only two that we know would use
On 8/7/07, Cornelia Huck <[EMAIL PROTECTED]> wrote:
> On Mon, 06 Aug 2007 22:23:07 +0200,
> Javier Pello <[EMAIL PROTECTED]> wrote:
>
> > > > 2. The second part changes _request_firmware in
> > > > drivers/base/firmware_class.c to actually check the return value
> > > > of kobject_uevent and skip
On Tue, 07 Aug 2007 08:00:40 +0200
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> (cutting out lists from CC)
>
> > > > > Your patch is changing the API in a very unsafe way, since there will
> > > > > be no error or warning on an unconverted fs. And that could lead to
> > > > > security holes.
>
Please pull from 'for-linus' branch of
git://git390.osdl.marist.edu/pub/scm/linux-2.6.git for-linus
to receive the following updates:
arch/s390/Kconfig |4 -
arch/s390/hypfs/inode.c | 12 +++
drivers/s390/char/monwriter.c |6 ++
drivers/s390/char/vmur.c
From: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
drivers/s390/crypto/zcrypt_mono.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: quilt-2.6/drivers/s390/crypto/zcrypt_mono.c
From: Heiko Carstens <[EMAIL PROTECTED]>
Also removes a bunch of ^L in drivers/s390/cio/cmf.c
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
arch/s390/kernel/audit.c|7 +--
arch/s390/kernel/audit.h| 15
From: Cornelia Huck <[EMAIL PROTECTED]>
Rename css[] to channel_subsystems[] to avoid name clashes.
Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
drivers/s390/cio/chp.c| 14
drivers/s390/cio/css.c| 69
From: Michael Holzheu <[EMAIL PROTECTED]>
If the z/VM reader is already open, it can happen that after opening the
Linux reader device, not the topmost file is processed. According the
semantics of the Linux z/VM unit record device driver, always the topmost
file has to be processed. With this
From: Cornelia Huck <[EMAIL PROTECTED]>
Comment a bunch of function in docbook style and convert existing
comments on structures to docbook.
Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
drivers/s390/cio/ccwgroup.c | 67 +++--
From: Cornelia Huck <[EMAIL PROTECTED]>
s390-drivers is generated using the docbook comments. It should
eventually supersede Documentation/s390/cds.txt.
Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
Documentation/DocBook/Makefile
From: Cornelia Huck <[EMAIL PROTECTED]>
subchannel_add_files() no longer exists, remove from header.
Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
drivers/s390/cio/css.h |1 -
1 file changed, 1 deletion(-)
Index:
From: Michael Holzheu <[EMAIL PROTECTED]>
If memory buffers above 2GB are used, diagnose 14 raises a specification
exception. This fix ensures that buffer allocation is done below the 2GB
boundary.
Signed-off-by: Michael Holzheu <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL
From: Cornelia Huck <[EMAIL PROTECTED]>
Fix some formatting and correct a comment.
Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
drivers/s390/cio/cmf.c | 133 ++---
include/asm-s390/cmb.h
From: Cornelia Huck <[EMAIL PROTECTED]>
- Fix existing kerneldoc-style comments.
- Move descriptions of functions from cmb.h to cmf.c.
Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
drivers/s390/cio/cmf.c | 87
From: Michael Holzheu <[EMAIL PROTECTED]>
If a reader file with HOLD status is at the top of the reader queue, currently
all read requests will return data of the second file in the queue. But the
semantics of vmur is that always the topmost file is read. With this fix
-EPERM is returned on open,
From: Heiko Carstens <[EMAIL PROTECTED]>
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
0ff9fb08 0ff9fb18 0002
0ff9fbb8 0ff9fb30 0ff9fb30
From: Michael Holzheu <[EMAIL PROTECTED]>
vmur allocates one contiguous kernel buffer to copy user data when creating
ccw programs for punch or printer. If big block sizes are used, under memory
pressure it can happen, that we do not get memory in one chunk. Now we
allocate memory for each single
401 - 500 of 1202 matches
Mail list logo
