David Mack wrote:
> Then I got very, very lucky, since I have successfully rebooted
> 2.6.23.1-23.fc8 four times (zero panics) and this is the first time a
> 2.6.23 kernel has not panicked on me in months.
>
> This does not fill me with confidence in the theory that the panics I've
> been seeing a
On 10/18/2007 01:59 PM, Kok, Auke wrote:
> David Mack wrote:
>> It appears that the needed e100 fix made it into the Fedora
>> 2.6.23.1-23.fc8 kernel. Boots reliably now.
>>
>> Huge thanks and great work, guys.
>
>
> DaveJ, I didn't push anything upstream. Can you verify this now works?
>
One o
ition.
Dave
> -Original Message-
> From: Dave Jones [mailto:[EMAIL PROTECTED]
> Sent: Sunday, October 21, 2007 6:05 PM
> To: Kok, Auke
> Cc: David Mack; Herbert Xu; netdev@vger.kernel.org;
> [EMAIL PROTECTED]
> Subject: Re: e100 problems in .23rc8 ?
>
> On Thu,
On Sun, Oct 21, 2007 at 09:04:40PM -0400, Dave Jones wrote:
>
> I included the patch below in the latest build, but I've not had
> chance to try it on an e100 box yet..
Looks good to me. Thanks Dave!
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
H
On Thu, Oct 18, 2007 at 10:59:59AM -0700, Kok, Auke wrote:
> David Mack wrote:
> > It appears that the needed e100 fix made it into the Fedora
> > 2.6.23.1-23.fc8 kernel. Boots reliably now.
> >
> > Huge thanks and great work, guys.
>
> DaveJ, I didn't push anything upstream. Can you verif
On 10/18/2007 01:59 PM, Kok, Auke wrote:
> David Mack wrote:
>> It appears that the needed e100 fix made it into the Fedora
>> 2.6.23.1-23.fc8 kernel. Boots reliably now.
>>
>> Huge thanks and great work, guys.
>
>
> DaveJ, I didn't push anything upstream. Can you verify this now works?
>
We di
---Original Message-
>> From: Kok, Auke [mailto:[EMAIL PROTECTED]
>> Sent: Friday, October 12, 2007 10:05 AM
>> To: Herbert Xu
>> Cc: David Mack; Dave Jones; netdev@vger.kernel.org;
>> [EMAIL PROTECTED]
>> Subject: Re: e100 problems in .23rc8 ?
>>
>
Cc: David Mack; Dave Jones; netdev@vger.kernel.org;
> [EMAIL PROTECTED]
> Subject: Re: e100 problems in .23rc8 ?
>
> Herbert Xu wrote:
> > On Fri, Oct 12, 2007 at 07:54:33AM -0700, David Mack wrote:
> >> Still no joy here. See attached capture. What's really
> we
6, 2007 7:35 AM
> To: Eric Sandeen
> Cc: David Mack; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> netdev@vger.kernel.org
> Subject: Re: e100 problems in .23rc8 ?
>
> On Tue, Oct 16, 2007 at 09:33:15AM -0500, Eric Sandeen wrote:
> >
> > Hm... running 2.6.23-6.fc8, I&#x
Herbert Xu wrote:
> On Tue, Oct 16, 2007 at 09:33:15AM -0500, Eric Sandeen wrote:
>> Hm... running 2.6.23-6.fc8, I've been through 30+ reboot cycles without
>> a problem. Before, I'd oops every 5 or so times I booted...
>>
>> I now have another NIC in the box, disabled; I don't think that should
>
On Tue, Oct 16, 2007 at 09:33:15AM -0500, Eric Sandeen wrote:
>
> Hm... running 2.6.23-6.fc8, I've been through 30+ reboot cycles without
> a problem. Before, I'd oops every 5 or so times I booted...
>
> I now have another NIC in the box, disabled; I don't think that should
> be affecting anythi
Herbert Xu wrote:
> David Mack <[EMAIL PROTECTED]> wrote:
>> If I understand the message Dave Jones sent yesterday, the patch you
>> mention *was* applied to the e100 driver in 2.6.23-6.fc8?
>
> Nope, he applied a different one which doesn't have the crucial
> part to disable NAPI polls before reg
David Mack <[EMAIL PROTECTED]> wrote:
> If I understand the message Dave Jones sent yesterday, the patch you
> mention *was* applied to the e100 driver in 2.6.23-6.fc8?
Nope, he applied a different one which doesn't have the crucial
part to disable NAPI polls before registration.
Cheers,
--
Visi
Herbert Xu wrote:
> On Fri, Oct 12, 2007 at 07:54:33AM -0700, David Mack wrote:
>> Still no joy here. See attached capture. What's really weird is that it
>> shows *two* kernel panics, one in e100_poll and one in _list_add.
>
> Yes that's the symptom one would expect from that bug. We really
> n
> Cc: Herbert Xu; netdev@vger.kernel.org; [EMAIL PROTECTED];
> David Mack
> Subject: Re: e100 problems in .23rc8 ?
>
> On Thu, Oct 11, 2007 at 09:10:34AM -0700, Kok, Auke wrote:
> > Herbert Xu wrote:
> > > On Wed, Oct 10, 2007 at 08:36:38PM -0400, Dave Jones wrote
ones; Kok, Auke; netdev@vger.kernel.org; [EMAIL PROTECTED]
> Subject: Re: e100 problems in .23rc8 ?
>
> On Fri, Oct 12, 2007 at 07:54:33AM -0700, David Mack wrote:
> > Still no joy here. See attached capture. What's really
> weird is that it
> > shows *two* kernel pa
On Fri, Oct 12, 2007 at 07:54:33AM -0700, David Mack wrote:
> Still no joy here. See attached capture. What's really weird is that it
> shows *two* kernel panics, one in e100_poll and one in _list_add.
Yes that's the symptom one would expect from that bug. We really
need to apply the same fix th
On Thu, Oct 11, 2007 at 09:10:34AM -0700, Kok, Auke wrote:
> >>
> >> commit 416b5d10afdc797c21c457ade3714e8f2f75edd9
> >> Author: Auke Kok <[EMAIL PROTECTED]>
> >> Date: Fri Jun 1 10:22:39 2007 -0700
> >>
> >> e1000: disable polling before registering netdevice
>
> this patch actually called
Eric/David, the Fedora 8 RPM version 2.6.23-6.fc8 will have this if you
want to give it a shot too. It'll be at
http://people.redhat.com/davej/kernels/Fedora/f7.92/ when it's done
building in an hour or so.
Dave
Thanks, I'll give it a whirl this evening. I put a new net card in that
On Thu, Oct 11, 2007 at 09:10:34AM -0700, Kok, Auke wrote:
> Herbert Xu wrote:
> > On Wed, Oct 10, 2007 at 08:36:38PM -0400, Dave Jones wrote:
> >> The e1000 changes you reference above, is this the changeset you mean?
> >>
> >> commit 416b5d10afdc797c21c457ade3714e8f2f75edd9
> >> Author: Auk
Herbert Xu wrote:
> On Wed, Oct 10, 2007 at 08:36:38PM -0400, Dave Jones wrote:
>> The e1000 changes you reference above, is this the changeset you mean?
>>
>> commit 416b5d10afdc797c21c457ade3714e8f2f75edd9
>> Author: Auke Kok <[EMAIL PROTECTED]>
>> Date: Fri Jun 1 10:22:39 2007 -0700
>>
>>
On Wed, Oct 10, 2007 at 08:36:38PM -0400, Dave Jones wrote:
>
> The e1000 changes you reference above, is this the changeset you mean?
>
> commit 416b5d10afdc797c21c457ade3714e8f2f75edd9
> Author: Auke Kok <[EMAIL PROTECTED]>
> Date: Fri Jun 1 10:22:39 2007 -0700
>
> e1000: disable polling
On Thu, Sep 27, 2007 at 02:58:27PM +0800, Herbert Xu wrote:
> Kok, Auke <[EMAIL PROTECTED]> wrote:
> > Dave Jones wrote:
> >> Last night, I hit this bug during boot up..
> >> http://www.codemonkey.org.uk/junk/e100-2.jpg
> >>
> >> This morning, I got a mail from a Fedora user of the same
> >
Kok, Auke <[EMAIL PROTECTED]> wrote:
> Dave Jones wrote:
>> Last night, I hit this bug during boot up..
>> http://www.codemonkey.org.uk/junk/e100-2.jpg
>>
>> This morning, I got a mail from a Fedora user of the same
>> .23-rc8 based kernel that has seen a different trace
>> also implicating e100..
On Wed, Sep 26, 2007 at 11:10:11AM -0700, Kok, Auke wrote:
> Dave Jones wrote:
> > Last night, I hit this bug during boot up..
> > http://www.codemonkey.org.uk/junk/e100-2.jpg
> >
> > This morning, I got a mail from a Fedora user of the same
> > .23-rc8 based kernel that has seen a different
Dave Jones wrote:
> Last night, I hit this bug during boot up..
> http://www.codemonkey.org.uk/junk/e100-2.jpg
>
> This morning, I got a mail from a Fedora user of the same
> .23-rc8 based kernel that has seen a different trace
> also implicating e100..
>
> http://www.codemonkey.org.uk/junk/e100.
ericj wrote:
I want to thank everyone who helped with this.
It was proven to be a hardware issue. The board designer had left a GPIO
pin in an indeterminate state because he was planning to use it later to
do something with the battery charge circuitry.
I apologize for wasting everyone's time.
I want to thank everyone who helped with this.
It was proven to be a hardware issue. The board designer had left a GPIO
pin in an indeterminate state because he was planning to use it later to
do something with the battery charge circuitry.
I apologize for wasting everyone's time.
On Mon, 06 Aug
On Mon, 06 Aug 2007 17:45:09 -0700, Kok, Auke wrote
> [moving to netdev mailinglist]
> Eric,
>
> please don't forget that an entire team here at Intel is
> dedicated to supporting e100 and pro/1000 devices from Intel.
>
> Most of the pro/100 features are documented in the SDM which
> contains s
[moving to netdev mailinglist]
ericj wrote:
On Mon, 6 Aug 2007 11:20:58 -0500, ericj wrote
On Mon, 06 Aug 2007 12:13:28 -0400, Jeff Garzik wrote
eepro100 is going to be removed. Please try e100 on 2.6.22 or
2.6.23-rc2.
I will give the 2.6.23 a try.
I tried 2.6.23-rc2 and there was no cha
Andrew Morton wrote:
I was doing some suspend-to-ram testing on the Vaio with the 2.6.22-rc3-mm1
lineup. After 10 or 15 cycles a resume failed:
[ 357.119436] Suspending device full
[ 357.120450] Suspending device zero
[ 358.084978] Suspending device port
[ 358.085664] Suspending device null
YOSHIFUJI Hideaki / [EMAIL PROTECTED] wrote:
Hello.
I heard that there is a plan to remove eepro100 driver from kernel,
but from the IPv6 point of view, there are still some issues with
e100 driver, which does not exist in eepro100.
We are using some e100/eepro100 devices, and we have found tha
Harry Coin wrote:
At 10:19 AM 1/15/2007 -0800, Auke Kok wrote:
Have you tried the version in 2.6.19?
I even tried copying and pasting the e100_down and the latest PM stuff
from the newest e100.c version on sourceforge. I admit to being
defeated as to how to join a sourceforge group. Too
At 10:19 AM 1/15/2007 -0800, Auke Kok wrote:
Have you tried the version in 2.6.19?
I even tried copying and pasting the e100_down and the latest PM stuff from
the newest e100.c version on sourceforge. I admit to being defeated as to
how to join a sourceforge group. Too many hours writing
Harry Coin wrote:
Hello from Iowa.
Below please find a fix to the Wake On Lan function in the e100.c (intel
10/100) driver. With the original driver distributed in kernel 2.6.18
in debian etch, wake on lan did not work. This was tested on 14 dell
optiplexes with built-in ethernet chips in
Jesse Brandeburg wrote:
sorry for the delay, your mail got marked as spam. In the future
please copy networking issues to netdev@vger.kernel.org, and be sure
to copy the maintainers of the driver you're having problems with
(they are in the MAINTAINERS file)
On 11/22/06, Amin Azez <[EMAIL PROTE
Hi Auke,
On Mon, Nov 27, 2006 at 11:18:13AM -0800, Auke Kok wrote:
> >I'm seeing some odd behavior using the e100 driver for an intel ethernet
> >controller 82557/8/9 (revv 10). It appears as if the e100 driver is
> >handling interrupts generated by another device, though I am not certain
> >of t
sorry for the delay, your mail got marked as spam. In the future
please copy networking issues to netdev@vger.kernel.org, and be sure
to copy the maintainers of the driver you're having problems with
(they are in the MAINTAINERS file)
On 11/22/06, Amin Azez <[EMAIL PROTECTED]> wrote:
I notice a
Shaw Vrana wrote:
Hello All,
I'm seeing some odd behavior using the e100 driver for an intel ethernet
controller 82557/8/9 (revv 10). It appears as if the e100 driver is
handling interrupts generated by another device, though I am not certain
of this..
Using some printks, I see some odd packet
Anders Grafström wrote:
Anders Grafström wrote:
I ran mii-diag when the LEDs went out and the register dump
said it was in loopback. It is somewhat difficult reproduce.
It seems to be timing dependent, something else has to occur
at the same time.
I must confess I have only seen it with the 2.6.
>> Anders Grafström wrote:
>>> I ran mii-diag when the LEDs went out and the register dump
>>> said it was in loopback. It is somewhat difficult reproduce.
>>> It seems to be timing dependent, something else has to occur
>>> at the same time.
>>> I must confess I have only seen it with the 2.6.13 k
Auke Kok wrote:
Anders Grafström wrote:
Auke Kok wrote:
Allthough the spec itself didn't talk about phy reset times, I've ran
this
patch with
some debugging output on a few boxes and did some speed/duplex settings,
and the PHY
reset returned succesfull after the very first mdio_read, which is
Anders Grafström wrote:
Auke Kok wrote:
Allthough the spec itself didn't talk about phy reset times, I've ran this
patch with
some debugging output on a few boxes and did some speed/duplex settings,
and the PHY
reset returned succesfull after the very first mdio_read, which is before
any msleep(
Auke Kok wrote:
> Allthough the spec itself didn't talk about phy reset times, I've ran this
> patch with
> some debugging output on a few boxes and did some speed/duplex settings,
> and the PHY
> reset returned succesfull after the very first mdio_read, which is before
> any msleep(10)
> is execut
Auke Kok <[EMAIL PROTECTED]> :
[...]
> okay, I don't think this is needed at all:
>
> Allthough the spec itself didn't talk about phy reset times, I've ran this
> patch with some debugging output on a few boxes and did some speed/duplex
> settings, and the PHY reset returned succesfull after the
Auke Kok wrote:
Francois Romieu wrote:
Anders Grafstrom <[EMAIL PROTECTED]> :
[...]
I'm thinking something like this patch.
I do not have the spec for the max duration at hand but it makes sense.
Can you:
- decrease the duration of each sleep and increase the count of
iterations
- put the
Francois Romieu wrote:
Anders Grafstrom <[EMAIL PROTECTED]> :
[...]
I'm thinking something like this patch.
I do not have the spec for the max duration at hand but it makes sense.
Can you:
- decrease the duration of each sleep and increase the count of iterations
- put the break on a line of
Anders Grafstrom <[EMAIL PROTECTED]> :
[...]
> I'm thinking something like this patch.
I do not have the spec for the max duration at hand but it makes sense.
Can you:
- decrease the duration of each sleep and increase the count of iterations
- put the break on a line of its own
- add a Signed-of
Andrew Morton wrote:
Enable netconsole-over-e100, and `reboot -f' hangs. Disabling netconsole
prevents that from happening.
I assume what's happening is that the driver gets shut down and then
something tries to do a printk through it, and things hang.
For some reason sysrq-B still reboots the
Auke Kok wrote:
> Can you include a full `dmesg` and `lcpci -vv -s 00:12.0` ?
>
> Also you're using 3.5.10-k2, can you try the current git tree version
> instead? I can send you the e100.c if wanted.
Yes, please, to make sure that we'll really discuss the same version.
Will then try to collect th
Jan Kiszka wrote:
Hi,
we have a couple of industrial PCs here with Intel PRO/100 controllers
on board. Most of them work fine with the e100, but today I stumbled
over one box that doesn't: Reception works (RX counter increases, ARP
cache gets filled up), but transmission fails (TX counter is als
Hi,
> If the EEPROM has a broken checksum, the user should have an option
> that allows him to try and use the device anyways, end of story.
Ive come across this problem a number of times on e1000 chips (to be
clear it was vendor programming issues).
The driver has the option to read and write
[EMAIL PROTECTED] said:
> And BTW I want to remind the entire world that the last time Intel
> cried wolf to all of us about vendors using broken EEPROMs with their
> networking chips it turned out to be a bug in one of the patches Intel
> put into the Linux driver. :-)
>
> Intel should really humb
David Miller wrote:
Please put the option into the e100 driver to allow trying to use the
device even if the EEPROM checksum is wrong.
Whee, the users win! :-)
If an Intel developer doesn't do it, I will.
I hope you don't piss off the nice guys at Intel who contribute source
code to the Lin
From: David Miller <[EMAIL PROTECTED]>
Date: Fri, 04 Aug 2006 04:20:24 -0700 (PDT)
> I totally agree, Intel driver maintainers generally act like complete
> idiots in these kinds of situations.
>
> If the EEPROM has a broken checksum, the user should have an option
> that allows him to try and us
From: "Molle Bestefich" <[EMAIL PROTECTED]>
Date: Fri, 4 Aug 2006 13:04:07 +0200
> You're trying to pull Linux end users into a war between Intel and
> it's vendors, so you can make end users scream at the vendors when
> they forget to run the checksum tool.
I totally agree, Intel driver maintain
Auke Kok wrote:
Charlie Brady wrote:
> Let's assume that these things are all true, and the NIC currently does
> not work perfectly, just imperfectly, but acceptably. With the recent
> driver change, it now does not work at all. That's surely a bug in the
> driver.
There is no logic in that sent
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> Act 1
>
> Enter the mpi_start_xmit() function, which is airo's xmit function.
> This function takes the aux_lock first, with irq's off, then calls
> skb_queue_tail(). skb_queue_tail takes the sk_receive_queue.lock (with
> irqsave as well).
Nope, ma
On Fri, 2006-07-07 at 13:19 -0400, Dave Jones wrote:
> Another one triggered by a Fedora-development user..
>
> e100: eth1: e100_watchdog: link up, 100Mbps, half-duplex
>
> =
> [ INFO: possible irq lock inversion dependency detected ]
>
> On 4/5/06, David S. Miller <[EMAIL PROTECTED]> wrote:
> From: Roland Dreier <[EMAIL PROTECTED]>
> Date: Wed, 05 Apr 2006 14:52:24 -0700
>
> > > + case 0x1030 ... 0x1034:
> >
> > Do we use the gcc "case range" extension in the kernel? (This is an
> > honest question -- I don't think I've seen i
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Wed, 05 Apr 2006 14:52:24 -0700
> > + case 0x1030 ... 0x1034:
>
> Do we use the gcc "case range" extension in the kernel? (This is an
> honest question -- I don't think I've seen it used anywhere, and I'd
> be curious to know what the taste arbiter
Roland Dreier wrote:
> + case 0x1030 ... 0x1034:
Do we use the gcc "case range" extension in the kernel? (This is an
honest question -- I don't think I've seen it used anywhere, and I'd
be curious to know what the taste arbiters think of it)
I'm not a fan of it either but it is used already
On Wednesday 05 April 2006 15:52, Roland Dreier wrote:
> > + case 0x1030 ... 0x1034:
>
> Do we use the gcc "case range" extension in the kernel? (This is an
> honest question -- I don't think I've seen it used anywhere, and I'd
> be curious to know what the taste arbiters think of it)
There ar
On Wed, 5 Apr 2006, Roland Dreier wrote:
> > + case 0x1030 ... 0x1034:
>
> Do we use the gcc "case range" extension in the kernel? (This is an
> honest question -- I don't think I've seen it used anywhere, and I'd
> be curious to know what the taste arbiters think of it)
It's OK AFAIK.
grep fi
> +case 0x1030 ... 0x1034:
Do we use the gcc "case range" extension in the kernel? (This is an
honest question -- I don't think I've seen it used anywhere, and I'd
be curious to know what the taste arbiters think of it)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
t
Jesse Brandeburg wrote:
On 1/28/06, Mattia Dongili <[EMAIL PROTECTED]> wrote:
On Thu, Jan 26, 2006 at 08:02:37PM +0100, Stefan Seyfried wrote:
On Wed, Jan 25, 2006 at 04:28:48PM -0800, Jesse Brandeburg wrote:
Okay I reproduced the issue on 2.6.15.1 (with S1 sleep) and was able
to show that
On 1/28/06, Mattia Dongili <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 26, 2006 at 08:02:37PM +0100, Stefan Seyfried wrote:
> > On Wed, Jan 25, 2006 at 04:28:48PM -0800, Jesse Brandeburg wrote:
> >
> > > Okay I reproduced the issue on 2.6.15.1 (with S1 sleep) and was able
> > > to show that my patch t
On Thu, Jan 26, 2006 at 08:02:37PM +0100, Stefan Seyfried wrote:
> On Wed, Jan 25, 2006 at 04:28:48PM -0800, Jesse Brandeburg wrote:
>
> > Okay I reproduced the issue on 2.6.15.1 (with S1 sleep) and was able
> > to show that my patch that just removes e100_init_hw works okay for
> > me. Let me k
On Thu, Jan 26, 2006 at 08:02:37PM +0100, Stefan Seyfried wrote:
> Will be in the next SUSE betas, so if anything breaks, we'll notice
> it.
I doubt it. As Jesse mentioned, e100_hw_init is called from e100_up,
so the call from e100_resume was really superfluous.
Olaf
--
Olaf Kirch | --- o ---
On Wed, Jan 25, 2006 at 04:28:48PM -0800, Jesse Brandeburg wrote:
> Okay I reproduced the issue on 2.6.15.1 (with S1 sleep) and was able
> to show that my patch that just removes e100_init_hw works okay for
> me. Let me know how it goes for you, I think this is a good fix.
worked for me in the
On St 25-01-06 16:28:48, Jesse Brandeburg wrote:
> On 1/25/06, Jesse Brandeburg <[EMAIL PROTECTED]> wrote:
> > On 1/25/06, Olaf Kirch <[EMAIL PROTECTED]> wrote:
> > > On Wed, Jan 25, 2006 at 10:02:40AM +0100, Olaf Kirch wrote:
> > > > I'm not sure what the right fix would be. e100_resume would prob
On 1/25/06, Jesse Brandeburg <[EMAIL PROTECTED]> wrote:
> On 1/25/06, Olaf Kirch <[EMAIL PROTECTED]> wrote:
> > On Wed, Jan 25, 2006 at 10:02:40AM +0100, Olaf Kirch wrote:
> > > I'm not sure what the right fix would be. e100_resume would probably
> > > have to call e100_alloc_cbs early on, while e1
On 1/25/06, Olaf Kirch <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 25, 2006 at 11:37:40AM -0800, Jesse Brandeburg wrote:
> > its an interesting patch, but it raises the question why does
> > e100_init_hw need to be called at all in resume? I looked back
> > through our history and that init_hw call h
On Wed, Jan 25, 2006 at 11:37:40AM -0800, Jesse Brandeburg wrote:
> its an interesting patch, but it raises the question why does
> e100_init_hw need to be called at all in resume? I looked back
> through our history and that init_hw call has always been there. I
> think its incorrect, but its ta
On 1/25/06, Olaf Kirch <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 25, 2006 at 10:02:40AM +0100, Olaf Kirch wrote:
> > I'm not sure what the right fix would be. e100_resume would probably
> > have to call e100_alloc_cbs early on, while e100_up should avoid
> > calling it a second time if nic->cbs_avai
On Wed, Jan 25, 2006 at 10:02:40AM +0100, Olaf Kirch wrote:
> I'm not sure what the right fix would be. e100_resume would probably
> have to call e100_alloc_cbs early on, while e100_up should avoid
> calling it a second time if nic->cbs_avail != 0. A tentative patch
> for testing is attached.
Repo
On Wed, Jan 25, 2006 at 12:21:42AM +0100, Mattia Dongili wrote:
> I experienced the same today, I was planning to get a photo tomorrow :)
> I'm running 2.6.16-rc1-mm2 and the last working kernel was 2.6.15-mm4
> (didn't try .16-rc1-mm1 being scared of the reiserfs breakage).
I think that's because
On Tue, Jan 24, 2006 at 11:59:19PM +0100, Stefan Seyfried wrote:
> Hi,
> since 2.6.16rc1-git3, e100 dies on resume (regardless if from disk, ram or
> runtime powermanagement). Unfortunately i only have a bad photo of
> the oops right now, it is available from
> https://bugzilla.novell.com/attachmen
78 matches
Mail list logo
