"Paul Menage" <[EMAIL PROTECTED]> writes:
> On 3/7/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
>>
>> All that being said, if it were going to save space without overly
>> complicating things I'm actually not opposed to using nsproxy, but it
>
> If space-saving is the main issue, then the latest
Dave Hansen <[EMAIL PROTECTED]> writes:
> On Wed, 2007-03-07 at 15:59 -0600, Serge E. Hallyn wrote:
>> Space saving was the only reason for nsproxy to exist.
>>
>> Now of course it also provides the teensiest reduction in # instructions
>> since every clone results in just one reference count inc
"Paul Menage" <[EMAIL PROTECTED]> writes:
> No, Sam was saying that nsproxy should be the object that all resource
> controllers hook off.
I think implementation wise this tends to make sense.
However it should have nothing to do with semantics.
If we have a lot of independent resource controlle
On 3/7/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> Effectively, container_group is to container as nsproxy is to namespace.
The statement above nicely summarizes the confusion in terminology.
In the namespace world when we say container we mean roughly at the level
of nsproxy and contain
Shane wrote:
> On Tue, 2007-03-06 at 16:43 +0530, Vaidyanathan Srinivasan wrote:
>> Please let me know if so see any problem running the patch. The
>> patches are against 2.6.20 only since dependent patches are at that level.
>
> My problem - a bad copy of the patch. It patches o.k.
> However,
On Mon, Feb 12, 2007 at 12:15:22AM -0800, [EMAIL PROTECTED] wrote:
> +/**
> + * container_lock - lock out any changes to container structures
> + *
> + * The out of memory (oom) code needs to mutex_lock containers
> + * from being changed while it scans the tasklist looking for a
> + * task in an o
On Wed, Mar 07, 2007 at 05:51:17PM +0530, Srivatsa Vaddagiri wrote:
> If that is the case, I think we can push container_lock entirely inside
> cpuset.c and not have others exposed to this double-lock complexity.
> This is possible because cpuset.c (build on top of containers) still has
> cpuset->
On Mon, Feb 12, 2007 at 12:15:23AM -0800, [EMAIL PROTECTED] wrote:
> /*
> @@ -913,12 +537,14 @@ static int update_nodemask(struct cpuset
> int migrate;
> int fudge;
> int retval;
> + struct container *cont;
This seems to be redundant?
--
Regards,
vatsa
-
To unsubscribe fro
On Mon, Feb 12, 2007 at 12:15:23AM -0800, [EMAIL PROTECTED] wrote:
> - mutex_lock(&callback_mutex);
> - list_add(&cs->sibling, &cs->parent->children);
> + cont->cpuset = cs;
> + cs->container = cont;
> number_of_cpusets++;
> - mutex_unlock(&callback_mutex);
What's the rul
On 3/7/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
On Mon, Feb 12, 2007 at 12:15:23AM -0800, [EMAIL PROTECTED] wrote:
> /*
> @@ -913,12 +537,14 @@ static int update_nodemask(struct cpuset
> int migrate;
> int fudge;
> int retval;
> + struct container *cont;
This seem
On 3/7/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
On Mon, Feb 12, 2007 at 12:15:23AM -0800, [EMAIL PROTECTED] wrote:
> - mutex_lock(&callback_mutex);
> - list_add(&cs->sibling, &cs->parent->children);
> + cont->cpuset = cs;
> + cs->container = cont;
> number_of_cpuset
On Wed, Mar 07, 2007 at 08:01:32AM -0800, Paul Menage wrote:
> > > @@ -913,12 +537,14 @@ static int update_nodemask(struct cpuset
> > > int migrate;
> > > int fudge;
> > > int retval;
> > > + struct container *cont;
> >
> > This seems to be redundant?
>
> It gets used in the
On 3/7/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
It makes sense in the first cpuset patch
(cpusets_using_containers.patch), but should be removed in the second
cpuset patch (multiuser_container.patch). In the 2nd patch, we use this
comparison:
if (task_cs(p) != cs)
On 3/7/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
If that is the case, I think we can push container_lock entirely inside
cpuset.c and not have others exposed to this double-lock complexity.
This is possible because cpuset.c (build on top of containers) still has
cpuset->parent and walking
Paul Menage wrote:
>> In the namespace world when we say container we mean roughly at the level
>> of nsproxy and container_group.
>>
> So you're saying that a task can only be in a single system-wide container.
>
Nope, we didn't make the mistake of nailing down what a "container" was
too
On 3/7/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
Paul Menage wrote:
>> In the namespace world when we say container we mean roughly at the level
>> of nsproxy and container_group.
>>
> So you're saying that a task can only be in a single system-wide container.
>
Nope, we didn't make the mistake
Srivatsa Vaddagiri wrote:
> container structure in your patches provides for these things:
>
> a. A way to group tasks
> b. A way to maintain several hierarchies of such groups
>
> If you consider just a. then I agree that container abstraction is
> redundant, esp for vserver resource control (ns
Paul Menage wrote:
> But "namespace" has well-established historical semantics too - a way
> of changing the mappings of local names to global objects. This
> doesn't describe things liek resource controllers, cpusets, resource
> monitoring, etc.
>
> Trying to extend the well-known term namespace t
On 3/7/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
But "namespace" has well-established historical semantics too - a way
of changing the mappings of local * to global objects. This
accurately describes things liek resource controllers, cpusets, resource
monitoring, etc.
Sorry, I think this statem
"Paul Menage" <[EMAIL PROTECTED]> writes:
> On 3/7/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
>> But "namespace" has well-established historical semantics too - a way
>> of changing the mappings of local * to global objects. This
>> accurately describes things liek resource controllers, cpusets, re
On 3/7/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
Pretty much. For most of the other cases I think we are safe referring
to them as resource controls or resource limits.I know that roughly covers
what cpusets and beancounters and ckrm currently do.
Plus resource monitoring (which may
"Paul Menage" <[EMAIL PROTECTED]> writes:
> On 3/7/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> The real trick is that I believe these groupings are designed to be something
>> you can setup on login and then not be able to switch out of.
>
> That's going to to be the case for most resource
Paul Menage wrote:
> Sorry, I think this statement is wrong, by the generally established
> meaning of the term namespace in computer science.
>
Sorry, I didn't realise I was talking with somebody qualified enough to
speak on behalf of the Generally Established Principles of Computer Science.
On 3/7/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
Sorry, I didn't realise I was talking with somebody qualified enough to
speak on behalf of the Generally Established Principles of Computer Science.
I made sure to check
http://en.wikipedia.org/wiki/Namespace
http://en.wikipedia.org/wiki/Namesp
Srivatsa Vaddagiri <[EMAIL PROTECTED]> writes:
> Heavily based on Paul Menage's (inturn cpuset) work. The big difference
> is that the patch uses task->nsproxy to group tasks for resource control
> purpose (instead of task->containers).
>
> The patch retains the same user interface as Paul Menage'
Paul Menage wrote:
> I made sure to check [...]wikipedia.org[...] when this argument started ...
> :-)
>
Wikipedia?! That's not a referen[...]
oh bugger it. I've vented enough today and we're on the same page now I
think.
>> This is the classic terminology problem between substance and fun
Hi list,
I am using kernel 2.6.20.1. I have written a module,which will
register a function at local_in hook, i have found a strange behavior
with the packets getting in my callback function i.e
[let say i am sending 1500 bytes to this machine from the network]
ping -s 1500
1>in case of fragme
On 03/07/2007 03:33 PM, Jeremy Fitzhardinge wrote:
I know the vmi time code has coloured your view here, but I surely hope
it can be got into a better state before posting. I'm biased of course,
but I would rather hope that all these drivers we're talking about will
be as stylistically clean as
On Wed, 2007-03-07 at 15:25 -0800, Zachary Amsden wrote:
> > Looking at vmitimer.c and the number of hardcoded assumptions are
> > telling me, that we are heading in exactly the opposite direction.
> >
>
> No, VMI timer is unique because for SMP, it is based on the APIC. On
> i386, SMP is har
Dan Hecht wrote:
> On 03/07/2007 03:33 PM, Jeremy Fitzhardinge wrote:
>> I know the vmi time code has coloured your view here, but I surely hope
>> it can be got into a better state before posting. I'm biased of course,
>> but I would rather hope that all these drivers we're talking about will
>>
On Wed, 2007-03-07 at 15:33 -0800, Jeremy Fitzhardinge wrote:
> > On the other hand we yet see things like:
> >
> > /* We use normal irq0 handler on cpu0. */
> > time_init_hook();
> >
> > Which is just reaching into the kernel code directly and does not handle
> > the clock event in
Thomas Gleixner wrote:
> Sigh. The cut zero hairball is already in mainline. :(
>
Yes, there were a couple of unfortunate patches in that series, but they
got fast-tracked in with the promise they would get fixed asap.
> Sure. If the clockevent API is changed, then the users get fixed. This
>
On Fri, 2007-03-02 at 16:16 -0800, Jeremy Fitzhardinge wrote:
>
> Yes, the intent is that running a CONFIG_PARAVIRT kernel on native
> hardware will have negligible performance hit compared to running a
> non-paravirt kernel.
>
> J
It turned out that VDSO was turned off by CONFIG_PARAVIRT o
Tim Chen wrote:
> It turned out that VDSO was turned off by CONFIG_PARAVIRT option,
> causing the system call to use inefficient int 0x80 which led to the
> increase system_call time I was seeing. I noted that Ingo has caught
> this problem and proposed a patch to correct this issue in another mai
Thomas Gleixner wrote:
You managed to avoid the usage of other code (i.e. PIT / HPET) already,
so why is it sooo desireable to emulate apics instead of substituting it
by a small and sane replacement ? Just because you happen to have an
LAPIC emulator ? That's no reason to wire yourself into the
Daniel Arai wrote:
> But more importantly, we want a kernel that can run both on native hardware
> and
> in a paravirtualized environment. Linux doesn't really provide abstractions
> for
> replacing the appropriate code. We tried to hook into the source code at a
> level that seemed possib
From: Andrew Morton <[EMAIL PROTECTED]>
Revert 7628b0a8c01a02966d2228bdf741ddedb128e8f8. Thomas Bachler
reports:
Commit 7628b0a8c01a02966d2228bdf741ddedb128e8f8 (drivers/net/tulip/dmfe:
support basic carrier detection) breaks networking on my Davicom DM9009.
ethtool always reports there
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Tetsuo Handa <[EMAIL PROTECTED]> told me that connect(2) with TCPv6
socket almost always took a few minutes to return when we did not have any
ports available in the range of net.ipv4.ip_local_port_range.
The reason was that we used incorrect seed for c
On Wed, 07 Mar 2007 09:12:12 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
>
> From: Andrew Morton <[EMAIL PROTECTED]>
>
> Revert 7628b0a8c01a02966d2228bdf741ddedb128e8f8. Thomas Bachler
> reports:
>
> Commit 7628b0a8c01a02966d2228bdf741ddedb128e8f8 (drivers/net/tulip/dmfe:
> support basic carr
On Wed, Mar 07, 2007 at 11:11:49 -0500, Chuck Ebbert wrote:
> Sami Farin wrote:
> > On Tue, Mar 06, 2007 at 23:53:49 +0200, Sami Farin wrote:
> > ...
> >> And I found bug in gcc-4.1.2, it gave 0 for ncubic results
> >> when doing 1000 loops test... gcc-4.0.3 works.
> >
> > Found it.
> >
> > --- c
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Wed, 7 Mar 2007 13:12:46 +0100
> Well that still needs the ugly div64_64 function. At least my goal was to
> eliminate that, not make it faster (I don't see any evidence this function
> is particularly performance critical). You prefer to keep div64_64?
On Wed, 2007-03-07 at 06:06 -0500, Jeff Garzik wrote:
> Adrian Bunk wrote:
> > Subject: forcedeth: skb_over_panic
> > References : http://bugzilla.kernel.org/show_bug.cgi?id=8058
> > Submitter : Albert Hopkins <[EMAIL PROTECTED]>
> > Status : unknown
>
>
> I think this is fixed by the re
Dave,
I did some research based on your feedback. Specifically, I
looked at removing ->map_queue() and allowing ->enqueue() to take care
of mapping and locking of the queues (and ->dequeue()). I found that it
can be done either way, but I'm not sure I like taking the locking out
of dev_qu
This patch removes the following not or no longer used exports:
- drivers/char/random.c: secure_tcp_sequence_number
- net/dccp/options.c: sysctl_dccp_feat_sequence_window
- net/netlink/af_netlink.c: netlink_set_err
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on
On Tue, Mar 06, 2007 at 12:44:08AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-rc2-mm1:
>...
> git-netdev-all.patch
>...
> git trees
>...
drivers/net/wireless/libertas/debugfs.c contains:
#define item_addr(n) ((u32) &((wlan_adapter *)0)->n)
This is wrong on 64bit architectures.
c
I didn't say to use skb->priority, I said to shrink skb->priority down
to a u16 and then make another u16 which will store your queue mapping
value.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Wed, 7 Mar 2007 23:40:59 +0100
> This patch removes the following not or no longer used exports:
> - drivers/char/random.c: secure_tcp_sequence_number
> - net/dccp/options.c: sysctl_dccp_feat_sequence_window
> - net/netlink/af_netlink.c: netlink_set_err
On Wed, Mar 07, 2007 at 11:40:59PM +0100, Adrian Bunk wrote:
> This patch removes the following not or no longer used exports:
> - drivers/char/random.c: secure_tcp_sequence_number
This part looks reasonable.
Acked-by: Matt Mackall <[EMAIL PROTECTED]>
--
Mathematics is the supreme nostalgia of o
On Wed, 7 Mar 2007 23:41:16 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 06, 2007 at 12:44:08AM -0800, Andrew Morton wrote:
> >...
> > Changes since 2.6.20-rc2-mm1:
> >...
> > git-netdev-all.patch
> >...
> > git trees
> >...
>
> drivers/net/wireless/libertas/debugfs.c contains:
>
From: Eric Paris <[EMAIL PROTECTED]>
Date: Fri, 02 Mar 2007 13:29:50 -0500
> The security hooks to check permissions to remove an xfrm_policy were
> actually done after the policy was removed. Since the unlinking and
> deletion are done in xfrm_policy_by* functions this moves the hooks
> inside t
From: Eric Paris <[EMAIL PROTECTED]>
Date: Fri, 02 Mar 2007 13:51:24 -0500
> pfkey_spdget neither had an LSM security hook nor auditing for the
> removal of xfrm_policy structs. The security hook was added when it was
> moved into xfrm_policy_byid instead of the callers to that function by
> my e
From: Eric Paris <[EMAIL PROTECTED]>
Date: Fri, 02 Mar 2007 15:15:36 -0500
> Inside pfkey_delete and xfrm_del_sa the audit hooks were not called if
> there was any permission/security failures in attempting to do the del
> operation (such as permission denied from security_xfrm_state_delete).
> Th
From: David Miller <[EMAIL PROTECTED]>
Date: Wed, 07 Mar 2007 15:43:16 -0800 (PST)
> From: Eric Paris <[EMAIL PROTECTED]>
> Date: Fri, 02 Mar 2007 13:51:24 -0500
>
> > pfkey_spdget neither had an LSM security hook nor auditing for the
> > removal of xfrm_policy structs. The security hook was add
The basic calculation has to be done in 32 bits to avoid
doing 64 bit divide by 3. The value x is only 22bits max
so only need full 64 bits only for x^2.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
net/ipv4/tcp_cubic.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
On Wed, 2007-03-07 at 10:14 -0800, Stephen Hemminger wrote:
> On Wed, 07 Mar 2007 09:12:12 -0800
> Greg KH <[EMAIL PROTECTED]> wrote:
>
> >
> > From: Andrew Morton <[EMAIL PROTECTED]>
> >
> > Revert 7628b0a8c01a02966d2228bdf741ddedb128e8f8. Thomas Bachler
> > reports:
> >
> > Commit 7628b0a8
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 7 Mar 2007 17:07:31 -0800
> The basic calculation has to be done in 32 bits to avoid
> doing 64 bit divide by 3. The value x is only 22bits max
> so only need full 64 bits only for x^2.
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
On Wed, 7 Mar 2007, Dan Williams wrote:
>
> Definitely right. If it doesn't work for your card, it needs to be
> fixed for your card.
Well, regressions are regressions. And they are a *lot* more important
than any new features. If it doesn't work, it gets reverted.
Linus
-
To
David Miller wrote:
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 7 Mar 2007 17:07:31 -0800
The basic calculation has to be done in 32 bits to avoid
doing 64 bit divide by 3. The value x is only 22bits max
so only need full 64 bits only for x^2.
Signed-off-by: Stephen Hemminger <[E
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 07 Mar 2007 19:10:47 -0800
> David Miller wrote:
> > What about Willy Tarreau's supposedly even faster variant?
> > Or does this incorporate that set of improvements?
> >
> That's what this is:
> x = (2 * x + (uint32_t)div64_64(a, (uint
On Wed, Mar 07, 2007 at 07:10:47PM -0800, Stephen Hemminger wrote:
> David Miller wrote:
> >From: Stephen Hemminger <[EMAIL PROTECTED]>
> >Date: Wed, 7 Mar 2007 17:07:31 -0800
> >
> >
> >>The basic calculation has to be done in 32 bits to avoid
> >>doing 64 bit divide by 3. The value x is only 22
On Wed, 7 Mar 2007 08:42:39 +0200 (EET)
Pekka Savola <[EMAIL PROTECTED]> wrote:
> On Tue, 6 Mar 2007, Chris Friesen wrote:
> > Stephen Hemminger wrote:
> >> +arp_notify - BOOLEAN
> >> + Define mode for notification of address and device changes.
> >> + 0 - (default): do nothing
> >> + 1 - Gene
MMC: Fix typo in mmc highspeed
Signed-off-by: Kyungmin Park <[EMAIL PROTECTED]>
--
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 4a73e8b..3b8f7af 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1134,7 +1134,7 @@ static void mmc_process_ext_csds(struct mmc_host
*host)
Hello netfilter-devel,
I would like to submit chaostables (v0.5_svn23) for inclusion. Primary
use is to detect, spoof and slowdown various sorts of port scans.
Implementation details can be found at http://jengelh.hopto.org/p/chaostables/
If you have any comments or suggestions, do not hestitat
New hwmon drivers since 2.6.16.42 for the following hardware:
- National Semiconductor pc87427
- SMSC lpc47m192 and lpc47m997
- Winbond w83791d
Location:
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/
git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
Changes since
Andrew Morton <[EMAIL PROTECTED]> writes:
>
> That's:
>
> pci_restore_pcix_state(dev);
> pci_restore_msi_state(dev);
> WARN_ON(!hlist_empty(&dev->saved_cap_space));
>
> return 0;
Hmm. Either I am confused of I just found an unanticipated leak.
pci_restore_msi_sta
Hi,
I have MPC8548 Linux based firewall which will mostly do packet processing
for 80% time.
So obviously most of the time it will RX and TX packets through gianfar
Ethernet driver.
I want to lock my interrupt handler of this driver in the L1 cache.
1. Are there any kernel APIs to lock any funct
On Wed, 2007-03-07 at 11:52 -0800, Andrew Morton wrote:
> On Wed, 7 Mar 2007 16:46:20 -0300 "Luiz Fernando N. Capitulino" <[EMAIL
> PROTECTED]> wrote:
>
> > Em Tue, 6 Mar 2007 00:44:08 -0800
> > Andrew Morton <[EMAIL PROTECTED]> escreveu:
> >
> > |
> > | Temporarily at
> > |
> > | http://use
Kyle Moffett a écrit :
Prefetching is also fairly critical on a Power4 or G5 PowerPC system as
they have a long memory latency; an L2-cache miss can cost 200+ cycles.
On such systems the "dcbt" prefetch instruction brings in a single
128-byte cacheline and has no serializing effects whatsoev
Andrew Morton wrote:
(cc restored. Please always do reply-to-all)
On Wed, 28 Feb 2007 18:05:13 +0200 [EMAIL PROTECTED] wrote:
On Wednesday 28 February 2007 17:19, Sid Boyce wrote:
openSUSE 10.3 Alpha and KDE-3.5.6, xorg-x11-7.2. KDE is setup not to
require a password to unlock, but it
On Tue, 6 Mar 2007 23:45:29 -0800, Andrew Morton wrote:
> On Wed, 07 Mar 2007 15:39:27 +0800 "Wu, Bryan" <[EMAIL PROTECTED]> wrote:
>
> > Thanks a lot, could you please give me a script just to kill this
> > whitespace? So I can do it before sending you patches.
>
>
> Is pretty simple:
>
> #!/b
Hello.
The BUG_ON() check at move_freepages() is wrong.
Its end_page is start_page + MAX_ORDER_NR_PAGES. So, it can be
next zone. BUG_ON() should check "end_page - 1".
This is fix of 2.6.21-rc3-mm2 for it.
Signed-off-by: Yasunori Goto <[EMAIL PROTECTED]>
---
mm/page_alloc.c |2 +-
1 file
Bill Irwin wrote:
On Tue, 2007-03-06 at 22:44 -0800, Bill Irwin wrote:
What do you see as the obstacle to eliminating nested IRQ's?
On Wed, Mar 07, 2007 at 04:34:52AM -0800, Arjan van de Ven wrote:
political will, or maybe just the lack of convincing people so far
Politica
2.6.21rc3 from today git, thinkpad z60m, pl2303 usb-rs232 adapter and:
[ 84.087080] usb 2-2: new full speed USB device using uhci_hcd and address 3
[ 84.232615] usb 2-2: configuration #1 chosen from 1 choice
[ 84.235540] pl2303 2-2:1.0: pl2303 converter detected
[ 84.235732] usb 2-2: pl23
On Tue, 6 Mar 2007, Eric Buddington wrote:
> On Tue, Mar 06, 2007 at 01:34:41PM -0500, Alan Stern wrote:
> > The stack trace didn't include the khubd process at all. Probably that
> > means it had already died.
>
> No, it's still there. I ran 'echo t >/proc/sysrq-trigger' again, and
> khubd did
On Wed, Mar 07, 2007 at 11:03:21AM -0500, Alan Stern wrote:
> On Tue, 6 Mar 2007, Eric Buddington wrote:
>
> > On Tue, Mar 06, 2007 at 01:34:41PM -0500, Alan Stern wrote:
> > > The stack trace didn't include the khubd process at all. Probably that
> > > means it had already died.
> >
> > No, it
From: Alan Stern <[EMAIL PROTECTED]>
This patch (as863) fixes a problem encountered sometimes when resuming
a port on a UHCI controller. The hardware may turn off the
Resume-Detect bit before turning off the Suspend bit, leading usbcore
to think that the port is still suspended and the resume has
This patch (as849) fixes a bug in the USB hub driver. A single
pre-allocated buffer is used for all port status reads, but nothing
guarantees exclusive use of the buffer. A mutex is added to provide
this guarantee.
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman
On Wed, 7 Mar 2007, Eric Buddington,,, wrote:
> > > So SysRq-t doesn't show anything about khubd, and SysRq-p doesn't give
> > > me anything at all. What else can I try?
How about SysRq-r?
> > I'm baffled. khubd should have shown up as the process with ID 163. Is
> > that process listed under
On Wed, Mar 07, 2007 at 03:22:05PM -0500, Alan Stern wrote:
> On Wed, 7 Mar 2007, Eric Buddington,,, wrote:
>
> > > > So SysRq-t doesn't show anything about khubd, and SysRq-p doesn't give
> > > > me anything at all. What else can I try?
>
> How about SysRq-r?
SysRq : Keyboard mode set to XLATE
On Wed, 7 Mar 2007, Eric Buddington wrote:
> On Wed, Mar 07, 2007 at 03:22:05PM -0500, Alan Stern wrote:
> > On Wed, 7 Mar 2007, Eric Buddington,,, wrote:
> >
> > > > > So SysRq-t doesn't show anything about khubd, and SysRq-p doesn't give
> > > > > me anything at all. What else can I try?
> >
>
On Wed, 7 Mar 2007 17:18:29 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote:
> I've never heard of a process failing to show up in a SysRq-t listing. It
> suggests something is wrong with the process management in the kernel you
> were using. That leads me to think a non -mm kernel might giv
On Wed, 2007-03-07 at 12:27 +0530, Vivek Goyal wrote:
> Hi,
>
> Here is another attempt on x86_64 relocatable bzImage patches(V4). This
> patchset makes a bzImage relocatable and same kernel binary can be loaded
> and run from different physical addresses.
have these patches been extensively tes
Arjan van de Ven <[EMAIL PROTECTED]> writes:
> On Wed, 2007-03-07 at 12:27 +0530, Vivek Goyal wrote:
>> Hi,
>>
>> Here is another attempt on x86_64 relocatable bzImage patches(V4). This
>> patchset makes a bzImage relocatable and same kernel binary can be loaded
>> and run from different physical
On Wed, Mar 07, 2007 at 12:29:20PM +0530, Vivek Goyal wrote:
>
>
> This patch makes pgtable.h and page.h safe to include
> in assembly files like head.S. Allowing us to use
> symbolic constants instead of hard coded numbers when
> refering to the page tables.
>
> This patch copies asm-sparc64/c
Hi.
On Wed, 2007-03-07 at 07:07 -0800, Arjan van de Ven wrote:
> On Wed, 2007-03-07 at 12:27 +0530, Vivek Goyal wrote:
> > Hi,
> >
> > Here is another attempt on x86_64 relocatable bzImage patches(V4). This
> > patchset makes a bzImage relocatable and same kernel binary can be loaded
> > and run
On Wed 2007-03-07 12:42:00, Vivek Goyal wrote:
>
>
> o Use appropriate names for 64bit regsiters.
>
> Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
> Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]>
ACK.
Pavel
--
(english) h
Hi!
> o Various cleanups. One of the main purpose of cleanups is that make
> wakeup.S as close as possible to trampoline.S.
>
> o Following are the changes
> - Indentations for comments.
> - Changed the gdt table to compact form and to resemble the
> one in trampoline.S
>
Hi!
> + movw$0x0e00 + 'i', %ds:(0xb8012)
> + movb$0xa8, %al ; outb %al, $0x80;
> +
> - movw$0x0e00 + 'i', %ds:(0xb8012)
> - movb$0xa8, %al ; outb %al, $0x80;
Outbs were my debugging hacks, perhaps you can simply remove them at
this point? Not sure
Hi!
> o Moved wakeup_level4_pgt into the wakeup routine so we can
> run the kernel above 4G.
>
> o Now we first go to 64bit mode and continue to run from trampoline and
> then then start accessing kernel symbols and restore processor context.
> This enables us to resume even in relocatable
Hi!
> o __pa() should be used only on kernel linearly mapped virtual addresses
> and not on kernel text and data addresses.
>
> o Hibernation code needs to determine the physical address associated
> with kernel symbol to mark a section boundary which contains pages which
> don't have to be
Hi!
> o virt_to_page() call should be used on kernel linear addresses and not
> on kernel text and data addresses. Swsusp code uses it on kernel data
> (statically allocated swsusp_header).
>
> o Allocate swsusp_header dynamically so that virt_to_page() can be used
> safely.
>
> o I am cha
Hi!
> o virt_to_page() call should be used on kernel linear addresses and not
> on kernel text and data addresses. Swsusp code uses it on kernel data
> (statically allocated swsusp_header).
>
> o Allocate swsusp_header dynamically so that virt_to_page() can be used
> safely.
>
> o I am cha
* Pavel Machek <[EMAIL PROTECTED]> [2007-03-07 23:45]:
>
> > + if ((&wakeup_end - &wakeup_start) > (PAGE_SIZE*2))
> > printk(KERN_CRIT
> > - "ACPI: Wakeup code way too big, will crash on attempt to
> > suspend\n");
> > + "ACPI: Wakeup code way too b
Hi.
On Thu, 2007-03-08 at 07:49 +1100, Nigel Cunningham wrote:
> Hi.
>
> On Wed, 2007-03-07 at 07:07 -0800, Arjan van de Ven wrote:
> > On Wed, 2007-03-07 at 12:27 +0530, Vivek Goyal wrote:
> > > Hi,
> > >
> > > Here is another attempt on x86_64 relocatable bzImage patches(V4). This
> > > patchs
Hi.
On Wed, 2007-03-07 at 23:50 +0100, Pavel Machek wrote:
> Hi!
>
> > o virt_to_page() call should be used on kernel linear addresses and not
> > on kernel text and data addresses. Swsusp code uses it on kernel data
> > (statically allocated swsusp_header).
> >
> > o Allocate swsusp_header
On Wed, Mar 07, 2007 at 07:07:39AM -0800, Arjan van de Ven wrote:
> On Wed, 2007-03-07 at 12:27 +0530, Vivek Goyal wrote:
> > Hi,
> >
> > Here is another attempt on x86_64 relocatable bzImage patches(V4). This
> > patchset makes a bzImage relocatable and same kernel binary can be loaded
> > and ru
On Wed, Mar 07, 2007 at 11:40:53PM +0100, Pavel Machek wrote:
> Hi!
>
> > o Various cleanups. One of the main purpose of cleanups is that make
> > wakeup.S as close as possible to trampoline.S.
> >
> > o Following are the changes
> > - Indentations for comments.
> > - Changed the gdt ta
On Wed, Mar 07, 2007 at 11:41:57PM +0100, Pavel Machek wrote:
> Hi!
>
> > + movw$0x0e00 + 'i', %ds:(0xb8012)
> > + movb$0xa8, %al ; outb %al, $0x80;
> > +
>
> > - movw$0x0e00 + 'i', %ds:(0xb8012)
> > - movb$0xa8, %al ; outb %al, $0x80;
>
> Outbs were my d
On Thu, Mar 08, 2007 at 10:15:02AM +1100, Nigel Cunningham wrote:
> Hi.
>
> On Thu, 2007-03-08 at 07:49 +1100, Nigel Cunningham wrote:
> > Hi.
> >
> > On Wed, 2007-03-07 at 07:07 -0800, Arjan van de Ven wrote:
> > > On Wed, 2007-03-07 at 12:27 +0530, Vivek Goyal wrote:
> > > > Hi,
> > > >
> > >
On Wed, Mar 07, 2007 at 11:45:08PM +0100, Pavel Machek wrote:
[..]
>
> > + if ((&wakeup_end - &wakeup_start) > (PAGE_SIZE*2))
> > printk(KERN_CRIT
> > - "ACPI: Wakeup code way too big, will crash on attempt to
> > suspend\n");
> > + "ACPI: Wakeup co
601 - 700 of 712 matches
Mail list logo
