LinuxLists.cc - Linux 2.6.19-rc2

[permalink] [raw]

Subject: Re: Linux 2.6.19-rc2

On Fri, 13 Oct 2006, Alistair John Strachan wrote:
>
> Does anybody know what's up with the git server? Hopefully it's just my
> connection...

It's likely either
- a mirroring issue (the git.kernel.org server is _not_ the main one I
push to, so it can take a while, and if some objects haven't made it,
the upload side will exit because the repository isn't "valid" until
the full mirror has happened)
- too many clients trying at the same time

In this case, I suspect the latter.

Linus

2006-10-13 18:26:57

by Michal Piotrowski

[permalink] [raw]

Subject: Re: Linux 2.6.19-rc2

On 13/10/06, Michal Piotrowski <[email protected]> wrote:
> Hi,
>
> Linus Torvalds wrote:
> > Ok, it's a week since -rc1, so -rc2 is out there.
> >
>
> Please consider applying this patches.
>

Aghr... mirror problem. Please ignore.
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0e7af8d04ecb4f6ba8cd1f731f036a004ad0e174

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)

2006-10-13 18:34:38

by Alex Romosan

[permalink] [raw]

Subject: Re: Linux 2.6.19-rc2

Linus Torvalds <[email protected]> writes:

> So if you had issues with -rc1 (which had a ton of merges - even
> more so than most -rc1 releases, I think), this should hopefully be
> a lot better.

airo driver suspend is still broken. i still need to apply the patch
posted originally at (with an explanation of why airo suspend is not
working anymore)
http://marc.theaimsgroup.com/?l=linux-kernel&m=116025080215854&w=2 to
get the driver to suspend. (the patch still applies to 2.6.19-rc2 with
minor fuzz).

--alex--

--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |

2006-10-13 20:54:20

by Willy Tarreau

[permalink] [raw]

Subject: Re: Linux 2.6.19-rc2

On Fri, Oct 13, 2006 at 10:55:17AM -0700, H. Peter Anvin wrote:
> Alistair John Strachan wrote:
> >On Friday 13 October 2006 17:49, Linus Torvalds wrote:
> >>Ok, it's a week since -rc1, so -rc2 is out there.
> >
> >Does anybody know what's up with the git server? Hopefully it's just my
> >connection...
> >
> >[alistair] 18:38 [~/linux-git] git pull
> >fatal: unexpected EOF
> >Fetch failure:
> >git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> >
>
> No, this is the result of a serious problem with gitweb.
>
> We run gitweb behind a cache (otherwise it would be unacceptably
> expensive), but when httpd starts timing out on gitweb, it spawns gitweb
> over and over and over again, and the load on the machine skyrockets,
> throttling other services.
>
> This happens every time we're on one server instead of two (one server
> is down right now for network rewiring.)
>
> I think for now I'm just going to put a loadavg cap on running gitweb...

I encountered a similar problem (to a far lower scale) when putting
gitweb on my poor parisc server behind my ADSL line. The machine used
to OOM several times a week. So I've set up an haproxy instance in
front of it with a limit on the number of concurrent connections per
backend. All excess connections are queued and served as soon as one
slot frees up. The machine has never crashed since. Would you be
interested in some help in trying to set it up ? Assuming that epoll
is available, I have absolutely no worries about the load. As an added
benefit, it could also provide HA and LB but I understand it's not the
main concern right now.

Willy

2006-10-14 11:15:03

[permalink] [raw]

Subject: [0/3] 2.6.19-rc2: known regressions

As usual, we are swamped with bug reports for regressions after -rc1.

For an easier reading (and hoping linux-kernel might not eat the emails),
I've splitted the list of known regressions in three emails:
[1/3] known unfixed regressions
[2/3] knwon regressions with workarounds
[3/3] known regressions with patches

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

2006-10-14 11:22:36

[permalink] [raw]

Subject: [1/3] 2.6.19-rc2: known unfixed regressions

This email lists some known unfixed regressions in 2.6.19-rc2 compared
to 2.6.18.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.

Subject : CONFIG_X86_VOYAGER=y, CONFIG_SMP=n compile error
References : http://lkml.org/lkml/2006/10/7/51
Submitter : Jesper Juhl <[email protected]>
Caused-By : David Howells <[email protected]>
commit 7d12e780e003f93433d49ce78cfedf4b4c52adc5
Status : unknown

Subject : CONFIG_X86_VISWS=y, CONFIG_SMP=n compile error
References : http://lkml.org/lkml/2006/10/7/51
Submitter : Jesper Juhl <[email protected]>
Caused-By : David Howells <[email protected]>
commit 7d12e780e003f93433d49ce78cfedf4b4c52adc5
Status : unknown

Subject : unable to rip cd
References : http://lkml.org/lkml/2006/10/13/100
Submitter : Alex Romosan <[email protected]>
Status : unknown

Subject : sata-via doesn't detect anymore disks attached to VIA vt6421
References : http://bugzilla.kernel.org/show_bug.cgi?id=7255
Submitter : Thierry Vignaud <[email protected]>
Status : unknown

Subject : monitor not active after boot
References : http://lkml.org/lkml/2006/10/5/338
Submitter : Olaf Hering <[email protected]>
Caused-By : Antonino Daplas <[email protected]>
commit 346bc21026e7a92e1d7a4a1b3792c5e8b686133d
Status : unknown

Subject : SMP x86_64 boot problem
References : http://lkml.org/lkml/2006/9/28/330
http://lkml.org/lkml/2006/10/5/289
Submitter : [email protected]
Status : submitter was asked to git bisect
result of bisecting seems to be wrong

Subject : do_IRQ: No irq handler for vector
References : http://lkml.org/lkml/2006/10/11/13
Submitter : Robert Hancock <[email protected]>
Handled-By : "Eric W. Biederman" <[email protected]>
Status : Andrew: a few people are seeing this. Eric is working it.

Subject : messed up keyboard events, TSC related
References : http://bugzilla.kernel.org/show_bug.cgi?id=7291
Submitter : David Gerber <[email protected]>
Handled-By : Dmitry Torokhov <[email protected]>
John Stultz <[email protected]>
Status : Dmitry and John are investigating

Subject : ide-generic no longer finds marvell controller
References : http://bugzilla.kernel.org/show_bug.cgi?id=7353
Submitter : Kenny Graunke <[email protected]>
Caused-By : Patrick Jefferson <[email protected]>
commit a4bea10eca68152e84ffc4eaeb9d20ec2ac34664
Handled-By : Alan Cox <[email protected]>
Status : Alan is investigating

Subject : cpufreq not working on AMD K8
References : http://lkml.org/lkml/2006/10/10/114
Submitter : Christian <[email protected]>
Handled-By : Mark Langsdorf <[email protected]>
Status : Mark is investigating

2006-10-14 11:25:38

[permalink] [raw]

Subject: [2/3] 2.6.19-rc2: knwon regressions with workarounds

This email lists some known regressions with workarounds in 2.6.19-rc2
compared to 2.6.18.

Unless proper solutions become available, we should implement the
workarounds.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Please trim the Cc when answering.

Subject : snd-hda-intel <-> forcedeth MSI problem
References : http://lkml.org/lkml/2006/10/5/40
http://lkml.org/lkml/2006/10/7/164
Submitter : Prakash Punnoor <[email protected]>
Status : suggested workaround for 2.6.19:
deactivate MSI in snd-intel-hda by default

Subject : DVB frontend selection causes compile errors
References : http://lkml.org/lkml/2006/10/8/244
Submitter : Adrian Bunk <[email protected]>
Caused-By : "Andrew de Quincey" <[email protected]>
commit 176ac9da4f09820a43fd48f0e74b1486fc3603ba
Handled-By : Michael Krufky <[email protected]>
"Andrew de Quincey" <[email protected]>
Status : possible workaround: don't allow CONFIG_DVB_FE_CUSTOMISE=y

2006-10-14 11:56:10

by Eric W. Biederman

[permalink] [raw]

Subject: Re: [1/3] 2.6.19-rc2: known unfixed regressions

Adrian Bunk <[email protected]> writes:

> This email lists some known unfixed regressions in 2.6.19-rc2 compared
> to 2.6.18.
>
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a breakage or I'm considering you in any other way possibly
> involved with one or more of these issues.
>
> Due to the huge amount of recipients, please trim the Cc when answering.
>
>

> Subject : do_IRQ: No irq handler for vector
> References : http://lkml.org/lkml/2006/10/11/13
> Submitter : Robert Hancock <[email protected]>
> Handled-By : "Eric W. Biederman" <[email protected]>
> Status : Andrew: a few people are seeing this. Eric is working it.

Please see commit: 994bd4f9f5a065ead4a92435fdd928ac7fd33809
That part should fine in -rc2

YH found a corner case I missed (in my bug fix refactoring) and submitted a patch
earlier today. But that only shows up when we resubmit an irq which
is almost never.

Eric

2006-10-14 19:08:04

by Olaf Hering

[permalink] [raw]

Subject: Re: Linux 2.6.19-rc2

On Fri, Oct 13, Linus Torvalds wrote:

>
> Ok, it's a week since -rc1, so -rc2 is out there.

The tar.gz is broken:
tar tvfz /mounts/mirror/kernel/v2.6/testing/linux-2.6.19-rc2.tar.gz| head
-rw-r--r-- git/git 542 2006-10-13 18:25:04 linux-2.6.19-rc2.gitignore
-rw-r--r-- git/git 18693 2006-10-13 18:25:04 linux-2.6.19-rc2COPYING
-rw-r--r-- git/git 90289 2006-10-13 18:25:04 linux-2.6.19-rc2CREDITS

2006-10-15 12:25:06

[permalink] [raw]

Subject: Re: [0/3] 2.6.19-rc2: known regressions

On Sat, Oct 14, 2006 at 01:14:58PM +0200, Adrian Bunk wrote:
> As usual, we are swamped with bug reports for regressions after -rc1.
>
> For an easier reading (and hoping linux-kernel might not eat the emails),
> I've splitted the list of known regressions in three emails:
> [1/3] known unfixed regressions
> [2/3] knwon regressions with workarounds
> [3/3] known regressions with patches

There's a raft of ARM regressions as well (see
http://armlinux.simtec.co.uk/kautobuild/2.6.19-rc2/index.html), mostly
related to the IRQ changes, as well as this error:

sysctl_net.c:(.text+0x64a8c): undefined reference to `highest_possible_node_id'

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core

2006-10-15 12:42:15

[permalink] [raw]

Subject: Re: [0/3] 2.6.19-rc2: known regressions

On Sun, Oct 15, 2006 at 01:24:54PM +0100, Russell King wrote:
> On Sat, Oct 14, 2006 at 01:14:58PM +0200, Adrian Bunk wrote:
> > As usual, we are swamped with bug reports for regressions after -rc1.
> >
> > For an easier reading (and hoping linux-kernel might not eat the emails),
> > I've splitted the list of known regressions in three emails:
> > [1/3] known unfixed regressions
> > [2/3] knwon regressions with workarounds
> > [3/3] known regressions with patches
>
> There's a raft of ARM regressions as well (see
> http://armlinux.simtec.co.uk/kautobuild/2.6.19-rc2/index.html), mostly
> related to the IRQ changes, as well as this error:

Thanks, I'll look at them before preparing the next version of my
regressions list.

> sysctl_net.c:(.text+0x64a8c): undefined reference to `highest_possible_node_id'

This problem already got an entry a few hours ago:

Subject : undefined reference to highest_possible_node_id
References : http://lkml.org/lkml/2006/9/4/233
http://lkml.org/lkml/2006/10/15/11
Submitter : Olaf Hering <[email protected]>
Caused-By : Greg Banks <[email protected]>
commit 0f532f3861d2c4e5aa7dcd33fb18e9975eb28457
Status : unknown

> Russell King

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

2006-10-19 09:09:51

[permalink] [raw]

Subject: Re: [0/3] 2.6.19-rc2: known regressions

On Sun, Oct 15, 2006 at 02:42:10PM +0200, Adrian Bunk wrote:
> On Sun, Oct 15, 2006 at 01:24:54PM +0100, Russell King wrote:
> > On Sat, Oct 14, 2006 at 01:14:58PM +0200, Adrian Bunk wrote:
> > > As usual, we are swamped with bug reports for regressions after -rc1.
> > >
> > > For an easier reading (and hoping linux-kernel might not eat the emails),
> > > I've splitted the list of known regressions in three emails:
> > > [1/3] known unfixed regressions
> > > [2/3] knwon regressions with workarounds
> > > [3/3] known regressions with patches
> >
> > There's a raft of ARM regressions as well (see
> > http://armlinux.simtec.co.uk/kautobuild/2.6.19-rc2/index.html), mostly
> > related to the IRQ changes, as well as this error:
>
> Thanks, I'll look at them before preparing the next version of my
> regressions list.
>
> > sysctl_net.c:(.text+0x64a8c): undefined reference to `highest_possible_node_id'
>
> This problem already got an entry a few hours ago:
>
> Subject : undefined reference to highest_possible_node_id
> References : http://lkml.org/lkml/2006/9/4/233
> http://lkml.org/lkml/2006/10/15/11
> Submitter : Olaf Hering <[email protected]>
> Caused-By : Greg Banks <[email protected]>
> commit 0f532f3861d2c4e5aa7dcd33fb18e9975eb28457
> Status : unknown

Looking at this commit and the mails, it was known on the 4th September
that this patch caused build errors while this change was in -mm, yet it
still found its way into mainline on 2nd October.

Is anyone going to look at fixing this problem, or should we be asking
for the commit to be reverted?

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core

2006-10-20 18:07:32

[permalink] [raw]

Subject: Re: [0/3] 2.6.19-rc2: known regressions

On Thu, Oct 19, 2006 at 09:17:54AM +0100, Russell King wrote:
> On Sun, Oct 15, 2006 at 02:42:10PM +0200, Adrian Bunk wrote:
> > On Sun, Oct 15, 2006 at 01:24:54PM +0100, Russell King wrote:
> > > On Sat, Oct 14, 2006 at 01:14:58PM +0200, Adrian Bunk wrote:
> > > > As usual, we are swamped with bug reports for regressions after -rc1.
> > > >
> > > > For an easier reading (and hoping linux-kernel might not eat the emails),
> > > > I've splitted the list of known regressions in three emails:
> > > > [1/3] known unfixed regressions
> > > > [2/3] knwon regressions with workarounds
> > > > [3/3] known regressions with patches
> > >
> > > There's a raft of ARM regressions as well (see
> > > http://armlinux.simtec.co.uk/kautobuild/2.6.19-rc2/index.html), mostly
> > > related to the IRQ changes, as well as this error:
> >
> > Thanks, I'll look at them before preparing the next version of my
> > regressions list.
> >
> > > sysctl_net.c:(.text+0x64a8c): undefined reference to `highest_possible_node_id'
> >
> > This problem already got an entry a few hours ago:
> >
> > Subject : undefined reference to highest_possible_node_id
> > References : http://lkml.org/lkml/2006/9/4/233
> > http://lkml.org/lkml/2006/10/15/11
> > Submitter : Olaf Hering <[email protected]>
> > Caused-By : Greg Banks <[email protected]>
> > commit 0f532f3861d2c4e5aa7dcd33fb18e9975eb28457
> > Status : unknown
>
> Looking at this commit and the mails, it was known on the 4th September
> that this patch caused build errors while this change was in -mm, yet it
> still found its way into mainline on 2nd October.
>
> Is anyone going to look at fixing this problem, or should we be asking
> for the commit to be reverted?

Since everyone seems intent at ignoring this issue, here's a patch to
try to solve it.

Probably will suffer from occasionally not being included in the kernel,
and therefore the function not exported for modules, but at least it's
a _lot_ better than the current utterly broken situation.

Signed-off-by: Russell King <[email protected]>

diff --git a/lib/Makefile b/lib/Makefile
index cf98fab..8845514 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -5,7 +5,7 @@ #
lib-y := ctype.o string.o vsprintf.o cmdline.o \
bust_spinlocks.o rbtree.o radix-tree.o dump_stack.o \
idr.o div64.o int_sqrt.o bitmap.o extable.o prio_tree.o \
- sha1.o irq_regs.o
+ sha1.o irq_regs.o nodemask.o

lib-$(CONFIG_MMU) += ioremap.o
lib-$(CONFIG_SMP) += cpumask.o
diff --git a/lib/cpumask.c b/lib/cpumask.c
index 7a2a73f..3a67dc5 100644
--- a/lib/cpumask.c
+++ b/lib/cpumask.c
@@ -43,19 +43,3 @@ int __any_online_cpu(const cpumask_t *ma
return cpu;
}
EXPORT_SYMBOL(__any_online_cpu);
-
-#if MAX_NUMNODES > 1
-/*
- * Find the highest possible node id.
- */
-int highest_possible_node_id(void)
-{
- unsigned int node;
- unsigned int highest = 0;
-
- for_each_node_mask(node, node_possible_map)
- highest = node;
- return highest;
-}
-EXPORT_SYMBOL(highest_possible_node_id);
-#endif
diff --git a/lib/nodemask.c b/lib/nodemask.c
new file mode 100644
index 0000000..6c49eb5
--- /dev/null
+++ b/lib/nodemask.c
@@ -0,0 +1,19 @@
+#include <linux/kernel.h>
+#include <linux/cpumask.h>
+#include <linux/module.h>
+
+#if MAX_NUMNODES > 1
+/*
+ * Find the highest possible node id.
+ */
+int highest_possible_node_id(void)
+{
+ unsigned int node;
+ unsigned int highest = 0;
+
+ for_each_node_mask(node, node_possible_map)
+ highest = node;
+ return highest;
+}
+EXPORT_SYMBOL(highest_possible_node_id);
+#endif

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core

2006-10-20 18:22:27

by Andrew Morton

[permalink] [raw]

Subject: Re: [0/3] 2.6.19-rc2: known regressions

On Fri, 20 Oct 2006 19:07:22 +0100
Russell King <[email protected]> wrote:

> > > Subject : undefined reference to highest_possible_node_id
> > > References : http://lkml.org/lkml/2006/9/4/233
> > > http://lkml.org/lkml/2006/10/15/11
> > > Submitter : Olaf Hering <[email protected]>
> > > Caused-By : Greg Banks <[email protected]>
> > > commit 0f532f3861d2c4e5aa7dcd33fb18e9975eb28457
> > > Status : unknown
> >
> > Looking at this commit and the mails, it was known on the 4th September
> > that this patch caused build errors while this change was in -mm, yet it
> > still found its way into mainline on 2nd October.
> >
> > Is anyone going to look at fixing this problem, or should we be asking
> > for the commit to be reverted?
>
> Since everyone seems intent at ignoring this issue, here's a patch to
> try to solve it.

I sent the below to Linus yesterday...

From: Andrew Morton <[email protected]>

Qooting Adrian:

- net/sunrpc/svc.c uses highest_possible_node_id()

- include/linux/nodemask.h says highest_possible_node_id() is
out-of-line #if MAX_NUMNODES > 1

- the out-of-line highest_possible_node_id() is in lib/cpumask.c

- lib/Makefile: lib-$(CONFIG_SMP) += cpumask.o
CONFIG_ARCH_DISCONTIGMEM_ENABLE=y, CONFIG_SMP=n, CONFIG_SUNRPC=y

-> highest_possible_node_id() is used in net/sunrpc/svc.c
CONFIG_NODES_SHIFT defined and > 0

-> include/linux/numa.h: MAX_NUMNODES > 1

-> compile error

The bug is not present on architectures where ARCH_DISCONTIGMEM_ENABLE
depends on NUMA (but m32r isn't the only affected architecture).

So move the function into page_alloc.c

Cc: Adrian Bunk <[email protected]>
Cc: Paul Jackson <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---

lib/cpumask.c | 16 ----------------
mm/page_alloc.c | 16 ++++++++++++++++
2 files changed, 16 insertions(+), 16 deletions(-)

diff -puN lib/cpumask.c~highest_possible_node_id-linkage-fix lib/cpumask.c
--- a/lib/cpumask.c~highest_possible_node_id-linkage-fix
+++ a/lib/cpumask.c
@@ -43,19 +43,3 @@ int __any_online_cpu(const cpumask_t *ma
return cpu;
}
EXPORT_SYMBOL(__any_online_cpu);
-
-#if MAX_NUMNODES > 1
-/*
- * Find the highest possible node id.
- */
-int highest_possible_node_id(void)
-{
- unsigned int node;
- unsigned int highest = 0;
-
- for_each_node_mask(node, node_possible_map)
- highest = node;
- return highest;
-}
-EXPORT_SYMBOL(highest_possible_node_id);
-#endif
diff -puN mm/page_alloc.c~highest_possible_node_id-linkage-fix mm/page_alloc.c
--- a/mm/page_alloc.c~highest_possible_node_id-linkage-fix
+++ a/mm/page_alloc.c
@@ -3120,3 +3120,19 @@ unsigned long page_to_pfn(struct page *p
EXPORT_SYMBOL(pfn_to_page);
EXPORT_SYMBOL(page_to_pfn);
#endif /* CONFIG_OUT_OF_LINE_PFN_TO_PAGE */
+
+#if MAX_NUMNODES > 1
+/*
+ * Find the highest possible node id.
+ */
+int highest_possible_node_id(void)
+{
+ unsigned int node;
+ unsigned int highest = 0;
+
+ for_each_node_mask(node, node_possible_map)
+ highest = node;
+ return highest;
+}
+EXPORT_SYMBOL(highest_possible_node_id);
+#endif
_

2006-10-20 18:30:20

by Kevin Radloff

[permalink] [raw]

Subject: Re: Linux 2.6.19-rc2

On 10/13/06, Linus Torvalds <[email protected]> wrote:
> Ok, it's a week since -rc1, so -rc2 is out there.

A bit behind, but booting still takes ages on my laptop as
libata/ata_piix tries to probe a device that isn't there (I reported
this previously against -rc1, but got no response):

Linux version 2.6.19-rc2 (root@farstrider) (gcc version 4.1.2 20061007
(prerelease) (Debian 4.1.1-16)) #1 PREEMPT Tue Oct 17 11:40:02 EDT
2006
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000ce000 - 00000000000d0000 (reserved)
BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003f6f0000 (usable)
BIOS-e820: 000000003f6f0000 - 000000003f6fb000 (ACPI data)
BIOS-e820: 000000003f6fb000 - 000000003f700000 (ACPI NVS)
BIOS-e820: 000000003f700000 - 0000000040000000 (reserved)
BIOS-e820: 00000000fec10000 - 00000000fec20000 (reserved)
BIOS-e820: 00000000ffb00000 - 00000000ffc00000 (reserved)
BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
1014MB LOWMEM available.
Entering add_active_range(0, 0, 259824) 0 entries of 256 used
Zone PFN ranges:
DMA 0 -> 4096
Normal 4096 -> 259824
early_node_map[1] active PFN ranges
0: 0 -> 259824
On node 0 totalpages: 259824
DMA zone: 32 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 4064 pages, LIFO batch:0
Normal zone: 1997 pages used for memmap
Normal zone: 253731 pages, LIFO batch:31
DMI 2.3 present.
ACPI: RSDP (v000 FUJ ) @ 0x000f5d80
ACPI: RSDT (v001 FUJ FJNB189 0x01070000 FUJ 0x00000100) @ 0x3f6f4c92
ACPI: FADT (v001 FUJ FJNB189 0x01070000 FUJ 0x00000100) @ 0x3f6faf8c
ACPI: SSDT (v001 FUJ FJNB189 0x01070000 INTL 0x20030522) @ 0x3f6fab42
ACPI: BOOT (v001 FUJ FJNB189 0x01070000 FUJ 0x00000100) @ 0x3f6faf64
ACPI: DSDT (v001 FUJ FJNB189 0x01070000 MSFT 0x0100000e) @ 0x00000000
ACPI: PM-Timer IO Port: 0xfc08
Allocating PCI resources starting at 50000000 (gap: 40000000:bec10000)
Detected 1100.104 MHz processor.
Built 1 zonelists. Total pages: 257795
Kernel command line: root=/dev/sda3 ro acpi_sleep=s3_bios
resume2=file:/dev/sda3:0x1f2df40
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
CPU 0 irqstacks, hard=b0348000 soft=b0347000
PID hash table entries: 4096 (order: 12, 16384 bytes)
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1027448k/1039296k available (1660k kernel code, 11372k
reserved, 525k data, 120k init, 0k highmem)
virtual kernel memory layout:
fixmap : 0xffff8000 - 0xfffff000 ( 28 kB)
vmalloc : 0xf0000000 - 0xffff6000 ( 255 MB)
lowmem : 0xb0000000 - 0xef6f0000 (1014 MB)
.init : 0xb0324000 - 0xb0342000 ( 120 kB)
.data : 0xb029f263 - 0xb0322a2c ( 525 kB)
.text : 0xb0100000 - 0xb029f263 (1660 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 2200.79 BogoMIPS (lpj=1100399)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: a7e9f9bf 00000000 00000000 00000000
00000180 00000000 00000000
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 1024K
CPU: After all inits, caps: a7e9f9bf 00000000 00000000 00000040
00000180 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Compat vDSO mapped to ffffe000.
CPU: Intel(R) Pentium(R) M processor 1100MHz stepping 05
Checking 'hlt' instruction... OK.
ACPI: Core revision 20060707
ACPI: setting ELCR to 0200 (from 0800)
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfd982, last bus=3
PCI: Using configuration type 1
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
Boot video device is 0000:00:02.0
PCI quirk: region fc00-fc7f claimed by ICH4 ACPI/GPIO/TCO
PCI quirk: region fc80-fcbf claimed by ICH4 GPIO
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: Transparent bridge - 0000:00:1e.0
PCI: Bus #03 (-#06) is hidden behind transparent bridge #01 (-#03)
(try 'pci=assign-busses')
Please report the result to linux-kernel to fix this permanently
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 9 10 11) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 9 10 11) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 7 9 10 *11)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB_._PRT]
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 8 devices
SCSI subsystem initialized
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0
PCI: Bus 2, cardbus bridge: 0000:01:0a.0
IO window: 00003400-000034ff
IO window: 00003800-000038ff
PREFETCH window: 50000000-51ffffff
MEM window: 56000000-57ffffff
PCI: Bus 3, cardbus bridge: 0000:01:0a.1
IO window: 00003c00-00003cff
IO window: 00001000-000010ff
PREFETCH window: 52000000-53ffffff
MEM window: 58000000-59ffffff
PCI: Bridge: 0000:00:1e.0
IO window: 3000-3fff
MEM window: d0200000-d02fffff
PREFETCH window: 50000000-53ffffff
PCI: Setting latency timer of device 0000:00:1e.0 to 64
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:01:0a.0[A] -> Link [LNKA] -> GSI 11 (level,
low) -> IRQ 11
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11
ACPI: PCI Interrupt 0000:01:0a.1[B] -> Link [LNKB] -> GSI 11 (level,
low) -> IRQ 11
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 7, 524288 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
Simple Boot Flag at 0x7f set to 0x1
SGI XFS with no debug enabled
io scheduler noop registered
io scheduler cfq registered (default)
ACPI: AC Adapter [AC] (on-line)
ACPI: Battery Slot [CMB1] (battery present)
ACPI: Battery Slot [CMB2] (battery absent)
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
ACPI: Lid Switch [LID]
ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected an Intel 855 Chipset.
agpgart: Detected 8060K stolen memory.
agpgart: AGP aperture is 128M @ 0xd8000000
libata version 2.00 loaded.
ata_piix 0000:00:1f.1: version 2.00ac6
PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:1f.1[A] -> Link [LNKC] -> GSI 11 (level,
low) -> IRQ 11
PCI: Setting latency timer of device 0000:00:1f.1 to 64
ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0x1810 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x1818 irq 15
scsi0 : ata_piix
ata1.00: ATA-6, max UDMA/100, 156301488 sectors: LBA
ata1.00: ata1: dev 0 multi count 16
ata1.00: configured for UDMA/100
scsi1 : ata_piix
ata2.00: ATAPI, max UDMA/33
ata2.01: qc timeout (cmd 0xa1)
ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
ata2: failed to recover some devices, retrying in 5 secs
ata2.01: qc timeout (cmd 0xa1)
ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
ata2: failed to recover some devices, retrying in 5 secs
ata2.01: qc timeout (cmd 0xa1)
ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
ata2: failed to recover some devices, retrying in 5 secs
ata2.00: configured for UDMA/33
scsi 0:0:0:0: Direct-Access ATA FUJITSU MHT2080A 0022 PQ: 0 ANSI: 5
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
sda: sda1 sda2 < sda5 > sda3
sd 0:0:0:0: Attached scsi disk sda
scsi 1:0:0:0: CD-ROM MATSHITA UJDA755 DVD/CDRW 1.00 PQ: 0 ANSI: 5

As is actually detected, there's a hard drive on the first channel and
a DVD-ROM/CDRW on the second channel.

00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV
Processor to I/O Controller (rev 02)
00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV
Processor to I/O Controller (rev 02)
00:00.3 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV
Processor to I/O Controller (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM
Integrated Graphics Device (rev 02)
00:02.1 Display controller: Intel Corporation 82852/855GM Integrated
Graphics Device (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M)
USB2 EHCI Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 83)
00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface
Bridge (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE
Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
SMBus Controller (rev 03)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03)
00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
AC'97 Modem Controller (rev 03)
01:0a.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ab)
01:0a.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ab)
01:0a.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 03)
01:0a.3 System peripheral: Ricoh Co Ltd R5C576 SD Bus Host Adapter (rev 01)
01:0a.4 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter
01:0c.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
01:0d.0 Ethernet controller: Atheros Communications, Inc. AR5212
802.11abg NIC (rev 01)

--
Kevin 'radsaq' Radloff
[email protected]
http://thesaq.com/

2006-10-20 18:32:09

[permalink] [raw]

Subject: Re: [0/3] 2.6.19-rc2: known regressions

On Fri, Oct 20, 2006 at 11:19:00AM -0700, Andrew Morton wrote:
> On Fri, 20 Oct 2006 19:07:22 +0100
> Russell King <[email protected]> wrote:
>
> > > > Subject : undefined reference to highest_possible_node_id
> > > > References : http://lkml.org/lkml/2006/9/4/233
> > > > http://lkml.org/lkml/2006/10/15/11
> > > > Submitter : Olaf Hering <[email protected]>
> > > > Caused-By : Greg Banks <[email protected]>
> > > > commit 0f532f3861d2c4e5aa7dcd33fb18e9975eb28457
> > > > Status : unknown
> > >
> > > Looking at this commit and the mails, it was known on the 4th September
> > > that this patch caused build errors while this change was in -mm, yet it
> > > still found its way into mainline on 2nd October.
> > >
> > > Is anyone going to look at fixing this problem, or should we be asking
> > > for the commit to be reverted?
> >
> > Since everyone seems intent at ignoring this issue, here's a patch to
> > try to solve it.
>
> I sent the below to Linus yesterday...

Ah, okay. Must not have poped out of the other side of Linus by 6am GMT
then. (We also seem to have non-working git snapshots again, so when I
looked at the ARM kautobuild it showed the same old errors.)

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core

2006-10-20 18:35:06

[permalink] [raw]

Subject: Re: [0/3] 2.6.19-rc2: known regressions

On Fri, 20 Oct 2006, Russell King wrote:
>
> Since everyone seems intent at ignoring this issue, here's a patch to
> try to solve it.

Heh. I just merged another one (through Andrew), so it _should_ be fixed
in my tree already. But thanks,

Linus

2006-10-20 18:54:17

[permalink] [raw]

Subject: Re: [0/3] 2.6.19-rc2: known regressions

On Fri, 20 Oct 2006, Russell King wrote:
>
> Ah, okay. Must not have poped out of the other side of Linus by 6am GMT
> then.

Yeah, I applied Andrew's patch-bomb just an hour or two ago.

> (We also seem to have non-working git snapshots again, so when I
> looked at the ARM kautobuild it showed the same old errors.)

Gaah. Remind me where the autobuild is again..

Linus

2006-10-20 18:59:53

[permalink] [raw]

Subject: Re: [0/3] 2.6.19-rc2: known regressions

On Fri, Oct 20, 2006 at 11:50:53AM -0700, Linus Torvalds wrote:
> On Fri, 20 Oct 2006, Russell King wrote:
> > Ah, okay. Must not have poped out of the other side of Linus by 6am GMT
> > then.
>
> Yeah, I applied Andrew's patch-bomb just an hour or two ago.

That explains why I hadn't seen it, and probably explains why there
hadn't been any git snapshots since Thursday morning (my time) - so
nothings actually broken. Ignore me! 8)

> > (We also seem to have non-working git snapshots again, so when I
> > looked at the ARM kautobuild it showed the same old errors.)
>
> Gaah. Remind me where the autobuild is again..

The main status page is at:
http://armlinux.simtec.co.uk/kautobuild/

You could argue that it should be able to run off the git tree itself -
I'll probably even agree with you, but kautobuild isn't my system.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core

2006-10-20 20:51:20

by Alan

[permalink] [raw]

Subject: Re: Linux 2.6.19-rc2

Ar Gwe, 2006-10-20 am 14:30 -0400, ysgrifennodd Kevin Radloff:
> On 10/13/06, Linus Torvalds <[email protected]> wrote:
> > Ok, it's a week since -rc1, so -rc2 is out there.
>
> A bit behind, but booting still takes ages on my laptop as
> libata/ata_piix tries to probe a device that isn't there (I reported
> this previously against -rc1, but got no response):

Probing is somewhat broken in 2.6.18 - something in the core code
changed as its upset quite a few drivers at once. One case causes
repeated errors and finally detection of an ATAPI device, the other
causes repeated errors and then failure when no device is present but
takes a few minutes and keeps IRQs locked off for long periods. Both
appear to be fallouts from the new EH code.

Alan

2006-10-20 21:10:22

[permalink] [raw]

Subject: Re: [0/3] 2.6.19-rc2: known regressions

On Fri, 20 Oct 2006, Russell King wrote:
> >
> > Gaah. Remind me where the autobuild is again..
>
> The main status page is at:
> http://armlinux.simtec.co.uk/kautobuild/

Ahh. At least _most_ builds seem ok. I only looked at the first failing
one, and it _seems_ to be due to "drivers/usb/gadget/pxa2xx_udc.c" which
still includes <asm/irq.h> rather than <linux/irq.h>.

Maybe. I could do the trivial fix myself, but there have been people who
have ARM build environments, so maybe somebody who can actually verify
whether that one-liner fixes things (or whether there is something else
hiding) can do that and send me the patch.

[ Although I've gotten so much email lately that maybe I already missed
that patch. Ahh, the joys of SCM discussions ;) ]

Linus

2006-10-20 21:12:46

by Jeff Garzik

[permalink] [raw]

Subject: Re: Linux 2.6.19-rc2

Alan Cox wrote:
> Ar Gwe, 2006-10-20 am 14:30 -0400, ysgrifennodd Kevin Radloff:
>> On 10/13/06, Linus Torvalds <[email protected]> wrote:
>>> Ok, it's a week since -rc1, so -rc2 is out there.
>> A bit behind, but booting still takes ages on my laptop as
>> libata/ata_piix tries to probe a device that isn't there (I reported
>> this previously against -rc1, but got no response):
>
> Probing is somewhat broken in 2.6.18 - something in the core code
> changed as its upset quite a few drivers at once. One case causes
> repeated errors and finally detection of an ATAPI device, the other
> causes repeated errors and then failure when no device is present but
> takes a few minutes and keeps IRQs locked off for long periods. Both
> appear to be fallouts from the new EH code.

There are definitely warts related to the new EH stuff, but specifically
for SATA + ata_piix, it has been a long hard road of trying various
probing mechanisms. Tejun has some patches that revert all the PCS work
and rewinds back to original SATA ata_piix probing, in -mm for testing.

If testing feedback proves positive, let's go ahead and fast-track that
up the line.

With ata_piix, I would worry more about PCS register follies than core
libata. Users can try the module option force_pcs=[0|1|2] to experiment
and see if any of the three possibilities improves their boot.

Jeff

2006-10-22 12:24:06

[permalink] [raw]

Subject: 2.6.19-rc2: known unfixed regressions (v3)

This email lists some known unfixed regressions in 2.6.19-rc2 compared
to 2.6.18 that are not yet fixed Linus' tree.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.

Subject : ppc prep boot hang
References : http://lkml.org/lkml/2006/10/14/58
Submitter : Meelis Roos <[email protected]>
Status : unknown

Subject : X60s: BUG()s, lose ACPI events after suspend/resume
References : http://lkml.org/lkml/2006/10/10/39
Submitter : Martin Lorenz <[email protected]>
Status : unknown

Subject : T60 stops triggering any ACPI events
References : http://lkml.org/lkml/2006/10/4/425
http://lkml.org/lkml/2006/10/16/262
Submitter : "Michael S. Tsirkin" <[email protected]>
Status : unknown

Subject : CONFIG_X86_VOYAGER=y, CONFIG_SMP=n compile error
References : http://lkml.org/lkml/2006/10/7/51
Submitter : Jesper Juhl <[email protected]>
Caused-By : David Howells <[email protected]>
commit 7d12e780e003f93433d49ce78cfedf4b4c52adc5
Status : unknown

Subject : CONFIG_X86_VISWS=y, CONFIG_SMP=n compile error
References : http://lkml.org/lkml/2006/10/7/51
Submitter : Jesper Juhl <[email protected]>
Caused-By : David Howells <[email protected]>
commit 7d12e780e003f93433d49ce78cfedf4b4c52adc5
Status : unknown

Subject : sata-via doesn't detect anymore disks attached to VIA vt6421
References : http://bugzilla.kernel.org/show_bug.cgi?id=7255
Submitter : Thierry Vignaud <[email protected]>
Status : unknown

Subject : SMP x86_64 boot problem
References : http://lkml.org/lkml/2006/9/28/330
http://lkml.org/lkml/2006/10/5/289
Submitter : [email protected]
Status : submitter was asked to git bisect
result of bisecting seems to be wrong

Subject : unable to rip cd
References : http://lkml.org/lkml/2006/10/13/100
Submitter : Alex Romosan <[email protected]>
Status : unknown

Subject : cpufreq not working on AMD K8
References : http://lkml.org/lkml/2006/10/10/114
Submitter : Christian <[email protected]>
Handled-By : Mark Langsdorf <[email protected]>
Status : Mark is investigating

Subject : MSI errors during boot (CONFIG_PCI_MULTITHREAD_PROBE)
References : http://lkml.org/lkml/2006/10/16/291
Submitter : Stephen Hemminger <[email protected]>
Handled-By : Greg KH <[email protected]>
Status : Greg is working on a fix

Subject : snd-hda-intel <-> forcedeth MSI problem
References : http://lkml.org/lkml/2006/10/5/40
http://lkml.org/lkml/2006/10/7/164
Submitter : Prakash Punnoor <[email protected]>
Status : patches are being discussed

2006-10-22 13:23:42

by Andi Kleen

[permalink] [raw]

Subject: Re: 2.6.19-rc2: known unfixed regressions (v3)

On Sunday 22 October 2006 14:23, Adrian Bunk wrote:

> Subject : SMP x86_64 boot problem
> References : http://lkml.org/lkml/2006/9/28/330
> http://lkml.org/lkml/2006/10/5/289
> Submitter : [email protected]
> Status : submitter was asked to git bisect
> result of bisecting seems to be wrong

Does this still happen with 2.6.19rc2-latestGIT ?

-Andi

2006-10-22 14:46:58

by Gene Heskett

[permalink] [raw]

Subject: Re: 2.6.19-rc2: known unfixed regressions (v3)

On Sunday 22 October 2006 08:23, Adrian Bunk wrote:
>This email lists some known unfixed regressions in 2.6.19-rc2 compared
>to 2.6.18 that are not yet fixed Linus' tree.
>
[...]
>
>Subject : unable to rip cd
>References : http://lkml.org/lkml/2006/10/13/100
>Submitter : Alex Romosan <[email protected]>
>Status : unknown

FWIW Alex, I just ripped track 2 of a Trace Adkins CD using grip and
cdparanoia, then listened to the track in mplayer, while running
2.6.19-rc2. No problem at all. This is however, an older FC2 system, so
I'd be inclined to point the finger at cdparanoia's latest version. Mine
hasn't been updated for quite a while. I have these installed:

cdparanoia-alpha9.8-20.1
cdparanoia-libs-alpha9.8-20.1
cdparanoia-devel-alpha9.8-20.1

--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

2006-10-22 15:17:47

by Alex Romosan

[permalink] [raw]

Subject: Re: 2.6.19-rc2: known unfixed regressions (v3)

Gene Heskett <[email protected]> writes:

> On Sunday 22 October 2006 08:23, Adrian Bunk wrote:
>>This email lists some known unfixed regressions in 2.6.19-rc2 compared
>>to 2.6.18 that are not yet fixed Linus' tree.
>>
> [...]
>>
>>Subject : unable to rip cd
>>References : http://lkml.org/lkml/2006/10/13/100
>>Submitter : Alex Romosan <[email protected]>
>>Status : unknown
>
> FWIW Alex, I just ripped track 2 of a Trace Adkins CD using grip and
> cdparanoia, then listened to the track in mplayer, while running
> 2.6.19-rc2. No problem at all. This is however, an older FC2 system, so
> I'd be inclined to point the finger at cdparanoia's latest version. Mine
> hasn't been updated for quite a while. I have these installed:
>
> cdparanoia-alpha9.8-20.1
> cdparanoia-libs-alpha9.8-20.1
> cdparanoia-devel-alpha9.8-20.1

the system doesn't lock up all the time, but every time i start ripping
i get this in syslog:

Oct 22 08:08:16 trinculo kernel: hdc: write_intr: wrong transfer direction!

which didn't use to happen before 2.6.19-rc2 (the lockups did).
anyway, i just gave it another try, grip wasn't able to rip the cd but
i was able to eject the cd from the drive and then abort execution. i
am using cdparanoia that came with grip, and this is a very old
version (2.96, the last before they switched to gnome). i also tried
with the recent version of cdparanoia but the same thing happens.

--alex--

--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |

2006-10-23 00:55:50

by Gene Heskett

[permalink] [raw]

Subject: Re: 2.6.19-rc2: known unfixed regressions (v3)

On Sunday 22 October 2006 11:17, Alex Romosan wrote:
>Gene Heskett <[email protected]> writes:
>> On Sunday 22 October 2006 08:23, Adrian Bunk wrote:
>>>This email lists some known unfixed regressions in 2.6.19-rc2 compared
>>>to 2.6.18 that are not yet fixed Linus' tree.
>>
>> [...]
>>
>>>Subject : unable to rip cd
>>>References : http://lkml.org/lkml/2006/10/13/100
>>>Submitter : Alex Romosan <[email protected]>
>>>Status : unknown
>>
>> FWIW Alex, I just ripped track 2 of a Trace Adkins CD using grip and
>> cdparanoia, then listened to the track in mplayer, while running
>> 2.6.19-rc2. No problem at all. This is however, an older FC2 system,
>> so I'd be inclined to point the finger at cdparanoia's latest version.
>> Mine hasn't been updated for quite a while. I have these installed:
>>
>> cdparanoia-alpha9.8-20.1
>> cdparanoia-libs-alpha9.8-20.1
>> cdparanoia-devel-alpha9.8-20.1
>
>the system doesn't lock up all the time, but every time i start ripping
>i get this in syslog:
>
>Oct 22 08:08:16 trinculo kernel: hdc: write_intr: wrong transfer
> direction!
>
>which didn't use to happen before 2.6.19-rc2 (the lockups did).
>anyway, i just gave it another try, grip wasn't able to rip the cd but
>i was able to eject the cd from the drive and then abort execution. i
>am using cdparanoia that came with grip, and this is a very old
>version (2.96, the last before they switched to gnome). i also tried
>with the recent version of cdparanoia but the same thing happens.
>
My grip is a bit newer than that, 3.20 I believe.

>--alex--

--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

2006-10-23 11:32:12

by Andrey Panin

[permalink] [raw]

Subject: Re: 2.6.19-rc2: known unfixed regressions (v3)

On 295, 10 22, 2006 at 02:23:55PM +0200, Adrian Bunk wrote:
> This email lists some known unfixed regressions in 2.6.19-rc2 compared
> to 2.6.18 that are not yet fixed Linus' tree.
>
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a breakage or I'm considering you in any other way possibly
> involved with one or more of these issues.
>
> Due to the huge amount of recipients, please trim the Cc when answering.
>
>
> Subject : CONFIG_X86_VISWS=y, CONFIG_SMP=n compile error
> References : http://lkml.org/lkml/2006/10/7/51
> Submitter : Jesper Juhl <[email protected]>
> Caused-By : David Howells <[email protected]>
> commit 7d12e780e003f93433d49ce78cfedf4b4c52adc5
> Status : unknown

Attached patch fixes this problem.

--
Andrey Panin | Linux and UNIX system administrator
[email protected] | PGP key: wwwkeys.pgp.net

Attachments:

(No filename) (0.00 B)
signature.asc (189.00 B)
Digital signature Download all attachments

2006-10-23 15:28:32

by Meelis Roos

[permalink] [raw]

Subject: Re: 2.6.19-rc2: known unfixed regressions (v3)

> Subject : ppc prep boot hang
> References : http://lkml.org/lkml/2006/10/14/58
> Submitter : Meelis Roos <[email protected]>
> Status : unknown

Seems to be fixed in 2.6.19-rc2+git as of 20061022.

--
Meelis Roos

2006-10-23 20:59:06

[permalink] [raw]

Subject: Re: 2.6.19-rc2: known unfixed regressions (v3)

On Mon, Oct 23, 2006 at 06:20:18PM +0300, Meelis Roos wrote:
> >Subject : ppc prep boot hang
> >References : http://lkml.org/lkml/2006/10/14/58
> >Submitter : Meelis Roos <[email protected]>
> >Status : unknown
>
> Seems to be fixed in 2.6.19-rc2+git as of 20061022.

Thanks for the information, I've removed it from my list.

> Meelis Roos

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

2006-10-24 14:57:45

by Stefan Richter

[permalink] [raw]

Subject: Re: 2.6.19-rc2: known unfixed regressions (v3)

Hi Adrian,

here is another one:

Subject : [ohci1394 on PPC_PMAC] pci_set_power_state() failure and breaking suspend
References : http://lkml.org/lkml/2006/10/24/13
Submitter : Benjamin Herrenschmidt <[email protected]>
Caused-By : Stefan Richter <[email protected]>
commit ea6104c22468239083857fa07425c312b1ecb424
Status : looking for answer when to ignore return code of pci_set_power_state

--
Stefan Richter
-=====-=-==- =-=- ==---
http://arcgraph.de/sr/

2006-10-24 15:07:09

by Michael S. Tsirkin

[permalink] [raw]

Subject: Re: 2.6.19-rc2: known unfixed regressions (v3)

Quoting r. Adrian Bunk <[email protected]>:
> Subject: 2.6.19-rc2: known unfixed regressions (v3)
>
> This email lists some known unfixed regressions in 2.6.19-rc2 compared
> to 2.6.18 that are not yet fixed Linus' tree.
>
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a breakage or I'm considering you in any other way possibly
> involved with one or more of these issues.
>
> Due to the huge amount of recipients, please trim the Cc when answering.
>

skip, hope I didn't trim too much.

>
> Subject : T60 stops triggering any ACPI events
> References : http://lkml.org/lkml/2006/10/4/425
> http://lkml.org/lkml/2006/10/16/262
> Submitter : "Michael S. Tsirkin" <[email protected]>
> Status : unknown

Just retested with 2.6.19-rc3 - it's still there:
e.g. after I do a full kernel compile, my T60 stops triggering any ACPI events:
tail -f /var/log/acpid does not show anything, even on Fn/F4 which is supposed
to be always enabled. Restarting the acpid doesn't do anything either - ACPI
starts working again, for a while, only after reboot.

Works fine in 2.6.18 ( + this patch http://lkml.org/lkml/2006/7/20/56).

--
MST

2006-10-24 17:27:30

by Prakash Punnoor

[permalink] [raw]

Subject: Re: 2.6.19-rc2: known unfixed regressions (v3)

Am Sonntag 22 Oktober 2006 14:23 schrieben Sie:
> Subject : snd-hda-intel <-> forcedeth MSI problem
> References : http://lkml.org/lkml/2006/10/5/40
> http://lkml.org/lkml/2006/10/7/164
> Submitter : Prakash Punnoor <[email protected]>
> Status : patches are being discussed

2.6.19-rc3 contains a work-around. Case closed. :-)
--
(?= =?)
//\ Prakash Punnoor /\\
V_/ \_V

Attachments:

(No filename) (426.00 B)
(No filename) (189.00 B)
Download all attachments

2006-10-24 19:48:45

[permalink] [raw]

Subject: Re: 2.6.19-rc2: known unfixed regressions (v3)

On Tue, Oct 24, 2006 at 04:57:43PM +0200, Stefan Richter wrote:
> Hi Adrian,
>
> here is another one:
>
> Subject : [ohci1394 on PPC_PMAC] pci_set_power_state() failure and breaking suspend
> References : http://lkml.org/lkml/2006/10/24/13
> Submitter : Benjamin Herrenschmidt <[email protected]>
> Caused-By : Stefan Richter <[email protected]>
> commit ea6104c22468239083857fa07425c312b1ecb424
> Status : looking for answer when to ignore return code of pci_set_power_state

Thanks, added.

> Stefan Richter

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

2006-10-24 19:58:31

[permalink] [raw]

Subject: Re: 2.6.19-rc2: known unfixed regressions (v3)

On Tue, Oct 24, 2006 at 07:27:48PM +0200, Prakash Punnoor wrote:
> Am Sonntag 22 Oktober 2006 14:23 schrieben Sie:
> > Subject : snd-hda-intel <-> forcedeth MSI problem
> > References : http://lkml.org/lkml/2006/10/5/40
> > http://lkml.org/lkml/2006/10/7/164
> > Submitter : Prakash Punnoor <[email protected]>
> > Status : patches are being discussed
>
> 2.6.19-rc3 contains a work-around. Case closed. :-)

Thanks for the confirmation.

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

2006-10-25 08:28:30

by Pavel Machek

[permalink] [raw]

Subject: Re: 2.6.19-rc2: known unfixed regressions (v3)

On Tue 2006-10-24 17:00:51, Michael S. Tsirkin wrote:
> Quoting r. Adrian Bunk <[email protected]>:
> > Subject: 2.6.19-rc2: known unfixed regressions (v3)
> >
> > This email lists some known unfixed regressions in 2.6.19-rc2 compared
> > to 2.6.18 that are not yet fixed Linus' tree.
> >
> > If you find your name in the Cc header, you are either submitter of one
> > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > of you caused a breakage or I'm considering you in any other way possibly
> > involved with one or more of these issues.
> >
> > Due to the huge amount of recipients, please trim the Cc when answering.
> >
>
> skip, hope I didn't trim too much.
>
> >
> > Subject : T60 stops triggering any ACPI events
> > References : http://lkml.org/lkml/2006/10/4/425
> > http://lkml.org/lkml/2006/10/16/262
> > Submitter : "Michael S. Tsirkin" <[email protected]>
> > Status : unknown
>
> Just retested with 2.6.19-rc3 - it's still there:
> e.g. after I do a full kernel compile, my T60 stops triggering any ACPI events:
> tail -f /var/log/acpid does not show anything, even on Fn/F4 which is supposed
> to be always enabled. Restarting the acpid doesn't do anything either - ACPI
> starts working again, for a while, only after reboot.
>
> Works fine in 2.6.18 ( + this patch http://lkml.org/lkml/2006/7/20/56).

Bugzilla.kernel.org, assign it to acpi people...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

2006-10-25 08:38:53

by Michael S. Tsirkin

[permalink] [raw]

Subject: Re: 2.6.19-rc2: known unfixed regressions (v3)

Quoting r. Pavel Machek <[email protected]>:
> > >
> > > Subject : T60 stops triggering any ACPI events
> > > References : http://lkml.org/lkml/2006/10/4/425
> > > http://lkml.org/lkml/2006/10/16/262
> > > Submitter : "Michael S. Tsirkin" <[email protected]>
> > > Status : unknown
> >
> > Just retested with 2.6.19-rc3 - it's still there:
> > e.g. after I do a full kernel compile, my T60 stops triggering any ACPI events:
> > tail -f /var/log/acpid does not show anything, even on Fn/F4 which is supposed
> > to be always enabled. Restarting the acpid doesn't do anything either - ACPI
> > starts working again, for a while, only after reboot.
> >
> > Works fine in 2.6.18 ( + this patch http://lkml.org/lkml/2006/7/20/56).
>
> Bugzilla.kernel.org, assign it to acpi people...

Already done, http://bugzilla.kernel.org/show_bug.cgi?id=7408

--
MST

2006-10-29 10:33:29

[permalink] [raw]

Subject: Re: [0/3] 2.6.19-rc2: known regressions

Hi

I did search the archives, but it does seem to be the new one. r8169
network driver introduced in 2.6.19-rcX a set_mac_address function, which
doesn't work for me. It should resolve the bugreport
http://bugzilla.kernel.org/show_bug.cgi?id=6032 but, as you see from the
last comment from the original reporter and from my following comment, it
doesn't seem to. I think, it should either be fixed or reverted. My
test-system, was a ppc NAS (KuroboxHG):

0000:00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 128 (8000ns min, 16000ns max), Cache Line Size: 0x08 (32 bytes) Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at bfff00 [size=256]
Region 1: Memory at bfffff00 (32-bit, non-prefetchable) [size=256]
Capabilities: [dc] Power Management version 0
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Thanks
Guennadi
---
Guennadi Liakhovetski

2006-10-29 20:21:36

[permalink] [raw]

Subject: Re: [0/3] 2.6.19-rc2: known regressions

On Sun, 29 Oct 2006, Guennadi Liakhovetski wrote:
>
> I did search the archives, but it does seem to be the new one. r8169
> network driver introduced in 2.6.19-rcX a set_mac_address function, which
> doesn't work for me. It should resolve the bugreport
> http://bugzilla.kernel.org/show_bug.cgi?id=6032 but, as you see from the
> last comment from the original reporter and from my following comment, it
> doesn't seem to. I think, it should either be fixed or reverted. My
> test-system, was a ppc NAS (KuroboxHG):

Can you please test the things that Francois asks you to test in the last
comment?

That said, it does appear that the patch breaks things for some people,
and the upsides seem very limited - only relevant when somebody tries to
change the MAC address, which is not a very normal thing to do anyway.

So maybe reverting it is the right thing to do. Guennadi, can you confirm
that it is commit a2b98a69 ("r8169: mac address change support") that
breaks it, and that reverting just that one commit fixes things for you?

But please check the things that are suggested in the bugzilla entry
first.

Francois? Jeff?

Linus

2006-10-29 22:38:42

[permalink] [raw]

Subject: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

Linus Torvalds <[email protected]> :
[regression related to r8169 MAC address change]
> Francois ? Jeff ?

Go revert it.

Despite what I claimed, I can not find a third-party confirmation by email
that it works elsewhere.

It would probably be enough to remove the call to __rtl8169_set_mac_addr()
in rtl8169_hw_start() though.

In place of the test suggested in bugzilla, I'd rather see Guennadi test
the thing below (acked on netdev by the initial victim if someone wonders
why it has not changed the status of bugzilla so far):

>From f092d907f78e81846dfaf1008a6409c3c4b58f27 Mon Sep 17 00:00:00 2001
From: Francois Romieu <[email protected]>
Date: Sat, 21 Oct 2006 21:07:36 +0200
Subject: [PATCH] r8169: perform a PHY reset before any other operation at boot time

Realtek's 8139/810x (0x8136) PCI-E comes with a touchy PHY.
A big heavy reset seems to calm it down.

Fix for http://bugzilla.kernel.org/show_bug.cgi?id=7378.

Signed-off-by: Francois Romieu <[email protected]>
Signed-off-by: Darren Salt <[email protected]>
---
drivers/net/r8169.c | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index f1c7575..927fc17 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1440,6 +1440,22 @@ static void rtl8169_release_board(struct
free_netdev(dev);
}

+static void rtl8169_phy_reset(struct net_device *dev,
+ struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+ int i;
+
+ tp->phy_reset_enable(ioaddr);
+ for (i = 0; i < 100; i++) {
+ if (!tp->phy_reset_pending(ioaddr))
+ return;
+ msleep(1);
+ }
+ if (netif_msg_link(tp))
+ printk(KERN_ERR "%s: PHY reset failed.\n", dev->name);
+}
+
static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
@@ -1468,6 +1484,8 @@ static void rtl8169_init_phy(struct net_

rtl8169_link_option(board_idx, &autoneg, &speed, &duplex);

+ rtl8169_phy_reset(dev, tp);
+
rtl8169_set_speed(dev, autoneg, speed, duplex);

if ((RTL_R8(PHYstatus) & TBI_Enable) && netif_msg_link(tp))
--
1.4.2.4

2006-10-30 00:20:50

[permalink] [raw]

Subject: Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

On Sun, 29 Oct 2006, Francois Romieu wrote:

> Linus Torvalds <[email protected]> :
> [regression related to r8169 MAC address change]
> > Francois ? Jeff ?
>
> Go revert it.
>
> Despite what I claimed, I can not find a third-party confirmation by email
> that it works elsewhere.
>
> It would probably be enough to remove the call to __rtl8169_set_mac_addr()
> in rtl8169_hw_start() though.
>
> In place of the test suggested in bugzilla, I'd rather see Guennadi test
> the thing below (acked on netdev by the initial victim if someone wonders
> why it has not changed the status of bugzilla so far):

AFAIU, you wanted it applied on the top of the "non-working" kernel
(2.6.19-rc2-ish)? No, it didn't work. And, worse yet, I think, it is after
testing that patch that the interface got into a state, when netconsole
worked, ping worked, but ssh didn't. A poweroff was needed to recover. In
case you still need it, here's the info you requested:

00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 128 (8000ns min, 16000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at febfff00 [size=256]
Region 1: Memory at bffffc00 (32-bit, non-prefetchable) [size=256]
Capabilities: [dc] Power Management version 0
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: ec 10 69 81 17 00 b0 02 10 00 00 02 08 80 00 00
10: 01 ff bf 00 00 fc ff bf 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 dc 00 00 00 00 00 00 00 10 01 20 40

dmesg when it didn't work (I do use netconsole, don't think it matters?):

r8169 Gigabit Ethernet driver 2.2LK loaded
eth0: RTL8169s/8110s at 0xc9004c00, 00:0d:0b:99:44:70, IRQ 16
netconsole: device eth0 not up yet, forcing it
r8169: eth0: link down
r8169: eth0: link up

The same when it's working.

Yes, just commenting out the line

__rtl8169_set_mac_addr(dev, ioaddr);

fixes it (without the patch from your previous email).

Thanks
Guennadi
---
Guennadi Liakhovetski

2006-10-30 12:06:59

[permalink] [raw]

Subject: Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

Guennadi Liakhovetski <[email protected]> :
[...]
> AFAIU, you wanted it applied on the top of the "non-working" kernel
> (2.6.19-rc2-ish)?

No. Please apply it on top of a 2.6.19-rc3 where the mac address change
feature has been reverted (or where __rtl8169_set_mac_addr has been
commented out at your option).

[...]
> dmesg when it didn't work (I do use netconsole, don't think it matters?):

I'd rather fix everything else without netconsole first. It will make
my life simpler.

--
Ueimor

2006-10-30 13:03:03

by Oleg Verych

[permalink] [raw]

Subject: Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

On 2006-10-29, Francois Romieu wrote:
>
> Linus Torvalds <[email protected]> :
> [regression related to r8169 MAC address change]
>> Francois ? Jeff ?
>
> Go revert it.
>
> Despite what I claimed, I can not find a third-party confirmation by email
> that it works elsewhere.

It works for me:
,--
|root@flower:/home/olecom# ip l set eth0 addr 00:00:00:00:00:02
|root@flower:/home/olecom# ip l set eth0 addr 00:00:00:00:00:03
|root@flower:/home/olecom# ip l set eth0 addr 00:00:00:00:00:04
|root@flower:/home/olecom# ip l set eth0 addr 04:44:44:44:44:04
|root@flower:/home/olecom# ip l show
|1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
| link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
| 2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
| link/ether 04:44:44:44:44:04 brd ff:ff:ff:ff:ff:ff
|root@flower:/home/olecom# lspci -v | grep Realtek
| 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
|RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
|root@flower:/home/olecom#
|root@flower:/home/olecom# uname -a
|Linux flower 2.6.19-rc2-vanilla-ai #4 SMP PREEMPT Tue Oct 17 02:19:16
|UTC 2006 x86_64 GNU/Linux
|root@flower:/home/olecom#
`--
____

2006-10-30 22:08:44

[permalink] [raw]

Subject: Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

On Mon, 30 Oct 2006, Guennadi Liakhovetski wrote:

> Ok, with just __rtl8169_set_mac_addr disabled it works. With netconsole
> disabled, and your phy_reset patch applied it seems to still work. The

The "seems" above was the key word. Once again I had a case, when after
re-compiling the kernel again with the disabled call to
__rtl8169_set_mac_addr only ping worked. And a power-off was required to
recover. So, that phy_reset doesn't seem to be very safe either.

Thanks
Guennadi
---
Guennadi Liakhovetski

2006-10-30 22:38:11

[permalink] [raw]

Subject: Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

On Mon, 30 Oct 2006, Francois Romieu wrote:

> Guennadi Liakhovetski <[email protected]> :
> [...]
> > AFAIU, you wanted it applied on the top of the "non-working" kernel
> > (2.6.19-rc2-ish)?
>
> No. Please apply it on top of a 2.6.19-rc3 where the mac address change
> feature has been reverted (or where __rtl8169_set_mac_addr has been
> commented out at your option).

Ok, with just __rtl8169_set_mac_addr disabled it works. With netconsole
disabled, and your phy_reset patch applied it seems to still work. The
printk

+ printk(KERN_ERR "%s: PHY reset failed.\n", dev->name);

doesn't get printed. If I uncomment __rtl8169_set_mac_addr it stops
working again. What does it tell us about the original set_mac_address
problem?

I haven't said it's an on-board chip, not a plug-in card. Don't know how
setting the mac address worked in your configuration, but if it is storred
in a prom, maybe it is just missing on my board?

The kernel is not 2.6.19-rc3 either. It is a clone of the powerpc git some
time shortly after 2.6.19-rc2.

Thanks
Guennadi
---
Guennadi Liakhovetski

2006-10-30 23:30:29

[permalink] [raw]

Subject: Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

Guennadi Liakhovetski <[email protected]> :
[...]
> doesn't get printed. If I uncomment __rtl8169_set_mac_addr it stops
> working again. What does it tell us about the original set_mac_address
> problem?

Probably that it is issued too early/bluntly. I'll redo it later.

[...]
> The kernel is not 2.6.19-rc3 either. It is a clone of the powerpc git some
> time shortly after 2.6.19-rc2.

You miss 73f5e28b336772c4b08ee82e5bf28ab872898ee1 and
733b736c91dd2c556f35dffdcf77e667cf10cefc. It should not matter.

--
Ueimor

2006-10-30 23:50:05

[permalink] [raw]

Subject: Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

Guennadi Liakhovetski <[email protected]> :
[...]
> The "seems" above was the key word. Once again I had a case, when after
> re-compiling the kernel again with the disabled call to
> __rtl8169_set_mac_addr only ping worked. And a power-off was required to
> recover. So, that phy_reset doesn't seem to be very safe either.

Can you replace phy_reset by the patch below and try it twice ?

It's interesting to know if it does not always behave the same.

diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index f1c7575..4b05dea 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -570,8 +570,8 @@ static void rtl8169_xmii_reset_enable(vo
{
unsigned int val;

- val = (mdio_read(ioaddr, MII_BMCR) | BMCR_RESET) & 0xffff;
- mdio_write(ioaddr, MII_BMCR, val);
+ mdio_write(ioaddr, MII_BMCR, BMCR_RESET);
+ val = mdio_read(ioaddr, MII_BMCR);
}

static void rtl8169_check_link_status(struct net_device *dev,
@@ -1440,6 +1440,22 @@ static void rtl8169_release_board(struct
free_netdev(dev);
}

+static void rtl8169_phy_reset(struct net_device *dev,
+ struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+ int i;
+
+ tp->phy_reset_enable(ioaddr);
+ for (i = 0; i < 100; i++) {
+ if (!tp->phy_reset_pending(ioaddr))
+ return;
+ msleep(1);
+ }
+ if (netif_msg_link(tp))
+ printk(KERN_ERR "%s: PHY reset failed.\n", dev->name);
+}
+
static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
@@ -1468,6 +1484,8 @@ static void rtl8169_init_phy(struct net_

rtl8169_link_option(board_idx, &autoneg, &speed, &duplex);

+ rtl8169_phy_reset(dev, tp);
+
rtl8169_set_speed(dev, autoneg, speed, duplex);

if ((RTL_R8(PHYstatus) & TBI_Enable) && netif_msg_link(tp))

2006-10-31 19:02:46

[permalink] [raw]

Subject: Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

On Tue, 31 Oct 2006, Francois Romieu wrote:

> Guennadi Liakhovetski <[email protected]> :
> [...]
> > The "seems" above was the key word. Once again I had a case, when after
> > re-compiling the kernel again with the disabled call to
> > __rtl8169_set_mac_addr only ping worked. And a power-off was required to
> > recover. So, that phy_reset doesn't seem to be very safe either.
>
> Can you replace phy_reset by the patch below and try it twice ?
>
> It's interesting to know if it does not always behave the same.

Well, with that one I booted 3 times, all 3 times it worked. I'll leave it
in to see if it ever fails. So, what does it tell us about the
set_mac_address thing?

Thanks
Guennadi
---
Guennadi Liakhovetski

2006-10-31 23:15:08

[permalink] [raw]

Subject: Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

Guennadi Liakhovetski <[email protected]> :
[...]
> Well, with that one I booted 3 times, all 3 times it worked. I'll leave it

Thanks.

Let's cross fingers.

> in to see if it ever fails. So, what does it tell us about the
> set_mac_address thing?

It tells nothing more about the set_mac_address thing. If people need
MAC address change support, I can surely hack something and keep a
patch for future reference. Imho it is anything but 2.6.19 material
though.

The patch that I sent to you on 2006/10/29 was enough to fix the link
detection issues experienced with the 0x8136 chipset (1. Darren Salt
on netdev {25/26/31}/08/2006 and {21/22}/10/2006, 2. Syed Azam on BZ,
see http://bugzilla.kernel.org/show_bug.cgi?id=7378).

Your computer was good at spotting issues with the MAC address stuff,
so it was the perfect candidate to test pending fixes for different
problems. As you noticed, it was not exactly safe to feed the MII
control register with some potentially uninitialized stuff, whence
the patch from yesterday.

It remains to be seen if:
- it still does the job for the 0x8136
- it does not induce new regressions in existing 8169

o Darren and Syed, are your 0x8136 still happy with the patch
0001-r8169-perform-a-PHY-reset-before-any-other-operation-at-boot-time.txt
at http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.19-rc4/r8169
on top of 2.6.19-rc4 ?

o Darren, still ok to keep your S-o-b in it ?

o Could the r8169 users out there check that the same patch does not add
new regressions to their favorite 2.6.19-rc4 ?

o Lennert, can you apply the two patches
- 0001-r8169-perform-a-PHY-reset-before-any-other-operation-at-boot-time.txt
- 0002-r8169-more-magic.txt
at http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.19-rc4/r8169 against
2.6.19-rc4 (2.6.19-rc4 reverted the MAC address changes) and see if the
n2100 board still needs to remove the SYSErr handler ?

--
Ueimor

2006-10-31 23:38:18

[permalink] [raw]

Subject: Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

On Wed, 1 Nov 2006, Francois Romieu wrote:

> Guennadi Liakhovetski <[email protected]> :
>
> > in to see if it ever fails. So, what does it tell us about the
> > set_mac_address thing?
>
> It tells nothing more about the set_mac_address thing. If people need
> MAC address change support, I can surely hack something and keep a
> patch for future reference. Imho it is anything but 2.6.19 material
> though.

Aha, ok, thanks. Just noticed that the set_mac_address has been reverted
in -rc4, so, that's resolved. Good.

> Your computer was good at spotting issues with the MAC address stuff,
> so it was the perfect candidate to test pending fixes for different
> problems. As you noticed, it was not exactly safe to feed the MII
> control register with some potentially uninitialized stuff, whence
> the patch from yesterday.

Glad it was useful. I have to warn you though, that that "computer" is not
very actively used ATM and doesn't stay on for too long. However, if you
can suggest a way to stress test that phy reset thingie, I could run some
overnight test.

Thanks
Guennadi
---
Guennadi Liakhovetski

2006-11-01 05:00:37

by Lennert Buytenhek

[permalink] [raw]

Subject: Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

On Wed, Nov 01, 2006 at 12:05:38AM +0100, Francois Romieu wrote:

> o Lennert, can you apply the two patches
> - 0001-r8169-perform-a-PHY-reset-before-any-other-operation-at-boot-time.txt
> - 0002-r8169-more-magic.txt
> at http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.19-rc4/r8169 against
> 2.6.19-rc4 (2.6.19-rc4 reverted the MAC address changes) and see if the
> n2100 board still needs to remove the SYSErr handler ?

2.6.19-rc4 + these two patches => doesn't work

2.6.19-rc4 + these two patches + SYSErr removal => works

For reference:
* 2.6.19-rc4 + SYSErr removal => works

So, while these two patches don't fix the problem, they don't seem
to be making things worse, something the MAC address change did do.

cheers,
Lennert

2006-11-01 20:06:40

by Darren Salt

[permalink] [raw]

Subject: Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)

This message is in MIME format which your mailer apparently does not support.
You either require a newer version of your software which supports MIME, or
a separate MIME decoding utility. Alternatively, ask the sender of this
message to resend it in a different format.

--163681386--1739281754--1718250983
Content-Type: text/plain; charset=us-ascii

I demand that Francois Romieu may or may not have written...

[snip]
> o Darren and Syed, are your 0x8136 still happy with the patch
> 0001-r8169-perform-a-PHY-reset-before-any-other-operation-at-boot-time.txt
> at http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.19-rc4/r8169
> on top of 2.6.19-rc4 ?

It is.

I then tried 0002-r8169-more-magic.txt, mainly to see that it doesn't cause
any problems. Unfortunately, it did... however, a little reading showed that
you've stopped enabling transmit and receive for all but four of the chip
types supported by the driver.

An incremental fix is attached.

> o Darren, still ok to keep your S-o-b in it ?

Yes.

[snip]
--
| Darren Salt | linux or ds at | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Buy less and make it last longer. INDUSTRY CAUSES GLOBAL WARMING.

Never have a drink when you are feeling sorry for yourself.

--163681386--1739281754--1718250983
Content-Type: text/plain; charset=iso-8859-1; name="0003-r8169-fix-more-magic.patch"
Content-Disposition: attachment; filename="0003-r8169-fix-more-magic.patch"

r8169: fix more magic so that 8101e etc. work again

r8169-more-magic killed transmit & receive on my laptop's RTL8101e. Turns out
to be that the enabling of these functions had been unitnentionally removed.

(This is one of two possible fixes, the other being the removal of the if()
guarding the other tx/rx-enable call. Both work here.)

Signed-off-by: Darren Salt <[email protected]>

--- drivers/net/r8169.c~ 2006-11-01 19:53:02.000000000 +0000
+++ drivers/net/r8169.c 2006-11-01 19:54:16.000000000 +0000
@@ -1921,7 +1921,10 @@
(tp->mac_version != RTL_GIGA_MAC_VER_02) &&
(tp->mac_version != RTL_GIGA_MAC_VER_03) &&
(tp->mac_version != RTL_GIGA_MAC_VER_04))
+ {
rtl8169_set_rx_tx_config_registers(tp);
+ RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
+ }

RTL_W8(Cfg9346, Cfg9346_Lock);

--163681386--1739281754--1718250983--

2006-11-01 21:37:33