Eric Dumazet wrote:
> On Tue, 14 Aug 2007 20:00:15 +0200
> Tobias Diedrich <[EMAIL PROTECTED]> wrote:
>
> > Eric Dumazet wrote:
> >
> > > Tobias Diedrich <[EMAIL PROTECTED]> wrote:
> > >
> > > > Hello,
> > > >
Herbert Xu wrote:
> Tobias Diedrich <[EMAIL PROTECTED]> wrote:
> >
> > Meanwhile I added a slab statistic rrd script. Nothing obvious to
> > see on ari or yumi yet, but on oni (which after all is the most
> > affected by this) I can see 'size_2048' and
Herbert Xu wrote:
> On Sat, Dec 15, 2007 at 11:08:58AM +0100, Tobias Diedrich wrote:
> >
> > Hmm, how do I look for that, if netstat doesn't look suspicous?
>
> Thanks. What does /proc/net/sockstat show?
[EMAIL PROTECTED]:~$ cat /proc/net/sockstat
sockets: used 143
T
Hello,
I suspect I'm seeing a slow dst cache leakage on one of my servers.
The server in question (oni) regularly needs to be rebooted, because
it loses network connectivity. However, netconsole and syslog shows that the
machine is still running and the kernel complains about "dst cache
overflow".
Andrew Morton wrote:
> erp, we have major version skew between 2.6.23-rc1-mm1 and 2.6.23-rc3 here,
> sorry.
>
> Could I ask for a redone patch against mainline?
Since I'm seeing this problem on 2.6.23-rc3, I tried adapting it.
I'm running it now and the NULL pointer messages are gone.
Index: l
Eric Dumazet wrote:
> Tobias Diedrich <[EMAIL PROTECTED]> wrote:
>
> > Hello,
> >
> > I suspect I'm seeing a slow dst cache leakage on one of my servers.
> > The server in question (oni) regularly needs to be rebooted, because
> > it loses netwo
Yinghai Lu wrote:
> On 12/19/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> >So the pin2 case should be tested right after the pin1 case as we do
> >currently. On most new boards that will be a complete noop.
> >
> >But it is better than our current blind guess at using ExtINT mode.
> >
> >I f
Ayaz Abdulla wrote:
> For all those who are having issues, please try out the attached patch.
Will try.
I reverted to 2.6.19 w/o suspend/resume patch last weekend to make
sure on 2.6.19 forcedeth is stable and noticed something odd:
Because I didn't include the suspend/resume patch I obviously ha
Tobias Diedrich wrote:
> Ayaz Abdulla wrote:
> > For all those who are having issues, please try out the attached patch.
>
> Will try.
Does not apply cleanly against 2.6.20, is this one fixed up right?
--- linux-2.6.20/drivers/net/forcedeth.c.orig 2007-02-09 13:02:02.0
Jeff Garzik wrote:
> Tobias Diedrich wrote:
> >Tobias Diedrich wrote:
> >>Ayaz Abdulla wrote:
> >>>For all those who are having issues, please try out the attached patch.
> >>Will try.
> >
> >Does not apply cleanly against 2.6.20, is this one
Tobias Diedrich wrote:
> Jeff Garzik wrote:
> > Tobias Diedrich wrote:
> > >Tobias Diedrich wrote:
> > >>Ayaz Abdulla wrote:
> > >>>For all those who are having issues, please try out the attached patch.
> > >>Will try.
> > >
>
Jeff Garzik wrote:
> Robert Hancock wrote:
> >Yes, the fact that it's going into simplex mode is the problem, it
> >wasn't in simplex to start with. It looks like pata_amd does an
> >ata_pci_clear_simplex only for certain chip models, maybe this model
> >needs it as well?
>
> Deleting the ata_p
Jeroen Roodhart wrote:
> > Any "me toos" out there, any suggestions?
>
> Big "me too" here. I use this board to run "workstation and home samba
> services"
> and it seems that under stress, the connection gets lost. Can't put my finger
> on
> the when/what/why too.
I've seen some issues with f
Linus Torvalds wrote:
> On Sun, 17 Dec 2006, Tobias Diedrich wrote:
> >
> > No such luck, it still panics and the APIC error is also unchanged.
>
> Ok. I don't see anything wrong off-hand, but I'll keep the patch in the
> tree in the hopes that Andi and/or Eric
Linus Torvalds wrote:
> Your dmesg is kind of interesting:
>
> ..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 enabled(7)APIC error on CPU0:
> 04(40)
> .. failed
>
> where that APIC error on CPU0 seems to be a "Send accept error" and "Send
> illegal vector" thing. I think we actually got the i
Pallipadi, Venkatesh wrote:
> There are two things that can be happening when OS does not see HPET in
> ACPI.
> - BIOS did enable HPET in chipset and did not communicate it to OS.
> - BIOS did nothing to enable HPET in chipset.
>
> The quirk below tries to find the HPET base address in case 1. Bu
Eric W. Biederman wrote:
> Tobias Diedrich <[EMAIL PROTECTED]> writes:
>
> > Linus Torvalds wrote:
> >
> >> Your dmesg is kind of interesting:
> >>
> >> ..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 enabled(7)APIC error on
> >> CPU0:
Tobias Diedrich wrote:
> I can also report, that updating the BIOS to version 0609 (released
> last week or so, also adds the long-missing HPET support) also makes
> the problem go away since the first testcase then already works.
> I'm currently running with the BIOS downgrade
Yinghai Lu wrote:
> Please check the latest version. ( 01/02/2007)
Works for me, with both BIOS versions / routing variants.
patches/series:
patch-2.6.20-rc4
patch-2.6.19-rc3-nokmem
myconfig
ccache
timer_01022007.diff
hpet-quirk
dmesg diff:
--- dmesg-20070108-2.6.20-rc4-bios-0402 2007-01-08 01:5
Eric W. Biederman wrote:
> Tobias. I don't have a box with the problem yours does, and this
> doesn't quite try any of the cases you have been asked to test
> so could you please test this one?
Works fine with BIOS 0402.
patches/series:
patch-2.6.20-rc4
patch-2.6.19-rc3-nokmem
myconfig
ccache
x8
Lu, Yinghai wrote:
> -Original Message-
> From: Tobias Diedrich [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 09, 2007 2:01 PM
> To: Eric W. Biederman
> Cc: Linus Torvalds; Lu, Yinghai; Andrew Morton; Adrian Bunk; Andi Kleen;
> Linux Kernel Mailing List
> Su
Linus Torvalds wrote:
> We should be getting close to a 2.6.21 release, so please update any
> regression reports you've done,
For me, suspend to disk works only once (has been the case for all
.21-rcs IIRC, but I didn't get around to report it so far).
There are some threads about an issue like
Adrian Bunk wrote:
> Does CONFIG_HPET_TIMER=n make any difference?
Unfortunately not.
> Does the latest -git work?
Coming up next :)
--
Tobias PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
-
To unsubscribe from this list: send the line "unsub
Adrian Bunk wrote:
> On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote:
> > Linus Torvalds wrote:
> >
> > > We should be getting close to a 2.6.21 release, so please update any
> > > regression reports you've done,
> >
> > For me,
Rafael J. Wysocki wrote:
> On Saturday, 14 April 2007 10:16, Tobias Diedrich wrote:
> > Adrian Bunk wrote:
> > > On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote:
> > > > Linus Torvalds wrote:
> > > >
> > > > > We should b
Adrian Bunk wrote:
> On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote:
> > Linus Torvalds wrote:
> >
> > > We should be getting close to a 2.6.21 release, so please update any
> > > regression reports you've done,
> >
> > For me,
Tobias Diedrich wrote:
> Adrian Bunk wrote:
> > On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote:
> > > Linus Torvalds wrote:
> > >
> > > > We should be getting close to a 2.6.21 release, so please update any
> > > > regression r
Tobias Diedrich wrote:
> > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit
> > commit ed746e3b18f4df18afa3763155972c5835f284c5
> > Author: Rafael J. Wysocki <[EMAIL PROTECTED]>
> > Date: Sat Feb 10 01:43:32 2007 -0800
> >
> > [PAT
Rafael J. Wysocki wrote:
> On Saturday, 14 April 2007 15:00, Adrian Bunk wrote:
> > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote:
> > > Tobias Diedrich wrote:
> > > > > ed746e3b18f4df18afa3763155972c5835f284c5 is
Rafael J. Wysocki wrote:
> On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote:
> > Rafael J. Wysocki wrote:
> > > On Saturday, 14 April 2007 15:00, Adrian Bunk wrote:
> > > > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote:
&
Rafael J. Wysocki wrote:
> On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote:
> > Rafael J. Wysocki wrote:
> > > On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote:
> > > > Rafael J. Wysocki wrote:
> > > > > On Saturday, 14 April 2007 15:00,
Tobias Diedrich wrote:
> Rafael J. Wysocki wrote:
> > On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote:
> > > Rafael J. Wysocki wrote:
> > > > On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote:
> > > > > Rafael J. Wysocki wrote:
> &g
Rafael J. Wysocki wrote:
> On Sunday, 15 April 2007 17:14, David Brownell wrote:
> > On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote:
> > > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
> >
> > > > > > > Yes, it's a
Adrian Bunk wrote:
> This email lists some known regressions in Linus' tree compared to 2.6.20.
Since I didn't see any mention of this:
I'm seeing an Oops when removing the ohci1394 module:
[ 16.047275] ieee1394: Node removed: ID:BUS[158717321-38:0860]
GUID[c033ced6]
[ 16.047287] B
Rafael J. Wysocki wrote:
> On Sunday, 15 April 2007 21:40, Tobias Diedrich wrote:
> > Rafael J. Wysocki wrote:
> > > On Sunday, 15 April 2007 17:14, David Brownell wrote:
> > > > On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote:
> > > > > On
Rafael J. Wysocki wrote:
> On Wednesday, 25 April 2007 19:14, Tobias Diedrich wrote:
> > Rafael J. Wysocki wrote:
> > > On Sunday, 15 April 2007 21:40, Tobias Diedrich wrote:
> > > > Rafael J. Wysocki wrote:
> > > > > On Sunday, 15 April 2007 17:14, D
Mika Westerberg wrote:
> On Thu, Jun 11, 2015 at 02:08:22AM +0200, Tobias Diedrich wrote:
> > In create_gpio_led only the legacy pass propagates the label by passing it
> > into
> > devm_gpio_request_one.
> >
> > On the newer devicetree/acpi path the
) out lo
gpio-479 (led3) out hi
Signed-off-by: Tobias Diedrich
---
drivers/gpio/devres.c | 6 --
drivers/gpio/gpiolib.c| 6 --
drivers/input/keyboard/gpio_keys_polled.c | 9 +
drivers/leds/leds-gpio.c | 20
driver requesting the GPIO will be probed
> > again. This also aligns ACPI GPIO lookup code closer to DT as it does
> > pretty much the same when no gpiochip driver was found.
> >
> > Reported-by: Tobias Diedrich
> > Signed-off-by: Mika Westerberg
>
> Make
, platform/PRP0001:00, AMD SBX00:
gpio-477 (led1) out hi
gpio-478 (led2) out lo
gpio-479 (led3) out hi
Signed-off-by: Tobias Diedrich
---
drivers/gpio/devres.c | 6 +-
drivers/gpio/gpiolib.c| 6 --
include/linux/gpio/consumer.h
In principle this driver could export a pinmux interface as well, but
since setting up the pinmux settings is the BIOS/EFI responsibility
I don't think it makes sense to add it (I only read it to print
the current mux state in /sys/kernel/debug/gpio).
Signed-off-by: Tobias Die
Oleksij Rempel wrote:
> Yes, this is "normal" problem. The firmware has no error handler for PCI
> bus related exceptions. So if we filed to read PCI bus first time, we
> have choice to Ooops and stall or Ooops and reboot ASAP. So we reboot
> and provide an kernel "firmware panic!" message.
> Every
Oleksij Rempel wrote:
> Am 07.06.2017 um 02:12 schrieb Tobias Diedrich:
> > Oleksij Rempel wrote:
> >> Yes, this is "normal" problem. The firmware has no error handler for PCI
> >> bus related exceptions. So if we filed to read PCI bus first time, we
> &g
.2017 um 00:39 schrieb Tobias Diedrich:
> > Oleksij Rempel wrote:
> >> Am 07.06.2017 um 02:12 schrieb Tobias Diedrich:
> >>> Oleksij Rempel wrote:
> >>>> Yes, this is "normal" problem. The firmware has no error handler for PCI
> >>>
44 matches
Mail list logo
