* Bug: sunrpc
From: Vincent ROQUETA @ 2004-01-28 8:56 UTC (permalink / raw)
To: nfs
kernel : 2.6.1
patch :
http://www.citi.umich.edu/projects/nfsv4/linux/kernel-patches/kernel-patches-2.6.1-1/linux-2.6.1-CITI_NFS4_ALL.patch
-> Compilation: really hard to compil, many problems with ACL
kernel config:
# Network File Systems
#
# CONFIG_NFS_FS is not set
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_V4_ACL=y
CONFIG_EXPORTFS=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=m
CONFIG_RPCSEC_GSS_KRB5=m
(I can't compil if SUNRPC_GSS and RPCSEC_GSS_KRB5 are buit-in)
modprobe:
modprobe auth_rpcgss OK
modprobe rpcsec_gss_krb5 OK
mount --bind /home/tests /export/tests OK
exportfs -i -ofsid=0 *:/export -> bug
Jan 27 20:40:01 fastreboot kernel: kmem_cache_create: duplicate cache
rpc_inode_cache
Jan 27 20:40:01 fastreboot kernel: ------------[ cut here ]------------
Jan 27 20:40:01 fastreboot kernel: kernel BUG at mm/slab.c:1269!
Jan 27 20:40:01 fastreboot kernel: invalid operand: 0000 [#1]
Jan 27 20:40:01 fastreboot kernel: CPU: 0
Jan 27 20:40:01 fastreboot kernel: EIP: 0060:[<c0141b77>] Not tainted
Jan 27 20:40:01 fastreboot kernel: EFLAGS: 00010202
Jan 27 20:40:01 fastreboot kernel: EIP is at kmem_cache_create+0x447/0x530
Jan 27 20:40:01 fastreboot kernel: eax: 00000033 ebx: f7df0878 ecx:
c043a96c edx: c0371bdc
Jan 27 20:40:01 fastreboot kernel: esi: c0357b21 edi: f89ba988 ebp:
f7df0614 esp: f7257f4c
Jan 27 20:40:01 fastreboot kernel: ds: 007b es: 007b ss: 0068
Jan 27 20:40:01 fastreboot kernel: Process modprobe (pid: 933,
threadinfo=f7256000 task=f7318710)
Jan 27 20:40:01 fastreboot kernel: Stack: c032d300 f89ba978 00022000 f7257f68
f7df0654 c0000000 ffffffe0 000000c0
Jan 27 20:40:01 fastreboot kernel: c03731b0 c0373194 f89c9240 f7256000
f89b9417 f89ba978 000001e0 00000020
Jan 27 20:40:01 fastreboot kernel: 00022000 f89b9300 00000000 f890e00c
c0373194 c03731b0 c0138467 c043a884
Jan 27 20:40:01 fastreboot kernel: Call Trace:
Jan 27 20:40:01 fastreboot kernel: [<f89b9417>] register_rpc_pipefs+0x37/0x60
[sunrpc]
Jan 27 20:40:01 fastreboot kernel: [<f89b9300>] init_once+0x0/0xe0 [sunrpc]
Jan 27 20:40:01 fastreboot kernel: [<f890e00c>] init_sunrpc+0xc/0x54 [sunrpc]
Jan 27 20:40:01 fastreboot kernel: [<c0138467>] sys_init_module+0x127/0x230
Jan 27 20:40:01 fastreboot kernel: [<c010922d>] sysenter_past_esp+0x52/0x71
Jan 27 20:40:01 fastreboot kernel:
Jan 27 20:40:01 fastreboot kernel: Code: 0f 0b f5 04 df ca 32 c0 8b 0b e9 74
ff ff ff 8b 47 38 c7 04
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [PATCH]Re: NAT before IPsec with 2.6
From: Patrick McHardy @ 2004-01-28 8:49 UTC (permalink / raw)
To: Harald Welte
Cc: Henrik Nordstrom, Willy Tarreau, Tom Eastep, Michal Ludvig,
netfilter-devel
In-Reply-To: <20040128000938.GH11761@sunbeam.de.gnumonks.org>
Harald Welte wrote:
>Hi!
>
>[please ignore the last message, I mistakenly sent an outdated, incomplete
> patch]
>
>I've now hacked a preliminary patch. Be warned, I didn't even test if
>it compiles. Maybe someone who actually has a running 2.6.x ipsec setup
>can give it a try.
>
>What it should be doing
>- traverse the additional chains as described in the last email
>- have connection tracking recognize two seperate connections, one
> for the decapsulated traffic, one for the encapsulated
>- thus, even SNAT/DNAT should be working.
>- locally-encapsulated traffic shows up with input device "ah4" or
> "esp4" in POSTROUTING.
>- locally-encapsulated traffic shows up with output device "ah4" or
> "esp4" in OUTPUT.
>
>What is missing (TODO):
>- no dummy device names in INPUT/PREROUTING for locally-decapsulated
> packets. This is somewhat harder
>- no real output device shown in OUTPUT for locally-encapsulated
> packets. I'm not sure if it is legal to typecast the just-popped
> dst_entry to 'struct rtable' and derive the output interface from
> there.
>
>Please give feedback.
>
>
I see two problems with this approach. The dummy devices don't have
any ip config, so f.e. REDIRECT will fail. The bigger problem is
hooking in output routines that return NET_XMIT_BYPASS. dst_output
loops until the return code of skb->dst->output != NET_XMIT_BYPASS.
These output routines replace skb->dst when finished by calling dst_pop.
If we pass the packet through netfilter in between, the dst_entry
might get replaced in ip_route_me_harder or elsewhere and not all
transformations will be applied. If NAT is used,
ip_route_{input,output} might even return a different policy bundle.
Anyways, I'm testing it (slightly hacked) as soon as the compile finishes ;)
Regards,
Patrick
^ permalink raw reply
* InterScan NT Alert
From: postmaster-lX1WLSqV685oZSuCWFJQuMGzyFzmqZ/k @ 2004-01-28 8:48 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Sender, InterScan has detected virus(es) in your e-mail attachment.
Date: Wed, 28 Jan 2004 14:18:45 +0530
Method: Mail
From: <acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
To: <mec-WqBc5aa1uDFeoWH0uzbU5w@public.gmane.org>
File: doc.scr
Action: clean failed - deleted
Virus: WORM_MIMAIL.R
begin 666 InterScan_Disclaimer.txt
M5&AE(&EN9F]R;6%T:6]N(&-O;G1A:6YE9"!I;B!T:&ES(&5L96-T<F]N:6,@
M;65S<V%G92!A;F0-0q2iP0p74hk@public.gmane.org(&%T=&%C:&UE;G1S('1O('1H:7,@;65S<V%G92!A
M<F4@#0II;G1E;F1E9"!F;W(@=&AE(&5X8VQU<VEV92!U<V4@;V8@=&AE(&%D
M9')E<W-E92AS*2!A;F0@;6%Y(&-O;G1A:6X-2ZHtrH1AIUU@public.gmane.org]N9FED96YT:6%L(&]R('!R
M:79I;&5G960@:6YF;W)M871I;VXN#0I)9B!Y;W4-4u3rHeVEGOc@public.gmane.org)E(&YO="!T:&4@:6YT
M96YD960@<F5C:7!I96YT+"!P;&5A<V4@;F]T:69Y('1H92!S96YD97(@870@
M4V%M<W5N9R!%;&5C=')O($UE8VAA;FEC<R!O<@T*861M:6Y <V5M<V]F=&EN
M9&EA+7-A;7-U;F<N8V]M(&EM;65D:6%T96QY(&%N9"!D97-T<F]Y(&%L;"!C
M;W!I97,@;V8@=&AI<R!M97-S86=E(&%N9"!A;GD-Yg1PUgpZdv8@public.gmane.org;65N=',N#0I!
M;GD@=6YA=71H;W)I>F5D(')E=FEE=RP@=7-E+"!D:7-C;&]S=7)E+"!D:7-S
M96UI;F%T:6]N+"!F;W)W87)D:6YG+"!P<FEN=&EN9R!O<B!C;W!Y:6YG(&]F
M('1H:7,@96UA:6P@;W(@86YY#0IA8W1I;VX@=&%K96X@:6X@<F5L:6%N8V4@
M;VX@=&AI<R!E+6UA:6P@:7,@<W1R:6-T;'D@<')O:&EB:71E9"!A;F0@;6%Y
5(&)E('5N;&%W9G5L+-wPuJ0ROkVbw@public.gmane.org*#0H-"@T*
end
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* BANNED FILENAME (document.zip) IN YOUR MAIL
From: amavisd-new @ 2004-01-28 8:40 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20040128084042.F1954244151-KM3ALrBo/q9J7q7XAxDqxw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]
BANNED FILENAME ALERT
Our virus checker found
banned filename: document.zip
in your email to the following recipient:
-> james-bnD7R/pdkU1Nctl32NmFlg@public.gmane.org
Delivery of the email was stopped!
Please check your system for viruses,
or ask your system administrator to do so.
For your reference, here are headers from your email:
------------------------- BEGIN HEADERS -----------------------------
Received: from lists.sourceforge.net (unknown [218.232.70.120])
by pluto.emse.fr (Postfix) with ESMTP id F1954244151
for <james-bnD7R/pdkU1Nctl32NmFlg@public.gmane.org>; Wed, 28 Jan 2004 09:40:42 +0100 (CET)
From: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
To: james-bnD7R/pdkU1Nctl32NmFlg@public.gmane.org
Subject: hello
Date: Wed, 28 Jan 2004 17:41:27 +0900
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0004_5DA393AD.D62921CE"
X-Priority: 3
X-MSMail-Priority: Normal
Message-Id: <20040128084042.F1954244151-KM3ALrBo/q9J7q7XAxDqxw@public.gmane.org>
-------------------------- END HEADERS ------------------------------
[-- Attachment #2: Delivery error report --]
[-- Type: message/delivery-status, Size: 391 bytes --]
[-- Attachment #3: Undelivered-message headers --]
[-- Type: text/rfc822-headers, Size: 604 bytes --]
Received: from lists.sourceforge.net (unknown [218.232.70.120])
by pluto.emse.fr (Postfix) with ESMTP id F1954244151
for <james-bnD7R/pdkU1Nctl32NmFlg@public.gmane.org>; Wed, 28 Jan 2004 09:40:42 +0100 (CET)
From: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
To: james-bnD7R/pdkU1Nctl32NmFlg@public.gmane.org
Subject: hello
Date: Wed, 28 Jan 2004 17:41:27 +0900
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0004_5DA393AD.D62921CE"
X-Priority: 3
X-MSMail-Priority: Normal
Message-Id: <20040128084042.F1954244151-KM3ALrBo/q9J7q7XAxDqxw@public.gmane.org>
^ permalink raw reply
* Re: I still love you LUbza
From: m0sia @ 2004-01-28 8:35 UTC (permalink / raw)
To: XkXmXLXFXcX; +Cc: Linux-kernel
In-Reply-To: <ECF7EF98H42LECBG@debianplanet.org>
On Wed, 28 Jan 2004 01:29:54 +0000
XkXmXLXFXcX@debianplanet.org wrote:
> Error 551: We are sorry your UTF-8 encoding is not supported by the server, so the text was automatically zipped and attached to this message.
w32.doom virus!!! i hate it!!
^ permalink raw reply
* Re: 2.6.2-rc2-mm1
From: Han Boetes @ 2004-01-28 8:36 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20040127233402.6f5d3497.akpm@osdl.org>
Hmmm my build breaks with:
LD .tmp_vmlinux1
arch/i386/kernel/built-in.o(.init.text+0x1342): In function `setup_memory':
: undefined reference to `find_smp_config'
arch/i386/kernel/built-in.o(.entry.text+0xb11): In function `vic_sys_interrupt':
: undefined reference to `smp_vic_sys_interrupt'
arch/i386/kernel/built-in.o(.entry.text+0xb35): In function `vic_cmn_interrupt':
: undefined reference to `smp_vic_cmn_interrupt'
arch/i386/kernel/built-in.o(.entry.text+0xb59): In function `vic_cpi_interrupt':
: undefined reference to `smp_vic_cpi_interrupt'
arch/i386/kernel/built-in.o(.entry.text+0xb7d): In function `qic_timer_interrupt':
: undefined reference to `smp_qic_timer_interrupt'
arch/i386/kernel/built-in.o(.entry.text+0xba1): In function `qic_invalidate_interrupt':
: undefined reference to `smp_qic_invalidate_interrupt'
arch/i386/kernel/built-in.o(.entry.text+0xbc5): In function `qic_reschedule_interrupt':
: undefined reference to `smp_qic_reschedule_interrupt'
arch/i386/kernel/built-in.o(.entry.text+0xbe9): In function `qic_enable_irq_interrupt':
: undefined reference to `smp_qic_enable_irq_interrupt'
arch/i386/kernel/built-in.o(.entry.text+0xc0d): In function `qic_call_function_interrupt':
: undefined reference to `smp_qic_call_function_interrupt'
arch/i386/mach-voyager/built-in.o(.text+0x1bd): In function `voyager_power_off':
: undefined reference to `voyager_cat_power_off'
arch/i386/mach-voyager/built-in.o(.text+0x3e6): In function `check_from_kernel':
: undefined reference to `voyager_status'
arch/i386/mach-voyager/built-in.o(.text+0x425): In function `check_continuing_condition':
: undefined reference to `voyager_status'
arch/i386/mach-voyager/built-in.o(.text+0x448): In function `check_continuing_condition':
: undefined reference to `voyager_cat_psi'
arch/i386/mach-voyager/built-in.o(.text+0x523): In function `thread':
: undefined reference to `voyager_status'
arch/i386/mach-voyager/built-in.o(.text+0x56b): In function `thread':
: undefined reference to `voyager_status'
# Han
^ permalink raw reply
* Re: subject-prefixing of ml postings (was Re: A humble request)
From: Harald Welte @ 2004-01-28 8:31 UTC (permalink / raw)
To: Kiran Kumar; +Cc: Zeeshan Ali, netfilter-devel
In-Reply-To: <20040128045409.9799.qmail@web14007.mail.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 1152 bytes --]
On Tue, Jan 27, 2004 at 08:54:09PM -0800, Kiran Kumar wrote:
> --- Kiran Kumar <immidi_kiran@yahoo.com> wrote:
>
> > I have built up some content based on the rules of
> > another list that I am on (most of which are, I
> > guess,
> > relevant here as well). The patch for the homepage
> > module of cvs is attached.
>
> Sorry, seems the previous one had a problem..
> resending it.
thanks a lot, I've committed your change to CVS and will update the
homepage shortly.
Have you been progressing with some of the other proposed work (either
homepage-related, or netfilter-related), or are you waiting for me
making a concrete assignment?
I really don't want to lose your offer for help just because of some
misunderstanding.
> Kiran Kumar Immidi
--
- Harald Welte <laforge@netfilter.org> http://www.netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Problem with i2c-algo-ibm_ocp driver on ppc405 board
From: Matteo Bortolin @ 2004-01-28 8:25 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: llandre
Hi all,
I've developed an RTC driver that uses i2c core and for a PPC405-based
board (PPChameleonEVB).
The i2c-Algorithm driver is the i2c-algo-ibm_ocp.c and the i2c-adapter is
the i2c-adap-ibm_ocp.c
The problem is in timer_interrupt() function (/arch/ppc/kernel/time.c) with
CONFIG_RTC_11_MINUTE_MODE enabled.
Into this function there is a call to a ppc_md.set_rtc_time that is a
pointer to a my set_rtc_device function that in turn
calls the i2c_master_send().
The problem is that kernel crashes (kenrel panic) when ppc_md.set_rtc_time
is called.
Debugging the coed, I've seen that kernel crashes into iic_sendbytes()
function (i2c-algo-ibm_opc.c) .
After debugging inside of iic_sendbytes() function I asked to me:
As in the time_interrupt() function, interrupt are disabled,
i2c-algo-ibm_ocp.c cannot work properly.
This would mean that a kernel that use i2c-algo-ibm_ocp.c and a i2c
RTC-driver cannot work properly
with CONFIG_RTC_11_MINUTE_MODE!!!
Is this correct?
If yes, how can I solve my problem?
Matteo Bortolin
DAVE Srl
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [LARTC] IMQ Stability
From: Alexander Trotsai @ 2004-01-28 8:25 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-105066408632475@msgid-missing>
On Fri, Jan 23, 2004 at 10:29:13AM -0700, Michael S. Kazmier wrote:
MSK>Hello all,
MSK>I have been doing a lot of archive searching over the last week reading
MSK>posts on IMQ and it's apparent stability / instability. I have seen a
MSK>number of posts about it not being maintained as well. Can anyone talk to
MSK>me about IMQ's stability in a heavy throughput environment (20 Mbps) and
MSK>what was causing IMQ to fail if you know.
I use it and it's work OK for me
Traffic at some router up to 30-40 Mbit
IMQ has one trouble
Don't assing address to imq interface becase kernel crash it
you do this.
--
Best regard, Aleksander Trotsai aka MAGE-RIPE aka MAGE-UANIC
My PGP key at ftp://blackhole.adamant.ua/pgp/trotsai.key[.asc]
Big trouble - ..disk or the processor is on fire.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: Patchomatic Snapshot Packages
From: Harald Welte @ 2004-01-28 8:20 UTC (permalink / raw)
To: Jim Gifford; +Cc: Netfilter Mailinglist, Netfilter Development Mailinglist
In-Reply-To: <004c01c3e56b$58dc7490$db00a8c0@W2RZ8L4S02>
[-- Attachment #1: Type: text/plain, Size: 823 bytes --]
On Tue, Jan 27, 2004 at 10:52:50PM -0800, Jim Gifford wrote:
> I just noticed since Jan 11th, there have not been any snapshots of
> patch-o-matic. Is this being discontinued??
no, there seems to be a problem with the script generating them. I
definitely updated that script when I reorganized the layout of the CVS
tree, but there still seems to be a problem with it.
thank you for letting us know.
I'll investigate.
> Jim Gifford
--
- Harald Welte <laforge@netfilter.org> http://www.netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Good logfileviewer or analyser?
From: Eric Leblond @ 2004-01-28 8:19 UTC (permalink / raw)
To: Nicole Haehnel; +Cc: netfilter
In-Reply-To: <40176ED9.4040607@epost.de>
[-- Attachment #1: Type: text/plain, Size: 331 bytes --]
Le mer 28/01/2004 à 09:12, Nicole Haehnel a écrit :
> Hi,
>
> I'm searching a logfileviewer or analyser for iptables
> to view the output on a web server.
You can use ulog and see logs with ulog-php :
http://home.regit.org/ulogd-php.html
BR,
--
Eric Leblond
Nufw, Now User Filtering Works (http://www.nufw.org)
[-- Attachment #2: Ceci est une partie de message numériquement signée. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* ALSA noise (was: Re: 2.6.2-rc2-mm1)
From: Joshua Kwan @ 2004-01-28 8:18 UTC (permalink / raw)
To: linux-kernel, linux-mm
In-Reply-To: <20040127233402.6f5d3497.akpm@osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]
On Tue, Jan 27, 2004 at 11:34:02PM -0800, Andrew Morton wrote:
> - Various fixes. Nothing stands out.
This doesn't have quite as much to do with -mm as it probably should,
but this high pitched noise + random static on ALSA playback happens
on all of my machines that use intel8x0 PAST 2.6.1-rc1-mm2. (That is,
2.6.1-rc2 stock has the bug, onwards until this release 2.6.2-rc2-mm1.)
As I've repeated a few times on a few threads on LKML, this involves:
1) a high pitched whining type noise when the system is *NOT* under load
which goes away if the CPU usage is at ~100%.
2) lots of annoying pops of static during wave playback (hurts my ears.)
I'm not so bold as to try to figure what changed between 2.6.1-rc1-mm2
and 2.6.1-rc2 stock that could have caused this. Can anyone offer
pointers on how to tackle this bug? I don't wish to be stuck with such
an old kernel in the heat of 2.6 stable release development :)
Hoping for a quick resolution for this bug. Other people have noticed it
as well...
--
Joshua Kwan
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Re: [Bluez-devel] Windows Port
From: Antony C. Roberts @ 2004-01-28 8:18 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Peter Kjellerstedt, BlueZ Mailing List
In-Reply-To: <1075277296.12766.63.camel@pegasus>
Marcel Holtmann wrote:
>Hi Antony,
>
>
>
>>I have no problem with GPL in the RFCOMM and L2CAP bits. My aim is to
>>have a sub-system (set of services) which are accessible from an API.
>>The RFCOMM and L2CAP bits can remain GPL no problem. The driver would be
>>open-source (but not GPL) as would the API itself and any user mode apps.
>>
>>
>
>be very careful with putting your code not under GPL. You should read
>what the FSF says about derived work etc. Actually this would be another
>reason for me to start from scratch.
>
>Regards
>
>Marcel
>
>
>
>
Thanks for the warning. The stuff I want to port will be isolated in the
services provided and all the code in this application will, as
required, still be GPL. However, the parts which interface to these
services (the hardware driver and the API) would be a modified GPL that
does not require the entire program to be made public but only the
original source code and any modifications made to it.
Regards,
Antony C. Roberts.
^ permalink raw reply
* Re: cs46xx capture dropout on busy systems
From: Jaroslav Kysela @ 2004-01-28 8:16 UTC (permalink / raw)
To: Perry Scott; +Cc: alsa-devel
In-Reply-To: <5.2.1.1.0.20040127224801.00a8b6b0@pop3.fone.net>
On Tue, 27 Jan 2004, Perry Scott wrote:
> [2.4.23]
>
> I've been chasing a capture dropout in the old OSS cs46xx driver
> (drivers/sound/cs46xx.c) for the past two months (evenings and weekends),
> and I finally nailed it. I looked over at the ALSA driver, and I think I
> see the same problem there as well. I traced the peek/poke(PD1_CBA) from
> the update_ptr routine to the read routine, so I'm pretty confident the bug
> is there.
>
> Briefly, I'm doing 8-channel recording, using 4 TB Santa Cruz
> cards. Occasionally, one of the cards loses a chunk of data. I traced the
> problem to the 4k dma buffer size. The IRQ updates the capture pointer,
> but it only has a 1/44th second real-time latency before it loses data. If
> the read doesn't get reposted by the application within that time, data
> will be lost. All it really takes is a busy system - either an IRQ from
> another card, or another thread getting in the way.
>
> I fixed the problem in the OSS driver by copying the 4k ping-pong into a
> larger buffer, which is then drained by read(). Essentially, I implemented
> the Scatter/Gather in the ISR. It's not pretty, but it
> works. (Incidentally, if anyone has found the Cirrus documentation on
> cs46xx capture S/G, I'd be most appreciative. The only document I found in
> the ALSA documentation archive glibly said that S/G is "complicated" and
> that 1/44th second should be OK - yeah, right.)
>
> This problem is likely to affect *any* sound card with a 4k dma
> ping-pong. I'm not sure if the cs46xx is the only pathological case out
> there, but I wouldn't be surprised if there are others. The really
> disturbing thought is that ALSA itself has real-time issues because 4k is a
> common dma size (say it isn't so!)
>
> I'm a couple weeks away from porting my application to ALSA, so if someone
> else wants to load up a bunch of sound cards, feel free. I'm finding the
> bug injecting a sine wave into the four cards, then looking for large
> deltas from one sample to the next.
>
> Comments?
Yes, we effectively use large buffer as well. Look to indirect_pointer()
routines - we copy data from the 4k DMA buffer here. So you can have for
example 128k buffer. Of course, the 4k (resp. 2k limit for one chunk) is
limit only for interrupt latency, but if your system is well tuned, it
should be ok. In other words, we do things in same way as you use in the
OSS code.
Note that the most of soundcards have at least 64k DMA buffer for samples.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: Root Drive Mirroring and LVM.
From: Sven Luther @ 2004-01-28 8:15 UTC (permalink / raw)
To: Neil Brown; +Cc: Atro.Tossavainen, linuxppc-dev, linux-raid, tas
In-Reply-To: <16407.4986.950905.135422@notabene.cse.unsw.edu.au>
On Wed, Jan 28, 2004 at 12:42:18PM +1100, Neil Brown wrote:
>
> On Tuesday January 27, atossava@cc.helsinki.fi wrote:
> > Sorry about the crossposting.
> >
> > I wrote on the Yellow Dog Linux list when somebody asked about software
> > RAID on YDL about my experiences with it:
> >
> > >> The one really big gotcha is that the Macintosh partitioning scheme
> > >> can't tell the Linux kernel that certain partitions are to be
> > >> considered "Linux RAID autodetect" (as in x86 using the DOS partition
> > >> table type 0xfd). This means that you can't boot a Mac Linux system
> > >> directly from RAID because the kernel won't be able to autostart the
> > >> RAID devices. You have to work around this by creating an initial RAM
> > >> disk that uses the raidstart command to start your metadevices, then
> > >> swaps the initrd out of the way and proceeds to start the real system.
> >
>
> This is not entirely true. Certainly an initial-ram-disk is one
> solution and is (I think) the preferred long-term solution. However
> you can also boot from raid with kernel-parameters like:
>
> md=0,/dev/hda1,/dev/hdc1 boot=/dev/md0
>
> where '0' indicated which md device (md0 in this case), and the
> remaining words are the devices to assemble it from.
This is said to be broken on latest 2.4.x kernels though. Didn't try
myself though, since i only have a single drive, and don't really want
to mess up with it.
> > to which Tim Seufert replied on the same list:
> >
> > > Hmmm. That would seem to be a lack in the Linux RAID code, since the
> > > Macintosh partition table has a vastly more flexible partition type
> > > field than DOS: instead of a single byte it's a string. It would mean
> > > breaking from the convention of using the "Apple_SVR2_UNIX" type for
> > > Linux partitions, but that really is just a convention as far as I know.
> >
> > Perhaps the PPC Linux developers and the Linux RAID developers should
> > get together on this and make some decisions so as to make it happen.
> >
>
> I personally think auto-detect is the wrong approach and have no
> desire to extend it to other partition types (I cannot remove it from
> DOS partitions as that breaks back-compatability).
> Just use "md=..."
Ok.
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Root Drive Mirroring and LVM.
From: Sven Luther @ 2004-01-28 8:15 UTC (permalink / raw)
To: Neil Brown; +Cc: Atro.Tossavainen, linuxppc-dev, linux-raid, tas
In-Reply-To: <16407.4986.950905.135422@notabene.cse.unsw.edu.au>
On Wed, Jan 28, 2004 at 12:42:18PM +1100, Neil Brown wrote:
>
> On Tuesday January 27, atossava@cc.helsinki.fi wrote:
> > Sorry about the crossposting.
> >
> > I wrote on the Yellow Dog Linux list when somebody asked about software
> > RAID on YDL about my experiences with it:
> >
> > >> The one really big gotcha is that the Macintosh partitioning scheme
> > >> can't tell the Linux kernel that certain partitions are to be
> > >> considered "Linux RAID autodetect" (as in x86 using the DOS partition
> > >> table type 0xfd). This means that you can't boot a Mac Linux system
> > >> directly from RAID because the kernel won't be able to autostart the
> > >> RAID devices. You have to work around this by creating an initial RAM
> > >> disk that uses the raidstart command to start your metadevices, then
> > >> swaps the initrd out of the way and proceeds to start the real system.
> >
>
> This is not entirely true. Certainly an initial-ram-disk is one
> solution and is (I think) the preferred long-term solution. However
> you can also boot from raid with kernel-parameters like:
>
> md=0,/dev/hda1,/dev/hdc1 boot=/dev/md0
>
> where '0' indicated which md device (md0 in this case), and the
> remaining words are the devices to assemble it from.
This is said to be broken on latest 2.4.x kernels though. Didn't try
myself though, since i only have a single drive, and don't really want
to mess up with it.
> > to which Tim Seufert replied on the same list:
> >
> > > Hmmm. That would seem to be a lack in the Linux RAID code, since the
> > > Macintosh partition table has a vastly more flexible partition type
> > > field than DOS: instead of a single byte it's a string. It would mean
> > > breaking from the convention of using the "Apple_SVR2_UNIX" type for
> > > Linux partitions, but that really is just a convention as far as I know.
> >
> > Perhaps the PPC Linux developers and the Linux RAID developers should
> > get together on this and make some decisions so as to make it happen.
> >
>
> I personally think auto-detect is the wrong approach and have no
> desire to extend it to other partition types (I cannot remove it from
> DOS partitions as that breaks back-compatability).
> Just use "md=..."
Ok.
Friendly,
Sven Luther
^ permalink raw reply
* Re: anti-dos
From: Ray Leach @ 2004-01-28 8:14 UTC (permalink / raw)
To: Netfilter Mailing List (E-mail)
In-Reply-To: <F22386C3FEB012449238672E38ED61E71642B1@overlord.overturemedia.com>
[-- Attachment #1: Type: text/plain, Size: 2208 bytes --]
On Wed, 2004-01-28 at 09:18, Fritz Mesedilla wrote:
> in preparation to sco's feb 1. dos attack, is there any special iptables rules that i can use to avoid dos attacks?
> all i have right now is i blocked all ports then opened the mail and internet.
>
> what else can i do for rules?
>
You can use the limit support to limit packet rates:
### syn-flood chain
$IPTABLES -N syn-flood
$IPTABLES -A syn-flood -i $IFACE_INET -m limit --limit 75/s
--limit-burst 100 -j RETURN
$IPTABLES -A syn-flood -i $IFACE_DMZ -m limit --limit 75/s --limit-burst
100 -j RETURN
$IPTABLES -A syn-flood -i $IFACE_INT -j RETURN
$IPTABLES -A syn-flood -j LOG --log-prefix "SYN-FLOOD: "
$IPTABLES -A syn-flood -j DROP
$IPTABLES -A INPUT -i $IFACE_INT -p tcp --syn -j syn-flood
$IPTABLES -A INPUT -i $IFACE_DMZ -p tcp --syn -j syn-flood
$IPTABLES -A INPUT -i $IFACE_INET -p tcp --syn -j syn-flood
> thanks.
>
>
> Cheers,
>
> fritz <www.mesedilla.com>
> ---
> + Basta Ikaw Lord
>
>
>
>
> ----------------------------------------------------------------------
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the sender immediately by e-mail and delete this e-mail from your
> system. Please note that any views or opinions presented in this
> email are solely those of the author and do not necessarily represent
> those of the company. Finally, the recipient should check this email
> and any attachments for the presence of viruses. The company accepts
> no liability for any damage caused by any virus transmitted by this
> email.
>
> Overture Media, Inc.
> Direct Line: (632) 635-4785
> Trunkline: (632) 631-8971 Local 146
> Fax: (632) 637-2206
> Level 1 Summit Media Offices, Robinsons Galleria EDSA Cor. Ortigas Ave., Quezon City 1100
--
--
Raymond Leach <raymondl@knowledgefactory.co.za>
Network Support Specialist
http://www.knowledgefactory.co.za
"lynx -source http://www.rchq.co.za/raymondl.asc | gpg --import"
Key fingerprint = 7209 A695 9EE0 E971 A9AD 00EE 8757 EE47 F06F FB28
--
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Good logfileviewer or analyser?
From: Nicole Haehnel @ 2004-01-28 8:12 UTC (permalink / raw)
To: netfilter
Hi,
I'm searching a logfileviewer or analyser for iptables
to view the output on a web server.
Does anybody knows a good script, tool or something else?
Thanks!
Nicole
^ permalink raw reply
* Re: [Bluez-devel] Windows Port
From: Marcel Holtmann @ 2004-01-28 8:08 UTC (permalink / raw)
To: Antony C. Roberts; +Cc: Peter Kjellerstedt, BlueZ Mailing List
In-Reply-To: <40176BC2.9020307@acroberts.com>
Hi Antony,
> I have no problem with GPL in the RFCOMM and L2CAP bits. My aim is to
> have a sub-system (set of services) which are accessible from an API.
> The RFCOMM and L2CAP bits can remain GPL no problem. The driver would be
> open-source (but not GPL) as would the API itself and any user mode apps.
be very careful with putting your code not under GPL. You should read
what the FSF says about derived work etc. Actually this would be another
reason for me to start from scratch.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply
* Re: NetBSD port and a couple of remarks
From: Ian Pratt @ 2004-01-28 8:07 UTC (permalink / raw)
To: Christian Limpach; +Cc: xen-devel, Ian.Pratt
In-Reply-To: <1075237191.4016d147c2019@lola.Pin.LU>
> I have made a NetBSD-current kernel which boots on Xen. It still has some
> problems but it's good enough to boot multi-user and allows logins.
Good job! It's really good to hear that another OS is up and
running on Xen.
Out of interest, how many man hours do you think it took you? I'm
very impressed you managed to figure the Xen i/f out on your own
without any help from Keir and the rest of us.
> While working on this, I noticed a few problems and I'm wondering if these
> are corrected in Xen versions >1.1:
There's been a few fixes and improvements for the hypervisor i/f
in the 1.2 tree, but I don't think it will take long to forward
port NetBSD.
We'll investigate your specific bug reports.
> I hope to commit this to the NetBSD tree eventually. Or I'll make patches
> available after some cleaning up.
Great! We'd be very pleased to put the patches in the xen
distribution in the meantime, as soon as you're ready.
> Finally, if someone could get me a xen-1.2 and/or xen-unstable tree out of
> bitkeeper, that would be much appreciated.
There's a pretty recent src/binary tar ball in:
www.cl.cam.ac.uk/netos/xen/downloads/xeno-1.2.tar.gz
It's still in the form of a BK repository, but all of the files
are checked out.
BTW: I offered to buy dinner for anyone that did an OS port. I
hope you'll take me up on that offer...
Best,
Ian
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: SMP AMD64 (Tyan S2882) problems.
From: Martin Polak @ 2004-01-28 8:02 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel
In-Reply-To: <p73fze1fdk4.fsf@nielsen.suse.de>
Andi Kleen wrote:
> Jan Kasprzak <kas@informatics.muni.cz> writes:
>
> You don't say if you run a 32bit or a 64bit kernel. I will assume 64bit.
>
>
>>Is it normal? How can I set up some IRQ balancing (or at least hard-wire
>>3ware for CPU1 and eth0 for CPU0)?
>
>
> Run irqbalanced
>
>
Well I posted that thing two weeks ago, occuring on a dual 240
K8T-Master from MSI, and yes: running irqbalance works fine, but still I
believe that there is some sort of weirdness in initialization code of
the kernel (2.6), because on 2.4 Kernels smp-affinity defaults to every
cpu and on 2.6 it doesnt.
Martin Polak
^ permalink raw reply
* Re: [Bluez-users] Logitech Bluetooth Mx900+keyboard support.
From: Marcel Holtmann @ 2004-01-28 8:00 UTC (permalink / raw)
To: Terence Rudkin; +Cc: Olivier Bornet, BlueZ Mailing List
In-Reply-To: <1075234547.3064.13.camel@localhost.localdomain>
Hi Terence,
> I finally had a chance to patch kernel and try hid2hci with this patch
> kernel. I still got success. but hcitool dev never reported any
> devices. I looked at the code in hid2hci, my diff is below.
>
> I first made the change at 204. And found that the /dev/usb/hid was not
> opening. Finding me /dev to be /dev/usb I changed line 79 to match my
> file structure.
be more specific and make a unified diff.
> Now I get
> hciconfig
> hci0: Type: USB
> BD Address: 00:07:61:07:ED:A9 ACL MTU: 192:8 SCO MTU: 64:8
> UP RUNNING PSCAN ISCAN
> RX bytes:131 acl:0 sco:0 events:14 errors:0
> TX bytes:32 acl:0 sco:0 commands:13 errors:0
>
> But not input from mouse and keyboard.
The dongle is now in HCI mode and this means that you have to handle the
HID protocol by yourself. Run the bthid daemon.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply
* Re: [Bluez-devel] Windows Port
From: Antony C. Roberts @ 2004-01-28 7:58 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Peter Kjellerstedt, BlueZ Mailing List
In-Reply-To: <1075276388.12766.49.camel@pegasus>
>>I may be stating the obvious, but do not forget about the
>>license issue. As far as I can tell from a quick search
>>through the BlueZ repository, only the code in libs2/lib
>>and utils2/lib is under LGPL, the rest (including the "old"
>>libraries) are under GPL. This means that any program or
>>kernel driver that uses any of the GPLed parts need to be
>>GPLed too. (This, btw, goes for Linux applications too that
>>use or link with the GPLed parts.)
>>
>>
>
>actually there is no problem with GPL or LGPL software on the Windows
>platform, but you are right that every kernel driver or program must be
>licensed under GPL, too.
>
>The libs2 is not really LGPL at the moment (even if the header of the
>files say so). Max and I already agreed that we should make the new
>library LGPL, but there are still some code snippets that are copyright
>by Qualcomm. And this code is GPL only at the moment, which means that
>the complete code will be still under the GPL. Maybe it is a good time
>to discuss this now. Max, what is the current status on this?
>
>
>
I have no problem with GPL in the RFCOMM and L2CAP bits. My aim is to
have a sub-system (set of services) which are accessible from an API.
The RFCOMM and L2CAP bits can remain GPL no problem. The driver would be
open-source (but not GPL) as would the API itself and any user mode apps.
Regards,
Antony C. Roberts.
^ permalink raw reply
* Re: [Bluez-users] hci0 problem after timeout
From: Marcel Holtmann @ 2004-01-28 7:57 UTC (permalink / raw)
To: Rafael Vidal Aroca; +Cc: BlueZ Mailing List
In-Reply-To: <40170986.70105@3WT.com.br>
Hi Rafael,
> Hi guys, i made a bluetooth network from my linux box to my ipaq box,
> but i'm having some problems. Both systems runs linux and bluez.
>
> In PC side i use the folowing commands:
>
> pand --listen --role GN
> hciconfig hci0 -lm master,accept
>
> Then on iPaq:
>
> hcitool inq
> pand --connect 00:80....
> ifconfig bnep0 192.168.2.2 netmask 255.255.255.0
>
> Back to PC:
>
> ifconfig bnep0 192.168.2.1 netmask 255.255.255.0
>
>
> Doing that i can ping and ssh to my ipaq pocket pc and can also use
> internet through pc. But just for 30 seconds!!!!
>
> After about 30 seconds the conection fails and pc's dmesg shows
> nothing. I just get and error when trying to restart hci0:
>
>
> root@gemini:~# hciconfig hci0 down
> root@gemini:~# hciconfig hci0 up
> Can't init device hci0. Connection timed out(110)
>
>
> I really think the problem is in the pc side, and i'm having trouble
> putting this D-Link DBT-120 usb bluetooth dongle to work since last
> year. Can anyone help or point solutions?
>
> Distro: Debian Woody
> Kernel: 2.4.22 (no from distro, i compiled)
> hotplug: 2004_01_05 (latest)
> bluefw: 1.0
>
> Hope i gave enough info. Thanks in advance.
give us the output of "hciconfig -a" for your devices. What kind of USB
host controller do you have (lspci)? What USB host driver do you use?
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply
* Re: 2.6.2-rc2-mm1
From: Mike Fedyk @ 2004-01-28 7:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
In-Reply-To: <20040127233402.6f5d3497.akpm@osdl.org>
On Tue, Jan 27, 2004 at 11:34:02PM -0800, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2-rc2/2.6.2-rc2-mm1/
>
>
> - From now on, -mm kernels will contain the latest contents of:
>
> Linus's tree: linus.patch
> The ACPI tree: acpi.patch
> Vojtech's tree: input.patch
> Jeff's tree: netdev.patch
> The ALSA tree: alsa.patch
>
> If anyone has any more external trees which need similar treatment,
> please let me know.
>
How about the fbdev tree?
^ 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.