* Re: promise (105a:3319) unattended boot
From: Joel Jaeggli @ 2004-10-15 20:27 UTC (permalink / raw)
To: Alistair John Strachan; +Cc: a.ledvinka, linux-kernel
In-Reply-To: <200410152112.18691.alistair@devzero.co.uk>
On Fri, 15 Oct 2004, Alistair John Strachan wrote:
> On Friday 15 Oct 2004 15:41, you wrote:
>> Hello.
>>
>> Got here http://pciids.sourceforge.net/iii/?i=105a3319
>> As http://linux.yyz.us/sata/faq-sata-raid.html#tx4 calls it
>> soft/accelerator raid version
>> Going to use latest kernel from /pub/linux/kernel/v2.4/
>>
>> But bios even with keyboard unplugged requires me to press one of 2 keys
>> to either define array OR continue booting in case no array is defined.
>>
>> What would you recommend me to do?
>> - stay with ft3xx module from promise and 10 level RAID array and not use
>> sata_promise?
>> - define some array in bios and completely ignore that fact and use
>> sata_promise, bypass bios and define custom linux soft raid arrays?
>
> If you define an array, AFAIK the controller doesn't do anything physically to
> the discs. It's just the settings it tells the promise driver (thus software
> RAID). If you define ANY array, the drives should still be detected by Linux
> individually and you can use linux/md to RAID them.
for sanity purposes we generally define spanned volumes each composed of
one disk. this still bites you ocasionaly because the controller will
pause when one or more disks are missing which otherwise may or may not be
catostrophic ie if you have a software raid-5 raid 1 or 10 stripe it'll
probably do fine with one disk missing, but the promise will freak again.
> This is how I'm doing it on my older PATA promise card.
>
>> - anything else (no bios flashing and no hw hacking)?
non-raid sata or pata promise cards are darn cheap...
>
>
--
--------------------------------------------------------------------------
Joel Jaeggli Unix Consulting joelja@darkwing.uoregon.edu
GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
^ permalink raw reply
* Re: absolutely baffled as to why PPP link doesn't allow pings
From: carlsonj @ 2004-10-15 20:25 UTC (permalink / raw)
To: linux-ppp
In-Reply-To: <Pine.LNX.4.60.0410151211340.11955@localhost.localdomain>
Robert P. J. Day writes:
> you are the man. i can't believe it was nothing more than turning on
> HW flow control. grrrrr .....
>
> rday
>
> p.s. but on the bright side, i know a lot more about PPP now. :-P
Good to hear that it's working.
Yes, it'd be nice if such things were easier to debug and (with better
tools) less likely to happen.
--
James Carlson <carlsonj@workingcode.com>
^ permalink raw reply
* RE: ACPI S3 resume only reboots
From: Pallipadi, Venkatesh @ 2004-10-15 20:25 UTC (permalink / raw)
To: Alberto Piai; +Cc: Li, Shaohua, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
>-----Original Message-----
>From: Alberto Piai [mailto:albeclemit-whZMOeQn8C0@public.gmane.org]
>Sent: Friday, October 15, 2004 12:41 PM
>To: Pallipadi, Venkatesh
>Cc: Li, Shaohua; acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>Subject: Re: [ACPI] ACPI S3 resume only reboots
>
>On Fri, 15 Oct 2004 06:52:57 -0700
>"Pallipadi, Venkatesh" <venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>
>> >> > From the comment in those lines, push and pop are not
>> >required for all
>> >> > platforms. Can you just comment out that push and pop and
>> >see how far
>> >> > you can go.
>> >
>> >I know it's not the most the effective way to proceed, but at
>> >least i tryed ;)
>> >I've been moving around the pushl $0 (that causes reboot) to
>> >check if the code was still executing. That's what i found.
>
>> > testl $1, video_flags - wakeup_code
>> > ### If I put pushl $0 here, it causes reboot.
>> >code is still alive.
>> > jz 1f
>> > ## pushl $0 here doesn't make reboot (hang on wakeup)
>> >
>> > lcall $0xc000,$3
>
>> Jz is jump on zero. The instructions following jz here never gets
>> executed unless you pass "acpi_sleep=s3_bios". You have to follow the
>> code to where 1: is.
>
>I followed the code until the line that makes it hang:
>[...]
>wakeup_pmode_return:
> movw $__KERNEL_DS, %ax
> movw %ax, %ss # THIS LINE
>MAKES IT HANG
> movw %ax, %ds
> movw %ax, %es
> movw %ax, %fs
> movw %ax, %gs
> movw $0x0e00 + 'u', 0xb8016
>
> # reload the gdt, as we need the full 32 bit address
> lgdt saved_gdt
> lidt saved_idt
> lldt saved_ldt
>[...]
>
>...what's happening now?
>Thanks,
>Alberto
>
I think all the experiments you are doing here are really good. I hate
to loose the history of this issue later. Can you please open a bugzilla
here (http://bugme.osdl.org) and document all the informations we have
on this until now.
Thanks,
Venki
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
^ permalink raw reply
* RE: services for predetermined IP addresses
From: Daniel Chemko @ 2004-10-15 20:25 UTC (permalink / raw)
To: kate, Jason Opperisano, netfilter
> so the drop-all would be..?
>
> iptables -A INPUT -p TCP -i eth0 -s 0/0 -j DROP
>
> or did I just invent my own thing here?
> tia
> Kate
I was just about to comment:
To drop by-by-policy, any rule that doesn't get matched earier gets
picked up by the policy rule.
You would use:
iptables -P INPUT DROP
^ permalink raw reply
* Re: [parisc-linux] "find" bug, kernel 2.6.8.1-pa11?
From: Helge Deller @ 2004-10-15 20:24 UTC (permalink / raw)
To: parisc-linux; +Cc: Thibaut VARENE
In-Reply-To: <30C87152-1EA4-11D9-B246-0030656F07A2@parisc-linux.org>
Hi Thibaut,
in case you did not apt-get updated' your machine to latest stuff, please do so.
I saw a lot of those errors with old userspace-binaries as well (e.g. even after login with ssh, or while using "screen").
Updating fixed everything.
Just an idea...
Helge
On Friday 15 October 2004 14:17, Thibaut VARENE wrote:
> Hi,
>
> Do we have some kind of bug here? See:
>
> /exports contains several NFS mountpoints:
>
> [varenet@JukeBox /exports]$ mount | grep nfs
> npyu:/Volumes/Atom/racine on /exports/npyu type nfs
> (ro,noexec,soft,nolock,rsize=8192,wsize=8192,tcp,addr=147.215.7.13)
> neko:/home/ftp/mp3_1 on /exports/neko/mp3-1 type nfs
> (ro,noexec,soft,nolock,rsize=8192,wsize=8192,addr=147.215.80.181)
>
> Now see what happens:
>
> [varenet@JukeBox /exports]$ find . > /home/varenet/playlistnow
> find: ./npyu/boxon/caprice/Metal/Royal Hunt - The watchers: Value too
> large for defined data type
> find: ./npyu/boxon/clubpc/Ziq/A5
> (Darmstadt)/Warmduscher_Vs_Overdog_-_Live_at_A5_(Darmstadt)-DAB-12-30
> -2003-OMA: Value too large for defined data type
> find: ./npyu/boxon/done/Keeper Of The Seven Keys II: Value too large
> for defined data type
> find: ./npyu/boxon/done/ROLLING STONES - Albumes 1964-1971 - CD1 de
> BaTMaN/THE ROLLING STONES - 1965 - December's Children: Value too large
> for defined data type
> find: ./npyu/boxon/samy/Vrac/pop: Value too large for defined data type
> find: ./npyu/boxon/samy/Walt Disney Phil Collins: Value too large for
> defined data type
> find: ./npyu/boxon/samy/albums/ALADDIN: Value too large for defined
> data type
> find: ./npyu/boxon/samy/albums/jah/THE selection: Value too large for
> defined data type
> find: ./npyu/boxon/samy/squarepusher: Value too large for defined data
> type
> find: ./npyu/iTunes/Benny Benassi/Hypnotica: Value too large for
> defined data type
> find: memory exhausted
>
> [varenet@JukeBox /exports]$ wc -l /home/varenet/playlistnow
> 14023 /home/varenet/playlistnow
>
> [varenet@JukeBox /exports]$ uname -a
> Linux JukeBox 2.6.8.1-pa11 #1 Sat Sep 11 19:54:13 CEST 2004 parisc
> GNU/Linux
>
> Top showed that find ate all available memory before being killed:
> 22499 varenet 25 0 257m 243m 1584 R 65.4 64.6 2:12.61 find
>
> That box has 492MB RAM, it's a B132L+, running sarge.
>
> /exports has more than 60000 files, representing about 200GB of data.
>
> running find on one of the origin folders (the biggest actually) on the
> NFS server host shows:
>
> [varenet@npyu /Volumes/Atom]$ find racine/ | wc -l
> 48867
>
> (npyu is an OSX box, fwiw).
>
> HTH,
>
> Thibaut VARENE
> The PA/Linux ESIEE Team
> http://www.pateam.org/
>
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
>
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply
* Re: Generic VESA framebuffer driver and Video card BOOT?
From: Jon Smirl @ 2004-10-15 20:19 UTC (permalink / raw)
To: Kendall Bennett; +Cc: Alan Cox, Linux Kernel Mailing List, fbdev
In-Reply-To: <416FB275.6425.1C3D985@localhost>
On Fri, 15 Oct 2004 11:20:21 -0700, Kendall Bennett
<kendallb@scitechsoft.com> wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> > On Iau, 2004-10-14 at 21:46, Kendall Bennett wrote:
> > > a way to spawn a user mode process that early in the boot sequence (it
> > > would have to come from the initrd image I expect) then the only option
> > > is to compile it into the kernel.
> >
> > There is exactly that in 2.6 - the hotplug interfaces allow the
> > kernel to fire off userspace programs. Jon Smirl (who you should
> > definitely talk to about this stuff) has been hammering out a
> > design for moving almost all the mode switching into user space for
> > kernel video.
>
> That is awesome! I am all for moving this outside of the kernel, as it
> would allow the use of ream vm86() services for VGA/VESA BIOS access on
> x86 and the user of the emulator for non-x86 platforms.
>
> The only catch would be making sure this stuff is available really early
> in the boot sequence. As it stands right now the solution we have brings
> up the video almost imediately after you see the 'uncompressing kernel
> image' message on the serial port. The other solution of course is to get
> this into the boot loader which is what the AmigaOne folks did for their
> machines (U-Boot brings up the video). We are working with those guys to
> update their BIOS emulator to the latest version as the one they have
> doesn't work that reliably.
>
> Anyway how do I find out more about this in 2.6?
>
> Also I assume the code would need to end up in the initrg image, correct?
> Can you point me at some resources to learn more about how to get custom
> code into the initrd image?
The plan for this in 2.6 is to first write a VGA device driver. This
driver is responsible for identifying all of the VGA devices in a
system and ensuring only one of them gets enabled a time. I started
writing this but I haven't finished. This driver would be compiled
into the kernel. I can send source if you are interested.
I have added hooks to the PCI subsystem to record the boot video
device. If the VGA driver finds VGA devices other than the boot one it
will generate hotplug events on them. Initramfs should contain a reset
program for using X86 mode to reset these cards. To do this you need
two things from the kernel: 1) a way to make sure only a single VGA
device is active (VGA driver, allow you to disable the current VGA
device, reset the card, restore the active VGA device) and 2) a way to
get the ROM image. There is a patch in -mm that makes the ROMs visible
in sysfs that should be in the kernel shortly.
So, when you first boot you have two choices, 1) use a display the
boot ROM setup, such as VGAcon or PROMcon. or 2) have no display.
People want this both ways. VGAcon/PROMcon will let you get output
very early in the boot process.
Next the VGA driver will initialize. This will trigger user space
resets using the program on initramfs. Now it is possible to use all
of your displays. To control this from something like resume, the
driver sets a lock that is cleared by the reset app and the end of
reset. This will keep other processes out of the driver until reset is
finished.
Right now I am working on a merged fbdev/DRM that supports multi-head
adapters. It's turning out to be much more work than I though because
neither DRM or fbdev handle multihead at the device driver level. You
can get snapshots of the code at mesa3d.bkbits.net but it doesn't work
right yet. This driver is designed to run after the VGAdriver has
reset the hardware.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* RFC: hotplug & libata.
From: Andy Warner @ 2004-10-15 20:16 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide@vger.kernel.org
I've spent time over the last 10 days or so working
through hotplug issues with libata and am coming round
to the position that the current __init/probe mechanism
may need some reorganisation for hotplug to work well.
I can currently (mostly) hotplug SATA drives that were
present at __init/probe all day long; but things
are less good for drives which were not present
at __init/probe.
If it's not there at __init/probe time, the groundwork
isn't in place to add devices later without some fairly
nasty & repetitious code. I keep coming back to a model
where the host adapter ports are initialised, then the
initial drive scan & addition is effectively a hot-plug
event (either automatic or forced, depending on hardware
capabilities.)
Unfortunately, I fear that any impending PATA/libata
train-wreck may conflict with this, due to the behaviour
of some (many) of the PATA chipsets out there (e.g.
misbehaving seriously when no active devices are attached
to the bus etc.)
Anyone have thoughts/advice to share on this concept? I think
the re-org may be quite intrusive, and I don't want to waste
cycles on something that "would never work with PATA, because
of blah, blah, blah.."
--
andyw@pobox.com
Andy Warner Voice: (612) 801-8549 Fax: (208) 575-5634
^ permalink raw reply
* [ALSA - driver 0000583]: xruns when playing audio or video files
From: bugtrack @ 2004-10-15 20:17 UTC (permalink / raw)
To: alsa-devel
A BUGNOTE has been added to this bug.
======================================================================
https://bugtrack.alsa-project.org/alsa-bug/bug_view_page.php?bug_id=0000583
======================================================================
Reported By: KAtiOS
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Bug ID: 583
Category: PCI - atiixp
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution: Gentoo Linux
Kernel Version: 2.6.9_rc4
======================================================================
Date Submitted: 10-15-2004 16:27 CEST
Last Modified: 10-15-2004 22:17 CEST
======================================================================
Summary: xruns when playing audio or video files
Description:
I get xruns when playing files.
I tested with lots of 2.6 kernels, up to 2.6.9_rc4 with the same results.
It seems that mplayer with sdl output works fine, but xruns with alsa.
Using acpi=off or pci=noacpi helps in mplayer but not in vdr (with
softdevice plugin - using alsa).
======================================================================
----------------------------------------------------------------------
lee - 10-15-2004 18:43 CEST
----------------------------------------------------------------------
This is a kernel issue, not an ALSA bug. If you want xrun-free operation
you HAVE to use a kernel patched for low latency. Please close this bug.
----------------------------------------------------------------------
KAtiOS - 10-15-2004 18:51 CEST
----------------------------------------------------------------------
Since when a low latency [so.. patched] kernel is needed to listen to music
and play video correctly?
Given that the processor isn't particulary weak and that's the only task
of the system, it shouldn't be hard to keep pace.
----------------------------------------------------------------------
lee - 10-15-2004 19:02 CEST
----------------------------------------------------------------------
OK, you are right, you should not need to patch the kernel to avoid massive
xruns with regular AV playback. The reason I say it's a kernel issue is
that disabling ACPI seems to fix the problem.
Do you get fewer xruns if you disable xrun debugging? This can cause a
cascade effect where a single xrun triggers hundreds of them due to printk
overhrad.
Also, does it work OK with a 2.4 kernel?
----------------------------------------------------------------------
KAtiOS - 10-15-2004 19:12 CEST
----------------------------------------------------------------------
Disabling ACPI seems to help with mplayer, but mplayer causes troubles only
a few times in the duration of a music, whereas VDR got several xruns a
second, whether ACPI is disabled or not.
I tried with xrun debugging desactived but VDR acts the same (visibly at
least).
I haven't used a 2.4 in months, would it helped it I tried with one?
----------------------------------------------------------------------
KAtiOS - 10-15-2004 19:24 CEST
----------------------------------------------------------------------
Also note that I tried in the past with and without preempt without making
a major difference that I can still think of.
(preemp activated right now btw)
----------------------------------------------------------------------
lee - 10-15-2004 19:29 CEST
----------------------------------------------------------------------
I get the occasional xrun with mplayer even with the latest 2.6 low latency
kernels. I figure it's a bug in mplayer's ALSA support. VDR I don't
know. Do other users of that program report the same issue?
There are many, many apps out there with buggy ALSA support but good OSS
support. Try a known good app like aplay or alsaplayer.
----------------------------------------------------------------------
KAtiOS - 10-15-2004 20:28 CEST
----------------------------------------------------------------------
Humm.. yes but since mplayer seems to be working ok with audio files, I
don't think alsaplayer will help.
I just tested, I have xrun with a video played with mplayer (acpi off)
Any video player I could test?
----------------------------------------------------------------------
lee - 10-15-2004 22:17 CEST
----------------------------------------------------------------------
If audio plays back OK but AV playback causes xruns, then this cannot be an
ALSA issue. Mplayer's ALSA support is known to be buggy. I am not sure
there is a video player with known good ALSA support. You might want to
ask on the alsa-user list.
Bug History
Date Modified Username Field Change
======================================================================
10-15-04 16:27 KAtiOS New Bug
10-15-04 16:27 KAtiOS Distribution => Gentoo Linux
10-15-04 16:27 KAtiOS Kernel Version => 2.6.9_rc4
10-15-04 18:43 lee Bugnote Added: 0002168
10-15-04 18:51 KAtiOS Bugnote Added: 0002169
10-15-04 19:02 lee Bugnote Added: 0002170
10-15-04 19:12 KAtiOS Bugnote Added: 0002171
10-15-04 19:24 KAtiOS Bugnote Added: 0002172
10-15-04 19:29 lee Bugnote Added: 0002173
10-15-04 20:28 KAtiOS Bugnote Added: 0002174
10-15-04 22:17 lee Bugnote Added: 0002175
======================================================================
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
^ permalink raw reply
* Re: Fw: signed kernel modules?
From: Tonnerre @ 2004-10-15 20:11 UTC (permalink / raw)
To: Josh Boyer
Cc: root, gene.heskett, linux-kernel, Roman Zippel, David Howells,
Rusty Russell (IBM), David Woodhouse, Greg KH, Arjan van de Ven,
Joy Latten
In-Reply-To: <1097862366.29988.51.camel@weaponx.rchland.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1489 bytes --]
Salut,
On Fri, Oct 15, 2004 at 12:46:06PM -0500, Josh Boyer wrote:
> I'd disagree. Do you consider SELinux to be policy as well just because
> it's in the kernel?
>
> As David said in his response, it's a mechanism. Whether _you_ choose
> to use it or not decides the "policy". That's why I said put a config
> option around it. You would still have _choice_.
Actually, even though I agree that Richard is overdramatizing, his
point is not completely invalid. Remembering the trusted computing
initiative, it's always a question of who holds the keys to your
computer. In our case it's no problem, since we compile all the
software on the computer ourselves, and thus we have full control over
what we do.
What trusted computing revealed is that there is at least amongst some
companies a desire to be able to dictate what's going on on your
computer. Think Disney here.
Sure, TCPA is dead. But I've seen a TPM chip. On an Intel test board.
IBM has them as well. I agree that we can trust all these entities
now. But what's going to happen ten years from now? We don't know.
I'm not proclaiming paranoia. I don't say we should burn this patch
alive. I only say that from time to time we have to take care of not
getting to the Wernher von Braun excuse.
Tonnerre
PS. I did a module signing patch some years ago. I did a framework. I
did tests. I got scared of its power. All I say is, take care.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: services for predetermined IP addresses
From: kate @ 2004-10-15 20:14 UTC (permalink / raw)
To: Jason Opperisano, netfilter
In-Reply-To: <20041015200157.GA7982@bender.817west.com>
--- Jason Opperisano <opie@817west.com> wrote:
> On Fri, Oct 15, 2004 at 12:41:15PM -0700, kate
> wrote:
> > Hello,
> >
> > As I see increased scans on my IP address, I want
> to
> > limit access to only predetermined IP address
> ranges
> > for certain services - Is the following the
> correct
> > way to do this?
> >
> > <snip>
> > # (Part A) Rules for incoming packets from
> Internet
> > # Packets for established connections
> > iptables -A INPUT -p ALL -d $ETH0_IP -m state
> --state
> > ESTABLISHED,RELATED -j ACCEPT
>
> stylistic note: the "-p ALL" is kinda
> unnecessary...
>
> > # (Part B) TCP Rules
> > iptables -A INPUT -p TCP -i eth0 -s 123.45.1.1
> > --destination-port 21 -j okay # userA
> > iptables -A INPUT -p TCP -i eth0 -s 123.45.0/16
> > --destination-port 22 -j okay #users A - Z
>
> i think you're missing a "0" there: 123.45.0/16
> should really be
> 123.45.0.0/16.
>
> > </snip>
> >
> > So I understand -
> > ONLY User A can ftp, and all those in 123.45. can
> ssh
> > , BUT no-one else on the Internet can request
> services
> > ?
>
> yes--as along as somewhere further down the chain
> you hit a drop-all
> rule of some sort...
Yes, I see that now...
# (Part B) TCP Rules
iptables -A INPUT -p TCP -i eth0 -s 123.45.1.1
--destination-port 21 -j okay # userA
iptables -A INPUT -p TCP -i eth0 -s 123.45.0.0/16
--destination-port 22 -j okay #users A - Z
so the drop-all would be..?
iptables -A INPUT -p TCP -i eth0 -s 0/0 -j DROP
or did I just invent my own thing here?
tia
Kate
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
^ permalink raw reply
* Re: promise (105a:3319) unattended boot
From: Alistair John Strachan @ 2004-10-15 20:12 UTC (permalink / raw)
To: a.ledvinka; +Cc: linux-kernel
In-Reply-To: <OF77D5B4E1.A38CC6EC-ONC1256F2E.004E78A5-C1256F2E.0050B72C@promon.cz>
On Friday 15 Oct 2004 15:41, you wrote:
> Hello.
>
> Got here http://pciids.sourceforge.net/iii/?i=105a3319
> As http://linux.yyz.us/sata/faq-sata-raid.html#tx4 calls it
> soft/accelerator raid version
> Going to use latest kernel from /pub/linux/kernel/v2.4/
>
> But bios even with keyboard unplugged requires me to press one of 2 keys
> to either define array OR continue booting in case no array is defined.
>
> What would you recommend me to do?
> - stay with ft3xx module from promise and 10 level RAID array and not use
> sata_promise?
> - define some array in bios and completely ignore that fact and use
> sata_promise, bypass bios and define custom linux soft raid arrays?
If you define an array, AFAIK the controller doesn't do anything physically to
the discs. It's just the settings it tells the promise driver (thus software
RAID). If you define ANY array, the drives should still be detected by Linux
individually and you can use linux/md to RAID them.
This is how I'm doing it on my older PATA promise card.
> - anything else (no bios flashing and no hw hacking)?
>
--
Cheers,
Alistair.
personal: alistair()devzero!co!uk
university: s0348365()sms!ed!ac!uk
student: CS/AI Undergraduate
contact: 1F2 55 South Clerk Street,
Edinburgh. EH8 9PP.
^ permalink raw reply
* Re: Memory leak in 2.4.27 kernel, using mmap raw packet sockets
From: Marcelo Tosatti @ 2004-10-15 18:23 UTC (permalink / raw)
To: bgagnon; +Cc: linux-kernel
In-Reply-To: <OFDDC77A23.4D34536B-ON85256F2D.00514F15-85256F2D.00517F52@coradiant.com>
On Thu, Oct 14, 2004 at 10:50:14AM -0400, bgagnon@coradiant.com wrote:
> (Please cc me directly, since I am not a subscriber to this list)
>
> Hi,
>
> I discovered a memory leak in the mmap raw packet socket implementation,
> specifically when the client application core dumps (elf format). More
> specifically, the entire ring buffer memory leaks under such
> circumstances. I have reproduced the problem with our custom app, which
> links with Phil Wood's mmap version of libpcap (
> http://plublic.lanl.gov/cpw) as well as with tcpdump binding against the
> same library. I have asserted the problem presence in kernels 2.4.26 and
> 2.4.27. It has been resolved in kernel 2.6.8.
>
> In a nutshell, the reference count of the ring buffer page frame is not
> handled properly by the core dump function elf_core_dump() in
> fs/binfmt_elf.c. After exiting this function, all ring buffer page frames
> reference counts have been increased by one, which impedes their release
> when the socket is closed.
>
> The reference count mishap is related to the fact that the ring buffer
> page frames have their PG_reserved bit set when they are created by the
> raw packet socket. According to the comments in mm.h, this is to ensure
> the pages don't get swapped out to disk. elf_core_dump() calls
> get_user_pages(), which increments the reference count, irrespective of
> the PG_reserved bit, while the subsequent put_page() call only decrements
> it if the PG_reserved bit is clear.
>
> According to a similar kernel mailing list thread (
> http://www.ussg.iu.edu/hypermail/linux/kernel/0311.3/0495.html), the page
> reference count field is not significant if the PG_reserved bit is set.
> Applied to our particular case, the raw packet socket implementation
> should unconditionally reset the reference count when the socket is
> closed, so that the memory gets released. However, I fear this would cause
> user space applications to crash: according to the mmap man page, the
> memory mapping should survive the socket closure:
>
> "The munmap system call deletes the mappings for the specified address
> range, and causes further references to addresses within the range to
> generate invalid memory references. The region is also automatically
> unmapped when the process is terminated. On the other hand, closing
> the file descriptor does not unmap the region."
>
> So, on 2.4 kernels, we are facing the following situation:
>
> 1- The reference count information IS important to control the ring buffer
> lifetime
> 2- The PG_reserved bit causes the reference count not to be handled
> properly by different kernel subsystems, the core dump functions being one
> of them
>
> >From what I could understand, 2.6 developer fixed the get_user_pages()
> code so it does not increment to reference count if the page has the
> PG_reserved bit set. I don't know if this is readily applicable to 2.4
> kernels, since it may break some other subsystem that rely on its current
> behavior.
>
> So, unless a better solution is found, I would propose a localized fix for
> the leak, in function elf_core_dump(), starting at line 1275 (comments
> are my own) :
>
> if (get_user_pages(current, current->mm, addr, 1, 0, 1, /*BG: this
> ALWAYS will increment the ref count*/
> &page, &vma) <= 0) {
> DUMP_SEEK (file->f_pos + PAGE_SIZE);
> } else {
> if (page == ZERO_PAGE(addr)) {
> DUMP_SEEK (file->f_pos + PAGE_SIZE);
> } else {
> void *kaddr;
> flush_cache_page(vma, addr);
> kaddr = kmap(page);
> DUMP_WRITE(kaddr, PAGE_SIZE);
> flush_page_to_ram(page);
> kunmap(page);
> }
> /*BG: Start of fix*/
> if (PageReserved(page))
> /* BG: just undo the ref count increase done in
> get_user_pages*/
> put_page_testzero(page);
> else
> put_page(page);
> /*BG: end of fix */
> }
Hi Bernand,
I prefer doing the "if (PageReserved(page)) put_page_testzero(page)" as
you propose instead of changing get_user_pages(), as there are several
users which rely on its behaviour.
I have applied your fix to the 2.4 BK tree.
Thanks.
^ permalink raw reply
* RE: [Patch 12/16 2.5] ixgb: replace kmalloc with vmalloc to allocate driver local data structures
From: Venkatesan, Ganesh @ 2004-10-15 20:10 UTC (permalink / raw)
To: Christian Borntraeger; +Cc: jgarzik, netdev
Kmalloc resources are more scarce than vmalloc. In this case, there are
systems where allocation of [rt]xdr->buffer_info fails when the
descriptor ring sizes are set to the maximum allowable value (4096) and
kmalloc is used. Using vmalloc solves this issue.
Ganesh.
-----Original Message-----
From: Christian Borntraeger [mailto:linux-kernel@borntraeger.net]
Sent: Friday, October 15, 2004 9:47 AM
To: Venkatesan, Ganesh
Cc: jgarzik@pobox.com; netdev
Subject: Re: [Patch 12/16 2.5] ixgb: replace kmalloc with vmalloc to
allocate driver local data structures
Ganesh Venkatesan wrote:
> - rxdr->buffer_info = kmalloc(size, GFP_KERNEL);
[...]
> + rxdr->buffer_info = vmalloc(size);
What is the rationale for this change?
If I recall correctly, Linus opposes the use of vmalloc if there is no
real
need.
cheers
Christian
^ permalink raw reply
* Re: strange delays in vc class
From: Kay Sievers @ 2004-10-15 20:09 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20041015000446.GA2796@vrfy.org>
On Fri, Oct 15, 2004 at 09:18:26PM +0200, Kay Sievers wrote:
> On Fri, Oct 15, 2004 at 11:59:35AM -0700, Greg KH wrote:
> >
> > Ugh. In looking at the kernel code, I don't see how it could be doing
> > this. But the console startup code is a strange beast...
>
> The close will remove the "dev" file and the wait_for_sysfs from the
> add-hotplug will spin and fail or at best will recover with the next
> hotplug-add. The "remove" event beats the "add"! We have the same event
> serializing problem here, we solved with udevd for udev.
I may reactivate my old hotplugd work to address this?
We merge udev and udevd. We parse the config and rules once on startup and
then wait for events as udevd does today.
On a kernel event udevd does a fork() but _no_ exec(). This will create a
new instance of the same code with the already parsed config in memory.
The forked udevd instance will:
o wait for sysfs internally
o if needed create the node and set the environment
o execute /etc/hotplug.d/ scripts (with DEVPATH in the environment)
This leads to:
o complete serialized hotplug sequence handling
o hotplug.d/ execution with sane sysfs state and created node
o no more dev.d/ (can just live in hotplug.d/)
o no udev disk activity (with nodes and db on tmpfs)
o only one process fork() for every event (besides possible callouts)
It is a bit far from the current model but we already rely on a running
daemon. I've had something like this in mind with all my recent work.
In the very long run we may even set /proc/sys/kernel/hotplug to "" after
bootup and udevd(hotplugd) can get the hotplug-events over netlink :)
What do you think?
Kay
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* [PATCH 2.6.9-rc4 2/2] slip: use netdev_priv
From: Stephen Hemminger @ 2004-10-15 20:05 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
Replace dev->priv with netdev_priv(dev)
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
diff -Nru a/drivers/net/slip.c b/drivers/net/slip.c
--- a/drivers/net/slip.c 2004-10-15 12:35:54 -07:00
+++ b/drivers/net/slip.c 2004-10-15 12:35:54 -07:00
@@ -459,13 +459,11 @@
static void sl_tx_timeout(struct net_device *dev)
{
- struct slip *sl = (struct slip*)(dev->priv);
+ struct slip *sl = netdev_priv(dev);
spin_lock(&sl->lock);
if (netif_queue_stopped(dev)) {
- struct slip *sl = (struct slip*)(dev->priv);
-
if (!netif_running(dev))
goto out;
@@ -495,7 +493,7 @@
static int
sl_xmit(struct sk_buff *skb, struct net_device *dev)
{
- struct slip *sl = (struct slip*)(dev->priv);
+ struct slip *sl = netdev_priv(dev);
spin_lock(&sl->lock);
if (!netif_running(dev)) {
@@ -529,7 +527,7 @@
static int
sl_close(struct net_device *dev)
{
- struct slip *sl = (struct slip*)(dev->priv);
+ struct slip *sl = netdev_priv(dev);
spin_lock_bh(&sl->lock);
if (sl->tty) {
@@ -548,7 +546,7 @@
static int sl_open(struct net_device *dev)
{
- struct slip *sl = (struct slip*)(dev->priv);
+ struct slip *sl = netdev_priv(dev);
if (sl->tty==NULL)
return -ENODEV;
@@ -562,7 +560,7 @@
static int sl_change_mtu(struct net_device *dev, int new_mtu)
{
- struct slip *sl = (struct slip*)(dev->priv);
+ struct slip *sl = netdev_priv(dev);
if (new_mtu < 68 || new_mtu > 65534)
return -EINVAL;
@@ -578,7 +576,7 @@
sl_get_stats(struct net_device *dev)
{
static struct net_device_stats stats;
- struct slip *sl = (struct slip*)(dev->priv);
+ struct slip *sl = netdev_priv(dev);
#ifdef SL_INCLUDE_CSLIP
struct slcompress *comp;
#endif
@@ -613,7 +611,7 @@
static int sl_init(struct net_device *dev)
{
- struct slip *sl = (struct slip*)(dev->priv);
+ struct slip *sl = netdev_priv(dev);
/*
* Finish setting up the DEVICE info.
@@ -631,7 +629,7 @@
static void sl_uninit(struct net_device *dev)
{
- struct slip *sl = (struct slip*)(dev->priv);
+ struct slip *sl = netdev_priv(dev);
sl_free_bufs(sl);
}
@@ -720,7 +718,7 @@
if ((dev = slip_devs[i]) == NULL)
break;
- sl = dev->priv;
+ sl = netdev_priv(dev);
if (sl->tty || sl->leased)
continue;
if (dev->flags&IFF_UP)
@@ -747,7 +745,7 @@
if (dev == NULL)
break;
- sl = dev->priv;
+ sl = netdev_priv(dev);
if (sl->leased) {
if (sl->line != line)
continue;
@@ -789,7 +787,7 @@
i = sel;
dev = slip_devs[i];
if (score > 1) {
- sl = dev->priv;
+ sl = netdev_priv(dev);
sl->flags &= (1 << SLF_INUSE);
return sl;
}
@@ -800,7 +798,7 @@
return NULL;
if (dev) {
- sl = dev->priv;
+ sl = netdev_priv(dev);
if (test_bit(SLF_INUSE, &sl->flags)) {
unregister_netdevice(dev);
dev = NULL;
@@ -818,7 +816,7 @@
dev->base_addr = i;
}
- sl = dev->priv;
+ sl = netdev_priv(dev);
/* Initialize channel control data */
sl->magic = SLIP_MAGIC;
@@ -1261,7 +1259,7 @@
static int sl_ioctl(struct net_device *dev,struct ifreq *rq,int cmd)
{
- struct slip *sl = (struct slip*)(dev->priv);
+ struct slip *sl = netdev_priv(dev);
unsigned long *p = (unsigned long *)&rq->ifr_ifru;
if (sl == NULL) /* Allocation failed ?? */
@@ -1407,7 +1405,7 @@
dev = slip_devs[i];
if (!dev)
continue;
- sl = dev->priv;
+ sl = netdev_priv(dev);
spin_lock_bh(&sl->lock);
if (sl->tty) {
busy++;
@@ -1424,7 +1422,7 @@
continue;
slip_devs[i] = NULL;
- sl = dev->priv;
+ sl = netdev_priv(dev);
if (sl->tty) {
printk(KERN_ERR "%s: tty discipline still running\n",
dev->name);
^ permalink raw reply
* [PATCH 2.6.9-rc4 1/2] slip: use module_param
From: Stephen Hemminger @ 2004-10-15 20:04 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
Replace MODULE_PARM with module_param (also make slip_maxdev static).
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
diff -Nru a/drivers/net/slip.c b/drivers/net/slip.c
--- a/drivers/net/slip.c 2004-10-15 12:34:30 -07:00
+++ b/drivers/net/slip.c 2004-10-15 12:34:30 -07:00
@@ -57,6 +57,7 @@
#define SL_CHECK_TRANSMIT
#include <linux/config.h>
#include <linux/module.h>
+#include <linux/moduleparam.h>
#include <asm/system.h>
#include <asm/uaccess.h>
@@ -85,8 +86,8 @@
static struct net_device **slip_devs;
-int slip_maxdev = SL_NRUNIT; /* Can be overridden with insmod! */
-MODULE_PARM(slip_maxdev, "i");
+static int slip_maxdev = SL_NRUNIT;
+module_param(slip_maxdev, int, 0);
MODULE_PARM_DESC(slip_maxdev, "Maximum number of slip devices");
static int slip_esc(unsigned char *p, unsigned char *d, int len);
^ permalink raw reply
* [PATCH 2.6.9-rc4 2/2] b44: use netdev_priv
From: Stephen Hemminger @ 2004-10-15 20:03 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
Replace uses of dev->priv with netdev_priv
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
diff -Nru a/drivers/net/b44.c b/drivers/net/b44.c
--- a/drivers/net/b44.c 2004-10-15 12:23:59 -07:00
+++ b/drivers/net/b44.c 2004-10-15 12:23:59 -07:00
@@ -1885,7 +1885,7 @@
static int b44_suspend(struct pci_dev *pdev, u32 state)
{
struct net_device *dev = pci_get_drvdata(pdev);
- struct b44 *bp = dev->priv;
+ struct b44 *bp = netdev_priv(dev);
if (!netif_running(dev))
return 0;
@@ -1906,7 +1906,7 @@
static int b44_resume(struct pci_dev *pdev)
{
struct net_device *dev = pci_get_drvdata(pdev);
- struct b44 *bp = dev->priv;
+ struct b44 *bp = netdev_priv(dev);
pci_restore_state(pdev, bp->pci_cfg_state);
^ permalink raw reply
* [PATCH 2.6.9-rc4 1/2] b44: replace MODULE_PARM
From: Stephen Hemminger @ 2004-10-15 20:02 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
Replace MODULE_PARM with module_param
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
diff -Nru a/drivers/net/b44.c b/drivers/net/b44.c
--- a/drivers/net/b44.c 2004-10-15 12:23:11 -07:00
+++ b/drivers/net/b44.c 2004-10-15 12:23:11 -07:00
@@ -8,6 +8,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
+#include <linux/moduleparam.h>
#include <linux/types.h>
#include <linux/netdevice.h>
#include <linux/ethtool.h>
@@ -79,10 +80,10 @@
MODULE_AUTHOR("Florian Schirmer, Pekka Pietikainen, David S. Miller");
MODULE_DESCRIPTION("Broadcom 4400 10/100 PCI ethernet driver");
MODULE_LICENSE("GPL");
-MODULE_PARM(b44_debug, "i");
-MODULE_PARM_DESC(b44_debug, "B44 bitmapped debugging message enable value");
static int b44_debug = -1; /* -1 == use B44_DEF_MSG_ENABLE as value */
+module_param(b44_debug, int, 0);
+MODULE_PARM_DESC(b44_debug, "B44 bitmapped debugging message enable value");
static struct pci_device_id b44_pci_tbl[] = {
{ PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_BCM4401,
^ permalink raw reply
* Re: services for predetermined IP addresses
From: Jason Opperisano @ 2004-10-15 20:01 UTC (permalink / raw)
To: netfilter
In-Reply-To: <20041015194115.58352.qmail@web21525.mail.yahoo.com>
On Fri, Oct 15, 2004 at 12:41:15PM -0700, kate wrote:
> Hello,
>
> As I see increased scans on my IP address, I want to
> limit access to only predetermined IP address ranges
> for certain services - Is the following the correct
> way to do this?
>
> <snip>
> # (Part A) Rules for incoming packets from Internet
> # Packets for established connections
> iptables -A INPUT -p ALL -d $ETH0_IP -m state --state
> ESTABLISHED,RELATED -j ACCEPT
stylistic note: the "-p ALL" is kinda unnecessary...
> # (Part B) TCP Rules
> iptables -A INPUT -p TCP -i eth0 -s 123.45.1.1
> --destination-port 21 -j okay # userA
> iptables -A INPUT -p TCP -i eth0 -s 123.45.0/16
> --destination-port 22 -j okay #users A - Z
i think you're missing a "0" there: 123.45.0/16 should really be
123.45.0.0/16.
> </snip>
>
> So I understand -
> ONLY User A can ftp, and all those in 123.45. can ssh
> , BUT no-one else on the Internet can request services
> ?
yes--as along as somewhere further down the chain you hit a drop-all
rule of some sort...
-j
--
Jason Opperisano <opie@817west.com>
^ permalink raw reply
* Get vìagra for a great price.
From: Allie R. Dewitt @ 2004-10-15 20:01 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Hi,
We have a new offer for you. Buy cheap Vìagra through our online store.
- Private online ordering
- No prescription required
- World wide shipping
Order your drugs offshore and save over 70%!
Click here: http://rx-zone.com/meds/
Best regards,
Donald Cunfingham
No thanks: http://rx-zone.com/rm.html
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
^ permalink raw reply
* Re: page fault scalability patch V10: [2/7] defer/omit taking page_table_lock
From: Marcelo Tosatti @ 2004-10-15 20:00 UTC (permalink / raw)
To: Christoph Lameter; +Cc: akpm, linux-kernel, linux-ia64
In-Reply-To: <Pine.LNX.4.58.0410151203521.26697@schroedinger.engr.sgi.com>
Hi Christoph,
Nice work!
On Fri, Oct 15, 2004 at 12:04:53PM -0700, Christoph Lameter wrote:
> Changelog
> * Increase parallelism in SMP configurations by deferring
> the acquisition of page_table_lock in handle_mm_fault
> * Anonymous memory page faults bypass the page_table_lock
> through the use of atomic page table operations
> * Swapper does not set pte to empty in transition to swap
> * Simulate atomic page table operations using the
> page_table_lock if an arch does not define
> __HAVE_ARCH_ATOMIC_TABLE_OPS. This still provides
> a performance benefit since the page_table_lock
> is held for shorter periods of time.
>
> Signed-off-by: Christoph Lameter <clameter@sgi.com>
>
> Index: linux-2.6.9-rc4/mm/memory.c
> =================================> --- linux-2.6.9-rc4.orig/mm/memory.c 2004-10-14 12:22:14.000000000 -0700
> +++ linux-2.6.9-rc4/mm/memory.c 2004-10-14 12:22:14.000000000 -0700
> @@ -1314,8 +1314,7 @@
> }
>
> /*
> - * We hold the mm semaphore and the page_table_lock on entry and
> - * should release the pagetable lock on exit..
> + * We hold the mm semaphore
> */
> static int do_swap_page(struct mm_struct * mm,
> struct vm_area_struct * vma, unsigned long address,
> @@ -1327,15 +1326,13 @@
> int ret = VM_FAULT_MINOR;
>
> pte_unmap(page_table);
> - spin_unlock(&mm->page_table_lock);
> page = lookup_swap_cache(entry);
> if (!page) {
> swapin_readahead(entry, address, vma);
> page = read_swap_cache_async(entry, vma, address);
> if (!page) {
> /*
> - * Back out if somebody else faulted in this pte while
> - * we released the page table lock.
> + * Back out if somebody else faulted in this pte
> */
> spin_lock(&mm->page_table_lock);
> page_table = pte_offset_map(pmd, address);
The comment above, which is a few lines down on do_swap_page() is now
bogus (the "while we released the page table lock").
/*
* Back out if somebody else faulted in this pte while we
* released the page table lock.
*/
spin_lock(&mm->page_table_lock);
page_table = pte_offset_map(pmd, address);
if (unlikely(!pte_same(*page_table, orig_pte))) {
> @@ -1406,14 +1403,12 @@
> }
>
> /*
> - * We are called with the MM semaphore and page_table_lock
> - * spinlock held to protect against concurrent faults in
> - * multithreaded programs.
> + * We are called with the MM semaphore held.
> */
> static int
> do_anonymous_page(struct mm_struct *mm, struct vm_area_struct *vma,
> pte_t *page_table, pmd_t *pmd, int write_access,
> - unsigned long addr)
> + unsigned long addr, pte_t orig_entry)
> {
> pte_t entry;
> struct page * page = ZERO_PAGE(addr);
> @@ -1425,7 +1420,6 @@
> if (write_access) {
> /* Allocate our own private page. */
> pte_unmap(page_table);
> - spin_unlock(&mm->page_table_lock);
>
> if (unlikely(anon_vma_prepare(vma)))
> goto no_mem;
> @@ -1434,30 +1428,39 @@
> goto no_mem;
> clear_user_highpage(page, addr);
>
> - spin_lock(&mm->page_table_lock);
> + lock_page(page);
Question: Why do you need to hold the pagelock now?
I can't seem to figure that out myself.
> page_table = pte_offset_map(pmd, addr);
>
> - if (!pte_none(*page_table)) {
> - pte_unmap(page_table);
> - page_cache_release(page);
> - spin_unlock(&mm->page_table_lock);
> - goto out;
> - }
> - atomic_inc(&mm->mm_rss);
> entry = maybe_mkwrite(pte_mkdirty(mk_pte(page,
> vma->vm_page_prot)),
> vma);
> - lru_cache_add_active(page);
> mark_page_accessed(page);
> - page_add_anon_rmap(page, vma, addr);
> }
>
> - set_pte(page_table, entry);
> + /* update the entry */
> + if (!ptep_cmpxchg(vma, addr, page_table, orig_entry, entry)) {
> + if (write_access) {
> + pte_unmap(page_table);
> + unlock_page(page);
> + page_cache_release(page);
> + }
> + goto out;
> + }
> + if (write_access) {
> + /*
> + * The following two functions are safe to use without
> + * the page_table_lock but do they need to come before
> + * the cmpxchg?
> + */
They do need to come after AFAICS - from the point they are in the reverse map
and the page is on the LRU try_to_unmap() can come in and try to
unmap the pte (now that we dont hold page_table_lock anymore).
> + lru_cache_add_active(page);
> + page_add_anon_rmap(page, vma, addr);
> + atomic_inc(&mm->mm_rss);
> + unlock_page(page);
> + }
> pte_unmap(page_table);
>
> /* No need to invalidate - it was non-present before */
> update_mmu_cache(vma, addr, entry);
> - spin_unlock(&mm->page_table_lock);
> out:
> return VM_FAULT_MINOR;
> no_mem:
> @@ -1473,12 +1476,12 @@
> * As this is called only for pages that do not currently exist, we
> * do not need to flush old virtual caches or the TLB.
> *
> - * This is called with the MM semaphore held and the page table
> - * spinlock held. Exit with the spinlock released.
> + * This is called with the MM semaphore held.
> */
> static int
> do_no_page(struct mm_struct *mm, struct vm_area_struct *vma,
> - unsigned long address, int write_access, pte_t *page_table, pmd_t *pmd)
> + unsigned long address, int write_access, pte_t *page_table,
> + pmd_t *pmd, pte_t orig_entry)
> {
> struct page * new_page;
> struct address_space *mapping = NULL;
> @@ -1489,9 +1492,8 @@
>
> if (!vma->vm_ops || !vma->vm_ops->nopage)
> return do_anonymous_page(mm, vma, page_table,
> - pmd, write_access, address);
> + pmd, write_access, address, orig_entry);
> pte_unmap(page_table);
> - spin_unlock(&mm->page_table_lock);
>
> if (vma->vm_file) {
> mapping = vma->vm_file->f_mapping;
> @@ -1589,7 +1591,7 @@
> * nonlinear vmas.
> */
> static int do_file_page(struct mm_struct * mm, struct vm_area_struct * vma,
> - unsigned long address, int write_access, pte_t *pte, pmd_t *pmd)
> + unsigned long address, int write_access, pte_t *pte, pmd_t *pmd, pte_t entry)
> {
> unsigned long pgoff;
> int err;
> @@ -1602,13 +1604,12 @@
> if (!vma->vm_ops || !vma->vm_ops->populate ||
> (write_access && !(vma->vm_flags & VM_SHARED))) {
> pte_clear(pte);
> - return do_no_page(mm, vma, address, write_access, pte, pmd);
> + return do_no_page(mm, vma, address, write_access, pte, pmd, entry);
> }
>
> pgoff = pte_to_pgoff(*pte);
>
> pte_unmap(pte);
> - spin_unlock(&mm->page_table_lock);
>
> err = vma->vm_ops->populate(vma, address & PAGE_MASK, PAGE_SIZE, vma->vm_page_prot, pgoff, 0);
> if (err = -ENOMEM)
> @@ -1627,49 +1628,49 @@
> * with external mmu caches can use to update those (ie the Sparc or
> * PowerPC hashed page tables that act as extended TLBs).
> *
> - * Note the "page_table_lock". It is to protect against kswapd removing
> - * pages from under us. Note that kswapd only ever _removes_ pages, never
> - * adds them. As such, once we have noticed that the page is not present,
> - * we can drop the lock early.
> - *
> + * Note that kswapd only ever _removes_ pages, never adds them.
> + * We need to insure to handle that case properly.
> + *
> * The adding of pages is protected by the MM semaphore (which we hold),
> * so we don't need to worry about a page being suddenly been added into
> * our VM.
> - *
> - * We enter with the pagetable spinlock held, we are supposed to
> - * release it when done.
> */
> static inline int handle_pte_fault(struct mm_struct *mm,
> struct vm_area_struct * vma, unsigned long address,
> int write_access, pte_t *pte, pmd_t *pmd)
> {
> pte_t entry;
> + pte_t new_entry;
>
> entry = *pte;
> if (!pte_present(entry)) {
> /*
> * If it truly wasn't present, we know that kswapd
> * and the PTE updates will not touch it later. So
> - * drop the lock.
> + * no need to acquire the page_table_lock.
> */
> if (pte_none(entry))
> - return do_no_page(mm, vma, address, write_access, pte, pmd);
> + return do_no_page(mm, vma, address, write_access, pte, pmd, entry);
> if (pte_file(entry))
> - return do_file_page(mm, vma, address, write_access, pte, pmd);
> + return do_file_page(mm, vma, address, write_access, pte, pmd, entry);
> return do_swap_page(mm, vma, address, pte, pmd, entry, write_access);
> }
I wonder what happens if kswapd, through try_to_unmap_one(), unmap's the
pte right here ?
Aren't we going to proceed with the "pte_mkyoung(entry)" of a potentially
now unmapped pte? Isnt that case possible now?
^ permalink raw reply
* Re: [PATCH 2.6.9-rc2 8/8] S2io: two buffer mode
From: Andi Kleen @ 2004-10-15 19:57 UTC (permalink / raw)
To: Leonid Grossman
Cc: 'Jeff Garzik', 'Raghavendra Koushik',
'Chris Leech', ravinandan.arakali,
'Francois Romieu', netdev, rapuru.sriram
In-Reply-To: <200410151948.i9FJmo39006757@guinness.s2io.com>
On Fri, Oct 15, 2004 at 12:48:34PM -0700, Leonid Grossman wrote:
> OK, we will debug and try to fix this.
iirc it was originally implemented for HIPPI because the MM
system had some problems with allocating 64K linear buffers
reliably. But I'm not sure anybody still uses the HIPPI
driver so it may have been a bit bitrotted.
-Andi
^ permalink raw reply
* Re: Trying to get Ax25 running.
From: Chuck Hast @ 2004-10-15 19:55 UTC (permalink / raw)
To: Linux-hams List
In-Reply-To: <Pine.SUN.4.58.0410151221210.28043@eskimo.com>
I am not interested in doing multiple TNC's all I want is the crc part,
Do I still have to use the master slave part? Looks like the AX25-
config program does not take into account such things.
Here is a listing from a lsmod on my system
kp4djt@rf-tool:~> lsmod
Module Size Used by
mkiss 10020 0
ax25 58476 1 mkiss
This is the ax25-up script file that the ax25-config program created.
#!/bin/bash
# Startkiss0
# Firmware-TNCs in den KISS-Modus schalten
#stty 19200 < /dev/ttyS0
#echo -e "\r\033@K1\r" > /dev/ttyS0
#sleep 3
#
# KISS-Modul einbinden
modprobe ax25; modprobe kiss; modprobe mkiss
#
# KISS-Ger� an /dev/ttyS0 als Port kiss0 anbinden
/usr/sbin/kissattach -i 44.1.1.1 /dev/ttyS0 kiss0
# Parameter einstellen: P=128, W=10, TX-Delay=100
/usr/sbin/kissparms -p kiss0 -r 128 -s 10 -l 10 -t 100
# Endkiss0
# StartARNM
#
# Logins von au�n erm�lichen
/usr/sbin/ax25d &
echo $! > /var/run/ax25d.pid
#
# Start AX25 routing daemon
/usr/sbin/ax25rtd &
echo $! > /var/run/ax25rtd.pid
insmod netrom
nrattach -i 44.1.1.1 nr0
#
# Monitor auf Terminal 11 starten
/usr/bin/listen -artc > /dev/tty11 &
echo $! > /var/run/listen.pid
# EndARNM
-
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: absolutely baffled as to why PPP link doesn't allow pings
From: Robert P. J. Day @ 2004-10-15 19:52 UTC (permalink / raw)
To: linux-ppp
In-Reply-To: <Pine.LNX.4.60.0410151211340.11955@localhost.localdomain>
On Fri, 15 Oct 2004 carlsonj@workingcode.com wrote:
> Robert P. J. Day writes:
> > well, we're making progress, although not the way i would have liked.
> > as a simple test, we just hooked up the serial ports of the systems
> > direct connect with a serial cable, and PPP worked just dandy.
> >
> > putting the modems back in the circuit re-introduced the problem. so
> > it could be the modems or the initialization strings we're using.
> > back to the drawing board ...
>
> That certainly points in a different direction. One possibility is
> that you're running into flow control problems or transparency issues
> with the modems.
>
> If they're like USR modems, then "AT&F1" usually does the trick.
you are the man. i can't believe it was nothing more than turning on
HW flow control. grrrrr .....
rday
p.s. but on the bright side, i know a lot more about PPP now. :-P
^ permalink raw reply
* Re: Announcing Binary Compatibility/Testing
From: Matthias Urlichs @ 2004-10-15 19:49 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <1097709855.5411.20.camel@localhost>
Hi, Robert Love wrote:
> Any other incompatibility lies in libraries, but we have library
> versioning. There is nothing wrong with newer libs breaking
> compatibility so long as they have a different soname.
Glibc doesn't use library versioning. It uses *symbol* versioning.
Thus, for some library entry points you now see multiple symbols with the
same name but different versions (ancient vs. old vs. new "struct stat",
16- vs. 32-bit UID, whatever). As long as the header files you compile
against match the library you link to, it all works transparently.
For the library's user, that is. The author's job is harder...
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
^ 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.