* Re: [ANNOUNCE] udev 089 release
From: Kay Sievers @ 2006-04-04 20:19 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20060403171123.GA24860@vrfy.org>
On Tue, Apr 04, 2006 at 09:56:16PM +0200, David Gómez wrote:
> Hi Kay,
>
> On Apr 04 at 09:51:10, Kay Sievers wrote:
> > > KERNEL="card*", NAME="dri/card%n", GROUP="video"
> >
> > Greg has fixed it and it works for me. What kernel is it?
>
> 2.6.16. I think the radeon module is having problems detecting the card (X300).
You probably need a new X server:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;hódd5c37382472a8b245ad791ed768771594e60c
Kay
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Jakub Narebski @ 2006-04-04 20:18 UTC (permalink / raw)
To: git
In-Reply-To: <7vhd596ua0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I was re-reading the hydra stuff and realized I've seen the "a
> cap that bundles independent tracks together" pattern somewhere
> else in the history of git.
>
> It is very similar to how "bind commit" would have worked.
[...]
> A "bind commit" proposal was made to support subprojects living
> in their own subdirectories. The picture to describe the commit
> ancestry chain would be almost the same as the above picture,
> except that it did not uncap and recap, but would have built its
> own ancestry chain.
One of versions of "hydra commit" proposals, in the mail which is yet to
appear on Gmane git mailing list archive, and Gmane NNTP interface to git
mailing list, was to define commit dependency (to which chain commit would
get) in the terms of affecting files in the same directory. Simple
generalization to subtree (directory and its subdirectories) gives "bind
commit for subprojects".
> It had two different kinds of commit relationships: parenthood
> and directory structure binding.
Great minds think alike :-P -- we (Sam and I) were talking on #git about
adding "depends-on" field to commit.
In the email to write I would propose that instead of adding "depends-on"
field (or "bind") one can at least in prototype stage make parallel
development, commiting simultaneously to the tree where history is history,
and to the tree where history is dependence, or bind. I hope I will make
myself clearer in upcoming message; see Sam post beginning this thread - we
want to make both pictures (on the left and on the right) simultaneously.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* RE: [patch 22/26] acpi memory hotplug cannot manage _CRS with plural resoureces
From: Moore, Robert @ 2006-04-04 20:16 UTC (permalink / raw)
To: Moore, Robert, KAMEZAWA Hiroyuki, Brown, Len
Cc: akpm, linux-acpi, kaneshige.kenji
Sorry, you should use acpi_os_free()
> -----Original Message-----
> From: Moore, Robert
> Sent: Monday, April 03, 2006 10:34 AM
> To: 'KAMEZAWA Hiroyuki'; Brown, Len
> Cc: akpm@osdl.org; linux-acpi@vger.kernel.org;
> kaneshige.kenji@jp.fujitsu.com
> Subject: RE: [patch 22/26] acpi memory hotplug cannot manage _CRS with
> plural resoureces
>
> > BTW, For freeing buffer.pointer (returned by acpi_get_object_info
etc.),
> > should I also use kfree() ?
> >
>
> For that (memory that was originally allocated by the acpica core),
you
> should use the ACPI_FREE macro.
>
> Bob
^ permalink raw reply
* Re: xenU/x86_64: error: incompatible type for argument 1 of 'pud_val'
From: Axel Thimm @ 2006-04-04 20:10 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
In-Reply-To: <s5hodzh72z4.wl%tiwai@suse.de>
[-- Attachment #1: Type: text/plain, Size: 2837 bytes --]
On Tue, Apr 04, 2006 at 05:52:15PM +0200, Takashi Iwai wrote:
> At Tue, 4 Apr 2006 13:15:57 +0200,
> Axel Thimm wrote:
> >
> > Hi,
> >
> > I'm trying to build rpms for alsa 1.0.11rc4 for several
> > distributions/arch in the RHEL/Fedora Core world and came across the
> > following issue:
> >
> > CC [M] /builddir/alsa-driver-1.0.11rc4/acore/memory_wrapper.o
> > /builddir/alsa-driver-1.0.11rc4/acore/memory_wrapper.c: In function 'snd_compat_vmalloc_to_page':
> > /builddir/alsa-driver-1.0.11rc4/acore/memory_wrapper.c:40: warning: implicit declaration of function 'VMALLOC_VMADDR'
> > /builddir/alsa-driver-1.0.11rc4/acore/memory_wrapper.c:45: error: incompatible type for argument 1 of 'pud_val'
> > /builddir/alsa-driver-1.0.11rc4/acore/memory_wrapper.c:46: warning: implicit declaration of function 'pte_offset'
> > /builddir/alsa-driver-1.0.11rc4/acore/memory_wrapper.c:46: warning: assignment makes pointer from integer without a cast
> >
> > That's on FC5/x86_64 building for the kernel flavour xenU
> > (guest). Building for FC5/i386 works.
>
> vmalloc_to_page() should exist in linux/mm.h in the case of 2.6
> kernel. Check config.log whether configure properly detected the
> function or not.
The check failed due to
configure:7067: checking for vmalloc_to_page
configure:7098: /usr/bin/gcc -c -Wall -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -I/kernel/include -nostdinc -iwithprefix include -DKBUILD_BASENAME="dummy" conftest.c >&5
In file included from /kernel/include/linux/smp.h:19,
from /kernel/include/linux/sched.h:26,
from /kernel/include/linux/mm.h:4,
from conftest.c:26:
/kernel/include/asm/smp.h: In function 'hard_smp_processor_id':
/kernel/include/asm/smp.h:78: warning: implicit declaration of function 'GET_APIC_ID'
/kernel/include/asm/smp.h:78: error: 'APIC_BASE' undeclared (first use in this function)
/kernel/include/asm/smp.h:78: error: (Each undeclared identifier is reported only once
/kernel/include/asm/smp.h:78: error: for each function it appears in.)
/kernel/include/asm/smp.h:78: error: 'APIC_ID' undeclared (first use in this function)
/kernel/include/asm/smp.h: In function 'cpu_present_to_apicid':
/kernel/include/asm/smp.h:113: error: 'BAD_APICID' undeclared (first use in this function)
/kernel/include/asm/smp.h: In function 'logical_smp_processor_id':
/kernel/include/asm/smp.h:136: warning: implicit declaration of function 'GET_APIC_LOGICAL_ID'
/kernel/include/asm/smp.h:136: error: 'APIC_BASE' undeclared (first use in this function)
/kernel/include/asm/smp.h:136: error: 'APIC_LDR' undeclared (first use in this function)
configure:7104: $? = 1
--
Axel.Thimm at ATrpms.net
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* RE: 2.6.17-rc1-mm1: why did acpi_ns_build_external_path() become global?
From: Moore, Robert @ 2006-04-04 20:07 UTC (permalink / raw)
To: Adrian Bunk, Andrew Morton, Brown, Len; +Cc: linux-kernel, linux-acpi
This interface is public now because it is used in common/dsrestag.c
This is the problem as I see it:
We have a continuing issue where we have a bunch of ACPI components
(interpreter, table manager, resource manager, etc.) Depending on how
the pieces are put together, various sub-parts of the components are
used or not used, depending on the application. The kernel-level code is
integrated into many different operating systems. Each OS used a
different subset of the available external interfaces. Further, each of
the user-level applications (iASL compiler, AcpiExec utility, etc.) use
different interfaces.
In this case, it is the iASL compiler that is using build_external_path.
We could certainly go so far as to put each public interface into a
separate file, allowing each application (and host OS) to pick and
choose the exact interfaces it needs (and I have seen it done this
way.), but this leads to a huge number of small files and I'm not sure
we want this.
However, attempting to track all of this with extensive #ifdefs, etc. is
awkward and ugly at best and very difficult to maintain.
I'm open to suggestions.
Bob
> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Adrian Bunk
> Sent: Tuesday, April 04, 2006 9:30 AM
> To: Andrew Morton; Brown, Len
> Cc: linux-kernel@vger.kernel.org; linux-acpi@vger.kernel.org
> Subject: 2.6.17-rc1-mm1: why did acpi_ns_build_external_path() become
> global?
>
> On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.16-mm2:
> >
> > git-acpi.patch
> >...
> > git trees.
> >...
>
> acpi_ns_build_external_path() became global but isn't used outside the
> file it's defined in.
>
> Was this accidental or is a usage pending?
>
> 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
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: 2.6.17-rc1-mm1: why did acpi_ns_build_external_path() become global?
From: Moore, Robert @ 2006-04-04 20:07 UTC (permalink / raw)
To: Adrian Bunk, Andrew Morton, Brown, Len; +Cc: linux-kernel, linux-acpi
This interface is public now because it is used in common/dsrestag.c
This is the problem as I see it:
We have a continuing issue where we have a bunch of ACPI components
(interpreter, table manager, resource manager, etc.) Depending on how
the pieces are put together, various sub-parts of the components are
used or not used, depending on the application. The kernel-level code is
integrated into many different operating systems. Each OS used a
different subset of the available external interfaces. Further, each of
the user-level applications (iASL compiler, AcpiExec utility, etc.) use
different interfaces.
In this case, it is the iASL compiler that is using build_external_path.
We could certainly go so far as to put each public interface into a
separate file, allowing each application (and host OS) to pick and
choose the exact interfaces it needs (and I have seen it done this
way.), but this leads to a huge number of small files and I'm not sure
we want this.
However, attempting to track all of this with extensive #ifdefs, etc. is
awkward and ugly at best and very difficult to maintain.
I'm open to suggestions.
Bob
> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Adrian Bunk
> Sent: Tuesday, April 04, 2006 9:30 AM
> To: Andrew Morton; Brown, Len
> Cc: linux-kernel@vger.kernel.org; linux-acpi@vger.kernel.org
> Subject: 2.6.17-rc1-mm1: why did acpi_ns_build_external_path() become
> global?
>
> On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.16-mm2:
> >
> > git-acpi.patch
> >...
> > git trees.
> >...
>
> acpi_ns_build_external_path() became global but isn't used outside the
> file it's defined in.
>
> Was this accidental or is a usage pending?
>
> 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
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: Does dom0 see all physical processors? (RE:[Xen-ia64-devel] SAL INFO virtualization)
From: Ian Pratt @ 2006-04-04 20:06 UTC (permalink / raw)
To: Magenheimer, Dan (HP Labs Fort Collins), Keir Fraser, Tian, Kevin
Cc: xen-ia64-devel, xen-devel, Tristan Gingold
> I understand and sympathize with the need for dom0 to
> sometimes get and use information from each processor that is
> only available if dom0 is running on each processor.
>
> However, AFAIK, SMP guests are always gang-scheduled, correct?
No, there's no need to strictly gang schedule, and the current scheduler makes no attempt to do so. It may generally be a decent thing to do, though.
> (If not, aren't there some very knotty research issues
> related to locking and forward progress?)
You could end up preempting a vCPU holding a lock which could lead to daft behaviour of naïve spin locks. A number of possible workarounds have been prototyped, but since it doesn't seem to be much of a problem in practice nothing has been checked in.
> So on a 16-processor system, every time dom0 needs to run
> (e.g. to handle backend I/O for any one of perhaps hundreds
> of domains), *every* domain gets descheduled so that dom0 can
> be (gang-)scheduled on all 16 processors?
>
> If true, this sounds like a _horrible_ performance hit, so I
> hope I'm misunderstanding something...
This isn't an issue.
After booting you probably want dom0 to give up all but 1 vCPU anyway.
Ian
^ permalink raw reply
* [Bug 6331] New: cpu frequency gets lowered by kernel when cord is pulled(init=bin/sh)
From: bugme-daemon @ 2006-04-04 20:03 UTC (permalink / raw)
To: cpufreq
http://bugzilla.kernel.org/show_bug.cgi?id=6331
Summary: cpu frequency gets lowered by kernel when cord is
pulled(init=bin/sh)
Kernel Version: 2.6.16 from kernel.org
Status: NEW
Severity: low
Owner: cpufreq@www.linux.org.uk
Submitter: mike@palczewski.net
Most recent kernel where this bug did not occur: unknown
Distribution: ubuntu dapper
Hardware Environment: Dell inspiron 9300 Inetl Pentium M 1.73 using
centrino-speedstep
Software Environment: ubuntu dapper gcc 4.0.3
Problem Description:
when ac cord is pulled (even in single user mode, or with init=/bin/sh)
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
get's set to the scaling_min_freq automatically
any scripts that run and try to set scaling_max_freq to something else end up
instead making sure that this gets reverted back to min freq
this is using the performance governor.
Steps to reproduce:
boot kernel with flag init=/bin/sh and ac plugged in (to make sure no other
scripts of anything could possibly be changing this)
# mount /sys
pull plug
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
repeat last step until it eventually goes back to the full frequency and stays
there.
a workaround for scrits that normally control these things is to have them sleep
for a while after an AC event has occured.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
^ permalink raw reply
* Re: [Alsa-devel] Slab corruptions & Re: 2.6.17-rc1: Oops in sound applications
From: Ken Moffat @ 2006-04-04 20:00 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Jan Niehusmann, Ken Moffat, linux-kernel, alsa-devel
In-Reply-To: <s5h7j656tpp.wl%tiwai@suse.de>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 258 bytes --]
On Tue, 4 Apr 2006, Takashi Iwai wrote:
> What happens if you copy the whole subtree linux/sound and
> linux/include/sound from 2.6.16?
also needs include/linux/sound.h (building at the moment)
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
^ permalink raw reply
* Re: [BUG] git-http-fetch segfault
From: Radoslaw Szkodzinski @ 2006-04-04 19:54 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Git Mailing List
In-Reply-To: <20060404184935.GG14967@reactrix.com>
[-- Attachment #1.1: Type: text/plain, Size: 1689 bytes --]
Nick Hengeveld wrote:
> On Tue, Apr 04, 2006 at 07:11:40PM +0200, Radoslaw Szkodzinski wrote:
>
>> I have some problems cloning stgit repository (maybe something's broken there).
>>
>> astralstorm@zen /home/devel $ git clone
>> http://homepage.ntlworld.com/cmarinas/stgit.git stgit
>> error: Unable to find adad46f365219e9bcc1a212826ca65eaac09729c under
>> http://homepage.ntlworld.com/cmarinas/stgit.git/
>> Cannot obtain needed blob adad46f365219e9bcc1a212826ca65eaac09729c
>> while processing commit 8847a11b3bbf5406f37a360e5466f0e392c56383.
>
> That host name resolves to multiple IP addresses, is it possible that
> one of the servers was out of sync? I tried cloning directly from each
> address and couldn't reproduce the problem.
>
Anyhow, git-http-fetch shouldn't segfault.
It's not my server, I don't know the exact configuration.
Also the repository is not mine.
It is reproducible here 100% of the time.
Here, it resolves like that:
astralstorm@zen $ resolveip homepage.ntlworld.com
IP address of homepage.ntlworld.com is 62.253.162.12
IP address of homepage.ntlworld.com is 62.253.162.178
IP address of homepage.ntlworld.com is 62.253.162.10
IP address of homepage.ntlworld.com is 62.253.162.11
I have an strace for you, bzipped and attached.
It is an output of the command:
strace -e 'trace=!poll,gettimeofday,select' -o fetch-strace.log git-http-fetch
-v -a -w heads/master heads/master http://homepage.ntlworld.com/cmarinas/stgit.git/
I hope it is enough to hunt the bug. If you need more info, please just ask.
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #1.2: fetch-strace.log.bz2 --]
[-- Type: application/octet-stream, Size: 15607 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply
* [lm-sensors] 2.6.16-rc5: unreasonable temperature reported by
From: Jean Delvare @ 2006-04-04 19:59 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <44144A01.2050207@t-online.de>
Harald,
> "Power control" reminds me of something: Sometimes ACPI power off
> doesn't work. Do you think this is a related problem?
I don't think so. The other I2C chips we've seen which were dealing
with "power" were usually VID control chips, which can be used to
slightly alter the CPU Vcore. This can be used for power-saving
purposes or overclocking purposes, depending on the change direction.
My understanding is that these chips should not be needed for regular
users. But then again, I don't know what _this_ chip does at all, so I
can't tell.
> Creating a driver on my own sounds pretty cool. Probably it is
> allowed to use an existing driver as a template?
Not allowed. Required ;)
Not absolutely required, in fact, but strongly encouraged, as this will
make it much easier for you. Hardware monitoring drivers have many
common points, and if you choose your template(s) properly, the new
driver can be done in no time and its review will be much faster too.
I didn't look at the datasheet for your chip yet (no time for this
sorry) so I can't tell you exactly which driver to start from. But this
should be an i2c-only driver (no platform driver, and no i2c-isa
trick.) Maybe lm90 will do, as it's both simple and up-to-date with
regards to recent changes. And you can always peek at other drivers for
the features your chip has and lm90 doesn't.
--
Jean Delvare
^ permalink raw reply
* Re: Patch-o-matic cleanup
From: Samuel Díaz García @ 2006-04-04 19:57 UTC (permalink / raw)
To: Netfilter Development Mailinglist; +Cc: Patrick McHardy
In-Reply-To: <443165AA.4030509@trash.net>
Patrick, after the last "cleanup" (18/9/2005?), many patches were removed
and 2.4/2.6 compatibility broken, for example the "condition" match over
2.6 or CONNMARK over 2.4.
I think, that if devteam are going to invert time to "cleanup" pomng,
would be fantastic that old ussefull and broken patches (or teorically
merged into kernel main base) must be reviewed.
For example, you put pptp_conntrack to be deleted, but I used it into 2.4
kernel versions, where it isn't into mainline.
That are the ticks I think you will need to take care of.
Good work, regards.
Patrick McHardy escribió:
> Following (quite late) the decision taken at the netfilter workshop to
> clean up the pomng repository by removing old patches and moving some
> patches out of the netfilter repository, I've started by removing the
> obsolete ipsec* patches and the policy match. Both have been merged
> and were pretty outdated.
>
> If noone can name good reasons against it, I will also remove the
> following patches in a few days:
>
> - NETLINK: obsolete
> - NETMAP: in mainline for a long time
> - TRACE: don't recall the reason, but its on my list :)
> - comment: in mainline
> - conntrack_locking: seriously outdated, if someone wants to resurrect
> this patch he can use the history
> - dropped_table: also don't recall the reason
> - goto: in mainline
> - ipq_vmark: obsoleted by nfnetlink_queue
> - mport: mainline multiport supports all of its features
> - netfilter-docbook: outdated
> - owner-socketlookup: unfixable broken
> - pool: obsoleted by ipset
> - pptp-conntrack-nat: in mainline now, patches are missing critical
> fixes
> - unclean: bad idea
>
>
>
--
Samuel Díaz García
Director Gerente
ArcosCom Wireless, S.L.L.
CIF: B11828068
c/ Romero Gago, 19
Arcos de la Frontera
11630 - Cadiz
http://www.arcoscom.com
mailto:samueldg@arcoscom.com
msn: samueldg@arcoscom.com
Móvil: 651 93 72 48
Tlfn.: 956 70 13 15
Fax: 956 70 34 83
^ permalink raw reply
* Re: blade servers?
From: Wes Felter @ 2006-04-04 19:55 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20060404024244.28E9A5F76B@work.bitmover.com>
Larry McVoy wrote:
> I figured that people here would know. If you were looking for blade
> servers and you were more interested in cost and heat generation than the
> most performance, what would you buy?
Consider systems based on the "Sossaman" Xeon LV processor; it has good
integer performance and low power.
For example, at IBM we just released a new model of the BladeCenter HS20
(model 7981); I've seen one of these servers using only 100W when
running. Real servers are never going to be as cheap as the cheapest
whiteboxes, but they do run cool.
Wes Felter - wesley@felter.org
^ permalink raw reply
* Re: [ANNOUNCE] udev 089 release
From: David Gómez @ 2006-04-04 19:56 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20060403171123.GA24860@vrfy.org>
Hi Kay,
On Apr 04 at 09:51:10, Kay Sievers wrote:
> > KERNEL="card*", NAME="dri/card%n", GROUP="video"
>
> Greg has fixed it and it works for me. What kernel is it?
2.6.16. I think the radeon module is having problems detecting the card (X300).
Thanks for the fast reply ;)
--
David Gómez Jabber ID: davidge@jabber.org
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: [ANNOUNCE] udev 089 release
From: Kay Sievers @ 2006-04-04 19:51 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20060403171123.GA24860@vrfy.org>
On Tue, Apr 04, 2006 at 09:46:11PM +0200, David Gómez wrote:
>
> BTW, with udev-089 the drm devices are not created. The rule
> in my config scripts is:
>
> KERNEL="card*", NAME="dri/card%n", GROUP="video"
Greg has fixed it and it works for me. What kernel is it?
Kay
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* [lm-sensors] 2.6.16-rc5: unreasonable temperature reported by
From: Jean Delvare @ 2006-04-04 19:49 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <44144A01.2050207@t-online.de>
Hallo Harald,
> > This is some kind of "high-density" PC, i.e. it is hard to disassemble.
> > I was lucky that the first chip was easy to spot, but the second one
> > could be anywhere. I would suggest to postpone this to tomorrow.
>
> I have opened the case, removed the power supply and the harddisk,
> but I did not find another Fintek chip. Is it possible that it
> is close to the CPU, maybe below the cooler, or so?
>
> Maybe it is integrated on the chip we found?
I doubt it. My Fintek contact told me it is a custom ASIC they made
for just one company, so I'm almost certain it's a separate chip. Maybe
it doesn't even have Fintek's usual top marking because of the "custom"
aspect.
No need to search any further anyway, finding the chip won't help us.
Fintek cannot provide a datasheet for custom ASICs. And that chip might
not need a driver in the first place.
--
Jean Delvare
^ permalink raw reply
* [linux-lvm] pvmove on a root partition
From: Christopher Probst @ 2006-04-04 18:58 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <20060404123532.GD21526@dragonhold.org>
Hello LVMers
Doing a pvmove
pvmove /dev/hdb1 /dev/hdb2 where /dev/hdb1 is mounted on "/"
makes my system unuseable. I can't log into my machine even in a text
console. Has anybody tried this before?
Christo
^ permalink raw reply
* Re: [ANNOUNCE] udev 089 release
From: David Gómez @ 2006-04-04 19:46 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20060403171123.GA24860@vrfy.org>
Hi,
On Apr 03 at 07:11:23, Kay Sievers wrote:
> Provide "udevtrigger" program to request events on coldplug. The
> shell script is much too slow with thousends of devices.
Nice solution for the generating coldplugging events ;).
BTW, with udev-089 the drm devices are not created. The rule
in my config scripts is:
KERNEL="card*", NAME="dri/card%n", GROUP="video"
But i was having some problems with the radeon DRM module (DRI
not working), so maybe this is no udev problem, but a radeon
driver problem. I just remembered a message in this list about
drm devices so i wanted to ask to the list if this problem was
fixed.
Thanks,
--
David Gómez Jabber ID: davidge@jabber.org
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: [Qemu-devel] Missing ARMv6 instructions?
From: Daniel Jacobowitz @ 2006-04-04 19:42 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <1143996162.6857.110.camel@localhost>
On Sun, Apr 02, 2006 at 04:42:42PM +0000, Chris Wilson wrote:
> Hi Jamie,
>
> > I like the idea, but do you know of anyone using OpenCores devices
> > implemented in silicon? It seems to me the motivation for ARM
> > emulation is to be able to simulate embedded devices that people may
> > feasibly end up using.
>
> I'm no expert, but it appears that OpenCores have a working core that
> runs most of the MIPS instruction set. MIPS is a very well known, tried
> and trusted architecture. My cable modem has a MIPS-compatible processor
> made by Toshiba. It seems to me that MIPS is just as realistic and
> usable platform as ARM. But I would be very interested to hear from
> anyone who knows better.
>
> Now, I wonder when Qemu will support MIPS emulation? :-)
Good question. How about... last year?
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply
* Re: 2.6.17-rc1-mm1: KEXEC became SMP-only
From: Muli Ben-Yehuda @ 2006-04-04 19:38 UTC (permalink / raw)
To: Zachary Amsden
Cc: Eric W. Biederman, Adrian Bunk, Andrew Morton, linux-kernel,
rdunlap, fastboot
In-Reply-To: <4432C7AC.9020106@vmware.com>
On Tue, Apr 04, 2006 at 12:23:24PM -0700, Zachary Amsden wrote:
> This gets rid of both the code duplication and makes it somewhat more
> obvious what is going on - plus it is easy to extend to other functions,
> and as a bonus feature, you don't need to change any code in other
> subarchitectures if you need to add a new hook.
ppc has 'struct machdep_calls' (asm-powerpc/machdep.h) which serves
the same purpose, and it's indeed a clean way of doing this sort of
thing.
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
^ permalink raw reply
* [Qemu-devel] SPARC iommu mapping
From: Joerg Platte @ 2006-04-04 19:27 UTC (permalink / raw)
To: qemu-devel
Hi!
I still have problems when using a disk image for the SPARC system emulator.
Reading and writing now works better than in previous versions, but sometimes
data written to image is simply corrupt. To find this problem I wrote a small
program writing data to the beginning of a disk image. Afterwards I compared
the written data in the image with the expected values. Most of the data was
correct, but sometimes a few pages mostly contains only zeros.
To find this problem, I enabled debugging in the esp.c file and printed the
mapped address (after iommu mapping). In some cases the mapped address is
zero:
Normal write:
ESP: DMA Direction: r, addr 0x008fd000 0000000b
ESP: DMA Direction: r, addr 0x0bea1000 0000e000
ESP: DMA address 0bea2000
ESP: DMA address 0bea4000
ESP: DMA address 0bea5000
ESP: DMA address 0bea6000
ESP: DMA address 0bea7000
ESP: DMA address 0bea8000
ESP: DMA address 0bea9000
ESP: DMA address 0beaa000
ESP: DMA address 0beab000
ESP: DMA address 0beac000
ESP: DMA address 0bead000
ESP: DMA address 0beaf000
ESP: DMA address 0beb0000
Faulty write:
ESP: DMA Direction: r
ESP: DMA Direction: r, addr 0x008fd000 0000000b
ESP: DMA Direction: r, addr 0x0beb1000 0000e000
ESP: DMA address 0beb2000
ESP: DMA address 0beb3000
ESP: DMA address 0beb4000
ESP: DMA address 0beb5000
ESP: DMA address 0beb6000
ESP: DMA address 0beb7000
ESP: DMA address 0beb8000
ESP: DMA address 00000000
I used this code in handle_ti to produce this output:
dmaptr = iommu_translate(s->espdmaregs[1] + i);
if ((olddma&0xfffff000) != (dmaptr&0xfffff000)) {
DPRINTF("DMA address %08x\n", dmaptr);
olddma=dmaptr;
}
Unfortunately, I'm no hardware or SPARC expert and it took a whole day to
track down this problem. So I'm not able to find the reason for this
behaviour. What may cause the wrong mapping? Is this some kind of page fault,
which must be handled by the kernel? Or just a bug?
regards,
Jörg
^ permalink raw reply
* Re: 2.6.16-rt10
From: Steven Rostedt @ 2006-04-04 19:27 UTC (permalink / raw)
To: Simon Derr; +Cc: Ingo Molnar, linux-kernel
In-Reply-To: <Pine.LNX.4.61.0604041726490.15050@openx3.frec.bull.fr>
On Tue, 4 Apr 2006, Simon Derr wrote:
>
> But I must be severely misunderstanding something.
>
> What I understood is that in preemptible sections preempt_count() is
> zero, and in non preemptible sections it is >0.
>
> If preempt_count() is 1, then preempt_enable_no_resched() will decrement
> it and issue a warning. This is what happens in disabled_fph_fault().
>
> Where am I wrong ?
You're not.
There's nothing unstable about it. The problem is that you didn't
schedule when you could have. With Linux, this really isn't an issue,
but with the -rt kernel we concentrate on low latency, and by not
calling schedule when preempt count goes to zero and the need_resched
flag may be set, you may be delaying a high priority process
unnecessarily, for longer than needed. This in the -rt kernel _is_ a
bug.
So for a stability point of view, that missed schedule wont crash the
kernel, but it might cause an xrun in JACK.
Now, sometimes a call to preempt_enable_no_resched is called just before
schedule is called, this is done so you don't have a double schedule.
For this, it is ok to call *_no_resched, but you need to flag that this
is ok by calling __preempt_enable_no_resched directly.
-- Steve
^ permalink raw reply
* RE: Does dom0 see all physical processors? (RE: [Xen-ia64-devel] SAL INFO virtualization)
From: Magenheimer, Dan (HP Labs Fort Collins) @ 2006-04-04 19:27 UTC (permalink / raw)
To: Keir Fraser, Tian, Kevin; +Cc: Tristan Gingold, xen-devel, xen-ia64-devel
I understand and sympathize with the need for dom0 to
sometimes get and use information from each processor
that is only available if dom0 is running on each processor.
However, AFAIK, SMP guests are always gang-scheduled, correct?
(If not, aren't there some very knotty research issues related
to locking and forward progress?)
So on a 16-processor system, every time dom0 needs to
run (e.g. to handle backend I/O for any one of perhaps hundreds
of domains), *every* domain gets descheduled so that dom0
can be (gang-)scheduled on all 16 processors?
If true, this sounds like a _horrible_ performance hit, so
I hope I'm misunderstanding something...
Dan
> -----Original Message-----
> From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk]
> Sent: Tuesday, April 04, 2006 1:26 AM
> To: Tian, Kevin
> Cc: xen-devel; xen-ia64-devel@lists.xensource.com;
> Magenheimer, Dan (HP Labs Fort Collins); Tristan Gingold
> Subject: Re: [Xen-devel] Does dom0 see all physical
> processors? (RE: [Xen-ia64-devel] SAL INFO virtualization)
>
>
> On 4 Apr 2006, at 03:17, Tian, Kevin wrote:
>
> >
> > Then consider your question about a large box with many processors.
> > How about the real environment? Is it the case to provide a
> 16-way SMP
> > box, or a 16-way NUMA box? I prefer to the latter. If it's
> a NUMA box,
> > dom0 sees physical ACPI table and can be configured as NUMA aware.
>
> This is a model we must support if we are to have domain0
> handle other
> processor-related ACPI activities (e.g., power management). The power
> information and available settings won't make much sense to the user
> unless there's an equivalence between VCPUs and PCPUs for domain0.
>
> -- Keir
>
>
^ permalink raw reply
* Re: Help with Averatec C3500
From: Bjorn Helgaas @ 2006-04-04 19:26 UTC (permalink / raw)
To: Michael J. Kidd; +Cc: linux-acpi, Alan Stern
In-Reply-To: <442EB141.5040205@linuxkidd.com>
On Saturday 01 April 2006 09:58, Michael J. Kidd wrote:
> I have an Averatec C3500 Convertible Tablet PC. With the initial bios
> version that ships with the unit, USB and PCMCIA both work fine in
> linux. However, there is a terrible keyboard lag and dropped keys. The
> follow-on bios revisions fixed the keyboard issues, but caused USB and
> PCMCIA to both stop working. Note: All devices continue to operate fine
> in Windows. I'm posting this here in hopes that someone will take
> interest in this issue ( there are several others trying to use linux on
> these laptops. ) I've captured dmesg output after enabling
> CONFIG_USB_DEBUG and CONFIG_PCMCIA_DEBUG in the kernel config, and the
> output from lspci -vvxxx, as well as the DSDT output from both the
> original BIOS ( USB working / Keyboard not ) and the latest BIOS
> revision ( USB Not working / Keyboard works great ).
>
> The link for all this captured data is: http://www.linuxkidd.com/c3500
> I've detailed the machine hardware, running kernel, etc.. as well as
> linked to all the above described captures.
Thanks for your effort in debugging this. Can you please open a
bug report at http://bugzilla.kernel.org?
> After posting the above request to the linux-usb list, Alan Stern
> responded with:
> ----------------------------------------------------------------------
> According to the log, the I/O memory mappings for the USB and PCMCIA
> controllers aren't getting set up. It's not a USB or PCMCIA issue at all;
> you should ask for help on the PCI and ACPI mailing lists.
I don't know enough about USB to know what you're referring to.
Can you point out the messages that suggest a PCI or ACPI issue?
Bjorn
^ permalink raw reply
* Re: 2.6.17-rc1-mm1: KEXEC became SMP-only
From: Zachary Amsden @ 2006-04-04 19:23 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Adrian Bunk, Andrew Morton, linux-kernel, rdunlap, fastboot
In-Reply-To: <m1irpp41wx.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman wrote:
>
> If all you are doing is this one little clean up we can probably stop here.
> But this looks like a start on getting a vmi or xen subarch working.
>
Yes, that is certainly part of the purpose. But the subarch layer
really should be cleaned up, and getting rid of code duplication seems
like a good first step.
> If this is really a prelude to introducing more subarchitectures we
> need to fix the infrastructure, so it is obvious what is going on.
> I would really like to see a machine vector, so we could compile in
> multiple subarchitectures at the same time. That makes building
> a generic kernel easier, and the requirement that the we need
> to build a generic kernel makes the structure of the subarchiteture
> hooks hierarchical and you wind up with code whose dependencies
> are visible. Instead of the current linker and preprocessor magic.
> Functions named hook are impossible to comprehend what they
> are supposed to do while reading through the code.
>
I see your point. Are you thinking of something like:
struct subarch_hooks subarch_hook_vector = {
.machine_power_off = machine_power_off,
.machine_halt = machine_halt,
.machine_irq_setup = machine_irq_setup,
.machine_subarch_setup = machine_subarch_probe
...
};
And machine_subarch_probe can dynamically change this vector if it
confirms that the platform is appropriate?
This gets rid of both the code duplication and makes it somewhat more
obvious what is going on - plus it is easy to extend to other functions,
and as a bonus feature, you don't need to change any code in other
subarchitectures if you need to add a new hook.
Zach
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.