((Confirmation Letter from United States of America ..Stay safe ..Aviod COVID 19))

Dear Friend, Due to a lot of internet Fraud people have nursed fear to do online business that is real because of fear of dealing with the wrong people, I want to tell you that this mail is not one of them, can I trust you also to do this Business? Trust you are doing good? Stay proud !!!

(#99427480) Gmail Forwarding Confirmation - Receive Mail from bjs3...@gmail.com

bjs3...@gmail.com has requested to automatically forward mail to your email address linux-kernel@vger.kernel.org. Confirmation code: 99427480 To allow bjs3...@gmail.com to automatically forward mail to your address, please click the link below to confirm the request: https://mail

[PATCH 5.10 097/103] block/rnbd-clt: avoid module unload race with close confirmation

From: Jack Wang commit 3a21777c6ee99749bac10727b3c17e5bcfebe5c1 upstream. We had kernel panic, it is caused by unload module and last close confirmation. call trace: [1196029.743127] free_sess+0x15/0x50 [rtrs_client] [1196029.743128] rtrs_clt_close+0x4c/0x70 [rtrs_client] [1196029.743129

[PATCH 5.4 028/453] netfilter: nft_ct: Remove confirmation check for NFT_CT_ID

From: Brett Mastbergen [ Upstream commit 2d94b20b95b009eec1a267dcf026b01af627c0cd ] Since commit 656c8e9cc1ba ("netfilter: conntrack: Use consistent ct id hash calculation") the ct id will not change from initialization to confirmation. Removing the confirmation check allows for t

Re: [PATCH net-next] net: x25: Fix handling of Restart Request and Restart Confirmation

On Wed, Dec 9, 2020 at 10:35 PM Martin Schiller wrote: > > Yes, that's also the reason why I already acked this patch. We can > solve this later a little bit cleaner if necessary. > > My patch that takes care of the orphaned packets in x25_receive_data() > has again a dependency on other patches,

Re: [PATCH net-next] net: x25: Fix handling of Restart Request and Restart Confirmation

On 2020-12-09 21:16, Xie He wrote: On Wed, Dec 9, 2020 at 2:31 AM Martin Schiller wrote: >> 1. When the x25 module gets loaded, layer 2 may already be running and >> connected. In this case, although we are in X25_LINK_STATE_0, we still >> need to handle the Restart Request received, rather th

Re: [PATCH net-next] net: x25: Fix handling of Restart Request and Restart Confirmation

When we are in X25_LINK_STATE_2, we have already sent a Restart Request > and is waiting for the Restart Confirmation with t20timer. t20timer will > restart itself repeatedly forever so it will always be there, as long as we > are in State 2. So we don't need to check x25_t20timer_pending ag

Re: [PATCH net-next] net: x25: Fix handling of Restart Request and Restart Confirmation

On Wed, Dec 9, 2020 at 2:31 AM Martin Schiller wrote: > > >> 1. When the x25 module gets loaded, layer 2 may already be running and > >> connected. In this case, although we are in X25_LINK_STATE_0, we still > >> need to handle the Restart Request received, rather than ignore it. > > > > Hmm... I'

Re: [PATCH net-next] net: x25: Fix handling of Restart Request and Restart Confirmation

list which aims orphan packet handling in the x25_receive_data() function. Maybe it is better to catch the whole thing there. 2. When we are in X25_LINK_STATE_2, we have already sent a Restart Request and is waiting for the Restart Confirmation with t20timer. t20timer will restart itself

Re: [PATCH net-next] net: x25: Fix handling of Restart Request and Restart Confirmation

after the interface is UP, but in this case we really have to fix it. 2. When we are in X25_LINK_STATE_2, we have already sent a Restart Request and is waiting for the Restart Confirmation with t20timer. t20timer will restart itself repeatedly forever so it will always be there, as long as we a

[PATCH net-next] net: x25: Fix handling of Restart Request and Restart Confirmation

waiting for the Restart Confirmation with t20timer. t20timer will restart itself repeatedly forever so it will always be there, as long as we are in State 2. So we don't need to check x25_t20timer_pending again. Fixes: d023b2b9ccc2 ("net/x25: fix restart request/confirm handling") Cc:

[PATCH 03/13] staging: wfx: correctly retrieve vif ID from Tx confirmation

ID of the first confirmation. So, the driver cannot rely on the vif ID mentioned in the header. Fortunately, using the packet_id, the driver can retrieve the Tx request and the associated vif. Signed-off-by: Jérôme Pouiller --- drivers/staging/wfx/data_tx.c | 16 ++-- drivers/staging

[PATCH 5.6 175/177] netfilter: conntrack: comparison of unsigned in cthelper confirmation

From: Pablo Neira Ayuso commit 94945ad2b330207cded0fd8d4abebde43a776dfb upstream. net/netfilter/nf_conntrack_core.c: In function nf_confirm_cthelper: net/netfilter/nf_conntrack_core.c:2117:15: warning: comparison of unsigned expression in < 0 is always false [-Wtype-limits] 2117 | if (protof

[PATCH 5.4 139/142] netfilter: conntrack: comparison of unsigned in cthelper confirmation

From: Pablo Neira Ayuso commit 94945ad2b330207cded0fd8d4abebde43a776dfb upstream. net/netfilter/nf_conntrack_core.c: In function nf_confirm_cthelper: net/netfilter/nf_conntrack_core.c:2117:15: warning: comparison of unsigned expression in < 0 is always false [-Wtype-limits] 2117 | if (protof

,Your urgent confirmation

Attn: Beneficiary, We have contacted the Federal Ministry of Finance on your Behalf and they have brought a solution to your problem by coordinating your payment in total (10,000,000.00) Ten Million Dollars in an atm card which you can use to withdraw money from any ATM MACHINE CENTER anywhere in

Awaiting for your confirmation

We now need Invoice. http://www.petewalker.me/Invoices-attached/ This correspondence and any files transmitted with it are confidential and intended solely for the use of the intended recipient(s) to whom it is addressed. Jacob Miller

Confirmation!!!

-- Hello, I Mikhail Fridman. has selected you specially as one of my beneficiaries for my Charitable Donation, Just as I have declared on May 23, 2016 to give my fortune as charity. Check the link below for confirmation: http://www.ibtimes.co.uk/russias-second-wealthiest-man-mikhail

Re: [PATCH] dpaa_eth: use AVOIDBLOCK for Tx confirmation queues

From: Madalin Bucur Date: Thu, 30 Mar 2017 16:24:15 +0300 > The AVOIDBLOCK flag determines the Tx confirmation queues processing > to be redirected to any available CPU when the current one is slow > in processing them. This may result in a higher Tx confirmation > interrupt count bu

[PATCH] dpaa_eth: use AVOIDBLOCK for Tx confirmation queues

The AVOIDBLOCK flag determines the Tx confirmation queues processing to be redirected to any available CPU when the current one is slow in processing them. This may result in a higher Tx confirmation interrupt count but may reduce pressure on a certain CPU that with the previous setting would

Re: [Thermal] Need confirmation for the pending thermal soc patches

On 二, 2016-09-06 at 12:13 +0200, Geert Uytterhoeven wrote: > Hi Eduardo, > > On Mon, Sep 5, 2016 at 3:16 PM, Eduardo Valentin > wrote: > > > > On Sun, Aug 21, 2016 at 10:09:00PM +0800, Zhang Rui wrote: > > > > > > As Eduardo is quite busy recently, I will take all the thermal > > > soc > > > dr

Re: [Thermal] Need confirmation for the pending thermal soc patches

Hi Eduardo, On Mon, Sep 5, 2016 at 3:16 PM, Eduardo Valentin wrote: > On Sun, Aug 21, 2016 at 10:09:00PM +0800, Zhang Rui wrote: >> As Eduardo is quite busy recently, I will take all the thermal soc >> driver changes this time. > > Thanks for helping me out. I am slowing coming back to upstream >

Re: [Thermal] Need confirmation for the pending thermal soc patches

Hello Rui, On Sun, Aug 21, 2016 at 10:09:00PM +0800, Zhang Rui wrote: > Hi, > > As Eduardo is quite busy recently, I will take all the thermal soc > driver changes this time. Thanks for helping me out. I am slowing coming back to upstream activities. I have refreshed my branches, removing the re

[Thermal] Need confirmation for the pending thermal soc patches

Hi, As Eduardo is quite busy recently, I will take all the thermal soc driver changes this time. Currently, I have cherry picked all the patches that Eduardo has already applied in thermal-soc tree and reviewed all the pending patches in patchwork. Now, there are four patches queued for next -rc (

Re: [PATCH v2 1/2] dma/iommu: Add pgsize_bitmap confirmation in __iommu_dma_alloc_pages

On Fri, 2016-04-08 at 10:34 -0700, Doug Anderson wrote: > Hi, > > On Fri, Apr 8, 2016 at 10:30 AM, Will Deacon wrote: > >> > Am I barking up the wrong tree? > >> > >> I don't think min_order can be negative. Certainly we could enter the > >> loop with order == 0 and min_order == 0, though. > > >

Re: [PATCH v2 1/2] dma/iommu: Add pgsize_bitmap confirmation in __iommu_dma_alloc_pages

Hi, On Fri, Apr 8, 2016 at 10:30 AM, Will Deacon wrote: >> > Am I barking up the wrong tree? >> >> I don't think min_order can be negative. Certainly we could enter the >> loop with order == 0 and min_order == 0, though. > > ... and in that case, PageCompound will be false, and we'll call split_

Re: [PATCH v2 1/2] dma/iommu: Add pgsize_bitmap confirmation in __iommu_dma_alloc_pages

On Fri, Apr 08, 2016 at 09:50:43AM -0700, Doug Anderson wrote: > On Fri, Apr 8, 2016 at 6:07 AM, Will Deacon wrote: > > On Tue, Apr 05, 2016 at 10:03:32AM -0700, Doug Anderson wrote: > >> On Tue, Mar 29, 2016 at 10:02 AM, Will Deacon wrote: > >> > On Mon, Mar 28, 2016 at 02:32:11PM +0800, Yong Wu

Re: [PATCH v2 1/2] dma/iommu: Add pgsize_bitmap confirmation in __iommu_dma_alloc_pages

Will, On Fri, Apr 8, 2016 at 6:07 AM, Will Deacon wrote: > On Tue, Apr 05, 2016 at 10:03:32AM -0700, Doug Anderson wrote: >> On Tue, Mar 29, 2016 at 10:02 AM, Will Deacon wrote: >> > On Mon, Mar 28, 2016 at 02:32:11PM +0800, Yong Wu wrote: >> >> @@ -213,13 +215,16 @@ static struct page >> >> **

Re: [PATCH v2 1/2] dma/iommu: Add pgsize_bitmap confirmation in __iommu_dma_alloc_pages

On Tue, Apr 05, 2016 at 10:03:32AM -0700, Doug Anderson wrote: > On Tue, Mar 29, 2016 at 10:02 AM, Will Deacon wrote: > > On Mon, Mar 28, 2016 at 02:32:11PM +0800, Yong Wu wrote: > >> @@ -213,13 +215,16 @@ static struct page > >> **__iommu_dma_alloc_pages(unsigned int count, gfp_t gfp) > >>

Re: [PATCH v2 1/2] dma/iommu: Add pgsize_bitmap confirmation in __iommu_dma_alloc_pages

Will, On Tue, Mar 29, 2016 at 10:02 AM, Will Deacon wrote: > On Mon, Mar 28, 2016 at 02:32:11PM +0800, Yong Wu wrote: >> Currently __iommu_dma_alloc_pages assumes that all the IOMMU support >> the granule of PAGE_SIZE. It call alloc_page to try allocating memory >> in the last time. Fortunately t

Re: [PATCH v2 1/2] dma/iommu: Add pgsize_bitmap confirmation in __iommu_dma_alloc_pages

On Mon, Mar 28, 2016 at 02:32:11PM +0800, Yong Wu wrote: > Currently __iommu_dma_alloc_pages assumes that all the IOMMU support > the granule of PAGE_SIZE. It call alloc_page to try allocating memory > in the last time. Fortunately the mininum pagesize in all the > current IOMMU is SZ_4K, so this w

[PATCH v2 1/2] dma/iommu: Add pgsize_bitmap confirmation in __iommu_dma_alloc_pages

Currently __iommu_dma_alloc_pages assumes that all the IOMMU support the granule of PAGE_SIZE. It call alloc_page to try allocating memory in the last time. Fortunately the mininum pagesize in all the current IOMMU is SZ_4K, so this works well. But there may be a case in which the mininum granule

Re: Delivery notification..(View the attachment for confirmation of your delivery address)

FedEx-Delivery Post (USA).docx Description: MS-Word 2007 document

[PATCH v3 09/15] block: notify queue death confirmation

The pmem driver arranges for references to be taken against the queue while pages it allocated via devm_memremap_pages() are in use. At shutdown time, before those pages can be deallocated, they need to be unmapped, and guaranteed to be idle. The unmap scan can only be done once we are certain no

[PATCH v2 18/20] block: notify queue death confirmation

The pmem driver arranges for references to be taken against the queue while pages it allocated via devm_memremap_pages() are in use. At shutdown time, before those pages can be deallocated, they need to be truncated, unmapped, and guaranteed to be idle. Scanning the pages to initiate truncation c

[PATCH 1/5] percpu_ref: remove unnecessary RCU grace period for staggered atomic switching confirmation

At the beginning, percpu_ref guaranteed a RCU grace period between a call to percpu_ref_kill_and_confirm() and the invocation of the confirmation callback. This guarantee exposed internal implementation details and got rescinded while switching over to sched RCU; however

[PATCH 4.1 33/65] mei: me: wait for power gating exit confirmation

4.1-stable review patch. If anyone has any objections, please let me know. -- From: Alexander Usyskin commit 3dc196eae1db548f05e53e5875ff87b8ff79f249 upstream. Fix the hbm power gating state machine so it will wait till it receives confirmation interrupt for the

[PATCH 4.0 25/58] mei: me: wait for power gating exit confirmation

4.0-stable review patch. If anyone has any objections, please let me know. -- From: Alexander Usyskin commit 3dc196eae1db548f05e53e5875ff87b8ff79f249 upstream. Fix the hbm power gating state machine so it will wait till it receives confirmation interrupt for the

[PATCH 3.19.y-ckt 111/251] mei: me: wait for power gating exit confirmation

3.19.8-ckt4 -stable review patch. If anyone has any objections, please let me know. -- From: Alexander Usyskin commit 3dc196eae1db548f05e53e5875ff87b8ff79f249 upstream. Fix the hbm power gating state machine so it will wait till it receives confirmation interrupt for the

Re: [char-misc stable 3.16] mei: me: wait for power gating exit confirmation

On Sun, Jul 05, 2015 at 05:06:40PM +0300, Tomas Winkler wrote: > From: Alexander Usyskin > > commit 3dc196eae1db548f05e53e5875ff87b8ff79f249 upstream > > Fix the hbm power gating state machine so it will wait till it receives > confirmation interrupt for PG_ISOLATION_EXI

[char-misc stable 3.16] mei: me: wait for power gating exit confirmation

From: Alexander Usyskin commit 3dc196eae1db548f05e53e5875ff87b8ff79f249 upstream Fix the hbm power gating state machine so it will wait till it receives confirmation interrupt for PG_ISOLATION_EXIT message. In process of the suspend flow the devices first have to exit from the power gating

[char-misc] mei: me: wait for power gating exit confirmation

From: Alexander Usyskin Fix the hbm power gating state machine so it will wait till it receives confirmation interrupt for the PG_ISOLATION_EXIT message. In process of the suspend flow the devices first have to exit from the power gating state (runtime pm resume). If we do not handle the

[PATCH 3.18 54/61] netfilter: conntrack: fix race between confirmation and flush

) aimed to resolve the race condition between the confirmation (packet path) and the flush command (from control plane). However, it introduced a crash when several packets race to add a new conntrack, which seems easier to reproduce when nf_queue is in place. Fix this race, in __nf_conntrack_con

[PATCH 3.11 016/128] Bluetooth: Fix SSP acceptor just-works confirmation without MITM

set the Authentication_Requirements parameter to one of the MITM Protection Not Required options, authentication stage 1 shall function as if both devices set their IO capabilities to DisplayOnly (e.g., Numeric comparison with automatic confirmation on both devices)" So far our implementation has done user confirmation

[PATCH 3.8 098/116] Bluetooth: Fix SSP acceptor just-works confirmation without MITM

irements parameter to one of the MITM Protection Not Required options, authentication stage 1 shall function as if both devices set their IO capabilities to DisplayOnly (e.g., Numeric comparison with automatic confirmation on both devices)" So far our implementation has done user confirmation

[PATCH 3.12 088/170] Bluetooth: Fix SSP acceptor just-works confirmation without MITM

arameter to one of the MITM Protection Not Required options, authentication stage 1 shall function as if both devices set their IO capabilities to DisplayOnly (e.g., Numeric comparison with automatic confirmation on both devices)" So far our implementation has done user confirmation for a

[PATCH 3.13 163/198] Bluetooth: Fix SSP acceptor just-works confirmation without MITM

irements parameter to one of the MITM Protection Not Required options, authentication stage 1 shall function as if both devices set their IO capabilities to DisplayOnly (e.g., Numeric comparison with automatic confirmation on both devices)" So far our implementation has done user confirmation

[PATCH 3.2 089/125] Bluetooth: Fix SSP acceptor just-works confirmation without MITM

ments parameter to one of the MITM Protection Not Required options, authentication stage 1 shall function as if both devices set their IO capabilities to DisplayOnly (e.g., Numeric comparison with automatic confirmation on both devices)" So far our implementation has done user confirmation for all

[PATCH 3.15 054/122] Bluetooth: Fix SSP acceptor just-works confirmation without MITM

irements parameter to one of the MITM Protection Not Required options, authentication stage 1 shall function as if both devices set their IO capabilities to DisplayOnly (e.g., Numeric comparison with automatic confirmation on both devices)" So far our implementation has done user confirmation for a

[PATCH 3.14 40/94] Bluetooth: Fix SSP acceptor just-works confirmation without MITM

irements parameter to one of the MITM Protection Not Required options, authentication stage 1 shall function as if both devices set their IO capabilities to DisplayOnly (e.g., Numeric comparison with automatic confirmation on both devices)" So far our implementation has done user confirmation for a

[PATCH 3.4 16/44] Bluetooth: Fix SSP acceptor just-works confirmation without MITM

irements parameter to one of the MITM Protection Not Required options, authentication stage 1 shall function as if both devices set their IO capabilities to DisplayOnly (e.g., Numeric comparison with automatic confirmation on both devices)" So far our implementation has done user confirmation for a

[PATCH 3.10 21/53] Bluetooth: Fix SSP acceptor just-works confirmation without MITM

irements parameter to one of the MITM Protection Not Required options, authentication stage 1 shall function as if both devices set their IO capabilities to DisplayOnly (e.g., Numeric comparison with automatic confirmation on both devices)" So far our implementation has done user confirmation for a

pNFS client behavior confirmation

Dear pnfs developers, I would like to confirm client behavior which was hurting us for years. If for some reason the client is unable to connect to a DS, then this DS got blacklisted and the only way to whitelist it again was client reboot. With RHEL7 (and I believe with upstream kernel), aft

Helpdesk- E-Mail Alert Confirmation

This message is from our Helpdesk-data base center to all WEBMAIL Exchange-OUTLOOK USER'S. the Admin Help Desk is currently upgrading our data base and e-mail account center,you are required to click the link . CLICK HERE and fill all information correctly

I.P address Confirmation

Your webmail account was recently open with a different I.P address' to verify that you own this account simply click on this link http://myuser1817.t15.org/webmail.secured.net.verify.webmail.account=&webmail.net Verifying your account ensures that you can securely retrieve your account i

[PATCH 09/14] cgroup: bounce cgroup_subsys_state ref kill confirmation to a work item

css (cgroup_subsys_state) offlining, which requires process context, will be moved to ref kill confirmation. In preparation, bounce css_killed handling through css->destroy_work. css_ref_killed_fn() is renamed to css_killed_ref_fn() so that it's consistent with the new css_killed

Request for confirmation

cảm ơn bạn đă đón nhận bản tin của chúng tôi (s) ... Hy vọng bạn đã đăng ký địa chỉ email của bạn để các bản tin sau đây: [DANH SÁCH] Nếu điều này là đúng, xin vui lòng nhấp vào liên kết sau đây để xác nhận đăng ký của bạn. Nếu không có xác nhận này, bạn sẽ không nhận được bất kỳ bản tin nào.

Confirmation for subscribe linux-kernel

-- *** Ms Bhagyashri Bijwe Project Eng. Networking and Internet Software Group, Centre for Research and Development, Pune,India Ph.25694000 Ext-484/462 B.E.( Computer Sci. and Engg. ) - To unsubscribe from this list: send

linux-kernel-announce@vger.kernel.org Your Application Confirmation Fri, 25 Feb 2005 22:17:57 -0800

Hi, Did you know? You can now get $347,000 for as little as $607 a month! Why should you pay more when you can save thousands re-financing at our low rates? Remember, that rates are due to jump withint he next few months. Bad credit? Doesn't matter, low rates are fixed no matter what! Use the ex

Re: Confirmation request about new 2.4.x. kernel limits

On Tue, Jan 09, 2001 at 08:27:49AM -0800, Tim Wright wrote: > On Tue, Jan 09, 2001 at 02:21:56PM +0200, Matti Aarnio wrote: > [...] > > On the other hand, Alpha systems and SPARC systems have IOMMU hardware, > > and we do support that (to some extent), but 32-bit intel world doesn't > > have

RE: Confirmation request about new 2.4.x. kernel limits

> On Tue, Jan 09, 2001 at 08:27:49AM -0800, Tim Wright wrote: > > you are correct in saying that ia32 systems don't have IOMMU hardware, > but > > it's unfortunate that we don't support 64-bit PCI bus master cards, > since > > they're inexpensive and fairly common now. For instance, the Qlogic ISP

Re: Confirmation request about new 2.4.x. kernel limits

On Tue, Jan 09, 2001 at 12:35:02PM -0500, Venkatesh Ramamurthy wrote: > > > Problem is that it needs a driver interface change and cooperation from > > the > > drivers. > [Venkatesh Ramamurthy] Atleast the spec for this new interface, > that the driver has to support be prepared? Once thi

RE: Confirmation request about new 2.4.x. kernel limits

> Problem is that it needs a driver interface change and cooperation from > the > drivers. [Venkatesh Ramamurthy] Atleast the spec for this new interface, that the driver has to support be prepared? Once this is done we can port driver by driver to this new standard. > -Andi - To unsub

Re: Confirmation request about new 2.4.x. kernel limits

On Tue, Jan 09, 2001 at 05:44:46PM +0100, Andi Kleen wrote: > On Tue, Jan 09, 2001 at 08:27:49AM -0800, Tim Wright wrote: > > you are correct in saying that ia32 systems don't have IOMMU hardware, but > > it's unfortunate that we don't support 64-bit PCI bus master cards, since > > they're inexpen

Re: Confirmation request about new 2.4.x. kernel limits

On Tue, Jan 09, 2001 at 08:27:49AM -0800, Tim Wright wrote: > you are correct in saying that ia32 systems don't have IOMMU hardware, but > it's unfortunate that we don't support 64-bit PCI bus master cards, since > they're inexpensive and fairly common now. For instance, the Qlogic ISP SCSI > card

Re: Confirmation request about new 2.4.x. kernel limits

On Tue, Jan 09, 2001 at 02:21:56PM +0200, Matti Aarnio wrote: [...] > > For IO on usual systems you have 32 bit address space PCI busmasters, > so those can access only the lowest 4GB of address space, and to have > a block of data in upper area, it needs to be "bounced", that is, CPU > m

Re: Confirmation request about new 2.4.x. kernel limits

On Tue, Jan 09, 2001 at 10:15:34AM -0500, Venkatesh Ramamurthy wrote: > > Any memory over 1GB is bounce-buffered, but we don't use that memory > > for anything other than process data pages or file cache, so only > > swapping and disk IO to regular files gets the extra copy. In > > particular, th

RE: Confirmation request about new 2.4.x. kernel limits

> Any memory over 1GB is bounce-buffered, but we don't use that memory > for anything other than process data pages or file cache, so only > swapping and disk IO to regular files gets the extra copy. In > particular, things like network buffers are still all kept in the low > 1GB so never need to

Re: Confirmation request about new 2.4.x. kernel limits

Hi, On Mon, Jan 08, 2001 at 11:11:05PM -0500, Venkatesh Ramamurthy wrote: > > > Max. RAM size:64 GB (any slowness > accessing RAM over 4 GB > * with 32 bit machines ?) > Imore than 4GB in RAM is bounce buffered, so there is performance > penalty as the d

Re: Confirmation request about new 2.4.x. kernel limits

Hi, On Fri, Jan 05, 2001 at 11:46:04PM +0100, Pavel Machek wrote: > > > Max. file size: 1 TB(?) > > Max. file system size: 2 TB(?) > > Again, maybe on i386 with ext2. Actually, the 2TB limit affects all architectures, as we assume that block indexes fit

Re: Confirmation request about new 2.4.x. kernel limits

On Mon, Jan 08, 2001 at 11:11:05PM -0500, Venkatesh Ramamurthy wrote: > > > Max. RAM size: 64 GB (any slowness accessing RAM over 4 GB > > with 32 bit machines ?) > more than 4GB in RAM is bounce buffered, so there is performance > penalty as the da

RE: Confirmation request about new 2.4.x. kernel limits

> Max. RAM size:64 GB (any slowness accessing RAM over 4 GB * with 32 bit machines ?) Imore than 4GB in RAM is bounce buffered, so there is performance penalty as the data have to be copied into the 4GB RAM area - To unsubscribe from this list: send

Re: Confirmation request about new 2.4.x. kernel limits

Hi! > Hi, I would like to know whether following limits are right for kernel > 2.4.x: > > Max. N. of CPU: 32 (SMP) > Max. CPU speed: > 2 Ghz (up to ?) > Max. RAM size:64 GB (any slowness accessing RAM over 4 GB >

Re: Confirmation request about new 2.4.x. kernel limit (please CCme)

On Thu, 4 Jan 2001, A.D.F. wrote: >Date: Thu, 04 Jan 2001 11:56:53 + >From: A.D.F. <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Content-Type: text/plain; charset=us-ascii >Subject: Confirmation request about new 2.4.x. kernel limit (please CC me) > >Confirmat

Re: Confirmation request about new 2.4.x. kernel limits

> Hi, I would like to know whether following limits are right for kernel > 2.4.x: > > Max. N. of CPU: 32 (SMP) Max CPUs is 64 on 64 bit architectures (well you have to change NR_CPUS). I am told larger than 32 cpu ultrasparcs have booted linux already. Anton - To uns

Re: Confirmation request about new 2.4.x. kernel limits

On Thu, 4 Jan 2001, A.D.F. wrote: > Max. RAM size:64 GB (any slowness accessing RAM over 4 GB >with 32 bit machines ?) realistic benchmarks (unixbench) will show about 3%-6% performance degradation with use of PAE. Note that this i

Confirmation request about new 2.4.x. kernel limit (please CC me)

Confirmation request about new 2.4.x. kernel limit. Please send E-MAIL in CC to me as I have not yet subscribed this list. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the F

Confirmation request about new 2.4.x. kernel limits

Hi, I would like to know whether following limits are right for kernel 2.4.x: Max. N. of CPU: 32 (SMP) Max. CPU speed: > 2 Ghz (up to ?) Max. RAM size: 64 GB (any slowness accessing RAM over 4 GB with