* Re: What means "\xc7\x44\x24\x18\xda\xff\xff\xff\xe8"
From: Dan Sheppard @ 2006-04-10 20:17 UTC (permalink / raw)
To: openbsd shen; +Cc: kernel
In-Reply-To: <6ff3e7140604051838k1b332990i488f373aad99fa71@mail.gmail.com>
I can explain this, but I'll need a bit more convincing about your whitehated-ness.
I've been dabbling for a while with custom-kitting a honeypot machine with a kit
which sits under suckit2 and event-logs it, to see what da kidz get up to on
sukit'ed machines. Just curiosity, really, having come up against suckit a fair
few times.
Dan.
^ permalink raw reply
* [PATCH] au1100fb suspend/resume support
From: Rodolfo Giometti @ 2006-04-10 20:25 UTC (permalink / raw)
To: linux-mips; +Cc: source
[-- Attachment #1: Type: text/plain, Size: 356 bytes --]
Hello,
here a patch for au1100fb.c in order to add suspend/resume support.
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail: giometti@enneenne.com
Linux Device Driver giometti@gnudd.com
Embedded Systems giometti@linux.it
UNIX programming phone: +39 349 2432127
[-- Attachment #2: patch-au1100fb-pm --]
[-- Type: text/plain, Size: 2248 bytes --]
Index: drivers/video/au1100fb.c
===================================================================
RCS file: /home/develop/cvs_private/linux-mips-exadron/drivers/video/au1100fb.c,v
retrieving revision 1.7
diff -u -r1.7 au1100fb.c
--- a/drivers/video/au1100fb.c 2 Jan 2006 16:53:11 -0000 1.7
+++ b/drivers/video/au1100fb.c 10 Apr 2006 20:18:40 -0000
@@ -7,6 +7,8 @@
* Karl Lessard <klessard@sunrisetelecom.com>
* <c.pellegrin@exadron.com>
*
+ * PM support added by Rodolfo Giometti <giometti@linux.it>
+ *
* Copyright 2002 MontaVista Software
* Author: MontaVista Software, Inc.
* ppopov@mvista.com or source@mvista.com
@@ -648,17 +650,66 @@
return 0;
}
+#ifdef CONFIG_PM
+static u32 sys_clksrc;
+static struct au1100fb_regs fbregs;
int au1100fb_drv_suspend(struct device *dev, u32 state, u32 level)
{
- /* TODO */
+ struct au1100fb_device *fbdev = (struct au1100fb_device*) dev_get_drvdata(dev);
+
+ if (!fbdev)
+ return 0;
+
+ switch (level) {
+ case SUSPEND_DISABLE :
+ /* Save the clock source state */
+ sys_clksrc = au_readl(SYS_CLKSRC);
+
+ /* Blank the LCD */
+ au1100fb_fb_blank(VESA_POWERDOWN, &fbdev->info);
+
+ /* Stop LCD clocking */
+ au_writel(sys_clksrc & ~SYS_CS_MUD_MASK, SYS_CLKSRC);
+
+ break;
+
+ case SUSPEND_SAVE_STATE :
+ memcpy(&fbregs, fbdev->regs, sizeof(struct au1100fb_regs));
+
+ break;
+
+ case SUSPEND_POWER_DOWN :
+
+ break;
+ }
+
return 0;
}
int au1100fb_drv_resume(struct device *dev, u32 level)
{
- /* TODO */
+ struct au1100fb_device *fbdev = (struct au1100fb_device*) dev_get_drvdata(dev);
+
+ if (!fbdev)
+ return 0;
+
+ switch (level) {
+ case RESUME_RESTORE_STATE :
+ memcpy(fbdev->regs, &fbregs, sizeof(struct au1100fb_regs));
+
+ break;
+
+ case RESUME_ENABLE :
+ au_writel(sys_clksrc, SYS_CLKSRC);
+
+ au1100fb_fb_blank(VESA_NO_BLANKING, &fbdev->info);
+
+ break;
+ }
+
return 0;
}
+#endif
static struct device_driver au1100fb_driver = {
.name = "au1100-lcd",
@@ -666,8 +717,10 @@
.probe = au1100fb_drv_probe,
.remove = au1100fb_drv_remove,
+#ifdef CONFIG_PM
.suspend = au1100fb_drv_suspend,
.resume = au1100fb_drv_resume,
+#endif
};
/*-------------------------------------------------------------------------*/
^ permalink raw reply
* Re: [RFC/PATCH] Shared Page Tables [0/2]
From: Dave McCracken @ 2006-04-10 20:11 UTC (permalink / raw)
To: Christoph Lameter
Cc: Hugh Dickins, Linux Kernel Mailing List, Linux Memory Management,
Adam Litke, wli
In-Reply-To: <Pine.LNX.4.64.0604101020230.22947@schroedinger.engr.sgi.com>
--On Monday, April 10, 2006 10:22:34 -0700 Christoph Lameter
<clameter@sgi.com> wrote:
>> Here's a new cut of the shared page table patch. I divided it into
>> two patches. The first one just fleshes out the
>> pxd_page/pxd_page_kernel macros across the architectures. The
>> second one is the main patch.
>> (...)
>
> Could you break out the locking changes to huge pages?
The lock changes to hugetlb are only to support sharing of pmd pages when
they contain hugetlb pages. They just substitute the struct page lock for
the page_table_lock, and are only about 30 lines of code. Is this really
worth separating out?
Dave McCracken
^ permalink raw reply
* Re: [RFC/PATCH] Shared Page Tables [0/2]
From: Dave McCracken @ 2006-04-10 20:11 UTC (permalink / raw)
To: Christoph Lameter
Cc: Hugh Dickins, Linux Kernel Mailing List, Linux Memory Management,
Adam Litke, wli
In-Reply-To: <Pine.LNX.4.64.0604101020230.22947@schroedinger.engr.sgi.com>
--On Monday, April 10, 2006 10:22:34 -0700 Christoph Lameter
<clameter@sgi.com> wrote:
>> Here's a new cut of the shared page table patch. I divided it into
>> two patches. The first one just fleshes out the
>> pxd_page/pxd_page_kernel macros across the architectures. The
>> second one is the main patch.
>> (...)
>
> Could you break out the locking changes to huge pages?
The lock changes to hugetlb are only to support sharing of pmd pages when
they contain hugetlb pages. They just substitute the struct page lock for
the page_table_lock, and are only about 30 lines of code. Is this really
worth separating out?
Dave McCracken
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* . and .. on search results
From: Steve French @ 2006-04-10 20:11 UTC (permalink / raw)
To: linux-fsdevel
There are cases in which servers fails to return . and .. in search
(readdir) results over CIFS. In particular Windows servers which
export the root of a drive.
Is returning . and .. in readdir results always required (ie a client
change is necessary to insert them if they were not returned)? and do .
and .. have to be first in the list of entries in the directory (which
would be very inconvenient since I may have to read through all of the
directory search results)? Although . and .. are usually returned in
the first of what could be many search (Transact2 FindNext) responses
from the server, I don't think it is required.
^ permalink raw reply
* Re: Black box flight recorder for Linux
From: linux-os (Dick Johnson) @ 2006-04-10 20:07 UTC (permalink / raw)
To: Krzysztof Halasa; +Cc: Andi Kleen, Robert Hancock, linux-kernel
In-Reply-To: <m3k69xkygp.fsf@defiant.localdomain>
On Mon, 10 Apr 2006, Krzysztof Halasa wrote:
> "linux-os \(Dick Johnson\)" <linux-os@analogic.com> writes:
>
>> Further, in a boot where the BIOS needs to initialize hardware,
>> It will write all RAM before enabling NMI. This makes sure that
>> the parity bit(s) are set properly. Most BIOS will attempt to
>> preserve RAM on a 'warm' boot as a throw-back to the '286 days
>> with their above-1MB-memory-manager paged RAM because the
>> only way to get back from protected mode to 16-bit real mode
>> was a hardware reset.
>
> I think there is no distinction WRT RAM test between cold and warm
> boot anymore. If the BIOS clears the RAM is, I think, determined by
> the "fast POST" option in BIOS setup (it always checks the size
> so some bytes will be changed anyway).
>
>> When using a memory-manager like DOS's
>> HIMEM.SYS, you might actually be rebooting the machine hundreds
>> of times per second!
>
> Yes but it uses (or, rather, used) a CMOS flag to skip POST (not only
> the RAM test) and to go directly to the entry point in real mode.
>
> IIRC (I may be wrong, that was 15+ years ago) only 286 required
> KBC reset to return to real mode (did LOADALL matter?), 386s have
> no such problem.
>
>
> BTW I understand the idea have nothing to do with actual aircraft,
> so it would be the admin rather than NTSB looking at the data(?).
> --
> Krzysztof Halasa
Yes. After I responded and after reading other responses I noted that
the idea was to review the reason for a PC crash. There are no
good places to store things that can be counted upon to remain after
a crash. Even though CMOS RAM goes to 0x7f and not all of it is
needed for BIOS setup, many/(maybe all) BIOS checksum the whole
thing with some hair-brained checksum routines so it's not a good
place to store things. Many BIOS use 128k or more, which can
be re-written in 64k pages. Certainly there is space available
...but... the BIOS would be trashed if a power-failure occurred
during the write, so that's not a good place either. I did, at
one time, use a "spare" page of screen memory (one that wasn't
displayed) during the boot process (buffering for a bootable NVRAM
disk). This is "available" RAM, but it isn't going to survive
even as screen-card reset!
Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.42 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
\x1a\x04
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
^ permalink raw reply
* Re: GPIO endianness on MPC8349
From: Kumar Gala @ 2006-04-10 20:06 UTC (permalink / raw)
To: bwarren; +Cc: linuxppc-embedded
In-Reply-To: <1144698501.972.103.camel@saruman.qstreams.net>
On Apr 10, 2006, at 2:48 PM, Ben Warren wrote:
> Hello,
>
> I'm a noobie to this CPU, and am utterly confused with how the bits
> are
> ordered on the GPIO ports. I imagine it's the same as all Freescale
> PPCs, but who knows. Anyway...
>
> Using an MPC8349MDS eval board, I have one LED to play with. From the
> schematic, it's connected to GPIO1[1]. From other processors that
> I've
> worked with, I would have expected to toggle it with either 0x40000000
> (IBM 405) or 0x00000002 (68360). Nope. To make this bit move, I mess
> with bit 0x00000040 in the appropriate DAT register. This leads me to
> believe that either the bit ordering is something
> like ...89abcdef01234567 (sorry for the confusing notation, but
> hopefully it makes sense) or the schematic has a typo. Since I'm
> trying
> to write a generic GPIO handler, I'd like to have a little
> confidence in
> my extrapolation from a single point.
>
> Can anybody shed some light on this?
This is because the Freescale docs are misleading. If you look at
the schematic you will see the LED is wired to GPIO1[5] which makes
sense for the 0x40 value you have to use.
- kumar
^ permalink raw reply
* Re: Change outbound ICMP source
From: R. DuFresne @ 2006-04-10 20:05 UTC (permalink / raw)
To: Nathaniel Hall; +Cc: netfilter
In-Reply-To: <443A9DA4.30801@gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 10 Apr 2006, Nathaniel Hall wrote:
> I have been trying to figure out how to change the source IP address of an
> ICMP packet that originates from the firewall. Here is my application.
>
> Instead of dropping a packet I reject it with ICMP host unreachable messages.
> I would like to make it appear that the firewall isn't there, so I would like
> to change the source IP address to be that of our upstream router. How would
> I go about doing this?
>
>
by blocking the ICMP's at that upstream router.
Thanks,
Ron DuFresne
- --
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
admin & senior security consultant: sysinfo.com
http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A E838 B2DF AFCC 94B0 6629
...We waste time looking for the perfect lover
instead of creating the perfect love.
-Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFEOrqOst+vzJSwZikRAuLvAJ4xoqhQ7URdwmnuie+bsB7XLqz5WwCfYzBQ
7xiEJTytpedk3pYCnKSGnkQ=
=rfrz
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: command queueing cmd_per_lun, queue_depth and tags
From: Brian King @ 2006-04-10 20:04 UTC (permalink / raw)
To: Patrick Mansfield; +Cc: linux-scsi
In-Reply-To: <20060410185919.GA15124@us.ibm.com>
Patrick Mansfield wrote:
> On Fri, Apr 07, 2006 at 05:29:28PM -0500, Brian King wrote:
>> Patrick Mansfield wrote:
>>> Currently cmd_per_lun is the default queue depth for both tagged and
>>> untagged queueing. That is, if the LLDD does not modify queue_depth in its
>>> slave_configure, queue_depth will be set to cmd_per_lun, no matter what
>>> the command queueing/tag support.
>>>
>>> If we don't allow queueing in the LLDD, and cmd_per_lun is supposed to be
>>> the default depth for untagged support, shouldn't it always be 1, and
>>> hence go away?
>> This seems to assume there are no SCSI devices which do command queuing, but do
>> not support queue tags. This is not the case.
>
> I should not have used "untagged", that is misleading and a problem with
> current scsi core, where we reference tcq, tags, and don't seem to mention
> task attributes.
>
> But LLDD can override anything in slave_configure.
I guess my biggest problem with this part of the patch is that it prevents an
LLDD that wants this behavior from being able to use scsi_adjust_queue_depth
to set the queue depth, whether it be in slave_configure, change_queue_depth, etc.
> Also, it looks like we could safely use cmd_per_lun as the default
> queue_depth, rather than setting it to 1 as done in my previous
> post/patch.
Ok. If we do that and also allow scsi_adjust_queue_depth
to adjust the queue depth when tagged == 0, as is allowed today,
then I think most of my objections to the patch should disappear,
although it may require me to make a couple ipr changes.
>>> Similarily, why do some LLDD's use a cmd_per_lun of 3, or (like
>>> ncr53c8xx_slave_configure) set queue_depth for !tagged_supported to
>>> anything other than 1?
>> In the case of ipr, there are two scenarios. The first is for JBOD disks.
>> I use a default queue depth of 6 in ipr. When running untagged, with a queue depth
>> of > 1, the ipr adapter firmware then maintains a queue, guaranteeing only
>> one command will be outstanding to the device at once. This lower level
>> queue allows for a faster turnaround of commands and improved performance.
>> The second case is that of RAID arrays. These show up as logical scsi disks.
>> They support command queueing, but not tagged command queueing.
>
> So you just want the task attibutes, and don't care about tag management
> (i.e. you don't ever use cmd->request->tags)? That is similar to FCP.
Correct. The ipr adapter firmware generates its own queue tags before sending
tagged commands to the device.
>>> I know (at least) FCP can always do simple queueing, but I don't think
>>> scsi core should allow multiple commands to be sent if the device does not
>>> have CMDQUE (or BQUE).
>> This will break both of the working scenarios I described above for ipr
>> and performance will suffer significantly. The inquiry data for ipr RAID
>> arrays does not set either CMDQUE or BQUE.
>
> Sounds like they are sort of SCSI-2 compliant, that is allowed there but
> mentioned as obsolete in current SCSI-3 (spc3r23.pdf).
>
> The LLDD can override the queue_depth for these cases.
Agreed, but my first comment applies here as well.
>>> Also we don't even check the BQUE in the INQUIRY result (byte 6, bit 7).
>>> Should this be changed? That is set tagged_supported if BQUE is set, like
>>> we do for CMDQUE (byte 7 bit 1). And also set simple_tags if
>>> tagged_supported is set.
>> I don't like the idea of always enabling TCQ in scsi core simply if
>> the device supports it. What if the HBA does not support it? To make
>> matters more interesting, what if the HBA does not support TCQ, but does
>> support untagged command queueing, similar to ipr as described above?
>
> They can override it in slave_configure.
Sure. I could add a scsi_deactivate_tcq in slave_configure.
--
Brian King
eServer Storage I/O
IBM Linux Technology Center
^ permalink raw reply
* Re: [spi-devel-general] [PATCH][2.16.17-rc1-mm2] spi: Added spi master driver for Freescale MPC83xx SPI controller
From: Vitaly Wool @ 2006-04-10 20:03 UTC (permalink / raw)
To: Kumar Gala; +Cc: David Brownell, Greg KH, linux-kernel, spi-devel-general
In-Reply-To: <Pine.LNX.4.44.0604101414500.5501-100000@gate.crashing.org>
Hi,
Kumar Gala wrote:
>+irqreturn_t mpc83xx_spi_irq(s32 irq, void *context_data,
>+ struct pt_regs * ptregs)
>+{
>+ struct mpc83xx_spi *mpc83xx_spi = context_data;
>+ u32 event;
>+ irqreturn_t ret = IRQ_NONE;
>+
>+ /* Get interrupt events(tx/rx) */
>+ event = mpc83xx_spi_read_reg(&mpc83xx_spi->base->event);
>+
>+ /* We need handle RX first */
>+ if (event & SPIE_NE) {
>+ u32 rx_data = mpc83xx_spi_read_reg(&mpc83xx_spi->base->receive);
>+
>+ if (mpc83xx_spi->rx)
>+ mpc83xx_spi->get_rx(rx_data, mpc83xx_spi);
>+
>+ ret = IRQ_HANDLED;
>+ }
>+
>+ if ((event & SPIE_NF) == 0)
>+ /* spin until TX is done */
>+ while (((event =
>+ mpc83xx_spi_read_reg(&mpc83xx_spi->base->event)) &
>+ SPIE_NF) == 0)
>+ ;
>
>
This is a potentially endless loop so two questions here.
First, did you do any measurements on how long it can loop here?
The, what if a bus error occurs and this bit is never set?
>+
>+ mpc83xx_spi->count -= 1;
>+ if (mpc83xx_spi->count) {
>+ if (mpc83xx_spi->tx) {
>+ u32 word = mpc83xx_spi->get_tx(mpc83xx_spi);
>+ mpc83xx_spi_write_reg(&mpc83xx_spi->base->transmit,
>+ word);
>+ }
>+ } else {
>+ complete(&mpc83xx_spi->done);
>+ }
>
>
So, if it's not SPIE_NF, it's not marked as HANDLED?
Vitaly
^ permalink raw reply
* Important Reply....
From: Dr Frank, @ 2006-04-10 19:52 UTC (permalink / raw)
Dear Sir/Madam,
My name is Dr. Frank Jim, a senior staff and auditor
head of computing department here in our bank.I have only written to
seek your indulgence and assistance. I wish to make a transfer
involving a huge amount of £15,000,000.00.(fifteen million pounds
sterling).
I am proposing to make this transfer to a designated bank
account of your choice. Thus, for your indulgence and support, I
propose an offer of 25% of the total amount to be yours after the
transfer has been successfully concluded.
Kindly reply me stating
your interest, and I shall furnish you with the details and necessary
proceedure with which to make the transfer. I am anxiously awaiting
your response through my alternative email address: frankprivate@myway.
com : Please get back with your information. TELEPHONE NUMBER/FAX.
Thanks and Godbless.
Dr. Frank Jim.
............................................................................................................
DR. FRANK JIM, SENIOR STAFF AND AUDITOR HEAD OF COMPUTING
DEPARTMENT.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: Skype
From: Marc Haber @ 2006-04-10 20:01 UTC (permalink / raw)
To: netfilter
In-Reply-To: <443A89ED.1090800@caris.com>
On Mon, Apr 10, 2006 at 01:38:05PM -0300, Peter Marshall wrote:
> I keep getting articles on my desk, and reading news posts about how
> *bad* skype is. I just wanted to here what everyone here thinks of
> skype. Do any pf you allow it on your network ?
One customer of mine, a multinational enterprise with like 11K
employees in Germany alone, has completely banned Skype from the
network. I don't know what happened, but judging from the grade people
go ballistic if you even dare to mention "VoIP" or "Softphone", it was
something really really bad.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
^ permalink raw reply
* [PATCH] [BUG 143] [2nd try] Fix checksum errors over IPSec ESP tunnels
From: James Dykman @ 2006-04-10 19:59 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 7568 bytes --]
This patch moves the prep for checksum calculations from dev_queue_xmit()
into netback. The pointers in the skb headerare
set up for all IPv4 TCP/UDP traffic passing through netback, but the
checksums are not actually calculated until they absolutely
have to be (currently in dev_queue_xmit() and xfrm4_output()).
This removes some xen-specific code from the net/core/dev.c, at the
expense of some overhead for domU-domU traffic. Also
note that xfrm4_output() has to recalculate skb->h.raw, which gets
stomped. I have not bothered to track down where this happens;
I think it's a sign that setting up these pointers so far from where they
will be used is a bit fragile. But, it does work/fix the problem.
Tested on:
changeset: 9533:806d04252761
tag: tip
user: kaf24@firebug.cl.cam.ac.uk
date: Wed Apr 5 05:37:37 2006 +0100
summary: Fix checksum-offload problems introduced in c/s 9514, due to
With xm-test w/network-route/vif-route, and also with the failing config
from bug 143.
For reference, the first try:
http://lists.xensource.com/archives/html/xen-devel/2006-02/msg00162.html
Comments were:
http://lists.xensource.com/archives/html/xen-devel/2006-03/msg00521.html
Signed-off-by: Jim Dykman <dykman@us.ibm.com>
Jim
diff -r a8b1d4fad72d linux-2.6-xen-sparse/drivers/xen/netback/netback.c
--- a/linux-2.6-xen-sparse/drivers/xen/netback/netback.c Mon Mar 20
11:01:32 2006
+++ b/linux-2.6-xen-sparse/drivers/xen/netback/netback.c Fri Mar 24
16:45:17 2006
@@ -13,6 +13,9 @@
#include "common.h"
#include <xen/balloon.h>
#include <xen/interface/memory.h>
+#include <net/ip.h>
+#include <linux/tcp.h>
+#include <linux/udp.h>
/*#define NETBE_DEBUG_INTERRUPT*/
@@ -451,6 +454,33 @@
}
}
+inline static int checksum_setup(struct sk_buff *skb)
+{
+ if (skb->protocol != htons(ETH_P_IP))
+ return -1;
+ skb->nh.raw = skb->data;
+ skb->h.raw = (unsigned char *)skb->nh.iph + 4*skb->nh.iph->ihl;
+ if (skb->h.raw >= skb->tail)
+ return -1;
+ switch (skb->nh.iph->protocol) {
+ case IPPROTO_TCP:
+ skb->csum = offsetof(struct tcphdr, check);
+ break;
+ case IPPROTO_UDP:
+ skb->csum = offsetof(struct udphdr, check);
+ break;
+ default:
+ if (net_ratelimit())
+ printk(KERN_ERR "Attempting to checksum a non-"
+ "TCP/UDP packet, dropping a protocol"
diff -r a8b1d4fad72d linux-2.6-xen-sparse/drivers/xen/netback/netback.c
--- a/linux-2.6-xen-sparse/drivers/xen/netback/netback.c Mon Mar 20
11:01:32 2006
+++ b/linux-2.6-xen-sparse/drivers/xen/netback/netback.c Fri Mar 24
16:45:17 2006
@@ -13,6 +13,9 @@
#include "common.h"
#include <xen/balloon.h>
#include <xen/interface/memory.h>
+#include <net/ip.h>
+#include <linux/tcp.h>
+#include <linux/udp.h>
/*#define NETBE_DEBUG_INTERRUPT*/
@@ -451,6 +454,33 @@
}
}
+inline static int checksum_setup(struct sk_buff *skb)
+{
+ if (skb->protocol != htons(ETH_P_IP))
+ return -1;
+ skb->nh.raw = skb->data;
+ skb->h.raw = (unsigned char *)skb->nh.iph + 4*skb->nh.iph->ihl;
+ if (skb->h.raw >= skb->tail)
+ return -1;
+ switch (skb->nh.iph->protocol) {
+ case IPPROTO_TCP:
+ skb->csum = offsetof(struct tcphdr, check);
+ break;
+ case IPPROTO_UDP:
+ skb->csum = offsetof(struct udphdr, check);
+ break;
+ default:
+ if (net_ratelimit())
+ printk(KERN_ERR "Attempting to checksum a non-"
+ "TCP/UDP packet, dropping a protocol"
+ " %d packet",
skb->nh.iph->protocol);
+ return -1;
+ }
+ if ((skb->h.raw + skb->csum + 2) > skb->tail)
+ return -1;
+ return 0;
+}
+
/* Called after netfront has transmitted */
static void net_tx_action(unsigned long unused)
{
@@ -637,6 +667,14 @@
skb->ip_summed = CHECKSUM_UNNECESSARY;
skb->proto_csum_valid = 1;
skb->proto_csum_blank = !!(txreq.flags &
NETTXF_csum_blank);
+ if (skb->proto_csum_blank) {
+ ret = checksum_setup(skb);
+ if (ret < 0) {
+ kfree_skb(skb);
+ mop++;
+ continue;
+ }
+ }
netif->stats.rx_bytes += txreq.size;
netif->stats.rx_packets++;
diff -r a8b1d4fad72d linux-2.6-xen-sparse/net/core/dev.c
--- a/linux-2.6-xen-sparse/net/core/dev.c Mon Mar 20 11:01:32 2006
+++ b/linux-2.6-xen-sparse/net/core/dev.c Fri Mar 24 16:45:17 2006
@@ -116,12 +116,6 @@
#endif /* CONFIG_NET_RADIO */
#include <asm/current.h>
-#ifdef CONFIG_XEN
-#include <net/ip.h>
-#include <linux/tcp.h>
-#include <linux/udp.h>
-#endif
-
/*
* The list of packet types we will receive (as opposed to discard)
* and the routines to invoke.
@@ -1270,31 +1264,8 @@
/* If a checksum-deferred packet is forwarded to a device that
needs a
* checksum, correct the pointers and force checksumming.
*/
- if (skb->proto_csum_blank) {
- if (skb->protocol != htons(ETH_P_IP))
- goto out_kfree_skb;
- skb->h.raw = (unsigned char *)skb->nh.iph +
4*skb->nh.iph->ihl;
- if (skb->h.raw >= skb->tail)
- goto out_kfree_skb;
- switch (skb->nh.iph->protocol) {
- case IPPROTO_TCP:
- skb->csum = offsetof(struct tcphdr, check);
- break;
- case IPPROTO_UDP:
- skb->csum = offsetof(struct udphdr, check);
- break;
- default:
- if (net_ratelimit())
- printk(KERN_ERR "Attempting to checksum a
non-"
- "TCP/UDP packet, dropping a
protocol"
- " %d packet",
skb->nh.iph->protocol);
- rc = -EPROTO;
- goto out_kfree_skb;
- }
- if ((skb->h.raw + skb->csum + 2) > skb->tail)
- goto out_kfree_skb;
+ if (skb->proto_csum_blank)
skb->ip_summed = CHECKSUM_HW;
- }
#endif
/* If packet is not checksummed and device does not support
diff -r a8b1d4fad72d patches/linux-2.6.16-rc6/net-csum.patch
--- a/patches/linux-2.6.16/net-csum.patch Mon Mar 20 11:01:32 2006
+++ b/patches/linux-2.6.16/net-csum.patch Fri Mar 24 16:45:17 2006
@@ -39,3 +39,18 @@
*portptr = newport;
return 1;
}
+--- ../pristine-linux-2.6.16/net/ipv4/xfrm4_output.c 2006-03-24
16:17:38.000000000 -0500
++++ ./net/ipv4/xfrm4_output.c 2006-03-24 16:13:24.000000000 -0500
+@@ -103,6 +103,12 @@ static int xfrm4_output_one(struct sk_bu
+ struct xfrm_state *x = dst->xfrm;
+ int err;
+
++ if (skb->proto_csum_blank) {
++ skb->ip_summed = CHECKSUM_HW;
++ skb->proto_csum_blank = 0;
++ skb->h.raw = (unsigned char *)skb->nh.iph +
4*skb->nh.iph->ihl;
++ }
++
+ if (skb->ip_summed == CHECKSUM_HW) {
+ err = skb_checksum_help(skb, 0);
+ if (err)
[-- Attachment #2: bug143.patch.v2 --]
[-- Type: application/octet-stream, Size: 3993 bytes --]
diff -r a8b1d4fad72d linux-2.6-xen-sparse/drivers/xen/netback/netback.c
--- a/linux-2.6-xen-sparse/drivers/xen/netback/netback.c Mon Mar 20 11:01:32 2006
+++ b/linux-2.6-xen-sparse/drivers/xen/netback/netback.c Fri Mar 24 16:45:17 2006
@@ -13,6 +13,9 @@
#include "common.h"
#include <xen/balloon.h>
#include <xen/interface/memory.h>
+#include <net/ip.h>
+#include <linux/tcp.h>
+#include <linux/udp.h>
/*#define NETBE_DEBUG_INTERRUPT*/
@@ -451,6 +454,33 @@
}
}
+inline static int checksum_setup(struct sk_buff *skb)
+{
+ if (skb->protocol != htons(ETH_P_IP))
+ return -1;
+ skb->nh.raw = skb->data;
+ skb->h.raw = (unsigned char *)skb->nh.iph + 4*skb->nh.iph->ihl;
+ if (skb->h.raw >= skb->tail)
+ return -1;
+ switch (skb->nh.iph->protocol) {
+ case IPPROTO_TCP:
+ skb->csum = offsetof(struct tcphdr, check);
+ break;
+ case IPPROTO_UDP:
+ skb->csum = offsetof(struct udphdr, check);
+ break;
+ default:
+ if (net_ratelimit())
+ printk(KERN_ERR "Attempting to checksum a non-"
+ "TCP/UDP packet, dropping a protocol"
+ " %d packet", skb->nh.iph->protocol);
+ return -1;
+ }
+ if ((skb->h.raw + skb->csum + 2) > skb->tail)
+ return -1;
+ return 0;
+}
+
/* Called after netfront has transmitted */
static void net_tx_action(unsigned long unused)
{
@@ -637,6 +667,14 @@
skb->ip_summed = CHECKSUM_UNNECESSARY;
skb->proto_csum_valid = 1;
skb->proto_csum_blank = !!(txreq.flags & NETTXF_csum_blank);
+ if (skb->proto_csum_blank) {
+ ret = checksum_setup(skb);
+ if (ret < 0) {
+ kfree_skb(skb);
+ mop++;
+ continue;
+ }
+ }
netif->stats.rx_bytes += txreq.size;
netif->stats.rx_packets++;
diff -r a8b1d4fad72d linux-2.6-xen-sparse/net/core/dev.c
--- a/linux-2.6-xen-sparse/net/core/dev.c Mon Mar 20 11:01:32 2006
+++ b/linux-2.6-xen-sparse/net/core/dev.c Fri Mar 24 16:45:17 2006
@@ -116,12 +116,6 @@
#endif /* CONFIG_NET_RADIO */
#include <asm/current.h>
-#ifdef CONFIG_XEN
-#include <net/ip.h>
-#include <linux/tcp.h>
-#include <linux/udp.h>
-#endif
-
/*
* The list of packet types we will receive (as opposed to discard)
* and the routines to invoke.
@@ -1270,31 +1264,8 @@
/* If a checksum-deferred packet is forwarded to a device that needs a
* checksum, correct the pointers and force checksumming.
*/
- if (skb->proto_csum_blank) {
- if (skb->protocol != htons(ETH_P_IP))
- goto out_kfree_skb;
- skb->h.raw = (unsigned char *)skb->nh.iph + 4*skb->nh.iph->ihl;
- if (skb->h.raw >= skb->tail)
- goto out_kfree_skb;
- switch (skb->nh.iph->protocol) {
- case IPPROTO_TCP:
- skb->csum = offsetof(struct tcphdr, check);
- break;
- case IPPROTO_UDP:
- skb->csum = offsetof(struct udphdr, check);
- break;
- default:
- if (net_ratelimit())
- printk(KERN_ERR "Attempting to checksum a non-"
- "TCP/UDP packet, dropping a protocol"
- " %d packet", skb->nh.iph->protocol);
- rc = -EPROTO;
- goto out_kfree_skb;
- }
- if ((skb->h.raw + skb->csum + 2) > skb->tail)
- goto out_kfree_skb;
+ if (skb->proto_csum_blank)
skb->ip_summed = CHECKSUM_HW;
- }
#endif
/* If packet is not checksummed and device does not support
diff -r a8b1d4fad72d patches/linux-2.6.16-rc6/net-csum.patch
--- a/patches/linux-2.6.16/net-csum.patch Mon Mar 20 11:01:32 2006
+++ b/patches/linux-2.6.16/net-csum.patch Fri Mar 24 16:45:17 2006
@@ -39,3 +39,18 @@
*portptr = newport;
return 1;
}
+--- ../pristine-linux-2.6.16/net/ipv4/xfrm4_output.c 2006-03-24 16:17:38.000000000 -0500
++++ ./net/ipv4/xfrm4_output.c 2006-03-24 16:13:24.000000000 -0500
+@@ -103,6 +103,12 @@ static int xfrm4_output_one(struct sk_bu
+ struct xfrm_state *x = dst->xfrm;
+ int err;
+
++ if (skb->proto_csum_blank) {
++ skb->ip_summed = CHECKSUM_HW;
++ skb->proto_csum_blank = 0;
++ skb->h.raw = (unsigned char *)skb->nh.iph + 4*skb->nh.iph->ihl;
++ }
++
+ if (skb->ip_summed == CHECKSUM_HW) {
+ err = skb_checksum_help(skb, 0);
+ if (err)
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* GPIO endianness on MPC8349
From: Ben Warren @ 2006-04-10 19:48 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I'm a noobie to this CPU, and am utterly confused with how the bits are
ordered on the GPIO ports. I imagine it's the same as all Freescale
PPCs, but who knows. Anyway...
Using an MPC8349MDS eval board, I have one LED to play with. From the
schematic, it's connected to GPIO1[1]. From other processors that I've
worked with, I would have expected to toggle it with either 0x40000000
(IBM 405) or 0x00000002 (68360). Nope. To make this bit move, I mess
with bit 0x00000040 in the appropriate DAT register. This leads me to
believe that either the bit ordering is something
like ...89abcdef01234567 (sorry for the confusing notation, but
hopefully it makes sense) or the schematic has a typo. Since I'm trying
to write a generic GPIO handler, I'd like to have a little confidence in
my extrapolation from a single point.
Can anybody shed some light on this?
thanks,
Ben
^ permalink raw reply
* Re: RFC deprecating the possible action
From: Linda Knippers @ 2006-04-10 19:55 UTC (permalink / raw)
To: Steve Grubb; +Cc: Linux Audit
In-Reply-To: <200604101505.57763.sgrubb@redhat.com>
Steve Grubb wrote:
> We currently have 5 syscall rules in the capp.rules file and lspp.rules file
> that would be eliminated by this change. I could always delete them from the
> rule file, but other people will make the mistake of setting possible on some
> rules without studying the kernel code.
>
> What's people's thoughts on this?
I think if 'possible' no longer is needed, let's remove it. The only
reason I can think of for keeping it is if people want to have the
same rules file for RHEL4 as for RHEL5, in which case it could be
silently ignored or turned into a regular watch on a RHEL5 system.
- ljk
^ permalink raw reply
* [U-Boot-Users] U-boot 1.0.2
From: Wolfgang Denk @ 2006-04-10 19:50 UTC (permalink / raw)
To: u-boot
In-Reply-To: <D9DD9C6F41C7AF44AEF97CD16305DF80024EB7@server.Microsym.local>
In message <D9DD9C6F41C7AF44AEF97CD16305DF80024EB7@server.Microsym.local> you wrote:
>
> I am looking for u-boot v.1.0.2
> Maybe somebody have it.
All the servers do. Ask them, politely.
> ------_=_NextPart_001_01C65CD5.04728D83
> Content-Type: text/html;
> charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
And never post HTML on this list, please.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The speed of time is one second per second.
^ permalink raw reply
* Re: Slab errors on 4xx (STB04)
From: Andre Draszik @ 2006-04-10 19:48 UTC (permalink / raw)
To: Andre Draszik, linuxppc-embedded
In-Reply-To: <20060410071457.GA16898@gate.ebshome.net>
Eugene Surovegin wrote:
> On Mon, Apr 10, 2006 at 12:33:56AM +0200, Andre Draszik wrote:
>> Since it _seems_ to work nevertheless - is CONFIG_DEBUG_SLAB known to be
>> broken on this platform?
>
> Yes, it's very likely that CONFIG_DEBUG_SLAB is the culprit here. This
> [...]
Thanks Roland and Eugene for the advice.
> You can try changing __dma_sync() to do flush_dcache_range() even for
> DMA_FROM_DEVICE case. However, do this only to check this theory, not
> as a permanent solution :).
OK, I will play with the cache later today... I wanted DEBUG_SLAB turned
on for some other unrelated problem, so just for debugging, this hack
would be fine if it worked :)
Greetings,
Andre'
^ permalink raw reply
* Re: Problems compiling with GCC-4.0.0
From: Luís Cargnini @ 2006-04-10 19:48 UTC (permalink / raw)
To: linux-omap-open-source
In-Reply-To: <fb249edb0604100148m2f6857ds9413fabe953cc5a5@mail.gmail.com>
take a look at my blog
http://lvcargnini.blogspot.com/
On 4/10/06, andrzej zaborowski <balrog@zabor.org> wrote:
>
> Hi,
>
> On 10/04/06, Kanagesh R <kanagesh@india.com> wrote:
> > Hello,
> >
> > I have been using a toolchain built using crosstools.
> > The version of tools is as follows:
> > GCC-3.4.1
> > Binutils-2.15
> > GLIBC-2.3.2
> >
> > This has been compiling all kernels (2.6.12, 2.6.13,
> > 2.6.15) fine without any issues.
> >
> > I've now downloaded the ELDK (Ver 4) toolchain from
> > www.denx.de and I've tried to compile 2.6.15-omap1,
> > but without success. It breaks while compiling file
> > drivers/input/touchscreen/omap/ompa_ts.c (however,
> > when the same sources are compiled with GCC-3.4.1,
> > it builds fine)
> >
> > The version of tools in this toolchain is:
> > GCC-4.0.0
> > Binutils-2.16.1
> > GLIBC-2.3.5
> >
> > I then built a GCC-4.0.0 crosscompiler using crosstools
> > and I hit the same problem.
> >
> > Is anyone else using the ELDK-4.0 toolchain (or crosscompiler
> > GCC-4.0.0) and has similar problems?
>
> As far as I remember this has been already corrected. 2.6.15 was
> giving a couple of errors with GCC 4 but all of them trivially
> fixable.
> Please update your kernel sources.
> >
> > warm regards,
> > Kanagesh
> >
> >
> > --
> > India.com free e-mail - www.india.com.
> > Check out our value-added Premium features, such as an extra 20MB for
> mail storage, POP3, e-mail forwarding, and ads-free mailboxes!
> > _______________________________________________
> > Linux-omap-open-source mailing list
> > Linux-omap-open-source@linux.omap.com
> > http://linux.omap.com/mailman/listinfo/linux-omap-open-source
> >
>
> Regards,
> Andrew
> --
> balrog 2oo6
>
> Dear Outlook users: Please remove me from your address books
> http://www.newsforge.com/article.pl?sid=03/08/21/143258
>
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source
>
>
>
--
Thanks && Regards
Msc. Bsc. Luís Vitório Cargnini
IEEE Member
Mastering Degree student @ PUC-RS Electrical Engineer Faculty
^ permalink raw reply
* [U-Boot-Users] BDI vs. Lauterbach
From: Wolfgang Denk @ 2006-04-10 19:48 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1317633204.20060410215844@varma-el.com>
In message <1317633204.20060410215844@varma-el.com> you wrote:
>
> SH7751 family. TRACE32 know _nothing_ about new revision (7751R),
> and refuse to work at all. For a defeated of Lb,
> I could say that I don't know what Abatron offer in this situation,
> and this situation was 3 years ago.
> Wolfgang?
This probably depends on what was changed between versions, but I
guess the same szenario might happen with Abatron, too. But then, the
price for software updates + support is some 142 Euro per year, which
makes the decision easy enough.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You don't have to worry about me. I might have been born yesterday...
but I stayed up all night.
^ permalink raw reply
* Re: Device Mapper as a cache for SAN?
From: Eric Van Hensbergen @ 2006-04-10 19:46 UTC (permalink / raw)
To: device-mapper development
In-Reply-To: <20060410184531.GA12908@www.ewilts.org>
On 4/10/06, Ed Wilts <ewilts@ewilts.org> wrote:
>
> The obvious question is why? What would this provide that the kernel
> and file systems don't already provide?
>
Well, kernel provides in-memory page cache, not local disk page cache.
There is some ongoing remote file system local disk cache work being
done, but it applies primarily to AFS and NFS - not block-based
transports such as iSCSI and AOE. The various cluster file systems
may provide something more akin to this, but again, this doesn't
really cover SAN technologies -- not in any sort of a generic way.
Let me know if I'm missing something.
-eric
^ permalink raw reply
* question : transfer size
From: Raz Ben-Jehuda(caro) @ 2006-04-10 19:45 UTC (permalink / raw)
To: linux-ide@vger.kernel.org; +Cc: Jeff Garzik
Jeff hello.
i have been measuring the transer size of a request_t in
the deadline io scheduler dispatch request method.
i issued a dd of 1MB over a maxtor disk, which according
to the max_hw_sectors has 2048 sectors.
but in the scheduler i see only 1024 sectors.
So my question is:
where and how the transfer size is being determined ?
if i am going to expand the biovec size from 256 to 512
will it matter ?
thank you
--
Raz
^ permalink raw reply
* Re: Black box flight recorder for Linux
From: Krzysztof Halasa @ 2006-04-10 19:44 UTC (permalink / raw)
To: linux-os (Dick Johnson); +Cc: Andi Kleen, Robert Hancock, linux-kernel
In-Reply-To: <Pine.LNX.4.61.0604100754340.25546@chaos.analogic.com>
"linux-os \(Dick Johnson\)" <linux-os@analogic.com> writes:
> Further, in a boot where the BIOS needs to initialize hardware,
> It will write all RAM before enabling NMI. This makes sure that
> the parity bit(s) are set properly. Most BIOS will attempt to
> preserve RAM on a 'warm' boot as a throw-back to the '286 days
> with their above-1MB-memory-manager paged RAM because the
> only way to get back from protected mode to 16-bit real mode
> was a hardware reset.
I think there is no distinction WRT RAM test between cold and warm
boot anymore. If the BIOS clears the RAM is, I think, determined by
the "fast POST" option in BIOS setup (it always checks the size
so some bytes will be changed anyway).
> When using a memory-manager like DOS's
> HIMEM.SYS, you might actually be rebooting the machine hundreds
> of times per second!
Yes but it uses (or, rather, used) a CMOS flag to skip POST (not only
the RAM test) and to go directly to the entry point in real mode.
IIRC (I may be wrong, that was 15+ years ago) only 286 required
KBC reset to return to real mode (did LOADALL matter?), 386s have
no such problem.
BTW I understand the idea have nothing to do with actual aircraft,
so it would be the admin rather than NTSB looking at the data(?).
--
Krzysztof Halasa
^ permalink raw reply
* Re: Masquerading problems - XenU 3.0 on x86_64
From: Jim Pick @ 2006-04-10 19:43 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel Devel
In-Reply-To: <fcc37838df00f161b6a92dc569683a8e@cl.cam.ac.uk>
[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]
The last change I had on xen-3.0-testing.hg was:
changeset: 9612:32b22f5286be
user: kaf24@firebug.cl.cam.ac.uk
date: Thu Apr 6 18:34:32 2006 +0100
summary: Fix another blkback kernel thread I introduced. :-( The
kernel thread
(ignore the changeset number - I checked some stuff into my own hg
repository)
It looks like I had changeset 9579.
I built it from within a Domain 0 running the Debian unstable amd64
packages from amd64.debian.net.
$ gcc --version
gcc (GCC) 4.0.3 (Debian 4.0.3-1)
I'll attach my gzipped kernel config.
Anything else that would be useful? I can also grant you access to the
machine if that would be of any benefit.
Cheers,
- Jim
Keir Fraser wrote:
>
> On 9 Apr 2006, at 21:18, Jim Pick wrote:
>
>>>> Has anybody else encountered this? Also, if it's already been fixed
>>>> somewhere, I'd love to know. Any Netfilter debugging tips would
>>>> also be appreciated.
>>>
>>> Turn off tx checksum offload in your domU's using ethtool. We had
>>> fixed some forms of NAT with our checksum offload, but maybe not for
>>> your type of setup.
>>
>>
>> That fixed it. Thanks!
>
>
> It would be interesting to know more about your configuration, and also
> what Xen version you were using. Changeset 9579 fixed some bugs, so if
> your repository is older than that then you might well see problems.
>
> -- Keir
>
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 5311 bytes --]
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [Qemu-devel] USB Tablet Emulation
From: Brad Campbell @ 2006-04-10 19:44 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <443AB1E4.3050607@wasp.net.au>
[-- Attachment #1: Type: text/plain, Size: 818 bytes --]
Brad Campbell wrote:
> Brad Campbell wrote:
>
>> The wheel works in SDL although there is currently a bug where it
>> steps by 2 instead of 1.. so it's ok for scrolling, but scrolling
>> through a selection box causes it to skip every second selection.
>> I've not tested the wheel with the vnc patch yet. I'll get to those
>> tonight..
>
> Wheel works in VNC unmodified :) (yay)
>
> I've been playing some more on the Win98 calibration issue and I'll keep
> looking at that, but for now it' still a no-go. And the 2 step wheel
> thing still needs fixing.
Fixed the descriptor.. Now works perfectly in Win98, 2k and XP :)
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
[-- Attachment #2: qemu-usb-hid-001.patch --]
[-- Type: text/plain, Size: 1176 bytes --]
diff -ur qemu-clean/hw/usb-hid.c qemu/hw/usb-hid.c
--- qemu-clean/hw/usb-hid.c 2006-04-10 23:39:14.000000000 +0400
+++ qemu/hw/usb-hid.c 2006-04-10 23:41:39.000000000 +0400
@@ -161,7 +161,7 @@
0x00, /* u8 country_code */
0x01, /* u8 num_descriptors */
0x22, /* u8 type; Report */
- 65, 0, /* u16 len */
+ 70, 0, /* u16 len */
/* one endpoint (status change endpoint) */
0x07, /* u8 ep_bLength; */
@@ -203,10 +203,13 @@
0x09, 0x30, /* Usage X */
0x09, 0x31, /* Usage Y */
0x15, 0x00, /* Logical Minimum 0 */
- 0x27, 0xFF, 0xFF, 0x00, 0x00, /* Logical Maximum 0xffff */
+ 0x26, 0xFF, 0x7F, /* Logical Maximum 0x7fff */
+ 0x35, 0x00, /* Physical Minimum 0 */
+ 0x46, 0xFF, 0x7F, /* Physical Maximum 0x7fff */
0x75, 0x10, /* Report Size 16 */
0x95, 0x02, /* Report Count 2 */
0x81, 0x02, /* Input (Data, Var, Abs) */
+ 0x05, 0x01, /* Usage Page Generic Desktop */
0x09, 0x38, /* Usage Wheel */
0x15, 0x81, /* Logical Minimum -127 */
0x25, 0x7F, /* Logical Maximum 127 */
^ permalink raw reply
* Comment about proc-dont-lock-task_structs-indefinitely.patch
From: Prasanna Meda @ 2006-04-10 19:42 UTC (permalink / raw)
To: akpm, ebiederm; +Cc: linux-kernel
Hi,
In reply to http://marc.theaimsgroup.com/?l=linux-kernel&m=114119848908725&q=raw
I was not following and just noticed it. The bug is introduced in the patch
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/broken-out/proc-dont-lock-task_structs-indefinitely.patch
The task decrement problem is fixed, but I think we have two more
problems in the following patch segment.
The priv->tail_vma should not be set NULL; In old code, the local
variable tail vma was overloaded for two more purposes as return value
and also in version calculation, in addition to beging initialised
from gate vma. It we set the priv->tail_vma as NULL as the following
patch does, and if we seek back, we will not be able to see the gate
vma anymore from m_next.
@@ -337,35 +349,37 @@ static void *m_start(struct seq_file *m,
}
if (l != mm->map_count)
- tail_vma = NULL; /* After gate vma */
+ priv->tail_vma = NULL; /* After gate vma */
out:
if (vma)
return vma;
/* End of vmas has been reached */
- m->version = (tail_vma != NULL)? 0: -1UL;
+ m->version = (priv->tail_vma != NULL)? 0: -1UL;
up_read(&mm->mmap_sem);
mmput(mm);
- return tail_vma;
+ return priv->tail_vma;
Thanks,
Prasanna.
^ 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.