* Re: [PATCH 2.6.17-rc6-mm2] fbdev: tag by scantype in sysfs
From: Antonino A. Daplas @ 2006-06-20 10:29 UTC (permalink / raw)
To: linux-fbdev-devel; +Cc: Antonino A. Daplas
In-Reply-To: <4497C289.5060007@st.com>
Daniel THOMPSON wrote:
> Antonino A. Daplas wrote:
>> Daniel THOMPSON wrote:
>>> There has been no further comment since this was posted in early May.
>>> This either means is uncontentious or useless ... I hope the former.
>>>
>> I thought you were still in 'discussion' mode with Geert :-)
>
> I was, but there was no further discussion so I brought it back to you.
>
>> Anyway, this should be fine, I'm just a bit worried that it might
>> break existing user apps that might be used to having modes without
>> the scan type specified.
>
> I shared this worry which is why my original patch only tagged the,
> comparatively rare, interlaced modes. However the current approach (no
> optional fields) is slightly cleaner and I took the view that since
> no-one on fbdev-devel seems to object ...
>
Okay. But if we are going to break this, let's break it with finality.
Does anyone believe that the above format is final? How about including
sync signals too?
#define FB_SYNC_HOR_HIGH_ACT 1 /* horizontal sync high active */
#define FB_SYNC_VERT_HIGH_ACT 2 /* vertical sync high active */
#define FB_SYNC_EXT 4 /* external sync */
#define FB_SYNC_COMP_HIGH_ACT 8 /* composite sync high active */
#define FB_SYNC_BROADCAST 16 /* broadcast video timings */
Secondly, that attribute 'modes' violate the 'one file, one value' rule of
sysfs (and that includes 'virtual_size', and 'pan'). We need to clean
these up. How about something like this?
/sys/class/graphics---fb0
:
--fb1
:
--fbn
:
--mode0---640x480@60
: :
: --1024x768@60
:
--mode1
where mode[n] represents the currently attached display to fb[n]
Tony
^ permalink raw reply
* Problem with UDP Connection Tracking Entry & ICMP Port Unreachable
From: nishit @ 2006-06-20 10:31 UTC (permalink / raw)
To: netfilter
Hi,
when i receieve icmp port unreachable error for any udp =
connection, conntrack entry for that connection is not deleted. Why is =
it So ??
Nishit Shah.
^ permalink raw reply
* Re: Raid5 reshape
From: Nigel J. Terry @ 2006-06-20 10:35 UTC (permalink / raw)
To: Neil Brown, linux-raid
In-Reply-To: <449734AE.10907@nigelterry.net>
Nigel J. Terry wrote:
Well good news and bad news I'm afraid...
Well I would like to be able to tell you that the time calculation now
works, but I can't. Here's why: Why I rebooted with the newly built
kernel, it decided to hit the magic 21 reboots and hence decided to
check the array for clean. The normally takes about 5-10 mins, but this
time took several hours, so I went to bed! I suspect that it was doing
the full reshape or something similar at boot time.
Now I am not sure that this makes good sense in a normal environment.
This could keep a server down for hours or days. I might suggest that if
such work was required, the clean check is postponed till next boot and
the reshape allowed to continue in the background.
Anyway the good news is that this morning, all is well, the array is
clean and grown as can be seen below. However, if you look further below
you will see the section from dmesg which still shows RIP errors, so I
guess there is still something wrong, even though it looks like it is
working. Let me know if i can provide any more information.
Once again, many thanks. All I need to do now is grow the ext3 filesystem...
Nigel
[root@homepc ~]# mdadm --detail /dev/md0
/dev/md0:
Version : 00.90.03
Creation Time : Tue Apr 18 17:44:34 2006
Raid Level : raid5
Array Size : 735334656 (701.27 GiB 752.98 GB)
Device Size : 245111552 (233.76 GiB 250.99 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Tue Jun 20 06:27:49 2006
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 128K
UUID : 50e3173e:b5d2bdb6:7db3576b:644409bb
Events : 0.3366644
Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1
2 3 65 2 active sync /dev/hdb1
3 22 1 3 active sync /dev/hdc1
[root@homepc ~]# cat /proc/mdstat
Personalities : [raid5] [raid4]
md0 : active raid5 sdb1[1] sda1[0] hdc1[3] hdb1[2]
735334656 blocks level 5, 128k chunk, algorithm 2 [4/4] [UUUU]
unused devices: <none>
[root@homepc ~]#
But from dmesg:
md: Autodetecting RAID arrays.
md: autorun ...
md: considering sdb1 ...
md: adding sdb1 ...
md: adding sda1 ...
md: adding hdc1 ...
md: adding hdb1 ...
md: created md0
md: bind<hdb1>
md: bind<hdc1>
md: bind<sda1>
md: bind<sdb1>
md: running: <sdb1><sda1><hdc1><hdb1>
raid5: automatically using best checksumming function: generic_sse
generic_sse: 6795.000 MB/sec
raid5: using function: generic_sse (6795.000 MB/sec)
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
raid5: reshape will continue
raid5: device sdb1 operational as raid disk 1
raid5: device sda1 operational as raid disk 0
raid5: device hdb1 operational as raid disk 2
raid5: allocated 4268kB for md0
raid5: raid level 5 set md0 active with 3 out of 4 devices, algorithm 2
RAID5 conf printout:
--- rd:4 wd:3 fd:1
disk 0, o:1, dev:sda1
disk 1, o:1, dev:sdb1
disk 2, o:1, dev:hdb1
...ok start reshape thread
md: syncing RAID array md0
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000
KB/sec) for reconstruction.
md: using 128k window, over a total of 245111552 blocks.
Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP:
<0000000000000000>{stext+2145382632}
PGD 7c3f9067 PUD 7cb9e067 PMD 0
Oops: 0010 [1] SMP
CPU 0
Modules linked in: raid5 xor usb_storage video button battery ac lp
parport_pc parport floppy nvram snd_intel8x0 snd_ac97_codec snd_ac97_bus
snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device
snd_pcm_oss snd_mixer_oss ehci_hcd ohci1394 ieee1394 sg snd_pcm uhci_hcd
i2c_nforce2 i2c_core forcedeth ohci_hcd snd_timer snd soundcore
snd_page_alloc dm_snapshot dm_zero dm_mirror dm_mod ext3 jbd sata_nv
libata sd_mod scsi_mod
Pid: 1432, comm: md0_reshape Not tainted 2.6.17-rc6 #1
RIP: 0010:[<0000000000000000>] <0000000000000000>{stext+2145382632}
RSP: 0000:ffff81007aa43d60 EFLAGS: 00010246
RAX: ffff81007cf72f20 RBX: ffff81007c682000 RCX: 0000000000000006
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff81007cf72f20
RBP: 0000000002090900 R08: 0000000000000000 R09: ffff810037f497b0
R10: 0000000b44ffd564 R11: ffffffff8022c92a R12: 0000000000000000
R13: 0000000000000100 R14: 0000000000000000 R15: 0000000000000000
FS: 000000000066d870(0000) GS:ffffffff80611000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 000000007bebc000 CR4: 00000000000006e0
Process md0_reshape (pid: 1432, threadinfo ffff81007aa42000, task
ffff810037f497b0)
Stack: ffffffff803dce42 0000000000000000 000000001d383600 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000
Call Trace: <ffffffff803dce42>{md_do_sync+1307}
<ffffffff802640c0>{thread_return+0}
<ffffffff8026411e>{thread_return+94}
<ffffffff8029925d>{keventd_create_kthread+0}
<ffffffff803dd3d9>{md_thread+248}
<ffffffff8029925d>{keventd_create_kthread+0}
<ffffffff803dd2e1>{md_thread+0} <ffffffff80232cb1>{kthread+254}
<ffffffff8026051e>{child_rip+8}
<ffffffff8029925d>{keventd_create_kthread+0}
<ffffffff802640c0>{thread_return+0} <ffffffff80232bb3>{kthread+0}
<ffffffff80260516>{child_rip+0}
Code: Bad RIP value.
RIP <0000000000000000>{stext+2145382632} RSP <ffff81007aa43d60>
CR2: 0000000000000000
<6>md: ... autorun DONE.
^ permalink raw reply
* Re: Linux 2.6.17.1
From: Michael Buesch @ 2006-06-20 10:35 UTC (permalink / raw)
To: Chris Wright; +Cc: stable, torvalds, linux-kernel
In-Reply-To: <20060620101350.GE23467@sequoia.sous-sol.org>
On Tuesday 20 June 2006 12:13, Chris Wright wrote:
> We (the -stable team) are announcing the release of the 2.6.17.1 kernel.
Please consider inclusion of the following patch into 2.6.17.2:
It fixes a possible crash. Might be triggerable in networks with
heavy traffic. I only saw it once so far, though.
--
Place the Init-vs-IRQ workaround before any card register
access, because we might not have the wireless core mapped
at all times in init. So this will result in a Machine Check
caused by a bus error.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Index: tmp/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===================================================================
--- tmp.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-06-18 18:51:48.000000000 +0200
+++ tmp/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-06-18 19:02:19.000000000 +0200
@@ -1870,6 +1870,15 @@
spin_lock(&bcm->_lock);
+ /* Only accept IRQs, if we are initialized properly.
+ * This avoids an RX race while initializing.
+ * We should probably not enable IRQs before we are initialized
+ * completely, but some careful work is needed to fix this. I think it
+ * is best to stay with this cheap workaround for now... .
+ */
+ if (unlikely(!bcm->initialized))
+ goto out;
+
reason = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
if (reason == 0xffffffff) {
/* irq not for us (shared irq) */
@@ -1891,20 +1900,11 @@
bcm43xx_interrupt_ack(bcm, reason);
- /* Only accept IRQs, if we are initialized properly.
- * This avoids an RX race while initializing.
- * We should probably not enable IRQs before we are initialized
- * completely, but some careful work is needed to fix this. I think it
- * is best to stay with this cheap workaround for now... .
- */
- if (likely(bcm->initialized)) {
- /* disable all IRQs. They are enabled again in the bottom half. */
- bcm->irq_savedstate = bcm43xx_interrupt_disable(bcm, BCM43xx_IRQ_ALL);
- /* save the reason code and call our bottom half. */
- bcm->irq_reason = reason;
- tasklet_schedule(&bcm->isr_tasklet);
- }
-
+ /* disable all IRQs. They are enabled again in the bottom half. */
+ bcm->irq_savedstate = bcm43xx_interrupt_disable(bcm, BCM43xx_IRQ_ALL);
+ /* save the reason code and call our bottom half. */
+ bcm->irq_reason = reason;
+ tasklet_schedule(&bcm->isr_tasklet);
out:
mmiowb();
spin_unlock(&bcm->_lock);
--
Greetings Michael.
^ permalink raw reply
* IO streams sync
From: alejandro @ 2006-06-20 10:38 UTC (permalink / raw)
To: alsa-devel
In-Reply-To: <mailman.4401.1150734905.2958.alsa-devel@lists.sourceforge.net>
Lee Revell escribió:
>On Mon, 2006-06-19 at 18:17 +0200, alejandro wrote:
>
>
>>Hello,
>>
>>Is there any document describing the ALSA components and functions?
>>Particularly the link between audio I/O and timers, in order to frame
>>accurate sync multiple audio cards and video.
>>
>>
>
>You probably want to be using JACK for this. ALSA is just a low level
>HAL. There are some patches floating around that add video capabilities
>("videojack").
>
>Lee
>
>
>
James Courtier-Dutton escribió:
>alejandro wrote:
>
>>Hello,
>>
>>Is there any document describing the ALSA components and functions?
>>Particularly the link between audio I/O and timers, in order to frame
>>accurate sync multiple audio cards and video.
>>
>>Thank you,
>>
>
>
>Alejandro,
>
>This is achieved using the snd_pcm_delay() function call.
>It gives you a measure of the number of samples between the current
>write pointer and the codec output.
>I.e. If you call snd_pcm_writei() now, it will be snd_pcm_delay() sample
>frames duration until the sample reach the speakers.
>So, from that you can accurately predict the exact time that a
>particular sample will reach the speakers, and therefore keep video in
>sync with it.
>This method is used in xine (http://xinehq.de)
>See the audio_out.c loop.
>
>One then combines this with a resampler (as xine does), to adjust for
>clock speed differences between sound cards and the system timer, so
>this prevents sync drift.
>
>James
>
>
>
Lee and James,
It is not possible to sync two interfaces if we don't have timestamped
frame numbering (UST/MSC pairs). That means that we need to know, from a
common clock, the time at which a (numbered) frame will be output or was
input from a jack. Current time is not usable, because obviously there
is an unknown delay between function calls. If the system is not able to
produce timestamp/frame count pairs, there is no possibility to sync
audio streams or audio to video streams. I have looked at JACK, and the
situation is the same as with the ALSA API.
There are cards in the market with such timestamped operations supported
in the hardware and proprietary APIs, but is there a way to accessing
these operations from ALSA or JACK?
Thank you,
Alejandro
--
Alejandro Palencia
Open Studio Networks
+34 932054354
^ permalink raw reply
* Re: [0/5] GSO: Generic Segmentation Offload
From: David Miller @ 2006-06-20 10:40 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <20060620093219.GF31854@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 20 Jun 2006 19:32:19 +1000
> On Tue, Jun 20, 2006 at 07:09:19PM +1000, herbert wrote:
> >
> > I've attached some numbers to demonstrate the savings brought on by
> > doing this. The best scenario is obviously the case where the underlying
> > NIC supports SG. This means that we simply have to manipulate the SG
> > entries and place them into individual skb's before passing them to the
> > driver. The attached file lo-res shows this.
>
> Obviously I forgot to attach them :)
:-)
The changes look good on first scan, I'll look more deeply and
meanwhile we'll let the patches ferment for a few days so others
can comment too :-)
^ permalink raw reply
* Re: [RFC 0/13] extents and 48bit ext3
From: Laurent Vivier @ 2006-06-20 10:40 UTC (permalink / raw)
To: Jeff Garzik
Cc: Andrew Morton, Stephen C. Tweedie,
ext2-devel@lists.sourceforge.net, linux-kernel, Linus Torvalds,
Mingming Cao, linux-fsdevel, alex, Andreas Dilger, Qi Yong
In-Reply-To: <4497C485.7000400@garzik.org>
[-- Attachment #1.1: Type: text/plain, Size: 2246 bytes --]
Jeff Garzik wrote:
> Laurent Vivier wrote:
>> Jeff Garzik wrote:
>>> Laurent Vivier wrote:
>>>> Qi Yong wrote:
>>>>> Linus Torvalds wrote:
>>>>>
>>>>>> On Fri, 9 Jun 2006, Stephen C. Tweedie wrote:
>>>>>>
>>>>>>
>>>>>>> When is the Linux syscall interface enough? When should we just
>>>>>>> bump it
>>>>>>> and cut out all the compatibility interfaces?
>>>>>>>
>>>>>>> No, we don't; we let people configure certain obsolete bits out
>>>>>>> (a.out
>>>>>>> support etc), but we keep it in the tree despite the indirection
>>>>>>> cost to
>>>>>>> maintain multiple interfaces etc.
>>>>>>>
>>>>>> Right. WE ADD NEW SYSTEM CALLS. WE DO NOT EXTEND THE OLD ONES IN
>>>>>> WAYS THAT MIGHT BREAK OLD USERS.
>>>>>>
>>>>>> Your point was exactly what?
>>>>>>
>>>>>> Btw, where did that 2TB limit number come from? Afaik, it should be
>>>>>> 16TB for a 4kB filesystem, no?
>>>>>>
>>>>>>
>>>>> Partition tables describe partitions in units of one sector.
>>>>> 2^(32+9) = 2T
>>>>>
>>>>> To prevent integer overflow, we should use only 31 bits of a 32-bit
>>>>> integer.
>>>>> 2^(31+12) = 8T
>>>>>
>>>>> There's _terrible_ hacks to really get to 16T.
>>>>>
>>>>> -- qiyong
>>>>>
>>>> IMHO, a simple solution is to use "Logical Volume Manager" instead of
>>>> partition
>>>> manager: we create 64bit filesystem in a Logical Volume, not in a
>>>> partition.
>>> That doesn't solve anything, if you are not using a 64bit filesystem.
>>
>> Sorry, I don't undestand why ???
>>
>> You can use 32bit filesystem too, but you limit the size of the
>> logical volume
>> to be compatible with the filesystem you use. LVM allows to create
>> several 32bit
>> volumes on a big (> 8T) disk (if exists)
>
> Let's review the thread:
>
> qiyong: <these limits> exist in the filesystem
> you: bust those limits with LVM!
>
> I think you are misunderstanding the subthread.
>
Yes...
I understood:
qiyong: <these limits> exist in the partition manager.
(because with patches proposed on http://www.bullopensource.org/ext4 these
limits don't exist anymore in the filesystem.)
Regards,
Laurent
--
Laurent Vivier
Bull, Architect of an Open World (TM)
http://www.bullopensource.org/ext4
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
[-- Attachment #3: Type: text/plain, Size: 161 bytes --]
_______________________________________________
Ext2-devel mailing list
Ext2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ext2-devel
^ permalink raw reply
* Re: [PATCH] AT91RM9200 NAND support
From: Savin Zlobec @ 2006-06-20 10:49 UTC (permalink / raw)
To: tglx; +Cc: linux-mtd
In-Reply-To: <1150795093.6780.117.camel@localhost.localdomain>
Thomas Gleixner wrote:
>On Tue, 2006-06-20 at 11:07 +0200, Savin Zlobec wrote:
>
>
>>I've put the kernel with latest mtd on my board and got the following:
>>
>>Nand is recognized as 'NAND device: Manufacturer ID: 0x98, Chip ID: 0x75
>>(Toshiba NAND 32MiB 3,3V 8-bit)',
>>should be 'NAND device: Manufacturer ID: 0xec, Chip ID: 0x75 (Samsung
>>NAND 32MiB 3,3V 8-bit)'.
>>
>>No bad blocks are detected at initial nand scan, but when running
>>flash_eraseall all blocks are found bad.
>>
>>
>
>Hmm. The interface has not changed, AFAICT. What version of
>flash_eraseall are you using and which commandline options ?
>
>Can you verify with the latest mtd-utils from
>
>http://git.infradead.org/?p=mtd-utils.git;a=summary
>
>
I did the following modifications to nand_base.c :
--- drivers/mtd/nand/nand_base.c.orig 2006-06-20 12:19:10.000000000 +0200
+++ drivers/mtd/nand/nand_base.c 2006-06-20 12:18:51.000000000 +0200
@@ -1134,10 +1134,6 @@
else
buf += ops->ooblen;
- readlen -= ops->ooblen;
- if (!readlen)
- break;
-
if (!(chip->options & NAND_NO_READRDY)) {
/*
* Apply delay or wait for ready/busy pin. Do this
@@ -1151,6 +1147,10 @@
nand_wait_ready(mtd);
}
+ readlen -= ops->ooblen;
+ if (!readlen)
+ break;
+
/* Increment page address */
realpage++;
And managed to erase the nand flash and mount JFFS2 on it, but writting
still
didn't work - got errors like :
Data CRC d507eb40 != calculated CRC 2e617dde for node at 00e4f700
The I put a call to nand_wait_ready at the top of nand_command function and
as far as I could test everything worked (exept that the flash is still
recognized
as Toshiba (0x98) not Samsung (0xec)).
It looks (to me) that there are still some parts of the code that should
wait for
nand to get ready before sending commands.
savin
^ permalink raw reply
* Re: [git pull] ieee1394 tree for 2.6.18
From: Stefan Richter @ 2006-06-20 10:38 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jody McIntyre, Andrew Morton, linux1394-devel, Ben Collins,
linux-kernel
In-Reply-To: <Pine.LNX.4.64.0606191902350.5498@g5.osdl.org>
Linus Torvalds wrote:
> On Sun, 18 Jun 2006, Stefan Richter wrote:
>>
>> the IEEE 1394 subsystem updates for Linux 2.6.18 are now staged in Ben's
>> revived linux1394 git tree. I guess the URL to pull from is
>> git://git.kernel.org/pub/scm/linux/kernel/git/bcollins/linux1394-2.6.git
>
> I'm sure that URL works fine, but I want to see what I'm pulling before I
> pull it, so _please_ use one of the scripts that generates diffstats and
> shortlogs, or do it by hand..
Here are stat and shortlog; not from the actual git tree but from patches as
they went in. Side notes: The spike in the diffstat is whitespace formatting.
Sem2mutex and kthread conversions as well as suspend/resume fixes are not
complete yet.
Documentation/feature-removal-schedule.txt | 4
drivers/ieee1394/Kconfig | 13
drivers/ieee1394/csr1212.c | 2
drivers/ieee1394/csr1212.h | 1
drivers/ieee1394/dma.c | 18
drivers/ieee1394/eth1394.c | 51 +-
drivers/ieee1394/eth1394.h | 2
drivers/ieee1394/highlevel.c | 445 +++++++++------------
drivers/ieee1394/hosts.c | 7
drivers/ieee1394/hosts.h | 19
drivers/ieee1394/ieee1394_core.c | 62 +-
drivers/ieee1394/ieee1394_transactions.c | 10
drivers/ieee1394/nodemgr.c | 61 ++
drivers/ieee1394/ohci1394.c | 37 +
drivers/ieee1394/ohci1394.h | 10
drivers/ieee1394/raw1394.c | 54 +-
drivers/ieee1394/sbp2.c | 85 +---
drivers/ieee1394/sbp2.h | 23 -
drivers/ieee1394/video1394.c | 16
19 files changed, 463 insertions(+), 457 deletions(-)
Alexey Dobriyan:
eth1394: endian fixes
Arjan van de Ven:
Semaphore to mutex conversion.
Christoph Hellwig, Andrew Morton:
ieee1394_core: switch to kthread API
Daniel Drake:
video1394: be quiet
Jean-Baptiste Mur:
ieee1394/ohci1394: CycleTooLong interrupt management
Jim Westfall:
ieee1394: speed up of dma_region_sync_for_cpu
Jody McIntyre:
Update feature removal of obsolete raw1394 ISO requests.
Robert Hancock:
Fix broken suspend/resume in ohci1394
Stefan Richter:
eth1394: replace __constant_htons by htons
ieee1394: adjust code formatting in highlevel.c
ieee1394: hl_irqs_lock is taken in hardware interrupt context
ieee1394: add preprocessor constant for invalid csr address
ieee1394: extend lowlevel API for address range properties
ieee1394: save RAM by using a single tlabel for broadcast transactions
ieee1394: support for slow links or slow 1394b phy ports
ohci1394: make phys_dma parameter read-only
ohci1394: set address range properties
ohci1394: Remove superfluous call to free_dma_rcv_ctx,
raw1394: fix whitespace after x86_64 compat patch
sbp2: Kconfig fix
sbp2: fix deregistration of status fifo address space
sbp2: use __attribute__((packed)) for on-the-wire structures
sbp2: provide helptext for CONFIG_IEEE1394_SBP2_PHYS_DMA and mark it experimental
sbp2: fix S800 transfers if phys_dma is off
sbp2: remove ohci1394 specific constant
sbp2: log number of supported concurrent logins
sbp2: remove manipulation of inquiry response
sbp2: make TSB42AA9 workaround specific to Momobay CX-1
--
Stefan Richter
-=====-=-==- -==- =-=--
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH] Fix the build error of Wind River PPMC board
From: Mark.Zhan @ 2006-06-20 10:40 UTC (permalink / raw)
To: Mark.Zhan; +Cc: linux-mips, ralf
In-Reply-To: <4497CAA6.1010809@windriver.com>
Hi,
Sorry for the stupid line wrap problem, again.
It is re-posted.
Signed-off-by: Rongkai.Zhan <rongkai.zhan@windriver.com>
------
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 89ec332..e38f0cd 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -360,7 +360,7 @@ config MIPS_SEAD
board.
config WR_PPMC
- bool "Support for Wind River PPMC board"
+ bool "Wind River PPMC board"
select IRQ_CPU
select BOOT_ELF32
select DMA_NONCOHERENT
diff --git a/arch/mips/gt64120/wrppmc/Makefile b/arch/mips/gt64120/wrppmc/Makefile
index 72606b9..7cf5220 100644
--- a/arch/mips/gt64120/wrppmc/Makefile
+++ b/arch/mips/gt64120/wrppmc/Makefile
@@ -9,6 +9,6 @@
# Makefile for the Wind River MIPS 4KC PPMC Eval Board
#
-obj-y += int-handler.o irq.o reset.o setup.o time.o pci.o
+obj-y += irq.o reset.o setup.o time.o pci.o
EXTRA_AFLAGS := $(CFLAGS)
diff --git a/arch/mips/gt64120/wrppmc/int-handler.S b/arch/mips/gt64120/wrppmc/int-handler.S
deleted file mode 100644
index edee7b3..0000000
--- a/arch/mips/gt64120/wrppmc/int-handler.S
+++ /dev/null
@@ -1,59 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * Copyright (C) 1995, 1996, 1997, 2003 by Ralf Baechle
- * Copyright (C) Wind River System Inc. Rongkai.Zhan <rongkai.zhan@windriver.com>
- */
-#include <asm/asm.h>
-#include <asm/mipsregs.h>
-#include <asm/addrspace.h>
-#include <asm/regdef.h>
-#include <asm/stackframe.h>
-#include <asm/mach-wrppmc/mach-gt64120.h>
-
- .align 5
- .set noat
-NESTED(handle_IRQ, PT_SIZE, sp)
- SAVE_ALL
- CLI # Important: mark KERNEL mode !
- .set at
-
- mfc0 t0, CP0_CAUSE # get pending interrupts
- mfc0 t1, CP0_STATUS # get enabled interrupts
- and t0, t0, t1 # get allowed interrupts
- andi t0, t0, 0xFF00
- beqz t0, 1f
- move a1, sp # Prepare 'struct pt_regs *regs' pointer
-
- andi t1, t0, CAUSEF_IP7 # CPU Compare/Count internal timer
- bnez t1, handle_cputimer_irq
- andi t1, t0, CAUSEF_IP6 # UART 16550 port
- bnez t1, handle_uart_irq
- andi t1, t0, CAUSEF_IP3 # PCI INT_A
- bnez t1, handle_pci_intA_irq
-
- /* wrong alarm or masked ... */
-1: j spurious_interrupt
- nop
-END(handle_IRQ)
-
- .align 5
-handle_cputimer_irq:
- li a0, WRPPMC_MIPS_TIMER_IRQ
- jal do_IRQ
- j ret_from_irq
-
- .align 5
-handle_uart_irq:
- li a0, WRPPMC_UART16550_IRQ
- jal do_IRQ
- j ret_from_irq
-
- .align 5
-handle_pci_intA_irq:
- li a0, WRPPMC_PCI_INTA_IRQ
- jal do_IRQ
- j ret_from_irq
-
diff --git a/arch/mips/gt64120/wrppmc/irq.c b/arch/mips/gt64120/wrppmc/irq.c
index 8605687..80d6b79 100644
--- a/arch/mips/gt64120/wrppmc/irq.c
+++ b/arch/mips/gt64120/wrppmc/irq.c
@@ -30,7 +30,19 @@
#include <asm/irq_cpu.h>
#include <asm/gt64120.h>
-extern asmlinkage void handle_IRQ(void);
+asmlinkage void plat_irq_dispatch(struct pt_regs *regs)
+{
+ unsigned int pending = read_c0_status() & read_c0_cause();
+
+ if (pending & STATUSF_IP7)
+ do_IRQ(WRPPMC_MIPS_TIMER_IRQ, regs); /* CPU Compare/Count internal timer */
+ else if (pending & STATUSF_IP6)
+ do_IRQ(WRPPMC_UART16550_IRQ, regs); /* UART 16550 port */
+ else if (pending & STATUSF_IP3)
+ do_IRQ(WRPPMC_PCI_INTA_IRQ, regs); /* PCI INT_A */
+ else
+ spurious_interrupt(regs);
+}
/**
* Initialize GT64120 Interrupt Controller
@@ -53,9 +65,6 @@ void __init arch_init_irq(void)
/* enable all CPU interrupt bits. */
set_c0_status(ST0_IM); /* IE bit is still 0 */
- /* Install MIPS Interrupt Trap Vector */
- set_except_vector(0, handle_IRQ);
-
/* IRQ 0 - 7 are for MIPS common irq_cpu controller */
mips_cpu_irq_init(0);
diff --git a/arch/mips/gt64120/wrppmc/setup.c b/arch/mips/gt64120/wrppmc/setup.c
index 20c591e..2db6375 100644
--- a/arch/mips/gt64120/wrppmc/setup.c
+++ b/arch/mips/gt64120/wrppmc/setup.c
@@ -125,7 +125,7 @@ static void wrppmc_setup_serial(void)
}
#endif
-void __init plat_setup(void)
+void __init plat_mem_setup(void)
{
extern void wrppmc_time_init(void);
extern void wrppmc_timer_setup(struct irqaction *);
^ permalink raw reply related
* Re: [Ext2-devel] [RFC 0/13] extents and 48bit ext3
From: Laurent Vivier @ 2006-06-20 10:40 UTC (permalink / raw)
To: Jeff Garzik
Cc: Qi Yong, Linus Torvalds, Andrew Morton, Stephen C. Tweedie,
ext2-devel@lists.sourceforge.net, linux-kernel, Mingming Cao,
linux-fsdevel, alex, Andreas Dilger
In-Reply-To: <4497C485.7000400@garzik.org>
[-- Attachment #1: Type: text/plain, Size: 2246 bytes --]
Jeff Garzik wrote:
> Laurent Vivier wrote:
>> Jeff Garzik wrote:
>>> Laurent Vivier wrote:
>>>> Qi Yong wrote:
>>>>> Linus Torvalds wrote:
>>>>>
>>>>>> On Fri, 9 Jun 2006, Stephen C. Tweedie wrote:
>>>>>>
>>>>>>
>>>>>>> When is the Linux syscall interface enough? When should we just
>>>>>>> bump it
>>>>>>> and cut out all the compatibility interfaces?
>>>>>>>
>>>>>>> No, we don't; we let people configure certain obsolete bits out
>>>>>>> (a.out
>>>>>>> support etc), but we keep it in the tree despite the indirection
>>>>>>> cost to
>>>>>>> maintain multiple interfaces etc.
>>>>>>>
>>>>>> Right. WE ADD NEW SYSTEM CALLS. WE DO NOT EXTEND THE OLD ONES IN
>>>>>> WAYS THAT MIGHT BREAK OLD USERS.
>>>>>>
>>>>>> Your point was exactly what?
>>>>>>
>>>>>> Btw, where did that 2TB limit number come from? Afaik, it should be
>>>>>> 16TB for a 4kB filesystem, no?
>>>>>>
>>>>>>
>>>>> Partition tables describe partitions in units of one sector.
>>>>> 2^(32+9) = 2T
>>>>>
>>>>> To prevent integer overflow, we should use only 31 bits of a 32-bit
>>>>> integer.
>>>>> 2^(31+12) = 8T
>>>>>
>>>>> There's _terrible_ hacks to really get to 16T.
>>>>>
>>>>> -- qiyong
>>>>>
>>>> IMHO, a simple solution is to use "Logical Volume Manager" instead of
>>>> partition
>>>> manager: we create 64bit filesystem in a Logical Volume, not in a
>>>> partition.
>>> That doesn't solve anything, if you are not using a 64bit filesystem.
>>
>> Sorry, I don't undestand why ???
>>
>> You can use 32bit filesystem too, but you limit the size of the
>> logical volume
>> to be compatible with the filesystem you use. LVM allows to create
>> several 32bit
>> volumes on a big (> 8T) disk (if exists)
>
> Let's review the thread:
>
> qiyong: <these limits> exist in the filesystem
> you: bust those limits with LVM!
>
> I think you are misunderstanding the subthread.
>
Yes...
I understood:
qiyong: <these limits> exist in the partition manager.
(because with patches proposed on http://www.bullopensource.org/ext4 these
limits don't exist anymore in the filesystem.)
Regards,
Laurent
--
Laurent Vivier
Bull, Architect of an Open World (TM)
http://www.bullopensource.org/ext4
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Linux 2.6.17.1
From: Chris Wright @ 2006-06-20 10:44 UTC (permalink / raw)
To: Michael Buesch; +Cc: Chris Wright, stable, torvalds, linux-kernel
In-Reply-To: <200606201235.19811.mb@bu3sch.de>
* Michael Buesch (mb@bu3sch.de) wrote:
> On Tuesday 20 June 2006 12:13, Chris Wright wrote:
> > We (the -stable team) are announcing the release of the 2.6.17.1 kernel.
>
> Please consider inclusion of the following patch into 2.6.17.2:
>
> It fixes a possible crash. Might be triggerable in networks with
> heavy traffic. I only saw it once so far, though.
I didn't notice that it made it to Linus' tree yet. Can you make sure
to push it up, and I'll queue it for -stable.
thanks,
-chris
^ permalink raw reply
* Re: configuring iptables for masquerading
From: Pascal Hambourg @ 2006-06-20 10:50 UTC (permalink / raw)
To: netfilter
In-Reply-To: <002b01c6939b$3e0f4580$cf34000a@sven>
Hello,
Angel Tsankov a écrit :
> I've configured iptables for masquerading and when some of the
> masqueraded hosts performs a trace route I get this:
>
> tracert www.abv.bg
MS Windows traceroute ?
> Tracing route to www.abv.bg [194.153.145.105]
> over a maximum of 30 hops:
>
> 1 17 ms 5 ms 6 ms 194.153.145.105
>
> Trace complete.
Same with any source and destination hosts ?
Does "normal" access (web, ftp...) to the destination host work ?
This looks like the result of a TTL normalization that could be caused
by an iptables rule with the TTL target in the 'mangle' table. You can
dump the active ruleset with the command 'iptables-save'.
> This route is obviously too short. I have attached the
> /etc/rc.d/rc.iptables file. Could someone tell me what I have misconfigured?
I don't see anything which could cause such behaviour in your script.
^ permalink raw reply
* [PATCH] ide: disable dma for transcend CF
From: Kirill Smelkov @ 2006-06-20 10:52 UTC (permalink / raw)
To: Andrew Morton, B.Zolnierkiewicz; +Cc: linux-kernel, linux-ide
NB: bart/ide-2.6.git seems to be unmaintained, so I'm sending this directly to -mm
I have a CF card which identifies itself as model=TRANSCEND rev=200508011
The card id labeled as TS512MCF80
hdparm -i /dev/hdci reports:
...
DMA modes: mdma0 mdma1 *mdma2
IDE controller:
IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
but if dma is turned on i get a lot of errors::
hdc: dma_timer_epiry: dma_status == 0x21
hdc: DMA timeout error
hdc: dma timeout error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
...
So blacklist this CF model.
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Index: linux-2.6.17/drivers/ide/ide-dma.c
===================================================================
--- linux-2.6.17.orig/drivers/ide/ide-dma.c 2006-06-18 05:49:35.000000000 +0400
+++ linux-2.6.17/drivers/ide/ide-dma.c 2006-06-20 11:37:30.000000000 +0400
@@ -129,6 +129,7 @@
{ "SanDisk SDP3B-64" , "ALL" },
{ "ATAPI CD-ROM DRIVE 40X MAXIMUM", "ALL" },
{ "_NEC DV5800A", "ALL" },
+ { "TRANSCEND" , "20050811" },
{ NULL , NULL }
};
^ permalink raw reply
* [PATCH] ide: fix revision comparison in ide_in_drive_list
From: Kirill Smelkov @ 2006-06-20 10:52 UTC (permalink / raw)
To: Andrew Morton, B.Zolnierkiewicz; +Cc: linux-kernel, linux-ide
NB: bart/ide-2.6.git seems to be unmaintained, so I'm sending this directly to -mm
Fix ide_in_drive_list: drive_table->id_firmware should be searched *in* id->fw_rev,
not vise versa.
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Index: linux-2.6.17/drivers/ide/ide-dma.c
===================================================================
--- linux-2.6.17.orig/drivers/ide/ide-dma.c 2006-06-20 13:51:49.000000000 +0400
+++ linux-2.6.17/drivers/ide/ide-dma.c 2006-06-20 13:52:14.000000000 +0400
@@ -147,7 +147,7 @@
{
for ( ; drive_table->id_model ; drive_table++)
if ((!strcmp(drive_table->id_model, id->model)) &&
- ((strstr(drive_table->id_firmware, id->fw_rev)) ||
+ ((strstr(id->fw_rev, drive_table->id_firmware)) ||
(!strcmp(drive_table->id_firmware, "ALL"))))
return 1;
return 0;
^ permalink raw reply
* [Qemu-devel] cvttps2dq, movdq2q, movq2dq incorrect behaviour
From: Julian Seward @ 2006-06-20 10:54 UTC (permalink / raw)
To: qemu-devel
The SSE2 instructions cvttps2dq, movdq2q, movq2dq do not behave
correctly, as shown by the attached program. It should print
cvttps2dq_1 ... ok
cvttps2dq_2 ... ok
movdq2q_1 ... ok
movq2dq_1 ... ok
but instead produces
cvttps2dq_1 ... ok
cvttps2dq_2 ... not ok
result0.sd[0] = 12 (expected 12)
result0.sd[1] = 3 (expected 56)
result0.sd[2] = -2147483648 (expected 43)
result0.sd[3] = 3 (expected 87)
movdq2q_1 ... not ok
result0.uq[0] = 1302123111658042420 (expected 5124095577148911)
movq2dq_1 ... not ok
result0.uq[0] = 1302123111658042420 (expected 5124095577148911)
result0.uq[1] = 6221254864647256184 (expected 0)
I looked at QEMU's instruction decoders for these, and compared them
to Valgrind's, but could not see what the problem was. The decode
logic looks OK. Maybe the problem is elsewhere.
J
-------------------------------------------------------------------
#include <math.h>
#include <setjmp.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
typedef union {
char sb[1];
unsigned char ub[1];
} reg8_t;
typedef union {
char sb[2];
unsigned char ub[2];
short sw[1];
unsigned short uw[1];
} reg16_t;
typedef union {
char sb[4];
unsigned char ub[4];
short sw[2];
unsigned short uw[2];
long int sd[1];
unsigned long int ud[1];
float ps[1];
} reg32_t;
typedef union {
char sb[8];
unsigned char ub[8];
short sw[4];
unsigned short uw[4];
long int sd[2];
unsigned long int ud[2];
long long int sq[1];
unsigned long long int uq[1];
float ps[2];
double pd[1];
} reg64_t __attribute__ ((aligned (8)));
typedef union {
char sb[16];
unsigned char ub[16];
short sw[8];
unsigned short uw[8];
long int sd[4];
unsigned long int ud[4];
long long int sq[2];
unsigned long long int uq[2];
float ps[4];
double pd[2];
} reg128_t __attribute__ ((aligned (16)));
static sigjmp_buf catchpoint;
static void handle_sigill(int signum)
{
siglongjmp(catchpoint, 1);
}
__attribute__((unused))
static int eq_float(float f1, float f2)
{
return f1 == f2 || fabsf(f1 - f2) < fabsf(f1) * 1.5 * pow(2,-12);
}
__attribute__((unused))
static int eq_double(double d1, double d2)
{
return d1 == d2 || fabs(d1 - d2) < fabs(d1) * 1.5 * pow(2,-12);
}
static void cvttps2dq_1(void)
{
reg128_t arg0 = { .ps = { 12.34F, 56.78F, 43.21F, 87.65F } };
reg128_t arg1 = { .sd = { 1L, 2L, 3L, 4L } };
reg128_t result0;
char state[108];
if (sigsetjmp(catchpoint, 1) == 0)
{
asm(
"fsave %3\n"
"movlps 0%0, %%xmm4\n"
"movhps 8%0, %%xmm4\n"
"movlps 0%1, %%xmm5\n"
"movhps 8%1, %%xmm5\n"
"cvttps2dq %%xmm4, %%xmm5\n"
"movlps %%xmm5, 0%2\n"
"movhps %%xmm5, 8%2\n"
"frstor %3\n"
:
: "m" (arg0), "m" (arg1), "m" (result0), "m" (state[0])
: "xmm4", "xmm5"
);
if (result0.sd[0] == 12L && result0.sd[1] == 56L && result0.sd[2] == 43L
&& result0.sd[3] == 87L )
{
printf("cvttps2dq_1 ... ok\n");
}
else
{
printf("cvttps2dq_1 ... not ok\n");
printf(" result0.sd[0] = %ld (expected %ld)\n", result0.sd[0], 12L);
printf(" result0.sd[1] = %ld (expected %ld)\n", result0.sd[1], 56L);
printf(" result0.sd[2] = %ld (expected %ld)\n", result0.sd[2], 43L);
printf(" result0.sd[3] = %ld (expected %ld)\n", result0.sd[3], 87L);
}
}
else
{
printf("cvttps2dq_1 ... failed\n");
}
return;
}
static void cvttps2dq_2(void)
{
reg128_t arg0 = { .ps = { 12.34F, 56.78F, 43.21F, 87.65F } };
reg128_t arg1 = { .sd = { 1L, 2L, 3L, 4L } };
reg128_t result0;
char state[108];
if (sigsetjmp(catchpoint, 1) == 0)
{
asm(
"fsave %3\n"
"movlps 0%1, %%xmm5\n"
"movhps 8%1, %%xmm5\n"
"cvttps2dq %0, %%xmm5\n"
"movlps %%xmm5, 0%2\n"
"movhps %%xmm5, 8%2\n"
"frstor %3\n"
:
: "m" (arg0), "m" (arg1), "m" (result0), "m" (state[0])
: "xmm4", "xmm5"
);
if (result0.sd[0] == 12L && result0.sd[1] == 56L && result0.sd[2] == 43L
&& result0.sd[3] == 87L )
{
printf("cvttps2dq_2 ... ok\n");
}
else
{
printf("cvttps2dq_2 ... not ok\n");
printf(" result0.sd[0] = %ld (expected %ld)\n", result0.sd[0], 12L);
printf(" result0.sd[1] = %ld (expected %ld)\n", result0.sd[1], 56L);
printf(" result0.sd[2] = %ld (expected %ld)\n", result0.sd[2], 43L);
printf(" result0.sd[3] = %ld (expected %ld)\n", result0.sd[3], 87L);
}
}
else
{
printf("cvttps2dq_2 ... failed\n");
}
return;
}
static void movdq2q_1(void)
{
reg128_t arg0 = { .uq = { 0x012345678abcdefULL, 0xfedcba9876543210ULL } };
reg64_t arg1 = { .uq = { 0x1212121234343434ULL } };
reg64_t result0;
char state[108];
if (sigsetjmp(catchpoint, 1) == 0)
{
asm(
"fsave %3\n"
"movlps 0%0, %%xmm4\n"
"movhps 8%0, %%xmm4\n"
"movq %1, %%mm6\n"
"movdq2q %%xmm4, %%mm6\n"
"movq %%mm6, %2\n"
"frstor %3\n"
:
: "m" (arg0), "m" (arg1), "m" (result0), "m" (state[0])
: "xmm4", "mm6"
);
if (result0.uq[0] == 0x012345678abcdefULL )
{
printf("movdq2q_1 ... ok\n");
}
else
{
printf("movdq2q_1 ... not ok\n");
printf(" result0.uq[0] = %llu (expected %llu)\n", result0.uq[0],
0x012345678abcdefULL);
}
}
else
{
printf("movdq2q_1 ... failed\n");
}
return;
}
static void movq2dq_1(void)
{
reg64_t arg0 = { .uq = { 0x012345678abcdefULL } };
reg128_t arg1 = { .uq = { 0x1212121234343434ULL, 0x5656565678787878ULL } };
reg128_t result0;
char state[108];
if (sigsetjmp(catchpoint, 1) == 0)
{
asm(
"fsave %3\n"
"movq %0, %%mm6\n"
"movlps 0%1, %%xmm4\n"
"movhps 8%1, %%xmm4\n"
"movq2dq %%mm6, %%xmm4\n"
"movlps %%xmm4, 0%2\n"
"movhps %%xmm4, 8%2\n"
"frstor %3\n"
:
: "m" (arg0), "m" (arg1), "m" (result0), "m" (state[0])
: "mm6", "xmm4"
);
if (result0.uq[0] == 0x012345678abcdefULL && result0.uq[1] == 0ULL )
{
printf("movq2dq_1 ... ok\n");
}
else
{
printf("movq2dq_1 ... not ok\n");
printf(" result0.uq[0] = %llu (expected %llu)\n", result0.uq[0],
0x012345678abcdefULL);
printf(" result0.uq[1] = %llu (expected %llu)\n", result0.uq[1],
0ULL);
}
}
else
{
printf("movq2dq_1 ... failed\n");
}
return;
}
int main(int argc, char **argv)
{
signal(SIGILL, handle_sigill);
cvttps2dq_1();
cvttps2dq_2();
movdq2q_1();
movq2dq_1();
exit(0);
}
^ permalink raw reply
* Re: [PATCH] no_pci_serial
From: Milan Svoboda @ 2006-06-20 10:11 UTC (permalink / raw)
To: Russell King; +Cc: linux-kernel, Russell King
Thank you for your reply.
I have created these patches (no_pci_serial and no_pci_mem) because I got
some errors (missing ixp4xx_pci_write/read)
when I tried to compile kernel for ixp4xx without pci bus support. Now, I
tried it again and got clean build. I think I had to forget
to do make clean before...
Milan Svoboda
Russell King <rmk+lkml@arm.linux.org.uk>
Sent by: Russell King <rmk@arm.linux.org.uk>
06/16/2006 09:31 PM
To: Milan Svoboda <msvoboda@ra.rockwell.com>
cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] no_pci_serial
On Fri, Jun 16, 2006 at 03:21:08PM +0000, Milan Svoboda wrote:
> This patch allows to compile 8250 driver on systems without pci bus.
inb/outb/readb/writeb methods have nothing to do with the presence of
a PCI bus or not, so the patch is wrong - and it actually breaks a lot
of machine implementations which use this.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: Linux 2.6.17.1
From: Michael Buesch @ 2006-06-20 10:56 UTC (permalink / raw)
To: Chris Wright, linville; +Cc: stable, torvalds, linux-kernel
In-Reply-To: <20060620104416.GG23467@sequoia.sous-sol.org>
On Tuesday 20 June 2006 12:44, Chris Wright wrote:
> * Michael Buesch (mb@bu3sch.de) wrote:
> > On Tuesday 20 June 2006 12:13, Chris Wright wrote:
> > > We (the -stable team) are announcing the release of the 2.6.17.1 kernel.
> >
> > Please consider inclusion of the following patch into 2.6.17.2:
> >
> > It fixes a possible crash. Might be triggerable in networks with
> > heavy traffic. I only saw it once so far, though.
>
> I didn't notice that it made it to Linus' tree yet. Can you make sure
> to push it up, and I'll queue it for -stable.
It is in -mm and I think John Linville also queued it upstream
through Jeff to Linus.
>From my perspective, everything is done ;)
--
Greetings Michael.
^ permalink raw reply
* Re: Mailing list slow?
From: Massimiliano Hofer @ 2006-06-20 10:57 UTC (permalink / raw)
To: netfilter-devel; +Cc: Patrick McHardy
In-Reply-To: <4496C3D7.2040809@trash.net>
On Monday 19 June 2006 5:33 pm, Patrick McHardy wrote:
> Is it just me or are other people also experiencing large
> delays with mails to netfilter-devel? My mails are visible
> on the lists.netfilter.org web interface but I receive them
> with large delay ..
Some of my messages took 24 hours to make it throu (after being delivered to
vishnu.netfilter.org).
On several occasions I had problem sending them in the first place. Here is
one of my postfix logs:
Jun 18 09:16:53 waobagger postfix/smtp[9876]: 685DC3D3353:
to=<netfilter-devel@lists.netfilter.org>,
relay=vishnu.netfilter.org[213.95.27.115], delay=30082, status=deferred (host
vishnu.netfilter.org[213.95.27.115] said: 451 Error while writing spool file
(in reply to end of DATA command))
--
Saluti,
Massimiliano Hofer
^ permalink raw reply
* Re: Mailing list slow?
From: Amin Azez @ 2006-06-20 10:57 UTC (permalink / raw)
To: netfilter-devel
In-Reply-To: <4496C3D7.2040809@trash.net>
Patrick McHardy wrote:
> Is it just me or are other people also experiencing large
> delays with mails to netfilter-devel? My mails are visible
> on the lists.netfilter.org web interface but I receive them
> with large delay ..
I post via NNTP at news.gmane.org and a rate patch for ipt_account has
taken 4 days to arrive.
I've also seen less posts in the last few days than I would expect.
Sam
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: Add title attribute with unshortened value for table cells
From: Timo Hirvonen @ 2006-06-20 10:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e78gun$65s$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Timo Hirvonen wrote:
>
> > http://onion.dynserv.net/git/gitweb.cgi
> >
> > Global symbol "$path" requires explicit package name at
> > /var/www/localhost/htdocs/git/gitweb.cgi line 1521.
> > Execution of /var/www/localhost/htdocs/git/gitweb.cgi aborted due to
> > compilation errors.
> >
> > The line is:
> >
> > $file =~ m#^/# or $file = "$projectroot/$path/$file";
> >
> > $path seems to be undefined. I don't understand perl very well so I
> > can't fix it.
>
> Temporary fix is in:
>
> "[PATCH] Fix: Support for the standard mime.types map in gitweb"
> (Message-Id: <11507843541678-git-send-email-jnareb@gmail.com>)
> http://permalink.gmane.org/gmane.comp.version-control.git/22172
Seems to work now. I also enabled blame and it works too. But I noticed
that the search is sometimes broken. If you click a "blob" link and
then try to search something gitweb will complain:
403 Forbidden - Unknown commit object.
"h" parameter is blob, not commit. Shouldn't the h parameter be set to
HEAD always when searching? Searching starts at h so the search results
vary:
http://onion.dynserv.net/git/gitweb.cgi?p=cmus.git&a=search&h=HEAD&s=pickaxe%3Atheme
http://onion.dynserv.net/git/gitweb.cgi?p=cmus.git&a=search&h=fd2d983d51858e25cc71b14b59c787e1683ba7c5&s=pickaxe%3Atheme
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* spinlock recursion bug
From: Oliver Spang @ 2006-06-20 10:58 UTC (permalink / raw)
To: linux-kernel
Arghhh, forgot the subject, so sorry for the repost:
I got the following bug from the kernel (2.6.16):
BUG: Spinlock recursion on CPU#0, swapped/0 (not tained)
lock d94566c4, .magic:dead4ead, .owner: swapper/0, .owner_cpu:0
BUG: Spinloc lockup on CPU#0, swapper/0, d94566c4 (not tained)
Unfortunately there is no dump or call trace afterwards, and the address of the lock isn't the same on each crash.
Could you give me a hint how to get a call trace after the crash, or can I somehow resolve the address of the lock to a symbol?
Can you please CC me, because I'm not subscribed to the list.
Regards,
Oliver
--
"Feel free" – 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
^ permalink raw reply
* Re: Linux 2.6.17.1
From: Chris Wright @ 2006-06-20 10:57 UTC (permalink / raw)
To: Michael Buesch; +Cc: Chris Wright, linville, stable, torvalds, linux-kernel
In-Reply-To: <200606201256.27252.mb@bu3sch.de>
* Michael Buesch (mb@bu3sch.de) wrote:
> It is in -mm and I think John Linville also queued it upstream
> through Jeff to Linus.
> From my perspective, everything is done ;)
Sounds good, thanks.
-chris
^ permalink raw reply
* Re: [patch] increase spinlock-debug looping timeouts (write_lock and NMI)
From: Nick Piggin @ 2006-06-20 10:59 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andrew Morton, Dave Olson, ccb, linux-kernel, Peter Chubb,
Arjan van de Ven
In-Reply-To: <20060620095135.GC11037@elte.hu>
[Corrected Arjan's address I messed up earlier.]
Ingo Molnar wrote:
> * Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>
>
>>Ingo Molnar wrote:
>>
>>>curious, do you have any (relatively-) simple to run testcase that
>>>clearly shows the "scalability issues" you mention above, when going
>>
>>>from rwlocks to spinlocks? I'd like to give it a try on an 8-way box.
>>
>>Arjan van de Ven wrote:
>>
>>>I'm curious what scalability advantage you see for rw spinlocks vs real
>>>spinlocks ... since for any kind of moderate hold time the opposite is
>>>expected ;)
>>
>>It actually surprised me too, but Peter Chubb (who IIRC provided the
>>motivation to merge the patch) showed some fairly significant
>>improvement at 12-way.
>>
>>https://www.gelato.unsw.edu.au/archives/scalability/2005-March/000069.html
>
>
> i think that workload wasnt analyzed well enough (by us, not by Peter,
> who sent a reasonable analysis and suggested a reasonable change), and
> we went with whatever magic change appeared to make a difference,
> without fully understanding the underlying reasons. Quote:
>
> "I'm not sure what's happening in the 4-processor case."
>
> Now history appears to be repeating itself, just in the other direction
> ;) And we didnt get one inch closer to understanding the situation for
> real. I'd vote for putting a change-moratorium on tree-lock and only
> allow a patch that tweaks it that fully analyzes the workload :-)
>
> one thing off the top of my mind: doesnt lockstat introduce significant
> overhead? Is this reproducable with lockstat turned off too? Is the same
> scalability problem visible if all read_lock()s are changed to
> write_lock()? [like i did in my patch] I.e. can other explanations (like
> unlucky alignment of certain rwlock data structures / functions) be
> excluded.
Yes, it would need re-testing.
>
> another thing: average hold times in the spinlock case on that workload
> are below 1 microsecond - probably on the range of cachemiss bounce
> costs on such a system.
It's the wait time that I'd be more worried about. As I said, my wild
guess is that the wait times are creeping up.
> I.e. it's the worst possible case for a
> spinlock->rwlock conversion! The only reason i can believe this to make
> a difference are cycle level races and small random micro-differences
> that cause heavier bouncing in the spinlock workload but happen to avoid
> it in the read-lock case. Not due to any fundamental advantage of
> rwlocks.
I'd say the 12 way results show that there is a fundamental advantage
(although that's pending whether or not lockstat is wrecking the results).
I'd even go out on a limb ;) and say that it will only become more
pronounced at higher cpu counts.
Correct me if I'm wrong, but... a read-lock requires at most a single
cacheline transfer per lock acq and a single per release, no matter the
concurrency on the lock (so long as it is read only).
A spinlock is going to take more. If the hardware perfectly round-robins
the cacheline, it will take lockers+1 transfers per lock+unlock. Of
course, hardware might be pretty unfair for efficiency, but there will
still be some probability of the cacheline bouncing to other lockers
while it is locked. And that probability will increase proportionally to
the number of lockers.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* Re: APRS Parser
From: Curt, WE7U @ 2006-06-20 11:00 UTC (permalink / raw)
To: Jeff Laughlin; +Cc: Chuck Hast, linux-hams
In-Reply-To: <8ea83f40606192129t28c742y94299329b8548076@mail.gmail.com>
On Mon, 19 Jun 2006, Jeff Laughlin wrote:
> I started on an APRS parser written in perl. It handles most of the
> major bits of the standard and I used it to dump APRS data into
> postgresql and it kept up with the global APRS internet feeds no
> problem, in fact I was suprised at how fast it was. It turned out that
> PostgreSQL consumed vastly more system resources than the parser and
> that was mostly disk IO, CPU load was relatively light. It could
> certainly still use some work but it's functional and well documented
> and I included example code. You can get it from
> http://sourceforge.net/projects/ham-aprs-parser/
There's also the Perl APRS code that Ian wrote (the APRS spec
editor) which validates packets. I should have a copy of it around
somewhere if you can't find it on the 'net. That would be excellent
code to have around as an example, just because it was at one time
the most complete Perl decoder implementation.
On SourceForge I believe there are C++ classes and perhaps Java code
for parsing APRS sentences, and of course the Xastir project
(SourceForge again) has a bunch of C code. It's a _bunch_ of C code
though!
I also have Perl code for authenticating on the 'net if you'd like
that. It's a direct Perl translation of the C-code that Steve Dimse
published and I use it extensively in my Perl scripts which inject
objects into Firenet.
--
Curt, WE7U. APRS Client Comparisons: http://www.eskimo.com/~archer
"Lotto: A tax on people who are bad at math." -- unknown
"Windows: Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
^ 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.