* Re: [v4l-dvb-maintainer] Re: drivers/media/video/saa7115.c misreports max. value of contrast and saturation
From: Hans Verkuil @ 2006-03-08 21:42 UTC (permalink / raw)
To: v4l-dvb-maintainer; +Cc: Adrian Bunk, Kyler Laird, mchehab, linux-kernel
In-Reply-To: <20060308211900.GM4006@stusta.de>
On Wednesday 08 March 2006 22:19, Adrian Bunk wrote:
> On Wed, Feb 15, 2006 at 12:19:08AM -0500, Kyler Laird wrote:
> > For changes to V4L2_CID_CONTRAST and V4L2_CID_SATURATION, the value
> > is checked by "if (ctrl->value < 0 || ctrl->value > 127)" yet the
> > maximum value in v4l2_queryctrl is set to 255 for both of these
> > items. This means that programs (like MythTV) which set the
> > contrast and saturation to the midvalue (127) get *full* contrast
> > and saturation. (It's not pretty.)
> >
> > Setting the maximum values to 127 solves this problem.
>
> Mauro, can you comment on this issue?
It's fixed with the patch with subject '[PATCH 08/13] Fix maximum for
the saturation and contrast controls.' It was posted by Mauro to the
linux mailinglist a week ago. I hope it will be fixed in 2.6.16, but
Mauro should know more about it. It was a stupid copy-and-paste bug so
I see no reason why it shouldn't go in.
> > Please copy me on responses.
> >
> > Thank you.
> >
> > --kyler
>
> cu
> Adrian
^ permalink raw reply
* Re: [PATCH] Define flush_wc, a way to flush write combining store buffers
From: Benjamin LaHaise @ 2006-03-08 21:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Bryan O'Sullivan, akpm, ak, paulus, linux-kernel
In-Reply-To: <1141853919.11221.183.camel@localhost.localdomain>
On Thu, Mar 09, 2006 at 08:38:39AM +1100, Benjamin Herrenschmidt wrote:
> I think people already don't undersatnd the existing gazillion of
> barriers we have with quite unclear semantics in some cases, it's not
> time to add a new one ...
We went over the details of this in a pretty long thread, and you can't
use any of the existing memory barriers to solve this particular problem.
I think the definition of this one is well done now.
-ben
--
"Time is of no importance, Mr. President, only life is important."
Don't Email: <dont@kvack.org>.
^ permalink raw reply
* Re: [PATCH] Define flush_wc, a way to flush write combining store buffers
From: Bryan O'Sullivan @ 2006-03-08 21:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: akpm, ak, paulus, bcrl, linux-kernel
In-Reply-To: <1141853919.11221.183.camel@localhost.localdomain>
On Thu, 2006-03-09 at 08:38 +1100, Benjamin Herrenschmidt wrote:
> I think people already don't undersatnd the existing gazillion of
> barriers we have with quite unclear semantics in some cases, it's not
> time to add a new one ...
What do you suggest I do, then? This makes a substantial difference to
performance for us. Should I confine this somehow to the ipath driver
directory and have a nest of ifdefs in an include file there?
<b
^ permalink raw reply
* Re: [Bluez-devel] PIN helper
From: Dave Mielke @ 2006-03-08 21:40 UTC (permalink / raw)
To: bluez-devel
In-Reply-To: <20060308221925.17d20407.fotopiper@o2.pl>
[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]
[quoted lines by Radek on 2006/03/08 at 22:19 +0100]
>from whot I had read in the net there had been some controversies about
>the pinhelpers. The d-bus one need d-bus, and the python one need some
>extra libs as well as X..
May I use this opportunity to "readvertise" a script I tried to bring to your
collective attention some months ago. It's attached to this post as "bluepin".
It works in text mode, supports a file containing address/pin mappings, and
uses the dialog utility to bring up a text-mode prompt on a spare virtual
terminal for devices not listed in the file. Please give it some consideration.
I'll be glad to enhance it as necessary regarding whatever features it's
missing or could use in addition to what it already does. See the comments at
the top of the script for more detail.
--
Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the
Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me
EMail: dave@mielke.cc | Canada K2A 1H7 | if you're concerned about Hell.
http://FamilyRadio.com/ | http://Mielke.cc/bible/
[-- Attachment #2: bluepin --]
[-- Type: text/plain, Size: 1956 bytes --]
#!/bin/sh
# This script has been written by Dave Mielke <dave@mielke.cc>. It's a light
# weight, text mode, Bluetooth PIN helper script. Its dependencies are:
# * /bin/sh The standard system command shell.
# * open A command which opens a free virtual terminal.
# * dialog A command which presents a text-mode dialog.
#
# The file /etc/bluetooth/pins is searched for a line corresponding to the
# Bluetooth address of the device. Each line of this file should contain the
# address of a device and its PIN, in that order, separated by space. If the
# address is found then the corresponding PIN is automatically supplied. If
# it's not found then the user is prompted via a text-mode dialog in a free
# virtual terminal. The console automatically returns to the original virtual
# terminal as soon as the PIN is entered.
pinsFile="/etc/bluetooth/pins"
pinLimit=16
[ "${#}" -gt 0 ] && {
direction="${1}"
shift
[ "${#}" -gt 0 ] && {
address="${1}"
shift
if [ "${#}" -gt 0 ]
then
name="${1}"
shift
else
name=""
fi
[ -f "${pinsFile}" -a -r "${pinsFile}" ] && exec <"${pinsFile}" && {
while read a p x
do
[ "${a}" = "${address}" ] && {
echo "PIN:${p}"
exit 0
}
done
}
if [ "${direction}" = "out" ]
then
adjective="outgoing"
preposition="to"
else
adjective="incoming"
preposition="from"
fi
title="Bluetooth PIN Prompt"
time="`date '+%Y-%m-%d@%H:%M:%S'`"
prompt="Enter PIN for ${adjective} Bluetooth connection ${preposition} ${name}[${address}]"
pin="`open 3>&1 -s -w -- dialog --output-fd 3 --clear --title "${title}" --cr-wrap --max-input "${pinLimit}" --inputbox "${time}\n\n${prompt}" 0 0 ""`"
[ -n "${pin}" ] && {
echo "PIN:${pin}"
exit 0
}
}
}
echo ERR
exit 0
^ permalink raw reply
* Bt87x Audio Capture
From: Ondrej Ivanič @ 2006-03-08 21:39 UTC (permalink / raw)
To: alsa-devel
Hi
I have problems with audio capture function on my tv card. After
`modprobe snd_bt87x', I have got nothing in logs (dmesg, messages).
Last relevant info is from bt878 module:
bt878: AUDIO driver version 0.0.0 loaded
bt878: Bt878 AUDIO function found (0).
PCI: Found IRQ 12 for device 0000:00:0a.1
PCI: Sharing IRQ 12 with 0000:00:0a.0
bt878(0): Bt878 (rev 17) at 00:0a.1, irq: 12, latency: 64, memory:
0xe9000000
PCI: Found IRQ 10 for device 0000:00:0c.0
PCI: Sharing IRQ 10 with 0000:00:07.2
lspci output:
$ lspci -s 00:0a -vn
00:0a.0 0400: 109e:036e (rev 11)
Subsystem: 11bd:0012
Flags: bus master, medium devsel, latency 64, IRQ 12
Memory at e9002000 (32-bit, prefetchable) [size=4K]
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2
00:0a.1 0480: 109e:0878 (rev 11)
Subsystem: 11bd:0012
Flags: bus master, medium devsel, latency 64, IRQ 12
Memory at e9000000 (32-bit, prefetchable) [size=4K]
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2
$ lspci -s 00:0a
00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 Video
Capture (rev 11)
00:0a.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture
(rev 11)
alsa configuration:
alias snd-card-0 snd-ens1371
alias snd-card-1 snd-bt87x
alias sound-slot-0 snd-card-0
alias sound-slot-1 snd-card-1
options snd-bt87x id="tv" load_all=1
# OSS/Free portion - card #1
alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss
## OSS/Free portion - card #2
alias sound-service-1-0 snd-mixer-oss
alias sound-service-1-3 snd-pcm-oss
alias sound-service-1-12 snd-pcm-oss
alias /dev/mixer snd-mixer-oss
alias /dev/dsp snd-pcm-oss
alias /dev/midi snd-seq-oss
options snd cards_limit=2
lsmod output:
$ lsmod
Module Size Used by
snd_bt87x 11496 0
snd_seq_midi 6816 0
snd_pcm_oss 49440 0
snd_mixer_oss 17088 1 snd_pcm_oss
snd_seq_oss 31552 0
snd_seq_midi_event 5664 2 snd_seq_midi,snd_seq_oss
snd_seq 47824 5 snd_seq_midi,snd_seq_oss,snd_seq_midi_event
snd_ens1371 18596 0
snd_rawmidi 19840 2 snd_seq_midi,snd_ens1371
snd_seq_device 6732 4 snd_seq_midi,snd_seq_oss,snd_seq,snd_rawmidi
snd_ac97_codec 93088 1 snd_ens1371
snd_ac97_bus 1728 1 snd_ac97_codec
bt878 8088 0
tuner 43012 0
tda9887 14352 0
msp3400 32848 0
bttv 158480 1 bt878
video_buf 17060 1 bttv
i2c_algo_bit 8360 1 bttv
btcx_risc 3912 1 bttv
tveeprom 13744 1 bttv
i2c_core 16752 6
tuner,tda9887,msp3400,bttv,i2c_algo_bit,tveeprom
snd_pcm 79976 4
snd_bt87x,snd_pcm_oss,snd_ens1371,snd_ac97_codec
snd_timer 20580 2 snd_seq,snd_pcm
snd 44804 11
snd_bt87x,snd_pcm_oss,snd_mixer_oss,snd_seq_oss,snd_seq,snd_ens1371,snd_rawmidi,snd_seq_device,snd_ac97_codec,snd_pcm,snd_timer
soundcore 7168 1 snd
snd_page_alloc 8424 2 snd_bt87x,snd_pcm
I don't have an idea what is wrong, because I can't found any output
from snd_bt87x module.
Thanks
PS. I'm not on the list. Send CC to me, please.
--
Ondrej Ivanic
(ondrej@kmit.sk)
-------------------------------------------------------
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=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: [PATCH] Define flush_wc, a way to flush write combining store buffers
From: Benjamin Herrenschmidt @ 2006-03-08 21:38 UTC (permalink / raw)
To: Bryan O'Sullivan; +Cc: akpm, ak, paulus, bcrl, linux-kernel
In-Reply-To: <e27c8e0061e03594b3e1.1141853501@localhost.localdomain>
On Wed, 2006-03-08 at 13:31 -0800, Bryan O'Sullivan wrote:
> In some circumstances, a CPU may perform stores to memory in non-program
> order, or held in on-chip store buffers for a potentially long time.
> These kinds of circumstances include:
>
> - Stores to a PCI MMIO region that has write combining enabled
>
> - Use of non-temporal store instructions
>
> - The CPU's memory model permitting weak store ordering
>
> This patch introduces a new macro, flush_wc(), that flushes any pending
> stores from the local CPU's write combining store buffers, if the CPU has
> such a capability. If the CPU doesn't provide explicit control over write
> combining, flush_wc() is simply an alias for wmb(). Here is an example:
I think people already don't undersatnd the existing gazillion of
barriers we have with quite unclear semantics in some cases, it's not
time to add a new one ...
Ben.
^ permalink raw reply
* [Xenomai-core] Anybody Has Sample Code of Message Queue Performance Measurement in User Space for Xenomai Native Mode?
From: Wu, John @ 2006-03-08 21:35 UTC (permalink / raw)
To: xenomai; +Cc: Chau, Ngaiman, Wu, John
[-- Attachment #1: Type: text/plain, Size: 161 bytes --]
We are in the process of calibrating Xenomai native API message queue
performance in user space application. Does anybody has sample code to
share with us?
[-- Attachment #2: Type: text/html, Size: 506 bytes --]
^ permalink raw reply
* via-rhine.c PXE revisited
From: Joerg Bashir @ 2006-03-08 21:35 UTC (permalink / raw)
To: linux-kernel
I'm PXE booting a few hundred VIA Epia M based boards with 2.6.x.
While there is a fix for the PXEROM it requires rolling your own VIA BIOS
to incorporate it. VIA has not released a BIOS update for this board
since late 2004, and our vendor is not receiving any linux love from VIA
about this issue.
Therefore, it's still necessary to comment out line 1968 in
drivers/net/via-rhine.c (from 2.6.16-rc5 for example)
/* Hit power state D3 (sleep) */
/* iowrite8(ioread8(ioaddr + StickyHW) | 0x03, ioaddr + StickyHW);
*/
/* TODO: Check use of pci_enable_wake() */
Previously on the LKML the issue with setting this option was breaking
WOL on other versions of this hardware.
Is it a feasible request a config option to address this issue?
It's quite obviously a firmware bug in the PXEROM as Alan Cox clearly
pointed out last time around. See http://lkml.org/lkml/2004/11/11/151
I know it's a lame request in order to avoid patching a kernel every time
it comes out instead of being able to do make oldconfig and have it just
work... but I thought I'd ask.
Thanks,
Joerg
Here is lspci from those boxen...
0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8623 [Apollo CLE266]
0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP]
0000:00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host
Controller (rev 80)
0000:00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 80)
0000:00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 80)
0000:00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 80)
0000:00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
0000:00:11.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
0000:00:11.5 Multimedia audio controller: VIA Technologies, Inc.
VT8233/A/8235/8237 AC97 Audio Controller (rev 50)
0000:00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II]
(rev 74)
0000:01:00.0 VGA compatible controller: VIA Technologies, Inc. VT8623
[Apollo CLE266] integrated CastleRock graphics (rev 03)
^ permalink raw reply
* Re: usbkbd not reporting unknown keys
From: Matheus Izvekov @ 2006-03-08 21:34 UTC (permalink / raw)
To: dtor_core; +Cc: linux-kernel
In-Reply-To: <d120d5000603081247i69f9e7dbm6ef614f50140227f@mail.gmail.com>
On 3/8/06, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> On 3/8/06, Matheus Izvekov <mizvekov@gmail.com> wrote:
> > Just discovered it needs usb debugging to be set. But isnt
> > inconsistent the fact that the atkbd driver does this differently from
> > the usbkbd driver? If its a good idea to print those messages by
> > default or one, why its not for the other?
>
> usbkbd will only report standard keys and is supposed in limited
> circumstances so it complaining about unknown keys is not very useful.
> Why do you need it? Doesn't hid driver work for you?
>
> --
> Dmitry
>
It works, except that i have some multimedia keys which are not
mapped. Im going to add those to the table soon, thats why i needed
those messages. So you think the usbkbd behaviour is the correct one,
and the default behaviour must be changed in the atkbd driver?
^ permalink raw reply
* Re: Request for feedback on Generic Timeofday Subsystem (B20)
From: Luck, Tony @ 2006-03-08 21:33 UTC (permalink / raw)
To: john stultz; +Cc: linux-arch
In-Reply-To: <1141772520.21582.36.camel@leatherman>
On Tue, Mar 07, 2006 at 03:01:58PM -0800, john stultz wrote:
> You are right there. The jitter handling (if I recall, basically a
> cmpxchg w/ the last read cycle value to be sure the clocksource doesn't
> go backward) wouldn't be doable in userspace, but it seems that would
> already be a pretty bad hit on performance. Is it not? And how many
> systems actually use unsycned/jittery ITCs instead of alternative mmioed
> clocksources?
Yes the cmpxchg can be painful on a large NUMA ... so those systems tend
to use a non-jittery source. Smaller machines may not have access (as
BIOS may not describe where the HPET is), and there is also a tradeoff
since reading the "ar.itc" register is much faster[1] than reading some
bus-based clock ... so the cmpxchg may not hurt too badly if you only
have a few cpus.
> Regardless, if its really a blocking issue, I'm not opposed to putting
> the direct access methods back into the structure, or going with an
> alternative solution to make these bits doable. Ingo might have a better
> idea for this as well.
I'm always open to a "better idea" ... but if one of those fails to show up
then I'd like to have the direct access methods.
> Do you have any other issues or questions?
Not at this time.
-Tony
[1] Ok, "is less slow than" (reading ar.itc isn't "fast" either).
^ permalink raw reply
* [PATCH] Define flush_wc, a way to flush write combining store buffers
From: Bryan O'Sullivan @ 2006-03-08 21:31 UTC (permalink / raw)
To: akpm, ak, paulus, benh, bcrl; +Cc: linux-kernel
In some circumstances, a CPU may perform stores to memory in non-program
order, or held in on-chip store buffers for a potentially long time.
These kinds of circumstances include:
- Stores to a PCI MMIO region that has write combining enabled
- Use of non-temporal store instructions
- The CPU's memory model permitting weak store ordering
This patch introduces a new macro, flush_wc(), that flushes any pending
stores from the local CPU's write combining store buffers, if the CPU has
such a capability. If the CPU doesn't provide explicit control over write
combining, flush_wc() is simply an alias for wmb(). Here is an example:
store A
store B
store C
flush_wc()
store D
store E
flush_wc()
flush_wc() says nothing about whether {A,B,C} may be reordered with
respect to each other, or whether {D,E} may, but it guarantees that
{A,B,C} will make it off-CPU before {D,E}. An arch that implements
flush_wc() should make the stores occur immediately, if possible.
In the case of writes to remote NUMA memory or PCI MMIO space, a
bridge chip may still hold on to stores after they've been issued by
the CPU. Thus flush_wc() makes no guarantees regarding the visibility
of stores to other CPUs, remote memory, or PCI devices.
The intention is that flush_wc() will typically be used for
latency-sensitive MMIO writes where the full cost of guaranteeing that
the writes have made it all the way to their target is not necessary
or desirable.
It is implemented by way of a new header file, <linux/system.h>.
This header can be a site for oft-replicated code from <asm-*/system.h>,
but isn't just yet.
Signed-off-by: Bryan O'Sullivan <bos@pathscale.com>
diff -r c89918da5f7b -r e27c8e0061e0 include/asm-i386/system.h
--- a/include/asm-i386/system.h Sat Feb 25 08:01:07 2006 +0800
+++ b/include/asm-i386/system.h Wed Mar 8 13:28:29 2006 -0800
@@ -502,6 +502,12 @@ struct alt_instr {
#define wmb() __asm__ __volatile__ ("": : :"memory")
#endif
+/*
+ * Flush the CPU's write combining store buffers.
+ */
+#define flush_wc() alternative("lock; addl $0,0(%%esp)", "sfence", \
+ X86_FEATURE_XMM)
+
#ifdef CONFIG_SMP
#define smp_mb() mb()
#define smp_rmb() rmb()
diff -r c89918da5f7b -r e27c8e0061e0 include/asm-powerpc/system.h
--- a/include/asm-powerpc/system.h Sat Feb 25 08:01:07 2006 +0800
+++ b/include/asm-powerpc/system.h Wed Mar 8 13:28:29 2006 -0800
@@ -53,6 +53,12 @@
#define smp_wmb() barrier()
#define smp_read_barrier_depends() do { } while(0)
#endif /* CONFIG_SMP */
+
+/*
+ * Guarantee store/store ordering. On some arches, this flushes the CPU's
+ * write combining store buffers.
+ */
+#define flush_wc() __asm__ __volatile__ ("eieio" : : : "memory")
struct task_struct;
struct pt_regs;
diff -r c89918da5f7b -r e27c8e0061e0 include/asm-x86_64/system.h
--- a/include/asm-x86_64/system.h Sat Feb 25 08:01:07 2006 +0800
+++ b/include/asm-x86_64/system.h Wed Mar 8 13:28:29 2006 -0800
@@ -330,6 +330,11 @@ static inline unsigned long __cmpxchg(vo
#define set_mb(var, value) do { (void) xchg(&var, value); } while (0)
#define set_wmb(var, value) do { var = value; wmb(); } while (0)
+/*
+ * Flush the CPU's write combining store buffers.
+ */
+#define flush_wc() asm volatile("sfence" ::: "memory")
+
#define warn_if_not_ulong(x) do { unsigned long foo; (void) (&(x) == &foo); } while (0)
/* interrupt control.. */
diff -r c89918da5f7b -r e27c8e0061e0 include/linux/system.h
--- /dev/null Thu Jan 1 00:00:00 1970 +0000
+++ b/include/linux/system.h Wed Mar 8 13:28:29 2006 -0800
@@ -0,0 +1,27 @@
+/*
+ * Copyright 2006 PathScale, Inc. All Rights Reserved.
+ *
+ * This file is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
+ */
+
+#ifndef _LINUX_SYSTEM_H
+#define _LINUX_SYSTEM_H
+
+#include <asm/system.h>
+
+#ifndef flush_wc
+#define flush_wc() wmb()
+#endif
+
+#endif /* _LINUX_SYSTEM_H */
^ permalink raw reply
* Re: [future of drivers?] a proposal for binary drivers.
From: Randy.Dunlap @ 2006-03-08 21:32 UTC (permalink / raw)
To: Tim Tassonis; +Cc: linux-kernel
In-Reply-To: <440F4C80.6070907@cubic.ch>
On Wed, 8 Mar 2006, Tim Tassonis wrote:
> >
> > if there was binary allowed (with any license) maybe dlink themself
> > would build a driver, make documentation and provide it on CD, just
> > see how much effort would be saved and in end he would get more time
> > to treat his patients.
> >
>
> Apart from all the other good arguments already posted:
>
> Are you really sure they will? Maybe dlink will, but I can tell from
> personal expierience (whine, whine) that the majority of vendors still
> won't release drivers. For the simple reason because they regard Linux a
> market too small to support. That is the main reason for most of them,
> not the license stuff.
Right, what we really need IMO is specs and the right to produce
GPL drivers from the specs. Very little real work is required from the
vendors aside from IP/legal.
> Before Linux, I was an OS/2 user and although every vendor in the world
> was allowed to provide OS/2 drivers, there were more or less the same
> amount of vendor contributed drivers as there are now in Linux.
>
> I'm 100% sure that Linux supports more hardware than OS/2 did back then
> and the user base (Desktop wise) was at least as big as Linux.
>
> OS/2 died exactly because software companies didn't write closed-source
> software, hardware companies didn't write closed-source drivers, and IBM
> couldn't write it all themselves.
>
> So why repeat this desaster?
> Tim
--
~Randy
^ permalink raw reply
* Re: [PATCH 4/6] NFS: Add dentry materialisation op [try #7]
From: Christoph Hellwig @ 2006-03-08 21:31 UTC (permalink / raw)
To: David Howells; +Cc: akpm, linux-fsdevel, linux-kernel
In-Reply-To: <20060308203026.25493.17935.stgit@warthog.cambridge.redhat.com>
> (*) _d_rehash() has been added as a wrapper around __d_rehash() to call it
> with the most obvious hash list (the one from the name). d_rehash() now
> calls _d_rehash().
We're not really kean on single _ prefix functions. Could you give it a saner
name instead (or a new one for __d_rehash and rename _d_reshash to that)
^ permalink raw reply
* RE: Re is there an easy way to tell if anacpi_deviceis on a PCI bus?
From: Randy.Dunlap @ 2006-03-08 21:29 UTC (permalink / raw)
To: Brown, Len; +Cc: Accardi, Kristen C, linux-acpi
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B30065236FA@hdsmsx401.amr.corp.intel.com>
On Wed, 8 Mar 2006, Brown, Len wrote:
>
> >To find if an acpi_device is a child of a PCI bus, it seems
> >that you need to look at its parent, and parents of parents...
> >to see if any are a PCI bus, eg have HID PNP0A03.
>
> Alternatively, you could go top-down,
> acpi_get_devices( PCI_ROOT_HID_STRING,
> and provide a callback to walk below the PCI bus found
> to see if you find your device.
I think that's what the SATA-ACPI patch does to find SATA objects,
if you want to look and see if if would help you at all.
Check http://www.xenotime.net/linux/SATA/2.6.16-rc4/libata-acpi.patch,
the callback function is get_devices().
--
~Randy
^ permalink raw reply
* Re: [future of drivers?] a proposal for binary drivers.
From: Tim Tassonis @ 2006-03-08 21:28 UTC (permalink / raw)
To: linux-kernel
>
> if there was binary allowed (with any license) maybe dlink themself
> would build a driver, make documentation and provide it on CD, just
> see how much effort would be saved and in end he would get more time
> to treat his patients.
>
Apart from all the other good arguments already posted:
Are you really sure they will? Maybe dlink will, but I can tell from
personal expierience (whine, whine) that the majority of vendors still
won't release drivers. For the simple reason because they regard Linux a
market too small to support. That is the main reason for most of them,
not the license stuff.
Before Linux, I was an OS/2 user and although every vendor in the world
was allowed to provide OS/2 drivers, there were more or less the same
amount of vendor contributed drivers as there are now in Linux.
I'm 100% sure that Linux supports more hardware than OS/2 did back then
and the user base (Desktop wise) was at least as big as Linux.
OS/2 died exactly because software companies didn't write closed-source
software, hardware companies didn't write closed-source drivers, and IBM
couldn't write it all themselves.
So why repeat this desaster?
Tim
^ permalink raw reply
* Re: OF default catch on grub2 on 43p-260
From: Chris Abbey @ 2006-03-08 21:28 UTC (permalink / raw)
To: grub-devel
In-Reply-To: <200603081135.12576.hollis@penguinppc.org>
On Wednesday 08 March 2006 11:35 am, Hollis Blanchard wrote:
> This part here won't work. GRUB doesn't look for an OF variable named
> "debug" (technically such a thing does not exist, according to IEEE1275),
> but rather a commandline argument. So you would do this:
oops, guess I missread the conversation I was reading, thanks for clearing
that up.
> From the OF prompt, before you boot GRUB, could you do the following and
> send the output:
> 0 > dev /memory@0
> 0 > .properties
> In particular, the "available" property is the one I'm interested in. That
> will tell us what areas of memory are considered free...
0 > dev /memory@0
ok
0 > .properties
name memory
device_type memory
reg 00000000 40000000
available 00004000 00bfc000 01400000 3ec00000
#address-cells 00000001
#size-cells 00000000
0 > boot floppy:,grubof.mod debug=all
Failed to claim heap at 0x4000, len 0x1fb000
DEFAULT CATCH!, code=fff00700 at %SRR0: 00206090 %SRR1: 00023000
ok
0 >
So If I'm reading that correctly, there is 0x00bfc000 bytes availabel at an
offest of 0x00004000, since grub is asking for 0x001fb000, and that is less
than 0x00bfc000... I don't get why it's failing.
(And just for reference: no changes to the setup in nvram and my crusty old
yaboot loads just fine, boots the kernel and I'm off and running... the
machine has been beaten on pretty hard on a regular basis, so hardware wise
things seem to be in good shape.)
--
6OB/7T -=- LTC Embedded Linux -=- Base Lead Nerd and Cat Herder
Cube: 025-3/B207 -=- TieLine: 553.5061 -=- Extern: 507.253.5061
Notes: Christopher Abbey/Rochester/IBM -=- Net: cabbey@us.ibm.com
The value of Open Standards is only evident to Open Minds.
^ permalink raw reply
* Re: [PATCH 2/6] 9p: Fix error handling on superblock alloc failure [try #7]
From: Christoph Hellwig @ 2006-03-08 21:28 UTC (permalink / raw)
To: David Howells; +Cc: akpm, rminnich, lucho, ericvh, linux-fsdevel, linux-kernel
In-Reply-To: <20060308203021.25493.85005.stgit@warthog.cambridge.redhat.com>
On Wed, Mar 08, 2006 at 08:30:21PM +0000, David Howells wrote:
> The attached patch adds error handling and cleanup in the case that sget()
> fails, lest a memory leak occur.
this is a small and simple fix that should go into 2.6.16 after the 9p
maintainers ACKed it. Of course that means redoing it to apply before the
get_sb prototype change.
^ permalink raw reply
* Re: 2.6.16-rc5 perfmon2 new code base + libpfm with Montecito support
From: Stephane Eranian @ 2006-03-08 21:22 UTC (permalink / raw)
To: William Cohen; +Cc: linux-kernel, perfmon, perfctr-devel, linux-ia64
In-Reply-To: <440F4130.5040703@redhat.com>
Will,
On Wed, Mar 08, 2006 at 03:40:16PM -0500, William Cohen wrote:
> >
> >I have released another version of the perfmon new base package.
> >This release is relative to 2.6.16-rc5
>
> Hello Stephane,
>
> Is there any thoughts on how perfmon2 is going to work with xen enabled
> kernels or processors that support virtualization?
>
AFAIK, there is currently no Xen support for PMU on any platforms. By "support"
I mean suport for guests using the PMU. As such, I do not think this works.
I am planning on looking at this next because this is becoming a pressing matter
and not just on IA-64.
My first goal is to ensure that a guest using perfmon2 works once it is virtualized.
That implies that the Xen VMM does save/restore PMU state on guest switch. That's a bare
minimum.
As for HW virutlization support, I think it helps a little bit but there still needs to
be some additional code in the VMM to make this work correctly. This is also something
I want to look at.
--
-Stephane
^ permalink raw reply
* Re: [PATCH 1/6] NFS: Permit filesystem to override root dentry on mount [try #7]
From: Christoph Hellwig @ 2006-03-08 21:25 UTC (permalink / raw)
To: David Howells
Cc: torvalds, akpm, steved, trond.myklebust, aviro, linux-fsdevel,
nfsv4, linux-kernel
In-Reply-To: <20060308203018.25493.23720.stgit@warthog.cambridge.redhat.com>
could you please remove the linux-cachefs list from the cc list? It's
subscribers only and gives an annoying bounce for every message replied
to yours.
^ permalink raw reply
* Re: [PATCH 1/6] NFS: Permit filesystem to override root dentry on mount [try #7]
From: Christoph Hellwig @ 2006-03-08 21:25 UTC (permalink / raw)
To: David Howells
Cc: akpm, aviro, linux-kernel, nfsv4, steved, torvalds, linux-fsdevel
In-Reply-To: <20060308203018.25493.23720.stgit@warthog.cambridge.redhat.com>
could you please remove the linux-cachefs list from the cc list? It's
subscribers only and gives an annoying bounce for every message replied
to yours.
^ permalink raw reply
* Re: [Xenomai-core] Error on rtdm skin with --enable-dox-doc
From: Gilles Chanteperdrix @ 2006-03-08 21:24 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-core
In-Reply-To: <440F2973.6000408@domain.hid>
Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
> > Jan Kiszka wrote:
> > > Rodrigo Rosenfeld Rosas wrote:
> > > > Hi Jan,
> > > >
> > > > When compiling svn xenomai I noticed the following error with --enable-dox-doc
> > > > switch:
> > > >
> > > > CC [M] kernel/xenomai/skins/rtdm/drvlib.o
> > > > kernel/xenomai/skins/rtdm/drvlib.c:1513:1: error: unterminated #ifdef
> > > >
> > >
> > > I just passed this stage with trunk revision 671 without problems
> > > (doxygen 1.4.4). Moreover, there is no #ifdef or related preprocessor
> > > stuff in the latest drvlib.c at line 1513.
> >
> > I have a few warnings with doxygen 1.4.2:
> >
> > ksrc/skins/rtdm/drvlib.c:151: Warning: Member rtdm_task_destroy found in multiple @defgroup groups! The member will be put in group rtdmtask, and not in group rtdmtask
>
> That's totally weird: "You are in rtdmtask, and not in rtdmtask!?" Even
> more confusing, there is only a single "@defgroup rtdmtask" in the code.
>
> I think I said this before: doxygen's error reporting sucks! I'm not
> excluding that something is broken here, but I don't know where to look.
> Could anyone of you try some older revisions of drvlib.c and
> rtdm.h/rtdm_driver.h to check where the regression(?) may come from?
I have just checked, the error appears with revision 121, an old
one. EXPORT_SYMBOL may be the culprit, again...
--
Gilles Chanteperdrix.
^ permalink raw reply
* [2.6 patch] include/linux/kobject.h: fix a typo
From: Adrian Bunk @ 2006-03-08 21:24 UTC (permalink / raw)
To: Andrew Morton; +Cc: gregkh, linux-kernel
It shouldn't cause real harm, but it hurts my eyes.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
This patch was already sent on:
- 4 Mar 2006
--- linux-2.6.16-rc5-mm2-full/include/linux/kobject.h.old 2006-03-04 00:15:42.000000000 +0100
+++ linux-2.6.16-rc5-mm2-full/include/linux/kobject.h 2006-03-04 00:15:55.000000000 +0100
@@ -255,7 +255,7 @@
extern int subsys_create_file(struct subsystem * , struct subsys_attribute *);
extern void subsys_remove_file(struct subsystem * , struct subsys_attribute *);
-#if defined(CONFIG_HOTPLUG) & defined(CONFIG_NET)
+#if defined(CONFIG_HOTPLUG) && defined(CONFIG_NET)
void kobject_uevent(struct kobject *kobj, enum kobject_action action);
int add_uevent_var(char **envp, int num_envp, int *cur_index,
^ permalink raw reply
* Re: [PATCH 5/6] NFS: Unify NFS superblocks per-protocol per-server [try #7]
From: Christoph Hellwig @ 2006-03-08 21:23 UTC (permalink / raw)
To: David Howells
Cc: torvalds, akpm, steved, trond.myklebust, aviro, linux-fsdevel,
linux-cachefs, nfsv4, linux-kernel
In-Reply-To: <20060308203028.25493.84121.stgit@warthog.cambridge.redhat.com>
Everything in nfs4_get_root past the "create a mount to represent the NFS.."
comment in nfs4_get_root is generic and not nfs-specific. this should move
into a helper in namei.c instead of adding all these odd exports.
what it's doing looks a little fishy aswell, but I'll come back to that later.
^ permalink raw reply
* Re: [PATCH 5/6] NFS: Unify NFS superblocks per-protocol per-server [try #7]
From: Christoph Hellwig @ 2006-03-08 21:23 UTC (permalink / raw)
To: David Howells
Cc: akpm, aviro, linux-kernel, nfsv4, steved, torvalds, linux-cachefs,
linux-fsdevel
In-Reply-To: <20060308203028.25493.84121.stgit@warthog.cambridge.redhat.com>
Everything in nfs4_get_root past the "create a mount to represent the NFS.."
comment in nfs4_get_root is generic and not nfs-specific. this should move
into a helper in namei.c instead of adding all these odd exports.
what it's doing looks a little fishy aswell, but I'll come back to that later.
^ permalink raw reply
* Re: [patch 1/4] net: percpufy frequently used vars -- add percpu_counter_mod_bh
From: Benjamin LaHaise @ 2006-03-08 21:17 UTC (permalink / raw)
To: Ravikiran G Thirumalai; +Cc: Andrew Morton, linux-kernel, davem, netdev, shai
In-Reply-To: <20060308210726.GD4493@localhost.localdomain>
On Wed, Mar 08, 2006 at 01:07:26PM -0800, Ravikiran G Thirumalai wrote:
> But on non x86, local_bh_disable() is gonna be cheaper than a cli/atomic op no?
> (Even if they were switched over to do local_irq_save() and
> local_irq_restore() from atomic_t's that is).
It's still more expensive than local_t.
> And if we use local_t, we will add the overhead for the non bh
> percpu_counter_mod for non x86 arches.
Last time I checked, all the major architectures had efficient local_t
implementations. Most of the RISC CPUs are able to do a load / store
conditional implementation that is the same cost (since memory barriers
tend to be explicite on powerpc). So why not use it?
-ben
--
"Time is of no importance, Mr. President, only life is important."
Don't Email: <dont@kvack.org>.
^ 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.