All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: SIP ALG and netfilter
From: Harald Welte @ 2004-01-27 10:45 UTC (permalink / raw)
  To: Siddhartha Gavirneni; +Cc: netfilter-devel
In-Reply-To: <20040122212258.17112.qmail@web20805.mail.yahoo.com>

[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]

On Thu, Jan 22, 2004 at 01:22:58PM -0800, Siddhartha Gavirneni wrote:
> Hi,
>   I am new to this list, and I am here because I would
> like to develop a SIP ALG for netfilter. And for this
> purpose, I need help from you guys.

Great.  I suppose you are talking about free software development?
 
> Firstly, I tried searching for the SNMP ALG's source
> code, but could not find it. I would like to use that
> to understand the ALG approach for netfilter.

ip_nat_snmp.c

SNMP might not be the best example, since it only is a NAT helper, but
no conntrack helper.  Please look for ip_{conntrack,nat}_ftp.c for an
easy example... and ip_{conntrack,nat}_h323.c for a more sophisticated
one.

> Second, is there anyone else working on this? If yes,
> who is it, and can I contact those developers?

Please talk to Nikolai Dahlem <listuser@epygi.de>, he was working on
such a solution. 

> Thank you,
> Siddharth.

-- 
- 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: cfi_cmdset_0002 -- erase suspends broken.
From: David Woodhouse @ 2004-01-27 10:43 UTC (permalink / raw)
  To: dvrabel; +Cc: Linux MTD List
In-Reply-To: <40163B1F.1010702@cantab.net>

On Tue, 2004-01-27 at 10:19 +0000, David Vrabel wrote:
> _____________________________________________________________________
> The message in this transmission is sent in confidence for the
> attention of the addressee only and should not be disclosed to any
> other party. Unauthorised recipients are requested to preserve this
> confidentiality. Please advise the sender if the addressee is not
> resident at the receiving end.  Email to and from Arcom is
> automatically monitored for operational and lawful business reasons.

I can't find a way to make mailman trap for moderation any messages with
'confidental' and/or 'addressee' in the _text_, only to filter on
headers. So I've added 'Received:.*mail.*.arcom.com' along with
'From:.*dolby.com' to the blocked-for-having-clueless-management list.

Anyone else with similar disclaimers want to step forward now and
volunteer to be added to the list, to prevent them from accidentally
sending such crap in the future and being summarily removed?

-- 
dwmw2

^ permalink raw reply

* Re: [new filter] simple packet authentication
From: Harald Welte @ 2004-01-27 10:43 UTC (permalink / raw)
  To: Alexandre Becoulet; +Cc: netfilter-devel
In-Reply-To: <200401230216.08607.alexandre.becoulet@epita.fr>

[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]

On Fri, Jan 23, 2004 at 02:16:08AM +0100, Alexandre Becoulet wrote:
> On Friday 23 January 2004 01:25, Andrew Hall wrote:
> 
> > This is a neat idea although I'd probably be a bit wary to use the IP ID
> > field when considering it's use with fragments.
> 
> Sure, using the IP ID field could be an issue. The module will not mangle 
> fragmented packets (offset > 0 or MF flag set). That's why packets have to be 
> mangled before being routed. At least, it should work for locally-generated 
> packets, and for packets reaching the first gateway. It should not be usefull 
> to mangle the packet later.

well, there is one problem... once you have IP_DF set, the Fragment ID
is believed to be ueseless.  Linux in fact is setting it to zero, at
least in some cases, for performance reasons (contention on the id
counter).  So I could  imagine some weird implementations that would
then discard the IPid at some later point in the forwarding path of your
packet.

-- 
- 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: PS/2 Mouse problems with kernel 2.6.2_rc2
From: johann lombardi @ 2004-01-27 10:39 UTC (permalink / raw)
  To: Robert van Herk, linux-kernel
In-Reply-To: <40163820.9070105@students.cs.uu.nl>

> Does anyone have any clues? For example: am I doing wrong or is it a
> kernel bug ;-)?
Are you using DMA with your disk?
For my part, "hdparm -d1 /dev/xxx" solves the problem.

Johann


^ permalink raw reply

* Re: Ultra5 + Linux kernel 2.6.1 =  hangs while booting
From: Ralph Mitchell @ 2004-01-27 10:40 UTC (permalink / raw)
  To: sparclinux
In-Reply-To: <002801c3e2fb$d22e3c60$6400010a@goldeneye>

I think I have the same problem.  I get the same boot messages, followed by:

    PROMLI

and there it stops.  Nothing else happens, no keys work, can't break 
into the OK prompt, have to power down to get its attention.

However, 2.6.0 *does* work, built from gentoo-dev-sources (actually 
2.6.0-gentoo-r1).

I've built 2.6.1 from gentoo-dev-sources & sparc-dev-sources, and I 
downloaded vanilla 2.6.1 from kernel.org.  None of them boot.

I just applied patch.2.6.2-rc2 and that didn't boot either.

I have an E450, 4x400MHz cpus, 4Gb mem, bunch-o-disks, quad hme and no 
display.  I'm using serial console, which works just fine in 2.6.0. 

Ralph Mitchell

Alex Smith wrote:

>(Also submitted to debian sparc list)
>
>Hi Everyone,
> 
>I currently have version 2.4.18 #2 of the kernel, which came when I
>installed Debian woody for Sparc.  Everything is 'stable', except for gcc
>and related packages which were upgraded to 'testing' (gcc 3.3.2).  I have
>been trying to compile a version of 2.6.1 for over a week with lots of
>problems and I'm finally stuck, exhausting the web and forums, and need some
>help.  
> 
>I have tried endless .config permutations, the most promising being the 2.6
>Ultra10 example from:
> 
>http://dev.gentoo.org/~ciaranm/configs/kernel/
> 
>It seems like a lot of people like me have trouble with the size of the
>kernel, and I can't ever use vmlinux, even compressed, so I follow these
>steps:
> 
>make menuconfig
>make
>make image
>make modules
>make modules_install
> 
>The arch/sparc64/boot/image is then placed in /boot (along with the new
>/boot/System.map) and added to silo.conf.
> 
>Whenever I try to boot to this from silo, I get:
> 
>      boot: linux6
>      Loaded kernel version 2.6.1
> 
>      Remapping the kernel... done.
>      Booting Linux...
> 
>Where it flashes the keyboard LEDs once, then appears to freeze
>indefinitely. I have tried many of the graphics modules, but is there one I
>need specifically?  How will my Ultra5 config need to be different from the
>Ultra10?  Should I go back to a 2.6 instead of 2.6.1?
> 
>Any ideas would be truly appreciated; I'm just tired of compiling.
> 
>Thanks,
> 
>      Alex Smith
>      ans1024@rit.edu
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe sparclinux" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>  
>


^ permalink raw reply

* Re: NAT before IPsec with 2.6
From: Harald Welte @ 2004-01-27 10:39 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: Henrik Nordstrom, Tom Eastep, Michal Ludvig, netfilter-devel
In-Reply-To: <20040124092721.GA19140@alpha.home.local>

[-- Attachment #1: Type: text/plain, Size: 3896 bytes --]

On Sat, Jan 24, 2004 at 10:27:21AM +0100, Willy Tarreau wrote:
> On Sat, Jan 24, 2004 at 10:21:12AM +0100, Henrik Nordstrom wrote:
>  
> > These hooks have not yet been done, mostly because nobody has contributed
> > the code adding these hooks to the new IPSec implementation in a 
> > reasonable manner I guess.
> 
> OK, that's good news. At first, I thought that people were against this
> mode of operation. This is now just a matter of time for anyone of us to
> understand how to add the hooks and send a patch ! I wish I add time...

I have to agree with Henrik.  Once there is an implementation that the
netfilter core team is happy with, we're certainly going to push very
hard to include this in the mainstream kernel.

I have to admit that I haven't yet found a 'perfect' solution of that
problem - but I'm following the ongoing discussion.

JFYI: I really don't like the 'postrouting called twice' solution.  This
violates one of the core basics of netfilter/iptables so far.

I also disagree that an ESP packet should be trated as locally
generated (and thus iterate over OUTPUT).   From my perspective, locally
generated means more something like: sent via a local userspace process
using PF_INET sockets.  If we consider a packet after any kind of change 
as locally-generated, we could argue doing this with NAT'ed packets,
too.  Please try to convince me, if I'm missing some point.

One of the fundamental principles behind netfilter/iptables, especially
NAT, is it's symmetric behaviour (between incoming and outgoing packets,
between the hooks, ...).   So with any possible solution, this should be
kept in mind.

Also, I could expect way more headaches with regard to NAT of IPsec
encapsulated packets.  NAT is based on connection tracking and thus
connection tracking has to be fully compatible with the 2.6.x IPsec
implementation.

Right now, conntrack doesn't even notice that there are ESP/AH packets.
PREROUTING creates a new conntrack for the unencapsulated packet.  Later
the packet is encapsulated, and confirmed at POSTROUTING time [where it
is still the same skb, but one should argue whether that ESP packet
really belongs to the original connection].

My proposal:
From conntracks view (and thus from NAT view), there (shuld be?) two
seperate connections for any given to-be-encapsulated packet:

- the payload connection (tcp/udp/whatever)
	- conntrack entry created at PREROUTING
	- conntrack entry confirmed (put in hash) at XXX
- the AH/ESP connection 
	- conntrack entry created at YYY
	- conntrack entry confirmed at POSTROUTING

To do this, somewhen between esp_output() is called and the beginning of
the modification of the packet payload, we need to call
nf_hook(POST_ROUTING).  This way, conntrack would be able to put the
connection in the hash, and people can do SNAT-like operations in
nat->POSTROUTING.  We could even pass a dummy output device structure
with an interface name "esp" so people can SNAT everything heading for
esp encapsulation.

As for the AH/ESP connection, this has to be created just after the
packet was encapsulated.  We need ot clear skb->nfct (and drop refcount
to old conntrack) after encapsulation, and call nf_hook(PRE_ROUTING).

The then-encapsulated packet will then finally go via the traditional
ipv4 stack and come to the POST_ROUTING hook, where the ESP connection
can be confirmed.

This should solve all our NAT problems for free, shouldn't it?

> Regards,
> Willy

-- 
- 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: Is gcc 3.2.2 suitable for kernel builds?
From: Daniel Andersen @ 2004-01-27 10:37 UTC (permalink / raw)
  To: John Heil; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.58.0401262211480.7728@scsoftware.sc-software.com>

> It seems that some gcc 3.2.2 optimizations are generating
> bogus code sequences.
>
> Has anyone else had compiler issues w gcc 3.2.2?
>
> Thanks much,
>
> johnh

As recently posted in a thread "gcc 2.95.3", please have a look at
http://developer.osdl.org/cherry/compile/

3.2.2 and 2.6.x should work fine under most circumstances.

What kernel-version, optimizations and architecture are you using?

Daniel Andersen


^ permalink raw reply

* Re: pmdisk working on ppc (WAS: Help port swsusp to ppc)
From: Benjamin Herrenschmidt @ 2004-01-27 10:37 UTC (permalink / raw)
  To: Michael Schmitz
  Cc: Pavel Machek, Hugang, Patrick Mochel, Nigel Cunningham,
	ncunningham, linuxppc-dev list
In-Reply-To: <Pine.LNX.4.44.0401271130010.23778-100000@opal.biophys.uni-duesseldorf.de>


> I don't mind the wait for memory being freed. Copying more pages with
> interrupts disabled would mean a higher chance for PMU lockup, won't it?

It's also possible that there is a bug and it just crashes :)

Also, I do suspend devices before the page copy, and I quickly hacked a
PMU sysdev that should suspend ADB interrupts (at least) so that should
be fine, except if you have a brightness request in flight maybe ?

The whole PMU suspend thing must be reworked I suppose. (And the battery
monitoring thing "paused" as well, we must wait for async PMU requests,
that is at least battery requests and backlight ones to stop)

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply

* Re: Strange xmms deaths under high disk load
From: Piotr Kowalczyk @ 2004-01-27 10:36 UTC (permalink / raw)
  To: linux-kernel

Hello World\n

> I have encountered a very strange (to me, at least) error.  I can
> reliably cause xmms to crash by simply doing some intensive disk IO.
> Copying a few hundred megabytes usually does it.  After about 20
> seconds of heavy disk IO, xmms will die with this message:

[...]

> Should I just call it an xmms bug, or should I start digging for
> hardware problems or kernel bugs?

Well, at least not hardware problems, I think. I don't know anything 
about messages that xmms throws, but it hangs regularly under heavy 
disk load. Usually clicking pause and play is enough to bring it back.
In case of doing anything else it hangs completely. 
I have Athlon XP 1700+, sound via via82xx, ATA-100, 
kernel 2.6.1 (with 2.6.0 was the same). 
Had no problems with 2.4, but haven't used alsa then. Maybe i'll try to
debug it a bit more if i find some time. 
chears, 

-- 
Piotr Kowalczyk <pikov@piasta.pl>
PRDKW (iols)


^ permalink raw reply

* Re: pmdisk working on ppc (WAS: Help port swsusp to ppc)
From: Michael Schmitz @ 2004-01-27 10:34 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: Pavel Machek, Hugang, Patrick Mochel, Nigel Cunningham,
	ncunningham, linuxppc-dev list
In-Reply-To: <1075154452.6191.91.camel@gaston>


> > > Ah, also: The "Freeing memory" phase takes forever. That should
> > > really be fixed.
> >
> > Well, it does the trick for me, but it takes 50% or so of suspend
> > time. Some memory managment guru making "freeing memory" faster would
> > certainly be welcome.
> > 								Pavel
> > PS: But I'd like to keep it simple...
>
> Haven't looked at it yet. Several crash reports so far, mostly
> lockups right after printing the number of pages to save. I wonder
> if we have something broken in there. It dies for me once too at
> this point.

The PMU locking up with interrupts disabled, for me (Lombard, 400 MHz).
Seems to happen more often on slow machines.
Otherwise, it works (saving to the last swap partition if you try to
specify which one to use; patch sent to Ben FWIW).

> Also, at least on pmac laptops, the HD is usually so fast, that
> I suspect spending 10 seconds freeing things is less efficient than
> spending this 10 seconds writing 200Mb of data to disk :) Also, one
> wakup, it's quite painful to see everything be swapped in again. It
> may make sense to be less agressive on the memory freeing, though
> finding a good balance isn't easy.

I don't mind the wait for memory being freed. Copying more pages with
interrupts disabled would mean a higher chance for PMU lockup, won't it?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply

* Re: [uPATCH] ufs.txt update
From: szonyi calin @ 2004-01-27 10:33 UTC (permalink / raw)
  To: linux-kernel
In-Reply-To: <Pine.LNX.4.58.0401270409450.949@pervalidus.dyndns.org>

 --- Frédéric_L._W._Meunier <1@pervalidus.net> a écrit : > On
Tue, 27 Jan 2004, GOTO Masanori wrote:
> 
> > At Sun, 25 Jan 2004 09:26:21 +0100,
> > Jochen Hein wrote:
>
> > This patch updates typos and HP-UX description in
> > Documentation/filesystems/ufs.txt, suggested by
> Andries.Brouwer@cwi.nl
> > and Jochen Hein <jochen@jochen.org>.
> 
> Someone could also add some notes to ufs.txt and the Configure
> entry for 2.4 and 2.6 about the lack of UFS2 support, which is
> the default since FreeBSD 5.1.
> 

yeah.
... and about the missing write support for solaris x86 ufs 
partition ... :-(



=====
--
A mouse is a device used to point at 
the xterm you want to type in.
Kim Alm on a.s.r.

_________________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

^ permalink raw reply

* Re: 1.0.2 release
From: Jaroslav Kysela @ 2004-01-27 10:28 UTC (permalink / raw)
  To: Carl-Daniel Hailfinger; +Cc: ALSA development
In-Reply-To: <4016394B.7080201@gmx.net>

On Tue, 27 Jan 2004, Carl-Daniel Hailfinger wrote:

> Jaroslav Kysela wrote:
> > Hello all,
> > 
> > 	we released packages 1.0.2.
> 
> The current tree from kernel.org claims in linux/include/sound/version.h
> that only Alsa 0.9.7 is integrated. Is that correct?

Yes, in Andrew Morton's (mm) tree is more updated ALSA and you can get 
latest patches from:

ftp://ftp.alsa-project.org/pub/kernel-patches

We fixed all of serious bugs now so I will ask Linus to sync with our BK 
tree today.

						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

* SBLive: mirroring analog inputs to rear channel
From: tibors @ 2004-01-27 10:26 UTC (permalink / raw)
  To: alsa-devel

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

Hi,

sorry if this is not the right place to ask, but on alsa-users noone could help me...

recently I have discovered that all kind of external inputs 
(stereo inputs) on my SBLive (with 4 analog speakers) works, 
but their sounds (analog cd, mic, line-in) can be hear only 
on the front channels. I tried all of alsamixer's elements - no success.
Computer based sounds (mp3, video, games) use all four 
speakers, regardless of how many channels are in it. (E.g. my 
stereo mp3s are played through all 4 speakers.)

I don't know if rear channels should be used by simple mixer 
tricks - I think I need to mirror these inputs to rear channels, too.

Should anyone help me how to make it?

Thanks!
Sipi
____________________________________________________________________
Miert fizetsz az internetert? Korlatlan, ingyenes internet hozzaferes a FreeStarttol.
Probald ki most! http://www.freestart.hu

^ permalink raw reply

* Re: bk pull on ia64 linux tree
From: Jes Sorensen @ 2004-01-27 10:23 UTC (permalink / raw)
  To: linux-ia64
In-Reply-To: <Pine.LNX.4.58.0401121658240.14305@evo.osdl.org>

>>>>> "David" = David Mosberger <davidm@napali.hpl.hp.com> writes:

David> Hi Linus, please do a

David> 	bk pull http://lia64.bkbits.net/to-linus-2.5

David> This will update the files shown below (only ia64-specific
David> files are touched).

David,

Is this patch available as a normall diff somewhere?

Thanks,
Jes

^ permalink raw reply

* Re: [Linux-fbdev-devel] Re: monochrome display fix.
From: Benjamin Herrenschmidt @ 2004-01-27 10:19 UTC (permalink / raw)
  To: Thiemo Seufer
  Cc: Linus Torvalds, James Simmons, Linux Fbdev development list,
	Linux Kernel Mailing List
In-Reply-To: <20040127074035.GF1315@rembrandt.csv.ica.uni-stuttgart.de>


> It was always broken. This went unnoticed, apparently nobody tried to use
> a kernel which supports mono and colour framebuffers at the same time.

Still, the patch is ugly.. I'd rather just calculate the colour
normally, and only conditionally store it once in the end...

Ben.



^ permalink raw reply

* Re: Re: monochrome display fix.
From: Benjamin Herrenschmidt @ 2004-01-27 10:19 UTC (permalink / raw)
  To: Thiemo Seufer
  Cc: Linus Torvalds, James Simmons, Linux Fbdev development list,
	Linux Kernel Mailing List
In-Reply-To: <20040127074035.GF1315@rembrandt.csv.ica.uni-stuttgart.de>


> It was always broken. This went unnoticed, apparently nobody tried to use
> a kernel which supports mono and colour framebuffers at the same time.

Still, the patch is ugly.. I'd rather just calculate the colour
normally, and only conditionally store it once in the end...

Ben.




-------------------------------------------------------
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: 1.0.2 release
From: Carl-Daniel Hailfinger @ 2004-01-27 10:11 UTC (permalink / raw)
  To: Jaroslav Kysela; +Cc: ALSA development
In-Reply-To: <Pine.LNX.4.58.0401271049310.3133@pnote.perex-int.cz>

Jaroslav Kysela wrote:
> Hello all,
> 
> 	we released packages 1.0.2.

The current tree from kernel.org claims in linux/include/sound/version.h
that only Alsa 0.9.7 is integrated. Is that correct?


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/



-------------------------------------------------------
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: RE: preparing toshiba_acpi driver release
From: Ducrot Bruno @ 2004-01-27 10:21 UTC (permalink / raw)
  To: Brown, Len; +Cc: John Belmonte, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <BF1FE1855350A0479097B3A0D2A80EE0CC8A54-N2PTB0HCzHJF3Yvz3xaN/VDQ4js95KgL@public.gmane.org>

On Mon, Jan 26, 2004 at 02:29:02PM -0500, Brown, Len wrote:
> > Wait.  I take video, not hotkey :)
> 
> Yes, I just mentioned hotkeys because that is the other part of the
> platform dependent drivers which need a more generic solution.
> 
> > > I think video brightness control will be a very popular and visible
> > > feature -- no pun intended;-)
> > 
> > ATM I much prefer _CST though, even if there is no visible 
> > effect other
> > than people may notice that their laptop will run longer on battery,
> > and if they don't have some usb driver loaded.
> 
> I was thinking about ergonomics rather than power-savings -- though
> probably brightness control has some power savings benefits too -- maybe
> somebody on the list has numbers for screen power consumption?

backlights are power hungry monster.

> 
> > > In the back of my head I'm also wondering if we've got a 
> > missing piece
> > > of the suspend/resume puzzle here too -- and I'd hate for 
> > ACPI to be the
> > > "missing link" to get that key feature working.
> > 
> > IMHO, there is a need at first to glue devices in the ACPI 
> > namespace and the
> > devices enumerated by OS a la pnpbios...
> 
> For suspend/resume, or for something else?

For enumerating devices, should be usefull for suspend/resume.
The ACPI subsystem then may be able to call specific AML method
for this device, but at first, driver need to know that such
method exist.

> PNP is only for ISA devices, yes?  Is it really still used?

PNP was first designed for PCI device, IIRC.  Anyway, common isa devices
include serial ports, parallel ports, keyboard controller to name
a few.  Now, Linux do have some kind method to glue such devices
with real drivers.  It's more to point to look that kind of code
in order to see if ACPI can do the same, but with all the devices in mind.

> When we were working on interrupts somebody suggested that we ask the
> ISA bus driver about what ISA interrupts where taken rather than using a
> table inside the ACPI code containing "conventions".  The conventions
> are simple, and so far seem to be functional -- though one could argue
> such heuristics are sort of a hack.

ISA devices do have 'well known' interrupts, io ports.  Anyway, isa devices
are enumerated by ACPI and configuration may be retrived for them if
really needed (they are children of the isa bridge function of the
southbridge, in a hopefully well written AML).

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
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: Is gcc 3.2.2 suitable for kernel builds?
From: m0sia @ 2004-01-27 10:19 UTC (permalink / raw)
  To: John Heil; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.58.0401262211480.7728@scsoftware.sc-software.com>

On Mon, 26 Jan 2004 22:15:29 -0800 (PST)
John Heil <kerndev@sc-software.com> wrote:

> 
> It seems that some gcc 3.2.2 optimizations are generating
> bogus code sequences.
> 
> Has anyone else had compiler issues w gcc 3.2.2?
> 
> Thanks much,
> 
> johnh
> 
> -
> -----------------------------------------------------------------
> John Heil
> South Coast Software
> Custom systems software for UNIX and IBM MVS mainframes
> 1-714-774-6952
> johnhscs@sc-software.com
> http://www.sc-software.com
> -----------------------------------------------------------------
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

I'm using gcc 3.2.2 and everything is "ok". What optimization are you
using? Maybe you will upgrade to 3.2.3?

^ permalink raw reply

* Re: cfi_cmdset_0002 -- erase suspends broken.
From: David Vrabel @ 2004-01-27 10:19 UTC (permalink / raw)
  To: Linux MTD List
In-Reply-To: <1075129557.24024.81.camel@hades.cambridge.redhat.com>

David Woodhouse wrote:
> On Mon, 2004-01-26 at 10:12 +0000, David Vrabel wrote:
> 
>>>The problem with the occasional bit errors appears to only occur 
>>>when the erase is suspended for a write so I've temporarily disabled
>>>that.
>>
>>Seems I left the patch off that does this.
> 
> Thanks. Wanna go ahead and commit it?

Done.  MTD CVS should now work on AMD chips though performance will be 
poor when used with (for example) JFFS2.

David Vrabel



_____________________________________________________________________
The message in this transmission is sent in confidence for the attention of the addressee only and should not be disclosed to any other party. Unauthorised recipients are requested to preserve this confidentiality. Please advise the sender if the addressee is not resident at the receiving end.  Email to and from Arcom is automatically monitored for operational and lawful business reasons.

This message has been checked for all viruses by MessageLabs Virus Control Centre.

^ permalink raw reply

* Re: [OFFTOPIC]   "smack the penguin"
From: Voicu Liviu @ 2004-01-27 10:13 UTC (permalink / raw)
  To: Chris Friesen; +Cc: linux-kernel
In-Reply-To: <401177DB.8010901@nortelnetworks.com>



Chris Friesen wrote:

| Diversion for friday afternoon...how far can you get?
|
| Personal best is 586
|
| http://www.meph.eu.org/
|
1224.1

http://pluto.huji.ac.il/~pacman/images/kick_penguin.png



^ permalink raw reply

* Re: Documentation Bugs
From: Clemens Ladisch @ 2004-01-27 10:12 UTC (permalink / raw)
  To: Torrey Hoffman; +Cc: Patrick Shirkey, ALSA Development
In-Reply-To: <1074896628.13428.189.camel@moria.arnor.net>

Torrey Hoffman wrote:
> My .asoundrc at this point closely follows the documentation (with
> corrections as noted in bug#2) and looks like:
>
> pcm.ac97 {
> 	type hw
> 	card 0
> 	device 0
> }
>
> pcm_slave.sl2 {
> 	pcm ac97
> 	rate 44100
> }
>
> pcm.rate_convert {
> 	type rate
> 	slave sl2
> }
>
> The documentation says:
> "Now you can call this newly created virtual device by: aplay -D
> rate_convert test.wav"
>
> But when I try that, I get this error:
>
> Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
> aplay: set_params:805: Broken configuration for this PCM: no configurations available
>
> Note that "aplay -D ac97 test.wav" works, but plays too fast (at 48000),
> and gives the warning "please, try the plug plugin (-Dplug:ac97)". If I
> do that, it works perfectly.

This example is intended to demonstrate a virtual device that accepts
all sample rates and converts them to 44.1 kHz before playing.

However, it seems your hardware supports 48 kHz only.

I think the example should use 48 instead of 44.1 because that is the
only sample rate guaranteed to be available on AC'97 codecs.


HTH
Clemens




-------------------------------------------------------
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

* PS/2 Mouse problems with kernel 2.6.2_rc2
From: Robert van Herk @ 2004-01-27 10:06 UTC (permalink / raw)
  To: linux-kernel

Hi people,

I have problems with my ps/2 mouse and keyboard under kernel 2.6.2_rc2.

Whenever the system is under heavy load, the mouse goes crazy. Also the 
keyboard start dropping characters or responding slow. Waiting with 
keyboad and mouse input for about half a minute sometimes solves the 
problem.

dmesg gives the following errors:
psmouse.c: Mouse at isa0060/serio1/input0 lost synchronization, throwing 
2 bytes away.
atkbd.c: Keyboard on isa0060/serio0 reports too many keys pressed.

These messages actually occur more than once.

I have seen that messages like these occur more than once on the mailing 
list, though in my case putting psmouse_noext to the boot options didn't 
solve the issue.

This is the hardware used:
PS/2 mouse. Check one with and one without scrollwheel, same results.
AMD Athlon 2400+
512 MB Memory
1 80 gig IDE harddisk

Asus A7V333-X motherboard

Furthermore, some exotic hardware: Medion MD2819 television card.

It seems that the messages occur when heavy disk activity takes place. 
It looks like the harddisk gets priority over the mouse, causing the 
mouse to drop bytes, but ofcourse this is pure guessing. Anyhow, the 
symptom is that whenever heavy disk activity takes places, the mouse 
responds sluggish at first and later goes totally crazy...

Does anyone have any clues? For example: am I doing wrong or is it a 
kernel bug ;-)?

Greetings,
Robert

^ permalink raw reply

* Re: [PATCH] multple rules files support/symlink rules support
From: "Andrey Borzenkov"  @ 2004-01-27  9:54 UTC (permalink / raw)
  To: linux-hotplug
In-Reply-To: <200401172313.00189.arvidjaar@mail.ru>



-----Original Message-----

> 
> On Mon, Jan 26, 2004 at 08:31:23PM +0300, Andrey Borzenkov wrote:
> > On Thursday 22 January 2004 20:44, Svetoslav Slavtchev wrote:
> > > > On Sat, Jan 17, 2004 at 11:13:00PM +0300, Andrey Borzenkov wrote:
> > > > > Attached patch adds support for
> > > > >
> > > > > - multiple rules files. You can now do
> 
> ...
> 
> > I do not :) the only reason to allow multiple files was to allow overriding; I 
> > had to update patch for ude-014 and sorting directory contents turned out to 
> > be quite easy so this is the final version - it takes single name which is 
> > either file or directory; directory is scanned, sorted in ascending order and 
> > read. klibc version does not support directory.
> > 
> > > >
> > > > I don't really understand this.  Can you give an example of how this
> > > > would work?  Why do we want to have multiple symlinks from different
> > > > rules?
> >
> > you simply can't easily merge these two rules. Allowing second rule (in second 
> > file) is much more flexible - you simply get two symlinks pointing to the 
> > same file. None of them knows or cares about device is really named as long 
> > as symlinks are correctly created.
> > 
> > because this version assumes configuration be ordered it now ignores name only 
> > if it has not already been defined; else name with empty NAME/SYMLINK is 
> > silently ignored.
> 
> Uhh, why do this inside of udev?
> You must be root to setup the rules. So we can expect that you are able
> to run a update script or something that creates the main file.
> This can also merge your conflicting rules if needed.
> 

unfortunately because you removed my example this statement is rather
theoretical.

Once more:

NAME="sd*" PROGRAM="/build-standard-scsi-name" SYMLINK="%c"
SYSFS_product="Memory Bird" SYMLINK="my_flash"

Can you explain how are you going to merge them? And even programmatically?
there is nothing in those rules that suggests they will be applied
to the same device. They are likely to be maintained
separately by people who do not know about other rule nor care.
The first one may be part of standard distro (LSB conformance,
devfs compatibility, sr -> scd mapping, whatever). The second
will be created by particular user on particular system. He may
not even know nor care about the other one.

And do not forget that end-users are not likely to ever edit
udev configuration. They will be using some frontends provided
by distributions. I just try to make life for people creating
those frontends easier.

Those two rules are not conflicting in any way. They complement
each other. Having them as separate files makes maintenance much
easier.

regards

-andrey


-------------------------------------------------------
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
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

^ permalink raw reply

* 1.0.2 release
From: Jaroslav Kysela @ 2004-01-27  9:51 UTC (permalink / raw)
  To: ALSA development; +Cc: ALSA Announce

Hello all,

	we released packages 1.0.2.

ChangeLog:
**********

common
  * added support for new automake
alsa-driver
  * general
    - fixed typo in configure for detecting RedHat kernels
    - added resource allocation failure messages to all drivers
    - fixes in PCI memory allocation routines
    - fixed the build of 2.6 kernel with modversion
    - fixed PCI DMA allocation for most PCI cards
    - added SNDRV_PCM_STATE_DISCONNECTED state
    - more complete sysfs support
    - fixed 2.2 kernel support
    - added the support of stack dump at xrun
    - Change -EINVAL to -EALREADY in snd_pcm_unlink()
  * added intel8x0 modem driver
  * sb16 - fixed PnP problems
  * au88x0 - added pci fixup code
  * ens1371
    - cleanups in s/pdif controls
    - added rear/line-in switch
  * via82xx
    - fixed DXS volume value
    - more quirks
  * intel8x0
    - fixed the 6 channel output on nforce
    - added more quirks
    - added the workaround for a hardware bug in intel 440MX B-stepping
  * cmipci - improved s/pdif status bits initialization
  * emu10k1
    - renamed "Surround Digital" -> "Surround" to avoid ac97 name clashing
  * emusynth
    - added native API (hwdep) for soundfont handling
  * USB audio driver
    - add support for Edirol UM-1SX
    - added quirk for Sound Blaster MP3+
  * MPU401
    - fix names for MPU-401 ports
  * HDSP
    - set the PCI latency timer to 255 for fixing some misbehavior
  * OSS emulation
    - fixed the oops in OSS mixer when the control elements are dynamically changed
    - a next attempt to fix click at the end of stream
alsa-lib
  * general
    - added SNDRV_PCM_STATE_DISCONNECTED state
    - fixed SHM memory leak fix in pcm routines
    - fixed non-version build
    - removed the function-in-function for qsort
    - CMIPCI, ICE1712 - fixed the iec958 capture using asym plugin
  * direct plugins
    - close all file descriptors in server_job()
    - improved compatibility with xine (fixes in poll() implemetation)
    - added slowptr option which improves pointer accuracy
    - dmix optimizations
alsa-utils
  * improved amidi

						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


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.