* [BUG] 2.5.52
From: Bill Davidsen @ 2003-01-08 13:23 UTC (permalink / raw)
To: Linux Kernel Mailing List
Running 2.5.52 (unpatched) I see these mesages on the console. I didn't
see them right a boot time, but they are there in the morning (about 8
hours later).
set_rtc_mmss: can't update from 1 to 56
set_rtc_mmss: can't update from 3 to 57
set_rtc_mmss: can't update from 5 to 58
set_rtc_mmss: can't update from 6 to 59
The system is running ntpd against a stratum three server, APM has system
time in GMT, let me know if any other info is useful, I may not run this
kernel again unless someone cares about this message.
--
bill davidsen <davidsen@tmr.com>
^ permalink raw reply
* Re: Remove GIO interface
From: Maciej W. Rozycki @ 2003-01-08 13:13 UTC (permalink / raw)
To: Ladislav Michl; +Cc: linux-mips, Ralf Baechle, Guido Guenther
In-Reply-To: <20030108140818.C17162@erebor.psi.cz>
On Wed, 8 Jan 2003, Ladislav Michl wrote:
> ap = (struct archdata *)(mp->archdata_start);
>
> if (ap->dbe_table_start == NULL ||
> !(mp->flags & (MOD_RUNNING | MOD_INITIALIZING)))
> continue;
> /* READ HERE: we don't reach this point because kernel is the last module
> * and it is not initialized yet, so it has no archdata */
Hmm, it would be good to have archdata_start and archdata_end initialized
statically for kernel_module. Added to my to-do list.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: the last changes to trident driver
From: James Tappin @ 2003-01-08 13:13 UTC (permalink / raw)
To: Takashi Iwai; +Cc: james, alsa-devel
In-Reply-To: <s5h4r8jaj1c.wl@alsa2.suse.de>
On Wed, 08 Jan 2003 14:05:35 +0100
Takashi Iwai <tiwai@suse.de> wrote:
TI> > P.S. any ideas on the incompatibility with a kernel with gameport
TI> > enabled as modules?
TI>
TI> ehm, i thought you had compiled the driver with a different kernel
TI> tree? you build the modules with versions, so it must be
TI> incompatible...
No, even after I fixed that problem, it still gave unresolved symbols
until I disabled the gameport stuff in the kernel and rebuilt that,
rebooted with the new kernel and did a clean rebuild of ALSA.
James
--
+------------------------+-------------------------------+---------+
| James Tappin | School of Physics & Astronomy | O__ |
| sjt@star.sr.bham.ac.uk | University of Birmingham | -- \/` |
| Ph: 0121-414-6462. Fax: 0121-414-3722 | |
+--------------------------------------------------------+---------+
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: Question for Marcelo
From: Tomas Szepe @ 2003-01-08 13:19 UTC (permalink / raw)
To: Alan Cox; +Cc: lkml
In-Reply-To: <1042034152.24099.4.camel@irongate.swansea.linux.org.uk>
> [alan@lxorguk.ukuu.org.uk]
>
> I've also dropped rmap out for now.
Hmm, what for?
--
Tomas Szepe <szepe@pinerecords.com>
^ permalink raw reply
* Re: IDE DMA disabled with via82cxxx on kernels >= 2.5.35
From: Alan Cox @ 2003-01-08 14:02 UTC (permalink / raw)
To: rwhron; +Cc: Linux Kernel Mailing List
In-Reply-To: <20030108051651.GA6511@rushmore>
On Wed, 2003-01-08 at 05:16, rwhron@earthlink.net wrote:
> I have two machines with VIA chipsets. Recent 2.5
> kernels boot with "DMA disabled".
It turns it on again but forgets to tell you. Its on the fix list
bu tfor 2.4 first
^ permalink raw reply
* Re: the last changes to trident driver
From: Takashi Iwai @ 2003-01-08 13:05 UTC (permalink / raw)
To: James Tappin; +Cc: james, alsa-devel
In-Reply-To: <20030108125227.4ee7ff0a.sjt@star.sr.bham.ac.uk>
At Wed, 8 Jan 2003 12:52:27 +0000,
James Tappin wrote:
>
> TI>
> TI> hmm, unfortunately the stack wasn't parsed correctly with symbols.
> TI> did you build the alsa drivers with debug option
> TI> (--with-debug=full)? anyway, please rebuild the drivers with the
> TI> attached patch (and debug option, if not yet). i hope a fatal oops
> TI> or hang-up can be avoided now...
> TI> oh, also, please update the cvs tree again. i've done some changes
> TI> since yesterday.
>
> As far as I can tell that works, i.e. the modules load, aplay plays a
> wav file and there's nothing in /var/log/syslog -- I can't tell if any
> sound's coming out.
thanks. then it's better to commit it to cvs, to avoid for other
people to get oops :)
>
> Best regards,
> James
>
> P.S. any ideas on the incompatibility with a kernel with gameport
> enabled as modules?
ehm, i thought you had compiled the driver with a different kernel
tree? you build the modules with versions, so it must be
incompatible...
ciao,
Takashi
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: PIC programming question
From: Frank Terhaar-Yonkers @ 2003-01-08 13:04 UTC (permalink / raw)
To: Phil; +Cc: linux-hams
In-Reply-To: <200301062005.06383.phil@spiderweb.com.au>
Phil,
I bought a cheap (hooks up to parallel port) programmer from:
http://www.dontronics.com/prod.html
It and the PICALL software are like USD$65 assembled. Works with nearly
any PIC chip.
Also, check out "mplab" which is a free assembly language dev
environment available from www.microchip.com.
If you are doing a lot of fooling around and testing, buy a couple of
PICs that are eeprom based. Erase them with a high-intensity UV light.
Cheaper in the long run than the burn once, throw aways.
cheers,
- Frank
Phil wrote:
> Hello All,
>
> I'd to try my hand at PIC programming and the projects that I have in mind are
> amateur radio related so I suppose this question is not off topic.
>
> I have some utilities (gputils) that will create the hex code, however I'm
> wondering what other people use to actually program the PIC.
>
> An Internet search didn't reveal very many programmers for Linux. One
> interesting project is called ponyprog2000. The hardware is more complex than
> a typical programmer that operates under MS Windows but it's probably more
> versatile. The software appears to be easy enough to use.
>
> Does anyone have a favorite PIC programmer? My only interest at the moment is
> to be able to program PIC 16F84 and 16F876 chips.
>
--
\\\\////\\\\////\\\\\////\\\\\////\\\\////\\\\////
Frank Terhaar-Yonkers W4FTY TRA 8325/L2
Cisco Systems, Inc.
NSITE - Pineview Building - RTP
7025 Kit Creek Road PO Box 14987
Research Triangle Park, North Carolina 27709
fty@cisco.com voice(919)392-2101 fx(919)392-4833
^ permalink raw reply
* Re: [PATCH][TRIVIAL] menuconfig color sanity
From: Alan Cox @ 2003-01-08 13:56 UTC (permalink / raw)
To: jeff gerard; +Cc: Linux Kernel Mailing List
In-Reply-To: <20030108104714.GM268@gage.org>
On Wed, 2003-01-08 at 10:47, jeff gerard wrote:
> hi,
>
> using yellow and green text with a "white" background in menuconfig works all
> right on console, but it looks like crap under xterm, rxvt, etc. no
> matter whose fault that is, the trivial patch below makes things more
> readable without any major change in appearance. applies to 2.4 and 2.5.
>
> now you can stop wondering about support for "lug and play", "mateur radio",
> and "elephony" in the linux kernel.
Try that on a mono monitor before merging it
^ permalink raw reply
* Re: small fix for nforce ide chipset driver in 2.5.54
From: Alan Cox @ 2003-01-08 13:53 UTC (permalink / raw)
To: James Curbo; +Cc: Andre Hedrick, Linux Kernel Mailing List
In-Reply-To: <20030108075539.GA4128@carthage>
On Wed, 2003-01-08 at 07:55, James Curbo wrote:
> so I added a #define for PCI_DEVICE_ID_NVIDIA_NFORCE_IDE as 0x0065. It
> compiled fine and I am in fact running that kernel now. I would have
> just sent a patch but I am new to kernel hacking, this is just a one
> liner and I'm sure you know where it goes better than I do.
Someone deleted it about 2.5.50, and though I sent in the fix twice Linus
still hasn't applied it 8(
^ permalink raw reply
* Re: opening a port..
From: Robert Botha @ 2003-01-08 13:02 UTC (permalink / raw)
To: mdew; +Cc: netfilter
In-Reply-To: <1042029237.4335.2.camel@india>
Check if the service is listening..and if it's listening on *:4662 or on a
specific interface.
netstat -tupln|grep ":4662"
----- Original Message -----
From: "Dharmendra.T" <dharmu@nsecure.net>
To: "mdew" <mdew@mdew.dyndns.org>
Cc: "netfilter" <netfilter@lists.netfilter.org>
Sent: Wednesday, January 08, 2003 2:33 PM
Subject: Re: opening a port..
>
>
> On Wed, 2003-01-08 at 17:42, mdew wrote:
> >
> > Hi,
> > Just *testing* this out..
> >
> > iptables -A INPUT -i eth0 -p tcp --dport 4662 -j ACCEPT
> > iptables -A INPUT -i eth0 -p udp --dport 4662 -j ACCEPT
> > iptables -A INPUT -i eth1 -p udp --dport 4662 -j ACCEPT
> > iptables -A INPUT -i eth1 -p tcp --dport 4662 -j ACCEPT
> > iptables -A INPUT -i eth1 -p tcp --sport 4662 -j ACCEPT
> > iptables -A INPUT -i eth1 -p udp --sport 4662 -j ACCEPT
> > iptables -A INPUT -i eth0 -p udp --sport 4662 -j ACCEPT
> > iptables -A INPUT -i eth0 -p tcp --sport 4662 -j ACCEPT
> >
> > iptables -A FORWARD -o eth0 -p tcp --dport 4662 -j ACCEPT
> > iptables -A FORWARD -o eth1 -p tcp --dport 4662 -j ACCEPT
> > iptables -A FORWARD -o eth1 -p udp --dport 4662 -j ACCEPT
> > iptables -A FORWARD -o eth0 -p udp --dport 4662 -j ACCEPT
> > iptables -A FORWARD -o eth0 -p udp --sport 4662 -j ACCEPT
> > iptables -A FORWARD -o eth1 -p udp --sport 4662 -j ACCEPT
> > iptables -A FORWARD -o eth1 -p tcp --sport 4662 -j ACCEPT
> > iptables -A FORWARD -o eth0 -p tcp --sport 4662 -j ACCEPT
> >
> > yet, when i try to telnet to it,
> >
> > mdew:~# telnet 127.0.0.1 4662
> > Trying 127.0.0.1...
> > telnet: Unable to connect to remote host: Connection refused
> >
> > Yeah I know I have lots of unnessary rules, but im only testing 'em...it
> > just seems a little strange that i cant see 4662 (Edonkey port) on the
> > router.
> >
> > -mdew
> >
> >
> Note:
> telnet 127.0.0.1 port
>
> This will not go through any of the interfaces(eth*). You should allow
> this through -i lo.
>
> Here some how you are getting connected and you are getting the response
> connection refused. Probably you are not running the service on the
> router!.
>
> --
> Dharmendra.T
> Linux Enthu
>
>
>
>
>
^ permalink raw reply
* ipv6 stack seems to forget to send ACKs
From: Wichert Akkerman @ 2003-01-08 13:08 UTC (permalink / raw)
To: netdev, linux-kernel
Recently a few friends setup an ipv6 icecast server to play with ipv6
and encourage people to use ipv6 more. When using linux this does
not work perfectly though: after a certain period (usually a bit
over 10 minutes) of listening to the stream traffic suddenly stops and
one has to reconnect. A tcpdump of the traffic seems to indicate that
the linux client suddenly stops sending ACKs and as a result the server
stops sending us data:
13:57:39.812123 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9352713 win 32616 <nop,nop,timestamp 846062 369670698>
13:57:39.823581 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9352713:9353921(1208) ack 1 win 5712 <nop,nop,timestamp 369670698 846028> [class 0x2]
13:57:39.823636 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9353921 win 32616 <nop,nop,timestamp 846063 369670698>
13:57:39.835144 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9353921:9355129(1208) ack 1 win 5712 <nop,nop,timestamp 369670698 846028> [class 0x2]
13:57:39.835197 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9355129 win 32616 <nop,nop,timestamp 846064 369670698>
13:57:39.844277 2001:968:1::2.8000 > tornado.wiggy.net.33035: P 9355129:9355601(472) ack 1 win 5712 <nop,nop,timestamp 369670701 846062> [class 0x2]
13:57:39.844326 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9355601 win 32616 <nop,nop,timestamp 846065 369670701>
13:57:40.221776 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9355601:9356809(1208) ack 1 win 5712 <nop,nop,timestamp 369670739 846065> [class 0x2]
13:57:40.221846 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9356809 win 32616 <nop,nop,timestamp 846103 369670739>
13:57:40.233558 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9356809:9358017(1208) ack 1 win 5712 <nop,nop,timestamp 369670739 846065> [class 0x2]
13:57:40.233613 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9358017 win 32616 <nop,nop,timestamp 846104 369670739>
13:57:40.245110 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9358017:9359225(1208) ack 1 win 5712 <nop,nop,timestamp 369670739 846065> [class 0x2]
13:57:40.245160 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9359225 win 32616 <nop,nop,timestamp 846105 369670739>
13:57:40.282351 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 <nop,nop,timestamp 369670744 846103>
13:57:40.284307 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9360433:9360653(220) ack 1 win 5712 <nop,nop,timestamp 369670744 846103>
13:57:40.297307 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9360653:9361861(1208) ack 1 win 5712 <nop,nop,timestamp 369670745 846104>
13:57:40.297376 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9359225 win 32616 <nop,nop,timestamp 846111 369670744,nop,nop,sack sack 1 {9360653:9361861} >
13:57:40.308222 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9362081:9363289(1208) ack 1 win 5712 <nop,nop,timestamp 369670745 846104> [class 0x2]
13:57:40.308271 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9359225 win 32616 <nop,nop,timestamp 846112 369670744,nop,nop,sack sack 2 {9362081:9363289}{9360653:9361861} >
13:57:40.310424 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9361861:9362081(220) ack 1 win 5712 <nop,nop,timestamp 369670745 846105>
13:57:40.310471 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9359225 win 32616 <nop,nop,timestamp 846112 369670744,nop,nop,sack sack 1 {9360653:9363289} >
13:57:40.325396 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9363289:9363509(220) ack 1 win 5712 <nop,nop,timestamp 369670750 846111> [class 0x2]
13:57:40.325447 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9359225 win 32616 <nop,nop,timestamp 846113 369670744,nop,nop,sack sack 1 {9360653:9363509} >
13:57:40.568652 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 <nop,nop,timestamp 369670773 846113>
13:57:41.121608 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 <nop,nop,timestamp 369670829 846113>
13:57:42.242095 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 <nop,nop,timestamp 369670941 846113>
13:57:44.481379 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 <nop,nop,timestamp 369671165 846113>
13:57:48.963035 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 <nop,nop,timestamp 369671613 846113>
13:57:53.955118 fe80::250:4ff:fe0b:dd79 > tornado.wiggy.net: icmp6: neighbor sol: who has tornado.wiggy.net
13:57:53.955183 tornado.wiggy.net > fe80::250:4ff:fe0b:dd79: icmp6: neighbor adv: tgt is tornado.wiggy.net
13:57:57.921294 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 <nop,nop,timestamp 369672509 846113>
13:58:15.841902 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 <nop,nop,timestamp 369674301 846113>
13:58:28.296672 tornado.wiggy.net.33035 > 2001:968:1::2.8000: F 1:1(0) ack 9359225 win 32616 <nop,nop,timestamp 850911 369670744,nop,nop,sack sack 1 {9360653:9363509} >
13:58:28.323604 2001:968:1::2.8000 > tornado.wiggy.net.33035: . ack 2 win 5712 <nop,nop,timestamp 369675550 850911>
tornado.wiggy.net is my client running Linux 2.4.19 (unpatched, UP machine),
and 2001:968:1::2 is the icecast server running Linux 2.4.20-rc2-ac3 (SMP).
If you want to test the stream yourself, please stream from
http://ipv6.lkml.org:8000/difm .
Wichert.
--
Wichert Akkerman <wichert@wiggy.net> http://www.wiggy.net/
A random hacker
^ permalink raw reply
* Re: Question for Marcelo
From: Alan Cox @ 2003-01-08 13:55 UTC (permalink / raw)
To: Samuel Flory; +Cc: Walt H, Linux Kernel Mailing List
In-Reply-To: <3E1B8E2B.9060200@rackable.com>
On Wed, 2003-01-08 at 02:34, Samuel Flory wrote:
> I believe that he would prefer that it get tested in the ac tree 1st.
> Alan seemed receptive to including it, but he's not doing much with the
> 2.4 ac kernel any more.
>
I've been working on merging a lot of stuff with Marcelo and cleaning up the
other changes. 2.4.21pre-ac should be out today, and its a lot smaller than
before as Marcelo as almost all the apic stuff, IDE updates etc. I've also
dropped rmap out for now
^ permalink raw reply
* Re: Requested: CMI8330 testers?
From: Takashi Iwai @ 2003-01-08 13:00 UTC (permalink / raw)
To: Bernard Urban; +Cc: alsa-devel
In-Reply-To: <87el83q0oh.fsf@merceron.meteo.fr>
Hi Bernard,
thanks for your reply.
At 27 Dec 2002 10:19:10 +0100,
Bernard Urban wrote:
>
> Takashi Iwai <tiwai@suse.de> writes:
>
> > Hi,
> >
> > can anyone who owns the CMI8330 ISA test the attached patch?
>
> I am your man !!! Happy to see that this card is no longer forgotten.
> 1 month ago, I have written the following to
> alsa-devel@lists.sourceforge.net, but it never got there (I was not a
> subscriber at this time).
>
> ******************************************
>
> Short story: (and main problem)
> =========
> I have tried to hack the cmi8330 driver version 0.9.0beta10, which
> does not work, by relying on the (semi) functional last 0.5 driver. It
> is difficult to appreciate the changes done between 0.5 and 0.9,
> as the CVS Changelog misses the 0.5 era.
> Any hint to fill this hole would be appreciated.
>
> More generally, I am wondering if ALSA is still considering
> maintenance on old sound chips drivers?
we can maintain the code but none of us have these hardwares for
test...
> As an alsa-1.0 release is near, this topic seems important to the
> credibility of the project.
>
> Long story: (plus a lot of other minor problems)
> =========
> I have access to 4 different Linux machines, with different sound
> cards. All the machine run Debian Woody, kernel 2.4.18,
> same config for 4 machines, as far as hardware permits:
> AMD K6-II with a SB Vibra 16x PnP
> AMD K6-II with a CMI8330
> PIII with a intel 810
> Athlon with a VIA8233
>
> First, the two K6-II machines run fine the OSS sb driver.
> When I got the Athlon machines, as via8233 is not supported by OSS
> drivers, I decided to switch to ALSA 0.9 (woody packages 0.9.0beta12).
>
> The Athlon with snd-via8233 runs fine, no problems with using the OSS
> compatibility level.
> The PIII with snd-intel8x0 runs well, except that xquake (original bin
> from Id) runs without producing any sound. Moot point, because
> quakeforge version works well (alsa plugin).
>
> So the problem here seems to be in the oss compatibility level ?
most likely the problem is due to mmap on OSS emulation.
the OSS emulation should be "direct" mode in some cases.
you can change the behavior via writing to oss proc file like
echo "xquake 0 0 direct" > /proc/asound/card0/pcm0p/oss
please check alsa-kernel/Documentation/ALSA-Configuration.txt for
details.
> Now the AMD K6-II with a SB Vibra 16X PnP: runs with snd-sb16. In the
> mixer I must force the 16 bit DMA to be allocated to Capture
> to have PCM sound for all kind of audio formats. If set to Auto, for instance
> .au format is not recognized. Also, xquake runs and produces sound only with
> option 8bits sound.
perhaps this is also related with the above.
> quakeforge works well, but there is a time lag in
> producing sound, which does not exist with the OSS driver.
> Tuning snd-mixahead does not help.
this is not sure. does the delay happen only on quake or do you mean
it generally? if it's general behavior, then it's easier to debug.
anyway we need to trace at which point the delay occurs.
> Finally the AMD K6-II with the CMI8330 and the snd-cmi8330 driver.
> Version 0.9 does not produce sound at all. But going back to alsa 0.5,
> I was able to produce PCM sound and play CDs. The mixer tuning is very
> buggy (this was documented in the alsa-user mail list 2 years ago!),
> but you can have it working. xquake does not produce sound though.
> quakeforge cannot be run (they use the 0.9 alsa API).
>
> Another real pain with this driver is the use of
> two devices (pcmC0D1p and pcmC0d0c) on the same card. This requires
> editing several configuration files to have OSS applications work.
> For instance, I must switch /dev/dsp with /dev/adsp and change in
> alsa.conf to the following line:
> defaults.pcm.device 1
>
> This was corrected in the 0.9 snd-cmi8330 driver, but as it now does not
> produce sound... I have analyzed the driver code differences between
> 0.5 and 0.9. The main difference in handling the hardware seems to be that
> in the 0.5 version, the SB mixer part is initialized, not in the 0.9
> one. So I added such an initialization step. I added also the SB mixer
> controls to the cmi8330 ones, as it is no more possible to add a second
> mixer device in the 0.9 API, at least I do not see how.
> (This addition is not understood
> by alsamixer, but amixer with the complex controls works, with the
> same kind of curious behaviour as amixer-0.5)
well, the mixers are all mixed up on alsa 0.9. it's possible to
assign the ad1848 mixer elements with the index 1, though.
> And guess what, bingo, I got PCM sound ! But an horrible sound, very
> distorted, so something is still working badly. This
> was just after removing the 0.5 driver and installing the modified 0.9 one.
> After rebooting the machine with the 0.9 running, no more sound!
ok, it explains the hardware init problem.
i'll check the difference between 0.5 and 0.9.
btw, my last patch was already committed to cvs.
ciao,
Takashi
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: Remove GIO interface
From: Ladislav Michl @ 2003-01-08 13:08 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: linux-mips, Ralf Baechle, Guido Guenther
In-Reply-To: <Pine.GSO.3.96.1030108133732.1580C-100000@delta.ds2.pg.gda.pl>
On Wed, Jan 08, 2003 at 01:41:41PM +0100, Maciej W. Rozycki wrote:
> On Wed, 8 Jan 2003, Ladislav Michl wrote:
>
> > * Even in case everything work as stated in documentation, we are unable
> > to use this mechanism to detect Newport for console driver (the main
> > reason why I created this interface was to provide neccessary
> > informations to Xserver), because our DBE handling doesn't work until
> > modules are initialized (in case we are building kernel with modules
> > support).
>
> That is a bug and it should be fixed. What are the symptoms?
the most notable symptom is machine hang at boot time :-) it doesn't apply
to cvs kernel, just to my private one where I called get_dbe in console_init.
you cannot use get_dbe _before_ init_modules is called (ie. in board_irq_init).
reason is following (copy&paste from traps.c). read "READ HERE".
static inline unsigned long
search_dbe_table(unsigned long addr)
{
unsigned long ret = 0;
#ifndef CONFIG_MODULES
/* There is only the kernel to search. */
ret = search_one_table(__start___dbe_table, __stop___dbe_table-1, addr);
return ret;
#else
unsigned long flags;
/* The kernel is the last "module" -- no need to treat it special. */
struct module *mp;
struct archdata *ap;
spin_lock_irqsave(&modlist_lock, flags);
for (mp = module_list; mp != NULL; mp = mp->next) {
if (!mod_member_present(mp, archdata_end) ||
!mod_archdata_member_present(mp, struct archdata,
dbe_table_end))
continue;
ap = (struct archdata *)(mp->archdata_start);
if (ap->dbe_table_start == NULL ||
!(mp->flags & (MOD_RUNNING | MOD_INITIALIZING)))
continue;
/* READ HERE: we don't reach this point because kernel is the last module
* and it is not initialized yet, so it has no archdata */
ret = search_one_table(ap->dbe_table_start,
ap->dbe_table_end - 1, addr);
if (ret)
break;
}
spin_unlock_irqrestore(&modlist_lock, flags);
return ret;
#endif
}
so although traps are initialized one cannot use them and have to wait
until modules are initialized too.
anyway, even if you fix this issue it is not reason for keeping GIO
interface.
ladis
^ permalink raw reply
* Re: Re: rotation.
From: Sven Luther @ 2003-01-08 12:55 UTC (permalink / raw)
To: John Bradford
Cc: Måns Rullgård, luther, geert, jsimmons,
linux-fbdev-devel, linux-kernel
In-Reply-To: <200301081205.h08C5mPv000776@darkstar.example.net>
On Wed, Jan 08, 2003 at 12:05:48PM +0000, John Bradford wrote:
> > > > > I'm about to implement rotation which is needed for devices
> > > > > like the ipaq.
> > > > > The question is do we flip the xres and yres values depending
> > > > > on the rotation or do we just alter the data that will be
> > > > > drawn to make the screen appear to rotate. How does hardware
> > > > > rotate view the x and y axis? Are they rotated or does just
> > > > > the data get rotated?
> > > >
> > > > Where are you going to implement the rotation? At the fbcon or
> > > > fbdev level?
> > > >
> > > > Fbcon has the advantage that it'll work for all frame buffer
> > > > devices.
> > >
> > > But you could also provide driver hooks for the chips which have
> > > such a rotation feature included (don't know if such exist, but i
> > > suppose they do, or may in the future).
>
> It would be nice to have an option to be able to do the rotation
> entirely in software - some desktop users might prefer to have a
> portait-orientated display, when their graphics card doesn't have any
> hardware rotation facilities at all.
Well, that is James plan. I suppose that for hardware that can do
hardware rotation, it will be faster to do it instead of having the
software do it though, and thus it would be nice to have a driver hook
or something.
This way, if rotation is asked, then if the driver supports hardware
rotation, do it, and if not, do it in software.
At first, no driver will support hardware rotation anyway, so it would
be done in software.
And then, you reuse the same stuff to drive a chinese console or
something such.
Friendly,
Sven Luther
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: [Asterisk] DTMF noise
From: Matti Aarnio @ 2003-01-08 13:04 UTC (permalink / raw)
To: David D. Hagood; +Cc: linux-kernel
In-Reply-To: <3E1C1CDE.8090600@sktc.net>
On Wed, Jan 08, 2003 at 06:43:10AM -0600, David D. Hagood wrote:
> Thomas Tonino wrote:
> >Roy Sigurd Karlsbakk wrote:
> >>so - we DO NOT need a 'simplistic' DTMF decoder.
> >
> >You need a good one. But good can be simplistic, is what I'm saying.
> >
> >DTMF was designed to be easy to decode reliably. Complex doesn't
> >automatically mean better.
>
> I haven't looked at the code, but I'd recommend using a bank of Goertzel
> filters -
Do look into drivers/isdn/isdn_audio.c That does use Görtzel
filter, but does not do complete energy comparisons -> false detections.
/Matti Aarnio
^ permalink raw reply
* Re: opening a port..
From: mdew @ 2003-01-08 12:53 UTC (permalink / raw)
To: mdew-pop3; +Cc: netfilter
In-Reply-To: <1042027958.606.7.camel@nirvana>
On Thu, 2003-01-09 at 01:12, mdew wrote:
>
> Hi,
> Just *testing* this out..
>
> iptables -A INPUT -i eth0 -p tcp --dport 4662 -j ACCEPT
> iptables -A INPUT -i eth0 -p udp --dport 4662 -j ACCEPT
> iptables -A INPUT -i eth1 -p udp --dport 4662 -j ACCEPT
> iptables -A INPUT -i eth1 -p tcp --dport 4662 -j ACCEPT
> iptables -A INPUT -i eth1 -p tcp --sport 4662 -j ACCEPT
> iptables -A INPUT -i eth1 -p udp --sport 4662 -j ACCEPT
> iptables -A INPUT -i eth0 -p udp --sport 4662 -j ACCEPT
> iptables -A INPUT -i eth0 -p tcp --sport 4662 -j ACCEPT
>
> iptables -A FORWARD -o eth0 -p tcp --dport 4662 -j ACCEPT
> iptables -A FORWARD -o eth1 -p tcp --dport 4662 -j ACCEPT
> iptables -A FORWARD -o eth1 -p udp --dport 4662 -j ACCEPT
> iptables -A FORWARD -o eth0 -p udp --dport 4662 -j ACCEPT
> iptables -A FORWARD -o eth0 -p udp --sport 4662 -j ACCEPT
> iptables -A FORWARD -o eth1 -p udp --sport 4662 -j ACCEPT
> iptables -A FORWARD -o eth1 -p tcp --sport 4662 -j ACCEPT
> iptables -A FORWARD -o eth0 -p tcp --sport 4662 -j ACCEPT
>
> yet, when i try to telnet to it,
>
> mdew:~# telnet 127.0.0.1 4662
> Trying 127.0.0.1...
> telnet: Unable to connect to remote host: Connection refused
>
> Yeah I know I have lots of unnessary rules, but im only testing 'em...it
> just seems a little strange that i cant see 4662 (Edonkey port) on the
> router.
>
> -mdew
ok, from another machine->router. (same problem)
telnet 10.0.0.6 4662
Trying 10.0.0.6...
telnet: Unable to connect to remote host: Connection refused
^ permalink raw reply
* Re: the last changes to trident driver
From: James Tappin @ 2003-01-08 12:52 UTC (permalink / raw)
To: Takashi Iwai; +Cc: james, alsa-devel
In-Reply-To: <s5h8yxvam1u.wl@alsa2.suse.de>
On Wed, 08 Jan 2003 13:00:29 +0100
Takashi Iwai <tiwai@suse.de> wrote:
TI> At Wed, 8 Jan 2003 11:06:50 +0000,
TI> James Tappin wrote:
TI> >
TI> > On Wed, 08 Jan 2003 11:08:39 +0100
TI> > Takashi Iwai <tiwai@suse.de> wrote:
TI> >
TI> > TI> At Tue, 7 Jan 2003 23:20:51 +0000,
TI> > TI> James Tappin wrote:
TI> > TI> >
TI> > TI> > On Tue, 07 Jan 2003 17:04:47 +0100
TI> > TI> > Takashi Iwai <tiwai@suse.de> wrote:
TI> > TI> >
TI> > TI> > > Hi,
TI> > TI> > >
TI> > TI> > > if someone has a Trident 4DNX (not DX), could you test the
TI> > TI> > > latest CVS driver? i hope my last change doesn't break,
TI> > TI> > > but i couldn't test the board atm...
TI> > TI> > >
TI> > TI> > >
TI> > TI> >
TI> > TI> > Hi Takashi,
TI> > TI> > I've managed to resolve my unresolved references problem
TI> > TI> > by rebuilding
TI> > TI> > the kernel without gameport support, but now attempting to
TI> > TI> > aplay a wav file produces an immediate segfault (but it
TI> > TI> > refuses to dump core).
TI> > TI>
TI> > TI> hmm, perhaps it caused oops in kernel.
TI> > TI> could you check the kernel message and get the trace via
TI> > TI> ksymoops if possible?
TI> > TI>
TI> >
TI> > I've just logged into the machine from work and looked back at the
TI> > system logs and this is what I see from "ksymoops syslog.0":
TI> >
TI>
TI> hmm, unfortunately the stack wasn't parsed correctly with symbols.
TI> did you build the alsa drivers with debug option
TI> (--with-debug=full)? anyway, please rebuild the drivers with the
TI> attached patch (and debug option, if not yet). i hope a fatal oops
TI> or hang-up can be avoided now...
TI> oh, also, please update the cvs tree again. i've done some changes
TI> since yesterday.
As far as I can tell that works, i.e. the modules load, aplay plays a
wav file and there's nothing in /var/log/syslog -- I can't tell if any
sound's coming out.
Best regards,
James
P.S. any ideas on the incompatibility with a kernel with gameport
enabled as modules?
--
+------------------------+-------------------------------+---------+
| James Tappin | School of Physics & Astronomy | O__ |
| sjt@star.sr.bham.ac.uk | University of Birmingham | -- \/` |
| Ph: 0121-414-6462. Fax: 0121-414-3722 | |
+--------------------------------------------------------+---------+
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: opening a port..
From: mdew @ 2003-01-08 12:52 UTC (permalink / raw)
To: Dharmendra.T; +Cc: netfilter
In-Reply-To: <1042029237.4335.2.camel@india>
On Thu, 2003-01-09 at 01:33, Dharmendra.T wrote:
>
>
> On Wed, 2003-01-08 at 17:42, mdew wrote:
> >
> > Hi,
> > Just *testing* this out..
> >
> > iptables -A INPUT -i eth0 -p tcp --dport 4662 -j ACCEPT
> > iptables -A INPUT -i eth0 -p udp --dport 4662 -j ACCEPT
> > iptables -A INPUT -i eth1 -p udp --dport 4662 -j ACCEPT
> > iptables -A INPUT -i eth1 -p tcp --dport 4662 -j ACCEPT
> > iptables -A INPUT -i eth1 -p tcp --sport 4662 -j ACCEPT
> > iptables -A INPUT -i eth1 -p udp --sport 4662 -j ACCEPT
> > iptables -A INPUT -i eth0 -p udp --sport 4662 -j ACCEPT
> > iptables -A INPUT -i eth0 -p tcp --sport 4662 -j ACCEPT
> >
> > iptables -A FORWARD -o eth0 -p tcp --dport 4662 -j ACCEPT
> > iptables -A FORWARD -o eth1 -p tcp --dport 4662 -j ACCEPT
> > iptables -A FORWARD -o eth1 -p udp --dport 4662 -j ACCEPT
> > iptables -A FORWARD -o eth0 -p udp --dport 4662 -j ACCEPT
> > iptables -A FORWARD -o eth0 -p udp --sport 4662 -j ACCEPT
> > iptables -A FORWARD -o eth1 -p udp --sport 4662 -j ACCEPT
> > iptables -A FORWARD -o eth1 -p tcp --sport 4662 -j ACCEPT
> > iptables -A FORWARD -o eth0 -p tcp --sport 4662 -j ACCEPT
> >
> > yet, when i try to telnet to it,
> >
> > mdew:~# telnet 127.0.0.1 4662
> > Trying 127.0.0.1...
> > telnet: Unable to connect to remote host: Connection refused
> >
> > Yeah I know I have lots of unnessary rules, but im only testing 'em...it
> > just seems a little strange that i cant see 4662 (Edonkey port) on the
> > router.
> >
> > -mdew
> >
> >
> Note:
> telnet 127.0.0.1 port
>
> This will not go through any of the interfaces(eth*). You should allow
> this through -i lo.
>
> Here some how you are getting connected and you are getting the response
> connection refused. Probably you are not running the service on the
> router!.
>
> --
> Dharmendra.T
> Linux Enthu
>
ok, telnet from another machine to the router.
telnet 10.0.0.6 4662
Trying 10.0.0.6...
telnet: Unable to connect to remote host: Connection refused
what "service" should I be running? I simply want 4662 open both ways.
-mdew
^ permalink raw reply
* Re: [Linux-fbdev-devel] Re: rotation.
From: Sven Luther @ 2003-01-08 12:55 UTC (permalink / raw)
To: John Bradford
Cc: Måns Rullgård, luther, geert, jsimmons,
linux-fbdev-devel, linux-kernel
In-Reply-To: <200301081205.h08C5mPv000776@darkstar.example.net>
On Wed, Jan 08, 2003 at 12:05:48PM +0000, John Bradford wrote:
> > > > > I'm about to implement rotation which is needed for devices
> > > > > like the ipaq.
> > > > > The question is do we flip the xres and yres values depending
> > > > > on the rotation or do we just alter the data that will be
> > > > > drawn to make the screen appear to rotate. How does hardware
> > > > > rotate view the x and y axis? Are they rotated or does just
> > > > > the data get rotated?
> > > >
> > > > Where are you going to implement the rotation? At the fbcon or
> > > > fbdev level?
> > > >
> > > > Fbcon has the advantage that it'll work for all frame buffer
> > > > devices.
> > >
> > > But you could also provide driver hooks for the chips which have
> > > such a rotation feature included (don't know if such exist, but i
> > > suppose they do, or may in the future).
>
> It would be nice to have an option to be able to do the rotation
> entirely in software - some desktop users might prefer to have a
> portait-orientated display, when their graphics card doesn't have any
> hardware rotation facilities at all.
Well, that is James plan. I suppose that for hardware that can do
hardware rotation, it will be faster to do it instead of having the
software do it though, and thus it would be nice to have a driver hook
or something.
This way, if rotation is asked, then if the driver supports hardware
rotation, do it, and if not, do it in software.
At first, no driver will support hardware rotation anyway, so it would
be done in software.
And then, you reuse the same stuff to drive a chinese console or
something such.
Friendly,
Sven Luther
^ permalink raw reply
* Re: Remove GIO interface
From: Maciej W. Rozycki @ 2003-01-08 12:41 UTC (permalink / raw)
To: Ladislav Michl; +Cc: linux-mips, Ralf Baechle, Guido Guenther
In-Reply-To: <20030108133013.A17162@erebor.psi.cz>
On Wed, 8 Jan 2003, Ladislav Michl wrote:
> * Even in case everything work as stated in documentation, we are unable
> to use this mechanism to detect Newport for console driver (the main
> reason why I created this interface was to provide neccessary
> informations to Xserver), because our DBE handling doesn't work until
> modules are initialized (in case we are building kernel with modules
> support).
That is a bug and it should be fixed. What are the symptoms?
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: /var/lib/nfs/sm/ files
From: Trond Myklebust @ 2003-01-08 12:46 UTC (permalink / raw)
To: Christian Reis; +Cc: NFS, linux-kernel
In-Reply-To: <20030108095050.C22321@blackjesus.async.com.br>
On Wednesday 08 January 2003 12:50, Christian Reis wrote:
> - Why don't all the diskless workstations get an entry in that
> directory while they are running? Right now I have 5 running, and
> only one has an entry there.
...because only clients that are currently holding POSIX locks will have an
entry.
> - Why do most entries' mtime get updated periodically, but a few of
> the entries go stale with time?
The file should get deleted every time the client releases all locks and
successfully manages to notify the server that it is stopping monitoring.
> - Why do some of the stale entries get left over even after the
> workstations have halted (these ones present the nfs hang issue)?
As I've told you before: 'stale' entries, as you call them, indicate that the
rpc.statd never managed to notify the server that it should stop monitoring.
It indicates either the server or the client crashed before the POSIX locks
held by the client got released, or possibly that the rpc.statd processes
crashed (or got 'kill -9' ed).
Cheers,
Trond
^ permalink raw reply
* Re: rp_filter
From: Roberto Nibali @ 2003-01-08 12:38 UTC (permalink / raw)
To: Patrick Schaaf; +Cc: Netfilter Developers
In-Reply-To: <20021228091730.GC440@oknodo.bof.de>
>> Can we *please* move the rp_filter cruft into the firewalling code
>> proper?
I agree with Patrick on that it is not an intelligent idea to touch core network
stuff in the netfilter code. Especially I seem to see more and more routing
related POM patches for netfilter while I wonder what issues people really have
with the current routing code which is where rp_filter belongs to?
> Upon thinking a bit more about your request, there is one thing
> that annoys me about rp_filter, and where iptables may eventually
> help: there was (and probably is) the idea of a DROP table, where
> you can LOG packets coming from all kinds of drop sites within
> the network stack. It would be great if I had a way to LOG packets
I've once started it but due to the network core's diversity in handling such
cases I've stopped doing it. You get everything from silent drop via kfree over
skb_free over return EINVAL over goto drop and so on ...
> rejected by rp_filter. IMHO the big problem to the unwary end-user,
> is the _invisibility_ of the drops caused by rp_filter.
That is a general nuisance and setting verbose_route_log and log_martians
already helps a bit but most of the FIB related errors don't get logged. I know
what you're talking about, I've even once started to debug tcpdump because of a
badly set rp_filter value while doing asymmetric routing in a load balanced
environment. It sucks rocks!!
> A simple net_ratelimit()ed printk() in the appropriate place, would
> already help a lot. If you walk your request over to linux-net, maybe
> you could make that your fallback position :-)
netdev or linux-net might be the best place to discuss it, yes. As a start you
could patch ../linux/net/ipv4/fib_frontend.c:fib_validate_source(). Check for
the rpf variable and follow it's invariants.
I don't agree with putting a net_ratelimit() on every network related place for
logging. I took them out in my kernels because I rather have a system that can
filter less packets but log the most packets than having a packet filter that
can filter a lot but where syslogd doesn't get enough computing time anymore to
read the printk ringbuffer.
Best regards,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
^ permalink raw reply
* Re: [parisc-linux] Visualize FX2
From: Thibaut VARENE @ 2003-01-08 12:35 UTC (permalink / raw)
To: Yves De Muyter; +Cc: parisc-linux
In-Reply-To: <20030108122009.GD16018@sithi.connected.be>
On mercredi, jan 8, 2003, at 13:20 Europe/Paris, Yves De Muyter wrote:
> Hello,
>
> I just got a C240 and i'm new to the PA-RISC architecture. It runs
> debian fine except the Visualize FX2 graphics board only works under
> sticon. What's the status of an XFree or FB driver for this card? Is
> any1 working on that?
Well, there is at the moment no support for FX cards.
Only Vis-EG are supported.
FX aren't likely to be supported soon, due to various legal problems
(patents and co).
If you want to keep that FX card, you'll have to use it with STICON...
HTH,
Thibaut VARENE
The PA/Linux ESIEE Team
http://pateam.esiee.fr/
^ permalink raw reply
* Re: [Asterisk] DTMF noise
From: David D. Hagood @ 2003-01-08 12:43 UTC (permalink / raw)
To: Thomas Tonino; +Cc: Roy Sigurd Karlsbakk, linux-kernel
In-Reply-To: <3E1BD88A.4080808@users.sf.net>
Thomas Tonino wrote:
> Roy Sigurd Karlsbakk wrote:
>
>> so - we DO NOT need a 'simplistic' DTMF decoder.
>
>
> You need a good one. But good can be simplistic, is what I'm saying.
>
> DTMF was designed to be easy to decode reliably. Complex doesn't
> automatically mean better.
>
I haven't looked at the code, but I'd recommend using a bank of Goertzel
filters -
http://www.google.com/search?hl=en&lr=&ie=ISO-8859-1&q=Goertzel+filter+DTMF&btnG=Google+Search
The basic idea is that you have 8 filters (for the 4 row and 4 column
frequencies), as well as 8 filters looking at the first harmonic of the
8 frequencies. You then compare the energies in each frequency - if you
see significant energy in the harmonic filter bank, discard the signal.
That prevents you from detecting speech as DTMF, since speech will
usually have harmonics that a good DTMF signal won't.
Since the Goertzel filters are simple, they can be implemented in fixed
point math rather than floating point. At work, we've done this on a
Motorola 56301 DSP, which is a fixed-point DSP. I think there's an app
note from Moto on this - I'll check when I get into work today.
^ 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.