* Re: Marvell MV88SX6041 SATA Driver PIO4 Mode Not DMA
From: Jeff Garzik @ 2005-11-11 14:03 UTC (permalink / raw)
To: Jens Axboe; +Cc: Spencer Tuttle, linux-ide
In-Reply-To: <20051111121447.GQ3699@suse.de>
Jens Axboe wrote:
> On Fri, Nov 11 2005, Jeff Garzik wrote:
>
>>Spencer Tuttle wrote:
>>
>>>I have just compiled the new 2.6.14 kernel from the gentoo-sources tree.
>>>
>>>I can access the drives just fine, but it seems really slow. Here is
>>>the dmesg output when I load the kernel module
>>
>>That's expected, since the driver in 2.6.14 only does PIO mode.
>>
>>Try 2.6.14-gitN which supports EDMA.
>
>
> Did you see these as well:
>
> blk_queue_max_hw_segments: set to minimum 1
>
> Could it be forgetting to set ->sg_tablesize as well?
[jgarzik@sata linux-2.6]$ grep MV_MAX_SG_CT drivers/scsi/sata_mv.c
MV_MAX_SG_CT = 176,
MV_SG_TBL_SZ = (16 * MV_MAX_SG_CT),
.sg_tablesize = MV_MAX_SG_CT,
^ permalink raw reply
* [SOLVED] Re: [Qemu-devel] 32bit emulation in x86_64 System emulation
From: Mario Goppold @ 2005-11-11 14:00 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <200510270837.04842.mgoppold@tbz-pariv.de>
Hi list,
i have found some partial solutions for my problem:
1st: write a script for individual programs
#!/bin/sh
export LD_ASSUME_KERNEL=2.4 # this disables tls
a.out # or some useful
2nd: disable thread-local storage (tls) for 32-bit programs
mv /lib/tls /lib/tls.disabled
ldconfig
Mario.
Am Donnerstag, 27. Oktober 2005 08:37 schrieb Mario Goppold:
> Hi list,
>
> I've tried to install SuSE92 x68_64 as guest (qemu 0.7.2 with and without
> kqemu). During the install grub terminates with core. But not only grub
> terminates:
>
> #include <stdio.h>
> int main() {
> printf("Hallo Welt!\n");
> return 0;
> }
>
> gcc a.c ; ./a.out is ok but
> gcc -m32 a.c; ./a.out Segmentation fault (core dumped)
>
> with gdb:
> Core was generated by `./a.out'.
> Program terminated with signal 11, Segmentation fault.
>
> warning: current_sos: Can't read pathname for load map: Input/output
> error
>
> Reading symbols from /lib/tls/libc.so.6...done.
> Loaded symbols for /lib/tls/libc.so.6
> Reading symbols from /lib/ld-linux.so.2...done.
> Loaded symbols for /lib/ld-linux.so.2
> #0 0x5568aff4 in ?? () from /lib/tls/libc.so.6
> (gdb) where
> #0 0x5568aff4 in ?? () from /lib/tls/libc.so.6
> #1 0x555d4bf3 in _IO_file_stat_internal () from /lib/tls/libc.so.6
> #2 0x555d4bf3 in _IO_file_stat_internal () from /lib/tls/libc.so.6
> #3 0x555ca494 in _IO_file_doallocate_internal () from /lib/tls/libc.so.6
> #4 0x555d77be in _IO_doallocbuf_internal () from /lib/tls/libc.so.6
> #5 0x555d550a in _IO_new_file_overflow () from /lib/tls/libc.so.6
> #6 0x555d49fd in _IO_new_file_xsputn () from /lib/tls/libc.so.6
> #7 0x555b25e8 in vfprintf () from /lib/tls/libc.so.6
> #8 0x555ba7b0 in printf () from /lib/tls/libc.so.6
> #9 0x080483e0 in main () at a.c:4
>
> What's worng? Outside of qemu it works fine.
> In the meantime i've found out that's not (only) a SuSE problem:
>
> SuSE92, SuSE93, SuSE10, FC4 fails but Ubuntu 5.10 works fine (all in
> x86_64).
>
> Have anyone see this behaviour. What can i do?
>
> Mario
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
^ permalink raw reply
* How to speed up raid1 resync ?
From: Nicolas Mailhot @ 2005-11-11 14:00 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 4056 bytes --]
Hi,
I'm performing various lvm/raid experiments on my system. As a result,
I've trashed one of the two disks of a raid1 set. So now the raid is
rebuilding, as soon as it finished I intend to retry experimenting
(disconnect one drive in the raid set, experiment with the other, if big
mistake replug the other one and sync with it).
However mdmadm resync is dog slow (if gracefully backgrounded)
$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 hdc1[2] hda1[0]
2096384 blocks [2/1] [U_]
resync=DELAYED
md1 : active raid1 hdc3[2] hda3[0]
76886976 blocks [2/1] [U_]
[=>...................] recovery = 5.6% (4374912/76886976)
finish=1164.8min speed=1036K/sec
Is there a way to speed it up ? I don't want to wait 1164.8min, and I
don't care if the resync monopolises most of the system.
Kernel is 2.6.14-git11 based (from Fedora Core Devel)
The two disks are identical PATA models :
ATA device, with non-removable media
Model Number: Maxtor 6Y080L0
Serial Number:
Firmware Revision: YAR41BW0
Standards:
Supported: 7 6 5 4
Likely used: 7
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 160086528
device size with M = 1024*1024: 78167 MBytes
device size with M = 1000*1000: 81964 MBytes (81 GB)
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 1
Standby timer values: spec'd by Standard, no device specific
minimum
R/W multiple sector transfer: Max = 16 Current = 16
Advanced power management level: unknown setting (0x0000)
Recommended acoustic management value: 192, current value: 128
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5
*udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* NOP cmd
* READ BUFFER cmd
* WRITE BUFFER cmd
* Host Protected Area feature set
* Look-ahead
* Write cache
* Power Management feature set
Security Mode feature set
SMART feature set
* FLUSH CACHE EXT command
* Mandatory FLUSH CACHE command
* Device Configuration Overlay feature set
* Automatic Acoustic Management feature set
SET MAX security extension
Advanced Power Management feature set
* DOWNLOAD MICROCODE cmd
* SMART self-test
* SMART error logging
Security:
Master password revision code = 65534
supported
not enabled
not locked
frozen
not expired: security count
not supported: enhanced erase
HW reset results:
CBLID- above Vih
Device num = 0 determined by the jumper
Checksum: correct
on the following controller :
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) (prog-if 8a
[Master SecP PriP])
Subsystem: Giga-byte Technology: Unknown device 5002
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Region 4: I/O ports at f000 [size=16]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Regards,
--
Nicolas Mailhot
[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Slowdown is gone & apt-get works with updated reiser4. So nevermind...
From: John Gilmore @ 2005-11-11 13:59 UTC (permalink / raw)
To: reiserfs-list
I grabbed the reiser4 patch for 2.6.14-rc5 and compiled it. Thanks to
Vladimir V. Saveliev's comments about
EXPORT_SYMBOL(clear_page_dirty_for_io);
in mm/page-writeback.c, I was able to get it working as a module, and it seems
to have taken care of it.
I would have waited for the official 2.6.14-mm1 reiser patch before upgrading
to 2.6.14, but CD burning didn't work with 2.6.12.
<rant>
There is, btw, one main reason that I've decided that whatever trouble it may
cause, and whatever growing pangs I may experience along the way, root
reiser4 is worth it. Does anybody remember GoBack? It was a versioning system
for windows 95/98 that was incredibly flexible and useful. Tracked all
changes to the whole disk. Old versions of a file? no problem. grab an old
version of a directory for referance temporarily? easy. Got a virus? revert
the whole HD, and then grab the newer copies of your documents and saved
games as needed.
Microsoft includes an almost useless version of the same ability with their
"system restore" facility on XP, but I've never seen or heard of anybody
using it. And rightfully so, it majorly stinks. It doesn't track all files,
it's interface is opaque, the fact that it even exists is hidden seven layers
deep, you can't control which files are restored, you can't list previous
versions of a file, you can't copy an old version of a subdirectory and it's
contents out without wiping the new version. You can bet that in 10 years or
so, Microsoft will come out with a version of system restore that doesn't
suck though. Integrated into the file manager, right click access, and
everything else too.
Goback is the only thing that I missed when I switched over to linux, and
reiser4 is the only thing I've found that even hints at a similar ability.
Even if it takes another 10 years to reach the same point of usability that
GoBack had, it'll be well worth it.
And when that day comes, I won't even have to reformat (you didn't have to
reformat to install GoBack, either.) It's been 10 years or so since my last
format (Hrmm... a little over eight, actually) and I figured that as long as
my HD was trashed (another reason to love reiser4 - any fs that has a
standard tool that commonly trashes file systems beyond any hope of
recovery... darn fsck.ext3) I might as well prepare for the future, and get
better performance while I'm at it.
Note though, that features are definitely the first thing for me, performance
is nice but not something that I'll notice too much, and I'd definitely be
willing to sacrifice some to get enhanced semantics or versioning. Compiles
take forever no matter what you do, and as long as the little things (like
starting vim) don't take longer than a second or two, that's good enough.
</rant>
^ permalink raw reply
* Re: [netfilter-core] Re: [PATCH] ip_conntrack_proto_tcp
From: Patrick McHardy @ 2005-11-11 13:58 UTC (permalink / raw)
To: Pablo Neira; +Cc: coreteam, Vlad Drukker, netfilter-devel
In-Reply-To: <437495E7.5050500@eurodev.net>
Pablo Neira wrote:
> Vlad Drukker wrote:
>
>>Attached patch for ip_conntrack to account TCP sessions started with SYN
>>+PUSH flags. Looks weird, but some HW vendors do TCP their own way.
>>
>>Let's earn some points from RFC 1025.
>
> I see this patch like a sort of workaround to make broken devices with
> the TCP connection tracking, right? In that case, I don't think that
> it's a good idea polluting our code with workarounds for every existing
> broken device. The HW vendors must fix their devices.
Unfortunately this is unlikely to happen, and if Linux itself
accepts SYN|PSH, I don't see a reason why ip_conntrack shouldn't
as well.
^ permalink raw reply
* doubts about intent-logging
From: Carlos Carvalho @ 2005-11-11 13:56 UTC (permalink / raw)
To: linux-raid
If I understand the Compendium (also known as mdadm manpage :-) ) the
intent-logging bitmap is stored near the superblock when the name
"internal" is specified. Does this mean that it'll be in the 128KB
area of the superblock? If so, what happens if there isn't enough
space? This is likely for medium-to-large arrays, say 500+GB with the
default chunk 4K.
About the size of the bitmap-chunk, wouldn't it be better if it were
the size of a stripe? I ask this because I thought all IO to an array
was done in multiples of the stripe size even if the write request is
smaller.
What's the influence of intent-logging in the performance of a raid5
array? It seems that it'll increase the number of writes, so a
degradation is likely, no? This is important to decide if
intent-logging is worth. I'd think that it's only worth for machines
that crash often and leave the array dirty.
^ permalink raw reply
* Re: [JFFS2]remove totlen from jffs2_raw_node_ref
From: Artem B. Bityutskiy @ 2005-11-11 13:52 UTC (permalink / raw)
To: Pierre.Ricadat@UTBM.fr; +Cc: linux-mtd
In-Reply-To: <1131701962.437466ca80ccc@webmail2.utbm.fr>
Pierre.Ricadat@UTBM.fr wrote:
> Hi'
>
> I'm trying to remove totlen from jffs2_raw_node_ref structure.
>
> Could you confirm (or not) the following changes are needed? I understood that
> from http://lists.infradead.org/pipermail/linux-mtd/2003-October/008689.html
>
> - create a jffs2_raw_node_ref structure even for the dirty nodes (in scan.c :
> case JFFS2_NODETYPE_CLEANMARKER, line 632)
>
> - create a jffs2_raw_node_ref for the obsolete nodes we add to wasted (in
> scan.c, line 729)
>
> - then modify the calls to totlen in the other files and use
> ref_totlen()instead.
Hi, I implemented this once and AFAIR, yes, it was enough.
--
Best Regards,
Artem B. Bityutskiy,
St.-Petersburg, Russia.
^ permalink raw reply
* Re: Compilation Issue on RG9
From: Krzysztof Oledzki @ 2005-11-11 13:49 UTC (permalink / raw)
To: Hai Wang; +Cc: netfilter-devel
In-Reply-To: <5efe1e0b0511110543v7d24c88bmc7c0dd761e502f01@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 565 bytes --]
On Fri, 11 Nov 2005, Hai Wang wrote:
> Hello everyone
Helllo,
> I encountered a problem when I tried to compile iptables-1.3.4 on RH9 (
> 2.4.25), I got the following errors, please shed some lights on it.
>
> ensions/libipt_time_sh.o -c extensions/libipt_time.c
> extensions/libipt_time.c: In function `init':
> extensions/libipt_time.c:66: structure has no member named `date_start'
> extensions/libipt_time.c:67: structure has no member named `date_stop'
Whitch version of patch-o-magic did you use?
Best regards,
Krzysztof Olędzki
^ permalink raw reply
* Re: [PATCH 21/20] v4l: prevent saa7134 alsa undefined warnings
From: Takashi Iwai @ 2005-11-11 13:49 UTC (permalink / raw)
To: Mike Krufky
Cc: Andrew Morton, Linux and Kernel Video, linux-kernel,
Mauro Carvalho Chehab
In-Reply-To: <4373CBC6.4080305@linuxtv.org>
At Thu, 10 Nov 2005 17:37:58 -0500,
Mike Krufky wrote:
>
> Prevent the following build warnings:
>
> *** Warning: "snd_card_free"
> *** Warning: "snd_card_register"
> *** Warning: "snd_device_new"
> *** Warning: "snd_card_new"
> *** Warning: "snd_ctl_add"
> *** Warning: "snd_ctl_new1"
> *** Warning: "snd_pcm_set_ops"
> *** Warning: "snd_pcm_new"
> *** Warning: "snd_pcm_lib_ioctl"
> *** Warning: "snd_pcm_hw_constraint_integer"
> *** Warning: "snd_pcm_stop"
> *** Warning: "snd_pcm_period_elapsed"
> [drivers/media/video/saa7134/saa7134-alsa.ko] undefined!
>
> Signed-off-by: Michael Krufky <mkrufky@m1k.net>
> Acked-by: Mauro Carvalho Chehab <mchehab@brturbo.com.br>
>
> drivers/media/video/saa7134/Kconfig | 2 +-
> 1 files changed, 1 insertion(+), 1 deletion(-)
>
> --- linux.orig/drivers/media/video/saa7134/Kconfig
> +++ linux/drivers/media/video/saa7134/Kconfig
> @@ -1,6 +1,6 @@
> config VIDEO_SAA7134
> tristate "Philips SAA7134 support"
> - depends on VIDEO_DEV && PCI && I2C && SOUND
> + depends on VIDEO_DEV && PCI && I2C && SOUND && SND && SND_PCM_OSS
No, this driver should select SND_PCM_OSS, instead.
Takashi
^ permalink raw reply
* Re: [RFC] Support for stackable file systems on top of nfs
From: John T. Kohl @ 2005-11-11 13:45 UTC (permalink / raw)
To: Trond Myklebust, dhowells, nfsv4, fsdevel
In-Reply-To: <1131681856.8804.103.camel@lade.trondhjem.org>
>>>>> "Trond" == Trond Myklebust <trondmy@trondhjem.org> writes:
Trond> On Thu, 2005-11-10 at 21:32 -0500, Trond Myklebust wrote:
>> It sounds to me like you want to talk to the cachefs folks. They too
>> need special hooks in the NFS low-level page cache routines in order to
>> be able to mirror write requests to the local backing store and/or
>> reroute read requests to that backing store.
Trond> Note: I'm not saying that you should special case Clearcase for NFS, but
Trond> if both you and cachefs have similar requirements for hooks, then
Trond> perhaps we could look for a common solution (perhaps at the VFS level?).
Thanks for the encouragement.
It looks to me like the i_mapping and f_mapping stuff is intended to let
a stacking file system share pages with a backing-store file system (we
really want to share pages, it's efficient and avoids a whole host of
cache coherency problems), but the interfaces are not adequate for that
to work with NFS as the backing-store.
Other than i_mapping/f_mapping, I don't think it's possible right now
for stacking file systems to handle the address_space operations in our
layer *and* share the same pages with the backing-store, since the struct
pages are attached to the address space via file->f_mapping.
So yeah, if NFS or other file systems need to have a file pointer for
its paging operations, sounds like we need some changes in the VM/file
system interfaces to provide page sharing for stacking file systems.
[Special-casing for NFS would be tricky and probably improper--should we
really care what's below us? How would we determine that our backing
store inode is an NFS inode (or any other sort that doesn't handle
i_mapping hosting)? We don't have access to the NFS symbol names for
the file_operations or address_space_operations, so we can't even cheat
and determine whether the object below us is NFS.
So in essence the i_mapping/f_mapping stuff is not really fully usable,
unless the stacking file system "knows" that the backing store is safe.]
--
John Kohl
Senior Software Engineer - Rational Software - IBM Software Group
Lexington, Massachusetts, USA
jtk@us.ibm.com
<http://www.ibm.com/software/rational/>
^ permalink raw reply
* Compilation Issue on RG9
From: Hai Wang @ 2005-11-11 13:43 UTC (permalink / raw)
To: netfilter-devel
Hello everyone
I encountered a problem when I tried to compile iptables-1.3.4 on RH9 (
2.4.25), I got the following errors, please shed some lights on it.
Thanks!
Hai
ensions/libipt_time_sh.o -c extensions/libipt_time.c
extensions/libipt_time.c: In function `init':
extensions/libipt_time.c:66: structure has no member named `date_start'
extensions/libipt_time.c:67: structure has no member named `date_stop'
extensions/libipt_time.c: In function `parse':
extensions/libipt_time.c:394: structure has no member named `date_start'
extensions/libipt_time.c:407: structure has no member named `date_stop'
extensions/libipt_time.c: In function `print':
extensions/libipt_time.c:489: structure has no member named `date_start'
extensions/libipt_time.c:492: structure has no member named `date_start'
extensions/libipt_time.c:494: structure has no member named `date_stop'
extensions/libipt_time.c:497: structure has no member named `date_stop'
extensions/libipt_time.c: In function `save':
extensions/libipt_time.c:524: structure has no member named `date_start'
extensions/libipt_time.c:525: structure has no member named `date_stop'
make: *** [extensions/libipt_time_sh.o] Error 1
^ permalink raw reply
* Re: Rename window
From: Trond Myklebust @ 2005-11-11 13:41 UTC (permalink / raw)
To: Neil Horman; +Cc: Edward Hibbert, nfs
In-Reply-To: <20051111133036.GA3847@hmsendeavour.rdu.redhat.com>
On Fri, 2005-11-11 at 08:30 -0500, Neil Horman wrote:
> I don't believe rename ever guaranteed atomicity of its operation. If you want
> to guarantee atomicity I expect you will want to implement a locking strategy
> around the directories/files you are modifying in the rename operation using fcntl
> locking.
No. Edward is correct in that a POSIX filesystem is supposed to
guarantee atomicity (this is one reason why we have a dedicated rename()
instead of playing games like link(a,b); unlink(b);).
Unfortunately, as I said, there are issues in the VFS...
Cheers,
Trond
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* nf_conntrack: state or conntrack match with ipv6?
From: Deti Fliegl @ 2005-11-11 13:39 UTC (permalink / raw)
To: Netfilter Development Mailinglist
Hi there,
is there any state or conntrack match extension supported with
nf_conntrack on ipv6?
Deti
^ permalink raw reply
* Re: Rename window
From: Trond Myklebust @ 2005-11-11 13:38 UTC (permalink / raw)
To: Edward Hibbert; +Cc: nfs
In-Reply-To: <9E621559095AA746B22B21CD4FAF99A557356D@EDINMAIL1.ad.datcon.co.uk>
On Fri, 2005-11-11 at 11:42 +0000, Edward Hibbert wrote:
> I have noticed a atomicity problem with the handling of rename by the
> Linux NFS client, and just wanted to check if this is something that
> we just have to work-around, or is there some other solution.
>
> The problem arises when two different machines issue a file rename
> which is identical.
>
> E.g. rename oldname newname
>
> You would expect that one machine would be successful, and the other
> would fail. However, the NFS client seems to be issuing 3 NFS
> operations to perform the rename
> * LOOKUP oldname
> * LOOKUP newname
> * RENAME oldname newname
> There is a timing window where both LOOKUPs can succeed (if the other
> machine does the rename at the right time). In this case, the Linux
> NFS client does not issue the final NFS RENAME operation - BUT still
> returns success to the caller.
>
> Thus both machines have succeeded in renaming the file.
>
> You might argue that since they are performing the same operation that
> it is OK for both to succeed, but I have an application that depends
> on the atomicity of the operation, as it uses the filename to hold a
> counter, and rename to assign a unique counter to a process.
This is another of those cases where the VFS has optimised for local
filesystem behaviour, and where fixing this problem would require
significant VFS changes.
You'd basically have to add a new lookup intent for the RENAME function
in order to tell the NFS layer that it can ignore the lookup requests.
We probably will get round to doing that sometime, but it is not one of
the most pressing bugs on my list.
In the meantime, I'd suggest just not relying on this level of atomicity
(there are in any case situations where this is always impossible - for
instance in sillyrename() situations).
Cheers,
Trond
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Compilation Issue on RH9
From: Hai Wang @ 2005-11-11 13:38 UTC (permalink / raw)
To: netfilter
Hello everyone
I encountered a problem when I tried to compile iptables-1.3.4 on RH9 (
2.4.25), I got the following errors, please shed some lights on it.
Thanks!
Hai
ensions/libipt_time_sh.o -c extensions/libipt_time.c
extensions/libipt_time.c: In function `init':
extensions/libipt_time.c:66: structure has no member named `date_start'
extensions/libipt_time.c:67: structure has no member named `date_stop'
extensions/libipt_time.c: In function `parse':
extensions/libipt_time.c:394: structure has no member named `date_start'
extensions/libipt_time.c:407: structure has no member named `date_stop'
extensions/libipt_time.c: In function `print':
extensions/libipt_time.c:489: structure has no member named `date_start'
extensions/libipt_time.c:492: structure has no member named `date_start'
extensions/libipt_time.c:494: structure has no member named `date_stop'
extensions/libipt_time.c:497: structure has no member named `date_stop'
extensions/libipt_time.c: In function `save':
extensions/libipt_time.c:524: structure has no member named `date_start'
extensions/libipt_time.c:525: structure has no member named `date_stop'
make: *** [extensions/libipt_time_sh.o] Error 1
^ permalink raw reply
* [PATCH] DECnet fix SIGPIPE
From: Patrick Caulfield @ 2005-11-11 13:35 UTC (permalink / raw)
To: davem; +Cc: linux-kernel
This patch fixes SIGIPIPE for DECnet. Currently recvmsg generates SIGPIPE
whereas sendmsg does not; for the other stacks it seems to be the other way
round!
It also fixes the bug where reading from a socket whose peer has shutdown
returned -EINVAL rather than 0.
Signed-off-by: Patrick Caulfield <patrick@tykepenguin.com>
diff --git a/net/decnet/af_decnet.c b/net/decnet/af_decnet.c
--- a/net/decnet/af_decnet.c
+++ b/net/decnet/af_decnet.c
@@ -1664,17 +1664,15 @@ static int dn_recvmsg(struct kiocb *iocb
goto out;
}
- rv = dn_check_state(sk, NULL, 0, &timeo, flags);
- if (rv)
- goto out;
-
if (sk->sk_shutdown & RCV_SHUTDOWN) {
- if (!(flags & MSG_NOSIGNAL))
- send_sig(SIGPIPE, current, 0);
- rv = -EPIPE;
+ rv = 0;
goto out;
}
+ rv = dn_check_state(sk, NULL, 0, &timeo, flags);
+ if (rv)
+ goto out;
+
if (flags & ~(MSG_PEEK|MSG_OOB|MSG_WAITALL|MSG_DONTWAIT|MSG_NOSIGNAL)) {
rv = -EOPNOTSUPP;
goto out;
@@ -1928,6 +1926,8 @@ static int dn_sendmsg(struct kiocb *iocb
if (sk->sk_shutdown & SEND_SHUTDOWN) {
err = -EPIPE;
+ if (!(flags & MSG_NOSIGNAL))
+ send_sig(SIGPIPE, current, 0);
goto out_err;
}
^ permalink raw reply
* Compilation issue on RH9
From: Hai Wang @ 2005-11-11 13:33 UTC (permalink / raw)
To: netfilter
Hello everyone,
I encountered a problem when I tried to compile iptables-1.3.4 on RH9 (
2.4.25), I got the following errors, please shed some lights on it.
Thanks!
Hai
^ permalink raw reply
* Re: Buggy IDE / ATA drive on 2.6? DMA timeouts, 2.4 is fine
From: Bartlomiej Zolnierkiewicz @ 2005-11-11 13:33 UTC (permalink / raw)
To: Rahul Siddharthan; +Cc: linux-ide
In-Reply-To: <1131459964.4370b57cdfbc5@imp1-g19.free.fr>
On 11/8/05, Rahul Siddharthan <rsidd@online.fr> wrote:
> Bartlomiej Zolnierkiewicz said on Nov 8, 2005 at 14:17:13:
> > On 11/8/05, Rahul Siddharthan <rsidd@online.fr> wrote:
> > > I have a HP Pavilion ze5385us laptop bought in 2003, which has a
> > > ALi15X3 IDE controller and a Toshiba MK6021GAS ATA disk. For about
> > > two months, since an upgrade to kernel 2.6.10+, I'd been noticing
> > > occasional sluggishness with the laptop, and occasionally "DMA timeout"
> > > errors. But until a week ago they were rather rare, and never occurred
> > > with the other kernel/OS's I have on the machine: Linux 2.4.27, Windows XP,
> > > DragonFly BSD. The exact error is:
> > >
> > > hda: dma_timer_expiry: dma status == 0x21
> > > hda: DMA timeout error
> > > hda: dma timeout error: status=0xd0 (busy)
> > >
> > > ide: failed opcode was: unknown
> > > hda: DMA disabled
> > > ide0: reset: success
>
> [snip]
> > > Now I have been running the laptop on DragonFly and Linux 2.4 for about
> > > 3 hours each and there have been no problems whatever. I even successfully
> > > burned a CD in dummy mode and then in real mode.
> > >
> > > I have no clue what's going on but I am convinced that the 2.6 IDE driver is
> > > somehow bad for my laptop.
Does 2.4 kernel work reliably for you now?
If so please do more testing and find the latest kernel version
which works for you, otherwise it is very unlikely that somebody
will be able to help you as going from 2.4.27->2.6.10 means going
through insane amount of changes.
> > > Any ideas?
> >
> > http://smartmontools.sf.net
>
> OK, smartctl -a says
> SMART overall-health self-assessment test result: PASSED
> and reports 14 errors, the most recent 2 at 7287 hours, (303 days + 15
> hrs) so the DMA timeout errors aren't here. Do you need the full
> output?
Yes.
Bartlomiej
^ permalink raw reply
* Re: ip_conntrack_netlink & nf_conntrack
From: Pablo Neira @ 2005-11-11 13:33 UTC (permalink / raw)
To: Krzysztof Oledzki; +Cc: Netfilter Development Mailinglist
In-Reply-To: <Pine.LNX.4.64.0511111417130.7120@bizon.gios.gov.pl>
Krzysztof Oledzki wrote:
> Since we now have nf_conntrack included in 2.6.15 and
> ip_conntrack_netlink is a part of ip_conntrack, I'm wonder if there are
> any plans for porting ip_conntrack_netlink into nf_conntrack
> (nf_conntrack_netlink)?
Yes. I'll post a patch of such porting soon.
--
Pablo
^ permalink raw reply
* Re: Rename window
From: Neil Horman @ 2005-11-11 13:30 UTC (permalink / raw)
To: Edward Hibbert; +Cc: nfs
In-Reply-To: <9E621559095AA746B22B21CD4FAF99A557356D@EDINMAIL1.ad.datcon.co.uk>
On Fri, Nov 11, 2005 at 11:42:01AM -0000, Edward Hibbert wrote:
> I have noticed a atomicity problem with the handling of rename by the
> Linux NFS client, and just wanted to check if this is something that we
> just have to work-around, or is there some other solution.
>
> The problem arises when two different machines issue a file rename which
> is identical.
>
> E.g. rename oldname newname
>
> You would expect that one machine would be successful, and the other
> would fail. However, the NFS client seems to be issuing 3 NFS
> operations to perform the rename
>
> * LOOKUP oldname
> * LOOKUP newname
> * RENAME oldname newname
>
> There is a timing window where both LOOKUPs can succeed (if the other
> machine does the rename at the right time). In this case, the Linux
> NFS client does not issue the final NFS RENAME operation - BUT still
> returns success to the caller.
>
> Thus both machines have succeeded in renaming the file.
>
> You might argue that since they are performing the same operation that
> it is OK for both to succeed, but I have an application that depends on
> the atomicity of the operation, as it uses the filename to hold a
> counter, and rename to assign a unique counter to a process.
>
> Any help appreciated.
>
I don't believe rename ever guaranteed atomicity of its operation. If you want
to guarantee atomicity I expect you will want to implement a locking strategy
around the directories/files you are modifying in the rename operation using fcntl
locking.
Regards
Neil
> Edward.
>
>
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*nhorman@redhat.com
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [x86_64] 2.6.14-git13 mplayer fails with "v4l2: ioctl queue buffer failed: Bad address" (2 Nov 2005, 11 Nov 2005)
From: Junichi Uekawa @ 2005-11-11 13:29 UTC (permalink / raw)
To: Michael Krufky
Cc: Junichi Uekawa, linux-kernel, video4linux-list, debian-amd64
In-Reply-To: <87y83vl780.dancerj%dancer@netfort.gr.jp>
Hi,
> > One question -- At exactly what point does this break for you? The git
> > commit key above was from today, but at what point did this LAST work
> > for you? It would be really helpful if you can do a git bisection test,
> > so that we can isolate the trouble patch if in fact it is a regression.
>
> df70b17f88a4d1d8545d3569a1f6d28c6004f9e4 2 Nov 2005 Nonfunctional bttv
> d83c671fb7023f69a9582e622d01525054f23b66 1 Nov 2005 (fails to boot due to USB issues)
> 6e9d6b8ee4e0c37d3952256e6472c57490d6780d 27 Oct 2005 Functional bttv
That was wrong; I re-tested it and it looks like
6e9d6b8ee4e0c37d3952256e6472c57490d6780d was a bad one.
2.6.14 (741b2252a5e14d6c60a913c77a6099abe73a854a) is functional.
$ git-bisect start
$ git-bisect bad 6e9d6b8ee4e0c37d3952256e6472c57490d6780d
$ git-bisect good 741b2252a5e14d6c60a913c77a6099abe73a854a
Bisecting: 721 revisions left to test after this
regards,
junichi
^ permalink raw reply
* Re: 2.6.14-mm2
From: Reuben Farrelly @ 2005-11-11 13:28 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
In-Reply-To: <20051111005513.0dda25f3.akpm@osdl.org>
On 11/11/2005 9:55 p.m., Andrew Morton wrote:
> Reuben Farrelly <reuben-lkml@reub.net> wrote:
>> The 2.6.14 with your linus.patch works fine, so it looks like an -mm(1|2)
>> specific problem, which is common to both sky2 and e100 drivers (unlikely to
>> be e100 specific I guess).
>
> That's getting us closer.
>
> Would you be able to revert the git-netdev-all.patch changes in e100.c? To
> do that, take the drivers/net/e100.c from 2.6.14+linus.patch and simply
> overwrite the e100.c in 2.6.14-mm2 with it.
>
> Or, prepare a 2.6.14-mm2 tree and use
> http://www.zip.com.au/~akpm/linux/patches/stuff/e100.c, which amounts to
> the same thing.
>
> Thanks.
Unfortunately made no difference.
However I noticed that I had compiled 2.6.14-mm1+2 with a couple of different
and probably significant config options from rc5-mm1:
CONFIG_PREEMPT=y
CONFIG_DEBUG_PREEMPT=y
CONFIG_KALLSYMS_ALL=y
I reverted those changes and rebuilt -mm2, and it all seems OK now after 6x
reboots and about 18 or so times removal and reinsertion of the two modules.
The reason for this being on in the config was that PREEMPT and the debug for
it was turned on to find the sd.c oopsing problem I had in -mm1, but it was
obviously not turned off afterwards. I'm not sure it should have *needed* to
be turned off though?
Then to double check I put CONFIG_PREEMPT and CONFIG_DEBUG_PREEMPT back into
that same config via menuconfig the way it was originally, made mrproper and
rebuilt, and the network failed to come up at all (again) on boot on first
attempt. This is consistent with both network drivers and not just the e100
failing to function, I think, as either both drivers always work, or both
always fail.
So in summary -
2.6.14-rc5-mm1 (preempt): <didn't test>
2.6.14-rc5-mm1 (no preempt) : works
2.6.14 with linus.patch (preempt): works
2.6.14 with linus.patch (no preempt): works
2.6.14-mm1 (preempt): broken ***
2.6.14-mm1 (no preempt): <didn't test>
2.6.14-mm2 (preempt): broken ***
2.6.14-mm2 (no preempt): works
All tests done with multiple reboots.
-mm2 seems otherwise to be quite OK apart from this issue.
^ permalink raw reply
* Re: [PATCH] gianfar mii needs to zero out the mii_bus structure
From: Jeff Garzik @ 2005-11-11 13:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: netdev, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0511091211030.26349-100000@gate.crashing.org>
applied
^ permalink raw reply
* Re: [patch 1/7] s390: synthax checking for VIPA addresses fixed
From: Jeff Garzik @ 2005-11-11 13:26 UTC (permalink / raw)
To: Frank Pavlic; +Cc: netdev, linux-kernel
In-Reply-To: <20051110124902.GA7936@pavlic>
applied 1-7
^ permalink raw reply
* Re: geodefb issues, possible patch
From: David Vrabel @ 2005-11-11 13:25 UTC (permalink / raw)
To: linux-fbdev-devel
In-Reply-To: <eb77d7060511110405i13b8bc8aw335147185398cd22@mail.gmail.com>
Jorge Luis Zapata Muga wrote:
>
> i am having problems with the geode fb driver in 2.6 kernels. it seems
> that it cant ioremap the video registers. ive debug a little bit of
> code and compared it to the
> previous kernel tree (2.4) geode fb driver amd (i think) provided. the
> old driver works perfectly on my SBP.
What CPU and companion chip is on this board? The current 2.6 driver
only supports the Geode GX1 with CS5530A.
What kernel version are you using?
> ok here are the things i found:
> * when requesting the pci regions all the pci_resource_start,
> pci_resource_len return 0's
Can you send the output of 'lspci -vvv -x' for the companion chip video
device?
> * the hardcoded offsets for mapping are different from what i found in
> the other driver, ive changed them to the older values. (to map the
> video reg, display controller reg, and the fb memory)
Er. I doubt this is the correct thing to do since the driver matches the
GX1 data sheet.
> * the display controller functions to blank the screen, configure
> display, set clock freq, etc used the vid_regs for writel readl
> instead (as seen in the other driver) of the dc_vid (display
> controller registers).
I don't follow you here. The display controller has nothing to do with
the DCLK frequency nor blanking the screen -- that's purely a function
of the video device in the companion chip.
> i have a patch if someone is interested. the problem is that i dont
> know what else to do, as i cant debug (with printf's) the driver as i
> dont have a screen, how does a fb driver gets debugged?
I use a serial console.
> does this driver actually works?
It works on the board I have.
> maybe i have an issue with the pci detection?
It's possible that the BIOS not correctly initializing all PCI devices
correctly. I don't really know a whole lot about PCI on x86 platforms,
though.
David Vrabel
ps. I'd suggest ignoring the old 2.4 driver for the most part since it's
crap and very hard to follow -- refer to the datasheets instead.
--
David Vrabel, Design Engineer
Arcom, Clifton Road Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK Web: http://www.arcom.com/
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
^ 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.