4) ALARM
Aux Fan: 0 RPM (min = 10546 RPM, div = 128) ALARM
fan5:0 RPM (min = 10546 RPM, div = 128) ALARM
Sys Temp:+45 C (high =-5 C, hyst = -34 C) ALARM
CPU Temp: +39.5 C (high = +80.0 C, hyst = +75.0 C)
AUX Temp: +44.5 C (high = +80.0 C, hyst = +75.0 C
ted by Leon Moonen
# This is for an Asus P5P800, voltages for A8V-E SE.
Should I hardwire correct dividers or pulse per rev in sensors.conf or
is the driver supposed to work the correct dividers out --- like it did
before 2.6.23-rc?
--
Stefan Richter
-=-=-=== =--- -=-==
http://arcgraph.de/sr/
-
To un
#x27;ve got a hunch that the most suitable format for Linux kernel
documentation, after careful consideration of what we want from it and
how we author and maintain it, will turn out to be...
...plaintext.
--
Stefan Richter
-=-=-=== =--- -=-=-
http://arcgraph.de/sr/
-
To unsubscribe from this li
nslation issues?
> * even more style issues
Indeed.
--
Stefan Richter
-=-=-=== =--- -=--=
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/maj
Olaf Hering wrote:
> Fix crash in sbp2_remove_device() when dma_set_mask() fails.
Thanks for finding this. I will examine the allocation and deallocation
paths once more with your fix side by side later today, then move it
upstream.
--
Stefan Richter
-=-=-=== =--- --===
http://arcgraph
EE 1394 application-layer software has this
requirement.
(Well, debugging and forensic tools rely on that mode too, notably
BenH's firescope, but this software runs remote, hence it's a different
beast from sbp2.)
--
Stefan Richter
-=-=-=== =--- --===
http://arcgraph.de/sr/
-
To uns
Robert Hancock wrote:
> Stefan Richter wrote:
>> So that's the story why that dma_set_mask went into sbp2: Sbp2 wants
>> mappings in a _subset_ of the OHCI-1394 controllers DMA range.
>>
>> Anyway. For now I will simply go with what 2.6.23-rc has and what
>>
range.
Anyway. For now I will simply go with what 2.6.23-rc has and what
2.6.21 had: No dma_set_mask anywhere in the 1394 subsystem. We can
revisit this whenever an actual need arises.
--
Stefan Richter
-=-=-=== =--- --==-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line
> This patch forces the driver to read the fan divider values during early
> init.
> Otherwise, a call to store_fan_min() could access uninitialized variables.
Alas not; there is no change.
(I applied on vanilla 2.6.23-rc2 and rebooted.)
--
Stefan Richter
-=-=-=== =--- --=-=
Use this command:
>
> $ git bisect start v2.6.23-rc2 v2.6.22-rc5 drivers/hwmon/w83627ehf.c
>
> Doing it this way will force you to reboot between tests; I think we would
> need that anyway.
I'll try to reserve the time for that on some evening next week.
Thanks,
--
Stefa
fan speeds.
PS: The actual behavior under 2.6.22-rc5 is that the CPU fan speed is
displayed correctly from the start, while the case fan speed is
initially shown as 0 but jumps to the correct speed after ksensors'
first display update.
--
Stefan Richter
-=-=-=== =--- --=-=
http://ar
s an MSI 945GT Speedster-A4R, userland is
Gentoo's lm_sensors-2.10.1 and ksensors-0.7.3.
Booting back into 2.6.22-rc5 (which seems identical with 2.6.22 as far
as w83627ehf is concerned) brings back the correct fan speeds.
--
Stefan Richter
-=-=-=== =--- --=-=
http://arcgraph.de/sr/
-
To unsub
ing in dmesg when that happens ?
There was nothing in Olaf's report, except for trouble in sbp2 _after_
the failure. http://lkml.org/lkml/2007/8/1/344 (I don't have a PMac.)
--
Stefan Richter
-=-=-=== =--- --=-=
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line
an use plaintext
viewers which implement this, or utilities or browser plugins which
follow URLs in the clipboard.)
--
Stefan Richter
-=-=-=== =--- --=--
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
(Adding Cc: linuxppc-dev, olh)
Robert Hancock wrote:
> Stefan Richter wrote:
>> Date: Wed, 1 Aug 2007 20:30:36 +0200 (CEST)
>> From: Stefan Richter <[EMAIL PROTECTED]>
>> Subject: ieee1394: revert "sbp2: enforce 32bit DMA mapping"
>>
>> Revert com
Date: Wed, 1 Aug 2007 20:30:36 +0200 (CEST)
From: Stefan Richter <[EMAIL PROTECTED]>
Subject: ieee1394: revert "sbp2: enforce 32bit DMA mapping"
Revert commit 0555659d63c285ceb7ead3115532e1b71b0f27a7 from 2.6.22-rc1.
The dma_set_mask call somehow failed on a PowerMac G5, PPC64:
d card and a VIA based card.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
Backport of commit 25659f7183376c6b37661da6141d5eaa21479061.
drivers/firewire/fw-sbp2.c|5 -
drivers/firewire/fw-transaction.h |2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
Ind
[EMAIL PROTECTED] wrote:
> On Fri, 3 Aug 2007, Stefan Richter wrote:
>> There is a variety of possible naming schemes:
>>
>> - Naming by order of discovery.
>> - Naming by vendor/model name strings.
>> - Naming by universally unique identifier.
>> - Namin
like an overly /obvious/ language feature to me.
--
Stefan Richter
-=-=-=== =--- ---==
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majo
he Linux OS.
There is only the most primitive naming scheme implemented in the kernel
because naming policy, like most other kinds of policy, is better left
to userland. The kernel is a too restricted framework to implement such
things. The kernel lacks runtime-configuration files, scripting
inte
Al Viro wrote:
> On Fri, Aug 03, 2007 at 12:51:16AM +0200, Guennadi Liakhovetski wrote:
>> On Fri, 3 Aug 2007, Stefan Richter wrote:
>>
>>> Guennadi Liakhovetski wrote:
>>>> with
>>>>
>>>>char c[4] = "012345";
>>>&
'3'}.
C99 says char c[4] = "0123"; is a perfect way to say char c[4] = {'0',
'1', '2', '3'};. Do you want gcc to choose otherwise and ban the former
of the two idioms?
--
Stefan Richter
-=-=-=== =--- ---==
http://arcgraph.de
Guennadi Liakhovetski wrote:
> with
>
> char c[4] = "012345";
>
> the compiler warns, but actually allocates a 6-byte long array...
Off-topic here, but: sizeof c / sizeof *c == 4.
--
Stefan Richter
-=-=-=== =--- ---==
http://arcgraph.de/sr/
-
To unsubscribe
with a string literal now, and the
resulting array will contain a non-zero member as last element, and I
mean it". And since there is no such annotation possible, gcc does not
warn and demand that you annotate the perfectly valid and 100%
spec-compliant construct char a[4] = "1234&
Linus, please pull from the for-linus branch at
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git
for-linus
to receive the following fixes for the new and old 1394 subsystems:
Stefan Richter (5):
ieee1394: revert "sbp2: enforce 32bit DMA mapping"
Olaf Hering wrote:
> On Wed, Aug 01, Stefan Richter wrote:
>> Revert commit 0555659d63c285ceb7ead3115532e1b71b0f27a7 from 2.6.22-rc1.
> This change fixes the oops, and I can access the drive again.
Did it oops always or only sometimes?
--
Stefan Richter
-=-=-=== =--
.driver_probe_device+0x13c/0x200
I have now idea why dma_set_mask failed, nor do I see where the
subsequent oops came from.
From: Stefan Richter <[EMAIL PROTECTED]>
Subject: ieee1394: revert "sbp2: enforce 32bit DMA mapping"
Revert commit 0555659d63c285ceb7ead3115532e1b7
;> dev_dbg_f(zd_chip_dev(chip),
>>
Also, why is there this cast right before that?
zd_addr_t *a16 = (zd_addr_t *)NULL;
--
Stefan Richter
-=-=-=== =--- =
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
al
variable of the same name. Maybe you could submit another cleanup patch
for that too while you are at it?
--
Stefan Richter
-=-=-=== =--- =
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
uldn't leave inexplicable linebreaks
and other whitespace strangeness behind.
--
Stefan Richter
-=-=-=== =--- =
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info a
Greg KH wrote:
> Rolled up patch is at:
> kernel.org/pub/linux/kernel/v2.6/stable-testing/patch-2.6.21.7-rc1.gz
^^
stable-review
--
Stefan Richter
-=-=-=== -=== =
http://arcgraph
h=bde271c001ba33ef1f61dd0f563f74d319cd1f0e;hp=c3feeaab387537ef00aa2085b4f54f6d7e4abca0
--
Stefan Richter
-=-=-=== -=== ===-=
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at htt
ion about bugzilla.kernel.org, to those who don't know
already: By far not all maintainers and developers use bugzilla.
I don't know for which subsystems it makes sense to file a report in
bugzilla. I think your best bet is to report at the mailinglists
listed in linux/MAINTAINERS.
--
S
s
and a lot of development branches. Some are located at git.kernel.org.
Among else, this gives you a predictable release rythm and very timely
updated stable branches.
--
Stefan Richter
-=-=-=== -=== ===--
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscr
ould give you "trying to assign nonexistent symbol SUSPEND_POSSIBLE"
> kconfig warnings on architectures without SUSPEND_POSSIBLE.
Unless /all/ architectures define it, of course.
--
Stefan Richter
-=-=-=== -=== ===--
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the l
Adrian Bunk wrote:
> On Sat, Jul 28, 2007 at 12:47:37AM +0200, Stefan Richter wrote:
>> Yes, that's the price to pay if you want to select something that in
>> turn depends on a number of other things.
>
> Yes, but a good user interface is worth it.
That's right
E_SUSPEND
> + select HOTPLUG_CPU
> + default y
Yes, that's the price to pay if you want to select something that in
turn depends on a number of other things.
Wait, doesn't HOTPLUG_CPU also depend on EXPERIMENTAL?
--
Stefan Richter
-=-=-=== -=== ===--
http://arcgra
Andrew Morton wrote:
> On Fri, 27 Jul 2007 09:41:01 +0200 Stefan Richter <[EMAIL PROTECTED]> wrote:
...
>> SubmitChecklist already tells us to check with sparse before submission.
>
> rofl. First we have to talk everyone into checking their stuff with gcc.
Ah, I forgot ---
Andrew Morton wrote:
> On Fri, 27 Jul 2007 02:42:58 +0200 Stefan Richter <[EMAIL PROTECTED]> wrote:
>> Besides, how about reorienting the CodingStyle text to the essential?
...
> If sparse has gone and added a warning for this then it is more than
> nitpicking. Reducing the a
nd more being buried in dry
nitpicking.)
--
Stefan Richter
-=-=-=== -=== ==-==
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/firewire/fw-ohci.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
Index: linux/drivers/firewire/fw-ohci.c
===
--- linux.orig/d
to do with this issue. Hence it
would be practical to test the patches on 2.6.22, but if you prefer you
could also test them on 2.6.23-*. Thanks,
--
Stefan Richter
-=-=-=== -=== ==--=
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
dates the x86 and swiotlb versions to
> include the relevant warnings. (I already observed that it trips on the
> bus_reset_tasklet of the new firewire_ohci driver.)
Also in ohci_set_config_rom().
--
Stefan Richter
-=-=-=== -=== ==--=
http://arcgraph.de/sr/
-
To unsubscribe from this li
the attached patches, one
patch at a time? They apply to 2.6.22.
--
Stefan Richter
-=-=-=== -=== ==---
http://arcgraph.de/sr/
firewire: fw-sbp2: default to 128k transfers
because that's what the old sbp2 driver does per default, to avoid
trouble with buggy devices.
A test on a 1394b hardware
your patch _does not_ do. Don't even describe _how_
your patch does what it does (unless it's obfuscated, but then that
would be a bad patch anyway).
Just describe _why_ it does something.
--
Stefan Richter
-=-=-=== -=== ==---
http://arcgraph.de/sr/
-
To unsubscribe from this list:
test this again on the
smaller machines.
--
Stefan Richter
-=-=-=== -=== =-===
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.h
Andreas Messer wrote:
> On Monday, 23. Juli 2007 01:34 Stefan Richter wrote:
>> Are you sure the FireWire controller is from VIA? Check with lscpi.
>> The NVidia nForce2 chipset has an own FireWire controller, and that one
>> is only "supported" by a gross hac
y should be added soon.)
I always only test vanilla kernels (with ieee1394/firewire patches). I
wanted to start testing -rt kernels because they are known to make bugs
of the old ieee1394 drivers more visible, but simply didn't find the
time to do such tests yet.
--
Stefan Richter
-=-
irewire-ohci. There is even a bug report in Red Hat's
bugzilla where fw-ohci hung up when trying to initialize an nForce2 chip.
> Software:
> Kernel Vanilla 2.6.22, gcc 4.1.2.
>
> On another PC same problem, but replugging one or two times get the thing
> working.
elements. Comment on the Why if it
isn't obvious. It shouldn't be necessary to comment on the How, because
that should be coded in an obvious way in the first place.
--
Stefan Richter
-=-=-=== -=== =-==-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line &
Krzysztof Halasa wrote:
> Stefan Richter <[EMAIL PROTECTED]> writes:
>
>> The latter is sometimes hard or impossible to satisfy. Therefore the
>> select statement should be used with care, i.e. only for library-type
>> helper code which itself shouldn't depend
he
select statement should be used with care, i.e. only for library-type
helper code which itself shouldn't depend on further options.
--
Stefan Richter
-=-=-=== -=== =-=-=
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Make the option SBP2_PHYS_DMA available on all architectures where it
compiles. This includes x86-64 where I runtime-tested it successfully.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
CONFIG_VIRT_TO_BUS is nice. Thanks Stephen.
--- a/drivers/ieee1394/Kconfig
+++ b/drivers/ie
Is it sensible and safe to let a driver which uses bus_to_virt (but not
virt_to_bus) depend on CONFIG_VIRT_TO_BUS? Thanks,
--
Stefan Richter
-=-=-=== -=== =-=-=
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
f the code that uses the config option has a lot of flexibility,
In other words, nobody will ever know what this config option really does.
> at least until we start enforcing standards.
--
Stefan Richter
-=-=-=== -=== =-=--
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the
>>> +config STABLE
>>> + bool "Stable kernel"
PS: Imagine the headlines at Slashdot, CNET et al when this gets in.
--
Stefan Richter
-=-=-=== -=== =-=--
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu
t;
help
If the kernel is configured as a test build, various checks
useful for testing of pre-releases will be activated.
If unsure, say N.
--
Stefan Richter
-=-=-=== -=== =-=--
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "un
If you say N, all options in this submenu will be skipped and
disabled.
> From a quick look at drivers/macintosh/Kconfig, all of the entries are for
> m68k
> and PPC Macs only. The only thing that depends on X86 is the main menu...
There is one entry for all sorts of Macs, MAC_EMUMOU
API"
Who:Arjan van de Ven <[EMAIL PROTECTED]>
--
Stefan Richter
-=-=-=== -=== =--==
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.o
Robert P. J. Day wrote:
> i *did* submit a preliminary patch once upon a time, and it
> (predictably) went nowhere.
A patch which pulls the word "experimental" into prompts or adds a
dedicated directive for tagging of options? Can't find it in archive
observed that feature requests
don't set anything in motion until a first patch is sent. Even a patch
that is far from perfect can get things going really quickly. (If the
requested feature makes sense to other people.)
--
Stefan Richter
-=-=-=== -=== =--==
http://arcgraph.de/sr/
-
To uns
Date: Tue, 17 Jul 2007 02:15:36 +0200 (CEST)
From: Stefan Richter <[EMAIL PROTECTED]>
Subject: firewire: fix memory leak of fw_request instances
Found and debugged by Jay Fenlason <[EMAIL PROTECTED]>.
The bug was especially noticeable with direct I/O over fw-sbp2.
Signed-off-by: St
Date: Thu, 12 Jul 2007 22:25:14 +0200 (CEST)
From: Stefan Richter <[EMAIL PROTECTED]>
Subject: firewire: fw-ohci: fix "scheduling while atomic"
context_stop is called by bus_reset_tasklet, among else.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
Fixes http
subsystem.
drivers/firewire/fw-ohci.c|3 ++-
drivers/firewire/fw-sbp2.c| 16 +++-
drivers/firewire/fw-transaction.c |9 +++--
drivers/firewire/fw-transaction.h |4
4 files changed, 16 insertions(+), 16 deletions(-)
Stefan Richter (5
t to new SCSI data buffer accessors
PS: Kudos to Jay Fenlason for doing the difficult and time-consuming
parts of it, the memleak debugging.
--
Stefan Richter
-=-=-=== -=== =--==
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
Jan Engelhardt wrote:
> On Jul 16 2007 20:49, Stefan Richter wrote:
>>
>>It is an error to add visible Kconfig options without help text. Among
>>them are the new "menuconfig" options. Jan obviously never uses "make
>>oldconfig".
>
> Untrue
Jean Delvare wrote:
> This one took more time than expected,
These words sound strangely familiar, as if I often said them myself.
Can't be.
--
Stefan Richter
-=-=-=== -=== =---=
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
en: December 2006
-Who: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
+Who: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
--
Stefan Richter
-=-=-=== -=== =
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
What: drivers depending on OSS_OBSOLETE
When: options in 2.6.23, code in 2.6.25
Note 2: Current linux-2.6.22-git* has SOUND_BT878 and
SOUND_CS4232 depending on OSS_OBSOLETE.
What: /sys/firmware/acpi/namespace
When: 2.6.21
--
Stefan Richt
A'...'endif # A' will be invisible and disabled.
--
Stefan Richter
-=-=-=== -=== =
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
; in a strict
sense. Bug fixes should usually go through maintainers. But for fixes
which are obvious == easy to verify, [EMAIL PROTECTED] makes sense as a
central point for submitters to turn to, to lower the barrier for
submission.
--
Stefan Richter
-=-=-=== -=== =
http://arcgraph.de/s
;d be happy to post further details or run tests, if anyone
> is interested.
>
> ...Akkana
I am not aware of anything that a PCI driver like ohci1394 could do
about it. Somebody correct me if I'm wrong, but this is between the
BIOS and low-level code for the x86 PC plat
Alan Cox wrote:
> The English versions need a last updated too, that way we would know when
> they are past their best before date (as most of them are)
I've got the impression that whenever I saw a "last updated:" note in a
documentation, this note was out of dat
Cornelia Huck wrote:
> On Thu, 12 Jul 2007 07:47:52 +0200,
> Stefan Richter <[EMAIL PROTECTED]> wrote:
>> Also keep in mind that either device_move() should update the numa_node,
>> or the subsystems which call device_move() should explicitly update it
>> on their
Yinghai Lu wrote:
> Stefan Richter wrote:
>> Yinghai Lu wrote:
>>> original default is -1, and this patch just try to use parent's node as
>>> default.
>>
>> But in many cases, the patch does so at a time when the parent is not
>> yet known.
> t
Yinghai Lu wrote:
> original default is -1, and this patch just try to use parent's node as
> default.
But in many cases, the patch does so at a time when the parent is not
yet known.
--
Stefan Richter
-=-=-=== -=== -==--
http://arcgraph.de/sr/
-
To unsubscribe from this list: se
I wrote:
> - device_move() should update the device.node.
device.numa_node of course.
--
Stefan Richter
-=-=-=== -=== -=-==
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majo
Adrian Bunk wrote:
>> > http://kernelnewbies.org/Linux_2_6_22
> But when you anyway publish release notes for your subsystem, also
> pasting them to the Wiki shouldn't be much extra work.
I will do so from now on. Until now I was too lazy to create an account
there
ivers/input/gameport/gameport.c::
gameport_init_port() which sets the parent device *after* the
call to device_initialize().
- device_move() should update the device.node.
--
Stefan Richter
-=-=-=== -=== -=-==
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line &
Already available:
> http://kernelnewbies.org/Linux_2_6_22
And of course there are several journalists who cover such matters.
I'm also sure that some subprojects issue their own release notes; e.g.
the linux1394 project does.
--
Stefan Richter
-=-=-=== -=== -=-==
http://arcgraph.de/sr/
-
1394 drivers enabled and the new ones disabled.
>Or if you didn't, try it.
Or actually disable one driver or subsystem in each test boot. (Also
parport, USB...)
--
Stefan Richter
-=-=-=== -=== -=-=-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "un
automatically loose "experimental" status. It does when it has
been extensively and successfully debugged, verified and tested, and no
reservations regarding run-time stability or userspace interface
stability remain. Is this true for these profiling options?
--
Stefan Richter
-=-=-=== -==
Fix write() for 32bit userland on 64bit kernel
ieee1394: raw1394: Add ioctl() for 32bit userland on 64bit kernel
Stefan Richter (25):
ieee1394: ohci1394: remove dead CONFIG variable
ieee1394: add comments in struct hpsb_packet
ieee1394: raw1394: Add ioctl() for 32bit userla
Date: Sun, 24 Jun 2007 15:31:54 +0200 (CEST)
From: Stefan Richter <[EMAIL PROTECTED]>
Subject: [RFC PATCH] ieee1394: remove old isochronous ABI
Based on patch "the scheduled removal of RAW1394_REQ_ISO_{SEND,LISTEN}"
from Adrian Bunk, November 20 2006.
This patch also remove
ing for
> information: why is this warning happening? naugthy cdparanoia? naughty
> kernel? I'm a bit confused and I want to use my external DVD drive for
> ripping from time to time, to "exercise" it...
>
> Thanks a lot in advance :)
>
&
On 6 Jul, Robert P. J. Day wrote:
> On Fri, 6 Jul 2007, Stefan Richter wrote:
>> Robert P. J. Day wrote:
>> > --- a/arch/i386/kernel/io_apic.c
>> > +++ b/arch/i386/kernel/io_apic.c
>> > @@ -353,7 +353,7 @@ static void set_ioapic_affinity_irq(unsig
ic_pte(struct page *page, enum km_type type)
This misnamed CONFIG_DEBUG_PAGE_TYPE (it's not a Kconfig variable) has
about 120 lines debug code dangling on it. So, replacing it by #if 0
will hopefully motivate a kind janitor to send a removal patch for that
debug code eventually. I don't
ed in compiling their kernel with
-DCONFIG_BALANCED_IRQ_DEBUG injected via the commandline. But we'll hear
from them if that's the case.
On the other hand, these debug macros seem to be very old. I'll have a
closer look with qgit/git-blame later today. Maybe it's time to remo
l.h. This is an option similar to other
CONFIG_SERIAL_ options in numerous places.
Serial drivers are orphaned, aren't they?
> feel free to take this as seriously as you want. :-)
>
> rday
--
Stefan Richter
-=-=-=== -=== --==-
http://arcgraph.de/sr/
-
To unsubscribe from this list
I was told that only i386 aligns 64 bit integers at 4 bytes boundaries
while all other architectures (32 bit architectures with 64 bit
siblings) align it on 8 bytes boundaries.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/ieee1394/raw1394.c |6 +-
1 file chan
its on top of ohci1394 = PCI driver for FireWire
controllers.)
I guess it should be the lowlevel's pci_dev.dev, unless the midlayer
cares to set
set_dev_node(&midlayer_dev.dev, dev_to_node(midlayer_dev.dev.parent));
And either way, for full effect of NUMA awareness in the highlevel
network dr
architectures
> have version optimized to their features.
...but of course we generally include linux/rwsem.h instead of
architecture-specific header files. linux/rwsem.h will transparently
pull in the optimized variants for us. (It's evident from the source.)
--
Stefan Richter
-=-
On 29 Jun, Stefan Richter wrote:
> Linus, please pull from the for-linus branch at
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git
> for-linus
>
> to receive the following updates.
>
> Stefan Richter (2):
> firewire: fix as
Linus, please pull from the for-linus branch at
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git
for-linus
to receive the following updates.
Stefan Richter (2):
firewire: fix async reception on big endian machines
firewire: add Kconfig help on building
Andrew Morton wrote:
> On Tue, 19 Jun 2007 23:45:58 +0200 (CEST) Stefan Richter <[EMAIL PROTECTED]>
> wrote:
>> - Other git kernel trees can be found listed at http://kernel.org/git
>
> rofl. You want git trees? I got git trees:
Well, the HOWTO has a target audienc
can be set, and your handler should
> probably be SCHED_FIFO.
Does this cooperate nicely with a SCHED_FIFO thread of a userspace data
acquisition program or audio server or the like?
--
Stefan Richter
-=-=-=== -==- ==-=-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "
Alas that won't work so good, because nobody reads help texts.
I thought about adding some crude multiple choice selection (build the
old stack, build the new stack, build both stacks). It's possible, but
it would introduce awkward dummy config variables.
Signed-off-by: Stefan Richt
ubsystem, and work on the new firewire subsystem
will be focused on stabilization and feature completion in the short to
mid term.
--
Stefan Richter
-=-=-=== -==- ==---
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
o so.
Everybody is allowed to submit. But there is a certain degree of both
persistence and adaptability required to get one's first submissions
upstream. However, these qualities are also required to fix difficult bugs.
--
Stefan Richter
-=-=-=== -==- =-==-
http://arcgraph.de/sr/
-
Zoltán HUBERT wrote:
> So I feel that a turning-point is coming where a really
> really really (x 15) stable and reliable kernel is NEEDED.
Not satisfied with 2.6.16.y or one of the "enterprise" distro kernels?
--
Stefan Richter
-=-=-=== -==- =-==-
http://arcgraph.de/sr/
601 - 700 of 1128 matches
Mail list logo
