* 2 (minor) Alpha probs in 2.5.51
From: Dr. David Alan Gilbert @ 2002-12-16 0:33 UTC (permalink / raw)
To: linux-kernel; +Cc: rth
(This is with rth's exception patch to fix the mount problem).
1) If compiled for the LX164 platform it is missing a number of symbols
at link time (fine if built generic):
arch/alpha/kernel/built-in.o(.data+0x3030): undefined reference to
`cia_bwx_inb'
arch/alpha/kernel/built-in.o(.data+0x3038): undefined reference to
`cia_bwx_inw'
.
.
.
(and a handful more)
2) This is a kind of subtle one. Straight after boot up if I run 'w'
or 'top' I get the warning:
Unknown HZ value! (831) Assume 1024.
This value creeps up:
Unknown HZ value! (958) Assume 1024.
over a period of a few minutes till the warning goes away.
Dave
---------------- Have a happy GNU millennium! ----------------------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
^ permalink raw reply
* gas "ljmp" instruction
From: ram @ 2002-12-16 0:22 UTC (permalink / raw)
To: linux-assembly
Hi,
I was looking at bootsect.S in the Linux sources to understand how
the boot process works and noticed the "ljmp" instruction but I can
find no documentation on it either in the Intel docs or the gas docs.
Does anyone know what it does, and more generally, is there
some documentation on the full set of x86 opcode mnemonics supported
by gas ? I'm a novice at the x86 instruction set ...
Thanks.
Ram
^ permalink raw reply
* Re: [PATCH] envy24control.[ch] update for hoontech cards.
From: Henry Walpool @ 2002-12-16 0:15 UTC (permalink / raw)
To: Jaroslav Kysela, Henry Walpool; +Cc: alsa-devel@lists.sourceforge.net
The Hoontech Media 7.1 card has a consumer/professional option at least under windows. I would assume that with the correct information from hoontech one could program this under alsa. Of course I don't have a clue, I'm just guessing here.
Thanks for the information.
--- Jaroslav Kysela <perex@suse.cz> wrote:
>On Sat, 14 Dec 2002, Henry Walpool wrote:
>
>> Added some code to block out the error messages for the hoontech cards
>> when someone tries to access the professional/consumer option. I tried
>> to get the information from hoontech but no luck. I don't think it would
>> be that hard to add the correct code to enable these functions but
>> hoontech is not talking unfortunately. Hoontech even stopped responding
>> to my e-mails. The last response I got was "e-mail the alsa-developers".
>> "They have all the information about hoontech cards already."
>
>The original hoontech cards have hardwired support (in hardware) for
>consumer mode only.
>
> Jaroslav
>
>-----
>Jaroslav Kysela <perex@suse.cz>
>Linux Kernel Sound Maintainer
>ALSA Project, SuSE Labs
_____________________________________________________________
Want a new web-based email account ? ---> http://www.firstlinux.net
_____________________________________________________________
Select your own custom email address for FREE! Get you@yourchoice.com w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: How to do -nostdinc?
From: Steffen Persvold @ 2002-12-16 0:17 UTC (permalink / raw)
To: Keith Owens; +Cc: linux-kernel
In-Reply-To: <1357.1039954001@ocs3.intra.ocs.com.au>
On Sun, 15 Dec 2002, Keith Owens wrote:
> There are two ways of setting the -nostdinc flag in the kernel Makefile :-
>
> (1) -nostdinc $(shell $(CC) -print-search-dirs | sed -ne 's/install: \(.*\)/-I \1include/gp')
> (2) -nostdinc -iwithprefix include
>
> The first format breaks with non-English locales, however the fix is trivial.
>
> (1a) -nostdinc $(shell LANG=C $(CC) -print-search-dirs | sed -ne 's/install: \(.*\)/-I \1include/gp')
>
> The second format is simpler but there have been reports that it does
> not work with some versions of gcc. I have been unable to find a
> definitive statement about which versions of gcc fail and whether the
> problem has been fixed. Anybody care to provide a definitive
> statement?
>
> If kernel build cannot rely on gcc working with -nostdinc -iwithprefix include
> then we need to convert to (1a).
Well, it works fine with gcc-2.91.66 (egcs-1.1.2 release), gcc-2.96 (RH
7.{1,2,3} versions), and gcc-3.2 (RH 8.0 version)
Of course there are other versions out there but 2.91 is rather old...
Regards,
--
Steffen Persvold | Scali AS
mailto:sp@scali.com | http://www.scali.com
Tel: (+47) 2262 8950 | Olaf Helsets vei 6
Fax: (+47) 2262 8951 | N0621 Oslo, NORWAY
^ permalink raw reply
* Re: RAM and swap partition
From: Heimo Claasen @ 2002-12-16 0:00 UTC (permalink / raw)
To: linux-newbie
Chuck - that swapfile: has it to be created anew just before any
prog/app is run ? Or could I just leave it "on" ?
Well, and then - can I conclude from this that a swap _partition_ is
basically used like a file ?
(Or else: would programs which need swap create their _specific_ files
in a swap partition ?)
-heimo
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* Re: Support for Arctic platform (405LP based)
From: Paul Mackerras @ 2002-12-15 23:43 UTC (permalink / raw)
To: Cort Dougan; +Cc: Tom Rini, linuxppc-embedded
In-Reply-To: <20021215121526.M30941@duath.fsmlabs.com>
Cort Dougan writes:
> How about killing the _2_4_devel tree? When I created it I want it to be a
> playground for stabilizing then moving things over to 2_4 failry quickly.
> It seems to have become the defacto "want board X, you better use
> _2_4_devel" tree.
Now that Marcelo is using BK, what I would really like to do is to
kill both the linuxppc_2_4 and linuxppc_2_4_devel trees and move to a
tree that is a child of Marcelo's linux-2.4 tree.
> When I went looking for a working 4xx tree recently I had to write a script
> that would go through the last year of changesets in _2_4 and _2_4_devel
> and try to build them then stick the result into a file. That ran for 7
> days on a 2.0Ghz Dual x86. Then, that only gave me a list of building
> trees. Knowing that there's only 1 tree would be much easier!
4xx in particular is a problem because I'm not convinced about the
approach that has been taken for some of the 4xx infrastructure. The
ocp stuff seems a lot more complicated than it needs to be, for
instance. There is no particular reason that I can see why the 8xx
stuff in 2_4_devel shouldn't go to Marcelo for 2.4.21.
Paul.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [2.4.20] via82cxxx goes postal and locks system, no full duplex(?)
From: Michal Jaegermann @ 2002-12-15 23:47 UTC (permalink / raw)
To: Mark Rutherford; +Cc: linux-kernel@vger.kernel.org
In-Reply-To: <3DFBFD61.1B367CD2@justirc.net>
On Sat, Dec 14, 2002 at 10:56:17PM -0500, Mark Rutherford wrote:
> I get a lot of errors, sometimes it locks the system, sometimes it does
> not.
I only can to add that I reported basically the same error sometimes
in October with respect to a kernel 2.4.18-17.8.0 used at that
time in Red Hat 8.0 distribution ( #76603 is a reference to Red Hat
bugzilla). The only difference is that it works for me 100% of
time. :-)
Initially I ascribed it mistakenly to 'gnome-session', as it tries
to play something and locks my machine with an absolute reliability,
and without any traces in logs, but in later comments I corrected
that initial impression. So far I do not know of any fixes but
sounds like the same "improvements" found its way into 2.4.20
kernel.
>
> lspci info:
> 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)
> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
>
> 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
....
> 00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686
> AC97 Audio Controller (rev 50)
I have here somewhat older hardware but in various aspects quite
similar
00:00.0 Host bridge: VIA Technologies, Inc. VT8371 [KX133] (rev 02)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8371 [KX133 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 21)
....
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686
AC97 Audio Controller (rev 20)
This is a more complete picture of my PCI bus:
-[00]-+-00.0 VIA Technologies, Inc. VT8371 [KX133]
+-01.0-[01]----00.0 Matrox Graphics, Inc. MGA G400 AGP
+-07.0 VIA Technologies, Inc. VT82C686 [Apollo Super South]
+-07.1 VIA Technologies, Inc. VT82C586B PIPC Bus Master IDE
+-07.4 VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
+-07.5 VIA Technologies, Inc. VT82C686 AC97 Audio Controller
\-09.0-[02]--+-04.0 LSI Logic / Symbios Logic 53c895
\-05.0 Digital Equipment Corporation DECchip 21142/43
Michal
^ permalink raw reply
* two thermal zones
From: Giuseppe Ciotta - @ 2002-12-15 23:38 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
hi ! i have two thermal zones on my acer 634XVI they are:
THRC THRS
what does they are respectively ?
regards
--
Giuseppe Ciotta
emacs -batch -l vmunix.el -f init
gpg key id: 0x62C77413
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: 2.4.21-pre1 broke the ide-tape driver
From: Mikael Pettersson @ 2002-12-15 23:38 UTC (permalink / raw)
To: m.c.p; +Cc: alan, linux-kernel, marcelo
On Sun, 15 Dec 2002 02:23:34 +0100, Marc-Christian Petersen wrote:
>> Kernel 2.4.21-pre1 broke the ide-tape driver: the driver
>> now hangs during initialisation. 2.2 kernels (with Andre's
>> IDE patch) and 2.4 up to 2.4.20 do not have this problem.
>> My box has a Seagate STT8000A ATAPI tape drive as hdd;
>> hdc is a Philips CD-RW, and the controller is ICH2 (i850 chipset).
>http://linux.bkbits.net:8080/linux-2.4/patch@1.828?nav=index.html|ChangeSet@-7d|cset@1.828
Addendum: this patch fixes the init-time hang, and ide-tape does
seem to work fine, but 'rmmod ide-tape' oopses -- 2.4.20-ac2 also
oopses on 'rmmod ide-tape'.
/Mikael
Unable to handle kernel NULL pointer dereference at virtual address 000000c4
d08a8048
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<d08a8048>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: 00000000 ebx: 00000000 ecx: c0241ea0 edx: 00000128
esi: 00000014 edi: d08aa9c0 ebp: bfffeb08 esp: ce825f88
ds: 0018 es: 0018 ss: 0018
Process rmmod.old (pid: 614, stackpage=ce825000)
Stack: d08a1000 fffffff0 d08a1000 c0116a53 d08a1000 fffffff0 ce7d5000 bfffeb08
c0115ef7 d08a1000 00000000 ce824000 bffffc85 00000001 c0106c17 bffffc85
08060ac8 00000100 bffffc85 00000001 bfffeb08 00000081 0000002b 0000002b
Call Trace: [<c0116a53>] [<c0115ef7>] [<c0106c17>]
Code: 8b 83 c4 00 00 00 85 c0 74 0e 68 a4 a8 8a d0 50 e8 1f ce 8d
>>EIP; d08a8048 <END_OF_CODE+8be8/????> <=====
>>ecx; c0241ea0 <chrdevs+0/7f8>
>>edi; d08aa9c0 <END_OF_CODE+b560/????>
>>ebp; bfffeb08 Before first symbol
>>esp; ce825f88 <_end+e5c4db8/10620e90>
Trace; c0116a53 <free_module+17/98>
Trace; c0115ef7 <sys_delete_module+f3/1b0>
Trace; c0106c17 <system_call+33/38>
Code; d08a8048 <END_OF_CODE+8be8/????>
00000000 <_EIP>:
Code; d08a8048 <END_OF_CODE+8be8/????> <=====
0: 8b 83 c4 00 00 00 mov 0xc4(%ebx),%eax <=====
Code; d08a804e <END_OF_CODE+8bee/????>
6: 85 c0 test %eax,%eax
Code; d08a8050 <END_OF_CODE+8bf0/????>
8: 74 0e je 18 <_EIP+0x18>
Code; d08a8052 <END_OF_CODE+8bf2/????>
a: 68 a4 a8 8a d0 push $0xd08aa8a4
Code; d08a8057 <END_OF_CODE+8bf7/????>
f: 50 push %eax
Code; d08a8058 <END_OF_CODE+8bf8/????>
10: e8 1f ce 8d 00 call 8dce34 <_EIP+0x8dce34>
^ permalink raw reply
* Re: [Oops 2.5.51] PnPBIOS: cat /proc/bus/pnp/escd
From: Paul @ 2002-12-15 23:36 UTC (permalink / raw)
To: John Bradford; +Cc: linux-kernel
In-Reply-To: <200212152339.gBFNddsV002213@darkstar.example.net>
John Bradford <john@bradfords.org.uk>, on Sun Dec 15, 2002 [11:39:38 PM] said:
> >
> > Hi;
> >
> > 'cat /proc/bus/pnp/escd' consistantly produces this:
> >
> > Paul
> > set@pobox.com
> >
> > (need any more info, just ask)
>
> Could you run that oops through ksymoops, please?
>
> John.
Hi;
Sorry, I had, but it didnt seem to add any more info
than what the kernel popped out, with all the debugging on:
Paul
set@pobox.com
ksymoops 2.4.7 on i686 2.4.20-rc2. Options used
-v ./vmlinux (specified)
-K (specified)
-L (specified)
-O (specified)
-m ./System.map (specified)
SGI XFS for Linux 2.5.51 with no debug enabled
Unable to handle kernel paging request at virtual address ffffd000
00007b74
*pde = 00001063
Oops: 0000
CPU: 0
EIP: 0088:[<00007b74>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010007
eax: 000000a0 ebx: 00a0d07b ecx: 00000400 edx: 00000000
esi: 0000d000 edi: 00000000 ebp: c31e7eb0 esp: c31e7e88
ds: 00a0 es: 0098 ss: 0068
Stack: 00000000 0090d000 00907b89 d049d4eb 00000042 00680068 0246d016 00920098
c31e7efc 0080000b 00000042 00a00098 00000090 00000000 c0217074 00000060
00000082 00000000 00000000 00000068 00000068 00000246 00000042 c31e7efc
Call Trace:
[<c0217074>] __pnp_bios_read_escd+0xf0/0x14c
[<c02170df>] pnp_bios_read_escd+0xf/0x30
[<c02180cf>] proc_read_escd+0x5f/0xf0
[<c015dab5>] proc_file_read+0xb9/0x174
[<c0138d27>] vfs_read+0xab/0x150
[<c0138ff4>] sys_read+0x28/0x3c
[<c010a7c7>] syscall_call+0x7/0xb
Code: Bad EIP value.
>>EIP; 00007b74 Before first symbol <=====
Trace; c0217074 <__pnp_bios_read_escd+f0/14c>
Trace; c02170df <pnp_bios_read_escd+f/30>
Trace; c02180cf <proc_read_escd+5f/f0>
Trace; c015dab5 <proc_file_read+b9/174>
Trace; c0138d27 <vfs_read+ab/150>
Trace; c0138ff4 <sys_read+28/3c>
Trace; c010a7c7 <syscall_call+7/b>
^ permalink raw reply
* Re: 2.4.20 smp on alpha won't boot
From: Ivan Kokshaysky @ 2002-12-15 23:35 UTC (permalink / raw)
To: Tom Vier; +Cc: linux-kernel
In-Reply-To: <20021206021638.GA357@yzero>
On Thu, Dec 05, 2002 at 09:16:38PM -0500, Tom Vier wrote:
> my dual 667mhz up2000+ will not boot 2.4.20 when compiled w/ smp support. it
> dies, killing the idle task after trying to access virt addr 0, just after
> the slab info is printed.
Can you reproduce that with 2.4.21-pre1?
If so, the oops, .config and so on are welcomed.
Ivan.
^ permalink raw reply
* Re: Modem Identification - Thanks
From: Frank Roberts - SOTL @ 2002-12-15 23:21 UTC (permalink / raw)
To: dashielljt; +Cc: Linux Newbie
In-Reply-To: <Pine.LNX.4.50.0212151527590.856-100000@athame.gmpexpress.net>
Thanks for the info.
By the way there is a Thinkpad user group and news group at:
linux-thinkpad@linux-thinkpad.org
Thanks
Frank
On Sunday 15 December 2002 15:29, dashielljt wrote:
> Well you should know that on freshmeat newsletter in the last couple days
> a package was released for the thinkpad which would allow you to program
> the thinkpad's buttons to do certain linux tasks. It's
> thinkpad_buttons-x.y.z.tar.gz I think.
>
> Jude <dashielljt(at)gmpexpress-dot-net>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* Re: [Oops 2.5.51] PnPBIOS: cat /proc/bus/pnp/escd
From: John Bradford @ 2002-12-15 23:39 UTC (permalink / raw)
To: Paul; +Cc: linux-kernel
In-Reply-To: <20021215230344.GE1432@squish.home.loc>
>
> Hi;
>
> 'cat /proc/bus/pnp/escd' consistantly produces this:
>
> Paul
> set@pobox.com
>
> (need any more info, just ask)
Could you run that oops through ksymoops, please?
John.
^ permalink raw reply
* Re: 2.4.19, don't "hdparm -I /dev/hde" if hde is on a Asus A7V133 Promise ctrlr, or...
From: John Bradford @ 2002-12-15 23:37 UTC (permalink / raw)
To: D.A.M. Revok; +Cc: linux-kernel
In-Reply-To: <200212151725.57046.marvin@synapse.net>
> man, the Magic SysReq key didn't work ( at all ):
> it were DEAD
> The drive-light stayed on for 10+ hours, nothing happening ( that I could
> figure out ) the whole time. It /stayed/ dead.
>
> /dev/hde is part of a RAID-5 in my system ( because I no longer trust
> anything else ), and this only happens on drives connected onto the
> Promise controller.
>
> Oh, yeah, I forgot to include this:
> trying to touch/activate/read the S.M.A.R.T. in any drive on the Promise
> kills it, too. Can't activate the reliability-system without killing
> the kernel? /that's/ ironic, eh?
>
>
> As for having another terminal connected to my home machine...
> 1. if the kernel's dead, then how's that gonna work, and
Maybe just the console was not responding.
If I start X with /dev/null as the core pointer, the console locks
completely, but I can still log in on a serial terminal.
I have seen machines which will mostly stop responding when you issue
a sleep command to a disk, E.G.
hdparm -Y /dev/hda
you can't terminate the process with control-C, for example, but if
you are logged in on another virtual terminal, or have another
terminal window open in X, you can reset the interface, and the
machine will respond again.
> 2. why have 2 terminals on one machine when I'm a hermit?
Why not? I read and write a lot of E-Mail on a serial terminal right
next to my main console, and what about debugging SVGALIB applications?
> I /do/ thank you for the interface-reset tip, though, I hope I never need
> that info : )
It can be useful for recovering from a spun-down disk that won't spin
up again :-)
John
^ permalink raw reply
* Re: Present rate from proc-fs
From: Chris Howells @ 2002-12-15 23:08 UTC (permalink / raw)
To: Jonas Genannt, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <200212151709.58541.jonasge-hi6Y0CQ0nG0@public.gmane.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
On Sunday 15 December 2002 16:09, Jonas Genannt wrote:
> But some notebooks (Toshiba Satellite 3000-514) does not offer the present
> rate in the proc-fs.
> My program needs the value!! How I program that I could calcualte the
> remaining time without the present rate?
>
> Or could I calcualte the present rate from the other values?
Well, you could monitor the remaining capacity, and see how long it takes to
go down and by how much.
- --
Cheers, Chris Howells -- chris-NvB7AskkBIqIudiWw5vspbVCufUGDwFn@public.gmane.org, howells@kde.org
Web: http://chrishowells.co.uk, PGP key: http://chrishowells.co.uk/pgp.txt
KDE: http://www.koffice.org, http://printing.kde.org, http://usability.kde.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE9/QtuF8Iu1zN5WiwRAgJYAKCaZ+X7pbXj7+2zmNcOT7/2rs+0+wCfYRPF
DffyEyYFZsgIAX5jbAFxzLs=
=OrdS
-----END PGP SIGNATURE-----
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* arp poisoning immunity
From: Ilya Teterin @ 2002-12-15 23:11 UTC (permalink / raw)
To: linux-kernel
Hello,
here is a patch (URL: http://securitylab.ru/_tools/antidote2.diff.gz) for
linux kernel (2.4.18 and .19 tested) to resisting ARP spoofing (improves LAN
security). Comments are welcome.
If applied, it brings a new sysctl parameter:
net.ipv4.neigh.<interface name>.arp_antidote
that defines kernel behaviour when changes in correspondence between MAC
and IP are detected.
Parameter value 0 corresponds standart behaviour, ARP cache will be
silently updated.
Value=1..3 corresponds "verification" behaviour. Kernel will send ARP
request to test if there is a host at "old" MAC address. If such
response received it lets us know than one IP pretends to have
several MAC addresses at one moment, that probably caused by ARP spoof
attack.
Value=1 - just report attack and ignore spoofing attempt.
Value=2 - ARP cache record will be marked as "static" to prevent attacks
in future.
Value=3 - ARP cache record will be marked as "banned", no data will be
delivered to attacked IP anymore, untill system administrator unban
ARP record updating it manually.
^ permalink raw reply
* [Oops 2.5.51] PnPBIOS: cat /proc/bus/pnp/escd
From: Paul @ 2002-12-15 23:03 UTC (permalink / raw)
To: Linux Kernel Mailing List
Hi;
'cat /proc/bus/pnp/escd' consistantly produces this:
Paul
set@pobox.com
(need any more info, just ask)
Unable to handle kernel paging request at virtual address ffffd000
printing eip:
00007b74
*pde = 00001063
*pte = 00000000
Oops: 0000
CPU: 0
EIP: 0088:[<00007b74>] Not tainted
EFLAGS: 00010007
EIP is at 0x7b74
eax: 000000a0 ebx: 00a0d07b ecx: 00000400 edx: 00000000
esi: 0000d000 edi: 00000000 ebp: c31e7eb0 esp: c31e7e88
ds: 00a0 es: 0098 ss: 0068
Process md5sum (pid: 25925, threadinfo=c31e6000 task=c7204640)
Stack: 00000000 0090d000 00907b89 d049d4eb 00000042 00680068 0246d016 00920098
c31e7efc 0080000b 00000042 00a00098 00000090 00000000 c0217074 00000060
00000082 00000000 00000000 00000068 00000068 00000246 00000042 c31e7efc
Call Trace:
[<c0217074>] __pnp_bios_read_escd+0xf0/0x14c
[<c02170df>] pnp_bios_read_escd+0xf/0x30
[<c02180cf>] proc_read_escd+0x5f/0xf0
[<c015dab5>] proc_file_read+0xb9/0x174
[<c0138d27>] vfs_read+0xab/0x150
[<c0138ff4>] sys_read+0x28/0x3c
[<c010a7c7>] syscall_call+0x7/0xb
Code: Bad EIP value.
<6>note: cat[25925] exited with preempt_count 1
^ permalink raw reply
* [PATCH][Netfilter]: forgotten dev_put for bridge-devices in nf_reinject() in netfilter.c
From: Bart De Schuymer @ 2002-12-15 22:40 UTC (permalink / raw)
To: David S.Miller; +Cc: Netfilter Development Mailinglist
Hello David,
The following patch was sent last Tuesday (5 days ago) on the netdev and
netfilter-devel mailing lists and I don't see it in Linus' tree yet, so I
thought I'd send it directly to you.
The patch is from Patrick McHardy <kaber@trash.net>.
The problem was caused by the bridge-netfilter patch from me. nf_queue()
dev_holds the phys{in,out}dev devices, but nf_reinject() doesn't dev_put()
them.
If this is already in your patch queue, my apologies, otherwise,
please apply,
Bart
--- linux-2.5.50/net/core/netfilter.c.orig 2002-12-10 14:16:20.000000000 +0100
+++ linux-2.5.50/net/core/netfilter.c 2002-12-10 14:19:23.000000000 +0100
@@ -574,7 +574,15 @@
/* Release those devices we held, or Alexey will kill me. */
if (info->indev) dev_put(info->indev);
if (info->outdev) dev_put(info->outdev);
-
+#if defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE)
+ if (skb->nf_bridge) {
+ if (skb->nf_bridge->physindev)
+ dev_put(skb->nf_bridge->physindev);
+ if (skb->nf_bridge->physoutdev)
+ dev_put(skb->nf_bridge->physoutdev);
+ }
+#endif
+
kfree(info);
return;
}
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Pavel Machek @ 2002-12-15 22:43 UTC (permalink / raw)
To: William Lee Irwin III, Pavel Machek, Mike Hayward, linux-kernel
In-Reply-To: <20021215223703.GA2690@holomorphy.com>
Hi!
> >> This is the same for me. I'm extremely uninterested in the P-IV for my
> >> own use because of this.
>
> > Well, then you should fix the kernel so that syscalls are done by
> > sysenter (or how is it called).
> > Pavel
>
> ABI is immutable. I actually run apps at home.
Perhaps that one killer app can be recompiled?
> sysenter is also unusable for low-level loss-of-state reasons mentioned
> elsewhere in this thread.
Well, disabling v86 may be well wroth it :-).
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: William Lee Irwin III @ 2002-12-15 22:37 UTC (permalink / raw)
To: Pavel Machek; +Cc: Mike Hayward, linux-kernel
In-Reply-To: <20021215215951.GA6347@elf.ucw.cz>
At some point in the past, I wrote:
>> This is the same for me. I'm extremely uninterested in the P-IV for my
>> own use because of this.
On Sun, Dec 15, 2002 at 10:59:51PM +0100, Pavel Machek wrote:
> Well, then you should fix the kernel so that syscalls are done by
> sysenter (or how is it called).
> Pavel
ABI is immutable. I actually run apps at home.
sysenter is also unusable for low-level loss-of-state reasons mentioned
elsewhere in this thread.
Nice try, though.
Bill
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Pavel Machek @ 2002-12-15 21:59 UTC (permalink / raw)
To: William Lee Irwin III, Mike Hayward, linux-kernel
In-Reply-To: <20021213154544.GK9882@holomorphy.com>
Hi!
> > Any ideas? Not sure I want to upgrade to the P7 architecture if this
> > is right, since for me system calls are probably more important than
> > raw cpu computational power.
>
> This is the same for me. I'm extremely uninterested in the P-IV for my
> own use because of this.
Well, then you should fix the kernel so that syscalls are done by
sysenter (or how is it called).
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Pavel Machek @ 2002-12-15 22:01 UTC (permalink / raw)
To: Albert D. Cahalan; +Cc: linux-kernel, hpa, terje.eggestad
In-Reply-To: <200212150406.gBF469M482759@saturn.cs.uml.edu>
Hi!
> > As far as I know, though, the SYSENTER patch didn't deal with several of
> > the corner cases introduced by the generally weird SYSENTER instruction
> > (such as the fact that V86 tasks can execute it despite the fact there
> > is in general no way to resume execution of the V86 task afterwards.)
> >
> > In practice this means that vsyscalls is pretty much the only sensible
> > way to do this. Also note that INT 80h will need to be supported
> > indefinitely.
> >
> > Personally, I wonder if it's worth the trouble, when x86-64 takes care
> > of the issue anyway :)
>
> There is another way:
>
> Have apps enter kernel mode via Intel's purposely undefined
> instruction, plus a few bytes of padding and identification.
> Require that this not cross a page boundry. When it faults,
> write the SYSENTER, INT 0x80, or SYSCALL as needed. Leave
> the page marked clean so it doesn't need to hit swap; if it
> gets paged in again it gets patched again.
Thats *very* dirty hack. vsyscalls seem cleaner than that.
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* Re: 2.4.19, don't "hdparm -I /dev/hde" if hde is on a Asus A7V133 Promise ctrlr, or...
From: D.A.M. Revok @ 2002-12-15 22:25 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <200212152139.gBFLdI1p002059@darkstar.example.net>
man, the Magic SysReq key didn't work ( at all ):
it were DEAD
The drive-light stayed on for 10+ hours, nothing happening ( that I could
figure out ) the whole time. It /stayed/ dead.
/dev/hde is part of a RAID-5 in my system ( because I no longer trust
anything else ), and this only happens on drives connected onto the
Promise controller.
Oh, yeah, I forgot to include this:
trying to touch/activate/read the S.M.A.R.T. in any drive on the Promise
kills it, too. Can't activate the reliability-system without killing
the kernel? /that's/ ironic, eh?
As for having another terminal connected to my home machine...
1. if the kernel's dead, then how's that gonna work, and
2. why have 2 terminals on one machine when I'm a hermit?
I /do/ thank you for the interface-reset tip, though, I hope I never need
that info : )
On Sun 15 December, 2002 16:39, you wrote:
>> have to use the power-switch to get the machine back
>
>If you have another terminal accessible, you could try:
>
>hdparm -w /dev/hda
>
>to reset the interface. I can't guarantee that it wouldn't loose
>data, though.
>
>John.
--
http://www.drawright.com/
- "The New Drawing on the Right Side of the Brain" ( Betty Edwards,
check "Theory", "Gallery", and "Exercises" )
http://www.ldonline.org/ld_indepth/iep/seven_habits.html
- "The 7 Habits of Highly Effective People" ( this site is same
principles as Covey's book )
http://www.eiconsortium.org/research/ei_theory_performance.htm
- "Working With Emotional Intelligence" ( Goleman: this link is
/revised/ theory, "Working. . . " is practical )
http://www.leadershipnow.com/leadershop/1978-5.html
- Corps Business: The 30 /Management Principles/ of the U.S. Marines (
David Freedman )
^ permalink raw reply
* Re: possible problems with rc6 aplay
From: Mark Knecht @ 2002-12-15 22:15 UTC (permalink / raw)
To: patrick reardon; +Cc: Alsa-Devel
In-Reply-To: <3DFCFB5A.9B34D27C@earthlink.net>
Patrick,
I'm not an Alsa expert so take all of this with a grain of salt. The
difference between 48K and 44.1K is indeed about a whole step, so that's
consistent with your results. You have 48000 samples that are supposed
to take one second to play, but you are taking more than one second to
play then. The result is the output tuning is low.
Since CDs are ALWAYS 44.1K, this would make sense when you burn a CD.
You could get around this by resampling the 48K input down to 44.1K.
There is some open source software for doing that.
This will change the quality of the sound a bit, and is the main
reason I always work at 44.1K.
I don't remember how to do it, but there is an option I've seen in
some .asoundrc files that allows you to set the frequency of the
Hammerfall. I have two Hammerfalls, so I suppose I had better learn to
do that one of these days.
Good luck,
Mark
On Sun, 2002-12-15 at 13:59, patrick reardon wrote:
> hi everyone:
>
> i'm running on a PIII with kernel 2.4.18 and Alsa 0.9.0rc6 and a Hammerfall 9636 card.
> Alsa has been working fine for the last year, or so it seems. recently a scsi CD burner
> was installed. i have some recordings of live performances made with "arecord", version
> 0.9.0beta8a. they play back just fine, but when i tried to burn them to CD, they were low
> by about 2 to 3 half steps.
>
> Joerg Shilling suggested that Alsa was writing the wrong headers. so i upgraded to rc6
> and on the first try on each of the old WAV files, "aplay" also played them too slowly.
> however, on subsequent runs, everything was fine again. i don't understand this behaviour
> at all.
>
> someone on LAU suggested that since it was too low by about 2-3 half steps, data was being
> recorded at 48000 but Alsa thought it was at 44100.
>
> info in /proc/asound/hammerfall/rme9652:
>
> ------------snip-------------
> .
> .
> Latency: 4096 samples (2 periods of 16384 bytes)
> Hardware pointer (frames): 0
> Passthru: no
> Clock mode: autosync
> Pref. sync source: ADAT1
>
> IEC958 input: Coaxial
> IEC958 output: Coaxial only
> IEC958 quality: Consumer
> IEC958 emphasis: off
> IEC958 Dolby: off
> IEC958 sample rate: error flag set
>
> ADAT Sample rate: 44100Hz
> .
> .
> ---------snip-----------------
>
>
> for months up until about an hour ago the ADAT sample rate read 48000. in that hour i
> changed my .asoundrc from
>
>
> -----------snip---------------
> pcm.hammerfall { #"hammerfall" is the alias for "snd-rme9652" in /etc/modules.conf
> type hw
> card0
> }
>
> ctl.hammerfall {
> type hw
> card0
> }
> -----------snip---------------
>
>
> to the following
>
>
> -----------snip---------------
>
> pcm.rme9652 { #changed from "hammerfall" to "rme9652" on 12.15.2002
> type hw
> card 0
> }
>
> ctl.rme9652 { #same as above comment
> type hw
> card 0
> }
> ---------snip-----------------
>
>
> after the .asoundrc change i recorded a fresh WAV and burned it to CD but with the same
> problem -- too slow. also, with the new .asoundrc, version rc6 plays WAV's recorded with
> the old .asoundrc and version rc6 a little too fast. i'm at a loss for new ideas to debug
> this.
>
> can anyone enlighten me about this, or does anyone know where i can download some
> reference WAV files (for example, a middle C tone) to check whether the burning problem
> might involve Alsa or whether it's something else in my setup?
>
> any pointers would be greatly appreciated.
>
> tia,
> patrick
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: RFC: p&p ipsec without authentication
From: Andrew McGregor @ 2002-12-15 21:59 UTC (permalink / raw)
To: Rik van Riel, netdev; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.50L.0212151745360.2711-100000@imladris.surriel.com>
It's not crazy at all. Perfectly practical, now that lots of people have
fast enough machines and slow enough connections that it won't drive them
mad with the performance issues :-)
Actually, it can be done (fairly) securely against MITM attacks as well.
Check out a keying protocol called HIP, most of the resources are linked to
from www.hip4inter.net.
The basic idea is that each end prove to the other that they know a private
key. The MITM protection is quite hard to describe :-)
And it can be done (at least on IPv6) with almost zero cost in time for
connections that don't support HIP, as well as only one round trip +
compute time for those that do.
There are four implementations in progress, two for linux. It would be
very nice to get the necessary hooks into the mainline kernel.
Cool, eh?
Andrew
--On Sunday, December 15, 2002 18:34:06 -0200 Rik van Riel
<riel@conectiva.com.br> wrote:
> Hi,
>
> I've got a crazy idea. I know it's not secure, but I think it'll
> add some security against certain attacks, while being non-effective
> against some others.
>
> The idea I have is letting the ipsec layer do opportunistic encryption
> even when there are no ipsec keys known for the destination address,
> ie. negotiate a key when none is in the configuration or DNS.
>
> I know this gives absolutely no protection against man-in-the-middle
> attacks (except maybe being able to detect them), but it should prevent
> passive sniffing of network traffic, as done by some governments.
>
> If this "random" encryption could be turned on with one argument to
> ip or ifconfig and millions of hosts would use it, sniffing internet
> traffic might just become impractical (or too expensive) for large
> organisations. Furthermore, even if just 0.1% of the hosts were to
> use ipsec authentication, the 3-letter agencies would be faced with
> the additional challenge of identifying which connections could safely
> be intercepted with man-in-the-middle attacks and which couldn't.
>
> Not to mention the fact that the port number on many communications
> would be invisible, vastly increasing the difficulty of doing any
> kind of statistical analysis on the traffic that's traversing the
> network.
>
> Is this idea completely crazy or only slightly ?
>
> regards,
>
> Rik
> --
> Bravely reimplemented by the knights who say "NIH".
> http://www.surriel.com/ http://guru.conectiva.com/
> Current spamtrap: <a
> href=mailto:"october@surriel.com">october@surriel.com</a> -
> 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/
>
>
^ 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.