* Re: IBM spamms me with error messages
From: Keith Owens @ 2002-12-11 14:12 UTC (permalink / raw)
To: kernel list
In-Reply-To: <20021211133509.GC3575@atrey.karlin.mff.cuni.cz>
On Wed, 11 Dec 2002 14:35:12 +0100,
Pavel Machek <pavel@suse.cz> wrote:
>> > I replied to some mail on l-k and IBM spammed me with 20+ error
>> > messages. Now it is apparently going to do that again.
>>
>> Still/again ?
>
>It seems to happen after I group-reply to message on the list. Being
>subscribed and quiet does not seem to trigger it. When I do
>group-reply, I do get pair of error messages, then another pair of
>same error messages, and it continues like that.
>
>This time it "only" sent two pairs of error messages...
<aol>Me too</aol>. I have blocked 32.97.182.0/24 at my firewall, let
IBM eat their own garbage messages.
^ permalink raw reply
* hostname forwarding
From: bernard @ 2002-12-11 14:05 UTC (permalink / raw)
To: netfilter
In-Reply-To: <FD8F124A387AD6119F7900A0D218B32154A614@hslex01.hslbz.local>
I'm using iptables to redirect external requests depending on their
port/protocol like this :
hostname A:80 -> public ip -> iptables -> 192.168.1.1:80
hostname B:80 -> public ip -> iptables -> 192.168.1.1:80
It works pretty well, thanks to iptables :-)
Now I want to redirect on a hostname basis on different private ip's
like this :
hostname A:80 -> public ip -> iptables -> 192.168.1.1:80
hostname B:80 -> public ip -> iptables -> 192.168.1.2:80
Does anyone know a solution ?
Thanks for your help.
Bernard
^ permalink raw reply
* Re: Is this going to be true ?
From: Måns Rullgård @ 2002-12-11 14:17 UTC (permalink / raw)
To: Rik van Riel; +Cc: Joseph D. Wagner, 'Serge Kuznetsov', linux-kernel
In-Reply-To: <Pine.LNX.4.50L.0212111139560.21756-100000@imladris.surriel.com>
Rik van Riel <riel@conectiva.com.br> writes:
> > > Research Firm: Microsoft Will Use Linux by 2004:
> > > [trim]
> >
> > Over Bill Gates' dead body. The Microsoft Corporation is of the genuine
> > belief that Microsoft Windows is the operating system of the future.
>
> Wait a moment, didn't they say that OS/2 was the operating
> system of the future ?
>
> And what about that overly complex internet thingy, that'd
> never take off, people would use MSN instead.
>
> We have always been at war with Oceania.
640K
> > The following scenarios are far more likely.
>
> They'll have no choice but to follow their customers around.
> A corporation can't exist without clients.
There is one option: brainwash customers. MS is used to doing it.
--
Måns Rullgård
mru@users.sf.net
^ permalink raw reply
* Re: [PATCH] dm.c - device-mapper I/O path fixes
From: Joe Thornber @ 2002-12-11 14:18 UTC (permalink / raw)
To: Kevin Corry
Cc: Denis Vlasenko, Joe Thornber, Linus Torvalds, Kernel Mailing List,
lvm-devel
In-Reply-To: <02121107165303.29515@boiler>
On Wed, Dec 11, 2002 at 07:16:53AM -0600, Kevin Corry wrote:
> However, it might be a good idea to consider how bio's keep track of errors.
> When a bio is created, it is marked UPTODATE. Then, if any part of a bio
> takes an error, the UPTODATE flag is turned off. When the whole bio
> completes, if the UPTODATE flag is still on, there were no errors during the
> i/o. Perhaps the "error" field in "struct dm_io" could be modified to use
> this method of error tracking? Then we could change dec_pending() to be
> something like:
>
> if (error)
> clear_bit(DM_IO_UPTODATE, &io->error);
>
> with a "set_bit(DM_IO_UPTODATE, &ci.io->error);" in __bio_split().
The problem with this is you don't keep track of the specific error to
later pass to bio_endio(io->bio...). I guess it all comes down to
just how expensive that spin lock is; and since locking only occurs
when there's an error I'm happy with things as they are.
- Joe
^ permalink raw reply
* Netfilter module falls out - what happens to pakets?
From: Freckmann, Christian @ 2002-12-11 14:11 UTC (permalink / raw)
To: 'netfilter@lists.netfilter.org'
I use netfilter with the 2.4.19 kernel. IP forwarding is deactived by the
kernel.
What happens to incoming, forwarded and outgoing pakets if only the
netfilter module doesn't work but the system is still running?
Can they pass the system or are they blocked?
Thanks for your help and best regards
^ permalink raw reply
* Re: 2.5.51 -- rivafb is whacky (characters flipped on vertical axis, 640x480 usable area shown inside a higher-res area, etc).
From: James Simmons @ 2002-12-11 15:06 UTC (permalink / raw)
To: Miles Lane; +Cc: linux-fbdev-devel
In-Reply-To: <3DF6D6D5.5060902@attbi.com>
> James, I appreciate all your hard work. I hope my bug report
> isn't too upsetting for you. I think you are making great progress.
> It is also a shame that so much of the driver porting has fallen
> on your shoulders. If I were a programmer. I'd help, but my skills
> are in software testing, for the most part.
Thank you :-) Its getting there.
-------------------------------------------------------
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: PPTP+NAT+MASQ anyone?
From: Roy Sigurd Karlsbakk @ 2002-12-11 14:14 UTC (permalink / raw)
To: Martin Josefsson; +Cc: Netfilter mailinglist
In-Reply-To: <1039615426.20573.80.camel@tux>
> IIRC the pptp patch doesn't apply if you've applied tcp-windowtracking
> patch, that patch is quite invasive.
>
> I just tried applying _all_ patches that come before the pptp patch in
> p-o-m to 2.4.19 and then applying the pptp patch, no problem, worked
> fine.
Then what am I doing wrong???
cd /usr/src
tar xzf packed/linux-2.4.19.tar.gz
ln -s linux-2.4.19 linux
cd netfilter/patch-o-matic
./runme pending
./runme extra
roy
--
Roy Sigurd Karlsbakk, Datavaktmester
ProntoTV AS - http://www.pronto.tv/
Tel: +47 9801 3356
Computers are like air conditioners.
They stop working when you open Windows.
^ permalink raw reply
* [linux-lvm] pvcreate -- ERROR "Success"
From: Tru64 User @ 2002-12-11 14:22 UTC (permalink / raw)
To: linux-lvm
Firsttimer, trying to take advantage of LVM on Linux.
I have used it on AIX, so i have the concept.
I have a RAID Array (1.1Tb) SCSI-ATA drive (sdb) that
i was trying to create a volume out of (pvcreate).
However, it gives me an ERROR "Success" message.
I initially had it formatted with with reiserfs, but
then wiped it clean, and erased partition table as
described in howtos (dd /dev/zero....). Debug also
posted below.
Any leads to get this working?
Exact error below. Thnks in advance.
******************
chinook@/home/moll# pvcreate /dev/sdb
Password:
pvcreate -- ERROR "Success" getting size of physical
volume "/dev/sdb"
pvcreate [-d|--debug] [-f[f]|--force [--force]]
[-h|--help] [-y|--yes]
[-v|--verbose] [--version] PhysicalVolume
[PhysicalVolume...]
chinook@/home/moll$
**********BEGIN_Debug*****************
Script started on Wed Dec 11 15:17:09 2002
cerebus@/home/mollel$ s pvcreate --debug /dev/sdb
<1> lvm_get_iop_version -- CALLED
<22> lvm_check_special -- CALLED
<22> lvm_check_special -- LEAVING
<1> lvm_get_iop_version -- AFTER ioctl ret: 0
<1> lvm_get_iop_version -- LEAVING with ret: 10
<1> lvm_lock -- CALLED
<22> lvm_check_special -- CALLED
<22> lvm_check_special -- LEAVING
<1> lvm_lock -- LEAVING with ret: 0
<1> pv_check_name -- CALLED with "/dev/sdb"
<22> lvm_check_chars -- CALLED with name: "/dev/sdb"
<22> lvm_check_chars -- LEAVING with ret: 0
<22> lvm_check_dev -- CALLED
<333> lvm_check_partitioned_dev -- CALLED
<4444> lvm_get_device_type called
<4444> lvm_get_device_type leaving with 1
<333> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<22> lvm_check_dev -- LEAVING with ret: 1
<1> pv_check_name -- LEAVING with ret: 0
<1> pv_get_size -- CALLED with /dev/sdb and 0xbfffdfa0
<22> lvm_dir_cache -- CALLED
<333> lvm_add_dir_cache -- CALLED with /dev/sda
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 1
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/sda1
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 1
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/sdb
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 1
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/hda
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/hda1
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/hda2
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/hda5
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/hda6
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/hda7
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/hda8
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/hda9
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/hda9
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: NOT ADDED
<22> lvm_dir_cache -- LEAVING with ret: 11
<22> lvm_dir_cache_find -- CALLED with /dev/sdb
<333> pv_check_name -- CALLED with "/dev/sdb"
<4444> lvm_check_chars -- CALLED with name: "/dev/sdb"
<4444> lvm_check_chars -- LEAVING with ret: 0
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 1
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> pv_check_name -- LEAVING with ret: 0
<333> lvm_dir_cache -- CALLED
<333> lvm_dir_cache -- LEAVING with ret: 11
<22> lvm_dir_cache_find -- LEAVING with entry: 2
<22> lvm_check_partitioned_dev -- CALLED
<333> lvm_get_device_type called
<333> lvm_get_device_type leaving with 1
<22> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<22> lvm_partition_count -- CALLED for 0x810
<333> lvm_get_device_type called
<333> lvm_get_device_type leaving with 1
<22> lvm_partition_count -- LEAVING with ret: 16
<22> pv_get_dev_size -- CALLED with /dev/sdb and
0xbfffdfa0
<22> pv_get_dev_size -- LEAVING with ret: -1951217920
<1> pv_get_size -- LEAVING with ret: -1951217920
<1> lvm_error -- CALLED with: -1951217920
<1> lvm_error -- LEAVING with: "Success"
pvcreate -- ERROR "Success" getting size of physical
volume "/dev/sdb"
pvcreate [-d|--debug] [-f[f]|--force [--force]]
[-h|--help] [-y|--yes]
[-v|--verbose] [--version] PhysicalVolume
[PhysicalVolume...]
<1> lvm_unlock -- CALLED
<1> lvm_unlock -- LEAVING with ret: 0
chinook@/home/moll# exit
exit
Script done on Wed Dec 11 15:17:21 2002
***************END_DEBUG********************
=====
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
^ permalink raw reply
* Re: portfw on iptables 2.4 kernel problem.
From: Joel Newkirk @ 2002-12-11 14:25 UTC (permalink / raw)
To: Reckhard, Tobias, netfilter
In-Reply-To: <96C102324EF9D411A49500306E06C8D1021AE392@eketsv02.cubis.de>
On Wednesday 11 December 2002 04:00 am, Reckhard, Tobias wrote:
> Munging both replies into one, my answers are inline.
>
> > > I expect you're trying to access the FTP server on
> > > 10.0.0.11 from the
> > > Internet by redirecting connections to the firewall's external IP
> > > address (203.100.100.1) to the FTP server.
> > >
> > > Take care of the FTP control connection:
> > > 2. Permit INPUT on the outside interface of the firewall to TCP
> > > port 21 with states NEW and ESTABLISHED
> > > 3. Permit OUTPUT on the outside interface of the firewall from TCP
> > > port 21 with state ESTABLISHED
> > > 4. In the PREROUTING chain use DNAT to redirect packets "-p tcp -d
> > > 203.100.100.1 --dport 21" (see point 2 above) to the internal
> > > server at 10.0.0.11.
> > > 5. Permit FORWARDing of those same packets with states NEW and
> > > ESTABLISHED. 6. Permit FORWARDing of response packets ("-s
> > > 10.0.0.11 --sport 21") with state ESTABLISHED.
> >
> > This wouldn't work at all. INPUT shouldn't enter into it at
> > all, unless
> > the DNAT fails, and OUTPUT only if a packet is required to leave the
> > firewall machine itself, IE if that is where the connection
> > is attempted from or to.
>
> The above takes care of the control connection only. Since the
> Internet machine believes it is accessing an FTP server on the
> firewall itself, the latter is addressed by its FTP control
> connection. This means that the packets cross the firewall's INPUT
> chain, before they can be DNATed in the PREROUTING chain. I'm not
> entirely sure about the outbound packets, but most things netfilter
> apart from NAT require symmetric rules, so I suppose you need an
> OUTPUT rule to match the INPUT one.
I don't see how this would be. The first chain that a packet entering
the firewall hits is mangle-PREROUTING, second is nat-PREROUTING. At
that point it is DNATted, and then hits a routing decision that
determines if it is local or not, IE INPUT or FORWARD. It should never
'cross' INPUT at all, unless my understanding (and most sources I've
read, and traversal tests performed) is faulty.
> [FTP data]
>
> Thanks for the info, but I know all about FTP data.. What did you
> think steps 7 through 15 in my recipe were for?
Apologies for this, somehow I lost track of the entire end of your
message. I snipped it off to reply about INPUT, and just kept on going
based on what I still had left, forgetting the remainder. Someday I'll
learn to pay more attention when writing 3am replies... (and 3:10 am
replies to those replies :^)
j
^ permalink raw reply
* Re: Why does C3 CPU downgrade in kernel 2.4.20?
From: Denis Vlasenko @ 2002-12-11 19:09 UTC (permalink / raw)
To: Dave Jones; +Cc: Daniel Egger, Joseph, linux-kernel@vger.kernel.org
In-Reply-To: <20021211105808.GA17354@codemonkey.org.uk>
On 11 December 2002 08:58, Dave Jones wrote:
> On Wed, Dec 11, 2002 at 11:19:23AM -0200, Denis Vlasenko wrote:
> > > Prolly I would have to do more benchmarking to find out about
> > > aligment advantages.
> >
> > I heard cmovs are microcoded in Centaurs.
> > s...l...o...w...
>
> Hardly surprising given that the chip isn't targetted at the
> performance market.
*We Support 686 Instruction Set* plastered everywhere? ;)
Who cares that a single cmov take some tens of cycles...
(btw, can someone measure that? I have no C3...)
On 7 July 2002 12:32, Willy TARREAU wrote:
> because GCC's output is really ugly. In fact, it is
> also ugly when it generates cmov. I disassembled my
> libc and found that it subobtimizes the code at the
> point that it's far worse with cmov than without !
> (more instructions, more memory accesses, more
> registers used).
Do not try to optimize "pedal to the metal" without
actually looking at the results.
With "-march=i686" on C3 one will get:
* Non-optimal GCC code generation
* Really Slow (tm) cmovs
* Buggy code (cmov with mem operands)
if one don't think above two are not enough ;)
On 10 December 2002 05:22, Daniel Egger wrote:
> Am Die, 2002-12-10 um 06.52 schrieb Dave Jones:
> > I believe someone (Jeff Garzik?) benchmarked gcc code generation,
> > and the C3 executed code scheduled for a 486 faster than it did for
> > -m586
> > I'm not sure about the alignment flags. I've been meaning to look
> > into that myself...
>
> Interesting. I have no clue about which C3 you're talking about here
> but a VIA Ezra has all 686 instructions including cmov and thus
> optimising for PPro works best for me.
Such things need testing. A kernel compile would suffice I guess.
--
vda
^ permalink raw reply
* Re: Linux 2.5.51
From: James Simmons @ 2002-12-11 15:26 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Benjamin Herrenschmidt, Stian Jordet, Allan Duncan, linux-kernel
In-Reply-To: <m1smx4vrem.fsf@frodo.biederman.org>
> How well does this driver work if you don't have a firmware
> driver initialize the card? aka a pci option ROM.
>
> I am interested because with LinuxBIOS it is still a pain to run
> PCI option roms, and I don't necessarily even have then if it a
> motherboard with video. There are some embedded/non-x86 platforms
> with similar issues.
>
> My primary interest is in the cheap ATI Rage XL chip that is on many
> server board. PCI Vendor/device id 1002:4752 (rev 27) from lspci.
>
> If nothing else if some one could point me to some resources on
> how to get the appropriate documentation from the video chipset
> manufacturers I would be happy.
>
> But I did want to at least point that running a system with out bios
> initialized video was certainly among the cases that are used.
Unfortunely ATI doesn't like to release info on what needs to be done to
initialize without frimware. I really wish this was the case. I did see
email back about someone getting a mach64 card working without firmware.
They used a bus analysiser to do this. I will see what kind of patches I
can dig up.
^ permalink raw reply
* Re: PPTP+NAT+MASQ anyone?
From: Martin Josefsson @ 2002-12-11 14:26 UTC (permalink / raw)
To: Roy Sigurd Karlsbakk; +Cc: Netfilter mailinglist
In-Reply-To: <200212111514.55539.roy@karlsbakk.net>
On Wed, 2002-12-11 at 15:14, Roy Sigurd Karlsbakk wrote:
> Then what am I doing wrong???
>
> cd /usr/src
> tar xzf packed/linux-2.4.19.tar.gz
> ln -s linux-2.4.19 linux
> cd netfilter/patch-o-matic
> ./runme pending
> ./runme extra
I have no idea, you say you use p-o-m from cvs and that you apply all
pending patches... after doing that the pptp patch works fine here.
--
/Martin
Never argue with an idiot. They drag you down to their level, then beat
you with experience.
^ permalink raw reply
* Re: buffer head read/write
From: David Chow @ 2002-12-11 14:31 UTC (permalink / raw)
To: Bryan Henderson; +Cc: linux-fsdevel, Neil Brown
In-Reply-To: <OF0DD4434B.DD4F20EA-ON87256C8C.00005E0F-88256C8C.0001B123@us.ibm.com>
OK, I think you know what I want, and you've just told me this is
impossible, then the best I could do is try to execute the task as best
as the CPU can. This is stolen from Neils md super block writing routing
that he just gave me a few days ago and merged with
wait_for_complettion. Does this code make sense?
static int sync_buffer_io(kdev_t dev, unsigned long sector, int size,
struct page *page, int rw)
struct buffer_head bh;
struct completion event;
init_completion(&event);
init_buffer(&bh, bh_complete, &event);
bh.b_rdev = dev;
bh.b_rsector = sector;
bh.b_state = (1 << BH_Req) | (1 << BH_Mapped);
bh.b_size = size;
bh.b_page = page;
bh.b_reqnext = NULL;
bh.b_data = page_address(page);
generic_make_request(rw, &bh);
run_task_queue(&tq_disk);
spin_lock_irq(even.wait.lock);
if (!event.done) {
DECLARE_WAITQUEUE(wait, current);
wait.flags |= WQ_FLAG_EXCLUSIVE;
__add_wait_queue_tail(event.wait, &wait);
do {
__set_current_state(TASK_UNINTERRUPTIBLE);
spin_unlock_irq(event.wait.lock);
run_task_queue(&tq_disk);
spin_lock_irq(event.wait.lock);
} while (!x->done);
__remove_wait_queue(event.wait, &wait);
}
event.done--;
spin_unlock_irq(&x->wait.lock);
return test_bit(BH_Uptodate, &bh.b_state);
}
This is dedicate to run the task of tq_disk instead of just schedule() which doesn't know
which task is going to run. Please comment. Thanks.
regards,
David
Bryan Henderson wrote:
>
>
>
>
>>I know how to make a call to general_make_request() but
>>wait for the buffer to complete which is too slow.
>>If I am doing a continuous sychronous read/write ..., can I put those
>>
>>
>"dirty
>
>
>>buffers"/"non-up-to-date buffers" in the head of the buffer queue so
>>that they get written by their respective handler immediately?
>>
>>
>
>"immediately" in computer systems normally means "while I wait" rather than
>"before doing anything else." That's why you got a bunch of answers that
>weren't what you were looking for.
>
>What you want is a way to assign priority to a block I/O request, so that
>a particular one gets executed first regardless of other factors, like
>that it's a mile away from where the head is now or 100 other requests
>came in before it. There's no way to do priority in today's block I/O
>layer.
>
>Incidentally, this has nothing to do with the buffer cache. The queue in
>question is for all I/O to a block device; it is below the buffer cache.
>
>
--
-----------------------------------------------------------------------------
David Chow | Managing Director
http://www.shaolinmicro.com
ShaoLin Microsystems - Multiply Efficiency
-----------------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH] dm.c - device-mapper I/O path fixes
From: Denis Vlasenko @ 2002-12-11 19:19 UTC (permalink / raw)
To: Kevin Corry, Joe Thornber; +Cc: Kernel Mailing List, lvm-devel
In-Reply-To: <02121107165303.29515@boiler>
On 11 December 2002 11:16, Kevin Corry wrote:
> > > --- diff/drivers/md/dm.c 2002-12-11 12:00:29.000000000 +0000
> > > +++ source/drivers/md/dm.c 2002-12-11 12:00:34.000000000 +0000
> > > @@ -238,10 +238,11 @@
> > > static spinlock_t _uptodate_lock = SPIN_LOCK_UNLOCKED;
> > > unsigned long flags;
> > >
> > > - spin_lock_irqsave(&_uptodate_lock, flags);
> > > - if (error)
> > > + if (error) {
> > > + spin_lock_irqsave(&_uptodate_lock, flags);
> > > io->error = error;
> > > - spin_unlock_irqrestore(&_uptodate_lock, flags);
> > > + spin_unlock_irqrestore(&_uptodate_lock, flags);
> > > + }
> > >
> > > if (atomic_dec_and_test(&io->io_count)) {
> > > if (atomic_dec_and_test(&io->md->pending))
> >
> > This seems pointless, end result:
> >
> > spin_lock_irqsave(&_uptodate_lock, flags);
> > io->error = error;
> > spin_unlock_irqrestore(&_uptodate_lock, flags);
>
> Are you saying the "if (error)" part is pointless? If so, I have to
No. Locking is pointless. What exactly you try to protect here?
> disagree. A bio may be split into several sub-bio's. When each of
> those split bio's completes, they are going to call this function.
> But if only one of those split bio's has an error, then the error
> might get lost without that "if" statement.
>
> However, it might be a good idea to consider how bio's keep track of
> errors. When a bio is created, it is marked UPTODATE. Then, if any
> part of a bio takes an error, the UPTODATE flag is turned off. When
> the whole bio completes, if the UPTODATE flag is still on, there were
> no errors during the i/o. Perhaps the "error" field in "struct dm_io"
> could be modified to use this method of error tracking? Then we could
> change dec_pending() to be something like:
>
> if (error)
> clear_bit(DM_IO_UPTODATE, &io->error);
>
> with a "set_bit(DM_IO_UPTODATE, &ci.io->error);" in __bio_split().
You seem to overestimate my knowledge of this part of the kernel. :(
--
vda
^ permalink raw reply
* Re: PPTP+NAT+MASQ anyone?
From: Roy Sigurd Karlsbakk @ 2002-12-11 14:31 UTC (permalink / raw)
To: Martin Josefsson; +Cc: Netfilter mailinglist
In-Reply-To: <1039616794.20561.83.camel@tux>
On Wednesday 11 December 2002 15:26, Martin Josefsson wrote:
> On Wed, 2002-12-11 at 15:14, Roy Sigurd Karlsbakk wrote:
> > Then what am I doing wrong???
> >
> > cd /usr/src
> > tar xzf packed/linux-2.4.19.tar.gz
> > ln -s linux-2.4.19 linux
> > cd netfilter/patch-o-matic
> > ./runme pending
> > ./runme extra
>
> I have no idea, you say you use p-o-m from cvs and that you apply all
> pending patches... after doing that the pptp patch works fine here.
it does not here. see previous message for error message
--
Roy Sigurd Karlsbakk, Datavaktmester
ProntoTV AS - http://www.pronto.tv/
Tel: +47 9801 3356
Computers are like air conditioners.
They stop working when you open Windows.
^ permalink raw reply
* Re: [TRIVIAL PATCH] FBDEV: Small impact patch for fbdev
From: James Simmons @ 2002-12-11 14:36 UTC (permalink / raw)
To: Petr Vandrovec
Cc: Linux Fbdev development list, Linux Kernel Mailing List, adaplas
In-Reply-To: <A042D564F44@vcnet.vc.cvut.cz>
> > int fb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info)
> > {
> > int xoffset = var->xoffset;
> > int yoffset = var->yoffset;
> > int err;
> >
> > if (xoffset < 0 || yoffset < 0 || info->fbops->fb_pan_display ||
>
> I'm probably missing something important, but do not you want
> !info->fbops->fb_pan_display
> instead?
Oops. Typo to the screen. That wasn't commited :-)
^ permalink raw reply
* Re: [PATCH] dm.c - device-mapper I/O path fixes
From: Denis Vlasenko @ 2002-12-11 19:24 UTC (permalink / raw)
To: Joe Thornber, Kevin Corry; +Cc: Kernel Mailing List, lvm-devel
In-Reply-To: <20021211141820.GA21461@reti>
On 11 December 2002 12:18, Joe Thornber wrote:
> On Wed, Dec 11, 2002 at 07:16:53AM -0600, Kevin Corry wrote:
> > However, it might be a good idea to consider how bio's keep track
> > of errors. When a bio is created, it is marked UPTODATE. Then, if
> > any part of a bio takes an error, the UPTODATE flag is turned off.
> > When the whole bio completes, if the UPTODATE flag is still on,
> > there were no errors during the i/o. Perhaps the "error" field in
> > "struct dm_io" could be modified to use this method of error
> > tracking? Then we could change dec_pending() to be something like:
> >
> > if (error)
> > clear_bit(DM_IO_UPTODATE, &io->error);
> >
> > with a "set_bit(DM_IO_UPTODATE, &ci.io->error);" in __bio_split().
>
> The problem with this is you don't keep track of the specific error
> to later pass to bio_endio(io->bio...). I guess it all comes down to
> just how expensive that spin lock is; and since locking only occurs
> when there's an error I'm happy with things as they are.
lock();
a = b;
unlock();
Store of ints is atomic anyway. You need locking if a is a larger entity,
say, a struct.
--
vda
^ permalink raw reply
* Re: Warning: about not setting max_sectors
From: James Bottomley @ 2002-12-11 14:37 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-scsi
In-Reply-To: <20021211105747.A32363@infradead.org>
hch@infradead.org said:
> Yepp. Will you fix it or should I send a patch?
I'll do it (I may even look at adjusting the maximum based on the device).
James
^ permalink raw reply
* Re: [Fwd: [BENCHMARK] AIM9 results]
From: Oleg Drokin @ 2002-12-11 14:41 UTC (permalink / raw)
To: Hans Reiser; +Cc: ReiserFS, Paolo Ciarrocchi, mason
In-Reply-To: <3DF67316.1040107@namesys.com>
Hello!
On Wed, Dec 11, 2002 at 02:04:54AM +0300, Hans Reiser wrote:
> thanks for your interesting results. Chris and Oleg can probably
> comment best, so I will let them do so.
As recent measurements show, block I/O speed is slower for 2.5.50+
as compared to 2.4.19, that might explain why reiserfs is slower too.
Also in between of 2.5.50 and 2.5.51 there was something fixed that led to
some block I/O improvement (not very big), and this can be observed
in these benchmark results too ;)
Bye,
Oleg
^ permalink raw reply
* Re: [PATCH] dm.c - device-mapper I/O path fixes
From: Kevin Corry @ 2002-12-11 14:02 UTC (permalink / raw)
To: Denis Vlasenko, Joe Thornber; +Cc: Kernel Mailing List, lvm-devel
In-Reply-To: <200212111430.gBBETua06759@Port.imtp.ilyichevsk.odessa.ua>
On Wednesday 11 December 2002 13:19, Denis Vlasenko wrote:
> On 11 December 2002 11:16, Kevin Corry wrote:
> > > > --- diff/drivers/md/dm.c 2002-12-11 12:00:29.000000000 +0000
> > > > +++ source/drivers/md/dm.c 2002-12-11 12:00:34.000000000 +0000
> > > > @@ -238,10 +238,11 @@
> > > > static spinlock_t _uptodate_lock = SPIN_LOCK_UNLOCKED;
> > > > unsigned long flags;
> > > >
> > > > - spin_lock_irqsave(&_uptodate_lock, flags);
> > > > - if (error)
> > > > + if (error) {
> > > > + spin_lock_irqsave(&_uptodate_lock, flags);
> > > > io->error = error;
> > > > - spin_unlock_irqrestore(&_uptodate_lock, flags);
> > > > + spin_unlock_irqrestore(&_uptodate_lock, flags);
> > > > + }
> > > >
> > > > if (atomic_dec_and_test(&io->io_count)) {
> > > > if (atomic_dec_and_test(&io->md->pending))
> > >
> > > This seems pointless, end result:
> > >
> > > spin_lock_irqsave(&_uptodate_lock, flags);
> > > io->error = error;
> > > spin_unlock_irqrestore(&_uptodate_lock, flags);
> >
> > Are you saying the "if (error)" part is pointless? If so, I have to
>
> No. Locking is pointless. What exactly you try to protect here?
The "struct dm_io *io" that is passed to dec_pending() can be accessed by
multiple threads at the same time, thus some form of locking is required.
I had been thinking about whether the "error" field could be an atomic_t,
which would remove the requirement for the spinlock in dec_pending().
However, I don't know how atomic_t's behave with negative values. I know
atomic_t's are only guaranteed to have 24-bits of precision, yet all arch's
define atomic_t with a signed integer. Can anyone enlighten me on this?
Perhaps we could make "error" and atomic_t, and store the absolute-value of
the error code, and always return -error in the bio_endio() call. Or is that
just too ugly?
--
Kevin Corry
corryk@us.ibm.com
http://evms.sourceforge.net/
^ permalink raw reply
* [PATCH 2.5.51] sonypi driver update
From: Stelian Pop @ 2002-12-11 14:49 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Linus Torvalds
Hi,
This little patch changes the way button release events are reported
by the sonypi driver to the application: previously, separate
release events were detected for each button. However, many buttons
(example: the jogdial, the capture button, the back button etc) share
the same release event.
The attached patch propagates a single 'ANYBUTTON_RELEASED' event
to the userspace, leaving all state machine intelligence to the
application.
Kunihiko IMAI should be credited for his ideas and tests.
Linus, please apply.
Stelian.
===== include/linux/sonypi.h 1.7 vs edited =====
--- 1.7/include/linux/sonypi.h Mon Dec 2 12:14:30 2002
+++ edited/include/linux/sonypi.h Tue Dec 3 14:40:25 2002
@@ -43,9 +43,9 @@
#define SONYPI_EVENT_JOGDIAL_DOWN_PRESSED 3
#define SONYPI_EVENT_JOGDIAL_UP_PRESSED 4
#define SONYPI_EVENT_JOGDIAL_PRESSED 5
-#define SONYPI_EVENT_JOGDIAL_RELEASED 6
+#define SONYPI_EVENT_JOGDIAL_RELEASED 6 /* obsolete */
#define SONYPI_EVENT_CAPTURE_PRESSED 7
-#define SONYPI_EVENT_CAPTURE_RELEASED 8
+#define SONYPI_EVENT_CAPTURE_RELEASED 8 /* obsolete */
#define SONYPI_EVENT_CAPTURE_PARTIALPRESSED 9
#define SONYPI_EVENT_CAPTURE_PARTIALRELEASED 10
#define SONYPI_EVENT_FNKEY_ESC 11
@@ -93,7 +93,7 @@
#define SONYPI_EVENT_MEYE_OPPOSITE 53
#define SONYPI_EVENT_MEMORYSTICK_INSERT 54
#define SONYPI_EVENT_MEMORYSTICK_EJECT 55
-
+#define SONYPI_EVENT_ANYBUTTON_RELEASED 56
/* get/set brightness */
#define SONYPI_IOCGBRT _IOR('v', 0, __u8)
===== drivers/char/sonypi.h 1.13 vs edited =====
--- 1.13/drivers/char/sonypi.h Mon Dec 2 12:16:40 2002
+++ edited/drivers/char/sonypi.h Wed Dec 11 15:33:00 2002
@@ -37,7 +37,7 @@
#ifdef __KERNEL__
#define SONYPI_DRIVER_MAJORVERSION 1
-#define SONYPI_DRIVER_MINORVERSION 16
+#define SONYPI_DRIVER_MINORVERSION 17
#define SONYPI_DEVICE_MODEL_TYPE1 1
#define SONYPI_DEVICE_MODEL_TYPE2 2
@@ -171,6 +171,13 @@
u8 data;
u8 event;
};
+
+/* The set of possible button release events */
+static struct sonypi_event sonypi_releaseev[] = {
+ { 0x00, SONYPI_EVENT_ANYBUTTON_RELEASED },
+ { 0, 0 }
+};
+
/* The set of possible jogger events */
static struct sonypi_event sonypi_joggerev[] = {
{ 0x1f, SONYPI_EVENT_JOGDIAL_UP },
@@ -186,7 +193,6 @@
{ 0x5d, SONYPI_EVENT_JOGDIAL_VFAST_UP_PRESSED },
{ 0x43, SONYPI_EVENT_JOGDIAL_VFAST_DOWN_PRESSED },
{ 0x40, SONYPI_EVENT_JOGDIAL_PRESSED },
- { 0x00, SONYPI_EVENT_JOGDIAL_RELEASED },
{ 0, 0 }
};
@@ -195,7 +201,6 @@
{ 0x05, SONYPI_EVENT_CAPTURE_PARTIALPRESSED },
{ 0x07, SONYPI_EVENT_CAPTURE_PRESSED },
{ 0x01, SONYPI_EVENT_CAPTURE_PARTIALRELEASED },
- { 0x00, SONYPI_EVENT_CAPTURE_RELEASED },
{ 0, 0 }
};
@@ -293,6 +298,7 @@
unsigned long mask;
struct sonypi_event * events;
} sonypi_eventtypes[] = {
+ { SONYPI_DEVICE_MODEL_TYPE1, 0, 0xffffffff, sonypi_releaseev },
{ SONYPI_DEVICE_MODEL_TYPE1, 0x70, SONYPI_MEYE_MASK, sonypi_meyeev },
{ SONYPI_DEVICE_MODEL_TYPE1, 0x30, SONYPI_LID_MASK, sonypi_lidev },
{ SONYPI_DEVICE_MODEL_TYPE1, 0x60, SONYPI_CAPTURE_MASK, sonypi_captureev },
@@ -301,6 +307,7 @@
{ SONYPI_DEVICE_MODEL_TYPE1, 0x30, SONYPI_BLUETOOTH_MASK, sonypi_blueev },
{ SONYPI_DEVICE_MODEL_TYPE1, 0x40, SONYPI_PKEY_MASK, sonypi_pkeyev },
+ { SONYPI_DEVICE_MODEL_TYPE2, 0, 0xffffffff, sonypi_releaseev },
{ SONYPI_DEVICE_MODEL_TYPE2, 0x38, SONYPI_LID_MASK, sonypi_lidev },
{ SONYPI_DEVICE_MODEL_TYPE2, 0x08, SONYPI_JOGGER_MASK, sonypi_joggerev },
{ SONYPI_DEVICE_MODEL_TYPE2, 0x08, SONYPI_CAPTURE_MASK, sonypi_captureev },
===== drivers/char/sonypi.c 1.12 vs edited =====
--- 1.12/drivers/char/sonypi.c Fri Nov 22 14:46:41 2002
+++ edited/drivers/char/sonypi.c Wed Dec 11 12:34:17 2002
@@ -714,11 +714,11 @@
SONYPI_DRIVER_MAJORVERSION,
SONYPI_DRIVER_MINORVERSION);
printk(KERN_INFO "sonypi: detected %s model, "
- "verbose = %s, fnkeyinit = %s, camera = %s, "
+ "verbose = %d, fnkeyinit = %s, camera = %s, "
"compat = %s, mask = 0x%08lx\n",
(sonypi_device.model == SONYPI_DEVICE_MODEL_TYPE1) ?
"type1" : "type2",
- verbose ? "on" : "off",
+ verbose,
fnkeyinit ? "on" : "off",
camera ? "on" : "off",
compat ? "on" : "off",
--
Stelian Pop <stelian@popies.net>
^ permalink raw reply
* RE: Regarding consistent_alloc
From: acurtis @ 2002-12-11 14:41 UTC (permalink / raw)
To: Pantelis Antoniou, joakim.tjernlund
Cc: acurtis, Tom Rini, Dan Malek, Paul Mackerras, Matt Porter,
linuxppc-embedded
In-Reply-To: <3DF70C55.3010709@intracom.gr>
> >>m8xx_cpm_hostalloc(), if it is anything like the 8260 version,
> enables you
> >>to allocation memory from dual-port RAM. (which could be handy and/or
> >>required for certain CPM related operations) _va() and _pa()
> only work for
> >>main memory addresses. For all other address ranges the iopa()
> function must
> >>be used. (I hope this is helpful)
> >>
snip
>
> Each platform which is based on 8xx defines the amount of uncached
> memory that is expected
> to be used by it's drivers. It's not hard to make a rough estimation
> since most people
> that use the 8xx have very tight control of the hardware.
> We organize then the memory in a heap, which is able to do allocations and
> deallocations properly. That allows drivers that are loaded as modules
> to operate
> correctly and does not fragment (much) the memory.
I almost missed the context change here... Changing xxx_cpm_hostalloc() to
be consistent with other main memory allocation routines would probably be a
good thing. However there is still a need to manage the dual-port RAM, i.e.
xxx_cpm_dpalloc(), where this requirement is probably not practical. The
only way to make this happen is to force all memory regions to be contiguous
both virtually and physically to enable the "simpler" address translation
routines to function properly.
As for a iova() routine, ioremap() will return a previously configured
virtual address when asked to map the same physical memory space.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Why does C3 CPU downgrade in kernel 2.4.20?
From: Dave Jones @ 2002-12-11 14:59 UTC (permalink / raw)
To: Denis Vlasenko; +Cc: Daniel Egger, Joseph, linux-kernel@vger.kernel.org
In-Reply-To: <200212111419.gBBEJua06684@Port.imtp.ilyichevsk.odessa.ua>
On Wed, Dec 11, 2002 at 05:09:34PM -0200, Denis Vlasenko wrote:
> > > I heard cmovs are microcoded in Centaurs.
> > > s...l...o...w...
> > Hardly surprising given that the chip isn't targetted at the
> > performance market.
> *We Support 686 Instruction Set* plastered everywhere? ;)
It's an *optional* extension to the 686 as stated in
the Intel documentation.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* [PATCH 2.4.21-pre1] sonypi driver update
From: Stelian Pop @ 2002-12-11 14:51 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Marcelo Tosatti
Hi,
This little patch changes the way button release events are reported
by the sonypi driver to the application: previously, separate
release events were detected for each button. However, many buttons
(example: the jogdial, the capture button, the back button etc) share
the same release event.
The attached patch propagates a single 'ANYBUTTON_RELEASED' event
to the userspace, leaving all state machine intelligence to the
application.
Kunihiko IMAI should be credited for his ideas and tests.
Marcelo, please apply.
Stelian.
===== include/linux/sonypi.h 1.7 vs edited =====
--- 1.7/include/linux/sonypi.h Mon Dec 2 12:19:31 2002
+++ edited/include/linux/sonypi.h Wed Dec 11 10:37:00 2002
@@ -43,9 +43,9 @@
#define SONYPI_EVENT_JOGDIAL_DOWN_PRESSED 3
#define SONYPI_EVENT_JOGDIAL_UP_PRESSED 4
#define SONYPI_EVENT_JOGDIAL_PRESSED 5
-#define SONYPI_EVENT_JOGDIAL_RELEASED 6
+#define SONYPI_EVENT_JOGDIAL_RELEASED 6 /* obsolete */
#define SONYPI_EVENT_CAPTURE_PRESSED 7
-#define SONYPI_EVENT_CAPTURE_RELEASED 8
+#define SONYPI_EVENT_CAPTURE_RELEASED 8 /* obsolete */
#define SONYPI_EVENT_CAPTURE_PARTIALPRESSED 9
#define SONYPI_EVENT_CAPTURE_PARTIALRELEASED 10
#define SONYPI_EVENT_FNKEY_ESC 11
@@ -93,6 +93,7 @@
#define SONYPI_EVENT_MEYE_OPPOSITE 53
#define SONYPI_EVENT_MEMORYSTICK_INSERT 54
#define SONYPI_EVENT_MEMORYSTICK_EJECT 55
+#define SONYPI_EVENT_ANYBUTTON_RELEASED 56
/* get/set brightness */
#define SONYPI_IOCGBRT _IOR('v', 0, __u8)
===== drivers/char/sonypi.h 1.12 vs edited =====
--- 1.12/drivers/char/sonypi.h Mon Dec 2 12:16:22 2002
+++ edited/drivers/char/sonypi.h Wed Dec 11 15:32:51 2002
@@ -37,7 +37,7 @@
#ifdef __KERNEL__
#define SONYPI_DRIVER_MAJORVERSION 1
-#define SONYPI_DRIVER_MINORVERSION 16
+#define SONYPI_DRIVER_MINORVERSION 17
#define SONYPI_DEVICE_MODEL_TYPE1 1
#define SONYPI_DEVICE_MODEL_TYPE2 2
@@ -171,6 +171,13 @@
u8 data;
u8 event;
};
+
+/* The set of possible button release events */
+static struct sonypi_event sonypi_releaseev[] = {
+ { 0x00, SONYPI_EVENT_ANYBUTTON_RELEASED },
+ { 0, 0 }
+};
+
/* The set of possible jogger events */
static struct sonypi_event sonypi_joggerev[] = {
{ 0x1f, SONYPI_EVENT_JOGDIAL_UP },
@@ -186,7 +193,6 @@
{ 0x5d, SONYPI_EVENT_JOGDIAL_VFAST_UP_PRESSED },
{ 0x43, SONYPI_EVENT_JOGDIAL_VFAST_DOWN_PRESSED },
{ 0x40, SONYPI_EVENT_JOGDIAL_PRESSED },
- { 0x00, SONYPI_EVENT_JOGDIAL_RELEASED },
{ 0, 0 }
};
@@ -195,7 +201,6 @@
{ 0x05, SONYPI_EVENT_CAPTURE_PARTIALPRESSED },
{ 0x07, SONYPI_EVENT_CAPTURE_PRESSED },
{ 0x01, SONYPI_EVENT_CAPTURE_PARTIALRELEASED },
- { 0x00, SONYPI_EVENT_CAPTURE_RELEASED },
{ 0, 0 }
};
@@ -293,6 +298,7 @@
unsigned long mask;
struct sonypi_event * events;
} sonypi_eventtypes[] = {
+ { SONYPI_DEVICE_MODEL_TYPE1, 0, 0xffffffff, sonypi_releaseev },
{ SONYPI_DEVICE_MODEL_TYPE1, 0x70, SONYPI_MEYE_MASK, sonypi_meyeev },
{ SONYPI_DEVICE_MODEL_TYPE1, 0x30, SONYPI_LID_MASK, sonypi_lidev },
{ SONYPI_DEVICE_MODEL_TYPE1, 0x60, SONYPI_CAPTURE_MASK, sonypi_captureev },
@@ -301,6 +307,7 @@
{ SONYPI_DEVICE_MODEL_TYPE1, 0x30, SONYPI_BLUETOOTH_MASK, sonypi_blueev },
{ SONYPI_DEVICE_MODEL_TYPE1, 0x40, SONYPI_PKEY_MASK, sonypi_pkeyev },
+ { SONYPI_DEVICE_MODEL_TYPE2, 0, 0xffffffff, sonypi_releaseev },
{ SONYPI_DEVICE_MODEL_TYPE2, 0x38, SONYPI_LID_MASK, sonypi_lidev },
{ SONYPI_DEVICE_MODEL_TYPE2, 0x08, SONYPI_JOGGER_MASK, sonypi_joggerev },
{ SONYPI_DEVICE_MODEL_TYPE2, 0x08, SONYPI_CAPTURE_MASK, sonypi_captureev },
===== drivers/char/sonypi.c 1.11 vs edited =====
--- 1.11/drivers/char/sonypi.c Fri Nov 22 14:49:08 2002
+++ edited/drivers/char/sonypi.c Wed Dec 11 12:34:16 2002
@@ -714,11 +714,11 @@
SONYPI_DRIVER_MAJORVERSION,
SONYPI_DRIVER_MINORVERSION);
printk(KERN_INFO "sonypi: detected %s model, "
- "verbose = %s, fnkeyinit = %s, camera = %s, "
+ "verbose = %d, fnkeyinit = %s, camera = %s, "
"compat = %s, mask = 0x%08lx\n",
(sonypi_device.model == SONYPI_DEVICE_MODEL_TYPE1) ?
"type1" : "type2",
- verbose ? "on" : "off",
+ verbose,
fnkeyinit ? "on" : "off",
camera ? "on" : "off",
compat ? "on" : "off",
--
Stelian Pop <stelian@popies.net>
^ permalink raw reply
* Re: [PATCH] dm.c - device-mapper I/O path fixes
From: Kevin Corry @ 2002-12-11 14:06 UTC (permalink / raw)
To: Denis Vlasenko, Joe Thornber; +Cc: Kernel Mailing List, lvm-devel
In-Reply-To: <200212111435.gBBEYWa06788@Port.imtp.ilyichevsk.odessa.ua>
On Wednesday 11 December 2002 13:24, Denis Vlasenko wrote:
> On 11 December 2002 12:18, Joe Thornber wrote:
> > On Wed, Dec 11, 2002 at 07:16:53AM -0600, Kevin Corry wrote:
> > > However, it might be a good idea to consider how bio's keep track
> > > of errors. When a bio is created, it is marked UPTODATE. Then, if
> > > any part of a bio takes an error, the UPTODATE flag is turned off.
> > > When the whole bio completes, if the UPTODATE flag is still on,
> > > there were no errors during the i/o. Perhaps the "error" field in
> > > "struct dm_io" could be modified to use this method of error
> > > tracking? Then we could change dec_pending() to be something like:
> > >
> > > if (error)
> > > clear_bit(DM_IO_UPTODATE, &io->error);
> > >
> > > with a "set_bit(DM_IO_UPTODATE, &ci.io->error);" in __bio_split().
> >
> > The problem with this is you don't keep track of the specific error
> > to later pass to bio_endio(io->bio...). I guess it all comes down to
> > just how expensive that spin lock is; and since locking only occurs
> > when there's an error I'm happy with things as they are.
>
> lock();
> a = b;
> unlock();
>
> Store of ints is atomic anyway. You need locking if a is a larger entity,
> say, a struct.
Storing an int is *not* atomic unless it is declared as atomic_t and you use
the appropriate macros (see include/asm-*/atomic.h). Remember, we are talking
about a field in a data structure that can be accessed from multiple threads
on multiple CPUs.
--
Kevin Corry
corryk@us.ibm.com
http://evms.sourceforge.net/
^ 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.