* Re: Linux 2.6.19-rc2
2006-10-13 16:49 Linux 2.6.19-rc2 Linus Torvalds
@ 2006-10-13 17:40 ` Alistair John Strachan
2006-10-13 17:55 ` H. Peter Anvin
` (2 more replies)
2006-10-13 17:42 ` Michal Piotrowski
` (6 subsequent siblings)
7 siblings, 3 replies; 68+ messages in thread
From: Alistair John Strachan @ 2006-10-13 17:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, H. Peter Anvin
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
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: Linux 2.6.19-rc2
2006-10-13 17:40 ` Alistair John Strachan
@ 2006-10-13 17:55 ` H. Peter Anvin
2006-10-13 20:52 ` Willy Tarreau
2006-10-13 17:57 ` Paolo Ornati
2006-10-13 17:59 ` Linus Torvalds
2 siblings, 1 reply; 68+ messages in thread
From: H. Peter Anvin @ 2006-10-13 17:55 UTC (permalink / raw)
To: Alistair John Strachan, Kay Sievers
Cc: Linus Torvalds, Linux Kernel Mailing List
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...
-hpa
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Linux 2.6.19-rc2
2006-10-13 17:55 ` H. Peter Anvin
@ 2006-10-13 20:52 ` Willy Tarreau
0 siblings, 0 replies; 68+ messages in thread
From: Willy Tarreau @ 2006-10-13 20:52 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Alistair John Strachan, Kay Sievers, Linus Torvalds,
Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Linux 2.6.19-rc2
2006-10-13 17:40 ` Alistair John Strachan
2006-10-13 17:55 ` H. Peter Anvin
@ 2006-10-13 17:57 ` Paolo Ornati
2006-10-13 17:59 ` Linus Torvalds
2 siblings, 0 replies; 68+ messages in thread
From: Paolo Ornati @ 2006-10-13 17:57 UTC (permalink / raw)
To: Alistair John Strachan
Cc: Linus Torvalds, Linux Kernel Mailing List, H. Peter Anvin
On Fri, 13 Oct 2006 18:40:28 +0100
Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> 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
Same problem here.
--
Paolo Ornati
Linux 2.6.19-rc1-g9eb20074 on x86_64
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Linux 2.6.19-rc2
2006-10-13 17:40 ` Alistair John Strachan
2006-10-13 17:55 ` H. Peter Anvin
2006-10-13 17:57 ` Paolo Ornati
@ 2006-10-13 17:59 ` Linus Torvalds
2 siblings, 0 replies; 68+ messages in thread
From: Linus Torvalds @ 2006-10-13 17:59 UTC (permalink / raw)
To: Alistair John Strachan; +Cc: Linux Kernel Mailing List, H. Peter Anvin
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Linux 2.6.19-rc2
2006-10-13 16:49 Linux 2.6.19-rc2 Linus Torvalds
2006-10-13 17:40 ` Alistair John Strachan
@ 2006-10-13 17:42 ` Michal Piotrowski
2006-10-13 18:26 ` Michal Piotrowski
2006-10-13 18:34 ` Alex Romosan
` (5 subsequent siblings)
7 siblings, 1 reply; 68+ messages in thread
From: Michal Piotrowski @ 2006-10-13 17:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, dwmw2
Hi,
Linus Torvalds wrote:
> Ok, it's a week since -rc1, so -rc2 is out there.
>
Please consider applying this patches.
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)
----
[PATCH] Fix 'headers_install' with separate output directory
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
diff --git a/Makefile b/Makefile
index 80dac02..bdf7c18 100644
--- a/Makefile
+++ b/Makefile
@@ -932,7 +932,7 @@ headers_install_all: include/linux/versi
PHONY += headers_install
headers_install: include/linux/version.h scripts_basic FORCE
- @if [ ! -r include/asm-$(ARCH)/Kbuild ]; then \
+ @if [ ! -r $(srctree)/include/asm-$(ARCH)/Kbuild ]; then \
echo '*** Error: Headers not exportable for this architecture ($(ARCH))'; \
exit 1 ; fi
$(Q)$(MAKE) $(build)=scripts scripts/unifdef
---
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst
index cac8f21..6a7b740 100644
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
@@ -168,7 +168,7 @@ ifdef GENASM
$(call cmd,gen)
else
-$(objhdr-y) : $(INSTALL_HDR_PATH)/$(_dst)/%.h: $(srctree)/$(obj)/%.h $(KBUILDFILES)
+$(objhdr-y) : $(INSTALL_HDR_PATH)/$(_dst)/%.h: $(objtree)/$(obj)/%.h $(KBUILDFILES)
$(call cmd,o_hdr_install)
$(header-y) : $(INSTALL_HDR_PATH)/$(_dst)/%.h: $(srctree)/$(obj)/%.h $(KBUILDFILES)
^ permalink raw reply related [flat|nested] 68+ messages in thread* Re: Linux 2.6.19-rc2
2006-10-13 16:49 Linux 2.6.19-rc2 Linus Torvalds
2006-10-13 17:40 ` Alistair John Strachan
2006-10-13 17:42 ` Michal Piotrowski
@ 2006-10-13 18:34 ` Alex Romosan
2006-10-13 18:37 ` Olaf Hering
` (4 subsequent siblings)
7 siblings, 0 replies; 68+ messages in thread
From: Alex Romosan @ 2006-10-13 18:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, shaggy
Linus Torvalds <torvalds@osdl.org> 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. |
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: Linux 2.6.19-rc2
2006-10-13 16:49 Linux 2.6.19-rc2 Linus Torvalds
` (2 preceding siblings ...)
2006-10-13 18:34 ` Alex Romosan
@ 2006-10-13 18:37 ` Olaf Hering
2006-10-14 11:14 ` [0/3] 2.6.19-rc2: known regressions Adrian Bunk
` (3 subsequent siblings)
7 siblings, 0 replies; 68+ messages in thread
From: Olaf Hering @ 2006-10-13 18:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 68+ messages in thread* [0/3] 2.6.19-rc2: known regressions
2006-10-13 16:49 Linux 2.6.19-rc2 Linus Torvalds
` (3 preceding siblings ...)
2006-10-13 18:37 ` Olaf Hering
@ 2006-10-14 11:14 ` Adrian Bunk
2006-10-14 11:22 ` [1/3] 2.6.19-rc2: known unfixed regressions Adrian Bunk
` (4 more replies)
[not found] ` <20061017155934.GC3502@stusta.de>
` (2 subsequent siblings)
7 siblings, 5 replies; 68+ messages in thread
From: Adrian Bunk @ 2006-10-14 11:14 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton; +Cc: Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 68+ messages in thread* [1/3] 2.6.19-rc2: known unfixed regressions
2006-10-14 11:14 ` [0/3] 2.6.19-rc2: known regressions Adrian Bunk
@ 2006-10-14 11:22 ` Adrian Bunk
2006-10-14 11:54 ` Eric W. Biederman
2006-10-14 11:25 ` [2/3] 2.6.19-rc2: knwon regressions with workarounds Adrian Bunk
` (3 subsequent siblings)
4 siblings, 1 reply; 68+ messages in thread
From: Adrian Bunk @ 2006-10-14 11:22 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Linux Kernel Mailing List, Jesper Juhl, David Howells,
James.Bottomley, pazke, linux-visws-devel, Alex Romosan,
Jens Axboe, Thierry Vignaud, jgarzik, linux-ide, Olaf Hering,
Antonino Daplas, linux-fbdev-devel, art, ak, discuss,
Robert Hancock, Eric W. Biederman, David Gerber, Dmitry Torokhov,
John Stultz, linux-input, Kenny Graunke, Patrick Jefferson,
Alan Cox, Christian, Mark Langsdorf, davej, cpufreq
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 <jesper.juhl@gmail.com>
Caused-By : David Howells <dhowells@redhat.com>
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 <jesper.juhl@gmail.com>
Caused-By : David Howells <dhowells@redhat.com>
commit 7d12e780e003f93433d49ce78cfedf4b4c52adc5
Status : unknown
Subject : unable to rip cd
References : http://lkml.org/lkml/2006/10/13/100
Submitter : Alex Romosan <romosan@sycorax.lbl.gov>
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 <tvignaud@mandriva.com>
Status : unknown
Subject : monitor not active after boot
References : http://lkml.org/lkml/2006/10/5/338
Submitter : Olaf Hering <olaf@aepfle.de>
Caused-By : Antonino Daplas <adaplas@pol.net>
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 : art@usfltd.com
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 <hancockr@shaw.ca>
Handled-By : "Eric W. Biederman" <ebiederm@xmission.com>
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 <dg-kernel-bug@zapek.com>
Handled-By : Dmitry Torokhov <dtor@insightbb.com>
John Stultz <johnstul@us.ibm.com>
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 <kenny@whitecape.org>
Caused-By : Patrick Jefferson <henj@hp.com>
commit a4bea10eca68152e84ffc4eaeb9d20ec2ac34664
Handled-By : Alan Cox <alan@redhat.com>
Status : Alan is investigating
Subject : cpufreq not working on AMD K8
References : http://lkml.org/lkml/2006/10/10/114
Submitter : Christian <christiand59@web.de>
Handled-By : Mark Langsdorf <mark.langsdorf@amd.com>
Status : Mark is investigating
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: [1/3] 2.6.19-rc2: known unfixed regressions
2006-10-14 11:22 ` [1/3] 2.6.19-rc2: known unfixed regressions Adrian Bunk
@ 2006-10-14 11:54 ` Eric W. Biederman
0 siblings, 0 replies; 68+ messages in thread
From: Eric W. Biederman @ 2006-10-14 11:54 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Linux Kernel Mailing List, Robert Hancock, Yinghai Lu
Adrian Bunk <bunk@stusta.de> 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 <hancockr@shaw.ca>
> Handled-By : "Eric W. Biederman" <ebiederm@xmission.com>
> 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* [2/3] 2.6.19-rc2: knwon regressions with workarounds
2006-10-14 11:14 ` [0/3] 2.6.19-rc2: known regressions Adrian Bunk
2006-10-14 11:22 ` [1/3] 2.6.19-rc2: known unfixed regressions Adrian Bunk
@ 2006-10-14 11:25 ` Adrian Bunk
[not found] ` <20061014113409.GL30596@stusta.de>
` (2 subsequent siblings)
4 siblings, 0 replies; 68+ messages in thread
From: Adrian Bunk @ 2006-10-14 11:25 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Linux Kernel Mailing List, Prakash Punnoor, perex, alsa-devel,
Andrew de Quincey, Michael Krufky, v4l-dvb-maintainer
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 <prakash@punnoor.de>
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 <bunk@stusta.de>
Caused-By : "Andrew de Quincey" <adq_dvb@lidskialf.net>
commit 176ac9da4f09820a43fd48f0e74b1486fc3603ba
Handled-By : Michael Krufky <mkrufky@linuxtv.org>
"Andrew de Quincey" <adq_dvb@lidskialf.net>
Status : possible workaround: don't allow CONFIG_DVB_FE_CUSTOMISE=y
^ permalink raw reply [flat|nested] 68+ messages in thread[parent not found: <20061014113409.GL30596@stusta.de>]
* Re: [3/3] 2.6.19-r2: known regressions with patches
[not found] ` <20061014113409.GL30596@stusta.de>
@ 2006-10-15 12:09 ` Jean Delvare
0 siblings, 0 replies; 68+ messages in thread
From: Jean Delvare @ 2006-10-15 12:09 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
Sylvain BERTRAND, David Hubbard, lm-sensors, Greg Kroah-Hartman
Hi Adrian,
On Sat, 14 Oct 2006 13:34:09 +0200, Adrian Bunk wrote:
> This email lists some known regressions in 2.6.19-rc2 compared to 2.6.18
> with patches available.
>
> Unless there are specific reasons against doing so, we should try to get
> these patches into -rc3.
>
> (Especially the lad who wrote the patch for the third entry should ush
> his patch...)
>
> 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 : w83781d modprobing failure
> References : http://bugzilla.kernel.org/show_bug.cgi?id=7293
> Submitter : Sylvain BERTRAND <sylvain.bertrand@gmail.com>
> Caused-By : David Hubbard <david.c.hubbard@gmail.com> (?)
> commit 8202632647278eba7223727dc442f49227c040d0 (?)
> Handled-By : Jean Delvare <khali@linux-fr.org>
> Patch : http://bugzilla.kernel.org/show_bug.cgi?id=7293
> Status : patch available
Patch was tested successfully by Sylvain, I sent it to Greg already,
who should push it to Linus soon (with 7 other hwmon patches.)
Thanks,
--
Jean Delvare
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [0/3] 2.6.19-rc2: known regressions
2006-10-14 11:14 ` [0/3] 2.6.19-rc2: known regressions Adrian Bunk
` (2 preceding siblings ...)
[not found] ` <20061014113409.GL30596@stusta.de>
@ 2006-10-15 12:24 ` Russell King
2006-10-15 12:42 ` Adrian Bunk
2006-10-29 10:33 ` Guennadi Liakhovetski
4 siblings, 1 reply; 68+ messages in thread
From: Russell King @ 2006-10-15 12:24 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: [0/3] 2.6.19-rc2: known regressions
2006-10-15 12:24 ` [0/3] 2.6.19-rc2: known regressions Russell King
@ 2006-10-15 12:42 ` Adrian Bunk
2006-10-19 8:17 ` Russell King
0 siblings, 1 reply; 68+ messages in thread
From: Adrian Bunk @ 2006-10-15 12:42 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List
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 <olaf@aepfle.de>
Caused-By : Greg Banks <gnb@melbourne.sgi.com>
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
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: [0/3] 2.6.19-rc2: known regressions
2006-10-15 12:42 ` Adrian Bunk
@ 2006-10-19 8:17 ` Russell King
2006-10-20 18:07 ` Russell King
0 siblings, 1 reply; 68+ messages in thread
From: Russell King @ 2006-10-19 8:17 UTC (permalink / raw)
To: Adrian Bunk, Andrew Morton; +Cc: Linus Torvalds, Linux Kernel Mailing List
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 <olaf@aepfle.de>
> Caused-By : Greg Banks <gnb@melbourne.sgi.com>
> 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [0/3] 2.6.19-rc2: known regressions
2006-10-19 8:17 ` Russell King
@ 2006-10-20 18:07 ` Russell King
2006-10-20 18:19 ` Andrew Morton
2006-10-20 18:31 ` Linus Torvalds
0 siblings, 2 replies; 68+ messages in thread
From: Russell King @ 2006-10-20 18:07 UTC (permalink / raw)
To: Adrian Bunk, Andrew Morton, Linus Torvalds,
Linux Kernel Mailing List
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 <olaf@aepfle.de>
> > Caused-By : Greg Banks <gnb@melbourne.sgi.com>
> > 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 <rmk+kernel@arm.linux.org.uk>
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
^ permalink raw reply related [flat|nested] 68+ messages in thread* Re: [0/3] 2.6.19-rc2: known regressions
2006-10-20 18:07 ` Russell King
@ 2006-10-20 18:19 ` Andrew Morton
2006-10-20 18:31 ` Russell King
2006-10-20 18:31 ` Linus Torvalds
1 sibling, 1 reply; 68+ messages in thread
From: Andrew Morton @ 2006-10-20 18:19 UTC (permalink / raw)
To: Russell King; +Cc: Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List
On Fri, 20 Oct 2006 19:07:22 +0100
Russell King <rmk+lkml@arm.linux.org.uk> 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 <olaf@aepfle.de>
> > > Caused-By : Greg Banks <gnb@melbourne.sgi.com>
> > > 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 <akpm@osdl.org>
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 <bunk@stusta.de>
Cc: Paul Jackson <pj@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
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
_
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: [0/3] 2.6.19-rc2: known regressions
2006-10-20 18:19 ` Andrew Morton
@ 2006-10-20 18:31 ` Russell King
2006-10-20 18:50 ` Linus Torvalds
0 siblings, 1 reply; 68+ messages in thread
From: Russell King @ 2006-10-20 18:31 UTC (permalink / raw)
To: Andrew Morton; +Cc: Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List
On Fri, Oct 20, 2006 at 11:19:00AM -0700, Andrew Morton wrote:
> On Fri, 20 Oct 2006 19:07:22 +0100
> Russell King <rmk+lkml@arm.linux.org.uk> 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 <olaf@aepfle.de>
> > > > Caused-By : Greg Banks <gnb@melbourne.sgi.com>
> > > > 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [0/3] 2.6.19-rc2: known regressions
2006-10-20 18:31 ` Russell King
@ 2006-10-20 18:50 ` Linus Torvalds
2006-10-20 18:59 ` Russell King
0 siblings, 1 reply; 68+ messages in thread
From: Linus Torvalds @ 2006-10-20 18:50 UTC (permalink / raw)
To: Russell King; +Cc: Andrew Morton, Adrian Bunk, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [0/3] 2.6.19-rc2: known regressions
2006-10-20 18:50 ` Linus Torvalds
@ 2006-10-20 18:59 ` Russell King
2006-10-20 21:06 ` Linus Torvalds
0 siblings, 1 reply; 68+ messages in thread
From: Russell King @ 2006-10-20 18:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, Adrian Bunk, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [0/3] 2.6.19-rc2: known regressions
2006-10-20 18:59 ` Russell King
@ 2006-10-20 21:06 ` Linus Torvalds
0 siblings, 0 replies; 68+ messages in thread
From: Linus Torvalds @ 2006-10-20 21:06 UTC (permalink / raw)
To: Russell King; +Cc: Andrew Morton, Adrian Bunk, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [0/3] 2.6.19-rc2: known regressions
2006-10-20 18:07 ` Russell King
2006-10-20 18:19 ` Andrew Morton
@ 2006-10-20 18:31 ` Linus Torvalds
1 sibling, 0 replies; 68+ messages in thread
From: Linus Torvalds @ 2006-10-20 18:31 UTC (permalink / raw)
To: Russell King; +Cc: Adrian Bunk, Andrew Morton, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: [0/3] 2.6.19-rc2: known regressions
2006-10-14 11:14 ` [0/3] 2.6.19-rc2: known regressions Adrian Bunk
` (3 preceding siblings ...)
2006-10-15 12:24 ` [0/3] 2.6.19-rc2: known regressions Russell King
@ 2006-10-29 10:33 ` Guennadi Liakhovetski
2006-10-29 20:17 ` Linus Torvalds
4 siblings, 1 reply; 68+ messages in thread
From: Guennadi Liakhovetski @ 2006-10-29 10:33 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: [0/3] 2.6.19-rc2: known regressions
2006-10-29 10:33 ` Guennadi Liakhovetski
@ 2006-10-29 20:17 ` Linus Torvalds
2006-10-29 22:34 ` r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions) Francois Romieu
0 siblings, 1 reply; 68+ messages in thread
From: Linus Torvalds @ 2006-10-29 20:17 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Adrian Bunk, Andrew Morton, Francois Romieu, Jeff Garzik,
Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 68+ messages in thread* r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)
2006-10-29 20:17 ` Linus Torvalds
@ 2006-10-29 22:34 ` Francois Romieu
2006-10-30 0:20 ` Guennadi Liakhovetski
2006-10-30 13:02 ` Oleg Verych
0 siblings, 2 replies; 68+ messages in thread
From: Francois Romieu @ 2006-10-29 22:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: Guennadi Liakhovetski, Adrian Bunk, Andrew Morton, Jeff Garzik,
Linux Kernel Mailing List, tmattox, spiky.kiwi, r.bhatia
Linus Torvalds <torvalds@osdl.org> :
[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 <romieu@fr.zoreil.com>
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 <romieu@fr.zoreil.com>
Signed-off-by: Darren Salt <linux@youmustbejoking.demon.co.uk>
---
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
^ permalink raw reply related [flat|nested] 68+ messages in thread* Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)
2006-10-29 22:34 ` r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions) Francois Romieu
@ 2006-10-30 0:20 ` Guennadi Liakhovetski
2006-10-30 12:01 ` Francois Romieu
2006-10-30 13:02 ` Oleg Verych
1 sibling, 1 reply; 68+ messages in thread
From: Guennadi Liakhovetski @ 2006-10-30 0:20 UTC (permalink / raw)
To: Francois Romieu
Cc: Linus Torvalds, Guennadi Liakhovetski, Adrian Bunk, Andrew Morton,
Jeff Garzik, Linux Kernel Mailing List, tmattox, spiky.kiwi,
r.bhatia
On Sun, 29 Oct 2006, Francois Romieu wrote:
> Linus Torvalds <torvalds@osdl.org> :
> [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
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)
2006-10-30 0:20 ` Guennadi Liakhovetski
@ 2006-10-30 12:01 ` Francois Romieu
2006-10-30 20:59 ` Guennadi Liakhovetski
0 siblings, 1 reply; 68+ messages in thread
From: Francois Romieu @ 2006-10-30 12:01 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Linus Torvalds, Adrian Bunk, Andrew Morton, Jeff Garzik,
Linux Kernel Mailing List, tmattox, spiky.kiwi, r.bhatia
Guennadi Liakhovetski <g.liakhovetski@gmx.de> :
[...]
> 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)
2006-10-30 12:01 ` Francois Romieu
@ 2006-10-30 20:59 ` Guennadi Liakhovetski
2006-10-30 21:17 ` Guennadi Liakhovetski
2006-10-30 23:25 ` Francois Romieu
0 siblings, 2 replies; 68+ messages in thread
From: Guennadi Liakhovetski @ 2006-10-30 20:59 UTC (permalink / raw)
To: Francois Romieu
Cc: Linus Torvalds, Adrian Bunk, Andrew Morton, Jeff Garzik,
Linux Kernel Mailing List, tmattox, spiky.kiwi, r.bhatia
On Mon, 30 Oct 2006, Francois Romieu wrote:
> Guennadi Liakhovetski <g.liakhovetski@gmx.de> :
> [...]
> > 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)
2006-10-30 20:59 ` Guennadi Liakhovetski
@ 2006-10-30 21:17 ` Guennadi Liakhovetski
2006-10-30 23:44 ` Francois Romieu
2006-10-30 23:25 ` Francois Romieu
1 sibling, 1 reply; 68+ messages in thread
From: Guennadi Liakhovetski @ 2006-10-30 21:17 UTC (permalink / raw)
To: Francois Romieu
Cc: Linus Torvalds, Adrian Bunk, Andrew Morton, Jeff Garzik,
Linux Kernel Mailing List, tmattox, spiky.kiwi, r.bhatia
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)
2006-10-30 21:17 ` Guennadi Liakhovetski
@ 2006-10-30 23:44 ` Francois Romieu
2006-10-31 19:02 ` Guennadi Liakhovetski
0 siblings, 1 reply; 68+ messages in thread
From: Francois Romieu @ 2006-10-30 23:44 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Linus Torvalds, Adrian Bunk, Andrew Morton, Jeff Garzik,
Linux Kernel Mailing List, tmattox, spiky.kiwi, r.bhatia
Guennadi Liakhovetski <g.liakhovetski@gmx.de> :
[...]
> 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))
^ permalink raw reply related [flat|nested] 68+ messages in thread* Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)
2006-10-30 23:44 ` Francois Romieu
@ 2006-10-31 19:02 ` Guennadi Liakhovetski
2006-10-31 23:05 ` Francois Romieu
0 siblings, 1 reply; 68+ messages in thread
From: Guennadi Liakhovetski @ 2006-10-31 19:02 UTC (permalink / raw)
To: Francois Romieu
Cc: Linus Torvalds, Adrian Bunk, Andrew Morton, Jeff Garzik,
Linux Kernel Mailing List, tmattox, spiky.kiwi, r.bhatia
On Tue, 31 Oct 2006, Francois Romieu wrote:
> Guennadi Liakhovetski <g.liakhovetski@gmx.de> :
> [...]
> > 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)
2006-10-31 19:02 ` Guennadi Liakhovetski
@ 2006-10-31 23:05 ` Francois Romieu
2006-10-31 23:37 ` Guennadi Liakhovetski
` (2 more replies)
0 siblings, 3 replies; 68+ messages in thread
From: Francois Romieu @ 2006-10-31 23:05 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Linus Torvalds, Adrian Bunk, Andrew Morton, Jeff Garzik,
Linux Kernel Mailing List, tmattox, spiky.kiwi, r.bhatia,
Darren Salt, Syed Azam, Lennert Buytenhek
Guennadi Liakhovetski <g.liakhovetski@gmx.de> :
[...]
> 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
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)
2006-10-31 23:05 ` Francois Romieu
@ 2006-10-31 23:37 ` Guennadi Liakhovetski
2006-11-01 5:00 ` Lennert Buytenhek
2006-11-01 19:01 ` Darren Salt
2 siblings, 0 replies; 68+ messages in thread
From: Guennadi Liakhovetski @ 2006-10-31 23:37 UTC (permalink / raw)
To: Francois Romieu
Cc: Linus Torvalds, Adrian Bunk, Andrew Morton, Jeff Garzik,
Linux Kernel Mailing List, tmattox, spiky.kiwi, r.bhatia,
Darren Salt, Syed Azam, Lennert Buytenhek
On Wed, 1 Nov 2006, Francois Romieu wrote:
> Guennadi Liakhovetski <g.liakhovetski@gmx.de> :
>
> > 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)
2006-10-31 23:05 ` Francois Romieu
2006-10-31 23:37 ` Guennadi Liakhovetski
@ 2006-11-01 5:00 ` Lennert Buytenhek
2006-11-01 19:01 ` Darren Salt
2 siblings, 0 replies; 68+ messages in thread
From: Lennert Buytenhek @ 2006-11-01 5:00 UTC (permalink / raw)
To: Francois Romieu
Cc: Guennadi Liakhovetski, Linus Torvalds, Adrian Bunk, Andrew Morton,
Jeff Garzik, Linux Kernel Mailing List, tmattox, spiky.kiwi,
r.bhatia, Darren Salt, Syed Azam, tbm
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)
2006-10-31 23:05 ` Francois Romieu
2006-10-31 23:37 ` Guennadi Liakhovetski
2006-11-01 5:00 ` Lennert Buytenhek
@ 2006-11-01 19:01 ` Darren Salt
2006-11-01 21:35 ` Francois Romieu
2006-11-03 14:52 ` Azam, Syed S
2 siblings, 2 replies; 68+ messages in thread
From: Darren Salt @ 2006-11-01 19:01 UTC (permalink / raw)
To: g.liakhovetski, romieu
Cc: torvalds, bunk, akpm, jgarzik, linux-kernel, tmattox, spiky.kiwi,
r.bhatia, syed.azam, buytenh
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 <linux@youmustbejoking.demon.co.uk>
--- 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--
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)
2006-11-01 19:01 ` Darren Salt
@ 2006-11-01 21:35 ` Francois Romieu
2006-11-03 14:52 ` Azam, Syed S
1 sibling, 0 replies; 68+ messages in thread
From: Francois Romieu @ 2006-11-01 21:35 UTC (permalink / raw)
To: Darren Salt
Cc: buytenh, g.liakhovetski, romieu, torvalds, bunk, akpm, jgarzik,
linux-kernel, tmattox, spiky.kiwi, r.bhatia, syed.azam
Darren Salt <linux@youmustbejoking.demon.co.uk> :
[...]
> (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.)
I'll update the patch with your change but the removal of the if() would
not match Realtek's init sequence.
Lennert, I have compared 2.6.19-rc4 + 0001-r8169-perform-a-PHY-reset-etc
with the serie of patches against 2.6.18-rc4 which was reported to work
on your n2100 (thread on netdev around 05/09/2006). Can you:
- apply the patch below on top of 2.6.19-rc4 + 0001 and see if it works ?
Don't apply 0002, it is not required.
- if it works (it should if I have not messed it again), can you check
that it still works if you do not apply the first hunk ? It should as
well.
If everything went fine this far, it would be nice to know if both the
move of the write to ChipCmd and the mdio_write are required to fix
your issue (I'd expect the move alone to not be enough as 0002 got this
part right for the 8110sb).
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 50b753d..b2fdbb8 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -491,7 +491,7 @@ static int rtl8169_poll(struct net_devic
#endif
static const u16 rtl8169_intr_mask =
- SYSErr | LinkChg | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK;
+ LinkChg | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK;
static const u16 rtl8169_napi_event =
RxOK | RxOverflow | RxFIFOOver | TxOK | TxErr;
static const unsigned int rtl8169_rx_config =
@@ -1283,11 +1283,6 @@ static void rtl8169_hw_phy_config(struct
/* Shazam ! */
if (tp->mac_version == RTL_GIGA_MAC_VER_04) {
- mdio_write(ioaddr, 31, 0x0001);
- mdio_write(ioaddr, 9, 0x273a);
- mdio_write(ioaddr, 14, 0x7bfb);
- mdio_write(ioaddr, 27, 0x841e);
-
mdio_write(ioaddr, 31, 0x0002);
mdio_write(ioaddr, 1, 0x90d0);
mdio_write(ioaddr, 31, 0x0000);
@@ -1855,6 +1850,8 @@ rtl8169_hw_start(struct net_device *dev)
RTL_W8(Cfg9346, Cfg9346_Unlock);
+
+ RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
RTL_W8(EarlyTxThres, EarlyTxThld);
/* Low hurts. Let's disable the filtering. */
@@ -1895,7 +1892,7 @@ rtl8169_hw_start(struct net_device *dev)
RTL_W32(TxDescStartAddrLow, ((u64) tp->TxPhyAddr & DMA_32BIT_MASK));
RTL_W32(RxDescAddrHigh, ((u64) tp->RxPhyAddr >> 32));
RTL_W32(RxDescAddrLow, ((u64) tp->RxPhyAddr & DMA_32BIT_MASK));
- RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
+
RTL_W8(Cfg9346, Cfg9346_Lock);
/* Initially a 10 us delay. Turned it into a PCI commit. - FR */
^ permalink raw reply related [flat|nested] 68+ messages in thread* RE: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)
2006-11-01 19:01 ` Darren Salt
2006-11-01 21:35 ` Francois Romieu
@ 2006-11-03 14:52 ` Azam, Syed S
1 sibling, 0 replies; 68+ messages in thread
From: Azam, Syed S @ 2006-11-03 14:52 UTC (permalink / raw)
To: Darren Salt, g.liakhovetski, romieu
Cc: torvalds, bunk, akpm, jgarzik, linux-kernel, tmattox, spiky.kiwi,
r.bhatia, buytenh
Yes, It is still working.
Syed Azam
System Software Engineer
Hewlett-Packard Company
-----Original Message-----
From: Darren Salt [mailto:linux@youmustbejoking.demon.co.uk]
Sent: Wednesday, November 01, 2006 1:01 PM
To: g.liakhovetski@gmx.de; romieu@fr.zoreil.com
Cc: torvalds@osdl.org; bunk@stusta.de; akpm@osdl.org; jgarzik@pobox.com;
linux-kernel@vger.kernel.org; tmattox@gmail.com; spiky.kiwi@gmail.com;
r.bhatia@ipax.at; Azam, Syed S; buytenh@wantstofly.org
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.t
xt
> 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 <linux@youmustbejoking.demon.co.uk>
--- 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--
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)
2006-10-30 20:59 ` Guennadi Liakhovetski
2006-10-30 21:17 ` Guennadi Liakhovetski
@ 2006-10-30 23:25 ` Francois Romieu
1 sibling, 0 replies; 68+ messages in thread
From: Francois Romieu @ 2006-10-30 23:25 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Linus Torvalds, Adrian Bunk, Andrew Morton, Jeff Garzik,
Linux Kernel Mailing List, tmattox, spiky.kiwi, r.bhatia
Guennadi Liakhovetski <g.liakhovetski@gmx.de> :
[...]
> 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)
2006-10-29 22:34 ` r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions) Francois Romieu
2006-10-30 0:20 ` Guennadi Liakhovetski
@ 2006-10-30 13:02 ` Oleg Verych
1 sibling, 0 replies; 68+ messages in thread
From: Oleg Verych @ 2006-10-30 13:02 UTC (permalink / raw)
To: linux-kernel
On 2006-10-29, Francois Romieu wrote:
>
> Linus Torvalds <torvalds@osdl.org> :
> [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#
`--
____
^ permalink raw reply [flat|nested] 68+ messages in thread
[parent not found: <20061017155934.GC3502@stusta.de>]
* Re: 2.6.19-rc2: known unfixed regressions (v2)
[not found] ` <20061017155934.GC3502@stusta.de>
@ 2006-10-17 16:23 ` Olaf Hering
2006-10-17 16:29 ` Adrian Bunk
[not found] ` <4534C7A7.7000607@hp.com>
1 sibling, 1 reply; 68+ messages in thread
From: Olaf Hering @ 2006-10-17 16:23 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linux-kernel, linux-fbdev-devel
On Tue, Oct 17, Adrian Bunk wrote:
> Subject : monitor not active after boot
> References : http://lkml.org/lkml/2006/10/5/338
> Submitter : Olaf Hering <olaf@aepfle.de>
> Caused-By : Antonino Daplas <adaplas@pol.net>
> commit 346bc21026e7a92e1d7a4a1b3792c5e8b686133d
> Status : unknown
The nvidiafb change was removed again. I will see if I can figure out
why the EDID is lost.
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.19-rc2: known unfixed regressions (v2)
2006-10-17 16:23 ` 2.6.19-rc2: known unfixed regressions (v2) Olaf Hering
@ 2006-10-17 16:29 ` Adrian Bunk
0 siblings, 0 replies; 68+ messages in thread
From: Adrian Bunk @ 2006-10-17 16:29 UTC (permalink / raw)
To: Olaf Hering; +Cc: linux-kernel, linux-fbdev-devel
On Tue, Oct 17, 2006 at 06:23:23PM +0200, Olaf Hering wrote:
> On Tue, Oct 17, Adrian Bunk wrote:
>
> > Subject : monitor not active after boot
> > References : http://lkml.org/lkml/2006/10/5/338
> > Submitter : Olaf Hering <olaf@aepfle.de>
> > Caused-By : Antonino Daplas <adaplas@pol.net>
> > commit 346bc21026e7a92e1d7a4a1b3792c5e8b686133d
> > Status : unknown
>
> The nvidiafb change was removed again. I will see if I can figure out
> why the EDID is lost.
Thanks for the information, I missed this patch.
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
^ permalink raw reply [flat|nested] 68+ messages in thread
[parent not found: <4534C7A7.7000607@hp.com>]
* Re: Linux 2.6.19-rc2
2006-10-13 16:49 Linux 2.6.19-rc2 Linus Torvalds
` (5 preceding siblings ...)
[not found] ` <20061017155934.GC3502@stusta.de>
@ 2006-10-20 18:30 ` Kevin Radloff
2006-10-20 20:53 ` Alan Cox
2006-10-22 12:23 ` 2.6.19-rc2: known unfixed regressions (v3) Adrian Bunk
7 siblings, 1 reply; 68+ messages in thread
From: Kevin Radloff @ 2006-10-20 18:30 UTC (permalink / raw)
To: Linus Torvalds, Alan Cox, Jeff Garzik; +Cc: Linux Kernel Mailing List
On 10/13/06, Linus Torvalds <torvalds@osdl.org> 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
radsaq@gmail.com
http://thesaq.com/
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: Linux 2.6.19-rc2
2006-10-20 18:30 ` Linux 2.6.19-rc2 Kevin Radloff
@ 2006-10-20 20:53 ` Alan Cox
2006-10-20 21:12 ` Jeff Garzik
0 siblings, 1 reply; 68+ messages in thread
From: Alan Cox @ 2006-10-20 20:53 UTC (permalink / raw)
To: Kevin Radloff; +Cc: Linus Torvalds, Jeff Garzik, Linux Kernel Mailing List
Ar Gwe, 2006-10-20 am 14:30 -0400, ysgrifennodd Kevin Radloff:
> On 10/13/06, Linus Torvalds <torvalds@osdl.org> 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Linux 2.6.19-rc2
2006-10-20 20:53 ` Alan Cox
@ 2006-10-20 21:12 ` Jeff Garzik
0 siblings, 0 replies; 68+ messages in thread
From: Jeff Garzik @ 2006-10-20 21:12 UTC (permalink / raw)
To: Alan Cox
Cc: Kevin Radloff, Linus Torvalds, Linux Kernel Mailing List,
linux-ide@vger.kernel.org
Alan Cox wrote:
> Ar Gwe, 2006-10-20 am 14:30 -0400, ysgrifennodd Kevin Radloff:
>> On 10/13/06, Linus Torvalds <torvalds@osdl.org> 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* 2.6.19-rc2: known unfixed regressions (v3)
2006-10-13 16:49 Linux 2.6.19-rc2 Linus Torvalds
` (6 preceding siblings ...)
2006-10-20 18:30 ` Linux 2.6.19-rc2 Kevin Radloff
@ 2006-10-22 12:23 ` Adrian Bunk
2006-10-22 13:23 ` Andi Kleen
` (5 more replies)
7 siblings, 6 replies; 68+ messages in thread
From: Adrian Bunk @ 2006-10-22 12:23 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Linux Kernel Mailing List, Meelis Roos, paulus, linuxppc-dev,
Martin Lorenz, Michael S. Tsirkin, len.brown, linux-acpi, pavel,
linux-pm, Jesper Juhl, David Howells, James.Bottomley, pazke,
linux-visws-devel, Thierry Vignaud, jgarzik, linux-ide, art, ak,
discuss, Alex Romosan, Jens Axboe, Christian, Mark Langsdorf,
davej, cpufreq, Stephen Hemminger, Greg KH, linux-pci,
Prakash Punnoor, perex, alsa-devel
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 <mroos@linux.ee>
Status : unknown
Subject : X60s: BUG()s, lose ACPI events after suspend/resume
References : http://lkml.org/lkml/2006/10/10/39
Submitter : Martin Lorenz <martin@lorenz.eu.org>
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" <mst@mellanox.co.il>
Status : unknown
Subject : CONFIG_X86_VOYAGER=y, CONFIG_SMP=n compile error
References : http://lkml.org/lkml/2006/10/7/51
Submitter : Jesper Juhl <jesper.juhl@gmail.com>
Caused-By : David Howells <dhowells@redhat.com>
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 <jesper.juhl@gmail.com>
Caused-By : David Howells <dhowells@redhat.com>
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 <tvignaud@mandriva.com>
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 : art@usfltd.com
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 <romosan@sycorax.lbl.gov>
Status : unknown
Subject : cpufreq not working on AMD K8
References : http://lkml.org/lkml/2006/10/10/114
Submitter : Christian <christiand59@web.de>
Handled-By : Mark Langsdorf <mark.langsdorf@amd.com>
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 <shemminger@osdl.org>
Handled-By : Greg KH <greg@kroah.com>
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 <prakash@punnoor.de>
Status : patches are being discussed
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.19-rc2: known unfixed regressions (v3)
2006-10-22 12:23 ` 2.6.19-rc2: known unfixed regressions (v3) Adrian Bunk
@ 2006-10-22 13:23 ` Andi Kleen
2006-10-22 14:46 ` Gene Heskett
` (4 subsequent siblings)
5 siblings, 0 replies; 68+ messages in thread
From: Andi Kleen @ 2006-10-22 13:23 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Linux Kernel Mailing List, art
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 : art@usfltd.com
> Status : submitter was asked to git bisect
> result of bisecting seems to be wrong
Does this still happen with 2.6.19rc2-latestGIT ?
-Andi
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.19-rc2: known unfixed regressions (v3)
2006-10-22 12:23 ` 2.6.19-rc2: known unfixed regressions (v3) Adrian Bunk
2006-10-22 13:23 ` Andi Kleen
@ 2006-10-22 14:46 ` Gene Heskett
2006-10-22 15:17 ` Alex Romosan
2006-10-23 11:32 ` Andrey Panin
` (3 subsequent siblings)
5 siblings, 1 reply; 68+ messages in thread
From: Gene Heskett @ 2006-10-22 14:46 UTC (permalink / raw)
To: linux-kernel; +Cc: Alex Romosan, Adrian Bunk
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 <romosan@sycorax.lbl.gov>
>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.
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.19-rc2: known unfixed regressions (v3)
2006-10-22 14:46 ` Gene Heskett
@ 2006-10-22 15:17 ` Alex Romosan
2006-10-23 0:55 ` Gene Heskett
0 siblings, 1 reply; 68+ messages in thread
From: Alex Romosan @ 2006-10-22 15:17 UTC (permalink / raw)
To: Gene Heskett; +Cc: linux-kernel, Adrian Bunk
Gene Heskett <gene.heskett@verizon.net> 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 <romosan@sycorax.lbl.gov>
>>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. |
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.19-rc2: known unfixed regressions (v3)
2006-10-22 15:17 ` Alex Romosan
@ 2006-10-23 0:55 ` Gene Heskett
0 siblings, 0 replies; 68+ messages in thread
From: Gene Heskett @ 2006-10-23 0:55 UTC (permalink / raw)
To: linux-kernel; +Cc: Alex Romosan, Adrian Bunk
On Sunday 22 October 2006 11:17, Alex Romosan wrote:
>Gene Heskett <gene.heskett@verizon.net> 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 <romosan@sycorax.lbl.gov>
>>>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.
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.19-rc2: known unfixed regressions (v3)
2006-10-22 12:23 ` 2.6.19-rc2: known unfixed regressions (v3) Adrian Bunk
2006-10-22 13:23 ` Andi Kleen
2006-10-22 14:46 ` Gene Heskett
@ 2006-10-23 11:32 ` Andrey Panin
2006-10-23 15:20 ` Meelis Roos
` (2 subsequent siblings)
5 siblings, 0 replies; 68+ messages in thread
From: Andrey Panin @ 2006-10-23 11:32 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linux-kernel
[-- Attachment #1.1: Type: text/plain, Size: 996 bytes --]
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 <jesper.juhl@gmail.com>
> Caused-By : David Howells <dhowells@redhat.com>
> commit 7d12e780e003f93433d49ce78cfedf4b4c52adc5
> Status : unknown
Attached patch fixes this problem.
--
Andrey Panin | Linux and UNIX system administrator
pazke@donpac.ru | PGP key: wwwkeys.pgp.net
[-- Attachment #1.2: patch-fix-visws --]
[-- Type: text/plain, Size: 3962 bytes --]
Signed-off-by: Andrey Panin <pazke@donpac.ru>
arch/i386/mach-visws/visws_apic.c | 7 +---
include/asm-i386/mach-visws/do_timer.h | 53 --------------------------------
include/asm-i386/mach-visws/mach_apic.h | 5 +++
3 files changed, 8 insertions(+), 57 deletions(-)
diff -urdpNX /usr/share/dontdiff linux-2.6.19-rc2.vanilla/arch/i386/mach-visws/visws_apic.c linux-2.6.19-rc2/arch/i386/mach-visws/visws_apic.c
--- linux-2.6.19-rc2.vanilla/arch/i386/mach-visws/visws_apic.c 2006-10-22 14:32:13.000000000 +0400
+++ linux-2.6.19-rc2/arch/i386/mach-visws/visws_apic.c 2006-10-22 14:37:30.000000000 +0400
@@ -122,7 +122,7 @@ static void end_cobalt_irq(unsigned int
spin_unlock_irqrestore(&cobalt_lock, flags);
}
-static struct hw_interrupt_type cobalt_irq_type = {
+static struct irq_chip cobalt_irq_type = {
.typename = "Cobalt-APIC",
.startup = startup_cobalt_irq,
.shutdown = disable_cobalt_irq,
@@ -159,7 +159,7 @@ static void end_piix4_master_irq(unsigne
spin_unlock_irqrestore(&cobalt_lock, flags);
}
-static struct hw_interrupt_type piix4_master_irq_type = {
+static struct irq_chip piix4_master_irq_type = {
.typename = "PIIX4-master",
.startup = startup_piix4_master_irq,
.ack = ack_cobalt_irq,
@@ -167,9 +167,8 @@ static struct hw_interrupt_type piix4_ma
};
-static struct hw_interrupt_type piix4_virtual_irq_type = {
+static struct irq_chip piix4_virtual_irq_type = {
.typename = "PIIX4-virtual",
- .startup = startup_8259A_irq,
.shutdown = disable_8259A_irq,
.enable = enable_8259A_irq,
.disable = disable_8259A_irq,
diff -urdpNX /usr/share/dontdiff linux-2.6.19-rc2.vanilla/include/asm-i386/mach-visws/do_timer.h linux-2.6.19-rc2/include/asm-i386/mach-visws/do_timer.h
--- linux-2.6.19-rc2.vanilla/include/asm-i386/mach-visws/do_timer.h 2006-10-22 14:33:24.000000000 +0400
+++ linux-2.6.19-rc2/include/asm-i386/mach-visws/do_timer.h 1970-01-01 03:00:00.000000000 +0300
@@ -1,53 +0,0 @@
-/* defines for inline arch setup functions */
-
-#include <asm/fixmap.h>
-#include <asm/i8259.h>
-#include "cobalt.h"
-
-static inline void do_timer_interrupt_hook(void)
-{
- /* Clear the interrupt */
- co_cpu_write(CO_CPU_STAT,co_cpu_read(CO_CPU_STAT) & ~CO_STAT_TIMEINTR);
-
- do_timer(1);
-#ifndef CONFIG_SMP
- update_process_times(user_mode_vm(irq_regs));
-#endif
-/*
- * In the SMP case we use the local APIC timer interrupt to do the
- * profiling, except when we simulate SMP mode on a uniprocessor
- * system, in that case we have to call the local interrupt handler.
- */
-#ifndef CONFIG_X86_LOCAL_APIC
- profile_tick(CPU_PROFILING);
-#else
- if (!using_apic_timer)
- smp_local_timer_interrupt();
-#endif
-}
-
-static inline int do_timer_overflow(int count)
-{
- int i;
-
- spin_lock(&i8259A_lock);
- /*
- * This is tricky when I/O APICs are used;
- * see do_timer_interrupt().
- */
- i = inb(0x20);
- spin_unlock(&i8259A_lock);
-
- /* assumption about timer being IRQ0 */
- if (i & 0x01) {
- /*
- * We cannot detect lost timer interrupts ...
- * well, that's why we call them lost, don't we? :)
- * [hmm, on the Pentium and Alpha we can ... sort of]
- */
- count -= LATCH;
- } else {
- printk("do_slow_gettimeoffset(): hardware timer problem?\n");
- }
- return count;
-}
diff -urdpNX /usr/share/dontdiff linux-2.6.19-rc2.vanilla/include/asm-i386/mach-visws/mach_apic.h linux-2.6.19-rc2/include/asm-i386/mach-visws/mach_apic.h
--- linux-2.6.19-rc2.vanilla/include/asm-i386/mach-visws/mach_apic.h 2006-01-03 06:21:10.000000000 +0300
+++ linux-2.6.19-rc2/include/asm-i386/mach-visws/mach_apic.h 2006-10-22 14:16:53.000000000 +0400
@@ -51,6 +51,11 @@ static inline void clustered_apic_check(
{
}
+static inline int apicid_to_node(int logical_apicid)
+{
+ return 0;
+}
+
/* Mapping from cpu number to logical apicid */
static inline int cpu_to_logical_apicid(int cpu)
{
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.19-rc2: known unfixed regressions (v3)
2006-10-22 12:23 ` 2.6.19-rc2: known unfixed regressions (v3) Adrian Bunk
` (2 preceding siblings ...)
2006-10-23 11:32 ` Andrey Panin
@ 2006-10-23 15:20 ` Meelis Roos
2006-10-23 20:59 ` Adrian Bunk
2006-10-24 15:00 ` Michael S. Tsirkin
2006-10-24 17:27 ` Prakash Punnoor
5 siblings, 1 reply; 68+ messages in thread
From: Meelis Roos @ 2006-10-23 15:20 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, paulus,
linuxppc-dev
> Subject : ppc prep boot hang
> References : http://lkml.org/lkml/2006/10/14/58
> Submitter : Meelis Roos <mroos@linux.ee>
> Status : unknown
Seems to be fixed in 2.6.19-rc2+git as of 20061022.
--
Meelis Roos
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.19-rc2: known unfixed regressions (v3)
2006-10-23 15:20 ` Meelis Roos
@ 2006-10-23 20:59 ` Adrian Bunk
2006-10-24 14:57 ` Stefan Richter
0 siblings, 1 reply; 68+ messages in thread
From: Adrian Bunk @ 2006-10-23 20:59 UTC (permalink / raw)
To: Meelis Roos
Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, paulus,
linuxppc-dev
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 <mroos@linux.ee>
> >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
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.19-rc2: known unfixed regressions (v3)
2006-10-23 20:59 ` Adrian Bunk
@ 2006-10-24 14:57 ` Stefan Richter
2006-10-24 19:48 ` Adrian Bunk
0 siblings, 1 reply; 68+ messages in thread
From: Stefan Richter @ 2006-10-24 14:57 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
Benjamin Herrenschmidt
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 <benh@kernel.crashing.org>
Caused-By : Stefan Richter <stefanr@s5r6.in-berlin.de>
commit ea6104c22468239083857fa07425c312b1ecb424
Status : looking for answer when to ignore return code of pci_set_power_state
--
Stefan Richter
-=====-=-==- =-=- ==---
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.19-rc2: known unfixed regressions (v3)
2006-10-24 14:57 ` Stefan Richter
@ 2006-10-24 19:48 ` Adrian Bunk
0 siblings, 0 replies; 68+ messages in thread
From: Adrian Bunk @ 2006-10-24 19:48 UTC (permalink / raw)
To: Stefan Richter
Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
Benjamin Herrenschmidt
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 <benh@kernel.crashing.org>
> Caused-By : Stefan Richter <stefanr@s5r6.in-berlin.de>
> 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.19-rc2: known unfixed regressions (v3)
2006-10-22 12:23 ` 2.6.19-rc2: known unfixed regressions (v3) Adrian Bunk
` (3 preceding siblings ...)
2006-10-23 15:20 ` Meelis Roos
@ 2006-10-24 15:00 ` Michael S. Tsirkin
2006-10-25 8:28 ` Pavel Machek
2006-10-24 17:27 ` Prakash Punnoor
5 siblings, 1 reply; 68+ messages in thread
From: Michael S. Tsirkin @ 2006-10-24 15:00 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
len.brown, linux-acpi, pavel, linux-pm, jgarzik, linux-ide
Quoting r. Adrian Bunk <bunk@stusta.de>:
> 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" <mst@mellanox.co.il>
> 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
^ permalink raw reply [flat|nested] 68+ messages in thread* Re: 2.6.19-rc2: known unfixed regressions (v3)
2006-10-24 15:00 ` Michael S. Tsirkin
@ 2006-10-25 8:28 ` Pavel Machek
2006-10-25 8:37 ` Michael S. Tsirkin
0 siblings, 1 reply; 68+ messages in thread
From: Pavel Machek @ 2006-10-25 8:28 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Adrian Bunk, Linus Torvalds, Andrew Morton,
Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm,
jgarzik, linux-ide
On Tue 2006-10-24 17:00:51, Michael S. Tsirkin wrote:
> Quoting r. Adrian Bunk <bunk@stusta.de>:
> > 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" <mst@mellanox.co.il>
> > 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.19-rc2: known unfixed regressions (v3)
2006-10-25 8:28 ` Pavel Machek
@ 2006-10-25 8:37 ` Michael S. Tsirkin
0 siblings, 0 replies; 68+ messages in thread
From: Michael S. Tsirkin @ 2006-10-25 8:37 UTC (permalink / raw)
To: Pavel Machek
Cc: Adrian Bunk, Linus Torvalds, Andrew Morton,
Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm,
jgarzik, linux-ide
Quoting r. Pavel Machek <pavel@suse.cz>:
> > >
> > > 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" <mst@mellanox.co.il>
> > > 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: 2.6.19-rc2: known unfixed regressions (v3)
2006-10-22 12:23 ` 2.6.19-rc2: known unfixed regressions (v3) Adrian Bunk
` (4 preceding siblings ...)
2006-10-24 15:00 ` Michael S. Tsirkin
@ 2006-10-24 17:27 ` Prakash Punnoor
2006-10-24 19:58 ` Adrian Bunk
5 siblings, 1 reply; 68+ messages in thread
From: Prakash Punnoor @ 2006-10-24 17:27 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 438 bytes --]
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 <prakash@punnoor.de>
> Status : patches are being discussed
2.6.19-rc3 contains a work-around. Case closed. :-)
--
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 68+ messages in thread