* Re: [PATCH] git log [diff-tree options]...
From: Junio C Hamano @ 2006-04-09 19:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604091158310.9504@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Well, on the other hand, the new "git log --diff" should get the revision
> counting right even if it's _not_ done by the caller.
Not if the user uses --diff-filter and/or --pickaxe, and after
we start omitting the log message part when no diff is output.
> So I'd suggest:
> - drop git-whatchanged entirely
> - keep it - for historical reasons - as a internal shorthand, and just
> turn it into "git log --diff -cc"
>
> and everybody will be happy (yeah, it will show a few merge commits
> without diffs, because the diffs end up being uninteresting, but that's
> _fine_, even if it's not 100% the same thing git-whatchanged used to do)
I tend to agree. A merge commit touching a path but not
actually changing the contents of the path from parents might be
a significant event.
^ permalink raw reply
* Re: [PATCH] dc395x: dynamically map scatter-gather for PIO (take 2)
From: Guennadi Liakhovetski @ 2006-04-09 19:10 UTC (permalink / raw)
To: James Bottomley; +Cc: linux-scsi, Sebastian Frei, Fredrik Roubert, lenehan
In-Reply-To: <Pine.LNX.4.60.0604022004520.17410@poirot.grange>
On Sun, 2 Apr 2006, Guennadi Liakhovetski wrote:
> Hello all,
>
> This time I really mean it:-)
>
> The current dc395x driver uses PIO to transfer up to 4 bytes which do not
> get transferred by DMA (under unclear circumstances). For this the driver
> uses page_address() which is broken on highmem. Apart from this the
> actual calculation of the virtual address is wrong (even without highmem).
> So, e.g., for reading it reads bytes from the driver to a wrong address
> and returns wrong data, I guess, for writing it would just output random
> data to the device.
It's been a week since the patch submission. James, Jamie, I'd really like
to hear some feedback.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: [RFC][PATCH 1/5] uts namespaces: Implement utsname namespaces
From: Eric W. Biederman @ 2006-04-09 19:08 UTC (permalink / raw)
To: Andi Kleen; +Cc: Serge E. Hallyn, linux-kernel
In-Reply-To: <200604090800.57814.ak@suse.de>
Andi Kleen <ak@suse.de> writes:
> On Saturday 08 April 2006 22:28, Serge E. Hallyn wrote:
>
>> The consensus so far has been to start putting things into task_struct
>> and move if needed. At least the performance numbers show that so far
>> there is no impact.
>
> Performance is not the only consider consideration here. Overall
> memory consumption is important too.
>
> Sure for a single namespace like utsname it won't make much difference,
> but it likely will if you have 10-20 of these things.
The highest estimate I have seen is 10, including the current
mount namespace.
Basically it looks like: mounts, uts, sysvipc, net, pid, uid.
Not very many.
Even in your worst cast estimate of 20. That puts
us at. 8*20 = 160. 160 vs 10K. or about a 1% size increase.
Not terribly noticeable.
And I think 20 - 40 bytes of increase not 160 is a lot
closer to where we will be in the short term.
>> iirc container patches have been sent before. Should those be resent,
>> then, and perhaps this patchset rebased on those?
>
> I think so.
That is premature optimization, and it ties the implementations
together. Which makes implementing this that much harder,
and we do want separate sharing of these things.
Once we have something working I don't have a problem going back
and revisiting what it takes to optimize the size of the
implementation. But while we still have correctness issues
to worry about such a small optimization before we can
even measure the benefit or have a good feel of the users
does not make sense.
If you really think this is a beneficial approach to reducing
size you can already apply it to all of the thread pointers.
Where the gain is immediately noticeable, and the count is
similar.
We will be happy to follow the best current practices.
Eric
^ permalink raw reply
* [ALSA - driver 0001944]: 0001491: Onboard sound of HP Kayak workstation isn't detected properly
From: bugtrack @ 2006-04-09 19:12 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1944>
======================================================================
Reported By: axion
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 1944
Category: ISA - ad1816a
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution: slackware
Kernel Version: 2.6.16
======================================================================
Date Submitted: 03-20-2006 13:56 CET
Last Modified: 04-09-2006 21:12 CEST
======================================================================
Summary: 0001491: Onboard sound of HP Kayak workstation isn't
detected properly
Description:
Detection of AD1816AJS chip contained on the board of HP Kayak workstation
(chipset i440LX) is not detected by ALSA - tested in both PnP and non-PnP
mode. With legacy OSS driver it works fine in non-PnP mode (PnP probably
doesn't work), but there's need to hard-write all parameters like io, irq,
dma and so...
======================================================================
----------------------------------------------------------------------
axion - 03-20-06 13:58
----------------------------------------------------------------------
alsa version is 1.0.11rc2 ( builtinto kernel 2.6.16 )
----------------------------------------------------------------------
axion - 04-09-06 21:12
----------------------------------------------------------------------
also tried driver version rc4
Issue History
Date Modified Username Field Change
======================================================================
03-20-06 13:56 axion New Issue
03-20-06 13:56 axion Distribution => slackware
03-20-06 13:56 axion Kernel Version => 2.6.16
03-20-06 13:58 axion Note Added: 0008720
04-09-06 21:12 axion Note Added: 0009184
======================================================================
-------------------------------------------------------
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: 2.6.17-rc1-mm2: badness in 3w_xxxx driver
From: Jeff Garzik @ 2006-04-09 19:12 UTC (permalink / raw)
To: Andrew Morton; +Cc: Nick Orlov, linux-kernel, axboe, James.Bottomley
In-Reply-To: <20060409113240.630b9a24.akpm@osdl.org>
Andrew Morton wrote:
> Nick Orlov <bugfixer@list.ru> wrote:
>> The following patch: x86-kmap_atomic-debugging.patch exposed a badness
>> in 3w_xxx driver.
>
> Sweet, thanks.
>
>> I'm getting a lot of:
>>
>> Apr 9 13:00:04 nickolas kernel: kmap_atomic: local irqs are enabled while using KM_IRQn
>> Apr 9 13:00:04 nickolas kernel: <c0104103> show_trace+0x13/0x20 <c010412e> dump_stack+0x1e/0x20
>> Apr 9 13:00:04 nickolas kernel: <c01159c9> kmap_atomic+0x79/0xe0 <c028b885> tw_transfer_internal+0x85/0xa0
>> Apr 9 13:00:04 nickolas kernel: <c028ca7e> tw_interrupt+0x3fe/0x820 <c0143b9e> handle_IRQ_event+0x3e/0x80
>> Apr 9 13:00:04 nickolas kernel: <c0143c70> __do_IRQ+0x90/0x100 <c01057a6> do_IRQ+0x26/0x40
>> Apr 9 13:00:04 nickolas kernel: <c010396e> common_interrupt+0x1a/0x20 <c0101cdd> cpu_idle+0x4d/0xb0
>> Apr 9 13:00:04 nickolas kernel: <c010f2cc> start_secondary+0x24c/0x4b0 <00000000> 0x0
>> Apr 9 13:00:04 nickolas kernel: <c214ffb4> 0xc214ffb4
>>
>> I'm running 32 bit kernel on AMD64x2 w/ HIGHMEM enabled.
>> I think this is an old bug since the 3w_xxxx.c has not been changed for
>> a long time (at least since 2.6.16-rc1-mm4).
>>
>> Please let me know if you want me to try some patches.
>>
>
>
> From: Andrew Morton <akpm@osdl.org>
>
> We must disable local IRQs while holding KM_IRQ0 or KM_IRQ1. Otherwise, an
> IRQ handler could use those kmap slots while this code is using them,
> resulting in memory corruption.
>
> Thanks to Nick Orlov <bugfixer@list.ru> for reporting.
>
> Cc: <linuxraid@amcc.com>
> Cc: James Bottomley <James.Bottomley@SteelEye.com>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> ---
>
> drivers/scsi/3w-xxxx.c | 3 +++
> 1 files changed, 3 insertions(+)
>
> diff -puN drivers/scsi/3w-xxxx.c~3ware-kmap_atomic-fix drivers/scsi/3w-xxxx.c
> --- devel/drivers/scsi/3w-xxxx.c~3ware-kmap_atomic-fix 2006-04-09 11:28:08.000000000 -0700
> +++ devel-akpm/drivers/scsi/3w-xxxx.c 2006-04-09 11:29:21.000000000 -0700
> @@ -1508,10 +1508,12 @@ static void tw_transfer_internal(TW_Devi
> struct scsi_cmnd *cmd = tw_dev->srb[request_id];
> void *buf;
> unsigned int transfer_len;
> + unsigned long flags = 0;
>
> if (cmd->use_sg) {
> struct scatterlist *sg =
> (struct scatterlist *)cmd->request_buffer;
> + local_irq_save(flags);
> buf = kmap_atomic(sg->page, KM_IRQ0) + sg->offset;
> transfer_len = min(sg->length, len);
> } else {
> @@ -1526,6 +1528,7 @@ static void tw_transfer_internal(TW_Devi
>
> sg = (struct scatterlist *)cmd->request_buffer;
> kunmap_atomic(buf - sg->offset, KM_IRQ0);
> + local_irq_restore(flags);
ACK.
Though please make sure the active maintainer is CC'd on this... There
is even a helpful MAINTAINERS entry for this driver.
Jeff
^ permalink raw reply
* Help: Can't resume an Abit NF7 (nForce2) from S3
From: Andreas Saur @ 2006-04-09 19:15 UTC (permalink / raw)
To: linux-acpi
Dear list.
I've got three Abit NF7 (nForce2) boards here, and hope I can make S3
work for them. I've tried a lot of patches and Vanilla (and -mm)
Kernels. I've also published a bug report at Bugzilla
(http://bugzilla.kernel.org/show_bug.cgi?id=6326).
The last kernel I've tried was 2.6.17-rc1-mm2 (at the very moment the
most recent one). But nothing worked yet. My problem isn't a
non-returning VGA screen, my whole box is dead after invoking '#echo -n
mem > /sys/power/state' from the single user mode. After waking the
mashine up, the CPU-Fan and the HDD come up, but the keyboard is dead,
and all logs are empty after reset. And that is the bad part of it, I
can't offer you a logging entry, because there is none.
Question 1: How can I get some logs out of my box? ( e.g. CONFIG_DEBUG_??? )
Question 2: Is anybody out there with a working 'resume from S3' on an
Abit NF7?
Question 3: If NF7 is a notorious no go board for ACPI, could i at least
get mental assistence? ;-)
Thank's for support in advance.
Andreas
P.S.: detailled informations about my system see:
http://bugzilla.kernel.org/show_bug.cgi?id=6326
^ permalink raw reply
* Re: A failed-disk-how-to anywhere?
From: Martin Stender @ 2006-04-09 19:16 UTC (permalink / raw)
To: Mike Hardy; +Cc: Brad Campbell, linux-raid
In-Reply-To: <44394EAB.5090309@h3c.com>
I'm sorry - I replied to Brad's email a few hours ago, but I was a
bit too fast, and didn't notice I was replying to his personal account.
Here's my reply - as you can see, all is fine now! Thank you both!
(doing a '#cat /proc/mdstat', show that everything went well)
Martin
<reply>
Hello Brad
You got very close ... :-)
Thank you! I swapped the IDE-cables, and the thing booted nicely!
So from within webmin (I know ... but it's easy to use) I created
three new linux raid partitions on the new drive, and - also from
webmin - added those to the array.
Running a #top - I can see some re-syncing is going on - so I guess
everything is fine!
Big thanks!
Martin
</reply>
On 09/04/2006, at 20.12, Mike Hardy wrote:
>
> Brad Campbell wrote:
>> Martin Stender wrote:
>>
>>> Hi there!
>>>
>>> I have two identical disks sitting on a Promise dual channel IDE
>>> controller. I guess both disks are primary's then.
>>>
>>> One of the disks have failed, so I bought a new disk, took out the
>>> failed disk, and put in the new one.
>>> That might seem a little naive, and apparently it was, since the
>>> system won't boot up now.
>>> It boots fine, when only the old, healthy disk is connected.
>
>
>> My initial thought would be you have hde and hdg in a raid-1 and
>> nothing
>> on the on-board controllers. hde has failed and when you removed
>> it your
>> controller tried the 1st disk it could find (hdg) to boot of..
>> Bingo..
>> away we go.
>> You plug a new shiny disk into hde and now the controller tries to
>> boot
>> off that, except it's blank and therefore a no-go.
>>
>> I'd either try and force the controller to boot off hdg (which
>> might be
>> a controller bios option) or swap hde & hdg.. then it might boot
>> and let
>> you create your partitions on hdg and then add it back into the
>> mirror.
>
>
> I'd add another stab in the dark and guess that you didn't install
> your
> boot loader on both drives.
>
> Not that I've ever done that before (ok, a few times, most recently
> two
> days ago, sigh)
>
> Typically the BIOS will try all hard drives and so it should have
> rolled
> to one that worked, but if only the "failed" drive had the boot loader
> then you are of course not bootable.
>
> I solved this by booting rescue mode, starting up the raid arrays,
> mounting them, and manually grub installing. Here's a good page for
> the
> grub incantations:
> http://gentoo-wiki.com/
> HOWTO_Gentoo_Install_on_Software_RAID_mirror_and_LVM2_on_top_of_RAID#B
> ootloader_installation_and_configuration
>
> -Mike
>
^ permalink raw reply
* Re: [PATCH] i386/x86-64: Return defined error value for bad PCI config space accesses
From: Jeff Garzik @ 2006-04-09 19:17 UTC (permalink / raw)
To: Andi Kleen, Andrew Morton; +Cc: Linux Kernel Mailing List
In-Reply-To: <200604091900.k39J0uVn013016@hera.kernel.org>
Linux Kernel Mailing List wrote:
> - if (!value || (bus > 255) || (devfn > 255) || (reg > 255))
> + if (!value || (bus > 255) || (devfn > 255) || (reg > 255)) {
> + *value = -1;
> return -EINVAL;
> + }
>
> spin_lock_irqsave(&pci_config_lock, flags);
>
> diff --git a/arch/i386/pci/mmconfig.c b/arch/i386/pci/mmconfig.c
> index 2002c74..f77d7f8 100644
> --- a/arch/i386/pci/mmconfig.c
> +++ b/arch/i386/pci/mmconfig.c
> @@ -80,8 +80,10 @@ static int pci_mmcfg_read(unsigned int s
> unsigned long flags;
> u32 base;
>
> - if (!value || (bus > 255) || (devfn > 255) || (reg > 4095))
> + if (!value || (bus > 255) || (devfn > 255) || (reg > 4095)) {
> + *value = -1;
> return -EINVAL;
> + }
>
> base = get_base_addr(seg, bus, devfn);
> if (!base)
> diff --git a/arch/x86_64/pci/mmconfig.c b/arch/x86_64/pci/mmconfig.c
> index d4e25f3..b493ed9 100644
> --- a/arch/x86_64/pci/mmconfig.c
> +++ b/arch/x86_64/pci/mmconfig.c
> @@ -75,8 +75,10 @@ static int pci_mmcfg_read(unsigned int s
> char __iomem *addr;
>
> /* Why do we have this when nobody checks it. How about a BUG()!? -AK */
> - if (unlikely(!value || (bus > 255) || (devfn > 255) || (reg > 4095)))
> + if (unlikely(!value || (bus > 255) || (devfn > 255) || (reg > 4095))) {
> + *value = -1;
As the code check indicates, value might be NULL.
Please fix.
Jeff
^ permalink raw reply
* PRAMFS
From: Antonio Di Bacco @ 2006-04-09 19:20 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
anyone knows if pramfs for kernel 2.4 is stable, anyone used it? When
downloading it I saw that the date is very old (2004). I saw people using
jffs2 on pram, but I think there is a big waste of memory in using it, isn't
it? My pram is only 512KB.
Bye,
Antonio.
^ permalink raw reply
* Re: [Qemu-devel] Absolute USB-HID device musings (was Re: VNC Terminal Server)
From: Brad Campbell @ 2006-04-09 19:22 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <44395575.1040303@austin.rr.com>
Lonnie Mendez wrote:
> Please see the patch posted yesterday to this mailing list:
>
> http://gnome.dnsalias.net/patches/qemu-hidmousexp.patch
Ta for that.. not sure how I missed it.
Now to try and get it to work..
Sprinkling printf's around the place it inits the usb controller and mouse, registers that mouse as
the mouse handler.. then promptly registers the ps2 mouse over the top.. so it's not working in any
case. Having disabled the ps2 mouse in windows.. I need to get friendly with keyboard navigation of
the device manager again ;)
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
^ permalink raw reply
* Re: [OOPS] related to swap?
From: Ian Kumlien @ 2006-04-09 19:31 UTC (permalink / raw)
To: Nick Piggin; +Cc: Linux-kernel
In-Reply-To: <44339031.4040307@yahoo.com.au>
[-- Attachment #1: Type: text/plain, Size: 936 bytes --]
On Wed, 2006-04-05 at 19:38 +1000, Nick Piggin wrote:
> Ian Kumlien wrote:
> > As i said, i really doubt that the memory is at fault here, it has done
> > several passes over the memory but not all tests. I can give it a go
> > though, but i really doubt it'll find anything.
>
> If it doesn't cost you much time (ie. do it overnight) it could save some
> developers a lot of time.
Well, the memory passes test 1-5 and 8. The 32 bit thingies all fail on
4 dimms, so either 4 dimms are broken or the test is broken for amd64.
Anyways, i noticed that the memory clocking got skewed when all the
memory was in the machine, so i've removed 1gb of memory.
> > The kernel i run is a plain 2.6.16.1 from kernel.org (i have heard that
> > you can actually compile gentoos own these days)
>
> OK, good.
2.6.16.2 now... And a new nvidia driver...
--
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 200 bytes --]
^ permalink raw reply
* Re: 2.6.17-rc1-mm2: badness in 3w_xxxx driver
From: Arjan van de Ven @ 2006-04-09 19:21 UTC (permalink / raw)
To: Jeff Garzik
Cc: Andrew Morton, Nick Orlov, linux-kernel, axboe, James.Bottomley
In-Reply-To: <44395C98.7010208@garzik.org>
> > Cc: <linuxraid@amcc.com>
> > ---
> >
> ACK.
>
> Though please make sure the active maintainer is CC'd on this... There
> is even a helpful MAINTAINERS entry for this driver.
I'd say it is ;-)
^ permalink raw reply
* Re: Black box flight recorder for Linux
From: Krzysztof Halasa @ 2006-04-09 19:23 UTC (permalink / raw)
To: James Courtier-Dutton; +Cc: linux list
In-Reply-To: <44379AB8.6050808@superbug.co.uk>
James Courtier-Dutton <James@superbug.co.uk> writes:
> Now, the question I have is, if I write values to RAM, do any of those
> values survive a reset? If any did survive, one could use them to
> store oops output in. I am currently only interested in Intel CPU and
> AMD CPU based motherboards. If only some values survived, one could
> use some sort of redundant encoding so the good values could be
> recovered.
>
> The main advantage of something like this would be for newer
> motherboards that are around now that don't have a serial port.
Interesting idea.
I think the most trivial and reliable way would be to solder some
I^2 or similar EEPROM chip to, for example, parallel port connector.
Most motherboards have an internal I^2C bus / SMBus (for reading RAM
types and for other things) and I think it could be used to connect
the EEPROM instead of external port.
There are 512 Kbit (64 KB) and 1 Mbit (128 KB) EEPROMs available -
there is plenty of space not only for crash dump but for whole dmesg.
--
Krzysztof Halasa
^ permalink raw reply
* [LARTC] tc counters "problem"
From: Francisco @ 2006-04-09 19:24 UTC (permalink / raw)
To: lartc
Hi, I'm using tc and HTB to shape my outgoing ADSL traffic. I was trying to
make some graphs on the classes by meassuring the "sent bytes" of each class
using rrdtool to store the data (as kbps after conversion). I expected that
meassuring the root class I would get values similar that the ones I get
measuring the interface counters but they differ by a large amount.
Is there something obvious I'm missing here?, is this approach correct?
Thank you.
Francisco
kaori ~ # tc -s class show dev ppp0
class htb 1:1 root rate 200000bit ceil 200000bit burst 6Kb/8 mpu 0b overhead
0b cburst 1699b/8 mpu 0b overhead 0b level 7
Sent 378286130 bytes 2185057 pkt (dropped 0, overlimits 0 requeues 0)
rate 182312bit 29pps backlog 0b 0p requeues 0
lended: 0 borrowed: 0 giants: 0
tokens: 168756 ctokens: -13270
class htb 1:10 parent 1:1 leaf 10: prio 1 rate 200000bit ceil 200000bit burst
6Kb/8 mpu 0b overhead 0b cburst 1699b/8 mpu 0b overhead 0b level 0
Sent 115548283 bytes 1520567 pkt (dropped 0, overlimits 0 requeues 0)
rate 1848bit 4pps backlog 0b 0p requeues 0
lended: 1520567 borrowed: 0 giants: 0
tokens: 250020 ctokens: 67994
class htb 1:20 parent 1:1 leaf 20: prio 2 rate 180000bit ceil 180000bit burst
6Kb/8 mpu 0b overhead 0b cburst 1689b/8 mpu 0b overhead 0b level 0
Sent 262755089 bytes 664505 pkt (dropped 0, overlimits 0 requeues 0)
rate 180456bit 25pps backlog 0b 15p requeues 0
lended: 664490 borrowed: 0 giants: 0
tokens: 113243 ctokens: -89463
class htb 1:30 parent 1:1 leaf 30: prio 3 rate 1000bit ceil 120000bit burst
6Kb/8 mpu 0b overhead 0b cburst 1659b/8 mpu 0b overhead 0b level 0
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
lended: 0 borrowed: 0 giants: 0
tokens: 50331648 ctokens: 113321
class htb 1:40 parent 1:1 leaf 40: prio 4 rate 1000bit ceil 60000bit burst
6Kb/8 mpu 0b overhead 0b cburst 1629b/8 mpu 0b overhead 0b level 0
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
lended: 0 borrowed: 0 giants: 0
tokens: 50331648 ctokens: 222548
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: [PATCH] git log [diff-tree options]...
From: Linus Torvalds @ 2006-04-09 19:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bgmbm8b.fsf@assigned-by-dhcp.cox.net>
On Sun, 9 Apr 2006, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > Well, on the other hand, the new "git log --diff" should get the revision
> > counting right even if it's _not_ done by the caller.
>
> Not if the user uses --diff-filter and/or --pickaxe, and after
> we start omitting the log message part when no diff is output.
Fair enough. At that point the counting does have to be done in the
caller, I guess.
> A merge commit touching a path but not actually changing the contents of
> the path from parents might be a significant event.
Yes. The fact that git-whatchanged happens to ignore such things right now
is just a implementation detail, not a "good thing". The new git log seems
to be better in pretty much all respects.
The bigger conceptual difference is actually that once you do revision
pruning based on the pathname limiter, we prune away parents of merges
that seem "uninteresting". So before, when you had the same change come
through two different branches, "git-whatchanged" would actually show it
twice, while the new "git log" approach would tend to show it just once
(because it would pick one of the histories and ignore the other).
I think that's fine (and probably even preferable), but it's another
example of something where we might want to have an option to not
simplify the merge history. It's likely that nobody will ever care, but
who knows..
Linus
^ permalink raw reply
* Re: Black box flight recorder for Linux
From: Eric W. Biederman @ 2006-04-09 19:25 UTC (permalink / raw)
To: Andi Kleen; +Cc: James Courtier-Dutton, Robert Hancock, linux-kernel
In-Reply-To: <200604091704.47566.ak@suse.de>
Andi Kleen <ak@suse.de> writes:
> On Saturday 08 April 2006 18:28, James Courtier-Dutton wrote:
>> Andi Kleen wrote:
>> > On Saturday 08 April 2006 16:05, Robert Hancock wrote:
>> >> Andi Kleen wrote:
>> >>> James Courtier-Dutton <James@superbug.co.uk> writes:
>> >>>> Now, the question I have is, if I write values to RAM, do any of those
>> >>>> values survive a reset?
>> >>> They don't generally.
>> >>>
>> >>> Some people used to write the oopses into video memory, but that
>> >>> is not portable.
>> >> I wouldn't think most BIOSes these days would bother to clear system RAM
>> >> on a reboot. Certainly Microsoft was encouraging vendors not to do this
>> >> because it slowed down system boot time.to
>> >
>> > Reset button is like a cold boot and it generally ends up with cleared
>> > RAM.
>> >
>> > -Andi
>>
>> Thank you. That saved me 30mins hacking. :-)
Actually clearing the memory can be done at full memory bandwidth
which can happen in seconds. On systems with ECC you need initialize
all of the check bits so some kind of write to memory needs to happen.
In practice a reset does not clear the memory and only a few bits
tend to get flipped. Unless you can get support from the
BIOS/firmware developers it isn't a practical approach though.
> First if you're not aware of this - the "official" way right now
> to solve this problem is kexec + kdump + a preloaded crash kernel. But in
> practice it still has many problems because a lot of drivers cannot
> reinitialize the hardware properly. And of course it will users need
> to load the crash kernel in advance and lose about 64MB of RAM.
Does a kernel really need 64M? That number seems insanely large
to me. 8M should be more than sufficient if someone actually
tried to be small. If you are aiming for a dedicated hardware
solution you don't need even need a kernel in there and the
amount reserved could be reduced to less than a meg.
The size etc becomes a trade off between what is expedient
and maintainable.
Eric
^ permalink raw reply
* Re: net interface renaming issue (+fix?)
From: Thomas de Grenier de Latour @ 2006-04-09 19:28 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20060409192140.73644723@eusebe>
On Sun, 9 Apr 2006 22:00:49 +0400,
Andrey Borzenkov <arvidjaar@mail.ru> wrote:
> net/core/dev.c:netdev_run_todo():
> err = netdev_register_sysfs(dev);
> if (err)
> printk(KERN_ERR "%s: failed sysfs
> registration (%d)\n",
> dev->name, err);
> dev->reg_state = NETREG_REGISTERED;
> break;
>
> So basically there is a window between net device appearing in sysfs
> and 'address' returning usable value. To test you could move
> dev->reg_state assignment before netdev_register_sysfs call; if this
> helps it makes sense ask on net list if this is safe change.
As far as i can test, yes, it works fine. I will forward your
suggestion to -netdev@.
Btw, many thanks to both of you, Andrey and Sergey, for the fast
answers and crystal-clear explanations of the actual issue.
--
TGL.
-------------------------------------------------------
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: [Xenomai-core] Proposal to use buildbot for Xenomai
From: Wolfgang Grandegger @ 2006-04-09 19:31 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-core
In-Reply-To: <4438E90F.6070304@domain.hid>
Jan Kiszka wrote:
> Niklaus Giger wrote:
>> Am Samstag, 8. April 2006 10:44 schrieb Jan Kiszka:
>>> Niklaus Giger wrote:
>>>> Hi everybody
>> <..>
>>> This is a really great idea! Of course, I already have another test
>>> candidate in mind: RTnet 8). Specifically the PPC environment would be
>>> interesting, as our "buildbot" (sorry, Wolfgang G. ;) ) is typically
>>> very busy so that build regressions are sometimes only detected with
>>> delay on that platform. Is it also possible to explicitly trigger an
>>> update and rebuild?
>> Yes of course. Just select a buildslave (e.g. ppc or hcu3 ->
>> http://ngiger.dyndns.org/buildbot/hcu3) and you may manually trigger it. I
>> intentionally left this facility open for everybody to test it. But it would
>> of course be possible to restrict it only to a few selected developers.
>>
>> If you want, I can help you to setup the master.cfg for a rtnet buildbot.
>
> I would love to, but you know - time...
>
>>> But also for Xenomai I would see this as a very useful tool, e.g. for
>>> 2.4 build tests (I must confess I only test sporadically against this
>>> kernel).
>> I will add one. Could you please e-mail me (privately if you want) a working
>> config (ppc, no cross compiling if possible). Or do you want to add a build
>> slave under your control?
>
> Hmm, I would prefer to just use something, especially as my PPC
> experiences are quite limited :). But I guess here are qualified people
> listening who can quickly dig out some config.
In arch/ppc/configs of the (DENX) 2.4 kernel are plenty of
configurations for the PowerPC boards, e.g. TQM8620_defconfig,
icecube_5200_defconfig, TQM866M_defconfig, etc. But we need cross
compilation for most of the embedded boards. Do you need the
configuration with IPIPE and Xenomai options enabled?
>
>> <..>
>>> Is there no reset button you could control via a master station, e.g. by
>>> attaching some cheap electronic to a parallel or serial port?
>> There is a reset button, but then you have it running and consuming
>> electricity all the times.
>
> Yep, understandable.
>
>>> I just remember that DENX once had or still have a remote PPC test-lab
>>> running. I CC'ed Wolfgang, maybe he could comment on this if and how it
>>> could be used.
>> I would be willing to setup a buildbot for the u-boot, too, as my board boots
>> with a very outdated version of u-boot.
We simply use remote controllable power switches to switch the boards on
and off.
Wolfgang.
^ permalink raw reply
* RE: PAE in 3.0.2
From: Ian Pratt @ 2006-04-09 19:31 UTC (permalink / raw)
To: Brian Hays, xen-devel
> I've noticed that the download repo doesn't have a PAE (32p)
> install build. Is PAE currently broken in 3.0.2?
No, it just a really anoying bug with the autobuild system, and I've
been sick and haven't gotten around to fixing it.
[The 'make oldconfig' is bailing out because it needs keyboard input]
Ian
^ permalink raw reply
* [ALSA - driver 0001331]: MSI K8N's SB Live 24 bit, no sound from line-in
From: bugtrack @ 2006-04-09 19:40 UTC (permalink / raw)
To: alsa-devel
The following issue has been ASSIGNED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1331>
======================================================================
Reported By: Cimmo
Assigned To: jcdutton
======================================================================
Project: ALSA - driver
Issue ID: 1331
Category: PCI - ca0106
Reproducibility: always
Severity: trivial
Priority: normal
Status: assigned
Distribution: Fedora Core 4
Kernel Version: 2.6.12-1.1398-x86_64
======================================================================
Date Submitted: 08-13-2005 01:27 CEST
Last Modified: 04-09-2006 21:40 CEST
======================================================================
Summary: MSI K8N's SB Live 24 bit, no sound from line-in
Description:
I have a MSI K8N Platinum motherboard that has a SBLive! 24 bit
integrated.
(Un)fortunatelly this motherboard provide two different jacks for Mic and
Line-In instead of one single jack like the pci version of the sb live 24
bit.
With this card I cannot hear any sound that come from line-in.
For Example I have a tv card, its output audio go into line-in: result is
I cannot hear nothing from the tv, I can only see channels without audio.
The "Capture feedback into playback" in the mixer change the mic's
volume.
There is nothing that change line-in's volume.
======================================================================
----------------------------------------------------------------------
jcdutton - 08-13-05 01:41
----------------------------------------------------------------------
In order to help me implement support for what you want, please try the
following:
arecord -fdat -Dhw:0,0 | aplay
arecord -fdat -Dhw:0,1 | aplay
arecord -fdat -Dhw:0,2 | aplay
arecord -fdat -Dhw:0,3 | aplay
Please tell me which one works for the "line in".
If should record from the line in and then play it to the speakers with a
small delay.
----------------------------------------------------------------------
Cimmo - 08-13-05 18:30
----------------------------------------------------------------------
There are some problems, none of the 4 lines works, this is what I have
done:
[cimmo@localhost ~]$ arecord -fdat -Dhw:0,0 | aplay
Recording WAVE 'stdout' : Signed 16 bit Little Endian, Rate 48000 Hz,
Stereo
Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
Aborted by signal Interrupt...
Aborted by signal Interrupt...
[cimmo@localhost ~]$ arecord -fdat -Dhw:0,1 | aplay
Recording WAVE 'stdout' : Signed 16 bit Little Endian, Rate 48000 Hz,
Stereo
Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
Aborted by signal Interrupt...
Aborted by signal Interrupt...
[cimmo@localhost ~]$ arecord -fdat -Dhw:0,2 | aplay
Recording WAVE 'stdout' : Signed 16 bit Little Endian, Rate 48000 Hz,
Stereo
Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
arecord: pcm_read:1252: read error: Input/output error
[cimmo@localhost ~]$ arecord -fdat -Dhw:0,3 | aplay
Recording WAVE 'stdout' : Signed 16 bit Little Endian, Rate 48000 Hz,
Stereo
Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
arecord: pcm_read:1252: read error: Input/output error
----------------------------------------------------------------------
Cimmo - 08-31-05 15:14
----------------------------------------------------------------------
What I have to do? Waiting for an answer...
----------------------------------------------------------------------
rlrevell - 08-31-05 18:59
----------------------------------------------------------------------
It's clearly a driver bug so all you can do at this point is wait for a
response from the driver developer.
----------------------------------------------------------------------
jcdutton - 09-10-05 10:31
----------------------------------------------------------------------
You might have an older version of the kernel driver.
Please post the output of: http://alsa.opensrc.org/TroubleShooting
Do Questions 1,2,3 and 4 and post the output here.
If you find that you do not have the latest alsa-driver, please try to
upgrade to it.
Please note that Line-in has never ever worked for your motherboard based
sound card in Linux, due to lack of enough information to implement it.
So, it is not really a bug, but instead a feature that we don't know how
to implement yet.
----------------------------------------------------------------------
Cimmo - 10-19-05 19:13
----------------------------------------------------------------------
1) Alsa is installed via module. Actually I've kernel v2.6.12.9
2) Advanced Linux Sound Architecture Driver Version 1.0.9 (Sun May 29
07:31:02 2005 UTC).
3) 1.0.9
4)
0 [CA0106 ]: CA0106 - CA0106
MSI K8N Diamond MB [SB0438] at 0xde00 irq 16
1 [Camera ]: USB-Audio - Camera
Camera at usb-0000:00:02.0-8, full speed
----------------------------------------------------------------------
jcdutton - 11-07-05 00:02
----------------------------------------------------------------------
The version of alsa-driver you have is too old.
Support for your sound card was only added recently.
Please upgrade your version of alsa-driver.
If you compiled your own kernel, then simply installing alsa-driver will
update them for you.
----------------------------------------------------------------------
Cimmo - 11-07-05 11:07
----------------------------------------------------------------------
So I've to switch to development version 1.0.10rc2?
----------------------------------------------------------------------
Cimmo - 11-11-05 19:33
----------------------------------------------------------------------
Ok I've compiled and installed succesfully alsa-driver and alsa-lib
1.0.10rc3
I've retested everything:
putting TV audio output to mic it works great, I can listen to TV!
With this configuration I'm be able to record and play with these 2
commands:
arecord -fdat -Dhw:0,1 | aplay
arecord -fdat -Dhw:0,2 | aplay
with line-in there is no chance: audio doesn't work, and none of the four
0,x works.
I've to stress Creative for documentation?
Tell me something
Thanx
Marco
----------------------------------------------------------------------
jcdutton - 12-13-05 13:16
----------------------------------------------------------------------
Ok, so now the mic in works, but line in does not.
The only way to fix this is if I get a hardware sample.
The connections of the mic and line in are hardware specific and different
from all other SB Live 24bit cards.
You could try and get MSI to send me a hardware sample if you wish to fix
this.
----------------------------------------------------------------------
Cimmo - 12-13-05 13:34
----------------------------------------------------------------------
Of course send to you a sample means that I have to pay for this and can't
do this :)
The only thing I can do is to give and ssh login to my pc to try via
remote, it can help you?
Issue History
Date Modified Username Field Change
======================================================================
08-13-05 01:27 Cimmo New Issue
08-13-05 01:27 Cimmo Distribution => Fedora Core 4
08-13-05 01:27 Cimmo Kernel Version => 2.6.12-1.1398-x86_64
08-13-05 01:41 jcdutton Note Added: 0005798
08-13-05 01:42 jcdutton Status assigned => feedback
08-13-05 18:30 Cimmo Note Added: 0005807
08-31-05 15:14 Cimmo Note Added: 0005989
08-31-05 18:59 rlrevell Note Added: 0005991
09-10-05 10:31 jcdutton Note Added: 0006107
10-19-05 19:13 Cimmo Note Added: 0006496
11-07-05 00:02 jcdutton Note Added: 0006610
11-07-05 11:07 Cimmo Note Added: 0006612
11-11-05 19:33 Cimmo Note Added: 0006678
12-13-05 13:16 jcdutton Note Added: 0007007
12-13-05 13:34 Cimmo Note Added: 0007015
04-09-06 21:40 jcdutton Status feedback => assigned
======================================================================
-------------------------------------------------------
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
* [ALSA - driver 0001331]: MSI K8N's SB Live 24 bit, no sound from line-in
From: bugtrack @ 2006-04-09 19:42 UTC (permalink / raw)
To: alsa-devel
The following issue has been CLOSED
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1331>
======================================================================
Reported By: Cimmo
Assigned To: jcdutton
======================================================================
Project: ALSA - driver
Issue ID: 1331
Category: PCI - ca0106
Reproducibility: always
Severity: trivial
Priority: normal
Status: closed
Distribution: Fedora Core 4
Kernel Version: 2.6.12-1.1398-x86_64
Resolution: open
Fixed in Version:
======================================================================
Date Submitted: 08-13-2005 01:27 CEST
Last Modified: 04-09-2006 21:42 CEST
======================================================================
Summary: MSI K8N's SB Live 24 bit, no sound from line-in
Description:
I have a MSI K8N Platinum motherboard that has a SBLive! 24 bit
integrated.
(Un)fortunatelly this motherboard provide two different jacks for Mic and
Line-In instead of one single jack like the pci version of the sb live 24
bit.
With this card I cannot hear any sound that come from line-in.
For Example I have a tv card, its output audio go into line-in: result is
I cannot hear nothing from the tv, I can only see channels without audio.
The "Capture feedback into playback" in the mixer change the mic's
volume.
There is nothing that change line-in's volume.
======================================================================
----------------------------------------------------------------------
Cimmo - 12-13-05 13:34
----------------------------------------------------------------------
Of course send to you a sample means that I have to pay for this and can't
do this :)
The only thing I can do is to give and ssh login to my pc to try via
remote, it can help you?
----------------------------------------------------------------------
jcdutton - 04-09-06 21:42
----------------------------------------------------------------------
Fixed in alsa cvs on 9-4-2006
Fixed in alsa cvs 1.0.11rc5 or above.
Issue History
Date Modified Username Field Change
======================================================================
08-13-05 01:27 Cimmo New Issue
08-13-05 01:27 Cimmo Distribution => Fedora Core 4
08-13-05 01:27 Cimmo Kernel Version => 2.6.12-1.1398-x86_64
08-13-05 01:41 jcdutton Note Added: 0005798
08-13-05 01:42 jcdutton Status assigned => feedback
08-13-05 18:30 Cimmo Note Added: 0005807
08-31-05 15:14 Cimmo Note Added: 0005989
08-31-05 18:59 rlrevell Note Added: 0005991
09-10-05 10:31 jcdutton Note Added: 0006107
10-19-05 19:13 Cimmo Note Added: 0006496
11-07-05 00:02 jcdutton Note Added: 0006610
11-07-05 11:07 Cimmo Note Added: 0006612
11-11-05 19:33 Cimmo Note Added: 0006678
12-13-05 13:16 jcdutton Note Added: 0007007
12-13-05 13:34 Cimmo Note Added: 0007015
04-09-06 21:40 jcdutton Status feedback => assigned
04-09-06 21:42 jcdutton Status assigned => closed
04-09-06 21:42 jcdutton Note Added: 0009185
======================================================================
-------------------------------------------------------
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: Watch Performance
From: Steve Grubb @ 2006-04-09 19:48 UTC (permalink / raw)
To: linux-audit; +Cc: redhat-lspp
In-Reply-To: <200604081221.58080.sgrubb@redhat.com>
Hi,
Based on finding an unnecessary function call to selinux_task_ctxid when
evaluating syscall rules, I built a new kernel and re-ran the same tests.
rules seconds loss
0 47 0%
10 53 11%
25 68 43%
50 99 109%
75 132 178%
90 157 232%
The 75 rule performance hit is now 178% instead of 184%. So there is some
notable improvement in performance.
For comparison, I also loaded the 90 rules config into RHEL4. There is only a
6% performance hit compared to no rules. I think the bulk of that comes from
evaluating the 10 syscall rules rather than the file system audit code.
-Steve
^ permalink raw reply
* Re: [LARTC] tc counters "problem"
From: Andreas Klauer @ 2006-04-09 19:50 UTC (permalink / raw)
To: lartc
In-Reply-To: <200604091624.20565.ranmakun@arnet.com.ar>
On Sun, Apr 09, 2006 at 04:24:20PM -0300, Francisco wrote:
> I expected that meassuring the root class I would get values similar that
> the ones I get measuring the interface counters but they differ by a
> large amount.
The statistics you posted seem to be fine. Which interface counters are
you talking about? tc starts counting only after the qdiscs/classes were
created, so if you have a separate count somewhere which started counting
some other time, the difference will of course be huge (as far as total
packet count is concerned).
Regards
Andreas Klauer
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* [2.6 patch] remove the obsolete IDEPCI_FLAG_FORCE_PDC
From: Adrian Bunk @ 2006-04-09 19:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Bartlomiej Zolnierkiewicz
This patch removes the obsolete IDEPCI_FLAG_FORCE_PDC.
Noted by Sergei Shtylylov <sshtylyov@ru.mvista.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
This patch was already sent on:
- 7 Apr 2006
drivers/ide/pci/pdc202xx_old.c | 2 --
drivers/ide/setup-pci.c | 13 -------------
include/linux/ide.h | 1 -
3 files changed, 16 deletions(-)
--- linux-2.6.17-rc1-mm1-full/include/linux/ide.h.old 2006-04-07 00:51:49.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/include/linux/ide.h 2006-04-07 00:52:03.000000000 +0200
@@ -1221,7 +1221,6 @@
enum {
/* Uses ISA control ports not PCI ones. */
IDEPCI_FLAG_ISA_PORTS = (1 << 0),
- IDEPCI_FLAG_FORCE_PDC = (1 << 1),
};
typedef struct ide_pci_device_s {
--- linux-2.6.17-rc1-mm1-full/drivers/ide/pci/pdc202xx_old.c.old 2006-04-07 00:52:13.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/drivers/ide/pci/pdc202xx_old.c 2006-04-07 00:52:19.000000000 +0200
@@ -798,7 +798,6 @@
.autodma = AUTODMA,
.bootable = OFF_BOARD,
.extra = 48,
- .flags = IDEPCI_FLAG_FORCE_PDC,
},{ /* 2 */
.name = "PDC20263",
.init_setup = init_setup_pdc202ata4,
@@ -819,7 +818,6 @@
.autodma = AUTODMA,
.bootable = OFF_BOARD,
.extra = 48,
- .flags = IDEPCI_FLAG_FORCE_PDC,
},{ /* 4 */
.name = "PDC20267",
.init_setup = init_setup_pdc202xx,
--- linux-2.6.17-rc1-mm1-full/drivers/ide/setup-pci.c.old 2006-04-07 00:52:27.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/drivers/ide/setup-pci.c 2006-04-07 00:54:28.000000000 +0200
@@ -580,7 +580,6 @@
int port;
int at_least_one_hwif_enabled = 0;
ide_hwif_t *hwif, *mate = NULL;
- static int secondpdc = 0;
u8 tmp;
index->all = 0xf0f0;
@@ -592,21 +591,9 @@
for (port = 0; port <= 1; ++port) {
ide_pci_enablebit_t *e = &(d->enablebits[port]);
- /*
- * If this is a Promise FakeRaid controller,
- * the 2nd controller will be marked as
- * disabled while it is actually there and enabled
- * by the bios for raid purposes.
- * Skip the normal "is it enabled" test for those.
- */
- if ((d->flags & IDEPCI_FLAG_FORCE_PDC) &&
- (secondpdc++==1) && (port==1))
- goto controller_ok;
-
if (e->reg && (pci_read_config_byte(dev, e->reg, &tmp) ||
(tmp & e->mask) != e->val))
continue; /* port not enabled */
-controller_ok:
if (d->channels <= port)
break;
^ permalink raw reply
* Re: [PATCH] i386/x86-64: Return defined error value for bad PCI config space accesses
From: Andi Kleen @ 2006-04-09 19:55 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Andrew Morton, Linux Kernel Mailing List
In-Reply-To: <44395DD2.8080700@garzik.org>
On Sunday 09 April 2006 21:17, Jeff Garzik wrote:
> As the code check indicates, value might be NULL.
>
> Please fix.
It should never be NULL. If anything that's a BUG_ON, but crashing on it is ok
too.
But I'll change it to a BUG_ON in the next patch thanks.
-Andi
^ 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.