Re: [PATCH net] cosa: Add missing kfree in error path of cosa_write

Wang Hai wrote: : If memory allocation for 'kbuf' succeed, cosa_write() doesn't have a : corresponding kfree() in exception handling. Thus add kfree() for this : function implementation. Acked-By: Jan "Yenya" Kasprzak Looks correct, thanks. That said, COSA is an ancient ISA bus device designed

Re: wan-cosa: Use memdup_user() rather than duplicating its implementation

SF Markus Elfring wrote: : > What about the GFP_DMA attribute, which your patch deletes? : > The buffer in question has to be ISA DMA-able. : : Thanks for your constructive feedback. : : Would you be interested in using a variant of the function "memdup_…" : with which the corresponding

Re: wan-cosa: Use memdup_user() rather than duplicating its implementation

SF Markus Elfring wrote: : > What about the GFP_DMA attribute, which your patch deletes? : > The buffer in question has to be ISA DMA-able. : : Thanks for your constructive feedback. : : Would you be interested in using a variant of the function "memdup_…" : with which the corresponding

Re: [PATCH] wan-cosa: Use memdup_user() rather than duplicating its implementation

Hello, SF Markus Elfring wrote: : From: Markus Elfring : Date: Sat, 20 Aug 2016 10:10:12 +0200 : : Reuse existing functionality from memdup_user() instead of keeping : duplicate source code. : : This issue was detected by using the Coccinelle software.

Re: [PATCH] wan-cosa: Use memdup_user() rather than duplicating its implementation

Hello, SF Markus Elfring wrote: : From: Markus Elfring : Date: Sat, 20 Aug 2016 10:10:12 +0200 : : Reuse existing functionality from memdup_user() instead of keeping : duplicate source code. : : This issue was detected by using the Coccinelle software. What about the GFP_DMA

Re: [PATCH 2/2] cosa.c : Array index 'i' is used before limits check.

Sergei Shtylyov wrote: : Hello. : : On 02/24/2015 10:52 PM, Ameen Ali wrote: : : >avoid out-of-bounds-read by checking count before indexing. : : >Signed-off-by: Ameen Ali : >--- : > drivers/net/wan/cosa.c | 2 +- : > 1 file changed, 1 insertion(+), 1 deletion(-) : : >diff --git

Re: [PATCH 2/2] cosa.c : Array index 'i' is used before limits check.

Sergei Shtylyov wrote: : Hello. : : On 02/24/2015 10:52 PM, Ameen Ali wrote: : : avoid out-of-bounds-read by checking count before indexing. : : Signed-off-by: Ameen Ali ameenali...@gmail.com : --- : drivers/net/wan/cosa.c | 2 +- : 1 file changed, 1 insertion(+), 1 deletion(-) : : diff

Re: PATCH: mvsas: add support for Supermicro AOC-SAS2LP-MV8

Christoph Hellwig wrote: : On Fri, May 16, 2014 at 02:06:42PM +0200, Jan Kasprzak wrote: : > any news with this patch? Will it be acked by you and submitted upstream? : > Thanks! : : Give me an Acked-by and I'll pull it in. Acked-By: Jan "Yenya" Kasprzak Not sure whether I s

Re: PATCH: mvsas: add support for Supermicro AOC-SAS2LP-MV8

Christoph Hellwig wrote: : On Fri, May 16, 2014 at 02:06:42PM +0200, Jan Kasprzak wrote: : any news with this patch? Will it be acked by you and submitted upstream? : Thanks! : : Give me an Acked-by and I'll pull it in. Acked-By: Jan Yenya Kasprzak k...@fi.muni.cz Not sure whether I should

Re: PATCH: mvsas: add support for Supermicro AOC-SAS2LP-MV8

it be acked by you and submitted upstream? Thanks! -Jan Kasprzak -- | Jan "Yenya" Kasprzak | | New GPG 4096R/A45477D5 - see http://www.fi.muni.cz/~kas/pgp-rollover.txt | | http://www.fi.muni.cz/~kas/Journal: http://www.fi.muni.cz/~kas/blog/ | There's clearly a balance between "oct

Re: PATCH: mvsas: add support for Supermicro AOC-SAS2LP-MV8

upstream? Thanks! -Jan Kasprzak -- | Jan Yenya Kasprzak kas at {fi.muni.cz - work | yenya.net - private} | | New GPG 4096R/A45477D5 - see http://www.fi.muni.cz/~kas/pgp-rollover.txt | | http://www.fi.muni.cz/~kas/Journal: http://www.fi.muni.cz/~kas/blog/ | There's clearly a balance between

PATCH: mvsas: add support for Supermicro AOC-SAS2LP-MV8

Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Kernel driver in use: mvsas Kernel modules: mvsas Signed-off-by: Jan Kasprzak

PATCH: mvsas: add support for Supermicro AOC-SAS2LP-MV8

Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Kernel driver in use: mvsas Kernel modules: mvsas Signed-off-by: Jan Kasprzak k

Re: [patch 05/14] Convert from class_device to device for cosa sync driver

Tony Jones wrote: : On Mon, Aug 20, 2007 at 03:48:11PM -0700, [EMAIL PROTECTED] wrote: : > -- : > Content-Disposition: inline; filename=wan.patch : > : > Convert from class_device to device for drivers/net/wan/cosa. This is part of : > the work to eliminate struct class_device. : :

Re: [patch 05/14] Convert from class_device to device for cosa sync driver

Tony Jones wrote: : On Mon, Aug 20, 2007 at 03:48:11PM -0700, [EMAIL PROTECTED] wrote: : -- : Content-Disposition: inline; filename=wan.patch : : Convert from class_device to device for drivers/net/wan/cosa. This is part of : the work to eliminate struct class_device. : : Signed-off-by:

Re: MOXA: mxser_new lockup

Jiri Slaby wrote: : I went through the locking again just now, but I can't see anything : wrong. Could you please enable CONFIG_PROVE_LOCKING and CONFIG_DEBUG_LOCKDEP and : retest? : : And also post stty -a -F /dev/ttyMIXX or a setup passed to : tcsetattr/ioctl(TCSETA/S) if available. What do

Re: MOXA: mxser_new lockup

Jiri Slaby wrote: : I went through the locking again just now, but I can't see anything : wrong. Could you please enable CONFIG_PROVE_LOCKING and CONFIG_DEBUG_LOCKDEP and : retest? : : And also post stty -a -F /dev/ttyMIXX or a setup passed to : tcsetattr/ioctl(TCSETA/S) if available. What do

MOXA: mxser_new lockup

Hello, I have a MOXA C168H card, and after the upgrade from 2.6.19 to 2.6.21-rc6 (and from moxa.c to mxser_new.c) I get a system lockup after few seconds of communicating over the MOXA serial line. Noting is printed on the serial console at all. The system is SMP x86_64 (Fedora 5). I may

MOXA: mxser_new lockup

Hello, I have a MOXA C168H card, and after the upgrade from 2.6.19 to 2.6.21-rc6 (and from moxa.c to mxser_new.c) I get a system lockup after few seconds of communicating over the MOXA serial line. Noting is printed on the serial console at all. The system is SMP x86_64 (Fedora 5). I may

Re: No mptable found (Tyan h1000E)

Len Brown wrote: : This board appears to have no APIC (MADT) table -- which is what Linux uses to enumerate processors : in ACPI mode. (doesn't have MPS either, but in ACPI mode you wouldn't use it anyway). : : Are there any BIOS SETUP settings for enabling SMP or ACPI features? : In

Re: No mptable found (Tyan h1000E)

Len Brown wrote: : This board appears to have no APIC (MADT) table -- which is what Linux uses to enumerate processors : in ACPI mode. (doesn't have MPS either, but in ACPI mode you wouldn't use it anyway). : : Are there any BIOS SETUP settings for enabling SMP or ACPI features? : In

No mptable found (Tyan h1000E)

Hello, I have a Tyan h1000E (S3970) dual-socket board, with two dual-core AMD Athlon 2210 CPUs (4 cores total). The problem is that the kernel apparently cannot detect the SMP configuration (after boot, /proc/cpuinfo lists only one processor). The full dmesg output is available at

No mptable found (Tyan h1000E)

Hello, I have a Tyan h1000E (S3970) dual-socket board, with two dual-core AMD Athlon 2210 CPUs (4 cores total). The problem is that the kernel apparently cannot detect the SMP configuration (after boot, /proc/cpuinfo lists only one processor). The full dmesg output is available at

TCP segmentation offload performance

Hello, world! I tried to find out whether the TCP segmentation offload can perform better on my server than no TSO at all. My server is dual Opteron 244 with Tyan S2882 board with the following NIC: eth0: Tigon3 [partno(BCM95704A7) rev 2003 PHY(5704)] (PCIX:100MHz:64-bit)

TCP segmentation offload performance

Hello, world! I tried to find out whether the TCP segmentation offload can perform better on my server than no TSO at all. My server is dual Opteron 244 with Tyan S2882 board with the following NIC: eth0: Tigon3 [partno(BCM95704A7) rev 2003 PHY(5704)] (PCIX:100MHz:64-bit)

2.6.11.3 slab error crash

Hi all, yesterday our HP DL-585 quad opteron server running 2.6.11.3 crashed with the attached messages. The main load is NFS serving and running postfix as well as some other userland processes. The server uses XFS on top of LVM for NFS-exported volumes. More details available at

2.6.11.3 slab error crash

Hi all, yesterday our HP DL-585 quad opteron server running 2.6.11.3 crashed with the attached messages. The main load is NFS serving and running postfix as well as some other userland processes. The server uses XFS on top of LVM for NFS-exported volumes. More details available at

Re: drivers/block/ub.c and multiple LUNs

Pete Zaitcev wrote: : On Mon, 21 Mar 2005 12:42:45 +0100 Jan Kasprzak <[EMAIL PROTECTED]> wrote: : : > is the ub.c USB storage driver supposed to work with multi-LUN(?) devices? : : There's no reason why it won't, see the attached patch. I just need to : send the patch to Greg Kroa

Re: drivers/block/ub.c and multiple LUNs

Pete Zaitcev wrote: : On Mon, 21 Mar 2005 12:42:45 +0100 Jan Kasprzak [EMAIL PROTECTED] wrote: : : is the ub.c USB storage driver supposed to work with multi-LUN(?) devices? : : There's no reason why it won't, see the attached patch. I just need to : send the patch to Greg Kroah one day

drivers/block/ub.c and multiple LUNs

Hello, is the ub.c USB storage driver supposed to work with multi-LUN(?) devices? I have a Palm Tungsten T5, which in drive mode looks like two USB storage devices (the internal flash is one LUN and the SD/MMC card in the slot is another one). With usb_storage driver I can see both

drivers/block/ub.c and multiple LUNs

Hello, is the ub.c USB storage driver supposed to work with multi-LUN(?) devices? I have a Palm Tungsten T5, which in drive mode looks like two USB storage devices (the internal flash is one LUN and the SD/MMC card in the slot is another one). With usb_storage driver I can see both

Re: [ACPI] inappropriate use of in_atomic()

Andrew Morton wrote: : : in_atomic() is not a reliable indication of whether it is currently safe : to call schedule(). : : This is because the lockdepth beancounting which in_atomic() uses is only : accumulated if CONFIG_PREEMPT=y. in_atomic() will return false inside : spinlocks if

Re: [ACPI] inappropriate use of in_atomic()

Andrew Morton wrote: : : in_atomic() is not a reliable indication of whether it is currently safe : to call schedule(). : : This is because the lockdepth beancounting which in_atomic() uses is only : accumulated if CONFIG_PREEMPT=y. in_atomic() will return false inside : spinlocks if

Re: sysfs/kobject update breaks ACPI?

Jan Kasprzak wrote: : my laptop (Asus M6R, http://www.fi.muni.cz/~kas/m6r/) has problems with : ACPI with newer kernels - most of ACPI operations fail [...] : However, the patch does not touch anything related to ACPI : (I think). It is a sysfs and kobject update. So I don't see how

sysfs/kobject update breaks ACPI?

Hi all, my laptop (Asus M6R, http://www.fi.muni.cz/~kas/m6r/) has problems with ACPI with newer kernels - most of ACPI operations fail - here is the sample of error messages printed during boot. All other error messages contain the "AE_TIME" line as well: Initializing Cryptographic API

sysfs/kobject update breaks ACPI?

Hi all, my laptop (Asus M6R, http://www.fi.muni.cz/~kas/m6r/) has problems with ACPI with newer kernels - most of ACPI operations fail - here is the sample of error messages printed during boot. All other error messages contain the AE_TIME line as well: Initializing Cryptographic API

Re: sysfs/kobject update breaks ACPI?

Jan Kasprzak wrote: : my laptop (Asus M6R, http://www.fi.muni.cz/~kas/m6r/) has problems with : ACPI with newer kernels - most of ACPI operations fail [...] : However, the patch does not touch anything related to ACPI : (I think). It is a sysfs and kobject update. So I don't see how

Re: Memory leak in 2.6.11-rc1?

Jan Kasprzak wrote: : I think I have been running 2.6.10-rc3 before. I've copied : the fs/bio.c from 2.6.10-rc3 to my 2.6.11-rc2 sources and booted the : resulting kernel. I hope it will not eat my filesystems :-) I will send : my /proc/slabinfo in a few days. Hmm, after 3h35min

Re: Memory leak in 2.6.11-rc1?

[EMAIL PROTECTED] wrote: : My guess would be the clone change, if raid was not leaking before. I : cannot lookup any patches at the moment, as I'm still at the hospital : taking care of my new born baby and wife :) Congratulations! : But try and reverse the patches to fs/bio.c that

Re: Memory leak in 2.6.11-rc1?

Linus Torvalds wrote: : Jan - can you give Jens a bit of an idea of what drivers and/or schedulers : you're using? I have a Tyan S2882 dual Opteron, network is on-board tg3, there are 8 P-ATA HDDs hooked on 3ware 7506-8 controller (no HW RAID there, but the drives are partitioned and

Re: Memory leak in 2.6.11-rc1?

: I've been running 2.6.11-rc1 on my dual opteron Fedora Core 3 box for a week : now, and I think there is a memory leak somewhere. I am measuring the : size of active and inactive pages (from /proc/meminfo), and it seems : that the count of sum (active+inactive) pages is decreasing. Please : take

Re: Memory leak in 2.6.11-rc1?

: I've been running 2.6.11-rc1 on my dual opteron Fedora Core 3 box for a week : now, and I think there is a memory leak somewhere. I am measuring the : size of active and inactive pages (from /proc/meminfo), and it seems : that the count of sum (active+inactive) pages is decreasing. Please : take

Re: Memory leak in 2.6.11-rc1?

Linus Torvalds wrote: : Jan - can you give Jens a bit of an idea of what drivers and/or schedulers : you're using? I have a Tyan S2882 dual Opteron, network is on-board tg3, there are 8 P-ATA HDDs hooked on 3ware 7506-8 controller (no HW RAID there, but the drives are partitioned and

Re: Memory leak in 2.6.11-rc1?

[EMAIL PROTECTED] wrote: : My guess would be the clone change, if raid was not leaking before. I : cannot lookup any patches at the moment, as I'm still at the hospital : taking care of my new born baby and wife :) Congratulations! : But try and reverse the patches to fs/bio.c that

Re: Memory leak in 2.6.11-rc1?

Jan Kasprzak wrote: : I think I have been running 2.6.10-rc3 before. I've copied : the fs/bio.c from 2.6.10-rc3 to my 2.6.11-rc2 sources and booted the : resulting kernel. I hope it will not eat my filesystems :-) I will send : my /proc/slabinfo in a few days. Hmm, after 3h35min

Re: 2.6.11-rc1-bk9 crash in mdadm

Lars Marowsky-Bree wrote: : On 2005-01-21T17:12:30, Jan Kasprzak <[EMAIL PROTECTED]> wrote: : : > Just FWIW, I've got the following crash when trying to boot a 2.6.11-rc1-bk9 : > kernel on my dual opteron Fedora Core 3 box. I will try -bk8 now. : : Attached is a likely candida

Memory leak in 2.6.11-rc1?

Hi all, I've been running 2.6.11-rc1 on my dual opteron Fedora Core 3 box for a week now, and I think there is a memory leak somewhere. I am measuring the size of active and inactive pages (from /proc/meminfo), and it seems that the count of sum (active+inactive) pages is decreasing.

2.6.11-rc1-bk9 crash in mdadm

Hi, Just FWIW, I've got the following crash when trying to boot a 2.6.11-rc1-bk9 kernel on my dual opteron Fedora Core 3 box. I will try -bk8 now. -Yenya Starting up RAID devices: md5 Unable to handle kernel NULL pointer dereference at 0008 RIP: {__make_request+61} PGD

2.6.11-rc1-bk9 crash in mdadm

Hi, Just FWIW, I've got the following crash when trying to boot a 2.6.11-rc1-bk9 kernel on my dual opteron Fedora Core 3 box. I will try -bk8 now. -Yenya Starting up RAID devices: md5 Unable to handle kernel NULL pointer dereference at 0008 RIP:

Memory leak in 2.6.11-rc1?

Hi all, I've been running 2.6.11-rc1 on my dual opteron Fedora Core 3 box for a week now, and I think there is a memory leak somewhere. I am measuring the size of active and inactive pages (from /proc/meminfo), and it seems that the count of sum (active+inactive) pages is decreasing.

Re: 2.6.11-rc1-bk9 crash in mdadm

Lars Marowsky-Bree wrote: : On 2005-01-21T17:12:30, Jan Kasprzak [EMAIL PROTECTED] wrote: : : Just FWIW, I've got the following crash when trying to boot a 2.6.11-rc1-bk9 : kernel on my dual opteron Fedora Core 3 box. I will try -bk8 now. : : Attached is a likely candidate for a fix

Re: XFS: inode with st_mode == 0

Christoph Hellwig wrote: : I have a better patch than the one I gave you (attached below). If you : send me a mail with steps to reproduce your remaining problems I'll put : this very high on my TODO list after christmas. Btw, any chance you could : try XFS CVS (which is at 2.6.9) + the patch

Re: XFS: inode with st_mode == 0

Christoph Hellwig wrote: : I have a better patch than the one I gave you (attached below). If you : send me a mail with steps to reproduce your remaining problems I'll put : this very high on my TODO list after christmas. Btw, any chance you could : try XFS CVS (which is at 2.6.9) + the patch

Re: AIC7xxx kernel driver; ATTN Mr. Justin T. Gibbs

Alan Cox wrote: : Except for an obscure bug under very high memory load I'm not aware of any : outstanding bugs in the AIC7xxx driver, certainly not like you describe. There : is however always a first time for any bug 8) Well, AIC7xxx crashes on me with stock 2.4.5 kernel (Athlon TB

Re: AIC7xxx kernel driver; ATTN Mr. Justin T. Gibbs

Alan Cox wrote: : Except for an obscure bug under very high memory load I'm not aware of any : outstanding bugs in the AIC7xxx driver, certainly not like you describe. There : is however always a first time for any bug 8) Well, AIC7xxx crashes on me with stock 2.4.5 kernel (Athlon TB

CacheFS

Hello, a friend of mine has developed the CacheFS for Linux. His work is a prototype read-only implementation for Linux 2.2.11 or so. I am thinking about adapting (or partly rewriting) his work for Linux 2.4. But before I'll start working, I'd like to ask you for comments on the

CacheFS

Hello, a friend of mine has developed the CacheFS for Linux. His work is a prototype read-only implementation for Linux 2.2.11 or so. I am thinking about adapting (or partly rewriting) his work for Linux 2.4. But before I'll start working, I'd like to ask you for comments on the

Re: Possible problem with zero-copy TCP and sendfile()

Wolfgang Rohdewald wrote: : On Tuesday 17 April 2001 22:36, Jan Kasprzak wrote: : > +    if (len == -1 || len > 0 && len < count) { : : are you sure there are no missing () ? : : if ((len == -1) || (len > 0) && (len < count)) { : : assumig that &&am

Re: Possible problem with zero-copy TCP and sendfile()

Jesse S Sipprell wrote: : After cursory examination of proftpd, it appears that there is a misuse of the : sendfile() call under Linux, which may be responsible for the corruption. The : code was originally based on BSD semantics. Under Linux, the offset argument : is not being used correctly

Re: Possible problem with zero-copy TCP and sendfile()

Jan Kasprzak wrote: : $ cmp -cl seawolf-sendfile.iso seawolf-i386-SRPMS.iso [...] : : Which simply means, that at 160628609 it started to send : the CD image from the beginning. Well, I did strace of proftpd, and it _may_ be a mis-interpretation of the sendfile(2) semantics

Re: Possible problem with zero-copy TCP and sendfile()

Andi Kleen wrote: : I guess to debug this problem it would be useful to get some idea about the : nature of the corruption. Could you enable sendfile() again, and when a : user complains ask to download it again and provide a : cmp -cl fileA fileB | head -500 listing of their differences?

Re: Possible problem with zero-copy TCP and sendfile()

Alan Cox wrote: : > : but once a fixed BIOS is out for your board that would be a good first step. : > : If it still does it then, its worth digging for kernel naughties : > : : > I don't think I have 686b southbridge. I have 686 (without "b"): : : Ok. What revision of 3c90x card do you

Re: Possible problem with zero-copy TCP and sendfile()

Andi Kleen wrote: : On Tue, Apr 17, 2001 at 03:10:07PM +0200, Jan Kasprzak wrote: : > 00:0c.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 74) : : IIRC the problem came up earlier. Some versions of 3com NICs seem to make : problems with the hardware checksum. There w

Re: Possible problem with zero-copy TCP and sendfile()

Alan Cox wrote: : > The long story: My server is Athlon 850 on ASUS A7V, 256M RAM. : > Seven IDE discs, one SCSI disc. The controllers and NIC are as follows : > (output of lspci): : : See the VIA chipset report on www.theregister.co.uk about corruption problems : with VIA chipsets. The

Possible problem with zero-copy TCP and sendfile()

Hello, I have discovered a possible problem on my host. The short story is: When downloading ISO images from this host (which runs 2.4.3 + zerocopy and ProFTPd with sendfile()), the image is sometimes corrupted (MD5 checksum of the downloaded file does not match). The

Possible problem with zero-copy TCP and sendfile()

Hello, I have discovered a possible problem on my host. The short story is: When downloading ISO images from this host (which runs 2.4.3 + zerocopy and ProFTPd with sendfile()), the image is sometimes corrupted (MD5 checksum of the downloaded file does not match). The

Re: Possible problem with zero-copy TCP and sendfile()

Alan Cox wrote: : The long story: My server is Athlon 850 on ASUS A7V, 256M RAM. : Seven IDE discs, one SCSI disc. The controllers and NIC are as follows : (output of lspci): : : See the VIA chipset report on www.theregister.co.uk about corruption problems : with VIA chipsets. The cases

Re: Possible problem with zero-copy TCP and sendfile()

Andi Kleen wrote: : On Tue, Apr 17, 2001 at 03:10:07PM +0200, Jan Kasprzak wrote: : 00:0c.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 74) : : IIRC the problem came up earlier. Some versions of 3com NICs seem to make : problems with the hardware checksum. There were

Re: Possible problem with zero-copy TCP and sendfile()

Alan Cox wrote: : : but once a fixed BIOS is out for your board that would be a good first step. : : If it still does it then, its worth digging for kernel naughties : : : I don't think I have 686b southbridge. I have 686 (without "b"): : : Ok. What revision of 3c90x card do you have ?

Re: Possible problem with zero-copy TCP and sendfile()

Jesse S Sipprell wrote: : After cursory examination of proftpd, it appears that there is a misuse of the : sendfile() call under Linux, which may be responsible for the corruption. The : code was originally based on BSD semantics. Under Linux, the offset argument : is not being used correctly

Re: Possible problem with zero-copy TCP and sendfile()

Jan Kasprzak wrote: : $ cmp -cl seawolf-sendfile.iso seawolf-i386-SRPMS.iso [...] : : Which simply means, that at 160628609 it started to send : the CD image from the beginning. Well, I did strace of proftpd, and it _may_ be a mis-interpretation of the sendfile(2) semantics

Re: Possible problem with zero-copy TCP and sendfile()

Andi Kleen wrote: : I guess to debug this problem it would be useful to get some idea about the : nature of the corruption. Could you enable sendfile() again, and when a : user complains ask to download it again and provide a : cmp -cl fileA fileB | head -500 listing of their differences?

Re: Possible problem with zero-copy TCP and sendfile()

Wolfgang Rohdewald wrote: : On Tuesday 17 April 2001 22:36, Jan Kasprzak wrote: : + if (len == -1 || len 0 len count) { : : are you sure there are no missing () ? : : if ((len == -1) || (len 0) (len count)) { : : assumig that has precedence over || (I believe so) Yes

Re: drivers/block/loop.c:max_loop

Jens Axboe wrote: : On Mon, Apr 16 2001, Jan Kasprzak wrote: : > Hello, : > : > I run a relatively large FTP server, and I've just reached : > the max_loop limit of loop devices here (I use loopback mount of ISO 9660 : > images of Linux distros here). Is there any rea

drivers/block/loop.c:max_loop

Hello, I run a relatively large FTP server, and I've just reached the max_loop limit of loop devices here (I use loopback mount of ISO 9660 images of Linux distros here). Is there any reason for keeping the max_loop variable in loop.c set to 8? Thanks, -Yenya -- \ Jan

drivers/block/loop.c:max_loop

Hello, I run a relatively large FTP server, and I've just reached the max_loop limit of loop devices here (I use loopback mount of ISO 9660 images of Linux distros here). Is there any reason for keeping the max_loop variable in loop.c set to 8? Thanks, -Yenya -- \ Jan

Re: drivers/block/loop.c:max_loop

Jens Axboe wrote: : On Mon, Apr 16 2001, Jan Kasprzak wrote: : Hello, : : I run a relatively large FTP server, and I've just reached : the max_loop limit of loop devices here (I use loopback mount of ISO 9660 : images of Linux distros here). Is there any reason for keeping

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

Jan Kasprzak wrote: : : : : 2.96-69 should be ok (thats the one I've been using without trouble). The : : original one with RH 7.0 off the CD does miscompile a few kernel things. : : It is the original one. I'll try with the -69: : With 2.96-69 the reiserfs seems to work well

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

Alan Cox wrote: : > Hans Reiser wrote: : >: This is why our next patch will detect the use of gcc 2.96, and complain, in the : >: reiserfs Makefile. : >: : > OK, thanks. It works with older compiler (altough I use gcc 2.96 : > for a long time for compiling various 2.[34] kernels without

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

Hans Reiser wrote: : This is why our next patch will detect the use of gcc 2.96, and complain, in the : reiserfs Makefile. : OK, thanks. It works with older compiler (altough I use gcc 2.96 for a long time for compiling various 2.[34] kernels without problem). -Yenya -- \ Jan "Yenya"

ReiserFS Oops (2.4.1, deterministic, symlink related)

Hello, with ReiserFS support in 2.4.1 I have decided to give it a try. I created a filesystem on a spare partition, mounted it as /mnt, and tried to use it. The kernel crashed - I am able to reproduce it with the following steps: - boot linux with init=/bin/bash - [optional]

ReiserFS Oops (2.4.1, deterministic, symlink related)

Hello, with ReiserFS support in 2.4.1 I have decided to give it a try. I created a filesystem on a spare partition, mounted it as /mnt, and tried to use it. The kernel crashed - I am able to reproduce it with the following steps: - boot linux with init=/bin/bash - [optional]

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

Hans Reiser wrote: : This is why our next patch will detect the use of gcc 2.96, and complain, in the : reiserfs Makefile. : OK, thanks. It works with older compiler (altough I use gcc 2.96 for a long time for compiling various 2.[34] kernels without problem). -Yenya -- \ Jan "Yenya"

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

Alan Cox wrote: : Hans Reiser wrote: : : This is why our next patch will detect the use of gcc 2.96, and complain, in the : : reiserfs Makefile. : : : OK, thanks. It works with older compiler (altough I use gcc 2.96 : for a long time for compiling various 2.[34] kernels without problem).