* 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
* possible problems with rc6 aplay
From: patrick reardon @ 2002-12-15 21:59 UTC (permalink / raw)
To: alsa-devel
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/
^ permalink raw reply
* Re: 2.5.51: sleep broken
From: P. Christeas @ 2002-12-15 21:56 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <200212131604.23595.p_christ-U04EIuiosng@public.gmane.org>
I also noted some perculiarity in the code:
in: linux/arch/i386/kernel/acpi.c
in: acpi_reserve_bootmem(void)
...
if ((&wakeup_end - &wakeup_start) > PAGE_SIZE)
printk(KERN_CRIT "ACPI: Wakeup code way too big, will crash on
attempt to suspend (0x%8.8lx)\n",
(&wakeup_end - &wakeup_start));
--- I added the parameter to see what's happening. The message indicated an
0x3000 size. (12k)
the comment for the fn says:
* We allocate a page in low memory for the wakeup
* routine for when we come back from a sleep state. The
* runtime allocator allows specification of <16M pages, but not
* <1M pages.
Are the above lines correct? AFAIK macro PAGE_SIZE = 4096
That would mean that only <4k code is allowed. OK, but the comment suggests
otherwise...
-------------------------------------------------------
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: IDE-CD and VT8235 issue!!!
From: Patrick Petermair @ 2002-12-15 21:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Vojtech Pavlik
In-Reply-To: <20021215215057.A12689@ucw.cz>
Vojtech Pavlik:
> You're not alone with this problem. I suspect some fishy stuff in the
> vt8235, because the driver programs it exactly the same as vt8233a,
> but while the vt8233a doesn't seem to have problems with DVDs and
> CDs, the vt8235 fails for many people.
Thanks for the info ... like I expected ...
> Can you send me 'hdparm -i' of the drive?
starbase:/# hdparm -i /dev/hdc
/dev/hdc:
Model=TOSHIBA DVD-ROM SD-M1302, FwRev=1006, SerialNo=X900304741
Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=256kB, MaxMultSect=0
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 *udma2
AdvancedPM=no
Thanks for all your effort here. It's great to see such a good
community.
Patrick
^ permalink raw reply
* Re: 2.4.20 st + aic7xxx (Adaptec 19160B) + VIA KT333 repeatable freeze
From: kevin @ 2002-12-15 21:52 UTC (permalink / raw)
To: Justin T. Gibbs; +Cc: linux-kernel
In-Reply-To: <17460000.1039982505@aslan.btc.adaptec.com>
On Sun, Dec 15, 2002 at 01:01:45PM -0700, Justin T. Gibbs wrote:
> > On Fri, 13 Dec 2002 11:51:27 +1100,
> > Kevin Easton <kevin@sylandro.com> wrote:
> >> I'm not sure exactly where this problem fits in, but I'm getting a
> >> completely repeatable freeze (100% lockup, no response to keyboard)
> >> triggered by writing to /dev/st0 (dd if=/dev/urandom of=/dev/st0 bs=512
> >> count=163840 will reproduce it).
> >> So... does anyone have any ideas how I should start trying to track this
> >> down?
>
> You might also look into your BIOS to ensure that the option "PCI Byte
> Merging" is disabled. This option allows the chipset to perform illegal
> byte merging on the PCI bus that will upset the Adaptec. Since the byte
> merging will only occur in certain scenarios (heavily dependent on what
> is going on with the SCSI bus), you may only see the lockup when accessing
> a particular device or running a certain program.
>
> The latest versions of the aic7xxx and aic79xx drivers will automatically
> detect this broken VIA behavior and will fall back to using PIO for register
> access. Although I haven't generated patches against 2.4.20, you can pull
> down a src tarball for 2.4.X that should just drop in:
OK, will do - thanks. I don't think the BIOS on this board has such an
option, so I might have to put up with PIO register access.
- Kevin.
^ permalink raw reply
* Re: [PATCH] kexec for 2.5.51....
From: Ed Tomlinson @ 2002-12-15 21:41 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: linux-kernel, Greg KH
In-Reply-To: <m11y4jatbe.fsf@frodo.biederman.org>
On December 15, 2002 04:03 pm, Eric W. Biederman wrote:
> Ed Tomlinson <tomlins@cam.org> writes:
> > Why not include this info in kexec -h ? Bet it would prevent a few
> > failure reports...
>
> I will look, at that.
>
> > Two more possible additions to the kexec command.
> >
> > 1. kexec -q which returns rc=1 and types the pending selection and
> > its command/append string if one exists and returns rc=0 if nothing
> > is pending.
>
> This would require effort to little purpose. If you just call kexec
> it loads the kernel and then calls shutdown -r now. So the loaded kernel
> should be a transient entity anyway.
Consider, you are not sure what kexec has been setup to do (maybe
some other admin has something setup to take a crash dump etc). You
do not want to destroy this setup, so you do kexec -q
Think being able to query the pending kexec is very usefull. Also
using an rc means that scripts can use it too.
> > 2. kexec -c which clears any pending kernels.
>
> This I can and should do. The kernel side is already implemented.
Thanks
Ed Tomlinson
^ permalink raw reply
* Re: [LARTC] Nearly complettly victory
From: Martin Josefsson @ 2002-12-15 21:31 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-103997189019035@msgid-missing>
On Sun, 2002-12-15 at 18:02, David Coello wrote:
> Hi
>
> At last i achive to make QOS works limitting bandwidth per port but with
> one exception : ftp. I don´t know why this port doesn´t works (aplies the
> default rule not the own). Anyone has experience with a similar problem?
Do you know how ftp works?
It uses one control-connection on a static port and dynamic
data-connections. So it's only the control-connection that uses a known
port. It's the data in this control-connection that you probably are
limiting, and this is not what you want.
It is possible to mark all packets that are part of a ftp
data-connection using iptables.
iptables -t mangle -A PREROUTING -m helper --helper ftp -j MARK
--set-mark 1
This will work if you have the ip_conntrack_ftp module loaded or
compiled into your kernel. It will only work for the ports
(control-connection) which ip_conntrack_ftp has been told to listen to.
(default only port 21, change with module option 'ports')
For control-connections on port 21 you use "ftp" to match.
If it's say port 2121 and you've told ip_conntrack_ftp to listen to that
port you should use "ftp-2121" to match.
I hope this helps.
--
/Martin
Never argue with an idiot. They drag you down to their level, then beat
you with experience.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: math on variables
From: Pea Jay @ 2002-12-15 21:20 UTC (permalink / raw)
To: Stephan Sauerburger; +Cc: linux-assembly
In-Reply-To: <20021215122906.GB8507@sauerburger.org>
> mov [totalcoins],0 ;This gives an error. I just want to
> ;initialize them to 0 at beginning.
NASM needs to know what size this variable is.
mov dword [totalcoins], 0
mov [totalcoins], dword 0
Since you're doing two variables, you might want to use a register to
generate shorter code.
xor eax, eax
mov [totalcoins], eax
mov [totalvalue], eax
If you only run this function once, you can initalize them by putting
them in the .data section.
> add [totalcoins],[nickels] ;error: invalid combination of
> ;opcode and operands. Tried
You can only have one square-bracket thing per instruction, this is a
limitation of the way the instructions are encoded. So you have to use
two instructions.
You may want to forget zeroing totalcoins above, and just do this at the
end:
mov eax, [quarters]
add eax, [dimes]
add eax, [nickels]
add eax, [pennies]
mov [totalcoins], eax
(and check for overflows on the adds if that is a posibility)
> ;add value in centes to "totalvalue"
> ;(nickels are worth 5 cents, so multiply by 5 first.)
> mov eax,[nickels]
> mul eax,5 ;error: invalid combination of
> mov [nickels],eax ;opcode and operands.
Two things here. First is that the operands eax and edx are implied.
The second is that the 5 must be either a register or a memory variable.
So you should do one of these two:
mov eax, [nickels]
mov edx, 5
mul edx
mov [nickels], eax
...or, what I usually do with mul and div...
mov eax, [nickels]
mul [five] ; and somewhere have: five dd 5
mov [nickels], eax
...or, you could do this...
mov eax, 5
mul dword [nickels]
mov [nickels], eax
In all cases, eax and the specified memory or register are multiplied,
and the result is stored in edx:eax. This is because a dword can hold
up to 4294967295, and that value multiplied by itself is
18446744065119617025 which requires a quadword to store. Since you're
not using quadwords, you need to check either edx and make sure it is
zero, or before the multiplication make sure nickels is less than
858993459. If nickels won't be that large, then you can forget about
it.
> I find it odd, but I have found no information on such operations on
> variables anywhere on the web or my books. Perhaps I'm just dense.
I wouldn't be surprised if the information wasn't there. The hardest
thing about assembly language is finding information. Once you get past
that point it's pretty easy.
If you like, you can email me your questions in the future. I think
this list is meant for linux specific questions.
- peajay
^ 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 21:39 UTC (permalink / raw)
To: D.A.M. Revok; +Cc: linux-kernel
In-Reply-To: <200212151549.37661.marvin@synapse.net>
> 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.
^ permalink raw reply
* Replacing the SUSU ifcfg-{up/down}
From: Matt Young @ 2002-12-15 21:13 UTC (permalink / raw)
To: Linux Kernel Mailing List
The Suse method of bringing up the usb ethernet interface seems rather
complicated. Is there a simpler set of initiasization scripts?
^ permalink raw reply
* Re: IDE-CD and VT8235 issue!!!
From: AnonimoVeneziano @ 2002-12-15 21:16 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20021215215057.A12689@ucw.cz>
Vojtech Pavlik wrote:
>On Sun, Dec 15, 2002 at 12:55:31AM +0100, AnonimoVeneziano wrote:
>
>
>>Patrick Petermair wrote:
>>
>>
>>
>>>Hi!
>>>
>>>Same problem here. I have addressed this issue several times...so far no
>>>solution.
>>>
>>>My specs:
>>>MSI KT3 Ultra2 (VT8235)
>>>TOSHIBA DVD-ROM SD-M1302
>>>YAMAHA CRW8424E
>>>
>>>Kernel 2.4.19:
>>>The one I'm currently using. It doesn't detect the VT8235 and therefore
>>>I have no dma. But I can access/mount my DVD without a problem.
>>>
>>>Kernel 2.4.20:
>>>Detects the VT8235 at boot but hangs with my DVD Rom (hdc) --> doesn't
>>>boot. I have posted my problem here an Alan Cox suggested that I should
>>>try the -ac tree.
>>>
>>>Kernel 2.4.20-ac2:
>>>Some improvements - It detects the VT8235 at boot, also my DVD and CDRW.
>>>It boots fine and I have DMA on all my discs. But as soon as I try to
>>>mount a CD/DVD (mount /cdrom) the system hangs and I get this:
>>>
>>>
>
>
>
>>Please, anyone help us, I can't live with a 6 MB HD bandwith!!!:-D
>>
>>
>
>You're not alone with this problem. I suspect some fishy stuff in the
>vt8235, because the driver programs it exactly the same as vt8233a, but
>while the vt8233a doesn't seem to have problems with DVDs and CDs, the
>vt8235 fails for many people.
>
>It might be some new DVD drive, though.
>
>Can you send me 'hdparm -i' of the drive?
>
>I'll try to make a patch to circumvent the problem ...
>
>Thanks.
>
>
>
Here the hdparm -i of my first ATAPI drive.
I don't know if my Cd-recorder have the same problem, It have never
tried to initialize it.
Byez
/dev/hdc:
Model=_NEC DV-5800A, FwRev=1.90, SerialNo=
Config={ Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=0kB, MaxMultSect=0
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
IORDY=yes, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 *udma2
AdvancedPM=no
^ permalink raw reply
* Re: [PATCH] Add CONFIG_ACPI_RELAXED_AML option
From: Pavel Machek @ 2002-12-15 20:59 UTC (permalink / raw)
To: Moore, Robert
Cc: 'Herbert Nachtnebel', NoZizzing OrDripping,
acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Therien, Guy,
Grover, Andrew
In-Reply-To: <B9ECACBD6885D5119ADC00508B68C1EA0D19B9AB-LkGsggTGxVmSsB6bSF6DdVDQ4js95KgL@public.gmane.org>
Hi!
> I must agree that this is a really bad idea. Once we start allowing these
> kinds of errors to slip by, there is potentially no end to it. It's a very
> slippery slope that will potentially plunge everyone into the same kind of
> BIOS abyss that ACPI was intended to solve in the first place.
>
> Worse, there are situations where the AML interpreter cannot "guess" what
> the ASL/AML (BIOS) coder actually intended, i.e., there are multiple
> solutions to the problem.
>
> What is really being proposed here is for Linux ACPI to be bug-for-bug
> compatible with Microsoft. This is impossible to do deterministically
> because the MS interpreter is closed source. The only standard that we have
> that we can code to is the ACPI specification, and this has to be the last
> word on the matter.
Okay, but we can try. We can for example ignore '*PNP101' and
understand it as 'PNP101', with printk("Star is not valid character in
device name"), which is way more helpufull than /proc/battery does not
exist.
I believe CONFIG_ACPI_RELAXED_AML is good idea.
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
-------------------------------------------------------
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: [PATCH] kexec for 2.5.51....
From: Eric W. Biederman @ 2002-12-15 21:03 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: linux-kernel, Greg KH
In-Reply-To: <200212141859.07191.tomlins@cam.org>
Ed Tomlinson <tomlins@cam.org> writes:
> On December 14, 2002 02:37 pm, Eric W. Biederman wrote:
> >
> > Hurray! a bug report :)
>
> Feels good huh.
Getting new and interesting feedback is good. You can tell something
is happening if a bug report is submitted.
> > > One other datum. Without the --append line a kernel booted with kexec
> > > hangs when
> > >
> > > tring to mount the real root - it cannot find the device.
> >
> > I suspect you want to specify --append="root=/dev/xyz" when calling kexec.
>
> This helps - see below.
>
> > > Am I using kexec correctly? What else can I try? Is there any debug
> > > info I can gather?
> >
> > Generally you want to put kexec -e your shutdown scripts just before
> > the call to reboot. And then you can just say: kexec ...
> > and the you get a clean system shutdown. Dropping to run level 1
>
> Why not include this info in kexec -h ? Bet it would prevent a few
> failure reports...
I will look, at that.
> Two more possible additions to the kexec command.
>
> 1. kexec -q which returns rc=1 and types the pending selection and
> its command/append string if one exists and returns rc=0 if nothing
> is pending.
This would require effort to little purpose. If you just call kexec
it loads the kernel and then calls shutdown -r now. So the loaded kernel
should be a transient entity anyway.
> 2. kexec -c which clears any pending kernels.
This I can and should do. The kernel side is already implemented.
> > With respect to USB it is quite possible something in the USB drivers
> > does not shutdown correctly on a reboot, and the driver then has trouble
> > reinitializing the device.
>
> Very possible since I did not do an init 0/1/6 before the kexec -e. Usb
> was probably being asked to do something very unexpected...
Ideally drivers should be able to cope with this.
> > Which kernel are you booting with kexec anyway?
>
> 2.5.51 + fbcon(bk) + usb(bk) + kexec
Ah, the easy case kexec loading the same kernel that had the kexec support....
Eric
^ permalink raw reply
* Re: 2.5.51 on Alpha oopses on mount
From: Matt Reppert @ 2002-12-15 21:01 UTC (permalink / raw)
To: Richard Henderson; +Cc: linux-kernel
In-Reply-To: <20021215105722.A3831@twiddle.net>
On Sun, 15 Dec 2002 10:57:22 -0800
Richard Henderson <rth@twiddle.net> wrote:
> On Sat, Dec 14, 2002 at 12:31:55PM -0600, Matt Reppert wrote:
> > >>PC; fffffc00004a5240 <__copy_user+100/1d4> <=====
> > Trace; fffffc0000385920 <sys_mount+40/160>
>
> This fault is expected and is _supposed_ to be handled by the
> exception mechanism. Why this stopped working, I don't know.
>
> For grins, see if the following helps. It's something that I
> need for the shared-library modules anyway, and it eliminates
> an extra variable from the problem.
This seems to work, mount doesn't oops anymore. I guess this
means I can go back to trying to get the shared modules patches
to compile and boot, since this is in shared-modules-alpha.
Thanks!
Matt
^ permalink raw reply
* Re: IDE-CD and VT8235 issue!!!
From: Vojtech Pavlik @ 2002-12-15 20:50 UTC (permalink / raw)
To: AnonimoVeneziano; +Cc: linux-kernel
In-Reply-To: <3DFBC4F3.2070603@tin.it>
On Sun, Dec 15, 2002 at 12:55:31AM +0100, AnonimoVeneziano wrote:
> Patrick Petermair wrote:
>
> >Hi!
> >
> >Same problem here. I have addressed this issue several times...so far no
> >solution.
> >
> >My specs:
> >MSI KT3 Ultra2 (VT8235)
> >TOSHIBA DVD-ROM SD-M1302
> >YAMAHA CRW8424E
> >
> >Kernel 2.4.19:
> >The one I'm currently using. It doesn't detect the VT8235 and therefore
> >I have no dma. But I can access/mount my DVD without a problem.
> >
> >Kernel 2.4.20:
> >Detects the VT8235 at boot but hangs with my DVD Rom (hdc) --> doesn't
> >boot. I have posted my problem here an Alan Cox suggested that I should
> >try the -ac tree.
> >
> >Kernel 2.4.20-ac2:
> >Some improvements - It detects the VT8235 at boot, also my DVD and CDRW.
> >It boots fine and I have DMA on all my discs. But as soon as I try to
> >mount a CD/DVD (mount /cdrom) the system hangs and I get this:
> >
> Please, anyone help us, I can't live with a 6 MB HD bandwith!!!:-D
You're not alone with this problem. I suspect some fishy stuff in the
vt8235, because the driver programs it exactly the same as vt8233a, but
while the vt8233a doesn't seem to have problems with DVDs and CDs, the
vt8235 fails for many people.
It might be some new DVD drive, though.
Can you send me 'hdparm -i' of the drive?
I'll try to make a patch to circumvent the problem ...
Thanks.
--
Vojtech Pavlik
SuSE Labs
^ permalink raw reply
* 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 20:49 UTC (permalink / raw)
To: linux-kernel
( that's a capital-aye in the hdparm line )
not even the Magic SysReq key will work.
also, don't
"cd /proc/ide/hde ; cat identify"
... same thing
drive-light comes on, but have to use the power-switch to get the machine
back, ( lost stuff again, fuck )
proc says it's pdc202xx
Promise Ultra series driver Ver 1.20.0.7 2002-05-23
Adapter: Ultra100 on M/B
--
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: Machine Check Exception
From: Jan-Benedict Glaw @ 2002-12-15 20:39 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20021215202227.GA7375@codeblau.de>
[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]
On Sun, 2002-12-15 21:22:27 +0100, Felix von Leitner <felix-kernel@fefe.de>
wrote in message <20021215202227.GA7375@codeblau.de>:
> As soon as I start oggenc on my 2.5 kernel, I get this message:
>
> CPU 0: Machine Check Exception: 0000000000000004
> Bank 0: f60600000000135 at 000000001ea46db0
> Kernel panic: CPU context corrupt
>
> This vc then hangs, but I could log in and write down the message on
> another vc. Is this a hardware error? Should I replace my CPU? My
> memory? Is my machine overheating? I have had several strange and
> unexplained segfaults and reboots under 2.4 recently.
Probably you're suffering from bad RAM. Please create a memtest86 boot
floppy and try it in your own... Segfaults and reboots mostly are bad
CPU fans or bad RAM:-p
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur
fuer einen Freien Staat voll Freier Bürger" | im Internet!
Shell Script APT-Proxy: http://lug-owl.de/~jbglaw/software/ap2/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Modem Identification - Thanks
From: dashielljt @ 2002-12-15 20:29 UTC (permalink / raw)
To: Frank Roberts - SOTL; +Cc: Linux Newbie
In-Reply-To: <200212151455.13854.sotl155360@earthlink.net>
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>
On Sun, 15 Dec 2002, Frank Roberts - SOTL wrote:
Hi All
I finally got the IBM A30P Think Pad I have been working on for the last month
on line.
Getting Linux on was a bitch you people may recall all my posts concerning the
various distributions over this.
The modem has proven to be equally chalanging mainly because of lack of
information on which is the best procedure to use.
The only major outstanding item required for this box is minicom or its
replacement. Hopefully the latter as I find minicom a trite stuffy but
usable.
Thanks again for all the great help.
Frank
-
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
-
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
* RFC: p&p ipsec without authentication
From: Rik van Riel @ 2002-12-15 20:34 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
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>
^ permalink raw reply
* ext3 updates for 2.4.20
From: Andrew Morton @ 2002-12-15 20:28 UTC (permalink / raw)
To: lkml, ext3-users@redhat.com
There are three patches at
http://www.zip.com.au/~akpm/linux/patches/2.4/2.4.20/
sync_fs.patch:
Fix the ext3 data=journal data-loss-on-unmount bug
sync_fs-fix.patch:
Fix sync_fs.patch to not deadlock the fs when running
`mount -o remount' against a heavily loaded filesystem.
ext3-use-after-free.patch
Fix a use-after-free bug which can cause memory corruption
if the filesystem runs out of space, or runs out of free
inodes.
Instructions for downloading and applying these patches are at
http://www.zip.com.au/~akpm/linux/ext3/
^ permalink raw reply
* [patch] ext3 use-after-free bugfix
From: Andrew Morton @ 2002-12-15 20:26 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: lkml, ext3-users@redhat.com
A change was made to ext3 in 2.4.20-pre9 which will cause the
filesystem to run ext3_mark_inode_dirty() against a freed inode.
This will occur when an application attempts to add a new file/directory
to the filesystem and encounters space or inode exhaustion.
The results of this are unpredictable. Usually, nothing happens. But
it can cause random memory corruption on SMP, and the kernel will crash
if compiled for "debug memory allocations".
The problem is that ext3_add_nondir() will do an iput() of the inode
on error (which frees the inode) but we then run ext3_mark_inode_dirty()
against it.
Fix it so that we only run ext3_mark_inode_dirty() if the inode was
successfully instantiated.
fs/ext3/namei.c | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
--- 24/fs/ext3/namei.c~ext3-use-after-free Sun Dec 15 11:27:50 2002
+++ 24-akpm/fs/ext3/namei.c Sun Dec 15 11:27:50 2002
@@ -429,8 +429,11 @@ static int ext3_add_nondir(handle_t *han
{
int err = ext3_add_entry(handle, dentry, inode);
if (!err) {
- d_instantiate(dentry, inode);
- return 0;
+ err = ext3_mark_inode_dirty(handle, inode);
+ if (err == 0) {
+ d_instantiate(dentry, inode);
+ return 0;
+ }
}
ext3_dec_count(handle, inode);
iput(inode);
@@ -465,7 +468,6 @@ static int ext3_create (struct inode * d
inode->i_fop = &ext3_file_operations;
inode->i_mapping->a_ops = &ext3_aops;
err = ext3_add_nondir(handle, dentry, inode);
- ext3_mark_inode_dirty(handle, inode);
}
ext3_journal_stop(handle, dir);
return err;
@@ -490,7 +492,6 @@ static int ext3_mknod (struct inode * di
if (!IS_ERR(inode)) {
init_special_inode(inode, mode, rdev);
err = ext3_add_nondir(handle, dentry, inode);
- ext3_mark_inode_dirty(handle, inode);
}
ext3_journal_stop(handle, dir);
return err;
@@ -934,7 +935,6 @@ static int ext3_symlink (struct inode *
}
inode->u.ext3_i.i_disksize = inode->i_size;
err = ext3_add_nondir(handle, dentry, inode);
- ext3_mark_inode_dirty(handle, inode);
out_stop:
ext3_journal_stop(handle, dir);
return err;
@@ -971,7 +971,6 @@ static int ext3_link (struct dentry * ol
atomic_inc(&inode->i_count);
err = ext3_add_nondir(handle, dentry, inode);
- ext3_mark_inode_dirty(handle, inode);
ext3_journal_stop(handle, dir);
return err;
}
_
^ permalink raw reply
* Re: aic7xxx woes in 2.5
From: Justin T. Gibbs @ 2002-12-15 20:17 UTC (permalink / raw)
To: Ishikawa, Andrew Morton; +Cc: linux-scsi
In-Reply-To: <3DFC1BD2.F2F347C9@yk.rim.or.jp>
> Hi,
>
>> The parity error is intermittent. But when it happens, the lockup
>> always happens.
>>
>> This never happens in 2.4 kernels.
>>
>> It seems to happen a little more frequently on uniprocessor builds.
>>
>> So relevant questions would be:
>>
>> 1) Why does only 2.5 get the parity error?
>
>
> Since you say "uniprocessor builds", maybe you are using
> high-quality dual processor board. But just in case, does your
> motherboard support proper PCI parity bus check?
These are SCSI parity errors, not PCI parity errors.
--
Justin
^ permalink raw reply
* [patch] ext3 deadlock fix
From: Andrew Morton @ 2002-12-15 20:25 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: lkml
My recent fix for the ext3 data=journal umount data loss problem
has a bug. The filesystem can deadlock if someone runs `mount -o remount'
while the filesystem is under load. Everything which writes to that
filesystem gets stuck in `D' state.
This is because:
a) ext3_sync_fs() has to wait until a transaction has finished.
b) a transaction cannot finish when someone else holds lock_super().
Because lock_super() is used in the block allocator.
The patch ensures that ->sync_fs is never run under lock_super().
Documentation/filesystems/Locking | 2 ++
fs/buffer.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
--- 24/Documentation/filesystems/Locking~sync_fs-fix Sun Dec 15 11:12:48 2002
+++ 24-akpm/Documentation/filesystems/Locking Sun Dec 15 11:16:15 2002
@@ -93,6 +93,7 @@ prototypes:
void (*delete_inode) (struct inode *);
void (*put_super) (struct super_block *);
void (*write_super) (struct super_block *);
+ int (*sync_fs) (struct super_block *);
int (*statfs) (struct super_block *, struct statfs *);
int (*remount_fs) (struct super_block *, int *, char *);
void (*clear_inode) (struct inode *);
@@ -108,6 +109,7 @@ delete_inode: no
clear_inode: no
put_super: yes yes maybe (see below)
write_super: yes yes maybe (see below)
+write_super: yes no maybe (see below)
statfs: yes no no
remount_fs: yes yes maybe (see below)
umount_begin: yes no maybe (see below)
--- 24/fs/buffer.c~sync_fs-fix Sun Dec 15 11:12:48 2002
+++ 24-akpm/fs/buffer.c Sun Dec 15 11:13:13 2002
@@ -327,9 +327,9 @@ int fsync_super(struct super_block *sb)
lock_super(sb);
if (sb->s_dirt && sb->s_op && sb->s_op->write_super)
sb->s_op->write_super(sb);
+ unlock_super(sb);
if (sb->s_op && sb->s_op->sync_fs)
sb->s_op->sync_fs(sb);
- unlock_super(sb);
unlock_kernel();
return sync_buffers(dev, 1);
_
^ permalink raw reply
* Machine Check Exception
From: Felix von Leitner @ 2002-12-15 20:22 UTC (permalink / raw)
To: linux-kernel
As soon as I start oggenc on my 2.5 kernel, I get this message:
CPU 0: Machine Check Exception: 0000000000000004
Bank 0: f60600000000135 at 000000001ea46db0
Kernel panic: CPU context corrupt
This vc then hangs, but I could log in and write down the message on
another vc. Is this a hardware error? Should I replace my CPU? My
memory? Is my machine overheating? I have had several strange and
unexplained segfaults and reboots under 2.4 recently.
Felix
^ permalink raw reply
* Re: aic7xxx woes in 2.5
From: Justin T. Gibbs @ 2002-12-15 20:09 UTC (permalink / raw)
To: Andrew Morton, linux-scsi
In-Reply-To: <3DFC059A.9AA3F75F@digeo.com>
> For about six months in the 2.5 series, using aic7xxx, about every fourth
> boot one of my disks tends to get:
>
> (scsi1:A:4:0): parity-error detected in Data-in phase: SEQADDR(0x1ae)
> SCSIRATE(0x88) scsi1:0:4:0: Attempting to queue an ABORT message
>
> This is invariably fatal.
...
> This never happens in 2.4 kernels.
>
> It seems to happen a little more frequently on uniprocessor builds.
>
> So relevant questions would be:
>
> 1) Why does only 2.5 get the parity error?
Most likely different loads on your SCSI bus. The driver can't "make up"
SCSI bus parity errors.
> 2) Why does the recovery lock up?
I would actually have to know the sequencer instruction that we
are blocked on in the clear_critical_sections code to be able to
say. Several recovery bugs have been fixed in later driver versions.
> 3) Does anyone have a diff for Justin's new driver?
Just populate the scsi/aic7xxx directory with the files found
here:
http://people.FreeBSD.org/~gibbs/linux/SRC/
You will need to merge in the Kconfig and Makefile for the scsi
directory, but if you are running a fairly recent kernel, you
can just overwrite those files with those supplied in the linux-2.5
archive supplied at the above URL.
--
Justin
^ 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.