* Re: [PATCH] (4/5) improved notifier callback mechanism - read copy update
From: Vamsi Krishna S . @ 2002-12-19 12:49 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Linus Torvalds, Alan Cox, Kernel List
In-Reply-To: <1040249652.14364.192.camel@dell_ss3.pdx.osdl.net>
Hi Stephen,
On Wed, Dec 18, 2002 at 11:06:08PM +0000, Stephen Hemminger wrote:
> The notifier interface was only partially locked. The
> notifier_call_chain needs to be called in places where it is impossible
> to safely without having deadlocks; for example, NMI watchdog timeout.
>
> This patch uses read-copy-update to manage the list. One extra bit of
> safety is using a reference count on the notifier_blocks to allow for
> cases like oprofile which need to sleep in a callback.
>
<snip>
>
> int notifier_call_chain(struct list_head *list, unsigned long val, void
> *v)
> {
> - struct list_head *p;
> + struct list_head *p, *nxtp;
> int ret = NOTIFY_DONE;
>
> - list_for_each(p, list) {
> + rcu_read_lock();
> + list_for_each_safe_rcu(p, nxtp, list) {
> struct notifier_block *nb =
> list_entry(p, struct notifier_block, link);
>
> + atomic_inc(&nb->inuse);
> ret = nb->notifier_call(nb,val,v);
> + atomic_dec(&nb->inuse);
> +
There could be a small problem here. When rcu_read_lock() is called,
it bumps the preempt_count, so when the called handler attempts
to sleep, it will oops with "Bad: scheduling in atomic region".
--
Vamsi Krishna S.
Linux Technology Center,
IBM Software Lab, Bangalore.
Ph: +91 80 5044959
Internet: vamsi@in.ibm.com
^ permalink raw reply
* Re: Test program for raid
From: Gordon Henderson @ 2002-12-19 12:13 UTC (permalink / raw)
To: SCHEP. - Schepke, Arnt; +Cc: 'linux-raid@vger.kernel.org'
In-Reply-To: <984305F1827DD5118FEA0000D1105F0A01BDC0B7@HW_MAIL>
On Thu, 19 Dec 2002, SCHEP. - Schepke, Arnt wrote:
> Hi,
> just a little question: I want to test my Software-RAID1 System.
> I have some errors and want something like a one year usage in a one day
> test.
What sort of errors?
> Do you have an idea what program to use?
It depends on what you want to test ...
To test the disk system, data paths and so on, I use 'bonnie' which is a
disk benchmark program. I run about 6 or 8 of them in a loop for several
days (if possible) before making a server go live. Running more than one
is obviously no use as a benchmark, but it does seem give it it good
thrashing. The trick is to not start them at the same time, but to stagger
them - that way you get a good mix of the different operations that Bonnie
performs.
I use this:
#!/bin/sh
# /usr/local/bin/dob
dobon & sleep 120 ; dobon & sleep 120
dobon & sleep 120 ; dobon & sleep 120
dobon & sleep 120 ; dobon & sleep 120
dobon & sleep 120 ; dobon & sleep 120
And:
#!/bin/csh
# /usr/local/bin/dobon
@ n = 1
while (1)
echo Pass number $n
bonnie -s1047 -n0 -u0
@ n++
end
You many have to alter the flags to bonnie depending on what version you
use (this is for bonnie++ as supplied with Debian 3)
Make sure the filesystem has enough disk space - this will require 8GB of
disk space...
I've managed to break an IBM server raid controller with this - so much
for RAID in hardware. IBM acknowledge the fault too and are supposed to be
working on it... Don't buy IBM, stick to software raid :)
However, I recently had a Linux (s/w raid + ext2) system which would run
this all night, but FAIL on FSCK... So after running this for some time,
stop it, then umount the filesystem and run several FSCKs on it. (The
failure reason was an AMD hardware fault - cured by plugging in a PS2
mouse and compiling the mouse driver back into the kernel)
Good luck!
Gordon
^ permalink raw reply
* Re: ALSA update
From: Jaroslav Kysela @ 2002-12-19 12:18 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Ruslan U. Zakirov, Greg KH, Linux Kernel Mailing List
In-Reply-To: <s5hof7ius93.wl@alsa2.suse.de>
On Thu, 19 Dec 2002, Takashi Iwai wrote:
> At Wed, 18 Dec 2002 22:51:27 +0300 (MSK),
> Ruslan U. Zakirov <cubic@miee.ru> wrote:
> >
> > Hello, Jaroslav and All.
> > How about other changes in new 2.5 kernel, like new PnP layer (Adam Belay)
> > or changes with module & boot params (Rusty Russel)? There are now some
> > changes in 2.5.52 kernel in sound/isa/opl3sa2.c that make this driver not
> > compatible with other kernels. May be it's better split your tree in
> > several trees for each version of kernels?
>
> if possible, we'll build up some wrapper for 2.4 on alsa-driver (not
> the codebase for 2.5) tree. if not possible, yes, splitting to two
> trees would be reasonable for such big changes...
>
> thanks for noticing this issue. i'll check them now.
I just removed the complete callback redefinitions from the 2.5 tree,
but we still have three small OLD_USB sections (mainly commenting 2.5
code which 2.4 code requires to override). Hopefully, it's quite reasonable.
What do you think, Greg?
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
^ permalink raw reply
* Re: heatload 0.4 now with throttling support
From: Ducrot Bruno @ 2002-12-19 12:09 UTC (permalink / raw)
To: Malte Thoma; +Cc: Ducrot Bruno, ACPI-Devel
In-Reply-To: <3E009EB5.7010109-iYtK5bfT9M8b1SvskN2V4Q@public.gmane.org>
On Wed, Dec 18, 2002 at 05:13:41PM +0100, Malte Thoma wrote:
>
>
> Ducrot Bruno wrote:
>
> >After dpkg and heatload, get
> >Sorry can't open any of the following files:
> > /proc/acpi/thermal_zone/THRM/temperature
> > /proc/acpi/thermal/0/status
> >
> >But
> ># ls /proc/acpi/thermal_zone/
> >THM0
> >
> >
> >Please fix by parsing the entry of /proc/acpi/thermal_zone,
> >
It is exactly the same as for your /proc/acpi/thermal_zone/THRM/temperature
You can not know in advance what will be the name of
/proc/acpi/thermal_zone/THRM
The 'name' THRM is actually given by the BIOS (by the DSDT, in fact).
the only 'clean' way to go is to get the entry(ies) of
/proc/acpi/thermal_zone/
Doing something like (not tested):
char *get_the_name_of_that_damned_temp_file(void)
{
int n;
int i;
struct dirent **temp;
char *name;
static char temperature[4096]; /* OK.. we can do certainly better here via malloc.. */
n = scandir("/proc/acpi/thermal_zone", &temp, 0, alphasort);
if (n < 0) {
return NULL;
}
for (i = 0; i < n; i++) {
/* skip .* */
if ((temp[i]->d_name)[0] == '.')
continue;
name = temp[i]->d_name;
sprintf(temperature, "/proc/acpi/thermal_zone/%s/temperature", name);
free(temp);
return temperature;
}
free(temp);
return NULL;
}
It should return the first 'temperature' file for all newer release of ACPI.
For 'older', it is OK for /proc/acpi/thermal/0/temperature
Then, that file contain:
ducrot@novae:~$ cat /proc/acpi/thermal_zone/THM0/temperature
temperature: 45 C
(I must admit also that I don't know for /proc/acpi/thermal/0/temperature,
'older' way).
Cheers,
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* Re: ALSA update
From: Takashi Iwai @ 2002-12-19 12:17 UTC (permalink / raw)
To: Greg KH; +Cc: Jaroslav Kysela, Linux Kernel Mailing List
In-Reply-To: <20021218192740.GC32190@kroah.com>
At Wed, 18 Dec 2002 11:27:40 -0800,
Greg KH wrote:
>
> On Wed, Dec 18, 2002 at 08:17:55PM +0100, Jaroslav Kysela wrote:
> >
> > Not much. We have 9 #ifdef's and all trying to resolve the conflicts with
> > new function prototypes which is difficult to replace with defines or
> > inline functions. Perhaps, you'll have an idea to solve this problem.
>
> Short of keeping a 2.4 version and a 2.5/2.6 version, no, I do not have
> any ideas, sorry. The USB core has changed a lot between those two
> trees, as you know.
yep, i know :)
but it's also nice to keep the same codebase, because the test
environment of most of users is still on 2.4.
i'll do clean up the codes once when all major bugs are fixed.
Takashi
^ permalink raw reply
* [LARTC] Filter in HTB not working
From: Nestor S A Melo @ 2002-12-19 12:06 UTC (permalink / raw)
To: lartc
I have a problem in setting up HTB.
It appears filters doesn't work at all, besides "tc filter show" show it as
being correctly configured.
Class 1:10 never sent any traffic, but as iptables show below, it should be
sending packets.
The HTB version I'm using is 3.3, with kernel 2.4.17.
The setup is as follows:
---------------------------------------------------------------
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1 htb default 20 r2q 10
tc class add dev eth0 parent 1: classid 1:2 htb rate 256kbit
tc class add dev eth0 parent 1:2 classid 1:10 htb rate 26kbit ceil 128kbit
prio
1
tc qdisc add dev eth0 parent 1:10 handle 10 sfq perturb 10
tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip sport 23
0xffff classid 1:10
tc class add dev eth0 parent 1:2 classid 1:20 htb rate 220kbit ceil 256kbit
prio 2
tc qdisc add dev eth0 parent 1:20 handle 20 sfq perturb 10
---------------------------------------------------------------
The stats:
---------------------------------------------------------------
[root@NL1000 htb]# tc -s -d qdisc show
qdisc sfq 20: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb 10sec
Sent 5116 bytes 94 pkts (dropped 0, overlimits 0)
qdisc sfq 10: dev eth0 quantum 1514b limit 128p flows 128/1024 perturb 10sec
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
qdisc htb 1: dev eth0 r2q 10 default 20 direct_packets_stat 0 ver 3.6
Sent 5116 bytes 94 pkts (dropped 0, overlimits 0)
[root@NL1000 htb]# tc -s -d class show dev eth0
class htb 1:10 parent 1:2 leaf 10: prio 1 quantum 1000 rate 26Kbit ceil
128Kbit
burst 1632b/8 mpu 0b cburst 1762b/8 mpu 0b level 0
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
lended: 0 borrowed: 0 giants: 0
tokens: 401969 ctokens: 88149
class htb 1:2 root rate 256Kbit ceil 256Kbit burst 1926b/8 mpu 0b cburst
1926b/8 mpu 0b level 7
Sent 5116 bytes 94 pkts (dropped 0, overlimits 0)
lended: 0 borrowed: 0 giants: 0
tokens: 46975 ctokens: 46975
class htb 1:20 parent 1:2 leaf 20: prio 2 quantum 2816 rate 220Kbit ceil
256Kbit burst 1880b/8 mpu 0b cburst 1926b/8 mpu 0b level 0
Sent 5116 bytes 94 pkts (dropped 0, overlimits 0)
lended: 94 borrowed: 0 giants: 0
tokens: 53324 ctokens: 46975
[root@NL1000 htb]# tc -s -d filter show dev eth0
filter parent 1: protocol ip pref 100 u32
filter parent 1: protocol ip pref 100 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 100 u32 fh 800::800 order 2048 key ht 800
bkt
0 flowid 1:10
match 00170000/ffff0000 at 20
[root@NL1000 htb]# iptables -t mangle -L -nvx
Chain PREROUTING (policy ACCEPT 3590 packets, 557751 bytes)
pkts bytes target prot opt in out source
destination
0 0 MARK tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:23 MARK set 0x6
146 12954 MARK tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp spt:23 MARK set 0x6
Chain OUTPUT (policy ACCEPT 315 packets, 16936 bytes)
pkts bytes target prot opt in out source
destination
---------------------------------------------------------------
So, what is going wrong?
Thanks in advance,
--
_____________________
Nestor S A Melo
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* bug-tracking system.
From: tomasz motylewski @ 2002-12-19 12:06 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
In-Reply-To: <s5hsmwuuuss.wl@alsa2.suse.de>
On Thu, 19 Dec 2002, Takashi Iwai wrote:
> > PS: recently, new people started working on Debian's ALSA packages.
> > We'll try to forward all the bugs and patches that have piled up against
> > our packages in the previous era. What's the prefered way of reporting
> > bugs and problems against alsa packages components?
>
> please post to alsa-devel. the bug tracking system seems not working
> effectively, so far...
Do you mean SourceForge?
Don't you think it should be documented THERE?
Something like "please do not use, post reports to alsa-devel...".
It usually works like that: relatively new user/developer finds a bug, clicks
"Bug reporting" from ALSA homepage and is in a system which "seems not working
effectively".
Best regards,
--
Tomasz Motylewski
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* Mailing Canada
From: Adauto @ 2002-12-19 12:04 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/html, Size: 562 bytes --]
^ permalink raw reply
* Re: [PATCH]: remove warnings on promlib
From: Maciej W. Rozycki @ 2002-12-19 12:04 UTC (permalink / raw)
To: Juan Quintela; +Cc: linux-mips, Ralf Baechle
In-Reply-To: <m2r8cemhxt.fsf@demo.mitica>
On 19 Dec 2002, Juan Quintela wrote:
> Something like that?
Sure.
> Once there, s/vsprintf/vsnprintf/.
>
> If anybody calls prom_printf with more than 1024 chars, we were b0rked
> :((
And thanks for fixing this.
> I didn't did the changes for the other users of prom_* that was using
> asm/sgialib.h, but change is trivial.
Well, it's usually quite easy to do such stuff to offload maintainers of
the respective files. And sometimes there are ones that lack an active
maintainer but "just work". Alternatively, <asm/sgialib.h> itself might
include <asm/prom.h> to ease the transition.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: [PATCH]: make highmem only things enclosed in the right #ifdef
From: Maciej W. Rozycki @ 2002-12-19 11:59 UTC (permalink / raw)
To: Juan Quintela; +Cc: linux mips mailing list, Ralf Baechle
In-Reply-To: <m2znr2mieg.fsf@demo.mitica>
On 19 Dec 2002, Juan Quintela wrote:
> What do you think of this new one?
Well, you could remove the line below:
> sizeof(pgd_t ) * USER_PTRS_PER_PGD);
>
> - pgd_base = swapper_pg_dir;
>
> #ifdef CONFIG_HIGHMEM
but that's nitpicking (and I may fix it up if Ralf applies the patch as
is) -- I've pointed you out the problem of spacing more to bring your
attention to such details than to object this particular change. The
patch looks semantically OK.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: ALSA update
From: Takashi Iwai @ 2002-12-19 12:07 UTC (permalink / raw)
To: Ruslan U. Zakirov; +Cc: Jaroslav Kysela, Linux Kernel Mailing List
In-Reply-To: <Pine.BSF.4.05.10212182234560.25928-100000@wildrose.miee.ru>
At Wed, 18 Dec 2002 22:51:27 +0300 (MSK),
Ruslan U. Zakirov <cubic@miee.ru> wrote:
>
> Hello, Jaroslav and All.
> How about other changes in new 2.5 kernel, like new PnP layer (Adam Belay)
> or changes with module & boot params (Rusty Russel)? There are now some
> changes in 2.5.52 kernel in sound/isa/opl3sa2.c that make this driver not
> compatible with other kernels. May be it's better split your tree in
> several trees for each version of kernels?
if possible, we'll build up some wrapper for 2.4 on alsa-driver (not
the codebase for 2.5) tree. if not possible, yes, splitting to two
trees would be reasonable for such big changes...
thanks for noticing this issue. i'll check them now.
--
Takashi Iwai <tiwai@suse.de> SuSE Linux AG - www.suse.de
ALSA Developer ALSA Project - www.alsa-project.org
^ permalink raw reply
* Re: 2.4.19, don't "hdparm -I /dev/hde" if hde is on a Asus A7V133 Promise ctrlr, or...
From: Tomas Szepe @ 2002-12-19 12:03 UTC (permalink / raw)
To: Andre Hedrick; +Cc: Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.10.10212190314260.8350-100000@master.linux-ide.org>
> > > > > > So. I /think/ that somehow the Promise controller isn't being
> > > > > > initialized properly by the Linux kernel, UNLESS the mobo's BIOS
> > > > > > inits it first?
> > > > >
> > > > > In some situations yes. The BIOS does stuff including fixups we mere
> > > > > mortals arent permitted to know about.
> > > >
> > > > OTOH mere mortals are allowed to make full dump of PCI config ;)
> > > >
> > > > "D.A.M. Revok" <marvin@synapse.net>, can you send lspci -vvvxxx
> > > > outputs when you boot with BIOS enabled and BIOS disabled?
> > >
> > > Promise knows this point.
> > > Thus they moved the setting to a push/pull in the vendor space in the
> > > dma_base+1 and dma_base+3 respectively.
> > >
> > > lspci -vvvxxx fails when the content is located in bar4 io space.
> >
> > Clearly Promise is the one storage vendor whose products are best avoided.
>
> I would not say this is the case. What is going on is people are wanting
> to migrate to more of an internal hidden operation.
>
> Think about it from their side.
> They want to make it easier to program the card.
The result of their attempts has seemed to be the exact opposite
so far, so I'd say they're either hiding a bit too much or the
hardware doesn't cut it.
Anyway, what are the chances of the 2.4.21-pre PDC driver getting
fixed up so it works like it did in 2.4.18?
> Linux is an OS that like to know what is going on all the time,
> and the two clash.
Are you suggesting something to the point of Windows not having
to cope with the same issues? There has to be some kind of fundamental
difference given Promise themselves successfully hosed the Linux driver
the instant they touched it, while the Windows one just works. :)
--
Tomas Szepe <szepe@pinerecords.com>
^ permalink raw reply
* Re: [PATCH]: fix compiler warnings in the math-emulator
From: Maciej W. Rozycki @ 2002-12-19 11:52 UTC (permalink / raw)
To: Juan Quintela; +Cc: linux mips mailing list
In-Reply-To: <m28yynnes2.fsf@demo.mitica>
On 18 Dec 2002, Juan Quintela wrote:
> In the kernel for IP22 (I suppose the same for other architectures),
> it has only two Assembler warnings. And they are all in the fast
> path :(
>
> one is in entry.S:excetp_vec3_r4000
That's damn performace-critical. Thats why the VCED and VCEI handlers
are inlined there (unlike the rest) in the first place.
> and the other is in head.S:ejtag_debug_handler
That's non-critical, but I see no reason to degrade code because of
deficiencies of tools. Tools should be fixed instead.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: Test program for raid
From: Alvin Oga @ 2002-12-19 11:46 UTC (permalink / raw)
To: SCHEP. - Schepke, Arnt; +Cc: 'linux-raid@vger.kernel.org'
In-Reply-To: <984305F1827DD5118FEA0000D1105F0A01BDC0B7@HW_MAIL>
hi ya
On Thu, 19 Dec 2002, SCHEP. - Schepke, Arnt wrote:
> Hi,
> just a little question: I want to test my Software-RAID1 System.
> I have some errors and want something like a one year usage in a one day
> test.
>
> Do you have an idea what program to use?
- pull the power cord "now" .... see if the system keeps working
- pull the ide cable to disk ... see if it keeps working and boots in
degraded mode
- resync everything...
-- load up your PC with lots of jobs... say an xload of 10 or 50 ...
and see if the system dies or hangs....
- not a fair test to renice things either...
- now increase room temperature by 10C ....
- that should simulate what would be 10yr lifespan
and drop it to failur in 5 years
( whatever the normal lifespan was is cut in 1/2 for
( every 10C increase in ambient temp
- you can simulate 4 years of work in 1 year at 20C above normal
- amount of work it does ... your machine will fail long before you
hit a year's work to be tested in 1 day
- whatever it says is the MTBF on your components... divide that in half
and that might be your expected lifespan...
- no simple way to do "lifespan tests"
- other than increase room temp by +10C, +20C, +30C ...
-- just save your data daily to other "offline backup media"
as you never know when things will die
c ya
alvin
^ permalink raw reply
* Re: [PATCH]: fix compiler warnings in the math-emulator
From: Maciej W. Rozycki @ 2002-12-19 11:44 UTC (permalink / raw)
To: Juan Quintela; +Cc: linux mips mailing list, Ralf Baechle
In-Reply-To: <m2el8fnf36.fsf@demo.mitica>
On 18 Dec 2002, Juan Quintela wrote:
> maciej> A few warnings are unavoidable -- e.g. there is no way to shut up gas
> maciej> complaining about macros expanding into multiple instructions in branch
> maciej> delay slots. Too bad.
>
> I tried the
> .set nowarn
> and found it didn't work.
There is no such gas directive, but perhaps it might be added as writing
".set nomacro" before every branch may be a nuisance and obfuscate the
code unnecessarily. On the contrary ".set nowarn" should be fairly rare.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: PROBLEM: kernel 2.4.20 option CONFIG_BLK_STATS breaks /proc/partitons so "mount" can't mount devices by UUID.
From: Andries Brouwer @ 2002-12-19 11:51 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: jiri.wichern, linux-kernel
In-Reply-To: <Pine.LNX.4.50L.0212181330100.3431-100000@freak.distro.conectiva>
On Wed, Dec 18, 2002 at 01:31:44PM -0200, Marcelo Tosatti wrote:
> Could you please expand on the "sporadically" so we can inform the user in
> a better way when he should not use CONFIG_BLK_STATS ?
He should never use it.
We had extensive discussion a few months ago, and I gave you
these Bugzilla references. Maybe you were confused because this
CONFIG_BLK_STATS code also was buggy, but that is unrelated.
Older versions of mount, fdisk and also the lvmutils, fail
because they expect the original format.
Later versions of mount and fdisk - I don't know about lvmutils -
just parse the start of a line, and hence can cope with additional
stuff at the end of the line.
But there is something else. One of the problems with statistics
in /proc/partitions is that the file changes dynamically - some
statistic can go from 99 to 100 and take a position more. A program
reading it will get bad data if it reads a buffer and then the next,
and between the two reads the contents shifts.
So far two solutions have been proposed:
A user side one: Tell stdio to use a very large buffer, in the hope
that all will be read at once. (This is what RedHat does.)
And a kernel side one: Make sure the kernel generates constant
length output.
[But it is really ridiculous to put ugly hacks in lots of programs -
Why? In order to avoid changing a single filename in sar?
Break mount in order not to break sar?
I still hope you remove this garbage again.]
Andries
^ permalink raw reply
* Re: [PATCH]: make prototype of printk available
From: Maciej W. Rozycki @ 2002-12-19 11:40 UTC (permalink / raw)
To: Juan Quintela; +Cc: linux mips mailing list, Ralf Baechle
In-Reply-To: <m2of7imhkw.fsf@demo.mitica>
On 19 Dec 2002, Juan Quintela wrote:
> maciej> Why is the default log level incorrect here?
>
> The problem (not here in general), is that if printk's use the default
> log level, then you as a user has no way to raise/lower the default
> log level (i.e. the messages that you want to printk or not).
Well, the default level is KERN_WARNING and can be changed using sysctl.
Otherwise it's handled identically to explicitly tagged messages -- you
may control direct console output with the same sysctl.
Obviously there are printks that beg for an explicit tag.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: 2.4.19, don't "hdparm -I /dev/hde" if hde is on a Asus A7V133 Promise ctrlr, or...
From: Andre Hedrick @ 2002-12-19 11:45 UTC (permalink / raw)
To: Tomas Szepe; +Cc: Linux Kernel Mailing List
In-Reply-To: <20021219111450.GD17201@louise.pinerecords.com>
On Thu, 19 Dec 2002, Tomas Szepe wrote:
> > > > > So. I /think/ that somehow the Promise controller isn't being
> > > > > initialized properly by the Linux kernel, UNLESS the mobo's BIOS
> > > > > inits it first?
> > > >
> > > > In some situations yes. The BIOS does stuff including fixups we mere
> > > > mortals arent permitted to know about.
> > >
> > > OTOH mere mortals are allowed to make full dump of PCI config ;)
> > >
> > > "D.A.M. Revok" <marvin@synapse.net>, can you send lspci -vvvxxx
> > > outputs when you boot with BIOS enabled and BIOS disabled?
> >
> > Promise knows this point.
> > Thus they moved the setting to a push/pull in the vendor space in the
> > dma_base+1 and dma_base+3 respectively.
> >
> > lspci -vvvxxx fails when the content is located in bar4 io space.
>
> Clearly Promise is the one storage vendor whose products are best avoided.
I would not say this is the case. What is going on is people are wanting
to migrate to more of an internal hidden operation.
Think about it from their side.
They want to make it easier to program the card.
Linux is an OS that like to know what is going on all the time, and the
two clash.
> Andre, could you give a recommendation on what add-on IDE controllers are
> not junk hardware and will work nicely with Linux? 'Cos I can't seem to
> remember seeing anything in the shelves other than Promise or CMD64X/68X.
Hmmm...
Andre Hedrick
LAD Storage Consulting Group
^ permalink raw reply
* Re: gettimeofday() moving backwards
From: Ducrot Bruno @ 2002-12-19 11:39 UTC (permalink / raw)
To: Herbert Nachtnebel
Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
p.a.richards-Y3tGgqFSo3OFxr2TtlUqVg
In-Reply-To: <B900970C7DD9474C972986EB3EC7C58F0D404F-PWLG29+z7hEKeIAE67mlpo2P0GrZ+RbP@public.gmane.org>
On Thu, Dec 19, 2002 at 11:01:22AM +0100, Herbert Nachtnebel wrote:
> In 2.4 there exists CONFIG_ASYNC_TSC to help with such things.
Warn. Some libc are broken, and will hang. Be sure to update.
And mplayer when using win32 dll will segfault, also..
> I never tried it, but it should change the gettimeofday()
> system call to not use the TSC for time calculations. This
> results in a really slow system call since now it uses the PIT
> for every access, but the system time should be smoothly again.
ACPI timer could help, I guess.
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* Re: [ANNOUNCE] 2.5.52-lsm1
From: William Lee Irwin III @ 2002-12-19 11:42 UTC (permalink / raw)
To: linux-security-module, linux-kernel
In-Reply-To: <20021219111433.GM1922@holomorphy.com>
> On Thu, Dec 19, 2002 at 02:51:23AM -0800, Chris Wright wrote:
>> The Linux Security Modules project provides a lightweight, general
>> purpose framework for access control. The LSM interface enables
>> security policies to be developed as loadable kernel modules.
>> See http://lsm.immunix.org for more information.
>> 2.5.52-lsm1 patch released. This is a rebase up to 2.5.52 as well as
>> numerous module updates and bugfixes. The interface has changed, and
>> the hooks are controlled with CONFIG_SECURITY now. Currently LIDS and
>> DTE will not compile.
>> Full lsm-2.5 patch (LSM + all modules) is available at:
>> http://lsm.immunix.org/patches/2.5/2.5.52/patch-2.5.52-lsm1.gz
>> The whole ChangeLog for this release is at:
>> http://lsm.immunix.org/patches/2.5/2.5.52/ChangeLog-2.5.52-lsm1
>> The LSM 2.5 BK tree can be pulled from:
>> bk://lsm.bkbits.net/lsm-2.5
On Thu, Dec 19, 2002 at 03:14:33AM -0800, William Lee Irwin III wrote:
> Forgive my ignorance (if this applies) but I recently submitted a patch
My apologies. The patch (as I've heard from hch) has gone out separately.
Thanks to both gregkh and chris for rapid responses, and many apologies
from me wrt. my uninformed responses.
For the majority of -lsm users: This was an API update. No semantic
differences wrt. bugs or other issues should be visible. Thank you
for your patience, and I apologize in advance for my ignorance. Rest
assured in the fact that my changes are not critical to your security
correctness and that chris and gregkh have been thorough, diligent
and highly responsive wrt. the incorporation of this API update along
with your essential security updates.
Thanks,
Bill
^ permalink raw reply
* Re: [PATCH] arecord without timelimit produces buggy wav files.
From: Jordi Mallach @ 2002-12-19 11:35 UTC (permalink / raw)
To: alsa-devel
In-Reply-To: <s5hsmwuuuss.wl@alsa2.suse.de>
[-- Attachment #1: Type: text/plain, Size: 857 bytes --]
On Thu, Dec 19, 2002 at 12:12:19PM +0100, Takashi Iwai wrote:
> > [resent with my subscriber address... is someone moderating alsa-devel?]
> no, but it's filtered only for subscribers.
Yeah, I mean, if non-subscriber posts are not going to be moderated (ie,
make them go through manually), they should be rejected. Mailman said my
post was waiting for "moderator approval".
> > Daniel Kobras reported a bug in arecord ages ago, against
> > beta10a. Quoting:
> thanks, applied to cvs with a bit modification.
> please post to alsa-devel. the bug tracking system seems not working
> effectively, so far...
Ok, thanks.
--
Jordi Mallach Pérez -- Debian developer http://www.debian.org/
jordi@sindominio.net jordi@debian.org http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/~jordi/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Re: [Alsa-user] fm801 driver status?
From: Takashi Iwai @ 2002-12-19 11:31 UTC (permalink / raw)
To: Friedrich Ewaldt; +Cc: Thierry Vignaud, alsa-devel
In-Reply-To: <3E0077E9.9050402@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 3060 bytes --]
At Wed, 18 Dec 2002 14:28:09 +0100,
Friedrich Ewaldt wrote:
>
> Hi Takashi!
>
> Thank you very much for your work!
>
> The last patch solved the problem. No system hangs anymore. Looking
> back, I must say it was not *that* practical to reboot the system every
> time I used the audio device :-)
> The sound quality is ok (I wouldn't expect it any better with this cheap
> card). Using my impulse response program, I also recognized that the
> overall D/A + A/D latency is constant (32 samples) as expected.
good to hear that!
> (I could
> never see this before because using my cs46xx based xfire the latency
> changes in the range of 200 - 258 samples with every run. Bad - the
> xfire has much better sound quality. Is this a hint that pcm_link()
> doesn't work with cs46xx or is this maybe due to the DSP structure of
> the xfire?)
might be a chip limitation, but might be a dsp code which currently we
are using...
> Using aplay, at the end of the audio file the last played samples get
> repeated once. This doesn't happen with 'play', 'cat somefile /dev/dsp'
> or 'artsplay'. But when I cause an error beep in a shell, I first hear
> the beep and then the last samples played back before by any program
> like aplay, play, xmms,... I can reproduce this as many time as I like,
> i.e. the samples remain in the soundcard buffer all the time.
> Another issue regarding aplay: playing back mono wav with a sampling
> frequency below 44k1, the sound get's crackled. This also doesn't happen
> with the other playback programs.
hmm, this could have been a cause of the last hang-up.
the unexpected interrupt was not caught by the handler.
could you check /proc/asound/card0/pcm0p/sub0/hw_params for each case?
also, please try the attached patch (the drivers should be compiled
with --with-debug=full) and see what shown in the kernel messages.
this will print the current ply_ctrl register value.
the patch is to the latest cvs. the cvs tree already includes the
last fix and some additions for pause/release and spdif-out.
> Now I don't know if these small problems result from playing back
> through the alsa device directly or if they are caused by aplay. Sorry
> to say I've no other native alsa app installed at the moment to do tests
> (e.g. alsa output for xmms ...).
>
> Takashi wrote:
>
> >perhaps do you see something out in the kernel messages on console 10
> >(alt+f10) when the system hangs? well, after hang up, you cannot
> >switch the console, but you can start aplay on a certain
> >console, switch with alt+f10 and wait until the playback is finished.
> >
> >
> I can switch with alt+f1 .. +f6 to the consoles 1 ..6, alt+f7 is X, but
> alt+f8 and alt+f10 only show a blinking cursor at the top. Does that
> mean that there are no messages or are I'm doing something wrong? (I
> don't see any messages that I can read in /var/log/messages afterwards)
not sure, but it should depend on the configuration or the
distribution.
anyway, it doesn't matter, the problem looks almost solved :)
Takashi
[-- Attachment #2: fm801-debug.dif --]
[-- Type: application/octet-stream, Size: 866 bytes --]
Index: alsa-kernel/pci/fm801.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/pci/fm801.c,v
retrieving revision 1.25
diff -u -r1.25 fm801.c
--- alsa-kernel/pci/fm801.c 19 Dec 2002 11:22:33 -0000 1.25
+++ alsa-kernel/pci/fm801.c 19 Dec 2002 11:26:55 -0000
@@ -337,6 +337,7 @@
return -EINVAL;
}
outw(chip->ply_ctrl, FM801_REG(chip, PLY_CTRL));
+ snd_printd("trigger: ply_ctrl = 0x%x\n", chip->ply_ctrl);
spin_unlock(&chip->reg_lock);
return 0;
}
@@ -409,6 +410,7 @@
chip->ply_ctrl |= snd_fm801_rate_bits(runtime->rate) << FM801_RATE_SHIFT;
chip->ply_buf = 0;
outw(chip->ply_ctrl, FM801_REG(chip, PLY_CTRL));
+ snd_printd("prepare: ply_ctrl = 0x%x\n", chip->ply_ctrl);
outw(chip->ply_count - 1, FM801_REG(chip, PLY_COUNT));
chip->ply_buffer = runtime->dma_addr;
chip->ply_pos = 0;
^ permalink raw reply
* piix4 ide error still present in 2.4.21-pre1
From: Meelis Roos @ 2002-12-19 11:35 UTC (permalink / raw)
To: linux-kernel
The problem with mwdma2 drive attached to piix4 (430tx chipset) is still
present in 2.4.21-pre1. It no more hangs like 2.4.19 and 2.4.20 did but it
behaves like 2.4.19-ac - lots of error messages, machine stops during ide
errors or reinitialization for several seconds but recovers and error is
given to userspace. The drive works well in 2.4.18.
dmesg:
hdd: dma_timer_expiry: dma status == 0x61
hda: dma_timer_expiry: dma status == 0x61
hdd: timeout waiting for DMA
hdd: timeout waiting for DMA
hdd: (__ide_dma_test_irq) called while not waiting
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: drive not ready for command
hdd: status timeout: status=0xd0 { Busy }
hdc: DMA disabled
hdd: drive not ready for command
ide1: reset timed-out, status=0xff
hdd: dma_timer_expiry: dma status == 0x41
hdd: timeout waiting for DMA
hdd: timeout waiting for DMA
hdd: (__ide_dma_test_irq) called while not waiting
hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: drive not ready for command
hdd: status timeout: status=0xd0 { Busy }
hdd: drive not ready for command
After this line, hdd is offline an no sector is readable, read gest IO
error.
---
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: [PATCH]: make prototype of printk available
From: Maciej W. Rozycki @ 2002-12-19 11:22 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Juan Quintela, linux mips mailing list
In-Reply-To: <20021219000332.B1132@linux-mips.org>
On Thu, 19 Dec 2002, Ralf Baechle wrote:
> This is a printk that's executed if a user program is just trying to
> execute the right code, so a user could flood syslog that way. Imho the
> printk call should go away?
Indeed -- that's a report of a non-fatal exception. If unhandled, user
will get output from the default signal handler. And if diagnostics is
needed in the emulator, Dprintk or a similar solution may be used.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: [PATCH] arecord without timelimit produces buggy wav files.
From: Takashi Iwai @ 2002-12-19 11:12 UTC (permalink / raw)
To: Jordi Mallach; +Cc: alsa-devel, stevenk, madkiss
In-Reply-To: <20021218144558.GA24742@nubol.int.oskuro.net>
Hi,
At Wed, 18 Dec 2002 15:45:58 +0100,
Jordi Mallach wrote:
>
> [1 <text/plain; iso-8859-1 (quoted-printable)>]
> [resent with my subscriber address... is someone moderating alsa-devel?]
no, but it's filtered only for subscribers.
> Hello,
>
> Daniel Kobras reported a bug in arecord ages ago, against
> beta10a. Quoting:
>
> > When running arecord without timelimit (no -d option), the size of the
> > RIFF chunk in a wav file is not updated when the recording is finished.
> > The resulting wav causes trouble with some applications as the dummy
> > chunk size is negative. (Chunk sizes are spec'ed as signed integer.
> > Don't ask me why.) The following patch adds the proper fixup for the
> > RIFF chunk. Patch against version 0.9.0beta10a-2 of alsa-utils.
thanks, applied to cvs with a bit modification.
> The current Debian packages have this patch applied, and the full bug
> log is in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=131875.
>
> Thanks,
> Jordi
>
> PS: recently, new people started working on Debian's ALSA packages.
> We'll try to forward all the bugs and patches that have piled up against
> our packages in the previous era. What's the prefered way of reporting
> bugs and problems against alsa packages components?
please post to alsa-devel. the bug tracking system seems not working
effectively, so far...
--
Takashi Iwai <tiwai@suse.de> SuSE Linux AG - www.suse.de
ALSA Developer ALSA Project - www.alsa-project.org
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ 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.