numbers mean, eg :
8c4f3c3fa968 874d3954a35c 2 1
the first is the occurrences in upstream and second for the occurrence
in 3.2.xx right?
Regards,
Jack
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
On Tue, 07 Jan 2014 14:02:14 +0100
Paul Bolle pebo...@tiscali.nl wrote:
diff --git a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c index
a41f01e..8ace450 100644 ---
a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c +++
This time, replying to the list as well.
-Jack
P.S. sorry for the delay, I was swamped.
On Tue, 07 Jan 2014 14:01:18 +0100
Paul Bolle pebo...@tiscali.nl wrote:
+ } else {
+ /* state == RES_CQ_HW */
+ if (r-com.state != RES_CQ_ALLOCATED)
if (state != RES_CQ_HW
On 01/04/2014 07:09 AM, Al Viro wrote:
> On Thu, Jan 02, 2014 at 10:36:30AM +0100, Jack Wang wrote:
>
>>> Bug happened at line 1486, looks disk->fops is NULL here for some
>>> reason, is it reasonable to add a check like:
>>>
>>> if
On 01/04/2014 07:09 AM, Al Viro wrote:
On Thu, Jan 02, 2014 at 10:36:30AM +0100, Jack Wang wrote:
Bug happened at line 1486, looks disk-fops is NULL here for some
reason, is it reasonable to add a check like:
if (disk-fops)
if (disk-fops-release)
ret = disk-fops-release
On 12/30/2013 04:55 PM, Jack Wang wrote:
> Hi,
>
> We saw NULL pointer dereference below:
>
> Dec 28 16:24:26 server kernel: [979193.076399] BUG: unable to handle
> kernel NULL pointer dereference at 0008
> Dec 28 16:24:26 server kernel: [979193.076401] IP: []
On 12/30/2013 04:55 PM, Jack Wang wrote:
Hi,
We saw NULL pointer dereference below:
Dec 28 16:24:26 server kernel: [979193.076399] BUG: unable to handle
kernel NULL pointer dereference at 0008
Dec 28 16:24:26 server kernel: [979193.076401] IP: [8116952f]
__blkdev_put
gt; port_num, int slave)
> p->gid_group.name = "gid_idx";
> p->gid_group.attrs = alloc_group_attrs(show_port_gid_idx,
> NULL, 1);
> - if (!p->gid_group.attrs)
> + if (!p->gid_group.attrs) {
> + ret = -ENOMEM;
> goto
se(disk, mode);
0x81162e8c <+380>: mov%r12d,%esi
0x81162e8f <+383>: mov%r14,%rdi
0x81162e92 <+386>: callq *%rax
0x81162e94 <+388>: mov %eax,%ebp
0x81162e96 <+390>: jmpq 0x81162d9a &l
: jmpq 0x81162d9a __blkdev_put+138
snip
Bug happened at line 1486, looks disk-fops is NULL here for some
reason, is it reasonable to add a check like:
if (disk-fops)
if (disk-fops-release)
ret = disk-fops-release(disk, mode);
Happy New Year and Best regards:)
Jack
= alloc_group_attrs(show_port_gid_idx,
NULL, 1);
- if (!p-gid_group.attrs)
+ if (!p-gid_group.attrs) {
+ ret = -ENOMEM;
goto err_free_pkey;
+ }
ACK. Julia's patch is correct -- this is indeed a bug-fix.
-Jack
--
To unsubscribe from this list: send
Regards,
Jack Kofi, esq
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Regards,
Jack Kofi, esq
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
f recent re-design of the MSI/MSI-X interrupts enabling
> pattern this driver has to be updated to use the new technique to
> obtain a optimal number of MSI/MSI-X interrupts required.
>
> Signed-off-by: Alexander Gordeev
> ---
ACK.
-Jack
--
To unsubscribe from this list: send t
should actually read something like the following:
As a result of changes to the MSI/MSI_X enabling procedures, this driver
must be modified in order to preserve its current msi/msi_x enablement
logic.
-Jack
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
ut is already
upstream.
I will re-review.
-Jack
NACK. This change does not do anything logically as far as I can tell.
pci_enable_msix in the current upstream kernel itself calls
pci_msix_table_size. The current code yields the same resultswill
as the code suggested below. (i.e., the sugge
_msix_table_size(). There is no error here, and
it is simply confusing.
-Jack
> As result of recent re-design of the MSI/MSI-X interrupts enabling
> pattern this driver has to be updated to use the new technique to
> obtain a optimal number of MSI/MSI-X interrupts required.
>
> S
by pci_msix_table_size(). There is no error here, and
it is simply confusing.
-Jack
As result of recent re-design of the MSI/MSI-X interrupts enabling
pattern this driver has to be updated to use the new technique to
obtain a optimal number of MSI/MSI-X interrupts required.
Signed-off-by: Alexander Gordeev
about is already
upstream.
I will re-review.
-Jack
NACK. This change does not do anything logically as far as I can tell.
pci_enable_msix in the current upstream kernel itself calls
pci_msix_table_size. The current code yields the same resultswill
as the code suggested below. (i.e., the suggested
.
The change log here should actually read something like the following:
As a result of changes to the MSI/MSI_X enabling procedures, this driver
must be modified in order to preserve its current msi/msi_x enablement
logic.
-Jack
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
re-design of the MSI/MSI-X interrupts enabling
pattern this driver has to be updated to use the new technique to
obtain a optimal number of MSI/MSI-X interrupts required.
Signed-off-by: Alexander Gordeev agord...@redhat.com
---
ACK.
-Jack
--
To unsubscribe from this list: send the line
Dear Friend,
I will want to discuss something with you about your family and it has some
form of relationship with you going by the similarity in the name.
So kindly get back to me if you are interested so that we can discuss more
about this.
Regards,
John Jack Dick Ven Der Berg
Dear Friend,
I will want to discuss something with you about your family and it has some
form of relationship with you going by the similarity in the name.
So kindly get back to me if you are interested so that we can discuss more
about this.
Regards,
John Jack Dick Ven Der Berg
an
> Cc: Rik van Riel
> Cc: Minchan Kim
> Cc: Andi Kleen
> Signed-off-by: Andrew Morton
> Signed-off-by: Linus Torvalds
> [ luis: backported to 3.5: adjusted context ]
> Signed-off-by: Luis Henriques
Hi Greg,
I suppose this patch also needed for 3.4, right?
Regards,
-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
[ luis: backported to 3.5: adjusted context ]
Signed-off-by: Luis Henriques luis.henriq...@canonical.com
Hi Greg,
I suppose this patch also needed for 3.4, right?
Regards,
Jack
---
mm
ernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Hi,
Back to 2010, Mike(cc-ed) try to add a flush time out interface, similar
to what you want here, no idea why it's just ignored?
http://www.spinics.net/lists/linux-scsi/msg45017.html
Jack
--
To unsubscribe f
Jack
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wed, 14 Aug 2013, Greg Kroah-Hartman wrote:
On Wed, Aug 14, 2013 at 12:40:56PM -0400, Jack Hill wrote:
Hi Greg,
Apologies if this question is due to my ignorance of kernel development
practices. Feel free to point me at documentation.
I noticed that you applied this patch to the 3.10
not applied to that tree?
Thanks!
Jack
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
not applied to that tree?
Thanks!
Jack
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wed, 14 Aug 2013, Greg Kroah-Hartman wrote:
On Wed, Aug 14, 2013 at 12:40:56PM -0400, Jack Hill wrote:
Hi Greg,
Apologies if this question is due to my ignorance of kernel development
practices. Feel free to point me at documentation.
I noticed that you applied this patch to the 3.10
Dear Friend,
I will want to discuss something with you about your family and it has some
form of relationship with you going by the similarity in the name.
So kindly get back to me if you are interested so that we can discuss more
about this.
Regards,
John Jack Dick Ven Der Berg
Dear Friend,
I will want to discuss something with you about your family and it has some
form of relationship with you going by the similarity in the name.
So kindly get back to me if you are interested so that we can discuss more
about this.
Regards,
John Jack Dick Ven Der Berg
Dear Friend,
I will want to discuss something with you about your family and it has some
form of relationship with you going by the similarity in the name.
So kindly get back to me if you are interested so that we can discuss more
about this.
Regards,
John Jack Dick Ven Der Berg
Dear Friend,
I will want to discuss something with you about your family and it has some
form of relationship with you going by the similarity in the name.
So kindly get back to me if you are interested so that we can discuss more
about this.
Regards,
John Jack Dick Ven Der Berg
Vi tilbyr legitime lån som personlige og forretningsmessige lån uten sikkerhet
(bare identification) med maksimum
garanti, på 3% rente, fra $ 5000 til $ 90,000,000 i 1 år til 40 år
nedbetalingstid overalt i verden
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Vi tilbyr legitime lån som personlige og forretningsmessige lån uten sikkerhet
(bare identification) med maksimum
garanti, på 3% rente, fra $ 5000 til $ 90,000,000 i 1 år til 40 år
nedbetalingstid overalt i verden
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
de.
>
I think Lindar already replied to you, and tested it on hardware.
So you can add her:
Acked-by or Tested-by
Regards,
Jack
> Signed-off-by: Yijing Wang
> Cc: xjtu...@gmail.com
> Cc: lindar_...@usish.com
> Cc: "James E.J. Bottomley"
> Cc: linux-s...@v
replied to you, and tested it on hardware.
So you can add her:
Acked-by or Tested-by
Regards,
Jack
Signed-off-by: Yijing Wang wangyij...@huawei.com
Cc: xjtu...@gmail.com
Cc: lindar_...@usish.com
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: linux-s...@vger.kernel.org
Cc: linux-kernel
Hi all,
We saw below bug in our production.
Kernel is linux 3.4.23, as I know it means control was transferred to a
data page. This could happen because of a stack overflow (overwrite
return address with bogus pointer into data pages), or by calling a
function pointer which isn't pointing where
Hi all,
We saw below bug in our production.
Kernel is linux 3.4.23, as I know it means control was transferred to a
data page. This could happen because of a stack overflow (overwrite
return address with bogus pointer into data pages), or by calling a
function pointer which isn't pointing where
From: Jack Mitchell
having /usr/local/include hardcoded into the makefile is not necessary as this
is automatically included by GCC. It also infects cross-compile builds with the
host systems includes.
Signed-off-by: Jack Mitchell
---
tools/lib/traceevent/Makefile | 2 +-
1 file changed, 1
From: Jack Mitchell jack.mitch...@dbbroadcast.co.uk
having /usr/local/include hardcoded into the makefile is not necessary as this
is automatically included by GCC. It also infects cross-compile builds with the
host systems includes.
Signed-off-by: Jack Mitchell jack.mitch...@dbbroadcast.co.uk
(my gcc at least was already
> if effect setting vlan in the generated assembly code), so I'll just
> merge that.
>
> - R.
Thanks!
-Jack
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More maj
vlan in the generated assembly code), so I'll just
merge that.
- R.
Thanks!
-Jack
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
s_eth, is_eth, is_vlan, is_grh, 0,
> >ud_header);
>
> if (!is_eth) {
-Jack
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
) {
-Jack
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 02/01/2013 04:50 PM, Jack Wang wrote:
> Hi All,
> In our product system, we have several sata disks attached to one
> machine. So when one of the disk fails, the jbd2(yes, we use ext4)
> will hang forever and we will get something in /var/log/messages like
below.
>
he end_io can be called accordingly? Am I missing something here?
Thanks,
Tao
[Jack Wang]
Hi Tao,
Have you tried:
echo 1 > /sys/block/sdv/device/delete
echo "- - -" > /sys/class/scsi_host/host
another way is :
find out which phy the disk attached to and:
echo 1 > /sys/class/sa
accordingly? Am I missing something here?
Thanks,
Tao
[Jack Wang]
Hi Tao,
Have you tried:
echo 1 /sys/block/sdv/device/delete
echo - - - /sys/class/scsi_host/host
another way is :
find out which phy the disk attached to and:
echo 1 /sys/class/sas_phy/phy-x:x:x/link_reset
Jack
On 02/01/2013 04:50 PM, Jack Wang wrote:
Hi All,
In our product system, we have several sata disks attached to one
machine. So when one of the disk fails, the jbd2(yes, we use ext4)
will hang forever and we will get something in /var/log/messages like
below.
It seems to me
[Jack Wang]
Do you see bug51881, which may relate to what you see
https://bugzilla.kernel.org/show_bug.cgi?id=51881
btw: also correct Dan's mail address.
I'm using Asus PIKE 6480 SAS card, whose chipset is "RAID bus
controller: Marvell Technology Group Ltd. MV64460/64461/64462 S
[Jack Wang]
Do you see bug51881, which may relate to what you see
https://bugzilla.kernel.org/show_bug.cgi?id=51881
btw: also correct Dan's mail address.
I'm using Asus PIKE 6480 SAS card, whose chipset is RAID bus
controller: Marvell Technology Group Ltd. MV64460/64461/64462 System
t.
>
> --
> Jens Axboe
>
A really good performance, woo.
I think the device tested is really fast PCIe SSD builded by fusionio
with fusionio in house block driver?
any compare number with current mainline?
Jack
--
To unsubscribe from this list: send the line "unsubsc
with current mainline?
Jack
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ART.
Signed-off-by: Jack Pham
---
drivers/usb/dwc3/debugfs.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index d4a30f1..be4eff7 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -56,7 +5
.
Signed-off-by: Jack Pham ja...@codeaurora.org
---
drivers/usb/dwc3/debugfs.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index d4a30f1..be4eff7 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3
iver. See, for example, mlx4_ib_post_send() in the
same file (qp.c).
-Jack
On Friday 28 September 2012 14:48, Paul Bolle wrote:
> Building qp.o (part of the "Mellanox ConnectX HCA support" driver)
> triggers this GCC warning:
> drivers/infiniband/hw/mlx4/qp.c: In function ‘mlx4
, for example, mlx4_ib_post_send() in the
same file (qp.c).
-Jack
On Friday 28 September 2012 14:48, Paul Bolle wrote:
Building qp.o (part of the Mellanox ConnectX HCA support driver)
triggers this GCC warning:
drivers/infiniband/hw/mlx4/qp.c: In function ‘mlx4_ib_post_send’:
drivers
Hi Roland,
I am on vacation until next Tuesday -- I'll look at this then.
-Jack
On Monday 24 September 2012 21:36, Roland Dreier wrote:
> On Mon, Sep 24, 2012 at 7:02 AM, Stephen Rothwell
> wrote:
> > After merging the akpm tree, today's linux-next build (powerpc
> > ppc64
Hi Roland,
I am on vacation until next Tuesday -- I'll look at this then.
-Jack
On Monday 24 September 2012 21:36, Roland Dreier wrote:
On Mon, Sep 24, 2012 at 7:02 AM, Stephen Rothwell s...@canb.auug.org.au
wrote:
After merging the akpm tree, today's linux-next build (powerpc
iniband tree and
> commit 0ff1fb654bec ("{NET, IB}/mlx4: Add device managed flow steering
> firmware API") from the net-next tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix
> as necessary.
Thanks, Stephen!
Your merge looks fine. Ack.
-Ja
fix as necessary.
Thanks, Stephen!
Ack for IB side.
-Jack
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
them) from the infiniband tree and commit
0ff1fb654bec ({NET, IB}/mlx4: Add device managed flow steering firmware
API) from the net-next tree.
Just context changes (I think). I have fixed it up (see below) and can
carry the fix as necessary.
Thanks, Stephen!
Ack for IB side.
-Jack
, IB}/mlx4: Add device managed flow steering
firmware API) from the net-next tree.
Just context changes. I fixed it up (see below) and can carry the fix
as necessary.
Thanks, Stephen!
Your merge looks fine. Ack.
-Jack
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
ds on a system simulator.
--- jack
--
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
callouts
Unfortunately, the current driver does not allow me to quantify
which of the differences is most significant.
Also, I'll try to post the driver within the next few days. It is
still in development but it compiles and can successfully run most
workloads on a system simulator.
--- jack
Flushing on the GRU is slow so being able to flush
multiple pages with a single request is a benefit.
Seems like the latter difference could be significant for other users
of mmu notifiers.
--- jack
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
being able to flush
multiple pages with a single request is a benefit.
Seems like the latter difference could be significant for other users
of mmu notifiers.
--- jack
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
not seen your patch recently). So I don't know exactly what you
> are doing...
>
> But why does _anybody_ (why does Christoph's patches) need to invalidate
> when they are going to be more permissive? This should be done lazily by
> the driver, I would have thought.
Agree. Althoug
will fault again & the TLB
dropin will be repeated. This is optimized for the case where invalidates
are rare - true for users of the GRU.
In general, though, I agree. Most users of mmu_notifiers would likely
required a mutex or something equivalent.
--- jack
--
To unsubscribe
. This is optimized for the case where invalidates
are rare - true for users of the GRU.
In general, though, I agree. Most users of mmu_notifiers would likely
required a mutex or something equivalent.
--- jack
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
does Christoph's patches) need to invalidate
when they are going to be more permissive? This should be done lazily by
the driver, I would have thought.
Agree. Although for most real applications, the performance difference
is probably negligible.
--- jack
--
To unsubscribe from this list: send
and a hardware simulator.
The driver itself is still a few weeks from being ready to post but I can
send code fragments of the portions related to mmuops or external TLB
management if anyone is interested.
--- jack
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
itself is still a few weeks from being ready to post but I can
send code fragments of the portions related to mmuops or external TLB
management if anyone is interested.
--- jack
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
On Tuesday 12 February 2008 00:18, Roland Dreier wrote:
> Thanks, applied.
>
> Jack, I thought you guys tested the build on powerpc. How did this
> sneak through?
>
It did not sneak through, because the problem does not exist in the OFED git.
The following commit was pe
On Tuesday 12 February 2008 00:18, Roland Dreier wrote:
Thanks, applied.
Jack, I thought you guys tested the build on powerpc. How did this
sneak through?
It did not sneak through, because the problem does not exist in the OFED git.
The following commit was performed to
git
It did this with and without the PAX patch
--
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Trying to boot 2.6.24 produces the following error messages when udev is
called:
VFS: Mounted root (xfs filesystem) readonly.
Freeing unused kernel memory: 208k freed
PAX: modprobe:752, uid/euid: 0/0, invalid execution attempt at
88018000 RIP:
[] :videodev:videodev_init+0x0/0x87
PGD
Trying to boot 2.6.24 produces the following error messages when udev is
called:
VFS: Mounted root (xfs filesystem) readonly.
Freeing unused kernel memory: 208k freed
PAX: modprobe:752, uid/euid: 0/0, invalid execution attempt at
88018000 RIP:
[88018000]
It did this with and without the PAX patch
--
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ay do it once you add start,end to range_end
> > > only thanks to the additional pin on the page.
> >
> > Right but that pin requires taking a refcount which we cannot do.
>
> GRU can use my patch without the pin. XPMEM obviously can't use my
> patch as my invalida
an incremental patch adding
invalidate_range_start/end would be required to support XPMEM too.
--- jack
--
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://vger.kernel.org/majordomo-info.html
Please
On Thu, Jan 31, 2008 at 06:39:19PM -0800, Christoph Lameter wrote:
> On Thu, 31 Jan 2008, Robin Holt wrote:
>
> > Jack has repeatedly pointed out needing an unregister outside the
> > mmap_sem. I still don't see the benefit to not having the lock in the mm.
>
> I never u
On Thu, Jan 31, 2008 at 08:24:44PM -0600, Robin Holt wrote:
> On Thu, Jan 31, 2008 at 07:56:12PM -0600, Jack Steiner wrote:
> > > @@ -2033,6 +2034,7 @@ void exit_mmap(struct mm_struct *mm)
> > > unsigned long end;
> > >
> > > /* mm's last user ha
e_all" callout is not very descriptive.
Why not use "exit_mmap". That matches the function name, the arch callout
and better describes what is happening.
--- jack
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messag
On Thu, Jan 31, 2008 at 08:24:44PM -0600, Robin Holt wrote:
On Thu, Jan 31, 2008 at 07:56:12PM -0600, Jack Steiner wrote:
@@ -2033,6 +2034,7 @@ void exit_mmap(struct mm_struct *mm)
unsigned long end;
/* mm's last user has gone, and its about to be pulled down
On Thu, Jan 31, 2008 at 06:39:19PM -0800, Christoph Lameter wrote:
On Thu, 31 Jan 2008, Robin Holt wrote:
Jack has repeatedly pointed out needing an unregister outside the
mmap_sem. I still don't see the benefit to not having the lock in the mm.
I never understood why this would
On Wed, Jan 30, 2008 at 11:41:29AM -0800, Christoph Lameter wrote:
> On Wed, 30 Jan 2008, Jack Steiner wrote:
>
> > I see what you mean. I need to review to mail to see why this changed
> > but in the original discussions with Christoph, the invalidate_range
> > callouts
e unregister function.
Currently, there is no __mmu_notifier_unregister() defined.
Moving to a different lock solves the problem.
-- jack
--
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wed, Jan 30, 2008 at 02:37:20PM +0100, Andrea Arcangeli wrote:
> On Tue, Jan 29, 2008 at 06:28:05PM -0600, Jack Steiner wrote:
> > On Tue, Jan 29, 2008 at 04:20:50PM -0800, Christoph Lameter wrote:
> > > On Wed, 30 Jan 2008, Andrea Arcangeli wrote:
> > >
>
On Wed, Jan 30, 2008 at 02:37:20PM +0100, Andrea Arcangeli wrote:
On Tue, Jan 29, 2008 at 06:28:05PM -0600, Jack Steiner wrote:
On Tue, Jan 29, 2008 at 04:20:50PM -0800, Christoph Lameter wrote:
On Wed, 30 Jan 2008, Andrea Arcangeli wrote:
invalidate_range after populate allows
the problem.
-- jack
--
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wed, Jan 30, 2008 at 11:41:29AM -0800, Christoph Lameter wrote:
On Wed, 30 Jan 2008, Jack Steiner wrote:
I see what you mean. I need to review to mail to see why this changed
but in the original discussions with Christoph, the invalidate_range
callouts were suppose to be made BEFORE
; > The last refcount is released by the invalidate_range itself.
>
> That is true for your implementation and to address Robin's issues. Jack:
> Is that true for the GRU?
I'm not sure I understand the question. The GRU never (currently) takes
a reference on a page. It has no mechanism for tracking
itself.
That is true for your implementation and to address Robin's issues. Jack:
Is that true for the GRU?
I'm not sure I understand the question. The GRU never (currently) takes
a reference on a page. It has no mechanism for tracking pages that
were exported to the external TLBs.
--- jack
On Jan 25, 2008 3:34 PM, Jack Harvard <[EMAIL PROTECTED]> wrote:
>
> On Jan 25, 2008 3:02 PM, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> >
> >
> > On Jan 25 2008 14:39, Jack Harvard wrote:
> > >> On Jan 25 2008 13:40, Jack Harvard wrote:
>
On Jan 25, 2008 3:02 PM, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
>
> On Jan 25 2008 14:39, Jack Harvard wrote:
> >> On Jan 25 2008 13:40, Jack Harvard wrote:
> >> >Hi,
> >> >
> >> >I'm trying to boot Linux, but the /init process f
On Jan 25, 2008 2:27 PM, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
>
> On Jan 25 2008 13:40, Jack Harvard wrote:
> >Hi,
> >
> >I'm trying to boot Linux, but the /init process failed. Here is the
> >info:
> >
> >=FF<6>/init exit code:
Hi,
I'm trying to boot Linux, but the /init process failed. Here is the
info:
=FF<6>/init exit code: -14
/init exit code: -14
<4>Failed to execute /init
Failed to execute /init
<6>/sbin/init exit code: -14
Just wondering what do those different exit codes mean?
Thanks, -J
--
To unsubscribe
401 - 500 of 827 matches
Mail list logo
